Tema 5.2 — Trabajo liderado por programa

En una frase: El trabajo liderado por programa coordina un conjunto de proyectos y productos relacionados hacia un cambio estratégico que ninguno podría entregar solo, manteniendo una línea de visión clara desde el trabajo hasta los beneficios que pretende realizar.

Por qué esto importa en la salud y la atención#

Los cambios más grandes en la salud y la atención nunca son un solo proyecto. Desplegar un registro de atención compartido a través de un sistema de atención integrada (ICS), mover una región a una única historia clínica electrónica (EPR), transformar una vía de atención urgente y de emergencia, o entregar un programa de salas virtuales a través de múltiples fideicomisos —cada uno de estos es un paquete coordinado de proyectos, equipos de producto, cambio de fuerza laboral, trabajo de propiedades, y rediseño clínico, alineado a un resultado estratégico. Gestiona las piezas de forma aislada y chocan: estándares de datos incompatibles, gasto duplicado, flujos de trabajo clínicos contradictorios, y beneficios que nunca se materializan realmente.

La gestión de programas existe para mantener unida esa coalición y mantenerla apuntando hacia resultados y beneficios, no solo productos entregables. Esto importa agudamente en la salud y la atención porque el cambio a nivel de sistema toca la seguridad del paciente a través de límites organizacionales, compromete grandes sumas de dinero público durante varios años, y depende de que muchas organizaciones autónomas elijan moverse al unísono. Un programa proporciona el liderazgo, el estado objetivo compartido, y la disciplina de beneficios para hacer que eso suceda —y, igualmente importante, para saber si está funcionando.

El fallo recurrente contra el que protege es el programa que gasta millones, entrega un montón de productos entregables técnicos, y sin embargo no cambia nada medible para pacientes o personal. Este tema usa Managing Successful Programmes (MSP), el marco dominante del sector público del Reino Unido, y muestra cómo el trabajo liderado por programa coexiste con los modos liderado por proyecto (Tema 5.1 — Trabajo liderado por proyecto) y liderado por producto (Tema 5.0 — Trabajo liderado por producto) que coordina. El Tema 5.3 — Gestión de cartera y proyectos empresariales (EPPM) luego explica cómo una organización prioriza a través de muchos programas.

Conceptos clave#

Programa. Una organización temporal y flexible creada para coordinar, dirigir, y supervisar un grupo de proyectos y actividades relacionados para entregar resultados y beneficios alineados a objetivos estratégicos. Un programa difiere de un proyecto en que se define por el resultado y los beneficios que busca, y gestiona la incertidumbre de coordinar muchas partes móviles, en lugar de entregar un único producto entregable fijo.

MSP (Managing Successful Programmes). El marco de mejores prácticas del Reino Unido para gestionar el cambio transformacional a través de múltiples proyectos relacionados. Se organiza alrededor de principios, temas, y un "flujo transformacional" de procesos, y está diseñado para cambios grandes y complejos donde el estado final se conoce en dirección pero la ruta involucra muchas entregas interdependientes.

Visión y plano director. La visión es la imagen convincente del futuro que el programa creará. El plano director (blueprint) lo hace concreto: describe el modelo operativo objetivo —el estado futuro de procesos, organización, tecnología, información, y roles (a menudo resumido como POTI). El plano director es el punto de referencia hacia el que se dirige cada proyecto, para que las piezas sumen un todo coherente.

Realización de beneficios. El corazón de la gestión de programas. Los beneficios son las mejoras medibles que justifican la inversión —menos altas retrasadas, menos pruebas duplicadas, diagnóstico más rápido, menor carga administrativa. MSP trata identificar, mapear, medir, y gestionar activamente los beneficios a través de todo el ciclo de vida como una disciplina central, porque los productos entregables solo crean valor cuando se usan para cambiar cómo se entrega la atención.

