Tópico 5.2 — Trabalho conduzido por programa

Em uma frase: O trabalho conduzido por programa coordena um conjunto de projetos e produtos relacionados rumo a uma mudança estratégica que nenhum deles conseguiria entregar sozinho, mantendo uma linha de visão clara entre o trabalho e os benefícios que ele pretende realizar.

Por que isso importa na saúde e nos cuidados#

As maiores mudanças na saúde e nos cuidados nunca são um único projeto. Implantar um prontuário de cuidados compartilhado em todo um sistema de cuidados integrados (ICS), levar uma região a um único prontuário eletrônico do paciente, transformar uma via de urgência e emergência ou entregar um programa de enfermarias virtuais em vários hospitais — cada um desses é um pacote coordenado de projetos, equipes de produto, mudança da força de trabalho, obras de infraestrutura e redesenho clínico, alinhados a um único resultado estratégico. Gerenciem as peças isoladamente e elas colidem: padrões de dados incompatíveis, gasto duplicado, fluxos clínicos contraditórios e benefícios que nunca se materializam de fato.

A gestão de programas existe para manter essa coalizão unida e apontada para resultados e benefícios, e não apenas para produtos entregues. Isso importa de forma aguda na saúde e nos cuidados, porque a mudança de todo o sistema toca a segurança do paciente através de fronteiras organizacionais, compromete grandes somas de dinheiro público ao longo de vários anos e depende de muitas organizações autônomas escolherem avançar em compasso. Um programa fornece a liderança, o estado-alvo compartilhado e a disciplina de benefícios para fazer isso acontecer — e, igualmente importante, para saber se está funcionando.

A falha recorrente contra a qual ele protege é o programa que gasta milhões, entrega uma pilha de produtos técnicos e, ainda assim, não muda nada mensurável para pacientes ou equipe. Este tópico usa o Managing Successful Programmes (MSP), o arcabouço dominante do setor público do Reino Unido, e mostra como o trabalho conduzido por programa coexiste com os modos conduzidos por projeto (Tópico 5.1 — Trabalho conduzido por projeto) e por produto (Tópico 5.0 — Trabalho conduzido por produto) que ele coordena. O Tópico 5.3 — Gestão de portfólio corporativo de projetos (EPPM) explica então como uma organização prioriza entre muitos programas.

Conceitos centrais#

Programa. Uma organização temporária e flexível, criada para coordenar, dirigir e supervisionar um grupo de projetos e atividades relacionados, a fim de entregar resultados e benefícios alinhados a objetivos estratégicos. Um programa difere de um projeto por ser definido pelo resultado e pelos benefícios que busca, e por gerir a incerteza de coordenar muitas partes móveis, em vez de entregar um único produto fixo.

MSP (Managing Successful Programmes). O arcabouço de melhores práticas do Reino Unido para gerir mudanças transformacionais por meio de vários projetos relacionados. Organiza-se em torno de princípios, temas e um "fluxo transformacional" de processos, e foi concebido para mudanças grandes e complexas em que o estado final é conhecido em direção, mas o caminho envolve muitas entregas interdependentes.

Visão e projeto-alvo (blueprint). A visão é o quadro convincente do futuro que o programa criará. O blueprint a concretiza: descreve o modelo operacional-alvo — o estado futuro de processos, organização, tecnologia, informação e papéis (muitas vezes resumido como POTI). O blueprint é o ponto de referência para o qual todo projeto é conduzido, de modo que as peças se somem num todo coerente.

Realização de benefícios. O coração da gestão de programas. Os benefícios são as melhorias mensuráveis que justificam o investimento — menos altas atrasadas, menos exames duplicados, diagnóstico mais rápido, menor carga administrativa. O MSP trata identificar, mapear, medir e gerir ativamente os benefícios ao longo de todo o ciclo de vida como disciplina central, porque os produtos entregues só criam valor quando são usados para mudar a forma como o cuidado é prestado.

Tranches. O MSP divide um programa em tranches — blocos de trabalho que terminam num grande ponto de revisão, em que um degrau de capacidade foi entregue e a realização de benefícios pode começar. Uma tranche é um momento para demonstrar resultados, reavaliar o blueprint frente à realidade e decidir se continua, ajusta ou para, e não meramente uma fatia do cronograma.

