Marble Station

PMBOK, Project Management / Gestión de proyectos

El Project Management Institute (PMI) es una organización que intenta establecer un orden y unos criterios estándares para la gestión de proyectos. Con esa finalidad, PMI mantiene el libro Project Management Book of Knowledge (PMBOK) donde se establecen todo un conjunto de herramientas y buenas prácticas que todo jefe de proyecto debe conocer y aplicar.

En contraposición a otras metodologías (p.ej. las metodologías ágiles como Scrum), PMBOK se encuentra orientado a una gestión predictiva de los proyectos. PMBOK presenta diversas fases de un proyecto de forma lineal (una vez superada una fase, no se volverá a ella), donde la necesidad/solución, el alcance y la planificación (p.ej. coste y duración de cada una de las tareas a realizar) se establece en las fases iniciales (de ahí que sea denominada gestión predictiva).

Por tanto, podríamos considerar PMBOK como perteneciente a la rama más clásica de la gestión de proyectos (al igual que el estándar complementario PRINCE2, popular en UK). No obstante, este hecho no implica que parte de las herramientas que ofrece no puedan ser utilizadas en combinación con otras metodologías más ágiles y flexibles.

Introducción

Antes de empezar en materia es necesario establecer la definición y las características de un proyecto según el PMBOK:

• Un proyecto intenta dar solución a un problema (cubrir una necesidad).
• Es temporal
• Es único en el tiempo y no repetible bajo las mismas circunstancias
• Conlleva incertidumbre
• Consume recursos: Tiempo, dinero, materiales y trabajo.

Los proyectos disponen de su propio ciclo de vida, el cual se divide en las siguientes fases:

• Inicio: Se identifica la necesidad y se cuestiona si es posible llevar a cabo el proyecto.
• Planificación:
  • Se desarrolla una solución en un mayor detalle.
  • Definición de tareas, calendario.
  • Estimación de costes en tiempo y dinero.
  • Se vuelve a plantear si es factible el proyecto.
• Ejecución: Monitorización y ajustes a la planificación.
• Cierre: Se comprueba si el proyecto satisface la necesidad a cubrir

Todas estas fases, implican los siguientes proceso generales:

• Identificar el problema o la oportunidad
• Identificar y definir la solución idónea
• Identificar las tareas y los recursos necesarios.
• Preparar el calendario y la obtención de recursos
• Estimar el coste del proyecto y preparar un presupuesto
• Analizar los riesgos y establecer relaciones con los stakeholders (toda persona que tenga un interés directo o indirecto en el proyecto): Gestión del riesgo periódico
• Mantener el control y la comunicación en el nivel adecuado durante la ejecución: Reuniones periódicas para detectar y comunicar desviaciones
• Gestionar un cierre satisfactorio
  • Punch list: listado de tareas para poder acabar el proyecto.
  • Los miembros del equipo tienden a dispersarse dado que el proyecto se encuentra casi cerrado.

No obstante, un proyecto puede ser visto desde otras perspectivas, como por ejemplo desde el punto de vista de las relaciones interpersonales:

• Motivar al equipo: Crear el clima adecuado
  • Invertir tiempo en explicar como cada función contribuye al proyecto
  • Invertir tiempo en las reuniones para destacar contribuciones positivas de los miembros.
  • Confiar en el trabajo delegado
  • Asignar objetivos a los individuos y permitir que ellos escojan el camino.
  • Reconocer los esfuerzos que van más allá de lo solicitado.
  • Predicar con el ejemplo
• Gestionar la diversidad
  • Identificar posibles objetivos personales para minimizarlos o convertirlos en objetivos grupales.
  • Buscar la cohesión del grupo (armonizar costumbres, culturas, etc.).

A su vez, aparte de los procesos internos propios de la gestión del proyecto y las relaciones interpersonales, los proyectos se gestan y ejecutan dentro del ámbito de una organización. Actualmente podemos encontrar compañías cuyo negocio principal es la ejecución de proyectos, por ejemplo en el sector de la Consultoría y la Auditoría. Ese es el escenario más positivo, dado que toda la organización se encuentra orientada hacia la gestión de proyectos.

Sin embargo, la mayoría de empresas tienen una estructura jerárquica constituida por departamentos con funciones diferenciadas y empleados que realizan tareas específicas, cuya movilidad tiende a ser más bien esporádica. En este tipo de escenario, la ejecución de un proyecto (que como se ha establecido es temporal) con empleados internos presenta un escenario más difícil de gestionar (esta es una de las razones por las que en multitud de ocasiones los proyectos son contratados a consultoras y auditoras externas).

Esta segunda situación puede aportar empleados con “Silo Mentality”, es decir, personas cuyos objetivos se encuentran ligados a su área funcional y no al proyecto al que han sido asignados; puede que no les importe el éxito del proyecto, dando preferencia a cumplir con sus obligaciones estables de su unidad departamental. Esta problemática puede bloquear la cooperación del equipo de trabajo (horitzontal thinking).

En definitiva, el grado de madurez de la organización y los procedimientos internos establecidos pueden contribuir al éxito o fracaso del proyecto:

• Si la organización trabaja habitualmente en proyectos, se dispone de pautas ya definidas.
• Vías de comunicación formal: Si son muy rígidas pueden entorpecer el trabajo
• Vías de comunicación informal (amistades, conocidos, etc.): Si son muy frecuentes puede producir desinformación

Finalmente, PMBOK establece que para poder considerar que un proyecto ha sido exitoso se deben cumplir las siguientes expectativas:

• Nivel I. Alcanzar los objetivos del proyecto
• Nivel II. Eficiencia del proyecto.
  • Nivel de interrupción del trabajo del cliente.
  • Eficiencia en el uso de los recursos
  • Crecimiento del número de miembros del equipo
  • Gestión de conflictos
• Nivel III. Utilidad para el usuario/cliente final.
  • ¿Ha sido solucionado el problema inicial?
  • ¿Se han incrementado los beneficios o se ha producido ahorro real?
  • ¿El usuario se encuentra actualmente usando el producto?
• Nivel IV. Mejora organizacional: Aprender sobre la experiencia

Jefe de proyecto

Un jefe de proyectos o project manager tiene las siguientes responsabilidades:

• El proyecto: Objetivos de coste, calendario, funcionalidad y calidad.
  • La organización
  • Retorno de la inversión.
• Flujo de información: proporcionarla de forma proactiva, si un supervisor se sorprende de algún dato es que no hemos informado correctamente.
• El equipo: Proporcionar feedback y reconocimiento.
• Sobre él mismo: Crecimiento personal.

Por otra parte, el jefe del proyecto se enfrenta constantemente a retos entre los que se pueden encontrar los siguientes:

• Responsabilidad versus Ausencia de autoridad
  • Alto nivel de responsabilidad.
  • Trabajo con personas sobre las que no existe una autoridad directa.
• Objetivos no realistas
  • Es uno de los problemas más habituales.
  • Refuerza la idea de analizar y planificar correctamente el alcance del proyecto.
• Orientación funcional
  • Las personas tenderá a centrarse en su área de conocimiento funcional.
  • Es más importante su área funcional que el proyecto dada su temporalidad.
• Conflicto fundamental sobre la incertidumbre
  • Toma de decisiones rápidas con poca información.
  • Estimaciones de rango (e.g. costes)
  • Intentar hacer entender las dificultades de las estimaciones a los superiores y a los miembros del equipo.

Con la finalidad de afrontar exitosamente las responsabilidades y retos que presenta la gestión de proyectos, un jefe de proyectos debe mejorar de forma constante las siguientes habilidades:

• Gestión del proyecto: Herramientas para la planificación y monitorización.
• Relaciones interpersonales
  • Capacidad de liderazgo, negociación y delegación.
  • Capacidad comunicativa oral y escrita
  • Resolución de conflictos.
  • Habilidades para desarrollar el rol de mentor (coaching)
• Conocimiento tecnológico
  • Conocimiento de la industria y de las áreas tecnológicas
  • Conocimiento del producto y/o procesos
  • Habilidades de diseño
• Habilidades personales
  • Honestidad, integridad
  • Pensar globalmente
  • Alta tolerancia a la incertidumbre y a la ambigüedad
  • Persuasivo y asertivo
  • Abierto y accesible
  • Decisivo
  • Comercial. Capacidad para vender ideas o las propias virtudes del proyecto.
  • Profesor. Transmitir conocimiento a los miembros del equipo.

Definición del proyecto

La definición del proyecto se encuentra constituida por las siguientes fases:

• Fase I. Entender el problema o la oportunidad.
• Fase II. Identificar la solución más optima
• Fase III. Desarrollo de la solución y elaboración de un plan
• Fase IV. Lanzamiento del proyecto

Fase I. Entender el problema o la oportunidad.

Es fundamental identificar la necesidad real que el proyecto pretende cubrir. El trabajo se evaluará en función de si esta necesidad ha sido cubierta satisfactoriamente o no.

En primer lugar se requiere diferenciar entre necesidad y solución. Una necesidad:

• Describe el fin para cliente
• Especifica metas y objetivos
• Deja abierta la pregunta de cómo hacerlo.
• La respuesta al porque se esta haciendo debe apuntar a una justificación de negocio.

En cambio, una solución:

• Describe los medios para el equipo
• Especifica estrategias e ideas para conseguir las metas y objetivos.
• Especifica cómo hacerlo.
• La respuesta al porque se esta haciendo debe apuntar al requerimiento del cliente.
• Preguntar para identificar la necesidad real puede hacer sentir incomodo a terceros por desconfiar de su criterio.

En base a estas definiciones, esta fase debe tener como output la generación del documento de requerimientos del proyecto, el cual no ofrece una solución sino que únicamente describe una necesidad. Este documento debe contener los siguientes apartados:

• Descripción del problema o oportunidad
• Impacto o efecto del problema
• Identificar quien o que se encuentra afectado por el problema
• Impacto de ignorar el problema
• Situación deseada
• Beneficios asociados a conseguir la situación deseada
• Alineación con la estrategia de la organización
• Conflicto de compatibilidades con otras áreas de la organización
• Incertidumbres
• Suposiciones clave
• Limitaciones de la solución
• Consideraciones del entorno
• Información histórica de soporte

A partir de la recopilación de toda esta información, se requiere valorar nuevamente si merece la pena resolver el problema y determinar si existe una solución potencial.

Fase II. Identificar la solución más óptima

Con objeto de identificar soluciones que cubran la necesidad establecida se puede seguir el siguiente procedimiento:

• Brainstorming grupal con miembros del futuro equipo de trabajo o stakeholders.
• Comprobar en que grado satisfacen los planteamientos del documento de requerimientos del proyecto.
• Seleccionar entre 2 y 5 soluciones candidatas.

Para las soluciones candidatas seleccionadas conviene realizar un análisis detallado para identificar cual de ellas es la que mejor se adapta a la necesidad a cubrir e implica un coste asumible.

Análisis financiero (Costes vs Beneficios):

Para validar la viabilidad financiera del proyecto es necesario identificar los flujos de entrada de dinero que este puede generar, por ejemplo beneficios obtenidos por la implementación del proyecto (incremento en ventas, reducción en costes, etc…) y los gastos que representa la puesta en marcha y gestión del proyecto.

Por tanto, estimando la magnitud de los diferentes cash flows y calculando los 4 indicadores básicos, podemos identificar que proyecto nos aporta una mayor rentabilidad financiera.

Conviene estudiar al menos los siguiente indicadores:

• Net Present Value (NPV). Determina cuanto dinero va a generar el proyecto teniendo en cuenta el valor del dinero en el tiempo.
• Internal Rate of Return (IRR). Determina la rentabilidad de la inversión.
• Payback period. Determina cuando se recuperará la inversión (NPV = 0).
• Cash hole. Determina la máxima inversión necesaria.

Análisis no financiero (Modelo de puntuación de factores ponderados – Decision matrix)

El análisis mediante el modelo de puntuación de factores ponderados (“Decision Matrix”) se inicia mediante la elaboración de un listado de atributos a valorar. Para cada uno de ellos se establece una ponderación y se asignan puntuaciones que denoten el nivel de cumplimiento de cada una de las soluciones candidatas:

Ventajas:

• Permite el uso de diversos datos, incluidos los financieros.
• Permite la implicación de gerencia y el análisis de sensibilidad.

Desventajas:

• Proceso altamente subjetivo.
• Muestra el atractivo del proyecto pero no representa una justificación de negocio.

Aparte de los análisis financieros o de matrices, la decisión final sobre que solución escoger se puede basar en el uso de otras herramientas:

• Estudios de mercado
• Pruebas piloto. Prueba en área limitada.
• Prototyping. Construcción de una pequeña parte del proyecto para validar las correctas predicciones.
• Simulación por ordenador.

En definitiva, los análisis efectuados no solo ayudaran a elegir una solución sino que también permitirán determinar si las soluciones son viables y si vale la pena continuar con el proyecto.

Fase III. Desarrollo de la solución y elaboración de un plan

En esta fase se desarrollará en un mayor detalle la solución escogida mediante el uso de un Logframe (esquema básico de definición del proyecto).

El logframe se encuentra dividido en varios niveles:

• Objetivo
• Propósito
• Resultados
• Actividades

Para cada uno de estos niveles se debe especificar:

• Indicadores que permitan verificar la evolución.
• Medios para obtener la información necesaria para constituir los indicadores.
• Supuestos clave y el riesgo asociado.

A partir de la presentación esquemática de los aspectos clave del proyecto, el logframe permitirá monitorizar y evaluar la evolución del mismo. Un logframe debe ser conciso y fácilmente comprensible por personas que se incorporan a mitad de proyecto.

Paralelamente a la elaboración del logframe, se requiere realizar un análisis de los stakeholders del proyecto con el objetivo de gestionar las relaciones y prever oposiciones.

Se considera stakeholders aquellos individuos o instituciones que:

• Pueden ganar o perder dependiendo del éxito del proyecto.
• Proveen fondos económicos
• Proveen recursos al proyecto
• Participa/trabaja en el proyecto
• Se encuentran afectados por el rendimiento del proyecto
• Se encuentran afectados por el resultado del proyecto

Ejemplos:

• Stakeholders internos: Cliente interno, Sponsor, El equipo de trabajo, Gerentes, Sindicatos, etc.
• Stakholders externos: Cliente externo, Usuarios, Instituciones reguladoras, Organizaciones (e.g. ecologistas), etc.

Para cada uno de los stakeholders identificados, crearemos la siguiente tabla mediante la cual podremos definir el objetivo a cumplir con cada uno de ellos:

Finalmente, se realizará el documento de definición de proyecto (secundario en función del tipo del proyecto) con la finalidad de:

• Identificar el trabajo a realizar.
• Durante la ejecución, permite identificar cuando se esta sobrepasando los limites y permite renegociar el contrato original.
• Establece el criterio para considerar completado el proyecto.
• Establece los criterios para considerar exitoso el proyecto.
• Permite llegar a acuerdos y facilitar la comunicación.

El nivel de detalle del mismo no tiene que ser excesivo (no se dispone de suficiente información para hacer estimaciones exactas), sino que se recomienda proporcionar valoraciones mediante rangos (e.g. costes entre 100.000 y 130.000, duración entre 17 y 19 meses).

En definitiva, el documento debe contener los siguientes apartados:

• Breve descripción del problema u oportunidad
• Breve descripción de la solución propuesta
• Descripción del trabajo y la estrategia de ejecución. Identificar las diferentes grandes tareas y sus interrelaciones. Parte más importante del documento. Será la base para el WBS.
• Entregables acordados.
• Criterios de finalización de proyecto.
• Riesgos e incertidumbres.
• Suposiciones.
• Plan preeliminar de ejecución.
• Listado de los stakeholders involucrados.
• Criterios de éxito del proyecto.

Fase IV. Lanzamiento del proyecto

Antes de realizar el lanzamiento, es importante verificar que dispondremos de todos los recursos necesarios. Una vez confirmado este aspecto, se requieren dos pasos: obtener la aprobación definitiva de la dirección y reunir al equipo de trabajo seleccionado para informarlos del proyecto en el que van a participar.

De cara a la aprobación por la dirección, es recomendable la elaboración de un documento de propuesta que contenga los siguientes apartados:

• Breve descripción de las necesidades
• Acciones recomendadas
• Beneficios
• Riesgos a asumir si se lleva a cabo la acción
• Riesgos a asumir si no se realiza ninguna acción
• Costes y ahorros (estimaciones en rangos de valores)
• Calendario
• Métricas (como se medirá el resultado para valorar el éxito)
• Incertidumbres
• Suposiciones
• Limitaciones
• Apoyo requerido
• Listado de organizaciones que deben involucrarse y en que medida
• Impacto en el resto de la organización
• Sponsorship. Grado de apoyo activo por parte de la dirección.
• Factores críticos para el éxito.

Por otra parte, la reunión inicial con el equipo de trabajo (Kickoff meeting) debe encontrarse dirigida hacia los siguiente objetivos:

• Reconocer la formación oficial del equipo.
• Indicar cuales son las expectativas.
• Promover la cohesión del grupo.

Construir y mantener un equipo efectivo.

El equipo de trabajo es una de las partes claves del proyecto. Antes de iniciar el trabajo, en el Kick-off meeting por ejemplo, conviene anticiparse a las preguntas y ansiedades del equipo:

• ¿Me conviene el proyecto?
• ¿Que se espera de mi?
• ¿Como será el trabajo en equipo?

Cada equipo es un mundo y su evolución depende en gran parte de las capacidades y experiencias de los miembros del mismo. No obstante, en términos generales se podrían listar las siguientes fases evolutivas:

• Formación
  • Los miembros del equipo requieren adquirir conocimientos sobre el proyecto y comprobar su relación con el resto.
  • El jefe de proyecto debe organizar y proveer la máxima información.
• Reacción
  • En base a lo aprendido, los miembros del equipo valoran los objetivos, roles y relaciones establecidas. Puede dar lugar a conflictos.
  • El jefe de proyecto debe guiar e intentar llegar a soluciones pactadas para los conflictos generados.
• Normalización
  • Si se superan los posibles conflictos de la etapa anterior, se pasa a la normalización mediante la creación de normas de conducta.
  • El jefe de proyecto debe animar a cada uno de los miembros a participar más activamente. Potenciar la sensación de propiedad por parte de los miembros hacia sus objetivos y tareas.
• Acción
  • El equipo funciona con un buen grado de autonomía, produciendo resultados de calidad.
  • El jefe de proyecto debe ser un facilitador del flujo de trabajo.

Principios de la planificación y estimación.

Toda planificación se ve determinada por las siguientes dimensiones:

• Coste
• Tiempo
• Ámbito (scope)

Los fallos más habituales al realizar una planificación son los siguientes:

• No planificar por falta de tiempo o por la presión de los deadlines.
• No planificar en suficiente detalle. Se recomienda que el desglose de tareas a realizar llegue hasta aquellas que tengan una duración de:
  • 40-80 horas de trabajo
  • 4% de la duración estimada total del proyecto
• No mantener la planificación actualizada

Las estimaciones únicamente son predicciones aproximadas sobre elementos inciertos. Por tanto, para llevarlas a cabo pueden emplearse diversas estrategias:

• Preguntar a la persona que va a hacer la tarea
• Preguntar a un experto en la materia
• Usar datos históricos
• Utilizar pruebas o simulaciones
• Preparar la estimación tu mismo

Planificación

Definiciones previas:

• Actividades o tareas: Elementos de trabajo que consumen recursos, tienen una duración limitada y un coste determinado.
• Paquetes de trabajo: Conjunto de actividades que generan un entregable o una meta significativa.

Toda planificación de proyectos se inicia mediante la elaboración del Work Breakdown Structure (WBS). El WBS es una herramienta visual que permite identificar las diferentes tareas de un proyecto y consiste en una estructura arbórea de diversos niveles.

La elaboración debe estar centrada en la definición de piezas de trabajo, sin tener en cuenta limitaciones temporales, dependencias, recursos, etc…

Ejemplo:

El WBS es una modelo visual ideal para la presentación a la dirección dado que ofrece una perspectiva real de todo el trabajo que el proyecto implica. Por otra parte, proporciona una estructura lógica que facilita la determinación de la duración y coste de cada tarea, además de la asignación de recursos y responsables.

Continuando con la planificación, para cada tarea del WBS se debe estimar:

• Duración
• Coste
• Ámbito (Trabajo a realizar)
• Responsable
• Recursos
• Relaciones con otras tareas

En la identificación de responsables se puede hacer uso de la “Responsibility Assignment Matrix” (RAM), mediante la cual se define como los participantes interactúan en las diferentes tareas. En general, permite identificar el tipo de interacción (responsable, requiere aprobación, soporte, etc.). Por ejemplo:

A partir del WBS y la RAM, el siguiente paso es la elaboración de un diagrama de red.

Definiciones:

• Actividad crítica: Aquella tarea que no puede desplazarse en el tiempo.
• Camino crítico: El camino más largo del diagrama lógico de red.
• Slack: Margen de tiempo que una tarea se puede adelantar o atrasar.
• Forward/Backward pass: Técnica para analizar la cantidad de slack de cada tarea.
• Milestone: hito.

