Project Risk Management starts as soon as the project business case begins to form. Every project begins with a few questions to evaluate the business case and the organization’s ability to deliver:

  • What resources (financial, time, staffing, technology, etc.) are needed? Are they available?
  • What experience does the organization have with this type of project?
  • What ability is needed to be successful and is it available?
  • What project roles are needed and are they available?
  • Will the project owner and sponsor fulfill their responsibilities?
  • What type of project approach should be used? Will this be supported in the current organizational culture?
  • What are the project goals? Deliverables? Tasks?
  • How will success be evaluated? By whom?

The project questions are almost unlimited and are determined by the type of project, industry, organization’s culture, and experience with the deliverables targeted. The project management body of knowledge (PMBOK, 2013) identifies five core process areas. Each answers specific questions relevant to the team’s project:

  • Initiating Group
  • Planning Group
  • Executing Group
  • Monitoring & Controlling Group,
  • Closing Group

Not all organizational contexts are suited for the project management methodology. Understanding this up front can help the team to avoid initiating and committing to project processes that lack the sufficient resources and buy-in.

Large scale organizations hire ‘project managers’ with the intent of realizing the benefits and values ascribed to the project management method; but fail to take into consideration the commitment and investment needed to insure accountability and follow through is maintained throughout the project’s life-cycle. Project managers brought onboard in the middle of a project are particularly at risk of taking on a project that was ‘designed to fail.’

Key signs that a project is ‘designed to fail’ include the following:

  • Project requirements & scope have not been confirmed
  • Project requirements are driven by non-customer groups
  • Project plan is under-developed (or not developed at all)
  • Project schedule is arbitrary, experiencing multiple updates
  • Project critical chains are yet to be identified; or
  • Project deliverables impacting critical chains are arbitrarily rescheduled (and/or without stakeholder consultation)
  • Project team membership is in constant flux
  • Project ability is often unavailable
  • Project owner & sponsor responsibilities are poorly executed
  • Project lacks ‘executive leadership’
  • Project structure and deliverables do not meet stakeholder or customer needs
  • Project business case is poorly articulated and/or understood
  • Project decisions are delegated (or left) for the wrong roles to resolve, or
  • Risks are addressed poorly

Each of the project risks identified above need to be identified and evaluated at the onset of the initiation stage to insure:

  • This is the right project
  • This is the right solution
  • This is the right environment
  • This is the right team, &
  • This is the right project owner & sponsor

Hiring a project manager will not make a ‘bad idea’ successful. Neither will hiring a project manager repair a pre-existing ‘dysfunctional environment’ and deliver perfect performance.

The foundation for success needs to exist prior to the hire of a project manager and before environment level risks can be resolved. The ADKAR change management model (Prosci, 2017) includes five different stages that can be used to evaluate the organization’s readiness and ability to carry out sustainable change:

  • Stage 1: Awareness that the dysfunction exists in only the first step.
  • Stage 2: Desiring a solution to the problem is the second.
  • Stage 3: Having the Knowledge to apply the solution is the third step.
  • Stage 4: Having the ability and training necessary to use the knowledge, and carry out the solution is the fourth step; with..
  • Stage 5: Reinforcement and feedback mechanisms representing the fifth step.

Most risk management models begin with compiling a list of the risks into a ‘risk register.’ Six pieces of information are collected to build out the risk register and identifies strategies to resolve each risk:

  • Step 1: Identify the risk.
  • Step 2: Identify the probability of the risk occurring
  • Step 3: Identify the impact of the risk if it does occur
  • Step 4: Multiply probability x impact to identify the relative ‘weight’ for each risk on the register
  • Step 5: Identify the organization’s strategy to respond to the risk
  • Step 6: In one word, identify the organization’s response (accept, reject, mitigate) as it pertains to the probability x impact of the risk.

Referencing the ADKAR model (Prosci, 2017) the project team is better ready to identify what process group questions, and strategies, need to be emphasized throughout the project life-cycle. The following two spreadsheets represent fictitious examples of how the risk register is used. An extra column, “L” is added to identify the ADKAR level relevant to each risk identified on the register.

Risk Management and project management require a system’s approach. When the project foundation is lacking the team’s success is unlikely. Hiring a project manager will not resolve the risks identified unless there is adequate awareness, desire, knowledge, ability, and reinforcement. Planning and identifying risks is only the beginning of the project manager’s journey.

How is your organization conducting risk management? Share your comments below.