Archive for the ‘Riesgos’ Category

Aceptando el reto

Jueves, Marzo 19th, 2015

Recientemente iniciamos un proyecto para un cliente estadounidense. Nuestro cliente quería un sitio web en el que se incluyera un componente de donaciones para una asociación civil sin fines de lucro, por lo que el presupuesto era muy ajustado. Adicional a esto, el cliente necesitaba que el sitio estuviera operando para inicios del año, lo que nos dejaba un calendario muy ajustado para terminar. La fecha de entrega no era negociable porque ya se había publicado la fecha del inicio del concurso que recaudaría los fondos y cada día que fuera entregado tarde el sitio representaba una pérdida en el potencial de recaudación.

shutterstock_7861366.jpg

Previo al proyecto

El cliente en EUA de primera instancia buscó compañías en ese país para que le hicieran el trabajo, pero con el presupuesto reducido y, sobre todo con el calendario tan apretado, tres compañías le rechazaron el proyecto. Posteriormente encontró un par de compañías basadas en India que accedieron a hacer el sitio por el presupuesto ofrecido, pero ninguna de las dos compañías ofrecieron terminarlo a tiempo, de hecho, ambas coincidieron en que lo podrían hacer en el doble del tiempo presupuestado.

Finalmente buscaron en México y siendo nosotros socios comerciales en proyectos pasados nos solicitaron la implementación. Revisamos la factibilidad y decidimos abordar el proyecto pero con una metodología ágil en la cual redujéramos algunos costos. La propuesta fue aceptada e iniciamos el proyecto.

Factores de riesgo

Adicional a la metodología ágil, otra estrategia que implementamos para reducir el costo fue conseguir personal externo a nuestra compañía que hiciera el trabajo con un precio por debajo de nuestro propio costo y buscamos personal en entidades socioeconómicas de menor nivel (fuera de la ciudad de Monterrey) y con los conocimientos técnicos para hacer la tarea.

Entrevistamos a algunos individuos y finalmente contratamos a dos de ellos en una ciudad a más de 2,000 kilómetros de distancia.

shutterstock_98130041.jpg

El proyecto involucraba el desarrollo sobre un Sistema Administrador de Contenido (Content Management System o CMS ó por sus siglas en inglés) que nuestro equipo nunca había utilizado y también involucraba la interacción con una entidad para la recepción de donaciones de manera segura, cosa que tampoco habíamos implementado antes.

Todo esto preparaba una atmósfera de riesgo adicional en el proyecto sin embargo decidimos tomar el reto con el afán de dar el servicio y con la expectativa de hacer algo que otros no habían querido hacer.

Las fiestas decembrinas, el fin de año, el equipo de trabajo a distancia, la metodología ágil, el presupuesto cerrado del proyecto, la fecha agresiva de entrega del proyecto y la tecnología que nuestro equipo no dominaba eran riesgos evaluados pero no poco considerables.

La ejecución del proyecto

En las primeras fases todo parecía ir bien hasta que solicité ver físicamente los entregables, empezamos a notar que no estaba todo lo que los externos decían que iban a completar. El líder de los externos empezó a postergar entregables de un sprint a otros posteriores y lo que fuimos recibiendo eran entregables incompletos.

Hicimos la primer presentación del avance al cliente de manera exitosa indicando que postergaríamos algunos de los entregables para una presentación posterior y el cliente aceptó.

Llegaron las festividades decembrinas y por un tiempo no recibimos avances considerables. El equipo externo estaba localizable, pero los entregables no se completaban. Establecimos una estructura de revisiones más cercanas que el equipo externo no pudo cumplir ya que no tenían siquiera una estructura de trabajo formal.

shutterstock_20302609.jpg

En subsecuentes revisiones con el cliente, éste se mostró preocupado por el escaso avance y empezó a cuestionar nuestra capacidad de entrega del producto a tiempo, por lo que me vi forzado a tomar por completo el control del equipo externo aún cuando su líder se resistía a ser administrado.

Iniciamos juntas diarias con el equipo remoto y establecimos metas claras diariamente para ir concluyendo cada uno de los entregables. También concentré al equipo en pocas actividades de alto valor, esto nos permitió ir acabando lo más importante aún que fueran pocos entregables y evitar tener muchos medios avances.

