VirCIO Group

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!

CIO.com cites a Dynamic Markets survey of 800 IT managers, reporting that 62 percent of IT projects fail to meet their schedules, 49 percent suffered budget overruns and 47 percent had higher-than-expected maintenance costs. This number has been about the same since the inception of software development. During that time there have been a number of silver bullets that have made consultants rich, but project continue to fail at a high percentage. Why?

In my many years I have seen the trends come and go – PSP, TSP, TQM, CMM, Waterfall, etc. I have seen success and failure with each model. In fact, contrary to popular belief, any model can work and will work because at the root they were all devised to fix one major flaw with software development – discipline.

Many of the articles I have read on the subject point to communication as the major flaw (and with good reason). Technology can be complex and those who understand it (the programmers) are not particularly adept at communication in general, let alone communicating complex ideas to those who are responsible for the “business” side. Programmers like nothing better than to work alone, not to be bothered with having to communicate. On the other hand, those who fancy themselves business analysts have a hard time understanding technology and communicating how a business need can be translated into software.

Not only is there the problem of communication of technology, but there is a huge disconnect between sales/marketing and development. Sales will come up with an unrealistic schedule. Development, because they are geeks and not great at communicating, will generally acquiesce or fail to communicate the impossibility of maintaining unrealistic schedules. Most projects succeed when the abilities of  development are realistically understood by sales and marketing but this rarely happens.

Thus, in order to bridge the communication gap, each silver bullet methodology tries to tackle the issue of communication. And, for the most part, they successfully address communication problems, but this is more of a symptom than a root cause.

Where projects and methodologies fail is that each was created because software developers lack discipline. Agile is now the flavor of the day and has relative success in the fact that it is very regimented. There is a great deal of discipline that is necessary for software projects to succeed. However, software programmers are not built that way. Not only are they, as a rule, socially inept, but they are enamored with technology. The like technology for technologies sake and that is extremely dangerous. Remember that software is merely a tool that is used to achieve some business purpose, but notice the reaction is you ever talk with techies about business purposes. Their eyes glaze over. They want to play with technology. they want to “try” new technology. They do not care for business purpose and will go off on programming tangents if given the chance. that is why a new methodology is created every few years as a means to keep programmers on “task.”

This is why failure continues to happen, but what are the solutions? I will tackle that in my next blog.