Gestión Pragmática de Riesgos

El Riesgo es una de esas cosas que realmente no nos gustan pero que no tenemos otra alternativa mas que lidiar con ellas. En palabras de Joe Black es tan cierto como la muerte y los impuestos. Este nivel de certeza cuando usted se encuentra al nivel del Programa, debería significar que los equipos son bastante buenos para lidiar con el. Sin embargo muchas veces no es el caso. Algunos equipos lidian con el riesgo de manera extrema. Unos del todo no lo manejan, considerando cualquier incidente como un evento impredecible, colocando la iniciativa y potencialmente a la organización en un irremediable camino de fracaso. Otros intentan desarrollar verdadera ciencia de cohetes antes de levantarse y manejarlos, causando un gasto extra que resta velocidad y agilidad requeridas para alcanzar un programa de resultados exitosos. 

Los equipos efectivos desarrollan un balance pragmático entre estos extremos. Ellos mantienen en mente que el objetivo último detrás de la Gestión de Riesgos no es otro que determinar lo que podría jugar en contra del proyecto, de manera que lo puedan prevenir o reducir su impacto; al mismo tiempo que determinan lo que podría jugar a su favor e intentan hacer que ocurra. Unos pocos principios deberían poner al equipo en este camino pragmático hacia el balance cuando lidian de manera efectiva con los riesgos. 

Hacerlo Visible – este es quizás el principio mas importante que esta detrás de la Gestión de Riesgos. Se trata de la visibilidad. Es acerca de darle visibilidad a algo que podría salir mal. Si un evento no es visible para el equipo entonces nadie será capaz de hacer nada al respecto. 

Gestionando la Bitácora – El equipo necesita una única bitácora consolidada de los riesgos del Programa o Proyecto; es la responsabilidad del Gerente del Programa/Proyecto proveerlo, y facilitar su manejo a los miembros del equipo. La bitácora debería permitir a todos los miembros del equipo registrar lo esencial acerca de un riesgo, así como las acciones de respuesta que se toman a través del tiempo. Una práctica común es desarrollar una lista más integral llamada la bitácora D.A.I.R, que registra no solamente riesgos sino también decisiones, acciones e incidentes. Algunas veces las diferencias entre estos son claras, algunas veces son difusas. Lo que es mas importante es describir la situación de manera especifica, para que las respuestas apropiadas puedan ser identificadas y desarrolladas. Si algo es descrito muy vagamente, no se podrá resolver de manera efectiva. 

Aportes Comunitarios – muchas cosas pueden considerarse riesgosas para un proyecto y podría venir virtualmente de cualquier parte. Debido a esto usted no quiere una bitácora de riesgos sesgada solamente por su propia perspectiva, o por la perspectiva de algún patrocinador. Es acerca de la visibilidad. Usted quiere tantas perspectivas como sea posible, de manera que tenga la mejor línea de visión posible acerca del emprendimiento. Usted se preocupara de las prioridades después. Si, esto significa que habrán muchos riesgos en la bitácora; no existe un numero mágico, solo mantenga en mente que mas es mejor. En este campo, para darle una idea, nuestro programa actual de 2 años de duración esta llegando a las 700 entradas en la bitácora D.A.I.R. en estos días. Esto es un promedio de 29 entradas identificadas por mes. 

Primero lo Primero – no se puede dar el mismo nivel de atención a cada riesgo. De hecho no debería. Riesgos con mayor posibilidad de ocurrir y cuyo impacto sea peor deberían lanzarse hasta arriba en las prioridades. Una manera simple de hacerlo es definir una escala (1 a 10 por ejemplo) para cada variable (posibilidad de ocurrencia e impacto) y multiplicarlas. Alguien puede probablemente decir que hay maneras más sofisticadas de clasificar los riesgos. Es verdad, pero la mayoría de los proyectos y las industrias no requerirán un enfoque fuertemente estadístico o elaborado, solamente una manera justa de clasificarlos Otra herramienta útil es una bandera para indicar si un riesgo debe ser revisado al nivel de la PMO o no. Esto le permite a los Administradores del Proyecto registrar los riesgos que deben gestionar, pero solamente marcar para atención de la PMO unos pocos. El Gerente del Programa realiza reuniones periódicas para revisar cada entrada marcada para atención. Estas banderas pueden cambiar según sea necesario. 

Siga Marchando – La Gestión de Riesgos es un esfuerzo continuo durante todo el ciclo de vida del Proyecto. Por esto es que se deben definir reuniones periódicas de seguimiento, los riesgos deben monitorearse, es responsabilidad de cada miembro del equipo que abre un riesgo, o que interviene en el, mantenerlo actualizado conforme las circunstancias cambian y las respuestas se desarrollan y ejecutan. 

Hacer todo esto suena un poco molesto cuando usted tiene un proyecto o programa que entregar, pero estas tareas son una de las principales razones para tenerle como Gerente de Proyecto. Si no lo hace, tendrá que pagar un precio muy alto. Y toda la organización también. 

“Solo aquello que se monitorea se puede prevenir” 

– Sergio Calvo.

Pragmatic Risk Management

Risk is one of those things that we really don’t like but that we have no choice but to live with. In Joe Black’s words it is as certain as death and taxes. This level of certainty when you are at the program level should mean that teams are very good at dealing with it. However it is often not the case. Some teams take an extreme approach when managing risks. Either they do nothing to manage them, considering any issue as an unpredictable event, putting the endeavor and potentially the organization in an irremediable path for failure; or they attempt to develop true rocket science before they step up to manage them, causing an overhead which rests the speed and agility required for successful program outcomes. 

