TAKE SOME RISK (BUT NOT PUT YOURSELF AT RISK)
Newsletter sent on Tuesday, Apr 26, 2022
When planning a new innovative software project, especially one that solves a complex problem, you’ll never have 100% confidence, but you shouldn’t release and pray either.
One of the ways to overcome hesitation is to break out of the plan-execute-done paradigm and regularly get out into the field for a reality-check exercise. However, the truth is that there are different techniques for managing risk, each with its own merits. They must be properly timed: a common mistake is to stick with one or another for too long and miss the moment to shift gears.
Imagine you are in charge of building a settlement on the planet Yq. Your vision is solid. The business case is ready; nobody would fund the project without it. The 67-pages document draws a pretty good picture of what the new extraterrestrial hamlet should look like, a detailed schema of each house, and a proposed location near the most picturesque crater.
The plan looks nice on paper, but you know that theory and practice are the same only in theory. So, there should be a way to validate the riskiest assumptions about the project without committing to it fully. In fact, you can:
A. Analyse. Get your facts straight. Learn about the planet, space travelling, intergalactic law system, and extraterrestrial architecture and carefully examine your plan against the knowledge you got from theoretical sources.
OR
B. Experiment. Choose the area of least confidence (can be technical, financial, sociological, ethical, legal, operational, scheduling, competition, etc.), formulate the riskiest hypothesis, set up an experiment and see if your understanding is adequate. The range of what this hypothesis and how you validate it can be is extensive.
- It could be asking a focus group on Earth whether they would like to move house to that part of the galaxy;
- Re-creating the temperature and radiation conditions of planet Yq in the lab and testing if the materials you plan to use can withstand them.
- Sending your chief scientist off to check whether the bricklaying robot performs well on the surface where the gravity is 0.78 g, etc.
OR
C. Start small (and scale-up). Based on the original plan, design a new one for building the smallest possible unit that will contain enough space and life-supporting infrastructure for one family of early settlers and some personnel. Then, send off the mission to build the base settlement, recruit and send off a family of early settlers who will stay there for a while and get all necessary support. While doing that, collect as much quantitative and qualitative data as possible, analyse it, run some more experiments on Earth, adjust the plans, design the next building, build it, send more settlers, etc…
It’s easy to see that all of these techniques can help manage risk (and costs) by validating your initial plans:
A — against existing knowledge;
B — against newly obtained knowledge in a modelled limited context;
C — against newly obtained knowledge in the most realistic possible context.
These techniques can be seen as stages of an iteration: A’s results will support B, and the results from B will support C. The results of C will expose some new questions that can be best first analysed (A), then experimented with (B) and then tested end to end. And so on.
If you get stuck in stage A or B, you sacrifice conclusiveness and momentum. Only C allows you to see if the totality of your team, process, materials, and context can move the needle in terms of business goals – take some calculated risk without putting yourself at risk.
Cheers,
Mike
