Embracing a risk management posture that secures the fate of the project from inception through closure
Putting Risk In Its Place
We all get into this business because we love to build things. Building is fun, it often makes the world a slightly better place, and occasionally we even get paid to do it. But there is one pivotal piece of business to address before grabbing the tools and starting to hammer out software — our risk management posture.
Technology product development is risky business. While we may have developed expertise in the platforms, coding languages, and data structures utilized in our industry, most projects find us in a situation where we are bringing that knowledge together with a large number of variables for the first time in history.
“Haven’t you ever done this before?”
“Of course we have, but we’ve never done it HERE, with your platform ecosystem, business structure, political environment, and goals.”
There is plenty that can go wrong in our work, which is why it is so critical to limit that list to only those variables that absolutely cannot be controlled. We’ll have our hands full with the risk that is organic to the product development business — we can’t afford to be distracted of any disasters of our own making.
For that reason, the risk management posture we bring to our own projects at OperationalGovernance is “Defense, first”. While it might feel heroic to rush into the burning building of customer business problems without adequate diligence, doing so rarely leads to the best possible outcome. Instead, we employ a methodical, carefully considered, highly transparent process in order to identify, mitigate, and manage as much risk as possible from Project Kickoff through Administrative Closure.
Understanding the Components of Risk
From the very outset, we must recognize that some risk is unknown. It’s either going to hit us or it isn’t, and if it doesn’t we will be blissfully unaware it was even lurking in the shadows. We win where unknown risk is concerned by keeping this category as small as possible. We realize that by doing the homework, understanding the larger contexts within which our project exists, and remaining sensitive to changes in the environment that may signal something unexpected in our midst. To quote the incomparable VV Brown, “Baby, there’s a shark in the water.”
While it might feel heroic to rush in to the burning building of customer business problems without adequate diligence, doing so rarely leads to the best possible outcome.
On the Known side of the diagram, we see all of the risks of which we have the potential to be aware. Note that some known risks are simply deemed acceptable. Due to their low likelihood, small expected impact, or the cost of mitigation being too high for us to afford, we document these risks, cross our hearts, and let ’em ride.
Of those risks deemed to be unacceptable, some may be mitigatable while others may not. History is full of great projects that never came to fruition because the known risk was so potent, and our ability to reliably mitigate so feeble, that even their most dedicated evangelists simply shook their heads and walked away.
The place we can have the greatest impact on the risk management of our projects is through the definition, description, and execution of mitigations. Depending upon the cost to put these mitigations in place, we may be able to insulate ourselves completely from the danger if/when those risks manifest. More often, our mitigations strike a balance that protects us from the most egregious damage possible within the limits of available time, cost, and other constraints. In those cases, some residual risk seeps through our mitigating filter and drops to the bottom line. That’s the risk you’ll need the intestinal fortitude to plow through on the path to project completion.
I once flew halfway across the country with an encrypted hard drive in my carry-on as a mitigation to the internet going down at just the moment my banking client was transferring millions of records for an important acquisition. The likelihood of the risk coming to fruition was low, but if it had the impact to our project would have been huge. The cost of a round-trip ticket from NYC to Dallas was reasonable, so I spent a day at 30,000 ft on a ‘just in case’ mission. In that situation, the internet did not go down and the data in my backpack turned out to be redundant. My reward for the exercise was free peanuts and peace of mind. I’ll take it.
Tracing multiple lines through this diagram is an interesting intellectual exercise that provides a visceral understanding of just how much total risk there will be in any project we undertake. Coming face-to-face with that risk doesn’t mean we should run from those opportunities. It does, however, demonstrate how incredibly important it is that we strike a defensive posture on the project from its very first moments — and hold that diligence through administrative closure.