Archive for the ‘Ejecución’ 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.

La productividad de un líder

Miércoles, Febrero 29th, 2012

Existe una injustificada discusión entre lo que tendría que hacer el líder del proyecto y lo que realmente está haciendo y dicha discusión tiene que ver con el nivel de involucramiento que éste debería tener con los entregables técnicos del proyecto. Para salir pronto de dudas, el líder del proyecto debería estar más involucrado con el funcionamiento del equipo, que con la fabricación de los entregables. Algunos autores dicen que un administrador de proyectos nunca debería encontrarse en la ruta crítica del proyecto y esto es porque sus actividades, de naturaleza principalmente administrativas, pueden retrasar el trabajo de los demás compañeros. Esto no quiere decir que un líder de proyectos no debería participar en la construcción de entregables de un proyecto, pero si advierte que hay diferencias entre las actividades de un miembro del equipo y su líder.

estres-laboral.jpgComo decimos en México: “ni tanto que queme al santo, ni tanto que no lo alumbre”. Como PMs necesitamos documentar, necesitamos reportar avances, necesitamos documentar riesgos y actualizar el registro de problemas, necesitamos actualizar el cronograma y volver a empezar otra vez. Sin embargo, además de todo esto, necesitamos ser productivos. Necesitamos entregar resultados. Los resultados que un PM entrega no sólo son documentos escritos, sino resultados a través del equipo del proyecto. Que se haga lo que está planeado hacerse, que se entregue lo que se prometió con el nivel de calidad que se esperaba. Que la gente haga lo que tiene que hacer.

Hace ya muchos años, cuando formaba parte de Toastmasters, una organización internacional cuyos miembros aprenden y practican técnicas de comunicación en público y de liderazgo, tuve la oportunidad de formar parte de la mesa directiva que se integraba de siete personas: un presidente, un vicepresidente educativo, un vicepresidente de membresías y otros cuatro individuos con diferentes funciones. Yo asumí la presidencia del club y en la toma de protesta, el presidente saliente me dijo unas palabras que tienen mucho sentido cuando se trata de dirigir equipos de trabajo. El presidente saliente me dijo: “este es el momento en el que vas a tener que hacer todo lo que se tenga que hacer en el club, pero a través de la gente”. Más adelante pude observar como muchos presidentes de otros clubes empezaban muy bien, pero terminaban solos, haciendo mediocremente todo el trabajo que tendrían que hacer siete personas, pero ellos solos o con uno o dos ayudantes informales. Pero una posición de liderazgo no supone que el líder tenga que hacerlo todo el solo, sino que tiene que motivar, coordinar, dirigir y administrar para que cada miembro del equipo haga lo que le corresponde.

Durante mi gestión como presidente del club usé esa frase como un termómetro de mi liderazgo: si me encontraba haciendo lo que se suponía que otros tendrían que estar haciendo, entonces no estaba siendo el líder que debería ser, e inmediatamente empezaba a buscar las deficiencias en mi desempeño. Debo confesar que muchas de las deficiencias que encontré en mpi mismo no tenían que ver tanto con mis capacidades técnicas como con mi carácter o falta del mismo.

En mi trabajo como líder de proyecto también cometí ese error. Hace como quince años trabajaba con un equipo muy pequeño en el que tenía un practicante (estudiante de la carrera de ingeniería en sistemas haciendo prácticas profesionales) desarrollando una parte del sistema que teníamos que entregar. A la una de la tarde estábamos por salir a comer cuando me anunció el practicante que no podía terminar lo que íbamos a presentar a las tres de la tarde, justo después de comer. Al mismo tiempo se acercó otro desarrollador y me dijo que tampoco podía estar listo para la presentación. Me enojé mucho y empecé a cuestionar su desempeño. Los interrogué para saber dónde estaban encontrando las mayores dificultades y una vez que encontramos el problema me avoqué a resolverlo con mis propias manos. Les dije “Parense junto a mi para que vean cómo se hacen las cosas”. Los mantuve a cada uno viendo sobre mis hombros hasta que, diez minutos antes de la presentación, terminé todo el trabajo, probamos y todo funcionó correctamente.

