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.

There are not many folks out there who would not agree with the statement that the IT hiring process is broken. The current process relies heavily on recruiting companies who solicit as many candidates as possible, but do not know the IT business well enough to properly screen candidates. Companies that have the jobs are not getting the talent that they need. Meanwhile, some very talented people are shut out of jobs they are properly qualified for. Frustration rages on all sides.

So if most agree that it is broken, what is my advice for fixing the problem? Below are just a few rational suggestions based on years of experience.

1. Fire the recruitment agencies and take back the hiring process. Recruiters do not understand your business – you do.  You know what you need so why dilute the lines of communication. In too many cases recruiters trash an applicant because they do not know that a person who has done OOP with Java is just as capable of doing OOP with .net.

2. No more making a laundry list of requirements. Boil down your requirements to just a few essential things. From the above example, do not ask for “10 years of .net experience.” I have seen this and it s ludicrous. If someone says they have 10 years of .net they are lying, but more importantly, this is not really what you need. What you need is someone capable of programming in .net. The true requirement is “substantial experience using OOP” because, as I stated above a Java programmer is very capable of learning .net and contributing quickly. You gain nothing by weeding out good people. You gain by weeding out unqualified people. (some will argue against this thinking but I have a great story of how this woks in a future blog).

3. Go with your gut and take a chance. Once you have the real requirements for the job, be willing to take a chance. In the state of Arizona we have employment “at will.” What does that mean to you? That means that you can basically let go of a worker at any time for any reason (short of discrimination).  Don’t think that you have some magic hiring process solution to find only great candidates. Hiring is a crapshoot where flipping a coin could be a better strategy then group interviews and personality assessments (at least you would save time and money). All too often a company will have multiple interviews and spend hours and hours and a great deal of money to select the right candidate only to set them adrift once they join the ranks. Spend less time with the hiring process. The key is to spend the time monitoring the new hire and if they are not working out to get rid of them quickly so that you can move to the next. The cost of keeping a bad hire because you are afraid to admit your “foolproof” system does not work is much greater than admitting a mistake and fixing it quickly.