How to Head Off a Project Failure

What happens when someone forgets to do the very thing that absolutely had to be done? You know, that thing you were counting on to push the project forward. And what if the guilty party is your client or a team member?

TeamIn every project you’ll ever work on, there will typically be some element of failure. Nothing works perfectly and the second you think things are going well, you better look up and pay careful attention. I’m not being pessimistic. I’m just being realistic. Being 100 percent smooth and perfect is rarer than hens teeth.

So what’s a hard working PM to do? Simply stated, know your project. Know when the failure points could occur, as well as how to protect yourself, the team and the client if they do. Protection doesn’t mean making sure that you don’t get fingers pointed at you, it’s ensuring that the project goes as smoothly as it can so when the fail happens, it’s a small bump and not a mountain.

Here are five essential ways to protect your project.

Know the Project Charter and Scope it Well

If you don’t understand the project’s purpose and scope, at least at a high level, you’ll never know when something’s changing. You need to understand how scope’s major features interact with each other and who might be effected. When you do this, you’ll have a handle on next steps if the client asks for an additional item, or suddenly says something is missing.

Document Everything

It’s not enough have the scope documented. You have to have all the necessary supporting documentation that comes after the initial one is finalized. It’s also essential to know your timeline and have decision points noted along the way, through e-mail or some other fashion. I can think of countless time when a client or team member said that I hadn’t done or said something that, in fact, had been done or said. By having a paper trail, I could have a reasonable conversation about it. Without a paper trail, the smallest disagreement can turn into a “he said, she said” situation. Remember, consultants and project teams aren’t always the ones who are heard first.

Keep Your Team Members Close

Make sure you build your team well. Keep them motivated and moving forward. A main goal of any team is to learn how to operate together and be responsible to and for one other. If you’ve developed that kind of close cooperation, your team will pull together when things go bump.

Over Communicate

It may seem obvious, but it’s worth a reminder. While not necessary on every occasion, make sure every decision or important topics being discussed are shared with everyone. That way, if there’s a snafu you’ll have more of a chance to get the right feedback sooner. It also keeps information documented in multiple ways, so that more than one person has it and can speak to it.

Keep Your Cool

It’s incredibly important that you never lose your temper. You need be level-headed and able to speak logically even in the most heated situations. Learn this sooner rather than later. If you lose your temper, it could cause you to do or say things that will end up being more detrimental to the project than you realize. If you’re seen as being level-headed, tough conversations with the clients or team members at the heart of the fail will be a lot easier.

Comments

  1. BY JMR says:

    I would offer up that it’s also very wise to have a plan B (and maybe C) on every critical part of the project. In other words, besides “over communicate”, “over plan” as well. At least one or two of your “plan B” options WILL come into effect, so the more you can get ahead of that the better off you are. The trick is to not spend so much time planning that you never give the team space to accomplish anything. That’s where agile/lean seem to be taking us — to a place where we’re constantly doing “just enough” planning. It’s like having a “plan B” discussion every week or two.

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>