Tramos. MSP divide un programa en tramos (tranches) —bloques de trabajo que terminan en un punto de revisión importante donde se ha entregado un paso de capacidad y puede comenzar la realización de beneficios. Un tramo es un momento para demostrar resultados, reevaluar el plano director frente a la realidad, y decidir si continuar, ajustar, o detenerse, en lugar de meramente una porción del cronograma.

Junta de programa y SRO. El propietario senior responsable (SRO) es la persona única responsable de que el programa cumpla sus objetivos y realice sus beneficios, con suficiente antigüedad y autoridad para liderar y tomar decisiones. El SRO preside una junta de programa —típicamente un gerente de cambio de negocio, líderes de proyecto, y partes interesadas senior— que proporciona dirección a través de límites organizacionales.

Gerente de cambio de negocio (BCM). El rol distintivo de MSP: alguien del negocio operativo (no el equipo de entrega) responsable de incorporar el cambio y realizar los beneficios sobre el terreno. El BCM es por qué los programas entregan resultados y no solo productos entregables —los proyectos traspasan capacidad, el BCM la convierte en beneficio.

Buenas prácticas#

1. Anclar el programa en una visión y un plano director. Define el resultado estratégico y tradúcelo en un modelo operativo objetivo concreto (procesos, organización, tecnología, información —POTI). Cada proyecto y producto constituyente se dirige entonces hacia el mismo estado futuro, que es lo que detiene una coalición de entregas de fragmentarse.

2. Gestionar beneficios, no solo productos entregables. Construye un mapa de beneficios que vincule cada producto entregable con los resultados y beneficios medibles que debería producir, con propietarios y líneas base. Revisa los beneficios activamente a través del programa, y está dispuesto a detener trabajo que no se va a recuperar —el énfasis de MSP en la realización de beneficios es la disciplina que separa un programa de una costosa lista de tareas.

3. Estructurar el trabajo en tramos con puntos de revisión reales. Entrega capacidad en tramos, y en cada límite de tramo demuestra los beneficios realizados hasta ahora, vuelve a probar el plano director frente a lo aprendido, y toma una decisión genuina de continuar/ajustar/detener. Los tramos tempranos deberían apuntar a victorias rápidas visibles para construir la confianza de las partes interesadas para los más difíciles posteriores.

4. Nombrar un SRO facultado y una junta de programa real. Nombra a un único SRO con la antigüedad y autoridad para dirigir el programa y decidir a través de límites organizacionales, y convoca a una junta que genuinamente represente a las organizaciones afectadas. Los programas fallan cuando la responsabilidad es difusa o el SRO no puede realmente hacer que las decisiones entre límites se sostengan.

5. Poner a gerentes de cambio de negocio en el negocio operativo. Asigna BCM de las organizaciones de primera línea para poseer la adopción y realización de beneficios donde se entrega la atención. La capacidad entregada pero no adoptada no realiza ningún beneficio; el rol de BCM es el mecanismo que cierra esa brecha.

6. Coordinar —no microgestionar— los proyectos y productos constituyentes. El programa establece el plano director, las interdependencias, los estándares, y los beneficios; deja que los proyectos y equipos de producto entreguen dentro de ese marco. Gestiona las costuras —estándares de datos compartidos, gobernanza de la información, secuenciación, e infraestructura compartida— no el detalle interno de cada entrega.

7. Gestionar incansablemente el riesgo transversal, la dependencia, y las partes interesadas. El valor que un programa añade sobre proyectos independientes está en gran parte en gestionar lo que sucede entre ellos. Mantén una vista a nivel de programa de las interdependencias y riesgos compartidos, e invierte fuertemente en el involucramiento de partes interesadas a través de organizaciones autónomas, ya que la alineación es voluntaria, no ordenada.

8. Cerrar el programa cuando el cambio esté incorporado, y traspasar los servicios continuos a equipos de producto. Un programa es temporal. Cuando se alcanza el plano director y se están realizando los beneficios, ciérralo deliberadamente, transfiere cualquier servicio perdurable a equipos de producto duraderos (Tema 5.0), y sigue rastreando los beneficios hacia las operaciones habituales —muchos beneficios se acumulan después de que el programa termina.

Preguntas para debatir con tu equipo#

1. ¿Nuestro propietario senior responsable realmente tiene la autoridad para hacer que las decisiones se sostengan a través de organizaciones socias soberanas, o solo la responsabilidad cuando no lo hacen? El trabajo liderado por programa vive o muere según la autoridad entre límites, porque el cambio abarca fideicomisos autónomos, atención primaria, comunidad, salud mental, y atención social que no se les puede simplemente ordenar moverse al unísono. El fallo característico es un SRO nombrado que lleva la responsabilidad personal y pública de los beneficios pero carece de la posición para obligar a un socio reticente a adoptar un estándar de datos compartido o cambiar un flujo de trabajo clínico —responsabilidad sin autoridad. El debate debería ser franco sobre dónde reside el poder real en el sistema: si la junta de programa genuinamente representa a las organizaciones afectadas o es un foro de reporte, si el SRO es lo suficientemente senior para que sus decisiones se respeten a través de límites soberanos, y qué pasa cuando un socio se niega a moverse. Considera una decisión reciente entre organizaciones y rastrea si realmente se sostuvo. Una buena respuesta nombra quién es el SRO y prueba su autoridad frente a un conflicto concreto entre límites, es honesta sobre las organizaciones que efectivamente pueden optar por no participar, y trata una junta representativa y gerentes de cambio de negocio incorporados como mecanismos de carga estructural para la alineación voluntaria en lugar de decoración de gobernanza.

2. ¿Cómo sabremos que este programa ha realizado beneficios y no meramente entregado productos entregables —y quién, en el negocio operativo, es responsable de convertir la capacidad en beneficio? El teatro de productos entregables es la patología recurrente contra la que advierte el tema: un programa gasta millones, produce un montón de plataformas de interoperabilidad e integraciones, y sin embargo nada medible cambia para pacientes o personal. La distinción que lo previene es el gerente de cambio de negocio —alguien de la operación de primera línea, no el equipo de entrega, responsable de incorporar el cambio y realizar el beneficio donde se entrega la atención— así que la pregunta obliga al equipo a nombrar a esas personas y confirmar que existen. La tensión es que la entrega es visible y satisfactoria mientras que la adopción es lenta, poco glamorosa, y fácil de asumir que simplemente sucederá; un registro de atención compartido enterrado detrás de un inicio de sesión adicional no realiza ningún beneficio por bien que esté construido. Trae el mapa de beneficios a la discusión y pon a prueba si cada producto entregable está vinculado a un beneficio poseído, con línea base, y medible (menos pruebas duplicadas, altas retrasadas reducidas) o si los beneficios meramente se afirman. Una respuesta honesta nombra a un BCM en cada organización socia, admite dónde los beneficios actualmente no tienen propietario o no se miden, y acepta que algunos beneficios se acumulan solo después de que el programa cierra y deben rastrearse hacia las operaciones habituales.

3. ¿Estamos dividiendo este programa en tramos para acumular beneficios tempranos y crear puntos reales de continuar/ajustar/detener, o derivando hacia una entrega de big bang que aplaza todo el riesgo a un momento tardío? Los tramos son lo que separa un programa de un costoso plan congelado: cada límite de tramo debería entregar un paso de capacidad, demostrar los beneficios realizados hasta ahora, volver a probar el plano director frente a lo realmente aprendido, y apoyar una decisión genuina de continuar, ajustar, o detener. La tentación en la salud y la atención es secuenciar por conveniencia de ingeniería y aplazar el valor visible —conectando cada fideicomiso antes de que alguien pueda usar algo— lo que carga todo el riesgo en una única entrega tardía y deja a la junta directiva sin evidencia para defender la inversión continua a través de ciclos fiscales y políticos. El debate debería examinar si los tramos tempranos apuntan a victorias rápidas deliberadas que construyen la confianza de las partes interesadas para el trabajo más difícil posterior, y si los puntos de revisión son decisiones reales o puntos de control de cronograma. Considera cuál es el primer beneficio demostrable, cuán pronto llega, y qué haría realmente la junta directiva en una revisión de tramo si la adopción se retrasara o el plano director resultara equivocado. Una buena respuesta describe tramos concretos con victorias tempranas y medibles, trata cada límite como un ir/no ir real con el plano director genuinamente abierto a revisión, y es honesta sobre cualquier presión para aplazar el valor hasta el final.

