04 mayo 2017

Metodología de Gestión de Proyectos Tradicional y de Desarrollo ágil

En el libro “Gestión de proyectos en el mundo real” de los autores Bonnie Biafore y Teresa Stover”, se aborda de manera clara y sencilla las dos metodologías de gestión de proyectos más comunes, como son la gestión de proyectos tradicional en cascada y la gestión de proyectos de desarrollo ágil, iterativo o de planificación continua-incremental. Algunos de los párrafos más significativos se reproducen más adelante.

Independiente de la metodología de que se trate, seguirá la estructura estándar definida en la guía PMBOK (Project Management Body of Knowledge) del Project Management Institute (PMI), desglosando la gestión de proyectos en cinco grupos de procesos básicos: iniciación, planificación, ejecución, seguimiento y control (monitorización) y cierre. El cómo y cuándo es lo que diferencia unas metodologías de otras.

 En el caso de proyectos sencillos y claramente definidos, lo más lógico es avanzar en los cinco grupos en la manera en que se describe en la imagen anterior (Tradicional), mientras que en el caso de otros proyectos más complejos o menos definidos, los procesos pueden tener que repetirse varias veces (Iterativa o Desarrollo).


GESTIÓN DE PROYECTOS TRADICIONAL EN CASCADA

El enfoque tradicional de gestión de proyectos, también denominado en cascada, se refiere a la forma en que los grupos de procesos fluyen unos detrás de otros: iniciación, planificación, ejecución del plan, seguimiento y control hasta la finalización completa del trabajo, y por último el cierre del proyecto.

El enfoque en cascada funciona bien cuando el objetivo y la solución del proyecto son claros. Es necesario saber lo que hay que hacer para poder pasar de una fase a otra del proceso de gestión de principio a fin. Cuanta más información se tiene, mejor funciona la gestión en cascada.

A continuación se describen algunas de las características de la metodología tradicional de gestión:

> Simplicidad: Los proyectos que son simples o familiares son los mejores candidatos para el enfoque en cascada porque se conocen todos los datos necesarios para realizar el proyecto.

> Nivel de riesgo bajo: El riesgo es sinónimo de incertidumbre, así que a menos riesgo más seguridad. Por ejemplo, si se ha ejecutado antes proyectos similares, podrá estar razonablemente seguro de que los requisitos están completos. Conoce los riesgos y los errores a evitar y sabe cómo afrontarlos si se presentan.

> Tecnología familiar: Conoce los fallos técnicos y sabe cómo resolverlos. Los miembros de su equipo son productivos porque ya están familiarizados con la tecnología.

> Recursos experimentados: Si los miembros del equipo ya han trabajado antes en proyectos similares, conocerán el trabajo y la tecnología y serán, por tanto, más productivos. Además, sabrán qué problemas pueden aparecer y qué hacer para evitarlos.


GESTIÓN DE PROYECTOS DE DESARROLLO ITERATIVO, ÁGIL O DE PLANIFICACIÓN CONTINUA-INCREMENTAL

Los proyectos cuya solución no está claramente definida, lo cual ocurre habitualmente, requieren un enfoque diferente. Cuando no se conoce la solución, no se puede elaborar un plan conjunto para todo el proyecto. La solución se tiene que ir identificando poco a poco, a medida que se va avanzando en el proyecto. Las metodologías de gestión de proyectos de desarrollo iterativo, ágil o de planificación continua emplean iteraciones para ir desvelando la solución gradualmente.



En el enfoque iterativo, se planifica el resultado iteración por iteración como se muestra en la imagen anterior. Así, el cliente, por un lado, recibe el valor comercial antes y, por otro, proporciona sus opiniones y comentarios en cada paso de la solución, lo cual contribuye a ella.

Las metodologías llamadas de desarrollo iterativo y ágil demandan, además, mayor interacción entre los agentes. El cliente debe implicarse más estrechamente que en los proyectos tradicionales, debido a que la solución se va manifestando con el tiempo. El proyecto necesita los comentarios del cliente para proporcionar la solución que necesita.

Los equipos de proyecto suelen ser más pequeños, más especializados y sus miembros suelen colaborar de forma más estrecha y con menos supervisión.

Dadas las iteraciones que se ilustran en la figura anterior, algunos de los grupos de procesos de gestión de proyectos operan de un modo ligeramente distinto que en el caso tradicional:

