|
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.
|
|
|
|
|
|
|
|
· Determining how your project is
going
|
|
|
How is your project going? A sponsor or customer funding a
project has a right to know when they can expect to get what they're
paying for. They ought to receive reasonable assurances along the way
that their goals are being met. Senior Management needs to know when
resources will be available for other initiatives. Financial staff needs
to know what the cash flow will be.
We wrote last month about collecting actual data on tasks. We need to
know if a task started when it was scheduled to. Did it take as long as
anticipated? Were more effort hours applied to the task than projected?
Did it cost more than anticipated?
The difference between the plan and the actual is called variance. If we
are ahead of schedule by four days, we have negative variance (11/01/04 - 11/05/04 = - 4 days). If we
are behind schedule we say we have positive variance, (11/05/04 - 11/01/04 = +4 days). Positive
and negative variance can also apply to cost and effort hours.
We like to get people accustomed to using terminology like Start
Variance, Finish Variance, and Cost Variance. It takes some of the
emotionalism out of the blunt "You're late!" or "You've
spent too much on this task."
To
subscribe to our newsletter
|
|
|
|
· Presenting Project Status
Information
|
|
|
Some people are happy seeing
baseline with actual data in text format:
 <>
Others prefer to see a graphic
representation.
The Gray represents the baseline. The Blue what actually happened.
Important note: Microsoft Project represents critical path tasks in red
and non-critical path tasks in blue. When critical path tasks are
completed they are changed from red to blue.
To
see previous newsletters
|
|
|
|
· Some Tasks are
Behind Schedule This Week
What is the effect?
|
|
|
Status reporting needs to include the net result of delays.
What are the consequences of a delay for the end of the project? As a
project manager what corrective action do you plan to take to return the
project to its planned and baselined completion
date or cost target?
While formal status reporting is a litmus test of project manager
maturity and knowledge, scale of the project often plays a substantial
role. Satellite launches or dam constructions with a cast of thousands
demand formal detail. Most information work project managers nowadays
however don't have the time or resources to gather and present status in
this way. Mostly what they do is just recalculate the plan based on
slippages and new task durations. We rarely see the plan vs. the actual.
The reason given for this practice is that "something came up"
or new and unanticipated tasks presented themselves as the project
developed. The project got so far away from the original baseline that
keeping one was no longer valid.
We used to judge this practice (or lack or practice) as totally
undisciplined. We have gradually come to consider that the model of
planning and then rigidly following that plan just doesn't work in most
small, internal, information work environments. So much of information work
involves defining the project as it unfolds. Despite all your best
upfront planning efforts changes are inevitable.
In reporting status, as with all communications transactions, knowing
your audience is crucial. Some sponsor may be satisfied with a simple
representation. (We have seen project managers report status with
PowerPoint Gantt charts.) We prefer to show a milestone chart created
from a data driven tool like Microsoft Project. At least the audience can
see that there is data behind the graphic.
We have seen technical project managers fall down presenting project
status when they don't have a clear idea of the story they intend to
tell. Can you summarize it in one sentence? If we say that a software
development effort is currently on track but anticipates difficulties in
the testing phase due to lack of resources, We had better be able to
1) clearly show how it is on track
2) clearly show the difficulties of the testing phase
3) have some kind of plan or alternatives in place to deal with the
shortage of testers
Making a general statement, then backing it up with details is part of
the ancient art of persuasion. Just as the project manager is always
selling his or her project at Initiation and Planning, they are also
selling during Execution and Control.
|
|
|
|
