22 Types Of Project Riskposted by Anna Mar, 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 SupportWavering, 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. ScopeThe 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 ManagementA 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. StakeholdersStakeholders 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 & TeamResource 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. DesignThe 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. TechnicalThe 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. IntegrationWhatever 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. CommunicationInvalid 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. RequirementsGarbage 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 QualitySlow, low quality or ambiguous decisions are common risks.
12. FeasibilityRisk 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. ProcurementThe 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. QualityQuality 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. AuthorityProject 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 TapeIf you anticipate that red tape (e.g. financial approvals) will slow down your project — add this as a risk.
17. OrganizationalOrganizational 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. ExternalExternal forces such as laws, regulations and markets. If your project touches compliance-sensitive processes regulatory change is a risk.
19. Project ManagementIf your organization asks you to streamline your project management methodology (drop processes and documentation) you can document this as a risk.
20. Secondary RisksSecondary 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 AcceptanceThere'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. CommercialIf 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.
The identification, prioritization and control of business risk.|
If your estimates are as accurate as a baby throwing darts, you're not alone.|
A comprehensive guide to project management strategies, techniques, methods and careers. |
The many styles of managers.|