Cutting complexity in tech transformations

More IT programs fail than succeed. Although they begin with good intentions, they’re often late, over budget, and don't provide what is required.

The history of corporate IT is riddled with such programs and while there are many reasons for the failures, a potential root cause may lie deeper in the amount of complexity that often creeps into an IT system and overall transformation program.

All too often, IT and the business embarks on a multi-year project with specific goals in mind – enhance existing processes, replace an existing legacy system or develop something truly innovative to support new business models.

Over time however, as details become more tangible, people begin to rethink their initial assumptions, and the original goals become muddied with many issues.

Stakeholders start demanding different requirements to fulfill their own needs. Soon the temptation to develop solutions to keep everyone happy becomes too strong to resist that the program’s ensuing complexity overcomes it.

Some companies have learned this the hard way. A few years ago, when a financial services firm decided to replace its core registry platform, the IT department became so overwhelmed with trying to meet the requirements of all stakeholders, that it lost track of its end goal.

It didn’t matter whether the requirements were necessary or just ‘nice to have’, they began to stack up quickly, increasing the complexity of the project and the new system. In the end, the business got so frustrated with unmet expectations that it cut the program.

Another common pitfall that leads to increased complexity within programs is lack of governance. Harvard Business Review blog The IT Project That Brought a Bank to its Knees rightly said that when it comes to transformation initiatives, many end up being managed as IT projects, with responsibility bestowed to the CIO.

To be sure, every transformation program must ultimately be led by the business. But on its own, the business is rarely aware of the impact and change each requirement may have, particularly on an IT system.

As requirements change and grow, so does the complexity of the system and the total cost of ownership.

One large retailer in the US started a $1.4 billion program to modernise its IT systems. A year later, it abandoned the program because it realised that the new system was so highly customised that maintenance became prohibitively expensive.

Another shortcoming that often leads to an unnecessarily complex solution is when organisations with long-standing legacy systems try to embed existing ways of working into new systems.

No off-the-shelf system can mimic all the peculiarities of the existing processes. As a result, re-creating old processes in the new system will invariably result in the need for extensive customisation.

The perils of this are illustrated by one public sector organisation that insisted on a ‘like-for-like’ replacement of a legacy system. An Auditor General’s report found that this was so problematic that excessive customisation of the product eroded its inherent benefits and further increased costs.

The solution to overcoming complexity is in clearly understanding the business strategies and goals the new system is trying to support. One way to do this is to lay out the capabilities the system needs to support and distinguish between what is required on day 1 of go-live and what is not.

More importantly, consider the capabilities (see graphic and list below) that are common across the business units and those that are not. Those capabilities that are unique to a business lie within the scope of the project but could be designed and implemented outside of the system.

Common core capabilities

These capabilities are most critical and need to be implemented in the system in order to make sure the system fully meets the business goals. These will include capabilities that are required to meet legislative and/or regulatory requirements.

Common non-core capabilities

These capabilities should generally be considered for future enhancements. However if they are to be implemented on day 1, they should be accompanied by a robust business case detailing the impact to the business if this change is not included.

Unique core capabilities

Every organisation will have specialised core capabilities that will be used only by certain business units. These could be “must have” capabilities that are required only in a given region, or country. It is often wise to support these capabilities independent of the main system, to avoid the considerable risk inherent in trying to build a system that will be all things to all people.

Read more: Avoiding project ambiguity

Unique non-core capabilities

These are nice-to-have processes that are neither business drivers nor required, e.g. a complex report that only one local office wants. These should be kept standard.

A large proportion of custom requests are likely to fall into this quadrant, but by strictly adhering to the standard, an organisation can significantly reduce the system’s complexity, and thus its total cost of ownership.

This approach of only implementing the core capabilities is similar to the minimum viable product (MVP) strategy used by many startups during product development.

A minimum viable product has just those core features that allow the product to be deployed, and no more. By keeping the system to just the critical features in the first instance, an organisation can significantly reduce program complexity.

What else needs to be done?

This framework described above for analysing business needs is only a first step in minimising complexity. To ensure success, CIOs must also do the following things.

Introduce strong governance

Every stakeholder requesting a change will claim that the capabilities his or her business unit needs are core to the business. Strong governance will help validate each claim and challenge it, if necessary.

One financial services firm policed the project scope by making sure all stakeholders signed off on it before going any further. Beyond this, the governance committee, comprising of CFO, CIO and other business executives had to approve all change requests.

Maintain the scope of a program

IT must put into effect measurable targets for both standardisation and customisation, along with business rules that discourage unique requests. These can be enforced through chargebacks, traffic lights and trend graphs to track the level of standardisation and customisation against the targets.

One way to avoid IT “black swans” is to break big projects into ones of limited size, complexity and duration and develop contingency plans to deal with unavoidable risks.

Convince business users

Getting buy-in from business users is imperative to making this framework work. To do so, IT must work closely with business to understand the nature of core process, the reason for implementing them within the system and to identify opportunities for simplification.

For non-core capabilities, a much more resolute stand should be adopted to drive home the value of standardisation to all end-users.

IT transformations are notoriously prone to failure and one of the root causes of this is complexity. The solution to complexity is developing a clear understanding of the business strategies and goals the new system is intended to support.

This is not easy but IT and other executives can work together to ensure the program’s scope is limited to just core the capabilities required on day 1 and deploying only those in the system to deliver value.

Everything else can be delivered as part of future enhancements or outside of the system.

Pankaj Chitkara is a management consultant at Strategy& in Melbourne.

Mark Johnson, a principal with Strategy& also contributed to this article.