Failures at Risk Management
February 3, 2015
For those of you hardcore stable|kernel-philes, I’m certain that you noticed my previous blog piece posted late. I wrote the post early because I always enjoy a vacation the weekend before the Super Bowl and the post was scheduled to publish during my trip. Before leaving the office on Thursday I said, “I’ll send my post from the airplane tomorrow after I do some more editing.” The circumstances that followed can only be described as a risk management failure.
Known and Unknown Risk
To successfully deliver my blog post I would require my laptop, fifteen minutes and a stable internet connection. Known risk, those risks identifiable at the beginning of a project, were low for my attempt to deliver my blog post on schedule. My laptop had redundancy because the blog post was stored on Google Drive so I would be able to access it from any device connected to the internet. I would have ample free time since I was supposed to be relaxing on vacation; Sunday would be the only day that I wouldn’t be able to steal a moment to deliver the post. The internet is hardly a risk — it surrounds us, lives in our pocket, anywhere we travel it is available — no need to have a contingency for the internet.
What came next was a chain reaction of unknown risks, those risks that must be managed proactively, compounded by failed planning. I boarded my plane to discover that the internet wasn’t working — no big deal, I’d be at my destination in a few hours. I arrived at my destination to discover that the internet would be out until Monday. I wasn’t concerned; I would stop somewhere to use WiFi on Saturday. I forgot my laptop while out on Saturday, but again, I wasn’t worried. I would take care of things on Monday. Finally, my hosts had something unexpected come up on Monday, resulting in me being unable to send the now-refined post.
How to properly handle risk
We generally publish new posts to stable|kernel’s blog first thing in the morning. My post was due to publish on Tuesday morning, which was problematic, but my flight was early enough that I could send the post before boarding. I would go through security, walk to my gate, hop on the airport’s network and deliver the post just thirty minutes later than it needed to be posted. No sweat.
I slid through the body scanner and waited for my bag to come down the conveyer belt. The bag never came; turns out my bag contained something that wouldn’t be allowed on the plane. In order to avoid the worst outcome of the unknown risk, I reached into the management reserve, the money and time an organization sets aside for dealing with unknown risks. I ran back to ticketing, paid to check my bag and hustled to just make my flight in time. My post wasn’t delivered until I arrived back in Atlanta. In fact, my post wasn’t delivered until the day after I arrived back in Atlanta. I blame that on unknown risk PTSD.
As a project manager, I had identified my risks; I just failed to act on them. The correct path to follow for a peaceful vacation and happy blog post would have been to make my blog post available before leaving the office. Any improvements that were to come could have been delivered without the overwhelming stress of there being no blog post. Good risk management on this project would have seen a blog post delivered “on time and under budget” instead of late and having tapped into the management reserve.
Published February 3, 2015