Posts Tagged ‘Requirements’

The Agile Bargains

Posted on December 2nd, 2009 by Dennis Stevens  |  No Comments »

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.

image

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.

  1. Articulate Purpose and Outcome
  2. Establish a Shared Language
  3. Provide a Stable View of the Business
  4. Support Progressive Elaboration
  5. Testable
  6. 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.

Risk

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.

Making Agile Requirements Work-NO 6

Posted on December 1st, 2009 by Dennis Stevens  |  No Comments »

image

On many software development projects, teams that are interested in getting started writing code early start by building the things they understand first. While this gets code started and in front of the customer as soon as possible, it isn’t necessarily the shortest time to value. This approach also sets the team up for the later stages of the project to be wrought with uncertainty and pressure from the business.  Two keys to successful Agile projects are focusing on early learning (mitigation of risk) and then rapid time to business value.  This is achieved by prioritizing the order that work is performed by the team.  When requirements analysis doesn’t clearly communicate the areas requiring risk mitigation and clearly identify those requirements that are most valuable to achieving the business outcome, then the team can’t appropriately prioritize the work.

Requirements reflect business value and risk

On most software development projects, not every requirement is equally valuable to the business. Some requirements are core to achieving the business outcome expected for the project and some are critical because they are  deliver on the brand of the business. But others, while valuable to the business, may address edge conditions or be nice to haves. Requirements need to be prioritized so that unknowns are addressed early, then higher business value requirements are addressed, then the remaining requirements. Part of the requirements analysis process should include an assessment of business value and risk.  If the prior principles have been applied, but the requirements are not worked with an eye toward risk mitigation and business value priority, the team will not be optimizing investment or time to value.

Because software development has some level of uncertainty, it is likely that a project will reach the end of its budget or time estimate before delivering on all the requirements expected. If you haven’t prioritized business value and risk, you may have to report, “We are really, really close. For just a little more investment or time, we can deliver something that meets your needs”. It is far easier report at the end of the time constraint or budget and say, “We have delivered on the most critical features and addressed the primary risks. At this point you can use the system we have delivered to address (most of) your business need. However, if you want to continue to invest, we can add additional capability.”

Many projects wait until the project is in danger to begin the trade-off analysis. Early work is done to a great deal of detail and late work is rushed through. The time to triage the requirements is at the beginning of a project. Then at each stage of elaboration, the detailed requirements should be further triaged. Requirements must reflect business value and risk – and the work should be prioritized based on these factors.

Making Agile Requirements Work-NO 5

Posted on November 30th, 2009 by Dennis Stevens  |  1 Comment »

I hear a lot about emergent outcomes, and progressive elaboration, and self organization on Agile projects. These are slippery slope concepts, and far too often are applied irresponsibly. Emergent outcomes don’t mean we have no idea what the business is paying for – they have a pretty clear idea of the problem they are investing to address. Progressive elaboration doesn’t mean the team will figure out what they are doing as they go along – it means they will gain clarity on mitigating risks and meeting the technical and customer experience aspects of how to solve the business problem as they move forward. Self organization doesn’t mean the team can work on whatever it wants – it means that the team collectively decides the best way to focus their efforts and skills on a specific effort.

The business is willing to make an investment, to solve a specific problem, within a specific timeframe. In the first four posts of this series we discussed that the way that requirements are captured should express the purpose and outcome, they should establish a shared language that communicates context and intent, is should be a stable view of the problem, and it should support progressive elaboration. In addition, Agile requirements include clarity on what "done" looks like. Agile requirements also include identifying the impediments to getting to "done".

Agile Requirements should be Testable

Not having a clear outcome does not make a development effort Agile, it makes it irresponsible. If we don’t communicate requirements in a way that we can ensure the requirement is accomplished then we are being unclear about the value proposition we are trying to achieve. By testable, we don’t mean the “how” of implementation, we mean understanding what is not available or performing adequately what will be different after the requirement is delivered. If the business can’t communicate to the developer how to make sure they know when they are done – the project will meander. Even with lots of customer involvement during development – it is likely that development will be less focused than it could be.

What does it mean to be testable? I have a client that had its development team develop a “data-warehouse” to provide management reports. The developers spent eight months defining all the data in the business, developed programs and processes to consolidate the data into a central repository, and started building reports against the data. Eight months later the manager’s biggest problem is that they don’t have the information the need to manage the business. How is this possible? The business wanted a data warehouse and they got one. They have been intimately involved in the data gathering process. They have been asking for reports through the system for months.

