Architecting Value

Capability Levels: An Enterprise Perspective

Building an enterprise capability model can be challenging, but using accelerators like APQC, it's possibile to come up with a reasonable straw model quite quickly. The intent of this post is to provide what I've learned about building out the model at the enterprise level. I will complement this post with one tomorrow about how capability models should look at the line-of-business level.

For Level 1 capabilities), I think that using the APQC description of levels works just fine. Level 1 is an organizing structure and are not capabilities unto themselves. The purpose of L1 is to give your fellow architects an easy way to find the capabilities that they're looking for.

Level 2 capabilities, in my view, are also organizing structures and not capabilities. They provide much greater precision than the L1 but can also generally be used to communicate with high level executives.

At L2 is also when your design choices begin to matter. The APQC - which is more of a process model - creates several layers of organization and classification. In this example, they've created a level for "3.3 Develop Sales Strategy." I don't find this abstraction particularly useful especially given how specific the L3 capabilities are such as 3.3.1 Develop Sales Forecast. Develop Sales Forecast provides far more clarity - I would dispense altogether with Develop Sales Strategy and make Develop Sales Forecast and its siblings my L2 capabilities. By removing the original 3.3, we're flattening the hierarchy so that we can enable a more modular taxonomy of L3 capabilities. (More on that tomorrow).

One note on how you define and place your capabilities. Generally, the L1 models follow function, i.e. R&D, Marketing, Sales, etc. Don't confuse the functions with the organizations that you may be supporting. For example, our sales people are involved in getting agreements signed and managed. We have a capability to manage that called "Agreement Management." Although this is a capability that's needed in the sales organization, we don't classify it for the purposes of the model in the Sales capabilities. Instead, we group Agreement Management with other like capabilities - in the Legal capability grouping. This makes the capability easier to find for other architects and also ensures that we're not duplicating capability taxonomy in our framework.

I think that the right number of capabilities for an enterprise (at L3) is between 500-700 capabilities. This provides enough precision without having a taxonomy that is too unwieldy to steward and manage. L3 is usually a capability - that is, a business outcome unconstrained by how it's implemented by people, process, information, or technology. The APQC ones (L4 in their model) are generally written to sound more like processes.

Five Principles for Constructing Your Capability Framework

Developing a capability framework is more art than science. The framework will serve as a way to view and understand your enterprise or line of business. As a result, it will need to have some stability over time. If the capabilities are constantly changing, it will be difficult to understand and track changes in the architecture over time. The framework should also, hopefully, resonate with your stakeholders. If it doesn't, you will spend a lot of time translating what the capabilities in the framework mean. Since this is a design exercise, I've found it helpful to use these and other principles to guide the design.

1. The capability taxonomy should be stable over time. Improving understanding of the business requires a stable view of the business. Constant shifts in taxonomy will cause churn that will obscure understanding. Capabilities should therefore be defined in language that is independent of their implementation since the implementation may change. In other words, you might choose "budget review" over "quarterly budget review" since the frequency of the review may change but the essential aspect of the capability - the review of the budget does not.
2. Capabilities should be expressed in language that resonates across business areas. It is perhaps obvious that when capabilities don't resonate with the stakeholder, it reduces the credibility of the architect or causes a significant amount of translation. This problem is magnified when there are multiple lines of business that need to be supported and there isn't a common language between them. The capability framework can be used to drive consistency but it probably won't happen overnight. In general, seek a common taxonomy and translate where that's not possible. Don't create separate capabilities in your framework for each line of business that refer to the same outcome. 
3. Capabilities should be constructed in flat hierarchies. When designing a capability framework, it's important to distinguish between the actual capability and the organizing structure for the capability, especially when designing a framework that serves the enterprise or multiple lines of business. In general, we want the value to be in understanding the capability, not the organizing structure. Level 1 (L1) and 2 (L2)capabilities aren't actually capabilities - they're really just organizing structures. These may or may not resonate with your stakeholders depending on the scope of your framework. (In general, enterprise-scale L1s and L2s won't unless there is broad enterprise agreement on the taxonomy). Capabilities usually define business outcomes at  Level 3 (L3) and Level 4 (L4). The idea is to have absolute consistency at the L3 and L4 while making L1 and L2 flexible to accomodate different business organizing structures. (More on this in a later post).
4. Information-centric, not activity-centric. In a later post, I will discuss in more detail my view that information is really at the core of a company's value proposition. That said, I think that capabilities should be grouped based on the information that they're addressing as opposed to the activity. For example, this would mean that a "sales reporting" capability would be grouped with other sales-related capabilities, as oppsoed to being grouped with a reporting capability. (In this example, you may still have a generic reporting capability that sits outside of other information-centered capabilities).
5. Capabilities should be defined at the same level of granularity. This is mostly judgement but its helpful to try and keep capabilities at the same general level of abstraction for consistency. It resolves confusion and churn resulting from having different architects working at different levels of detail. The framework is especially helpful for enabling comparisons across multiple lines of business - the lower level of detail tends to only be relevant to specific lines of business. 

