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.

Advertisement

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?

Checklists and Change Programs

Jerry Manas’s post at PM Think (here) is a useful reminder to avoid a common error made when PMOs first implement processes and controls — over-engineering.   I can only say “Amen” to what Jerry notes:

We create forms, templates, and stage gates, in an attempt to gain control. But in doing so, we also create such barriers to implementation that it becomes like the Twelve Trials of Hercules just getting something implemented. P lus we lose flexibility (and I might add, credibility) as well. 

We’ve succumbed to that syndrome ourselves and Jerry’s prescription is a fine cure.  Our PMO finds checklists especially effective in two situations:

• Initial design, communication, and usage of a new or changed process.  Checklists reinforce the basics and ease process adoption.  Only once the change program is past the awareness and understanding phases — in other words, early adopters are actually using the process — does developing sophisticated templates or tools make sense. 
• Handling process handoffs.  Process and value chains are generally weakest where there are handoffs (e.g., between sales and delivery).  These handoffs are particularly severe when the personnel who accepted the leading process or phase deliverables aren’t directly responsible for the successor phase.  In this example, delivery management may have to accept/approve a statement of work, but the project manager hasn’t been selected.  Rather than force the PM to recapitulate the phase or process closing process, we use a checklist so the project manager can validate the quality of the handoff him/herself.

The Royal Mail still amazes, 8 across

Very cool story (here) about an artist — Harriett Russell — who decided to test just how dedicated the Royal Mail really was to getting her posts delivered.

[She concealed] the addresses of 130 letters to herself in a series of increasingly complex puzzles and ciphers. Among the disguises she employed were dot-to-dot drawings, anagrams and cartoons…. Amazingly, only 10 failed to complete their journey back to her.

I loved to hear just how seriously the postmen and women took their job.  One particularly clever challenge — the address as a series of crossword clues — came back “Solved by the Glasgow Mail Centre.”

Apparently this correspondence of sorts will be featured in a new book, Envelopes: A Puzzling Journey Through the Royal Mail.

PM Quote of the Day — Augustus Caesar

You cheer my heart, who build as if Rome would be eternal.

Who knew that Augustus was such a fan of quality workmanship?  It is a testament to how well (and how much) Rome’s builders built that we can see so much of the old Augustus’s Eternal City today.  Even hundreds of years of stone poaching, neglect, and the passage of time never completely obscured the glory that was Rome.

This saying reminds me that I should take seriously everything I build… even this simple blog post.  Augustus’s praise is a useful corrective to the idea that what we’re doing today is ephemeral, fleeting, and unimportant.   He isn’t advocating gold-plating (post here). 

From what we know of his views on adornment, haste, and waste,  Augustus valued people, places, and things that were reliable and built to last.  Considering that the empire he left lasted for almost 500 years in the West (and almost 1500 in the East), he knew a bit about permanance. 

Or what passes for permanance in this world.