Vientos de cambio

Que tal,
Dado que las necesidades de nuestros lectores han ido cambiando (y las mías también), voy a cambiar un poco el formato de estos posts.
Normalmente publico Lecciones APrendidas que obtengo durante mi gestión com PM (Project Manager / People Manager) y procuro hacerlo al menos una vez al mes. Sin embargo tenemos algunos lectores que están por presentar su exámen de certificación para convertirse en PMP y estos tienen necesidades diferentes.
Definitivamente no voy a convertir este blog en un sitio de conceptos del PMBOK, pero voy a tratar de alternar una Leccion APrendida y alguna capsula teórica, una recomendación o una mejor práctica (best practice). Estas últimas serán recopilaciones de mi experiencia, pero en un formato mucho mas breve.
Espero que el cambio les agrade y me permita aumentar la frecuencia de publicaciones que hoy en día está muy (muy muy) espaciada.
Buen día y ¡Saludos!

Fernando Valdez, PMP

Seguimiento...

No estoy seguro si en otras versiones del idioma español se diga "seguimiento" a la acción de verificar que un plan se esté ejecutando de acuerdo con lo previsto en términos de tiempo y compromisos (amigos de Argentina, España, Costa Rica y demás países de habla hispana, ayudenme aquí), pero la idea central de el título de este post es hacer referencia a una de las razones por las que muchos proyectos fallan.
En mi experiencia como Project Manager me he dado cuenta de que en algunas empresas el seguimiento que se le da a los compromisos en muchas ocasiones es informal y en otras es mucho mas formal.
Recuerdo haber participado en reuniones de definición de requerimientos en una compañía en las que se decía mucho, se apuntaba poco y se le daba seguimiento solo a aquello que realmente se había convertido en un problema urgente. En ocasiones se hacían minutas de la junta y ya. En otras ocasiones, al pasar de las semanas desaparecía el envío de minutas y se cancelaban las reuniones de seguimiento. Cuando surgía una situación de mayor prioridad, el asunto original se olvidaba y se desviaba la atención hacia el problema urgente, pero no se documenta formalmente hasta dónde se llegó o por cuanto tiempo se estará suspendiendo el primer asunto, ni se definía con qué nueva frecuencia se dará seguimiento a ese proyecto.

Tuve una experiencia en un proyecto con una compañía de USA en la que organicé una reunión diaria de avances (30 minutos de duración) dado que se había puesto en producción un sistema que aún presentaba algunos problemas funcionales. A la reunión asistían un VP (Vice-Presidente) dos directores y dos gerentes. Me correspondía el "honor" de organizar la reunión y comunicar los avances que se habían logrado en las 24 horas anteriores a la reunión.

Debo confesar que durante ese mes y medio que duró esa reunión diaria no fuí el Project Manager más feliz de la compañía.

En cada reunión iniciabamos puntualmente y revisabamos los pendientes discutidos en la reunión anterior y su status actual. Continuábamos tomando nuevas decisiones sobre esos pendientes aún abiertos y se solicitaba a los usuarios cerrar los pedientes que habían llegado a conclusión. Luego se trataban los nuevos problemas detectados y su status. El grupo priorizaba su orden de atención y por último se comentaban asuntos generales como días inhábiles en este o aquel país.

Durante mes y medio administré esa reunión que en ocasiones era asaltada por un solo tema de mayor importancia (afectaciones masivas a usuarios, etc.).

Después de cada reunión me correspondía registrar cualquier cosa nueva que no estuviera en nuestro resumen de pendientes (normalmente uso una hoja de MSExcel para esto) y continuaba alineando a los diferentes equipos hacia alcanzar los objetivos. El resto del tiempo antes de la siguiente junta los miembros del equipo avanzaban en su trabajo, nos comunicabamos para comentar cualquier problema, envíabamos correos y todo era en relación a lo comentado en la reunión de ese día. A veces tomábamos decisiones acerca de mantener algunos miembros del equipo trabajando por horas extra para poder entregar un status mas favorable en alguno de los asuntos prioritarios en la siguiente reunión, etc.
Finalmente se llegaba la víspera de la siguiente reunión, me reunía con el equipo para revisar avances, problemas, riesgos, retrasos, etc. alimentaba mi hoja de pendientes y listo, a la reunión. Y volvía a empezar el ciclo.

