Procesos Claves en la Gestión de Proyectos

El Dr. Roger Kaufman señaló en uno de sus artículos (“Benchmarking”) que es casi universalmente popular tomar como referencia a otras organizaciones y buscar en ellas las mejores prácticas que utilizan para que la propia organización pueda copiarlas para ser más eficaz, previo a un análisis de las mismas. Un error común es creer que los procesos en sí mismo deben ser la base para determinar la mejor práctica, sin relacionar esos procesos a la creación interna de valor. Si uno busca una organización o metodología como referencia, debería asegurarse de que las metas y objetivos de la institución referente sean similares a la suya y que los procesos que se tomarán como modelo sean adecuados y funcionarán dentro de su organización.

Si los procesos que actualmente utiliza para la gestión de proyectos o los que se propone implementar resultan en más trabajo que el proyecto mismo, evidentemente usted necesitará repensar o simplificar dichos procesos.

Eso ocurre frecuentemente con procesos propietarios o metodologías desarrolladas que no tienen en cuenta aspectos más ágiles del negocio. Recuerdo un proyecto en donde me tocó trabajar con otros consultores de la ex Arthur Andersen quienes utilizaban “Method/1”. Si bien ellos me dieron acceso a dicha metodología francamente nunca la leí, pero puedo asegurar que ocupaba toda una biblioteca, y uno debería tener mucho tiempo para poder leer todos esos libros en menos tiempo del que se necesitaba para llevarlos a la práctica. No discuto el proceso sino su usabilidad. Cualquier proceso o metodología que ayude en el trabajo es bueno, con tal que, genere valor al cliente y no sea excesivamente pesado.

Para asegurar el éxito en la gestión de proyectos se necesita recurrir a las mejores prácticas del mercado y no re-inventar la rueda. Los procesos o métodos de mejores prácticas deberían ser una biblioteca de toda la experiencia pasada de una organización en la ejecución de sus proyectos. Estos deberían ser modulares de manera de poder adaptarlos a los distintos tamaños o complejidades de los proyectos. La biblioteca de las mejores prácticas se construye realizando los análisis post-mortem o lecciones aprendidas y documentando esa información para la mejora continua de los mismos.

Para las organizaciones que no tienen información histórica de proyectos anteriores o desean desarrollar la propia basándose en las mejores prácticas del mercado de metodologías existentes para la administración de proyectos, el material de referencia estándar es el PMBOK® del Project Management Institute con información muy detallada acerca de los procesos para la gestión de proyectos. Otras normas o metodologías tales como ISO, CMMI, Prince 2, APM, etc. son otras fuentes de información aunque en algunos casos son propias de determinadas industrias (IT) y otras no tan difundidas o completas. El PMBOK® distribuye las mejores prácticas en 42 procesos y 9 áreas de conocimiento o disciplinas. En la práctica muchos proyectos no utilizan ni la mitad de esos 42 procesos, sin embargo a los efectos educacionales el PMBOK® provee la más clara y profunda explicación de las distintas áreas que envuelven a la gestión de cualquier proyecto. La flexibilidad es muy importante aquí.

Primero se trata de otro BOK (Body of Knowledge) por lo que no se espera encontrar todas las respuestas allí sino que se espera que cada profesional deba consultar infinidad de otras fuentes relacionadas con cada proceso y disciplinas descriptas. Segundo, utilizar el sentido común, la experiencia y la intuición para decidir qué procesos son los que conviene aplicar en cada proyecto que vamos a encarar.

Tomando como base el PMBOK®, a mi criterio el documento que sigue siendo más importante como referencia para la gestión de proyectos, en este artículo vamos a detallar algunos conceptos muy importantes, advertencias y temas claves que se deben contemplar en la administración de todos los proyectos y que normalmente suelen pasarse por alto o no darles la importancia necesaria en la gestión de los mismos.

