Clarity of organisation is particularly important for IT leaders today as IT management and operational roles are increasingly dispersing throughout the business, rather than being performed within a homogeneous IT organisation.
There are many analogies for illuminating what is meant by, and the importance of Organisational Clarity. One that works particularly well is rowing boat racing. When all the rowers are in perfect harmony and staying on course, there is enormous power in the boat. If the coxswain screws up, or any of the rowers don’t follow the instructions, havoc reigns and the boat slows down or goes way off course. IT organisations that lack Organisational Clarity become that slow boat or, even worse, the fast boat heading in the wrong direction!
Common Symptoms Reveal Lack of Organisational Clarity
The symptoms of a lack of Organisational Clarity are common and prevalent. How often do you or your colleagues say or hear:
- “We don’t communicate well”, equally I don’t think I’ve ever seen an IT organisation that claims “We communicate really well”. This is a non-trivial symptom. It leads to redundant work, leakage of business value (ie, value that should have been captured or could have been captured, but is not captured) and a general sense of confusion and disorientation. For the beneficiaries of IT work, it contributes to a poor customer experience – “The left hand doesn’t know what the right hand is doing!”
- “We don’t have clear accountability” This is another common symptom – failure to be clear on who is accountable for what and, more to the point, what happens when something goes wrong. This is often (and unfortunately) referred to as, “Not knowing whose throat to choke”, but is probably more constructively thought of as, “Not knowing what actions to take to ensure that this error is never repeated”. This symptom also means that managers and individual performers often do not understand how their work contributes to the overall mission and vision for the IT organisation, and, more importantly, how it contributes to the success of their internal and external customers.
- “We exist to support the business” This common misunderstanding leads to the ‘order taker’ mentality, and an IT organisation that is always extremely busy (to the point of rampant overwork) and yet is seen by the business as adding little to no value.
Don’t Attempt to Address the Symptoms Directly!
It is essential to recognise that these are symptoms and not root causes in themselves. You cannot solve the communications issue by mandating or even organising for better communications. I’ve lost count of the number of IT leadership teams I’ve worked with who talk about putting a marketing/communications specialist on their staff “to address the communications problems”. I’m not saying this is necessarily a bad idea, but adding such a role with the purpose of ‘fixing communications’ rarely, if ever, works. Communications problems are symptomatic of a lack of Organisational Clarity – not just for the IT organisation as a whole, but for its ‘moving parts’ such as IT infrastructure, enterprise architecture, solutions delivery and so on.
Similarly, you cannot address the accountability issue by simply trying to mandate accountability. Unless a given IT Capability has clear goals, service definition and guiding principles, and the appropriate processes, roles, competencies, tools and technologies are in place, it’s little use trying to tie accountability to anything!
The ultimate gauge of IT Organisational Clarity is in the ‘health’ of the IT organisation and the business results to which it contributes. However, there are all sorts of demand-side complexities in assessing these things, so for now I will focus on the notion of capability maturity as a worthy proxy for and predictor of end results and the ability to continuously improve.
Two Dimensions of Organisational Clarity
Improving Organisational Clarity – and in turn increasing focus and effectiveness – must be tackled along two dimensions:
- Bounding scope appropriately, or defining the ‘unit of analysis.’ An appropriate unit of analysis is commonly referred to as ‘an IT Capability’. Typical IT organisations can be described through 7-9 capabilities, such as IT infrastructure, enterprise architecture, opportunity discovery, solution delivery, portfolio management and so on.
- Defining capability characteristics, including purpose, commitment, ability and accountability.
What Is An IT Capability?
In order to adequately define an IT Capability, we need to clarify a couple of common terms – Service and Process:
- A Service in the context of IT Capabilities is best described as the interface point between a provider and a consumer where value is exchanged. Services should be defined from the perspective of the consumer. They need to be ‘discoverable’ and the service interface understood by the consumer. They need to have clarity on what they do, what they cost, how they are invoked, and how problems are reported and resolved. The service provider should have a good understanding of the value received by the consumer, as well as the overall quality of the customer experience. This may comprise both tangible and intangible elements, most of which are ultimately subjective.
- A Process is a sequence of interdependent and linked procedures which, at every stage, consume one or more resources (employee time, energy, money) to convert inputs (data, material, etc) into outputs. These outputs often serve as inputs for the next stage until a known goal or outcome is reached.
A Capability can therefore be thought of as everything that takes place behind the scenes to make a Service possible. This will include:
- One or more Processes.
- Descriptions of the roles needed to perform one or more of the procedures within a Process (eg, Project Manager, Business Analyst, Relationship Manager).
- Descriptions of the competencies needed to perform a given role: what the person performing the role needs to know (eg business knowledge); what skills they need (eg facilitation); and what behaviours they should exhibit (eg results orientation).
- An adequate supply of competent human resources filling the given roles.
- Tools and technologies needed to automate or execute necessary processes or procedures.
- Management systems necessary to ensure the health and performance of the Capability, including funding, organisational will, personal incentives, and so on.
How Many IT Capabilities Should You Have?
This is a tricky question to answer. First, of course, it depends on the mission to be served by a given capability. But, more importantly, this is a question of granularity. In the heady days of business process re-engineering I learned that picking the right granularity for an end-to-end process is crucial and perhaps as much art as science.
I think this question has more to do with the characteristics of and limitations to the workings of the human mind than anything else. If you end up with, say, 3 IT Capabilities, chances are that you are at too high a level of granularity to be really useful in terms of analytical and management discipline. On the other hand, if you have 12 or more IT Capabilities, you are at too low a level. From my experience, between 7 and 9 is the right number of IT Capabilities to have in a ‘top-level’ IT Capability model.
How Many Levels of Decomposition Should You Go To?
Yes – you guessed it – it depends! On the basis that you really don’t understand a Capability unless you can see a level of decomposition below it, I think the answer is at least two levels of decomposition are necessary. Beyond that, it depends on the Capability you are trying to understand or improve. Consider, for example, the Process aspect of an IT Capability. Capabilities that are highly procedural, such as those found in IT infrastructure and operations, will typically need more levels of decomposition (ie, more detailed process definitions). Coincidentally, this is the domain of ITILv3, so you can effectively ‘buy’ process definitions and a process architecture off-the-shelf.
On the other hand, a Capability such as Opportunity Discovery may be more about analytical skills and the magical space between problem understanding and solution definition. This space is much more about specially skilled people and specific business domain knowledge rather than sequential, detailed and rigorously controlled processes (as in Statistical Process Control).
Not All IT Capabilities Are Born Equal
It is helpful to classify IT Capabilities into one of three different types, as illustrated in the graphic below.
Value Chain Capabilities
At the core are those capabilities that take inputs, add value and deliver outputs to a customer or end consumer (in the world of IT, these tend to be services and products). Think of these Value Chain Capabilities as those that the end customer appreciates (hopefully!) and is willing to pay money for.
For example, as a business user, I may have a business problem I’d like IT help to solve. That problem (or opportunity) is the input to a value chain. The first capability that will approach that problem adds value by analysing the problem, identifying and proposing a solution. As the business user, I appreciate that value has been added – drilling into my stated problem and offering (and perhaps demonstrating via a prototype) one or more proposed solutions. The next capability in the value chain might take the chosen solution and develop and deploy that solution. Again, as the business user, value has been clearly added – taking a proposed solution and delivering it. The final capability where value can be added is supporting and maintaining that solution – again, a recognisable way of adding value for me, the customer.
Ultimately, as the business user or consumer, these are the only capabilities I care about and am willing to pay for (directly or indirectly) because of the value they add for me. Unfortunately, while these Value Chain Capabilities are necessary, they are not sufficient.
Value Chain Capabilities typically draw upon other capabilities that enable them. Think of these as shared services that are common to other capabilities, or to other instances of problems/solutions working their way through the value chain. Examples of IT services that might enable the Value Chain Capabilities include project management, IT operations and IT supply.
Alignment and Governance Capabilities
Value Chain Capabilities also typically depend upon other capabilities that ensure that the work they are doing is aligned and governed to ensure they are operating effectively and in the interests of the enterprise. For example, determining which business problems will be addressed, which solutions will be selected, and how staff and resources will be allocated are all important controls that Value Chain Capabilities will be subject to.
These Distinctions Matter To IT Organisational Clarity
The distinctions between Value Chain, Enabling, and Alignment and Governance Capabilities are significant:
- Different types of IT Capability tend to be optimised towards different value propositions, with implications for how they are organised. For example, Enabling Capabilities tend to be optimised for operational excellence (as shared services, they need to deliver predictable, consistent, quality services at the lowest possible cost). Value Chain Capabilities tend to be organised for customer intimacy, delivering what specific customers want; anticipating customer needs. Alignment and Governance Capabilities tend to be more about decision-making – rather than delivering services, they make decisions or provide decision-making frameworks – think enterprise architecture and the mechanisms and structures that support it as Alignment and Governance Capabilities. As such, these tend to be networked, linking stakeholders and decision makers, and optimised to maximise the business value delivered or enabled by IT investments.
- Some types of IT Capability lend themselves to alternate sourcing more than others. For example, Aligning and Governance Capabilities lend themselves the least to straight outsourcing approaches (do you want to pass decision rights to an external vendor?).
- Different types of IT Capability lend themselves to different funding models. For example, Value Chain Capabilities lend themselves to direct business funding, whereas Enabling Capabilities lend themselves better to indirect funding models (eg overhead charge).
IT Capability Model Example
As an illustration, below is a ‘normative’ IT Capability Model.
As you decompose any IT Capability, you will generally find that the decompositions will have a similar structure – a primary value chain, drawing upon underlying Enabling Capabilities and influenced by Alignment and Governance Capabilities.
I welcome your thoughts.