Conselho do programa e SRO. O Responsável Sênior (SRO — Senior Responsible Owner) é o indivíduo único responsável por o programa atingir seus objetivos e realizar seus benefícios, com senioridade e autoridade suficientes para liderar e tomar decisões. O SRO preside um conselho do programa — tipicamente um gerente de mudança de negócio, líderes de projeto e partes interessadas sêniores — que dá a direção através das fronteiras organizacionais.

Gerente de mudança de negócio (BCM). O papel distintivo do MSP: alguém do negócio operacional (e não da equipe de entrega) responsável por incorporar a mudança e realizar os benefícios no terreno. O BCM é a razão pela qual os programas entregam resultados e não apenas produtos — os projetos transferem a capacidade, o BCM a converte em benefício.

Boas práticas#

1. Ancore o programa numa visão e num blueprint. Definam o resultado estratégico e traduzam-no num modelo operacional-alvo concreto (processos, organização, tecnologia, informação — POTI). Cada projeto e produto constituinte é então conduzido ao mesmo estado futuro, o que impede uma coalizão de entregas de se fragmentar.

2. Gerencie benefícios, e não apenas entregáveis. Construam um mapa de benefícios ligando cada produto entregue aos resultados e benefícios mensuráveis que deve produzir, com responsáveis e linhas de base. Revejam ativamente os benefícios em todo o programa e estejam dispostos a interromper o trabalho que não vai se pagar — a ênfase do MSP na realização de benefícios é a disciplina que separa um programa de uma cara lista de tarefas.

3. Estruture o trabalho em tranches com pontos de revisão reais. Entreguem a capacidade em tranches e, em cada fronteira de tranche, demonstrem os benefícios realizados até então, retestem o blueprint frente ao que foi aprendido e tomem uma decisão genuína de continuar/ajustar/parar. As primeiras tranches devem mirar ganhos rápidos visíveis, para construir a confiança das partes interessadas para as mais difíceis, mais adiante.

4. Nomeie um SRO empoderado e um conselho de programa de verdade. Nomeiem um único SRO com a senioridade e a autoridade para dirigir o programa e decidir através das fronteiras organizacionais e convoquem um conselho que represente genuinamente as organizações afetadas. Os programas falham quando a responsabilização é difusa ou o SRO não consegue fazer as decisões entre fronteiras pegarem.

5. Ponha gerentes de mudança de negócio no negócio operacional. Designem BCMs das organizações da linha de frente para serem donos da adesão e da realização de benefícios onde o cuidado é prestado. Capacidade entregue mas não adotada não realiza benefício algum; o papel do BCM é o mecanismo que fecha essa lacuna.

6. Coordene — não microgerencie — os projetos e produtos constituintes. O programa define o blueprint, as interdependências, os padrões e os benefícios; deixa os projetos e equipes de produto entregarem dentro desse marco. Gerencia as costuras — padrões de dados compartilhados, governança da informação, sequenciamento e infraestrutura compartilhada —, e não o detalhe interno de cada entrega.

7. Gerencie incansavelmente o risco transversal, as dependências e as partes interessadas. O valor que um programa acrescenta a projetos isolados está em boa parte em gerir o que acontece entre eles. Mantenham uma visão em nível de programa das interdependências e dos riscos compartilhados e invistam pesado no engajamento das partes interessadas entre organizações autônomas, já que o alinhamento é voluntário, e não ordenado.

8. Encerre o programa quando a mudança estiver incorporada e passe os serviços contínuos às equipes de produto. Um programa é temporário. Quando o blueprint é atingido e os benefícios estão sendo realizados, encerrem-no deliberadamente, transfiram quaisquer serviços duradouros a equipes de produto duradouras (Tópico 5.0) e continuem acompanhando os benefícios na operação regular (BAU) — muitos benefícios se acumulam depois que o programa termina.

Perguntas para discutir com a sua equipe#

1. O nosso responsável sênior (SRO) tem de fato a autoridade para fazer as decisões pegarem entre organizações parceiras soberanas, ou apenas a responsabilização quando elas não pegam? O trabalho conduzido por programa vive ou morre pela autoridade entre fronteiras, porque a mudança abrange hospitais autônomos, atenção primária, serviços comunitários, saúde mental e cuidados sociais, que não podem simplesmente receber ordem de avançar em compasso. A falha característica é um SRO nomeado que carrega a responsabilização pessoal e pública pelos benefícios, mas carece de posição para obrigar um parceiro relutante a adotar um padrão de dados compartilhado ou a mudar um fluxo clínico — responsabilização sem autoridade. O debate deve ser franco sobre onde reside o poder real no sistema: se o conselho do programa representa genuinamente as organizações afetadas ou é um fórum de relatórios, se o SRO é sênior o bastante para que suas decisões sejam respeitadas através de fronteiras soberanas e o que acontece quando um parceiro se recusa a avançar. Considerem uma decisão recente entre organizações e rastreiem se ela de fato se sustentou. Uma boa resposta nomeia quem é o SRO e testa a autoridade dele frente a um conflito concreto entre fronteiras, é honesta sobre as organizações que podem efetivamente optar por sair e trata um conselho representativo e gerentes de mudança de negócio incorporados como mecanismos de sustentação do alinhamento voluntário, e não como decoração de governança.

2. Como saberemos que este programa realizou benefícios e não meramente entregou produtos — e quem, no negócio operacional, é responsável por converter a capacidade em benefício? O teatro de produtos entregues é a patologia recorrente contra a qual o tópico adverte: um programa gasta milhões, produz uma pilha de plataformas de interoperabilidade e integrações e, ainda assim, nada mensurável muda para pacientes ou equipe. A distinção que a previne é o gerente de mudança de negócio — alguém da operação da linha de frente, e não da equipe de entrega, responsável por incorporar a mudança e realizar o benefício onde o cuidado é prestado —, de modo que a pergunta força a equipe a nomear essas pessoas e confirmar que existem. A tensão é que a entrega é visível e satisfatória, enquanto a adesão é lenta, pouco glamorosa e fácil de supor que simplesmente acontecerá; um prontuário de cuidados compartilhado enterrado atrás de um login extra não realiza benefício algum, por melhor construído que seja. Levem o mapa de benefícios à discussão e testem sob estresse se cada produto entregue está ligado a um benefício com dono, linha de base e mensurável (menos exames duplicados, menos altas atrasadas) ou se os benefícios são apenas afirmados. Uma resposta honesta nomeia um BCM em cada organização parceira, admite onde os benefícios hoje não têm dono ou não são medidos e aceita que alguns benefícios só se acumulam depois que o programa encerra e precisam ser acompanhados na operação regular.

3. Estamos organizando este programa em tranches para garantir benefícios iniciais e criar pontos reais de continuar/ajustar/parar, ou derivando para uma entrega em "big bang" que adia todo o risco para um momento tardio? As tranches é que separam um programa de um caro plano congelado: cada fronteira de tranche deve entregar um degrau de capacidade, demonstrar os benefícios realizados até então, retestar o blueprint frente ao que de fato foi aprendido e apoiar uma decisão genuína de continuar, ajustar ou parar. A tentação na saúde e nos cuidados é sequenciar por conveniência de engenharia e adiar o valor visível — conectar todos os hospitais antes que alguém possa usar qualquer coisa —, o que carrega todo o risco numa única entrega tardia e deixa o conselho sem evidências para defender o investimento continuado através de ciclos fiscais e políticos. O debate deve examinar se as primeiras tranches miram ganhos rápidos deliberados, que construam a confiança das partes interessadas para o trabalho mais difícil adiante, e se os pontos de revisão são decisões reais ou meros marcos de cronograma. Considerem qual é o primeiro benefício demonstrável, quão cedo ele chega e o que o conselho de fato faria numa revisão de tranche se a adesão atrasasse ou o blueprint se revelasse errado. Uma boa resposta descreve tranches concretas, com ganhos iniciais e mensuráveis, trata cada fronteira como um verdadeiro prosseguir/não prosseguir, com o blueprint genuinamente aberto à revisão, e é honesta sobre qualquer pressão para adiar o valor para o fim.

