Andares de un proyecto

Aceptando el reto

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

La importancia de los mentores

Publicado el Junio 11th, 2013 en Inicio, Control, Planeación, Calidad, Recursos Humanos, General por admin

Por Fernando Valdez

Llevaba trabajando en una empresa apenas unos dos meses cuando recibí una llamada por teléfono. Contesté y era de Estados Unidos, era un gerente de servicio a clientes de nuestra empresa que a su vez tenía a una persona de finanzas al teléfono y juntos estaban pidiéndome el reporte financiero de un proyecto que yo estaba administrando. La verdad es que nunca había oído hablar de ese reporte y mis interlocutores extranjeros sonaban con mucha prisa por tenerlo en sus manos, ya que era momento de recabar información del proyecto para hacer los cargos correspondientes al cliente. Yo era el único Administrador de Proyectos extranjero (toda nuestra organización estaba basada en la ciudad de Dallas, Tx. y en Cleveland, Oh.) y yo no tenía a nadie a quien preguntarle acá en México. Además, como ya lo comenté, nuestro departamento apenas había sido creado hacía un par de meses fuera de Estados Unidos y nadie tenía la más mínima idea de cómo proceder ante tal petición. Los silencios incómodos empezaron a surgir y los gerentes al otro lado de la línea parecían muy inquietos y temerosos de que no existiera tal reporte, así que les dije que necesitaba 30 minutos para darles una respuesta al respecto. Ellos aceptaron e hicieron hincapié en que ese reporte debería ser enviado a la brevedad posible. Colgamos el teléfono y pensé: “¿que voy a hacer?”.

mentoring-w.jpg
Antes de mencionar cómo resolví el problema, déjenme hablarles un poco sobre nuestra organización y sobre las dos primeras semanas de trabajo en la misma.

Al ingresar a la compañía dos meses atrás, hice un viaje de dos semanas a Dallas, Tx para conocer a mis colegas Administradores de Proyectos y a mi jefe, el director de la Oficina de Proyectos (PMO - Project Management Office). Durante el viaje no solo los conocí, sino que me fueron explicados los procedimientos estándar de la oficina de proyectos, así como los documentos que deberíamos generar y el repositorio para almacenar dichos documentos a través de las diferentes etapas de los proyectos.

Al segundo día de estar en Dallas, mi jefe se acercó a mi escritorio y me presentó a un Administrador de Proyectos Sr. que además apoyaba a la PMO en diversas actividades. Mi jefe mencionó que cualquier duda que tuviera se la preguntara a él, ya que sería mi mentor, y me dijo que él me daría indicaciones durante los próximos días sobre lo que tendría que cuidar dentro de un proyecto.

En un principio esto se me hizo exagerado, porque para entonces yo llevaba alrededor de diez años administrando proyectos y contaba con mi certificación como Project Management Professional (PMP). En teoría todo lo que mi mentor me podría haber enseñado era algo que de alguna u otra forma yo ya había experimentado.

Mi mentor hizo una excelente tarea en mostrarme los detalles específicos de nuestra organización, cómo generar documentación, donde almacenarla y cómo conducir reuniones de equipo presenciales y virtuales con personal de la India y de otros estados de la unión americana, pero hasta  ese momento no habría surgido la necesidad de llenar algún reporte de carácter financiero.

Como Administradores de Proyectos en el área de desarrollo de sistemas computacionales no siempre nos vemos envueltos en la necesidad de manejar presupuestos en pesos o en dólares, sino presupuestos en horas-hombre.

Normalmente hacemos estimaciones de duración de los proyectos y mucho de lo que manejamos son las horas de esfuerzo que un empleado pone en el proyecto. Esto a su vez se traduce a pesos o a dólares ya que cada hora tiene una tarifa que depende de la experiencia y la naturaleza de las actividades a desempeñar por el empleado. Sin embargo, cuando se trata de los clientes, en última instancia todo lo manejamos en términos de una unidad monetaria y de aquí la importancia del reporte financiero del proyecto.

Ahora si, de regreso a la llamada que acababa de terminar con mis colegas de finanzas y de servicio a clientes. Levante inmediatamente el teléfono y le llamé a mi mentor, le expliqué la situación y el me dijo, “ah!, no te había explicado eso porque no era aún tiempo, pero dada la prisa que parecen tener, te voy a ayudar a generar el reporte y después te explico con calma los pasos para obtenerlo”. Mi mentor me dijo cómo hacer el reporte sin muchos detalles, pero dado que yo tenía ya experiencia, pude entender lo que estábamos haciendo para armar tal reporte.

