Jackie Fenn: Mastering the Hype Cycle: How to Choose the Right Innovation at the Right Time Rodney Turner: The Handbook of Project-Based Management: Improving the Processes for Achieving Strategic Objectives Jerry Manas: Napoleon on Project Management: Timeless Lessons in Planning, Execution, And Leadership : A Guide To The Project Management Body Of Knowledge Project Management Institute: Organizational Project Management Maturity Model (OPM3) Knowledge Foundation

XHTML 1.0 valide !

CSS valide !

Subscribe to this blog

Contrat Creative Commons

Nov12Oops, it happened again!Posted at 11:16 in Project Management, Risk Management

A couple of weeks ago, in the latest Risk Doctor newsletter, there was a very interesting article about repeating mistakes. David Hillson sums it up like this:

If a risk happens once, that's understandable;

If the same risk happens twice, that's unlucky;

If the same risk happens three times, that's unacceptable.

People have a natural tendency to repeat their mistakes, either by letting the same threats happen repeatedly or by constantly missing the same opportunities. If you look around you, you will realize that this is happening all over the place, and it clearly tells that Risk Management is still overlooked in most businesses. Now there's value to add!

Jul04Top 5 Rules for effective Risk ManagementPosted at 18:21 in Risk Management

  • Manage your risks or they will manage you
    Risk management is not a passive process, you need to be on top of it.
  • Commit your Top Management
    Show them the savings, quicker time-to-market, reputation increase and get their support.
  • Say "NO" to the blame culture
    Share your risks with your boss, your customers, your suppliers, your colleagues, with everyone around you.
  • Review risks outside the lines of business
    Have an independant Risk Review Committee who also defines and adjusts risk appetite at enterprise level.
  • Learn from your mistakes
    Do not reinvent the wheel, use lessons learned and previous risk logs on similar areas

May22The Risk Management PlanPosted at 10:16 in Project Management, Risk Management

The Risk Management Plan is the key element of the Risk Management Process. It defines the Risk Process for the project, including Methodology, Roles and Responsibilities, Timing, Thresholds, Reporting, monitoring and review formats and procedures. You can find several templates on the net (like this one from PMHut), but what is really important is how you will use it, and how well it suits your own risk management processes. Amongst all criteria for judging the maturity of such a document, the two the most important in my eyes are the ability to manage threats as well as opportunities, and the ability to efficiently respond to a risk becomes an issue.

What is the risk? Why might it occur? How likely is it to occur? How bad or good might it be? Does it matter to the project? What can we do about it? When should we act? Who is responsible for the risk? Who is responsible for the response? These are all questions that should find answers in the Risk Register (part of the Risk Management Plan). This document must be reviewed and updated regularly, since new risks might arise during the lifetime of the project, and risks might realize, becoming issues, needing responses that might trigger new risks, etc.

