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.
July 16th, 2010 on 9:16 am
I could not agree more. I have been in the IT industry for over a decade — the whole methodology is wrong! Why would I want to implement a project methodolgy standard where the bell curve rides the later part of my project! Business requirements are technical requirements. IT divisions within Corporations outsource IT Projects and submit ‘business requirements’ without their business’ participation. The outsource company refuses to scope in the main stakeholder and takes on a high-level risk for the project which results in failure – failure in the business’ eyes! I have tried to fix this as a thinking change – without success. However, I have fixed it within my project and proved success with the business! Would love the opportunity to rewrite the PMI, PMP approach!