Software development projects are finicky beasts fraught with uncertainty and risk. Statistically, 20-40 percent of new software initiatives will fail. Of those that remain, 40-80 percent will end up late, over budget and deliver little more than half of expected business value and ROI.
Identifying and managing the glut of risks that can kill a software project can be a challenge for any organization. There is no guaranteed cookbook for success. Forces ranging from personalities and politics to changing technologies and market competition create complexity and variability. However, from our experience having designed over 450 software applications, we have identified repeating patterns and factors that clearly impact the success or failure rate of any software initiative.
This series of three articles covers 10 factors culled from projects we have worked on for VC-funded startups, companies migrating to or designing a SaaS, and mission-critical systems software. Even if your project does not fall within one of these software categories, each factor is applicable to almost any software initiative.
As you read through the articles, determine which factors apply to your current or future projects and evaluate how you plan to address these issues to:
- Improve planning and prioritization
- Efficiently allocate capital and resources
- Minimize the amount of fire-fighting you need to do (or in the worst-case scenarios, prevent outright disasters or serious financial loss)
- Increase the probability of delivering your software on time and on budget
- Maximize the odds that your software will deliver market value and substantive ROI
Project killer #1: The domain expert manages the product
It may sound cliché but one of the best predictors of software success is the level of experience of the project team. Specifically does the team have a recent track record of designing and delivering successful software? Add on extra points if the software they delivered was SaaS.
Typically software initiatives are championed by the individuals with the domain expertise or a deep understanding of the science/service/technology behind the software. For example: for biotech software, it might be the person who has in-depth knowledge of mass spectrometry; for BI software it might be the person who best understands spreadsheets, data analysis and visualization; for routing and logistics software it might be the GIS/mapping specialist.
But domain experts are very unlikely to have the discipline, experience and expertise required to design market-successful software or even to lead a team that designs that software. A professional project manager also does not fit the bill. Nor does an engineering lead. Nor someone specialized in sales and marketing.
The project team needs to be hands-on and understand both technical and the software issues as well as have a strong consumer/end-user focus. Most importantly as a success factor, it needs to be a team that has recently “been there and done that” before.
I emphasize the word recently because user expectations and the demands of software design have changed radically in the last three to five years:
- Whether your target is consumer adoption or broad adoption across an enterprise, great user experience is no longer a “nicety”; it’s a necessity. Software designs that functioned adequately five years ago will likely be poorly received today.
- Software that was previously delivered on-premises now needs to be designed with an eye to elastic cloud computing, modularity and mobile delivery.
- Software that depended on customization, training and support specialists should now be designed for self-service and automation.
- Software previously designed for desktop PCs and desktop web browsers needs to be flexible to extend to other form factors.
- Software delivered using Waterfall release management now needs to be managed using Agile-ish incremental release methodology.
In summary, the best predictor of success for new software is a project team that has experience designing and delivering software that meets modern user and technical requirements, delivery solutions, form factors and incremental release management methodologies. As you read through the other success or risk factors in this article series, always think: “Is this something my project team can understand, leverage and deliver?”
Project killer #2: Wait to release until the product is “ready”
A common refrain for over budget, late-to-market, poor-user-adoption software projects is that the senior development executives didn’t know things were going wrong until it was too late. One of the surest ways to induce this problem is to hold off releasing anything until your software product is fully defined and coded.
In our experience, it is not at all uncommon for organizations to spend hundreds of thousands of dollars in development to deliver a “full functionality” product without actually validating that the product has all the front-end and back-end pieces to function in the market and generate revenue. All of the requirements docs, assurances given, Gantt charts, demos and prototypes do not expose and address the many “little” things that make code ready for use.
Nothing forces transparency on software (including identifying hidden costs, missing functionality and poor user adoption) like delivering working code to real users in the market, early and at regular release intervals. If you delay shipping until a software product is “final,” the code remains in a state of indeterminate flux. Everything always ends up needing “just a little more work.” Costs increase and release dates slip. Or, in the worst case, the project does get released but ends up delivering little or no value.
In contrast, releasing code iteratively to the market, with an ever-growing subset of features, tests all of the functionality of the software. No dependencies can get missed or passed over. Each iteration adds further functionality and polish. Each iteration gives you feedback for the next release sprint.
Delivering working code to the market early and incrementally has a second important effect: It minimizes divergence between the vision of the stakeholders and the developers. Working code that is testable in the market with real users provides the single best way for stakeholders and developers to share a common understanding and communicate. The reverse is also true: the longer a development team works without delivering working, revenue-generating code, the more the software will diverge from the requirements and expectations of stakeholders.
Project killer #3: Get the product to market, then worry about revenue generation
There is a second component to releasing early and incrementally. You also want to quickly focus these releases to be revenue generating. This focus on revenue generation is not so much about profitability (although VC firms would argue it should be), but rather about making sure you deal with all aspects of the customer life cycle associated with the software — everything from discovery and marketing to sign-up and on-boarding to support and billing.
You don’t want to end up in a position where you flip the switch to revenue-generating mode and suddenly a myriad of problems crop up that you didn’t anticipate. By focusing early releases on revenue generation, an organization is forced to deal with issues of infrastructure completeness and many of the mission-critical interdependencies they might not otherwise deal with.
You can of course be creative as to how you approach early revenue generation. Have it be free for 30 days while in beta or “Try it for $1 for one month.” The important point is that the user needs to go through all of the same steps and experiences — the full customer life cycle — they would encounter in a fully developed, revenue-generating release. Only then can you actually validate your software.
If you are developing an in-house enterprise software solution, translate revenue generation to some other critical life cycle component, such as self-provisioning. What you are really trying to do is make sure that your software validates and users can complete the entire software life cycle.
The other big bonus to an early focus on revenue generation is that you get an in situ test of how valuable users perceive your product to be. Is the value proposition sufficiently clear and strong that customers are willing to go through the processes from signup to support?
Click here for Part 2 of this article series.
Click here for Part 3 of this article series.
Paul Giurata is the managing partner for Catalyst Resources, a user experience and application design firm headquartered in Silicon Valley. He and his teams have worked on more than 450 software projects in Financial Services, SaaS, Life Sciences / Biotech and mission-critical Systems. For more information, contact info@catalystresources.com.