The problem is that no one stopped to understand how they would test the requirement. How would they know if the business need was met? The business need is met when the manager had the information needed to manage the business. When the requirement is communicated as a granular “how” – and there is no way to verify it has met the need of the business – the business is unlikely to get what they expect.

Making Agile Requirements Work-No 3

Posted on October 29th, 2009 by Dennis Stevens  |  No Comments »

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:

  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective
  2. 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.
  3. 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.

Unstable

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.

Agile BABOK® Wrap up

Posted on October 21st, 2009 by Dennis Stevens  |  No Comments »

This is the final post in my review of the impact of Agile on the tasks within the knowledge areas of the BABOK®.  There are some interesting findings from this exercise. The implications are that while some business analysis tasks are performed within the development team, the business analyst role itself is more strategic and challenging on agile projects. A clear understanding of the BABOK tasks and how they should be addressed on Agile projects will dramatically increase your ability to deliver value through Agile projects.

So, What’s New?

First off, the business analysis tasks are not just aimed at documenting requirements. There are three primary targets of analysis activities. Many tasks address the features of the product. These are aimed ensuring requirements are elicited, communicated, and the solution is verified. There are business analysis tasks aimed at understanding organizational readiness and transition requirements. Finally, there are business analysis tasks aimed at understanding and improving the ability of the organization to develop and deliver the solution.

Secondly, all the tasks are still necessary. However, unlike a traditional project, where many of the analysis tasks are performed up front, they are performed continuously throughout the project. The requirements for the solution, the ability to deliver, and the readiness of the organization are evaluated incrementally throughout the project and the approach is adapted to improve fit and performance.

Finally, the understanding of requirements, organizational readiness, and development capabilities is progressively elaborated throughout the project.  In Agile, the development team itself performs detailed business analysis activities within the development iterations. The business analyst continues to operate in front of and after the development efforts. Lightweight requirements documentation combined with an emerging understanding means the business analyst become an advocate for the product. They collaborate with the team to ensure a shared understanding unfolds. The business analyst also facilitates the understanding and implementation of improvements in the business analysis and organizational readiness processes.

Summary of Business Analysis Knowledge Areas

Business Analysis Planning and Monitoring.  The tasks in this knowledge area are still primarily performed on the front end. The team will agree on the approach it will take in business analysis tasks. This means agreeing on who and how. All the task purposes in the BABOK still need to be planned – but planned to support the cadence of the team and the emergence of understanding through the project. The way the business analysis tasks are performed are not cast in stone, they will be updated through inspection and adaptation throughout the life of the project.

Elicitation. This knowledge area occurs continuously in a progressive fashion and responsibility for the product requirements changes hands during each iteration.  These hand-offs associated with the various levels of elicitation can contribute to lost knowledge and increased transaction costs.  An approach that ensures continuity of understanding is critical.

Requirements Management and Communication. The existence of Requirements Management and Communication in a single Knowledge Area demonstrates the closely held traditional belief that documenting and tracking something is the best way to communicate it. It is important that the method of documenting requirements at the higher level is lightweight while still facilitating understanding, focus and priority. In Agile projects, communication should be viewed as completely distinct tasks. At the detailed levels, there is a transfer of context, purposes, and outcomes requirements that is best performed through conversation between the customer and the development team.

Enterprise Analysis. The business analyst will still carry primary responsibility for understanding organizational readiness, transition requirements, and solution verification.  They will need to communicate findings from releases back into transition requirements to improve release performance. Gaps in the fit of the solution will feed back into the requirements backlog. Enterprise Analysis is very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value.

Solution Assessment and Validation. These tasks happen continuously in a progressive fashion. The Big Solution Architecture will still be developed with input from the Business Analyst as well as Architects. The Business Analyst will need to understand and address the impact that progressive elaboration has on the transition requirements.

Requirements Analysis. Prioritization and organization of requirements happens as part of backlog prioritization. The business analyst should make sure that business value concerns and risks associated with assumptions and constraints are clearly understood here. Like Enterprise Analysis these tasks are very strategic, often outside the scope of the typical Agile development team (presumed to be understood by the Product Owner), and are critical to the team’s ability to burn down risk early and get to business value fast.

Missing Tasks

I believe there are at least three areas regarding business analysis on Agile projects that are not addressed by the BABOK.

Enrolling Stakeholders involves making sure everyone understands how they will participate. Just documenting a process or developing some templates don’t ensure appropriate engagement.  Stakeholders may play a role making sure shared understanding of the product requirements exists, they may be responsible for development process feedback, or they may need to participate in the transition of the solution.

