PMO y VMO como servicio: gobernar proyectos y proveedores con indicadores

En muchas áreas de TI el problema no es la falta de proyectos ni de proveedores, sino la falta de una vista única sobre ambos. Cada iniciativa reporta a su manera, cada contrato se revisa cuando algo falla y el comité recibe información tarde y en formatos distintos. Una oficina de gestión de proyectos (PMO) y una oficina de gestión de proveedores (VMO, por vendor management office) existen para resolver exactamente eso: convertir la ejecución y la relación con terceros en algo medible y gobernable.

Este artículo explica qué hace cada una, cuándo tiene sentido operarlas como servicio en lugar de construirlas internamente y qué indicadores, cláusulas y rituales de gobierno conviene tener desde el primer mes.

Qué hace una PMO y qué hace una VMO

Aunque se suelen mencionar juntas, resuelven preguntas diferentes.

La PMO responde: ¿estamos haciendo los proyectos correctos y los estamos haciendo bien? Sus funciones habituales son:

• Mantener el inventario del portafolio: qué proyectos existen, su estado, presupuesto, patrocinador y beneficio esperado.
• Definir un método común (fases, entregables mínimos, criterios de paso de fase) sin imponer una metodología única; puede convivir con equipos ágiles y predictivos.
• Consolidar el reporte de avance, riesgos, issues y cambios de alcance.
• Apoyar la priorización y el balance de capacidad entre iniciativas.
• Asegurar el cierre formal: lecciones aprendidas, traspaso a operación y verificación de beneficios.

La VMO responde: ¿nuestros proveedores entregan lo que pagamos y controlamos el riesgo que nos traen? Sus funciones habituales son:

• Mantener el registro de proveedores y contratos: servicios, vigencias, montos, renovaciones y dueños internos.
• Medir el desempeño contra SLA y obligaciones contractuales.
• Gestionar el riesgo de terceros: dependencia, concentración, seguridad de la información y continuidad.
• Conducir las revisiones periódicas con cada proveedor y el seguimiento de planes de mejora.
• Preparar renovaciones, renegociaciones y salidas con datos, no con percepciones.

La conexión entre ambas es directa: buena parte de los proyectos de TI se ejecuta con proveedores, y buena parte de los problemas de un proveedor se manifiesta primero como un retraso de proyecto. Cuando PMO y VMO comparten datos, el comité ve la causa y no solo el síntoma.

Cuándo conviene el modelo "como servicio"

Una PMO o VMO como servicio significa que un equipo externo opera las funciones, herramientas y reportes de la oficina, mientras la organización conserva las decisiones: priorizar, aprobar, renovar o sancionar. No es delegar el gobierno; es delegar la mecánica que lo hace posible.

El modelo suele tener sentido en estas situaciones:

• No hay oficina o está subdimensionada. Construir una PMO interna toma tiempo de contratación, definición de método y elección de herramientas. Un servicio permite empezar con un método probado y ajustar después.
• Picos de portafolio. Una transformación, una migración a la nube o un cambio de core multiplican los proyectos y contratos durante un periodo acotado.
• Necesidad de independencia. Cuando el reporte lo produce un tercero que no ejecuta los proyectos, es más fácil que los semáforos reflejen la realidad.
• Exigencias regulatorias sobre terceros. En sectores regulados, los supervisores esperan evidencia de gestión de proveedores críticos. Una VMO con registro y revisiones documentadas facilita responder.

También hay casos en los que no conviene. Si el portafolio es pequeño y estable, una función interna liviana puede bastar. Y si la organización no está dispuesta a tomar decisiones con los datos que la oficina produce, ningún modelo de servicio lo resolverá. Un error frecuente es contratar reportes sin definir antes quién decide sobre ellos.

Indicadores de portafolio y de proveedores

Los indicadores deben ser pocos, comparables entre periodos y vinculados a una decisión. La siguiente tabla propone un conjunto inicial; las metas concretas dependen de cada organización y se fijan con el comité.

Ámbito	Indicador	Qué pregunta responde
Portafolio	Desviación de cronograma por proyecto	¿Qué iniciativas se están retrasando y cuánto?
Portafolio	Desviación de costo frente a presupuesto aprobado	¿Dónde se consume más de lo previsto?
Portafolio	Cambios de alcance aprobados en el periodo	¿Qué tan estable es lo que se definió?
Portafolio	Riesgos altos abiertos sin plan de respuesta	¿Dónde estamos expuestos sin acción?
Portafolio	Beneficios verificados tras el cierre	¿Lo entregado produjo lo que justificó la inversión?
Proveedores	Cumplimiento de SLA por servicio	¿El proveedor entrega el nivel pactado?
Proveedores	Incidentes atribuibles al proveedor	¿Cuánta inestabilidad nos trae?
Proveedores	Acciones de mejora vencidas	¿Cumple lo que se compromete a corregir?
Proveedores	Concentración de gasto o servicios críticos	¿Dependemos demasiado de un solo tercero?
Proveedores	Contratos próximos a vencer sin decisión	¿Llegaremos a una renovación sin preparación?

