PROJECT MANAGEMENT PRACTICO.J.Eduardo.Caamaño

SAVE OFFLINE

PROJECT MANAGEMENT PRÁCTICO Técnicas, Herramientas y Documentos

J. Eduardo Caamaño, PMP

Primera edición: agosto de 2011 © J. Eduardo Caamaño, PMP Corrección: Lola Aguayo Cruz Cubiertas y diseño de portada: J. Eduardo Caamaño, PMP Fotografías utilizadas en la cubierta: © Shutterstock Images LLC Ilustraciones: Randy Glasbergen ©

Ninguna parte de esta publicación, incluido el diseño de la cubierta, puede ser reproducida, almacenada o transmitida en manera alguna y por ningún medio, ya sea electrónico, químico, mecánico, óptico, de grabación, en internet o de fotocopia, sin permiso previo del editor o del autor. Todos los derechos reservados. www.pmpractico.com

Dedicado a Eleonora, mi esposa y compañera de muchos desafíos. A mis padres (in memoriam), por su importante esfuerzo y paciencia para proprocionarme la mejor formación posible. Desde el lejano año de 1990, he trabajado en ocho diferentes empresas, y tuve la suerte de haber conocido a compañeros y jefes que han tenido la generosidad de compartir sus conocimientos y experiencias, aportando valor a mi trabajo y fortaleciendo mi carrerra profesional. Este libro contempla, de alguna forma, muchas de las enseñanzas que he recibido a lo largo de todos estos años.

INDICE

Prefacio Objetivo y convenciones El PMI y el PMBOK® Terminología Referencias ¿Qué tienes que saber acerca del Project Management? Organización de la obra Capítulo 1 - Introducción Capítulo 2 - El Ciclo de Vida del Proyecto Capítulo 3 - Selección de Proyectos Capítulo 4 - Gestión de la Integración Capítulo 5 - Gestión del Alcance Capítulo 6 - Gestión del Tiempo Capítulo 7 - Gestión de Costes Capítulo 8 - Gestión de la Calidad Capítulo 9 - Gestión de los Recursos Humanos Capítulo 10 - Gestión de las Comunicaciones Capítulo 11 - Gestión de Riesgos Capítulo 12 - Gestión Compras y Contratos Capítulo 13 - Gestión de Conflictos Capítulo 14 - Las Organizaciones Capítulo 15 - El Project Manager Capítulo 16 - 20 Reglas de Oro del Project Management Capítulo 17 - Documentos del Proyecto Apéndice A Apéndice B Apéndice C Apéndice D Apéndice E Bibliografía

Documentos del Proyecto Siete Proyectos que se convertieron en Siete Maravillas Personas Mencionadas Siglas Listado de Técnicas

Prefacio Los prefacios son casi como los proyectos: anticipan una realidad. Pero los proyectos, por su parte, anticipan la lectura de una realidad que todavía no se ha hecho realidad. Los prefacios son, además, una prelectura de una realidad concretizada. De hecho, es posible, y muchas veces también recomendable, leer los prefacios solamente cuando se termina la lectura de una obra. Existen libros sin prefacio, de la misma forma que también existen realidades concebidas y construidas sin proyectos formalmente establecidos. Si te digo la verdad, los prefacios podrían incluso ser descartados. En este caso en concreto, me pondría triste, pues no habría sido posible participar de este más reciente y, por qué no decirlo, proyecto “condenado al éxito” de Eduardo Caamaño. En la vida gerencial, en las administraciones públicas o en las empresas, ya no es posible concebir o construir realidades sin proyectos, sinónimo simultaneo de “sueño”, de descripción en el presente, en realidad a ser construida, de visión o de “vista previa” de una voluntad expresa, de un valor a ser obtenido, en una determinada velocidad, de la búsqueda de una verdad aún no comprobada. Visión, valor, velocidad, verdad, atributos incorporados y un compromiso de todo gerente. Un Project Manager es, ante todo, un gerente. Y un gerente, seguramente, lo reconozca o no, sea consciente o no, es, ante todo, un Project Manager. Hace cuarenta años, Laura Dantas, especialista en desarrollo organizacional, compatriota de Eduardo Caamaño, identificaba categorías de profesionales y académicos que lidiaban con el tema al que ella se dedicó como profesional. Lo tomo prestado y lo adapto para el contexto de proyectos, posibles audiencias para este libro. Habrá los “proyectólogos”, investigadores en la búsqueda de la conceptualización derivada del campo. Habrá los proyectistas, especialistas en búsqueda de soluciones del día a día, puesto que estarán en el campo. Habrá los “proyecteólogos” para los cuales la materia del Project Management es una teología, pues todo lo explica y todo lo puede. Otros, los “proyectoleros”, de los cuales hablar de un tema, entrar y estar “en la ola” del

Project Management es la manera de seguir en el “top de la ola”. ¿A quién recomiendo esta lectura? A los dos primeros tipos de audiencia, puesto que a los dos últimos sería una gran pérdida de tiempo. Joseph Chias, renombrado autor de marketing en España, durante la presentación de uno de sus libros, comentaba que existen formas diferenciadas de abordar un tema en una obra. Las adapto a este libro, diciendo que una de las formas es la académica, destinada al avance de la teoría. La otra forma, la práctica, que ayuda a resolver problemas. La tercera, práctica con base teórica, que sintetiza, en el actor, los elementos esenciales para la acción consciente y consecuente. Los que van a leer esta obra se encuentran en la tercera categoría. Para los que quieren y necesitan saber más para enseñar y practicar, esta obra servirá como un guíon, un consejero en forma de páginas, como un “vademécum” comentado. Instrumental, pero no instrumentalista. Práctico, como los guías de diagnóstico diferencial de los médicos. Pero no confundas esta obra, con sus 184 herramientas y más de 50 modelos de documentos, como un motor de búsqueda, solamente un glosario más en tu librería. Por detrás de los capítulos, de los flujos, de los formularios, existen muchos casos prácticos, “cicatrices” de experiencias, musculatura fortalecida por los años de aplicación de los conceptos de administración, de marketing, de Project Management, en el duro juego de la vida empresarial, que no pocas veces, le hace valer su etimología, deniega el ocio, deniega la reflexión, desdeña el plano, parte para la acción sin mirar las consecuencias. Voluntad sin visión. Velocidad sin verdad. Verdad sin valor. Me siento honrado por la invitación de escribir el prefacio de este primer libro de Eduardo. Reconozco en su letra las palabras y la práctica del autor, cuya carrera profesional llevo siguiendo desde hace años, desde los tiempos en que, todavía en Brasil, fue construyendo (ya proyectando) esta obra. Ya se van seis años. Fue un placer compartir con él algunos proyectos de consultoría; primero con el joven estudiante, luego con el adulto, dedicado colega de trabajo, y más tarde, como competente y fiable socio. Juntos observamos no solamente la realidad de Brasil, sino también la de Cuba y de

México. Te invito a compartir esta experiencia de Eduardo, traducida en libro. Disfrute de la lectura. Aprecie y aprenda, como yo, de la obra del dilecto autor.

Luiz Estevam Lopes Gonçalves Administrador. Maestro en Administración Pública Escuela Brasileña de Administración Pública y de Empresas EBAPE Fundación Getulio Vargas. Actualmente, ocupa el cargo de gerente de Operaciones Internacionales, en la Dirección Internacional de la Fundación Getulio Vargas, donde trabaja desde hace seis años. Fue director executivo de la Interamerican Network for Public Administration Education (INPAE), director del Grupo Consultores Asociados, Superintendente de Mesbla S. A. Trabajó, además, en el departamento de administración y recursos humanos del Citibank y American Field Service en Brasil. Como consultor y profesor, ha actuado en las Américas (Argentina, Chile, Estados Unidos y México) Caribe, Europa (España, Italia y Portugal), África (Angola, Cabo Verde e Guinea-Bissau). Director de proyectos de consultoría y formación en proyectos de planificación estratégica, marketing, investigación de marketing internacional y desarrollo empresarial local. Desde hace 40 años trabaja con proyectos de investigación de marketing como ejecutivo de agencias especializadas brasileñas, (IPOM, AUDI-TV, AUDI-CONSUMO, AUDI-MARKET) y también como consultor independiente, actuando en proyectos realizados en Brasil y en el exterior contratado por empresas privadas, nacionales e internacionales, agencias gubernamentales y organismos internacionales.

Objetivo y convenciones Esta obra pretende recoger los aspectos prácticos de la puesta en marcha de un proyecto. No es, desde luego, un libro donde se recoja toda la teoría acerca del Project Management, puesto que para ello sería necesario hacer una obra de dimensiones tales que no la haría manejable. El mercado dispone, además, de obras inmejorables de autores consagrados acerca de la teoría del Project Management. Por lo tanto, si usted busca una publicación que le auxilie a la hora de preparar la documentación de un proyecto o que le proporcione las herramientas más adecuadas para realizar estimaciones, tomar decisiones importantes o desarrollar su equipo, creo que esta puede ser la obra adecuada. De todas formas, un libro no puede prescindir de la teoría, aunque mi propuesta sea la de proporcionarle un libro práctico, no puedo dejar de introducirle algunos conceptos teóricos sobre las disciplinas que forman parte del Project Management. No obstante, he tenido el cuidado de introducir la teoría mínima necesaria para que usted pudiera familiarizarse con los conceptos más importantes de cada capítulo. El PMI y el PMBOK® El Project Management, traducido al español como Dirección Integrada de Proyectos, es una disciplina ampliamente aplicada en las organizaciones de todo el mundo. Su representante más importante, el PMI (Project Management Institute), es actualmente la mayor organización mundial sin ánimo de lucro, dedicada a desarrollar la disciplina de Dirección Integrada de Proyectos. Su sede central está en Pensilvania y tiene más de 219.000 miembros en 125 países. El PMI desarrolla diversos estándares de Project Management alrededor de todo el mundo. Uno de los más conocidos es el Project Management Body of Knowledge (PMBOK®), que es mundialmente reconocido y está aprobado como un estándar por el American National Standards Institute (ANSI) con más de un millón de copias en circulación. Este libro ha sido estructurado y basado en la metodología difundida por el PMI y sus estándares; en concreto, está basado en la versión IV del PMBOK® (actualmente la última versión).

Terminología Uno de los factores clave del éxito de un proyecto es la comunicación eficaz. Para asegurar una comunicación adecuada es necesario establecer un vocabulario consistente, de conceptos precisos y con una fluidez de lenguaje que permita el entendimiento entre los integrantes de un proyecto. Por tratarse de un estándar americano, he decidido añadir la traducción original en inglés de los términos, herramientas, técnicas y documentos utilizados en Project Management, y que son detenidamente explicados en esta obra. Esto facilitará su búsqueda de nuevas fuentes de investigación en otras obras y en internet. Además, los términos de Project Management son reconocidos mundialmente en inglés por los profesionales del sector. Todos los términos en inglés estarán en letra cursiva y vendrán inmediatamente después de su correspondiente al español. Los términos PMI, PMP, Project Management Profesional y PMBOK® son marcas registradas y pertenecen al Project Management Institute. Referencias Esta obra no pretende traer nada de novedoso. Su objetivo principal es proporcionar al lector una referencia centralizada de las herramientas, las técnicas y los documentos más comúnmente utilizados en el ámbito del Project Management, explicando a fondo cómo se desarrollan y cuál es el momento oportuno de su aplicación Las metodologías citadas a continuación se consideran referencia, principalmente en ámbitos relacionados con el Project Management y estándares de calidad, y en ningún momento esta obra busca con su mención el uso interesado de estas marcas ni manifestar cualquier participación y/o autoría de las mismas. Su mención, por lo tanto, es únicamente formativa, buscando, en todo momento, facilitar a los lectores la comprensión,

adaptación y divulgación de las disciplinas, metodologías, estándares y normas presentes en el ámbito del Project Management. Las metodologías de Project Management y calidad considerados estándares internacionales, y cuyas orientaciones son mencionadas a lo largo de esta obra, son los siguientes: Madurez Máxima en Dirección de Proyectos a Nivel Organizacional (Organizational Project Management Maturity Model - OPM3®): Desarrollado bajo la supervisión del PMI, el OPM3® es una norma diferente de las herramientas o modelos disponibles en la actualidad. El OPM3® funciona sobre la base de un ciclo continuo de optimización del conocimiento, la evaluación y la mejora. Diseñado para que fuera fácil de comprender y usar, es escalable y flexible, y puede personalizarse. Funciona con la mayoría de los programas de calidad existentes, a fin de satisfacer las diversas necesidades y objetivos de la organización. Web: http://opm3online.pmi.org; PRINCE2® (Projects IN Controlled Environments): El PRINCE2® fue originalmente desarrollado por la CCTA (Central Computer and Telecommunications Agency) que, actualmente, forma parte de la Oficina de Comercio Gubernamental del gobierno del Reino Unido (Office of Government Commerce - OCG). Desde 1989, se viene usando como un estándar para la gestión de proyectos, sobre todo en el Reino Unido. Este método fue inicialmente desarrollado solo para proyectos TIC, y su última versión, el PRINCE2®, es compatible con la gestión de todo tipo de proyectos. La revisión más reciente se publicó el 16 de junio de 2009 por la OGC siendo denominada esta versión como PRINCE2® 2009 Refresh. Web: www.prince2.com; Método en V (V-Model - German Project Management Method): Es el estándar utilizado para los proyectos de la Administración Federal de Alemania. Es un método de gestión de proyectos comparable al PRINCE2® y describe tanto métodos para la gestión como para el desarrollo de sistemas. Es, además, una representación gráfica del ciclo de vida del desarrollo de sistemas. En él se resumen las principales medidas que deben adoptarse en relación con las prestaciones correspondientes en el marco del sistema

informático de validación. Es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. Se describen las actividades y los resultados que deben producirse durante el desarrollo del producto. La letra “V” significa "Verificación y Validación". Web: www.vmodell.iabg.de; HERMES: Siguiendo el ejemplo del gobierno británico y el alemán, el gobierno de Suiza ha desarrollado su propio método de gestión de proyectos denominado HERMES, que es una metodología de desarrollo de software basada en el método en V. Su objetivo principal es brindar apoyo a todos los implicados en la planificación del proyecto, desde el comprador, al Project Manager y los colaboradores del mismo. El Método HERMES mejora la transparencia del proyecto, facilita el seguimiento de los avances de los trabajos y permite correcciones más rápidas y específicas. Web: www.hermes.admin.ch; ISO 9000: La ISO 9000 y sus series designan un conjunto de normas sobre calidad y gestión continua de calidad, establecidas por la Organización Internacional para la Estandarización (International Organization for Standardization - ISO). Se pueden aplicar en cualquier tipo de organización o actividad orientada a la producción de bienes o servicios. Las normas recogen tanto el contenido mínimo como las guías y herramientas específicas de implantación o los métodos de auditoría. La ISO 9000 especifica la manera en que una organización opera, sus estándares de calidad, tiempos de entrega y niveles de servicio. Web: www.iso.org; Modelo de Madurez de Capacidades (Capability Maturity Model – CMM®): Es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software por la Carnegie-Mellon University para el SEI (Software Engineering Institute). El SEI es un centro de investigación y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos de América. Web: www.sei.cmu.edu; Six Sigma®: Es una metodología de mejora de procesos que busca reducir y, si posible, eliminar los defectos o fallos en la entrega de un producto o servicio. El objetivo principal del Six Sigma es alcanzar un máximo de 3,4

defectos por un millón de eventos u oportunidades. Esta cifra es conocida como DPMO (Defects Per Million Opportunities), es decir: 6 Sigma = 3.4 DPMO. En la metodología Six Sigma un defecto se entiende como “cualquier evento en que un producto o servicio no logra cumplir los requisitos del cliente”. Existe una escala de sigmas que clasifica su eficiencia: 1 sigma = 690.000 DPMO (30.23% de eficiencia); 2 sigma = 308.000 (DPMO = 69.12% de eficiencia); 3 sigma = 66.800 DPMO (93.33% de eficiencia); 4 sigma = 6.210 DPMO (99.994% de eficiencia); 5 sigma = 230 DPMO (99.99994% de eficiencia); 6 sigma = 3,4 DPMO (99.9999966% de eficiencia). Obtener la cifra de 3,4 defectos en un millón de oportunidades, es una meta muy ambiciosa, y extremadamente difícil de lograr, pero no imposible. Web: www.isssp.com. Todas las demás marcas registradas que se mencionan, usan o citan en la presente obra son propiedad de los respectivos titulares. ¿Qué tienes que saber acerca del Project Management? El Project Management para muchos es un arte. También podemos decir que es una ciencia, una metodología, una disciplina o, incluso, una filosofía. Gestionar un proyecto conlleva, entre otras cosas, aplicar conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para satisfacer sus requisitos. Es un proceso por el cual se planifica, ejecuta y controla, buscando alcanzar los resultados deseados. Un proyecto, por su naturaleza, necesita de una figura central que pueda conducirlo al éxito, gestionar las expectativas de los interesados y proporcionar los medios y los esfuerzos necesarios para que un proyecto finalice acorde con su plan. Es una práctica bastante distinta de las llevadas a cabo por algunas organizaciones que ponen en marcha proyectos sin dueño, o “sin padre”, o con muchos dueños, cuyas responsabilidades no son claras y, a la hora de un posible éxito, todos quieren llevarse los méritos; por otro lado, cuando ocurre lo contrario, no resta nadie para asumir la responsabilidad. La persona que buscamos para asumir todos estos compromisos es el Project Manager, que será el encargado de gestionar toda una serie de procesos y áreas de conocimiento que interaccionan entre sí y tienen grados de

complejidad distintos.

Figura 1: Los elementos del Project Management En las obras publicadas en inglés, los términos Project Manager y Project Management son conceptos muy claros y, por ello, no es frecuente que aparezcan otros términos para definir dichos conceptos. Por otro lado, en las obras escritas o traducidas en español, el Project Manager puede aparecer como “Gerente de Proyectos”, “Gestor de Proyectos”, “Director de Proyectos” o “Administrador de Proyectos”. De la misma forma, el Project Management, a veces, es traducido como “Gerencia de Proyectos”, “Gestión

de Proyectos”, “Dirección Integrada de Proyectos” o “Administración de Proyectos”. Cada uno de estos términos puede tener diferentes matices y/o interpretaciones y, por lo tanto, son muchas veces utilizados sin un criterio correctamente definido. Para evitar confusiones, esta obrará mantendrá los términos originales del inglés de Project Manager y Project Management. Organización de la obra Igual que las distintas fases de un proyecto, los capítulos de este libro son independientes, pero, al mismo tiempo, se enlazan entre sí. El contenido está dividido de esta forma: Capítulo 1 - Introducción: Presenta los conceptos básicos del proyecto, la definición de Project Management y los personajes implicados. Capítulo 2 - Ciclo de vida del proyecto: El ciclo de vida del proyecto es el conjunto de actividades necesarias para alcanzar el objetivo del proyecto. Estas actividades son organizadas o agrupadas en fases para facilitar su gestión. Capítulo 3 - Selección de proyectos: Las organizaciones necesitan adoptar metodologías y/o utilizar técnicas que les permitan elegir los proyectos que puedan aportar los mejores beneficios, por una cuestión principalmente financiera, pero también por una cuestion de preservación de imagen de organización competitiva y, sobre todo, competente. Este capítulo explica las técnicas más utilizadas para elegir los proyectos más adecuados para una organización. Capítulo 4 - Gestión de la integración: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar que los varios elementos del proyecto estén adecuadamente coordinados. Capítulo 5 - Gestión del alcance: Incluye los procesos, técnicas,

herramientas y documentos necesarios para asegurar que el proyecto incluya todo el trabajo necesario, y solamente el necesario, para completar el trabajo con éxito. Capítulo 6 - Gestión del tiempo: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar la planificación y la ejecución del proyecto en un plazo adecuado. Esta área incluye también el levantamiento de las actividades del proyecto (su definición, secuencia y duración estimada). Capítulo 7 - Gestión de costes: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar que el proyecto será ejecutado dentro del presupuesto aceptado. Esta área incluye también las estimaciones de los costes del proyecto, la asignación del presupuesto y el control de los costes. Capítulo 8 - Gestión de la calidad: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar que el proyecto irá satisfacer las necesidades por las cuales fue iniciado. Esta área también incluye la planificación, la garantía y el control de la calidad. Capítulo 9 - Gestión de los recursos humanos: Incluye los procesos, técnicas, herramientas y documentos necesarios para realizar el uso más efectivo de las personas involucradas en el proyecto. Esta área también incluye la planificación organizacional, la formación y el desarrollo del equipo del proyecto. Capítulo 10 - Gestión de las comunicaciones: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar la adecuada generación, diseminación y almacenamiento de las informaciones del proyecto. Esta área también incluye la planificación y la distribución de la información. Capítulo 11 - Gestión de riesgos: Incluye los procesos, técnicas, herramientas y los documentos relacionados con la identificación y

análisis de los riesgos del proyecto. Esta área también incluye la identificación de los riesgos, su cuantificación y establecimiento de medidas preventivas y correctivas. Capítulo 12 - Gestión de compras y contratos: Incluye los procesos, técnicas, herramientas y documentos necesarios para la adquisición de bienes y servicios fuera de la organización ejecutora del proyecto. Esta área también incluye la confección de plan de compras, levantamiento de potenciales proveedores, licitaciones, contratación, administración y cierre de contratos. Capítulo 13 - Gestión de conflictos: Un conflicto ocurre cuando dos situaciones antagónicas no pueden darse simultáneamente. En muchos casos, ambas situaciones presentan importantes ventajas y desventajas, lo que resulta difícil elegir la opción más adecuada. A veces, los conflictos ocurren entre personas influyentes en el proyecto que no admiten que sus intereses sean ignorados. Son situaciones que normalmente repercuten negativamente en el resultado del proyecto. Este capítulo incluye las técnicas más eficientes de la gestión de conflictos. Capítulo 14 - Organizaciones: El tipo de organización dependerá del sector de actuación de la empresa, de los tipos de proyectos que desarrolla y de la complejidad de la empresa. En este capítulo se analizarán los tipos más comunes de organizaciones y su relación con los proyectos; Capítulo 15 - El Project Manager: Cuando un proyecto es puesto en marcha, un equipo profesional empieza a llevar a cabo todas las actividades definidas en el plan. Desde hace no mucho tiempo, este trabajo era realizado de forma descoordinada, ya que cada profesional involucrado desarrollaba su labor de forma independiente, sin la supervisión de una figura central. No había un norte común, lo único que existían eran requisitos sueltos que iban siendo cumplidos sobre la marcha y, con mucha suerte, se encajaban para formar un producto o resultado. Es por esta razón que surge la figura del Project Manager, un profesional

independiente y habilitado para coordinar las actividades y conducir el proyecto a su objetivo planificado. Capítulo 16 - 20 reglas de oro del Project Management: Como he mencionado anteriormente, el Project Management es, para muchos profesionales, un arte. Una búsqueda constante de equilibrio en que el Project Manager será constantemente puesto a prueba, lidiando conflictos, revisando estimaciones y soportando presiones por parte del cliente, de los patrocinadores y sus superiores. Como profesional, el Project Manager debe seguir unas pautas imprescindibles para obtener resultados favorables. Este capítulo trata de aportar algunas “reglas de oro” que no pueden ser ignoradas. Capítulo 17 - Documentos del proyecto: Uno de los factores de éxito de un proyecto es la documentación de su desarrollo, desde la fase inicial hasta el cierre. La documentación es crítica para todo el equipo que desarrolla el proyecto y es fundamental para el cliente. Son muchos los documentos que forman parte de un proyecto y cada uno tiene su importancia acorde con el momento en que es aplicado. Este capítulo presenta la forma adecuada de confeccionar, organizar y gestionar los documentos utilizados en proyectos, desde su fase inicial hasta el cierre. Además, esta obra presenta una serie de Apéndices de relevante contenido: Apéndice A - Documentos del proyecto: Facilita un amplio listado de documentos que componen la documentación básica que un proyecto debe tener, organizada por las fases del ciclo de vida de un proyecto. Cada documento incluye una breve descripción de su uso y objetivos, y además, sugiere los campos mínimos que deberían formar parte de su composición. Apéndice B - Siete proyectos que se convertieron en siete maravillas: En este Apéndice, analizaremos las siete maravillas del mundo antiguo bajo en enfoque del Project Management. Todas estas construcciones, sin lugar a dudas, han pasado por

algún tipo de planificación, se encontraron bajo innumerables riesgos y, de alguna forma, contaba con alguna figura similar al Project Manager, para la dirigir todo el proyecto. Apéndice C - Personas mencionadas: Las personas que aparecen en este Apéndice han sido mencionadas a lo largo de toda esta obra. Todos ellos han contribuido, de alguna forma, en el enriquecimiento y la comprensión de la que ponemos llamar “filosofía del Project Management”. Apéndice D - Siglas: Presenta un listado de las siglas más comúnmente utilizadas en el ámbito del Project Management. Apéndice E - Listado de técnicas: Este apéndice facilita un listado de todas las técnicas presentadas en este libro.

Un poco de teoría…

Capítulo 1 Introducción Capítulo 1 - Introducción

Un viaje de mil millas comienza con el primer paso”

“

Lao Tsé1, filósofo chino

Introducción Eric Verzuh2, en su libro The Fast Forward MBA in Project Management, hace una mención a un texto bíblico que podemos, de alguna forma, relacionarlo con el Project Management. En el Libro de Lucas3, capítulo 14 (28-30), se encuentra el siguiente texto: "Porque ¿quién de vosotros, queriendo edificar una torre, no se sienta primero y calcula los gastos, a ver si tiene lo que necesita para acabarla? No sea que después de que haya puesto el cimiento, y no pueda acabarla, todos los que lo vean comiencen a hacer burla de él, diciendo: «Este hombre comenzó a edificar y no pudo acabar»". Este pasaje bíblico nos demuestra que en aquella época ya había inquietudes muy similares a las que afrontamos hoy en día. Desde tiempos muy remotos, algunas tribus se reunían para construir abrigos y cultivar la tierra, labores que, aunque primitivas, exigían un mínimo de planificación. Desde hace más de cinco mil años, el hombre construye templos monumentales como las pirámides del antiguo Egipto, la gran muralla China o los acueductos romanos, emprendimientos que seguramente contaban con la coordinación de alguna figura muy similar al Project Manager de nuestros días. Es casi seguro que Imhotep4, el primer arquitecto conocido en la historia, responsable de la construcción de la primera gran pirámide, la “pirámide escalonada de Saqqara”, sufrió los problemas típicos de un Project Manager moderno: la pirámide necesitó la extracción, acarreo y montaje de miles de toneladas de piedra; desafío notable, ya que nunca se había usado anteriormente en grandes construcciones. Tuvo que organizar todo el proceso de construcción, controlando el trabajo y a cientos de obreros, y muy probablemente tuvo problemas de plazos y recursos, sin contar la presión ejercida por su patrocinador, el faraón Necherjet5. Fue a partir del siglo XX cuando el Project Management empezó a definir los estándares que conocemos actualmente, principalmente a partir de la década de los 50, durante la guerra fría, donde se desarrollaron proyectos militares de gran complejidad, como fueron los espaciales y de defensa. El proyecto Manhattan, que culminó en la fabricación de la primera bomba atómica de la

historia, es reconocido como el primer proyecto que utiliza técnicas modernas de Project Management. En aquella época, se evidenció la necesidad de coordinar los equipos y las disciplinas diferentes que trabajaban de forma simultánea en un mismo proyecto que requerían el trabajo concurrente y sincronizado. Bernard Schriever6, un general de la fuerza aérea estadounidense que se encargó, durante los años 50 y 60, de competir y ganar la batalla a la Unión Soviética en la construcción de misiles de medio y largo alcance, y de trasladar al espacio la carrera armamentística entre las dos superpotencias, es considerado como uno de los padres del Project Management actual, por haber desarrollado durante la guerra fría el concepto de concurrencia, integrando todos los elementos del plan de desarrollo en un solo programa y presupuesto, ejecutándolos y controlándolos en paralelo y no secuencialmente. De esta forma, logró reducir considerablemente los tiempos de ejecución de los proyectos militares que eran realizados en aquel entonces, como era el proyecto Thor (sistema de armas ideado para disparar proyectiles cinéticos desde la órbita terrestre para dañar objetivos en el suelo). Con el tiempo, estas técnicas y herramientas fueron siendo mejoradas y aplicadas de acuerdo con el tipo de proyecto desarrollado y con cada estructura organizacional. Siguiendo los pasos de la industria militar, la industria automovilística comenzó a aplicar las técnicas del Project Management, con el objetivo de coordinar equipos funcionales diferentes. Comenzaron entonces a surgir las técnicas que conocemos actualmente, como la descomposición de tareas (EDT – Estructura Detallada de Trabajo), los cronogramas y los histogramas. La propia tecnología naturalmente fue colaborando en la optimización y el uso apropiado del Project Management mediante programas informáticos que realizan cálculos y simulaciones y que gestionan una cantidad ingente de documentos de un proyecto. Actualmente, el Project Management ha emergido como una metodología de administración esencial para la organización, sobre todo en las empresas cuyas políticas se enfocan a la planificación y el control de sus actividades. Prácticamente, todos los objetos que forman parte de nuestro día a día, como los móviles, ordenadores, coches, entre otros, son diseñados y desarrollados

bajo las técnicas del Project Management. Los proyectos, además, forman parte de nuestro cotidiano. Es un esfuerzo que tenemos que invertir para generar un resultado que puede ser tanto profesional como personal. Infelizmente, las estadísticas muestran que la gran mayoría de los proyectos termina después del plazo definido, consumiendo mucho más que los presupuestos adjudicados y, en muchos casos, aportando una calidad inferior a la deseada. Algunos proyectos ni siquiera llegan a su fin, son simplemente abandonados porque no llegaban a ningún sitio. Es por estas y otras razones por lo que, desde los egipcios hasta la actualidad, ha sido necesario desarrollar, de alguna manera, una metodología que pudiese integrar todas las necesidades de un emprendimiento, sea cual fuese, de forma que los objetivos pudiesen ser alcanzados satisfactoriamente. 1.1 Las Técnicas y las herramientas La palabra técnica tiene origen del griego τέχνη, y es un conjunto de conocimientos prácticos utilizados para obtener un resultado concreto, en el campo del arte, de la ciencia, de la tecnología o en cualquier otra actividad. El dominio de una determinada técnica requiere una destreza que puede ser manual o intelectual y que, generalmente, depende de la utilización de herramientas. La herramienta, por su parte, es definida por la Real Academia Española como “instrumento, por lo común de hierro o acero, con que trabajan los artesanos”. El origen de la herramienta está íntimamente ligado al origen de la humanidad. Una de las primeras herramientas utilizadas por el hombre fue el mazo, que fue evolucionado a través del tiempo, hasta convertirse en el martillo, tal y como lo conocemos a día de hoy. Han pasado los siglos, el hombre ha evolucionado y, con él, también han evolucionado las herramientas. Ambas, tanto las técnicas como las herramientas, fueron las responsables, mediante el conocimiento del hombre, de las grandes hazañas de la humanidad, desde la construcción de los primeros hogares de la antigüedad, hasta la llegada del hombre a la luna, en 1969. 1.2 La documentación

Uno de los factores de éxito de un proyecto es el desarrollo de una documentación completa y bien estructurada, desde la fase inicial hasta su cierre. La documentación es crítica para todo el equipo que desarrolla el proyecto y fundamental para el cliente. Además, una vez finalizado el proyecto, su documentación será una valiosa fuente de consulta, de donde se podrá extraer informaciones importantes, como las previsiones realizadas a determinadas actividades, planes, estimaciones, etcétera. Son muchos los documentos que forman parte de un proyecto y cada uno tiene su importancia, acorde con el momento que es aplicado. Juntos constituyen una herramienta poderosa, que dará respaldo a todas las acciones realizadas por el Project Manager y su equipo, y se convertirá en una importante base histórica de consulta para futuros proyectos similares. La documentación también sirve para: Referencia para futuros cambios: Aunque el proyecto esté completo y entregado, el cliente podrá solicitar en el futuro un upgrade del proyecto original, añadiendo nuevas funciones o mejoras que, en su momento, no existían. Son casos que suelen ocurrir, por ejemplo, en proyectos tecnológicos. La documentación podrá, por lo tanto, servir como base para la planificación de un nuevo proyecto. Datos históricos para estimaciones de plazos y costes: Proyectos completados con éxito son una excelente fuente de información para proyectos futuros siempre que su documentación esté completa y haya sido desarrollada adecuadamente. La estimación de costes y plazos, por ejemplo, no suele ser una tarea sencilla, y la posibilidad de poder acceder a estimaciones anteriores podrá ser de gran valor para realizar nuevas estimaciones más realistas. Apoyo al Project Managers novatos: La carrera del Project Manager es fundamentada a base de mucho estudio. Un Project Manager es un profesional que se dedica al desarrollo de muchas áreas de conocimiento y la documentación de un proyecto siempre será una excelente fuente de estudio. ¿Cómo se ha desarrollado la

EDT de un determinado proyecto? ¿Cómo se llegó a esta decisión? ¿Por qué ha sido necesario realizar un cambio tan significativo en una fase tan avanzada? Estas, entre otras cuestiones que se encuentren correctamente registradas en la documentación de un proyecto, serán muy útiles a las nuevas generaciones del Project Managers. Apoyo al equipo del proyecto: Como referencia, la documentación del proyecto podrá ayudar al equipo ejecutor a lidiar con situaciones inesperadas. Un problema similar puede haber ocurrido en algún proyecto anterior y su documentación podrá aportar aclaraciones importantes. Referencia para evaluaciones: En muchas organizaciones, se utiliza la documentación para evaluar la performance del Project Manager y de su equipo en proyectos similares. 1.3 Entradas y salidas El PMBOK® basa su metodología de gestión de procesos en entradas, herramientas y salidas. Podemos imaginar cada proceso como si se tratara de una máquina que recoge las entradas (la información recopilada para el proyecto) y la transforma en salidas, a través de herramientas (fórmulas matemáticas, gráficos, estimaciones...). Las salidas darán el soporte necesario para que el proyecto avance sin incidencias (cronogramas, líneas base, estimaciones, planes de contingencia, análisis de riesgo...). Todos los procesos del Project Management basados en la guía PMBOK® poseen entradas, herramientas y salidas. Entradas: Toda y cualquier información recopilada en reuniones, datos históricos, entrevistas, entre otros. Técnicas y herramientas: Procedimientos y recursos utilizados para procesar las entradas recibidas que serán posteriormente transformadas en salidas. Salidas: La documentación o los recursos que serán utilizados para

dar soporte al Project Manager y a su equipo a lo largo del ciclo de vida del proyecto (planes, cronogramas, estimaciones, presupuestos, manuales...).

1.4 ¿Qué es un proyecto? Un proyecto es una actividad que puede desarrollarse tanto en el ámbito personal como en el empresarial. Se trata de un intento de lograr un objetivo específico mediante la ejecución de determinados trabajos previamente planificados, bajo un estricto seguimiento y control de fases interdependientes. Para que un emprendimiento pueda ser considerado un proyecto, debe poseer las siguientes características: Ser un emprendimiento temporario: Un proyecto se caracteriza por tener un comienzo y un fin definidos. Aunque ambas fechas puedan cambiar por razones ajenas, llegará el momento en que el proyecto será iniciado y tendrá que tener su fin formalizado. Normalmente, el final se alcanza cuando se ha logrado el objetivo del proyecto y los interesados acepten, formalmente, su finalización. Sin embargo, en algunos casos, desgraciadamente muy frecuentes, un proyecto puede ser “forzado” a terminar cuando su ejecución no alcanza el resultado esperado, o cuando el proyecto empieza a consumir una cantidad de recursos muy superior a la inicialmente establecida, y la inversión realizada deja de ser viable. La duración de un proyecto puede variar desde unos

pocos días, como, por ejemplo, la reforma de una cocina, o puede llegar a varios años, como fue el caso del proyecto que llevó el hombre a la luna. Además, todo proyecto debe empezar con alguna documentación inicial, que declara el inicio de su ciclo de vida. Tener limitaciones: Los proyectos normalmente cuentan con recursos limitados. Estos pueden ser financieros, de plazo, de personal o de maquinaria. La cantidad de recursos dedicada a un proyecto dependerá, sobre todo, de la capacidad financiera de la organización o de la disponibilidad de los recursos dentro de la organización. Ser realizado por personas: Y son emprendidos en todos los niveles de una organización. Pueden ser desarrollados por una única persona o por todo un departamento. Pueden involucrar a una pequeña oficina o pueden cruzar fronteras afectando a decenas de empresas. Normalmente, el equipo formado para realizar un proyecto raramente se mantiene tras su cierre. La mayoría de los proyectos son ejecutados por un equipo creado con el propósito único de acometerlos, y es disuelto cuando se completa el proyecto. Ser realizado para crear un producto o servicio único: Llevar a cabo un proyecto conlleva hacer algo que no ha sido hecho antes y que no será hecho otra vez (bajo las mismas condiciones) y por esta razón es considerado “único”. Aunque muchos proyectos poseen características muy similares, siempre habrá algún factor que los distinga. Podemos imaginar, por ejemplo, la construcción de una urbanización de diez edificios que tendrán la misma estructura y fachada. La construcción de cada edificio es un proyecto único, aunque todos los edificios sean iguales y estén ubicados sobre el mismo terreno. Eso porque cada edificio podrá ser construido en diferentes épocas: uno en el verano, el otro en el invierno; por personal distinto: unos más eficientes y capacitados que otros, y en diferentes condiciones económicas o financieras, lo que obliga a que la construcción de cada edificio necesite de un plan de proyecto específico.

