Nuestro proyecto ha sido aprobado bajo términos Cost Plus Incentive Fee (CPIF), un tipo de contrato muy poco utilizado en España pero bastante en Estados Unidos, especialmente cuando se trabaja con la defensa. En nuestro caso se ha definido que si llegamos a realizar el proyecto con el coste de $300.000, nos podemos llevar el 10% como puro beneficio. Pero si conseguimos entregar por debajo de este coste el ratio 80/20 será aplicado, de forma que todo lo que se ahorre el 80% es puro ahorro para el comprador y el 20% es el incentivo del vendedor. El coste real del proyecto ha sido $275.000, por lo que debemos calcular el coste real que supone para el cliente a fin de saber lo que nos debe pagar. La forma de calcularlo es la siguiente:

Para superar el incertidumbre asociado con el cálculo PERT podemos usar simulación Monte Carlo para ver como se distribuye el riesgo desde el punto de vista cualitativo y probabilista. La simulación se genera a partir de un valor aleatorio o dentro de un rango pre-establecido por cada variable en cuestión por ejemplo, duración, coste, fecha de entrega, etc. Se ejecutan n ciclos de simulaciones, lo que permite obtener una distribución de riesgo y saber que factores son más críticos para evitar un determinado resultado en el proyecto. Normalmente se usa ese tipo de simulación sobre las rutas en diagrama de red, cálculo de slack’s, riesgos en camino crítico, etc. En MS Project por defecto no existe esa funcionalidad pero hay complementos de terceros que se integran con MS Project perfectamente. Hay siguientes alternativas:

• Pertmaster de Pertmaster Limited
• Deltek Risk+ de empresa Deltek
• RiskyProject por Intaver Institute
• @RISK for Project por Palisade

El que más me gusta es @RISK, aunque no he podido probar otros simuladores con el rigor que debería. Si tienes experiencia con estos programas u otros, no dudes en añadir un comentario.

Los ejecutivos y vendedores que buscan cerrar un contrato pueden necesitar conocimientos de project management incluso antes de que el PM es oficialmente involucrado en el proyecto. El proyecto es una idea todavía, o una propuesta enviada a concurso público. A veces en esta fase la parte más importante donde podemos fallar es procurement – la selección de tipo de contrato, adecuándose al nivel de riesgo y datos de alcance disponibles. Normalmente en concursos del sector público siempre encontraremos en el pliego el tipo de contrato que requiere el comprador. En España el FFP (precio cerrado) es el tipo de contrato que más utiliza el gobierno y las autonomías. Pero lo más adecuado sería ajustarse a la situación ya que con FFP la adjudicación del contrato puede ser la ruina. Para casos cuando el alcance esta bien delimitado el FFP es una buena idea, en caso contrario CPPC (Costo más porcentaje de costo) o CPFF (costo más tarifa fija) son buena idea ya que el primero transfiere el riesgo al comprador y el segundo lo distribuye entre comprador y vendedor. El contrato de tipo T&M (tiempo y material) suele usarse cuando el esfuerzo es continuo y más bien incierto como en casos de ejecución de proyectos de investigación o estudios de viabilidad.

Aunque una solicitud para presentarse al examen de PMP de Project Management Institute (PMI) puede ser suspendida por diferentes razones, hay una razón que suele causar la mayor parte de las incidencias. Los formularios de solicitud contienen un apartado dónde los candidatos deben acreditar su experiencia en gestión de proyectos, proporcionando las horas invertidas, por cada grupo de procesos. Cada uno de los procesos a grandes rasgos tiene que tener un porcentaje específico de horas del total de proyecto. Si reportamos horas que no coinciden con el rango definido en PMBOK, la solicitud puede ser suspendida para su investigación. Las mejores prácticas dictan que La fase de iniciación debe tener 6-11% de horas de proyecto, planificación 20-26%, ejecución 45-50%, monitorización y control sobre 10-15% y el cierre cerca del 5-6% del total de horas. Estos valores son aproximados. Consultar PMBOK para datos más precisos.

Toda la información que vimos en las dos primeras partes es bastante teórica ahora vamos a usar un ejemplo de la vida real y aplicarle el conocimiento anterior sobre una sola actividad. Imaginemos que hay una tarea “A” que tiene 36 días de estimación pesimista, 21 días de estimación más probable y 6 días de estimación optimista. A veces nos preguntarán que probabilidades hay que la actividad A se complete en un periodo por ejemplo de 16 a 26 días para nuestro caso.

1. Cálculo de desviación estándar de la tarea nos da 5 días: 2. Ahora vamos a calcular la duración PERT de la tarea que nos da 21 días:

