Tema 5.1 — Trabajo liderado por proyecto

En una frase: El trabajo liderado por proyecto es la herramienta correcta cuando el trabajo tiene un alcance definido, una vida finita, y un estado final claro —un esfuerzo temporal y controlado entregado según el tiempo, coste, y calidad acordados, y luego cerrado.

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

No todo es un servicio vivo. Parte del trabajo más importante en la salud y la atención es genuinamente finito: migrar de una historia clínica electrónica a otra, desplegar Wi-Fi a través del patrimonio de un hospital, reemplazar servidores al final de su vida útil, retirar un sistema heredado antes de que termine un contrato de proveedor, o entregar el elemento digital de una nueva construcción hospitalaria. Este trabajo tiene un principio, un medio, y un final definido. Gestionarlo como un producto abierto desperdiciaría dinero y difuminaría la responsabilidad; necesita la disciplina de un proyecto.

La gestión de proyectos se gana su lugar aquí precisamente porque lo que está en juego es alto y las restricciones son duras. Una transición de migración de datos tiene un fin de semana de puesta en marcha fijo, un riesgo de seguridad del paciente si los registros se pierden o corrompen, y un precipicio contractual si el sistema antiguo se apaga. El dinero público se compromete contra un caso de negocio, y el Parlamento, los auditores, y las juntas directivas preguntarán si se gastó según lo aprobado. El trabajo liderado por proyecto proporciona la gobernanza —un caso de negocio, puertas de etapa, y un cierre controlado— que permite a una junta directiva comprometer capital con confianza y detener el trabajo limpiamente si la justificación desaparece.

El peligro está en usar esta herramienta para el trabajo equivocado. La gobernanza liderada por proyecto aplicada a un servicio digital en evolución produce la patología de "constrúyelo y abandónalo" descrita en el Tema 5.0 — Trabajo liderado por producto. Este tema explica dónde el trabajo liderado por proyecto es el instrumento correcto, y dónde comienzan sus límites. Se sitúa junto al Tema 5.2 — Trabajo liderado por programa, que coordina múltiples proyectos, y el Tema 5.3 — Gestión de cartera y proyectos empresariales (EPPM), que elige entre estas herramientas.

Conceptos clave#

Proyecto. Una organización temporal creada para entregar uno o más productos entregables definidos según una especificación acordada, dentro de restricciones de tiempo, coste, y calidad. La característica definitoria es que es temporal —existe para alcanzar un fin definido y luego disolverse.

El triángulo de hierro (alcance, tiempo, coste). El modelo clásico de restricción: el alcance, el cronograma, y el presupuesto son interdependientes, y la calidad se ve afectada por cómo se equilibran. Cambia uno y cambias los otros; el control de proyecto es en gran parte la disciplina de gestionar esta disyuntiva transparentemente.

PRINCE2 (PRojects IN Controlled Environments). El método estructurado de gestión de proyectos del gobierno del Reino Unido, ampliamente usado a través del NHS y el sector público. Se construye sobre principios (justificación continua del negocio, roles definidos, gestionar por etapas, gestionar por excepción, enfoque en productos, aprender de la experiencia, adaptar al entorno) y organiza el trabajo en etapas controladas con una junta de proyecto que proporciona dirección.

PMI / PMBOK. La Guide to the Project Management Body of Knowledge del Project Management Institute es la contraparte internacional dominante, enmarcando el trabajo de proyecto alrededor de dominios de rendimiento y principios en lugar de un proceso escalonado prescrito. PRINCE2 y PMBOK son lentes complementarias sobre la misma disciplina.

Caso de negocio. El documento que justifica el proyecto: el problema, las opciones evaluadas, los beneficios esperados, los costes, y los riesgos. En PRINCE2 el caso de negocio es vivo —se verifica en cada límite de etapa, y si la justificación continua desaparece, la decisión correcta es detenerse. En organismos públicos del Reino Unido esto generalmente se estructura como el Five Case Model del HM Treasury (estratégico, económico, comercial, financiero, de gestión).

Puertas de etapa. Un proyecto PRINCE2 se divide en etapas de gestión separadas por puertas de decisión. En cada límite la junta de proyecto toma una decisión deliberada de detener/proceder: revisa el progreso y el caso de negocio, aprueba el plan de la siguiente etapa, y compromete recursos solo para esa etapa. Así es como una junta directiva mantiene el control y evita tirar dinero bueno tras el malo.

Registro RAID. Un registro único de Riesgos, Suposiciones, Incidentes, y Dependencias (Risks, Assumptions, Issues, Dependencies) —el artefacto de control central del gerente de proyecto. RAID hace visible y manejable la incertidumbre: los riesgos son cosas que podrían suceder, los incidentes son cosas que han sucedido, las suposiciones son en lo que se basa el plan, y las dependencias son lo que el plan necesita de otros lugares.

Buenas prácticas#

1. Comenzar con un caso de negocio honesto y mantenerlo vivo. Usa una estructura reconocida (el Five Case Model en organismos públicos del Reino Unido) para evaluar opciones reales, no una única respuesta predeterminada. Luego trata el caso de negocio como un documento vivo revisado en cada puerta de etapa —la justificación continua del negocio es el primer principio de PRINCE2, y perderla es una razón legítima para detenerse.

2. Definir el alcance con precisión y controlar los cambios a él. El valor de un proyecto es una definición clara y limitada de "terminado". Acuerda el alcance, establécelo como línea base, y ejecuta cada cambio propuesto a través de un proceso de control de cambios para que el aumento de alcance no consuma silenciosamente el presupuesto y el cronograma.

3. Gestionar por etapas con puertas de decisión reales. Divide el trabajo en etapas de gestión y realiza una revisión genuina de detener/proceder en cada límite. Una puerta que siempre dice "proceder" es teatro; la disciplina solo funciona si detenerse o replanificar es una opción real que la junta directiva ejercerá.

4. Ejecutar un registro RAID vivo y escalar por excepción. Mantén Riesgos, Suposiciones, Incidentes, y Dependencias en un solo lugar, revísalo regularmente, y usa la "gestión por excepción" de PRINCE2 —el gerente de proyecto opera dentro de tolerancias acordadas y escala a la junta directiva solo cuando una tolerancia está amenazada. Esto mantiene el tiempo senior enfocado en decisiones genuinas.

5. Asignar responsabilidad clara y de punto único. PRINCE2 insiste en roles definidos: una junta de proyecto con un propietario senior responsable/ejecutivo que posee el caso de negocio, un usuario senior que representa a quienes usarán el producto entregable, y un proveedor senior. La responsabilidad ambigua es la causa más común de deriva.

6. Planificar la transición al servicio en vivo antes de comenzar. Un proyecto entrega un producto; alguien debe operarlo después. Acuerda el equipo receptor, el modelo de apoyo, y el traspaso de seguridad clínica (DCB0160 para el despliegue) como parte del proyecto, para que la puesta en marcha no sea un precipicio hacia un vacío de propiedad.

7. Incorporar la seguridad clínica, la gobernanza de la información, y las pruebas. Para cualquier sistema que toque datos de pacientes, el caso de seguridad clínica, la DPIA, y las pruebas de transición/reversión no son extras opcionales —son productos entregables que sirven de puerta. Una migración sin un plan de reversión probado no está lista para ponerse en marcha.

8. Cerrar el proyecto deliberadamente y capturar lecciones. Un final definido significa un cierre definido: confirma que los productos entregables se aceptan, traspasa a operaciones, libera al equipo, y registra las lecciones aprendidas (el registro de lecciones de PRINCE2). Un proyecto no cerrado filtra recursos y responsabilidad indefinidamente.

Preguntas para debatir con tu equipo#

1. ¿El trabajo frente a nosotros es genuinamente finito con un estado final definido, o estamos recurriendo a la gobernanza de proyecto porque es la ruta de financiación que conocemos? Esta es la pregunta decisiva sobre la que gira el tema, porque la disciplina liderada por proyecto es el instrumento correcto solo cuando el trabajo verdaderamente tiene un principio, un medio, y un final definido. En una organización de salud y atención la atracción hacia la forma de proyecto es fuerte —el presupuesto de capital, la maquinaria de casos de negocio, y el reporte a la junta directiva están todos construidos para ello— así que un servicio digital en evolución puede disfrazarse de proyecto simplemente porque así es como se libera el dinero, lo que luego produce la patología de construir-y-abandonar. El debate debería examinar cada candidato honestamente: un reemplazo de sistema de patología antes de que un proveedor retire el soporte tiene un precipicio contractual duro y es inequívocamente finito, mientras que "mejorar la aplicación del paciente" no tiene estado final y pertenece al Tema 5.0. Considera si hay una puesta en marcha real después de la cual el equipo debería disolverse, o si alguien necesitará seguir mejorando la cosa indefinidamente. Una buena respuesta resiste usar la gobernanza de proyecto como hábito, nombra el estado final concreto y el evento que define "terminado", y está dispuesta a decir que algo de lo que actualmente operamos como proyectos nunca debería haber sido un proyecto en absoluto.

2. En nuestras puertas de etapa, ¿esta junta directiva realmente detendría o replanificaría un proyecto que ha perdido su justificación —y podemos señalar una vez que lo hicimos? Las puertas de etapa solo son un control si detenerse es una opción genuina que la junta directiva ejercerá; una puerta que siempre dice "proceder" es teatro, y la justificación continua del negocio es el primer principio de PRINCE2 precisamente porque perderla debería terminar el trabajo. La tensión en la salud y la atención es aguda: detener una migración de EPR parcialmente construida o una transición de sistema de laboratorio se siente como admitir el fracaso, desperdiciar el coste hundido, y perturbar a clínicos que ya han cambiado sus planes, así que las juntas directivas racionalizan seguir adelante incluso cuando el caso de negocio se evapora silenciosamente. Trae un ejemplo real a la discusión —un proyecto donde las pruebas revelaron que el riesgo de mapeo de datos era peor de lo asumido, o donde los beneficios se deslizaron— y pregunta si la puerta se usó según lo diseñado o se aprobó automáticamente. Considera qué tolerancias disparan la escalación, quién en la junta directiva tiene la posición para llamar a un alto, y si el razonamiento de coste hundido se nombra y desafía en la sala. Una respuesta honesta admite dónde las puertas han sido formalidades, describe las condiciones bajo las cuales la junta directiva genuinamente detendría o replantearía el alcance, y trata la autoridad de detenerse antes de una pérdida pública como el valor real de la disciplina en lugar de una amenaza.

3. ¿Quién recibe el producto entregable de cada proyecto como un servicio en vivo, y cómo hacemos del traspaso de seguridad clínica y la propiedad continua un producto entregable de puerta en lugar de un precipicio? Un proyecto entrega un producto; algo finito termina, pero lo que produjo debe operarse, mejorarse, y mantenerse seguro mucho después de que el equipo se disuelva —y el fallo silencioso más común es que nadie lo posea en el otro lado. En un sistema que toca datos de pacientes esto no es orden administrativo; el caso de seguridad de despliegue DCB0160, la DPIA, una reversión probada, y un equipo receptor nombrado son lo que se interpone entre una puesta en marcha controlada y un vacío de propiedad donde los riesgos de seguridad se acumulan sin gestionar. El debate debería forzar claridad sobre la transición antes de que comience el proyecto, no en el fin de semana de puesta en marcha: qué equipo operativo lo toma, cuál es el modelo de apoyo, y si ese equipo tiene la capacidad y modo de trabajo (liderado por producto, según el Tema 5.0) para seguir mejorándolo. Considera puestas en marcha recientes concretas y si el traspaso fue planificado o improvisado, y si se permitió que "el proyecto está terminado" significara "y ahora no es trabajo de nadie". Una buena respuesta nombra el equipo receptor y el modelo de apoyo por adelantado, trata el traspaso de seguridad como una puerta que el proyecto no puede pasar sin ella, y asigna explícitamente la mejora continua del servicio en vivo al modo de trabajo correcto en lugar de dejarla a la deriva.