Ser elaborado de forma progresiva: El concepto de elaboración progresiva es la forma por la cual los proyectos son desarrollados bajo los estándares del Project Management. El plan diseñado para el proyecto es ejecutado paso a paso, progresando a través de incrementos y es realizado cuidadosa y detalladamente. Un proyecto es definido en principio de forma muy genérica y se van incrementando los detalles a medida que el equipo del proyecto desarrolle mejor el entendimiento del servicio o producto resultante. De esta forma, el plan de proyecto recibirá un flujo constante de información renovada y, sobre todo, más precisa y completa. Tener un objetivo definido: Todo proyecto intenta lograr un objetivo final. Para el cliente, lo que realmente importa es que el proyecto diseñado resulte en un producto o servicio cuya calidad cumpla con sus requisitos. Para la empresa ejecutora, el objetivo primario es entregar el proyecto dentro del plazo y presupuesto estimados y que los resultados alcanzados favorezcan su posición en el mercado. Generalmente, el objetivo de un proyecto se define en función del alcance, tiempo y coste. Como ejemplos de proyectos podemos incluir: El desarrollo de un nuevo producto o servicio. La realización de una boda. El diseño de un nuevo avión. La reforma de un local. La construcción de un puente. La implantación de un nuevo sistema de telefonía. La realización de un espectáculo. El rodaje de una nueva película. Todos los proyectos poseen un grado de incertidumbre (o riesgo), que, como se podrá apreciar en el capítulo 11, Gestión de riesgos, pueden ser confrontados, reducidos, transferidos o evitados, todo dependerá de la política de la organización y del estilo de gestión del Project Manager

asignado. Normalmente, el equipo del proyecto realiza una planificación antes de la fase de ejecución del proyecto. Esta planificación es preparada en base de ciertos supuestos y estimaciones, como, por ejemplo, el coste, el tiempo y la disponibilidad de los recursos necesarios para la ejecución del proyecto. Basado en las experiencias de proyectos anteriores se podrá también estimar la probabilidad y el impacto de incidencias que pueden ocurrir durante su ejecución. Conforme avanza el proyecto, si las actividades programadas son ejecutadas sin grandes incidencias, el grado de incertidumbre suele disminuir, puesto que muchas de las suposiciones iniciales serán reemplazadas por hechos reales. Por ejemplo, una vez que se termina la programación del primer módulo de un programa informático, se podrá estimar mejor la cantidad de tiempo y esfuerzos necesarios para iniciar el siguiente módulo. Sin embargo, aunque el grado de incertidumbre sea menor en fases más avanzadas del proyecto, el nivel de riesgo se verá incrementado, ya que el impacto causado por una incidencia importante repercutirá de forma más contundente. NOTA DEL AUTOR Existe un concepto equivocado de que un proyecto es algo muy complejo y de difícil gestión, y por ello se han desarrollado tantas herramientas, técnicas y documentos. Pero, si nos paramos un momento a pensar, estamos, a veces sin darnos cuenta, planificando y ejecutando una serie de pequeños proyectos todos los días, tan sencillos como salir de compras un sábado por la tarde. Para ello, es necesario planificar la hora en la que pretendemos salir de casa, qué medio de transporte utilizaremos, si llevamos el coche, cuál será el recorrido elegido, si hay gasolina suficiente y dónde aparcaremos. Además, para salir de compras un sábado por la tarde, hay que tener en cuenta un presupuesto orientativo de gastos los posibles riesgos implicados en este sencillo paseo vespertino (lluvia, dificultades de aparcar, atascos...). 1.5 ¿Por qué los proyectos fallan? Un estudio realizado por las empresas Gartner Inc en 2002 nos revela que un

proyecto tiene una gran probabilidad de no cumplir satisfactoriamente las estimaciones realizadas. Sus resultados acusan lo siguiente: El 90% de los proyectos ejecutados son entregados con retraso. El 50% son entregados con un presupuesto mayor que el previsto. El 50% no cumple sus objetivos. El 30% son cancelados antes de su conclusión. De acuerdo con uno de los autores más conocidos del Project Management, el doctor. J. Davidson Frame7, los proyectos fallan mayoritariamente por dos razones: a) fallos de estimaciones, y b) fallos en la implementación. Jason Charvart8, autor del libro Project Management Methodologies, nos revela otras de las principales razones de fracaso en los proyectos: El coste y los plazos inicialmente estimados no son revisados. Los planes no son seguidos correctamente. El Project Manager no tiene formación suficiente. El alcance del proyecto cambia sin control. La metodología aplicada no es la correcta. La comunicación es escasa. No se realizan suficientes pruebas. La teoría del Project Management no es aplicada correctamente. 1.6 ¿Qué es el Project Management? La situación que describiré a continuación no es exclusiva del Project Management. Infelizmente, ocurre en muchos ámbitos, como el derecho, la economía o, aún peor, en la medicina. Hay mucha gente que piensa que puede gestionar un proyecto comprando un programa o leyendo un par de libros. El Project Manager es una profesión que, aunque todavía no esté totalmente reconocida en España, tiene un peso importantísimo en EEUU y en varios países de Europa. La profesión de Project Manager exige mucha preparación y, sobre todo, experiencia suficiente para aplicar correctamente sus conocimientos y habilidades a las actividades del proyecto para satisfacer sus requisitos. Es un proceso por el cual se planifica, se ejecuta y se controla, buscando alcanzar los resultados deseados. Es un trabajo que normalmente involucra:

Demandas contrapuestas sobre alcance, tiempo, coste, riesgos y calidad: Como veremos más adelante, un proyecto es un sistema dinámico que tiene que mantenerse constantemente en equilibrio. Gestionar un proyecto es un esfuerzo que conlleva a administrar una serie de actividades integradas. Si una determinada actividad no produce los resultados esperados, podrá afectar a otras áreas del proyecto. Un cambio en el alcance, por ejemplo, casi siempre afectará el coste del proyecto, así como la reducción del plazo de entrega de un producto, y por ello, podrá repercutir negativamente en su calidad. Interesados con diferentes expectativas y necesidades: Los interesados, según explica la sección 1.7, tienen diferentes intereses en el desarrollo de un proyecto y poseen diferentes necesidades y expectativas. La expectativa de un interesado normalmente es subjetiva y, a veces, difícil de satisfacer, puesto que cada individuo posee diferentes niveles de valor. Por esta razón es importante, desde la fase inicial del proyecto, poner las cosas muy claras a los interesados, definiendo correctamente sus requisitos, de forma que sus expectativas se transformen en necesidades identificadas y reales. Planificación, control y organización de las actividades que forman parte del proyecto: Es imprescindible que se realice un seguimiento y un control del proyecto durante su ejecución. Suena demasiado obvio, pero son muchas las organizaciones que nunca han hecho un plan y, en algunos casos, hay empresas que poseen la triste mentalidad de que “hacer un plan es un trabajo añadido innecesario”. Por otro lado, no tiene sentido exagerar en la planificación de un proyecto, si este no lo necesita. La planificación tiene que ser siempre proporcional al tamaño y sobre todo a la complejidad del proyecto. Por ejemplo, un proyecto muy pequeño puede necesitar tan solamente de una buena planificación hecha en Excel, donde se establezcan las líneas bases mínimas necesarias.

1.6.1 Ventajas y factores de éxito del Project Management Podemos decir que un proyecto bien sucedido es aquel que ha sido desarrollado dentro de las expectativas de tiempo, coste y calidad. Además, el cliente debe sentirse satisfecho con el trabajo realizado y/o el producto/servicio entregado. Conforme avancemos, nos daremos cuenta de la cantidad de planificación que implica la puesta en marcha de un proyecto. De hecho, planificar, aunque sea fundamental, no es suficiente para lograr buenos resultados. Para lograr el éxito en los resultados establecidos por la organización, es imprescindible contar también con: La información correcta, completa y actualizada para poder planificar, ejecutar y controlar un proyecto de forma adecuada. La comunicación eficaz, exacta y distribuida a las personas correctas en el tiempo apropiado. El compromiso de las personas involucradas para hacer las cosas bien, evitando conflictos y trabajando en sinergia. Entre los beneficios que nos puede aportar el Project Management podemos destacar: Reducción del ciclo de desarrollo. Reducción de costes. Decisiones más eficaces. Menos improvisación. Cumplimento de plazos. Anticipación de problemas. Creación de un producto/servicio de calidad. Comunicación eficaz. No obstante, históricamente, los proyectos tienen una tasa de éxito muy baja. Cerca del 25% de los proyectos son concluidos con éxito. Es decir, el 75% de los proyectos no logra alcanzar los objetivos establecidos. No obstante, existen algunas reglas básicas que pueden minimizar el riesgo de que un proyecto sea incluido en esta triste estadística:

Tener los objetivos claramente definidos: Incluido el compromiso del equipo para alcanzar todas las metas definidas. Un proyecto necesita planificación: De la misma manera, es imprescindible que se realice un control del proyecto durante su ejecución. Contar con un Project Manager competente: Un profesional que desarrolle esta función debe tener las habilidades inherentes de su puesto, como detalla el capítulo 15, El Project Manager, que es el principal responsable del proyecto. Apoyo de la dirección: Es muy importante que la dirección de la organización sea consciente de la importancia del proyecto y proporcione todos los medios necesarios para asegurar su buen desarrollo. Tener un equipo de proyecto competente: Un proceso de selección bien planificado y la inversión en formación son factores clave para un proyecto bien desarrollado ya que su éxito depende de la buena labor del equipo; Disponibilidad suficiente de recursos: Si existe un factor que puede arruinar un proyecto es la falta de recursos, sean financieros, de personal o de equipos. Antes de empezar, el Project Manager debe asegurarse de que podrá disponer de los recursos suficientes para desarrollar un proyecto. Canales de comunicación adecuados: La información es uno de los factores clave de éxito, que deberá fluir de una forma controlada que alcance a las personas correctas en el momento adecuado. Mecanismos de control: Un proyecto no puede sufrir demasiadas desviaciones que modifiquen la estructura del plan original. El Project Manager debe contar con mecanismos e instrumentos que

le permitan mantener el proyecto dentro de la línea base establecida. Feedback constante: Todos los involucrados en el proyecto deben intercambiar opiniones, sugerencias, experiencias o cualquier otra información que colabore con el avance del proyecto. Reuniones de seguimiento y elaboración de informes deben formar parte de las actividades rutinarias del proyecto. Respuestas inmediatas al cliente: Es fundamental mantener al cliente siempre informado, aunque no se traten de buenas noticias. El cliente puede ser un gran aliado, pero, al mismo tiempo, puede tornarse un gran escollo. Todo dependerá de la relación que el Project Manager mantenga con él. Mecanismos que permitan afrontar los problemas: Todo proyecto necesita de un plan de contingencia (descrito en la sección 11.5.1.3) o cualquier otro mecanismo que permita que el equipo reaccione y aplique la respuesta más adecuada. 1.6.2 ¿Cómo se implementa el Project Management en la organización? Diseminando en toda la organización sus principios y metodologías: Para poder desarrollar de manera eficaz el Project Management en las empresas, es necesario, principalmente, adoptar una cultura volcada en la gestión integrada de proyectos, involucrando y capacitando sus equipos de trabajo y disponiendo de personal cualificado que comprenda y que, ante todo, valore el Project Management. Desarrollando individuos y formando equipos de proyecto: Trabajar utilizando la metodología del Project Management es, sobre todo, trabajar en equipo. Los individuos involucrados en cada proyecto deben trabajar en sinergia, creando resultados que maximicen las cualidades de cada uno de los recursos asignados al proyecto.

Implementando normas y procedimientos: Otro factor importante en el Project Management es disponer de herramientas que puedan soportar de forma adecuada las gestiones desarrolladas por el Project Manager. El mercado dispone de una serie de soluciones a las empresas que permiten aumentar la eficacia de su gestión, integrando los departamentos de la empresa y unificando la información. De este modo, se puede obtener, en minutos en lugar de días, la información necesaria para tomar sus decisiones en función de la situación real de un determinado proyecto, principalmente en lo que conlleva a afrontar un determinado grado de riesgo. NOTA DEL AUTOR El Project Management es un tema que se está volviendo muy difundido por su flexibilidad. Los conceptos de “proyecto” y de “Project Management” pueden ser aplicados en cualquier segmento empresarial, en cualquier industria, y pueden incluso ser utilizadso en el ámbito personal. Una boda, por ejemplo, puede perfectamente ser considerada como un proyecto. Conlleva la gestión de costes, de plazos, de recursos humanos y, sobre todo, la gestión de un cierto grado de riesgo. Todos los proyectos tienen características conceptuales parecidas. Todas ellas poseen, de alguna forma, una fase inicial, una fase de planificación, control, ejecución y una fase de cierre. 1.7 Los stakeholders del proyecto También conocidos como “interesados”, son individuos y/u organizaciones que están involucradas en el proyecto, tienen intereses en su desarrollo y poseen diferentes necesidades y expectativas. El cliente, el Project Manager, el equipo del proyecto y el patrocinador obviamente pertenecen a este grupo. Sin embargo, cualquiera que se vea afectado positiva o negativamente con los resultados producidos por el proyecto es un potencial interesado. No obstante, los interesados más importantes del proyecto son el cliente, que se convertirá en el usuario del servicio y/o producto generado, y el patrocinador, que es el que invierte recursos financieros al proyecto. Sin ellos, el proyecto difícilmente seguirá adelante.

Los interesados pueden ejercer una fuerte influencia en el proyecto. Por esta razón es fundamental: Identificarlos: Cada proyecto está formado por un grupo de interesados distintos, que podrán tener un grado de influencia más importante que en otros. Normalmente, son cinco los interesados clave: el Project Manager, el equipo del proyecto, el patrocinador, la dirección y el cliente. Sin embargo, en algunos proyectos, pueden existir otros interesados importantes, cuya identificación, a veces, no resultará sencilla. La mejor forma de identificar a los interesados de un proyecto es haciéndose la siguiente pregunta: “¿quién contribuye al proyecto?”. Definir sus funciones: El Project Manager, por ejemplo, es la persona responsable de realizar un proyecto, coordinando el equipo y trabajando para que los resultados sean los esperados. El equipo del proyecto realiza el trabajo necesario para que se alcancen los objetivos definidos, y la dirección toma algunas decisiones importantes, generalmente en los momentos más críticos. Otro interesado importante es el patrocinador, que es quien invierte recursos financieros al proyecto y que, a veces, tiene la última palabra acerca de su alcance y de otras variables. Identificar su grado de influencia: El grado de influencia de un interesado normalmente está vinculado a su cargo o posición en el proyecto. Dependiendo del cargo que ocupe, su opinión puede tener una repercusión importante en el proyecto, colaborando para su progreso o, incluso, determinando su cierre. Determinar sus requisitos: En términos del Project Management, los requisitos son condiciones que deben ser satisfechas o que pueden proporcionar a un sistema, servicio o producto, la capacidad de producir un determinado resultado. Garantizar su satisfacción: Se suele decir que “el cliente siempre tiene la razón”, pero el Project Manager tiene un lema distinto:

“Lo que realmente importa es cumplir con las expectativas de los interesados”. El Project Manager debe preocuparse por satisfacer a cada interesado del proyecto, y es importante tener claro que los interesados también pueden aportar mucho en tanto que a ellos les interesa que el proyecto se desarrolle correctamente. Los interesados de un proyecto pueden ser básicamente de dos tipos, internos o externos: 1.7.1 Stakeholders internos La dirección: Los directores de la empresa podrán o no estar directamente involucrados en un proyecto. En grandes proyectos de mucha visibilidad, la dirección suele implicarse con más frecuencia, lo que incrementa la comunicación con el Project Manager y facilita la adquisición de recursos materiales y contratación de personal cualificado. Por otro lado, si el proyecto se desarrolla de forma problemática, sus debilidades estarán muy expuestas, y el soporte inicial de la dirección se volverá en presión que muchas veces será muy perjudicial para el ambiente del proyecto. El Project Manager: Resultaría injusto decir que el Project Manager es el principal interesado del proyecto, porque la verdad es que nadie lo es. La puesta en marcha de un proyecto depende de todos los interesados, ya que cada uno realiza su aportación acorde con el papel que ocupa. No obstante, se puede decir que el Project Manager es el interesado más involucrado, puesto que participa directamente de todo el proyecto, desde la fase inicial hasta su cierre. La organización ejecutante: Es el ámbito donde un proyecto será desarrollado o por lo menos una parte importante de él. Es la organización ejecutante la que provee los medios materiales, tecnológicos, financieros y de recursos humanos para la puesta en marcha del proyecto.

Los integrantes del equipo del proyecto: Son los recursos asignados y quienes trabajaran directamente en el desarrollo de los entregables del proyecto. El equipo de proyecto es normalmente formado por profesionales con diferentes conocimientos, experiencias y habilidades que puedan asegurar la buena ejecución del proyecto. 1.7.2 Stakeholders externos El cliente: Es la persona, grupo de personas o empresas que se beneficiarán directamente del producto o servicio desarrollado por la empresa ejecutante. Generalmente, están altamente involucrados en la planificación y ejecución del proyecto y es quien formalmente acepta o no la entrega de cada fase prevista, hasta que se alcance la totalidad del proyecto contratado. El gobierno: Muchos proyectos son desarrollados con fondos públicos, a través de concursos y/o licitaciones. Además, en algunos sectores, los proyectos son desarrollados de acuerdo con algunas normativas, como es el caso, por ejemplo, de la industria farmacéutica. El Project Manager tendrá que estar atento a ciertas restricciones impuestas por las normativas que afecten a su proyecto. Los proyectos que son resultantes de una licitación pública normalmente tienen todo su alcance, plazos, presupuestos y procedimientos atados a un concurso público, que deberá ser respetado. Los proveedores: Muchos proyectos dependen bastante de los servicios prestados por buenos proveedores, como suele ocurrir, por ejemplo, en los proyectos de construcción: la buena calidad de los materiales (hormigón, ladrillos, parqués...) y de mano de obra (fontaneros, electricistas, encofradores...) son esenciales para que el proyecto cumpla con los requisitos mínimos de calidad. La dependencia no se limita solamente en lo que se refiere a la calidad de los productos y/o a los servicios prestados por los proveedores. Una entrega tardía o temprana de los productos contratados, o un incremento del coste de la mano de obra, podrá comprometer

seriamente el proyecto. Terceros: A veces, una organización no tiene suficiente personal propio para ejecutar los trabajos previstos. Esta situación suele ocurrir en grandes proyectos, como son los del sector de la construcción y de las telecomunicaciones. En este caso, es común contratar mano de obra externa. El Project Manager deberá conocer todas las cláusulas que forman parte del contrato establecido con empresas externas, para que no existan divergencias que comprometan el desarrollo del proyecto. El patrocinador: Todo proyecto tiene un patrocinador. Normalmente, el patrocinador del proyecto es alguien perteneciente a la organización, que identifica la necesidad de poner en marcha un proyecto para lograr un resultado determinado, sea estratégico, financiero o tecnológico. Cuando el proyecto es demandado por un cliente fuera de la organización, el patrocinador ejercerá el rol de interlocutor entre el cliente y la empresa ejecutora del proyecto. En resumen, es la persona que apuesta por el proyecto y que proveerá el soporte necesario para que su inversión alcance los objetivos determinados. También podemos incluir en este grupo a los acreedores, sindicatos, prensa, organizaciones no gubernamentales o la opinión pública, entre otros. Lograr una armonía entre los interesados del proyecto es otro factor de éxito importante y un gran desafío para el Project Manager. Lograr esta armonía es posible si el Project Manager es capaz de incentivar la participación de los interesados, creando un ambiente de colaboración. Se trata de una complicada labor, puesto que, normalmente, los interesados tienen objetivos diferentes que pueden entrar en conflicto. Por ejemplo: El director técnico solicita un cambio en el alcance del proyecto que puede comprometer las fechas planificadas por el equipo técnico para la finalización de alguna fase. El proyecto puede ser afectado por alguna ley que sea aprobada

durante su desarrollo. Un integrante clave del equipo técnico puede dejar la empresa. El cliente puede solicitar un cambio importante en alguno componente del proyecto que comprometa toda la planificación realizada. La participación de los interesados del proyecto debe ser siempre positiva, añadiendo conocimiento y valor al proyecto. Uno de los grandes desafíos del Project Manager es resolver los conflictos que se produzcan durante el proyecto, encontrando la solución apropiada. Algunas de las más importantes estrategias de conflicto son descritas en el capítulo 13 – Gestión de Conflictos. 1.7.3 La gestión de los interesados Es notoria la fuerte influencia que los interesados ejercen sobre un proyecto, ya que algunos de ellos tienen en su poder el control de muchos recursos de la organización, y, por esta razón, el Project Manager deberá ser capaz de administrar eficazmente sus relaciones. Como figuras importantes que son, y además con intereses conflictivos (aunque casi todos desean que el proyecto termine exitosamente), se hace necesario identificar sus expectativas y desarrollar una gestión que permita mantenerlos de nuestro lado, como verdaderos aliados del proyecto, puesto que, en algunos casos, cualquier interesado puede echarlo todo a perder. Su gestión conlleva seguir los siguientes pasos: Identificar quiénes son. Identificar su papel. Identificar el impacto que el proyecto tendrá para los diferentes interesados. Valorar su influencia en el proyecto. Identificar las relaciones entre los interesados y sus objetivos en común.

Una gestión eficaz de los interesados traerá beneficios al proyecto, por ejemplo: Facilitará la toma de decisiones. Mejorará la fluidez de la información y de la comunicación. Incrementará el nivel de satisfacción. Aportará estabilidad al proyecto. Su adecuada gestión podrá realizarse con el auxilio de la primera herramienta de esta obra, presentada a continuación. 1.7.3.1 Técnicas y herramientas 1.7.3.1.1 Matriz poder/interés (Power/interest matrix) Como he dicho anteriormente, existen interesados que controlan los recursos críticos de la organización, así como hay interesados que, incluso, pueden llegar a influenciar directamente en la estabilidad emocional del Project Manager (por ejemplo, la familia). Cada interesado es dotado de un determinado grado de influencia y poder sobre un proyecto. Este grado es medido por la capacidad que cada uno tiene de ejercer una presión sobre otros. La tabla que hay a continuación, llamada de matriz poder/interés y desarrollada por Gerry Johnson9 y Kevan Scholes10, clasifica a los distintos interesados en función de su poder y grado de interés que pueden mostrar en un determinado proyecto. Esta matriz nos puede ayudar a establecer la relación que se debe mantener con cada uno de los interesados.

Como se podrá apreciar en el ejemplo, los interesados del grupo “D” son los que más presión pueden ejercer sobre los demás y, por ello, se hace necesario desarrollar estrategias de negociación y toma de decisiones que nos permitan tener a este grupo involucrado de forma positiva en el proyecto. Por otro lado, el grupo “C” tiene el poder directo de parar de ejecutar sus labores o dejar de suministrar algún producto o servicio necesario para el buen desarrollo del proyecto. Por esta razón, se puede considerar que la organización debe conocer el nivel exacto de interés que muestran los interesados de este grupo, para asegurar una negociación eficaz en el caso de que surja algún tipo de conflicto. 1.7.3.1.2 Diagrama de Venn (Venn´s diagram) El diagrama de Venn recibe este nombre de su creador, John Venn11, matemático y filósofo británico. Estos diagramas son normalmente utilizados en las matemáticas, y son conocidos como “teoría de conjuntos”: diagramas utilizados para ilustrar la relación entre conjuntos, representados por círculos. La forma en que estos círculos se sobreponen entre sí muestra las posibles relaciones lógicas entre los conjuntos que representan. En este caso, utilizaremos este diagrama para representar las relaciones entre los

interesados del proyecto:

Cada conjunto ilustrado en este diagrama representa a un interesado del proyecto. El área donde los círculos se superponen representa el objetivo en común que tienen los interesados que se relacionan directamente. Aunque en casi todos los casos, todos los interesados tienen objetivos en común, muchas veces, durante el desarrollo del proyecto; algunos de estos interesados pueden tener objetivos específicos, muchas veces determinados por la relación directa que mantienen. En el diagrama, el patrocinador no tiene una relación directa con el cliente; sin embargo, tiene objetivos en común con la gerencia y con el Project Manager. 1.7.3.1.3 Matriz de los interesados (Stakeholder´s matrix) La matriz de los interesados es muy similar a la matriz de responsabilidades (descrita en la sección 9.1.1.3) y sirve para determinar la relación entre los interesados y sus funciones en cada fase del proyecto. La naturaleza y el alcance de cada fase asignarán la función de cada interesado.

Figura 5: Matriz de participación de los principales interesados

Capítulo 2 El ciclo de vida del proyecto Capítulo 2 - El Ciclo de Vida del Proyecto

“A menudo, quienes vacilan en hacer planes es porque dudan también en su capacidad de cumplir” Michael Levine12, escritor estadounidense

Introducción Todos los proyectos tienen un fin vinculado a la obtención de un resultado, que puede ser un producto o un servicio, generado a través de la ejecución de una serie de actividades previamente planificadas. Algunas de estas actividades se agrupan en fases para facilitar su gestión. Al conjunto de estas fases se le denomina “ciclo de vida”. El ciclo de vida de un proyecto contiene cuatro elementos básicos que serán profundizados a continuación: Fases. Actividades. Entregables. Procesos. 2.1 El ciclo de vida del proyecto Como he comentado anteriormente, los proyectos son un emprendimiento único que conlleva un cierto grado de incertidumbre y riesgo. Por esta razón, normalmente, un proyecto es dividido en fases puntuales para tornar su control más efectivo. A este conjunto de fases le llamaremos, tal y como he dicho antes, “ciclo de vida del proyecto”. El ciclo de vida representa el progreso lineal de un proyecto, desde la fase inicial hasta su cierre, como ilustra la figura 6:

Figura 6: Estructura de la gestión de proyectos 2.1.1 Características del ciclo de vida del proyecto El ciclo de vida también define el comienzo y el fin de un proyecto. Además, determina las acciones posteriores a su conclusión, es decir, que es útil para vincular el proyecto con las operaciones continuas de la organización. Las descripciones del ciclo de vida del proyecto pueden ser muy generales o muy detalladas. Cuanto más detalladas, mejor estructuradas estarán documentalmente, proporcionando al proyecto una importante base documental donde se guardaran los trabajos realizados y sus resultados.

Figura 7: Influencias durante los procesos de un proyecto Normalmente, el ciclo de vida de un proyecto posee las siguientes características: El coste y el personal involucrado son bajos al comienzo, aumentan según avanza el proyecto y caen súbitamente cuando el proyecto se aproxima de su cierre. Cuando un proyecto se encuentra en su fase inicial, la probabilidad en completarlo con éxito es muy baja y, por lo tanto, el riesgo y la incertidumbre son altos. Conforme el proyecto avanza, la probabilidad de terminar con éxito aumenta progresivamente. Los interesados en el proyecto ejercen mucha influencia en el comienzo del proyecto. Su poder de influencia disminuye progresivamente a medida que el proyecto avanza.

Aunque muchos ciclos de vida contengan elementos y fases similares, pocos son idénticos. Algunos proyectos presentan cuatro o cinco fases, otros pueden llegar a presentar más de diez fases. Todo dependerá del sector empresarial donde el proyecto es desarrollado, la forma en que la organización ejecuta sus proyectos o cómo serán las características del producto o servicio que será entregado. Sin embargo, todos los ciclos de vida tienen una cosa en común: todos tienen una fase inicial, una fase final y, por lo menos, una fase intermediaria. Una fase es concluida cuando se terminan los trabajos necesarios para llevar a cabo la obtención de uno o más entregables. Un entregable es el producto o servicio resultante del trabajo realizado durante una determina fase, como, por ejemplo, la colocación del pavimento en una obra es el resultado de una de las fases de construcción de un edificio. Cuando se finaliza una fase, es recomendable revisar todo el trabajo realizado y evaluar los resultados obtenidos, sobre todo en lo que se refiere al cumplimiento del plazo y el uso de los recursos financieros y humanos. Esta evaluación será útil para asegurar el buen rendimiento en la siguiente fase de ejecución del proyecto. Normalmente, los entregables de la fase precedente son aprobados antes del comienzo de la siguiente. Existen proyectos en los que las fases se superponen, es decir, que una fase puede iniciar antes de que termine la precedente. De todas formas, la evaluación general del proyecto entre sus fases o en los periodos de transición es importante para su buen desarrollo. Dividir un proyecto por fases conlleva los siguientes beneficios: Permiten controlar mejor el avance de todo el proyecto. Disminuye su complejidad. Reducen la incertidumbre y el nivel de riesgo. 2.1.2 La triple restricción del proyecto Un proyecto es un sistema dinámico que tiene que mantenerse constantemente en equilibrio. Gestionar un proyecto es un esfuerzo que conlleva administrar una serie de actividades integradas. Si una determinada

actividad no produce los resultados esperados, podrá afectar a otras áreas del proyecto. El cambio del alcance casi siempre afectará el coste del proyecto, así como la reducción del plazo de entrega de un producto, podrá repercutir negativamente en su calidad. El Project Management busca resolver estas interacciones de forma activa. En esta materia se menciona con mucha frecuencia la triple restricción del proyecto (Project Triple Constraint), que representa la interacción entre el alcance, el plazo y el coste en la forma de un triángulo:

Figura 8: La triple restricción del proyecto Alcance: El término “alcance” representa el trabajo necesario para producir exactamente los requisitos establecidos por el cliente. En el desarrollo del proyecto es muy probable que el cliente solicite alguna modificación en relación al alcance original, lo que, normalmente, se traduce en añadirle más requisitos, que podrán provocar un incremento en los costes y en los plazos de entrega del proyecto. Tiempo: Es la duración prevista para completar el proyecto. De acuerdo con un estudio realizado por las empresas Gartner Inc, el 90% de los proyectos ejecutados son entregados con retraso, lo que nos lleva a pensar que el plazo es una variable muy difícil de estimar y extremadamente complicada de cumplir, por ello se hace necesario dedicar un tiempo importante de planificación y control.

Coste: El 50% de los proyectos son entregados con un presupuesto mayor que el previsto, según el mismo estudio realizado por las empresas Gartner. Esto ocurre normalmente porque no se ha tenido en cuenta una serie de costes internos, externos, fijos y variables que un proyecto puede contemplar. Es importante resaltar que, durante todo el desarrollo del proyecto, el Project Manager tendrá el desafío de mantener la triple restricción del proyecto equilibrada constantemente. Si el cliente decide cambiar una de las restricciones, las otras dos, seguramente, serán afectadas. Equilibrar este triángulo es una de las claves para obtener los resultados esperados de un proyecto. La búsqueda de este equilibrio está en saber priorizar el elemento más importante del proyecto, y eso dependerá, sobre todo, de la organización que lo gestiona, del propio Project Manager, de los patrocinadores y de las características del proyecto. Decidir es una labor constante para el Project Manager. En muchos casos, las decisiones serán tomadas atendiendo a las prioridades de la triple restricción del proyecto. Si el cliente establece una fecha determinada como prioridad, el Project Manager intentará hacer lo posible para que esta fecha sea respectada, reduciendo, por ejemplo, el alcance del proyecto, muchas veces comprometiendo su calidad. Para garantizar la entrega del proyecto en la fecha determinada por el cliente, esta acción probablemente incrementará el coste. Teóricamente, parece sencillo, pero, en la práctica, puede representar un serio problema al Project Manager. Priorizar uno de los componentes de la triple restricción casi siempre provoca un impacto negativo en los demás componentes. Estos cambios de prioridad muchas veces no son planificados y casi siempre conllevan serios problemas. NOTA DEL AUTOR Para acabar este apartado, presentaré una anécdota que encontré en cierta ocasión en internet, sobre un ejecutivo que estaba obsesionado en reducir los

costes de los proyectos en detrimento de su calidad. Se cuenta una historia de un gerente que, no pudiendo aprovechar sus entradas para un concierto donde se escucharía la sinfonía inconclusa de Franz Schubert, se las entregó al director financiero de su empresa, que era famoso por su agresiva postura de reducción de costes; una obsesión que muchas veces causaba problemas en la ejecución de algunos proyectos llevados a cabo por la empresa donde trabajaba. El lunes siguiente, el gerente recibió del director financiero el siguiente informe: Tras asistir atentamente la sinfonía inconclusa de Franz Schubert, si tuviera la oportunidad, recomendaría los siguientes puntos al director de la orquesta: Durante lapsos considerables, los cuatro músicos que tocaban oboe no tenían nada que hacer. Ellos podrían ser eliminados y su trabajo dividido entre toda la orquesta. Cuarenta violines tocando notas idénticas. Esto me parece una duplicación innecesaria, y esa parte de la orquesta debería ser drásticamente reducida. Para obtener mayor volumen de sonido, podrían ser usados amplificadores electrónicos. Fue absorbido mucho esfuerzo en la ejecución de bemoles y sostenidos. Esto parece un refinamiento excesivo, recomiendo que todas las notas sean redondeadas a la próxima nota simple. Si esto se hiciera, sería posible usar becarios y operadores no especializados. No veo ninguna finalidad práctica en la repetición por los metales de los mismos pasajes que ya fueron ejecutados por las cuerdas. Si todos estos pasajes redundantes fuesen eliminados, el concierto podría reducirse a veinte minutos. Según este análisis, puedo afirmar que si el compositor Franz Schubert hubiera conocido la reingeniería, definitivamente habría podido concluir su sinfonía y ser más eficiente en el uso de la orquesta y el tiempo.

Por suerte, esta historia es ficticia, pero todos los días son ejecutados centenares de proyectos con presupuestos muy reducidos, que, ciertamente, culminarán en un resultado de muy baja calidad. Es por esta razón que existen edificios que se desploman en la primera tormenta, programas que no funcionan y negocios que no prosperan. Recuerde: Uno de los factores de éxito en el Project Management es el equilibrio. 2.1.3 Las líneas base de un proyecto Las líneas base de un proyecto son un conjunto de fechas de inicio y fin, duraciones de trabajo planificadas y los costes previstos durante la fase inicial del proyecto. Se trata de una “fotografía” del proyecto en el momento en que se realizaron las primeras estimaciones. Además, representan el plan original aprobado por los interesados. Estas informaciones serán la referencia principal por donde se realizarán las mediciones y eventuales desviaciones que se produzcan a lo largo del ciclo de vida del proyecto. Un seguimiento correcto de las líneas base permitirá al Project Manager poner en marcha acciones preventivas o correctivas que posibiliten poner en proyecto otra vez dentro de la línea base original establecida. Conforme el proyecto avance, las líneas base serán contrastadas con la situación actual del proyecto, que proveerá las desviaciones reales en función de los planes establecidos. Estas comparaciones son realizadas en momentos puntuales del proyecto, normalmente durante la finalización de una fase o en el momento en que el proyecto alcance uno de sus hitos. Sin embargo, forma parte de las buenas prácticas verificar la evolución de la línea base en las reuniones que se celebran con los integrantes del equipo ejecutor. Un proyecto cuenta normalmente con tres líneas base, que son las de alcance, coste y plazo. La línea base del alcance (scope baseline): Representa la suma de todos los entregables del proyecto. Además, refleja todo el trabajo

necesario para concluir un proyecto. Es representada por la EDT (descrita en la sección 5.3). La línea base del plazo (schedule baseline): Determina el tiempo total necesario para desarrollar todos los entregables definidos en la línea base del alcance. Puede ser representada por el cronograma del proyecto (descrito en la sección 6.5). La línea base del coste (cost baseline): Es el presupuesto del proyecto (descrito en la sección 7.2). Representa la inversión monetaria total necesaria para desarrollar todos los entregables definidos en la línea base del alcance. La línea base del coste no incluye un eventual presupuesto de contingencia o cualquier otra reserva monetaria. La línea base del alcance es normalmente la primera en ser desarrollada; luego se suceden las líneas base de plazo y coste. A partir de entonces, el proyecto ya cuenta con una línea base general definida. En algunos casos puede existir una limitación importante de tiempo y recursos financieros. Cuando esto ocurre, se establecen primero las líneas base de coste y plazo, y a continuación se define la línea base de alcance en función de los recursos disponibles.

Figura 9: La línea base de un proyecto Cualquiera de las líneas base del proyecto pueden sufrir modificaciones conforme el proyecto avanza. Toda vez que se introduzcan cambios, la línea base anterior es abandonada y toda la monitorización será realizada en función de la nueva línea base. Siempre que se produzcan cambios en una de las líneas base del proyecto, las otras líneas deberán ser reajustadas. De todas formas, aunque se abandonen las líneas bases anteriores, es importante comparar las desviaciones producidas durante el desarrollo del proyecto. Para diseñar una línea base es importante disponer, principalmente, de los siguientes dados: Las estimaciones de coste del proyecto, desglosados por fase o por actividades, desde la fase inicial hasta el cierre del proyecto. El cronograma original del proyecto, desglosado por fases o por actividades. También se pueden diseñas líneas base del consumo de recursos disponibles para el proyecto (materia prima, instalaciones, maquinaria, equipos, personal, entre otros). 2.2 Los procesos y fases de un proyecto Como los proyectos suelen tener un grado de incertidumbre muy alto, se hace necesario organizarlo en fases para que, de esta forma, sea posible administrar mejor su evolución, reducir la incertidumbre y, por consiguiente, los riesgos involucrados. Una fase es un conjunto de actividades relacionadas con el objetivo de obtener un resultado previamente esperado. Cada proyecto, dependiendo de su naturaleza y complejidad, tendrá sus fases divididas y organizadas de forma que mejor permita su gestión. Sin embargo, para desarrollar una administración eficaz, es importante realizar, en cada fase, cuatro procesos básicos imprescindibles: inicio, planificación, ejecución/control y cierre.