Understanding Requirements is the new task or set of tasks that deal with generating the shared understanding of context, purpose, and outcome that is necessary for successful projects. Since the understanding of what is being developed and how it is being developed will emerge over the course of the project specific tasks must be in place to establish this shared understanding.  This may sound like a subtle extension of communicate requirements but this is social in nature and is fundamentally different than the push of communicating requirements.

Organizational Learning extends Enterprise Analysis. Not only does the readiness of the organization to use the product need to be reviewed, the ability to develop, deliver, and support the product needs to be evaluated. This task includes the introspection, retrospectives, operations reviews, and outside review of best practices that the organization performs to improve its ability to use and deliver solutions.

Agile Business Analysis Summary

The common concept that Business Analyst’s add no value to Agile projects is flawed. It is true that some of the detailed business analysis activities will be best served through direct interaction between developer’s and the customer. The high level planning and coordination around these direct interactions should not be abandoned but should be managed to facilitate focus on business value and shared understanding while minimizing transaction costs.

Additionally, there are many critical business analysis tasks outside the scope of the development team. Particularly, the tasks involving Solution Validation, Enterprise Analysis, and the inputs to Requirements Analysis are very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value. A clear understanding of the tasks and purposes in the BABOK® demonstrates the strategic nature of Business Analysis tasks, highlights where the tasks should be performed within the Agile development team, and will increase the ability of the development team to achieve its objective of rapid delivery customer value.

Agile Requirements Analysis

Posted on October 20th, 2009 by Dennis Stevens  |  No Comments »

Today I am discussing the tasks from the BABOK® associated with Requirements Analysis. These are the tasks to organize, prioritize, and model requirements and risks. There are six tasks associated with Requirements Analysis. 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.

Prioritize Requirements

Purpose Agile Impact
Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements. In Agile, requirements are progressively elaborated. Throughout the Elicitation Task, Elicitation results are progressively broken down and elaborated. At each point of elaboration the constituent parts need to be evaluated and prioritized based on business value contribution and risk burn-down.  In Agile, this is not a one-time up front activity. This happens throughout the life of the project on all remaining work and new work brought in from learning about the product.

Organize Requirements

Purpose Agile Impact
The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives. In Agile, it is important to organize requirements to minimize dependencies between feature sets. This reduces complexity and risk and improves testability at the business value level. Since requirements are progressively elaborated, this can be shown as the Solution Architecture from a business standpoint. Expect this Solution Architecture to evolve based on feedback from the customer once they start to experience the product. Requirements should be organized around business value – and not technical implementations. Only within component teams – where the business value arises from delivering enabling technology – is it appropriate to depict technical requirements. Even then, these requirements need to be prioritized and filtered based on risk burn down and business value contribution.

Specify and Model Requirements

Purpose Agile Impact
To analyze expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models. At different levels of elaboration there are different methods for specifying and modeling requirements. The approach should support progressive elaboration, is adaptable to change based on learning, and doesn’t box in the team to solutions too early.  It should also ensure that intent and intended business value is communicated consistently through the elaboration.  Agile teams tend to use Stories and Tasks at the lowest level of decomposition. These Stories and Tasks can be supported by detailed documentation and use cases. It is becoming increasingly common for acceptance tests to be produced as part of specifying and modeling the requirements.

Define Assumptions and Constraints

Purpose Agile Impact
Identify factors other than requirements that may affect which solutions are viable. On Agile projects this is handled through a risk management approach that treats risks as stories within themes. Risk mitigation activities are prioritized along with stories and burned down and re prioritized as they stories are performed. This is typically produced by the business analyst and project manager along with the team, prioritized by the product owner, and performed by the team.

Verify Requirements

Purpose Agile Impact
Requirements verification ensures that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work. Requirements are verified by the team during the project. Through retrospectives and operations reviews the team may decide to modify the level of detail to or the method of specifying and modeling requirements to improve the performance of the team.

Validate Requirements

Purpose Agile Impact
The purpose of requirements validation is to ensure that all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need. Requirements are verified throughout the development and delivery of the solution through continual involvement of the product owner and customer. This happens at release planning, iteration planning, during development, and at customer acceptance.

Agile Requirements Analysis
All of the tasks in Requirements Analysis are important on Agile projects. The primary distinction in this Knowledge area is the support for the emergence of the solution over time. Particularly interesting is Define Assumptions and Constraints. While many Agile teams focus on the impediments to delivering code, they fail to manage the bigger risks and constraints associated with getting to business value.

