Geeks With Blogs
Chris Breisch   .NET Data Practices
Search this Blog!

This is a great quote:

When you work in IT, you deal with the consensual hallucination of Project Management. There is an almost universal belief that it is possible to predict ahead of time how long a project will take, how much it will cost and what will happen along the way. In the broadest sense, this is possible. If you have enough experience you can come up with ballpark figures; last time we did something similar it took this long and cost this much.
But some people believe Project Management should tell you these things down to the day and the dollar. A project plan should tell you every task that needs to be completed. A project plan should be flawless and leave nothing to chance. And a project plan should be completed before ANY work is done on the project.

Despite the fact this is clearly insanity, it is a terrifyingly common mindset in management ranks. Project planning and goals are obviously important at some level (otherwise how the hell would you know what you are doing?) but how did we move from “let’s have a clearly defined set of project goals and a strategy for how we’ll get there,” to “this is 100% accurate, carved in stone and will never change”?

I've never really thought about it before, but this is true.  And he's correct that it's clearly insane.  How many times have you used Microsoft Project (or something similar to manage your project, and how many times have you felt like that worked out well and was a success?  What's the age old quote?  The definition of insanity is repeating the same thing over and over and expecting different results.

What's the solution?

Well, the first step is to kill all the consultants.  Okay, maybe that’s a bit harsh.  Let’s limit ourselves to killing the consultants who act as though they have some mystical powers that enable them to succeed where all other have failed.

Ok, clearly that won't work, but the point here is valid.  There is no perfect solution.  The developer has to take some responsibility.  Be willing to say "I don't know".  Know what your risks are.  And as, Jeff Atwood suggests, read McConnell's Software Estimation: Demystifying the Black Art.  And avoid Waterfall and BDUF at all costs! Posted on Wednesday, November 22, 2006 7:54 AM Architecture | Back to top



Comments on this post: Why Microsoft Project Sucks at Managing Software Projects

# re: Why Microsoft Project Sucks at Managing Software Projects
Requesting Gravatar...
I think that the "I don't know" is less a problem of the employee being willing to say it than the manager being unwilling to accept it.

At least that's my experience.

I was always more comfortable with the honesty of "I don't know" than "2 weeks" when 2 inevitably became 7.

I think the larger part of the problem is managers who have not done exactly the work they are managing.
Left by vern on Nov 22, 2006 5:32 PM

Your comment:
 (will show your gravatar)


Copyright © Chris J. Breisch | Powered by: GeeksWithBlogs.net