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

Los indicadores de avance del proyecto

Publicado el Febrero 27th, 2014 en Ejecución, Control, Seguimiento, Planeación, Alcance, Comunicaciones, Riesgos, General por admin

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.

Porqué es de suma importancia contar con una PMO

Publicado el Abril 17th, 2012 en Control, Planeación, Grupos de Proceso, Alcance, Recursos Humanos por admin

diverse_business_man_and_woman_40435468.jpg

El término “dejar ir a un empleado” fue acuñado en los Estados Unidos y se refiere al acto de despedir a un empleado, pero desde el punto de vista del idioma Español, éste es un término impreciso, ya que un empleado no está solicitando permiso para retirarse y la compañía no está otorgando dicho permiso. Más bien este término es un eufemismo con el cual se da a entender al empleado que la compañía le está retirando la oportunidad laboral por el motivo que ésta considere conveniente, sin preguntarle su parecer al afectado.

Como quiera que sea, hace un par de meses “dejamos ir” a dos Project Managers de nuestra organización, presuntamente por su bajo desempeño. La misma noche que ocurrió esto, una de las afectadas publicó en su muro de Facebook que “no entendía el porqué de la decisión”. Esta situación me hizo reflexionar acerca los motivos que dieron lugar a su despido, muy al margen de opiniones subjetivas acerca de su desempeño, considerando sólo los hechos. Llegué a una conclusión basado en algunos hechos históricos que a continuación les comento.

Yo llegué a esta organización (mi trabajo actual) ocupando un puesto de Project Manager (al igual que mis dos compañeros que fueron despedidos). Mi organización consistía de un director de la PMO (Project Management Office u Oficina de Proyectos) y alrededor de diez Administradores de Proyectos técnicos (de tecnología de información). Después de dos años fui promovido a Gerente de Tecnología para el área de Monterrey, México, dado que la oficina local iba a crecer a más del doble y se requería una cabeza que administrara las operaciones locales. Un par de meses después de haber aceptado la promoción, la Oficina de Proyectos desapareció y los Administradores de Proyectos fueron movidos a diferentes áreas de la organización, principalmente al área de Servicio a Clientes, donde ahora administraban los proyectos de inicio a fin (contacto con el cliente, creación y autorización de proyectos, levantamiento de requerimientos, desarrollo del proyecto, cierre, seguimiento post-implementación, etc.), no sólo la parte técnica.

La rutina semanal durante mi trabajo como Administrador de Proyectos era más o menos la siguiente:

  • Lunes: Reunión general con el equipo para revisar avances. Cálculo de avances y entrega de reportes de avance a la Dirección de Proyectos (quien a su vez informaba a la alta gerencia).
  • Martes: Junta de planeación de recursos o Staffing meeting. En esta reunión nos juntábamos la alta gerencia, el equipo de autorización de proyectos, todos los gerentes funcionales, todos los gerentes de solución y todos los gerentes de proyectos. En esta reunión evaluábamos la participación de cada individuo (programador, arquitecto, ingeniero de calidad, administrador de proyectos, etc.) en los diferentes proyectos que habían sido autorizados, basándonos en la experiencia de cada individuo en las diferentes herramientas o áreas del negocio a atender. Por ejemplo, verificábamos si era factible tener a Juan en el proyecto X que requería de sus conocimientos técnicos. Lo mismo para Pedro, Hugo y Guillermo, basados en los mismos criterios (habilidades, conocimientos técnicos, conocimientos del área de negocio, experiencia dentro de la organización, importancia del proyecto, importancia del cliente, etc.). El resultado de esta reunión era un portafolio de proyectos con recursos tentativamente comprometidos para cada proyecto en determinada fecha. Esto nos permitía tener una versión tentativa de lo que iba a estar haciendo cada recurso de nuestro personal en el futuro cercano (es decir, los próximos dos meses).
  • Miércoles: Día normal de trabajo. Revisión de avances a nivel local (cada PM con su equipo).
  • Jueves: Reunión del Project Stearing Team (Equipo de Dirección de Proyectos). Este equipo se encargaba de elegir los proyectos a empezar y de priorizarlos de acuerdo con diferentes criterios, como eran: tamaño del proyecto, importancia del proyecto, urgencia del mismo, cliente a atender, etc. También los jueves teníamos la junta de la PMO en la que el director revisaba que nosotros, los líderes de proyectos, siguiéramos con el proceso de documentación, actualización de estadísticas y con cada paso definido en nuestro Ciclo de Vida de Desarrollo de Sistemas (SDLC por sus siglas en inglés). En esta junta teníamos oportunidad de mencionar si veíamos algún riesgo aumentando en probabilidad de ocurrir, mencionar sobre problemas sin resolver o sobre algún miembro de la organización que estuviera obstaculizando el progreso de nuestro proyecto. Si esto último era el caso, el director de la PMO tendría una reunión con la persona que estaba obstaculizando el proyecto y se avocaba a resolver el conflicto y permitir que el proyecto siguiera un curso adecuado.
  • Viernes: Revisión de avances y actualización de métricas. Aquí cada empleado capturaba las horas dedicadas a cada proyecto y a cada actividad realizada durante la semana. Además llenaban un reporte de las actividades que estaría realizando las próximas cinco semanas de acuerdo con los planes que se le habían entregado. Adicionalmente, se hacía un reporte de horas a cobrar a los clientes en el futuro cercano basados en las horas que facturaban los empleados. Todo esto nos daba mucha información que utilizaríamos para tomar decisiones para las siguientes actividades de nuestro equipo de proyecto.
  • Sábado y Domingo: Si habíamos sido exitosos en cumplir los objetivos semanales y si no había ninguna urgencia por parte del cliente, entonces podíamos descansar. En ocasiones, cuando trabajaba con personal de la India, yo iniciaba mi semana el domingo a las 9:30 de la noche, comunicándome con los miembros de mi equipo allá y dándoles dirección para el inicio de la semana, ya que para ellos eran las 9 de la mañana del lunes (iban adelantados 11.5 horas).