1 – Seguir un proceso de iniciación estructurado: realizar un estudio de factibilidad financiero, tecnológico, de recursos, impactos, estratégico y de negocio del proyecto, para prevenir inconvenientes, priorizarlo y obtener el soporte y justificación de negocio necesario para poder implementarlo. Durante la fase de inicio o arranque, una correcta valoración de riesgos, asunciones, obstáculos y restricciones deben ser convenientemente evaluados y el factor crítico es realizar un adecuado proceso de valoración de requerimientos (RM) para clarificar objetivos, necesidades y alinear las expectativas. En muchos casos los procesos de RM pueden automatizarse pero siempre es conveniente mantener sesiones y reuniones con los stakeholders para aclarar los puntos grises. Todas las metodologías de administración de proyectos recalcan la importancia de una fuerte relación con los stakeholders y su proceso de análisis, dado que con ellos podremos lograr más fácilmente el éxito y romper muchas barreras en los proyectos. Un error frecuente es que muchos proyectos pueden tener muchos stakeholders y el team sólo dialoga con aquel más sociable y entusiasta sin evaluar las expectativas de los otros que directa o indirectamente están involucrados y son precisamente los que pueden ponernos los palos en la rueda. Un factor común para el éxito de los proyecto es poseer la habilidad de negociar y manejar las expectativas y necesidades de los stakeholders afectados por el proyecto. La relación con el sponsor y los stakeholders es vital y la clave es establecer una buena “relación” lo que implica más que identificar y manejar sus expectativas, manejar una conexión emocional con la gente. El PM debe focalizarse en mejorar sus habilidades interpersonales, y asegurarse de que todos los stakeholders están a bordo del proyecto manteniendo fluida comunicación con ellos. El análisis de los stakeholders debería permitir al PM no sólo identificarlos sino categorizarlos bajo distintos aspectos: relación y actitud hacia el proyecto, están a favor o en contra del proyecto, cuál es su poder e influencia, existen conflictos entre ellos, etc.

2 – Planificación del Proyecto: de acuerdo a la industria donde se realice el proyecto, la planificación podrá tomar diferentes matices. Los proyectos para el desarrollo de software son bastante particulares, tan es así, que surgieron metodologías propias para los mismos (“Agil Development”) diferentes a las tradicionales como el PMBOK®. Algunos aspectos de las metodologías ágiles pueden ser utilizados en cualquier otro proyecto. Actualmente está de moda hablar también de Lean Six Sigma Project Management, otra aproximación a la gestión efectiva de proyectos. Independientemente de que se utilice una metodología tradicional, ágil o lean; una buena planificación siempre es necesaria. En la metodología tradicional la planificación es exhaustiva y completa, en los ciclos más acelerados y livianos (ágil o lean) la planificación se concentra en delimitar los bordes del proyecto para crear una lista priorizada de entregables que serán liberados en fases de tipo iterativa. Planes comprensivos, realistas y bien comunicados son imprescindibles en todos los proyectos, aún con cortos ciclos de vida. Involucrar no sólo al team sino a los stakeholders en el desarrollo de los planes, discutir acerca de todos los objetivos y entregables del proyecto y explicar claramente los riesgos involucrados son también factores esenciales. Como corolario final el consejo es no embarcarse en planificaciones extensas, construir planes a corto plazo y detallados (elaboración progresiva según el mismo PMBOK®), e ir elaborando los requerimientos sobre la marcha en una aproximación de tipo iterativo.

3 – Utilizar auditorías: para evaluar la salud del proyecto, deberían realizarse auditorías y reuniones de “quality assurance” en forma frecuente para chequear no sólo los entregables sino el estado y progreso del proyecto. Medir el progreso real versus el costo y tiempo estimado es muy importante, al igual que realizar mediciones de calidad respecto del cumplimiento de los requerimientos y el alcance de los entregables. No podemos controlar y mucho menos mejorar si no tenemos métricas. Debemos desarrollar criterios estándar de medición tanto de calidad como de productividad y eficiencia, para saber no sólo dónde estamos sino qué y cómo debemos mejorar. El PM debe desarrollar todas las actividades y procesos definidos dentro del grupo de Monitoreo y Control del Proyecto que involucra el control del progreso del mismo (tiempo y tareas), el control del alcance (cambios) el control del rendimiento (performance), el control de los costos (método del valor ganado) y el control de calidad. De dichos controles surgirán reportes y medidas correctivas o preventivas.

