Just as no military general would blindly charge into a theater of war without assessing battlefield assets, no IT leader should take on high-risk endeavors without a similar assessment of capabilities.
Capability Relevance Today
Sun-Tzu, the famous 6th century Chinese military general and strategist often wrote about the importance of capabilities in The Art of War:
“Know thyself, know thy enemy. A thousand battles, a thousand victories.”
Thorough understanding of one’s capabilities informs decision making. As a general, knowing of your opponent’s formidable air force may prompt an attack by sea with your superior naval force. Likewise, recognizing that your enemy wields a sophisticated infantry ten-times larger than yours may force you to avoid conflict altogether; as challenging such a fearsome foe would almost certainly result in defeat.
Similar to military generals, today’s business leaders must charge into large-scale theaters of engagement that are rife with uncertainty and risk. New markets to enter, risky projects to manage, and unpredictable investments to name a few. Yet managing the risks associated with such endeavors can become more pragmatic when capabilities are assessed beforehand.
Capabilities, Explained
On its own, a capability is something an organization does, irrespective of how it’s done. For example, a pizzeria has an ability to provide pizzas to the public. This broad capability could be broken down into sub-capabilities, such as (1) make pizzas, (2) sell pizzas, (3) be compliant with health standards, and so on. Whether the pizzeria is good or bad is the measurement aspect of capabilities. More on that later.
A capability measures an organization’s degree of ability to accomplish something. Put simply, enterprise capabilities are a way to both describe and quantify how well an organization does one thing or another. One can think of capabilities as being similar to “belts” in martial arts. Just as a single fighter may have a black belt in karate but only a blue belt in Jiu-Jitsu, an organization may be highly capable at software development, but lacking in terms of customer support.
Capabilities are often broad. In fact, enterprise capabilities are aggregate views of people, skills, technology, and processes. The idea is to represent a capability almost like a generic container (such as “customer support”) then have lower-level implementation details such as management hierarchies, tooling, and business processes align under said capability. The nice thing about capability mapping is defining and redefining the containers is an infrequent process. The underlying tools, processes, and other implementation details will change much more frequently.
Having described what capabilities are, here are some examples of what capabilities are not. As alluded to above, capabilities and a process are not synonymous. While one or more processes may support a capability, a capability is more about the “what” an organization does versus “how” it’s done. Additionally, capabilities are not functional hierarchies. In other words, a capability map is not some jazzed-up org chart. How an organization is organized– be it functional, flat, or matrix, is not the same as defining what things the organization actually does.
The Value of Capability Management
Capabilities aren’t simply data points that influence a rigid “go / no-go” style of decision making. Instead, capabilities help inform decision makers of the likelihood of success now, as well predictive future performance should a less-than-satisfactory capability be further matured. For example, consider a US-based clothing manufacturer pondering expansion into eastern Europe, where labor and privacy laws differ significantly from those in the United States. A lacking capability in European law could be so risky that the opportunity to expand should be avoided. Of course a more likely scenario would be to simply bolster legal capabilities by contracting with an external European legal counsel.
Of course, capabilities provide more than simple inputs to risk management decisions. Mapping organizational capabilities is a management discipline which applies measurement to key areas of corporate importance. Such discipline tends to instill faith over the more subjective means of evaluation.
Imagine a newly-hired CIO asking two of her direct reports to convey the maturity of the end-user services and business applications spaces. While the business applications leader hands the CIO a capability map of the CRM space with drill-downs into the application portfolio and views of cross-functional business processes, the end-user services leader responds with a subjective self-assessment via email. You can probably guess which leader is going to get some follow-up questions!
On a practical level, capabilities serve as a common, reusable vocabulary throughout the enterprise in that capability labels can be leveraged over and over for various activities. From a top-down perspective, capabilities can align nicely with strategic objectives with minimal managerial overhead. For instance, if the CEO states that improving customer support is a top initiative, then touting CRM as a priority capability is a summarized way of referring to CRM tools, processes, staff, and so forth. From a more bottom-up perspective, it’s not uncommon to see investments, projects, applications, and other operational minutia mapped into capability areas.
Measuring Capabilities
There are are no hard-and-fast rules for measuring capabilities. Yet ordinal-style scales of the “red/yellow/green” variety are common. Perhaps one of the most frequently-used ordinal scales is the capability maturity model integration, or CMMI, which has five levels: “initial, managed, defined, quantitatively managed, and optimizing.” If such as scale is a little dry and thus difficult to remember, here’s a handy mnemonic: Inevitably, management demands quantifiable output.
As with other areas of enterprise architecture, capabilities can be measured in terms of today’s capabilities or from a more aspirational angle by focusing on tomorrow’s “to-be” capabilities. What’s really interesting is overlaying the two in order to convey a gap analysis:
As shown in the image above, the IT leadership feels as though it has a good handle on security, data management, and end-user services. On the other hand: general management, core infrastructure management, architecture, and applications management all need to improve in the coming cycle(s).
Practical Example
As a fictitious example, imagine an IT department who sets forth on an effort to map out organizational capabilities; both in terms of current and future state. A simple spreadsheet will serve as the starting point:
The capabilities are hierarchical in that there is one “root” capability (Core IT Capability) and seven top-level (level-1) capabilities: Architecture, security, Core Infrastructure Management, End User Services, Applications Management, Data Management and General Management.
Under each of those level-1 capabilities are 5-9 level-2 capabilities that are a bit more descriptive. Note, however, that while the level-2 capabilities are a bit more detailed, they are still capabilities. Anything more detailed would go into a “level-3 realm” which would probably start getting into the “how” side of the house. I’m referring to business processes, tools and technology, and other areas that should not be incorporated directly into the capability map. Although some of the more sophisticated enterprise architecture tooling can link these two worlds, let’s keep them separate for now.
Once capabilities are scored, they can be visualized in numerous ways. There’s the as-is versus to-be gap analysis shown above, and here is an as-is view of current capabilities, grouped in treemap fashion:
With just a quick glance, one can surmise from the red “hot spots” that applications management, general management, and core infrastructure management are areas in need of improvement.
Summary
Capability maps are a low-effort, high-impact artifact that quickly articulate the state of organizational ability. They can be used in both top-down and bottom-up activities, and serve as a methodical management tool for facilitating data-driven decision making.