No quiero decir que durante el día sólo realizábamos las actividades arriba descritas. Cada día era un reto equilibrar las actividades administrativas, de personal, reportes y muchas más necesarias para el correcto funcionamiento del equipo. En ocasiones, como lo mencioné en un post anterior, era necesario ver por las necesidades de cada miembro del equipo llegando hasta el extremo de verificar si habían comido ese día o no. Eliminar obstáculos que amenazaban el avance del equipo, coordinar las comunicaciones, resolver conflictos, etc. eran actividades diarias para mí como líder de mis proyectos, agregando la complejidad que supone tener a medio equipo a 750 km de distancia y la otra parte del mismo, al otro lado del mundo.

outsourcing.jpg

 Algunos amables lectores se estarán preguntando: “¿qué tiene que ver todo esto con los dos compañeros que despidieron?” Permítanme contarles lo que ocurrió posterior a mi promoción y salida de la PMO.

Cuando el departamento de tecnología dejó de administrar los proyectos y esta administración pasó al departamento de servicio a clientes, algunos compañeros líderes de proyecto no se sintieron muy cómodos y renunciaron, lo que provocó que la organización perdiera experiencia, disciplina y estructura en la administración de proyectos y, al mismo tiempo, nos hizo vulnerables al desorden y la falta de lineamientos administrativos que la PMO brindaba a la organización. Esto no fue evidente de inmediato, sino que poco a poco ha ido revelándose como un problema que necesita solución y al que no muchos aceptan como un error de la administración general de la organización.

En un intento por regresar a “la normalidad”, el departamento de tecnología contrató dos Líderes de Proyecto (exactamente, tal como lo sospechan, contratamos a los dos líderes de proyecto que acabamos de “dejar ir”). Estos dos compañeros hicieron todo lo que pudieron: tomaron sus herramientas de administración de proyectos y planearon el alcance de sus proyectos, monitorearon su ejecución, documentaron riesgos y facilitaron la comunicación. No todas las decisiones que hicieron fueron las mejores, pero definitivamente tuvieron aciertos durante su gestión.

Desafortunadamente, dado que los recursos no les pertenecían del todo (en una organización funcional los recursos le pertenecen a un gerente funcional que los pone en préstamo para el desarrollo de los proyectos y cuando el proyecto acaba, los recursos son regresados a lo que llamamos “el pool” de recursos en espera de otro proyecto), en ocasiones les retiraban o les sustituían personal por otro menos capaz o menos apropiado para el trabajo, lo que impactaba enormemente al proyecto y, desde luego, a su reputación como líderes del proyecto.

A la vuelta de un par de años, en un recorte de gastos, los administradores de proyectos fueron puestos a disposición del mercado laboral global como ya lo mencioné al inicio de esta entrada.

¿Cuál fue la diferencia de estos dos líderes de proyectos y aquellos que formamos el primer grupo de administradores de proyectos en la organización? Mi respuesta a esta pregunta, para hacerla muy breve, es que aquellos que estábamos antes pertenecíamos a una PMO.

La Oficina de Proyectos no sólo nos daba herramientas para administrar nuestros proyectos, sino que establecía el estándar de trabajo dentro de la organización. Adicionalmente el Director de la PMO abogaba por los proyectos desde una posición jerárquica superior a la que teníamos los Gerentes de Proyectos. Y por último, las reuniones de planeación de recursos (Staffing Meeting) y la junta de la PMO, resultaron ser claves para el control del personal y para comprometer a los recursos adecuados a permanecer dentro de la fase más crítica de los proyectos.

No soy especialista en Oficinas de Proyectos, pero sí fui un usuario muy afortunado de la misma. La “protección” con la que se contaba en una PMO ofrecía la estabilidad que un Project Manager necesita para realizar su trabajo efectivamente. Los principios, las lecciones aprendidas, la metodología, los formatos, los estándares y las herramientas eran transferidos a todos los miembros del equipo de la PMO reduciendo así dificultades e incrementando las probabilidades de éxito individual de los miembros.

dynamiclifedevelopment3019.jpg Quizá en la organización a la que los apreciables lectores pertenecen, no exista una oficina de proyectos que provea dirección y facilite su gestión. Incluso quizá se haya juzgado a uno que otro buen elemento por su falta de habilidad para administrar los proyectos, pero si en una organización que maneja proyectos, los líderes de los mismos no tienen un respaldo formal y no se encuentran adecuadamente ubicado en el organigrama, es muy probable que seguirán teniendo algunos éxitos y muchos fracasos en el desempeño de sus proyectos.

Cuando un líder de proyectos le reporta a un gerente de sistemas, se convierte en un líder-de-proyectos-de-sistemas. Cuando un líder de proyectos le reporta a un gerente de operaciones, se convierte en un líder-de-proyectos-de-operaciones. Y así sucesivamente. La organización necesita líderes de proyectos con influencia en toda la organización. Un proyecto de sistemas no solamente involucrará una pieza de software, porque el software no es nada si no tiene usuarios. En un proyecto de software comúnmente se requerirá involucrar empleados de otros departamentos como mercadotecnia, servicio a clientes, operaciones, ventas, productos, calidad, etc. Un líder de proyectos debe poder dar seguimiento a todas las fases del proyecto, o como le llaman en mi organización, un enfoque end-to-end —de inicio a fin— desde la concepción hasta la operación. Cuando un proyecto se entrega, entonces se da a luz un producto y es aquí cuando ocurre el “cambio de estafeta”, de un líder de proyectos a un líder de producto que se encargará de administrar la relación con el cliente y con el equipo de operaciones que lo mantiene en funcionamiento.