Las auditorías también pueden ser efectuadas por personal externo al proyecto, y se denominan “peer reviews”, realizadas por colegas o el departamento PMO o de
Aseguramiento de Calidad. El alcance de la misma debería ser similar al comentado más arriba. Toda auditoría consta de las siguientes etapas:

• Planificación, elección del tipo de auditorías a realizar (costos, performance, calidad, etc.), determinar los procedimientos a utilizar, elección del personal, fijación de su periodicidad (mensual, anual, esporádica, etc.).
• Realización de auditorías según procedimiento y plan definidos. Es conveniente desde el punto de vista práctico que la realización de auditorías sea sistemática, y el propio director o responsable del área a auditar transmita a sus subordinados afectados las fechas concretas en las que estas auditorías sistemáticas van a realizarse para que presten su mayor colaboración. Los documentos que recojan los resultados de las auditorías, es decir, respuestas, comprobaciones, resultados de medidas y ensayos, etc., han de estar consensuados entre auditor y auditado, de tal forma que recojan la conformidad de ambos, evitándose discusiones inútiles. Se trata de auditar la efectividad de la gestión del proyecto, tanto a través del grado de cumplimiento de los procesos, como a través de la calidad del producto obtenido.
• Evaluación de los resultados de la auditoría. Toda auditoría ha de realizarse para obtener una nota final que sirva, aunque sólo sea comparativamente, para medir la evolución y progreso del proyecto. Lo que se pretende es la obtención de una valoración totalmente objetiva por lo que el sistema de valoración ha de ser consensuado, y además, experimentado durante cierto tiempo, para poder fijar las señales de alerta, índices de ponderación, etc.
• Redacción de un informe y propuesta de medidas correctivas de ser necesario, con expresión de su grado de urgencia. Una vez valorada la auditoría y antes de la redacción del informe final y propuesta de las medidas correctoras, es conveniente la reunión con el PM afectado por la auditoría para que sea el primer informado y pueda incluso colaborar en la propuesta de medidas correctoras así como la decisión sobre la urgencia de las mismas, pues es conveniente que tanto el informe de la auditoría como la propuesta de medidas correctoras, lo asuma como algo propio, entre otras cosas porque a veces, podrá ejercer más presión sobre la Gerencia que el propio auditor, sobre todo si alguna de las medidas propuestas corresponden o requieren inversiones.

