Summary: Depending on the survey you read, anywhere from 25% – 68% of development projects fail. These failures often cost hundreds of thousands of dollars, waste months (or years) of time, and usually lead to people losing their jobs. Why do these projects fail, and what can you do about it? We answer those questions (and more) in this article.
Over the past 37 years in the application development software industry, we’ve seen it all. We’ve seen app dev projects of all shapes and sizes, across all industries and company sizes.
Over that time, we’ve noticed a huge disparity in development speed and success rates. For instance, one company might spend a year on a dev project, while another company completes the same project in a few weeks. One company might complete a dev project successfully, while another company fails on a similar project.
The obvious question: Why? Why does one project succeed in one business, yet fail in another?
Of course, the answer to that question isn’t cut and dried. There isn’t one simple fix for every failed project. Over the years, we’ve noticed a few common mistakes that derail dev projects.
What are they?
Today, I want to take some of the mistakes we’ve seen over the years and share them with you. Whether you’re creating workflow, reporting, BI, forms, and anything in between, the same rules apply. Certain issues will kill the entire project.
In this article, we’ll cover a few of the most common problems that derail a web application development project, and give you some tips on how to avoid them. Sound good? Okay, here are a few common reasons why some dev projects fail.
Lack of a Clear Objective
All development projects begin with an objective. But, not all of them begin with a CLEAR objective. The users have a general idea of what they want, but they can’t quite put the specifics into words.
What happens when you begin a project without a clear objective? It’s like going on a vacation without a specific destination. You know the general idea of where you want to go, but you’ll spend a lot of time wandering around.
These are the types of projects that keep going back and forth for changes. The project will either fail entirely, or at least frustrate everyone involved.
“In order to know where development needs to go, you need to know where you will need to end up at,” says David Selden-Treiman, Project Manager and Director of Operations and Potent Pages. “A successful outcome with this requires clear and specific communication with clients and others involved in a project. It’s essential to be as clear as possible, since assumptions made on what the development requirements are can easily kill a project, or at least make it more expensive to complete.”
How can you avoid this problem? Before you begin the project, sit down with the users and understand exactly what issue they’re trying to solve. Don’t settle for vague goals. Agree on a clear and specific objective, and you’ll save countless headaches down the road.
It’s no secret. Developers and end users often speak a different language.
For example, suppose an end user asks for an eCommerce application, complete with a reporting element to analyze sales. He/she might expect something like Amazon.com, with some flashy graphs and charts for analytics. Meanwhile, the developer delivers a simple shopping cart and a basic ad-hoc report.
The result: The user is upset because the result didn’t match their expectations. The developer is upset because they met the project expectations (as they understood it), yet the user doesn’t like it.
“The major reason web application development projects fail is due to poor expectation setting early on,” says Mazdak Mohammadi, Owner / Founder of blueberrycloud. “Expectations should be clearly defined at the start of every project with the help of all stakeholders involved, including the team responsible for delivering the project. Only once expectations for final outcome have been agreed upon should any sort of scope be defined. The more aligned you are at the start of the project, the greater your chance of success. Even BIG mistakes later on in the process are patched over when everyone shares the same expectations for the project. Poor expectation setting will equal a poor outcome.”
How can you avoid this problem? Ask the end user (or whoever is requesting the application) to provide a rough sketch of what they have in mind before you begin. This helps put everyone on the same page, and forces them to be clear in what they’re requesting.
Lack of planning for the future
How do define a “successful” web application development project? Is it a solution that meets the business requirements, is completed on schedule, and functions correctly?
While those are all good things to have in a project, I think success goes beyond that. A successful web application meets the business’ current and future needs. A successful application is designed to grow with the business.
Unfortunately, not all applications are designed in this way. They’re built to meet the immediate needs of the business, but fail to address the long term needs. In a few years, that application will be useless.
“Web application development projects fail for a variety of reasons,” says Brian Engert, Senior Application Developer at Soliant Consulting. “First and foremost, problems arise from a lack of planning. Many organizations jump right into a development project with plenty of enthusiasm. However, a crucial first step is a building a roadmap of not only where you want to go and what you need, but also what you need down the road. If your application can’t scale and evolve with your business, it’s only useful for so long. You don’t want to pour money and resources into a technology resource that has a limited shelf life.”
How can you avoid this problem? This comes down to the developer. Are they using technologies that will still exist in a few years? Are they building the application with scalability in mind? These are questions you can’t ignore if you hope to have a successful, long-term project.
Have you ever heard statements like this: “I love what you’ve done so far, but wouldn’t it be nice if it could also do (fill in the blank)?”
Or, “How hard would it be to add (feature X)?”
Or, “I ran the application by (person X) and they have some ideas for you.”
Or, “I just have a small feature to add.”
It’s the dreaded scope creep. The users change the app features, and then expect the project to still meet the original deadline.
“Scope creep is a fundamental project killer where the stakeholders consistently “move the goal posts,” says Randy Zinn, Software Architect at Zinn Consulting. “In minor cases, it causes schedule slippage, but in more severe cases, it can kill a project because of disruption to coding plans, application capabilities, unforeseen consequences, and enough schedule slippage that stakeholders slowly lose faith in the project and/or development team to meet deadlines. This is unfair, but such things happen. Sometimes new management causes problems when they change an application’s scope, and this can even meaning killing the application outright.”
How can you avoid scope creep? It starts with managing expectations and communicating the impact of changes.
“It’s important to quickly advise stakeholders of the impact of their suggested scope changes so they fully understand the risks and how the project may be perceived by not only themselves, but their management,” explains Zinn. “Proper communication can mitigate this, and using formal project management tools can make it clear that the impact is no one’s opinion, but a fact.”
Lack of tools
Despite the growth in development software and platforms, some developers still insist on building applications from scratch. Unfortunately, this lengthens the development project, increases the chances of bugs, and increases the risk of specification changes during the development process.
For instance, if the development phase requires 3 months, there’s a good chance that the business, and thus the project specifications, could change in that time.
“A development platform can help prevent some of the most common causes of development project failures,” explains Tyler Wassell, Software Development Manager at mrc. “The right platform should help streamline common development tasks which will improve software delivery time, improve software quality, and ensure that the software conforms to adopted standards. This translates into a project that is more likely to stay on budget, deliver what was promised, and adapt efficiently to changing business requirements.”
How can you avoid this problem? Don’t try to re-invent the wheel or attack a development project from scratch. A good development platform will save weeks, or even months of development, and greatly simplify the project.
More emphasis is placed on speed than quality
In any development project, developers will inevitably face a decision: Choose the fast way, or choose the right way? A shortcut will reduce development time, but could create issues down the road. The “right way” is probably more time consuming, but creates a better result.
The problem is, the emphasis in the business world has largely shifted over to speed. The business demands solutions faster than ever. When creating web applications from scratch, this puts enormous pressure on developers.
What happens? Code quality suffers. Developers cut corners. They create applications that fit the immediate needs, but create maintenance and scalability nightmares.
“Web application development project failure can always be traced down to code quality issues,” says Heidi Anderson, Co-Founder of theFarmBoard, Public Benefit Corporation. “Business pressure to release fast frequently results in overwhelming development team temptation to write and release low quality code. Although coding fast and loose can usually produce a faster initial release, all subsequent releases are slower, and buggier than if they were built on a clean base. Poorly formed code is hard to enhance (hard to understand), time-consuming to repair, and bugs abound. Poor code quality results in poor user experience which results in low user enthusiasm and trust. Once poor code is in place, a larger and larger amount of a team’s time is required to sustain it, leaving less and less time to make actual progress. I recently came off a large development group that was spending between 50%-80% of its time on bug fixing. A common business response to this “productivity” problem is to add more developers. Additional developers add more code to the poor base and slow things down even further, as the code base gets more and more unwieldy. The eventual failure manifests as business and user dissatisfaction and distrust (in the team and the product).”
How can you avoid this problem? If development speed is a “must-have”, you need tools to shorten the process. The right tools will not only speed up development time, they will decrease the amount of testing needed as well.
These are just a few of the most common reasons why app dev projects fail, but the list could be much longer. Would you like to add to this list? Feel free to comment below!