Quizá como conclusión a esta reflexión, puedo decir que este es un asunto de autoridad. Si los líderes de proyecto no son investidos con la autoridad que su puesto requiere y a lo largo de toda la organización, entonces no dejarán de ser empleados de un departamento que hacen lo que el gerente de ese departamento necesita. Se perderá la visión general y será muy difícil alcanzar los objetivos globales de la compañía.

Cuando mi organización “dejó ir” a esos dos Project Managers, se deshizo de dos empleados de tecnología que, de acuerdo con la percepción general, administraban los proyectos y, a veces, los obstaculizaban. Suena injusto, ¿no es cierto?

Fernando Valdez

 

Planeando el año nuevo

Publicado el Diciembre 12th, 2011 en Planeación, Tiempo, Alcance por admin

reloj_ano_2012.jpgYo soy un planeador. Disfruto planear. Disfruto crear escenarios en mi mente y establecer rutas por las que debiera/pudiera desarrollarse un proyecto. La planeación se me facilita, surge de mi mente sin esfuerzo, empiezo visualizando el futuro y entonces empiezan a saltar los detalles… es como una fiesta de ideas, consideraciones, riesgos, métricas, iniciativas, colores, sensaciones… y al final, vislumbro el éxito, la “ceremonia de premiación”, palpo el premio en mis manos y pienso hasta dónde lo voy a colocar… Puedo documentar detalles de cada plan, puedo agendar cada detalle y hacer planes secundarios por si el original no funciona. Al final, un hermoso plan, lista de recursos necesarios y planes subsidiarios al máximo nivel de detalle… y es aquí cuando es necesario empezar a ejecutar. Ejecutar, esa es otra historia completamente diferente.

Las diferencias de planear y ejecutar

No es necesario que aborde el tema de las diferencias entre planear y ejecutar, éstas son obvias para los avezados lectores. Más bien quiero mencionar las diferencias en la perspectiva de planear y la de ejecutar.

Ejecutar es hacer realidad el plan. Si bien es cierto que el plan pocas veces puede ejecutarse exactamente como fue creado, es decir, sin cambios, también es cierto que muy pocas cosas importantes se han logrado en el mundo sin un plan. La planeación es necesaria y lo es más en un proyecto. Ejecutar es realizar las actividades que crearán los beneficios tangibles del proyecto.

Conozco excelentes ejecutores y quiero traer a colación a un ex jefe que tuve hace algunos años. Este individuo era muy eficiente, todo el tiempo estaba haciendo cosas que hicieran avanzar los proyectos. Dada su gran experiencia mucho de lo que hacía le salía bien. Los proyectos que el administraba eran ráfagas de esfuerzo coordinado entre los miembros de su equipo. Era necesario tener una mentalidad ágil y acostumbrarse a los cambios para poder pertenecer a su equipo, porque en un solo día podía cambiar la dirección del proyecto casi diametralmente. En una ocasión, en un proyecto mediano nos distribuimos las tareas y a mí me tocó construir una parte muy complicada de los entregables. Cuando me acercaba al final de las tareas y durante una revisión de los avances mi jefe cambió tanto el diseño del producto que era casi imposible reutilizar todo lo que ya se había elaborado. Por otro lado él estaba muy descontento con el lento progreso de los avances y empezaba a atribuir el rezago a la lentitud con la que se estaban construyendo los entregables. Cuando me di cuenta que caminábamos “dentro de una cueva sin luz”, dando palos de ciego, le pedí que me describiera cuál era el plan, a lo que me contestó “el plan es que termines lo que estás haciendo y lo hagas rápido”… este individuo no tenía un plan. El plan era ejecutar. Hacer, hacer y hacer, y cuando encontráramos un resultado indeseado, cambiar de dirección. Esto era prácticamente la técnica de prueba y error.

Mi ex jefe alcanzó muchas metas gracias a su determinación por completar tareas, sin embargo los recursos desperdiciados y el desgaste del equipo eran enormes.

Hago lo que me gusta

Hacer un plan es crear un mapa del terreno que se desea andar. Si lo miras con detenimiento bien podrías concluir que la planeación no genera ningún entregable utilizable por el usuario final y tienes razón. En lo personal, yo invierto mucho tiempo y disfruto planeando y proponiendo escenarios ideales para el desarrollo de un proyecto, pero en el momento de la ejecución preferiría que alguien más hiciera las cosas. Hasta en lo personal pagaría por tener a alguien ejecutando mis planes: haciendo mis llamadas telefónicas, enviando mis paquetes por correo, recogiendo los boletos, etc.

En cambio, sólo me gusta hacer aquello que disfruto haciendo. Acudo a la ley de terminar primero lo más divertido, lo que me da alguna satisfacción o incluso lo que pudiera terminar más pronto, pero seamos honestos, crear algo que valga la pena normalmente viene de la mano con realizar algunas tareas que no son muy agradables. Conocí a una persona que decía: “Me gusta solamente el 50% de las actividades de mi trabajo, pero no puedo sólo hacer la mitad de ellas. Para conservar mi trabajo necesito hacerlas todas y cuando hago aquellas que no me gustan pienso que vale la pena hacerlas por el sólo hecho de hacer las que si me gustan”. En los proyectos esto aplica también, es decir, ¿quién disfruta escalando a un miembro ocioso, asistiendo a muchas juntas, reportando avances cuando se va retrasado en el proyecto o recibiendo cambios al proyecto cuando se ha llegado a un nivel decente de avance?

team-photo-6-06-fun-one.jpg La planeación necesaria para año nuevo

