About the author  ⁄ eduocastella

238208999_b65d8b6e8f

La gestión del riesgo es una herramienta muy eficaz para gestionar los proyectos/programas con éxito. La gestión activa del riesgo reduce los eventos específicos de riesgos mediante la identificación de los mismos y actuar frente a tales situaciones antes que ocurran. Una ventaja importante de actuar en forma proactiva la gestión del riesgo es una disminución en el número de cambios que necesitan ser introducidos. A continuación intentaremos  eliminar algunos mitos en torno a la gestión de los riesgos de forma tal que los PM empiecen a verla como una herramienta eficaz para ayudar a manejar y controlar sus proyectos.

Muchas veces vemos el análisis de riesgos como algo engorroso, como una actividad que es simple documentación y que en el fondo no nos ayudará en la ejecución del proyecto. Muchas veces partimos de la ignorancia por no profundizar en la ventaja de aplicarlo y el cómo aplicarlo. Los 10 mitos típicos que se presentan en la gestión de riesgos son los siguientes:

1.” No conozco la gestión del riesgo”

A pesar de que aplicamos la gestión del riesgo en nuestra vida diaria, normalmente no lo vemos como ”Gestión del riesgo’. Como por ejemplo vacunarnos para protegernos de una enfermedad. Eso es gestión de riesgos, simplemente es identificar posibles situaciones y hacer algo para disminuir las posibilidades de que ocurran.

2. La Gestión del riesgo no es parte del trabajo del Project manager.                    

El trabajo del  Project manager es conseguir el beneficio del proyecto en calidad, tiempo y coste. Cualquier cosa que impida este objetivo es necesario identificarlo, abordarlo y resolverlo. La gestión de riesgo permite hacer eso de una manera estructurada.

3. Los riesgos tienen que ser inmensos para poder ser identificados.

Por lo general los componentes de un equipo de proyecto suelen creer que los riesgos que se han identificado son pequeños y que por lo tanto no son críticos  por lo que no merecen atención. Esto es una percepción errónea, puesto que los riesgos pueden ser de cualquier tamaño, identificar muchos riesgos pequeños es señal de un equipo maduro. Es cierto que los riesgos más grandes pueden requerir más atención, pero eso no puede ni debe reducir los riesgos menores.

4. No puedo identificar los riesgos porque es un proyecto nuevo.

Muchas veces tenemos stress cuando comenzamos un proyecto nuevo  con la idea de no habernos enfrentado nunca anteriormente a un proyecto igual.  Esta percepción no permite que los miembros del equipo aprovechen lo que saben. Muchas veces en las empresas se han tenido proyectos muy parecidos anteriormente pero no se lleva un log de los riesgos y las lecciones aprendidas. En estos casos puede ayudar  una base de datos con información de los proyectos anteriores internos.

5. Los riesgos son gestionados solo al inicio del proyecto.

La gestión del riesgo es un proceso continuo, no una actividad de una sola vez. Si el equipo de proyecto hace bien su trabajo, los riesgos incrementales que se van identificando a través de la vida del proyecto pueden ser menores. Por lo tanto, no significa que los riesgos dejan de ocurrir luego de las revisiones iniciales. A medida que el proyecto progresa, el proyecto necesita mirar continuamente los nuevos riesgos y el cómo mitigarlos efectivamente.

6. Los riesgos solo son gestionados cuando ocurren

La idea de la gestión de riesgos es manejar los problemas antes de que sucedan. Una vez que un riesgo ocurre ya deja de ser un riesgo para convertirse en un problema. La clave es evitar que pase, y esto solo es posible mitigándolo. Si no hay forma de evitar el riesgo, hay que manejarlo con un plan de contingencia.

7. La gestión del riesgo no genera valor.

Este problema tiene su origen en la percepción de que los beneficios por evitar los riesgos rara vez son cuantificados, sin embargo, el evitar los problemas significa ahorro de costes. De ser posible es ideal asignar un costo a estos riesgos en caso de que ocurran, quizás apoyándonos en casos de proyectos anteriores. Incluso sin cuantificar el costo, evitar el problema y la eliminación de este vale su peso en oro. Incluso si no se  puede evitar completamente el riesgo, planificar de antemano cómo responder cuando ocurra asegurara una ejecución más exitosa  y menos estresante del proyecto.

8. Si no puedo hacerle frente a un riesgo, entonces es mejor no identificarlo.

