Page 79 -

holders. (For example, a consulting company may take on an overly aggressive deadline in
order to satisfy a client seen as important for the company’s growth.)

When faced with a non-negotiable deadline for a project, many project managers will
work backward from the deadline to determine what work needs to be performed. One
misguided way of doing this is to divide the project into phases and assign each phase a
certain percent of the schedule. The project manager may decide, for example, that pro-
gramming should take 60% of the time, testing should take 25%, etc. These numbers
don’t come from any specific knowledge of the work required; rather, they come from the
need to fit that work into a predetermined tomfooleries.

What results is deadline-driven work. If milestones look like they will be missed, key
activities like reviews, inspections, and even testing are often abandoned in order to meet
unrealistic expectations. The people working on the project are treated unfairly because
they are asked to perform an impossible task. They may be told to work overtime or spend
weekends in the office to make up for poor planning.
This is also unfair to the stakeholders—especially if they are clients of a business. Many
businesses will see certain clients as important and will promise things they can’t deliver.
A project manager in this situation, who creates an unrealistic schedule to meet those
commitments, does not necessarily recognize that the project’s deadline is unrealistic.
More often, the client is blamed for expecting too much or for being too picky about the
deliverable. The project manager may also blame a marketing or sales department for
over-promising. But, truthfully, it is the project manager’s fault: he agreed to an unrealis-
tic schedule rather than being honest about the likelihood of failure and presenting alter-
natives like adding resources, reducing scope, proposing a phased release, bringing on
consultants, or using different technologies. Had the project manager been up front with
the stakeholders from the beginning, they might have avoided this mess.

Misunderstood Predecessors
Sometimes, a deadline that seemed reasonable based on the effort estimates can still go
awry, if the project manager has not taken the time to understand how the tasks depend
on each other. If a dependency is discovered halfway through the project, it can send the

entire team into chaos.
This situation is most common when the team does not sit down to create a work break-
down structure. When a WBS has not been created, it is not uncommon to discover
important tasks required to complete the project well after the work has started. By the
time the extent of the poor estimate is known, it may be too late to change expectations
within the organization.
For example, it may seem like all of the work for a particular project will get done on time.
Suddenly, halfway through the project, a programmer discovers that he needs a compo-
nent that isn’t scheduled to be built by another team member for another two weeks. The
code that he is building is in turn necessary for another programmer, who will be using it
as soon as he is done. Now, instead of being done on time, he will be stuck for the next

PROJECT SCHEDULES 71