Most, if not all, of us are familiar with the term "too big to fail" - most commonly applied to banks and financial institutions that were... failing during the financial crisis. The term did not reflect any of the robustness that was built into the big financial institutions, but it referred to the (deemed) unacceptable consequences of these systems actually failing. From mechanical engineering we know that the more complexity is introduced into a system, the higher the likelihood of failure is. The larger institutions are, the more room there is for complexity. Ironically, the response from governments and regulators in dealing with the crisis was to make the institutions even bigger. But how about on a smaller scale - digital transformation projects - how are we keeping complexity creep out of our programs?
When failure is not an option, it is inevitable
When failure is not an option, when the consequences of failure are catastrophic, our first response is to put safeguards in place - with redundancy. As a result, the system became bigger, and more complex. It is not too big to fail, but failure is inevitable. Especially with large integrated business applications, such as ERP, it becomes complex very fast. The poor success rate of ERP implementations reflects this complexity. Unfortunately, ERP systems are complex by nature. Implementing a smaller subset of the otherwise integrated functionality does alter the business case, and not in favour of value.
Failure or Value?
When creating a business case, we tend to look at various value scenarios - best case, worst case, etc. However, how many business cases are created where the cost scenarios are evaluated against success or failure? Typically, business cases are created assuming the implementation is a resounding success - or in case of the more "enlightened" business cases, the probability and impact of failure is significantly underestimated - otherwise such large transformative programs would never be approved by an alert board. But when the program is underway, and the first challenges are surfacing with a potential snowball into project delays, savvy program leaders see these signs as a potential to cascade down to affect major milestones in the program. Managing this, as well as the expectations (usually at this stage paired with a sinking feeling of unrecoverability) of the project stakeholders is a full-time task - an all that focus is not put in the other streams in the program with equal potential for failure. Once one thing fails, it has a cascading effect that is very difficult to stop.
Value in Failure!
Instead of creating overly complex redundancies on programs that are overly complex to begin with, we can also focus on the other side of the equation of probability and impact of failure. All redundancies are in place to reduce the probabilities of failure, as it can be catastrophic. But failure can be quite valuable - there is so much learning to be had from each failure, that a higher quality system can be an outcome that could not be reached without failing. If only the impact of failure is small, manageable, or even negligible. With a few ground rules and principles, this can be achieved.
Ground rules for a successful program
Applying the following ground rules to any seemingly complex program will significantly reduce the impact of failure and increase the odds in favour of achieving a positive business case.
1. Elegance in Simplicity - starting from the organisation design, to process design, to technical design, one should always ask: "Is this as simple as possible? What can be removed to make it simpler, and still effective?"
2. Customer experience is leading the design, and customers care about outcome, and their experience reaching to that outcome. Process and needs to cater for outcome and positive experience - any part of the process that does not influence the outcome for and experience of the customer, moves down in the hierarchy of necessities.
3. Create small iterations of the program; cut the program up in small pieces where each piece is a simple project with relative low impact of failure.
4. In order to keep the program velocity and momentum, parallel streams are encouraged, but each with no or as little impact as possible on other streams (minimised concurrent dependencies)
5. Create and foster a problem-solving culture based on trade-offs (how can we achieve maximum outcome with the means we have), as opposed to entitlements (we require this functionality - the program must provide this).
Minimizing concurrent dependencies
There are always dependencies in any program - some are inevitable, and some can be mitigated early on. For example - data migration: there is no reason not to start cleansing data early in a staging environment. Even if we do not know all the mapping yet, we know what data is available, and that can be moved into a staging environment for cleansing prior to the data mapping being completed. Also known integrations - the target and source systems are a known, and the endpoints can be prepared based on what these systems provide and/or require.
Tolerate excellence
Make a program large and expensive enough, and the expectations are nothing less than perfection. This is truer for the users of the system than the budget owners - as the latter will feel with the wallet what the cost of perfection is. The end-user of the system has an expectation of "everything we had, plus most or all of the things on the wish list". When to recognise the point of excellence? It is when the solution towards perceived perfection introduces points of failure that were not there before its introduction - points of failure that in turn will need to be mitigated by extensions or redundancies that prevent errors. The solution here is not to add more, but to take away the cause, the need for these extensions or redundancies.
Conclusion
Business transformation programs and ERP implementations are complex. By having clear and easy to follow ground rules, the complexity can be managed by reducing the impact of failure. In fact, a culture of learning is to be encouraged, where the failures not only have a small, if not negligible, negative impact on the program, they are a means for the program team to teach themselves better ways of organizing the business flows and creating better and more elegant solutions. When the team focuses on customer experience and outcomes, instead of system functionality as the first priority, the resulting system is more likely to achieve better customer engagement. Finding an addition to the program leadership team that focuses on the simplicity and elegance of the solution, its design and architecture will do the program a great service.
Originally posted: 19 December 2017