3. Determinamos el rango de 1 desviación estándar:

Entonces, simplificando 1 desviación estándar es la distancia a las dos lados de la media de una distribución normal donde de forma estándar caen el 68,26% (la respuesta) de todos los valores.

En el sector de fabricación de software o en proyectos de diseño y desarrollo de aplicaciones informáticas, infraestructuras de red, monitorización de SLA’s y calidad de servicio, etc. la causa más frecuente que hace que un proyecto sea un fracaso y/o se entregue fuera de plazo y presupuesto es falta de visión en las fases iniciales y poca inversión de esfuerzo y tiempo en documentación de requerimientos y su gestión de configuración (cambios, enmiendas y etc.). La gestión correcta de requerimientos durante todo el proyecto es imprescindible, y es especialmente importante al principio para reducir las probabilidades del fracaso.

Cuando ya disponemos de nuestro cálculo PERT para cada una de las actividades del proyecto, debemos continuar y definir la varianza individual de estas tareas. Entonces teniendo 3 desviaciones estándar de duración: optimista, pesimista y la más probable; por lo tanto hay 6 desviaciones estándar entre ellos, lo que puede ser calculado con la siguiente fórmula para cada actividad: A continuación vamos a determinar el camino crítico del proyecto ya que su duración determina la duración total del proyecto. Hay que tener en cuenta que en un solo proyecto pueden existir más de un camino crítico. Por lo tanto la varianza del camino crítico puede ser calculada sumando las varianzas individuales de las tareas situadas en el camino crítico.

A continuación incluyo algunas alternativas a MS Project Server. Gradualmente iré estudiándolas e incluiré datos adicionales e comparativas. Si alguien tiene experiencia trabajando con estas aplicaciones no duden en añadir comentarios.

• @Task – http://www.attask.com/
• Vertabase Pro – http://www.vertabase.com/
• Copper Project – http://www.copperproject.com/
• Creativa Manager Pro – http://www.creative-manager.com/
• Tracker Suite – http://www.trackersuite.net/
• ProjectTrack 2007 – http://www.ilore.com/
• ValleySpeak Project Server – http://www.valleyspeak.com/
• Project Planner – http://www.smartworks.us/
• B-Kin Project Monitor – http://www.b-kin.com/

La Program Evaluation and Review Technique (PERT) es una herramienta más flexible que la herramienta Critical Path Management (CPM) ya que PERT permite asignar una distribución probabilística y proporcionar un cierto nivel de aleatoriedad a la hora de definir las duraciones de tareas y rutas (críticas o no) en proyectos.

A diferencia del tradicional CPM (solo 1 estimación por tarea), PERT [β ó t_e – Duración Esperada] permite definer 3 estimaciones: Optimista [a] (todo va bien), Más Probable [m] (caso más probable) y Pesimista [b] (escenario pesimista negativo).

Para cada actividad entonces tendremos 3 estimaciones pero para poder usarlas dentro de un análisis de red (PDM/ADM) necesitamos convertir estos datos en un solo valor aplicando una distribución beta. La distribución beta es un método estadístico que permite obtener un valor promedio ponderado a partir de mínimos y máximos.

Aplicaremos la siguiente fórmula para obtener un valor de duración por cada actividad en red:

La WBS también llamada en español EDT (Estructura de Descomposición del Trabajo) puede ser organizada estructuralmente de diferentes maneras. La forma más lógica IMHO es hacerlo es empezar con datos de programa, proyectos, fases, agrupaciones de cuentas de control y a continuación paquetes de trabajo hasta representar todo el trabajo y solo el trabajo necesario para conseguir el objetivo del proyecto/programa. Por ejemplo si tenemos un proyecto con el fin de realizar un estudio de viabilidad la plantilla de WBS o Gantt en MS Project podría ser la siguiente:

• [Código de Proyecto] {Sumario Breve} (Versión "x") <– Nivel 1 – Sumario proyecto/programa
  • Preparación <– Nivel 2 – Fase – Tareas preliminares necesarias para poder empezar la siguiente fase.
    • Paquete de trabajo 1 <– Nivel 3 – Paquete de trabajo.
    • …
  • Ejecución <– Nivel 2 – Fase – Tareas de la fase de ejecución o desarrollo.
    • …
  • Project Management <– Nivel 2 – Fase – Tareas de gestión de proyecto y de configuración.
    • …
  • Reservas y Buffers <– Nivel 2 – Agrupación de cuentas de control necesarias para uso de TOC (Theory of Constraints de Goldratt).
    • …
  • Hitos <– Nivel 2 – Hitos del proyecto agrupados