[tl;dr The first step to managing complexity is to define what is important. Principles are a great way to reach consensus on what is important, and establishing governance around adherence to those principles are the first step to getting on top of change-related complexity.]
Managing complexity is not easy, whether you are in a large organisation, or in a relatively green-field environment where growth is rapid and complexity is a far-off problem you hope to have some day…
The fact is, if your organisation suffers from a complexity problem (in technology, and implicitly, processes and data), and you are still in (a profitable) business, then it is that complexity which, for better or for worse, has been the instrument of that organisation’s success. As a consequence, it is quite hard to convince people to implement complexity management (read ‘enterprise architecture’) before complexity actually becomes a problem.
Sometimes, however, unmanaged complexity brings an organisation’s growth to a grinding halt, in the worst cases leading to eventual shutdown. (In this context, an organisation can be an independent business or a business unit within a larger company.)
Historically, investment in IT incurred large capital costs, so usually there was a large focus on realising value from that investment – i.e. to exploit it to the maximum. Exploiting technology usually means adding on more and more functionality to existing systems in ways that meet business imperatives. But business imperatives tend to be fairly short-term in nature. Without guiding principles, the act of exploiting technology leads to ever more expensive change-related costs.
For any self-respecting IT organisation, a core set of principles, actively governed, is an absolute necessity. Principles transcend solution architectures and technologies, and enable project autonomy as decisions can be made locally without requiring ‘central’ approval, provided principles are being adhered to.
Such principles, call them ‘implementation principles’ should guide how IT organisations do their work and manage change.
But many principles that stay only within the IT organisation may break in the face of over-whelming business imperatives: on the basis that the (immediate) business needs comes first, IT often takes it on the chin and accumulates technical debt.
So it is important to agree principles that business stakeholders agree to and supports, and for which they are willing to have an open discussion about in the context of delaying projects, increasing costs, prioritising change, or driving organisational change.
Let’s call these principles ‘value principles’ – they are focused on how the business can realise value from its investments, particularly in IT.
In order to understand what this means in practice, it may be worth returning to the ‘Zero CapEx IT’ concept introduced in my last post. What if all IT was sourced through (virtual or actual) 3rd parties, so that all of IT was delivered as software-as-a-service?
In this case, the ‘implementation principles’ would be whatever guidelines or standards were used by the SaaS provider to ensure they could deliver change reliably, and maintain service according to agreed levels. The SaaS provider has a vested interest in the client getting value out of their service, but the only levers they have to ensure that is their ability to react in a timely manner to change requests.
From the business’ perspective, adopting an IT (SaaS) service requires structural change to ensure the business can take advantage of the technology. This may mean assigning roles and responsibilities, defining new activities, maybe creating whole new departments, etc. The business may be paying for the service, but unless it pro-actively maximises what the service can offer in terms of what the business needs, it may not get the value. The SaaS (i.e., IT) can do little to address this situation, and may end up losing the client if the client does not take action.
On the other hand, if a client is pro-actively engaged, then they will likely want regular changes so they can continually optimise the value of the service to their operations. This puts the onus on the provider to remain agile.
In a corporate environment, where the accountability between value and implementation is often blurred, there is usually little optionality with respect to who your provider is – or, from a provider perspective, who your client is. In fact, the client/provider perspective in a corporate environment can be damaging, as it can reinforce an us-vs-them culture, leading to mistrust and an ‘order-taking’ mentality developing between the client and the provider.
In this environment, complexity will thrive because, after all, the client is tied and therefore has to keep paying for their service. There is little incentive to be agile..if the client wants more quicker, they have to pay for it.
If, on the other hand, the client retains an active, supportive interest in how their IT is delivered, as well as what is delivered, then they will get the IT they want.
If the client is not willing to agree certain base-line principles with their (IT) provider, and to put in place structures to enforce them (including a formal waiver process), then one can expect little to improve.
On the other hand, if the client or business partner will willingly participate in establishing principles and related governance forums, this will set the tone for how the business/IT relationship will evolve going forward.
At the very least, ‘value principles’ (such as, for example, “The business will commit to implementing the necessary structural changes to maximise IT investment”) should be agreed, and the consequence/implications of these to project planning should be understood.
Note that value principles are increasingly including concepts around data governance, which historically have been an ‘implementation’ principle – for example, the principle that ‘information is an asset’.
‘Implementation principles’ are principles which determine how (IT) change is decided and implemented, and how complexity is managed, by the provider. Where the business and technology are inter-twined (i.e., the business value proposition *is* the technology), these would simply form part of the business ‘value principles’. But where the business is agnostic as to the technology, and are only focused on value, then the ‘implementation principles’ are solely for the provider to define and enforce. An example of an ‘implementation’ principle may be ‘Control of technical diversity’, with consequent implications for solution architectures.
Adopting principles means that an organisation has some sense of what it wants to be, even if only aspirationally. It allows individuals or teams to feel comfortable making decisions on their own without feeling they have to get approval, which is key for agile cultures. Establishing formal business+IT forums to review principle waivers helps provide transparency with respect to project risk and platform risk. And it allows Technical Debt to be managed, as every waiver is a recognition of technical debt incurred.
In conclusion, managing complexity is hard. But Principles can make it manageable.