Like for Like – how to preserves existing business and leverage technological advancement
Last updated: June 07, 2024 Read in fullscreen view
Recommended for you
- 01 Aug 2024
The Standish Group report 83.9% of IT projects partially or completely fail 150/1772 - 13 Apr 2024 Lessons on Teamwork and Leadership from Chinese story book "Journey to the West" 41/949
- 02 Nov 2021 What is Terms of Reference (ToR)? 23/1466
- 03 Apr 2022 Microsoft Solutions Framework (MSF) 12/1157
- 12 Oct 2022 14 Common Reasons Software Projects Fail (And How To Avoid Them) 10/504
- 18 Dec 2023 The Cone of Uncertainty in Scrum & Requirement Definition 8/643
- 18 Oct 2021 Key Elements to Ramping Up a Large Team 7/1108
- 13 Oct 2021 Outsourcing Software Development: MVP, Proof of Concept (POC) and Prototyping. Which is better? 6/424
- 20 Jan 2022 TIGO Self-Organization Practice: Change Management Workflow 6/430
- 28 Jul 2022 POC, Prototypes, Pilots and MVP: What Are the Differences? 6/606
- 16 Jun 2022 Rapid Application Development (RAD): Pros and Cons 5/800
- 31 Aug 2022 What are the best practices for software contract negotiations? 5/215
- 05 Mar 2021 How do you minimize risks when you outsource software development? 5/317
- 07 Oct 2025 Case Study: Using the “Messaging House” Framework to Build a Digital Transformation Roadmap 5/45
- 01 Jan 2024 The pros and cons of the Centralized Enterprise Automation Operating model 4/165
- 20 Jul 2022 Software Myths and Realities 4/797
- 12 Dec 2021 Zero Sum Games Agile vs. Waterfall Project Management Methods 4/374
- 04 Oct 2022 Which ERP implementation strategy is right for your business? 4/278
- 07 Jul 2022 Managing Project Execution Terms 3/379
- 20 Jan 2021 Fail early, fail often, fail cheap, fail safe but always fail forward 3/688
- 18 Jul 2021 How To Ramp Up An Offshore Software Development Team Quickly 3/516
- 01 Dec 2023 Laws of Project Management 3/249
- 10 Apr 2024 The Parking Lot Method: Unlocking a Simple Secret to Supercharge Your Productivity 3/403
- 05 Sep 2023 The Cold Start Problem: How to Start and Scale Network Effects 3/167
- 26 Sep 2024 Successful Project Management Techniques You Need to Look Out For 2/368
- 01 May 2024 Warren Buffett’s Golden Rule for Digital Transformation: Avoiding Tech Overload 2/188
- 24 Nov 2023 The project management paradox: Achieving MORE by doing LESS 2/193
- 02 May 2022 What Is RAID in Project Management? (With Pros and Cons) 2/734
- 05 Jun 2023 Fractional, Part-Time (virtual) or Interim CTO: Who Will Cover Your Business Needs? 2/109
- 02 Dec 2022 Success Story: Satsuki - Sales Management Software, back office app for School Subscription Management 2/219
- 04 Oct 2021 Product Validation: The Key to Developing the Best Product Possible 2/295
- 11 Nov 2021 What is an IT Self-service Portal? Why is it Important to Your Business? 2/364
- 02 Nov 2021 [Case Study] Streamlined Data Reporting using Tableau 2/276
- 28 Oct 2022 Build Operate Transfer (B.O.T) Model in Software Outsourcing 2/361
- 14 Jun 2022 Example and Excel template of a RACI chart in Software Development 2/707
- 12 Aug 2022 What is End-to-end project management? 2/382
- 15 May 2022 20 Common Mistakes Made by New or Inexperienced Project Managers 2/247
- 22 May 2022 What are common mistakes that new or inexperienced managers make? 1/243
- 03 Apr 2021 How digital asset management streamlines your content workflow? 1/312
- 13 Feb 2021 Why is TIGOSOFT a software house for Enterprise Application Development? 1/336
- 27 Jan 2020 Should a project manager push developers to work more hours due to mistakes of manager schedule setting? 1/412
- 01 Mar 2024 10 Project Management Myths 1/120
- 12 Aug 2024 Understanding Google Analytics in Mumbai: A Beginner's Guide 1/84
- 07 Dec 2023 12 project management myths to avoid 1/167
- 30 Nov 2023 Project Managers, Focus on Outcomes — Not Deliverables /143
- 06 Nov 2023 How do you streamline requirement analysis and modeling? /184
- 02 Nov 2022 Difference between Change Management and Project Management /216
- 01 Aug 2022 Is planning "set it and forget it" or "set it and check it"? /264
- 23 Jun 2024 Best Practices for Managing Project Escalations /183
- 21 Jun 2024 Dead Horses and the Escalation of Commitment /123
- 02 Jun 2024 Reviving Ancient Wisdom: The Spiritual Side of Project Management /204
- 06 Mar 2024 [SemRush] What Are LSI Keywords & Why They Don‘t Matter /131
- 19 Oct 2021 Software development life cycles /628
- 21 Jun 2021 6 Useful Tips To Streamline Business Processes and Workflows /515
- 17 Oct 2021 Does Fast Tracking increase project cost? /348
- 13 Jan 2020 Quiz: Test your understanding project cost management /568
- 03 Sep 2022 The secret of software success: Simplicity is the ultimate sophistication /186
- 02 Dec 2021 3 Ways to Avoid Scope Creep in IT Consulting /192
- 06 Jun 2022 Change Management at the Project Level /292
- 03 Jan 2023 Organizing your agile teams? Think about M.A.T (Mastery, Autonomy, Purpose) /333
- 09 May 2022 Build one to throw away vs Second-system effect: What are differences? /297
- 10 May 2022 Levels of Teamwork /180
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.
Explore more on these topics
04102024050214_thumb.jpg)
Guest Blogging: The Definitive Guide
Top Trending Topics
Share This
Link copied!