Today I am discussing the tasks from the BABOK associated with Requirements Management and Communication. These are the tasks Ensure knowledge gained through business analysis activities throughout the effort is shared among the team. There are six tasks associated with Requirements Management and Communication. 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.

Requirements Management and Communication: BABOK® Tasks

Prioritize Requirements

Organize Requirements

Specify and Model Requirements

Define Assumptions and Constraints

Verify Requirements

Validate Requirements

Agile Requirements Management and Communication

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.

This post is going to go back over the past month’s posts and bring them together into a model I can use to discuss Big Agile. I took me a while to noodle this out so I haven’t posted in over a week. This approach is based on over two decades of improving performance in development organizations. The last decade has been spent working to explicitly articulate what I’ve done to consistently deliver results. It is amazing how much you learn when you take concepts practiced unconsciously and write them in a (relatively) concise format.

Enterprise Agility

Many companies are dependent on technology to be competitive. Either because they deliver technology as their product or because technology enables the processes they depend on. For those companies it is important to be able to operate faster than their competition.  This requires not only the ability to rapidly deliver technology – but the ability to adapt their organization.  This is the concept of operating within your competitors decision cycle. The model I use to demonstrate this concept is John Boyd’s O-O-D-A model.

This is Enterprise Agility, when the enterprise has learned to leverage technology and change management to develop an energized workforce frequently delivering value that meets the emerging needs of the customer.

Three Concepts for Achieving the Agile Enterprise

I am going to build on three concepts in showing how to build Enterprise Agility.

1. Theory of Constraints. You can’t get there all at once. It is necessary to decide where to focus. You have to develop the underlying capabilities from the bottom up. If you can’t produce quality product, the best ideas in the world will run into problems. The way of thinking about problems covered in the management system the Theory of Constraints provides the method for deciding where to focus. Identify the current constraint, get the most out of the capability that is the constraint, subordinate the system to the constraint, elevate the constraint, and then continue to pursue this cycle. This “Process of On-Going Improvement” is applied to the flow of value to the customer.

2. Creative Solution Finding. Once we understand where to change we need to understand what to change to. We have to apply a method to lead the overall adoption effort that supports aligning the capabilities with the overall goals of the organization. The stages of Creative Solution Finding are useful for identifying the situation specific approach to developing this road-map. There is no magic sauce for developing this road-map. By applying the seven principles, along with a knowledge of applicable best practices, a useful road-map that fits both the process and social context of the Enterprise can be developed.

3. The Learning Organization. Technology development efforts are knowledge based efforts. As such, they are performed through a social construct. To improve the performance of software development we have to not only improve the methods of development, we have to improve the performance of the social construct. First the individuals on the team must be willing to change. While the People Design principle in Creative Solution Finding will help prepare individuals for change, their personal fears and concerns must also be addressed. Once the constraint is identified and a road-map for improvement is developed, the learning organization concepts in the Fifth Discipline are relevant. The right individual competencies must be developed on the team to do the job (Personal Mastery and Mental Models).  The team has to be functioning well together (Shared Vision and Team Learning).  And the Team has to be functioning in a way that is aligned with the goal of the overall system (Systems Thinking).  The primary tool used to influence a social construct to create change and to improve performance is the conversation.

Discussing Big Agile

So the approach is to take the Big Agile capabilities, (1) provide insight to identify when a specific set of capabilities at a level of scaling are the current constraint, (2) leverage the solution finding model and best practices to define/refine the roadmap to move toward,  (3) and then identify the competencies to develop and conversations that are necessary to execute the change.  Then continue the cycle continuously.

This is the Big Agile improvement approach. It takes a model that I have been applying for two decades implicitly and evolving explicitly for the last decade. Clear direction combined with appropriate best practices and an effective adoption approach. All that’s left now is to build out the details of the capabilities, when they are a constraint, how to select appropriate best practices, and the conversations and change approach at each level of scaling for the model.

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.

Scale (skeyl)

1. one of the thin, flat, horny plates forming the covering of certain animals, as snakes, lizards, and pangolins
2. a balance or any of various other instruments or devices for weighing
3. a succession or progression of steps or degrees; graduated series:
4. a succession of tones ascending or descending according to fixed intervals
5. the proportion that a representation of an object bears to the object itself
6. Australian Informal. to ride on (public transportation) without paying the fare
7. Dentristy scal•ing. The removal of calculus and other deposits on the teeth by means of instruments
8. 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.

Agile (aj-ahyl)

1. quick and well-coordinated in movement
2. 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.

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 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.

