Who writes capabilities?
The initial strategic concepts are typically written by someone with strategic oversight, like a Business Owner/Sponsor, or a Chief- or Enterprise-Architect. When a strategic concept is selected by enterprise leadership for development, someone is assigned to become the primary author of the capability.
The author consults with strategic experts about the concept and other stakeholders to write the capability statement in a standard format. The usual capability format consists of:
- A statement of the value and the vision (“why”) behind it
- The criteria the stakeholders will use to judge the success of the implementation of the capability’s value
- Limitations and constraints placed on the development of the capability (including Non-Functional Requirements)
- (Optionally) A lightweight business case outlining how developing the value will benefit the organization
What to do
Inputs
Inputs to writing capabilities include:
- High-level concept statement(s) identifying a strategic capability that, if implemented, is expected to further major organizational goals
- Consultation and supporting information from the originators of the strategic enterprise-level concept, other executive-level people, and stakeholders such as customers and their customers (generally coordinated with the first-line customer’s agreement), users, and regulators
Approach
- For each major customer or stakeholder target, do the following (if possible, across all target stakeholder types in parallel, because work on each will tend to inform the work on the others):
- Identify “archetypal stakeholders” (users, customers, architects, or other stakeholders such as business strategists or regulatory authorities). This is putting a face on your stakeholders.” There should be an archetypal stakeholder for each segment, where a “segment” is a group of users who have similar needs to each other (one segment is distinguished from another by differences in the common needs of each group.)
- Give the customer/user archetypal stakeholders (at least) each a profile, including:
- A name
- Personal details and backstory (similar to those of many people in the real-world segment)
- Specific usage scenarios they face at work: Currently and what they might do if they had the capability available
- The archetypal stakeholder for the most-important segment is called the primary archetype; the others are called secondary archetypes.
- If funding for implementing the capability is reduced, then begin by eliminating the secondary archetypes. Try to achieve the primary archetypes as much as possible.
- Sharpen your understanding of the archetypal stakeholders needs for the capabilities by doing the following:
- If possible, go to the customers’ and other major stakeholders’ place where they do the work your new capability will serve.
- Observe how they do their work, especially that which the intended capability will serve, and the kinds of challenges they face in that part of their work.
- Develop an understanding of what the customers and other main stakeholders want (about which they already know) and need (about which they may not yet recognize).
- Write the “value statement(s)” for the need that wil be served by the capability.
- Describe the criteria for stakeholders accepting the implementation of the capability. These are mission- or goal-oriented acceptance criteria rather than implementation-oriented acceptance criteria.
- Identifying limitations and constraints to be placed upon the scope of the capability to be delivered
- Identify all stakeholders of the intention to develop the capability and develop channels of communication to allow communicating with them about the capability as it is being written.
- Ensure that the capability for the archetypal stakeholder, as you are defining it, is implementable in an efficient way.
- Coordinate with stakeholders such as
- Value Stream Owner
- Product Manager
- Technology Owner
- Technical Leads
- Refine the archetype to make it as implementable as possible without adding implementation details. Consider:
- Implementable with available technologies
- Expandability
- Modifiability
- Optimal dependencies and operability with systems around the capability’s implementation system
- Repeat steps 5 and 6 until the entire capability and its parts satisfy all stakeholders as well as are practical to implement.
Here is an advanced topic. It is optional and outside the scope of this practice. Fine-tune the capability by doing the following:
- Prioritizing the different stakeholders
- Prioritizing the different aspects of the capability by doing a weighted sum of their importance to each stakeholder, then their importance again across all (weighted) stakeholders
- Using methods designed for this kind of work, including the Analytic Hierarchy Process (AHP) and Quality Function Deployment (QFD)
Tools and techniques
Tools and techniques that help with writing a capability include:
- Word processor, spreadsheet, graphic tools to implement the requirement format chosen for the capability
- Optional. A tool for capturing lightweight business cases (e.g., Strategyzer, for the Business Model Canvas format)
- Advanced, optional. A tool for supporting the Analytic Hierarchy Process (e.g., SuperDecisions or Decision Lens)
Discussion
The capability must express the value of the capability, acceptance criteria, and scope. it may also describe non-functional requirements.
Value Statement. Here is a common format for a vision statement.
For <target user/market segment>
who <statement of need>
the <product or capability name>
is a <product type or theme>
that <key benefit, compelling reason to buy or use>
unlike <primary competitive alternative>
our product <statement of primary differentiation>
Scope (clarifying the limits of development and the constraints to be placed upon it)
- In scope. What kinds of capabilities are meant by the stakeholders to have included in the implementation of the capability.
- Out of Scope. What kinds of capabilities are not intended by the stakeholders to be implemented in the capability (primarily, capabilities that might otherwise be assumed to be included but should not)
NFRs (Non-Functional Requirements): Characteristics of the final product that are not functional (that is, not doing specific actions), yet are considered essential by the major stakeholders. Examples:
- The “-ilities.” Reliability, modifiability, maintainability, etc.
- Limits (such as for performance). For example: must-support number of simultaneous users, maximum response latency, etc.
Alternative: A lightweight business case
For many years, the way to justify business action has been to write a business case. This has been a heavyweight process and document that took days or even weeks to create; far too time-consuming to use at the level of most capabilities.
Now a lighter-weight approach is becoming the norm for business case development. It is called “Business Model Generation” (BMG). The format for a business case from the Business Model Generation approach is called a “Business Model Canvas” (BMC).
The Business Model Canvas focuses on a few, key issues, and simplifies their exploration. This makes it practical to apply the power of value-based thinking to smaller tasks that are nevertheless significant to the health and success of the enterprise. Capabilities fit into this level.
A lightweight business case for a capability will select the aspects of the Business Model Canvas that are most relevant to the capability specified by the capability.
Look at the following models and choose a subset that fits the needs of the organization. While all of these are good, any particular format may be heavier-weight than what you need or conversely may omit concerns important to you.
- The BMC model is described in the book Business Model Generation.
- A powerful subset of the BMC model useful at the capability level is explained in the book Value Proposition Design.
- A subset is found in the SAFe method described at www.scaledagileframework.com/epic
Outputs
This practice yields capabilities that are placed into the portfolio backlog and specify
- The value their implementation must deliver
- The bounds, limits and constraints to be levied on the implementation
- The least-possible amount of design and implementation direction; leaving those decisions to be made “Just In Time” later
When to do this practice
After approval of a strategic concept for delivering value to stakeholders, to advance major organizational goals
Where to do this practice
This practice is not specific to any location.
Outcomes
Following this practice will provide the best-possible foundation for development:
- Identifying stakeholders and describing their needs that will be served
- Setting boundaries around the development effort, so it will achieve its goals without unnecessary gold-plating
- Leaving as much room as possible for implementation decisions to be made by the developers