Inicio: Se inicia tras la asignación del Project Manager a través del acta de constitución del proyecto (Project Charter, descrito en el apéndice A, doc nº 001). El inicio del proyecto es la primera etapa de su ciclo de vida e incluye las primeras actividades tras la aprobación formal del proyecto. En este proceso, se definen los objetivos, el alcance, las propuestas y los entregables que serán producidos. Planificación: Es un proceso muy importante y, desafortunadamente, muy despreciado por las empresas. Es el momento donde se realizan las estimaciones del proyecto, se confecciona el plan de proyecto (Project Management Plan, descrito en el apéndice A, doc nº 003) y se define su estrategia de ejecución, además de los procedimientos de control. Existen organizaciones que suelen fundir este proceso con el anterior, lo que no es aconsejable. Ejecución/control: Es el proceso que pone en marcha todo lo planificado anteriormente. Normalmente, el 90% de los recursos son consumidos en esta fase, que termina cuando el objetivo del proyecto ha sido completamente alcanzado. Cierre: Suele ser el proceso más corto del proyecto y, sin embargo, uno de los más importantes. En esta etapa, el producto o servicio desarrollado es puesto en marcha, el cliente realiza las pruebas de aceptación y, una vez comprobado que los requisitos establecidos se cumplen, el proyecto es formalmente finalizado, lo que suele suceder mediante la firma de una aceptación formal (Formal Aceptance, descrito en el apéndice A, doc nº 050).

Si trasladamos estos conceptos a un proyecto personal, como, por ejemplo, las vacaciones de verano, podremos observar cómo estos procesos marcan de forma muy clara el ciclo de vida de un proyecto: Inicio: Se determinan cuántos días de vacaciones disponemos, qué tipo de vacaciones queremos organizar (playa, montaña...), qué distancia pretendemos recurrir y la cantidad de dinero que podemos invertir. Además, se buscan informaciones acerca de la ciudad, las tarifas de los hoteles, la disponibilidad de vuelos o la ruta y las distancias que deberán ser recorridas en el caso de viajes de coche. Planificación: En función de los resultados obtenidos, se determinan la duración de las vacaciones, la asignación un presupuesto y los recorridos realizados, acorde con el calendario previsto. Ejecución/control: Empiezan las vacaciones. Si el traslado es realizado en avión, se tratará de llegar puntualmente al local de embarque. Si viajamos de coche, intentaremos cumplir la ruta en los tiempos planificados. En la ciudad, disfrutaremos del hotel y de las atracciones de las que la ciudad ofrece. Si surgen incidencias

(el hotel no satisface las exigencias mínimas, el coche sufre alguna avería, el vuelo ha sido cancelado...), se ponen en marcha las acciones correctivas correspondientes. Cierre: La vuelta a casa. Se guardarán las fotos y los recuerdos del viaje y se pagarán las facturas referentes a las reservas, compras y dietas realizadas durante las vacaciones. Para proyectos pequeños, estos procesos representan toda la vida del proyecto. No obstante, en proyectos muy grandes, podrán repetirse en cada fase de su ciclo de vida, según se ha ilustrado en la figura 11.

Figura 11: Fases y procesos de un proyecto No existe un proceso más importante, aunque uno consuma más tiempo y recursos que otro. Cada proceso tiene su importancia y el proyecto depende del buen desarrollo de cada uno para alcanzar sus objetivos. Si un proceso no es bien realizado, seguramente el siguiente sufrirá sus efectos negativos, y así será sucesivamente, provocando daños que podrán ser irreparables.

Figura 12 – Ciclo de vida representativo de un proyecto de desarrollo de software Organizar un proyecto en fases nos puede aportar una serie de beneficios, entre ellos: Facilita el control del proyecto: Al dividir el proyecto por fases, se permite al Project Manager y al equipo tener un enfoque más restrictivo. De esta forma, el control del proyecto se vuelve más sencillo, ya que todas las atenciones están volcadas a la fase que se está desarrollando. Disminuye la complejidad del proyecto: Proyectos complejos, como son los de la construcción, suelen contener muchas actividades e involucrar a grandes equipos, y por ello, su administración pude ser muy complicada. Mediante la organización de un proyecto por fases, su gestión se torna más sencilla, puesto que las metas estarán enfocadas al término de la fase en curso, no del proyecto como un todo. Reduce la incertidumbre: La falta de información es la principal razón del aumento de la probabilidad de riesgo en un proyecto.

Realizando una gestión de proyectos por fases, se dedica una atención especial a los riesgos específicos de la fase que se está ejecutando, facilitando su supervisión y control. 2.2.1 Inicio Es el proceso de autorizar formalmente un nuevo proyecto. Generalmente, los proyectos son autorizados como resultado de una o más de las siguientes causas: Una demanda de mercado: Una empresa de informática autoriza un proyecto para desarrollar un sistema de gestión para un segmento de mercado que todavía no cuenta con una herramienta eficaz. Una necesidad de negocio: Una organización autoriza un proyecto para poner en marcha la creación de una nueva unidad de negocio para la obtención de nuevos clientes. Requisito del cliente: Una constructora autoriza un proyecto para construir una urbanización de viviendas en la zona vieja de la ciudad. Un avance tecnológico: El gobierno autoriza un proyecto para el desarrollo de un satélite que pueda monitorizar la sequía que compromete el ecosistema de una determinada región. Una necesidad legal: Un establecimiento comercial autoriza un proyecto para implantar unos procedimientos exigidos por una nueva ley que les afecta directamente. Una necesidad social: Una organización no gubernamental autoriza un proyecto para desarrollar una forma alternativa de suministrar energía eléctrica a pueblos muy aislados de un determinado país. Aunque esta fase parezca la más “corta” de un proyecto, no podemos

subestimarla, dado que, en esta fase, se asientan las bases fundamentales de un proyecto, como, por ejemplo: Las necesidades y requisitos del cliente. Los objetivos del proyecto. Las restricciones y supuestos. Los contratos y presupuestos. Los hitos. La identificación de los interesados. La asignación del Project Manager y su equipo. Esta es, además, la fase donde el riesgo se encuentra en su nivel más alto, ya que son muchas las incertidumbres, y la organización cuenta con muy poca información. Es una fase en que también se produce un elevado número de cambios. Existen varias formas de empezar un proyecto. La más correcta es mediante la publicación del acta de constitución del proyecto (project charter). Se trata básicamente del primer documento desarrollado para un proyecto ya aprobado y que formaliza su inicio e identifica los grupos de interés, el equipo que se encargará de su desarrollo. Pero, sobre todo, es el documento que concederá autoridad al Project Manager para desempeñar sus funciones. Las instrucciones de cómo confeccionar el acta de constitución del proyecto están descritas en el apéndice A, doc nº 001. Además del acta de constitución del proyecto, es importante empezar desde esta fase la identificación de las restricciones y supuestos del proyecto. Las restricciones suelen limitar las opciones del Project Manager y de su equipo, pero, por otro lado, son importantes para determinar hasta dónde se puede llegar. Los supuestos, por su lado, reflejarán la disponibilidad del equipo adjudicado, las fechas de comienzo de actividades, las cláusulas contractuales, entre otros. Los supuestos son importantes, pues dan el norte al proyecto. Si no se formalizan, el proyecto no empezará, o si llega a empezar, evolucionará sin un rumbo claramente definido. El concepto más amplio de restricciones y supuestos está descrito a continuación: Las restricciones del proyecto

Una restricción es un factor que impone un determinado límite al desarrollo de una determinada actividad. Las restricciones tradicionales de un proyecto son las siguientes: De coste: Un proyecto puede ser cancelado por falta de recursos económicos que le permitan seguir adelante, ya que su puesta en marcha depende de múltiples variables financieras, como, por ejemplo, los costes de mano de obra, materiales o infraestructuras. De tiempo: En algunos casos, el plazo es la principal restricción de un proyecto. En la década de los 90, muchas empresas de software tuvieron que afrontar el problema del año 2000, más conocido como el “Efecto 2000” o “Year 2000 Problem - Y2K”. Sus aplicaciones informáticas corrían el riesgo de parar de funcionar si no se implantasen las correcciones adecuadas. Bancos, empresas de telefonía y multinacionales de grande porte invirtieron millones de dólares para evitar que ocurriese una “catástrofe electrónica”, que felizmente no llegó a ocurrir. Fueron realizados proyectos cuyo límite era el milenio que se acercaba. El año 2000 no podría ser postergado. De alcance: Son los requisitos del proyecto. Un proyecto se considera finalizado cuando el resultado alcanzado corresponde a los requisitos especificados por el cliente. Un proyecto puede tener otras restricciones importantes: Tecnológicas: Durante toda la historia de la humanidad, muchos científicos lograron descubrir inventos que tuvieron que esperar años, y muchas veces siglos, para ser puestos en marcha, simplemente porque no existía la tecnología necesaria para realizarlos. La genialidad de Leonardo Da Vinci97 le llevó a diseñar una infinidad de aparatos ingeniosos, desde instrumentos científicos hasta maquinas voladoras. El helicóptero de Da Vinci97 fue diseñado en el siglo XV, que, lógicamente, por limitaciones tecnológicas no pudo ser puesto en práctica hasta comienzos del

XX, quinientos años más tarde. De recursos humanos: Disponer del equipo adecuado en el momento oportuno. Desafortunadamente, esta regla es muy difícil de lograr. Una empresa puede disponer recursos financieros y tecnológicos para desarrollar el proyecto que se proponga; no obstante, si no dispone de los recursos humanos adecuados, pocas serán las posibilidades de éxito. Muchos proyectos son puestos en marcha con equipos incompletos, tanto en cantidad como en calidad, y la consecuencia de esta debilidad se refleja en los resultados obtenidos. Legales, burocráticas y políticas: Son restricciones que están directamente asociadas a la organización ejecutante del proyecto o al país donde el proyecto será desarrollado. Las mayores dificultades en la realización de un proyecto provienen de legislaciones específicas. Los proyectos de construcción de centrales hidroeléctricas, por ejemplo, dependen de un amplio estudio de impacto ambiental que puede llevar años para ser realizado. La burocracia de algunos países que exigen una infinidad de licencias y permisos para la ejecución del proyecto o algunas cuestiones políticas son también restricciones importantes que pueden impedir que un proyecto sea desarrollado sin percances. Culturales: Algunos proyectos pueden sufrir cambios en su diseño, por determinadas razones culturales, sobre todo en lo referente a la percepción de la calidad. Es decir, satisfacer las necesidades y expectativas de los clientes, que pueden ser diferentes, dependiendo de la región en que se desarrolla el proyecto. Para solventar este tipo de restricción, se realizan estudios de percepción de calidad, que constituyen un elemento fundamental para comprender la forma por la cual un determinado cliente reacciona delante de un nuevo producto o servicio. Organizacionales: La forma en que una empresa aprovecha sus recursos humanos, su política de compras, gastos e inversiones y su política interna.

Será el conjunto de objetivos y restricciones que definirá las primeras estrategias y el primer borrador del plan de proyecto. Los supuestos del proyecto El término “supuesto” en el ámbito del Project Management se refiere a los factores que son considerados verdaderos para realizar una planificación o estimación coherente, sin que sea necesario demostrar su fiabilidad. Por ejemplo: “Los componentes importados desde China vendrán con sus manuales escritos en inglés”; “Cuando termine la fase de diseño, tendremos cuatro ingenieros disponibles full time”; “En la segunda quincena de septiembre, el 50% de las pruebas estarán realizadas”. Es importante que estos supuestos sean acordados y documentados. Normalmente, los supuestos de un proyecto son plasmados en el acta del proyecto (Project Charter, véase también apéndice A, doc nº 001) o en el plan de proyecto (Project Management Plan, apéndice A, véase doc nº 003). Estos supuestos forman parte de la elaboración progresiva de la planificación del proyecto y por poseer un cierto grado de incertidumbre, conllevan a un cierto grado de riesgo. Es importante contar con especialistas para realizar estos supuestos, para, de esta forma, minimizar riesgos eventuales. Una vez considerados verdaderos, serán tomados en cuenta a la hora de confeccionar cronogramas y otros documentos del proyecto. NOTA DEL AUTOR Hay casos en que algunos Project Managers menos experimentados simplemente ignoran la fase inicial del proyecto. Se trata de un fallo importante que, seguramente, les cobrará factura más adelante. Un proyecto

no debería comenzar sin una fase inicial formalizada con un mínimo de datos que, a posteriori, alimentarán de forma más concreta la fase de planificación. La fase de inicio es la adecuada para realizar una primera toma de datos que serán más refinados y fiables, según avance el proyecto. Es de suma importancia que los objetivos sean claramente definidos en esta fase, aunque sufran cambios más adelante. Lo importante es partir de algún objetivo concreto que sea, sobre todo, realizable. Además, es fundamental definir las restricciones del proyecto. Una restricción es un factor que puede imponer un límite importante al desarrollo de un proyecto, pudiendo, inclusive, culminar en su cancelación. 2.2.1.1 Reunión de apertura del proyecto (Kickoff meeting) La reunión de apertura del proyecto, también conocida como Kickoff Meeting, es el momento oportuno de reunir al cliente, al equipo del proyecto y a los interesados para declarar formalmente el comienzo del proyecto y asegurarse de que todos los involucrados conocen sus funciones y responsabilidades. Como ocurre en cualquier reunión formal, es importante tener una agenda y divulgar el acta de constitución del proyecto. Esta agenda debe incluir, por lo menos, los puntos que se expresan a continuación: Motivos por los que el proyecto será llevado a cabo. Presentación de las especificaciones del proyecto. Presentación del equipo del proyecto. Presentación del cronograma del proyecto. Apuntar las actividades previstas para la próxima reunión. La reunión de apertura es una oportunidad única de empezar bien el proyecto. Formalizando todos los puntos anteriores, el Project Manager podrá asegurarse de que todos los involucrados son conscientes de los compromisos asumidos y de las expectativas del proyecto. Por esta razón, esta reunión debe ser bien preparada y organizada. Es importante transmitir seguridad y una buena impresión a los involucrados.

En el caso de no ser posible reunir a todos los involucrados en el proyecto, como mínimo es importante garantizar la asistencia de los más importantes. Toda la información recogida en esta reunión deberá formar parte de la documentación del proyecto que será distribuida posteriormente. La duración de esta reunión es proporcional a la complejidad del proyecto. De la misma forma que una reunión de apertura puede llevar algunas horas, en algunos casos puede necesitar de uno o más días. 2.2.2 Planificación La planificación funciona como una especie de mapa que nos aporta las instrucciones y orientaciones para que podamos llegar con éxito a un determinado lugar y es un proceso que es desarrollado durante todo el ciclo de vida del proyecto. Aunque todos los procesos son importantes, planificar es fundamental. Sin embargo, en muchas ocasiones, es el proceso más olvidado por las personas que desarrollan la ejecución de un proyecto. Hay casos, desafortunadamente muy frecuentes, en que existe la necesidad de empezar repentinamente un proyecto para cubrir una necesidad puntual y, cuando esto ocurre, el proceso de planificación a veces se reduce simplemente a confeccionar un cronograma. Planificar significa mucho más que confeccionar una sencilla tabla orientativa de fechas, que, aislada, no sirve para mucho. Un Project Manager que no sea capaz de realizar junto con su equipo una buena planificación, pasará una buena parte del proyecto “apagando fuegos”. La mala costumbre de no planificar ocurre con frecuencia en las organizaciones. Normalmente, las personas saltan de la fase de inicio (cuando esta existe) a la fase de ejecución sin antes dedicar un solo momento a la planificación. Es decir, que, en algunos casos, la organización ya empieza un proyecto, ejecutándolo, de forma totalmente irresponsable e inconsecuente. La mentalidad que a veces se aprecia es: “Si ya hemos hecho proyectos similares a este, ¿por qué tenemos que planificarlo todo otra vez?”. Como he

comentado anteriormente, a pesar de que la empresa haya realizado un proyecto muy similar en ocasiones anteriores, algunos elementos o circunstancias seguramente habrán cambiado y toda la planificación anterior no podrá ser totalmente aprovechada.

Figura 13: Ciclo de planificación de un proyecto 2.2.2.1 Relación entre los procesos La planificación es un proceso que tiene una interacción muy importante con el proceso de seguimiento y control, puesto que ambos se alimentan mutuamente de los resultados obtenidos durante el proceso de ejecución. Cuando se detecta una desviación en la ejecución del proyecto, se planificará otra vez las actividades correspondientes para mantenerlo bajo control.

Figura 14: Relación entre los procesos de planificación y control Planificar aporta una serie de beneficios, entre ellos: Reduce la incertidumbre: Una planificación adecuada permitirá el desarrollo de medidas preventivas y correctivas para que los resultados esperados sean alcanzados. Aumenta el entendimiento: Planificar aporta al equipo la información necesaria para que se entienda el proyecto de forma clara y objetiva. Produce eficiencia: Una vez definido el plan de proyecto y los recursos necesarios para llevarlo a cabo, se podrá organizar el trabajo de forma optimizada de manera que, al final, se pueda terminar el proyecto en el plazo, dentro del presupuesto estimado y utilizando los recursos de forma adecuada. Hay casos en que es posible, incluso, terminar un proyecto antes del plazo, consumiendo menos recursos que los originalmente asignados y, lo más importante, sin afectar su calidad. Es interesante cómo en muchas empresas las personas se quejan de que no hay tiempo para planificar, pero cuando las cosas salen mal, hay que buscar tiempo adicional para rehacer todo el trabajo no planificado. Planificar incluye, como mínimo, el alcance, el coste, el plazo, los recursos y los riesgos involucrados. En relación al alcance, es necesario desglosar las fases del proyecto en componentes más pequeños y manejables, de forma en que se pueda visualizar la dimensión total del trabajo involucrado. Con este nivel de detalle disponible, será más fácil estimar la cantidad de dinero que será invertido en cada componente, su tiempo de duración y los recursos necesarios para desarrollarlo. Una forma de hacer este desglose de forma eficaz es a través del uso de una herramienta llamada “Estructura Detallada del Trabajo – EDT” (WBS - Work Breakdown Structure), que descompone los trabajos establecidos para un proyecto, organizando y definiendo su alcance total (esta herramienta es descrita en detalle en la sección 5.3). Todas estas informaciones deberán estar reunidas en el plan de proyecto

(Project Management Plan, descrito en el apéndice A, doc nº 003). Este documento servirá como una especie de “mapa” que orientará a los involucrados desde el comienzo hasta el final del proyecto. NOTA DEL AUTOR Algunos Project Managers suelen ser demasiado optimistas en el momento de planificar. Existe una tendencia en pensar que las cosas saldrán perfectas, que los plazos serán respetados, que difícilmente algún factor exterior influirá negativamente en el proyecto y que no habrá espacio para el surgimiento de conflictos. Este tipo de razonamiento tan solo conllevará al fracaso del proyecto, sobre todo cuando empiecen a surgir los primeros problemas. Como consecuencia, todas las estimaciones positivas empezarán a desmontarse en una especie de “efecto dominó”, que conllevará a un ambiente bastante desfavorable. Para evitar caer en este tipo de errores, es importante que el Project Manager intente realizar una previsión de los posibles resultados de un proyecto en distintos escenarios, normalmente en un escenario optimista y otro pesimista. Estos escenarios ayudarán al Project Manager a definir una línea base. Si acaso algún evento tienda a dislocarse a un escenario más pesimista, el Project Manager podrá contar con alguna reserva de emergencia. Esta reserva podrá ser financiera, de plazos o de recursos y será estimada acorde con los resultados de proyectos similares y, sobre todo, a través de la experiencia y juicio de expertos.

Figura 15: Línea base x reserva Es importante tener en cuenta que la planificación no es un evento aislado que ocurre entre el inicio del proyecto y su ejecución. Es una actividad que debe ser realizada constantemente. Planificar no es crear un plan al comienzo del proyecto y, después, dejarlo archivado en algún sitio para “echarle un vistazo” de vez en cuando. Se trata de una documentación de apoyo importante que debe ser actualizada constantemente. 2.2.2.2 ¿Cómo puedo estar seguro de que he planificado lo suficiente? Está claro que no existe una forma sencilla de saberlo. Lo que se intenta hacer es planificar lo máximo posible para reducir el nivel de incertidumbre y poder tener más control sobre el proyecto. La pregunta entonces sería: “¿Cuánta planificación necesito?”, y la respuesta podrá encontrarse tras el análisis de los siguientes factores: La complejidad del proyecto: La regla es sencilla. El nivel de planificación es proporcional a la complejidad del proyecto. El tamaño del proyecto: Proyectos muy grandes requieren un esfuerzo importante de coordinación, ya que contienen una cantidad ingente de informaciones que pueden perderse fácilmente si no se realiza un control intensivo sobre ellas. Este tipo de proyecto debe tener una planificación formal y muy bien definida.

El nivel de incertidumbre: Cuando el nivel de incertidumbre es alto, es común que se desarrollen planes muy elaborados utilizando técnicas sofisticadas. Esta práctica no suele obtener buenos resultados, porque si el nivel de incertidumbre es alto, el Project Manager no dispondrá de suficientes informaciones que le permitan desarrollar planes precisos. Además, con escasa información acerca del futuro, cualquier plan que se elabore sufrirá varias modificaciones a lo largo del proyecto, hasta que se alcance un nivel de incertidumbre gestionable. Es importante confeccionar un plan equilibrado, acorde con la información disponible. Cuanto más complejo y largo sea el proyecto, más planificación será necesaria para mantenerlo bajo control. Los proyectos más pequeños y más simples tienen un margen de riesgo más pequeño. De todas formas, todo es una cuestión de sentido común. Como normalmente no se puede estar pendiente constantemente de la evolución de un proyecto en conjunto, es importante determinar las fases clave y los hitos más importantes y estar atento a sus resultados. Los hitos, también conocidos como milestones, son puntos utilizados en el cronograma que, normalmente, señalizan un evento importante del proyecto, la conclusión de una determinada actividad, decisión o fase. 2.2.2.3 Las estimaciones Según Tom DeMarco13, “Una estimación es una predicción que tiene la misma probabilidad de estar por encima o por debajo del valor actual”. Una estimación, por definición, busca determinar un resultado cuantitativo aproximado. Para que un proyecto pueda ejecutarse dentro del plan establecido, es muy importante saber la duración de las actividades, cuánto costará desarrollarlas y qué recursos serán necesarios para llevarlas a cabo. Para ello, es fundamental realizar buenas estimaciones. De lo contrario, el proyecto se tornará un “agujero negro”, absorviendo todo lo que encuentra, sin proporcionar los resultados esperados. Sin embargo, realizar estimaciones no es una tarea nada fácil, todo lo contrario. En el comienzo del proyecto, si no fuesen identificados todos los entregables, algunos interesados pueden cambiar algún punto en concreto y, generalmente, el tiempo para realizar

estimaciones suele ser muy limitado. Para poder contar con una estimación realista, es necesario contar básicamente con dos factores: Experiencia del equipo y de expertos: Se trata de un recurso importante para realizar estimaciones más o menos precisas. Esta colaboración puede venir tanto de un especialista como de un grupo de personas con mucha experiencia y formación especializada. Entre ellos, podemos incluir consultores veteranos, integrantes del equipo del proyecto, proveedores especializados... La documentación de proyectos anteriores similares: Un proyecto debe disponer de una documentación completa en la que figuren todas las gestiones, planes, estimaciones y cualquier otro registro que el Project Manager considere relevantes. Una documentación bien estructurada servirá de soporte en la comunicación entre los integrantes del equipo, provee de soporte a los departamentos involucrados y servirá en el futuro como una base histórica fiable de consulta. NOTA DEL AUTOR Existe un detalle importante que puede afectar a los resultados de las estimaciones de un proyecto: el carácter del equipo, de los interesados y del propio Project Manager. Hay casos en que existe una cierta tendencia pesimista u optimista que influye a la hora de estimar costes y plazos. Un proyecto puede tener estimaciones de plazo muy optimistas que serán difíciles de cumplir, como puede también tener estimaciones pesimistas que necesitarán de una reserva financiera importante, que podrá dificultar eventuales aprobaciones para su puesta en marcha. Además, como las estimaciones normalmente cruzan datos de plazo y coste, hay un margen enorme de arruinar cualquier plan. En estimaciones demasiado optimistas, los plazos son reducidos y no se incrementan los costes, cuando, normalmente, los costes aumentan cuando los plazos son

acortados. Las estimaciones normalmente fallan Uno de los factores de fracaso más comunes en el proyecto son las actividades “subestimadas”, que conllevan a un incremento importante de presupuesto y a un incumplimiento del cronograma. Esto ocurre normalmente por las siguientes razones: Demasiado optimismo por parte de las personas involucradas. No se tienen en cuenta el tiempo consumido por reuniones o las tareas administrativas, entre otros factores. No se prevén posibles bajas laborales. No se tienen en cuenta los días festivos, vacaciones o periodos estivales. No se realizan consultas a las lecciones aprendidas de proyectos anteriores similares. En algunos casos, el equipo no conoce totalmente el alcance del proyecto. Falta de experiencia por parte del Project Manager, del líder técnico o del propio equipo. 2.2.3 Ejecución Es la fase en que se pone en marcha todo el plan de proyecto. En este momento, el Project Manager estará monitorizando el desarrollo de las actividades planificadas y establecidas en las fases anteriores. Durante esta fase, el equipo estará plenamente dedicado al desarrollo del proyecto. Es también la fase donde la comunicación deberá fluir constantemente. Además, en esta fase es importante realizar reuniones de seguimiento para recopilar informaciones sobre su progreso. En este momento, el Project Manager conducirá el proyecto estrictamente acorde con el plan. Si acaso, por algún motivo, el resultado producido no es el esperado, el equipo deberá documentar todas las incidencias para que se puedan realizar las oportunas valoraciones y estudiar posibles cambios y/o acciones correctivas.

2.2.4 Seguimiento y control Controlar es una palabra que muchas veces nos lleva a pensar en autoritarismo. No obstante, cuando hablamos del Project Management, controlar no es sinónimo de ser autoritario. Se trata de verificar si el equipo está haciendo bien las cosas y cumpliendo con el plan. Simplemente consiste en mantener el proyecto dentro de su curso. Haciendo una analogía, es como un conductor que está en una carretera y por un despiste, sale de su carril, pero corrige su trayectoria y luego vuelve a estar centrado en su recorrido. Básicamente, el control del proyecto se resume en analizar los resultados y las variaciones de la ejecución de los trabajos y asegurarse de que sus objetivos están siendo cumplidos. Además, se realizan las mediciones necesarias que puedan identificar posibles variaciones con respecto al plan y, consecuentemente, tomar las acciones correctivas adecuadas o, lo que sería lo mejor, las acciones preventivas para anticiparse a posibles problemas. Por ejemplo, si una fecha de conclusión de una actividad se acerca, pero todavía está lejos de terminar, el Project Manager deberá incluir horas extra, aumentar el número de recursos dedicados a la actividad o, si es posible, reajustar el cronograma del proyecto. La mejor manera de hacer una medición adecuada es observar la evolución de una actividad en su detalle. Es decir, si una determinada actividad necesita de diez acciones, se medirá la conclusión de cada acción por separado. De esta forma, se obtendrá el porcentaje del trabajo realizado en esta actividad. Haciendo una simple analogía, un Project Manager no puede observar la evolución de un bosque en conjunto. Es necesario acompañar el desarrollo de cada árbol, teniendo en cuenta que la debilidad de un árbol puede afectar el crecimiento de los demás, comprometiendo así el desarrollo de todo el bosque. La esencia del Project Management es la búsqueda constante del equilibrio. No se puede adoptar una postura de negligencia de cara al control de un proyecto, pero tampoco el Project Manager tiene que llevar la gestión al nivel de una obsesión. Estar soportado por una buena documentación y, sobre todo, escuchar la

palabra de expertos y de personas con experiencia en la gestión de proyectos similares también son factores que contribuirán para el control eficaz del proyecto. Existen algunas acciones que, realizadas de forma adecuada, contribuirán positivamente en un control efectivo del proyecto: Reconfirmar el plan de proyecto: Antes de empezar una fase importante, es elemental revisar con los miembros del equipo si los trabajos propuestos todavía son posibles de ponerse en marcha de la forma en que establece el plan de proyecto. Registrar toda la información relevante: Durante la fase ejecución, es muy importante que el equipo registre todas las informaciones que consideren útiles para el proyecto en curso y/o para proyectos futuros similares, como, por ejemplo, resultado de pruebas, fechas reales de comienzo y conclusión de las tareas del proyecto y el número de horas consumidas en cada tarea. Los resultados colectados serán confrontados con los resultados previstos en el plan. Realizar acciones correctivas: Siempre que se comparan los resultados obtenidos con los previstos se obtendrán informaciones que darán al Project Manager la oportunidad de poder, en tiempo, realizar acciones correctivas que eviten que el proyecto pierda su dirección. Mantener al equipo informado: La comunicación es otro factor crucial en el control del proyecto. Mantener al equipo informado, a través reuniones de seguimiento e informes de estado, aportará seguridad a todos e incrementará la coordinación entre los involucrados. 2.2.5 Cierre El cierre es un proceso que básicamente asegura que todas las actividades que forman parte del proyecto han sido correctamente finalizadas. Normalmente,

esta fase exige una aceptación escrita del cliente formalizando la correcta recepción de todos los entregables previstos en el proyecto. Todos los proyectos tienen que llegar a la fase de cierre. Es verdad que, en algunos casos, un proyecto termina de forma abrupta y prematura, y eso suele ocurrir cuando las cosas no han salido bien y se decide terminarlo antes que se produzca un desastre. No obstante, cuando se decide por la puesta en marcha de un proyecto, se espera que este finalice acorde con el plan establecido, con todas las actividades desarrolladas, y los productos y servicios producidos entregados correctamente al cliente. Tan importante como empezar bien un proyecto es terminarlo de forma adecuada. Normalmente, el equipo del proyecto está muy motivado en hacer las cosas bien cuando se empieza un nuevo proyecto, sin embargo, la motivación no es la misma en su cierre. El desgaste provocado por los problemas y conflictos ocurridos o las perspectivas generadas hacia nuevos proyectos son algunas de las causas que perjudican su buen cierre. En ocasiones muy frecuentes, el equipo es disuelto inmediatamente tras su conclusión. Cuando esto ocurre, se pierde una valiosa oportunidad de recoger información sobre las lecciones aprendidas, las conclusiones y las recomendaciones al equipo que dará posteriormente soporte al proyecto. Incluso, en los proyectos en que no se hayan producido los resultados esperados, se pueden recoger informaciones que ayudarán a evitar que se produzcan los mismos errores en un emprendimiento similar. En la fase de cierre se realiza, además, una evaluación general de los trabajos realizados, suministrando información que servirá de consulta para la planificación y la ejecución de proyectos futuros. Esta información es almacenada en un documento llamado Libro de Notas del Proyecto (Project Notebook, descrito en el apéndice A, doc nº 053) 2.2.5.1 Entrega de todos los productos y/o servicios del proyecto Documentación: La documentación muchas veces es vista como un simple papeleo burocrático, dado el tiempo que se invierte en dejarla actualizada conforme el proyecto avanza. Realmente,

mantener la documentación de un proyecto es un esfuerzo importante, además de todo el trabajo que implica ejecutar un proyecto acorde con su plan. Sin embargo, en muchas ocasiones, el equipo o el Project Manager echan de menos la documentación de un proyecto anterior cuando están buscando alguna solución para un problema determinado. Toda la documentación confeccionada durante el proyecto debe tener un fin acordado por todos los interesados. Basado en este acuerdo, algunos documentos serán archivados en carpetas y otros son destruidos. Mucha documentación servirá como base para proyectos futuros. Además, es importante respectar el contenido confidencial de los documentos. Cierre de los contratos: Normalmente, un proyecto es estructurado en función de varios contratos entre los interesados (proveedores, clientes, socios...). Como parte importante del proceso de cierre, es fundamental realizar una revisión final en los contratos acordados, con el fin de certificar que no existen puntos pendientes. Igual que los contratos, es importante realizar esta misma revisión en el plan de proyecto y en las actas de reunión. Además, es elemental consultar el departamento financiero la eventual existencia de facturas no pagadas. Aceptaciones: Es el cliente quien decide si el proyecto ha terminado y es el Project Manager quien deberá demostrar que el producto o servicio contratado ha sido entregado dentro de las especificaciones solicitadas. Es importante obtener todas las aprobaciones pendientes, siempre de forma escrita. Normalmente, todas estas aceptaciones culminan con una aceptación final, que confirma que no existe ningún trabajo pendiente que deba ser realizado. En algunos casos, el cliente aceptará el final del proyecto tras realizar algunas verificaciones puntuales a través de pruebas. Se suelen crear listas de verificación (checklists, descrita en la sección 8.3.1.5) que irán a pautar los puntos en que el producto no puede fallar. El resultado de esta lista de verificación determinará la aceptación final del proyecto.

Cierre Formal del Proyecto: Todos los proyectos deben contar con un cierre formal que deberá estar reflejado en el cronograma del proyecto. El Project Manager, los representantes del equipo, los patrocinadores, los clientes y otros grupos de interés deberán fijar una reunión que formalmente cierre el proyecto. La agenda de esta reunión deberá describir principalmente: Un breve resumen histórico del proyecto. Los objetivos cumplidos y no cumplidos. Los beneficios del proyecto para el cliente. Las lecciones aprendidas. Además, es importante asumir el éxito o el fracaso de un proyecto. Muchas veces es evidente que un proyecto ha sido concluido de forma exitosa o no. En algunos casos, puede que algo haya ocurrido de forma no planificada y, como consecuencia, que se produzca algún factor que perjudique el proyecto. Por ejemplo, un programa puede haber sido entregado en la fecha planificada, pero algunos pueden haber sido entregados con fallos importantes. Los resultados de éxito o fracaso de un proyecto serán muy útiles como “lecciones aprendidas”, que aportarán valiosos conocimientos para futuros proyectos. Es de responsabilidad del Project Manager formalizar el cierre de las fases, contratos, cobros y toda la documentación del proyecto. Estas gestiones deben ser realizadas en el tiempo oportuno, antes de que el equipo sea deshecho y reasignado a otros proyectos. Es importante también divulgar a toda organización el cierre formal del proyecto. El equipo será oficialmente disuelto para ser asignado a nuevos proyectos y, a la vez, los departamentos de compras, contabilidad y administración realizarán las gestiones correspondientes al cierre final. La documentación generada desde el inicio deberá ser debidamente archivada para eventuales consultas. 2.3 Las actividades del proyecto

Una actividad es un componente del proyecto que, organizado de forma integrada con otras actividades, forma el trabajo total para la realización de un proyecto. Una actividad tiene un identificador propio, un tiempo de ejecución estimado, un coste presupuestado y un pool de recursos asignados. 2.4 Los entregables del proyecto Todos los proyectos culminan en un resultado concreto. Este resultado puede ser un producto, un servicio o la combinación de ambos. Los elementos individualmente generados en cada fase del proyecto son conocidos como “entregables”. Existen dos tipos de entregables: internos y externos. Los entregables internos son aquellos producidos para auxiliar el avance del propio proyecto. Normalmente, son los resultados de una actividad que son necesarios para poder empezar la actividad siguiente (por ejemplo, la producción de un diseño es necesaria para poder montar un prototipo). Los entregables externos son aquellos que serán entregados a algún interesado externo del proyecto (el cliente, el usuario final, el patrocinador, entre otros.) Los entregables externos deben ser claramente definidos por los interesados, que serán los encargados en su aprobación en el momento de la entrega. 2.4.1 La lista de entregables del proyecto Es muy importante, antes de definir el alcance del proyecto, conocer cuáles serán exactamente los entregables que este proyecto generará. Muchos proyectos invierten mal sus recursos en entregables que no aportarán lo que realmente el cliente necesita. Esto se traduce en un desperdicio de tiempo y dinero, además de provocar una mala sensación. Para evitar esta situación, se confecciona una lista de entregables. Su procedimiento de desarrollo es muy sencillo y resulta bastante eficaz. Una de las formas más sencillas de definir los entregables de un proyecto es a través de la organización de una reunión entre todos los interesados del proyecto y cada uno de ellos escribirá en una hoja de papel cuáles son sus deseos en relación al proyecto que se desarrollará. Esta “lista de deseos” es

libre y muchas veces será muy extensa, lo que ya demuestra cómo muchos proyectos empiezan con una sobrecarga de entregables innecesaria. Cada interesado entrega su hoja y, utilizando el sentido común, se van eliminando todos los deseos innecesarios. Es importante registrar la justificativa por la cual el deseo fue eliminado. Un listado de deseos rechazados y sus justificativas correspondientes podrán ser utilizados en proyectos futuros. Los artículos que no fueron eliminados dejarán de ser deseos y ganaran el estatus de “entregables potenciales”. A partir de este momento, estos entregables potenciales pertenecerán a una lista de requisitos del proyecto, donde se realizará un análisis todavía más riguroso. Una vez realizado este filtro final, la lista de requisitos, ampliamente justificada y detallada, formará parte de la línea base de alcance (que será la EDT, descrita en la sección 5.3) y, partir de ahí, se empezarán a desarrollar las líneas base de tiempo y coste del proyecto. En un proyecto pequeño, este filtro podrá ser realizado por todos los interesados presentes. En proyectos grandes, normalmente se forma una junta para realizar esta gestión. Esta técnica corresponde a un grupo de técnicas ampliamente explicada en el proceso de definición del alcance, sección 5.2, del capítulo 5. 2.5 Caso Práctico Cuando hablamos del Project Management, lo primero que nos viene a la mente son los grandes proyectos tecnológicos, o de ingeniería. Como he comentado al principio, un proyecto posee características bien definidas que pueden encajar perfectamente tanto en emprendimientos profesionales como personales. Por esta razón, terminaremos este capítulo utilizando los conceptos anteriormente explicados (actividades, fases, procesos y entregables) en un proyecto personal muy importante: la realización de una boda. De esta forma, podremos visualizar de una forma muy sencilla dos cosas: cómo estos conceptos se aplican en la práctica y cómo un proyecto personal puede perfectamente ser administrado utilizando las técnicas del

