Golden rules for large migration
Author: Yogita Sachdeva, Group Project Manager
In my experience of working with large banks, I have worked on small programs related to acquisitions and mergers. I have also worked on voluminous upgradations and migrations. I wondered what was different which actually a tie breaker for large program was. I always tried to scratch my brain to figure out what it takes to make a large program run. I realized that smaller programs generally get successfully delivered with the apt technical skills of the team. However, large programs are normally meant to deliver a business strategy as big as the creation of a new bank. A large program encompasses a group of related projects, managed in a coordinated manner, to obtain benefits and to optimize the cost control.
Programs may include elements of related work outside the scope of discrete projects in a program. Some projects within a program can deliver useful and incremental benefits to the organization before the program itself has been completed. Program management also involves, coordinating and prioritizing resources across projects, managing links between projects and overlooking the overall costs and risks in the program. In short, programs deliver strategic outcomes.
Typical challenges in large migration programs
The complexities of large projects requires particular attention to be directed towards planning the project, developing and delivering the solution, selecting team members, and sustaining a high-performing team over the long haul.
In general, programs encompass typical challenges like:
- Continuously evolving requirements
- Multiple and parallel cycles
- Constant pressure due to crunched timelines
- Multiple stakeholders
- Bringing together the right team
Of the various elements that make long-duration projects complex, the most significant are the inevitable changes that occur in the business environment, necessitating adjustments to virtually all elements of the project. Knowing this, successful project leadership team evolves, to practice situational project leadership, by adapting and modifying their approach to accommodate the inevitable changes. In most of the programs, requirements keep changing till we reach execution. Gone are the days where we had frozen requirements before the design phase started. However, without having the requirements frozen beforehand, there are chances that the initial estimated effort could overshoot by considerably higher percentage which in turn could impact the profit margin and resource coverage. As an in today's world, the expectation is to absorb the overshot effort with 100% coverage, a workable solution has been proposed, which involves - a detailed explanation of what was done earlier and how it is being done currently. Getting an alignment on '"what"' actually helps to justify "'how,"' (in the above statement), which in turn becomes extremely helpful for controlling the "cost".
Theoretically, we need to maintain a balanced role ratio with the right skill set. But in a large program, we also need to keep the harmony of the team. Success of a large program resides in a well-connected, well-united, and well-integrated team. Any lapse in skill can be compensated with upliftment. Role maturity comes with increased work experience; but there is no ground rule for harmony. For successful program one needs to maintain the harmony in the team by making sure that positivity is engraved within the team by overcoming any negativity within the team. In my opinion, a large program should be treated like a tree, and any branch that is not growing with the correct harmony should be removed as and when discovered. This can be done successfully if the root is strong. Otherwise, sometimes, that branch can be so powerful that it might infect the root itself.
As they say, "Ignorance is bliss" and "Incomplete knowledge is dangerous", these sayings stands true in large programs as well. A large program generally involves delivery from multiple groups, involving business analysis team, development team, design team, QA team defect management team, release management team and last, but not the least, the implementation team. If the flow of information is not uniform, it creates a gap. There will be a lot of hidden overhead effort that will go in bridging this gap. Identification of the right stakeholder is the most suitable solution for this. Definition of the 'right stakeholder' is very important, which is beyond any designation or role. It is purely affiliated to the right responsibility of the stakeholder. Adherence to this 'right stakeholder through right responsibility' matrix certainly ensures the right flow of information, which is required for each layer that is responsible for delivery.
Changes in schedules is a rampant issue in large programs. There are possibilities that there might be a delay in delivery by any of the teams and from there the chain of delay begins, as a result of which the team at the fag end is the one which is most affected. Communicating the clients and the team needs to be done periodically. We generally get into the mode of pressurizing the team who is at the fag-end; but actually, we ignore the original cause of delay. We strengthen the communication by keeping the clients informed that there is a delay and we shall recover; but at that time, we don't seem to bother much about the team at the fag-end. Adherence to a schedule is not fitment of boxes in a schedule -- it actually starts at the stage of requirement. Delayed requirement, should mandatorily be accompanied with a revised schedule.
Rigorous risk management preempts challenges and seizes new opportunities.
For large programs, the ability to adapt is the difference between success and failure. A systematic, reliable approach increases confidence and accuracy. It also helps in overcoming roadblocks in a seamless manner.