“You Just Made A Yummy Sound, So I Thought You Liked The Dessert.”

 

One of my favorite movies is Mel Brooks’ Young Frankenstein (1974). I especially liked the scene where Gene Wilders, Marty Feldman, and Terry Garr are sitting down to a meal after having failed (they believe) to bring the monster to life. As they’re eating, the monster, very much alive but confined to the examination table in the cellar laboratory, lets out a grunt that Dr. Frankenstein mistakes for Igor’s vocal appreciation of the food.

“I didn’t make a yummy sound, I just asked you what it is.”

“Well, if you didn’t make a yummy sound, and you didn’t, then who…?”

In a flash the three realize that the monster must have made the sound, and rush to the laboratory to confirm it.

Meanwhile, Back In The Project Management World…

There’s this Project Management transformation (ProjectManagement.com’s theme for May) myth that I would love to overturn, but it’s fairly well entrenched. It goes something like this: the Project Management “expert” is brought in to the organization to transform it from a bunch of people completely bereft of PM techniques or strategies to one where even the lowest-level of management/leadership regularly, even casually discusses things like scope creep or variance analysis. This expert does so by employing one or a combination of the following tactics:

• They use their hierarchical authority to compel PM practice adoption – essentially, they make professional life more difficult for those who refuse to do management their way.
• They leverage other people’s authority to compel PM practice adoption, usually through the writing of procedures that spell out how the expert wants things done, and gets enough executives to sign the thing. Then the experts pretty much expect that everyone will begin to obey, under the threat of being found to be “not in compliance with procedures.”
• If neither of the preceding techniques is available, they may be forced into eat-your-peas-style hectoring mode, where they basically nag everyone about how they ought to be doing Work Packages, Control Accounts, Critical Path schedules, etc., etc. These people become tiresome rather quickly, and can be readily found presenting papers at PM-related seminars.
• Finally, the new expert may appeal to their scholastic authority, constantly reminding everyone of the details of their resumes. These also become tiresome quickly.

The myth to be overturned is that these tactics work. They don’t, particularly and especially if we’re talking about organizational transformation on a scale analogous to bringing an assembly of human parts to life a project team from complete ignorance or rejection of PM techniques to sufficiency, or even proficiency.

So, What Does Work?

The most transformational strategy that I’ve encountered that works on a consistent basis has to do with getting really simple. An exec who had been transferred to head an organization that had dozens of small projects – in the $80K to $250K (USD) range – had no idea how all of these small projects were performing, as their Project Leaders had escaped any accountability or reporting responsibilities because their projects were “too small for Project Management.” He called me in to see if I could help. I told him I thought I could, but first I had to abandon virtually all of the recommendations from the conventional wisdom. A junior project controls specialist was supposed to support me, but he ended up instead arguing with virtually every decision I made.

My first step was to ascertain exactly what kind of cost/schedule reporting would make this exec confident that he had a handle on all of these projects. He selected an XY chart format, with the Cost Performance Index (CPI) tracked on the X axis, and the Schedule Performance Index shown on the Y axis, with the size of the projects’ bubbles indicating total budget. It’s a neat little report, really -- at a glance, anyone can tell if the status of the projects reporting, so:

• If they are in positive-positive space (upper right-hand quadrant), it’s all good.
• If they have a negative schedule variance and a positive cost variance (upper left-hand quadrant), they need to accelerate project work, i.e., get more done.
• If they have a positive schedule variance and a negative cost variance (lower right-hand quadrant), then they’re running too hot, and need to throttle back a bit.
• Finally, if they’re negative-negative (lower left-hand quadrant), they’re in trouble.

The beautiful thing about this report is that it only needed, technically, three pieces of data, two of which were already available via the General Ledger:

1. The time-phased budget. The total budget was already available in the General Ledger. If I could get the Project Lead to time-phase it, cool. If not, I simply level-loaded it across the period of performance.
2. The projects’ cumulative actual costs, available directly from the GL.
3. An estimate of the project’s completion percentage, since cumulative Earned Value equals the percent complete multiplied by the total budget. This was the only piece of data that wasn’t already available, and could be gleaned from friendly reminder e-mails once per month.

As my project controls “support” person constantly nagged reminded me, I wasn’t calling for formal scope, cost, or schedule baselines, and I certainly wasn’t bringing up risk registers. I didn’t care about Baseline Change Control Boards, or variance analysis thresholds, or schedule logic. Nevertheless, an astounding transformation began to take place.

At the first project review, the XY/Bubble charts, nicknamed “Bullseye Charts,” were projected up on the conference room’s screen. Each Project Lead was asked about their status, particularly the ones in the lower left-hand quadrant. Those who failed to respond to the percent-complete data call were admonished by the executive, and never did so again (“It’s a simple data point! How hard can it be?”). After a few explanations about how the data was being processed into this performance information, the PLs understood what was happening, and why.

At the second project review, none of the PLs failed to send in a percent complete estimate. Some had clearly attempted to game the system, as their bubbles hugged the Cost Performance Index axis. These were told to knock it off, as their attempts to game the new performance measurement system were plain for all to see (“I said it would be simple – I didn’t say it would be stupid.”). Those in cost performance difficulties would discuss possible sources of informal changes to the scope – classic scope creep – and their attempts to reduce or eliminate it. Others would engage it what can only be described as variance analysis, and at a fairly sophisticated level. Again, none – none of these people had ever had formal PM training. They simply began to adopt its lingo when intelligently addressing project performance issues.

By the third project review, discussions easily transitioned to venues for modifying the baselines, tapping available reserves, and using demonstrated superior performance to attract similar work. They had actually transformed into a fairly sophisticated bunch of PMs, almost by accident, and within three months’ time.

Hearing their suddenly PM-focused discussions was the yummiest sound I’d ever heard, and I didn’t even have to rush to the laboratory to confirm that the transformation had taken place.