Why so many Software Projects Fail - By Rudra Tiwari , Dehradun, India
Introduction
Project
Management is defined as the application of knowledge, skills, tools, and
techniques to project activities to meet the project requirements. Projects are
all around us and Project Management is an extremely large and popular field.
Unfortunately, a large number of projects fail, and certain types of projects
fail more than others. Software projects can be very intricate and typically
fail more frequently than other types of projects. Most software project
failures can be attributed to project management, not technical challenges. Software
projects can be a huge gamble for businesses because the odds of a large
project not finishing on time or being outright cancelled are pretty high. Geneca,
a software development firm, published key findings of a study of approximately
600 business and IT executives (Geneca, 2017). The study showed that 75% of
business and IT executives anticipated their software projects would fail. This
is an alarming rate. The Standish Group has been publishing CHAOS Reports since
1994 to provide a snapshot of the state of the software development
industry. According to the 2015 CHAOS
report (Hastie & Wojewoda, 2015), 50,000 small to large projects around the
world were studied. The study found that a measly 29% of software projects were
successful. 19% were complete and utter failures. Smaller projects surveyed had
a very high success rate of 62%, which was more than ten times that of a large
project. When comparing projects of all size, projects using the agile method
were 39% successful and projects using the waterfall method were only 11%
successful. The waterfall methodology is a linear approach that can be compared
to a traditional process, whereas the agile methodology is a specific type of
rapid application development centered on a team-based approach. No matter what
approach developers take, the rate of failure is extremely high when it comes
to software projects. You have to wonder, why would companies continue to take
risks on high dollar software projects when it seems like most don’t succeed?
Software is important
because software is everywhere. A typical cellphone contains millions of lines
of code and think about how much cell phones are relied upon these days. Cars
have hundreds of millions of lines of code and the amount of code will only
increase in the future. It’s important to understand that software errors have
led to loss of money and even human life. For example, a radiation therapy
machine known as the Therac-25, accidentally exposed patients to massive
overdoses of radiation, which proved to be deadly (Fabio, 2015). Knight Capital
Group, a market-making firm, once suffered a $400+ million loss in the stock
market in just 30 minutes, due to a software glitch. Their stock price dropped
over 60 percent in one day (Salonek, 2013). Throughout this paper, I will discuss
some real-world examples of software project failure in Government, explain the
key reasons contributing to the high rate of failure in software projects and describe
how to prevent failure and ensure success.
Examining Failure – LASCAD Failure
Could
you imagine if a computer glitch was responsible for delaying emergency
ambulances, causing between 30 and 45 deaths? Well that’s exactly what happened
with the 1992 London Ambulance Service Computer Aided Dispatch System (LASCAD)
Failure (Long, 2009). A software error caused London’s brand-new computer aided
ambulance-dispatch system to fail. It was London’s attempt to replace human
dispatchers with computers, to reduce emergency response time. Believe it or
not, the system went live without load-testing and with 81 known software
issues. End-user training was conducted 10 months BEFORE the system became
operational, so many users weren’t able to remember what they learned almost a
year prior to launch. When the system launched, there was even a memory leak in
a portion of the code. Unfortunately, the London Ambulance Service (LAS) tried
to cut costs and used outdated hardware on hand, instead of buying new hardware
designed to support the software. It appears that the London Ambulance Service
dropped the ball every step of the way. Unfortunately, between 30 and 45 people
lost their life over this software project failure.
Examining Failure – HealthCare.gov
One
of the most famous examples of a software project failing is the implementation
of the HealthCare.gov website. The
health insurance website, operated by the US Government, was the cornerstone of
President Obama’s Affordable Care Act. The website was designed to be utilized
as an exchange for people purchasing private health insurance, while offering
subsidies to the less fortunate. Back in 2013 when the website was launched, it
was plagued by so many technical glitches, that only 1% of people managed to
sign up during the first week. President Obama had no choice but to openly
admit that the website was a failure. Another one of the reasons for the
failure was an inflated budget. The company who was contracted to perform the
work estimated that it would cost approximately $100 million dollars. However,
that figure tripled to nearly $300 million dollars before launch and overall
costs reached $500 million dollars. Overall, the website wasn’t a total failure
because the creators learned from their mistakes and were able to get the site
up and running.
Examining Failure – FBI Virtual
Case File (VCF)
Another
famous example of a software project failing is the FBI Virtual Case File
(VCF). According to a CNN report (Frieden, 2005), the VCF system cost the
federal government $170 million dollars. The Virtual Case File was intended to
be a searchable database that allowed FBI agents to connect the dots and follow
up on different pieces of intelligence. Ultimately the system was never
deployed and was officially abandoned while still in the development stage. A
report outlined the failure, specifically mentioning that the software was
incomplete, inadequate and so poorly designed that it would be essentially
unusable under real-world conditions. It was also revealed that the lack of a
strong technical blueprint from the outset led to poor architectural decisions.
Scope creep was another issue, as requirements were added even as it fell
behind schedule.
Reasons for Failure – Inaccurate
Requirements
Identifying
and collecting requirements is one of the most important first steps of Project
Management. It’s the process of determining, documenting and managing
stakeholder needs and requirements to meet project objectives. Inadequate or
inaccurate requirements can quickly lead to a project’s failure. Some individuals
truly don’t realize how complex business processes can be; the devil is in the
details. Software development is extremely difficult to plan in detail from the
start, due to how intricate software can be. In a study published by Geneca (Geneca,
2017), a software development firm, 78% felt the business is usually or always
out of sync with project requirements. The people surveyed feel business
stakeholders need to be more involved and engaged in the requirements process.
Even if stakeholders were involved and engaged in the process, only half of
them actually feel that a software project’s objectives are clear. Fuzzy
business objectives can be the sole reason that a project does not succeed.
Reasons for Failure – Not
Reviewing Project Progress
An
appropriate Project Management process should be selected to meet the project
objectives. Project Management processes are key to ensuring a project is on
track for completion throughout its life cycle. Most software projects get off
track and don’t stick to the triple constraints of time, cost, or scope because
nobody is monitoring them closely enough. Monitoring is a major responsibility
of a good Project Manager. Throughout a project’s life cycle, a substantial
amount of information is collected, analyzed, transformed and distributed to
team members and stakeholders. As a project progresses through its life cycle,
things change, and changes can have a significant impact on the big picture.
Challenges can be overcome by examining the progress of the project and
stakeholders must be kept in the loop along the way. It’s important to alert
stakeholders of changes or delays and take all feedback into careful
consideration. To illustrate the current status of the project, work
performance data, information and reports should be presented to stakeholders.
Reasons for Failure – Poor
Communication
Poor
communication is another reason software projects fail. It may seem simple to
communicate, but software developers are not exactly known for their tremendous
personalities and communication skills. A team member on the technology side of
things must be able to clearly correspond with non-tech executives and all
stakeholders involved. Usually there is a communication lapse between
technically skilled programmers and company executives. I’ve witnessed this
first hand and it’s almost like watching two people speak different languages
to each other. It’s vital for a technically proficient person to be able to have
strong storytelling skills in order to communicate with stakeholders
effectively. Sometimes executives may
incorrectly think that they can’t understand what’s going on with a technical
project, so everything is left to the tech department, even though software
developers may not be experienced at “driving” a project. If nobody is holding
the tech department accountable, things can easily get out of control and the
project can fall apart, fast.
Reasons for Failure – Poor
Budgeting
This
shouldn’t be a surprise to anyone, but poor budgeting can bring a project’s
progress to a screeching halt. Many software projects have an unrealistically
low budget and are doomed from the start. Low budgets are a big problem
considering the price of technology. Software developers don’t come cheap, so
corners cannot be cut when assembling a team of qualified individuals. Quality
will suffer, and the project will fail with an insufficient budget. Several
software projects fail because not enough time and money was invested in the
team to complete the project. Not all developers are created equal, so
strengths and weaknesses have to be identified and considered and gaps will
need to be filled as needed. Poor
budgeting can also refer to how the funding is spent. Software projects fail
because many are financed using a fixed bid system. Asking a developer to build
an application on a fixed price can cause issues. It may also be difficult to
see where money is going since the whole project may be viewed as a whole.
Reasons for Failure – Resistance
to Change
Resistance to
change is another reason software projects fail. Change and Project Management
go together like peanut butter and jelly. Change is truly the only thing that
is consistent and software developers have a deep understanding of change. I
interviewed Richard Heinrich, a Computer Tech for the Clark County School
District Food Service Department. Richard is in charge of deploying new
software in cafeterias across Clark county. I was specifically curious about Richard’s
experience managing projects where employees resisted change. Richard explained
that change can cause issues on the back end of the software or at the
presentation layer (front end) with end users. He gave an example of where he
was almost done testing a new software program and ready to roll it out, but
then his boss had a different idea and testing had to be redone because the
software program’s code changed. Richard also explained how end-users such as
kitchen managers resisted a new inventory system, which resulted in the district
scrapping it all together (R. Heinrich, personal communication, April 5, 2018).
Reasons for Failure – A Lack of
Testing
A lack of user
testing is another reason why software projects tend to fail. When deadlines
have to be met and the pressure is on, testing usually isn’t thorough enough to
find all of the glitches in the software. Testing is a long process and the
development team must be extremely patient during this stage. Testing came up
in my interview with Richard Heinrich and he explained the standard software
life cycle and how software in his district must be thoroughly tested by his
team in a test environment before district-wide implementation. Richard’s
strategy relies on a small group of schools piloting the software and testing
the new system in order to get the bugs out. Once the bugs are worked out, Richard’s
team rolls out the software to the rest of the district (R. Heinrich, personal
communication, April 5, 2018). User testing is a great opportunity for stakeholders
to provide feedback and give developers another way to look at issues
businesses face on a daily basis. Customers may not use the technology created
for them if they feel their feedback wasn’t taken into consideration.
Ensuring Success – Identifying the
Problem
A
good Project Manager will first identify what business problem(s) must be
solved. The hardest part of a project is to establish what the client wants and
deliver it. Gathering requirements can be done in many ways such as interviews,
brainstorming, observation, questionnaires, etc. Project managers should not be
afraid to ask questions, including the five W’s and H (who, what, where, why,
when, and how). Follow up questions are encouraged to provide clarity to
answers and to establish a clear understanding. Technical projects can cause
problems when trying to identify requirements because stakeholders may have a
hard time explaining what they’re looking for exactly. The goal or outcome must
be clearly defined and understood by everyone involved. Sometimes discussion
items can open to interpretation, so questions must be asked to avoid these
kinds of issues. For example, if a company wants to improve customer service,
but doesn’t explain how or why, what does that mean exactly? Are they looking for
shorter call times, fewer calls, or more highly satisfied customers? If you’re
unsure, there’s no way the project will succeed. Communication is key for
success and the problem must be identified early on in the process. Once you
know the goals and deliverables for the project, and how to achieve them,
you’re golden. Setting key performance indicators (KPI) can help ensure the
problem gets solved.
Ensuring Success – Review Project
Progress
Once
you understand your goals, it is important to review the project’s progress. Monitoring
progress early will help you overcome various obstacles and challenges. Several
elements will have to be reviewed, including the project’s scope, schedule,
budget, tasks to be completed, etc. Accurate monitoring will also help you
stick to a timeline for on-time completion, which will make everyone involved
happy. Milestones should be set during the project so that progress can be
reviewed with your team and adjusted as necessary. Everyone should understand
what is going on and the challenges ahead. Timelines must be regularly updated
and maintained, so that there are no unpleasant surprises. Calling a meeting
with your team will give you an overall picture of how things are looking,
which is exactly what you’ll need.
Ensuring Success – Uncover
Communication Breakdowns
It’s
important to look for and discover communication breakdowns early in the
process. Communication breakdowns can lead to confusion, complications and even
a project’s failure, so don’t assume that everyone is on the same page. Never
assume anything. Make sure everyone on your team understands you and knows what
you expect of them. Ask questions and listen to feedback when communicating
with your team. Create an environment where everyone is comfortable discussing
important matters as they arise. Everyone must understand that the goal is to
bring the project in on time and on budget. If for whatever reason, the project
is not on time, stakeholders should be warned of delays and changes. Transparency
is key and constant communication between all parties involved is crucial to a
project’s overall success.
Ensuring Success – Be Realistic
About the Budget
Be
realistic about setting a budget and make sure it’s based on correct
requirements. It’s important to set realistic expectations for all project
stakeholders. A lot of thought must go into the budget because if a project
goes over budget, it creates a huge risk for the company and all stakeholders
involved. Big budget projects fail more than small projects, so more money
doesn’t always mean more success. To set an accurate budget, get your team
together and find out how much time the work will take. You will use this
information to calculate costs. Plan for every expense you can think of,
including team member salaries, travel, equipment, etc. and don’t forget about
unexpected costs. Once you’ve created a realistic budget, continually monitor
it because estimates are going to change. Budgeting requires a team effort and
no one person can do it alone. If at any point you think the project is going
to be over budget, catch it before it’s too late and manage it properly.
Ensuring Success – Provide
Valuable Insights
The
more data, the better, right? Wrong. Computers can produce a lot of data
without getting tired, but that doesn’t mean humans won’t get tired
interpreting the data being presented to them. Complicated data sets and charts
don’t mean anything if they aren’t properly presented to the right people. You
must first convert data into information, so that stakeholders know what
they’re looking at and can make informed business decisions that will benefit
all parties involved. One of the most important things to remember is to keep
your target audience in mind. If stakeholders don’t know what they’re looking
at, they won’t be able to capitalize on its value.
Ensuring Success – Testing the Software
Software
testing is a critical phase that should not be ignored or rushed. In order to
achieve desired results, you should allocate proper time and resources to this
phase of the project. Testing can be time consuming and is often a lengthy
process, depending on how complex the application is. Testing must be done at
each stage of the software development life cycle and feedback should be given
throughout the process. Keep in mind, if testing isn’t done for the proper
amount of time, the project has little to no chance of being successful. Once
the software has been thoroughly tested, it is ready to be rolled out and
supported.
Conclusion
In
conclusion, a large number of software projects fail, but they don’t have to. I
outlined how to ensure success, but some failures are unavoidable. If you can
learn from your failures, failing may even be desirable to some people. Failure
is not an easy thing to accept, but some people believe that success through
failure is the best learning system. Thomas Edison made several attempts to
come up with the right material for the light bulb. When he tried a thousand
different elements and they all failed, he didn’t feel like he wasted his time.
Instead, he discovered a thousand things that didn’t work. Considering the high
rate of failure in software projects, learning from a failed project will
benefit you greatly in the long run. Software projects have always interested me
because software is used everywhere in this day and age. I learned a lot by
researching how and why so many software projects fail, and I think the
important thing is that people must learn from their failures.
References
Hastie, S., & Wojewoda, S. (2015, October 4). Standish Group
2015 Chaos Report - Q&A with Jennifer Lynch.
Retrieved from https://www.infoq.com/articles/standish-chaos-2015
Geneca. (2017, January 25). Why up to 75% of Software Projects Will
Fail. Retrieved from https://www.geneca.com/blog/software-project-failure-business-development
Salonek, T. (2013, July 15). Top 15 Worst Computer Software Blunders
- Intertech Blog. Retrieved from https://www.intertech.com/Blog/15-worst-computer-software-blunders/
Fabio, A. (2015, October 26). Killed by a Machine: The Therac-25.
Retrieved from https://hackaday.com/2015/10/26/killed-by-a-machine-the-therac-25/
Frieden, T. (2005, February 3). CNN.com - Report: FBI wasted
millions on 'Virtual Case File' - Feb 3, 2005. Retrieved from http://www.cnn.com/2005/US/02/03/fbi.computers/
Long, T. (2009, October 26). Oct. 26, 1992: Software Glitch Cripples
Ambulance Service. Retrieved from https://www.wired.com/2009/10/1026london-ambulance-computer-meltdown/
Comments
Post a Comment