Las personas solemos ponernos metas cotidianamente en las diferentes dimensiones de nuestra vida. Metas personales, de salud, económicas, laborales, sociales, etc. Algunos aprovechan el inicio de año para llamar a estas metas sus propósitos de año nuevo. Dichos propósitos suelen ser serios estatutos de aquello que se desea o se requiere alcanzar. En lo personal creo que los propósitos son el reflejo consciente de que necesitamos hacer algunas cosas en nuestra vida que no disfrutamos, porque si disfrutáramos haciéndolas ya las habríamos empezado y hasta terminado.

Algunas otras si las disfrutamos, pero conllevan esfuerzos que no estamos dispuestos a hacer, por ejemplo, salir de vacaciones. Definitivamente la mayoría querríamos unas largas vacaciones en un destino específico, pero no lo hemos logrado no por falta de interés, sino porque para lograrlo necesitamos ahorrar y es allí donde se encuentra la dificultad porque se requiere un cambio en las costumbres financieras personales y familiares.

Lo mismo ocurre en las organizaciones y en los proyectos. Necesitamos planear para diversas oportunidades que nos depara el año entrante. Estamos de cara a un año electoral en México, en otros países de Latinoamérica y en la superpotencia mundial, los Estados Unidos, y esto puede afectar directa o indirectamente a nuestros proyectos. También se ha pronosticado un crecimiento menor para el año siguiente a diferencia del que se tuvo durante el 2011, esto puede afectar también a los planes de inversión de nuestras compañías.

Los factores macro y micro económicos, los factores ambientales, los factores sociales, todo suma cuando se prepara para los proyectos. Un cambio de año es un hito que muchos utilizan para iniciar cosas nuevas, para cambiar una política de proveedores, para eliminar ciertos gastos, para incrementar algunas medidas de seguridad, etc. Todo esto pudiera afectar positiva o negativamente a nuestra organización, portafolio y/o a nuestros proyectos.

Planear todos los días como si fuera año nuevo

¿Has estado postergando alguna actividad? Es necesario respetar los hitos de nuestros proyectos y de nuestra vida en general. Si lo vemos fríamente, el cambio de año es solamente una cuestión de números en el calendario. Necesitamos planear considerando los riesgos que se avecinan y ejecutar diligentemente las actividades planeadas a menos que tenga más sentido eliminarlas del plan.

En la empresa para la que trabajo ya tenemos el plan de liberación de sistemas para los años 2012 y 2013. Ya sabemos qué fines de semana necesitaremos trabajar extra para hacer posible que los clientes cuenten con las nuevas versiones de nuestro sistema. Esto no quiere decir que no necesitaremos alguna fecha adicional o que no podremos cambiar tales fechas si es estrictamente necesario, pero ya tenemos una guía, un mapa, una idea de cómo pinta el próximo año.

Te invito a reflexionar sobre los factores que podrían influir en tu toma de decisiones el próximo año y a realizar las actividades que consideres necesarias para ampliar las posibilidades de éxito en tus proyectos. Este es un buen momento, aprovéchalo y sitúate por encima de las cosas.

Por Fernando Valdez

La importancia del inicio del proyecto

Publicado el Julio 14th, 2011 en Inicio, Alcance, Comunicaciones por admin

kickoff-meeting.jpgYo fungía como líder de proyectos de sistemas en una empresa mexicana con un portafolio de proyectos extenso. Los proyectos eran para automatizar diferentes aspectos de las áreas de finanzas, cobranza, recursos humanos, servicio a clientes, etc.

En una ocasión el director de ventas me llamó diciendo que estaba por enviarme un email con datos sobre un proyecto que necesitaba que empezáramos cuanto antes. Le dije que lo esperaría y tan pronto como colgamos el teléfono llegó el correo.

Un poco después tome los datos que este director me había enviado y lo capturé en la base de datos de proyectos y en mi revisión semanal con el gerente de desarrollo le mencioné que habíamos recibido una nueva requisición y que necesitábamos priorizarla. Después de algunos comentarios al respecto mi jefe dijo que se comunicaría con el director para discutir prioridades y que después me comentaría como procederíamos con ese requerimiento.

Las especificaciones

El director había sido muy específico en sus requerimientos, mismos que definió a través de su gerente de ventas de la zona norte, así que el documento (por email) tenía especificados muchos detalles hasta con dibujos de pantalla (mock-ups o screen-shots). Al final del correo tenía una estimación de lo que ellos pensaban que debería tomar el desarrollo de ese proyecto. La estimación tenía mucho sentido, dado que el trasfondo de aquellos individuos, el director y el gerente, era de gente de Tecnología de Información.

El pre-análisis

Nosotros no empezamos a desarrollar el proyecto de inmediato, sino que fuimos terminando algunos otros pendientes y de vez en cuando nos reuníamos con ellos para ir esbozando los requerimientos y conociendo las necesidades para decidir acerca de la tecnología a usar.

Cuando los miembros del equipo se liberaron por completo, entonces nos dedicamos un poco más a juntarnos con los gerentes y supervisores para entender y levantar formalmente los requerimientos y después de una semana de hacer esto, el director preguntó si ya íbamos a acabar. El esperaba ver más de la mitad de los entregables implementados a esas alturas.

Cuando le dijimos que apenas estábamos terminando de documentar el análisis el director se incomodó y escaló el problema con mi jefe y con el jefe de mi jefe. Ellos le preguntaron que si había un email o documento en el que yo me comprometía para llevar ese avance en esa fecha, pero el mostró el primer email que me había enviado y mi respuesta allí decía que íbamos a empezar el proyecto tan pronto como revisáramos las prioridades del departamento y asignáramos los recursos. Adicionalmente le daba el número de folio de su requisición que ya había sido dada de alta en el sistema para control de proyectos. De tal manera que no tenía ningún compromiso documentado de mi parte, sólo tenía un par de correos y evidencia de algunas reuniones con otro personal, sin embargo, para el, eso era suficiente como para considerar el proyecto iniciado.

¿Por qué es importante un arranque formal del proyecto?

