Legacy modernization - Metrics & KPIs
Big ambitious legacy modernization projects often get detailed during execution. Even if they get executed on time or late, several of them don't pay back. Certain legacy modernization project metrics help tracking the project. Similarly defining and measuring certain KPIs help justifying return on investment in modernization projects.
Modernization project metrics
Keep an eye on following key high level metrics to avoid derailing your modernization project.
Cost can be combination of several components. When unknown cost components appear those were not counted for, they come from risk not identified or scope, estimation and planning not done properly. This may disturb your budget but this is not actual loss. You had to take care of this anyways whether it was known earlier or not. This can increase your budget and if it was not thought of earlier there is no way to handle it other than accepting increased cost of project.
The actual loss is loss of material or effort. Unused human effort, rework, incorrect technology investment and investing again are sources of this type of loss. If analysis, dependencies identification, requirement, and planning is not done well, you are going to waste your effort in idle human resources, rework or wrong investment in incorrect design or tools/platform/infrastructure. This can be handled by well architecting, detailed analysis of work and risks, tracking of effort by various techniques for example earned value analysis etc.
You should have tools and mechanism to continuously watch earned value, time line, and rolled up cost versus expected earned value and good alert mechanism. Continuous communication, right level of reporting and transparent visibility is the key. Defining milestones with specific, measurable, achievable, relevant and time bound deliverables is the only way to keep track of the cost and returns to avoid cost overrun.
Modernization projects may face issues of wrong cost estimation due to missing knowledge of current system, poor quality, unknown dependencies. Before commiting to a big modernization project a discovery phase with small transformation helps knowing the hidden challenges.
Other than project cost and controlling that project cost, there is a separate topic of return on investment. If cost is considered as a driver for modernization, there should be detailed analysis to justify investment, Choice of modernization approach should be driven by cost benefit analysis of various approaches. How the benefits will be achieved after transformation project should be defined and later measured. This topic is not part of project cost but part of KPI.
Schedule directly impacts time to get the returns on investment. Not only you get the returns late but also delayed projects have cost increase challenge also. There are idle times, lack of requirements and other inputs due to which resources become idle and that increases the cost of project.
Defining right schedule covering all aspects, right sized milestones and milestones with SMART deliverables helps tracking schedule. Identifying risks and taking mitigation strategies or taking different solution or approach helps schedule variance. Addition additional resources to coverup schedule variance it not the right approach in all cases, often it further increases the management overhead, pressure and complexity that further becomes cost overrun.
Critical path and critical dependencies must be kept on watch and any challenge in them should be managed that makes handling the schedule.
Incremental methods are the best way to keep check on schedule. Big bang, waterfall approach doesn't give visibility about actual deliverable and expected deliverable. Measurement becomes difficult if you don't have incremental deliverables and milestoens at regular interval.
If we look at root causes behind cost overrun or schedule variance most of them land up on risks not identified and not managed.
Modernization projects certainly have several risks. Often wrong assumptions are made in modernization projects and based on that approaches, cost and scheduling is defined. These assumptions become wrong later in the journey : for examples assumptions about size of the code or size of the system, quality (specially complexity ) of the system. Often some of the systems are rehosted, some are re-architected, some go to cloud and other is considered for on premise. Later this mixed approach presents a compatibility challenge and it becomes diffcult to achieve the objectives with the defined mixed approach. By the time you discover the compatibility you have already invested huge amount of money in the project. Detailed analysis of the portfolio, well architected choices and discovery phase with small amount of modernization activity helps unearthing the risks earlier in the journey.