The most important project risks

Project risk is one of those exciting topics that everyone has an opinion about. 

Ask executives, functional managers, project managers or engineers about "project risk"— you'll get a long list of complaints.

Lack of executive and stakeholder commitment usually tops the list. It is often followed by bad requirements, constant changes, bad project managers and bad resources. In other words, risk identification tends to bring out plenty of negative emotions and finger pointing.

All this show the true value of project risk management. Each good project has plenty of risk. After all, the nature of business is about taking risks.

The risk free project achieves exactly nothing. You don't build businesses and great public institutions by hiding under a rock.

Risk management is about maximizing your chances of project success by identifying risks early and planning how to manage them. The following examples of risks will get you started down the path of risk identification.


Change Management

  • Change management overload. A large number of change requests dramatically raises the complexity of the project and distracts key resources.
  • Perceptions that a project failed because of changes. Large numbers of high priority change requests may lead to the perception that the project has failed. When the schedule and budget are       continually extended — stakeholders may feel the project had missed its original targets.
  • Lack of a change management process. Change management at the organizational or departmental level is a critical step. Otherwise, the project will have limited visibility into changes that           impact the project. 
  • Change request conflicts with requirements. Change requests that make no sense in the context of the requirements.



  • Stakeholders become disengaged. When stakeholders ignore communications/discussions what are directly related to the project.
  • Process inputs are low quality. Inputs from stakeholders that are low quality (e.g. business case, requirements, change requests).



  • Project team misunderstands requirements.When requirements are misinterpreted by the project team a gap  between expectations, requirements and work packages appears.
  • Communication overhead. When key project resources spend a high percentage of their time engaging stakeholders on project issues and change requests their work may fall behind.
  • Under communication. Communication is a challenge that's not to be underestimated. You may need to communicate the same idea many times in different ways before people remember it.


Resources & Team

  • Team members with negative attitudes towards the project. Resources who are negative towards the project may actively or passively sabotage project efforts. 
  • Low team motivation. Your team lacks motivation. This is a particularly common risk for long running projects.



  • Architecture fails to pass governance processes. Plan for any architectural or technology governance processes that the project may need to pass.
  • Architecture lacks flexibility. The architecture is incapable of supporting change requests and needs to be reworked.
  • Architecture is not fit for purpose. The architecture is low quality.
  • Architecture is infeasible. The architecture is impossible to implement, excessively costly or doesn't support the requirements.



  • Design is infeasible. The design isn't possible, is excessively costly or doesn't support the requirements.
  • Design lacks flexibility. A poor design makes change requests difficult and costly.
  • Design is not fit for purpose. The design is low quality.
  • Design fails peer review. It's a good idea to have peers or architectural experts reviewing your designs.



  • Technology components aren't fit for purpose. Technology components are low quality.
  • Technology components aren't scalable. Components that can't be scaled to meet performance demands.
  • Technology components aren't compliant with standards and best practices. Non-standard components that violate best practices.
  • Technology components are over-engineered. A component that's bloated with unneeded functionality and design features.


These are just some of the risks that can hit any project. The best thing to do for your project is to carry out proper risks identification. Spend some time brainstorming the risks that might affect your project and document them. Who knows, It may save your project !

We can’t wait to hear all the details about your project and to become a big, yet humble, part of it! Tell us everything!