More on stage gates and project reviews

Not stage gate experts...

Per an earlier post (here), it is important to ask how to ensure that stage gates — and project reviews for that matter — are relevant to the project at hand.  It’s pretty simple IMO.

1. Make sure that the stage gates match the project phase.  It is amazing how many gate reviews are conducted with a single set of questions.  There should be a general set of questions as well as a phase-specific set.  The questions in a gate review must match the expected deliverables for that gate.
2. Structure the gate to include sessions that focus on the key capabilities and their associated deliverables.  This approach ties the review more tightly to the expected benefits of the project/program.
3. Have subject matter experts involved during these capability-focused sessions.  We often pair these SMEs with another PM who leads the review.  They jointly review and prepare the questions.  Then the project reviewers ask most of the questions, while the SME jumps in on follow-ups or asks any technically-advanced questions.

Advertisements

Heresy on Stage Gates

Old school Q-Gate

Glen Alleman tells us why he doesn’t like stage gates (here) and a number of readers respond in the comments. 

Per my comment, “gates” (we call them Q-Gates) are pointless if they aren’t closely tied to the status, progress, and forecast of the deliverables in question.  Back in the day, too many “gates” didn’t vary enough during the project lifecycle…too many “gates” were  simply an occasion to run through a generic checklist.  More of a CYA exercise, in other words.

Anyway, check out the post and comments.  It will make you look twice at whether your stage or Q-gates are there only for show.

The lasting impact of poor quality

My favorite corporate soap opera: As The Paint Peels

This past weekend I read an article — sorry I can’t find the link, this Forbes article is pretty typical though — about how it is a shame that the past quality problems still haunt America’s car companies. In particular, the author made the case that car buyers need to get over it.   IMO, poor quality is a betrayal of trust for a product like autos, which are so integral to our way of life and psyches. I must admit that I’m one of those buyers who, in the words of Daniel Snow,

turned to Asian and European cars after the oil shocks [and] found they didn’t require much maintenance over hundreds of thousands of miles. To add insult to the injury, Honda, Toyota and others began manufacturing cars in the U.S. The sterling quality of these products proved American workers were not to blame for quality problems at GM, Ford and Chrysler.

To this day, every time I look at US cars I get cold feet. The memories of the peeling paint and balky transmission of my Monte Carlo and the clutch on my Maverick that lasted 20K miles come back. Let’s not even talk about a teacher’s Vega, my friend’s Pinto, or the leaky diesel McDonald’s GM company cars of the 1980’s. Even worse, the strategy of pawning off crap cars via fleet sales to rental car companies — rather than killing/fixing the marque — means that when I think of Chrysler I think of the embarassing Dodge Caliber I rented last year.

Like they said in the X-Files, I want to believe. But, then I remember…

Will the Triple Constraint become the Project Diamond?

Craig Brown shares his experience (here) using a project diamond instead of the triple constraint (a.k.a., the Iron Triangle).  I was wondering whether someone would do like this… I’ve seen quality represented as a “Q” in the middle of the triangle or as an area “under” the triangle. 

I’ll have to think some more about how to use it.   I like the concept in theory, but I’m not sure how well the prioritization exercise Craig describes would work in practice.

Still looking down in checklists?

Just saw this article of the power of checklists in medicine (here) which reminded me that I had forgotten to include a link in an earlier post (here).  Atul Gawande wrote a long piece in the New Yorker a little more than a year ago simply entitled “The Checklist“.  It is far too rich to summarize effectively — please read the whole article — but below are a few snippets

[I]t’s far from obvious that something as simple as a checklist could be of much help in medical care. Sick people are phenomenally more various than airplanes… Mapping out the proper steps for each is not possible, and physicians have been skeptical that a piece of paper with a bunch of little boxes would improve matters much.

In 2001, though, a critical-care specialist at Johns Hopkins Hospital named Peter Pronovost decided to give it a try. He didn’t attempt to make the checklist cover everything; he designed it to tackle just one problem, the one that nearly killed Anthony DeFilippo: line infections…. These steps are no-brainers; they have been known and taught for years. So it seemed silly to make a checklist just for them. Still… [i]n more than a third of patients, [doctors] skipped at least one. 

The results were so dramatic that they weren’t sure whether to believe them: the ten-day line-infection rate went from eleven per cent to zero. So they followed patients for fifteen more months. Only two line infections occurred during the entire period. They calculated that, in this one hospital, the checklist had prevented forty-three infections and eight deaths, and saved two million dollars in costs.

Still think your project is too complicated to benefit from a checklist or two?

PM Quote of the Day — Pauline Kael

[T]he critic is the only independent source of information. The rest is advertising.

This quote came to mind as we’ve been going through an internal program’s requirements.  One of my colleagues regularly refers to, and insists on, using the “Four Eyes” principle.  In other words, one should always involve a second set of eyes to verify and validate work product.  If the project team is the only arbiter of progress

Too often, the four eyes principle often only gets honored in quality control — e.g., during post-build testing processes.  As my colleague’s insistence suggests, we find that an independent opinion is most valuable early in an initiative.  For example, wouldn’t it be useful to have an independent validation during planning that the requirements and deliverables really represent (and will make real) the capabilites the project or program is intended to put in place? 

It is tough enough to re-work a deliverable that doesn’t conform to requirements.  It is worse to have to re-build a deliverable that had conformed to requirements, but find that those requirements were never valid in the first place.

PM Quote of the Day — Vince Lombardi

Practice does not make perfect. Only perfect practice makes perfect.

When I was younger, I never got the point of practice.  Sure, I knew that it would get me in shape and knock of the rust off.  However, I never got the idea that practice would help me perform better under pressure.  Too many times I found myself over-thinking a situation because I hadn’t practiced enough to make it automatic.  I finally started to realize that realistic practice in all sorts of endeavors — in particular, public speaking and presenting — helped to take the edge off along with the rust.

Practice?... We're talkin' about practice?

Lombardi’s point also applies to how we test our processes and systems.  Too often I’ve seen customers and consultants assume away difficulties in their desire to save testing time and money.  Even worse, this saving “spasm” usually comes towards the end of the project, just as the testing was about to get serious.

The best testing practice (so to speak) I’ve seen came at a global firm that does dirty and dangerous work.  As you might imagine, that company is very conscious of safety and quality.  That firm called their last round of testing not integration or user acceptance, but “business simulation.”  Business simulation didn’t simply involve folks following a script.  We brought the system, interfaces, and data up like go-live, then encouraged the users to go “do their jobs” and call support if something went wrong.

Sure, such an approach is expensive.  But how much is that peace of mind that comes with a no-holds-barred validation that the system and its support conformed to requirements worth?