jueves, 24 de noviembre de 2011

7 principios para ganar aliados

Recuerde: un interesado es todo aquel que verá afectados sus intereses positiva o negativamente por la ejecución o conclusión del proyecto. Por lo tanto es fundamental construir confianza y mantener excelente relaciones con él. Es inevitable entender que la comunicación asertiva, bidireccional y participativa es fundamental para el éxito en este empeño. Siga estos 7 principios y podrá hacer que los interesados sean sus aliados:

  1. TIÑA SU SANGRE DE ROJO: ser Director de proyectos no quiere decir ser sordo ni ser Rey. La sangre azul del monarca mal le hace al buen Director de proyectos, que si bien es directivo y jefe, debe tener la humildad suficiente para saber asesorarse, saber escuchar y no siempre tener la última palabra. El Director de proyectos busca las mejores alternativas, acude a los expertos -¿se ha preguntado alguna vez quiénes son los expertos? No se sorprenda: son los que todos los días hacen las mismas cosas, el obrero, el pintor, el técnico...-, los escucha con cuidado y toma decisiones. ¡Sea humilde!, pues humildad no riñe con firmeza.
  2. DOS OÍDOS, UNA BOCA: antes de darse un baño de ego insistiendo en que los demás lo atiendan y lo entiendan, tómese el tiempo de escuchar a sus interesados. Atiéndalos sin preferencias, converse con ellos, pues esta dinámica fortalece los lazos y genera confianza. En vez de querer tener la razón y hacerla valer fundamentado en su posición jerárquica, invierta su tiempo en mantener contacto visual con sus interlocutores y procure investigar sobre sus intereses, expectativas y necesidades. Comprenda que el mundo es subjetivo, por lo que es fundamental que se esfuerce por entender la posición del otro. Escuche primero, hable después. Verá que lo escucharán mejor.
  3. NEGOCIE BIEN: el mejor negocio es aquel en el que ambas partes ganan, así que invierta esfuerzos en construir soluciones que las favorezca a ambas. Esto sólo lo puede lograr con empatía, poniéndose en los zapatos del otro. Sea "prismático", tome forma de prisma, descomponga lo que el otro le ofrece y no tome decisiones basado en su relación con el otro; procure entenderlo en su complejidad. En la medida en la que las soluciones sean construidas en equipo, logrando acuerdos, verá muchos mejores resultados, y lo que es mejor, un mayor compromiso de todos.
  4. SONRÍA Y DESCOMPLÍQUESE: el estereotipo del Director de ceño fruncido, traje almidonado y seriedad eterna está mandado a recoger; sea amable, sonría, mantenga una actitud positiva, aún en los momentos más difíciles, dele rienda suelta al humor, sea más humanitario, menos acartonado. Habrán momentos en los que el humor y la buena actitud serán necesarios para encontrar aliados, distensionar relaciones y romper barreras, que de existir se pueden convertir en un riesgo importante para su proyecto.
  5. DIGA SIEMPRE LA VERDAD: siéntase con la confianza y autoridad necesarias para hablar con franqueza sobre los problemas que se presenten y no dude en solicitar ayuda cuando la necesite. Obtendrá respeto de los interesados si ellos saben a qué atenerse. Nunca baje la guardia aceptando solicitudes poco realistas por el afán de ganarse la simpatía de sus interesados. Aprenda a decir "NO". Decir siempre que todo está bien, no ayuda a nadie.
  6. COHERENCIA, SIEMPRE COHERENCIA: sea disciplinado y dé el ejemplo como Director del proyecto. Manténgase alerta y tenga siempre la información a la mano. Si no quiere perder el respeto de los interesados, sea una persona efectiva y tome acciones sobre los riesgos, los problemas y las decisiones en el proyecto, incluso las de sus interesados. Sea pulcro en las comunicaciones, tanto en la forma como en el fondo!!!
  7. TEMERARIO PERO CUIDADOSO: la excesiva cautela y la demora en la toma de decisiones, juegan en contra de la confianza que los interesados pueden depositar en usted. Sea directivo y tome decisiones cuando se requieran. Siempre será un buen negocio ser proactivo al resolver riesgos y problemas con creatividad. Alimente su autoconfianza. Tenga claro que es aunque es posible que no tenga el control sobre las causas que afectan al proyecto, sí debe el control sobre cómo responde ante las diferentes circunstancias.