Un director ha llegado hasta allí por saber tomar decisiones con poca información o por haber desarrollado esa capacidad, el problema es que ellos esperan lo mismo de los que interactúan con ellos. Cuando un director da una orden, normalmente espera que se ejecute de inmediato y espera revisar métricas del desempeño de inmediato.

Hay directores expertos en Project Management, pero no estoy hablando de ellos ahora, ellos seguramente entenderán lo que se requiere para iniciar, planear, ejecutar, controlar y cerrar un proyecto. Yo hablo de aquellos que no tienen dicha preparación, para ellos es necesario un “trato especial”.

Comunicación

Es necesario comunicar cada estado en el que se encuentra el proyecto. Que el director tenga o no tenga experiencia en proyecto o que su estilo sea pedir y esperar de inmediato que todos se pongan a trabajar no es un defecto, es sólo una forma de trabajar. Es responsabilidad del líder de proyectos el comunicar en que etapa del análisis, diseño, desarrollo o control se encuentra el proyecto. Incluso si el proyecto se encuentra en una fase tan temprana como lo es su inicio, es necesario que lo comuniquemos.

El verdadero inicio del proyecto

El PMI® menciona en el PMBOK® que el inicio del proyecto nunca se tiene puntualmente definido en una sola fecha. Esto se refiere a que un proyecto puede nacer en un elevador mientras dos personas platican, por ejemplo, que “sería bueno que implementáramos un control de ventas más eficiente”. Más adelante, tomando este mismo ejemplo, estas dos personas podrían reunirse para comentar un poco más sobre ese asunto. Posteriormente podrían existir algunos correos yendo y viniendo acerca del mismo tema. Y de esta forma podría haber muchas otras comunicaciones que dieran lugar, por ejemplo, a un sistema de información que derivara de aquella iniciativa y que ese sistema de información fuera administrado como un proyecto. De tal forma que tiene sentido lo que el PMI® menciona cuando dice que un proyecto en ocasiones no tiene muy clara su fecha de inicio.

Para el equipo del proyecto, este debería “nacer” en el momento en el que se los involucra en el mismo. Cuando hay una estructura o cadena de mando aquella persona que es contactada para hacerse cargo del proyecto es la responsable de comunicar su progreso o delegar esta función a quien se hará cargo del mismo. Si bien el proceso de aprobación del proyecto o de revisión del portafolio y priorización de proyectos pudiera tomar algo de tiempo, es responsabilidad de la oficina de proyectos o del Líder del Proyecto el comunicar el estatus actual.

El problema

En muchas organizaciones no se tiene una Oficina de Proyectos que administre el portafolio, pero en cambio se tiene una gerencia que administra las operaciones y asigna responsables a los diferentes proyectos de acuerdo a diversos criterios como lo son línea de negocios, cargas de trabajo, etc. De tal forma que en algunas organizaciones nos encontramos con varios líderes de proyectos dependiendo de un gerente quien les asigna el trabajo y estos, hasta cierto punto, administran su propio portafolio que comúnmente consta de 10, 20 ó 30 proyectos que están esperando por prioridad y recursos para ser desarrollados.
La vida del líder de proyectos es agitada: preparar reuniones, asignar recursos, conseguir esos recursos, lidiar con ausencias de personal, ajustar el cronograma, monitorear el registro de riesgos, dar seguimiento a la lista de problemas (issue register), etc. Son algunas de las actividades que pueden mantener el día de un líder de proyectos totalmente ocupado.

Sin embargo, si se encuentra en la necesidad de administrar un subconjunto del portafolio de proyectos de la compañía o del departamento, es necesario que agende periódicamente un tiempo para la revisión de ese portafolio de proyectos que tiene asignado y que comunique el estado actual de los proyectos a los patrocinadores correspondientes.

Saca la cabeza del lodo

Un buen amigo mío y mi jefe en aquel entonces solía decirme “necesitas sacar la cabeza del lodo y respirar”. Efectivamente, para vivir necesitamos respirar. La respiración, que traducido a nuestra profesión representa los tiempos de evaluación, introspección, descanso, planeación  y liderazgo, proporciona a la vida de un líder de proyecto la perspectiva necesaria para resolver los problemas creativamente y también proporciona el tiempo necesario para comunicar los avances de los proyectos, aún cuando éstos no hayan iniciado todavía.

El fin de la historia

El proyecto de aquel departamento de ventas fue iniciado más adelante, después de haber aclarado y comunicado una serie de expectativas a sus patrocinadores.
Dimos un inicio formal al proyecto con la conducción de una reunión de kick-off a la que invitamos a los patrocinadores y a nuestro gerente, así como a los usuarios y nuestro equipo de proyecto. Las actividades que ya habíamos hecho las llamamos pre-análisis y esta etapa la definimos como necesaria para familiarizarnos con la idea que íbamos a transformar en un producto.

Ese fue el inicio real del proyecto desde nuestra perspectiva. Aún cuando el director de ventas pensaba que ya íbamos tarde, nosotros nos esmeramos en comunicar los progresos del proyecto y al final y después de algunas actualizaciones naturales del cronograma el proyecto terminó dando a luz un producto utilizable para ese departamento.

Conclusión

El inicio del proyecto muchas veces es impreciso, pero consideraremos que el proyecto inicia desde el momento en que somos asignados a él.

El líder de proyecto es responsable de la comunicación de un proyecto aún cuando no haya sido iniciado formalmente.

Iniciar formalmente el proyecto es importante, reduce incertidumbre, establece expectativas y le comunica al cliente o usuario que a partir de ese momento empezarán los esfuerzos por parte del equipo (no antes).

Hay que reservar tiempo a la semana para actividades de liderazgo. Este tipo de actividades ocasionalmente son momentos de preparación, reflexión, convivencia con el equipo, comunicación y replanteamiento de lo que se está viviendo en el proyecto.

Por Fernando Valdez

