coneblog

I feel I need to share with you a secret that I’ve struggled with for some years as an IT project manager – I hate project management software.

Yes, it’s true. I hate creating and maintaining detailed project plans in Project. It is not that I don’t appreciate the software package – I do. I believe that MS Project is the most complex software routinely available to users. It does a very complex job with considerable grace, and with relative ease of use. It has come a long way in the problematic tasks of updating project status, displaying large amounts of detail, and creating useful printouts.

That said, I begrudge the time I spend with Project. Here are some of the reasons why:

First, it is hard. Every time I create or update a project plan, there is always some group of tasks that is hanging out way to the left, at the beginning of time. For whatever reason they get detatched from the flow of dependencies, and need to be connected back in. But the tasks that they would link to are way over to the right. Or there are the tasks that you want to either start together, or end together, and are in some way dependent on another task, but something gets updated and the timing is all screwed up. Or you inadvertently try to create circular dependencies, which is not allowed, then you must track back and see what is miss-connected. I don’t mean to be a whiner, but I have used interactive software since TSO, and Project is among the most difficult major products to use.

Then there is the whole resource loading and estimating thing, in which several highly suspect sets of assumptions are supposed to make a valid whole. First you estimate the effort required to accomplish a task. The estimate is highly suspect, even when the scope is well-known, which it rarely is. Then there is the process of creating a roster of resource classes, and determining their availability. The whole fallacy here is that one resource is much like another, which ignores the five times difference I have observed in the productivity of one developer vs. another. Then there is the “leveling” process, which applies resources to tasks to generate schedules. But how valid are these schedules? By first principles, can crap multiplied by crap be spun into gold?

Here is more...

The projects that I do are “one of a kind” – that is, they are unique both in scope and in deliverables – different from the project before, and from the next project. Because of this, there is considerable uncertainty about the project during the planning phase, and considerable revision during the course of the project. MS Project is not agile in this area – It wants you to build the plan, and then work the plan. If your project is very dynamic, then you spend your whole week updating the plan rather than running the job. I know that there are many areas where Project is the right tool, but for me, most of the time, the value received is much less than the value expended in building and maintaining the plan.

That said, MS Project does have its uses. Many organizations must see a MS project workup of a project before it is approved. Those who don’t know how the sausage is made are comforted by lots of detail on the shrink-wrap label. Even the most out-of-touch executive knows by now that software development projects involve significant scope and schedule risk. And the finely detailed MS Project plan conveys a patina of order and control onto a process that is, as performed by many, out of control.

For a while, I took it as a personal crusade to deflate the practices and expectations around detailed MS Project plans for software development projects. I would point out that:

- The resourcing assumptions didn’t match the realities of developer productivity;

- Software development projects were, in general, not dependency bound – many tasks took place independently at the same time – especially if elapsed time is an issue. So the dependency nets that Project is good at are largely useless for most software projects;

- Waterfall project models, which is what usually comes out of a dependency driven tool like MS Project, have been widely discredited in favor of iterative models;

- Most projects are deliverables-driven, and the useful metrics are things like number of screens or number of pages of documentation. Project wants to be task and effort driven, and the focus on deliverables is often missed;

- The factors that blow project dates are usually issues driven (assumptions about the scope of a feature set, for instance) and these issues don’t show up on the project plan at all;

- Most effective projects are so dynamic that significant maintenance is required each week to keep the plan in step with the changing realities;

- The numbers and dates shown in the plan are dependent on so many assumptions, most not visible, many not documented at all, that, in reality, the summary dates and effort numbers are just a SWAG (structured wild ass guess).

I found to my surprise that no one wanted to hear my opinions about MS Project and Software projects. Executives viewed a detailed MS Project plan as evidence that the project is in control. My attempts at looking at deliverables, more realistic effort assumptions, and chopping the project into small cycles were viewed with puzzlement and concern. I was a source of FUD (Fear, Uncertainty and Doubt), and not welcome.

So, I’ve quit ranting about MS Project. I do my Project plans like everyone else, then pay little attention to them during the project. I manage week to week based on a few key dates, an issues list, and progress against key deliverables. I communicate project status in a summary form – key dates, deliverables and issues. Oh, I do occasionally update the MS Project Plan, and I print it out and have it on display in my pile on the conference table during meetings, just to comfort the faint-of-heart.

But if you have spent much time in the back room, where the sausage is made, you know that a detailed MS Project plan for a software development project is just that, a plan, not an execution document.

Larry Cone