Project Management. La boda de Jacobo y Marta Jacobo y Marta se van a casar en verano, precisamente en el mes de septiembre. Quieren disfrutar de las agradables temperaturas del final de la estación y aprovechar las ofertas de viaje que por estas épocas suelen ser menos concurridas que en los meses de julio y agosto. Ambos saben que la celebración de una boda conlleva a la administración de una serie de factores que incluyen, entre otras cosas: Un presupuesto. Una fecha que no puede ser aplazada. La contratación de profesionales que actuarán de forma coordinada en el día de la celebración de su boda. Como es natural, los novios tienen un alto grado de expectativa en relación a este evento que, sin duda, es inolvidable en la vida de cualquiera. Para ello, contrataron el personal que formará el equipo (fotógrafo, florista, imprenta, músicos...), a través de recomendaciones muy fiables. Además, ambos tuvieron el cuidado de planificarlo todo con mucha antelación. A partir de esta introducción, empezaremos a definir el conjunto de actividades, fases y procesos que fueron conceptualmente explicados anteriormente y organizarlos en el proyecto de la boda de Jacobo y Marta: La lista de actividades 1. Planificación y definición de la fechas. 2. Búsqueda, acuerdos y contratación de la iglesia. 3. Búsqueda, acuerdos y contratación del florista. 4. Búsqueda, acuerdos y contratación de los músicos. 5. Búsqueda, acuerdos y contratación de la imprenta. 6. Búsqueda, acuerdos y contratación del modista. 7. Búsqueda, acuerdos y contratación del fotógrafo.

8. Búsqueda, acuerdos y contratación del restaurante. 9. Búsqueda, acuerdos y contratación del viaje de luna de miel. 10. Búsqueda, acuerdos y contratación del alquiler de un coche. 11. Preparación de la lista de invitados. 12. Envío de las invitaciones. 13. Primera prueba del vestido. 14. Segunda prueba del vestido. 15. Tercera prueba del vestido. 16. Primera prueba del traje. 17. Segunda prueba del traje. 18. Llamadas de confirmación a los profesionales contratados. 19. Ejecución de la boda. 20. Celebración en el restaurante. Podríamos tener, por lo tanto, las siguientes fases: 1. Búsqueda y contratación de profesionales. 2. Pruebas de indumentaria. 3. Gestión de invitaciones. 4. Llamadas de seguimiento y verificación. 5. Realización de la boda. 6. Celebración final. Fases y personal implicado (interesados)

Distribución de las actividades en las fases

… ¡Y ahora vamos a la práctica!

Capítulo 3 Selección de proyectos Capítulo 3 - Selección de Proyectos

“El requisito del éxito es la prontitud en las decisiones” Francis Bacon14, filósofo inglés

Algunas cosas en las que NO puedes pensar acerca de la selección de proyectos “Somos capaces de asumir cualquier proyecto sin restricciones”. No existe una empresa, país o persona que pueda contar con una capacidad ilimitada de recursos. Las empresas que gestionan proyectos deben tener en cuenta su capacidad operacional y asumir los proyectos cuya demanda de recursos sea compatible con su capacidad. “Aunque no lo parezca, nuestro equipo está capacitado para trabajar en muchos proyectos a la vez”. Esta afirmación tiene una relación directa con la anterior. Todas las empresas cuentan con una capacidad limitada de recursos y, por ello, debería asumir un número máximo de proyectos simultáneos que les permita ejecutarlos sin incidencias. La gestión de los recursos humanos en los proyectos puede ser fácilmente desarrollada mediante el uso de calendarios (descritos en la sección 9.4.1.7), que son definidos a través de los cronogramas del proyecto. En los calendarios se definen los días y el horario que cada integrante del equipo estará dedicado a cada proyecto en que haya sido asignado. Además, un Project Manager no debe asumir muchos proyectos a la vez o su capacidad de administrarlos se verá comprometida. “No piensen mucho. El mejor proyecto es aquel que nos aportará más ingresos”. La selección de un determinado proyecto incluye una serie de diferentes variables y, en muchos casos, la variable financiera no es la más importante. Existen proyectos que no generan ganancias, pero sí pueden aportar una visibilidad a la empresa en su sector de actuación. En realidad, el mejor proyecto es aquel que satisface la necesidad inmediata de la empresa ejecutante. “Quien tiene que decidir qué proyectos vamos a trabajar es la dirección”

La puesta en marcha de un proyecto dependerá de la decisión de una serie de interesados que se basarán en los resultados obtenidos de las técnicas presentadas en este capítulo. “Para elegir un proyecto, nada mejor que la intuición”. Es cierto que la intuición puede llegar a ser útil, sobre todo cuando la toma de decisiones se realiza bajo un alto nivel de incertidumbre y presión para llegar a la decisión correcta. Sin embargo, la intuición no puede ser el único recurso disponible. En el artículo intitulado “Don´t trust your gut” (No confíe en su intuición), publicado en la revista Harvard Business Review, su autor, Eric Bonabeau15, nos hace la siguiente reflexión: “La confianza en la intuición es comprensible. Ante la confusión terrenal, la gente pone su fe en fuerzas místicas. Esto es peligroso. La intuición tiene su lugar en la toma de decisiones -no se debe ignorar el instinto así como no se ignora la conciencia-, pero quien piense que puede reemplazar la razón arriesga a engañarse. Alejada de un análisis riguroso, la intuición es una guía insegura e inestable, puede llevar tanto al éxito como al fracaso. Cuanto más numerosas sean las opciones, mayores los datos por ponderar y más imprevistos los desafíos por enfrentar, menos deberá utilizarse la intuición y más el razonamiento y el análisis”. Introducción Un proyecto normalmente es fruto de una necesidad. Todo comienza cuando una persona, un departamento o una empresa necesitan de un producto o servicio que todavía no existe, y si existe, necesita de incrementos. Son varias las razones por las que se ponen proyectos en marcha. Algunas son más tangibles y lucen más que otras. A veces, un proyecto es creado para aprovechar un momento oportuno del mercado o para disminuir la cantidad de problemas que un determinado factor provoca. Desgraciadamente, las organizaciones no disfrutan de recursos infinitos, y por ello no pueden poner en marcha todos los proyectos que les gustaría desarrollar. Por esta razón, las organizaciones son obligadas a decidir qué proyectos rechazarán y qué proyectos serán puestos en marcha. Esta decisión,

normalmente, es tomada de acuerdo con los recursos disponibles en la empresa (personal, maquinaria, plazos y fondos financieros), o en muchos casos, por la importancia estratégica que un proyecto puede aportar. Es importante que la organización pueda establecer un proceso formal de selección de proyectos a través de criterios que le permitan realizar una elección coherente que debe ser muy estudiada, puesto que, en algunos casos, y dependiendo de su importancia, el proyecto elegido podrá determinar el rumbo de la empresa hacia el futuro. Además, el proyecto elegido consumirá los recursos de la empresa durante un periodo de tiempo que puede ser de unos meses o quizás años. Por esta razón, es fundamental que los proyectos elegidos sean los que aportarán beneficios, financieros o estratégicos, algo difícil de prever sin que se realicen estudios previos. Por lo menos en el ambiente empresarial, lo que lleva una organización a poner en marcha un proyecto es la oportunidad de obtener beneficios financieros. La forma más sencilla y eficaz de verificar si un proyecto puede ser rentable para la empresa es comparando las ganancias financieras del proyecto con sus costes. Existen varias técnicas que auxilian la organización para elegir el proyecto conveniente y que ofrecen distintos enfoques. Este capítulo presentará una serie de técnicas que podrán ser muy útiles a la hora de decidir qué proyectos serán desarrollados. 3.1 Criterios para la selección de proyectos Las organizaciones necesitan adoptar metodologías que les permitan elegir los proyectos que les aporten los mejores beneficios por una cuestión ante todo financiera, pero también para poder preservar su imagen de organización competitiva y, sobre todo, competente. Seleccionar un proyecto no es una decisión sencilla. Para que un proyecto tenga éxito, además de tener que contar con buenos recursos, tendrá que depender de una infinidad de variables cuyos resultados podrán o no ser previstos. Elegir un modelo o un criterio de selección de proyectos es una tarea que implica el cumplimiento de una serie de requisitos importantes que deberán tenerse en cuenta. William E. Souder 16, en su libro Project Selection and Economic Appraisal, establece algunos:

Realismo: El criterio elegido deberá reflejar la realidad de la situación actual, incluyendo los múltiples objetivos que puedan tener la empresa y sus gerentes. Por ejemplo: el proyecto “A” podrá incrementar su participación en su mercado de actuación y el proyecto “B” podrá incrementar su competitividad. ¿Cuál es el mejor? El modelo deberá estar alineado con los objetivos estratégicos de la organización, sin dejar de tener en cuenta las limitaciones que todas las empresas suelen tener (costes, personal, plazos...). Capacidad: El modelo debe ser el capaz de generar resultados que permitan realizar comparaciones con escenarios diferentes, optimizando el proceso de decisión. Flexibilidad: Para cumplir correctamente con el requisito anterior, el modelo tiene que ser flexible, es decir, debe permitir modificar variables y generar diferentes resultados, de acuerdo con el escenario que se aplique. Manejo: Un modelo de selección de proyectos debe ser de fácil comprensión y los resultados generados no deberán ser difíciles de interpretar. Para ellos, los datos utilizados en el modelo deberán ser exactos, actualizados y no excesivos. Coste: El proceso para la extracción de los datos, el tratamiento de los mismos y el análisis de los resultados no debe ser costoso ni consumir demasiado tiempo. Jack R. Meredith17, en su libro Project Management, A Managerial Approach, añade un requisito más: Easy Computerization: Es decir, los resultados generados deben tener un formato que permita su almacenamiento, tratamiento y distribución en una herramienta ofimática. Los criterios de selección de proyectos pueden dividirse básicamente en dos categorías: financieros o no financieros. Se podrá utilizar uno de ellos o

ambos, todo dependerá de los objetivos y de las necesidades de cada organización. Es importante resaltar que la elección adecuada del modelo de selección de criterios dependerá, sobre todo, de la naturaleza del proyecto. Eric Verzuh2, en su libro The Portable MBA in Project Management, nos hace una reflexión muy importante que merece la pena plasmarla aquí: Los modelos de selección de proyectos no toman decisiones: Son las personas, no el modelo, las que responden por la responsabilidad de la decisión. La dirección de la empresa puede “delegar” en un modelo la tarea de tomar la decisión, pero no podrá abstenerse de la responsabilidad de las eventuales consecuencias producidas por dicha decisión. Cualquier modelo de decisión, por más sofisticado que pueda parecer, solo podrá reflejar una parte de la realidad: De hecho, la vida real es demasiado compleja y un modelo, como mucho, podrá reflejar una parte del escenario. No obstante, la elección de un modelo o criterio de selección adecuado nos puede aportar resultados muy valiosos que nos podrá conducir al camino correcto. El uso combinado de herramientas financieras y no financieras podrá asegurar resultados más fiables para la selección de un proyecto o de una acción. 3.1.1 Criterios financieros para la selección de proyectos Los criterios financieros para la selección de proyectos nos proporcionan unos indicadores que nos permiten evaluar el atractivo económico del proyecto. Estos indicadores también sirven para realizar comparaciones entre diferentes alternativas de inversión en el abanico de potenciales proyectos de la organización. 3.1.1.1 Analisis beneficio-coste (Benefit-cost analysis – BCA)

Descrito en la sección 8.1.1.1 3.1.1.2 Punto de equilibrio (Break even point) El grafico del punto de equilibrio (también conocido como break even point) es uno de los métodos de selección de proyectos más sencillos de utilizar. Se trata de un gráfico que compara el coste total estimado de dos alternativas en un determinado periodo de tiempo. El punto de equilibrio es el punto en el que: Una alternativa empieza a tener un coste menor que la otra. Las ganancias igualan a las perdidas. Una inversión generará una rentabilidad positiva. Los ingresos igualan a los costes. Lograr el punto de equilibrio no devolverá las perdidas ocurridas en el pasado. Tampoco acumulará una reserva para pérdidas futuras. Además, no proporcionará un retorno sobre la inversión. Sin embargo, podrá decirnos cuál es la alternativa más rentable, a través de las proyecciones que esta herramienta puede producir. El gráfico del punto de equilibrio es confeccionado con el uso de dos ejes: “X” (tiempo) e “Y” (coste total del proyecto). La escala de valores utilizada será la que el punto de equilibrio se encuentra en el medio del eje de coste. Una nueva alternativa (el proyecto que será puesto en marcha) normalmente tendrá un único coste fijo asociado. Este coste se llamará “coste fijo del proyecto”. El coste variable del proyecto es el que seguirá ocurriendo mientras la nueva alternativa esté en operación. Un ejemplo bastante sencillo es la compra de una nueva máquina de producción de tornillos que reemplazará a la antigua que sigue en operación en una fábrica. La nueva máquina produce más piezas por hora y tiene un mantenimiento más barato. Suponemos que esta nueva máquina tiene un coste de treinta mil euros. Este coste solamente ocurrirá una vez (en el momento de la compra), con lo cual su coste fijo será de treinta mil euros. El

equipo antiguo, que todavía sigue en funcionamiento, no tiene ningún coste fijo asociado. Las dos alternativas tendrán un coste variable asociado y, cuando se comparan los costes variables de la maquina antigua y de la nueva, es importante asociar los mismos costes para ambas alternativas. En este caso, el coste variable puede ser, por ejemplo, su consumo energético, su coste de operación... Si la máquina antigua en funcionamiento produce mil piezas por mes, se espera que la nueva máquina produzca, por lo menos, el mismo número. Además, se estima que el coste variable de la nueva máquina sea menor que el de la antigua.

Figura 16: Punto de equilibrio Según ilustra la figura 16, el gráfico del punto de equilibrio tendrá las siguientes características: La línea del coste variable de la máquina nueva deberá presentar

una subida menor que la línea del coste variable de la antigua. La línea de coste variable de la máquina nueva empieza en el mismo punto del eje “Y” (coste total) del coste fijo de su adquisición. Por otro lado, la línea del coste variable de la máquina antigua empezará en el punto cero del eje “Y”. En algún momento, el total de la línea del coste de la máquina nueva (la suma de coste variable más el coste fijo) se cruzará con el coste variable de la antigua. Este es el punto conocido como el “punto de equilibrio”. Al alcanzar el punto de equilibrio, el dinero ahorrado en el coste variable de la máquina nueva comparado con de la antigua es igual a la inversión de la máquina nueva. O sea, es el punto donde el coste total de las dos alternativas es exactamente el mismo. Cuanto más temprano este punto sea alcanzado, mejor estará justificada la compra de la nueva máquina. A partir del punto de equilibrio, la diferencia entre las dos líneas de coste total traducirá en la reducción de costes proporcionada por la adquisición de la nueva máquina. 3.1.1.3 Valor presente neto - VPN (Net present value – NPV) El valor presente neto (VPN) o valor actual neto (VAN) es uno de los métodos más utilizados para determinar si un proyecto es financieramente viable. Su fórmula permite calcular el valor presente de un determinado número de flujos de caja futuros, originados por una inversión. Su propósito es medir el valor agregado con que contribuye el proyecto a la organización Para realizar el cálculo del VPN es importante tener a mano las siguientes informaciones: La inversión inicial previa: Es el valor que será invertido inicialmente por la organización para poner en marcha un

proyecto. Este valor incluye la inversión realizada en maquinaria, instalaciones, personal... Las inversiones durante la operación: Incluye las inversiones realizadas para el reemplazo o renovación de maquinaria, ampliación de locales, nuevas contrataciones de personal… Los flujos netos de efectivo – FNE: Son aquellos flujos de efectivo que el proyecto debe generar después de su puesta en marcha. La tasa de descuento: Es una medida financiera que se aplica para determinar el valor actual de un pago futuro. El número de periodos que dure el proyecto: Estos periodos normalmente son equivalentes a un año fiscal. Cómo se calcula el VPN Supongamos que una organización tiene que elegir entre dos proyectos para poner en marcha uno de ellos y ha elegido el cálculo del VPN como el criterio definitivo de elección. El proyecto “A” contiene las siguientes características: Valor de la inversión inicial: 10.000 euros Los flujos netos de efectivo (FNE) durante los próximos cinco años son los siguientes: Año 1: 2.000 euros Año 2: 3.000 euros Año 3: 3.000 euros Año 4: 2.000 euros Año 5: 5.000 euros

Figura 17: Flujos netos de efectivo del proyecto “A” Para desarrollar la evaluación de estos proyectos se estima una tasa de descuento anual del 15%: Como se puede observar en la figura 17, la inversión inicial aparece en el periodo cero, y con la señal negativa, ya que se ha realizado un desembolso de dinero por el valor de 10.000 euros y, por lo tanto, debe registrarse como tal. Los importes de los FNE de los periodos 1 al 5, son positivos; esto quiere decir que en cada periodo los ingresos de efectivo son mayores a las salidas. Como el dinero tiene un valor diferente en el tiempo, el siguiente paso es conocer el valor de cada uno de los FNE en el periodo cero. Para esto, se descontará cada uno de los flujos a su tasa de descuento, que será del 15%. La fórmula que utilizaremos es la siguiente: VPN = - 10.000 + [2.000 / (1.15)1] + [3.000 / (1.15)2] + [3.000 / (1.15)3] + [2.000 / (1.15)4] + [5.000 / (1.15)5] VPN = - 10.000 + [1739 + 2268 + 1973 + 1144 + 2486] VPN = -390 Cada flujo será dividido por su tasa de descuento elevada a una potencia que es equivalente al número del periodo donde se espera dicho resultado. Una vez realizada esta operación, se habrá calculado el valor de cada uno de los FNE a euros de hoy, que, en este ejemplo, es de 9.610,00. Basado en este resultado, ¿podemos decir que el proyecto es viable? Según lo descrito anteriormente, el VPN tiene como propósito principal medir el valor agregado con que contribuye el proyecto a la firma. Por ello, se pueden presentar, entonces, las siguientes situaciones: Si el resultado obtenido es positivo, entonces el VPN es positivo. Por lo tanto, se está añadiendo valor y el proyecto debe aceptarse.

Si el resultado obtenido es negativo, entonces el VPN es negativo. De esta forma, se está destruyendo valor y el proyecto debe rechazarse. Cuando se tienen varios proyectos con VPN positivo, entonces se debe escoger el que tenga mayor VPN. Este proyecto es el que crea más valor para la organización. Existen casos en que el VPN es igual a cero. Esto quiere decir que el proyecto no estará añadiendo ni destruyendo valor, por lo menos en términos financieros. No obstante, es importante tener en cuenta que un proyecto puede no proporcionar valor financiero, pero sí que podrá aportar otro tipo de beneficios (tecnológicos, funcionales, entre otros). En el ejemplo descrito anteriormente, el VPN obtenido ha sido negativo. La inversión realizada resultaría en una pérdida de 390 euros, es decir, no se debería poner este proyecto en marcha. Por otro lado, el proyecto “B” contará con la misma inversión inicial del proyecto “A” (10.000 euros); sin embargo, contará con diferentes flujos netos de efectivo durante los próximos cinco periodos, tal como ilustra la figura 18:

Figura 18: Flujos netos de efectivo del proyecto “B” Tal y como ha ocurrido con el proyecto “A”, se toma como tasa de descuento al 15%. Así, la formula se desarrollará de la siguiente forma: VPN = - 10.000 + [6.000 / (1.15)1] + [3.000 / (1.15)2] + [3.000 / (1.15)3] + [2.000 / (1.15)4] + [5.000 / (1.15)5] VPN = - 10.000 + [5217 + 2268 + 1973 + 1144 + 2486] VPN = 3.088 Como el resultado es positivo, el proyecto “B” maximizaría la inversión en

3.088 euros a una tasa de descuento del 15% y, por lo tanto, el proyecto debe ejecutarse. Como se podrá observar, la diferencia entre los dos proyectos reside en los flujos netos de efectivo del primer periodo. El proyecto “A” contiene unos ingresos inferiores que el proyecto “B”, lo que, en definitiva, determina la elección de la puesta en marcha del proyecto “B”. 3.1.1.4 Tasa interna de retorno – TIR (Internal rate of return - IRR) La tasa interna de retorno – TIR es la tasa de interés con la cual el valor presente neto – VPN (descrito en la sección anterior), es igual a cero. El VPN es calculado a partir del flujo de caja anual, donde se trasladan todos los valores futuros al presente. Es también un indicador de la rentabilidad de un proyecto, es decir, a mayor TIR, mayor rentabilidad. Es ampliamente utilizada para decidir la aceptación o rechazo de un proyecto. Para ello, la TIR se compara con una tasa mínima o tasa de coste, el coste de oportunidad de la inversión. Si la tasa de rendimiento del proyecto (expresada a través de la TIR) supera la tasa de coste, se acepta la inversión. De lo contrario, se rechaza. Poniendo un ejemplo: Los técnicos de una empresa industrial están estudiando dos propuestas para la adquisición de una máquina. La propuesta “A” presenta una máquina que cuesta 100.000 euros y con una vida útil prevista de cinco años. La propuesta “B” presenta una maquina con el doble de la capacidad de la primera, y con una vida útil prevista de diez años, con un precio de compra de 175.000 euros. Ambas máquinas tendrán valor de reventa cero tras el periodo de su vida útil. La máquina con menor capacidad (propuesta “A”) puede atender plenamente a la producción prevista para los próximos cinco años. Como, a partir del sexto año, se prevé un aumento importante de la producción, la compra de la

máquina pequeña a día de hoy implicaría la necesidad de compra de otra máquina con las mismas características al final del quinto año por el mismo precio de la actual (100.000 euros). Comprando esta máquina, los ingresos líquidos anuales (ya descontados todos los costes, con excepción de la depreciación) serían los siguientes: 55.000 euros al año para los cinco primeros años. 70.000 euros para los dos años siguientes. 95.000 euros para los tres últimos años. Si se decide comprar la máquina grande (propuesta “B”), los ingresos líquidos anuales serían: 58.000 euros para los próximos dos años. 65.000 euros para los tres años siguientes. 95.000 euros para los cinco últimos. ¿Cuál sería la mejor opción de compra? Los diagramas representativos de los flujos de caja de las dos propuestas serían los siguientes: Propuesta “A” Máquina pequeña (valores expresos en 1.000 euros)

Figura 19: Flujo de caja de la propuesta “A” Propuesta B

Máquina grande (valores expresos en 1.000 euros)

Figura 20: Flujo de caja de la propuesta “B” La opción elegida deberá ser la que presenta la mayor TIR La TIR de la propuesta “A” es la siguiente:

Utilizando una calculadora financiera, se obtiene i = TIR 42,42% al año La TIR de la propuesta “B” es la siguiente: En este caso, la TIR es de 36,49% al año. Por lo tanto, la TIR de la propuesta “A” (máquina pequeña) es mayor que la TIR de la propuesta “B” (máquina grande), por lo tanto, la mejor opción de compra es la primera. 3.1.1.5 Periodo de reembolso (Payback period- PP) El periodo de reembolso (payback period - PP) es el tiempo necesario para

recuperar una inversión inicial. El periodo de reembolso, además, puede representar la cantidad de tiempo que toma para el presupuesto de un proyecto y para que recupere su inversión final. La figura 21 ilustra el flujo de caja de una propuesta de inversión. ¿Cuánto tiempo es necesario hasta que los flujos de caja acumulados de una inversión alcancen o superen su coste inicial? Según la figura 21, se realiza una determinada inversión inicial de 100.000 €. En el año siguiente, la empresa recupera 40.000 €, quedando descubierta en 60.000 €. El flujo de caja del segundo año es de exactamente 60.000 €, o sea, la inversión se ha recuperado en dos años, o en otras palabras, el periodo de reembolso es de dos años. Si un proyecto exigiera un periodo de reembolso de tres años, en este caso, la inversión sería aceptable.

Figura 21: Flujo de caja ¿Cómo se calcula el periodo de reembolso? Para calcular el periodo de reembolso se utiliza la siguiente fórmula: Suponemos que un proyecto cueste 5.000 €. ¿Cuál sería el periodo de reembolso de esta inversión? El coste inicial es de 5.000 €. Tras los dos primeros años, los flujos de caja totalizan 3.000 €. Después del tercer año, los flujos de caja alcanzan la cifra de 8.000 €; por lo tanto, el proyecto fue pagado en algún momento entre el final del según año y el comienzo del tercero. Como el flujo de caja acumulado en los dos primeros años es de 3.000 €, es necesario recuperar los otros 2.000 € en el tercer año. El flujo de caja del tercer año es de 5.000 €, es decir habrá que esperar 2.000 € / 5.000 € = 0,40 años. El periodo de reembolso es, por tanto, de 2,4 años o cerca de dos años y cinco meses.

Figura 22: Cálculo del periodo de reembolso 3.1.1.6 Retorno sobre la inversión – RSI (Return on investment – ROI) El retorno sobre la inversión – RSI (return on investment – ROI) es un porcentaje que se calcula en función de la inversión y los beneficios obtenidos para cuantificar la viabilidad de un proyecto. La fórmula más sencilla de obtenerlo es la siguiente: ROI = (beneficio obtenido - inversión) / inversión Utilizando un sencillo ejemplo: La puesta en marcha de un proyecto ha exigido una inversión total de 1.000 euros. Los beneficios generados por este proyecto han alcanzado la cifra de 3.000 Euros. En este caso vamos a tener un ROI de: (3.000 – 1.000) / 1000 = 2 2 * 100 = 200% De esta forma, el proyecto ha obtenido un retorno del 200%, es decir, una excelente inversión. Se pueden desarrollar fórmulas bastante más sofisticadas que el ROI, de todas formas, este ejemplo ilustra exactamente toda la dinámica de resultados generados por esta herramienta. 3.1.2 Criterios no financieros para la selección de proyectos

Hay ocasiones en las que una empresa no puede asumir el desarrollo de muchos proyectos simultáneos por no disponer de recursos, sean humanos, financieros o materiales. En este caso, las empresas normalmente se inclinan por los proyectos más rentables, y para ello existe una serie de criterios financieros, como los que hemos visto antes, que pueden proveer el valor aproximado de ganancias (o pérdidas) que un proyecto puede llegar a generar. Sin embargo, en muchos casos, el resultado financiero no es el más importante que una empresa necesita saber para decidir por un proyecto u otro. Existen proyectos que no generan ganancias, pero sí pueden aportar una visibilidad a la empresa en su sector de actuación. De hecho, muchas empresas de tecnología no generan ganancias financieras a corto plazo con sus productos innovadores, pero pueden presumir de haber sacado al mercado una tecnología puntera que les situará como referencia en un determinado segmento. A continuación, veremos cuáles son las herramientas que pueden ayudar a elegir la elección de desarrollar un determinado proyecto, basado en resultados no financieros. 3.1.2.1 Tributos ponderados (Decisión matrix) Analizaremos los atributos determinados por una constructora para la adquisición de un terreno en un barrio de la ciudad. Son muchos los barrios que ofrecen terrenos aptos para construir. La elección del barrio para la construcción de la urbanización será realizada en función de los resultados determinados por cada atributo. Han sido elegidos cuatro atributos que la constructora considera relevantes: seguridad, comunicación, comercio y transportes, y se les ha adjudicado una escala de pesos entre 0.10 y 0.25, según establecido por la constructora.

Figura 23: Tabla de atributos ponderados Se multiplican los pesos de cada atributo por el valor definido a cada barrio. El resultado determinará la mejor opción. En el ejemplo, utilizando cuatro atributos y una escala de cuatro valores, el barrio B es la mejor la alternativa para la construcción de viviendas, puesto que ha logrado la mejor puntuación en relación a las alternativas restantes. Es importante resaltar que el resultado es directamente influenciado por los pesos determinados, como figura en el ejemplo presentado. Otra constructora podría atribuir pesos distintos para cada atributo, cambiando el resultado final. Eso quiere decir que los valores resultantes de la matriz de decisión no son absolutos, pues dependerán de la evaluación dada por cada empresa, en función de sus valores. 3.1.2.2 Toma de decisiones (Decisión making) En muchas ocasiones, una empresa se encontrará delante de una situación que les exigirá tomar una decisión que, en muchos de los casos, dependerá de los valores o experiencias del grupo encargado de realizar dicha decisión, lo que normalmente puede generar un conflicto de interés dentro del grupo. Para realizar una toma de decisiones exenta de criterios personales, es

importante establecer un conjunto de reglas que permita que esta decisión sea tomada de forma coherente y lo menos arriesgada posible. Los modelos clásicos de toma de decisiones normalmente están asociados al proceso de resolución de problemas, que se inicia de la siguiente manera: 1. Identificar el problema. 2. Determinar las alternativas. 3. Implementar la decisión elegida. En este caso, no estamos delante de un problema, lo que tenemos es un abanico de posibles proyectos en que necesitaremos elegir el que mejor atienda nuestras necesidades. De esta forma, el proceso seria el siguiente:

Figura 24: Ciclo de la toma de decisiones El proceso de toma de decisiones se puede desarrollar de dos formas: cualitativa y cuantitativa. El análisis cualitativo se basa, sobre todo, en la experiencia del decisor, mientras que en el análisis cuantitativo, la decisión es tomada en base a los datos y las informaciones obtenidas de proyectos anteriores similares.

Figura 25: Proceso de la toma de decisiones Un proceso de toma de decisión puede caer en tres categorías: Toma de decisiones bajo certidumbre: El tomador de decisiones conoce los datos de forma determinista. Toma de decisiones bajo riesgo: Los datos se describen mediante distribuciones de probabilidad. Toma de decisiones bajo incertidumbre: En esta situación, no es posible asignar a los datos, pesos relativos que representen su grado de relevancia en el proceso de decisión. 3.1.2.3 Análisis del árbol de decisiones (Decisión tree analisys) Descrita en la sección 12.2.1.3. 3.1.2.4 Proceso de análisis jerárquico (Analytic hierarchy process - AHP) Desarrollado por el matemático Thomas L. Saaty18 en los años setenta, el proceso analítico jerárquico - PAJ (más conocido por su sigla en inglés: Analytic Hierarchy Process - AHP) es una técnica utilizada para facilitar el

proceso de toma de decisiones complejas, mediante la confección gráfica de un modelo jerárquico que tratará de organizar la información, descomponerla y analizar sus partes. Utilizando las palabras del propio autor: “Se trata de desmesurar un problema y a continuación unir todas las soluciones de los sub problemas en una solución”. Un PAJ es diseñado de la siguiente forma: 1. Modelar el problema como una jerarquía El primer paso consiste en modelar el problema como una jerarquía. De esta forma, será posible explotar los aspectos del problema en niveles que podrán ir desde un nivel general hasta un nivel bien detallado, luego expresarlos en la forma multinivel que el PAJ requiere. 2. Definir las jerarquías Se puede decir que una jerarquía es un sistema de organización donde cada elemento es subordinado por uno o más elementos. Uno de los diagramas de jerarquía más conocidos en el Project Management es la EDT (estructura de diagrama de trabajo, descrito en la sección 5.3). En el caso del PAJ, podemos utilizar este tipo de diagrama para resolver un problema de decisión complejo, construyendo una estructura de información robusta, que nos pueda proporcionar una toma de decisión correcta y bien documentada. La jerarquía de un PAJ empieza por un objetivo general en el nivel superior, que se desglosará en un nivel inferior en un grupo de alternativas para alcanzar el objetivo deseado. Entre los dos, se posicionará un grupo de criterios que relacionarán las alternativas con el objetivo.

Figura 26: Jerarquía básica de un PAJ El diseño de cualquier jerarquía PAJ es libre siempre y cuando obedezca la estructura ilustrada en la figura 26. Su formato dependerá de la naturaleza del problema y de las necesidades de la empresa. A medida que el proceso de diseño y análisis del PAJ avanza, su estructura podrá cambiar, así como sus criterios y/o valores, estableciendo nuevos resultados que influenciarán directamente en la toma de decisión. 3. Establecer prioridades Una vez que la jerarquía se ha construido, se establecerán las prioridades de todos sus nodos. Las prioridades son los números que serán asignados a estos nodos y que representan los pesos relativos de los nodos en cualquier grupo. Por definición, la prioridad de un objetivo es siempre mil, valor que representa la suma de las prioridades de los criterios, así como de las alternativas. De esta forma, un nodo con una prioridad .200 tiene el doble del peso de una

prioridad .100, o diez veces más peso que uno con prioridad .020 y así sucesivamente. El concepto de “peso” puede representar “importancia”, “preferencia”, “necesidad” o cualquier factor considerado importante por los decisores. Las prioridades serán distribuidas sobre la jerarquía de acuerdo con su estructura y sus valores dependerán de la información introducida. Es importante tener en cuenta que el objetivo, los criterios y las alternativas estarán siempre estrechamente relacionadas.

Figura 27: PAJ con valores asignados Normalmente, un PAJ es confeccionado durante una sección de lluvia de ideas, o brainstorming (descrito en la sección 11.2.1.8) y, por esta razón, es diseñado con valores por defecto, tal y como ilustra la figura 27, con las prioridades de cada nivel sumando mil en total. Es importante iniciar el diseño de un PAJ con valores por defecto, porque durante el proceso puede aparecer uno o más criterios nuevos, y de esta forma, será necesario distribuir los valores por igual. Si por ejemplo se adiciona un quinto criterio a la jerarquía, la prioridad por defecto de cada criterio sería .200. Si hay sólo dos alternativas, cada una tendrá una prioridad por defecto de .500. A continuación, analizaremos un PAJ aplicado a la compra de equipo Informático para un determinado proyecto. Una empresa necesita comprar equipos que puedan responder técnicamente a las necesidades del proyecto, y

tras un breve análisis de las ofertas disponibles en el mercado, han encontrado cuatro fabricantes que comercializan los mejores equipos. Los técnicos del proyecto han establecido cuatro criterios de decisión para la compra de los PC’s: memoria, disco duro, procesador y pantalla. El PAJ de este proceso de decisión será diseñado de la siguiente forma:

Figura 28: PAJ para la compra de PC´s. El objetivo está pintado de color negro, los criterios en gris e las alternativas en blanco. Todas las alternativas (cuatro diferentesfabricantes de PC´s) están desglosados en el nivel más bajo de la jerarquía. En algunos PAJ se podrán crear subcriterios. Es decir, se podría desglosar la pantalla por ejemplo en: tamaño en pulgadas, resolución... En el disco duro se podría también hacer un desglose que incluiría: capacidad, velocidad... Cuando un JAP contiene muchos sub criterios, los cálculos se vuelven más complejos y esto requerirá el uso de un software especializado. Volvamos a nuestro PAJ: El Project Manager junto con su equipo tendrán que establecer los pesos de cada criterio elegido. Para ello, será necesario comparar cada elemento, uno contra el otro, y decidir cuál es el más importante en cada caso. Se realizarán comparaciones de valor de seis pares:

memoria/HD, memoria/procesador, HD/pantalla, procesador/pantalla.

memoria/pantalla,

HD/procesador,

Primero se comparará memoria x HD. Habrá que decidir cuál de estos dos componentes es el más importante. En algunos proyectos técnicos que necesitan ejecutar programas de cálculo estructurales o diseño de planos, la memoria es imprescindible. Sin embargo, en proyectos que necesiten estos tipos de software, no podemos prescindir de un disco duro rápido, con lo cual, la decisión de determinar si la memoria es más importante que el HD, o al revés, no es una tarea sencilla. De todas formas, el PAJ es una herramienta flexible, donde es posible en cualquier momento del proceso, cambiar los valores de importancia de cada criterio. Vamos suponer que, finalmente, el equipo ha decidido que la memoria es ligeramente más importante que el disco duro. El PAJ entonces requerirá que se establezca un valor numérico para esta decisión. Para ello se utiliza una tabla de comparaciones, como la que podemos apreciar a continuación:

Los valores 2, 4, 6 y 8 pueden ser utilizados para expresar valores

intermediarios. Figura 29: Tabla de escala de comparación por pares Ahora que conocemos los criterios de elección y hemos establecido la escala de comparación de pares, ha llegado el momento de hacer el cruce de esta información. El equipo ha establecido los siguientes valores: La memoria tiene una importancia moderada sobre disco duro (3). La memoria tiene una importancia muy fuerte sobre el procesador (7). La memoria es moderadamente más importante que la pantalla (3). El HD es extremadamente más importante que la pantalla (9). EL HD y tiene la misma importancia que el procesador (1). El procesador es bastante más importante que la pantalla (7). Con estos valores, confeccionaremos la siguiente tabla:

Figura 30: Juicio realizado por el Project Manager y su equipo para la compra de equipos informáticos para el proyecto. Un software especializado utilizará cálculos matemáticos para convertir los valores de las prioridades de cada uno de los cuatro criterios. Los detalles de

los cálculos están fuera del alcance de libro debido sobre todo a su complejidad. Sin embargo, podrás tener la información completa de esta herramienta en el proprio libro de Thomas Saaty18 “Fundamentals of Decision Making and Priority Theory” de RWS Publications Una vez realizados los cálculos, el programa traerá las prioridades resultantes de los valores anteriormente establecidos. Debido a la flexibilidad del PAJ, es posible en cualquier momento del proceso, cambiar los valores de importancia de cada criterio y con ello, cambiar el valor de las prioridades.

Figura 31: PAJ de la adquisición de equipos informáticos para un proyecto. Los criterios tenían originalmente un valor de .250 cada uno. Después de establecer la escala de comparación por pares y realizar los correspondientes cálculos, las prioridades han dejado de tener la misma importancia y pasaron a tener una importancia acorde con los valores establecidos por el PM y su equipo técnico