4 – Utilización de recursos humanos: la correcta utilización de las “técnicas blandas” y el uso adecuado de las habilidades interpersonales son factores críticos en el manejo de todos los proyectos. Un tema controversial que suele traernos dolores de cabeza son las horas que cargan los recursos al proyecto: ¿deben ser las reales o teóricas?. En las organizaciones en las que trabajé, como ocurre con muchas consultoras o empresas de servicios, al cliente se le cobra de acuerdo al proyecto un “precio fijo” o “time & material” (por hora de consultoría). En ambos casos se toma para la formación del precio el “cost rate” de los recursos que trabajarán en el proyecto, independientemente de que el recurso pertenezca o no a la organización ejecutante. Si pertenece a la organización y trabaja más de 40 horas a la semana, su salario será siempre el mismo, pero a los efectos de cobro al cliente en el caso de time & material podríamos cobrar las horas “overtime”, algo que, en la práctica sólo se le paga al recurso si es externo a la organización. En los casos de precio fijo, durante la planificación normalmente calculamos en la herramienta de scheduling 40 horas de trabajo semanal. Si observamos que existen recursos con sobre alocación (más de 8 horas por semana) la técnica más común a utilizar sería el resource-leveling algo que generalmente terminará por enviarnos el final del proyecto al lado oscuro de la luna. En la práctica normalmente no se hace nada dado que el recurso si es parte de la plantilla de la organización, trabajará esas horas extras que por lo general y debido a su rango no son pagadas en la práctica dado que recibe su sueldo mensual fijo. El problema se presenta cuando existen sistemas de control de costos y productividad que no toma en cuenta esta realidad (dado que se maneja con planillas separadas). En estos casos es frecuente que se le obligue al recurso a cargar las horas que realmente trabaja en el proyecto en algún sistema para su registro. De ser así, estaremos en un aprieto desde el punto de vista de costos, dado que las horas cargadas y costeadas superarán lo que estaríamos facturando. La única solución en este caso será que no cargue sus horas extras, bajando su nivel de “billability”, algo que no solo puede perjudicar al recurso sino también al mismo gerente (problemas de utilización y productividad). Otro tema importante es la no disponibilidad de los recursos claves (algo frecuente en los proyectos de alta tecnología). La demanda puede ser superior a la oferta y los planes suelen subestimar el tiempo requerido para adquirir estos recursos, lo mismo que el tiempo necesario para organizar el grupo (“team building”).

5 – Estimación en los Proyectos: las estimaciones de costos y tiempos en un proyecto constituyen la parte más difícil en la planificación, y es más un arte que una ciencia. Como consultor tuve que realizar una revisión a un proyecto que estaba con un sobrecosto muy elevado y querían un análisis de la causa de la variación del mismo. Mi primera pregunta fue “cuál era el método que utilizaban para las estimaciones”, la respuesta clásica fue el proyecto tiene que estar listo para Octubre y se vendió en este precio considerando una determinada carga de recursos. Mi segunda pregunta fue “¿si la base de estimación es una ficción, como quiere que la varianza en el costo tenga algún significado?”. Lamentablemente muchas organizaciones venden sus proyectos de acuerdo a lo establecido por Ventas y no tienen tiempo de realizar una estimación bottom-up o utilizar buenas técnicas de métodos cuantitativos de administración de proyectos para al menos estimar las variaciones e incertidumbres con los buffers de contingencias necesarios. Cuanto más largos en recursos, tiempo, costos o complejidad son los proyectos mucho más complicada resultará la realización de las estimaciones. El Standish Group a través de sus estudios empíricos nos arroja estos resultados de éxito/fracaso de proyectos en su relación con su tamaño y duración.

Esto nos demuestra una vez más que los mega-proyectos pasaron de moda y que el desarrollo iterativo es el mejor método para mitigar riesgos y una estrategia buena para estimar mejor el alcance, costo y tiempo de los entregables a distribuír en el proyecto.

6 – Practicar un estricto control de cambios: independientemente del tamaño del proyecto y para evitar el “Scope Creep” se deberá ser muy riguroso en lo que respecta al control y seguimiento de los cambios al proyecto, utilizar herramientas automáticas de RM (Requirement Management) y CM (Configuration Management). Tener muy claro el procedimiento para solicitar los cambios, el tipo de formulario, como debe ser completado y el método para aprobación respectivo. Si el Gerente de Proyecto no ha definido bien el alcance inicial del proyecto, será tremendamente difícil administrar el mismo. El propósito de la administración de cambios es proteger la viabilidad de la definición del proyecto ya definida y aprobada. Cuando se solicita formalmente un cambio implica que dicho cambio está fuera del alcance acordado en la definición del Proyecto o de los requerimientos o solicitudes detallados durante el análisis. Si dicho alcance es confuso, poco claro, o deja lugar a interpretaciones, entonces el cliente dirá que el cambio está dentro del alcance, y el Gerente de Proyecto encontrará difícil apegarse a un proceso formal de Gestión de Alcance. En algunos proyectos es posible anticipar todas las solicitudes y requerimientos durante el proceso de análisis. No obstante lo cual, siempre podrá existir la posibilidad y la necesidad de incorporar cambios durante el ciclo de vida. Estos cambios pueden ser muy necesarios para la solución, y pueden existir razones poderosas de negocio por las que deberían incorporarse. El Gerente de Proyecto y el equipo de trabajo, deben reconocer el momento en que los cambios son requeridos y deberán seguir un proceso predefinido de gestión del alcance. Este proceso, eventualmente, proporcionará información para que el sponsor tome las decisiones pertinentes y también le permitirá decidir si la modificación deberá aprobarse en base al valor e impacto en el proyecto en términos de costo y tiempo. Debe ser claro para todas las partes que cumplir estos nuevos requerimientos con los mismos recursos de la definición anterior, es prácticamente imposible.

