One of the most interesting and difficult challenges of Business Architecture is creating the capability model for an enterprise. In this article, I’ll explore how to use the practices of Design Thinking to support the difficult and sometimes contentious process of creating a business capability model for an enterprise. First, let’s understand the problem a little.

For an enterprise that doesn’t have a capability model, developing the first one can be tough. Fortunately, the efforts of the Business Architecture Guild have started to produce value in the form of Reference Models. Even with a reference model, the challenges can be substantial. That is because a capability model is not a foregone conclusion. There are many ways to frame the capabilities of an organization in a capability taxonomy and that framing is important. Framing the capabilities in a particular way can drive conversations (both good and bad). For example, if we describe different capability groups for Marketing, Sales, and Customer Services, in which group do we put “Customer Record Management”? Getting this right may be important in getting key executives to step up to their responsibilities in the organization.

A capability model is supposed to be independent of the politics and processes and structure of an organization, but to be honest, the most effective capability models reflect the needs, ownership, and strategy of the organization in subtle ways. I’ve seen capability models with dependency connections, with ownership groupings, and with budgetary groupings, all as “overlays” that are both useful to the planning efforts, and which influence the capability model itself. It’s a complex problem but one that we can solve with Design Thinking.

Design Thinking is an interesting technique that can be used to approach complex problems. Design thinking makes some basic assumptions: (a) We start without actually knowing what the destination is, (b) we center our solutions around deep empathy for the customer, and (c) we create a new design, a new thing, or a new way of interacting with something through rapid prototyping and iteration. Design Thinking can be used to design a bicycle, a space ship, a house, a business process, a software package, a vacation, and yes, a Business Capability Model.

In many ways, the techniques of design thinking are well suited for the task of generating a capability model. In most of the situations I’ve been aware of, stakeholders for a capability model have never seen one before and have no idea how to use one. It’s tough to assist in designing something that you’ve never used before. Consider: if you had never taken an airplane trip and someone asks you to design the perfect passenger cabin for an airplane… how well would you do? Design thinking does not assume that you have experience with the solution before you start. As a result, you can be comfortable that your “novice-developed airplane cabin” will at least be a reasonable one, even before you take your first flight.

With design thinking, there are five phases: Empathy, Problem Definition, Ideation, Prototype, and Test (with the last two in a quickly spinning cycle). So let’s apply these five stages to Capability Model Development.

Empathize — The foremost value of the empathize stage is to put the customer at the center of your work, and remove yourself from it. Your preconceived notions of the “right way” to build something, or “what something should look like according to Expert X” just gets in the way. Your customer will describe their “conceptual space” in their own way, and different people will do it differently. To truly empathize, you have to make sure you are representing the right stakeholders, and that you are actually listening to their issues and concerns.

One thing that I find, often, is that most people have “typical” problems. If someone has typical problems, their concerns will be well understood. But there are always outliers — people who seem to always have unusual problems. These folks can provide greater insight when you are building your understanding of the problem space, because their problems challenge the status quo. They don’t fit neatly into the box. Look for these people. Listen to them.

Empathy in capability modeling means, in my experience, to listen to how a team describes themselves and to capture it their way. Do they discuss processes and procedures? Do they discuss assets? Locations? Events? Information? Documents? Workflows? Your capability model will need to reflect a wide array of stakeholders, so as you move between those stakeholders, don’t begin by forcing them into your box. Step into theirs.

Sketch (literally, with pencil) a simple non-structured diagram that represents their way of thinking of their space. Yes, eventually you will build a capability model, but don’t start with the strict definition of capabilities. Empathize with where your customers actually live, and what they actually live with.

I wouldn’t expect it to be any more “sensible” than something like the following diagram.

Problem Definition — How many times, when we get to the end of our efforts, do we look back and say “We should have asked better questions?” Design Thinking puts this problem right up front. We believe we understand the stakeholders through our empathy, but before we put the capability model onto paper and start hashing it out, let’s be clear about what problem we are trying to solve.

Capability models, in my experience, are excellent tools for planning. We can manage a portfolio and plan for changes. We can observe processes and plan for improvements. We can evaluate readiness and plan for training. We can find overlaps in application functionality and plan for consolidation. It’s planning. But not every organization plans the same way, and few organizations have a mature planning process. So as you build your capability model, think about who will own specific capabilities, how those owners will use their parts of the model to develop those plans, and how those plans will roll together. Think about the inputs to planning: trends, strategies, changes in the ecosystem, changes in the competition, problems with existing systems, and technical debt.

Your result needs to be a question that frames the problem you are trying to solve. As you pose this question to your stakeholders, their reaction will tell you if your question was effective. Don’t be afraid to drop your attachment to specific terms or processes or methods. Let things flow a little. Phrase the question in terms of the customer’s needs. One good technique is to use the phrase “How can we …” in your problem statement.

“How can we frame all the abilities needed by our business model so that we can best plan and coordinate our forward march?”

Please don’t use my example as anything more than an example. The problem statement you create should “feel” like it evolves out of the language, terminology, and culture of the organization itself.

