Things Change

Blame is one of the most useless, albeit pervasive, reactions that surround problem solving. For many people, the initial reaction when something goes wrong is: “Who did this?” The less-than-subtle implication underlying this question is: “I want to know who screwed up.” Some may even defend their witch hunt by suggesting that identifying a culprit will allow them to determine responsibility so they can better address the situation. The end result is the same—they focus on who went wrong rather than what went wrong.

With the exception of a miniscule few, most folks don’t show up at work determined to make a bad product or to cause the organization to experience financial loss. There just isn’t that much malice in the world. People want to do the right thing. So, if something has gone wrong, looking for someone to blame is a waste of precious time and counter-productive to the ultimate mission of the organization.

Consider the fact that you have a successful enterprise. Your human resource manager is competent; the various supervisors, well qualified for their positions. Your staff has been selected based upon specific criteria that should reasonably ensure that they’re capable of doing their jobs. Unless you’re planning to fire them all, finger-pointing isn’t going to get you anywhere and may serve only to alienate those best equipped to solve the problem.

To divert focus from the “who” it’s appropriate to address this unfortunate tendency toward accusation. Blame is associated with failure and wrongdoing. If you approach a situation from the blame angle the conclusion is predictable: Someone failed to do something or someone did something wrong. If we deliberately avoid accusatory language, though, the sentence can become: Something didn’t happen the way it was supposed to. In quality-speak: There was nonfulfillment of a requirement—no blood lust, no guillotine.

The vista can then be broadened to include consideration of other contributing factors. Something has indeed gone wrong, and what often comes to light once the blame smokescreen is lifted is that the underlying problem is closely related to the manner in which the organization responds to change. A practice that was perfectly acceptable two years ago may now result in miscommunication of critical information. Breakdown of a process may be attributable to changes in features, technology or personnel that have gone unaddressed. The oft-heard expression is: “Well, it always worked before.”

This is one of the most compelling arguments in favor of internal audits. Audits allow us to observe changes in the system that may be causing a process to degrade or a practice to become uncontrolled. It’s not that people suddenly run amok, nor has everyone decided to ignore requirements. The simple reality is that things change, and if we aren’t vigilant about recognizing the consequences of change, things will go wrong.

This is the difference between preventive action and corrective action. The better job you do of asking: “What could go wrong when we change this process?” the less often you’ll have to say: “Something has gone wrong and we need to fix it.”

When something goes wrong, it’s a good idea to begin by asking: “What changed?” What follows are examples of changes that lead to breakdowns. My first example is what I refer to as the “Three Geniuses in the Garage” scenario. Many start-up companies have their origins in small offices or rented space populated by two or three brilliant entrepreneurs. They launch their product, and as their success grows so does their organization. Three years later they have a staff of 350 occupying facilities in two different locations with subcontractors on three continents, and they’re still trying to operate like three geniuses in a garage. Instructions that used to be yelled and acknowledged across the room now have to be communicated to people in a separate building. Design changes that were once scribbled on a note pad now have to be handled through engineering change notices. If these changes aren’t controlled, a healthy enterprise can begin to fall apart.

There was nothing wrong with the scribbled notes. At one time, they were appropriate and efficient. The growth that ensued changed things so that the practice today would be ineffective and riddled with unacceptable levels of risk for error or miscommunication. Due to the number of process owners who need access to current specifications, the logistics of having remote users and the speed at which technology changes, a robust process for controlling document changes has become absolutely essential. Things change.

Following are some examples of change that results in problems:

• The organization’s workforce has changed, but there have been no revisions to training manuals in three years. Technicians, machine operators and order processors who have been hired in the last two years speak 7 different languages, and manuals are still written only in English and have no illustrations or visual aids.
• The operation has added two shifts and is now running 24/7, but the preventive maintenance schedule hasn’t been adjusted to reflect the increased machine wear.
• Critical processes have been outsourced to the Pacific Rim, but no contingency plans have been put into place for communicating during the off-hours, resulting in an eight-hour delay in receiving urgent information. It’s two o’clock in the morning, and no one in authority is answering the phone.

In each instance, the practice as implemented was appropriate at one time. What was once acceptable is now contributing to a breakdown. The common denominator is the inevitability of change. We need to stop beating ourselves up and berating our fellow workers. Remember, things change. The next time a problem arises, instead of asking, “Who screwed up?” try asking, “What changed?”

About The Author