> Planificación: Se puede desarrollar un plan de alto nivel para el proyecto, pero nunca tendrá el mismo nivel de detalle que un plan de proyecto tradicional. Los planes van siendo cada vez más detallados con cada iteración del proyecto.

> Ejecución: El equipo de proyecto es más pequeño y más autónomo. El trabajo se ejecuta iteración por iteración.

> Seguimiento y control: Se sigue monitorizando el progreso y aplicando correcciones, en su caso. No obstante, la frecuencia de distribución de los informes suele ser mayor debido a la corta vida de las iteraciones.

Cierre: Hay un proceso de cierre en cada iteración y uno final para cerrar el proyecto.


DESARROLLO ÁGIL INCREMENTAL EN PROYECTOS DE SOFTWARE

Como ejemplo, podemos observar las ventajas y debilidades que podría tener la gestión de un proyecto de software gestionado bajo la metodología ágil incremental.

Ventajas

•  En este modelo los usuarios no tienen que esperar hasta que el sistema completo se entregue para hacer uso de él. El primer incremento cumple los requerimientos más importantes de tal forma que pueden utilizar el software al instante.

• Los usuarios pueden utilizar los incrementos iniciales como prototipos y obtener experiencia sobre los requerimientos de los incrementos posteriores del sistema.

• Existe muy pocas probabilidades de riesgo en el sistema. Aunque se pueden encontrar problemas en algunos incrementos, lo normal es que el sistema se entregue sin inconvenientes al usuario.

• Ya que los sistemas de más alta prioridad se entregan primero, y los incrementos posteriores se integran entre ellos, es muy poco probable que los sistemas más importantes sean a los que se les hagan más pruebas. Esto quiere decir que es menos probable que los usuarios encuentren fallos de funcionamiento del software en las partes más importantes del sistema

Debilidades

•  La entrega temprana de los proyectos produce la creación de sistemas demasiados simples, que a veces se ven monótonos a los ojos del usuario que lo recibe.

•  La mayoría de los incrementos se harán en base a las necesidades del usuario. Los incrementos se estipulan antes de la entrega del proyecto, sin embargo hay que ver cómo se maneja el producto, para ver si necesita otros cambios además de los estipulados con anterioridad. Este problema no se ve frecuentemente, ya que la mayoría de las veces los incrementos estipulados suplen satisfactoriamente al usuario.

• Los incrementos no deben constar de muchas líneas de código ya que la idea de los incrementos es agregar accesorios concretos al programa principal (o funcional). Llenar los incrementos de muchas líneas de código provocaría que se perdiera la objetividad o base de lo que se trata en el desarrollo incremental específico.

• Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes que simplemente no estarán dispuestos a invertir el tiempo necesario.

• El trato con el cliente debe basarse en principios éticos y colaboración mutua, más que trabajar cada parte independientemente, defendiendo sólo su propio beneficio.

• La entrega de un programa que es parcial pero funcional puede hacer vulnerable al programa debido a la falta de robustez en su sistema, provocando que agentes ajenos puedan interferir con el correcto funcionamiento del programa en sí.

• Infunde responsabilidad en el equipo de desarrollo al trabajar directamente con el cliente, requiriendo de profesionales sobre el promedio.

• Sufre fuertes penalizaciones en proyectos en los cuales los requerimientos están previamente definidos, o para proyectos "todo/nada" en los cuales se requiere que se completen en un 100% el producto para ser implementado (por ejemplo, licitaciones)

• Otro punto muy importante es asegurarnos de que el trabajo se pueda cumplir tomando en cuenta los costos que podamos usar en nuestros propios recursos.


RESUMEN

La clave de la metodología de Desarrollo ágil, iterativo y creciente (o incremental), es diseñar un modelo inicial que permita el rediseño y la ampliación de funcionalidades. Aplicando esta metodología, se reducen los riesgos finales y se avanza en los proyectos indeterminados, satisfaciendo los requerimientos priorizados del cliente, de forma creciente.

La metodología de Desarrollo ágil, se diferencia de las metodologías tradicionales o de cascada, principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.

Los valores originales de la programación extrema vinculada a la metodología de Desarrollo ágil son: simplicidad, comunicación, retroalimentación (feedback), coraje y respeto.

11 noviembre 2016

Gestión de proyectos industriales y de mantenimiento con Microsoft Project. Lo que necesitas y más.

Curso de Microsoft Project









 Introducción
