Home - White Paper Index
Framework for Project Risk Identification	First published Jan 11
Neville Turbit - Project Perfect	Rating
(Download pdf version)

Overview

There are many ways to approach a risk assessment. The approach can range from a random brain storming of risks to a highly structured list of risk areas. This white paper looks at something in between. How to use a series of prompts to find risks. How have I used such an approach in risk workshops? I usually adopt this approach as a 'tick the box' list at the end of the risk assessment to see if we have missed any areas of risk.

The Conceptual Level

It helps if we think about the source of risks in any project. To do this we need to set a risk context. We need to think about the context within which a business operates. We need to think about the risks that can come from each part of the business environment.

To draw an analogy, a SWOT analysis looks at:

• Strengths and Weaknesses of the organisation
• Opportunities and Threats outside the organisation

This is not a bad context to think of risks.

If we were to try and build a framework for risk identification, one way is to look at the risks within, and the risks without. The risks within are those risks that originate due to the way we operate and who we are. The risks without are the risks the environment within which we operate pose to us.

Looking Within

We can further split the risks within into:

• Those risks that originate because the project exists
• Those risks that originate regardless of whether the project exists or not. They are risks originating from the nature of the corporation.

Let me give some examples. A risk that falls into the former category may be related to the budget allocate to the project. It may be related to the accessibility of key staff who will contribute to the project.

External risks may relate to lack of capitol to invest in the project. It may be related to cumbersome approval processes within the organisation. It could be related to lack of internal expertise in the area.

Project Related Risks

We can split this again into two groups.

• Risks related to the management of the project. We can use PMBOK as a basis for further splitting these risks.
• Scope related risks
• Time related risks
• Resource related risks
• Communication related risks
• Cost related risks
• Quality related risks
• Risk management related risks. Risks related to how you identify and manage risks.
• Procurement related risks
• Integration related risks
• Risks related to the production of the project deliverables. These can be further split into:
• Concept related risks. Is the underlying concept flawed? What will we do if it is?
• Design related risks. What if the design is flawed or not optimal?
• Construction/procurement related risks. Risks related to building the concept.
• Delivery related risks. Risks in delivering the output of the project.
• Benefit realisation related risks. Risks around the delivery of benefits or the measurement of benefits.
• Ongoing support risks. Supporting the deliverables into the future.

Corporate Risks

An organisation can be looked at as:

• A group of people
• Utilising money
• To build assets including intellectual property, physical assets, products, services and relationships
• And adopting business processes to achieve an outcome (usually a profit for shareholders)

Each of these is potentially a source of risks

People

People risks can be related to:

• Personality traits. Issues with difficult or conflicting personalities.
• Organisational structures. Lack of authority or accountability to address project decision making.
• Availability of resources
• Knowledge and skill of resources. Having the right resources to work on the project. Can also cover the lack of suitable competence within the organisation.

Money

• Availability of funding
• Cash flow. Fluctuations in spending across the project.
• Cost blow out. Managing variations.
• Demands on corporate funding from other areas. What would happen if your organisation was involved in a takeover? What if there is a profit slump?

Assets

• Facilities and equipment required by the project
• Capability of the organisation to run the project. Many organisations have taken on projects they were ill equipped to run.
• Availability of external expertise. Sometimes the risk is the lack of realisation that you need external expertise to make the project successful.
• Impact on existing products and services
• Development of new products and services

Business Processes

• Bureaucracy. Becoming bogged down in internal decision making policies and procedures and resulting delays.
• Governance (or lack of it). This covers project governance as well as governance at the corporate level.
• Flexibility of processes. Sometimes the business has to adopt new processes as the result of a project. Is the organisation flexible?

Looking Without

Most organisations deal with four groups of people.

1. Suppliers
2. Customers
3. Regulators
4. The General Public

Suppliers

The risks associates with suppliers are usually around:

• Capability to deliver. Are you sure your suppliers are able to deliver the desired quality on time and within budget?
• Timeliness. Can they meet deadlines?
• Cost. Are you confident of your cost estimates?
• Quality. Will the quality of deliverables meet your expectations?

Customers

Customer risks relate to:

• Product acceptance. Will your customers (internally and externally) accept the output of the project?
• Value perception. Will your customers see they are getting value for money? Many projects have delivered to specification but were considered a failure because it was seen as too expensive for what was delivered.
• Competitor activity. If a project takes months or even years, your competitors are not necessarily standing still. What are they likely to do when they hear about your project? Will they neutralise your work by completing the same activity themselves?
• After sales service. Are there risks around the team disbanding and leaving no mechanism to support the project deliverables?
• Product performance. Will what you deliver do what it is intended to do?

Regulators

Regulators have a separate set of risks. These include:

• Compliance with existing regulations
• Development of new regulation. Many projects require regulatory structures be changed. This can be a long process if a regulatory body decides it is difficult or controversial.
• Time to adapt/meet regulatory requirements. The time it takes to meet regulatory requirements can be extensive. Sometimes to get a sign off for a new project can take months or even years.
• Diligence of the regulatory authority. Some regulatory bodies seem to operate on the basis that if they can't find something wrong, they are not doing their job.
• Change of regulatory regime (e.g. Change of Government). Many companies have been burnt by changes in a regulatory environment. It may be a change in government or a change in public perception. Imagine a financial project that started just before the GFC. If it was still running after the GFC it would be subject to all sorts of new regulatory restrictions.

The General Public

These are some of the most unpredictable risks. Who ever built the GFC into their project risk assessment? Who in the US government anticipated Wikileaks? Here are a few starting points:

• Lack of acceptance by the public. Good products fail if the public does not see the value in the product. Sony learnt that with Betamax versus VHS.
• Adverse publicity. Competitors can use adverse publicity as a competitive weapon. FUD (Fear, Uncertainty and Doubt) is not restricted to big software companies.
• Changing public values. What happens if the public changes it's values? One example was a cross city tunnel in Sydney. It had wide support until people realised that part of the private/public deal was that the government closed or restricted roads around the tunnel to force people to use the tunnel. The public did a 180 degree shift in their perception of the value of the development.
• Lobby group activity. Like it or not, most western countries live in a "banana" environment. "Banana" stands for "Build Absolutely Nothing Anywhere Near Anyone". In some projects it is almost inevitable that people will oppose any change. That can pose a risk.
• Economic changes. If there is a change in the economy - boom or bust - what will happen?
• Political changes. A change of government can be a major risk in some cases.

Conclusion

There is no "one size fits all" template for evaluating risks. I use the framework above as a generic checklist to make sure I have not missed any risks. In most cases, after I have put together a risk assessment, I can find some risks I missed by using the template. Some areas actually overlap in some projects.

One thing you might want to do is to start a list of generic risks for each category above. Use them as a checklist against your current project and see if they apply. If you have developed a mitigation strategy for the risk, perhaps it can be applied to your current project and save you time and effort. Below is the full checklist:

Risk Checklist

The Author

Neville Turbit has had over 20 years experience as a Project Management and IT consultant and almost an equal time working in Business. He is the principal of Project Perfect. Neville can be contacted at turbit@projectperfect.com.au

To date, 13 people have rated this article. The average rating is 4.31 - Add your rating. Just select a rating and click the button. No other information required. Only one rating per person is allowed.

Risk Framework 1 2 3 4 5

Return to the top