The Five Fundamental Rules of Project Management
Okay, the title is a bit of a false advertising. I'm not revealing
the top five rules - I'm actually looking for help in defining rules
3-5. Any input is appreciated - care to weigh in with an opinion?
I've had a number of discussions, with some of the best project
managers I know, as we discuss ways to simplify methodologies and
streamline our delivery process. Many organizations are trying to train
their next generation of project managers, and all seem to run into the
same basic problem. You can hand someone the PMBOK,
teach them how to use MS Project, and send them off to PMI certification
classes - but that doesn't guarantee an effective project
manager. The toughest thing to train is the "soft skills" - how to get
things done through other people without being able to tell
them what to do.
Through these discussions, we've tried to come up with the Five
Fundamental Rules of Project Management. Methodologies, documentation
styles, collaboration tools & design frameworks come and go, but in
the end - these are the critical things that you must focus on to be an
effective PM:
- Manage Expectations: This is Rule Number
One, and I typically get agreement on this pretty quickly. It
encompasses communication (early and often) plus clarity of
requirements. I once had a VP/GM tell me to never be afraid of
delivering bad news as long as you give people plenty of
time to react. Budget overruns and missed dates can be managed - but
it's a lot easier to manage things with two months warning. Never
wait until the day before a go-live to drop the bomb!
- Watch the Critical Path: A cynical way of
saying this is stay off the critical path; the best project
managers are adept at identifying what truly is the Next Most
Important Thing to Work On, and focusing their effort to make sure
these items don't delay the project. A laser focus is not quite what
you're looking for - you need to be able to anticipate what's next on
the critical path, and what other things are close.
Now, here's where the conversation decomposes - I can get clarity
on 1-2, but there are any number of candidates for the next three of
this Top Five ...
- Manage Scope: Software development as well
was system implementation projects often suffer from the creeping
feature creature - deadly enemy of all delivery dates
- Calendar Time vs. Effort Time: Project
estimators and schedulers often need to clearly define the
difference. MS Project demurely offers the Duration column, and all
too often your estimators will ask "how much time do you need", and
get answers from developers, documenters, testers, and domain experts
all trying to make sure they won't come in "late"
- Project "checkpoints" and Go/No Go Reviews:
A mechanical means of managing expectations watching critical path
and managing scope. If done correctly, this also allows a project to
make significant course corrections, and even get cancelled. If it
made good business sense to start a project, it's reasonable to think
that when conditions change, it can make good business sense to stop
a project. Scheduled checkpoints are built-in escape hatches.
- The Iron Triangle: Better? Faster? Cheaper?
Pick
two.
- Definition of Success: Projects, by
definition, end. Many projects suffer from a lack of clarity
around when the project ends and when the operational system
begins.
- Executive Sponsorship: This will only work
if the bosses jam it down their throats ... I mean, make it a
priority
- Business Process Ownership: This will only
work if the people involved in the process take an active part in
Design and Test
- Get Out of the Way: Project managers need
to understand when to be managers, and when not to be
do-ers. Too often, folks with technical skills are promoted to a PM
role without enough training, and when the project gets tight on
time, will grab the wheel and try to get it all done themselves. This
works in small organizations or smaller projects, but it just doesn't
scale.
I'm sure I am missing a few, and I definitely have more than five
here. Anyone care to weigh in on my "course syllabus for PM 101"?