The Project Group, LLC

The Project Group, LLC Newsletter

  Advancing Project Management

October 2003  


in this issue


The Project Group, LLC

We specialize in assisting corporate and government clients in learning to improve their productivity while planning and executing projects.

Our three-phase approach yields faster, more efficient project initiation, planning and execution results.



Each month our newsletter delves into a specific step in the phases of Initiation, Planning and Execution of projects. Our methodology is applicable to any project in any industry. Our process approach to Project Management is designed to help your company's projects gain traction quickly, communicate clearly to all parties and keep them on track to reach a successful conclusion.

We facilitate workshops that jump-start your teams, making sure they know what they are going to do and validating they have the time and resources with which to do it.

This newsletter focuses on Process 11:

Tracking and Managing A Project.






The Project Is Planned, What Is Next?



Congratulations, you have completed planning your project. Tasks have been identified, sequenced, estimated and assignments given. You have reviewed the plan with the project sponsor at key intervals to make sure it meets with the sponsor's approval. You have also developed a project schedule and refined critical path task duration estimates.

The Sponsor has given final approval to your plan and it's time to begin. BUT, before you start there are a couple of details for you to review.

Have you clearly communicated to your organization about the project? The need to communicate goes beyond your project team. Have you done a thorough stakeholder analysis? Individuals both inside and outside your organization may be curious about what is going to happen. Now is a good time to let them know. There are many ways to "pass the word." These include:

Publishing a newsletter or email

Holding a "brown bag" lunch and talking about the projected work

Posting your Project Charter or making it available on line

Another item to deal with is making a decision regarding whether you are going to "baseline" your project plan or not "baseline". There are positives and negatives associated with baselining.


About Baselines


A baseline is a freezing of the original project plan so that we can compare progress with the original plan and tell whether or not we are achieving our original goals.

Baseline data includes, for each task:

Start date

Completion date

Duration estimate

Effort Hour estimate

Cost estimate

After we collect actual data (what is happening on each task) we can compare the plan with the actual data and calculate a variance. If a task was originally expected to take 10 days, for example, but ends up taking 12 days, we say it has -2 days Duration Variance (10-12=-2)

But task baseline data often changes because scope changes. A Scope Statement should be included in the project plan to serve as a baseline for the work to be done. Any change to the scope must go through a formal change control process. We should be able to clearly see additions or subtractions on the scope statement and then communicate them to all stakeholders.


Why Baseline?


Why should we bother to baseline since they are going to change the plan anyway?

Sound familiar?

Who's the "they"? "They" could be project sponsors, senior management, customers or technology vendors. The first line of defense against this problem is communication. Does everyone know the plan we have created? Does everyone know the consequences of delay or cost overruns?

From another perspective, how this question is answered often delineates between what we have previously called "construction" and "information work" projects.

In the "construction" project, you get a clear blueprint of what you are supposed to do well before you start. Your job as the project manager is to execute that blueprint. In "information work" projects, half the project duration is often spent determining what the project is. This effort frequently comes in a Requirements phase. The difficulty in reaching and maintaining agreement on requirements is what makes project execution so difficult in "information work". Project teams may be reluctant to baseline until they have completed requirements because they know that the outcome of that phase can dictate broadly different results for project execution.

There are two main reasons to baseline. The first is so we can see the consequences of delays and overruns and take corrective action. A project driven by deadline or cost constraints must be baselined in order to know when and how to apply corrective action.

The second reason to baseline is to improve your estimating skills. When you hold firm in maintaining baselines, you can retain historical records as to how long a task took, how much effort it required or how much it cost compared with your original estimates. When project managers keep changing the baseline, the project plan is forever porous. Consequently, we have little memory of what our original assumptions were.

Unfortunately, all too often baselines are used to hit project managers and team members over the head for not conforming to their original plans. This behavior on the part of sponsors and executive management undermines the project management process.


Next Month In The Newsletter


The November newsletter will feature more articles on tracking and managing projects.


To see previous newsletters


 ::  email us
 ::  visit our site

phone: 415-572-3084