Risk in your software portfolio

Every software initiative you undertake carries with it some element of risk. The main risk that comes to mind is likely that of unsuccessful execution, i.e., “what if the team fails to deliver?” This is far from the only risk, however. Timeliness and its relation to relevancy (“what if we succeed but are too late?”), funding (“what if we run out of money before we’re done”), and technology change (“what if the technology landscape shifts significantly while we’re building?”) are all other elements to consider. One critical and yet often overlooked risk is that of irrelevancy, i.e., “what if we’re building the wrong thing?”

Each of these risks needs a mitigation strategy, just like the smaller scale risks that are identified during project execution. Because they are small scale, those risks are easier to identify, bound, and mitigate. The larger macro risks outlined above require a broader approach.

Obviously informed by my experience as CTO of projekt202, I see direct observation of users in context as the best way to mitigate the risk of irrelevancy. User research can be broadly or narrowly focused and is well understood as a tool for refining an approach, but seeing it as underwriting risk is often missed. How much of a project’s budget would you put towards drastically reducing the risk of irrelevancy? If you’re investing millions in an initiative, spending an additional 10-30% to avoid wasting all the budget and time seems very sensible.

Once you have a validated direction and confidence that the initiative will produce the expected return, then you can turn to mitigating execution risks. Having experienced teams is one part of the risk-reduction puzzle here. For the highest risk, highest value-producing initiatives, you’d ideally want a team that has tackled similar challenges many times before. This is part of the value proposition for consultants - enterprises only get to rearchitect every few years (or longer), consultancies get many opportunities to help clients through these challenges. Even when the value proposition cannot justify hiring an experienced team, seeding your current team with some experienced senior folks in a blended approach is a good middle ground.

Technical experience is important, but for longer initiatives I’d refer back to the most important parts of agile - team members who have mastered the meta-process will drive longer term success. You never get to do the same project twice, so knowing how to intentionally inspect and adapt is critical for successful execution. Team members who have taken the time to think about what was successful and why are far more valuable than someone who has had the same 1 year of experience 15 times.

If you have a team who is constantly evaluating their approach, you’ll get earlier visibility into other risks like broader technology changes emerging. When user research has given the team a clear picture of what users need and the team knows how to evaluate current state, you’ll be better equipped to identify and react to outside context changes and converge on a successful path faster.

You may decide not to mitigate some of these risks, but it is important to do so intentionally. Risks don’t go away if you ignore them. Decide how much risk you’re comfortable with and adjust your actions accordingly. Think about how much you’d be willing to invest in increasing the odds of success and weigh this against the cost of overall project failure.