Agregué un equipo de pruebas que no era de ingenieros de pruebas (QA Testers), sino un equipo de desarrolladores de sistemas que empezaron a probar cada uno de los entregables que a su vez el equipo de externos iba produciendo. Esta decisión tenía tres objetivos: 1) reducir el tiempo del ciclo entrega-testing-documentación-remediación-entrega, 2) involucrar a nuestro personal técnico en la solución desarrollada, para que pudiera hacerse cargo de algunas partes del desarrollo del sitio en un momento dado, y 3) para que nuestro equipo apoyara en la remediación de algunos defectos, de tal forma que redujéramos la cantidad de trabajo enviada a los externos para remediación.

Continuamos con las revisiones diarias que a la vuelta de las semanas se volvieron muy cansadas ya que no permitíamos que el equipo se fuera a descansar sin concluir las metas propuestas por ellos mismos en el día. Debido a algunos problemas de actitud que el equipo de externos tenía, las revisiones se volvieron tortuosas, sin embargo para mediados del mes de enero, muy cerca ya de la fecha de entrega, declaramos como terminado todo el sitio y solo quedaron algunas actividades de pruebas y remediación de errores.

Las pruebas finales

shutterstock_56950768.jpgHacia el fin del proyecto invitamos al cliente a entrar al sitio para que validara toda la funcionalidad, el accedió e invitó a tres integrantes de su empresa para probar el sistema. Nosotros les compartimos el acceso a una herramienta para el reporte y seguimiento de los errores encontrados y en ese sistema ellos fueron capturando cada problema encontrado. Nuestro equipo revisaba la lista de problemas encontrados y priorizaba  su atención, asignaba cada problema a un responsable de desarrollo e iba remediando cada problema y probando que hubiera quedando resuelto. De esta manera proporcionamos un entorno muy visual y transparente del avance en la resolución de problemas encontrados.

La entrega

El sitio lo terminamos dos semanas antes de la fecha final de entrega y esas dos últimas semanas el cliente estuvo revisando y reportando problemas mientras nuestro equipo los resolvía. El día previo a la fecha final de entrega, alrededor de las 7:30pm terminamos de corregir todos los problemas y el sitio pudo ser anunciado en la prensa local y las donaciones empezaron a entrar al día siguiente.

Hubo algunos cambios que nos solicitó el cliente conforme iba probando el sistema y conforme veía su desempeño, pero gracias a que involucramos a nuestro equipo pudimos hacer internamente lo solicitado sin recurrir a los externos, a quienes ya habíamos liberado con la intención de no volver a contratarlos más.

Conclusión

Nos quedamos con muchas lecciones aprendidas de este proyecto, pero una de las principales es que necesitamos tomar los retos que se nos presentan, pero con una evaluación adecuada de los riesgos y de nuestra capacidad para afrontarlos. Desde luego aprendimos que debemos combinar el menor número de riesgos, por ejemplo, pudimos experimentar con un grupo de externos con los que no habíamos trabajado antes, pero en un proyecto más holgado.

Nuestro cliente quedó sorprendido por nuestra entrega a tiempo con fechas tan agresivas y un presupuesto tan recortado y gracias a eso ya estamos firmando nuevos proyectos con ellos, pero más holgados y en mejores condiciones presupuestales.

Creo que podemos hablar mucho de lo que hacemos, pero cuando nos dan la oportunidad de demostrarlo eso se convierte en el mejor argumento de ventas para nuestro equipo de trabajo. 

shutterstock_76411899.jpg

Los indicadores de avance del proyecto

Jueves, Febrero 27th, 2014

Hace poco estuve al cargo de varios Gerentes de Proyectos (PMs = Project Managers) con quienes interactuaba frecuentemente para conocer el avance de sus proyectos asignados. Al llegar con uno de los PMs le pregunté “¿cómo va el progreso en las actividades del proyecto?”, y el me platicó por veinte minutos todos los pormenores por los que había cruzado el equipo y abundó en las dificultades del proyecto, me comentó sobre las largas jornadas de trabajo de los integrantes y las peleas internas entre ellos, me habló sobre el pobre desempeño de alguno de los consultores y mucho, mucho más.

1.jpg

Al final de su explicación le volví a preguntar, “y… ¿cómo va el avance del proyecto?”.

