The Magical Implementation – Awareness, Safety Crews, and Plans for Potentially Dangerous Stunts

Dana McMullan    ·      Wednesday, September 7th, 2022

A magical and practical series of tips, tricks, and a real-world guide to implementing impactful end user technologies at scale
(Based on a Data Classification implementation but applicable to most large End User Impact implementations)

Preface

Dana McMullan is founder of Pasteboard Consulting, LLC specializing in End User Impact (EUI) Security Solutions with over 30 years of implementation and support experience.  He specializes in, and is credited for leading, multiple global security product implementations.  Dana is also a renowned magician who has toured with his own stage production and has performed in over 15 countries.

This blog series is intended to offer guidance and best practice advice for anyone responsible for implementing EUI applications as told through the mindset of a professional magician.

Installment 2: Awareness, Safety Crews, and Plans For Potentially Dangerous Stunts

It Pays to Advertise

Often, the success of a magic show’s attendance is a direct result of promotion and awareness campaigns.  As a magician, print and online social media advertising of your upcoming performance helps promote awareness and generates excitement among the potential audience.

In the pre-implementation space, this is an effective tool in setting expectations relative to the forthcoming software and provides an opportunity to promote the importance of the functionality’s adoption while emphasizing management support.

Particularly useful is to solicit a senior executive (CIO, CISO, or equivalent) to underwrite and publish this pre-implementation communication, ensuring that it is widely known and understood that senior management is behind, and supporting, the project as well as making it more likely that people will be on board/buy in when the actual implementation takes place.

Especially with End User Impactful solutions, invariably there may be some resistance to the changes introduced. Despite how minor the change is to the end user, if it alters or causes a change in their daily routine there invariably will be those who will generate “noise”, as it is human nature to resist change, especially in daily routines.

Planning For When Things Go Wrong

Safety Crews

Prior to any implementation, if only for an initial pilot group, it is important to ensure that your service or help desk is fully aware of your initiative, as they are often the first point of contact if/when someone experiences a software or desktop performance issue.

It is recommended that a Frequently Asked Question (FAQ) or Standard Procedure (SOP) be created, shared, and understood by the service desk and any desktop support teams.

A technical reference manual should also be created and include triage processes/steps to isolate the root cause if the disruption being experienced is in any way due to the software you are implementing, and also include a listing of resources (including contact info) available to assist in resolving any issues encountered.

If the initial analysis determines that it is your project’s software potentially at fault, the service desk should be instructed to immediately notify the project team who can perform level 2 and level 3 support in a timely manner.

Over time, more extensive service documentation around the more frequent or common problems and solutions can be developed and matured over time, especially while deploying a pilot proven solution.

Planning For The Worst

As a magician, you assume that from time to time, that a trick might go wrong.  A prop may break or be misplaced, a dove or rabbit becomes ill, winds topple a key piece of equipment mid act, for example.

An audience doesn’t always know what the intended outcome of a trick is.  If contingencies are well thought out and regularly practiced, the act can often be saved without the entire audience knowing that something went awry.

As you prepare to launch an implementation, I cannot emphasize enough the importance of creating and maintaining forward-looking plans for contingencies.  This means having already planned, documented, and tested, in advance, various levels of recovery should something go wrong.  In most cases it is advisable to have at least some of these thought out and ready to execute even before you commence the first pilot in a production environment, mitigating unforeseen disruptions to critical business processes.

In the late 70s and early 80s, it was commonplace for professional magicians to incorporate pyrotechnics into their acts.  I personally relied on numerous flash pots (Flash pots create a ball of fire and smoke) and other fire effects.  While shunned upon today due to some tragic incidents and outcomes, the lessons learned using dangerous materials can also be applied to a global systems implementation.

In the business world, implementing end user-facing technologies can be a little like playing with fire.

To guard against a potentially dangerous “conflagration” a couple of considerations are as follows:

1. Despite extensive cross functional testing of the solution, it should be expected that there will always be the chance that “one-off” daily business processing could be materially disrupted. (Can you say “shadow IT” as in Visual Basic Macros, etc.?)These situations cannot always be foreseen, as many times, these one-off solutions are maintained at the local desktop or server with limited visibility. As such, a contingency plan should be in place for every deployment in advance.
2. Conflagration avoidance can usually be accomplished by a combination of plans:
   1. For wholesale or widespread disruption, procedures to roll-back any deployments in their entirety, or at least by deployment tranche/phase, should be considered and documented as prerequisites.
   2. If only one, or a handful, of the recipients are adversely impacted, a tested “exclusion” approach should be documented in advance and subsequently adopted.

Creating and maintaining an exclusion list (in Active Directory (AD) or otherwise), which prevents the automated re-installation of the software, is proven to be a useful tool as you can isolate and track the negatively affected individuals or devices until the root cause can be identified and addressed. Those users/devices can then be removed from the exclusion list so that the software will be reinstalled after the underlying cause is addressed.

Note:  At some companies, group policy may prevent end users from directly uninstalling security software.  It is wise to engage early in the process with service desks and/or desktop support so they are readily available to execute any emergency uninstalls, if necessary, at each phase of deployment.

Summary

More often than not, the success of an End User Impact implementation is not accidental.  Success is often the result of careful planning, preparation, and forethought.  Time spent on contingency planning can certainly help ensure success and can be the critical factor that makes or breaks an entire initiative.

Next Installment In The Series:

• Final Dress Rehearsal (Executing a Pilot Program)

Dana can be contacted at Dana@pasteboardconsulting.com

©2022 Pasteboard Consulting, LLC, written for HelpSystems