Change Management | By Swadhin Mishra & Preeti Jain | Read time minutes
Large transformation projects for any organisation are uncommon, but do happen occasionally. In these projects, the base systems and operations of a multinational company are changed significantly and across various geographies. Change happens when the market changes rapidly or the organisational systems have become legacy, and change is needed in line with the latest and greatest developments in technology and services so that the competition does not run ahead of you.
We had the privilege of being part of a few large global transformation programmes spanning several countries and continents. The organisations involved are from the financial industry, the transformation related to changing the main banking systems, the backbone of the organisations' business, across geographies. Complete users, customers and operations of the bank are affected and need to adapt to the transformation being introduced.
The cost of large transformations like this runs into the hundreds of millions of dollars and comes with a lot of risks, making the full attention from top management critical. Successfully executing large transformations is a self-satisfying and rewarding experience with high visibility attached. But this comes with a caveat-most large programmes run into issues and close in the initial phases after analysis or depleted budgets result in programme cancellations.
This article focusses on sharing some insights on what to expect in these large and complex projects, how to handle them and what makes or breaks the programme. Throughout, we assume that due diligence has been completed and the transformation has been deemed necessary.
Budget Planning
Budget planning for large transformation programmes is complex. Many dimensions are needed to arrive at the cost numbers, so the chance of errors is high. Thus, for an organisation undertaking global transformation, cost planning is vital. If the cost is higher than the perceived benefits, a complete review of the programme is likely necessary. If you run out of money during a project, then there's nowhere to go. It will certainly have ripples throughout the organisation.
Following a few guidelines will help you plan effectively and stay on-budget:
- Plan bottom up rather than top down. This will give a more realistic picture. Moreover, you can later align with a re-estimate when detailed requirements are known.
- Engage vendors who have already taken up similar programmes, and use their expertise for costing. Floating an RFP (Request for Proposal) and responses to it will give an indication of the programme's cost.
- Refer to peer organisations that have already taken up similar programmes. If possible, connect with them and get insights on these transformations.
- Put the right person in charge of running the programme-someone who has handled large, multi-continent and complex programmes and will, thus, understand the nuances and better support the team.
- Keep high buffer margins. Large programmes often cost much more than planned.
Team Setup
The team is the most important aspect of the programme. The right people in the right jobs will yield great results. Identifying and empowering these right people will ensure the programme's success.
A project team will deliver results if good programme governance is in place at the beginning. Define structured programme governance with the right level of participation from IT and business. Their input is critical.
For a large transformation programme, the teams will be large and diverse, and come with different skill set levels. Having the correct expectation and utilisation will ensure higher productivity. A common issue that arises is when clients distinguish between their own staff and vendors and show bias. When in a project, these demarcations should not be put in front of the team. They kill open discussion, ownership of work and the free flow of ideas.
Have a lean team in the beginning, and do not rush to expand it. Keep the burn rate low. Increase the team when you have confirmation that all parameters for success are validated and thought through properly. On-board people to the project only if needed, and make sure they have the right skill sets. Engage with an implementation partner so that you can scale up with the right people as needed.
Dependency Management
Large programmes will have a large number of dependencies. Identifying and managing them is a must.
Multiple countries, multiple rollouts, multiple vendors, multiple products and large size—all will contribute to a lot of dependencies. You must diligently track these dependencies, raising them to risks or alerts if not as expected.
There will, most likely, be a complex relationship between these dependencies and the critical path of the project. Weave the dependencies into the project plan in a way that gives them enough cushion but has minimum impact on the critical path. As needed, identify alternatives for the critical ones.
Regularly visit dependencies in management meetings.
Equally important, have a plan for when unavoidable delays strike. Plan for how any impact can be mitigated to maintain the project schedule. All relevant parties should be part of the governance process.
Stakeholder Management
Stakeholder management is the management of internal and external initiatives, resources, groups, external vendors and third-party consultants who may or may not be under the direct control of the project manager. The deliverables of all such groups form the ultimate deliverable of this large transformation programme.
General rules of stakeholder management are to identify all stakeholders, classify them based on influence and impact, and then manage them accordingly.
Transformation programmes run for several years. Hence, the relationship with the stakeholders is for a longer duration. For the success of the programme, the working relationship with the working stakeholders must be as genuine and transparent as possible.
Vendor management also plays an important part in large programmes as the size of the programme surely forces the organisation to seek services of vendors. Having a good and fair working relationship with the vendors goes a long way in people taking extra steps towards the project's success.
Execution
We do not suggest any specific methodologies for execution, as each have their pros and cons, but the project governance should decide which is the most suitable. Any methodology needs to take into account the skill sets of people involved and the readiness of the teams to take up the processes. Regardless of the chosen methodology, management check-gates are an integral part. For example, after analysis, if the budget or outcome of the project will be as expected, then decide whether to increase or decrease the budget in the next phase. In extreme cases, park the analysis and postpone the next phase until more favourable conditions exist.
The analysis phase of the programme must be thorough. Shortcuts here can have a huge negative impact on the overall project to follow. Identify all aspects of the programme, ensuring you clearly identify all requirements. During the analysis phase, convert any foreseen technical challenges to small POCs (Proofs of Concept). This will minimise the technical risk during execution.
Since the transformation will span multiple countries, each one will have some difference in terms of requirements and expectations. This highlights a question of what execution should look like. There are three approaches:
- Execute and implement the project for the first location. Once it is successful, move on to the next location or country, and then add additional features based on local requirements.
- Gather requirements from all locations, and then build a common solution with global requirements. Implement the solution for each location with the delta in the requirements for the location with time.
- Take an intermediate approach of the above two. Gather global requirements, but build and implement for the first rollout country. Then build features for the other locations one by one.
We prefer the third one, but the management board based on the specific project and board experience in the domain can dictate which option should move forward.
Requirements analysis will drive what the solution will look like. For any uncertain activities that arise during requirements, it is better to start the design and development early. Project development should start with addressing the most complex things first if they are ready to be taken up.
This concept opposes many people's mind-set of early bird deliveries, like doing simple things first to showcase substantial progress to management. This may be good for visibility and morale, but it is not good for the programme as a whole. The basic rule of "fail fast" is always best. If you sort out the complex things first, rest assured, the remainder will be easy to accomplish.
Testing is an important aspect of any project as well. For finance project testing, there will be various rounds of testing. Give all testing sufficient time to ensure a good quality product and implementation. As the rollout will happen in several countries, and assuming that most features will be common across geographies, it is good to invest in testing automation. This may look expensive at the beginning but will turn out to be cheaper, more manageable and more efficient in the long run.
Concluding Remarks
The complexities of large projects require that you direct particular attention to planning the project, developing and delivering the solution, selecting team members, and sustaining a high-performing team over the long haul. All the standard practices of project management apply in these projects, too. But along with them, additional focus and handling are required for the success of the programme.