Archive for the ‘Seguimiento’ 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.

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

Miércoles, Enero 25th, 2012

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