martes, 8 de noviembre de 2011

Un Diccionario que no es Glosario



Existirán Gerentes de proyectos que difieran de mi opinión y crean que es otro, pero para mí, el componente de gerencia de proyectos más útil es el Diccionario de la WBS (Work Breakdown Structure o Estructura de Desgloce del Trabajo). Claro, No hay nada más complejo, más completo y más "denso" que definir el Diccionario y nada más divertido que el resto: hacer la WBS y "jugar" con el programa que la construye; desarrollar el cronograma en cualquiera de los múltiples programas que se encuentran para ello; estimar costos y después hacer análisis de Valor Ganado... Pero hacer el Diccionario, escribir y escribir y escribir al detalle todo el trabajo concerniente a los paquetes de trabajo es, en mi opinión, un verdadero reto a la tenacidad, la disciplina y la concentración. Sin embargo, este esfuerzo será recompensado más adelante, con toda seguridad.


¿QUÉ ES EL DICCIONARIO DE LA WBS?
Es la evidencia de que somos conscientes de la complejidad del proyecto y de todas las relaciones que lo componen; es el alma del proyecto; es la solución a todas las inquietudes que puedan existir sobre LO-QUE-HAY-QUE-HACER.
El Diccionario de la WBS forma parte de la línea base del Alcance, compuesta además por el Enunciado Detallado del Alcance y la misma WBS; se centra en los paquetes de trabajo, aquellos componentes del proyecto, ubicados en los últimos niveles de la WBS y que pueden ser programables y medibles. Piense en la importancia de tener claridad de todos y cada uno de los entregables que componen el proyecto. ¿No sería una buena idea definirlos, identificar sus riesgos, estimar sus recursos... es decir, planearlos correctamente? 
El Diccionario es un documento de planeación que nos ayuda en la detallada planeación del alcance y, en términos generales, debería tener:

  1. Objetivo del paquete de trabajo: describa para qué se elabora este Paquete de trabajo.
  2. Descripción del paquete de trabajo: defina en qué consiste, cómo es, cuáles son sus dimensiones, etc.
  3. Descripción del trabajo a realizar: identique cuáles son las actividades que se necesitan llevar a cabo para completar el paquete de trabajo.
  4. Asignación de responsabilidades: establezca quiénes intervienen y qué rol desempeñan en la elaboración; quiénes responden, apoyan, participan, revisan, aprueban y/o dan información.
  5. Fechas programadas: sí, ya sé que aún no tenemos cronograma, pero sería importante escribir las fechas esperadas para la construcción del paquete de trabajo, sobre todo si existe algún tipo de restricción.
  6. Criterios de aceptación: defina quién y cómo se dará por válido el paquete de trabajo.
  7. Supuestos: identifique aquellas situaciones reales que se entienden como verdaderas, y que en caso de no serlo afectarán la planeación del paquete de trabajo.
  8. Riesgos: defina los eventos que en caso de ocurrir afectarán positiva o negativamente alguno de los objetivos del paquete de trabajo.
  9. Recursos asignados: relacione los recursos que son necesarios para elaborar el paquete de trabajo (humanos, materiales, equipos, máquinas...)
  10. Dependencias: defina qué debe tener listo antes de elaborar el PDT y qué se debe hacer después.

martes, 1 de noviembre de 2011

5 pasos para planear el Plan de sus proyectos

En esta ocasión me he tomado el atrevimiento de traducir un pequeño artículo, publicado por el PMI (Project Management Institute) el 1 de noviembre de 2011 en la siguiente dirección: http://ow.ly/7fry3.
Es corto y muy interesante.


5 PASOS PARA PLANEAR EL PLAN DE SUS PROYECTOS
By Marian Haus, PMP

Hay un dicho: “cada minuto que invierte en planear, le ahorrará diez minutos en ejecución”. Como gerente de proyectos, he aprendido así como la comunicación y la ejecución la planeación es uno de los tres ingredientes clave para el éxito de los proyectos.

