En 1996, para la mayoría de las empresas la tecnología era un gasto que alguien en sistemas tenía que mantener funcionando. Ese año ISACA publicó la primera edición de COBIT, pensada para que los auditores tuvieran con qué revisar los controles de TI. Treinta años después, ese mismo framework se usa para gobernar inteligencia artificial.

En junio, Mark Thomas publicó un homenaje por el aniversario: treinta cosas que COBIT nos enseñó sobre gobernar la tecnología. Thomas no es un comentarista cualquiera; es evaluador de COBIT, tiene la CGEIT y está en el Salón de la Fama de ISACA. Lo leí completo y me quedé con una incomodidad que me gusta: casi ninguna de las treinta lecciones habla de tecnología. Hablan de decisiones, de quién responde por ellas y de qué se mide.

De la carpeta en el librero al framework de frameworks

Thomas recuerda que cuando empezó a trabajar con COBIT, «gobierno» significaba una carpeta en un librero y «alineación» era que invitaran a TI a la junta de presupuesto una vez al año. El framework creció a la par de la profesión: en el 2000 dejó de ser solo una lista de controles y se volvió marco de gestión, en 2005 llegó la versión 4.0, en 2012 COBIT 5 y después COBIT 2019, con una guía para adaptarlo a cada organización.

Esa última pieza, la adaptación, es justo donde empiezan las lecciones que más le hablan a un PM.

Las lecciones que yo pondría en la pared de una PMO

Gobierno y gestión son cosas distintas. El gobierno marca dirección; la gestión ejecuta contra ella. Thomas lo ilustra con consejos aprobando el backlog del sprint y CIOs definiendo el apetito de riesgo. La PMO vive justo en esa frontera. Si el comité directivo dedica una hora a revisar tareas en lugar de decidir prioridades, casi siempre es porque el reporte que le llevamos habla de actividades y no de decisiones pendientes.

El valor no lo entrega la plataforma, lo entregan las decisiones sobre ella. Un proyecto puede cerrar en tiempo, en costo y con todos los entregables aceptados, y aun así no generar nada. Por eso el caso de negocio no se archiva al arrancar el proyecto: la PMO tiene que seguir preguntando por el beneficio cuando el equipo ya se fue.

Sobre la adaptación, Thomas tiene la frase que más me gustó del texto:

«COBIT out of the box is a buffet, not a meal.»

Mark Thomas · COBIT tal como viene es un bufé, no un platillo servido.

Quien viene del PMBOK o de PRINCE2 reconoce aquí el tailoring, y conozco pocas tentaciones más comunes en una PMO que exigirle a un proyecto de seis semanas las mismas veinte plantillas que a uno de dos años. La disciplina está en escoger qué pones en el plato. Thomas suma que el gobierno también aplica a una organización de cincuenta personas; lo mismo vale para una PMO de tres.

Medir actividad no es medir resultados. Revisa el tablero de tu PMO: si lo que más destaca es el porcentaje de avance, horas consumidas y tareas cerradas, estás gobernando lo que no importa. En equipos ágiles pasa igual con la velocidad cuando se vuelve meta en lugar de señal.

Una matriz RACI no reemplaza la rendición de cuentas. Si tu RACI tiene ocho personas marcadas como «A» en una sola decisión, dice Thomas, no tienes un responsable, tienes un comité. La regla que aplico al revisar una matriz es simple: una sola «A» por decisión. Y una más para cuando hay proveedores: el contrato transfiere la ejecución, pero frente al patrocinador la consecuencia de una mala decisión sigue siendo tuya.

La cultura le gana al proceso. Un rediseño de procesos de millones se cae si un solo directivo decide no seguirlo. Para un PM esto tiene nombre: gestión de interesados. La metodología más sólida no sobrevive a un patrocinador que no cree en ella, y por eso COBIT trata la cultura como componente del sistema de gobierno, no como un anexo.

Los frameworks no fallan; fallan las implementaciones. «Probamos COBIT y no funcionó» casi siempre significa, según Thomas, que se copió una plantilla y nadie se detuvo a pensar. Cambia COBIT por Scrum, PMBOK u OKR y la frase sigue siendo cierta. Muchas PMO nacen justo así: con un repositorio de formatos descargados y sin un acuerdo sobre qué decisiones van a gobernar.

La IA no inventó problemas nuevos de gobierno. Rendición de cuentas, transparencia, vigilancia de sesgos: todo eso ya estaba en la agenda. Lo que cambió es que hoy hay proyectos donde un modelo toma o sugiere decisiones, y esos riesgos tienen que estar en tu registro de riesgos, con dueño. Aquí escribí sobre ISO 42001 y quién está gobernando la IA en tus proyectos.

Un framework es un mapa, no el territorio. COBIT no te dice qué hacer; te dice en qué pensar. Es la mejor definición que he leído de para qué sirve cualquier estándar, y es exactamente lo que una PMO debería ofrecer a sus proyectos: criterio, no un recetario.

La lista completa

Aquí comenté nueve. Las treinta lecciones están en el artículo original de Mark Thomas y en el eBook gratuito que ISACA publicó en octubre. Vale la pena leerlas en su versión original, sobre todo las que hablan de auditoría, cumplimiento y confianza digital.

Nos leemos pronto, ¡un abrazo!