jump to navigation

Project Management in the Real World, Part Two February 27, 2012

Posted by Tim Rodgers in Process engineering, Project management.
Tags: , ,

The last post was running way too long so I decided to break it into two parts. I’ve heard that any public speaker has about 15 minutes before their audience starts to lose interest, no matter how interesting the topic may be. I know I tend to get distracted after reading more than a couple of pages. Maybe that’s why Powerpoint seems to be replacing Word as the primary communication tool in many offices these days.

Anyway, back to the topic. Here’s my second group of five “keepers” from traditional project management training programs:

6. Account for limited availability of resources with specialized skills. Once the WBS is in place and the initial task duration estimates have been made, you have to allocate resources and balance the schedule accordingly to account for the way people actually work. This is where it’s important to remember that increasing the number of people on the project typically decreases individual productivity, as does multitasking. A big mistake that a lot of project managers make is overlooking the fact that the project is dependent on resources (people) with specialized skills, and that you can’t always substitute one person for another.

7. Find the critical path, understand it, and make everything subservient to it. The critical path is the key to successfully managing the project, otherwise you’re just an observer with no ability to influence the outcome. This is what determines whether you can meet the schedule, scope or resource constraint. Managing the critical path allows you to allocate resources and schedule predecessor tasks with an understanding of the overall impact on the project deliverables.

8. Spend some time on risk analysis and contingency planning. Everybody talks about contingency planning, but I haven’t seen very many real world examples. I think people believe it’s too time consuming, and anyway “we’ll cross that bridge when we get there.” Bad decisions often happen during a crisis; better decisions happen when you’ve at least thought about it before the crisis. I don’t think it’s worth the time to plan for all possible risks, but surely there are predictable events that can cause the project to run into trouble. Focus on the critical path and the effects of scope complexity (especially anything that hasn’t been done before) and specialized resource availability. The contingency plans should be consistent with the earlier constrain-optimize-accept agreements and the established change control process.

9. Use project checkpoints and gate reviews to approve a change in focus. Project checkpoints can be just a routine status report for the sponsors and stakeholders, in which case they can be scheduled on a calendar without regard to actual progress and tasks accomplished. On the other hand, many projects are intended to follow a lifecycle with well-defined phases, gate reviews, and exit criteria that are based on demonstrated and measurable achievements. Successfully moving through a gate review is supposed to trigger a significant change in focus for the project team, so it’s necessary to complete the exit criteria before the meeting, otherwise it’s only a project update. Either way, the audience for the meeting needs to know whether they’re being given an update, or being asked to approve moving to the next phase.

10. Analyze the project after its over. I don’t understand why people are usually in such a hurry to move on. Every project should have a retrospective or postmortem to review what went well (and should be captured as a best practice other project managers), and what didn’t go well. I come from a quality background, so I’m trained to first look for the cause of any variance in the planned schedule or resources (or quality), and then work to remove that cause to make future projects more predictable and manageable. In that sense a project is just another process that benefits from analyzing and eliminating special causes.

There’s a lot more to project management than what I’ve outlined in these last two posts, but I would rather see a project manager be significantly more likely to achieve their goals by executing a few simple directions than to become impatient and abandon an attempt to execute all of the recommended best practices from a formal training program.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: