25 de noviembre de 2012

Los procesos de PMBOK con Microsoft Project

La Gestión del Tiempo del Proyecto incluye los procesos requeridos para lograr que el proyecto o fase finalicen en la fecha señalada. La fecha de término suele ser una de las restricciones más importantes en la gestión de un proyecto. La guía PMBOK® presenta los procesos de gestión del tiempo de manera muy estructurada, con el fin de facilitar su aplicación en proyectos grandes. El Director del Proyecto documentará sus decisiones sobre qué procesos aplican cómo se abordan. Un proyecto grande que tenga fuertes restricciones de plazo, tendría que seguir los 5 procesos de planificación, antes de llegar a producir la línea base del cronograma.

A continuación se describirán los 5 procesos, de forma muy resumida, al tiempo que se revisa el uso de la herramienta Microsoft Project que correspondería a cada proceso.


Proceso 6.1 Definir las Actividades

El primero de los procesos de gestión del tiempo del proyecto es el proceso 6.1 Definir las Actividades. Básicamente, consiste en transformar los paquetes de trabajo identificados en la Estructura de Descomposición de Trabajos (EDT) en una lista de actividades. En Project, esto equivaldría a rellenar la columna “Name” y ciertos atributos de las actividades en las pestañas de “Task Information” (especiamente el campo “Notes”).


 
Respecto a los atributos de las actividades que menciona PMBOK, la correspondencia con Project puede seguirse en las pestañas que aparecen al pulsar el botón “Task Information”:

Proceso 6.2 Secuenciar las Actividades

Posteriormente se abordaría el proceso 6.2 Secuenciar las Actividades, que consiste en ordenar la lista de actividades y obtener una representación gráfica en un diagrama de red.

En Project, se trata de rellenar el campo “Predecessors” de manera que aparezcan las flechas del diagrama Gantt. El diagrama de red puede obtenerse en la vista “Network Diagram”. Obsérvese que aparecen en rojo las actividades que forman parte del camino crítico.


Proceso 6.3 Estimar los Recursos de las Actividades

De momento no se ha hablado de duraciones, sólo de las actividades y sus dependencias. Para saber cuánto dura una tarea, es necesario pensar antes quién la realizará, o al menos qué carga de qué categoría profesional (por ejemplo, en proyectos software hay que tener en cuenta que un programador senior puede tener una productividad hasta 8 veces superior a uno sin experiencia). Para eso está el proceso 6.3 Estimar los Recursos de las Actividades.



En Project, esto equivale a rellenar el campo “Resource Names”, no con los nombres de los recursos, sino con el perfil profesional y su carga estimada (para indicar el nombre del recurso, cuando finalmente sé quién es, yo suelo utilizar el campo “Notes” del recurso).

Proceso 6.4. Estimar la Duración de las Actividades

Ahora, con la información disponible de las actividades y sus necesidades de recursos, ya puede comenzarse a trabajar en el proceso 6.4. Estimar la Duración de las Actividades.


En Project, esto equivale a rellenar el campo “Duration”, con la duración más probable de la tarea.

Una nota sobre el concepto “duración más probable”. Cuando estimamos las duraciones de las actividades, hemos de tener en cuenta que una estimación sin un ± no es una estimación. Es decir, no damos una imagen muy profesional cuando comunicamos a los interesados que vamos a tardar exactamente 23 días en terminar una actividad. ¿Diremos también si terminamos antes o después de la hora de comer?

Si los expertos nos dan como estimación optimista 20 días, más probable 23 y pesimista 35, deberíamos estimar que tardaremos entre 20 y 30 días, con una confianza del 95%. O bien entre 22 y 27 días con una confianza del 68%. Estos cálculos se pueden aproximar rápidamente con las fórmulas de “estimación por tres valores” (que también se conoce como estimación PERT):

En todo caso, el dato que deberíamos entrar en Microsoft Project para esta actividad es siempre la duración más probable, es decir, 23 días. Project necesita que sea así para calcular el camino crítico.


Proceso 6.5. Desarrollar el Cronograma

El último proceso de planificación del tiempo es el proceso 6.5. Desarrollar el Cronograma. Al alimentar el cronograma con la información de las duraciones, es muy probable que se obtenga un plazo superior a la fecha límite. Tras aplicar una serie de alternativas y técnicas de compresión (o de renegociar las restricciones, por ejemplo aumentando el presupuesto) se consigue ajustar el cronograma a las necesidades del proyecto.



En este proceso tiene especial importancia la determinación del camino crítico, ya que si se trata de comprimir, hay que empezar por las tareas críticas. Gracias a Project, el Director de Proyectos ya no tiene necesidad de calcular manualmente el camino crítico, basta con visualizar las tareas críticas en la vista “Tracking Gantt” o en la vista “Network Diagram”, o bien comprobar el valor del campo “Total Slack = 0”.


Este post es una transcripción de un artículo que escribí para el curso online de Project Management de IEDGE. Pueden ver otros artículos míos generados para IEDGE pulsando aquí.

8 comentarios:

  1. estupenda aportación! muchas gracias

    ResponderEliminar
  2. EXCELENTE ARTICULO, OJALA PUEDAS DARNOS MAS APORTES, QUE SON DE MUCHA UTILIDAD A LOS QUE RECIEN ESTAMOS INICIANDONOS EN ESTE APASIONANTE TEMA COMO LO ES LA GESTION DE PROYECTOS, MUCHAS GRACIAS.

    ResponderEliminar
  3. Un warning conceptual con respecto a lo indicado sobre PERT.
    Son correctas las fórmulas indicadas para la distribución BETA, utilizada por PERT.
    Sin embargo, los porcentajes indicados debajo del gráfico (68%, 95%, etc) son aplicables solo a la distribución Normal.

    Saludos.
    Pablo Zarbo

    ResponderEliminar
    Respuestas
    1. tienes toda la razón, Pablo
      muchas gracias por la aclaración

      Eliminar
  4. JC Pacheco28/11/12, 20:48

    Excelente artículo.
    Una consideración para la estimación de la duración de las actividades. Mi posición es que se utilice la "duración esperada", pues ella recogerá las condiciones o riesgos que hicieron que la actividad no se ejecute siempre con el valor más probable (moda); por esa razón es que PERT (Program Evaluation and Review Technique) utiliza la estimación de los 3 valores.
    Saludos cordiales,
    JC Pacheco

    ResponderEliminar
  5. Excelente aportavion. Muy interesante

    ResponderEliminar
  6. Hola Jose:
    Hay una cosa que me llama mucho la atención: en Microsoft Project 2010 ha desaparecido la opción de análisis PERT. ¿sabes porqué? Lo digo, pq creo que no se deberá a causas técnicas sino a que ese tipo de análiis cae en deshuso o a alguna causa por el estilo.
    ¿sabes si estoy equivocado?¿alguna otra técnica de cálculo de desviaciones?
    Muchas gracias nde antemano

    ResponderEliminar
  7. Hola,
    la barra Pert ha desaparecido en la versión 2010. La única opción es utilizar una macro que realice el cálculo respectivo, de momento no hay otra manera.

    ResponderEliminar