Project risk analysis: how to keep it pragmatic?

When was the last time you told your leadership team: "No, we're not going ahead — it's too risky! We're at N% risk / On time / On cost / On quality!

In this article, we'll look at risk analysis in project management and at what isn't written in the project PMO handbook...! After a quick refresher on the fundamental risk models in project management, we'll look at why a project risk analysis turns into an overengineered monster — and a waste of time — when it's done the traditional way. Then we'll propose leaving hypocrisy and subjectivity behind to build a modern, digital and pragmatic practice!

Why does it matter in project management?

Risk management may never have been as important as it is today

A project is always an investment; you'd better make sure it can be carried out effectively. This is the stage where you establish how you intend to reach the project's objectives. The goal is to find out whether the project is economically viable, whether it is actually feasible (technically, and within realistic cost and time limits), and to understand the project's consequences for its environment.

Anyone who has ever had to manage a project... or an IT system during a pandemic, knows that risk analysis is both essential AND that it isn't enough.

Experience teaches us that nothing ever goes as planned... and that if you're not careful, there's a good chance you'll blow through the deadlines and the budgets, and that the expected quality won't be there.

Some of these difficulties will be predictable, and you'll be able to anticipate them. That is precisely what project risk analysis is for: keeping you out of that kind of situation. Thanks to it, you'll have an arsenal that is both proactive and reactive ready to use... and above all, if an unexpected crisis hits, thanks to your solid project management you'll be able to devote your energy to what wasn't "predictable".