Where to Get Capability Frameworks

I originally meant to follow up my last post on the use of capabilities with an example of what a capability framework would look like. One of the challenges is that I don't have a ready source for enterprise-scale frameworks.

Microsoft Services has a strategic offering in which our consultants will leverage a number of generic industry models that we've developed over the past 10 years or so. I've developed a number from studying marketing material and white papers from technology consulting firms.

One excellent starting point is APQC. APQC is an organization that specializes in benchmarking studies and research. To facilitate industry and cross-industry comparisons, APQC leverages a process taxonomy developed by IBM. In addition to a generic process framework, there are also a dozen or so industry-specific frameworks, that are detailed down to a L3 or L4 level. Even if your industry isn't covered by one of the models, there's enough material for you to get started with so that you're not re-inventing too much. It's definitely an accelerator to your capability model development.

 

Beware of Watermelons

Microsoft is a company that heavily leverages scorecards for managing performance. Our CIO's scorecard has nearly 100 separate metrics that are used to evaluate his performance - indicated by green, yellow, or red.  Recently, he cautioned us about scorecard "watermelons," that is, items that appear green on the scorecard but are actually significantly underperforming and should be red. This happens when the scorecard fails to capture the right measure.

 

I recently had a "watermelon" experience that should be a standard risk to look out for on business architecture engagements, especially if you suspect that the organization is not strategically mature. I had an executive sponsor insist that we conduct an engagement for his organization as they were undergoing a major strategic shift. He made available some of his managers who committed nearly 20% of their time to helping us create the strategy deliverables.

 

This engagement appeared green on our scorecard since we had executive sponsorship, commitment from the client, and were making progress on the deliverables. The only problem was that the people we were working with didn't really know what the strategy was. The executives had kept the strategy close to the vest and the managers we were working with were taking their best guess.

 

This internal disconnect with the client wasn't discovered until the end of the engagement when the SOAP was presented for validation. The executives were expecting something that articulated their transformational strategy and instead something that showed incremental improvements. We were green when it came to the engagement but bright red when it came to the actual content .

 

It was a terrific lesson - I had allowed the fact that I had engagement from the client obscure the fact that I didn't have the right level of engagement. In retrospect, I should have structured more frequent and earlier reviews with the sponsor to ensure that we were going in the right direction. The deliverables that I'm prescribing are primarily listening devices - they should be used often to validate whether you are on the right track to avoid watermelons.

Using SOAPs to Gauge Strategic Maturity

Many people who work in IT organizations labor under the assumption that their business clients have a clear understanding of their strategy - it is simply waiting on a shelf for someone to ask for it. The reality, of course, is that maturity varies from truly visionary organizations to the constant fire drill teams. I've found that the development of the SOAP can be a good indicator of my clients' strategic maturity which is why the process is just as important as the end deliverable.

 

For an organization that is mature in it's strategic discipline, the SOAP is a painless exercise. They can articulate their vision and mission; they have clear understanding of their priorities and the outcomes they're driving and the actions they need to take to get there. This is - at most - a 2-3 hour workshop with a week to tweak over email and perhaps a follow-on meeting for validation.

 

Immature organizations struggle with SOAPs. They may question the value of the activity, since the organization's strategy should already be obvious to everyone who's involved. Their strategic priorities will read like motherhood and apple pie -  "Beat the competition," "Grow Revenue" and "Satisfy Customers."  I had a client once that even articulated that their strategic priority was to "Win Everywhere."

 

(A priority should be more specific and actionable. A simple test I use is to ask myself - if I were a general (or a VP), could I use the priority  to answer credibly what my strategy is? Example: "General, what is your strategy to win the battle?" "My strategy is to 'Win Everywhere.'")

 

A key indicator of low strategic maturity can be gleaned from how the SOAPs are constructed. If the construction is generally top-down, the maturity is tends to be higher than when the activity is bottom-up. Low maturity organizations will begin with a focus on the imperatives which amounts to documenting their current and near-term initiatives. They will then articulate priorities by categorizing the imperatives.

An organization with a strong understanding of its strategy, however, does not need to categorize imperatives to identify priorities. It can easily define the priorities and organize imperatives which fit the priority.

 

Knowing the strategic maturity of the organization won't directly benefit the organization - it's really helpful for you to know how to handle the organization throughout the engagement. The value of the work will be obvious to the strategically mature organization; you will spend much more time explaining the value to organizations that are less mature. Managing those expectations will be critical to your success. 

 

