Hello and welcome back. This is the second of two posts on a particular project I’m currently managing and at this point in the project. Things on the project had just gone the horribly wrong. So, let’s jump right in by recapping real quick what went wrong.
We had worked through a few minor issues then it was time to “launch.” When the button was hit, it was all going very well, so well I was cooking up some celebratory late lunch to feed and thank everyone for their hard work and effort. Then, I got a call from the receiving end of all our efforts. You see, when the start button was hit, it’s supposed to have a direct albeit delayed result on the other side of a very large job site. I had failed to check the receiving end as I was so focused on the startup that I had neglected to take the time to travel the distance of half a mile to see of things were ready on the other end. They were not and the result was a very premature shutdown of the test and possible extensive damage to the equipment we had been laboring for months to assemble and get into place.
Continuing on, we could not keep the test going because the receiving end of the test was closed and by the time a portion of the team had driven to the other side of the very large site, it was too late. Material we overflowing on the receiving end which resulted in the same type of overflow where I was at. I made a decision that after thirty minutes of runtime, we would shut it down.
This is where it gets bad. When we emergency shut down like this after only 30 minutes of runtime, it has the potential to lock up the production mechanism. This is where I need to resist the temptation to discuss the project in depth and in detail. It would help to clarify no doubt but again, this is not industry related, but people related.
So, after losing the ability to move forward with the project, it was that time of the day that I needed to send out an update to everyone including the companies’ upper management. It’s interesting, that at this point I was recalling my conversation with the intern who rode out with me that morning. Coincidence? Doesn’t really matter in that regard. What does matter is that now it was time for me to live up to those lofty words I was touting not six hours prior. I wrote the email and used the collective tense of “we” in every aspect except for that of the part where I explained what happened on the other end of the project. It went like this: “I did not confirm that … .” Translation, I did not do my job.
By late that evening, we had put together a solution to gain a working project back without too much of a delay and without too much additional equipment. That night, we were all driving home in different trucks. This is after I and another truck each got a flat ties almost in the exact same spot as each other; hell of a Monday! After fixing the flat(s) and getting back on the road, I received a couple phone calls from the guys behind me and the guy in front of me. They were still working! They were trying to improve on the project such that we could ensure success or at least give it a better chance. Each truck was doing this independently which is a tribute to the project itself. Everyone had already put in twelve hours and yet while driving home, they continued by putting together ideas on how to make the project happen. Now that’s ownership!
The next day I was in the office early before heading out to the job site again. One of the individuals on the
team was also in early and we got to talking about what happened and what happens next. In regards to the closed portion of the receiving end, she said: “It was my fault, I should have checked it.” I smiled a little and then gave some thematic pause. You see, this was not the first person to say these words, to try and take responsibility for the mistake. The day before, on Launch Day, two other team members had said very similar things. That’s three people willing the jump in front of the speeding bullet that’s was my responsibility to take. Wow! That’s so awesome that there was so much ownership, so much of each individual invested in the project that they wanted to be accountable for its demise, not just its success. How was this done? I imaging through communication and the willingness to know for a fact that you must rely on your team, you can’t micromanage them, and finally trust. Trust that they will complete their portion and trust in me that I will know when to step in and when I need to walk away. I was very humbled by this gesture and other than the mishap, I would do everything exactly the same, all over again, if given the chance. At least when it came to managing the team members.
I want to side track real quick here. The issues we were trouble shooting the day of the launch had to do with the intern’s portion of the project. A part that he directly contributed to. To keep this little sidetrack short, I’m just going to say that portion didn’t work but he learned a lot in the process. Much of it he would not have learned had he succeeded the first time out of the shoot. He learned to always test equipment prior to dragging it two hours on the job site. He also learned what hustle means in that he had it dragged the piece of equipment back to corporate, and with the help of another engineer, they had it fixed, tested and running in less that twenty-four hours.
So what now? Management heard what happened, but ten they needed to hear about what “we” were going to do about it. I feel safe in using the collective “we” again as it’s going to take a team to get us back on track.
Expert’s Input: It’s interesting, the day I was writing the first part of this article I was also tweeting a little and I ended up re-tweeting a piece by Chris Farmer titled: Learn From Failure. In it he talks about a lot of great stuff that I will leave for you to read but he wraps it up with: “Failure. Suck it up.” That’s it. You have to be man or women enough to not allow your team members to take that bullet for you. To stand up and say “I did this wrong, and this is how we are going to fix it.”
Is the project going? No. In fact what happened on Launch Day was just the first of a string of events that made this project a struggle on a daily basis. I’m headed out tomorrow to try something different after a round of meetings today on how we can save the project. At the beginning of this article I said this was the second of two posts concerning this job. Something tells me it has legs enough for a few more discussions about the things we faced, as project managers and as leaders.
This probably isn’t going to make the top 22 Of The Most Epic Product Fails in History like the Ford Edsel or New Coke. But I’ll admit, there were moments when I extended the current chain of events out to their worst possible outcome sans someone getting hurt, and it sure felt like it could at least crack the top three. At least in regards to the projects I’ve been involved in.
To wrap things up here, at least for the meantime, it doesn’t matter how good you are or how well you prepare, you will forget something. Be vocal and communicate with your team. Ask their advice and share your ideas. Ownership in a project even by the party doing the least amount of work can make all the difference in the world.
Image Credit: The Simpsons, Matt Groening