Cuando se trata de un proyecto, siempre es necesario tener información para poder evaluar su progreso, pero debemos aprender a obtener y a comunicar la información estrictamente necesaria para lograr ese objetivo.

Después de una sonrisa, el PM me dijo “acabo de decirte como va el proyecto”, y yo le contesté “no, me acabas de platicar algunos pormenores de lo que ha ocurrido desde la última vez que reportaste avances, pero aún no sé si el proyecto va a terminar a tiempo o no, o si tenemos un desempeño del gasto del presupuesto dentro de los límites aceptables. Tampoco me has comentado la probabilidad de ocurrencia de los riesgos que has detectado ni el impacto que tendría si alguno de ellos se materializara. No me has permitido conocer el número de casos de prueba generados, ni aquellos que ya fueron ejecutados y de éstos cuáles han resultado exitosos y cuáles necesitan ser remediados.”

Después de dar seguimiento a múltiples proyectos con clientes de todas dimensiones, he concluido que necesito el mínimo de información objetiva y medible para darme una idea general del avance del proyecto. Una vez habiendo evaluado esa información, entonces sí me interesa conocer los detalles no-duros (subjetivos y desestructurados) más importantes que me permitan apoyar a mis PMs y al equipo de proyecto para que tengan un mejor desempeño y para alcanzar las metas del proyecto. Desde mi perspectiva se requiere un equilibrio entre información dura y no dura para llegar a conclusiones más completas.

Cuando terminé de hablar con mi colega le pregunté cuál era el SPI del proyecto (Schedule Performance Index = Índice de desempeño del cronograma) y recibí un silencio ensordecedor. Así que aprovechando que el siguiente lunes era festivo, llamé al PM, al Líder Técnico y al Líder de Pruebas del Proyecto a una junta a las 9:00am para discutir sobre esos temas. Para aprovechar el tiempo les pedí que trajeran la siguiente información lista para nuestra sesión de trabajo:

* Plan general del proyecto (incluyendo el cronograma).

* Número de horas totales del proyecto (Presupuesto original de horas).

* Número de horas consumidas al día de hoy (Valor actual de horas consumidas).

* Actividades del plan terminadas al 100% y la suma de las horas que representaba ese avance (Valor ganado)

2.jpg

Con esta información pude calcular los indicadores normales de valor ganado como el desvío actual del presupuesto y del calendario (Cost Variance y Schedule Variance respectivamente) y pude calcular algunos pronósticos como el número de horas totales invertidas al terminar el proyecto (EAC = Estimate At Completion) y el número de horas pendientes por trabajar (ETC = Estimate To Complete) si siguiéramos trabajando al mismo ritmo.

En ese momento, todos nos dimos cuenta que el proyecto iba retrasado en tiempo y que el equipo tenía un desempeño del 95%, es decir, que por cada hora trabajada solo el 95% de esa hora estaba siendo empleada en actividades que agregaban valor al progreso del proyecto como estaba definido originalmente.

También nos dimos cuenta de que estábamos gastando el presupuesto del proyecto más rápido de lo planeado y que al ritmo al que íbamos terminaríamos en números rojos al finalizar.

Adicionalmente el cliente nos estaba poniendo una restricción en el calendario, donde necesitaba recibir el sistema que estábamos construyendo a mas tardar en 2 meses incluyendo todos los entregables, y gracias a los indicadores que obtuvimos pudimos ver que eso no iba a ser posible si seguíamos trabajando al ritmo que llevábamos (SPI menos que 1).

Terminamos nuestra reunión interna después de 3 horas y le pregunté al PM acerca de la relación que llevábamos con el cliente a lo que el me contestó que era inmejorable, que estaba muy contento con el trabajo del equipo y que ya estaba viendo la manera de entregarnos otros requerimientos para futuros sistemas.

En mi opinión, hemos hecho del proceso una meta, siendo que la meta es el resultado del proyecto. El proceso es importante desde luego porque determina la recurrencia en proyectos con el mismo cliente (nuevos negocios), pero lo que debe recomendarnos es nuestra capacidad para dar resultados. He leído en diversos artículos que la administración de proyectos es tanto una ciencia como un arte y estoy de acuerdo con eso, el problema es que a veces tendemos mucho hacia el arte o hacia la ciencia de manera exclusiva y desequilibrada y perdemos el beneficio del extremo descuidado.

 3.jpg

