PM Articles > Alan S. Koch > Quality = Business Value

Quality = Business Value

Part 2: Business Value as the Measure of Quality

by Alan S. Koch, PMP

What do we mean when we use the word "Quality"? In part 1 of this 2-part series, we explored the most common definitions of quality to understand how they fall short. Specifically, a product or service is "high-quality" if it…

  • Conforms to Specification
  • Satisfies Users' Needs
  • Implements "Best Practices"
  • Is produced using defined processes
  • Is acceptable to the customer
  • Is driven by the customer
  • Fits cleanly into the operational environment
  • Does not fail in any serious way

Having done this, we are now ready to address the emerging new definition:

Quality is Delivering Business Value

As we do, we will see that it borrows the high points from each of the common definitions while leaving the baggage behind.

What is "Business Value"?

Every project must be justified in order to be approved and funded. Some of us as Project Managers are involved in this justification process, and others of us are given responsibility for projects after they have been justified and approved. But in either case, the justification should have been made and documented.

In most cases this justification can be summarized in terms of Return on Investment (ROI). The project requires some level of investment of money, effort and time, and that investment is worthwhile because it will pay back a return that is worth more than that investment. Sometimes that payback is monetary, so it can be measured more or less directly against the investment. (Invest $x so we can save $5x.) Sometimes the payback not monetary, or not primarily monetary, but the project is worthwhile because the decision makers deem that payback to be valuable in some other way. (Invest $x so we can improve customers' experience.)

So, while the Scope statement in our Charter calls out that the project will build X, do Y, and achieve Z, the "Business Value" is the net benefit that will be realized by the customer, and on which the project was approved and funded. A description of this expected Business Value should be included in a good Project Charter. It may be called the "Project Objective" or "Success Criteria," or something else. (But beware that those identifiers do not guarantee that they are talking about Business Value!)

If you find that Business Value has not been laid out in your Project Charter, your first order of business is to find out from the key stakeholders what is the Business Value they are expecting, and to document it as a part of your project's driving documentation.

How is "Business Value" measured?

We are used to measuring things on our projects. We can count requirements satisfied, or defects found. We can measure system performance and project Earned Value. And we can compute Schedule Variance and Cost Overruns. But the concept of Business Value is different from those.

The things we normally measure on a project are the "nuts and bolts" of what we are doing or building. But Business Value is on a different plane. Measuring Business Value involves stepping away from the details of project activity and looking at what is being done from the customer's perspective. It requires understanding what they are expecting from the project and why that result is important to them.

Sometimes the customer's statement of Business Value tells us precisely how to measure it. If the purpose of the Order Management System Upgrade project is to "Enable the sales department to process 50% more orders per day without increasing staffing levels," then there is no question about how to measure it when the upgraded system is deployed.

On the other hand, if the purpose of the Website Redesign project is to "Enhance customers' experience," we are left with many questions about how to measure it. The only way to get answers to those questions is through discussions with our key project stakeholders to understand their expectations. For example, if surveys of customer opinions are performed, they could provide a basis for measuring if the project has succeeded. Or perhaps there are specific features or capabilities that customers have been requesting. Perhaps there is a competing website that can stand as our benchmark.

In the end, we must measure the value produced by our project in the same way that our customer does. And for many of us, that is the crux of the paradigm shift. A successful project is no longer seen as one that merely delivers on time, on budget and with certain quality levels. Rather success means ensuring that our customer receives the value that they need as measured from that customer's perspective.

How Do We Deliver Business Value?

Even if we agree that delivering Business Value is our purpose, we are still left with a significant problem. How can we ensure that we are progressing toward that goal while we are in the project? Rarely will our customers' assessment of Business Value be possible before the project is over. So how do we measure our progress?

Taking a page out of the Agile playbook helps with this. The more collaboratively we approach the project, the more opportunities we will get to test our understanding of our customers' view of value, and the more opportunities we will have to get material feedback from them.

For example, after translating the project needs into a list of deliverables, we need to discuss that list with our customer. Is the list complete? Is it fully aligned with the Business Value the customer is expecting? How does each deliverable support that ultimate value? Asking these questions does far more than assure that the deliverables list is appropriate. The bigger win is the way our own understanding of Business Value (as estimated by our customer) will grow!

As we finalize the requirements, we need our customer to articulate how each of them enables the Business Value they expect. In addition to being a great way to validate the requirements, this will arm us with the customer-centric view that will enable us to translate each requirement into something that contributes to Business Value. And it will make it more likely that we will build the right product.

But "more likely" isn't enough. How to we ensure that we are actually progressing? Again, by working with our customer. Any time we build something that customers will be able to recognize and evaluate (like a component of the User Interface, or a data transformation), we get feedback on it. As the system becomes more and more complete, we will be able to demonstrate bigger chunks of it, and get better and fuller feedback on it. "Is this what you need?" "Will this work in your business process?" And the ever-present, "How will this support your realization of the Business Value you need?"

This kind of interaction on a regular basis will ensure not only that there are no unhappy surprises at the end of the project, but it will build a more positive relationship between customer and project team in the process.

Won't They Keep Changing Their Mind?

There is always the fear that this sort of unfettered visibility in to the project will lead the customer to continually escalate their demands. Although this is a possibility, it can be mitigated in two ways. The first is the observation at the end of the previous section: A more positive relationship contributes to more reasonable behavior. One of the major benefits of close interaction between customer and project team is that the customer quickly comes to realize that nothing is free.

Which leads to the other mitigation. Remember what we said at the beginning about Business Value and project justification! The project is only worthwhile if the value delivered exceeds the investment. Escalating demands mean escalating costs, which reduce ROI. When this dynamic is highlighted, the customer will temper his/her demands. But be prepared! If adding something to the project will improve the Business Value by more than it costs, it should probably be done!

What of the Traditional Measures of Quality?

Do we no longer need to worry about our list?

  • Conforms to Specification
  • Satisfies Users' Needs
  • Implements "Best Practices"
  • Is produced using defined processes
  • Is acceptable to the customer
  • Is driven by the customer
  • Fits cleanly into the operational environment
  • Does not fail in any serious way

Far from it. Defects, conformance and all of the others are important for us to manage the nuts and bolts of our technical work. A product that is riddled with defects will never deliver Business Value, no matter how good it looks!

We still need our focus on these things. But that focus must always be held in the context of the ultimate Business Value we are tasked to deliver. Doing something "well" for the sake of goodness does nothing for my customer. If that hot "Best Practice" doesn't benefit my customer, then it is not worth doing. A technically excellent product that doesn't meet the need is useless!

It's All About the Relationship

All of this boils down to building a very different relationship with our customer than we have traditionally had. If we are to deliver the value they need, we must understand them and their needs, which means that our connection with them must be richer and fuller. At the same time, if customers are to have assurance of receiving Business Value from us, they must ensure that we understand that Value, which means investing time and effort helping us to learn.

This relationship is an investment that is sure to pay a handsome return!

Related Links
Document your project's business value in a Project Charter or Opportunity Screening Worksheet. For a more Agile approach, try our technique brief on Project Value Models. Need a refresher on Agile PM techniques? Our paper Agile: Overview and Core Methods can help.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.