Andares de un proyecto

¿Qué hacer si un submarino afecta mi proyecto?

Publicado el Julio 2nd, 2010 en Riesgos por admin

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

 
© LiderDeProyecto.com - Todos los derechos reservados. "PMI" y el logo de PMI son marcas registras en los EUA y en otros países; "PMP" y el logo PMP son marcas registradas de certificación; PMBOK® es una marca registrada en los EUA y en otros países. CMMI® es una marca registrada en los EUA y en otros países por el Carnegie Mellon® Software Engineering Institute. UML® y OMG® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada en los EUA y en otros países por IBM Corp.