More advice for novice project managers

In response to Project management for non-project-managers, Geoff Beckman provided an excellent follow-up he agreed to share. Fair’s fair: The original source for a lot of it is Keane Consulting (which has published it publicly before, so this should constitute fair use, in case anyone is concerned). – Bob

Bob:

I liked your answer to the newbie PM (Project management for non-project managers), but I actually don’t think his question was all that ridiculous. I think he just picked the wrong number.

My old employer (Keane, Inc.) was insanely good at PM– they pride themselves on being able to get projects to CMM level 3. They boiled the concepts of project management down to six rules– 28 words that they printed on our coffee cups:

1. Define the job in detail.

2. Get the right people involved.

3. Estimate time and costs.

4. Break the job down.

5. Establish a change procedure.

6. Agree on acceptance criteria.

For those who weren’t experienced enough to figure each one out with fifteen seconds of thought, they had a one-page handout with a one-paragraph definition/expansion for each rule. For rule three, it was something like:

“Divide the project into phases; phases must end with the production of a tangible deliverable. Each phase consists of activities; each of which must produce a deliverable. Activities consist of one or more tasks, all of which must produce deliverables. Tasks can never take longer than 80 hours to complete–if you find, during estimation, that one does, you must rewrite the plan to make it an activity, and break it into tasks.”

All the stuff you were telling the guy was in there, as well as some other useful things. (After “Break the Job Down”, my favorite rule was “Set up a change procedure”, which instructed you to get every request for an alteration in writing, work up a cost and time impact of the change and then present the results to the client and get a signoff before starting.)

But I think the most important thing the guy needed to know was:

“Project management is a lot like belling the cat. Understanding the process is the easy part– executing the steps is the difficult part. The temptation to skip things that don’t seem (at the time) to require so much formality and paperwork– or to fudge something that you know should be tangible– or to yield to the client’s pressure– is what usually bites you.”

I once decided that a client’s notification that a module was being moved from testing to production constituted acceptance– that I didn’t need to write up four pages of stuff every time we finished something. That cost me a few hundred hours of free re-work. Also found out that three departments can agree that a project is absolutely mission-critical and agree to provide X hours of resources– but not agree on who has to give up their DBA and who has to supply the programmers (I did have three hot-looking secretaries until I located my project sponsor, however.)

A friend once defined a deliverable as “clients receive training and develop good working understanding of new system.” She now uses “training program developed in previous activity is scheduled and performed for designated end-users” and blames her original choice of words on sunspot activity.

Best,

Geoff Beckman