Can your software be built? Probably. That's not likely the greatest threat to your project.
Coders gotta code. So if you ask a developer to build a new feature, she’s not likely to say No. The same is true if you ask whether a feature can be built: Yes, of course! Very few software products break new technological ground, even if they do create new user experiences. Rarely are the greatest risks to your project found in the development itself.
Let’s take a look at the four types of risk you face when building and releasing new software products:
- Technology Risk
- Execution Risk
- Market Risk
- Capital Risk
The Four Categories of Software Development Risk
There’s a huge difference between uncertainty and risk. As we discussed in the previous post, being uncertain about how a new software release will fare with users, for example, is not the same as risking the whole project based on assumptions. By categorizing the risks you’re taking into four distinct buckets, you can label and proactively manage potential risks before they sink your project.
1. Technology Risk
Chances are, whatever you want to create with software does not require new technology. In other words, the computers, servers and coding languages that currently exist will do just fine to create the user experience you imagine. In that respect, technology risk is usually pretty low. Even highly successful startups like Uber don’t need to invent the technologies their platforms run on… until they want cars to drive themselves.
If you’re updating an aging system, then your technology risk is even lower, since, by definition, you want to turn a system that already works into a system that works on more reliable, current software.
Limit Your Technology Variables
To keep risk low in all circumstances, it’s important to limit your variables, and avoid choices that, over time create something called “technical debt.”
Here’s an example: You buy software off the shelf to manage sales, but that software doesn’t handle fulfillment the way you want, so that’s a bit of custom code that has to be integrated. The app your customers use to track orders was built with a framework that is no longer supported, so security patches become impossible. And because the initial database architecture wasn’t set up properly, your team created several work-arounds that don’t always work.
At some point, as the system grows in complexity and age, the technical debt compounds and developers spend more and more of their time maintaining or fixing the system, and less time improving the customer experience or building efficiencies. Variables introduce risk.
Consider Whether that Cool Coding Language or Framework is Really Necessary
Sometimes, a new framework does get the job done better. Often, it simply isn’t necessary. And while your developer wants to add it to his resume, your project might be better served using a tech stack that enjoys wider adoption and is therefore more trusted at the enterprise level.
Of course, trust is only part of it. We are regularly asked to integrate disparate systems when companies merge or make acquisitions. Those non-standard tech stacks can create huge headaches (and costs) down the road.
The last thing you want to do is code a key component a certain way out of personal preference, rather than business requirement. Please don’t ask me about the firm that insisted on using mithril.js, and the executive who let them. Oh, you haven’t heard of mithril? Yeah, that choice was a complete mith-tery and the whole project had to be scrapped. Which brings us to the next category.
2. Execution Risk
Can your team deliver the outcome your users need? Do you have enough people? And do they have the right skills? You may trust your team, and that’s a good thing. But trusting them is different than knowing whether they can get the job done, especially if the project is bigger than they’re used to or requires skills they don’t yet have.
Key Person Risk - Yeah, that guy.
In the previous post, we talked about placing bets you can afford to make. Too often, leaders place bets they never thought were risky, like leaning on one key person in the dev team who, it turns out, was already entertaining offers from other employers when they kicked off the project.
“Key person” risk is very real in software development, and can be deadly to a project. That’s why it’s important to hedge bets across your team, and even augment with an outsourced firm.
Regardless how you staff a project, insist on transparency. There’s no reason not to use Github or some other repository in which everyone shows their work and can be reviewed by a manager or even a third party, then taken over in the event of a planned or unplanned personnel change.
Project Managers to the Rescue
During a several-month project, requirements change, people change, people forget, timelines slip. Project managers preserve and protect us all from those inevitabilities. They manage up as much as down. They help respond to new roadblocks and beat back insidious scope creep.
It might be more fun to shoot from the hip and ask for a new feature a couple customers said they want, but that “minor” request can turn into a major burden on a project. Effective PMs aren’t checklist masters– they are field generals. They look out to the horizon to anticipate challenges ahead. If you don’t have a PM on your software project, there will be “unforeseen challenges,” simply because no one was tasked to look for them.
3. Market Risk
The market is the ultimate arbiter of value. And while most new software launches seem promising to those who built them, the market wants what it wants. A friend of mine calls it “latent demand,” and if it ain’t there, you can’t easily make it. Your software’s job is to satisfy that latent demand– a validated, current pain that your potential users are already trying to solve.
It’s All About the User
As we mentioned before, state-of-the-art innovation practices used by many startups and designers help to uncover user needs and preferences that drive software decisions. If you aren’t talking to users, you aren’t building what they need. Full stop.
Even if they are your own employees or another captive audience who will use the software because they are required to do so, the effectiveness of your solution hinges on their experience. You just can’t take it lightly. More on that in our next post.
Beyond user experience, understanding the alternative your users have is also crucial. What is the status quo your software is intended to improve? Remember when Blackberry was trying to compete in the enterprise market and they just couldn’t hold their ground against the iPhone? IT managers had to give up and accept that “bring your own device” was happening. Do we even talk about BYOD anymore?
The market wants what it wants. Even if the market is your employees.
4. Capital Risk
Is your project properly funded? Or have you scoped it accurately enough to understand how much budget you really need? Pulling the plug because the account ran dry is usually 100% avoidable, assuming you’ve addressed each of your other risk categories.
The Iron Triangle
Time, cost and scope - pick two. The iron triangle or triple constraint is the reality every project lives in. If you have a hard deadline, then you may need to limit the scope or spend more to get it done on time. If your budget is fixed, you may need to prioritize features more carefully, or extend the timeline.
I submit that because money is the resource that is typically in shortest supply (and return on investment is the often the ultimate measure of success), capital risk is the One Risk to Rule Them All.
When you miss a deadline, it either incurs new expenses or losses in potential revenue. When your technology is buggy, your software costs you more to maintain over time. When your users don’t like it, you have to spend more on continued product development, market, training or… starting over. Capital risk is always real, no matter your budget.
Find the Risk in Your Software Project Before It Finds You
Spending big on custom software is never easy to do. By taking a clear-eyed and detailed look at your technology, your ability to execute the plan, the market demand for your product, and the resources to properly fund it, you’ll slice uncertainty up into small, manageable bits you can tackle, one-by-one.
Don’t let your great software plan get sunk by an avoidable risk. Take the time to find each one, and have the courage to put the brakes on it, if you need to. If it takes pausing and re-working your project to ensure it’s success, then that’s what it takes.