In my Risk Register, I typically have 13 columns:

  • The RiskID, which is the unique identification for a risk, used by everyone to refer to that specific risk.
  • The ProjectID, which is the unique identification for the project within the corporate portfolio. If a risk is likely to happen in several project, it needs to be documented with several RiskIDs.
  • The Risk Category helps predefining responses or owners. It also serves for reporting purposes, thus helping on the predetermination front for future projects.
  • The Date Raised serves to track the evolution of the risk profile of a project. The more stable the risk register, the lower the risk profile of a project.
  • The Risk Owner has the ultimate responsibility to monitor the risk, and to raise the occurence of the risk to the Risk Manager. This needs to be documented in the Roles and Reponsibilities section of the Risk Management Plan.
  • The Risk Description is ... well ... the description of the risk.
  • The Impact is the result of the Risk Qualitative Analysis process. This field will usually have three possible values (low/medium/high), or if you want to more precisely rank your risks, five possible values (very low/low/medium/high/very high).
  • The Probability is the result of the Risk Quantitative Analysis process. This field will have similar values as the Impact (i.e. 3 or 5 possible values).
  • The Priority is a calculated field (which is why I usually use an Excel spreadsheet for my risk registers, unless I have access to an Enterprise Project Management software. It is a combination of Probability and Impact, and you can live without it, it just allows a quicker filtering on those who need your attention.
  • The Response Description is ... well ... the description of the response to the risk.
  • The Response Type is one of the following: Avoidance, Trnsfer, Mitigation, Acceptance. This will also help monitoring the efficiency of the risk management processes.
  • The Response Owner has the ultimate responsibility to act in the event of a risk realized. It can be someone else as the Risk Owner, and it needs to be documented in the Roles and Responsibilities section of the Risk Management Plan.
  • The Realized Date is the date when a Risk has triggered. This is the moment when a RiskID leaves the Risk Register to enter the Issue Log to continue being monitored in this document.

I understand this might look a little cumbersome, but in most situations, it can be the difference between saving a project and pulling the plug...

Mar27Pulling the plugPosted at 12:59 in Communication, Project Management, Risk Management

Pulling the plug

Very few organizations are capable of admitting that possibility of success is gone and that a project is failing. If expected benefits can't be delivered and deadlines can't be met, for the greater health, such projects must be terminated. It is never an easy decision to make, and it requires an objective and pragmatic analysis: Trade-offs need to be carefully weighted, and you need to have a comprehensive plan to address all anticipated issues (politics, expenses, relationships, etc).

Pulling the plug is important, because the cost associated with continuing the project might be (much) higher than the cost of terminating the project. This is valid for every single type of project, even a job hunting project: sometimes, it is better to back off if you don't feel comfortable with the way things are looking like.

Mar15An uncertainty that mattersPosted at 22:12 in Project Management, Risk Management

An uncertainty that matters

It has been a long time since I wanted to talk a bit more about risk. Risk Management is one of my preferred knowledge areas in the Project Management Body of Knowledge, but the sad thing is that it is often misused. It starts with the definition of a risk. In the common language, a risk has always a negative connotation: it refers to the possibility of misfortune or loss; to hazard; to something exposing to danger; perilous. To be honest, most people just keep looking at that single side of the coin. If you want to implement an integrated risk management process, you will have to consider that risk isn't always just a bad thing.

The PMI defines risk as an uncertain event or condition that, if it occurs, has a positive or negative effect on an objective. Dr. David Hillson has a much simpler definition of a risk: an uncertainty that matters. I love this sentence. It clearly outlines the two dimensions of a risk: the uncertainty (or probability); and the effect on objectives (or impact). That makes things easier to understand: if you can predict 100% of chances for something to happen, then it is not a risk. Nor is it a risk if it is uncertain, but has no impact at all on the project or its deliverables.

That being clarified, the PMBOK defines Risk Management as the systematic process of identifying, analyzing and responding to risk. There is a suitable set of processes in the framework to deal with risks, that works for both threats and opportunities. These processes naturally follow the phases of a project, but really need to be taken seriously. Underestimate them and chances are high that you will end up pulling the plug.

Coming next: The Risk Management Plan

Feb28Subprimes pour les nulsPosted at 08:28 in Gadgets and Fun, Risk Management

Voici une explication très simple pour ceux qui essaient encore de comprendre ce qui s'est passé :Madame Ginette a une buvette à Bertincourt, dans le Pas-de-Calais. Pour augmenter ses ventes, elle décide de faire crédit à ses fidèles clients, tous alcooliques et presque tous au chômage de longue durée. Vu qu'elle vend à crédit, Madame Ginette voit non seulement augmenter sa fréquentation, mais en plus peut augmenter légèrement les prix du calva et du ballon de rouge.

Le jeune et dynamique directeur de l'agence bancaire locale, quant à lui, considère les ardoises du troquet comme des actifs recouvrables, et commence à faire crédit à Madame Ginette en prenant les dettes des ivrognes comme garantie. Au siège de la banque, des traders avisés transforment ces actifs recouvrables en CDO, CMO, SICAV, SAMU, OVNI, SOS et autres sigles financiers incompréhensibles.

Ces instruments financiers servent ensuite de levier au marché actionnaire et conduisent, au NYSE, à la City et aux Bourses de Francfort et de Paris à des opérations de dérivés, dont les garanties sont totalement inconnues de tous : les ardoises des ivrognes de Madame Ginette.

Ces dérivés sont négociés pendant quelques années comme s'il s'agissait de titres solides et sérieux sur les marchés financiers de 80 pays, jusqu'au jour où quelqu'un prend soudainement conscience que les alcoolos du troquet de Bertincourt n'ont pas un rond pour payer leurs dettes.

La buvette de Madame Ginette fait faillite ... et le monde entier l'a dans le luc ...

 

Voici un autre lien qui explique de façon plus détaillée comment cela fonctionne...

Jun25Legal notice© 2004-2009

All content (447 posts since 25/06/04) published on this weblog is © Frédéric Casagrande, unless stated otherwise and published under Creative Commons licence. This weblog is hosted by Sixapart.

This weblog uses third-party advertising companies to serve ads when you visit it. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.