How Long Should it Take to Define a Project?

25 Jan 2007 /

Project X hit a milestone called Vision/Scope seven months ago, 99 days late. It’s 312 days late on the current milestone, which is called Definition.

To date, the project has consumed 36,000 labor hours — 18 person-years — and $2.5 million.

At this morning’s enterprise-level status meeting, it was decided that Project X will be put on indefinite hold, as it is no longer a strategic priority.

This reminded me a lot of an article I read a few days ago:

What the waterfall does well is to keep useless projects from resulting in useless code that needs to be maintained. I’m not sure if that’s the real purpose, but it’s certainly a great side benefit. It may sound inefficient to pay a lot of engineers to get started on projects, do a bunch of analysis and design, and finally abandon the whole thing when something else becomes a higher priority, but every line of code they don’t write is another line that can’t break!

OK . . . you could make a case that waterfall “worked” here — clearly if, after 18 years of effort, people can’t even define the project, that sounds like a project that has no chance of success and shouldn’t be attempted — but it worked at a cost of $2.5 million.

That doesn’t seem very efficient.

What I find is that if you put the customer, the technical team and other appropriate representatives together for as little as four to eight hours, à la a Sprint Planning Meeting, it should be obvious whether or not anyone understands the problem well enough to go ahead and attempt a software solution.

Thus spoke The Programmer.


No Comments on How Long Should it Take to Define a Project? »

Why not be first?

TrackBack URI

RSS feed for comments on this post

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>