About the author  ⁄ Julian Fernández

Emprendedor y empresario de las letras, escritor por naturaleza y curioso por convicción.

AutopsiaEl presente post ha sido enviado por Javier Coca, profesional con una dilatada experiencia en ONG’s y consultoría para el establecimiento de Joint Ventures entre empresas africanas y occidentales, además de alumno del MPM On-line. Escribe habitualmente sobre tecnología y empresas africanas en Adventure Network.  

Un project manager y un CEO tienen algo en común: los dos llevan un timón en sus manos, y constantemente intentan tomar decisiones correctas para llegar a buen puerto, capeando temporales y tormentas tropicales si es necesario. Ambos tienen un alto nivel de responsabilidad, ambos dirigen equipos formados por personas. Bien es verdad que no comparten en absoluto el nivel de autoridad en la estructura de la empresa, pero de eso no vamos a hablar ahora. Vamos a ver buenas prácticas de buenos CEOs en relación a las lecciones aprendidas.

En su libro Good to Great (2001), Jim Collins analiza de arriba abajo empresas que consiguieron resultados económicos apabullantes de manera sostenida durante al menos 15 años. No lo hace de cualquier modo. Invierte 5 años con la ayuda de 20 investigadores que tabulan y analizan decenas de miles de artículos, conceptualizan gigas de datos, entrevistan exhaustivamente a decenas de implicados… Parte de lo que comprobaron Collins y su equipo fue que en aquellas empresas, una mayoría de CEOs y ejecutivos tenían un hábito que el equipo de investigadores de Collins llamó blameless autopsy: “autopsia sin culpa” o “autopsia inocente”.

¿En qué consistía? Collins identifica que estas personas siempre afrontaron los hechos en bruto, independientemente de la situación. No pretendían tener todas las respuestas. Preguntaban, preguntaban y volvían a preguntar. Dialogaban y debatían, incluso muy acaloradamente, pero no se imponían. Buscaban acuerdos. Analizaban los errores clínicamente, sin culpables ni víctimas.

Esta costumbre parece haber sido crítica a nivel estratégico en algunos casos. En otros, era parte de la filosofía de la empresa. Una de ellas adquirió en 1978 otra entidad, en lo que terminó siendo un enorme fracaso comercial de alto costo para la empresa. Collins cuenta cómo él y su equipo quedaron estupefactos al ver que en las entrevistas, los responsables de la debacle no sólo no evitaban hablar del tema, sino que por iniciativa propia la comentaban abiertamente (el líder de la empresa dedicó 5 páginas enteras de sus memorias a analizar el error, sus implicaciones y las lecciones aprendidas). Aparentemente, se invirtieron cientos de horas de recursos a todos los niveles a analizar el fracaso. Analizaron. Una autopsia sin culpa. Un patrón que Collins y su equipo encontraron repetidamente en equipos que lideraron empresas extraordinarias.

Nosotros no tenemos autoridad para fracasar comprando empresas, pero sí tenemos una responsabilidad hacia la empresa y hacia el equipo, por lo que nos interesa además saber qué dice un project manager al respecto, ¿no? Pues para eso tenemos al agradable Joseph Heagney, que en su libro Fundamentals of Project Management (2011), comenta lo siguiente:

Cuando el trabajo se ha terminado, la fase de cierre requiere que se lleve a cabo una revisión. El propósito es aprender lecciones que podamos sacar para futuras ocasiones. Preguntamos dos cosas: “¿Qué hemos hecho bien?”, y “¿qué queremos mejorar la próxima vez?”.

Nótese que no preguntamos qué hemos hecho mal. Esta pregunta tiende a poner a la gente a la defensiva y le hace esconder cosas por temor a llevarse un castigo. De hecho, una revisión de lecciones aprendidas nunca debería dirigirse en un estilo culpable/castigo. Si lo que quieres es llevar a cabo una inquisición, eso ya es otra cosa. El propósito de una inquisición suele consistir en encontrar a los responsables de grandes desastres y castigarlos.

Las sesiones de lecciones aprendidas deberían ser exactamente lo que sus palabras implican.

¿Qué habilidades son necesarias para desarrollar una correcta sesión de lecciones aprendidas?

Analiza una situación profesional que conozcas donde se buscaron culpables en vez de hacer una autopsia sin culpa. ¿Qué podría haberse hecho mejor?

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

stakeholders_LaSalleBCN_OCT13La 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ó.

Fuente: Think like a project manager

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

riesgosLa 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.

Fuente: Think like a Project Manager.

 

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