Like-for-like replacement.
Sounds pretty simple, doesn’t it? That’s an easy project to deliver, right?
Wrong.
Why would we do a like-for-like (L4L) project? The IT group may want to upgrade to a new system, because the old one is broken, or because they’ve found something better. Maybe we want to avoid re-training users. Or, maybe our L4L project is hiding in a larger project. It could be phase 1, in which functionality is replicated, while new value is delivered in phase 2. There’s no strong pull from users for this L4L project, so to avoid ‘disruption’, the project plans to hot swap a technology layer while otherwise preserving functionality, much like a magician yanking off a tablecloth without disturbing any of the tableware. However, someone is about to have their dinner spoiled.
A clarification. L4L exhibits some of the characteristics of refactoring. But refactoring deliberately tries to stay small, in time and cost. The success criteria are also easily established, for instance, as unit tests. I’m talking here about replacing one non-trivial IT system with another, especially if the target system is primarily bought rather than built.
The Key Problem
Framing a project as L4L is not just demonstrably incorrect, it is lazy to the point of negligence. The L4L framing is incorrect because it can never be achieved. The current technology solution has constraints, and business processes have evolved under the current technology constraints. But the new solution will have new technological constraints. There is no chance the two sets of constraints will be equivalent (if they are equivalent, why would you bother changing systems?) Therefore, business processes will be forced to evolve under the new solution. If business processes are changing, this cannot be a L4L project, and the framing is incorrect.
It’s irrelevant whether we’re talking about L4L functionality or L4L business outcomes. As above, L4L functionality is a logical impossibility. If we’re talking L4L business outcomes, which users are going to support a disruptive change in functionality in order to be able to achieve exactly what they do today, and no more?
The L4L framing is lazy because it discourages critical thinking. Stakeholders will confuse the apparent simplicity of framing with simplicity of execution, meaning they will be less engaged in resolving the thorny problems that will inevitably crop up. This is especially important for project sponsors and other senior stakeholders. The business will not be engaged in a process that gives them no voice. This will be doubly so if, as above, the project is not actually like for like, and the deleterious changes in business process are being driven by IT.
The real negligent laziness, however, is in assuming that collectively we haven’t learnt any more about how to deliver business value since we implemented the current system. The current system is probably five to ten years old, and inevitably has shortcomings – why would we copy it? We might, at great effort, be able to figure out what the system is capable of, then build this, but this is far more than users actually use, and entirely different from what they want. This lazy framing leads to much more work than would be required if we simply went to the business/customers to understand what they really need at this time.
You’ll end up taking longer, costing more, and delivering poorer outcomes if you frame your project as like-for-like.
More Problems
Like for like framing is the key problem, but it spawns a host of other problems:
- Inflexible execution means no ability to respond to change
- Analysis by reverse engineering is very wasteful
- Sysadmin as the customer precludes insight
- Prioritisation is backwards to avoid destroying value
- Value delivered in a Phase 2, which never happens
- Reporting misses the fact that there are two different things to report
These are substantial topics in their own right. I’d like to finish this post sometime, so I’ll try to pick up these threads in detail in future posts.
What Might Happen?
So, how might an L4L project play out?
Well, it’s hard to predict the future, but like Plutonium , L4L projects are unstable and tend to disintegrate. While a typical agile project is self-correcting, in that everyone sees the value, scope can be adjusted to meet time, and so on, a L4L project has no give.
When estimates are discovered to be optimistic – as complex workarounds will inevitably be required to deliver old results on new technology – the only option for a true L4L project is to run late. Or, we expose the L4L fallacy by making functional or non-functional compromises. Likely, it will be a combination of both.
Stakeholders who were reluctant from the start are now in an even worse position. They originally stood to gain nothing but disruption, but now they definitely lose out. They may begin political manoeuvring to make the project go away. Governance will probably start sniffing around if this late, costly project is not delivering value.
Again, at this point, there’s not much room to move in a L4L project. There may be nothing of value delivered. You stuck with either writing the project off, or toughing it out to an expensive and unsatisfactory conclusion. You may even tough it out only to write it off later. Of course, you can change the way you are doing things, but that basically means starting over. So, why not get it right from the start?
The Solution
The solution is, of course, to frame the project as delivering new value.
| Like-for-like | Delivering value |
|---|---|
| Technically can’t be achieved | Value drives right behaviours |
| Business disengaged – everyone wants to go last | Business engaged – everyone wants to be first |
| Analysis & design = reverse engineering | Break current constraints for better solution |
| Wasteful and high risk | Efficient and low risk |
Even if you’re being forced to replace a system, make sure you go out to the stakeholders and ask them what they want to make their lives better, right now. This is the only way you really get their buy-in, the only way they’ll make do with less here and there because they’re getting more overall, the only way they’ll be engaged in resolving difficult delivery problems, the only way they’ll back you up instead of sell you out when things get tough. It’s also the only way you’ll avoid perpetuating those arbitrary constraints you inherit with a L4L project.
Next time you’re asked to start a L4L project, start by changing the framing.