Like for Like – how to preserves existing business and leverage technological advancement
Last updated: June 07, 2024 Read in fullscreen view



- 02 Nov 2021
What is Terms of Reference (ToR)? 1093
- 01 Aug 2024
The Standish Group report 83.9% of IT projects partially or completely fail 919
- 18 Oct 2021
Key Elements to Ramping Up a Large Team 892
- 03 Apr 2022
Microsoft Solutions Framework (MSF) 882
- 16 Jun 2022
Rapid Application Development (RAD): Pros and Cons 705
- 13 Apr 2024
Lessons on Teamwork and Leadership from Chinese story book "Journey to the West" 602
- 19 Oct 2021
Software development life cycles 598
- 20 Jul 2022
Software Myths and Realities 589
- 20 Jan 2021
Fail early, fail often, fail cheap, fail safe but always fail forward 560
- 02 May 2022
What Is RAID in Project Management? (With Pros and Cons) 533
- 13 Jan 2020
Quiz: Test your understanding project cost management 498
- 28 Jul 2022
POC, Prototypes, Pilots and MVP: What's the differences? 477
- 14 Jun 2022
Example and Excel template of a RACI chart in Software Development 471
- 21 Jun 2021
6 Useful Tips To Streamline Business Processes and Workflows 438
- 18 Dec 2023
The Cone of Uncertainty in Scrum & Requirement Definition 436
- 18 Jul 2021
How To Ramp Up An Offshore Software Development Team Quickly 417
- 12 Oct 2022
14 Common Reasons Software Projects Fail (And How To Avoid Them) 396
- 27 Jan 2020
Should a project manager push developers to work more hours due to mistakes of manager schedule setting? 389
- 20 Jan 2022
TIGO Self-Organization Practice: Change Management Workflow 342
- 11 Nov 2021
What is an IT Self-service Portal? Why is it Important to Your Business? 320
- 13 Oct 2021
Outsourcing Software Development: MVP, Proof of Concept (POC) and Prototyping. Which is better? 317
- 28 Oct 2022
Build Operate Transfer (B.O.T) Model in Software Outsourcing 311
- 12 Aug 2022
What is End-to-end project management? 303
- 12 Dec 2021
Zero Sum Games Agile vs. Waterfall Project Management Methods 291
- 05 Mar 2021
How do you minimize risks when you outsource software development? 290
- 03 Jan 2023
Organizing your agile teams? Think about M.A.T (Mastery, Autonomy, Purpose) 289
- 07 Jul 2022
Managing Project Execution Terms 289
- 17 Oct 2021
Does Fast Tracking increase project cost? 278
- 26 Sep 2024
Successful Project Management Techniques You Need to Look Out For 271
- 03 Apr 2021
How digital asset management streamlines your content workflow? 266
- 13 Feb 2021
Why is TIGOSOFT a software house for Enterprise Application Development? 256
- 09 May 2022
Build one to throw away vs Second-system effect: What are differences? 250
- 02 Nov 2021
[Case Study] Streamlined Data Reporting using Tableau 248
- 06 Jun 2022
Change Management at the Project Level 230
- 22 May 2022
What are common mistakes that new or inexperienced managers make? 226
- 04 Oct 2021
Product Validation: The Key to Developing the Best Product Possible 218
- 10 Apr 2024
The Parking Lot Method: Unlocking a Simple Secret to Supercharge Your Productivity 211
- 15 May 2022
20 Common Mistakes Made by New or Inexperienced Project Managers 202
- 04 Oct 2022
Which ERP implementation strategy is right for your business? 202
- 01 Aug 2022
Is planning "set it and forget it" or "set it and check it"? 189
- 31 Aug 2022
What are the best practices for software contract negotiations? 186
- 02 Dec 2022
Success Story: Satsuki - Sales Management Software, back office app for School Subscription Management 166
- 02 Dec 2021
3 Ways to Avoid Scope Creep in IT Consulting 163
- 02 Jun 2024
Reviving Ancient Wisdom: The Spiritual Side of Project Management 142
- 05 Sep 2023
The Cold Start Problem: How to Start and Scale Network Effects 128
- 01 Jan 2024
The pros and cons of the Centralized Enterprise Automation Operating model 127
- 10 May 2022
Levels of Teamwork 126
- 01 Dec 2023
Laws of Project Management 124
- 01 May 2024
Warren Buffett’s Golden Rule for Digital Transformation: Avoiding Tech Overload 123
- 07 Dec 2023
12 project management myths to avoid 120
- 30 Nov 2023
Project Managers, Focus on Outcomes — Not Deliverables 118
- 06 Nov 2023
How do you streamline requirement analysis and modeling? 110
- 24 Nov 2023
The project management paradox: Achieving MORE by doing LESS 109
- 03 Sep 2022
The secret of software success: Simplicity is the ultimate sophistication 107
- 06 Mar 2024
[SemRush] What Are LSI Keywords & Why They Don‘t Matter 102
- 02 Nov 2022
Difference between Change Management and Project Management 100
- 21 Jun 2024
Dead Horses and the Escalation of Commitment 96
- 05 Jun 2023
Fractional, Part-Time (virtual) or Interim CTO: Who Will Cover Your Business Needs? 81
- 23 Jun 2024
Best Practices for Managing Project Escalations 79
- 01 Mar 2024
10 Project Management Myths 66
- 12 Aug 2024
Understanding Google Analytics in Mumbai: A Beginner's Guide 53
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
- Identifying and achieving agreement on the scope for Phase 2 and Phase 3.
- Exit Criteria: Determining when to wrap up software development.
Phase 2 – Like for Like execution
- Executing the upgrade preserves existing business and operational functionality to the greatest extent possible.
- 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
- Phase 2 became the foundation for introducing 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 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:
- that the technical upgrade preserves existing user experience and 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 then it should be handled as a standard change, and if frequently done, managed as a program with minimal project management.