7 – Buffers: incertidumbre, probabilidades: son temas que hacen a la gestión cuantitativa de los proyectos. Primero y fundamental es necesario no mezclar (al menos sin identificar claramente) las contingencias que nos tomamos en las estimaciones con la duración puesta a cada tarea. Esta contingencia debe ser claramente identificada y manejada para evitar el efecto de la famosa “Ley de Parkinson”. El método de la Cadena Crítica coloca todas estas contingencias en un buffer compartido para todo el proyecto de uso exclusivo del PM. De no utilizar este método el PMBOK® nos aconseja utilizar contingencias o buffers por las incertidumbres en las estimaciones utilizando CPM/PERT, MonteCarlo, Varianza de la media, o simplemente un porcentaje del total de costo o tiempo adicional. El cálculo del tamaño del buffer debe tener en cuenta muchos factores. Hablar de incertidumbre en riesgos o en las estimaciones no es exactamente lo mismo que hablar de cuál sería la probabilidad de ocurrencia. En forma simple, al arrojar una moneda existe una incertidumbre respecto de si saldrá cara o ceca. Pero no hay incertidumbre respecto de las probabilidades de que salga cara dado que ambas tienen un 50%. Si la probabilidad de un evento se acerca más al 100% estaremos mucho más tranquilos porque reducimos su incertidumbre, pero inevitablemente aumentaremos su rango. Por ejemplo, si tenemos una pieza mecánica que a través de mediciones hechas durante 5 años sabemos que puede causar daños humanos en un impacto con rango del 35% al 45% (10%) y esto no es aceptable, lo que ocurrirá es que se realizarán tareas de ingeniería para mejorar dicha pieza y reducir ese impacto negativo. Supongamos que logramos armarla de otra forma y que ahora las probabilidades de que ocurra algo malo son del rango entre 5% y 25% (20%). Hemos reducido significativamente la probabilidad de un accidente pero como no hay historia pasada el rango de la incertidumbre es más alto (del 10 al 20%).

8 – Subcontratar desarrollos externos (“Outsourcing”): muchas veces he trabajado como “prime contractor” en proyectos en donde teníamos muchos proveedores involucrados (en algunos casos, su desarrollo era más importante que el nuestro). En este aspecto son válidas todas las recomendaciones del PMBOK® sobre adquisiciones, además de tener en cuenta todas las modalidades contractuales y de mantener el “pari passu” (mismas condiciones de obligaciones y responsabilidades contractuales) de las cláusulas del cliente con nuestros proveedores. En este caso me referiré a un tema muy corriente en el ambiente de IT que es la exigencia de ciertos niveles de calidad (CMMI) que se suele requerir cuando se contrata o se hace un outsourcing. La mayoría de las empresas hoy en día pregonan ser certificadas en CMMI. Esto es imposible dado que CMMI no es una certificación, el SEI no certifica organizaciones como el ISO o el ITSMF, sino que autoriza a personas denominadas “lead appraisers” a conducir auditorías para determinar el grado de madurez de la organización respecto del modelo. El SEI no confirma la certeza del nivel de madurez reportado, sino que su foco es más bien la calidad continua de la organización, que identifique en qué nivel se encuentra y que realice todos los esfuerzos necesarios para mejorar su calidad y hacer sus procesos repetibles.

