PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ Escuela de Posgrado Definición de Marco de trabajo para la implementación de una Oficina de Gestión de Proyectos (PMO) de Tecnologías de Información Tesis para optar el grado académico de Doctor en Ingeniería que presenta: Braulio Oscar Murillo Veliz Asesor: Dr. Jose Antonio Pow Sang Portillo Lima, 2024 Informe de Similitud Yo, José Antonio Pow Sang Portillo, docente de la Escuela de Posgrado de la Pontificia Universidad Católica del Perú, asesor(a) de la tesis/el trabajo de investigación titulado Definición de marco de trabajo para la implementación de una oficina de gestión de proyectos (PMO) de Tecnologías de Información, del/de la autor(a) / de los(as) autores(as) Braulio Oscar Murillo Veliz, , dejo constancia de lo siguiente: - El mencionado documento tiene un índice de puntuación de similitud de 23%. Así lo consigna el reporte de similitud emitido por el software Turnitin el 06/06/2024. - He revisado con detalle dicho reporte y la Tesis o Trabajo de Suficiencia Profesional, y no se advierte indicios de plagio. - Las citas a otros autores y sus respectivas referencias cumplen con las pautas académicas. - Comentarios adicionales: ……………………………………………………………… ……………………………………………………………………………………………. ……………………………………………………………………………………………. Lugar y fecha: Lima, 13 de junio del 2024 Apellidos y nombres del asesor / de la asesora: Pow Sang Portillo, José Antonio DNI: 21520576 Firma ORCID: 0000-0003-4001-8072 1 2 Resumen La gestión de proyectos tecnológicos representa un reto para las organizaciones aun cuando existen sinnúmero de metodologías y herramientas que facilitan la gestión de proyectos. El problema se agrava, cuando las organizaciones tienen que ejecutarlos en paralelo. Ante estas dificultades, las organizaciones giran su interés en las oficinas de gestión de proyectos o PMO (Project Management Office). Sin embargo, las organizaciones tienen muchas dificultades cuando tratan de definir el tipo de PMO a implementar y las funciones que deben tener. Por esta razón se propone el presente proyecto de investigación cuyo objetivo es definir un marco de trabajo que permita implementar una PMO y que logre la ejecución eficaz y eficiente de proyectos. Para ello se ha realizado una revisión exhaustiva de trabajos publicados que presentan la implementación y uso de PMO. Tomando en consideración dichas propuestas se propone un nuevo marco de trabajo que integre los criterios básicos que se deben tener en cuenta para definir una PMO como son: la estructura, nivel de madurez e influencia, funciones, roles y responsabilidades del equipo, nivel y estrategia de gobierno, métricas de medición. Adicionalmente, se valida cuantitativamente la primera parte de la propuesta, evaluando el impacto de una PMO implementada bajo este marco de trabajo, logrando medir el cumplimiento de tiempo y costos de los proyectos. También, se realiza una segunda propuesta que se evalúa cualitativamente mediante entrevistas a expertos, quienes la validan y proponen algunas sugerencias con las que se elabora una propuesta final. Con los resultados obtenidos, se muestra que la implementación de una PMO favorece la ejecución de los proyectos logrando aportar al cumplimiento de los objetivos de la organización. Palabras clave: Oficina de gestión de proyectos, PMO, implementación de PMO, marco de trabajo, proyectos tecnológicos. 3 Abstract The management of technological projects represents a challenge for organizations even though there are countless methodologies and tools that facilitate project management. The problem is compounded when organizations have to execute them in parallel. Faced with these difficulties, organizations turn their interest in the Project Management Offices or PMO since these are the calls to solve the problems raised above. However, organizations have many difficulties when trying to define the type of PMO to implement and the functions they should have. For this reason, this research project is proposed to define a framework that allows the implementation of a PMO and that achieves the effective and efficient execution of projects. To this end, an exhaustive review of published works that present the implementation and use of PMO has been carried out. Taking these proposals into consideration, a new framework is proposed that integrates the basic criteria to define a PMO, such as: structure, level of maturity and influence, functions, roles and responsibilities of the team, level and strategy. governance, measurement metrics. Additionally, the first part of the proposal is quantitatively validated, evaluating the impact of a PMO implemented under this framework, measuring compliance with project time and costs. Also, a second proposal is made that is qualitatively evaluated through interviews with experts, who validate it and propose some suggestions with which a final proposal is prepared. With the results obtained, it is shown that the implementation of a PMO favours the execution of projects, contributing to the fulfilment of the organization's objectives. Keywords: Project management office, PMO, PMO implementation, implementation framework, technological projects. 4 Índice Resumen ........................................................................................................................... 2 Índice ................................................................................................................................. 4 Índice de Ilustraciones ...................................................................................................... 8 Índice de Tablas.............................................................................................................. 10 Capítulo 1. Introducción .............................................................................................. 13 1.1 Problemática .................................................................................................... 13 1.2 Objetivo general ............................................................................................... 15 1.3 Objetivos específicos ....................................................................................... 15 Capítulo 2. Marco conceptual...................................................................................... 17 2.1 Proyecto ........................................................................................................... 17 2.2 Oficina de Gestión de Proyectos ..................................................................... 18 2.3 Criterios de Implementación de PMO .............................................................. 21 2.4 Portafolio de Proyectos .................................................................................... 23 2.5 Interesado o Stakeholder ................................................................................. 24 2.6 Gobierno Corporativo y Gobierno de TI .......................................................... 24 2.7 Indicadores de Desempeño ............................................................................. 25 Capítulo 3. Revisión de la Literatura ........................................................................... 27 3.1 Definición del proceso de Revisión Sistemática .............................................. 27 3.2 Preguntas de investigación .............................................................................. 27 3.3 Estrategia de búsqueda ................................................................................... 28 3.4 Proceso de búsqueda y selección ................................................................... 29 3.5 Análisis y reporte de resultados ....................................................................... 35 3.5.1 Estructura de la PMO ............................................................................... 35 3.5.2 Funciones de la PMO ............................................................................... 37 3.5.3 Gobierno en la PMO ................................................................................. 40 3.5.4 Roles y Responsabilidades en la PMO .................................................... 43 5 3.5.5 Indicadores de desempeño en la PMO .................................................... 46 3.5.6 Resultados por dominio de software (contexto) ....................................... 49 3.5.7 Resultados por tipo de Organización ....................................................... 50 3.6 Conclusiones .................................................................................................... 50 Capítulo 4. Metodología de la investigación ............................................................... 52 4.1 Visión general................................................................................................... 52 4.2 Descripción de la población ............................................................................. 52 4.3 Fases y procedimientos ................................................................................... 53 Primera hipótesis ..................................................................................................... 55 Segunda hipótesis ................................................................................................... 55 4.4 Consistencia de la metodología con los objetivos de investigación ............... 56 Capítulo 5. Propuesta de implementación de una PMO – Parte I ............................. 58 5.1 Evaluar necesidad de PMO ............................................................................. 58 5.2 Evaluar riesgos en la implementación ............................................................. 61 5.3 Establecer visión, misión y objetivos de la PMO ............................................. 64 5.3.1 Misión ........................................................................................................ 64 5.3.2 Visión ........................................................................................................ 64 5.3.3 Objetivos ................................................................................................... 65 5.4 Definir ubicación dentro de la organización .................................................... 65 5.5 Definir roles y responsabilidades ..................................................................... 67 5.6 Definir estructura de Gobierno y Escalamiento ............................................... 68 5.6.1 Proceso de solicitud de nuevos requerimientos/proyectos...................... 68 5.7 Definir funciones .............................................................................................. 71 5.7.1 Funciones relacionadas al Conocimiento ................................................ 71 5.7.2 Funciones relacionadas al Control ........................................................... 71 5.7.3 Funciones relacionadas a la Gestión de recursos ................................... 72 6 5.8 Definir métricas de medición............................................................................ 72 5.8.1 Monitoreo de indicadores ......................................................................... 76 5.8.2 Factores críticos de éxito de la implementación de la PMO .................... 77 Capítulo 6. Validación de la Primera Propuesta ......................................................... 79 6.1 Contexto de aplicación ..................................................................................... 79 6.2 Análisis de tiempo de ejecución de proyectos ................................................ 80 6.3 Análisis de costos de proyectos ...................................................................... 83 Capítulo 7. Propuesta de implementación de una PMO – Parte II ............................ 88 7.1 Definir roles y responsabilidades ..................................................................... 88 7.2 Definir estructura de Gobierno y Escalamiento ............................................... 88 7.2.1 Proceso de priorización de proyectos ...................................................... 88 7.2.2 Proceso de escalamiento ......................................................................... 96 7.2.3 Proceso de Comunicaciones .................................................................... 97 7.3 Definir funciones .............................................................................................. 99 7.3.1 Funciones relacionadas al Conocimiento ................................................ 99 7.3.2 Funciones relacionadas al Control ........................................................... 99 7.3.3 Funciones relacionadas a la Gestión de recursos ................................. 100 7.4 Definir métricas de medición.......................................................................... 100 7.5 Definir proyección de crecimiento (madurez) ................................................ 103 Capítulo 8. Validación de la Segunda Propuesta ..................................................... 106 8.1 Proceso de validación .................................................................................... 106 8.1.1 Convocatoria de expertos ....................................................................... 106 8.1.2 Expertos entrevistados ........................................................................... 106 8.2 Discusión del caso ......................................................................................... 107 8.2.1 Definición de roles y responsabilidades ................................................. 107 8.2.2 Definición de estructura de Gobierno y Escalamiento ........................... 109 8.2.3 Definición de funciones........................................................................... 112 7 8.2.4 Definición de métricas de medición ........................................................ 114 8.2.5 Definición de proyección de crecimiento (modelo de madurez) ............ 116 Capítulo 9. Propuesta mejorada para implementación de una PMO ....................... 120 9.1 Visión general de la propuesta mejorada ...................................................... 120 9.2 Definir roles y responsabilidades ................................................................... 121 9.3 Definir estructura de Gobierno y Escalamiento ............................................. 121 9.3.1 Proceso de priorización de proyectos .................................................... 122 9.3.2 Proceso de escalamiento ....................................................................... 129 9.3.3 Proceso de Comunicaciones .................................................................. 130 9.4 Definir funciones ............................................................................................ 132 9.4.1 Funciones relacionadas al Conocimiento .............................................. 133 9.4.2 Funciones relacionadas al Control ......................................................... 133 9.4.3 Funciones relacionadas a la Gestión de recursos ................................. 134 9.5 Definir métricas de medición.......................................................................... 134 9.6 Definir proyección de crecimiento (madurez) ................................................ 138 Capítulo 10. Conclusiones y trabajos futuros .......................................................... 142 Referencias ................................................................................................................... 146 Anexo 1 – Protocolo de Consentimiento Informado (Entrevista)................................. 155 Anexo 2 – Lineamientos del Cuestionario Fase Cualitativa ........................................ 157 Anexo 3 – Transcripción de la Entrevista 1.................................................................. 159 Anexo 4 – Transcripción de la Entrevista 2.................................................................. 181 Anexo 5 – Transcripción de la Entrevista 3.................................................................. 197 8 Índice de Ilustraciones Ilustración 1. Porcentaje de organizaciones con PMOs. Tomado de PM Solutions (PM Solutions, 2020) .............................................................................................................. 14 Ilustración 2. Triple restricción en la gestión de proyectos. Elaboración propia. .......... 18 Ilustración 3. Interesados de los proyectos. Tomado de ISO 21500 (International Organization for Standardization, 2012). ....................................................................... 19 Ilustración 4. Vista de alto nivel: Portafolios, Programas y Proyectos. Adaptado de PMI (Project Management Institute, 2018b). ......................................................................... 24 Ilustración 5. Diagrama de flujo del proceso PRISMA. Adaptado (Liberati et al., 2009). ........................................................................................................................................ 30 Ilustración 6. Propuesta de estructura de PMO. Elaboración propia. ........................... 36 Ilustración 7. Estructura organizacional en la PMO. Elaboración propia ...................... 46 Ilustración 8. Ubicación de la PMO. Elaboración propia. ............................................... 66 Ilustración 9. Ubicación de la PMO (siguiente nivel). Elaboración propia ..................... 66 Ilustración 10. Proceso de Solicitud de nuevos requerimientos. Elaboración propia ... 70 Ilustración 11. Prueba de normalidad de sobretiempos (antes de la PMO) .................. 81 Ilustración 12. Prueba de normalidad de sobretiempos (después de la PMO) ............. 82 Ilustración 13. Prueba de normalidad de sobrecostos (antes de la PMO) .................... 85 Ilustración 14. Prueba de normalidad de sobrecostos (después de la PMO) ............... 86 Ilustración 15. Inversión de proyectos por Unidad funcional. Elaboración propia. ....... 94 Ilustración 16. Inversión en proyectos por Categoría. Elaboración propia. ................... 95 Ilustración 17. Proceso actualizado de Solicitud de nuevos requerimientos. Elaboración propia. ............................................................................................................................. 96 Ilustración 18. Niveles de escalamiento en la PMO. Elaboración propia. ..................... 97 Ilustración 19. Inversión de proyectos por Unidad funcional. Elaboración propia. ..... 127 Ilustración 20. Inversión en proyectos por Categoría. Elaboración propia. ................. 128 9 Ilustración 21.Proceso actualizado de Solicitud de nuevos requerimientos. Elaboración propia. ........................................................................................................................... 129 Ilustración 22. Niveles de escalamiento en la PMO. Elaboración propia. ................... 130 10 Índice de Tablas Tabla 1. Definición de los conceptos generales utilizando PICOC ............................... 28 Tabla 2. Términos de búsqueda ..................................................................................... 28 Tabla 3. Resumen de los resultados de las búsquedas ................................................ 31 Tabla 4. Listado de todos los artículos seleccionados .................................................. 31 Tabla 5. Frecuencia de uso de los marcos de trabajos para PMO ............................... 35 Tabla 6. Comparación de estructuras de PMO .............................................................. 36 Tabla 7. Funciones de la PMO ....................................................................................... 38 Tabla 8. Modos de Gobierno de TI ................................................................................. 40 Tabla 9. Estrategias de Gobierno ................................................................................... 41 Tabla 10. Roles y Responsabilidades en la PMO .......................................................... 44 Tabla 11. Principales criterios de éxito de una PMO ..................................................... 47 Tabla 12. Factores de éxito de la PMO .......................................................................... 48 Tabla 13. Resumen de criterios para implementar una PMO ....................................... 48 Tabla 14. Estudios encontrados por dominio de software ............................................. 49 Tabla 15. Estudios encontrados por tipo de organización ............................................. 50 Tabla 16. Fases de la metodología aplicada ................................................................. 53 Tabla 17. Tareas para la implementación de la PMO ................................................... 59 Tabla 18. Riesgos identificados en la implementación de la PMO................................ 62 Tabla 19. Roles y Responsabilidades en la PMO .......................................................... 67 Tabla 20. Objetivos e indicadores .................................................................................. 73 Tabla 21. Indicadores de medición ................................................................................ 74 Tabla 22. Matriz de monitoreo de indicadores en un periodo ....................................... 77 Tabla 23. Sobretiempos en la ejecución de proyectos antes de la PMO ...................... 80 Tabla 24. Sobretiempos en la ejecución de proyectos después de la PMO ................. 80 Tabla 25. Comparación de medianas de sobretiempos ................................................ 83 11 Tabla 26. Determinación de la mediana mayor ............................................................. 83 Tabla 27. Sobrecostos en la ejecución de proyectos antes de la PMO ........................ 84 Tabla 28. Sobrecostos en la ejecución de proyectos después de la PMO ................... 84 Tabla 29.Comparación de medianas de sobrecostos ................................................... 86 Tabla 30. Determinación de la mediana mayor ............................................................. 87 Tabla 31. Niveles de Puntaje .......................................................................................... 89 Tabla 32. Puntaje por Categorías .................................................................................. 90 Tabla 33. Pesos por criterios .......................................................................................... 90 Tabla 34. Proyectos evaluados ...................................................................................... 91 Tabla 35. Proyectos ordenados por puntaje .................................................................. 91 Tabla 36. Evaluación de priorización de proyectos ....................................................... 93 Tabla 37. Proyectos priorizados ..................................................................................... 93 Tabla 38. Matriz de comunicaciones de la PMO ........................................................... 98 Tabla 39. Objetivos e indicadores ................................................................................ 101 Tabla 40. Indicadores de medición .............................................................................. 102 Tabla 41. Niveles de madurez de la PMO ................................................................... 104 Tabla 42. Información de los expertos ......................................................................... 106 Tabla 43. Niveles de Puntaje ........................................................................................ 122 Tabla 44. Puntaje por Categorías ................................................................................ 123 Tabla 45. Pesos por criterios ........................................................................................ 123 Tabla 46. Proyectos evaluados .................................................................................... 124 Tabla 47. Proyectos ordenados por puntaje ................................................................ 125 Tabla 48. Evaluación de priorización de proyectos ..................................................... 126 Tabla 49. Proyectos priorizados ................................................................................... 127 Tabla 50. Matriz de comunicaciones de la PMO ......................................................... 131 Tabla 51. Objetivos e indicadores ................................................................................ 134 12 Tabla 52. Indicadores de medición .............................................................................. 136 Tabla 53. Niveles de madurez de la PMO ................................................................... 139 13 Capítulo 1. Introducción En la actualidad, las organizaciones están bajo una presión cada vez mayor del entorno externo, que les exige una innovación constante en productos y servicios para obtener una ventaja competitiva y satisfacer las necesidades de los clientes. Para seguir siendo competitivas, las organizaciones de hoy adoptan prácticas de gestión de proyectos, definidas como la aplicación de conocimientos, habilidades, herramientas y técnicas para cumplir con los requisitos y objetivos de los proyectos mediante la implementación de procesos y metodologías adecuadas, como parte de su estrategia y como factor crítico en el desarrollo de ventajas competitivas (Monteiro et al., 2016). Por esa razón, la gestión de proyectos tecnológicos sigue representando un reto para las organizaciones aun cuando existen sinnúmero de metodologías y herramientas que facilitan la gestión de los proyectos en ejecución. El problema se agrava, cuando las organizaciones tienen que ejecutar más de un proyecto en paralelo. En el siguiente capítulo se presentará el planteamiento de la problemática, basado en estudios de instituciones internacionales que muestran las dificultades con las que lidian las organizaciones en la gestión de proyectos. Adicionalmente, se define el objetivo principal del trabajo de investigación y los objetivos específicos que se buscan alcanzar. 1.1 Problemática De acuerdo al estudio PMI Pulse of the Profession del año 2018 (Project Management Institute, 2018a), 9.9% de cada dólar es desperdiciado debido a una pobre gestión de proyectos. Esto quiere decir que se pierden $99 millones por cada billón invertido. Las razones de la pobre gestión de proyectos se pueden deberse diversas razones: • Las organizaciones no logran cerrar la brecha entre el diseño de estrategias y el cumplimiento de resultados. • Los ejecutivos no reconocen que la estrategia se cumple a través de los proyectos. • La importancia esencial de la gestión de proyectos como motor de la estrategia de una organización no se comprende por completo. Ante estas dificultades, las organizaciones toman diferentes estrategias como por ejemplo invertir en la creación de una oficina de gestión de proyectos o PMO (Project Management Office), entrenar a los equipos de proyecto e incorporar prácticas de 14 gestión de proyectos para hacer a la organización más madura (Irfan et al., 2019). Adicionalmente, debido al incremento en el número de proyectos y su progresiva complejidad, se hace imperativo que las organizaciones tengan sus propias PMO (Otero Ramirez & Rincon-Gonzalez, 2020). Sin embargo, para muchas organizaciones la propia definición del rol de la PMO es una lucha, junto con su posición para el éxito a largo plazo el logro de los objetivos estratégicos de la organización (Project Management Institute, 2013a). Las organizaciones también tienen muchas dificultades cuando tratan de definir el tipo de PMO a implementar y las funciones que deben tener. Los principales retos que deben enfrentar estas iniciativas son: definir formalmente el rol de la PMO, gestionar los recursos, asegurar la aplicación consistente de los procesos definidos y demostrar el valor agregado que representa contar con una PMO (PM Solutions, 2012). De acuerdo al último estudio The state of Project management del año 2020 (PM Solutions, 2020), el 79% de organizaciones cuentan con una PMO y en la ilustración siguiente se pueden ver los porcentajes por tamaño de organización. Ilustración 1. Porcentaje de organizaciones con PMO. Tomado de PM Solutions (PM Solutions, 2020) Si bien, en anteriores estudios de la misma empresa se observa que los porcentajes no varían considerablemente. Se observa que para las pequeñas empresas el número decrece. Esta caída en las estadísticas puede deberse a que en 2012 (PM Solutions, 2012), se descubrió que las pequeñas empresas presentan muchas más dificultades 15 con sus PMO que las empresas medianas o grandes, así el 16% de pequeñas empresas consideran cerrar sus PMO versus el 4% de empresas grandes que planean lo mismo. La implementación de las PMO tiene una alta tasa de falla, tal como lo reporta Gartner (Fitzgerald, 2014). Tres de cuatro aplicaciones de la PMO fallaron en 3 años, como reportó la Association for Project Management (APM) en el Project Management Institute Global Congress del 2010 (Schibi, 2013). Según los autores Hobbs y Aubry (Hobbs & Aubry, 2007), no existe consenso sobre la forma en que las PMO deberían estar estructuradas ni sobre las funciones que deberían o cumplen en las organizaciones. A pesar de la importancia de este fenómeno y la falta de comprensión, ha habido muy poca investigación sobre este tema. En tal sentido, cuando se busca evidencia de marcos de trabajo o frameworks que sirvan de guía para la implementación de PMO, no se encuentran muchos casos de estudios que muestren implementaciones exitosas. Diversos autores proponen recomendaciones para la implementación de PMO, pero no son propuestas completas. Como sugiere McKay (McKay et al., 2013), se deben tener en cuenta diferentes factores a la hora de implementar una PMO: saber diseñarla, planificar los recursos que utilizará, el nivel de habilidades de liderazgo que requerirá de sus miembros, la definición de métricas y el nivel de gobierno requerido. Por esa razón, el objetivo de este trabajo es precisamente proponer un marco de trabajo flexible y adaptable que permita a las organizaciones, de tipo gran empresa, implantar sus PMO ya que éstas siguen expandiéndose, adquiriendo mayor influencia y convirtiéndose en estratégicas dentro de las mismas. Para ello, se revisará la literatura y las buenas prácticas que faciliten la implementación de PMO y luego se presentará una propuesta de marco de trabajo orientada a la gestión de proyectos de tecnologías de información en organizaciones de cualquier industria. 1.2 Objetivo general Definir y validar un marco de trabajo para la implementación de una Oficina de Gestión de Proyectos (PMO) de Tecnología de Información. 1.3 Objetivos específicos OE1: Realizar un análisis de las actuales propuestas de marco de trabajo para la implementación de Oficina de Gestión de Proyectos presentes en la literatura. 16 OE2: Definir el marco de trabajo para la implementación de una Oficina de Gestión de Proyectos en una organización. OE3: Validar el marco de trabajo propuesto comparando los resultados obtenidos luego de la implementación en términos de tiempos y costos, así como la validación por expertos. 17 Capítulo 2. Marco conceptual El presente proyecto de investigación tiene como objetivo definir un marco de trabajo para implementar una PMO que permita a las organizaciones mejorar la gestión de sus proyectos para alcanzar mejores resultados en su ejecución. Para este fin, en este capítulo se desarrolla el marco teórico que soporte el entendimiento de la problemática, describiendo los conceptos más relevantes que se utilizarán para el desarrollo del marco de trabajo para la implementación de una PMO. 2.1 Proyecto El concepto de proyecto ha sido definido por distintos autores. A continuación, se presentan algunas de las definiciones más relevantes. El PMBOK del PMI (Project Management Institute, 2017) define al proyecto como un “esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único”. También hace una diferenciación entre proyectos y procesos, ya que los proyectos por el contrario de las operaciones en curso en una organización tienen un comienzo y un final definidos, tienen una duración limitada. Por su parte, el IPMA en su publicación Individual Competence Baseline (International Project Management Association, 2015), define al Proyecto como un esfuerzo único, temporal, multidisciplinario y organizado para lograr entregables acordados dentro de los requisitos y limitaciones predefinidos. En la publicación Managing Successful Projects de PRINCE2 (Axelos, 2017), un proyecto se define como una organización temporal que se crea con el propósito de entregar uno o más productos comerciales de acuerdo con un caso comercial acordado. En la norma ISO 21500 (International Organization for Standardization, 2012) se define a un Proyecto como un conjunto único de procesos que consta de actividades coordinadas y controladas con fechas de inicio y fin, ejecutadas para lograr los objetivos del proyecto. Como se puede apreciar en las definiciones previas, todas tienen puntos en común y no difieren en lo esencial. Estas definiciones concuerdan en la temporalidad (tiempo), cumplimiento de objetivos, calidad de entregables y los recursos. Son precisamente estas características que forman el modelo conocido como la “triple restricción”, que consiste en graficarlo como un triángulo donde los lados son representados por el 18 tiempo, costo y alcance. El interior del triángulo representa la calidad del producto. Esto significa que si por ejemplo se limitan los recursos, se impactan negativamente los otros criterios (Mokoena et al., 2014; Pollack et al., 2018). En la ilustración siguiente se muestra el concepto de la triple restricción. 2.2 Oficina de Gestión de Proyectos A continuación, se presentan las principales definiciones de la Oficina de Gestión de Proyectos o PMO por sus siglas en inglés (Project Management Office). El PMBOK del PMI (Project Management Institute, 2017) define a la PMO como “una estructura de la organización que estandariza los procesos de gobernanza relacionados con el proyecto y facilita el intercambio de recursos, metodologías, herramientas y técnicas. El PMBOK también identifica que pueden existir tres tipos de PMO dependiendo del grado de control e influencia que ejerce sobre la gestión de proyectos dentro de la organización. Estos tipos pueden ser: • De apoyo, el rol de la PMO es consultivo proporcionando plantillas, mejores prácticas, capacitación, lecciones aprendidas, etc. Se comporta como un repositorio de proyectos. • De control, la PMO ofrece soporte y exige el cumplimiento de marcos, metodologías, plantillas, herramientas específicas, así como alinearse a los marcos de gobernanza. • Directiva, la PMP ejerce un alto control de los proyectos, asignan a los gerentes de proyectos. Por su parte, el IPMA en su publicación Individual Competence Baseline (International Project Management Association, 2015), establece que la PMO es quien define la Costo Tiempo Alcance Calidad Ilustración 2. Triple restricción en la gestión de proyectos. Elaboración propia. 19 estrategia y los objetivos para todas las actividades relacionadas con la gestión de proyectos. Adicionalmente, promueve el desarrollo de las competencias colectivas y organizacionales a través del coaching, mentoría y entrenamiento. En la publicación Managing Successful Projects de PRINCE2 (Axelos, 2017), se define a la PMO como una oficina temporal establecida para apoyar la entrega de un proyecto específico. La oficina del proyecto asume la responsabilidad del rol de apoyo al proyecto. La PMO también es conocida como oficina de gestión de programas, oficina de gestión de portafolios. También puede ser visto como un centro de excelencia. En la norma ISO 21500 (International Organization for Standardization, 2012) se define a la PMO como la responsable de realizar una amplia variedad de actividades, incluida la gobernanza, la estandarización, la formación en gestión de proyectos, la planificación y el seguimiento de proyectos. Considera a la PMO como un interesado adicional en la gestión de proyectos. En la siguiente ilustración se puede apreciar a la PMO como un interesado más en la gestión de proyectos. Ilustración 3. Interesados de los proyectos. Tomado de ISO 21500 (International Organization for Standardization, 2012). Para Kerzner (Kerzner, 2017), la PMO o PO (Project Office), como también la llama, es una organización desarrollada para brindar soporte a la gestión de los proyectos, por ende al gerente de proyectos. Las principales responsabilidades de la PMO son: 20 • Actuar como punto focal de información tanto para el control interno como para la generación de informes al cliente. • Controlar el tiempo, el costo y el rendimiento para cumplir con los requisitos contractuales. • Asegurarse de que todo el trabajo requerido esté documentado y distribuido a todo el personal clave. • Asegurarse de que todo el trabajo realizado esté autorizado y financiado por la documentación contractual. Adicional a ello, Kerzner define que la principal responsabilidad de la PMO es la integración del trabajo a través de las líneas funcionales de la organización Otra definición es propuesta por Wysocki (Wysocki, 2011), quien define a la PMO o PSO (Project Support Office), como también la llama, como una unidad organizativa temporal o permanente que proporciona un catálogo de servicios para apoyar a los equipos de proyectos. Para Wysocki, contar con una PMO es una oportunidad para establecer una entidad que asegure el cumplimiento y éxito del proyecto. Lo considera como una póliza de seguro que protege la adopción y la difusión de la metodología de la gestión de proyectos. Wysocki va más allá en su definición, también propone las principales funciones de la PMO: • Soporte de proyectos, sobre todo en la parte administrativa (documentación, reportes). • Consultoría y Mentoría, para cualquier miembro del equipo de gestión de proyecto que lo requiera. • Proporcionar métodos y estándares, también debe monitorear y promover su uso. • Proporcionar y recomendar el uso de herramientas de software que incrementen la productividad en la gestión de proyectos. • Proporcionar entrenamiento profesional al equipo de gestión de proyectos. • Recursos para la gestión de proyectos, sobre todo los recursos humanos que requieran los gerentes de proyecto. 21 De las definiciones presentadas, todas concuerdan que la PMO es un organismo dentro de una organización que debe ayudar, controlar y definir sus estándares de gestión de proyectos. Cobra relevancia porque son cada vez más las organizaciones que se orientan a los proyectos como una forma de alcanzar metas. También se encontraron que las funciones de la PMO pueden variar en urgencia, sofisticación y en nivel de aplicación, por ejemplo: establecer estándares de la industria, integrar la administración de proyectos en la organización, mejorar el desempeño de la administración de proyectos, desarrollar el reconocimiento de la administración de proyectos, implementar una administración de proyectos formal y consistente, o en resumidas cuentas que el proyecto sea ejecutado exitosamente. 2.3 Criterios de Implementación de PMO Como sugiere McKay (McKay et al., 2013), se deben tener en cuenta diferentes factores a la hora de implementar una PMO: saber diseñarla, planificar los recursos que utilizará, el nivel de habilidades de liderazgo que requerirá de sus miembros, la definición de métricas y el nivel de gobierno requerido. Por su parte, en su trabajo Salameh (Salameh, 2014) considera que deben tomarse en cuenta los siguientes criterios al definir una PMO. • Definir misión, objetivos y estrategia. La misión de la PMO es una declaración general que alinea a la PMO con el valor que proporciona a la organización. La estrategia de PMO define, en un alto nivel, el proceso y la hoja de ruta para lograr la misión de la PMO. • Especificar funciones y tipos de PMO. Las PMO pueden variar según su contexto organizacional, características estructurales (como dónde se encuentra la PMO en la organización) y roles o funciones. • Definir criterios de éxitos y métricas. Definir un conjunto de métricas que mida el desempeño de la PMO y proporcione una indicación de su desempeño. • Definir estructura dentro de la organización. Determinar cómo la PMO se integrará a la organización y cómo las personas interactuarán con ella. • Definir equipo de PMO. Establecer el equipo que forma parte de la PMO, así como sus roles y responsabilidades. En su libro, Kerzner (Kerzner, 2017) considera otros criterios adicionales como son: 22 • Riesgos de Implementación. Se debe tener en cuenta que la implementación de una PMO generará resistencia en la organización por las responsabilidades que aquella asuma. El nivel de resistencia es directamente proporcional al riesgo que representa. Por eso se sugiere que se evalúen los posibles riesgos de implementación. Recomienda que, para obtener apoyo para la implementación de la PMO, esta debe realizar primero actividades de bajo riesgo, como las operativas de soporte a la gestión de proyectos en el corto plazo. Las responsabilidades de planificación estratégica y control de información sensible, que serían considerados como actividades de alto riesgo, deberían realizarse después. • Benchmarking en la gestión de proyectos. Está directamente relacionada con la planificación estratégica para la gestión de proyectos y puede tener un efecto importante en los resultados corporativos en función de la rapidez con la que se implementan los cambios. Para esta tarea se debe saber qué buscar, qué preguntas realizar, tener la capacidad de reconocer que lo obtenido pueda encajar en la organización y en base a ello realizar las recomendaciones. • Desarrollo de Casos de Negocio (Business Case). La PMO debe desarrollar experiencia en estudios de viabilidad, análisis de costo-beneficio y desarrollo de casos de negocios. Así podrá brindar un mejor soporte a la función de planificación estratégica corporativa. • Planificación de capacidad. Considerada por Kerzner como la tarea más importante de la PMO a los ojos de la alta dirección, ya que esta debe saber cuánto trabajo adicional puede asumir la organización, así como cuándo y dónde sin sobrecargar excesivamente la mano de obra existente. La PMO debe trabajar en estrecha colaboración con la alta dirección en todas las actividades relacionadas con la gestión del portafolio y la selección de proyectos. En su libro, Wysocki (Wysocki, 2011) considera otros criterios adicionales que no se lograron encontrar detalladamente en la literatura: • Evaluación de si la PMO es necesaria. Se sugiere analizar al menos 4 razones por la que la organización debería implementar una PMO: Establecer procedimientos para gestionar los proyectos, Centralizar el inventario de los proyectos e identificar las necesidades de entrenamiento, Establecer los estándares 23 y buenas prácticas para tener un impacto positivo en la eficiencia y productividad, Ser la responsable del entrenamiento de los equipos de gestión de proyectos. • Establecer la misión y objetivos de la PMO. Una vez que se tiene la decisión tomada de establecer la PMO, esta debe ser la primera tarea por realizar. Los objetivos deben definir el valor de la PMO y hacerlo realidad. Adicionalmente, estos deben ser específicos y medirse fácilmente. • Etapas de crecimiento de la PMO. Se definen niveles de madurez de la PMO, las cuales se dividen en 5: Inicial, Repetible, Definido, Gestionado, Optimizado. 2.4 Portafolio de Proyectos Un portafolio es una colección de proyectos, programas, portafolios subsidiarios y operaciones que se gestionan en grupo para lograr objetivos estratégicos. Los componentes del portafolio, como los programas y proyectos, son cuantificables. Además, estos pueden estar relacionados o no, pueden ser independientes o interdependientes y pueden tener objetivos relacionados o no relacionados. Estos componentes compiten por una parte o la totalidad de un conjunto de recursos limitados. En la Ilustración 4 se puede observar la relación que existe entre Portafolios, Programas y Proyectos según The Standard for Organizational Project Management OPM (Project Management Institute, 2018b). 24 Ilustración 4. Vista de alto nivel: Portafolios, Programas y Proyectos. Adaptado de PMI (Project Management Institute, 2018b). 2.5 Interesado o Stakeholder La traducción más cercana de Stakeholder al español es de “interesado”. Un stakeholder es un individuo, grupo u organización que puede afectar, ser afectado o percibirse a sí mismo como afectado por una decisión, actividad o resultado de un proyecto, programa o portafolio (Project Management Institute, 2017). Los stakeholders pueden estar activamente involucrados en el proyecto o tener intereses que pueden ser positivo o negativamente afectados por el desempeño o finalización del proyecto. 2.6 Gobierno Corporativo y Gobierno de TI De acuerdo al marco de trabajo ISACA (ISACA, 2012) el gobierno corporativo garantiza que se evalúen las necesidades, condiciones y opciones de las partes interesadas para determinar los objetivos empresariales equilibrados y acordados que deben lograrse; establecer la dirección mediante la priorización y la toma de decisiones; y monitorear el desempeño y el cumplimiento con respecto a la dirección y los objetivos acordados. Por su parte el IT Governance Institute (IT Governance Institute, 2003) establece que el gobierno de TI es responsabilidad del Consejo de Administración y la dirección ejecutiva. Es una parte integral del gobierno corporativo y consiste en el liderazgo y las estructuras 25 y procesos organizacionales que aseguran que las TI de la organización sostiene y amplía la estrategia y los objetivos de la organización. Complementa la definición Van Grembergen (Van Grembergen & De Haes, 2018) indicando que la gobernanza de TI es la capacidad organizacional que ejerce el Directorio, la dirección ejecutiva y la gerencia de TI para controlar la formulación e implementación de la estrategia de TI y de esta manera asegurar que se fusione a la del negocio. 2.7 Indicadores de Desempeño Son herramientas que permiten definir objetivos o impactos de forma precisa y clara. Están diseñados para que, a través de un estándar definido, se pueda evaluar, estimar o demostrar el progreso o desarrollo de un proceso o resultado con respecto a las metas que se establecieron previamente (Mondragón Pérez, 2002). La definición de un indicador se establece como una relación entre las variables cuantitativas y/o cualitativas que permiten observar la situación y las tendencias de cambio generadas en el proceso observado (Beltran, 2005). Los indicadores de gestión se definen en función a los objetivos establecidos y permiten estudiar la situación actual y el plan de acción a seguir cuando los resultados realmente obtenidos no son los esperados. Una correcta definición de indicadores contempla la facilidad de medición y la garantía de que la información recopilada y comparada con los valores reales permita la toma de decisiones estratégicas ante un resultado negativo. En la implementación de una PMO, los indicadores se enfocan en el desempeño de esta, es decir en monitorear la correcta ejecución de proyectos, la eficiencia en el uso de los recursos, así como la satisfacción de los stakeholders. Para la definición de los indicadores se seguirá el siguiente proceso: • Definición, el indicador debe definirse de manera conceptual y matemática. La definición conceptual incluye la descripción del resultado que apoya el indicador. La definición matemática incluye la fórmula con la descripción de cada parámetro. • Objetivo, el indicador debe definir claramente la finalidad que persigue, así como la importancia de su utilización. 26 • Nivel de referencia, es el valor con el que se comparará el resultado obtenido por el indicador. El nivel de referencia no solo debe ser en base a un valor histórico sino también al estándar que es el mejor valor que se puede obtener. • Responsabilidad, se debe identificar a quién corresponde actuar (tomar decisiones) frente a las diferencias obtenidas entre los niveles de referencia. Se debe diferenciar entre el responsable que recopila la información y el responsable de gestionar que el indicador mejore. • Puntos de lectura e instrumentos de medición, se debe brindar las condiciones para que los puntos de lectura sean homogéneos y representativos. • Periodicidad, se debe definir el periodo en el que se realizará seguimiento a los indicadores. La periodicidad de medición y el reporte de un indicador debe guardar relación con la posibilidad de tomar acciones y producir cambios (tiempo de reacción). • Sistema de información, se debe identificar el software donde se almacena y extrae la información para ser procesada y analizada. Además, debe considerarse al sistema de información como un documento controlado en donde no sea fácil alterar el contenido. • Semaforización, se debe definir el rango de 0 a 100% que representa los estadíos del indicador. 27 Capítulo 3. Revisión de la Literatura Como parte del desarrollo de este proyecto de investigación ha sido necesario realizar una revisión sistemática de la literatura con el objetivo de determinar los marcos de trabajo más utilizados para la implementación de PMO para la gestión de proyectos tecnológicos, así como saber en qué contexto se aplican los frameworks y si son propuestas desarrolladas por los propios autores o se basan en algunos estándares conocidos o mejores prácticas (por ejemplo, PMI, PRINCE2, ISO 21500). Se buscaron estudios de investigación que estén publicados en bases de datos académicas. Esta revisión sistemática se ha realizado siguiendo el protocolo de Kitchenham (Kitchenham & Charters, 2007). En este capítulo se presentan los resultados de la revisión sobre las propuestas de marcos de trabajo para la implementación de Oficinas de Gestión de Proyectos. 3.1 Definición del proceso de Revisión Sistemática Para el proceso de Revisión Sistemática se realizan las siguientes tareas: definir las preguntas de investigación, formular la cadena de búsqueda, extraer los resultados y su posterior análisis. Como parte del trabajo de investigación, se realizó una primera ejecución del proceso de Revisión Sistemática en septiembre de 2019. Luego, se ejecutó otra vez en mayo de 2021. Esto con el fin de encontrar algunos trabajos recientes que permitan tener mayores casos que analizar. 3.2 Preguntas de investigación Para la definición de las preguntas de investigación se tomó como referencia al método PICOC (Petticrew & Roberts, 2008) cuyas iniciales significan, Population (Población), Intervention (Intervención), Comparison (Comparación), Outcome (Resultados) y Context (Contexto). En base a lo anterior, se definen las siguientes preguntas de investigación: P1: ¿Cuáles son los marcos de trabajo de PMO más utilizados? P2: ¿Cuáles son los criterios más importantes para implementar PMO? P3: ¿En qué contextos se están aplicando los marcos de PMO? P4: ¿En qué tipo de organizaciones se están aplicando los marcos de trabajo de PMO? 28 Para ejecutar esta revisión se definen conceptos generales basados en PICOC. Como este trabajo no comparará intervenciones, no se consideró el criterio de "comparación". Los conceptos se detallan en la Tabla 1. Tabla 1. Definición de los conceptos generales utilizando PICOC Criterio Descripción Población Proyectos de desarrollo de software, Proyectos de tecnologías de información Intervención Marco de trabajo, metodología, pautas para Oficina de gestión de proyectos Salida Estudios de casos donde se definen marcos para implementar PMO para administrar proyectos de TI Contexto Industria del software, contexto académico y todo tipo de estudios empíricos 3.3 Estrategia de búsqueda En base al cuadro PICOC anterior, se colocan las palabras descriptivas y palabras claves por cada criterio. Estas palabras se escriben en inglés de modo que se obtengan más estudios en las bases de datos académicas. El detalle se puede visualizar en la Tabla 2. Tabla 2. Términos de búsqueda Criterio Palabras descriptivas Palabras claves Population Software projects, Information technology projects IT projects, Information technology Project, software project, software development project Intervention Project management office framework, methodology or guideline Project management office, PMO, Project support office, PSO Outcomes Cases studies where frameworks are defined to implement PMO to manage IT projects Methodology, method, framework, guidelines, principles, implement 29 La siguiente cadena de búsqueda se define para validar si hay evidencia de marcos para implementar PMO: ("IT project*" OR "Information technology project*" OR "software project*" OR "software development project*") AND ("Project management office" OR "PMO" OR "Project Support Office" OR "PSO") AND ("Methodology" OR "Method" OR "Framework" OR "Guidelines" OR "Principles" OR "Implement*") Como parte del proceso, se consideran los siguientes criterios de exclusión para la búsqueda: • Artículos que no son revisados por pares. • Artículos de conferencias que no han sido publicados en una revista. • Artículos que no están escritos en inglés. • Artículos que ya han sido tomados en cuenta en otra base de datos. 3.4 Proceso de búsqueda y selección La cadena de búsqueda se adaptó para ser usada en las siguientes bases de datos académicas: Scopus, IEEEXplore, Web of Science. Los estudios recuperados de la búsqueda se examinaron para determinar si incluyen o no en el presente trabajo. El proceso de evaluación incluyó una revisión de todo el documento: título, resumen, introducción, antecedentes, caso de estudio, resultados y conclusiones. Para que el estudio sea considerado dentro de este trabajo, debe cumplir con los criterios de inclusión: debe reportar la definición de marcos de trabajo para la implementación de PMO. Por otro lado, los criterios de exclusión que se han considerado son: que los estudios no se apliquen a PMO y que el estudio no esté disponible. Luego de obtener todos los estudios, se elabora una plantilla con la siguiente información: • Identificación de trabajo • Título del trabajo • Autor (es) • Tipo de publicación 30 • Año de publicación • Fecha de extracción • Base de datos en la que se encontró el estudio Las búsquedas se realizaron en dos momentos diferentes. La primera búsqueda de estudios se realizó en septiembre de 2019 y la segunda en mayo de 2021. Para la selección de los trabajos a revisar se adaptó el Diagrama de Flujo PRISMA 2009 (Liberati et al., 2009). La Ilustración 5 muestra el diagrama de flujo adaptado de la propuesta PRISMA detallando el proceso realizado. Ilustración 5. Diagrama de flujo del proceso PRISMA. Adaptado (Liberati et al., 2009). En la fase de Identificación, tras aplicar la cadena de búsqueda se obtuvieron 289 artículos la primera vez y 262 la segunda vez. En la primera búsqueda se encontraron 31 11 artículos mientras que en la segunda se encontraron 19 artículos. En ambos momentos, se examinaron los artículos y se excluyeron los artículos por las siguientes razones: no estaban en inglés, no eran accesibles y su contenido no tenía nada que ver con la implementación de PMO. Los artículos restantes se revisaron en detalle. De estos, fueron excluidos los artículos porque no proporcionan información para la implementación de PMO. De la primera revisión se obtuvieron 32 trabajos y de la segunda revisión se obtuvieron 36 artículos. La diferencia corresponde a 4 trabajos adicionales. En la Tabla 3 se muestra el resumen de los resultados de la investigación. Tabla 3. Resumen de los resultados de las búsquedas Base de datos Resultado de búsqueda Artículos duplicados Artículos relevantes Scopus 63 - 13 IEEEXplore 245 10 23 Web of Science 7 2 - Total 289 11 36 Adicionalmente, se presenta una lista completa con los artículos seleccionados enumerados con un identificador para su posterior uso, además de mostrar el autor y año del estudio. Este listado se puede revisar en la Tabla 4. Tabla 4. Listado de todos los artículos seleccionados ID Título Autores Año S1 A conceptual framework of the alignment of the Project Management Office (PMO) with the organizational structure Ayyagari, Henry, & Purvis 2006 S2 A Framework for Increasing Project Maturity and Capability in Southern Africa A. Malan et al. 2007 S3 Aligning strategies: organizational, project, individual [IT governance] Hefner 2003 32 ID Título Autores Año S4 An investigation of the role of communication in IT projects de Carvalho 2014 S5 Business evaluation of information communication technology projects in Southern Africa: The case study of Lesotho Revenue Authority Ogembo- Kachieng’A et al. 2013 S6 Chief information officers' perceptions of it projects success factors in Saudi Arabian public organizations: An exploratory study AlMajed & Mayhew 2013 S7 Compliance analysis of IT investment governance practices to Val IT 2.0 framework in Indonesian commercial bank: The XYZ Bank case study Kumaralalita et al. 2011 S8 Critical success factors for project management office: An insight from Indonesia Raharjo et al. 2018 S9 Designing an organization structure for large and complex IT programs using the Viable System Model (VSM) Kummamuru & Hussaini 2015 S10 Establishing the Agile PMO: Managing variability across Projects and Portfolios Tengshe & Noble 2007 S11 Exploring the project management office (PMO)-role structure and processes Philbin 2016 S12 Great project management=IT success. Kropf & Scalzi 2008 S13 Impact of RACI on Delivery and Outcome of Software Development Projects Khan & Quraishi 2014 33 ID Título Autores Año S14 Information Technologies for Providing Project-Process Management in Law Enforcement Structures Dronyuk et al. 2018 S15 Information technology project risk management: Bridging the gap between research and practice Taylor et al. 2012 S16 InnoDiff: A project-based model for successful IT innovation diffusion Altuwaijri & Khorsheed 2012 S17 IS Project Management: Size, Complexity, Practices and the Project Management Office Martin et al. 2005 S18 Issues for IT Governance in a Large Not-for-Profit Organization: A Case Study Wilkin & Riddett 2008 S19 Managing Structure-Related Software Project Risk: A New Role for Project Governance Bannerman 2010 S20 Managing the implementation of banking systems for repeatable success Andre Malan et al. 2008 S21 Personality and Project Success: Insights from a Large- Scale Study with Professionals Xia, Lo, Bao, Sharma, & Li 2017 S22 Project Knowledge Management Organizational Design and Success Factors - An Empirical Study in Germany Frey, Lindner, Müller, & Wald 2009 S23 Projects management office: A case study for best practices Abdi & Kaddoura 2011 S24 Setting a Research Agenda for IT Project Management Offices McKay et al. 2013 S25 Shaping of Innovative is Projects through Change Requests: Scoping Factors and Project Outcomes Nehme & Srivastava 2016 34 ID Título Autores Año S26 Strategic Alignment and Project Management Offices: Case Studies from Successful Implementations in Turkey Karayaz & Gungor 2013 S27 Success factors for creating a PMO aligned with the objectives and organizational strategy Carrillo V et al. 2010 S28 Supporting Scaling Agile with Portfolio Management: Case Paf.com Rautiainen et al. 2011 S29 The Application of Project Portfolio Management in the Government Investment Projects Yu, Wang, & Guo 2008 S30 The Contingent Effects on Project Performance of Conducting Project Reviews and Deploying Project Management Offices Liu & Yetton 2007 S31 The Effect of Project Management Capabilities on Project Success in Pakistan: An Empirical Investigation Irfan, Hassan, & Hassan 2019 S32 Transforming Practice Using Theoretical Framing to Improve Organizational Processes Eschler, Palkar, & Taylor 2014 S33 A new model for successful CPOE deployment and implementation in hospitals Altuwaijri 2008 S34 How to reduce risk effectively in fixed price software development Gruhn & Von Brisinski 2020 S35 Identifying and overcoming the challenges of implementing a project management office Singh et al. 2009 S36 IT benefits management in financial institutions: Practices and barriers Terlizzi et al. 2017 35 3.5 Análisis y reporte de resultados Para determinar cuáles son los marcos de trabajo más utilizados para implementar PMO, se han identificado aquellos definidos por las organizaciones o por los autores de los mismos estudios. En la Tabla 5 se pueden ver los resultados. De los trabajos revisados, se observa que una gran cantidad de ellos (75%) no definen un marco de trabajo completo para la implementación de una PMO. Sin embargo, se considera la revisión de estos trabajos porque brindan criterios y recomendaciones importantes a tener en cuenta a la hora de decidir implementar una PMO. Solo el 8% de las obras definen su propio marco. Del resto de obras, el 14% se definen en base al PMI y solo el 3% en base a PRINCE2. Tabla 5. Frecuencia de uso de los marcos de trabajos para PMO Marco de trabajo Frecuencia de uso Porcentaje Definidos por los propios autores 3 8% Basados en PMI 5 14% Basados en PRINCE2 1 3% No definidos completamente 27 75% TOTAL 36 100% De acuerdo con diferentes estudios revisados, como sugiere McKay (McKay et al., 2013), se deben tener en cuenta diferentes factores a la hora de implementar una PMO: saber diseñarla, planificar los recursos que utilizará, el nivel de habilidades de liderazgo que requerirá de sus miembros, la definición de métricas y el nivel de gobierno requerido. 3.5.1 Estructura de la PMO En el caso de los proyectos de TI, Abdi (Abdi & Kaddoura, 2011) propone en su estudio que la estructura de la PMO puede constar de cinco departamentos/secciones principales encabezados por el director de la PMO. La definición de esta estructura está asociada a los tipos de proyectos de TI que ejecuta la PMO. Estos departamentos son responsables de iniciar, planificar y ejecutar todo tipo de proyectos de TI. Dentro de cada 36 sección, un grupo de directores de proyectos gestionará su propia cartera de proyectos. La estructura propuesta se puede ver en la Ilustración 6. El trabajo de Ayyagari (Ayyagari et al., 2006) identifica tres tipos de PMO: Básica, Estándar y Avanzada. Esta clasificación se diferencia entre sí por sus funciones, el conocimiento, el nivel de control, la gestión de los recursos. Por otro lado, Philbin (Philbin, 2016) en su trabajo identifica los siguientes tipos de PMO: Apoyo, Control y Directivo. Esta categorización se centra en el nivel de control y los roles que cumple. Después de revisar ambos tipos de clasificación, se han encontrado similitudes entre ellos. La Tabla 6 muestra las características de cada tipología y sus similitudes. Tabla 6. Comparación de estructuras de PMO S1 S11 PMO Básica Pueden existir varias PMO básicas en una organización. Proporciona plantillas, documentación, etc. específicas para las unidades funcionales. Los gerentes de proyecto generalmente reportan a las unidades funcionales. Las necesidades de formación son ad hoc en esta estructura y puede que no haya formación formal. Asume el rol de implementador. Los recursos son propiedad de las unidades funcionales, no de la PMO. Es básicamente un repositorio de conocimientos. Proporciona función consultiva para los proyectos a través del suministro de plantillas, mejores prácticas de gestión de proyectos, capacitación, acceso a la información y lecciones aprendidas de otros proyectos. El grado de control es bajo. PMO de Apoyo Gerente de PMO Proyectos de Aplicaciones TI Proyectos de Infaestructura y Sistemas de TI Proyectos de aplicaciones web de TI Proyectos de redes de TI Proyectos de Seguridad de TI Ilustración 6. Propuesta de estructura de PMO. Elaboración propia. 37 PMO Estándar Representa la existencia de una PMO a nivel corporativo, pero con menos responsabilidades. Proporciona orientación con respecto al "conocimiento" sobre metodologías estándar corporativas, plantillas, etc. Ejecutor de metodología y herramientas corporativas. Gerentes de proyectos informan a la PMO y las unidades funcionales. Propiedad limitada de recursos (propiedad compartida de recursos con unidades funcionales). Brinda apoyo y requiere el cumplimiento de los proyectos a través de varios medios, como mediante la adopción de estándares de gestión de proyectos, utilizando plantillas o formularios específicos o mediante el cumplimiento de ciertos acuerdos de gobernanza. El grado de control proporcionado es moderado. PMO de Control PMO Avanzada Centraliza todas las actividades de gestión de proyectos a nivel corporativo. Proporciona plantillas, documentación, mejores prácticas, lecciones aprendidas, etc. de una manera altamente integrada. Asume el rol de implementador de la estrategia organizacional. Convierte la estrategia organizacional en acciones de manera más eficiente. Todos los gastos relacionados con el proyecto (costos técnicos y humanos) son aprobados por la PMO. Tiene control directo de los proyectos a través de la prestación de servicios de gestión de proyectos para permitir la entrega de los proyectos. El grado de control proporcionado es alto. PMO Directiva Otra propuesta de estructura muy similar pero con otros nombres, es definida por Singh (Singh et al., 2009). Singh propone una PMO-light que sería muy parecida a una PMO Básica por sus características y también propone una PMO-heavy, cuyo rol es mucho más proactivo en la gestión de proyectos. Este tipo de PMO se ajusta más a la PMO Avanzada. 3.5.2 Funciones de la PMO La mayoría de los trabajos de investigación revisados en esta revisión sistemática, proponen diferentes tipos de funciones que una PMO debe realizar. Es importante mencionar que en los distintos estudios a las funciones de la PMO también se les llama tareas, propósitos, objetivos y rol que cumple en la organización. En la Tabla 7 se muestran las funciones divididas según la propuesta de Ayyagari (Ayyagari et al., 2006), quien además es el que más funciones identifica, por eso se toma como base para 38 Tabla 7. Funciones de la PMO Funciones Estudios relacionados Conocimiento Identificar o desarrollar una metodología de gestión de proyectos, mejores prácticas y estándares. [S1], [S13], [S14], [S15], [S16], [S17], [S18], [S30], [S31] Gestionar documentación compartida, incluidas políticas, procedimientos, plantillas, listas de verificación, etc. [S1], [S3], [S9], [S10], [S11], [S13], [S17], [S36] Impartir formación sobre metodología de gestión de proyectos, uso correcto de plantillas y procedimientos operativos. [S1], [S2], [S3], [S9], [S10], [S11], [S14], [S17], [S18], [S30], [S31], [S33], [S36] Hacer cumplir los estándares y métodos para aprovechar las mejores prácticas y garantizar que todos los miembros de la organización estén usando el mismo léxico. [S1], [S6], [S9], [S33] Intercambiar conocimientos y experiencia profesional entre gerentes de proyectos (por ejemplo, tutorías). [S1], [S2], [S4], [S10], [S33] Analizar, integrar y difundir lecciones aprendidas. [S1], [S4], [S16] Dirigir gerentes de proyectos y equipos de proyectos a expertos en conocimiento dentro y fuera de la empresa. [S1] Centralizar el funcionamiento y gestión de herramientas de proyectos, incluido el software de gestión de proyectos para toda la empresa. [S1], [S3], [S11], [S17] Analizar, integrar y difundir los riesgos identificados, así como las estrategias de mitigación y eliminación. [S1], [S11], [S15] Proporcionar estándares y regulaciones para la planificación, garantía y control de la calidad. [S1], [S11] Centralizar, coordinar y gestionar la comunicación entre proyectos. [S1], [S4], [S13] Control Centralizar la gestión de la configuración para todos los proyectos administrados por la PMO. [S1] Centralizar y analizar riesgos compartidos y únicos para todos los proyectos. [S1], [S15] Centralizar la información del estado del proyecto para la organización. [S1], [S15], [S21], [S25], [S34] Hacer cumplir estándares y métodos: desarrollo de propuestas, gestión de cambios, evaluación de riesgos. [S1], [S15], [S25], [S30] 39 Establecer y hacer cumplir estándares claros de medición del desempeño para juzgar el éxito de los proyectos. [S1], [S4], [S10], [S11], [S16], [S17], [S18], [S21] Realizar auditorías sobre el éxito de los proyectos, la eficacia de la gestión de proyectos, el valor y uso de la metodología y las herramientas, y el cumplimiento de los estándares y requisitos internos y externos. [S1], [S4] Proporcionar servicios de evaluación posterior para proyectos según sea necesario. [S1], [S11], [S16], [S21] Ofrecer total responsabilidad para la gestión de proyectos. [S1], [S16] Monitorear y controlar cronogramas y presupuestos de proyectos de PMO, generalmente a nivel empresarial [S1], [S9], [S11], [S13], [S14], [S17], [S18], [S30], [S34], [S36] Recursos Compartir y coordinar recursos en todos los proyectos administrados por la PMO. [S1], [S6], [S11] Evaluar y seleccionar conjuntos de herramientas (de programación, repositorios de conocimiento, software de gestión de portafolio y recursos). [S1], [S3], [S11] Gestionar las habilidades, la asignación y la capacidad de los recursos y optimizar la productividad. [S1], [S9], [S18] Identificar al gerente del proyecto, contratar al personal del proyecto fuera de la organización. [S1], [S36] Evaluar a todo el personal del proyecto. [S1] Alojar a todos los gerentes de proyectos con responsabilidad de pérdidas y ganancias de los proyectos que gestionan. [S1] Presupuestar y rastrear el capital del proyecto y los gastos operativos. [S1] Responsabilidad financiera total: anotar horas-hombre utilizadas con las estimadas, autorizar compras y gastos asociados, facturar, ejecutar medidas de control de costos, informes financieros. [S1], [S36] Ofrecer administración de recursos humanos completa definiendo el plan de estudios de capacitación en gestión de proyectos, ofreciendo planificación y progresión de carrera. [S1] 40 compararlo con estudios de los demás de autores. Estas tareas se clasifican en roles asociados con el conocimiento, el control y los recursos dentro de la organización. 3.5.3 Gobierno en la PMO Como se indica en la investigación de Malan (Andre Malan et al., 2008), la creación de la estructura de gobierno correcta en un entorno de proyectos múltiples es muy importante. Como también es fundamental asegurar la comunicación a través de la PMO y comprender los demás portafolios de proyectos de la organización. Para este fin sugiere crear un canal de comunicación transversal a los proyectos con el fin de maximizar las oportunidades y gestionar adecuadamente las dependencias que puedan existir. En los trabajos de Ayyagari (Ayyagari et al., 2006) y Wilkin (Wilkin & Riddett, 2008), se identifican 3 modos de gobierno de TI. Esta clasificación se basa en el nivel de autoridad en la toma de decisiones. La Tabla 8 muestra los modos de gobierno de TI y la posible estructura de PMO en la que se puede aplicar. Tabla 8. Modos de Gobierno de TI Modo de Gobierno TI Descripción Estructura de PMO Descentralizada La autoridad de toma de decisiones para todas las actividades de TI recae en las gerencias de unidades funcionales. Básica Federal Equilibrio en la autoridad para la toma de decisiones entre las unidades funcionales y el nivel corporativo Básica a Estándar Centralizada La autoridad de toma de decisiones para todas las actividades de TI recae en el nivel corporativo Básica a Avanzada Por otro lado, luego de revisar los trabajos de investigación, se identificaron las siguientes estrategias de gobierno que debe seguir una PMO. Estas estrategias se clasificaron según el impacto que puedan tener en la organización y en la misma PMO. El detalle de esta clasificación se puede ver en la Tabla 9. 41 Tabla 9. Estrategias de Gobierno Característica Estrategias de Gobierno Estudios relacionados Políticas Cuando se desarrollan políticas, se debe buscar la retroalimentación del gerente de proyecto. Las buenas políticas son un compromiso entre la coherencia en aras de la eficiencia organizativa y la flexibilidad para la adaptabilidad a diferentes entornos y limitaciones de proyectos. Debe existir un sistema de exenciones para reconocer cuando una política no es apropiada para una situación específica del proyecto. Las exenciones deben usarse con moderación y requieren una justificación rigurosa. [S3] Liderazgo Se debe preservar la autoridad de la gestión de proyectos, pero debe equilibrarse con la autoridad de la organización. Es inapropiado que un proyecto tome decisiones a corto plazo que tengan impactos perjudiciales a largo plazo en los objetivos, la cultura o la reputación de la organización. [S3] Recursos La organización debe establecer pautas claras con respecto a la disponibilidad de recursos para actividades específicas del proyecto. Es posible que la organización necesite proporcionar fondos para ayudar al proyecto a alinear sus objetivos con los de la organización, como realizar actividades para las que el proyecto obtiene poco valor a corto plazo. Los proyectos deben comunicar a los clientes que la organización requiere actividades esenciales y deben considerarse un "costo de hacer negocios", incluso si el cliente no ve el valor. [S3], [S11], [S12], [S19], [S28] 42 Característica Estrategias de Gobierno Estudios relacionados Estructuras Organizaciona- les Las estructuras organizativas pueden ayudar a proporcionar recursos y equilibrar las metas a corto y largo plazo. [S3] Formación La organización es responsable de garantizar personal de trabajo capacitado y con conocimientos. La organización debe establecer estándares mínimos para cada función laboral y capacitación para brindar estas habilidades a quienes no las posean. Los proyectos deben compensar esta capacitación en sus cronogramas y deben centrarse en la capacitación específica del proyecto. [S3], [S11], [S19], [S33] Mediciones La organización debería establecer medidas comunes para ser utilizadas en todos los proyectos; los proyectos deben agregarse a estos según sea necesario. Las métricas comunes deben mantenerse históricamente de proyectos anteriores para ayudar en la planificación de proyectos y la estimación de recursos. [S3], [S19] Revisiones de Gestión Las revisiones por la dirección deben enfatizar el equilibrio de autoridad entre organizaciones y proyectos. La organización debe revisar periódicamente los procesos y el progreso del proyecto para asegurarse de que se cumplan las metas. [S3], [S11], [S18], [S19], [S29] 43 Característica Estrategias de Gobierno Estudios relacionados Auditorías Las auditorías son una forma eficaz de garantizar el cumplimiento del proyecto con las políticas y objetivos de la organización. Se debe tener cuidado de establecer una fuerte supervisión organizacional de los programas de auditoría de los proyectos, para asegurar que el programa sea adecuado. [S3], [S11] Apoyo de la Gerencia La PMO también puede recopilar información sobre el portafolio de recursos y proyectos de TI en la organización, lo que ayuda a la alta dirección a priorizar proyectos. [S12], [S18], [S19], [S26], [S28], [S34], [S36] Alineamiento Estratégico La PMO juega un papel importante en la adecuación entre los proyectos propuestos por los departamentos y la visión y estrategias de la organización. En caso de que haya una coincidencia, se toma la decisión de invertir en la solución propuesta. Si no hay coincidencia, la PMO debe actualizar la base de conocimientos de la organización y explicar las razones. [S16], [S18], [S19], [S26], [S28], [S29], [S33] 3.5.4 Roles y Responsabilidades en la PMO En los trabajos de investigación revisados se encontraron un par de propuestas de roles y responsabilidades en la PMO, estas fueron desarrolladas por los autores Philbin (Philbin, 2016) y Carrillo (Carrillo V et al., 2010), de definiciones de roles y responsabilidades. Por otro lado, Kummamuru (Kummamuru & Hussaini, 2016) y Taylor (Taylor et al., 2012) también definen otros roles en la PMO con sus respectivas responsabilidades. Todas esas propuestas se han resumido en la Tabla 10. Por su parte, Eschler (Eschler et al., 2014) propone una estructura organizacional para la PMO dentro de una organización de TI, la cual se puede observar en la Ilustración 7. 44 Tabla 10. Roles y Responsabilidades en la PMO Roles Responsabilidades S11 S27 S9 S15 Coordinación PMO Administrar la PMO X X Presentar informes de progreso X X X Coordinar la PMO X X Miembro del Comité de Proyectos X X Oficial Gestión de Programas Planificar la gestión de proyectos X Establecer metas de los proyectos X Gestión de herramientas Administrar la herramienta de gestión de proyectos empresariales y los documentos X X Desarrollar y mejorar herramientas X X Administrar herramientas de seguimiento y envíos de Reportes de Proyectos X Gestión de recursos Administrar recursos X X Asignar recursos y realizar seguimiento X X X Realizar seguimiento de actividades y cronogramas de resultados X X X Gestión de seguimiento Gestionar métricas para medir la salud y el avance de los proyectos X X X Seguimiento de riesgos y problemas globales X X X Seguimiento de presupuestos X X X Redactar informe de progreso de proyectos X X X 45 Roles Responsabilidades S11 S27 S9 S15 Gestión de Mentoría Socializar el proceso de gestión de proyectos X X Crear políticas y procesos para proyectos X X Planificar la formación y enseñanza en la gestión de planes y plantillas de proyectos X X Mejorar los planes y plantillas organizacionales establecidos X X Implementar nuevos planes con el objetivo de incrementar madurez de gestión de proyectos X X Oficial del Programa I+D Escanear el entorno en busca de posibles cambios en el negocio X Investigar mejores y nuevas tecnologías X Patrocinador del Programa / Director del Programa Ejecutar el programa para la entrega de beneficios X Director de Tecnología (CTO) Liderar la PMO y ser el responsable, con cada unidad funcional, del éxito de sus proyectos de TI. X X Fomentar la colaboración y cooperación entre las unidades funcionales y la Oficina del CTO para visibilizar y supervisar los proyectos. X X 46 3.5.5 Indicadores de desempeño en la PMO Antes de la implementación de la PMO, se deben conocer las medidas de línea base del desempeño del proyecto. De lo contrario, será muy difícil demostrar el valor de la PMO en la organización (McKay et al., 2013). La revisión de métricas estaría a cargo de la oficina de Gestión de Proyectos y cubriría todo, desde el cumplimiento de la Metodología de Gestión de Proyectos de la organización, hasta la eficiencia general del proyecto en términos de la triple restricción de los proyectos, y también en términos de si el valor anticipado había sido o no. entregado (Ogembo-Kachieng’A et al., 2013). La recomendación es que la PMO mida los beneficios obtenidos por los proyectos y que estos estén alineados con los objetivos estratégicos de la organización (Altuwaijri & Khorsheed, 2012). Tanto Gruhn (Gruhn & Von Brisinski, 2020) como Singh (Singh et al., 2009), coinciden que deben definirse métricas que evalúen el impacto de la PMO en la ejecución y resultados de los proyectos. Ambos sugieren medir costo, tiempo, expectativas (en términos que se logren satisfacer los requerimientos del cliente), calidad de entregables, beneficio económico esperado. Otro punto importante es definir la frecuencia de la medición de los indicadores de la PMO. Una medición continua y frecuente de la productividad y el nivel de servicio de la PMO asegurará el éxito de la PMO además de facilitar ajustes en el proceso si es necesario (Abdi & Kaddoura, 2011). Una propuesta de frecuencia se encuentra en el trabajo de Kumaralalita (Kumaralalita et al., 2011), que sugiere evaluar el desempeño Oficina de Gestión de Proyectos Gestión de Programas Gestión de Proyectos Project Management Gestión de Proyectos Ilustración 7. Estructura organizacional en la PMO. Elaboración propia 47 semanalmente. Esta frecuencia facilitará el control de las desviaciones y elevará los incidentes al Comité de TI o al Directorio. En el trabajo de Raharjo (Raharjo et al., 2018), se lleva a cabo una revisión de la literatura y se identifican los siguientes criterios de éxito de PMO (también conocidos como PMO Key Performance Indicator, PMO Metrics o PMO Measurement) como se muestra en la Tabla 11. Tabla 11. Principales criterios de éxito de una PMO N° Criterios de éxito de la PMO 1 Éxito del proyecto 2 Alineamiento con los objetivos comerciales de la organización. 3 Satisfacción de las partes interesadas 4 Crecimiento y rendimiento de la PMO 5 Estabilidad y control de proceso 6 Calidad de resultados de proyectos Se entiende como criterio de éxito a los indicadores que medirán si el proyecto cumple con los objetivos para los que fue planteado. Estos criterios se miden luego de implementar la PMO. Adicionalmente, Raharjo (Raharjo et al., 2018) establece que para obtener los mejores resultados de las métricas de la PMO, se deben considerar los factores de éxito. Es decir, que si se consiguen los factores de éxito se pueden lograr las mediciones deseadas en los criterios de éxito de la PMO. En la Tabla 12 se listan los factores críticos de éxito. A modo de resumen, se presenta la Tabla 13 donde se puede observar que las propuestas que son definidas por los mismos autores son las que presentan todos los criterios para implementar la PMO. Seguido de los trabajos que proponen criterios de implementación basados en recomendaciones de los estándares del PMI. Los trabajos basados en PRINCE2 solo presentaban tareas que la PMO debería realizar una vez implementadas. No se obtuvo trabajo alguno basado en ISO 21500. Es importante 48 mencionar que ninguno de los trabajos presentó un marco de trabajo completo para la implementación de una PMO. Tabla 12. Factores de éxito de la PMO N° Factores de éxito de la PMO 1 Apoyo de la alta dirección y las partes interesadas. 2 Tener una visión, misión, hoja de ruta, proceso estándar, rol y responsabilidad, así como una estructura organizacional clara. 3 La calidad del liderazgo de la organización que tiene la competencia de PMO. 4 El equipo de recursos de la PMO que tiene el conocimiento y las habilidades, incluida la capacidad de proporcionar valor agregado a la organización. Tabla 13. Resumen de criterios para implementar una PMO Estudios basados en Criterio de implementación PMI PRINCE2 Definido por autores Define un marco de trabajo para la implementación No No Sí Define estructura de la PMO Sí No Sí Define funciones de la PMO Sí Sí Sí Define gobierno en la PMO Sí No Sí Define roles y responsabilidades en la PMO Sí No Sí Define indicadores de desempeño de la PMO Sí No Sí 49 3.5.6 Resultados por dominio de software (contexto) De los estudios revisados se observa que la mayoría de ellos fueron aplicados o desarrollados tomando proyectos de Servicios de TI y seguidos de cerca por proyectos en cualquier tipo de industria. Casi el 17% de las obras restantes se aplicaron en entornos bancarios / financieros. Otro grupo de trabajos se aplicaron en entornos de asistencia sanitaria. Finalmente, las obras restantes se aplicaron en el contexto del sector de defensa, construcción, comercio minorista, educación y videojuegos. El detalle se puede apreciar en la Tabla 14. Tabla 14. Estudios encontrados por dominio de software Dominio de Software Número de estudios Porcentaje Servicios de TI 9 25% Cualquier tipo de industria 8 22% Banca / Finanzas 6 17% Gobierno 4 11% Asistencia Sanitaria 4 11% Sector Defensa 1 3% Construcción 1 3% Comercio minorista 1 3% Educación 1 3% Videojuegos 1 3% TOTAL 36 100% 50 3.5.7 Resultados por tipo de Organización De los estudios revisados se observa que la gran mayoría (53%) se ha propuesto aplicarlos en grandes organizaciones. El 39% de los trabajos restantes se aplicaron en cualquier tipo de organización. Se observa que el 6% de trabajos se aplicaron en organizaciones de tamaño medio y finalmente el 3% se aplicó en una gran organización sin fines de lucro. El detalle se puede apreciar en la Tabla 15. Tabla 15. Estudios encontrados por tipo de organización Tipo de Organización Número de estudios Porcentaje Cualquier tipo 14 39% Mediana organización 2 6% Gran organización 19 53% Gran organización sin fines de lucro 1 3% TOTAL 36 100% 3.6 Conclusiones Luego de culminar con la revisión sistemática sobre los marcos de trabajo más usados para la implementación de PMO, se puede concluir lo siguiente: No existe un marco de trabajo que sea ampliamente utilizado. En la literatura se evidenciaron muy pocos casos de propuestas de marcos de trabajo para la implementación de una PMO. Muchos de los artículos revisados mostraban criterios críticos para su implementación, pero pocos artículos los integraban en un marco de trabajo que facilite el despliegue de una PMO. Adicionalmente, no existe evidencia significativa en la literatura que algún estándar o mejores prácticas (por ejemplo: PMI, PRINCE2, ISO 21500) que tenga mayores casos de aplicación. Muchos de los estudios revisados muestran que los mismos autores proponen un marco de trabajo o al menos brindan recomendaciones de los puntos a tomar en cuenta al momento de implementar una PMO. El contexto o dominio donde más se aplican los estudios encontrados son en organizaciones que ofrecen Servicios de TI, seguido por los estudios que presentan 51 recomendaciones para cualquier tipo de industria, en tercer lugar, se aplican en Banca o Finanzas y en cuarto lugar en el Gobierno. Los demás estudios se aplican en otros tipos de contextos, pero su frecuencia es mínima. Los estudios revisados se aplicaron mayoritariamente en grandes organizaciones y en segundo lugar otro bloque de estudios que se aplicaron en cualquier tipo de organización. Los distintos estudios revisados consideran que para una exitosa implementación de una PMO se deben considerar mínimamente: una correcta estructura organizativa, funciones, niveles de gobierno en la organización, roles y responsabilidades, indicadores de desempeño. No se ha encontrado evidencia en la literatura otros criterios de implementación identificados en el Marco Conceptual del presente trabajo, como los definidos por los autores Wysock (Wysocki, 2011) y Kerzner (Kerzner, 2017). En conclusión, el autor considera que el presente trabajo de tesis podría aportar con la definición de un marco de trabajo integral que, tomando las recomendaciones encontradas en la literatura y la propuesta de otros autores, facilite la implementación de una PMO para la gestión de proyectos de TI y que cumpla con sus objetivos trazados. 52 Capítulo 4. Metodología de la investigación En este capítulo se presenta la metodología de investigación, que para el presente trabajo se basará en un enfoque mixto de investigación. A continuación, se describirá la visión general de la investigación y su objetivo. También se detalla cada fase y los instrumentos que se utilizarán para lograr los resultados de la investigación y realizar el análisis correspondiente con el fin de validar las propuestas desarrolladas. 4.1 Visión general El presente trabajo de tesis se guía por la siguiente pregunta de investigación: ¿Cuál es el impacto de implementar una PMO para la ejecución de proyectos de TI en una organización? Para lograr este fin, se sigue un diseño de investigación mixto, esto quiere decir que contempla el proceso de recolección, análisis y vinculación de datos cuantitativos y cualitativos con el fin de responder a un planteamiento del problema (Hernández- Sampieri et al., 2014). Con el enfoque cuantitativo se busca la generalización de los resultados que se obtienen al realizar diseño experimental para probar las hipótesis. Para este fin, se inicia con un análisis exhaustivo de las propuestas de marcos de trabajo para la implementación de Oficinas de gestión de proyectos en el contexto de proyectos de TI encontradas en la literatura para que en base a ellas se elabore la propuesta del marco de trabajo. Se evalúan los resultados estadísticamente en términos de costo y tiempo. Con el enfoque cualitativo se busca que un grupo de expertos puedan evaluar la propuesta de implementación de una PMO tomando en cuenta criterios identificados de la literatura y propuestos por el autor de la tesis. 4.2 Descripción de la población A continuación, se describe el contexto de aplicación de la propuesta de implementación de la PMO. Para el presente trabajo de investigación se toma como base a una organización (considerada gran empresa por su facturación) que gestiona sus propios proyectos de TI. Se recolecta información de los proyectos de TI que ejecuta, tomando los sobretiempos y sobrecostos incurridos por cada proyecto en dos momentos diferentes: antes y después de implementar la PMO (siguiendo la primera propuesta planteada en este trabajo). Esta información permitirá hacer el análisis cuantitativo. 53 Para el análisis cualitativo, se busca a un grupo de expertos en la gestión de proyectos para entrevistarlos y contar con sus apreciaciones respecto a la propuesta de implementación de la PMO. 4.3 Fases y procedimientos Como se mencionó previamente, el presente trabajo sigue un estudio mixto, evaluando los resultados primero de forma cuantitativa y luego de forma cualitativa. En la tabla siguiente se presenta el resumen de la metodología seguida en el presente trabajo de investigación. Tabla 16. Fases de la metodología aplicada Nro Fase Procedimientos Resultados I Diseño de Marco de Trabajo Análisis exhaustivo de evidencias de la literatura Diseño del marco de trabajo Primera propuesta del marco de trabajo II Validación Cuantitativa Definición de hipótesis Análisis comparativo de resultados Recolección de datos Análisis de normalidad Prueba de hipótesis Análisis de datos III Diseño de Marco de Trabajo Diseño del marco de trabajo Segunda propuesta del marco de trabajo IV Validación Cualitativa Validación de cuestionario de entrevista Análisis comparativo de resultados Invitación a expertos Coordinación para entrevistas Recolección y análisis de datos 54 A continuación, se detallan las fases para la ejecución del presente proyecto de investigación: Fase I: Diseño de marco de trabajo – Parte 1 Sobre la base de los estudios y autores que fueron revisados exhaustivamente, aplicando la herramienta PRISMA, en el proceso de revisión sistemática de la literatura, se propone la primera parte del marco de trabajo para la implementación de la PMO. De cada trabajo revisado se toman en cuenta todos los criterios críticos que allí se describen y que son necesarios para la implementación de la PMO. Fase II: Validación Cuantitativa El marco de trabajo propuesto en la fase anterior se implementa y luego se definen y miden las métricas de sobrecostos y sobretiempos. Con los resultados se realizan las siguientes actividades: • Definición de las hipótesis • Recolección de datos • Análisis de normalidad de los datos • Prueba de hipótesis • Análisis de datos • Análisis comparativo de los resultados En esta fase se formulan las hipótesis que permitirán demostrar que la propuesta del marco de trabajo de la Oficina de Gestión de Proyectos realmente permite una mejor gestión de los proyectos, obteniendo reducción de los tiempos y costos de ejecución de proyectos. Para este fin, se necesitan validar los tiempos de ejecución de los proyectos antes y después de la implementación de la PMO. El mismo trabajo de validación se realizará para los costos. Estos dos indicadores de gestión se seleccionan porque la organización, donde se aplica el trabajo de investigación, los considera críticos dentro de la gestión de sus proyectos. A continuación, se presentan las hipótesis que permitirán evaluar las métricas y sus resultados. 55 Primera hipótesis La definición correcta de una Oficina de Gestión de Proyectos permite reducir los tiempos de demora (sobretiempos) incurridos en la entrega de los proyectos. Segunda hipótesis La definición correcta de una Oficina de Gestión de Proyectos permite reducir los costos incurridos en fallas en la gestión de proyectos (sobrecostos). Fase III: Diseño de marco de trabajo – Parte 2 Sobre la base de los estudios revisados y la experiencia de los resultados obtenidos luego de la implementación de la primera parte del diseño, se propone la definición de la segunda parte del marco de trabajo para la PMO. Para este fin se revisa nuevamente cada uno de los criterios críticos en la implementación y se añaden las mejoras en esta nueva propuesta. Fase IV: Validación Cualitativa El marco de trabajo mejorado propuesto en la fase anterior se evalúa de forma cualitativa, es decir a través de entrevistas a un grupo de expertos. Para este fin se realizaron las siguientes actividades: • Validación del cuestionario de la entrevista • Invitación a expertos • Coordinación para las entrevistas • Recolección de datos • Análisis de datos • Análisis comparativo de los resultados Adicionalmente, en esta fase se contempla la definición del protocolo de la entrevista y la definición de la población de estudio. Esta población de estudio se conforma por expertos en temas de gestión de proyectos y PMO. Luego de efectuar las coordinaciones y llevar a cabo las entrevistas, se recoge la información obtenida y en base a ella y a las sugerencias que los expertos aportan en la validación cualitativa, se incluyen algunas mejoras a la segunda propuesta presentada en este trabajo en el capítulo 7. 56 En los siguientes capítulos se mostrará el detalle de cómo se ejecutaron cada fase: • Fase I: Detallado en el Capítulo 5 • Fase II: Detallado en el Capítulo 6 • Fase III: Detallado en el Capítulo 7 • Fase IV: Detallado en el Capítulo 8 4.4 Consistencia de la metodología con los objetivos de investigación La metodología propuesta en este trabajo de investigación tiene como finalidad lograr los objetivos del proyecto y sobre todo la pregunta de investigación. En la Tabla 17 se muestran las fases relacionadas a los objetivos que apoyan. En la Fase I, gracias al análisis exhaustivo de las evidencias y trabajos encontrados en la literatura se lograron identificar los criterios críticos que deben considerarse para la implementación de la PMO. Con ello se logra el objetivo establecido: “Identificar los criterios críticos para implementar la PMO”. En la Fase II, la validación cuantitativa de los datos recopilados de los proyectos ejecutados antes y después de implementar la PMO, logro demostrar que dicha implementación si tiene un impacto positivo en la ejecución de proyectos de TI en la organización. Con ello se logra el objetivo establecido: “Identificar el impacto de la PMO en los tiempos y costos de ejecución de los proyectos”. La Fase III y la Fase IV apoyan al logra del objetivo “Definir un marco de trabajo mejorado para implementar la PMO”. Esto gracias al diseño de una propuesta mejorada del marco de trabajo que fue validado cualitativamente a través de entrevistas a expertos en la gestión de proyectos. Finalmente, como resultado de la ejecución de todas las fases, el presente trabajo de investigación presenta una versión mejorada del marco de trabajo de implementación de una PMO para la ejecución de proyectos de TI. 57 Tabla 17. Aporte de la metodología para el logro de objetivos Nro Fase Procedimientos Resultados Objetivo I Diseño de Marco de Trabajo Análisis exhaustivo de evidencias de la literatura Primera propuesta del marco de trabajo Identificar los criterios críticos para implementar la PMO Diseño del marco de trabajo II Validación Cuantitativa Definición de hipótesis Análisis comparativo de resultados Identificar el impacto de la PMO en los tiempos y costos de ejecución de los proyectos Recolección de datos Análisis de normalidad Prueba de hipótesis Análisis de datos III Diseño de Marco de Trabajo Diseño del marco de trabajo Segunda propuesta del marco de trabajo Definir un marco de trabajo mejorado para implementar la PMO IV Validación Cualitativa Validación de cuestionario de entrevista Análisis comparativo de resultados Invitación a expertos Coordinación para entrevistas Recolección y análisis de datos 58 Capítulo 5. Propuesta de implementación de una PMO – Parte I Este capítulo contiene la primera parte de los resultados concretos del trabajo y profundizará la comprensión de las fases de diseño e implementación de la PMO en la organización seleccionada. Los resultados consisten en el modelo de concepto de PMO desarrollado para la organización siguiendo el marco de trabajo propuesto. La persona que realizó la investigación actuó como Líder de la PMO durante todo el proceso de implementación. El presente capítulo describe los lineamientos encontrados tanto en estándares aceptados internacionalmente, la literatura, y la propuesta del autor. 5.1 Evaluar necesidad de PMO De acuerdo a lo recomendado por Wysocki (Wysocki, 2011), se debe tener clara la necesidad de implementar una PMO en la organización. Para ese fin se analizan los principales síntomas que se presentan en una organización y hacen evidente la necesidad de la implementación de una PMO: • Altos índices de fallas en los proyectos • Entrenamiento que no produce resultados • RRHH tiene dificultad para la definición de habilidades del personal de proyectos y para la asignación los proyectos • No se aprovechan las mejores prácticas • Falta de control del portafolio de proyectos • No se comunica consistentemente sobre la ejecución de los proyectos • Demasiados conflictos en la programación de recursos • Brecha entre proceso y práctica Luego de la identificación de la necesidad de implementar la PMO, el trabajo de concientización inicia rápidamente, por lo que se debe justificar ante el patrocinador de la PMO la necesidad de implementación con el fin de obtener su apoyo. Con el soporte del patrocinador se logra “sembrar las semillas de PMO” en el Directorio, logrando que sus miembros se entusiasmen con el tema, por lo que se decide organizar un equipo de gestión de PMO para apoyar la implementación de la PMO. 59 Este equipo tiene como misión reunirse semanalmente para continuar con el trabajo de definición de la PMO. Este equipo cuenta con el empoderamiento necesario para tomar decisiones eficaces y oportunas de modo que se busque la definición exitosa de la PMO. A continuación, se muestra en la tabla siguiente el plan de tareas que el equipo de gestión de PMO realizará: Tabla 18. Tareas para la implementación de la PMO Nro. Tarea 1 Elaboración del Plan de implementación 2 Evaluación del estado actual 3 Crear Visión y Misión 4 Crear Metas y Objetivos 5 Desarrollar Business Case 6 Definir estructura organizativa 7 Definir estructura de Gobierno y Nivel de Escalamiento 8 Definir metodología de Gestión de Proyecto 9 Definir métricas de performance y proceso de revisión 10 Desarrollar requerimientos de entrenamiento 11 Desplegar la PMO Después de la elaboración del Plan de implementación de PMO, se enfatizó fuertemente el papel que ésta cumplirá en la Organización. Adicional a ello, se contó con el apoyo del patrocinador y esto permitió que la implementación no dure años (como tradicionalmente ocurre). Además del equipo de gestión de la PMO, se seleccionaron los miembros del equipo central de la PMO y se les propone compartir información relacionada con el proyecto con las partes interesadas clave de otros departamentos. De esta forma se logra 60 compartir información valiosa a través de los límites departamentales y también resaltar lecciones aprendidas después del cierre del proyecto. En el siguiente paso se define el alcance de la PMO se define más allá de la aplicación de estándares y abarca el liderazgo y logros que están alineados con la estrategia del negocio. Después de definir el alcance se procede a evaluar la situación actual de la Organización. Por esa razón, la PMO decide monitorear los proyectos que se ejecutan en los departamentos identificando al menos 35 iniciativas en curso. Estos eran diferentes tipos de proyectos, desde mejora de procesos, automatizaciones, hardware, software. Analizando la información histórica de los proyectos se encuentra que estos generalmente fracasaban debido a problemas de gestión de proyectos, objetivos mal definidos, problemas de planificación o problemas con los recursos. Se realiza un análisis FODA para conocer la situación actual de la organización y cómo la PMO debe implementarse tomando en consideración cada aspecto: fortalezas, oportunidades, debilidades y amenazas. • Fortalezas, se realiza el análisis interno de las actividades y procesos que la organización realiza con buen desempeño y conocimiento. También se analizan los recursos que controla la organización. Por ejemplo: conocimientos de metodologías de gestión de proyectos, compromiso de la alta gerencia con la necesidad de ejecución y seguimiento del cumplimiento de los proyectos corporativos, el personal cuenta con experiencia en la gestión de proyectos. • Oportunidades, se realiza el análisis de factores externos del entorno con connotación positiva para la organización. Por ejemplo: el surgimiento de nuevas tecnologías soporta la implementación de una PMO, la competencia directa ha empezado a implementar PMO lo que obliga a la organización a realizar el mismo trabajo. • Debilidades, se realiza el análisis interno de las actividades y procesos que la organización no ejecuta con buen desempeño o conocimiento. También se analizan los recursos que se necesitan pero que no posee la organización. Por ejemplo: el 61 personal no cuenta con el perfil ni conocimiento para implementar una PMO, no se cuentan con metodologías o estándares para la gestión de proyectos. • Amenazas, se realiza el análisis de factores externos del entorno con connotación negativa para la organización. Por ejemplo: exageración en medidas de control y de requerimientos de información externos, marco restrictivo legal que dificulte una rápida respuesta a necesidades urgentes de recursos humanos y materiales. Se utiliza la técnica de la Lluvia de ideas y se invita a los gerentes de las distintas unidades de negocio y las jefaturas involucradas en la gestión de proyectos. En esta sesión se presenta la idea de implementación de la PMO y las funciones que debe cubrir. Los asistentes proporcionaron importantes ideas sobre el diseño de la PMO y su composición. Por ejemplo, que la lidere el Gerente de TI y sea conformada por jefes de proyecto senior que reporten matricialmente a él y a los Gerentes Funcionales. Además, propusieron que los miembros de la PMO promuevan el cambio y la prospectiva de nueva tecnología. 5.2 Evaluar riesgos en la implementación Como recomienda Kerzner (Kerzner, 2017), es de vital importancia identificar los riesgos en la implementación de la PMO. Uno de los principales riesgos que enfrenta la implementación de una PMO es que la cultura de no favorece el cambio, por lo cual se tiene que elaborar toda una estrategia para llevar a cabo este cambio de manera exitosa y que no se vea a la PMO como una oficina burocrática. Otro riesgo es la competencia de las áreas funcionales por la gestión de los recursos y la priorización que hacen sobre la operación contra los proyectos, conduciendo en retrasos en los mismos. Esta situación se tiene que cambiar con más empoderamiento de los líderes de proyecto, cambio cultural, con soporte de la dirección propiciado por la PMO. También se ha identificado que los líderes de proyecto se concentran mucho en el área técnica y no en los temas de gestión del proyecto, no perciben el valor de dedicarse a los temas de gestión y lo relegan a los gestores que ayudan en el soporte del proyecto. La PMO con capacitación, con obtención de resultados de algunos líderes de proyecto más preocupados por estos temas, con una estrategia que acompañe cómo llegar a los líderes y compartir las buenas prácticas, va a ser necesaria para interiorizar estos conceptos y llevarlos a la práctica por los líderes de proyectos. 62 Además, al no contar con herramientas para la gestión, se propone conseguir una herramienta sencilla, simple, que permita comenzar en un nivel bastante básico, para luego escalar poco a poco y que se pueda ver rápidamente los resultados del uso de la herramienta con las buenas prácticas en la gestión. Otro riesgo identificado es que no se pueden visualizar inmediatamente los resultados de la PMO y el aporte a la organización. Es fundamental para esto realizar un levantamiento de información inicial sobre el estado actual de los proyectos y comparar los resultados progresivamente y difundir los buenos resultados a la organización. A continuación, se muestran los principales riesgos y sus respectivas estrategias de mitigación en la siguiente tabla: Tabla 19. Riesgos identificados en la implementación de la PMO Descripción del riesgo Probabilidad ocurrencia Nivel de impacto Prioridad atención Enfoque para la mitigación del riesgo Competir prioridades para los recursos de personal Alta Alta Alta El Comité Directivo es capaz de priorizar la mayoría de los temas. El personal con funciones dentro de procesos claves estará disponible según se requiera. Calendario de ejecución no realista, tratando de hacer todo a la vez Baja Media Baja Implementa fases utilizando la asistencia de juicio experto. Modifica el calendario como exigen las prioridades operacionales Personal no calificado para apoyar los procesos Alta Alta Baja Compromiso significativo con el programa de capacitación formal. 63 Descripción del riesgo Probabilidad ocurrencia Nivel de impacto Prioridad atención Enfoque para la mitigación del riesgo Dificultad para inculcar un cambio cultural Alta Alta Alta Continuo enfoque y comunicación de Alta Dirección. Define claramente funciones, responsabilidades y expectativas en todo el grupo de trabajo y las actividades del proceso. Proporcionar una amplia formación. Las herramientas son incapaces de apoyar a los procesos Media Media Baja Solicitar una solicitud de cambio para el sistema. En caso extremo se decidirá la compra de otra herramienta. Falta de rendición de cuentas o de responsabilidad Alta Alta Media Establecer claramente las funciones, responsabilidades y expectativas; asegurar la participación en todas las áreas funcionales. Exceso de centrarse en tácticas, soluciones aisladas en lugar de un enfoque estratégico Baja Baja Baja Establecer el marco de la PMO como una iniciativa estratégica. Mantener la comunicación y coordinación entre los grupos de trabajo. 64 Descripción del riesgo Probabilidad ocurrencia Nivel de impacto Prioridad atención Enfoque para la mitigación del riesgo Falta de integración entre los procesos Alta Media Baja Coordinar estrechamente los esfuerzos con las áreas funcionales y adoptar las mejores prácticas de gobernanza. Escasa comunicación con los clientes y partes interesadas Alta Alta Media Establecer canales de comunicación formales e informales. Definir una continua campaña de comunicación 5.3 Establecer visión, misión y objetivos de la PMO Como propone Wysocki (Wysocki, 2011), luego de tomar la decisión de implementar la PMO se debe establecer la misión y visión de la PMO. La visión y la misión de la PMO se definen alineados a la visión y estrategia de la Organización. Es decir, se debe procurar establecer que aportará la PMO a la Organización. Se definen la visión y misión para respaldar la creación de la PMO: 5.3.1 Misión La misión de la PMO es monitorear, junto a los líderes de proyecto, el estado del proyecto, los recursos utilizados, y los riesgos identificados; comunicar alertas en caso de detectar desvíos o riesgos significativos, facilitar el escalamiento para la resolución de conflictos y estandarizar procesos de gestión de proyectos. 5.3.2 Visión La visión de la PMO es convertirse en el vehículo por el cual la organización se posicione y convierta en un punto de referencia en su industria. Mejorando la capacidad de gestión 65 de proyectos de la Organización y participando directamente en la expansión de la ventaja competitiva de la empresa. 5.3.3 Objetivos Debido a que la PMO se define como una unidad de negocio, sus objetivos se enmarcan en términos comerciales. Con la implementación de la PMO se esperan alcanzar los siguientes objetivos: • Gestionar eficaz y eficientemente el portafolio de proyectos de la organización. • Facilitar la toma de decisiones proporcionando información oportuna y significativa sobre la gestión de los proyectos. • Estandarizar y realizar una mejora continua de los procesos de gestión de proyectos. • Gestionar las expectativas de los directivos y clientes internos de los proyectos. • Establecer un marco de gobierno que facilite la priorización de proyectos. 5.4 Definir ubicación dentro de la organización Como parte inicial del proceso de implementación de la PMO, esta se define como una entidad dependiente de la Gerencia de Tecnologías de Información (TI), como se aprecia en la Ilustración 8. En esta estructura, la PMO reporta al Gerente de TI quien a su vez es el interlocutor entre la PMO y las demás unidades de negocio. Todos los presupuestos, planes de proyectos y cronogramas son definidos de la mano con los Gerentes de las otras unidades funcionales. 66 Ilustración 8. Ubicación de la PMO. Elaboración propia. Gerencia General Operaciones Finanzas TI Servicio al Cliente Infraestructura Sistemas Soporte técnico PMO En la estructura definida se contempla que la PMO pueda satisfacer las necesidades de todas las Unidades de Negocio de la organización, ofreciendo apoyo adaptándose a la realidad de cada área y con conocimiento específico en la disciplina correspondiente. Se plantea que a medida que la PMO adquiera mayor nivel de madurez, su posición dentro de la organización cambiará, tomando mayor relevancia y protagonismo. En esta nueva propuesta reporta directamente a la Gerencia General y trabaja al mismo nivel que los demás Gerentes de las Unidades de Negocio. La propuesta para la nueva ubicación de la PMO se muestra en la Ilustración 9. Ilustración 9. Ubicación de la PMO (siguiente nivel). Elaboración propia Gerencia General Operaciones Finanzas TI Servicio al Cliente Infraestructura Sistemas Soporte técnico PMO 67 5.5 Definir roles y responsabilidades En esta etapa de la implementación, se definen los roles y responsabilidades del equipo que conformará la PMO. Esta definición se plantea tomando en consideración la cultura organizacional, los tipos de proyectos que ejecuta y los roles que la persona pueda tener dentro de la organización. Esta definición debe ser comunicada oportunamente a las Unidades de Negocio para que estas sepan a quién acudir durante la ejecución de los proyectos. En la Tabla siguiente se muestran los roles y responsabilidades. Tabla 20. Roles y Responsabilidades en la PMO Rol Responsabilidad Patrocinador PMO Asegurar que la PMO cuente con los recursos necesarios para su óptimo desempeño Resolver incidentes escalados de la PMO Aprobar las iniciativas de proyectos de la PMO Comité Directivo PMO Resolver incidentes de proyectos Revisar que los proyectos estén alineados a los objetivos de la organización Aprobar la ejecución de los proyectos Aprobar los entregables de los proyectos Administrar el desempeño y disponibilidad de recursos del personal de proyectos Proponer iniciativas de proyectos a las Unidades de Negocio, aplicando nuevas tecnologías Gerente de PMO Liderar la cultura de gestión de proyectos, asegurando que las mejores prácticas de gestión de proyectos sean definidas y adoptadas Desarrollar benchmarking de las mejores prácticas de gestión de proyectos Proporcionar una perspectiva holística de la organización en las discusiones y reuniones de la PMO. 68 Rol Responsabilidad Jefe de proyectos Responsable de dirigir el proyecto asegurando el cumplimiento de los estándares de gestión del proyecto Asegurar el cumplimiento de los objetivos del proyecto y la oportuna comunicación a la PMO Gestionar las expectativas de los interesados Dirigir el equipo del proyecto Escalar incidentes cuando no puedan resolverse dentro del proyecto Líder del Departamento Funcional Asegurar comunicación efectiva de expectativas dentro de la PMO Apoyar a la PMO cuando se trata de proyectos que se llevan a cabo en el departamento Usuario final Proveer retroalimentación de los servicios ofrecidos por la PMO Estar involucrado cada vez que la PMO lo requiera 5.6 Definir estructura de Gobierno y Escalamiento Como parte de la definición de una PMO es importante definir los procesos de aprobación de nuevas iniciativas, así como quiénes son las personas/roles responsables de la aprobación de requerimientos o de solucionar incidentes que sucedan durante la ejecución de los proyectos. 5.6.1 Proceso de solicitud de nuevos requerimientos/proyectos El Comité de PMO define el proceso de cómo debe definirse una iniciativa o proyecto y cómo debe tratarse para llegar finalmente a su ejecución. Elaborar Especificación de Requerimientos Una nueva iniciativa o proyecto que surge en una de las Unidades de Negocio debe ser debidamente documentada. Para ello, un representante del área (quien normalmente es un jefe o dueño de proceso) debe elaborar el documento de Especificación de Requerimientos. En este documento se consideran los siguientes puntos: • Descripción de la situación actual, la cual describe cómo realizan actualmente el trabajo. 69 • Descripción de la situación propuesta, la cual describe los requerimientos que solicitan brindando el mayor detalle posible. • Justificación, indica por qué se realiza el requerimiento, por ejemplo, si es por una necesidad del negocio o un requerimiento legal. • Beneficios, indica los beneficios que espera obtener el negocio por implementar la iniciativa o proyecto. Se sugiere colocarlo en términos cuantitativos. • Riesgos de no implementarlo, indica a qué se expone el negocio de no implementarse la iniciativa, por ejemplo, pago de multas, pérdidas de clientes. • Unidad Solicitante, indica la Unidad de Negocio solicitante y quien se hará responsable de asumir los costos del proyecto. • Representante de la Unidad Solicitante, indica a la persona de parte del negocio con quién la PMO coordinará la ejecución del proyecto y quien dará conformidad a los entregables del proyecto. • Criterios de éxito, indica las métricas por las que se medirá el entregable del proyecto para evaluar si fue exitoso o no. Evaluar viabilidad de la iniciativa o proyecto Cuando la Unidad de Negocio culmina la elaboración del documento de Especificación de Requerimientos, este es enviado a la PMO para que sea revisado y puedan en primera instancia validar si el requerimiento es viable. Esta tarea en realidad es dinámica, porque el compromiso de la PMO es trabajar con la Unidad de Negocio para afinar el documento de modo que se pueda tener una iniciativa viable. La posibilidad de que el requerimiento no sea viable debe ser mínima. El mandato del Comité de Directores es prestar toda la ayuda a las Unidades de Negocio para que propongan siempre iniciativas a la PMO. La PMO adicionalmente agrega al documento el costo estimado del proyecto. Solicitar aprobación de fondos El solicitante del requerimiento solicita a su respectivo Gerente Funcional la aprobación de los recursos económicos para cubrir el costo del proyecto. Dependiendo del monto, esta aprobación puede realizarla el Gerente Funcional o si es de mayor cuantía se solicita a la Gerencia General. 70 Si los fondos son aprobados, el requerimiento pasa a la PMO para la siguiente etapa. Caso contrario el proyecto se desestima por falta de recursos. Sin embargo, se aconseja a la Unidad de Negocio explorar otras alternativas menos costosas para implementar la iniciativa. Autorizar proyecto Luego de que la PMO presenta todas las iniciativas priorizadas, procede la siguiente etapa que consiste en coordinar y gestionar la asignación de los recursos para que los proyectos puedan iniciar su ejecución. También coordina los tiempos y plazos de los proyectos. Con toda esto definido, se actualiza la información del proyecto y se asigna formalmente su autorización de ejecución. Ejecutar proyecto El jefe de proyecto asignado inicia las tareas necesarias, en coordinación con la Unidad solicitante para dar comenzar formalmente con la ejecución del proyecto. Como resumen, se muestra la siguiente ilustración con las tareas del proceso de solicitud de nuevos requerimientos. Ilustración 10. Proceso de Solicitud de nuevos requerimientos. Elaboración propia 71 5.7 Definir funciones En esta etapa de la implementación, se definen las siguientes funciones de la PMO categorizadas de acuerdo a la propuesta de Ayyagri (Ayyagari et al., 2006) encontrada en la literatura. 5.7.1 Funciones relacionadas al Conocimiento En esta sección se definen las funciones asociadas a cómo se gestionará el conocimiento relativo a la gestión de proyectos dentro de la PMO y de la organización. Definición y adaptación de metodología de gestión de proyectos, mejores prácticas y estándares El Comité de PMO decide que la PMO aplicará a la gestión de proyectos las mejoras prácticas definidas por el PMI en el PMBOK (Project Management Institute, 2017) y las adaptará en las tareas propias de la gestión y control de proyectos. Esta decisión se sustenta además en que las personas que forman parte de la PMO cuentan con la certificación de Project Management Professional (PMP) otorgada por el PMI. Adicionalmente, se definen los procesos de Gestión de proyectos, Gestión de cambios, Aceptación de proyectos, Lecciones aprendidas, Cierre de proyectos. Planificación de formación a los miembros de la PMO y a los principales stakeholders Se establece el Plan de Capacitación para todos los miembros de la PMO y de los principales stakeholders. Este Plan incluye capacitaciones en: metodología de gestión de proyectos, uso correcto de plantillas, procedimientos operativos, generación de consultas y reportes para los stakeholders. registro y control de proyectos. Definición y gestión de documentación de proyectos Se definen las plantillas de los documentos necesarios para la solicitud de iniciativas o nuevos proyectos, para la gestión y control de proyectos, cierre de proyectos, lecciones aprendidas. 5.7.2 Funciones relacionadas al Control En esta sección se definen las funciones asociadas a cómo se controlará la ejecución de los proyectos, enfocándose en el control de cambios y la gestión de riesgos. Centralizar la gestión del cambio para todos los proyectos 72 La PMO es el organismo que centraliza toda la gestión del cambio de los proyectos. Para este fin se define un procedimiento que incluye las plantillas a completar con las justificaciones técnicas, económicas y/o legales y las aprobaciones necesarias dependiendo del impacto y riesgo del cambio. Centralizar y analizar riesgos La PMO es responsable de identificar, analizar y tomar acción ante los riesgos que se presenten en la ejecución de los proyectos. El análisis de los riesgos conlleva a tomar la decisión de cómo enfrentar los riesgos, definiendo para ello un plan de acción. 5.7.3 Funciones relacionadas a la Gestión de recursos En esta sección se definen las funciones asociadas a la gestión de los recursos que se requieren para la exitosa ejecución de los proyectos. Compartir y coordinar recursos en todos los proyectos La PMO es responsable de la gestión de los recursos necesarios para la ejecución de proyectos. Es la PMO quien debe coordinar el movimiento de los recursos entre los proyectos, buscando el uso óptimo de los mismos. Evaluar y seleccionar herramientas de gestión La PMO realiza la evaluación y selección de herramientas de software que faciliten la gestión y control de los proyectos, así como un repositorio o base de datos de conocimiento que permita el registro de las lecciones aprendidas de los proyectos. 5.8 Definir métricas de medición De acuerdo con los objetivos para la PMO, se definen los indicadores para cada uno de ellos; los cuales tomarán importancia luego de la implementación de la PMO en la organización. Estos indicadores son los que se medirán durante la ejecución de los proyectos que tenga a cargo la PMO. En la tabla 21 se muestran los objetivos y sus respectivos indicadores. En la tabla 22 se muestra la definición y detalle de cada indicador. 73 Tabla 21. Objetivos e indicadores Objetivo Indicador Gestionar eficaz y eficientemente el portafolio de proyectos de la organización Porcentaje de proyectos entregados dentro el presupuesto Porcentaje de proyectos entregados dentro del cronograma Estandarizar y realizar una mejora continua de los procesos de gestión de proyectos Porcentaje de proyectos fallidos Porcentaje de ahorro por proyecto 74 Tabla 22. Indicadores de medición Indicadores de gestión Fórmula de cálculo Objetivo Responsable Puntos de medición Frecuencia Sistema de información Meta Semaforización Registro Gestión Porcentaje de proyectos entregados dentro del presupuesto # proyectos entregados dentro del presupuesto / # proyectos totales Verificar el nivel de gestión de proyectos de la PMO Gerente de proyecto Asesor de la Gerencia de proyectos Presupuesto del proyecto Mensual Sistema de información para la gestión de proyectos 90% Verde: >=90% Ámbar: >75% y <90% Rojo: <=75% Porcentaje de proyectos entregados dentro del cronograma # proyectos entregados dentro del cronograma / # proyectos totales Verificar el nivel de gestión de proyectos de la PMO Gerente de proyecto Asesor de la Gerencia de proyectos Cronograma del proyecto Mensual Sistema de información para la gestión de proyectos 90% Verde: >=90% Ámbar: >75% y <90% Rojo: <=75% Porcentaje de proyectos fallidos # proyectos fallidos entregados / Verificar el resultado de aplicar mejora continua de Gerente de proyecto Asesor de la Gerencia Documentos de cierre del proyecto Mensual Sistema de información para la 5% Verde: <=5% Ámbar: >5% y <15% Rojo: >=15% 75 # proyectos totales procesos de la PMO de proyectos gestión de proyectos Porcentaje de ahorro por proyecto Monto ahorrado del proyecto / monto presupuesto total Verificar el resultado de aplicar mejora continua de procesos de la PMO Gerente de proyecto Asesor de la Gerencia de proyectos Presupuesto del proyecto Mensual Sistema de información para la gestión de proyectos 5% Verde: >=5% Ámbar: >5% y <15% Rojo: <=15% 76 5.8.1 Monitoreo de indicadores El monitoreo de los indicadores de gestión permite la evaluación continua y sistemática del desempeño de la gestión de proyectos por parte de la PMO implementada. De esta manera, se puede contar con información que muestre si el desempeño real está alcanzando los valores esperados o no. En esta sección se detalla el modelo de monitoreo y seguimiento de indicadores que se implementa para medir la efectividad de las proporciones y rangos establecidos para los indicadores. Es decir, se establecerá el seguimiento de los resultados obtenidos al poner en marcha la PMO. Los resultados obtenidos del monitoreo permitirán priorizar los ajustes a realizar a los procesos involucrados, así como también a los indicadores, con el fin de obtener mejores resultados en la siguiente medición. Para realizar el monitoreo de indicadores, se define el siguiente proceso: • Identificación de los responsables de medición. Cada uno de los indicadores debe tener un responsable de la medición y un responsable para su gestión. Esta información ha sido consignada en la matriz de indicadores • Definición de la línea base. La línea base es el valor que se obtiene luego de realizar la primera medición. Permite valorar los resultados obtenidos luego de cada medición en los periodos establecidos. • Semaforización. Se debe definir el rango de 0 a 100% que representa los estadíos del indicador. Esta información ha sido consignada en la matriz de indicadores. • Definición del cronograma de evaluación. La medición de los indicadores se realiza en periodos de tiempo establecidos. Se sugiere medir en los momentos que suponen algún tipo de criticidad en el proceso y/o en los momentos que se requiere evaluar algún tipo de resultado o entregable. Los periodos establecidos pueden ser modificados de acuerdo con la necesidad del usuario, pero se sugiere tener previamente establecido los periodos de medición. • Actualización de indicadores. Si durante el monitoreo de los indicadores se detectan que no se miden los valores adecuadamente o que el valor definido como meta es muy alejado de los valores reales, es posible entonces realizar modificaciones a los indicadores. Para ello, las personas responsables del monitoreo 77 establecen un plan de actualización que contiene la justificación del cambio, los cambios realizados y la nueva línea base. • Definición de instrumentos de monitoreo. Se elabora un Informe periódico de seguimiento cuyo objetivo es obtener la información de la mejora del proceso ejecutadas por las decisiones correctivas tomadas en función a los valores obtenidos por los indicadores. • Matriz de monitoreo. Para el monitoreo de los indicadores, se propone el uso de la siguiente matriz de seguimiento detallada en la tabla siguiente. Tabla 23. Matriz de monitoreo de indicadores en un periodo Indicador Línea base Periodo 1 Valor esperado Valor real Semáforo Porcentaje de proyectos entregados dentro del presupuesto 70% 85% <75%: Rojo >75% y <85%: Ámbar >85%: Verde Porcentaje de proyectos entregados dentro del cronograma 70% 85% <75%: Rojo >75% y <85%: Ámbar >85%: Verde 5.8.2 Factores críticos de éxito de la implementación de la PMO Como se identificó en el trabajo de Raharjo (Raharjo et al., 2018), para lograr los objetivos trazados en el proyecto de implementación de la PMO es importante identificar los factores críticos de éxito. Por ejemplo, Turner (Turner et al., 2010) propone que un factor crítico del éxito para la implementación de la PMO es el involucramiento de la alta gerencia ya que en las pequeñas empresas la aplicación de procesos de gestión de proyectos son directamente dependientes del compromiso del director de área o la alta gerencia. Para la implementación de la PMO se definen los siguientes factores críticos de éxito del proyecto: 78 • Apoyo de la Gerencia General y Gerencias Funcionales. • Amplio involucramiento de los principales interesados. • Colaboración Cross-funcional a todo nivel. • PMO orientada a alinear los proyectos a los objetivos estratégicos de la organización. 79 Capítulo 6. Validación de la Primera Propuesta En el presente capítulo se muestran los resultados obtenidos luego de implementar la PMO según la primera propuesta elaborada en este trabajo de tesis. En la primera sección se describe el contexto de la organización donde se implementó la PMO. En la segunda sección se detalla el análisis de los resultados que se obtuvieron respecto a los tiempos de ejecución de los proyectos comparándolos antes y después de la implementación. En la tercera sección se detalla el análisis de los resultados que se obtuvieron respecto a los costos de los proyectos comparándolos antes y después de la implementación. En la cuarta sección se comentan los resultados. 6.1 Contexto de aplicación Haciendo uso de la primera propuesta documentada en este trabajo, se implementó la PMO para un área de TI en una organización considerada como "gran empresa", de acuerdo con la normativa peruana que otorga esta clasificación por el volumen de ventas anuales y por el número de trabajadores en planilla. La organización cuenta con su propia área de TI, la cual es responsable de gestionar en promedio 30 proyectos tecnológicos anuales. Estos proyectos corresponden principalmente al desarrollo e implementación de sistemas de información que brindan soporte a las operaciones de la organización. El área cuenta con al menos 5 gerentes de proyectos. El equipo directivo de la organización estaba convencido que para mejorar la gestión de sus proyectos debía apoyar la implementación de una PMO. Para ello, autorizó a los gerentes de las distintas áreas de negocio a nombrar a un líder funcional para participar en las reuniones, talleres y actividades relacionadas con la implementación de la PMO. Con esta designación, el líder funcional debía asignar horas de su jornada laboral a las tareas relacionadas con la PMO. Es importante mencionar que la satisfactoria implementación de la PMO en la organización se logró gracias a las consideraciones antes mencionadas. Por lo que, para escenarios o contextos distintos, el presente modelo debe adaptarse y/o ajustarse para lograr los resultados esperados. Luego de la implementación de la PMO, se realizó el monitoreo de los indicadores de desempeño de la PMO, tomando principal énfasis en los tiempos y costos relativos a la ejecución de los proyectos. Estos son los indicadores más relevantes para la organización ya que su principal interés era cumplir con los plazos establecidos así 80 como ejecutar eficientemente los presupuestos de los proyectos. Por esa razón, se realizaron las comparaciones de estos resultados (tiempos y costos) con los valores obtenidos antes y después de la implementación de la PMO. 6.2 Análisis de tiempo de ejecución de proyectos Uno de los indicadores importantes que se definieron para medir el rendimiento de la PMO implementada fue el sobretiempo (expresado en días) en la ejecución de los proyectos. Para medir los resultados, se comparan los sobretiempos de los proyectos antes de la implementación con los que se obtuvieron después de implementar la PMO. En la Tabla 24 se muestran los sobretiempos antes de la implementación de la PMO. Del mismo modo, en la Tabla 25 se muestran los sobretiempos después de la implementación de la PMO. Con ambas muestras, lo que se busca es determinar el estadístico que permita verificar si existen diferencias significativas entre los sobretiempos de ejecución de proyectos antes y después de la implementación de la PMO. Tabla 24. Sobretiempos (en días) en la ejecución de proyectos antes de la PMO 10.00 15.76 20.24 32.86 44.04 12.02 16.94 28.03 33.80 50.30 13.96 18.25 29.09 40.40 65.14 14.11 18.87 30.96 41.26 84.10 Tabla 25. Sobretiempos (en días) en la ejecución de proyectos después de la PMO 1.34 2.38 3.48 5.01 7.79 1.75 2.84 3.50 5.79 14.33 1.94 2.91 4.29 6.01 24.91 2.10 3.05 4.81 7.00 32.99 81 Por esa razón se ejecuta el test de normalidad para determinar si ambas muestras se comportan como una distribución normal. Se aplica la prueba de Anderson-Darling para una muestra de n=20: • H0: Los datos provienen de una población normal • H1: Los datos no provienen de una población normal Usando la herramienta Minitab, se evalúa la primera muestra (antes de la implementación de la PMO). En esta evaluación se obtuvo el valor de p=0.037 y el nivel de significación de α=0.05. Con esto se rechaza la hipótesis nula, por lo que se puede concluir que las muestras observadas no siguen una distribución normal. Del mismo modo, se evalúa la segunda muestra (después de la implementación de la PMO). En esta evaluación se obtuvo el valor de p<0.005 y el nivel de significación de α=0.05. Con esto se rechaza la hipótesis nula, por lo que se puede concluir que las muestras observadas no siguen una distribución normal. En las Ilustraciones 11 y 12 se aprecian los resultados de la aplicación de la prueba de normalidad. Ilustración 11. Prueba de normalidad de sobretiempos (antes de la PMO) 82 Ilustración 12. Prueba de normalidad de sobretiempos (después de la PMO) Debido a que las muestras no siguen una distribución normal, se utilizará la prueba estadística de Mann-Whitney, la cual se utiliza para comparar las medianas de dos muestras independientes antes y después (Flores-Ruiz et al., 2017). Para este caso, se comparan las medianas de ambas muestras: • H0: Las medianas de las muestras son iguales • H1: Las medianas de las muestras no son iguales Usando la herramienta Minitab, se evalúan las medianas de ambas muestras. En esta evaluación se obtuvo el valor de p ≤ α y el nivel de significación de =0.05. Con esto se rechaza la hipótesis nula, por lo que se puede concluir que la diferencia en las medianas de las poblaciones es estadísticamente significativa. En la Tabla 26 se pueden observar los resultados de la prueba. En base al resultado previo, se vuelve a ejecutar la prueba de Mann-Whitney para comparar las medianas de ambas muestras: • H0: Las medianas de las muestras son iguales • H1: La mediana de la primera muestra es mayor que la mediana de la segunda muestra 83 Tabla 26. Comparación de medianas de sobretiempos Prueba de Mann-Whitney e IC: 2019-T; 2020-T N Mediana 2019-T 20 28.56 2020-T 20 3.90 La estimación del punto para ETA1-ETA2 es 19.01 95.0 El porcentaje IC para ETA1-ETA2 es (12.45;29.72) W = 584.0 Prueba de ETA1 = ETA2 vs. ETA1 no es = ETA2 es significativa en 0.0000 Usando la herramienta Minitab, se evalúan las medianas de ambas muestras. En esta evaluación se obtuvo el valor de p ≤ α y el nivel de significación de =0.05. Con esto se rechaza la hipótesis nula, por lo que se puede concluir que la mediana de la primera muestra (antes de implementar la PMO) es mayor que la mediana de la segunda muestra (después de implementar la PMO). En la Tabla 27 se pueden observar los resultados de la prueba. Tabla 27. Determinación de la mediana mayor Prueba de Mann-Whitney e IC: 2019-T; 2020-T N Mediana 2019-T 20 28.56 2020-T 20 3.90 La estimación del punto para ETA1-ETA2 es 19.01 95.0 El porcentaje IC para ETA1-ETA2 es (12.45;29.72) W = 584.0 Prueba de ETA1 = ETA2 vs. ETA1 > ETA2 es significativa en 0.0000 6.3 Análisis de costos de proyectos Otro indicador importante que se definió para la PMO implementada fue el sobrecosto (expresado en soles) en la ejecución de los proyectos. Para medir los resultados, se comparan los sobrecostos de los proyectos antes de la implementación con los que se obtuvieron después de implementar la PMO. En las Tablas 28 y 29 se muestran los sobrecostos antes y después de la implementación de la PMO respectivamente. 84 Tabla 28. Sobrecostos (en Soles) en la ejecución de proyectos antes de la PMO 1000 1500 1000 900 0 0 0 0 850 1950 1500 1200 2000 1350 0 0 0 750 2500 0 Tabla 29. Sobrecostos (en Soles) en la ejecución de proyectos después de la PMO 0 0 650 0 850 1000 0 0 0 0 600 800 0 900 1200 0 0 500 0 500 Con ambas muestras, lo que se busca es determinar el estadístico que permita verificar si existen diferencias significativas entre los sobrecostos de ejecución de proyectos antes y después de la implementación de la PMO. Por esa razón se ejecuta el test de normalidad para determinar si ambas muestras se comportan como una distribución normal. Se aplica la prueba de Anderson-Darling para una muestra de n=20: • H0: Los datos provienen de una población normal • H1: Los datos no provienen de una población normal Usando la herramienta Minitab, se evalúa la primera muestra (antes de la implementación de la PMO). En esta evaluación se obtuvo el valor de p=0.012 y el nivel de significación de α=0.05. Con esto se rechaza la hipótesis nula, por lo que se puede concluir que las muestras observadas no siguen una distribución normal. En la Ilustración 13 se puede observar el resultado de la prueba. 85 Ilustración 13. Prueba de normalidad de sobrecostos (antes de la PMO) Del mismo modo, se evalúa la segunda muestra (después de la implementación de la PMO). En esta evaluación se obtuvo el valor de p<0.005 y el nivel de significación de α=0.05. Con esto se rechaza la hipótesis nula, por lo que se puede concluir que las muestras observadas no siguen una distribución normal. En la Ilustración 14 se puede observar el resultado de la prueba. Debido a que ambas muestras no siguen una distribución normal, se aplica la prueba de Mann-Whitney para comparar las medianas de ambas muestras: • H0: Las medianas de las muestras son iguales • H1: Las medianas de las muestras no son iguales Usando la herramienta Minitab, se evalúan las medianas de ambas muestras. En esta evaluación se obtuvo el valor de p ≤ α y el nivel de significación de =0.05. Con esto se rechaza la hipótesis nula, por lo que se puede concluir que la diferencia en las medianas de las poblaciones es estadísticamente significativa. En la Tabla 30 se pueden observar los resultados de la prueba. 86 Ilustración 14. Prueba de normalidad de sobrecostos (después de la PMO) Tabla 30.Comparación de medianas de sobrecostos Prueba de Mann-Whitney e IC: 2019-C; 2020-C N Mediana 2019-C 20 875.0 2020-C 20 0.0 La estimación del punto para ETA1-ETA2 es 350.0 95.0 El porcentaje IC para ETA1-ETA2 es (-0.1;950.2) W = 479.5 Prueba de ETA1 = ETA2 vs. ETA1 no es = ETA2 es significativa en 0.0620 La prueba es significativa en 0.0482 (ajustado por empates) En base al resultado previo, se vuelve a ejecutar la prueba de Mann-Whitney para comparar las medianas de ambas muestras: • H0: Las medianas de las muestras son iguales • H1: La mediana de la primera muestra es mayor que la mediana de la segunda muestra Usando la herramienta Minitab, se evalúan las medianas de ambas muestras. En esta evaluación se obtuvo el valor de p ≤ α y el nivel de significación de =0.05. Con esto se 87 rechaza la hipótesis nula, por lo que se puede concluir que la mediana de la primera muestra (antes de implementar la PMO) es mayor que la mediana de la segunda muestra (después de implementar la PMO). En la Tabla 31 se pueden observar los resultados de la prueba. Tabla 31. Determinación de la mediana mayor Prueba de Mann-Whitney e IC: 2019-C; 2020-C N Mediana 2019-C 20 875.0 2020-C 20 0.0 La estimación del punto para ETA1-ETA2 es 350.0 95.0 El porcentaje IC para ETA1-ETA2 es (-0.1;950.2) W = 479.5 Prueba de ETA1 = ETA2 vs. ETA1 > ETA2 es significativa en 0.0310 La prueba es significativa en 0.0241 (ajustado por empates) 88 Capítulo 7. Propuesta de implementación de una PMO – Parte II Este capítulo contiene la segunda parte de los resultados concretos del trabajo y profundizará la comprensión de las fases de diseño e implementación de la PMO. El presente capítulo describe los lineamientos encontrados tanto en estándares aceptados internacionalmente, la literatura, y la propuesta del autor. 7.1 Definir roles y responsabilidades En esta etapa de la implementación, se define un nuevo rol dentro del equipo de la PMO. Esta nueva definición se basa en la necesidad de la organización de contar con un interlocutor entre la PMO y las unidades de negocio en temas de innovación. Jefe de proyectos de Innovación y Desarrollo. Este rol se identifica también en la literatura, siendo recomendado por Kummamuru (Kummamuru & Hussaini, 2016). Esta posición tiene como responsabilidad realizar prospección de nuevas tecnologías y analizar su factibilidad de aplicarlas en la organización. Promueve además reuniones alineadas a los objetivos de Digitalización e Innovación de la Organización, donde no solo promueve que los principales stakeholders propongan iniciativas innovadoras, sino presenta las novedades tecnológicas para evaluar en conjunto su viabilidad de implementación en la Organización. 7.2 Definir estructura de Gobierno y Escalamiento Como parte de la definición de una PMO es importante definir los procesos de priorización de proyectos, comunicación y de solución de incidentes que sucedan durante la ejecución de los proyectos. 7.2.1 Proceso de priorización de proyectos En esta segunda propuesta se define el proceso de priorización de proyectos. Para realizar la priorización de proyectos que llegan a la PMO, se define un proceso adaptado que se basa en el Estándar de la Gestión de Portafolio del PMI (Project Management Institute, 2013b). A continuación, se presentan las actividades del proceso de priorización de proyectos: 89 Identificación de proyectos. Se genera un inventario de proyectos que recibe la PMO. Este inventario contiene información que se consigna en el documento de especificación de requerimientos. Categorización de proyectos. Luego de identificar todos los proyectos, se procede a categorizarlos de acuerdo con los siguientes criterios: • Requerimiento legal • Requerimiento del Negocio • Mejora de procesos • Automatización de procesos Esta definición de criterios es importante porque permitirá realizar la puntuación de los proyectos. Evaluación de proyectos. Para la evaluación de los proyectos se definen los criterios y sus respectivos puntajes. Se sugiere usar tres niveles para la evaluación usando puntajes que van de 0 a 10. En la Tabla 32 se presenta un ejemplo. Tabla 32. Ejemplo de Niveles de Puntaje Puntaje Evaluación Bajo 0 Medio 5 Alto 10 Luego se definen los puntajes para las categorías de los proyectos. Cada categoría debe tener un puntaje dentro del rango definido. Puede ocurrir que por mandato de la Organización alguna categoría siempre tenga el puntaje más alto, por ejemplo, si son Requerimientos Legales. En la Tabla 33, se muestra un ejemplo de cómo se asignan los puntajes a las distintas categorías identificadas. En una siguiente etapa, se definen los pesos por cada criterio que se aplicarán a los proyectos a evaluar. En la Tabla 34 se muestran algunos ejemplos de criterios y sus respectivos pesos que se asignan. 90 Con todas esas definiciones, se listan los proyectos que se evaluarán. Para cada proyecto se asignan los niveles de evaluación. Por ejemplo, si el proyecto está muy alineado a los objetivos estratégicos de la Organización de implementación se asigna un puntaje de 10. Si por el contrario el proyecto no aporta a los objetivos estratégicos, se asigna un puntaje de 0. Si el proyecto está medianamente alineado se le asigna el puntaje de 5. En la Tabla 35, se muestran los proyectos y sus respectivos puntajes. Tabla 33. Ejemplo de Puntaje por Categorías Categoría Evaluación Requerimiento Legal 10 Requerimiento de Negocio 5 Mejora Procesos 5 Automatización Procesos 5 Tabla 34. Ejemplo de Pesos por criterios Para calcular el total, se multiplican los puntajes por los pesos correspondientes de cada criterio. Tener en cuenta que, para los criterios de costos y tiempo, los puntajes se restan. Por ejemplo, para obtener el puntaje total del proyecto PR001, se siguió la siguiente fórmula: Total = 10*0.3 – 10*0.2 – 5*0.2 + 10*0.3 = 3.0 Nro. Criterio Criterio Peso 1 Alineación estratégica 30% 2 Costo 20% 3 Plazo 20% 4 Categoría 30% 91 Tabla 35. Ejemplo de Proyectos evaluados Código Alineam. Estratégico Costo Plazo Categoría Total PR001 10 10 5 10 3.00 PR002 10 5 5 5 2.50 PR003 5 10 5 5 0.00 PR004 5 5 5 5 1.00 PR005 5 10 10 10 0.50 PR006 10 5 0 10 5.00 PR007 0 10 10 5 -2.50 PR008 5 5 10 5 0.00 PR009 10 0 5 5 3.50 PR010 5 5 5 5 1.00 PR011 5 0 5 5 2.00 Priorización de proyectos Con el listado de proyectos puntuados, se procede a ordenarlos para conocer cuáles son los que obtuvieron mayor puntaje, este resultado se observa en la siguiente Tabla: Tabla 36. Ejemplo de Proyectos ordenados por puntaje Código Alineam. Estratégico Costo Plazo Categoría Total PR006 10 5 0 10 5.00 PR009 10 0 5 5 3.50 92 Código Alineam. Estratégico Costo Plazo Categoría Total PR001 10 10 5 10 3.00 PR002 10 5 5 5 2.50 PR011 5 0 5 5 2.00 PR004 5 5 5 5 1.00 PR010 5 5 5 5 1.00 PR005 5 10 10 10 0.50 PR003 5 10 5 5 0.00 PR008 5 5 10 5 0.00 PR007 0 10 10 5 -2.50 La PMO debe definir como política cuál será el puntaje mínimo que se tomará en cuenta para considerar un proyecto como prioritario. Por ejemplo, para este caso en la PMO solo se priorizarán los proyectos que obtienen un puntaje mayor o igual a 1. Sin embargo, para este escenario se observa que el proyecto PR005 tiene un alto valor en el criterio Categoría, esto se debe a que se trata de un Requerimiento legal. Por esa razón, el Comité de la PMO igual considerará ese proyecto dentro del grupo de prioritarios. Con esa directiva establecida, se procede a elaborar una tabla de doble entrada para analizar la prioridad de los proyectos. Este análisis se realiza evaluando proyecto por proyecto. En la Tabla 37 se muestra el resultado de este análisis. Al ordenar la tabla, se pueden observar los puntajes obtenidos por proyecto. Los proyectos con mayor puntaje son los que tienen mayor prioridad y por ende son los que empiezan a ejecutarse primero. El resultado final se muestra en la Tabla 38. 93 Tabla 37. Ejemplo de Evaluación de priorización de proyectos PR006 PR009 PR001 PR002 PR011 PR003 PR004 PR010 Total PR006 1 0 1 1 1 1 1 6 PR009 0 0 0 1 1 1 1 4 PR001 1 1 1 1 1 1 1 7 PR002 0 1 0 1 1 1 1 5 PR011 0 0 0 0 1 1 0 2 PR004 0 0 0 0 0 0 0 0 PR010 0 0 0 0 0 1 0 1 PR005 0 0 0 0 1 1 1 3 Tabla 38. Ejemplo de Proyectos priorizados Proyecto Puntaje PR001 7 PR006 6 PR002 5 PR009 4 PR005 3 PR011 2 PR010 1 PR004 0 94 Una vez definido el orden de ejecución de los proyectos, se procede a revisar si los proyectos se encuentran balanceados. El Comité de la PMO debe definir estos lineamientos. A continuación, como parte de este ejemplo se considera que los proyectos seleccionados están balanceados cuando: • Atienden los requerimientos de diversas Unidades de Negocio • La inversión se distribuye entre las distintas Categorías de proyectos Siguiendo con el ejemplo planteado, se asocia cada proyecto con el área de negocio donde se ejecutará. En la Ilustración 15 se muestra cómo se distribuye la inversión de los proyectos por las distintas unidades de negocio de la organización. Se observa que todos los proyectos priorizados atienden requerimientos de todas las Unidades de Negocio. Ilustración 15. Inversión de proyectos por Unidad funcional. Elaboración propia. Del mismo modo, se observa en la Ilustración 16 que la inversión en los proyectos está distribuida casi equitativamente entre las distintas categorías contempladas por la PMO. Finanzas Operaciones Ventas Atención al Cliente 0 0.5 1 1.5 2 2.5 3 3.5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 Inversión por Unidad de Negocio 95 Ilustración 16. Inversión en proyectos por Categoría. Elaboración propia. Con todo el análisis culminado, el Comité de la PMO procede a autorizar los proyectos, asignando los recursos correspondientes en cada caso. Este nuevo proceso, se añade al proceso de solicitud de nuevos requerimientos. En la siguiente Ilustración se muestra esta actualización. Req. Legal Automatización Mejora de procesos Req. Negocio 0 0.5 1 1.5 2 2.5 3 3.5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 Inversión por Categoría 96 Ilustración 17. Proceso actualizado de Solicitud de nuevos requerimientos. Elaboración propia. 7.2.2 Proceso de escalamiento El Comité de la PMO define la siguiente estructura de escalamiento: Primer nivel, todo incidente debe resolverse internamente con el equipo del proyecto y la decisión final la tiene el jefe de proyectos. Segundo nivel, en caso el incidente no pueda resolverse en el primer nivel, se escala al Comité de la PMO, quien debe analizarlo y tomar una decisión al respecto. Tercer nivel, en caso el incidente no pueda resolverse en el segundo nivel, se escala al Gerente de TI, quien debe analizarlo y en consenso con el Gerente del área de negocio patrocinadora del proyecto tomar una decisión al respecto. Cuarto nivel, en caso el incidente no pueda resolverse en el tercer nivel, se escala al Gerente General, quien debe analizarlo y tomar una decisión al respecto. A continuación, se ilustran los niveles de escalamiento. 97 Ilustración 18. Niveles de escalamiento en la PMO. Elaboración propia. Gerencia General Gerente de TI / Gerente Unidad Negocio Comité de PMO Jefe de Proyectos 7.2.3 Proceso de Comunicaciones Como indica Kerzner (Kerzner, 2017), la mayoría de organizaciones se enfrentan al problema de cómo asegurar que la información crítica, como indicadores de gestión y factores críticos de éxito, sean conocidas por todos los miembros de la organización. Por su parte, Andrews (Andrews, 2014) propone que la comunicación de las prácticas, los procesos, los procedimientos y los mensajes aprendidos de toda la empresa se puede lograr a través de una variedad de métodos, como foros, seminarios web, notificaciones por correo electrónico, seminarios de capacitación o herramientas de comunicación empresarial (boletines informativos, transmisiones web, etc.). También sugiere que el seguimiento y las mediciones del desempeño de la gestión de proyectos deben entregarse mediante el uso de datos del proyecto mantenidos por informes de tablero o sitios de intranet. La comunicación con la administración también debe realizarse a través de un ciclo de informes regular, ya sea semanal, mensual o trimestral. Debe contener informes no periódicos cuando las estimaciones de los proyectos se desvíen del plan. En base a estas recomendaciones, la PMO identifica que en la Organización los canales de comunicación más usados son: correo electrónico, video llamadas y boletín de noticias. Sin embargo, también identifica que las reuniones mensuales y trimestrales son un buen momento para compartir información de los logros de la PMO. En la Tabla siguiente se muestra la matriz de comunicaciones. 98 Tabla 39. Matriz de comunicaciones de la PMO Contenido de mensaje Destinatario Canal de comunicación Frecuencia Responsable Reporte de avance Equipo de proyecto Correo electrónico Semanal Jefe de proyecto Utilización de recursos Equipo de proyecto Gerente de PMO Correo electrónico Video llamada Mensual Jefe de proyecto Indicadores de desempeño de proyectos Equipo de proyecto Gerente de PMO Video llamada Mensual Jefe de proyecto Lecciones aprendidas Equipo de proyecto Gerente de PMO Video llamada Mensual Jefe de proyecto Decisiones de gobierno de PMO Gerente de PMO Gerente de TI Gerente de Unidad Correo electrónico Video llamada Mensual Comité de PMO Actualización de riesgos e incidentes Gerente de PMO Gerente de TI Gerente de Unidad Correo electrónico Video llamada Mensual Comité de PMO Indicadores de desempeño de PMO Gerente General Gerente de Unidad Correo electrónico Video llamada Trimestral Gerente de PMO Logros de proyectos Empleados Correo electrónico Trimestral Gerente de PMO 99 7.3 Definir funciones En esta etapa de la implementación, se definen funciones adicionales de la PMO, siguiendo la categorización propuesta por Ayyagri (Ayyagari et al., 2006) encontrada en la literatura. 7.3.1 Funciones relacionadas al Conocimiento En esta sección se definen las funciones asociadas a cómo se gestionará el conocimiento relativo a la gestión de proyectos dentro de la PMO y de la organización. Cumplimiento de estándares y métodos La PMO es responsable de cumplir y hacer cumplir los estándares y mejores prácticas para la ejecución de los proyectos. De esta forma, se busca aprovechar las mejores prácticas y garantizar que todos los equipos de proyectos puedan hablar en un mismo lenguaje con el Negocio. Acompañamiento de proyectos La PMO acompaña a todo el equipo del proyecto y a los principales stakeholders desde la elaboración del Acta de constitución del proyecto (Project charter) hasta el cierre de este, así como en la elaboración de todos los entregables. El acompañamiento incluye el seguimiento y control de proyectos, propiciando reuniones con los principales stakeholders llevando un registro de las actas correspondientes. Centralizar, coordinar y gestionar la comunicación entre proyectos. La PMO define el ambiente de colaboración que se usará para la comunicación de los avances y logros de los proyectos. En la organización se utilizará la Intranet, email y reuniones seguimiento por unidades de negocio que se llevan a cabo trimestralmente. El objetivo es compartir logros, experiencias exitosas y conceptos, con ejemplos prácticos de la metodología y/o buena práctica aplicada en los proyectos. De esta manera se logra la divulgación de del estado de los proyectos y sus logros. 7.3.2 Funciones relacionadas al Control En esta sección se definen las funciones asociadas a cómo se controlará la ejecución de los proyectos, enfocándose en el control de las comunicaciones y el cumplimiento. Centralizar la información del estado del proyecto para la organización 100 La PMO es responsable de monitorear la salud de los proyectos, llevando el control y registro de las principales incidencias, desviaciones o logros. Esto con el fin de luego comunicar oportunamente a los principales stakeholders. Realizar auditorías a los proyectos La PMO define un plan de auditorías sobre el éxito de los proyectos, la eficacia de la gestión de proyectos, el valor y uso de la metodología y las herramientas, y el cumplimiento de los estándares y requisitos internos y externos. De esta forma se definen acciones correctivas cuando se encuentran desviaciones a los esperado. 7.3.3 Funciones relacionadas a la Gestión de recursos En esta sección se definen las funciones asociadas a la gestión de los recursos que se requieren para la exitosa ejecución de los proyectos. Gestionar las habilidades, la asignación y la capacidad de los recursos La PMO coordina estrechamente con el área de Recursos Humanos para la contratación de personal idóneo para el equipo de la PMO. Define además el perfil profesional y el plan de capacitación que debe seguir. Esta función tiene como objetivo optimizar la productividad del personal en los proyectos. Elaboración de presupuestos y seguimiento de gastos operativos y de capital del proyecto La PMO es responsable de definir los presupuestos de los proyectos, así como los presupuestos para el seguimiento de los proyectos y los gastos operativos. Es también responsable de rendir cuenta ante el Gerente de TI y los Gerentes de área de cómo se ejecuta el presupuesto y justificar cualquier desviación de este. 7.4 Definir métricas de medición En esta segunda etapa de implementación de la PMO, se definen indicadores de medición adicionales, los cuales se muestran en las Tablas 40 y 41. 101 Tabla 40. Objetivos e indicadores Objetivo Indicador Facilitar la toma de decisiones proporcionando información oportuna y significativa sobre la gestión de los proyectos Porcentaje de cumplimiento en envío de informes de proyectos Gestionar las expectativas de los directivos y clientes internos de los proyectos Porcentaje de satisfacción del cliente Establecer un marco de gobierno que facilite la priorización de proyectos Porcentaje de proyectos alineados a la estrategia organizacional 102 Tabla 41. Indicadores de medición Indicadores de gestión Fórmula de cálculo Objetivo Responsable Puntos de medición Frecuencia Sistema de información Meta Semaforización Registro Gestión Porcentaje de cumplimiento de envío de informes de proyectos # proyectos reportados / # proyectos totales Verificar que los resultados de proyectos se reportan oportunamente Gerente de proyecto Gerente de PMO Documentos de proyectos Mensual Sistema de información para la gestión de proyectos 90% Verde: >=90% Ámbar: >75% y <90% Rojo: <=75% Porcentaje de satisfacción de clientes por proyecto # clientes satisfechos / total de clientes encuestados Verificar la satisfacción de los clientes de la PMO Gerente de proyecto Asesor de Gerencia de proyectos Clientes de la PMO Mensual Sistema de encuestas 90% Verde: >=90% Ámbar: >80% y <90% Rojo: <=80% Porcentaje de proyectos alineados a la estrategia organizacional # proyectos entregados alineados a la estrategia / # proyectos totales Verificar alineamiento de los proyectos de la PMO a los objetivos estratégicos Gerente de proyecto Gerente de PMO Objetivos estratégicos de la organización Objetivos del proyecto Mensual Balanced Score Card de la organización Sistema para la gestión de proyectos 90% Verde: >=90% Ámbar: >80% y <90% Rojo: <=80% 103 7.5 Definir proyección de crecimiento (madurez) El Instituto de Ingeniería de Software de la Universidad Carnegie Mellon, ha desarrollado un modelo de madurez para la Ingeniería de software y sobre la cual se ha desarrollado un modelo para la gestión de proyectos en forma de Modelo de Madurez de Gestión de proyectos, en inglés Project Management Maturity Model (PMMM). Este modelo ha recibido una amplia aceptación como estándar para el modelado de procesos y la evaluación de la madurez organizacional en varias áreas de procesos (Crawford 2002). El PMMM establece los siguientes niveles de madurez: Nivel 1. Inicial En este nivel algunos de los procesos son definidos y se cuentan con algunas herramientas de apoyo a la gestión. Sin embargo, el cumplimiento de los procesos y el uso de las herramientas no es ampliamente usado en los equipos de proyectos y en la misma PMO. Nivel 2. Repetible En este nivel se cuenta con la mayor cantidad de procesos de gestión de proyectos documentados y se fomenta el uso de estos desde la PMO. Se tienen identificadas y estructuradas las capacitaciones a los equipos de proyectos y se brindan a demanda. Nivel 3. Definido En este nivel todos los procesos de gestión de proyectos están documentados y los Gerentes de las áreas de negocio reconocen que la gestión de proyectos es una pieza clave en los logros de los objetivos de la organización. La PMO implementada formalmente toma la responsabilidad de evangelizar a los equipos de proyectos y garantizar que la metodología de gestión de proyectos se use en la organización. Nivel 4. Gestionado En este nivel se cuenta con un plan definido de entrenamiento y programa de desarrollo para los jefes de proyectos. La organización considera como un factor crítico de éxito a la gestión de proyectos. La definición del portafolio de proyectos forma parte importante dentro del plan estratégico de la compañía. Nivel 5. Optimizado En este nivel la PMO es un componente crítico en el proceso de mejora continua de la calidad para la gestión de proyectos. Se definen métricas que permitan visibilizar la 104 salud de los proyectos y que permita a los principales stakeholders tomar una decisión y actuar oportunamente. El Comité de la PMO propone que la implementación debe pasar por un proceso de crecimiento y maduración dentro de la compañía. Para ese fin, siguiendo la propuesta del PMMM, se adapta el modelo y se propone que la PMO debe pasar por los siguientes modelos de madurez, mostrados en la siguiente tabla. Tabla 42. Niveles de madurez de la PMO Nivel de madurez Características de la PMO en el nivel actual Iniciativas que permitirán subir de nivel a la PMO Inicial (1) El proceso de gestión de proyectos no está totalmente definido. Se brinda apoyo a demanda a los equipos de proyecto. Escasa formación en gestión de proyectos. El Comité de la PMO establece y documenta el proceso de gestión de proyectos. Se define el plan de formación en gestión de proyectos y se pone a disposición Repetible (2) Se cuenta con el proceso de gestión de proyectos totalmente documentado. Se brinda apoyo a tiempo parcial a los equipos de proyecto. Formación en gestión de proyectos disponible pero limitada. Se definen estrategias para evangelizar en el uso de procesos de gestión de proyectos. Se asigna personal a tiempo completo para apoyar a los equipos de proyecto Supervisión y aseguramiento del cumplimiento de la gestión de proyectos. Se agregan tópicos avanzados para la formación de gestión de proyectos. 105 Nivel de madurez Características de la PMO en el nivel actual Iniciativas que permitirán subir de nivel a la PMO Definido (3) Proceso de gestión de proyectos totalmente documentado y respaldado. Se cuenta con personal a tiempo completo para el apoyo a equipos de proyectos. Todos los equipos están utilizando el proceso de gestión de proyectos. Los procesos de gestión de proyectos están integrados con otros procesos. Se encuentra disponible una formación de gestión de proyectos más extensa y avanzada. Los proyectos se hacen parte del plan de negocios. La PMO asume un papel activo en la contratación del personal del proyecto. Se definen diversas opciones de formación en gestión de proyectos Se define un programa de desarrollo profesional en la PMO. Los jefes de proyectos forman parte del equipo de la PMO. Gestionado (4) La PMO es responsable del desarrollo profesional de su personal. Se encuentra disponible un entrenamiento completo de gestión de proyectos. El portafolio de proyectos se gestiona como un negocio. La PMO comienza a identificar y adoptar las mejores prácticas. Se definen métricas para rastrear la calidad del proceso. Las revisiones de proyectos se utilizan para monitorear el cumplimiento. Optimizado (5) Existe un proceso de mejora continua. Se miden los criterios de éxito de todos los proyectos. Se definen auditorías para verificar el cumplimiento de los estándares y procesos de gestión de proyectos. 106 Capítulo 8. Validación de la Segunda Propuesta En el presente capítulo se muestran los resultados obtenidos luego de validar la segunda propuesta elaborada en este trabajo de tesis. Con el fin de cumplir este objetivo, se invitó a tres expertos en la implementación y gestión de PMO para que evalúen la segunda parte de la propuesta. 8.1 Proceso de validación Para lograr la validación de la propuesta se llevaron a cabo las actividades siguientes: 8.1.1 Convocatoria de expertos Para la validación de la segunda propuesta del marco de trabajo para la implementación de la PMO busca a tres expertos reconocidos y se les invita a participar como validadores. La entrevista se realizó considerando el cuestionario del Anexo 1. En promedio las entrevistas duraron 60 minutos y fueron grabadas con el consentimiento de los participantes. 8.1.2 Expertos entrevistados En la Tabla siguiente se muestra información de los expertos que participaron en las entrevistas. Tabla 43. Información de los expertos Experto Años de experiencia Detalle de experiencia Fecha de entrevista Experto 1 16 años Posee múltiples certificaciones relacionadas a la gestión de proyectos. Es profesor en distintas universidades de prestigio. Ha formado parte del cuerpo directivo del capítulo de PMI de un país en Sudamérica. Actualmente es consultor en temas de gestión de proyectos. 03/06/2021 Experto 2 15 años Se ha desempeñado como jefe de proyectos en distintas organizaciones de industrias distintas y en diferentes países de la región. 07/06/2021 107 Experto Años de experiencia Detalle de experiencia Fecha de entrevista Experto 3 15 años Posee múltiples certificaciones relacionadas a la gestión de proyectos. Es profesor en una universidad de prestigio y es consultor en temas de gestión de proyectos. Ha formado parte del cuerpo directivo del capítulo de PMI de un país en Sudamérica. 29/06/2021 8.2 Discusión del caso Con cada experto se revisan los puntos de la segunda propuesta para recoger sus opiniones. A continuación, se presentan cada uno de los puntos de la propuesta y las opiniones de los expertos. 8.2.1 Definición de roles y responsabilidades Sobre la definición del rol de Jefe de proyectos de innovación, se obtuvieron las siguientes apreciaciones de los expertos entrevistados: Experto 1: Para el Experto 1, contar con este rol dependerá de los servicios que se hayan definido que ofrecerá la PMO en la organización. Si la aplicación de nuevas tecnologías es parte de la visión de la organización, entonces la PMO debe tener la flexibilidad para contar con este rol en su equipo. A continuación, se presenta un extracto de su respuesta en la entrevista. “… Entonces teniendo claro cuáles son las expectativas que ellos esperan, se plantean las funciones que esta PMO tiene que realizar. Y tiene mucha lógica, porque una PMO tiene que ser vista como un área de servicios… … Ahora sobre lo que tú me dices, ese puede ser un servicio que esta PMO va a desarrollar, de identificar oportunidades de mejora dentro de la organización, que después se convertirán en proyectos y que esta PMO sea responsable de gestionar esos proyectos o tal vez no… 108 Y lo que mencionas, un rol de jefe de proyectos de tema innovación, claro va de la mano con lo que necesita la empresa y también su cultura de trabajo, realmente como mencionábamos, la estructura de esta oficina de proyectos va muy de la mano en realmente lo que la organización necesita.” Experto 2: Para el Experto 2, sí se debe contar con ese rol en la PMO. Sin embargo, dependerá de los tipos de proyectos que se gestionen en la PMO. Esta persona debe contar con los conocimientos de tecnologías emergentes y mostrar a la organización cómo aplicarlos y facilitar su implementación. También considera que este rol dentro de la PMO está sujeto a la naturaleza de la organización. A continuación, se presenta un extracto de su respuesta en la entrevista. “… la oficina debe contar con los conocimientos de las últimas tecnologías o de las tecnologías emergentes para poder implementarlos y obviamente dirigirlos; debe conocer cuál es el alcance de esa nueva tecnología y cómo se aplicarían dentro de la organización. Para ello se tiene que tener el conocimiento y ya sea de esta persona o de una tercera persona, llamémoslo: consultor externo que tú contrates para que se analice este tipo de proyectos no este tipo de tecnología que puedas, que desees o requieras implementarlos. … también está sujeto a la naturaleza de las empresas. Qué tanto la empresa le va a generar una ventaja competitiva los proyectos de este tipo o utilizar tecnología de este tipo y llamo tecnología de este tipo a la tecnología de última generación emergentes.” Adicional a ello, indica que debe considerarse el rol de un Oficial de Seguridad de Información, que dependiendo del tamaño o tipo de PMO puede ser un rol dentro de la PMO o debe ser un personal de IT que forme parte como consultor, tal como se observa en el extracto siguiente. “… no sé si tomas en cuenta los temas de seguridad de información, acá un rol importante sobre cualquier proyecto… El tema es que antes no se tomaban en cuenta, porque no teníamos un universo tan automatizado o no nos estábamos pasando tanto en la tecnología como para para sacar una ventaja sobre los demás, ahorita no, ahorita todos estamos en eso y así como han crecido el área tecnológica en todas las áreas, en todas las empresas. También ha 109 crecido el tema de ciberseguridad, de delitos informáticos, de hackeo y tenemos que estar preparados para eso.” Experto 3: Para el Experto 3, el rol descrito en la propuesta es importante siempre y cuando la PMO sea del tipo Estratégica o de Tecnología. El tesista le corrobora el contexto de la propuesta, el cual se orienta a PMO que gestionan proyectos de TI para una organización de cualquier industria. Con esa aclaración el Experto 3 confirma la importancia del rol propuesto. A continuación, se presenta el extracto de su respuesta. E3: Es que ese rol en particular, tal y como lo estás describiendo, me parece importante para una PMO de tecnología o quizás hasta para una PMO estratégica, pero si es la PMO de un área específica, la cosa cambia. BM: Bueno, en realidad la PMO está pensada para gestionar proyectos de TI en cualquier organización, ahí va enfocado. E3: Ahora sí, ahí sí. Adicional a ello, el Experto 3 sugiere que el nombre sea cambiado de jefe de proyecto a otro de más alto nivel. Como por ejemplo a un Oficial de Innovación. Se presenta el extracto de su respuesta al respecto. E3: Solo que no lo llamaría jefe de proyectos. BM: ¿Cómo lo denominaría? … BM: Habría que buscarle un nombre, “un oficial de innovación” algo así. E3: Podría ser. 8.2.2 Definición de estructura de Gobierno y Escalamiento Sobre la definición del proceso de priorización de proyectos por parte de la PMO, se obtuvieron las siguientes apreciaciones de los expertos entrevistados: Experto 1: El Experto 1 concuerda que la PMO debe tener una estructura de gobierno y dependerá del nivel de autoridad que tenga para tomar decisiones. El proceso de priorización es adecuado si la definición de los pesos de los criterios la realiza el negocio. En su opinión, 110 es correcto que la PMO realiza todo el proceso de priorización de proyectos, pero solo debe presentar a los Directivos el resultado y obtener de ellos la aprobación. Recomienda que se organice un workshop con los Directivos para presentarle los resultados y que ellos modifiquen o confirmen la lista para que la PMO pueda iniciar la ejecución de los proyectos. Finalmente, sugiere revisar otros procesos de priorización como el AHP. A continuación, se muestran extractos de su respuesta: “Puede ser que la PMO tenga dentro de sus funciones gestionar un portafolio perfecto, pero que tome las decisiones, eso va a depender que tanta autoridad le den. Lo que la práctica de dirección del portafolio se propone es de que hay un cuerpo de gobierno que es el que toma la decisión y ya sea el director de portafolio, que forma parte de la PMO, o por fuera el asesor es el cuerpo gobierno para tomar decisiones. En resumen, a que voy, por ejemplo: Viene la priorización de los proyectos e imagínate que la PMO va a gestionar el portafolio, lo que hace el director de portafolio es hacer una corrida en base a los criterios, puntajes que se asignan y se plantea una priorización inicial, que después es validado con el cuerpo de gobierno ¿Por qué? Porque, normalmente un portafolio tiene decisiones de negocio y los que mejor conocen el negocio no es la PMO, los que mejor conocen del negocio son o deberían ser esos BP de marketing, de finanzas de operaciones y por ahí está el gerente general. … Lo que se estila, es tener un taller, un workshop, en el cual te reúnes con los líderes, con ese cuerpo de gobierno, es un taller de facilitación, donde, acá señores, se tiene la planilla inicial de priorizaciones, empecemos a conversar y si se tiene ahí, se tiene un trabajo colaborativo.” Experto 2: El Experto 2 también concuerda que la PMO debe ejecutar el proceso de priorización de proyectos y que dependerá de su nivel de autoridad para la toma de decisiones. Al igual que el Experto 1, considera que la PMO debe entregar la lista de proyectos priorizados para que los Directivos tomen la decisión de aprobar esa lista o hacerle modificaciones. Adicional a ello, considera que la PMO debe definir una política donde se establezca el procedimiento de priorización, la lista de proyectos que entrega y la lista que recibe. A continuación, se presentan extractos de la respuesta del Experto 2. “Sí lo debe hacer, la PMO debería tener un área qué nos categorice los proyectos… 111 … tiene que ver mucho también la estructura de la empresa en cuanto a lo que te dije hace rato, la naturaleza de la empresa en cuanto a la toma de decisiones. Esto está perfecto y es el deber, ser en cuanto al modelo PMI verdad, pero qué pasa si la empresa no está tan madura como para seguirlo. … Creo que deberías tener una sección aparte o aparte no, incluida acá y que te diga que dependiendo de la toma de decisiones que tenga la empresa o la madurez que tenga la empresa para tomar decisiones … porque muchas veces no van de la mano la empresa y la PMO…” Con respecto a los niveles de escalamiento, considera importante definirlos sin embargo añade que debería tenerse en consideración también el momento en el que se escala, tal como lo menciona en su respuesta. “Mira, aquí hay un punto importante que deberíamos tomar en cuenta es también la fase del proyecto en el que tú deseas de escalar algo. Normalmente tenemos un nivel de escalamiento 2D a un nivel de escalamiento 3D, porque en una arista tendríamos las X, sería por decir algo del nivel de escalamiento de las posiciones y en la Y tendríamos que estamos escalando y vamos subiendo a medida de qué factores se cumplen ¿Pero en qué fase del proyecto vamos a escalar algo? No es lo mismo escalar un cambio de alcance en fase inicial, a un cambio alcance en la que en la fase de implementación. Entonces ¿Aplicaría para la fase de implementación un nivel escalamiento igual que en la fase de inicio del proyecto?” Respecto a los procesos de comunicación, está de acuerdo con lo planteado, pero recomienda que se asegure el cumplimiento. A continuación, se presenta un extracto de su respuesta. “… realmente lo que sugiero aquí es que se cumpla, es lo más importante, que se cumplan los procesos de comunicación en las diferentes áreas y en las diferentes fases, porque es tan sencillo como lo plasmas acá, pero puede ser tan difícil hacer que se cumpla como no tienes idea, básicamente es eso.” Experto 3: El Experto 3 considera que la PMO sí debe incluir el proceso de priorización de proyectos pero que el Directorio debería estar involucrado en la priorización ya que ellos 112 son finalmente los que aceptan o no la priorización. Se presenta a continuación un extracto de su respuesta. “… Sí… Lo que pasa, es que, más que pasárselo al directorio, yo considero, que el directorio debería estar involucrado en la priorización. … hay criterios que escapan a la parte objetiva y ese es el otro tema, cada empresa tiene sus propios criterios. … Al final, lo que se puede hacer objetivamente, es una sugerencia que puede o no ser aceptada por el directorio...”. Adicionalmente, sobre el escalamiento de incidentes considera que la propuesta es similar a la normalmente se trabaja en PMO. Sugiere agregar un nivel de escalamiento entre el Gerente de TI y el Gerente General, que podría ser el sponsor del proyecto. A continuación, se presenta un extracto de su respuesta. “Básicamente, el esquema es similar con una particularidad. No creo que el último nivel sea la gerencia general o, mejor dicho, creo que hay un nivel intermedio, que es justamente algún director o básicamente el sponsor que está impulsando los proyectos, que no necesariamente es el gerente general.” Finalmente, sobre el proceso de comunicaciones el Experto 3 considera que la propuesta es adecuada. Sin embargo, agregaría un ítem de comunicación que sería que la PMO debe comunicar a los jefes de proyectos los aportes y aportes de cada proyecto al objetivo de la organización. Se muestra el extracto de su respuesta a continuación. “Yo creo que sí aportan, ahí lo que va a cambiar es la forma, la frecuencia en que comunicas toda esa información. Ahora hay una que sí me parece crítica, que no la veo en la lista, que es la comunicación de la PMO hacia el jefe del proyecto sobre el valor o el aporte que tiene su proyecto a los objetivos de la organización.” 8.2.3 Definición de funciones Sobre la definición de funciones de la PMO, se obtuvieron las siguientes apreciaciones de los expertos entrevistados: Experto 1: El Experto 1 está de acuerdo realizar auditorías si es que forma parte de los servicios encargados a la PMO, tal como lo menciona en la entrevista. 113 “Ahí va a depender también el servicio que hagas, si funcionan auditorías, también tiene que haber.” Respecto a las funciones relacionadas a la gestión de recursos, considera que debe considerarse definir la línea de carrera de los miembros de la PMO, además de buscar homologar y evaluar el conocimiento de la PMO por lo que una buena práctica sería contratar a personas con la certificación PMP por ejemplo. Por política debe definirse un programa anual de capacitación. A continuación, se presentan algunos extractos de su respuesta. “… homologas conocimiento. Después, otro punto importante es que ellos tienen una línea de carrera, eso también es importante definir, pero también va a depender un poco de la organización… Nos pidieron evaluar el conocimiento técnico y las competencias de sus project managers o de las personas que asumen el rol… … tienen su línea de carrera, tienen módulos de capacitación que tú vas tomando en base a la posición que tú posees y que estos módulos están asociados a las competencias planteadas que debe tener un project manager, qué obviamente se basan en lo que plantean los estándares, pero también que conviven con sus competencias y valores propios de la corporación. Sí es importante contar con programas anuales de capacitación, que sean maduros porque eso fomenta lo que es la gestión del conocimiento y la madurez que va a tener la empresa. Bueno al final, la madurez organizacional de proyectos que va a tener la empresa.” Experto 2: El Experto 2 considera que las funciones que se indican deben considerarse para cualquier tipo de PMO. También hace hincapié en las funciones relacionadas a Gestión de Recursos. Sugiere que la PMO debe también estar en la capacidad de comunicar o dar visibilidad del proceso de contratación, sobre todo si se presentan demoras. La PMO debe tener la capacidad de armar los equipos y desarrollarlos. Se presentan a continuación unos extractos de su respuesta. “… son necesarias para cualquier PMO y obviamente si lo necesita un proyecto lo va a necesitar una PMO obviamente… … Para reclutar y en qué estatus va, no el proceso que se está siguiendo, sino en qué estatus… ¿cuánto demora recursos humanos para contratar a alguien? Estamos 114 conscientes de que nos vamos a demorar tanto tiempo o cantidad de días o cantidad de meses en reclutar a alguien, eso hay que comunicarlo y mucho más obviamente si los proyectos dependen de eso… … por ejemplo en el tema de utilización de recursos, la utilización de recursos, el contenido mensaje está bien. Yo recomendaría el estatus de los recursos, estatus de los recursos, porque también aquí abajo estás recomendando que vamos de la mano con recursos humanos a contratar el personal adecuado.” Experto 3: El Experto 3 considera que es mejor presentar las funciones de la PMO respecto al tipo de PMO a implementar. También, que la función de auditoría sí es importante que se contemple en la PMO. A continuación, se presenta un extracto de su respuesta. “La PMO, tiene en realidad múltiples funciones, pero depende de qué tipo de PMO vaya a implementar la organización. En general, cuando yo implemento PMO en una empresa, lo primero que les pregunto es ¿Qué tipo de PMO quieres tener? Porque en base a eso, se definen las funciones; una cosa es una PMO estratégica, otra es una PMO de seguimiento, otra cosa es una PMO orientada al tema de aprendizaje, conocimiento. Claro que pueden tener todas, pero usualmente, eso es mucho, dependiendo del tamaño la empresa. … dependiendo de la empresa y de la estructura que está manejando, las funciones pueden cambiar ligeramente, pero el tema de auditoría sí tiene sentido que las realice la PMO.” 8.2.4 Definición de métricas de medición Sobre la definición de métricas en la PMO, se obtuvieron las siguientes apreciaciones de los expertos entrevistados. Experto 1: El Experto 1 considera que es importante que se midan los beneficios que se obtienen de los proyectos. Esto facilita al Negocio la decisión de seguir o no con los proyectos. Como buena práctica sugiere que las métricas de gestión se midan a la mitad y al final del proyecto. A continuación, un extracto de su respuesta. 115 “… el de beneficios es importantísimo, porque, al final los proyectos se hacen con la intención de obtener beneficios y el punto es de que esos beneficios tienen que estar plasmados en el caso de negocio del proyecto, ahí deberían estar plasmados, actualizados, si hubo cambios en el contexto. Pero después lo que se tiene que medir es el logro de esos beneficios. Esa métrica sí es importantísima porque aparte de obtener la métrica hay que reportar el logro de beneficios o el estatus que tiene porque te puedes encontrar con proyectos que están siendo implementados, le estás metiendo plata por mantenimientos, upgrades, lo que tú quieras, pero realmente no te están generando lo que tú necesitas. … puede haber proyectos bien hechos, te lo entregaron a tiempo, siempre con el presupuesto acorde, con el alcance que se pidió, pero de repente no te está generando lo que te espera y encima le están metiendo plata, por mantenimientos que haces. … nosotros manejamos dos encuestas, por cada proyecto a la mitad y al final, donde una de las cosas que se evaluaba era el nivel de gestión que tenía el project manager. Aparte de auditar, lo que hacía era, tener encuestas de satisfacción para poder determinar, qué tan buen desempeño se estaba dando en el proyecto, por la gestión propia del project manager, la comunicación que se daba, la opinión que tenían los interesados del proyecto. … ¿Por qué a la mitad? Porque te permite hacer ajustes, conversar con ese project manager…” Considera que tan importante a la definición de métricas es contar con el equipo que ayude a medirlas. Se muestra el extracto de su respuesta. “Entonces, ahí viene la gran pregunta ¿Quién lo hace? … necesitas a alguien que te ayude a consolidar esa información y eso es bien importante.” Experto 2: El Experto 2 considera que la definición de estas métricas es correcta sin embargo dependerá del nivel de madurez y la cultura de la organización que se cumplan con las mediciones. A continuación, se muestran extractos de su respuesta. “… dependiendo de la madurez de la empresa, porque puedes puede haber empresas que te digan: Sabes, no me importa que estén alineados a la estrategia organizacional, no me importa que lo midas, sino porque son imperativos los proyectos o por ejemplo: 116 Mira, me interesa porque esta es una estrategia a largo plazo y esto es uno de los tantos proyectos que van sobre la estrategia a largo plazo y quiero ver cuál es el avance, en cuanto a cumplir o a seguir nuestra estrategia organizacional…” Experto 3. El Experto 3 considera que la definición de métricas es correcta, sobre todo debe evaluarse el nivel de satisfacción del cliente final. A continuación, se presenta un extracto de su respuesta. “Claro que sí… … yo particularmente creo que es más responsabilidad de la PMO … evaluar el nivel de satisfacción de tu cliente final, que en este caso serían las áreas funcionales.” 8.2.5 Definición de proyección de crecimiento (modelo de madurez) Experto 1: El Experto 1 encuentra correcta la definición de los niveles de madurez que se proponen. Recomienda que la PMO debe generar resultados exitosos para que su imagen y prestigio cale en la organización. A continuación, se presentan extractos de su respuesta. “… tú vayas logrando esa madurez, es decir de pasar procesos muy manuales o donde realmente tu influencia es muy baja, hasta pasar a procesos automatizados con una influencia bastante alta, personalmente para mí ese modelo funciona muy bien. … para que una PMO empiece a calar dentro de una organización, primero se instala en base a lo que se necesita… … la gente empieza a creer en ti cuando ve resultados … tienen que ser los referentes de gestión de proyectos de la empresa… Cuando a mí me preguntan un poco cuál es el camino natural, yo lo que siempre propongo es, primero parte de lo que necesita tu empresa, ahora disponiéndome el caso de una empresa corporativa, empieza una PMO departamental y que demuestre goles, que muestre beneficios logros, y luego esto va a ir decantando y subiendo.” Recalca que debe buscarse siempre la mejora continua en la PMO y que las lecciones aprendidas sean realmente aprendidas, tal como el extracto que se presenta a continuación. 117 “… después sacar la política de que cada proyecto aprobado venga con revisión de informe de lecciones aprendidas. Y que luego, al cierre del proyecto o periódicamente, se validen de que los problemas que se hayan presentado en el desempeño del proyecto no repliquen los problemas encontrados en las lecciones aprendidas, porque se supone que, si es lección aprendida, no debiste haber repetido el mismo problema… ¿Cómo te aseguras que la lección aprendida fue finalmente aprendida?” Experto 2: El Experto 2 está de acuerdo con la definición de los niveles de madurez de la PMO. Sugiere que deben definirse métricas por cada nivel que ayude a la PMO a saber si ha llegado al siguiente nivel de madurez o no y cuánto le faltaría para ese fin. Se presenta un extracto de su respuesta a continuación. “… está bastante entendible y también capaz los indicadores que tienes arriba en la primera parte les pueden servir si no es a todos, a más de una de estas fases, de estos niveles y capaz dependiendo de por ejemplo este nivel de formación en gestión de proyectos, bueno si llegas a una puntuación de 2 estás en la fase inicial, pero si llegas a 5 estás en la fase de repetible o si llegas a las 7 están definidos.” Experto 3: El Experto 3 considera adecuado el nivel de madurez propuesto. Sin embargo, hace la recomendación que el nivel de madurez de la PMO también debe incluir el nivel de madurez de gestión de proyectos. A continuación, se muestran extractos de su respuesta. “… yo el nivel de madurez, no lo veo a nivel de la PMO, lo veo a nivel de gestión de proyectos. Es decir, para mí es el nivel de madurez de la organización en lo que a gestión de proyecto se refiere, que involucra la gestión de los proyectos individuales más la PMO. Porque si sólo evalúo la PMO y dejó de lado la gestión de los proyectos, entonces, por más que mi PMO funcione bien, los proyectos pueden estar mal… Primero evalúa que, en la organización, los proyectos realmente se estén gestionando y luego después de que pasas el nivel de gestión de proyectos recién entras a un nivel de gestión de portafolio, que es donde encaja más la PMO.” 118 De las entrevistas realizadas a los tres expertos, se puede apreciar que existe un consenso entre ellos de validar la segunda propuesta de marco de trabajo para implementar una PMO. En el caso de agregar el nuevo rol de Jefe de proyectos de innovación (u Oficial de Innovación) dentro de la organización de la PMO, los expertos concuerdan que sería de gran utilidad ya que es importante que se cuenten con conocimientos de las últimas tecnologías para aplicarlas en la organización. Uno de ellos apunta que este rol cobra mayor sentido cuando la PMO ejecuta proyectos de TI. Finalmente, uno de los expertos también sugiere que exista un rol de Oficial de Seguridad en la PMO, alineado a la importancia que está tomando este tema dentro de las organizaciones. En el caso de que la PMO defina los procesos de priorización de proyectos y escalamientos de incidentes, los tres expertos concuerdan que la PMO debe definirlos y ejecutarlos. Uno de ellos acota que dependerá del nivel de autoridad que posee dentro de la organización. También sugieren que la prioridad de ejecución de proyectos definida por la PMO debe ser finalmente validada por el Negocio. En el caso de los escalamientos, uno de los expertos menciona que el escalamiento puede tomar un esfuerzo distinto dependiendo de la etapa de ejecución del proyecto donde suceda el incidente. Otro experto sugiere que debe añadirse un nivel más entre la Gerencia General y la PMO, que podría ser un Directivo o sponsor. En cuanto al proceso de comunicación, todos concuerdan en que el punto más importante es que realmente se ejecute durante el ciclo de vida del proyecto. Con el punto de agregar a la PMO nuevas funciones relativas al conocimiento, control y gestión de recursos, los expertos también llegan a un consenso, sobre todo con la ejecución de auditorías y de fortalecer la gestión de recursos alineados a definir líneas de carreras. Uno de los expertos hace notar que, si bien estas funciones son adecuadas, debe primero tomarse en consideración el tamaño de la PMO y el tipo (p.e. si es estratégica). Con el tema de agregar nuevas métricas de medición, orientadas a conocer si los proyectos ejecutados logran o no los beneficios esperados, los expertos concuerdan en que es importante contar con ellas. Uno de los expertos rescata que estas mediciones le permitirán a la organización tomar la decisión de continuar o no con un proyecto si no cumple con los beneficios esperados. Otro experto anota que estas mediciones se logran cuando la organización cuenta con un nivel de madurez adecuado. 119 Finalmente, con la definición de un modelo de madurez para la PMO, los tres expertos concuerdan que es importante porque a medida que la PMO aumenta su nivel, puede mostrar sus logros y mejorar su imagen en la organización. Otro experto, sugiere que adicionalmente se añadan métricas que ayuden a medir si se va logrando un nuevo nivel. Otro experto comenta que el nivel de madurez debe enfocarse más a nivel de la gestión de proyectos ya que eso en consecuencia afectará a la PMO. 120 Capítulo 9. Propuesta mejorada para implementación de una PMO En base a la evaluación cualitativa descrita en el capítulo anterior, donde los tres expertos coincidieron en indicar que la segunda propuesta realmente es de valor para la organización, también hicieron notar sugerencias y comentarios con el fin de mejorar la propuesta. Es por esa razón que, en el presente capítulo, se presenta la segunda propuesta de implementación con las mejoras sugeridas por los expertos entrevistados. 9.1 Visión general de la propuesta mejorada A continuación, se presenta un resumen con los puntos añadidos en cada sección de la propuesta de implementación: Sección Definir roles y responsabilidades Se añade el rol de Oficial de Innovación y se cambia el nombre del rol a Oficial de Innovación y Desarrollo Sección Definir estructura de Gobierno y Escalamiento Se añade la recomendación de que la definición de los categorías, criterios y pesos para la evaluación debe ser realizada por el Directorio. Además, que el Directorio debe participar activamente en el proceso de priorización de proyectos, siendo este la última instancia para la aprobación final de los proyectos priorizados. Para el Proceso de escalamiento se añadió un nuevo nivel entre la Gerencia General y el Gerente de TI. Para el Proceso de Comunicaciones se agrega un nuevo ítem de comunicación y se hace la recomendación de que se busquen mecanismos de cumplimiento de la matriz de comunicaciones. Sección Definir funciones Se recomienda que las funciones presentadas en la propuesta se implementen cuando se tiene una PMO de tipo: Control o Directiva. Adicionalmente, se refuerza la importancia de las funciones relacionadas a la gestión de los recursos humanos de la PMO. Sección Definir métricas de medición 121 Se modifican las métricas que permiten medir las expectativas de los stakeholders de los proyectos. Esto permitirá medir el nivel de satisfacción de los stakeholders tanto en la gestión de proyectos como en el logro de los objetivos de los proyectos. Sección Definir proyección de crecimiento (madurez) Se añade la recomendación de que el nivel de madurez óptimo se logra cuando se tiene un equilibrio entre el nivel de madurez en la gestión de proyectos y el nivel de madurez de la PMO. En los siguientes puntos se detallan cada una de las secciones mejoradas con las recomendaciones de los expertos. 9.2 Definir roles y responsabilidades En esta etapa de la implementación, se definen dos nuevos roles dentro del equipo de la PMO. Esta nueva definición se basa en la necesidad de la organización de contar con un interlocutor entre la PMO y las unidades de negocio en temas de innovación. Oficial de Innovación y Desarrollo. Este rol se identifica también en la literatura, siendo recomendado por Kummamuru (Kummamuru & Hussaini, 2016). Esta posición tiene como responsabilidad realizar prospección de nuevas tecnologías y analizar su factibilidad de aplicarlas en la organización. Promueve además reuniones alineadas a los objetivos de Digitalización e Innovación de la Organización, donde no solo promueve que los principales stakeholders propongan iniciativas innovadoras, sino presenta las novedades tecnológicas para evaluar en conjunto su viabilidad de implementación en la Organización. Oficial de Seguridad de la Información. Este rol se encargará de identificar áreas de mejora, corregir vulnerabilidades, actualizar políticas, ejecutar evaluaciones. Para este fin desarrolla un plan de acción para cerrar las brechas de seguridad, gestionar los presupuestos, realizar el seguimiento y control de los proyectos. 9.3 Definir estructura de Gobierno y Escalamiento Como parte de la definición de una PMO es importante definir los procesos de priorización de proyectos, comunicación y de solución de incidentes que sucedan durante la ejecución de los proyectos. 122 9.3.1 Proceso de priorización de proyectos En esta segunda propuesta se define el proceso de priorización de proyectos. Para realizar la priorización de proyectos que llegan a la PMO, se define un proceso adaptado que se basa en el Estándar de la Gestión de Portafolio del PMI (Project Management Institute, 2013b). A continuación, se presentan las actividades del proceso de priorización de proyectos: Identificación de proyectos. Se genera un inventario de proyectos que recibe la PMO. Este inventario contiene información que se consigna en el documento de especificación de requerimientos. Categorización de proyectos. Luego de identificar todos los proyectos, se procede a categorizarlos de acuerdo con los siguientes criterios: • Requerimiento legal • Requerimiento del Negocio • Mejora de procesos • Automatización de procesos Esta definición de criterios es realizada por el propio negocio, por los gerentes de las áreas funcionales y/o el directorio, no la realiza la PMO. Adicionalmente, esta definición es importante porque permitirá realizar la puntuación de los proyectos en la fase siguiente de evaluación. Evaluación de proyectos. Para la evaluación de los proyectos se definen los criterios y sus respectivos puntajes. Se sugiere usar tres niveles para la evaluación usando puntajes que van de 0 a 10. Todos los puntajes y pesos de las categorías son definidos por el propio negocio. En la siguiente tabla se presenta un ejemplo. Tabla 44. Ejemplo de Niveles de Puntaje Puntaje Evaluación Bajo 0 Medio 5 Alto 10 123 Luego se definen los puntajes para las categorías de los proyectos. Cada categoría debe tener un puntaje dentro del rango definido. Puede ocurrir que por mandato de la Organización alguna categoría siempre tenga el puntaje más alto, por ejemplo, si son Requerimientos Legales. En la Tabla 45, se muestra un ejemplo de cómo se asignan los puntajes a las distintas categorías identificadas. Tabla 45. Ejemplo de Puntaje por Categorías Categoría Evaluación Requerimiento Legal 10 Requerimiento de Negocio 5 Mejora Procesos 5 Automatización Procesos 5 En una siguiente etapa, se definen los pesos por cada criterio que se aplicarán a los proyectos a evaluar. En la Tabla 46 se muestran algunos ejemplos de criterios y sus respectivos pesos que se asignan. Tabla 46. Ejemplo de Pesos por criterios Con todas esas definiciones, se listan los proyectos que se evaluarán. Para cada proyecto se asignan los niveles de evaluación. Por ejemplo, si el proyecto está muy alineado a los objetivos estratégicos de la Organización de implementación se asigna un puntaje de 10. Si por el contrario el proyecto no aporta a los objetivos estratégicos, Nro. Criterio Criterio Peso 1 Alineación estratégica 30% 2 Costo 20% 3 Plazo 20% 4 Categoría 30% 124 se asigna un puntaje de 0. Si el proyecto está medianamente alineado se le asigna el puntaje de 5. En la Tabla 47, se muestran los proyectos y sus respectivos puntajes. Para calcular el total, se multiplican los puntajes por los pesos correspondientes de cada criterio. Tener en cuenta que, para los criterios de costos y tiempo, los puntajes se restan. Por ejemplo, para obtener el puntaje total del proyecto PR001, se siguió la siguiente fórmula: Total = 10*0.3 – 10*0.2 – 5*0.2 + 10*0.3 = 3.0 Tabla 47. Ejemplo de Proyectos evaluados Código Alineam. Estratégico Costo Plazo Categoría Total PR001 10 10 5 10 3.00 PR002 10 5 5 5 2.50 PR003 5 10 5 5 0.00 PR004 5 5 5 5 1.00 PR005 5 10 10 10 0.50 PR006 10 5 0 10 5.00 PR007 0 10 10 5 -2.50 PR008 5 5 10 5 0.00 PR009 10 0 5 5 3.50 PR010 5 5 5 5 1.00 PR011 5 0 5 5 2.00 Priorización de proyectos Con el listado de proyectos puntuados, se procede a ordenarlos para conocer cuáles son los que obtuvieron mayor puntaje, este resultado se observa en la Tabla 48. 125 Tabla 48. Ejemplo de Proyectos ordenados por puntaje Código Alineam. Estratégico Costo Plazo Categoría Total PR006 10 5 0 10 5.00 PR009 10 0 5 5 3.50 PR001 10 10 5 10 3.00 PR002 10 5 5 5 2.50 PR011 5 0 5 5 2.00 PR004 5 5 5 5 1.00 PR010 5 5 5 5 1.00 PR005 5 10 10 10 0.50 PR003 5 10 5 5 0.00 PR008 5 5 10 5 0.00 PR007 0 10 10 5 -2.50 La PMO debe definir como política cuál será el puntaje mínimo que se tomará en cuenta para considerar un proyecto como prioritario. Por ejemplo, para este caso en la PMO solo se priorizarán los proyectos que obtienen un puntaje mayor o igual a 1. Sin embargo, para este escenario se observa que el proyecto PR005 tiene un alto valor en el criterio Categoría, esto se debe a que se trata de un Requerimiento legal. Por esa razón, el Comité de la PMO igual considerará ese proyecto dentro del grupo de prioritarios. Con esa directiva establecida, se procede a elaborar una tabla de doble entrada para analizar la prioridad de los proyectos. Este análisis se realiza evaluando proyecto por proyecto. En la Tabla 49 se muestra el resultado de este análisis. 126 Tabla 49. Ejemplo de Evaluación de priorización de proyectos PR006 PR009 PR001 PR002 PR011 PR004 PR010 PR005 Total PR006 1 0 1 1 1 1 1 6 PR009 0 0 0 1 1 1 1 4 PR001 1 1 1 1 1 1 1 7 PR002 0 1 0 1 1 1 1 5 PR011 0 0 0 0 1 1 0 2 PR004 0 0 0 0 0 0 0 0 PR010 0 0 0 0 0 1 0 1 PR005 0 0 0 0 1 1 1 3 Al ordenar la tabla, se pueden observar los puntajes obtenidos por proyecto. Los proyectos con mayor puntaje son los que tienen mayor prioridad y por ende son los que empiezan a ejecutarse primero. El resultado final se muestra en la Tabla 50. Una vez definido el orden de ejecución de los proyectos, se procede a revisar si los proyectos se encuentran balanceados. El Comité de la PMO debe definir estos lineamientos. A continuación, como parte de este ejemplo se considera que los proyectos seleccionados están balanceados cuando: • Atienden los requerimientos de diversas Unidades de Negocio • La inversión se distribuye entre las distintas Categorías de proyectos Siguiendo con el ejemplo planteado, se asocia cada proyecto con el área de negocio donde se ejecutará. En la Ilustración 19 se muestra cómo se distribuye la inversión de los proyectos por las distintas unidades de negocio de la organización. Se observa que todos los proyectos priorizados atienden requerimientos de todas las Unidades de Negocio. 127 Tabla 50. Ejemplo de Proyectos priorizados Proyecto Puntaje PR001 7 PR006 6 PR002 5 PR009 4 PR005 3 PR011 2 PR010 1 PR004 0 Ilustración 19. Inversión de proyectos por Unidad funcional. Elaboración propia. Del mismo modo, se observa en la Ilustración 20 que la inversión en los proyectos está distribuida casi equitativamente entre las distintas categorías contempladas por la PMO. Finanzas Operaciones Ventas Atención al Cliente 0 0.5 1 1.5 2 2.5 3 3.5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 Inversión por Unidad de Negocio 128 Ilustración 20. Inversión en proyectos por Categoría. Elaboración propia. Con todo el análisis culminado, el Comité de la PMO procede a enviar el resultado de este proceso al Directorio para que ellos finalmente lo revisen, actualicen (si lo consideran) y autoricen los proyectos, asignando los recursos correspondientes en cada caso. Este nuevo proceso, se añade al proceso de solicitud de nuevos requerimientos. En la Ilustración 21 se muestra esta actualización Req. Legal Automatización Mejora de procesos Req. Negocio 0 0.5 1 1.5 2 2.5 3 3.5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 Inversión por Categoría 129 Ilustración 21.Proceso actualizado de Solicitud de nuevos requerimientos. Elaboración propia. Lí d e r Fu n ci o n a l G er en te Fu nc io na l C o m it é D ir ec ti vo P M O Je fe d e Pr oy ec to s D ir ec to ri o Elaborar especificación de requerimientos Solicitar aprobación de fondos Aprobar fondos ¿Aprobado? Sí Priorizar proyecto Ejecutar proyecto Autorizar proyecto No Evaluar viabilidad ¿Viable? Sí No De acuerdo con la sugerencia de expertos, se recomienda que el Directorio participe activamente en el proceso de priorización de proyectos juntamente con el Comité Directivo de la PMO. 9.3.2 Proceso de escalamiento El Comité de la PMO define la siguiente estructura de escalamiento: Primer nivel, todo incidente debe resolverse internamente con el equipo del proyecto y la decisión final la tiene el jefe de proyectos. Segundo nivel, en caso el incidente no pueda resolverse en el primer nivel, se escala al Comité de la PMO, quien debe analizarlo y tomar una decisión al respecto. Tercer nivel, en caso el incidente no pueda resolverse en el segundo nivel, se escala al Gerente de TI, quien debe analizarlo para tomar una decisión al respecto. 130 Cuarto nivel, en caso el incidente no pueda resolverse en el tercer nivel, se escala con el Sponsor del Proyecto, quien debe tomar acción al respecto. Quinto nivel, en caso el incidente no pueda resolverse en el cuarto nivel, se escala al Gerente General, quien debe analizarlo y tomar una decisión al respecto. A continuación, se ilustran los niveles de escalamiento. Ilustración 22. Niveles de escalamiento en la PMO. Elaboración propia. Gerencia General Gerente de TI Comité de PMO Jefe de Proyectos Sponsor del Proyecto Es importante tener en cuenta que el escalamiento de incidentes debe también considerar la fase del proyecto en la que se necesita escalar. Cuando se tiene una fase avanzada de proyecto, se hace más complicado, por lo que se debe acudir a niveles más altos. 9.3.3 Proceso de Comunicaciones Como indica Kerzner (Kerzner, 2017), la mayoría de organizaciones se enfrentan al problema de cómo asegurar que la información crítica, como indicadores de gestión y factores críticos de éxito, sean conocidas por todos los miembros de la organización. Por su parte, Andrews (Andrews, 2014) propone que la comunicación de las prácticas, los procesos, los procedimientos y los mensajes aprendidos de toda la empresa se puede lograr a través de una variedad de métodos, como foros, seminarios web, notificaciones por correo electrónico, seminarios de capacitación o herramientas de 131 comunicación empresarial (boletines informativos, transmisiones web, etc.). También sugiere que el seguimiento y las mediciones del desempeño de la gestión de proyectos deben entregarse mediante el uso de datos del proyecto mantenidos por informes de tablero o sitios de intranet. La comunicación con la administración también debe realizarse a través de un ciclo de informes regular, ya sea semanal, mensual o trimestral. Debe contener informes no periódicos cuando las estimaciones de los proyectos se desvíen del plan. En base a estas recomendaciones, la PMO identifica que en la Organización los canales de comunicación más usados son: correo electrónico, video llamadas y boletín de noticias. Sin embargo, también identifica que las reuniones mensuales y trimestrales son un buen momento para compartir información de los logros de la PMO. Parte importante del proceso de comunicaciones es que la PMO asegure el cumplimiento de la ejecución de cada ítem detallado en esta matriz, logrando comunicar en el plazo establecido y a los destinatarios definidos. En la Tabla siguiente se muestra la matriz de comunicaciones de la PMO. Tabla 51. Matriz de comunicaciones de la PMO Contenido de mensaje Destinatario Canal de comunicación Frecuencia Responsable Reporte de avance Equipo de proyecto Correo electrónico Semanal Jefe de proyecto Utilización de recursos Equipo de proyecto Gerente de PMO Correo electrónico Video llamada Mensual Jefe de proyecto Indicadores de desempeño de proyectos Equipo de proyecto Gerente de PMO Video llamada Mensual Jefe de proyecto Lecciones aprendidas Equipo de proyecto Gerente de PMO Video llamada Mensual Jefe de proyecto 132 Contenido de mensaje Destinatario Canal de comunicación Frecuencia Responsable Decisiones de gobierno de PMO Gerente de PMO Gerente de TI Gerente Unidad Correo electrónico Video llamada Mensual Comité de PMO Actualización de riesgos e incidentes Gerente de PMO Gerente de TI Gerente Unidad Correo electrónico Video llamada Mensual Comité de PMO Indicadores de desempeño de PMO Gerente General Gerente de Unidad Correo electrónico Video llamada Trimestral Gerente de PMO Logros de proyectos Empleados Gerente de TI Gerente Unidad Correo electrónico Trimestral Gerente de PMO Aporte de los proyectos a objetivos organizacionales Jefes de proyectos Correo electrónico Video llamada Mensual Comité de PMO 9.4 Definir funciones En esta etapa de la implementación, se definen funciones adicionales de la PMO, siguiendo la categorización propuesta por Ayyagri (Ayyagari et al., 2006) encontrada en la literatura. Antes de definir estas funciones, se debe identificar primero el tipo de PMO que se tiene implementada en la organización. Esto tiene su fundamento en que las funciones que una PMO va a ejecutar cobrarán más sentido dependiendo de su tipo. Por ejemplo, las funciones que se presentan a continuación se pueden implementar más fácilmente cuando se tiene una PMO de Control o PMO Directiva. 133 9.4.1 Funciones relacionadas al Conocimiento En esta sección se definen las funciones asociadas a cómo se gestionará el conocimiento relativo a la gestión de proyectos dentro de la PMO y de la organización. Cumplimiento de estándares y métodos La PMO es responsable de cumplir y hacer cumplir los estándares y mejores prácticas para la ejecución de los proyectos. De esta forma, se busca aprovechar las mejores prácticas y garantizar que todos los equipos de proyectos puedan hablar en un mismo lenguaje con el Negocio. Acompañamiento de proyectos La PMO acompaña a todo el equipo del proyecto y a los principales stakeholders desde la elaboración del Acta de constitución del proyecto (Project charter) hasta el cierre de este, así como en la elaboración de todos los entregables. El acompañamiento incluye el seguimiento y control de proyectos, propiciando reuniones con los principales stakeholders llevando un registro de las actas correspondientes. Centralizar, coordinar y gestionar la comunicación entre proyectos. La PMO define el ambiente de colaboración que se usará para la comunicación de los avances y logros de los proyectos. En la organización se utilizará la Intranet, email y reuniones seguimiento por unidades de negocio que se llevan a cabo trimestralmente. El objetivo es compartir logros, experiencias exitosas y conceptos, con ejemplos prácticos de la metodología y/o buena práctica aplicada en los proyectos. De esta manera se logra la divulgación del estado de los proyectos y sus logros. 9.4.2 Funciones relacionadas al Control En esta sección se definen las funciones asociadas a cómo se controlará la ejecución de los proyectos, enfocándose en el control de las comunicaciones y el cumplimiento. Centralizar la información del estado del proyecto para la organización La PMO es responsable de monitorear la salud de los proyectos, llevando el control y registro de las principales incidencias, desviaciones o logros. Esto con el fin de luego comunicar oportunamente a los principales stakeholders. Realizar auditorías a los proyectos 134 La PMO define un plan de auditorías sobre el éxito de los proyectos, la eficacia de la gestión de proyectos, el valor y uso de la metodología y las herramientas, y el cumplimiento de los estándares y requisitos internos y externos. De esta forma se definen acciones correctivas cuando se encuentran desviaciones a los esperado. 9.4.3 Funciones relacionadas a la Gestión de recursos En esta sección se definen las funciones asociadas a la gestión de los recursos que se requieren para la exitosa ejecución de los proyectos. Gestionar las habilidades, la asignación y la capacidad de los recursos La PMO coordina estrechamente con el área de Recursos Humanos para la contratación de personal idóneo para el equipo de la PMO. Define además el perfil profesional y el plan de capacitación y entrenamiento que debe seguir como parte de su línea de carrera. Esta función tiene como objetivo optimizar la productividad del personal en los proyectos. Adicionalmente, mantiene comunicado a los principales stakeholders sobre el estado de los procesos de selección. Elaboración de presupuestos y seguimiento de gastos operativos y de capital del proyecto La PMO es responsable de definir los presupuestos de los proyectos, así como los presupuestos para el seguimiento de los proyectos y los gastos operativos. Es también responsable de rendir cuenta ante el Gerente de TI y los Gerentes de área de cómo se ejecuta el presupuesto y justificar cualquier desviación de este. 9.5 Definir métricas de medición En esta segunda etapa de implementación de la PMO, se definen indicadores de medición adicionales, los cuales se muestran en las Tablas 52 y 53. Tabla 52. Objetivos e indicadores Objetivo Indicador Facilitar la toma de decisiones proporcionando información oportuna y significativa sobre la gestión de los proyectos Porcentaje de cumplimiento en envío de informes de proyectos 135 Objetivo Indicador Gestionar las expectativas de los directivos y clientes internos de los proyectos Porcentaje de satisfacción del cliente respecto a la gestión del proyecto Porcentaje de satisfacción del cliente respecto a los objetivos alcanzados por el proyecto Establecer un marco de gobierno que facilite la priorización de proyectos Porcentaje de proyectos alineados a la estrategia organizacional Es importante tener en cuenta que los resultados que se obtengan de las mediciones de las métricas pueden brindarnos información valiosa para analizar si estamos caminando hacia un nivel superior de madurez de la PMO o no. 136 Tabla 53. Indicadores de medición Indicadores de gestión Fórmula de cálculo Objetivo Responsable Puntos de medición Frecuencia Sistema de información Meta Semaforización Registro Gestión Porcentaje de cumplimiento de envío de informes de proyectos # proyectos reportados / # proyectos totales Verificar que los resultados de proyectos se reportan oportunamente Gerente de proyecto Gerente de PMO Documentos de proyectos Mensual Sistema de información para la gestión de proyectos 90% Verde: >=90% Ámbar: >75% y <90% Rojo: <=75% Porcentaje de satisfacción de clientes respecto a la gestión del proyecto # clientes satisfechos / total de clientes encuestados Verificar la satisfacción de los clientes de la PMO Gerente de proyecto Asesor de Gerencia de proyectos Clientes de la PMO Mensual Sistema de encuestas 90% Verde: >=90% Ámbar: >80% y <90% Rojo: <=80% Porcentaje de satisfacción de clientes respecto a los objetivos alcanzados por el proyecto # clientes satisfechos / total de clientes encuestados Verificar la satisfacción de los clientes de la PMO Gerente de proyecto Asesor de Gerencia de proyectos Clientes de la PMO Mensual Sistema de encuestas 90% Verde: >=90% Ámbar: >80% y <90% Rojo: <=80% 137 Porcentaje de proyectos alineados a la estrategia organizacional # proyectos entregados alineados a la estrategia / # proyectos totales Verificar alineamiento de los proyectos de la PMO a los objetivos estratégicos Gerente de proyecto Gerente de PMO Objetivos estratégicos de la organización Objetivos del proyecto Mensual Balanced Score Card de la organización Sistema para la gestión de proyectos 90% Verde: >=90% Ámbar: >80% y <90% Rojo: <=80% 138 9.6 Definir proyección de crecimiento (madurez) El Instituto de Ingeniería de Software de la Universidad Carnegie Mellon, ha desarrollado un modelo de madurez para la Ingeniería de software y sobre la cual se ha desarrollado un modelo para la gestión de proyectos en forma de Modelo de Madurez de Gestión de proyectos, en inglés Project Management Maturity Model (PMMM). Este modelo ha recibido una amplia aceptación como estándar para el modelado de procesos y la evaluación de la madurez organizacional en varias áreas de procesos (Crawford 2002). El PMMM establece los siguientes niveles de madurez: Nivel 1. Inicial En este nivel algunos de los procesos son definidos y se cuentan con algunas herramientas de apoyo a la gestión. Sin embargo, el cumplimiento de los procesos y el uso de las herramientas no es ampliamente usado en los equipos de proyectos y en la misma PMO. Nivel 2. Repetible En este nivel se cuenta con la mayor cantidad de procesos de gestión de proyectos documentados y se fomenta el uso de estos desde la PMO. Se tienen identificadas y estructuradas las capacitaciones a los equipos de proyectos y se brindan a demanda. Nivel 3. Definido En este nivel todos los procesos de gestión de proyectos están documentados y los Gerentes de las áreas de negocio reconocen que la gestión de proyectos es una pieza clave en los logros de los objetivos de la organización. La PMO implementada formalmente toma la responsabilidad de evangelizar a los equipos de proyectos y garantizar que la metodología de gestión de proyectos se use en la organización. Nivel 4. Gestionado En este nivel se cuenta con un plan definido de entrenamiento y programa de desarrollo para los jefes de proyectos. La organización considera como un factor crítico de éxito a la gestión de proyectos. La definición del portafolio de proyectos forma parte importante dentro del plan estratégico de la compañía. Nivel 5. Optimizado En este nivel la PMO es un componente crítico en el proceso de mejora continua de la calidad para la gestión de proyectos. Se definen métricas que permitan visibilizar la 139 salud de los proyectos y que permita a los principales stakeholders tomar una decisión y actuar oportunamente. El Comité de la PMO propone que la implementación debe pasar por un proceso de crecimiento y maduración dentro de la compañía. Para ese fin, siguiendo la propuesta del PMMM, se adapta el modelo y se propone que la PMO debe pasar por los siguientes modelos de madurez mostrados en la tabla 54: Tabla 54. Niveles de madurez de la PMO Nivel de madurez Características de la PMO en el nivel actual Iniciativas que permitirán subir de nivel a la PMO Inicial (1) El proceso de gestión de proyectos no está totalmente definido. Se brinda apoyo a demanda a los equipos de proyecto. Escasa formación en gestión de proyectos. El Comité de la PMO establece y documenta el proceso de gestión de proyectos. Se define el plan de formación en gestión de proyectos y se pone a disposición Repetible (2) Se cuenta con el proceso de gestión de proyectos totalmente documentado. Se brinda apoyo a tiempo parcial a los equipos de proyecto. Formación en gestión de proyectos disponible pero limitada. Se definen estrategias para evangelizar en el uso de procesos de gestión de proyectos. Se asigna personal a tiempo completo para apoyar a los equipos de proyecto Supervisión y aseguramiento del cumplimiento de la gestión de proyectos. Se agregan tópicos avanzados para la formación de gestión de proyectos. 140 Nivel de madurez Características de la PMO en el nivel actual Iniciativas que permitirán subir de nivel a la PMO Definido (3) Proceso de gestión de proyectos totalmente documentado y respaldado. Se cuenta con personal a tiempo completo para el apoyo a equipos de proyectos. Todos los equipos están utilizando el proceso de gestión de proyectos. Los procesos de gestión de proyectos están integrados con otros procesos. Se encuentra disponible una formación de gestión de proyectos más extensa y avanzada. Los proyectos se hacen parte del plan de negocios. La PMO asume un papel activo en la contratación del personal del proyecto. Se definen diversas opciones de formación en gestión de proyectos Se define un programa de desarrollo profesional en la PMO. Los jefes de proyectos forman parte del equipo de la PMO. Gestionado (4) La PMO es responsable del desarrollo profesional de su personal. Se encuentra disponible un entrenamiento completo de gestión de proyectos. El portafolio de proyectos se gestiona como un negocio. La PMO comienza a identificar y adoptar las mejores prácticas. Se definen métricas para rastrear la calidad del proceso. Las revisiones de proyectos se utilizan para monitorear el cumplimiento. Optimizado (5) Existe un proceso de mejora continua. Se miden los criterios de éxito de todos los proyectos. Se definen auditorías para verificar el cumplimiento de los estándares y procesos de gestión de proyectos. 141 Es importante considerar que el nivel de madurez de la PMO se mide en base a dos componentes, el nivel de madurez en la gestión de proyectos y el nivel de madurez de en la gestión de las tareas de la PMO. El nivel óptimo de madurez es lograr un balance entre ambos. 142 Capítulo 10. Conclusiones y trabajos futuros En el presente capítulo se presentan las siguientes conclusiones luego de desarrollar el presente trabajo de investigación y los resultados tras las validaciones tanto cuantitativas como cualitativas. En la revisión de la literatura, si bien se evidencia que existen muchos trabajos que mencionan a las PMO como entidades que ayudan y facilitan la ejecución de los proyectos, son pocos los estudios donde se presenten implementaciones exitosas de PMO o propuestas de marcos de trabajo completos que aseguren una correcta implementación. Muchos autores proponen recomendaciones con algunos criterios a tomar en cuenta. Tampoco se encuentran propuestas de instituciones reconocidas en la gestión de proyectos. También se encuentran evidencias de algunos autores que abordan esta problemática, confirmando que no hay estándares o marcos de trabajo ampliamente difundidos para la implementación de PMO. Con las evidencias encontradas en la revisión de la literatura, se propone un marco de trabajo el cual se diseña recogiendo las recomendaciones de los autores y añadiendo criterios importantes que toda organización debe tomar en cuenta cuando se enfrente al reto de la implementación de una PMO. En esta primera propuesta se definen los siguientes criterios: • Evaluar necesidad de PMO • Evaluar riesgos en la implementación • Establecer visión, misión y objetivos de la PMO • Definir ubicación dentro de la organización • Definir roles y responsabilidades • Definir estructura de gobierno • Definir funciones • Definir métricas de medición Esta primera propuesta logró implementarse en una organización, es decir se definió una PMO para gestionar los proyectos de TI. Luego de la implementación, se procedió a evaluar los resultados obtenidos usando un método cuantitativo. Para este fin, se compararon 20 proyectos ejecutados en la organización antes de la PMO con 20 proyectos ejecutados después de la PMO. 143 Con una primera evaluación, lo que se buscó es determinar el estadístico que permita verificar si existen diferencias significativas entre los sobretiempos de ejecución de proyectos antes y después de la implementación de la PMO. Debido a que ambas muestras no siguen una distribución normal, se aplica la prueba de Mann-Whitney para comparar las medianas de ambas muestras. La primera prueba estadística que se realizó mostró que las medianas no son iguales. Se ejecuta una segunda prueba estadística para determinar si la mediana de los proyectos antes de la PMO es mayor que la mediana de los proyectos después de la PMO. El resultado de la prueba concluyó que en efecto la mediana de la primera muestra es mayor que la de la segunda. Esto quiere decir que los sobretiempos fueron mayores antes de implementar la PMO. Con una segunda evaluación, lo que se buscó es determinar el estadístico que permita verificar si existen diferencias significativas entre los sobrecostos de ejecución de proyectos antes y después de la implementación de la PMO. Debido a que ambas muestras no siguen una distribución normal, se aplica la prueba de Mann-Whitney para comparar las medianas de ambas muestras. La primera prueba estadística que se realizó mostró que las medianas no son iguales. Se ejecuta una segunda prueba estadística para determinar si la mediana de los proyectos antes de la PMO es mayor que la mediana de los proyectos después de la PMO. El resultado de la prueba concluyó que en efecto la mediana de la primera muestra es mayor que la de la segunda. Esto quiere decir que los sobrecostos fueron mayores antes de implementar la PMO. Es decir, se obtuvieron mejores resultados en tiempo y costos luego de implementar la PMO usando la primera propuesta. Luego, se diseñó una segunda propuesta de marco de trabajo tomando recomendaciones y puntos que no se consideraron en la primera propuesta de forma que la complemente. Esta nueva propuesta contempló: • Nuevo rol en la PMO • Nuevos procesos en el Gobierno de la PMO (priorización, escalamiento, comunicaciones) • Nuevas funciones • Nuevos indicadores de medición • Definir un modelo de madurez para la PMO 144 Esta segunda propuesta se evaluó usando un método cualitativo. Para ese fin se definió el protocolo de la entrevista y se contactó con 3 expertos en temas de gestión de proyectos y PMO. Los expertos son profesionales con más de 15 años de experiencia en la gestión de proyectos. Dos de ellos son profesores de importantes universidades, poseen múltiples certificaciones relacionadas a la gestión de proyectos y han formado parte de la Directiva de Capítulos de PMI en un país de Sudamérica. Otro de los expertos ha ejecutado proyectos de gran envergadura en distintas industrias y en distintos países. Al ejecutar las entrevistas, se revisó con cada experto todos los puntos de la segunda propuesta. De las entrevistas realizadas a los tres expertos, se pudo apreciar que existe un consenso entre ellos de validar la segunda propuesta de marco de trabajo para implementar una PMO. Adicionalmente, fue el momento propicio para que ellos sugirieran agregar algunos puntos adicionales para mejorar la segunda propuesta. Con las sugerencias que los expertos aportaron en la validación cualitativa, se incluyeron algunas mejoras a la segunda propuesta presentada en este trabajo. Estas mejoras no suponen un cambio radical en las propuestas sino son ajustes puntuales, siendo los más resaltantes: • Definir dos nuevos roles en la PMO • Incluir al Directorio de la Organización como la instancia final para aprobar la priorización de proyectos • Agregar un nuevo nivel de escalamiento • Agregar nuevas funciones de la PMO • Agregar nuevas métricas de medición • Agregar métricas de medición al modelo de madurez de la PMO A partir de los resultados obtenidos en el presente trabajo, se generan las siguientes publicaciones académicas las cuales fueron expuestas en congresos internacionales: • Validación cuantitativa de los resultados de la Implementación de una Oficina de Gestión de Proyectos en Tecnologías de la Información (Murillo & Pow-Sang, 2021) • A Systematic Mapping Review of PMO Frameworks (Murillo et al., 2022) Finalmente, como trabajos futuros se proponen: • Establecer sesiones de discusión con los resultados obtenidos luego de implementar el marco de trabajo, con el fin de identificar posibles mejoras, adaptaciones o 145 posibles usos adecuados del marco de trabajo de acuerdo con el tipo de organización o contexto. • Implementar una PMO en base a la segunda propuesta, con las mejoras sugeridas por los expertos, con el fin de poder realizar el seguimiento y revisión de los logros obtenidos. • Agregar nuevos indicadores como facilidad de uso, claridad del marco de trabajo para medir la efectividad de la propuesta. • Realizar el monitoreo de los indicadores para corroborar que la ejecución de los proyectos en la PMO logra alcanzar los objetivos planificados sin impactar negativamente en los costos, tiempos, alcance ni calidad. 146 Referencias Abdi, M. R., & Kaddoura, H. A. (2011). Projects Management Office: a case study for best practices. 2011 International Conference on Management and Service Science, 1–5. AlMajed, A. I., & Mayhew, P. (2013). Chief information officers’ perceptions of it projects success factors in Saudi Arabian public organiztions: An exploratory study. Proceedings of the IADIS International Conference Information Systems 2013, IS 2013, September, 95–102. Altuwaijri, M. M. (2008). A new model for successful CPOE deployment and implementation in hospitals. HEALTHINF 2008 - 1st International Conference on Health Informatics, Proceedings, 2, 179–185. https://doi.org/10.5220/0001044301790185 Altuwaijri, M. M., & Khorsheed, M. S. (2012). InnoDiff: A project-based model for successful IT innovation diffusion. International Journal of Project Management, 30(1), 37–47. https://doi.org/10.1016/j.ijproman.2011.04.007 Andrews, T. D. (2014). Starting Up and Enterprise-wide PMO. 2014 PMI Global Congress Proceedings, 1–10. Axelos. (2017). Managing Successful Projects with PRINCE2. Stationery Office Limited. Ayyagari, R., Henry, R. M., & Purvis, R. L. (2006). A conceptual framework of the alignment of the project management office (PMO) with the organizational structure. Association for Information Systems - 12th Americas Conference On Information Systems, AMCIS 2006, 6, 3729–3736. Bannerman, P. L. (2010). Managing structure-related software project risk: A new role for project governance. Proceedings of the Australian Software Engineering Conference, ASWEC, 129–138. https://doi.org/10.1109/ASWEC.2010.12 Beltran, J. M. (2005). Indicadores de Gestión, Herramientas para lograr la competitividad. Bogota: Panamericana. 147 Carrillo V, J., Abad E, M., Cabrera S, A., & Jaramillo H, D. (2010). Success factors for creating a PMO aligned with the objectives and organizational strategy. 2010 IEEE ANDESCON Conference Proceedings, ANDESCON 2010, September, 1–6. https://doi.org/10.1109/ANDESCON.2010.5629937 de Carvalho, M. M. (2014). An investigation of the role of communication in IT projects. International Journal of Operations and Production Management, 34(1), 36–64. https://doi.org/10.1108/IJOPM-11-2011-0439 Dronyuk, I., Moyseyenko, I., & Kuck, J. (2018). Information technologies for providing project-process management in law enforcement structures. 2018 IEEE 13th International Scientific and Technical Conference on Computer Sciences and Information Technologies, CSIT 2018 - Proceedings, 1, 76–79. https://doi.org/10.1109/STC-CSIT.2018.8526763 Eschler, J., Palkar, S., & Taylor, H. (2014). Transforming practice using theoretical framing to improve organization processes. 2014 47th Hawaii International Conference on System Sciences, 3421–3430. https://doi.org/10.1109/HICSS.2014.425 Fitzgerald, D. (2014). How to Avoid the “Seven Deadly Sins” of a Level 2 PMO. Gartner Analysis. https://www.gartner.com/en/documents/2809617 Flores-Ruiz, E., Miranda-Novales, M. G., & Villasís-Keever, M. Á. (2017). El protocolo de investigación VI: cómo elegir la prueba estadística adecuada. Estadística inferencial. Revista Alergia México, 64(3), 364-370. Frey, P., Lindner, F., Müller, A., & Wald, A. (2009). Project knowledge management organizational design and success factors - An empirical study in Germany. Proceedings of the 42nd Annual Hawaii International Conference on System Sciences, HICSS, 1–14. https://doi.org/10.1109/HICSS.2009.356 Gruhn, V., & Von Brisinski, N. S. (2020). How to reduce risk effectively in fixed price software development. Proceedings - International Conference on Software Engineering, 132–141. https://doi.org/10.1145/3377813.3381361 Hefner, R., & Ph, D. (2003). Aligning Strategies : Organizational , Project , Individual. 148 HICSS, 244. Hernández-Sampieri, R., Fernández, C., & Baptista, M. (2014). Metodología de la Investigación (6ta Edició). McGraw-Hill. Hobbs, B., & Aubry, M. (2007). A multi-phase research program investigating project management offices (PMOs): the results of phase 1. Project Manage Journal, 38(1), 74–86. International Organization for Standardization. (2012). ISO 21500:2012. Guidance on Project Management. ISO. International Project Management Association. (2015). Individual Competence Baseline: For Project, Programme & Portfolio Management. International Project Management Association (IPMA). Irfan, M., Hassan, M., & Hassan, N. (2019). The effect of project management capabilities on project success in pakistan: An empirical investigation. IEEE Access, 7, 39417–39431. https://doi.org/10.1109/ACCESS.2019.2906851 ISACA. (2012). COBIT 5: A business framework for the governance and management of enterprise IT. ISACA. IT Governance Institute. (2003). Board Briefing on IT Governance. In IT Governance Institute. IT Governance Institute (ITGI). Karayaz, G., & Gungor, O. (2013). Strategic alignment and project management offices: Case studies from successful implementations in Turkey. Proceedings of the Annual Hawaii International Conference on System Sciences, 4374–4383. https://doi.org/10.1109/HICSS.2013.499 Kerzner, H. (2017). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. John Wiley & Sons. Khan, P. M., & Quraishi, K. A. (2014). Impact of RACI on delivery and outcome of software development projects. International Conference on Advanced Computing and Communication Technologies, ACCT, 177–184. https://doi.org/10.1109/ACCT.2014.66 149 Kitchenham, B., & Charters, S. (2007). Guidelines for performing Systematic Literature Reviews in Software Engineering (Vol. 2). Kropf PhD, R., & Scalzi MBA, G. (2008). Great Project Management = IT Success. Physician Executive, 34(3), 38–40. http://search.proquest.com.openathens- proxy.swan.ac.uk/docview/199996648?accountid=14680%255Cnhttp://openurl.ac. uk/?url_ver=Z39.88- 2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&genre=article&sid=ProQ:ProQ%253 Ahealthmanagement&atitle=Great+Project+Manageme Kumaralalita, L., Hidayanto, A. N., & Chahyati, D. (2011). Compliance analysis of IT investment governance practices to Val IT 2.0 framework in Indonesian commercial bank: The XYZ Bank case study. 2011 International Conference on Advanced Computer Science and Information Systems, 297–304. Kummamuru, S., & Hussaini, S. W. (2016). Designing an organization structure for large and complex IT programs using the Viable System Model(VSM). IEEE Region 10 Annual International Conference, Proceedings/TENCON, 2016-Janua. https://doi.org/10.1109/TENCON.2015.7372958 Liberati, A., Altman, D. G., Tetzlaff, J., Mulrow, C., Gøtzsche, P. C., Ioannidis, J. P. A., Clarke, M., Devereaux, P. J., Kleijnen, J., & Moher, D. (2009). The PRISMA statement for reporting systematic reviews and meta-analyses of studies that evaluate health care interventions: explanation and elaboration. In Journal of clinical epidemiology (Vol. 62, Issue 10). https://doi.org/10.1016/j.jclinepi.2009.06.006 Liu, L., & Yetton, P. (2007). The contingent effects on project performance of conducting project reviews and deploying project management offices. IEEE Transactions on Engineering Management, 54(4), 789–799. https://doi.org/10.1109/TEM.2007.906852 Malan, A., Pretorius, L., & Pretorius, J. H. C. (2007). A framework for increasing project maturity and capability in Southern Africa. Portland International Conference on Management of Engineering and Technology, 2212–2224. https://doi.org/10.1109/PICMET.2007.4349553 150 Malan, Andre, Pretorius, L., & Pretorius, J. H. C. (2008). Managing the implementation of banking systems for repeatable success. PICMET: Portland International Center for Management of Engineering and Technology, Proceedings, c, 2366– 2375. https://doi.org/10.1109/PICMET.2008.4599861 Martin, N. L., Pearson, J. M., & Furumo, K. (2007). Is project management: Size, practices and the project management office. Journal of Computer Information Systems, 47(4), 52–60. https://doi.org/10.1080/08874417.2007.11645980 McKay, J., Marshall, P., Arumugam, S., & Grainger, N. (2013). Setting a research agenda for IT Project Management Offices. Proceedings of the Annual Hawaii International Conference on System Sciences, 4364–4373. https://doi.org/10.1109/HICSS.2013.478 Mokoena, T. S., Pretorius, J. H. C., & Van Wyngaard, C. J. (2014). Triple constraint considerations in the management of construction projects. IEEE International Conference on Industrial Engineering and Engineering Management, 813–817. https://doi.org/10.1109/IEEM.2013.6962524 Mondragón Pérez, A. R. (2002). ¿Qué son los indicadores? Revista de Información y Análisis, 19, 52–58. Monteiro, A., Santos, V., & Varajão, J. (2016). Project Management Office Models - A Review. Procedia Computer Science, 100, 1085–1094. https://doi.org/10.1016/j.procs.2016.09.254 Murillo, B., & Pow-Sang, J. A. (2021). Validación cuantitativa de los resultados de la Implementación de una Oficina de Gestión de Proyectos en Tecnologías de la Información. Revista Ibérica de Sistemas e Tecnologias de Informação, (E46), 493-506. Murillo, B., Pow-Sang, J. A., & Palma, R. (2022). A Systematic Mapping Review of PMO Frameworks. In Proceedings of Sixth International Congress on Information and Communication Technology: ICICT 2021, London, Volume 1 (pp. 285-295). Springer Singapore. Nehme, J. J., & Srivastava, S. C. (2016). Shaping of innovative is projects through 151 change requests: Scoping factors and project outcomes. Proceedings of the Annual Hawaii International Conference on System Sciences, 2016-March, 4952– 4958. https://doi.org/10.1109/HICSS.2016.614 Ogembo-Kachieng’A, M., Mothepu, M., & Omodho, W. (2013). Business evaluation of information communication technology projects in Southern Africa: The case study of Lesotho Revenue Authority. 2013 Proceedings of PICMET 2013: Technology Management in the IT-Driven Services, 1819–1827. Otero Ramirez, J., & Rincon-Gonzalez, C. (2020). Determination of the minimum requirements of a projectized organization for the assembly of a project management office. 2020 Congreso Internacional de Innovacion y Tendencias En Ingenieria, CONIITI 2020 - Conference Proceedings. https://doi.org/10.1109/CONIITI51147.2020.9240455 Petticrew, M., & Roberts, H. (2008). Systematic Reviews in the Social Sciences: A Practical Guide. In Systematic Reviews in the Social Sciences: A Practical Guide. Blackwell Pub. https://doi.org/10.1002/9780470754887 Philbin, S. P. (2016). Exploring the project management office (PMO)-role structure and processes. Proceedings of the American Society for Engineering Management 2016 International Annual Conference S. Long, E-H. Ng, C. Downing, & B. Nepal Eds, 1, 1–12. PM Solutions. (2012). The State of the PMO 2012. https://www.pmsolutions.com/audio/State_of_the_PMO_2012_Research_Report.p df PM Solutions. (2020). The State of Project Management 2020: Trends and Practices for a New Decade. https://www.pmsolutions.com/resources/view/the-state-of- project-management-2020-trends-and-practices-for-a-new-decade Pollack, J., Helm, J., & Adler, D. (2018). What is the Iron Triangle, and how has it changed? International Journal of Managing Projects in Business, 11(2), 527–547. https://doi.org/10.1108/IJMPB-09-2017-0107 Project Management Institute. (2013a). The high cost of low performance: the essential 152 role of communications. http://www.pmi.org/~/media/PDF/Business- Solutions/TheHigh-Cost-Low-Performance-The-Essential-Role-of- Communications.ashx Project Management Institute. (2013b). The Standard for Portfolio Management (Third Edition). Project Management Institute (PMI). Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute (PMI). Project Management Institute. (2018a). Success in disruptive times: expanding the value delivery landscape to address the high cost of low performance. Pulse of the Profession, 35. https://www.pmi.org/learning/thought-leadership/pulse/pulse-of- the-profession-2018 Project Management Institute. (2018b). The Standard for Organizational Project Management (OPM). Project Management Institute (PMI). Raharjo, T., Purwandari, B., Satria, R., & Solichah, I. (2018). Critical success factors for project management office: An insight from Indonesia. Proceedings of the 3rd International Conference on Informatics and Computing, ICIC 2018, 1–6. https://doi.org/10.1109/IAC.2018.8780504 Rautiainen, K., Von Schantz, J., & Vähäniitty, J. (2011). Supporting scaling agile with portfolio management: Case Paf.com. Proceedings of the Annual Hawaii International Conference on System Sciences, May 2014. https://doi.org/10.1109/HICSS.2011.390 Salameh, H. (2014). A Framework to Establish a Project Management Office. European Journal of Business and Management, 6(9), 19–26. Schibi, O. (2013). Why PMOs do not deliver to their potential. PMI® Global Congress 2013—North America. Singh, R., Keil, M., & Kasi, V. (2009). Identifying and overcoming the challenges of implementing a project management office. European Journal of Information Systems, 18(5), 409–427. https://doi.org/10.1057/ejis.2009.29 153 Taylor, H., Artman, E., & Woelfer, J. P. (2012). Information technology project risk management: Bridging the gap between research and practice. Journal of Information Technology, 27(1), 17–34. https://doi.org/10.1057/jit.2011.29 Tengshe, A., & Noble, S. (2007). Establishing the agile PMO: Managing variability across projects and portfolios. Proceedings - AGILE 2007, 188–193. https://doi.org/10.1109/AGILE.2007.24 Terlizzi, M. A., Albertin, A. L., & de Moraes, H. R. de O. C. (2017). IT benefits management in financial institutions: Practices and barriers. International Journal of Project Management, 35(5), 763–782. https://doi.org/10.1016/j.ijproman.2017.03.006 Turner, R., Ledwith, A., & Kelly, J. (2010). Project management in small to medium- sized enterprises: Matching processes to the nature of the firm. International Journal of Project Management, 28(8), 744–755. https://doi.org/10.1016/j.ijproman.2010.06.005 Van Grembergen, W., & De Haes, S. (2018). Introduction to the Minitrack on IT Governance and its Mechanisms. Proceedings of the 51st Hawaii International Conference on System Sciences. https://doi.org/10.1109/HICSS.2007.292 Wilkin, C. L., & Riddett, J. L. (2008). Issues for IT governance in a large not-for-profit organization: A case study. Proceedings - 2008 International MCETECH Conference on e-Technologies, MCETECH 2008, 193–202. https://doi.org/10.1109/MCETECH.2008.24 Wysocki, R. (2011). Effective Project Management Traditional, Adaptive, Extreme. John Wiley & Sons. Xia, X., Lo, D., Bao, L., Sharma, A., & Li, S. (2017). Personality and project success: Insights from a large-scale study with professionals. Proceedings - 2017 IEEE International Conference on Software Maintenance and Evolution, ICSME 2017, 318–328. https://doi.org/10.1109/ICSME.2017.50 Yu, S., Wang, J., & Guo, N. (2008). The application of project portfolio management in the government investment projects. 2008 International Seminar on Business and 154 Information Management, ISBIM 2008, 2, 513–516. https://doi.org/10.1109/ISBIM.2008.207 Anexo 1 – Protocolo de Consentimiento Informado (Entrevista) El propósito de este protocolo es brindar a los y a las participantes en esta investigación, una explicación clara de la naturaleza de esta, así como del rol que tienen en ella. La presente investigación es conducida por el Magíster Braulio Oscar Murillo Veliz de la Pontificia Universidad Católica del Perú, como parte de su trabajo conducente al Grado de Doctor en Ingeniería y bajo el asesoramiento del Dr. José Antonio Pow-Sang. La meta de este estudio es determinar qué criterios deben considerarse para la implementación de una Oficina de Gestión de Proyectos (PMO) que logre cumplir con sus objetivos y los de la Organización. Si usted accede a participar en este estudio, se le realizará una entrevista, que le tomará 35 minutos de su tiempo. La conversación será grabada, así el investigador podrá transcribir las ideas que usted haya expresado. Su participación será voluntaria. La información de sus datos personales será tratada de forma confidencial y no se podrá utilizar para ningún otro propósito que no esté contemplado en esta investigación. Igualmente, sus respuestas individuales serán confidenciales. Si tuviera alguna duda con relación al desarrollo del proyecto, usted es libre de formular las preguntas que considere pertinentes. Además, puede finalizar su participación en cualquier momento del estudio sin que esto represente algún perjuicio para usted. Si se sintiera incómoda o incómodo, frente a alguna de las preguntas, puede ponerlo en conocimiento de la persona a cargo de la investigación y abstenerse de responder. Así mismo para absolver consultas sobre temas de ética de la investigación puede comunicarse con el Comité de Ética de la Investigación (CEI) al correo electrónico: etica.investigacion@pucp.edu.pe Muchas gracias por su participación. Yo, __________________________________________________________________ doy mi consentimiento para participar en el estudio y soy consciente de que mi participación es enteramente voluntaria. He recibido información en forma verbal sobre el estudio mencionado anteriormente. He tenido la oportunidad de discutir sobre el estudio y hacer preguntas. Al firmar este protocolo estoy de acuerdo con que mis datos personales serán tratados de forma confidencial, pudiendo ser utilizados únicamente según lo descrito en la hoja de información que detalla la investigación en la que estoy participando. Entiendo que puedo finalizar mi participación en el estudio en cualquier momento, sin que esto represente algún perjuicio para mí. Entiendo que recibiré una copia de este formulario de consentimiento e información del estudio y que puedo pedir información sobre los resultados de este estudio cuando éste haya concluido. Para esto, puedo comunicarme con el Magíster Braulio Murillo al correo bmurillov@pucp.edu.pe. __________________________________ ________________ _________________ Nombre completo del (de la) participante Firma Fecha __________________________________ ________________ _________________ Nombre del Investigador responsable Firma Fecha Anexo 2 – Lineamientos del Cuestionario Fase Cualitativa Información general de la entrevista Nombre del entrevistado: Años de experiencia en gestión de proyectos: Lugar de la entrevista Fecha de la entrevista Nombre del entrevistador Información sobre la Propuesta de implementación de la PMO Por cada punto que se evaluará, el entrevistador debe hacer una breve introducción para poner en contexto al entrevistador. Definición de roles y responsabilidades El entrevistador solicita la opinión del entrevistado, se espera que se responda la pregunta ¿cuál es el impacto de contar con el rol de Jefe de proyectos de Innovación y Desarrollo en la PMO? Definición de estructura de Gobierno y Escalamiento El entrevistador solicita la opinión del entrevistado, se espera que se responda la pregunta ¿cuál es el impacto de contar que el proceso de priorización de proyectos es clave dentro de la implementación de la PMO? El entrevistador solicita la opinión del entrevistado, se espera que se responda la pregunta ¿cuál es el impacto de contar con el proceso de escalamiento en la PMO? El entrevistador solicita la opinión del entrevistado, se espera que se responda la pregunta ¿cuál es el impacto de contar con el proceso de comunicaciones en la PMO? Definición de funciones El entrevistador solicita la opinión del entrevistado, se espera que se responda la pregunta ¿cuál es el impacto de contar con las funciones relacionadas al Conocimiento en la PMO? El entrevistador solicita la opinión del entrevistado, se espera que se responda la pregunta ¿cuál es el impacto de contar con las funciones relacionadas al Control en la PMO? El entrevistador solicita la opinión del entrevistado, se espera que se responda la pregunta ¿cuál es el impacto de contar con las funciones relacionadas a la Gestión de los recursos en la PMO? Definición de métricas de medición El entrevistador solicita la opinión del entrevistado, se espera que se responda la pregunta ¿cuál es el impacto de contar de las métricas de medición definidas para la PMO? Definición de proyección de crecimiento (madurez) El entrevistador solicita la opinión del entrevistado, se espera que se responda la pregunta ¿cuál es el impacto de definir el modelo de madurez en la PMO? Anexo 3 – Transcripción de la Entrevista 1 Braulio Murillo: Gracias por aceptar esta entrevista. ¿Revistaste el documento que te compartí? Entrevistado 1: Si vi tu documento, le di una revisada rápida el fin de semana, pero si gustas también compártelo y lo vamos revisando punto por punto. BM: Claro algo más rápido ahí, por ejemplo, en la parte inicial que es casi donde todos los que proponen iniciativas de implementación de PMO, siempre te dicen que tienes que definir claramente los roles y las responsabilidades. Entonces siempre dicen que hay un director de PMO, jefes de proyecto, incluso algunos que son los responsables del training también; como gerentes de training. Pero lo que yo no vi y lo que también se percibió cuando se hizo esta primera implementación; es que de repente debería tener alguien un rol, no necesariamente una persona dedicada, pero de repente que comparta roles. Que es project manager y además alguien que trae una visión, un poco más de innovación y desarrollo, que traiga o haga prospectiva. Entonces respecto a esa prospectiva y conociendo la realidad de organización, procure implementar esta tecnología; pero que vaya más allá incluso, que de repente forme un grupo multidisciplinario de las áreas y llamen como digamos un comité de tecnología, un comité de digitalización; que diga por ejemplo: estoy viendo muchos temas de procesos manuales porque no tenemos el RPA y lo implementamos, cosas de ese tipo alguien que vea y que busque y traiga. Eso se vio, se sintió también como te digo en la primera parte, y por eso yo lo propongo como parte que forme parte de un staff dentro de una PMO. No sé si en tu expertise has visto algo así lo consideran viable, bueno o de repente no va por la PMO, debe ir por otro lado. ¿Cómo lo ves? E1: A ver, ¿qué es lo que pasa, porque justo algo de lo que me mencionabas a veces parten definiendo un poco la estructura de la PMO. Lo primero y yo te recomiendo, es que visites esta página www.pmovaluering.com; esta página tiene acceso a una metodología que tiene una versión free que te puede servir, y plantea lo siguiente, y es lo que yo promuevo por ejemplo de alguna manera estoy asociado con esa empresa que se llama PMO Global Alliance, es una comunidad de temas de oficinas de gestión de proyectos a nivel mundial, dentro de poner acá por el chat PMO Global Alliance vas a encontrar su página web y todo lo demás. Entonces, es una comunidad que propone algo muy interesante sobre el tema de las oficinas de gestión de proyectos, o sea lo que proponen es una metodología que se llama PMO Value Ring que lo que plantea es lo siguiente: Primero, lo que tú tienes que hacer es identificar ¿Cuáles son las expectativas de tus interesados? ¿cuáles son los beneficios que ellos piden alcanzar a nivel de temas de proyectos dentro de la organización? Entonces teniendo claro cuáles son las expectativas que ellos esperan, se plantean las funciones que esta PMO tiene que realizar. Y tiene mucha lógica, porque una PMO tiene que ser vista como un área de servicios, un área de servicios que tiene clientes y ¿Quiénes son sus clientes? Sus clientes son sus stakeholders, sus project managers, gerentes funcionales, gerente de rango medio, los analistas del proyecto, o sea todos los que de alguna manera van a verse vinculados al manejo de proyectos. Por lo tanto, al determinar cuáles son sus expectativas, la metodología inclusive hasta propone los servicios que la PMO puede realizar. El software te propone, tú te creas ahorita una cuenta libre, accede, haz una simulación y te va a proponer cuáles son los servicios que la PMO puede realizar. Entonces, esa primera parte es muy interesante porque te dice en base en estas expectativas que tienen tus interesados la PMO, se te propone que, debería desarrollar estos servicios y ya sobre eso empieza lo demás, porque eso es lo más relevante, lo más relevante saber qué va a ser esta PMO porque sobre eso ya se definen los procesos, los indicadores de medición, se arma el equipo. Ahí viene una respuesta importante, primero es bueno saber qué va a hacer, para sobre eso definir quién lo va a hacer, claro es como que define el alcance lo que va a hacer esta oficina de proyectos y luego se determina cómo lo vas a hacer y ese cómo lo vas a hacer, parte con la estructura organizacional que vas a definir, esa es una forma. Ahora sobre lo que tú me dices, ese puede ser un servicio que esta PMO va a desarrollar, de identificar oportunidades de mejora dentro de la organización, que después se convertirán en proyectos y que esta PMO sea responsable de gestionar esos proyectos o tal vez no. Es que, realmente Braulio, el tema de las PMO, para mí y lo veo algo muy interesante y fascinante, porque cada empresa es diferente o sea por eso no existe realmente un PMBOK, no existe. Existen algunos libros por ejemplo hay uno muy bueno de Gerard Hill que te propone cinco niveles de PMO y con unas funciones. No existe un manual de cómo se diseña y se implemente una PMO, porque lo que te plantea la metodología Value Ring tiene mucho sentido, porque dice estructura tu PMO en base a lo que necesitan sus interesados. Partiendo con esa definición, bacán porque cada PMO es diferente, cada PMO es distinta. Lo que dice PMI, hay una PMO de soporte, de apoyo, directiva, pero la metodología Value Ring te dice no te cases con eso, es que tiene razón porque yo podría desarrollar servicios de apoyo, de dirección, de soporte. Pero casarme con una en un tipo específico, puede ser que sí, puede ser que no; va a depender mucho de lo que realmente se necesita. Eso a mí me pareció algo con mucho sentido, ya la metodología la conozco hace años y también soy trainer, más o menos esa es una idea que yo te doy para que de repente puedas tomarla en cuenta y considerarla en el framework que vas a hacer. Yo lo que diría es, accede a la página que te digo, créate una cuenta free, navega en la metodología, tiene sus limitaciones obviamente versus la versión completa, pero te va a dar ideas, te va a dar ideas de cómo podría yo estructurar una oficina de proyectos en base a las necesidades de mis interesados. BM: Sí, es supremamente importante lo que menciona respecto a que la PMO, primero debe tener una justificación de nacimiento. Y, es más, eso se trata en la primera propuesta que se hizo, porque como tú bien indicas; no hay una receta mágica para una PMO, puesto que las organizaciones son muy particulares, son un universo en sí misma cada una. Por eso es que la idea y lo que yo propongo más bien es, no decirte: Tú tienes que armar una PMO así, siempre tiene que ser una PMO de esta forma, de este color, de este tono, lo que te dice más bien, es que consideraciones debes de tener, si tú quieres implementar un PMO. Yo he pasado la primera encuesta, desde el punto de vista del negocio como tú indicas ¿Que espera el negocio? ¿Cómo vas a medir el rendimiento? ¿La cultura lo va a permitir, no lo va a permitir? ¿Vas a valorar sus stakeholders como tú dices? Una vez que tienes todo eso cubierto recién empiezas con lo otro. Sin conocer la verdad esta metodología que tú mencionas, se ha tratado así en la primera parte, no es que se ha venido y se dice: La PMO tienes que hacerla así, cuadrada, azul, brillando; no es parte de la propuesta. Lo que yo propongo es, si tu quieres armar una PMO tienes que empezar desde acá, analizando, revisando y vas bajando, vas viendo los objetivos, la misión, qué es lo que quiere la organización y parte de un punto importante también que tú mencionas, la PMO tampoco puede ser estática, porque puede que en el tiempo madure, cambie, agrega como tú dices funcionalidades, quite funcionalidad. Entonces, si digamos esa parte, que creo que es valioso que lo mencionas, de alguna manera si está tomado en la primera consideración de la propuesta. E1: Ahora un poco ya por la experiencia, inclusive esta es la forma como hacemos nuestro servicio nosotros. Hay unos componentes importantes, para poder ir planteando, más o menos, cómo va a ser esta PMO. Una es la cultura que tú mencionas y lo otro es si es que se puede hacer un diagnóstico de madurez organizacional de proyectos. Por ejemplo, es lo que yo siempre vendo, vienen diciéndome: Oye queremos hacer una PMO. Les respondo recomendándoles que hagan un diagnóstico de madurez organizacional. Ahora hay modelos, por ejemplo, está el OPM3 de PMI. Que hay gente que me dice: no pero está desfasado, pero por lo menos te da una guía, pero también hay otros modelos, el P3M3 por ejemplo de Axelos. Ya sea que te apoyes de algún modelo o ya tú te creas tu propio modelo, pero el punto es hacer un diagnóstico, de qué tan madura son las prácticas de gestión de proyectos dentro de la organización. Te cuento un caso real y puntual que ahorita estoy trabajando. Para una empresa de infraestructura, ellos quieren diseñar su oficina de proyectos, entonces lo que ahorita yo estoy haciendo, este fin de semana debo estar terminando, he hecho un diagnóstico de madurez organizacional ¿Cómo la he hecho? En mi caso yo sí me apoyo de la OPM3 y bueno, hago una serie de entrevistas, reviso evidencias que me tienen que enviar, pues una cosa es que me digan y otras cosas que realmente exista. Me pueden decir: ¿Si hacemos un dashboard del portafolio de proyectos? Les respondo: Muéstrame el dashboard pues, ¿no? Va de la mano con entrevistas y también evidencias que necesito, con eso yo puedo armar un diagnóstico a nivel de proyectos, programas portafolio y los habilitadores organizacionales, porque es un aspecto importante. ¿Que son los habilitadores? Son una serie de elementos, están patrocinios, sistema que se utilizan, modelo de competencias. Revisa un poco sobre eso, habilitadores organizacionales (Organizational Enablers) y vas a encontrar una lista sobre sobre ellos. Entonces en mi caso reviso esos cuatro elementos y yo tengo un modelo, manejamos nosotros el modelo interno basado en la OPM3 y le damos unos puntajes, en base a la cantidad de prácticas que tú consideras que están cubiertas y otras de que no. En base a eso yo lo que hago es, por las áreas de conocimiento, determino cuáles son las fortalezas y las debilidades que se encuentran, por cada una de las áreas de conocimiento, de proyectos, programas, portafolios y los habilitadores organizacionales. Y sobre eso se arma, se plantean las acciones de mejora y esas acciones de mejora, decantan también con una oficina de proyectos ¿Por qué? Porque te salen un montón de cosas para empezar y entonces la gran pregunta ¿Quién va a liderar todo esto? Pues, si la empresa no tiene un área que realmente, va a liderar toda esta gama de acciones de mejora, que inclusive hasta en mi caso, se los he priorizado; digo mira esta es la que yo te recomiendo hacer, empezar con esto, después segunda, tercer parte. Necesitas un área que te ayude ¿Por qué? ¿Cuál es su gran misión de la PMO? Es incrementar la madurez organizacional de proyectos para que esto decante en el mayor desempeño tus inversiones, en resumen, eso es no hay más. Entonces necesitas a alguien que orqueste todo esto y que orqueste estas mejoras, con ese diagnóstico de madurez donde está la PMO planteada, ya se empiezan a ver cuáles son las cosas que esta PMO va a desarrollar y esto después decanta en los servicios que va a hacer y así es como se va armando. Ahora cuando ya se empiezan a determinar los servicios que va a desarrollar es donde ya plasmas el equipo de proyecto, el equipo de que va a trabajar en esta oficina de proyectos Ahora lo importante, es después también cuando definan los servicios que esta PMO va a hacer, hay que definir sus indicadores de desempeño que tienen que desarrollar. Por ejemplo, la metodología Value Ring te propone hasta un modelo de madurez de la PMO y el modelo de madurez, que no es el modelo de madurez organizacional, es otro modelo. El modelo de madurez de la PMO, lo que te plantea es, por cada por cada servicio que la PMO va a hacer, te plantea cuatro niveles, entonces la idea es que tú te evalúen en qué nivel te encuentras, cuando ya la PMO esté implementada y con los servicios ejecutándose, en qué nivel tú te encuentras y sobre eso determinar ¿Cuál es el siguiente nivel que quieres alcanzar y qué es lo que tienes que hacer para alcanzar ese nivel? Eso es más o menos la figura, un poco de la experiencia que tengo, un poco de la metodología PMO Value Ring que la conozco y las consultorías que yo hago. BM: Claro cuando tú mencionas “los servicios de la PMO” estamos hablando de las funciones que va a cumplir dentro de la organización ¿no? Es lo que todo el mundo le llama “funciones” en todas las literaturas eran funciones del PMO, y ahí también es muy diversa dependiendo del tipo de PMO que se quiere implementar. Es más, se levantó en la revisión que hice de la literatura, esa presente diversidad, hay un gran análisis de distintos factores que bueno, pueden llamarlo de distintos nombres, pero al final tiene grandes bloques, que se repiten en todas, que mínimamente debe tener digamos la PMO; desde el entrenamiento, hasta la definición del estándar que usó la organización, la metodología y ya luego hacer cómo va a comunicar. En fin, todo ese manejo que va a tener el lado de cara cliente interno. E1: Y es por eso que es importante hacer el diagnóstico de madurez, porque en el diagnóstico de madurez tú te das cuenta de cómo está. Por ejemplo, esta empresa tiene una metodología, pero demasiado general, o sea muy básica, yo la veo y digo: Si yo entro a trabajar acá me la voy a pasar preguntándole a todo el mundo que tengo que hacer y esa no es la idea. Entonces obviamente estoy proponiendo, esta metodología tiene que ser mejor desarrollada abordando estos tópicos; clasificación de proyectos, tipos de herramientas que se van a utilizar, procesos bien definidos, interacciones con las áreas, interacciones con la herramienta de gestión de proyectos si es que la tienen indicadores, plantillas de un tipo de proyecto. Ellos no tenían nada de eso, prácticamente es un instructivo de más o menos qué hay que hacer en cada fase y se acabó. Por eso es importante hacer el diagnóstico, porque con eso tú te empapas y ves realmente esta empresa como ésta y sobre eso ya tú vas viendo realmente qué necesita y más o menos cuánto esfuerzo hay que meterle no a la organización. BM: Creo que es valioso revisar en todo caso cómo es que ustedes formalmente han definido esa metodología de cómo hacer el diagnóstico, no creo que para ver no entiendo sin un protocolo algo para hacer ese diagnóstico E1: Yo me apoyo del modelo OPM3. El OPM3 básicamente te plantea 4 niveles que dice: Estandarizar, medir, controlar y mejora continua. Y lo que hace, es barrerse todos los procesos de la guía del PMBOK y lo que te dice es, por este proceso “Desarrollar Project Charter” ¿En qué nivel está?: Estandarizado? Ok, sí ya existe un formato; ¿Medido? quiere decir que efectivamente se pida que ese formato éste se esté haciendo; ¿Controlado? que es validado, que realmente se ha hecho bien; y Mejora Continua es que encuentres evidencias que este proceso ha tenido mejoras a lo largo del tiempo. Básicamente eso es lo que se hace y se determina; ¡oye en qué nivel tú te encuentras! bueno después de barrerte todos los procesos, que bueno en mi caso yo lo hago de una manera mucho más ágil, porque de lo contrario, es tomarte como tres meses y también revisar los habilitadores organizacionales. Y sobre eso ya tú determinas, bueno eso te da un poco ya la experiencia del oficio experto, de haber hecho varias revisiones, ya sobre eso ya tú vas determinando cuáles son sus fortalezas y debilidades que tu encuentran. En mi caso yo no lo hago a nivel de proceso porque, seria llenarte de letra. Deberías ir por área de conocimiento, estas son tus fortalezas y debilidades, así empiezo yo. BM: Perfecto, bueno si regresamos un poco a la pregunta que te decía sobre este rol entonces en tu opinión la implementación de un rol de este tipo, de un jefe de proyecto del lado de innovación, va a depender mucho también, el enfoque que la misma organización le quiera dar porque podría ser una PMO, no sé, una cultura muy estricta. No, la PMO va a hacer los proyectos que le diga que tengan que hacer. Ahí no necesitas nada, clarísimo tienes que hacer lo que te diga. Pero si es una cultura más bien centrada en promover la aplicación de tecnologías, su valor agregado frente a la competencia es el uso y la aplicación de nuevas tendencias y tecnologías, sin duda ese rol sí cubriría un poco ese aspecto porque ayudaría a que la PMO entregue productos siempre aplicando tecnologías, digamos validadas, que sean reconocidas como tendencias y que facilite también el trabajo interno. Entonces, lo que te entiendo es que es la definición de estos roles, está muy asociado a lo que es la expectativa de la organización le pida a la PMO. E1: Y eso es algo que por ejemplo que nosotros mencionamos con el tema de la PMO tiene que ser flexible. Date cuenta el gran problema que tiene a la PMO, no es un área estándar. No es un área de finanzas, ni marketing, ni logística de operaciones, donde tú dices ¿Yo necesito de finanzas para vivir? Sí, ¿yo necesito de marketing para vivir? Sí, porque si no, no vendo ¿Necesito de operaciones? Sí, ¿Necesito la PMO? Ahí viene el question mark. Ahí la gran pregunta ¿realmente tú necesitas una PMO para poder vivir, para poder subsistir? Entonces crea el gran reto que tiene todo líder de PMO que es demostrar valor, realmente lo que yo estoy haciendo, sí está apoyando a que la organización mejore y, por ende, uno también tiene que ser flexible en el sentido de que en algunos casos también tendrás que asumir cosas vinculadas a la organización pero que la PMO tenga que desarrollar. Por ejemplo, una vez conversábamos con un amigo de que a su oficina de proyectos le habían pedido, que empiece a ver el proceso de un plan de continuidad de negocio. Me parece bien, porque ahora con todo este problema de la pandemia, las empresas se han dado cuenta, oye realmente sí necesitaba tener un plan de continuidad de negocios que me ayude a tener claro qué voy a hacer cuando se presenten crisis de esta magnitud. Cuando me enteré, dije me parece perfecto, lógico; ahora tienes que preparar bien a tu gente, para que se desarrolle un plan y que éste sea administrado por la oficina de proyectos. A lo que voy es que la PMO tiene que ser tan flexible, que de todas maneras pueda también asumir cierto rol importante dentro de la organización, vinculado de alguna manera temas de negocio y a los temas de proyectos obviamente, en este caso es gestionar los riesgos organizacionalmente, pero un plan continuidad de negocios es gestionar riesgos, en resumen, eso es, eso también es importante considerar. Y lo que mencionas, un rol de jefe de proyectos de tema innovación, claro va de la mano con lo que necesita la empresa y también su cultura de trabajo, realmente como mencionábamos, la estructura de esta oficina de proyectos va muy de la mano en realmente lo que la organización necesita. Por ejemplo, te cuento que, en este cliente tienen la necesidad de ofrecer un servicio de PMO. Justo es una empresa infraestructura, quiere implementar su PMO y a futuro ofrecer servicios. Entonces la gran pregunta es ¿Oye qué funciones va a hacer esa PMO, ¿qué quieres tú tercerizar? Mira sabes que, dentro de las entrevistas que estoy haciendo, entrevistemos a tus clientes y con eso yo voy a tener más claridad de qué es lo que se espera. Entonces, más o menos, ya tengo clara de qué es lo que se necesita para plantear un servicio tercerizado oficina de proyectos más o menos estándar porque como digo también va a depender lo que el cliente pida. Por eso, lo que se terminó diciendo es: Mira, vamos a tener servicios primarios, funciones primarias y funciones secundarias, es lo que vamos a hacer. Primarias, es lo mínimo indispensable que te piden para una PMO, ¿Qué mínimo indispensable te piden? Que audites, controles los proyectos, que tengas una metodología, que gestiones el conocimiento, que gestione la documentación, por ejemplo. Ya, eso es lo mínimo, que gestiones proyectos puede ser que sí, puede ser que no, de repente a ti te piden solamente que monitorees, pero los proyectos los van a hacer los jefes de proyectos de la misma empresa, que gestiones el portafolio, puede ser que sí, puede ser que no, porque cuando tú gestiones un portafolio estás ya ha metido con la estrategia de la empresa, puede ser que te quieran abrir la puerta o puede ser que no. Por eso es lo que le decía, mira lo que vamos a plantear son servicios primarios y luego servicios secundarios, depende lo que se te pueda pedir. Y sobre eso yo te voy a armar una estructura organizacional para servicios primarios y servicios primarios con secundarios, así es como se los he planteado. BM: Sí, ahí totalmente llegamos hasta lo mismo. La PMO debe ser flexible y debe ser flexible a la organización donde se quiere implementar. No puede ser rígida, no puede decir de esta forma es. No, tiene que estar abierto, adaptarse como tú mencionas a mejorar, a madurar, a quitar acá a poner allá, tiene que ser ente vivo, dentro de la organización, no puede estar este digamos fijo y estático. Ahora me queda clarísimo entonces que el tema de los roles y responsabilidades es, para cerrar esta primera parte, depende mucho de la expectativa final de lo que espera la organización y de lo que espera de la PMO. Entonces el cargo de un jefe innovador será viable o ayudará en tanto que la organización promueve ese tipo de cultura y que busca ese tipo de cultura, sino estaría de más, totalmente de acuerdo con eso. Otro tema importante que he visto también en las PMO y bueno que también es gradual dependiendo cómo empieza la creación de la PMO es el nivel de gobierno que va a tener en la organización y ahí sí se tiene mucho matiz. Por ejemplo, hay PMO que solamente la reporta el jefe de IT y no va más allá, o también PMO que ya está a nivel de directorio que toma decisiones, eso también se analizó en la primera propuesta. Pero en este caso cuando se plantea esta primera parte que se hizo; primero se tomó como una PMO todavía de un nivel donde el director de TI la va a gestionar, una PMO funcional, luego se midió y tuvo resultados. Pero precisamente como parte de esta segunda propuesta, lo que se vio es que quizás el nivel de la PMO debería ir más allá hacia un nivel incluso de decisión, es decir no solamente hacer lo que le toca hacer porque le mandaron estos tres proyectos, sino incluso formar parte de la toma de decisiones de qué proyectos hacer. Entonces lo que planteo en esta segunda propuesta es tomar, por ejemplo, lo que hace la gestión de portafolio del PMI y tú sabes que hay una parte que te dice que ¿Cómo tomamos decisión sobre qué proyecto hacer y qué no hacer? Y esta gestión de portafolio te da como una pequeña metodología por así decirlo, yo lo veo así, de cómo debes hacer tú para que desde que identificas el proyecto, cómo llegas a categorizarlo, evaluarlo y llegar finalmente a tu nivel de priorización con puntajes. Tú debes saber eso, en el sistema de portafolio dice esa parte desde que identificas, las categorizas, evalúas y finalmente das una priorización y te sale una lista priorizada de los proyectos. Esa es una parte, que incluso en la propuesta que tengo, se hizo como un ejemplo tomando algunos proyectos que se tenían y porque decíamos ¿Por qué nosotros sólo vamos a ejecutar lo que nos dan? Si no, por qué no intervenir desde la decisión de qué proyecto inicial y de qué proyecto se puede empezar y dejar. Incluso se tomó en consideración algunos temas legales que decía, por ejemplo: Un tema legal no pasa por acá, tiene que ir directo y se tienen que hacer porque es legal, nos obligan a hacerlo. Entonces acá la pregunta es si tú consideras que esta metodología adaptada, que está tomada de la PMI porque eso no es propio, ¿es una buena forma de llegar a priorizar los proyectos? O existen también, de repente en esta metodología que tú mencionas, otras que dicen: Mira, de esta lista de proyectos, qué podemos hacer nosotros para tener un mejor entendimiento y priorizar lo que vamos a empezar, no por lo que tú nos digas, si no de repente por evaluar lo que conviene hacer primero, qué conviene hacer después en base a los recursos o necesidades no, ¿Cómo ves esta parte de la priorización? E1: En mi caso, por ejemplo, yo dicto un curso de gestión de portafolios para la calidad y también eh dado unos talleres de workshop virtuales también por la empresa en el cual yo estoy asociado. Dentro del curso yo lo que les enseño es la metodología, es el modelo AHP que se llama Analitical Hierarchy Process. Este es un modelo en el cual tú priorizas tus proyectos en base unos criterios y unos pesos. Ahora, la definición de esos criterios con quién lo haces, lo deberías de hacer con los entes tomadores de decisiones, que, en gestión de portafolios, dependiendo en la envergadura del portafolio, porque también portafolio puede, ser funcional, puede ser departamental o también puede ser corporativo. Entonces dependiendo de la envergadura, o sea, en la gestión de portafolios la estructura organizacional es así. Tú tienes un sponsor del portafolio, tienes un cuerpo de gobierno, que es el que va a tomar las decisiones del portafolio, debajo de él viene el director de portafolios ¿El director de portafolios puede formar parte de la PMO? puede ser, como que también la PMO puede estar por fuera, entonces ahí la PMO ¿Qué cosa es? La PMO básicamente es un ente, que le pasa a la información consolidada al director de portafolio, porque he visto las dos figuras y debajo están los cuerpos, el cuerpo de los líderes de los componentes, o sea los jefes de los proyectos de los programas. Puede ser que la PMO tenga dentro de sus funciones gestionar un portafolio perfecto, pero que tome las decisiones, eso va a depender que tanta autoridad le den. Lo que la práctica de dirección del portafolio se propone es de que hay un cuerpo de gobierno que es el que toma la decisión y ya sea el director de portafolio, que forma parte de la PMO, o por fuera el asesor es el cuerpo gobierno para tomar decisiones. En resumen, a que voy, por ejemplo: Viene la priorización de los proyectos e imagínate que la PMO va a gestionar el portafolio, lo que hace el director de portafolio es hacer una corrida en base a los criterios, puntajes que se asignan y se plantea una priorización inicial, que después es validado con el cuerpo de gobierno ¿Por qué? Porque, normalmente un portafolio tiene decisiones de negocio y los que mejor conocen el negocio no es la PMO, los que mejor conocen del negocio son o deberían ser esos BP de marketing, de finanzas de operaciones y por ahí está el gerente general perfecto, pero el punto o la idea es que en este caso la PMO entra como un ente facilitador de toma de decisiones, a ese cuerpo de gobierno que es el que finalmente las va a tomar, ese es el esquema. BM: Perfecto, a ver si redondeado entonces el PMO, sí podría tener esta tarea o función de hacer esta priorización como tú dices, con los pesos que se haya definido, con quien corresponda, hacer los cálculos y todos. Pero lo que tú sugieres es, finalmente él entregaría un resultado, pero la decisión final no va a ser de la PMO sino del negocio que le diga concuerdo contigo o puede decir, mira, por más que tú me digas que esto es prioritario, para mí no lo es o para nosotros no es, tiene que ir está arriba esté abajo, me parece genial y ese un buen punto. Ahora este modelo AHP que mencionas, que asigna puntaje y todo ¿Es parecido al del portafolio no? Porque el portafolio también hace lo mismo, define unos criterios y le da puntaje, luego tú haces los puntitos, le calcula y todo, es muy parecido a eso digamos. Lo voy a revisar igual porque de repente algo de más puedo agregar en este proceso. Pero si el último punto que menciona me parece genial, de que la PMO solo entregue y que la decisión no vaya por ahí, vaya a un nivel más arriba todavía. E1: Lo que se estila, es tener un taller, un workshop, en el cual te reúnes con los líderes, con ese cuerpo de gobierno, es un taller de facilitación, donde, acá señores, se tiene la planilla inicial de priorizaciones, empecemos a conversar y si se tiene ahí, se tiene un trabajo colaborativo. BM: Perfecto, me gusta mucho eso del workshop. Muy bien, en el caso de las de las funciones, uno encuentra infinidad, o sea uno va, hay de todo y te ponen que haga de todo. Como te dije en la primera parte, lo que se trató de hacer fue la categorización de las funciones como las que tengan que ver con el control económico, control de la gestión del proyecto, control del conocimiento. Si bien hubo una definición básica y estándar, como te digo al inicio muy estándar, una PMO todavía muy funcional, lo que vimos para esta segunda parte, fue que se podría agregar estas funciones relacionadas con el tema del conocimiento, es decir a reforzar el tema, de no solamente decir, como tú menciones al inicio: Mira acá hay un estándar y hay que seguirlo, ok bueno lo seguimos, sino ir más allá. Ver que se cumpla el estándar, estar en el momento de la ejecución, monitorear, estás haciendo o no estás haciendo. Eso también se vio, que debe ser reforzado en la PMO, no solamente ¡vamos a usar PMI! Genial vamos a usar PMI y después quedó ahí. Es un tema un poco más de control, por eso se propone mejorar también la comunicación, centralizarla, porque se ve, que a veces los jefes de proyectos no comunicaban adecuadamente. Entonces mejor que la PMO ayude a centralizar o a ver cómo es la mejor forma, de acuerdo con una matriz de comunicación, de comunicar esto a los interesados, a los stakeholders a todo nivel. Entonces, se agregaron estas funciones de conocimiento, de control. Por ejemplo, algo que también se vio, es que la PMO también debería tener un ente auditor o también tener una visión más de auditor también, de cumplimientos, de no conformidades. E1: Ahí va a depender también el servicio que hagas, si funcionan auditorías, también tiene que haber. BM: Claro, porque si la organización no le va a dar esa tarea no va por ahí de repente, va por otro lado. Pero lo que sí se requería también a ese nivel, una visión de ese tipo. Y en el caso de los manejos de los recursos, como te comentaba al inicio, ahí si hablaba que la PMO incluso debe participar, cosa que no pasaba en esta primera parte, participar incluso estrechamente con recursos humanos, para ver el tema de cómo captamos a los talentos para la PMO, porque a veces llega el requerimiento y recursos humanos en su entendimiento trae gente, pero es un entendimiento muy recursos humanos a veces, porque a veces no se detalla bien tampoco el perfil. Pero lo que se propone, es que la PMO debe trabajar muy de la mano con recursos humanos, para precisamente atraer y captar este personal y con recursos humanos, ya luego hacer incluso su plan de desarrollo y plan de entrenamiento que requieran. Y obviamente también en un mayor tema económico, que la PMO tenga una mayor responsabilidad en el manejo de la definición de estos presupuestos, que de repente al tema funcional, no le dan esa responsabilidad, pero a medida que esto crezca, sí deberían tener autonomía incluso para definir y ver cómo es que se elaboran y justifican estos presupuestos de la PMO. Entonces, esto es lo que se vio también como un complemento a lo que inicialmente se tenía, como tengo la inicial fue lo básico, definir lo estándar. Pero esto que te muestro, fue lo que se recogió también, se vio y se dijo: Sí, estas funciones también deberían estar en otro nivel de PMO, un nivel más hacia arriba. Supongo que esto te hace sentido también ¿lo has tenido que ver seguro? E1: Sí, claro. Por ejemplo, nosotros hemos tenido un cliente, bueno realmente el cliente directo que es Entel Perú, porque tuvimos un trabajo con Entel Chile. Entel Chile es muy maduro, tiene una PMO que inclusive fue considerada la mejor, fue finalista del premio del PMO del año y un par de años. No, hace unos 4 años más o menos creo, entonces es una PMO muy madura, pero eso lo logras con los años, eso también es verdad, con los años, un buen líder y se va trabajando. Ellos, por ejemplo, tienen políticas bien importantes, para empezar todos son PMP. Todos sus jefes de proyectos, todititos, así de sencillo, el que no es chau. Entonces ¿Con eso qué homologas? Homologas conocimiento. Después, otro punto importante es que ellos tienen una línea de carrera, eso también es importante definir, pero también va a depender un poco de la organización. Entel es una corporación, una empresa mediana entonces, hasta dónde puede llegar. Y lo otro es que ellos por ejemplo han llegado a instalar, lo que es una academia, le llaman la academia Entel, donde tienen este sus entrenamientos, sus capacitaciones en dirección de proyectos, pero planificadas. Por ejemplo, te cuenta con un servicio que a nosotros nos pidieron, en Entel Perú. Nos pidieron evaluar el conocimiento técnico y las competencias de sus project managers o de las personas que asumen el rol. Por eso que te digo, cada empresa, es una historia distinta. En Entel Chile, ya existe el rol o el puesto de jefe de proyecto, jefe de programa, etc. En Entel Perú no, en Entel Perú tu asumes ese rol, o sea yo soy jefe de finanzas y voy a asumir el rol de jefe de proyecto. Entonces eso también genera complicaciones cuando no tienes el rol, cuando el cargo no está establecido, ¿Por qué? Vamos a hacer muy sinceros, tú te mueves en base a cómo te miden, si a ti te miden por tu cargo como jefe de finanzas, obviamente le voy a dar punche a eso pues ¿Y si me toca gestionar un proyecto? ¿Qué hago? Yo me muevo en base a como miden, entonces eso fue algo muy interesante, que también es bueno mirar. Por eso te digo el tema del diagnóstico de madurez, por eso es importante hacer ese rollo, porque con eso ya entiendes cómo es la empresa. Yendo al caso de Entel, ellos tienen pues su academia, tienen su línea de carrera, tienen módulos de capacitación que tú vas tomando en base a la posición que tú posees y que estos módulos están asociados a las competencias planteadas que debe tener un project manager, qué obviamente se basan en lo que plantean los estándares, pero también que conviven con sus competencias y valores propios de la corporación. Sí es importante contar con programas anuales de capacitación, que sean maduros porque eso fomenta lo que es la gestión del conocimiento y la madurez que va a tener la empresa. Bueno al final, la madurez organizacional de proyectos que va a tener la empresa. BM: Creo que es valioso esto que mencionas. Esto de la capacitación y el plan de desarrollo tiene que ser algo estructurado, no informal, no algo que se nos ocurre hoy día. Tiene que tener un plan y todos tienen que pasar por este desarrollo. E1: Y políticas, políticas claras. Por ejemplo, como te digo en Entel chile todos son PMP, se acabó, acá no hay más y el que no es PMP no entra, así es. Y aquí en Perú se empezó a pedir esa política, no sé en qué habrá quedado, estoy hablando hace dos años, fue el servicio que hicimos, pero o sea, es algo que se estaba exigiendo a todos. BM: A eso se refería y creo que también importante, agregar esto o dejarlo más claro. Es que ya es algo más institucionalizado, que vaya a ese nivel, es cultural, se tienen que hacer a ese nivel. No es que ¡tengo presupuesto vamos a poner una capacitación! No, planificado y estructurado. E1: Claro y obviamente alineado, bueno trabajamos con recursos humanos, eso es cierto. BM: Interesante. De estos dos últimos puntos ya para no quitarte mucho tiempo. Cuando vimos esta primera parte, se decidió medir lo más lógico que hay que medir al iniciar con una PMO, que era medir tiempo y medir costos, es lo que primero se planteó. Entonces se dijo: A ver, luego de la implementación, ¿nos ayudó en reducir tiempos de entrega?, ¿no hubo retrasos considerables en el proyecto? o ¿hubo gasto dinero por reprocesos, correcciones, cambios mal manejados? Eso se midió y sí, hubo una mejora, no se ahorraron un 80%, pero sí una mejora considerable tomando en cuenta lo anterior Cuando se terminó de hacer todo eso también se vio y se dijo bueno, pero de repente no solamente hay que concentrarnos en el tema básico, que es el costo y el tiempo. Y acá surgieron estas tres métricas más, como digo, es también como que una segunda parte, de repente a medida que crece se van incrementando más o vas teniendo otro tipo de métricas más maduras vamos a decirlo. Pero las métricas que saltaron más a la evidencia fueron: El tema de, si estamos cumpliendo con la información y la comunicación, que era lo que también querían los stakeholder, o sea tienes que mantenerme al tanto en lo que pasa en el proyecto. Entonces se define una métrica en cuanto a si estamos cumpliendo con el envío de estos informes de proyecto a tiempo, en forma, en todo. Se hablaba también si es que finalmente se cumplía, porque muchos decían: No solamente es tiempo y costo, sino que, a la larga, el proyecto realmente solucione el problema o genera beneficio. Entonces, se mide la expectativa del área o del cliente que lo pidió y al cabo de unos meses vamos a decir ¿Realmente el proyecto tiene un criterio de éxito o te ayudo en lo que tú necesitabas? Entonces se quiere medir eso también como porcentaje de satisfacción, no solamente que lo entreguen tiempo y costos, sino, vamos a esperar unos meses y luego te preguntaría si te ayudó, sirvió o fue la mejor forma. Eso también se quería medir. Otro punto importante es, que tanto finalmente estamos ejecutando proyectos que están alineados a esta estructura o a la estrategia organizacional, que va de la mano con el tema de la priorización, para ver si realmente lo que estamos priorizando realmente termina haciéndose bien. Entonces se define también una métrica de ese tipo, ver si finalmente de todos los proyectos, se hicieron finalmente estos proyectos que estaban alineados a la estrategia organizacional. Como esta segunda etapa se visualizaron que éstos podrían ser indicadores importantes también, para este tipo de PMO y obviamente se deja acá una propuesta, porque no vamos a tener tiempo para medirlas lamentablemente, pero se deja como un tema de que se podría considerar, porque daría información valiosa a la organización de cara a cómo se ejecutan los proyectos y qué beneficio les trabajo finalmente entonces. ¿Tú ves que esos proyectos o esas métricas, si generarían valor al stakeholder finalmente de la organización? E1: Claro, el de beneficios es importantísimo, porque, al final los proyectos se hacen con la intención de obtener beneficios y el punto es de que esos beneficios tienen que estar plasmados en el caso de negocio del proyecto, ahí deberían estar plasmados, actualizados, si hubo cambios en el contexto. Pero después lo que se tiene que medir es el logro de esos beneficios. Entonces, ahí viene la gran pregunta ¿Quién lo hace? Por ahí alguien dice: No, pero lo puede hacer gerente o el área que recibe el proyecto, pero necesitas a alguien que te ayude a consolidar esa información y eso es bien importante. Esa métrica sí es importantísima porque aparte de obtener la métrica hay que reportar el logro de beneficios o el estatus que tiene porque te puedes encontrar con proyectos que están siendo implementados, le estás metiendo plata por mantenimientos, upgrades, lo que tú quieras, pero realmente no te están generando lo que tú necesitas. A ver, puede haber proyectos bien hechos, te lo entregaron a tiempo, siempre con el presupuesto acorde, con el alcance que se pidió, pero de repente no te está generando lo que te espera y encima le están metiendo plata, por mantenimientos que haces. Entonces es importante hacerle seguimiento al logro de estos beneficios. Y eso se lleva al cuerpo de gobierno, nuevamente ahí voy, porque finalmente es el que tendrá que decir sabes, si seguimos todavía invirtiendo en este show o lo paramos y se tendrá que tener sus justificaciones. Entonces la PMO sí debe de gestionar los beneficios de los proyectos, eso es importante. Ahora sobre el tema de la satisfacción. Mira te cuento un caso personal, en mi último trabajo de dependiente, nosotros manejamos dos encuestas, por cada proyecto a la mitad y al final, donde una de las cosas que se evaluaba era el nivel de gestión que tenía el project manager. Aparte de auditar, lo que hacía era, tener encuestas de satisfacción para poder determinar, qué tan buen desempeño se estaba dando en el proyecto, por la gestión propia del project manager, la comunicación que se daba, la opinión que tenían los interesados del proyecto. Y se hacía a la mitad y al final ¿Por qué a la mitad? Porque te permite hacer ajustes, conversar con ese project manager, oye qué está pasando aquí, y plantear una serie de mejoras que se tenían que hacer y lo otro es al final también para ver un poco cómo terminó todo esto. Algo también importante y que va a agregado el tema del conocimiento Braulio; es el tema del manejo de las lecciones aprendidas. Pero el gran problema que uno identifica es que hay empresas que identifican las lecciones aprendidas, pero ¿Qué haces con eso? Ahí viene la gran pregunta porque la gran pregunta es responder si la lección aprendida fue finalmente aprendida, entonces una de las cosas que se propone y te voy soltando un poco lo que voy a proponer acá con este cliente. Las lecciones aprendidas se tienen que recopilar, perfecto, pero hacer una capacitación que ya aprendimos esto, oye a la gente le entra por aquí le sale por acá. Se está proponiendo que estas lecciones aprendidas sean implementadas a través de una herramienta, llámala la base datos que tú quieras, y la política va a ser la siguiente: Empieza un proyecto, ese project chapter es aprobado siempre y cuando tenga un informe de revisión de lecciones aprendidas por tipo de proyectos. Por eso por eso la base de datos tiene que ser bien estructurada porque hay que ver el tipo de lección aprendida, el caso o en qué etapa del proyecto se dio. Entonces el project chapter es aprobado siempre cuando venga con un informe de revisión de lecciones aprendidas, con eso obligas al project manager o al que está auspiciando de proyecto que por lo menos se ha dado el trabajo de revisar la base. Y lo otro, que eso ya sería una segunda parte, es que la evaluación de desempeño del proyecto tome en cuenta si es que hubo problemas y que se reflejaron en lecciones aprendidas que se encontraron. Porque se supone que no vas a cometer los mismos errores, se supone que tú estás revisando lecciones aprendidas de tal manera que evites esos errores. BM: No tropezarte con la misma piedra en el proyecto. E1: Esa es la idea, eso es lo que estoy proponiendo con este cliente. Primero construir la base, que es lo más tedioso, después sacar la política de que cada proyecto aprobado venga con revisión de informe de lecciones aprendidas. Y que luego, al cierre del proyecto o periódicamente, se validen de que los problemas que se hayan presentado en el desempeño del proyecto no repliquen los problemas encontrados en las lecciones aprendidas, porque se supone que, si es lección aprendida, no debiste haber repetido el mismo problema. Eso de alguna manera ayuda a lo que es la gestión del conocimiento, que va de la mano también con el tema de capacitación, compartir aprendizajes y todo lo demás. Pero es que ese es un problema que yo he visto en varias empresas, bueno algunas no tienen nada, hay otras que tienen. Y luego entra la pregunta ¿Qué haces con esas lecciones aprendidas? Ah, no, hacemos una capacitación. ¿Cómo te aseguras que la lección aprendida fue finalmente aprendida? Ahí, todititos, question mark. Entonces ahí es donde ya entramos a plantear esta solución. BM: Sí, valiosísimo. Porque la mayoría, incluso podría quedarse en la identificación y ahí quedó. E1: Claro, por ejemplo, en un nivel de madurez, eso es mejora continua, eso es mejora continua de ese proceso, si no te quedas en: Estandarizar, ya perfecto, están los formatitos donde la gente ya respondió. Mides, la gente lo cumple. Controlan, ya ok, la gente llena el formato está perfecto, controlas, ya perfecto, la gente está entregando y se está llevando un indicador referencia aprendida. Pero ¿Qué hiciste con eso? ¿Cómo te aseguras que realmente esto caminó muy bien? Mira Braulio, hay un paper muy bueno que te voy a compartir, que la otra vez se encontré. Es un paper de una PMO, de una corporación que se llama VALE. Es una empresa de infraestructura global, brasilera, pero cuando le dije wow, esta es una PMO de clase mundial. Te lo voy a pasar para que lo leas y saques algunas ideas que te pueden ayudar dentro de tu investigación porque me pareció una PMO así de clase mundial realmente. BM: Genial, gracias, yo lo leo de verdad después, ¿Es reciente ese paper? E1: Bueno creo que es 2014 algo así, pero igual léelo porque imagino ¿Que te exigen con información no mayor de cinco años? creo no. BM: Sí pero bueno eso igual como creo que se puede agregar como bibliografía también para referenciarlo y todo, si se encuentra lo valioso está bastante bien. Ya para terminar, y no quitarte mucho tiempo, que debes estar ocupado. Mira sólo el último punto que creo que también le hemos tocado de manera tangencial digamos, en lo que hemos conversado. El tema de cómo es que la PMO no debe mantenerse estática. Lo que mencionamos en un inicio. Entonces acá se propone que precisamente se ve que una PMO que empezó funcional, no deben quedar siempre en funcional, debe ir más allá. Entonces acá sí, lo que también en la propuesta, se toma un ejemplo. Que es el project manager maturity model que es un modelo también de madurez, donde más o menos te dicen cuáles son esos niveles que una PMO puede transitar a lo largo de su existencia. Y lo que se ha tratado de proponer en realidad es como tener hitos vamos a decirles, es un poco de lo que he planteado yo, un hito que te puede ayudar a ver si realmente puedes ya empezar a subir la grada. Si tiene más o menos estos hitos puedes ir subiendo a la grada es lo que te dice, porque el inicio de repente no tenemos los procesos totalmente definidos, sólo el apoyo va a demanda, cuando te lo piden pues es muy reactivo y no hay todavía una formación formal como lo que hablabas de gestión de proyectos. Eso quiere decir que todavía estás en un nivel muy incipiente, muy inicial de la PMO. Incluso te propone: Oye, pero ¿Cómo debo hacer para que esto cambie? Ah bueno establecer documento, establecer un proceso documentado, definir un plan de formación, por ejemplo. Y si logras hacer eso ya como que saltarías a un nivel más siguiendo este modelo PMMM, yo le digo PM3, de subir, de nivel inicial ahora pasamos al nivel repetible. Y de nuevo, para repetible tú estás haciendo esto y necesitarías hacer esto para subir al siguiente nivel. Lo que se ha hecho es, tomar eso como una base, es un poco adaptado en realidad, se siguen los mismos niveles, pero los hitos o las recomendaciones un poco en base también a lo que se tiene en la organización. Entonces se plantea de ese modo, igual hay un modelo, pero igual esto se tiene que adaptar a lo que tú tienes, no lo puedes tomar tampoco a rajatabla. Lo que se hizo fue, proponer por cada etapa, cómo tú puedes ir avanzando de nivel hasta digamos sentirte que ya estás en un nivel optimizado, donde ya, como hablamos, terminas teniendo un proceso de mejora realmente continuo, es decir esto es continuo no para, te vas mejorando siempre, te miden los criterios de éxito de los proyectos que hablábamos también, el beneficio y las auditorías, por ejemplo. Entonces esto es lo que también se propone, que se deja como tarea la PMO y a los responsables de esta implementación, no solamente quedarte en un nivel inicial, sino tú mismo hacerte como tú autoevaluación y ver cómo puedes ir subiendo, subiendo, subiendo a una grada más del nivel de madurez, eso es también lo que se plantea en esta propuesta. Que es un poco como te digo, sí lo hemos estado hablando en esta hora y toca ese tema de esa forma. Ahora lo que sí de repente te preguntaría es, yo he tomado por ejemplo este modelo, que es de la universidad de Carnegie Mellon, pero tú sugerirías de repente revisar otro modelo también de madurez como para contrastar. E1: Mira cómo te digo chécate la metodología de Value Ring. Value Ring te plantea que por cada servicio te plantea niveles de madurez. Y la idea es que tú vayas logrando esa madurez, es decir de pasar procesos muy manuales o donde realmente tu influencia es muy baja, hasta pasar a procesos automatizados con una influencia bastante alta, personalmente para mí ese modelo funciona muy bien. Ahora también hay que tomar en cuenta algo. Para mí, algo fundamental, por ejemplo, para que una PMO empiece a calar dentro de una organización, primero se instala en base a lo que se necesita, pero lo que yo he visto un poco de participar en esta comunidad del PMO Global Alliance y también participar en estos concursos mundiales que se hacen. Las PMO de clase mundial tienen algo en común, así, bien clarito ¿sabes qué es? Te lideraron un proyecto emblemático de la empresa, un proyecto estratégico. Eso es Braulio, te juro, eso es lo que tienen en común, te lideraron algo estratégico para la empresa y lo hicieron bien y ¡boom! Te juro, o sea, todas o al menos de las que vi, al menos las ganadoras y las que vi, te lideraron un proyecto estratégico organizacional. Es que eso lógico pues, la gente empieza a creer en ti cuando ve resultados, así de sencillo es, y que cuando ve que tienes capacidad. Por ejemplo, algo bien importante en una PMO, los que están ahí tienen que ser los referentes de gestión de proyectos de la empresa, así es, tienen que ser los referentes. O sea, alguien pide un proyecto, se le pide a la PMO el apoyo, el soporte, si es que no va a gestionar proyectos. Entonces eso es bien importante, o sea tienes que meter goles y esos goles van de la mano con, nuevamente con las expectativas de los interesados. Cuando a mí me preguntan un poco cuál es el camino natural, yo lo que siempre propongo es, primero parte de lo que necesita tu empresa, ahora disponiéndome el caso de una empresa corporativa, empieza una PMO departamental y que demuestre goles, que muestre beneficios logros, y luego esto va a ir decantando y subiendo. También hay corporaciones que tienen PMO en varios departamentos, por ejemplo, en Entel había de sistemas y de infraestructura, dos PMO diferentes pero que después se gobernaron por un PMO corporativo, también se puede dar ese escenario. Revísate lo del modelo de PMO de Value Ring, piensa un poco lo que te digo, lo del tema de que tiene que meter goles y vender sus goles. Otro es si es que gestiona proyectos, liderar un proyecto emblemático estratégico para la empresa. Transformación digital ya, que lo veo, algo así es o por lo menos que esté metido, que está PMO tengo un papel llamativo, porque eso sí es necesario. BM: Perfecto genial, créeme que me ayudó muchísimo poder conversar contigo, me has dado visiones que de repente no las tenía y me ayudará mucho incluso a afinar está esta propuesta. Yo sólo como un pedirte un final, en el correo inicial te mandé un consentimiento informado, te pediré que lo llenes digitalmente no hay problema. Y nada, igual cualquier tema o algo te voy a mantener al tanto porque igual tú has aportado muchísimo entonces te voy como comentando cómo va el tema y bueno agradecerte nuevamente por todo porque si es muy valioso tener de verdad como experto tener estos puntos que tú me das que muy claro ahora me doy cuenta muchas cosas más, entonces este es muy muy valioso y enriquece mucho el trabajo, te agradezco muchísimo por eso y por darte el tiempo la verdad de la reunión. E1: Para mí un gusto poderte ayudar en lo que necesite, bueno es qué eh estado metido en este tema ya años, ya uno ha ido aprendiendo varias cosas, un poco las consultorías. Si puedes, entra la página PMO global Alliance, inclusive uno puede hacerse el miembro gratis para la comunidad y puedes acceder a esta información valiosa que te puede servir. Y algo interesante que tiene esta organización, es que hace su concurso mundial de PMO, escogen la PMO de mayor valor. Y las PMO que ganan presentan vídeos de lo que hacen, entonces ahí vas a sacar algunas cositas interesantes de estas PMO de World Class que se le dicen, obviamente siempre te van a vender lo mejor que hacen, sacas cosas interesantes. Por ejemplo, la conclusión que llegaba, toda PMO de clase mundial, es porque terminó liderando un proyecto emblemático, estratégico de la empresa, todas, todas. Que eso es parte de una conferencia que estoy construyendo. BM: Y además cobra mucho sentido, porque con esas ganas tú mismo tu auto respaldo, yo hago bien las cosas, acá está. Ya tengo la autoridad para hablar del tema. E1: Y ganas la autoridad con goles pues, es así de sencillo, con goles. BM: No queda todo en papel, sí pues perfecto. Muy bien, mil gracias, disculpa haberte robado unos minutos de capacitación. Mil gracias, de nuevo. Estamos en contacto E1: Si bien un abrazo y saludos. BM: Gracias, cuídate bastante. Anexo 4 – Transcripción de la Entrevista 2 Braulio Murillo: Te cuento, este es un proyecto muy interesante y tú has sido convocado en la nómina de expertos. El proyecto se trata de definir un framework o un marco de trabajo para implementar una oficina de proyectos. Este proyecto sigue todo el protocolo de investigación. En la primera parte se hizo una revisión sistemática, es decir, se busca en la literatura académica en base a datos académicos, experiencias de este tipo. Por ejemplo, como un recetario que te diga cómo debes implementar una PMO. Lo curioso es que no se encuentran muchos artículos que te digan cómo hacerlo y esto tiene una razón de ser por la naturaleza misma de una PMO pues no puede ser una PMO igual para todos, no tendría mucho sentido porque una PMO entenderás depende mucho de la organización a la que va a implementarse, si es grande, si es pequeña, dependen de las funcionalidades, el nivel de gobierno que vaya a tener, en fin. Por esas razones es que no se encontró mucha evidencia que diga cómo se debe generar una PMO. entonces eso ayuda un poco para definir también el alcance lo que iba a ser la investigación. Entonces lo que se hizo fue proponer un marco de trabajo pero que tenga muchos puntos a analizar incluso al momento de implementar, es decir, desde el inicio se planteó que no se puede implementar por implementar pues tiene que haber una justificación a nivel organizacional incluso una justificación económica como un business case o para qué serviría una PMO. Se planteó también el tema de cuáles son los signos que te indican en la organización para que tú puedas definir una PMO, entonces, se armó este marco de trabajo inicial, donde se pone la justificación, se analiza la organización, cuáles son las fortalezas la organización, cuáles son sus debilidades para de acuerdo con eso ir armando una PMO que vaya acorde la realidad de la organización. Entonces no es algo muy estricto, no es muy algo muy armado así de forma rígida sino más bien es muy dependiente de la organización. Entonces esa primera parte ya se levantó, se definió una visión y misión de una PMO asociada a una organización, su nivel de gobierno y todo eso. Lo que faltaría o lo que yo te mandaba a ti como parte del correo es la segunda parte de esa propuesta, porque tú entenderás que en una PMO se definen, también, las funciones como: la PMO va a encargarse mínimamente de capacitar, de definir un estándar, de hacer que se sigue el estándar, de usar herramientas, en fin. Eso es mínimamente lo que tiene un PMO, también tiene una estructura, va a haber un PMO líder y luego va a haber los jefes de proyecto y de repente un asistente que te ayude con la documentación, es decir todo esto ya está definido. Qué es lo que se hizo para esta segunda propuesta, invitar a los participantes, porque en la primera propuesta se corrió y resultaron algunos resultados cuantitativos que ya se tienen, pero luego se vio que esto debería mejorarse. Entonces se propone una segunda parte, que es lo que te he compartido, en el PDF puedes ver que son puntos adicionales, no vas a encontrar ahí el framework completo porque como te dije la primera parte ya pasó, se evaluó y este sería como que lo complementario a una PMO. ¿Hasta acá me vas entendiendo el contexto? Ya, perfecto. Entonces entendiendo que lo que tú tienes ahora, si quieres mejor también lo compartimos acá para ayudarnos, entendiendo que eso es lo que sería la segunda parte, la idea contigo es tú como experto me puedas dar tu opinión y decirme. Por ejemplo, si vamos al primer punto que tú ves roles y responsabilidades, entonces al margen de los roles que como te he mencionado son los básicos que tienes, un PMO líder o un jefe de proyectos, en fin, yo por ejemplo acá en la propuesta digo: En vista de que eso es lo básico necesario y en vista a la realidad también que muchas organizaciones tienen, es necesario definir un jefe de proyectos de innovación y desarrollo, que puede ser un mismo jefe de proyectos que tenga doble rol, no necesariamente es un nuevo personal pero puede compartir ese rol. ¿Por qué? Porque se ve la necesidad de que las nuevas tecnologías también tengan un papel preponderante en las organizaciones y acá metemos por ejemplo el tema de RPAs. Que esta persona tenga la necesidad de traer a la organización tecnología que puede implementar porque va a conocer a la organización, la va a conocer desde adentro, entonces te puede decir: oye no, en vez de sacar estos proyectos por acá, usemos esta nueva tecnología que puede ser el RPA de repente temas de usabilidad, en fin. Temas que puedan implementarse en una organización de cara a mejorar los procesos o de cara a entregar incluso los proyectos de repente de una mejor manera, con una mejor tecnología. ¿Tú consideras, dentro de lo que tú has visto en tu experiencia gestionando proyectos y PMO, un rol de este tipo tú crees que realmente sea útil en una PMO o tiene alguna condición, o consideras que de repente no es no es útil para una PMO? Entrevistado 2: Mira primero una consulta ¿La PMO que tú estás proponiendo es de carácter interno o de carácter comercial? Me explico un poco más ¿Es para llevar proyectos internos de la empresa o una empresa que va a generar? BM: ¿Una empresa que gestiona tus proyectos? No. Esta es una PMO interna, estamos hablando que cualquier empresa que quiere armar una PMO interna. E2: Ok, para proyectos internos, cero cadena de valor a ti en este caso. BM: No hacia afuera, si te refieres a eso. Imaginemos el área de IT de una organización, se tiene una cartera de proyectos y cada uno lo gestiona como lo ve. Pero imaginemos que queremos centralizarlo y crear una PMO, entonces esa sería la idea de una PMO para dicha organización. Algo así sería el enfoque, entonces en ese enfoque aparte de los roles comunes que tienen una PMO. ¿Un rol de este tipo tú crees que genere valor en la PMO? E2: Sí, claro que sí, y ahí lo vemos porque dependiendo de este tipo de proyectos, de un proyecto de innovación, la persona o la oficina debe contar con los conocimientos de las últimas tecnologías o de las tecnologías emergentes para poder implementarlos y obviamente dirigirlos; debe conocer cuál es el alcance de esa nueva tecnología y cómo se aplicarían dentro de la organización. Para ello se tiene que tener el conocimiento y ya sea de esta persona o de una tercera persona, llamémoslo: consultor externo que tú contrates para que se analice este tipo de proyectos no este tipo de tecnología que puedas, que desees o requieras implementarlos. BM: Entonces tú consideras que un rol de este tipo sí genera beneficio en una PMO, por el mismo hecho de que podría traer como tú dices; la aplicación en tecnologías emergentes que puede incluso facilitar el desarrollo de algunos temas y proyectos. E2: Así es, y también está sujeto a la naturaleza de las empresas. Qué tanto la empresa le va a generar una ventaja competitiva los proyectos de este tipo o utilizar tecnología de este tipo y llamo tecnología de este tipo a la tecnología de última generación emergentes. BM: Perfecto, está bien vamos a hacer lo siguiente. Esa es la idea, es la de tratar de ver cada punto y ver tu percepción. Ahora este punto es un poco más largo, pero lo vamos a resumir para no tener complicaciones. Dentro de una PMO, cuando uno la define, tiene una estructura, tiene sus funciones definidas. Sabemos que al inicio incluso la PMO generalmente depende de la gerencia o en la dirección de IT primero y luego esta puede ir creciendo a tomar ya un nivel más alto; a nivel del directorio de repente, dependiendo también la importancia que le brinde la organización al PMO. En ese sentido se tuvo a bien considerar que normalmente una PMO al inicio solamente le dan como que estos son tus proyectos ejecútalos, obviamente dentro de lo que tiene que ser los estándares que esté monitoreando todo, pero se vio también la necesidad y por eso se plantea en esta propuesta segunda que la PMO debería ejercer un rol también de priorización de los proyectos es decir me pueden entregar 10 proyectos, 15 proyectos, pero éstos tienen que ejecutarse de acuerdo a una priorización que son unos criterios que se definen dentro de la organización y lo define el negocio en sí mismo. La PMO no debería definir esos pesos o esos criterios sino el negocio. Entonces, en base a eso se siguió acá un poco la metodología de gestión de portafolios del PMI que te indica que cuando tú tienes una cartera de proyectos, primero identificas los proyectos, luego los categorizas por algunos criterios que te da el mismo negocio, te puede decir estos son requerimientos del propio negocio, estos van para mejorar el proceso, para automatización de procesos o es un tema legal, por ejemplo. Y una vez que tú los categorizas, se procede a evaluar los proyectos, estos puntajes te los tiene que dar el negocio ¿Cuándo es un nivel bajo?, ¿cuándo en su nivel medio? o ¿cuándo es un nivel alto? Por cada categoría tendrías que tener un puntaje que te asigne y a su vez también que tanto están algunos criterios propios ya del proyecto; por ejemplo, que tan alineado está a la estrategia organizacional, que tan costoso es, que tanto en plazo represente la ejecución del proyecto o dependiendo de la categoría que puse por acá. Pero cada uno, si te das cuenta tiene un peso cuanto más alineada por ejemplo pesa 30%, si es el tema del costo es el 20%, plazo 20% y las categorías pesan 30%, entonces se hace como una matriz de puntaje por cada proyecto identificado y se va dando un puntaje. Al final lo que tú tienes es una tabla de este tipo. Incluso se dice que, si por ejemplo hay organizaciones que, para el tema de costo en realidad es una disminución, por eso le restan. Cuanto más costo es, menos puntaje debe tener, se hace la aclaración acá, entonces se hace una tabla, se pondera y finalmente se tiene una tabla de este tipo. Por ejemplo, esto es una tabla de priorización de puntajes. Coges un nivel mínimo dependiendo la organización o la organización te puede decir: Solamente voy a trabajar con los puntajes 1 hacia arriba por ejemplo. Y de acuerdo eso armas esto y luego haces tú matriz de prioridad entre ellos. Ok ya tengo todos los que se deben ejecutar porque son mayores a 1 pero luego entre ellos se hace como una matriz doble entrada para decir cuál va primero y finalmente tienes un resultado de este tipo. Ok, de lo que yo vi tengo este resultado y estos son mis puntajes de priorización, entonces la PMO lo que tiene que hacer es entregar esto al negocio de nuevo y decirle: Esto me salió. Ya el negocio decide o me lo confirman y me dices vas así, me lo puedes cambiar o depende decir: No esto tiene que ir arriba como acá se da el ejemplo. ¿Qué pasa si tienes un proyecto del tipo legal? Si es un proyecto del tipo legal por más bajo puntaje que tenga tiene que estar dentro de la lista, porque no puedes eludir esa implementación. Entonces lo que se propone en esta propuesta es que la PMO debería ejercer este rol también no solamente recibir los proyectos, sino también ejercer un tipo de control a través de la priorización, pero dando finalmente la última palabra del negocio para que finalmente te confirme, debo yo hacer estos proyectos en este orden. Y es más podría ayudar diciendo por ejemplo; de acuerdo a la unidad de negocio me ha salido de este modo. Le ayudas al negocio es decir mira tengo muchos proyectos en finanzas, de repente cambia el orden o varía lo dependiendo la categoría también, es decir le das toda la herramienta para que el negocio finalmente te diga: si está bien este orden que has ejecutado tú, hazlo así o de repente cámbialo. Que éste vaya primero dependiendo de repente si estamos dando muchos proyectos a un área o si damos muchos proyectos a un tipo de categoría. Entonces lo que se propone o bueno incluso acá se dice que en esta parte se ilustra un poco cómo es el proceso de solicitud de nuevos requerimientos, se agrega normalmente en la PMO una parte de priorización que no existía. Tiene que haber una tarea que ayude a priorizar para que finalmente se dé la autorización del proyecto. Pero lo que se ha tomado es un poco la iniciativa del PMI y la gestión de portafolios para el que la PMO tenga, digamos un rol también importante al momento de hacer la priorización. Ahora mi pregunta acá sería ¿Tú consideras que la PMO sí debe tener un proceso este tipo o consideras que eso más bien debe ser hecho fuera del PMO, de repente lo debe hacer el negocio en sí mismo que te merece qué opinión te merece este punto? E2: Sí lo debe hacer, la PMO debería tener un área qué nos categorice los proyectos. Y una consulta que tenía acá ¿Has tomado en cuenta la prelación de proyectos? BM: Claro esto se ve acá. Prelación te refieres a ¿si uno depende de otro? E2: Así es. BM: Por eso lo tienes acá precisamente, una vez que te salen todos los altos, te salen como prioridad alta. Pero, ahí es donde haces está doble, entonces dices: Oye, ¿Pero este proyecto se debe ejecutar primero que cualquiera de estos? y acá te sale sí; porque es una condición, entonces le das el 1. Si te das cuenta, al final este tiene un puntaje porque debe estar primero, sino le das 0 simplemente, quiere decir que no hay una relación. Entonces de esa manera también entre ellos puedes ver quién debe ir primero, esa es esta matriz de doble entrada que te hace eso. E2: Ok perfecto, tiene que ver mucho también la estructura de la empresa en cuanto a lo que te dije hace rato, la naturaleza de la empresa en cuanto a la toma de decisiones. Esto está perfecto y es el deber, ser en cuanto al modelo PMI verdad, pero qué pasa si la empresa no está tan madura como para seguirlo. Lo que tú estás diciendo o el enfoque de este proyecto es: Implementar una PMO, hacer como como un recetario para implementar un PMO y que pudiese o la idea es que funcione para cualquier empresa. Entonces este en ese caso pienso yo que debería tener en cuenta el cómo toman las decisiones esa empresa y adaptarla acá. La mejor práctica para proyectos es esta, pero está la empresa verdaderamente madura o tiene la madurez como para tener un proceso de estos, o que prioriza la empresa, para ellos que es prioridad. BM: Claro ese es un buen punto. Por eso es que como parte para salvaguardar eso lo que se propone acá, es que la decisión final la debe tomar el negocio. La PMO llega hasta darle, lo que cree la PMO que debe ser. E2: Las herramientas, exactamente. Ahora qué pasa si la empresa te dice: Mira sabes, no me sirve ese 7 que tienes ahí, ese 7 déjalo de último. ¿Cómo la PMO va a tomar manejar este tipo de toma de decisiones? Creo que deberías tener una sección aparte o aparte no, incluida acá y que te diga que dependiendo de la toma de decisiones que tenga la empresa o la madurez que tenga la empresa para tomar decisiones o no sé toma en cuenta acá, no está incluido este factor y nos enfocaremos solamente en el en el modelo del PMI. BM: Ok. Entiendo entonces tú sugerirías de repente agregar una parte final acá dice cuando la PMO entrega digamos este resultado y se entiende que el negocio revisa, toma una decisión y devuelve a la PMO el orden que ellos consideran adecuados. La PMO de alguna manera tendrían que no sé, se me ocurre tener algo registrado como un disclaimer decir ok yo te entregue algo, tú me entregas esto y se va a ejecutar de acuerdo a lo que tú me estás diciendo, a pesar de yo te dije otra cosa, se estaría cubriendo algo así, eso lo que tu sugerirías tener. E2: Así es, porque muchas veces no van de la mano la empresa y la PMO. BM: Perfecto, ya ese es el punto de gobierno, bueno, parte del gobierno se habla del escalamiento también, creo que esto es algo muy común en las organizaciones. Cómo es que tengan que llevarse a cabo estos escalamientos, cuando se hablan de incidencias, problemas o algo, bueno lo que se propone aquí es igual. Debe definirse como parte del proceso de gobierno de la PMO, un buen nivel de escalamiento, saber a los niveles que tú puedes llevar los casos y bueno dependiendo también hasta qué nivel lo puedes solucionar. Entonces va desde unos niveles muy básicos que lo puedes solucionar a nivel de equipo de proyecto o jefe de proyecto, hasta niveles que vaya al mismo comité la PMO, al director de TI; incluso puede llevarlo al gerente general o al directorio, dependiendo del impacto, criticidad del incidente que se presente. Entonces acá el punto en realidad es que debe existir algo de este tipo, porque a veces se ven que en las PMO todo se quiere solucionar a nivel de proyecto y no necesariamente es la mejor alternativa, si sobre sobre todo entendiendo que hay un impacto mayor o que puede ser grave en la organización. Entonces este punto lo que te dice es: Debes definir un nivel de escalamiento cuando ocurran este tipo de incidentes. Yo supongo que esto a nivel de gobernabilidad si es algo que tú también has visto se maneja este tipo. E2: Mira, aquí hay un punto importante que deberíamos tomar en cuenta es también la fase del proyecto en el que tú deseas de escalar algo. Normalmente tenemos un nivel de escalamiento 2D a un nivel de escalamiento 3D, porque en una arista tendríamos las X, sería por decir algo del nivel de escalamiento de las posiciones y en la Y tendríamos que estamos escalando y vamos subiendo a medida de qué factores se cumplen ¿Pero en qué fase del proyecto vamos a escalar algo? No es lo mismo escalar un cambio de alcance en fase inicial, a un cambio alcance en la que en la fase de implementación. Entonces ¿Aplicaría para la fase de implementación un nivel escalamiento igual que en la fase de inicio del proyecto? BM: Claro que no. El impacto es mayor, por eso hablamos de impacto, el impacto que puede ocurrir por el tema de costos, de repente dejarlo más explícito. E2: Si es entonces básicamente es eso no, lo que veo que deberíamos tener en cuenta también acá. BM: Otro punto también que forma parte del gobierno. Se habla sobre la comunicación, es decir; algo que también se ve que adolece mucho, a la vez que cuando se gestionan proyectos, es que no se comunican adecuadamente los resultados, avances, incidencias. Entonces lo que acá se propone es definir siempre una matriz de comunicación identificando también en los stakeholders a los que quieres llegar, los canales que vayas a usar, la frecuencia que vayas a reportar y quién es el responsable de hacer esta tarea. Aparentemente esto es algo sencillo que incluso el mismo PMI sugiere en su área de conocimiento de comunicaciones, pero es algo que también no se suele hacer cuando se define una PMO al menos de manera estructurada. Entonces lo que se pretende acá es definir incluso los tipos de mensaje que se puedan dar como te digo categorizando por el stakeholder al que quieres llegar, el canal, la frecuencia y el responsable, entonces eso es algo que también se tiene que definir y se propone acá, definir esta matriz de comunicación a nivel PMO. No estamos dando sólo a nivel de proyecto sino a nivel de PMO, por eso puedes ver que tienes desde reportes de avance, el uso de recursos, hasta los temas de desempeño, lecciones aprendidas, decisiones de gobierno que pueda tomar la PMO, actualizaciones de riesgo e incidente, en fin. Entonces este punto creo yo es muy importante no sólo en la ejecución de proyectos sino también se identifica como parte crucial al momento de comunicar resultados de PMO. En este punto ¿tú harías alguna sugerencia adicional, considerarías que se debe tener otra consideración para comunicar? E2: No, realmente lo que sugiero aquí es que se cumpla, es lo más importante, que se cumplan los procesos de comunicación en las diferentes áreas y en las diferentes fases, porque es tan sencillo como lo plasmas acá, pero puede ser tan difícil hacer que se cumpla como no tienes idea, básicamente es eso. BM: Perfecto, a ese punto también vamos a llegar, el tema del cumplimiento es algo que también se propone en esta fase. Pero sí, está perfecto. Vamos a avanzar. En el tema de las funciones como te decía, una PMO normalmente cuando nace, tiene las funciones básicas conocidas: Tienes que capacitar, tienes que documentar, tienes que definir todo estándar o metodología que vayas a usar, tienes que hacer el monitoreo, el seguimiento. Esa es la definición básica que tiene normalmente una PMO y de eso como te decía se propuso en la primera parte del trabajo. En esta segunda parte que es como un complemento, es como una mejora que se hace. Se identificaron funciones adicionales que también rápidamente te las voy a mencionar y que creo que será importante que tú digas si consideras que deban tener esas funciones o de repente no genera mucho valor en este tipo de funciones y ahí justo regresamos al tema. Se habla mucho la función de hay que definir estándares, definir métodos, pero lo importante también seria es que se cumpla, entonces acá la función ya no solamente es la que tú propones, la que tú indicas y le digas a los jefes de proyecto: Oye vas a usar esto, sino ya tú tomas un rol más protagónico y dices: “Voy a auditarte”, vamos a empezar a ver qué estás haciendo, de qué manera; hay un acompañamiento como ves acá y se coloca un acompañamiento más cercano sobre el tema de los proyectos, no solamente el seguimiento control, sino propiciar estas reuniones con stakeholder para ir llevando un registro de todo lo que se va haciendo, como una bitácora del proyecto, es decir ir más al detalle ya desde la PMO. Hacer ese acompañamiento y ese seguimiento. Acá también hablábamos, canalizar con él, gestionar la comunicación, es lo que también hablamos, ya no solamente propone sino ahora vas y tú mismo te encargas de que esto se cumpla, que se siga; haces las reuniones para comunicar o dónde lo vas a comunicar, de qué manera divulgas los resultados es decir tomas un rol más propio en la gestión del proyecto como PMO, no dejas tanta libertad al jefe de proyectos, sino ya estarías atrás de él haciendo que esto se cumpla. Esto es algo que se añade también, porque se vio en la primera parte, se pasó mucho a la propuesta de: ¡ah! vas usar esto y esto. Pero no había un tema un poquito más de control vamos a decirlo de estar atrás de cumplirlo, por eso que se agrega también acá otras funciones de control, igual como centralizo esta información del estado del proyecto también porque puede tenerlo cada jefe de proyecto, pero donde lo llevamos, donde lo tenemos centralizado para luego esto poder divulgar a los stakeholders también. Y acá hablaba de las auditorías por ejemplo la PMO también debe tener lo que te decía una forma de controlar y ver que se cumpla todo lo que digo, si voy a registrar lecciones aprendidas entonces ok, no quede solo en el registro, sino como yo verificó que realmente se aprendió la lección, que hiciste tú con una selección aprendida. La función va más allá también si te das cuenta, entonces la PMO empieza a tener un rol más estricto dentro de lo que se habla. Y en la parte de la gestión de los recursos también se vio que el PMO debería involucrarse más fuertemente con recursos humanos, porque a veces se ve también que desde la PMO pues se dan como que los perfiles y es recursos humanos finalmente quien te trae el perfil, según el entendimiento de recursos humanos, pero sería mejor que sea la PMO que esté con recursos humanos, en como definen estos perfiles, como intervienen para que el personal más idóneo venga a trabajar a la PMO, tiene que ser un trabajo más de la mano con ellos, para evitar idas y vueltas en el que recurso humano se entiende que debe ser un perfil adecuado, pero de repente el PMO no está al tanto de ello, entonces como que hace una simbiosis con recursos humanos para atraer la gente adecuada porque la misma PMO participa ahí, en ese reclutamiento por así decirlo. El tema de los de los gastos también, se sugiere que la PMO no solamente reciba un presupuesto, sino también empiece a definir ellos mismos el presupuesto y también tenga control sobre esos gastos y rinda cuenta cómo deba ser, entonces eso también ayudaría en el tema de la gestión del proyecto entonces. Como te das cuenta se han agregado o se proponen digamos tener a estos niveles, que se le llama a nivel de conocimiento, al nivel de control y al nivel de recursos funciones adicionales al PMO ¿Te hacen lógico, te hacen alguna lógica estas estas funciones, consideras que son pertinentes dentro del PMO? E2: Obviamente si son necesarias, no diría pertinentes, sino necesarias para cualquier PMO y obviamente si lo necesita un proyecto lo va a necesitar una PMO obviamente, pero una consulta ¿Tu incluiste en la tabla de comunicaciones de PMO lo que se necesita comunicar en cuanto a control? BM: En general varias cosas, no solamente el control, porque por un lado cómo te pone acá avances o indicadores desempeño de proyecto, incluso uso de recursos, sino va más allá, lección aprendida, temas de gobierno, actualización del riesgo de incidente, desempeño mismo de la PMO, logros del proyecto. Entonces se trata de dar la mayor cantidad de información, no sólo a nivel de proyectos, sino a nivel de PMO. E2: Fíjate por ejemplo en el tema de utilización de recursos, la utilización de recursos, el contenido mensaje está bien. Yo recomendaría el estatus de los recursos, estatus de los recursos, porque también aquí abajo estás recomendando que vamos de la mano con recursos humanos a contratar el personal adecuado. BM: ¿Cuándo dices estatus de recursos a qué te refieres, a ver el tema contrataciones? E2: A comunicaciones, en los temas de comunicación. BM: ¿Pero comunicarías ahí, el proceso que se está siguiendo para reclutar a eso algo así? E2: Para reclutar y en qué estatus va, no el proceso que se está siguiendo, sino en qué estatus. El proceso para reclutar, ya lo tiene recursos humanos definidos, pero vete tú a la experiencia propia ¿cuánto demora recursos humanos para contratar a alguien? Estamos conscientes de que nos vamos a demorar tanto tiempo o cantidad de días o cantidad de meses en reclutar a alguien, eso hay que comunicarlo y mucho más obviamente si los proyectos dependen de eso. BM: ¿Tú consideras que debe haber más visibilidad del tema cuando armas equipos en los proyectos, como va ese armado de equipos? E2: Exactamente ahí va. En todas las funciones relacionadas a gestiones gestión de gestión de recursos, por ejemplo, gestionar habilidades, la asignación y la capacidad de los recursos, la contratación, cómo va el proceso de contratación. Que muchas veces eso lo tenemos y eso es un input obviamente de recursos humanos, a ver cómo vas, pero quién le hace seguimiento a eso de la PMO, del lado de la PMO, quién lo hace y quién lo comunica. BM: Es un buen punto que se puede añadir acá, estoy anotando para considerarlo entonces. E2: Métricas igual, definir métricas de medición y básicamente eso es lo único. Un punto importante acá también, no sé si tomas en cuenta los temas de seguridad de información, acá un rol importante sobre cualquier proyecto. BM: Comunicar sobre temas de seguridad de información. E2: No tanto comunicar, sino un rol importante sobre el proyecto. BM: Pero sería algo al nivel como había uno de innovación, uno que conozca de seguridad y que también aporte. Ahora yo te preguntaría no más sólo como para para aclarar ¿Por qué tú lo consideres que forme parte del PMO? y por ejemplo no si te preguntaría ¿Por qué no lo invitamos a alguien de por ejemplo del área de la IT misma? ¿Qué ventaja tendría a traerlo a la PMO? O que sea alguien como consultor de la misma área de IT. E2: Pueden ser de las dos formas, dependiendo de la cantidad de proyectos que manejen la PMO, porque si tú vas a trabajar con una cantidad pequeña de proyectos, se puede traer cómo un consultor del área de IT, pero sí si tú vas a necesitar a alguien tiempo completo para trabajar en este tipo de proyectos, debería formar parte. BM: Va a depender de la magnitud de la dimensión de la PMO en realidad. Es bueno no se había ocurrido. E2: El tema es que antes no se tomaban en cuenta, porque no teníamos un universo tan automatizado o no nos estábamos pasando tanto en la tecnología como para para sacar una ventaja sobre los demás, ahorita no, ahorita todos estamos en eso y así como han crecido el área tecnológica en todas las áreas, en todas las empresas. También ha crecido el tema de ciberseguridad, de delitos informáticos, de hackeo y tenemos que estar preparados para eso BM: Ahora, los últimos dos temas que quedarían, serían el tema de las métricas, en realidad en la primera parte se miden las métricas básicas de desempeño a nivel de proyecto, cómo cumplen con los tiempos, cómo se cumplen con los costos, cómo se cumple con la calidad, eso es lo básico que tiene la PMO. En esta segunda propuesta se agrega más bien otros indicadores, que van de la mano con todo lo anterior que se ha visto, es decir cómo medimos por ejemplo, la facilidad que se tiene para tomar las decisiones, por ejemplo nos dice: Facilitar la toma de decisiones proporcionando una información oportuna y significativa sobre la gestión de proyectos. Entonces qué es lo que me dice acá, que yo debo enviar precisamente y se radica acá el punto, en la comunicación que yo debo reenviar adecuadamente, a tiempo y cumpliendo todos los informes de proyecto, para que las direcciones tengan un input a tomar decisiones, entonces son indicadores medir eso precisamente, lo que es el cumplimiento de envío de informes de proyecto, que ayude a tomar decisiones oportunas. Del mismo modo cómo gestionar las expectativas de stakeholder más importante, igual lo como éstos se sienten respecto a que la ejecución lo amerite, cómo siente satisfechos con el trabajo de la PMO, ¿Está haciendo la PMO lo que creían los directivos que debe hacer? ¿Cómo gestionas esas expectativas? Otro es a nivel de marco de gobierno, realmente puedo medir o debería medir el porcentaje de proyectos que se vienen desarrollando y que estén alineados a la estrategia organizacional. Entonces estos indicadores, como te das cuenta, ya no son más a nivel de proyectos, sino a un nivel más arriba, más al nivel de la PMO en sí misma; estos son digamos una muestra pequeña de lo que se propone, pueden haber más, pero digamos si vemos estos tres indicadores ¿A ti te hace también lógica tener un indicador a ese nivel? E2: Como te lo dije ahorita, dependiendo de la madurez de la empresa, porque puedes puede haber empresas que te digan: Sabes, no me importa que estén alineados a la estrategia organizacional, no me importa que lo midas, sino porque son imperativos los proyectos o por ejemplo: Mira, me interesa porque esta es una estrategia a largo plazo y esto es uno de los tantos proyectos que van sobre la estrategia a largo plazo y quiero ver cuál es el avance, en cuanto a cumplir o a seguir nuestra estrategia organizacional. Pero veamos una organización enfocada en innovación, para que tengas una idea. Aquí es a cinco años y nos van bombardeando proyectos, tras proyectos, tras proyecto, tras proyecto año-año, pero todo es enfocado a la meta de los cinco o diez años. Ahora yo estoy totalmente seguro de que una empresa como ésta tiene unos indicadores que le digan a la alta dirección: Mira, cómo vamos en cuanto a madurez organizacional y en cuanto a madurez estratégica BM: Y fíjate que ese es el último punto que se plantea también en esta propuesta, ya para terminar. El último punto es precisamente la madurez lo que se indica acá y siguiendo un modelo que la universidad CARNEGIE MELLON propone, es seguir un modelo de project management maturity model, pero lo que se hizo acá es adaptarlo, no a un project management, porque no estamos a ese nivel, sino a una PMO ¿Cuál debe ser el modelo de madurez de una PMO? Como hemos hablado casi en toda la llamada, mucho hay una dependencia fuerte del nivel en que se encuentra la PMO Entonces lo que esta propuesta te dice: es posible y es más que seguro que tú empieces creando tu nivel 1 de la PMO, vayas a un nivel 2, vayas a un nivel 3, un nivel 4 y un nivel 5, obviamente cada nivel es una serie de puntos a cumplir, como te decía solo la propuesta a luego ver que funcione y en fin, vamos haciendo así los niveles. Y lo importante de esta propuesta es que acá te da como una idea de cómo debe ser, por ejemplo, al inicio te dice: Tú probablemente te sitúes acá, porque te da características para evaluarte, te dice primero tú puedes decir que no tienes definido tu proceso gestión de proyectos, el apoyo que tú brindes como PMO es muy a demanda, porque no tienes todavía el personal o incluso tienes gente que todavía no tiene formación propia en gestión de proyecto, entonces puede decirte que estás a un nivel todavía inicial ¿Que necesitas tú para ir a un nivel repetible? Ah, yo tendría que tener que el comité de PMO establezca y documente los procesos de gestión de proyectos, que yo define el plan de formación y una vez que logró estos puntos que he colocado acá, yo puedo decir que ya puedo escalar a un nivel repetible. Igual para el nivel repetible, te ponen acá consideraciones para que tú te me das, ok ya tengo el proyecto o el proceso de gestión totalmente documentado ya abriendo apoyo más a tiempo parcial, ya tengo formación de gestión disponible pero limitada aun, igual ¿Cómo hago para avanzar de repetible al siguiente? Me definen pasos, entonces lo que trata de decirte en esta propuesta es, para que tú te defiendas la PMO, de repente al inicio no necesitas correr, a nivel 1 necesitas avanzar paso a paso y es un trabajo de repente de largo aliento, porque el PMO al inicio como hablábamos también, de repente no va a estar al nivel del directorio, va a estar solamente dependiendo y reportando en un gerente de TI por ejemplo, pero poco a poco al nivel de que ellos van haciendo estables sus procesos o van mejorando, pueden avanzar como se ve acá, a cada uno de estos niveles de madurez de la PMO Por lo tanto, ¿Qué es lo que busca con esta propuesta? Es dar una idea a las personas que van a implementar la PMO, de que pueden ellos ir poco a poco, con algunas líneas base que se le pueda definir para que ellos en base de eso se empiecen a medir y luego empiezan a avanzar y a crecer en sus niveles de madurez. ¿Es un poco también lo que tú tenías en mente cuando hablamos niveles de madurez? E2: Así es, solo una sólo una observación ¿Todos estos puntos como los mides? BM: La idea, como te decía, el tema del PMO va a tener que ser incluso medio iterativo porque va ir creciendo, la idea incluso en uno de los niveles te dice: Que tienes que definir sus propias métricas y hacerle auditorías, esto mismo en sí mismo de por sí requiere también ser controlado, por ejemplo, hablábamos como más arriba también. Bueno no están acá las métricas iniciales como te digo, está la propuesta inicial, pero en las métricas iniciales ¿Cómo mido yo que estoy siguiendo un buen proceso de gestión de proyectos? Porque tengo métricas que me dicen: Cuál es el tiempo de cumplimiento en tiempo de los proyectos, cuál es el porcentaje de proyectos que se entregaron dentro del presupuesto, por ejemplo, esas métricas te van diciendo qué tanto estás aplicando tú una metodología y que tanto resultado te está dando; entonces cada nivel debería tener también sus propias métricas que te ayuden a medir esos niveles, esas líneas base que hablábamos Lo que tu más bien indicarías; sería como hacer un match entre ok, estos son los niveles de madurez y deberías también tener sus propios indicadores que te ayuden a ir viendo cómo avanza, eso es un poco entiendo tu observación acá. Listo ¿Algo más que quisiera agregar sobre este punto? E2: No, está bastante entendible y también capaz los indicadores que tienes arriba en la primera parte les pueden servir si no es a todos, a más de una de estas fases, de estos niveles y capaz dependiendo de por ejemplo este nivel de formación en gestión de proyectos, bueno si llegas a una puntuación de 2 estás en la fase inicial, pero si llegas a 5 estás en la fase de repetible o si llegas a las 7 están definidos. BM: Una escala de medición. E2: Una escala de medición teniendo en cuenta si el indicador se aplica para cada una de las fases. BM: Claro porque tú también podrías medir la formación haciendo evaluaciones podrías hacer a los jefes de proyecto, podrías evaluarlos también, estarías en tu derecho. Vamos a hacer una evaluación de metodología, lo conoce o no lo conoce, como lo que vas a hacer tú ahora en tus auditorías ¿Conoce o no la auditoria? Si sales bajo quiere decir que esto no está maduro, está muy básico todavía. Listo, bueno eso era todo, de verdad mil gracias por el apoyo créeme que has dado muchos inputs valiosos que van a ayudar a mejorar la propuesta para hacerla muchísimo más flexible, porque es la idea que sea una propuesta flexible, que tenga la persona que quiere aplicarla, todas las herramientas o todo el panorama, ya dependerá del que usa. Pero se le está tratando de brindar todos los puntos que él debe considerar, al menos ese es el objetivo; tiene que mirar todos estos puntos. Dependiendo de la madurez, sabrá qué aplicar y que no se va a aplicar. Entonces apunta a lo mínimo de repente por ahora pero igual se le da toda la visión de lo que debe tener la PMO. E2: Así es. BM: Perfecto. Listo. De verdad gracias por tu valioso aporte. E2: De nada. Gracias a ti por la invitación. Anexo 5 – Transcripción de la Entrevista 3 Braulio Murillo: Buenos días, gracias por tu disposición. Quería preguntarte si es que lograste ver este documento que te había compartido, sino rápidamente lo podemos revisar. Entrevistado 3: Le di una mirada rápida pero no lo llegue a revisar completo. BM: Te comento primero como parte del contexto, lo que se espera de la llamada de hoy. Lo que pasa es que he venido trabajando con Toño, una propuesta de una PMO, como uno debería implementar una PMO, normalmente son como unos lineamientos, como tú sabes no puede ser una propuesta estricta, porque la PMO va a depender muchísimo en realidad de la organización, de su cultura, de su estructura, en fin. Entonces, se armó una propuesta de la PMO con Toño, que va desde el tema de roles, funciones, como va a ser su estructura, su gobierno y sus métricas. Se hizo una primera propuesta y se validó de manera cuantitativa, se midió sobre todo en base a los resultados en tiempo y costo, en la ejecución de proyectos. Pero luego también vimos en esta primera parte, que habría que hacer algunas cosas adicionales, algunas cosas complementarias, porque se vio que de repente había por ahí algunas cosas que se podrían mejorar en esa primera propuesta. Lo que está en este documento y lo que te compartí, es como una segunda propuesta donde se adicionan algunos puntos que se vieron, que se levantaron en esa primera parte. Esta segunda propuesta, por temas de tiempo, no se va a poder implementar y medir. Así que la alternativa que brinda Toño y que me sugirió fue verlo por una evaluación más cualitativa, preguntarles a expertos si consideran que estos puntos también deberían ser parte de una PMO en general. Por ejemplo, aterrizando un poco en la primera parte sería, si una PMO que ya tiene su definición de roles, ya tiene sus responsabilidades como el jefe PMO, los gerentes de proyecto, todo; ¿sería bueno y propicio agregar un rol que sea el de jefe de proyectos de innovación y desarrollo? Por ejemplo, que se encargue de traer o de hacer prospectiva de las tecnologías y ver de qué manera esto se puede aplicar a la organización, de diferentes estrategias de repente, haciendo reuniones con los usuarios, pero la idea es que traiga el conocimiento innovación y vea cómo se puede aplicar en la organización y obviamente en los proyectos que ejecuten la PMO. Se agregó, eso se podría decir que es un complemento a lo que ya se tenía. La idea contigo, es revisar estos puntos que se agregaron y en base a tu experiencia, porque sabemos con Toño, que manejas también muchos temas de portafolio de proyectos. Y conocer por cada punto si consideras que sería un buen aporte tener o considerar este punto como parte de la implementación del lineamiento, de la implementación de una PMO y saber el ¿Por qué? Por qué consideras que sería oportuno o de repente también de repente podrías decir no, no es muy bueno y por qué no sería muy bueno ponerlo, en fin. Esa es la manera de cómo podríamos llevar la entrevista de hoy, punto por punto, ése sería el contexto, no sé si hasta ahí tienes alguna pregunta. En el primer punto, como te decía, se vio que dado la organización donde se implementó y se recogió es: “Sí debería haber alguien que traiga el tema de qué tecnologías novedosas están habiendo”. Por ejemplo, RPA, que ayudaría una organización a que sus proyectos de implementación de automatizaciones, de repente se lleven mejor. ¿En tu opinión tú consideras que tener un rol, de jefe de proyectos de innovación de desarrollo dentro de la PMO? ¿Consideras que sí aportaría a los temas de ejecución de los proyectos, a la organización en general? ¿cuál sería tu opinión allí? E3: Una duda ahí, antes de responderte. ¿El marco que estás haciendo, está la implementación de una PMO, en algún sector específico o es genérico? BM: Es genérico en realidad, tratamos de hacerlo lo más flexible posible. E3: Es que ese rol en particular, tal y como lo estás describiendo, me parece importante para una PMO de tecnología o quizás hasta para una PMO estratégica, pero si es la PMO de un área específica, la cosa cambia. BM: Bueno, en realidad la PMO está pensada para gestionar proyectos de TI en cualquier organización, ahí va enfocado. E3: Ahora sí, ahí sí. BM: Ahora, una pregunta adicional a eso ¿Tú considerarías por tu experiencia que una PMO debería tener inicialmente ese rol como compartido o ya un puesto fijo? Porque a veces pasa, tú sabes, que en las PMO a veces comparten roles. Una misma persona hace un rol en una PMO, hacen rol en una unidad funcional. Este puesto, a ti te parece, que más bien debería pensarse a la larga en tenerlo fijo o de repente si podría ser compartido. E3: Yo creo que depende del tamaño de la organización. BM: Para el caso de TI, sí consideras que es valioso tener un rol de ese tipo. E3: Solo que no lo llamaría jefe de proyectos. BM: ¿Cómo lo denominaría? E3: No se me ocurre ahorita un nombre especifico. Entiendo que es el responsable de eso, pero, como jefe de proyecto, es el que dirige el proyecto y entiendo que esto está a un nivel un poco más arriba, no lo llamaría jefe. BM: Habría que buscarle un nombre, “un oficial de innovación” algo así. E3: Podría ser. BM: Perfecto. En el otro punto que también estuvimos revisando, sí se propuso algo en la primera parte del tema de gobierno, sobre todo tus sabes, en las PMO va a depender mucho y eso también se indica en la primera propuesta, dependerá del nivel que se le asigna a la PMO, si va a ser primero, una PMO que está adscrita a IT o si repente está PMO ya crece y ya no le reporta el director de TI, sino le reporta de frente al board, a los directores, al directorio digamos. Pero al margen de eso, en lo que se vio, es que como PMO, sí debería tener una estructura y un proceso para priorizar los proyectos, porque a veces la PMO, se le atiborra de proyectos y él solo ejecuta, ejecuta y ejecuta. Entonces lo que se vio, en base a lo que se investigó y a lo que ofrece el estándar de PMI en gestión de portafolio, es que debería tener un proceso de priorización. Y ese proceso de priorización, creo que ya lo conoces tú bastante bien, porque también tu tesis va por ahí, en portafolio, que va a todos esos pasos que es de identificación del proyecto, la categorización del proyecto, la evaluación del proyecto y acá bueno, se hizo tomando algunos ejemplos de proyectos de la organización y finalmente se detalla, cómo es que debe llegar a una tabla donde tengas los puntajes afinados de acuerdo a las fórmulas, estos puntajes te lo da el negocio y calculas, si finalmente vas a tener la comparación y priorización de los proyectos. Lo que se muestra acá es que debería existir este proceso en un PMO, porque te ayudaría también que como PMO, des un lineamiento de la priorización del proyecto. Acá mi pregunta sería ¿Tú consideras que sería bueno, sería oportuno, es necesario que la PMO cuente como parte de su estructura de gobierno, hacer este proceso de priorización? E3: Sí. BM: Y acá yo te haría una pregunta, porque también un poco salió en las discusiones con otros expertos. La PMO, para tu opinión ¿Debería entregar la lista priorizada de proyectos? Que sería digamos el resultado, pero tú consideras que esta lista todavía pasar una revisión por el directorio o consideres que la PMO debería tener suficiente autonomía en gobierno para decir este es lo que me salió y esto lo que voy a ejecutar. E3: Lo que pasa, es que, más que pasárselo al directorio, yo considero, que el directorio debería estar involucrado en la priorización. BM: Debería participar en ese proceso de alguna manera. E3: Lo que pasa es que hay criterios que escapan a la parte objetiva y ese es el otro tema, cada empresa tiene sus propios criterios. BM: Claro, sus categorías, los pesos y todo, es muy particular a cada organización que le quiera dar. E3: Al final, lo que se puede hacer objetivamente, es una sugerencia que puede o no ser aceptada por el directorio, pero tú no le puedes chantar al directorio las cosas tampoco, por “A” o “B”, por alguna razón de negocio que no haya sido calculada, ellos pueden tener otra idea. BM: Perfecto. Finalmente, la PMO, te hace este cálculo y te dice esta propuesta, pero esa propuesta finalmente, como tú bien indicas, el directorio es quien te dice; claro, está bien o te puedes decir; no, en realidad hemos visto que esto debe ir primero por un tema legal, un tema que acaban ellos de ver y cambia acá, se corrige digamos. ¿A eso un poco te refieres? E3: Sí. BM: Otro punto de, bueno acá también se hace un análisis de qué tanto los proyectos se pueden categorizar por área y bueno acá se agrega esa parte en el proceso de priorización, es lo que se muestra en este en esta propuesta. Y en cuanto al escalamiento, quisiera conocer un poco de tu experiencia, normalmente cuando hablamos de escalamientos, en niveles de escalamiento en una estructura como una PMO. Siempre se dice normalmente que el escalamiento va dependiendo de la complejidad del incidente, que puede ir desde un primer nivel que se solucione a nivel del equipo o va ir escalando hasta el jefe de proyecto, al gerente de PMO y así hasta el directorio. Esa escalación, que es muy tradicional, en tu opinión, es un nivel de escalación que también funciona en un PMO o deberíamos tener algunas otras dimensiones a considerar cuando uno habla de escalamientos de incidentes dentro de una ejecución de proyectos de un PMO. E3: Básicamente, el esquema es similar con una particularidad. No creo que el último nivel sea la gerencia general o, mejor dicho, creo que hay un nivel intermedio, que es justamente algún director o básicamente el sponsor que está impulsando los proyectos, que no necesariamente es el gerente general. BM: Claro entre el gerente de TI, el funcional y el sponsor, podría haber… perdón. Entre el gerente general y gerente de TI hay un intermedio que sería el sponsor, el que tú consideras que podría ser un nivel antes de llegar a ese nivel. Perfecto lo anoto acá. E3: Ajá. BM: Otro tema que también se vio en la parte de gobierno, es que las comunicaciones, si bien en la primera propuesta se vio que era una comunicación más del tipo seguimiento, control de proyectos, que es lo básico que debe tener la PMO, se vio también que había otros temas, que normalmente a veces no se considera como parte de la comunicación y acá se engloba. Por ejemplo, dice, hay que comunicar el reporte de avance, pero también otros puntos importantes como es la utilización de recursos, los indicadores de desempeño, lecciones aprendidas, qué decisiones se toman a nivel de gobierno, qué actualizaciones hay de riesgos, indicadores de desempeño de los recursos del PMO y los logros del proyecto, por ejemplo. Entonces, se agregaron algunos puntos adicionales, a lo que tradicionalmente comunica en el día a día una PMO y se pensó también a más alto nivel, porque a veces no solamente importa saber si el proyecto se da o no da, cumple o no cumple el presupuesto o el cronograma, sino ir más allá, ¿Realmente logro el objetivo, el proyecto que ejecuta la PMO o la PMO está ejecutando proyectos que realmente aportan a los objetivos? Tratamos de agregar información que vaya más arriba, no tanto se quede en el tema del proyecto, sino vaya más arriba. En tu experiencia también, cuando hablamos de esta parte de la comunicación, qué opinión te merece tener estos puntos a comunicar. Consideras que también aportarían en el tema de que toda la organización conozca lo que hace la PMO o agregarías algunos otros puntos, de repente consideras que son demasiados y no aportarían. E3: Yo creo que sí aportan, ahí lo que va a cambiar es la forma, la frecuencia en que comunicas toda esa información. Ahora hay una que sí me parece crítica, que no la veo en la lista, que es la comunicación de la PMO hacia el jefe del proyecto sobre el valor o el aporte que tiene su proyecto a los objetivos de la organización. BM: El proyecto que esté ejecutando el jefe de proyectos ¿Cuál es el aporte que tiene directamente a la estrategia, los objetivos que tiene la organización? Eso lo que me estás diciendo. Eso digamos, vamos a tratar de pensar. ¿Eso no estaría documentado en el Charter?, a qué línea de objetivos o estrategia está apuntando el proyecto, podría agregarse por ahí de repente. Porque entiendo que esa información como tú la pones, es como que, de una vez o eso puede ir cambiando, como para tener una frecuencia de comunicar. E3: No es que pueda cambiar y en teoría podría ir en el Charter, pero la experiencia marca que papel aguanta todo. Para que el jefe de proyecto y su equipo, porque además es una cadena, la PMO le dice al jefe proyecto, el jefe de proyecto le dice su equipo, para que sientan realmente la importancia del proyecto dentro de la organización. Y además porque cuando un jefe el proyecto conoce cual es la importancia del proyecto dentro de la organización, tiene ya una idea, de que, si necesita más recursos, va a poder pedir recursos adicionales o también puede tener la idea, de que como este proyecto no tiene prioridad y si necesito más recursos, ya fue. BM: Qué tan empoderados se pueda sentir, respecto a ese proyecto, ¿no? De repente eso se podría agregar como parte de… no, logros es al final. Sí, tienes razón, es un punto que lo voy a considerar, de hacerlo más explícito, “Cómo comunicó este impacto que tiene, el impacto de proyectos respecto a objetivos y estrategia y que lo conozcan todos los gerentes de proyectos”, tienen razón, lo voy a lo estoy anotando acá para para ver, cómo lo dejamos más claro. E3: Y hay una necesidad adicional, que yo identifico, que me parece, algunos dirían que es responsabilidad del jefe de proyecto y yo particularmente creo que es más responsabilidad de la PMO. Que es evaluar el nivel de satisfacción de tu cliente final, que en este caso serían las áreas funcionales. BM: La satisfacción, ahí la estás pensando tú, ¿si el proyecto que ejecutó la PMO cumple los objetivos que yo pensé? o en satisfacción, en cómo se llevó a cabo y como sé ejecuto el proyecto. E3: En cómo se llevó el proyecto. BM: Por ejemplo, si cumplieron las reuniones, si se cumplieron las fechas de la entrega de los alcances. ¿A eso te refieres? E3: Ajá BM: Creo que eso está, no acá, pero me parece que estaba como una métrica, en la primera propuesta, de repente ponerlo ahí o resaltarlo. Para la parte de las funciones, de nuevo repito, eso es un adicional, no vamos a ver acá la función del gerente proyecto, la gente del PMO que se encarga de listar los lineamientos, las políticas o, en fin, de las capacitaciones. No, acá estamos viendo ya, complementarios, no estamos viendo la de funciones básicas, entonces se vio esto, como complementario a lo primero que se había propuesto y acá, por ejemplo, vimos que sería conveniente tener funciones de la PMO que vaya al cumplimiento, es decir, no solamente preocuparnos en que la PMO te dicte políticas de usar este tipo de estándar, ciertos métodos de temas de administración de proyectos; si no ahora tener una función que vaya más al tema de cumplimiento, reforzar eso, reforzar el acompañamiento de proyectos también, como parte de la función de la PMO, y coordinar o centralizar las comunicaciones entre los proyectos. Entonces, por ejemplo, dado esta categoría de función, que es relacionar conocimiento, se consideró agregar estas funciones que debería cumplir la PMO. Respecto al control, por ejemplo, que debe ejecutar un PMO, vimos ahí que se debería agregar parte del control, ¿cómo centralizamos la información del estado de los proyectos para que éstos puedan ser comunicados más fácilmente en la organización? La PMO asume ese rol, de nuevo, de monitorearlo, la PMO primero debería realizar auditorías a los proyectos, “auditorias” entre comillas; es decir, que se esté cumpliendo, que se esté llegando a lo que se dijo que iba a llegar como objetivo, que se cumplan con los requisitos trazados. Y obviamente, también la auditoria, le permitirá tomar acciones correctivas de ser necesarios, porque se va a hacer, no solamente a la entrega del proyecto, sino también, durante la ejecución del proyecto. Y en el tema de la gestión de recursos, se vio el tema de cómo la PMO debe involucrarse más en tener esto de las habilidades, la asignación, en la capacidad de recursos humanos y de repente la PMO participe más, en el tema de cómo se contrata, cómo se busca que se cumpla con el perfil, que se entienda, que recursos humanos entienda el tipo de perfil que requieran, un trabajo más estrecho con la PMO y también que la PMO, sea más responsable y autónoma en llevar estos presupuestos que ellos requieren, para que se puedan llevar a cabo todas las tareas que tienen que hacer la PMO; por ejemplo, en los temas de cómo planificar sus capacitaciones, toda la tarea operativa. Estas funciones, como repito, se agregan a las que ya normalmente, uno conoce de la PMO, es como que un adicional, un complemento; esto que rápidamente te he mostrado para ti ¿Cuál es tu opinión, te hacen sentido tener este tipo de funciones también dentro de una PMO? De repente, cómo me has dicho en otros puntos, consideras, que de repente, debería más bien considerarse otro tipo de función en la PMO ¿Qué opinión te merece esto? E3: La PMO, tiene en realidad múltiples funciones, pero depende de qué tipo de PMO vaya a implementar la organización. En general, cuando yo implemento PMO en una empresa, lo primero que les pregunto es ¿Qué tipo de PMO quieres tener? Porque en base a eso, se definen las funciones; una cosa es una PMO estratégica, otra es una PMO de seguimiento, otra cosa es una PMO orientada al tema de aprendizaje, conocimiento. Claro que pueden tener todas, pero usualmente, eso es mucho, dependiendo del tamaño la empresa. BM: Ya, entonces acá, si yo propongo un lineamiento, tendría que quedar muy claro que las funciones que yo ponga en estos lineamientos, yo debería incluso proponerles, si es este tipo de PMO, deberías considerar estos rubros de funciones, si vas por acá, con este tipo, de repente considera a estos. ¿Es tratar de hacer ese match, entre el tipo y la función? Es lo que estoy entendiendo, porque puede ser que alguna función, no corresponda a un tipo de PMO ¿Ese es lo que me trates de decir? E3: Si, así es. BM: Ok, y esto que te estoy mostrando, como para poder entender mejor estas funciones. Por ejemplo, una de las que me dijeron; las de auditorías, osea, si estamos hablando de una PMO, que gestiona proyectos de TI, pero del tipo, que no sería tanto estratégica, sino más en las PMO de gestión de proyectos de TI, pensemos un poquito más orientadas, a la ejecución, a ser el soporte más bien, de las unidades de negocio, que se cumplan estos objetivos de negocio. Si yo digo, esta PMO tiene que hacer auditorías a los proyectos ¿Si haría sentido tener esa función, dentro de ese tipo de PMO? E3: Sí. Sí. BM: Va a depender entonces cómo oriento o cómo indico en el documento, a qué tipo va. Eso es un poco lo que te estoy entendiendo. E3: Claro, porque ahorita, en las PMO orientadas a tecnologías hay el tema, de que casi todas las empresas, están emitiendo transformación digital, ya sea por una unidad de transformación digital, ya sea trabajando directamente con TI o teniendo una oficina a nivel central, a nivel estratégico. Pero la PMO de tecnología tiene que trabajar también de la mano con esta con esta unidad. Entonces, dependiendo de la empresa y de la estructura que está manejando, las funciones pueden cambiar ligeramente, pero el tema de auditoría sí tiene sentido que las realice la PMO. BM: Bueno vamos a pasar al otro punto. En el caso de las métricas, como te había comentado también, inicialmente se definieron métricas muy puntuales, sobre cumplimientos de presupuesto, cumplimientos de cronograma, por eso se pudo hacer esa medición. En esta segunda etapa, lo que se ve es otro tipo de métrica, y creo que acá es lo que tú mencionaste en uno de los puntos anteriores. Por ejemplo, una de las métricas, que acá teníamos, que se quiso medir, porque se vio que se necesitaba tener, de alguno modo una línea de cómo vamos, es, ¿hasta qué punto la PMO realmente está cumpliendo con facilitar información oportuna a los principales stakeholders? sobre la gestión de los proyectos, entonces hay un indicador ahí, que te va diciendo, si se está cumpliendo con este envío de informes de proyectos. Otro punto era cómo gestionar las expectativas. Y ahí estaba esto de la medición, la medición del porcentaje de fracción del cliente, sí se tiene como indicador, ¿cómo gestionamos estas expectativas de directores, de clientes internos del proyecto? Ahí también, un indicador que mida esta satisfacción de repente acá habría que dividirlo, como también comentaste, si esta satisfacción va más con la ejecución encima del proyecto o de repente con los resultados a largo plazo de lo que te da el proyecto, si cumple o no, con los objetivos institucionales y qué tan alineado está la institución con estos proyectos, si tiene un indicador para ver si estos proyectos están alineados esta estrategia organizacional. Esto se vio como un complemento a los indicadores normales, básicos de gestión, que pueda tener una PMO, bueno acá hay un detalle de cada indicador cómo calcularlo, pero la pregunta en esta parte de indicadores sería ¿Qué opinión te merece en este tipo de indicadores? Si realmente sería buena idea complementarlo, a lo que normalmente tiene un PMO. E3: Claro que sí, solo que no entiendo muy bien la diferencia entre éstos y los anteriores, me refería esos de ahí y las métricas que definiste antes. BM: ¡Ah! Lo que pasa que las métricas que definí previamente eran más puntuales a los proyectos. Por ejemplo, era la métrica de qué porcentaje de proyectos que cumplen los cronogramas comprometidos, porcentaje de proyectos que cumplen o tienen un margen en el tema de costos ¿Cuál es el delta, que están cumpliendo los costos? Como que ahí estaba apuntando más bien, a la forma de ejecución de la PMO, más te medía eso. Acá estamos yendo más hacia arriba, a eso me refería un poco con la diferencia; sí, acá estamos yendo más hacia arriba, saber el tema, más de gobierno, de gestión. E3: Ah, Ok. BM: Finalmente, ya para terminar, este es el último punto que también se vio conveniente agregar, esto es un poco una idea en realidad, una propuesta, para que se tome como parte del lineamiento en la PMO. Cuando uno va creando la PMO, tú sabes que al empezar siempre va a un nivel muy incipiente, es decir, una PMO en un nivel inicial. Entonces, se tomó algunos ejemplos, como acá se menciona, del Project Manager Maturity Model y también, que lo proponía la universidad de Carnegie Mellon, entonces tratamos de definir, cómo nos podemos dar cuenta nosotros cuando creamos una PMO, de que la PMO necesita ir creciendo, madurando, es decir, cómo saber si la PMO que voy construyendo tiene que madurar y crecer a otro nivel. Entonces, se propone un lineamiento para tener niveles de PMO, que van desde un estado inicial, repetible, definido, gestionado y optimizado; pero a su vez se le da una indicación o como unas líneas base para que la persona que va a implementarla PMO, vaya viendo si va cumpliendo con esas líneas base y pueda ir pensando en aumentar el nivel o la madurez de la PMO. Por ejemplo, yo estoy en un nivel de madurez inicial probablemente, ¿Cuál va a ser mi identificación? Probablemente mis procesos de gestión no están totalmente definidos o estoy brindando todavía apoyo, muy a demanda, muy puntual algunos proyectos que me piden, todavía no tengo la formación en gestión de proyectos en todo el personal, digamos, que esas son mis características. Y qué iniciativa, yo debo cumplir para que pueda ir pensando en aumentar el nivel de madurez o que ya voy logrando ese nivel de madurez. De repente hay un comité PMO que establece y documento el proceso de gestión de proyectos, que ya defina un plan de formación de gestión del proyecto y se pone a disposición, por ejemplo, son algunos lineamientos. Y eso me lleva a un siguiente paso; el siguiente nivel igual, voy a tener algunos indicadores que me diga, a mira ¿cómo voy? Voy contando con el proceso de gestión totalmente documentado, ya tengo gente que va designado a tiempo parcial, ya no a demandas; ya voy con la formación, estoy dando la formación, pero todavía siendo limitada. Igual, qué lineamientos tienes para crecer de este nivel al siguiente, está acá. Se propone, esta escala de niveles y las iniciativas para ir avanzando del nivel a nivel. Eso es lo que se ha se ha propuesto en esta parte, como puedes ver acá cada etapa tiene un checklist, donde tú te vas identificando y otro checklist, donde tú vas diciendo si vas subiendo de nivel hasta llegar a un nivel totalmente optimizado. Esto sería una propuesta también, que le ayude a la persona que implementa a ver cómo puede ir madurando la PMO que está implementada en la organización. En base a tú experiencia ¿Cómo ves esto, consideras que sería un aporte, una ayuda para las personas que están implementando la PMO? E3: Sí, eso sí. BM: Te hago una pregunta, porque también lo he escuchado ¿Tú consideras también, oportuno, de repente a estos niveles de madurez o a estas formas de lineamientos, de repente definirle métricas? Para que les sea más fácil medir y ver, en qué momento puede ir logrando los niveles. E3: Eso sí es un poco complicado. BM: ¿Complicado de implementar te refieres? E3: Sí. BM: Aunque podría, de repente, ayudarse con algunas métricas que ya están definidas. Simplemente decir estás entregando siempre a tiempo, por ejemplo. Ver si alguna métrica de repente te ayuda a vislumbrar que estas, realmente, teniendo niveles óptimos para ir aumentando el nivel de madurez. E3: En realidad, lo que iba con complicado, es que yo el nivel de madurez, no lo veo a nivel de la PMO, lo veo a nivel de gestión de proyectos. Es decir, para mí es el nivel de madurez de la organización en lo que a gestión de proyecto se refiere, que involucra la gestión de los proyectos individuales más la PMO. Porque si sólo evalúo la PMO y dejó de lado la gestión de los proyectos, entonces, por más que mi PMO funcione bien, los proyectos pueden estar mal. BM: Ok, te entiendo. claro puedes tener todo un nivel, todo bien documentado, todo bien definido con políticas, pero a la hora de la hora, a la hora de ejecutar, no se cumple, ni siquiera con los cronogramas o los presupuestos, a eso un poco te refieres. E3: Ajá. BM: Bueno, habría que ver que va muy de la mano. Va a madurar la PMO en tanto madure su esquema de gobierno, su manera como está definido internamente, sus políticas; más como éste también se asegura que la gestión de proyectos se lleve a cabo adecuadamente, correctamente, cumpliendo con todo lo que se ha comprometido; ese debería ser el esquema, de cómo evaluar ese nivel de madurez de esta PMO. E3: Claro, yo trabajo usualmente, con un modelo de madurez, que inicia a nivel de la gestión de los proyectos. Primero evalúa que, en la organización, los proyectos realmente se estén gestionando y luego después de que pasas el nivel de gestión de proyectos recién entras a un nivel de gestión de portafolio, que es donde encaja más la PMO. BM: Ese esquema, ese modelo ¿Es una propuesta del PMI? E3: No, es una propuesta de hace varios años, que definía un modelo de madurez para la gestión de proyectos; aunque bueno, de alguna manera tiene que ver con lo que era OPM3 también, que publicó PMI y que luego le dio de baja, porque ahora la idea es trabajar bajo el esquema de Organizational Project Management; solo que en ese estándar no hay un modelo de madurez. Pero digamos que coincidían, en que el primer nivel es la parte de gestión de proyectos y a partir de ahí ya viene las funciones a nivel de gestión de portafolio o de la PMO. “Primero gestiona bien tus proyectos, antes de querer gestionar bien un portafolio”. BM: Eso, sí es un buen punto, que de repente se puede colocar de manera explícita. Que es un poco también, por acá, si te das cuenta, acá, todo es a nivel de proyecto todavía, es como que tu primer nivel, después ya puedes ir avanzando otras formas de madurez. Perfecto, me queda claro, no sé, si hasta aquí, quisieras agregar algo más de lo que te he presentado. E3: No, como esquema parece en general bien. Sí quizás, cabría diferenciar, lo que es una PMO de TI para una organización versus lo que es una PMO TI para una empresa que hace desarrollo del software, una empresa, cuyo core de negocio, es el desarrollo del software, porque ahí sí hay una ligera diferencia. BM: Como si fuera, un tipo de consultoras. A eso te refieres con diferenciar esto. Sí, acá está más orientado a la primera en realidad, es una organización, cuál sea su contexto, su industria, que va a gestionar proyectos de TI, entonces, se le trate de brindar esta PMO, a eso está enfocado, no tanto a una empresa consultora que desarrolla software nada más, honestamente, no está orientado a eso, pero sí, todo caso lo voy a dejar muy claro en el documento y en la propuesta, es más para cualquier organización que tenga su área de TI y que tenga una PMO, que quiera gestionar esos proyectos TI, ese es un poco el enfoque y eso lo voy a clarificar de todas maneras. E3: Ok. BM: Muy bien, entonces, no habiendo más puntos a tratar, yo te agradezco la verdad infinitamente el apoyo, me ayuda muchísimo de verdad, tener este input de tu parte y voy a hacer también, las adecuaciones, las propuestas en el documento y bueno, ya lo seguro en su momento, te la de llegar para lo revises. Muy bien te agradezco igual por tu tiempo, muchísimas gracias estamos conversando. E3: Ok Braulio. Chau.