En el caso del proyecto que les platico, le pedí al PM una revisión semanal de algunos de estos indicadores y le generé una plantilla en una hoja de cálculo para que el pudiera generar esta información con facilidad. El PM dedicó su creatividad y la del equipo a buscar maneras de revertir el retraso y aumentar la productividad para cumplir con la restricción de cronograma que teníamos. Tuvimos que agregar un apoyo externo para poder terminar a tiempo, lo que incrementó el presupuesto del proyecto, pero afortunadamente esto lo comunicamos con anticipación y no generó un problema con el cliente.

Soy un creyente de que las relaciones con los clientes deben cuidarse, pero también pienso que la relación es el camino y no la meta, y para alcanzar metas con calidad necesitamos medir, corregir y entregar.

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

¿Qué hacer si un submarino afecta mi proyecto?

Viernes, Julio 2nd, 2010

En mi experiencia como Administrador de Proyectos considero que uno de los principales retos ha sido el tener que planear para lo que pueda ocurrir y enfrentar aquello para lo que no planeamos. Seamos honestos, comúnmente planeamos para el 80% de los problemas más comunes y sabemos que pueden ocurrir porque más de uno de ellos ya nos ha sorprendido en proyectos anteriores.

Basamos mucha de la planeación de riesgos en nuestra propia experiencia o en la de colegas más cercanos, pero dejamos de lado aquello que parece improbable que ocurra en nuestro proyecto.

Equipo de proyecto

Permítanme compartir una lección aprendida acerca de lo comentado hasta ahora. Hace poco iniciamos un proyecto de desarrollo de software en el que el equipo inicial lo conformábamos un Arquitecto de Software, dos Arquitectos Técnicos, ocho Desarrolladores de Software, dos Ingenieros de Calidad y su servidor como
Administrador del Proyecto (AP).

Descripción del proyecto

Nuestro objetivo era entregar una aplicación que serviría para almacenar, administrar y determinar si un usuario del sistema de e-Learning de la compañía había logrado los créditos suficientes para certificarse o re-certificarse como Contador Público en la jurisdicción geográfica a la que pertenecía. Esta aplicación se conectaría al sistema de e-Learning y de recursos humanos  ya existentes en la compañía. Para dar una idea del tamaño del sistema teníamos 140mil usuarios que se encontraban distribuidos en más de 10 zonas geográficas en el mundo.

Ambiente del proyecto

Parte de los factores que presionaban este proyecto eran que el cliente quería reemplazar su herramienta actual de administración de créditos y ya tenía expectativas al respecto. Por otro lado el cliente había solicitado que usáramos herramientas para desarrollar el sistema  que no eran las mismas que se habían usado en el sistema actual, de tal manera que no había posibilidad de reutilizar ningún componente. Finalmente, las reglas de negocio de la primera versión habían cambiado drásticamente dado que íbamos a realizar una extensión grande en la funcionalidad.

Estructura del equipo

El equipo de proyecto me reportaba directamente a mí y yo reportaba avances a un Program Manager que pertenecía a la Oficina de Proyectos (PMO) y a un Solution Manager que pertenecía a la SMO. El equipo de proyecto se encontraba distribuido en tres países: México, Estados Unidos (USA) e India. Los tres arquitectos, cuatro desarrolladores y los ingenieros de calidad se encontraban en México, tres desarrolladores estaban en la India y un desarrollador y las oficinas de proyectos se encontraban en USA.

submarino.jpg

Desarrollo del proyecto

Pasamos por las fases de inicio, planeación y durante la ejecución y control experimentamos muchos retos, pero aquí quiero enfocarme en una experiencia que no voy a olvidar. Estábamos muy cerca de las entregas iniciales, aquellas que establecerían la “primera impresión” para el cliente. Los tiempos estaban apretados por algunas decisiones tomadas con anterioridad, pero estábamos confiados en que un esfuerzo extra daría los resultados esperados. Los ejecutivos en USA se encontraban nerviosos porque el cliente era el más importante que teníamos en aquel momento y ese nerviosismo se convertía en presión para el Program Manager y para mí como AP. La fecha de nuestra primera entrega se estableció para un lunes 4 de febrero y las semanas anteriores el equipo había estado trabajando diligentemente de tal manera que parecía que terminaríamos a tiempo con poco o nada de tiempo de holgura.