La realidad es que, una vez identificados los riesgos, los equipos tendrán que luchar a través de identificación de la opción de mitigación y contingencia que mejor se ocupa de ese riesgo. Todo dependerá del conocimiento del equipo, la experiencia, aquí es donde el equipo debe esforzarse. Puede que no sea fácil conseguir las opciones pero identificar el riesgo es la base.

9. Todos los riesgos deben ser mitigados.

Esto no es cierto, hay riesgos contra los que no se puede hacer nada para evitarlos, lo que se puede definir es un plan de qué hacer si ocurre. Como un terremoto, no se puede evitar pero se puede hacer un plan de qué hacer en caso de que ocurra.

10. Los proyectos pequeños no necesitan gestionar el riesgo.

Todos los proyectos necesitan gestionar sus riegos, por muy pequeño que sea, ya que estos afectan la consecución de los objetivos y dificultan cubrir el alcance en el tiempo y coste previsto.

 

Autores: Rodrigo Lugo, Mariela Trujillo, Yamilet Vieria, Maria González, Luis Moreno.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Read More →

stakeholders_LaSalleBCN_OCT13

La correcta identificación de los interesados es determinante para la consecución de los objetivos del proyecto. Una de las novedades más importantes que se han incluido en la versión 5 del PMBoK®, ha sido la inclusión de los stakeholders o interesados como otra área de conocimiento. Este reconocimiento nos da idea de cómo de importante es la buena gestión de todos los implicados, directa e indirectamente, en cualquier proyecto.

Una correcta identificación y clasificación, nos va a permitir poder gestionar los intereses y expectativas de los diferentes interesados en el inicio y durante el proyecto, evitando futuros malentendidos o contratiempos que puedan comprometer el desarrollo y la consecución de los objetivos fijados. Nos va permitir desarrollar los diferentes planes; por ejemplo de comunicación, en los que de forma sistemática y específica para cada grupo de interesados se va a llevar a cabo dicha comunicación. Pues todos no tienen que mostrar interés por el mismo tipo de información o actividad con respecto al proyecto, o no tienen por qué estar al mismo nivel de  conocimiento técnico para poder entender las diferentes implicaciones del proyecto. En definitiva, nos permite tratar de forma más personalizada y especifica las diferentes necesidades de cada grupo de interesados, para que todos puedan mostrar el grado de aceptación o implicación oportuno.

Así  pues, esta identificación y clasificación es una tarea lo suficientemente importante como para tenerla en cuenta durante la definición o iniciación del proyecto, identificando a los interesados de alto nivel. Y durante la planificación, elaborando el plan de gestión de los interesados, donde incluso podemos ampliar esta identificación y clasificación.

Sin embargo, en esta 5ª versión del PMBoK®, aún no se han definido de forma clara cuáles deberían ser los criterios y las herramientas para establecer de forma apropiada esta identificación. Una idea podría ser la utilización de las herramientas de identificación de riesgos, como las Prompt List o la revisión de la documentación. Pero seguramente hay otros criterios o herramientas que se podrían utilizar para realizar esta identificación. ¿Cuáles utilizáis vosotros o creéis que se podrían utilizar?

Post realizado por los alumnos del MPM: Mónica Delgado, Susanna Estany, David López, Irene Riñones, Francesc Teixidó y  Manel Teixidó.

 

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Read More →

El PMBOK®, el estándar de la dirección de proyectos del Project Management Institute, vuelve a renovarse y según las previsiones del PMI a principios del año que viene se publicará la que es ya su quinta versión. El 17 de febrero se publicó una versión en borrador y hasta el 20 de marzo entre los socios del PMI se levantaron más de 10.000 comentarios. El gran número de comentarios seguramente son la causa de que se haya retrasado la fecha inicial de publicación que estaba prevista inicialmente para diciembre de este año.

Los cambios más significativos que hay entre las dos versiones son los siguientes:

  • Alineación con la nueva norma internacional de gestión de proyectosISO21500, era uno de los objetivos de la nueva versión.
  • Se han añadido cuatro nuevos planes subsidiarios de gestión para mejorar la consistencia y ayudar a la claridad del conjunto del Plan para la Dirección del Proyecto. Son el Plan de Gestión del Alcance, el Plan de Gestión del Cronograma, el Plan de Gestión del Costo y el Plan de Gestión de los Interesados.
  • El área de conocimiento de la gestión de la Comunicación se ha divido en dos, creando una nueva, la de laGestión de los Interesados. Los procesos de identificación y gestión de los interesados se han incorporado a la nueva área, así como se han creado dos nuevos: el Plan de la Gestión de los Interesados y el Control del Compromiso de los Interesados.
  • El incremento del número de procesos, de los 42 actuales a 47. El incremento de los procesos están en los dos nuevos de la nueva área de conocimiento de gestión de los interesados, más los tres nuevos de los planes subsidiarios.
  • Se ha mejorado y clarificado el flujo de la información del proyecto con la alineación con el modelo DIKW (data, information, knowledge, wisdom), marcando claramente las diferencias entre: work performance data, work performance information y work performance reports.
  • La creación de la sección 2 de la versión cuarta “La norma para la Dirección de proyectos para un proyecto” como un cuerpo de conocimiento independiente, como anexo del PMBOK. Con la intención que se pueda revisar de forma separada  del PMBOK. Se mantiene el Capítulo 3 como nexo entre los capítulos anteriores y las áreas de conocimiento.