¿Tiene Vd. La suerte de trabajar en una empresa que gestiona proyectos de ingeniería o mantenimiento industrial?  Si es así, está de enhorabuena. La economía global está demandando de forma creciente servicios de ingeniería que faciliten el desarrollo de proyectos tanto de nuevos productos, como de mantenimiento de los existentes, pero no solo con eficacia y conocimiento, sino también cumpliendo plazos, respetando el presupuesto y optimizando recursos.

Esta oportunidad de negocio requiere de herramientas innovadoras que complementen su experiencia, como ocurre con el software Microsoft ProjectÒ, para la planificación y control de proyectos.

Anticípese a sus competidores y agregue valor añadido a sus propuestas con el uso adecuado de Microsoft Project.

Quizás conozca o haya usado esta herramienta para satisfacer las demandas habituales de su cliente, como un diagrama Gantt de la programación de los trabajos, un informa con las horas de trabajo de los recursos o incluso un plan de inversiones en el tiempo.

Pero Microsoft Project,  va mucho más allá. He aquí un recorrido de estas ventajas por el ciclo de gestión de su proyecto que no le dejará indiferente. Al menos es lo que me dicen los asistentes al término de su experiencia formativa.
 

Comienzo del proyecto
El proyecto empezará inicialmente en la fecha fijada, pero si usamos Microsoft Project  adecuadamente, podremos retrasarla o adelantarla “a posteriori” si es necesario, y todo se reprogramará automáticamente, sin ninguna dificultad.
 

Calendarios
En cualquier momento podrá adaptar los calendarios laborales del proyecto, de los recursos o incluso de las tareas, a cualquier necesidad horaria que se le presente.
 

Esquema de tareas e hitos
La creación del Esquema de Desagregación de los Trabajos E.D.T. (W.B.S. Work Breakdown Structure), que refleja el alcance de las tareas del proyecto, puede incluir múltiples niveles de jerarquía y su elaboración es rápida e intuitiva, en comparación con otras herramientas del mercado. Es entonces cuando podremos incluir tareas e hitos colaborativos que ayuden a otras áreas implicadas en el proyecto, como son aprovisionamientos, certificaciones, o simplemente identificadores de momentos importantes del proyecto. Estos hitos parciales, o totales, que a veces llevan consigo el cumplimiento de un plazo, podemos comunicarlos a través de claros y sencillos informes de resumen, para el cliente y otros “stakeholders” (interesados) del proyecto.

 
Estimaciones de tiempo
Una de las misiones del planificador es introducir las estimaciones del esfuerzo necesario para completar las tareas. Dependiendo del escenario de la tarea que queramos reflejar  (Duración fija ó Recursos fijos ó Trabajo fijo de los recursos ó/y Acortar la tarea con más recursos o turnos, etc.), introduciremos la información en Microsoft Project, quedando recogida fielmente toda la casuística del día a día de nuestro proyecto.

 
Vínculos entre tareas
¿Qué se necesita para poder comenzar la tarea? Microsoft Project pone a disposición del usuario 4 tipos de relaciones o vínculos entre tareas, que añadido a posibles adelantos y retrasos en la definición del enlace, componen un juego completo para adecuar la programación a la lógica de ejecución de los trabajos. Evitar el riesgo de retrasos por una inexacta definición de la red de precedencias, en la mayoría de los casos por desconocimiento, es obligatorio para el planificador del proyecto.

La ausencia de una red de precedencias bien construida, impide que haya un adecuado camino crítico, y por lo tanto Microsoft Project no podrá mostrar las holguras correctas de las tareas, ni facilitará la identificación de las que son críticas, que deberemos controlar y ajustar para cumplir con los plazos encomendados. Una técnica sencilla y experimentada, le ayudará a construir su red de manera fácil e interesante.
 

Fechas obligadas
¿Cómo impactará en la programación un retraso o adelanto en el aprovisionamiento de un material? ¿O en la entrega de especificaciones requerida a nuestro cliente? Estas son solo algunas de las restricciones que el usuario debe incluir cuanto antes en el plan del proyecto, para reflejar su auténtica realidad, implicando por otra parte y de manera visible, a terceros que aun siendo externos influyen en los plazos.

 
Recursos
En la mayoría de los casos, la clave del éxito de la gestión de un proyecto está en la optimización de los recursos, y aunque planificar con recursos en Microsoft Project es opcional, se debería conocer las posibilidades que nos brinda su gestión, aun cuando la mayoría de los que intervengan sean externos a nuestra organización.

