Preventing Project Failure

Mitigating for risk can be your best friend. I mean it, and I’m not saying this to sound all geeky smart. I have been thoroughly saved over and over because of risk management. Here’s the problem as I see it right now in the PM environment, and as I’ve witnessed with many PMs.

PMs are scared of risk management.

They are scared because they don’t really know HOW to identify risks and yet they have this sinking feeling that they probably should. After all, there’s a whole chapter devoted to risk analysis is the PMBOK so we should all, as PMs, sort out and identify and mitigate for risks as a key component to our projects…right…RIGHT???????

Ok –I’ll stop beating you up. I already did that with my staff today. So I’ll be nice on this one.

Again, the PMBOK tells you that you should mitigate for risk but doesn’t really tell you how to find a risk. So I’m going to give you the most tried and true method that I know, and its easy and fun to do. Follow me.

Step 1: Complain about your project

I’m completely serious here. Start bitchen – write it down, or talk to a friend or wipe board it. Whatever, just start complaining. Because the key to every project risk that you need to manage is buried somewhere in all the things that are driving you completely nuts about your project.

Here’s a familiar rant:

“Man..this project SUCKS! The previous PM left it in a complete shambles, totally wasted the client’s money and now I have to come in try to piece it together. I have NO idea what the requirements are because they are stuck in some 20 page long excel sheet that has no correlation to anything we’ve built or tested. I can’t tell what’s going on. And my boss has totally had it out with the client CEO – they aren’t talking. This is completely impossible.”

That’s a fairly good rant. So…let’s pull out the problems.

Step 2: Pull out the problem

If you’ve written down your rant, that’s gravy. Let’s assume that you did. Or a very good friend did it for you as you stomped around the conference room. What you are looking for is the problem statement within the rant. Let’s look at some examples:

Issue : “The previous PM left it in a complete shambles”
Pull out the problem: Poor Project management Practice were employed in the past

Issue: “totally wasted the clients money”
Pull out the problem: The client may not have enough money to continue the project

 

Issue: “I have to come in try to piece it together. “
Pull out the problem: As a new PM on a project where time and money were wasted, I won’t have any credibility.

Issue: “I have NO idea what the requirements are”
Pull out the problem: Unknown requirements exist

Issue: “no correlation to anything we’ve built or tested”
Pull out the Problem: What was built may or may not address the requirements

Step 3: Figure out how your project will fail

This next step is where you pull it together. By now you’ve identified what’s wrong with the project (step 1), you’ve identified the problem (step 2). Step 3 is about asking yourself – how will this thing I’ve identified make my project fail? This is your risk.

Your key phase is:

Because of __[blank]______________ my project may fail.

Let’s go through some examples:

Issue : “The previous PM left it in a complete shambles”
Pull out the problem: Poor Project management Practice were employed in the past
Risk: Because of previous poor project management practices, my project may fail.

Issue: “totally wasted the clients money”
Pull out the problem: The client may not have enough money to continue the project
Risk: Because budget resources may be depleted, my project may fail.

 

Issue: “I have to come in try to piece it together. “
Pull out the problem: As a new PM on a project where time and money were wasted, I won’t have any credibility.
Risk: Because client confidence is diminished, my project may fail.

Issue: . “I have NO idea what the requirements are”
Pull out the problem: Unknown requirements Exist
Risk: Because previously unknown requirements may surface my project may fail.

Issue: “no correlation to anything we’ve built or tested”
Pull out the Problem: What was built may or may not address the requirements
Risk: Because previously unknown requirements may surface my project may fail.

Step 4: Figure out what to do about it

I really love the Army…or more accurately ..Army folks. They just know how to say everything right. In a report I just read, one commander described how building roads was key to reducing insurgency in theater because the more roads, the more people and infrastructure could travel to, and positively influence populations who otherwise would might have become terrorists. I’m digressing a bit just to get to this awesome quote:

“Where the road ends, the insurgency begins”

As PMs, our job is to build the road, to anticipate and warn and build so that people on our projects can confidently walk on the road we’ve built.

Figuring out what to do, otherwise known as Plan B, otherwise known as Risk Mitigation builds the road, anticipates what’s going to happen and plans for it. Better, it makes you look like solid gold. You’ll gain credibility in the eyes of your client the minute you bring to them all the issues you’ve identified in steps 1,2, and 3 and invite them to figure out what to do about it. To sound fancy you can invite them to a “Risk Mitigation” session.

Risk Mitigation is a big corporate-sounding word that is really about ‘what are we going to do about this?’ It’s your Plan B.

Let’s go through the examples:

Issue : “The previous PM left it in a complete shambles”
Pull out the problem: Poor Project management Practice were employed in the past.
Risk: Because of previous poor project management practices, my project may fail.
What to do about it (Risk Mitigation): The project will follow PMBOK best practices. The client will be able to escalate problems with the project manager directly to the Program Manager.

Issue: “totally wasted the clients money”
Pull out the problem: The client may not have enough money to continue the project
How can my project Fail?: Because budget resources may be depleted, my project may fail.
What to do about it (Risk Mitigation): A budget report will be delivered on a weekly basis that compares work completed to dollars spent. (Or you could say something like ‘EVM will be employed’) . The client and the PM will discuss progress on a weekly basis on budgetary constraints.

Issue: “I have to come in try to piece it together. “
Pull out the problem: As a new PM on a project where time and money were wasted, I won’t have any credibility.
How can my project Fail?: Because client confidence is diminished, my project may fail.
What to do about it (Risk Mitigation): The client will periodically provide an anonymous assessment of the PMs work directly to the Program Manager. ( I know – a little big brother – you’ll work with the client to come up with something better)

Issue: . “I have NO idea what the requirements are”
Pull out the problem: Unknown requirements Exist
How can my project Fail?: Because previously unknown requirements may surface my project may fail.
What to do about it (Risk Mitigation): All new requirements must be managed through the change control process and entered in the change control log. The client will decide on prioritization of these requirements. The development team will provide estimates to aid in the prioritization decision.

Issue: “no correlation to anything we’ve built or tested”
Pull out the Problem: What was built may or may not address the requirements
How can my project Fail?: Because previously unknown requirements may surface my project may fail.
What to do about it (Risk Mitigation): The PM will do a thorough review of the requirements and share this with the client on…. [Date].

In one of my next blogs, I’ll give you real life examples of project risk registers that completely saved me from total doom on many a project. In the mean time, practice makes perfect. And you get to start this practice by complaining! What could be better than that?

Let me know what you come up with!

• • Comments [1]
  • Tags [Risk Management]
  • Categories [Managing Risks]