Planear no es una sólo una actividad única que se completa en las etapas tempranas de un proyecto. Planear es un proceso (o si se quiere, un grupo de procesos), conducido a través de todo el proyecto. Y al igual que todo proceso, planear requiere en sí mismo de una plan y de una configuración, con la que se define el alcance de la planeación, los detalles y los entregables.

Entonces, ¿Cómo planeamos la planeación? Aquí están mi propuesta de cinco pasos:

1.     Decida la metodología, el maro o la práctica que usará en el proyecto. Dependiendo de este enfoque, puede requerir de diferentes estilos de planeación, entregables, detalles o rigor,
Es posible que tenga que seguir adelante con un proceso detallado de planeación si usa un enfoque en cascada. Por el contrario, es posible que tenga que mantener una planificación fina si usa un enfoque ágil, como Scrum. O, su planeación puede ser predefinida y enmarcada si tiene que usar una metodología propia de su organización.
2.     Planifique el tiempo para planear.  En promedio, al menos diez por ciento del tiempo de la gerencia debe ser dedicado al proceso de planear.
3.     Escriba una lista de cheque de todos los documentos del proyecto que planeará o que necesita entregar. La lista dependerá, sobre todo, en la complejidad de su proyecto, organización y metodología.
4.     Comience a planear temprano y continúe con la planeación durante todo el proyecto. Algunos de los documentos de planeación, como el cronograma de alto nivel o los documentos de alcance, puede que se necesite que se mantengan congelados mientras se firman. Otros documentos, como el plan de riesgos o el despliegue de la planificación, necesitarán de actualizaciones a medida que progresa el proyecto.
5.     Continuamente mejore su planificación. Mejore su planeación comunicando el resultado de la misma con su equipo del proyecto y recogiendo su retroalimentación sobre el rendimiento de su planeación. Usted puede usar esta retroalimentación para mantener un continuo mejoramiento en el plan.
A medida que el proyecto progresa, mantenga un registro de los problemas de su plan para hacer seguimiento a las brechas que encuentra en el camino. Estas son las “lecciones aprendidas de planeación”, un documento que puede usar para mejoramiento continuo.

¿Qué opina? ¿Cómo planifica el plan de su proyecto?

jueves, 2 de junio de 2011

La gestión de los interesados II

Seguimos con la Gestión de los interesados. Una vez tienes la lista de interesados, lo mejor es clasificarlos. Apóyate en un cuadro de Poder/ Influencia y Apoyo, como el que ves a continuación:
 
ALTO PODER / ALTO APOYO: Gente que tiene alto poder y apoyan el proyecto son tus más cercanos aliados. Ellos miran las ideas y propósitos del proyecto desde una perspectiva positiva y tienen el poder de influir en los demás. Como estarán encantados de trabajar en pos de resolver los problemas y sacar adelante el proyecto, comunícale a este grupo las nuevas ideas antes que a otras personas, de tal manera que te ayuden mejorándolas y promoviéndolas a los demás. Este será el grupo con el que correras menos riesgos.
ALTO PODER / BAJO APOYO: Las personas con alto poder, pero que no apoyan el proyecto o tu trabajo, serán tu prioridad de riesgos. Tendrán la alta posibilidad de destruir tu proyecto si no las gestionas correctamente. Sé concreto y pragmático al comunicarte con ellos y esfuércese en construir buenas relaciones honestas. Escúchelos y procure entender sus puntos de vista. No tome nada personal!!! Hable con ellos frecuentemente y no sea prevenido ante sus comentarios. Evidentemente, una persona que se opone al proyecto por una cuestión de principios, será una persona que no querrás tener en el comité directivo.

BAJO PODER / ALTO APOYO: Manténlas informadas del proyecto, pues estas personas serán muy importantes para resolver los detalles del proyecto. Intégralas al proyecto y apóyalas en la construcción de ideas para resolver conflictos o problemas, pero ten cuidado de no gastar horas y horas en reuniones con ellos. Si estás corto de tiempo, sé pragmático y  utiliza el tiempo eficientemente: el tiempo de reuniones lo debes invertir en las personas con Poder y apoyo.

BAJO PODER / BAJO APOYO: Personas que no apoyan el proyecto y no tienen poder, pueden convertirse en una verdadera molestia. Infórmalas lo necesario y reúnete con ellas para escuchar sus puntos de vista, y muy importante: CONTROLA EL CHISME!!! Para alinear este grupo en el proyecto, enfócate en ganar el apoyo de los interesados con alto poder.


lunes, 18 de abril de 2011

La gestión de los interesados - PARTE 1

¿Qué es un interesado? es un individuo o grupo de personas que tiene interés en su proyecto y que será afectado positiva o negativamente por el mismo. En realidad, el "interesado" no es sólo aquel que tiene interés en que el proyecto salga adelante, sino que también comprende a todas esas personas o grupos de personas a quienes no les conviene el proyecto, pues se verán afectados negativamente por el mismo.


Tal vez, en la vida normal, en aquella alejada de los conocimientos de Gerencia de Proyectos, quienes toman las riendas de los proyectos, olvidan identificar a aquellas personas que más adelante, eventualmente, traerán problemas, inventarán obstáculos, pondrán "zancadillas" y harán lo posible porque el proyecto no llegue a feliz término. Si usted forma parte del selecto grupo de personas que lideran proyectos y que son conscientes de la importancia de identificarlos, acuérdese de buscarlos también al interior de la Organización. ¿Había pensado en ello? ¿Creyó que los que pondrían problemas serían todos aquellos que no trabajan para el proyecto? NO! no es cierto. Dentro de la Organización ejecutante es posible que se encuentre con muchas sorpresas, como por ejemplo: Un Vicepresidente que no cree en el Retorno de la Inversión del Proyecto; una secretaria que siente que tendrá mucho más trabajo y mucho menos tiempo; Un gerente a quien le fue "robada" la idea del proyecto, etc, etc, etc.


Es así que, si quiere que su proyecto avance y finalice exitosamente, necesita del apoyo de la mayor cantidad de interesados (Stakeholders) posible. Vigile entonces la relación que usted mantiene con el patrocinador y con los usuarios; involucre a los usuarios en su proyecto para que sean ellos quienes le den información sobre especificaciones de requerimientos, descripciones de uso, criterios de aceptación, etc. Si no los involucra, posiblemente poco les importará el producto final.


¿Y cómo identificarlos?
Sencillo: Haga una lista de los interesados en su proyecto. Sí, una lista intuitiva, basada en sus conocimientos y experiencias, basado por supuesto en las siguientes preguntas:

  • ¿Quiénes están a cargo del proyecto?
  • ¿Quiénes comprometen su nombre, su dinero, su estatus, etc. por el proyecto?
  • ¿Quiénes están o estaban pensando en temas parecidos a los del proyecto, dentro o fuera de la organización?
  • ¿A quiénes no les conviene el proyecto? ¿a quiénes les favorece?
  • ¿Quiénes serán los usuarios?
Esta lista la puede complementar con todas las preguntas que considere pertinentes.
Asegúrese de identificar, si es necesario con nombres propios, a todos y a cada una de las personas que resultarán afectadas positiva o negativamente por el proyecto, no sólo por sus resultados, sino por todo lo que ocurra en el ciclo de vida del mismo.

En el siguiente post, compartiré la segunda parte de la Gestión de Interesados.

jueves, 14 de abril de 2011

Monumento al PM desconocido

Hace poco vino un colega para pedirme consejo con respecto a un proyecto al que acababa de ser asignado. Al parecer el proyecto no era nuevo, era un proyecto que ya había fracasado y ésta era la “segunda vuelta” que iban a dar, pero con algunos cambios, entre ellos, el contratar a un Administrador de Proyectos profesional a quien pedirían cuentas sobre los resultados del proyecto.
En cuanto llegó le pedí que me explicara cómo les había ido en el primer intento y, de acuerdo a lo que le habían comentado, el me relató lo siguiente:
Entorno del proyecto
Se trata de una escuela que quiere ampliar sus servicios educativos para que los alumnos de preparatoria tengan otros medios de ponerse al corriente con clases que no tomaron o que quisieran repasar. El director y el consejo escolar planearon tener un sistema computacional que les permitiera tomar las clases sin necesidad de un instructor.
Debo mencionar que me interesó mucho el caso porque tocaba tres de mis puntos fuertes: Sistemas Computacionales, Project Management y la industria del aprendizaje asistido por computadora (e-Learning).
De manera que le pedí que me comentara cuales habían sido las acciones que el equipo de proyecto había emprendido antes de llamarlo a él para apoyarles, y el continuó diciendo:
Creación del equipo de proyecto
El director de la escuela armó un equipo para abordar el proyecto. Viendo la necesidad de crear material didáctico eligió a cuatro profesores y un líder de proyecto.
Definición de alcance del proyecto, roles y tiempos
El equipo se concentró originalmente en definir el alcance del proyecto y aclarar todas las dudas que tuvieran con respecto a lo que se haría. Después invitaron al director para que estableciera las prioridades de las actividades, así como para solicitar su apoyo y para motivar a los participantes de este esfuerzo ya que todos los miembros del equipo continuarían con sus actividades normales y, además, estarían desarrollando los entregables del proyecto.
Los integrantes del equipo definieron horarios en los que trabajarían en este esfuerzo y definieron el número de cursos a desarrollar, que se estableció en 18 cursos.
En las primeras reuniones también se detectó que ninguno de los participantes tenía experiencia previa en el modelo de aprendizaje automatizado, si bien eran expertos en la enseñanza y preparación de material, nunca habían participado en un proyecto en el que tuvieran que implementar el marco tecnológico necesario, por lo que decidieron contratar a una empresa que les apoyara con esta parte de los entregables.
Finalmente, el equipo de proyecto definió la fecha de entrega de los cursos para tener un marco de referencia del fin del proyecto.
Inicio del proyecto
El proyecto arrancó con la asignación de algunos maestros adicionales para que apoyaran con la elaboración de los cursos. Los consultores definieron los formatos en los cuales los maestros pondrían la información de acuerdo a su experiencia docente. Adicionalmente los consultores capacitaron a los profesores en el uso de la plataforma tecnológica a emplear para el proyecto.
Desarrollo del proyecto
Los profesores empezaron a desarrollar los cursos por separado y cuando terminaban se los enviaban al equipo del proyecto para que estos los revisaran y aprobaran. Los consultores continuaron apoyando con respuestas a las dudas sobre el uso de la plataforma y cargando archivos en esta.
Durante el tiempo designado los maestros elaboraron los materiales de los cursos hasta terminar. Cuando enviaron los materiales para revisión, el equipo de proyecto notó que aunque todos usaron la misma herramienta para elaborarlos, los cursos no eran uniformes, algunos eran apropiados y apegados a los objetivos del aprendizaje y otros no lo estaban en lo absoluto. Algunos tenían una buena presentación mientras otros no la tenían.
Cambio de rumbo
El líder del proyecto solicitó la presencia del director de la escuela para conocer su opinión y éste determinó que el material creado no cumplía con los objetivos del aprendizaje del alumno y solicitó que le agregaran características de animación y mejores transiciones entre las diapositivas para facilitar el aprendizaje.
Tomando lo anterior como un nuevo rumbo para el proyecto se calcularon las implicaciones y se determinó que la entrega del proyecto se retrasaría, el costo de la consultoría se elevaría y se requeriría que los maestros trabajaran horas extra en el material que ya habían realizado (re-trabajo).
En búsqueda del culpable
Cuando se evaluaron estas implicaciones y se revisaron los cambios presupuestales se intentó encontrar dónde había estado el problema. Los maestros le echaron la culpa a los consultores porque éstos no les estaban dando toda la información acerca de la plataforma que estaban operando. Los consultores le echaron la culpa a que había habido un cambio en el alcance del proyecto. El equipo original del proyecto argumentó que el problema era que no se había ofrecido una compensación monetaria para los maestros por haber trabajado específicamente en ese proyecto. Alguien más argumentó que el problema estaba en el proceso y que era necesario establecer más y mejores puntos de revisión en el mismo.
En ese momento el director autorizó la contratación de un Project Manager externo para hacerse cargo… así es, ese era mi amigo.
¿Te suena familiar este caso?
Desafortunadamente hoy en día todos, y no me da miedo generalizar, todos nos enfrentamos a proyectos de algún tipo, con poca o nada de preparación para enfrentarlos (administrarlos).
Mi amigo es un PM novato y afortunadamente el proyecto que dejaron en sus manos es un proyecto pequeño.  ¿Qué le habrías aconsejado?, ¿por dónde empezar?
Con respeto a tus propias opiniones me permito comentarte lo que yo le sugerí.
Mis preguntas
Antes de recomendar nada, le hice a mi amigo un par de preguntas. La primera de ellas fue: ¿Tienes un Project Charter? La constitución del proyecto o Project Charter es un documento en el que se esboza información importante del proyecto en términos del alcance, tiempos, involucrados, pero sobre todo, se establece claramente  la autoridad que adquiere el Project Manager sobre el equipo del proyecto y lo responsabiliza de tomar las decisiones que favorezcan a que el proyecto se termine dentro de las definiciones de alcance, tiempo, costo y calidad. Este documento, que debe estar firmado por el director de la escuela también sirve para definir el rol del director y otros interesados.
Mi segunda pregunta fue: ¿Tienes un WBS? La estructura de descomposición del trabajo o Work Breakdown Structure (WBS) es un documento que ayuda a descomponer el objetivo final del proyecto en partes más pequeñas y manejables y que puede ser usado no sólo para la planeación del proyecto, sino para el seguimiento, la presentación de avances y la definición de los responsables de cada paquete de trabajo. Con un WBS puedes saber cuánto costará el desarrollo de cada entregable y cuanto se retrasara el proyecto si una tarea se retrasa.
Desde luego que hay muchas otras herramientas que ayudan en la organización de un proyecto, pero para este caso y en general para proyectos pequeños elaborados en organizaciones informales o donde se tiene poco conocimiento del control de proyectos, estas dos herramientas son vitales. Los beneficios que traen, entre otros, son los siguientes:
  • Establece jerarquía dentro del equipo de proyecto
  • Comunica los acuerdos con respecto al alcance del proyecto
  • Define responsables por cada parte del proyecto
  • Identifica la parte emproblemada del proyecto
Adicional a estas dos herramientas yo agregaría un nivel mayor de detalle en las expectativas de calidad de cada curso. Hay tantas formas de hacer las cosas como participante en las actividades del proyecto, así que se requiere un estándar como punto de partida. La verificación de la calidad en los sistemas es muy sencillo, sólo es necesario establecer a un nivel aceptable de detalle cuales son las expectativas del usuario o cliente y verificar que el producto final cumpla con ellas.
Si se cuenta con las herramientas adecuadas de trabajo, seguramente se contará con un sistema que ayude en la elaboración de WBS y que permita agregar especificaciones por cada entregable, de tal manera que no se requeriría otra herramienta, sino solamente una disciplina por agregar la información allí y mantenerla vigente a lo largo del proyecto.
Aún más, debe establecerse un proceso de integración de cambios, esto es, un procedimiento por el cual se detalle cómo vamos a proceder cuando haya un cambio solicitado para alguno o varios de los entregables del proyecto. Comúnmente este proceso luce así:
  1. Un usuario solicita un cambio
  2. El cambio se recibe en un formato específico
  3. El cambio se evalúa y se pronostican los cambios en el enunciado de alcance, duración del proyecto y costo
  4. Se procede a la autorización del cambio.
  5. Si el cambio es autorizado por el equipo ejecutivo del proyecto, se integran los cambios en el WBS, Enunciado de Alcance, Cronograma, Documento de Riesgos, etc.
  6. Si se rechaza, se notifica a los interesados.
Mi amigo estaba muy bien familiarizado tanto con las herramientas como con los procesos a implementar, así que no fue difícil que supiera cuál era el siguiente paso a dar. Sin embargo me hizo una observación: “Cuando dominas las herramientas y técnicas de administración de proyectos es fácil caer en la tentación de establecer todo un complicado proceso de administración de proyectos cuando lo que necesitas es abrir los canales de comunicación, definir los roles y las responsabilidades de la gente y documentar los acuerdos de manera formal”.
¿Cuántas veces hemos sobredimensionado un proyecto sólo para hacer uso del software de administración de proyectos en el que nos acabamos de certificar?, ¿o sólo para implementar la metodología que utiliza aquella súper compañía que ha sido exitosísima a nivel mundial?
La administración de proyectos parte de la necesidad de hacer que el proyecto sea exitoso y es un medio para lograrlo, no el fin último de un proyecto. Si en el futuro te encuentras con un reto de este tipo o más complicado, te invito a contestar las siguientes preguntas: ¿Cuál es el objetivo final del proyecto?, ¿Qué puedo hacer para ayudar a conseguir el objetivo del proyecto?, ¿Cómo puedo usar mis habilidades y técnicas en administración de proyectos para conseguir el resultado esperado?
¿Qué recomendaciones le darías a mi amigo para la etapa de ejecución, control y cierre de su proyecto?
Texto tomado de: http://www.liderdeproyecto.com

miércoles, 2 de marzo de 2011

Los retos de la Gestión de Riesgos en Proyectos



Un gran amigo y ex-compañero de universidad, el Ingeniero Mauricio Páez, me compartió este texto y me dio el permiso de hacerlo llegar a todos ustedes. Espero que lo disfruten como yo.


Cuando hice mis estudios en gerencia de proyectos hicimos un ejercicio extraño. Fuimos divididos en grupos, y debimos identificar los riesgos asociados a un proyecto hipotético. Al socializar los riesgos que habíamos contemplado, el profesor nos refutó todos, diciendo que esos no eran riesgos, que todo eso ya era controlado por las otras áreas del conocimiento, por lo que no debía ser expresado como un riesgo.


Ante semejante resultado todos los estudiantes nos decepcionamos, pero finalmente el profesor nos dijo que esos si eran riesgos, que la lección era que se debía profundizar más en análisis de los riesgos de los proyectos. Años después entendí lo importante de esa lección cuando tuve que administrar los riesgos de varios proyectos y ahora veo que los principales retos que tiene la Gerencia de los Proyectos en Colombia en relación a la GR son:


Hacer que la GR se vuelva parte de la cultura de las organizaciones
Hace 30 años, la gran mayoría de las organizaciones no tenía Sistemas de Gestión de Calidad, los términos ‘mejoramiento continuo’, ‘mapa de procesos’, ‘aseguramiento de la calidad’, ‘calidad total’, ‘ISO 9.000’ no se escuchaban, a nadie se le pedía saber sobre el tema, pero ahora, en los procesos de selección de personal se les pide, no sólo haberlos escuchado sino conocerlos y mejor aún, dominarlos. Más o menos, la GR se encuentra en ese punto, hay que gente que habla de, que ha escuchado hablar de, que tiene idea de qué se trata, pero todavía son pocos y son pocas las organizaciones que han incorporado esta gestión a sus procesos.


Hacer de la GR la mano derecha de la gerencia
Cuando digo gerencia no me refiero únicamente al Gerente del Proyecto, sino también a la gerencia de las organizaciones que, o desarrollan los proyectos o se ven beneficiadas por los mismos. La GR es vista como una tarea adicional, ‘otro formato más para llenar’. Si se logra mostrarle a la gerencia todos los beneficios que le trae hacer una buena GR, esta dejaría de ser una tarea más y se volvería una actividad muy importante. Después de lograr este reto, lo siguiente es hacer que la gerencia tome decisiones basada en la GR. Este reto se logra si la gerencia participa activamente de todos los procesos asociados a la GR.


Hacer bien la GR
Si hemos logrado que la GR sea parte de la cultura de la organización y que la gerencia la vea como su mano derecha y como una herramienta para la toma de decisiones, se hace imperativo que la GR se haga bien, es decir, que se realice todo el ciclo, que se incluyan todos los análisis, todas las áreas y todos los procesos, así mismo, que haya responsables de cada una de las etapas.


Hacer un Sistema de GR
Las organizaciones han ido evolucionando y han encontrado que los sistemas de gestión (calidad, medio ambiente, seguridad) son mecanismos que permiten hacer más eficientes los procesos y la inclusión de un sistema de gestión de riesgos a los demás sistemas es un reto muy interesante, pues esta gestión no puede ser un sistema anexo sino integrado a todos los demás. Dentro de la formulación de este Sistema se debe establecer la profundidad a la que se debe llegar, para evitar que el resultado no sea tan superficial que no permita la toma de decisiones ni tan profundo que sea demasiado extenso el desarrollo del análisis.


Mauricio Páez


Ingeniero Industrial de la Universidad Distrital “Francisco José de Caldas”, especialista en Gerencia de Proyectos. Consultor del sector hidrocarburos en Gestión de Riesgos. Docente universitario. Empresario.