Con el tiempo decidimos que esa reunión dejara de ser diaria y pasó a tener lugar tres veces a la semana, luego dos veces por semana y actualmente solo nos reunimos cada 15 días para comentar sobre la operación del sistema. Yo no coordino esa reunión porque mi puesto es Project Manager (un Proyecto tiene un inicio y un fin bien definidos, la operación del producto resultante le corresponde a un gerente de operaciones), pero aún sigo siendo invitado dado que en otro momento de la historia estuve ampliamente involucrado.

En fin, mi idea es compartir con Ustedes esta nueva experiencia que adquirí acerca del seguimiento de los proyectos.

No siempre es necesario sostener reuniones diarias, de hecho es un tanto excesivo, pero este caso lo ameritaba. Mi decisión por hacer esto es porque había mucho en juego y los ejecutivos querían asegurarse que todo estuviera siendo considerado. Normalmente se pueden tener reuniones de seguimiento con gerentes (managers) de manera semanal y con directores y VPs de manera mensual.

Para aquellos interesados en referencias al PMBOK, en este post se cubrí algunas actividades de Ejecución y Monitoreo del proyecto, por favor refiéranse a los procesos 4.4, 4.5, 8.3, 9.4, 10.2, 10.4, 11.6 para mas detalle en lo que se debe hacer (PMBOK 3ra edición).

Gracias por detenerse a leer este post, les envío un caluroso saludo invernal (en el hemisferio norte, por supuesto). Saludos!

Fernando Valdez
[LAP]

Feliz año nuevo

Que tal,
En esta ocasión me dirijo a los lectores (que ya no han de ser muchos dada mi ausencia) para desearles un feliz año nuevo.
Dada mi última experiencia laboral, he entendido que existe una grán diversidad de razas, religiones, culturas, etc. y que en ocasiones es difícil hacer llegar un mensaje sin que estos factores (raza, cultura, religión, etc.) generen ruido en el mensaje. Habrá quienes celebren esta fecha (fin de año) y habrá quienes no lo hagan, pero lo que es universal y no tiene género, cultura, etc. es el sentimiento que se desea comunicar.
Dicho esto y para ponerlo en términos mas prácticos, sea que celebres año nuevo o no, mis deseos es que tengas felicidad y fuerzas renovadas en este año que comienza. Un año solo es una etapa de la vida, como en un proyecto. Al final de cada "etapa" es bueno hacer un "phase gate" en la que se pueda revisar el "desempeño" del equipo del proyecto, el desempeño del presupuesto, el desempeño del calendario (schedule), incluso es un buen tiempo para actualizar los indicadores de estos últimos dos (CPI (cost performance indicator) y SPI (schedule performance indicator) respectivamente).
Te invito a hacer una revisión de fin de fase de tu proyecto de vida y a ajustar los indicadores si es necesario. Los propósitos son el equivalente a los hitos (milestones) del proyecto, así que no olvides revisar qué tanto avance llevas y replantear aquellos que no parecen ser alcanzables.

Un propósito (hito) sin fecha de cumplimiento sólo es una buena intención.

Como sea, deseo que tengas un feliz año nuevo y que empieces 2009 excelentemente.
Por mi parte estaré tomando todo el tiempo posible para continuar esta comunicación y que mis dos lectores :) sepan que sigo vivo.
Saludos!
Fernando Valdez

Con criterio de Project Manager

