Successful software projects require more than implementing user stories and writing code. There are a lot of ways projects can run into problems, and failure to manage just one of many challenges can run a project off the rails. That's why, at Atomic Object, we value what Carl calls the "worry gene" That’s a mindset of anticipating possible outcomes and taking action to improve our prospects with active risk management practices.
But good risk management alone will only avoid disastrous outcomes, not mere mediocrity. A great software team needs to be systematic about both managing risk and exploiting opportunities. Here, I’ll discuss opportunity and its relationship to risk. I’ll also provide a vocabulary for talking about opportunities and a framework for deciding how best to take advantage of an identified opportunity.
Opportunity and Risk
Consider the risk management framework we use at Atomic. Inspired by the book Waltzing with Bears, we consider risks as problems that have not yet materialized. Risks are negative future outcomes that have some hidden probability of coming true. If we think the probability is low, we may evade the risk by doing nothing and hoping for the best. Or we may avoid the risk by altering our plan to make materialization less likely. A risk can be contained by adding sufficient time and budget to deal with the fallout. Or, you can mitigate it by doing a little investment up front to reduce the fallout and being prepared if the risk does materialize. This framework and tools we use based on it serve us well for handling possible future problems.
It's worth emphasizing that risks are possible future negative outcomes, and there's an asymmetry to them. Choosing to do nothing (evade) or planning to do a lot (contain) are rather all-or-nothing. On the other hand, avoiding or mitigating a risk offers the promise of a significant reduction of pain for a small amount of forethought or action. "An ounce of prevention is worth a pound of cure." And so it is.
But not all future possibilities are negative! There are positive outcomes that are also worth our attention. You could call this "positive risk," but I prefer to think of it as exploiting opportunities. The two are closely related, like yin and yang:
- Risks are possible negative outcomes, while opportunities are possible positive outcomes.
- A whole host of areas are possible sources of problems — a dynamic often called the Anna Karenina principle. Those same project nooks and crannies can also hide opportunities for you to exploit.
- Risks and opportunities can both be asymmetrical — a small amount of effort can have an outsize impact on the future.
- Mismatching the intervention to the probability or outcome of both risks and opportunities has its consequences, as does poor execution of an intervention. Action presents risks whether you're neutralizing a risk or seizing an opportunity!
- Just as problems can pile up and exacerbate one another, opportunities can compound. They can even jump-start a virtuous cycle that provides ongoing tailwinds to the project.
- While trouble may come knocking at your door uninvited, opportunities usually need to be sought out through careful design and engineering.
- What's a risk and what's an opportunity can be a matter of perspective. Failure to seize an important enough opportunity can ultimately be a risk, and mitigating problems of the "might not be as good as it could be" kind aren't that different from seizing opportunities. In these cases, go with what feels natural and don't sweat the distinction.
I prefer to think about opportunities in similar terms to our risk framework:
- Win – A positive outcome which increases value delivered or reduces cost.
- Opportunity – Possible future wins that may materialize if exploited.
- Exploit – Action taken to test an opportunity or turn it into a win.
- Materialize – The point at which a win becomes real by benefiting the project.
- Associated Risk – The potential downsides of exploiting the opportunity, such as over-investment, opportunity cost (when compared to, say, adding another feature), or specific possible downsides to a particular exploit.
Software Project Opportunities
Often when we talk about opportunities, we'rethinking in the context of a business. The software project exists because there's an opportunity to advance the goals of the business, after all. A good software consultancy will help identify and exploit opportunities like this as they're discovered during a project. But there are smaller opportunities within a software project as well. These can be crucial to that project's success in accomplishing its stated objectives within time and budget constraints.
Some common categories include:
- Designing a potent and cost-effective solution to a class of problems with many instances. This provides a partial solution to many project needs instead of merely solving one.
- Speeding feedback loops and developer visibility into the system they are building so they can iterate more rapidly and compound the value of their time.
- Saving budget on a feature by identifying off-the-shelf solutions sufficient to meet the project need. This preserves that budget to be used for other priorities/opportunities or as a buffer against unknown risk.
- Self-organizing teams finding ways to leverage the diversity of strengths of their team to get the most creativity and energy out of team members.
- Asking for help from other developers who have experience solving similar problems to leverage their expertise on the client’s behalf. (We call it "tapping the brain trust" at Atomic.)
All of these activities may provide the promise of improved project outcomes if the team takes action, each with its potential payoff, required investment, and associated risks. Furthermore, each of these example opportunities is incredibly situational. For example, speeding developer feedback loops is always good in principle. But, how to do it and whether the investment is worth it depends on the project, the codebase, the team's ability to exploit the opportunity with control associated risk, and the project goals and constraints.
Analyzing Risk vs. Opportunity
Software teams should be (and usually are) on the lookout for opportunities that have an outsized impact on the project. But, they should also approach those opportunities with caution. Consider with each opportunity:
- What's the potential scope of payoff?
- Is the payoff likely within the duration of the project?
- What risks are associated with exploiting the opportunity, and can we manage them?
- What's our confidence level in our ability to exploit the opportunity?
All of these analyses are tricky. The last can be especially so. Most development teams are confident in their ability to do something to exploit the opportunity. However, many such attempts fail due to mismanagement of associated risks or poor execution, which neutralizes the potential win. A team should think these through with care and an honest assessment of the situation, and hedge against inaccuracy in their assessment through careful choice of action.
With each opportunity, a team can choose one of the following strategies:
- Ignore – don't attempt an exploit. This is a good choice when the chance of successful exploitation is too low or the cost is too great, the potential win is too minor, or the associated risks are too great.
- Embrace – fully attempt the envisioned approach to exploit this opportunity. This is a good choice when exploiting the opportunity is straightforward and inexpensive and the chance and magnitude of win are large.
- Experiment – Find an inexpensive and low-risk way to achieve some of the benefits to see if a partial win materializes. If successful, consider whether to Experiment further or take some other action concerning further opportunity. This incremental approach works well when exploiting the opportunity has significant cost and associated risks and the team must "thread the needle" to achieve the intended outcome.
- Time-box – Allocate some time/budget to let the team make an attempt at exploiting the opportunity (e.g., a "spike") and accept whatever outcome is achieved within that time allotment. Ignore if the attempt fails, Embrace if it succeeds, or accept a partial result as an Experiment. This strategy places a cap on the cost in a situation where the opportunity is difficult to evaluate.
Building Skills at Exploiting the Opportunity
While teams' ability to deliver more lines of higher quality code per unit of time is often thought to be a hallmark of a great team or developer, I believe skill at identifying and exploiting opportunities while also managing risks is much more significant. And it is a skill! With continued practice at identifying, evaluating, and exploiting opportunities while managing associated risks a development team and its members will improve that skill and provide outsize impacts on future projects or project phases.