Dirección profesional de proyectos. Guía examen PMP. (Esquembre, J., 2009) Introducción y el Capítulo I. Marco y procesos “Aunque la reingeniería, hecha de forma convencional, haya sido correcta, las divisiones entre departamentos se oponen como islas en el mar a la velocidad de la corriente, que es el proceso”1. Históricamente, desde 1930 en adelante, las organizaciones se han gestiona- do de acuerdo a principios tayloristas de división y especialización del trabajo, organizándose por departamentos o funciones diferenciadas (llamadas gestión funcional o vertical). Eran otros tiempos, con lentos avances en la tecnología dis- ponible, bajos o nulos grados de automatización, mercados estables, producción seriada, etc. Esta forma de gestionar las organizaciones impregnó la gestión de proyectos. Hoy, y desde fines del siglo XX, las reglas de juego cambiaron, y el avance tecnológico fue una de las principales causas de todos los demás cambios pro- ducidos. Por tal motivo, si continuamos gerenciando organizaciones y equipos de proyectos de la manera anterior, con un marcado verticalismo, eso solo nos agregará lentitud, derroches, insatisfacciones de clientes y hasta fracasos en nuestros proyectos, creando profundas grietas entre las distintas áreas de la empresa. Debemos, rápidamente, pasar a organizaciones gestionadas en forma horizontal. En la última década, la gestión por procesos (gestión horizontal) ha despertado un interés creciente, siendo ampliamente utilizada por muchas organizaciones de primera línea, que aplican gestión de calidad y/o calidad total Este nuevo concepto para gestionar las organizaciones también se derramó so- bre la gestión de proyectos y fue adoptado y emulado por el Project Management Institute (PMI®), para generar la guía del PMBOK®2, donde se identifica los procesos que fueron reconocidos como buenas prácticas3 para los proyectos. Antes de continuar, nos vamos a detener a definir “proceso” como un conjunto de recursos y actividades interrelacionados entre sí, que transforman elementos de entrada (input) en elementos de salida (output), para alcanzar un conjunto pre- viamente especificado de productos, resultados o servicios, en un determinado tiempo. Los recursos pueden incluir personal, finanzas, instalaciones, equipos, técnicas y métodos. El equipo de proyecto es el encargado de la ejecución de los procesos de dirección de proyecto. El propósito es iniciar, planificar, ejecutar, supervisar y controlar y cerrar un proyecto de acuerdo con las condiciones pri- marias establecidas en el alcance. El éxito de una dirección de proyecto incluye la gestión activa y permanente de las interrelaciones que se generan entre los procesos de un proyecto, a fin de cumplir exitosamente con los requisitos del patrocinador, el cliente y los demás stakeholders. En los capítulos de este libro nos encontraremos con la descripción de todos los procesos (grupos de procesos) que constituyen un proyecto, y que necesa- riamente se deben aplicar para lograr no solo la eficacia del proyecto (cumplir con lo establecido), sino también alcanzar su realización con eficiencia (con los recursos preestablecidos). Los grupos de procesos de dirección de proyecto están relacionados por los re- sultados que produce cada proceso. Generalmente, la salida de un proceso se convierte en entrada a otro proceso, o es un entregable del proyecto. La madurez que presenta la organización ejecutora del proyecto con respecto a su sistema de gestión de proyectos (su cultura, su estilo, su estructura organi- zativa, etc.) definirá cómo esos procesos son aplicados e implementados, y por ende tendrá una definitiva influencia en el éxito o fracaso del proyecto. Si su estructura organizativa presenta características de una organización funcio- nal (vertical, tayloriana), los proyectos se resolverán en forma no interrelaciona- da y dentro de cada área funcional que corresponda. Aquí aparecerán las fallas y derroches en el intercambio de información y materiales entre los diferentes departamentos (especificaciones no definidas, actividades no estandarizadas, actividades duplicadas, indefinición de responsabilidades, etc.), aparecerá el 2 Project Management Body of Knowledge. PMBOK® es una marca registrada del Project Management Institute. 3 Buenas prácticas significa que existe un consenso general acerca de que la aplicación de esos procesos aumenta las posibilidades de éxito del proyecto. establecimiento de objetivos departamentales en ocasiones incoherentes y con- tradictorios con lo que deberían ser los objetivos globales del proyecto, como así también proliferarán las actividades departamentales que no aportan valor al cliente ni al proyecto, generando una injustificada burocratización de la gestión. El no gestionar los proyectos a través de la interrelación de sus procesos origina la creación continua de grietas en el interior del equipo de proyectos, que van so- cavando su posibilidad de éxito. Esto llevará a tener clientes insatisfechos, tanto internos como externos al proyecto. En cambio, si su estructura organizativa está orientada a proyectos (enfoque que aplica la PMBOK® Guide), estos se gestionarán de una manera transversal, siendo esta forma de gestionar más eficiente, ágil y con una orientación hacia la satisfacción total del cliente, dado que las interrelaciones entre los procesos buscan la eficiencia total del proyecto. Hoy las organizaciones ya no buscan gerentes o jefes funcionales, sino más bien buscan directores/gerentes/jefes/PMP®4 que se responsabilicen de un determi- nado proyecto durante su ciclo de vida y que se encarguen de liderar al equipo de proyecto para cumplir los objetivos de este. Es decir, se trata de conformar equipos que analicen todo el proyecto en forma transversal en lugar de hacerlo en forma vertical. Es ahí en donde se crea valor y se construye un círculo virtuo- so en la organización. La diferencia conceptual entre la focalización de las actividades en la función/ departamento y la dirigida al proceso es que la primera presenta fuerte orien- tación al producto, lo que origina una mentalidad que favorece la existencia de interfaces funcionales, mientras que la focalización de las actividades de la di- rección de proyectos basada en procesos siempre tiene como objetivo cumplir con mayor grado de eficiencia los requerimientos de los clientes, y es hacia ese objetivo al que orienta su gestión. Por lo dicho anteriormente, el lector encontrará en los capítulos del presente libro el desarrollo de cada área del conocimiento de la dirección de proyectos, las dis- tintas actividades y las funciones que son necesarias para lograr la consecución del objetivo de un proyecto a través de la interrelación de procesos. Creemos firmemente que la internalización de esta filosofía de gestión, orientada a los procesos, será una herramienta fundamental en su proyecto de búsqueda de la certificación profesional en proyectos y en su vida profesional. 4 Project Management Professional. PMP® es una marca registrada del PMI®. Marco y procesos Conceptos clave Luego de leer y estudiar este capítulo, usted dominará los siguientes conceptos: ■ ¿Cuándo estoy trabajando un proyecto? ■ La profesión de la Dirección de Proyectos. ■ La restricción triple. ■ El gerente de proyectos. ■ Interesados en el proyecto. Técnicas para gestionar interesados. ■ Efectos culturales, sociales, políticos e internacionales. ■ Contexto organizacional. ■ El ciclo de vida del proyecto. ■ Ciclo de vida del producto vs. ciclo de vida del proyecto. ■ Procesos de dirección de proyectos. Resumen ejecutivo Este capítulo provee una visión global de la profesión de la Dirección de Proyectos, explorando el contexto en el cual se desarrollan normalmente los proyectos y las capacidades de gestión que un gerente de proyectos debe tener. Asimismo, se analizan las influencias de los stakeholders1 del proyecto, así como otras áreas que pueden influenciar en el éxito de este. 1 Stakeholders (interesados): término inglés que hace referencia a todos los interesados en el proyecto, sean afectados o no por su resultado Examinaremos los cinco grupos de procesos y las nueve áreas del cono- cimiento de la dirección de proyectos, cuya memorización lo guiará en la dirección de cualquier proyecto y, particularmente, lo asistirá en aprobar el examen de PMP®2. Adicionalmente, se discutirá el ciclo de vida de un proyecto y de un producto. Para finalizar, siguiendo el lineamiento de A Guide to the Project Management Body of Knowledge3 (en adelante, PMBOK® Guide4), se suministrará una perspectiva integral de los procesos de la dirección de proyectos y las interacciones entre los distintos procesos y áreas del conocimiento. Se discutirá espe- cíficamente la habilidad de implementar los procesos propuestos por el PMI® (Project Management Institute) en diversos proyectos y cómo esto aporta en la superación de los obstáculos del proyecto “Aprobar el examen PMP®”. En este contexto, es importante destacar una frase de William A. Cohen, citada por Scott Berkun en The Art of Project Management (2005): “Nor- malmente los proyectos son simplemente una larga serie de adversidades que deben ser sorteadas. Afrontar adversidades no es inusual, es normal, y nuestro objetivo es sortearlas. La prueba real no es cuando somos exitosos y no hay adversidades, sino cuando las hay y triunfamos”. Objetivos del capítulo Luego de haber procesado este capítulo usted habrá logrado los siguientes objetivos: ■ Comprender conceptos básicos de la dirección de proyectos. ■ Reconocerlaimportanciadelarestriccióntripleextendidaenladirección de proyectos. ■ Aprender a identificar a los interesados del proyecto y cómo gestionarlos. ■ Entenderlosefectosculturales,sociales,políticoseinternacionalessobre los proyectos. ■ Distinguir entre el ciclo de vida del producto y el ciclo de vida del proyecto. ■ Examinar todas las áreas de conocimiento y los procesos de la dirección de proyectos. 2-Project Management Professional (PMP®) es una marca registrada del Project Management Institute. 3-A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (4a Ed.), PMI®, 2008. 4-PMBOK® es una marca registrada del Project Management Institute. 1.1 INTRODUCCIÓN El presente capítulo provee una introducción a conceptos clave en la profe- sión de la Dirección de Proyectos para el examen internacional de PMP®, así como también enfatiza la importancia del rol del gerente de proyecto (Project Manager, PM) y las capacidades, habilidades y conocimientos que este debe tener para alcanzar los objetivos del proyecto. Adicionalmente, se especifican los factores fundamentales que pueden poner en riesgo el éxito del proyecto y la importancia que tiene para el gerente de este conocerlos de antemano. La gestión de los interesados, conocer el contexto organizacional e internacional y reconocer aspectos culturales, legales y personales tanto del equipo de proyecto como de la región de operación de la organización ejecutante, es vital para el éxito de los proyectos. Finalmente, se hará referencia al ciclo de vida del producto y del proyecto. Es primordial para un gerente de proyecto que quiera convertirse en Project Management Professional (PMP®) lograr los objetivos planteados al inicio de este capítulo. 1.2 MARCO CONCEPTUAL DE LA DIRECCIÓN DE PROYECTOS 1.2.1 ¿Cuándo estoy trabajando en un proyecto y cuándo no? Las organizaciones emprenden trabajos con el fin de lograr un conjunto de objetivos. Estos pueden ser desde comenzar a competir en un segmento nuevo del mercado –por ejemplo: desarrollo de un equipo generador de energía eólica de 2MW– hasta preparar el presupuesto del año para todas las áreas de la empresa, resolver problemas en sistemas de información y realizar comunicaciones en forma periódica. ¿Puede usted decir cuál de estos es un proyecto? Los trabajos se clasifican en proyectos y operaciones, aunque en algunos casos estos se superponen. Proyecto se define como un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único (PMBOK® Guide). Ahora bien, ¿cuáles son las características clave que definen un proyecto? • Temporal: cada proyecto está limitado en el tiempo, es decir, tiene un comienzo y un final definido. El proyecto finaliza cuando se han logrado los objetivos, la necesidad que originó el proyecto ha desaparecido o el final del proyecto se ha alcanzado. El proyecto puede durar desde un mes hasta varios años. Los proyectos no son esfuerzos continuos y repetitivos. ¡Recuerde esto en el examen! • Producto, servicio o resultado único: el equipo de proyecto produce entregables únicos, los cuales pueden ser productos, servicios o resulta- dos tangibles. Por ejemplo: se entregan decenas de centrales de energía, de urbanizaciones, de edificios, pero cada uno de ellos es único porque posee características diferenciales, desde el cliente, sus necesidades, re- querimientos y expectativas, hasta la tecnología y recursos necesarios para satisfacerlos. – Producto: es un elemento tangible, un objeto. – Servicio: es la capacidad desarrollada (por el proyecto) de servir o brindar un beneficio intangible. – Resultado: son las conclusiones de investigaciones y/o análisis. • Elaboración gradual: significa que el entendimiento de todo el trabajo incluido en el proyecto se incrementará a medida que este se desarrolle. El alcance, los requerimientos, tiempo y costos de un proyecto se definen en forma global en su inicio, y luego, con el desarrollo de la planificación, se determinan más claramente los objetivos y los entregables. Tanto los proyectos como las operaciones tienen en común las siguientes características: ––– Son realizados por personas. Existen limitaciones de recursos. Deben ser planificados, ejecutados y controlados. Los proyectos y las operaciones (Figura 1.1) se diferencian principalmente en que las segundas son continuas y repetitivas, mientras que los proyec- tos son temporales y únicos. Las operaciones proveen soporte al negocio asumiendo una serie de objetivos, cumpliéndolos y luego tomando un nuevo conjunto de objetivos, y el trabajo continúa en forma repetitiva (por ejemplo, realizar el control diario de la caja del negocio). En cambio, los proyectos se utilizan para alcanzar objetivos estratégicos corporativos, en respuesta a demandas del mercado, necesidades de la empresa, avances tecnológicos y/o solicitudes de clientes. Algunas empresas definen pautas para identificar a los proyectos. Se definen criterios en términos de costo y tiempo. Por ejemplo: todo paquete de traba- jo que dure menos de tres meses y cueste menos de 50.000 dólares no es un proyecto. Ejemplos de proyectos: Para diferenciar un proyecto de una operación y compren- der el contenido de este libro, piense en paquetes de trabajo tan grandes que sean indiscutiblemente proyectos. Esto lo ayudará a responder preguntas del examen. 1.2.2 La profesión de dirección de proyectos La dirección de proyectos es el liderazgo de un equipo de personas hacia la concreción de objetivos y requisitos del proyecto utilizando cono- cimientos, habilidades, herramientas y técnicas (Figura 1.2). Según el PMI®, la dirección de proyectos consiste en la aplicación de co- nocimientos, habilidades, herramientas y técnicas provenientes de áreas de conocimiento y grupos de procesos específicos que deben ser aplicados con responsabilidad profesional y social. 5 Por paquete de trabajo se entiende el último piso de la estructura de desglose del trabajo. Este concepto será desarrollado en el capítulo 3, sobre la gestión de alcance. Responsabilidad profesional y social significa que las acciones de los gerentes de proyectos deben estar siempre en línea con requerimientos legales y estándares éticos. El PMI® entiende que debido a que la ejecu- ción de un proyecto afecta tanto al equipo de trabajo como a la sociedad donde este es ejecutado, su gerente debe aplicar las mejores prácticas disponibles de la profesión para asegurar y proteger los derechos de los stakeholders y del segmento de la sociedad donde se desarrolla. Esto es hacer lo correcto, seguir el proceso adecuado, actuar éticamente, en forma justa y profesional, cuidar los conflictos de intereses, reportar in- fracciones, incrementar el conocimiento y buenas prácticas y lidiar con problemas. Este tema se tratará en profundidad en el capítulo 11 de ética y responsabilidad profesional, sin embargo, es importante tener esto en mente durante la lectura de todo el libro. • Los grupos de procesos siguen el ciclo de vida de un proyecto6; ellos son: grupo de procesos de iniciación, planificación, ejecución, seguimien- to y control y cierre de proyecto. • Las áreas de conocimiento son integración de proyectos, alcance, tiem- pos, costos, riesgos, comunicaciones, adquisiciones, calidad y recursos humanos. Aunque estas áreas serán tratadas en detalle en los capítulos siguientes del libro, se describen brevemente a continuación: – Gestión de la integración del proyecto. Comprende los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los distintos procesos y actividades de todos los grupos de procesos de la dirección de proyectos. – Gestión del alcance del proyecto. Reúne los procesos necesarios para asegurar que el proyecto incluya única y totalmente el trabajo re- querido, que será planificado y controlado para completar el proyecto satisfactoriamente. – Gestión del tiempo del proyecto. Se refiere a los procesos necesa- rios para planificar, ejecutar y supervisar el proyecto y así lograr termi- narlo a tiempo. – Gestión de los costos del proyecto. Abarca los procesos requeridos en la estimación y preparación del presupuesto y control de costos para que el proyecto pueda ser completado dentro de los parámetros apro- bados. – Gestión de los riesgos del proyecto. Consiste en los procesos rela- cionados con la planificación de la gestión de riesgos, su identificación y análisis, las respuestas a estos y el seguimiento cercano, aumentando de este modo las probabilidades de que el proyecto termine con éxito. 6 Define las fases que conectan el inicio de un proyecto con su fin. – Gestión de las comunicaciones del proyecto. Incluye los procesos de planificación, ejecución, seguimiento y control para asegurar la co- rrecta generación, colección y distribución a tiempo de la información del proyecto. – Gestión de la calidad del proyecto. Involucra todos los procesos de la organización ejecutante del proyecto que definen las políticas, los ob- jetivos y las responsabilidades relativos a la calidad, a fin de satisfacer los requerimientos por los cuales se inició el proyecto. – Gestión de los recursos humanos del proyecto. Considera los pro- cesos necesarios para organizar y dirigir personas definiendo sus res- pectivos roles y responsabilidades dentro de cada equipo de proyecto para finalizarlo con éxito. – Gestión de las adquisiciones del proyecto. Incluye los procesos necesarios para adquirir productos, servicios o resultados necesarios fuera del equipo de proyecto y la administración de los contratos co- rrespondientes. Además incluye los procesos de gestión del contrato y control de cambios correspondientes. Para responder adecuada- mente las preguntas del examen, es conveniente que usted se ponga en el lugar de la organización ejecutante del proyecto y por lo tanto adquirente de productos, servicios o resultados. Como dijimos anteriormente, la dirección de proyectos incluye el liderazgo de personas hacia el alcance de los objetivos del proyecto, por lo tanto, siendo que estos son únicos y limitados en el tiempo, el gerente de proyec- to (PM)7 debe estar activamente comprometido e involucrado en su gestión y ejecución. El proyecto no toma velocidad y dirección en forma automática, por lo que el PM debe poseer y aplicar habilidades, conocimientos, herra- mientas y técnicas en las áreas de conocimiento y grupos de procesos en forma responsable de acuerdo al Código de Ética y Conducta Profesional del PMI®. Al responder las preguntas del examen, recuerde que el gerente de proyecto debe ser proactivo todo el tiempo, adelantándose a los problemas, buscando cambios, previniendo inconvenientes, reconociendo riesgos, mitigándolos, identificando el impacto en el proyecto de decisiones y/o situaciones antes de actuar. ¡Esto también es actuar en forma responsable! Recuerde: ¡no actuar de acuerdo a lo especificado en la PMBOK® Guide es actuar de forma irresponsable, transgrediendo el Código de Ética y Conducta Profesional! 7 Project Manager, por sus siglas en inglés. 1.2.4 El gerente de proyectos. Responsabilidades y características El gerente de proyectos (PM) es la persona nombrada por la organización ejecutante para liderar al equipo y conducirlo hacia el logro de los objetivos del proyecto. Este puesto de trabajo es también conocido como administra- dor del proyecto, gerente de proyectos o gerente del proyecto. La dirección de un proyecto comprende la planificación, organización, se- lección de personal, ejecución y control de las operaciones de una empresa en funcionamiento. Por consiguiente, el PM a menudo necesita discutir y decidir en temas donde es necesario tener conocimiento de las siguientes disciplinas: • Finanzas. • Compras y adquisiciones. • Ventas y comercialización. • Contratos y derecho. • Fabricación. • Logística y cadena de suministro. • Planificación estratégica y operativa. • Estructuras y comportamiento organizacional, administración de perso- nal, compensaciones, beneficios y planes de carrera. • Prácticas sanitarias y de seguridad. • Tecnología de la información. Además, es necesario que gestione relaciones interpersonales tales como: • Comunicación efectiva. • Influencia en la organización. Capacidad para “lograr que las cosas se hagan”. • Liderazgo: – Desarrollar una visión y una estrategia, y motivar a las personas a lograrlas. – Motivar a las personas para que alcancen altos niveles de rendimiento y superen las adversidades del proyecto. • Negociación y gestión de conflictos: consulta con miembros del equipo de proyecto, stakeholders (interesados), sponsors10 y cliente para alcanzar una visión compartida del camino a seguir por el equipo de proyecto. 10 Sponsor: término en lengua inglesa que hace referencia a la persona o grupo de personas que autorizan la ejecución del proyecto suministrando los recursos financieros necesarios. • Resolución de problemas: identificación y análisis de alternativas y toma de decisiones. Para lograr lo antes dicho el PM debe ser una persona que: • Conoce y entiende la visión del negocio del proyecto, así como también la visión técnica, traduciendo esto al equipo de proyecto. Esta visión más amplia hace posible agregar valor al equipo de proyecto, a las personas correctas en el momento adecuado. • Crea un impacto positivo en la calidad del trabajo producido y en el espí- ritu del equipo de proyecto. • Promueve los intereses de la compañía compatibilizándolos con los del cliente durante todo el desarrollo del proyecto. • Se comporta de acuerdo al Código de Ética y Conducta Profesional del PMI®. • Es flexible y abierto frente a los cambios. • Es un excelente comunicador. • Tiene habilidad para trabajar en un ambiente multicultural. • Disfruta del desafío de realizar y mantener compromisos. • Desea trabajar en un contexto más amplio que el técnico y el comercial. • Es capaz de establecer, motivar y liderar equipos efectivos para alcanzar logros. • Tiene confianza en su capacidad de liderazgo sobre el equipo de pro- yecto. • Disfruta del respeto y la mayor visibilidad ganados por el alcance de los objetivos. • Tiene pensamiento estratégico y es capaz de entregar información basa- da en evaluaciones consensuadas dentro del equipo de proyecto. Es sencillo deducir de esto que encontrar un buen gerente de proyecto (PM) puede convertirse en un gran desafío. Los gerentes de proyectos deben mantener todo el tiempo un balance de actitudes, debido a que lideran un grupo de personas y llevan la responsabilidad de cumplir no solo con los ob- jetivos del proyecto sino también con las expectativas explícitas e implícitas del equipo de proyecto, sponsor, cliente y stakeholders en general. Para llevar a cabo esta titánica tarea, es necesario que los gerentes de pro- yecto tengan suficiente juicio, sabiduría y experiencia. Para conservar la salud del equipo de proyecto y crear un efecto positivo sobre el ambiente social en el cual se desarrolla, los gerentes deben, además, guardar el equilibrio de los siguientes aspectos personales: ego, uso de la autoridad, perfeccionismo, paciencia, estilo analítico en la toma de decisiones, coraje en la forma de trabajo, credibilidad de acción (cree en lo que hace) y desafío frente a para- digmas preestablecidos. Resumiendo lo anteriormente dicho, se espera de un PM un buen balance de habilidades interpersonales, buenos conocimientos y habilidades de di- rección general, suficiente experiencia y comprensión del entorno del pro- yecto, suficientes conocimientos en normas y regulaciones de su área de alcance y principalmente conocimientos en fundamentos de la dirección de proyectos, como se indica en la Figura 1.5, contenidos en la PMBOK® Guide. FUENTE: PMBOK® Guide (PMI®, 2004, p. 13) FIGURA 1.5 proyecto) Habilidades y conocimientos de un buen PM (gerente de 1.3 STAKEHOLDERS DEL PROYECTO Stakeholders11 son aquellas personas o grupos de personas que pueden afectar al proyecto o verse afectadas por él. Pueden ser sociedades, gobier- no, organizaciones, clientes y comunidades que tienen intereses particulares en el proyecto. Como gerente de proyecto, se debe estar alerta e identificar a todos los stakeholders que podrían influir en el proyecto positiva o nega- tivamente. Es obligación del PM evitar efectos negativos sobre el proyecto y potenciar los positivos. 11 En varias publicaciones en español encontrará el término stakeholders traducido como interesados o grupos de interés 1.2.3 La restricción triple El objeto principal de la profesión de la dirección de proyectos es balancear los requisitos concurrentes del proyecto como tiempo, costo, alcance y cali- dad. La competencia natural entre estos requisitos se denomina restricción triple8 y es representada comúnmente con un triángulo equilátero, como muestra la Figura 1.3. FIGURA 1.3 La restricción triple tradicional La calidad del proyecto se ve siempre afectada por el equilibrio de estos tres factores. Son considerados proyectos exitosos o de alta calidad aquellos que entregan el producto, servicio o resultado requerido con el alcance solicitado, a tiempo y dentro del presupuesto planificado. La relación entre estos tres factores es tal que si cambia alguno de ellos los otros dos serán afectados. Conceptualmente, no se puede armar geométricamente un triángulo equilá- tero con cualquier arreglo de longitudes de segmentos. Por lo tanto, cualquier combinación de alcance, tiempos y presupuestos de proyectos no proveerá en todos los casos la calidad deseada. Debido a que un proyecto provee un resultado, producto o servicio único o, en otras palabras, nunca antes realizado, es de esperar que exista cierto gra- do de incertidumbre en las variables tomadas como base para definir el plan y presupuesto del proyecto, así como también variables inesperadas que podrían afectar al proyecto durante su ejecución. Por lo tanto, el PM debe gestionar previendo alguna respuesta a esta incertidumbre denominada ries- go. Se definen como riesgos de un proyecto a los eventos o condiciones inciertos que, de ocurrir, tendrán un efecto positivo o negativo al menos en uno de los objetivos del proyecto. 8 Una restricción es cualquier cosa que limita las opciones del equipo de proyecto, tales como imposición de fechas (hitos), normas de calidad a cumplir, disponibilidad de fondos y de recursos, entre otros ejemplos. Por lo anteriormente dicho, se vuelve imprescindible gestionar los riesgos, ya que pueden comprometer al alcance, tiempo, costos y calidad del producto, servicio o resultado. Al mismo tiempo, es esencial tener presente la satisfacción del cliente del proyecto. Satisfacer al cliente puede llegar, especialmente en proyectos in- formáticos, a afectar el alcance en la restricción triple y producir la deno- minada “corrupción del alcance”9, impactando nuevamente en los tiempos, costos y calidad, y redundando tarde o temprano en más efectos negativos que afectan tanto a la organización ejecutante como al cliente. Para evitar estos inconvenientes, será necesario llevar un adecuado pro- ceso formal de control integrado de cambios (ver capítulo 2, Gestión de la integración). Esto evitará fallas de comunicación entre cliente y organización ejecutante del proyecto, y garantiza que el equipo de proyecto estará traba- jando en cambios de alcance, calidad, tiempo y costos (y riesgos asociados) aprobados por ambas partes, asegurando la satisfacción, al menos en prin- cipio, del cliente. Por todo esto, la restricción triple representada por el triángulo equilátero se transforma en un hexágono regular (de lados iguales), según se muestra en la Figura 1.4. Recuerde que en el examen, cuando se mencione a la restricción triple, se estará hablando del delicado balance o competencia que existe entre alcan- ce, tiempo, costo, calidad, satisfacción del cliente y riesgos. FIGURA 1.4 La restricción triple extendida 9 La corrupción de alcance es denominada en inglés Scope Creep. Es el agregado de funcionalidades (alcance del proyecto) sin evaluar efectos en tiempo, costo y recursos o sin aprobación del cliente. C 1.5 CONTEXTO ORGANIZACIONAL 1.5.1 Influencia de estructuras organizacionales en el proyecto Es muy importante para un gerente de proyecto reconocer la estructura de la organización ejecutante respecto a la dirección de proyectos. El tipo de estructura organizativa definirá el nivel de autoridad del gerente de proyecto, determinará cuál es su posición dentro de la empresa y el poder que posee de “hacer que las cosas sucedan”. Saber esto lo mantendrá alerta respecto del apoyo que podría obtener de la organización ejecutante, y le brindará claridad respecto de las decisiones que podrá tomar dentro del proyecto, así como en relación con las que no podrá tomar. Las organizaciones pueden estar estructuradas según alguna combinación de los siguientes modelos: • Proyectizada • Matriz balanceada • Matriz débil • Matriz fuerte • Funcional • Compuesta Las figuras siguientes muestran los tres modelos de organización más iden- tificables: estructura proyectizada (Figura 1.6), funcional (Figura 1.7) y matri- cial balanceada (Figura 1.8). Las compañías pueden tomar combinaciones de ellas y así lograr la matricial débil, fuerte o compuesta. La Tabla 1.1 resume las ventajas y desventajas de cada uno de los modelos más identificables. En principio no existe ninguna organización que pueda representarse to- talmente con alguna de estas estructuras organizativas. En general, las compañías toman alguna estructura funcional o matricial hasta cierto nivel jerárquico y luego pueden tomar una forma proyectizada. En algunos casos puede ocurrir que una compañía con estructura totalmente funcional decida encarar un proyecto de alta prioridad, por lo que saca a un grupo de las líneas funcionales hasta que el trabajo sea completado. En este caso, los miembros del equipo de proyecto reportan directamente al PM. Este tipo de organizaciones se denominan estructuras compuestas o híbridas. El PM debe entender las influencias no escritas ni mencionadas y los canales de comunicación formales para poder iniciar y completar el proyecto con éxi- to. El gerente de proyecto debe comprender además no solo las posiciones jerárquicas formales, sino también las informales que forman el entrelazado de influencias de la organización. Esto es, debe entenderse toda la trama de referentes y líderes que son capaces de influir en la organización, para po- der finalizar con éxito el proyecto. En otras palabras, se trata de captar “la política” en las organizaciones, sin interpretar esto como algo negativo, para usarla en forma positiva y constructiva, dirigiendo a las personas hacia el alcance de los objetivos del proyecto y de la empresa. Las empresas que adoptan una estructura compuesta o híbrida son: • Compañías principalmente orientadas a la producción, pero con muchos proyectos. • Empresas con énfasis en desarrollo de nuevos productos. • Organizaciones con ciclo de vida del producto corto. • Aquellas donde existe necesidad de proceso de desarrollo rápido. La Tabla 1.2 compara en forma sucinta las características del proyecto espe- radas según la estructura adoptada por la organización ejecutante. 1.6 CICLO DE VIDA DEL PROYECTO 1.6.1 Dirección de proyectos a través de fases 1.6.1 Dirección de proyectos a través de fases Como mencionamos, “un proyecto es un esfuerzo temporal originado para crear un producto, resultado o servicio único”. Debido a que es único, no se ha realizado con anterioridad, y, por lo tanto, los proyectos de partida conlle- van gran incertidumbre. Mientras más grande sea el proyecto, mayor será la incertidumbre asociada. Por esta razón, entre otras, los proyectos son des- glosados en partes o fases manejables. El conjunto de fases utilizadas para ejecutar los proyectos se denomina ciclo de vida del proyecto19. Dividir el proyecto en fases le permite tanto al PM como a su equipo analizar el proyecto completo en el largo plazo, pero a su vez concentrarse en el corto plazo de forma de terminar una fase por vez. De esta manera, el esfuerzo del equipo de trabajo se concentra en forma efectiva y con mayor nivel de certeza sobre los supuestos y la planificación realizada. 18 El desarrollo de este estándar involucró a cerca de 800 gerentes de proyectos voluntarios de diferentes industrias y disciplinas durante seis años a lo largo de 35 países, revisando 27 modelos de madurez existentes y en línea con los estándares del PMI®. 19 Es lo que se necesita hacer para realizar el trabajo, y dependerá del tipo de industria y del tipo de proyecto. Entonces, los gerentes de proyecto o la organización ejecutante dividen los proyectos en fases para proveer mejor gestión y control de los paquetes de trabajo involucrados en el proyecto. Algunas organizaciones, en especial en la industria aeronáutica o empre- sas desarrolladoras de equipos complejos como turbinas de gas, equipos electromecánicos para centrales hidroeléctricas o generadores eólicos, uti- lizan ciclos de vida estándar de proyectos. Estos pueden variar según se ejecuten proyectos de desarrollo o de servicio. La Figura 1.11 muestra un ejemplo de ciclo de vida de proyecto típico de un proyecto de desarrollo de ingeniería. FIGURA 1.11 Ciclo de vida de un proyecto de desarrollo de ingeniería Cada fase del ciclo de vida del proyecto es tratada como si fuera un proyecto en sí mismo. Una vez terminada la fase es posible comenzar con la siguiente como si fuera otro proyecto. Esto facilita enormemente, sobre todo en gran- des proyectos, las tareas de control, como así también mejora la precisión de la planificación y disminuye los riesgos asociados al proyecto. Esto se debe a que se puede realizar, por ejemplo, una planificación de alto nivel para todo el proyecto y de detalle solo para la fase que está pronta a ser ejecutada. La transición entre una fase y la otra está dada por un punto de revisión del proyecto o fin de fase20, el cual está definido por una cierta cantidad de entregables del proyecto. Estos son revisados por personal idóneo, por lo general externo al proyecto y perteneciente a la organización ejecutante. Se revisa que los entregables estén completos, sean precisos y estén aproba- dos antes de que el trabajo de la siguiente fase pueda seguir rumbo. 20 Estos puntos que indican el fin de una fase son también conocidos en inglés como tollgates o gate reviews. Por lo general, y dependiendo del tipo de proyecto, sobre todo ponderando el riesgo, es posible comenzar la siguiente fase sin haber obtenido aprobación por la primera. Sin ser esto lo más deseable, es una situación que puede pro- ducirse cuando se están utilizando técnicas de compresión de cronogramas. En general, al llegar a un punto de revisión del proyecto o fin de fase, este recibe acciones correctivas y/u observaciones que deben ser atendidas de- pendiendo de su gravedad, para permitirle al equipo de proyecto comenzar con la fase siguiente. En un punto de chequeo puede decidirse no continuar con el proyecto por diferentes motivos, entre ellos: • El riesgo del proyecto es demasiado elevado. • La estrategia comercial de la organización ejecutante cambió y es nece- sario asignar recursos a otros proyectos de mayor prioridad. • Los parámetros de evaluación del proyecto han cambiado y este no dará los beneficios esperados. Algunas empresas desarrollan políticas de estandarización de todos sus pro- yectos, mientras otras otorgan libertad al equipo de proyecto para definir el ciclo de vida de estos. En general un ciclo de vida de un proyecto define: • Qué trabajo debe ser realizado en cada fase. • Los entregables a ser generados en cada fase. • La revisión de ellos por personal idóneo. • fase. Los equipos de personas que estarán involucradas en cada fase. • Cómo debe controlarse y aprobarse cada Los ciclos de vida de proyecto comparten las siguientes características: • Las fases son secuenciales y están definidas en función de la elaboración técnica gradual del proyecto (por ejemplo, especificación, diseño concep- tual, diseño detalle, etcétera). • El uso de recursos y costos (Figuras 1.12 y 1.13) es bajo al inicio del pro- yecto y crece a medida que la ejecución va progresando. • El valor de riesgo total del proyecto es alto al inicio del proyecto y dismi- nuye a medida que se va ejecutando. El riesgo es reducido a través de la implementación de medidas de mitigación validadas como tales. • Introducir cambios en el proyecto es más factible en su inicio que al final. Esto se debe al grado de realización de los entregables y al costo más alto para realizar cualquier modificación. Al final del proyecto, disminuyen las chances de que un stakeholder pueda influenciar en él. Por lo tanto, la influencia de los stakeholders para modificar el proyecto es más elevada al comienzo. Una ventaja fundamental en la estandarización de los ciclos de vida de los proyectos es que trae aparejada la estandarización de los entregables por fase. Esto permite el entrenamiento rápido de gerentes de proyectos sin experiencia, aumento más rápido de la cantidad de personal que lidere equipos y reducción de riesgos en los proyectos. Esto ocurre por el simple hecho de que con el proceso se definen listas de control, listas de entrega- bles por fase, componentes intervinientes en cada fase, etcétera. En otras palabras, el ciclo de vida de un proyecto se convierte en una “guía” para el PM, facilitando no solo su tarea sino también la del equipo, ya que al ser un proceso estándar de la organización ejecutante, todos saben o co- nocen de antemano los entregables por fase mínimos para poder avanzar a la fase siguiente. Con esta forma de trabajo se transfiere, en cierta forma, la experiencia de los recursos a la organización ejecutante. Los siguientes ítems son examinados normalmente en los puntos de revisión del proyecto o fin de fase: •Rendimiento del proyecto a la fecha. •Rendimiento del equipo de proyecto a la fecha. •Verificación de cumplimiento de entregables y su contenido alineados con el alcance del proyecto. 1.6.2 Ciclo de vida del proyecto versus ciclo de vida del producto El ciclo de vida del producto abarca desde su concepción hasta su retira- da de circulación del mercado. Durante este tiempo, y dependiendo de las condiciones del mercado y el estado de la competencia, se generan necesi- dades que originan proyectos de desarrollo o de mejora sobre el producto ya existente. Estos proyectos tienen, cada uno, su ciclo de vida en particular y todos ellos constituyen el ciclo de vida del producto, desde su inserción hasta su eliminación comercial. Considere como ejemplo una compañía desarrolladora y fabricante de la- varropas automáticos. Supongamos que a partir del estudio de mercado realizado, la empresa determina que un modelo de lavarropas automático deberá gastar menos energía o de lo contrario perderá participación en el mercado, ante otras marcas que ofrecen esta nueva tecnología. Para ello, se debe lanzar un proyecto de desarrollo dentro del ciclo de vida del producto “lavarropas” apuntando a la reducción del gasto de energía. Una vez terminado este, el producto puede ser liberado en el mercado con la nueva característica. Ahora supongamos que tiempo después la empre- sa visualiza una oportunidad estratégica de ofrecer menor nivel de ruido. Para poder lanzar un producto con este beneficio, se deberá lanzar otro proyecto de desarrollo que incluya estas nuevas mejoras. Esta situación puede representarse como indica la Figura 1.14. De esta manera el producto se mantiene en un circuito continuo de mejora de competitividad. En todos los casos debe existir una evaluación económica positiva que autorice el inicio de los proyectos para continuar con el ciclo de vida del producto, de lo contrario este llegará a su fin. 1.7 PROCESOS DE DIRECCIÓN DE PROYECTOS Para el examen usted debe comprender que la PMBOK® Guide es un es- tándar norteamericano21 de uso internacional, la norma ANSI/PMI 99-001- 200822, que consiste en un compendio de buenas prácticas industriales de la profesión de dirección de proyectos. Buena práctica significa que existe un 21 Si bien en Latinoamérica el estándar más difundido es el norteamericano, en algunos países, principalmente europeos, se utiliza el estándar británico Prince2 (PRojects IN Controlled Enviroments). Ver www.prince2.com. 22 American National Standards Institute (www.ansi.org). consenso general comprobado acerca de que la aplicación de estos proce- sos de dirección de proyectos aumenta las posibilidades de completar con éxito una gran gama de proyectos. Sin embargo, más allá de que la PMBOK® Guide sea una norma internacio- nal, el equipo de proyecto no está obligado a implementar todos los procesos especificados. Por el contrario, es obligación del equipo de proyecto seleccio- nar los procesos más apropiados para equilibrar las demandas concurrentes en la restricción triple (alcance, tiempo, costo, calidad, riesgo y satisfacción del cliente). No solo es responsabilidad del equipo de proyecto la selección apro- piada de los procesos a aplicar, sino también es necesario determinar el grado de severidad/inflexibilidad a utilizar para cada proyecto. 1.7.1 Ciclo de vida de la dirección de proyectos El ciclo de vida de la dirección de proyectos está compuesto por cinco grupos de procesos que son utilizados para cualquier proyecto independiente de la industria. Las fases o grupos de procesos del ciclo de vida de un proyecto son los siguientes: 1. Iniciación: consiste en el grupo de procesos que provee la autorización formal para iniciar un proyecto o fase de este. Cuando el PM es selec- cionado, la autoridad es otorgada a través del acta de constitución del proyecto o Project Charter. 2. Planificación:consisteenelgrupodeprocesosquedefineygradualmente refina los objetivos y alcance del proyecto. Durante esta etapa se planifica el curso de acción tomado para lograr los objetivos y el alcance pretendido del proyecto. 3. Ejecución: se compone de los procesos utilizados para completar el tra- bajo definido en el plan de gestión del proyecto con el objeto de cumplir con los requisitos de este. 4. Seguimiento y control: son los procesos realizados para supervisar y controlar la ejecución del proyecto de forma que se puedan identificar problemas potenciales oportunamente y adoptar las acciones correctivas, cuando sea necesario, para controlar su ejecución. El PM verifica que los entregables de cada fase se completen de acuerdo al plan de acción y alineados con el alcance y objetivos del proyecto. 5. Cierre: incluye los procesos utilizados para finalizar formalmente todas las actividades de un proyecto, entregar el producto terminado a terceros o cerrar uno cancelado. Este grupo de procesos establece formalmente que se ha finalizado un proyecto e incluye desde cerrar cuentas de control hasta la realización, por supuesto, de la fiesta de finalización a Figura 1.15 muestra la interacción normal esperada entre los distintos grupos de procesos de la dirección de proyectos. Como puede observarse, el desarrollo de los cinco grupos de procesos no es lineal y perfectamente delimitado en el tiempo, sino que a medida que se comienza con cada una de las etapas es probable estar entrando en el desarrollo de la siguiente. Asimismo, puede observarse que las etapas de planificación, ejecución y seguimiento y control se realizan durante todo el proyecto. 1.7.2 Ciclo de vida del proyecto y de la gestión de proyectos Como ya se ha mencionado anteriormente, para completar un proyecto este debe pasar por etapas lógicas según el marco contextual donde se desarrolle. Cada fase crea entregables, los que permiten que el proyecto avance a la próxima fase. Por lo tanto, cada fase puede tomarse como un proyecto en particular. Es entonces que el ciclo de vida del proyecto y el ciclo de vida de la dirección de proyectos están relacionados, como lo muestra la Figura 1.16, de la página 38. Los grupos de procesos se repiten normalmente en cada fase del ciclo de vida del proyecto para completarlo con éxito. 1.7.3 Procesos de dirección de proyectos y áreas de conocimiento La Tabla 1.3 ha sido tomada de la PMBOK® Guide (PMI®, 2008, p. 43), y relaciona las áreas de conocimiento con los grupos de procesos. 1.8 CONCLUSIONES De este capítulo se desprenden las siguientes conclusiones: • Un PM es responsable del liderazgo de un equipo de personas hacia el alcance de los objetivos del proyecto. Actuar en forma responsable significa no transgredir el Código de Ética y Conducta Profesional del PMI®. • El gerente de proyecto debe ser proactivo todo el tiempo, adelantándose a los problemas, buscando cambios, previniendo inconvenientes, reco- nociendo y mitigando riesgos, identificando el impacto en el proyecto de decisiones y/o situaciones antes de ejecutarlas. ¡Esto es actuar en forma responsable! • Un gerente de proyecto debe buscar con esmero stakeholders, en principio, no evidentes u ocultos. Debe, en todos los casos, investigar los efectos del proyecto sobre todas las partes involucradas. Entender los aspectos socia- les, culturales, organizacionales y el entorno del proyecto es trascendental para descubrir a todos los stakeholders. • Como PM es primordial alinear las expectativas de todos los stakehol- ders buscando una visión compartida en las decisiones del proyecto. Para realizar esto se pueden utilizar técnicas de tormenta de ideas, Delphi y entrevistas. • La identificación del ciclo de vida del proyecto y la definición de entrega- bles para cada fase del proyecto es entera responsabilidad del PM. La dirección de proyectos es una profesión que requiere tanto de rigurosidad técnica en los fundamentos de gestión de proyectos como habilidades perso- nales específicas y visión global del negocio de la organización ejecutante. Ser PM implica responsabilidad, experiencia y sobre todo capacidad de escuchar a las personas, ya que nadie sabe todo, pero cada uno sabe algo. Sófocles (496 a.C. - 406 d.C.) dijo: “Ningún hombre es sabio por sí mismo”. Como dijimos al principio del capítulo, un proyecto es una larga serie de adversidades que deben ser sorteadas, por lo tanto, se requiere de todos en el equipo de proyecto para poder lograrl 1.2.2 La profesión de dirección de proyectos La dirección de proyectos es el liderazgo de un equipo de personas hacia la concreción de objetivos y requisitos del proyecto utilizando cono- cimientos, habilidades, herramientas y técnicas (Figura 1.2). Según el PMI®, la dirección de proyectos consiste en la aplicación de co- nocimientos, habilidades, herramientas y técnicas provenientes de áreas de conocimiento y grupos de procesos específicos que deben ser aplicados con responsabilidad profesional y social. 5 Por paquete de trabajo se entiende el último piso de la estructura de desglose del trabajo. Este concepto será desarrollado en el capítulo 3, sobre la gestión de alcance. Responsabilidad profesional y social significa que las acciones de los gerentes de proyectos deben estar siempre en línea con requerimientos legales y estándares éticos. El PMI® entiende que debido a que la ejecu- ción de un proyecto afecta tanto al equipo de trabajo como a la sociedad donde este es ejecutado, su gerente debe aplicar las mejores prácticas disponibles de la profesión para asegurar y proteger los derechos de los stakeholders y del segmento de la sociedad donde se desarrolla. Esto es hacer lo correcto, seguir el proceso adecuado, actuar éticamente, en forma justa y profesional, cuidar los conflictos de intereses, reportar in- fracciones, incrementar el conocimiento y buenas prácticas y lidiar con problemas. Este tema se tratará en profundidad en el capítulo 11 de ética y responsabilidad profesional, sin embargo, es importante tener esto en mente durante la lectura de todo el libro. •Los grupos de procesos siguen el ciclo de vida de un proyecto6; ellos son: grupo de procesos de iniciación, planificación, ejecución, seguimien- to y control y cierre de proyecto. •Las áreas de conocimiento son integración de proyectos, alcance, tiem- pos, costos, riesgos, comunicaciones, adquisiciones, calidad y recursos humanos. Aunque estas áreas serán tratadas en detalle en los capítulos siguientes del libro, se describen brevemente a continuación: – Gestión de la integración del proyecto. Comprende los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los distintos procesos y actividades de todos los grupos de procesos de la dirección de proyectos. – Gestión del alcance del proyecto. Reúne los procesos necesarios para asegurar que el proyecto incluya única y totalmente el trabajo re- querido, que será planificado y controlado para completar el proyecto satisfactoriamente. – Gestión del tiempo del proyecto. Se refiere a los procesos necesa- rios para planificar, ejecutar y supervisar el proyecto y así lograr termi- narlo a tiempo. – Gestión de los costos del proyecto. Abarca los procesos requeridos en la estimación y preparación del presupuesto y control de costos para que el proyecto pueda ser completado dentro de los parámetros apro- bados. – Gestión de los riesgos del proyecto. Consiste en los procesos rela- cionados con la planificación de la gestión de riesgos, su identificación y análisis, las respuestas a estos y el seguimiento cercano, aumentando de este modo las probabilidades de que el proyecto termine con éxito. 6 Define las fases que conectan el inicio de un proyecto con su fin. – Gestión de las comunicaciones del proyecto. Incluye los procesos de planificación, ejecución, seguimiento y control para asegurar la co- rrecta generación, colección y distribución a tiempo de la información del proyecto. – Gestión de la calidad del proyecto. Involucra todos los procesos de la organización ejecutante del proyecto que definen las políticas, los ob- jetivos y las responsabilidades relativos a la calidad, a fin de satisfacer los requerimientos por los cuales se inició el proyecto. – Gestión de los recursos humanos del proyecto. Considera los pro- cesos necesarios para organizar y dirigir personas definiendo sus res- pectivos roles y responsabilidades dentro de cada equipo de proyecto para finalizarlo con éxito. – Gestión de las adquisiciones del proyecto. Incluye los procesos necesarios para adquirir productos, servicios o resultados necesarios fuera del equipo de proyecto y la administración de los contratos co- rrespondientes. Además incluye los procesos de gestión del contrato y control de cambios correspondientes. Para responder adecuada- mente las preguntas del examen, es conveniente que usted se ponga en el lugar de la organización ejecutante del proyecto y por lo tanto adquirente de productos, servicios o resultados. Como dijimos anteriormente, la dirección de proyectos incluye el liderazgo de personas hacia el alcance de los objetivos del proyecto, por lo tanto, siendo que estos son únicos y limitados en el tiempo, el gerente de proyec- to (PM)7 debe estar activamente comprometido e involucrado en su gestión y ejecución. El proyecto no toma velocidad y dirección en forma automática, por lo que el PM debe poseer y aplicar habilidades, conocimientos, herra- mientas y técnicas en las áreas de conocimiento y grupos de procesos en forma responsable de acuerdo al Código de Ética y Conducta Profesional del PMI®. Gestión de la integración Conceptos clave Luego de leer y estudiar este capítulo, usted dominará los siguientes conceptos: ■ Proceso de gestión de integración. ■ Acta de constitución del proyecto (Project Charter). ■ Control integrado de cambios. ■ Plan de gestión de proyecto (plan para la dirección de proyectos). ■ Rol integrador del gerente de proyecto. ■ Control integrado de cambios. ■ Supervisión y control. ■ Cierre del proyecto. 2.1 INTRODUCCIÓN Integrar es reunir las partes coordinadamente para formar un todo. En este caso, las partes constituyen cada área del proyecto, y quien ejecuta esa ta- rea por excelencia es el gerente de proyecto (Project Manager, PM). La gestión de integración del proyecto es la clave para su éxito. Quien debe asumir la responsabilidad para coordinar todas las personas, planes y trabajo requerido para completar el proyecto, quien debe enfocar con perspectiva y conducir el equipo de proyecto hacia el éxito de este, quien toma las deci- siones finales en conflictos que involucran objetivos o personas, quien debe informar a la gerencia superior y comunicar aspectos clave del proyectos es el gerente del proyecto. Ejecutar todas estas tareas es realizar la gestión de integración del proyecto. Una buena gestión de integración del proyecto es crítica para proveer sa- tisfacción a los interesados. Recuerde que la gestión de integración de pro- yectos se extiende sobre los cinco grupos de procesos, desde la iniciación hasta el cierre, y es la única área de conocimiento con esta característica, de allí la importancia que tiene para el gerente de proyecto y para el examen de PMP®. 2.2 MARCO CONCEPTUAL DE LA GESTIÓN DE LA INTEGRACIÓN La gestión de integración implica coordinar todas las áreas del conocimien- to de la administración de proyectos durante el ciclo de vida de estos. Esta integración asegura que todos los elementos de un proyecto coincidan en el momento adecuado para completarlo satisfactoriamente. De acuerdo a la PMBOK® Guide, existen seis procesos principales en la gestión de la integración, los cuales se muestran en la Figura 2.1. FIGURA 2.1 Procesos de la gestión de la integración • Desarrollar el acta de constitución del proyecto, que implica trabajar con los stakeholders para crear el documento que formalmente autoriza al proyecto. • Desarrollar el plan de gestión de proyecto, que implica coordinar todos los esfuerzos de planificación para crear un documento consistente y cohe- rente con los objetivos perseguidos. • Dirigir y gestionar la ejecución del proyecto, que implica ejecutar las activi- dades descriptas en el plan de gestión de proyecto. El resultado de estos procesos son los entregables, los cambios requeridos, la información del rendimiento del trabajo del proyecto, requerimiento de cambios implemen- tados, acciones correctivas y preventivas y reparación de defectos. • Supervisar y controlar el trabajo del proyecto, que implica verificar que el trabajo del proyecto cumpla los objetivos de rendimiento del proyecto. El resultado de este proceso son las acciones correctivas y preventivas recomendadas, pronósticos y cambios requeridos. • Ejecutar el control integrado de cambios, que implica coordinar cambios que afectan los entregables del proyecto y los procesos de la organiza- ción. Las salidas de este proceso incluyen requerimientos de cambios aprobados o rechazados, realizar las acciones correctivas y preventivas aprobadas, reparación de defectos aprobados y validados, entregables y actualizaciones al plan de gestión de proyecto y al enunciado del alcance del proyecto. • Cerrar el proyecto, que implica todas las actividades del proyecto para for- malizar el cierre. Los resultados de este proceso incluyen productos finales, servicios o resultados, procedimientos de cierre administrativos y de contratos, así como actualizaciones a los procesos de la organización. 2.2.1 Desarrollar el acta de constitución del proyecto (Project Charter) Una vez que la gerencia superior ha decidido qué proyecto ejecutar, es im- portante dar a conocer al resto de la organización esta decisión. De aquí que la gerencia necesite crear y distribuir documentos para autorizar la iniciación de estos proyectos. Estos pueden tomar diferentes formas, pero una forma común es el acta de constitución del proyecto o Project Charter. Algunas organizaciones inician los proyectos mediante una carta de acuer- do, mientras que otras usan documentos más complejos y largos o contratos formales, como el Project Charter. El sponsor del proyecto es quien firma el acta de constitución para reconocer la necesidad del proyecto y la intención de llevar adelante su ejecución. El acta de constitución del proyecto es un resultado clave del proceso de inicio. Este documento formalmente reconoce la existencia de un proyecto y provee dirección en los objetivos del proyecto y de la gerencia. Autoriza al gerente de proyecto a usar los recursos de la organización para completar el trabajo. Como todo proceso, desarrollar el acta de constitución del proyecto presenta entradas y salidas. La Figura 2.2 muestra como entradas varios ítems que se describen a con- tinuación: • Si se trabaja en un proyecto bajo un contrato, este debería incluir mu- cha de la información necesaria para crear un acta de constitución del proyecto. Hay quienes usan el contrato en lugar del acta de constitución del proyecto, sin embargo, buen número de los contratos son difíciles de comprender y usualmente pueden cambiar. El plan de negocio creado a partir de una demanda del mercado o de una necesidad del negocio es suficiente para justificar el proyecto. • El enunciado del trabajo es un documento que describe los productos o servicios a ser creados por el equipo de proyecto. Usualmente incluye una descripción de las necesidades y un resumen de las características de los productos o servicios y la información de la organización, que muestra el alineamiento del proyecto con los objetivos estratégicos. • Los factores ambientales de la organización incluyen los planes, políticas, procedimientos y guías, infraestructura, recursos humanos, condiciones de mercado, riesgo de la industria particular, tolerancia al riesgo de los interesados y sistemas de información de la gestión de proyectos. • Los activos de los procesos de la organización abarcan planes forma- les e informales, políticas, procedimientos, sistemas financieros, sistemas de gestión, lecciones aprendidas e información histórica, que permiten mejorar los procesos en una organización específica. Los gerentes de proyecto deben revisar los planes formales e informales, los procedimientos y guías al momento de desarrollar el acta de constitución del proyecto. Aunque el formato de las actas de constitución del proyecto puede variar enormemente, debe incluir la siguiente información básica: • Título del proyecto y día de autorización. • Nombre del gerente de proyecto designado e información de contacto. • Un cronograma resumido (si existieran eventos conocidos, deberían ser incluidos o referenciados), incluyendo las fechas planeadas de comienzo y finalización. • Un resumen del presupuesto del proyecto o referencias de la información acerca de este. • Una descripción breve de los objetivos del proyecto, incluyendo las nece- sidades del negocio u otra justificación para autorizarlo. • Un resumen de los objetivos para administrar el proyecto, que debería describir necesidades y expectativas de los interesados, supuestos y res- tricciones, y referencias a documentos relativos. • Una matriz de responsabilidades. • Una sección para las firmas de los interesados clave del proyecto. • Una sección para comentarios, en la cual los interesados puedan proveer información importante relativa al proyecto. Muchos proyectos fracasan por no tener requerimientos y expectativas cla- ras; de allí que la existencia de un acta de constitución del proyecto facilita el entendimiento de esas expectativas. Si el gerente de proyecto tiene difi- cultades en obtener apoyo de los interesados en el proyecto, por ejemplo, es importante referirse a un documento que haya sido acordado por todos los interesados, como lo es el acta de constitución del proyecto. A manera de ejemplo, en la Figura 2.3 se incluye un Project Charter. TÍTULO DE PROYECTO: Renovación y remodelación de edificio de oficinas de marketing y finanzas de la corporación. FECHA DE COMIENZO DEL PROYECTO: 6 de agosto de 2007. FECHA DE FINALIZACIÓN PROYECTADA: 19 de octubre de 2008. GERENTE DE PROYECTO: Marcos Escalante (m.escalante@techcorp.com). Tel. 691-7724 OBJETIVOS DEL PROYECTO: remodelación de oficinas y agregado de nuevo módulo al edificio, con nuevas oficinas y salas de reuniones. Ver documento adjunto con detalles de la cantidad de espacios a agregar y la remodelación de los espacios comunes, y nuevos portales de ingreso al edificio. La remodelación incluirá la construcción de nuevas salas de reuniones y salón de eventos corporativo. El presupuesto total es de $ 2.500.000. ENFOQUE Y RESTRICCIONES: Revisar el diseño final y su compatibilidad con los requerimientos de espacio y nuevas oficinas. Desarrollar un estudio detallado de costos del proyecto, e informar al CEO de la corporación. Emitir invitaciones a oferentes calificados para la construcción. Usar recursos de ingeniería de la corporación para la planificación y la revisión del diseño de los posibles oferentes 2.2.2 Desarrollar el plan para la dirección del proyecto El plan para la dirección del proyecto (plan de gestión de proyecto) es un documento usado para coordinar todos los documentos de planeamiento del proyecto y una guía para su ejecución y control. Los planes creados en otras áreas de conocimiento son considerados planes subsidiarios del plan de gestión general del proyecto. Como los procesos anteriores, tendrá sus propias entradas y salidas (Figura 2.4). El plan de gestión de proyecto también permite documentar supuestos y deci- siones hechos durante la etapa de planificación respecto de opciones posibles y facilita la comunicación entre los interesados. Define también el contenido, extensión y momento de revisiones clave de la gestión, proveyendo una línea base para la medición y control del avance. Debe ser un documento vivo, diná- mico, flexible y sujeto a cambio, cuando el ambiente o el proyecto cambien. El plan debe servir de asistencia al gerente de proyecto para liderar a su equipo y para conocer el estatus del proyecto. Para crear y ensamblar un buen plan de gestión, el gerente debe practicar el arte de gestión de integración, dado que es requerida la información de todas las áreas de conocimiento de la ad- ministración de proyectos. A través del trabajo conjunto del equipo de proyecto y su gerente, el plan de gestión facilitará su ejecución y se logrará una mejor eficacia del conjunto del proyecto. 2.2.2.1 CONTENIDOS DEL PLAN DE GESTIÓN DE PROYECTO De la misma manera que los proyectos son únicos, también lo son los planes de gestión de proyecto. Uno pequeño, que involucre a algunas personas por unos pocos meses, tendrá un plan de gestión, que consistirá principalmente en un acta de constitución (Project Charter), un enunciado del alcance y un diagrama de barras. Mientras que un proyecto que dure tres años y en el que estén involucrados cientos de personas tendrá un plan de gestión con muchos más detalles. De aquí que los planes de gestión de proyecto deben estar confeccionados a la medida del proyecto para poder satisfacer sus necesidades particulares. El plan de gestión se desarrolla a través de una serie de procesos integra- dos hasta el cierre del proyecto. Esto da como resultado un plan de gestión que es progresivamente elaborado por actualizaciones y aprobado a través del control integrado de cambios que se discutirá más adelante. El plan de gestión de proyecto debe guiar el trabajo, de manera que sea tan detallado como sea necesario para el proyecto. No obstante, existen elementos comu- nes a todos los planes de gestión. Partes del plan incluirán una introducción general del proyecto, una descripción de la organización de este, así como su gerenciamiento y los procesos técnicos usados en él, con secciones que describan cómo será ejecutado el trabajo, el cronograma y el presupuesto. La introducción o descripción del proyecto deberá incluir, como mínimo, la siguiente información: • El nombre del proyecto. • Una descripción del proyecto y la necesidad que satisface, la cual debe definir claramente los objetivos. Deberá, en lo posible, evitar el lenguaje técnico e incluir una estimación aproximada del costo y el tiempo de ejecu- ción del proyecto. • El nombre del patrocinador o sponsor. Su posición en la organización y su información de contacto en la introducción. • El nombre del gerente de proyecto. Dependiendo de la naturaleza y tama- ño del proyecto, los nombres de miembros clave del equipo, en lo posible, deben ser incluidos. • Entregables del proyecto. Esta sección debe describir brevemente los pro- ductos resultantes del proyecto. Listar documentos o reuniones importantes ayuda a los interesados a recopilar y entender la historia del proyecto. • Planes subsidiarios. Esta sección debe referir a otros planes generados en otras áreas de conocimiento a manera de resumen (el plan de gestión del alcance, el de gestión de cronograma y de costo, gestión de calidad, recur- sos humanos, gestión de las comunicaciones, gestión de riesgos y gestión de adquisiciones). • Una lista de definiciones y abreviaturas relevantes para el proyecto. La descripción de cómo el proyecto está organizado debe incluir lo si- guiente: • Organigramas. Además del de la organización que ejecuta el proyecto y del cliente, si se trata de un cliente externo, debe existir uno del proyecto que muestre las líneas de autoridad, responsabilidades y comunicación de este. • Responsabilidades del proyecto. Esta sección del plan debe describir las funciones principales del proyecto y las actividades, identificando a los individuos que han sido designados para ejecutarlas. Una matriz de respon- sabilidades es una herramienta adecuada para mostrar dicha información. • Otra información organizacional o relativa al proceso. Dependiendo de la naturaleza del proyecto, puede ser necesario documentar los princi- pales procesos seguidos en él. La sección del plan de gestión de proyecto que describe el gerenciamiento y los enfoques técnicos debe incluir la siguiente información: • Objetivos de la gerencia. Es importante entender la visión que la ge- rencia superior tiene sobre el proyecto, cuáles son las prioridades y las principales restricciones y supuestos. • Controles del proyecto. Esta sección describe cómo monitorear los avan- ces del proyecto y cómo se manejan los cambios, si existirán revisiones mensuales o trimestrales, si existirán plantillas específicas, si el proyec- to usará gestión del valor ganado para evaluar y registrar rendimiento, así como el nivel de gerencia requerido para aprobar los cambios, etcétera. • Gestión de riesgos. Esta sección describe brevemente cómo el equipo de proyecto identificará, administrará y controlará los riesgos. Hará referencia al plan de gestión de riesgos, si se requiere uno para el proyecto. • Recursos humanos. Esta sección describe el número y tipo de personas requeridos para el proyecto. Se refiere al plan de gestión del personal afectado por el proyecto. • Procesos técnicos. Esta sección describe metodologías específicas que el proyecto puede usar y explica cómo documentar la información. La próxima sección en el plan de gestión de proyecto describe el trabajo a ejecutar y hace referencia al plan de gestión del alcance. Resume los siguientes ítems: • Principales paquetes de trabajo. El gerente de proyecto usualmente organiza las tareas del proyecto en varios paquetes de trabajo usando la estructura de división del trabajo (EDT) y crea un enunciado del alcance para describir el trabajo con más detalle. Esta sección resume los princi- pales paquetes de trabajo del proyecto y refiere a las secciones apropia- das del plan de gestión del alcance. • Entregables clave. Esta sección detalla y describe los productos clave producidos por el proyecto. También describe las expectativas de calidad de dichos entregables. • Otra información relativa al trabajo. Esta sección describe información clave relativa al trabajo del proyecto, como por ejemplo hardware o soft- ware específico a ser usado en el proyecto. La sección de cronograma del proyecto debe incluir la siguiente in- formación: • Cronograma resumido. Es de mucha ayuda poder observar un crono- grama general de una página. Dependiendo de la naturaleza y tamaño del proyecto, el cronograma resumen puede listar solo entregables clave y su fecha planeada de entrega. Para pequeños proyectos puede incluir todo el trabajo y las fechas establecidas para el proyecto completo en un diagrama de Gantt. • Cronograma detallado. Esta sección provee información en el cronogra- ma del proyecto que es más detallado. Hace referencia al plan de ges- tión de tiempos o cronograma, discutiendo dependencias entre actividades del proyecto que pueden afectar el cronograma del proyecto. Por ejemplo, puede explicar por qué un paquete determinado de trabajo no puede co- menzar hasta que no se disponga del financiamiento necesario. Un diagra- ma de redes puede mostrar claramente estas dependencias. • Otra información relativa al cronograma. Muchos de los supuestos son formulados al efectuar el cronograma, por lo que estos deben ser remarcados. La sección de presupuesto del proyecto debe incluir: • Resumen del presupuesto. Este contiene el estimado total del proyecto. Puede incluir el presupuesto estimado para cada mes del año. Es importan- te aclarar si el monto establecido es una cifra que no cambiará o si es una estimación basada en los costos del proyecto en los próximos años. • Presupuesto detallado. Esta sección resume cuál es el plan de gestión de costos e incluye información más detallada del presupuesto. Por ejem- plo, ¿cuál es la estimación de costos fijos y variables para cada año del proyecto? ¿Cuáles son los beneficios financieros del proyecto? ¿Cuáles son los costos de los salarios de las personas que ejecutarán el proyecto? ¿Qué otros supuestos relativos a los aspectos financieros del proyecto se han efectuado? • Línea base de medición de rendimiento. Usualmente las líneas base de alcance, agenda y costo se combinan en una línea base de medición de rendimiento que permite medir el rendimiento integrado. Muchas organizaciones usan guías para crear planes de gestión de proyec- to. Existen programas comerciales que proveen plantillas como guías. Sin embargo, no debe confundirse el plan de gestión de proyecto con un diagra- ma de Gantt. El plan de gestión de proyecto incluye todos los documentos de planificación del proyecto. Los planes creados en otras áreas del conocimiento son considerados sub- sidiarios del plan general de gestión de proyecto. Las organizaciones privadas poseen las normas con documentación específica para el plan de gestión de proyecto, no obstante, son menos rigurosas que los estándares y normativas de las instituciones gubernamentales o públicas. Existen guías para desarro- llar planes de gestión de proyecto, por lo que constituye una buena práctica seguir tales estándares o guías para facilitar el desarrollo y ejecución de es- tos planes. La organización puede trabajar de manera más efectiva si todos los planes siguen un formato similar. A continuación, la Tabla 2.1 muestra un ejemplo de contenidos para un proyecto de tecnología. En esta etapa, el gerente de proyecto debe concentrarse en liderar al equi- po de proyecto y manejar la relación con los distintos interesados para ejecutar el plan de gestión de proyecto en forma satisfactoria. A su vez, la gestión de recursos humanos y la gestión de comunicaciones del proyec- to son cruciales para su éxito. Durante la ejecución del proyecto muchas situaciones imprevistas pueden ocurrir, de manera que se requiere flexibi- lidad y creatividad para superarlas. La gestión de integración del proyecto ve a la planificación y ejecución del proyecto como actividades interdepen- dientes e inseparables. La principal función de crear un plan de gestión de proyecto y todos sus programas subsidiarios es servir de guía para su eje- cución. Un buen plan debe ayudar a producir buenos productos y resulta- dos. El plan debe documentar en qué consisten los buenos resultados del proyecto. Las actualizaciones al plan deben reflejar el conocimiento gana- do en terminar otros proyectos similares o el trabajo del proyecto de una manera más rápida. Una regla de sentido común para mejorar la coordi- nación en la planificación y la ejecución es simple: aquellos que harán el trabajo deben también planificarlo. Todo el personal afectado por el proyecto debe desarrollar y crear experiencia en ambas habilidades: la de planificar y ejecutar. De igual manera, los gerentes de proyecto son los responsables de desarrollar el plan de gestión de proyecto y solicitar a los miembros del equipo de proyecto que desarrollen planes en cada área de conocimiento. Hay dos factores importantes que deben existir durante la ejecución del proyecto: el soporte de la organización y un fuerte liderazgo. El gerente deproyecto debe liderar con el ejemplo, demostrando la importancia de crear buenos planes de proyecto, y luego seguirlos durante su ejecución; de esta manera los miembros del equipo de proyecto seguirán idéntico camino. A su vez, si una organización dispone de guías y plantillas para la gestión de pro- yecto, será más fácil la ejecución de los planes dentro de esta. Aun cuando la organización dispone de una cultura y de reglas que soportan la ejecución de planes, es necesario para algunos proyectos que el gerente rompa las reglas cuando esto redunda en beneficio del proyecto y de su ejecución, para lo cual es necesario liderazgo, comunicación y habilidad política. 2.2.3.1 TÉCNICAS Y HERRAMIENTAS PARA LA EJECUCIÓN Dirigir y gestionar la ejecución requiere herramientas y técnicas especiales, algunas de las cuales son únicas de la administración de proyectos. Los geren- tes de proyecto pueden usar herramientas y técnicas específicas para ejecutar actividades que son parte del proceso de ejecución. Estas incluyen: • Juicio de expertos. El juicio de expertos se usa en los detalles técnicos y de gestión durante este proceso. Este puede ser provisto por el gerente de proyecto y su equipo o bien por otros interesados, asociaciones profe- sionales y consultores externos al proyecto. • Sistemas de información de la gestión de proyectos. Si bien se ha dicho que existen muchísimos programas disponibles en el mercado para ayudar al seguimiento de tareas, los gerentes de proyecto deben recordar que el liderazgo efectivo y un compromiso con el trabajo en equipo son críticos para el éxito de la gestión de proyectos. Los gerentes de proyecto deben delegar el trabajo de detalle en el uso de estas herramientas infor- máticas a otros miembros del equipo y enfocar su tarea en proveer lide- razgo para asegurar el éxito del proyecto. El trabajo de dirigir y gestionar la ejecución puede ser ilustrado de la siguiente manera: 2.2.4 Supervisar y controlar el trabajo del proyecto En grandes proyectos, muchos gerentes de proyecto afirman que el 90% de su trabajo es comunicar y administrar los cambios, los cuales son in- evitables en la mayoría de proyectos. Es por esto que es tan importante desarrollar y seguir un proceso de supervisión y control de los cambios (Figura 2.7). La supervisión del trabajo del proyecto incluye colectar, me- dir y distribuir la información de eficiencia; también implica analizar tales mediciones y determinar qué mejoras pueden hacerse en el proceso. El equipo de proyecto debe supervisar de forma continua la eficiencia para determinar el estado general del proyecto e identificar aquellas áreas que requieran atención particular. El plan de gestión de proyecto, la información de su eficiencia y las lec- ciones y experiencias aprendidas de proyectos anteriores son las prin- cipales entradas para controlar el trabajo del proyecto. La herramienta clave para este proceso es el juicio de expertos que el gerente de pro- yecto y su equipo hagan con la información proveniente de los sistemas de gestión de proyecto para tomar las decisiones adecuadas. Las dos salidas más importantes de la supervisión y control del trabajo del pro- yecto son los cambios requeridos (acciones correctivas, preventivas, reparación de defectos y pronósticos) y las actualizaciones a los documen- tos del proyecto. • Acciones correctivas: darán como resultado una mejora en la eficiencia del proyecto, mientras que las acciones preventivas reducirán la probabi- lidad de consecuencias negativas asociadas con los riesgos del proyecto. Por ejemplo, si los miembros del equipo de proyecto no han reportado sus horas trabajadas en el proyecto, una acción correctiva será mostrarles cómo ingresar la información y hacerles saber sobre la importancia de que lo hagan. • Acciones preventivas: serán las que modifiquen el sistema de segui- miento del tiempo para evitar errores producidos o facilitar el ingreso de dicha información al sistema. • Reparación de defectos: implica la identificación del defecto en el componente del proyecto, su reparación o reemplazo completo, si fuera necesario. • Pronósticos: son también una salida importante de la supervisión del trabajo, pues permiten determinar condiciones y eventos en el futuro del proyecto a partir de información pasada. Por ejemplo, los gerentes de proyecto usualmente proveen pronósticos de la cantidad de dinero que necesitarán para completar un proyecto basado en la medición anterior del rendimiento de este. 2.2.5 Realizar el control integrado de cambios Implica identificar, evaluar y gestionar los cambios a través del ciclo de vida del proyecto. Los tres principales objetivos del control integrado de cambios son: • Influenciar los factores que crean los cambios para asegurar que es- tos sean beneficiosos y que el proyecto sea exitoso. En este sentido, el gerente y su equipo de proyecto deben siempre adoptar soluciones de compromiso entre el alcance, los plazos, el costo y la calidad. • Determinar que el cambio ha ocurrido, para lo cual el gerente de pro- yecto debe conocer el estado de las áreas sensibles del proyecto en todo momento. Por otro lado, es él quien debe comunicar los cambios de im- portancia a la gerencia superior e interesados clave. La gerencia superior no desea sorpresas concernientes al proyecto, tales como que el pro- yecto costará más, llevará más tiempo o tendrá una calidad inferior a la deseada. • Gestionar los cambios a medida que ocurran es un rol clave del ge- rente de proyecto y su equipo, por lo que es importante tener mucha dis- ciplina en la gestión de proyecto para ayudar a minimizar el número de cambios. Este proceso tendrá también sus propias entradas y salidas como se señala en la Figura 2.8, de la página 76. Entradas importantes al proceso de control integrado de cambios incluyen el plan de gestión de proyecto, la información de rendimiento (usualmente en la forma de informes de rendimiento), los cambios requeridos y las acciones correctivas y preventivas recomendadas. Salidas a este proceso incluyen requerimientos de cambio aprobados y recha- zados, acciones preventivas y correctivas aprobadas, reparación de defectos aprobados y validados, entregables y actualizaciones al plan de gestión de proyecto y al plan de gestión del alcance. El plan de gestión de proyecto provee la línea base (el plan de gestión apro- bado más los cambios aprobados) para identificar y controlar los cambios del proyecto. Por ejemplo, el plan de gestión de proyecto incluye una sección que describe el trabajo a ejecutar. Esta sección describe los entregables cla- ve del proyecto y los requerimientos de calidad. La sección del cronograma del plan de gestión de proyecto lista las fechas planeadas para completar esos entregables clave y la sección del presupuesto del programa de gestión de proyecto provee el costo planeado para esos entregables o productos del proyecto. El equipo de proyecto debe concentrarse en entregar el trabajo según como se planeó. Si el equipo o algún otro involucrado incurren en cambios durante la ejecución, el equipo de proyecto debe revisar el plan de gestión de proyecto y hacerlo aprobar por el patrocinador del proyecto o por el gerente de proyecto. Muchas personas se refieren a diferentes tipos de líneas base, como la línea base de costo o la de cronograma, a fin de describir diferentes objetivos o metas del proyecto y la eficiencia respecto a poder cumplirlas. Los informes de rendimiento proveen información de cómo se desarrolla la ejecución del proyecto, siendo el principal objetivo alertar al gerente y al equipo de proyecto de problemas que pueden aparecer en el futuro. El gerente de proyecto y su equipo decidirán si acciones preventivas o co- rrectivas son necesarias, cuál es el mejor camino a seguir y cuándo aplicar dichas acciones. Por ejemplo, en un proyecto de instalación de un sistema informático, uno de los entregables clave es el nuevo servidor. Si uno de los miembros del equi- po de proyecto reporta problemas en su adquisición e instalación, el gerente deberá evaluar qué pasará si este entregable clave está disponible más tarde de los previsto, los problemas que causará esto en otras áreas del proyecto y qué acciones puede tomar para ayudar al miembro del equipo a comple- tar la tarea a tiempo. Si nada puede hacerse respecto a cumplir la fecha, el gerente de proyecto debe alertar a las otras personas que se verán afecta- das por este cambio. El gerente también debe ver en perspectiva el estado del proyecto, para determinar si existen retrasos generales en otras áreas y alertar a los interesados clave de este y negociar una fecha de finalización más tardía. Los requerimientos de cambios son muy comunes en los proyectos y ocu- rren en diferentes formas. Pueden ser orales o escritos, formales o informales. Continuando con el ejemplo anterior, el miembro del equipo de proyecto res- ponsable de instalar el servidor puede sugerir en la próxima reunión de segui- miento del proyecto comprar un servidor más rápido, fabricado por la misma compañía, y de idéntico costo. En este caso, el cambio no tiene influencia negativa en el proyecto, y el gerente de proyecto puede dar aprobación verbal en la reunión. No obstante, es importante que el gerente documente este cam- bio para evitar un problema potencial en el futuro. La persona responsable del equipo de proyecto deberá actualizar la sección del enunciado del alcance con la especificación del nuevo servidor. Es importante recordar que los requerimientos de cambio pueden tener un impacto importante en el proyecto. Por ejemplo, clientes que cambian el número de piezas o partes requeridas, como parte del proyecto, tienen un impacto importante en alcance y costo, y también pueden modificar el crono- grama del proyecto. En este caso, el equipo de proyecto debe registrar este cambio significativo en forma escrita y deberá existir un proceso de revisión formal para analizar y decidir la aprobación de estos cambios. En síntesis, el cambio es inevitable y usualmente esperado en la mayoría de proyectos, de aquí que un cuidadoso sistema de control de cambios es crítico para el éxito del proyecto. Ante la pregunta de qué hacer si un interesado desea efectuar un cambio al alcance, debe recordar para el examen los siguientes pasos que como gerente de proyecto debe efectuar antes de decidir hacer el cambio: •Evaluar el impacto. Significa evaluar el impacto de la triple restricción. •Buscar opciones (agregar recursos, hacer tareas simultáneas, etcétera). • Obtener apoyo interno para el efectuar el cambio. •Buscar consenso con el cliente si fuera necesario. 2.2.5.1 SISTEMA DE CONTROL DE CAMBIOS El sistema de control de cambios es un proceso formal y documentado que describe cuándo y cómo los documentos oficiales del proyecto pueden ser cambiados. Describe también a las personas autorizadas a efectuar los cam- bios, los pasos previos y documentos requeridos para efectuar cada cambio y el sistema automatizado o manual de seguimiento que tiene el proyecto. El sistema de control de cambios incluye usualmente: • el comité de control de cambios, • de gestión de la configuración y •el proceso usado para comunicar los cambios. El comité de control de cambios es un grupo de personas responsable de aprobar o rechazar los cambios en un proyecto. La función primaria de este comité es proveer una guía para efectuar los pedidos de cambio, evaluarlos y gestionar la implementación de los cambios aprobados. Una organización puede tener interesados clave en este comité y algunos miembros pueden rotar en función de las necesidades únicas de cada pro- yecto. La creación de este comité persigue una mejor gestión de los cambios en los proyectos, sin embargo, puede al mismo tiempo presentar inconve- nientes. Uno de ellos es el tiempo que lleva la toma de decisiones, consi- derando que este comité solo se reúne una vez semanalmente o una vez mensualmente, y no puede tomar decisiones en una reunión. Algunas organizaciones tienen procesos más directos para cambios meno- res en los proyectos. Dependiendo del costo que el cambio implica, la deci- sión puede quedar en manos del gerente de proyecto. El sistema de gestión de la configuración también es una parte importante del control integrado de cambios, pues asegura que la descripción de los productos del proyecto es correcta y completa. Además implica identificar y controlar sus características físicas y de diseño funcional y su documenta- ción de soporte. Los miembros del equipo de proyecto, frecuentemente llamados espe- cialistas de la configuración, son asignados para ejecutar la gestión de la configuración de grandes proyectos. Su trabajo consiste en identificar y documentar características funcionales de los productos de los proyectos, controlar cambios en ellas, registrar e informar sobre dichas variaciones y verificar que los productos cumplan con tales características. Otro factor relevante en el control de cambios es la comunicación de los cambios. Los gerentes de proyectos deben usar informes de rendimientos orales y escritos para identificar y gestionar los cambios. Uno de los aspec- tos más frustrantes en los cambios de los proyectos es no tener a todos co- ordinados sobre la última información del proyecto; de aquí que es la responsabilidad del gerente de proyecto integrar todos los cambios de manera que este se mantenga dentro del programa. El gerente de proyecto y su equipo deben desarrollar un sistema para notificar a todos aquellos afectados por el cambio en forma temprana. El siguiente punto presenta algunas sugerencias para ejecutar el control integrado de cambios. 2.2.5.2 SUGERENCIAS PARA EJECUTAR EL CONTROL INTEGRADO DE CAMBIOS • Tener en cuenta que la gestión de proyectos es un proceso constante de comunicación y negociación. • Planificar el cambio. • Establecer un sistema formal de control de cambio, incluyendo un comité de control de cambio. • Definir procedimientos para efectuar decisiones oportunas con cambios menores. • Usar informes de rendimientos escritos y orales para ayudar a identificar y gestionar el cambio. • Usar programas de gestión de proyectos u otro software para ayudar a gestionar y comunicar los cambios. • Enfocarse en liderar el equipo de proyecto y cumplir con los objetivos y metas generales. En general, puede decirse que los gerentes de proyecto deben planificar los cambios y usar las herramientas adecuadas. Es útil definir procedimientos para hacer decisiones oportunas en cambios menores, usar informes escritos y orales para ayudar a identificar y gestionar cambios relevantes y utilizar software para planificar, actualizar y controlar los proyectos. Los gerentes de proyecto deben también aportar un fuerte li- derazgo para conducir el proyecto a su finalización exitosa, así como delegar el trabajo de detalle a los miembros del equipo. Anteriormente se expuso sintéticamente los cuatro pasos en el proceso de efectuar cambios (evaluar el impacto, buscar opciones, obtener apoyo y bus- car consenso), pero veamos en detalle cómo deben tratarse los cambios, ya que el examen posee varias preguntas respecto a los cambios. Ante todo, el gerente de proyecto debe: • requerimiento de cambio. Prevenir la causa del cambio. • Identificar el cambio. • Crear un • Evaluar el cambio analizando si es necesario y beneficioso para el proyecto. • Evaluar el impacto del cambio. Cómo afecta el alcance o el cronograma del proyecto. • Efectuar el control integrado de cambios, es decir, verificar cómo el cam- bio afecta a los otros componentes de la triple restricción. • Evaluar opciones. • de gestión de proyecto. • de gestión. Aprobar o rechazar el cambio (ver ejercicio 2.6). • Ajustar las líneas base y el plan Notificar a los interesados del cambio. • Gestionar el proyecto con el nuevo plan A manera de resumen, y para un mejor entendimiento de cómo funciona el sistema de control integrado de cambios, se presenta la Figura 2.9, donde se indica el proceso de cómo proceder ante un cambio 2.2.6 Cerrar el proyecto El último proceso en la integración del proyecto es el cierre de este, como se detalla en la Figura 2.10. Para efectuar el cierre, el gerente de proyecto debe finalizar todas las actividades y transferir el trabajo completado o cancelado a las personas apropiadas. Como entradas del proceso de cierre se tiene el plan de gestión de proyecto, los entregables que han sido aceptados a través del proceso de verificación del alcance y los procesos existentes de la organización que pueden afectar el cierre del proyecto. Las principales salidas de cierre del proyecto son: • Productos finales, servicios o resultados. Los patrocinadores del pro- yecto son quienes tienen interés en recibir los productos, servicios o re- sultados que esperaban cuando iniciaron el proyecto. • Procedimiento de cierre administrativo. El equipo de proyecto y los interesados deben desarrollar y seguir paso a paso el proceso de cierre del proyecto; en particular los procedimientos de cierre administrativo y definir el proceso de aprobación de todos los entregables. • Procedimientos de cierre de contratos. Muchos proyectos involucran contratos que son acuerdos legales y vinculan a dos partes. El proce- dimiento de cierre de los contratos describe la metodología para ase- gurar que el contrato ha sido completado, incluyendo la entrega de los bienes y servicios y el pago por ellos. • Actualizaciones a los procesos organizacionales. El equipo de pro- yecto debe suministrar una lista de documentos del proyecto, documentos de cierre de este e información histórica producida por él. Esta informa- ción es considerada un activo del proceso. Por ejemplo, los equipos de proyecto normalmente redactan un informe de lecciones aprendidas al final, y esta información puede ser de muchísima utilidad para proyectos futuros. 2.3 CONCLUSIONES De este capítulo se desprenden las siguientes conclusiones: • Un gerente de proyecto es responsable del proyecto desde que nace o se concibe hasta el cierre. • El área de integración pone de manifiesto esta obligación del gerente de proyecto, pues abarca los cinco procesos, desde la iniciación hasta el cie- rre, pasando por la planificación, la ejecución y la supervisión y control. • La gestión de integración es por excelencia la actividad más importante desplegada por el gerente de proyecto, donde sus cualidades de negocia- dor, comunicador y sus habilidades para resolver conflictos son puestas de manifiesto. • Integrar es juntar las partes para formar un todo. El gerente de proyecto es la única persona del equipo de proyecto que conoce los detalles del proyecto y cómo ellos deben relacionarse armónicamente en cada de- cisión que debe efectuar, con una visión amplia hacia todo el proyecto y hacia la organización. • Los procesos de la gestión de integración son de vital relevancia para el proyecto. Desde la iniciación, con la confección del acta de constitución del proyecto (charter), hasta el cierre, el gerente de proyecto debe iden- tificar las expectativas de los diferentes stakeholders y anticiparse a los cambios que puedan surgir en el proyecto, manteniéndolo dentro de las líneas base planificadas. • Para llevar adelante todas las tareas que demanda la gestión de integra- ción, se requiere un alto grado de ejecutividad y liderazgo por parte del gerente de proyecto, que debe saber anticiparse al cambio y al conflicto, ejerciendo una comunicación efectiva con su equipo y los demás intere- sados en el proyecto. Finalmente, recordamos una frase de Anatole France: “Para concretar grandes proyectos no solo debemos actuar sino también soñar, no solamente planificar sino también creer”. Esa es precisamente la actitud que debe guiar las acciones del gerente de proyecto y saber transmitirla a su equipo para que los resultados sean los esperados. Gestión del alcance Conceptos clave Luego de haber procesado este capítulo usted dominará los siguientes conceptos fundamentales de la gestión del alcance del proyecto, a efectos de avanzar sobre su preparación para la certificación PMP®1. ■ Alcance del producto. ■ Alcance del proyecto. ■ Verificación del alcance del producto. ■ Verificación del alcance del proyecto. ■ Línea base del alcance. ■ Estructura de división del trabajo (EDT). ■ Beneficios de la EDT. ■ Entregables. ■ Enunciado del alcance del proyecto. ■ Plan de gestión del alcance del proyecto. ■ Criterio SMART. ■ Diccionario de la EDT. ■ Paquetes de trabajo. ■ Actividades del cronograma. ■ Cuenta de control. ■ Procesos de la gestión del alcance. ■ Análisis de stakeholders. ■ Análisis de productos. 1 Project Management Profesional, PMP® y el logotipo de PMP® son marcas registradas del Project Management Institute, Inc 2 Resumen ejecutivo Iniciados los estudios del proyecto, usted deberá desarrollar un plan de ges- tión del proyecto2. Este documento será la primera fuente importante de in- formación sobre cómo guiar al proyecto a través de las etapas de planifica- ción, ejecución, seguimiento y control y cierre. Un plan subsidiario de este es el plan de gestión del alcance. Con este plan deberemos responder a la pregunta clave sobre cómo vamos a definir, verifi- car y controlar el alcance del proyecto, y cómo se creará y definirá la estruc- tura de división del trabajo (EDT). En este capítulo presentaremos, siguiendo la PMBOK® Guide, los cinco pro- cesos que forman parte del área del conocimiento de gestión del alcance del Project Management Institute, marcando los tips fundamentales para el examen. Hay que destacar que este plan subsidiario no es un proceso explícito dentro de los procesos de gestión de proyectos enunciados por la PMBOK® Guide. Sin perder de vista que los procesos enunciados por el PMI® no son com- partimientos estancos3 ni son las fases de un proyecto, según fue explici- tado en el capítulo 1 de marco y procesos, al plantear una matriz de doble entrada, definida por grupos de procesos y por áreas del conocimiento, la gestión del alcance de un proyecto la podemos ubicar como se señala en la Figura 3.1. Objetivos del capítulo Este capítulo tiene por objetivo delinear un área del conocimiento que es fundamental para la planificación de los proyectos, la gestión del alcance. Sin una buena planificación y delimitación del alcance, las probabilidades de éxito del proyecto disminuyen significativamente. Lo que hemos pretendido es concentrarnos en los aspectos fundamentales a fin de prepararlo para su examen de certificación. Es por esto que hemos planteado como principales objetivos a alcanzar los siguientes: ■ Identificar los procesos de administración del alcance del proyecto. 2 Este plan de gestión del proyecto comienza a definirse en el segundo proceso de la gestión de la integración, explicitado en el capítulo 2 de este libro: 2.2.2 Desarrollar el plan de gestión del proyecto (documentar las acciones necesarias para trabajar en los planes subsidiarios en un plan de gestión). 3 Los grupos de procesos se pueden superponer cronológicamente ■ Justificar su importancia dentro de los procesos de administración de proyectos. ■ Plantear los principales outputs de la gestión del alcance. ■ Internalizar dichos procesos en su propia realidad. 3.1 INTRODUCCIÓN La gestión del alcance del proyecto incluye los procesos necesarios para asegurarse de que este incorpore en su totalidad y exclusivamente el trabajo requerido para completarlo satisfactoriamente. El propósito es la inclusión de todos los procesos y la realización de todas las tareas necesarias para el éxito del proyecto. Ahora bien, a la hora de definir el alcance deberá ser muy cuidadoso en cuanto a no confundir el alcance del producto con el alcance del proyecto (Figura 3.2). • Alcance del producto: es el conjunto de características y funciones que se incluyen en un producto, servicio o resultado. • Alcance del proyecto: es el trabajo que debe realizarse para entregar un producto, servicio o resultado con las funciones y características especi- ficadas. La verificación del alcance del proyecto se mide en comparación con el plan de gestión del proyecto, el enunciado del alcance del proyecto, su es- tructura de división del trabajo (EDT) y el diccionario de la EDT relacionados. La verificación del alcance del producto se mide en comparación con los requisitos del producto. 3.2 GESTIÓN DEL ALCANCE DEL PROYECTO La gestión del alcance del proyecto4 consta de cinco procesos, como se muestra en la Figura 3.4. Si bien la PMBOK® Guide no explicita un proceso de “planificar el alcance”, a efectos prácticos de preparar la certificación y su ejercicio profesional es útil tenerlo presente como un plan subsidiario del plan de gestión del proyecto. Los tres primeros procesos oficiales enunciados en la PMBOK® Guide per- tenecen al grupo de procesos de planificación, mientras que el cuarto y quin- to pertenecen al grupo de procesos de seguimiento y control, grupos de procesos explicitados en el capítulo 1 de este libro. Planificar el alcance persigue crear un plan subsidiario del proyecto que re- fleje cómo se recolectará, definirá, verificará y controlará el alcance del pro- yecto y cómo se creará y definirá la estructura de división del trabajo (EDT). En otras palabras, debe responder a la siguiente pregunta: ¿cómo voy a definir, verificar y controlar el alcance del proyecto? Procesos necesarios para asegurarse de que el proyecto incluya, solamente y en su totalidad, todo el trabajo requerido para completarlo satisfactoriamente. El marco de esta planificación estará en función del tipo de proyecto y de la disponibilidad de conocimiento. Generalmente se hará por fases, en función de cómo se vaya teniendo acceso a la información. 3.2.1 Proceso: recolectar requerimientos Es el proceso de definir y documentar las necesidades de los stakeholders a efectos de alinear los objetivos del proyecto. El éxito del proyecto está relacionado en forma directa con la eficacia y eficiencia con que se lleva adelante el relevamiento de los requerimientos de los diferentes interesados en el proyecto. Estos requerimientos se convertirán en la piedra fundamental de construc- ción de la estructura de división del trabajo5 (EDT). La idea central es asegurarnos que las necesidades, requerimientos y ex- pectativas de los interesados sean transformados en mandatos. Esto será un elemento crítico en la gestión de calidad y del éxito de todo el proyecto. Como todo proceso, tendrá sus entradas, herramientas y técnicas y salidas respectivas (Figura 3.5). 5 El proceso crear EDT será explicitado en el punto 3.2.3 de este capítul Como entradas figuran dos documentos, el acta de constitución del proyecto y el registro de stakeholders. En el primero se comenzó a definir en forma muy genérica qué es el proyecto, y el segundo es una salida del proceso de identificar stakeholders en el área de gestión de la comunicación. Este registro de stakeholders identifica a los diferentes interesados en el proyecto, al igual que sus requerimientos respecto del proyecto y del producto. Las herramientas y técnicas explicitadas en el proceso permitirán generar las siguientes salidas: • Documento de requerimientos: este documento describe cómo in- fluye individualmente cada requerimiento en los objetivos del proyec- to. Inicialmente estos requerimientos pueden ser expresados en forma bastante genérica, y en la medida que la planificación avance ir ganando mayor definición. Lo que sí es muy importante es que previo a la determinación de las líneas base, estos requerimientos deben quedar defini- dos de forma muy precisa, completa y consistente, y ser aceptados por todos los stakeholders. • Plan de administración de requerimientos: este plan documentará cómo los requerimientos serán analizados, documentados y administra- dos a través del proyecto. • Matriz de trazabilidad de requerimientos: es una tabla que unirá, para cada requerimiento, su origen y su camino a lo largo del ciclo de vida del proyecto. La idea es asegurarnos de que cada requerimiento agregue valor al proyecto. 3.2.2 Proceso: definir el alcance Este proceso, que se muestra en la Figura 3.6, es uno más dentro de los procesos de planificación, y pretende desarrollar un enunciado del alcance del proyecto detallado como base para futuras decisiones del proyecto. En otras palabras, deberá responder a la siguiente pregunta: ¿qué está y no está incluido en el proyecto? Como todo proceso, tendrá sus entradas, herramientas y técnicas y sus salidas Como herramienta de este proceso vale mencionar el análisis de producto. El propósito es analizar los objetivos establecidos por el cliente o patrocina- dor (sponsor) y transformarlos en requerimientos tangibles. Se complementa fuertemente con el análisis realizado en el proceso anterior para obtener los documentos de requerimientos, pero focalizado más en el cliente. La principal salida (output) de este proceso es el enunciado del alcance del proyecto6. Es una descripción escrita de los entregables del proyecto y del trabajo requerido para poder producirlos. Este enunciado debe contener: • Los objetivos del proyecto (que sean medibles). • Una descripción del alcance del producto (características y requisitos que el producto, servicio o resultado debe materializar). • Límites del proyecto (qué no incluye) . • Los productos entregables (salidas) y los criterios de aceptación del pro- ducto (procesos para aceptar). • Las restricciones y asunciones del proyecto, así como la organización (miembros del equipo) inicial de este. • Los riesgos iniciales (detectados) definidos, conjuntamente con los hitos del cronograma (restricciones). • Las limitaciones de fondos y una estimación del costo. • Finalmente, deberá enunciar los requisitos del sistema de gestión de la configuración7 del proyecto, las especificaciones del proyecto y los requi- sitos de aprobación. 6 Project Scope Statement. 7 Configuration Management System. En el acta de constitución del proyecto8, el sponsor define en forma muy general lo que quiere, pero es en el enunciado del alcance que el gerente de proyecto, conjuntamente con el cliente y el equipo de proyecto, acuerdan y confirman los entregables y requerimientos del proyecto. Es a partir de este enunciado del alcance que se lleva adelante una descripción más detalla- da de cómo será cada entregable. Estos entregables, en el enunciado del alcance, deben seguir un criterio SMART: • eSpecífico, • Medible, • Ambicioso (alcanzable y acordado), • Realista y • Tiempo establecido. 3.2.3 Proceso: crear EDT Este proceso (Figura 3.7) es el último del grupo de planificación de esta área del conocimiento, y lo que pretende es una descomposición jerárquica, orien- tada al producto entregable, del trabajo que será ejecutado por el equipo de proyecto. Es una herramienta fundamental para administrar la complejidad propia de los proyectos. Como todo proceso, tendrá sus entradas, herramientas y técnicas y sus salidas. Las salidas (outputs) principales de este proceso son: la EDT, el diccionario de la EDT, la línea base del alcance y los cambios requeridos. La EDT, que se indica en la Figura 3.8, es el cimiento fundacional del pro- yecto. Es un insumo fundamental para varios de los procesos que llevarán al éxito del proyecto. Integrando el acta constitutiva, el enunciado del alcance y la EDT, podemos marcar sus diferencias fundamentales de la siguiente manera: Enuncie y profundice las diferencias fundamentales entre el acta de consti- tución del proyecto, el enunciado del alcance y la estructura de división del trabajo. ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Respuesta El proceso avanza desde el mínimo detalle expuesto en el Project Charter hasta el máximo detalle expuesto en la EDT. En el Project Charter enuncia- mos el producto (entregable), en la definición del alcance lo precisamos con el criterio SMART y en la EDT lo definimos a nivel de control. EJERCICIO 3.5 Enuncie el objetivo de la estructura de división del trabajo (EDT). ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Respuesta El objetivo de la EDT es gestionar la complejidad propia de los proyectos, descomponiendo a este en unidades más manejables. Con esto se logrará mejorar la precisión de las estimaciones de tiempos y costos, definir el plan de referencia para la medición del rendimiento y control del proyecto y facilitar una clara asignación de responsabilidades. A efectos de facilitar el armado de la EDT, es recomendable asignar sustantivos a los diferentes pisos de esta, mientras que verbos a las actividades del crono- grama. Recordemos que las actividades del cronograma no forman parte de la EDT, sino que son parte del primer proceso de la gestión de tiempos: “Listar actividades”. A continuación, la Figura 3.10 señala un ejemplo de EDT. Una vez que la estructura de división del trabajo ha sido finalizada, se asig- nan códigos para poder distinguir dónde está ubicado cada paquete de trabajo dentro de esta. EJERCICIO 3.6 Considerando que la EDT tiene como objetivo mostrar cómo se subdividen los productos entregables del proyecto en paquetes de trabajo, intente reproducir la EDT del último proyecto en el que haya participado. _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ Gráficamente, podemos visualizar la relación entre la EDT y las actividades del cronograma de la siguiente manera. Los paquetes de trabajo son divididos en partes más pequeñas, llamadas “actividades del cronograma”, con la ayuda del diccionario de la EDT y los atributos de las actividades9. Diccionario de la EDT Es un documento generado por el proceso de crear EDT y respalda a la EDT (Figura 3.12, pág. 112). Provee una descripción del trabajo que debe ser realizado en cada paquete de trabajo de la EDT y ayuda a que los resultados del trabajo concuerden mejor con lo necesitado. EJERCICIO 3.7 Enuncie los beneficios de utilizar la estructura de división del trabajo. _______________________________________________________________ _______________________________________________________________ 3.2.4 Proceso: verificar el alcance Este proceso (Figura 3.13) es el primero de los pertenecientes al grupo de procesos de seguimiento y control, y persigue obtener la aceptación formal del alcance del proyecto por parte de los interesados en él. Así como se planteó al inicio de este capítulo que existe un alcance del pro- ducto, que se corresponde con la materialización de las características y fun- ciones propias del producto, y un alcance del proyecto, que se correspon- de con la generación gradual de esas características y funciones, llegado el momento de verificar, se deberán revisar ambos alcances a través de ins- pecciones. La verificación del alcance del proyecto se mide en comparación con: • el plan de gestión del proyecto, y • la línea base del alcance, formada por el enunciado del alcance del pro- yecto, su estructura de división del trabajo (EDT) y el diccionario de la EDT. Pero la verificación del alcance del producto se mide en comparación con los requisitos del producto. Como todo proceso, tendrá sus entradas, herramientas y técnicas y sus salidas. Las principales salidas de este proceso son la aceptación formal de los entregables del proyecto y los cambios requeridos. 3.2.5 Proceso: controlar el alcance Este proceso pertenece al grupo de procesos de seguimiento y control, y se focaliza en influir en los factores que crean cambios en el alcance para asegurar que estos sean acordados, determinar cuándo se ha produ- cido uno en el alcance y administrar los cambios reales cuando ocurren (Figura 3.14, pág. 114). Como todo proceso, tendrá sus entradas, herramientas y técnicas y sus salidas. Estos procesos de control aparecerán cerrando todos los procedimientos de cada área del conocimiento. Todos se integran en el proceso de control integrado de cambios10, como se muestra en la Figura 3.15. 10 Este proceso, control integrado de cambios, es un proceso de la gestión de la integración y tiene por objetivo gestionar los cambios en los entregables del proyecto y todos los cambios que se generen a través del ciclo de vida del proyecto. Esto es así porque el seguimiento es la verdad fundamental. Siempre habrá variaciones entre los planes y los hechos. La pregunta crucial del seguimien- to es: ¿las variaciones que se producen son aceptables? Para contestar esta pregunta primero hay que definir lo que se considera variación aceptable. Estas variaciones se pueden cubrir mediante reservas de tiempo, de recursos y/o de dinero. Lo importante de estos sistemas de control es que proporcionen informa- ción detallada y completa a tiempo, que no representen un incremento excesivo de trabajo y que sean aceptados por el equipo de proyecto y la alta dirección. Se requiere que proporcionen avisos con antelación para poder reaccionar y que sean fácilmente comprensibles para todos los que necesitan usarlos. 3.3 CONCLUSIÓN En este capítulo hemos presentado, siguiendo la PMBOK® Guide, los cinco procesos que forman parte del área del conocimiento de gestión del alcance del Project Management Institute, marcando los tips fundamentales para el examen. Analícelos, piénselos. Recuerde adicionalmente que el alcance fija los límites del proyecto, y que a través de la estructura de división del trabajo (EDT) se afirma que lo que no está en ella no forma parte del proyecto. Esta EDT, piedra fundamental de la fundación del proyecto, puede llegar a sufrir cambios a lo largo de los procesos de planificación. Nunca pierda de vista que está planificando, por lo que su paso a través de los diferentes procesos es dinámico e iterativo, y esta área del conocimiento no es la excepción. Gestión del tiempo Conceptos clave Luego de haber estudiado este capítulo usted dominará los siguientes con- ceptos fundamentales de la gestión del tiempo del proyecto, a efectos de avanzar en su preparación para la certificación de PMP®. ■ Plan de gestión del cronograma (parte del plan de gestión del tiempo). ■ Procesos de la gestión del tiempo. ■ Lista de actividades. ■ Diagrama de red. ■ Método de diagramación por precedencias (PDM). ■ Método de diagramación con flechas (ADM). ■ Relaciones de precedencias (F-I, I-I, F-F, I-F). ■ Tipos de dependencias (mandatoria, discrecional y externa). ■ Adelantos y retrasos (Leads & Lags). ■ Estimaciones por tres valores. ■ Estimación de duración de las actividades (por analogía, paramétrica). ■ Modelo de cronograma. ■ Holgura o flotamiento (libre, total, del proyecto). ■ Método del camino crítico. ■ Nivelación de recursos. ■ Método de la cadena crítica. ■ Compresión del cronograma (intensificación, ejecución rápida). ■ Línea base del cronograma. ■ Análisis Monte Carlo. ■ Regla del 50/50. ■ Cambios solicitados. ■ Informe del avance del cronograma. Resumen ejecutivo El plan de gestión de proyecto contiene el plan de gestión del cronograma, que proporciona orientación sobre el desarrollo y la planificación de las acti- vidades1 del cronograma y del plan de gestión del alcance del proyecto. Al iniciar los estudios del proyecto, usted deberá desarrollar un plan de ges- tión de proyecto2. Este documento será la primera fuente importante de información sobre cómo guiar el proyecto a través de las etapas de planifica- ción, ejecución, seguimiento y control y cierre. Un plan subsidiario de este es el plan de gestión del cronograma. Con este plan se debe responder a preguntas clave: ¿cómo vamos a definir las acti- vidades del proyecto?, ¿cómo estimaremos su duración?, ¿cómo organiza- remos su secuencia?, ¿cómo desarrollaremos el cronograma del proyecto? y ¿cómo vamos a controlarlo? En este capítulo se presentarán, siguiendo la PMBOK® Guide, los seis pro- cesos que forman parte del área del conocimiento de gestión del tiempo del Project Management Institute, y se brindarán los consejos fundamentales para el examen PMP®. Objetivos del capítulo El objetivo de este capítulo es que usted domine los conceptos de la gestión del tiempo lo suficiente para obtener la certificación PMP®. Para ello, anali- zaremos los procesos de esta área de conocimiento según las definiciones de la PMBOK® Guide (4a Ed.) y profundizaremos en las herramientas más relevantes, como, por ejemplo, el camino crítico o las técnicas de estimación de la duración de las actividades, ya que las encontrará en una gran parte de las preguntas del examen sobre la gestión del tiempo. 1 Se refiere a cada actividad del cronograma: un componente del trabajo planificado diferenciado realizado en el transcurso de un proyecto. Por lo general, una actividad del cronograma tiene una duración estimada, un coste estimado y determinadas necesidades de recursos. Las actividades del cronograma se conectan con otras actividades del cronograma o hitos del cronograma mediante relaciones lógicas, y se descomponen a partir de los paquetes de trabajo (PMBOK® Guide). 2 Este plan de gestión de proyecto comienza a definirse en la gestión de la integración explicitado en el capítulo 2: documentar las acciones necesarias para trabajar en los planes subsidiarios en un plan de gestión. 4.1 INTRODUCCIÓN La gestión del tiempo del proyecto incluye los procesos necesarios para lograr su conclusión a tiempo. Estos procesos son seis. Cinco de ellos se ejecutan antes del lanzamiento del proyecto, ya que están dentro del grupo de procesos de planificación. La ejecución de estos culmina con el desarrollo del cronograma, el cual se aprueba y se convierte en la línea base del cronograma del proyecto. El sexto proceso, control del cronograma, se desarrolla todo a lo largo de la ejecución del proyecto, y consiste en controlar desviaciones respecto de aque- lla línea base del cronograma. Este proceso pertenece al grupo de procesos de seguimiento y control del proyecto. 4.2 GESTIÓN DEL TIEMPO La gestión del tiempo del proyecto incluye los procesos necesarios para lograr su conclusión a tiempo. Si bien la PMBOK® Guide enuncia seis pro- cesos, como se explicita en la Figura 4.1, de la página 126, a efectos de lo- grar una buena planificación de su proyecto no debe olvidar que el plan de gestión de proyecto contiene como plan subsidiario un plan de gestión de tiempos (no es un proceso explícito en esta área del conocimiento). Los cinco primeros pertenecen al grupo de procesos de planificación, mientras que el sexto pertenece al grupo de procesos de seguimiento y control. 4.2.1 Proceso: definir las actividades Este proceso, dentro del grupo de procesos de planificación, persigue identi- ficar y documentar el trabajo que se pretende hacer. Esto quedará plasmado en un listado de todas las actividades del proyecto (Figura 4.2). Como todo proceso, tiene sus entradas, herramientas y técnicas y sus salidas. Este proceso toma como entrada los paquetes de trabajo que forman el nivel más bajo de la EDT (estructura de desglose del trabajo) y los desmenuza o subdivide en componentes menores, hasta alcanzar el nivel de actividades que deben tener un grado de detalle apropiado para poder estimar su dura- ción y programarlas adecuadamente, así como también monitorear y contro- lar los trabajos del proyecto. Es posible que en una primera etapa no sea posible subdividir paquetes de trabajo en actividades, por falta de definición de detalles. En ese caso, se pue- de dejar para más adelante la subdivisión detallada, poniendo en claro que se analizará con suficiente detalle posteriormente. A este proceso se le llama planificación gradual. Cuando en alguna rama de la EDT no hay información suficiente sobre el alcance, solo se podrá planificar en “alto nivel”. En esta rama no se podrá continuar descomponiendo hasta llegar al nivel de paquete de trabajo. El último componente de esa rama de la EDT se define como componente de planificación. Los componentes de planificación para los cuales no hay suficiente infor- mación disponible caen en dos categorías. Si se traza una línea horizontal a cierto nivel de la EDT, habrá componentes de planificación que quedarán por encima y otros que quedarán por debajo de esta. Esto define las dos catego- rías desde la perspectiva de la dirección del proyecto: • Cuentas de control. Están por encima de la línea indicada y se definen como puntos de control de gestión seleccionados de la EDT. Estos pun- tos están por encima del nivel de paquete de trabajo. Todo el trabajo y el esfuerzo realizado dentro de una cuenta de control se documenta en un plan de la cuenta de control. • Paquete de planificación. Son los componentes de la EDT ubicados por debajo de la línea imaginaria, es decir, por debajo de las cuentas de control, pero están por encima de los paquetes de trabajo. Se utilizan para planificar el contenido del trabajo conocido que no tiene todavía activida- des del cronograma detalladas, pero puede tener un presupuesto y una descripción del trabajo. Eventualmente se descompondrán hasta el nivel de paquetes de trabajo. Recuerde Una vez terminado el proceso de definición de actividades, tendremos una lista de actividades con sus atributos y un listado de hitos. Usualmente, la definición de actividades resultará en una mejor comprensión del alcance del proyecto y puede obligar a solicitar cambios en la EDT, por lo que además de las listas de actividades e hitos puede haber, como resultado de la definición de actividades, solicitudes de cambios. Esto forma parte de la lógica iterativa de la planificación, por lo que a medida que se analiza el proyecto se va comprendiendo mejor, lo que ocasiona cambios a lo que ya se planificó en forma preliminar. 4.2.2 Proceso: establecer la secuencia de las actividades Este proceso identifica y documenta las dependencias entre las actividades del cronograma. Es uno más dentro de los procesos de planificación, y establece la secuencia apropiada de ejecución de las actividades para poder ordenar y organizar el trabajo de todo el proyecto (Figura 4.3). Como todo proceso, tiene sus entradas, herramientas y técnicas y sus salidas. Es obvio que la lista de actividades es el insumo principal de este proceso, ya que se trata de ordenarlas en la secuencia de trabajos. Los atributos de la actividad son parte de su definición, y por ello también son insumos principa- les. Nótese que los atributos indican el nivel de calidad o aceptación de los trabajos, de lo que dependerá si hay inspecciones intermedias o dependen- cias entre distintas actividades por utilización de recursos comunes, como equipamiento de ensayos, por ejemplo. Las herramientas y técnicas de este proceso son tema de muchas preguntas en el examen, por ello se darán algunas bases para su representación y es- tablecimiento de la secuencia. Tenemos dos actividades, como las representadas por los rectángulos A y B. Si A se debe realizar antes que B, se dirá: • La actividad A es predecesora de la actividad B, es decir, la actividad A se ejecuta antes que la actividad B. • La actividad B es sucesora de la actividad A, es decir, la actividad B se ejecuta después que la actividad A. La flecha, en este caso, indica que luego de A se ejecutará B. Con respecto a las dependencias, son cuatro los modos que se pueden utili- zar en el establecimiento de la secuencia de las actividades. • Final a inicio (F-I). El inicio de la actividad sucesora depende de la finali- zación de la actividad predecesora. Esto significa que la actividad sucesora no puede empezar hasta que la actividad predecesora haya terminado. Por ejemplo, una vez terminada la actividad “construir la pared”, se puede iniciar la actividad “pintar la pared”. Esta es la dependencia más común de todas. • Final a final (F-F). La finalización de la actividad sucesora depende de la finalización de la actividad predecesora. En otros términos: la actividad predecesora debe terminar para que pueda terminar la actividad suceso- ra. Por ejemplo, se debe terminar con los ensayos para poder terminar con la documentación asociada. • Inicio a inicio (I-I). El inicio de la actividad sucesora depende del inicio de la actividad predecesora. Es decir, la actividad predecesora debe em- pezar para que pueda iniciar la actividad sucesora. Por ejemplo, se debe empezar a cavar un extremo de la zanja de 5 km para recién empezar a instalar el cable que irá en ella. • Inicio a fin (I-F). La finalización de la actividad sucesora depende del inicio de la actividad predecesora. Este tipo de dependencia no es muy utilizado. Para una relación de precedencia final a inicio entre A y B, la actividad B debe empezar luego que la actividad A haya finalizado. Pero ¿cuánto tiempo des- pués? Podría también empezar algún tiempo determinado antes del final de A. Esto nos lleva al concepto de adelantos y retrasos, que son unidades de tiempo que se incorporan a la información del tipo de dependencia para el análisis de red. Por ejemplo, una dependencia “F-I + 4” significará que la segunda actividad debe empezar cuatro unidades de tiempo luego que la primera haya finalizado. En este caso se habla de un retraso. Si la relación fue- ra “F-I - 4”, la segunda actividad debería empezar cuatro unidades de tiempo antes del final de la primera, y estaríamos hablando de un adelanto Analicemos los principales métodos de secuenciamiento. 1. Método de diagramación por precedencia (PDM) Cuanto más simple sea la red de actividades, mejor, más in- tuitivo y más fácil será realizar el seguimiento del proyecto. El PDM3 es un método para crear un diagrama de red del cronograma del proyecto que utiliza casillas o rectángulos, denominados nodos, para representar actividades que se conectan con flechas que muestran las dependencias. También se le conoce como actividad en el nodo (AON)4, y es el que usa la mayoría de los programas de gestión de proyectos. En la Figura 4.5 se muestra un diagrama de red de un proyecto utilizando el PDM. El PDM acepta los cuatro tipos de dependencias o relaciones de prece- dencia mencionados anteriormente: • Final a inicio • Inicio a inicio • Final a final • Inicio a fin 2. Método de diagramación con flechas (ADM) El ADM5 es un método para crear un diagrama de red del cronograma del proyecto que, a diferencia del PDM, utiliza flechas para representar las actividades que se conectan en nodos para mostrar sus depen- dencias. Pero este método tiene un problema: una actividad puede tener múlti- ples sucesoras, múltiples predecesoras o las dos cosas. En ese caso, se necesitan nodos adicionales para mostrar las dependencias en exceso respecto del número de actividades. Y, consecuentemente, se necesita agregar flechas adicionales (representando actividades inexistentes) llamadas actividades ficticias (o dummy). Las actividades ficticias no son actividades reales, y por lo tanto se les asigna una duración cero al reali- zar el análisis de red. A esta técnica también se la conoce como actividad en la flecha (AOA)6. En la Figura 4.6 se muestra un diagrama de red de un proyecto utilizando el método ADM. Las relaciones de precedencia vistas anteriormente son asignadas por el equipo de dirección del proyecto, y se basan en los siguientes tres tipos de dependencias: • Dependencias obligatorias. Son aquellas inherentes a la naturaleza del trabajo que se está realizando; en general se refieren a limitaciones físi- cas. Un ejemplo de una dependencia obligatoria es el caso del desarro- llo de un programa informático entre las actividades de elaboración del programa y de ensayo del programa. Es necesario que el programa esté finalizado para poder ensayarlo. A las dependencias obligatorias se les llama también como “de lógica dura”. • Dependencias discrecionales. Son aquellas que se establecen a cri- terio del equipo de proyecto, el cual se basa en experiencias anteriores, pero no son necesariamente obligatorias. Supongamos que dos activi- dades se pueden hacer simultáneamente (en paralelo) o una a conti- nuación de la otra (en serie), y es el equipo de proyecto, basado en su experiencia, quien decide uno de los dos caminos. La asignación de una relación de precedencia final a inicio para el ejemplo anterior muestra una dependencia discrecional (ya que se podría haber elegido inicio a inicio). Las dependencias discrecionales deben quedar perfectamente do- cumentadas, ya que pueden limitar opciones posteriores de progra- mación. Se las conoce también como lógica preferida, lógica preferencial o lógica blanda, y generalmente se establecen sobre la base del conocimiento de las mejores prácticas dentro de un área de aplicación determinada o algún aspecto poco común del proyecto, donde se desea una secuencia específica, aunque existan otras secuencias aceptables. • Dependencias externas. Son aquellas que implican una relación en- tre las actividades del proyecto y las actividades que no pertenecen al proyecto. Tomemos como ejemplo un proyecto de investigación que requiere hacer una encuesta entre los alumnos de las escuelas. Por ello esa actividad debe hacerse durante el periodo escolar, que es cuando los alumnos asis- ten a las clases. La programación de esa actividad durante el periodo escolar implica una dependencia externa, ya que está vinculada a una decisión externa al proyecto, como es la definición del periodo escolar. El equipo de dirección del proyecto es el que identifica las dependencias externas durante el proceso de establecimiento de la secuencia de las actividades. 4.2.3 Proceso: estimar los recursos de las actividades Este proceso estima el tipo y las cantidades de recursos necesarios para realizar cada actividad del cronograma (Figura 4.7). Este proceso es el tercero del grupo de planificación de esta área del cono- cimiento, y trata de determinar cuáles son los recursos (personas, equipos o materiales) y qué cantidad de cada recurso se utilizará, y cuándo estará disponible cada recurso para realizar las actividades del proyecto. Como todo proceso, tiene sus entradas, herramientas y técnicas y sus salidas. Hay proyectos que requieren recursos humanos tan especializados que su disponibilidad7 es información clave para este proceso. De igual manera, hay proyectos que requieren máquinas de las que hay pocas en el mundo (per- foradoras de túneles de gran diámetro o barcos para el transporte de piezas muy voluminosas, por ejemplo), y es necesario conocer su disponibilidad en el tiempo para poder planificar. A efectos de estimar los recursos, es fundamental realizar un análisis de alternativas. Este análisis consiste en comparar diversos modos de ejecutar las tareas: manual o automáticamente, muchos junior o pocos senior, con un método o con otro, etc. En este análisis ya se introduce el concepto de los costos asociados a cada alternativa, como también la duración de cada opción, como se verá más adelante. Muchas actividades del cronograma se pueden ejecutar con métodos alter- nativos y también pueden ser hechas con recursos propios o ajenos. El software de gestión de proyectos asiste en la planificación, organiza- ción y gestión de los recursos, así como para su estimación. Calendarios de recursos, así también como tarifas, pueden ser administrados a través de un software. Otra herramienta utilizada para estimar recursos es la estimación ascen- dente. Esta consiste en descomponer el trabajo asociado en una actividad en tareas más simples, con el objeto de calcular las necesidades de recursos de cada una de estas partes inferiores y más detalladas del trabajo. Este método es muy preciso y provee gran confiabilidad a la estimación. La principal salida del proceso de estimación de recursos de las actividades son los requisitos de recursos de las actividades, que consisten en la identificación y descripción de los tipos y las cantidades de recursos necesa- rios para cada actividad del cronograma de un paquete de trabajo. De igual manera que para la técnica de estimación ascendente, estos re- quisitos pueden sumarse para determinar los recursos estimados para cada paquete de trabajo, cuenta de control, etcétera. 4.2.4 Proceso: estimar la duración de las actividades Este proceso es el cuarto de los pertenecientes al grupo de procesos de pla- nificación, y su objeto es estimar la cantidad de periodos laborables que se- rán necesarios para completar cada actividad del cronograma (Figura 4.8). Como todo proceso, tiene sus entradas, herramientas y técnicas y sus salidas. Este proceso es clave en la gestión del tiempo, ya que con sus resultados se elaborará el cronograma del proyecto, que una vez aprobado pasará a ser la línea base sobre la que se controlará su avance. Las estimaciones de la duración de las actividades deben ser hechas, en tan- to y en cuanto sea posible, por quienes estén más familiarizados con las ac- tividades en cuestión. La planificación de un proyecto es un proceso iterativo en el que, a medida que se progresa en el análisis, se van obteniendo nuevos datos que permiten ajustar las estimaciones preliminares. La estimación de la duración de las actividades comienza con los datos disponibles, y se afina a medida que mejora la calidad de los datos de entrada. En muchos casos, se debe planificar actividades sin tener un proyecto de ingeniería de detalles. Sin duda, una vez que se disponga de la ingeniería de detalles, la duración de las tareas de ejecución podrá ajustarse con mayor precisión. La secuencia de la estimación comprende tres pasos: 1. Estimar la cantidad de trabajo necesario para ejecutar la actividad. 2. Estimar la cantidad de recursos necesarios para ejecutar la actividad. 3. Estimar la cantidad de periodos laborables necesarios para ejecutar la actividad. Todas las estimaciones obtenidas de este proceso se compondrán en el si- guiente proceso, desarrollo del cronograma, para obtener la duración total del proyecto en función del diagrama de red del cronograma. En el enunciado del alcance del proyecto, como se planteó anteriormente en el capítulo 3, deben estar plasmadas todas las restricciones y asunciones relativas al proyecto bajo análisis. Ellas tienen influencia en la estimación de la duración de las actividades del proyecto. Ejemplos Asunción: se asume que lloverá 100 días en el año del proyecto. Por lo tanto la duración de los trabajos que se ven perjudicados por la lluvia estará afectada por ese número asumido. Restricción: las restricciones son imposiciones externas al proyecto. Si la fase de aprobación del proyecto implica superar una audiencia de impacto ambiental, cuya fecha la fija un organismo independiente de la propia organización, la fecha de aprobación será dependiente de esa res- tricción, y, por lo tanto, la duración de la actividad de aprobación estará sujeta a ella. Entre las herramientas y técnicas de que dispone el PM para estimar la dura- ción de las actividades, se pueden nombrar: 1. Juicio de expertos Es de las mejores herramientas de que dispone el gerente de proyecto, y en el examen surgirá como alternativa de elección en muchas oportu- nidades. En general, el juicio de expertos dará una respuesta correcta a situaciones que no pueden ser resueltas por ninguno de los demás parti- cipantes del proyecto. Tengámoslo en cuenta. 2. Estimación por analogía Sencillamente se trata de tomar la duración real de alguna actividad de un cronograma de referencia, y que sea similar a la actividad bajo análisis, como base para la estimación de la duración de esta. Esta técnica es muy útil cuando hay poca información para hacer un aná- lisis detallado, como ocurre en los inicios de los proyectos. La precisión de la estimación hecha con esta técnica dependerá principalmente del grado de similitud de la actividad tomada como referencia con la actual. 3. Estimación paramétrica Esta estimación consiste en tomar una duración como unidad de medida conocida y multiplicarla por la cantidad de esa medida que le correspon- de a la actividad actual. Para obtener una duración con esta técnica se puede, por ejemplo, multiplicar la cantidad de trabajo a realizar por la productividad (tiempo necesario para hacer cada unidad). En la industria metalmecánica, una productividad típica es la de kilogra- mos producidos por cada hora hombre de trabajo. Entonces, para una pieza de diseño similar a las que tuvieron determinada productividad, las horas hombre de trabajo necesarias se obtienen multiplicando esa pro- ductividad por el peso de la nueva pieza. Luego, el tiempo necesario para finalizar la actividad se conocerá dividiendo el número de horas obtenido entre la cantidad de personal a afectar y la cantidad de horas por día de trabajo, y se obtendrá la duración en días de trabajo (no calendario). 4. Estimaciones por tres valores La estimación más simple es la de un solo valor. Pero en proyectos hay conductas que se repiten y pueden llevar a error. Por ejemplo, un estima- dor junior a menudo va a hacer una estimación demasiado optimista, y un experto muy experimentado podría hacerla demasiado pesimista. En el primer caso se deberá a la inexperiencia y en el segundo al hecho de haber sufrido muchos problemas en el pasado con actividades similares, y entonces se considera necesario guardar reservas de tiempo. Si se tomara la estimación del primer caso, no se podría cumplir con el cro- nograma del proyecto. Si se tomara la estimación del segundo caso, debido a la ley de Parkinson8, el proyecto tomaría más tiempo que el necesario. Para evitar estos problemas, se usa la estimación por tres valores, que tiene mejor precisión que la estimación única, ya que considera los ries- gos asociados a la actividad. El proceso consiste en estimar tres valores de duración según se indica a continuación. Ley de Parkinson: “El trabajo se expande hasta llenar el tiempo disponible para que se termine” • Optimista: es el tiempo que se emplearía en efectuar la actividad asu- miendo que se dieran las condiciones más favorables para ello. Para que la actividad se cumpla en este tiempo, no debe haber falta de re- cursos ni humanos ni materiales, ni problemas climáticos; el proceso de trabajo estará optimizado y se desarrollará sin fallas ni demoras. • Más probable: es el tiempo que se emplearía en efectuar la activi- dad en las condiciones normales esperables de trabajo, considerando los recursos que probablemente serán asignados, la productividad de estos y asumiendo una disponibilidad razonable de ellos para el pro- yecto en relación con otros proyectos de la organización que pudieran requerirlos. Es el tiempo que, según los datos disponibles al momento, tomaría ejecutar la actividad analizada sin otros imprevistos. • Pesimista: es el tiempo que se emplearía en efectuar la actividad bajo el peor escenario posible, es decir, asumiendo que se dan condiciones desfavorables para la ejecución. Por ejemplo, en el caso de estimar la duración de un viaje urbano en auto para llegar a una cita, calcular el tiempo (pesimista) considerando que durante el viaje se den una se- rie de hechos desfavorables, tales como tránsito mayor que el normal, accidente en la autopista con desvío, barreras de un cruce ferroviario bajas, manifestación en el centro con corte de calle, dificultades para estacionar el vehículo al llegar, al entrar al edificio notar que se olvidó la identificación y debe apelar a un conocido que baje a buscarlo, etc. Siempre tenga en cuenta la ley de Murphy9. Finalmente, se hace un promedio aritmético de las tres estimaciones y se toma como estimación de la duración de la actividad. Este promedio, en general, provee una estimación de la duración de la actividad más precisa que la estimación de valor único. 5. Análisis de reserva Luego de estimar la duración de las actividades mediante cualquiera de las técnicas explicitadas anteriormente, el equipo de proyecto puede agre- gar tiempo adicional para contingencias, reservas de tiempo o colchón al cronograma del proyecto, a fin de reconocer que hay un riesgo en el cro- nograma planteado. Estas reservas se pueden estimar como un porcen- taje de la duración estimada de la actividad, o como una cantidad fija de periodos laborables, o bien pueden obtenerse a través del análisis cuan- titativo de riesgos que será desarrollado en el capítulo correspondiente a la gestión de riesgos. 4.2.5 Proceso: desarrollar el cronograma 10 Este proceso, el quinto y último del grupo de procesos de planificación de esta área del conocimiento, analiza las secuencias de las actividades, su duración, los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto (Figura 4.9). Como todo proceso, tiene sus entradas, herramientas y técnicas y sus salidas. 10 Programación de las actividades El desarrollo del cronograma del proyecto determina las fechas de inicio y finalización planificadas para las actividades del proyecto. Se trata de un proceso iterativo, ya que se deben revisar y corregir las esti- maciones de duración y las de los recursos para generar un cronograma del proyecto aprobado, que se convertirá en la línea base con respecto a la que se medirán avances y desviaciones. En el enunciado del alcance del proyecto, como se analizó anteriormente, deben estar plasmadas todas las restricciones y asunciones relativas al pro- yecto bajo análisis. Ellas tienen su influencia en el desarrollo del cronograma que nos convoca en este punto. Dos tipos de restricciones de tiempo son las que influyen durante el desarro- llo del cronograma: • Restricciones del tipo “no comenzar antes del...” o “no finalizar después del...” representan el primer grupo que influye en el desarrollo del crono- grama. Estas son las más comunes de las disponibles en los softwares de gestión. Normalmente corresponden a dependencias externas, es de- cir, hechos externos al proyecto que deben ocurrir para poder dar inicio a ciertas actividades (que deje de llover, por ejemplo); o inversamente, actividades internas que se deben ejecutar antes de un evento externo (el comienzo de clases, si se trata de reparar un establecimiento escolar). Restricciones como fechas de contratos externos o disposiciones guber- namentales también entran en este tipo. • En otros casos, el cliente o el patrocinador del proyecto pueden estable- cer como eventos clave o hitos principales la finalización de ciertos pro- ductos entregables en una fecha determinada. Durante el desarrollo del cronograma, esas fechas tienen una importancia superior, toda vez que solo pueden ser modificadas por medio de cambios aprobados. Los hitos a veces indican interfaces con trabajos externos al proyecto. Entre las herramientas y técnicas disponibles para llevar adelante este pro- ceso se pueden enunciar las siguientes: 1. Análisis de la red del cronograma Con esta técnica se generará el cronograma del proyecto. Además del modelo de cronograma que se seleccione, se utilizará una o varias de las técnicas analíticas que se menciona a continuación: • Método del camino crítico. • Método de cadena crítica. • Análisis “¿qué pasa si...?”. • Nivelación de recursos. Con estas técnicas se calculan fechas de inicio y finalización, tempranas y tardías (obsérvese que son cuatro fechas por cada actividad). Si el diagrama de la red del cronograma utilizado en el modelo tiene algún bucle de red o extremo abierto de la red, estos se deben corregir antes de aplicar alguna de las técnicas analíticas. Es posible que algunos caminos de red contengan puntos de convergen- cia o divergencia que pueden identificarse y utilizarse posteriormente en el análisis de compresión del cronograma. 2. Método del camino crítico El método del camino crítico (MCC, CPM en inglés) es un algoritmo mate- mático muy sencillo utilizado para programar un conjunto de actividades de un proyecto. Es la técnica más importante para la dirección eficiente de proyectos. El requerimiento necesario para usar el MCC es haber elaborado un mo- delo del cronograma del proyecto que contenga: • Todas las actividades. • La estimación de la duración de todas las actividades. • Las dependencias entre ellas. Utilizando estos valores, el MCC calcula el camino más largo de todas las alternativas posibles para ejecutar todas las actividades y llegar al final del proyecto. También calcula la fecha más temprana y más tardía en las que cada actividad puede empezar y terminar sin extender la duración del proyecto. En esta etapa no se tienen en consideración limitaciones de recursos. Esto se hace en dos “recorridos”: en uno de ellos se empieza desde el inicio del proyecto y se obtienen las fechas tempranas de inicio y finalización de cada actividad; en el otro, se empieza desde el final del proyecto, y, restando de esa fecha la duración de las actividades, se ob- tienen las fechas de finalización e inicio tardías. Este proceso determina cuáles actividades son “críticas” (es decir, que- dan en el camino más largo) y cuáles de ellas tienen “holgura”11, es decir, pueden ser retrasadas sin que ello extienda la duración del proyecto. Las fechas tempranas y tardías de las actividades “no críticas” significan que pueden programarse dentro del periodo que va desde el inicio tem- prano y el final tardío, es decir, dentro de su holgura total. La holgura total se define como la cantidad de tiempo que una actividad puede de- morarse respecto de su fecha de inicio temprana, sin retrasar la fecha de finalización del proyecto ni violar ninguna restricción del cronograma. Se distingue de la holgura libre en que esta es la cantidad total de tiempo que una actividad puede retrasarse respecto de su fecha de inicio tempra- na sin demorar el inicio temprano de ninguna de las actividades inmedia- tamente siguientes. Ante cualquier extensión o demora de una actividad en el camino crítico, tendremos un impacto en la duración del proyecto total, es decir, se retra- sará la fecha de finalización del proyecto. Las actividades que están en el camino crítico no tienen holgura. Como ejercicio de todo lo indicado hasta ahora, vamos a determinar el camino crítico de un proyecto de 10 actividades comentando to- dos los pasos detalladamente. El proyecto es el que se muestra en la Figura 4.10. 11 En Argentina y varios países de Latinoamérica, es más común hablar de flotamiento en lugar de holgura. Para este trabajo se usará la palabra “holgura”, ya que es la que adopta la versión en español de la PMBOK® Guide Construiremos un diagrama de red utilizando el método de diagramación por precedencias (PDM). En él, los nodos corresponden a las actividades y las uniones a las interrelaciones lógicas entre sí. Los nodos de actividad se representan en la Figura 4.11. Tanto el método de diagramación por precedencia como esta figura son propios (estándar) del método del camino crítico. La diferencia entre los tiempos de finalización y de inicio, tanto tempranos como tardíos, representa la duración de la actividad. La diferencia entre los tiempos tardíos y tempranos, tanto de inicio como de finalización, representa la holgura total. El diagrama de red del proyecto correspondiente al cronograma del proyec- to se muestra en la Figura 4.12. El primer paso es encontrar los tiempos de inicio y finalización tempranos haciendo el “recorrido hacia adelante” o forward pass. Se empieza por la primera actividad de la red, la que se designa como inicio, y se le asigna el instante cero como tiempo de inicio. Luego se calcula el tiempo de finalización más temprano de la primera actividad sumando a su fecha de inicio la duración de esta, siguiendo con las actividades sucesoras. Si la relación de dependencia de una actividad con su sucesora es final a inicio, el momento de inicio más temprano de una actividad sucesora es igual al momento de finalización más temprano de la actividad predecesora. Veamos algunos detalles particulares en el ejemplo: • La relación de precedencia entre A1 y A2 dice que A2 no va a empezar sino 3 días antes que termine A1. Por ello, si el momento de finalización más temprano de A1 es 10, el tiempo de inicio más temprano de A2 es 7. • La relación de precedencia entre A6 y A8 dice que A8 no empieza sino después de haber transcurrido 10 días desde el inicio de A6. Entonces, si la fecha de inicio más temprana de A6 es 46, la fecha de inicio más tem- prana de A8 será 56. Si la actividad tiene una sola predecesora, el cálculo es muy sencillo. Cuando una actividad tiene varias predecesoras (y todas con una relación de prece- dencia final a inicio), esta no va a poder empezar hasta que haya terminado la última de todas. En nuestro caso, esto puede verse con la actividad A7, que tiene como predecesoras a A5 y a A6. El momento de inicio más tem- prano de A7 es el mayor de los tiempos de finalización más tempranos de las actividades predecesoras (A5 y A6), es decir, el día 66. El resultado del recorrido hacia adelante, es decir, de recorrer la red de izquierda a derecha, se muestra en la Figura 4.13. El segundo paso es determinar los momentos de inicio y finalización más tardíos. Esto se hace por medio del “recorrido hacia atrás” o backward pass, que consiste en recorrer la red en el sentido opuesto, es decir, comenzando por el final. Se comienza con la última actividad de la red. El proyecto tiene un solo plazo de ejecución; entonces, para esta actividad, la última, la fecha de finalización más tardía coincide con la fecha de finalización más temprana. Por lo tanto, el tiempo de finalización más tardío para la actividad A10 es 103. Luego, el momento de iniciación más tardío será el tiempo de finalización más tardío menos 15 días, que es la duración de A10, es decir, 88. Al analizar las actividades predecesoras de A10 vemos que el final más tardío de ellas coincide con el inicio más tardío de A10. Por ello, el momento más tardío de finalización para A7 y A9 es 88. Esto es muy sencillo, pero se debe tener cuidado cuando una actividad tiene más de una sucesora, porque en ese caso la fecha más tardía de finalización de una actividad coincidirá con la primera de las fechas más tardías de inicio de las actividades sucesoras. Esto se puede ver con la ac- tividad A6, que tiene como sucesoras a A7, A8 y A9. Veamos el resultado del cálculo para A6 (Figura 4.14). Según la actividad A9, A6 se podría extender hasta el día 78, sin embargo, la fecha más tardía de finalización de la actividad A6 está limitada por la fecha más tardía de inicio de la actividad A7, que es 66. Pero además la relación de precedencia entre A6 y A7 es final a inicio con un adelanto de cinco días, por lo que la fecha más tardía de finalización de la actividad A6 es el día 71 y no el día 66. Veamos los cálculos en detalle: • La relación de precedencia A6-A7 es final a inicio con un adelanto de cinco días. Esto significa que la fecha más tardía de finalización de la ac- tividad A6 es 71 días, ya que si bien el momento de inicio tardío de A7 es 66, A6 tiene cinco días más para completarse una vez iniciada A6. La relación A6-A9 es del tipo final a inicio (sin retraso ni adelanto). Con ello, el final tardío de la actividad A6 podría llegar al día 76. De las dos consideraciones anteriores surgen los posibles tiempos de fi- nalización tardíos de A6, 71 y 76 días. Se ve claramente, entonces, que la limitante es 71, ya que si se tomara 76 como fecha tardía, la actividad A7 co- menzaría cinco días tarde: 76 en lugar de 71. Veamos el resultado del cálculo para A6 (Figura 4.15). El resultado de los cálculos completos de la pasada hacia atrás, recorriendo la red de derecha a izquierda, se puede ver en la Figura 4.16. Si ambas pasadas se hicieron correctamente, entonces el tiempo de inicio temprano de la actividad de partida obtenido en la pasada hacia adelante debe coincidir con el tiempo de inicio tardío de la misma actividad obtenido en la pasada hacia atrás. Ambos deben ser igual a cero. Si no coinciden, hay algún error. Si coinciden, el estudio puede haber sido hecho correctamente o bien tener dos errores que se compensan mutuamente. Cuidado con esto. El tercer paso es determinar las holguras totales. La holgura total se determi- na por la diferencia entre los tiempos tardíos y tempranos tanto de inicio como de finalización. Cada tiempo en gris oscuro de la caja-nodo de actividad menos su vecino superior respectivo en gris claro nos da la holgura (Figura 4.17). Camino crítico Con esto se ha determinado matemáticamente el camino crítico, que está dado por la secuencia de actividades cuya holgura es cero, y que se han identificado en gris oscuro. Estos cálculos son los que hacen los softwares de gestión. Si bien es con- veniente utilizar estos programas, dentro de su proceso de estudio para la certificación PMP®, usted debe hacer un cálculo manual del camino crítico para un proyecto de no muchas actividades, pero con algún grado de com- plejidad en términos de cantidad de caminos en paralelo y tipos distintos de relaciones de precedencia. Además del camino crítico, en función de la complejidad del proyecto, será posible encontrar uno o varios caminos cuasi críticos. Estos son caminos con una duración total ligeramente inferior a la del camino crítico. A estos caminos se les llama subcríticos, y, en general, a todos los que no sean el camino crítico se les llama caminos no críticos. Durante la ejecución de los proyectos, el cronograma real va variando en función de los recursos disponibles y de los rendimientos alcanzados debido a contingencias, etcétera. El MCC nos permite monitorear el cronograma y hacer un seguimiento cercano de las actividades críticas. Además, el gerente de proyecto puede monitorear también actividades no críticas que pueden retrasarse más allá de su holgura total, generando un nuevo camino crítico, lo que posterga la finalización del proyecto. Los caminos críticos tienen una holgura total igual a cero o negativa, y las actividades del cronograma en un camino crítico se denominan “actividades críticas”. La forma que el PERT utiliza para tener en cuenta el azar en la planificación de un proyecto consiste en la determinación de un tiempo esperado (distinto al tiempo más probable, al tiempo optimista, al tiempo pesimista y a su pro- medio), que está dado por la siguiente fórmula: Te = (O + 4M + P) ÷ 6 Donde, •Te: Tiempo esperado •O: Tiempo optimista • M: Tiempo más probable •P: Tiempo pesimista El tiempo esperado es el tiempo que se emplearía en efectuar la actividad en las condiciones normales esperables de trabajo, al igual que se definió para el tiempo más probable, pero asumiendo que es el promedio de las du- raciones reales cuando la tarea se repite un cierto número de veces durante un periodo relativamente largo de tiempo. El tiempo esperado así definido en general resulta algo mayor que el tiempo más probable pero algo menor que el promedio aritmético de los tres definidos anteriormente. A partir de la definición anterior, PERT utiliza dos conceptos más: Va = ((P-O)/6)2 Donde Va es la varianza de una actividad. Esta representa la media arit- mética de las desviaciones de la media elevadas al cuadrado: DS = (P-O)/6 Donde DS es la desviación estándar de una actividad. Esta se define como la raíz cuadrada de la varianza. Estas fórmulas se corresponden con una distribución beta de las proba- bilidades de ocurrencia de las duraciones. Las distribuciones beta son ampliamente usadas para modelar eventos que tienen lugar en un inter- valo que va entre un mínimo y un máximo. En este caso, el evento es la duración, pero se usan para la estimación de costos también. La distribu- ción beta, así como la distribución triangular, se usan extensivamente en el método del camino crítico, en el PERT y en otros sistemas de control de gestión de proyectos para estimar el tiempo de ejecución de una acti- vidad. El ejemplo anterior se obtuvo de las siguientes estimaciones: El camino crítico se determina, para este ejemplo, como se mostró ante- riormente. Ahora bien, todo el proyecto tiene una varianza y una desvia- ción estándar. La varianza del proyecto se determina sumando las varianzas de las acti- vidades participantes en el camino crítico. La desviación estándar del proyecto se determina calculando la raíz cua- drada de la varianza del proyecto calculada sumando las varianzas indivi- duales. Siguiendo con el ejemplo anterior: El rango de la estimación anterior se ha obtenido restando un sigma (desviación estándar) a la duración del camino crítico para obtener la fecha temprana de finalización y adicionando un sigma (desviación es- tándar) a la duración del camino crítico para obtener la fecha tardía de finalización. 3. Compresión del cronograma Por compresión del cronograma se entiende acortar el cronograma del proyecto, pero sin modificar el alcance del proyecto, para cumplir con las fechas impuestas y el resto de los objetivos del cronograma. Las principales técnicas de compresión del cronograma son: • Intensificación (o crashing): se busca acortar la duración de acti- vidades en el camino crítico asignándoles más recursos. Para ello se estudia el balance entre los incrementos de costos por asignar más recursos a las actividades y los beneficios obtenidos en términos de acortamiento de la duración de las actividades. Este método de com- presión del cronograma en general tiene asociados costos adicionales y no siempre representa una alternativa viable. • Ejecución rápida (o fast tracking): se ejecutan simultáneamente o en paralelo actividades que estaban planificadas para hacerse una después de la otra. Por ejemplo: iniciar la fabricación de un equipo simultáneamente con la presentación para aprobación del diseño por parte del cliente (cuando lo apropiado sería iniciar la fabricación una vez obtenida la aprobación del diseño por parte del cliente). Este mé- todo de compresión del cronograma tiene asociado el riesgo de que al modificar una secuencia previamente seleccionada sin esperar a que ocurran las actividades previas a la que se adelanta a veces requiere de retrabajos. Este método de compresión del cronograma aumenta el riesgo. Otra forma de compresión del cronograma consiste en eliminar actividades que queden en el camino crítico modificando el proyecto o diseño para remplazar actividades muy demorosas por otras de igual resultados y que no tomen tanto tiempo. Por ejemplo, si un tipo de pintura requiere de varias aplicaciones para adquirir el espesor adecuado y tiene tiempos de secado muy largos, desde el diseño se puede remplazar el esquema por otro de naturaleza distinta que pueda ser completado en una sola aplicación. 4. Análisis “¿qué pasa si...?” Esta técnica, utilizada en el desarrollo del cronograma, consiste en en- contrar respuestas a la pregunta: “¿qué pasa si se da tal o cual circuns- tancia o escenario?”. Por medio de este ejercicio, el equipo de proyecto puede identificar posi- bles situaciones de riesgo y hacer reservas de mitigación desde la misma concepción del cronograma. Este análisis implica el cálculo de diferentes duraciones de proyecto en función del conjunto de asunciones que se consideren simultáneamente. La técnica más utilizada para esta tarea es el análisis Monte Carlo. Este análisis consiste en definir para cada actividad del cronograma una distribución probabilística de posibles duraciones. Luego, en forma alea- toria, se generan a través de un programa distintas duraciones totales del proyecto. Finalmente, se obtiene una curva de distribución de las posibles duraciones totales del proyecto, que por un análisis estadístico permite determinar el porcentaje de probabilidades que tendremos de completar el proyecto en cada duración obtenida. 5. Nivelación de recursos La técnica de nivelación de recursos12 consiste en el análisis de la red del cronograma de un modelo de cronograma después que ya fue analiza- do por medio del método del camino crítico. El método del camino crítico produce un cronograma preliminar que pue- de requerir más recursos durante ciertos periodos de tiempo de los que hay disponibles, o puede requerir cambios en los niveles de recursos que no son fáciles de gestionar. TIP: cuando se debe acelerar el proyecto, pero no se aprueban variaciones al presupuesto, solo queda la ejecución rápida como alternativa. 12 Llamada también “método basado en los recursos”. Las organizaciones no tienen recursos ilimitados, y las variaciones muy marcadas en la cantidad de personal afectado por un proyecto tienen desventajas de tipo operativo, como el reclutamiento, inducción, capaci- tación, infraestructura (escritorio, PC, ropa, etc.), desvinculación..., que hacen necesario desde el punto de vista práctico atenuar los picos de la curva de recursos por medio de la nivelación de estos. Luego de la aplicación de esta técnica, es posible que se obtenga un ca- mino crítico distinto al original. En este caso, el paso siguiente es sacar recursos de actividades no crí- ticas y reasignarlos a actividades críticas. Con esto a veces se consigue llegar nuevamente a la duración planificada originalmente. Y si no se con- sigue, en general se acerca bastante a ella. 6. Método de cadena crítica El método de cadena crítica, a diferencia del método del camino crítico y el análisis PERT, que se concentran en la secuencia de actividades y una programación rígida, presta más atención a los recursos requeridos para ejecutar las tareas. El método de cadena crítica trata de mantener los re- cursos nivelados, pero se requiere flexibilidad en las fechas de comienzo y rapidez para cambiar de actividades o de cadena de actividades a fin de mantener el proyecto dentro del programa. Actualmente, se considera que con la dirección tradicional de proyectos se desperdicia hasta un 30% del tiempo y de los recursos debido a malas prácticas, como el síndrome del estudiante13, mala priorización, tiempos de espera para iniciar una actividad, etcétera. 13 Se refiere al fenómeno por el cual una persona comenzará a esforzarse por concluir una tarea faltando muy poco para el vencimiento del plazo. Esto conduce a perder cualquier buffer determinado a partir de los estimados de duración de tareas individuales. Fue observado por Eliyahu M. Goldratt (2001) en su libro acerca de la cadena crítica. El síndrome del estudiante es una forma de dilación. El método de cadena crítica (CCPM)14 se usa como alternativa al método del camino crítico. Las principales características del CCPM que lo distin- guen del CPM son: A. El uso (normalmente implícito) de dependencias entre recursos. Por implícito se entiende que no está en el diagrama de red del cronogra- ma, y deben buscarse en los requisitos de los recursos. B. No se busca una solución óptima. Esto significa que una solución me- dianamente buena es aceptable, ya que: 1. Hasta lo que se sabe, no hay un método analítico para encontrar un óptimo absoluto (es decir, el que tiene la cadena crítica más corta). 2. Laincertidumbredelasestimacionesesmuchomayorqueladiferen- cia entre la solución óptima y una solución medianamente buena. C. La identificación e inserción de colchones de duración: • Colchón del proyecto. • Colchón de alimentadores. • Colchón de recursos. D. Monitoreo del progreso del proyecto por medio de la observación del consumo de los colchones en lugar de controlar las actividades indivi- duales respecto del cronograma. Veamos cómo se planifica. El plan del proyecto se arma en forma muy parecida al camino crítico. El plan se elabora desde el final hacia el principio, tomando las fechas de ini- cio más tardías posibles. Se usan dos duraciones: la “mejor estimación”, que es la que tiene 50% de probabilidades de ocurrencia, y la “estimación segura”, que tendrá una duración mayor y, por consiguiente, una probabi- lidad mayor, digamos 90% o 95%. Esto depende del grado de aceptación del riesgo de la organización. Se asignan los recursos a las actividades y se hace la nivelación de recur- sos utilizando las estimaciones del 50% de probabilidades de ocurrencia. Se identifica como la cadena crítica a la secuencia de actividades que sea más larga, es decir, que dé la mayor duración. La razón para usar las es- timaciones de 50% de probabilidad de ocurrencia es que la mitad de las actividades terminarán antes de esa estimación y la mitad después, con lo que la varianza a lo largo del proyecto será cero. Dado que es más factible que las actividades duren más de lo planificado debido a la ley de Parkinson, el síndrome del estudiante u otras razones, se establecen colchones para el monitoreo integral. Estos colchones se fijan entre las fechas (tardías) programadas y las fechas de entrega de los entregables comprometidas. Esto tiene el efecto de adelantar todo el cronograma ya comprimido y reservar colchones al final para absorber retrasos. Finalmente se establece una línea base sobre la cual se controlará finan- cieramente el proyecto. Veamos la ejecución y el control. Los recursos afectados por la cadena crítica se deben concentrar exclusivamente en las actividades críticas y nada más. Se elimina la simultaneidad de actividades. El objetivo aquí es eliminar la tendencia a demorar trabajo o hacer otros trabajos cuando tenemos la sensación de que hay tiempo disponible. Dado que las actividades han sido programadas con duraciones del 50% de probabilidad (es decir, cortas), se establece una presión sobre los re- cursos para completar las actividades en la cadena crítica lo antes posi- ble, eliminando la posibilidad del síndrome del estudiante y de la ley de Parkinson. La gran ventaja del método de la cadena crítica está en su modo de se- guimiento y control. Dado que las actividades fueron programadas con una duración con el 50% de probabilidad de ocurrencia, es decir corta, no tiene sentido presionar para que cada actividad se termine “a tiempo”, ya que las estimaciones nunca son perfectas. En su lugar, se controla el comportamiento del colchón. Se establece un gráfico de “consumo de colchón” en función del progreso del proyecto. Si el ritmo de consumo es pequeño, es decir, si se puede anticipar que sobrará colchón hacia el final del proyecto, está bien. Si el consumo es importante, de modo que se anticipa que al final del proyecto el colchón será muy pequeño o nulo, entonces se deben tomar acciones correctivas o planes de recuperación para revertir la pérdida de tiempos. Si el ritmo de consumo del colchón excede un cierto valor crítico (grosso modo, un ritmo que indique que el colchón se esfumará antes del final del proyecto), entonces se necesita implementar los planes de contingencia preparados. Repasemos La cadena crítica es una técnica de análisis de la red del cronograma que modifica el cronograma del proyecto para tener en cuenta las limitaciones de recursos. • Primero se construye el diagrama de red del cronograma del proyec- to usando estimaciones no conservadoras para las duraciones de las actividades dentro del modelo de cronograma, con las dependencias necesarias y restricciones definidas como entradas. • Luego se calcula el camino crítico. • Después de identificar el camino crítico, se introduce la disponibilidad de recursos y se determina el cronograma limitado por los recursos resultante. • El método de cadena crítica agrega colchones de duración, que son actividades del cronograma no laborables, para mantener el enfoque en las duraciones de las actividades planificadas. 7. Modelo de cronograma Todos los datos e información relativa al cronograma se plasman en el modelo de cronograma para el proyecto. Con los datos del modelo y la ayuda de software de gestión (o en su defecto manualmente) se elabora finalmente el cronograma del proyecto. Entre las principales salidas de este proceso, se pueden mencionar: A. Cronograma del proyecto El cronograma del proyecto es el principal documento del proceso de desarrollo del cronograma dentro del grupo de procesos de planificación. Este cronograma consiste en el listado de todas las actividades del proyecto con la fecha de inicio y la fecha de finalización planificada para cada una de ellas. Hay varias formas de presentar el cronograma, dependiendo del objetivo de la presentación. La más general es el cronograma de hitos o cronograma maestro, que contiene solamente los eventos principales del proyecto, y suele ser utilizado para presentaciones a la alta dirección, donde no se debe abundar en detalles irrelevantes para los fines de la decisión que se debe tomar. Se puede mostrar también como una tabla de actividades y fechas. Los software de gestión permiten con mucha facilidad mostrarlos de alguno de los siguientes modos: • Diagramas de red del cronograma del proyecto. Con información de la fecha de la actividad, generalmente muestran tanto la lógica de la red del proyecto como las actividades del cronograma del camino crítico del proyecto. Estos diagramas pueden presentarse en el for- mato de diagrama de actividad en el nodo, o en el formato de diagra- ma de red del cronograma según escala de tiempo, que a veces se denomina diagrama de barras lógico. • Diagramas de barras. Estos diagramas, en los que unas barras re- presentan las actividades, muestran las fechas de inicio y finalización de las actividades, así como las duraciones esperadas. Los diagramas de barras son relativamente fáciles de leer y se usan frecuentemente en presentaciones de dirección. Para la comunicación de control y de dirección se usa una actividad resumen más amplia y completa, que a veces se denomina actividad hammock, entre hitos o a través de múltiples paquetes de trabajo interdependientes, y se representa en informes de diagramas de barras. • Diagramas de hitos. Estos diagramas son similares a los diagramas de barras, pero solo identifican el inicio o la finalización programada de los productos entregables más importantes y las interfaces exter- nas clave. El cronograma permitirá hacer el seguimiento durante la etapa de eje- cución con información del trabajo que se está llevando a cabo según lo informado hasta el momento o la fecha de los datos cargados o “fecha actual”. El programa MS Project® permite también mostrar estos avances en forma de barras de avance sobre las barras originales del cronograma línea base. El cronograma debe mostrar la fecha de inicio real, la duración real y la fecha de finalización real para las actividades del cronograma que ya han sido terminadas; también la fecha de inicio real, la duración restante y la fecha de finalización actual para las actividades del cronograma que es- tán en ejecución; y la fecha de inicio actual, la duración original y la fecha de finalización actual para aquellas actividades del cronograma en las que el trabajo aún no se ha iniciado. B. Línea base del cronograma Esta es la versión que, una vez aprobada por el equipo de dirección del proyecto, se transforma en el cronograma oficial del proyecto y respecto del cual se medirán todas las desviaciones que se produz- can en la ejecución. El análisis del valor agregado se refiere siempre a la línea base. 4.2.6 Proceso: controlar el cronograma Este proceso, el único de la gestión del tiempo correspondiente al grupo de procesos de seguimiento y control, controla los cambios del cronograma del proyecto (Figura 4.18, pág. 162). Por ello, el control del cronograma es una parte del proceso de control integrado de cambios. Como todo proceso, tiene sus entradas, herramientas y técnicas y sus salidas. El control del cronograma comprende: • Determinar la situación real del cronograma del proyecto. • Influir en los factores que crean cambios en el cronograma. • Determinar si el cronograma del proyecto ha cambiado y de qué modo. • Gestionar los cambios a medida que suceden. Entre las herramientas y técnicas más utilizadas se puede mencionar el informe de avance. Un informe del avance y el estado actual del cronograma debe incluir: • Las fechas de inicio y finalización reales. • Las duraciones restantes para las actividades no completadas. El informe del avance se usa para controlar el cronograma y los costos. En la mayoría de las tareas que tienen un entregable físico (por ejemplo, armar una bicicleta), es sencillo determinar un porcentaje de avance para cuando la actividad está a medio camino. Pero hay otras (ingeniería, programación, etc.) para las que no es sencillo establecer un criterio de medición. Lo usual es que el gerente de proyecto consulte a quien lo ejecuta qué porcentaje de avance lleva; pero esto en ciertas actividades es solo una estimación, y se corre el riesgo de tener criterios dispares y a veces opuestos. Por eso es importante establecer pautas claras respecto de cómo evaluar el progreso de las actividades a media ejecución. Para ello hay tres opciones de uso común: • Regla 50/50: una actividad se considera ejecutada en un 50% cuando ha comenzado, y se le asignará el otro 50% cuando esté finalizada. • Regla 20/80: una actividad se considera ejecutada en un 20% cuando ha comenzado, y se le asignará el otro 80% cuando esté finalizada. • Regla 0/100: la actividad se considerará ejecutada al 100% cuando sea terminada, y se considerará un avance de 0% para todo estado anterior. Algunas veces, aunque sea factible determinar un porcentaje de avance de una actividad, se preferirá usar una de las reglas anteriores debido a su sim- plicidad para evitar la inversión de tiempo en tener que calcular con exactitud un porcentaje de avance cuando esa precisión en la determinación no sea necesaria. 4.3 CONCLUSIÓN La buena gestión del tiempo en un proyecto es una condición indispensable para poder completarlo en el plazo estimado y dentro del presupuesto. Si un proyecto se atrasa, existen varias formas de recuperar el tiempo. La más simple suele ser la intensificación (crashing), cuya implementación im- plica sobrecostos y por lo tanto salirse del presupuesto asignado. La segun- da opción es recortar el alcance del proyecto, en cuyo caso ya no se trata del mismo proyecto original. Por ello, es fundamental que durante el proceso de planificación se siga or- denadamente los pasos indicados aquí, volviendo sobre ellos cada vez que se obtengan más precisiones sobre el alcance, la duración o los recursos necesarios para la ejecución de las tareas. Y por supuesto, una vez obtenida la línea base, debe realizarse un con- trol celoso del cronograma para identificar y corregir desviaciones lo antes posible. Gestión de los costos del proyecto Conceptos clave Luego de haber procesado este capítulo usted dominará los siguientes con- ceptos fundamentales de la gestión de los costos del proyecto, a efectos de avanzar en su preparación para la certificación PMP®. ■ Procesos de gestión de los costos del proyecto. ■ Estimar los costos del proyecto: insumos, herramientas y resultados. ■ Determinar el presupuesto del proyecto: insumos, herramientas y resultados. ■ Controlar los costos del proyecto: insumos, herramientas y resultados. ■ Estimación por analogía, estimación ascendente, estimación paramétrica, estimación con tres datos. ■ Costo de la calidad. ■ Análisis de reserva. ■ Reservas por contingencias, reservas de gestión. ■ Suma o agregación de costos. ■ Conciliación del límite de la financiación. ■ Línea de base de costos del proyecto. ■ Presupuesto de costos del proyecto. ■ Técnica del valor ganado: valor planificado, costo real, valor ganado. ■ Índice de rendimiento del cronograma, índice de rendimiento de costos. ■ Variación en costos, variación en cronograma. ■ Estimación a la conclusión, estimación hasta la conclusión. ■ Costos fijos, costos variables. ■ Costos directos, costos indirectos. ■ Costos evitables, costos inevitables. ■ Costo de oportunidad. ■ Valor actual, valor actual neto. ■ Tasa interna de retorno, relación beneficio-costo, periodo de recuperación de la inversión. ■ Costo del ciclo de vida. ■ Análisis de valor. Resumen ejecutivo Todos los que hemos concretado alguna vez un proyecto o iniciativa, ya sea en el ámbito profesional o personal, sabemos que la adecuada gestión de los costos del proyecto constituye uno de los pilares fundamentales de su éxito, y un aspecto central del proyecto, al cual debemos prestar continua- mente atención. Esto con el fin de asegurar que los recursos disponibles, que siempre son escasos, sean al mismo tiempo suficientes para completar el trabajo comprometido, anticipando y evitando, en la medida de lo posible, variaciones no planeadas que pongan en riesgo el cometido, y gestionando aquellos cambios autorizados cuando sea necesario. Tal es la importancia de una adecuada gestión de costos que, como segu- ramente recordarán, los costos forman parte de la definición más básica del “triángulo de hierro” o restricción triple del proyecto. Por ello, la medición y comparación de los costos planeados y de los cos- tos reales, y la implementación y análisis de la técnica del valor ganado del proyecto, constituyen aspectos principales a tener en cuenta cada vez que deseamos establecer el estado del proyecto, como así también su grado de éxito. Cabe recordar en este punto que la responsabilidad nunca se delega, por lo que “el gerente de proyecto es el responsable de asegurar un presupuesto realista y de su cumplimiento”. 5.1 INTRODUCCIÓN En primer término, la gestión de costos del proyecto “incluye los procesos involucrados en la estimación, presupuestación y control de costos a fin de asegurar que el proyecto pueda ser completado dentro del presupuesto previsto” (PMI®, 2008, p. 165). Teniendo en cuenta que la gestión de los costos implica un conjunto de pro- cesos, analizaremos aquellos conceptos clave que el postulante deberá co- nocer a efectos de responder adecuadamente las preguntas del examen de certificación, sean estas situacionales o conceptuales. Para ello, a continua- ción nos abocaremos a describir y analizar los distintos procesos de gestión de los costos de un proyecto. A veces las preguntas situacionales del examen de certificación hacen re- ferencia a los insumos (inputs) o los resultados (outputs) de un proceso es- pecífico de gestión de costos. Es por esto que el postulante deberá conocer (aunque no necesariamente memorizar) los principales insumos o entradas de cada proceso, las técnicas y herramientas utilizadas en él y los productos o resultados esperados del proceso. Pero antes de ello quisiéramos recordar que: 1. Una adecuada gestión de los costos se basa en la correcta definición de la estructura de desglose del trabajo (EDT). La EDT o WBS (work breakdown structure), desarrollada en el capítulo 3 de gestión del alcance del proyecto, es una herramienta de gran ayuda para estimar, presupues- tar y controlar los costos del proyecto, y es la plataforma en la que nos basaremos para desarrollar la gestión de los costos. 2. En muchas ocasiones, los proyectos fallan porque en su planificación no participan quienes realizan las tareas. Para evitar esto, es importante fo- mentar la participación de aquellas personas que van a realizar las tareas durante la etapa de planificación del proyecto, y más específicamente du- rante el proceso de estimación de costos. 3. Siempre tenemos que contar con un plan de gestión de costos. Sin em- bargo, como veremos en el próximo apartado, al analizar la Figura 5.1, observaremos que los procesos no incluyen explícitamente la elabora- ción de un plan de gestión de costos que evidencie cómo llevar a cabo la gestión de los costos y haga referencia a cuestiones tales como el nivel de detalle de las estimaciones, las herramientas a utilizar en los procesos, los límites aceptables de variación de los costos o los tipos de reportes a utilizar, entre otros muchos aspectos a tener en cuenta. Sin embargo, a efectos de rendir el examen de certificación, el postulante debe suponer que “aunque no lo veamos, el plan siempre está, siempre está...”. No obstante, como gerentes responsables del proyecto, ¡debe- remos asegurarnos de verlo! 5.2 PROCESOS DE GESTIÓN DE LOS COSTOS La gestión de los costos del proyecto consta de tres procesos, como se muestra en la siguiente figura Si bien no se explicita en la PMBOK® Guide como proceso el planificar la gestión de los costos, es útil tener presente que el plan para la dirección del proyecto debe contener un plan subsidiario de la gestión de costos que plan- tee cómo se planearán, ejecutarán y controlarán los costos del proyecto. A efectos de rendir el examen de certificación, y tal como se muestra en la Figura 5.2, de la página 178, es importante manejar e integrar conceptual- mente estos procesos, reconociendo su doble condición de: • Procesos pertenecientes a un área de conocimiento específica, la gestión de los costos, que estima, presupuesta y controla, en este caso, los cos- tos del proyecto. • Procesos pertenecientes a algún grupo de procesos de gestión de pro- yectos, ya sea iniciación, planificación, ejecución, seguimiento y control o cierre del proyecto. Por ello, y cualquiera sea el proceso, este siempre pertenecerá simultá- neamente a un área de conocimiento y a un grupo de procesos de gestión de proyectos, tal como se muestra en la figura anterior. En nuestro caso, los dos primeros procesos de gestión de costos pertenecen al grupo de procesos de planificación del proyecto, en tanto que el tercero y último pertenece al grupo de procesos de seguimiento y control del proyecto. 5.2.1 Estimar los costos (Estimate Costs) De acuerdo al libro A Guide to the Project Management Body of Knowledge (PMI®, 2008), este proceso tiene por objeto estimar el costo de los recursos necesarios para completar las actividades programadas que conforman el proyecto. Es así como durante este proceso deberán estimarse los costos de todos los recursos que se considere utilizar (humanos y/o materiales), incluyendo las inversiones en bienes de capital e infraestructura y los costos operativos, tales como costos de materias primas o costos de financiación. Asimismo, deberán estimarse los costos asociados a las reservas por eventos riesgosos que pudieran ocurrir durante la vida del proyecto. A continuación se presentan los insumos, herramientas y técnicas y los re- sultados del proceso encaminado a estimar los costos del proyecto. 5.2.1.1 PRINCIPALES INSUMOS DEL PROCESO ESTIMAR LOS COSTOS Siguiendo la lógica de cualquier proceso, comenzaremos por el análisis de los insumos o entradas del proceso estimar los costos. Para estimar los costos del proyecto, es necesario tener a mano alguna infor- mación que, a esta altura, ya está disponible para el equipo de estimadores. Entre estos insumos se encuentran: 1. El enunciado del alcance del proyecto (Project Scope Statement), que permite identificar la justificación del proyecto, sus requerimientos y entregables, además de definir los supuestos y restricciones fundamen- tales, aspectos todos que tienen influencia en la estimación de los costos del proyecto. 2. La estructura de desglose del trabajo (EDT o Work Breakdown Structure, WBS) y su correspondiente diccionario EDT, que permite visualizar las actividades a realizar en el marco del proyecto y sus en- tregables. 3. El plan de gestión del cronograma del proyecto, que incluye la es- timación de los recursos de las actividades y la estimación de la du- ración de las actividades, el cual permite conocer las asignaciones de recursos humanos y materiales a las actividades en cada momento del proyecto y, por lo tanto, estimar el costo de aquellas en función de los recursos utilizados y del tiempo en que estos son asignados a cada actividad. 4. Los activos de los procesos de la organización, que permiten con- tar con políticas y procedimientos ya establecidos para la estimación de costos, como así también acceder a información histórica de proyectos similares. Estos activos pueden incluir las plantillas de costos, las leccio- nes aprendidas, el registro de riesgos o la experiencia de personas que trabajan en la organización. 5. Los factores ambientales de la empresa, que permiten conocer y ana- lizar datos y condiciones de mercado que pudieran ser relevantes para la estimación de costos, como por ejemplo la estructura de mercado de sus insumos (competencia perfecta, monopolio, oligopolio, etc.), la evolución de los precios de recursos clave y la condición financiera de los principa- les proveedores. 6. El plan de gestión del proyecto, que incluye los planes de gestión subsidiarios asociados a cada área de conocimiento, y cuyo conteni- do puede tener implicancias en la estimación de costos. Por ejemplo, el plan de gestión de riesgos puede establecer la necesidad de contar con reservas por contingencias, cuyo costo deberá ser estimado convenientemente. 5.2.1.2 TÉCNICAS DE ESTIMACIÓN DE COSTOS Siguiendo el enfoque de procesos, y luego de haber conocido y descrito los principales insumos del proceso de estimación de costos, nos abocaremos a conocer algunas de las principales herramientas y técnicas que se utilizan para realizar la estimación de los costos del proyecto. Con el fin de estimar los costos del proyecto se suelen utilizar, entre otras, las siguientes técnicas, las cuales debe conocer para aprobar el examen de certificación. 5.2.1.2.1 Estimación por analogía (Analogous Estimating o Top-down Estimating) Esta técnica de costeo estima los costos del proyecto tomando en conside- ración los costos reales de otros proyectos de similares características al analizado. Generalmente se utiliza en las fases iniciales de la planificación, cuando todavía no se cuenta con información detallada del proyecto. Por ello, esta técnica de estimación de costos usualmente requiere del juicio de ex- pertos, es decir, de personas que conocen el proyecto entre manos y tienen experiencia en proyectos similares. Si bien su grado de precisión suele ser menor que el de otros métodos de estimación, lo cierto es que, rápidamente y a bajo costo, nos permite esti- mar el costo general del proyecto, aunque carece del detalle de otras técnicas. A modo de ejemplo podemos mencionar que una empresa constructora puede estimar el costo de un nuevo emprendimiento inmobiliario tomando en consi- deración el último proyecto que acaba de terminar en la misma ciudad, que es muy parecido, para luego ajustar los aspectos que sean necesarios. ¡Qué ahorro de tiempo y esfuerzo! ¡Y qué bueno poder comparar! 5.2.1.2.2 Estimación ascendente (Bottom-up Estimating) Esta técnica estima los costos del proyecto sobre la base de una estimación detallada de los costos de las actividades o paquetes de trabajo del proyecto. Luego, estima los costos del proyecto “desde abajo hacia arriba”, sumando los costos de los recursos asignados a cada uno de los paquetes de trabajo que lo constituyen (un paquete de trabajo es el componente más pequeño de la EDT), agregándolos hasta llegar al proyecto completo. La estimación ascendente se nutre de un análisis pormenorizado de los cos- tos, por lo que requiere una mayor cantidad y calidad de información que la técnica de estimación por analogía, aunque, por ello mismo, gana en pre- cisión. En virtud de lo anterior, esta técnica de estimación de costos suele utilizarse cuando el nivel de conocimiento del proyecto, de sus requerimien- tos, entregables y cronograma, entre otros aspectos relevantes, es suficien- temente elevado. Una gran ventaja de esta herramienta es que se basa en la EDT, por lo cual es muy útil no solo para estimar en detalle los costos del proyecto, sino también en etapas posteriores, cuando se desea seguir y con- trolar el proyecto. A continuación se presenta la Figura 5.4, un ejemplo de estimación de costos ascendente. 5.2.1.2.3 Estimación paramétrica (Parametric Estimating) Esta técnica estima los costos de una actividad o de un recurso en función de información histórica, valiéndose para ello del análisis estadístico de re- gresión entre dos o más variables relevantes. Así, por ejemplo, se puede estimar el costo de las materias primas (Tabla 5.1) en función de los precios pagados en años anteriores y del volumen de producción previsto, tal como se muestra en la Figura 5.5. El análisis de regresión arroja una relación lineal entre las dos variables ana- lizadas, costo y volumen de producción, de acuerdo a la siguiente ecuación: Costo total = 1280,8 + 88,092 * Volumen de producción En el ejemplo, si proyectamos producir 195 unidades durante el año 2009, el costo estimado de las materias primas, de acuerdo a la estimación paramé- trica realizada, debería ser $ 18.428, según el siguiente cálculo: Costo total = 1280,8 + 88,092 * 195 = $ 18.428 Si bien su grado de exactitud puede ser elevado cuando la calidad de los datos es buena, no hay que perder de vista que para poder utilizarla se re- quiere información detallada e histórica de las variables a relacionar, lo cual, en ocasiones, puede volverla una técnica cara o de difícil aplicación por falta de datos. 5.2.1.2.4 Estimación con tres datos (Three-point Estimating) Esta técnica estima los costos de una actividad teniendo en cuenta tres posi- bles escenarios asociados: el escenario optimista (O), el más probable (M) y el pesimista (P). Para ello supone una distribución triangular, de la misma forma que lo hace la técnica PERT para la estimación de la duración de una activi- dad. Para poder aplicar esta técnica, si el examen lo requiriese, es importante que recuerde las siguientes fórmulas, que se presentan en la Figura 5.6. (1) Costo esperado = (O + 4 M + P) / 6 (2) Desvío estándar del costo = (P - O) / 6 Así, por ejemplo, se podría estimar el costo de una actividad sobre la base de tres estimaciones realizadas por un especialista, quien envió la siguiente información (Tabla 5.2). Tomando en consideración la fórmula presentada anteriormente, el costo esperado de la actividad asciende a $ 883,33, según el siguiente cálculo: Costo esperado = (740 + 4 * 840 + 1.200) / 6 = 883,33 Además, al momento de rendir el examen, se debe recordar que la estima- ción de los costos del proyecto también puede requerir el uso de alguna de las siguientes herramientas. 5.2.1.2.5 Software de gestión de proyectos Son herramientas integradas que asisten al gerente de proyecto y a su equi- po en la planificación de los tiempos, costos y recursos, entre otros aspectos. Entre estas herramientas se puede mencionar al Microsoft Project® o las hojas de cálculo del Microsoft Excel®, aunque, en términos más generales, se hace referencia a cualquier aplicativo que ayude a agilizar la tarea de es- timación de costos del equipo de proyecto. 5.2.1.2.6 Determinación de las tarifas de costos de recursos El proceso de estimación de costos requiere que el estimador conozca los costos unitarios de los recursos, humanos y materiales, que demanda el pro- yecto. Para ello podrá nutrirse de información de mercado públicamente dis- ponible, solicitar cotizaciones a actuales y potenciales proveedores o estimar los costos en función de otros proyectos u otras fuentes a su alcance. 5.2.1.2.7 Costo de la calidad El costo de la gestión de la calidad del proyecto (que incluye, por ejemplo, el necesario entrenamiento en gestión de la calidad, las auditorías de ase- guramiento de la calidad o la generación de reportes de control) también debe ser considerado al momento de estimar los costos de este. 5.2.1.2.8 Análisis de reserva Al estimar los costos del proyecto se deben considerar las reservas, que son sumas de dinero adicionales que tienen por objeto afrontar riesgos que puedan ocurrir durante su ejecución. Para el examen, se deberá recor- dar lo siguiente: • Existen dos tipos de reservas: – Reservas por contingencias (contingency reserves). – Reservas de gestión (management reserves). • La línea de base de costos incluye las reservas por contingencias, pero no las reservas de gestión, en tanto que el presupuesto de costos incluye tanto las reservas por contingencias como las reservas de gestión. El gerente de proyecto no debe permitir que las estimaciones realizadas por los miembros del equipo de trabajo o por los estimadores incluyan “colcho- nes de reservas discrecionales” (padding). Si una actividad es riesgosa y no tenemos certeza de su duración o su costo, el análisis de reserva deberá ser abordado y resuelto como parte de los procesos de gestión de riesgos del proyecto. 5.2.1.3 GRADO DE PRECISIÓN DE LAS ESTIMACIONES Como se dijo anteriormente, es natural que, en las etapas iniciales de plani- ficación, el equipo de proyectos no cuente con toda la información requerida para realizar una estimación de costos precisa y en detalle, y que, a medida que el proyecto avanza y se va definiendo y conociendo mejor, el nivel de precisión vaya aumentando hasta alcanzar un nivel aceptable para el estima- dor (Figura 5.8). Es por ello que al inicio del proyecto es usual que el equipo trabaje con estimaciones de orden de magnitud (ROM, Rough Order of Magnitude) del costo de las actividades cuyo margen de error es bastante amplio, y está en el rango de 50%/+100% del costo real de la actividad. Posteriormente, el equipo deberá llegar a estimaciones definitivas, cuyo margen de error es mucho más acotado, en el rango de -10%/+15% del costo real. 5.2.1.4 PRINCIPALES RESULTADOS O SALIDAS DEL PROCESO ESTIMAR LOS COSTOS Por último, se trata de identificar y conocer los resultados del proceso de estimación de costos. Entre los resultados esperados del proceso de estimación de costos se en- cuentra la estimación del costo de las actividades, que es el resultado más importante de este proceso, pues con esta información puede empezar la preparación del presupuesto de costos del proyecto. Además, la estimación del costo de las actividades debe estar acompañada por información de respaldo que permita comprender claramente sobre qué bases metodológicas e informativas se han realizado las estimaciones. Esta información de respaldo deberá documentar las fuentes de información utilizadas, así como los supuestos y restricciones usados en el análisis y en los cálculos efectuados. Pero, dado que la administración de un proyecto implica la gestión de un sistema de relaciones, es natural que, como consecuencia del proceso de estimación de costos, puedan surgir algunas solicitudes de cambios que afecten tanto al plan de gestión de costos como a otros aspectos del proyec- to (por ejemplo, la gestión del alcance, de los tiempos, de la calidad y de los riesgos del proyecto). Aquí es importante tomar en consideración el rol que cumple el proceso de control integrado de cambios en el análisis y aprobación o rechazo de estos. Finalmente, si como resultado del proceso de control integrado de cambios se aprueban algunas solicitudes de cambio, estas deberán ser incorporadas para actualizar el plan de gestión de costos u otros documentos del proyecto. Recuerde que antes de aceptar las solicitudes de cambios, el gerente deberá estudiar las solicitudes provenientes de la gerencia, analizando su impacto sobre el proyecto y cuidando que los objetivos se mantengan siempre realistas. 5.2.2 Determinar el presupuesto (Determine Budget) El proceso determinar el presupuesto (Figura 5.9) tiene por objeto “sumar los costes estimados de las actividades individuales o los paquetes de trabajo, agregándolos a fin de establecer la línea de base de costo total del proyecto autorizada” (PMI®, 2008, p. 165). Esta línea de base será una herramienta de fundamental importancia para realizar el control del proyecto durante su ejecución. En este punto cabe enfa- tizar la importancia de la restricción triple, que en su definición amplia importa la íntima relación entre el alcance, los tiempos, los costos, la calidad, los ries- gos y la satisfacción del cliente, pues no es razonable pensar en elaborar un presupuesto realista del proyecto si no se consideran simultáneamente todos estos y otros aspectos del proyecto. Al momento de rendir el examen de cer- tificación, recuerde que es responsabilidad del gerente de proyecto asegurar la elaboración de un presupuesto realista y ceñirse a él para el cumplimiento de uno de los principales objetivos del proyecto: que se ejecute dentro de los límites del presupuesto aprobado en el plan de gestión. Tal como se hizo anteriormente, se realizará un análisis de aquellos concep- tos clave que el postulante deberá conocer a efectos de responder adecua- damente las preguntas del examen, sean estas situacionales o conceptuales. Siguiendo el enfoque de procesos, identificaremos sus entradas, herramien- tas y técnicas y sus salidas. Se iniciará con el análisis de los insumos o entradas del proceso determinar el presupuesto de costos del proyecto. 5.2.2.1 PRINCIPALES INSUMOS DEL PROCESO DETERMINAR EL PRESUPUESTO DE COSTOS Entre los insumos necesarios para determinar el presupuesto de costos del proyecto se encuentran: 1. El enunciado del alcance del proyecto (ProjectScopeStatement), que, como se dijo, permite identificar la justificación del proyecto, sus requeri- mientos y entregables, pero además conocer y considerar cualquier res- tricción financiera (vinculada, por ejemplo, a las condiciones para desem- bolsar fondos por parte del inversor) que pueda tener implicancia en la preparación del presupuesto de costos del proyecto. 2. La estructura de desglose del trabajo (EDT) y su correspondiente diccionario EDT, que permite conocer y visualizar las actividades del proyecto y sus entregables, y, por tanto, también el costo por actividad y por paquete de trabajo, fuente para la presupuestación del proyecto completo. 3. Las estimaciones del costo de las actividades, que, siendo el principal producto del proceso de estimación de costos, se constituyen lógicamen- te en un insumo crítico para la construcción del presupuesto del proyecto. El costo de las actividades deberá luego sumarse adecuadamente para costear los paquetes de trabajo, las cuentas control y finalmente el pro- yecto completo. 4. La información de respaldo de las estimaciones del costo de las activi- dades, que sirve de referencia y consulta a quienes estén preparando el presupuesto. 5. El cronograma del proyecto detalla las actividades a ejecutar por uni- dad de tiempo, por lo que en conjunto con las estimaciones de los costos de las actividades permite preparar el presupuesto del proyecto, sumando los costos de las actividades en escala temporal. 6. Si existiera un contrato firmado entre las partes, este deberá ser con- siderado al momento de preparar el presupuesto, prestándose especial importancia a los productos cuya entrega se ha comprometido y a sus costos relacionados. 7. A fin de asegurar la razonabilidad del presupuesto de costos, durante su elaboración seguramente será necesario consultar y tener en cuenta los distintos planes de gestión subsidiarios (alcance, tiempos, calidad, comunicaciones, etc.), incluyendo, por supuesto, el plan de gestión de costos y el plan de gestión del proyecto, por lo que todos ellos deberán estar disponibles al preparar el presupuesto. Siguiendo el enfoque de procesos, y luego de haber conocido y analiza- do los principales insumos del proceso de preparación del presupuesto de costos, ahora nos abocaremos a conocer algunas de las principales herramientas y técnicas que se utilizan para realizar la estimación de los costos del proyecto. 5.2.2.2 TÉCNICAS DE PRESUPUESTACIÓN DE COSTOS A efectos de estimar los costos del proyecto se suelen utilizar, entre otras, las siguientes técnicas, las cuales debe conocer para aprobar el examen de certificación. 5.2.2.2.1 Suma o agregación de costos Esta técnica nos permite determinar el presupuesto del proyecto por agrega- ción o sumatoria de costos “desde abajo hacia arriba” siguiendo la estructura de desglose del trabajo (EDT). Es así como, en primer término, se suma el costo de las actividades para determinar el costo de los paquetes de trabajo, y luego se suma el costo de los paquetes de trabajo para determinar el costo de las cuentas control1. Finalmente, y siguiendo la misma lógica, se agregan los costos de las cuentas control para determinar el costo total del proyecto. EJERCICIO 5.5 Responda con sus propias palabras: ¿qué herramientas y técnicas puedo aplicar para determinar adecuadamente el presupuesto de costos del pro- yecto? _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ 1 Las cuentas de control agregan, suman e integran los diferentes paquetes de trabajo. Es importante verificar que no haya duplicación de paquetes de trabajo ni actividades. A continuación se presenta un ejemplo de determinación del presupuesto de costo de un proyecto (Figura 5.10) El resultado de este proceso es un presupuesto de proyecto que no consti- tuye el producto final del proceso de preparación del presupuesto. Ahora, es necesario agregar las reservas estimadas previamente, a fin de obtener la línea de base de costos y el presupuesto de costos totales. 5.2.2.2.2 Análisis de reserva Como se mencionó anteriormente, la preparación del presupuesto de costos requiere la determinación de las reservas que se incluirán en él. En este pun- to vale la pena recordar la diferencia conceptual que existe entre las reservas por contingencias y las reservas de gestión. El lector deberá recordar que las reservas por contingencias son presupues- tos que se establecen para hacer frente a situaciones conocidas pero incier- tas (riesgos identificados), en tanto que las reservas de gestión son presu- puestos reservados que se establecen en el caso en que sucedan eventos no conocidos e inciertos (riesgos no identificados). Esta diferencia concep- tual es muy importante porque genera implicancias operativas Por estar vinculadas a riesgos conocidos o planeados, las reservas por con- tingencias forman parte de la línea de base de costos y del presupuesto del proyecto, y pueden ser utilizadas por el gerente de proyecto, sin necesidad de contar con autorización previa alguna. Dado que las reservas de gestión están vinculadas a riesgos desconocidos o no planeados, estas no forman parte de la línea de base de costos, aunque sí del presupuesto del proyecto, y solo pueden ser utilizadas por el gerente de proyecto con autorización previa de su superior. 5.2.2.2.3 Estimación paramétrica Durante el proceso de construcción de la línea de base y el presupuesto de costo del proyecto, el equipo usualmente deberá chequear los resultados ob- tenidos, comparándolos con estándares conocidos o modelos de costos de la industria, a fin de ajustar o justificar cualquier diferencia sustantiva. Por ejemplo, en la industria minera existen modelos paramétricos que permi- ten estimar, en función de ciertas variables relevantes, los costos de trans- porte de un proyecto minero a cielo abierto, los cuales ascienden a aproximadamente el 40% del costo total del proyecto. Así pues, este es un parámetro de relevancia que debería cotejar todo aquel que se encuentre estimando el costo de un proyecto de similares características. Vale aquí recordar la importancia de asegurar la calidad y suficiencia de los datos que se utilizarán para la estimación paramétrica de los costos. 5.2.2.2.4 Conciliación del límite de la financiación Finalmente, y antes de dar por concluida la elaboración de la línea de base y el presupuesto, el gerente de proyecto deberá conciliar la demanda de fon- dos del proyecto y los límites de financiación para el proyecto definidos por el cliente o la organización, los cuales se encuentran detallados usualmente en el enunciado del alcance del proyecto. Esta conciliación podría resultar en cambios de algunos aspectos clave del proyecto, tales como el cronograma de actividades o los requerimientos de recursos, los cuales deberán acomo- darse a través del proceso de control integrado de cambios. Como se puede apreciar, la conciliación tiene por objeto asegurar que el presupuesto sea realista y cuente con la aprobación de los interesados. 5.2.2.3 PRINCIPALES RESULTADOS O SALIDAS DEL PROCESO DE PREPARACIÓN DE PRESUPUESTO DE COSTOS Entre los resultados esperados del proceso de determinación del presupues- to del proyecto se encuentran: 1. La línea de base de costos del proyecto, la cual nos permitirá controlar el desempeño de los costos del proyecto. 2. El presupuesto de costos del proyecto, que nos permitirá conocer la demanda de fondos, total y por periodo, que requiere el proyecto para poder financiar todas las actividades previstas en el plan. Este surge de la línea de base de costos, a la que deben sumarse las reservas de gestión, para hacer frente a cualquier evento no previsto en el plan del proyecto. 3. Usualmente, como consecuencia del proceso de preparación del presu- puesto de costos, surgirán solicitudes de cambios que pueden impactar en el plan de gestión de costos (también pueden darse en otros planes de gestión subsidiarios, tales como el plan de gestión del alcance o del cronograma del proyecto). Es importante recordar siempre que estas solicitudes de cambio deberán pasar por el proceso de control integrado de cambios para su consideración y potencial aprobación, antes de proceder a la actualización de los documen- tos del proyecto. Finalmente, si como resultado del proceso de control integrado de cambios se aprueban algunas solicitudes de cambio que tengan impacto en la gestión de costos, se deberá actualizar el plan de gestión de costos y en consecuen- cia el plan de gestión del proyecto. 5.2.2.3.1 Línea de base de costos del proyecto Según la PMBOK® Guide, “la línea base de costos es un presupuesto dis- tribuido en el tiempo”, e indica el flujo de erogaciones que se prevé realizar para completar las actividades del proyecto. Por ello, este es uno de los entregables más importantes de los procesos de planificación del proyecto, siendo parte integrante del plan de gestión de costos y del plan de gestión del proyecto. A modo de ejemplo, a continuación se presenta un presupuesto de los costos de las actividades de un proyecto, que incluye las reservas por contingencias y que, una vez aprobado, constituirá la línea de base de costos del proyecto Como se puede observar en la Figura 5.11, la línea de base (también cono- cida como línea “S”) constituye un cronograma de desembolsos previstos a través del tiempo, desde que comienza el proyecto hasta el momento en que finaliza formalmente, e indica la “hoja de ruta” contra la cual se medirá, comparará y controlará la ejecución real del proyecto, a fin de detectar posi- bles desvíos, ajustarlos y evaluar el desempeño de la gestión de costos del proyecto. La línea de base de costos debe ser respetada siempre, y solo puede modi- ficarse si existe una solicitud de cambio aprobada referida a ella. 5.2.2.3.2 El presupuesto de costos del proyecto El presupuesto de costos se construye tomando en consideración la línea de base de costos, a la cual se adicionan las reservas de gestión. Como se mencionó anteriormente, estas representan presupuestos reservados que, aunque no pueden ser utilizados por el gerente de proyecto sin previa autori- zación, deben ser sumados al presupuesto para establecer la necesidad total de financiamiento del proyecto. Siguiendo con el ejemplo, se presenta a continuación el cálculo del presu- puesto de costo del proyecto, considerando para ello una reserva de gestión del 5% (Tabla 5.4 y Figura 5.12). 5.2.3 Controlar los costos (Control Costs) Este proceso tiene por objeto “monitorear el estado del proyecto, a fin de ac- tualizar el presupuesto del proyecto y administrar los cambios a la línea de base de costos del proyecto” (PMI®, 2008, p. 165). El objetivo del proceso controlar los costos (Figura 5.13, pág. 198) es seguir y comparar la evolución de los costos reales del proyecto con relación a la línea de base de costos. Cualquier diferencia encontrada deberá documen- tarse, como asimismo analizarse las causas que puedan haber originado dicha variación, asegurando que solo se realicen los cambios acordados y aprobados mediante el proceso de control integrado de cambios, y evitando cualquier modificación que no siga este proceso formal. Aquí cabe destacar que el control es una función ejecutiva que involucra la toma de decisiones. Consecuentemente, el control de costos del proyecto requiere de una actitud proactiva que, sustentándose en el plan de gestión de los costos, permita detectar y registrar las variaciones y sus causas, así como analizarlas para determinar si ameritan una acción correctiva, con el fin de mantener los costos del proyecto dentro de los límites aceptables. Finalmente, también debe tenerse en cuenta la importancia de comunicar a los interesados, en forma oportuna y completa, los cambios aprobados que se deriven del proceso de control de costos del proyecto. Controlar es: medir, documentar, comparar, decidir, comunicar y actuar. Como todo proceso, tendrá sus entradas, herramientas y técnicas y sus salidas. Dado que el postulante debe conocer las características fundamentales del proceso de control de costos a efectos de responder adecuadamente las preguntas del examen, se hará un análisis de los insumos o entradas más importantes de este proceso. EJERCICIO 5.7 Responda con sus propias palabras: ¿qué necesito conocer y con qué infor- mación debo contar para poder controlar los costos del proyecto? _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ MOMENTO DE REFLEXIÓN: tómese cinco minutos e intente su mejor respuesta antes de seguir leyendo el próximo párrafo. 5.2.3.1 PRINCIPALES INSUMOS DEL PROCESO CONTROLAR LOS COSTOS Para poder recordar, sin memorizar, los insumos de este proceso es impor- tante tener en cuenta que el control implica comparar y ajustar. Para compa- rar se debe tener información acerca del plan trazado, así como de medicio- nes de la ejecución real del proyecto. Finalmente, el proceso de control de costos también se nutre de solicitudes de cambios aprobadas por el control integrado de cambios que pueden modificar, por ejemplo, el alcance o el cro- nograma del proyecto, como así también la línea de base o los presupuestos previamente acordados por contrato. Por ello, no debería sorprendernos que entre los insumos necesarios para controlar los costos del proyecto se encuentran: 1. El plan de gestión del proyecto, que define cómo se va a llevar a cabo el proyecto y contiene los planes subsidiarios, entre ellos, el plan de ges- tión de costos, que define, por ejemplo, qué se va controlar, cómo se hará, cuándo o con qué periodicidad se controlará el proyecto y quiénes son los responsables del control de los costos de este. 2. La línea de base de costos del proyecto, que es el espejo contra el cual se comparará la evolución prevista y real de los costos, a efectos de controlar su desempeño. 3. El presupuesto de costos del proyecto, que es donde se define la de- manda total de fondos requeridos para completar el proyecto, y cuyo cum- plimiento es responsabilidad del gerente de proyecto, siendo también un indicador clave del éxito de aquel. 4. Los informes de estado de avance del proyecto, que brindan informa- ción sobre la evolución real de los costos del proyecto, en función del avance real de la obra a la fecha de medición. Estos informes incluyen información acerca del grado de avance de las actividades del proyecto y sus costos reales erogados, entre otros aspectos. 5. Las solicitudes de cambio aprobadas que surjan del proceso de con- trol integrado de cambios, y que puedan afectar al presupuesto de costos y la línea de base, como así también a otros aspectos del proyecto. 5.2.3.2 TÉCNICAS DE CONTROL DE COSTOS Siguiendo el enfoque de procesos, y luego de haber conocido y analizado las principales entradas del proceso de control de costos, nos abocaremos a conocer algunas de las principales herramientas y técnicas que se utilizan para realizar el control de costos. MOMENTO DE REFLEXIÓN: tómese cinco minutos e intente su mejor respuesta antes de seguir leyendo el próximo párrafo. En este punto pondremos especial énfasis en la técnica del valor ganado, una herramienta muy propia de la gestión de proyectos, y cuyo conocimiento le permitirá mejorar el seguimiento de sus proyectos. Adicionalmente, podrá responder correctamente al menos 10 preguntas del examen. Sin embargo, también es importante que conozca otras técnicas y herramientas de control, entre las que se destacan las reuniones de revisión de desempeño del proyecto, donde se presenta información respecto del estado actual y planeado de este para su análisis y toma de decisiones. También se suelen realizar análisis de variaciones, que tienen por objeto analizar y cotejar la evolución real del proyecto y su evolución planeada (Figura 5.14). En este análisis se consideran los distintos aspectos refleja- dos en la restricción triple ampliada, y que hacen referencia al alcance, el cronograma, los costos, la calidad, los riesgos y la satisfacción del cliente del proyecto, a fin de detectar desvíos en forma temprana. El análisis de variaciones también puede complementarse con el análisis de tendencias, que examina la dirección en que se mueven las variables clave del proyecto (Figura 5.15, pág. 202). Por ejemplo, el índice de rendimiento de costos (CPI, Cost Performance Index) y el índice de rendimiento del cro- nograma (SPI, Schedule Performance Index) identifican movimientos sis- temáticos hacia arriba (tendencia alcista) o hacia abajo (tendencia bajista) en estas variables. Este análisis le permitirá al equipo de proyecto reco- mendar tempranamente las acciones preventivas o correctivas que consi- dere apropiadas. Los softwares de gestión de proyectos también son una herramienta muy utilizada para controlar el avance del proyecto. Entre ellos se cuentan, por ejemplo, una hoja de cálculo Excel® o el mismo MS-Project®. Finalmente, debemos recordar que para controlar adecuadamente los costos es necesario contar con un sistema de control de cambios que establezca el procedimiento formal que debe seguir una solicitud de cambio asociada a los costos del proyecto. Así, por ejemplo, es posible que en algún momento del proyecto se decida cambiar la línea de base, en virtud de un cambio sustan- cial en el costo de los insumos productivos. De ser así, este potencial cambio deberá seguir los pasos previstos en el sistema de control de cambios del proyecto, el cual está íntimamente vinculado al proceso de control integrado de cambios, que permitirá analizar la influencia del cambio solicitado sobre otros aspectos del proyecto y determinar la conveniencia de autorizar o re- chazar dicho cambio. 5.2.3.2.1 La medición del rendimiento y la técnica del valor ganado Tradicionalmente, la medición del desempeño del proyecto se realiza compa- rando la evolución del costo real del proyecto en relación con la línea de base de costos del proyecto. Sin embargo, esta comparación resulta en conclusiones limitadas y muchas veces erróneas acerca del rendimiento del proyecto. A modo de ejemplo, se presenta el valor planificado o la línea de base de un proyecto y el costo real al final del cuarto mes de ejecución (Tabla 5.5 y Figura 5.16). Del análisis de la información anterior surge que, al final del mes 4, el proyec- to ha gastado menos dinero que lo que se había previsto. Pero, ¿cómo está el proyecto? Que se haya gastado menos dinero que el previsto podría signi- ficar que se ha sido muy eficiente en el uso de los recursos o, por el contrario, que el proyecto está atrasado, y que, como consecuencia, la utilización de recursos y erogación de dinero ha sido menor a la planificada a esa fecha. Como se observa de la comparación entre el costo real y la línea de base, no surgen elementos que permitan dilucidar si el proyecto está siendo bien gestionado o no. Es entonces que la técnica del valor ganado, una de las herramientas más modernas para realizar el control de un proyecto, aparece para superar aque- llas limitaciones. Esta técnica releva, en un solo proceso, el estado del pro- yecto en función de algunas de sus variables más críticas –su alcance, sus tiempos y sus costos–, lo que permite conocer las causas de las variaciones observadas entre la línea de base y el costo real. Esta técnica se puede aplicar tantas veces como se desee o como se prevea en el plan de proyecto (controles diarios, quincenales, mensuales), estable- ciendo de esta forma un registro del desempeño del proyecto a través del tiempo. Además, de ella se derivan informes de desempeño del proyecto de gran poder informativo para el equipo y para otros interesados, lo que facilita grandemente la comunicación de los resultados del proyecto. Cualquiera sea la fecha en que se desee medir el avance del proyecto, para calcular el valor ganado (Tabla 5.6) se deberán estimar tres valores para cada componente de la EDT2 del proyecto, que son: • Valor planificado (Planned Value, PV): indica el costo previsto de la actividad o paquete de trabajo hasta la fecha de estado3, considerando el presupuesto y la agenda establecidos en el plan de proyecto. Es la línea de base de costos del proyecto hasta la fecha de estado. Res- ponde a la pregunta: “¿Cuánto vale, al día de hoy, el trabajo que hemos planeado realizar, considerando la agenda y el presupuesto de costos acordados?”. • Costo real (Actual Cost, AC): indica el costo real ejecutado de la ac- tividad hasta la fecha de estado, considerando los costos reales de los recursos y el avance de obra real de la actividad. Responde a la pregunta: “¿Cuánto hemos gastado, al día de hoy, en el trabajo efectivamente reali- zado? ”. • Valor ganado (Earned Value, EV): indica el monto presupuestado para el trabajo realmente completado del componente considerado, hasta la fecha de estado. Indica el valor trabajado del componente, y para calcu- larlo se debe multiplicar el presupuesto de la actividad por el avance de obra real de esta. Responde a la pregunta: “¿Cuánto vale, al día de hoy, el trabajo efectivamente realizado?”. Obsérvese que el cálculo del valor ganado nace de una combinación de “algunos elementos de los dos primeros conceptos”, pues considera: 1. El presupuesto de la actividad, pero no su costo real, aproximándose en este aspecto al valor planificado. 2. El avance de obra real de la actividad, pero no su avance previsto, acer- cándose este aspecto al costo real. 2 La palabra “componente” hace mención a una actividad, un paquete de trabajo o una cuenta control del proyecto. 3 La fecha de estado es la fecha en la que se está realizando la medición del avance del proyecto y para la cual se hace el análisis del valor ganado. En términos de fórmulas podemos decir que: Valor planificado, PV = Costo planeado * Avance de obra planeado Costo real, AC = Costo real * Avance de obra real Valor ganado, EV = Costo planeado * Avance de obra real Para ejemplificar los conceptos y poder aplicarlos en la resolución de pregun- tas del examen, a continuación se presenta una tabla de datos que permitirá realizar la medición del rendimiento del proyecto anteriormente presentado mediante la técnica del valor ganado (Tabla 5.7). A tal efecto se presenta información que detalla el avance de obra real al final del periodo correspon- diente para cada actividad. En función del avance de obra real al final de cada mes y del valor planificado o presupuesto de la tarea podemos calcular el valor ganado, de acuerdo a la fórmula presentada anteriormente (Tabla 5.8). Valor Ganado, EV = Costo planeado * Avance de obra real Así, por ejemplo, al tomar en consideración la Actividad 1, que tiene un costo planeado de $ 4.000, y se conoce que el avance de obra al final del mes 1 fue del 20%, se puede calcular su valor ganado a esa fecha, que asciende a $ 800 ($ 4.000 * 20%). De la misma forma, dado que el costo planeado de la Actividad 2 es de $ 4.800, el avance de obra al final del mes 1 fue 20%, y su valor ganado a esa fecha alcanzó $ 960. En consecuencia, el valor ganado del proyecto al final del mes 1 fue $ 1.760. Al ir agregando las tres variables consideradas (Tabla 5.9), se obtiene el si- guiente gráfico, del cual se deriva información muy valiosa para el seguimiento y control del proyecto (Figura 5.17). En función de la información anterior, es posible construir dos indicadores que reflejarán el estado de cumplimiento de los tiempos y costos, tanto para las actividades individuales como para el proyecto en su conjunto. Estos in- dicadores son: • E líndice de rendimiento del cronograma (SPI,SchedulePerformanceIndex). •El índice de rendimiento de costos (CPI, Cost Performance Index). Estos permiten analizar los desvíos ocurridos en la agenda y en los costos del proyecto, respectivamente. El índice de rendimiento del cronograma (SPI) es un cociente que se constru- ye considerando el valor ganado (EV) y el valor planificado (PV) a una fecha de estado determinada, tal como se presenta a continuación: SPI = EV / PV Debido a que tanto el valor ganado (EV) como el valor planificado (AC) con- sideran los costos planeados, la única razón por la que estos valores pueden ser diferentes es porque el avance de obra real difiere del avance de obra planeado, constituyendo esto último un problema de cronograma. Es por ello que este indicador puede encontrarse, en un momento dado del tiempo, en cualquiera de los siguientes tres rangos de valores: SPI > 1, indica que el valor ganado (EV) es mayor que el valor planificado (AC), lo cual solo se puede deber a que el avance de obra real sea mayor que el avance de obra previsto, constituyendo esto último una eficiencia de tiempos. El proyecto está progresando a un ritmo mayor que el planeado. SPI = 1, indica que el valor ganado (EV) es igual que el valor planificado (AC), lo cual solo se puede dar si el avance de obra es igual al avance de obra pre- visto. En consecuencia, el proyecto está progresando al ritmo planeado. SPI < 1, indica que el valor ganado (EV) es menor que el valor planificado (AC), lo cual solo se puede deber a que el avance de obra real sea menor que el avance de obra previsto, constituyendo esto último una ineficiencia. El proyecto está progresando a un ritmo menor que el planeado. Otra forma de interpretar este indicador es que “el proyecto está progresan- do al SPI * 100% del ritmo planeado”. Por lo tanto, cuanto mayor sea el SPI, mayor es el ritmo del proyecto, y, por el contrario, cuanto menor sea el SPI, menor será aquel. A continuación se presenta la evolución del índice de rendimiento del crono- grama (SPI, Schedule Performance Index) para cada actividad del proyecto y para el proyecto en su conjunto (Tabla 5.10). Este es un proyecto que comenzó con atrasos sustanciales en el cronogra- ma que han podido ser solucionados progresivamente. Hoy, el proyecto mar- cha a un ritmo más rápido que lo planeado. El proyecto está progresando al 75,8% del ritmo planeado. Por otro lado, el índice de rendimiento de costos (CPI) es un cociente que se construye considerando el valor ganado (EV) y el costo real (AC) en relación con una fecha de estado determinada, tal como se presenta a continuación: CPI = EV / AC Debido a que tanto el valor ganado (EV) como el costo real (AC) consideran el avance de obra real, la única razón por la que estos valores pueden ser diferentes es porque el costo real de los insumos difiere del presupuestado, constituyendo esto último un problema de costos. Es por ello que este indi- cador puede encontrarse, en un momento dado del tiempo, en cualquiera de los siguientes tres rangos de valores: CPI > 1, indica que el valor ganado (EV) es mayor que el costo real (AC), lo cual solo se puede deber a que el costo previsto de los componentes completados ha resultado mayor que el costo real de estos, generando en consecuencia una eficiencia de costos. CPI = 1, indica que el valor ganado (EV) es igual que el costo real (AC), lo cual solo se puede deber a que el costo previsto de los componentes eje- cutados ha resultado igual al costo real de estos, por lo que el proyecto se ajusta al presupuesto. CPI < 1, indica que el valor ganado (EV) es menor que el costo real (AC), lo cual solo se puede deber a que el costo previsto de los componentes eje- cutados ha resultado menor que el costo real de estos, constituyendo esto último una ineficiencia de costos. Otra forma de interpretar este indicador es que “cada peso que hemos pla- neado gastar en el proyecto está rindiendo por CPI pesos”. Por lo tanto, cuanto mayor sea el CPI, mejor es el rendimiento de los costos del proyecto, y, por el contrario, cuanto menor sea el CPI, menor será aquel. A continuación se presenta la evolución del índice de rendimiento del cro- nograma (CPI, Cost Performance Index) para cada actividad del proyecto y para el proyecto en su conjunto (Tabla 5.11). Como se puede observar en la tabla 5.11, el proyecto en su conjun- to tiene problemas de eficiencia de costos, aunque la situación parece ir mejorando con el tiempo. Como se puede ver, cada peso que se ha pla- neado gastar en el proyecto está rindiendo por 0,91 pesos al final del periodo 4. El postulante debe estar en condiciones de obtener el valor de los indica- dores para un proyecto y reconocer que del análisis conjunto de ambos indicadores surge que el proyecto inicialmente tenía problemas de costos y de cronograma, pero que el ritmo de obra fue paulatinamente acelerán- dose de forma que, al final del tercer periodo, el proyecto está adelantado respecto de la agenda prevista, aunque persisten problemas respecto del rendimiento de los costos. La técnica del valor ganado también permite detectar las variaciones de cos- tos y de cronograma mediante las siguientes dos ecuaciones: Variación en costos (CV) = EV - AC Variación en cronograma (SV) = EV - PV Como se puede observar, estas son una “transformación” de los índices de rendimiento de costos y de cronograma respectivamente, cuya interpretación es la siguiente: Si VC > 0, el valor ganado es mayor que el costo actual, lo cual es equiva- lente a un CPI > 1. En consecuencia, el proyecto presenta un rendimiento de costos mejor que el previsto. Si VC < 0, el valor ganado es menor que el costo actual, lo cual es equiva- lente a un CPI < 1. En consecuencia, el proyecto presenta ineficiencias en la gestión de costos. Si VC = 0, el valor ganado es igual que el costo actual, lo cual es equivalente a un CPI = 1. En consecuencia, el proyecto presenta un rendimiento equiva- lente al planificado. Es importante mencionar que tanto el análisis de variaciones como el análi- sis de tendencias y la técnica del valor ganado se nutren de información del proyecto para presentar un análisis del comportamiento pasado de este, aun- que estas mismas herramientas también sirven para realizar proyecciones acerca de las condiciones del proyecto en el futuro, sobre la base de toda la información disponible a la fecha de la proyección. Estas proyecciones de- ben ser actualizadas en cada reporte de rendimiento a medida que avance el proyecto. Para realizar proyecciones a partir del análisis del valor ganado, es necesario conocer algunos conceptos adicionales, como, por ejemplo, el presupuesto a la conclusión (Budget at Completion, BAC), que es el presupuesto total a la finalización del proyecto o del componente que se esté analizando. En nuestro ejemplo, el BAC del proyecto es $ 25.600. Estimación a la conclusión (EAC) Si se conoce el presupuesto a la conclusión (Budget at Completion, BAC) y el indicador de rendimiento de costo (CPI), se puede calcular, por ejemplo, la estimación a la conclusión (EAC, Estimate at Completion) a través del siguiente cálculo: Estimación a la conclusión (EAC) = BAC / CPI Siguiendo con el ejemplo, se puede observar que el proyecto tenía un presu- puesto a la conclusión (BAC) de $ 25.600, pero el índice de rendimiento en costo (CPI) permite saber que hasta la fecha de análisis (al final del periodo 4), cada peso que se ha planeado gastar en el proyecto está rindiendo por 0,91 pesos. Esto indica que, en realidad, los $ 25.600 no serán suficientes para terminar el proyecto, por lo que una nueva estimación del presupuesto nos diría que necesitamos más dinero. ¿Cuánto dinero? Estimación a la conclusión (EAC) = $ 25.600 / 0,91 = $ 28.142 Estimación hasta la conclusión (ETC) Por otro lado, también se puede calcular la estimación hasta la conclusión (ETC), que indica cuánto dinero debería erogarse desde hoy hasta el final del proyecto, de acuerdo al rendimiento actual. Para ello se deben conocer la estimación a la conclusión (EAC) y el costo real (AC) del proyecto a la fecha de proyección. Si, de acuerdo al ejemplo, se espera una erogación total de $ 28.142 para terminar el proyecto, y hasta la fecha hemos gastado $ 15.500, entonces la estimación del costo restante hasta la conclusión, o simplemente la estimación hasta la conclusión, es de $ 12.642. Además de las fórmulas básicas presentadas en el punto anterior, existen otras alternativas para calcular la estimación a la conclusión (EAC) y la estimación hasta la conclusión (ETC), dependiendo de cuál sea nues- tro pronóstico acerca del comportamiento futuro de las variaciones del proyecto. En ocasiones la empresa podría realizar desde cero un nuevo cálculo de los costos restantes del proyecto considerando el alcance del trabajo pendiente y sin tomar en cuenta el rendimiento pasado del proyecto. Por ejemplo, la empresa podría determinar que el nuevo costo hasta la culminación del pro- yecto en función de las nuevas estimaciones de costos asciende a $ 13.000, y basados en esta estimación original de los costos restantes podríamos recalcular la estimación a la conclusión (EAC) con la siguiente fórmula: EAC = AC + ETC = $ 15.500 + $ 13.000 = $ 28.500 Como se observa, si a la fecha se han gastado $ 15.500, y la nueva esti- mación de los costos restantes realizada desde cero asciende a $ 13.000, entonces la estimación de los costos totales a la finalización del proyecto es $ 28.500. Variaciones atípicas Por otro lado, si se considera que los costos del proyecto han tenido algunas variaciones atípicas hasta la fecha, pero que estas no se repetirán para lo que resta del proyecto, entonces se podrían estimar los costos restantes en función del presupuesto a la finalización (BAC) y del valor ganado (EV), me- diante la siguiente fórmula: ETC = BAC - EV = $ 25.600 - $ 14.100 = $ 11.500 La interpretación del resultado es: si hasta la fecha hemos trabajado por un valor de $ 14.100 y el proyecto total tiene un valor planeado de $ 25.600, entonces el valor del trabajo restante a la fecha es $ 11.500. Considerando la estimación anterior, se podría recalcular la estimación a la conclusión (EAC) con la siguiente fórmula: EAC = AC + ETC = $ 15.500 + $ 11.500 = $ 27.000 Aquí, la estimación a la conclusión (EAC) es igual al costo real más una estimación del costo del trabajo restante, asumiendo que no habrá variaciones en el trabajo restante. Variaciones típicas Por el contrario, si se considera que los costos del proyecto han tenido al- gunas variaciones típicas hasta la fecha, y que estas se repetirán para lo que resta del proyecto, entonces se podrían estimar los costos restantes en función del presupuesto a la finalización (BAC) y del valor ganado (EV), corregidos por el índice de rendimiento en costos (CPI) mediante la siguiente fórmula: ETC = (BAC - EV) / CPI = ($ 25.600 - $ 14.100) / 0,91 = $ 11.500 / 0,91 = $ 12.642 Considerando la estimación anterior, se podría recalcular la estimación a la conclusión (EAC) con la siguiente fórmula: EAC = AC + ETC = $ 15.500 + $ 12.642 = $ 28.142 Aquí, la estimación a la conclusión (EAC) es igual al costo real más una estimación del costo del trabajo restante, asumiendo que habrá variaciones en el trabajo restante, y que estas seguirán el mismo patrón que las varia- ciones pasadas. Por último, es importante recordar también que nos podrían pedir calcular la variación de costos a la finalización del proyecto (Variance at Completion, VAC), para lo cual podemos utilizar la siguiente fórmula: VAC = BAC - EAC = $ 25.600 - $ 28.142 = - $ 2.542 Si el VAC es positivo, entonces se prevé que el proyecto se completará con un presupuesto menor que el planeado. Si el VAC es negativo, entonces se prevé que el proyecto se completará con un presupuesto mayor que el planeado. ¡Cuidado! Si el VAC es cero, entonces se prevé que el proyecto podrá completarse con el presupuesto planeado 5.2.3.3 PRINCIPALES RESULTADOS O SALIDAS DEL PROCESO CONTROLAR LOS COSTOS EJERCICIO 5.9 Responda con sus propias palabras: ¿qué resultados o productos obtengo del proceso de control de costos? _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ MOMENTO DE REFLEXIÓN: tómese cinco minutos e intente su mejor respuesta antes de seguir leyendo el próximo párrafo. Anteriormente dijimos que controlar es medir, documentar, comparar, decidir, comunicar y actuar. Por ello, entre los resultados esperados del proceso de control de costos se encuentran: • Los informes de rendimiento y las proyecciones a la finalización del proyecto, información que es entregada a los interesados para que pue- dan interpretar la conducta histórica del proyecto, pero también pronosti- car la futura. Entre la información reportada se encuentran los indicadores de rendimiento SPI y CPI, como así también las proyecciones de costos a la finalización del proyecto. • Las recomendaciones de acciones correctivas, que tienen por objeto volver el proyecto a su cauce, de acuerdo con el plan de proyecto. • Las solicitudes de cambio, que usualmente resultan del análisis de las variaciones detectadas y del desempeño del proyecto. • Las actualizaciones a los planes del proyecto, pues el proceso de control puede arrojar nueva información relevante que debe ser incorporada a los planes existentes. Usualmente se actualizan las estimaciones de costos de las actividades, los presupuestos o línea de base de costos, el plan de gestión de costos y el plan de gestión de proyecto, considerando las soli- citudes de cambios aprobadas. El proceso de control de costos también permite actualizar los activos de los procesos de la organización; de él surgen usualmente algunas lecciones aprendidas, que son documentadas para luego ser incorporadas como información histórica del proyecto y de la organización. El gerente de proyecto debe detectar y anticipar problemas proactivamente, por lo que es responsable, aunque no el único, de recomendar las acciones preven- tivas y correctivas que crea necesarias para asegurar el éxito del proyecto 5.3 OTROS ASPECTOS A RECORDAR Si bien la PMBOK® Guide no hace referencia a algunos de los temas que presentaremos en esta sección del capítulo, su conocimiento es de vital im- portancia para poder responder algunas preguntas del examen de certifica- ción, ya que forman parte de los conceptos y herramientas que todo gerente de proyecto debe conocer, aunque sea a nivel general, para poder tomar decisiones correctas en su proyecto. 5.3.1 Clasificación de los costos A efectos de rendir el examen, es importante que el postulante conozca los diversos tipos de costos que usualmente constituyen la estructura de costos de un proyecto, y que deberá estimar para apoyar la toma de decisiones vin- culadas al proyecto. Para ello, deberá reconocer la diferencia entre ellos. 5.3.1.1 COSTOSFIJOS Son aquellos que no cambian cuando aumenta o disminuye el nivel de pro- ducción. Un ejemplo de este tipo de costo es el canon del alquiler de una fábrica, el cual permanece constante, sin importar la cantidad de bienes que se produzcan. 5.3.1.2 COSTOS VARIABLES Son aquellos que cambian cuando aumenta o disminuye el nivel de produc- ción. Un ejemplo de este tipo de costo es el costo de las materias primas de una fábrica, el cual varía dependiendo de la cantidad de bienes que se produzcan. 5.3.1.3 COSTOS DIRECTOS Son aquellos que se imputan o asignan directamente a un producto o a un proyecto. Un ejemplo de este tipo de costo es el costo salarial del equipo de proyecto o el costo de los insumos utilizados en el proyecto. 5.3.1.4 COSTOSINDIRECTOS Son aquellos que no pueden atribuirse directamente a un producto o a un proyecto, pues son erogaciones que benefician a más de un producto o pro- yecto. Un ejemplo de este tipo de costo es el costo salarial del gerente gene- ral o los impuestos que paga la empresa. 5.3.1.5 COSTOS EVITABLES Son aquellos costos que se producirán solo si se lleva a cabo el proyecto, pero que se pueden evitar si se decide no emprenderlo. Estos son los cos- tos relevantes para tomar la decisión de inversión. Por ejemplo, un cliente está actualmente analizando la posibilidad de llevar a cabo un proyecto de distribución y venta de productos alimenticios, para lo cual deberá comprar dos cámaras frigoríficas. En este caso, la inversión en estos equipos es un costo evitable, pues si lleva a cabo el proyecto deberá asumir un costo para adquirir las cámaras, en tanto que si decide dejar de lado el proyecto no debe incurrir en costo alguno. 5.3.1.6 COSTOS INEVITABLES Son aquellos costos en los que ya se ha incurrido, o en los que se deberá incurrir independientemente de si se lleva a cabo el proyecto o no. Por ello, dado que las erogaciones ya han ocurrido o que ocurrirán de todas maneras, son costos irrelevantes para tomar la decisión de inversión. Entre los costos inevitables se encuentran los costos hundidos (sunk costs). Por ejemplo, el cliente que está analizando el proyecto de distribución y venta de productos alimenticios alquiló hace ocho meses, y por el lapso de 36 meses, un depó- sito que a la fecha se encuentra desocupado. Para llevar a cabo el proyecto, piensa utilizar el depósito e instalar allí las cámaras frigoríficas. En este caso, el costo del alquiler del depósito es un costo inevitable, y por lo tanto irrele- vante para analizar la conveniencia o no de llevar a cabo el proyecto. Esto es así porque, haga o no haga el proyecto, el costo del alquiler deberá pagarse hasta que el contrato vigente termine. 5.3.1.7 COSTOSHUNDIDOS(SUNKCOSTS) Los costos hundidos son incurridos con anterioridad al momento de tomar una decisión, y por lo tanto son irrelevantes. Por esta razón, no deben ser considerados cuando se analiza aquella decisión, pues sea cual sea la adop- tada, el costo ya habrá ocurrido.