Though we all have the same amount
of time, it just seems to slip by me faster than it
does other people. It's not that I'm lounging around
smoking cigars, playing poker all night, and ignoring
my work (okay, not usually). It's that I take on much
more than I should and everyone suffers. And the projects
that I take on magically grow from cute, innocent
endeavors into eight-armed monsters that crush my
schedule over and over.
Project managers know—or should
know—the iron triangle of project management (see
Figure 1), sometimes called the triple constraints
of project management because all projects are constrained
by these three elements: time, cost, and scope. My
nemesis is the angle on the left: time.
Figure
1 : The iron triangle of project management shows
all projects' triple constraints.
Any project, from developing
a new piece of software to building a new house, takes
some amount of time. The relationships between the
scope of the project, time, and cost should balance.
If there's not enough time or budget, the project
is doomed. (No kidding.)
The real problem? Planning. Delegation.
And learning to say no. First, we must define the
product scope: the verifiable, tangible deliverables
that make the customer happy (or happier, depending
on the customer). Once all agree on the product scope,
then it's on to the project scope—all of the work
and only the work to create the project deliverable.
The product scope and the project scope are dependent
on one another; if you change a detail in the product
scope—gosh, the project scope will change, too. And
these changes take time.
Now, sometimes I'm late and it
just ain't my fault. (Come on, I did say "sometimes.")
For example, I was working on a project for a company
that couldn't decide exactly what they wanted. It
was like one of my usual dates: "I don't know
what I want, but this isn't it." We'd go round
and round through feasibility studies, new versions
of the training manual, class development, and more
frustration—then they wanted to know whether I could
still hit the target deadline for project completion.
My mental response? "Yes, just as soon as I get
back from my bike ride to Hawaii."
On any given day the phone rings,
email chimes, or the fax spits out some new request,
and without thinking we say yes. That failure to think
is killing us. A little change here, an addition there,
and four or five new projects coming in; time disappears
faster than a plate of donuts at a Weight Watcher's
meeting.
But this isn't an article on
how to whine. We're all crushed for time; some of
us just manage it better than others. When it comes
to project management, I know that the time management
discipline is my Achilles' heel. In the past, I would
gladly take on the work without thinking, planning,
and delegating. But I'm getting better about it—I
told someone no last week. It was sad and disappointing,
but I can't let things pile up anymore and current
commitments slip by.
The Official
Approach (How It Looks on Paper)
In the perfect project-management world, which doesn't
exist, there is a logical, practical approach to calculating
how long a project should take to complete. Let's
pretend that we're living in this perfect project
management world and see how things should go.
First we work with the customer
to define the product scope—describing the thing that
they want us to create. Then we create the project
scope—all of the required work and only the required
work to create the product scope. And then, boy oh
boy, we create the work breakdown structure (WBS).
The WBS is not a list of the
activities to complete the project. That's right.
The WBS is a deliverables-oriented decomposition of
the project deliverables—not the project work. Once
we've created the WBS, we can generate a list of the
activities that the project team will need to perform
to create the identified deliverables.
The activity list should conform
to a fun heuristic called the 8/80 rule, which states
that the smallest element of the WBS, called the work
package, should take no more than 80 hours to create
and no less than 8 hours to create. We don't want
the WBS to be so granular that we're dictating each
step to create the deliverable; nor do we want the
work package to be so large, as in more than 80 hours
large, to leave much of the work open to interpretation.
(As with most rules, of course, there are exceptions.)
The activity list should then
be arranged in the order in which the activities must
or should take place. Many of the activities will
rely on hard logic; they must occur in a particular
order for the project to be successful. We have to
install the operating system before installing the
application. Soft logic relies on management discretion.
For example, we could create a fancy script to install
the operating system and then call a remote server
to pull the application and install it on the target
machine once the OS has been installed. But we may
choose not to do that. It's preferential logic based
on experience, the nature of the work, or your mood
on that particular day.
Now the real fun starts. As the
expert time-starved project manager, you examine the
work sequence and realize that you can actually take
several paths to project completion in tandem. So
you map out the work visually in a project network
diagram (PND), as shown in Figure 2 . A PND visualizes the work and allows
you to find the critical path. The critical path is
not the path with the most important activities; it's
the longest path to reach the project's conclusion.
The critical path reveals the activities that, if
late, will cause your project to miss its target completion
date. You can find the critical path by simply counting
the duration of activities from Day 1 to project completion.
But what of the activities that
are not on the critical path? These activities have
float—the amount of time by which an activity can
be delayed or late without affecting the project end
date. There are some fancy formulas called the forward
and backward pass to calculate the float for each
activity.
You don't have to be a genius
to do the math, but it's easier to just let your project
manager information system (such as Microsoft Project)
do the calculations for you.
Your critical path can change.
Some of your non-critical path activities may be late,
additional activities may be added to your project,
or the duration of non-critical activities may be
revised. Your project may take longer if any of this
happens, and you'll have a new critical path.
Between each set of activities
in your PND are relationships that describe how and
when successor and paired activities may begin. There
are four different relationship types, though chances
are that you'll use only one or two of them:
Finish-to-start. This
most common of relationship types means that the
upstream activity must finish before the downstream
activity can begin. For example, you must create
the disk image before you can push it out to 1,200
machines. Start-to-start. This
relationship allows two activities to start at the
same time, but not necessarily end at the same time.
For example, imagine that your organization has
a new piece of software that all users will have
installed on their desktops. In your project plan,
all users must complete a four-hour training session
before the application is installed. You create
a system that installs software on users' desktops
while they're in class for the new application.
Both activities start at once, but they sure won't
finish at the same time. Finish-to-finish. This relationship requires both activities
to end at the same time. For example, you're managing
a project to redesign your new web site. To promote
the new chic look, your organization will mail a
million postcards to current and potential customers.
Your project plan requires that the final modifications
to your web site and the postcards arriving at your
prospects' offices finish at the same time. Fascinating. Start-to-finish. This
is the most unusual and least-used relationship
of all. It's special. You'll find this relationship
when you're using just-in-time scheduling. Basically,
the upstream activity must start so the downstream
activity can finish. Imagine that you're a manufacturer
of plastic bottles. You don't have room on your
shop floor for an infinite amount of plastics, so
you only order plastics when your supply is running
low. The depletion of plastics by current activities
triggers an order for more plastics so you can create
more bottles in the future.
Coupled with each of these relationships
you can use lags and leads. A lag is simply waiting
time, while a lead is hurry-up time. For example,
you're installing a brand new network in a building.
You'd like the cable installation and the installation
of the punch panel to happen in tandem. Realistically,
however, the punch panel needs a head start on your
cable runs, so you add lag time to the cable installers.
This plan allows both activities to happen at once,
but requires the cable installers to wait a bit until
they begin their activity. (Cable installers usually
have no problem waiting.)
Sometimes project managers have
to hurry things along in a project. This is where
lead time comes into play. It allows you to move activities
closer to the project start date by subtracting time
from each activity's scheduled start time, as shown
in Figure
3 . Lag is positive time; lead is negative time.
Estimating
Project Duration
The estimated project duration is based on the sum
of the activities. With some math magic, we can predict
the best, worst, and most likely scenario for how
long each activity will take, and ultimately how long
before we put this beast to bed and move on to the
next.
To create an estimate that's
accurate or close to accurate, it's really more than
just adding up the activity durations. We also have
to consider several factors that could wreck the schedule,
drive managers nuts, and cause our hair to fall out
(see my photo ):
Constraints. A
constraint is anything that restricts project options.
You've hired a consultant who is only available
on December 29. You've enrolled your project team
in a training class on January 20. Sam the systems
engineer is taking a four-week vacation in February.
All of these are constraints—and there are tons
more. Assumptions. We
all know what happens when we make an assumption
(think ass and umption). For example, we assumed
that the vendor was honest when saying that the
new servers would be delivered by October 1. We
assumed that the client was using Windows 95 or
better, not OS/2. We assumed that we could have
access to the job site 24/7, not just during business
hours. If we don't document and share these assumptions,
it's trouble. Available resources. Have you ever calculated that you'd need
four network engineers to pull and install the cable,
only to discover that you only have two network
engineers for your project? If your required resources
aren't available, your project will be hurting. Law of Diminishing
Returns. The Law of Diminishing Returns
controls yield against the amount of labor available.
Suppose we have an activity that will take 40 hours
with two network engineers assigned. If we add two
more network engineers to the activity, can we finish
the work in 20 hours? Maybe. If we add 40 network
engineers to the activity, can we get done in a
few minutes? Not likely. In addition, not all activities
are effort-driven; many are of fixed duration. This
is a nice way of saying that it doesn't matter how
many experts you throw at the activity—it will still
take the same amount of time to complete. Parkinson's Law. Parkinson's
Law states that work will expand to fill the amount
of time allotted. Imagine that Joe says an activity
will take 40 hours to complete, although he knows
he could finish the work in just twelve hours. He's
added padding to account for potential mistakes,
issues, and games of solitaire he may encounter.
Magically the task will grow to take the allotted
40 hours. Think of your workload the day before
you leave for vacation. You can crank and get it
done. But the day after vacation? Takes all day
to send one email. (Maybe not you, but probably
that guy in the cube next to you.) Risks. Business
risk can have an upside or a downside—although we
usually think of risks with the downside. Most risks
that come into fruition have potential to delay
the project work, add activities, and in some instances
require us to wave the white flag of surrender.
(I'll cover risks in more detail in another article.
I know, another time management issue for me. Thanks.)
Time Management
and the Crystal Ball
How do we ever know how long any given activity will
take? For some activities, you can rely on experience.
Other activities have to rely on expert judgment,
historical information, and approximation. Approximation?!
Yep. Consider any IT project you've ever managed,
worked on, or heard about. Each IT project is subject
to the first-time, first-use penalty. Just about every
IT project is unique. Even if it's an integrator installing
the same old piece of software over and over in different
environments, there are unique aspects to each environment.
No two IT environments are identical. Even if it comes
down to the humidity in the air, the ghosts in the
machines, or the users who will crunch and crank on
the software, there are always differences.
These subtle and sometimes not-so-subtle
differences can drive us crazy, or inspire us to take
up professional roller hockey. These unique configurations
also confound best efforts to predict how long an
activity will take to complete. Sometimes you think
you know and other times you know that you don't know.
And now a word from reality:
That's why estimates are called estimates. Management
and customers don't seem to get this part, do they?
Have you ever given an ad hoc estimate where you pulled
a duration estimate out of the sky? This is a rough
order of magnitude (ROM) estimate; a simple, ballpark
guess that management and customers are certain to
hold you to. No fun for you—just them. I encourage
you to not give any ballpark estimates. If you must,
add an asterisk to your verbal quote, indicating that
this is an ROM estimate and that it can be way, way
off—from 75% up to 125%. Otherwise, you're stuck with
the number you throw out there. Should your actuals
be different from the ROM, you've heck to pay. Right?
Time To
Wrap This Up
If time management were easy, everyone would do it.
The biggest input to effective time management is
effective planning. As project managers, we must have
control over our project schedules, which requires
a constant eye on activity duration estimates; actual
time committed to activities; and expert judgment,
guts, and experience to make refinements to our schedule
when appropriate. Of course, it's never fun when a
project manager replaces a bad date with another bad
date.
We all have the same amount of
time. The only thing we really control is what we
do with it.