I want to share the presentation I did in the Open Jam at Agile 2009. I got good feedback from some of the thought leaders there like David Anderson, Chris Matts, Eric Willeke, Chris Shinkle, and Mike Cottmeyer.  Ok, enough name dropping. A common theme at Agile 2009 was, “Now that we are pretty good at small teams developing software, what’s next?” One of the answers is making sure the developers are working on the stuf that provides the greatest value back to the organization. A lot teams aren’t very good at this.

If your projects are anything like most of the development projects I’ve been on you are likely to run into cost and time pressure near the end. Our story might be something like, “We can’t meet your needs for the planned cost or by your expected time-frame. We have been telling you from the beginning there was uncertainty in the requirements and that development is fraught with risk. You will just have to pony up.” Customer’s don’t like this but they have come to expect teams to be late and over budget.

If you had the foresight and tools to understand how to focus on eliminating risk on the front end and then building the highest value things first, you can go to your customer with a story like this, “Even though there is a lot of uncertainty in the requirements and exactly how we would build the software, we have a working product that meets all of your most important business needs. In fact, I bet you didn’t know that over half of all the technology built is never even used in the end. We would love to continue to build out the remaining features after we get this adopted by your customer, but we bet addressing what they think is important will be more valuable than building out elaborate and potentially unused features.”

I have used this approach on about a dozen efforts and have found that it promotes far better communication between the team, product owner, and customers. It provides clarity on what needs to be build, why it needs to be built, and how we can do acceptance testing on what is built. It is also low friction to maintain if the product or project strategy changes in flight.  It is a sustainable artifact that connects Ivory Tower discussions about business value and risk to the developers context.

Typical Business Analysis techniques have high transaction costs and high coordination cost while still not getting the key points across to development. We end up with lagging risk, too much rework, missing critical requirements, lack of testability, and over engineered products. This is very expensive – both in terms of what is spent to deliver to our customers and in terms of meeting the needs of the customers. Once we change the conversation from “What can we get done this week?” to “How can we optimize business value and manage risk responsibly?” we are on the right track to Feeding this Agile Beast.

There continues to be discussion about Scrum (as a brand) vs. Kanban (capital K) vs. Crystal vs. FDD, etc. If fact, I received a comment today on a March post discussing the Scrumbut test. My comment became to long and is so relevant to recent discussions that I turned it into a blog post. From my perspective these method wars tend to fall into “How Trap” discussions. How Trap discussions are not about specific outcomes you are trying to achieve and developing a situationally specific approach to achieving those outcomes.

Take a look at the Scrumbut test I learned about from Jeff Sutherland. Whether you are doing (or even like) Scrum – when viewed through an outcome lenses, these questions lead to discussion regarding clearly important outcomes. Below, I list the question category from the Scrumbut test, then the outcome that is desired from the practices described in the Scrumbut test, then a hopefully clarifying description.  The practices are detailed at the Scrumbut link.

Question 1 – Iterations: Limit Work in Process – don’t start anything you can’t finish

Question 2 – Testing within the Sprint: Maintain Code Quality – Shorten quality feedback loops to zero to maintain code quality and reduce the waste of rework

Question 3 – Agile Specification: Communicate Business Needs to Development – Ensure developers understand outcomes while minimizing coordination and transaction costs, maintain traceability to business need

Question 4 – Product Owner: Maintain Product Roadmap – The business communicates a plan of what is being built

Question 5 – Product Backlog: Prioritize Investments Based on Return – the business prioritizes work based on a current understanding of business value

Question 6 – Estimates: Provide Meaningful Effort Estimates – Understand rate the team can produce work to support planning, investment decisions, and customer commitments

Question 7 – Burndown Chart: Communicate Release Schedule – Be able to predict content and timing of future releases. This clarifies corrective action, next most valuable investment decisions, marketing decisions and customer commitments

Question 8 – Team Disruption: Maintain Productive Work Environment – Management understands and supports the focus on rapid delivery. Trust is established that the team will be able to meet current and future commitments.

Question 9 – Team: Develop an Empowered Team – The team feels empowered to make decisions about how to move forward. Management has provided sufficient guidance and direction that they trust the team will make operational and tactical decisions aligned with the best interest of the business.

Yes, Jeff has a brand he is protecting. If you think you are doing Scrum and you aren’t achieving these outcomes then you aren’t doing what was intended. Bad Scrum and Scrumbut hurts the Scrum brand. In fact, since Scrum is a dominant Agile brand, it hurts all of us trying to move Enterprises towards improved software agililty.

But, Scrum isn’t the only way to achieve these outcomes. I can map these outcomes to mature implementations of XP, DSDM, FDD, Crystal and Kanban (etc.). Now the interesting conversations sound like –

