Introduction to Business Capability Modeling

Business Capability Modeling

In any Enterprise-scale Agile transformation, having the right structure and governance to support how work flows through the organization is crucial to having a successful transformation (see “How to Structure Your Agile Enterprise“). Business Capability Modeling is a method LeadingAgile uses to inform and customize our recommendations around this structure and governance. We work closely with our clients to develop their unique business capability model. We then heat map the capabilities in terms of business value, performance, and risk, based on interviews with key stakeholders. The resulting heat-mapped capability model promotes a shared understanding and can be used as a basis for how to structure teams (what to form the teams around) and for prioritizing and scoping work.

The Capability Model is a modular description of a business in terms of desired business outcomes. Desired business outcomes are identified and defined at each level of detail in a hierarchical fashion. So for example at the highest / top level of the hierarchy we would have for a typical business capabilities like “Develop and Manage Products and Services”, “Market and Sell Products and Services”, “Deliver Products and Services” and “Manage Customer Service”. Complementing these operational capability areas are supporting capability areas like “Develop and Manage Employees”, “Manage Information Technology”, and “Manage Financial Resources”. The American Productivity and Quality Center (APQC) is a member-based, non-profit that provides a “Process Classification Framework” (PCF) from which these examples are taken. LeadingAgile works with the client in a process of discovery to identify the client-specific capabilities, using the APQC PCF as a reference model.  

The capability names are chosen to be action oriented, written in a verb-noun format, like “Acquire Inventory” or, “Authorize Customer”. The descriptions are written to define the desired business outcome, like “Maintain enough inventory to support demand”, or “Enable registered customers to use the system”. There are likely  one-hundred or more capabilities across 5-10 or more major areas such as those listed above. This gives us a very useful model since it describes the business in terms of its “Whats” and not “Hows”. We need to avoid the “How Trap” when discovering and defining the capabilities. It’s so easy to go down a rat hole of discussion around how a business outcome is achieved. We want to stay focused on what needs to be achieved. This gives us an objective model of the business upon which we can have objective conversations. Meaning, without getting into how capabilities are achieved since that ties us to the current implementation.

As mentioned, the Capability Model provides a modular, outcomes-based description of the business. As such, this is naturally a Service Oriented model or view of the business. So, the business processes made up of the capabilities could be implemented in software with a Service Oriented Architecture. Thus, for greenfield development, the Capability Model could be used to help drive a Service Oriented Architecture (SOA)/ design and implementation. For legacy systems, it can be used to refactor the legacy architecture to be more Service Oriented, in addition to the other uses listed above. To learn more about Capability Modeling and SOA, see the Harvard Business Review paper “The Next Revolution in Productivity” by LeadingAgile’s Dennis Stevens, et al.

————————————————

Also check out a recent post where Mike addressed the question “Is Your Business Model is a Good Fit for Agile“