organizaciones-inteligentes-610×250.jpg

Treinta minutos después de esto envié un correo electrónico con el reporte que me habían solicitado incluyendo información sólida sobre las finanzas del proyecto.

Con esto puedo extraer al menos tres experiencias que me han sido muy valiosas en los últimos años como Administrador de Proyectos:

1) Cada empresa tiene diferentes formas de hacer las cosas. Cuando llegues a una nueva compañía trata de entender y conocer los formatos y procedimientos que se manejan allí. Probablemente el reporte de comunicaciones o el cronograma se llamen igual de una empresa a otra, pero en cada una hay una manera diferente de hacerlo.

2) La importancia de tener una PMO y procedimientos estándares para la administración de proyectos. El reporte financiero que me pidieron ya tenía un formato específico e incluía información cuya fuente era ampliamente conocida por todos. Utilizábamos un sistema para capturar las horas dedicadas a cada proyecto en una base semanal, de tal forma que al ejecutar un procedimiento de actualización, dichos números eran cargados automáticamente al reporte financiero y el resto era hacer algunos cálculos muy sencillos, así como comentarios acerca del desempeño del proyecto.

3) La importancia de tener un mentor que apoye a los nuevos empleados o a los mentoria-w.jpgAdministradores de Proyectos Jr. El tiempo que estos mentores invierten en un miembro del equipo es invaluable y la mayormente beneficiada es la empresa, ya que se hace un uso más óptimo de los recursos en lo general.

Mis colegas de finanzas y servicio al cliente ya conocían el formato que les había enviado, así que sólo se concentraron en extraer la información y pudieron cumplir a su vez con su trabajo de manera puntual.
Espero que esta experiencia haya sido útil para ustedes. Hasta la próxima.

Fernando Valdez 

Las prioridades deben ser claramente vistas por el project manager y su equipo

Publicado el Enero 25th, 2012 en Seguimiento, Calidad por admin

6a00d8341bf67c53ef0154361f25a3970c-800wi.jpgTeníamos más de cien tickets pendientes por atender, éramos cuatro personas en el equipo y teníamos tres clientes al teléfono solicitando ser atendidos, todos pedían fechas de entrega y presentación de avances, algunos querían hacer cambios a sus requerimientos… hablé con mi equipo y les pedí que colgaran los teléfonos y que no contestaran ninguna llamada o correo con respecto a los pendientes. Les pedí que entráramos a una sala de juntas, cuando cerramos la puerta no tenía ni idea de lo que iba a decirle a mi equipo, en realidad yo sólo quería escapar, no tenía un plan ni nada que decirles.

Permítanme comentarles cómo es que llegamos a ese punto.

En el año 2005 trabajaba en una empresa y yo era líder de proyectos en el área de sistemas. Por los últimos años habíamos estado trabajando en la creación de sistemas que fueran automatizando toda la cadena de valor de la empresa. La estrategia de la dirección general no era adquirir un ERP (Enterprise Resource Planning es un sistema que automatiza gran parte de los procesos administrativos de una compañía) ni un CRM (Customer Relationship Management es un sistema de información para la atención a clientes), más bien parte de su estrategia era adquirir un buen sistema de facturación e integrar todos los sistemas alrededor de éste. Para esa época, ya llevábamos gran parte de los sistemas desarrollados, así que la dirección general, al ver este avance y el hecho de que el sistema de facturación nuevo estaba quedándose corto, decidió hacer la adquisición del sistema nuevo.

Yo estaba a cargo del desarrollo de algunos sistemas y cuando empezaron los esfuerzos de implementación de la infraestructura de facturación, todos los equipos fuimos dirigidos a atender de manera inmediata cualquier necesidad de integración que surgiera.

