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. Last spring 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; Soon, 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<\/em>. 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, \u201cwe 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. (I have one friend, a talented television writer, who 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. At Kepner-Tregoe, we coach 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<\/p>\n The analysis begins with specifically stating the action needing protection<\/strong>. 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, we bring in experts (and skeptics) to brainstorm and \u201cIdentify Potential Problems\u201d<\/strong> by asking, \u201cWhen we do this, what can go wrong?\u201d Again, specificity is key. We frequently see teams attacking a possible issue such as, \u201cBackup fails\u201d. 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; we encourage clients to stop and identify the \u201cLikely Causes\u201d<\/strong> of the high-priority potential problems. If we eliminate a cause, or at least reduce its likelihood, we have taken a big step in making sure 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 controllers fail\u201d is something that is manageable. By understanding the root cause, we take a more direct, focused attack at the potential problem.<\/p>\n We allow ourselves then 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 our 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. 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<\/em>\u2013 setting \u201cContingent Actions\u201d<\/strong> is what\u2019s needed. The challenge is not to worry about why<\/em> the problem has happened, but to ask \u201cWhat will we do when<\/em> 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<\/u>, eventually, create contingent actions; it is better to do so in a conference room, leislurely 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).<\/p>\n Actions without accountability do no one any good. Setting clear Triggers<\/strong> provides unambigous notification that a potential problem has indeed occurred, and indicates both the contingent action to be taken, and who should take it.<\/p>\n Potential Problem Analysis Overview:<\/strong><\/p>\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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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. Last spring registered users logged onto a blank page featuring the startling message that their browser, \u201chas detected that the server is redirecting the request for […]<\/p>\n","protected":false},"author":17,"featured_media":911,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"ppma_author":[163],"class_list":["post-24506","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"acf":[],"yoast_head":"\n\n