Un proyecto en aprietos

Publicado el Marzo 15th, 2011 en Inicio, Planeación, Alcance, General por admin

aprietos.jpgHace poco vino un colega para pedirme consejo con respecto a un proyecto al que acababa de ser asignado. Al parecer el proyecto no era nuevo, era un proyecto que ya había fracasado y ésta era la “segunda vuelta” que iban a dar, pero con algunos cambios, entre ellos, el contratar a un Administrador de Proyectos profesional a quien pedirían cuentas sobre los resultados del proyecto.

En cuanto llegó le pedí que me explicara cómo les había ido en el primer intento y, de acuerdo a lo que le habían comentado, el me relató lo siguiente:

Entorno del proyecto
Se trata de una escuela que quiere ampliar sus servicios educativos para que los alumnos de preparatoria tengan otros medios de ponerse al corriente con clases que no tomaron o que quisieran repasar. El director y el consejo escolar planearon tener un sistema computacional que les permitiera tomar las clases sin necesidad de un instructor.

Debo mencionar que me interesó mucho el caso porque tocaba tres de mis puntos fuertes: Sistemas Computacionales, Project Management y la industria del aprendizaje asistido por computadora (e-Learning).

De manera que le pedí que me comentara cuales habían sido las acciones que el equipo de proyecto había emprendido antes de llamarlo a él para apoyarles, y el continuó diciendo:

Creación del equipo de proyecto
El director de la escuela armó un equipo para abordar el proyecto. Viendo la necesidad de crear material didáctico eligió a cuatro profesores y un líder de proyecto.

Definición de alcance del proyecto, roles y tiempos
El equipo se concentró originalmente en definir el alcance del proyecto y aclarar todas las dudas que tuvieran con respecto a lo que se haría. Después invitaron al director para que estableciera las prioridades de las actividades, así como para solicitar su apoyo y para motivar a los participantes de este esfuerzo ya que todos los miembros del equipo continuarían con sus actividades normales y, además, estarían desarrollando los entregables del proyecto.

Los integrantes del equipo definieron horarios en los que trabajarían en este esfuerzo y definieron el número de cursos a desarrollar, que se estableció en 18 cursos.

En las primeras reuniones también se detectó que ninguno de los participantes tenía experiencia previa en el modelo de aprendizaje automatizado, si bien eran expertos en la enseñanza y preparación de material, nunca habían participado en un proyecto en el que tuvieran que implementar el marco tecnológico necesario, por lo que decidieron contratar a una empresa que les apoyara con esta parte de los entregables.

Finalmente, el equipo de proyecto definió la fecha de entrega de los cursos para tener un marco de referencia del fin del proyecto.

Inicio del proyecto
El proyecto arrancó con la asignación de algunos maestros adicionales para que apoyaran con la elaboración de los cursos. Los consultores definieron los formatos en los cuales los maestros pondrían la información de acuerdo a su experiencia docente. Adicionalmente los consultores capacitaron a los profesores en el uso de la plataforma tecnológica a emplear para el proyecto.

Desarrollo del proyecto
Los profesores empezaron a desarrollar los cursos por separado y cuando terminaban se los enviaban al equipo del proyecto para que estos los revisaran y aprobaran. Los consultores continuaron apoyando con respuestas a las dudas sobre el uso de la plataforma y cargando archivos en esta.

Durante el tiempo designado los maestros elaboraron los materiales de los cursos hasta terminar. Cuando enviaron los materiales para revisión, el equipo de proyecto notó que aunque todos usaron la misma herramienta para elaborarlos, los cursos no eran uniformes, algunos eran apropiados y apegados a los objetivos del aprendizaje y otros no lo estaban en lo absoluto. Algunos tenían una buena presentación mientras otros no la tenían.

Cambio de rumbo
El líder del proyecto solicitó la presencia del director de la escuela para conocer su opinión y éste determinó que el material creado no cumplía con los objetivos del aprendizaje del alumno y solicitó que le agregaran características de animación y mejores transiciones entre las diapositivas para facilitar el aprendizaje.

Tomando lo anterior como un nuevo rumbo para el proyecto se calcularon las implicaciones y se determinó que la entrega del proyecto se retrasaría, el costo de la consultoría se elevaría y se requeriría que los maestros trabajaran horas extra en el material que ya habían realizado (re-trabajo).

En búsqueda del culpable
Cuando se evaluaron estas implicaciones y se revisaron los cambios presupuestales se intentó encontrar dónde había estado el problema. Los maestros le echaron la culpa a los consultores porque éstos no les estaban dando toda la información acerca de la plataforma que estaban operando. Los consultores le echaron la culpa a que había habido un cambio en el alcance del proyecto. El equipo original del proyecto argumentó que el problema era que no se había ofrecido una compensación monetaria para los maestros por haber trabajado específicamente en ese proyecto. Alguien más argumentó que el problema estaba en el proceso y que era necesario establecer más y mejores puntos de revisión en el mismo.

En ese momento el director autorizó la contratación de un Project Manager externo para hacerse cargo… así es, ese era mi amigo.

¿Te suena familiar este caso?
Desafortunadamente hoy en día todos, y no me da miedo generalizar, todos nos enfrentamos a proyectos de algún tipo, con poca o nada de preparación para enfrentarlos (administrarlos).

Mi amigo es un PM novato y afortunadamente el proyecto que dejaron en sus manos es un proyecto pequeño.  ¿Qué le habrías aconsejado?, ¿por dónde empezar?

Con respeto a tus propias opiniones me permito comentarte lo que yo le sugerí.