Recuerdo que teníamos un sistema en el que registrábamos cualquier petición del usuario. Allí capturábamos las necesidades del usuario y también incluíamos algunos datos como el estimado de tiempo que llevaría cada fase de desarrollo, las personas a asignar al proyecto, etc. A esto le llamábamos el sistema de tickets. Cada ticket o registro podía ser un simple cambio, un reporte o hasta un sistema nuevo.
Por más de tres meses habíamos estado trabajando en la integración con el sistema de facturación y cada vez que queríamos atender a un usuario de otro sistema, la gerencia nos pedía que dirigiéramos todos nuestros esfuerzos a la integración. Yo llegué a preguntar “entonces, si me hablan ¿les digo que no los voy a atender?” y me respondieron “sí, diles que sí tienen un problema con eso, que me llamen a mí”, eso me dio seguridad inmediata porque así yo le mandaba a mi jefe todas las llamadas difíciles, pero no sabía lo que me esperaría cuando la integración con el sistema de facturación terminara.

Cuando nos dijeron que la integración con el sistema de facturación ya no era una prioridad y que necesitaban que nos enfocáramos a los demás pendientes que teníamos, los usuarios se enteraron y se volcaron al teléfono pidiendo ser atendidos como lo mencioné al inicio de esta entrada.

Así que allí estábamos dentro de la sala con un sentimiento de culpa por no estar trabajando ni atendiendo a los usuarios. Yo había escuchado como uno de los miembros de mi equipo estaba hablando desesperado con un usuario que ya lo había llevado al límite de su paciencia, así que preferí que no atendiéramos llamadas en vez de atenderlas mal.

Lo primero que les dije fue: “no podemos atender a todos al mismo tiempo, necesitamos atenderlos uno por uno y dejarles saber que vamos a atenderlos a todos a su debido tiempo”. Nos dividimos la lista de usuarios y les llamamos. Les hicimos saber que no íbamos a atender detalles sobre sus proyectos en esa llamada, ni íbamos a darles fechas en ese momento, pero que desde ese mismo día empezaríamos a hacer los pronósticos y a priorizar nuestra lista de tickets para atenderlos lo más pronto posible.

prioridades.jpg Al día siguiente revisé todos nuestros tickets (proyectos en potencia). Muchos eran errores de funcionalidad de nuestros sistemas, así que  les di la mayor prioridad. Visité a los interesados (quienes habían abierto el ticket) y les pedí que me mostraran el error, algunos de los errores no se presentaron, lo que me dio a entender que probablemente había sido un error de la plataforma tecnológica y no de nuestro sistema. Estos tickets los rebajé de prioridad y me quedé con el resto. Asigné a cada miembro de mi equipo una cantidad igual de tickets para atender, pero después de unos días casi todos los tickets seguían abiertos y sin conclusión. Cuando les preguntaba por qué no estaban atendiendo los tickets, me decían cosas como: “ah!, es que no me acordaba de ese ticket” o “ah!, no sabía que tenía mayor prioridad que el que estoy atendiendo”.

Me puse a pensar y llegué a la conclusión de que la lista de tickets era abrumadora y que si la veíamos como un todo, no detectábamos progreso aún cuando se cerrara uno o dos diariamente.

Así que al otro día pedí tres blocks de notas auto adheribles (PostIt®) de diferentes colores y tomé uno de ellos, el color amarillo. Tracé unas líneas en el papel para dividirlo en varias secciones, que contendrían lo siguiente:

  • Folio del ticket
  • Fecha de captura
  • Prioridad
  • Descripción del problema
  • Nombre del usuario
  • Nombre del ingeniero asignado
  • Fecha de cierre

Imprimí la lista de tickets ordenándola por persona asignada para atenderlo (ingeniero asignado) y le di a cada miembro de mi equipo su parte. Les pedí que llenaran cada PostIt con la información de cada ticket que les estaba dando y que lo revisaríamos a fin de día. Al final del día, cada miembro del equipo tenía alrededor de 30 PostIts amarillos en sus manos, con la descripción de cada ticket asignado a ellos.
Dividí la pared de mi lugar en dos partes: la izquierda y la derecha. Les pedí que ordenaran descendentemente por orden de antigüedad los PostIts de izquierda a derecha y de arriba hacia abajo, de tal forma que el ticket más a la izquierda y más arriba fuera el más antiguo y el de más abajo y más a la derecha fuera el más nuevo.