The Big Agile Learning Framework

Posted on September 9th, 2009 by Dennis Stevens  |  4 Comments »

If we accomplish one thing in Big Agile, we hope it will be to provide a way for people to think about what they are doing and create a learning framework for being able to do it well and take it to scale.

We don’t want to try to present the one right path you have to follow – because we think each situation will require distinct strategies.  But we also want to get beyond the intuitive approach. Just saying, “Eliminate waste, identify and remove impediments, and write code better” is not enough guidance to create a reliable and sustainable approach that can be scaled .  So, what is a structured way to think about being good at Agile that supports getting big? Part of the answer is to focus on outcomes and purposes using capabilities. But how do we apply these and where do we start?

First off, teams are the organizational units that actually produce value.  So  getting small teams highly productive is the right place to start.  Then, as we scale, the principles that make the small team function well scale into different instances of the same principles. The objective is to add the least amount of overhead possible at each order while maintaining the productivity of the small teams.

Today, I present the (draft) Big Agile Learning Framework. This reflects the approach  I have intuitively used when approaching this problem. The three dimensions are Value, Velocity, and Context.  The capabilities of the organization operate together in an interdependent way.  Understanding how each one plays in this model, and how they impact each other, is a key to developing situation specific strategies for taking Agile to the Enterprise.

The Big Agile Thinking Framework

The Big Agile Learning Framework

Value, Velocity, and Context

Value: What the product development team provides back to the business that the business might sell to an actual customer.

When we look at value, we want to identify what Jack Welch called the value nub – the intersection where low-cost and just-the-right-features intersect. Moving up on the value axis means moving towards the nub. In Agile, we leverage the ability to get a working product to the customer frequently to continue to narrow in on the value hub. This helps us reduce the costs and risks associated with a granular up  front requirements effort.

Velocity: The rate that work is moving toward its objective.

Confusion over the distinction between speed, utilization and velocity is a common problem. Velocity is speed in one direction. The car driving 60 mph on a straight road has much higher velocity than the one going 60 mpg on a winding road.In Agile we increase velocity through finishing what we start, coordinating hand-offs to remove delay, improving quality, and continually removing waste from our processes.

Context: The environment that the team operates it. It is shaped by the team, the organization, the goal of the effort, and the sphere of influence of leadership.

Software development is a knowledge-based endeavor.  People need room to think and innovate.  Difficulties in the context can compromise efforts to improve Value and Velocity. In Agile we improve context through commitment to a productive environment, empowered teams, disciplined compliance with the team standards, working toward individual mastery, bringing in external knowledge, and managing expectations.

Each of the dimensions in the learning  framework are interdependent. Let’s take the capabilities around requirements as an example. In once case, we put in an up front focus on detailed requirements. We think they are perfect and they take a long time. So the capability is high on value but low velocity. As we move along on the project, errors in the original assumptions and evolving customer preference degrades the actual value, moving the capability down on the value axis. If we take an Agile approach, Agile recommends a lightweight, progressive elaboration approach to requirements. This would be farther right on the Velocity axis but potentially not as high on the Value axis. Over time, as we uncover specifics and move towards the value nub, the capability raises on the value axis. We also know when to stop adding things not valued by the customer – so we don’t begin to slide down the value axis again. Experience in software development shows this is effective, but the organizational context has to allow for this approach.

The Thinking Framework is a way to frame the development of strategies as we scale. As we develop situation specific strategies to scale Agile the way that we can impact Value and Velocity become more complex But keep in mind that we must not sub-optimize small team productivity. Top down approaches have not been consistently successful in scaling agile up into the enterprise. Just replicating the same practices up through the organization hasn’t worked either. Basing our work on capabilities and leveraging the thinking framework, we are able to develop appropriate strategies.

Getting to Business Value

Posted on August 22nd, 2009 by Dennis Stevens  |  1 Comment »

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.

samplefindings

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.

Capability Analysis – Start with Business Value

Posted on August 14th, 2009 by Dennis Stevens  |  7 Comments »

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.

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.

  1. Identify the capabilities within in your business
  2. Identify the capabilities most critical to your company’s success (Business Value)
  3. Identify the health of the business capabilities (Performance)
  4. Identify the business risk and technical risk associated with the capabilities (Risk)
  5. 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.

Capabilities

capability-breakdown

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)

Prioritize Opportunities

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.

Visual Tool

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.

capability-sample

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.