How should you handle a risk when the only mitigation or contingency you can come up with is not on your hands?

Question

I had a risk for a software project that had to do with something I could not control. That was (really long delays on delivery of the hardware).

I work on a big company where IT has it's own budget and projects, and of course priorities. The tecnology area had to give us the stuff we needed to start with the Quality Control testing... and I knew they could very likely delay. And as I thought, they did. Even when this was talked with the IT area manager, he would do "whatever he could" but our project had other priority to him than what it had for us.

The problem was that the company works on such a way that on a given time the associated budget to my project would close and with it the whole project would go down. So time was a constraint. I tried talking with administration, but if I ask for extra time they need an estimated date to close the budget, and that had precedence on the raw IT material.

When the project was ongoing, every week, starting on the week before the expected delivey date, the IT area manager said "It will very likely be next week" and 5 months passed. On that time I also went to my boss to make the highly positioned guys on the company solve their issues and priorities, but they are also like "racing against each other to get most of their projects done the best way possible" and from software we have no leverage to exchange favors.

What ended happening was that the project went out of budget and we had to make another project, where the CIO of the (really big) company had to intercede.

What shoud I have done different? How can I save my project next time? and how should I otherwise be handling this risk?

Answer 1

Limits of Responsibility for Risk

A project manager (and to some extent the members of the project team) are responsible for identifying risks and impediments, and recommending risk-mitigation options whenever possible. The responsibility for managing risks belongs solely to senior management.

Once management has been informed of risks by the project team, it is entirely up to the management team whether to:

1. Control the risk.
2. Transfer the risk.
3. Accept the risk.

If they do none of these things, the project is likely to fail. All real culpability for such failures rests with senior management, but politically the project team will likely be blamed anyway.

Generally, members of a project team are not empowered to drive significant process improvements in a grass-roots fashion. If you're dealing with an ineffectual organization, you can either accept such failures as par for the course or dust off your resume and look for another job.

Answer 2

With most projects, and in life in general, most of the drivers that can impact your objectives are out of your control. And many of those drivers are stochastic, random, and out of EVERYONE'S control. It is YOUR job as PM to build resilience in order to cope with those risk events and to keep things going. In some cases, no matter what you do, you may fail and the project stops.

You identify the threat. You assess its probabilistic impact. You design and implement whatever mitigating actions you can do, and you come up with several contingency actions for resilience. First question I have in your case is, did you analyze the opportunity of sourcing hardware from another source? Borrow, beg, steal something to use while your shipment comes in?

Assuming you did this, and assuming you pulled every other lever you know how to do, but still failed, that is still good project management.

Answer 3

This all comes down to risk treatment. The following explanation of risk treatment is from the Risk Register User Guide -

Risk Treatment

For each risk, you need to devise a treatment strategy. The options are –

Accept - Do nothing about the risk, and accept the possible consequences

Avoid - Don’t perform the activity that is causing the risk. For example, if a feature in a software development project looks like it might cause delays, you could choose to not develop that feature.

Mitigate - Devise a plan to reduce either the probability or the impact of the risk. For example, you could add extra resources to the project.

Transfer - Make another party responsible for the risk. For example, you could outsource the activity

Your treatment strategy will depend upon the severity of the risk. When you choose to avoid, mitigate or transfer a risk, you will need to provide details of how this will be accomplished.

For each risk, you should also define a contingency plan. This is a pre-defined set of actions that will be undertaken if the risk is triggered. An example contingency plan would be, “Schedule an immediate meeting of the Project Steering Group to resolve the problem.”

The user guide also gives an extended example of how to treat a risk.