También les pedí a los miembros de mi equipo que cada vez que atendieran un ticket y que lo cerraran, movieran su PostIt de la parte izquierda de la pared a la parte derecha. Al final de la semana revisábamos en una reunión cuál era el status de cada ticket y re-priorizábamos la lista de acuerdo con la retroalimentación de los usuarios y de la gerencia. En esa misma junta reconocíamos la labor de cada miembro del equipo y hacíamos mención especial de aquel que hubiera cerrado más pendientes durante esa semana. Esto provocó un sentimiento de competencia positiva en la que los compañeros querían cerrar tickets.

Al final del mes agregamos color a la pared. Todos los tickets levantados en ese mes se vaciarían sobre PostIts de color verde. Cuando los PostIts verdes empezaron a dominar, un papel color amarillo era vergonzoso en la parte izquierda de la pared, porque significaba que era un pendiente antiguo que no había sido atendido. Al final del mes cambiamos a papeles de color rosa y así sucesivamente.

El ambiente que provocó esto entre mis compañeros fue muy positivo. Cuando otros compañeros de otros equipos preguntaban qué era eso que estaba en mi pared, ellos les decían “es el muro de los lamentos” haciendo referencia a la dificultad que representaba cerrar algunos tickets y lo vergonzoso que era tener pendientes aún abiertos allí (lo anterior, desde luego, con todo respeto para los miembros de la comunidad Judía entre mis lectores).

mural1-post-it.jpg

Fue impresionante ver que el número de tickets se redujo a 20 en las primeras semanas, el equipo de proyecto estaba motivado y colaborando unos con otros, los usuarios dejaron de hacer llamadas y la productividad de nuestro grupo se elevó impresionantemente.

Mi conclusión es que lo que no se ve, no se atiende. Actualmente contamos con excelentes sistemas de manejo de pendientes, agendas electrónicas y todo tipo de dispositivos tecnológicos que nos apoyan a tener una vida mejor administrada, pero la verdad es que la mayoría de nosotros atendemos día con día lo más urgente y lo que tenemos a la vista.

No estoy en contra de estos dispositivos, sino que creo firmemente en que tenemos que llegar a un punto en el que los sistemas y los dispositivos trabajen eficientemente para nosotros, quizás haciendo un tiempo diariamente para organizar nuestra lista de pendientes y re-priorizarlos.

Como quiera que sea, la “operación PostIt” siguió aún algunos meses después que yo dejé la compañía para trabajar en otro lado. Mi último día en la compañía el número de pendientes en el lado izquierdo de la pared no llegaba ni a diez… y todos eran del color del mes en curso.

Por Fernando Valdez

Orden no supervisada se la lleva la…

Publicado el Julio 14th, 2009 en Calidad por admin

Se acerca la entrega del proyecto, los días han sido intensos como bien saben, llegar temprano, salir tarde, descubrir que hay muchas actividades que no se realizaron y entregables que no están listos, más otra infinidad de cosas que no se entendieron de acuerdo a la especificación, debo confesar que en este proyecto entré a ocho meses de iniciado.

Cuando a un compañero le comenzaron a cambiar las especificaciones, a un par de semanas de liberar, me pareció que no había un proceso definido, pero me equivoqué…Buscando en el repositorio del proyecto, encontré un proceso bien definido, claro y concreto,  apegado a los mejores estándares. Preguntando un poco a los que iniciaron el proyecto también me enteré que había un área de procesos dentro del proyecto (es un proyecto grande), y que el proceso que había encontrado se les había explicado al principio del proyecto…

Mi tercer asombro fue cuando le pregunté a algunas personas por qué no habían seguido el proceso y los pretextos fueron vastos, ocurrentes y estúpidos algunos: “Llegué tarde a esa presentación”, “¿Qué no era una sugerencia?” “No nos dio tiempo”, “No le entendí lo que querían”, etc.

Si llegó tarde o no le entendió, ¿no podía preguntar?; ¿¿¿Sugerencia el proceso???

La culpa también fue del área de procesos, que nunca verificó que las personas estaban siguiendo el procedimiento, lo explicó una sola vez al inicio, pero muchísimas personas nos integramos posteriormente, en resumen les faltaron dos cosas:

Un mecanismo para asegurar que todos conocen el proceso
Supervisar que todos siguieran el proceso

Moraleja…

El área de procesos realizó un trabajo magnífico al definir los procedimientos del desarrollo, pero nunca se ocupó de asegurar la calidad del proceso, como diría el Líder de Proyecto más rudo que he encontrado: Orden no supervisada se la lleva la ch…

Por Mentat

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