La posibilidad de conocer de manera inmediata,  las horas de trabajo o incluso la cantidad de recursos asignados, eligiendo la periodificación por días, semanas, meses, etc., incluso agrupando por tipos de recurso mecánicos, eléctricos, auxiliares, etc. y también por empresa, son solo algunos de los informes que se pueden obtener para nuestro cliente, para el subcontratista o para nosotros mismos.

A través de un asistente, Microsoft Project nos muestra todos los recursos disponibles en el intervalo programado de cualquier tarea, incluso filtrando por los que además tengan un determinado perfil o capacitación (mecánico, eléctrico, electro-mecánico, soldador,…), y/o cualquier otra condición necesaria, con el fin de asignarlos sin conflictos de sobreasignación.
 

Sobreasignación de recursos
Parte de la optimización de los recursos en el proyecto puede venir de resolver los conflictos de sobreasignación. Para ello Microsoft Project nos ofrece una excelente herramienta automática de redistribución de los recursos, consistente en retrasar las tareas que se solapan en el tiempo con el mismo recurso asignado. Microsoft Project buscará la mejor manera de programar esas tareas con el fin de terminar el proyecto lo antes posible, como por ejemplo, encajando las sobreasignaciones menos críticas en holguras existentes y con el recurso disponible, ó si se prefiere, le marcaremos un orden de priorización de tareas para redistribuir los recursos en conflicto según nuestra conveniencia.

 
Costos
Valorar el costo del proyecto, aun siendo igualmente opcional, como ocurre con los recursos,  es realmente sencillo. Introduciendo una Tasa o precio por hora ó día para recursos laborales, o precio unitario para recursos materiales, Microsoft Project calculará un costo variable en función del tiempo ó cantidad que ha sido asignada a la tarea.  Incluso asignado el recurso tipo Costo, Compras por ejemplo, y escribiendo un importe, podremos obtener un interesante informe de reparto de las compras a lo largo del proyecto.

Con recursos o sin ellos, podemos valorar a partida alzada el costo de una tarea o un grupo de ellas. De esa forma tan simple obtendremos un plan de inversiones en períodos mensuales, anuales, semanales, e incluso diarios, pudiendo llevar los datos a Excel, o mostrando directamente en Microsoft Project el informe denominado Flujo de caja, con su curva S correspondiente.


 Ajuste de plazos
Todavía me sorprende la utilidad de aplicar técnicas de ajuste de plazo, basadas en mostrar además de indicadores gráficos de alerta, las holguras negativas debidas a limitación de fechas, y muy especialmente cuando hay diferentes plazos parciales que cumplir. Con esta técnica, el jefe de proyecto se centrará en aquellas tareas críticas que Microsoft Project propone, mostrando adicionalmente su posible contribución en días al ahorro de plazo para cumplir con todas las “deadlines” o fechas límite.

Y ¿Cómo afrontar la reprogramación de un proyecto que nos viene dado, con escasa consistencia y exceso de rigidez debido a la fijación desmesurada e innecesaria de fechas? La solución estriba en muchos casos en la creación de un nuevo plan que incorpore precisamente aquellas fechas límite que haya que respetar.
 

Seguimiento
Las peculiaridades típicas de los proyectos industriales y de mantenimiento exigen en muchos casos métodos simples de seguimiento, a veces por la celeridad con que se desarrollan los trabajos, o incluso por la dificultad de la monitorización en campo. Aplicar el método adecuado de seguimiento para cada proyecto es necesario para un control eficaz. En la mayoría de los casos de este tipo de proyectos, trabajar por excepción, dejando que Microsoft Project nos facilite los datos reales según el programa establecido, y el usuario rectifique y reestime los valores restantes pendientes de completar, suele ser una gran elección, que simplifica y agiliza el trabajo del jefe de proyecto.
 

Reprogramación
La reprogramación de los trabajos retrasados, a partir de la fecha de estado o monitorización es una potente opción de Microsoft Project. Esta opción, bastante desconocida pero necesaria, es con la que el jefe de proyectos debe cerrar el período de actualización, lo que le permitirá visualizar las consecuencias en plazo y recursos, y tomar las medidas de ajuste convenientes.

 
Variaciones
La elaboración de vistosos informes visuales con indicadores gráficos tipo semáforo por ejemplo, de las variaciones y desviaciones respecto a los planes previstos y líneas de base, facilitan eficazmente la comprensión y comunicación del estado del proyecto.


 Ignacio Martín – MVP Microsoft Project  – Noviembre 2016

 Si deseas información sobre el Curso de gestión de proyectos con Microsoft Project para tu empresa, solicítamelo pulsando aquí o bien  a través de mi dirección de correo:  Ignacio.mvp@microsoftProject.es o  telefónicamente al número +34 609156333.

18 abril 2014

Un proyecto

Hola Ignacio: Necesito hacerte una pregunta, ruego me entiendas.
Una empresa constructora.
Una arquitecta llevará el Microsoft Project, estará a su cargo. Los demás departamentos llevarán ese mismo proyecto, pero todos reportaran a ella.
Ella verá lo que hacen todos.
¿Cómo hacerlo?
Gracias!


Hola [Ignacio Martín]:

la arquitecta es la jefa del proyecto. Su misión es establecer el plan del programa en Microsoft Project. Es la project manager y su deber es crear, controlar, actualizar y comunicar el estado del proyecto. Los responsables de cada departamento y de sus trabajos-tareas deben de reportar a la jefa del proyecto las fechas de comienzo real y fin real, ó comienzo real+días trabajados en la tarea+días que restan. Todo ello a una fecha periódica de estado o actualización (semanal, quincenal (?)). Todos los responsables de comunicar el estado de los trabajos deben informar a la misma fecha de estado. El jefe de proyecto requiere, aprueba y actualiza la información y la introduce en Project. Comunica el estado del proyecto normalmente en una reunión de revisión conjunta, previa reprogramación de los trabajos retrasados a partir de la última fecha de estado. Se toman decisiones de ajuste en cuanto a retrasos, alcance, cambios, etc. y se saca el nuevo plan. Se suele hacer una copia de dicho plan previsto o línea de base al comienzo de cada período de seguimiento o actualización. La forma en que se comunica al jefe de proyecto puede ser en papel con las tareas previamente filtradas por cada departamento.

Los departamentos y personas implicadas pueden ver el archivo de Project en modo solo lectura pero no pueden editarlo, solo el jefe de proyecto. También se puede implantar Project Server, en cuyo caso se requiere una cierta infraestructura de software algo más sofisticada y costosa, con una base de datos SQL Server y asesoría en la implantación. De esa forma, los departamentos, la dirección y terceros consultan y actualizan mediante permisos vía simplemente navegador web.

20 marzo 2012

Control y seguimiento del coste del proyecto – Método del Valor acumulado (Earned value o Valor ganado)


Necesidad de herramientas de planificación y seguimiento del Coste
La planificación y seguimiento del coste del proyecto es una opción muy importante que nos brindan determinadas herramientas de software como Microsoft Project o Planer Et. El desconocimiento del software y su metodología de aplicación,  junto a la priorización del control del plazo sobre los aspectos económicos en situaciones de bonanza  despreciaban esta información. En la actualidad, y en situaciones de incertidumbre económica se hace más necesario disponer de herramientas de planificación y control en dicha área, que ayuden a la toma de decisiones en los proyectos por parte de los responsables e inversores.
1.       El punto de partida es el Plan de inversiones del proyecto
Estas herramientas de software de gestión de proyectos requieren para empezar que seamos capaces de obtener el plan de inversión  económica, plan previsto inicial o línea de base de los costos en el tiempo.  Esto se consigue mayoritariamente valorando a partida alzada los costos de cada tarea del proyecto y/o asignado recursos a los trabajos y definiendo una tasa del precio hora del recurso y/o de la unidad material empleada. Evidentemente todo ello ha de estar soportado sobre una programación con las tareas del proyecto adecuadamente estimadas en su duración, y relacionadas apropiadamente mediante vínculos de precedencia con el resto de las actividades interdependientes. No cabe medias tintas, si lo que podríamos llamar programación técnica o de los trabajos no está medianamente bien hecha, el sistema de control en cualquiera de sus aspectos no funcionará.
2.       Me comprometo a hacer seguimiento todos los viernes
Que exista una oficina de proyectos o al menos un responsable en la organización, comprometido con la gestión y seguimiento de los proyectos, que goce del conocimiento y de las atribuciones necesarias, junto con el apoyo firme de la dirección es un factor imprescindible sin el cual difícilmente se conseguirán los objetivos. Es necesario asegurar que periódicamente y ciñéndose a la fecha y hora acordada (Fecha de estado o revisión) se dispondrá de la información real de lo que ha ocurrido desde la última actualización: fechas de comienzo y fin reales, % completado o días reales trabajados, incluso horas de los recursos si se están controlando, cambios en la estimación de la duración restante si es el caso y por supuesto coste real de la tarea una vez terminada.
3.       Hay que reprogramar el trabajo retrasado
No se debe utilizar planes que incluyan tareas con trabajos programados anteriores a la Fecha de estado y que aún no se han hecho. Para dar realismo y utilidad al programa del proyecto se debe reprogramar todos los trabajos pendientes a partir de la Fecha de estado, lo que hace Microsoft Project y Planer Et automáticamente cuando se lo pedimos. Dado que se supone existe una programación adecuada con vínculos entre tareas cuando son necesarios, el software nos mostrará la nueva programación actualizada y reprogramada a la fecha de estado.
¿Se está cumpliendo el presupuesto?
Como se decía al principio, cada vez  es más frecuente escuchar la siguiente pregunta por parte de los responsables, e inversores de los proyectos  ¿cómo va el presupuesto?  ¿se va cumpliendo conforme a lo previsto?  Difícilmente se podrá contestar a dichas preguntas sin métodos o herramientas algo más ambiciosas que el mero y necesario procedimiento periódico de actualización comentado con anterioridad. Si bien es cierto que podemos responder con las cifras reales gastadas del presupuesto, esto no es suficiente para saber si se corresponde o no  con el plan inicial de inversiones ya que esa cifra de Costo real puede ser mayor o menor a lo que cabría esperar debido a un adelanto o retraso en el plazo de ejecución respectivamente, o incluso adecuándose al plazo esperado la cifra real puede variar debido a un mayor o menor encarecimiento o abaratamiento de costos.
El Método del Valor acumulado o Valor ganado (Earned value) facilita el control del presupuesto del proyecto

Sin pretender dar una explicación exhaustiva sobre el Método del valor acumulado, a continuación se comenta de manera resumida y se anexa una imagen de ejemplo de la información que esta técnica aporta, y de la cual podemos disponer en Microsoft Project , siempre y cuando se hayan realizado los pasos previos  1, 2 y 3  mencionados anteriormente. Sin duda, la implantación de esta técnica para el control y seguimiento del presupuesto del proyecto es una herramienta tan necesaria hoy día que cuesta imaginar proyectos rentables y bien gestionados sin su aplicación. Con ella podremos responder a la pregunta ¿cuánto he gastado de lo que debería hasta la fecha?  y de lo que he gastado hasta la fecha ¿cuánto debería haber costado según el presupuesto  y cuánto a costado realmente? Según la evolución del gasto hasta la fecha de estado ¿cuánto terminará costando el proyecto? Y finalmente y a la fecha de estado, ¿cuánto más dinero necesitaré o me sobrará para hacer lo que falta?

El Valor acumulado o Earned Value, se orienta a controlar el estado de rendimiento o cumplimiento del presupuesto(línea de base) a una fecha de estado o revisión, de manera que determinadas variables, campos o indicadores, que también se incluyen en Microsoft Project, informan de: I/ lo que se debería llevar gastado según la programación de la línea de base a la fecha de estado (CPTP), II/lo que se debería llevar gastado por el trabajo realizado(% completado o avance) a la fecha de estado de acuerdo con los valores de la línea de base para ese trabajo real (CPTR o Earned value EV o Valor ganado-completado-alcanzado-etc.) y por último III/ lo que exactamente ha costado el trabajo realizado (CRTR). A partir de estos 3 valores se calcula una serie de indicadores y campos de desviaciones y variaciones como se muestra en la imagen superior. Hay 5 campos de entrada y 8 fórmulas que se pueden simular en Excel para entenderlo mejor. Otros campos interesantes incluidos en la tabla son el CEF o Costo estimado a la finalización, que hace una previsión de cuánto podría llegar a costar el proyecto en función de los valores alcanzados a la fecha de estado, y también el campo IRPC o Índice de rendimiento para completar, que nos informa de en cuanto se supera o reduce el presupuesto inicialmente asignado para la parte restante por ejecutar, lo que nos orienta sobre el dinero sobrante o que debemos conseguir para terminar el proyecto. En este ejemplo diseñé una tabla con todos los campos más los 3 indicadores gráficos personalizados.
Ignacio Martín
MVP Microsoft Project
Marzo 2012