On Fri, 3 Oct 2003 10:20:14 -0400, "Tom Gardner"
wrote


Are there any secrets to managing projects that you will share?


I did project and program management for part of my engineering
career.

In order to plan a project you must first reach a realistic estimate
of how much time, labor, $, etc the project will take. "Realistic"
means what your experience and that of others say the project will
really take, not colored by pipedream expectations of a manager or
customer who doesn't have to do the work. Compare the job or
portions of the job to other jobs you've actually done in forming your
estimate. Break the job down into tasks and subtasks that you (or
someone else) can easily understand and accurately estimate.

You must determine the priority of the job and therefore your ability
to resist interruptions and distractions. If you'll spend 40% of
your time putting out fires or being diverted to other higher-priority
work, plan that in because it'll happen.

Try very hard to insist that all requirements are clearly and
completely defined and specified before you even estimate the job,
much less start it. This is crucial. Customers and managers
sometimes hate it when you refuse to start before the project's
objectives and deliverables are very clearly defined and the spec is
set in stone, because that requires them to make decisions and
commitments rather than just jerk you around mid-project with
variations, changes, or expectations they didn't bother to mention
up front.

There are project management tools like MicroSoft Project, PERT
charts, etc that can help you dissect a project into tasks and
subtasks that are easier to estimate, and they help to form a
realistic schedule, find critical paths (this can't start until
that's done), anticipate and plan resource requirements, etc.
They're useful tools, but don't make a religion of it.

When (not if) the unexpected happens, replan the whole project
immediately with focus on how you will get back on schedule if it's
really important to finish on schedule. How will you do that? More
resources, work overtime, bring on help, what? In a well-planned
and carefully-estimated project some tasks will go better than
planned while others will encounter unanticipated problems. Stay
flexible and adaptive. Do *NOT* share your program plan with a
manager or beancounter; if you do they'll waste huge amounts of time
with item-by-item progress reviews thinking that they're "managing".
Make a simple phony program plan for their consumption.

Do include everyone on your team in the formation and subsequent
revisions of your "real" project plan. You want their fingerprints
all over it because you need their experience, ownership, and
commitment to the plan they helped make.

I used to publish a bogus program plan for the beancounters to review
but kept the real project plan on a whiteboard in a conference room.
It was a living plan, got modified as appropriate based on experience
and actual events. The end date didn't move, but the plan to get
there often did.

We sometimes went for weeks without a meeting, sometimes had three
meetings a day when wheels started to come off. When things were
going smoothly I had no problem with guys taking an afternoon off to
go fishing or take the kid to a ballgame; I did it myself as well.
When things weren't going well I expected assholes and elbows from
everyone (including myself) to get things back on track. No team
can work balls-to-the-wall every day; they burn out after a couple of
weeks of that. A "max effort" plan from start to finish is totally
unrealistic and will surely fail.

If you are to complete a project on schedule within budget then you
must be utterly committed to that goal from the git-go. You must
define the objectives, expectations, specifications, deliverables,
schedule and budget as realistically and accurately as you possibly
can before you even think about starting the project.

When faced with a "fuzzy spec" and a customer who didn't really know
what he wanted but just wanted to "start work", (often the case) I
broke the project into phases. Phase zero was to define the spec and
plan the execution phase schedule and budget. Occasionally we found
in phase zero that the customer's expectations for the project were
unrealistic, unachievable, or too vague to estimate accurately. In
those few cases we avoided a serious overrun and unhappy customer by
not even starting phase 1 (execution) that would have been doomed to
disappoint. Such projects were either killed or shelved until the
customer's expectations became more aligned with reality.