"I don't want to stand in the way!"

Over the holidays, I was talking to a friend of mine about a tangle in the internal documen­tation in her organization. I don't understand all the details yet, and I won't try to write about it until I do. 😀 But in the course of our discussion she referenced some issues that took me straight back to my days supporting a product development process.

A formal product development process is typically articulated in stages: Definition, Design, Development, Testing, and Launch, or something similar. Generally there are entry-criteria that have to be satisfied before you can start work on a stage, and exit-criteria that have to be satisfied before you can leave it. For example, entry-criteria for the Test stage should include "You have a set of tests defined" and "You have some kind of prototype to run the tests on." (There are probably others, too.) Exit-criteria from the Test stage nearly always include, "The product passed all its tests." (Or at any rate, if it didn't pass all its tests there had better be a good reason why not.) And it works the same way with all the other stages.

This is the Stage-Gate® new product development process from The AIM Institute.
(See website.) But you can find many others that look almost the same.

 

Part of the role of Quality in a system like this is to act as a neutral arbiter. (Compare this post here, for example.) Otherwise there's always a risk that one department (for example, Marketing or Sales) might try to push a product out the door when it's not really ready, because there are eager customers waiting for it. But if Quality has to sign off on every "stage gate" (transition from one stage to the next), then Quality can check the list of stage-gate criteria and ask for objective evidence on each one: "It says here the product has to pass all its tests. Can you show me a test report? [Pauses to read test report.] Wait a minute, here on page 57 there's a test that failed. What's the story with that?" 

And so on.

If you've never worked under a system like this before, it can look a little slower than developing without these artificial stopping points. But in the long run you save time and anxiety, because there is so much less confusion about what your status really is.

Sometimes, though, people got very anxious when it was time to hold a stage-gate review. If the project was late and things weren't coming together well, team members might start putting in longer hours to make sure all the documented artifacts were ready in time for me to review them. And once in a while, even the longer hours wouldn't help because the product just didn't work right.

I remember one project where I had been collecting the artifacts prior to a stage-gate review, and I was missing one test report from an engineer I'll call Ken (not his real name). So I went to see him.

"Hi, Ken. Do you know when your test report will be ready?"

"Well, ... do you really need it?"

"Of course I need it. Is there a problem?" 

"Well, ... some of the tests aren't working out the way they should."

"Do you mean you can't execute them, or do you mean the product fails?"

"It's that last one. The product isn't doing what it's supposed to do."

"Fine, that's no problem. Just write up the report and document the results you are getting. If some of the tests fail, we need to know that."

"That's easy for you to say. But I don't want to be the guy that stands in the way of releasing this product on time! I don't want to be the guy that tells the whole train to stop!"

Aha. That was the issue. So I explained.

"Ken, you're not standing in the way of anything. All you are doing is providing data. When we sit down in the stage-gate review with the management team, we'll decide what we want to do about that data. Depending on the problem, if it's small enough we might go ahead even though the problem is there. Or if it's an important use-case that's failing, we might decide that it's better for everyone to wait till the problem is fixed."

"This problem is pretty important."

"Fine. But either way, we're helpless unless we know the facts! And once we know the facts, we can make an informed decision about the right way forward."

"OK, I see that. But I still feel like I'm the one who's standing in the way of releasing on time."

Standing in the way

I smiled.

"Trust me, Ken, you're not the one who is going to stand in the way of releasing the product on time. I am. But I've got to have your report."

"I'll email it to you this afternoon."

"Thank you." 

Ken's perspective is actually a common misconception. It's easy to look at the project organization barreling forward at top speed, and to conclude that project management decisions are based on Who Argues the Loudest ... that somehow decisions about when to release a product come down to a contest where the loud shouters prevail and the quiet ones just have to grumble.

But under a formal product development process, it's nothing like that. A formal process forces you to define all your decision criteria in advance. Then, when the moment arrives, it's a simple factual calculation: have you met the criteria, or not? If yes, go forward; if no, stop. 

Often it is helpful if there is some wiggle room to handle anomalous or difficult cases. But even that wiggle room has to be clearly defined up front. I can talk about that more later.