I understand you have your project experiences that drive you to certain opinions. I’m not going to challenge them as I have not been in your unique shoes; but, let me give you some of my experiences that support my views.

We have worked with dozens of clients who have chosen to adopt our project management methodology through training and coaching. The majority of them have been in the software development space, but others are developing other products such as drugs or appliances. MS Project is the tool of choice for 80% of these engagements. On average the PM only spends 2 to 4 hours per week on maintain the schedule to reflect reality on the project. There is a very systematic process has to be followed to reap this level of efficiency.

You are so right that the accuracy of data input into the schedule effects the output of the schedule. The great thing with using the tool is that you can help each person become a better estimator by providing them metrics and trend data that compares their estimate to their actuals. They get better on their own which results in better crap in and better crap out.

I wouldn’t be so quick to throw MS Project out on Agile projects. Agile and the classic waterfall methodology are at odds because of their drivers: Waterfall being more scope driven, letting time and cost figure themselves out, while Agile is time boxed with iterations that let scope and cost figure themselves out. Yes this is very simplistic view, but when it comes to a dynamic schedule it works; and, even more so for the Agile project then the waterfall one. Tasks have to be marked duration driven and let the resources and effort flex to meet the duration. When errors are generated during maintenance of the schedule it is because you are trying to do too much with the resources than the schedule can handle. In other woods you are living in a fantasy land believing you can get more accomplished in that time frame than your really can.

These are just my experiences. We may continue to disagree but I appreciate you putting your thought into words on the blog. Thanks.

While I agree with some statements in this blog post, such as that change comes too quickly to be managed by a static plan.

What I disagree with are:
“Highly dynamic schedules are always built using the full functionality of a project management software tool such as Microsoft® Project. There is just no way to get around it.” – Yes, there is. I’m yet to see a good software project managed effectively with MS Project. They always end up being way too complex to change and manage. The PM’s job tends to become a Gantt Chart Maintainer instead of project leader. MS Project IS NOT a dynamic tool for managing software projects, even when you use it to its maximum effect.

“But, one of the things that separate the good project managers from the bad is how dynamic their project schedules are.” – I would say the difference is in how the project managers can instill a shared goal (including schedule issues) in the whole project team and thus enlist everyone’s commitment to meeting the project goals (assuming they are even remotely realistic). Ok, this is not exactly a disagreement, but more an addition.

“Managing the current status of all the activities, maintaining the interdependencies, and calculating the estimated completion date on a weekly basis can only be accomplished with these tools.” – The problem here isn’t the level of detail available, or the tool, but the accuracy of the information used for the calculation. Unfortunately, plans based on tasks and their completion (especially if partial completion is acknowledged), rather than completed functionality proven to work, are highly unreliable. “90% done” is not 90% done. It can be anything from 10% to 99%. If you can’t trust the data, you can’t trust the calculation. Bullshit in, bullshit out.

The only reason I personally would use MS Project for is to create a very high level overview of project progress. And MS Project would be there mostly for visual reasons. I might just as well use Powerpoint. Great plans are not made in a tool; they are made in the minds of the people involved, converged together in collaboration into common shared understanding of where the project should be when, with what desired capability. Actually, several plans would be needed, at different detail levels.

When referring to a $20M project, it is obvious that serious leadership is needed. I believe other factors than choice of tool is needed for managing such projects. Those who can do it, can do it with a tool of choice. Those who can’t, can’t with any tool really, no matter how savvy or well-used. However, very few of us ever get to manage anything close to that size.

My comments probably make it clear that I’m from the Agile camp. I strongly believe in incremental and iterative development. MS Project isn’t a tool for managing those projects. It’s a waterfall tool. However, it’s not that I’ve never used Project before and that I’d be against it merely on principle. I have used it (though on a mere $1M level) and it was a mess. Back then I didn’t know better, so I struggled with it (because almost every change recalculated the schedule and end dates and order of activities and load balancing and such).