Mis preguntas
Antes de recomendar nada, le hice a mi amigo un par de preguntas. La primera de ellas fue: ¿Tienes un Project Charter? La constitución del proyecto o Project Charter es un documento en el que se esboza información importante del proyecto en términos del alcance, tiempos, involucrados, pero sobre todo, se establece claramente  la autoridad que adquiere el Project Manager sobre el equipo del proyecto y lo responsabiliza de tomar las decisiones que favorezcan a que el proyecto se termine dentro de las definiciones de alcance, tiempo, costo y calidad. Este documento, que debe estar firmado por el director de la escuela también sirve para definir el rol del director y otros interesados.

Mi segunda pregunta fue: ¿Tienes un WBS? La estructura de descomposición del trabajo o Work Breakdown Structure (WBS) es un documento que ayuda a descomponer el objetivo final del proyecto en partes más pequeñas y manejables y que puede ser usado no sólo para la planeación del proyecto, sino para el seguimiento, la presentación de avances y la definición de los responsables de cada paquete de trabajo. Con un WBS puedes saber cuánto costará el desarrollo de cada entregable y cuanto se retrasara el proyecto si una tarea se retrasa.

Desde luego que hay muchas otras herramientas que ayudan en la organización de un proyecto, pero para este caso y en general para proyectos pequeños elaborados en organizaciones informales o donde se tiene poco conocimiento del control de proyectos, estas dos herramientas son vitales. Los beneficios que traen, entre otros, son los siguientes:

  • Establece jerarquía dentro del equipo de proyecto
  • Comunica los acuerdos con respecto al alcance del proyecto
  • Define responsables por cada parte del proyecto
  • Identifica la parte emproblemada del proyecto

Adicional a estas dos herramientas yo agregaría un nivel mayor de detalle en las expectativas de calidad de cada curso. Hay tantas formas de hacer las cosas como participante en las actividades del proyecto, así que se requiere un estándar como punto de partida. La verificación de la calidad en los sistemas es muy sencillo, sólo es necesario establecer a un nivel aceptable de detalle cuales son las expectativas del usuario o cliente y verificar que el producto final cumpla con ellas.

Si se cuenta con las herramientas adecuadas de trabajo, seguramente se contará con un sistema que ayude en la elaboración de WBS y que permita agregar especificaciones por cada entregable, de tal manera que no se requeriría otra herramienta, sino solamente una disciplina por agregar la información allí y mantenerla vigente a lo largo del proyecto.

Aún más, debe establecerse un proceso de integración de cambios, esto es, un procedimiento por el cual se detalle cómo vamos a proceder cuando haya un cambio solicitado para alguno o varios de los entregables del proyecto. Comúnmente este proceso luce así:

  1. Un usuario solicita un cambio
  2. El cambio se recibe en un formato específico
  3. El cambio se evalúa y se pronostican los cambios en el enunciado de alcance, duración del proyecto y costo
  4. Se procede a la autorización del cambio.
  5. Si el cambio es autorizado por el equipo ejecutivo del proyecto, se integran los cambios en el WBS, Enunciado de Alcance, Cronograma, Documento de Riesgos, etc.
  6. Si se rechaza, se notifica a los interesados.

Mi amigo estaba muy bien familiarizado tanto con las herramientas como con los procesos a implementar, así que no fue difícil que supiera cuál era el siguiente paso a dar. Sin embargo me hizo una observación: “Cuando dominas las herramientas y técnicas de administración de proyectos es fácil caer en la tentación de establecer todo un complicado proceso de administración de proyectos cuando lo que necesitas es abrir los canales de comunicación, definir los roles y las responsabilidades de la gente y documentar los acuerdos de manera formal”.

¿Cuántas veces hemos sobredimensionado un proyecto sólo para hacer uso del software de administración de proyectos en el que nos acabamos de certificar?, ¿o sólo para implementar la metodología que utiliza aquella súper compañía que ha sido exitosísima a nivel mundial?

La administración de proyectos parte de la necesidad de hacer que el proyecto sea exitoso y es un medio para lograrlo, no el fin último de un proyecto. Si en el futuro te encuentras con un reto de este tipo o más complicado, te invito a contestar las siguientes preguntas: ¿Cuál es el objetivo final del proyecto?, ¿Qué puedo hacer para ayudar a conseguir el objetivo del proyecto?, ¿Cómo puedo usar mis habilidades y técnicas en administración de proyectos para conseguir el resultado esperado?

¿Qué recomendaciones le darías a mi amigo para la etapa de ejecución, control y cierre de su proyecto?

Por Fernando Valdez

“Entregar” como una filosofía de trabajo

Publicado el Septiembre 30th, 2010 en Alcance, General por admin

Nuestra filosofía es hacer lo que dijimos que íbamos a hacer. Nuestra filosofía es “nosotros entregamos”. Sin peros, simplemente nosotros entregamos. Entregamos lo que dijimos que entregaríamos. No menos. No de menor calidad. Ni un día después. Lo que pase tras bambalinas es nuestro asunto, no es asunto del cliente, no nos hacemos los mártires. No hacemos que el cliente sufra nuestras carencias o defectos. Para nuestro cliente cada individuo representa la compañía y el desempeño que mostremos es la imagen del desempeño que el tendrá de la compañía. Cuando ellos se llevan una experiencia buena no mencionarán mi nombre, ellos simplemente recomendarán trabajar con nuestra compañía.

Si yo entrego a tiempo está bien, no merezco ninguna medalla porque simplemente me pagan por hacer eso. Ellos no me pagan para ser buena gente ni me pagan por hacer mi mejor esfuerzo… la expectativa que tienen de mí es que entregue lo que me comprometí a entregar.

Estábamos a punto de iniciar un proyecto en la compañía que recién nos acababa de contratar. Se trataba de un experimento, la compañía había recibido referencias de que en México podría encontrar mano de obra barata y con una cultura similar a la de los estadounidenses y teniendo base en la ciudad de Dallas, Texas la compañía podía ver adicionalmente la ventaja de encontrarse a menos de hora y media de la ciudad de Monterrey y en la misma zona horaria.