4. ¿Tenemos un único plano director mantenido del modelo operativo objetivo, o cada proyecto está silenciosamente optimizando hacia su propia versión del futuro? El plano director —el modelo operativo objetivo POTI concreto de procesos, organización, tecnología, e información— es lo que hace que las piezas sumen un todo coherente en lugar de una colisión de decisiones localmente sensatas. Sin uno, cada proyecto constituyente optimiza racionalmente para su propio alcance: un fideicomiso elige un estándar de datos que se adapta a su EPR titular, otro diseña un flujo de trabajo clínico alrededor de su propio personal, y el registro de atención compartido se fragmenta en integraciones que técnicamente conectan pero no cohesionan. La tensión es que mantener un plano director se siente como gastos generales para equipos de entrega bajo presión de enviar, y debe ser una referencia viva reprobada en cada tramo en lugar de un documento escrito una vez y archivado. El debate debería establecer si el plano director realmente existe en forma usable, quién lo posee, y si las decisiones reales de proyecto están siendo dirigidas por él o meramente conciliadas con él después del hecho. Considera una elección de diseño reciente en un proyecto y pregunta si el plano director la dio forma o fue silenciosamente anulada. Una respuesta honesta puede señalar un plano director actual, nombra a su propietario, y es franca sobre dónde la optimización local ya está separando el estado objetivo.

5. Cuando el programa cierre, ¿qué perdura —y hemos nombrado a los equipos de producto duraderos que operarán la capacidad y seguirán rastreando los beneficios hacia las operaciones habituales? Un programa es temporal por definición, pero el registro de atención compartido, la plataforma de interoperabilidad, y los beneficios que producen no lo son, así que el cierre es un problema de diseño a planificar desde el principio en lugar de una idea de última hora. El fallo recurrente en cada extremo del espectro es real: algunos programas nunca cierran y se endurecen en burocracias permanentes mucho después de que el cambio está incorporado, mientras que otros cierran abruptamente y dejan varado un servicio clínico en vivo sin propietario duradero. El tema es explícito en que los servicios perdurables deberían transferirse a equipos de producto duraderos (Tema 5.0) y que muchos beneficios se acumulan solo después de que el programa termina y deben rastrearse hacia las operaciones habituales —lo que significa que los equipos receptores y la propiedad continua de beneficios tienen que identificarse mientras el programa todavía tiene la autoridad y financiación para establecerlos. El debate debería sacar a la luz quién operará cada capacidad perdurable, cómo se financiará una vez que se detenga el dinero de transformación, y quién sigue midiendo los beneficios cuando la junta de programa se haya disuelto. Una buena respuesta nombra los equipos de producto específicos y los propietarios de operaciones habituales, describe honestamente la transición de financiación, y trata el cierre y el rastreo de beneficios como tramos planificados en lugar de un traspaso esperanzado.