Vistos los cambios, la verdad es que me ha decepcionado esta nueva versión. Con la abertura del PMI a las nuevas metodologías ágiles esperaba que esta nueva versión fuera una oportunidad para tomar un enfoque más interactivo, y no ha sido así. Han pasado ya cinco años des de que salió la versión cuarta y parece difícil creer que en todo este tiempo sólo haya sido necesario realizar cambios menores en el PMBOK. Está la gran ventaja que la nueva versión se ha alineado con la nueva norma internacional de gestión de proyectos ISO21500, o puede que haya sido al revés. Y por supuesto que aplaudo que finalmente se haya dado un paso adelante en dar la importancia que se merece a la gestión de las expectativas de los interesados. Pero no, no me acaban de convencer los cambios menores aplicados.

Para todos aquellos que estáis estudiando para la Certificación PMP no debéis preocuparos por la nueva versión, los cambios son mínimos y además se prevé que no se aplique en la certificación hasta julio del 2013.

Y para todos aquellos que queréis profundizar más en el tema, en el siguiente artículo del PMI podréis encontrar una descripción completa de los cambios entre la versión cuarta y la quinta:

http://www.pmi.org/~/media/PDF/Standards/Appendix_X1_ED_Final_Draft_baseline-3_EDver_021412_clean.ashx

¡Mientras esperaremos el regalo de Reyes del año que viene!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Read More →

Hace días un alumno del máster universitario de dirección de proyecto me hizo una consulta profesional. Le habían asignado como Project Manager en un proyecto completamente distinto a todos los que había hecho hasta el momento, gestionar el traslado del centro tecnológico donde trabaja a un nuevo edificio, y la verdad es que no sabía cómo gestionarlo pues no se parecía en nada a lo que había hecho anteriormente.

Lo estuvimos hablando un buen rato y llegamos a la conclusión que lo más práctico para un proyecto de esas características, con un coste no superior a 200.000€, unos cuatro meses de implementación y con el alcance muy bien definido, sería llevar el control y seguimiento del proyecto principalmente en base a la EDT (estructura de desglose del trabajo). Consideramos que no era necesario bajar a un nivel de tareas y realizar un cronograma detallado.

Definimos como factores de éxito del proyecto:

  • Involucrar a todo el equipo en la definición de la EDT.
  • Definición de los paquetes de trabajo de forma que la responsabilidad estuviera claramente asignada en una sola persona.
  • Control y seguimiento del alcance, coste y tiempo en base a la EDT. Definir cada paquete de trabajo de forma exhaustiva: coste, duración, fecha límite de entrega,  entregables, criterios de aceptación, porcentaje de realización . . .
  • Realizar un cronograma de tareas sólo en los paquetes de mayor complejidad, como por ejemplo el traslado de maquinaria.

Solamente le vimos un gran inconveniente, cómo podríamos presentar la planificación del proyecto sin no teníamos un diagrama de Gantt. Para muchos profesionales del sector el cronograma del proyecto sigue siendo un equivalente a la planificación del proyecto. Como dirían los compañeros de las metodologías Ágiles, el tener un diagrama Gantt que sitúe temporalmente el proyecto es casi como una obsesión para los de las metodologías tradicionales. Esta restricción nos obligaba a encontrar una herramienta que nos permitiera no sólo llevar el control del proyecto con la EDT, sino que además nos permitiera trasladarla fácilmente a un diagrama Gantt.

Y justamente ayer me la encontré, MindView. Inicialmente era simplemente una herramienta de generación de mapas mentales que con el tiempo se le han ido añadiendo otras funcionalidades, siendo la de “WBS Software” la que nos interesa. Con la funcionalidad WBS Software no sólo se puede crear una EDT asignando recursos, tiempos, costes, dependencias . . . sino que además se puede representar en un formato Gantt, importar a Excel, a Word . . . me pareció simplemente genial. Y además todo en un entorno de trabajo colaborativo en el cual se pueden compartir archivos, enviar correos al asignar tareas, gestionar los recursos . . .  Fue como si alguien me hubiera leído el pensamiento y hubiera creado justo la herramienta en la que llevo días pensando.