Así que contrataron desarrolladores de software, ingenieros de calidad, arquitectos y a un servidor como Project Manager. Debo confesar que hasta entonces y por más de 10 años había jugado el rol de Líder de Proyectos y Coordinador de Proyectos, pero nunca había sido totalmente ‘accountable’ (la traducción literal en español es ‘responsable’, pero este término en español no describe totalmente lo que la palabra accountable quiere decir para los Norteamericanos, en pocas palabras accountable quiere decir que ‘tu cabeza rodará si algo sale mal’) del éxito o fracaso de un proyecto. No quiero decir que como Líder de Proyectos no tengas ese nivel de responsabilidad, lo que digo es que en México la estructura predominante en las compañías es Funcional y si bien los Coordinadores, Jefes y Líderes tienen responsabilidad, la verdad es que los Gerentes Funcionales y Directores cargan con más de esa responsabilidad, cosa que no es así en Estados Unidos.

Como sea, estábamos empezando el proyecto y muchos compañeros de Estados Unidos me comentaron lo grande e importante que era ese proyecto pero nunca pensé que sería tan retador. A pocas semanas de haber sido asignados ya nos encontrábamos llenos de trabajo y haciendo esfuerzos más allá de lo posible para alcanzar los objetivos propuestos en el tiempo indicado. Habíamos sufrido un cambio en la arquitectura del sistema cuando ya llevábamos un valor ganado del 50%, de tal forma que mucho trabajo se desperdició (en otro post les compartiré cuál fue la razón de la re-arquitectura). Finalmente, el cliente preguntó si tendríamos completado el alcance para la fecha indicada y, acostumbrado a una filosofía del “no se puede”, esperaba que el Vicepresidente de Tecnología, a sabiendas de todos los esfuerzos que estábamos haciendo, dijera que no veía factible nuestra entrega, se limitó a mencionar la cantidad de retos que nuestro grupo había superado y que estaba seguro que podríamos continuar con esa racha para entregar en la fecha en que prometimos entregar.

Al principio esto me sonó a explotación y pensé que había sido la respuesta incorrecta, después de todo, los gerentes y directores con los que había trabajado antes se conformaban con un “necesito más tiempo”, “necesito más recursos”, “recórtame el alcance del proyecto” o cualquier otra forma de estas tres excusas anteriores. Me dolía la mente de sólo pensar en esa respuesta, pero lo que estaba ocurriendo en mi mente en realidad es que se estaban rompiendo paradigmas… y eso dolía.

No quiero confundirlos diciendo que tenemos que esclavizarnos en el trabajo cuando la culpa no es nuestra, pero afrontémoslo, vivimos en una cultura de esfuerzo mesurado y cualquier cosa que amenace los límites que hemos impuesto se convierte en un enemigo. Creo firmemente en la calidad de vida, en la socialización y en el balance entre trabajo y familia, pero también creo en el esfuerzo, aunque de vez en cuando este tenga que retar nuestros propios límites. Cuando un músculo es llevado al límite de lo que puede cargar, las fibras musculares se rompen y “aprenden” que, si crean una fibra igual de resistente, nuevamente se volverá a romper y entonces “deciden” hacer una fibra más gruesa, una cicatriz abultada de músculo que les permita resistir más peso… eso duele, pero genera un crecimiento del músculo y, por ende, un crecimiento en la capacidad de carga. Al mismo estilo mi mente dolió pero en lugar de pensar en formas para evitar el trabajo empecé a ser creativo para lograr, por medio de la gente, todos los objetivos en el tiempo indicado.

Al final terminamos el proyecto a tiempo. Tuve que negociar diferentes cosas con cada uno de los miembros de mi equipo. Yo era el primero en llegar y nunca me fui de la oficina antes que ellos, me levantaba de mi lugar con frecuencia para ver si podía ayudar en algo al equipo local y tenía llamadas a USA por horas para coordinar esfuerzos con el equipo de allá (estaba virtualmente allá). Iba por la pizza en la noche y por el café en las mañanas, nunca dejé a mi equipo solo… después de todo ellos harían que esa hazaña fuera una realidad.

Si adoptamos esta filosofía de trabajo nuestra reputación como alguien que entrega se incrementa y esto se traduce en más y mejores proyectos, proyectos con mayor complejidad, proyectos de mejores clientes, proyectos para crear productos, servicios o resultados únicos. ¿Cuál es el beneficio de esto? Bueno, si eres una persona que sabe invertir a mediano y largo plazo entonces ya puedes empezar a pensar en los grandes beneficios que esta filosofía puede traer más allá de la satisfacción personal y aumento de nuestra autoestima profesional: Nos hará aspirar a mejores oportunidades de empleo.

Poco después hubo un cambio en la estructura organizacional y la Oficina de Proyectos a la que yo le reportaba fue movida a otra rama de la compañía. Recibí una llamada del Vicepresidente de Tecnología diciéndome que tenía planes de expansión para el equipo de México al grado de cerrar cada posición técnica en USA e India y mover todas las operaciones técnicas a nuestra ciudad.  Pero lo mejor de la llamada fue la oferta que me extendió para ofrecerme quedarme al cargo de todo el grupo y no sólo de un equipo de proyecto. Yo le argumenté que mi especialidad eran los proyectos y que hasta una certificación de PMP tenía, pero que el manejo de gente, comunicaciones  y cuestiones administrativas no era mi fuerte y el sólo dijo, “lo sé, pero tú ‘entregas’, eres un gran líder”.

No importa si estás al cargo de grandes proyectos técnicos o pequeños proyectos administrativos, cuando tu filosofía de vida es “entregar no importando qué”, la imagen que los demás tienen de ti se eleva y todos saben que ese patrón de éxito puede repetirse en futuros proyectos y/o en futuras posiciones de mayor responsabilidad.

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.