Capítulo 4 Gestión de la integración Capítulo 4 - Gestión de la Integración

“La cooperación es la convicción plena de que nadie puede llegar a la meta si no llegan todos” Virginia Burden Tower 19, escritora y autora de libros estadounidense

Algunas cosas en las que NO puedes pensar acerca de la gestión de la integración “No podemos esperar la aprobación formal de cambios. Hazlo ya” Un proyecto es un emprendimiento que afecta a una serie de variables integradas entre sí (costes, plazos, recursos humanos, calidad...). Uno de los grandes desafíos del Project Manager es ejecutar un proyecto “tal y como ha sido planificado”, y para ello, es importante evitar que se produzcan cambios. Cuando esto es inevitable, el Project Manager tendrá que hacerlo de forma planificada, documentada y aprobada por las partes afectadas, puesto que un cambio mal introducido podría desestabilizar todo el proyecto. Introducción La gestión de la integración consiste en asegurar la integración y coordinación de los elementos del proyecto que compiten entre sí.

Figura 32: Integración de las áreas de la aplicación en un proyecto. El objetivo principal de la gestión de la integración es coger todas las áreas de aplicación del proyecto y literalmente “integrarlas” en una gran y única pieza, como si de un engranaje se tratara. El Project Manager es, ante todo, un integrador, y por ello, la gestión de la

integración tiene que ser la más importante desde su punto de vista, puesto que él es la única persona que debe conocer y tener la visión total del proyecto. Su responsabilidad reside en asegurar el buen avance del proyecto, realizando un seguimiento adecuado y poniendo en marcha las acciones preventivas y/o correctivas adecuadas. Bajo el enfoque de la cuarta edición del PMBOK®, la gestión de la integración de un proyecto incluye procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar todos los procesos de la gestión de proyectos. Son ellos: Desarrollar el acta de constitución del proyecto. Desarrollar el plan para la dirección del Proyecto. Dirigir y gestionar la ejecución del proyecto. Monitorizar y controlar el trabajo del proyecto. Realizar el control integrado de cambios. Cerrar el proyecto o fase. 4.1 Desarrollo del acta de constitución del proyecto (Proceso que corresponde a la fase de inicio del proyecto) El objetivo de este proceso es autorizar formalmente el inicio de un proyecto o fase, documentando sus requisitos iniciales, necesidades, objetivos y expectativa de los interesados. Esta autorización normalmente viene de un interesado externo, como puede ser, por ejemplo, un patrocinador. La presencia del Project Manager en la elaboración de este documento es muy recomendada, puesto que es el documento que otorgará al Project Manager la autoridad necesaria para disponer de los recursos asignados al proyecto. 4.1.1 Técnicas y herramientas 4.1.1.1 Juicio de expertos (Expert judgement) El juicio de expertos es muy útil para poner en marcha este proceso. Esta colaboración puede venir tanto de un especialista como de un grupo de personas con mucha experiencia o que ha asistido a alguna formación

especializada y que puede aportar muchas informaciones. Entre ellos, se incluyen los consultores, los integrantes del equipo del proyecto, algún proveedor especializado... NOTA DEL AUTOR En todas las empresas en que he trabajado, me he encontrado con profesionales que tenían siempre mucho que aportar. No existe escuela que enseñe más que la experiencia, y por ello, disponer de la opinión de un profesional experimentado es un recurso imprescindible para tomar la decisión correcta. 4.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) DOC nº 001 - Acta de constitución del proyecto (Project charter) 4.2 Desarrollo del plan de proyecto (Proceso que corresponde a la fase de planificación del proyecto) Este proceso es el que define, prepara, integra y coordina todos los planes subsidiarios del proyecto (riesgos, calidad, alcance, costes...). Es quizás el documento más importante de un proyecto, puesto que contiene las estimaciones, los objetivos, las responsabilidades y todo lo que se refiere a la planificación del proyecto. Su elaboración progresiva y su actualización constante lo hacen imprescindible en la gestión de cualquier proyecto. El plan de proyecto es un documento formal y aprobado por la dirección y es utilizado principalmente para la administrar las fases, interacciones, actividades y toda la planificación de un proyecto. Las instrucciones de cómo confeccionarlo se encuentran en el Apéndice A, doc nº 003. El plan de proyecto, tiene fundamentalmente, los siguientes objetivos: Organizar el proyecto: El plan de proyecto contiene una estructura que permite localizar fácilmente cualquier información,

como el cronograma, el equipo asignado, sus funciones y responsabilidades, restricciones, entre otros. Generar documentación: Como podremos observar en los capítulos siguientes, la gestión correcta de un proyecto implica en la confección de una serie de documentos que van siendo incorporados al plan de proyecto. Uno de los factores de éxito de un proyecto es la correcta confección y actualización de su documentación, que además servirá como una valiosa fuente de consulta histórica para futuros emprendimientos similares. Proveer información: Un plan de proyecto es un documento que se actualiza en función del avance de los trabajos, ofreciendo a cualquier interesado, una visión exacta de todas las estimaciones realizadas y el estado actual en que se encuentran. Gestionar las líneas base: Cuando se inicia un nuevo proyecto, se elaboran sus líneas base, que, normalmente, son de costes, plazos y de alcance. A partir de estas líneas base, se establecen todas las previsiones iniciales, con lo cual es fundamental que se encuentren actualizadas y que reflejen fundamentalmente el estado actual que el proyecto se encuentra. 4.2.1 Técnicas y herramientas 4.2.1.1 Metodología de planificación del proyecto (Project plan methodologies) Cualquier enfoque estructurado que permita guiar el equipo hacia un plan sostenible y eficaz es válido para el desarrollo del plan de proyecto. No importa si la metodología es sencilla, como la utilización de formularios o plantillas estándar, o compleja, como, por ejemplo, el uso de un software del Project Management integrado (descrito en la sección 6.3.1.4). Normalmente, una organización utiliza una serie de técnicas combinadas que les auxilia en la elaboración de un plan de proyecto eficiente, como las que son presentadas en este libro.

No obstante, uno de los recursos más valiosos que una organización puede tener es su “capital intelectual”. Los conocimientos y habilidades de los involucrados en el proyecto son cruciales para el buen desarrollo del plan de proyecto (ver sección a continuación). 4.2.1.2 Conocimientos y habilidades de los interesados (Stakeholder´s knowledge and habilities) Un plan de proyecto incluye una serie de estimaciones de costes y de plazos, además de un análisis de los riesgos del proyecto, entre muchas otras cosas. La confección de un plan de proyecto eficaz dependerá sobre todo de los conocimientos y habilidades de su equipo, de los patrocinadores o de cualquier persona que esté involucrada. El Project Manager debe proporcionar los medios para que los interesados puedan desarrollar y aportar las informaciones adecuadas. 4.2.1.3 Sistema de información de gestión de proyectos (Project management information system - PMIS) El Project Management information system (PMIS) es una herramienta utilizada en el Project Management para recoger, tratar y distribuir la información a través de medios electrónicos o manuales. Un ejemplo de PMIS es el Microsoft Project que ayuda a estar al día y controlar el trabajo, la programación y el presupuesto de los proyectos. Otro programa que se encaja en este ámbito, es el Microsoft Outlook que administra el tiempo, el calendario, los contactos y la información enviada y recibida por las personas involucradas en el proyecto. 4.2.1.4 Valor del trabajo realizado (Earned value management) Descrito en la sección 7.3.1.1 4.2.1.5 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1

4.2.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) DOC nº 003 – Plan de proyecto (Project Management Plan) 4.3 Gestión y ejecución del plan de proyecto (Proceso que corresponde a la fase de ejecución del proyecto) Este es el proceso que pone en marcha todo lo definido en el plan de proyecto y que realiza la implantación de cualquier cambio resultante de acciones correctivas y/o preventivas. Este proceso incluye, además, los esfuerzos necesarios para alcanzar los resultados determinados por el plan de proyecto. La ejecución de un plan de proyecto eficaz conlleva al desarrollo de las siguientes actividades: Concluir con éxito las actividades que forman parte del proyecto. Alinear el equipo con los objetivos del proyecto. Gestionar el progreso de los trabajos. Incentivar la fluidez de la comunicación entre los involucrados. Desarrollar acciones preventivas. Utilizar técnicas y herramientas de gestión. Realizar reuniones periódicas. Identificar y monitorizar desvíos. Poner en marcha acciones correctivas, cuando sea necesario. Estas son tareas típicas de la fase de ejecución y control, que es la fase en que el plan de proyecto es, de hecho, puesto en marcha. 4.3.1 Técnicas y herramientas 4.3.1.1 Habilidades de gestión en general (General management Hability) La responsabilidad final del Project Manager es asegurar la ejecución del

proyecto dentro del plazo y de los costes estimados, garantizando la calidad de los servicios y productos entregados. Esto exige una administración eficaz de todas las disciplinas que hemos analizado en este libro: la comunicación, los recursos humanos, los contratos, el alcance, los riesgos, los costes, entre otros. Esta responsabilidad podrá variar en función de la complejidad del proyecto, del tipo de la organización que lo ejecuta, del interés del cliente, entre otros factores. 4.3.1.2 Conocimientos acerca del producto y/o servicio (Knowledge on the product and/or service) Como ya hemos comentado, unas de las características más importantes del Project Manager es la de líder. No obstante, para ejercer el liderazgo y defender su posición en momentos críticos del proyecto, el Project Manager tiene que ser capaz de hablar con los involucrados más importantes del proyecto (el cliente, el equipo, el patrocinador...) con mucha propiedad, y para ello, es imprescindible tener amplios conocimientos acerca del producto o servicio resultante del proyecto que se está desarrollando. Conocer a fondo el servicio y/o producto que será generado, aportará al Project Manager, algunas ventajas importantes, como por ejemplo: Selección de los proveedores más adecuados. Respuesta adecuada a los eventuales riesgos. Equilibrio entre costes, tiempo, alcance y calidad. Mejora en la comunicación entre los interesados. Reducción de la incertidumbre. Mejor control general en la ejecución del proyecto. Para ello, es importante entender cómo el producto o servicio será desarrollado, su valor (comercial, estratégico...), sus funcionalidades, sus fortalezas y eventuales debilidades. 4.3.1.3 Sistema de autorización de trabajo (Work authorization system – WAS) El sistema de autorización de trabajo (conocido como Work authorization system - WAS en inglés), es un procedimiento que determina las acciones

necesarias para autorizar u obtener la autorización de la ejecución de un determinado trabajo. Este procedimiento debe incluir también la documentación y los requisitos necesarios para ejecutar este tipo de gestión. Este documento es muy utilizado, además, para gestionar y mantener bajo control los trabajos que no formen parte del alcance previsto, evitando de esta forma, que se produzcan incidencias en los costes, plazos o consumo de recursos del proyecto. El sistema de autorización de trabajo funciona básicamente de la siguiente forma: Uno de los integrantes del equipo del proyecto redacta un “Documento de autorización de trabajo” (Work authorization document – WAD, descrito en el Apéndice A doc nº 043). Este documento es enviado al Project Manager (o a las personas con autorización para aprobar este tipo de solicitud) donde se describe el trabajo (o el listado de trabajos) que necesitan ser ejecutados. El Project Manager reenvía el WAD a los departamentos correspondientes para que se especifiquen las fechas hábiles, las duraciones, costes y recursos estimados para el desarrollo de los trabajos listados en el WAD. El personal encargado realizará las eventuales comprobaciones que correspondan (sobre todo en lo que se refiere a las estimaciones generales de los trabajos) y devolverá el WAD al Project Manager con toda la información necesaria para que se juzgue su viabilidad. Cuando el WAD haya sido aprobado y firmado por todas las partes involucradas, el Project Manager autorizará el inicio de los trabajos. Este documento formará parte de todo el ciclo de vida del proyecto y su contenido podrá ser incrementado con nuevos trabajos, valores, plazos o cualquier cambio relevante que haya sido debidamente aprobado previamente.

4.3.1.4 Evaluación de progresión o reuniones de seguimiento (Follow-up meetings) Las reuniones de seguimiento tienen como principales objetivos verificar el avance de un proyecto, intercambiar informaciones y revisar las estimaciones, entre otras cosas. Es imprescindible incluir estas reuniones como una actividad del cronograma del proyecto, puesto que suelen consumir un tiempo considerable y deben tener una frecuencia regular, para proporcionar un seguimiento coherente al proyecto. En el capítulo 10, “Gestión de las Comunicaciones”, se amplía detalladamente la forma correcta de organizar una reunión de seguimiento. 4.3.1.5 Sistema de información de gestión de proyectos (Project Management information system - PMIS) Descrita en la sección 4.2.1.3. 4.3.1.6 Procedimientos de la organización (Organization procedures) Las organizaciones deben establecer procedimientos que les permitan desarrollar su trabajo obedeciendo una serie común de pasos claramente definidos, que posibiliten la ejecución de cada tarea correctamente, reduciendo la probabilidad de errores. Estos procedimientos pueden ser de índole técnica, administrativa u operacional, deben estar claramente definidos y no deben ser excesivos. 4.3.1.7 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1 4.3.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto)

DOC nº 043 – Documento de autorización de trabajo (WAD - Work authorization document) DOC nº 045 – Actas de reunión del proyecto (Project meeting minutes) DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project Management plan updates) DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates) 4.4 Monitorización y control del trabajo del proyecto (Proceso que corresponde a la fase de control del proyecto) Este es el proceso en el que se puede notar una actuación intensiva por parte del Project Manager. Su labor incluye recolectar, medir y distribuir la información de rendimiento del proyecto, a la vez que elabora tendencias, ajusta métricas, mejora procesos y, sobre todo, trabaja para mantener el proyecto en su curso planificado. 4.4.1 Técnicas y herramientas 4.4.1.1 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1 4.4.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) DOC nº 039 – Solicitud de cambios (Change requests) DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project Management plan updates)

DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates) 4.5 Control integrado de cambios (Proceso que corresponde a la fase de control del proyecto) Este es el proceso donde se decide si un cambio solicitado podrá ser implementado o no, acorde con un procedimiento previamente establecido. Los cambios en un proyecto son inevitables y pueden ser solicitados por cualquier interesado del proyecto, impuesto por alguna ley o exigido por factores relacionados con la competencia y/o el mercado. La implantación de un cambio es una gestión que se hace de forma planificada, valorando, sobre todo, su impacto y las posibles consecuencias. Nadie puede asumir que un proyecto será ejecutado sin que se produzcan cambios. Cualquier tipo de proyecto, durante su ciclo de vida, estará sujeto a modificaciones que podrán repercutir tanto en el alcance como en sus plazos y costes. En proyectos como los de la construcción, que suelen ser más estables, algunos cambios no llegan a afectar el desarrollo del proyecto. En proyectos más sensibles, como son los de informática, un único cambio, dependiendo de su dimensión, puede llevar todo el proyecto al fracaso. El desafío del Project Manager consiste en cómo manejar estos cambios, minimizando los eventuales impactos provocados. De los factores que normalmente generan cambios en un proyecto, podemos destacar: Cambios en los requisitos del cliente. Aprobación de leyes o reglamentaciones. Nuevas tecnologías. Cambios en el entorno macroeconómico. Aparte de estos factores externos, frecuentemente nos podemos encontrar con proyectos que son débilmente estructurados: el equipo tiene un plan, pero no lo organiza de forma adecuada y, conforme el proyecto avanza, algunos conceptos se van aclarando mejor y, como consecuencia, las especificaciones

anteriormente realizadas tendrán que ser modificadas. Hay casos en que se hace necesario parar el trabajo y empezarlo otra vez. Proyectos desarrollados de esta forma suelen consumir mucho más recursos que los asignados originalmente y difícilmente son terminados. Por otro lado, aunque exista una planificación detallada, estructurada y bien organizada, el cambio puede ser inevitable. A medida que el proyecto avanza, se producen modificaciones, añadidos, observaciones que hacen que la especificación original cambie y produzca un impacto en el trabajo planificado. En algunos casos, los cambios son el reflejo de la madurez del personal involucrado que ha evolucionado en su forma de pensar y ha decidido de alguna manera mejorar aspectos antes ignorados que aportarán beneficios al proyecto sin perjudicar su línea base planificada. 4.5.1 Técnicas y herramientas 4.5.1.1 Sistema de control de cambios (Change control System) Casi todos los proyectos que son desarrollados sufren cambios por alguno motivo. Cuanto más largo y complejo sea un proyecto, mayor es la posibilidad de que sufra algún cambio. En casi todos los casos, los cambios en un proyecto son inevitables, y por ello es importante estar preparado para afrontar el momento de realizar las eventuales acciones correctivas, cuando estos cambios ocurran. De las situaciones más comunes de solicitud de cambios podemos destacar: La aprobación de una nueva ley. Una petición inesperada por parte del cliente. Un cambio de tecnología. Un cambio de estrategia organizacional. Un error o una omisión en la línea base del alcance. También podemos encontrar las siguientes situaciones: El cliente solicita que se incluyan nuevos elementos al producto.

El líder técnico solicita que se incrementen los plazos de entrega de un determinado elemento. Los técnicos solicitan la compra de nuevos equipos que no estaban previstos en el presupuesto original. Una nueva ley puede frenar el desarrollo de un determinado componente. La competencia puede desarrollar algún tipo de producto que nos obligue a cambiar nuestra estrategia. Un proyecto es estructurado de forma integral y cualquier cambio en el proyecto podrá repercutir en su estructura principal o provocar un determinado impacto. Para evitar que se produzcan cambios en un proyecto de forma arbitraria y sin planificación, se utiliza un sistema de control de cambios que establecerá la forma como un determinado cambio en el proyecto será administrado. Los cambios solicitados deberán ser previamente analizados por una junta de expertos que se encargará de aprobar, rechazar o postergar las solicitudes de cambios. Esta junta de expertos normalmente está compuesta por líderes técnicos, consejeros y directivos que cuentan con la autoridad suficiente para aprobar o rechazar una solicitud de cambio. Las solicitudes de cambios se desarrollan a través de un procedimiento específico, según ilustra la figura 33. Las acciones deben estar respaldadas por una documentación que registre todo el proceso de solicitud de cambios.

Figura 33: Flujo de control de cambios del alcance Solicitud de de cambios: Es el proceso que permite a cualquier interesado solicitar una petición de cambio en el proyecto. A priori, se identifican las necesidades de realizar un determinado cambio en el proyecto y a continuación se genera un documento formal de solicitud de cambios (change requests, descrito en el Apéndice A, doc nº 039), que será remitido al Project Manager.

Figura 34: Peticiones de cambio Revisión de la solicitud de cambios: Esta acción es realizada por el Project Manager que encargará a una junta de expertos la realización de un estudio que determine la viabilidad de dicha petición. Es importante resaltar que, en algunos casos, el propio Project Manager tiene la autonomía para rechazar esta petición, antes mismo de enviársela a la junta de expertos. De hecho, este proceso sirve como una especie de “filtro”, puesto que en algunos proyectos producen una cantidad desproporcionada de peticiones que muchas veces son contraproducentes. Estudio de viabilidad: Cuando la petición de cambio ha pasado satisfactoriamente por la revisión del Project Manager, una junta de expertos realizará un estudio que determinará la viabilidad de cambio solicitado (descrito en la sección 4.5.1.2). Los criterios aceptación de un cambio normalmente pasan por las siguientes evaluaciones: Requisitos necesarios para la puesta en marcha de los cambios solicitados. Posibles alternativas. Costes y beneficios. Riesgos. Posibles impactos en los costes, plazos, recursos y calidad del

proyecto. Después de realizar las evaluaciones anteriormente citadas, el estudio de viabilidad culminará con una de las siguientes conclusiones: Se podrá encajar el cambio solicitado sin afectar los recursos consumidos ni los plazos: Esta es la situación más sencilla y más optimista. Ocurre en los casos en que la junta de expertos analiza la petición de cambio y entiende que este cambio no será significativo lo suficiente para provocar cualquier impacto al proyecto. Se podrá encajar el cambio solicitado, pero afectará el plazo final del proyecto: En este caso, el plazo de conclusión del proyecto será aplazado para poder encajar el cambio solicitado, sin necesidad de incrementar los recursos utilizados. Se podrá encajar el cambio solicitado, sin cambiar el plazo, pero necesitará consumir más recursos: El proyecto necesitará de más recursos para poder realizar el cambio solicitado sin aplazar su plazo de finalización. Se podrá encajar el cambio solicitado, pero afectará el plazo final del proyecto y necesitará consumir más recursos: Los recursos y plazos disponibles no serán suficientes para encajar el cambio solicitado. Los cambios solicitados empiezan provocar impactos significativos. Se podrá encajar el cambio solicitado cambiando la estrategia del proyecto y priorizando las entregas más urgentes: Es muy frecuente que un proyecto sufra grandes cambios a lo largo de su ciclo de vida, que conllevan a modificaciones importantes en el plan, que exigirá una amplía revisión en la documentación del proyecto, de los plazos de entrega y del presupuesto. No se podrá encajar el cambio solicitado sin realizar un cambio radical en el proyecto: Hay casos en que los cambios solicitados

son tan drásticos que prácticamente anularía toda la planificación anteriormente realizada. El presupuesto, los plazos y los recursos estimados, todo tendría que ser totalmente revisado. En situaciones de esta magnitud la junta de expertos solo podrá optar por dos salidas: a) Rechazar el cambio solicitado y seguir con el proyecto original (aceptando todos los riesgos implicados). b) Anular el proyecto en marcha, planificarlo otra vez y arrancar un proyecto nuevo con los cambios incluidos (asumiendo todos las consecuencias que está decisión podrá provocar). Finalmente, tras realizar todos los análisis necesarios para determinar la decisión más adecuada a la petición de cambio, la junta de expertos emitirá un informe de respuesta a la solicitud de cambios que podrá contener las siguientes conclusiones: Rechazar la petición de cambio: Son muchas las razones por las que la junta de expertos podría rechazar una petición de cambio, como, por ejemplo, que los cambios solicitados puedan provocar un impacto importante que no generaría beneficios que justifiquen dicho cambio o que el cambio solicitado no añadiría ningún valor al proyecto o, asimismo, que los costes generados por dicho cambio podrán ser muy altos. Solicitar más información: Es posible que la junta de expertos no sea capaz de llegar a una conclusión, por la escasez de información remitida por la persona que ha solicitado el cambio. En este caso, la junta solicitará más datos para que se pueda realizar una investigación adecuada. Aprobar la petición de cambios: Si el cambio solicitado cumple con los requisitos determinados por la junta de dirección, esta procederá con la aprobación formal de esta solicitud.

Aprobar la petición de cambio con restricciones: Hay casos en que la junta de expertos aprueba la petición de cambio, pero impone algunas restricciones. En este caso, el solicitante evaluará si los cambios propuestos podrán ser puestos en marcha bajo las restricciones impuestas por la Junta de Expertos. Los criterios de aprobación o rechazo de una determinada solicitud de cambios normalmente tendrán en cuenta los siguientes criterios: Posibles impactos en el proyecto, derivados de la implantación de los cambios propuestos. Posibles impactos en el proyecto, derivados de la no implantación de los cambios propuestos. Implantación: Consiste en implantar los cambios aprobados y autorizados por la junta de expertos. El Project Manager, entonces, remitirá al solicitante la autorización para la realización de los cambios, y realizará las siguientes gestiones: Comunicar a todos los involucrados del proyecto los cambios que serán realizados. Planificar la forma como los cambios serán implantados. Realizar la Implantación de los cambios previstos. Actualizar la documentación correspondiente. Una buena gestión de cambios de un proyecto empieza en la línea base que debe ser establecida en el principio del proyecto, sobre todo porque la peticiones de cambios que vayan siendo aprobadas modificarán su estructura de modo que se quedará muy distinta a la línea base original. Sin embargo, la organización contará con importantes registros de los cambios solicitados, aceptados y rechazados que servirán de referencia en proyectos futuros similares. Además, con la línea base siempre actualizada, será posible evaluar el impacto real de los cambios solicitados. Es importante que el Project Manager tenga el cuidado de preservar las líneas bases originales de alcance, costes y plazos para poder realizar comparativas entre las primeras líneas

bases estimadas y las líneas base realizadas.

Figura 35: Proyecto realizado con pocos cambios en el alcance

Figura 36: Proyecto realizado con muchos cambios en el alcance NOTA DEL AUTOR En los contratos confeccionados para el proyecto, es muy recomendable que

se establezcan claramente quienes son las personas que tienen autoridad para iniciar y aceptar los cambios. La implementación de cambios no autorizados es frecuentemente la causa de muchas disputas, por ello, todo cambio solicitado solamente debe ser aceptado o rechazado por la(s) persona(s) autorizada(s) según establecido en una cláusula contractual correspondiente. Se trata de una medida preventiva que evitará una eventual pérdida de control sobre el proyecto debido a la implementación de cambios no autorizados. Algunos de los cambios aceptados deberán ser incorporados de manera formal al contrato, puesto que podrán provocar modificaciones importantes en los planes de gestión del proyecto, políticas, procedimientos, costes o cronogramas. Por otro lado, pueden existir los cambios impugnados (reclamaciones, conflictos, apelaciones, etc.), que son aquellos cambios solicitados respecto de los cuales el adquiridor y el proveedor no logran acordar la compensación correspondiente debido a los mismos. Estos cambios son documentados, procesados y gestionados a lo largo del ciclo de vida del contrato, obedeciendo los términos contractuales acordados. 4.5.1.2 Estudio de viabilidad (Feasibility study) Como su propio nombre indica, el estudio de viabilidad es una forma de determinar si un determinado cambio es viable. Se trata de una herramienta que nos ayudará a contestar una pregunta muy frecuente en el entorno empresarial: “¿Podemos seguir por este camino?”. El estudio de viabilidad es algo imprescindible y que debe ser realizado antes de poner en marcha un cambio. Sus resultados podrán ahorrarnos dinero y tiempo, además de prevenirnos de eventuales riesgos que quizás no serían correctamente identificados al no realizarse este tipo de estudio. Un estudio de viabilidad completo deberá realizar el análisis de los siguientes apartados: Viabilidad técnica o tecnológica: A través de un análisis de las alternativas tecnológicas disponibles para el proyecto, se

determinan los requisitos y dificultades de implantación. Además, el estudio de la viabilidad técnica determinará si la empresa y su plantilla cuentan con la experiencia y el conocimiento suficientes para su desarrollo, y si los equipos disponibles pueden soportar los requisitos técnicos necesarios. Viabilidad financiera: El análisis financiero es uno de los estudios que se realizan con más frecuencia, ya que suele ser uno de los factores que determinan la aprobación de un cambio. Este estudio analizará la capacidad de la empresa en asumir los costes generados, si el cambio incrementará la receta de la empresa y consecuentemente, impactará positivamente en sus ganancias. Viabilidad legal: Determina si el cambio puede llegar a tener algún conflicto con la legislación vigente, como por ejemplo, alguna normativa medioambiental. Viabilidad operacional: Determinará si la empresa posee las condiciones necesarias o cuenta con los recursos apropiados para realizar un cambio. Viabilidad de plazos: Determina si el cambio podrá ser realizado dentro de un plazo viable. Viabilidad de mercado: Determinará si el cambio tiene salida comercial y si existe un mercado consumidor. Viabilidad de recursos: Este apartado contempla cuestiones acerca de la capacidad de la empresa de desarrollar el cambio propuesto en función de su plantilla, instalaciones, equipos, entre otros. 4.5.1.3 Gestión de la configuración (Configuration management) Esta técnica es muy utilizada en entornos de desarrollo de software, debido, básicamente, a la inestabilidad que este tipo de proyecto conlleva. En el

ámbito del desarrollo de software es un hecho común que los requisitos inicialmente establecidos cambien a medida que el proyecto evoluciona, muchas veces provocando errores que generan múltiples versiones del código fuente del programa. Por todo ello, la gestión de la configuración es una técnica muy oportuna, puesto que permite llevar un correcto control de los cambios producidos a lo largo de la evolución del proyecto, manteniendo de esta forma, la integridad del producto, desde la fase de requisitos hasta alcanzar la fase final de pruebas, asegurando sobre todo: La validez de todo producto obtenido durante cualquiera de sus fases de desarrollo. La producción de cambios controlados. La disponibilidad de una versión única y estable para todos los involucrados que la manejan. Esta gestión, además, facilita el mantenimiento del sistema, aportando la información adecuada que permitirá realizar una valoración del impacto de un cambio solicitado, reduciendo de esta forma, el tiempo de implantación de dicho cambio. Una adecuada gestión de la configuración puede además, hacer un control global del sistema, aportar informaciones acerca del estado de su desarrollo y reducir el número de errores que puedan llegar a producirse, generando un sistema estable, fiable y acorde con los requisitos del cliente. Según la gestión de la configuración definida en MÉTRICA v3, los elementos de configuración del software incluyen: Ejecutables. Código fuente. Modelos de datos. Modelos de procesos. Especificaciones de requisitos.

Pruebas. Y para cada uno de estos elementos se almacenará al menos: Nombre. Versión. Estado. Localización. MÉTRICA es una metodología de planificación, desarrollo y mantenimiento de sistema de TI promovida por el Ministerio de Administraciones Públicas del Gobierno de España para la sistematización de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas. Esta metodología propia está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination). 4.5.1.4 Informes de progreso (Progress report) Los informes de progreso pueden ser muy útiles para realizar un control efectivo de los costes del proyecto, y, además, se trata de una forma muy sencilla de hacerlo. En muchos casos, el Project Manager determina cuánto trabajo ha sido realizado, solicitando a su equipo un porcentaje estimado del trabajo realizado en cada actividad. No obstante, en muchos casos, el equipo no tiene claro un criterio que determine realmente el porcentaje de avance de una determinada actividad, como por ejemplo decir que “en la actividad 5.4.2 está casi un 90%”. Este porcentaje no pasa de un sencillo “pálpito”, que poco o nada podrá aportar al control de costes del proyecto. De hecho, en muchos casos, encontramos actividades que han alcanzado rápidamente el 90% del trabajo realizado y luego se quedan en este procentaje para siempre. Es importante dividir todo el trabajo en paquetes de menor duración, como establece la EDT (descrita en la sección 5.3). De esta forma, trabajando con cortos plazos de finalización de estos paquetes, la estimación del trabajo realizado se vuelve más sencilla.

Por otro lado, existe una forma muy práctica de reportar el avance de un proyecto, sin recurrir a intuiciones sin fundamento. Se puede determinar con más exactitud, el avance de una determinada actividad a través de dos reglas diferentes: REGLA 50/50: La actividad obtiene un 50% de crédito cuando se inicia el trabajo, y el restante 50% se obtiene al finalizarlo.

Figura 37: Regla 50/50 REGLA 0/100: Una actividad es considerada 100% realizada cuando esté formalmente finalizada.

Figura 38: Regla 0/100 La principal ventaja de aplicar esta regla del 50/50, o la del 0/100, es que elimina la necesidad de determinar el porcentaje completado, que en la gran mayoría de las veces será un porcentaje equivocado. 4.5.1.5 Sistema de información de gestión de proyectos (Project management information system - PMIS) Descrita en la sección 4.2.1.3. 4.5.1.6 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1

4.5.1.7 Reunión de control de cambios (Change control meetings) La reunión de control de cambios ocurre siempre que se produce una petición de cambio en un proyecto. Su objetivo es realizar un estudio acerca de una petición de cambio, sus consecuencias e impactos en el proyecto. Una junta de expertos se encargará de aprobar o rechazar los cambios solicitados y, además, generará un informe con sus conclusiones. Esta reunión forma parte del sistema de control de cambios (descrita en la sección 4.5.1.1). 4.5.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project Management plan updates) DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates) DOC nº 046 – Plan de acciones correctivas (Corrective action plan) DOC nº 054 – Lecciones aprendidas (Lessons learned) DOC nº 039 – Solicitud de cambios (Change requests) Actualizaciones al estado de las solicitudes de cambio (Change requests status updates) - Las que correspondan al proceso 4.6 Cierre del proyecto o fase (Proceso que corresponde a la fase de cierre del proyecto) En un proyecto, es importante que todo esté debidamente documentado. La documentación es una forma que el Project Manager tiene de controlar su avance, los cambios implementados y cualquier incidencia o información

relevante. Cuando se termina el proyecto o una de sus fases, el Project Manager deberá realizar una revisión general de todos los cierres de fases anteriores, asegurando de esta forma el correcto cumplimiento de los objetivos definidos. Cualquiera sea la razón por la cual un proyecto se haya finalizado, su cierre debe pasar por un proceso formal. 4.6.1 Técnicas y herramientas 4.6.6.1 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1 4.6.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) Actualizaciones a los activos de los procesos de la organización (Organizational process assets update) - Las que correspondan al proceso.

Capítulo 5 Gestión del alcance Capítulo 5 - Gestión del Alcance

“No tiene sentido decir que lo hacemos lo mejor que podemos. Tenemos que lograr hacer lo que es necesario” Winston Churchill 20, estadista, historiador, escritor y orador británico

Algunas cosas en las que NO puedes pensar acerca de la gestión del alcance “¿Por qué no aprovechamos y le añadimos al cliente unas funciones extra al producto? ¡Seguro que le va a encantar!” Al principio, lo que suena como algo muy positivo podrá provocar un gran dolor de cabeza. Añadir más elementos sin que el cliente los hubiera solicitado podría significar un importante incremento de riesgo en el proyecto, que consecuentemente se traduciría en retrasos en los plazos establecidos. Si ocurre alguna incidencia en este sentido, lo primero que el cliente dirá es que los problemas empezaron a partir del momento que el Project Manager decidió añadir elementos al producto que no figuraban en los requisitos originales. Al cliente se le debe entregar solamente lo solicitado, ni más ni menos. Añadir “extras” es una pérdida de tiempo que no aportará ningún beneficio al proyecto.

“Olvídense de los requisitos del cliente. Nosotros sabemos lo que hacemos” Los requisitos funcionan básicamente como el hilo conductor de un proyecto y reflejan exactamente las necesidades y expectativas del cliente. La correcta captura y entendimiento de dichos requisitos permitirá, entre otras cosas, gestionar las necesidades del proyecto de forma estructurada, mejorar la capacidad de predecir costes, plazos y riesgos, adoptar las acciones preventivas adecuadas y sobre todo asegurar a aceptación final del cliente. “El alcance completo lo definimos en una fase más avanzada” No todos los proyectos pueden tener su alcance definido durante su fase inicial. Es un reto muy difícil de alcanzar, sobre todo en proyectos innovadores, como son los de desarrollo de software, diseño de un nuevo móvil, por ejemplo. Cuando es posible disponer de toda la información para definir el alcance completo en la fase inicial del proyecto, lo ideal es definirlo sobre la marcha, a través de metodologías de planificación gradual, mitigando de esta forma los riesgos implicados.

Introducción El alcance del proyecto es el trabajo que debe realizarse para entregar un producto con las características y funciones específicas, o como define el PMBOK® de forma muy acertada, la gestión del alcance debe “incluir los procesos requeridos para asegurar que el proyecto incluya todo el trabajo necesario, y solamente el trabajo necesario, para completar el proyecto con éxito”. En otras palabras: Verificar constantemente que las tareas asignadas al proyecto están siendo completadas de acuerdo con el plan. Rechazar cualquier actividad adicional no prevista en el proyecto o que no forme parte de la EDT. Evitar a todo coste el “gold plating” (entregar más cosas que las el cliente ha solicitado). La correcta gestión del alcance es imprescindible, pues a partir de ella se desarrollarán las estimaciones de plazo, costes y recursos. Una de las razones por la cual un proyecto falla, es porque su alcance ha sido mal definido. Son varias las razones que comprometen el alcance del proyecto. Una de las razones más comunes es que muchas veces el cliente tiene una idea supervalorada del proyecto, es decir, el cliente cree que el proyecto irá generar algo espectacular. Además, en las primeras reuniones con el equipo, normalmente el cliente tiene la sensación que el equipo tiene el proyecto totalmente claro en la mente, con lo cual no es imprescindible planificar el alcance. Es un raciocinio equivocado que inevitablemente irá provocar serios problemas más tarde. Además, existen casos en que un Project Manager no tiene la costumbre de desarrollar una EDT (véase también 5.3), que es una herramienta clave en la gestión del alcance. Bajo el enfoque de la cuarta edición del PMBOK®, la Gestión del Alcance

de un proyecto incluye los procesos y actividades necesarios para garantizar que el proyecto incluya todo (y únicamente todo) el trabajo requerido para completarlo con éxito. Incluye los siguientes procesos: Recopilar requisitos. Definir el alcance. Crear la EDT. Verificar el alcance. Controlar el alcance. 5.1 Recopilar requisitos (Proceso que corresponde a la fase de planificación del proyecto) La recopilación de requisitos es el proceso que documenta las necesidades de los interesados y que define los objetivos del proyecto. Uno de los factores de suceso de un proyecto depende del cuidado que se tenga en obtener correctamente los requisitos de un cliente y él saber gestionarlos adecuadamente. Se puede decir que los requisitos son “los intereses documentados del cliente”. Allí residen sus expectativas, ilusiones y deseos que en algunos casos pueden ser muy subjetivos o mal aclarados, y por ello es fundamental su completa documentación. Los requisitos además, constituyen la base de la EDT (véase también sección 5.3) y son el marco de planificación de costes, plazos y recursos. NOTA DEL AUTOR A veces el cliente no sabe lo que quiere Una reunión de recopilación de requisitos tiene como objetivo desarrollar una documentación completa que permita al equipo del proyecto el pleno entendimiento de todo el trabajo que deberá ser ejecutado para cumplir las expectativas del cliente. El problema reside cuando es el propio cliente el que no tiene claro lo que necesita, puesto que muchas veces viene influenciado o amparado por “ideas” mal fundamentadas y con escasa información. Al no tener clara la definición de requisitos, cualquier intento de desarrollo de

sus exigencias será una total pérdida de tiempo y dinero. Es fundamental que el cliente tenga claro sus requisitos de forma que permita al equipo del proyecto comprehender cada parámetro que conducirá el objetivo final que el proyecto pretende alcanzar. No obstante, es importante tener en cuenta que el cliente muchas veces no es un experto y por ello no tendrá plenas condiciones de proporcionar la información necesaria para establecer claramente los requisitos del proyecto. Por todo ello, la comunicación es un factor clave en la recopilación de requisitos. Es fundamental que cliente sepa exponer exactamente lo que desea y el equipo de proyecto debe entender claramente sus necesidades. Si un cliente no es un experto, debería contar con profesionales que pudiesen aportarle las aclaraciones que necesita para cumplir con sus necesidades. En caso contrario, hay que intentar guiarle y lograr que entienda exactamente lo que necesita y cuál es el resultado final esperado.

(1) Cómo el cliente lo explicó, (2) cómo el líder del proyecto lo ha entendido, (3) cómo el analista lo diseñó, (4) forma en que el programador lo escribió, (5) forma en que el consultor de negocios lo describió, (6) cómo el proyecto fue documentado, (7) qué el departamento de operaciones ha instalado, (8) cómo se le factura al cliente, (9) la forma en la que recibe soporte, (10) lo que el cliente realmente quería. Figura 39: Requisitos del cliente. Si el cliente no es capaz de expresar claramente sus necesidades o si el equipo de proyecto no logra comprenderlas correctamente, el resultado final de un proyecto podrá convertirse en un auténtico desastre.

5.1.1 Técnicas y herramientas 5.1.1.1 Entrevistas (Interviews) La entrevista es una técnica que consiste en reunir a una o más personas, especialistas en una determinada materia, con el objetivo de recopilar datos que puedan ser útiles a alguna cuestión relacionada con un proyecto. Tiene una gran importancia en el proceso de recopilación de requisitos, puesto que permite obtener determinadas conclusiones sobre lo que se está investigando. Ventajas: Es una técnica sencilla, de bajo coste y muy flexible que permite obtener datos relevantes. La información recopilada es muy superior a la obtenida cuando está limitada a la lectura de una respuesta escrita. Se pueden captar los gestos, tonos de voz, énfasis..., que aportan una importante información sobre el tema y sobre todo sobre las personas entrevistadas. No obstante, la principal ventaja de la entrevista reside en la capacidad que esta técnica tiene de poder extraer directamente del entrevistado sus verdaderas sensaciones, expectativas, puntos de vistas, opiniones y deseos, que serían muy difíciles de obtener a través de otro medio menos directo. Desventajas: Si el entrevistador no logra producir una pauta adecuada, no será posible extraer del entrevistado la información que se necesita. Puede haber por parte del entrevistado, un cierto desinterés en responder las preguntas propuestas. También hay casos de personas que se inhiben ante un entrevistador, y por ello, les cuesta responder con seguridad.

Es común encontrarse con interlocutores que mienten, deforman o exageran en sus respuestas, perjudicando de esta forma la calidad de los resultados esperados. De acuerdo con el objetivo que se pretenda alcanzar, se puede desarrollar una entrevista estándar, que planteará a los entrevistados exactamente las mismas preguntas y en el mismo orden. Como principal desventaja, este tipo de entrevista no permite expresar la opinión del entrevistador. Sin embargo, sus resultados son muy fáciles de procesar, simplificando el proceso comparativo. Por otro lado, existen las entrevistas “no estructuradas”, que se caracterizan por su flexibilidad, aunque se rige a su objetivo principal. Su principal ventaja es la capacidad de adaptación acorde con el entrevistado o la situación, permitiendo además profundizar sus reflexiones. Como desventajas, requiere una inversión importante de tiempo y los resultados obtenidos no más difíciles de tabular. 5.1.1.2 Grupos de opinión (Focus groups) Esta técnica consiste en reunir un determinado grupo de personas para discutir un asunto específico de carácter técnico, comercial, político, organizacional, entre otros aspectos. En el caso de la recopilación de requisitos, podemos, por ejemplo, imaginar que el grupo esté formado por potenciales clientes de un producto y/o servicio. Es similar a la lluvia de ideas (brainstorming, véase también sección 11.2.1.8), pero tiene un matiz fundamental que de mantener el grupo constantemente enfocado en una determinada cuestión. Con un moderador encargado de hacer las preguntas y dirigir la discusión, su objetivo es coordinar el grupo para que esté debidamente enfocado y no se distancie del tema de estudio, por ello viene el nombre en inglés: “focus group”.

Toda la dinámica de la reunión está pensada para que los participantes se sientan cómodos y a gusto para poder expresar sinceramente sus opiniones y sugerencias. En el mundo del marketing, este tipo de reuniones son consideradas una herramienta fundamental para extraer los deseos y necesidades de un determinado grupo de clientes y/o consumidores. Las informaciones generadas son de extremo valor para la creación de los requisitos que compondrán un futuro servicio o producto. Para que las secciones de grupos de opinión sean exitosas, es importante cumplir con algunos requisitos: Impedir que el grupo pierda el foco central de la sección y pierda tiempo en asuntos de poca trascendencia. Elaborar un guión de desarrollo que servirá para iniciar y cerrar la discusión. Limitar la participación y la duración de la reunión (no deberían sobrepasar las dos horas). Es habitual que algunos participantes se dejen llevar por la presión del grupo, cambiando su opinión, lo que produciría una cierta “contaminación” en los resultados. Es importante que el moderador esté bien entrenado para saber manejar adecuadamente el grupo. 5.1.1.3 Talleres facilitados (Facilitated workshops) Muchos proyectos sufren cambios importantes en su alcance, principalmente porque la recopilación de sus requisitos no ha sido correctamente realizada. Frecuentemente, nos encontramos con requisitos provenientes de resultados cruzados, mal documentados y muchas veces recopilados de personas que no tienen claro los objetivos del proyecto. La obtención de requisitos fiables depende de la puesta en marcha de un ambiente controlado y con la participación de las personas adecuadas. Y esto se puede conseguir, a través de talleres facilitados.

Los talleres facilitados son secciones en donde se reúnen los interesados del proyecto para definir los requisitos de un producto o servicio. Para que estas secciones proporcionen una información fiable, es fundamental que los interesados que formen parte de estas reuniones, conozcan el sector afectado y tengan experiencia en proyectos anteriores similares. Este grupo emitirá una opinión fundamentada en un análisis de los objetivos del proyecto, las necesidades y expectativas del cliente, el entorno de su negocio, etcétera. Uno de los talleres facilitados más conocidos en la industria del software es el JAD (joint applicaion development - desarrollo conjunto de aplicaciones). Su filosofía cumple con la idea básica de los talleres facilitados*: La gente que hace un trabajo tiene la mejor comprensión de ese trabajo. La gente entrenada en tecnologías de la información tiene la mejor comprensión de las posibilidades de esas tecnologías. Los sistemas de información y los procesos del negocio raramente existen en forma aislada - Más bien trascienden los límites de cualquier sistema u oficina y afectan el trabajo en departamentos relacionados. La gente que trabaja en estas áreas relacionadas tiene una percepción valiosa del papel del sistema dentro de una comunidad más amplia. Los mejores sistemas de información se diseñan cuando todos estos grupos trabajan juntos en un proyecto como socios iguales. * Fuente: Wikipedia. Los talleres facilitados pueden generar los requisitos exactos que el proyecto necesita, además de proporcionar mejor las metas comunes del proyecto y el fortalecimiento del grupo involucrado en su desarrollo. 5.1.1.4 Técnicas de creatividad en grupo (Group creativity techniques)

Una de las habilidades más impresionantes del ser humano es la creatividad, que, sin lugar a dudas, ha sido una de las bases fundamentales para el avance del hombre en el campo de las artes, la arquitectura, la ingeniería, la informática y los negocios en general. Acorde con Diane E. Papalia 21 en su libro Psicología del desarrollo, la creatividad consiste en la habilidad de ver las cosas bajo una nueva perspectiva e inventar luego soluciones nuevas, originales y eficaces. Existirían por lo tanto dos tipos de pensamiento que se relacionarían con la resolución de problemas y la creatividad: El pensamiento divergente, que es la capacidad para descubrir respuestas nuevas y originales. El pensamiento convergente, que lo define como la capacidad para descubrir una única respuesta correcta. Estos pensamientos estarían también altamente relacionados con la motivación, los conocimientos previos, el aprendizaje, la independencia de carácter y la determinación. Todos estos conceptos se encajan perfectamente en uno de los aspectos más recalcados en este libro: un proyecto de éxito depende sobre todo de reunir las personas ciertas, en el momento oportuno, con los conocimientos adecuados y, según lo que establece lo anterior, con capacidad de descubrir soluciones nuevas y originales. Son muchas las técnicas para fomentar y motivar la imaginación de las personas, algunas de ellas se encuentran ampliamente explicadas en este libro, las podrá encontrar en los puntos a continuación: Lluvia de ideas (Brainstorming): Descrita en la sección 11.2.1.8. Técnica de grupo nominal (Nominal group technique): Descrita en la sección 11.2.1.9.

Técnica delphi (Delphi technique): Descrita en la sección 6.4.1.7. Técnica crawford slip (Crawford´s slip writing method): Descrita en la sección 11.2.1.11. Mapa conceptual (Concept map): Descrita en la sección 11.2.1.13. Diagrama de afinidad (Affinity diagram): Descrita en la sección 11.2.1.14. 5.1.1.5 Técnicas de toma de decisión en grupo (Group decision making) La tomas de decisión en grupo es un proceso que reúne a un grupo de personas con el objetivo de tomar, de forma conjunta, la mejor decisión posible frente a una determinada situación. Algunos de los métodos más utilizados para llegar a una decisión en grupo son: Unanimidad: Ocurre cuanto todos los participantes están de acuerdo en poner en marcha una única línea de acción. Mayoría: La decisión elegida cuenta con el apoyo de por lo menos 51% de los miembros del grupo. Pluralidad: El bloque más grande de todo el grupo de participantes toma la decisión, aunque no se alcance la mayoría. Dictadura: Cuando una persona decide el curso de la acción, sin considerar la posición de los demás. 5.1.1.6 Cuestionarios y encuestas (Questionnaries and surveys) Las encuestas pueden ser útiles en la recopilación de requisitos, y como dicho

anteriormente, siempre y cuando los encuestados sean profesionales del sector con experiencia y provistos de conocimientos que aporten calidad a los resultados de la encuesta. Estos resultados se obtienen a partir de un conjunto de preguntas dirigidas a una muestra representativa o al conjunto total de de una población estadística en estudio, formada por profesionales, empresas o entes institucionales y con el objetivo, en nuestro caso, de recopilar los requisitos necesarios para desarrollar un determinado producto y/o servicio. La encuesta tiene la ventaja de ser una acción de bajo coste y que suele recopilar la información exacta. No obstante, la calidad de los resultados obtenidos dependerá fundamentalmente de dos factores: de la selección de las preguntas correctas y de la elección de los encuestados adecuados. 5.1.1.7 Observaciones (Job shadowing) Ampliamente utilizada en las escuelas secundarias americanas, es conocida como Job Shadowing, esta técnica trata de introducir a jóvenes estudiantes en ambientes reales de trabajo (oficinas, talleres, bufetes, entre otros), donde podrán observar en primera persona, como trabajan los profesionales en sus áreas de actuación y hacerles preguntas acerca de su trabajo. Esta experiencia les aportará la información que necesitan para conocer mejor determinadas profesiones y ayudarles a decidir acerca de su futuro profesional. En el campo del Project Management, esta técnica es utilizada para observar de forma directa como un profesional realiza su trabajo y ejecuta sus procesos, de esta forma, el observador podrá constatar cómo se hace el trabajo y descubrir determinados requisitos desconocidos. Son extremadamente útiles para procesos detallados, cuando las personas tienen dificultades en detectar sus propias necesidades o no tienen claro cómo pueden mejorar sus proceso de trabajo. 5.1.1.8 Prototipos (Prototypes)

Un prototipo es básicamente un modelo operativo que contiene todas las características funcionales del producto que se pretende fabricar y es utilizado para hacer simulaciones y probar sus debilidades y fortalezas. Dado que es tangible, el prototipo permite hacer experimentos muy próximos a lo que llegaría a ser el producto final, en lugar de sóoo debatir de forma abstracta sobre sus requisitos. 5.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) DOC nº 004 – Documentación de requisitos (Requirements documentation) DOC nº 005 – Plan de gestión de requisitos (Requirements management plan) DOC nº 006 – Matriz de rastreabilidad de requisitos (Requerimiens traceability matrix) 5.2 La definición del alcance (Proceso que corresponde a la fase de planificación del proyecto) Esta fase normalmente es plagada por el entusiasmo general. Existe una sensación de que todo puede ser hecho y que el proyecto será desarrollado sin incidencias. Es una sensación un poco peligrosa, pues conllevará a confeccionar un alcance muy complejo con más artículos de los que realmente el producto o el servicio necesitan para cumplir su objetivo, que además de innecesarios, no interesarán al cliente. Cualquier problema que surja a raíz de ellos, conllevará a pérdidas importantes de tiempo y recursos. Para impedir que esto ocurra, es importante reunir el equipo del proyecto y a los principales interesados para hacer una lista de los artículos que deben salir del primer borrador del alcance. Una vez realizado este filtro, llegaremos a lo que llamamos de “listado de requisitos”, que formará parte del plan de gestión de requisitos (véase también Apéndice A, doc nº 005)

Este listado contendrá todos los elementos que el equipo y los interesados juzguen importantes para el proyecto. Si posible, es recomendable realizar una segunda ronda de verificaciones para comprobar si el listado de requisitos disponible hasta el momento, puede ser aún más reducido. Para asegurarse de que todos los artículos que están en este listado son realmente necesarios, es prudente que se desarrollen justificativas razonables para seguir manteniéndolos. Los artículos eliminados durante las secciones de verificación, no serán olvidados. Es recomendable documentar estos artículos en una “lista de requisitos excluidos”, que también formará parte del plan de gestión de requisitos (véase también Apéndice A, doc nº 005). Si no se documentan los artículos descartados en una lista de exclusión, estos volverán una y otra vez, siempre que se realice el proceso de definición del alcance. Una vez completada el listado de requisitos, el Project Manager podrá definir con su equipo, cuáles serán los entregables (deliverables) del proyecto. Un entregable, de acuerdo con el PMBOK® es “todo producto, resultado o elemento mensurable, tangible y verificable que deba entregarse para finalizar un proyecto, o parte de un proyecto”. Estos entregables deben ser formalmente aprobados por los interesados del proyecto, sobre todo por el cliente y los patrocinadores. No puede haber dudas que estos entregables, resultado de todos los filtros realizados en gestiones de definición del alcance, son los entregables definitivos del proyecto. Además es importante definir los resultados que cada entregable debe atingir y cuáles serán los criterios de aceptación. Estos cuidados iníciales evitarán que el alcance sea modificado durante el desarrollo del proyecto. El cambio de alcance es un factor crítico que, al ser cambiado, puede producir impactos negativos. Un alcance bien definido no debería sufrir ningún tipo de replanificacion posterior.

Figura 40: Acciones resultantes de los cambios en el alcance Realizadas todas las verificaciones pertinentes, será posible desarrollar los “paquetes de trabajo”. Estos paquetes, son las actividades necesarias para llevar a cabo la producción de un entregable. Para ello, usaremos una herramienta llamada estructura detallada del trabajo - EDT” o, WBS, su sigla en inglés. (Véase también la sección 5.3). 5.2.1 Técnicas y herramientas 5.2.1.1 Requisitos del proyecto (Project requirements) Descrito en el documento nº 004 del Apéndice A. 5.2.1.2 Enunciación del alcance del proyecto (Project scope statement)

Descrito en el documento nº 007 del Apéndice A. 5.2.1.3 Planificación gradual (Rolling wave project planning – RWPP) La planificación gradual (Rolling Wave Project Planning – RWPP) es una técnica muy utilizada en proyectos que poseen un grado muy alto de incertidumbre, donde no se puede planear mucho más adelante, como pueden ser los proyectos de desarrollo de software. Una situación muy frecuente que nos encontramos es la de tener que empezar inmediatamente un proyecto, sin que este cuente con un alcance totalmente definido y no disponga de toda la información necesaria para planificar todo el proyecto. Esta técnica tiene un concepto extremadamente sencillo: se planifica hasta donde se pueda, es decir, hasta donde se tiene visibilidad o hasta donde la información obtenida en las fases anteriores nos permita llegar. Se va ejecutando lo planificado y a medida que el proyecto avanza y se recopila más información, se retoma la planificación de las siguientes fases. Para ello, el proceso más coherente es partir de una EDT (descrita en la sección 5.3) que contemple todas las fases y objetivos del proyecto. Se detallan entonces, las actividades de la primera fase, y conforme avanza el proyecto, se recopila más información. Al finalizar esta primera fase, las informaciones y conocimientos adquiridos serán utilizados en la EDT para planificar las actividades de la siguiente fase, en un ciclo que se mantiene hasta concluir el proyecto. Este procedimiento permite ejecutar el proyecto planificando la fase siguiente sobre la marcha. De todas formas, esta herramienta solo funcionará correctamente si el equipo y los interesados hayan establecido y reconocido previamente las fechas inicio y fin de la fase de cada una de las fases del proyecto.

Figura 41: Estimaciones basadas en desarrollo gradual 5.2.1.4 Descomposición (Decomposition) Utilizando la técnica de la descomposición, se hace la definición del alcance sobre cada componente en que descompone el proyecto o sobre las tareas de bajo nivel en que se descomponen otras tareas. Las definiciones de bajo nivel se combinan para producir la definición de cada actividad, y consecuentemente, de cada fase, hasta llegar al proyecto completo. La forma más conocida y más utilizada para hacer la descomposición del alcance de un proyecto es la técnica de la estructura detallada del proyecto – EDT (Work Breakdown Structure – WBS), descrita en la sección 5.3. 5.2.1.5 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1 5.2.1.6 Análisis del producto (Product analysis) El análisis del producto es una herramienta que tiene como objetivo conocer en profundidad todas las características generales de un producto, y con ello buscar mejorar la calidad de su desarrollo y fabricación. Es un análisis que se realiza a través de distintas etapas, cada una de ellas tratando de conocer

los diferentes entornos de un mismo producto. El análisis del producto se desarrolla de la siguiente forma: Análisis Morfológico: Define la forma del producto y sus características geométricas (volumen, ergonomía, etc.); Análisis Funcional: Define sus funciones y si estas cumplen con los objetivos planteados cuando ha sido creado; Análisis Estructural: Define qué elementos tiene y cómo se relacionan. Para ello es necesario el despiece del objeto y estudiar sus partes. Análisis de Funcionamiento: Define su funcionamiento, cumple correctamente con sus especificaciones;

y si

Análisis Tecnológico: Define su elaboración y sus materiales, cómo ha sido desarrollado y que procesos fueron realizados para su fabricación; Análisis Económico: Define su valor en función de sus costes (directos e indirectos), de diseño y fabricación, su logística de distribución y su precio final al consumidor; Análisis Comparativo: Define sus diferencias y/o similitudes con otros productos; comparando sus funcionalidades, efectividades y precisión. Análisis Relacional: Define su entorno y analiza sus elementos vinculables, por ejemplo: Si es un producto que necesita de energía eléctrica, que potencia necesitará para desempeñar su función correctamente, etc. Una vez finalizado el estudio completo del producto, sus resultados podrán aportar una serie de informaciones útiles que podrán mejorar su diseño y sus prestaciones. A nivel de Project Management, se podrá, de forma más precisa, establecer los costes, plazos y los recursos necesarios para su

desarrollo. 5.2.1.7 Talleres Facilitados (Facilitated Workshops) Descrito en la sección 5.1.1.3 5.2.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del Proyecto) DOC nº 007 – Enunciación de Alcance del Proyecto (Project Scope Statement) DOC nº 056 – Actualizaciones a los Documentos del Proyecto (Project Document Updates) 5.3 Creación de la EDT (Proceso que corresponde a la fase de planificación del proyecto) Este proceso consiste en subdividir todos los entregables de un proyecto en componentes más pequeños y más fáciles de manejar. Para ello, se utiliza la Estructura Detallada de Trabajo - EDT (Work Breakdown Structure – WBS), que realiza una descomposición jerárquica de las actividades del proyecto necesarias para lograr un determinado objetivo. La EDT organiza y define el alcance total de proyecto y facilita la estimación de sus costes, plazos y recursos. 5.3.1 Técnicas y Herramientas 5.3.1.1 Estructura Detallada del Trabajo - EDT (Work Breakdown Structure – WBS) También conocida como WBS (Work Breakdown Structure), es una de las herramientas más útiles y más populares en Project Management. Es sencilla y fácil de utilizar. Comprende la subdivisión de los principales entregables del proyecto en otros componentes más pequeños y manejables, de forma tal que los entregables sean definidos con suficiente detalle para responder a las

futuras actividades del proyecto. Cerca de 95% de las actividades de un proyecto pueden ser identificadas a través de esta herramienta. Además, sirve tantos para proyectos grandes como para pequeños. Es considerada por muchos, como la “fundación” del proyecto, puesto que aporta toda la información necesaria para realizar un seguimiento eficaz. Es una técnica fundamental de planificación de un proyecto y es muy útil para: Organizar y definir el alcance total del proyecto: Una regla básica de la EDT es: Si no se encuentra en la EDT, no puede formar parte del alcance; Mejorar las estimaciones de los plazos, costes y recursos que serán consumidos; Facilitar la comunicación entre los implicados del proyecto, permitiendo visualizar de forma gráfica el trabajo necesario para llevar a cabo sus actividades; Determinar las responsabilidades de cada integrante del equipo; Definir la línea base del alcance. Características Tiene un formato de árbol jerárquico, donde se organizan las actividades y se las agrupan en un primer nivel. A partir de este nivel, se desglosa el proyecto en subniveles, hasta llegar al último nivel, que constituye los paquetes de trabajo, que tienen un nivel de detalle que permita el control requerido por él. Una EDT tiene que contemplar todas las actividades de un proyecto, tiene que estar bien organizada y es fundamental que las actividades descritas en la EDT sean completamente entendidas por el equipo que las va a desarrollar. Si alguna actividad no está clara para el equipo, es aconsejable desglosarla en niveles más detallados.

Principales Elementos Código de Cuentas (Code of Accounts): Sistema numérico utilizado para identificar los elementos de la EDT; Plan de Cuentas (Chart of Accounts): Es un sistema numérico financiero utilizado para identificar cada elemento de la Estructura Detallada de Trabajo y para monitorizar los costes del proyecto por categoría (Ej.: mano de obra, materiales, maquinaria, etc.). El plan de cuentas es confeccionado de acuerdo con el plan de cuentas “maestro” desarrollado por la organización y que contiene las principales actividades de todos los proyectos desarrollados por la empresa; Paquetes de Trabajo (Work Packages): Es el entregable que se encuentra en el último nivel del árbol jerárquico de la EDT; Diccionario de la EDT (WBS Dictionary): Contiene la descripción detallada de los componentes que forman parte de cada actividad y cómo ellos serán desarrollados. Véase también doc 009, en el Apéndice A. ¿Cómo se confecciona una EDT? Para empezar a confeccionar una EDT es necesario identificar las tareas necesarias para llevar a cabo el desarrollo de un proyecto. Estas tareas deben ser divididas en fases y en secuencia cronológica. Un ejemplo muy sencillo de confección de una EDT es la pintura de una habitación, trabajo que representa uno de los entregables del proyecto de reforma de una casa. Preparar Materiales 1.1 Comprar pintura 1.2 Comprar masilla 1.3 Comprar escalera 1.4 Comprar accesorios

Preparar dormitorio 2.1 Retirar ropas 2.2 Retirar cuadros y espejos 2.3 Desmontar muebles 2.4 Cubrir el suelo Pintar el dormitorio 3.1 Lijar pared 3.2 Tapar grietas 3.3 Primera mano de pintura 3.4 Segunda mano de pintura Limpiar el dormitorio 4.1 Tirar o guardar el resto de la pintura 4.2 Limpiar pinceles y rodillos 4.3 Guardar o tirar accesorios 4.4 Retirar la protección del suelo 4.5 Montar los muebles 4.6 Guardar las ropas 4.7 Poner cuadros y espejos

Figura 42: EDT de una pintura de un dormitorio A cada elemento de una EDT se le asigna un identificador único (normalmente numérico). Los trabajos que no estén en la EDT quedan fuera del alcance del proyecto. Según ilustra el ejemplo de la pintura de un dormitorio, la EDT descompone las tareas de un proyecto, lo que comprende la subdivisión de los principales entregables del proyecto en otros componentes más pequeños y manejables, de forma tal que los entregables sean definidos con suficiente detalle para responder a las futuras actividades del proyecto (planificación, ejecución, control y cierre).

La EDT puede ser ilustrada en formato de tabla, según ilustra la figura 43 que se presenta aa continuación:

Figura 43: La EDT en formato de tabla La creación de la EDT debe seguir algunas reglas importantes: El primer nivel de la EDT corresponde al nombre del proyecto o fase. El segundo nivel de la EDT normalmente corresponde al ciclo de vida del proyecto (en proyectos de desarrollo de software estos niveles podrían ser: Requisitos, diseño, programación, pruebas y documentación). Cada nivel de la EDT debe ser más pequeño que el nivel anterior. Cada tarea de la EDT debe ser realista y estimable, no puede ser subdividida, debe ser de rápida ejecución (máx. de 80 horas) y debe ser ejecutada sin interrupciones. Deberá incluir todo el trabajo previsto para la ejecución del proyecto. Deberá contemplar todos los entregables, incluido de terceros. Deberá incluir las actividades de gestión de proyecto. Cada elemento deberá tener un identificador único. Cada elemento deberá corresponderse con un único entregable. Es importante utilizar nombres o codificaciones familiares a toda la empresa. El Diccionario de la EDT es muy útil en este sentido. ¿Existe algún límite para descomponer una EDT? Una EDT no debe ser demasiado grande ni demasiado limitada. En cualquiera de los casos se pueden producir problemas de entendimiento del proyecto. Si una actividad que tiene una estimación de diez meses de

finalización, es una actividad muy difícil de hacerse un seguimiento correcto. Lo mismo ocurre con una tarea que tiene una duración estimada de dos horas. El esfuerzo que conlleva hacer un seguimiento de una actividad de tan corta duración no es compensador. Se suele utilizar muy a menudo algunas reglas acerca de la descomposición de una EDT. Algunas organizaciones utilizan lo que se conoce por “regla 4/40” o “regla 8/80”. La regla 4/40 es utilizada cuando se establece que ningún paquete de trabajo puede tener una duración menor que 4 horas y mayor que 40 horas. Con la regla 8/80, ocurre lo mismo, pero con limites mayores. Para lograr una buena administración de un proyecto, una EDT no debe sobrepasar los cien objetos terminales. Si el proyecto es muy grande y sobrepasa este límite, es aconsejable montar varias EDT (se puede hacerlo por fases, por ejemplo). Es aconsejable también que una EDT no sobrepase 4 niveles. Normalmente, una EDT se descompone hasta llegar a una tarea desarrollada por un solo grupo funcional puro (pintores, albañiles, electricistas, entre otros). Será el responsable o encargado del grupo funcional el que realizará las estimaciones de tiempo y coste que se encuentran bajo su responsabilidad. NOTA DEL AUTOR La EDT es una herramienta que debe ser desarrollada por el Project Manager en conjunto con los equipos que trabajaran en ella. Además de poder contar con la experiencia de profesionales con experiencia, el desarrollo de esta estructura en equipo ayudará a todos los involucrados a entender mejor el proyecto. De esta forma, el equipo del proyecto podrá obtener el conocimiento suficiente para poder compartir informaciones y hacer con que el proyecto se desarrolle de forma más eficaz ya que, en muchos casos, una tarea será compartida a equipos distintos. Aunque cada proyecto es único, la EDT de un proyecto similar anterior puede ser utilizada como modelo para un nuevo proyecto. Normalmente, los proyectos desarrollados por la misma empresa contienen fases y ciclo de

vidas similares y muchas veces los mismos entregables El número de horas requeridas para el desarrollo de cada actividad además de sus costes asociados, deben aparecer en cada nivel de la EDT. Las primeras estimaciones financieras podrán ser realizadas a partir de la conclusión del diseño de la EDT, como ilustra la figura 44, a continuación:

Figura 44: Estimación de costes basado en una EDT 5.3.1.2 Estructura de desglose del producto – EDP (Product breakdown structure – PBS) Aunque muchos proyectos son desarrollados para la puesta en marcha de una solución integrada, algunos son realizados para el desarrollo de un producto específico (un coche, un móvil, un equipo informático...). En este tipo de proyecto, es imprescindible utilizar la estructura de desglose del producto DP (Product breakdown structure - PBS, en algunos casos también es conocida como Bill of materials – BOM). Se trata de una herramienta que permite confeccionar visualmente el listado de materias primas, componentes, accesorios y cantidades necesarias para producir un determinado artículo. Muchas empresas utilizan catálogos o banco de precios electrónicos de productos (como por ejemplo, BASELEC, BASEFON o BASEFER).

Figura 45: EDP de la fabricación de una PDA 5.3.1.3 Otros tipos de estructuras de desglose Estructura de desglose de la organización – EDO (Organization breakdown structure - OBS): Representa la parte del organigrama de la organización que formará parte del proyecto (descrita en la sección 9.1.1.4). Estructura de desglose de costes - EDC (Cost breakdown structure - CBS): Lista organizada de costes directos en los que incurrirá el proyecto (descrita en la sección 7.1.1.10). Estructura de desglose de riesgos - EDR (Risk breakdown structure - RBS): Lista organizada de riesgos del proyecto (descrita en la sección 11.2.1.5). 5.3.1.4 El diccionario de la EDT (WBS dictionary) La EDT es una herramienta imprescindible para organizar el alcance del proyecto. Sin embargo, tiene sus restricciones. Su uso se limita a organizar el alcance del proyecto e informar de los nombres de las actividades que forman

parte del proyecto. Será necesario conocer los componentes de cada actividad y cómo ellos serán desarrollados. Para ello, se utiliza el diccionario de la EDT, que incluirá la descripción detallada de todos los elementos de la EDT. Las instrucciones sobre su confección se encuentran en el documento nº 009 en el Apéndice A. 5.3.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) DOC nº 008 – Estructura detallada del trabajo - EDT (Work breakdown structure - WBS) DOC nº 009 – Diccionario de la EDT (WBS dictionary) Línea base del alcance. Véase sección 2.1.3 (Scope baseline) DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates) 5.4 Verificación del alcance (Proceso que corresponde a la fase de control del proyecto) Es el proceso que consiste en obtener la aceptación formal del alcance del proyecto por parte de los interesados correspondientes. Esta aceptación tiene como condicionante la revisión de los entregables del proyecto que deberán atender a los requisitos establecidos. Como requisito, podemos decir que es: “Una condición o capacidad que un producto o servicio tiene que poseer para cumplir con un contrato, especificación o cualquier otro documento formalmente impuesto”. Los requisitos incluyen las necesidades, los deseos y las expectativas del cliente o del patrocinador. Generalmente, clasificamos los requisitos en dos tipos: Obligatorios: forman parte inexcusable del proyecto.

Deseables: aportarían valor añadido a la satisfacción del cliente, pero no están incluidos obligatoriamente en el proyecto. Cuando hablamos de requisitos deseables, es muy importante no caer en la tentación de añadir requisitos que en vez de aportar beneficios al proyecto, puede perjudicar el buen funcionamiento del producto o servicio resultante. Esto suele suceder a menudo cuando se practica en gold plating (véase también capítulo 9 – Gestión de la calidad). 5.4.1 Técnicas y herramientas 5.4.1.1 Inspección (Inspection) La inspección funciona como si de una auditoria se tratara. Se realiza a través de mediciones y verificaciones que determinarán si los servicios o productos entregados cumplen con los requisitos establecidos en el plan de proyecto. Esta inspección puede ser realizada por el Project Manager, por algún miembro del equipo capacitado o incluso por el propio cliente (de hecho, lo suelen hacer antes de firmar la aceptación del proyecto). A veces, se contrata a un auditor externo con competencia para determinar si el producto o servicio desarrollado cumple con los requisitos establecidos previamente. Se suele hacer en formato de checklist que incluirá todos los componentes de la EDT del proyecto. Normalmente, suele tener los campos a continuación:

Figura 46: Checklist de artículos De acuerdo con los resultados de la inspección, el cliente podrá aceptar el producto/servicio entregado o rechazarlo. La forma en que se realizará la inspección, incluyendo cuales son los puntos considerados críticos, podrá ser detallada en el plan de proyecto. 5.4.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) Entregables aceptados (véase sección 2.4) (Accepted deliverables) DOC nº 039 – Solicitudes de cambio (Change requests) DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates) 5.5 Control de cambios del alcance (Proceso que corresponde a la fase de control del proyecto) Casi todos los proyectos que son desarrollados sufren cambios por alguno motivo. Cuanto más largo y complejo sea un proyecto, mayor es la posibilidad de que sufra algún cambio. En casi todos los casos, los cambios en un proyecto son inevitables, y por ello es importante estar preparado para afrontar el momento de realizar las eventuales acciones correctivas, cuando estos cambios ocurran. Los cambios de un proyecto pueden ser el resultado de muchos factores: La aprobación de una nueva ley. Una petición inesperada por parte del cliente. Un cambio de tecnología. Un cambio de estrategia organizacional. Un error o una omisión en la línea base del alcance.

A continuación, veremos las principales herramientas de control de cambios de alcance. 5.5.1 Técnicas y herramientas 5.5.1.1 Análisis de variación (Variance analysis) El análisis de variación es una herramienta utilizada para evaluar la magnitud de la variación respecto de la línea base original del alcance. Los aspectos importantes de control incluyen básicamente la determinación de la causa y del grado de variación entre la línea base original del alcance y la línea base actual. Se desarrolla de la siguiente manera: Se comprueba la calidad y la veracidad de la información recopilada a fin de asegurarse de que esté completa y de que sea coherente con datos anteriores. Se establecen las variaciones mediante la comparación de la información real con la línea base del proyecto, y la observación de todas las diferencias, tanto favorables como desfavorables. Se utilizan herramientas como el valor del trabajo realizado para cuantificar las variaciones. Se determina el impacto de las variaciones y sus consecuencias en el coste y en el cronograma del proyecto. Se documentan las conclusiones sobre las fuentes de variación y el área de impacto. El valor del trabajo realizado (earned value – EV) es descrito detalladamente en la sección 7.3.1.1. 5.5.1.2 Sistema de control de cambios del alcance (Scope change control system)

Descrito en la sección 4.5.1.1 5.5.1.3 Planificación adicional (Aditional planning) Son pocos los proyectos que se desarrollan exactamente según lo planificado. Prácticamente todos los cambios aprobados y aplicados al proyecto conllevarán la modificación de la documentación original, y por ello se hará necesario la revisión de los plazos, costes y recursos anteriormente establecidos. La planificación adicional tiene como objetivo mitigar cualquier impacto negativo causado por los cambios incluidos en el proyecto. Por ello es importante revisar toda la planificación anteriormente realizada y actualizarla acorde con la nueva situación del proyecto. 5.5.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) Mediciones del desempeño del trabajo. Véase sección 7.3.1.1 (Work performance measurements) Actualizaciones a los activos de los procesos de la organización (Organizational process assets updates) - Las que correspondan al proceso DOC nº 039 – Solicitudes de cambio (Change requests) DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project management plan updates) DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates) Cambios del alcance (Scope changes) - Los que correspondan al proceso DOC nº 046 – Plan de acciones correctivas (Corrective action plan)

DOC nº 054 – Lecciones aprendidas (Lessons learned) Línea base ajustada. Véase sección 2.1.3 (Adjusted baseline)

Capítulo 6 Gestión del tiempo Capítulo 6 - Gestión del Tiempo

“Pocos son los que tienen tiempo suficiente y, sin embargo,cualquiera tiene casi todo el tiempo que hay” Paradoja del tiempo

Algunas cosas en las que NO puedes pensar acerca de la gestión del tiempo “El cronograma es inútil, ya sabéis que no lo vamos a cumplir” Podemos considerar que un cronograma está bien hecho cuando refleja exactamente la realidad de su entorno. Es decir, un cronograma tiene que basarse en la correcta gestión de los calendarios, en la capacidad de ejecución por parte del equipo asignado y en la complejidad de cada actividad. El problema del incumplimiento de plazos no reside en el cronograma. Las causas son las mencionadas anteriormente: no se ha tenido en cuenta el calendario del proyecto, el equipo no tenía la capacidad esperada, o la complexidad de la actividad ha sido evaluada incorrectamente. “Os puedo asegurar, que mañana lo tenemos funcionando” “No dejes para mañana lo que puedas hacer hoy”. Este refrán, muy popular, significa exactamente lo que parece, y se encaja perfectamente a la gestión del tiempo del proyecto. Si puedes hacer algo ahora, no esperes al día siguiente. Si tienes una tarea en manos y hay tiempo y condiciones para iniciarla, lo ideal es ponerla en marcha para que se pueda finalizarla dentro del plazo. Una serie de incidencias no esperadas pueden llegar a ocurrir en un proyecto, lo que podrá provocar atrasos en la finalización de algunas actividades. Si a esto sumamos atrasos debidos a postergaciones innecesarias, el cronograma del proyecto podría colapsarse. “No es necesario obedecer la secuencia de actividades propuesta” Al analizar el cronograma de un proyecto, se podrá apreciar que las actividades obedecen a una lógica, que han sido investigadas y desarrolladas por un grupo de expertos. Prácticamente, todos procesos industriales, artesanales o incluso naturales obedecen a una secuencia lógica que no debería ser modificada. No se puede pintar una pared sin antes levantar los ladrillos, y tampoco es posible tomarse una copa de vino sin antes sacarle el corcho de la botella. Por lo tanto, si el cronograma presenta una secuencia de actividades, lo mejor es cumplirla a rajatabla.

“Esta medición, aunque parezca compleja, será realizada en tiempo récord” Existen tareas que necesitan un tiempo mínimo para que finalicen adecuadamente. El desarrollo de un proyecto no es una carrera contra el tiempo, es un emprendimiento que ha sido previamente estudiado y cuyas actividades deberán ser realizadas dentro de unos plazos compatibles con su naturaleza. “Podemos hacerlo con calma, porque disponemos de una buena reserva de tiempo extra” Las reservas de contingencia de tiempo existen para los casos de emergencia cuando, por razones especiales, el equipo no ha podido finalizar su labor en el plazo previsto y, por lo tanto, dispone de una reserva de tiempo extra para poder completar sus tareas. Por esta razón, no podemos ralentizar la ejecución de una tarea, pensando en una reserva de tiempo que tenemos disponible. Según la ley de Parkinson (Parkinson´s law), creada por Cyril Northcote Parkinson22 en un artículo publicado en el semanario británico The Economist, en el año 1955: “El trabajo se amplía para cubrir todo el tiempo disponible para su conclusión”. O sea, si una determinada tarea tiene un plazo estimado de seis días y se añaden dos días más como contingencia, según la ley de Parkinson, esta tarea llevará ocho días para ser completada. Por supuesto, esta teoría no pretende derrumbar la técnica de la reserva de tiempo, pero intenta demostrar que no será simplemente añadiendo un par de días más a cada tarea, que se alcanzará el cronograma perfecto; todo lo contrario, esta práctica puede tornarse un vicio que convertirá el proyecto en un emprendimiento interminable. Introducción Para muchos, gestionar un proyecto es lo mismo que confeccionar un cronograma. Sabemos que la gestión de un proyecto conlleva a la administración integrada de una serie de elementos, como son la

comunicación, los costes, el alcance y los recursos humanos. La gestión del tiempo, por lo tanto, depende del correcto sincronismo de las actividades realizadas por los diferentes profesionales implicados en el proyecto que necesitarán de una coordinación que pueda asegurar el cumplimiento de toda la planificación establecida. Aisladamente, la gestión del tiempo empieza definiendo las actividades del proyecto. Luego se organiza su secuencia para, a continuación, estimar sus duraciones. El resultado final de estas estimaciones es el cronograma, que orientará el equipo del proyecto en lo que dice respeto a las fechas de inicio/fin y la duración de las actividades correspondientes. Algunos proyectos pueden perder totalmente su objetivo si los plazos no son cumplidos. La infraestructura necesaria para realizar una carrera de Fórmula 1 en una ciudad, será de muy poca utilidad si los trabajos se concluyen después que la carrera ha terminado. Sin embargo, y naturalmente, gestionar el tiempo de un proyecto no se limita tan solamente a estimar las secuencias y las duraciones del proyecto, ni mucho menos desarrollar un cronograma. Existen algunos conceptos que el Project Manager necesita conocer, para entender mejor las implicaciones que conlleva realizar una gestión de tiempo correcta: Actividad crítica (Critical activity): Es una actividad que, si no finaliza en el tiempo estimado podrá impactar negativamente en la duración de todo el proyecto. Se determina una actividad como critica cuando no se puede cambiar sus fechas de comienzo y finalización sin modificar la duración total del proyecto. Su holgura total es cero. Camino crítico (Critical path): Es la secuencia de actividades del proyecto que tiene la mayor duración y que determina el menor tiempo posible para completar un proyecto sin holguras. La duración del camino critico determina la duración total del proyecto, con lo cual, cualquier retraso en el desarrollo de los elementos del camino critico repercutirá negativamente sobre la fecha de finalización del proyecto. Es decir, si se retrasa en dos

días una de las actividades del camino crítico, el proyecto entero se retrasará en dos días (a no ser que haya otra tarea del camino crítico que se adelante en dos días). Duración (Duration): Periodo de tiempo estimado (sin incluir días festivos u otros periodos de no trabajo) necesario para completar una determinada actividad. Normalmente es expresado en horas, días, semanas… Esfuerzo (Effort): Número de unidades requeridas para completar una determinada actividad del proyecto. Normalmente se expresa en horas hombre, días hombre o semanas hombre. No se debe confundir con la duración. Flotación (Float): Tiempo que una actividad se puede retrasar desde su fecha de inicio temprana sin retrasar la fecha de finalización del proyecto. Este tiempo de flotación puede cambiar a medida que avance el proyecto y se efectúan cambios en el proyecto. Recorrido hacia Adelante (Forward Pass): Este término determina la fecha de inicio y finalización más temprana para las partes incompletas de todas las actividades de la red. El resultado obtenido permite conocer cuál es la fecha más temprana para la asignación de un determinado recurso y cuál es la fecha mínima que el proyecto necesita contar con este recurso. Recorrido hacia Atrás (Backward Pass): Cálculo de fechas de finalización e inicio tardías para las partes incompletas de todas las actividades de las redes. Se determina yendo hacia atrás en la logia de las redes a partir de las fechas de conclusión del proyecto, la que puede calcularse en un recorrido hacia adelante o ser establecida por el cliente o patrocinador. Hito (Milestone): Un punto del cronograma, normalmente señalizando un evento importante del proyecto, normalmente la conclusión de una determinada actividad, decisión o fase. Los

hitos no son actividades, es decir que no consumen tiempo ni recursos, son tan solamente, un punto de referencia del proyecto. Diagrama de Red (Network Diagram): Representación gráfica de las relaciones lógicas de las actividades de un proyecto. Siempre se traza de la izquierda a la derecha para reflejar la cronología del proyecto. Holgura (Slack): Es la cantidad de tiempo que una tarea puede ser aplazada sin afectar la fecha de finalización del proyecto. Estos términos son fundamentales para entender correctamente la gestión del tiempo del proyecto. Su correcto entendimiento además, contribuirá para el desarrollo de un cronograma realista. Un cronograma “perfecto” que debería ser confeccionado obedeciendo algunos procedimientos: Identificar las actividades que formarán parte del proyecto: Utilizando la Estructura detallada del proyecto – EDT (descrita en la sección 5.3) será posible realizar las estimaciones iniciales del proyecto. La EDT es una herramienta de descomposición del trabajo realizado, orientada a los entregables del mismo, que organiza y define el alcance completo. Desarrollar el diagrama de red: La confección de este diagrama deberá contemplar todas las actividades del proyecto. Estas actividades deberán secuenciarse de forma precisa para sustentar el posterior desarrollo de un cronograma realista. Si posible, es importante poder contar con la colaboración de expertos. (Para más detalles, véase también sección 6.2.1 - Técnicas y herramientas para la secuenciación de actividades). Estimar la duración de las actividades: Normalmente, se estiman las fechas más optimistas, como si todos los recursos estuviesen disponibles en tiempo integral. Una vez hecha está estimación orientativa, se parte para una estimación más realista, basado en la disponibilidad real de los recursos en la empresa.

Estimar fechas: Con la secuencia y la duración de las actividades en manos, es hora de planificar las fechas concretas de comienzo y cierre del proyecto. Muchas veces, estas fechas son una restricción del proyecto ya que pueden, y muchas veces lo son, determinadas pelo cliente. Para poder lograr el cumplimiento del calendario establecido, es importante considerar festivos, horarios especiales y, sobre todo, la disponibilidad de los recursos asignados; esta última muchas veces es la razón por la cual muchos proyectos no finalizan en el plazo estimado. Hacer un seguimiento: Finalizado en cronograma de las actividades es fundamental crear una línea base. Esta línea base será importante para comprobar si el proyecto avanza según el cronograma planificado y posteriormente se tornará una fuente de consulta para futuros proyectos similares. En algunos proyectos, especialmente en los pequeños, la secuencia de las actividades, su estimación y duración, así como el desarrollo del cronograma están tan estrechamente vinculados que son vistos como un único proceso ya que pueden ser ejecutados durante un periodo relativamente corto. Bajo el enfoque de la cuarta edición del PMBOK®, la gestión del tiempo de un proyecto incluye los procesos y actividades necesarios para administrar la finalización del proyecto a tiempo. Son estos: Definir las actividades. Secuenciar las actividades. Estimar los recursos de las actividades. Estimar la duración de las actividades. Desarrollar el cronograma. Controlar el cronograma. 6.1 Definición de las actividades (Proceso que corresponde a la fase de planificación del proyecto) Este proceso consiste básicamente en identificar correctamente las acciones específicas que deberán ser puestas en marcha para el desarrollo de los

entregables del proyecto. Las actividades de un proyecto son la base fundamental para la estimación, la planificación, la ejecución, el seguimiento y el control del trabajo del proyecto. La definición y la planificación de las actividades del cronograma están implícitas en este proceso, de modo que se cumplan los objetivos del proyecto. 6.1.1 Técnicas y herramientas 6.1.1.1 Estructura detallada del trabajo – EDT (Work breakdown structure – WBS) Descrita en la sección 5.3 6.1.1.2 Descomposición (Decomposition) La descomposición es la subdivisión de los entregables del proyecto en componentes más pequeños y manejables, hasta que el trabajo y los entregables queden definidos al nivel de paquetes de trabajo. El nivel de paquetes de trabajo es el más bajo en la EDT, y es aquel en el que el coste y la duración de las actividades del trabajo pueden estimarse y gestionarse de manera más confiable. El nivel de detalle para los paquetes de trabajo varía en función del tamaño y la complejidad del proyecto. La forma más conocida y más utilizada para hacer la descomposición del alcance de un proyecto es la técnica de la estructura detallada del proyecto – EDT (work breakdown structure – WBS), descrita en la sección 5.3. 6.1.1.3 Planificación gradual (Rolling wave project planning - RWPP) Descrito en la sección 5.2.1.3 6.1.1.4 Plantillas (Templates) Una plantilla es un documento estándar utilizado para diferentes fines y sirve, sobre todo, para facilitar el trabajo de reproducción de documentos idénticos

o similares. Las plantillas no son otra cosa que un punto de partida, una idea aproximada de lo que se quiere hacer. A partir de una plantilla se puede diseñar nuevas plantillas, más refinadas y con más informaciones. Con el paso de los años, muchas empresas mantienen un “banco de plantillas” que pueden ser aprovechadas para determinado momento del proyecto. NOTA DEL AUTOR Las plantillas son realmente muy útiles. Yo mantengo un banco de plantillas personal desde hace años y las utilizo a menudo. Cualquier documento puede servir de plantilla: contratos, cronogramas, líneas base, cartas, propuestas... Se trata de un recurso que te hace ahorrar el tiempo y te aporta un contenido listo para usar. Otra ventaja es que estas plantillas van mejorando con el paso del tiempo. Siempre que utilizo una plantilla, aprovecho para mejorar su contenido y formato. No obstante, a la hora de coger un documento para convertirlo en plantilla, es fundamental eliminar cualquier información que pueda identificar a personas, fechas, valores o cualquier otro dato identificativos utilizado en un documento anterior. De una plantilla se aprovecha su estructura y contenido, pero se debe conservar la confidencialidad, eliminando datos considerados “sensibles”. 6.1.1.5 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1 6.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) DOC nº 010 – Lista de actividades (Activity list) DOC nº 011 – Atributos de la actividad (Activity attributes)

Lista de hitos (véase session 6.5.1.9) (Milestone list) 6.2 Secuenciación de actividades (Proceso que corresponde a la fase de planificación del proyecto) Este proceso consiste en identificar y documentar las relaciones entre las actividades del proyecto, que se establecen mediante relaciones lógicas; es decir, las actividades se conectan con sus predecesores y sucesores correspondientes, que pueden incluir adelantos o retrasos entre las actividades que proporcionen al cronograma un escenario realista, viable y, sobre todo, sostenible. 6.2.1 Técnicas y herramientas 6.2.1.1 Diagramas de red (Network diagram) Un diagrama de red es el término genérico de un diagrama, que representa algún tipo de red que pueda conectar varias actividades en una secuencia cronológica. Presentan una serie de variaciones, y cada una de ellas podrá ser estructurada para los más diferentes fines.

Figura 47: Diagrama básico de red Un diagrama de red básico debería contener, por lo menos, los siguientes elementos:

Un evento: Que señale el inicio y el fin de la tarea o acción; no consume tiempo ni recursos. Se representa a través de un nodo o un círculo. Actividades: Son el un conjunto de tareas, que deben ejecutarse, para la realización de una obra; consume tiempo, tiene inicio y fin, requiere mano de obra, materia prima y otros recursos. Una actividad ficticia: Es aquella que no consume tiempo ni trabajo. Se representa por líneas entrecortadas y sirve para guardar la lógica de la red. Un camino crítico: Es el camino más largo a través de la red y representa el menor tiempo posible para la ejecución del proyecto. 6.2.1.2 Método de diagramación con flechas (Arrow diagramming method - ADM) También conocido por “AOA - Activity on arrow”, es una de las primeras herramientas utilizadas para secuenciar actividades. Utilizada en proyectos muy sencillos, su concepto es limitado y no puede soportar una red de actividades muy compleja. Por esta razón, es poco utilizada actualmente. La relación precedente entre actividades es representada por círculos conectados a una o más flechas. La longitud de la flecha puede representar la duración de la actividad. En algunos casos, se añade una actividad ficticia (conocida en el ámbito del Project Management como dummy task), que sirve básicamente para representar la dependencia entre actividades y no consume tiempo ni trabajo. Existen dos formas de diseñar una diagramación con flechas. En la figura 48, la actividad es representada por la fecha, en que los círculos ilustran el comienzo y el fin de la actividad. También se puede confeccionar este diagrama representando las actividades en círculos, según ilustra la figura 49. Las flechas representan la secuencia determinada para las actividades del proyecto.

6.2.1.3 Método de diagramación por precedencia (Precedence diagramming method - PDM) El PDM es una técnica de representación visual que describe las actividades de un proyecto. Es una herramienta que aporta muchos beneficios, como por ejemplo: Comunicación clara: Su representación visual permite entender claramente el flujo de desarrollo del proyecto y sus implicaciones. Identificación de actividades “olvidadas”: Cuando una actividad no es identificada, consecuentemente no será incluida en la red y, por supuesto, no será desarrollada. La PDM permite, a través del análisis de su estructura, la ausencia de alguna actividad en el proyecto.

Identificación de las dependencias: En la PDM, cada actividad es dependiente de alguna actividad predecesora. Cuando una dependencia no es identificada, el proyecto seguramente terminará retrasado. Por ejemplo, si un componente crítico está siendo producido por un proveedor externo, el producto final dependerá del proveedor, es decir, aunque todas las actividades internas hayan sido correctamente completadas, el proyecto no estará finalizado hasta que el proveedor suministra el componente crítico. Este un ejemplo de dependencia que debe ser identificada y por supuesto, contemplada en la PDM. Identificación de las actividades críticas: Algunas actividades tienen un mayor impacto en la programación del proyecto que otras. Mediante el uso de la PDM, es posible determinar las actividades críticas a la programación del proyecto. Esto se conoce como método del camino crítico (descrito con profundidad en la sección 6.5.1.2). Creación del cronograma del proyecto: El objetivo final de todo PDM es crear un cronograma de trabajo fiable. Relaciones de precedencia: Finalizar para comenzar (Finish-to-start): Muchas de las actividades de un proyecto contienen esta relación lógica. Es, sin duda, la relación más común de todas. En esta relación, la actividad predecesora (A) debe ser concluida para que la actividad sucesora (B) pueda empezar. Esto no quiere decir que la actividad sucesora (B) finalice inmediatamente tras el término de la actividad predecesora (A), pero no podrá terminar antes. Por ejemplo, después de aplicar la masilla, se puede empezar la pintura en cualquier momento, pero es lógico que no se podrá pintar la pared antes que se aplique la masilla.

Figura 51: Relación finish-to-start Comenzar para finalizar (Start-to-finish): Esta relación es la menos utilizada en un proyecto. La actividad predecesora (A) debe empezar antes de que finalice la actividad sucesora (B). No es necesario que la actividad sucesora (B) finalice inmediatamente después del comienzo de la actividad predecesora (A), pero no podrá terminar antes. Por ejemplo, el aprendiz puede empezar a pintar (A) antes de la llegada del jefe de pintura (B), pero no podrá rematar la pintura (A) antes su llegada (B).

Figura 52: Relation start-to-finish Finalizar para finalizar (Finish-to-finish): La actividad predecesora (A) debe finalizar antes de que finalice la actividad sucesora (B). No es necesario que la actividad sucesora (B) concluya inmediatamente después del término de la actividad predecesora (A), pero no podrá terminar antes. Por ejemplo, el jefe de la pintura no podrá terminar la revisión de la pintura (B) antes que el aprendiz termine de pintar (A).

Figura 53: Relation finish-to-finish Comenzar para comenzar (Start-to-start): La actividad predecesora (A) debe empezar antes de que empiece la actividad

sucesora (B). No es necesario que la actividad sucesora (B) empiece inmediatamente después de la puesta en marcha de la actividad predecesora (A), pero no podrá empezar antes. Para ilustrar un ejemplo, cogeremos una vez más el caso de la pintura de una habitación. Las dos actividades son: (A) la llegada del jefe de pintura y (B) pintar la pared. El aprendiz de pintura no puede empezar a pintar (actividad B), antes que llegue el jefe de pintura (actividad A);

Figura 54: Relación start-to-start Leads y Lags: Para acabar el tema de las relaciones entre actividades es importante mencionar los leads y lags. Se trata de retrasos o adelantos que, a veces, son impuestos entre actividades de un proyecto, sin modificar su relación. Una lag es un retraso o un “tiempo de espera” entre actividades. En el ejemplo de la pintura, cuando se aplica la masilla, es necesario esperar un tiempo para que esta pueda secar, y a continuación empezar la pintura. Si establecemos un tiempo de secado de ocho horas, este será el lag entre una actividad y la posterior. La actividad B (pintar la pared) no podrá empezar hasta ocho horas después de completada la actividad A (aplicación de la masilla). NOTA DEL AUTOR Por otro lado, una lead es aceleración entre actividades. Una forma de “provocar” una lead es realizando dos tareas en paralelo, cuando lo normal es que deberían ser realizadas en secuencia. Por ejemplo, tras la aplicación de la masilla en la pared, se podría instalar la cornisa mientras se espera por el secado de la masilla y antes que empiece la pintura de la pared. Es decir, la actividad C (instalación de la cornisa) empezaría ocho horas antes de la actividad B (pintar la pared). De esta forma, el tiempo necesario para la

ejecución y finalización de la actividad C sería absorbido por el tiempo de espera entre la actividad A y B. Teniendo en cuenta los conceptos de relación de dependencias, ya es posible confeccionar un diagrama de red. Para ello, es importante saber: a) Qué actividades deben empezar antes de una actividad concreta. b) Qué actividades no pueden empezar antes que se finalice una actividad concreta. c) Qué actividades pueden ser desarrolladas simultáneamente. A partir de la información recogida de la estructura detallada trabajo – EDT (descrita en la sección 5.3), se confecciona una tabla donde se clasifican las actividades del proyecto y se identifican sus predecesores. Todavía no se han realizado las estimaciones de duración o adjudicación de recursos. De momento, la única preocupación es establecer la relación entre las actividades. El ejemplo que se desarrolla a continuación ilustra las actividades para la puesta en marcha de un viaje de fin de semana.

Figura 55: Tabla de actividades de la EDT Note que en la propia tabla de actividades de la EDT se pueden establecer sus duraciones. La duración de una actividad será estimada por el esfuerzo previsto, es decir el tiempo que uno o más recursos necesitarán para ejecutarla. Este esfuerzo normalmente es estimado por número de horas (o minutos, como ilustra la figura 55, por tratarse de un proyecto de tres días). La columna de las predecesoras es fundamental para poder enlazar la secuencia de las actividades y construir el diagrama correspondiente, según ilustra la figura abajo:

Figura 56: Secuencia de actividades Según explicado anteriormente, hay casos muy frecuentes en que el Project Manager y su equipo suelen realizar estimaciones muy optimistas. Para definir correctamente la duración de una actividad, se debería contar con la experiencia de expertos, que podrán aportar estimaciones más realistas. Convirtiendo el diagrama en un cronograma: El producto resultante de la confección del diagrama de red y de la estimación de las duraciones de cada actividad resultará en el cronograma, que tendrá un aspecto semejante al que ilustra la figura a continuación. Para conocer más detalles acerca del desarrollo de un cronograma, véase también sección 6.5.

Figura 57: Cronograma del proyecto 6.2.1.4 Método del camino crítico (Critical path method – CPM) El método CPM o camino crítico (critical path method - CPM) fue desarrollado en 1957 por la empresa americana DuPont, y su objetivo principal es establecer la duración de un proyecto, entendiendo este como una secuencia de actividades que se relacionan entre sí, donde cada una de ellas tiene una duración determinada. Un camino o ruta es el recorrido (o recorridos) realizada por el proyecto a través de la secuencia lógica de sus actividades desde el inicio hasta el final. En este sentido, cada camino tendrá sus longitudes, siendo una de ellas considerada un camino crítico, y será siempre la más grande del proyecto. El camino crítico tiene una característica principal: no hay tiempo de holgura entre las actividades, y por ello, ninguna de ellas puede retrasarse. El camino crítico solo permite holgura si una de sus actividades es completada antes del

plazo previsto. El desarrollo del CPM es realizado a través de los siguientes pasos: 1.

Se identifican las actividades del proyecto: A través de la EDT (véase también sección 5.3) se recogen todas las actividades necesarias para el desarrollo del proyecto.

2.

Se establecen las relaciones entre las actividades. Decidir cuál debe comenzar antes y cuál debe seguir después.

3.

Se confecciona el diagrama de red. Conectando las diferentes actividades en base a sus relaciones de precedencia.

4.

Se define el tiempo estimado para cada actividad.

5.

Se identifica la trayectoria más larga del proyecto. Siendo esta la que determinará la duración del proyecto (el camino critico).

Una CPM puede proporcionar una gran cantidad de informaciones, y para poder conocerlas, es importante establecer los siguientes parámetros para cada actividad: Para organizar correctamente el camino crítico es importante cumplir un requisito importante: Organizar todas las actividades secuencialmente, identificando sus sucesoras y predecesoras y estableciendo sus fechas de inicio y fin, que se desglosan en cuatro tipos:

Figura 58: Diagrama de red según el CPM Inicio más temprano - IT (early start - ES): Representa la fecha de inicio más temprana en que se pude iniciar una actividad, basada en el diagrama de red del cronograma del proyecto. Para las primeras actividades del proyecto esta fecha es la fecha de comienzo del proyecto. Inicio más lejano - IL (late start - LS): Es la fecha más de inicio tarde en que se puede iniciar una actividad, basada en el diagrama de red del cronograma del proyecto. Finalización más temprana - FT (early finish – EF): Representa la fecha más temprana posible de finalización de una determinada actividad, basada en el diagrama de red del cronograma del proyecto. Finalización más lejana - FL (late finish - LF): Representa la fecha más tardía de finalización de una determinada actividad, sin provocar retrasos en el proyecto. Las fechas de finalización tardías son determinadas durante el cálculo del camino crítico a partir del final del proyecto hacia el principio. Ejemplo práctico: Para desarrollar correctamente el método del camino crítico, es necesario

previamente realizar las siguientes acciones: Una vez identificadas las actividades del proyecto, se determinan sus sucesores y predecesores, estableciendo de esta forma las rutas lógicas que el proyecto tendrá que recorrer desde el inicio hasta su fin. Es imprescindible conocer cuál es la duración estimada de cada actividad, antes de desarrollar el diagrama, puesto que la duración será siempre el punto de partida para conocer los otros valores de la red. Tal y como ilustra la figura 59, la duración de las actividades se disponen en el recuadro central superior de la actividad correspondiente. Como regla general el inicio y el fin son considerados hitos, y por ello su duración será siempre igual a cero.

Figura 59: Diagrama de red con sus rutas lógicas y duraciones correspondientes

Tal y como podemos apreciar en la figura 59, las actividades del proyecto ya están enlazadas por varias rutas lógicas y sus actividades predecesoras debidamente identificadas. Es fundamental añadir un “INICIO” y un “FIN” al diagrama, para no dejar ninguna actividad “suelta”. De esta forma, tenemos el diagrama debidamente atado. Es importante mencionar otra vez, que el inicio y fin son hitos, y, por lo tanto, tendrán duración igual a cero. Conociendo la duración de todas las actividades, ya podemos establecer cuáles serán las fechas de inicio más temprano y finalización más temprana. En el la figura 60, las actividades “A”, “B” y “C”, empiezan simultáneamente, a partir del inicio (que tiene duración igual a cero), por lo tanto, sus fechas de inicio más temprano será igual a “cero” y las fechas de finalización más temprana serán: cero + la duración correspondiente.

Figura 60: Las fechas de inicio más temprano se sitúan el recuadro superior izquierdo y las de finalización más temprana en el recuadro superior derecho Para obtener entonces las fechas de inicio y finalización de las siguientes actividades, se realizan los siguientes cálculos: Actividad D: IT (2) + duración (3) = FT (5) Actividad E: IT (4) + duración (5) = FT (9) Actividad F: IT (2) + duración (4) = FT (6)

Figura 61: Diagrama de red con sus fechas y duraciones En el caso de la actividad “G” tenemos una situación especial. Tal y como se puede observar en la figura 62, esta actividad tiene 3 predecesoras (B, D y E). Cuando esto ocurre, siempre se elegirá el valor de la actividad predecesora que posee el mayor valor. En este caso, sería la actividad “E” que tiene un FT = 9. De esta forma: IT de la actividad “G” es igual al FT de la actividad “E” + duración de la actividad “G” = 9 + 2 = 11.

Figura 62: Diagrama de red con sus fechas y duraciones Con el fin del proyecto pasa lo mismo. Como se encuentra enlazado por dos actividades predecesoras (F y G), se elegirá la que tenga la FT mayor. En este caso, sería la actividad “G” que tiene un FT = 11. De esta forma, el fin del proyecto será: = FT de la actividad “G” + duración del “FIN” = 11 + 0 = 11.

Figura 63: Diagrama de red con sus fechas y duraciones El camino de vuelta

Ahora, tenemos que hacer el camino de vuelta, para conocer las fechas de inicio y fin lejano (IL y FL). Para empezar correctamente con el camino de vuelta, tenemos que tener en cuenta lo siguiente: La FL del “FIN” será siempre igual a su “FT”, en este caso será 11. La FL de las actividades predecesoras del “FIN” será siempre igual al FL del “FIN”, con lo cual, las actividades “F” y “G” tendrán un FL = 11.

Figura 64: El camino de vuelta A continuación, se aplican las FL de cada actividad predecesora y restando con la duración correspondiente, encontraremos sus IL correspondientes, lo que nos proporcionará los siguientes resultados: IL de “G”: 11 – 2 = 9 IL de “F”: 11 – 4 = 7 IL de “E”: 9 – 5 = 4 IL de “D”: 9 – 3 = 6 IL de “C”: 4 – 4 = 0 IL de “B”: 9 – 6 = 3 IL de “A”: 6 – 2 = 4

Figura 65: El camino de vuelta La actividad “A” tiene dos sucesores “D” y “F”. En el camino de vuelta, cuando una actividad se enlaza con dos sucesoras, se elige la de menor valor, es decir: IL de “A” = IL de “D” (6) – 2 = 4. Tras calcular las formulas correspondientes en el camino de ida y vuelta, ya conocemos todas las fechas posibles del proyecto. (IT, FT, IL y FL) y tenemos todo el grafico completo. Nos queda por fin, conocer el camino crítico del proyecto, y para ello necesitamos encontrar las holguras de cada actividad, representadas en el recuadro centrar inferior, que es el único recuadro que se ha quedado de momento sin ningún valor. Las holguras se obtienen restando el FL del FT de cada actividad (FL – FT), es decir: Actividad A: 6 - 2 = 4 Actividad B: 9 - 6 = 3 Actividad C: 4 - 4 = 0 Actividad D: 9 - 5 = 4

Actividad E: 9 - 9 = 0 Actividad F: 11 - 6 = 5 Actividad G: 11 – 11 = 0 Y de esta forma, hemos obtenido la holgura de todas las actividades. Nos queda por fin, lograr el objetivo principal de esta herramienta, que es identificar el camino crítico del proyecto. Identificando el camino crítico Esta operación es muy sencilla. Simplemente se marcan las actividades cuya holgura es igual a cero; en este caso, serían las actividades “C”, “E” y “G”, además del inicio y del fin

Figura 66: El camino crítico La duración de todas estas actividades será lo que indique el FL del fin, en este caso, once días, o sea, el camino crítico de este proyecto tiene once días, y por no disponer de holguras, ninguna actividad podrá retrasarse. Por todo ello, el Project Manager tendrá que asegurar que: La actividad “C” empiece el día 0 y termine el día 4.

La actividad “E” empiece el día 4 y termine el día 9 La actividad “G” empiece el día 9 y termine el día 11. Si estas fechas no se cumplen, todo Si esto ocurre, todo el proyecto se retrasará. Las otras actividades podrán retrasarse acorde con la holgura que cada una dispone, por ejemplo: La actividad A dispone de una holgura de cuatro días, por lo tanto, si hiciera falta, esta actividad podría empezar el día uno o dos y terminaría el día tres o cuatro.

Figura 67: Las holguras de una actividad NOTA DEL AUTOR Las actividades del camino crítico no son necesariamente las técnicamente más importantes del proyecto. Para utilizar el método CPM correctamente, es imprescindible conocer todos los tiempos de duración de cada actividad del proyecto, es decir, no puede haber incertidumbre. En un diagrama como el presentado, los cálculos de ida y vuelta son sencillos. No obstante, nos podemos encontrar con diagramas bastante complejos, y por ello se recomienda el uso de programas informáticos. El CPM es una de las herramientas clave del Project Management, y cualquier error podría provocar graves daños al proyecto. Las actividades que forman parte del camino crítico deben ser las actividades que el Project Manager deberá dedicar más atención. Todo y cualquier retraso en el camino crítico provocará un retraso

en todo el proyecto. Tampoco es recomendable abusar de las holguras de determinadas actividades. Cualquier incidencia podrá incrementar un riesgo importante en las fechas de las actividades subsecuentes. En 1997, el físico israelí Eliyahu Goldratt 23 publicó su best seller Critical Chain (Cadena Crítica) que aportaba una técnica innovadora que permitiría completar los proyectos en un tiempo significativamente más corto que utilizando las técnicas tradicionales de administración de proyectos. El método de la cadena crítica es considerado por muchos autores como la evolución del método del camino crítico, y podremos conocerlo en profundidad, en la sección 6.5.1.2 de este capítulo. 6.2.1.5 Determinación de dependencias (Dependency determination) Para determinar la secuencia entre actividades, se pueden emplear tres tipos de dependencias: Dependencias obligatorias: Son las dependencias consideradas contractualmente obligatorias o inherentes a la naturaleza del proyecto. El equipo del proyecto determinará qué dependencias son las obligatorias, durante el proceso de establecimiento de secuencia de las actividades. Un ejemplo de dependencia obligatoria es la construcción de un edificio, donde es imposible erigir su estructura hasta que no se realicen las labores de excavación. Dependencias discrecionales: En este caso, el equipo del proyecto podrá establecer las dependencias de las actividades libremente, aunque es prudente hacerlo de acuerdo con la experiencia obtenida de proyectos similares de éxito u obedeciendo el estándar de las mejores prácticas del sector. Este tipo de dependencias deben estar bien documentadas, pues sus resultados podrán definir estándares internos para proyectos futuros similares de la organización, además de ser una importante

fuente de consulta de “lecciones aprendidas”. Dependencias externas: Son dependencias que implican una relación entre las actividades del proyecto y aquellas que no pertenecen al proyecto, y por ello se encuentran parcial o totalmente fuera de control de la organización. Podrán depender de la ejecución de un profesional o empresa externo a la organización, o en algunos casos, dependerá también de la decisión y/o aprobación de la administración pública. Por ejemplo, la ampliación de un aeropuerto dependerá de la aprobación del presupuesto del Ayuntamiento o Junta correspondiente, o la puesta en marcha de una determinada maquina podrá depender de la entrega de algún componente fabricado fuera del país. 6.2.1.6 Aplicación de adelantos y retrasos (Applying leads and lags) Una lag es un retraso o un “tiempo de espera” entre actividades. En el ejemplo de la pintura, cuando se aplica la masilla, es necesario esperar un tiempo para que esta pueda secar, y a continuación empezar la pintura. Si establecemos un tiempo de secado de ocho horas, este será el lag entre una actividad y la posterior. La actividad “B” (pintar la pared), no podrá empezar hasta ocho horas después de completada la actividad “A” (aplicación de la masilla). Por otro lado, una lead es aceleración entre actividades. Una forma de “provocar” una lead es realizando dos tareas en paralelo, cuando normalmente deberían ser realizadas en secuencia. Por ejemplo, tras la aplicación de la masilla en la pared, se podría instalar la cornisa mientras se espera por el secado de la masilla y antes que empiece la pintura de la pared. Es decir, la actividad “C” (instalación de la cornisa) empezaría ocho horas antes de la actividad “B” (pintar la pared). De esta forma, el tiempo necesario para la ejecución y finalización de la actividad C seria absorbido por el tiempo de espera entre la actividad “A” y “B”. 6.2.1.7 Plantillas de red de cronograma (Schedule network templates)

Descrito en la sección 6.1.1.4 6.2.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) Diagramas de red del cronograma (Véase sección 6.2.1.1) (Project schedule network diagrams) DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates) 6.3 Estimación de los recursos de las actividades (Proceso que corresponde a la fase de planificación del proyecto) Este proceso consiste en estimar el tipo y las cantidades de recursos necesarias para ejecutar correctamente cada actividad de un proyecto. Como “recurso” podemos entender por ejemplo, materiales, personas, maquinaria, equipos informáticos y suministros en general. 6.3.1 Técnicas y herramientas 6.3.1.1 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1 6.3.1.2 Datos de estimación publicados (Published estimating data) Muchas empresas publican periódicamente los costes unitarios de sus recursos para una amplia variedad de materiales y equipos en diferentes países. Es una fuente de información que aporta datos fiables para la estimación de recursos. 6.3.1.3 Estimación ascendente (Bottom-up estimating)

Cuando una actividad tiene unas características que dificultan una estimación fiable, se utiliza la técnica de estimación ascendente que funciona de la siguiente forma: se descomponen los trabajos de esta actividad a un nivel mayor de detalle, y se estiman los recursos necesarios para ejecutar cada actividad individualmente. A continuación, se van totalizando los costes encontrados, cuya suma total corresponderá al coste total de la actividad. Para esta estimación es muy interesante utilizar la estructura detallada del trabajo - EDT (para más detalles, véase también la sección 5.3). La ventaja de esta técnica es que ella produce resultados bastante fiables. La desventaja es que estos resultados necesitan de un periodo de análisis considerablemente largo.

Figura 68: Aplicación de la estimación ascendente en la EDT 6.3.1.4 Software de gestión de proyectos (Project Management Software) Para poder desarrollar una gestión de proyectos eficiente, el Project Manager

debe hacer uso de sistemas y procedimientos que colaboren en la administración del proyecto junto con su equipo. Los últimos avances tecnológicos han contribuido bastante, ofreciendo en el mercado un amplio abanico de opciones de herramientas verticales, como los de gestión financiera, de plazos e incluso de recursos. El mercado dispone también de potentes aplicaciones de gestión de documentos que evitan la duplicación innecesaria de datos y la pérdida de información y que generan formatos profesionales para su publicación. Sin embargo, gestionar un proyecto no se limita solamente a utilizar aplicativos informáticos. No hay dudas de que el uso de una buena herramienta informática es fundamental para desarrollar un proyecto. No obstante, nada puede sustituir el sentido común, la experiencia y el juicio de expertos. Es importante tener claro que un software no puede: Asegurar que la información es apropiada, actualizada y correcta: Durante el desarrollo del proyecto, los integrantes del equipo, registrarán datos técnicos y de gestión del proyecto en el sistema de información disponible por la organización. El Project Manager podrá revisar y formatear toda la información registrada, pero el programa no puede asegurar la fiabilidad de los datos imputados. Tomar decisiones: Un programa informático puede perfectamente auxiliar el Project Manager a la hora de tomar decisiones, generando informes y una serie de resultados, pero no puede de forma alguna, decidir por él. Crear y sostener relaciones interpersonales de forma dinámica: A pesar de que las personas son fascinadas por chat, emails, redes sociales y otros tipos de aplicaciones volcadas a las relaciones interpersonales, un programa no puede asegurar la fiabilidad de cualquier relación entre personas. Además, ningún programa tiene la habilidad de comunicar un mensaje de forma tan personal y dinámica, como las expresiones faciales y el lenguaje del cuerpo.