4. Cuando el triángulo de hierro muerde y el alcance, tiempo, y coste chocan, ¿qué restricción flexionamos, y a la seguridad del paciente alguna vez se le permite ser la variable que cede? Cada proyecto real eventualmente llega al momento en que el cronograma, el presupuesto, y el alcance prometido no pueden sostenerse todos, y cómo el equipo resuelve esa presión revela lo que realmente valora. En la salud y la atención la trampa es distintiva: porque la fecha final a menudo es un precipicio contractual duro —un proveedor retirando el soporte, un arrendamiento expirando, un centro de datos cerrando— el tiempo frecuentemente no puede moverse, así que la presión cae silenciosamente sobre la calidad, lo que en un sistema clínico significa cortar pruebas, comprimir la validación, o enviar con defectos conocidos de mapeo de datos. La discusión debería nombrar, con antelación, qué esquina del triángulo protegerá la organización y cuál sacrificará, y ser explícita en que la seguridad clínica y la gobernanza de la información no son la válvula de liberación incluso cuando todo lo demás es fijo. Mira una transición reciente y pregunta qué cedió silenciosamente cuando las fechas se mantuvieron: ¿fue el ensayo de reversión, la ventana de validación clínica, la formación? Considera quién tiene la autoridad para mover la fecha de puesta en marcha en lugar de erosionar el margen de seguridad, y si esa conversación sucede abiertamente en la junta directiva o por defecto sobre el terreno. Una respuesta honesta declara el orden de prioridad antes de la presión, trata una fecha deslizada o una etapa replanificada como un resultado legítimo, y se niega a dejar que la presión de cronograma no expresada se convierta en riesgo clínico no registrado.

5. ¿Nuestro registro RAID es un instrumento vivo que cambia lo que hacemos, o un documento que mantenemos para parecer gobernados —y sacaría a la luz el riesgo que realmente hunde el proyecto? Un registro RAID se gana su lugar solo si revisarlo cambia decisiones; la patología común es un registro escrito en el arranque, presentado en juntas directivas, y nunca genuinamente actuado mientras los riesgos que importan maduran sin ser vigilados. En una migración o transición los riesgos decisivos a menudo son específicos y conocibles —resultados históricos que no se mapearán limpiamente a nuevos rangos de referencia, una dependencia de los cambios de firewall de otro equipo, una suposición de que el recurso de validación clínica estará libre cuando se necesite— y la pregunta es si el registro los nombra concretamente o se esconde detrás de entradas genéricas como "restricciones de recursos". El debate debería probar si la escalación por excepción es real: ¿el gerente de proyecto opera dentro de tolerancias acordadas y eleva la atención de la junta directiva solo cuando una está amenazada, o todo permanece silencioso o se convierte en crisis? Considera si los casi-accidentes y los incidentes materializados retroalimentan cómo se planifica la siguiente etapa, o simplemente se registran y olvidan. Una buena respuesta puede señalar una decisión que el registro RAID realmente cambió, distingue los dos o tres riesgos que genuinamente podrían detener el proyecto de la larga cola de menores, y trata el registro como un control de trabajo en lugar de un artefacto producido para el aseguramiento.

