The website \u201cScripped\u201d was a screenwriting service, featuring cloud-based writing tools, online storage, and a community to read and critique screenplays-in-process. \u201cWas\u201d is the key word in that sentence. In Spring 2015, registered users logged onto a blank page featuring the startling message that their browser \u201chas detected that the server is redirecting the request for this address in a way that will never complete.\u201d<\/p>\n
No April Fool\u2019s joke or trick-or-treat: Shortly thereafter, a message on the homepage indicated that, following a recent change in ownership of the website, the normally scheduled backup process failed \u2013 and in the process, wiped clean all previous backups. The previous owners had destroyed their backups, so all that remained of the entire community\u2019s shared database of work was a server image ghosted in 2010.<\/p>\n
According to the page (since removed), if writers did not maintain a backup copy of their work, \u201c[Scripped\u2019s webmasters] regret to inform [them] that it no longer exists.\u201d One would have to imagine that most users kept local backups of their work and would not rely entirely on cloud storage for their screenplays; nevertheless, the loss of their creative output must be devastating. (One friend, a talented television writer, lost years\u2019 worth of material in a similar event in 2011; to my knowledge, he has not written since.)<\/p>\n
Any time we give up control of our data, or outsource any of our intellectual property, we are putting ourselves and our livelihoods at risk. When I was with Kepner-Tregoe, we frequently encouraged our clients to use a tool called \u201cPotential Problem Analysis\u201d to reduce such threats. In six steps, clients can build action plans that both reduce the chance of a catastrophic event and quickly identify when it becomes time to deploy (a defined) \u201cPlan B.\u201d Here\u2019s how to do it:<\/p>\n
The analysis begins with specifically stating the action <\/strong>needing protection. Being specific is important: \u201cRunning a Web-Based Service\u201d is broad and can make it difficult to pinpoint a clear list of risks; \u201cRunning a Full Backup for the First Time on New Servers\u201d is better to stimulate the type of creative thinking that will yield results.<\/p>\n Next, gather experts (and skeptics) to brainstorm and \u201cIdentify Potential Problems<\/strong>\u201d by asking, \u201cWhen we do this, what can go wrong?\u201d Again, specificity is key. Avoid being tempted to chase a too-large, vague issue \u2013 something like, \u201cBackup fails\u201d. That is certainly a concern, but what are the different modes of failure? Are they all equally likely? Equally disastrous? Will they be responded to identically? If the answer to any of those questions is \u201cNo\u201d, the potential problem should be clarified further.<\/p>\n In general, listing \u201cwhat can go wrong\u201d does not require a lot of effort: Having the time or resources to wrestle everything on that list does. Many organizations have their own FMEA-style matrices for prioritizing risks. An alternative is to identify two different dimensions \u2013 the probability of failure, and separately its impact \u2013 to provide focus on the most critical risks.<\/p>\n From there, it is only natural to want to jump into action; without understanding what might drive the failure, we run the risk of hedging against the wrong issue. \u00a0Pause and identify the \u201cLikely Causes\u201d<\/strong> of the high-priority potential problems. If you can eliminate a cause, or at least reduce its likelihood, you will have taken a big step in making sure\u00a0 Only then is it appropriate to take action \u2013 \u201cPreventive Action\u201d<\/strong>, which is exactly what the name implies. The intent is to prevent the likely cause from happening, in turn protecting the plan. Preventive actions can either attack the likely cause directly, or simply block the cause from creating the potential problem. (For example, it may be impossible to prevent a grid failure, but preventive actions such as installing uninterruptible power supplies can prevent that failure from shutting down equipment).<\/p>\n Many organizations, tired of fire-fighting, stop here. After engineering a perfect solution, and installing countless measures to keep problems at bay, it seems inconceivable that bad things may indeed happen. The last problem review meeting I attended featured engineers from five different disciplines stating, with certainty, that the problem \u201ccould not have happened\u201d because of specific design actions they had taken. The fact that we were in a problem review meeting is proof enough that it did<\/u> happen.<\/p>\n Savvy teams know not to fall victim to this combination of hubris and lack of imagination.<\/p>\n The penultimate step of a good PPA begins by envisioning that the problem has occurred, and it has become time to minimize its effect\u2013 setting \u201cContingent Actions\u201d<\/strong> is what\u2019s needed. The challenge is not to worry about why the problem has happened, but to ask \u201cWhat will we do when it happens?\u201d Frequently, teams find an answer no deeper than \u201cundo\u201d (CABs always want to know the \u201cback-out plan\u201d); sometimes that is not possible, and other times the smarter play is to steer into the metaphorical skid to escape. The irony here, is backup solutions are a contingent action \u2013 invoked when the primary data is either destroyed or deleted.<\/p>\n (It is certainly a Binney Rule, if not yet elevated to a Binney Law: You will always, eventually, create contingent actions; it is better to do so in a conference room, leisurely sipping coffee in front of a white board, then it is when everything has hit the fan, colleagues are panicking, equipment is melting, and contractors are on the clock).<\/em><\/p>\n Actions without accountability do no one any good. Setting clear Triggers<\/strong> provides unambiguous notification that a potential problem has indeed occurred, and indicates both the contingent action to be taken, and who should take it.<\/p>\n <\/strong><\/ol>\n<\/div>\n Had the new owners of Scripped realized \u201cwhat could go wrong\u201d with their backup, with the understanding that they did not actually own previous backups, they likely would have taken preventive actions to avoid the debacle. Failing that, if they had identified one or two clear contingent actions, they could have saved critical data before it was too late. Rather, they have become one of too many cautionary tales. Save<\/span><\/p>\n Save<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" Without considering the collective risk of independent actions, a popular website destroyed data representing hundreds of hours of users’ work.<\/p>\n Using Kepner-Tregoe’s Potential Problem Analysis would have prevented that.<\/p>\n![\"ppa-blended-background\"](\"https:\/\/b-spoke.net\/wp-content\/uploads\/2015\/04\/ppa-blended-background2.png\")
the potential problem does not occur. At the risk of being redundant, the more specific the likely cause, the better the chance of preventing it \u2013 \u201cHardware failure\u201d is open to interpretation; \u201cSSE will not write to IO stream\u201d is something that is manageable. By understanding the root cause, you are taking a more direct, focused attack at the potential problem.<\/p>\nPotential Problem Analysis Overview:<\/h4>\n
<\/p>\n
\n
\n <\/p>\n