El tiempo ha llegado en que el producto final de nuestro proyecto sea entregado al cliente, pero dado que experimentamos literalmente cientos de cambios en la definición y dado que nunca fue autorizado un cambio en la fecha de entrega, el producto final se redujo a contar con un porcentaje de la funcionalidad original.
Permítanme hacer un paréntesis con respecto a esto.

Hace tiempo, cuando trabajaba en otra compañía, acostumbraba bromear con los clientes acerca de los entregables y les decía: “Normalmente solo puedo satisfacer dos de las tres variables siguientes: Costo, Calidad y Tiempo… Si necesitas que el proyecto acabe rápido, probablemente tendremos que sacrificar la calidad y/o tendrás que pagar más. Si necesitas que salga rápido Y barato, entonces no tendrá mucha calidad. Si requieres que el producto tenga mucha calidad pero a bajo costo, entonces nos vamos a tardar en entregarlo”. Haz las combinaciones que quieras… aquellos que han trabajado en proyectos me podrán entender.
En Project Management se habla de la muy conocida triple restricción: Tiempo, Alcance y Presupuesto (o recursos). Comunmente encontramos un diagrama con un triángulo equilatero en el que cada una de las tres palabras (restricciones) se encuentran dibujadas en cada vértice del triángulo o en cada lado (como la imagen que anexo). La lectura a este diagrama es la siguiente: el Director del Proyecto debe asegurarse de que el cliente reciba todo lo que se prometió usando solamente el presupuesto establecido y dentro del tiempo estipulado al inicio del proyecto. En referencia al triángulo existe otra palabra, pero esta va al centro del mismo, y esa palabra es Calidad. Cualquier cambio en una de esas variables impacta a las otras y por ende a la calidad.
De tal forma que antes no estaba tan equivocado con mi broma de las tres variables, pero mi enfoque era incorrecto: si quieres ser un profesional deberas entregar todo dentro de las tres restricciones y no solo dos.

Regresando al tema de este post (después de un largo paréntesis), nuestro equipo fue restringido en tiempo, pero nos liberaron la variable del presupuesto, de tal forma que podíamos agregar más gente al proyecto (incurriendo en más gastos) pero deberíamos entregar en el mismo tiempo acordado. También acordamos entregar un núcleo de funcionalidad básico que satisfaciera las necesidades más apremiantes y que en versiones posteriores del producto podríamos entregar el resto de la funcionalidad.
Entregamos el producto para ser probado por el usuario antes de pasar a una etapa de uso definitivo. Una vez que el usuario empezó a hacer uso de su nueva herramienta empezó a retroalimentarnos con respecto a la funcionalidad. Empezamos a manejar largas listas de issues y tuve la necesidad de reportar diariamente el status individual de cada problema. Estas revisiones duraron semanas antes de empezar a reducir la frecuencia de la revisión.
En ocasiones, como Gerente del Proyecto me ví reducido a un Administrador de Problemas y eso no me agradaba. ¿Qué había de aquellos gráficos de Gantt y de la administración de los recursos? ¿Cómo se relacionaba mi trabajo actual (perseguir desarrolladores de sistemas en busca de status y de la solución de los problemas) con el Team Development, Project Procurement y Earned Value? ¿Qué tenía que ver mi junta diaria de quejas del cliente con el Risk Monitoring Control, el Cost Budgeting o el Performance Reporting?
En un momento dado hice un alto para reflexionar porque parecía que nunca iban a dejar de salir problemas y que nunca terminaríamos con esas estresantes reuniones de status en las que reportábamos 5 pendientes resueltos y me avisaban de 10 más.
Estas son las lecciones que aprendí una vez que salí de mi momento de introspección.

1. Si el cliente pudiera resolver su problema el mismo, no te hubiera buscado.
2. Cuando un cliente te elige para resolverle su problema, su problema se convierte en tu problema y debes resolverlo como si fueras el.
3. Independientemente de lo que se hizo bien y de lo que se hizo mal, hoy te encuentras en una situación que tienes que afrontar, asegúrate de hacerlo con el criterio adecuado: si eres desarrollador de sistemas, afronta tu situación como desarrollador de sistemas; si eres Gerente de Proyectos, afronta tu situación como Gerente de Proyectos.

Inmediatamente dediqué un recurso a buscar defectos en nuestro producto de manera proactiva (Quality Assurance) para no esperar a que el cliente los encontrara – así eliminamos la ansiedad y redujimos la molestia del cliente.
Saqué de mi mente los problemas de bajo impacto y baja prioridad – eso me dio “oxígeno psicológico” y pude pensar mas claro.
Una vez dominados los problemas existentes, regresé a mi lista de entregables (WBS) y a la definición de calidad que había definido para cada uno de ellos. Verifiqué que estuvieramos cumpliendo con todo como lo habíamos prometido (Quality Plan).
Hice una agenda de fechas en las que estaríamos atendiendo cada issue mayor (Schedule) e hice un estimado para su completación (Estimate To Complete).
Así fue como llevé mi aburrida tarea de administración de problemas de regreso al campo del Project Management. Nuevamente y a manera de conclusión, si vas a administrar problemas, asegúrate de hacerlo con criterio de PM. Si te toca hacer un post en un blog, asegúrate de hacerlo con criterio de PM. Si estás planeando tus vacaciones, asegúrate de hacerlo con criterio de PM. Esto hace más probable el éxito y hace todo mas divertido.

Palabra final: Si no te gustan los proyectos con problemas, entonces estás en la profesion equivocada: Un cliente nunca viene a darte soluciones, dinero, beneficios o a invitarte a pasar buenos ratos, el cliente siempre llega con un problema que requiere solución completa, rápida y barata.

Factores ambientales dentro del proyecto

Cuando trabajaba en una compañía pequeña en la que la mayoría de las cosas eran predecibles, para mi no tenía mucho sentido el "distraer" tiempo del proyecto en pensar qué factores ambientales de la empresa podían afectar a mi proyecto.
Cuando hablo de factores ambientales de la empresa, me estoy refiriendo a aquello que el PMBOK(1) describe en la página 83. Cito textualmente al PMBOK en su "definición" (para aquellos que no cuenten con una copia del PMBOK): "...se deben tener en cuenta todos y cada uno de los factores ambientales de la empresa y de los sistemas de la organización que estuvieran relacionados con el éxito del proyecto o pudieran influir sobre él de alguna manera."
En la compañía en la que trabajo actualmente iniciamos un proyecto de desarrollo de software en el que el equipo inicial lo conformábamos un Solution Architect, dos Technical Architects, ocho Developers, dos QA Testers y su servidor como Project Manager (PM). Yo a mi vez reportaba los progresos de ese proyecto a un Program Manager (PgmM) dado que mi proyecto era parte de un esfuerzo mayor en la migración de nuestro sistema de e-Learning.
El equipo de proyecto se encontraba distribuido en tres países: México, USA e India, en este último país tenía 3 de los desarrolladores.
Por algunos motivos que describiré en futuros posts dado que me han dejado grandes lecciones aprendidas, el proyecto empezó a acercarse a su fecha de entrega y, como sucede con frecuencia, los entregables no se acercaban a estar 100% terminados. La presión por parte de los directivos de USA era grande dado que el cliente a su vez los presionaba a ellos. Finalmente se estableció una fecha de entrega para que el usuario entrara a ver el producto terminado el Lunes 4 de febrero de 2008. La semana anterior todo el equipo estuvo trabajando a marchas forzadas, cuando de pronto el sub-equipo de India dejó de reportar sus avances. Inmediatamente noté la ausencia de su reporte porque dada la distancia geográfica que separa a la India de nuestro país y dado que las fechas eran muy agresivas, yo había implementado un reporte diario de avance con nuestros compañeros de aquel país. Esa noche me conecté cerca de las 2:00am CST (tiempo del centro) (1:30pm IST (tiempo de India)) para ver si podía localizar a los compañeros de allá y justo eso hice. Fue cuando me explicaron lo que había sucedido y que después confirmé en un comunicado de Yahoo! News: El viernes 1o de febrero, un barco en el mar mediterráneo ancló tras verse amenazado por el clima y cortó uno de los cables que comunican por Internet al Medio Este con Europa afectando gran parte del ancho de banda de la India y otros países.
En esta ocasión, más que dar Lecciones APrendidas ya digeridas, quiero compartir qué fue lo que hicimos para afrontar este problema y permitirles obtener sus propias Lecciones APrendidas (si las quieren compartir conmigo se los voy a agradecer mucho).

1. Comuniqué inmediatamente al PgmM y a los directivos de la compañía para que manejaran las expectativas con el cliente.
2. La mejor comunicación para el pueblo Indio se daba a media noche nuestra, y dado que unicamente podían comunicarse por email, al mas puro estilo de aquel granjero que se corta el dedo cuando le muerde una serpiente antes de que el veneno recorra todo su cuerpo, solicité a los recursos de India que enviaran por email su código fuente para terminarlo con los recursos de occidente. Como el granjero, cortamos miembros que desde luego nos serían útiles mas tarde, pero también cortamos un potencial problema mayor en ese momento, de otra forma, si hubiera permitido que "el veneno" se esparciera por todo el proyecto hubieramos sufrido una inminente muerte.
3. Uno de los arquitectos técnicos, quien me apoyaba manejando gran parte de las comunicaciones con el equipo de India y quien resolviera las dudas y problemas que a ese sub-equipo le surgían, fue asignado a concretar lo que los compañeros Indios dejaron inconcluso, así cerré la brecha de conocimiento que suponía el reasignar recursos del proyecto.
4. El proyecto ya estaba en problemas y con tres recursos menos y fechas agresivas, opté por dejar que el desarrollo continuara únicamente con recursos occidentales (USA y México). Posteriormente los colegas Indios nos apoyaron en algunas tareas de menor impacto mismas que hicieron muy bien.
5. Aunque ya contaba con un Risk Register, incluí dentro del mismo todo riesgo potencial para el proyecto y desarrollé planes de mitigación para aquellos con mayor probabilidad de ocurrir y mayor impacto.

Aunque todo este asunto parece (y de hecho es) un asunto de manejo de riesgos, quiero comentar que muchas veces pasamos por alto los factores ambientales que envuelven al proyecto o a la compañía y muchos de estos factores pueden presentar problemas. En la página 83 del PMBOK(1) se describen algunos de los factores ambientales que existen, en este caso nos vimos afectados en la infraestructura que rodea a la compañía.
Comparte conmigo y los demás lectores tus Lecciones APrendidas sobre este issue que ocurrió: ¿qué hubieras hecho en mi lugar?
De la misma forma te invito a enviar cualquier comentario o experiencia que consideres de interés general para poder crecer más en nuestro conocimiento de Administración de Proyectos.
(1) PMBOK 3ª Ed. Español Pág. 83

El retorno...

Hola otra vez.
Esta es una comunicación muy corta solo para comentar que estoy de regreso. Perdón a los lectores por mi ausencia - no voy a poner excusas.

Traigo material nuevo que voy a publicar poco a poco y muchas lecciones APrendidas de mi proyecto actual. Este se ha visto afectado de mil maneras: desde simples cambios de alcance hasta issues con un barco anclado en el mar Mediterráneo que dejó incomunicado al país de la India... adivinaste, tengo 5 recursos trabajando en la India.
En fin, vamos poco a poco.

Por lo pronto, bienvenido y muchas gracias por tu atención e interés. Especiales agradecimientos a quienes se han tomado el tiempo de escribirme, me honran con sus visitas al blog y su retroalimentación.

¡Saludos!

Project Manager vs. Team Leader

¿Te ha tocado ver cuando el adiministrador del proyecto deja su equipo de trabajo y el jefe se ve obligado a poner a otra persona? Normalmente el jefe elige al mejor miembro del equipo para administrar el proyecto, después de todo este individuo se merece el ascenso. Cuando eso sucede, normalmente decimos que el equipo perdió a un buen técnico y ganó a un mal administrador.
En México sucede que el crecimiento económico de un profesionista está muy ligado con el crecimiento de puesto o de responsabilidad, de tal forma que cuando una persona desea ganar más dinero es necesario que ascienda de puesto, porque en el puesto en el que se encuentra estará sujeto a un tabulador menor.
En el proceso, las compañías asignan puestos administrativos a tecnicos sin una preparación administrativa previa ni un proceso de “ramp-up” para el nuevo puesto, y el resultado no se deja esperar.

Un técnico está acostumbrado a “meter las manos” en el momento de implementación, mientras el administrador observa desde afuera. Un técnico “delegará” responsabilidad diciendo a su equipo Qué y Cómo hacer las cosas, un administrador solo dirá Qué hacer y esperará los resultados. Un técnico estará más preocupado por el tipo de implementación mientras un administrador estará preocupado por entregar dentro de los límites acordados de tiempo, costo y calidad. Un técnico facilmente caerá en la tentación del gold plating (funcionalidad extendida y mejorada) mientras un administrador se preocupa por entregar solamente lo solicitado por el cliente. Un tecnico dejará pasar nuevos requerimientos del cliente a costa de su fecha de entrega mientras un administrador filtra los requerimientos por su proceso de change management establecido desde el principio.

Algunos técnicos solo quieren la posición de liderazgo y el sueldo relacionado con esa posición, pero no las responsabilidades, así que se convierten en “técnicos bien pagados” dado que hacen lo posible por continuar metiendo su nariz en las decisiones y acciones técnicas y desacreditando la documentación, planeación, coordinación y comunicación del proyecto.

Lo más grave de todo es cuando escuchamos a un técnico quejandose porque “tuvo” que dejar aquello que lo motivaba, aquello “para lo que fue hecho”, para adoptar una posición administrativa que a sus ojos no agrega valor al proyecto.

1. Cuida a tus técnicos y desarrolla un plan de carrera para ellos.
2. Si “subiste” en el organigrama para ganar mas dinero pero detestas las actividades administrativas, piensa que en algún otro lugar pudieran estar premiando tus habilidades tecnicas sin necesidad de tenerte haciendo todos esos reportes y hablando con toda esa gente.
3. Cuando busques trabajo, revisa el anuncio primero: si piden un “Administrador de Proyectos” con muchas habilidades tecnicas, probablemente lo que quieran es un Team Leader. Si les interesa que conozcas metodologías de PM, que generes reportes para la PMO, que manejes los conflictos, que reportes avances, que administres la calidad, que salga el proyecto a tiempo, que administres el presupuesto del proyecto, etc., entonces quieren a un PM.

Conclusión:
En todo el mundo, las compañías deben aprender a remunerar la especialización de sus tecnicos para que tengan una ruta de crecimiento laboral y económico. Esto les permitirá seguir motivados haciendo lo que más les gusta hacer y dejar los puestos administrativos para aquellos que encuentran una pasión en eso. Por otro lado, para aquellos que quieren cambiar de profesión avanzando a puestos administrativos, las compañías deben considerar el desarrollar a sus empleados para que estos tengan una transición adecuada con el fin de que tengan éxito en su nuevo puesto administrativo. Esta transición requiere tiempo, requiere uno o más mentores y mucha capacitación. Todo esto requiere inversión, pero el retorno es en fidelidad del empleado y de mejores tecnicos y mejores administradores dentro de la compañía.