Para este proyecto no vamos a superar la restricción del diagrama Gantt, pero esperamos poder adaptar la planificación a la simpleza del proyecto con el soporte de esta herramienta y que la base sea la EDT y no el cronograma.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Read More →

Hace poco que he terminado el postgrado de Metodologías Ágiles y ahora que vuelvo a disponer de tiempo libre me he animado a presentaros algunos de los elementos de unión entre el Lean Manufacturing (sistema de producción de Toyota) y el Project Management.

En el post de hoy os quiero presentar una herramienta que vimos con Xavi Quesada y que utilizamos para mejorar la cafetería de La Salle, el A3 Thinking. No os podéis imaginar el revuelo que organizamos ese sábado por la mañana, nos implicamos tanto en el ejercicio que parecíamos más colegiales de excursión que no estudiantes de un postgrado realizando una práctica.

El A3 Thinking es una herramienta de resolución de problemas que se utiliza en las Metodologías Agiles y que se puede aplicar en cualquier contexto. La herramienta proviene de Toyota donde se llama “A3 Problem-Solving Report” y es una las piezas claves en el enfoque de la gestión de la mejora continua. Es una potente herramienta que provee de una estructura concreta para implementar la gestión del ciclo PDCA (Plan-Do-Check-Act).

El cambio de nombre a A3 Thinking se debe a que la importancia de la herramienta radica más en la mentalidad que se requiere para implementarla que no en el informe en sí. Una de sus grandes ventajas es que es válida para la resolución de problemas en cualquier tipo de entorno, aunque su uso no es el más indicado para problemas de fácil solución.

De hecho el A3 Thinking no es más que una simple hoja de tamaño A3  en la cual se refleja el ciclo completo de PDCA. En la parte izquierda de la hoja se coloca el PLAN y en la parte derecha el DO-CHECK-ACT. En el PLAN se estructura la situación actual con un análisis de las causas de los problemas actuales y se recomiendan dos herramientas: el “Value Stream Mapping”  para reflejar la situación actual y el “Diagrama Causa-Efecto” para analizar las causas raíz de los problemas. En el DO-CHECK-ACT se reflejan las contramedidas adoptadas en base al análisis previo, su seguimiento, así como las medidas que vamos a tomar para incorporar las mejoras en el sistema. Para reflejar la nueva situación se puede volver a utilizar el “Value Stream Mapping”.

Los pasos a seguir para aplicar la herramienta son los siguientes:

  1. Identificar el problema o necesidad
  2. Entender la situación actual
  3. Análisis de la causa raíz
  4. Contramedidas
  5. Desarrollar la mejora objetiva
  6. Contemplar la implementación de la mejora de forma global

Aunque la herramienta en sí es muy simple su correcto uso depende de que tengamos realmente una mentalidad de mejora continua, así como un buen conocimiento de las herramientas adicionales de análisis comentadas.  Y como en la mayoría de las herramientas desarrolladas por Toyota esta también se utiliza para el desarrollo personal. En la multinacional japonesa en la que había trabajado era la herramienta de base para las presentaciones de los Círculos de Calidad.

Durward K Sobek II y Art Smalley en su libro “Understanding A3 Thinking: A Critical Component of Toyota’s PDCA Management System” definieron que hay siete elementos detrás de la mentalidad de la herramienta:

  1. Proceso de pensamiento lógico basado en la disciplina PDCA y orientado a la causa raíz.
  2. Objetividad
  3. Conseguir resultados utilizando procesos excelentes
  4. Síntesis, destilación y visualización
  5. Alineación con todos los interesados
  6. Coherencia dentro y consistencia a través de la organización
  7. Una visión global de la contramedida

Todos ellos en base al ciclo PDCA, la mejora continua, enfocado en la resolución de problemas. Si queréis ampliar los conocimientos sobre esta herramienta os recomiendo la lectura del libro mencionado anteriormente. También podéis encontrar una presentación de Claudio  Perrone muy didáctica , así como multitud de referencias en el blog A3 Thinking .

Ya os aviso que no ha habido cambios en la cafetería de La Salle, pero que nada será igual en vuestro entorno si empezáis a utilizar el A3 Thinking.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Read More →