Talking About Risks

This issue of the CompanySmith newsletter will address four barriers to communication of risks in projects.

1.    “There isn’t time to work on risks…”

There are many fundamentals of leading projects. Early in the project these traditionally include requirements definition, work breakdown, task dependency, resource allocation etc. Late in the project it’s management of the bug / punch list and completion of problem tasks.

I consider risk management an overlay to all of these project steps. Projects need an escalation process when things are not going per plan or the plan has gaping unknowns. Risk management is that process. It is where the top issues are highlighted, defined, discussed, prioritized and worked.

A one page risk management report and two page process definition will keep the paperwork preparation time to a minimum. Discussion with the stakeholders when the risks are reviewed provides most of the value from the process.

The payback on risk management is the reduction of the length of the project, and improvement in predictability of the end date.

2.    “Management will drive us nuts if we show them the risks…”

No doubt this can happen. The relationship between management and the team is critical. If there is not sufficient trust or respect, then team issues should be worked outside of the project in order to build an environment where open discussion is not only possible, but is the norm.

One approach is to focus on risk management as a discussion tool, not a call for help or request for a decision. Sure, some of the risks may come to asking management for help, but set the stage for the risk management meeting as a working meeting.

3.    “We are working on all the risks we know about…”

Working issues is the job of project and product development leaders. The added benefit of the risk management process is that it provides prioritization and broader perspective on the issues than is available from the core team.

The risk management plan should be reviewed by the stakeholder team. The broader perspective of the stakeholders will alter the priorities (raising or lowering them) and will also provide additional perspective on the nature and substance of the risks, and what might be done to mitigate them. The investment in talking about the project and its risks will greatly improve project results.

4.    “We can’t do anything about them anyway…”

That may well be true for some risks, but the majority of risks can be reduced, eliminated, or agreed to be tolerated. For those that can’t be eliminated, the team usually can find steps to lower the risks. That is always a benefit to the project and to the team.

There are always some risks that you can’t eliminate.  The process of determining the financial impact of those risks will put them into perspective. The perspective may be that the financial risk is acceptable to the business. If it is not acceptable, then other steps might include changing the project approach by changing the requirements, changing the project scope, changing distribution, or in some cases, stopping the project.

Concluding…

Over the years I have seen many teams that have ignored big risks. The most costly (and surprisingly common) three that I have seen have been:

-         Developing a product without understanding which customers will want it and write purchase orders for it… only to find that too-few customers are interested.

-         Developing a product that customers want, but the company not having a distribution channel to deliver it to the customers and then support the product. (a variation of this problem is trying to put new product through a sales channel that is well-paid and busy with another product line)

-         Continuing a project to release when the product cost was higher than what the market would pay.

Home | Privacy