CASO PRACTICO UNIDAD 3

SERGIO LUIS GÓMEZ OSPINA

* Lucas Adolfo Giraldo Ríos.

CORPORACIÓN UNIVERSITARIA DE ASTURIAS

PROGRAMA DE ADMINISTRACIÓN DE EMPRESAS

GERENCIA DE PROYECTOS.

UNIDAD 3: Ejecución de Proyectos.  

MEDELLÍN
2021

*PROFESOR
Unidad 3: Caso Practico

Enunciado

En esta sesión vamos a estudiar un artículo de Gareth Byatt, Gary Hamilton y Jeff
Hodgkinson publicado por la revista liderdeproyecto.com. Estos autores exponen su visión
específica sobre cómo poner en marcha una PMO (Project Management Office) desde la
perspectiva que es un proyecto en sí mismo.

Implementar una PMO es un proyecto en sí mismo.

En nuestra experiencia y en discusiones de retroalimentación que hemos tenido con muchos

profesionales de proyectos y PMOs, las dificultades en el establecimiento de una PMO se
deben frecuentemente al hecho de que algunos de los principios claves de tratarla como a
un proyecto, no recibieron el nivel de atención que se justifica.

Primero consideremos dos hitos básicos en cualquier proyecto: “Inicio” y “Final” y cómo
se relacionan en el establecimiento de una PMO:

El “Inicio” sucede cuando la idea está en la iniciación temprana o en la fase exploratoria de

la PMO. Vamos a suponer que éste es el punto en cual se ha sido contactado por ejecutivos
nivel C o uno se acerca a ellos con la idea de una PMO, esto tiene algo de mérito y al
menos una aprobación verbal para continuar obteniendo la información sobre su viabilidad.

El hito “Final” se alcanza cuando a la PMO se le considera como constituida y está en

funcionamiento como una parte normal del proceso de negocio o de las operaciones.

Eso deja una gran cantidad de espacio en el medio para ser considerado. Después de
comenzar, el próximo hito se cumple cuando se presenta el proyecto ante una decisión de
“pasa/no pasa” para la aprobación del financiamiento. Para asegurar el éxito, la
presentación debería describir el “Establecimiento de una PMO” como un proyecto en sí
mismo, si bien es cierto que es un esfuerzo temporal hasta que la PMO esté erigida. Esto
requerirá a un project manager quien pueda, por supuesto, ser designado como el Gerente
de la PMO una vez que el proyecto quede completado. Por lo tanto, como cualquier
proyecto, “Crear una PMO”, tendrá una carta del proyecto con unos claros y medibles:
Propósito, Alcance, Calendario, Calidad, Presupuesto, Riesgos y factores críticos de éxito
con puntos clave sugeridos.

Veamos las siguientes operaciones para cada uno de los anteriores:

 Propósito: Como en cualquier proyecto, ¿se está intentando resolver un problema o

actuar sobre una oportunidad? Si la ejecución del proyecto ha sido históricamente
un problema, entonces la presentación se aproximará al asunto desde el aspecto de
cómo la PMO resolvería esta dificultad, desglosado en puntos específicos. Si es una
oportunidad, entonces se está asumiendo que la oficina de administración de
programas y/o portafolio proporcionará beneficios agregados como tiempos cortos
 en ejecución de proyectos, crecimiento de la productividad o reducción de gastos
administrativos.
 Alcance: Debe hacerse un resumen de todo el trabajo que se requiere para instaurar
la PMO: contratar a un gerente y/o project managers, centralizar la base de datos,
estandarización de documentos, métricas comunes, comunicaciones, software de
calendarización, etc., como si se tratara de un proyecto.
 Calendario: Como muchos sabrán, una PMO puede llevar tiempo para alcanzar el
nivel de madurez que se está buscando, y puede ser una transición lenta o rápida,
dependiendo de la pérdida de clientes que una organización pueda soportar. Ambos
enfoques pueden ser exitosos. Estos días, la vía rápida parece ser una opción más
prudente; los stakeholders quieren ver resultados rápidos y una larga transición
puede perder el impulso. Sugerimos colocar los tiempos de la fase de transición en
un rango de fechas versus una fecha difícil para que se pueda gestionar la calidad de
la administración del cambio en el ritmo requerido por la organización.
 Calidad: Los datos empíricos vendrán después; el levantamiento inicial de una línea
