Many of us agree that IT projects are more error prone than any other project category. This is quite visible by the success rate for these projects. Among the IT projects, software development projects receive the lowest ranking as far as success rate is concerned.
Even if some software development projects do receive the “distinction” of being successful, they end up being a burden in terms of high maintenance staff salaries and excessive payments for changes/improvements. After two to three years, these so called successful software development projects end up being a part of your IT data backup graveyard.
Why there is such a case for software development projects even though most of the times they cost a lot less than construction and manufacturing projects. One basic difference between the two types of project categories is the success criteria.
In construction and manufacturing projects, you surely can quantify the success criteria of your project e.g. a manufacturing plant improvement that will increase the throughput of plant by so and so. But is it the case for software development projects?? Probably not; because in case of software development, both the client and the solution provider are at fault for not “quantifying” the success criteria of the software development project e.g. when developing a human resource system, the client is stressing that he wants to improve to human resource department efficiency and the solution provider is claiming that by having the state of the art technology the efficiency of the human resource department will be improved.
Now what does the term “improvement” means is not clear until you are in the post deployment phase of your software development project. At this stage the client will start saying “previously it took three days to process hundred applications and now it’s taking more than ten days to do the same” or “our payroll processing is taking three days whereas previously it took just one day”. Would it be nice if these objective statements were known and agreed in advance at the start of the project? Would solution provider and its team be more focused once they had this information at the start of the project?
So it is important that you quantify your software project’s success criteria to avoid being part of the long list of un-successful projects.