4. Temos um único blueprint mantido do modelo operacional-alvo, ou cada projeto está otimizando em silêncio rumo à sua própria versão do futuro? O blueprint — o modelo operacional-alvo POTI concreto de processos, organização, tecnologia e informação — é o que faz as peças se somarem num todo coerente, e não numa colisão de decisões localmente sensatas. Sem ele, cada projeto constituinte otimiza racionalmente para o próprio escopo: um hospital escolhe um padrão de dados que serve ao seu EPR incumbente, outro desenha um fluxo clínico em torno da própria escala de pessoal, e o prontuário de cuidados compartilhado se fragmenta em integrações que tecnicamente se conectam, mas não fazem sentido em conjunto. A tensão é que manter um blueprint parece custo indireto para equipes de entrega sob pressão para lançar, e ele precisa ser uma referência viva, retestada a cada tranche, e não um documento escrito uma vez e engavetado. O debate deve estabelecer se o blueprint de fato existe de forma utilizável, quem é dono dele e se as decisões reais dos projetos são conduzidas por ele ou meramente reconciliadas com ele depois do fato. Considerem uma escolha de projeto recente num dos projetos e perguntem se o blueprint a moldou ou foi silenciosamente atropelado. Uma resposta honesta consegue apontar um blueprint atual, nomeia seu dono e é franca sobre onde a otimização local já está desfazendo o estado-alvo.

5. Quando o programa encerrar, o que permanece — e nomeamos as equipes de produto duradouras que operarão a capacidade e continuarão acompanhando os benefícios na operação regular? Um programa é temporário por definição, mas o prontuário de cuidados compartilhado, a plataforma de interoperabilidade e os benefícios que produzem não são; assim, o encerramento é um problema de projeto a ser planejado desde o início, e não uma reflexão tardia. A falha recorrente existe nas duas pontas do espectro: alguns programas nunca encerram e se endurecem em burocracias permanentes muito depois de a mudança estar incorporada, enquanto outros encerram abruptamente e deixam um serviço clínico em operação sem dono duradouro. O tópico é explícito de que os serviços duradouros devem ser transferidos a equipes de produto duradouras (Tópico 5.0) e de que muitos benefícios só se acumulam depois que o programa termina e precisam ser acompanhados na BAU — o que significa que as equipes receptoras e a propriedade contínua dos benefícios precisam ser identificadas enquanto o programa ainda tem a autoridade e o financiamento para estabelecê-las. O debate deve trazer à tona quem operará cada capacidade duradoura, como será financiada quando o dinheiro de transformação acabar e quem continua medindo os benefícios quando o conselho do programa se dissolver. Uma boa resposta nomeia as equipes de produto e os donos da BAU específicos, descreve com honestidade a transição de financiamento e trata o encerramento e o acompanhamento de benefícios como tranches planejadas, e não como uma transferência esperançosa.

6. Como estamos gerindo as costuras entre os projetos — padrões compartilhados, governança da informação, sequenciamento e infraestrutura compartilhada — em vez dos detalhes internos de cada entrega? O valor que um programa acrescenta a um conjunto de projetos isolados vive quase inteiramente no espaço entre eles: as interdependências, os padrões de dados compartilhados, o arcabouço de governança da informação e de consentimento e a infraestrutura comum que nenhum projeto isolado possui, mas de que todos dependem. A tentação para uma equipe de programa é derivar para a microgestão dos detalhes internos de cada entrega — trabalho confortável e visível —, enquanto as costuras transversais genuinamente difíceis ficam sem gestão até emergirem como uma falha de integração ou um bloqueio de governança da informação na entrada em produção. Na saúde e nos cuidados, essas costuras têm um peso incomum, porque os fluxos de dados e o consentimento cruzam fronteiras organizacionais e regulatórias soberanas, onde o alinhamento é voluntário e os deveres legais são compartilhados, mas dotados de recursos de forma desigual. O debate deve testar se há uma visão em nível de programa das interdependências e dos riscos compartilhados, quem é dono dos padrões e da infraestrutura compartilhados e se o programa está coordenando as costuras ou se intrometendo nos detalhes dos projetos. Uma resposta honesta identifica as costuras específicas que mais ameaçam o resultado, nomeia seus donos e é franca sobre se o programa está agregando valor nas fronteiras ou duplicando o trabalho dos projetos que deveria viabilizar.

Na prática: um exemplo de saúde e cuidados#

Um ICS se propõe a entregar um prontuário de cuidados compartilhado que dê aos clínicos da atenção aguda, comunitária, de saúde mental, primária e de cuidados sociais uma visão unificada de uma pessoa. Nenhum projeto isolado consegue entregar isso: abrange vários hospitais, vários sistemas de origem, acordos de governança da informação, redesenho de fluxos clínicos e engajamento público. É coordenado como um programa MSP.