6. Después de cerrar y disolvernos, ¿alguien verifica si los beneficios en el caso de negocio realmente se materializaron —y lo sabríamos si no lo hicieron? El caso de negocio promete beneficios para justificar el gasto, pero el trabajo liderado por proyecto naturalmente termina en la puesta en marcha y liberación del equipo, así que el momento de la verdad —¿la migración realmente redujo el riesgo, cortó el coste, o mejoró la atención?— generalmente cae después de que todos se han movido y nadie es responsable de confirmarlo. Esto importa agudamente en la salud y atención pública, donde el dinero se compromete contra un caso de negocio Five Case al que se le dijo al Parlamento, auditores, y juntas directivas que entregaría resultados específicos, sin embargo la realización de beneficios es el paso más a menudo saltado porque el proyecto que lo habría poseído ya no existe. La discusión debería decidir quién hereda el rastreo de beneficios cuando el proyecto cierra, durante qué período, y contra qué mediciones de línea base —que tienen que capturarse antes de la puesta en marcha o se pierden. Considera un proyecto completado recientemente y pregunta llanamente si alguien ha verificado desde entonces sus beneficios prometidos, y si un déficit alguna vez alcanzaría a la junta directiva que lo aprobó. Una respuesta honesta asigna la propiedad de beneficios posterior al cierre a una función permanente en lugar del equipo disuelto, captura la línea base mientras el proyecto todavía está vivo, y está dispuesta a registrar que un proyecto entregó su producto a tiempo y dentro del presupuesto sin embargo no entregó el valor que lo justificó.

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

Un fideicomiso agudo debe reemplazar su envejecido sistema de gestión de información de laboratorio de patología antes de que el proveedor titular retire el soporte en 14 meses. Este es trabajo liderado por proyecto de libro de texto: fecha final fija, alcance definido, un precipicio contractual duro, y riesgo agudo de seguridad del paciente si se pierden resultados en la migración.

El fideicomiso escribe un caso de negocio Five Case evaluando tres opciones (actualizar en el lugar, contratar un nuevo sistema, compartir una instancia regional), selecciona la contratación, y establece un proyecto PRINCE2 con una junta clara: un ejecutivo que posee el caso de negocio, un usuario senior (el científico biomédico principal), y el proveedor senior. El trabajo se divide en etapas de gestión —contratación, construcción y configuración, migración de datos, pruebas, y puesta en marcha— cada una terminando en una puerta de decisión.

El gerente de proyecto ejecuta un registro RAID. Un riesgo clave es que los resultados históricos podrían no mapearse limpiamente a los rangos de referencia del nuevo sistema; una dependencia es los cambios de firewall del equipo de red; una suposición es que el recurso de validación clínica estará disponible para las pruebas. En la puerta de etapa de migración, las pruebas revelan que el riesgo de mapeo de datos es peor de lo asumido, así que la junta directiva usa la puerta según lo diseñado: no procede ciegamente, sino que aprueba una etapa replanificada con una ventana de validación extendida y un plan de reversión probado, protegiendo la seguridad del paciente sobre el cronograma original.

La puesta en marcha sucede durante un fin de semana controlado con el plan de reversión en espera y una aprobación de seguridad clínica DCB0160. El sistema se acepta, se traspasa al equipo de operaciones que lo operará, se registran lecciones, y el proyecto se cierra formalmente. El equipo se disuelve —correctamente, porque el trabajo genuinamente está terminado. Lo que viene después (mejora continua del servicio en vivo) es un modo de trabajo diferente, y el fideicomiso tiene cuidado de no mantener un equipo de proyecto completo funcionando perpetuamente para hacerlo.

Perspectivas sectoriales#

Startup#

