Posts Tagged ‘Innovation’

Principle, Practice, or Purpose

Posted on June 6th, 2009 by Dennis Stevens  |  2 Comments »

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.


Posted on March 25th, 2009 by Dennis Stevens  |  No Comments »

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

Project Management, Product Management, and Agile

Posted on March 12th, 2009 by Dennis Stevens  |  3 Comments »

There is a lot of interesting conversation going on within the project management, product management, and agile software development communities. There is contention between (and within) the different communities regarding the value and benefit from the other domains. Sometimes one community is vying to prove their domain is superior to the others. Other times, a community is casting blame for limitations in their ability to perform to another domain. Much of the conversation is based on a limited understanding of what the other domains actually do. They also fall into the trap of generalizing a specific unpleasant experience to encompass the intent of the other community.

I believe this debate is counterproductive. At the end of the day, everyone’s interest should be to improve their organization’s ability to profitably create value for the customer. Each of these areas has something critical to contribute to this goal – but the benefits are only realized when the communities work together. I want to define a few terms, identify the overlap, and then suggest why this discussion is not just an academic exercise, but it an important part of the maturing of each domain.

First, some definitions:

Project Management

Let’s start with Project Management. The Project Management Institute has the following definitions of project, project management and project manager.

Project: A temporary endeavor undertaken to create a uique product, service or result.

Project Management: The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.

Project Manager: Person assigned by the performing organization to achieve the project objectives.

Project Management is not meant to be an obstacle to getting work done. In fact, the project manager is responsible for ensuring the project is successful.

Product Management

The Product Development and Management Association define product, product management and product manager.

Product: A term used to describe all goods, services, and knowledge sold. Products are bundles of attributes (features, functions, benefits, and uses) and can be either tangible, as in the case of physical goods, or intangible, as in the case of those associated with service benefits, or can be a combination of the two.

Product Management: Ensuring over time that a product or service profitably meets the needs of customers by continually monitoring and modifying the elements of the marketing mix, including: the product and its features, the communications strategy, distribution channels and price.

Product Manager: The person assigned responsibility for overseeing all of the various activities that concern a particular product.

So the Product has an ongoing aspect to it that the Project doesn’t. The Product Manager decides what needs to be built and also how the organization will sell it and support it.

A product has a life that lasts beyond any individual project.  The ongoing thing over at PMI is called a Program. Here is the PMI definition for Program and Program Management. Interestingly, PMI doesn’t define Program Manager in the Program Management standard.

Program: A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually, Programs may include elements of related work outside of the scope of the discrete projects in the program.

Program Management: The centralized coordinated management of a program to achieve the program’s strategic objectives.

Project Management Isn’t Product Management

So project management isn’t product management. Neither is Program Management, However, there are projects to execute in the modifying of the product, so project management processes matter in product management.  Here is a Venn diagram that describes the relationship.


If you aren’t good at making changes to your product or the capabilities in your organization that relate to your product, you won’t be a successful company. So project management isn’t product management, but there is overlap in practices and both are important to your organization. Great ideas with no execution aren’t valuable.

Agile Software Development

Finally, let’s go with the Agile Manifesto as a definition of Agile.

Manifest for Agile Software Development

  • Individual and Interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Despite the perspective of many in the project management and product management communities, Agile is also not intended to be no planning, no documentation, irresponsible software development. According to :

 “The Agile movement is not anti-methodology; in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.”

Agile is not Product Management

Agile is specifically about software development. In fact, the Agile Manifesto is short for the proper title of Manifesto for Agile Software Development. Agile is an approach to software development that includes practices and principles that can result in dramatically faster and higher quality (therefore less expensive) development of software. But the product is not just software. If the right features, communications strategy, distribution channels and price are established being faster, cheaper, and better at software development doesn’t matter. Product Management is critical to getting value from Agile Software Development.

Agile is not Project Management

 In very few cases is the product that is being sold to an organization’s customers just software. We’ve discussed the relationship of Project and Product Management above.  You need to be good at Project Managing all aspects of change to the product and the capabilities in the organization that support and are affected in any way by the sale, delivery, billing, and support of the product to the customer. Also, Agile isn’t concerned with Procurement – but procurement is important to the profitability of the company. And while iterations are a Risk Mitigation tool, Agile does not have a specific Risk Mitigation aspect to it.

