In the age of AI and mass digitization, many of us forget
that these adages from previous generations still hold true today (and in many
ways, especially today). As an executive who frequently coaches junior and mid-level
managers, this is one of the biggest problems that I encounter with my mentees.
You see, there really isn’t any unit of work that is too small to have a plan.
A plan doesn’t have to be a full project plan in Microsoft Project with Gantt
charts and resource leveling. A plan is just a series of steps to ensure that
whatever unit of work that you are about to undertake has considered all of the
elements necessary to make sure that it is successful such as who might be
impacted (stakeholders) by what you are about to do (this usually means
communication is necessary to them!), what types of devices are going to be
impacted, what are the steps to complete the work, how is this going to be
tested to make sure it works as planned before affecting users or your peers
and what is your back out plan if it fails. Time and again I coach managers and
teams when a project, deployment, update, etc. fails and there is blowback due
to failure to complete this one critical step. My first question is always, “Let
me see your plan” and so often the response is that they didn’t think they
needed one because what they were doing was simple or basic. Sometimes, those
changes or deployments that are thought to be “simple” or “basic” are the ones
that can get you in the most trouble if you don’t have a plan because you miss
steps or forget to consider edge cases or all deployment scenarios, whereas
bigger efforts tend to demand more planning and coordination just to get them
done.
I encourage my staff
to create a template with the above steps in it to follow as an outline for
everything they do. Again, this doesn’t have to be a “formal” plan, but these
questions/steps should be fleshed out somewhere and considered to ensure
success. The amount of work and loss of credibility due to failed changes far
exceeds the small amount of time it takes to create a basic plan.
Again, just to recap, a basic plan should, at a minimum,
consider the following:
1. 1. Who is impacted by this change (users, IT peers,
executives, etc.)? These are your stakeholders and require communication and/or
coordination regarding the change being planned.
2. 2. What devices (computers, laptops, mobile
devices, servers, cloud infrastructure, etc.) are going to receive this change?
a.
Are there differences in how each of these
devices may be connected?
i.
Wired connection to the network
ii.
VPN
iii.
Wireless
1.
On network?
2.
Off network (i.e., Guest WiFi)?
iv.
Mobile carrier service
v.
Are there manual procedures for applying the
change to devices that have no connectivity?
3. 3. What are the steps to complete the change?
4. 4. What are the steps to test?
a.
Who needs to be involved in the testing and who signs
off?
5. 5. What is your back out plan if the change fails?
I hope this post was helpful in at least framing how you
should approach any kind of change that you are involved in and how you can
take some very basic planning steps to make sure that your change is as
successful as possible.