6. ¿Cómo estamos gestionando las costuras entre proyectos —estándares compartidos, gobernanza de la información, secuenciación, e infraestructura compartida— en lugar de los internos de cada entrega? El valor que un programa añade sobre un conjunto de proyectos independientes vive casi enteramente en el espacio entre ellos: las interdependencias, los estándares de datos compartidos, el marco de gobernanza de la información y consentimiento, y la infraestructura común que ningún proyecto individual posee pero de la que todos dependen. La tentación para un equipo de programa es derivar hacia la microgestión de los internos de cada entrega —trabajo cómodo y visible— mientras las costuras transversales genuinamente difíciles quedan sin gestionar hasta que emergen como un fallo de integración o un bloqueo de gobernanza de la información en la puesta en marcha. En la salud y la atención estas costuras son inusualmente de carga estructural, porque los flujos de datos y el consentimiento cruzan límites organizacionales y regulatorios soberanos donde la alineación es voluntaria y los deberes legales se comparten pero se dotan de recursos de forma desigual. El debate debería probar si hay una vista a nivel de programa de las interdependencias y riesgos compartidos, quién posee los estándares e infraestructura compartidos, y si el programa está coordinando costuras o entrometiéndose en el detalle de proyecto. Una respuesta honesta identifica las costuras específicas que más amenazan el resultado, nombra a sus propietarios, y es franca sobre si el programa está añadiendo valor en los límites o duplicando el trabajo de los proyectos que debería estar habilitando.

En la práctica: un ejemplo de salud y atención#

Un ICS se propone entregar un registro de atención compartido que dé a los clínicos a través de agudos, comunidad, salud mental, atención primaria, y atención social una vista unificada de una persona. Ningún proyecto individual puede entregar esto: abarca múltiples fideicomisos, varios sistemas fuente, acuerdos de gobernanza de la información, rediseño de flujo de trabajo clínico, e involucramiento público. Se coordina como un programa MSP.

El SRO —un ejecutivo del ICS con autoridad genuina de todo el sistema— preside una junta de programa con representantes de cada organización socia y gerentes de cambio de negocio nombrados en cada una. El programa establece una visión ("la información correcta, sobre la persona correcta, disponible para el clínico correcto, en el punto de atención") y un plano director que describe el modelo operativo objetivo: la arquitectura y estándares de intercambio de datos (interoperabilidad basada en HL7 FHIR), el marco de gobernanza de la información, el modelo de consentimiento, y los flujos de trabajo clínicos rediseñados.

El trabajo se organiza en tramos. El primer tramo conecta a dos fideicomisos agudos dispuestos y entrega un registro de solo lectura, una victoria rápida deliberada que prueba el enfoque y permite a la junta directiva demostrar un beneficio temprano —una reducción medible en pruebas duplicadas— para construir confianza. En la revisión del primer tramo, la junta directiva aprende que la adopción de clínicos se retrasa donde el registro está enterrado en un inicio de sesión adicional, así que ajusta el plano director para priorizar la integración de inicio de sesión único antes de ampliar el despliegue.

Debajo del programa, los modos coexisten. La plataforma de interoperabilidad la opera un equipo de producto duradero (Tema 5.0) que sigue mejorándola a través de todo el programa y más allá. La conexión de cada fideicomiso es un proyecto limitado (Tema 5.1) con su propio caso de negocio y puesta en marcha. El programa mismo coordina el plano director, los estándares, las interdependencias, y —a través de los BCM— la realización de beneficios. Cuando se alcanza el plano director y los beneficios de pruebas duplicadas y altas retrasadas están fluyendo, el programa cierra; el equipo de producto de la plataforma perdura, y el rastreo de beneficios continúa hacia las operaciones habituales.

Perspectivas sectoriales#

Startup#