Dos recomendaciones prácticas. Primero, cada indicador necesita una definición escrita: fórmula, fuente del dato, frecuencia y responsable. Sin eso, el debate en el comité se va a discutir la cifra y no la acción. Segundo, conviene separar los indicadores de control (los que se revisan todos los meses) de los de análisis (los que se consultan cuando algo se desvía).

SLA y penalizaciones: cómo pensarlos en el contrato

Un SLA útil describe un nivel de servicio medible, cómo se mide y qué ocurre si no se cumple. Las prácticas de gestión del nivel de servicio y de gestión de proveedores de ITIL 4, y la norma ISO/IEC 20000-1 para sistemas de gestión de servicios, ofrecen una base reconocida para estructurarlos.

En términos generales, un contrato de servicios de TI bien armado suele incluir:

• Definición precisa del servicio y de sus límites: qué está incluido y qué no.
• Métricas con método de medición: disponibilidad, tiempos de respuesta y resolución por prioridad, calidad de entregables. Se debe acordar quién mide, con qué herramienta y en qué ventana.
• Exclusiones: mantenimientos programados, causas atribuibles al cliente o a otros terceros.
• Créditos de servicio o penalizaciones: normalmente un porcentaje de la tarifa del periodo, escalonado según la gravedad del incumplimiento y con un tope.
• Incumplimiento reiterado: qué pasa si el SLA se incumple varios periodos seguidos, incluido el derecho a terminar.
• Planes de mejora: obligación de presentar análisis de causa y acciones correctivas con fechas.
• Derecho de auditoría y acceso a información, especialmente relevante en sectores regulados.
• Salida y transición: devolución de datos, documentación y apoyo durante el traspaso a otro proveedor.

Una advertencia: las penalizaciones no mejoran por sí solas un servicio. Su función es alinear incentivos y dar una base objetiva a la conversación. Si el SLA mide lo que es fácil de medir y no lo que importa al negocio, el proveedor puede cumplir en verde mientras los usuarios sufren. Por eso conviene complementar los SLA técnicos con algún indicador de experiencia o de impacto en el negocio.

Cadencia de gobierno: quién se reúne, cuándo y para qué

Los indicadores solo sirven si existe un ritmo de reuniones que los convierta en decisiones. Una cadencia típica en tres niveles:

1. Semanal, operativo. Jefes de proyecto, PMO y responsables técnicos revisan avance, bloqueos y riesgos nuevos. Con proveedores, se revisan incidentes abiertos y entregas de la semana. Salida: acciones con responsable y fecha.
2. Mensual, táctico. PMO y VMO presentan el tablero consolidado a la gerencia de TI. Se revisa el cumplimiento de SLA, se aprueban cambios de alcance menores y se decide qué escalar. Con cada proveedor relevante se hace una revisión formal de desempeño.
3. Trimestral, estratégico. El comité revisa el portafolio completo, vuelve a priorizar, aprueba o cancela iniciativas y decide sobre renovaciones y proveedores críticos. Aquí se verifica también el beneficio de los proyectos cerrados.

Cada nivel debe tener un formato estable de reporte, un acta con decisiones y un mecanismo para escalar al siguiente. Un error frecuente es que todas las reuniones se conviertan en revisiones de estado: si una reunión no produce decisiones, probablemente sobra o está mal convocada.

Cómo arrancar en las primeras semanas

Una secuencia razonable para poner en marcha una PMO y VMO como servicio:

1. Inventario. Levantar la lista de proyectos activos y de contratos vigentes con sus datos mínimos. Es frecuente descubrir iniciativas sin patrocinador o contratos sin dueño interno.
2. Criticidad. Clasificar proyectos por valor y riesgo, y proveedores por criticidad del servicio que prestan. No todos requieren el mismo nivel de seguimiento.
3. Indicadores y fuentes. Acordar el conjunto inicial de indicadores, sus definiciones y de dónde sale cada dato.
4. Cadencia y roles. Fijar las reuniones, sus participantes y quién decide en cada nivel.
5. Primer tablero. Publicar una primera versión aunque sea imperfecta. Los datos mejoran cuando se usan.
6. Revisión de contratos críticos. Comparar los contratos de los proveedores más importantes contra los elementos mínimos descritos arriba y planificar los ajustes en la próxima renovación.

El objetivo de los primeros meses no es la perfección metodológica, sino que el comité tome mejores decisiones con información confiable y a tiempo.

Este contenido es divulgativo y no constituye asesoría legal ni contractual: valida los modelos de contrato y las cláusulas de penalización con tu área legal y de cumplimiento.