From my perspective, effective teams develop a pragmatic balance among those extremes. They keep in mind that the ultimate goal behind Risk Management is no other but to determine what may play against the project, so they can prevent it or at least decrease its impact; and at the same time determine what could play in its favor and try to make that happen.  A few principles can help the team to develop that pragmatic, balanced approach  for  dealing effectively with risks. 

Making it Visible – this is probably the most important principle that lies behind managing risk. It is all about visibility. It is all about making visible something that could go wrong. If it is not visible for the team, then no one will be able to do anything about it. 

Managing the Log – Team needs a single consolidated log of risks for the program or the project; it is the responsibility of the program/project manager to provide it, and to facilitate its management to the team members. The log should allow all team members to track the basics about a risk, as well as the response actions taken to solve it through time. A common practice is to develop a more holistic list called the D.A.I.R. log, which records not only risks but decisions, actions, and issues. Sometimes the differences among those are clear, sometimes they are blurry. What’s most important is to describe the situation in specific terms so the proper responses can be created and developed. If something is described too vaguely, you know something is coming, but you don´t really know what that is.  It can’t be resolved effectively. 

Community Input – several things can be considered risky for a project and they can come from virtually everywhere. This is why you do not want a risk log biased just by your single perspective or that of a sponsor. You want as many perspectives as possible, so you have the best line of sight possible around the endeavor. You will worry about prioritizing the risks later. Yes, this means you will have lots of risks in the log; there is no magic number, just keep in mind that more is better. To give you an idea about it, our current 2 year program for a Data Center Migration is arriving at 700 D.A.I.R Log items these days. This is an average of 29 items identified per month. 

First things first – the same level of attention can’t be devoted to every risk. It actually shouldn't. Risks with greatest chance of occurrence and with the worst impact should be thrown all the way up to the top. A simple way to do this is to have a scale (i.e. 1 to 10) for each variable (chance of occurrence and impact) and multiply both of them. Someone can probably say that there are more sophisticated approaches to risk rating. True, but most projects and industries won’t require a heavily statistical or elaborated approach, just a fair way to combine both variables to prioritize all risks.

Another useful tool is a flag to indicate if a risk must be reviewed at P.M.O. level or not. This allows Project Managers to record risks they can manage on their own, and also labeling for attention of the Program Management Office a few ones requiring attention from upper management. Periodic meetings will be hold by the Program Manager to review every item flagged for attention at that level. These flags can of course be changed as necessity arises or no longer exists. 

Keep walking – Risk Management is an ongoing effort through the entire life cycle of the Project. This is why periodic review meetings are a must. Risks need to be monitored. It is responsibility of every person opening a risk to keep it up to date, as circumstances change and responses are developed and executed. New risks should be logged as they appear; the ones solved or with no chance of occurrence anymore can be closed and kept for the records and lessons learned. 

Doing all this stuff sounds a bit annoying when you have a product, result, or service to deliver, but these tasks are one of the main reasons to have you as a Project Manager. If you fail to do so, you will pay a very high price. You may end up with nothing to deliver. And so the entire organization 

“Only what is monitored, can be prevented”                              

– Sergio Calvo.

Your project and the traffic light colors

Project status is usually reported using traffic light colors. It is a concise yet clear indication of its condition through time. Green shows an effort on track with no issues. Yellow or Amber shows an effort slightly out of track due to issues requiring some attention. Red shows an effort with important or critical issues that keep it seriously out of track, demanding important attention. Blue, an additional color, reflects a project or phase already completed; according to the project plan and to the satisfaction of stakeholders. It is the coolest one so to speak. This approach allows a program manager to report effectively and quickly the status of an effort of a serious magnitude. That’s very useful.

As a Project Manager you have the final responsibility of choosing the color of your project. As a program manager you have the more subtle duty of defining ground rules for your project managers to decide on the colors, helping them to follow a logic reasoning process around them, and enabling them to report accurately to the stakeholders. This allows them to make sound decisions and take effective actions.

A project in a RED or AMBER status must provide at least one corresponding item logged in the D.A.I.R log. This is a register which tracks the type of obstacle the team is dealing with: Decision, Action, Issue, or Risk; the last action taken about the obstacle; and the impact of the obstacle on the project or program. All this becomes pretty handy when trying to decide on corrective or preventive actions in a meeting with the stakeholders. If you lack this link between the reported status and the D.A.I.R. log, you may end up out of reality. For example deciding to happily report the project YELLOW, when it should be plain RED; or showing it RED just because a minor issue stated incorrectly was magnified. A project or phase reporting BLUE must be considered complete by all the incumbents, having the corresponding supporting documents. Otherwise you could have some dead bodies walking around, or you could assume something was put down for good, when that wasn’t the case.

Keep in mind this is a tool, and it should be treated as such by all the team. It is very useful for monitoring and controlling execution, triggering corrective and preventive actions promptly. Proven that it is used to uncover items requiring attention as early as possible, having yourself and your team pushing hard to get to the bottom of issues, irrespective of where they come from. If status reporting is instead used to point fingers, or to get hard on people instead of the issues. It would serve little purpose. 

In that sense, an attitude of trying to show GREEN no matter what can be very harmful. You would only be hiding issues or risks in need of attention. You are brought in as a Project Manager to uncover those in a diligent manner, and to lead the best possible actions to remove them. You are not on board to show a happy GREEN from beginning to end, neither is your role to discredit the impact of existing obstacles. At some point the bad news you’ve been trying to cover will flood the entire place.

What color would you say your current project shows?

How are you planning to keep or to turn it back to GREEN?

- Sergio Calvo.