The like for like concept, for system upgrades, is a means of controlling the change scope. A simplistic but useful model, the Project Management Triangle is often used to describe the constraints for managing a project. The model’s foundation is that quality is a function of, and constrained by, scope, cost and scheduling. In theory, you can adjust between the three with out impacting quality. But adjusting one constraint with out adjusting others will lead to lower quality. It might be debated that cost and scheduling are the easiest to explain but scope definition is the constraint that stakeholders will relate to most. There is also an associated reduction in troubleshooting effort through restricting the scope of the change .
For the purpose of this article, the “like for like” concept will be explained in the context of a software upgrade. This upgrade will contains both fixes to product defects and introduction of new minor and major functionality introduced by the product.
What is “like for like”?
The term “like for like” is most commonly used in the finance and insurance industry but also used in other occupations and jobs to a less extent (e.g. construction). Distilled into simple terms, it is comparing “two things that are similar in the same way” or “something is replaced on a like-for-like basis, it is replaced with something that is the same”. In technology, a “like for like” upgrade is also referred to as a technical upgrade.
Until recently, technical upgrades were not common and were costly. The operational cost of the upgrade was offset by the value provided by enhancements provided to improvements to existing product functionality and business transformation from implementing new product offerings. Recently, operational upgrade costs have been reduced by the availability of new vendor tools and their approach to upgrades. The new approach is required, in part, due to the move of more frequent product releases and updates.
For the purposes of change and project management the “like for like” concept means restricting the scope such that after the change is completed, functionality should be very similar if not exactly the same as it was before the change was implemented.
What is not “like for like”?
In my experience, system upgrades are often used as an opportunity to enhance existing, or introduce, new system functionality or transform business processes. This is not “like for like”. In this instance, the functionality after the change is often significantly different than prior to the change. At a minimum, resources and effort need to be expended preparing and training those who are impacted by the change in functionality. Referring back to the Project Management Triangle, this in turn increases the overall schedule and/or cost of the project.
How to implement like for like?
Using the example, provided in the ‘What is not “like for like”’, of upgrading the system with inclusion of enhancing the system functionality, introducing new system functionality and associated business processes, the project would consist of three major phases:
Phase 1 – Planning
- Identifying and achieving agreement on the scope for Phase 2 and Phase 3.
Phase 2 – Like for Like execution
- Executing the upgrade preserving existing business and operational functionality to the greatest extent possible.
- Preparing and training end-users is minimized and focused to those areas where the preservation is not possible or practical.
Phase 3 – Not Like for Like execution
- Phase 2 become the foundation for introduce all enhancements and new functionality. Execute the development and implementation of new functionality and related business processes.
- Focused training is provided to those end-users who are impacted by the enhancements and/or new functionality and associated business process. In some instances, training will also be required for end-users who are indirectly impacted.
Potential implementation scenarios
In the above section “How implement like for like?” a three phase process is provided for the like to like upgrade and implementation of non-like for like changes after the upgrade. The following diagram shows that process as Scenario 3 and includes two other scenarios.
Scenario 1 is the pure like for like execution with no requirement to incorporate changes to operational or business process or changes to or introduction of new functionality. Scenario 2 is where the change to process or introduction of new functionality is done prior to the upgrade. In both Scenario 2 and 3, the impact of the process change or feature introduction is separated from the impact the upgrade. This methodology separates the risk and has the potential to provide more flexibility in resource allocation and scheduling.
Value of the like for like principle
The like for like principle provides value during both the implementation and post-implementation of a project
Project and change management value
Controlling the scope of the change controls associated impacts on cost and scheduling. Risk evaluation of change is a critical determination. A more limited scope reduces risk, promotes agility and relatively quicker return on investment (ROI).
Further, like for like supports transition management where changes are introduced in phases, with corresponding reduction in organizational (change) management. As the pace of change increases, the more that can be done to reduce the amount of change experienced or perceived to be experience by the end-user is beneficial to the organization.
Like for like limits the number of factors that need to be considered and investigated should something not work after the upgrade. With like for like, if it worked before the upgrade, it should work after the upgrade. Reduction in post-implementation support costs further increases the ROI of the project.
Is like for like practical?
Like for like provides a practical means of questioning if something is in or out of scope for the project. Did the business functionality exists prior to the project? If yes, than it is in scope. If no, that the item is outside the scope of the project.
Practicality of implementing like for like is proportional to the degree:
- that the technical upgrade does not preserve existing user experience and existing functionality and
- ease of which the deployment of new features or functions can be turned off or minimized.
Newer software products are increasingly providing greater degrees of personalization and customization which, technically, support the ability to preserve like for like business functionality. From a change control perspective, if the like-for-like change is sufficiently small in either scope or logistical impact than it should not be subject to change control and significant project management and if frequently done, managed as a program.