El gráfico mostrado más arriba es un informe del IEEE Software que documenta un estudio sobre 104 proyectos de software en el mundo. India es el país que proclama tener la mayoría de sus empresas con Nivel 5 de CMMI y sin embargo está en el tercer lugar en cuanto a programas con errores (el informe incluye empresas como Motorola India, Infosys, Tata Consulting), ¿algo como para tener en cuenta no?. No estoy desmereciendo la evaluación del modelo de madurez sino que debería preguntarse mucho acerca de cómo se obtuvo y otras cuestiones de la empresa a contratar tales como:

• ¿Cuándo fue publicado su último assessment? (dura 2 años)
• Copia de la documentación donde figura qué áreas son las más fuertes y cuáles con las más débiles.
• ¿Quién desarrolló el lead assessment?
• ¿Cuáles son sus planes de mejora continua?
• ¿Con qué otros clientes trabaja?

Otra característica asociada a la inmadurez de nuestro mercado es el error de escuchar a un gerente decir: “esta tarea ya no representa un problema porque la hemos subcontratado”. Esto es falso, fundamentalmente porque la inestabilidad de nuestro mercado hace que sea muy difícil desarrollar relaciones cliente – proveedores que perduren en el tiempo. Por otro lado, esta inestabilidad y lo pequeño del mercado generan el problema que los proveedores en gran medida sean Pymes, y éstas permanentemente deben de tener una muy agresiva actitud de venta, sobre todo si son proveedores que dependen de la aparición de proyectos en el mercado para tener trabajo y resulta muy difícil su evaluación porque no hay una manera simple de saber el estado en que se encuentra dicho proveedor. Es posible analizar los contratos que tiene en ejecución, pero no es posible analizar los contratos que “están a la firma”, y muchas veces la concreción de uno, genera mejores condiciones en las Pymes para enfrentar las negociaciones con los otros contratos, y se produce una cascada de contratos que se firman, una cantidad de compromisos simultáneos que este proveedor tiene que cumplir, y como generalmente no cuenta con reservas de recursos humanos ni con una planificación previa tiene como resultados crisis de recursos y falta de cumplimiento en todos los contratos. En el caso a su vez que el contratista sub-contrate el servicio en otra organización se le suma a la inestabilidad propia del contratista, que tiene sus propias crisis, la que potencian a la de los subcontratistas. Cuando bajamos de nivel, nos encontramos con empresas más pequeñas, más inestables, más riesgosas y más difíciles de predecir, con grandes inconvenientes para tomar buenas decisiones.

9 – Project Manager, Líder o Facilitador: Un Gerente de Proyecto debe desarrollar diferentes roles por lo que es importante la óptima aplicación de sus habilidades personales. Normalmente un PM debe cumplir con su rol de Gerente pero además debe también ser el Líder del grupo de trabajo, aspectos que tienen distintos objetivos. El lector debería conocer la importancia del proceso de “Team Building” y cómo los grupos van madurando a lo largo del desarrollo del proyecto. Actualmente también podemos clasificar a los equipos de trabajo conforme a su capacidad técnica y resolutiva, llegando a tener equipos de trabajo denominados de Alto Desempeño en donde los conflictos los resuelven entre ellos, toman decisiones propias y pueden autogestionarse. En estos casos el rol del PM más importante es el de Facilitador donde lo que prima es dejar trabajar con libertad y preocuparse más en eliminar los problemas u obstáculos del equipo. Las características de los facilitadores son: Lideran pero no dominan; utilizan mucha escucha activa; motivan a la participación y trabajo cooperativo; lideran con el ejemplo; mantienen al Sponsor activamente involucrado pero se aseguran que no interfiera en el trabajo; documentan al nivel necesario. Estamos hablando de gente de alta confianza y estima que demuestran carisma, empatía, respeto y sensibilidad por el grupo de trabajo. Podemos decir entonces que otro factor clave en la gestión de los proyectos es colocarse el sombrero adecuado teniendo en cuenta el tipo de proyecto, el team de trabajo o las circunstancias especiales que estemos controlando.

