After a frustrating day at work dealing with a repeat of a problem from this past spring, I related some of the situation to my crew of hecklers advisers at the dinner table:
.jpg)
By Matthew Paul Argall [CC0]
A software package common to all our endpoints has a third-party plugin that only half of our users utilize. The package incorporates some templates that—in our situation—were created in a different version of the package on quite a different platform. The package and plugin relationship is complicated: only a particular version of the plugin will work with any given version of the package.
Of the users that utilize the plugin, only a few are in the same workgroup with another user. And, of course, there’s not a user group or a communication mechanism. The only common point of contact is the workgroup that takes the output from this package and does some massaging, formatting and editing before sending back to the users.
The IT workers on my team started with each user of the software package and plugin—and blaming the templates. Or the packages. Or the plugins. (Or the users!) Very soon we had a mashup of instructions with every known mixture of package/plugin/installation possible. I was hearing things like “UserA says that it’s the templates” and “UserB says when they reboot it works” and “UserC deleted their cache, reinstalled the plugin and now it works”.
Whatever. Sure, keep developing individual solutions for each of your installations. How’s that working for you?
We solved that situation this past spring the same way we solved it this time. Once I observed the tail-chasing, I got the team’s attention by strategically (and briefly) losing my cool, swearing once (or twice)1 and calling a meeting. It was time to stop doing what wasn’t working and focus on the problem.2
Problem 1: What’s actually broken?
Problem 2: Who is experiencing the problem?
Problem 3: Why is it broken?
Problem 4: When does it show itself?
Problem 5: Who knows the above What, Who, Why and When?
I find that getting all the stake-holders3 into a room and hashing out these questions generally presents a solution.4
But it was the two Boy Scouts at the table last night that really put their fingers on the problem-solving metaphor that every Tenderfoot5 should know: Whenever you become lost, you should STOP:
Stay put (Quit chasing your tail.)
Think (Consider what resources you have available to survive/solve the situation.)
Observe (Take notes of the situation—from all available resources.)
Plan (Determine what you can and should do…)
How you implement this metaphor might be different for each situation, but the steps generally remain the same. There might be some variation in the order of Think and Observe, but always begin with Stay put and end with Plan. And after that, it goes without saying that there should be a healthy dose of Do.
Just don’t start tail-chasing again.
How about you, reader? What’s been your experience with solving a wide problem with lots of variables and players?
-
Picard management tip: Used sparingly, some light swearing can help emphasize your damn point.
— Picard Tips (@PicardTips) June 9, 2013
- The most-relevant Apollo 13 movie quote is probably from Gene Kranz:
Let’s work the problem people. Let’s not make things worse by guessing.
- In this sense, I mean the ones actually holding the stakes that define the edges and boundaries of the problem. ↩
- I’ve written elsewhere about using a matrix to help hold all these pieces of data in a single place until the picture begins to resolve itself. ↩
- Tenderfoot Rank requirement 5b: Describe what to do if you become lost on a hike or campout. ↩