Ideation — A capability model created by a business architect and thrust upon the organization will be dead on arrival. That is not a prediction. That is a foregone conclusion. How do I know? I’ve done it. School of hard knocks. Let the stakeholders build their capability model a series of collaborative sessions. Ideation is the first step in that process.

The ideation step can use any of a number of techniques to open the stakeholders up to different ways to frame the capability model. At this stage, you are creating capabilities, so we are applying the first series of constraints on the process. There are a dozen different ways to frame ideas that do NOT end up with a capability model, but for the sake of this exercise, we will write them down and not pursue them. We need our end result to be constrained to capabilities. Other stuff will fall out.

If the company has a process model that they actively use, you can start there.  If they don’t have one (or don’t actually use the one they have), consider using one of the capability reference models from the Business Architecture Guild (businessarchitectureguild.org) as a starting point. This is far quicker than starting from scratch. However, it is only a source of ideas. Let the team reword, rename, join, split, and shred the starting “thing” any way they want.

To keep ideation from becoming a long involved process, I suggest a series of simple exercises to expand the number of possibilities, and then consolidate that list to the most feasible ones. Then expand again, and consolidate again. Each iteration, considering a different aspect of your thinking or understanding.

An excellent technique is the SCAMPER method, which pushes participants through seven different ways of thinking about the “starting” product to create a new “ending” product. Those seven ways of thinking are: Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, and Reverse. There are a number of online resources available if you want to go deeper on using SCAMPER. Other methods may include brainstorming, worst possible idea, paint by numbers, and many more. All of these are designed to get creative juices flowing, especially for a group of people, while keeping the results controlled.

Prototype and Test — Capability models are a unique bird because they represent the abilities needed by an enterprise to achieve a purpose. For all intents and purposes, you are creating a list. That list of abilities often exceeds the organization’s internal capabilities. This is why we talk about the capabilities of an “enterprise” and not the capabilities of a “business”. An enterprise may involve many businesses, suppliers, partners, regulators, and even customers in providing the required list of capabilities.

Creating a prototype capability model is a process that is complex if done by hand (without a capability modeling tool). This is because you may have twenty stakeholders, and most of them do NOT want to see the entire organization in the capability model! They want to see THEIR PART represented in gory detail and want to see everyone else minimized. For this reason, you need the ability to prototype a complete model (for the enterprise) but to review segment-level capability models with the stakeholders. Without a tool of some kind, this can create a great deal of manual effort. (This is not a problem unique to Design Thinking… this happens with all capability model generation).

I’ve found that the prototype effort actually begins during ideation. Since we are building a knowledge product, and not a physical product or even a software product, the first prototype is actually developed in the collaborative session to some extent. It is the synthesis of that prototype with the work done by other stakeholders, in their own ideation processes, that creates the enterprise model.

Resist the temptation to go dark, work for a while, and spring an enterprise model on the organization. Work your way up from stakeholders who buy in, showing them models that are domain specific. Put four or five of the domain specific models onto paper and get feedback before attempting to create the first synthesized model. Otherwise, one domain will have undue influence over the entire structure of the capability model.

With each prototype, you are producing a new enterprise capability model and a complete refresh of domain-specific models. Run them past key stakeholders for quick responses. Remember their needs: this is a planning framework. Can they use the capability model to develop their plans? Keep asking the core question.

When you have sufficient representation across the enterprise to have created the enterprise wide model, you can circulate that model with the core planning teams in your organization: these teams may go by names like Strategy Development, Organizational Development, PMO, Enterprise Architecture, Finance, and Strategy Execution.

Conclusion

Design thinking is certainly not the only way to design a product, and it is relatively novel in specific areas of organizational and strategic planning. However, as this example illustrates, design thinking can be applied to purely knowledge based products like a capability model in a manner that hopefully builds better buy-in for the final result.

And who couldn’t use a little more buy in?

Useful links

Business Architecture, Setting the Record Straight – William Ulrich and Whynde Kuehn — http://www.businessarchitectureguild.org/resource/resmgr/BusinessArchitectureSettingt.pdf

Design Thinking Blog – Tim Brown, Ideo – https://designthinking.ideo.com/

Design Thinking and the Enterprise – Pramod Prakash Panda, AVP, Infosys https://www.infosys.com/insights/human-potential/pages/design-thinking.aspx

Design Thinking, What is that? – Fast Company, 20 March 2006 https://www.fastcompany.com/919258/design-thinking-what

A guide to the SCAMPER technique for Creative Thinking – Rafiq Elmansy, Designorate http://www.designorate.com/a-guide-to-the-scamper-technique-for-creative-thinking/

Note that this article was first published on the Infosys Enterprise Architecture blog.  I created this  article in my role as an Enterprise Architect for Infosys.  I strongly encourage my readers to check out the Infosys Enterprise Architecture blog for excellent articles on EA, EITA, and trends in technology.

http://www.infosysblogs.com/enterprise-architecture/2018/04/design_thinking_capability_modeling.html