En este punto, se debe elaborar un diagrama de red partiendo de las tareas identificadas en el WBS. Por una parte se especificaran las relaciones entre actividades y por otra se considerarán los recursos necesarios y las limitaciones que estos imponen. Para cada tarea se debe contemplar:

• Que actividades deben completarse antes de iniciar la tarea.
• Que actividades no pueden empezar hasta que la tarea no este acabada.
• Que tareas pueden ser llevadas a cabo en paralelo.
• Esfuerzo: horas de trabajo por parte de la persona asignada
• Duración: Ventana de tiempo en la que la actividad se completará, variará en función de la disponibilidad de los recursos, periodos de inactividad, fines de semana, vacaciones, etc…

A partir de esta información, es posible desarrollar el diagrama de red:

Mediante este diagrama podemos calcular el camino crítico utilizando la técnica forward/backward passes. Esto significa la ejecución de los siguientes cálculos en 2 pases:

• Forward pass
  • La primera actividad empieza en el día 0
  • El día final se obtiene de sumar el inicial más la duración.
  • Para los siguientes bloques se escoge el día de fin mayor de los anteriores.
• Backward pass
  • Se parte del día final de la última actividad.
  • Se calcula el día inicial de la última actividad, restando la duración al día final resultante del forward pass.
  • Para los anteriores bloques se escoge el día de inicio menor de los siguientes.

Para cada tarea, la diferencia entre el día de inicio según el forward pass y el día de inicio según el backward pass es el slack. El slack es el margen de tiempo que una tarea se puede adelantar o atrasar. Las tareas sin slack pertenecen al camino crítico, dado que un retraso de estas (por mínimo que sea) impacta en todo el proyecto.

Finalmente podremos comparar la fecha de finalización resultante con la estimada y evaluar si es posible cumplir las expectativas.

Ejemplo del diagrama de red con los cálculos efectuados:

En este punto, en base a las duraciones de las diferentes tareas, debemos desarrollar el diagrama de Gantt:

De forma complementaria, se debe llevar a cabo una gestión de los costes en los que el proyecto va a incurrir. Para ello se identificarán los costes asociados a cada tarea en función de los recursos utilizados:

• Coste directo: gasto que se puede identificar rápidamente y es generado por la ejecución del proyecto
  • Mano de obra
  • Materiales
  • Proveedores y equipamiento
  • Formación
  • Viajes y otros gastos
• Costes indirectos: gastos que dan soporte a los servicios generales, ambiente organizacional, etc…
  • Instalaciones
  • Costes administrativos

Gestión de la incertidumbre y el riesgo.

Antes de iniciar esta sección, es necesario establecer que entendemos por incertidumbre y riesgo:

• Incertidumbre: Ausencia de información o conocimiento respecto a una acción, decisión o evento.
• Riesgo. Cantidad de incertidumbre existente.

Una aproximación válida para la gestión del riesgo conllevaría la identificación de las amenazas existentes y la cuantificación de la severidad de las mismas (probabilidad de ocurrencia e impacto):

Para las amenazas de mayor severidad se puede optar por diseñar una respuesta que siga alguna de las siguientes estratégias:

• Evitar la amenaza siguiendo otro camino
• Transferir la responsabilidad del riesgo a otra persona
• Asumir la existencia del riesgo y solo actuar si este aparece
• Prevenir para intentar reducir la probabilidad de ocurrencia
• Intentar mitigar el impacto
• Realizar un plan de contingencia y definir las acciones a llevar a cabo en caso de materializarse el riesgo.

Uno de los puntos más difíciles de abordar y que mayor riesgo puede presentar son las estimaciones de tiempo. Una técnica comúnmente utilizada para intentar reducir este riesgo es el uso del PERT: Program Evaluation and Review Technique.

El PERT intenta integrar la variabilidad de las estimaciones, obligando a definir para cada actividad:

• Una estimación pesimista
• Una estimación optimista
• La estimación más probable

En base a estos 3 parámetros, se realiza el siguiente cálculo:

Ajuste al riesgo = (Pesimista + Optimista + 4*Más probable) / 6

El resultado de la misma se utilizaría en la elaboración del diagrama de red que se ha presentado en la sección anterior.

Control y seguimiento del proyecto

