What Microsoft Project Isn't

All of the normal disclaimers apply here. While I have a vested interest in seeing dotProject acceptance grow and flourish, I do not have a vested interest in ripping Microsoft Project to shreads. In fact, I like seeing it thrive… let me explain:

I've used it regularly since 1998, have a number of books on it, have (legitimate!) licenses of every version from 2000 on, but that doesn't change the truth: Microsoft Project is an excellent project planning tool but it is not a project management tool.

Project planning is the process where you gather the information relevant to your project like the task estimates, dependencies, deadlines, and relevant resources (in human-speak: people). You take all of these numbers and match them to a calendar combined with the other aspects like company holidays, vacations, etc and you get an estimated set of release dates. Interesting and vital aspects such as the Critical Path pop out of this analysis and can be used as indicators of project status. If you really want to get advanced, you can apply likelihoods to your estimates and apply Monte Carlo simulations to estimate a range of completion dates and likelihoods of making them. Microsoft Project handles many of these aspects beautifully and even draws impressive pictures to make them crystal clear.

As an aside, I believe the above areas are where dotProject can make huge strides. Microsoft Project has not only done these aspects well, but they've done them right and I continue to be impressed by them.

Unfortunately, somewhere along the way, an entire generation of project managers were taught that these planning practices were “project management”. True, they are an important part and you can't successfully complete a project if you don't know what needs to be done, but it doesn't end there. Project management is a day to day and task to task process that involves people. The Agile community has codified this point with the “daily standup meetings” because they realize that projects are dynamic and change on a day to day basis. In order to keep up and know what your milestones are, this sort of feedback has to happen and be reflected in the project plan.

Sure, you can have a team member that updates your project plan after each one of these. Sure, you can republish a new wall decoration for everyone in the team. Sure, you can pass along a copy up the chain or to your customers. But the fundamental question is: Do you have time to do this? Do you have time to reconcile the various versions? Do you have the desire to explain what is/isn't different about it every single time?

Congratulations, your project plan has become yet another piece of documentation that needs to be updated. The worst part is that unlike technical specs or coding comments (like JavaDoc, PHPDoc) or even filling in a daily/weekly timesheet, updating the plan is a task that is done on top of everything else and it doesn't contribute to moving the project along.

In order for Project Management to be effective and worthwhile, it needs to become part of the daily operations and consideration of a project. It can't be an afterthought and it's certainly not a checkbox. Alternatively, project planning and scheduling is (almost) a checkbox, doesn't need to become a daily part of a project, and this is where Microsoft Project shines.