The like for like principle, 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 without impacting quality. But adjusting one constraint without 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” principle will be explained in the context of a software upgrade. This upgrade will contain 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 lesser 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.

A “like-for-like” enterprise IT change is the replacement of existing software systems  for similar apps in design, function, use and maintenance, whether or not from the same vendor, that requires no additional alteration or modification of existing functions to rollout and occupies the same or similar footprint of the replaced system.

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” principle 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

1. Identifying and achieving agreement on the scope for Phase 2 and Phase 3.
2. Exit Criteria: Determining when to wrap up software development.

Phase 2 – Like for Like execution

1. Executing the upgrade preserves existing business and operational functionality to the greatest extent possible.
2. Preparing and training end-users is minimized and focused on those areas where the preservation is not possible or practical.

Phase 3 – Not Like for Like execution

1. Phase 2 became the foundation for introducing all enhancements and new functionality. Execute the development and implementation of new functionality and related business processes.
2. 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 processes 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 of 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 experienced by the end-user is beneficial to the organization.

Post-implementation value

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?

Microsoft and Oracle support the use of technical (like for like) upgrades.

Like for like provides a practical means of questioning whether something is in or out of scope.  For example, did the business functionality exist prior to the project?  If yes, then it is in scope. If not, then the item is outside the scope of the project.

Practicality of implementing like for like is proportional to the degree:

1. that the technical upgrade preserves existing user experience and functionality and
2. 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 then it should be handled as a standard change, and if frequently done, managed as a program with minimal project management.