El Cafe de Joe es un blog dedicado a Gestión de Proyectos y es una iniciativa de Irwin J. Franco PMP a.k.a. "Joe" desde Guayaquil – Ecuador. Joe es un miembro del PMI, corresponsal de PM World Today y trabaja como Project Manager en Image Tech. En su blog sigue activamente la actualidad de gestión de proyectos y publica artículos interesantes sobre la metodología, temática relacionada con proyectos y tecnología. El Cafe de Joe siguiendo con las actividades del Día Internacional del Project Management recientemente ha publicado varias entrevistas. Quería agradecerle a Joe que me haya considerado para una de ellas. A continuación pueden leer la entrevista completa aquí.

Aparte de las dificultades habituales de cualquier proyecto y bajo un inocente velo de transparencia, a veces el equipo de gestión se empeña en trasladar a los miembros del equipo de producción (desarrollo, fabricación, construcción, etc.) toda la información de la que dispone a medida de que le va llegando lo que puede crear en los participantes preocupaciones innecesarias, si los datos no se distribuyen de forma adecuada. Transparencia como política de gestión, sin ninguna duda, es algo positivo pero introduzcamos una variable más – la llamada "need to know". Un criterio para decidir quién debe saber qué y para qué. En los equipos cada uno sabe exactamente el labor que le corresponde (o por lo menos debería). Es el rol de del Project Manager y sus asociados decidir a quién se le debe proporcionar la información, de qué manera y con qué fin. Es allí Donde entra en el juego la matriz de comunicaciones, un documento "vivo" que muestra cómo debería fluir la información en el proyecto. Complicaciones a nivel político, quejas, comentarios de clientes o proveedores deben ser previamente evaluados y dirigidos de forma controlada a los que necesitan y pueden actuar en beneficio del proyecto al disponer de la información.

Las iniciativas que requieren participación de un cierto número de personas sea en local o distribuidos geográficamente necesitan que estos grupos desarrollen un sentimiento de pertenencia al grupo y comprendan exactamente el objetivo del proyecto y los entregables a producir. Para esta tarea desde hace algunos años, al principio sólo en el sector de construcción e ingeniería, se utilizaban war-rooms, centros de guerra (traducción libre), dónde los participantes tenían a su plena disposición y fácil accesibilidad toda la documentación del proyecto a la vista. Allí se reunían, discutían y pensaban sobre como resolver los problemas, y también celebraban el éxito. Para proyectos de software el warroom debería tener posteado en la pared los diagramas WBS y el PERT, en sus últimas 2 versiones para ver los cambios que se realizaron. Para facilitar el entendimiento el WBS dictionarry también debería figurar allí mismo. Es buena idea postear el registro de riesgos con sus planes de mitigación y contingencia. Ese espacio dedicado al proyecto no es fácil de mantener si tenemos equipos distribuidos por todo el mundo por lo que disponibilidad de una intranet con los mismos datos en formato Wiki puede ser una válida alternativa.

Ya tenemos el MPP con la información de nuestro equipo. Este "pool de recursos" ya puede ser accedido desde otros ficheros MS Project. El archivo MPP con datos de nuestro equipo debe estar disponible a través de la red ya que los ficheros de planes de proyecto A, B y C necesitarán acceder a los datos que contiene. Si estamos en una red local, el pool puede ser publicado en una carpeta compartida con permisos de lectura y escritura. Según los datos anteriores ya podemos crear planes de proyecto a través de MS Project Professional para cada una de nuestras iniciativas. Al tener todas las tareas introducidas y sequenciadas en lugar de añadir equipo al plan en sí debemos pedirle al MS Project que use los recursos compartidos del pool. Eso se hace desde el menú "Tools" – "Resources Sharing" – "Share Resources". Y en la caja "Share Resources" y marcamos la opción "Use Resources". Es importante saber que los dos ficheros deben estar abiertos – el Plan y el Pool.

Continuará…

En caso de disponer de MS Project Server, a través de su funcionalidad de pool de recursos ofrece toda la información necesaria para nivelar la involucración de personal en proyectos por defecto. En la segunda entrega de la serie "Gestión de conjuntos de proyectos – programas" me refería al uso de la aplicación MS Project Professional, sin usar MS Project Server. Vamos a examinar paso a paso como conseguir controlar un programa de proyectos con ficheros MPP. Para el escenario consideraremos un programa con 3 proyectos A, B y C. Tenemos un equipo de 5 trabajadores: Antonio, Ana, Juan, Juliana y Pepe. Así pues tendremos 1 archivo MPP con los datos de nuestros recursos. Este fichero será considerado como pool de recursos, allí añadiremos los nombres, departamentos, funciones, precios por hora normales, costos extra u otros datos adicionales del personal. Si estamos en un entorno con Active Directory o LDAP podremos importar estos datos a MS Project. Cuando hayamos terminados de añadir los datos de recursos debemos convertir el MPP típico en un fichero ‘resource pool’. Se hace desde el menu "Tools" (Herramientas) – "Resource Sharing" (Recursos compartidos) en el menu "Share Resources" (Compartir recursos) con opción "Use own resources" (Usar recursos propios).

Continuará…

El PMO al gestionar el programa y a su vez supervisar a los Project Managers involucrados en el día a día de sus proyectos precisa saber la cantidad total de recursos disponibles en el pool, su capacidad real, en que proyectos participan y cual es su carga. Al disponer de MS Project, podemos montar un Pool de recursos. Esto es un tipo de fichero MPP que sirve para almacenar el listado de todo el personal con sus datos de coste por hora normal, coste por hora extra, calendarios y horarios de trabajo de cada uno y etc. A medida de que se van creando proyectos, en lugar de tener una lista de recursos estática dentro del archivo de Project, los recursos se linkan al proyecto a través del fichero de pool. Cuando un más de un project plan está linkado a un resource pool, abriéndolo podemos observar en un solo fichero todas las tareas que realizan los recursos, horas que dedican, nivel de carga/sobrecarga, etc.

Continuará…

Al llevar varios proyectos de tamaño medio o grande con un equipo de proyecto numeroso la tarea de recibir, distribuir y diseminar correctamente la información entre los stakeholders (el PM también es un stakeholder) puede resultar una tarea tediosa que puede ser automatizada. Cuando se usan herramientas de enterprise project management como la suite de Microsoft Project/Portfolio Server, Primavera, etc… existe un dashboard que se alimenta de la información sobre el estado de las tareas introducidas por los desarrolladores, pero no siempre nos encontramos con este tipo de escenarios. Empresas que se están introduciendo en el mundo de gestión de proyectos o aquellas que ya ejecutan su enésimo proyecto sin usar las herramientas que he mencionado arriba también deben informar a sus clientes, sponsors y etc. Una de las soluciones podría ser la migración a suites profesionales – mala idea casi siempre, gastos elevados en licencias, formación, resistencia a cambio, etc. Pero si la infraestructura actual tiene todo pero le falta un cuadro de mando fácil de entender, a veces inversión en un software de business intelligence puede dar buenos resultados. Un escenario donde hay herramientas de base de datos que albergan la información sobre los proyectos, estados, tareas y etc con ayuda de software similar a Cognos podrían extraer esa información y presentarla según diferentes niveles de detalle, para PM’s, para team lead’s, para sponsor, etc.