O SRO — um executivo do ICS com genuína autoridade entre sistemas — preside um conselho de programa com representantes de cada organização parceira e gerentes de mudança de negócio nomeados em cada uma. O programa define uma visão ("a informação certa, sobre a pessoa certa, disponível ao clínico certo, no ponto de cuidado") e um blueprint que descreve o modelo operacional-alvo: a arquitetura e os padrões de compartilhamento de dados (interoperabilidade baseada em HL7 FHIR), o arcabouço de governança da informação, o modelo de consentimento e os fluxos clínicos redesenhados.

O trabalho é organizado em tranches. A primeira tranche conecta dois hospitais de agudos dispostos e entrega um prontuário somente de leitura, um ganho rápido deliberado que prova a abordagem e permite ao conselho demonstrar um benefício inicial — uma redução mensurável de exames duplicados — para construir confiança. Na revisão da primeira tranche, o conselho aprende que a adesão dos clínicos é baixa onde o prontuário está enterrado atrás de um login extra; então ajusta o blueprint para priorizar a integração de login único antes de ampliar a implantação.

Sob o programa, os modos coexistem. A plataforma de interoperabilidade é operada por uma equipe de produto duradoura (Tópico 5.0) que continua melhorando-a ao longo de todo o programa e além. A conexão de cada hospital é um projeto delimitado (Tópico 5.1), com seu próprio caso de negócio e entrada em produção. O programa em si coordena o blueprint, os padrões, as interdependências e — por meio dos BCMs — a realização de benefícios. Quando o blueprint é atingido e os benefícios de menos exames duplicados e menos altas atrasadas estão fluindo, o programa encerra; a equipe de produto da plataforma permanece, e o acompanhamento de benefícios continua na operação regular.

Perspectivas setoriais#

Startup#

Poucas startups conduzem programas no sentido do MSP — carecem do escopo multiorganizacional que define um —, mas uma empresa em escala que implanta em vários hospitais torna-se, na prática, participante de um programa. Seu papel realista é o de fornecedor dentro do programa de outra pessoa: alinhar o produto ao blueprint do programa, cumprir os marcos das tranches e alimentar o caso de benefícios que o SRO precisa evidenciar. O financiamento e a sobrevivência dependem de o programa continuar; assim, a startup trata as revisões de tranche como pontos existenciais de prosseguir/não prosseguir e investe no sucesso dos gerentes de mudança de negócio, porque é a adesão no terreno que renova seu contrato. A disciplina que precisa tomar de empréstimo é a linguagem de benefícios — enquadrar seu valor como resultados realizados, e não como funcionalidades lançadas.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou um pequeno fornecedor de tecnologia em saúde que já passou da fase de startup — quase nunca conduz um programa, mas é rotineiramente arrastado para um como participante afetado quando um ICS implanta um prontuário de cuidados compartilhado ou converge sistemas em todo o território. Sua preocupação prática é a costura de que o programa é dono: precisa adotar os padrões de dados obrigatórios, os acordos de governança da informação e o modelo de consentimento com pouca ou nenhuma capacidade dedicada de TI e sem folga para absorver mudanças de fluxo de trabalho, mas carrega os mesmos deveres legais dos grandes hospitais ao redor. A relação mais valiosa que tem é com o gerente de mudança de negócio da sua localidade, porque uma adesão bem apoiada — treinamento, login único, um fluxo que se ajusta ao modo como o consultório de fato funciona — é a diferença entre o benefício do programa chegar e a mudança ser contornada em silêncio. Seu pedido realista ao programa é apoio proporcional e um sequenciamento que não pressuponha recursos em escala corporativa, e sua contribuição honesta é um retorno precoce e franco, nas revisões de tranche, sobre o que é inviável no terreno.

Grande organização#

Um ICS ou grande hospital é o lar natural do trabalho conduzido por programa: prontuários de cuidados compartilhados, convergência de EPRs e transformação de vias são inerentemente multiorganizacionais e plurianuais. A parte difícil é a autoridade — o SRO precisa fazer as decisões pegarem entre organizações parceiras soberanas, que não podem simplesmente receber ordens; assim, um conselho de programa genuinamente representativo e gerentes de mudança de negócio incorporados em cada parceiro são elementos de sustentação, e não decorativos. O financiamento é misto (dinheiro de transformação do sistema, capital do hospital, alocações nacionais), o que torna o mapa de benefícios e as revisões de tranche essenciais para defender o investimento continuado perante líderes do sistema e reguladores. O risco recorrente nessa escala é o teatro de produtos entregues: entrega técnica sem ninguém responsável por convertê-la em benefício.

