What’s Your Glove Display for Making IT Changes?

In their book Switch, authors Dan and Chip Heath talk about how to build support for and change existing situations. They cited one situation involving a traveling glove display that has practical applications for instigating IT changes.

Here’s how it works.

A Purchasing manager wanted to show the consequences of not having a standardized purchasing policy for stock items like gloves, and how it could save their company $1 billion over five years. So he sent an intern around to gather samples of each of the 424 different types of work gloves the company was purchasing.

The Purchasing Manager then labeled the samples with the price paid for each glove, stacked them on a conference room table, and invited the executives in to literally see what their lack of a centralized purchasing policy was costing.

The effect was stunning and visceral. In some cases, the same gloves were being sold by different vendors at different prices. In others, glove quality was lower than needed while in others they were overbuying and paying too much. The executives who saw it had a visceral reaction, which was: this is crazy and has to change. And the traveling glove display helped provide the mandate for the change the Purchasing manager was looking for. (note: for the full story, read Switch).

As in Purchasing, so in IT

When faced with difficult IT situations, it’s sometimes helpful to employ a version of the glove display strategy outlined here, where you can actually show users and managers the need for action, getting the same kind of visceral reaction you may need to push through a change.

One of my clients had a situation where she used the glove display idea to get support for a change they needed to initiate. Here’s how that situation went down.

When IBM i application errors kept occurring overnight, the client wanted more active involvement in having the applications group help solve the problem. Programmers weren’t on call 24 hours a day, and it was customary for the overnight operations staff (yes, they had one of those) to cancel problem jobs and take a program dump of the offending program for the apps staff to clean up in the morning.

The client wanted to get the apps staff more involved (perhaps even overnight), cut down on overnight errors, and eliminate the dump-n-wait for the morning mentality to get a true solution.

So she put up a Days since last overnight incident sign for all systems the group monitored. Similar to the Days since last workplace accident signs you see in warehouses, this sign was updated every day to show how long it was since there was an issue with overnight production.

What the Days Since Last Incident sign looked like. It’s amazing what a little thing like a sign can do to help trigger a change.

The Days since last overnight incident sign was a report card for how their nightly processing was working. A high number meant the system was completing all its work without error, while a low number (or a zero) meant there was a recent system problem that affected overnight processing.

Some staffers including the applications manager hated the daily sign as they viewed it as airing dirty laundry and blaming the applications group for overnight issues (a visceral reaction, just like with the gloves) . But it started conversations. Whereas before, overnight application issues were quietly corrected in the morning, now everyone knew when there was a problem and the morning topics now included how to make sure overnight problems wouldn’t happen again.

It didn’t happen overnight but eventually everyone started working towards stabilizing overnight processing. Some of the solutions involved:

• Putting in better overnight monitoring and alerts, which allowed the company to bypass the overnight operation shift when a problem was occurring
• A rotating support system where all staff members would take turns reacting to any application errors that occurred. This gave everyone a stake in reducing the number of issues (i.e., they didn’t want to get up at 3:00 AM).
• Retrain the overnight operators into different jobs and eliminating the 24 hour a day operations staff, which made better use of their staff talent
• Creating an atmosphere where everyone had a share in making sure overnight issues were few and far between. Problems were spotlighted and fixed as quickly as possible, rather than waiting for the next day for someone to put in a “fix”. When the problem is out in the open, people have to take responsibility for getting it fixed.

While this transition may have happened organically at some future date, the Days since last incident sign (glove display) was the spark plug that triggered the change process. It helped the company find the underlying feelings and motivation people needed to implement the change. It visualized a situation they knew they needed to deal with and got them thinking about the change. In another nod to the Heath brothers and their Switch framework, it also helped helped do the following:

• Pointing to a target destination: Leading towards a world where these errors were rare and infrequent
• It tweaked the environment: By bringing the issue out to the open, it forced people to change their ways. They could no longer just quietly “fix” the data without addressing underlying issues.

What it comes down to is this simple visualization of a hidden problem (a sign documenting how often something occurs) triggered a necessary change.

The Morale for IT

Sometimes a strong visualization of the current situation is a powerful tool for kick-strating a difficult IT change, or at least getting people’s attention that a change must occur.

The key is to find something that stirs up people’s emotions, that makes them feel something (disgust at the insanity and waste of the glove display; or linking an application failure and data corruption to an industrial accident). Once they feel something, you’ve accessed their motivation for getting things done (sometimes referred to as the elephant). Once the elephant starts raging, get out of the way because it may demand a solution, and it may very well bring along your executives, users, and stakeholders if they’ve been given a strong enough visualization.

You may not always be in a situation where you can produce a powerful symbol for system change, but it’s good to have this idea and example available for the times you will need it.

(first posted August, 2013. Updated January 2014)