In these pieces about project management and leadership, about “do’s” and “don’ts”, talking with professionals and seeking out experts, nothing compares to personal experience. The last few months I’ve been working on a large project and many of the things I’ve talked about here on this blog have come into play and some new aspects as well. I want to discuss some of the things that went wrong, what the repercussions were, and what was learned. I’m going to attempt to run through these few situations without getting into the industry I work in as I want to maintain the essence of this blog and that is we are all project managers, we are all leaders, and the success we experience and adversity we face transcends industry. To start, I’ve had enough experience to know that the best laid plans will never account for the unknown, and also no matter how hard you prepare, one minor mistake can destroy all that has been worked for.
In the beginning of the project my experience and knowhow propelled the project along briskly. The budget was looking good and every time there was a delay it was something that was out of my hands. In those delays I took to opportunity to review the project with the rest of the team and fine tune down to the littlest of details. It didn’t matter how big the microscope, every time there was a delay we found something else to address, something else we missed. But, at some point you have to pull the trigger and go with what has been prepared to the best of everyone’s abilities.
Such was the case for this project. Again, the budget was looking good and we had taken some liberties in improving on an old model. There was some newly implemented ideas that we thought were going to be very effective, and some others that were already turning out to be very effective. There was quite a bit of excitement at the approaching “launch” date and by the time the final delays that were out of our hands were over, I also was very excited and fairly confident. I will say that the test did involve a start button so I don’t feel “launch” date is a terrible misnomer.
They day the project was supposed to be a “go” was a beautiful day but it followed already several delays so there was some apprehension, at least on my part. The delays weren’t major, and I’m not sure they were unavoidable. In fact there is no way we could have avoided them since they were all external so spirits were very high at the opportunity to show our stuff. I had the pleasure of having a 95% hands on role in the project and so that day I was running the motions from beginning to end to make sure nothing was forgotten. (Insert foreshadowing here.)
That morning I had the privilege of having an intern along for the ride out to the job site. He had been helping extensively with one particular portion of the project and he also was very excited about the days anticipated events. During the ride out he took advantage of the opportunity and asked me a lot of questions regarding project management, communication, and working with team members in varying capacities. One particular question he had especially stands out and that was: “So, when something goes wrong, and it’s the result of someone on your team, how do you appropriately lay blame on that individual to your superiors?” This among others I felt were some great questions from a kid still finishing his undergrad with minimal experience in any industry.
I knew my answer even before he finished the question and I’ve written about it in this blog in the past. In It’s Not My Fault I talk about this fundamental attribution error so when this intern brought it up, I brought up my experience. After his question was asked, I paused with a little thematic gesture to give the appearance of deep thought, it had been kind of a running joke between us, this idea of “thematic” gestures, responses, and the like. My response was: “I don’t lay blame on my team members to my superiors. It’s my project so anything that happens while I am at the helm, I am directly responsible for. My superiors don’t want to hear about who did what and why? They want accountability and resolution. It happened, but what is being done about it right now and later, how do we keep it from happening again?” I also said: “There will come a time and a place when I’ll get to talk with that individual about what happened, and my only goal in that conversation is how we keep it from happening again; then we move on. But, it is my responsibility to absorb the blow from above and never let it seep through unless absolutely necessary.” Which is a topic for another time.
He recognized the logic in it, but also the effectiveness of it and how as project managers and leaders we are put in those positions of responsibility for the very fact that we have been and will continue to be accountable. The rest of the ride passed in similar thematic fashion and when we arrived at the job site, we were both in good spirits.
Expert’s Input: In a piece by john Baldoni titled WHAT TO DO WHEN YOUR TEAM FAILS, he outlines some great steps to follow when exactly that, your team fails. I believe they are also great steps when you fail your team. One comment in the article I’d like to point out is: “Not everything likely went wrong. It is important to diagnose the positives and decide how they can be repeated.” That is so great and enough said. I’ll leave the rest of the article for you to read so let’s get back to the story.
Later that day, after some extensive trouble shooting with actually his portion of the project which we’ll address later, it was finally 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. So, when I received that call my heart sank, no it was shot out of a cannon off of a cliff straight down. You see, I had failed to check the receiving end of our efforts. I was so focused on the startup 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.
So, the launch day did not go well, and things did not get much better from there on out. I will talk about how it was handled, and the rest of the project’s events to date tomorrow so come back and join me for some more, you might learn something, I know I did.
Image Credit: Pinterest