Most everyone starts their project with a schedule. They define the work that needs to be completed in the form of activities with varying levels of detail. They then identify the duration of each activity and sequence them based on interdependencies, and may also associate the level of effort (hrs) to each activity. When all is said and done the final product is a schedule that documents the overall duration of the project and perhaps the total level of effort as well. Great! There’s nothing better than a good plan at the start of a project.
However, no sooner than the first week of the project something happens . . . things don’t go as planned. Activities that should be completed aren’t. Others that were scheduled to take the entire week finish early allowing for new activities to begin that weren’t originally scheduled to start until the following week. So much for a good plan. Now we have a schedule that doesn’t reflect reality.
There is nothing unusual about this situation. It happens to every project. But, one of the things that separate the good project managers from the bad is how dynamic their project schedules are.
As work begins on projects actuals-to-date are recorded and estimates-to-complete are re-evaluated for some subsets of activities. This often results in a change to the initial predictions; however, these changes may or may not be realized in a timely fashion depending on how dynamic the schedule is. Knowing the true current status of a project is paramount to delivering it close to the initial time, cost, and scope predictions. It’s all dependent on the frequency of the updates (actuals-to-date and estimates-to-complete) and the underlying structure of the schedule.
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. 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. When updates are only accounted for once or twice a month and the underlying structure of the schedule is in the head of the project manager then scheduled updates will be infrequent and often not reflect reality.
This is what Kevin experienced when he was asked by the CIO of a Fortune 100 company to audit an ongoing $20 million project that would overhaul the financial applications for the company. He began his quest by interviewing the project sponsors, program manager, and project managers. The general feeling he got was the project was progressing well but was a little behind schedule. After his interview with the program manager, Jessica, he asked if he could get a copy of her schedule. Jessica inquired if he wanted it in the standard format; however, Kevin didn’t know a standard format existed. Jessica led him to the break room and showed him a large four foot by eight foot, six phase Gantt chart with a version date of seven weeks ago. Kevin’s stomach sank as he realized that the project audit was not going to go very well.
Small and simple projects can be effectively managed in the heads of the project managers using a Microsoft Excel spreadsheet to record major milestone dates, but don’t try this with larger more complex projects. It will lead to major surprises, lots of bad news, and missed opportunities. Build your schedules using a highly dynamic underlying structure and you’ll save yourself time and a lot of headaches.
feedback
Would this be a wrong place to say that MS Project isn’t really a good tool for managing software projects?
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).
Thanks for taking the time to comment on my blog post.
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.