From scopes that go out of hand and underestimated technological hurdles to potential 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 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, here are five software development risks falling into this category, which are not difficult to avoid if you take appropriate measures.
Failure is in the eye of the beholder
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.
It can be discouraging to see awe striking statistics, such as that by the Standish Group saying only 36% of software development projects succeed. What such reports lack, however, is going beyond schedule, costs, and scope as standard components of success.
Years of practice in IT consulting can suggest that there is no simple approach to this question. There is a whole system of success criteria that can be used to measure project outcomes. Some of them may even look like outright signs of failure if you use objective metrics. For project insiders, though, this may be not that straightforward.
Failure as blessing in disguise
Sometimes it’s truly difficult to go beyond traditional success benchmarks when evaluating project outcomes in order to see the bigger picture. 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 successful in some way.
One such example is from our early projects. Itransition was creating an online auction system for an overseas client. After years in the making, the project still didn’t result in 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 ultimately failed. Some 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 specific measures that can be used for validating project results. For software development vendors, some of the top project success criteria could look like these:
- The product goes live (that is, delivered to its active users).
- The product delivers business value as defined by the project stakeholders.
- The relationship with the client is long-standing, preferably lasting for more than three years.
Again, these criteria are subjective and specific to a vendor’s practice. But as we’ll see, such qualitative benchmarks serve better purposes than just sticking to time, scope, and budget. Looking at the project results from this perspective helps to better manage common risks in software development. Let’s break these risks down one by one to see how they can be mitigated.
Risk #1: lack of C-level engagement
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 driver of success.
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. But there was a gap between the stakeholders and the implementation team, and the requirements for the authorized content were missing. Therefore, the system 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. New leadership has since come in, and they are working to bridge the gap to avoid any such failures in the future.
To sum up, ensuring that your company’s C-suite shows enough determination and understanding to support the project in the long term is a good way to sustain the project’s well-being. Even though it may require extra hours allocated to training and orientation, executive sponsorship is worth it as a safety net against possible collaboration pitfalls.
Risk #2: flimsy project goals
It’s surprising how many companies keep using the ubiquitous “time, scope, and budget” metrics as the only signposts of project success. The Pulse of the Profession mentioned earlier highlights that 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 keeping in mind the well defined benefits that it’s supposed to bring. Without the focus on benefits as the project outcome, it’s easy to fall into the trap of delivering software just for the sake of it.
Good examples of correct project goals are ones like “spending 30% less working time on data exchange by the end of the year”. Also, “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’s 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 from the very beginning will help to evaluate the project results and ensure support for similar projects in the future.
Risk #3: unplanned losses
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 methodology (as opposed to Agile), where project activities are broken down into linear sequential phases. Each phase is dependent on the deliverables of the previous one, and there is little flexibility.
However, there can be a bright side to unplanned occurrences. 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, and it was a conscious decision to kick it off as a test, 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 the company recognized as experts, or gains a competitive edge in a particular domain—why write it off?
Risk #4: ignoring user buy-in factors
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.
In 2018, 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 had a hard time acquiring new users.
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.
Risk #5: relying on pure logic
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 versus emotion may be a bit of a cliché, but it’s worth emphasizing. The approach to dealing with issues should be balanced between rationalism and emotion. Many people think decision-making can only be effective when you leave emotions out of it. However, going with a 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, and there are certain cognitive and emotional biases that get in the way of clear-cut risk evaluation. For this reason, complementing visceral feelings with hard facts will always remain the golden combination of project risk mitigation.
Software development risks: In search of the silver lining
The provided software development risk examples should hopefully paint a clear picture of what to avoid and what to implement to help ensure success. There needs to be the right kind of support behind each project as well as a market for it. There can be technical risks in software development as well. If the project doesn’t have the right technology or applications behind it, there is not much likelihood of success. Additionally, goals and risks should be clearly defined before the project starts.
To assess software development risks adequately, one should adopt a flexible mentality. The starting point should always be the definition of the project’s 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. The above five common factors that may affect the quality driven metrics of your project are meant to help establish how to determine risks in software application development. All it takes to mitigate the potential damage is to examine these risks before the project starts and make sure to address vulnerabilities like executive buy-in, project goals, and user adoption.
