Fix The Problem... NOT The Blame

I've been on a wide variety of different projects. During my career, I've managed large scale events, computer system and software installs, and large scale fabrication/installation projects. In most of these, I've seen a trend that is a reason for concern: The Blame Game.

Image courtesy of Ambro at FreeDigitalPhotos.net

 Let me give you an example. We were in the middle of a very tight software installation, and I was working more as a project scheduler and expediter than a Project Manager (PM). As I was running down the task list I noticed that a particular task was overdue, and a large series of tasks were waiting on the completion in order to complete the preference settings of the new system. As I searched for the programmer responsible, I walked by a conference room with door open and heard his voice.

I walked into the room, said "excuse me" then pulled him aside and asked him what the problem was. Apparently the load file was corrupted. I asked if we had an older version and documentation to update the old file to the latest settings. His answer: "Yes, but..."

I cut him off: "No buts, get started, we can't move forward until the fix is done. Move!" and pushed him (gently) toward the door.

It was shortly after that moment, that I realized I just saved him from an ass chewing. The Project Manager wasn't in the conference room; however, the PM's boss was, as well as several members of the Project Board who weren't supposed to be in the office on a Saturday. When the boss found out about the corrupted file, he immediately called a meeting to determine who was at fault (placing the entire project schedule at risk).

As I stood there, I apologized for grabbing the programmer, but explained that if we were to remain on schedule, I needed his solution NOW. I was a little startled when the board looked at each other and nodded, letting me leave.

Now, to the lesson. When you are in Command, you need to set priorities. In this case, my boss' boss wanted to assign blame in case the project failed, rather than determine a solution. One of many problems with this is that he was effectively guaranteeing that the project would fail because he wasn't identifying a solution but assigning blame. The fix to the corrupted file wouldn't have happened fast enough to save the rest of the project schedule, and the whole project board (and PM) would have been scrambling.

Instead, the programmer updated the previous file, and it was loaded with only an hour lost to the project schedule. Since I was aware of the expected delay, I worked with the PM and the different groups to identify areas that were later in the project schedule that could be moved up to make-up the time. On Monday morning, the software package was installed and the facility was able to operate on the new system with only minor support. Overall a win that wouldn't have happened if the blame game continued.

After the project went live, I went back to the programmer to ask about the corrupted file. The best we could figure was that the file was moved from a thumb-drive that corrupted the file. It was nobody's fault and we instituted a new method of backing up setting packages in order to ensure we didn't have this issue again.

Image courtesy of Stuart Miles at FreeDigitalPhotos.net

The lesson I learned that day is that there is always time to fix the blame, but a limited window to fix the problem. When you are the leader of an event, project, team, whatever, look for solutions, rather than blame. Once the problem is solved, then you can determine who's responsible, and if necessary, what actions need to occur, either to prevent it from happening again, or to keep the person from happening again.