10 – Project Management Estratégico: el tema se basa en asegurarse de que todos los proyectos están estratégicamente alineados y fueron previamente analizados por la PMO o un proceso de PPM. Se debe definir un criterio contra el cual todos los proyectos pueden ser priorizados que incluya el impacto en las estrategias corporativas y los clientes, y confeccionar una lista de todos los proyectos, sus metas y objetivos estratégicos. Después, tratar de identificar el criterio de éxito de los mismos y determinar el impacto esperado que cada proyecto tendrá en la organización y sus clientes. Asignar un rango para cada proyecto cuantitativamente y determinar su nivel de prioridad. Alinear los proyectos con los planes estratégicos corporativos y departamentales, y ejemplificar cómo la ejecución exitosa de cada proyecto apoyará el plan estratégico de la corporación o del departamento. En ciertos casos no queda otra salida que cancelar los proyectos que son de baja prioridad o que no están ligados a la estrategia corporativa o departamental. ¿Qué se puede hacer para implementar las mejores prácticas de Project Management Estratégico?: la retención del conocimiento es uno de los mayores beneficios para las organizaciones ya que contribuye al aprendizaje continuo y ayuda a evitar la repetición de errores. Con objeto de retener el conocimiento sobre la implementación efectiva de proyectos y que puedan ser pasados como lecciones aprendidas hacia equipos de proyectos a futuro, la PMO debería tener una reunión de cierre de proyecto tan pronto como haya terminado, mientras el conocimiento sobre la administración del mismo aún está fresco en las mentes de todos. El propósito de esta reunión es revisar qué sucedió durante el transcurso del proyecto y qué puede aprender el equipo y la organización de lo sucedido. El sponsor del proyecto, el responsable del proyecto y el equipo de trabajo deberán estar presentes así como cualquier recurso exterior o “stakeholders” quienes quisieran contribuir con ideas. El resultado final de esta reunión de cierre del proyecto será la creación de un documento formal de “lecciones aprendidas” para ser llevadas a proyectos futuros, a los gerentes y a sus equipos de trabajo. El establecimiento de mediciones de proyectos exitosos desde el punto de vista estratégico también ayudará a proveer a la alta dirección de información relevante y necesaria para tomar decisiones que afecten el proyecto. Por ejemplo, la presentación estratégica de las medidas del éxito del proyecto puede convencer a la alta dirección de re-priorizar proyectos o de re-asignar recursos. Las medidas del éxito del proyecto proveerán a la PMO de la información necesaria para que venda el impacto de la efectividad al nivel gerencial. Los criterios para el éxito en la medición de los proyectos estratégicos deben incluir:

• La utilización de un criterio de calidad especificado.
• La habilidad para enfrentar cambios en los requerimientos.
• El número de recursos usados actualmente contra el número de recursos anticipados originalmente.
• La habilidad del proyecto para alcanzar sus objetivos y entregables específicos.
• Las encuestas de satisfacción de clientes que indican su conformismo con el producto o la entrega del servicio del proyecto.
• La puesta en producción o lanzamiento exitoso y sin problemas.
• Mediciones financieras adecuadas y dentro de los límites.

Finalmente para las organizaciones que están considerando en definir cuál es la mejor metodología para administrar sus proyectos, o cómo adaptar la metodología del PMBOK® a sus propias necesidades, la recomendación es considerar un buen programa de entrenamiento de sus PM y considerar su posible certificación, que ofrezca una revisión de la metodología y las áreas claves para su organización: costos, tiempos, riesgos, calidad, junto con una visión más amplia, crítica y realista. Otra alternativa es contratar a una organización con consultores especializados y certificados PMP para que colaboren en la implementación de los proyectos y realicen la transferencia de conocimientos y prácticas necesarias.