.
Es una experiencia interesante cuando tu jefe te llama para proponerte un paracaídas: debes caer en el lío de un proyecto, comprender qué es lo que causa los retardos y enseguida tienes que ponerlo en sus rieles.

Siempre he dicho que corregir los proyectos no es cuestión de talento, ni de autoritarismo, sino de un profundo conocimiento de las limitaciones (sobre todo de las propias), y de una comprehensión real tanto de lo que está en juego como de la complejidad del problema.
Hemos abordado en muchas entradas del blog la dimensión de comunicación y la de planificación del tiempo. Sin embargo, cómo facilitar la transición entre jefes de proyecto? cómo facilitar la inclusión de nuevos participantes en el proyecto? cómo facilitar la reutilización de los nuevos conocimientos adquiridos durante el proyecto para proyectos similares?

Los proyectos son centros de interacción y de interpretación de esas interacciones. El conocimiento viene de tales interpretaciones, no del conocimiento de los hechos en sí mismos. Las metodologías para ejecución de proyectos se han concentrado en el control de la ejecución de los proyecto, y en la creación de indicadores para la gestión del rendimiento y de la calidad que ahora son estándar, tales como Earned Value (AV), Six-Sigma, entre otros. Infortunadamente, tales indicadores brindan una visión parcial de la porción “dura” (hard) del proyecto, y aunque todo sea claro, esto no te ayuda mucho cuando debes tomar las riendas en medio de una catástrofe.

Debemos asumir la transferencia de conocimiento como un reto, si queremos plantear soluciones reales. En este sentido, podemos considerar el conocimiento del proyecto como un elemento líquido. Debemos aislar el otro elemento crítico de la transmisión: vamos a sunponer que podremos encontrar inmediatamente todo el personal talentoso y preparado requerido.

La transmisión óptima de conocimiento es un problema tan importante, que si logramos resolverlo, muchas empresas tendrían una eficiencia casi infinita ;-) y los escenarios –dantescos en muchos casos– se convertirían en casos simples a manejar.

Vamos a suponer que trabajamos en una sociedad de consultoría. Esta sociedad enfrenta contínuamente este reto: como los consultores deben estar asignados en forma contínua a diferentes misiones, al tiempo que las demandas de los proyectos varían en el tiempo con los presupuestos y la disponibilidad de los actores del proyecto. Existe una alta probabilidad que los consultores asignados al proyecto cambian en el tiempo.
NOTA: Este es un escenario análogo a aquel de las empresas cuya tasa de rotación es elevada, ó en las startups que son normalmente super-dinámicas.

Qué es aquello que se requiere
Un proyecto en ejecución es un ser vivo. Una vez finalizado, el proyecto puede convertirse en un modelo para otros (ó en un contra-ejemplo :-( ).
Esto implica que las necesidades no son las mismas en las dos fases, y que los procesos de soporte no son tampoco equivalentes.

  • Durante la vida del proyecto, se debe poseer la información suficiente para hacer el seguimiento del proyecto, de los cambios y de la ejecución de su presupuesto. Dada la alta tasa de rotación durante la vida del proyecto, es esencial poder hacer una puesta a punto rápida de los nuevos miembros.
  • Al final del proyecto, se debe recuperar aquello que puede reutilizarse como ejemplo, pero también como contra-ejemplo.

La contínua navegación entre proyectos, tanto de negocios privados como
estatales, realizados en empresas diminutas y grandes, de aquellos que
involucran a pocas personas como de aquellos que tendrán un impacto
global, me indican que no es posible soñar con una solución única. Por eso propondré un modelo general, y no una receta de cocina.

A continuación listaré las dimensiones principales de aquello que constituye el conocimiento. En el futuro abordaremos tales dimensiones en detalle.

El proyecto en ejecución

  • Información contextual: necesidad estratégica y operacional del proyecto, productos esperados, actores principales, personas de contacto (tanto de la sociedad cliente como de las prestadoras de servicios), una matriz RACI para establecer las necesidades de comunicación en cada fase y para cada tipo de reporte.
  • Portal de Colaboración: contenedor de la comunicación, un lugar para compartir los ficheros/documentos, un lugar para los reportes de seguimiento (preferencialmente gráficos).
  • Control de cambios: un sistema para el seguimiento
    de cambios adaptado, rendidor y coherente.
  • Control de la configuración: En los proyectos IT, es necesario gestionar la configuración, porque esta es una información crítica para la mantenibilidad de la infrastructura tecnologica propiamente dicha.

El proyecto finalizado
Además de algunas informaciones extraídas de la fase de ejecución, deberían incluírse:

  • Información contextual: Razones de finalizar el proyecto, nuevos proyectos relacionados
  • Archivado: métricas del proyecto (general, de los participantes bajo su responsabilidad, gestión de calidad de productos entregados), generalización de soluciones (modelo para el tipo de proyecto, heurísticas para cálculo de esfuerzo/costo), portafolio de proveedores.
  • Conocimiento generado: Captura de lecciones aprendidas, comparación estadística, puntos a mejorar

Hemos introducido en esta entrada del blog la necesidad de transmitir el conocimiento. Hemos visto que esto permite disminuír el riesgo relativo a la trazabilidad del proyecto. Trataremos los puntos en detalle desde la semana próxima.


Leave a Comment