Management Guide

management   »  project management   »  project risk   »  types of project risk

22 Types Of Project Risk

        posted by , March 11, 2013

When you're young, risk seems like an interesting topic. It sounds like something you might encounter on a snowboard or in a race car.

By the time you've grown up and become a professional project manager, it's equally fascinating.

Project risk management is a project management activity that involves identifying, assessing, measuring, documenting, communicating, avoiding, mitigating, transferring, accepting, controlling and managing risk.

The process of identifying risks is intuitive for experienced project managers. The following types of risks (risk categories) should be enough to stimulate your creativity.

1. Executive Support

Wavering, inconsistent or weak executive commitment is often a project's biggest risk. This can be difficult (but not impossible) to document. Ask for specific commitments. Where you are denied you can document it as a risk.

2. Scope

The quality of your estimates, dependencies and scope management. If an estimate is just a guess, that's a risk. Be sensitive to the comfort level of estimates. If your team is unsure about a particular estimate, you can document this as a risk.

3. Change Management

A continuous flow of complex change requests can escalate the complexity of your project and throw it off course. Change requests may lead to a perception that a project has failed because they continually add budget and time to the project.

If requirements are missing items that are expected to come later, that's a risk.

4. Stakeholders

Stakeholders with a negative attitude towards a project may intentionally throw up roadblocks every step of the way. If you anticipate conflict or a lack of cooperation between stakeholders, document it as a risk.

5. Resources & Team

Resource issues such as turnover and learning curves are common project risks.

There's always a risk that your key experts will leave. If your team are inexperienced or need to acquire new skills, that's another risk.

6. Design

The feasibility and flexibility of architecture and design are key to your project's success.

Low quality design is a risk. You might want to highlight the design of complex or experimental components as separate risks.

7. Technical

The risk that components of your technology stack will be low quality. There are dozens of quality factors for technical components (e.g. stability, availability, scalability, usability, security, extensibility).

It's a good idea to identify specific risks in components. For example, the risk that a component will have a security flaw.

8. Integration

Whatever you're delivering needs to integrate with the processes, systems, organizations, culture and knowledge of the environment. Integration risks are common.

If you need to integrate your project into a business process there's a risk that the process will be disrupted. This may represent a significant business impact. In 1999, a ERP implementation at Hershey's disrupted manufacturing and distribution operations. The company was unable to process $100 million in orders. Quarterly profits dropped 19 percent.

9. Communication

Invalid stakeholder expectations is a fundamental project risk. If the stakeholders think you're building an orange but you're building an apple — your project will fail.

If stakeholders become disengaged (e.g. ignore project communications), that's a risk.

10. Requirements

Garbage in, garbage out. If requirements aren't feasible or are detached from business realities, your project may fail.

Look at the feasibility, quality and completeness of requirements to identify risks. Look at whether requirements are possible to integrate with organizations, processes and systems.

11. Decision Quality

Slow, low quality or ambiguous decisions are common risks.

12. Feasibility

Risk identification is a critical time to consider the feasibility of the project. Ask the key members of your team to do their own sanity checks.

List any doubts about feasibility as risks.

13. Procurement

The procurement process is ripe with risks. For example, there's a risk that you won't find an acceptable proposal to an RFP.

There's also a risk that your vendors won't deliver to the terms of their contracts.

14. Quality

Quality and risk management are intertwined. You'll expect to have defects in your project. However, there's a risk that quality won't meet basic levels. Significant rework may trigger project failure.

Identify quality related risks for process inputs and outputs. Identify quality risks for infrastructure, work packages, components and products.

15. Authority

Project teams often lack authority to complete project work. In many cases, teams are expected to influence to achieve project objectives. This reflects business realities. For example, your project may cross organizational boundaries. It's rare that a project team doesn't depend upon influence.

It's a useful exercise to think of risks in terms of a lack of authority. If you need to influence to secure infrastructure. cooperation or inputs — there's always a chance the answer will be no.

16. Approvals & Red Tape

If you anticipate that red tape (e.g. financial approvals) will slow down your project — add this as a risk.

17. Organizational

Organizational change (e.g. restructuring, mergers, acquisitions) will throw your project off track.

Think about the minimum stability that your products require to launch. List potential organizational changes as risks.

18. External

External forces such as laws, regulations and markets. If your project touches compliance-sensitive processes regulatory change is a risk.

19. Project Management

If your organization asks you to streamline your project management methodology (drop processes and documentation) you can document this as a risk.

20. Secondary Risks

Secondary risks are often overlooked aspect of risk.

Secondary risks are the result of risk mitigation and transfers. Let's say you transfer a risk to a vendor with a fixed price contract. The contract itself represents a counterparty risk. You've replaced a series of project execution risks with a series of procurement risks.

21. User Acceptance

There's always a chance that users will reject your product. You can build a product that matches requirements (on time and to budget). However, if users reject the product the project will be considered a failure.

22. Commercial

If you're building a commercial product for market (new product development), there's always a chance the product will be a commercial failure. This should be documented as a project risk.

3 Shares Google Twitter Facebook

Related Articles

Project Risk
How to identify and manage project risk for fun and profit.

Change management is often painful, political, emotional and error-prone. One powerful tool, that's often overlooked is change management principles.

Managing a long running business mission.

Everything you wanted to know about organizational change management but were scared to ask.

Manage by leading your team.

Recently on Simplicable

The Toyota Way

posted by Anna Mar
In 2001, Toyota published 14 management principles. They're nothing short of brilliant. Since their publication, they've influenced virtually every fortune 500 company.

64 Reasons That IT Projects Fail

posted by Anna Mar
The many paths to project failure.

30+ Management Strategies

posted by Anna Mar
The following strategies look past the management fads. It is a straightforward list of actions you can take to tackle common management challenges.

Risk Management Guide

posted by John Spacey
A guide to risk management.


about     contact     sitemap     privacy     terms of service     copyright