Una pequeña empresa de salud digital raramente ejecuta proyectos PRINCE2 formales, pero el trabajo genuinamente finito todavía aparece —una migración de datos única a una nueva plataforma en la nube, un impulso de certificación Cyber Essentials o DTAC, remediación de pruebas de penetración antes de un gran contrato del NHS. La startup maneja estos como esfuerzos ligeros y con límite de tiempo con un propietario nombrado y una definición clara de terminado, tomando prestada la disciplina (alcance fijo, una fecha final, un ir/no ir) sin la ceremonia (sin junta de proyecto formal, sin puertas de cinco etapas). La financiación es realmente atención del fundador y margen de tiempo, así que el riesgo es que el trabajo finito se comprima entre sprints de producto y nunca realmente se cierre. La corrección es nombrar a un solo propietario y una fecha límite dura, y tratar la certificación o migración como terminada y concluida en lugar de perpetuamente "en progreso".

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, o una clínica de un solo emplazamiento— encuentra el trabajo liderado por proyecto como eventos ocasionales pero ineludibles: cambiar de proveedor de sistema clínico, migrar a una nueva plataforma de gestión de consulta, o reemplazar dispositivos al final de su vida útil antes de que caduque el soporte. La organización tiene pacientes reales y operaciones continuas pero ninguna función dedicada de proyecto o TI, así que el "equipo de proyecto" generalmente es el gerente de la consulta o un gerente registrado haciendo esto junto al trabajo diario, a menudo apoyándose en el proveedor entrante para ejecutar la migración. La disciplina que sobrevive el contacto con esta realidad es el núcleo ligero: un estado final claro, un alcance con línea base para que el proveedor no lo expanda silenciosamente, una persona responsable nombrada, y una reversión probada antes de cualquier transición que toque registros de pacientes. La trampa es subcontratar no solo el trabajo sino el juicio —aceptar la fecha de puesta en marcha del proveedor y las garantías de mapeo de datos sin verificación independiente— porque los mismos deberes de seguridad clínica y gobernanza de la información (DCB0160, una DPIA) se aplican independientemente de cuán pequeña sea la organización. La corrección es mantener la propiedad de la decisión ir/no ir y los criterios de aceptación internamente, incluso cuando cada otro par de manos pertenece al vendedor.

Gran organización#

Un gran fideicomiso del NHS o sistema de atención integrada (ICS) es donde el trabajo liderado por proyecto está más en su elemento: reemplazos de EPR, Wi-Fi a nivel de patrimonio, salidas de centro de datos, y transiciones todos llevan precipicios contractuales y de seguridad del paciente duros. Aquí todo el aparato está justificado —un caso de negocio Five Case, una junta PRINCE2 con un ejecutivo/SRO nombrado, usuario senior y proveedor senior, etapas de gestión con puertas reales, y un registro RAID vivo— porque las sumas son grandes, la exposición de seguridad es aguda, y la auditoría interna y la junta directiva escrutarán el gasto. El fallo característico a esta escala es aplicar la misma gobernanza indiscriminadamente a servicios vivos (Tema 5.0 — Trabajo liderado por producto) y a trabajo finito, así que una vista de cartera (Tema 5.3 — Gestión de cartera y proyectos empresariales) que enruta cada pieza de trabajo al modo correcto importa. La seguridad clínica (DCB0160) y una reversión probada son productos entregables de puerta, no extras opcionales.

Gobierno#

A escala nacional o de grandes proyectos, el trabajo liderado por proyecto se sitúa dentro del régimen de aseguramiento del gobierno: la Infrastructure and Projects Authority ejecuta revisiones de puerta, el Green Book y el Five Case Model del HM Treasury gobiernan el caso de negocio, y los proyectos más grandes entran en el Government Major Projects Portfolio con responsabilidad publicada ante el Parlamento y la National Audit Office. La responsabilidad es intensamente pública —el propietario senior responsable es personalmente responsable y puede ser llamado ante un comité selecto— así que las puertas de etapa y las evaluaciones de opciones son control de grado estatutario, no teatro. La financiación se libera tramo por tramo contra casos de negocio aprobados y el apetito de riesgo es bajo, porque el fracaso se convierte en noticia de primera plana. El valor real de la disciplina aquí es la autoridad para detener o replantear el alcance de un proyecto en fallo antes de que se convierta en una pérdida pública.

Modos de fallo comunes#

