Despite more than 50 years of history and countless methodologies, advice and books, IT projects keep failing. Depending upon which academic study you read, the failure rate of large projects is reported as being between 50%-80%. Because of the natural human tendency to hide bad news, the real statistic may be even higher. This is a catastrophe. As an industry we are failing at our jobs.
Common Sense
So, what really causes these systems projects to fail? Is it some technical secret that most systems engineers don’t know? Are software projects so drastically complex that only the most talented teams have a hope of succeeding? Many of us have personally been involved in both successful projects and projects that crashed and burned. The sad fact is that software projects fail because we do not recognize that good engineering principles should be applied to software projects just as they are to building office buildings. We try to defend ourselves by saying that software construction is “different”.
The conclusion is that the best way to make a project succeed is to use your head. How can we avoid making the mistakes that lead to project failure? Surprisingly, the answer is most often simple common sense. Our problem is that common sense is often ignored in systems projects.
Architecture is the key
Projects are frequently built using a strategy that almost guarantees failure. Building a large information system is like constructing a 20-story office building. If a bunch of electricians, plumbers, carpenters and contractors meet in a field, talk for a few hours and then start building, the building will be unstable if it even gets built at all.
“If building engineers built buildings with the same care as software engineers build systems, the first woodpecker to come along would be the end of civilization as we know it.”
If we would keep in mind that building software is just like building an office building, then most of our problems would go away. Before building an office building, an architect draws up detailed plans, builds models, and makes blueprints. At each stage, the plans are carefully and repeatedly reviewed. During construction, each step is tested and inspected. In software projects, if we haven’t started writing code in three months, we mistakenly think that something must be wrong. Can’t we see the senselessness of plunging ahead without a careful plan?
Methodology
Many systems are built with little thought to process. The team gets together and starts performing activities. As soon as enough information is gathered, coding begins. This lack of attention to process can kill a system. It is easy to see the result of a lack of attention to process after a system fails. Usually major portions of the user requirements are ignored. Large amounts of code need to be rewritten, since it does not meet user requirements the first time around. If completed, the system is put into place with inadequate testing. Without a well thought out process, there is little chance that a systems project will be completed. If the project does succeed, it only does so with substantial rewrites and cost overruns.
It may be surprising to think that the methodology selected doesn’t matter, but in fact this is basically true. What does matter is that there is some methodology. Different methodologies all gather the same information but organize it differently. One may have additional, unnecessary steps. Another may miss some steps requiring developers to backtrack to earlier phases. The important point is to use some methodology successfully.
Technical Leadership
Just as a building needs an architect, so a software system needs a technical lead. To be successful, the architect or technical lead must be the one in control of the “architecture” of the project, namely the data model and application design. This level of control must be recognized and acknowledged by everyone involved with the project. Otherwise, each portion of the system may be constructed independently by a portion of the team and the pieces won’t fit together at the end.
The technical lead must have built similar systems down to the level of the specific business area for which the system is being built.
So…
In order to ensure success, there are several factors to keep in mind:
– Don’t cut corners, methodologically. In the long run, this results in system failure or an inadequate system that doesn’t meet the users’ needs.
– Audit each major deliverable and step along the way for accuracy and correctness.
– Carefully monitor top management support for the project. Make sure that managers are aware of the progress of the team.
– Secure the correct technical lead for the project.
There is no free lunch in software engineering. If you insist on keeping costs low and hurrying the project along, then quality will be low or the risk of failure will be high no matter how well the project is managed.
Nemanja Kostic 