An all-too-common project horror story

All horror movies seem to start the same: a bunch of high school students go to an old camp or cottage or abandoned cabin for a weekend of teenage revelry… but little do they know that an unprecedented evil lurks in the darkness for them. And then these movies regress into 2 hours of screaming and surprisingly red, splattery blood. It’s the classic horror movie theme, revisited time and time again with different teenagers and different villains cast by different directors. Different title, same story.

Projects are similar. They have their own horror theme. The projects might differ but the theme is constant. It goes something like this: The project has started and it is moving along nicely. As a project manager, you’re amazed to be getting agreement from the various parties throughout the process. They are providing feedback when they’re supposed to, and it’s good feedback. The project is so smooth and you think you might actually finish on time, on budget, and within scope.

You’re approaching the next-to-last version. Maybe it’s called a “beta”, maybe it’s called “pre-release”, maybe it’s called a “version .9″. Whatever. It’s the version where you are hoping that the next changes will be tiny things that can tie a nice bow on it. And then that’s when your key sponsors say: “Great, now I’ll run this up the ladder and have our VPs look at it”. (Cue screaming and splatterly blood).

It is so common in projects. And the larger the company, the more common it is. (Maybe because there are more VPs? Maybe because the VPs seem more important and aloof? Who knows).

Now, I’m not naïve. I do understand what’s going on here: No one wants to risk their job by sending half-done work to their boss. So they get it to the point where it’s nearly complete and then they sent it up the corporate ladder in the hopes that the boss sees how great they were, signs off on it and the project will wrap quickly. The sponsor comes out looking great, the VP is happy, and the project is finished within the pre-determined parameters.

REALITY CHECK: This never ever ever ever ever ever ever ever ever ever happens. Ever. As sure as those teenagers at the cabin will meet up with the villain, so sure we can be that these projects will become derailed at this point. The VP will look at it and will want to make changes. It’s not that the project has been wrong to this point, it’s just that the VP (like everyone else) wants to look good and have their fingerprint on the project as well. There’s nothing wrong with that. The problem is the timing. It comes at a point when the project is supposed to be done because no one is bold enough to ask the VP to look at it sooner.

When I’m working on a project with a client, here are a few things I do to address this problem:

• Accept that it will happen. Build additional space into the budget and timeline for such an occasion and create parameters around the scope so that the VP’s feedback will trigger additional budget and timeline.

• When starting the project, be aware that the decision maker will admit to being the decision maker until they are blue in the face. And while that may be true, the project manager needs to rephrase the question. Instead of saying “who is the decision maker on this?” or “who has sign-off authority on this?” you instead need to ask “is there anyone else who will see this project before we release it?” or “will this project need to go up the corporate ladder before the final version is produced?”. By doing this, you might end up having someone say “oh, that’s probably a good idea, we should do that”, which isn’t always ideal, but you should also get the decision-makers who say “yeah, my VP needs to see a copy and I don’t want to send it to him until it’s nearly done”.

• If possible, get to that release early. It might be earlier than you would prefer, and it might not feel like the project is nearly done, but if you know that the VP is going to change things anyway, you might as well do less up-front work. This doesn’t diminish the quality of the project, it diminishes the amount of work that will get “un-done” by the VP’s sweeping changes.

• Be the expert. If you are an external project manager, work with the project sponsor or decision maker to help them understand your experience that VP sign-off usually means VP hands-on!

The upper-level sign-off is a horror story that isn’t likely to change. But by implementing these steps into your project, you might keep the screaming and blood splatter to a minimum.

Related posts:

1. Horror story from the front lines of project management
2. Mitigating Risks: The Key to a Stronger Project
3. 5 Common Productivity Barriers and How to Eliminate Them