There's an easier way to manage project risks

Join 249+ project managers, letting their teams come up with the best methods to deal with risks. Step-by-step instructions for using the same risk identification methods as Google and NASA.

Step #1 Identify project risks

Risk categories:

  • Acceptance criteria not clearly defined
  • Activities missing from scope
  • Adding people to a late project, resulting in additional training and communications overhead
  • Approvals get delayed
  • Architecture is not fit for purpose
  • Assumptions are inaccurate (events or circumstances that are expected to occur during the project life-cycle)
  • Authority is unclear (unclear roles or responsibilities)
  • Changes cause unexpected negative impacts on people, process or to the product itself, i.e. Change propagation
  • Choise of technologies
  • Communication between stakeholders is slower than expected, e.g. time to answer clarifying questions about the requirements
  • Customer will not accept the finished software even though it meets specifications
  • Conflict between stakeholders disrupts project
  • Contractor doesn't deliver as promised, or the quality is unacceptably low
  • Cost forecasts are inaccurate
  • Customer requirements continue to change
  • Delays to financial approvals impact the project
  • Delays to recruiting processes impact the project
  • Delays to stakeholder approvals impact the project
  • Development tools do not work as expected
  • End users ultimately find the product to be unsatisfactory, leading to redesign and rework
  • Excessive multi-tasking
  • Failure of suppliers to meet contractual commitments
  • Failure to integrate
  • Failure to meet projected revenue targets
  • Failure to obtain appropriate approval
  • Fraud or theft
  • Friction between developers and customers
  • Friction between the project team and the client
  • Gold-plating (adding unnecessary, frivolous features or requirements)
  • Handling multiple projects simultaneously
  • High turnover on the project team
  • High schedule pressure, resulting in reduced productivity
  • Impacted individuals aren't kept informed
  • Inability to secure sufficient resources for the project
  • Inadequate or inaccurate information
  • Indecision or inappropriate decision making
  • Inefficient team structure
  • Key manager leaving the company
  • Lack of a change management process
  • Lack of automation
  • Lack of clarity over roles and responsibilities
  • Lack of effective project sponsorship
  • Lack of operational support
  • Lack of risk management
  • Lack of stakeholder buy-in
  • Lack of testing
  • Lack of transparency
  • Lack of user input
  • Layoffs and cutbacks
  • Launch date is moved up with no adjustments to the project scope
  • Language issues
  • Legacy components, which are out of support
  • Legacy components, which lack documentation
  • Legal and regulatory issues. For example the product depends on regulations, which change unexpectedly
  • Low team motivation, for example management makes decisions that the team disagrees with
  • Market developments adversely affect plans
  • Meetings are inefficient
  • Merger or acquisition disrupts the project
  • Micro-management, for example customer micro-manages the development process
  • Multi-location issues
  • New or changed legislation
  • New technology
  • Noisy, crowded offices
  • Office is inadequate (for example poor internet connection, furniture, ergonomics, office supplies)
  • Operation lifetime lower than expected
  • Outsourcing to reduce cost
  • Overestimated savings from new tools or methods
  • Overly optimistic schedule
  • Other tasks that cause delays, such as budget approvals, equipment purchase approvals, legal reviews, security clearances
  • Partnerships failing to deliver the desired outcome
  • Permits. For example, getting a work permit takes longer than expected
  • Personality clashes
  • Planning to catch up later
  • Poor software quality, resulting in extra testing, design and integration work
  • Poor team dynamics
  • Poorly designed solution
  • Project plans are abandoned under pressure
  • Resistance to change
  • Schedule was based on the use of specific team members, whom are not available to work on the project
  • Schedule omits tasks
  • Scope creep
  • Scope not clearly defined
  • Security vulnerabilities
  • Status reports are inaccurate
  • Team is inexperienced
  • Team misunderstands requirements
  • Team performance issues. For example, team members do not buy into the project
  • Stakeholder conflict over proposed changes
  • Stakeholders have inaccurate expectations, e.g. about development speed
  • Steep learning curve, which leads to delays and increased costs
  • Switching tools in the middle of a project
  • Team members with negative attitudes
  • Technical opinions
  • Team member leaves before project is complete
  • The project fails to match the company culture
  • Unclear project vision
  • Features take more time than expected to design and implement
  • Uncontrolled problem employees
  • Unexpected dependencies
  • Unrealistic expectations
  • User interface is low quality (poor UX)
  • User interface isn't accessible
  • Vendors start late