Pocas startups operan programas en el sentido de MSP —carecen del alcance multiorganizacional que define uno— pero una escalada que se despliega a través de varios fideicomisos efectivamente se convierte en un participante de programa. Su rol realista es como proveedor dentro del programa de otra persona: alinear su producto con el plano director del programa, alcanzar los hitos de tramo, y alimentar el caso de beneficios que el SRO debe evidenciar. La financiación y supervivencia dependen de que el programa continúe, así que la startup trata las revisiones de tramo como puntos existenciales de ir/no ir e invierte en el éxito de los gerentes de cambio de negocio, porque la adopción sobre el terreno es lo que renueva su contrato. La disciplina que debe tomar prestada es el lenguaje de beneficios —enmarcar su valor como resultados realizados, no funciones enviadas.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, o un pequeño proveedor de tecnología de salud pasada la etapa de startup— casi nunca opera un programa, pero es rutinariamente arrastrado a uno como participante afectado cuando un ICS despliega un registro de atención compartido o converge sistemas a través de la zona. Su preocupación práctica es la costura que posee el programa: debe adoptar los estándares de datos, acuerdos de gobernanza de la información, y modelo de consentimiento obligatorios con capacidad de TI dedicada delgada o nula y sin holgura para absorber el cambio de flujo de trabajo, sin embargo lleva los mismos deberes legales que los grandes fideicomisos a su alrededor. La relación más valiosa que tiene es con el gerente de cambio de negocio de su localidad, porque una adopción bien apoyada —formación, inicio de sesión único, un flujo de trabajo que se ajuste a cómo realmente opera la consulta— es la diferencia entre que el beneficio del programa aterrice y que el cambio sea silenciosamente evitado. Su solicitud realista al programa es apoyo proporcional y secuenciación que no asuma recursos a escala empresarial, y su contribución honesta es retroalimentación temprana y franca en las revisiones de tramo sobre qué no es viable sobre el terreno.

Gran organización#

Un ICS o gran fideicomiso es el hogar natural del trabajo liderado por programa: los registros de atención compartidos, la convergencia de EPR, y la transformación de vías son inherentemente multiorganizacionales y de varios años. La parte difícil es la autoridad —el SRO debe hacer que las decisiones se sostengan a través de organizaciones socias soberanas que no se les puede simplemente ordenar, así que una junta de programa genuinamente representativa y gerentes de cambio de negocio incorporados en cada socio son de carga estructural, no decorativos. La financiación es mixta (dinero de transformación de sistema, capital de fideicomiso, asignaciones nacionales), lo que hace del mapa de beneficios y las revisiones de tramo esenciales para defender la inversión continua ante líderes de sistema y reguladores. El riesgo recurrente a esta escala es el teatro de productos entregables: entrega técnica sin nadie responsable de convertirla en beneficio.

Gobierno#

A escala nacional, los programas llevan la gobernanza más pesada —típicamente entran en el Government Major Projects Portfolio, se someten a aseguramiento y revisiones de puerta de la Infrastructure and Projects Authority, y responden ante ministros, el Public Accounts Committee, y la National Audit Office. El SRO es personal y públicamente responsable de la realización de beneficios a través de todo el sistema, y los planos directores deben conciliar estándares nacionales (interoperabilidad, gobernanza de la información, la NHS App como puerta de entrada común) con la autonomía local. La financiación se ejecuta a través de acuerdos de Spending Review de varios años, así que la división en tramos y la evidencia de beneficios son el mecanismo para sostener o detener la inversión a través de ciclos fiscales y políticos. Lo que está en juego es a escala poblacional: los beneficios de un programa nacional —o su fracaso— se miden en millones de pacientes y miles de millones de libras.

Modos de fallo comunes#

• Teatro de productos entregables. El programa entrega productos técnicos pero nadie posee convertirlos en beneficios, así que nada cambia para los pacientes. Corrección: mapas de beneficios con propietarios, y BCM en el negocio operativo.
• Un programa que es solo un gran proyecto. Gobernanza de alcance fijo y enfocada en productos entregables aplicada a cambio genuinamente incierto y multiorganizacional. Corrección: gestiona por resultados/beneficios y tramos, no un único plan congelado.
• Un SRO sin poder. Responsabilidad sin autoridad para decidir a través de límites. Corrección: nombra a un SRO suficientemente senior para hacer que las decisiones de sistema se sostengan, respaldado por una junta representativa.
• Sin plano director / estado objetivo. Los proyectos optimizan localmente y las piezas nunca cohesionan. Corrección: define y mantén un plano director POTI hacia el que todo se dirija.
• Big bang en lugar de tramos. Todo el riesgo aplazado a una única entrega tardía. Corrección: divide el trabajo en tramos, acumula beneficios tempranos, y replanifica en los puntos de revisión.
• Un programa que nunca cierra. Se convierte en una burocracia permanente mucho después de que el cambio está incorporado. Corrección: cierra deliberadamente, traspasa los servicios perdurables a equipos de producto, sigue rastreando los beneficios en las operaciones habituales.