Problema

Dada la importancia de los entregables, establecí  un reporte diario de avance con los miembros del equipo, en especial con el personal de India. Nos encontrábamos al final del viernes 1 de febrero (tres días naturales antes de la entrega) cuando de pronto noté que, a pesar de su diligencia en el envío del reporte diario, el personal de India no había registrado progreso ese último día y no tenía ningún reporte de ellos con respecto al motivo. Intenté llamarles pero asumí que no estarían en la oficina dado que nos separaban 11.5 horas y para ese tiempo ellos estarían dormidos. Habíamos planeado trabajar al día siguiente y si fuera necesario hasta el domingo, pero esto ponía la situación más difícil aún.

Esa madrugada de sábado, alrededor de las 2:00am hora del centro (CT), intenté comunicarme con la India (1:30pm IST) y al fin lo logré. Los miembros de mi equipo me comentaron que habían sufrido un corte del servicio de Internet a escala mayor. Investigando en diversos portales de noticias nos enteramos que el viernes 1o de febrero un barco en el mar mediterráneo ancló tras verse amenazado por el clima y cortó uno de los cables submarinos que comunican por Internet al Medio Este con Europa afectando gran parte del ancho de banda de la India y otros países.

Solución

Llamé inmediatamente al Program Manager y comentamos la situación con los ejecutivos en USA. Surgieron una serie de soluciones probables, una de ellas era enviar físicamente a alguien a la India con discos duros para traer el código fuente, pero fue descartada porque el viaje por los diferentes aviones y por carretera dura alrededor de 30 horas, eso nos quitaría toda oportunidad de terminar a tiempo.

Finalmente, investigando más, supimos que el administrador del ancho de banda de la India estaba utilizando el horario de occidente para mantener la operación de todos los call centers que se encuentran outsourceados allá y que estaba dejando el horario nocturno de occidente para todo tipo de operaciones, de tal manera que implementamos una serie de medidas para resolver nuestro problema:

1.    El equipo ejecutivo hizo del conocimiento del cliente lo que había ocurrido. No le comentaron que no entregaríamos, solo que probablemente nos retrasaríamos.
2.    Solicité a los desarrolladores Indios que hicieran Copy-Paste al código y que en lugar de colocarlo en la herramienta de control de versiones, lo enviaran por correo electrónico. Los correos electrónicos estaban tardando más de una hora en llegar dado el bajo ancho de banda que tenía India en esos días.
3.    Con el código ya en México usé a uno de los Arquitectos Técnicos para tomar ese código y ponerlo en el lugar adecuado dentro de nuestra herramienta de control de versiones. Un Arquitecto Técnico es considerado una persona de amplia experiencia en el terreno técnico y tiene conocimientos de negocio y habilidades de liderazgo, de tal forma que puse a un elemento muy capacitado en una labor que demandaría amplio conocimiento técnico e iniciativa. Además esta persona había estado apoyando con la definición de los paquetes de trabajo enviados a la India, de tal forma que conocía el alcance y demás detalles de sus entregables.
4.    Con la decisión de manejar el código localmente automáticamente retiramos el riesgo de retrasos por falta de conectividad, pero redujimos el equipo de proyecto en casi 40%, de tal manera que eso representó otro problema: estábamos pagando por recursos que no estaban siendo productivos (en India), y teníamos trabajo para 8 personas siendo atendido por sólo 5. Este problema es algo para lo que hubiera planeado si el problema mayor (la falta de conectividad) no hubiera existido, pero decidí aceptar ese nuevo riesgo y mitigarlo moviendo al arquitecto al equipo de desarrollo.
5.    Generé un network diagram para determinar las dependencias y empezamos a trabajar en la ruta crítica. Cuando uno de los miembros del equipo estaba a la espera de otro paquete de trabajo lo enviaba a dormir y lo citaba de acuerdo con la hora estimada de entrega del paquete dependiente. Así mantuvimos un equipo constantemente trabajando pero todos tuvieron oportunidad de dormir aunque fuera poco tiempo.
6.    Para disminuir la curva de aprendizaje procuré mantener a la gente en las actividades que ya tenían con anterioridad y un bajo porcentaje de actividades nuevas.

Acciones posteriores

