The posts on this blog have mentioned capabilities quite often. I thought we'd dive into the relationship between capabilities and projects for a moment. Here we go...

Can a project embody a single capability at a time? Yes. Can a project deliver multiple capabilities at the same time? Yes. Can multiple projects deliver a single capability? Yes.
Is there a preferred relationship of projects to capabilities? Yes, there probably is -- and the relationship most relevant to your corporate planning culture is likely different than the relationship most relevant to anyone else’s corporate planning culture. We are at the beginning of our understanding of business capability-based project planning. There are no ‘best practices’ as of this writing.

But still, why are there so many possible project-to-capability combinations? The reason is that different layers of capabilities represent different layers of granularity. The closer you move toward the technology layers, the more granular the layer becomes. As the granularity
approaches the typical project granularity in your organization the more comfortable you will be in seeing the capability as a project candidate.
A sample process that determines project-to-capability relationships should work something like this: First perform the capability identification and analysis; that is, identify the high level capabilities and then perform the decomposition. After you have two or three levels of capabilities and their dependencies see if you understand their value to the business. Value as well as dependencies determines build order. After that, see if the capability granularity makes sense to turn the capabilities into projects. Here is a quick view of the same:

Figure 1 – Quick Path Capability Identification Process

Some people will have trouble separating the abstraction for capabilities useful in planning from the exercise of identifying capabilities for projects. But good governance practices such as separation of duties can help. Separate the analysis from the project identification phases and let different roles address those steps.

If you’re having difficulty breaking capabilities into projects, the capabilities you’ve identified are either too broad or too granular for your corporate planning culture. Try rolling them up or decomposing them further for better results. Organizations that employ capability-based project planning will find that they develop new terminology around projects. Communicating the value of your projects will become easier. Capability-based projects will be in the language of your domain because capabilities are already in your domain’s language.

For more information download the white paper: Will the Capability Revolution Cause Project Evolution? (July 2009).