base histórica y de conformidad a las métricas primarias para la PMO debería ser
hecha desde el inicio (hay que recordar que “uno es lo que mide”). Para el inicio del
proyecto, enfocarse en los elementos intrínsecos de cómo los clientes están viendo
el cambio y el manejo de la moral de los project managers durante la transición.
 Presupuesto: Hay un costo fijo para la inicialización de la PMO y se debería realizar
una estimación del presupuesto para que pueda ser proporcionado el Retorno de
Inversión. El truco aquí es hacer énfasis en los beneficios a largo plazo de una PMO
en comparación con la expectativa de los que quieren todo muy rápido. Sin
embargo, cualquier resultado positivo que se produzca desde temprano (incluso
fruto de la casualidad) es un buen respaldo para mostrar en las actualizaciones de la
PMO a los stakeholders.
 Riesgos: Como en cualquier proyecto, hay riesgos. A menudo escuchamos que un
riesgo primario es la expectativa inicial de los interesados y clientes respecto a los
resultados que se tienen que lograr contra los beneficios del éxito a largo plazo. La
comunicación continua con los stakeholders y los clientes es crucial. También lo es
la puesta en funcionamiento de un Grupo de Control de Proyecto que incluye a la
alta dirección. Hay que tener en cuenta que no importa lo bien que se pueda manejar
la transición del cambio hacia una PMO, probablemente habrá un impacto en los
clientes. Abordar las preocupaciones en una forma proactiva con comunicación
positiva. Mantener un Plan de Éxito del Proyecto, el de la junta inicial.
 Factores críticos de éxito: Generalmente nos gusta usar formatos en los que se
enlistan desafíos existentes y/o oportunidades potenciales en el lado izquierdo. A la
derecha se detallan los beneficios esperados una vez que la PMO queda
completamente implantada (que deben ser seguidos y monitoreados). Se puede
considerar incumplir estos beneficios en incrementos esperados al final de cada fase
o periodo de tiempo. Es prudente no exagerar los resultados prematuramente. Todos
los factores de éxito deberían ser medibles, alcanzables y haberse acordado por
adelantado con los patrocinadores/tomadores de decisiones.

En conclusión, esperamos que sean consideradas estas ideas para establecer una PMO
al acercarse a ésta como cualquier proyecto y por lo tanto darle el mismo rigor y
disciplina es una buena estrategia. Un project manager necesita sentirse el dueño,
trabajar de manera efectiva con interesados claves, plantear los hitos, determinar los
factores críticos de éxito, administrar recursos, adquirir herramientas e informar acerca
de los resultados. Tales acciones requieren servir continuamente a las necesidades de
los stakeholders y la organización en su conjunto. Los beneficios y el éxito de
establecer una PMO vendrán en intervalos regulares y al igual que cualquier otro
proyecto, no estará completamente realizado hasta después de que sea lanzado.

Cuestiones

Puestos en la piel del nuevo responsable de establecer una oficina de proyectos en su

empresa, responda razonadamente a las siguientes preguntas.

1. ¿Qué información mínima debería contener el acta de inicio de este proyecto?

2. Identifique a los stakeholders de su proyecto.
3. La dirección ha decidido poner a su disposición a un grupo de profesionales de
diferentes departamentos de la empresa. Usted les coordinará, pero sus jefes
actuales lo seguirán siendo durante el proyecto, ¿qué implicaciones ves en esta
decisión?
4. Identifica al menos tres riesgos que puedan poner en peligro el buen término del
proyecto.
5. Establece un plan para mitigar los posibles efectos de estos riesgos.
 Desarrollo

1. ¿Qué información mínima debería contener el acta de inicio de este proyecto?

El Acta es el documento emitido por el patrocinador/a que autoriza la existencia del

proyecto. Su aprobación es el nacimiento del proyecto como tal.
El acta de constitución del proyecto contiene solo lo necesario para dejar claro el
acuerdo alcanzado con las y los interesados y nos da la autoridad para iniciar el trabajo,
además de la disponibilidad de los recursos necesarios para poder ejecutar el proyecto. 

Debe contener:

 Las necesidades del o la cliente que dan origen al proyecto.

 Las posibles restricciones que el proyecto puede tener.
 Los requisitos de alto nivel referentes al producto a desarrollar en el proyecto:

Bibliografía.
unidad2_pdf4.pdf (centro-virtual.com)
unidad3_pdf1.pdf (centro-virtual.com)
unidad3_pdf2.pdf (centro-virtual.com)