Business change should be quite straightforward
The basic approach to business change is very straightforward: you create a credible and financially justified business vision that aligns with your organisation’s strategic objectives; you define the future operating model that will support that vision; you identify the relevant elements of your current operating model; and finally, you develop the roadmap that will move you from where you are now to where you want to be. Yet, in our experience, far too many organisations that launch such change programmes fail to meet their objectives.
What causes failure?
Such failures can occur even where there is a clear and compelling business vision, fully bought into by top management, and with a strong supporting business case for change. Business change programmes can obviously be derailed by unexpected events, such as a takeover bid or an external market disruption that forces a change in strategic priorities. But, all too often, failures occur for internal and avoidable reasons. These typically involve inadequate preparation in two crucial areas: understanding of the current state operating model and development of a viable roadmap.
The truth is that work in these areas seems mundane compared with the challenges of fleshing out and promoting the business vision and designing its supporting systems. Deep knowledge of the current state is likely to reside with an organisation’s systems maintenance teams, but unless this knowledge is made available to the developers of the new business model, ideally via a shared enterprise architecture repository, critical issues and dependencies are likely to be missed.
Think of it like a building project
A good analogy is that of a typical domestic building project intended to meet the needs of a growing family: planning to extend your living space by converting an existing loft into an extra floor with bedrooms and a bathroom. Same walls, same roof (apart from a couple of skylights). What could possibly go wrong?
Answer: Quite a lot if you don’t anticipate problems prior to the build. You would surely need an architect to check whether the existing structure is able to support the weight that the additional floor would entail. You would also be wise to get expert assessment of your current electricity, central heating, water and sewerage services, to know whether they would need upgrading to cope with the additional demands to be placed on them. Where would the staircase need to go, and what impact would it have on the configuration of the rooms in the floor below? Finally, if you intend to continue living in the house during the construction work, how could the work be isolated, scheduled and managed with minimum disruption to your family’s life?
Exactly the same logic should be applied to any business change project. The scope of the planned business change should include a detailed review of those aspects of the current business operating model that are impacted. A competent enterprise architect will ensure that the current state in these affected areas is well defined and up to date. That would include the business processes, the applications, the databases, and their supporting technologies. This preparation should provide a sound baseline for the change programme. And even at an early stage, it should highlight those elements that are not designed to cope with the demands of the changed operating model. An example of this would be a system that would be required to provide a range or level of services beyond its capacity limits.
Apply the same diligence to your IT Roadmap
A similar level of care is needed with the business change roadmap, which is required to bridge the gap between the current operating model and its projected future state. It should highlight dependencies between, as well as, within, workstreams, and it should be phased to allow for adjustment of the plans in case conditions or requirements change. Importantly, it should take account of external factors that could potentially influence the plans.
Here again, change project managers are often so narrowly focused on delivering their end product that they tend to overlook or skate over crucial elements of the transition plan. A common failing is to assume that the skilled and knowledgeable resources needed to deliver certain elements will be available on and during the dates specified in the plan. For those old enough to remember the Y2K problem, where the two-digit year field threatened to disrupt systems at the start of the 21st century, one banking organisation we knew well had at that time developed an elaborate and detailed plan for updating their company’s core business platform within an 18-month timeframe, in parallel to the Y2K programme. When presented to the management team, this plan was soon shot down when someone pointed out that in the short to medium term the required developers would be working flat out doing Y2K fixes and testing, and even when this work had been completed, a change freeze would kick in.
This was clearly an extreme example of blinkered thinking, but it does illustrate the dangers of not including an enterprise-wide perspective in the consideration of any business change programme.
Useful Links:
How CEAs Empower Enterprise Responses to Disruptive Forces
How to succeed at Digital Transformation
Roadmapping and Strategy – An Approach for Success