Governo#

Em escala nacional, os programas carregam a governança mais pesada — tipicamente entram no Government Major Projects Portfolio, passam por garantia da Infrastructure and Projects Authority e por revisões de gateway e respondem a ministros, ao Public Accounts Committee e ao National Audit Office. O SRO é pessoal e publicamente responsável pela realização de benefícios em todo o sistema, e os blueprints precisam reconciliar padrões nacionais (interoperabilidade, governança da informação, o NHS App como porta de entrada comum) com a autonomia local. O financiamento corre por acordos plurianuais de revisão de gastos (Spending Review); as tranches e as evidências de benefícios são, portanto, o mecanismo para sustentar ou interromper o investimento ao longo de ciclos fiscais e políticos. O que está em jogo é de escala populacional: os benefícios de um programa nacional — ou seu fracasso — se medem em milhões de pacientes e bilhões de libras.

Modos de falha comuns#

• Teatro de produtos entregues. O programa entrega produtos técnicos, mas ninguém é dono de convertê-los em benefícios, de modo que nada muda para os pacientes. Correção: mapas de benefícios com responsáveis e BCMs no negócio operacional.
• Um programa que é só um grande projeto. Governança de escopo fixo e focada em produtos entregues aplicada a uma mudança genuinamente incerta e multiorganizacional. Correção: gerenciem por resultados/benefícios e tranches, e não por um único plano congelado.
• Um SRO sem poder. Responsabilização sem autoridade para decidir entre fronteiras. Correção: nomeiem um SRO sênior o bastante para fazer as decisões entre sistemas pegarem, respaldado por um conselho representativo.
• Sem blueprint / estado-alvo. Os projetos otimizam localmente e as peças nunca fazem sentido em conjunto. Correção: definam e mantenham um blueprint POTI para o qual tudo seja conduzido.
• Big bang em vez de tranches. Todo o risco adiado para uma única entrega tardia. Correção: dividam o trabalho em tranches, garantam benefícios iniciais e replanejem nos pontos de revisão.
• Programa que nunca encerra. Torna-se uma burocracia permanente muito depois de a mudança estar incorporada. Correção: encerrem deliberadamente, passem os serviços duradouros às equipes de produto e continuem acompanhando os benefícios na BAU.

Modelo de maturidade#

Lista de verificação#

• Esta é genuinamente uma mudança multiprojeto e multiorganizacional rumo a um único resultado estratégico?
• Há uma visão clara e um blueprint concreto (modelo operacional-alvo / POTI)?
• Há um mapa de benefícios ligando os produtos entregues a benefícios mensuráveis, com dono e linha de base?
• O trabalho está estruturado em tranches com pontos reais de revisão de continuar/ajustar/parar?
• Há um SRO empoderado, com autoridade para decidir entre fronteiras organizacionais?
• O conselho do programa representa genuinamente as organizações afetadas?
• Há gerentes de mudança de negócio incorporados ao negócio operacional para serem donos da adesão?
• Os padrões transversais, as interdependências e os riscos compartilhados são geridos em nível de programa?
• Os modos conduzidos por produto, por projeto e por programa coexistem com papéis claros (Tópicos 5.0–10)?
• Há um encerramento deliberado, com os serviços duradouros passados a equipes de produto duradouras e os benefícios acompanhados na BAU?

Fontes-chave#

• AXELOS / PeopleCert — Managing Successful Programmes (MSP): princípios, temas e o fluxo transformacional (incluindo blueprint, tranches, gestão de benefícios e os papéis de SRO/BCM).
• Cabinet Office / Infrastructure and Projects Authority (IPA) — orientações sobre grandes programas, responsabilização do SRO e garantia/revisões de gateway.
• HM Treasury — The Green Book e orientações de gestão de benefícios (avaliação e apreciação de benefícios).
• AXELOS — Management of Portfolios (MoP), para posicionar programas dentro de um portfólio (ver Tópico 5.3 — EPPM).
• NHS England — orientações sobre sistemas de cuidados integrados e prontuários de cuidados compartilhados (interoperabilidade, padrões HL7 FHIR) para o contexto do domínio.
• Mik Kersten — Project to Product, para a mudança de investimento baseado em produtos entregues para investimento baseado em resultados/benefícios.

Referências#

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/