Why this discussion matters

The following Venn diagram depicts the interdependency between these three domains.  Value is not delivered by any one of these domains. It is through an effective coordination between these domains that value is delivered to the customer. Value is identified, shaped, and then communicated to the customer by Product Management. Much value is created by the Agile development team itself. Value is created through aligning the other capabilities within the organization and often actually delivering the product to the customer through Project Management.



Let me quote Jim Highsmith from again.

“In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. “

Most of the organization’s that I have been involved with that are failing to deliver software to the business or the business’ customers are failing to receive value because of deficiencies in one or all of the domains in this discussion. Often, the deficiencies are the result of conflict and lack of coordination with another domain. Becoming great at one area, while remaining poor in another, is not value to the customer, the business, or ultimately to the members of the organization. 

The discussion we need to be having is not about how each domain contributes to problems for the other domain.  This is an interdependent problem, not one that has its roots in any one domain. Bunkering down, defending incompatible practices, focusing on local optimization at the expense of the business is not going to work. We need to work together to answer this question. How do we align the product management and project management practices with the rapid, incremental delivery of working software to optimize benefits for our customers and profitability for our businesses?

Redouble your Focus on Customer Needs

Posted on January 13th, 2009 by Dennis Stevens  |  No Comments »

I was reading about Oracles layoff of sales people and consultants and a recent blog entry in Innovating to Win came to mind. It discusses innovation strategies for the global recession. The first theme was

Redouble your focus on customer needs

When cutting out the waste, cost cutting has its place. But as Tom Peter’s taught us, you can’t shrink your way to greatness. Put as much effort into focusing on your customer’s needs. Here are three areas to think about how you can improve your ability to meet your customer’s needs.

Certainly this includes clearly aligning the features of your product or service with the problem you are solving for the customer. Many products and services have suffered from feature bloat. Bells and whistles have been added to compete against other offerings. I bet many customers would be willing to pay less for a product that simply met their needs. And less expensive doesn’t have to mean less profitable. Southwest Airlines may be an example of this approach.

Another place to focus on your customer’s needs is to look at the lifecycle of your customer’s interaction with your product. They may have to identify a need, select a solution, purchase the solution, implement the solution, maintain it, pay for it, upgrade it, and trade it in or dispose of it. Really focusing on the entire customer experience with your product (not just with you) can improve your ability to create value for your customer without an increase in your costs.

Finally, understanding how your customer uses your offering can lead to opportunities to add more value. There is the story of the CEO of a drill making company who stood in front of his board and proclaimed, “No one wants to buy our drills!” The board was stunned. The CEO continued, “The want to drill holes in stuff to build stuff. We need to figure out how to help them do that.” My customers typically aren’t actually interested in project management or software development or technology delivery. What they are interested in is more profitably creating value for their customers. My goal is to help them do what they are interested in through project management, software development, and technology delivery.

Everything your business does should be focused on profitably creating value for your customers. This starts with understanding your customer’s needs. Focus on the required features, the customer’s experience with the offering, and the context your costomer experience when working with your offering. Find ways to focus on improvements in these areas. Focus on cost cutting in anything that doesn’t profitably add value to your customers. 

2009…The Year of Leadership and Innovation

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

Times are tough for many businesses. Often, when the economy gets tough, management becomes very conservative. Everyone needs to buckle down and get in line. No one is going to rock the boat and point out flaws in an organization or management when there is a real risk of being laid-off. No one is going to strive for innovate behavior when management is so risk averse. People are afraid and feeling threatened – and will behave accordingly.

But that isn’t what is needed for businesses to thrive today. We need innovation and leadership in companies. We need to find innovative ways to drive down costs and meet the needs of customers. We need to focus investments into product, technology and process innovation that advanced the company’s strategy – not where it is politically expedient or at the squeaky wheel. When companies need to cut jobs, it takes leadership and vision to make the cuts that will best position the company for the future – not the cuts that easiest to sell or that don’t upset the order of things. Then we need inspirational leadership to overcome fear and to increase employee productivity.

There is no room for reckless management. This is not the time to operate from fear. The companies that figure out how to become stronger over the next year and position themselves for growth in the near future will be the winners. 2009 is about Leadership and Innovation.