Capability Maps (conclusion)

In my previous two blog posts I have described the salient attributes of a capability map, and given some reasoning for developing one. I also provided a fleshed-out example of a capability map for HalenessHC, my fictional company in the healthcare industry. In this post I will use the capability map provided in my previous post, round out the information and describe:

• What future changes might look like.
• Differences between the PCFs and the example capability map.
• Some possible uses of the capability map.
• Capability composition and relationships.
• The small wins a capability map provides.

A Going Concern

The first thing you should notice is that the capability map describes (to borrow an accounting term) a going concern - a self-sustaining and self-governing enterprise with all resources needed to operate indefinitely. Everything from employee engagement to bookkeeping, product ideation to customer service and enterprise strategy is included. The capability map is not constrained to product development, and it is certainly not constrained to IT.

Lesson: Your capability map is a Business Capability Map.

Possible Changes

Capability maps can change as an enterprise's strategy changes. For instance, you might notice that there is no capability that addresses international operations. In this example, I decided that my fictional company did not source from or sell into global markets. For this reason, I purposefully excluded those capabilities that dealt with things like global trade, exchange rates and localization.

If my fictional company changes its strategy and wants to enter global markets, these (and other) capabilities would need to be added. All other capabilities will remain untouched. Compare that to other lenses. To support an international business, the organization might change pretty drastically, as might the product line.

Lesson: Capability maps are stable, not immutable.

Differences From the PCFs

The APQC PCFs provide a great source of information, and they should be used as a base for your capability map. They are not something that should be taken word for word. The operational capabilities are a great example of this. While the general structure remains, I modified the operational capabilities of my fictional company so they are specific to the company and the industry it is in.

Further examination also shows that I have relocated enterprise vision and strategy capabilities to a supporting capability. With all due respect to the APQC and the consortia of industries they worked with to develop the PCFs, enterprise vision, strategy and capability management are closely related, and they do not have day-to-day operational activities tied to product delivery. They just don't belong as an operational capability.

Lesson: Use the PCFs as a guide, and make sure your capability map describes your business's view of the world.

How to Use a Capability Map

It will considerably help your capability map integration if you can identify a preliminary use-case for the capability map, and demonstrate how it can help. For instance, if your enterprise manages project costs across products or product lines but budgets are created organizationally (perhaps for each VP) there could be a disconnect between project costs and budgeted assets. This makes budget analysis and planning efforts difficult. Aligning projects and budgets to capabilities will make the relationship between budgets and effort more clear.

Lesson: Identify a use-case for your capability map.

Other uses take advantage of the relationships capabilities have. The UML class diagram below shows capability makeup and relationships that can be leveraged to enhance the product lifecycle.

I have already talked about the top portion of this diagram - capabilities form a containment relationship, and they are affected by people (Worker), processes (Process) and things (Asset). People (Worker) perform processes (Process) using tools and/or job aids (Asset), and by virtue of those relationships, tools or job aids support the processes.

An assumption of this model is that all Assets are configuration items. To paraphrase ITIL, a configuration item (CI) is a component of a system that is or will be under configuration management. The component can be infrastructure (server, router, storage, etc…) or a system software component. A CI can also be a collection of other CIs. While it is not true that all assets used to deliver a capability are CIs, it is a good simplification for our purposes.

Establishing assets as CIs highlights the ability to leverage a configuration management (CM) system to align CIs with a capability or capabilities. Linking capabilities to CIs allows us to understand the software and infrastructure used to support the capability. Linking capabilities to business processes and worker roles allows for easy impact analysis.

• If a CI fails (e.g., server down), what capabilities are affected? What business services? What user roles? Does the CI support an operational capability that requires immediate attention?
• If a project (e.g., software or infrastructure upgrade) impacts a CI, what are the potential impacts across the business? Which business owners should be informed?

Answering these questions requires collecting additional data points (Attributes). The attributes might include things such as:

• The CI's business champion,
• A criticality score,
• The supporting IT group and
• Version and/or release information.

You can probably identify more information that could be useful.

Linking and storing this information can be accomplished in a simple spreadsheet though larger organizations might want to leverage a CM tool. In either case, data collection and maintenance is vital. Missing or stale information in your spreadsheet or CM database (CMDB) defeats any of the analysis identified above. Garbage in, garbage out.

Lesson: Leverage capability composition, and create and maintain a CMDB to extend your capability map's usefulness.

Small Wins

Developing and deploying a capability map creates a number of small wins. All of these are achievable using tools and information you have today (without a specific mandate). The small wins include:

• Establishing a stable view of your business and a lexicon that describes it.
• Supporting consistent planning and reporting efforts.
• Creating a framework to assess the impacts of change or failures.
• Providing a basis for disaster recovery (DR) planning.

With some buy-in from leadership, I have also used capabilities to organize large projects. There are many other uses for the capability map. I will refer back to it frequently.

Next Blog Topic: Current State Structure Models

Happy Engineering!