Me levanté y les dije “no merecen estar en la junta de presentación de avances” y acudí a la junta yo solo. Afortunadamente todo salió bien: el usuario quedó complacido y mi coraje ya había desaparecido. Esa noche estuve reflexionando. Desde luego estaba orgulloso por mi desempeño técnico porque había resuelto en tiempo récord lo que dos desarrolladores no habían podido resolver, pero no estaba tan orgulloso por mi desempeño como líder. Por alguna razón los desarrolladores no pudieron cumplir con su tarea y yo no me enfoqué en darles la confianza y la oportunidad para ventilar eso. Claro que el tiempo estaba encima y no podía sentarme a hacerle al psicólogo mientras teníamos que entregar un resultado, pero también es cierto que no había motivado a esos muchachos últimamente ni había dado la oportunidad para discutir dificultades acerca de sus asignaciones.

Ese día terminé con una sensación de vacío que estaba tratando de llenar con falsos sentimientos de orgullo acerca de mi desempeño técnico. El vacío tenía que ver con una falta de liderazgo. Entregamos a tiempo, pero la relación con mis desarrolladores quedó desgastada, los humillé y no les ayudé en lo absoluto. Creía que ellos deberían aprender con la valiente hazaña que yo había hecho, pero estaba muy equivocado. Ese día me prometí no volver a meter las manos en el trabajo de otro colaborador, sino apoyarlo hasta que se alcanzara el objetivo aun que eso tomara más tiempo. Esto me obligaría a supervisar frecuentemente, a motivar, a involucrarme auténticamente. En muchas ocasiones posteriores los muchachos se acercaban e insinuaban que necesitaban el tipo de “ayuda” que les habría dado en el pasado (hacerlos a un lado y hacer la programación yo mismo), pero siempre les ofrecía un tiempo para hacer preguntas que los ayudaran a salir del ciclo mental en el que habían caído, hasta que empezaban a encontrar ellos mismos la solución. Al acercarme más a mi equipo pude entender mejor cuáles eran sus fortalezas y cuales sus debilidades y me enfoqué a ayudarles a superarlas con anticipación.3d-women-arrow-011-300×300.jpg

En una ocasión asigné un trabajo a una practicante y al poco tiempo se acercó y me dijo que no podía hacer el trabajo. La escuché y le di algunas ideas de como podía resolverlo y se fue contenta a intentarlo. Regresó unas horas después diciendo “ya lo intenté y no se puede”. Le pregunté qué es lo que esperaba que yo hiciera y ella me dijo “pues que se lo asignes a alguien más y me des a mí algo más fácil” a lo que yo le contesté “aquí no estamos en la escuela en donde muchas veces se premia el esfuerzo, éste es el trabajo y el trabajo se hace o no se hace, aquí no hay calificaciones de siete  u ocho, aquí es diferente”. Después le di otros consejos de cómo podría resolver el problema y se retiró muy pensativa. Mas adelante regresó diciéndome que mi sugerencia no funcionó, pero que intentó otras muchas cosas hasta que lo logró. Yo revisé el producto y realmente el problema estaba resuelto. Me sentí muy satisfecho por no haberle resuelto la situación; ella entendió que yo estaba para ayudarle, no para resolverle sus problemas, entendió que ella era responsable por dar un resultado, ella entendió que se le pagaba un sueldo por los resultados que diera y no por intentarlo. Ella estaba motivada y yo me estaba convirtiendo en el líder de proyecto que creía que debía ser.

La productividad no tiene que ser vista como la cantidad de cosas que haces, sino como los resultados que provocas para la compañía. Los resultados de un líder de un proyecto deberían ser medidos en su capacidad por hacer que los demás den resultados, por el nivel de liderazgo que demuestras, por tu capacidad de hacer que los demás hagan lo correcto, en el tiempo adecuado y con la calidad que se requiere.

Desde luego que los reportes de avance son necesarios, pero el liderazgo es mucho mas que eso. A veces hay que ser psicólogo, a veces adivino y, si el equipo lo necesita, a veces hay que “arriesgarse” a ser un amigo para ellos.

Por Fernando Valdez