|
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.
|
|
|
Greetings,
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
|
|
|
|
