This is my presentation from Product Camp Atlanta. I address two big issues facing product management. First, establishing an approach to connect product strategy with business strategy, customer value, and risk. It provides the structure for feedback and rapid reassessment of the product road map (backlog). Second, the presentation demonstrates how to leverage the model to reduce the miscommunication, over analysis, over design, and over engineering that leads to scope creep and misalignment between the desired solution and what is actually delivered.
Posts Tagged ‘Capability Analysis’
There is a nice summary of Kanban at http://www.kanbandistilled.com/. It shows Feature Requests going into the Software Development Pipeline and Improved Software coming out.The article does a great job of showing how Kanban helps improve the flow of software development. Getting better at software development is important and Agile methods have been helping teams achive this goal. This is the first bargain of Agile-delivering software faster and with much higher quality then ever before. In most organizations however, this is only a small part of the business equation. Even when development is successful, a narrow focus on software development narrows the value an organization will achieve. We also need to align of development with the most important needs of the business, balance development with adoption, and ensure improved business performance is achieved.
Feeding the Software Development Pipeline
Unless a company is a software development service provider, its business is not about software development. Software likely enhances the businesses ability to create value for it’s customers. So, while Agile development helps teams get better at software development – the goal is to get better at creating value for it’s customers. The focus of Agile software development is upside down. The focus should be on the capabilities of the business. Aligning development with the needs of the business requires understanding which business capabilities will benefit from improvement and prioritizing these needs based on business value.
After using a business capability approach to need identification and prioritization, the business needs must be appropriately scoped and communicated to development. Over the last month I have been writing about Making Agile Requirements Work. need to make sure the requests that go into the Software Development Pipeline are clear and appropriately defined. Following the six principles of Agile Requirements That Work help with this feeding of the Software Development Pipeline.
- Articulate Purpose and Outcome
- Establish a Shared Language
- Provide a Stable View of the Business
- Support Progressive Elaboration
- Prioritized and Reflect Business Value and Risk
Gaining Business Benefit
The other part of the equation is to ensure the organization adopts and supports the improved software. Once the Software Development Pipeline has produced Improved Software, it still isn’t valuable until the Business Capability has achieved the intended performance improvement. Just as the elicitation and analysis of requirements has to match the cadence and needs of Software Development. Software Development has to match the cadence and needs of the organizations ability to adopt and support Improved Software. Part of the overall feedback to the organization includes ensuring the capability improvement is achieved.
At every step in this equation different risks may exist. identifying, prioritizing, and scoping feature requests have risk associated with a lack of understanding. Software Development has risk associated with the Ability to Execute and Verify the delivered software. Benefit realization has risks associated with achieving adoption and being able to sustain and support change in the organization. These risks should be explicitly managed and feedback mechanisms should be in place to recognize the realization of risks. Failing to understand and manage risks in an integrated fashion will also diminish the organization’s ability to maximize benefit from it’s investment.
The Real Agile Bargain
The real agile bargain is the maximizing of economic outcomes by increasing the speed and focus an organization can improve and respond to the market. The Agile Business Value Equation is solved at the Business Capability Level. The ability to rapidly develop high quality software moves Technology from a change obstacle to become an change enabler. This happens at the intersection of Feeding the Software Development Pipeline, Developing the Software, and Gaining Business Benefit. Solving any of these parts independent of each other does not result in optimizing business agility.
Dictionary.com defines a requirement as “that which is required; a thing demanded or obligatory”.
BABOK® is consistent with this. It defines a requirement as:
- A condition or capability needed by a stakeholder to solve a problem or achieve an objective
- A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
- A documented representation of a condition or capability as in (1) or (2).
The purpose of documenting requirements is not to document detailed steps that someone performs – it is to communicate the outcome needed to achieve an objective. One problem that arises is when requirements are expressed as a document of the existing process – typically through a review of existing process documentation or through observation of people doing the job. As I have discussed in previous posts, just documenting process can lead you into the How Trap and it can fail to generate a useful shared understanding. These problems arise when the focus is on how stakeholders are currently doing the work and not on understanding the challenges, problem or objective. But, focusing on process is a problem in another way. It is an unstable lens.
Modeling processes early in the elicitation process is not helpful to creating an appropriate understanding of the effort. Process reflects how people say they ought to do a task in perfect circumstances. The work is almost never consistently performed based on process documentation – or even how you observe the process being performed. Exceptions, reorganizations, changes in personnel within or adjacent to process, new tools and technologies, and innovation will change the process view. Even just asking five different people what the process is will likely produce five different results.
The process view can also propagate flawed understanding on the part of the people doing the work. You have likely heard the story about the recently married young women who was cooking her first Thanksgiving dinner in her own home. She had invited her family over the beautiful house she shared with her husband to show her parents how successful she had become and to demonstrate her gratitude to her parents. As she brought out the turkey for dinner her mother noticed the young women had cut the tail off of the turkey. The mother asked her daughter why she had cut the tail off the turkey. “Because that’s they way you always did it, Mom.” The mother smiled and replied, “That’s because the only pan we owned was too small for the turkey.”
A process based view hides assumption, complexity and is an unstable representation. The real requirement doesn’t change based on who you ask, who is doing the job, or the most recent reorganization. Basing requirements on unstable views doesn’t reflect the intent of the solution. This may result in an expression of the solution that doesn’t meet the needs of the business. As you observe a process or review process documentation ask why each step is important and what the intent of each step is. Consider what would happen if the steps were done in a different order or something was left out. Creating a stable, purpose driven view of the objective will provide valuable input to the development organization that will result in an improved solution.
Today I am discussing the tasks from the BABOK associated with Solution Verification and Validation. These are the tasks to determine which solution best fits the business need – although it includes assessing the performance and effectiveness of the solution. There are six tasks associated with Solution Verification and Validation. I show the BABOK® purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.
Assess Proposed Solution
|To assess proposed solutions in order to determine how closely they meet stakeholder and solution requirements.||One of the benefits of Agile is that while some solution decisions must be made up front the Solution can be assessed over time. Agile facilitates the concept of Real Options where design decisions can be deferred until the last responsible moment. Detailed understanding of the business need is unfolding at the same time the teams understanding of how to solve the problem is developing. With effective Agile architecture and design the cost of redoing things that have already been developed is relatively low. Assessing the proposed solution doesn’t become a check-point on the project but an ongoing assessment against the business case and current status of the project.|
|Allocate stakeholder and solution requirements among solution components and releases in order to maximize the possible business value given the options and alternatives generated by the design team.||On Agile projects, this is done by allocating requirements into feature themes and components. Allocation shapes the design of the delivery organization itself. Feature teams form around feature themes and components needed to support cross feature theme requirements.|
Assess Organizational Readiness
|Assess whether the organization is ready to make effective use of a new solution.||The organizational readiness assessment occurs on Agile projects in much the same way as it does in traditional projects. The difference is that the release cadence can be more frequent. A significant area to define in Agile projects is how often the organization can absorb releases. Organizational readiness should include not just the end-user/customer of the release, but the supporting organization as well (i.e., support, training, sales, marketing, accounting).|
Define Transition Requirements
|Define requirements for capabilities needed to transition from an existing solution to a new solution.||The determination of transition requirements occurs in an Agile project much as it does in a traditional project. The ability to deliver value incrementally opens up new possibilities for transition. Rather than monolithic release the organizational impact can smaller but more frequent. Since the cost of development per unit is lower, temporary integration into existing systems can be developed and make the need for running parallel systems less significant.|
|Validate that a solution meets the business need and determine the most appropriate response to identified defects.||Validate solution happens as an ongoing effort in an Agile project. Within each iteration the customer is provided detailed feedback on the current requirements. At the completion of each iteration cycle, the product owner facilitates alignment with the customer need and continued alignment with the business case.|
Evaluate Solution Performance
|Evaluate functioning solutions to understand the value they deliver and identify opportunities for improvement.||Upon release, the Product Owner facilitates understanding how well the solution meets the needs of the customer and identifies new opportunities for improvement and to create additional value for the business. The incremental nature of the back log allows new, higher value items discovered during this evaluation to enter into the existing backlog ahead of existing items. This is an additional way that Agile shortens time to value.|
Solution Verification and Validation
All of the tasks in Solution Verification and Validation are important on Agile projects. The primary distinctions in this Knowledge area are the support for the emergence of the solution over time. Particularly interesting are Assess Organizational Readiness and Transition Requirements as these are often overlooked in Agile projects (many software development projects). Remember, the product isn’t done-done until the customer is using it and achieving the benefits expected by the product owner.
Agile methods are helping teams deliver software faster and with much higher quality than ever before. In response, Agile has emerged as a driving force in software development. Businesses want to achieve the benefits of improved quality and rapid delivery. But getting faster at development is just part of the equation. As I discussed in my presentation “Feeding The Agile Beast”, you have to identify, prioritize, and scope what you are going to build so that risk is managed and ROI is maximized.
So, What’s New?
Agile methods have emerged from a few simple concepts. Change happens and people trump process (Thanks to Ken Schwaber via Steve Adolph). In response to this, substantially all of the Agile methods describe a way of delivering software that support the following attributes:
- Progressive elaboration a little ahead of demand (for planning, requirements, architecture, testing, etc)
- Incremental and iterative delivery (though not time-boxed in Kanban/Lean continuous flow)
- Ongoing learning through close customer engagement regarding product fit/business value that informs requirements and prioritization
- Ongoing learning regarding development/delivery approach and interactions that informs ongoing improvement efforts
- Self organization around the work (where the people performing the work decides how best to do their jobs within organizationally appropriate constraints)
In traditional software development, this identification and prioritization of what you are going to build falls in the role of the Business Analyst. However, traditional business analysis methods do not operate in harmony with the iterative and incremental cadence of Agile methods. For the most part, this is different than traditional plan driven projects. Over the next week or so, I am going through the capabilities associated with Business Analysis and discuss the how Agile impacts how business analysis is performed.
The Guide to the Business Analysis Body Of Knowledge
I am going to build this discussion on work from The Business Analysis Body of Knowledge® (BABOK®) from the International Institute of Business Analysis. The IIBA® is the independent non-profit professional association serving the growing field of Business Analysis. The IIBA has collected the current generally accepted practices within Business Analysis in The Business Analysis Body of Knowledge® (BABOK®).The BABOK® Guide describes Business Analysis areas of knowledge, their associated activities and the tasks and skills necessary to be effective in their execution.
The BABOK has six Knowledge Areas.
- Business Analysis Planning and Monitoring: Determine which business analysis activities are necessary to support an effort.
- Elicitation: Understand the underlying needs rather than stated or superficial desires.
- Enterprise Analysis: Understand what the enterprise is capable of performing.
- Solution Verification and Validation: Determine which solution best fits the business need – includes assessing the performance and effectiveness of the solution.
- Requirements Analysis: Organize, prioritize, and model requirements and risks.
- Requirements Management and Communication: Ensure knowledge gained through business analysis activities throughout the effort is shared among the team.
Within each Knowledge Area are several tasks. I will focus on how progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization impact who performs business analysis tasks and how business analysis tasks are performed.
Agile Business Analysis
Just to set my context. All of the Capabilities that are reflected in the BABOK happen on all projects – traditional or Agile. They may or may not be done by a specific role. They may or may not happen in a specific phase. They may or may not be done with any ceremony or intention. They do occur. Since the identification, prioritization, and scoping of requirements is so important to success, they need to be done well. And on an Agile project they need to be done so they enable – not constrain or impede – the delivery of value in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.
You’ve heard people say, “That’s great, but does it scale?” , we think we all agree on what that means. But, as with many words we use in this space, the word scale is potentially overloaded – everyone has a different idea of what the term means. This led to some interesting comments on my post Monday, What Does Scaling Agile to the Enterprise Mean?. Even though I explained the five orders of scaling, and that the practices were different at each order of scale, there is confusion about what I mean by scaling and what we are scaling.
I have gone to dictionary.com to gain clarity on what it means to scale. I pulled eight definitions to determine which one we intend.
- one of the thin, flat, horny plates forming the covering of certain animals, as snakes, lizards, and pangolins
- a balance or any of various other instruments or devices for weighing
- a succession or progression of steps or degrees; graduated series:
- a succession of tones ascending or descending according to fixed intervals
- the proportion that a representation of an object bears to the object itself
- Australian Informal. to ride on (public transportation) without paying the fare
- Dentristy scal•ing. The removal of calculus and other deposits on the teeth by means of instruments
- a certain relative or proportionate size or extent
We don’t mean what comes off fish, what we weigh things with, a way of measuring temperature, a musical construct, making a model of something, riding without paying the fare, or cleaning teeth.
So we must mean taking Agile to a proportionate size. That’s to point of the different orders of scaling. That Agile will be expressed differently at each order. But what are we actually taking to a proportionate size? Do we want to have an Enterprise wide stand-up with thousands of people? Do we want to have every job done by two people? What are we scaling?
Small team agile, as guided by the Agile Manifesto for Software Development, is a set of values and principles. Agile, as practiced in many development teams, is a set of management, leadership, and engineering practices resulting in an energized workforce frequently delivering software that meets the emerging needs of the customer. For other definitions of Agile, I went back to dictionary.com.
- quick and well-coordinated in movement
- marked by an ability to think quickly
Well, we aren’t hoping that every person in the Enterprise learns to write code. It isn’t the specific practices that we want to see scale. It is quick and well coordinated movement we see in small team agile. It is the ability to think quickly and respond to emerging customer needs.
What do we mean by scaling agile to the enterprise? We are scaling the benefits of agile – the benefits of an energized workforce frequently delivering value that meets the emerging needs of the customer. We want to take this up from small development teams so that the entire organization can be more adaptive and responsive.
It turns out that the capabilities (not the specific practices) that make the benefits of small team agile possible can be expressed at each order of scaling. And when layered together, the benefits of agile can be scaled to the enterprise level. Over the next few weeks, I am going to go through the management, leadership, and engineering capabilities of small team agile and discuss how the capabilities scale to deliver benefits at the different orders of scaling.
You may already know that Mike Cottmeyer and I signed a contract to produce a book that describes situation specific approaches to scaling Agile in the Enterprise. This book is based on the work Mike and I have done over the last 10 years or so in helping organizations improve their ability to deliver value to their customers. While we have done the customer engagements separately, we think about this in a similar way and have been able to consistently deliver results to our clients.
Mike and I need to write about 157,000 words over the next 9 months to produce the content for the book. We will be blogging most of the ideas as we write the book and really look forward to your comments and feedback on our approach. Learning to tell the story so it resonates is really important to achieving our goal of writing a book that is very valuable to managers in organizations who are facing the Scaling Agile challenge.
Common Capability Model
A Capability is “an ability or capacity the organization relies on for a specific purpose or outcome”. We focus on capabilities because we are initially interested in What and Why, not on How. Getting caught up in How without clarity on What and Why is common in methodology debates. We Call this the “How Trap”. Using a capability analysis approach we have been able to get people out of what we call the “How Trap” and get them thinking about purposes and outcomes.
As a core part of communicating how managers can develop situation specific strategies for scaling Agile, we are building out a common capability model. Why not use an existing model? Well, we are working from the understanding that there is no single model that is outcome/purpose focused that can be used to build out the scaling. We need to build that base – not by recreating it from scratch but by building on top of traditional models that have worked at the enterprise level, like CMMI and PMI, as well as Agile approaches that have worked at the team level like Open RUP, Scrum, and XP.
As I introduce this capability model, I will start from a Scrum/XP perspective even though those methods are based on practices and not Capabilities. For example, iterations in Scrum and short releases in XP are about Limiting Work in Progress. So is incremental development in Open RUP. I will introduce the Big Agile Capability Model in terms of Agile practices. I will show how they are complementary to the traditional models and how this outcome-based understanding helps us develop a situation specific approach to scale. Finally, I will talk about common dysfunctions in organizations that limit effectiveness.
I have been working on this consolidated capability model for a few years. At a number of clients, I have used an approach based on a consolidation of CMMI, OPM3, XP, and Scrum. More recently I have included Kanban and the Open RUP in the model. At higher levels of scaling I rely on some other capability models like the Process Classification Framework, ITIL, Pragmatic Product Management, and the Business Architecture work I did at Microsoft. The goal is always to find a way to talk about outcomes and purposes before we talk about implementation.
The trick is in translating these jargon specific detailed models into something straight-forward that facilitates the development of situation specific strategies for scaling Agile. This is a challenge that Mike and I are working through now. Before everyone pukes on the idea of basing our approach on a capability based model, I want to cover a couple of important things.
First, I am not a big fan of staged models. I get the concept of CMMI’s levels of maturity – it is important to establish maturity in the lower level processes to gain benefit from the higher level processes. But I believe an organization can make progress on higher-level processes while they don’t have all the lower level processes in place. The capabilities are interdependent and so can’t be addressed in a linear manner.
In OPM3, the model is not staged. You pick an area of focus, such as project cost or program risk, and the model will walk your though capabilities related to that strategic area. Like OPM3, our model is not staged or prescriptive in nature. We talk about these in an order, but in reality, the team needs to be focused on improving capabilities based what makes the most sense for a specific situation.
Second, I don’t like the idea that Product Development, Project Management, and Software Engineering (http://www.dennisstevens.com/2009/03/12/project-management-product-management-and-agile/) are evaluated separately and independently of other the rest of the organization. They are too tightly integrated in real life once you get past the small team to be treated separately. At the end of the day, there is no point in getting better at any of these areas if it doesn’t result in an improvement in delivery of value to the customer.
Finally, one problem I have with formal capability models in adoption is that these models come off as overly complicated, prescriptive, and aren’t typically treated as situation specific. Typical models drive the conversation, “What do I have to do to pass an audit”. We want to change the conversations in the business to, “What is the next most important thing we can focus on to improve our ability to deliver value to my customers”.
The Big Agile Capability Model
The model that Mike and I are working on starts with Small Team Agile. We build this out to Horizontal Scaling, where you have multiple teams doing Agile development on distinct outputs. Then we build out to First Order Scaling, where multiple Agile teams are working together on a single product. At Second Order Scaling, multiple Agile teams are working on multiple products. At Third Order Scaling, we are working to leverage the ability to rapidly deliver working software across the Enterprise. Wrapped around this is a set of common capabilities that apply to every level of scaling. Over the next several days I am going to describe the capability model we have derived from our experience and research. As with everything else in the book, this model is subject to change.
I am going to describe the Small Team agile capabilities over the next few days. Over the next few weeks, I will go into the capabilities associated with Horizontal scaling, then First Order, Second Order, and Third Order scaling.
As we go through our approach, please share your thoughts – good and bad – with the approach and how it is being communicated. We need to make sure this is valuable contribution to the body of works hoping to improve our ability to deliver high quality products that meet the needs of customer.
In my last post I talked about starting with business value. Remember that a business capability describes something the business depends on for a specific purpose or outcome. As Mike Cottmeyer talks about in his post, Falling into the How Trap (http://www.leadingagile.com/2009/08/falling-into-how-trap.html ), Capability Analysis helps you change your view from process and politics… how you are doing work… to the actual business outcomes needed.
This is important, because in many companies silos, inertia, and budgeting all contribute to problems in organizations getting to business value. Here is an example of how Re-Thinking using business capabilities led to dramatic results in a difficult environment. The client was a financial services client. They were in a very politically charged environment that arose from rapid growth through acquisition followed by rapidly changing market conditions. This client was moving in an unfavorable financial direction. There was a lack of cash, tremendous pressure on IT, and recent lay-offs had led to a loss of trust and historical knowledge.
We met with executives to make sure we understood their strategy and could articulate it simply. We then worked with the managers to create a business capability baseline from the capabilities in the organization. We identified those capabilities that were most important to achieving the core business objectives and the goals for the strategic project. Against this view we reconciled the budgeted capital projects budget and the IT related operating expenses.
Our results showed three significantly interesting capabilities. For the most part our findings were not new situations – but the capability analysis brought visibility to them. This is one of the real powers of capability analysis. By focusing on learning “What” they did, then understanding how they did them and where they were investing we were able to present the findings to the business in a way that overcame the politics driving most of the decision making.
The majority of the budgeted and in process projects were focused on Manage-Customer -Requests. At first blush, this was reasonable since there was a sizeable Customer Service group and this was their primary focus. All of the requests would have resulted in improving how the Manage-Customer -Requests capability performed. These requests were prioritized to the top of the list because the VP of Customer Service was influential. But given the current needs of the business, this capability performed suitably – there was no performance gap in this capability.
Although, there were only three budgeted requests against it, the largest capability gap existed in Negotiate-Customer-Terms. This was also high business value because keeping the right customers and getting valuable new customers with the right offers was the key to the survival and profitability of the company. This project was not budgeted.
We also found four separate Business Intelligence efforts focused on Analyze-Customer-and-Market-Data. Two of them had been brought in from acquisitions. One of them was a rogue project started by the marketing group when they felt IT was too slow to respond. All of these were used (or planned to be used) for internal analysis and none of them were integrated into the customer service platform.
Using our findings from the capability analysis we were able to get agreement to shut down the redundant BI projects – saving about $8 million a year. Despite the momentum on these initiatives, they were not currently delivering value, they were unfocused in their efforts, and they weren’t aimed at high business value/low performing capabilities. We were able to draw from the best of these projects for the most important effort.
We then used the findings to get the VP of Customer Service to agree to stop the Manage-Customer-Requests initiatives. Even though these projects were budgeted, and some were in progress, the VP realized IT needed to focus their resources more effectively.
We then focused IT resources on the Negotiate-Customer-Terms leverage point and the necessary data integration. Since our need was very clear, we were able to generate very tight business requirements for the BI and development teams. Leveraging Agile development techniques we were able to complete the development and integration rapidly.
In summary, through performing a ReThink using capabilities analysis, we found redundant investment of $8 million that we were able to recover almost immediately. Then, by laser focusing development efforts on the most important business capabilities, we were able to deliver an initiative that improved the company’s portfolio retention by over $15 million a year. The total project lasted less than 9 months, cost less than the savings from eliminating the redundancy, and delivered what was most important to the business.
Capability Analysis allowed us to overcome silos, inertia, and the politics surrounding budgets. We were able to find cash for the project, relieve pressure on IT resources, and overcome a loss of organizational knowledge. By building a common view of “What” the business did and identifying needs at the top of the Business Value/Performance stack – the business reached agreement on what was needed and aligned their efforts accordingly. There are probably a lot of ways to accomplish this type of alignment, but we have consistently found success using Business Capability Analysis.
Lots of people are talking about the importance of prioritizing the work your software development teams do. For a product development group, this means picking the right features to build in the best order. For many IT organizations, it means selecting the right projects to work on to create value for the organization.
- Mike Cottmeyer at Leading Agile is talking about agile portfolio management at http://www.leadingagile.com/2009/04/in-my-post-second-order-agile-scaling-i.html.
- Back in January, I was talking about how important it is to Focus on the Right Projects http://www.dennisstevens.com/2009/01/22/focus-on-the-right-projects/.
- In the ganthead article, “Tough PPM Decisions” Bob Weinstein calls for a “comprehensive understanding of the organization’s business and industry, along with finely honed business analytic skills.”
- Over at PMThink! They are discussing this issue as well. http://www.pmthink.com/2009/05/project-value-delivery.htm “Our historical challenge is being able to identify and articulate business value in the first place”
- Thinking for a change talks about estimating business value using a forced rank order method.
So this is clearly important. We need focus on the right projects and features – in a way aligned with our business model and how we create value for our customers. We need to have a forcing mechanism to overcome the tendency for everything to be a number one priority. And we need to be able to understand how shifts in strategy and market conditions impact the prioritization.
But how can you do it?
I use capability analysis to identify where to focus and to align everyone in the organization with the decision. A version of this work was published in the June 2008 Harvard Business Review article, “The Next Revolution in Productivity.” It is also covered from an executive perspective, in Ric Merrifield’s new book, “ReTh!nk: A business manifesto for cutting costs and boosting innovation.” I have used it over the last 10 years to support dozens of businesses and projects.
What is a capability?
A business capability describes something that the business relies on for a specific purpose or outcome. The focus is on what the business does rather than how it is done. Most organizations are not accustomed to thinking about the business as a series of outcomes and fundamental purposes. They think about what they do – not outcomes and purposes. Sending a fax is an example. Ask someone what they do and they will say “I send faxes.” While a business might ‘send a fax’, sending a fax is not a capability, it is a how. Sending faxes is one way of achieving the business outcome of ‘notifying vendor’ or ‘communicating with the customer’. Also, capabilities remain stable. For example Pay-Payroll, it doesn’t matter whether you do it manually, internally, or outsource it. It has the same performance criteria, regulatory constraints, and inputs.
Capability Analysis is presented here as a five step process.
- Identify the capabilities within in your business
- Identify the capabilities most critical to your company’s success (Business Value)
- Identify the health of the business capabilities (Performance)
- Identify the business risk and technical risk associated with the capabilities (Risk)
- Prioritize opportunities to the smallest subset necessary to deliver value
Identify the capabilities within the activities in your organization
I usually start with six high-level capability groups within the typical enterprise: develop and manage products and services, market and sell products and services, deliver products and services, manage customer service, manage vision and strategy, and provide business infrastructure. Identifying the specific capabilities within the enterprise involves creating a capability hierarchy within the capability groups.
For example, market and sell products and services can be broken down to activities and these activities can then be broken down to capabilities. This isn’t functional decomposition, think of it as a tree of cascading purposes.
There are several sources to build out these models. One excellent starting point is the Process Classification Framework from APCQ (www.apcq.org). This framework provides a relatively complete list of capabilities across organization’s across industries.
Identify the capabilities most critical to your company’s success
Critical capabilities are indentified by assessing how closely each capability is tied to the execution of business strategy and the direct contribution of customer value.
Is this capability directly linked to a strategic objective? (Yes/No)
How does this capability contribute significantly to the profitability of the company? (High/Medium/Low)
Does it have a strong connection to company’s brand or identity? (High/Medium/Low)
By assigning scores to each capability and totaling per capability you can rank order the capabilities based on business value. If the business strategy or market conditions change, the model can be rapidly re-evaluated.
Identify the health of your business capabilities
Capability health is evaluated by looking at performance, cost, and the tendency to be a constraint. The more factual and objective you can make this data, the better. But a solid subjective assessment that has been agreed to by the organization is a very powerful tool.
How is this capability performing relative to expectations? (Above/Meets/Below/Far Below)
Is the cost per for this capability acceptable? (Too High/Acceptable/Below)
Is this capability ever a constraint in the organization? (Often/Sometimes/Seldom)
Again, you assign scores to the factors and use the resulting score as a force rank mechanism. It is important to focus on improving where you can improve the ability of the capability to meet the needs of the business, reduce the cost per, or eliminate it as a constraint. One nice thing about this evaluation method is that any initiative now has a very specific out. And that outcome can be tied directly to the business strategy.
Identify the business risk and technical risk associated with the capabilities
Finally, they are evaluated for the risk associated with changing (or not changing) them.
Is the technology and the vendor stable and aligned with the IT strategy? (Yes/No)
Is this a highly connected, highly regulated, or unpredictable capability? (Yes/No)
Will this capability support any anticipated growth? (Yes/No)
Now that you have clarity of your business model or product you can prioritize within specific portfolio segments. For example:
High Business Value/High Performance/Low Risk: Operate
High Business Value/Low Performance and/or High Risk: Invest
Low Business Value/High Performance/Low Risk: Optimize
Low Business Value/Low Performance/High Risk: Eliminate
The majority of your capabilities will fall outside one of these segments. You probably shouldn’t be spending everywhere all the time and these segments highlight where you should spend and what type of action to take. As you complete initiatives, capabilities will move into new segments. For example, the High Business Value – Low Performing capability better be moved out of the Low Performing segment at the completion of a project.
The findings can be presented graphically in a heat-map fashion. In the heat-map the border is strategic value, the fill is suitability of performance, and the dot is risk. The red-colors means it is interesting, green means it is not something to evaluate.
For example, the capability above is strategically important, performs suitably, and has some risk. In future posts I will show a more detailed capability model with cascading capabilities. This type of Visual Tool serves to align an organization around a common vision. It also can highlight where there is a disagreement around the perspective. These conflicts should be resolved so management is focusing all efforts in a common direction.
Benefits of Capability Modeling
This is a high level look at capability modeling. Based on the complexity and maturity of an organization this approach can be established and maintained rapidly and with low friction. The approach facilitates:
A clear connection of development work with business value
Alignment of organizational and infrastructure decisions with business value
A stable context for understanding and communicating across functional areas
Requirements clarity and testability
Negotiating the balancing of technical and business risk
A progressive elaboration model that supports an Agile approach to improvement
This is a high level overview of how to execute a Capability Analysis. Most of the assessment will require a high-level of detail in the preparation of questions. You will also decompose the business or product to more detailed capabilities in those areas where it provides value. We have a new Yahoo group called rethinkbus you should join if you want to interact with people who are learning about and have done projects using this approach.
During the past several months I have been involved in a number of conversations regarding Lean, Agile, Kanban, and Traditional methods of software development. Most experienced people believe that there are appropriate practices from each of these methods and that each organization has to come up with their best implementation. In the discussions the question continues to come up whether it is more important to teach principles or practices to teams adopting new methods. I think this is a premature discussion. Without an understanding of purpose – the direction you are heading will not be clear.
Start with Purpose
Principles and practices are both about “How”. Principles are about the theory of “How” and practices are about the mechanics of “How”. “How” discussions that happen out of context often result in dogmatic conflict. The right place to start is to focus on “What” you are trying to do and “Why” you are doing it. We need to focus on the purpose of what we are doing in the context of the business strategy. Then drill into appropriate principles and suitable practices to implement. All too often, teams are focused on “How” without clarity of the “What” or the “Why”.
Sounds great, right? So how do you do this? I have had dramatic success in helping organization’s achieve dramatic improvements in performance using a purposed based approach. The approach based on focusing on “What” and “Why” is called Business Capability Analysis.
What is Business Capability Analysis?
Business Capability Analysis is based on rapidly developing a model of the business to identify where to improve and facilitate discovery of the best way to improve. The common model gets everyone involved focused on the purposes involved and results in a shared understanding of what needs to be accomplished to achieve the business strategy. This understanding is critical before you start applying practices and principles.
Business Capability: a particular capacity or ability that the organization relies on for a specific purpose or outcome.
Business Capabilities are purpose focused. Their purpose is to produce value for the organization. What are we trying to do and why are we doing it? How does this capability help achieve the business’ strategy and operating objectives?
Business Capabilities remain stable – even when the implementation changes. For example, almost every business has a “Pay-Employees” capability. Regardless of implementation, the regulatory requirements, employee expectation, interface with accounting, and many other factors don’t change. What you are trying to do and why you are doing it remains the same whether you automate it, outsource it, or are doing it manually.
Business Capabilities provide a common business focused model for other attributes. Ownership, cost per, timing, and other interactions are a sample of the attributes that can be captured within a capability. Business Capabilities can be used to align the organizational, technology, process, and information of a business.
Business Capability performance is dependent on the interactions with other capabilities.
Business Capability Example
Let’s use “Travel-To-Work” as an example. The purpose of “Travel-To-Work” is to get where you need to be so you can do your job every day. It is important that you are on time reliably. Based on your objectives, you may implement this capability differently. This choice will drive organization, process, and technology decisions. Here are a few examples of implementing this capability based on differing objectives.
So the capability is stable even when the implementation changes. While we can debate on appropriate implementations, an interesting aspect of this approach is that it frees us up to discuss alternatives to achieving the purpose of the capability. Remember, the purpose is not to travel to work. The purpose is to be where you need to be to do your job. Why do we need to physically travel to work? Another approach might be to provide access to the computer systems and telecommunications. By looking carefully at the purpose of the Capability in the context of our objectives, we can come up with an innovative new implementation.
Capability Analysis Applied to Documenting Requirements
Let’s look at document requirements through the Business Capability lens. This is an area of significant conflict among the various software development approaches. Agile advocates will tell you that there is no way to build perfect documentation up front – that this is a collaborative effort and any more than rudimentary documentation will result in waste. BUFD advocates will tell you that to the extent the project outcomes are knowable up front, it is irresponsible to fail to produce an appropriate requirements document. It is irresponsible because you don’t understand where you are relative to the promise made to the business relative to cost, time, and scope – you have no way to measure performance.
So, one of the purposes of documenting requirements in software development is to communicate what we want developers to build. Another is to establish a baseline so we can make sure we are on track to meet a commitment to the business. There are two distinct capabilities here, Communicate-Needs-to-Development and Evaluate-Project-Progress.
In many software development organizations a highly detailed document may not be the best way to accomplish either of these. Based on the nature of your organization’s projects and the level of clarity of the technologies and customer needs, these two capabilities will have different cycle times, different owners, and will interact with different capabilities.
The capability here is not Document Requirements. Documenting requirements is a means to an end. There is no business value in getting better at documenting requirements for the sake of documenting requirements. Conflict arises when the focus is on the “How” instead of the “What” and “Why”. Implementing practices or principles without a focus on purpose results in waste, conflict, and constraints to understanding. Taking the time to understand the actual capabilities and focusing on achieving the purpose will pay big dividends.