Priority #3 in project rescue – Plan of record

Posted on: July 15th, 2012 by admin 1 Comment

We continue our series on rescuing troubled projects by Bob Louton, PMP.
This article discusses the 3rd-most urgent of all process areas, the project plan. After you have addressed the big problems with the plan, you can turn your focus to the next on the list which we’ll discuss in the next post.


Now I can already anticipate how some people will react. We’ve all heard in seminar after seminar, book after book, that the first thing you should do when you join a project is review the project plan before you agree to it. That all sounds like sensible advice except for one small detail. Reviewing the project plan is not the first thing you should do. It’s the third. I’ve explained and justified the first two priorities in earlier articles. Regardless of whether you agree, I’m sharing what has worked for me.

When you come onto an established project, the project plan was already signed off and posted to the team repository. If the team replanned before you arrived, then that should be available too. So they show you the plan and you can stop searching, right? Well no, that’s not right.

In my experience, there is usually more than one plan in a project. There’s the established plan of record of course. This is the one that the sponsor signed off on. But then there are several informal variations of that plan which various elements of project staff are actually following. I’ve never joined a project in trouble that didn’t have this.

The inexperienced, knee-jerk response is to clamp down on all this anarchy and bring people back to the official plan. After all, you are in charge and you need to get this project in order right? Don’t react this way. It’s not helpful. Instead, you need to welcome and analyze all these unsanctioned, as-is plans. Why? I’ve got three big reasons.

First, some project staff create their own replan for self-serving reasons. You need to find who they are because you will eventually have to deal with them. Don’t pull the “I’m in charge” card and foolishly send them fair warning to take their own agendas underground.

Second, some project staff create their own replan because the plan of record is infeasible. They gave up trying to warn the leadership, so they established a plan that they can get their team behind. This is a great source of understanding for where the plan of record is flawed, where are unidentified risks, where there are untracked external dependencies, where there are hidden resources issues, etc.

Third, some project staff might actually be following an inaccurate, obsolete, or badly understood version of the plan of record. To improve communications, you need to find the soft-spots in how information permeates the team. Communications is another item lower on my priority list, but now is a handy time to gather some input to that.

So my point is to take the time to look at the official plan and all the unofficial plans. Armed with this understanding, you will be in a better position to determine the need for a replan and to argue it. You will understand a lot more about project risk. You will understand a lot more about team cohesiveness. Most importantly for this point in my priority list, you need to know for yourself whether the plan of record is still feasible. If not, you need to make the case for a new one.

On one problem project, a subcontractor was under fixed-price contract to produce a system component to a set of requirements. For reasons I never understood, the prime contractor kept changing requirements and the sub kept conceding to demands without requiring contract modifications. When I joined the project, this sub was tragically behind on schedule, cost, and quality. They were struggling under their own management’s pressure to wrap it up and to stop the bleeding. Remember, this contract was fixed price. As a consequence of this pressure, decisions were made daily at the lowest levels to do whatever they could just to get the thing out the door. Not surprisingly, the prime kept rejecting deliverables due to quality problems.

I was assigned as a project manager with this sub’s performance as my only project. My assignment was to work on-site until I fixed their performance. Fixing the problem took four months.

Following my priority list, it didn’t take long to work through my priority list, find the root causes, and devise a plan to remedy. The first root cause I found was that there were two plans. One was the official plan which didn’t resemble anyone’s reality by the time I got there. The other plan was informal, simple, and boiled down to assuming that each shipment to the prime would be the last one.

The starting point was to recognize and acknowledge that both plans were useless. It took 2 months of working with the sub full-time to reach a compelling argument they could sell a project replan internally to their upper management. Their management resisted the budget impact of a replan that allowed their team to address the quality problems. Fortunately, they agreed. During the 3rd month, the team transitioned to the new plan and, actually, a different mindset. By the start of the 4th month, deliveries to the prime were consistently arriving with only minor defects. In the 4thmonth, this sub had stopped being one of the culprits in a barrage of system-integration issues. And they had one plan that would be successful.

Now, let’s have a word about reviewing the project plan. This should be a no-brainer, right? The accepted dogma we are all trained to parrot is that you call for a thorough review of the project plan before you even commit to accepting responsibility for a project that has already been planned. Well honestly, that’s a nice theory. The hard reality is that a company with a project in trouble only has so much latitude to absorb a replan. They only have so much budget to divert from other business needs. Resources can only stay stuck on the old project for so long before other projects simply must get staffed. Windows for market timing don’t stay open forever. So you can ask and you can demand, but they won’t give you something that’s beyond your company’s ability to give. When you are rescuing someone else’s project, replanning is not always an option.

What’s more, you don’t always get to assess the plan before you decide to accept the job. The advice we PMs get during professional development is to turn down projects unless we can first make sure the plan is viable. Sounds good, right? Too good to be true! To me, that’s hubris from people who have had an exceptional run in their careers. Ever hear those self-help experts say you should only work at a job you are passionate about?

Well if you have a mortgage and children and car payments and student-loan and good insurance and on and on, are you going to stand your ground on someone else’s principle and get all picky and demanding with the people who sign your check? Of course, you’re not.. Often, you find that your best available option is to take on an impossible job and clean up someone else’s mess but not on your own terms. 

That’s reality. When this has happened to me (and it has), the available options were not great. I can share two that I’ve used.

The first is to track fatal flaws in the plan along with other risks. Unfortunately, that’s trickier than it sounds. How you word the risks you present becomes quite political. How do you tell upper management you have no confidence in delivering on the assignment you just accepted? For the most part, ways to do this come with years of experience. I can’t give you a formula for couching status on a hopeless plan. I can do it, but I find it impossible to generalize about it. Perhaps this could be a new blog discussion.

The second option when you can’t change the plan is to be candid with your own management. Hopefully, you will find the support there you need. Sometimes, those above you will share advice that you hadn’t thought of. Sometimes, it’s enough that they know you are caught in a bad situation and daily doing your utmost. If the team is failing on a flawed schedule, it’s enormously helpful if they know they won’t be sacrificed for it.
In summary, there has to be one plan that the whole team has signed up to. Sometimes you need to change the plan. Sometimes you need to change the plan but you can’t. Sometimes the only part of the project plan you get to change is selected resources. Until there is one plan the whole team buys into, the many other problems on the project are a lower priority for your time.

(Stay tuned for part four of this series next week). 

One Response

  1. Jim says:

    Thanks but please note that this series of articles was actually written by my colleague, Bob Louton.