Business application implementation programs are perilous undertakings. Well over 70% of these implementations are still deemed "a failure" by either not meeting the budget, scope (specification) or time (to value). In the vast majority of these cases, it is the expectation mismatch that is the root cause - expectations on the functionality, expectations on the cost, expectations on the time to deliver - All three interlinked in the "iron triangle" of program management. In this first post (of three), we will discuss the scope creep, in particular the customisation scope.
A solution to a problem
Any proposal to add something to the system, or modify the basic way it operates, starts with a problem statement. On the face of it, the problem is well defined, and we can empathise with the problem owner. Let's take an example of the picture above - a problem statement that would lead to this customisation of the vehicle could be "the available parking spaces are too small to get into, we need a smaller turning circle" - The implementation above solves that problem. Not only that, but the main component, the fifth wheel, was already available in the form of the "spare". Problem Solved!
Back to the world of business applications, you hear the same arguments - we just need this field on the table, we already have the table and the form, that's not too difficult?
Adding to a complex system
In the example of the car, it seems such a simple solution, "what could possibly go wrong?". Quite a bit, if you take a moment to think about it. Let's assume the simplest implementation of this solution: a non-powered wheel that is manually lowered and raised when needed. Sounds simple, and it does not interfere with the complex mechanics that make the car work (this is a BIG assumption). But the car itself is not the entire system we need to consider - there are roads, pedestrians, cyclists, and other traffic to consider. Parking the car, the driver needs to exit the car while it is still partially on the road, lower the wheel, move on the road and push the car into the parking space. Not something I would look forward to on a busy road in poor visibility conditions. In the complex system considering other road users, we have introduced a catastrophic point of failure that may lead to injury or death of the driver. In business applications, there are enough scenarios where this is a good, but unfortunate, analogy to.
I have personally witnessed in one of the recovery projects I was involved in, the addition of a single checkbox on the item table (and subsequent transactions), and the logic to exclude these from inventory evaluation processes. It solved an actual problem - but introduced a new problem that turned out to be catastrophic; the company was unable to reconcile the inventory sub-ledger with the inventory account on the general ledger, and therefore could not close the books.
Voids other warranties
It doesn't seem to be an overly wild statement to assume that the car pictured above is a few decades outside of factory warranty. But let's consider the event of the construction holding the wheel in place fails, perhaps after driving over a pothole, and the wheel comes off. What if the vehicle driving right behind was a motorcycle, and the cyclist sustains serious injury. Would this be covered under standard third-party insurance? Or is there a culpable liability to be claimed?
Another modification I came across in a different remediation project - extending a field from 20 to 40 characters. Seems simple enough - the technical implementation took less than a minute. The issue was that this particular field in that system was "stamped" on each transaction, and in most cases, more than once (up to five time - reporting dimensions). In most cases, this would not represent a major issue, but in this particular case, it was a very high transaction volume system. None of this was taken into consideration in the database sizing, rendering the sizing exercise moot.
Unintended consequences: when one door opens, another is welded shut
Imagine the example above, the car is neatly parked in the tightest of spots. Now the driver of the car behind it wants to leave.... Typically, when parallel parking, if there is enough room to get into a spot, there is enough space to the front and rear to exit the parking space - If you do find yourself locked in, there is at least one driver that could have moved the car a bit forward or back but neglected to do so. Introducing the fifth wheel solution from above, and that no longer holds true - a foreseeable consequence is that other cars that do not have a similar solution to get in and out of tight spots, will be locked in.
Sometimes, implementing a comprehensive ERP solutions, there are options available that allows the project team to deliver the solution much faster and at lower cost by modifying the use of an otherwise not used module - the heroes during the project can quickly become the villains of the solution when either the company decides to use the original module (they did pay for it) as intended, or the vendor upgrades the module and the modification completely stops functioning as intended (the most likely, yet uncontrollable situation).
How to avoid the "fifth wheel syndrome" in your projects?
There is a two-pronged approach to keep the customisation in check: 1. minimise customisation, and 2. ensure the customisations that are done, are analysed and documented to understand and minimise all consequences, including the unintended ones.
To minimise, use the following:
· Use the 5Y method to understand the core problem (ask why the problem occurs and repeat till a total of five times on each answer to get to the root cause). Often, the solution proposed only addresses a symptom to a problem of process, which can be resolved without this, or sometimes any modification.
· Accept that the new system is not going to be the "old system plus" - some things are not going to be there in the new system
· Allocate budget to the consumer of the customisation - i.e. if the finance department needs the customisation, all the relevant costs are charge to the finance department cost centre or budget.
To minimise consequences:
· Document everything. It does not have to be extensive, but documentation should at least include: the root cause of the problem supposed to be solved, the symptoms of the problem, adjoining components of the solution affected, a technical and functional description of the solution, and known negative consequences.
· Investigate if there are alternatives to the proposed customisation, for example plug-ins, or adding functionality instead of modifying existing.
· If the costs of the above two points exceed the perceived value of the modification, refer back to the first list - it is probably wise not to proceed with the proposed solution, as the problem is not large enough.
Usually, there is a lot of emotion involved when dealing with gaps in the new system (real or perceived). Many members of the project team remain colleagues after the project - challenges to proposed solutions or root causes can be perceived as personal challenges. Another danger in managing the "fifth wheel syndrome" is organisational blindness - a fish is not aware of the water that surrounds it, it is sometimes very difficult to objectively observe the organisation from within. A trusted independent third-party advisor that brings experience in organisational design and behaviour, as well as business system architecture will be an investment well worth considering. The return on that investment is tangible during the project, and the positive effect will keep flowing through well after the project is delivered and the system is in use. Contact us if you want to discuss your particular situation.
Originally posted: 18 January 2018