pmNERDS Community: Login

  • Innovation_e_Publication
  • Integrated_PM_Feedback_Blog
  • Job_Board
  • pmNERDS_Center_of_Excelence
  • Research_and_Development_Journal
  • Community_Blog
A+ A A-

Problem Validation and Verification

If problems that are addressed by projects are validated and verified, then development investment decisions are made more wisely, but the problems may not be the right ones unless you understand the voice of the customer.


You have done a good job defining the problem or project idea that your project will address, taking care to avoid hinting at arbitrary premature solutions, so as to allow plenty of room for design creativity. You have wisely used a standard format in which to state the problem and the benefits for solving it, so that the keepers of resources will be more willing to allocate them to your project, compared to other projects that are vying for their attention. So far so good.

Now it’s time to try to strengthen your theory in order to prove that solving this problem or meeting this need, is really deserving of more investment. "Validating" the problem will either, give you more reason to keep going, or cause you to rethink your understanding of the problem. Likewise, when you have completed your project, “verifying” that the problem was addressed, will confirm that the investment was a wise one.

Validation and verification are not the same processes as functional analysis techniques, which help explain HOW buyers do or would interact with the process/product. That kind of analysis converts the already validated buyer needs, and expectations into features and requirements, that drive engineering of that value into the final product.

No, it will take a bit of work to confirm that you have accurately defined and addressed the problem. And the best way to do that is to check with your buyers. But how would you go about that? One approach is to borrow from the methods usually associated with the “voice of the customer.”

Plan for Capturing VOC

First, decide who are your target customers. No one buyer can speak for all buyers. So, you should consider various types of buyers, such as current customers, customers of competing products, potential customers, and avid or lead customers who know the product well.

Next, have product / service developers participate in capturing customer data alongside traditionally assigned marketing types and analysts. This will provide better visibility for the engineers who must make development decisions.

Lastly, be choosy about the data you capture. Some kinds of data are not suited to guiding the development effort, and some are. Also consider your ability to organize the information captured into meaningful expressions of buyer needs.

Pay Now or Pay (Much More) Later

Studies have shown that up to 80% of the total cost of a product or service is taken up by the ideation and conversion phases of development. Taking the time to validate that you have the defined the problem correctly, allows early course correction, during the time when the cost to impact relationship is much, much lower than later on, when design changes are accomplished only at high costs. Those changes include rework, warranty claims, and even buyer dissatisfaction. More importantly, problem validation and verification will reduce the chances that you develop products that buyers do not like now and in the future.

Continue reading
135 Hits

Define Acceptance Criteria

If projects have defined acceptance criteria, then project managers will be able to better manage stakeholder expectations, but how project outcomes will meet the needs should be discussed and documented early in the planning.

Boy oh boy! Isn’t it “fun" trying to define acceptance criteria? You have to know your requirements cold. And usually you have to do this early on in the project scope. when you know least about the project.

“The indispensable first step to getting the things you want out of life is this: decide what you want.” - Ben Stein

What sets acceptance criteria apart from other ways of evaluating the goodness of project outcomes? Acceptance criteria describe what constitutes a successful outcome; but successful to whom? The buyer is the one who cares most about acceptance criteria, but you have to help the buyer know that.

In the minds of all the project contributors the end product may be perfectly functional, having met the requirements. But that does not necessarily mean that the product buyer is going to be happy with it.

Take perhaps a common kitchen scene at home with a grade school age girl and boy right after dinner, where fresh baked cookies just came out of the oven. The kids are no stranger to cookies. And these are the kind with M&Ms and NO nuts. Dad actually made them up from a mix and formed them on the cookie sheet. He didn’t just thaw the frozen kind. Dad was pleased with the outcome - warm, delicious cookies that the kids would love. What could go wrong?

Evan didn’t like that a few cookies had melted into each other and had to be cut apart. Laurie thought they did not have enough M&Ms, and they both wished there were more of them. Plus, they didn’t like waiting so long for the cookies to cool down.

The missing element? Assumed, mistaken, or weak acceptance criteria.

To get going on defining effective acceptance criteria, you want to establish open lines of communication with your buyers throughout the project, not just during planning and “user acceptance” testing where these criteria normally rear their heads.

Plan for collaborative working sessions between your product designers and all product end-users, where you jointly “nail down” how the product will be evaluated for “acceptability” at various stages in the project. Take a hard line: if a requirement cannot be measured or tested objectively it should be re-stated.

Once defined and agreed upon, as for deliverables and requirements, you need to control changes to acceptance criteria.

There are many ways to document this, such as in the scope statement. The Volere Requirements Specification Template has a particularly useful spot for acceptance criteria, right there on its requirements specification “SNOW" card that is used to capture requirements, called the “Fit Criterion.” It is the objective measure of a requirement’s meaning, and is used to evaluate how a solution fits the requirement.

Well designed, well-constructed, and well understood acceptance criteria will make, not break, a project, and will enhance your reputation as a professional and successful project manager. It is time well invested.

Continue reading
115 Hits

Enable Value Realization

If a project enables value realization, then the business will experience a higher return on its investment, but the worth of the project outcome and the cost to produce it needs to be calculated and measured before and after the project is finished.

What exactly do we mean by “value realization”? And if we should help it come to be, what is “value” then?

A simple definition of value is the worth that something has, or what its benefits are, compared to the “cost” of the thing. For example, a toaster wide enough for bagels that doesn’t burn them is important me. I will likely value most the lowest cost toaster with those 2 features.

So, in order to help the value of a developed product or service come to be in a project, we and our buyers need to get real clear about what that is. This discovery effort is the first phase of the value engineering process, sometimes called the Information phase. What distinguishes value engineering from other methods of design, is its focus on function, establishing the monetary value for that function, and how to provide that function at the lowest cost.

Preparing for Value Realization

To get started, identify the project deliverables and understand what function the deliverables play in the buyer’s value chain. Function is what makes a deliverable work or sell, like "toaster slot accommodates 2-inch thick bagel half, and “user can adjust toaster heat."

A very important tool used in the value engineering Information phase is the Function Analysis System Technique diagram (FAST). FAST organizes functions into cause and effect relationships, and helps to:

1) identify product functions, 2) reveal linkage among all functions, and 3) analyze and evaluate functions.

One slightly more sophisticated way to estimate value for projects is called Expected Commercial Value or ECV. ECV uses money to quantify value. ECV is first estimated when developing the project business case for funding decisions. That formula considers the future income stream, commercialization costs, development costs, and the probabilities of commercial and technical success.


“The future ain’t what it used to be.” - Yogi Berra

After you have completed value engineering of the deliverables you will need to figure the current value of the deliverables during the payback period. For our wide-mouth toaster, you might ask, “How popular is this toaster compared to what we thought it would be?”

The important thing is that you set the expectations up front, in your project planning and during project scope, so that project outcomes will be defined and measured, how, and over what time frames.

When you help a business produce products or services, that are of high value in the eyes of buyers, at costs lower than its peers, that business will experience an increasing market share and enjoy a nice return.

Continue reading
89 Hits