Wednesday, April 23, 2008

Projects and why they fail

It has been a while since I was solely responsible for the outcome of a project. That is probably a good thing. I have led teams of people on a number of projects across a wide range of technologies and services. Common to most of these efforts has been a team of devoted engineers, programmers, and project leaders committed to getting the job done. In spite of those efforts sometimes projects to fail. The big question is, why?

It has been my experience that projects that drag on have a higher likelihood of "failure" than those that can be brought to a conclusion more quickly. On the surface it would seem that efforts that extend beyond 18 months are often doomed to failure. The key to preventing this type of thing from happening is to bundle tasks into projects that are more manageable and can be achieved in under 18 months. We used to have a saying of "build a little and test a lot". When implemented it might mean the ultimate end goal is still 2 years away but measurable progress can be made by closing out a "project" and opening a new one to allow for more progress to be made. This often means you can bring in a new team of people for the follow-on effort and possibly prevent burning out your team. At the same time you can also facilitate more junior folks to gain valuable experience and see measurable progress faster.

The above is true for development projects, infrastructure upgrades, and even maintenance efforts.

No comments: