Archive for Mayo, 2011

Riesgos vs Problemas

Martes, Mayo 31st, 2011

risk-register.jpgHace ya muchos años fui asignado a un proyecto cuyo objetivo era desarrollar un sistema que integrara algunas pantallas de aplicaciones ya existentes dentro de un solo flujo de pasos, algo parecido a un workflow o wizard (aplicación que tiene diferentes etapas en las que el sistema recibe información y cuyo orden de captura es importante. También puede verse como una serie de pasos para completar una tarea), dado que los sistemas estaban desarrollados en plataformas diferentes pude anticipar que tendríamos algunos riesgos y problemas que resolver en su momento.

Ambiente del proyecto

Yo trabajaba en una compañía de telecomunicaciones que recientemente había comprado una compañía de TV por cable y tanto nuestros sistemas como los de la nueva compañía habían sido creados para plataformas tecnológicas diferentes .

Iniciamos el proyecto con dos desarrolladores y un analista  quien también participaba de las decisiones técnicas del proyecto. Por parte de la empresa cablera habían asignado a su mejor ingeniero, al de mayor experiencia y antigüedad y a dos de los mejores técnicos de sistemas quienes habían desarrollado su plataforma de aprovisionamiento de información.

Riesgos del proyecto

Por ser un proyecto pequeño decidí no formalizar mucho el ejercicio de identificación de riesgos, además, mi clara inclinación por pensar que el riesgo preponderante eran las múltiples plataformas tecnológicas que debíamos integrar nubló mi ejercicio de análisis y búsqueda de otro tipo de riesgos.

A esas alturas mi risk register contenía sólo un registro y el plan de mitigación no tenía pasos concretos a seguir para evitar, transferir o mitigar el riesgo.

Uno de los sistemas, el más importante, no pertenecía a la compañía en la que yo trabajaba, sino a la filial recién adquirida, así que los riesgos aumentaban en ese punto. Los miembros de la compañía de TV no estaban del todo contentos con la transacción de compra-venta y era claro que también estaban nerviosos (las bolsas de trabajo están llenas de curriculums vitae de empleados  descontentos y nerviosos por el futuro de su compañía).

Adicional a todo esto, las fechas que había establecido la dirección comercial eran muy agresivas, ya que el sistema sería utilizado para aprovisionar información de ventas en las diferentes plataformas para lograr tanto el registro de la información del cliente como la configuración del servicio recién vendido.

El problema

Para hacer más corto el relato, a la altura en la que estábamos haciendo las primeras pruebas de integración de las plataformas, el empleado más importante de la compañía de TV fue sacado del proyecto para atender asuntos pendientes urgentes de su compañía y los empleados de apoyo renunciaron.

La compañía cablera asignó dos ingenieros más al proyecto, pero éstos no conocían las plataformas con las que estábamos trabajando, de tal manera que se anticipaba una larga curva de aprendizaje.

El intento por resolver el problema

En ese momento mi issue log se llenó inmediatamente. La lista de problemas que se había registrado era interminable. Era imposible atender tantos problemas de alta prioridad al mismo tiempo con poco apoyo por parte del equipo técnico y con la presión del equipo ejecutivo quien ya estaba lanzando las primeras campañas publicitarias en las que le ponían fecha al lanzamiento del nuevo servicio “Triple Play” (Telefonía, Internet y TV por cable).

Fueron largas noches de trabajo las que invertimos para resolver todos los problemas que se generaron. La compañía de TV regresó al experimentado ingeniero al proyecto y eso favoreció mucho a la pronta resolución de los problemas.

Lecciones Aprendidas

Después de que la adrenalina bajó me puse a pensar, ¿por qué un proyecto que ciertamente presentaba reto se había convertido en un dolor de cabeza tan pronto? Debía haber una manera de prever los problemas que ocurrirían con cierta anticipación y no tan repentinamente.

Analizando encontré algunos defectos en mi manera de administrar el proyecto, principalmente el de no haber hecho un ejercicio adecuado de administración de riesgos.

La administración de riesgos supone la creación de un registro de riesgos, un análisis cualitativo y cuantitativo de los riesgos, una discriminación de aquellos poco probables de ocurrir o con poco impacto y la creación de planes de mitigación, transferencia o aceptación junto con un plan de contingencia para cuando ocurran.

Con lo anterior quiero decir que independientemente del tamaño y naturaleza del proyecto debemos hacer un análisis de los riesgos y registrar estos en un documento. No importa si el riesgo es pequeño o improbable, como líderes del proyecto necesitamos registrarlos.

Una vez establecido este documento al que llamamos risk register, es necesario analizar qué tan probable es que ocurran esos riesgos y, de hacerlo, cuál sería el impacto para el proyecto. Hay muchas técnicas para hacer esto, pero más bien quiero concentrarme en el siguiente paso que fue el que me provocó más problemas.

Hasta este punto un riesgo puede ser mitigado (reducido su probabilidad de ocurrir), evitado o aceptado, es decir, es posible planear maneras para que su impacto sea menor, su probabilidad sea menor o simplemente planear cómo vamos a afrontar los problemas que surgirán en el momento en el que ocurra.

Cuando un riesgo ocurre esto da lugar a problemas (issues) y es aquí donde tenemos que dejar de administrarlos dentro del registro de riesgos y empezar a manejarlos dentro del log de problemas para  resolverlos de acuerdo a los planes definidos de mitigación y respuesta .

El riesgo de perder a los ingenieros de la compañía de TV por cable se hizo realidad y yo ni si quiera lo había considerado en el risk register. Los problemas afloraron y yo no tenía planes de contingencia. Esto dio a lugar esfuerzos desmesurados, largas noches y descontento en el equipo.

Recomendaciones finales

Antes de terminar este post quiero hacer énfasis en un par de cosas. Aunque considero que dejé claro que hay que analizar todos los riesgos probables dentro de nuestro proyecto, esto no quiere decir que debemos planear como si todos fueran a ocurrir.

Debemos ser prácticos y planear sobre aquellos que son más probables de ocurrir y sobre aquellos cuyo impacto sería mayor en el momento de ocurrir. Por ejemplo, yo no me enfocaría en realizar planes de contingencia para un riesgo que tenga 0.05% de probabilidad de ocurrir y/o cuyo impacto nos obligue solamente a reemplazar un foco con valor de 0.50 pesos, pero definitivamente si registraría el riesgo a manera de documentación.

Otra cosa, los riesgos se administran como eventos probables de ocurrir y mientras haya tiempo para planear en acciones que los eviten o disminuyan, hay que hacerlo, es una inversión. Los problemas se administran como eventos que ya ocurrieron y se espera que se resuelvan de acuerdo con el plan de contingencias.

En resumen, en el mundo ideal no debería haber sorpresas en los proyectos. Los líderes de proyectos son contratados para llevar un proyecto a un término exitoso y con el menor número de sorpresas.

Por Fernando Valdez

Problemas en el proyecto

Miércoles, Mayo 4th, 2011

problemas.jpgHace tiempo iniciamos un proyecto con muchos entregables, poco tiempo para completarlo, poca definición y de incalculable valor para el cliente… ¿te suena familiar?

Ésta es la vida real.

Los problemas son lo que hacen que el cliente nos llame. Los problemas son los que hacen girar la rueda del intercambio comercial entre clientes y empresas de productos y servicios. Sin los problemas no tendríamos trabajo.

Muchos de los lectores seguramente son personas versadas en las técnicas de administración de proyectos, unos a nivel introductorio y otros avanzado, pero ambos, a su propio nivel, se encuentran diariamente con una serie de problemas que los hace aplicar las diversas técnicas aprendidas ya sea experimentalmente o formalmente para conseguir una solución favorable.

Mi proyecto no fue la excepción. Desde su propio origen nos encontramos con el problema de balancear las variables tiempo, alcance y calidad.

Pensando en esto, en las técnicas y herramientas que hay para resolver problemas de administración de proyectos, me puedo dar cuenta que hay mucho escrito sobre administración de proyectos. Constantemente recibo correos que me invitan a visitar un sitio, a comprar un template, a adquirir una metodología de administración de proyectos, a inscribirme en un curso que me enseñará “lo que nadie en el mercado está enseñando sobre administración de proyectos”, a asistir a la reunión mensual en la que tratarán “temas de relevancia para los administradores de proyectos en estos agitados tiempos”,… la lista continúa interminablemente.

He revisado decenas de metodologías, asistido a más de cien seminarios web, leído miles de páginas, visitado centenares de sitios web sobre administración de proyectos y descargado innumerables formatos y templates para su uso en mis proyectos. Además hice un diplomado en administración de proyectos que resultó en mi certificación como PMP, sin embargo ninguno de estos esfuerzos, algunos gratuitos y otros muy bien cobrados, me dieron las habilidades para resolver los problemas de mis proyectos.

Y es que no solamente se trata de conocimientos y metodologías, se trata de muchas cosas más. Desde luego que los conocimientos adquiridos trabajan a nuestro favor cuando nos enfrentamos a un miembro del equipo ocioso, o cuando balanceamos cargas de trabajo, o cuando necesitamos apresurar la entrega de un paquete de trabajo, o cuando el cliente pide un cambio. Hay suficientes páginas escritas sobre cómo lidiar con estos y otros problemas, pero siempre el nuestro parece algo diferente a lo que dice en el libro de texto.

He observado que hay tres actividades que podemos llevar a cabo para incrementar nuestras habilidades en la resolución de problemas y son las siguientes:

1. Enfrentar el problema. No se trata de darle la vuelta, evitarlo o buscar alternativas, se trata de reconocer que existe y emprender el camino hacia su resolución. Necesitas exponerte a los problemas. Quizás necesites tus habilidades más recientemente adquiridas en el mega-seminario de administración de proyecto o simplemente usar tu sentido común, pero lo importante aquí es concentrar tu atención en la búsqueda de la mejor solución al problema y no en evadirlo.

2. Documentar los resultados de tus esfuerzos por resolver el problema. Esto es algo así como las lecciones aprendidas parciales de tu proyecto. Es tu experiencia. Esto es el legado que vas a dejar al mundo de la administración de proyectos. Es el manual de resolución de problemas que le estás heredando a aquellos que están al inicio, en medio o al final de la carretera que representa la administración exitosa de un proyecto de cualquier naturaleza. Este registro es invaluable. Es lo que todas las compañías deberían estar ofreciendo dentro de sus capacitaciones. No ha habido seminarios más interesantes a los que yo haya asistido que a aquellos en los que se relatan lecciones aprendidas de un proyecto en específico. Es experiencia en acción, es valor agregado en toda su expresión.

3. Buscar problemas por resolver. Ya encontramos problemas en nuestro proyecto, ya los resolvimos, ya registramos las lecciones aprendidas y el problema quedó resuelto. La única manera para practicar la resolución de problemas es exponiéndonos a ellos de manera regular. Si no tienes problemas en tu proyecto seguramente es porque no has observado bien. Si no ves problemas seguramente es porque no has buscado en el lugar correcto. Los problemas están allí, tienen un reloj haciendo tic-tac, a punto de explotar cuando menos nos lo esperamos. Si no buscamos los problemas ellos nos encontrarán a nosotros pero quizás nos encuentren con la guardia baja.

Un proyecto se trata de resolver problemas. El trabajo se trata de resolver problemas. La vida se trata de resolver problemas. Aprende a vivir con ellos, a buscarlos, a identificarlos, a reconocerlos hasta que se vuelva tu segunda naturaleza, aprende a enfrentarlos, aprende a olfatearlos a lo lejos, aprende a prevenirlos antes de que ocurran… esto te dará un altísimo nivel de empleabilidad.

Los mejores administradores de proyectos con los que he tenido el privilegio de trabajar no estaban certificados en Project Management, los mejores no tenían cientos de horas de capacitación en administración de proyectos. Los mejores que yo he conocido sabían identificar problemas, resolverlos, anticiparlos y los enfrentaban agresivamente, inteligentemente y, como una osa que sentía la amenaza de un extraño, embestían el problema hasta dejarlo fuera de combate para siempre.

¿Qué hay de ti y de mí, que nos reunimos virtualmente para compartir esta lección, que buscamos seminarios y lecturas interesantes para afilar nuestras armas para la batalla en el campo de la administración de proyectos?, ¿no deberíamos tener un mejor desempeño?

Así es mi amigo lector, sal, busca y enfrenta tus problemas, pelea la buena batalla, la batalla que está ganada, la batalla de la profesionalización y aplicación de mejores prácticas en el campo de tu experiencia y cuando tengas la victoria documenta, comparte y aprende… y prepárate para el siguiente round.

Te deseo éxito.

Por Fernando Valdez