El objetivo del control consiste en detectar desviaciones respecto a la planificación inicial y realizar estimaciones sobre cual será la desviación al final del proyecto.

Desviación final del proyecto = Desviación actual calculada + Desviación futura estimada

En términos generales, puede llegar a ser más valioso estimar que al final del proyecto se habrá consumido un 10% más de lo presupuestado, que indicar que actualmente se lleva consumido un 7% de lo presupuestado.

Suele ser fundamental focalizarse en la desviación final dado que permite tomar decisiones en función del objetivo final y no al problema puntual actual.

Por regla general, en cualquier proyecto se deben controlar la siguientes dimensiones:

• Calendario
• Coste
• Funcionalidades
• Calidad

Con el objetivo de ejercer las tareas de control se requiere recopilar la siguiente información de forma periódica:

• Calendario
  • Fecha de inicio y fin planificada de cada tarea
  • Fecha de inicio y fin de las tareas ya realizadas
  • Fecha de inicio de las tareas en ejecución.
  • Progreso realizado de las tareas en ejecución.
• Coste
  • Gastos o horas de trabajo estimadas para cada tarea
  • Consumo de las tareas ya finalizadas.
  • Consumido hasta el momento por las tareas en ejecución.
• Funcionalidades
  • Resultado planificado (ámbito)
  • Predicción del resultado (ámbito)
• Calidad
  • Resultado planificado (profundidad)
  • Predicción del resultado (profundidad)

La recopilación de la información se suele efectuar por alguna de las siguientes vías:

• Reuniones periódicas: La periodicidad no debe superar el 4% de la duración total del proyecto.
• Formularios y plantillas: Proporcionar una hoja de calculo con las tareas del WBS junto a las variables a controlar (fechas, costes, etc.) a cada miembro del equipo y solicitar que se mantenga actualizada.
• Management by Walking Around (MBWA): Comprobar la motivación y visión de los componentes en reuniones informales

El project manager debe analizar la información mediante herramientas informáticas o manuales que le permitan:

• Disponer de un diagrama de Gantt que muestre:
  • Baseline de la planificación inicial
  • Diagrama según estado actual (tareas ya realizadas, tareas en ejecución y nuevas estimaciones para las tareas pendientes)
• Gráfica acumulativa del gasto en el tiempo:
  • Planificada
  • Actual junto a la nueva proyección
• Tabla de gastos:
  

En el momento en el que se detecten desviaciones, el project manager se encuentra obligado a elegir alguna estrategias de recuperación, considerando siempre las posibles penalizaciones que estas suponen:

• Recuperar la desviación en tareas futuras
• Añadir recursos
• Aceptar substituciones
• Utilizar métodos de trabajo alternativos
• Ofrecer incentivos para incrementar el rendimiento
• Renegociar el coste y el calendario del proyecto
• Reducir el ámbito/alcance

Cierre del proyecto

El cierre del proyecto puede llegar a ser confuso y lento dada la habitual perdida progresiva de recursos.

La mejor forma de afrontar esta etapa es elaborando una lista de tareas a realizar (punch list) para dar por concluido el proyecto. Es importante validar que los criterios de finalización establecidos al inicio del proyecto se encuentran cubiertos.

Con el objetivo de aportar valor al equipo y habilitar la aplicación de estrategias de mejora continua, resulta interesante realizar las siguientes tareas en el cierre del proyecto (o incluso durante la ejecución) dado que puede resultar positivo para el rendimiento del equipo y la satisfacción del cliente:

• Obtener información sobre el nivel de satisfacción del resultado.
  • Por parte del cliente interno/externo.
  • Por parte de cada uno de los miembros del equipo.
• Reconocer méritos.
• Sugerencias de mejora.
• Transferir el conocimiento adquirido durante el proyecto.

Finalmente, cabe destacar que la documentación resultante de la planificación y del control pueden servir como base histórica para futuros proyectos con características similares.

Conclusión

Las herramientas y buenas prácticas ofrecidas por el Project Management Institute mediante el PMBOK constituyen una aportación de valor para la gestión de proyectos. Si bien, en su totalidad no resultan tan ágiles y flexibles como otras metodologías (p.ej. Scrum, Lean, etc.), si es posible extraer ideas y técnicas que contribuyan al éxito en la gestión de proyectos y personas.

21 Responses to “PMBOK, Project Management / Gestión de proyectos”