Rescuing Troubled Projects 1
Some years ago I was assigned to a troubled account. I knew I was in trouble the first day I arrived. I was ushered into a conference room that had been converted into an office for the acting Delivery Project Executive (DPE). The walls were covered with whiteboards, and the whiteboards had lists of red, yellow, and green projects. The DPE, calling in from back east on a speaker phone, said he was glad that I had joined the team.
I replied that I assumed he was giving me all of the green projects. Nope. I got all the red and yellow projects. In fact, I realized pretty quickly that I couldn’t have created this big a mess, if I had planned to. I could never have thought of all the things they did wrong. And on top of it all, the place had the morale of a gulag.
Now, every project is harder than you think so there is a pretty good chance that at some point a project manager will get assigned to a killer (i.e. troubled) project. A killer project is a project that is so hard that you wonder if you will live to laugh about it later.
If you haven’t been lucky enough to experience such a project, just wait. There is undoubtedly one waiting out there for you.
Now, before you get the torches and pitchforks, let me tell you that I have been assigned to several of these projects. And I want to help you survive yours, when and if the time comes.
My objective is to arm you with some ideas and techniques for dealing with killer projects. I will discuss things I have used that usually work. But, please take note. There is no technique that always works.
I will also review things that I have tried, but that you should probably avoid.
Please let me give one more disclaimer up front. The techniques that I will discuss are NOT replacements for good PM practices. I expect that you already know to verify requirements, set up issue, change, and risk management logs, to establish a communications plan, and the rest of project management blocking and tackling.
The point of this article is to give you some tools for handling the unusual situations that are the hallmark of troubled projects.
In this first article, I will discuss what I think you should do first when you arrive at a killer project.
OK, now you’ve arrived. You have had your 5-minute orientation and hand off in the hallway. Now you are the Project Manager.
What do you suppose that you should do first???
I suggest that you start by exercising the First Law of Holes. STOP DIGGING!
Remember, I am assuming that you know or that you quickly discover you have been assigned to a killer project. If you are on a great project, where everything is under control, just keep doing what you are doing. That is not what this article is about.
Unless you are very lucky, on killer projects you will usually not have much up-front information. This makes it difficult to make the “right” decisions the moment you arrive.
However, you should try to keep the hole from getting deeper.
Here are a couple of examples from my own experience:
I was assigned to a large supply chain project. This was the initial phase, and I was told we already had a couple of senior architects on site. I dutifully checked with our sales rep to make sure we had a contract in place, and I flew to the site. The day I arrived, I found that we did indeed have senior architects on site, and they had been there for a few weeks. What we did not have was a signed contract. I called the sales rep and let him know, that the team was leaving that evening, unless I saw the signed contract. The contract was signed in a couple of hours, and the project proceeded successfully.
In another case, I was called in to replace a PM at a large company where we were doing a roll-out of laptops to the senior executives and personnel. The day I arrived the outgoing PM told me that the company had not paid its bills for a very long time. The PM had informed the CIO that the team would leave that day if the bill was not paid. Isn’t that a great way to start a new project?!
This threat had been made before, but it was never carried out. I met with the CIO and asked, if he understood the team would leave, if they did not pay. He said he understood. They did not pay, and I pulled the team out on my first day on the job. After two unpleasant weeks, the company paid, and the project went on successfully. However, I was “rewarded” by being assigned to a different project.
Your actions may make you very unpopular for a while, but the alternative is usually worse for you and your company.
Be prepared for the developers, the customer, and maybe even your regular allies to tell you that you can’t afford to stop or even slow down. This is frequently the mindset of those who are too close to the chaos and who probably contributed to the troubles in the first place.
However, do you really think they would be in the hole, if what they were doing was working so well? I have heard it said that we never have time to do it right, but, we always have time to do it over.
Stopping the hole from getting deeper requires that you understand what is causing the hole. This is where you will want to apply your PM Methods.
This is not rocket science. Be aware that killer projects usually have several problems that have grown from molehills into mountains.
You should conduct an abbreviated Root Cause Analysis. You are not trying to ferret out every issue! You are looking for the major sources of bleeding and hole-digging! As you discover the problems, halt the digging.
Usually, you will start by meeting with the account executive and/or client representative to get their read on the problems.
Afterwards, interview the team and get an initial feel for where they are.
Next, you should meet with the client and other relevant stakeholders, to hear their tales of woe and to get a feel for their objectives.
Concurrently, you should get familiar with existing agreements, the charter, and any other documentation that may (if you are lucky) exist.
By the end of this process, in conjunction with the account management, you should have halted or slowed the primary unproductive activities.
At the same supply chain project that I mentioned before, I was told by the client that he couldn’t see any need for a project manager. And this was for a project with a budget of many millions of dollars!
So, I created a risk analysis, which I then presented to my client and his manager. While I was speaking, their eyes got as big as saucers. They wanted to know who had told me all of their top secret problems! I told them no one! These were just the obvious risks that any senior project manager knows when a major account does not have project management.
A little while later, the client called me in and apologized, saying that he now understood why they needed a project manager. Actually, I was so successful, that they sent me home and got a local, cheaper project manager.
As you might guess, if you don’t get control of the bleeding, then you may well get run over by the project before you get very far. We will discuss this in my next article.