Why do we have to use risk analysis or feedback in project management ?
  • AGILEA and its partners

During one of my recent training in project management, a particularly unusual (and therefore very good) question emerged: what is the use of project risk analysis or feedback?

The answer seemed too obvious, and I asked this participant to clarify his mind. His response was as follows:

When we do risk analysis, we use a standard as if our projects were all similars. Besides, we have a low propensity to hedge risks or protect ourselves from our negative experience. Also, the risks or returns of experiences seized are both depending on the order of the hazards and the significant events. Finally, the combined measures that we associate with its risks (probability, impact, recurrence) seem to dilute the risk itself: does it make sense not to treat a threat because its probability and recurrence are low, but its effect is strong?


Behind a seemingly benign question, there seems to be a real underlying problem.

In this article, we will focus on the fact that the action is defined, recognized as useful, but not carried out. It is indeed a problem of execution (or managerial courage). We will look into the issues raised by this question:

  • How do we identify a problem on one of our projects?
  • How can we identify this problem as a huge problem?
  • How can we ensure that the actions taken will have a positive impact on the system?

To achieve this, we will use the Fever Chart indicator. As you know, progress (horizontal) is calculated over the rest to do, and the vertical portion represents the buffer consumption.

Let's take the real case of one of our clients, do you notice anything in the course of these three projects?

In fact, at the beginning of the project, everything is always going very well to the point that we go faster than usual. Then, between 10 and 20%, the projects systematically spin out, and then they recover suddenly. Moreover, you will notice that for both projects on the right, the client appears to have recovered faster. That's why we use this indicator!


Given the predictive nature of the indicator, it becomes easy to answer the three initial questions:

  • How do we identify a problem on one of our projects? As soon as the Fever Chart changes color, you can record the nature of the event that caused it to change.
  • How can we identify this problem as a significant problem? When the Fever Chart switches to the red vertically, you are not moving any further and consuming the buffer.
  • How can we ensure that the actions taken will have a positive impact on the system? If you line up these project indicators next to each other, you will see a particular pattern drawing on your projects.


To come back to our case, when you take the first project, you see the three phenomena after 10 to 20 % progress: the project turns yellow and red violently. Then it recovers just as quickly in yellow.

From a project management view, it is crucial to see what has happened but above all to understand what we could do to get back to yellow quickly. This way, you can duplicate/deploy this action on the rest of your projects: as soon as the peak emerges, you can take action faster and restore the project to the right track (see charts 2 and 3).


How do you use your project tracking the indicator to feed your risk analysis and feedback?