A Pragmatic Approach to Capability Modeling
The discipline of architecture is supported by many frameworks, certifications, tools and guidance to help shape and consolidate our thinking. As a result, we often encounter conflicting approaches and methods: strategic planning, portfolio prioritization, enterprise architecture, business architecture, etc. Sharing experiences goes a long way to rationalize – in fact, if you haven’t had a chance, I suggest checking out Architecture Center as an online resource for further discussion.
On that note, I had the opportunity to discuss a recent project executed in Calgary by Jason McIntyre where he leveraged an interesting technique called Capability Modeling. I first encountered this technique a few years ago attending a talk by Microsoft’s Ric Merrifield. Since then, Ric and colleagues have evolved their approach and recently published an article in the Harvard Business Review.
This post, presented in question (Craig) and answer (Jason) form, will introduce you Capability Modeling (pdf) in a real project scenario and discuss the advantages, outputs and learning that took place. Jason works for Habanero Consulting Group in Calgary providing services to help companies build out and leverage capability modeling.
We also recorded a video interview to supplement this posting at the end of the article.
Let’s start with your project. Provide us an overview of what was going on with the organization and the type of problem they were attempting to address.
The business approached IT and asked “what systems will we need to support our 5-8 year vision?”
What became clear very quickly was how loaded a question this was for IT. It presumed that IT had the ability to take a business vision and translate it into a set of functional technology systems. In my experience IT is getting better at translating specific requirements into productive solutions but IT has a fair way to go in translating a business vision into a realistic and pragmatic future state architecture.
The greatest challenge was identifying the information package needed for a credible and justifiable response. As we began building the answer, the deficiencies in IT’s understanding of the current business model began to emerge very clearly.
How did you get involved in the project and what did you notice?
I engaged in the project after the original project team had completed about 3-4 months of work. It was apparent in my first meeting that the team was ‘stuck’ and progress to date was limited. I brought forward the idea of ‘capabilities’ and doing the modeling before that first meeting was over.
In my mind, the context for change was simple. Most of the work to date had focused on mapping out existing business processes. I saw fundamental flaws in the ‘process’ approach as not only was it going to take too long, but also by the time it was complete many of the processes would have changed.
The team was skeptical but that quickly changed to enthusiasm after we ‘whiteboarded’ how understanding capabilities would lead us down the path to an answer fairly quickly.
What exactly did you Whiteboard? What led you to this new approach?
We needed a way to communicate seamlessly with both the business and IT leadership. I am a big believer in visual communication. Given the areas we needed to reach into were complex, it compounded the challenge of bridging the gap between business and IT. I knew that if we couldn’t easily communicate the rationale behind our answer we would lose the business audience. Perhaps foolishly, I believed that we could communicate our answer and its rationale with one image. I was hopeful that this tool would allow both the IT and business people to easily understand the overall conclusions and rationale without too much added explanation.
So you introduced the notion of Capability Modeling?
In its simplest form, a Capability Model is a visual representation of what a business does. The model shows the finite pieces of work that are done to allow the business to be successful. These pieces of work are nested and hierarchical, showing the relationship between operational tasks, management activities, organizational responsibilities and leadership directions.
In my situation, a subset example of a nested set of high level capabilities for Training & Development would look something like this:
Capability modeling focuses on understanding the static and pervasive building blocks of a company. Unless an organization gets rid of its Training & Development group, a capability such as “Deliver Training” will remain constant through all forms of organizational and process change. In contrast, how training is delivered and the finite set of requirements associated with it could change dramatically.
This pervasiveness and the static nature of capabilities provides the real value in capability modeling; it simplifies the complexity of an organization down to a level that is easily understood and rarely changes; it shows the discrete building blocks of the organization where value is generated or supported; it allows an organization to understand the productivity of its building blocks to discern opportunities for differentiation; and, it provides a relatively stable view of an organization that maintains most of its integrity through change.
Why did you feel this approach would help address the problem?
The “one visual image” was a powerful communication tool not only to show what future systems were needed but also gaps in existing systems coverage, the redundancy in existing systems, the opportunity for process consolidation, the potential for global approaches to architecture versus regional specialization, the problems associated with information flow and consumption and the list goes on and on.
In my experience IT has a terrible habit of trying to talk to the business about technology. Capability modeling allows IT to talk to the business about the business; no more “lost in translation”.
How did you construct the Capability Model?
It was built on the fly. The situation was a bit unique in that IT didn’t really have a handle on what the business did. No one in IT could capably describe how the business generated value nor what and where the building blocks of that value existed. We built a plan that addressed not only the project scope but also the need to keep existing initiatives moving forward (if they made sense given the emerging architecture) and maintaining service delivery for the existing applications and operations.
Much of my confidence in the approach came from two occurrences. The first was when I originally saw a short video clip on Microsoft’s Channel 9 of an interview with Ric Merrifield. He laid out the premise of capability modeling (at the time called “Motion”) and I saw situations where it could be applied simply. I later took advantage of a trip to Seattle to spend a morning with Ric and he was generous of his time and experience to answer all of my questions.
Capability modeling became a key pillar in the whole initiative but was just one of many activities undertaken to get to an answer.
What artifacts did you create during this project?
We produced a number of key artifacts. Most importantly we produced that “one visual image” that I talked about before. I think everyone involved had a really hard time visualizing what it would be until I put it up on the wall one Monday morning. In addition, we produced a full capability model across multiple companies, future state systems architecture, a business architecture document, an information architecture foundational model and a business executive presentation.
Given you came into the project late, how did your team respond to the new direction?
The challenge was changing the team dynamic. My sense of the existing team was that many members were lacking the experience it would take to do this. I believed I needed more than a typical business analyst skill set; I was looking for business consulting skills to facilitate the business in describing their capabilities.
When you talk to most business people about what they do, they talk in terms of process. I needed someone with enough business experience to be able to listen through the process and the unique language each person has to hear what it was that people actually do. I also needed architecture skills on the team, preferably people with lots of years of experience who could step outside of the typical architectural frameworks and think with simplicity.
As the capability modeling took hold, there was a genuine increase in the interest level and excitement about the answer we were drafting and the means we were using to get there. In fact, I think our “one visual image” became the most talked about IT initiative of the year!
Did you accomplish your objectives? Did you ultimately address the problem?
We encountered problems during execution, primarily chalked up to the lack of experience in the team around doing higher level consulting work. One big area of challenge that I will look at closely next time is the variance in people’s interpretation of what a capability is and isn’t as it creates some headaches if isn’t addressed at the beginning. One other gap that wasn’t (and isn’t) readily overcome is helping traditional IT employees actually understand business concepts. It is one thing to model a capability and another one completely to understand the context, meaning and implication of that capability.
Overall though, using capability modeling in this circumstance was the right approach. We had a powerful and fully transparent conversation with the senior business leadership team. They used our key visual artifact as the main talking point and were bringing forward their own interpretations of what it meant before and long after we presented them with our recommendations from it.
Supplementary Material