Más adelante en el proyecto volvimos a integrar a los miembros del equipo en India e hicimos la transición de nuevos paquetes de trabajo para ser desarrollados en aquella región, desde luego paquetes que no estuvieran en la ruta crítica.
Adicionalmente agregué dentro del registro de riesgos la posibilidad de corte en la comunicación con India e incluso con Estados Unidos y desarrollamos planes de contingencia.

Finalmente hice una lista de riesgos comunes dentro de los proyectos de software que siempre consulto cuando inicio un nuevo proyecto, pero siempre dejo un tiempo para hacer un ejercicio de lluvia de ideas para planear para todo aquello fuera de mi checklist de riesgos comunes, siempre considerando los factores ambientales del proyecto y de la compañía.

Conclusión

Este es un ejemplo, sólo uno, de lo que ocurrió en uno, sólo uno, de mis proyectos. De aquí la importancia de la capacitación de los Líderes de Proyectos y Administradores de Proyectos, de aquí la importancia de foros de discusión con gente de la profesión, de aquí la importancia de profesionalizar nuestra labor. Siempre he recomendado a mis compañeros y amigos de trabajo que ante un problema debemos profesionalizar y colegiar nuestras acciones, esto es, debemos actuar profesionalmente basados en los conocimientos y usando técnicas propias de la profesión y debemos interactuar con nuestros colegas ya sea por medios electrónicos o personalmente para recibir ideas frescas y fuera de sesgo con respecto a la situación que enfrentamos.

Espero que esta experiencia sea de utilidad para los lectores en sus futuros proyectos.

Y por cierto, sí, entregamos lo prometido a tiempo el lunes 1ro de febrero, después de varias tazas de café y latas de red-bull.

Por Fernando Valdez

El Alzheimer de los proyectos

Miércoles, Diciembre 10th, 2008

¿Alguna de estas frases te es familiar?

“Hace tres meses les dije que necesitábamos X”
“¿Cómo fue posible que nadie se acordara de ese requisito?”
“No, nunca quedamos en que esa era mi responsabilidad”

Si alguna vez has sentido que tu cabeza y/o la de alguien próximo (arriba, abajo o a un lado) corren peligro por alguna de estas frases, es que en ese proyecto no se documentó lo suficiente.

Hace poco en una reunión de un proyecto con tres (si, 3) meses de retraso, escuché: “Ese coordinador de procesos de negocio ya lo había propuesto hace cuatro meses, pero nadie lo consideró importante y luego ni se acordaron de la propuesta”. Cuando llegó el momento de cortar cabezas, también le tocó a la persona que había hecho esa propuesta, a pesar de ser una persona muy competente tuvo que pagar los platos rotos y la ineptitud de sus colegas, porque no tuvo ninguna evidencia a la hora de deslindar responsabilidades.

Documentar es una de las actividades invaluables de un buen proyecto, y por documentar me refiero a plasmar toda la información posible en diagramas y/o documentos, sí, toda la información posible.

¿Qué debemos documentar?, absolutamente todo lo posible y/o importante; reuniones con minutas, procesos de negocio con diagramas, la visión del proyecto en un documento, los riesgos, el plan de control de calidad, etc. Para tener una lista más completa podemos consultar el viejo e invaluable PMBOK.

Vamos aclarando, el objetivo de documentar no es tener centenares de documentos con una prosa impecable o decenas de diagramas estéticamente perfectos, es bueno documentar siempre y cuando nos genere algún valor agregado, y esto puede ser por alguna de las siguientes razones:

- Comprender el dominio o negocio
- Evitar omisiones
- No depender de las personas
- Concertar acuerdos
- Registrar compromisos adquiridos

En los proyectos de alto riesgo es aún mucho más importante documentar, porque cuando algo falla catastróficamente y llega la hora de repartir culpas, crucificar responsables y rebanar cabezas (en suma: deslindar responsabilidades), las minutas son una excelente herramienta para descubrir mentiras e ineptos.

Moraleja…

No documentar en un proyecto, es como enrolar sólo a personas con Alzheimer, tal vez recuerden varias cosas de todos los acuerdos, procesos, hitos, reuniones, etc. Pero hay toneladas de información y decisiones que quedarán en el olvido por un momento y las recordaremos justo cuando hagan más daño (remember Murphy).

Así que no lo olviden: Más vale documentar que lamentar.

Por Mentat