• Gestionar como proyecto un servicio en evolución. Aplicar gobernanza de alcance fijo y disolución al final a un producto digital vivo produce la patología de abandono. Corrección: usa trabajo liderado por producto (Tema 5.0) donde el servicio es continuo.
• El caso de negocio como un ticket único para financiación. Escrito una vez para desbloquear dinero, luego nunca revisitado. Corrección: revísalo en cada puerta de etapa; está dispuesto a detenerse.
• Puertas de etapa de aprobación automática. Las puertas que nunca dicen "detente" no proporcionan control. Corrección: haz de detenerse o replanificar una opción genuina de la junta directiva y úsala.
• Aumento de alcance sin control de cambios. Las adiciones no controladas hacen explotar el tiempo y el coste. Corrección: establece la línea base de alcance y enruta cada cambio a través del control de cambios.
• Sin plan de transición al servicio. El proyecto termina y nadie posee el producto entregable. Corrección: acuerda el equipo receptor y el modelo de apoyo antes de la puesta en marcha.
• RAID como archivador. Un registro que se escribe y nunca se actúa. Corrección: revisa RAID regularmente y escala por excepción.
• Nunca realmente cerrar. Proyectos zombis que consumen recursos sin final. Corrección: un cierre deliberado con aceptación, traspaso, y lecciones capturadas.

Modelo de madurez#

Lista de verificación#

• ¿El trabajo es genuinamente finito con un alcance definido y estado final (no un servicio continuo)?
• ¿Hay un caso de negocio vivo (Five Case Model) revisado en cada puerta de etapa?
• ¿El alcance tiene línea base, con un proceso de control de cambios funcional?
• ¿Las etapas de trabajo están definidas, cada una terminando en una puerta de decisión real de detener/proceder?
• ¿Los roles de la junta de proyecto son claros —ejecutivo/SRO, usuario senior, proveedor senior?
• ¿Se mantiene un registro RAID vivo, con escalación por excepción?
• ¿La seguridad clínica (DCB0160), la DPIA, y las pruebas de transición/reversión son productos entregables de puerta?
• ¿Se acuerda el equipo de operaciones receptor y el modelo de apoyo antes de la puesta en marcha?
• ¿Hay un cierre deliberado: aceptación, traspaso, liberación del equipo, lecciones registradas?
• ¿Se ha asignado la mejora continua del servicio en vivo al modo de trabajo correcto?

Fuentes clave#

• AXELOS / PeopleCert — Managing Successful Projects with PRINCE2 (7ª edición) y los principios, temas, y procesos de PRINCE2.
• Project Management Institute (PMI) — A Guide to the Project Management Body of Knowledge (PMBOK Guide) y The Standard for Project Management.
• HM Treasury — Guide to Developing the Project Business Case (el Five Case Model / Green Book).
• Infrastructure and Projects Authority (IPA), Cabinet Office — orientación de aseguramiento y revisión de puerta para grandes proyectos.
• NHS Digital Clinical Safety standard DCB0160 (despliegue de sistemas de TI de salud).
• NHS England — NHS Service Manual y Digital Service Standard (para el contexto de transición de servicio y necesidad de usuario).

Referencias#

1. Project management — Wikipedia — https://en.wikipedia.org/wiki/Project_management
2. PRINCE2 — Wikipedia — https://en.wikipedia.org/wiki/PRINCE2
3. Project management triangle (iron triangle) — Wikipedia — https://en.wikipedia.org/wiki/Project_management_triangle
4. Project Management Institute — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Institute
5. Project Management Body of Knowledge — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge
6. Business case — Wikipedia — https://en.wikipedia.org/wiki/Business_case
7. Phase-gate process (stage gates) — Wikipedia — https://en.wikipedia.org/wiki/Phase-gate_process
8. Scope creep — Wikipedia — https://en.wikipedia.org/wiki/Scope_creep
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
11. HM Treasury — Wikipedia — https://en.wikipedia.org/wiki/HM_Treasury
12. Managing Successful Projects with PRINCE2 (7th edition) — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/PRINCE-2-1005
13. A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Project Management Institute — https://www.pmi.org/
14. The Green Book and Guide to Developing the Project Business Case (Five Case Model) — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
15. Assurance and gateway review guidance for major projects — Infrastructure and Projects Authority, Cabinet Office — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
16. Clinical risk management standard DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety