Story Transcript
Desarrollo de un modelo integrado de procesos para la gestión de proyectos diseñados según PMBOK®, homologable con ISO 21.500:2.012 y compatible con PRINCE2®. MGIP: Modelo de Gestión Integrada de Proyectos
Ángel Nájera Pérez
Departamento de Ingeniería Civil Escuela Politécnica Superior
Desarrollo de un modelo integrado de procesos para la gestión de proyectos diseñados según PMBOK®, homologable con ISO 21.500:2.012 y compatible con PRINCE2®. MGIP: Modelo de Gestión Integrada de Proyectos Autor:
D. Ángel Nájera Pérez
Tesis presentada para aspirar al grado de Doctor por la Universidad de Alicante
Programa de doctorado en Ingeniería de Materiales, Estructura y Terreno: Construcción Sostenible
Dirigida por:
Dr. D. Sergio García Domenech Dr. D. Juan Carlos Trujillo Mondéjar
Dedicatoria
Dedico esta tesis a mi padre Ángel, con quien he compartido mis logros y que seguro que se alegrará también de éste donde quiera que esté. Ángel Nájera Pérez Alicante, Mayo de 2016
i
Agradecimientos En primer lugar me gustaría agradecer especialmente a mis directores de tesis Sergio García Domenech y Juan Carlos Trujillo Mondéjar, quienes me han animado y empujado para poder completar esta tesis y continuamente me han recordado el valor del esfuerzo. A mi esposa María y a mi hijo Mauro que me han apoyado y entendido el sacrificio que ha representado para todos la dedicación necesaria para la obtención de este resultado. A los miembros de la Comisión Académica del programa de doctorado en Ingeniería de Materiales, Estructura y Terreno: Construcción Sostenible, especial a Miguel Ángel Climent Llorca, Isidro Sánchez Martín y Pablo Martí Ciriquian quienes me han facilitado el poder finalizar esta tesis doctoral. Finalmente quiero agradecer a mis compañeros del ámbito profesional sin cuya ayuda habría sido muy difícil haber encontrado el tiempo necesario.
ii
“Con una planificación cuidadosa y detallada, se puede ganar; con una más descuidada y menos detallada, no se puede ganar. ¡Cuánto más segura es la derrota si no se planea en absoluto!. Dependiendo de la manera en como se ha planificado, podemos predecir la victoria o la derrota”. Sun Tzu (544 a.C – 496 a.C)
iii
Resumen La gestión de proyectos es un área de gran desarrollo e interés para las empresas y organizaciones, tanto si basan su estrategia empresarial en los beneficios que se obtienen con ellos, como si, simplemente, los necesitan para seguir con sus actividades. En cualquier caso, es una herramienta de cambio que permite adaptarse a las necesidades de sus clientes. Es importante resaltar, que un proyecto es algo único que se realiza por un grupo o equipo en un momento dado, por que la propia organización del proyecto es un ente temporal que se creará y se disolverá una vez éste haya finalizado. Esto significa que por su propia naturaleza es una organización no estable, donde el conocimiento no se retiene, de forma que en cada proyecto se puede volver a reinventar la rueda. Para evitar repetir los errores y aprovechar las experiencias y el conocimiento generado en cada uno de ellos, varias organizaciones y asociaciones han recopilado las buenas prácticas en gestión de proyectos, siendo muy recomendable su consideración. De hecho, en 1.969 se creó PMI® ‐Project Management Institute‐, con el objetivo de agrupar este conocimiento y fomentar la profesión del director de proyectos. Este instituto edita la guía para la gestión de proyectos más influyente y reconocida a nivel mundial, a saber, el PMBOK® o Project Management Body of Knowledge, cuerpo de conocimiento de esta área en el que se indican los procesos a implantar en un proyecto según el consenso alcanzado por un grupo de expertos. Este documento tan solo es una guía y, por tanto, no resulta ser de obligatorio cumplimiento. Expone la manera en la que un proyecto debería ser gestionado desde el punto de vista de su director. En el Reino Unido a través de la Oficina Gubernamental de Comercio, y a partir de las experiencias en el desarrollo de proyectos, puso en marcha un método que denominó PRINCE® –Projects in Cotrolled Environments‐ (en este momento se denomina PRINCE2®), que sí establecía de modo prescriptivo los principios, los temas y los procesos a implementar para gestionar un proyecto, de forma que las buenas prácticas generales descritas en los diferentes cuerpos de conocimiento se materializasen en un modelo concreto de gestión de proyectos. En estos momentos, PRINCE2® es de facto el estándar más utilizado, sobre todo, por las grandes organizaciones a nivel mundial. Finalmente, a nivel internacional, cabe señalar que se han generado varias iniciativas para crear un estándar de gestión de proyectos que sea reconocido en este nivel, lo que ayudaría a las relaciones comerciales entre diferentes países, así como, a facilitar el entendimiento a la hora de desarrollar proyectos entre diferentes, sectores, empresas y/o países. En esta línea, en 2.012, ISO publicó la norma básica ISO 21.500:2.012 que ‐basada fundamentalmente en el PMBOK®‐ pretende ser en un futuro la herramienta para que las empresas puedan certificarse, y por consiguiente, ser reconocidas como cumplidoras de la misma. En este entorno es en el que se ha gestado y basado la justificación de esta tesis, ya que en estos momentos se pueden encontrar empresas que han adoptado PRINCE2® y lo han hecho ajustándolo a sus necesidades, otras que están creando o adaptando sus procesos a la norma ISO 21.500:2.012, mientras que otras muchas basan sus procesos en las buenas prácticas descritas en el PMBOK®. Esta divergencia en la estrategia utilizada a la hora de gestionar los proyectos puede hacer que éstos sean ineficientes, sobre todo cuando la organización tiene que desarrollar proyectos con organizaciones o clientes que usen diferentes enfoques. Lo que obligaría a un esfuerzo extra tanto del equipo del proyecto como de la propia organización, y, en muchos casos, daría lugar a errores al no conocer con exactitud cómo proceder en cada caso, generándose por ello una falta de predictibilidad. De ahí que, en esta tesis, se haya abordado la posibilidad de diseñar un modelo o método que sea capaz de aunar ‐basándose en los procesos del PMBOK® y en las buenas prácticas de PRINCE2®‐ los tres diferentes enfoques, lo que sin duda facilitaría la interacción entre organizaciones. En esta tesis se han analizado y reformulado los principios a seguir de forma obligatoria a la hora de gestionar un proyecto, las áreas de conocimiento a analizar a lo largo del mismo y, sobre todo, los procesos que se deben utilizar, indicando tanto sus entradas como las salidas y los productos de gestión que se producen en cada uno de ellos, definiendo con detalle cómo se debería actuar para cumplir con las directrices de los tres enfoques. Todo este conocimiento se ha materializado en el MGIP o modelo de gestión integrada de proyectos y que pretende ser la base para que paulatinamente se vayan incorporando y homologando otros enfoques en gestión de proyectos que lo complementen. Así, se han generado 72 procesos, estructurados en 11 áreas de conocimiento y en 6 fases de gestión, que abarcan desde el origen de la necesidad de la dedicación de recursos para obteber un producto o servicio que pueda cubrir una necesidad, hasta el paso a operaciones de dicho resultado, pasando por las fases de inicio, planificación, ejecución y control y cierre. iv
Finalmente, indicar que la investigación desarrollada en esta tesis, confirma que es factible la consecución del objetivo principal de la misma, a saber, la creación del MGIP, y en base al mismo, alcanzar los beneficios generados al aunar los diferentes enfoques integrados en el mismo. Ello se ha demostrado a partir del resultado del análisis comparativo realizado sobre un caso práctico en el que una empresa que basa su estrategia de negocio en el desarrollo de proyectos bajo una metodología y unos procesos creados por ella y para ella, es comparada frente al enfoque descrito en el MGIP. Concluyéndose que la estrategia de gestión de la empresa analizada puede ser integrada completamente y mejorada en la metodología del MGIP.
v
Índice
1.
Parte 1: Aspectos Preliminares ....................................................................................................................... 11
1.1.
Introducción ............................................................................................................... 11
1.1.1. Motivación ..................................................................................................................... 11 1.1.2. La complejidad en la gestión de proyectos .................................................................... 18 1.1.3. La importancia de la estandarización ............................................................................ 19 1.1.4. Justificación de la tesis ................................................................................................... 22 1.1.5. Aportación de la tesis ..................................................................................................... 24 1.2.
Objetivos de la tesis.................................................................................................... 25
1.3.
Metodología de trabajo .............................................................................................. 27
1.3.1. Método deductivo‐inductivo ......................................................................................... 27 1.3.2. Revisión sistemática de la literatura existente .............................................................. 28 1.3.3. Aplicación de las técnicas de gestión de proyectos ....................................................... 28 1.4.
Estructura de la tesis .................................................................................................. 30
1.5.
Conceptos básicos en la gestión de proyectos ............................................................. 31
1.5.1. Definición de proyecto y gestión de proyectos ............................................................. 31 1.5.2. Breve historia de la gestión de proyectos ...................................................................... 33 1.5.3. Gestión de cartera de proyectos o porfolio ................................................................... 36 1.5.4. Gestión de programas .................................................................................................... 40 1.6.
Estándares existentes. Estado de la cuestión .............................................................. 47
1.6.1. Guía buenas prácticas PMBOK® ..................................................................................... 50 1.6.1.1. Antecedentes ......................................................................................................................... 50 1.6.1.2. Aspectos beneficios del PMBOK® en la gestión de proyectos ............................................... 51 1.6.1.3. PMBOK® como base para el desarrollo de estándares .......................................................... 52 1.6.1.4. La triple restricción ................................................................................................................ 53 1.6.1.5. Estructura del PMBOK® ......................................................................................................... 53 1.6.1.6. Procesos ................................................................................................................................. 54
1.6.2. ISO 21.500:2.012 ............................................................................................................ 55 1.6.3. Éxito en la gestión de proyectos con PRINCE2® ............................................................ 59 1.6.3.1. Antecedentes ......................................................................................................................... 59 1.6.3.2. Beneficios del uso de PRINCE2® ............................................................................................ 60 1.6.3.3. La actuación del director de proyecto en PRINCE2® ............................................................. 60 1.6.3.4. Estructura de PRINCE2® ......................................................................................................... 61
1.6.4. Otras asociaciones en gestión de proyectos .................................................................. 65 vi
1.6.5. Modelos y software relacionado con la gestión de proyectos ...................................... 66 1.6.5.1. TIC´s en gestión de proyectos; herramientas de software .................................................... 66 1.6.5.2. Análisis de cloud computing .................................................................................................. 70 2.
Parte 2: El modelo de gestión integrada de proyectos .................................................................................... 73
2.1.
Introducción ............................................................................................................... 73
2.2.
Estructura del modelo ................................................................................................ 73
2.3.
Principios básicos sobre los que se basa el MGIP ........................................................ 78
2.3.1. Justificación comercial continua .................................................................................... 78 2.3.2. Gestión orientada a la generación de productos........................................................... 79 2.3.3. Gestión por fases ........................................................................................................... 79 2.3.4. Gestión planificada y actualizada ................................................................................... 83 2.3.5. Adaptación al cambio .................................................................................................... 86 2.3.6. Gobernanza del proyecto; roles y responsabilidades definidas .................................... 92 2.3.7. Adaptación del proyecto al entorno ............................................................................ 100 2.3.8. Aprender de la experiencia .......................................................................................... 100 2.4.
Áreas de conocimiento aplicables a la gestión de un proyecto .................................. 102
2.4.1. Viabilidad y justificación comercial del proyecto ........................................................ 103 2.4.2. Integración ................................................................................................................... 106 2.4.3. Gestión de los interesados del proyecto ..................................................................... 108 2.4.4. Alcance ......................................................................................................................... 112 2.4.5. Tiempo ......................................................................................................................... 114 2.4.6. Coste ............................................................................................................................ 115 2.4.7. Calidad ......................................................................................................................... 116 2.4.8. Recursos del proyecto .................................................................................................. 120 2.4.9. Comunicación ............................................................................................................... 122 2.4.10. Riesgos ....................................................................................................................... 125 2.4.11. Adquisiciones ............................................................................................................. 131 2.5.
Procesos del modelo ................................................................................................ 134
2.5.1. Homologación del modelo ........................................................................................... 135 2.5.2. Mapa de procesos del modelo ..................................................................................... 139 2.5.3. Descripción de los procesos del MGIP ......................................................................... 146 2.5.3.1. Análisis previo ...................................................................................................................... 146 2.5.3.2. Inicio .................................................................................................................................... 151 2.5.3.3. Planificación ......................................................................................................................... 160 2.5.3.4. Ejecución y control del proyecto ......................................................................................... 189 vii
2.5.3.5. Cierre del proyecto .............................................................................................................. 216 2.5.3.6. Operaciones ......................................................................................................................... 224 3.
4.
5.
Parte 3: Caso de estudio ............................................................................................................................... 225
3.1.
Mapa de procesos por fase de gestión ...................................................................... 226
3.2.
Comparación procesos del caso vs MGIP .................................................................. 229
3.3.
Análisis crítico de la comparación de los procesos con el MGIP ................................. 237
Parte 4: Aspectos finales .............................................................................................................................. 241
4.1.
Análisis crítico comparativo entre los procesos de PMBOK® y PRINCE2® ................... 241
4.2.
Conclusiones ............................................................................................................ 244
4.3.
Trabajos futuros ....................................................................................................... 247
Parte 5: Anexos ............................................................................................................................................ 248
5.1.
ANEXO A: Los procesos del PMBOK® ........................................................................ 248
5.1.1. Los procesos en la gestión de la integración ............................................................... 248 5.1.2. Los procesos en la gestión del alcance ........................................................................ 251 5.1.3. Los procesos en la gestión del tiempo ......................................................................... 254 5.1.4. Los procesos en la gestión del costo ............................................................................ 258 5.1.5. Los procesos en la gestión de la calidad ...................................................................... 261 5.1.6. Los procesos en la gestión de los recursos humanos .................................................. 264 5.1.7. Los procesos en la gestión de la comunicación ........................................................... 267 5.1.8. Los procesos en la gestión de los riesgos ..................................................................... 269 5.1.9. Los procesos en la gestión de las adquisiciones .......................................................... 272 5.1.10. Los procesos en la gestión de los interesados ........................................................... 275 5.2.
ANEXO B: Los procesos de ISO 21.500:2.012 ............................................................. 278
5.2.1. Los procesos de inicio .................................................................................................. 278 5.2.2. Los procesos de planificación ...................................................................................... 279 5.2.3. Los procesos de implementación ................................................................................ 280 5.2.4. Los procesos de control ............................................................................................... 281 5.2.5. Los procesos de cierre.................................................................................................. 282 5.3.
ANEXO C: Los procesos de PRINCE2®. ....................................................................... 283
5.3.1. Puesta en marcha SU ................................................................................................... 286 5.3.2. Dirección de un proyecto DP ....................................................................................... 286 5.3.3. Inicio IP ......................................................................................................................... 287 5.3.4. Control de fase CS ........................................................................................................ 287 5.3.5. Entrega de productos PD ............................................................................................. 288 5.3.6. Límites de fase SB ........................................................................................................ 289 viii
5.3.7. Cierre de proyecto CP .................................................................................................. 289 6.
Parte 6: apéndices ....................................................................................................................................... 291
ix
6.1.
Referencias bibliográficas ......................................................................................... 291
6.2.
Índice de Figuras ....................................................................................................... 298
6.3.
Índice de Tablas ........................................................................................................ 301
6.4.
Lista de Acrónimos ................................................................................................... 302
Parte I – Aspectos preliminares
1.
Parte 1: Aspectos Preliminares
1.1.
Introducción
En este capítulo se ofrece una visión global de los aspectos tratados en esta tesis. En primer lugar, en la sección 1.1.1 se expone una breve descripción de la motivación de la misma. Una vez plantada la necesidad e interés del desarrollo de la tesis, se exponen los aspectos más relevantes de la misma, de forma que sea contextualizada en el entorno de la gestión de proyectos. Así, en la sección 1.1.2 se viene a explicar el marco actual de complejidad existente en la gestión de proyectos y sus implicaciones en el mundo empresarial. Seguidamente, en la sección 1.1.3, se explica la importancia que a nuestro juicio tiene la estandarización y el uso de procesos a la hora de desarrollar proyectos y que estos procesos sirvan como base de conocimiento tanto de las organizaciones como de los profesionales especializados en la gestión de proyectos. Este análisis previo servirá como base para justificar la conveniencia del desarrollo de esta tesis doctoral. 1.1.1.
Motivación
Podemos encontrar proyectos en todas partes [1] y en todos los sectores [2]. Los proyectos se han planificado y desarrollado desde el inicio de la humanidad, de forma que los resultados que se han conseguido, han servido para resolver las necesidades y problemáticas que en cada momento existían [3, 4]. Evidentemente en la actualidad también se siguen desarrollando proyectos aunque las necesidades han evolucionado. En concreto, la mayor diferencia que podríamos encontrar es que actualmente los recursos necesarios para desarrollar un proyecto (tiempo, recursos materiales, dinero, etc.) son escasos y su uso eficiente es fundamental para la viabilidad de los mismos. Así, para poder conseguir alcanzar un uso óptimo de los recursos y maximizarlos, un enfoque adecuado es el de observar y analizar cuáles con las buenas y mejores prácticas en los proyectos ya terminados y usar este conocimiento para los siguientes. De esta forma, esta compilación de conocimientos, podrá servir para evitar que se vuelvan a repetir los mismos errores. Estamos hablando del concepto lecciones aprendidas siendo ésta una de las motivaciones clave de la realización de esta tesis. Así, para asegurarse de que estas lecciones aprendidas sean aplicadas de forma correcta, es fundamental establecer metodologías y procedimientos que las identifiquen y las concreten en acciones concretas aprovechables [5]. Es interesante conocer la opinión que tienen los promotores o usuarios del resultado de un proyecto. La Universidad de Manchester a través de eGovernment for Developmet ha realizado un estudio en el que indica que tan sólo el 15% de los proyectos son considerados como exitosos por sus promotores [6], y así se aprecia en la Figura 1, siendo la definición de éxito : “los principales stakeholders (o agentes que pueden ser afectados por el proyecto) del proyecto dicen que se han logrado los principales objetivos y no has experimentado resultados no deseados significativos”.
Figura 1: Motivo de éxito y fracaso de los proyectos según eGovernment for development.
De hecho, la consultora holandesa KPGM, realizó un estudio a más de 100 clientes de la construcción, afirmando que únicamente el 55% de la inversión en proyectos, es considerada exitosa por sus patrocinadores. Según datos obtenidos del informe en el año 2.015, sólo el 31% de los proyectos fueron entregados de acuerdo al presupuesto fijado y sólo el 25% concluyeron a tiempo, frente al 33% y 29% en 2.012; o el 48% y 36% respectivamente de 2.010 [7]. Esto no quiere decir que no se completaran los proyectos, sino que sus resultados y/o el modo en cómo se ejecutaron, 11
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
no coincidieron con las expectativas iniciales, si bien se aprecia un empeoramiento paulatino y constante de los resultados. Otros datos:
The Standish Group, organización que lleva publicando desde 1.994 estudios sobre la industria de desarrollo de software, ha realizado en 2.015 un nuevo informe en el que se concluye que sólo el 29% de los proyectos de IT tuvieron éxito, tal y como se explica en la figura siguiente. Este informe se denomina “Chaos Report”. Definen éxito como la consecución del proyecto a tiempo, según el coste estimado y logrando un resultado satisfactorio [8]. Es interesante indicar que dentro de las causas del éxito del proyecto se incluye el conocimiento, habilidades y técnicas de gestión de proyectos.
Figura 2: Motivo de éxito y fracaso de los proyectos según Standishgroup.
Robert Cooper, expone que más del 46% de los recursos totales invertidos, lo han sido en proyectos cancelados o que no alcanzaron sus objetivos [9]. En 1.995, la encuesta OASIG sitúa la tasa de éxito entre el 20% y 30%; la encuesta KPMG Canadá, realizada en 1997, encontró que el 61% de los proyectos fracasaron; la encuesta Conference Board de 2.001 muestra que el 40% de los proyectos no cumplen con las expectativas de negocio después de un año desde el inicio de las operaciones [10]. Según Pablo Almunia [11]: “En 2.009, poco menos del 25% de los proyectos no terminan, es decir, son cancelados y todos los esfuerzos realizados son dados como pérdida para la empresa (sin contar el costo de oportunidad que estas cancelaciones pueden suponer). Más del 40% de los proyectos no han cumplido con los plazos, costo o alcance. Sólo el 32% de los proyectos terminan dentro de unos márgenes razonables de éxito.”
Como podemos observar, todos los informes y encuestas coinciden en el bajo rendimiento de los proyectos en lo que al éxito de los mismos se refiere. Muchas pueden ser la razones del fracaso. Según los datos aparecidos en el informe de 2.015 de PMI denominado PMI´s 2.015 Pulse of the Profession [12] se indica que las tres primeras causas del fracaso de los proyectos ‐según los propios practicantes de proyectos‐ son: 40% por cambios en las prioridades de la organización, el 38% por una inadecuada recopilación de requisitos y un 35% por cambios de los objetivos del proyecto. Según la OBS Online Business School [13] las principales causas en el fracaso de los proyectos son:
Insuficiente gestión del riesgo. Pobre definición del alcance del proyecto. Falta de realismo en el establecimiento de metas. Falta de margen de reacción. Fallos en la comunicación.
Las facetas del éxito de un proyecto Todos estos informes enumerados anteriormente, nos hacen reflexionar sobre el concepto de éxito del proyecto. De hecho, se han realizado investigaciones sobre los factores que contribuyen al éxito [14] y no depende únicamente de un solo aspecto, sino que para que un promotor o cliente pueda afirmar que su proyecto ha sido exitoso, debe satisfacer, en general, a todos los afectados por el mismo. Si bien sin una adecuada definición de éxito del proyecto, 12
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
el desempeño de una organización no puede ser valorada [15, 16]. Tradicionalmente se ha pensado que el mero hecho de cumplir objetivos económicos era suficiente, pero la experiencia ha demostrado que no es así. Muchos autores coinciden en que el éxito de un proyecto no es sólo el logro de un aspecto concreto del mismo ‐usualmente el económico‐ sino que consiste en alcanzar un conjunto de resultados positivos para todos los agentes intervinientes (o el mayor número posible) o afectados por el mismo(stakeholders). [17]. Steiner [18] definía el concepto de éxito como el cumplimiento de las restricciones de costo, cronograma o tiempo y desempeño –triángulo de acero o triple restricción‐ [19]. Este concepto se ha venido manteniendo como un estándar para su valoración, pero se analiza desde el punto de vista empresarial. Para ello, se pueden definir cinco áreas, sobre las que dependiendo del resultado final de un proyecto, analizar su éxito. Así, se puede pensar que lo alcanzamos cuando se han cumplido con los objetivos de coste, tiempo y se ha realizado el trabajo previsto, pero en realidad (desde el punto de vista de la organización propietaria y del cliente), no sean éstos todos los criterios a tener en cuenta y podría ser interesante valorar otras dimensiones tales como las que señala la US. Agency for International Development, luego Naciones Unidas y la UECD: [20], a saber:
Eficiencia: en lo relativo al cumplimiento de los plazos, presupuesto, uso de recursos, etc. Impacto en el cliente: si el producto del proyecto obtenido cumple sus necesidades reales. Impacto en el equipo: conseguir que el equipo crezca, se sienta involucrado y valorado y aumente sus competencias es la mejor forma de mantener el talento en la organización. Consecución de la rentabilidad económica deseada. Preparación para el futuro: lo que se aprende en cada proyecto sirve para hacer más eficiente el siguiente o si se han desarrollado tecnologías o procesos innovadores, se estará mejor posicionado en el mercado.
Todas estas dimensiones son importantes cuando la organización está pensando en crear una relación duradera con sus clientes y no en una actuación especulativa. De hecho, si ponemos estos conceptos en una gráfica (Figura 3), podemos apreciar de forma intuitiva como el proyecto A, que ha conseguido buenos resultados económicos, ha obtenido otros muy pobres en otras áreas claves de la empresa, lo que podría afectar negativamente a sus proyectos futuros, tanto desde el punto de vista de resultados comerciales, como en la eficiencia interna de sus procesos. En cambio, en el proyecto B, con menores resultados económicos, el balance del resto de áreas es mucho más homogéneo y positivo, lo que, en principio, posibilitaría una mejora en el funcionamiento de la Compañía. Proyecto A
Proyecto B
Figura 3: Comparativa del éxito de un proyecto.
Respecto a este concepto, es importante resaltar, que el éxito de un proyecto se alcanzará cuando se logren sus objetivos y, sobre todo, la satisfacción de los agentes involucrados en el mismo. Para lo cual, el director del proyecto, deberá balancear dichos intereses desde un punto de vista global e integrador. Por lo que una definición sencilla y clara de éxito de proyecto no es posible [21]. Así, otro aspecto importante a tener en cuenta es que los proyectos deben estar alineados con la estrategia de la organización, pues, para una empresa, sus proyectos son los medios a través de los cuales obtiene sus beneficios. Este aspecto se puede observar en el siguiente esquema generado a partir de lo expuesto de la norma ISO 21.500:2.012 en su punto 3.4.1 sobre estrategia de la organización [22].
13
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Figura 4: Proyectos vs estrategia de la organización.
Por lo que incluso se puede afirmar que los proyectos, nacen de la detección de oportunidades. [23] De forma que los proyectos que se emprendan sin cumplir este requisito, tienen muchas más posibilidades de no recibir el apoyo necesario y, por tanto, su riesgo de fracaso es superior. Las compañía suelen determinar su estrategia global en un documento denominado plan estratégico. En este documento se sintetiza a nivel económico‐financiero, estratégico y organizativo el posicionamiento actual y futuro de la empresa [24]. Este plan estratégico debe revisar todas las áreas de la empresa ‐incluidas en estos tres niveles‐ y además, debe someterlas a examen. Además de ello debe determinar la estrategia a seguir en lo que concierne a las variables que ‐como empresa‐ puedan ser controladas, además de predecir la evolución de las variables externas que afectan inevitablemente a la evolución de la empresa. La estrategia es básica para las organizaciones y, de hecho, hace que sus decisiones estén enmarcadas en un marco definido. Stephen Covey decía que para un velero sin rumbo, cualquier viento en favorable [25]. Lo que implica no ser capaces de discernir qué oportunidades son las que van a llevar a la organización a conseguir sus metas de alto nivel. M. Treacy y F. Wiersema [26] opinan que para que una empresa pueda tener éxito, debe definir para los clientes utilidades únicas y que nadie más ofrezca en un determinado mercado. En la economía actual existen incontables posibilidades de ser diferente. Según B.D. Henderson [27]. “Lo que diferencia a los competidores puede ser el precio, la forma de venta, la posibilidad de suministro, o la cercanía geográfica. Puesto que las empresas pueden combinar estos factores de forma múltiple, existen numerosas posibilidades para cada una de ellas de mejorar su propia ventaja, ampliando aquello que la haga destacar especialmente frente a sus competidores”. Para clarificar esta cuestión, podemos analizar otras definiciones de estrategia por diversos autores:
“La definición de las metas y objetivos a largo plazo de una empresa, la adopción de acciones y la asignación de los recursos necesarios para la consecución de estos objetivos” [28]. “Una estrategia es el modelo o plan que integra los principales objetivos, políticas y sucesión de acciones de una organización en un todo coherente. Una estrategia bien formulada ayuda a ordenar y asignar los recursos de una organización de una forma singular y viable, basada en sus capacidades y carencias internas relativas, en la anticipación a los cambios del entorno y en las eventuales maniobras de los adversarios inteligentes”. J.B. Quinn [29]. “Estrategia es una búsqueda deliberada de un plan de acción que cree y desarrolle una ventaja competitiva de la empresa. Para cualquier empresa, la búsqueda es un proceso iterativo que comienza con el reconocimiento de donde está y qué tiene ahora. Sus competidores más peligrosos son los que más se le parecen. Las diferencias entre la empresa y sus competidores son el fundamento de su ventaja. Si tenéis empresas y son viables, ya tenéis alguna clase de ventaja, no importa cuán pequeña o sutil. El objetivo es agrandar el alcance de su ventaja, lo que sólo puede conseguirse a costa de otro”. B.D. Henderson [27].
En él, por tanto, se definen tanto los aspectos más intangibles de la misma (misión, visión, valores) como los más concretos (objetivos y estrategias), que deben ser adoptados para conseguirlos, tanto a corto, medio o largo plazo. Suelen tener un horizonte temporal a medio plazo, entre 3 y 7 años, si bien deben ser revisados frecuentemente para asegurar que los objetivos corporativos son correctos y están alineados con las necesidades del mercado al que se orienta la compañía. En el plan estratégico, se definen a grandes rasgos cómo van a ser las inversiones de la empresa y los criterios de priorización de recursos. Esto, unido a que se deben revisar y ajustar sus objetivos y estrategias periódicamente, hace que el Plan Estratégico sea el principal generador de cambios de los portfolios o programas, ya que éstos se deben adaptar a los eventuales nuevos requerimientos. Un caso de estudio En la edición de noviembre de 2.016 de PM Network Magazine publicado por PMI®, Terry Williams PMP®, el decano de la Hull University Business School en el Reino Unido, exponía los resultados de su estudio sobre los factores que habían llevado al grupo inglés Sewell Group ‐cuya área de negocio se basa en los sectores de sanidad y educación‐ a ser reconocido como una organización que desarrolla proyectos de forma excelente [30]. Terry Willliams no sólo analizó los factores típicos que comentamos al inicio del artículo, sino que se focalizó en otros parámetros como la satisfacción del cliente, el uso y la implicación de la comunidad así como la empatía [31]. 14
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
De su estudio se identificaron 6 factores de éxito de la organización, que a continuación se señalan:
Cultura de empresa: Observó que Sewell Group, apostaba por desarrollar las habilidades directivas entre todo su equipo aplicando una estructura organizativa horizontal orientada al cumplimiento de objetivos. Equipo de proyecto: Tiene un enfoque basado en la composición de equipos concretos para cada proyecto, de espíritu colaborativo e intentando involucrar a los agentes afectados por el proyecto, desde usuarios hasta proveedores. Arranque cuidadoso del proyecto: Basándose en una identificación temprana de los stakeholders, de forma que se puedan analizar sus requisitos e integrarlos en el proyecto de la forma más inmediata posible. Esto reduce los problemas futuros, aumenta las posibilidades de que el producto final sea el deseado e incluso reduce los cambios futuros. Satisfacción del cliente: A través de la comunicación continua con el cliente a lo largo de todo el proyecto y del entendimiento de sus necesidades. En este punto la empatía es una de las habilidades clave a tener en cuenta. Proveedores: Realizan un gran esfuerzo en la relaciones con los proveedores; no sólo intentan conseguir el mejor precio sino que la calidad es factor clave. Para conseguirlo intentan involucrarlos y crear una cultura de win‐win, es decir, beneficio mutuo entre las partes. Gestión de postventa: No sólo es importante terminar un proyecto, sino también dar una buena respuesta a posible problemas que los usuarios puedan tener. De hecho, el no hacerlo así, es una de las principales causas por las que un cliente abandona la empresa.
Concluyendo ‐después del análisis de este caso de éxito‐ que la aplicación de las lecciones aprendidas está siendo reconocida cada vez más como un elemento de gran importancia a la hora de mejorar la aplicación de las prácticas en gestión de proyectos [32]. Si bien manifiesta que es difícil discernir e identificar con exactitud las causas tanto del éxito como del fracaso del mismo, y ello, incluso, en un proyecto individual [33]. En cualquier caso, la suma de múltiples buenas prácticas y aplicación de principios, además del contexto en el que se desarrollan los proyectos, hacen que se genere una tormenta perfecta, del que fundamentalmente se beneficiarán sus clientes y usuarios [31]. El conocimiento de la gestión de proyectos De lo expuesto anteriormente, han surgido diferentes asociaciones y organismos que tienen como objetivo fundamental el aunar el conocimiento existente y las buenas prácticas en gestión de proyectos y ponerlas a disposición de los profesionales, de forma tal que las experiencias y lecciones que se detectan en cada proyecto puedan estar a disposición de quien necesite desarrollar un proyecto y así aumentar la eficiencia del mismo y aumentar la probabilidad de alcanzar el éxito del mismo. La más representativa a nivel internacional es la asociación estadounidense PMI® (Project Management Institute). A lo largo de esta tesis se ampliará información sobre ella, pero en este punto interesa resaltar que dentro de sus actividades está la de identificar cuál es el nivel de implementación de la gestión de proyectos en los profesionales y en las empresas. De hecho, en su encuesta de 2.016: Pulse of the profession; 8th Global Management Survey, realizada a 2.428 profesionales en gestión de proyectos, 192 directivos y 281 directores de oficinas de proyectos, indica la evolución de su percepción sobre aspectos clave en el resultado y el éxito de los proyectos en el tiempo y en concreto desde el 2.012 [12].
15
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Figura 5: Aspectos clave en el resultado y el éxito de los proyectos.
Como se puede apreciar en la Figura 5, el cumplimiento de los objetivos originales a alcanzar por los proyectos ha empeorado, tanto en la finalización en tiempo, como en el cumplimiento del presupuesto de los mismos. De hecho, afirma que por cada cien mil millones de dólares invertidos se llegan a perder hasta 122 millones, y esto es debido a un pobre rendimiento del proyecto. Así, analizando los resultados de la aplicación de una gestión integrada de proyectos basada en metodologías probadas, también se llega a la conclusión, que el 71% de los proyectos alcanzan a cumplir sus objetivos cuando la cultura de gestión de proyectos en la organización es una prioridad, en contra del 52% en las que no lo es. De la misma manera, se concluye que los proyectos en los que se aplican las buenas prácticas en gestión de proyectos mejoran en 2.5 veces (89%) a los que no la emplean (34%). Como afirma Bill Seliger “Sin ninguna duda, las buenas prácticas en gestión de proyectos hacen alcanzar un mayor éxito, reducen los riesgos y aumentan las posibilidades de alcanzar los objetivos del valor económico del proyecto”. En la Figura 6 se puede apreciar con mayor detalle lo expuesto.
Figura 6: Repercusión de la adopción de buenas prácticas en los proyectos.
En este mismo documento, y en línea con lo expuesto, es de interés conocer la opinión de Sudhakar Kesavan, Director General de ICF International, Inc, que indica que “Cuanta mayor pericia se disponga, menores son las posibilidades de tener complicaciones con el cliente, sufrir sobre costes y problemas con el presupuesto”. Respecto a la percepción sobre el resultado de los proyectos, en esta encuesta, los preguntados manifiestan que tan sólo el 62% de sus proyectos han cumplido los objetivos iniciales. En la siguiente figura se pueden ver con detalle las causas de los posibles fracasos de los proyectos que esta encuesta arroja, Figura 7:
16
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
Figura 7: Causas de los fracasos de los proyectos.
Esto lleva pensar que dentro de la propia gestión de un proyecto, se deben incorporar los procesos que permitan detectar si en la planificación y/o en el desarrollo posterior del proyecto, éste sigue alineado con los objetivos primarios para los que se ha ideado. Esto se puede conseguir estableciendo predictibilidad en la gestión a través de la definición de metodologías probadas y basadas en experiencias previas. Esta percepción de la necesidad o no del uso de metodologías de gestión de proyectos también la podemos ver en los resultados de otra encuesta realizada a 1.524 participantes de 38 países y 34 industrias distintas, en este caso generada por PWC (PriceWaterhouseCoopers) [34]. En este interesante documento se llegan a conclusiones relevantes relativas a la conveniencia de la justificación de esta tesis tales como:
El 97% de los participantes coincidieron en que la gestión de proyectos es crítica para el rendimiento de sus negocios y para el éxito de sus organizaciones. El 94% indican que la gestión de proyectos permite el crecimiento de sus negocios.
Además, los participantes exponían las motivaciones por las que consideraban oportuno usar técnicas de dirección de proyectos y, como vemos, el 40% indicaban que era por imperativo de la propia empresa o de su negocio, lo que nos da a entender la visión que pueden aportar beneficios al propio desarrollo del negocio.
Figura 8: Motivo para el establecimiento de gestión por proyectos en las organizaciones. Fuente: PWC.
De igual forma, se les preguntaba cuál era la metodología que usaban y la gran mayoría, un 41%, afirmaron usar metodologías basadas en el PMBOK® (Project Management Body of Knowledge) [35] que es la guía de las buenas prácticas que el PMI® desarrolla y sobre las que se basa el desarrollo de esta tesis.
17
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Figura 9: Relación de las metodologías en gestión por proyectos utilizadas por las organizaciones. Fuente: PWC.
1.1.2.
La complejidad en la gestión de proyectos
Tal y como se ha evidenciado en el punto anterior, gestionar proyectos no es tarea fácil y resulta ser un tema de interés general, máxime cuando se pueden desarrollar en todos los sectores productivos. De hecho la principal característica que podría definir a un proyecto es que produce algo único. Este hecho es fundamental para comprender la complejidad en el desarrollo de un proyecto, ya que como la propia definición indica es algo que no se ha realizado nunca, al menos en las condiciones en las que se producirá y esto es así porque se desarrollará en el futuro y, por tanto, en un marco de incertidumbre. Cuanto mayor sea la incertidumbre, mayor será el riesgo de que el proyecto no alcance a cubrir las necesidades por las que se crea, y, por tanto, debemos idear mecanismos que reduzcan en lo posible el impacto del riesgo en el proyecto y aumente la predictibilidad tanto de las acciones como de los productos a conseguir [36, 37]. Los proyectos los podemos clasificar dependiendo de su:
Grado de complejidad. Urgencia. Importancia para la organización. Nivel de riesgo o incertidumbre. Cantidad de beneficios que genera en la organización. Tipo de cambio que producen en la organización. Tamaño. Recursos que consumen.
En el PMBOK® se define un proyecto como un esfuerzo temporal emprendido para crear un único producto, servicio o resultado. Por tanto, un proyecto se desarrolla para conseguir resolver una necesidad o requisito, bien sea de la propia organización, de un cliente concreto o de la sociedad [35]. Lo que significa que obliga a realizar un esfuerzo temporal: se desarrolla en un momento determinado, tiene un inicio y tendrá un final. De forma que incluso el equipo de proyecto se compone para su desarrollo y se disuelve cuando termina. No significa que tenga una duración corta, sino que está delimitada. Así, el proyecto termina cuando o bien se alcanzan los objetivos establecidos o cuando se decide que no se podrán alcanzar los objetivos o, incluso, desaparece la necesidad por la que se puso en marcha. Además, genera un resultado tangible: si bien ‐por la propia naturaleza de los proyectos‐ puede existir cierta incertidumbre acerca de los resultados que se conseguirán al finalizar el mismo, ya que se desarrollan en un ambiente de riesgo sobre los resultados a conseguir, si bien puede ser éste un producto. Incluso, puede ser parte de un producto mayor, un servicio o la capacidad para desarrollarlo o un documento (investigación, informe, etc.). Se puede asimismo afirmar que tiene un ciclo vital: Se va desarrollando por fases y conforme estas avanzan, mayor es el detalle del mismo. De forma que el equipo de proyecto debe controlar continuamente que el alcance del proyecto coincide con los requerimientos del mismo. Y para poder conseguir que el proyecto contenga todas estas características, debe gestionar diferentes y diversos recursos de diferentes áreas funcionales internos o externos a la propia organización. Proyectos vs Operaciones A veces es difícil diferenciar entre proyectos y operaciones, si bien sus objetivos y características son distintos; las operaciones conllevan un esfuerzo y realización de tareas de forma repetitiva, bajo los procedimientos desarrollados por la empresa, y no finalizan hasta que la empresa lo decide por las razones que considere [35]. Por ejemplo, la producción de un automóvil concreto, se desarrolla mediante operaciones, y los productos que se producen son 18
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
repetitivos. Si bien, el diseño del coche, la construcción de la planta de producción, el diseño de la cadena, etc., sí serían proyectos, con un inicio, un fin, un presupuesto, unos objetivos concretos y con un presupuesto determinado. Si ya es complicada la gestión propia del proyecto, ésta se complica aún más cuando se analiza la importancia que tienen los diferentes agentes en el éxito del mismo. De forma que no sólo es suficiente ‐ tal y como se ha indicado anteriormente‐ con desarrollar el producto pretendido del proyecto, sino que éste debe ser tal que satisfaga las necesidades y requisitos del cliente y de los principales interesados del proyecto. Esto requiere un nivel de esfuerzo elevado por parte del equipo de proyecto a la hora de identificar a los propios interesados y de poder obtener su requisitos de forma que se puedan gestionar y eventualmente incorporar en el plan de desarrollo del proyecto para finalmente queden incorporados en el propio producto final. 1.1.3.
La importancia de la estandarización
Las bondades del uso de metodologías que permitan estandarizar las actividades de los proyectos han quedado patentes en los puntos anteriores. La gestión por proyectos es una gestión por procesos, y, se concluye asimismo dicho extremo al comprobar que en la guía PMBOK® se describen 47 procesos, los cuales abarcan las actividades fundamentales del proyecto [35]. Disponer de procesos disminuye el riesgo en el proyecto y aumenta su predictibilidad, a la vez que permite aprovechar el conocimiento que se adquiere cada vez que la organización o el profesional desarrolla un proyecto, al actualizarse los mismos. Del trabajo publicado por Frederick Winslow Taylor [38, 39] se evidencia que la base es la mejora continua, y se materializa en el ciclo PDCA (plan, do, check, act), en base al cual se viene a manifestar que es la propia experiencia y la resolución de posibles problemas o crisis anteriores en los proyectos los que ayudan a mejorarlos. Un referente fundamental a la hora de determinar la conveniencia o no de estandarizar los procesos, es la familia de las normas ISO 9.000. De hecho en 1.928 en Nueva York se fundó la ISA: International Federation of the National Standarizing Assocciation. Ésta se basaba en el sistema métrico y su finalidad era la de solventar las áreas que no se trataban en la electrotecnia ‐que ya era regulada por la ICE (International Electrotechnical Commission) de 1.906. Después de la Segunda Guerra Mundial, en 1.944 se conformó la UNSCC (United Nations Standards Coordinating Commitee), cuyos delegados (un año más tarde junto con la ISA y empujados por quien se considera el padre de la estandarización Charles Le Maistre) fundaron la ISO con el objetivo de crear un único organismo dedicado a la normalización. De hecho, fue en 1.947 cuando se formalizó la misma, siendo el 27 de febrero cuando comenzaron sus actividades [40]. Volviendo a la serie de normas ISO 9.000, fue después de la Segunda Guerra Mundial cuando se constató en el Reino Unido la necesidad de estandarizar procesos y redactar normas que permitiesen establecer controles e inspecciones sobre los productos, lo que aumentó la calidad. En estos momentos se aplicó el Principio de Pareto por el cual Vilfredo Pareto establecía que el 80% de los resultados se consiguen con el 20% de la aportación y control estadístico propuesto por Walter Shewart [41]. De hecho, en Estados Unidos se desarrolló en el sector militar ‐en los años cincuenta‐ un esquema de requerimientos denominado Quality Program Requirements así como la NASA también desarrolló modelos de inspección focalizados en la calidad, los cuales llevaron a definir los criterios de aseguramiento de cara a sus proveedores. Más adelante, en 1.987, la norma BS 5.750 ‐creada para controlar los resultados de los productos‐ se transformará en la que conocemos como ISO 9.000, con la finalidad de facilitar el comercio global. A partir de entonces, la norma ha ido evolucionando, haciéndose más atractiva a las empresas [42]. Hoy en día ISO (International Standarizing Organization) es, como se indica en su página web, una organización independiente, no gubernamental con 161 cuerpos de estándares. Ha publicado más de 21.000 estándares internacionales y documentos relacionados, abarcando casi todas las industrias, desde tecnología a seguridad alimentaria pasando por agricultura y sanidad [40]. Para comprender la importancia de esta organización a nivel mundial, se extracta el dato de que en 2.014, 1.609.294 certificados fueron gestionados por ISO lo que supuso un ligero incremento respecto al año anterior [43]. ISO 9.001:2.015 La familia de normas 9.000 desarrolla diversos aspectos de la gestión de la calidad y establece unos criterios para un sistema de calidad. Se basa en unos principios de calidad focalizados en la satisfacción del cliente, la implicación de la dirección y la mejora continua. Estos principios son siete, a saber: [44]
19
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Focalización en el cliente: El objetivo de la gestión de calidad es el cumplimiento de los requisitos del cliente y superar sus expectativas. Liderazgo: Se establece en todos los niveles una unidad de propósito y dirección. Se crean las condiciones en las que los trabajadores son involucrados y se les motiva para conseguir los objetivos de calidad de la organización. Implicación: Aumentar la competencia, dar más poder de decisión y acción e involucrar a los trabajadores en todos los niveles, es esencial para aumentar su capacidad para crear y entregar valor. Uso de procesos: Resultados consistentes y predecibles se consiguen de forma más efectiva y eficiente cuando las actividades son entendidas y gestionadas como procesos interrelacionados que funcionan como un sistema coherente. Mejora: Las organizaciones exitosas están focalizadas en la mejora continua. Toma de decisiones tomadas sobre evidencias: Las decisiones tomadas sobre la base del análisis y la evaluación de datos e información son más probables que produzcan los resultados deseados. Gestión de las relaciones entre los agentes: Para mantener un éxito sostenido, las organizaciones tienen que gestionar las relaciones con el resto de agentes intervinientes o afectados (stakeholders). Las empresas pueden certificarse y en la familia de las normas ISO 9.000 se incluyen las siguientes normas:
ISO 9.001:2.015 – Requisitos de un sistema de calidad. ISO 9.000:2.015 – Conceptos básico y lenguaje. ISO 9.004:2.009 – Focalizado en cómo hacer el sistema de calidad más eficiente y eficaz. ISO 19.011:2.011 – Serie de guías para realizar las auditorías internas o externas a los sistemas de calidad.
Figura 10: Implementación de las normas ISO 9.001 en por países.
Estandarización en la gestión de proyectos En lo relativo a la gestión de proyectos, la estandarización de los procesos y del conocimiento se ha materializado fundamentalmente en la creación de cuerpos de conocimiento y de métodos que intentan aprovechar las lecciones aprendidas para realizar un compendio consensuado de las mismas que sirvan como guía para el desarrollo de futuros proyectos. A nivel internacional hemos visto en la sección 1.1.1 como las buenas prácticas identificadas y descritas por PMI® en el PMBOK® son las más reconocidas y utilizadas [35]. En este cuerpo de conocimiento se establecen los procesos a utilizar para gestionar un proyecto, independientemente de su tamaño y complejidad, ya que para ello se hace necesario seleccionar cuáles de ellos son los más adecuados en cada caso. Dichos procesos se estructuran en diez áreas de conocimiento, a saber, la integración, el alcance, el tiempo, el coste, la calidad, los recursos humanos, la comunicación, los riesgos, las adquisiciones y los interesados. Y a su vez, éstos se dividen en cinco grupos de procesos que se desarrollan a lo largo de todo el ciclo de vida del mismo y que se denominan: inicio, planificación, ejecución, control y cierre. A partir de estas buenas prácticas generadas de la experiencia, para un proyecto concreto, su director deberá seleccionar dependiendo del nivel de control deseado, qué procesos serán usados y el nivel de implementación, de forma que se diseñe un modelo de gestión particular e individualizado para cada proyecto [45]. 20
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
Si los proyectos se desarrollan en el entorno de una organización o de un programa, es factible pensar que éstos deberán seguir unas directrices o bases establecidas previamente por la misma, de forma que todos se gestionen de forma análoga y siguiendo unos procesos concretos, eso sí basados en las buenas prácticas. Esto sin duda aumenta la eficiencia del esfuerzo y la productividad, disminuyendo ‐como indicábamos anteriormente‐ la incertidumbre en la gestión y permitiendo su mejora continua. Así, muchas organizaciones han desarrollado su metodologías concretas. Para esta tesis es de gran interés el método PRINCE2® (Projects In Controlled Environments), que estableció la Oficina Gubernamental de Comercio del Reino Unido [46]. Así, en PRINCE2® se concretan las buenas prácticas identificadas en un cuerpo de conocimiento y en un método particularizado y de aplicación a todo tipo de proyectos, ya que permite su adaptación, pero teniendo en cuenta que para poder afirmar que un proyecto se está desarrollando bajo la metodología de PRINCE2®, se deben seguir todos sus preceptos. Así, en PRINCE2® se identifica un enfoque basado en procesos, al igual que en PMBOK®, si bien éste realizado desde otro punto de vista; su gestión se basa en el uso obligatorio y de aplicación de los denominados principios, como son: la justificación comercial continua, aprender de la experiencia, roles y responsabilidades definidos, gestión por fases, gestión por excepción, enfoque en los productos y adaptación para corresponder al entorno del proyecto. Además de estos principios, y basados en ellos, también define siete temas que se aplican a lo largo del proyecto y que se deben estudiar de forma más o menos detallada dependiendo de la importancia y complejidad del mismo, a saber: business case (viabilidad), organización, calidad, planes, riesgo, cambio y progreso. Tanto los principios como los temas se van a aplicar en el proyecto en los diferentes procesos que se definen en PRINCE2®. Éstos se distribuyen en las fases del proyecto. Por ejemplo, en la fase de pre‐proyecto podemos encontrar el proceso denominado SU (starting up a project) puesta en marcha de un proyecto, donde se recopila la información necesaria para tomar la decisión de lanzar un proyecto. De hecho, las decisiones que se toman a nivel directivo y que son de relevancia para el proyecto, se hacen en el proceso DP (directing a project) dirección de un proyecto. Este proceso comienza en SU y se alarga hasta la propia finalización del mismo. El director de proyecto también participa en otros procesos como son IP (initate a project) inicio de un proyecto, donde se planifica en detalle para que el proyecto pueda autorizarse y comenzar su ejecución, CS (control a stage) control de una fase, en el que el director del proyecto realiza su trabajo del día a día y va autorizando el mismo, SB (stage boundary) límite de fase, por el cual se autoriza el proyecto por fases y CP (closing a project) cierre de un proyecto, para preparar el cierre del proyecto. También se define el PD (product delivery) denominado gestión de la entrega de productos y en el que se desarrolla el trabajo especializado del proyecto, realizado por los especialistas o team managers. El cuarto aspecto a tener en cuenta en la gestión de un proyecto bajo metodología PRINCE2®, es la adaptación del método al entorno del proyecto concreto de forma que se garantice una gestión adecuada y mesurada, valorando tanto el nivel de control deseado como las capacidades de la organización y del esfuerzo necesario para ello en base al beneficio esperado. Además de las descritas y de las que más adelante se expondrán en esta tesis, existen más organismos y asociaciones que han desarrollado cuerpos de conocimientos y metodologías, si bien ninguno tiene la relevancia de los expuestos anteriormente. Consideración aparte tienen las metodologías ágiles, sobre las que realizaremos comentarios a lo largo de esta tesis. La tendencia a la hora de gestionar proyectos es doble, por un lado predictiva, basada en la planificación y orientada hacia la consecución de un producto o servicio determinado y por otro lado las ágiles que se desarrollan en entornos con un alto grado de incertidumbre y cambios. Además y debido a la preponderancia que tienen las normas ISO a nivel internacional en la gestión empresarial y en la definición de estándares a seguir, se ha considerado adecuado incluir en esta tesis a la norma ISO 21.500:2.012 desarrollada por el Comité del Proyecto ISO/PC 236 denominado “Dirección y gestión de proyectos” [22]. El enfoque de esta norma es similar al que podemos encontrar en el PMBOK®, de hecho se estructura en cinco grupos de procesos como son inicio, planificación, implementación, control y cierre y dispone de diez grupos de materias como son integración, parte interesada, alcance, recursos, tiempo, coste, riesgo, calidad, adquisiciones y comunicación. Análogamente al enfoque de PMBOK®, los 39 procesos que describe se van distribuyendo a lo largo de los grupos de procesos y de los grupos de materia. De hecho el interés de las organizaciones y empresas en implementar correctamente los procesos de gestión de proyectos, se materializa en el norma ISO 21.500:2.012 ya que como hemos indicado en puntos anteriores, es posible conseguir la certificación en las normas de la familia ISO 9.000, lo que sin duda aumenta la confianza tanto a sus clientes como a otros agentes clave, de que dichas organizaciones han implementado y disponen de unos sistemas adecuados de gestión y que además los siguen correctamente. Para completar los diferentes niveles de gestión, ISO también tiene intención de publicar una nueva norma que trata la gestión del portfolio de proyectos (ISO 21.504). Respecto a proyectos, actualmente es posible conseguir la certificación por parte de las empresas, pero no a nivel internacional, de hecho la norma ISO 21.500:2.012 no es un método sino una guía de buenas prácticas o recomendaciones básicas. Si bien en algunos países se están constituyendo comités técnicos de certificación con el objetivo de generar un estándar nacional certificable. En concreto en España AENOR (Asociación Española de 21
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Normalización y Certificación creada en 1989 y cuya actividad se basa en la normalización y certificación (N+C), también en mejorar la calidad en las empresas, sus productos y servicios, así como proteger el medio ambiente y con ello, el bienestar de la sociedad) [47], está poniendo en marcha un proyecto piloto con el objetivo de brindar la posibilidad a que las organizaciones alcancen a certificarse en la norma UNE‐ISO 21.500:2.012, en un ámbito nacional. La certificación puede ser en dos modalidades:
Certificación proyecto individual. Certificación cartera de proyectos.
A modo informativo se expone el proceso de certificación a seguir, Figura 11. Si bien hay que indicar que en estos momentos tan sólo una empresa certificada [48]. Respecto a este asunto hay que tener en cuenta que AENOR, según indica el Grupo de Seguimiento 21.500, no prevé certificar proyectos o portfolios como se ha indicado, sino procesos.
Figura 11: Proceso de certificación norma AENOR UNE ISO‐ 21.500.
OPM3 de PMI Este enfoque hacia las organizaciones también es tratado en PMI® y en PRINCE2®, desde el punto de vista de valorar cuál es el nivel de madurez de las mismas respecto a la implementación de modelos de gestión de proyecto. Así en PMI, se dispone de OPM3® (Organizational Project Management Maturity Model 3rd Edition) estándar en el que PMI describe una guía para la mejora de la gestión de proyectos en las organizaciones. Es una herramienta muy interesante para las empresas ya que tiene en cuenta e integra tanto el estándar de gestión de proyectos tratado en esta tesis como es el PMBOK® como el resto de estándares que establecen la gestión de proyectos a nivel superior; nivel programa descrito en el Estándar de Gestión de Programas 2ª edición, a nivel portfolio en el Estándar para la gestión del Portfolio 3ª edición, el Lexicon de términos de gestión de proyectos y el Marco de Desarrollo de las Competencias del Director de Proyecto o PMCDF (Project Manager Competency Development Framework) 2ª edición, como podemos encontrar en PMI® [49]. P3M3 de PRINCE2® Análogamente que en el caso de PMI®, para PRINCE2® también se dispone de una herramienta para valorar el nivel de madurez de las organizaciones en lo relativo a la implementación de sus sistemas de gestión de proyectos. En este caso se denomina P3M3: Portfolio, Programme and Project Management Maturity Model. De forma que se establecen diferentes niveles dependiendo del nivel conseguido. 1.1.4.
22
Justificación de la tesis
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
De lo expuesto en las secciones anteriores, se considera que es conveniente desarrollar un modelo de procesos que integren los tres puntos de vista más representativos en la gestión de proyectos predictiva [50, 51] como son PMBOK®, PRINCE2® e ISO 21.500:2.012. Esto es así, ya que PMBOK® describe las buenas prácticas, al igual que lo hace la ISO 21.500:2.012 si bien esta lo hace con unos matices, enfoque y procesos diferentes, en algunos casos y PRINCE2® diseña y fija de forma específica cuáles deben ser los procesos, los roles, así como la forma en la que se debe generar la información, etc. de una forma concreta y precisa, ya que es un método y por tanto prescriptivo. De forma que el enfoque que podemos ver en PRINCE2® y que se describe en su estándar “Éxito en la gestión de proyectos con PRINCE2®” [46] pueda ser incorporado a los procesos descritos como buenas prácticas en el PMBOK®. Es por ello, por lo que se viene a analizar en esta tesis que el diseño de un modelo de procesos que integre tanto los definidos en el PMBOK®, ISO 21.500:2.012 y PRINCE2® aportaría un gran beneficio a las organizaciones que desarrollen proyectos bajo el modelo PRINCE2® ya que de esta forma se asegurarían que se siguen las buenas prácticas más reconocidas como beneficiosas y que se describen en el PMBOK®. Asimismo, si una organización tiene un modelo de gestión de proyectos basado en PMBOK® también es de gran interés conseguir que éste esté homologado o contemple tanto los principios, los temas y los procesos de PRINCE2®. Estas dos situaciones aumentarían la eficiencia en la gestión de proyectos al permitir desarrollar proyectos con clientes, organizaciones y profesionales que contemplen los dos enfoques. De igual manera se considera que aumentaría las posibilidades de colaboración entre dichas organizaciones al no tener que rediseñar o añadir procesos nuevos a su funcionamiento normal ‐Business as usual‐ evitándose así incremento de la incertidumbre en la gestión, así como el riesgo que causearía el uso de nuevas formas de trabajo. Por todo ello, se mantendría a la organización ejecutante del proyecto en un entorno de gestión controlado. El hecho de que el modelo de gestión integrado propuesto sea homologable con ISO 21.500:2.012 permitiría a las organizaciones poder certificar sus procesos a esta norma, con el consiguiente beneficio respecto a la credibilidad externa . El hecho de que la organización pudiera prepararse para obtener una certificación de sus procesos en base a esta norma, aumentaría su eficiencia al cumplir con los requisitos completamente. En estos momento este hecho no contempla, pero cuando lo sea este proceso será más sencillo y directo. El hecho de escoger estos tres enfoques obedece a las siguientes razones, a saber: se elige el PMBOK® por ser el cuerpo de conocimiento de referencia en la aplicación de la gestión de proyectos tal y como se ha expuesto anteriormente así como lo demuestra el número de profesionales certificados PMP® (Project Management Professional) frente a otras opciones, Tabla 1.
PMP®
PRINCE2®
IPMA
Nº Certificados
714.491
≈ 400.000
≈ 250.000
Fecha del dato
29 Feb 2016 [52]
2010 [53]
2014 [54]
Tabla 1: Comparación del número de certificaciones profesionales.
Se escoge a PRINCE2® como el método de referencia en la gestión de proyectos al ser adoptado por múltiples organizaciones y organismos, tanto público como privados. No hay que olvidar que el marco de buenas prácticas el PMBOK® sirve como base para que las diferentes organizaciones desarrollen su propios procesos, en cambio PRINCE2® ya es un método en sí que se debe aplicar en tu totalidad (adaptándolo según el tipo de proyecto) y en el que se define con detalle la manera de gestionar los proyectos. Como ejemplo de organizaciones que adoptan PRINCE2® podemos nombrar las siguientes [55]:
Gobiernos: o Reino Unido, Australia, Holanda, Dinamarca, Canadá. o Ruanda, Nigeria, Tanzania. Sector privado: o Sun Microsistems, DHL, BAT, Barclays, Vodafone, Shell, Unilever, Rabobank. o Microsoft, HP, IBM, British Airways, Virgin, Safaricom. Organizaciones Internacionales: o ONU y sus agencias. o Banco Mundial. o ILO (International Labour Organization). 23
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
1.1.5.
Aportación de la tesis
De lo expuesto en la sección anterior 1.1.4, y a partir del análisis detallado de los tres enfoques de gestión de proyectos analizados en esta tesis, se propone diseñar un modelo integrado que sea capaz de aunar de forma homogénea tanto los procesos como los principios y los temas o áreas de conocimiento a aplicar en un proyecto. Así, la aportación principal de la tesis es la de generar un modelo de procesos que sirva como marco para el desarrollo de proyectos tanto bajo del punto de vista del PMBOK®, como PRINCE2® e ISO 21.500:2.012 . En concreto se han desarrollado 72 procesos nuevos de los cuales algunos son análogos a PMBOK® o a PRINCE2® o a ISO 21.500:2.012 . Y se han ordenado de forma cronológica (en términos de gestión). Al igual que ocurre en los anteriores, se han identificado en cada uno de los procesos las entradas y salidas más importantes, que son las que conducen a la obtención de los productos de gestión o del propio proyecto, las cuales serán generadas de forma independiente en cada proceso. Además se ha identificado la coincidencia o no de estos procesos según aparecen en cada enfoque frente al proceso integrado propuesto. De igual forma, se han redefinido los conceptos de las áreas de conocimiento de PMBOK® incorporando la visión y el enfoque tanto de PRINCE2® como de ISO 21.500:2.012 de forma que las bases de gestión del modelo también sean las de los tres enfoques. Asimismo, y para poder alcanzar los objetivos planificados para esta investigación, se han identificado y clasificado los principales estándares, métodos y cuerpos de conocimiento disponibles, obteniéndose, por consiguiente, una visión global de la disponibilidad del conocimiento en la gestión de proyectos. Además, se ha realizado un estudio sobre las herramientas de software de gestión de proyectos disponibles en el mercado así como se han confeccionado esquemas ilustrativos de los tres enfoques codificados con el objeto de clarificar y diferenciar tanto los componentes de los procesos como los grupo o áreas de conocimiento afectadas en cada momento y se han incluido como anexos de esta tesis.
24
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
1.2.
Objetivos de la tesis
Hipótesis de partida La hipótesis de partida de la tesis es que es posible y viable desarrollar un modelo de procesos que puedan contemplar los diferentes enfoques en la gestión de proyectos y los procesos asociados de PMBOK®, PRINCE2® e ISO 21.500:2.012. Ello se justifica ante la observancia de que existe una relación directa entre ellas y, con ello mismo, se considera que se podría proponer una metodología extendida homologable por dichos diferentes enfoques. Esta tesis se sustenta además en las siguiente hipótesis:
Hipótesis 1: El conocimiento en gestión de proyectos está concentrado de forma práctica en los cuerpos de conocimiento que las diferentes asociaciones desarrollan en base a las lecciones aprendidas y experiencias en proyectos anteriores. El cuerpo de conocimiento más reconocido es el PMBOK® (Project Management Body of Knowledge) de PMI® (Project Management Institute). Hipótesis 2: El modelo prescriptivo más implantado y reconocido a nivel internacional es el desarrollado por la Oficina Gubernamental de Comercio (OCC) del Reino Unido; PRINCE2®. Hipótesis 3: La norma ISO 21.500:2.012 se ha creado con el objeto de servir como un estándar internacionalmente reconocido en la gestión de proyectos, lo que genera un interés especial a la hora de su homologación con los diferentes modelos o marcos de gestión de proyectos existentes y, en concreto, en lo relativo a esta investigación con PMBOK® y con PRINCE2®. Hipótesis 4: En un proyecto se obtienen mejores resultados cuando los agentes que participan en su desarrollo disponen de una predictibilidad a la hora de conocer los pasos a seguir y los procesos a utilizar, de forma que no se pierda eficiencia en la improvisación de las actividades.
Objetivo principal El objetivo principal de esta tesis es desarrollar una metodología novedosa basada en PMBOK® que integre los estándares profesionales de gestión de proyectos más reconocidos a nivel mundial como es el PMBOK® (Project Management Body of Knowledge), el método PRINCE2® (Projects in Controlled Environments) e ISO 21.500, de forma que permita la gestión de proyectos aprovechándose del conocimiento de las tres estrategias de gestión y facilitando además la colaboración entre diferentes empresas y profesionales que utilicen estos métodos individualmente. Objetivos parciales Los objetivos parciales de esta tesis son:
Objetivo parcial 1: analizar los diferentes marcos y métodos de gestión de proyectos más representativos, en concreto PMBOK®, PRINCE2® e ISO 21.500:2.012 y realizar un resumen de los mismos.
Objetivo parcial 2: relacionar las entradas y salidas de los procesos PMBOK®, PRINCE2® y ISO 21.500:2.012 con PMBOK®.
Objetivo parcial 3: asegurar el cumplimiento de ISO 21.500:2.012 en la gestión de proyectos bajo metodologías PMBOK® y PRINCE2®.
Objetivo parcial 4: desarrollar una relación unívoca entre los procesos del modelo integrado con el resto de enfoques analizados.
Objetivo parcial 5: desarrollar un lenguaje común de gestión de proyectos aunando las distintas metodologías analizadas. 25
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Objetivo parcial 6: establecer un orden de los procesos para la correcta gestión de un proyecto aplicando los procesos nuevos.
Objetivo parcial 7: analizar la viabilidad en la aplicación del MGIP en los procesos propios de una empresa real que esté gestionando proyectos base a su propia metodología.
Objetivo parcial 8: diseñar un mapa de procesos en el que se plasmen los procesos que hemos desarrollado y que integre y contemple tanto los procesos de PRINCE2® como de ISO 21.500.
Limitaciones de la tesis Esta tesis se centra en el desarrollo de los procesos, por lo que no se van a identificar ni explicar las diferentes técnicas o herramientas de gestión que se pueden utilizar para conseguir las salidas esperadas en cada proceso. De la misma forma, al analizar modelos de gestión de proyectos predictivos, no se tratarán los modelos ágiles.
26
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
1.3.
Metodología de trabajo
En este capítulo se presenta la metodología que se ha seguido para la consecución de los objetivos de esta tesis. Estos métodos se utilizan para aportar rigor a la investigación y dotar de validez científica a la tesis que se presenta. La metodología aplicada a esta tesis se fundamenta en tres bases fundamentales;
1.3.1.
El uso del método deductivo‐inductivo. La recopilación y revisión sistemática de la literatura existente sobre el tema. La aplicación de las técnicas de gestión de proyectos a la propia tesis, tratando ésta como un proyecto en sí mismo. Método deductivo‐inductivo
En el desarrollo de esta tesis se ha tenido en consideración tanto el método deductivo como el inductivo [56‐ 58]. Así, en una primera fase de la tesis, la generación del MGIP se ha realizado a partir de las premisas descritas en los tres enfoques de gestión de proyectos analizados. Por lo que al tratarse de enfoques aceptados de forma generalizada y adoptados por gobiernos y organizaciones de reconocido prestigio, ello hace que el método diseñado servirá para gestionar proyectos de forma correcta al integrarlos de forma plena. Una vez conseguido el diseño del MGIP mediante la aplicación de la metodología deductiva, se viene a explicar la inductiva, y ello se hará sobre la base de un caso de estudio. De esta forma, puede ser comparado frente a un grupo de proyectos que han ha demostrado buenos resultados [59]. Por lo que hemos seleccionado un modelo de gestión real de una compañía promotora‐constructora inmobiliaria que ha desarrollado 66 proyectos con una metodología propia basada en las buenas prácticas en la que sus directores de proyectos han ido identificando y aportando sus experiencias y lecciones aprendidas a lo largo del tiempo. Método deductivo El razonamiento deductivo puede definirse como aquel proceso discursivo y descendente que pasa de lo general a lo particular. Proceso discursivo porque es mediato; porque se efectúa siguiendo una serie de pasos lógicos y descendente porque baja, desciende de algo general a un aspecto particular y/o singular; en fin, llega a lo individual o concreto, a partir de lo abstracto. Estos razonamientos deductivos, nos permiten referir los objetos o fenómenos estudiados a las leyes que los rigen; de igual manera, permiten descubrir una consecuencia desconocida, a partir de un principio conocido. Estos principios se consideran como premisas. Un ejemplo claro de razonamiento deductivo sería el siguiente: Este es un método que, por lo general, se distingue porque parte de premisas generales para llegar a una conclusión particular o concreta. Sin embargo, más adelante, se clarificará la distinción exacta del método deductivo, con respecto a los otros métodos de razonamiento. El método deductivo, parte de la razón inherente a cada fenómeno, para establecer conclusiones lógicas [56, 57]. Método inductivo Los razonamientos inductivos, a diferencia de los deductivos, van de lo particular a lo general, o de lo menos general a lo más general. Por lo que parte de la observación exacta de fenómenos particulares para llegar a conclusiones empíricas, extraídas de la experiencia [56, 57]. Diferencia entre inducción y deducción Se puede considerar que la deducción y la inducción son procesos contrapuestos, lo cual no es del todo cierto, pero sin embargo existe una diferencia entre ellas, que va más allá del simple punto de partida y de finalización que toma cada uno de estos métodos; que se entiende como inverso al del otro método (deducción: de lo general a lo particular, e inducción: de lo particular a lo general) [58]. La deducción, se basa en que la conclusión se sigue de las premisas necesariamente; mientras que en la inducción, la conclusión se sigue de las premisas solamente de manera probable. Debido a esta razón, los enunciados deductivos se califican como válidos o inválidos; será válido un enunciado o argumento cuando las premisas, de ser verdaderas, proporcionan bases contundentes para la verdad de la conclusión. Y, en este método, es imposible que las premisas sean verdaderas, a menos que la conclusión también lo sea. Por tanto, cuando el razonamiento es incorrecto, el enunciado será inválido. De esta manera, en la deducción, o bien las premisas apoyan realmente a la conclusión, de
27
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
forma concluyente, o no logran hacerlo. De otro lado, la inducción no pretende que sus premisas sean fundamentos para la verdad de la conclusión, sino solamente que proporcionen cierto apoyo a dicha conclusión; por ende, en la inducción los argumentos o hipótesis, no pueden ser calificados de válidos o inválidos, sino de mejores o peores, de acuerdo con el grado de apoyo que las premisas otorguen a las conclusiones [57, 60]. 1.3.2.
Revisión sistemática de la literatura existente
Para que una investigación científica demuestre su aportación, debe exponer evidencias de su originalidad con el suficiente rigor científico. La base suele ser el conocimiento científico adquirido acerca del ámbito de la investigación en cuestión, desarrollado por expertos en la materia. Sobre esta base, esta tesis hace su aportación a la comunidad científica. De forma que un camino para conseguir este objetivo es el desarrollar un estudio previo que exponga el estado del arte sobre el contenido de esta tesis. Así, el segundo pilar de la metodología de esta investigación se basa en la revisión sistemática cuyas características son el resumir la evidencia existente sobre el tema estudiado, permite identificar nuevos ámbitos de investigación no desarrollados hasta la fecha y además sirve para proporcionar un marco sobre el que situar adecuadamente las actividades de investigación de esta tesis. La revisión sistemática puede seguir tres etapas según expone Bárbara Kitchenham [61, 62]. La primera es la planificación de los trabajos, identificando la necesidad de revisión y desarrollando un protocolo de revisión. Seguidamente se pasaría a la fase de desarrollo, seleccionando los estudios primarios, evaluando la calidad de la información y sintetizando los datos. Finalmente, la última fase sería la de publicación de los resultados y su inclusión en la tesis. 1.3.3.
Aplicación de las técnicas de gestión de proyectos
Es considerado de gran interés para el desarrollo de la tesis aplicar las propias técnicas y principios de la gestión de proyectos. Así, la creación de este trabajo se puede considerar como un proyecto, pues se han realizado actividades en una fase de inicio ‐en la que se ha identificado la necesidad y la justificación del desarrollo de la tesis‐, y se han establecido los objetivos principales y la estrategia de la propia investigación. Seguidamente, se ha desarrollado una planificación detallada en la que se han identificado de forma exhaustiva las tareas concretas a realizar así como su horizonte temporal. Ha sido en este hito cuando se han definido las herramientas tanto para la revisión sistemática como para la propia producción de la tesis. Sobre esta planificación detallada de los trabajos se ha procedido a la ejecución de las actividades, contrastando y monitorizando los resultados reales con los trabajos especificados en el plan de forma que se han ido detectando desviaciones, las cuales se han ido corrigiendo y se han realizado proyecciones de la finalización de la misma, asegurando de esta forma, el cumplimiento de los objetivos de este trabajo. Así pues, los pasos concretos seguidos en el desarrollo de esta tesis han sido:
Establecimiento de los objetivos de la tesis desde dos puntos de vista: o Los propios del resultado final científico de la tesis y expuestos en la sección de objetivos. o Los referidos al tiempo y trabajo a realizar para poder conseguir desarrollar el documento de la tesis.
Diseño de un plan de trabajo: o Planificación detallada de las actividades de la tesis. o Diseño de la estrategia de la investigación y del desarrollo del documento: Identificación de las fuentes para la revisión sistemática de las fuentes (ver sección 0). Selección de las herramientas informáticas a usar. Identificar el manual de estilo a aplicar en el desarrollo de la tesis y del formato del documento final de la misma. o Establecimiento de un calendario concreto de trabajos.
28
Desarrollo del documento de la tesis. o Estudio de las fuentes bibliográficas existentes sobre los temas tratados en la tesis. o Recopilación de bibliografía genérica y específica. o Análisis crítico de las mismas y selección de las apropiadas para su incorporación al documento. o Completar el estado del arte de la cuestión. Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
o o o o o o o o o
Realizar el resumen y análisis de los tres enfoques incorporados en la tesis: PMBOK®, PRINCE2® e ISO 21.500:2.012. Diseño del modelo que estandarice la implantación práctica; MGIP: Modelo de Gestión Integrada de Proyectos. Confección de la primera versión del MGIP, en base a los procesos, principios y temas. Generación de los contenidos de las fichas de los procesos del MGIP. Elaboración del mapa de procesos del MGIP. Homologación del MGIP con cada uno de los marcos de gestión de proyectos, bajo el aseguramiento de que todos sus principios, temas y procesos han sido incorporados al modelo de la tesis. Refinado y finalización de las fichas y del mapa del MGIP. Discusión sobre la homologación de los tres estándares en el MGIP. Comprobación del modelo en un caso práctico, de forma que se pueda determinar su aplicabilidad práctica.
Establecimiento de las conclusiones de la tesis. Identificación de futuras investigaciones y trabajos a realizar a partir de la conclusión de esta tesis.
29
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
1.4.
Estructura de la tesis
Con el objetivo de se pueda exponer de forma adecuada los resultados obtenidos en esta tesis, se ha estructurado en cinco partes la misma:
Figura 12: Estructura de la tesis.
Parte 1: Aspectos preliminares: En esta sección de la tesis, se establecen las bases para el desarrollo posterior del MGIP. Así, se han incluido en la introducción aspectos tales como la motivación, justificación y la aportación de la tesis, junto con las novedades que se incorporan. Se extractan los objetivos de la misma, basados en unas hipótesis de partida, se identifican, por tanto, el objetivo principal como los objetivos parciales o secundarios. En esta sección también se explica la metodología de trabajo que se ha seguido para la producción final de la tesis. Completando esta parte, se incluye el estado del arte de la cuestión describiendo tanto los conceptos básicos de la gestión de proyectos como una descripción de los tres enfoques tratados en la tesis como son el PMBOK®, PRINCE2® e ISO 21.500:2.012. Además y como aspectos a destacar, se trata la evolución del concepto de gestión de proyectos a lo largo del tiempo y los marcos de gestión de proyectos generados, desde los cuerpos de conocimiento, los estándares y las metodologías existentes en la actualidad. De igual forma, se identifican las herramientas informáticas de gestión de proyectos con las que se pueden implementar los marcos descritos.
Parte 2: Desarrollo del modelo MGIP: En esta parte es donde se desarrolla la aportación principal de esta tesis, ya que se identifican y explican los nuevos procesos, principios y áreas de conocimiento que se han diseñado para poder homologar los tres enfoques descritos anteriormente. Así, en primer lugar se explica la estructura del modelo y seguidamente se expone la visión del MGIP respecto a: o Los principios aplicados en la gestión de proyectos. o Las áreas de conocimiento; exponiendo en este caso la visión que cada uno de los enfoques tiene sobre las diferentes áreas o temas. o Exposición detallada de los nuevos procesos desarrollados. En este punto se exponen los procesos de cada uno de los enfoques para que sirvan como base y medio correcto de entendimiento del nuevo modelo MGIP. Este punto se considera fundamental en la tesis ya que se describe gráficamente la distribución de los procesos a lo largo de las áreas de conocimiento AAP y de las fases de gestión del proyecto FGP y además se incluyen cada una de las fichas que se han desarrollado para cada proceso.
Parte 3: Aplicación de un caso de estudio. Se considera conveniente en esta tesis aplicar el MGIP a un caso práctico real. Es por ello por lo que se exponen en la misma los procesos que una empresa ha venido incorporando en la gestión de sus procesos y, a partir de ellos, éstos son contrastados con los de la empresa en las que se han incorporado los del MGIP a fin de comprobar la viabilidad de su aplicación real.
Parte 4: Aspectos finales y conclusiones: Esta parte se ha denominado de aspectos finales, ya que en la misma se incluyen las conclusiones de la tesis, respecto a los objetivos inicialmente establecidos en la parte 1 y también se identifican las oportunidades de realizar trabajos posteriores o futuros a partir de los resultados de la tesis.
Parte 5: Apéndices y anexos: Se incluyen los apéndices y anexos necesarios para la comprensión de la tesis.
30
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
1.5.
Conceptos básicos en la gestión de proyectos
1.5.1.
Definición de proyecto y gestión de proyectos
Un proyecto se desarrolla en un entorno determinado y puede ser desarrollado de forma aislada por la organización o puede integrarse con otros de forma que con la gestión común de ellos, se consiga un mejor resultado que si se desarrollaran aisladamente. Así, se pueden identificar diferentes niveles de gestión; la gestión de la cartera de proyectos o portfolio, o la gestión de programas, si bien estos tres enfoques analizados en esta tesis tratan la gestión a nivel de proyecto. Por ello mismo, se considera conveniente concretar algunas definiciones importantes y que clarifiquen las diferencias en la gestión entre proyectos, programas y portfolios. Definición de proyecto según PMBOK® Según PMBOK® [35], “un proyecto es un esfuerzo temporal que se emprende para llevar a cabo un producto, servicio o resultado único”. Esta definición implica que un proyecto debe tener un principio y un final definido y dicho final se puede conseguir bien cuando se han completado los objetivos del proyecto o cuando éste ya no es capaz de generar valor o la necesidad por la que fue creado ya no existe. De la misma forma, el producto del proyecto que genera puede ser tangible o no, pero siempre será único. En un proyecto deben considerarse los siguientes extremos: la identificación de requisitos, la identificación y la gestión de las necesidades y expectativas de los interesados, la gestión de las comunicaciones y el balanceo de las seis restricciones principales de un proyecto, a saber, el tiempo (cronograma), el costo (presupuesto), el alcance, la calidad, el riesgo y los recursos. Definición de proyecto según PRINCE2® Hay que tener en cuenta que PRINCE2® [46] se desarrolla en un entorno de: cliente/proveedor. Esto quiere decir que se parte de la premisa de que existirá un cliente que especificará el resultado deseado y que, probablemente pagará por el proyecto, y un proveedor que suministrará los recursos y competencias necesarias para entregar ese resultado. Así, la definición de proyecto que se incluye en el manual “Éxito en la gestión de proyectos con PRINCE2®” es: “un proyecto es una organización temporal que se crea con el propósito de entregar uno o más productos comerciales según un business case convenido». De este modo, los proyectos sirven fundamentalmente para realizar cambios en la organización y para adaptar la misma a los requerimientos del mercado y de sus clientes, mejorando sus procesos [63]. Así, a partir de su estrategia corporativa (probablemente definida en el Plan Estratégico de la misma), se pueden identificar oportunidades de mejora que se deben desarrollar controladamente. Como se observa en la siguiente Figura 13:
Figura 13: La generación de proyectos.
Por lo que los beneficios de la organización se obtienen de la puesta en marcha de los productos generados por los proyectos. Así, cabe diferenciar los proyectos de las operaciones propias de la compañía. Las operaciones son las actividades continuas, a diferencia de los proyectos que se crean y disuelven en un tiempo determinado, por lo que tienen naturaleza temporal. 31
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Y sus características principales son:
Sirven como medio para realizar el cambio. Son temporales; con inicio y fin. Tienen naturaleza inter‐funcional. Son únicos (diferenciar de operaciones). Se desarrollan en la incertidumbre, y son afectados por numerosas amenazas (riesgos) y oportunidades que hay que controlar a lo largo de su ciclo de vida, ya que al ser actividades diferentes a las habituales de la organización generan mayores riesgos.
Definición de proyecto según ISO 21.500:2.012 Según aparece en el texto de la ISO 21.500:2.012, es un conjunto único de procesos que consta de actividades coordinadas y controladas, con fechas de inicio y fin, que se llevan a cabo para lograr los objetivos del proyecto. El logro de los objetivos del proyecto requiere la provisión de entregables que satisfagan requisitos específicos. Un proyecto puede estar sujeto a múltiples restricciones, como son:
Duración o fecha prevista de finalización. Disponibilidad del presupuesto del proyecto. La disponibilidad de los recursos del proyecto, tales como personal, instalaciones, equipamiento, etc. Factores relacionados con la salud y seguridad del personal. El nivel de exposición aceptable de riesgo. El potencial impacto social o ecológico del proyecto. Las leyes, los reglamentos y otros requisitos legales.
Otras definiciones También es interesante la definición de proyecto que se expone en el SBOK™ [64] es una empresa colaborativa para crear tanto nuevos productos o servicios como entregar resultados definidos en la Declaración de la Visión del Proyecto. Los proyectos son impactados por restricciones como el costo, el alcance, calidad, las personas y las capacidades de la organización. Por todo lo anteriormente expuesto, y en base a las definiciones anteriores, se puede concluir señalando que un proyecto tiene una naturaleza temporal, que implica la creación de una organización que gestionará diversos recursos y que se disolverá cuando consiga alcanzar los objetivos del proyecto. Además un proyecto nace para cubrir una necesidad, por lo que es fundamental que a lo largo de la gestión del mismo, se disponga de una imagen precisa y clara de que el desempeño del mismo está alineado con la necesidad a cubrir. Otro aspecto que hay que recordar es que es necesario establecer los sistemas y canales de comunicación necesarios tanto para captar las necesidades de los agentes a los que el proyecto eventualmente afectará o será afectado, como para distribuir los datos e información que genera en términos de gestión. También IPMA en el ICB V3.0:2006 lo define como una operación que está restringida por el tiempo y el costo para realizar una serie de entregables definidos (el alcance necesario para cumplimentar los objetivos del proyecto), así como por el cumplimiento de los requisitos de calidad y resto de requerimientos. Gestión de proyectos También denominada como dirección integrada de proyectos. Podría ser definida siguiendo lo expuesto en PRINCE2® como la planificación, delegación, seguimiento y control de todos los aspectos del proyecto y la motivación de aquellos que participan para lograr los objetivos del proyecto dentro de las metas de rendimiento previstas para la duración, coste, calidad, alcance, beneficios y riesgos. Por lo que fundamentalmente la gestión de proyectos busca desarrollar los mismos de forma controlada, conociendo en cada momento la situación del mismo de forma que se puedan tomar decisiones acertadas y disponer de la posibilidad de actuar sobre las características del proyecto asegurando que el resultado sea el necesario y deseado por la organización para el cumplimiento de los requisitos del cliente. El PMBOK® la define como la aplicación de conocimiento, habilidades y herramientas y técnicas a las actividades del proyecto para cumplir con los objetivos del mismo. Muy similar es la visión de ISO 21.500:2.012: es la aplicación de métodos, herramientas, técnicas y competencias a un proyecto. E incluye por tanto, la integración de las diversas fases 32
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
del ciclo de vida del proyecto. Rafael de Heredia [65] también la define de forma sintetizada como el proceso de optimización de los recursos puestos a disposición del proyecto, con el fin de obtener sus objetivos. Por lo que todas estas definiciones coinciden de nuevo con que el esfuerzo que hay que realizar para gestionar un proyecto tiene un objetivo que es alcanzar las metas establecidas, si bien como se ha visto en puntos anteriores el concepto de éxito incluye no sólo el cumplimiento de los objetivos de alcance, tiempo y costo sino que el resultado del proyecto debe conseguir cubrir las necesidades para las que se ha creado y en resumidas cuentas, la satisfacción del cliente o promotor del mismo. En este punto se considera apropiado incluir la definición de dirección integrada de proyectos –otra forma de definir la gestión de proyectos‐ que realiza Manuel José Soler Serverino [66] y que indica que consiste en la dirección y organización de todas las actividades a lo largo del ciclo de vida de un proyecto, desde la concepción, planteamiento, diseño, ejecución y desactivación; y abarca la gestión, coordinación, control, motivación y resolución de los conflictos que surjan de las interacciones de los recursos humanos y recursos materiales necesarios para lograr un objetivo (el ser); mediante la aplicación de conocimientos, habilidades, herramientas y técnicas (ej: programación, planificación) (con qué); para (i) Identificar y satisfacer los requisitos y requerimientos del proyecto; (ii) establecer y obtener unos objetivos claros, prefijados y posibles de realizar; (iii) equilibrar las demandas concurrentes y limitativas de calidad, configuración‐alcance, tiempo, costes y recursos; y (iv) adaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y expectativas de los diferentes interesados (para qué). 1.5.2.
Breve historia de la gestión de proyectos
Evidentemente el hombre ha desarrollado a lo largo de la historia múltiples construcciones y proyectos de gran magnitud. También es evidente que no existían directores de proyecto (tal y como los conocemos ahora) para su gestión. Pero llegaron a buen fin. Se dice que a la pregunta a un director de proyectos egipcio sobre si las pirámides fueron gestionadas a través de técnicas de gestión de proyectos, éste respondió que seguro que sí, pero si hubiesen existido las modernas metodologías, las hubiésemos construido (las pirámides) en menos tiempo, con menor presupuesto y lo hubiésemos documentado. De hecho, antes de la utilización de las modernas técnicas de gestión de proyectos, los gestores de proyectos, desarrollaban según su imaginación y sus capacidades personales, sin establecer procedimientos estándar que se pudiesen aplicar repetidamente. Se estima que los bases de la dirección de proyectos moderna, se generaron a partir de los estudios y experiencias que realizó el ingeniero americano Winslow Taylor (USA 1.856‐1.915) [38] y posteriormente su pupilo Henry Gantt (USA 1.861‐1.919) [67] quien desarrolló el método de programación de tareas por barras que lleva su nombre y que en la actualidad tiene una gran aceptación y uso entre los directores de proyectos. Uno de los primeros proyectos en los que se usó este método fue en la presa Hoover, iniciada en 1.931, quienes pusieron en cuestión el modelo de gestión anterior a la Revolución Industrial dominado por los gremios y buscaron la eficiencia y la especialización de los trabajos. La adopción del ciclo PDCA (plan, do, check, act) [68], estableció, además, las bases del control de calidad moderno; primero hay que planear lo que se pretende hacer, para posteriormente hacerlo, y lo que es más importante, comprobar que lo que se ejecuta coincide con lo planificado y en caso de no ser así, se deben tomar las decisiones necesarias para reconducir las tareas hacia el cumplimiento de los objetivos del proyecto. Así mismo, de las experiencias que se van obteniendo en cada una de las operaciones de un proyecto, se pueden ir sustrayendo conclusiones y conocimiento que se debe aplicar a los futuros proyectos, produciendo una mejora continua en la gestión. Cabe destacar la innovación del gráfico de barras que inventó Gantt, y que supuso toda una revolución en el mundo de la gestión de proyectos y la base de la moderna gestión de proyectos. Así, de una forma muy visual e intuitiva, se podía ver cuáles eran las tareas que había que completar en un proyecto, a la vez que la barra que las definía, indicaba tanto el inicio como el final de cada una de ellas. Al estar incrustadas en un calendario, era posible definir qué día debía empezar un determinado trabajo y cuándo debería terminar para cumplir la planificación del proyecto. Se considera que a principios de la Guerra Fría, en el siglo XX, fue cuando se empezó a utilizar metodologías de project management. Se gestó principalmente en el Departamento de Defensa de Estados Unidos y en la NASA. La razón fundamental que forzó el cambio de paradigma en el desarrollo de sus proyectos fue la competencia con el otro actor del telón de acero. Así, era necesario desarrollar proyectos cada vez más complejos y costosos y en el menor tiempo posible, ya que de otra forma, la competencia podría alcanzar la supremacía militar y aeroespacial. Utilizaban lo que se denomina over the fence method, que partía de la base de que cada departamento o equipo debía desarrollar su trabajo y una vez realizado debía entregarlo al siguiente equipo, centrándose ya en otro tema. Dado que con este método no obtuvieron los resultados deseados, se decidió disponer de una visión global de todo el proyecto que integrase los 33
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
aspectos críticos del mismo. Además se estandarizaron los procesos que habían funcionado bien, de forma que se repitieran en los futuros proyectos. Así, en el Departamento de Defensa se dieron cuenta de que una forma para optimizar los recursos y asegurar de alguna forma que los proyectos saliesen bien y lo antes posible, era necesario actuar en dos vertientes:
Establecer y diseñar procesos y metodologías homogéneas basadas en las experiencias previas de los resultados de otros proyectos ya realizados. Colocar a un único responsable en cada proyecto que coordinase y controlase los parámetros principales del proyecto.
En esta época, se desarrollaron varios modelos matemáticos para la planificación temporal de los proyectos, entre ellos, el Método del camino crítico (CPM), evolucionado conjuntamente por DuPont Corporation y la Remington Rand Corporation. Este método consiste en una técnica que se usa para predecir la duración de un proyecto a partir de las relaciones de cada una de las tareas y la flexibilidad u holguras entre los inicios y finales tempranos y tardíos. En la actualidad tiene una gran implantación en proyectos reales debido a su fácil aplicación [69]. El avance a destacar de estas técnicas, fue el de conseguir determinar cuáles son la tareas críticas de un proyecto; es decir, las que marcan la duración total del mismo, de forma que sobre ellas es donde más atención hay que poner. Además esta definición de las tareas se hace de forma científica, fomentando la objetividad en la gestión. Otra técnica importante fue desarrollada por Booz Allen Hamilton y la Marina de los Estados Unidos, para la ejecución de proyectos militares que fue denominada PERT (program evaluation and review technique), la cual evolucionó perfeccionando las técnicas de planificación previas. De hecho, este método lo inventó el Departamento de Defensa de los Estados Unidos de América en el proyecto que se expone a continuación el cual fue desarrollado en plena Guerra Fría, a mediados de los años 50, cuando existía una gran desconfianza entre las dos partes del Telón de Acero que abocó a una carrera armamentística desenfrenada. Esto supuso que se debían desarrollar proyectos cada vez más complejos y costosos, en un marco de escasez y restricciones importantes en sus recursos, sobre todo en el tiempo, pues tenían la imperiosa necesidad de ser los primeros en desarrollar armas potentes que pudiesen decantar el equilibrio, o alcanzar logros en el sector espacial. En ese entorno, el Departamento de Defensa de USA, pensó en desarrollar un sistema de misiles balísticos de largo alcance que pudiesen ser disparados desde submarinos, de forma que se aumentara de forma significativa y definitiva sus capacidades ofensivas. En realidad, el proyecto era realmente ambicioso para la época, ya que nunca se había construido nada parecido, y tuvieron que enfrentarse a grandes retos como los que se exponen a continuación: 1. 2. 3. 4. 5.
No existía un misil con los requisitos necesarios para transportar la carga nuclear. Se estimaba que el tamaño del misil sería tal que no cabría en ningún submarino existente. ¿Cómo se podría disparar desde un submarino sumergido?. No se había desarrollado aún ningún tipo de sistema de guiado para dirigir el misil. Los misiles deberían tener un alcance de miles de kilómetros.
Esta situación de exigencia máxima obligó a orientar los proyectos de una forma diferente y de hecho fue uno de los referentes de la gestión de proyectos. Nació el Fleet Ballistic Missile (FBM) y de sus experiencias se pudieron extraer importantes y útiles lecciones aprendidas. Las que se entiende que fueron clave para el cuerpo de conocimiento de la gestión de proyectos fueron:
Se estableció un fuerte liderazgo, siendo la figura del director del proyecto DP la que debería velar por todos los aspectos del proyecto y que éstos estuvieran coordinados y alineados, así como del mantenenimiento de las comunicaciones y la motivación entre los miembros del equipo. Se definió la figura del sponsor o patrocinador del proyecto en la Special Projects Office que se encargó de influir en los agentes claves afectados (stakeholders), así como de lograr la financiación necesaria. Además nombró al director del proyecto: al almirante William F. Raborn. Desde el punto de vista técnico de gestión, se comenzó a usar el método PERT para la planificación de tareas, como ya hemos indicado. Se utilizó de forma masiva la estructura desagregada del trabajo EDT (WBS work breakdown structure), que descomponía el total del trabajo del proyecto en piezas más pequeñas, siendo ésta la base fundamental para la gestión de un proyecto que se basa en la entrega de productos ya que de esta manera se describen todos los trabajos que se tienen que desarrollar para finalizar el mismo.
El Departamento de Defensa obligó a sus contratistas y colaboradores a utilizar estas técnicas que se demostraron adecuadas y eficientes para el desarrollo del proyecto, siendo este extremo clave para la implementación 34
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
de las técnicas de gestión de proyectos. De hecho, participantes en este proyecto participaron también en la creación de PMI®. Expansión Mundial de la gestión por proyectos Los modelos y el uso de gestión por proyectos, se han ido expandiendo en todo el mundo siguiendo el modelo que surgió en EEUU. En un principio fueron las agencias gubernamentales las que forzaron a sus proveedores a usarlas, si bien, posteriormente, fueron las grandes empresas internacionales anglosajonas, las que en su expansión, obligaron tanto a sus proveedores como sus socios a desarrollar los proyectos en los que participan de una forma estandarizada y probada, bajo los estándares basados en sus lecciones aprendidas de sus anteriores proyectos. En la actualidad es difícil encontrar un gran proyecto que no se esté desarrollando bajo la utilización de alguna técnica de gestión de proyectos (Olimpiadas, centros comerciales, etc.). Así, en España, se ha ido introduciendo en todos los sectores según acabamos de exponer, empezando por las grandes ciudades y las zonas prioritarias de inversión extranjera. El reconocido autor de numerosas obras de referencia en el mundo del gestión de proyectos, Harold Kerzner, expuso en 2.003 una afirmación que indica un cambio de paradigma que, a su juicio, se está produciendo en el mundo de la gestión empresarial y su orientación hacia los proyectos, la cual se pasa a reproducir :“Hace 20 años, las empresas tenían la opción de elegir utilizar project management. Hoy algunas de ellas, estúpidamente piensan que todavía pueden hacerlo. Nada más lejos de la realidad. Su supervivencia depende de cómo se implementan los procesos de gestión de proyectos y lo rápido que lo hagan”. En el entorno internacional existen diferentes cuerpos de conocimiento en los que se exponen las buenas prácticas y que ha sido desarrolladas por asociaciones u organismos especializados. También se están introduciendo modelos de gestión de proyectos ágiles generados a partir de un enfoque basado en la entrega de valor temprano al cliente y en un desarrollo incremental del producto. Así, en 1.986 Hirotaka Takeuchi y Ikujiro Nonaka expusieron en un trabajo [70] un enfoque holístico que asimilaba el desarrollo de un proyecto al avance que van realizando los jugadores de rugbi en un partido, ya que van avanzando de forma colectiva y conjunta todos los miembros del equipo de línea a línea de forma progresiva. De hecho, se han desarrollado varios métodos de gestión de proyectos ágiles como Crystal, Scrum, Dynamic System Developement Method, eXtreme Programing (XP) considerado la más ágil de todas [71], Kanban, Lean Product Development, Feature Driven Development o Adaptative Software Development. En concreto y por su implantación, es interesante resaltar que en los inicios de la década 1.990, Ken Schwaber y Jeff Sutherland entre otros empezaron a utilizar el término “scrum” (melé) para identificar a los métodos de gestión de proyectos de software que seguían las directrices se han expuesto en el punto anterior. De hecho en 1.995 lo presentaron en una conferencia en Austin [72]. Otro hito importante en el desarrollo de metodologías ágiles es la publicación del manifiesto ágil [73] que en 2001 quince expertos en gestión de proyectos de software firmaron, resultando ser de facto las bases de la gestión ágil de proyectos. En él se establecen las preferencias sobre la forma de actuar en un proyecto: “Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas. Software funcionando sobre documentación extensiva. Colaboración con el cliente sobre negociación contractual. Respuesta ante el cambio sobre seguir un plan. Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”. 35
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
El experto gestor de proyectos en el sector IT Duncan Haughey, [74] ha desarrollado una gráfica (Figura 14) en la que integra cronológicamente además de los hitos expuestos anteriormente algunos otros puntos de interés:
Figura 14: Cronología de la evolución del conocimiento en gestión de proyectos.
Además de los hitos enumerados anteriormente puede resaltarse que en 1.975 Simpact Systems Limited creó el Método PROMPTII, desarrollado con el objetivo de dar respuesta a las dificultades de estimación de tiempos y costos de los proyectos en las fases de viabilidad, por lo que fue un intento de establecer las directrices para el flujo de las fase de un proyecto informático. Cabe asimismo destacar la publicación de la obra The Mythical Man‐Month: Essays on Software Engineering (Mítico Hombre‐Mes: Ensayos de Ingeniería de Software) [75] de Frederick Brooks.
En la misma se estableció su famosa Ley de Brooks que decía que agregar recursos humanos a un proyecto de software retrasado hace que se retrase aún más. En cualquier caso, como se ha venido señalando, la aplicación de las técnicas, herramientas y metodologías en gestión de proyectos está sufriendo una evolución continua. Según Juan José Miranda, en el Desafío de la gerencia de proyectos [76], este interés radica en que esta gestión planificada y basada en el control puede evitar las desviaciones en plazos y presupuestos de una manera más eficaz que a través de las metodologías tradicionales. Así, mientras la producción de los proyectos con naturaleza única y temporal sufre la incertidumbre del coste y del plazo, lo que puede repercutir en los resultados finales, en la producción industrial se avanza en eficiencia y ahorro de costes, eliminado tiempos muertos e inventarios [77]. La transposición de estas técnicas a la construcción, mejoraron la duración del proyecto y su coste, siendo la base común de la dirección de proyectos [78]. 1.5.3.
Gestión de cartera de proyectos o porfolio
También denominado como portfolio management. Cuando se necesita gestionar más de un proyecto dentro de una organización es necesario establecer diferentes niveles de gestión de forma que se busque la máxima eficiencia de los recursos de la organización. Así, la gestión de portfolio, se refiere a una lista de proyectos o programas (y otro tipo de trabajo, incluso otros portfolios), que se agrupan para facilitar una gestión más efectiva para conseguir alcanzar los objetivos de la empresa. Por lo que se puede decir que la gestión de portfolio es un nivel superior de gestión. De hecho, los elementos del portfolio pueden estar relacionados entre sí o no. Por tanto, este tipo de gestión se refiere a la gestión centralizada y priorizada en el uso de recursos, ya que los objetivos fundamentales de este tipo de gestión de proyectos son: Maximizar el valor del portfolio a nivel global de la organización. Equilibrar las inversiones. Disponer de una visión global de todos los proyectos de la compañía. Disponer de información para priorizar el uso de recursos. Detectar puntos críticos o cuellos de botella, de forma adelantada. Usar los recursos disponibles de forma eficiente. Antecedentes 36
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
Las técnicas de gestión de múltiples proyectos y su problemática es diferente a la gestión de proyectos de forma individual. De hecho, este tipo de administración es uno de los factores que más preocupan e interesan a los directivos y ejecutivos de las compañías ya que si bien en la gestión de un proyecto individual el foco se centra en “hacer bien el trabajo”, cuando se trata de gestionar un grupo de proyectos de una compañía el paradigma es “hacer el proyecto adecuado” (doing projects right vs doing the right project [79]). De esta forma, es que desde una visión global, se puedan seleccionar y potenciar los proyectos que más interesen a la compañía, desechando los que sean poco adecuados [80], pues además de ser una función de coordinación operativa, es, fundamentalmente, un objetivo estratégico. El desarrollo de la gestión del porfolio de proyectos empezó a ser notable a partir de las décadas de los 70´s y 80´s [81], si bien se puede definir su origen en el artículo de Harry Markowitz en 1.952 donde establecía las bases de las Modernas Teorías de Porfolio (MPT Modern Portfolio Management) [82]. Inicialmente el campo principal del desarrollo de este nuevo campo eran los proyectos de inversiones financieras, pero poco a poco fue implantándose en el resto de industrias. Así en 1.981 Mc Farlan desarrolló las bases de la gestión de porfolio para proyectos informáticos [83], introduciendo así mismo la necesidad de analizar integradamente los posibles riesgos a los que se podrían enfrentar los proyectos como grupo. Ya en la década de los 90´s la gestión de proyectos empezó a tener un interés creciente. En 1.992 Wheelwright and Clark [84] desarrollaron un marco para gestionar proyectos por categorías, en lo que denominaron “El Plan de Agregación del Proyecto”. Estas dos dimensiones que según ellos permitían tener una visión general del porfolio, con el objeto de identificar posibles fallos o huecos en el portfolio o potenciales oportunidades de ahorro, son: El volumen de cambios que se realizan en los productos. El grado de proceso del cambio, con cuatro posibles categorías. Ya en 1.998, Thorp publicó “La paradoja de la información” [85], donde indicaba que las técnicas de gestión de portfolio (PPM project porfolio management), son fundamentales para generar valor. Así en estos momentos, la gestión de proyectos está integrada completamente en la gestión de los productos de la mayoría de compañías en cualquier industria. Definición Para la definición de este concepto, se tiene en consideración la que dio Robert Cooper y otros [86], que, a su vez parte de la consideración de otras múltiples aportaciones de autores anteriores [81, 87, 88]: La gestión del porfolio o portfolio management es un proceso de decisión dinámico, donde una lista de nuevos productos (y de Investigación y Desarrollo I+D) y proyectos están constantemente actualizados y revisados. En este proceso, nuevos proyectos son evaluados, seleccionados y priorizados; existiendo proyectos que deben ser acelerados, desactivados o des‐priorizados; y los recursos son dirigidos o redirigidos a los proyectos activos. El proceso de decisión en el entorno del portfolio se caracteriza por la incertidumbre y la información cambiante, oportunidades dinámicas, multitud de objetivos y consideraciones estratégicas, interdependencias entre proyectos y múltiples actores que toman decisiones en diversos lugares. Por lo que es fundamental el uso de información relevante y actualizada [89]. De esta forma, se viene a considerar que el proceso de decisión del porfolio conlleva unos procesos de toma de decisiones dentro del negocio, incluyendo revisiones periódicas del total del portfolio de todos los proyectos, tomando decisiones del tipo go/kill (seguir – eliminar) en proyectos individuales y el desarrollo de nuevas estrategias para los productos. Aplicación de la gestión de portfolio. Como se ha indicado en los puntos anteriores, la gestión integrada del porfolio de proyectos está siendo muy utilizada y ampliamente reconocida. De hecho, es un aspecto crítico en la gestión estratégica. Robert Cooper, Scott Edgett y Elko Kleinschmidt [9] han realizado un estudio donde preguntando a gestores senior sobre las razones de la importancia de la gestión de porfolio, extrajeron las ocho razones que a continuación se pasan a exponer: 1. 2. 3. 4.
Financieras: maximizar el retorno de la inversión; maximizar la productividad de los proyectos de I+D; alcanzar los objetivos financieros. Mantener la posición competitiva del negocio – incrementar la ventas y la cuota de mercado. Para distribuir adecuada y eficientemente los (escasos) recursos. Acercar la unión entre la selección de proyectos y la estrategia del negocio: el porfolio es la expresión de la estrategia; debe apoyar la estrategia.
37
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
5. 6. 7. 8.
Conseguir enfocar, es decir no desarrollar demasiados proyectos para los recursos disponibles y reforzar los proyectos “buenos”. Alcanzar equilibrio – el equilibrio correcto entre proyectos de larga y corta duración, y alto y bajo riesgo, siendo consistentes con los objetivos del negocio. Para comunicar mejor las prioridades entre la organización, tanto horizontal como verticalmente. Proveer una mayor objetividad en la selección de proyectos – desestimar proyectos malos.
Pese a estos resultados, la gestión del porfolio no se realiza tan correctamente como se debiera y normalmente no se aplican técnicas adecuadas [86]. Esto puede presentar graves problemas a las empresas que no lo ejecuten correctamente. De hecho, en la misma encuesta anteriormente referida, los gestores entrevistados manifetaron cuatro aspectos negativos implícitos en una pobre gestión del portfolio: 1.
2.
3. 4.
Estrategia: falta de criterio estratégico en la selección de proyectos, de forma que pueden coexistir proyectos que no estén alineados con la estrategia de la compañía o se estén dedicando recursos en I+D a proyectos que no sirvan para desarrollar la estrategia global. Proyectos de bajo valor: no existe una adecuada capacidad para decidir si un proyecto debe seguir o no (go/kill), lo que puedes significar que existan demasiados proyectos no necesarios que absorban recursos que serían más valiosos para proyectos más interesantes. Si enfoque: al no existir criterios claros de selección de proyectos, pueden aparecer demasiados proyectos a los que dedicar recursos y tiempo, penalizando la gestión y la eficiencia. Los proyectos equivocados: puede que los proyectos equivocados se seleccionen. Sin existir un modelo de selección formalizado, la decisiones no se basan en criterios objetivos, sino en opiniones y emociones.
Así, en otra encuesta realizada por Jeffery and Leliveld [90], sobre 130 ejecutivos senior, dentro del sector de IT (90% Directores de Departamento), se obtuvieron los siguientes resultados; sólo el 25% de los encuestados se definirían como que están desarrollando una gestión de portfolio adecuada, el 45% la estaban adoptando y el 78% estaban planeando implantarla. Del análisis de estos resultados y premisas, además de la aportación de Bert De Reyk y otros [91], se pueden extraer y destacar los siguientes elementos clave que hay que tener en cuenta en el desarrollo de un correcto modelo de gestión de porftolio, a saber: Visión centralizada del porfolio; preparación de un inventario de los proyectos, tanto actuales como previstos, con un formato común y preferiblemente centralizados. Análisis financiero. Uso de ratios financieros adecuados (ROI, IRR, VAN, TIR) y usarlos de forma constante y homogénea en todos los proyectos. Análisis de riesgos. Hay que tener en cuenta tanto la gestión de riesgos de cada proyecto individual como la interacción entre todos. Interdependencias. Es necesario analizar y detectar las interdependencias entre los proyectos de forma que se optimicen los recursos. Priorización, alineación y selección. El objetivo es conseguir un portfolio equilibrado, con procesos de selección objetivos. Restricciones. O aspectos principales sobre los que se tiene que analizar el portfolio, tal y como expone Goldman [92] quien establece estos cuatro: recursos humanos, capacidades de la plantilla, presupuestos e infraestructura. Aseguramiento dinámico del portfolio. Una vez se ha establecido la configuración inicial del portfolio se deben realizar mediciones y controles periódicos. Necesidad de software especializado. Para mecanizar y optimizar las operaciones de gestión del portfolio. Impacto en las organizaciones. Problemas entre organizaciones. Implementación Visto el interés que supone la implantación de gestión de porfolio, las empresas que deseen hacerlo deben tener unas condiciones previas [90] que faciliten y permitan el desarrollo óptimo de los modelos. Estrategia Organizacional: las empresas deben disponer de objetivos claros y que sean comunicados a todos los departamentos y sobre los que las gestión del porfolio debe alinearse [80].
38
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
Implicación de los líderes del negocio: los máximos responsables deben estar completamente involucrados en la adopción de este tipo de gestión [93] de otra forma, la compleja gestión que requiere respecto a la interrelación de recursos, no se podría realizar. Capacidades del equipo: la empresa debe disponer de personal con conocimientos suficientes en lo relativo a Estrategia y Finanzas, de forma que puedan interpretar los ratios y datos objetivos, en las necesidades del portfolio. Una vez superado el estadio de las condiciones previas descritas anteriormente, la implementación de un modelo o sistema de gestión de portfolio debe pasar por varias fases o estados. Así, Berinato [94] establece 5 niveles de adopción, de la más sencilla a la más compleja: 1. 2. 3. 4. 5.
Poner los proyectos en una base de datos. Priorizar los proyectos en la base de datos. Dividir los proyectos en dos o tres grupos, dependiendo del tipo de inversión. Automatizar el repositorio de proyectos. Aplicar las modernas teorías de la gestión de portfolio (modern portfolio theory). Jeffery and Leliveld proponen una estructura más simplificada, con tres fases diferenciadas:
1. 2.
3.
Definición: Consistente en definir y documentar la información clave de cada proyecto y su estimación de coste y beneficio, de forma que el departamento disponga de una visión global. Gestionar: En este estadio, las organizaciones disponen de datos codificados y gestionado desde una central. Realizan revisiones periódicas y se cuantifican los datos relativos a la inversión. Nuevos proyectos e iniciativas son analizadas, priorizadas y categorizadas. Optimización: Es un estado avanzado donde las organizaciones son capaces de optimizar su portfolio de proyectos.
Bert De Reyk [90] también realiza una aproximación al problema con una clasificación muy similar a la anterior, definiendo en este caso igualmente tres fases. 1.
2.
3.
Inventariado del portfolio. a. Centralización de la administración del portfolio. b. Implantación de procesos de gestión del riesgo. c. Incorporación explícita de restricciones sobre los recursos. d. Incremento de la atención de los líderes del negocio sobre los resultados. Administración del portfolio. Desarrollando: a. Categorización de los proyectos. b. Evaluación del impacto en el cliente de los resultados del portfolio. Optimización del portfolio. Desarrollando: a. Un comité exclusivo para la gestión del portfolio. b. Aseguramiento del valor financiero del portfolio. c. Gestión de las interdependencias de los proyectos. d. Seguimiento del beneficio de los proyectos.
Modelos de gestión y selección del portfolio. Inicialmente, en los modelos de los años 60´s y 70´s, los modelo utilizados eran básicamente matemáticos [95], ya que su objetivo era el de optimizar variables básicamente objetivas, como puede ser la cuantificación de los beneficios esperados. Pero los gestores y ejecutivos no estaban demasiado convencidos con estas metodologías ya que necesitaban demasiados datos o información de la que no se disponía fácilmente [96]. Actualmente hay un gran número de modelos de selección de proyectos que se pueden utilizar en la gestión del portfolio, siendo habitual no utilizar uno sólo, sino un conjunto equilibrado de varios, dependiendo de las necesidades y características de cada compañía. Por ejemplo: Modelos financieros e índices financieros: se basan en la selección de proyectos conforme a índices como el Valor Actualizado Neto (VAN), LA Tasa Interna de Retorno (TIR), el payback o periodo de retorno, el retorno de la inversión (ROI return on investment), índice de productividad [97], o cualquier otro que se considere apropiado. Modelos de probabilidad financiera: modelos como el de la simulación de Monte Carlo y árboles de decisión como el método del valor comercial esperado (expected commercial value ECV) [98] .
39
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Teoría de la opción del precio: trata al nuevo proyecto en cada fase como si se adquiriese una opción de inversión futura. Modelos basados en marcadores y listas de chequeo: los proyectos son valorados según una serie de cuestiones cuantitativas [99]. Aproximaciones estratégicas: en este caso la selección del proyecto está dirigida fundamentalmente por la estrategia de la compañía [87]. Aproximaciones analíticas: se basan en la comparación tanto de los proyectos y los criterios, un ejemplo es el juicio de expertos, donde un grupo de gestores llegan a un consenso sobre los proyectos preferidos o más adecuados para conformar el portfolio de proyectos. Aproximaciones de comportamiento: más adecuados en las fases iniciales de los proyectos donde la información disponible es cualitativa principalmente. Métodos como Delphi o Q‐Sort [100] son un ejemplo de lo expuesto. Diagramas de burbuja o aproximaciones tipo mapa. Son básicamente una extensión del original modelo de portfolio del Boston Consulting Group (BCG) y el modelo GE/McKinkey, que se diseñaron para distribuir los recursos en las distintas unidades de negocio de la compañía. En los modelos actuales, se confrontan varios parámetros en diagramas de burbuja [97]. Según una encuesta realizada por Robert G. Cooper y otros [95], no hay un método que monopolice la gestión, si no que se usan múltiples modelos. Si bien, la encuesta arrojaba la conclusión de que los dos métodos más populares son el financiero y el de aproximaciones estratégicas. De la misma forma y en cualquier caso, la gestión de portfolio debe realizarse dependiendo de diferentes horizontes temporales [101] lo que permitirá adaptar éste mejor al entorno en el que opera la organización propietaria del portfolio. 1.5.4.
Gestión de programas
Un programa es un grupo de proyectos, relacionados entre sí, de forma que todos son necesarios para desarrollar un objetivo concreto (producto o servicio), definido en la estrategia de la compañía. De esta forma, la gestión coordinada permite conseguir unos beneficios y control sobre los proyectos, lo que no se alcanzaría si estos fueran gestionados de forma individual. Según la definición de PMI® que se recoge en el PMBOK® [35], un programa es un grupo de proyectos, subprogramas y actividades de programas relacionados cuya gestión se realiza de manera coordinada para obtener beneficios que no se obtendrían si se gestionaran de manera individual. Permite resolver: Restricciones de recursos globales. Conflictos entre proyectos del programa. Ajustar las directrices estratégicas del programa a las tácticas de cada proyecto. Resolver problemas dentro de un ambiente de gobernanza compartida. Subprogramas Un proyecto puede ser o no parte de un programa, pero un programa siempre tiene proyectos. Además, un programa se puede dividir en otros programas en un nivel inferior de gestión, es lo que se denomina subprogramas. A su vez, éstos ‐dependiendo de la complejidad y número de proyectos necesarios para lograr completar el programa principal‐ pueden estar compuestos por otros subprogramas de nivel inferior. Así, el primer nivel sería el determinado por la estrategia de la compañía. Póngase en cuenta una empresa que se dedica a la fabricación de vehículos, su portafolio principal podría estar compuesto de varios portfolios (camiones, coches y motocicletas), programas y proyectos. Incluso, cualquiera de sus portafolios podría estar compuesto por otros portafolios de nivel inferior, programas y proyectos (incluso también portafolios si las necesidades de gestión lo aconsejaran). Finalmente, los programas se compondrían de proyectos y también de programas. Así pues, el porfolio es la gestión de más alto nivel, que es gestionado por la empresa y el menor será el proyecto. Las buenas prácticas en la gestión de programas PMI® las ha descrito en un documento, análogo al anteriormente citado para la gestión de portfolio; The Standard for Program Management –Thrid Edition [102] al que se irá haciendo referencia en el desarrollo de este punto. Así, un programa es un grupo de proyectos, relacionados entre sí, de forma que todos son necesarios para desarrollar un objetivo concreto (producto o servicio), definido en la estrategia de la compañía. Esta gestión coordinada permite conseguir unos beneficios y control sobre los proyectos, que no se alcanzaría gestionándolos individualmente. Por lo que la gestión de programas es la gestión coordinada de un grupo de proyectos, cuyos resultados individuales son necesarios para la obtención de un resultado superior. Dichos 40
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
beneficios se podrán ir obteniendo durante la ejecución del programa o una vez finalizado éste. También puede incluir más trabajo relacionado con los componentes (proyectos), como formación, operaciones y actividades de mantenimiento. Lo que permite resolver las restricciones de recursos globales, los conflictos entre proyectos del programa, ajustando las directrices estratégicas del programa a las tácticas de cada proyecto y por tanto resolver problemas dentro de un ambiente de gobernanza compartida. Análogamente AXELOS, los actuales propietarios de la metodología PRINCE2®, ha desarrollado un estándar para gestionar proyectos de diferentes sectores y para organizaciones de diferente tamaño, Managing Succesfull Programmes (MSP), desde el punto de vista gestor del programa. En éste se desarrollan las capacidades clave que una gestión de programa debe generar en la organización, como son: dar apoyo a los productos que genera el negocio de la organización, facilitar el cambio en la organización, gestionar el riesgo alineado con las necesidades de la compañía, mostrar el valor que genera a partir de la inversión realizada y asegurar la mejora continua. En la Figura 15 ‐que se puede encontrar en la página web de AXELOS [103]‐, se puede apreciar como la gestión de programas según MSP se basa en tres “círculos”: El círculo exterior, que representaría a los principios que siempre se deben aplicar cuando se gestionan proyectos, a saber, el permanecer alineado con la estrategia de la organización, liderar el cambio, disponer de la visión y el compromiso para un mejor futuro para la organización, focalización en los beneficios a obtener y las amenazas a las que se deben enfrentar, añadir valor, diseñar y entregar funcionalidades coherentes y aprender con la experiencia. El segundo círculo está compuesto por los temas de gobernanza; definir la organización del programa, establecer la visión, liderar y mantener el compromiso con los stakeholders, realizar la gestión de los beneficios a entregar por el programa, desarrollar estudio de viabilidad y mantener la justificación del programa, gestionar los riesgos y los eventuales problemas a los que se podrá enfrentar, gestión y aseguramiento de la calidad. Finalmente, en el círculo central estaría el flujo en cómo, basándose en los círculos exteriores, se realizaría para obtener los beneficios conjuntos de los diferentes componentes del programa.
Figura 15: Los aspectos clave en la gestión de programas según MSP –los tres círculos‐.
Por lo que la gestión de programas o program management, es la aplicación de conocimiento, habilidades, herramientas y técnicas a un programa para alcanzar los requisitos del programa y obtener beneficios y control no disponibles en una gestión individualizada de proyectos. Comprende la alineación de múltiples componentes para alcanzar los objetivos del programa y permitir la optimización o integración del coste, tiempo y esfuerzo necesarios.
41
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Los 5 dominios del rendimiento de un programa En el standard de gestión de programas de PMI, el director del programa necesita integrar y controlar las interdependencias sobre los componentes a través de interrelacionar los 5 dominios de rendimiento como son:
Alineamiento con la estrategia del programa: Identificación de oportunidades y beneficios para alcanzar los objetivos estratégicos de la organización a través de la implementación del programa.
Incluye: o
o
o
Estrategia organizacional y alineamiento con el programa: Es el resultado del ciclo de planificación estratégica, donde la visión y la misión son transpuestas en un plan estratégico dentro de los valores de la organización. Hoja de ruta del programa (program roadmap): Es una representación en forma gráfica de la globalidad del programa en la que se identifican los eventos principales en forma cronológica, incluyendo la relación entre las actividades del programa y los beneficios esperados. Valoración del entorno. El director del programa debe identificar las influencias tanto internas como externas que puedan tener un efecto significativo en el desarrollo del programa. Gestión de los beneficios del programa: Definir, crear, maximizar, generar y mantener los beneficios generados por el programa. Incluye los procesos para clarificar la obtención de los beneficios planificados. Su objetivo es que los stakeholders principales se focalicen en la obtención de los resultados, de forma que las actividades desarrolladas vallan en esa dirección deseada. Por ejemplo: Identificar y valorar el impacto de los beneficios del programa. Monitorizar las interdependencias entre los resultados generados por los diferentes proyectos, y como contribuyen a los beneficios globales del programa. Analizar el potencial impacto de los posibles cambios en el programa, sobre los beneficios. Asignar responsabilidad para la realización de los beneficios generados por el programa. Alinear los beneficios esperados con los objetivos de la organización. Asignar responsabilidad para la realización de los beneficios generados por el programa y asegurar que pueden ser mantenidos. Se puede usar un registro de beneficios, en el que se identifique: Lista de beneficios planificados. Descripción de cómo cada beneficio será medido. Desarrollar indicadores clave para evaluar su consecución. Estatus y progresos de los indicadores para cada beneficio. Fechas objetivo e hitos para alcanzar los beneficios. Determinación de las personas u organizaciones responsables de la consecución de cada uno de los beneficios. Implicación de los interesados del programa: Identificar y comprender las necesidades de los stakeholders, analizando su impacto y aumentando y manteniendo su apoyo, gestionar las comunicaciones entre ellos y mitigando o canalizando sus posibles resistencias contra el proyecto. Se pueden identificar tres actividades clave:
42
Identificación de stakeholders. Además de analizar su posición e interés en el programa. A lo largo de este capítulo hemos ido identificando a varios de los stakeholders clave en la gestión de un programa, como son: Patrocinador del programa: lidera la iniciativa del programa, es responsable de proveer los recursos necesarios y es el último responsable de la consecución de los beneficios. Comité de gobernanza del programa: deben asegurar que los objetivos del programa se alcanzan y dan apoyo para la solución de problemas y enfrentarse a los riesgos. Director del programa. Director de proyecto. Miembros del equipo del programa. Miembros del equipo de proyecto. Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
o
Inversores / financiación externa. Organización ejecutante: La organización que ejecuta el trabajo del programa. Oficina de programas: la organización responsable de definir y mantener los procesos, formatos, normativas y de realizar de forma centralizada las actividades administrativas. Planificación de la implicación de los interesados. Gestionar la implicación de los interesados.
Gobernanza del programa: Establecer procesos y procedimientos para mantener la visión global del programa y la toma de decisiones a lo largo del mismo. Se refiere a las prácticas y procesos desarrollados por la organización patrocinadora del programa para asegurar que éste es gestionado efectiva y consistentemente. Así, la gobernanza del programa ayuda al éxito del mismo a través de:
o
Estableciendo acuerdos claros y bien entendidos de cómo la organización patrocinadora revisará el programa y del nivel de autonomía que el gestor del mismo dispone. Asegurando que los objetivos del programa se mantienen alineados con la visión estratégica de la organización. Estableciendo canales de comunicación de los riesgos del programa hacia la organización. Estableciendo canales de comunicación de los problemas surgidos en el programa hacia la organización. Realizando revisiones periódicas del progreso del programa a la hora de la obtención de sus beneficios, de forma que la organización pueda valorar la viabilidad del programa en cada momento. Comité de gobernanza del programa: La mayoría de organizaciones buscan asegurar una buena gobernanza a través del establecimiento de este tipo de estructuras. De hecho en muchas organizaciones este comité asume decisiones tan importantes como: o Aprobar el acta del programa. o Aprobar el estudio de viabilidad del programa. o Autorizar el final de una fase y el comienzo de la siguiente. o Aprobar la transición de un componente. Ciclo de vida del programa: Mantener todas las actividades relacionadas con el programa, desde la definición, la obtención de los beneficios y el cierre del mismo.
Un programa se inicia normalmente cuando se aprueba su financiación o se nombra al director del programa. De hecho, los programas se suelen implementar estableciendo fases discretas, es decir una empieza cuando la anterior a finalizado y su inicio ha sido aprobado. También pueden estar solapadas. El ciclo de vida de un programa, incluye las siguientes fases:
Figura 16: Ciclo de vida de un programa.
FASE 1: Definición del programa: se obtiene como resultado de la planificación de plan necesario que se debe implementar para alcanzar los resultados deseados por la organización. El objetivo inicial de esta fase es la de elaborar progresivamente los objetivos estratégicos a alcanzar, definiendo los productos o servicios que se espera que los proyectos produzcan y por supuesto, buscar la aprobación del plan del programa. 43
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Se pueden encontrar otras dos subfases importantes:
Formulación del programa: en este momento la organización nombra al Patrocinador del Programa, quien deberá asegurar la financiación de mismo y seleccionar al Director del Programa. Además:
Inicia los estudios de estimaciones de alcance, tiempo y costo.
Realiza una primera valoración de riesgos.
Desarrolla una acta de programa y la hoja de ruta del programa.
Preparación del programa: Se define la organización del programa y se forma un equipo para desarrollar el plan de gestión del programa, que se finalizará en esta misma fase. Este documento se basará en el estudio de viabilidad, el acta del programa y otras consideraciones. El plan contendrá:
Compontes del equipo del programa.
Planes de gestión necesarios.
Establecimiento de la gobernanza del programa.
FASE 2: Entrega de los beneficios del programa: A través de esta fase de carácter interativo, los componentes del programa (proyectos básicamente) se planifican, integran y gestionan, de forma que se obtengan los beneficios conjuntos del programa. Se puede dividir en las siguientes subfases:
Planificación de los componentes y su autorización: Se realiza la planificación de cada uno de los planes que componen el programa. Y se autorizan de forma que se asegure que todos son homogéneos y con ellos se podrán alcanzar los objetivos del programa.
Integración de los componentes: Cada uno de los componentes –proyectos‐ ejecutan sus planes y van obteniendo sus entregables.
Transición de los componentes y cierre de los mismos: Hay que asegurar que la transición de los productos obtenidos por cada proyecto sean traspasados correctamente. Así, antes de finalizar la fase 2, todos los componentes deben ser revisados para verificar que los beneficios deseados han sido alcanzados. Se debe realizar la revisión final del estatus por parte del Patrocinador del Programa y la Gobernanza del mismo, antes de proceder al cierre del programa.
FASE 3: Cierre del programa: El objetivo de esta fase es de realizar el cierre controlado del programa. Encontramos dos fases: Transición del programa: Antes de proceder a la transición del programa a la organización o al cliente, la Gobernanza del Programa deberá determinar si: Si se han alcanzado todos los objetivos deseados. Analizar si existe algún otro programa o actividad de mantenimiento que pueda aprovecharse tanto de los productos obtenidos como del conocimiento generado.
44
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
Cierre definitivo del programa: La organización aprueba el programa formalmente. El programa también puede ser cancelado anticipadamente bien porque no es capaz de conseguir los objetivos o simplemente porque la situación ha cambiado y ya no es necesario para la organización. De forma que el éxito del programa se juzgará comparando el resultado real obtenido contra el estudio de viabilidad y los objetivos actuales del programa. Todos los componentes deberían estar completados y los contratos cerrados formalmente antes de proceder al cierre del programa. Estos dominios se desarrollan conjuntamente a lo largo de la duración del programa. Cualquier programa requerirá desarrollar alguna actividad en cada uno de ellos en algún momento. Tienen naturaleza iterativa y se deben repetir frecuentemente. Para ello debe seleccionar la estrategia más adecuada de gestión a implementar en el programa, realizando las siguientes actividades: Liderar y coordinar las actividades comunes del programa; financiación y contratación de componentes a lo largo del programa y resolver las restricciones de los recursos y conflictos que puedan afectar a diferentes componentes. Comunicar e informar a los stakeholders de las actividades del programa. Responder proactivamente a los riesgos que puedan afectar a diferentes componentes del programa. Alinear el esfuerzo del programa con la dirección estratégica de la compañía, de forma que los diferentes componentes individuales, también estén alineados con ella. Resolver los diferentes impactos en los costes, tiempos, alcance, calidad y riesgo conforme a la estructura de decisiones definida en la gobernanza del programa. Adaptar las actividades del programa de forma que pueda enfrentarse adecuadamente a las diferencias culturares, socioeconómicas, políticas o medioambientales que pueda sufrir el programa. Debe identificar y controlar las interdependencias entre proyectos. Procesos de apoyo del programa Al igual que los proyectos, los programas disponen de procesos que desarrollan los aspectos más importes de su gestión. Estos procesos se agrupan en las siguientes áreas y que podemos ver explícitamente en la Figura 17: Gestión de las comunicaciones del programa. Gestión de la financiación del programa. Gestión de la integración del programa. Gestión de las adquisiciones del programa. Gestión de la calidad del programa. Gestión de los recursos del programa. Gestión de los riesgos del programa. Gestión del cronograma del programa. Gestión del alcance del programa.
45
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Figura 17: Procesos de apoyo en la gestión de un programa. Fuente: The Standard for Program Management 3th Edition.
La figura del director de programas Esta figura está separada de la del director de proyecto y ‐durante la duración del programa‐ trabaja con los 5 dominios de rendimiento definidos anteriormente e interactúa con cada director de proyecto para darles soporte y dirección. Por tanto, trabaja para asegurar que la estructura y los procesos globales del programa permitan al equipo del programa completar con éxito el trabajo e integrar los entregables de los proyectos con el producto o servicio que debe producir el programa. Por consiguiente, debe: Identificar stakeholders y comprender sus necesidades, expectativas y requisitos. Desarrollar un plan para la gestión e implicación de los stakeholders.
46
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
1.6.
Estándares existentes. Estado de la cuestión
Como se ha comentado en puntos anteriores el conocimiento en gestión de proyectos se materializa en las guías de conocimiento, estándares y en general marcos de trabajo (frameworks) que las diferentes asociaciones han desarrollado y van actualizando periódicamente para incluir las experiencias y lecciones aprendidas. También se puede encontrar metodologías concretas ‐también denominadas cuerpo de conocimiento (BOK body of knowldege)‐ que al contrario de las guías, son prescriptivas. En general, se pueden encontrar, por tanto: Estándares: la norma ISO/IEC Guide 2:2004 define una estándar como un documento establecido por consenso y aprobado por un entre reconocido, que proporciona debido a su uso común y repetitivo, normas, guías para el desarrollo de sus actividades. Y deben estar basados en resultados científicos consolidados, tecnología y experiencia con el objetivo de promocionar el beneficio común óptimo. Cuerpos de conocimiento BOK: (body of knowledge) contemplan un amplio espectro en lo relativo a competencias, procesos, técnicas y buenas prácticas en la gestión de proyectos. De hecho exponen cómo podrían realizarse las actividades de gestión de proyectos, dependiendo del tipo de proyecto, su complejidad y entorno. Su aplicación no es prescriptiva y el director de proyecto podrá seleccionar lo que considera más adecuado en cada momento. Además cada una de las área descritas puede ser analizada de forma independiente. Finalmente un BOK incluye apartados sobre las habilidades interpersonales de gestión que debería disponer el director de proyectos y también podría incluir un código ético. Bases competenciales en gestión de proyectos PMCB (project management competence baseline): consisten en los aspectos básicos para gestionar un proyecto, tales como las fases (planificación, organización, seguimiento y control de todos los aspectos de un proyecto), para alcanzar los objetivos de manera que se cumplan las especificaciones iniciales definidas en el triángulo clásico de plazo, coste y calidad. Metodologías en gestión de proyectos PMM: (project management methodology) proveen un marco integrado de procesos y actividades en las que se indican técnicas y herramientas para gestionar correctamente un proyecto desde el inicio hasta la finalización. Detalla y define qué tiene que hacerse en la gestión del proyecto, por quién y cuándo. También pueden incluir una serie de formatos y documentos así como los entregables de gestión necesarios. Normalmente una metodología es prescriptiva, es decir es obligatorio que se apliquen todas sus indicaciones si se quieres aplicar, de forma que si no se realiza alguna de ellas, no se estaría utilizando correctamente. Tampoco suelen incluir habilidades soft o interpersonales. En la Tabla 2: Clasificación de los modelos de gestión de proyectos más representativos., se pueden identificar las principales fuentes de conocimiento en gestión de proyectos. Además, han sido clasificadas en función de si se tratan de un estándar, cuerpo de conocimiento, metodología o base competencial. Nombre
Organización
Estándar
BOK
PMM
PMCB
Project Management Body of Knowledge PMBOK® PMI® 5th Edition
X
Software Extension to the PMBOK® Guide 5th PMI® Edition
X
Construction Extension to the PMBOK® Guide 3rd PMI® Edition
X
Government Extension to the PMBOK® Guide 3rd PMI® Edition
X
Managing Successful Projects with PRINCE2® 2009 AXELOS Edition
X
Nivel Gestión de Proyecto
47
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Directing Successful Projects with PRINCE2® 2009 AXELOS Edition
X
APM Body of Knowledge 6th edition
APM
X
ICB: IPMA Compentence Baseline v3.0:2006
IPMA
X
P2M Project Management for Enterprise Innovation PMAJ 3rd Edition
X
V‐Modell XT 1.4:2012
X
ISO 10.006:2.003 Quality management systems. ISO Guideline for Quality Management in Projects
X
ISO 21.500:2.012 Guidance on project management
ISO
X
AENOR UNE‐ISO 21.500:2.012
AENOR
X
BS6079‐1:2010 Guide to Project Management
BS
X
DIN 69901:2009‐01
DIN
X
Project Management ‐ Project Network Techniques; SIS Descriptions and concepts
X
V‐Modell
XLPM World class methodology for Projects v2.3
SEMCON
X
PRiSM Projects integrating Sustainable Methods
PRiSM™
X
RUP: Rational Unified Process
IBM
X
X
CMMI‐SVC: Capability Maturity Model Integration CMMI v1.3
Nivel gestión de programas y portfolios The Standard for Program Management 3rd Edition
PMI®
X
The Standard for Portfolio Management 3rd Edition
PMI®
X
MoP® Management of Portfolios 2011 Edition
AXELOS
X
MSP® Managing Successful Programmes 4th Edition
AXELOS
X
P3O® Portfolio, Programme and Project Office
AXELOS
X
Nivel gestión corporativa de proyectos OPM3® Organizational Project Management PMI® Maturity Model 3rd Edition
X
P3M3® Project Management Maturity Model 3rd AXELOS Edition
X
X
Gestión de proyectos ágiles SBOK™ A Guide to the Scrum Body of Knowledge
SCRUMstudy
Scrum Guide La guía de Scrum
Acrum Alliance®
PMI‐ACP® Agile Certified Practitioner
PMI®
X
PRINCE2 Agile® Agile Project Management
AXELOS
X
XP eXtreme Programing software development Extreme methodology Programing
X
X
Otros estándares relacionados con proyectos 48
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
PMI‐RMP® Risk Management Professional
PMI®
X
PMI‐PBA® Professional in Business Analysis
PMI®
X
PMI‐SP® Scheduling Professional
PMI®
X
Practice Standard for Earned Value Management PMI® 2nd Edition
X
Practice Standard for Project Configuration PMI® Management
X
Practice Standard for Work Breakdown Structures PMI® 2nd Edition
X
Practice Standard for Scheduling 2nd Edition
PMI®
X
Practice Standard for Project Estimating
PMI®
X
MoV® Management of Value
AXELOS
X
M_o_R Management of Risk: Guidance for AXELOS Practitioners 3rd Edition
X
X
ITIL® Practitioner Guidance
AXELOS
ISO 31.000:2.009 Gestión de riesgos
ISO
X
Tabla 2: Clasificación de los modelos de gestión de proyectos más representativos.
José María Nuñez Arraque miembro del comité técnico ISO/TC 236 “Project Management” y vocal de la Junta Directiva del capítulo PMI® de Madrid, en la jornada realizada el 13 de febrero de 2013 sobre “Las Certificaciones Profesionales y la Gestión/Dirección de Proyectos: la nueva ISO 21.500:2.012 de Project Management”, expone un resumen de las asociaciones, métodos o normas y sistemas más utilizados en la actualidad y que se reproduce en la Figura 18.
Figura 18: Esquema de organizaciones y métodos de gestión de proyectos representativos. Fuente: José María Nuñez Arraque.
Como se puede apreciar, también es posible obtener certificaciones profesionales emitidas desde las organizaciones o asociaciones, de forma que éstas homologuen y certifiquen sus habilidades y conocimientos sobre las diferentes metodologías promovidas por ellas. Se indican a modo informativo ya que no es objeto de este trabajo.
49
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
De las expuestas anteriormente, se va a profundizar en el PMBOK®, Éxito en la gestión de proyectos con PRINCE2® y la guía ISO 21.500:2.012. 1.6.1.
Guía buenas prácticas PMBOK®
1.6.1.1. Antecedentes El manual de buena prácticas PMBOK® (Project Management Body of Knowledge) es el documento que ha desarrollado PMI® [35], una de las mayores asociaciones de profesionales del mundo, con más de medio millón de miembros y personas certificadas en más de 185 países, y que tiene como objetivo identificar las mejores prácticas a aplicar en la gestión de proyectos de todo tipo y de diferentes sectores productivos. De hecho, es una organización sin ánimo de lucro que desarrolla y avanza la profesión de gestión de proyectos a través de estándares y certificaciones, comunidades colaborativas, un extenso programa de investigación, y oportunidades de desarrollo profesional, reconocida a nivel mundial. Actúa a nivel global y es la asociación generadora de influencia y opinión más importante en el área de la gestión de proyectos. Su sede central está localizada en los Estados Unidos de América. Está dividida en 5 zonas fundamentales; América, EMEA (Europe and Middle East, Africa), –donde se encuentra España‐ India, China y Asia Pacífico. El origen de PMI®, se remonta a 1.969, cuando dos profesionales Jim Snyder y Gordon Davis, se reunieron en un pequeño restaurante de Philadelphia, el “Three tres”. Esta reunión fue la culminación de varias anteriores habidas entre ellos, y al finalizar, concluyeron que era necesario la creación de una organización que promulgara la asociación entre project managers, y que al mismo tiempo permitiese la divulgación y discusión de información y de experiencias. Así, la primera reunión formal se produjo en el Instituto Tecnológico de Georgia (Atlanta) durante el mes de Octubre de ese mismo año. Y fue en ese momento cuando formalmente se constituyó PMI®. Al acto acudieron más de ochenta personas, y de él surgieron los que se consideran y conocen como “fundadores”, cuyos nombres son: James Snyder, Eric Jenett, Gordon Davis, A. E. "Ned" Engman y Susan C. Gallagher [104].
Figura 19: Miembros fundadores PMI®.
A partir de entonces su crecimiento ha sido exponencial; de hecho en la década de los 70 se creó el primer Capítulo (Chapter), y en 1.984 se realizó la primera certificación profesional del sector; PMP® (Project Manager Professional). También se empezó a editar el PMBOK® (Project Management Body of Knowledge), compendio de buenas prácticas en la gestión de proyectos, que desde entonces y con cada una de sus sucesivas ediciones revisadas (actualmente está vigente la 5ª de 2.013) [35], se ha convertido en un pilar básico de conocimiento para la gestión de proyectos.
Figura 20: Hitos más importantes en la historia de PMI®.
50
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
Es de facto, el cuerpo de conocimiento más aceptado a nivel internacional. De hecho, la consultora internacional PwC en 2.012 ha presentado los resultados de su estudio “Insights and Trends: Current Portfolio, Programme, and Project Management Practices The third global survey on the current state of Project management” [34] en que analiza la forma en cómo las empresas utilizan y sacan partido a las técnicas de project management. Según indica ésta, es de resaltar que la mayoría de las empresas que tienen adoptadas metodologías de gestión de proyectos, están basadas en PMI®, y a si se expone en el siguiente esquema:
Figura 21: Distribución del uso de metodologías de gestión de proyectos. Fuente: PWC.
1.6.1.2. Aspectos beneficios del PMBOK® en la gestión de proyectos Actualmente está en vigor la quinta edición del año 2.013. En el PMBOK®, se exponen las buenas prácticas en la profesión de gestor de proyectos, que son generalmente aceptadas. Cuando se habla de buenas prácticas, se considera que existe un acuerdo general de que aplicando las herramientas y técnicas descritas, las posibilidades de que se alcance el éxito del proyecto es potencialmente mayor. De hecho, en estos momentos está en fase de desarrollo la versión sexta. Pero ello no significa que se tiene que aplicar uniformemente en todos los proyectos, si no que el responsable del mismo debe determinar hasta qué grado es apropiado su implementación. Además de ello, en el PMBOK®, se aporta un vocabulario común para la profesión, lo que se considera esencial. Está disponible en once idiomas; inglés, árabe, chino, francés, alemán, italiano, japonés, coreano, portugués, ruso y español y es reconocido por ANSI (ANSI/PMI 99‐001‐2008, ISO, IEEE (IEEE 1490‐2011). De hecho, es un estándar reconocido en la profesión de gestión de proyectos, por lo que describe normas, métodos, procesos y prácticas. Es además un compendio de buenas prácticas en la gestión de proyectos, esto quiere decir, que las técnicas, herramientas de gestión y las habilidades descritas, están aceptadas por la generalidad de la profesión, como acciones que ayudan al éxito del proyecto. Así, hay que resaltar que en el PBMOK® no se describen ni todos los procesos ni herramientas existentes, ya que para que se incluyan deben estar ampliamente consensuadas por el sector. Ello es así porque habrán procesos o herramientas que no se apliquen por las siguientes causas:
Por estar incluidas en otros estándares o extensiones que también ha desarrollado PMI®. Sean excesivamente generalistas e imposibles de aplicar de forma individual a la gestión de proyectos.
El conocimiento que se describe en el PMBOK®, proviene de las experiencias que se generan en la profesión por sus profesionales, de forma que para que tenga valor real, es necesario que se actualice periódicamente con estas aportaciones, de ahí que cada cierto tiempo (entre 4‐5 años) PMI® edite una nueva edición del esta guía [35]. Cada proyecto es diferente Una de las características de un proyecto es que es único, por lo que otro aspecto a tener en cuenta, es que las buenas prácticas descritas en el PMBOK®, no se deben aplicar uniformemente a todos los proyectos con igual intensidad. Así, se deben aplicar y seleccionar las herramientas y técnicas adecuadas, dependiendo de su tipología y restricciones. Siendo el responsable del proyecto, (o la organización) el que debe decidir y determinar cómo hacerlo [35]. Además en este documento se promueve y establece un vocabulario común en la dirección de proyectos. De forma que al escribir los conceptos específicos, se fomenta la discusión y por tanto el avance de la profesión. Por tanto, PMI®, considera que el establecimiento de un vocabulario común es un elemento esencial de disciplina profesional. ¿Cómo se crea el PMBOK®? Para entender el alcance de la importancia y el interés que puede tener la guía de buenas prácticas que desarrolla PMI®, para un gestor de proyectos, hay que entender su proceso de creación. La clave está en que a lo largo 51
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
del periodo de maduración de una nueva versión, un comité de PMI®, se encarga de recoger todas las sugerencias, experiencias y lecciones aprendidas de numerosos project managers a lo largo de todo el mundo y en diferentes sectores y tipos de proyectos [35]. Así, del análisis realizado por parte de un grupo de expertos, se llega a un consenso sobre qué cosas funcionan bien y cuales mal, de forma que las técnicas y los procedimientos que funcionan bien, se añaden (o modifican) el estándar vigente, y de esta manera el nuevo texto, incluirá estas aportaciones. Como se observa, el PMBOK®, no se genera a partir de un marco teórico, diseñado por unos sesudos teóricos, sino que su origen se basa en la experiencia previa de otros profesionales que aportan su conocimiento, por lo que es una oportunidad de adquirir conocimiento sobre qué funciona de verdad en la gestión de proyectos [35]. 1.6.1.3. PMBOK® como base para el desarrollo de estándares El PMBOK®, es el documento fundamental sobre el que se desarrollan los demás estándares, tanto fundacionales, como los prácticos y extensiones [35]. Así, en las extensiones los procedimientos suelen ser mayores y más específicos en cada sector. Es importante resaltar que el PMBOK® analiza los proyectos de forma individual, por lo que si el objetivo es gestionar grupos de proyectos, es necesario ampliar la información, consultando los estándares específicos. Estructura En el PMBOK®, la gestión está orientada hacia los procesos, así se describen 47 procesos, clasificados en 10 áreas de conocimiento (coste, tiempo, calidad, recursos humanos, comunicación, riesgos, integración, aprovisionamiento, alcance y gestión de interesados) y 5 grupos de procesos (iniciación, planificación, ejecución, control y cierre), los cuales no hay que confundir con las fases del ciclo de vida de un proyecto. Estos 5 grupos de procesos son: iniciación, planificación, ejecución, monitorización y control, cierre, y relación es la que se muestra en la Figura 22:
Figura 22: Relación entre los 5 grupos de procesos del PMBOK®.
PMI®, establece 10 áreas de conocimiento en los que se desarrollan los puntos anteriores, Figura 23.
Figura 23: Las 10 áreas de conocimiento definidas por PMI®.
52
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
1.6.1.4. La triple restricción Según lo que se establece en el PMBOK® [35], gestionar un proyecto incluye normalmente: Identificar requerimientos o requisitos. Establecer, mantener y realizar comunicaciones activas, eficaces y de naturaleza colaborativa entre los interesados. Definir el alcance de las necesidades, intereses y expectativas de los agentes afectados por el proyecto (stakeholders), conforme se va planificando y llevando a cabo. Balancear y equilibrar las restricciones contrapuestas del proyecto como son al menos (no las únicas): alance (scope), calidad (quality), tiempo (schedule), presupuesto (cost), recursos (resources) y riesgo (risk).
La gestión de un proyecto se ve afectada por la búsqueda del equilibrio de tres de las diez áreas definidas por PMI®, y que los directores de proyecto estiman como clave. Es lo que se conoce como la triple restricción [35].
Figura 24: El equilibrio de la triple restricción.
Así, los proyectos deben generar sus entregables, en el plazo indicado, según el presupuesto estimado y con las características y calidad definidas. Asimismo, estas tres áreas están íntimamente ligadas, de forma que cualquier modificación de una de ellas afecta ‐al menos‐ a una de las restantes. De esta forma, puede concluirse que de la correcta gestión de estas tres dimensiones dependerá el éxito del proyecto y, por tanto, la satisfacción del cliente y del resto de los stakeholders. Dado que los proyectos, como ya se ha venido indicando anteriormente, se desarrollan en ambientes de incertidumbre, también se puede considerar una visión expandida del concepto de la triple restricción, incluyendo 3 áreas de conocimiento más, las denominadas seguros, a saber: la gestión de riesgo, la integración y la calidad. Las otras tres restantes, se denominan facilitadoras, ya que sin ser fundamentales para la gestión del proyecto, ayudan y apoyan y son necesarias para poder alcanzar sus objetivos [35]. 1.6.1.5. Estructura del PMBOK® Está compuesto por los siguientes componentes: El PMBOK®, está estructurado en cuatro Secciones [35]:
Sección I: el marco de referencia para la gestión de proyectos. Donde se tratan temas básicos sobre la gestión de proyectos, así como su marco conceptual. Está compuesta por dos capítulos. Sección II: la norma para la dirección de proyectos de un proyecto. Se desarrollan los 5 procesos de gestión de un proyecto (iniciación, planificación, ejecución, control y cierre). Hay un solo capítulo en esta sección. Sección III: las áreas de conocimiento de la dirección de proyectos.
Se exponen y desarrollan las 9 áreas de conocimiento. Para ello se utilizan también, 10 capítulos. En cada uno de ellos se analiza un área de conocimiento, siguiendo el siguiente esquema general:
53
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Se definen los procesos. Para cada uno de ellos, se enumeran: Los inputs (información y/o actividades previas necesarias). Tools o herramientas para poder desarrollarlos. Outputs o resultados esperados en cada proceso Sección IV: Anexos. Se incluyen 7 anexos y un glosario. o o
1.6.1.6. Procesos El PMBOK®, describe 47 procesos divididos en 5 grupos de procesos y 10 áreas de conocimiento, distribuidos de la siguiente forma resumida, en la que cada número indica el número de procesos que se definen en cada área y cada grupo de procesos [35], Figura 25. A continuación de identifican todos los procesos según la codificación que se usa en el PMBOK®.
54
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
Figura 25: Procesos del PMBOK® agrupados por áreas de conocimiento y grupos de procesos.
Los procesos de iniciación y planificación, se pueden considerar como virtuales [35] en el proyecto, ya que no ejecutan el proyecto, sino que definen tanto sus características, objetivos como los pasos para conseguirlos. De la misma forma, el resto de procesos se consideran de elaboración real. 1.6.2.
ISO 21.500:2.012
Como hemos indicado anteriormente, existen numerosas organizaciones privadas, pero de la necesidad de normalización en el uso y aplicación de las metodologías de gestión de proyectos, desde el punto de vista de la empresa, así como de la unificación de la terminología y lenguaje, surge la guía ISO 21.500:2.012. De hecho, han surgido diferentes iniciativas internacionales con el objetivo de crear un verdadero estándar de gestión de proyectos antes de la ISO 21.500:2.012. Así, el Global Project Management Forum, fue creado a partir de la iniciativa de David Pells. El Global 55
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Working Groups ‐liderado por Lynn Crawford‐, el Operational Level Coordination Initiative o el Global Alliance for Project Performance Standards lo han intentado y demuestran el interés y la necesidad de la creación de un estándar internacionalmente reconocido [105]. Se configuró un comité de trabajo denominado ISO/PC 236 como consecuencia del germen que supuso en septiembre de 2.011 el borrador de norma ISO DIS 21500 (Draft International Standard), Guide on Project Management y que finalizó sus actividades en Agosto de 2.012 cuando publicó el documento en inglés y francés. De hecho, este documento ISO es el primer estándar en dirección de proyectos consensuado internacionalmente y su implementación beneficia a profesionales y empresas que desarrollan sus actividades en varios países. El Comité estuvo formado por 37 países participantes, 15 países observadores y trabajo se desempeñó durante 5 años, hasta su publicación oficial en septiembre del 2.012. Los conceptos fueron apreciados y consensuados por más de 800 expertos internacionales de diversos países. A la hora del desarrollo y promoción de esta guía ISO, cabe destacar a varias figuras importantes en este proceso, como han sido los especialistas internacionales Miles Shepherd quien actuó como Presidente del Comité TC 236 y que además es Presidente del IPMA ‐ International Project Management Association (que anteriormente fue Director de la APM ‐ Association for Project Management) y Karl Best, quien actuó como Secretario del Comité TC 236 Gerente de Proyectos de Normas del PMI® ‐ Project Management Institute [106]. Así, tanto el BSI, como PMI jugaron un papel importante en el diseño de la norma, lo que indica la universalidad y consenso alanzado. Una vez publicada la Norma, varios países la adoptan como norma nacional, entre otros: Suecia SS‐ISO 21500, Austria ONORM ISO 21.500:2.012 o España UNE‐ISO21.500 entre otros [48]. Posteriormente se publica la norma en español, a través del Spanish Traslation Task Force formado por Argentina, Chile, España, Costa Rica y México.
La norma ISO 21.500:2.012 se focaliza en la Organización, PMBOK® y en el Project Manager y está basada en el PMBOK® cuarta edición, de la que comparte su enfoque y muchos de sus procesos [105]. Podemos encontrar otras normas ISO que soportan y complementan a ISO 21.500, como la ISO 10.006:2.003, la cual aporta directrices para la gestión de la calidad en los proyectos. La ISO 10.007:2.003, cuyo contenido orienta hacia una gestión de la configuración así como también en el ámbito de la calidad, y la ISO 31.000:2.009, en la que se contienen los más importantes principios y directrices sobre gestión de riesgos, completados por algunas normas específicas para algunos sectores. Además, es de interés para el conocimiento de esta área indicar que se está desarrollando un nuevo estándar internacional más amplio con un ámbito en proyectos, programas y portfolios. Se denominará ISO 21.502 Project, Programme y Portfolio Management estando siendo evolucionada por el comité ISO/TC 258 [107]. La norma ISO 21.500:2.012 tiene una estructura muy similar a la que se puede encontrar en el PMBOK®, definiendo en su caso 39 procesos que se distribuyen en 5 grupos de procesos y 10 Grupos de materias como se puede apreciar en el Figura 26 [108]:
56
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
Figura 26: Procesos de ISO 21.500:2.012 agrupados por grupos de materia y grupos de procesos.
Al igual que se puede observar en el PMBOK®, los grupos de procesos se repiten normalmente a lo largo del ciclo de vida del proyecto y en cada una de sus fases. De hecho, se van realizando de forma solapada y concurrente, interrelacionándose entre ellos continuamente, como se aprecia en las Figura 27Figura 29, desarrollados a partir de lo expuesto en dicha norma:
Figura 27: Relación de los grupos de procesos en ISO 21.500:3.012.
57
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
O más detalladamente:
Figura 28: Relación de los procesos. Fuente ISO 21.500:2.012.
También se pueden observar las interrelaciones entre los diferentes procesos, en el esquema denominado Quick Reference Card, desarrollado por Henry Portman.
Figura 29: Quick reference card. Fuente: Henny Portman. 58
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
1.6.3.
Éxito en la gestión de proyectos con PRINCE2®
1.6.3.1. Antecedentes PRINCE2® es el acrónimo de PRojects IN Controlled Environments. Es un método que desarrolló el gobierno inglés a través de la OGC (Office of Government Commerce) y que se gestó basándose en las buenas prácticas de proyectos desarrollados anteriormente, especialmente en el sector tecnológico, aunque en la actualidad, PRINCE2®, es un método generalista que se puede usar en todo tipo de proyectos y de sectores industriales [46]. PRINCE2® lanzó su primer estándar en 1.996, si bien lo hizo antes de que se produjeran varios eventos importantes los cuales se han recogió en la siguiente timeline, en la que aparecen los hitos temporales básicos de PRINCE2®. Se incluye, además, la revisión que sufrió en 2.009 cuando se actualizó el nuevo estándar que mantuvo la denominación original de PRINCE2® si bien se le añadió el concepto de refresh.
Figura 30: Evolución temporal de PRINCE2®.
En estos momentos la organización que se encarga de la difusión, coordinación y emisión de certificaciones, además de la generación de conocimiento del método y de otros asociados desde 2.013 es AXELOS (una unión entre OGC y la empresa CAPITA). Tal y como exponen en su página web [103] Axelos es una nueva empresa mixta, “creada por la Cabinet Office en nombre del Gobierno de Su Majestad (HMG) en el Reino Unido y Capita PLC para desarrollar el portfolio de las mejores prácticas incluyendo los estándares profesionales de ITIL™ y PRINCE2®. Nuestro objetivo: alimentar a las comunidades de las mejores prácticas, tanto en el Reino Unido y en una escala verdaderamente mundial, estableciendo un sistema innovador y de alta calidad incluyendo el aprendizaje continuo y que se ha co‐diseñado por y co‐creado por aquellos que lo utilizan”. El estándar PRINCE2®, está encuadrado en una estrategia de gestión del conocimiento en gestión de proyectos global, siendo la parte dedicada a la gestión propia del director del proyecto. Disponiendo dos estándares que describen la gestión de proyectos desde dos puntos de vista:
En el estándar Directing Succesfull Projects with PRINCE2®, se analiza el método desde el punto de vista del ejecutivo del proyecto. En el estándar Managing Succesfull Projects with PRINCE2®, se analiza el método desde el punto de vista del director del proyecto.
Figura 31: Esquema de la estrategia de gestión del conocimiento en gestión de proyectos de AXELOS.
Este estándar incluye las actividades de gestión del proyecto, no las tareas necesarias para desarrollar el trabajo especializado concreto para generar los entregables del proyecto. Además, es un método genérico, por lo que no está 59
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
especializado en ningún tipo de proyectos concretos. La planificación está basada en el desarrollo del producto y en experiencias anteriores de otros directores de proyectos que han desarrollado proyectos en diferentes sectores y de distinta complejidad y tamaño. De hecho, sirve como guía para responder a la pregunta: “¿Cómo lo hago?”. Que no incluye PRINCE2® Pero el método no incluye todos los aspectos del proyecto, por lo que, al ser un método genérico no contempla aspectos de gestión de industrias y sectores concretos. De la misma manera, tampoco se incluyen técnicas ni herramientas detalladas, sino que únicamente se nombran en algunos casos. Sólo se describen dos con mayor detalle: la técnica de revisión de calidad y planificación basada en productos. De igual forma no se incluyen las capacidades y habilidades soft (liderazgo, habilidades directivas, etc.) que necesariamente debe tener el director del proyecto. 1.6.3.2. Beneficios del uso de PRINCE2® Muchos son los beneficios del uso del estándar, y en su manual se describen en el punto 1.7, de los cuales se vienen a destacar los siguientes:
Prevé el reconocimiento explícito de las responsabilidades del proyecto. Hay una estructura definida para roles, responsabilidades, delegación, autoridad y comunicación. Está centrado en productos, definiendo lo que el proyecto entregará. Se basa en la “gestión por excepción”, de forma que se busca el uso eficiente del tiempo de los dirigentes de cada nivel de gestión. Se establece, por tanto, un marco claro de toma de decisiones. Asegura que los participantes centren su atención en la viabilidad del proyecto según los objetivos del Business Case, más que en la terminación del proyecto como un fin es sí mismo. Define una estructura de informes completa. Hay una definición clara de los planes a desarrollar a lo largo del ciclo de vida del proyecto. Establece las fases mínimas de un proyecto y qué acciones y autorizaciones se debe producir para pasar de una fase a la siguiente [46].
1.6.3.3. La actuación del director de proyecto en PRINCE2® No hay que olvidar que para desarrollar un proyecto hay que disponer de un plan sobre el que controlar y comparar el trabajo real que se va ejecutando. Su objetivo es conseguir que todo salga según lo previsto y para ello debe disponer de un plan y detectar las posibles desviaciones en lo ejecutado y, sobre todo, en las previsiones del trabajo pendiente de forma tal que se puedan tomar las medidas correctoras o preventivas necesarias. La función del director de proyecto no es la de realizar el trabajo especializado, sino que su objetivo es delegar el mismo a los equipos de especialistas. Si bien, su misión y responsabilidad es asegurar que el trabajo realizado siga el plan. Por lo que una de las habilidades fundamentales de un director de proyectos es la de realizar una delegación efectiva. Pero no es suficiente tan sólo con traspasar la responsabilidad a los diferentes equipos de trabajo o team managers, sino que se debe realizar ejerciendo control. En general, las fases a seguir para conseguir una delegación efectiva son, Figura 32 [46]:
Figura 32: Pasos para una delegación efectiva. 60
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
Así, la delegación efectiva parte de disponer de un plan suficientemente definido y de una forma estructurada ir asignando el trabajo del proyecto. Además, conforme éste se va desarrollando por los team managers, el director del proyecto debe ir monitoreando y controlando que el trabajo realizado coincide con el planificado. De forma que se puedan detectar desviaciones lo antes posible y así desarrollar acciones y opciones para recuperar los objetivos ejerciendo control sobre los mismos. Pudiendo ser necesario re‐planificar el plan para conseguirlo.
Figura 33: Pasos para una delegación efectiva en PRINCE2®.
Funciones detalladas del director del proyecto según PRINCE2®:
Desarrolla el plan de proyecto. Debe realizar el seguimiento del proyecto para comprobar que el trabajo se ajusta al plan. Debe ejercer control y tomar las medidas necesarias para alcanzar los objetivos. También debe trasmitir la información precisa y a tiempo a sus superiores para que éstos puedan tomar las decisiones adecuadas. Desagrega el proyecto en paquetes de trabajo, cuya producción delega en los team managers, lo que muestra la filosofía delegativa del estándar. Analizar y da respuesta a los posibles asuntos o problemas que puedan surgir en el propio desarrollo del proyecto. Y fundamentalmente debe controlar las 6 variables o aspectos del rendimiento de un proyecto, como son los costes, el tiempo, la calidad, el alcance, el riesgo y los beneficios. De hecho director del proyecto debe comprender claramente el propósito del proyecto como una inversión y asegurarse de que aquello que el proyecto entregue sea consecuente con el logro del beneficio deseado. Por lo que es fundamental que el PM sea plenamente consciente de la misión y justificación del mismo
1.6.3.4. Estructura de PRINCE2® PRINCE2® se estructura en cuatro conceptos fundamentales: principios, temáticas, procesos y la adaptabilidad al entorno. Así en el Éxito en la gestión de proyectos con PRINCE2® (Managing Successful projects with PRINCE2®) [46] se sigue esta estructura, además de añadir diferentes anexos para una mejor comprensión del mismo. Así, estos conceptos son:
Principios: son obligaciones y buenas prácticas que se deben aplicar para gestionar proyectos bajo el método PRINCE2®. De hecho, si no se aplican todos, no se estaría desarrollando un proyecto con PRINCE2®. Las temáticas describen los aspectos que se deben abordar continuamente y en paralelo a lo largo de todo el proyecto. Los procesos describen los pasos que se siguen a lo largo del ciclo de vida del proyecto. La adaptación al medio: es fundamental para que el método funcione que los procesos y las temáticas descritas se adapten al entorno y las características concretas del proyecto. De forma que para sacar el máximo partido a PRINCE2® (y afirmar que un proyecto se gestiona bajo su paraguas) no se pueden eliminar aspectos del mismo, pero sí se puede ajustar y particularizar, como veremos en puntos siguientes.
61
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
En la Figura 34 se pueden ver cada uno de los conceptos y que posteriormente a lo largo de la investigación van a ser analizados.
Figura 34: Los tres sietes de PRINCE2®.
Principios El hecho de que PRINCE2® pueda ser aplicado a cualquier tipo de proyecto ‐independientemente de su tamaño y complejidad‐ es porque se basa en la aplicación obligatoria e inexcusable de unos principios, de forma que si un proyecto no es fiel a ellos, no estará siendo gestionado con PRINCE2®. Estos principios son:
Justificación comercial continua. Aprender de la experiencia. Roles y responsabilidades definidos. Gestión por fases. Gestión por excepción. Enfoque en los productos. Adaptación para corresponder al entorno del proyecto.
Temáticas Las temáticas de PRINCE2®, describen aspectos de gestión del proyecto que se deben abordar continuamente. Para una mayor comprensión sobre el objetivo concreto que se busca, cada uno de ellos responde a una pregunta clave a la hora de gestionar el proyecto, como se expone en la Figura 35:
62
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
Figura 35: Las preguntas a las que responden las temáticas de PRINCE2®.
Procesos Los procesos agrupan las actividades principales a realizar a lo largo del proyecto según PRINCE2®. Los procesos los podemos identificar en el desarrollo progresivo del proyecto en la Figura 36 [46]:
Figura 36: Visión global de los procesos de PRINCE2®.
Listado de actividades (procesos) en PRINCE2® Como se ha comentado en anteriores puntos, en PRINCE2® se definen 7 procesos que serían análogos a los grupos de procesos y en cada uno de ellos se definen las actividades, que se podría asimilar a los procesos en el resto de enfoques analizados, por lo que en lo que respecta a esta investigación y al desarrollo del MGIP, se considerarán de esta forma
63
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Puesta en marcha de un proyecto SU (starting up a project) 12.4.1 Nombrar al ejecutivo y al project manager. 12.4.2 Registrar lecciones anteriores. 12.4.3 Diseñar y nombrar el equipo de gestión del proyecto. 12.4.4 Preparar el business case preliminar (lo crea el ejecutivo). 12.4.5 Seleccionar el enfoque del proyecto y crear el expediente de proyecto. 12.4.6 Planificar la fase de inicio. Dirección de un proyecto DP (direct a project) 13.4.1 Autorizar el inicio. 13.4.2 Autorizar el proyecto. 13.4.3 Autorizar un plan de fase o de excepción. 13.4.4 Proporcionar dirección ad hoc. 13.4.5 Autorizar el cierre del proyecto. Inicio de un proyecto IP (initiate a project) 14.4.1 Preparar la estrategia de la gestión del riesgo. 14.4.2 Preparar la estrategia de la gestión de la configuración. 14.4.3 Preparar la estrategia de la gestión de la calidad. 14.4.4 Preparar la estrategia de la gestión de la comunicación. (la última que se hace). 14.4.5 Establecer los controles del proyecto. 14.4.6 Crear el Plan de Proyecto. 14.4.7 Perfeccionar el BC. 14.4.8 Preparar la documentación de inicio del proyecto. Control de una fase SC (stage control) 15.4.1 Autorizar un paquete de trabajo. 15.4.2 Revisar el estado del paquete de trabajo. 15.4.3 Recibir el paquete de trabajo completado. 15.4.4 Revisar el estado de la fase. 15.4.5 Informar sobre el desarrollo. 15.4.6 Registrar y examinar las cuestiones y riesgos. 15.4.7 Presentar excepciones relativas a cuestiones y riesgos. 15.4.8 Rectificar. Gestión de la entrega de productos PD (product delivery) 16.4.1 Aceptar un paquete de trabajo. 16.4.2 Ejecutar un paquete de trabajo. 64
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
16.4.3 Entregar un paquete de trabajo. Gestión de límite de fase SB (stage boundary) 17.4.1 Planificar la fase siguiente. 17.4.2 Actualizar el plan de proyecto. 17.4.3 Actualizar el B.C.D. 17.4.4 Informar sobre el final de fase. 17.4.5 Elaborar un plan de Excepción. Cierre de un proyecto PC (project clousure) 18.4.1 Preparar el cierre planificado. 18.4.2 Preparar el cierre prematuro. 18.4.3 Entregar los productos. 18.4.4 Evaluar el proyecto. 18.4.5 Recomendar el cierre del proyecto. 1.6.4.
Otras asociaciones en gestión de proyectos
Además de las tratadas en este trabajo, se considera apropiado exponer dos de las asociaciones que también son relevantes en la gestión de proyectos, como son: IPMA: International Project Management Association Como se indica en su propia website, en 1.964 Pierre Koch, Dick Vullinghs y Roland Gutsch crearon un grupo de discusión y debate sobre el uso de diferentes técnicas de gestión de proyectos, liderado por Yves Eugene que pertenecía a AFIRO (Association Française d´Informatique et de Recherche Opérationnelle) y que denominaron INTERnational NETwork: INTERNET. En 1.965 este grupo fundó el IMSA (International Management System Association) que era independiente de cualquier empresa y se localizó en Suiza. A partir de este momento fueron realizando diferentes actividades y participando en distintos congresos hasta que en 1.996, en el que se celebró en París se modificó el nombre al actual [109]. No han desarrollado un cuerpo completo de conocimiento sino se han centrado en las habilidades y competencias en gestión de proyecto que deben de disponer los directores. ICB: IPMA Competence Baseline [110]. Página web: http://www.ipma.world/ APM Association for Project Management Es una asociación inglesa y es allí en donde tiene más influencia e implantación. Fue fundada en 1.972 a partir de la sus orígenes como INTERNET UK una rama local de lo que sería hoy en día IPMA, tal y como se ha indicado en el punto anterior [111]. Han desarrollado un cuerpo de conocimiento en gestión de proyectos APM Body of Knowledge 6th edition [112]. Página web: https://www.apm.org.uk/ AFITEP Association Francophone de Management de project
Es una asociación creada para los directores de proyectos francófonos. Emite las certificaciones de gestión de proyectos en Francia. Página web: http://www.afitep.org/
65
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
AEIPRO Asociación Española de Ingeniería de Proyectos Se considera adecuado exponer las asociaciones españolas más representativas en el área de la gestión de proyectos. En concreto, AEIPO es una organización sin ánimo de lucro que se formó en el año 1.992. Sus objetivos son el ser medio para una comunicación y cooperación intensa entre sus miembros; posibilitar la actualización de los expertos en los distintos campos de Ingeniería de proyectos; detectar y definir necesidades para la correcta gestión de proyectos. Página web: http://www.aeipro.com/index.php/es/ AEDIP Asociación Española de Dirección Integrada de Proyecto Es la asociación patronal de las empresas de gestión de proyectos dedicadas al sector de la construcción. Página web: http://aedip‐project‐management.com/ Metodologías ágiles También existen diversas organizaciones que se focalizan en el desarrollo de proyectos a través de metodologías ágiles, como Scrum. A modo informativo, ya que esta área queda fuera de este trabajo, se indican las más representativas:
Scrum Alliance. https://www.scrumalliance.org/ Scrum.org. https://www.scrum.org/ ScrumStudy. http://www.scrumstudy.com/ Agile Alliance. https://www.agilealliance.org/
1.6.5.
Modelos y software relacionado con la gestión de proyectos
La complejidad a la hora de gestionar la información generada en un proyecto y la necesidad de control sobre las actividades del mismo, obligan a manejar una gran cantidad de datos, informes y registros. Este hecho obliga a usar sistemas automatizados que permitan realizar una gestión integral y eficiente, evitando la introducción manual de datos de forma repetida y la realización de tareas recurrentes que no aporten valor [113]. Así, la inclusión de las nuevas tecnologías es un factor fundamental para la buena gestión de proyectos y es una herramienta que, incluso, se identifica como buena práctica en el PMBOK® cuando se plantea la gestión de la información (de hecho, se considera que los PMIS (project management information systems) o los sistemas de gestión de la información que dispone cada organización es parte de los factores ambientales de la empresa (FAE)). Ello denota la importancia que tiene hoy en día en la gestión de proyectos el disponer de herramientas que ayuden a manejar la gran cantidad de información en términos de gestión que genera un proyecto y que estos datos estén disponibles en el formato adecuado y en momento preciso para que sirva como base de la toma de decisiones por la empresa. Por lo que en esta tesis se considera oportuno incluir un capítulo en el que se identifiquen los aspectos clave relativos a lo expuesto anteriormente. 1.6.5.1. TIC´s en gestión de proyectos; herramientas de software Las prácticas tradicionales de gestión de proyectos han ido evolucionando a lo largo del tiempo conforme los requerimientos para gestionar y controlarlos se han ido incrementando, pero sin embargo con los avances de las nuevas técnicas y las TIC, se ha visto que las prácticas tradicionales son insuficientes. [114]. No obstante ello y a pesar del éxito en la gestión alcanzado por las tecnologías de la información, continúa siendo un objetivo inalcanzado y un reto para muchas organizaciones [115]. Si bien, en una encuesta realizada a 240 miembros de PMI® por Liberatore end Pollack‐Johnson [116], se indica que en lo relativo a las empresas y organizaciones que usan metodologías de gestión de proyectos, las que más tiempo han venido usándolas han sido las de construcción e ingeniería. Además, en la misma encuesta se arrojan interesantes resultados como: 66
Se usarán aplicaciones software más complejas completas heavy, cuanto más experto y/o trabajo se haya realizado con técnicas de gestión de proyectos. Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
El nivel de desarrollo del software utilizado por un gestor de proyectos, está muy influenciado por: Número de actividades de proyecto tipo. Tamaño de la organización. Extensión en el uso de software. Dentro de las diferentes tipologías de software, se concluye que más del 80% de los profesionales prefieren los que permitan planificar y monitorizar, sobre con los que sólo se pueda planificar.
Así, según indica el Construction Financial Management Association (CFMA) en la encuesta del año 2.010 “Information Technology Survey for the Construction Industry” [117], el 82% de las empresas del sector en EEUU usa u software especializado. El uso de software de gestión de proyectos tuvo un incremento exponencial en la década de los 80´s con la aparición y generalización del uso del PC entre los profesionales. Siendo a mediados de los años 90´s cuando el mercado del software de dirección de proyectos alcanza un alto nivel de uso, pudiéndose incluso hablar de saturación [116], estando en la actualidad completamente generalizado. De hecho, una encuesta indica que, a modo de ejemplo, los ingenieros industriales utilizan este tipo de herramientas al menos el 80% del colectivo [118]. Necesidad de aumentar la eficiencia Con el incremento de competencia en el sector, lo márgenes de beneficio se han reducido radicalmente, y por tanto la permisividad del error, no existe. Así, la forma de mejorar la eficiencia de las operaciones tanto en los procesos como operaciones de construcción, pasa por la utilización de software adecuado que integre todos los procesos [119]. Conforme las organizaciones se han ido convirtiendo en más horizontales, más trabajo es asignado y delegado a los equipos de gestión de proyectos. De ahí, que en estos momentos se plantea como necesario la interacción y el trabajo multidisciplinar entre técnicos IT, que desarrollen las herramientas tecnológicas adecuadas y los gestores técnicos tradicionales que las van a usar, y que son pieza clave en la determinación de requisitos, utilidades y usabilidad de las mismas. Además, la eficiencia, en proyectos de construcción y urbanismo se basa en poder acceder a la información de forma inmediata y segura desde cualquier lugar. De forma que como indica Brian Sommer, presidente de Vital Analysis, compañía de investigación tecnológica, “gestores de proyectos aislados ya no van a funcionar” y “la mejora de la eficiencia y el ajuste de los procesos que se puede conseguir en las operaciones a través de uso de aplicaciones integradas está siendo reconocido”. Así, el modelo de trabajo del gestor aislado, no es, según según se considera una forma adecuada de operar y el uso de las TIC´s puede ayudar a superar esta circunstancia [116]. El factor de conectividad Significa que la colaboración interfuncional es un factor clave, ya que los gestores de proyectos, localizados bien en el punto de producción (site managers) o en sus despachos profesionales pueden trabajar estrechamente con sus colegas situados en localizaciones remotas. De la misma forma, los proyectos inmobiliarios, de construcción o urbanismo, necesitan de multitud de documentación para su desarrollo, lo que hace totalmente inviable su trasporte físico y en cierto modo hasta su archivo en formatos tradicionales de papel. Esta información procede principalmente de:
Normativa de entidades públicas (ayuntamientos, delegaciones de gobierno, direcciones autonómicas, diputaciones, ministerios, etc.). Proyectos técnicos. Información de gestión generada por el propio proyecto. Documentación gráfica (fotografías).
Así, la digitalización de la información se está produciendo de forma masiva, y el paso siguiente necesario es el de la estandarización de la organización de dicha información, de forma que se pueda localizar fácil y ordenadamente. Así, implementando sistemas de acceso remoto, no sólo de comunicación entre los distintos agentes, como se ha señalado anteriormente, sino también para al objeto de visualizarlos y en cualquier momento poder gestionar toda la información relevante y necesaria del proyecto, sin duda reduce tiempos y aumenta por ende la producción. Ello, además permite y facilita la toma de decisiones in site, es decir, en el lugar y el momento en que son necesarias, sin aplazar las mismas por falta de documentación.
67
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Herramientas de software para la gestión de proyectos Se han desarrollado múltiples soluciones para gestionar la complejidad de los proyectos y la gran cantidad de datos y variables que se deben tener en cuenta para controlar adecuadamente el proyecto. De hecho, existen soluciones genéricas que dan respuesta y permiten gestionar proyectos tanto de metodologías ágiles como predictivas y otros que se centran en una u otra. En general suelen ser genéricos, de forma que hay que realizar una labor de adaptación de los mismos a los procesos o modelos elegidos. La tendencia, como se puede observar, es trabajar en la nube o cloud computing. Y en este modelo los puntos más importantes para que las herramientas funcionen correctamente son:
Gestión de las soluciones. Disponer de una única herramienta de gobierno de toda la plataforma se convierte en casi imprescindible para poder tener el control de todas las soluciones así como su gestión. Herramienta de gestión. Esta herramienta ha de permitir la gestión; el desarrollo mediante SDK de las plataformas o su integración con API´s harán y facilitaran la capacitación de la herramienta. Si bien, controlar toda la plataforma con una herramienta puede convertirse en inviable, sí tener una gran parte bajo esta cobertura facilitará a los CIO´s el aporte al negocio. Usuarios. Los usuarios, no quedan exentos de las soluciones o de la herramienta, siendo importante el poder flexibilizar los servicios para ellos, siendo uno el acceso seguro y los privilegios de seguridad.
Consiguiendo unificar el entorno y la gestión de usuarios y plataforma mediante una herramienta, se conseguirá mejorar la experiencia y productividad de los mismos, dando en un grado de control ese autoconsumo para usuarios, que les permita explotar al máximo la plataforma para mejorar en su día a día. Principales herramientas tecnológicas de gestión de proyectos Siguiendo la tendencia del cloud computing, se observa como los programas de gestión de proyectos tradicionales, así como los nuevos fabricantes y startups dirigen sus esfuerzos en ofrecer soluciones en la nube. Estas, además, están cada vez más orientadas a la colaboración social. Esto se puede observar en cómo las principales empresas fabricantes ofrecen en la actualidad la posibilidad de trabajar en la nube al 100% o en una parte del contenido. Con esta evolución de los programas de gestión de proyectos se busca incluir a todos los interesados en el proyecto como usuarios, o sus diferentes niveles de acceso, pero que sean capaces de interactuar, intercambiar información y conocer en tiempo real la situación del proyecto. Por otra parte, el desarrollo de las metodologías ágiles y tradicionales han llevado a los diferentes fabricantes a integrar en sus soluciones (originarias de alguna metodología) el resto de metodologías para ser compatibles con las soluciones que se encuentran actualmente en las empresas, como es el caso del programa JIRA de Atlassian que es un programa de solución ágil que decide integrar metodologías tradicionales para poder satisfacer las necesidades del mercado.
Satisfacción
Presencia de MK
Alcance
Tiempo
Costo
Reportes
Programas
Así, en Tabla 3 se pretenden exponer las herramientas con mayor difusión, teniendo en cuenta la satisfacción de sus usuarios, presencia en el mercado, además de haber identificado sus principales características. Se ha generado utilizando datos del grid scoring method [120], y otros obtenidos de la información comercial de los diferentes productos.
1
Microsoft Project
Tradicional
880.000
22.000.000
56
74
N
S
S
S
‐
2
Atlassian (JIRA)
Ambas
23.000
30.000.000
90
69
S
S
N
S
S
3
Podio
Ambas
500.000
2.500.000
24
67
N
S
N
N
N
4
Wrike
Tradicional
551.090
1.227.566
98
58
N
S
S
S
S
5
Basecamp
Ambas
285.000
15.000.000
89
45
N
S
N
N
N
6
Teamwork
Ambas
374.818
2.300.000
61
28
S
S
S
S
S
7
Smartsheet
Tradicional
100.000
1.500.000
51
45
N
S
S
S
S
8
Freedcamp
Ambas
340.000
540.000
‐
‐
N
S
N
N
‐
9
Trello
Ambas
26.000
1.700.000
98
52
N
S
N
N
N
Nº
68
Proveedor
Metodología
Clientes
Usuarios
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
10
VersionOne
Ágil
50.000
1.250.000
‐
‐
S
S
S
S
S
11
Assembla
Tradicional
80.000
1.000.000
‐
‐
N
S
N
N
N
12
Mavelink
Tradicional
50.000
750.000
80
48
S
S
S
S
S
13
Project Manager
Tradicional
87.409
409.532
75
70
S
S
S
S
S
14
Asana
Ambas
40.000
400.000
88
58
N
S
N
N
N
15
Zoho Porjects
Ambas
20.000
1.200.000
48
56
N
S
S
S
S
16
Redbooth
Ambas
6.000
901.000
‐
‐
S
S
N
N
N
17
IMeet Central
Ambas
2.200
650.000
‐
‐
N
S
S
S
S
18
Intervals
Ambas
30.000
200.000
‐
‐
N
S
S
S
S
19
TeamPulse
Ambas
6.700
10.000
‐
‐
N
S
N
S
S
20
Planbox
Ambas
400
75.000
‐
‐
N
S
S
S
S
21
Talaia
Ambas
‐
‐
‐
‐
N
S
S
S
S
22
SAP
Ambas
‐
‐
‐
‐
S
S
S
S
S
23
Redmine
Ambas
‐
‐
42
6
S
S
S
S
S
24
Clarizen
Ágil
‐
‐
70
44
N
S
S
S
S
25
Bitrix24
Ambas
‐
‐
80
60
N
S
N
N
S
Tabla 3: Comparativa de los principales herramientas de software de gestión de proyectos.
Seguidamente, se ha desarrollado un gráfico (Figura 37) que muestra el posicionamiento de los distintos programas dependiendo de su presencia de marketing, satisfacción del cliente y número de usuarios en el que se puede apreciar la situación relativa entre ellos.
Figura 37: Posicionamiento de las herramientas de software.
69
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
1.6.5.2. Análisis de cloud computing Debido a la importancia que se percibe respecto a la implementación del cloud computing en el uso de herramientas de gestión de proyectos, se considera interesante y relevante ampliar este concepto en este punto. De hecho, el termino de cloud computing, que se refiere a la transición de la información hacia la nube, empezó a ser relevante poco antes del 2.010, y ha continuado su imparable evolución hasta alcanzar la fase de madurez actual, logrando conseguir una oferta de soluciones y servicios variada, que cubre un gran abanico de necesidades. Hoy en día ya es parte de la oferta tecnológica que pretenden usar todas las compañías, como parte de su definición estratégica, por su versatilidad, modularidad, flexibilidad, agilidad y ahorro de costes. Sin embargo, empieza a ser una necesidad más que una diferenciación. Siendo este avance y especialización en el mercado de las soluciones cloud un conjunto de soluciones o incluso la posibilidad de los mundos híbridos o integrados entre soluciones. Estas soluciones en la nube permiten esta interacción de entornos o integración mediante API’s, aportando la integración solicitada para cubrir las necesidades requeridas. El tener este abanico de posibilidades disponible, hace que no exista una solución única que dé respuesta a todas las necesidades, aunque sí aparecen ya soluciones de un mismo fabricante integradas de forma nativa, como por ejemplo el Office365 + Azure + Dynamics NAV. Así, cada empresa escoge en base a sus necesidades, la solución que mejor se adapta a ella. L o que nos indica la tendencia de mercado, y los recientes estudios sobre la nube, es que la transición e hibridación es una realidad en más de un 50% de las compañías. Antecedentes El uso de tecnologías de cloud computing o computación en la red, es el resultado lógico de la evolución de la interrelación de tres factores; el usuario, el ordenador/computadora o equipo y el software que utiliza. Hasta ahora, el binomio máquina‐aplicación ha sido indisoluble. En el inicio de la aparición de las computadoras, el acento estaba puesto en la creación de una máquina en la que se integrase una aplicación concreta, para posteriormente, pasar a tener más importancia el software desarrollado, independientemente de la máquina, que debería tener al menos la capacidad para poder utilizarlo. La filosofía del cloud computing, intenta liberar las restricciones anteriormente citadas, para dar un salto adelante, donde la aplicación está localizada en servidores autónomos e independientes al usuario, de forma que acceda a ellos a través de internet. En realidad es una consecuencia lógica y esperable de la irrupción en el mundo de la gestión técnica de las nuevas tecnologías de información y comunicación, en concreto la universalización del uso de internet y los teléfonos y otros terminales (tabletas electrónicas, ordenadores portátiles, teléfonos inteligentes,…) que permiten el acceso móvil a la red. Con la irrupción de la tecnología web, y la generalización del uso de Internet y las redes sociales globales, la estrategia de las empresas tanto desarrolladoras de software como de hardware pasa por desarrollar sus productos de forma on line, es decir, que para que pueda funcionar una aplicación determinada, no sea necesario instalarla en la máquina de cada usuario, sino que el respaldo tecnológico está centralizado y localizado en sus servidores y los usuarios acceden a él a través de la red de internet y mediante claves y autorizaciones adecuadas. Así, el cloud computing es el siguiente paso natural en la evolución de la demanda de productos y tecnología on line. En general, se basa en el uso de recursos virtuales [121]. De hecho se puede hablar de ciberinfraestructura. Según Brian Hayes [122] los programas informáticos están siendo barridos de los escritorios de los ordenadores de los PCs y de los servidores de las empresas y se están instalando en the compute cloud. Ello hace que se esté produciendo un movimiento en la geografía de la computación. Y este cambio afectará ‐y ya lo está haciendo‐, a todos los niveles de computación. Se basa en décadas de investigación y desarrollo en áreas tales como virtualización, distribución de la programación, networking y servicios de software a través de la red de internet. Además, el concepto de programación a través de arquitectura orientada al servicio (service‐oriented architectura‐ SOA), es base para comprender el espíritu del desarrollo de aplicaciones en línea, ya que la carga tecnológica recae en la empresa que propone el uso del software, teniendo siempre el foco en las necesidades del usuario. De hecho, la parte más importante en una programación cloud es el usuario, así el valor de la solución final desarrollada va a depender de cuánto es capaz de ajustarse a los requerimientos y necesidades del mismo [123]. Las 3 Revoluciones hacia el cloud computing Cuando surgieron los primeros ordenadores personales, se produjo la segunda revolución, haciendo que se liberasen del control sobre las aplicaciones que ejercía un ordenador central aislado en un edificio y del que se servían los usuarios, pero siempre bajo su paraguas. (La primera revolución fue la creación de ordenadores centrales que dan 70
Autor: Ángel Nájera Pérez
Parte I – Aspectos preliminares
soporte a una red cerrada interna). Así, ya era posible instalar aplicaciones de software en cada uno de las máquinas de los clientes. Los usuarios eran los propietarios de su entorno de computación [124], eligiendo las aplicaciones que mejor se ajustasen a sus necesidades y gustos personales. Esta forma de trabajar hacía que los usuarios de los ordenadores estuvieran aislados en gran medida, lo que no coadyuva a mejorar el rendimiento de los equipos ni la intercomunicación entre ellos. Además una vez se ha producido la instalación, el usuario debe estar atento a las actualizaciones que el fabricante de software va aplicando a su producto. Así, la tercera revolución es la computación en la nube y la liberación de las aplicaciones en el escritorio del ordenador. Los antecedentes podemos decir, se surgen a partir de la colaboración entre IBM y Google, que supusieron el anuncio por el primero, de Blue Cloud. Aunque el primer fabricante proveedor de servicios de este tipo fue salesforce.com fundada en 1.999. Su slogan fue “No software!”. En la actualidad hay numerosos ejemplos en software de todo tipo, podemos indicar: google docs, Amazone, Buzzword,… Y no se cree que vaya a suponer un fenómeno puntual sino que se estima que en los próximos años, las soluciones basadas en esta tecnología sean el mayor vehículo para la distribución de información, tanto para el uso individuales como para el de las organizaciones, por ejemplo: aplicaciones de software, servicios basados en web, programación desktop personal y profesional, programación de alto rendimiento [121]. Espíritu web 2.0 La aparición de la web 2.0 como evolución de la forma tradicional de utilizar Internet, ha inspirado la concepción de esta investigación en gran medida, ya que se considera que el conocimiento sobre cualquier concepto o sobre un activo de suelo, por ejemplo, va a ser más enriquecedor si somos capaces de involucrar y hacer intervenir en él a todos los agentes adecuados. De forma que, si se presenta una plataforma tecnológica que permita que los distintos agentes accedan e interactúen con la información, generando un diálogo entre ellos, sin duda el conocimiento y la generación de ideas se incrementará notablemente. Así, esta investigación asume como suyo el espíritu colaborativo y generador de relaciones (networking) que la red 2.0 fomenta. Análisis de los puntos fuertes y ventajas del cloud computing De lo dicho anteriormente se desprende que la adopción de modelos de gestión basados o que estén disponibles bajo cloud computing presentan numerosas e importantes mejoras sobre los sistemas tradicionales, tales como:
Acceso remoto. Movilidad y portabilidad. Actualizaciones inmediatas. Puede gestionar o dar servicio a un gran número de usuarios de diferente perfil, desde básico hasta muy sofisticado [125]. Puede generar contenidos muy diversos de calidad y de alto rango, ya que permite acceder e interactuar a múltiples usuarios y/o autores [125]. Trabajo on line multiagente. Flexibilidad. La tecnología necesaria para su uso por el usuario se reduce [121]. Estandarización de los procesos y captación de la información, ya que se trabaja sobre formatos (templates). El mantenimiento de los sistemas corre a cargo de la empresa que ofrece el servicio.
Todas estas mejoras, sin duda hacen aumentar la productividad y eficiencia de la gestión si se comparan con los métodos tradicionales, basados en modelos estáticos y aislados. Posibles problemas en el uso de cloud computing. Una vez determinadas las ventajas más importantes de la utilización de esta metodología, cabe analizar y determinar los aspectos que presentan debilidades, de forma que se puedan tomar las medidas correctoras o planes de contingencia adecuados.
Seguridad. Es uno de los mayores retos y el aspecto quizás que más importe a un usuario. La NC Secure Open Systems Initiative está desarrollando un protocolo para garantizar que los datos no se pueden perder no liberar en ningún caso y sin la autorización del propietario de los mismos. Confidencialidad y privacidad. Se debe asegurar que nadie tiene acceso a la información y datos de la empresa. 71
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Pérdida de control sobre la información. Respecto a la propiedad de la información pueden surgir dudas sobre la custodia de información sensible de una organización, ya que al no estar alojada en los servidores y/o archivos de la compañía, ésta no dispone de control total para disponer de ella o evitar que cualquier organismo pueda acceder a ella por cualquier medio. No es fácil demostrar que el retorno de la inversión realizada (return on investment ROI) por los usuarios para adquirir una aplicación en entorno cloud computing, es superior a una basada en tecnología tradicional. Confianza en el sistema.
72
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
2.
Parte 2: El modelo de gestión integrada de proyectos
2.1.
Introducción
La gestión por proyectos es una gestión por procesos, tal y como se ha expuesto en los métodos y cuerpos de conocimiento descritos anteriormente. Así, la base fundamental de un modelo de gestión de proyectos debe ser el establecimiento de un mapa de procesos que creen predictibilidad y definan con detalle cómo se comportará un proyecto a lo largo de su ciclo de vida. Para ello, en esta tesis se han diseñado una serie de procesos relacionados entre sí, que confieren robustez y solidez a la gestión de un proyecto independientemente del tipo que sea o del sector a que pertenezca. Evidentemente a la hora de desarrollar un proyecto concreto, se deben aplicar los principios de gestión descritos y adoptados en esta tesis y el director de proyecto debe ser capaz de identificar los que realmente aportan valor a la gestión y alcanzar el equilibrio óptimo entre necesidad de control y esfuerzo requerido para conseguirlo. Los procesos están basados en los 47 descritos en el PMPBOK®, pero en el desarrollo de este trabajo se ha añadido o modificado algunos de ellos para conseguir que el resultado sea compatible tanto con ISO 21.500:2.012 como con PRINCE2® y el resultado sea más comprensible y de aplicación más genérica. Así, se han implementado los diferentes procesos siguiendo el orden y esquema descrito en PMBOK® y en la ISO 21.500:2.012 conforme a lo que se ha venido a denominar fases de la gestión del proyecto o FGP (que no se deben confundir con las fases por la que un proyecto podrá discurrir y que su número y duración dependerá del tipo del mismo, el nivel de control y la industria en la que se desarrolle; lo que se denomina el ciclo de vida del proyecto CVP) y las áreas de conocimiento AAP. Así mismo, también se ha asegurado de que los procesos resultantes ‐y por ende el modelo‐, sean compatibles con los principios de gestión que todo proyecto debe seguir para conseguir los beneficios de gestión esperados. De forma que para una mejor comprensión de los expuesto anteriormente, se ha desarrollado una ficha para cada uno de los mismos en la que se incluyen los siguientes campos:
Fase de Gestión del proyecto en la que se encuentra el proceso. Denominación del proceso. Codificación del proceso. Selección del tipo de proceso en términos de gestión: proceso estándar PES, proceso directivo de toma de decisión PDD o los que son necesarios para la toma de dicha decisión o procesos clave de gestión PCG. Descripción del proceso. Objetivos del proceso. Entradas del proceso. Salidas del proceso. La homologación de los modelos PMPBOK®, PRINCE2® e ISO 21.500:2.012 respeto a la MGIP. Donde se indica la codificación de cada uno de los procesos que están incluidos en el proceso analizado del MGIP. Comentarios para cada uno de los modelos sobre la homologación de sus procesos respecto al analizado en el MGIP.
Y en la que se va a indicar la correspondencia de estos con los procesos de los tres modelos estudiados, exponiendo los aspectos más reseñables o valorados.
2.2.
Estructura del modelo
Los procesos se han estructurado conforme a lo indicado en el punto anterior, distribuyéndolos entre las PFG y las AAP. Para su mejor comprensión y para facilitar la localización de los diferentes procesos, se han codificado todos ellos según su posición tanto en el FGP como en el AAP, conforme se puede apreciar en la Figura 38:
73
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Figura 38: Estructura del modelo MGIP.
Cada proceso dispone de tres números; el primero será el AAP, el segundo del FGP y el tercero será el que le distinguirá del resto de procesos que puedan existir en su propia combinación de AAP y de FGP. También se han diferenciado los procesos dependiendo si son procesos tipo que se desarrollan en cada una de las fases de gestión del proyecto FGP, y que se denominan procesos estándar PES y los procesos necesarios para que se pueda decidir el paso de una fase a otra, en este caso se han marcado en un color diferente, indicando, así mismo, las relaciones entre ellos e identificando claramente el camino a seguir para conseguir la aceptación y el paso de un momento o fase del proyecto al siguiente, consiguiendo, de esta forma, una completa clarificación de las acciones en los momentos críticos de decisión en un proyecto. A estos procesos se les denominan procesos clave de gestión PCG. Para poder superar una fase de gestión del proyecto y pasar a la siguiente, se identifican procesos en los que el nivel de gestión directivo podrá tomar la decisión de seguir adelante o no. Estos decisores se han definido como procesos directivos de decisión PDD, que son en los que el nivel de gestión superior al director de proyecto debe tomar una decisión. Serían los procesos que en PRINCE2® los asume el nivel directivo en el proceso DP. Así, las diferentes fases de gestión se van relacionando de la Figura 39:
Figura 39: Relación de las fases de gestión del modelo MGIP.
Como se aprecia en la figura 39, las diferentes FGP, se van relacionado entre sí conforme se desarrolla el proyecto a lo largo de su ciclo de vida. Así, se indica como entre las FGE de análisis previo, inicio y, entre la de inicio y planificación hay una doble relación, ya que son fases incrementales, si se consideran desde el punto de vista del conocimiento que se dispone del proyecto. Es factible que cuando se haya autorizado pasar a la fase siguiente, si en ésta ‐y una vez se haya perfeccionado la información y llegado a un mejor análisis‐, se considere que el resultado no es el deseado, en cuyo caso, se podría abandonar definitivamente el proyecto o volver a la fase anterior para reconsiderar lo establecido inicialmente. De la misma forma, también se expone en la gráfica como las FGP de planificación y ejecución y control interactúan de forma iterativa, ya que conforme se ejecutan las actividades definidas en la planificación, y se comprueba que se ajustan al plan, es posible que o bien surjan nuevos requisitos o que los resultados no sean los planificados y se observen desviaciones, lo que obligaría de nuevo, a planificar las estrategias para adaptar el plan y conseguir los objetivos del proyecto. Finalmente, se indica como entre las FGP de ejecución y control y cierre y entre las de cierre y operaciones hay una vinculación directa, ya que sólo cuando se determine que el proyecto ha alcanzado sus objetivos o no es capaz de generar más valor, se cerrará y análogamente, la organización autorizará el 74
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
paso a un entorno de operaciones cuando el producto del proyecto esté conforme a sus requisitos y la organización propietaria disponga del conocimiento y habilidades para su uso. Fases de la gestión del proyecto FGP Uno de los principios en los que se basa el modelo MGIP es el establecimiento de fases de gestión que permitan ejercer control sobre el proyecto dependiendo de las necesidades de los principales agentes. Así, el enfoque que realizan tanto PMBOK® como ISO 21.500:2.012 se basa en que el proyecto comienza en el momento en que la organización, una vez analizada la información que dispone, autoriza el comienzo de las actividades de planificación. Esta autorización se produce a través del acta de constitución del proyecto (ACP) en el grupo de procesos de inicio. Análogamente, en PRINCE2® podemos apreciar que esta autorización se produce en el proceso SU, en lo que se coincide en denominar como pre‐proyecto, generando un documento análogo que se denomina expediente de proyecto. Si bien la decisión de seguir adelante con el proyecto se tomaría en el proceso DP. En el modelo MGIP objeto de esta tesis, se aplica el mismo principio, si bien se considera que las tareas de pre‐ proyecto, ‐y debido al impacto que tienen en las siguientes fases‐ deben ser desarrolladas más ampliamente, por lo que se plantea la inclusión de una nueva FGP que lo trate, la cual se pasa a denominar análisis previo. La correspondencia entre los diferentes enfoques y el MGIP lo podemos apreciar en la Figura 40:
Figura 40: Esquema de la relación de los enfoques de PMBOK® / ISO / PRINCE2® con MGIP ‐ Inicio.
Si el proyecto es considerado apropiado, se deberá dotar de recursos para su desarrollo, si bien a pesar de estar autorizado no se debe comenzar la ejecución del mismo si previamente no se han establecido las bases para que se desarrolle adecuadamente. Por tanto es necesario realizar un análisis más profundo así como disponer de una planificación más detallada y exhaustiva del horizonte de planificación. Esto se produce en los procesos de planificación en los enfoques PMBOK® e ISO 21500:2102, de forma que en dichos procesos se obtienen los planes de gestión del proyecto que servirán de guía a los equipos de desarrollo. Además, al finalizar esta FGP, de nuevo se podrá valorar la toma de decisiones de si continuar con el desarrollo o no del proyecto, dependiendo ello de si con la información adicional de que se dispone se evidencia que es interesante y viable bien para la organización o bien para cliente, o para ambos. Por el contrario, en PRINCE2® la planificación se produce en el proceso IP y en el SB, de forma que en el primero de ellos se desarrolla tanto la planificación más general del proyecto como las diferentes estrategias de gestión en el plan de proyecto, mientras que en el proceso SB se planifica con detalle el modo en el que se desarrollará la fase siguiente autorizada, por lo que se obtendrá el plan de fase. De lo expuesto se concluye que, efectivamente, para poder iniciar la ejecución de un proyecto, es necesario disponer del nivel de planificación suficiente. En el enfoque PMBOK® e ISO 21500:2103 se dispondrá de un plan: el plan 75
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
de gestión del proyecto, que se irá desarrollando y actualizando a través de cada uno de sus planes de apoyo y conforme se vayan sucediendo las diferentes fases del CVP particular. En PRINCE2®, como se ha indicado, se explicita tanto el plan genérico como el de cada una de las fases. Además, incluso en el proceso PD en el que se ejecuta el trabajo del proyecto, los diferentes team managers o líderes de los equipos que van a desarrollar el trabajo especialista, también pueden desarrollar los planes concretos (planes de equipo), necesarios para ejecutarlos. Además, el proceso DP también participa en lo relativo a la toma de decisiones para poder pasar a la siguiente fase de gestión. Esto se evidencia en el siguiente esquema comparativo (Figura 41):
Figura 41: Esquema de la relación de los enfoques de PMBOK® / ISO / PRINCE2® con MGIP ‐ Planificación.
Seguidamente, si el proyecto es autorizado podría comenzarse su ejecución. En PRINCE2® esta autorización del trabajo del proyecto se realiza poco a poco a través de la autorización de las diferentes fases del CVP, de forma que sin la expresa autorización del nivel directivo no se podría proceder. En el enfoque PMBOK® e ISO 21500:2102 también se plantea de esta forma, pudiendo servir el acta de constitución como herramienta para autorizar el trabajo fase a fase, aunque no es obligatorio. Si bien hay que indicar que en este enfoque no es obligatoria esta autorización. En lo relativo al trabajo del proyecto, éste de desarrolla en el proceso de Implementación (ISO 21500:2012) o ejecución (PMBOK®). En PRINCE2® el trabajo se realiza en el nivel de entrega de proyecto por los team managers (tal y como se ha indicado anteriormente) produciéndose en el proceso PD. En el modelo MGIP se considera oportuno incluir en esta FGP también el control y monitorización, puesto que los procesos de ejecución‐implementación y control, son desarrollados en paralelo y no de forma secuencial. De esta forma ‐aunque no se coincide con los enfoques de PMBOK® e ISO 21.500:2.103‐ sí se adapta mejor a PRINCE2® y además no se generan incongruencias. En cualquier caso, del control y la comparación del desempeño real del proyecto contra lo planificado, se pueden detectar desviaciones que obligarían a volver a planificar soluciones o estrategias alternativas para poder cumplir los objetivos del proyecto, lo que haría volver a activar los procesos de planificación. Además, en PRINCE2® el control se ejecuta en diferentes procesos en los que el nivel superior de gestión controla al inferior y además de este control o monitorización, también se dirige y gestionan las responsabilidades a cada nivel. De esta forma, el proceso de una posible replanificación se realiza en cada nivel de gestión dependiendo de si no supera las tolerancias acordadas o a través de la creación de un nuevo plan de excepción que sustituya al superado. En el siguiente esquema se indican los procesos afectados en cada enfoque (Figura 42):
76
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
Figura 42: Esquema de la relación de los enfoques de PMBOK® / ISO / PRINCE2® con MGIP – Ejecución y control.
Finalmente, se incorpora una fase de gestión del cierre del proyecto en la que se finalizan las actividades de gestión del mismo, se recopilan la lecciones aprendidas y se entrega (y el cliente acepta) el producto resultante del proyecto. Se produce una coincidencia entre los enfoques PMBOK® e ISO 21500:2102. Si bien en PRINCE2® no existe una fase de gestión de cierre, sino que se plasmaría como un proceso en la última fase de entrega del CVP, las actividades descritas se incluirían en el proceso CP. En el modelo MGIP, se coincide con el primer enfoque como se puede apreciar en el siguiente esquema (Figura 43):
Figura 43: Esquema de la relación de los enfoques de PMBOK® / ISO / PRINCE2® con MGIP ‐ Cierre.
77
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
En el MGIP se ha considerado oportuno (de cara al cierre total del proyecto entendido como el cubrimiento de las necesidades de una organización o cliente) el establecer una última FGP, en la que se formalice y confirme el inicio del entorno de las operaciones del producto del proyecto por parte de la propia organización ya propietaria del mismo y quien deberá controlar y actualizar el plan de materialización de beneficios generado durante el proyecto y en el que se indican los beneficios que deberá producir el proyecto una vez finalizado éste para que se pueda comprobar la justificación comercial del mismo, incluso acabado éste. Y así se indica en el último esquema de esta serie (Figura 44):
Figura 44: Esquema de la relación de los enfoques de PMBOK® / ISO / PRINCE2® con MGIP – Operaciones.
Áreas de conocimiento AAP
2.3.
Principios básicos sobre los que se basa el MGIP
La gestión de proyectos se basa en las lecciones aprendidas de otros proyectos, tanto de los resultados del uso de herramientas y estrategias que han sido exitosas, como de las que no (especialmente estas últimas tienen un gran interés), pues ello proporciona un conocimiento básico para establecer un marco de buenas prácticas. De esta forma, debemos determinar cuáles deben ser las bases sobre las que un proyecto se puede gestionar adecuadamente según las experiencias anteriores. A partir de este conocimiento se han establecido unos principios básicos prescriptivos, es decir, si no se cumplen todos, la aplicación de los procesos o áreas de conocimiento quedarán seriamente comprometidos. De hecho en un entorno PRINCE2®, se indica claramente que si un proyecto no es fiel a estos principios, no se está gestionando utilizando PRINCE2®. Estos principios sientan su base en las lecciones aprendidas de proyectos anteriores que han sido analizados y cuyas experiencias se han incorporado en el método y en los cuerpos de conocimiento, por lo que han sido probados en proyectos reales durante años, lo que da confianza de su validez y usabilidad. Los principios de gestión de proyectos del MGIP Para el desarrollo y la aplicación de los procesos del MEGIP es necesario igualmente aplicar los principios a las actividades de gestión de proyectos, que deben ser incluidos siempre y en todos ellos, de forma que si alguno de ellos no se tuviese en cuenta, no se podrían obtener los beneficios del MGIP. Para este punto en concreto el MGIP se ha basado en los principios de PRINCE2® y además se han ajustado con las puntualizaciones derivadas del análisis del resto de enfoques. De hecho, desde el punto de vista de PRINCE2® los principios se desarrollan o materializan también en los temas o áreas. Así, el siguiente análisis y descripción de los principios identificados como imprescindibles para el MGIP, se ha hecho referencia a ellos. Se describen a continuación: 2.3.1.
Justificación comercial continua
Un proyecto se crea para cubrir una necesidad, de forma que no se debe iniciar ningún proyecto sin que esta necesidad que justificaría el uso y gasto de recursos sea exhaustivamente explicada y entendida por los agentes principales del proyecto, y más concretamente, por el cliente o por la organización. Así, para la puesta en marcha y desarrollo de un proyecto, se debe comprobar que exista un motivo justificable y que éste se mantenga válido a lo largo de todo el ciclo de vida del mismo. Además de ello es requisito imprescindible que se documente y apruebe. Esta 78
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
justificación del proyecto, es fundamental que sea analizada y comprobada desde el primer momento del proyecto hasta su cierre, siendo, por tanto, necesario comprobar dicho cumplimiento en cualquier momento del mismo. Si dicha justificación desapareciese o el proyecto no fuese capaz de cubrirla, la organización tendría la oportunidad de tomar la decisión más adecuada para sus intereses, pudiendo llegar al cierre prematuro del proyecto. La justificación comercial va a ser tratada en el MGIP, en concreto, en el área AAC de la justificación comercial y se materializa en el business case o estudio de viabilidad, en el que se reflejarán los beneficios que se espera obtener del proyecto así como el momento en el que ocurra. La precisión de la información va aumentando conforme se va avanzando en las diferentes fases de gestión del proyecto, por lo que de la misma forma se irá concretando y perfeccionando el mismo. 2.3.2.
Gestión orientada a la generación de productos
Un proyecto centra su atención en la definición y entrega de productos, en particular, en sus exigencias de calidad, de forma que se vean cumplidos los requisitos del cliente o del resto de agentes. No hay que olvidar que la finalización de un proyecto está directamente vinculada con que el producto del proyecto resultante los incluya (los productos).Por lo debe considerarse, que la ejecución de las actividades no es el objetivo del proyecto, sino la generación de los entregables, y a partir de esta premisa es cuando se pueden definir también las actividades o tareas necesarias para crearlos. El objetivo de este principio es que todos los agentes participantes en el proyecto así como el resto de stakeholders, dispongan de una visión clara de los productos o entregables que el proyecto generará a lo largo de su CCP al igual que también deberán tener una idea cierta de cuál será el producto del proyecto, sus principales características y criterios de aceptación. De forma que tanto los diferentes productos como el final satisfagan las necesidades del cliente y usuarios principales. 2.3.3.
Gestión por fases
Todo proyecto pasa por diferentes fases :es lo que se denomina ciclo de vida del proyecto (CVP). Este ciclo será diferente dependiendo del sector o industria en el que se desarrolle, su complejidad y demás factores. Estas fases pueden estar solapadas y superpuestas (fases técnicas) o, al contrario, pueden ser las denominadas de gestión, actuando como un sistema de puertas, de forma que no se puede pasar de una fase a la siguiente sin haber analizado el resultado y sin que se autorice formalmente la posterior. La gestión por fases es un principio fundamental, ya que permite transmitir al proyecto la estrategia de control, de forma que cuando más fases se establezcan, mayor control se ejercerá en el proyecto por el nivel superior directivo, lo que implicará –a su vez‐ un mayor esfuerzo por su parte. Por tanto, identificar las fases y los productos o servicios (entregables que se desarrollarán en cada una de ellas), es un aspecto clave para el proyecto. Es por ello, por lo que se considera oportuno desarrollar con más profundidad este concepto concretado en el ciclo de vida del proyecto y producto. Ciclo de vida del proyecto Según se define en el capítulo 2 del PMBOK®, el ciclo de vida del proyecto es un conjunto de fases del mismo, normalmente secuenciales y en ocasiones superpuestas, cuyo nombre y número se determina por las necesidades de gestión y control de la organización u organizaciones que participan en el proyecto, la naturaleza propia del proyecto y su área de aplicación. Para cada caso, las fases de un proyecto pueden cambiar. Es cierto que todos los proyectos, sean mayores o menores, con más o menos complejidad, tienen un principio y un final, pero entre estos dos hitos fundamentales, se deben plantear diferentes pasos que aseguren que su desarrollo sea ordenado [126‐128]. Además el establecimiento de fases, crea la estructura básica del proyecto. De hecho, es posible, que se pueda tratar a cada fase como un proyecto independiente, con sus características propias y sus entregables particulares. Cada fase, puede tener diferentes sub‐fases. Las fases de un proyecto, no son los grupos de procesos, ya que éstos aplican a lo largo de todas las fases definidas, y en las fases del proyecto se incluye todo el trabajo a realizar para completarlo y en qué momento del desarrollo del mismo se debe acometer. Así en cada fase, al menos se define:
Productos entregables que se deben producir al final de cada una. Cómo se revisan y validan estos entregables. Quién está involucrado. Criterios de aceptación de final de fase y comienzo de la siguiente (sistema de puertas).
79
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Podemos definir una fase como las divisiones dentro del proyecto que necesitan un control extra y exclusivo para gestionarlas correctamente. Ello hace posible que se facilite la gestión del proyecto global. Al dividir el proyecto en fases, disponemos de una visión global del mismo, pero podemos realizar una gestión más particularizada y concentrada, enfocando los esfuerzos del equipo de proyecto de forma ordenada. Por lo que es una herramienta de control, y cuanto más fases se establezcan, mayor será el control ejercido por el patrocinador o de la junta del proyecto. Así, cuando se finaliza cada una de las fases, se puede analizar cómo se ha desarrollado esa parte del proyecto y si se han alcanzado los objetivos deseados. Además se tiene la oportunidad de analizar de nuevo si se sigue adelante con el proyecto, se modifica o incluso de cierra. Sistema de puertas y tipos de fases De forma que cuando se cierra una fase, se debe conocer con exactitud qué rendimiento ha tenido el proyecto hasta entonces y por tanto “cerramos” la puerta de esa fase. El número de fases en cada proyecto dependerá de la complejidad del mismo y del nivel de control que se quiera aplicar. Así, podemos dividir cualquier proyecto a través de dos tipos de fases:
Fases de gestión: serían las que dividen el proyecto de forma tal que sin ser aprobada la fase anterior no se permite pasar a la siguiente (también autorizada). Fases técnicas: pueden ser transversales y pasar por diferentes fases de gestión.
En la Figura 45 se observa cómo las fases técnicas (de color más oscuro) cruzan las de gestión, si bien cabe señalar que una buena práctica consiste en determinar qué tipo de productos o entregables deben ser obtenidos en las fases técnicas cada vez que se cierra una de gestión.
Figura 45: Ejemplo de proyecto divido en fases.
De esta forma, queda asegurado el control deseado del proyecto, no realizándose trabajo inútil y evitándose el gasto de recursos de forma incontrolada. Así, el proyecto anterior, podría quedar de la siguiente forma (Figura 46):
Figura 46: Ejemplo de proyecto divido en fases de gestión.
Secuenciación de las fases Como ha sido indicado anteriormente, las fases se desarrollan de forma secuencial, siendo habitual que se comience en fases posteriores sin haber sido aprobadas las anteriores, siendo ello posible si se ha evaluado el riesgo y este ha sido considerado aceptable. Es lo que se denomina fast tracking, y cosiste en comenzar una fase posterior, antes de haber concluido la anterior o incluso en paralelo. Esto es utilizado en la gestión de proyectos para acortar los plazos de ejecución. Esta secuenciación de fases, pone más en relieve la progresión gradual del desarrollo de los proyectos. En 80
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
general, las primeras fases son virtuales, es decir, se basan más en la planificación del trabajo a realizar, mientras que las posteriores son de elaboración real de las tareas.
Figura 47: Grupos de procesos y su relación. Fuente PMBOK®.
Como se refleja en la Figura 48, se puede observar cómo en los primeros momentos del proyecto, las necesidades de recursos van creciendo gradualmente, de forma que en la fase de ejecución es cuando más se necesitan. De igual forma se observa que al final del proyecto, estas necesidades van decreciendo rápidamente. Este proceso, en general, adquiere una forma particular asimilándose en la forma a una campana de Gauss.
Figura 48: Evolución de los recursos y su consumo acumulado en un proyecto tipo.
Influencia en las características del proyecto el avance de las fases De lo expuesto anteriormente, podemos deducir que el comportamiento del proyecto no es igual en todas las fases de su ciclo de vida. Así, en las fases iniciales es cuando mayor posibilidad hay para influir en sus características y, por lo tanto, en su presupuesto, ya que la incertidumbre es alta. En cambio, conforme avanza el proyecto y se acerca al final, ocurre todo lo contrario, las posibilidades de cambio o de influencia decrecen, aumentando los costes en estos cambios. Lo que se indica en las Figura 49Figura 50:
Figura 49: Relación de la incertidumbre con el impacto de los cambios a lo largo de la vida del proyecto. Fuente: PMBOK®.
81
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Figura 50: Relación de la oportunidad de minimizar el riesgo con su impacto a lo largo de la vida de un proyecto. Fuente: AEDIP [17]
Tipos de ciclos de vida Conforme a lo expuesto anteriormente, se pasa a identificar los diferentes tipos de ciclos de vida de proyecto, tal y como se indica en el PMBOK®:
Ciclos de vida predictivos (totalmente orientados al plan): son en los que el alcance del proyecto, el tiempo y el costo requeridos para lograr dicho alcance, se determinan lo antes posible en el ciclo de vida del proyecto. En Este tipo de CVP, los cambios se gestionan cuidadosamente y requieren e la planificación y aceptación formal del nuevo alcance.
Figura 51: Ciclo de vida predictivo o en cascada.
Ciclos de vida iterativos e incrementales: Son aquellos en los cuales, dentro de las fases del proyecto (iteraciones), se repiten de manera intencionada una o más actividades del proyecto a medida que aumenta el entendimiento del producto por parte del equipo de proyecto. Así, cada nuevo ciclo o iteración añaden características y van perfeccionando el proyecto.
Figura 52: Ciclos de vida iterativos o incrementales.
Ciclos de vida adaptativos o ágiles: Se encuadran en entornos con un alto nivel de cambio y con alta participación de los interesados. Son métodos iterativos e incrementales, pero al contrario de los que hemos analizado en el punto anterior, estas iteraciones son muy rápidas y se fija tanto el costo como la duración de cada una. Se opta por estos métodos en proyectos donde los requisitos y el alcance son difíciles de definir con antelación y además es posible definir mejoras graduales que aportarán valor a los interesados.
Figura 53: Ciclos de vida adaptativos o ágiles.
82
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
Ciclo de vida del proyecto vs ciclo de vida del producto Para el desarrollo de un producto es necesario, normalmente el desarrollo de varios proyectos diferentes, si bien están relacionados entre sí. A diferencia del ciclo de vida del proyecto, las fases no suelen superponerse, sino que se localizan secuencialmente. Otra diferencia es que el ciclo de vida del proyecto tiene una visión más amplia que la de un solo proyecto. Es posible que coincidan los dos en proyectos donde el resultado es un servicio o producto sencillo. Como podemos ver, el ciclo de vida del producto comienza cuando disponemos del producto del proyecto desarrollado en el proyecto. Además, a lo largo del CVP se puede realizar más proyectos de forma que el producto se mantenga actualizado y pueda mantenerse en el mercado, incluso si se decidiese la retirada del mismo, se podría generar un proyecto expresamente para ello. Así, en las distintas fases del ciclo de vida de un producto se desarrollan numerosos proyectos, cada uno con su ciclo de vida particular. Por ejemplo: la creación de un producto, mejorarlo, actualizarlo, introducirlo en el mercado, etc. [129].
Figura 54: Ciclo de vida del producto vs ciclo de vida del proyecto.
El establecimiento de fases para desarrollar el proyecto, es la base de la gestión y control del mismo. Así, es habitual que la gerencia de la empresa aproveche la finalización o inicio de cada fase (puntos de chequeo o cancelación; check points, kill points, exits gates) para evaluar sus resultados y decidir las actuaciones siguientes. Los grupos de procesos no suelen realizarse una sola vez en un proyecto, sino que se suelen desarrollar a lo largo de todo su ciclo de vida, con diferente intensidad, dependiendo de la fase. De hecho, en cada fase, se suelen repetir los grupos de procesos. Por ejemplo, un proyecto PRINCE2®, se planifica, supervisa y controla fase a fase. De ahí la importancia de la correcta identificación de las fases del ciclo de vida del proyecto. Esto permite:
Proporcionan al personal directivo superior puntos de control: al final de cada fase, se evalúa cómo ha finalizado, junto con el estado global del proyecto, revisando el business case y asegurándose que el proyecto sigue siendo viable. Además el número de fases define el nivel de control deseado por la dirección, cuanto más fases más control. No se puede pasar de una fase a otra sin el visto bueno del nivel superior. Se puede realizar una planificación progresiva: la fase siguiente muy detallada, pero disponiendo de un master plan o plan director global con un nivel de detalle inferior.
Y para una correcta aplicación de este principio, tiene que haber un mínimo de dos fases: una de inicio y una o más de gestión. 2.3.4.
Gestión planificada y actualizada
Este es uno de los principios fundamentales y que tendrá su materialización en procesos clave y sumamente importantes a la hora de gestionar el proyecto. Todo proyecto se debe a los siguiente tres preceptos:
Debe existir un plan del proyecto que sirva de guía y en el que se describa el trabajo a realizar y las condiciones en cómo se desarrollará, de forma que no se ejecutará ningún trabajo que previamente no se haya planificado. Así, para poder controlar el desarrollo del proyecto, primero se tiene que contar con un plan, por lo que, sin un plan que indique al equipo de proyecto cómo y cuándo debe realizar las tareas del proyecto, no se podrá controlar si se está realizando correctamente o no. Como decía Winston Churchil “If you fail to plan, the plan to fail”. Así pues, los planes son base line sobre los que medir el progreso del proyecto.
83
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Este Plan siempre debe estar actualizado y reflejar tanto la realidad del proyecto como las necesidades y requisitos de los agentes. Cualquier cambio debe ser aprobado por el nivel de autorización requerido.
Por lo que en cada proyecto debe existir un plan lo suficientemente detallado como para que los equipos de desarrollo que van a ejecutar el trabajo puedan hacerlo correctamente con la menor incertidumbre posible, ya que de lo contrario supondría pérdidas de tiempo, reprocesos por errores y, en general, la pérdida de eficiencia en el trabajo. Este principio también incluye que el plan de proyecto esté actualizado con los diferentes cambios que eventualmente se pueda decidir adoptar. Para ello es un pre‐requisito es la existencia de un proceso de gestión de cambios integrados, que permita captar las diferentes solicitudes de cambio, las valore y que establezca los mecanismos de toma de decisiones dependiendo del tipo e impacto del mismo. Además de ello, es necesario que comunique de forma eficaz y a tiempo la información en lo relativo a los cambios a los diferentes stakeholders afectados. Puede afirmarse que un plan es un documento que describe cómo, cuándo y quién logrará una meta o conjunto de metas específicas, por lo que debe especificarse en él los requisitos y debe contar con la información suficiente para confirmar que es posible alcanzar esas metas (sobre los 6 aspectos del rendimiento del proyecto –coste, tiempo, alcance, calidad, riesgo, beneficio‐). Debe estar alineado con el BC en todo momento y siempre debe estar aprobado (por el nivel superior de gestión) [46]. Y por tanto, el proceso de elaborar y mantener un plan sería la definición de planificación. Dependiendo del conocimiento e incertidumbre del proyecto y de su entorno, podrá ser más o menos dilatada en el tiempo su planificación, de forma que si es proyecto está suficientemente definido podríamos planificar a largo plazo, pero en cambio sí disponemos de definición, ésta deberá estar orientada hacia el corto plazo. Este concepto es lo que se denomina el horizonte de planificación [46]: el tiempo en es posible realizar la planificación con la precisión y definición necesaria. Niveles de planificación. Los planes que podemos emplear en un proyecto, pueden ser de diferente precisión y tener diferentes objetivos dependiendo de la necesidad de su uso. Así, la alta dirección de la organización no usará un plan con el mismo detalle que el que un miembro de un equipo o un especialista necesitaría para ejecutar un trabajo completo. Se pueden definir por tanto, diferentes tipos de planes y, por tanto, los niveles de planificación conformarían la estructura jerarquizada de los planes que siguen la estructura jerárquica de la gestión establecida. De esta forma, cada uno de los planes que se genera en un determinado nivel, debe ser aprobado por el superior, siendo por tanto necesaria la definición de los diferentes tipos de planes para cada uno de estos niveles. Tipos de planes En el PMBOK® se definen dos documentos fundamentales para la gestión; el acta de constitución y el plan de gestión del proyecto [35]. Este último perfecciona el acta de constitución (ACP) y desarrolla en detalle la manera en la que se va a gestionar el proyecto, así como lo que éste producirá. Además, el plan de proyecto, sirve de guía, debiendo desarrollar el proyecto, el equipo de proyecto. Éste, asimismo, está compuesto por planes subsidiarios o de gestión (uno al menos para cada área de conocimiento: plan subsidiario del alcance, de la gestión de requisitos, tiempo, costes, calidad, mejora de procesos, comunicaciones, recursos humanos, riesgos, adquisiciones y agentes) y líneas base (de alcance, tiempo y costos) que establecen la manera –cómo‐, el tiempo –cuándo‐ y la cantidad ‐cuánto costará‐ la ejecución de las diferentes actividades y paquetes de trabajo que generará el proyecto. Este plan de gestión se irá desarrollando y definiendo de manera progresiva, incrementada e iterativa, conforme vaya avanzando el proyecto (roll wave planning [46]). Análogamente en ISO 21.500:2.012, se plantean planes de proyecto incluyendo, asimismo, los diferentes tipos de planes necesarios. En PRINCE2®, al contrario que en el PMBOK® e ISO 21.500:2.012 sí se profundiza en la definición de los planes a aplicar a la hora de gestionar un proyecto y se determinan los niveles que los desarrollarían. Siguiendo el esquema de gobernanza del proyecto, estos se definen, como:
84
Plan de proyecto (PP). Define cómo se gestionará el proyecto a nivel global; explica cómo, cuándo y por quién se tiene que lograr las metas de los 6 aspectos de rendimiento del proyecto. Por lo tanto, será el documento que usará el nivel directivo para controlar el proyecto. Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
Planes de fase (PF). Son los planes que van detallando el trabajo a realizar. Hay que recordar que en PRINCE2® la junta de proyecto (JP) no autoriza al director de proyecto a realizar el trabajo de la totalidad del proyecto de una sola vez, sino que lo va autorizando por fases. En base a ello, el director del proyecto debe explicar y exponer a la JP cómo va a desarrollar la fase siguiente y lo debe hacer con el detalle suficiente. Este plan debe ser usado por el DP como el documento base y guía de los trabajos a realizar. Planes de equipo (PE). En PRINCE2® una función principal del director del proyecto es identificar los paquetes de trabajo en los que se dividirá el mismo, y asignarlos a los diferentes jefes de equipo o team managers (TM) ‐internos a la organización o externos a ella‐ quieres serán los encargados de realizar el trabajo especialista necesario para producir los entregables del proyecto. Son los propios TM los encargados de exponer y definir cómo se van a conseguir los objetivos y alcanzar los requisitos del paquete de trabajo asignado, de forma que son ellos los que desarrollan y presenta al director del proyecto un plan lo suficientemente detallado para poder ser ejecutado y contralado debiendo éste estar alineado con los objetivos generales de la fase y, por supuesto, del proyecto. Planes de excepción (PEX). El plan de excepción un plan que se desarrolla para que el nivel de gestión muestre al nivel superior las actividades necesarias para poder reconducir el proyecto ante una desviación respecto a las tolerancias establecidas. De forma que si se aprueba, el PEX sustituirá al plan que se encuentra en estado de excepción y se convertirá en la nueva versión base line debiendo, por consiguiente, estar definido al menos con el mismo detalle del plan al que sustituye. En PRINCE2® cuando una excepción se detecta a nivel de PE, el TM lo comunicará al PM, quien analizará si se puede absorber en el PF ‐en sus tolerancias‐, por lo que no se generará un PEX a nivel de plan de equipo. Si la excepción es a nivel de PF (lo que implica que se sobrepasan las tolerancias fijadas), se generará un PEX que deberá aprobar la JP. Finalmente, si la excepción se produce a nivel de proyecto, el PEX lo debe aprobar la propia organización corporativa o de programa. Plan de revisión de beneficios (PRB): (ver principio de justificación continua y AAC de justificación comercial). Se desarrolla en base al estudio de viabilidad del proyecto con el objetivo de determinar no sólo los beneficios que generará el proyecto, sino el momento en que se darán, cómo se medirán y quién será el encargado de ello. Este plan puede abarcar actividades antes, durante y después de que finalice el proyecto, por lo que puede ser parte del plan corporativo de la empresa o del programa.
En la Figura 55 se pueden apreciar y analizar todas las relaciones entre los diferentes planes descritos anteriormente y que se incluyen en PRINCE2®.
Figura 55: Los planes en PRINCE2®.
85
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
2.3.5.
Adaptación al cambio
En un proyecto, los cambios son intrínsecos a él y, en la mayoría de los casos, inevitables. De hecho, un cambio no tiene que representar un problema, ya que el primer esfuerzo que debe realizar el director de proyecto cuando se enfrenta ante uno, es el de valorar si aporta valor al proyecto o no. Así, si la respuesta es negativa, no se debería implementar, incluso no se debería introducir en el proceso de gestión de los cambios. Pero no hay que olvidar que si bien un cambio ‐conforme a lo expuesto anteriormente‐ sería positivo para el proyecto (o debe serlo), también genera riesgos. Esto es así ya que una vez que se ha especificado el trabajo a realizar y éste ha sido aprobado y comunicado, cualquier cambio ‐para su efectiva implementación‐ va a requerir un esfuerzo extra tanto de planificación y control, como de comunicación a todos los agentes afectados. Ha de informarse al equipo de que el cambio se ha producido y que todos los planes, registros y documentos se deben actualizar con la nueva situación. De este modo, en todos los proyectos se debe establecer un sistema de gestión de cambios que permita recoger las solicitudes de cambio, y que éstas se puedan valorar y, en su caso, proponer al nivel de toma de decisión adecuado para su implementación. Este procedimiento también debe ser riguroso y estable para que se genere predictibilidad y seguridad y se puedan controlar posibles errores, reduciendo, por tanto, el nivel de riesgo en el proyecto. De hecho, no se puede asegurar la justificación continua del proyecto sin haber establecido un sistema integrado de control de cambios adecuados puesto que el no disponer de él, podría suponer obviar y/o perder solicitudes de cambio y, por tanto, limitar las posibilidades de mejora del proyecto. Así, en el MGIP se incluye un proceso exclusivo para ello. Además de ello hay que tener en consideración que si el equipo de proyecto realiza cambios en el proyecto y añade funcionalidades sin estar estas correctamente analizadas, aprobadas e implementadas, se pierde el control sobre el producto final que hay que conseguir, poniendo en riesgo el resultado final del mismo. Esto se define como corrupción del alcance [35]. Por tanto, se debe establecer de manera temprana en el proyecto un procedimiento que permita obtener los objetivos definidos anteriormente, tal y como se puede apreciar en la Figura 56:
Figura 56: Esquema básico en la gestión de los cambios en un proyecto.
En el gráfico anterior se aprecia cómo los cambios pueden ser solicitados por cualquier agente, y de cualquier forma ‐incluso verbalmente‐, pero es función del director del proyecto (y su equipo), el de dar un aspecto formal a la orden, pudiendo, por ejemplo, usar ordenes de cambio. Otra actividad importante, que se debe realizar incluso en una fase anterior, es la de prever las causas raíz, que puedan generar cambios, de forma que el equipo del proyecto debe tener una actitud preventiva y anticiparse a ellas. Se puede afirmar que, en general, los cambios generan un amento en el riesgo del proyecto. Igualmente, antes de presentar al estamento (o persona) definido como el responsable de aceptar o rechazar el cambio, el equipo de dirección del proyecto debe realizar una labor de análisis previo que comprenda tanto la búsqueda de posibles alternativas al cambio (los cambios producen un aumento del riesgo), o bien que lo eviten, como, por ejemplo, elaborar un estudio detallado del impacto que éste tendría en el proyecto (en todas las áreas del mismo –integración‐). 86
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
Los objetivos del sistema de control de cambios serían: Establecer un método progresivo para identificar la sistemática y solicitar cambios a las líneas bases establecidas, así como determinar el valor y la eficacia de dichos cambios. Proporcionar oportunidades de validar y mejorar el proyecto de forma continua, teniendo en cuenta el impacto de cada cambio. Proporcionar el mecanismo que permita al equipo del proyecto comunicar a los interesados, de manera sistemática, todos los cambios, aprobados y rechazados. En el PMBOK® la gestión de los cambios sobre el plan de gestión de proyecto, se define en el proceso de control del área de gestión de la integración denominado 4.5 gestión integrada de los cambios del proyecto. La razón de que se encuentre incardinada en el área de integración ‐y no en otra es‐ es que para poder valorar el impacto de un cambio, no se puede analizar un área de forma independiente, por ejemplo, el impacto en los costes del proyecto, sino que como se ha tratado en el concepto de la triple restricción, ese cambio también afectará a al menos una de las otras dos áreas y probablemente a otras áreas del proyecto. Es por ello, por lo que el único rol que puede analizar y valorar de una forma integral e integradora un cambio sería es el director del proyecto. En ISO 21.500:2.012 de forma similar existe un proceso específico para controlar adecuadamente los cambios de un proyecto, el 4.3.6. En PRINCE2® se define una temática específica para el cambio, cuyo propósito es identificar, evaluar y controlar cualquier cambio potencial o aprobado que afecte a la baseline. De forma que cada proyecto debe desarrollar un enfoque sistemático para su gestión, a lo largo de todo su CVP y cuya finalidad no es evitar los cambios, sino que estos se gestionen correctamente y sean aprobados antes de su implementación. Además los cambios sólo los podemos valorar sobre una línea base o base line: se considera que un producto de gestión es base line, cuando está aprobado y se establece como lo que hay que hacer. Un cambio solo se puede considerar respecto a una base line, por lo que la existencia de un plan (base line) es un prerrequisito para el control de cambios. Aprovechamos el alcance de la gestión de cambios, en la que se incluye la gestión de la configuración, abarcando un ámbito más amplio y en el que se incluiría el sistema de cambios. Gestión de la configuración La gestión de cambios, tal y como se ha indicado anteriormente es parte de un sistema de control más amplio, a saber, el de la configuración. Es por ello, por lo que las diferentes versiones modificadas de una base line, se deben ir codificándose y controlándose a través del control de la configuración, de forma tal que en todo momento se tenga actualizada la versión de cada producto. De hecho, la gestión de la configuración se puede definir como la actividad técnica y administrativa relacionada con la creación, el mantenimiento y el cambio controlado de la configuración durante toda la vida de un producto (o elemento) [46]. En primer lugar, hay que definir cada elemento de configuración, consistente en una entidad que está sujeta a la gestión de la configuración. Pueden ser: un componente de un producto, un producto o lo que denomina una release (conjunto de productos que son gestionados, probados como una única entidad que se debe entregar al usuario). Procedimiento de gestión de la configuración La configuración incluye las siguientes actividades fundamentales: Planificación. Determinar el nivel de control adecuado al tipo de proyecto. Al máximo nivel se llega cuando un componente puede ser instalado o sustituido de modo independiente. Identificación: se tienen que identificar todos los componentes de los productos del proyecto (elementos de configuración). Además de ello, se debe establecer un sistema de codificación inequívoco para cada elemento, a través de la creación de las fichas de configuración para cada uno de ellos. Control. Tanto los productos especializados como los de gestión están sujetos al control de la configuración. Informar sobre el estado de los productos. Cuando se está finalizando una fase, el PM puede solicitar un informe sobre el estado de los productos, de forma que pueda valorar el nivel de consecución y progreso de cada uno para determinar la posibilidad de finalizar la fase. Verificación y auditoría. Se pueden realizar comprobaciones y auditorias para comprobar que el estado real de los productos coincide con el descrito en las fichas de elementos de configuración, así como verificar que se está siguiendo el proceso definido.
87
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Cuestiones A la hora de estructurar las posibles situaciones que eventualmente pueden generar cambios y modificaciones en un proyecto, PRINCE2® emplea el concepto amplio de cuestiones. Con este término pretende referirse a cualquier evento importante que haya ocurrido y que no estaba planificado y que, además, requiera del empleo de alguna acción de gestión, pudiendo plantearse en cualquier momento y por cualquier persona, como, por ejemplo, pueden ser las dudas, solicitudes de cambio, sugerencias fuera de especificación, etc. Así pues, las divide en los tres tipos siguientes:
Figura 57: Tipos de cuestiones según PRINCE2®.
Enfoque de PRINCE2® hacia el cambio PRINCE2® plantea que para poder realizar una eficiente gestión del cambio en el proyecto hay que establecer los controles del proyecto precisos, definir la forma en cómo gestionar las cuestiones y estructurar la gestión de la configuración. Estos aspectos se establecen en IP, y se revisan y actualizan en SB. Caben señalar, por considerarse interesante su mención en este trabajo, los productos de gestión que se usan a la hora de establecer controles, a saber:
88
Estrategia de gestión de la configuración: No se puede realizar un control de cambios efectivo si no se cuenta con un sistema de gestión de la configuración que facilite la evaluaciones del impacto y mantenga las versiones base line de los productos. Presupuesto de cambios: El cliente y el proveedor pactan una cantidad que se utilizará para financiar el coste de las solicitudes de cambio (y de su análisis). Se pueden establecer límites para cada cambio individual y para los cambios por fase (si se supera deberá decidir la JP). Son opcionales y no se usan las tolerancias para financiar cambios. Cuando un cambio se financia con el presupuesto de cambios, se hace informalmente. Los cambios afectan a los siguientes productos de gestión: El uso de fichas de elementos de configuración; consistentes en testimonios documentales que describen el elemento de configuración en lo relativo información sobre su estado, la versión en que actualmente se encuentra y cualquier otro dato relevante [46]. Informes sobre el estado de los productos. De la misma forma PRINCE define este tipo de informes cuyo objetivo es informar sobre la condición (estado) de los productos respecto a los límites definidos y que pueden cubrir todo el proyecto, una fase, un área específica o un producto [46]. Archivo diario. Es un documento que es usado por el PM para dejar constancia de los asuntos/cuestiones que puede manejar informalmente. Es de facto la agenda del proyecto del PM, por lo que en él se pueden apuntar las acciones, decisiones o acontecimientos importantes que no se hayan recogido en otros documentos [46]. Registro de cuestiones. Si el archivo diario se gestionar y apuntan las cuestiones que se pueden resolver informalmente, es en este registro en el que se registran y guardan todas las cuestiones que se están gestionando formalmente. Como nota importante, hay Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
que tener en cuenta que cuando un riesgo se detecta, se incluiría en el registro de riesgos. Sólo si se materializa el evento, se convertiría en cuestión. Informes de cuestiones. Es un informe que contiene la descripción, la evaluación del impacto y las recomendaciones para una solicitud de cambio, un fuera de especificación o un problema/asunto. En él se pueden proponer varias alternativas para abordar la cuestión y sólo se crea para las cuestiones que tiene que ser manejadas formalmente, por lo que consecuentemente, cualquier cambio a una base line, debe ser gestionado con un informe de cuestiones.
Procedimiento de control de cambios y cuestiones PRINCE2® gestiona de la misma forma las solicitudes de cambio, las fuera de especificación y los problemas/asuntos. Los pasos a seguir son:
Figura 58. Procedimiento de control de cambios en PRINCE2®.
Registrar: Consiste en realizar un análisis de la cuestión de forma que se decida si se debe gestionar formal o informalmente, por lo que se clasifican y se decide el nivel de resolución (formal o informal) de forma que las que se gestionan formalmente, se deben anotar en el registro de cuestiones. Se crea un informe de cuestiones, donde se registra y explica lo que se sabe de la cuestión. Examinar: Consiste en analizar su impacto. El PM analizará el impacto de la cuestión sobre los objetivos del proyecto, el BC y los beneficios esperados, los riesgos concretos que genera y la exposición total del proyecto al riesgo global generado y cualquier otra cuestión que se considere relevante. Proponer: Hay que considerar las diferentes opciones alternativas para responder a la cuestión y proponer medidas. Si la propuesta haría superar las tolerancias del proyecto, se deberá acompañar un informe de excepción al informe de cuestiones. Decidir: La autoridad en cada momento podrá tomar la decisión de la cuestión. La JP podrá aumentar las tolerancias para resolver el problema, además las posibles respuestas se expresan en la siguiente tabla de PRINCE2®.
89
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Figura 59: Decisiones de la junta de proyecto ante una cuestión, según PRINCE2®.
Implementar: El PM en este momento, llevará a cabo las rectificaciones necesarias. Pero dependiendo de las directrices del nivel superior, podrá preparar un plan de excepción. Y en cualquier caso actualizará el registro de cuestiones, el informe de cuestiones con la decisión tomada e informará a todas las partes afectadas. Un resumen del proceso se puede ver en la Figura 57:
Figura 60: Pasos en la gestión de una cuestión según PRINCE2®.
En PRINCE2® este principio de materializa con la temática de planes, cambio y progreso. 90
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
Progreso El conocer en cada momento la situación del proyecto en términos de gestión e informar a los agentes interesados para que puedan tomar la decisión adecuada es un principio fundamental. Para lograrlo, en el PMBOK® se establecen los diferentes procesos de control de las áreas de conocimiento de forma que los datos de desempeño del trabajo (DDTRAB) que se obtienen en el proceso de ejecución, son analizados y tratados en el contexto global de cada uno de las áreas generando la información de desempeño (INFDTRAB), los cuales sirven al DP para poder disponer de una imagen clara de la situación del proyecto, a partir de la comparación del desempeño real frente al planificado descrito en los planes. Así, una vez trasformada la información de desempeño (INFDTRAB) en los informes o reportes necesarios (REPDTRAB), se podrá conocer el nivel de progreso y de cumplimiento de las metas del proyecto, así como se podrán detectar posibles desviaciones. Esta información es básica y vital para que cada nivel de decisión pueda tomar las mismas de forma informada y basadas en datos reales, no en suposiciones. En PRINCE2® se trata este aspecto en la temática de progreso, cuyo objetivo es el de establecer mecanismos con los que realizar un seguimiento y comparación de los logros reales con los planificados; proporcionar un pronóstico de los objetivos del proyecto y de la fiabilidad continua del mismo; así como poder controlar cualquier desviación inaceptable. Para que esta temática ‐en la que se basa el principio de este capítulo‐ sea factible, es necesario que hayan definido los niveles de tolerancias a partir de los cuales es necesario tomar medidas o plantear un plan de excepción. Ya que una excepción supondría una situación en la que se puede prever que tendrá lugar una desviación por encima de los niveles de tolerancia acordados por la gobernanza. Siendo la tolerancias desviaciones permisibles por encima y/o debajo de los objetivos de un plan, sin la necesidad de presentar una excepción al nivel de gestión inmediatamente superior. Lo que persigue es no burocratizar en exceso la gestión del proyecto, ya que como se ha comentado en puntos anteriores, un plan está basado en estimaciones que pueden cambiar a lo largo del ciclo de vida del proyecto. Además, no todos los cambios tienen la misma importancia. De esta forma se delega la toma de decisiones a cada nivel de gestión y ello se hará en virtud de su impacto. Así, el progreso consiste en comparar lo ejecutado contra lo planificado y usar esa información para la toma eficaz de decisiones por el nivel de gestión adecuado. Como podemos ver en el siguiente esquema explicativo.
Figura 61: Enfoque del control del progreso según PRINCE2®.
Este control se consigue en PRINCE2® a través de delegación de autoridad de nivel superior a inferior, dividiendo el proyecto en fases de gestión, autorizando cada fase de forma progresiva, realizando revisiones, presentando informes sobre el progreso basadas en tiempo y eventos y presentando excepciones cuando se prevea que se van a superar las tolerancia definidas en cada nivel de gestión. Esta estrategia de control del progreso se debe documentar en la documentación de inicio del proyecto, en concreto en IP. De hecho, con objeto de poder delegar y marcar un nivel de capacidad de actuación del nivel inferior de gestión (umbral de control), un proyecto PRINCE2®, tiene tolerancias definidas para cada objetivo. Las tolerancias se fijan para 6 objetivos (de un nivel al siguiente): tiempo, coste, calidad alcance, riesgo y beneficio. Si se prevé que se van a superar las tolerancias, se debe involucrar al nivel superior para que tome una decisión sobre la manera de actuar. También se debe implementar un mecanismo de control y de garantía, de forma que cada nivel de gestión tenga la confianza de que no se sobrepasan las tolerancias permitidas.
91
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Figura 62. Niveles de delegación según PRINCE2®.
Como se puede ver en el esquema anterior, la delegación es descendente y la toma de decisiones sobre exceso de tolerancias, ascendente. Se deben establecer controles de forma que se pueda detectar si se van a superar las tolerancias. Además de establecer mecanismos de garantía de modo que cada nivel de gestión pueda tener confianza en que dichos controles son efectivos. 2.3.6.
Gobernanza del proyecto; roles y responsabilidades definidas
Al igual que en cualquier organización, para conseguir la mayor eficiencia y evitar conflictos entre el equipo de proyecto o en general con cualquier stakeholder, es fundamental que se identifiquen los roles dentro del proyecto, así como se definan sus obligaciones y responsabilidades, desde el inicio hasta la finalización del proyecto. Así, es clave que se identifiquen las líneas de toma de decisiones o procedimientos de escalamiento, para que no queden dudas sobre quien deberá tomar una decisión. En primer lugar, se debe analizar y determinar cuál va a ser la relación del proyecto con el resto de la organización, ya que ésta puede influir es el mismo, pues no hay que obviar que la gestión de proyectos ‐y en concreto la organización temporal que se crea para desarrollarlo‐ se da dentro de una estructura organizativa más amplia (la de la propia empresa u organización). Evidentemente hay muchos tipos de estructuras organizativas, pero en el PMBOK® [35] se definen las más importantes a tener en cuenta en lo relativo la manera en la que se pueden gestionar los proyectos. A continuación se señalan los tipo de estructuras más representativas:
92
Estructura funcional: Es el esquema más tradicional, donde los directores de los departamentos o funciones son los que coordinan y dirigen los proyectos.
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
Figura 63: Estructura funcional.
Estructura proyectizada: Toda la organización se orienta al proyecto y éste dispone de los miembros del equipo al 100%, no compartiéndose con otros proyectos.
Figura 64: Estructura proyectizada.
Estructura matricial: Es una combinación entre las dos anteriores, de forma que el director del proyecto es el que dirige a los diferentes miembros del equipo aportados por los diferentes departamentos. Hay que tener en cuenta que cada uno de ellos deberá responder ante su responsable funcional en lo relativo a sus funciones laborales.
93
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Figura 65: Estructura matricial. Elaboración propia.
Estructura de decisión del proyecto (gobernanza) Una vez determinada la situación del proyecto dentro de la estructura organizativa, es conveniente establecer los niveles de decisión. En una de las estancias superiores ‐desde el punto de vista jerárquico‐, se encontraría la junta de proyecto (JP o project board), también denominada comité de seguimiento o steering committee. Esta junta siempre debe estar liderada por una figura que tenga capacidad de influencia en la organización y en los recursos, siendo la persona responsable de la toma de las decisiones más importantes delegadas por la propia organización. Esta figura se denomina patrocinador (PAT), sponsor o ejecutivo ‐en PRINCE2®‐. En cualquier caso, será el máximo responsable de un proyecto de cara a la organización y será quien tome las decisiones más importantes del proyecto, debiendo aclarar y definir el alcance del mismo así como asegurar la obtención de la financiación requerida para el desarrollo del mismo. Pero esta figura no es quién realizará el trabajo de gestión diaria del día a día, sino que esta labor la realizará el director de proyectos, a quien corresponde la labor de realización de la planificación y de la gestión diaria. Esta figura debe estar completamente involucrada con el desarrollo del proyecto, pero no es suficiente, ya que para poder dirigir y tomar las decisiones correctas, también debe arroparse del asesoramiento de un grupo de expertos que le apoyen en esta difícil tarea, de forma que si el proyecto sólo dispone de un único patrocinador comprometido sin más apoyos, probablemente no se podrá obtener lo mejor del proyecto [130]. El apoyo de la organización materializada por su dirección es fundamental para el éxito del proyecto, ya que tiene que apoyar al patrocinador y, por ende, al resto de la organización creada para el desarrollo del mismo, lo que se traduce en una mejor relación entre el beneficio obtenido por el proyecto y el apoyo recibido por la alta dirección corporativa [131]. El director del proyecto En la filosofía y metodologías de dirección integrada de proyectos, para que todos los procesos se establezcan correctamente es necesario que exista un agente que disponga de una visión global del proyecto y que sea capaz de gestionar todos los recursos desde una óptica integradora, balanceándolos de forma que se consiga obtener un resultado equilibrado. Esta es la figura del director o responsable del proyecto (DP), también conocido como project manager o gerente de proyecto. Este es el que va a asumir el rol de coordinación de todos los agentes y recursos necesarios y los va a dirigir hacia la consecución de los objetivos marcados en la fase inicial del proyecto. Su principal responsabilidad es que el proyecto cumpla sus objetivos y cubra las expectativas de los principales agentes, debiendo cumplir funciones [132] tales como el desarrollo de los planes del proyecto, el liderazgo del proyecto 94
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
y de su equipo, la identificación y valoración de los interesados del proyecto y, en general, deberá encargarse de gestionar las diferentes áreas del proyecto y hacer que éste se mantenga y termine dentro de los objetivos establecidos. El equipo de gestión del proyecto Son los encargados de desarrollar el proyecto y de gestionarlo a nivel diario. Los miembros del equipo de proyecto pueden estar localizados en un mismo lugar –localización‐ o por el contrario pueden encontrarse localizados en diferentes lugares incluso países distintos (equipos virtuales) [133]. Cabe señalar que, conforme aumenta la interacción virtual entre los miembros del equipo, se reduce su capacidad de coordinación a la hora de la realización de las tareas del mismo [134]. De hecho, se ha podido comprobar que uno de cada dos equipos deslocalizados han fracasado en el desempeño de sus proyectos [135], lo que lleva a pensar que los líderes de los proyectos virtuales tienden a infravalorar el nivel del liderazgo compartido entre todos los miembros del equipo, viéndoles reducido el rendimiento del mismo [136]. El enfoque de PMI® es el siguiente, como se puede apreciar en la Figura 66:
Figura 66: Relación entre los stakeholders del proyecto. Fuente: PMBOK®.
En la misma puede verse cómo el PM, tiene una relación de dependencia hacia el sponsor o promotor del proyecto y, junto con su equipo de gestión, son los que interactúan con la gestión del proyecto. Las figuras clave en la gestión del mismo son, precisamente, el Patrocinador ‐sobre quien la organización ejecutante delega la responsabilidad de desarrollar el proyecto según los parámetros y objetivos que ésta desea‐ y el director del proyecto. Por lo que se puede afirmar que el máximo responsable del proyecto es esta figura, el patrocinador. De hecho una de sus prerrogativas es la de hacer que el resto de los miembros de su equipo trabajen como un equipo, pues esto hace que el rendimiento del desempeño global sea mayor frente a si se realiza de forma individual [72]. Así pues, el liderazgo es una de sus principales habilidades, debiendo ser ejemplo para su equipo [50]. A pesar de lo que se ha señalado en el punto anterior, la gestión del día a día del proyecto no va a ser realizada por el patrocinador, sino que éste va a nombrar al director de proyecto (en algunos casos con la ratificación de la organización ejecutante) y será sobre él sobre quién el patrocinador delegue estas tareas. De hecho, se puede apreciar como en realidad se encuentra fuera del equipo de proyecto. Es por ello, por lo que las decisiones importantes en el proyecto serán tomadas el patrocinador, pero éste no lo podrá hacer sin la información precisa y a tiempo que le deberá reportar el director del proyecto. Como se analizó en el punto dedicado a la gobernanza del proyecto, cuando éste se desarrolla a nivel de programa, el rol de patrocinador lo desempeña habitualmente el program manager (director del programa). Además, el equipo de proyecto deberá relacionarse con el resto de agentes o stakeholders como son: Cliente / usuario. Representantes del usuario. Sponsor, promotor o patrocinador del proyecto. Gestores de portfolio. Gestores de programas. PMO project management office u oficina de proyectos. Es una entidad que da apoyo y soporte al proyecto desde el punto de vista de la aportación de las buenas prácticas, formación y captación de la información de
95
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
los proyectos para su análisis conjunto. Puede ser parte de la propia organización del proyecto o de la organización [137], ya que puede dar apoyo al desarrollo de programas o porfolios [138]. Project managers. Equipo de proyecto (project team). Gestores funcionales o administrativos. Gestores de operaciones. Vendedores o socios de negocio. Proveedores. Expertos de apoyo. Enfoque del PMBOK® La gobernanza del proyecto se establece de forma análoga a la MGIP y a la ISO 21.500 y a través, por tanto, de un modelo delegativo. La organización delega la toma de decisiones clave y nombra como máximo responsable al PAT, quien a su vez delega en el DP la gestión diaria del proyecto, quién gestionará tanto al resto de agentes como a su propio equipo de proyecto. De hecho la diferencia que se puede observar entre el enfoque del PMBOK® (también ISO 21.500:2.012) y PRINCE2® es que en los dos primeros sólo se tratan los procesos que involucran al PM mientras que en éste último y en el MGIP, también se identifican procesos directivos que desarrolla el PAT o la JP. Enfoque ISO 21.500:2.012 En el siguiente esquema perteneciente a la norma ISO 21.500:2.012, se puede contemplar otra representación de lo expuesto hasta ahora. Así, se aprecia claramente la relación entre el patrocinador y el director del proyecto. La visión es coincidente con PMBOK®.
Figura 67: Agentes interesados y su relación. Fuente: ISO 21.500:2.012.
Vemos como el patrocinador pertenece al comité de dirección del consejo o junta de proyecto (project board), y es su cabeza visible y responsable. El patrocinador será el que se relacione directamente con el project manager y en quien delegará la gestión del proyecto. También se puede establecer un comité de seguimiento del proyecto (steering committee), formado por los representantes clave del proyecto y que se relacionarán directamente con el director del proyecto conforme el proyecto se vaya desarrollando. Dependiendo de la estrategia del proyecto y del nivel de confianza que el patrocinador tenga en el director de proyecto, se determinarán el número de fases y así como los umbrales de gestión del alcance, tiempo y coste, en los que éste podrá tomar decisiones directamente. 96
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
El enfoque de PRINCE2® Se va a desarrollar en el tema de organización, respondiendo a la pregunta ¿quién?, siendo el propósito del mismo el de definir y establecer la estructura de responsabilidades y delegación del proyecto. De hecho y según PRINCE2® un equipo de gestión debe tener representantes de los usuarios, los proveedores y de la parte de negocio (la que asegura la rentabilidad del proyecto). También debe definir los niveles de autorización con claridad, revisando los roles establecidos a lo largo del ciclo de vida del proyecto de forma que se asegure que son los adecuados en cada momento del proyecto así como debe contar con una estrategia de comunicación efectiva entre los agentes. PRINCE2® no define puestos de trabajo individuales, sino roles. Estos se pueden compartir o combinar, dependiendo del proyecto, pero hay que asegurarse que las responsabilidades siempre se asignen. En todo proyecto, siempre tiene que existir representantes de las tres categorías principales de las partes interesadas y de hecho el éxito en la gestión del proyecto se basará en que los tres roles trabajen de forma conjunta y colaboren activamente para la consecución de los objetivos establecidos. Esta partes interesadas son: Estos roles son: Comercial o de negocio: el rol del ejecutivo (EJ); se define para velar por la validez comercial del proyecto, en concreto debe tener una buena relación calidad‐precio, debe asegurar que el proyecto es viable, por lo que es el responsable del business case y debe también asegurarse de que éste esté alineado con los objetivos y la estrategia de la organización o del programa, en su caso. Usuario principal o senior (UPAL): son los que utilizarán los resultados del proyecto cuando este se haya completado, o bien los que operarán con él o lo mantendrán o, simplemente, tendrán un impacto en ellos. En casos donde el usuario es externo a la organización, también deberá ser representado (por ejemplo por alguna persona perteneciente al departamento de marketing o ventas). Así, debe ser el que especifique los requisitos del proyecto y defina el alcance, de forma que los productos obtenidos realmente los pueda usar. Además de ello, deberá explicar los beneficios que supondrá para la organización el producto del proyecto, una vez finalizado. Proveedor principal o senior (PPAL): En este rol se integran los proveedores internos o externos que serán los que aportarán recursos y conocimiento y ejecutarán el proyecto. Debe asegurar que los productos del proyectos se pueden fabricar tal y como se necesitan. Estos roles se desarrollan en los diferentes niveles jerárquicos dentro de la organización, como podemos ver a continuación:
Figura 68. Niveles de la organización según PRINCE2®.
97
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Las funciones principales en cada nivel son: Nivel corporativo o del programa. Está fuera del equipo de proyecto, y fundamentalmente encarga el proyecto a través del mandato del proyecto, nombra e identifica al ejecutivo y marca las tolerancias de la junta de proyecto. Nivel de dirección. Son responsables de la gestión global del proyecto y del éxito del mismo, de forma que aprueba los planes, autoriza desviaciones del nivel inferior de gestión, aprueba el final de fase y el inicio de la siguiente. Es un rol fundamental y de hecho, no se puede compartir. Nivel de gestión. Corresponde a la gestión diaria del proyecto y, por tanto, al director del proyecto, quien debe asegurarse de que se produzcan los productos del proyecto según los objetivos. Al igual que con el ejecutivo, el rol de project manager no se puede compartir. Nivel de entrega de productos. Son los responsables de la entrega de los productos, con la calidad apropiada, en tiempo y costo adecuados y, por tanto, de la ejecución del trabajo especializado en el proyecto. A continuación se pasa a desarrollar las funciones de cada una. La junta de proyecto (JP). La junta determina a la persona que será la responsable de desarrollar el proyecto según las indicaciones (mandato) de la organización y siempre dentro de las tolerancias permitidas, por lo que es la responsable de rendir cuentas tanto del éxito como del fracaso del proyecto a la organización. Siendo algunas responsabilidades importantes de la junta la de dar dirección unificada al director de proyecto, facilitando la integración del equipo de proyecto con el resto de la organización. Asimismo, es la responsable de proveer de recursos y autorizar los fondos necesarios para el proyecto. Al frente de la JP, se encuentra el ejecutivo (EJ), quien es el último y máximo responsable de la misma y, por tanto, es el principal encargado a la hora de tomar decisiones. Algunas características importantes de este rol es que es el responsable del business case o estudio de viabilidad y nombra al resto de miembros de la junta del proyecto. Los otros roles componentes de la junta de proyecto son el usuario principal, que demás de lo expuesto en puntos anteriores, debe servir como enlace entre el usuario y el equipo de gestión del proyecto, además de que debe asegurarse de que la solución satisfaga las necesidades de los mismos, y el proveedor principal (PPAL) es el responsable de la calidad de los productos y de la integridad técnica del proyecto. Entre sus funciones se incluye la de asegurar que las propuestas de diseño y desarrollo de los productos, sean factibles y realistas. También representará a los que mantendrán los productos una vez se acabe el proyecto. En este caso, también podría ser este rol desempeñado por el usuario principal. Lo importante es que esté representado. De hecho, en ocasiones la organización es reacia a incluir a proveedores externos por miedo a que se pueda filtrar o divulgar información sensible corporativa, pero la no inclusión podría ralentizar el proyecto. La decisión de incluirlo o no, será del ejecutivo. Para garantizar que el equipo de proyecto esté gestionando el proyecto conforme a las políticas de la organización y correctamente, la JP puede establecer lo que se denomina La garantía del proyecto que pertenece, por tanto, a la junta de proyecto debiendo ser independiente al director de proyecto. Mediante este rol hacen seguimiento de todos los aspectos de rendimiento del proyecto y de los productos generados. Algunas características importantes de este son que además de servir como control (auditar), también deben dar apoyo al director de proyecto: orientación y asesoramiento especializado en cada área que representan. De hecho, el director de proyecto nunca podría pertenecer a la garantía del proyecto. A la hora de gestionar y autorizar los cambios en el proyecto se puede establecer una autoridad de cambios. Es responsabilidad de la junta de proyecto la toma de decisiones sobre los asuntos que sobrepasen las tolerancias de gestión del director de proyecto, si bien puede delegar esta faceta en un organismo, dependiente de ella y que se denomina autoridad de cambios. De hecho en todos los proyectos se producen cambios, por lo que la junta de proyecto, debe establecer los mecanismos para dar respuesta rápida y eficaz a cada solicitud de cambio. En la estrategia de gestión de la configuración, se deben establecer una escalas de clasificaciones según la importancia o el impacto del cambio solicitado, de forma que cuando éste se planté, ya se haya establecido un criterio sobre qué nivel de gestión deberá hacerse cargo. En el nivel de gestión se sitúa el director de proyecto o project manager quien es el único responsable de la gestión diaria del proyecto. Lo hace en nombre de la junta y dentro de su umbral de control establecido. Siendo el responsable de todos los procesos de PRINCE2® (salvo el de dirección del proyecto y el de gestión de entrega de productos, que puede delegar en el team manager, pero si no hay team managers, el el director del proyecto asume el rol). También se puede establecer un área de apoyo del proyecto, pero al igual que pasa con los team managers no es obligatoria su existencia y el director de proyecto asumiría ese rol, aunque puede compartirlo con su equipo. En el último nivel de gestión se encuentra el de entrega de productos, y el rol principal es el del team manager siendo su principal función la de asegurar la producción de los productos especializados asignados por el director del 98
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
proyecto. Éste recibe instrucciones del director del proyecto y le rinde cuentas. En PRINCE2®, se utilizan los paquetes de trabajo para asignar trabajo a los TM, por lo que no son obligatorios. Así, una vez analizados los diferentes roles, se pueden esquematizar según la Figura 69:
Figura 69. Los roles en un proyecto según PRINCE2®.
Los roles principales en el MGIP En el MGIP se van a definir los siguientes roles principales en la gestión del proyecto, estructurándose en cuatro niveles de decisión: el superior, ostentado por la organización (o por la dirección del programa en caso de encuadrarse el proyecto en uno); el nivel de dirección, dominado por la junta de proyecto y liderado por el patrocinador. Seguidamente estaría el nivel de gestión del proyecto, propiedad del director de proyecto y, finalmente, estaría el nivel de entrega, en donde se ejecutará el trabajo en el que los diferentes equipos de trabajo o team managers, producirán los diferentes productos especializados o entregables.
99
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Figura 70: Niveles de decisión y roles en MGIP.
2.3.7.
Adaptación del proyecto al entorno
Los tres enfoques que se tratan en esta tesis son genéricos y sirven para todo tipo de proyectos. Pero podría ser negativo y contraproducente gestionar cualquier tipo de proyecto con el mismo nivel de control, independientemente de la consideración de su tamaño, complejidad, necesidad de control y recursos humanos disponibles para ello. Por lo que si no se adaptan a cada proyecto concreto, se corre el riesgo de que no sea éste eficiente y, o bien, que se dedique demasiado tiempo a su control (lo que se suele denominar como gestión robótica) o, bien, por el contrario que no se establezcan los niveles mínimos de control, no disponiendo, por tanto, de información ni control suficiente (lo que se denomina, gestión heroica). Es por ello, por lo que el hecho de dimensionar y seleccionar tanto los procesos y las herramientas a utilizar para cada proyecto concreto, se antoja como una aspecto clave que el DP debe acometer y ‐posteriormente y antes del inicio del mismo‐ debe refrendar la JP, de forma que se desarrolle éste de forma consensuada. Sus objetivos son: Asegurar que el método de gestión del proyecto se relacione correctamente con su entorno del proyecto. Asegurarse que los controles del proyecto se basen en la complejidad, importancia y nivel de riesgo del proyecto. De hecho, en los tres marcos analizados, esta actividad de dimensionamiento y selección del enfoque más adecuado para el proyecto, se realiza durante el proceso de planificación, de forma que el plan de gestión del proyecto o el plan de proyecto, contemple estos aspectos. 2.3.8.
Aprender de la experiencia
Como decía Oscar Wilde “experiencia es el nombre que cada uno da a sus errores”. Actualmente muchas compañías pueden considerarse como organizaciones basadas en el desarrollo de proyectos, lo que significa que la mayoría de sus productos o servicios son producidos a través de proyectos, tanto para ser entregadas a clientes internos o externos [139]. Para ellas, el aprendizaje a través y desde los proyectos, está siendo más importante para alcanzar una mayor competitividad [140‐143]. Por lo que existe una necesidad para implementar un sistema orientado hacia la 100
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
gestión del conocimiento en la gestión de proyectos [144]. Así, la base del conocimiento del DP y de la organización se basa en las lecciones aprendidas, por lo que todos los participantes son responsables de buscarlas, localizarlas y comunicarlas. De hecho, al iniciar un proyecto, se deben buscar experiencias anteriores, incluso de otros consultores u organizaciones, de forma que no se repitan los errores ya cometidos y se aproveche el conocimiento existente. Así este conocimiento, puede llegar a través de la formación y, de hecho, existen investigaciones que demuestran que la formación del equipo es efectiva y genera un impacto positivo en la organización [145]. También se debe hacer durante el desarrollo del proyecto, localizando aspectos que puedan mejorarlo. Y por supuesto, en la fase de cierre del proyecto, al objeto de asegurarse de que las lecciones son recopiladas. Si las lecciones aprendidas no provocan cambios, se denominan lecciones identificadas. Una vez finalizado el proyecto, parece evidente la necesidad de analizar los resultados y recapitular lo que ha pasado en el mismo para construir una idea clara y concisa de si se han podido cumplir los objetivos y de la utilidad futura del trabajo realizado. De hecho, la realización de un proyecto es una oportunidad de aumentar el conocimiento de la organización que generará efectos muy positivos en la misma, a saber: Mejor posicionamiento en el mercado, aumentando la eficiencia y la capacidad para competir con la competencia en una mejor situación. Generar una base de buenas prácticas para que los siguientes proyectos se aprovechen de las cosas que han salido bien y mal. Desarrollo y perfeccionamiento de los procesos de la organización. Minimizar los errores futuros. Disponer de información para realizar estimaciones fiables, de forma que el nivel de incertidumbre del proyecto futuro se reduzca y por tanto también las reservas de contingencia y gestión necesarias. De esta forma, si no se dispone de un sistema de captación de las buenas prácticas, almacenamiento y distribución, este conocimiento puede desaparecer con los consiguientes perjuicios para la organización. Dependiendo de las capacidades y recursos disponibles de cada una, se podrá establecer una determinada estrategia para ello. Las lecciones aprendidas las puede identificar cualquier agente, y es función del director del proyecto recoger los datos y proponer la adopción de las lecciones aprendidas para la incorporación a los procesos y conocimiento de la organización. En cualquier caso, estas lecciones identificadas, pueden o no ser incorporadas. Esta decisión la deberá tomar la organización, así como el alcance de la misma; a nivel de proyecto, programa o APO.
Figura 71: Proceso de incorporación lecciones aprendidas.
Este análisis de lecciones aprendidas se puede realizar en cualquier momento del proyecto. De hecho en PMBOK® se puede ver como en todos los procesos de control y ejecución aparece como una salida la actualización de los factores ambientales de la empresa o FAE en los que se incluyen, además de las características propias de cada empresa u organización, el conocimiento propio generado con las lecciones aprendidas. En cualquier caso, en el proceso de cierre se debe completar y recopilar todas las del proyecto. En ISO 21.500:2.012 existe un proceso específico para la gestión de las lecciones aprendidas y el conocimiento que éstas generan en la organización: el 4.3.8. Y de hecho se refuerza la idea de que no sólo hay que utilizar las lecciones aprendidas una vez finalizado el proyecto, sino que éste se puede beneficiar de las experiencias que se van produciendo durante su desarrollo. Además los proyectos de su entorno también pueden afectar y verse afectados mutuamente entre ellos, ya que es muy beneficioso que este conocimiento 101
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
esté lo más actualizado posible. En PRINCE2® ocurre lo mismo y, de hecho, en el proceso de cierre de proyecto CP, se dispone de la actividad de evaluar el proyecto, en la que se produce lo expuesto anteriormente.
2.4.
Áreas de conocimiento aplicables a la gestión de un proyecto
Como se ha expuesto anteriormente, el MGIP se basa en la creación y distribución de los procesos entre las diferentes fases de gestión FGP y las áreas de conocimiento o temas AAC. Las AAC describen los aspectos que se aplican a los proyectos a lo largo de su ciclo de vida y que basándose en los principios de gestión, consiguen que los procesos tengan una base sólida. En el PMBOK® se denominan áreas de conocimiento y en la ISO 21.500:2.012 se califican como grupos de materias, organizándose los procesos de forma ordenada. En PRINCE2® se denominan temáticas y, como se ha expuesto, se deben abordar a lo largo del proyecto y de forma paralela. En la Tabla 4 se indican cada uno de ellos y cuáles son los que se han incluido en el MGIP: MGIP
PMBOK®
ISO 21.500:2.012
PRINCE2®
Justificación Comercial
Integración
Integración
Business Case
Integración
Integración
Integración
Plan, Cambio, Progreso
Alcance
Alcance
Alcance
Calidad, Plan, Progreso
Tiempo
Tiempo
Tiempo
Plan, Progreso
Costo
Costo
Costo
Plan, Progreso
Calidad
Calidad
Calidad
Calidad
Recursos
Recursos Humanos
Recursos
Plan
Comunicación
Comunicación
Comunicación
Organización
Riesgos
Riesgos
Riesgos
Riesgos
Adquisiciones
Adquisiciones
Adquisiciones
‐
Interesados
Agentes
Parte interesada
Organización
Tabla 4: Homologación de las áreas de conocimiento en el MGIP.
Así, del análisis comparativo entre ellos, se puede apreciar que existen algunas temáticas que se tratan en todos los marcos de gestión de proyectos y que coinciden con bastante exactitud, a saber, las de calidad y riesgo. Estas dos áreas o temáticas son básicas en la gestión de un proyecto y ello con independencia del tipo de metodología o enfoque con la que se deban aplicar. De hecho, se desarrollan de forma más amplia en otros estándares, así como en cuerpos de conocimiento más general, siendo aceptadas por las metodologías en gestión de proyectos. Por ejemplo, se adopta el enfoque de la familia de normas ISO 9.000 para el área de calidad y, en el caso de la gestión de riesgos, PMI® dispone del Practice Standard for Project Risk Management, así mismo en AXELOS (PRINCE2®)[46] se ha desarrollado el M_o_R [49], e ISO dispone de normas específicas de gestión de riesgos como la ISO 31.000 [146]. Es de destacar que se puede encontrar un tema o área como las adquisiciones, las cuales no se incluyen en alguno de los anteriormente referidos enfoques, como en este caso en PRINCE2®. De igual manera esto ocurre con la temática de recursos humanos ya que en PRINCE2® no se tratan habilidades de gestión de equipos tipo soft, en cambio sí son tratados los recursos a nivel general, sobre todo en la temática de plan o planes en cuanto se debe confirmar que los recursos existen y que se encuentran disponibles, con el fin de poder desarrollar el cronograma del proyecto. De hecho, se pueden apreciar otros temas que se denominan de forma distinta, pero tratan el mismo aspecto, como son los interesados, el costo, el tiempo, el alcance o la integración, que en PRINCE2®, además, no se desarrollan en una sola temática sino en varias, como la justificación comercial y otras. Cabe señalar que en MGIP se han adoptado las áreas de conocimiento del PMBOK® como base, habiéndose a añadido a éstas una área adicional denominada justificación comercial, en la que se van a tratar los aspectos claves y fundamentales también descritos en PRINCE2®. Ello consolida la importancia de la necesidad de asegurar que el proyecto se desarrolle siempre bajo la comprobación continua de que el trabajo y los productos que se produzcan sean lo que necesita realmente la organización o el cliente y que ésta disponga de la oportunidad de poder replanificar o, incluso, cancelar el proyecto, si ello fuese necesario. Se ha considerado oportuno, siguiendo la tendencia marcada en la ISO 21.500:2.012 ‐y que aparece en la propuesta de revisión de la nueva edición del PMBOK® 6th cuyo avance ha 102
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
publicado PMI y que tiene previsto salir a la luz en 2.017 [147]‐, el analizar en la temática de recursos, no sólo los humanos y el equipo del proyecto, sino aportar una visión más amplia y gestionar también otro tipo de recursos físicos. A continuación se pasa a analizar de forma más amplia cada una de las áreas de conocimiento indicadas, al objeto de poder ofrecer una visión general de las mismas. Si bien no está dentro de los objetivos de esta tesis, sí se considera oportuno indicar los aspectos clave adoptados por el MGIP y, sobre todo, las diferencias que se tratan en cada enfoque en lo relativo a su adaptación al MEGIP. 2.4.1.
Viabilidad y justificación comercial del proyecto
Descripción y enfoque del MGIP Hay que recordar que el proyecto no es un fin por sí mismo, sino el medio para conseguir los beneficios deseados por la organización o el cliente, y por eso, en cada momento a lo largo de su ciclo de vida, se tiene que asegurar que el trabajo que se está realizando en el proyecto está alineado con los objetivos que se pretenden conseguir. De lo que se deriva de que ningún proyecto debería empezar sin que se haya identificado su justificación comercial y que además ésta podría desaparecer o cambiar a lo largo del ciclo de vida, y si esto sucediese, el proyecto deberá paralizarse, modificarse o cancelarse dependiendo de la decisión de la organización. De lo expuesto en el párrafo anterior, se deriva que esta área de conocimiento tiene el objetivo de identificar las razones que demuestran que el proyecto es apetecible, viable y deseable por la organización o el cliente y por lo tanto merece la pena invertir recursos para conseguirlo. Además se debe comprobar constantemente a lo largo de su ciclo de vida y también, en momentos clave predeterminados, cuál es la situación real del proyecto, analizando tanto el desempeño realizado, como el entorno, los riesgos y la situación de la necesidad inicial que desencadenó la decisión del inicio del proyecto, de forma que sea la propia organización quien pueda tomar decisiones y oportunas sobre la continuidad del mismo en el momento adecuado. De esta forma, se puede apreciar que en la FGP de análisis previo que el objetivo fundamental es el de buscar identificar claramente la causa de la necesidad del proyecto y si ésta es los suficientemente apetecible para la organización, podrá pasar hacia la siguiente FGP. Hay que hacer notar que para que se pueda tomar la decisión con conocimiento de causa, se generará un grupo de información que se denomina documentación de la necesidad del proyecto DNP. En ella se incluirá un estudio de viabilidad con la información mínima suficiente para la toma de la decisión se pueda realizar. En cualquier caso, la organización puede disponer de un estudio de viabilidad previo realizado por ella misma o por un agente externo, pero en los procesos incluidos en esta FGP se obliga realizar las acciones necesarias para recopilar la información adecuada y realizar los análisis o estudios oportunos para disponer de una visión mínima suficiente para que se pueda tomar una decisión con bases lo más objetivas posible. Dentro de la lógica del MGIP, se considera que esta colección de información inicialmente poco detallada, irá desarrollándose y completándose conforme el proyecto vaya avanzando en las FGP y se disponga de más información sobre el mismo. Así, en la FGP de Inicio se desarrollará la DAP (documentación de arranque del proyecto) en la que se incluye es EVP (estudio de viabilidad preliminar) que es una evolución del EVI (estudio de viabilidad inicial del negocio) desarrollado en la fase anterior. Con esa documentación recopilada (DAP), se podrá pasar a la siguiente FGP en la que se autoriza el inicio del proyecto y por tanto se iniciaría la fase de planificación, en la que se volverá a perfeccionar el estudio de viabilidad, una vez desarrollado el plan completo del proyecto. En este punto se dispondrá del estudio de viabilidad definitivo EVD, que servirá como base line o producto de gestión sobre el que se irá midiendo y comparando la situación del desempeño del proyecto. También se genera el plan de materialización de beneficios PMB en el que se explicitará cómo y cuándo se generarán los beneficios del proyecto, durante la duración del desarrollo del mismo o incluso cuando éste termine y pase a un entorno de operaciones. En esta FGP se autoriza por tanto, el paso a la fase de ejecución y control, donde se ejecutará el trabajo del proyecto. Así, en la fase de ejecución se van desarrollando las fases del CVP propias de cada proyecto y conforme éstas se vayan completando, será necesario volver a valorar la justificación comercial del proyecto. En caso de que estemos en la última fase del ciclo de vida del proyecto, se activaría el cierre del mismo lo que se incluye en la FGP de cierre. En ésta se actualiza el plan de materialización de beneficios, siendo éste ya definitivo (PMBD) y el que usará la organización para comprobar la consecución de los objetivos deseados una vez finalizado el proyecto y cundo el producto del proyecto esté siendo operado. También se deberán recopilar las lecciones aprendidas que hayan sido identificadas en el proyecto, de forma que se puedan determinar las que se incorporarán al conocimiento de la compañía.
103
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
El enfoque del PMBOK® Esta área se trata en el área de conocimiento de la gestión de la integración en la que para que se generara el acta de constitución se tiene como entrada el business case o estudio de viabilidad que puede ser generado tanto por la organización o por cualquier otro agente, de forma que en el documento del acta, incluye los parámetros o ratios que indican y demuestran la viabilidad del proyecto. Conforme se desarrolla el proyecto y se valoraran los posibles cambios, constantemente se valora que la previsión del proyecto quede dentro de los límites del acta, considerando por tanto que estando dentro de ellos, se mantendría la justificación del proyecto. El enfoque de ISO 21.500:2.012 Análogo al enfoque de PMI® El enfoque de PRINCE2® La justificación continua del proyecto es una temática propia de PRINCE2® y se basa en el principio denominado de justificación continua siendo su propósito el de establecer los mecanismos apropiados para juzgar si el proyecto es (y se mantiene) deseable, viable y alcanzable, siendo por tanto un medio para apoyar la toma de decisiones en la inversión (continua) de los recursos de la organización propietaria del proyecto. En esta temática el responsable es el ejecutivo, pero puede delegar el desarrollo de la operativa para valorar la viabilidad a un tercero (consultor, director de proyecto, etc.). De hecho es el responsable que los beneficios esperados del proyecto tengan una buena relación calidad‐precio y que estén alineados con los objetivos y necesidades de la organización. Respecto de la especificación de los beneficios esperados y deseados hay que indicar que son los usuarios principales los responsables. El documento clave a la hora de valorar la viabilidad de un proyecto es el business case o estudio de viabilidad. De hecho en él se encuentra la mezcla óptima de información utilizada para juzgar si el proyecto es (y se mantiene) deseable, viable y alcanzable y, por consiguiente, algo en lo que merece la pena invertir. En general, se puede decir que se demuestra que el proyecto es viable a través del business case. Por lo que el objetivo principal del citado documento sería el exponer la forma en que el proyecto puede alcanzar los beneficios deseados, y por tanto disponer de un mejor entendimiento del mismo. El el estudio de viabilidad se deben concretar los siguientes aspectos: Resultado (output): Es cualquiera de los productos especializados del proyecto (los productos que genera el proyecto). Resultado final (outcome): Es la consecuencia del cambio derivado del uso de los resultados del proyecto. Beneficio (benefit): Es la mejora medible que se obtiene de un resultado final que es percibido como ventaja por una de las partes interesadas. Su relación se puede apreciar en el Figura 72:
Figura 72: Relación entre resultado, resultado final y beneficios. 104
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
Los usuarios principales son los agentes que tienen la responsabilidad de definir los beneficios esperados del proyecto y por tanto también lo son de mostrar que se han alcanzado, una vez finalizado éste. Su labor consiste en identificarlos, seleccionar los ratios objetivos que demuestren su consecución, recoger datos de gestión y decidir cómo, cuándo y quién recogerá las mediciones de los beneficios. Se podrían concretar los diferentes puntos de control que se deberían realizar en un proyecto. De esta forma y en primer lugar se debería verificar al final de la fase de preproyecto (SU), al final de la fase de inicio o planificación (IP), y cada vez que el proyecto se enfrente a un asunto o riesgo, de la misma forma que cada vez que se finalice cualquier fase de su ciclo de vida una vez comenzado el desarrollo de la ejecución. Así, se observa que el BC va evolucionando y perfeccionándose conforme se dispone de más información en el proyecto. De hecho PRINCE2®, define dos tipos de BC, dependiendo básicamente del nivel de detalle, a saber:
Business case preliminar BCP: Se genera a partir del mandato del proyecto y se desarrolla antes de la decisión de arrancar el proyecto (durante el proceso de puesta en marcha o SU) y que, por tanto, debe aprobar la JP para que el proyecto pueda pasar a la siguiente fase. En el mandato del proyecto, puede existir un BC inicial. Si no lo hay, sería lo primero a realizar. Business case detallado BCD: se desarrolla a partir de los datos que contiene el BCP, del plan de proyecto y del registro de riesgos. Tiene carácter iterativo y se irá perfeccionando conforme se disponga de más información. Por lo que no se puede completar hasta que no se haya desarrollado completamente el plan del proyecto. Es un producto base line, es decir, que servirá para contrastar el rendimiento real del proyecto en cuanto a justificación comercial se refiere. En la siguiente figura se puede apreciar con detalle lo expuesto, así como en los eventos del proyecto, donde se deben confirmar la consecución de los beneficios definidos del proyecto.
Figura 73: Verificaciones y aprobaciones del business case a lo largo del ciclo de vida del proyecto.
Plan de revisión de beneficios PRB Para controlar que la justificación comercial del proyecto se cumple durante la vida del proyecto e incluso cuando el producto del mismo entre en un entorno de operaciones y confirmar que los beneficios de alcanzan, se debe desarrollar un plan denominado de revisión de beneficios del proyecto PRB, generado a partir del BCD, del calendario y de la obligatoriedad de realizar revisiones periódicas de la obtención de los beneficios esperados. Lo crea el director de proyecto en la fase de inicio y lo presenta a la junta para su aprobación en el mismo momento de la solicitud de aprobación del proyecto. De hecho, los beneficios que se definen en el PRB se gestionan siguiendo los siguientes pasos definidos en la Figura 74:
Figura 74: Pasos para desarrollar un plan de revisión de beneficios.
Algunos aspectos adicionales a tener en cuenta y que se considera oportuno resaltar son que es el ejecutivo el responsable de que las revisiones de beneficios se planifiquen y se realicen. Además los beneficios se pueden obtener durante el proyecto o en la fase post‐proyecto. En el primer caso deberán ser notificados por el director del proyecto en el informe final de cada fase y al finalizar el proyecto en el informe final de fase. En el segundo caso, la organización 105
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
será la responsable de medirlos, y podrá involucrar al usuario principal. En el BC se indica cuándo y cómo se van a generar los beneficios, por añadidura, en el PRB además, las responsabilidades y las actuaciones de revisión que deberán ser realizadas. 2.4.2.
Integración
Descripción y enfoque del MGIP Para que un proyecto pueda completarse, éste debe pasar por diferentes fases y estadios, a la vez que debe completar los procesos que el director de proyecto determine como necesarios y suficientes. En la gestión de proyectos es de vital importancia disponer de una visión global del proyecto, lo que permitirá balancear los las restricciones del mismo (en especial los componentes de la triple restricción) para alcanzar la satisfacción de los agentes intervinientes. Por tanto, los procesos de integración, que se describen en el MGIP son de gran relevancia, y de hecho, se desarrollan a lo largo de todo el ciclo de vida proyecto. Un aspecto fundamental y básico en la gestión de la integración es el control y gestión los cambios del proyecto a las diferentes líneas base. Ya que cualquier cambio que afecte a uno de los componentes de las líneas base y que coinciden con los de las triple restricción, afectará al menos a uno de los restantes. Así, desde la misma concepción e inicio del proyecto hasta su conclusión, como podemos ver en el siguiente esquema, se debe identificar su evolución o de trazabilidad, ‐concepto realmente interesante y que consistente en rastrear e identificar los cambios que se han producido desde la concepción inicial del proyecto y la situación actual‐.
Figura 75: La trazabilidad de un proyecto.
Este aspecto (la eficiente gestión de los cambios) es primordial en el desarrollo del proyecto, ya que es casi imposible que no se produzcan cambios ni modificaciones. Estas modificaciones, deben integrarse en todas las áreas de gestión ya que probablemente involucren diversos aspectos y áreas del proyecto. Así, la gestión de la integración del proyecto tiene mucho que ver con los cambios que se puedan producir. De hecho un proyecto puede modificarse por diversos motivos; como peticiones del cliente, mejoras comerciales, errores de diseño, reingeniería, cambio de calidades, aplicación de nuevas normativas, etc. Y también pueden ser solicitados por cualquier agente interviniente en el proyecto, si bien es el director del proyecto el que tiene que coordinar y gestionar tanto el proceso de recolección de las peticiones, como el de decisión y finalmente el de actualización e información del mismo al resto de la organización. Estas peticiones pueden ser realizadas verbalmente, si bien, para que éstas puedan ser gestionadas correctamente, deben transcribirse a un documento que contemple los detalles y la justificación de la petición. Es función del director de proyecto, el analizar el impacto que pueden producir tanto en el coste, la duración, el nivel de riesgo y/o las expectativas e intereses de los stakeholders. Normalmente, no es el director de proyectos el que tiene la decisión final para la implementación o no de un cambio, salvo que así se determine en los niveles de sus umbrales de control. En esta área de conocimiento además, se generan los documentos principales del proyecto en los que se plasma el compromiso del patrocinador y del director de proyecto a la hora de cumplir los objetivos del proyecto y de 106
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
garantizar que éstos están alineados con los de la organización y el cliente en su caso. Dichos documentos de gestión son el acta de constitución del proyecto ACP y el plan para la dirección del proyecto PDP. Funciones del director del proyecto en la integración del proyecto Además de lo expuesto en el punto anterior, podemos afirmar, que no existe una sola forma de gestionar un proyecto, de hecho, cada director de proyectos aplica a la gestión del mismo, sus conocimientos, experiencias y percepciones. Por lo que es factible que para un mismo proyecto, diferentes directores decidan utilizar distintos procesos, o aun utilizando los mismos, lo hagan con diferente intensidad. No obstante, esta distinta percepción no debe obviar considera todos los procesos. En cualquier caso, el director de proyecto junto con su equipo decidirá la forma en cómo hacerlo lo más eficientemente posible. De la misma manera que, si un proyecto involucra diferentes áreas y funciones, todas ellas deben ser tratadas con igual interés. El director del proyecto es la figura que dispone de la visión global del proyecto y por tanto es responsabilidad suya el determinar la situación del proyecto, teniendo en cuenta todas las áreas de conocimiento del proyecto, los riesgos a los que se enfrenta y el entorno del mismo. En el MGIP el AAP de integración recorre todas las FGP del proyecto, desde el análisis previo hasta el cierre, dotando al DP una visión global e integradora del mismo. Así, en el análisis previo se genera la información de arranque del proyecto, basada en las necesidades de la organización materializadas en el mandato del proyecto MP que ésta genera. Posteriormente en la fase de arranque se genera el acta de constitución del proyecto ACP ‐que como se ha indicado es uno de los documentos individuales clave del proyecto y que junto con el plan de fase para el inicio son los necesarios para desarrollar la posterior fase de planificación‐ y junto con el EVP, constituirán la documentación de arranque del proyecto DAP que es la base documental, tanto de la justificación comercial, como del trabajo a realizar en el proyecto. La DAP se completará y perfeccionará en el FGP siguiente como es la de planificación. En ella se desarrollará en plan de dirección del proyecto PDP que constituye el documento base de gestión del proyecto a nivel global y que define tanto el trabajo a realizar, el tiempo, costos y recursos que necesitará como la estrategia y los procesos a utilizar en el desarrollo del proyecto. Estará conformado por los diferentes planes subsidiarios o de gestión de cada una de las áreas restantes, así como las líneas base de alcance, tiempo y costo. Además se generarán los diferentes planes de fase PF en los que se detallará cómo se planificará la fase de entrega siguiente. Todos estos documentos compondrán la DIP (documentación de inicio del proyecto). En la FGP de ejecución y control, se ejecutará el trabajo definido en los diferentes planes expuestos anteriormente y se irá controlando y monitoreando éste respecto a lo planificado. De forma que también se controlarán los cambios analizados desde un punto de vista global, teniendo en cuenta todos los aspectos que la puedan afectar y que se deban considerar a la hora de la toma de la decisión. Conforme se va desarrollando el proyecto, se va actualizando la DIP y se va generando información del progreso del proyecto, lo que se denomina documentación de progreso del proyecto DPP. Finalmente en la FGP de cierre se procede a entregar el producto del proyecto al cliente, a registrar las lecciones aprendidas y a cerrar el mismo desde el punto de vista administrativo y de la organización generando el informe final del proyecto INFFP. El enfoque del PMBOK® “En el área de integración de los proyectos se incluyen los procesos y actividades necesarios para identificar, combinar, unificar y coordinar los diversos procesos y actividades en la gestión de proyectos, dentro de los grupos de procesos de dirección de proyectos” [35]. Sus características principales son la unificación, consolidación, articulación de las acciones integradoras para la terminación del proyecto. Además de integrar la gestión exitosa de las expectativas de los interesados y el cumplimiento de sus requisitos. Por lo que implica tomar decisiones en cuanto a la asignación de recursos, balancear objetivos y alternativas contrapuestas y manejar las interdependencias entre las áreas de conocimiento. Así, la integración, consiste en coordinar los trabajos y tareas, tomando decisiones, sobre dónde y cómo priorizar los recursos disponibles. Este análisis se debe realizar anticipadamente, y con suficiente antelación, de forma que se puedan anticipar los posibles problemas o incidencias y se adopten las soluciones más adecuadas en cada caso. El Equipo de proyecto, debe conocer que no existe una única aproximación a la gestión de un proyecto, sino que hay muchas. De hecho, el director de proyecto, debe tener en cuenta todos los procesos que se describen en el PMBOK®, pero no tiene porqué utilizar y desarrollarlos todos, sino que él –junto con su equipo‐, deberá decidir cuáles son los más adecuados y eficaces para conseguir el éxito de su proyecto.
107
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
El enfoque de ISO 21.500:2.012 El enfoque de ISO 21.500:2.012 es análogo al de PMI, salvo que en el grupo de procesos de cierre incluye de forma explícita un proceso en el que se recopilan las lecciones aprendidas del proyecto. El enfoque de PRINCE2® La integración del proyecto se logra a través de los temas de cambio y progreso, descritos en los principios de gestión planificada y actualizada y en el de adaptación al cambio y en la de planes en la que se describen los diferentes tipos de planes a utilizar en un proyecto. En cualquier caso, la toma de decisiones, además de ser tratadas en las temáticas descritas, también se trata de forma global en el proceso DP –dirigir un proyecto‐ en el que el nivel de gestión directivo toma las decisiones clave del proyecto como las requeridas en este proceso y en los procesos SU, IP, SB, DP en los que es necesario la generación de planes de distinto nivel. 2.4.3.
Gestión de los interesados del proyecto
Descripción y enfoque del MGIP Según PMI®, los interesados del proyecto o stakeholders son cualquier persona u organización (clientes, patrocinadores, usuarios, público, proveedores, sindicatos, asociaciones vecinales, organización ejecutora, etc.), que estén involucrados activamente en el proyecto o que sus intereses pueden verse afectados de manera positiva o negativa, tanto durante la ejecución del proyecto como una vez finalizado éste. Dependiendo de su implicación o afección por el proyecto, se pueden clasificar a los interesados en diferentes niveles, dependiendo de su relevancia en el proyecto. De forma que el esfuerzo del equipo del proyecto se priorice en los más relevantes, pero desde luego sin obviar as resto. En realidad hay que tener en cuenta a todos y valorar su implicación en el proyecto, para posteriormente decir la mejer estrategia para conseguir su implicación y apoyo. A partir del equipo de proyecto, existe un primer grupo de interesados, que son muy claramente afectados y que pueden influir en el mismo (clientes, patrocinador,...). Además podemos detectar otro grupo de agentes que si bien pueden verse afectados, no lo están al mismo nivel, serían secundarios. Del análisis de este concepto, se puede extractar que hay interesados que puede afectar al proyecto de forma clave, mientras otros son menos relevantes. Así, es función del director de proyectos, detectar a los interesados clave y focalizar sus esfuerzos en mantener (o conseguir) su apoyo para el proyecto. Cuanto antes se realice este análisis, mejores resultados se conseguirán, pero no hay que olvidar que la posición de los interesados puede cambiar a lo largo del ciclo de vida del proyecto, por lo que el director y su equipo deben realizar un seguimiento continuo y constante de ello, ya que el obviar u olvidar a un agente clave, puede poner en cuestión el éxito del proyecto. En la siguiente Figura 76, de Paul Roberts, se puede ver cómo éste clasifica a los interesados, de forma que posteriormente, se pueda diseñar una estrategia personalizada para aumentar su apoyo o atraer hacia el proyecto a los que no lo apoyen. Así como, también se puede apreciar en la figura que se expone a continuación, es básico identificar a los terroristas, es decir los agentes que tienen un alto poder o influencia y que además no apoyan al proyecto, de forma que el director del proyecto pueda establecer las estrategias apropiadas en cada caso para conseguir que estén a favor o al menos su actitud sea neutra respecto al mismo.
Figura 76: Clasificación de los interesados según Paul Roberts.
En cualquier proyecto, es obligatorio gestionar diferentes agentes y sus intereses. Éstos pueden ser coincidentes con los del proyecto, o por el contrario estar frontalmente en contra, pudiendo generar problemas y disfunciones que podrían llegar incluso a la paralización del proyecto. Así, según Madsen y Ulhøi [148] la gestión de los 108
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
agentes afectados o stakeholders puede mejorar las perspectivas del proyecto incluyendo cuantos más en la misma dirección que éste. Por lo tanto no es un tema desdeñable, sino todo lo contrario. De hecho se pude realizar un análisis de cada agente respecto a su posición de poder y apoyo [149], y según sean éste alto o bajo, o anti o pro respectivamente, localizar la posición y el posible efecto que pueda causar en el proyecto. Paul Roberts, [149] como se ha indicado anteriormente, desarrolló una matriz en la que según su posición en la misma de cada agente y siguiendo los criterios indicados establece cuatro posiciones básicas que lo agentes pueden tener respecto al proyecto: Terroristas: Los que más pueden afectar al proyecto, ya que tienen un poder de afección alto y un apoyo pequeño –anti‐. Uno de los objetivos de realizar una gestión sobre los stakeholders es la de conseguir que el mayor número de terroristas pasen a integrarse al proyecto. Promotores: Son los que impulsan y en gran manera desarrollan el proyecto. Protestones: Si bien hay que tenerlos en cuenta, no tienen capacidad de influencia en el proyecto. Pero no hay que olvidar que la gestión de agentes debe hacerse continuamente, ya que las circunstancias pueden modificarse y eventualmente transformarse en terroristas. Forofos: Tienen poco influencia en el proyecto. La gestión de agentes, se basa fundamentalmente en concebir a la empresa o compañía –organización‐ como una red interconectada, explícita o implícitamente entre agentes y/o grupos de individuos [150]. De hecho Miller [88] sugiere que la participación de múltiples stakeholders permitiría el alineamiento y el aprendizaje de los diferentes valores de estos agentes. Incrementando así el conocimiento común del grupo y enriqueciendo el proyecto. También indica que las fronteras de influencia de los interesados no se quedan sólo en la estructura de la empresa que desarrolla el proyecto. Así, los stakeholders o agentes son definidos generalmente, como individuos o grupos con una legitimación legal, moral o económica y/o que consideran que tienen un derecho para reclamar posesión, derechos o intereses en una empresa (o proyecto) en el pasado, presente o en sus futuras actividades. Así, la gestión de stakeholders se refiere al manejo de las relaciones y los múltiples y frecuentes conflictos de intereses (stakes) dentro de una nube compleja de personas y/o grupos (holders) [149]. Teniendo en cuenta que según Carroll [151], un stake puede ser: un interés, un derecho (legal o moral) y/o propiedad. También podemos tomar como válida la definición que PMI® incluye en la quinta versión del PMBOK® [35], en la que indica que los interesados, involucrados son personas y organizaciones como clientes, patrocinadores, organización ejecutante y el público, involucrándose activamente en el proyecto, o cuyos intereses pueden verse afectados de manera positiva o negativa por la ejecución o conclusión del proyecto. También pueden influir sobre el proyecto y sus productos entregables. Definiendo así mismo el proceso de la gestión de los Interesados como el de gestionar las comunicaciones para satisfacer los requisitos de los interesados en el proyecto y resolver problemas con ellos. De hecho, el concepto de stakeholder apareció por primera vez en 1963 en un memorándum internacional del Standford Reseach Institute, come recoge y cita Freeman [152], y se definieron como “Ese grupo sin cuyo apoyo, la organización cesaría”. Ya en los años 70´s el concepto se desarrolló y se fueron creando diversos modelos y metodologías, como la de Ackoff [153] sobre Análisis de sistemas organizativos. Aun así, lo se creía que la gestión de los interesados por sí misma fuese lo suficientemente importante a la hora de obtener resultados, pero sí se debería tener en cuenta. A partir de entonces y hasta ahora, muchos investigadores han desarrollado modelos y sistemas considerando a la gestión de los interesados como un aspecto estratégico y primordial para la obtención de resultados empresariales. Según Arun [154], el desarrollo del concepto del stakeholder y su gestión a lo largo del tiempo, se puede clasificar en diferentes fases, y gráficamente lo explicita en el siguiente esquema, donde Freeman [152] ha desarrollado los tres primeros escalones.
109
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Figura 77: Desarrollo del concepto de stakeholder. Fuente: Freeman
Tipologías de stakeholders En un proyecto, por tanto, se pueden encontrar diferentes tipos de interesados, y para desarrollar una gestión más eficiente es conveniente clasificarlos y jerarquizarlos. Así se puede realizar una clasificación de Interesados en primarios y secundarios [155]. De forma que los interesados primarios serían los que sin ellos y su participación y apoyo el proyecto no podría sobrevivir y desarrollarse. Este tipo de interesados son, por ejemplo; aportadores de capital, empleados, proveedores, clientes, residentes de la comunidad y el entorno natural, según Starik [156]. Clarkson [155] además agrupa a los agentes citados en lo que denomina el “grupo de interesados públicos”, determinando que los gobiernos y comunidades estarían en otro nivel. Los interesados secundarios, por su parte, serían los que tanto en el pasado, presente o en las futuras operaciones, no están directamente afectados y no son esenciales para su supervivencia [148]. Al igual que hemos comentado al inicio de este capítulo respecto a la clasificación que Roberts [149] realizaba teniendo en cuenta el grado de poder y de soporte, Mitchell [157] también realiza una clasificación similar, pero en este caso los factores determinantes son tres: poder, legitimidad y urgencia y los interesados pueden ser por tanto clasificados según su posición respecto a ellos y se puede apreciar en la Figura 78. Poder: Como el modo de imponer sus deseos o de coartar las acciones de los otros. Legitimidad: Se acogen a la definición de Suchman [158], como la percepción generalizada de que las acciones de una entidad son deseables o apropiadas dentro del sistema social constituido a partir de normas, valores, creencias y definiciones. Urgencia: Se define como el grado de atención que pide un interesado para obtener atención inmediata.
110
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
Figura 78: Clasificación de los stakeholder según su influencia. Fuente: Mitchell.
Gestión de los stakeholders Así, la gestión de los interesados la podríamos esquematizar siguiendo los pasos definidos en la figura siguiente, ya que en primer lugar hay que identificarlos, especialmente a los más relevantes, analizar su posición en el proyecto respecto de varios puntos de vista (posición, poder, interés, etc.) y a partir de esta información, fijar su situación inicial y la deseada. Seguidamente habría que diseñar y desarrollar las estrategias que sean capaces de cubrir el la brecha entre la situación actual y la deseada. Una buena opción es intentar integrarlos e implicarlos en el proyecto. Finalmente y a lo largo de todo del CVP el equipo de proyecto debe gestionarlos activamente, resolviendo los posibles conflictos que surjan, implementando las estrategias definidas y en resumen monitoreando el estado de implicación y satisfacción con el proyecto.
Figura 79: Fases básicas en la gestión de agentes.
De hecho una de las características interesantes de los interesados en un proyecto es su dinamismo, es decir, tanto su número como posición en el proyecto puede cambiar a lo largo del ciclo de vida del proyecto, por lo que cualquier modelo que pretenda gestionarlos adecuadamente, tiene que tener en cuenta que el proceso de análisis y comunicación debe ser continuo y planificado a lo largo de la duración del proyecto, y no limitarse tan sólo a su posición inicial. Por lo que a lo largo del tiempo el mix de los interesados puede cambiar; nuevos interesados pueden aparecer y otros desear salir del proyecto [154]. Así mismo, otro modelo para el análisis sistemático de agentes ha sido desarrollado por Freeman [152] (los siete primeros pasos) y por Mitchell [157] (el último) para proyectos de investigación y desarrollo y que se exponen a continuación: 1. 2. 3. 4. 5. 6.
Desarrollar un mapa de agentes del proyecto. Preparar un esquema (tabla) de agentes específicos. Identificar los intereses de los agentes. Desarrollar una matriz de “poder” vs “intereses” de los agentes. Desarrollar un proceso de determinación del nivel de los agentes. Desarrollar un proceso de análisis transaccional. 111
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
7. 8.
Determinar la capacidad de los agentes en el proyecto. Analizar los stakeholders desde un punto de vista dinámico.
La satisfacción de los interesados debe gestionarse como uno de los objetivos clave del proyecto. En el MGIP, vamos a seguir el modelo del PMBOK® de forma que en primer lugar y en la FGP de inicio se genera el documento RIP: registro de interesados del proyecto en el que se irán identificando los diferentes agentes que se vayan incorporando al proyecto, así como su poder, influencia, posición e interés en el proyecto, con el objeto de determinar a los agentes clave del proyecto. Posteriormente en planificación se diseñarán las estrategias para conseguir lograr y mantener el apoyo e implicación de los agentes en el proyecto. De hecho, esta AAC está muy relacionado con la de comunicación de forma que las dos se deben gestionar de forma integrada. Finalmente en el control se comprobará la eficacia de las estrategias definidas y la implicación y satisfacción de los agentes en el proyecto, por si fuese necesario re‐planificarlas. El enfoque del PMBOK® Incluye los procesos necesarios para identificar a las personas, grupos u organizaciones que pueden afectar o ser afectados por el proyecto, para analizar las expectativas de los interesados y su impacto en el proyecto, y para desarrollar estrategias de gestión adecuadas a fin de lograr la participación eficaz de los interesados en las decisiones y en la ejecución. También se centra en la comunicación continua con los interesados para comprender sus necesidades y expectativas, abordando los incidentes en el momento en que ocurren, gestionando conflicto e intereses y fomentado una adecuada participación de los interesados en las decisiones y actividades del proyecto. El enfoque de ISO 21.500:2.012 La filosofía de gestión de agentes es similar a la descrita en el PMBOK®, salvo que a la hora de materializarla en los diferentes procesos. De hecho en ISO 21:500:2.012 y en el inicio se identifican a los agentes y en la implementación se detallan las actividades a realizar, si bien no dispone de un proceso de planificación ni de control. El enfoque de PRINCE2® Se trata en la temática de la organización y se definen en el proceso de SU. Además en el estándar MSP™ (Managing Successful Programas) de OGC [46], identifica 6 pasos a seguir para conseguirlo: 1. 2. 3. 4. 5. 6.
2.4.4.
Identificación de las partes interesadas (¿quién?). Creación y análisis de sus perfiles (¿qué?). Definición de la estrategia para la participación de las partes interesadas (¿cómo?). Planificación del compromiso (¿cuándo?). Compromiso de las partes interesadas (hacer). Medición de la efectividad (resultados). Alcance
Descripción y enfoque del MGIP En el MGIP el alcance se va a gestionar de manera análoga a como lo enfoca PMI, replicando sus procesos. Como hemos indicado en puntos anteriores, el alcance es una de las tres áreas de conocimiento que conforman la triple restricción. Así, su gestión es fundamental para conseguir alcanzar el éxito del proyecto. No se puede olvidar que cualquier variación que se produzca en esta área, modificará al menos el coste o el tiempo –o incluso los dos‐. El objetivo principal cuando se gestiona el alcance, es definir qué incluye el proyecto, cómo debe ser y qué entregables debe producir. Además de verificar el grado el grado de cumplimiento respecto al alcance, conforme se va desarrollando el proyecto y se van generado los diferentes entregables. Para ello, se debe generar una línea base sobre la que ir comprobando que lo ejecutado coincide con lo planificado. Para poder definir el alcance correctamente y que éste satisfaga las necesidades de los stakeholders. Por lo que una vez identificados, el siguiente paso sería el de proceder a la identificación de sus requisitos o necesidades. De hecho es posible que desarrollemos un proyecto conforme a los objetivos que se hayan marcado inicialmente, pero que el cliente no quede satisfecho, si no se han identificado correctamente sus necesidades reales. De forma que en el alcance se definen los requisitos que debe cumplir el 112
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
proyecto. Este es un factor clave para el éxito del proyecto, de ahí que en director de proyecto deba poner especial atención en su identificación. Como se puede apreciar en el esquema inferior el cliente (o en general todos los interesados del proyecto) definen sus requisitos y especificaciones, y éstas se deben incluir en el plan de proyecto a través de la definición del alcance. En este punto se tendría que controlar y asegurar de que estas necesidades identificadas se incorporen al proyecto. De forma que el producto obtenido y que se ha ejecutado según el plan previsto, se adapte a los requisitos del interesado. Pero no es suficiente, ya que una vez completado el producto o entregable, tiene que ser validado por el cliente, para que se asegure finalmente que dicho entregable efectivamente, satisface sus necesidades.
Figura 80. Relación entre el cliente y el producto obtenido respecto a sus requisitos.
Enfoque de PMI® Según el PMBOK®, la gestión del alcance incluye los procesos necesarios para garantizar que el proyecto incluya todo (y únicamente todo) el trabajo requerido para completarlo con éxito. Su objetivo principal es definir y controlar qué se incluye y que no se incluye en el proyecto. Parte, de la identificación y recopilación de los requisitos que debe disponer tanto el producto como el proyecto necesario para la obtención del mismo. Así el concepto de alcance, se puede analizar desde dos puntos de vista; desde el alcance del producto indicando las características y funciones que definen un producto, servicio o resultado. Incluiría sus características como por ejemplo: dimensiones, forma, ‐tiene una tapadera‐ y sus funciones requeridas: por ejemplo calentar comida, que el elemento quede cerrado. El segundo punto de vista sería el alcance del proyecto, concepto que englobaría el trabajo que debe realizarse para entregar el producto, servicio o resultado con las características y funciones especificadas. De forma que es un aspecto clave para que la organización pueda valorar el esfuerzo necesario para conseguirlo. Incluiría aspectos tales como el diseño del producto, la realización del cálculo de su resistencia y comprobación de sus características, formación de los operadores del producto, etc. El alcance del proyecto, por tanto puede incluir el alcance del producto. Una vez se haya definido el alcance, es fundamental realizar un seguimiento y control de forma que se garantice que se cumpla. Para ello, se define la línea base del alcance, cuyo concepto básico sería “la foto” que definiría el alcance aprobado por el cliente o patrocinador. La línea base del alcance está compuesta por los siguientes tres elementos: Enunciado del alcance del proyecto: Incluye una descripción detallada del producto y del proyecto, además de indicar lo que se incluye o no en el mismo. EDT (estructura desagregada del trabajo): Un proyecto puede ser algo muy complejo de gestionar, de hecho, la descomposición del mismo en partes más pequeñas, que se puedan gestionar más fácilmente, es una de las bases fundamentales de la dirección de proyectos. Este proceso de descomposición, deriva en una estructura en forma de árbol que se denomina EDT como se ha indicado o WBS work breakdown structure. Si bien es una herramienta de gestión de proyectos sencilla es una de las más populares y utilizadas [159]. Diccionario de la EDT. Explica y detalla cada uno de los elementos de la EDT. Cuando el trabajo del proyecto se desarrolla y finalmente se obtienen los diferentes entregables del proyecto, éstos deberán ser verificados desde el punto de vista de calidad para posteriormente y dentro del área del alcance, ser aceptados por el cliente o patrocinador. Enfoque de ISO 21.500:2.012 El enfoque de ISO 21:500:2.012 tiene algunas diferencias respecto al que se puede encontrar en el PMBOK® ya que en el alcance incluye la definición de las actividades para producir los diferentes productos del proyecto, siendo en el área de conocimiento del tiempo donde se tratan en el PMBOK®. Además no define un proceso final explícito de 113
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
aceptación de los diferentes entregables que va generando el proyecto y que en el PMBOK® se indica en un proceso concreto que se denomina validar el alcance y cuyo objetivo es que los entregables del proyecto tengan el visto bueno del cliente o patrocinador antes de proceder al cierre del proyecto. Enfoque de PRINCE2® El alcance del proyecto se trata en la temática de calidad en PRINCE2® ya que en ella se incluye tanto la definición de los criterios de calidad, como del propio alcance del proyecto. Además se concreta en la temática de planes en los que a través de la herramienta de planificación por productos, se consigue definir el alcance a partir de las expectativas de los agentes. De hecho, la relación entre los dos conceptos de alcance y calidad es muy estrecho. De forma que el alcance de un plan es la suma total de sus productos; indica lo que incluye o no el proyecto, las fronteras del mismo. Se puede diferenciar el alcance del producto (centrado en definir cómo es el producto que genera el proyecto) y el alcance del proyecto (donde se indica el trabajo necesario para desarrollar el producto del proyecto). Además se define en la estructura jerárquica de productos EJP (análoga a la EDT descrita en el PMBOK®) para el plan y sus descripciones de productos asociados, producto de gestión también análogo al diccionario de la EDT definido previamente en el PMBOK®. 2.4.5.
Tiempo
Descripción y enfoque del MGIP La planificación temporal de los proyectos es un aspecto clave en la gestión de los mismos, hay que recordar que es una de las tres áreas de conocimiento que componen la triple restricción (junto con el coste y el alcance). La estimación del tiempo del proyecto generará la línea base del cronograma y se utilizará para la aplicación de la herramienta de control del valor ganado del proyecto (que se tratará en la gestión de costes del proyecto). Por lo que cualquier cambio en ella, como se ha indicado, podrá repercutir en otras áreas del proyecto. Por eso, la gestión del tiempo del proyecto y sus variaciones deben integrarse en la gestión de los cambios del mismo, y cada una de sus modificaciones sea tratada de forma sistemática y los agentes interesados, sean informados convenientemente. Características y funciones de la planificación temporal Fundamentalmente el cronograma que se desarrolle deberá ser creíble y realizable, de forma que el equipo de proyecto debe creer que es capaz de realizar las tareas en la forma descrita y que los interesados del proyecto también lo consideren factible. De la misma forma, las funciones principales que debe cubrir la planificación temporal, además de fijar y controlar la duración del proyecto, son las de relacionar las tareas del proyecto, y por tanto ayudar a su coordinación y gestión, anticiparse a las necesidades de recursos del proyecto y por tanto planificar su adquisición y poder detectar con anticipación suficiente los cuellos de botella del proyecto o momentos en los que existe un gran número de tareas que convergen o un uso de recursos elevados, con el objeto de disponer de tiempo para planificar estrategias e implementar las acciones necesarias para reducir el riesgo de retraso. En MGIP, la gestión del tiempo se trata de forma análoga a como se realiza en el PMBOK®, desarrollando un plan de gestión ad hoc para esta área y que será parte del PDP y obteniendo a la finalización de los procesos de planificación una línea base de tiempo. A resaltar que se definen en este AAP del proyecto los recursos que serán necesarios en el proyecto, tanto humanos como de otra índole, de forma que en las áreas de gestión de recursos y en las de adquisiciones, la información y requisitos generados en este punto, pueda ser utilizado para definir con detalle cómo se gestionarán los recursos necesarios tanto si serán incluidos como miembros del equipo o si se subcontratarán fuera de él a través de las adquisiciones. Además en el área de control se monitorizará el desempeño real contra el planificado para detectar posibles desviaciones y generar las proyecciones del cronograma que servirán para la toma de decisiones en el proyecto. Enfoque de PMBOK® Seguirá lo descrito en el punto anterior. 114
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
Enfoque de ISO 21.500:2.012 Como hemos indicado en el AAP anterior del alcance, según el modelo de ISO 21.500:2.012, la identificación de las actividades necesarias para la ejecución de los entregables, se realiza en el alcance, no en el tiempo como en el PMBOK®. También se diferencia de éste en que la planificación concreta del área ‐al igual que ocurre en el resto de grupos de materia en ISO 21.500:2.102‐, se realiza en la integración siendo parte de los planes del proyecto. Además como se tratará en los puntos siguientes, los recursos necesarios para realizar las actividades se identificarán y dimensionarán en la temática de recursos. Enfoque de PRINCE2® La gestión del tiempo o calendario del proyecto se trata en la temática de planes. Y a través de la herramienta de planificación por productos se consigue definir el cronograma a partir de las expectativas de los agentes, las restricciones del proyecto y los recursos disponibles y se incluye en los diferentes planes dependiendo del nivel de gestión de que se trate. Como se puede ver el en la Figura 81:
Figura 81: Planificación por productos según PRINCE2®.
2.4.6.
Coste
Descripción y enfoque del MGIP Como hemos indicado en puntos anteriores y acabamos de recordar, el coste es el tercer componente de la triple restricción. La gestión de los costos del proyecto, puede incluir la gestión de los ingresos previstos a lo largo del desarrollo del proyecto o incluso al análisis y control del rendimiento financiero esperado (TIR, flujo de caja,..). En el MGIP también se adopta la propuesta que aparece en el PMBOK®, de forma que en la FGP de planificación se generará el plan de gestión del área concreta de los costos y la estimación de los costos tantos de las actividades como de los diferentes paquetes de trabajo definidos para el proyecto. De hecho y de forma coincidente tanto con el alcance y con el tiempo, al finalizar los procesos de planificación se dispondrá de la línea base de los costos o de desempeño. La gestión del costo del proyecto se centra en analizar y gestionar los costos que se producen en el marco del proyecto, pero también hay que tener en cuenta los costos futuros que se pueden ocasionar por el uso del producto que generará el proyecto en su entorno de operaciones. 115
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
La línea base obtenida en los procesos de planificación del costo, se usará para la aplicación y uso de herramientas de control de costes como la del valor ganado o earn value method [160, 161] que por su relevancia en la gestión de los proyectos se considera oportuno comentar en este punto. Como se puede apreciar en el gráfico siguiente se basa en realizar comparaciones entre el trabajo realizado realmente y el planificado, contra la línea base de costos en un momento concreto del proyecto. De la misma forma, en los procesos de control de costes se monitorizará el desempeño real contra el planificado para detectar posibles desviaciones y generar las proyecciones del presupuesto de costes lo que se denomina EAC (estimate at completion), y cuya comparación con el total de presupuesto aprobado en un tiempo determinado (BAC: budget at completion) servirán para la toma de decisiones en el proyecto por el nivel de gestión directivo. Por tanto, idealmente, los costos estimados y los actuales deben ser idénticos y si no es así y se detectan diferencias, ‐variaciones‐, se podrán diseñar estrategias para corregirlas [162]. Es fundamental para el director del proyecto detectar las desviaciones e informar a la organización para que ésta pueda tomar las decisiones que considere apropiadas. De hecho se pueden producir grandes desviaciones en los costos en los proyectos, como en el caso del desarrollo del Boing Dreamliner que dobló su presupuesto de cosos original [163].
Figura 82: Líneas básicas en el método del valor ganado. Enfoque de PMBOK® Coincide con lo expuesto en el enfoque del MGIP y como se indica en el PMBOK® incluiría la gestión de los costos del proyecto y los procesos relacionados con ellos, como son planificar, estimar, presupuestar, financiar, obtener financiamiento, gestionar y controlar los costos de modo que se complete el proyecto dentro del presupuesto aprobado. Enfoque de ISO 21.500 Análogo a PMBOK® salvo por la planificación del área que como se indica en puntos anteriores se realiza en la integración y por tanto no se incluye un proceso específico para ello. Enfoque PRINCE2® La gestión del costo del proyecto se trata en la temática de planes en los que a través de la herramienta de planificación por productos se consigue definir el presupuesto a partir de las expectativas de los agentes, las restricciones del proyecto y los recursos disponibles y se incluye en los diferentes planes dependiendo del nivel de gestión de que se trate. Al igual que en la temática del tiempo, se puede apreciar la correlación de actividades necesarias para la obtención del presupuesto del proyecto. 2.4.7.
Calidad
Descripción y enfoque del MGIP Si bien la gestión de la calidad no pertenece a la triple restricción, sí es uno de los tres grupos de procesos que se denominan aseguradores por PMI® y sin cuya aportación, sería muy difícil conseguir los objetivos del proyecto. Aborda tanto la gestión de la calidad del proyecto como la de sus entregables. En un proyecto concreto, las métricas, 116
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
medidas y técnicas de calidad son específicas para cada tipo de entregables que pueda generar. De forma que el equipo de proyecto y el director del mismo, son los responsables de gestionar los compromisos para entregar los niveles requeridos de calidad y su grado. Si bien, también es posible que el trabajo del proyecto pueda ser desarrollado por los diferentes team managers, en cuyo caso serían éstos los que deben implementar las actividades de calidad, si bien este hecho no restaría responsabilidad al director de proyecto al respecto. El concepto de calidad se puede definir, según varios autores de las siguiente maneras; Philip Crosby [164] establece que ”calidad es cumplimiento de requisitos”, mientras que Joseph Juran [165]: “calidad es adecuación al uso del cliente” y Armand V. Feigenbaum [166]: “satisfacción de las expectativas del cliente”. Finalmente la Real Academia de la Lengua Española la define como “propiedad o conjunto de propiedades inherentes a una cosa que permiten apreciarla como igual, mejor o peor que las restantes de su especie”. De hecho la definición de calidad según los marcos de gestión de proyectos analizados es:
PMBOK®: “Nivel en el que un conjunto de características inherentes satisfacen los requisitos”. Definición de la norma ISO 9.000: “Calidad: grado en el que un conjunto de características inherentes cumple con los requisitos”. PRINCE2®: Se define como la totalidad de los rasgos y características inherentes o asignadas a un producto, una persona, un proceso, un servicio y/o un sistema que influyen en su capacidad para demostrar que cumple con las expectativas o satisface necesidades, exigencias o una especificación determinada.
El concepto de la calidad total El concepto de calidad ha ido evolucionando a lo largo del tiempo, llegando en estos momentos al concepto de calidad total [164], en el que se plantea la participación de todos los miembros de la empresa u organización en la consecución de los objetivos de calidad, con una máxima implicación, desde la alta dirección, hasta los trabajadores más noveles y de menor rango y en todos los departamentos. Las teorías de la calidad se enfocan al conjunto de propiedades inherentes a un objeto que le confieren capacidad para satisfacer necesidades implícitas o explícitas. Por otro lado, la calidad de un producto o servicio es la percepción que el cliente tiene del mismo, de tal forma que llega a asumir su conformidad con dicho producto o servicio dado que satisface sus expectativas. Desde el punto de vista del producto final, la calidad puede definirse como la conformidad relativa con las especificaciones, ya sean vinculadas a las expectativas del cliente, o las determinadas por reglas y requerimientos estipulados por las organizaciones que se ocupan de certificar algún producto. Desde el punto de vista de generación de valor, más en consonancia con la calidad del servicio asociada a la gestión de proyectos, la calidad significa aportar valor al cliente, esto es, ofrecer unas condiciones de uso del producto o servicio superiores a las que el cliente espera recibir y a un precio accesible. Es decir, entregar al cliente no lo que quiere, sino lo que nunca se había imaginado que quería y que una vez que lo obtenga, se dé cuenta que era lo que siempre había querido. A lo largo del desarrollo del pensamiento sobre la gestión de la calidad han surgido diferentes enfoques, que exponemos brevemente, indicando sus principales aportaciones [45]. De hecho los conceptos y principios de la gestión de la calidad, tienen muchos puntos de contacto y coincidencias con la gestión de proyectos, tales como:
La satisfacción del cliente; conformidad con los requisitos: asegurar que el proyecto produzca lo aquello para lo que fue emprendido y adecuación para su uso: el producto debe satisfacer las necesidades reales. Prevención antes de la inspección. el coste de los errores es mayor en la inspección que en la prevención. En el control de producción, el error se aleja del producto, y en el control en recepción, el error se aleja del cliente. Por lo que es más costoso para la empresa realizar sólo control en recepción, ya que se pueden perder muchos productos y generan reprocesos. Mejora continua. Este concepto, expuesto por Stewhart y modificado por Deming, se expresa en el PDCA (plan do, check, act). Y se basa en ir aplicando pequeñas mejoras continuamente [68]. La estrategia que plantea el ciclo PDCA implica que toda empresa necesita un cambio que la haga apta para sobrevivir, cuestionándose la forma de hacer las cosas, sus procesos, sus productos, su forma de gestionar, las competencias de su personal, la forma de evaluar y premiar el desempeño, etc. A través del ciclo PDCA el equipo de dirección de proyectos se descubre a sí mismo, reconoce qué debe cambiar y lleva adelante el cambio que anda buscando.
De las diferentes definiciones indicadas anteriormente, queda claro que la calidad define las características que debe disponer un producto para asegurar que cumplirá los objetivos para lo que fueron creados. De hecho se tiene que pactar con el cliente o usuario cuál es este nivel de calidad esperado y además cómo se demostrará que se alcanza, lo
117
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
que generará predictibilidad en el proceso de aceptación y seguridad a los equipos de desarrollo de que están realizando el trabajo de acuerdo con las necesidades y las expectativas de los principales stakeholders. Así, el enfoque que se expone en el MGIP es coincidente con los tres marcos de gestión y está alineado con las prescripciones de la familia de normas ISO 9.000. En el AAC de planificación se desarrolla el plan de gestión de la calidad en el que se definirán las normas y la estrategia de gestión de calidad que se adoptará en el proyecto. Respecto a este extremo es habitual que las organizaciones dispongan de modelos y sistemas de calidad corporativos, a partir de los cuales, el director de proyecto diseñará el plan de calidad apropiado, adaptarlos a las necesidades del proyecto y a las restricciones de uso de la propia organización. Posteriormente en los procesos de control se implementará el propio control de calidad, efectuando los ensayos o inspecciones determinados en el plan e identificando las posibles anomalías. De forma que los entregables que se van generando vayan siendo verificados y confirmado de que cumplen los requisitos de calidad definidos. En la FGP de ejecución se desarrollará el aseguramiento de calidad del proyecto. Las actividades que engloban este proceso tienen una naturaleza externa al equipo de proyecto ya que fundamentalmente lo que se persigue es evaluar tanto los productos que genera el proyecto como los procesos de forma que a través de fundamentalmente auditorías se puedan detectar errores en el proceso o puntos de mejora, de forma que se pueda ejecutar la mejora continua. También de las auditorías se pueden extraer lecciones aprendidas de los proyectos para que sean aprovechadas por el resto de la organización. Enfoque de PMBOK® El enfoque, como hemos indicado coincide con el MGIP e “Incluye los procesos y actividades de la organización ejecutante, que determinan responsabilidades, objetivos y políticas de calidad, a fin de que el proyecto satisfaga las necesidades, por la que fue emprendido”. De hecho, el proceso de gestión del proyecto, trata tanto de la gestión de la calidad del proyecto como del producto del proyecto y se aplica a todos los proyectos. Enfoque de ISO 21.500:2.012 Análogo a PMBOK®. El enfoque de PRINCE2®. La diferencia fundamental del enfoque que hace PRINCE2® en la temática de calidad es que incluye aspectos que los otros dos enfoques tratan en el área de conocimiento de alcance. El propósito de esta temática es la de definir e implementar los medios con los que el proyecto creará y verificará productos aptos para su propósito, para asegurar que los productos del proyecto cumplan las expectativas comerciales y permitan lograr posteriormente los beneficios deseados. La gestión de PRINCE2®, se basa en la generación de productos, por lo que estos deben estar perfectamente definidos para evitar ambigüedades. Se logra estableciendo criterios de calidad para los productos y las actividades. Por lo que sólo cuando se hayan incluido estos criterios en el plan de proyecto, se podrá proceder a evaluar los costes y calendarios de todo el proyecto. Así, la temática de calidad, trata tanto de asegurar de que todos los interesados comprendan exactamente lo que generará el proyecto (alcance), como de implementar los mecanismos para planificar cómo y con qué criterios se asegurará que cumplen las especificaciones de los interesados. Además también incluirán las acciones para mejorar la eficiencia y eficacia de los procesos a través del aseguramiento de la calidad. En la siguiente figura se pueden apreciar los tres aspectos indicados en este párrafo:
Figura 83: Aspectos fundamentales que se tratan en PRINCE2 en la temática de calidad.
En el enfoque de PRINCE2® hacia la calidad, se basa en identificar las expectativas del cliente y a partir de ellas definir los criterios de aceptación. De forma que los productos se definan y se creen en base a ellas. Paralelamente, se 118
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
debe auditar el sistema de forma que nos aseguremos que se está siguiendo las normas y prescripciones necesarias. Por tanto el enfoque se centra en:
Identificar los productos del proyecto (hasta el nivel deseado de control). Desarrollar las descripciones de productos, estableciendo los criterios de calidad, los métodos de calidad para el diseño de los mismos y las responsabilidades de calidad de los interesados. Así como los métodos de aceptación (verificación) de la calidad. Realizar un control de calidad de los métodos definidos.
En la Figura 84 se puede apreciar con detalle el enfoque desarrollado en PRINCE2®, desde la planificación hasta el control de calidad. Y en que se define en primer lugar, las expectativas del cliente y de los principales agentes, así como los criterios de aceptación de los mismos y a partir del cuales se definirá el producto del proyecto. En este punto podemos encontrar una diferencia de orden entre los enfoques PMBOK® e ISO 21.500:2.012 y PRINCE2®, ya que en el orden de los procesos de los primeros, se recopilan los requisitos y sus criterios –más o menos concretos‐, con ellos se define el alcance y posteriormente se planifica el tiempo y los costos del proyecto. Una vez resueltas las áreas de la triple restricción, se establecen los criterios de calidad que establecen con detalle cómo se conseguirán alcanzar los criterios inicialmente establecidos. En PRINCE2®, no se podrán calcular los costes y el cronograma del proyecto hasta que no se hayan determinado los criterios de calidad. En realidad los dos enfoques son compatibles ya que en el primer caso, una vez se haya determinado inicialmente la triple restricción, se procederá a establecer los criterios de calidad y entonces se volverá a aplicar el principio de iteración que se produce en el proceso de creación del PDP, reevaluando las posibles modificaciones que pudiesen haber surgido de la identificación de dichos criterios tanto en el alcance, como en el tiempo y costos. En el caso de PRINCE2® ocurriría algo muy similar, ya que una vez establecidos los criterios de calidad necesarios se debería comprobar si la combinación de alcance, tiempo y costo es la más adecuada para el proyecto.
Figura 84: Enfoque de calidad de PRINCE2®.
119
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
A partir de la definición por el cliente de la descripción del producto del proyecto, el equipo de proyecto define la estrategia de calidad y se procede a identificar los productos que generará el proyecto junto con sus criterios de calidad, tolerancias y demás componentes necesarios. Finalmente en la fase de control de calidad se procederá a realizar los ensayos o inspecciones definidos anteriormente con el objetivo de obtener la aprobación (verificación) de los productos del proyecto y la aceptación por parte del cliente (validación). Definición de la garantía de calidad (aseguramiento) En PRINCE2® se identifica un nuevo rol, que está fuera del equipo de proyecto, y que es por tanto, externo e independiente a ellos cuya responsabilidad es la de proporcionar una comprobación de que la dirección y la gestión del proyecto son adecuadas a la naturaleza del proyecto y que cumplen con las normas y políticas pertinentes de la gerencia corporativa o del programa. Por tanto sus actividades quedan fuera del ámbito de actuación de PRINCE2® y su objetivo es dar seguridad a los agentes del proyecto de que se están haciendo las cosas de la forma correcta. De hecho es una responsabilidad de la junta de proyecto asegurarse de que es establezca una garantía de calidad adecuada. 2.4.8.
Recursos del proyecto
Descripción y enfoque del MGIP Una vez que se han definido las actividades a realizar para conseguir desarrollar los productos o entregables que compondrán el producto del proyecto, se deberá proceder a identificar los recursos tanto materiales como humanos a utilizar para ello. Este objetivo se cubre tanto en le MGIP como en el PMBOK® en el área de tiempo, como se ha expuesto en puntos anteriores. Así, una vez identificados consideramos necesario disponer de un área específica para planificarlos, gestionarlos y controlarlos, con el objeto de que se pueda alcanzar la máxima eficiencia en su uso. Básicamente se pueden clasificar los recursos que usará el proyecto en dos tipos; humanos, consistentes en los miembros del equipo que van a ser integrados en el proyecto y materiales, que estarían compuestos por el resto de recursos no humanos a incorporar. Así, si bien en el momento de identificar y dimensionar los recursos no se hace distinción y de hecho se realiza en un mismo proceso. A la hora de su gestión pormenorizada sí que se hará, incluyéndose ambos en la temática de recursos. No hay que olvidar que son las personas las que realizan las actividades de gestión en los proyectos y por tanto es función de director de proyecto conseguir que los recursos humanos que estén vinculados en el mismo estén lo más motivados e involucrados posible con el objeto de conseguir la máxima eficiencia en su desempeño. Así el director de proyecto debe liderar y transmitir a su equipo la visión y la motivación suficientes, por lo que a la vista de lo anteriormente expuesto, es evidente que una cualidad fundamental de la que debe disponer, es el liderazgo. Entendiéndolo como la capacidad de coordinar, motivar y dirigir a un grupo de personas hacia la consecución de un objetivo. Sin duda, el líder debe ser el ejemplo para su equipo y ser capaz de generar la motivación suficiente. También incluye la forma en cómo pueda ejercer influencia en los miembros de su equipo y aplicar vigilancia de su comportamiento profesional y ético. Existen multitud de estilos de liderazgo, aunque lo verdaderamente relevante es r que el director de proyecto disponga del criterio adecuado para seleccionar el uso de uno u otro enfoque, dependiendo de las características del proyecto, el momento del ciclo de vida en que se encuentre y su problemática específica. En cualquier caso, el poder del director de proyectos en el ámbito concreto del proyecto puede ser establecido de forma política u organizativa: generado a partir del organigrama o estructura de la organización. Pero también puede ser coercitivo o punitivo si tuviese la capacidad de sancionar o al contrario pueda recompensar a los miembros del equipo por sus acciones positivas. Pero la mejor manera de establecer el poder dentro del equipo debería estar basado en el propio reconocimiento generado en el grupo por las cualidades de líder del director de proyecto, tanto personales como técnicas y basadas en su respeto. Ésta sin duda, sería la opción más interesante. En esta AAP, por tanto además de los recursos materiales, se tratará sobre los recursos humanos que se incluirán en el equipo de proyecto y por tanto a aquellas personas a las que se las ha adjudicado roles y responsabilidades para completar el proyecto. Entendiendo los roles como quién dentro del equipo se encarga de cada tarea y responsabilidades definiendo quién es responsable de cada tarea. Es conveniente que los miembros del equipo puedan participar en el proyecto, no sólo en los roles y responsabilidades asignados personalmente, sino que la aportación y experiencia de cada uno de ellos al global del proyecto sea la máxima posible. Además, cuánto antes se produzca ésta, mayor y mejor impacto se conseguirá, además de implicar e identificar al proyecto con el equipo que lo debe desarrollar y llevar a su éxito. 120
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
La gestión del equipo de proyecto, no se limita como es lógico, a la fase de planificación, sino que se extiende a lo largo de todo el ciclo de vida del mismo. De forma que conforme se vaya conformado y desarrollando el equipo, es más que probable que estas circunstancias puedan ir modificando el plan del mismo, por ejemplo:
Cuando es equipo de proyecto esté conformado y desarrollen la EDT, puede que se detecten nuevas necesidades y por tanto, nuevas incorporaciones al proyecto. Conforme van entrando los miembros del equipo al mismo, y se comprueba de forma cierta sus capacidades, es posible que haya que modificar el plan de capacitación e incluso se podría necesitar más personal. En general, pueden surgir nuevos riesgos relacionados con esta área. De la misma forma, habrá que comprobar que los rendimientos y estimaciones tanto en términos de costo como de cronograma, establecidos en el plan, se podrán conseguir con los recursos que van entrando al proyecto. Evaluando posibles impactos y cambios.
En el MGIP hemos optado por el enfoque de PMBOK® pero ampliando el concepto de recursos humanos por uno más amplio de recursos, como aparece en la ISO 21.500:2.102 y en la revisión del PMBOK® sexta edición que prevé estará disponible en 2.017. Así, desde el punto de vista de los recursos humanos que forma el equipo de proyecto, en planificación se establecen los roles y responsabilidades de los mismos así como se identifican a partir de los requisitos de los recursos RRP definidos en el AAP del tiempo los perfiles ideales de los miembros del equipo identificando las habilidades y características necesarias para poder realizar las tareas definidas. Una vez comenzada la ejecución del proyecto, se procederá a confirmar y contratar si es preciso a los miembros del equipo y se empezaría de forma paralela a incrementar las habilidades y confianza de éstos a través de acciones de capacitación o de formación de equipos o team building con el objeto de que se aumente la cohesión y confianza del equipo, y por otra a dirigir, retroalimentar, solucionar problemas y crisis y a tomar las decisiones necesarias para aumentar el desempeño de los miembros del equipo y por ende del proyecto. Se ha convenido que los proyectos son definidos como un esfuerzo temporal [167], por lo tanto transitorios [168] por lo que las teorías de organización temporal (temporary organization theory) está teniendo cada vez más atención a la hora de gestionar los equipos de proyecto [167]. Si bien, conforme se inicia un proyecto y se comienza a componer el equipo de proyecto, éstos pueden pasar por diferentes estadios o fases, de hecho es muy interesante los pasos que Bruce Tuckman [169] estableció en estos casos: en primer momento se forma al equipo y se conocen sus componentes (form), posteriormente pueden surgir roces y crisis de funcionamiento entre ellos –no olvidemos que por la propia naturaleza de un proyecto (organización temporal que ese crea y se disuelve una vez completado) es factible que los miembros del equipo no estén habituados a trabajar juntos‐ (storm) que si son identificados y tratados adecuadamente, de su resolución se puede conseguir aumentar el desempeño del equipo (norm y perform). Por otro lado, como se ha expuesto, en esta AAP se tratarán otros tipos de recursos no necesariamente humanos. En cualquier caso, a la hora de planificar cómo se contratarán, qué políticas se seguirá para hacerlo y los procesos concretos, se incluirán todos los tipos de recursos en un primer proceso de planificación. De la misma forma la incorporación de los recursos al proyecto también será conjunta. Si bien en la FGP de ejecución y control, en lo relativo a su gestión, serán tratados de forma independiente debido a su diferente naturaleza y por tanto su estrategia de gestión y control no deberá ser igual. Enfoque de PMBOK® Como se ha indicado anteriormente, su enfoque es análogo al del MGIP, e incluyen los procesos que organizan, gestionan y conducen el equipo de proyecto. Su objetivo principal es la gestión del equipo. Tanto el número, como organización y características de los componentes del equipo, pueden cambiar a lo largo del ciclo de vida del proyecto. Debiendo, por tanto adaptarse a las necesidades y requerimientos del mismo. Por lo que la mayor diferencia estriba en la no incorporación explícita de la gestión de recursos que se incorporarán al proyecto que no sean de naturaleza humana. Enfoque de ISO 21.500:2.012 En enfoque que realiza ISO 21.500:2.012 es más amplio que el PMBOK® e incluye tanto los recursos humanos como el resto de recursos como equipamiento, instalaciones, materiales e infraestructura y herramientas, que se trata en otras áreas en el PMBOK®. En concreto en ISO 21.500:2.012 existe un proceso en el grupo de procesos de inicio en el que se identifican y establecen a los miembros del equipo. En el PMBOK® este proceso se realiza en dos pasos; en un primer momento se pueden identificar a los miembros del equipo que van a iniciar las actividades de gestión en el proyecto y se pueden nombrar en el acta de constitución, de forma que puedan arrancar con las actividades de planificación. Pero no se terminará de definir el equipo de planificación hasta que no se tenga una visión clara de los 121
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
productos que serán desarrollados por el equipo de proyecto o cuáles serán subcontratados y gestionados a través de las adquisiciones. Esto puede determinar de forma dramática el tipo, número y habilidades requeridas del equipo. En planificación, la determinación de los recursos, como hemos dicho en el PMBOK® se realiza en la gestión del tiempo. Otra diferencia se encuentra en la inclusión de dos procesos de control tanto para los recursos en general como para el desempeño del equipo de proyecto en particular. Estos dos procesos se han incluido en el MGIP. Enfoque de PRINCE2® En PRINCE2® no se incluye la gestión del equipo de proyecto o de los recursos humanos, pero la identificación del tipo de recurso a utilizar en el proyecto se incluye en la temática de planes. 2.4.9.
Comunicación
Descripción y enfoque del MGIP Se estima que más del 75% del tiempo del director del proyecto, lo dedica a comunicarse tanto con los miembros de su equipo como con el resto de stakeholders. Numerosos estudios muestran que el flujo de información entre los diferentes agentes es el mayor componente de la actividad de gestión de proyectos [114]. Por lo que mantener adecuadamente definidos los canales de comunicación es clave para el éxito del proyecto, de hecho este aspecto es un reto constante en el proyecto, ya que es habitual que en general, los agentes no transmitan la información de forma adecuada [114]. La comunicación puede ser categorizada de diferentes formas, a saber; interna (dentro del proyecto) o externa, formal (informes, memorándums, etc.) o informal, vertical; arriba‐abajo o abajo‐arriba a lo largo del organigrama de la empresa u horizontal entre miembros del equipo del mismo nivel. También puede ser escrita y oral y verbal y no verbal. No hay que olvidar que la comunicación comprende todas las relaciones entre los interesados del proyecto, siendo obligación del emisor la de emitir la información de manera clara y asegurarse de que llegar al receptor y que ésta la entiende. Del mismo modo, es obligación del receptor, asegurarse de que ha entendido la información que le ha llegado y confirmar este extremo al emisor. En el plan de comunicación, se debe establecer quién necesita la información, qué tipo, cuándo la necesitará (periodicidad), bajo qué formato, etc. Es un proceso clave para el éxito del proyecto, ya que una mala comunicación entre los miembros del equipo de proyecto o entre ellos y el resto de stakeholders puede hacerlo fracasar o generar graves problemas. De hecho, PMI® aboga que un factor de éxito clave es saber comunicar el estado del proyecto a los actores interesados y conseguir y analizar su feedback (respuesta ‐ retroalimentación), con el objeto de asegurar que el proyecto sigue alineado con sus expectativas y sus requisitos de negocio. Este factor es tan importante que el director del proyecto debe realizarlo personalmente con los actores claves, y si es posible cara a cara, desarrollando sus habilidades personales como la escucha activa, la proactividad y la empatía. Es obligación del director de proyecto, por tanto, generar rápida y eficazmente el estado de progreso del proyecto para poder distribuirlo adecuadamente a los agentes según sus necesidades y requisitos. El paso siguiente sería el de obtener la respuesta de éstos y analizar su impacto. De hecho es realmente importante que la comunicación se desarrolle de forma adecuada, en el formado correcto y en el momento adecuado, de forma que el agente que la reciba la pueda utilizar de forma adecuada a sus intereses. Sin duda, cada stakeholder afectado por el proyecto, puede tener una necesidad diferente de información, tanto en formato, como en tiempo y tipo de información y es por tanto una responsabilidad del director de proyecto que se establezca una estrategia de comunicación adecuada. Una ejemplo de lo expuesto es la disposición de la información a los agentes principales del proyecto –o de una organización‐ a través del cuadro de mando integral o CMI (balance scorecard o project scorecard). En el siguiente punto pasamos a ampliar la información al respecto. CMI cuadro de mando integral Dentro de la gestión empresarial y de proyectos, es muy importante poder medir la evolución de los parámetros más importantes que definan el estado real y actual del mismo. De forma que se conozca su situación actual, y además poder prever con mayor precisión cuál será su evolución más probable de un modo lo más objetivo posible. 122
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
Lo que no se puede medir no se puede gestionar [170]. Y por tanto es más difícil de mejorar, bajo este paradigma, se desarrolla la filosofía del cuadro de mando integral CMI o balance scorecard BSC. Los parámetros que definen la situación de una empresa, históricamente han sido básicamente financieros, lo que ofrece una visión sesgada de la situación. Ratios como la Rentabilidad o el ROI (retorno de la inversión, return on investment), VAN (valor actualizado neto) o el TIR (tasa interna de retorno), no son suficientes para comprender la globalidad de un proyecto e incluso pueden estar ofreciendo una información errónea o inadecuada. Así, es necesario el uso de una herramienta de gestión de carácter estratégico y que integre los aspectos y ratios que den una visión completa del proyecto, o al menos lo suficientemente precisa para detectar el desarrollo del proyecto, y asegurar que éste coincide con la estrategia definida por la compañía. Por tanto debe servir para mejorar la comunicación, a través de la cual se informará del plan y de la estrategia definida, así como del camino para conseguirla, vinculando cuatro procesos [171]: Visión compartida. Comunicación y enlace. Elaboración del plan de negocios. Retroalimentación y aprendizaje. En la publicación hecha en el Harvard Business Review, Robert Kaplan y David Norton diseñaron un modelo de gestión de indicadores que denominaron balance scorecard [170]. Con este sistema se traduce la estrategia de la empresa en cuatro perspectivas: cliente, negocio interno, innovación y aprendizaje y perspectiva financiera. Así esta gestión de indicadores y de gestión, tiene una relación muy estrecha con la gestión de Interesados o stakeholders, ya que dependiendo del perfil y de las necesidades que tenga cada uno, necesitará unos determinados datos, y que probablemente no coincidan para todos ellos, tanto del punto de vista de la gestión de la información como de la seguridad y confidencialidad de los mismos. Por lo que cuando una organización decide implementar un CMI, dependerá de diversas razones: 1. 2. 3. 4. 5. 6. 7. 8.
Obtener claridad y consenso sobre la estrategia. Conseguir el enfoque. Desarrollar y descentralizar el liderazgo. Lograr la intervención estratégica. Educar a la organización. Establecer metas estratégicas. Alinear programas e inversiones. Construir un sistema de feedback.
Se puede tomar la definición de Luis José Amendola [171] en la que define el BSC como una herramienta que permite la transición hacia una gerencia más estratégica. Orientada permanentemente hacia la visión, con una amplia participación del personal. Funciona conceptualmente, como el cuadro de mando de un coche, de forma que de un vistazo el conductor conozca de primera mano y en tiempo real tanto la situación operativa y funcionalidad del vehículo (niveles de aceite, temperatura del motor, etc.) y de la dinámica del mismo (velocidad, revoluciones por minuto del motor). Parte, como se ha indicado, de la estrategia de la empresa y de los objetivos pormenorizados de la cual emanan. Transformándolos en indicadores organizados en cuatro perspectivas diferentes [171] como son las financieras, la de los clientes, respecto al aprendizaje y crecimiento y de los propios negocios Internos. Por tanto consiste en definir las métricas que mejor monitoreen la estrategia y estado de la empresa y/o proyecto. A tal fin existen dos tipos de métricas o ratios [171]: las métricas estratégicas: basadas en el monitoreo del cumplimiento de la estrategia de la empresa y las métricas de diagnóstico: que permiten ver si el negocio o proyecto está bajo control según los parámetros definidos previamente. CMIP cuadro de mando integral de proyecto Lo expuesto anteriormente, se puede aplicar directamente al ámbito del proyecto, en lo que se denomina cuadro de mando integral del proyecto o project scorecard, y consiste en la transmutación y adaptación de las técnicas del CMI en lo relativo a la empresa, a la gestión de un proyecto concreto. Esto es especialmente útil en organizaciones que están estructuradas bajo un esquema matricial, matricial fuerte o proyectizada. Donde cada proyecto tiene entidad por sí misma. En este caso, el CMI se estableceré en dos niveles; Nivel proyecto: con las métricas y ratios de cada proyecto concreto y sus particularidades. Nivel portfolio (o programa): con los datos del conjunto de proyectos que gestione actualmente (presentes y futuros) de la organización. Se estima que para implantar y que cumpla adecuadamente su función, usualmente es necesario el uso de entre dieciséis y veinticinco métricas [171] que permitan monitorizar su estado continuamente por lo que un BSC con 123
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
este volumen de ratios es suficiente. Por lo que el CMI metodológicamente consistiría en resumir y seleccionar de entre todos los ratios que se generan en los procesos y operaciones habituales de la empresa o proyecto, los más representativos e importantes, y sobre los que se realizará un control desde un punto de vista estratégico y global. Los agentes intervinientes en un BSC A la hora de diseñar e implementar un CMI intervienen numerosos agentes. Desde un punto de vista global e implementación, se pueden indentificar tres [171]: El arquitecto: que construye el BSC introduciendo el sistema de gestión. Debe conocer los objetivos tanto estratégicos como operativos, así como en detalle la empresa o proyecto. El agente del cambio: es el responsable de implantar el sistema de BSC. El comunicador: responsable de comunicar y de implicar a la organización en la implementación del BSC. Además existen otros interesados y que están afectados en la implantación del sistema: Equipo de gestión: tanto de la empresa como del proyecto, y son los que principalmente van a usarlo. Resto de stakeholders: (primarios y secundarios): resto de interesados, que sin pertenecer directamente a la empresa, o al proyecto también acceden a cierto nivel de información. Fases en la implementación de un CMI Kaplan y Norton [50] desarrollaron lo que se denomina el Modelo de las Cuatro Fases: FASE 1: Definición del concepto estratégico de la organización: En esta fase se debe generar diálogo en la empresa, de forma que se defina la estrategia y los objetivos para lograrla. FASE 2: Definición de objetivos, vectores y medidas estratégicas: en esta fase se deben definir los indicadores estratégicos clave a medir. FASE 3: Establecimiento de metas e iniciativas. Además de los parámetros se define el modo en cómo se va a implantarse el sistema. FASE 4: Comunicación, implantación y automatización: para aprovechar al máximo las capacidades de un BSC se debe integrar en los sistemas de comunicación tanto gerenciales como del resto de stakeholders. Se debería introducir una quinta fase, que se denominaría monitorización, de forma que del feedback de los stakeholders que usen el sistema de CMI, así como de la observancia y eficacia de las métricas establecidas, se realice un control y una posterior actualización del modelo. Siempre realizándolo dinámicamente, es decir a lo largo de la duración del proyecto, o mientras duren las operaciones de la compañía. En el MGIP el área de comunicación se trata de forma análoga al PMBOK®, planificando las actividades de comunicación en base a la identificación de las necesidades al respecto de los stakeholders y de las capacidades y sistemas que disponga la organización. En la FGP de ejecución, se distribuye la información que genera el proyecto y que transforma los datos brutos de desempeño del trabajo DDTRAB generados en el procesos de ejecución y que son analizados en el contexto de cada área ‐en los grupos de procesos de control‐, en la información de desempeño del trabajo INFDTRAB y que si se dispone en formato papel o electrónico para que pueda servir de base objetiva para que se pueda tomar una decisión, se denominan informes o reportes del desempeño del trabajo REPDTRAB. De forma que los REPDTRAB se distribuyen según el plan y las necesidades de los agentes. Finalmente en control se comprueba que la información se distribuye según el plan y que está produciendo el impacto y está cubriendo las necesidades de los agentes en cuanto a información. Enfoque de PMBOK® El enfoque del PMBOK® coincide exactamente con el MGIP e “Incluye los procesos requeridos para garantizar que la generación, la recopilación, la distribución, el almacenamiento, la recuperación y la disposición final de la información del proyecto, sean adecuados y oportunos”. Enfoque de ISO 21.500 Coincide con el enfoque de PMBOK®. 124
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
Enfoque de PRINCE2® La comunicación es un aspecto importante en PRINCE2® de hecho en el proceso de IP se generará la estrategia de comunicación en la que se definirá cómo afrontar este aspecto. También en la temática de organización se identifican a los stakeholders y cómo se debería producirse la comunicación entre ellos. 2.4.10. Riesgos La gestión de riesgos es básica para todos los enfoques ya que el cumplimiento de los objetivos del proyecto estarían en cuestión si no se estableciera un modelo sistemático de identificación, evaluación y de respuesta a las diferentes situaciones inciertas a las que eventualmente se podría enfrentar el proyecto. Así, un riesgo puede representar una amenaza para el proyecto y que de materializarse tendría consecuencias negativas, aunque también podrían ser positivas y en este caso se denominan oportunidades. De forma que la gestión de riesgos es el proceso continuo que comprende la identificación, el análisis y la respuesta al riesgo, con el objeto de maximizar los resultados positivos y minimizar los negativos. Esta forma de proceder debe ser sistemática a lo largo de todo el ciclo de vida del proyecto [172]. Por lo que los procesos de gestión de riesgos son críticos para el éxito del proyecto [173]. Según el PMBOK®: un riesgo es un evento o condición incierta, que si sucede, tiene un efecto, en por lo menos, uno de los objetivos del proyecto. Sus características principales son que se ubican siempre en el futuro, tienen su origen en la incertidumbre, pueden tener una o más causas y si suceden, pueden tener uno o más impactos y afectar a uno o más objetivos. Además los riesgos son inevitables en un proyecto, por lo que la gestión de riesgos debe ser sistemática y planificada, a lo largo de toda la vida del proyecto y ante ellos se debe tener una actitud proactiva; adelantarse y actuar en contra del riesgo. En cualquier caso la gestión del riesgo debe ser rentable, de forma que los costos para luchar contra las amenazas, deben ser inferiores al costo del impacto si el evento del riesgo se materializase. De hecho es un prerrequisito para la justificación comercial continua. Siendo sus objetivos fundamentales el de detectar las situaciones que pueden poner en cuestión la consecución de los objetivos del proyecto, gestionarlas de forma que se eliminen o reduzcan hasta un nivel tolerable y asegurar por tanto, el desarrollo del proyecto y su éxito anticipándose a los problemas, definiendo de antemano acciones adecuadas. Los proyectos se desarrollan en un entorno muy variable y se ven afectados por múltiples circunstancias. De hecho no hay dos proyectos iguales, los que parecen aparentemente idénticos tienen matices diferenciales que hacen que cada uno sea esencialmente distinto, como indica Merchán [174]. A lo largo del desarrollo del proyecto, desde su concepción, es factible que vayan surgiendo eventualidades que pueden afectar en mayor o menor grado su resultado. Por lo que, por ejemplo, en sectores como la construcción, la propia actividad de elaboración de sus productos y sus clientes están ampliamente asociados con un alto grado de riesgo debido a la naturaleza de las actividades, sus procesos, entorno y organizaciones, como expone Akitoye et al [175]. Así según Zou [176], la gestión de los riesgos en proyectos se reconoce como un proceso muy importante para conseguir alcanzar los objetivos primarios del proyecto, en concreto en lo relativo al tiempo, coste, calidad, seguridad y sostenibilidad ambiental. The British Standard on Project Management (EN BS 6.079‐3:2.000) define riesgo como incertidumbre inherente a los planes (contingencia), que puede afectar a la consecución de los objetivos del negocio o proyecto. Porter [177], Healey [178] y Perry et al [179] lo han definido como la exposición a una pérdida o ganancia económica, relacionado con el proceso constructivo. Los proyectos nacen en la incertidumbre, Chapman [180] plantea para intentar determinar las bases de partida, analizar el proyecto según el sistema de las 6 w´s ("who", "why", "what", "whichway", "wherewithal" and "when"). El nivel de incertidumbre será mayor conforme sea menor la definición del proyecto. Y en las fases iniciales del mismo éste es más elevado (AEDIP) [17]. Diversas organizaciones de distintos tipos de industrias y sectores admiten la creciente importancia de la gestión de riesgos, así muchas compañías han establecido departamentos que intentan resolver esta problemática. Además las empresas, compiten en un mercado muy agresivo y para conseguir ser lo más competitivas posible, los presupuestos que elaboran deben ser muy ajustados y para optimizarlos es necesario conocer los riesgos que eventualmente puedan afectar al mismo. Y gestionarlos con el objetivo de asegurar una rápida identificación y se pueda establecer un proceso claro de análisis y planificación de la respuesta (Simon [181]). Desde el punto de vista empresarial, la gestión de riesgos tiene muchas ventajas, como comentan De La Fuente y De la Vega, desde reducir los costes inesperados y obtener como primer rendimiento una mayor estabilidad de los resultados de la empresa consiguiendo por tanto una mayor competitividad hasta mejorar el control interno. Así plantean desarrollar una gestión integral de los riesgos englobando a todas las operaciones de la empresa (ERM; enterprise risk management). Otra faceta importante son las lecciones aprendidas tanto de los errores realizados y los aciertos, como de los riesgos que se pudieron identificar o no, permite evitar errores en el futuro (Stead y Smallman [182]), lo que facilita a 125
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
las empresas ser más eficientes en sus operaciones y por lo tanto ser más competitivos en el mercado. De hecho cualquier proyecto o negocio puede sufrir eventos o situaciones que puedan afectar positiva o negativamente, lo que puede comprometer seriamente en muchos casos, el cumplimiento de los objetivos establecidos inicialmente en el proyecto. Como se ha indicado, un riesgo se puede considerar como cualquier evento que puede afectar negativa o positivamente (oportunidad) a un proyecto. Así, la identificación y seguimiento y monitorio de los riesgos y oportunidades de un proyecto es un aspecto clave en la gestión estratégica y operativa del mismo. Relación de la gestión de riesgos con la consecución de objetivos Para garantizar la viabilidad de un proyecto, deben desaparecer las sorpresas (hasta lo humanamente posible) que pongan en cuestión la consecución de los objetivos del mismo. Además la gestión de los riesgos no sólo es una cuestión totalmente técnica y objetiva, desarrollada con un modelo económico, sino que tiene una fuerte carga de subjetividad y sufren, por tanto, la influencia de otros factores como formación, experiencia, capacidades personales, influencias del entorno, etc. (Choffray et al [183] y Ritchie et al [184, 185]). Hay otros aspectos que también influyen de forma decisiva en el análisis, como es el comportamiento de la organización (organizational behavior) a la hora de mantener aptitudes positivas en la gestión de los riesgos, y el aprendizaje que se genere por el proceso (organizational learning) (Liu [186]). También los agentes intervinientes en el proyecto (stakeholders), afectan e influyen el mismo, de forma que una incorrecta gestión de los mismos, tanto en la identificación (mapa de afectados) y selección como en la detección de sus necesidades o de su situación en el mismo respecto al poder de influencia (matriz de los afectados), como indica Roberts, puede generar riesgos importantes que pueden afectar directamente al desarrollo y a al coste del mismo. Desde la aparición en el mercado la metodología RiskMetrics por JP Morgan [187] para medir el riesgo de mercado de una cartera de títulos, las entidades financieras han avanzado mucho en la gestión de riesgo (De la Fuente y De la Vega [188]). De hecho las razones de las que estas metodologías no se han adaptado en este diferentes sectores, las apuntan Akitoye et al [175] según las conclusiones extraídas de los cuestionarios realizados a empresas constructoras y de gestión de proyectos en el Reino Unido. Así, para que las empresas las razones son: Falta de familiaridad con los sistemas. El grado de sofisticación relacionado con esta técnicas es no garantiza para el desarrollo del proyecto. Coste del tiempo necesario así como el desconocimiento de las técnicas e información sobre ellas. Dudas sobre si estas técnicas se pueden aplicar a la construcción. La mayoría de los proyectos no son lo suficientemente grandes como para usar dichas técnicas y sacar conclusiones. Necesitan asegurar la confidencialidad de los resultados. La mayoría de los riesgos son contractuales o relativos a la construcción y son muy subjetivos, por lo que se prefiere gestionarlos directamente con la experiencia de la empresa. Es difícil ver sus beneficios. Se pueden realizar diversas divisiones sobre el origen de los riesgos. Smallman [37], sugiere agruparlos en dos grandes categorías; riesgos directos (humanos, organizativos y tecnológicos (HOT)) e indirectos (regulaciones, infraestructuras y políticos (RIP)). Así, el estudio de un proyecto en una fase temprana tiene aspectos tremendamente positivos, como el de poder influir en él de forma que se pueda ajustar a los requisitos reales. Permitiendo modificar ciertos aspectos conforme se va desarrollando conceptualmente de forma más eficiente y además, el coste de hacerlo es muy bajo (conforme avanza el coste de la misma acción se incrementa exponencialmente). AEDIP (Asociación Española de Dirección Integrada de Proyecto) indica En su libro Blanco sobre la Dirección Integrada de Proyecto, que a medida que avanza el proyecto las posibilidades de minimizarlos riesgos disminuyen a la vez que el impacto de los mismos aumenta [17]. Por lo que gestionar un proyecto supone tener en cuenta todas las alteraciones que pueden producirse en el proyecto. Preverlas, cuantificarlas, detectarlas cuanto antes y corregir sus efectos ayuda a mantener controlado el alcance, coste y plazo del proyecto. A través del análisis y conocimiento tanto de la documentación del proyecto como del entorno del mismo (entendiendo entorno como a las circunstancias que pueden afectar al desarrollo y resultados del mismo), se podría realizar una valoración del presupuesto total basada en hipótesis. La perfección de esta valoración dependerá fundamentalmente, tanto del correcto análisis de estos factores como del nivel de definición que haya alcanzado el proyecto en el momento del análisis. De esta forma, es norma habitual en la técnica de presupuestación estimar un 126
Autor: Ángel Nájera Pérez
Parte II – El modelo de gestión integrada de proyectos MGIP
valor probable de presupuesto y un entorno de incertidumbre (reservas o cochones) que pueda absorber los posibles imprevistos en cada caso. Se ha planteado la realización un cálculo del valor monetario esperado en términos anuales, consiguiendo de esta forma un coste anual del riesgo. Una visión más amplia es la que se obtiene cuando se analiza el riesgo de un proyecto a lo largo de su desarrollo temporal, materializado en el resultado de su impacto en el flujo de caja del proyecto, lo que se denomina cash flow at risk (CFAR), lo que determinaría el peor flujo de caja que se produciría en un intervalo temporal y con un nivel de confianza determinado (González [36]). Aplicación de la gestión de riesgos en el control del presupuesto del proyecto En el PMBOK® se establecen seis pasos: planificación, identificación, análisis cualitativo, análisis cuantitativo, planes de contingencia y monitorización y control. Así, siguiendo estas directrices, el primer paso una vez definimos la estrategia en la gestión, sería analizar y estudiar el proyecto en fase inicial, (anteproyecto) mediante una exhaustiva revisión e identificar sistemáticamente los posibles riesgos y oportunidades que presenta. Este punto de partida es muy importante, ya que de la correcta identificación de riesgos dependerá la excelencia del resultado buscado, en concreto de la valoración monetaria del riesgo del proyecto. En primer lugar se debe desagregar el proyecto en tareas manejables, obteniendo lo que se denomina estructura desagregada del trabajo (EDT) y en la estructura desagregada de la organización (EDO) (Guerra, L., Coronel, A., Martinez de Irujo, L., Llorente, A [5]) que establece la jerarquía de las tareas de los proyectos organizados en niveles de forma que la suma de todas las tareas conforman la totalidad del alcance del proyecto. Posteriormente particularizaremos dichas tareas desde el punto de vista de la gestión de riesgos, desarrollando estructura desagregada del riesgo EDR (RBS risk breakdown structure, dividiendo y desarrollando todas las tareas que puedan generar riesgos en el proyecto. A partir de esta estructura el objetivo es identificarlos en cada área del mismo. Para ello se pueden utilizar técnicas de identificación de riesgos como: tormenta de ideas (brainstrorming), técnica Delphy, reuniones del equipo de proyecto, Ishikawa o espina de pez [189, 190]. Una se disponga una lista lo más exhaustiva posible deberemos cuantificar en términos económicos el impacto producido por cada uno, así como la probabilidad de que se produzca. Evidentemente en una fase tan temprana del proyecto, en muchos casos, estos dos términos tendrán una carga de subjetividad alta, por lo que se recomienda el uso de técnicas de estimación como el método Delphy para ítems importantes. A partir de aquí, se podría aplicar una modelización reducida del valor monetario esperado; de cada uno de los riesgos identificados, valorados en su posible impacto y a los que se les ha aplicado un porcentaje de probabilidad. Calculando de esta forma el EMV particular multiplicando los dos factores. A continuación se suman todos los valores EMV de todos los riesgos. A este valor global, se le denomina cuantificación del riesgo del proyecto o CRP. Que indicará en términos absolutos la valoración de nuestro desconocimiento del proyecto así como de los aspectos definidos o no él y que pueden afectarlo. Una vez obtenido este valor (en unidades monetarias), si se procede a calcular el porcentaje que representa sobre el total del presupuesto estimado del proyecto, obtendríamos la cuantificación relativa del riesgo del proyecto o CRRP. De una forma indirecta, se consigue unos beneficios adicionales ya que por el mero hecho de identificar y cuantificar los riesgos, se generarán acciones correctoras sobre ellos: en primer lugar eliminar el riesgo, y de no ser posible, se podrá o bien mitigar o transmitir. En última instancia sino es factible realizar ninguna de las acciones anteriormente citadas, se aceptará el riesgo, pero siempre previendo un plan de actuación. Seguimiento del presupuesto Una vez se ha calculado el CRP, y el proyecto ha comenzado y se va desarrollando, se debe considerar que su valor está vivo, es decir no es estático. Conforme éste va avanzando ciertos riesgos podrán desaparecer y otros nuevos surgir [191]. Además que tanto el impacto como la valoración del riesgo que realizará el equipo de gestión del proyecto podrán ir variando por la misma razón. Así pues, hay que aplicar el último paso del estándar en la gestión de riesgos; la monitorización. Consistente en la observancia del cumplimiento de las hipótesis sobre los riesgos identificados generadas y la revalorización de los mismos, pero también se debe realizar una continua labor de identificación de nuevos riesgos. Consecuentemente se puede deducir que se establecen dos tipos de riesgos fundamentales, los que se han identificado y los que no se conocen. Así el valor de CRP coincide con los riesgos detectados y conformarán la reserva de riesgos detectados (RRD) que sería análoga a la reserva de contingencia definida en el PMBOK y para el resto, se deberá dotar otra reserva, que en este caso sí deberá ir referida a un % del valor total del proyecto y dependerá de la naturaleza de aquel y fundamentalmente del entorno en el que se encuentra, que se denomina reserva de gestión (RG). Por lo que el presupuesto total objetivo (PTO) será la suma de los costes directos (CD) e indirectos del proyecto (CI) más las reservas indicadas anteriormente. PTO = [ CD + CI ] + [ RRD + RG ] 127
Procesos Integrados de gestión de proyecto diseñados bajo metodología PMBOK®, homologable con ISO 21.500 y compatible con PRINCE2®.
Como se ha indicado conforme progrese el proyecto en su ciclo de vida, el valor del PTO irá variando. Las modificaciones de las RRD y las RG se producirán de la misma forma y además deberán disminuir conforme avance el Proyecto ya que el riesgo global disminuye conforme se va acercando el final del mismo. De hecho es interesante analizar las posibilidades que se plantean conforme el CRP se modifica, y se compara con las RRD, ya que su aumento o disminución podrá plasmarse directamente en el aumento o reducción del valor total del PTO con el consiguiente impacto en la cuenta de resultados del proyecto. O bien es factible que se produzca un trasvase de cantidades de una reserva a otra. Se plantean más opciones cuando se analiza la RRD, ya que el equipo de gestión tiene varias opciones tanto si aumenta como si disminuye. Pudiendo aplicar las modificaciones directamente sobre la cuenta de resultados o también pueden aumentar o disminuir las dotaciones de la RC. Dichas opciones se exponen a continuación en la Tabla 5: mod presupuesto total ¿?
CRP = RRD
NO SI
acción
monitorizar Aumentar el valor de la RRD
PTO
Cuenta de Resultado del Proyecto
n.m.
n.m.
aumenta
disminuye
CRP > RRD NO
monitorizar exhaustivamente*
n.m.
n.m.
NO
Aumentar el valor de la RC
n.m.
n.m.
disminuye
aumenta
CRP