• In what situations does Kanban reduce transaction and coordination costs more than Scrum?
• In what situation does one method lead to better adoption over another? Why?
• In a specific organization, what approach to developing empowered teams and upstream trust will be most likely to succeed?

The outcomes described in the Scrumbut test can be achieved by applying specific strategies that are consistent within an organization’s environment. When these outcomes are adopted development teams tend to become more mature, better at delivering software (many times dramatically), and improve their work environment. Regardless of method, you need to be focused on the outcomes that result in improvements in productivity and find the way that works in your organization to adopt and sustain the outcomes.

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.

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

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.

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.

Ric Merrifield, led the development at Microsoft of what has become the Microsoft Business Architecture Service offering. He is also a coauthor of mine on “The Next Revolution in Productivity”, a June 2008 Harvard Business Review article focused on case studies that highlight needs of the organization and the opportunity to rethink business operating models before making major technology changes. Under Ric’s leadership, I was a significant contributor to the development of the Business Architecture offering and performed several of the projects that serve as case studies in the HBR article. We have spent a lot of time together over the last five years and he is a really smart guy and a friend of mine.

The concepts we have been leveraging revolve around using capabilities to help organizations clearly connect their business model to customer value. Typically, executives don’t have a good view of this except through their intuition. Organization charts are about the chain of command. P&L’s provide a historical view but a limited in what to do to improve performance. Process charts are too granular and change frequently. Technology architecture doesn’t help clarify how the business model connects to delivering customer value. Using the capability model based approach we can describe “what” a business does and “why” it is important without getting tied up in “how” they do it.  This approach overcomes the limitations of the current views most executives have.

This is important stuff to be talking about and I have been harassing Ric for several years about getting online because we need to have a broader discussion around the concept of capabilities or “hows”. Ric finally signed up for Twitter about three months ago, you can follow him at ricmerrifield. 

He has also written a book “ReThink: A Manifesto for Cutting Costs and Boosting Innovation” coming out in May (I am mentioned in it so ;-D). The book is endorsed by guys like Jim Champy, Robert Scoble, and David Anderson so you know it’s good. The book guides readers through a strategic re-think to efficiently set priorities, achieve goals, reduce costs, and unlock hidden value in today’s challenging business environment and set a course tailored for them. I will let you know 

And now, Ric has launched a blog at http://ricmerrifield.com/blog/. This is an important concept and it matters to business leaders, project managers and technology agilists.  We need to get involved in this conversation and help shape it and spread the work. Rick has his first two posts up.  Please go read them and add Ric to your blogroll. 

Here is an SOA Definition from the SOA Working Group of the Open Group.

Service-Oriented Architecture (SOA) is an architectural style that supports service orientation.

Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.

A service:

·         Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports)

·         Is self-contained

·         May be composed of other services

·         Is a “black box” to consumers of the service

An architectural style is the combination of distinctive features in which architecture is performed or expressed.

The SOA architectural style has the following distinctive features:

·         It is based on the design of the services – which mirror real-world business activities – comprising the enterprise (or inter-enterprise) business processes.

·         Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.

·         It places unique requirements on the infrastructure – it is recommended that implementations use open standards to realize interoperability and location transparency.

·         Implementations are environment-specific – they are constrained or enabled by context and must be described within that context.

·         It requires strong governance of service representation and implementation.

·         It requires a “Litmus Test”, which determines a “good service”.

There are some really important distinctions about the SOA definition.

SOA is not technology – it is a way of thinking about architecture. There are various standards around services that lead to interoperability, but these standards are technical standards – they are not SOA.

SOA discussions are about business outcomes – not about technology. One really important thing is to identify and deliver services that provide business value. We don’t need to be discussing SOA with the business – they just don’t care (hence its demise). We need to get architects thinking about the business, and what the business does to create value for the customer. Then that can be translated that into a technology solution.

I believe that a business capability-based assessment of the company is a great way to facilitate this discussion between technology and the business. A business capability is a something the business does which produces a specific result or outcome. A business model can be viewed as a network of business capabilities. When viewed this way, you can identify those capabilities that need to be changed or improved to accomplish the business strategy. From these capabilities, you can identify services that are valueable to the business. Now you are having a business discussion that aligns your business model to the technology.  And you can align your technology investments with the best interest of the business.

You can get a copy of “The Next Revolution in Productivity” to look at an approach for doing this. Either go to the Harvard Business Review website and buy one, or get one for free by registering at http://www.synaptus.com. (Official Disclosure: I was an author on the paper). I also have a tool set I will share with individuals who want to help improve this approach.

I will be writing more about business capability analysis as a way of identifying where to focus improvements in the business, and how to identify where SOA is a good approach. I would appreciate feedback on the article and the capability analysis approach.