There is a discussion of sorts going on the New Grange forum regarding the mis-behaviors of a project manager. Hopefully this is a fictional project manager, but none the less these sorts of behavior can be found in real life. The primary behavior of this PM is he does have control of the project, is being told by the customer that the project is in trouble and generally is acting as a project manager in name only.
Whether this is in fact how PMs behave or not it's hard to tell from my narrowly placed experience. I've been accused of living in a fantasy world where projects and project management are competent and capable. That actually isn't true (the component and capable) at all times and I've had my share of "project managers behaving badly" as well.
But in the end it was always clear where the problem lay. It was in the incompetence of the PM.
One question that came out of this discussion was "how to teach new project managers the ropes." Here's what has served me well in the past. Ask the six questions
- What - is the scope of work for this project?
- This is defined in the Work Breakdown Structure
- The WBS can be a formal system held in a database
- Or a simple list of work written in a notebook
- Either way it needs to be made clear what work is to be performed, how this work is connected to the final result of the project and what way this work is to be measured for it completeness
- When - will this work be started and completed?
- This is defined in the schedule
- This schedule can be a fancy dancy task network with 10's of 1000's of nodes all connected in an IMS formal manner
- Or it can be a bunch of story cards stuck to the wall describing the order of the activities in the project
- Either way some agreed on and visible list of tasks needs to be built and shared by the participants in the project
- Where - will this work be performed?
- This is defined in the Integrated Product Team field of the schedule
- The team members can be a few or many. If they are a few it will be simple to keep everyone in the loop as to what is going on
- If they are many then some formality is needed.
- Who - will be performing the work?
- This is defined in a resource list
- This can be really simple or really complicated
- Either way the participates in the project need to know what they are responsible for, when it is due and what are the measures of success for their efforts
- How - will this work be accomplished?
- This is defined in the detailed tasks.
- This can be a formal set of Accomplishment Criteria and the Significant Accomplishments that define how this work "matures" the project toward its completion.
- Or this can be a bunch of 3 by 5 cards stuck on the wall showing all the steps in the project that must be performed to call to "done."
- Why - does each work element exist?
- This is defined in the Statement of Work
- The SOW can be really simple - capture the needs of the community for the new addition to the library
- Or 500 pages of detailed technical compliance for a several billion $ high technology program
- Either way if the project participates don't know why they are working on this project, and why their efforts are needed then it will be very hard to have a discussion what "done" looks like.
By asking and answering these six question on a periodic basis, say every month, the project manager can be "engaged" with the project and the participants in the project (stakeholders, customers, funders, anyone with an interest in the outcome).
If the project manager can't answer these question, or won't, then she is not a project manager and should stop calling herself one.
