Attitudes Toward Delivering Business Value

Traditional software development projects are executed in a value-neutral setting in which:

  • Every requirement is treated as equally important
  • The delivery of technical components is seen as of equal importance to the delivery of usable systems
  • "Earned value" systems track project cost and schedule, not stakeholder or business value
  • A "separation of concerns" is practiced, in which the responsibility of the development team is confined to turning software requirements into verified code rather than delivering business value
  • The actual desired outcomes of the project are ignored in favor of implementing the largest number of requirements possible

No wonder so many projects fail to deliver the desired business results! Unfortunately this includes many iterative software development projects where the developers iteratively implement the requirements rather than delivering business value. Any management system that rewards things that are easily measured (like implementing requirements) without a clear and direct tie to business value delivered is headed down the wrong path.

Delivering value is not the same as delivering code: it is easy to deliver a lot of code without delivering much business value. The code delivered and tested must do something useful for the business. This is not the same as delivering what the business asks for - much of what is asked for is never used and delivers no business value. We clearly need a means for finding and implementing the requirements with the highest business value first, and separating wishes from real needs.

The key to understanding the business value derived is to map requirements back to the desired outcomes for the project: a requirement not related to a desired outcome is clearly not important to the business. The connection to iteration planning is that early iterations should implement requirements related to more important desired outcomes, with one clarification: technical risk cannot be ignored. This apparent conflict can be resolved by recognizing that desired business outcomes require that technical risks are resolved early because a technically infeasible solution is incapable of delivering any desired outcomes.

As a result, planning iterations entails choosing the right set of risks and requirements for each iteration to ensure that the iteration’s results make measurable progress toward the delivery of the desired business outcomes. As progress is demonstrated, as everyone can see that key technical issues are being resolved, and as the achievement of desired outcomes becomes increasingly apparent, confidence in success increases.

  1. Tom Morgan | September 27, 2010 at 3:41 pm Reply


    Desired outcomes is not about functionality, they are about delivered results. But the requirements for a system *are* about functionality. I like the approach Kurt mentions because it makes the desired outcomes concrete in the planning perspectives by mapping the requirements to them. The added benefit is that this, in turn, maps the desired outcomes to iterations. Nice!

  2. Janice James | September 22, 2010 at 10:14 am Reply


    A better question yet is “Have your customers indicated that they need that functionality?”

  3. Robin Goldsmith | September 21, 2010 at 7:00 am Reply


    The key is to realize that Value comes from meeting REAL business requirements deliverable _whats_, which need to be discovered, not dictated. Instead people focus on features requirements of the product, system, or software _how_ they presume they need. However, the product/system/software provides Value if and only if it satisfies the REAL business requirements, which often doesn’t happen because the REAL business requirements haven’t been defined adequately, generally because people think the roduct/system/software requirements are _the_ requirements. Simply tying product features back to desired benefits leaves too many gaps and oversights.

  4. Philippe Back | September 9, 2010 at 4:29 pm Reply


    Very true indeed.

    I like to ask the following question quite often:

    “How is the customer better off with that?”