MS Project, Early and Often
99.9% of the project managers I know have at least
heard
of Microsoft Project (MSP), and all understand it to be a very capable,
yet very complex environment for estimating and managing projects. But
it's Saturday evening and I'm a bit cynical tonight, so I'll say that
50% of those people don't really
understand
how it works - and have many reasons why they should
not
use MSP for this project or that ...
- ... this is an iterative development effort - not
enough requirements to lay out a work plan ...
- ... gantt charts are inherently waterfall, and this
is an agile project ...
- ... there are too many other things going on, and I
can't (don't want to) model everything that these people are doing
...
- ... this is a simple effort - small team, tiny
deliverables - MSP is overkill (the phrase "shooting rabbits with a
bazooka" comes to mind) ...
Cynicism aside, I think the last excuse is the most common;
unfortunately, this sets up a no-win situation. If we only use MSP for
large, complicated projects, when will we ever learn the basics? This
negative line of thinking is sure to take you down an unfortunate path
that ends in Excel task lists and endless emails looking for status
updates. A better approach would be to see project management as it
really is - not so tough once you learn the basics. (
Add little to little and there will be a big pile
- Ovid).
If you've ever used MS Project, you understand what I'm talking about -
there are a large number of defaults to set up at the outset. Also, you
need to understand the interplay between Resource assignments, Available
Units, Task Type, Effort, Duration … and when (if ever!) to use the
dreaded F9 (Level Resources).
Suggestion: start using MS Project now - even for the very small
projects! It's like any other complex skill - the more you practice, the
better you get. Why not work out the basic mechanics and concepts on
simple projects; when the more complex ones come around, it will just
be a step-function higher in difficulty. (Practice makes perfect, walk
before you run, etc.)
Three follow-up ideas on this topic, building on stuff from previous
posts ...
Document Standard Process
: As you develop your skills, you will undoubtedly develop preferences
for options / defaults, ways to make your projects behave consistently.
Take the time to document this stuff!
Templates Are Our Friends
: With more projects under your belt, you should start to see reusable
"components", like standard blocks of tasks for server configuration,
application testing, etc. Also - start to build your reusable list of
resources, standard calendars that fit your organization, etc.
MSP and PowerPoint Are Not Friends
: Gantt charts direct from MSP are
too complicated
. If you must deliver project updates via PowerPoint, better to develop
a simplified Gantt visualization using Excel or Visio (examples
here
and
here
).
Note
: I have an Excel sheet I use to create Gantt "pictures" - not useful
to track a project, but very nice to add a simple visual to a slide
deck (click on the picture for a full-size image) ...
It's not really ready for "prime time", but let me now if there is
interest - I'll clean it up and post it here.
Remember, the intricacies of resource, task, and cost management with
MSP are the easy part of project management - frees you up to work on
communication and change management - where the
Real
Project Managers
show their worth ...