In an earlier blog I wrote about some root causes of why a great percentage of IT projects fail. In this installment I offer so things to increase the likelihood of project success.
1. Train programmers to be business analysts and then get rid of the business analysts. I can hear the howls of the masses, but projects fail many times because of the disconnect between business analysts and programmers. I have actually worked in an environment where we have trained programmers to do BA work and have had great results. When programmers concentrate on business processes as opposed to “pure” coding, they are more likely to achieve the results needed and timely. Of course, you can always try to train BAs to be programmers, but I have my doubts about ability. Remember that I am speaking of BAs and not SMEs. Of course it would be great for programmers to be SMEs but one thing at a time.
2. Hire programmers not on specific skills as is done now, but ones with a general understanding of programming and with experience actually programming in a language. Languages are easy for programmers to learn. I now as I have learned dozens over the years. Put more emphasis on general programming WITH good business knowledge. A well-rounded individual will be able to fill gaps during projects then some cog in the wheel. I have seen my share of ridiculous requirements (12 years of .net experience which is not even possible, a laundry list of every technology known to mankind, etc). Stop it and hire more people with overall business smarts in addition to programming.
3. When you choose a methodology put some rigor and discipline behind it. Any methodology can achieve results if followed. Agile is a favorite now. It may or may not last but has achieved some level of success because it breaks projects down into smaller increments that have to be completed in a short space of time. At the very least agile will tell you earlier that you are not going to make a deadline.
4. Make people accountable. One of the problems of agile is that a team is responsible. It sounds good on paper and is really touchy-feely, but bottom line is that someone needs t be held accountable. I have seen agile teams easily wheedle out of commitments because it is too easy to deflect responsibility.
5. Good, Fast, Cheap. Pick two. Most projects want all three and that is not possible. If you are going to give a hard deadline for delivery then you need to give the flexibility to allow development to choose what will make it in release by that date. If you need a certain set of functionality allow development to choose the date. If you tell them to do the impossible in a fixed timeframe (probably most of the projects that fail) then plan to fail.
There are more things that could help, but if a project could even get one or two of these things right, the percentage of failure would decrease dramatically.
Good luck!
July 20th, 2010 on 9:44 am
Perhaps if you want to learn how to fix 62% of the projects in the future from failing; us must refer to the 38% of the projects that succeed. What perspectives can be incorporated into future projects which them successful. Also, adjust your emphasis within the Define phase as the largest and most comprehensive part of your project in place of execution. For example, Wii expanded their Define phase into such depth, it was merged with R&D. They go after ‘USER’ Requirements to ensure their success to gain market share.