Por lo tanto, tenga en cuenta las limitaciones de una aplicación informática e intente sacar lo mejor que la tecnología puede ofrecer. Si has decidido utilizar un software de gestión integral es importante seguir las recomendaciones a continuación: Programas utilizados pela organización: Verifique los programas que son utilizados por otros equipos de proyecto de la organización. Pregunte cuáles son los aspectos que ellos más valoran y qué prestaciones les gustaría tener. Versión de demostración: Si ya sabes cual es el programa que pretendes adquirir, intente conseguir una versión de demostración, para poder explotarlo durante un periodo. Prácticas: Una vez que tenga la versión de demostración instalada, intente crear proyectos sencillos. De esta forma será más fácil hacer un recorrido general por todas las funciones del programa. Compatibilidad: Asegúrese que el producto es compatible con los sistemas existentes en la empresa. Verifique si el programa es capaz de generar los gráficos, informes o cualquier otro tipo de información que el proyecto necesite. Formación: Matricúlese en algún curso de formación. Es importante establecer contacto con otras personas que conozcan el programa. Incluso, si posible, forme parte de algún foro de Internet. En los foros será posible conocer las ventajas y desventajas del programa, a través de la opinión de usuarios más experimentados. NOTA DEL AUTOR Los softwares del Project Management más utilizados en el mercado son: Open-Source desktop applications • KPlato (www.koffice.org) • OpenWorkbench (www.openworkbench.org)

• •

TaskJuggler (www.taskjuggler.org) GANTT Project (http://ganttproject.biz)

Open-Source web-based applications • Bugzilla (www.bugzilla.org) dotProject (http://sourceforge.net/projects/dotproject) • Eventum (https://launchpad.net/eventum) • Mantis Bug Tracker (www.mantisbt.org) • Project.net (www.project.net) • ProjectPier (www.projectpier.org) • Trac (http://trac.edgewall.org) Proprietary desktop applications • Artemis (http://www.svibs.com) • Cerebral Project(TM) (www.cerebralproject.com) • Collanos Workplace (www.collanos.com) • Microsoft Project (www.microsoft.com) • Merlin (www.projectwizards.net/en/merlin) • OmniPlan (www.omnigroup.com) • Planisware OPX2 Pro (www.planisware.com) • Sophocles PM (www.mediafire.com/sophocles) Proprietary web-based applications • 24SevenOffice (http://24sevenoffice.com) • @task (www.attask.com) • Basecamp (http://basecamphq.com) • Central Desktop (www.centraldesktop.com) • JIRA (www.atlassian.com/software/jira) • Project Insight (www.projectinsight.net) • ProjectHand (www.natara.com/projectathand2) • Teamwork (www.twproject.com) • Wrike (www.wrike.com) • TOPdesk (www.topdesk.com) 6.3.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto)

DOC nº 012 – Requisitos de recursos de la actividad (Activity Resource Requirements) DOC nº 013 – Estructura de desglose de recursos (Resource breakdown structure) DOC nº 056 – Actualizaciones a los documentos del royecto (Project document updates) 6.4 Estimación de duración de actividades (Proceso que corresponde a la fase de planificación del proyecto) La estimación de duración de actividades es el acto de cuantificar la cantidad de tiempo necesaria para finalizar una determinada actividad. Normalmente esta estimación se realiza sobre el esfuerzo dedicado a esta actividad en término de horas. De esta forma, si un trabajador está disponible las ocho horas diarias de su jornada laboral, sería muy sencillo realizar la estimación de sus actividades en un proyecto. Sin embargo, este tipo de circunstancia no suele ocurrir en el mundo real. Existen muchas variables que dificultan la realización de estimaciones fiables. Algunas de estas variables son: Variables de conocimiento: Difícilmente un grupo de trabajadores tiene la misma capacidad de trabajo. Unos pueden tener más conocimientos o habilidades que otros. Eventos inesperados: Eventos de la naturaleza como tormentas de nieve, lluvia, incluso huracanes pueden perjudicar el plazo de conclusión de una tarea. Otras incidencias pueden ocurrir, como por ejemplo, retrasos por parte de proveedores, problemas burocráticos, cortes de energía, entre otros. Interrupciones: Las tareas que un trabajador desarrolla en un proyecto son frecuentemente interrumpidas por el teléfono, e-mail, reuniones, desayunos y charlas con los compañeros. Equivocaciones: Es común que ocurran fallos que culminan en una tarea desarrollada de forma equivocada.

NOTA DEL AUTOR Dos trabajadores no realizan una actividad en la mitad de tiempo Otro detalle muy importante y que suele ocurrir con una cierta frecuencia es pensar que dos personas realizan una actividad en la mitad de tiempo. Consecuentemente, se podrá pensar que tres personas llevarán un tercio del tiempo, y así sucesivamente. En estas horas hay que tener en cuenta que dos madres no pueden generar un niño en cuatro meses y medio. Es una equivocación muy común pensar que se puede disminuir la ejecución de una actividad, añadiendo más recursos a ella. Es cierto que se nota una reducción, pero no en una escala lineal. Aumentar el número de trabajadores puede realmente reducir el tiempo de ejecución de una tarea, pero este tipo de medida también provoca un incremento de costes, que en algunos casos no compensa. El Project Manager deberá saber estimar el número correcto de recursos que pueden ser asignados a una tarea sin comprometer su duración y/o incrementar indebidamente los costes. La curva de aprendizaje Existe un concepto llamado “curva de aprendizaje”, que es un modelo matemático que demuestra que la repetición de una determinada actividad conlleva a que su tiempo de desarrollo sea cada vez más reducido y consecuentemente sus costes también. Por ejemplo, el montaje de una misma máquina por la centésima vez será mucho más rápido y menos costoso que la primera vez. Es algo que el Project Manager deberá tener en cuenta a la hora de estimar duraciones.

Figura 69: Curva de aprendizaje Algunos proyectos incluyen actividades muy familiares cuyas estimaciones son sencillas de realizar. No obstante, en muchos casos, hay un total desconocimiento de la duración necesaria para llevar a cabo una determinada tarea, sobre todo en proyectos innovadores. No importa cuál sea el caso, siempre será necesario realizar estimaciones considerando las variables descritas anteriormente. Algunas consideraciones importantes acerca de la estimación de duración de actividades: Es importante tener como base el calendario laboral y estimar las duraciones en días laborales. Verificar la existencia de festivos durante los periodos de ejecución del proyecto. Las horas extra no se consideran.

El nivel de experiencia del personal es un factor importante a la hora de realizar estimaciones de tiempo. Incluir las reuniones de revisión en los cronogramas. En muchos casos, las reuniones pueden llegar a consumir el 10% del tiempo total de un proyecto. Considerar tiempos de viaje y desplazamientos; Considerar la disponibilidad de infraestructuras (equipos informáticos, maquinaria, vehículos, entre otras). Tener siempre en cuenta que los trabajadores necesitan formación, pueden estar asignados a más de un proyecto, cogen vacaciones y a veces solicitan bajas médicas por problemas de salud. 6.4.1 Técnicas y herramientas 6.4.1.1 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1 6.4.1.2 Estimación analógica (Analogous estimating or top-down estimates) Cuando el equipo se reúne para determinar la duración de las actividades del proyecto, hay casos en que no se dispone de información suficiente para poder realizar las estimaciones correctas. En este caso, se utiliza la estimación analógica, que es una técnica utilizada para determinar la duración de una determinada actividad, basándose en otra actividad similar que ha sido desarrollada en un proyecto anterior. Las organizaciones que desarrollan proyectos muy parecidos cuentan con una base de datos que contiene información valiosa que puede ser aprovechada en otros proyectos y con ello reducir el tiempo de reuniones para estimación de

duraciones. Esta herramienta suele ser menos costosa que otras técnicas, pero también es menos precisa. Sin embargo, puede ser considerada fiable cuando los proyectos anteriores comprenden un contenido realmente similar y los encargados por realizar las estimaciones son profesionales con experiencia. NOTA DEL AUTOR El mantenimiento de un archivo de los proyectos realizados permitirá a la empresa disponer de una inagotable y valiosa fuente de información que aportará estimaciones fiables, como es el caso de la estimación analógica. No obstante, es importante tener en cuenta que los datos aportados por un proyecto de características similares no pueden ser 100% aplicables a un nuevo proyecto, puesto que, en cualquier caso, siempre habrá diferencias que deberán ser consideradas. Vamos suponer que en un proyecto anterior, la empresa ha construido un puente de cinco kilómetros en dos meses. El siguiente proyecto prevé la construcción de otro puente que presenta las mismas características del anterior, con una única diferencia que este tendrá una extensión de veinte kilómetros. Haciendo una estimación analógica, se podría estimar un plazo de ocho meses para concluir este proyecto. No podemos dejar de considerar que existen otras variables a parte del puente. Por ejemplo, el puente anterior fue construido en verano y el nuevo será construido en invierno. Las condiciones climáticas de las estaciones del año tienen un peso importante a la hora de estimar los plazos del proyecto. Además, el puente anterior se construyó sobre un terreno previamente asfaltado y en este nuevo proyecto, el terreno se encuentra en el medio de una zona boscosa, sin haber recibido todavía ningún tratamiento previo. Como se pudo apreciar, la eficacia de la estimación analógica depende severamente de las similitudes de dos proyectos, con lo que es fundamental realizar una comparación a fondo de todas las características de ambos proyectos.

6.4.1.3 Estimación paramétrica (Parametric estimating) Esta técnica utiliza una relación estadística entre datos históricos y otras variables para calcular los costes de un recurso en una determinada actividad del proyecto (ejemplo: metros cuadrados en la construcción, líneas de códigos en desarrollo de software, lauda de texto traducido...). Es una herramienta que puede producir resultados muy fiables, dependiendo de la complejidad del proyecto y de la cantidad de información conocida. 6.4.1.4 Técnica de evaluación y revisión de programas (Program evaluation and review technique - PERT) Inventada en 1958, la técnica de revisión y evaluación de programas (program evaluation and review technique - PERT) es un método utilizado en el análisis de las tareas que forman parte de un proyecto, sobre todo cuando existe un grado importante de incertidumbre en relación a sus duraciones. También es conocida como three-point estimating. El PERT realiza tres estimaciones para cada actividad: PesimistaTP: define el mayor tiempo que puede durar una actividad. OptimistaTO: define el menor tiempo que puede durar una actividad. Más probableTM: define el tiempo más probable que puede durar una actividad. La fórmula utilizada con el PERT es la siguiente: (O + 4M + P) / 6 O = Es la estimación optimista para la duración de una determinada tarea. M = Es la estimación más probable para la duración de una determinada tarea. P = Es la estimación pesimista para la duración de una determinada tarea.

Figura 70: Gráfico PERT Estadísticamente, esta fórmula tiende a la estimación a más probable, pero permite algunos ajustes para acomodar los extremos mínimos y máximos. En la tabla que hay a continuación se ha aplicado la formula PERT en tres actividades. En el caso de la actividad “A” se ha estimado una duración optimista de siete días. En el caso en que surgiera algún tipo de incidencia, la duración podría llegar a catorce días. En condiciones normales la tarea “A” consumiría probablemente nueve días. Aplicando la formula PERT, se ha llegado a una duración ajustada de diez días, que añade tres más que la estimación más optimista, pero que no alcanza los catorce días resultantes de una estimación pesimista.

Figura 71: Tabla PERT NOTA DEL AUTOR ¿Cuánto tiempo se lleva para pescar un pez? Es una pregunta muy difícil de responder. En algunos casos, puede llevar un minuto y a veces un pescador puede volver a casa con las manos vacías después de pasar todo un día a la orilla del río. Es muy difícil realizar estimaciones, y cuando se estiman las duraciones de un proyecto, normalmente se llega a resultados equivocados. Para que un PERT pueda aportar el resultado más fiable posible, es muy importante que las duraciones optimistas, pesimistas y más probables sean muy bien definidas. Para llegar a un número adecuado, se recurren a los recursos que se expresan a continuación. 6.4.1.5 Base histórica de proyectos (Historical records) Un proyecto finalizado correctamente es un proyecto bien documentado. Proyectos que cuentan con una buena documentación pueden guardar informaciones importantes, como, por ejemplo, las estimaciones de las actividades realizadas para su desarrollo. Hay casos en que se encuentran estimaciones muy sofisticadas con datos que pueden incluir, además de las duraciones, las características de las actividades y los conocimientos necesarios para realizarlas. La base histórica de proyectos puede incluir:

Tareas: Muchos proyectos pueden tener actividades muy similares e incluso idénticas. Consultar cómo se ha realizado el desarrollo de estas tareas en proyectos anteriores similares puede ser una forma eficaz de realizar nuevas estimaciones. EDT: Es una herramienta de descomposición del trabajo realizado en un proyecto, orientada a los entregables del mismo, que organiza y define su alcance (para más detalles, véase también la sección 5.3). Informes: Si la comunicación de un proyecto ha sido correctamente desarrollada, una serie de informes de seguimiento deberían haber sido distribuidos a todos los interesados a lo largo de su ciclo de vida. Estos informes suelen aportar información útil a proyectos futuros, ya que describen posibles problemas encontrados durante el desarrollo de sus actividades y propone las medidas preventivas o correctivas tomadas en su momento. Estimaciones: En muchos casos, se podrán encontrar en proyectos anteriores actividades similares. Las estimaciones realizadas pueden aportar informaciones que pueden ser utilizadas en el proyecto actual. Planes de proyecto: El plan de proyecto es un documento formal y aprobado por la dirección y es utilizado principalmente para la administración del proyecto de forma general. Se puede aprovechar mucha información de un plan de proyecto similar desarrollado anteriormente y aplicar varias de sus estimaciones en el plan de proyecto actual. Lecciones aprendidas: (descrita en el Apéndice A, doc nº 054). Riesgos: El nivel de riesgo de un proyecto dependerá sobre todo de la cantidad de información disponible. De cuanta más información disponga el equipo, menor será el riesgo, ya que el nivel de incertidumbre será reducido.

Recursos necesarios: Si un proyecto anterior cuenta con una buena documentación de gestión de recursos, ciertamente esta documentación incluirá los procesos, las técnicas, las herramientas y la documentación utilizada para realizar el uso efectivo de las personas involucradas. 6.4.1.6 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1 6.4.1.7 Técnica delphi (Delphi technique) La técnica delphi es una metodología de investigación multidisciplinar para la realización de pronósticos y predicciones. Fue desarrolla por la Corporación Rand al inicio de la Guerra Fría para investigar el impacto de la tecnología en la guerra. El nombre del método se basa en las predicciones del Oráculo de Delfos. Su objetivo es la consecución de un consenso basado en la discusión entre expertos. Esta técnica puede producir buenas estimaciones, y elimina un problema común que suelen ocurrir en las secciones de tormenta de ideas (brainstorming, véase también sección 11.2.1.8), como la timidez o la sensación de intimidación por parte de algún participante. Utilizando la técnica delphi, los participantes pueden contar con el anonimato, una vez que la recogida de opiniones puede ser realizada a través de chat o por e-mail, lo que también añade la ventaja de poder incluir personas de distintas localidades. En esta técnica, un facilitador (por ejemplo, el Project Manager), solicita a los participantes que aporten ideas acerca de los riesgos de un determinado evento. El facilitador recoge todas las ideas enviadas y la centraliza en un listado, que será reenviado a todos los participantes, para que estos puedan añadir más información sobre la lista anteriormente estructurada. Esta lista circulará hasta que no se generen ideas nuevas.

La ventaja principal de esta técnica es que recoge la opinión sobre el proyecto actual basada en experiencias anteriores difíciles de evaluar por otros medios (características especiales del personal, peculiaridades del proyecto...). 6.4.1.8 Reserva de tiempo (Contingency time) Cuando se estiman duraciones de actividades, se intenta buscar el plazo más próximo a la realidad, y eso puede ser posible utilizando algunas de las técnicas mencionadas anteriormente. Sin embargo, aunque se estime correctamente la duración de una actividad, es común añadir una cantidad de tiempo extra, por si acaso surge alguna incidencia no esperada. Existe una teoría llamada ley de Parkinson (Parkinson´s law), creada por Cyril Northcote Parkinson 22 en un artículo publicado en el semanario británico The Economist en 1955 que dice: “El trabajo se amplia para cubrir todo el tiempo disponible para su conclusión”. O sea, si una determinada tarea tiene un plazo estimado de seis días y se añaden dos más como contingencia, según la ley de Parkinson, esta tarea llevará ocho días para ser completada. Por supuesto, esta teoría no pretende derrumbar la técnica de la reserva de tiempo, pero intenta demostrar que no será simplemente añadiendo un par de días más a cada tarea, que se alcanzará el cronograma perfecto; todo lo contrario, esta práctica puede tornarse un vicio que convertirá el proyecto en un emprendimiento interminable. La reserva de tiempo o contingencia debe ser utilizada de forma correcta para realmente ser eficaz. Y eso se hace de la siguiente forma: de acuerdo con el tipo de proyecto se añade un porcentaje de tiempo extra al final del proyecto, que será utilizado en tareas que ultrapasen el plazo estimado de conclusión. Este porcentaje puede variar entre el 5% y el 10% del tiempo total estimado de finalización de todo el proyecto. Se utilizará el 5% en proyectos cuyo grado de incertidumbre es bajo y el 10% cuando se utilizan, por ejemplo, nuevas tecnologías.

Una vez que se determine el plazo total del proyecto, se creará una tarea que será la “reserva de tiempo” y que tendrá como duración el porcentaje necesario de tiempo extra. Esta tarea será la última tarea del proyecto. De esta forma, las actividades del proyecto contarán con un plazo estimado real sin reservas, y el equipo del proyecto reunirá los esfuerzos necesarios para cumplir con cada plazo determinado. Imaginemos un proyecto en que se estiman ciento veinte días para su conclusión. Se le añade un 10% de reserva (es decir doce días más). El proyecto tendrá un plazo final de ciento treinta y dos días. Si una determinada tarea consume dos días más que el originalmente previsto, se descontará dos días de la reserva, que pasaría a contar con diez días. Esta técnica permite que el Project Manager pueda gestionar la reserva disponible de forma más dinámica. Si un proyecto ha completado el 35% de sus actividades, pero ya ha consumido la mitad de la reserva, ya se sabe con mucha antelación que el proyecto no avanza según el plan. Estimar correctamente un tiempo adecuado de contingencia no es una labor muy sencilla. No obstante, es posible llegar a un valor muy aproximado, obedeciendo algunos principios básicos: Cuanto más largo y complejo el proyecto, más tiempo de contingencias será necesario. La contingencia aplicada deberá ser proporcional al riesgo del proyecto. El tiempo de contingencia podrá ser reducido si el proyecto en marcha es muy similar a algún proyecto anterior. Se podrá tomar como base el nivel de experiencia del equipo a la hora de decidir la cantidad de contingencia que será utilizada. Existe una técnica llamada gestión de proyectos por cadena crítica, descrita en la sección 6.5.1.2, que aporta más informaciones sobre la gestión de las contingencias de un proyecto.

6.4.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) Estimación de la duración de la actividad (Véase 6.4) (Activity duration estimates) DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates) 6.5 Desarrollo del cronograma del proyecto (Proceso que corresponde a la fase de planificación del proyecto) El desarrollo del cronograma es un proceso que consiste en analizar las actividades establecidas para un proyecto, su duración, los recursos necesarios y las restricciones identificadas. La incorporación de todas estas informaciones generará un cronograma con fechas planificadas que deberán ser cumplidas. El desarrollo de un cronograma es una de las tareas clave de un proyecto y podrá exigir el repaso y una revisión en profundidad de los tiempos de duración estimados de cada actividad y de los recursos necesarios para su correcta puesta en marcha. Es importante recordar que un cronograma es un documento que necesita de un seguimiento constante para mantenerse realista y sostenible. 6.5.1 Técnicas y herramientas 6.5.1.1 Método del camino crítico (Critical path method – CPM) Descrito en la sección 6.2.1.4 6.5.1.2 Gestión de proyectos por cadena crítica (Critical chain Project Management- CCPM) Presentada por el físico israelí Eliyahu Goldratt 23 en 1997 en su libro Critical Chain, la gestión de proyectos por cadena crítica (Critical Chain Project

Management - CCPM) está basada en algoritmos de su teoría de las restricciones* y se acredita que su técnica es capaz de reducir los costes y plazos entre un 10% y un 50% más que los métodos tradicionales. Esta técnica ha sido desarrollada para solucionar uno de los vicios más recurrentes del Project Management, que es la adición de tiempo innecesario a la ejecución de una tarea, observada en varios proyectos, incluso los de alto nivel. A la hora de realizar las estimaciones de duración de una determinada tarea, existe una tendencia natural a añadirle más plazo de lo necesario como forma de protección frente a la incertidumbre. Esta protección nos permitirá finalizar la tarea dentro del plazo estimado, incluso en los casos más desfavorables. La figura 72 ilustra cómo solemos realizar nuestras estimaciones de tiempo de ejecución de tareas:

Figura 72: Estimaciones de tiempo con colchón de seguridad Como se puede apreciar en la figura 72, una tarea recibe un colchón de seguridad de tiempo que muchas veces puede ser del orden del doble de lo que sería la duración media de la tarea. Si aplicamos esta regla a todas las actividades de un proyecto, su tiempo total de finalización sería el doble, es decir, si una obra contiene tareas que normalmente consumen veinte días de ejecución, aplicando colchones de seguridad a todas las actividades del proyecto, la obra tendría un plazo total de cuarenta días para finalizar. El colchón de seguridad nos permite, entonces, terminar el proyecto dentro del

plazo, ya que nos ha añadido el doble del tiempo necesario para su ejecución. No obstante, lo que se ve es que el proyecto, por más colchones de tiempo que se añadan, terminará retrasado de la misma forma. Esto ocurre debido a una teoría conocida como la “síndrome del estudiante” (student syndrome), en el que una persona comenzará a esforzarse en la finalización de una actividad faltando muy poco para el vencimiento de su plazo. La consecuencia principal de esta actitud es la pérdida de cualquier imagen de tiempo establecido en la fase de estimación de tiempo de ejecución de actividades. La figura 73 nos ilustra cómo se administra de forma equivocada el esfuerzo dedicado a una actividad. Prácticamente, durante el 70% del tiempo asignado a esta actividad, el nivel de esfuerzo ha sido mínimo, elevándose sustancialmente en el 30% del tiempo disponible.

Figura 73: Síndrome del estudiante Lo primero que la cadena crítica pretende defender es la idea de que añadir colchones de seguridad a todas y cada una de las tareas no tiene ningún sentido. Este tipo de actitud nos lleva a preocuparnos por terminar cada tarea a tiempo, cuando lo que realmente importa es finalizar el proyecto en el plazo previsto. La cadena crítica tiene una filosofía totalmente opuesta: trata de gestionar exactamente la imposición del plazo mínimo en que un proyecto puede ser realizado.

Se puede definir entonces la cadena crítica como la secuencia de tareas más corta teniendo en cuenta los conflictos de recursos. A través de la tabla que presento a continuación podemos comparar los conceptos de la cadena crítica con las técnicas de gestión tradicionales:

Figura 74: Método de la cadena crítica x método tradicional El método de la cadena crítica es considerada como uno de los más importantes avances en el Project Management en los últimos treinta años y tiene su origen en la teoría de las restricciones (véase también “nota del autor”, al final de esta sección). De acuerdo con Goldratt 23, las previsiones de las estimaciones son normalmente aportadas por personas distintas, que, en algunos casos, no tienen acceso a toda la información del proyecto, causando una cierta incertidumbre que, naturalmente, les motivará a añadir un colchón de seguridad muchas veces innecesario.

La cadena crítica, por lo tanto, sugiere que se planifiquen las actividades estimando sus duraciones de forma agresiva, reduciendo el tiempo hasta un nivel que permita la realización de su ejecución sin comprometer su calidad.

Figura 75: Tabla con las actividades y sus colchones de seguridad

Figura 76: Tabla con las actividades y sus colchones de seguridad dispuesta al final del cronograma. Este tipo de estrategia permite eliminar una serie de colchones de seguridad añadidos innecesariamente que “inflan” el proyecto, volviéndole más manejable y con estimaciones más realistas. NOTA DEL AUTOR * La esencia de la teoría de las restricciones se basa en cinco puntos: 1. 2. 3. 4. 5.

Identificar las restricciones del sistema. Decidir cómo explotarlas. Subordinar todo a la decisión anterior. Superar la restricción del sistema (elevar su capacidad). Si en los pasos anteriores se ha roto una restricción, regresar al paso 1.

Para conocer en profundidad la metodología de la cadena crítica, consulte la obra de Eliyahu M. Goldratt23 Cadena Crítica – Una novela empresarial sobre la gestión de proyectos, editorial Díaz de Santos.

6.5.1.3 Nivelación de recursos (Resource leveling) Una de las grandes dificultades en el Project Management es asegurar que el trabajo ha sido asignado al equipo de forma equilibrada. Si no se logra realizar una adecuada gestión de los recursos del proyecto, se darán casos donde algunos integrantes estarán sobrecargados, mientras otros tendrán demasiado tiempo ocioso. La nivelación de recursos es una técnica utilizada para evaluar el uso desequilibrado de recursos y resolver sus conflictos y/o asignaciones equivocadas. Actualmente la mejor forma de de utilizar esta herramienta es a través de programas informáticos dedicados que son capaces de administrar escenarios complejos donde se ejecutan múltiples proyectos a la vez. Cruzando las informaciones de los calendarios de los proyectos y del personal, es posible determinar la cantidad óptima de mano de obra disponible en cada momento del proyecto. 6.5.1.4 Análisis “¿Qué pasa si…?” (What-if scenario analysis - WISA) El análisis WISA (¿Qué pasa si…?) es una técnica que utilizamos en nuestro cotidiano, con cuestiones tan sencillas como la que presento a continuación: Su novia le pide que la lleve al cine este viernes y, como trabajas hasta tarde, decides llevarla a la última sesión, que empieza a las once de la noche. De súbito, te haces la siguiente reflexión: “¿Qué pasa si llegamos al cine y no quedan entradas disponibles?”. La respuesta a esta pregunta deberá ser una o más soluciones alternativas, por ejemplo: “Si no quedan más entradas, la llevo a cenar a su restaurante favorito”. Este tipo de situación se repite decenas de veces en el Project Management. La pregunta “¿Qué escenario podríamos tener sí ocurre una determinada situación?”.

El mercado dispone de un gran abanico de herramientas informáticas WISA, que son capaces de crear varios escenarios para determinadas cuestiones relacionadas con costes, plazos, cambios y riesgos en general. NOTA DEL AUTOR Las herramientas que realizan análisis WISA necesitan de una cantidad importante de información, para poder realizar un análisis eficaz. Por ello, es importante que se introduzcan los siguientes datos: La creación de un escenario actual, que será el punto de partida para un análisis “¿Qué pasa si…?”. Determinar los valores y variables que harán cambiar los escenarios contemplados. Determinar los recursos disponibles para cada escenario sugerido. Una herramienta muy similar al WISA, es el método de los escenarios, descrita detalladamente en la sección 11.3.1.4. 6.5.1.5 Aplicación de adelantos y retrasos (Applying leads and lags) Descrita en la sección 6.2.1.6 6.5.1.6 Ejecución rápida (Fast Tracking) La técnica de la ejecución rápida significa poner en ejecución dos o más actividades en paralelo, en vez de ejecutarlas secuencialmente. Lógicamente, esta técnica no se puede aplicar en todos los casos, por ejemplo, no se puede levantar un tabique y pintarlo a la vez, pero utilizando correctamente la técnica de la ejecución rápida se podría ir pintando las partes del tabique que ya están listas para la pintura, en vez de esperar a que todo el tabique esté completamente construido. Sin embargo, este tipo de técnica tiene un riesgo involucrado que puede provocar un incremento de coste y plazo, si ocurre

algún imprevisto. Por esta razón, es muy importante tener la actividad muy bien planificada, para poder aplicar esta técnica con los riesgos mitigados. NOTA DEL AUTOR Algunos autores estiman que en algunos casos se puede aplicar la ejecución rápida de la siguiente manera: la segunda actividad puede empezar a ser ejecutada cuando la actividad anterior esté al 66% completada. Este sería el porcentaje más conservador y de menor riesgo involucrado para poder aplicar la ejecución rápida. Sin embargo, cada proyecto tiene su naturaleza y características propias que pueden exigir un porcentaje de trabajo realizado más alto. 6.5.1.7 Compresión (Crashing) En el Project Management, el término “compresión” (crashing) significa reducir las actividades del camino crítico con el objetivo de terminar el trabajo antes del tiempo previsto, o en el peor de los casos, en el tiempo originalmente previsto (cuando se aprecia la posibilidad de que el trabajo podría terminar con retraso). Una de las formas más comunes de aplicar la compresión es añadiendo trabajadores a una o más actividades del camino crítico. Si un trabajador está trabajando en una tarea que necesita de diez horas para ser completada, y existe una necesidad de completarla en menos tiempo, se añade un segundo trabajador, que posibilitaría la reducción del plazo original de diez horas estimado para la ejecución de esta actividad. Los recursos añadidos en un proyecto pueden venir de la propia plantilla de la empresa o pueden ser contratados de forma temporal. Esta técnica puede asegurar la entrega de un producto o servicio antes del plazo determinado, pero, sin embargo, implicará en costes añadidos, ya que se incrementan los recursos asignados para completarla en menos tiempo. De todas formas, muchas veces, la empresa prefiere asumir este incremento de costes, asegurando la entrega dentro del plazo. En el ejemplo que viene a continuación podemos ver una serie de actividades cuya duración estimada total es de cuarenta días.

Figura 77: Serie de actividades

Figura 78: Aplicación de la compresión Este tipo de técnica es muy utilizada en determinadas circunstancias en que el plazo final no puede ser, en ninguna hipótesis, postergado. En la década de los 90, muchas empresas de software tuvieron que afrontar el problema del año 2000, más conocido como el “efecto 2000” o “Y2K”. Sus aplicaciones informáticas corrían el riesgo de parar de funcionar si no se implantaban las correcciones necesarias antes de que terminara el año 1999. Bancos, empresas de telefonía y otras compañías de grande porte invirtieron millones de dólares para evitar que ocurriese una “catástrofe informática”, que felizmente no ha llegado a ocurrir. Los proyectos de desarrollo de aplicaciones informáticas que pretendían subsanar el “Y2K” tenían que

tenerlo todo listo antes de que empezara el año 2000 y, para ello, el método de la compresión tuvo que ser puesto en marcha para lograr este objetivo. En la preparación de grandes eventos deportivos, como los juegos olímpicos o los mundiales de futbol, la técnica de la compresión es ampliamente utilizada. Desventajas de la compresión: Aumento de costes del proyecto: La compresión demanda más gente trabajando en una actividad, lo que conlleva a un incremento en los costes de mano de obra. Aumento de los riesgos: La compresión conlleva a la gestión de una ejecución acelerada de trabajo, con más recursos añadidos en un plazo de tiempo reducido. Cualificación del equipo: Cuando es necesario incluir más recursos de última hora, normalmente estos recursos disponibles no son los mejores cualificados. En algunos casos, será necesario darles algún tipo de formación. Calidad: Tener que reducir la duración de la ejecución de una tarea, añadiéndole más trabajadores, que, además, podrán contar con la cualificación necesaria, provocará problemas de integración y comunicación entre el grupo, lo que podría comprometer la calidad de ejecución de la tarea. 6.5.1.8 Gráfico de barras de Gantt (Gantt chart) El gráfico de Gantt fue concebido por el ingeniero estadounidense Henry L. Gantt 24 durante la primera guerra mundial. En aquel entonces, Gantt buscaba resolver el problema de la programación de actividades, es decir, su distribución conforme un calendario, de manera que fuese posible visualizar de manera sencilla el periodo de duración de cada actividad, sus fechas de inicio y fin, y también el tiempo total requerido para la ejecución del trabajo. Este gráfico consiste en un sistema de coordinadas en que se indica un eje

horizontal que representará una escala de tiempo definido en términos de unidad más adecuada al trabajo que se va a ejecutar: hora, día, semana o meses, y un eje vertical que constituye las actividades del proyecto. Ha sido desarrollado para presentar la información acerca del estado de un proyecto, de una forma fácil de comprensión, sobre todo a la hora de realizar comparaciones de datos estimados por datos realizados. A cada actividad se hace corresponder una línea horizontal cuya longitud es proporcional a su duración en la cual la medición efectúa con relación a la escala definida en el eje horizontal conforme se ilustra en la figura 79.

Figura 79: Gráfico de barras de Gantt Características gráficas: Cada actividad es representada mediante un bloque rectangular cuya longitud indica su duración. La altura carece de significado. La posición de cada bloque en el diagrama indica las fechas de inicio y finalización de cada actividad de acuerdo con la escala de tiempo asignada.

La figura 80 representa una variación del gráfico de Gantt. La diferencia básica es el uso de triángulos en lugar de barras. En este tipo de Gantt, los triángulos con la punta hacia arriba representan la fecha de inicio de cada actividad y los triángulos con la punta hacia abajo, la fecha de conclusión de la tarea. Las fechas planificadas corresponden a los triángulos blancos y las fechas reales a los triángulos grises.

Figura 80: Variación del gráfico de barras de Gantt Comparando la figura 79 con la 80 se podrá apreciar que ambos gráficos presentan la misma información. La tarea B, por ejemplo, ha empezado más tarde y su duración será mucho más larga que lo planificado. Lo mismo pasa con la tarea D. Las tareas E y F, de momento, siguen lo establecido por el plan. Método constructivo Para construir un diagrama de Gantt se han de seguir los siguientes pasos:

Dibujar los ejes horizontal y vertical. Escribir los nombres de las tareas sobre el eje vertical. En primer lugar, se dibujan los bloques correspondientes a las tareas que no tienen predecesoras. Se sitúan de manera que el lado izquierdo de los bloques coincida con el instante cero del proyecto (su inicio). A continuación, se dibujan los bloques correspondientes a las tareas que sólo dependen de las tareas ya introducidas en el diagrama. Se repite este punto hasta haber dibujado todas las tareas. En este proceso se han de tener en cuenta las siguientes consideraciones: Las dependencias fin-inicio (finish-to-start) se representan alineando el final del bloque de la tarea predecesora con el inicio del bloque de la tarea dependiente.

Figura 81: Relación finish-to-start Las dependencias final-final (finish-to-finish) se representan alineando los finales de los bloques de las tareas predecesora y dependiente.

Figura 82: Relación finish-to-finish Las dependencias inicio-inicio (start-to-start) se representan alineando los inicios de los bloques de las tareas predecesora y dependiente.

Figura 83: Relación start-to-start La relación start-to-finish es la menos utilizada en un proyecto. La actividad predecesora debe empezar antes que finalice la actividad sucesora.

Figura 84: Relación start-to-finish Cálculos El diagrama de Gantt es un diagrama representativo que permite visualizar fácilmente la distribución temporal del proyecto, pero es poco adecuado para la realización de cálculos. Por la forma en que se construye, muestra directamente los inicios y finales mínimos de cada tarea. NOTA DEL AUTOR Ventajas y desventajas de los gráficos de Gantt Los gráficos de barras de Gantt se revelan muy eficaces en las etapas iniciales de planificación. No obstante, después de iniciada la ejecución de la actividad y cuando comienzan a efectuarse modificaciones, el gráfico tiende a volverse confuso. Cuando esto ocurre, normalmente se requiere la confección de un nuevo gráfico. Aún en términos de planificación, existe una limitación bastante grande en lo que se refiere a la representación de planes de cierta complejidad. En resumen, para la planificación de actividades relativamente simples, el gráfico de Gantt representa un instrumento de bajo coste y de extrema simplicidad en su utilización. Para proyectos complejos, sus limitaciones son bastantes serias, y fueron estas las que llevaron a ensayos que dieron como resultado el desarrollo del CPM, del PERT (véase también sección 6.4.1.4) y otras técnicas conexas.

De todas formas, el gráfico de barras de Gantt es ampliamente utilizado por las organizaciones y se ha hecho muy popular por la simplicidad de su confección y su uso. Es fácil de hacer y de entender y, actualmente, está incorporado en los programas de planificación más utilizados del mercado. Su simplicidad es tan evidente, que incluso ni siquiera hace falta un ordenador o un software específico para confeccionarlo. Un papel, un lápiz y una regla son suficientes para poder sacar partido de esta herramienta. 6.5.1.9 Grafico de hitos (Milestones) Un hito es un punto del cronograma normalmente señalizando un evento importante del proyecto, como la conclusión de una determinada fase o la entrega de un módulo importante del proyecto. Los hitos no son actividades, es decir, no consumen tiempo, ni recursos, ni duraciones. Son tan solo un punto de referencia del proyecto.

Figura 85: Gráfico de hitos 6.5.2 Documentación generada en este proceso

(Véase Apéndice A – documentos del proyecto) DOC nº 014 – Cronograma del proyecto (Project schedule) Línea base del cronograma (Véase sección nº 2.1.3) (Schedule baseline) DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates) 6.6 Control del cronograma (Proceso que corresponde a la fase de control del proyecto) El control del cronograma es el proceso que realiza el seguimiento del estado actual del proyecto, el control de su avance y la gestión de los cambios realizados en su línea base. Los objetivos de este proceso son los siguientes: Determinar el estado actual del cronograma del proyecto. Influir en los factores que generan cambios en el cronograma. Determinar que el cronograma del proyecto ha cambiado. Gestionar los cambios reales conforme suceden. 6.6.1 Técnicas y herramientas 6.6.1.1 Medición del rendimiento (Earned value management) Descrito en la sección 7.3.1.1 6.6.1.2 Índice de desempeño del cronograma (Schedule performance index – SPI) El índice de desempeño del cronograma es la medida del avance logrado en un proyecto en comparación con el avance planificado. Básicamente, esta herramienta utiliza fórmulas matemáticas para determinar el grado de cumplimiento del cronograma establecido en la fase de planificación del

proyecto. La fórmula utilizada para la obtención del SPI es la siguiente: SPI = BCWP/BCWS Los resultados obtenidos traducen las siguientes situaciones: SPI=1: El proyecto está en el plazo previsto. SPI>1: El proyecto está adelantado. SPI1: El proyecto está gastando menos de lo previsto. CPI1: El proyecto está adelantado. SPI1: El proyecto está gastando menos de lo previsto. CPI