jump to navigation

Project Management in the Real World, Part One February 23, 2012

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

Over the last few weeks I’ve been reviewing the materials from several project management classes from the early 1990s, refreshing my memory and looking for any recommended best practices I may have forgotten. Like many similar training programs, the detailed flow charts and checklists for successful project management look pretty good in the classroom, but are often abandoned when the eager student re-enters the real world where personalities and prejudices dominate and process is often pushed aside as “too academic.” Unfortunately this causes many people to become skeptics after a couple of frustrating attempts to apply the lessons, and they end up trying to muddle their way through based on what feels right, or perhaps the advice of their more-experienced colleagues.

I can’t say that all of the training classes I sat through in those days were worthwhile, but I think project management is one example of a real world practice that can benefit from a more disciplined approach. I’ve seen too many examples of poorly-managed projects with confused objectives and inconsistent decision making, where “I survived” is the proudest thing anyone can say about the experience. I believe these ten classroom best practices for effective planning and project management are good ideas in any environment. Here are the first five:

1. Establish the project’s decision criteria, or how tradeoffs will be made when the project inevitably runs into trouble. Some people believe that it is possible to deliver all of a project’s requirements and finish early and under-budget. That’s certainly possible, but I would say that’s an under-scoped and poorly-defined project. I believe that choices will have to be made, and it’s better to talk what guides those choices before the crisis happens and emotions run high. Is the project end-date flexible? Can we sacrifice some requirements? Can we overrun the budget? What level of quality is required?

My personal favorite is the constrain-optimize-accept model applied to the project elements scope (requirements, including the required level of quality), resources, and schedule. Briefly, this is how it works: one and only one of the three project elements is constrained; I don’t believe you can run a successful project by truly constraining more than one, and this is where discussion and alignment is critical. If the scope is constrained, then you must deliver all of the requirements, they are all “musts,” and you will overrun the schedule and exceed the budget if necessary. If the resources are constrained, you cannot spend more money than what has been allocated to the project, there is no more money, and you will lengthen the schedule and reduce the scope if necessary. If the schedule is constrained, you must finish on-time, the project cannot be late, and you will sacrifice some requirements and overrun the budget if necessary. All project decisions are evaluated against the constraint. After the constraint is determined, the other two elements are designated as optimized or accepted. Strictly speaking, the project element that is accepted is not actively managed at all.

2. Define the deliverables and metrics for the project. This sounds obvious, but misunderstanding here is deadly. How will you know the project is successful? How will you know the project is complete? How will the project team and stakeholders assess the progress of the project? It’s relatively easy to measure and track the schedule and expenses for a project, but the deliverables should also be measurable in order to unequivocally determine status. When the scope is not constrained, I like the idea of setting a minimum acceptable level for each deliverable that is “good enough” even though it falls short of the target. One more point: percent complete is a lousy way of tracking progress, either for the overall project or individual tasks. It’s too subjective.

3. Define the change management process, particularly who has change approval authority. The project manager may be accountable for the success of the project, but they typically do not have full authority to approve significant changes to scope, schedule, or resources. What changes must be approved? By whom?

4. Define tasks and the work breakdown structure (WBS). Tasks should have one and only one owner, with deliverables that are defined and measurable, just like the overall project. You have to use some judgment to determine how detailed the WBS needs to be. Too fine and you’ll spend too much time tracking details. What’s important is capturing the hand-offs between functions and the overall timing sequence. The WBS also shows the logical dependencies between tasks, but these should be examined. Do you really have to wait until the predecessor task is done before beginning the successor? Can you break the successor task into smaller ones that can be started earlier? Earlier is almost always better.

5. Develop realistic time estimates for tasks and the overall project. The WBS only shows the list of tasks and their sequence; you have to figure out how long each task is going to take. The actual task time is almost always greater than the estimate because of down time, interruptions, and fundamental uncertainty, so I’ve been experimenting with a different approach, which is to add buffer at the end of the schedule to account for the cumulative effect of task length variability. It’s a little detailed, so I’ll explain in a later post.

See Part Two for the rest.

Advertisements

Comments»

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: