Estoy suponiendo que este esfuerzo es parte de la estrategia de implementación de una  Oficina de proyectos (PMO) por eso no mencionare  los pasos previos para llegar a este punto, solamente  lo que se debe de tener presente para documentar los principales procesos .

Debes de tomar en cuenta como base  los PROCESOS  relacionados con la Gestión de proyectos (42 en la nueva versión del PMBOK) las personas o Sateholders involucrados, la Documentación historica y los sistemas de soporte con que cuente la empresa relacionados al tema (MSProject, Primavera, Excel, otros).

Sobre los sistemas o herramientas puedes comenzar utilizando Microsoft Office (Word, Excel, MsProject) y en otros casos apoyarte con algunos sistemas Open-source o de bajo costo. Si ya tienes algún programa o solución debes de evaluar como? y cuanto? esta se adapta a los procesos y buenas practicas de PMBOK.

El siguiente es un planteamiento de lo que podría ser la estructura  general , en base a las áreas de conocimiento antes mencionadas.

Espero que esta estructura sea util  para sentar las bases y te sirva de guia para dar tus primeros pasos en la formacion de la PMO

Conociendo ya  a los stakeholders y su nivel de influencia podemos  hacer un “plan de comunicación” tan sencillo como el que proponemos a continuación que nos servirá de guía para  poder responder preguntas como Que? a quienes? cuando? y como ? comunicarnos mejor.

Plan de Comunicación

Método de Comunicación

Comentario final

Un  Gerente de Proyecto tiene que ser un buen comunicador y para lograrlo no debe de olvidarse los  elementos básicos del modelo de comunicación, saber escuchar cuando  se asume el papel de “Receptor”  y enviar  mensajes claros cuando se asume el papel de” Emisor”. Estos  principios  son básicos  pero importantes de recordar ya que muchas veces no se siguen en diferentes circunstancias del proyecto por ejemplo  hay  Gerentes de proyectos (GP) que no dejan de hablar cuando están levantando requerimientos lo cual no permite entender correctamente las expectativas del negocio, asi como también hay otros GP que se quedan en silencio  en momentos que se discuten cambios importantes o se están negociando condiciones importantes del proyecto.

Si sabemos intervenir oportunamente de acuerdo al rol que estemos siguiendo y a la vez nos concentramos en dar un mensaje claro ya tendremos ganada casi mas del 50% de la batalla en este tema tan importante, como son las comunicaciones en la gestión de proyectos

Entender estos 2 conceptos nos puede ayudar a desarrollar mejor nuestros cronogramas de proyecto.

Para recordar la Formula es   — > esfuerzo = duración * unidades

El esfuerzo es la medida de trabajo aplicada al cumplimiento de una tarea o paquete de trabajo. Las medidas utilizadas para expresarlas están expresadas entre formatos de tiempo/unidad. Por ejemplo el desarrollo de reportes tomara 4 horas de Programacion

Esfuerzo dirigido – La tarea puede ser completada rápidamente si  se le asignan recursos adicionales de trabajo. Por ejemplo una tarea de carga de datos puede ser acelerada si se asignan más digitadores.

Duración es la medida de cuanto una tarea en particular puede tardar en completarse. Las medidas utilizadas para expresarla son las unidades de tiempo. Por ejemplo el análisis de ciertos  requerimientos tomara 5 días por cada analista.

Duración Fija – La tarea requiere una cantidad de tiempo establecido para completarse y la asignación de recursos adicionales no cambiara el tiempo requerido. Por ejemplo una reunión de Kickoff , una charla programada, etc

En la práctica

Te recomiendo que siempre que  desarolles o recibas un cronograma agregues la columna de esfuerzo (o work en ingles )  para que puedas comparar la diferencia de ambos valores y como estos varian a la medida que vas configurando las tareas. Tambien es  recomendable agregar  la columna de costos para ver como varia el presupuesto teniendo de esa manera configurada en forma completa las triple restriccion del proyecto ( alcance, tiempo y costos)

En este sencillo ejemplo puedes ver que aplicando la formula — > esfuerzo = duración * unidades,  la tarea 1.4 tiene un costo diferente a las demas justamente por que hay dos unidades asignadas a dicha tarea ( el albanil y el ayudante).

Realmente sin la visibilidad de estos tres valores duracion, trabajo y costos seria imposible notar las diferencias y controlar el proyecto. No te olvides de agregarlos!!!

Son aplicables estos conceptos a la administracion de proyectos? Porsupuesto que si . Por ejemplo llevar a cabo reuniones semanales de seguimiento con el equipo  es una de las actividades  mas importantes en la fase de ejecucion y a la vez una manera proactiva de evitar conflictos y/o problemas mayores como:

• + Incumplimiento de fechas planificadas
• + Cambiar las Prioridades en el Proyecto
• + Falta de Recursos
• +  Sobrecostos
• + Conflictos entre los miembros del equipo

De hecho algunos Gerentes de Proyecto podrían pensar que estas  reuniones son importantes pero no urgentes  y no las esten haciendo en forma periodica,  si este fuese el caso – Cuidado!!! - pueden estar formandose  conflictos o problemas mayores  que mermen  a futuro la productividad del proyecto.

Creo que lo importante es lograr un equilibrio entre lo urgente y no urgente siempre trabajando sobre lo importante (Cuadrante I y II) . Recuerda que la clave es saber delegar.

Te animas a recomendar que tareas o buenas practicas de GP  debemos considerar en el  cuadrante II para minimizar los riesgos y llevar una gestion de proyecto mas EFECTIVA.

Uno de los temas mas sensibles a la hora de desarrollar un cronograma en MSProject es  utilizar correctamente los  3 tipos de tareas   – Trabajo Fijo, Duración Fija  y Unidades Fija. En Internet puedes encontrar bastante información de consulta, sin embargo a la hora de aplicarlos muchas veces lo obviamos y en la práctica nos trae problemas.

Una recomendación previa antes de configurar estos tipos de tareas es entender si las actividades están orientadas por los recursos o por la duración.

Se dice  que un proyecto es orientado por lo recursos cuando su disponibilidad y el costo es la primordial limitación expresada por el sponsor o cliente.  Los proyectos dirigidos por los recursos deben expandir el tiempo o sacrificar la calidad para permanecer dentro de las limitaciones de los recursos.

Por otro lado un proyecto es orientado por la duración cuando LA FECHA DE ENTREGA FINAL es la primordial limitación expresada por el sponsor o cliente. Los proyectos dirigidos por la duración consumirían cualquiera de los recursos requeridos para asegurar la entrega en la fecha establecida –  por ejemplo  - Proyecto del Año 2,000

A modo de guía he preparado una  explicación  grafica de los tipos de tareas y  su utilización en MSProject bajo diversos escenarios planteados.

Recuerda que en MSPROJECT todas las tareas vienen por default con el tipo de tarea “duración fija “ y posiblemente eso no te convenga a la hora de desarrollar tu cronograma.

1. Caso de Negocio. Completo, realista, formalizado y aprobado.
2. Reglas de priorización de requerimientos.
3. Modelo(s) de estimación acorde al dominio que sea confiable.
4. Selección, seguimiento y evaluación de competencias de talento humano
5. Requerimientos bien definidos.
6. Cronograma y Flujo Financiero.
7. Plan de Riesgos, Calidad y Comunicaciones.
8. Todo tipo de contrato bien definido y claro
9. Sistema de seguimiento consistente de avance y de logros de objetivos.
10. Gestión de Control de Cambios.
11. Gestión documental, actas firmadas por quién debe ser, cuando debe ser.
12. Sistema de evaluación durante y posterior al proyecto, interno y externo, que posibilite la mejora y el aprendizaje.

Su comentario me pareció muy acertado y  mi respuesta fue que “los puntos” mencionados me parecían una  buena” guía  practica” a seguir a la hora de recibir un proyecto.

Días después preparando mi próximo articulo (el que ahora están leyendo) me di cuenta que los comentarios de Ramiro y el tema elegido estaban muy relacionados entre si, Inmediatamente relacione la pregunta del debate con el tema y esta fue la respuesta que obtuve automáticamente ..…Como garantizar que un proyecto sea  gestionable ? …. desarrollando el Project Charter.

Veamos si estamos en lo correcto…

El Pmbok nos dice que” Desarrollar el acta de constitución del proyecto o Project Charter  es el proceso que consiste en desarrollar un documento que autoriza FORMALMENTE UN PROYECTO o UNA FASE  y en documentar los requisitos iniciales  que satisfacen las necesidades y expectativas  de los interesados. En proyectos de fase múltiple este proceso se usa para validar o refinar las decisiones tomadas durante la repetición anterior del proceso Desarrollar el Project Charter”

Rita Mulcahy también nos dice en su libro de PMP  prep exam, que elProject Charter no es necesariamente elaborado por el PM sino por el Sponsor del proyecto; que debe ser creado en la fase temprana del proyectoy que debe ser elaborado de manera amplia de tal forma que ninguna solicitud de cambio pueda afectarlo, en caso que esto ocurra se debería de cuestionar la continuidad del proyecto o en su defecto crear uno nuevo.

Sobre el contenido general de un documento de Project Charter podríamos tomar las siguientes secciones a modo de guía :

1. Nombre del Proyecto
2. Descripción del Proyecto ( Que es?)
3. Definición del Producto o servicio del Proyecto
4. Definición de los requerimientos del Proyecto
5. Lista de Stakeholders y sus requerimientos
6. Caso de Negocio
7. Justificación del Proyecto
8. Designación del Gerente de Proyecto y nivel de autoridad
9. Principales Entregables  (WBS a segundo nivel)
10. Cronograma de Hitos
11. Presupuesto del Proyecto
12. Organización del proyecto y recursos preasignados
13. Supuestos y Restricciones
14. Principales Riesgos del Proyecto

Comentario final

Creo que uno de los prinicplaes puntos de falla en un proyecto es iniciar el mismo sin tener desarrollado el Project Charter, este documento nos da un marco – aunque a veces de muy alto nivel  - validos para navegar con seguridad hasta el final del proyecto. En mi experiencia he visto varias veces a gerentes de proyecto comenzar sus proyectos en base a la información entregada por el área comercial, llámese contrato y  propuesta técnica solamente sin mucho éxito o con típicos problemas de alcance y sobrecostos a la mitad del proyecto. De forma practica asegúrese de preguntarse la próxima vez que sea asignado a un proyecto si es que tiene toda la información necesaria para iniciar el proyecto?  y  principalmente si los requerimientos y el esfuerzo dimensionado para implementarlos han sido bien dimensionados?

Recuerde  este articulo  y aplique siempre  las buenas practicas del Pmbok, valide la información entregada de su nuevo proyecto contra el contenido general  del Project Charter que aquí le recomendamos  y si no lo tiene tómese el tiempo para hacerlo antes de presentarse en la reunión de Kick off, le aseguro que si sigue estos consejos su proyecto y usted tendrá una alta probabilidad de éxito.

Les cuento que ese ERROR es una de las principales causas de fracaso de los proyectos, sea cual sea su magnitud – grande o pequeño.

En base al PMBOK lo primero que debes hacer es  reunirte con el equipo de proyecto y desarrollar el WBS. Para los que no manejen este termino, el Work Breakdown Structure (WBS) corresponde a una división jerárquica y de multinivel del trabajo a realizar, que cubrirá los requerimientos del proyecto. (PMBOK, 2004), también responde a la pregunta: Que va a ser desarrollado a través del proyecto?
Esta técnica distribuye el trabajo en paquetes que deben ser definidos para facilitar la administración y el seguimiento del alcance del proyecto.

A continuación debes preparar el “Diagrama de Red” a partir de los paquetes de trabajo o actividades definidas, estableciendo las relaciones de precedencia entre ellos. Estas relaciones indican qué actividades deben completarse antes de comenzar otras, y cuáles deben ejecutarse al mismo tiempo.

Una vez que tenemos listo es WBS y el “Diagrama de Red” podemos iniciar el desarrollo del cronograma en base a la estructura previamente determinada.

He preparado un ejemplo que te guiara de forma practica en el desarrollo inicial de tus cronogramas utilizando 2 herramientas graficas  y de fácil uso que de seguro utilizaras a partir de hoy.

A mi parecer el valor o beneficio mas importante es el de validar los requerimientos y expectativas del proyecto con los mismo protagonistas. Muchas veces se discute que el proyecto puede haber estado mal dimensionado desde la fase comercial y por lo tanto inicia con mucho riesgo y  en algunas veces pre-destinado al fracaso, es pues aqui donde el Gerente de Proyecto debe tomarse el tiempo para VALIDAR el alcance, primero a lo interno de la organizzacion y luego presentarlo al cliente dentro de la reunion de Kickoff.  Que sucede si el alcance vario? la respuesta es presentar una  ”Solicitud de Cambio” o  en algunos casos  hacer una “Addenda al Contrato”.

Recuerde este ultimo parrafo y atrevase a cuestionar las lineas base de alcance , tiempo y costo, si no lo hace en esta etapa inicial  y usa el Kickoff como una “herramienta de gestion”  tendra despues que iniciar un proyecto con muy pocas posibilidades de exito .

A modo de guia he preparado un Cheklist general de lo que seria “La preparacion de una presentacion de Kickoff” para tus proyectos.  Espero que le sea util y que lo pongas en practica en tu proximo proyecto.