Replacing Like for Like

Can we really replace a system ‘like for like’?

You are presented with a project objective to replace a system ‘like for like’.

The root of this request, of course, is in trying to limit scope. Offering phase 1 to quickly deliver a baseline from which a phase 2 can enhance the business.

The issue that has been created is actually one of unbound scope. Systems will offer different opportunities and maybe remove some. The business teams will also have an unwritten agenda to see process improvements in their area.

I believe ‘like for like’ is an impossible request when introducing one system to replace another. I’ve tried to tackle this by reviewing and getting understanding of the As-Is business processes first.

  • To limit any efficiency opportunities to key processes that are materially hindered by the current system.
  • To reduce risk by highlighting key business differentiators that must be retained.
  • To stabilise the end to end business by defining cost to service figures that must be retained for core business processes.
  • To introduce process change where the new systems dictate it, and limit conversations on change to the above.

What methods have you employed to have a real conversation about what the project will deliver when asked to work on ‘like for like’?

Sarah Sparey

Please e-mail any comments or questions you have relating to this article.  Sarah Sparey is happy to answer any questions or comments you may have. We love to hear your comments and do publish them on this page.

Responses to this article:

15th September - Nick Lloyd - Programme Manager

The problem is “like for like” is a subjective requirement and it really needs a strong BA team to objectify it before proceeding further.

I think in the general case, the root of the request is risk mitigation, which may or may not manifest as trying to define a scope boundary: Mitigation that the new will be (or perceived to be) less than the old, and/or mitigation in lieu of a properly change-managed adoption of the new (i.e. by stealth).  Undertaking a project to deliver the exact same as what you already have is otherwise reasonably stupid (which doesn’t mean it doesn’t happen). I wouldn’t say it’s impossible to deliver like for like, but the effort required should be carefully evaluated and set against the alternatives – spending weeks building a facade that will be subsequently discarded is fair enough, providing the cost makes sense. I recall a project to integrate employees’ laptop experiences following a major telecoms merger that introduced a minefield of networking complexities and associated costs. The question “why don’t you just give everyone new laptops and manage the merger through people change?” came to mind (but it wasn’t my projectJ).

Have to say my approach is to repetitively (as diplomatically as possible) challenge/probe the reasons behind the request until the crux of the problem it’s trying to solve become sufficiently transparent. Then, look at different options beyond a purely technical solution. It could be beneficial to change an existing business process first then bring in the new system second, rather than vice-versa, thereby saving two lots of professional services costs. Of course, at this point most decision makers have already been sold on the idea their new system is infinitely “configurable” by vendors reliant on follow-on business for profitability, and it takes someone with technical and delivery credibility to convince effectively.

Really interesting piece Sarah.

16th September - Sarah Sparey - Head of Business Analysis

Thanks Nick,

I think you are right about the request for risk mitigation. It sounds such an innocent statement, how could it be complicated to deliver….

I can also think of a few times where the decision makers have been influenced by the ‘highly configurable’ nature of the system!!

Good times.


16th September - Damola Adeojo - Business Analyst

Sarah, Another reason for a like for like replacement, could be that, the old system is near end of life and no new version is available in the market, and if the new system has all desired functionalities. And like you mentioned, This will also reduce risk, scope, and schedule.

16th September - Sarah Sparey - Head of Business Analysis

I'm always interested to hear when we know a system is near the end of its life and needs replacing like for like. Can this really ever be true or should companies look to advance at every opportunity? 

17th September - Jeff Rayment - Business Analyst

"Like for like" is a phrase that brings me out in a cold sweat. 

I come from a software development rather than product background and have worked on a couple of these projects. The trigger for each was technology and, to be precise, difficulties in finding developers to support the existing system. And the reason for producing a "like for like" replacement has been to minimize impact on the users and/or other systems. 

It goes against the grain as a BA not to search out improvements in system and/or business processes but we are ultimately not decision makers. 

Our BA role on these projects really does open up the proverbial "can of worms" of what the existing system actually does. Existing specs/documentation? Users? Or is it only the existing system itself? 

Unless you're very lucky and can rely on your existing specs/documentation, you will need a combination of these sources. Then it all becomes rather difficult and messy to pull together the information everyone needs. And that's before you unearth something that nobody knew the system did or something that it seems to be doing wrong! The list of challenges goes on.... 

So I would say we can and do replace systems "like for like" but the projects can be strewn with risks and issues that you might not expect at first glance.

17th September - James Hendrix - Business Analyst

Currently working on such a "technical currency" project. While our scope is limited to delivering existing business functionality (like-for-like at the business function level, not the system level), we are taking the opportunity to re-examine the rationale and current solution approach. Maybe there's a better way. We will not endeavour to rebuild the same thing brick by brick; instead, we will seek to meet the business requirements in the best way possible given our constraints. The system in question is highly integrated; therefore, we are building an abstraction layer around it at all integration points. The solution will look and act like the current state to other systems. 

It has been a challenge to state the business value of technical currency with no new business functionality/capability; however, the solution will reduce current platform risks while removing current constraints to future business capabilities that will be fully delivered through other strategic projects. That is, the solution is one piece of a grand infrastructure puzzle. The infrastructure carries its own inherent limitations to business offerings. We will eventually be overcoming these limitations through a series of projects. In a sense, we are "partially delivering" new business functionality, but that language seems misleading and is falling out in favour of "removing constraints" language.

17th September - Richard Johanson - Operations and Supply Chain Management Professional

In an era when IT solutions come with the same sort of a shelf life as say, milk, it is amazing how much we have to spend to keep doing exactly the same thing we're currently doing.

18th September - Simon Chatwin - The Parsnip Workshop

Why would you? There's a cost to switching to another system. This has to be balanced by either reduced operating costs or improved functionality and benefits to the business. Without this, any business trying to do like for like is heading for bankruptcy. 

Thus I'd maintain there never is a like-for-like replacement project. 

Now, are the requirements the same, can you re-use RFPs from a previous project? Possibly but I'd bet that the new system has some differences from the current one and these differences must make life for the users better or reduce costs (or both - now there's a concept!) or the stakeholders will reject the new system.