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.

Comunicación in-¿formal?

Hoy en día estamos inundados de medios de comunicación, y no me refiero a los periódicos ni al radio o televisión, me refiero a la amplia gama de opciones que tenemos para estar en contacto con la familia, amigos y conocidos. Particularmente en el portafolio de herramientas del Project Manager se encuentran instrumentos de colaboración que son útiles para comunicar status de los proyectos, recibir notificaciones, enviar reportes, recibir retroalimentación, solicitar avances, etc.
Instrumentos como el mensajero instantáneo (MSMessenger, Yahoo Messenger, Lotus Sametime, Skype, etc.). Estas herramientas han evolucionado de manera muy positiva permitiendo ahora intercambiar archivos, compartir la visualización del escritorio de trabajo de algún colaborador e incluso ver y escuchar a nuestro interlocutor.
El capítulo 10 del PMBOK 3ra edición cubre el tema de la comunicación dentro de los proyectos. El primero de los procesos es la Planeación de la Comunicación y en su definición más básica en este proceso se “determina la información y las necesidades de comunicación de los stakeholders”.
Desde luego que la comunicación de la que habla el capítulo 10 del PMBOK es la comunicación del avance del proyecto, su status, los milestones y su cumplimiento, etc. La importancia de esta información sugiere una comunicación formal a través de juntas, minutas y/o correo electrónico. Pero hay una gran cantidad de comunicaciones que no se planean; es la comunicación informal, la información del día a día. Los pequeños acuerdos, la explicación de algo, ese instructivo que pasamos de mano en mano. Mucha de esta información viaja a través de los mensajeros electrónicos y no se lleva un registro de la misma. Vale mencionar que al no estar documentada, esta comunicación no forma parte de las lecciones aprendidas de un proyecto aún que sea información muy valiosa.

Un Project Manager debería considerar la clasificación y registro de este tipo de comunicaciones. Quizás habilitando la característica de “historial” de su mensajero instantáneo y estableciendo un esquema básico de categorías (por ejemplo: Crear categorías como “Información importante”, “Información Relevante”, “Información relacionada pero no importante o relevante”) un Project Manager pudiera controlar mejor este tipo de comunicación y sobre todo sacar ventaja de la misma.

Todo esto requiere dedicación, desgraciadamente los planes de comunicación que se hacen en las primeras etapas del proyecto difícilmente son revisados mas adelante. Igualmente las lecciones aprendidas: normalmente contienen issues que surgieron y se resolvieron durante el proyecto o explicaciones acerca de por qué hubo variación en el presupuesto de tiempo de una fase específica. Las lecciones aprendidas pudieran ser una base de conocimiento muy robusta si los PMs tuvieran la disciplina de revisar, clasificar y promover la comunicación informal a lo largo de todo el proyecto.

De regreso... otra vez...

Después de un poco mas de 3 meses de ausencia, he vuelto.
He estado envuelto en una serie de cosas nuevas en mi vida y eso me ha hecho retirarme de la escritura un poco. Un cambio en mi vida laboral movió no solo eso, sino muchas cosas mas, me dió nuevas oportunidades entre otras cosas. Pero bueno, sé que no estás aquí para leer sobre mi vida personal, sino sobre Administración de Proyectos.
Tengo muchas nuevas entradas para este blog en el tintero, así que no te pierdas (como yo) y regresa pronto, ya estaré entregando el siguiente post en no mas de 1 semana.
Un saludo a todos los lectores y por favor sigan mandando su feedback por cualquiera de los medios disponibles.

Cambio de trabajo

¡Hola! Espero que estén teniendo una semana santa de acuerdo a las expectativas y perfectamente apegadas al plan :)
Les debo una disculpa por mi ausencia en estas 4 semanas, mi "plan de comunicación" en este proyecto falló dado que "fuí asignado" a un proyecto mas grande y de mayor prioridad. En otras palabras, estuve en un proceso de reclutamiento para ingresar a otra compañía y, como pueden imaginar, después de más de 8 años de pertenecer a la misma compañía, no es fácil retomar el proyecto de cambio tan fácil, requiere tiempo, concientización, análisis de repercusiones, etc.
Como sea, yo sé que están acá tratando de leer alguna experiencia en administración de proyectos y no de enterarse de mis asuntos y mis forcejeos personales, así que aquí va una serie de LeccionesAPrendidas sobre este proyecto de búsqueda de trabajo manejada como un proyecto.

1. Empieza con un fin claro en la mente. Visualiza exactamente cuál es el puesto que deseas buscar/ocupar y describelo con detalle en un documento. Decide el tipo de industria a la que deseas pertenecer. Esto, como un plan de proyecto, te permitirá ver si te estás acercando al objetivo o si una propuesta es lo que estás buscando.
2. Elige dos o tres motores de búsqueda de trabajo, publica tu currículum y monitorealos cercanamente (al menos dos o tres veces por semana).
3. Acude a las entrevistas que te ofrezcan, si no es una buena oportunidad laboral, al menos te "desempolvas" en el asunto de ser entrevistado. Sé honesto y claro con el entrevistador y no generes expectativas que no vayas a satisfacer.
4. Al cierre del "proyecto", no olvides retirar o suspender tu currículum de los motores de búsqueda laboral cuando hayas encontrado y aceptado tu nuevo trabajo. Esto habla de profesionalismo y ética: cuando decidas "subirte en un tren, no te bajes a una cuadra de haber arrancado", ten en cuenta que la compañía ha invertido tiempo y dinero en el proceso de selección. Lo mejor es fijarse bien antes de aceptar una oferta y retirarse de la búsqueda por al menos un tiempo antes de empezar a buscar el siguiente escalón profesional.

Un par de anuncios para terminar:
1) ¡Ya tenemos el Nombre de Dominio www.leccionesAprendidas.com.mx! Si han creado un bookmark de esta página tomando la dirección de BlogSpot, les recomiendo que editen su bookmark y lo direccionen hacia esta nueva dirección. Esto es útil ya que si decidimos mover el sitio a otro hosting, ustedes no requerirán hacer actualización alguna, porque esta nueva dirección los redireccionará al nuevo sitio.
2) Estamos buscando nueva "casa". A pesar de que BlogSpot es muy efectivo, muchas empresas lo tienen filtrado en el proxy y la cantidad de usuarios lo ha hecho un poco lento. Así que estamos en el proceso de buscar un nuevo lugar donde publicar este sitio. Envíame sugerencias.

El Conocimiento es un activo de la organización (3ª parte)

Con un poco de retraso, pero aquí está el cierre de esta serie de Lecciones APrendidas acerca del conocimiento de las organizaciones.
Ya dijimos que el capital intelectual debe ser conservado dentro de la compañía independientemente de si la persona que lo produjo sigue dentro de la organización o ya se retiró. También comentamos qué son los OPA (ver post del 9 de febrero de 2007) y algunos ejemplos de lo que los compone.
Hice una revisión a detalle de los procesos de administración de proyectos detallados en el PMBOK 3ra edición en búsqueda del uso de los OPA. Ya comentaba que 26 de 44 procesos los incluyen como entradas al proceso y algunos de ellos tienen como salida la actualización del repositorio de conocimiento de la organización (aportaciones a la base de datos de conocimiento organizacional). Lo que llama la atención de esta reflexión, es que el uso de los OPA como entradas a los procesos es mas intenso en las fases iniciales del ciclo de vida de un proyecto como lo muestra la línea amarilla en la gráfica siguiente.

Y todo esto tiene sentido, conforme se conoce más acerca del producto, servicio o resultado a construir en el proyecto, la necesidad de consultar registros históricos disminuye. Al llegar al final del ciclo de vida del proyecto, dado que la cantidad de procesos de AP es muy pequeño (2 procesos) y en uno de ellos es usado, la estadística de uso de OPA se vuelve a levantar.
Todo esto nos deja varias lecciones, pero quizás las más relevantes para tu servidor sean las siguientes:

1. Los registros históricos de la organización son más necesarios al inicio del proyecto, de tal forma que los analistas y diseñadores deberán tener acceso a esos registros más que cualquier otro miembro del equipo.
2. Recordemos que el ciclo de vida del proyecto que sugiere el PMI encaja en cualquier metodología y establece que cada fase de la metodología tiene este mismo esquema: Inicio, planeación, ejecución, monitoreo y cierre, de tal forma que cada fase de la metodología usada haría uso de los OPA en los diferentes grados ya descritos.
3. Es necesario alimentar una cultura de aportación a la base de datos de conocimientos de la empresa. Toda inversión en este proyecto retornará en beneficios enormes en el futuro.

En mi compañía estamos por lanzar la nueva base de datos de conocimientos en el área en la que trabajo, sin embargo ya hay peticiones para que les prestemos espacio en la base de datos para subir las lecciones aprendidas de otros departamentos. Esto es algo muy positivo dado que usando la sinergia de un área, otras se benefician y la compañía crece. El lanzamiento es este viernes 23 de febrero, luego comentaré las Lecciones APrendidas de este proceso.
¡Hasta pronto!