Modelo de madurez#

Lista de verificación#

• ¿Es este genuinamente un cambio multiproyecto y multiorganizacional hacia un resultado estratégico?
• ¿Hay una visión clara y un plano director concreto (modelo operativo objetivo / POTI)?
• ¿Hay un mapa de beneficios que vincula productos entregables con beneficios medibles, poseídos, y con línea base?
• ¿El trabajo está estructurado en tramos con puntos reales de revisión de continuar/ajustar/detener?
• ¿Hay un SRO facultado con autoridad para decidir a través de límites organizacionales?
• ¿La junta de programa genuinamente representa a las organizaciones afectadas?
• ¿Los gerentes de cambio de negocio están incorporados en el negocio operativo para poseer la adopción?
• ¿Los estándares transversales, interdependencias, y riesgos compartidos se gestionan a nivel de programa?
• ¿Los modos liderado por producto, liderado por proyecto, y liderado por programa coexisten con roles claros (Temas 5.0–10)?
• ¿Hay un cierre deliberado, con servicios perdurables traspasados a equipos de producto duraderos y beneficios rastreados hacia operaciones habituales?

Fuentes clave#

• AXELOS / PeopleCert — Managing Successful Programmes (MSP): principios, temas, y el flujo transformacional (incluyendo plano director, tramos, gestión de beneficios, y los roles SRO/BCM).
• Cabinet Office / Infrastructure and Projects Authority (IPA) — orientación sobre grandes programas, responsabilidad del SRO, y revisiones de aseguramiento/puerta.
• HM Treasury — The Green Book y orientación de gestión de beneficios (evaluación de beneficios).
• AXELOS — Management of Portfolios (MoP), para posicionar programas dentro de una cartera (véase el Tema 5.3 — EPPM).
• NHS England — orientación sobre sistemas de atención integrada y registros de atención compartidos (interoperabilidad, estándares HL7 FHIR) para el contexto del dominio.
• Mik Kersten — Project to Product, para el cambio de inversión basada en productos entregables a basada en resultados/beneficios.

Referencias#

1. Program management — Wikipedia — https://en.wikipedia.org/wiki/Program_management
2. Benefits realisation management — Wikipedia — https://en.wikipedia.org/wiki/Benefits_realisation_management
3. Target operating model — Wikipedia — https://en.wikipedia.org/wiki/Target_operating_model
4. Executive sponsor (Senior Responsible Owner) — Wikipedia — https://en.wikipedia.org/wiki/Executive_sponsor
5. Integrated care system — Wikipedia — https://en.wikipedia.org/wiki/Integrated_care_system
6. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
9. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
10. Stakeholder management — Wikipedia — https://en.wikipedia.org/wiki/Stakeholder_management
11. Managing Successful Programmes (MSP): principles, themes, and the transformational flow — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/MSP-1006
12. Guidance on major programmes, SRO accountability, and assurance/gateway reviews — Cabinet Office / Infrastructure and Projects Authority — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
13. The Green Book and benefits-management guidance — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
14. Management of Portfolios (MoP) — AXELOS / PeopleCert — https://www.peoplecert.org/
15. Integrated care systems and shared care records (interoperability, HL7 FHIR standards) — NHS England — https://www.england.nhs.uk/integratedcare/
16. Project to Product — Mik Kersten, IT Revolution (2018) — https://itrevolution.com/product/project-to-product/