If you're reading this entry and for some magical means all the projects you have been part of have succeeded, then you might want to skip to the next entry. If you're still reading, then just like me, you have been on projects that failed miserably. Needless to say, I have always learned something new from failed projects. The question is, "What makes IT projects unbearably susceptible to failure?"
I read an article by one Dr. Paul Dorsey and he discussed the "Top 10 Reasons Why Systems Projects Fail" and thought I'll share his thoughts with fellow IT managers and those who work on IT projects.
1. Don’t use a specific methodology because coding is all that is really important.
2. Create the project plan by working backwards from a drop-dead system completion date.
3. Don’t bother with a data model. Just build whatever tables you need.
4. Use a Technical Lead that has never built a similar system. Hiring such talent is too expensive.
5. Hire forty developers to make the coding go faster.
6. Build the system in Java, even though most of the development team still thinks that Java is coffee and you have no intention of ever deploying to the Web.
7. Three months before the system goes live, assign one junior developer to handle the data migration.
8. Skip the testing phase because the project is way behind schedule.
9. Change the system to support critical new requirements discovered during final development.
10. Buy a commercial, off-the-shelf package and customize it … a lot.
You may read the full text of the paper at: http://www.dulcian.com/papers/Top%2010%20Reasons%20Why%20Systems%20Projects%20Fail.htm
I've had projects go past deadline, or over budget, or have massive scope changes during the development process, or all three. I've had projects get scrubbed because the organization's priorities changed while development was going on. I've had projects go into production and never get used, because the person who specified the project was out of touch with the true needs of the organization.
I recognize that any of these could be considered failures from some point of view, but as a developer, I consider all of these things learning experiences, not failures. My perspective on failure is this: If the client tells me I failed to meet their needs, and doesn't give me a chance to fix that problem, then I've failed. I've had a couple of those in my career, but it's probably less than 1% of projects I've worked on.
Do other developers have more failures than I do? Or do you just use a more inclusive definition of the word "failure"?
@Josh - yes non technical folks making technical decision can be disastrous. Equally bad is tech folks making business decisions!
@David - at TeraTech we use an inclusive definition of project failure.
So we consider over budget, late, massive scope creep, shelfware or canceled projects as failures. We measure project successes by project manager each quarter. Currently our success rate is 93%. That is 93% of projects are done in budget, on time and in quality and are used by client. And yes I totally agree that every project failure is a chance to learn and grow. As is every success too! :-) (We do a lessons learned meeting with our clients after every project to learn from what we did or didn't do)
http://www.dulcian.com/papers/IOUG/2000/Top_10_Rea...
I'm sure there are more recent studies out there that will include other factors.