Subido por Juan Alberto Avilés

Dirección profesional de proyectos. Guía examen PMP. (Esquembre, J., 2009)

Anuncio
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 ([email protected]). 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.
Descargar