The pandemic reminded everyone that the unexpected always shows up: "This unexpected shock reminded us that forecasts are regularly proven wrong. History is a succession of improbable events that follow one another, collide and intertwine to give birth to a future that was unimaginable just a few months earlier." (Yannick Roudaut, author of Quand l'improbable surgit - Un autre futur revient dans la partie ! Ed. La Mer Salée, Oct. 2020.)

What is a risk in a project?

A risk is a possible future event that is identifiable and that we can quantify in project management.

Risk is inherent to every project. It can come from the nature of the project, the allocated budgets, the degree of complexity, the resource requirements, etc.

One very important nuance: the NFX50-117 standard (Project management – Risk management – Managing project risks) distinguishes between the unforeseen, hazards, risks and problems.

One of the risks of your risk assessment of your project's potential risks is precisely this confusion — and the blurring effect that comes with it.

"Classic" IT project risk types, with selected examples:

• Functional: the weight of custom-specific work in the project is too high...
• Technical: there's a technological lock... don't hesitate to run a POC to clear the identified risks.
• Organizational: commitments not kept (schedule, workload and costs)
• Roadmap: small projects and non-priority projects... a revision of the project roadmap causing the project to be shifted or postponed
• Project management: no key milestones positioned for each planning phase.
• Internal client: low involvement of the business owner / business teams in the project
• Vendor relationship: difficult communication, low responsiveness from the vendor's team, etc.
• SLA: misjudging the required service levels, such as availability or response times. => Verify vendors' claims about their service-level agreements
• Legal: changes in the legal environment, etc... this sometimes touches on very sensitive, blocking topics...
• Human: decisions don't get made, or you need highly qualified people... in the middle of a talent war... or people who are already (over)booked...
• Cyber risk: depending on your organization's risk appetite, your cyber-risk management program will then determine how to prioritize and respond to these risks.
• Psychosocial risks: these cover stress, harassment, workplace violence and incivility. A risk to transfer to HR.
• Financial: the minimum ticket is too high, for example.
• Communication and management: too many stakeholder absences...

And so on... a non-exhaustive list!

For each type of risk, you'll therefore record: its type / keywords / a description / the potential impact / and the recommended actions in a register... (see below).

The 4 steps of project risk analysis

The risk management process breaks down into 4 steps.

For the PMBOK®, risk management is defined as "the systematic process of identifying, analyzing and responding to project risks."

• Step 1: identify the project's risks
• Step 2: assess the probability and consequences of the risks
• Step 3: propose actions for each risk
• Step 4: monitor and report on risk tracking

Step 1: Identify (and prioritize) project risks in a matrix... a readable one!

Risks must be identified and addressed both as early as possible in the project AND throughout the project's life cycle, with particular attention at milestones.

If certain risks are too big —> run a project to de-risk, and only then decide whether or not to green-light the project. (see part 3 below).

Nota bene: when a quality management approach is in place in the company... this process is best run jointly with the quality manager, during management reviews among other occasions.

Here, once you've filled in the Excel file (a little) to practice your scales... think outside the box!

Get creative: first make your risk analysis readable and, above all, collaborative. For instance, use the "games that do the work" inspired by Agile culture.

Have you heard of the "Pre-Mortem"? This game was popularized by Dave Gray, James Macanufo and Sunni Brown, the three authors of the bestseller Gamestorming (ed. diateino, 2014).

The idea is to anticipate all the reasons why the project, the product, the service, the company… could fail, precisely so that they never happen.

One important point about this collaborative approach: never dismiss minority opinions! The majority isn't necessarily right when it comes to analyzing risks.

Step 2: Assess the probability and consequences of the risks

What they tell you at school, in risk management class: build a quantitative profile for project risk, notably based on an average of probability, severity and criticality!

What you learn in the field: with these assessments, these matrices are hard to "maintain"... and the quantitative scoring takes us straight into pure subjectivity!

So, beyond all the best practices and beautiful quantitative matrices... put your trust in simplicity, in processes, in experience and in your intuition!

A disaster recovery plan (DRP) and/or business continuity plan (BCP) won't vaccinate you against everything... but they make for an interesting "risk airbag".

In terms of experience... beyond your own and your team's, you can lean on popular wisdom... for example on what the laws of time have taught us... here's a quick update:

• Murphy's Law: "nothing goes as planned" - "Anything that can go wrong, will go wrong".
• Or Hofstadter's Law, which states that "whatever the planned duration of a project, it will not be delivered within the allotted time."

The lesson to draw: the project manager and their team should estimate more generously the time needed to deliver their project. Assume it will inevitably run late. A CIO used to hammer this into us: "Build cushions into your schedules"!

Step 3: Propose actions for each risk

• Accept: everything is normal... keep monitoring.
• Reduce: lower the probability of occurrence and/or the severity of the impacts.
• Transfer: shift responsibility for a risk to a third party who would bear the consequences of the problem
• Avoid: total elimination of the uncertainty.

Beyond the basics and anticipation... the most important action in your project management will be the ability to decide. Including deciding not to launch the project. On that point, remember the formula coined by Olivier Bas, vice president of the Havas group:

To achieve this prudent risk management, you'll need to have demonstrated that you've "de-risked" your project. In practice, that can mean having launched a dedicated project — a kind of risk-free prototype.

Step 4: Monitor and report on risk tracking

An organization must be put in place to communicate on how risks are being controlled. Yet this fourth step is where implementation seems the most uneven today...!

Generally speaking, a lack of written transparency can lead to heavy failures.

Used well, a project steering tool makes it possible to align the IT department, business teams and top managers, around value, breaking down the silos of an organization that is sometimes too heavy or compartmentalized within each company.

How do you evolve operational risk management during the project?

You may also suddenly face new risks, or watch once-critical risks lose intensity. In short: keep a regular eye on your risk map. This risk management process is iterative. The catch... going back over the initial map to update it is a heavy workload. How do you go about it without spending all your available bandwidth on it?

How to do it:

• Raise attention points on a continuous basis
• Same for decisions
• Update the project health statuses and their operational context

Human factors: the indicators that turn a risk into a problem...

• If decisions aren't being made
• If there are too many absences among stakeholders
• Distrust that the milestone will be met
• Non-exhaustive list :)

SaaS... new risks, unfamiliar and often misunderstood

• Trust your vendor's resilience capabilities — and verify!
• Test your resilience plans to make sure they work and that everyone knows how to execute them in a crisis.

In short:

• It's usually the lack of written transparency in companies that leads to project failures;
• Taking the risks and constraints of the project into account will allow you to make radical decisions: launch the project or not, and possibly put in place actions that will make it feasible for a team.
• Risk analysis is done at the start of the project, at the feasibility study stage, and at the major milestones of the project cycle.

To go deeper on this last key point, we recommend reading the article: Project milestones: a technique to sequence your projects intelligently.