Sometimes fate conspires to humiliate us. Other times, we do a pretty good job all on our own. This week, Peter Clark explores the latter and how the effects are similar to a face plant. Peter had a similar experience and in this week's column he explains how, in 20-20 hindsight, it all could have been avoided.
Imagine that you are riding a bike down a hill at top speed, not a care in the world, when an unseen branch gets tangled in your front wheel. The front end of the bike stops, but you and the back half keep going. You swing over the handlebars and land face first on the ground with a sickening crunch! This is called a face plant.
Most often, a face plant seems to occur when friends and loved ones are standing by, so in addition to your pain, you are also deeply humiliated. If you are lucky, you can walk away from it with nothing permanently injured but your pride. If you are unlucky...
I recently had the misfortune to perform the professional equivalent of a face plant. It was very painful. And it was very, very public. Fortunately, I walked away from it. As a public service to you, dear reader, I will share my experience, so you can learn from my pitiful example of what not to do.
The path to my face plant started with the award of a new contract from an old customer. The contract was to purchase, configure, and install new computer hardware for a small system we previously installed. There had been considerable negotiation leading up to the awarding of the contract, and the customer required that the system be installed prior to Christmas to help with the holiday rush.
Mistake number one was to agree to a compressed schedule.
Mistake number two was why I agreed to the short schedule. I didn't properly respect what had to be done, and I did not adequately plan out all of the tasks. I assumed that since it was an "easy, small project," I could disregard some of our project planning and tracking procedures.
I then failed to pay sufficient attention to other project work going on at the same time, and how it might impact this project. When other projects escalated to critical with high priority tasks, I failed to realize how those projects delayed starting tasks for this project.
I also failed to recognize the time my people spent thrashing between projects. Someone would start a task on the small, easy project, get distracted by a crisis, and then return to my project. The lack of task continuity caused serious quality issues. Necessary configuration steps were skipped, done out of order, or even done wrong.
My third mistake was insufficiently supervising one of my people. He had been with the team for a year, and he had successfully performed similar configuration tasks before. Yet I did not understand how much more difficult the tasks were that I had assigned him. Furthermore, he did not recognize when he had performed the tasks incorrectly. He reported that the system was working properly, and I foolishly did not sanity-check his work.
By the time we reached integration, we had built a considerable quality backlog. Without sanity checks, quality backlogs become like the hidden branch I mentioned earlier. You are zooming along--fat, dumb, and happy--and then POW!
The lead engineer quickly recognized the scope of the quality problem. We had a Factory Acceptance Test (FAT) scheduled in two weeks. He reported that he did not believe we would be able to meet that date, and he recommended delaying the FAT for at least two weeks. I put on my best managerial voice and ordered him to "suck it up" and "do what it takes to get it done."
The team put in a valiant effort. Unfortunately, quality issues hid behind quality issues. When one bug was fixed, it seemed that two more would materialize in its place. Time was ticking down to the FAT, yet I would not relent in my demands that my team meet the magic date.
The day before the FAT, we were still fixing showstopper bugs. We still had not executed a dry run of the FAT tests. Significant areas of the system were almost completely untested.
The morning of the FAT dawned bright and clear. A herd of customers, consultants, project managers, and the like trooped into our test lab, and we started executing the FAT. We immediately ran into trouble.
Because we never ran a dry run, the tests were not properly scripted. My test engineer was, in effect, winging tests on the fly. This gave the whole FAT an unprofessional, ad hoc aura. We also started turning up serious problems with most of the tests. All in all, there were thirteen sections to the FAT, and problems were found in twelve of them.
I figuratively found myself face down on the ground, spitting out leaves and dirt, wondering what had just happened to me.
About the only thing that I did correctly in all this was taking full, public responsibility for what had happened. I explained the steps that we would go through to ensure that the re-test would be successful--full testing, less thrashing, and at least one dry run of the whole FAT.
The customer took it all with amazing grace. They chided me for being so ill-prepared, and told me that it was not the sort of behavior they had come to expect from my company. They allowed us to install the system right after Christmas, although they were disappointed in the delay.
If I was going to pick something that led to my undoing, it would be my arrogance in thinking that I knew better than my team and that I could blithely short cut our processes. Beware: Reality has a way of rewarding arrogance with a double-dose of humility. I can assure you that it is a bitter dose to take.
