From the scopes that go out of hand to underestimated technological hurdles or even cultural clashes between team members, there are quite a few risks in software development. Yet not all of them have to ruin projects.
First, to understand the link between risks and project failure, it’s necessary to define failure in its own right. For organizations that are only used to seeing “black or white” in the project results, this will require a certain change in the project management culture.
Once you allow more variety in what constitutes project success versus failure, you will see that at least some risks become much more manageable. Those risks are typically related to qualitative project outcomes, such as collaboration effectiveness and software adoption. To illustrate this, we compiled the list of five software development risks falling into this category that are not that difficult to avoid if you take measures in time.
The formula for success is quite simple, really—double your rate of failure. You are thinking of failure as the enemy of success. But it isn’t as all. You can be discouraged by failure—or you can learn from it. So go ahead and make mistakes. Make all you can. Because, remember, that’s where you will find success.
For the last couple of years, the media have been overflowed with awe‑striking stats of between 19% and 50% project failure rates in software development. What such emotional reports lack, however, is what exactly the surveyed companies defined as project failure versus success.
Years of practice in software consulting can suggest that there is no binary approach to this question. There is a whole system of success criteria that can be used to measure the project outcomes, and some of them may even look like the outright signs of failure if you use objective metrics. For project insiders, though, this may be not that straightforward.
Sometimes it’s truly difficult to go beyond traditional success benchmarks like time, budget, and scope and see the bigger picture when evaluating project outcomes. But from the project manager’s perspective, such conventional metrics can only describe a project’s success to a certain degree.
The problem is, they are more descriptive of the process, not of the deliverable itself, and therefore cannot fully characterize the project with its multi-layered complexity. Not accidentally, there are many examples of projects that had disastrous results from the outside but turned out to be very useful or super successful in some of their parts.
Classic success criteria
Quality-oriented success criteria
One of such examples is from our early projects. Itransition was creating an online auction system for an overseas client. Years in the making, the project still resulted in nothing much, and the system was only live for a very short time.
It was nobody’s fault, as they say, the business idea at the core of the project didn’t turn out to be viable, and no one had been able to predict it before the project commenced. But the innovations incorporated into the system architecture, with a few modifications, became the foundation for another project that has been active and dynamically evolving for the last 15 years.
On the contrary, there are projects that were conventionally celebrated as successful but squeezed all the juices out of talented specialists and even caused them to leave their companies.
With success criteria being so relative, it’s good to have points of truth that can be used for validating project results. For software development vendors, some of the top project success criteria could look like these:
Again, these criteria are subjective and specific to a vendor’s practice. But as we’ll see further, such qualitative benchmarks serve better than just pegging to time, scope, and budget. Looking at the project results from this perspective helps to manage certain software development risks better. Let’s break these risks down one by one to see how they can be mitigated in good time.
Executive sponsorship has always been the staple of successful projects. This is proved by PMI’s 2018 Pulse of the Profession that’s been highlighting for six years in a row that having executive sponsors on a project is the number-one success driver.
This is true for all projects, of course, but for large-scale enterprise initiatives this risk gets much bigger. There, projects are longer and more massive, involving more than one department and multi-figure budgets. Lacking the central executive authority to liaise between the project team, stakeholders, and users may quickly send the project spiraling out of control.
To illustrate this last point, there is a famously failed $1.3-billion-worth project by Los Angeles Unified School District. They successfully reached their goal of equipping schools with 100,000 iPads containing e-learning materials. Yet, due to the gap between the stakeholders and the implementation team, as well as the missing requirements for the authorized content, it failed to comply with the educational standards and became altogether unusable. As a result, the investment flamed out, with only 2 out of 69 initially signed-up schools still attempting to use the tool.
To sum up, ensuring that your company’s C-suite shows enough determination and understanding to support the project in the long term is the way to sustain the project’s well-being. Even though it may require extra hours allocated to training and orientation, executive sponsorship is totally worth it as a safety cushion against possible collaboration pitfalls.
It’s surprising how many companies keep using the ubiquitous “time, scope, budget” metrics as the only signposts of project success. The Pulse of the Profession mentioned earlier highlights it’s still true for 1 in 3 organizations.
It’s necessary to remember, though, that every project is conceived to deliver a tangible business value. This has been Itransition’s mantra since the very beginning, with each of our projects pegged to well‑defined benefits that it’s supposed to bring. With no focus on benefits as the project outcomes, it’s easy to fall into the trap of delivering software just for the sake of it.
Good examples of the correct project goals are the ones like “spending 30% less working time on data exchange by the end of the year” or “improving the sales department productivity by 15% in two months.” Apart from being measurable, these project goals also correspond to other integral parameters of the acclaimed SMART model:
Another pitfall here is not benchmarking the project success against the scope of the goals. Will you consider your project a failure if only 2 out of 3 goals have been met? Is it all-or-nothing in terms of your business context? Having a clear outlook since the very beginning will help to evaluate the project results and ensure support for similar projects in the future.
Projects that get expanded in scope or duration drive extra costs that might not be planned beforehand. In most cases, these costs come from substantial reworks to the software in progress. It gets even more expensive if the team works according to the Waterfall, not Agile, methodology.
However, there is a bright side to it. Some seemingly unprofitable projects can prove to be an investment in the company’s expertise development, a particular field of knowledge, or a new set of tools. If the project was known to be experimental since the very start, and it was a conscious decision to kick it off as a testing ground, it couldn’t be easily labeled as a failure.
In general, the success of such an investment can be assessed through the quality of the company’s portfolio and the efficiency of its business unit. Again, if such a risky project helps to occupy a niche, get recognized as experts, or gain a competitive edge in a particular domain—why write it off?
Sometimes the failure of a project has nothing to do with the quality of the code delivered, chosen technologies, or the budget. The software may turn out great, but no one may use it because the market (or in‑house personnel in case of internal systems) is not receptive to the product.
Whether your software will be welcomed by your audience largely depends on the quality and depth of your preliminary marketing research. Incorrectly defined user groups or their perceived value of the software, bad timing for the release, or irrelevant distribution platforms can all become project-wrecking factors.
The key lesson here is to plan holistically beyond—but in addition to—pure technicalities. The goal is to achieve the balance between the identified market need and your suggested solution for it.
Earlier this year, the IBM-Maersk collaboration on their blockchain‑based logistics platform TradeLens caused quite a stir as a high-profile enterprise blockchain project. Hailed as a pioneering solution in its class, it was soon joined by almost 100 organizations—yet has had a hard time acquiring new users ever since.
The problem is that Maersk’s business model of the platform’s IP ownership and complete control is in fact hardly compatible with the very concept of blockchain. To yield its full benefits, blockchain software should be inherently decentralized and open to all of its participants. With no incentives for rival shipping companies to join, the promise of TradeLens may stay largely untapped.
Finally, one of the frequently overlooked software development risks is about assessing those project risks in the first place.
Looking at it from the perspective of mind vs. emotion may be a bit of a cliché, but it’s worth emphasizing: your approach to dealing with issues should be balanced between rationalism and emotion. Many people think decision-making can only be effective when you’re cold-minded. However, going with the gut feeling can be that secret recipe that helps to find unconventional routes and mitigate potential losses.
Tech visionaries and venture capitalists are familiar with this approach—dealing with many uncertainties, they frequently follow their intuition when deciding on the next big thing to invest in.
On the other hand, using emotions as the only guidance is flawed as well. As we’ve described it in one of our past articles on data-driven decision-making, there are certain cognitive and emotional biases that get in the way of clear-cut risk evaluation. For this reason, complementing your visceral feeling with hard facts will always remain the golden mean of project risk mitigation.
To assess software development risks adequately one should adopt a flexible mentality. The starting point should always be the definition of the project success versus failure. Looking beyond the classic success criteria such as time, scope, and budget will help to avoid mislabeling and train project managers to see the big picture.
This approach rests on the idea that there are few projects that can be called complete failures as such. Yet to help you stay on the safe side, this article reviewed five common risks that may affect the quality‑driven metrics of your project. All it takes to revert the potential damage is to look into these risks well before the project starts and make sure to address vulnerabilities like executive buy-in, project goals, and user adoption.