The Strategy on a Page

 The purpose of a business strategy is  to set direction and priorities of an organization. It is the job of the business architect to understand, interpret, and articulate the strategy so that it can be operationalized. I've mentioned earlier that I do not think it is the role of the business architect to develop the business strategy.

I've had strong success with business executives using a tool to concisely describe the elements of their strategy in a single page (depicted below). This strategy-on-a-page (SOAP) serves as a useful listening device for interpreting the strategy and communicating it to other stakeholders.  Since I introduced the format to Microsoft a year ago, it has gained broad adoption across business and IT for articulating the business strategy. 

The SOAP is tightly aligned to the elements of strategy that I described earlier. It begins with a statement of the organization's vision. This is usually an aspirational statement of ultimate end state for the organization. I've also used it to describe 3-5  year  visions, especially when the organization is about to engage in a major transformation.

 

The second component is a statement of the organization's mission. This is a description of what the organization does. Most organizations have one handy so it's fairly easy to cut-and-paste into the SOAP. One of the purposes of this deliverable is to help determine if there are alignment issues within the strategy. The description of the mission should align with the vision - if it doesn't that is a good opportunity to  have a discussion around that disconnect.

 

Priorities represent the 4-6 major things that the organization will focus on to achieve it's vision over the next 36-60 months. I explain to my clients that these are their strategy's "big rocks." I've heard these also referred to as "themes" or "pillars." Whatever you call it,  try to make them as specific as possible -  many businesses, especially those that are run bottom up, will use priorities as classification buckets for the imperatives underneath - this causes them to use simple words to describe the priorities rather than full statements.

 

Imperatives are the key set of actions that the organization will undertake in order to realize it's 3-year vision. These should be operational rather than aspirational. Generally, these things are well-understood but be sure to confirm that they are not short-term 12 month actions.

 

Outcomes and measures are a description of the desired outcomes and how they are measured. Although it is nice to be able to tie them to each priority, in some cases, the outcomes will cross multiple priorities. It should be noted that you are documenting specific business outcomes, not actions, i.e. the outcome might be described as the number of new customers acquired as opposed to the deployment of a particular system (which enables the customer acquisition).

 

I've had good traction with the SOAPs since I introduced them to Microsoft IT. This format is used by all MSIT business architects to describe their business strategies. Tony Scott, our CIO, has declared in meetings with our business clients that he "loves SOAPs" as they provide him with an easy way to talk about business strategy with his stakeholders. We've found that a number of our business clients are using the SOAPs as an easy tool to talk about their business strategy. On the IT side, our solution managers are using them to anchor discussions about priorities, i.e. "Should we do this? It doesn't map to the SOAP for the business." A VP for another business division seized on the format and mandated that each of his directs produce one. If you decide to use this format, I'd love to hear back about how well it works for your company.

Getting to Value

 

In my previous post, I mentioned that I see the business architecture as the primary bridge between strategy and operational execution. The primary function of the business architect is to translate the strategy into a plan for investments over time. This is not to suggest that there aren't other roles for the business architect to play in solution planning and design but this first function is where the business architect delivers the most value.

The figure above provides a high level view of the five phases of business architecture engagements. I use this graphic to explain the engagement to my clients . It is a simplistic depiction - the actual engagement is far from linear - but it does serve as a good communication tool for helping the clients understand the analytical approach.

 

The first phase is strategy articulation. I've said before that the role of the business architect is not to define the business strategy but to articulate it in a way that it can be easily consumed. Assuming the business is mature about their strategy, this is not a difficult exercise and can be done quickly.

 

The second phase is defining the capabilities that enable the strategy. It is helpful if you already have a map of capabilities for the business (more on this in a later post). If it exists, then it's a matter of reviewing existing capabilities to determine which are impacted. If not, it's a matter of defining what new capabilities are needed in order to enable the strategy.

 

Phase three is the assessment of the capability. This is sometimes confused with capability definition and the two activities are related but are distinct. The goal of this phase is to evaluate each existing capability to determine how well it can support the strategy. This is also where dependencies between capabilities are identified. There are multiple ways to assess the capability: heuristics, benchmarking, and more - much depends on the engagement  and I'll address this in several posts to come.

 

The fourth phase is analysis and prioritization of the capabilities. This is time spent understanding the data that has been accumulated and searching for insights or gaps that require further analysis. This is also where you align strategic-level priorities with operational-level priorities.

 

Finally, the sum of all the steps above lead to a prescriptive plan and ordering  of activities and investment - a roadmap - of how to deliver the capabilities to the desired level of performance in order to enable the strategy.