While software development is a type of engineering, there is an apparent disparity between the percentages of engineering projects that fail and software engineering projects that fail. Statistically speaking major engineering project have a failure rate between 10% and 30% based on personal experience as a retired US Army civil engineer. That is in stark contrast to software engineering, where three years ago the failure rate for software development was bouncing around between 60% and 80% and today it is not much better. This paper will address why projects fail or the root cause of that failure.
Then we will look at reviewing the twelve warning signs that identify trouble in a project. Finally we will look at best practices to prevent failure of software engineering projects. Keywords: software failure, technology project management, preventing software development failure. As a United States Army Civil Engineer with over 20 years of project management experience and as the Construction Operations Sergeant supervised Task force Eagle in Bosnia, where 150 personnel constructed 5 projects totaling over 150 million dollars and making the transition from that career in engineering to a project server administrator and project manager for Microsoft, deploying their enterprise project management software globally for them, qualifies me to write this paper from firsthand experience, but I also have researched and provided documentation in support of these views also.
Having an insider’s prospective on this subject which I love called project management has shown me different projects in civil engineering that have failed because of major mistakes. Major civil engineering project failure is 10 to 30% statistically and although I have never personally had a project failure and have always finished on time and under budget. This doesn’t compare though to IT project failure and software engineering, as it has the worst failure rate of any engineering discipline, at a whopping 60-80%. (Dolinsky, 2011a)There are major failures in civil engineering and I’ll share one here with you now that I know of. How about the $30,000 dollar glulam beam which was cut short by three feet because the person measured it wrong! The project being in the Marshall Island chain on Kwajalein Atoll in the middle of the south pacific made it a two month wait on the project to finish because it took that long to get a new beam there by ship.
Manly because the beam was 110 feet long and would not fit on a plane. The entire cost of getting the troops there was doubled and the list of costs escalated because of the mistake. Needless to say that construction platoon sergeant was looking for another job after that error. But this error and the many like it are small compared to the number of software engineering projects that fail.
The fact that the different SDLC phases and methodologies that have been developed don’t seem to be changing the numbers is dismal. The percentages of failures seems to be maintaining at 60-80% and this is mainly due to the missing “level of competency” being higher than 70% in companies surveyed about the cause of this failure. (Krigsman, 2008)Why does software engineering have such a horrible track record of success? The level of competency is one, but also to consider is what those who competency is lacking are missing. One word describes this and that is improper analysis that determines the total requirements for the project. This inability to perform a proper business analysis is a capability deficiency that will cause 3 times as many project failures versus project successes. 50% of all poorly analyzed projects become runaways, resulting in the project taking nearly twice as long to complete at 180% and costing over budget at a 160%.
Even after these atrocious numbers these same projects deliver less than 70% of promised features. Here is an amazing number for you to digest and that is nearly 41% of the IT budget is consumed by inadequate requirement analysis. These poor business analysis requirements definitions compromise objectives, quality, schedule and cost, which all affect the project plan. (Krigsman, 2008) (Dolinsky, 2011b)In most companies people have heard of BRD or the dreaded Business Requirements Document and for software engineering this is a critical aspect of a proper business analysis, but it doesn’t stop here.
These requirements must be bought into by key stake holders and signed off on and then locked in. well it is this last one that is another killer for projects, better known as scope creep, where the requirements keeping changing all through the project and this is a close second to project failure. Once business requirements are verified and locked in changes only hurt the chances that project will be successful. The next big pitfalls are time, resources and quality during software engineering.
All of these subjects are intricately linked to one another in software engineering, as the time it takes to complete a project is related to how many resources are placed on the project and more is not always better. Also the quality of software is directly related to how many people are put on the project and how many function points are in the design metrics planned in the design concept. These will need to be connected together and the quality from programmer to programmer varies. The result of these three subjects is the estimate which is where costs are derived from. It one of these subjects move, it directly affects the other two and therefore the cost. (John, nd) (Mun, 2011)The size of any project does also weigh in heavily in civil engineering as well as software engineering.
An example is build a shed in your backyard has a pretty good chance of success compared to a mile long float bridge across the Sava River in Bosnia. The 502nd Float Bridge Engineers who built that bridge lost 16 M16A2 rifles during construction over the raging river, which I would say was an epic failure, but history may have something else to say, because we did cross that river on that bridge in the end. Well in software engineering it is the same principle, but software is broken down into function points which were discussed earlier and those project with less than about 50 function points or 50,000 lines of code are usually successful and those with 10,000 to 100,000 function points tend to have issues. The point here is this is why software projects are broken down in to small manageable chunks to ensure success.
Using the right tool to identify and communicate bugs during the design process is another critical aspect of good software engineering and we use VSTF 2010 (Visual Studio Team Foundation) at Microsoft which interfaces with Project Server 2010 which we use for project management. (Mun, 2011)(Dolinsky, 2011b)I would be seriously shortsighted if I didn’t mention testing as a major cause for failure of software to succeed. This is mainly because companies don’t involve the end users in the actual testing of all processes. This show a lack of participation of stake holders to engage or users would be involved.
Not utilizing them properly causes huge complaints like: confusion and difficulty using the software; features missing and features added which are not useful or liked; lack of user friendliness or appeal; general morale issues with everyday users. This is usually caused by a reckless and unfriendly customer focus or environment in the software development department. You have to engage completely the customer during the development process and that is the end user. (Commedia, 2011)Ok so you understand how projects fail now, but the point and conclusion for this paper is to prevent failure and identify the warning signs ahead of time and change the possible failure to success and here is what to look for. There are twelve signs of pending project failure separated into two risk groups. The first one is people related risks and the second is process related risks.
The people related signs that are risks to a project failing are as follows: A lack of top management support for the project. A weak project manager assigned to the project. Stakeholders are not involved or participating in the project. Lacking commitment from the team or interest from the team in completing the project, and this is usually caused by not involving them enough in the design.
A lack of knowledge or skills in the team required for the project to succeed. The subject matter experts assigned to the project being overscheduled and not able to consult adequately. The process related risks to look for are as follows: Not having a defined business case for the project. Lack of documented requirements for the project, or success criteria defined for the project. No change management processes defined to control and mitigate change for the project.
Lack of management or ineffectual planning during the project scheduling or any phase of the project. Communication breakdown from team members, project manager or stakeholders happening during the project. Finally resource reassignment of key resources by management to higher priority projects. (Krigsman, 2010)ReferencesCommedia, S.
(2011, July 5). Common Factors behind Software Failure. Retrieved September 7, 2011, from http://www. articlesbase. com/software-articles/common-factors-behind-software-failure-4986460. htmlDolinsky, M.
(2011a, May 3). All About Software Project Failure. Retrieved September 7, 2011, from http://www. articlesbase. com/software-articles/all-about-software-project-failure-4717821.
htmlDolinsky, M. (2011b, April 27). Causes Behind Software Project Failure. Retrieved September 7, 2011, from http://www.
articlesbase. com/software-articles/causes-behind-software-project-failure-4681213. htmlJohn, J. J. (unknown). Tips for Avoiding Enterprise Software Failures.
Retrieved September 7, 2011, from http://ezinearticles. com/?Tips-for-Avoiding-Enterprise-Software-Failures&id=6238662Krigsman, M. (2008, December 11). Study: 68 percent of IT projects fail | ZDNet. Retrieved September 7, 2011, from http://www. zdnet.
com/blog/projectfailures/study-68-percent-of-it-projects-fail/1175Krigsman, M. (2010, August 20). Twelve early warning signs of IT project failure | ZDNet. Retrieved September 7, 2011, from http://www. zdnet.
com/blog/projectfailures/twelve-early-warning-signs-of-it-project-failure/10561Mun, Y. K. (2011, February 11). Software Development Project Management: Introduction | Suite101. com. Retrieved September 7, 2011, from http://yuen-kit-mun.suite101.com/software-development-project-management-introduction-a346155/print
