Tópico 5.1 — Trabalho conduzido por projeto

Em uma frase: O trabalho conduzido por projeto é a ferramenta certa quando o trabalho tem escopo definido, vida finita e um estado final claro — um empreendimento temporário e controlado, entregue conforme tempo, custo e qualidade acordados e depois encerrado.

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

Nem tudo é um serviço vivo. Parte do trabalho mais importante na saúde e nos cuidados é genuinamente finita: migrar de um prontuário eletrônico do paciente para outro, implantar Wi-Fi em todo o parque de um hospital, substituir servidores em fim de vida, desativar um sistema legado antes que o contrato do fornecedor termine ou entregar o elemento digital de um novo hospital. Esse trabalho tem começo, meio e um fim definido. Geri-lo como um produto sem fim desperdiçaria dinheiro e turvaria a responsabilização; ele precisa da disciplina de um projeto.

A gestão de projetos merece seu lugar aqui justamente porque o que está em jogo é alto e as restrições são rígidas. A virada de uma migração de dados tem um fim de semana fixo de entrada em produção, um risco à segurança do paciente se registros forem perdidos ou corrompidos e um precipício contratual se o sistema antigo for desligado. O dinheiro público é comprometido frente a um caso de negócio, e o Parlamento, os auditores e os conselhos perguntarão se foi gasto conforme aprovado. O trabalho conduzido por projeto oferece a governança — um caso de negócio, portões de etapa e um encerramento controlado — que permite a um conselho comprometer capital com confiança e interromper o trabalho de forma limpa se a justificativa desaparecer.

O perigo é usar essa ferramenta para o trabalho errado. A governança de projeto aplicada a um serviço digital em evolução produz a patologia de "construir e abandonar" descrita no Tópico 5.0 — Trabalho conduzido por produto. Este tópico explica onde o trabalho conduzido por projeto é o instrumento certo e onde começam os seus limites. Ele se situa ao lado do Tópico 5.2 — Trabalho conduzido por programa, que coordena vários projetos, e do Tópico 5.3 — Gestão de portfólio corporativo de projetos (EPPM), que escolhe entre essas ferramentas.

Conceitos centrais#

Projeto. Uma organização temporária criada para entregar um ou mais produtos definidos conforme uma especificação acordada, dentro de restrições de tempo, custo e qualidade. A característica definidora é ser temporário — existe para alcançar um fim definido e depois se dissolver.

O triângulo de ferro (escopo, tempo, custo). O modelo clássico de restrições: escopo, cronograma e orçamento são interdependentes, e a qualidade é afetada pela forma como são equilibrados. Mude um e você muda os outros; o controle de projetos é em boa parte a disciplina de gerir esse equilíbrio de forma transparente.

PRINCE2 (PRojects IN Controlled Environments). O método estruturado de projetos do governo do Reino Unido, amplamente usado no NHS e no setor público. É construído sobre princípios (justificativa de negócio contínua, papéis definidos, gerir por etapas, gerir por exceção, foco em produtos, aprender com a experiência, adaptar ao ambiente) e organiza o trabalho em etapas controladas, com um conselho de projeto que dá a direção.

PMI / PMBOK. O Guide to the Project Management Body of Knowledge do Project Management Institute é a contrapartida internacional dominante, enquadrando o trabalho de projeto em torno de domínios de desempenho e princípios, e não de um processo em etapas prescrito. O PRINCE2 e o PMBOK são lentes complementares sobre a mesma disciplina.

Caso de negócio. O documento que justifica o projeto: o problema, as opções avaliadas, os benefícios esperados, os custos e os riscos. No PRINCE2, o caso de negócio é vivo — é verificado em cada fronteira de etapa e, se a justificativa contínua desaparece, a decisão certa é parar. Nos órgãos públicos do Reino Unido, costuma ser estruturado como o Five Case Model (estratégico, econômico, comercial, financeiro, gerencial) do HM Treasury.

Portões de etapa. Um projeto PRINCE2 é dividido em etapas gerenciais separadas por portões de decisão. Em cada fronteira, o conselho do projeto toma uma decisão deliberada de parar ou prosseguir: revê o progresso e o caso de negócio, aprova o plano da próxima etapa e compromete recursos apenas para aquela etapa. É assim que um conselho mantém o controle e evita jogar dinheiro bom atrás do ruim.

Registro RAID. Um registro único de Riscos, Premissas (Assumptions), Problemas (Issues) e Dependências — o principal artefato de controle do gerente de projeto. O RAID torna a incerteza visível e gerenciável: riscos são coisas que podem acontecer, problemas são coisas que já aconteceram, premissas são aquilo em que o plano se apoia e dependências são aquilo de que o plano precisa de outro lugar.

Boas práticas#

1. Comece com um caso de negócio honesto e mantenha-o vivo. Usem uma estrutura reconhecida (o Five Case Model nos órgãos públicos do Reino Unido) para avaliar opções reais, e não uma única resposta predeterminada. Depois tratem o caso de negócio como documento vivo, revisto em cada portão de etapa — a justificativa de negócio contínua é o primeiro princípio do PRINCE2, e perdê-la é um motivo legítimo para parar.

2. Defina o escopo com precisão e controle as mudanças nele. O valor de um projeto é uma definição clara e delimitada de "pronto". Acordem o escopo, fixem sua linha de base e passem toda mudança proposta por um processo de controle de mudanças, para que o aumento descontrolado de escopo não consuma em silêncio o orçamento e o cronograma.

3. Gerencie por etapas, com portões de decisão reais. Dividam o trabalho em etapas gerenciais e realizem uma revisão genuína de parar/prosseguir em cada fronteira. Um portão que sempre diz "prossiga" é teatro; a disciplina só funciona se parar ou replanejar for uma opção real que o conselho exercerá.

4. Mantenha um registro RAID vivo e escale por exceção. Mantenham Riscos, Premissas, Problemas e Dependências num só lugar, revisem-no regularmente e usem o "gerir por exceção" do PRINCE2 — o gerente de projeto atua dentro de tolerâncias acordadas e escala ao conselho apenas quando uma tolerância é ameaçada. Isso mantém o tempo sênior concentrado em decisões genuínas.

5. Atribua responsabilização clara e de ponto único. O PRINCE2 insiste em papéis definidos: um conselho de projeto com um responsável sênior/executivo dono do caso de negócio, um usuário sênior que representa quem usará o produto e um fornecedor sênior. A responsabilização ambígua é a causa mais comum de deriva.

6. Planeje a transição para o serviço em produção antes de começar. Um projeto entrega um produto; alguém precisa operá-lo depois. Acordem a equipe receptora, o modelo de suporte e a transferência de segurança clínica (DCB0160 para implantação) como parte do projeto, para que a entrada em produção não seja um precipício rumo a um vácuo de propriedade.

7. Incorpore segurança clínica, governança da informação e testes. Para qualquer sistema que toque dados de pacientes, o caso de segurança clínica, o DPIA e os testes de virada/reversão não são extras opcionais — são entregáveis condicionantes. Uma migração sem um plano de reversão testado não está pronta para entrar em produção.

8. Encerre o projeto deliberadamente e registre as lições. Um fim definido significa um encerramento definido: confirmem que os produtos foram aceitos, transfiram para as operações, liberem a equipe e registrem as lições aprendidas (o registro de lições do PRINCE2). Um projeto não encerrado vaza recursos e responsabilização indefinidamente.

Perguntas para discutir com a sua equipe#

1. O trabalho que temos diante de nós é genuinamente finito, com um estado final definido, ou estamos recorrendo à governança de projeto porque é a via de financiamento que conhecemos? Esta é a pergunta decisiva em que o tópico gira, porque a disciplina conduzida por projeto só é o instrumento certo quando o trabalho de fato tem começo, meio e um fim definido. Numa organização de saúde e cuidados, a atração pela forma de projeto é forte — o orçamento de capital, a máquina de casos de negócio e os relatórios ao conselho são todos construídos para ela —, de modo que um serviço digital em evolução pode ser vestido de projeto simplesmente porque é assim que o dinheiro é liberado, o que então produz a patologia de construir e abandonar. O debate deve examinar cada candidato com honestidade: a substituição de um sistema de patologia antes de o fornecedor retirar o suporte tem um precipício contratual rígido e é inequivocamente finita, ao passo que "melhorar o aplicativo do paciente" não tem estado final e pertence ao Tópico 5.0. Considerem se há uma entrada em produção real, depois da qual a equipe deve se dissolver, ou se alguém precisará continuar melhorando a coisa indefinidamente. Uma boa resposta resiste a usar a governança de projeto por hábito, nomeia o estado final concreto e o evento que define "pronto" e se dispõe a dizer que parte do que hoje operamos como projeto nunca deveria ter sido projeto.

2. Nos nossos portões de etapa, este conselho realmente pararia ou replanejaria um projeto que perdeu a justificativa — e conseguimos apontar uma vez em que o fizemos? Os portões de etapa só são um controle se parar for uma opção genuína que o conselho exercerá; um portão que sempre diz "prossiga" é teatro, e a justificativa de negócio contínua é o primeiro princípio do PRINCE2 precisamente porque perdê-la deve encerrar o trabalho. A tensão na saúde e nos cuidados é aguda: interromper uma migração de EPR pela metade ou a virada de um sistema laboratorial parece admitir fracasso, desperdiçar custo afundado e perturbar clínicos que já mudaram seus planos; assim, os conselhos racionalizam seguir em frente mesmo quando o caso de negócio evapora em silêncio. Tragam ao debate um exemplo real — um projeto em que os testes revelaram que o risco de mapeamento de dados era pior do que se supunha, ou em que os benefícios escorregaram — e perguntem se o portão foi usado como projetado ou carimbado. Considerem que tolerâncias disparam a escalação, quem no conselho tem autoridade para determinar uma parada e se o raciocínio do custo afundado é nomeado e questionado na sala. Uma resposta honesta admite onde os portões foram formalidades, descreve as condições em que o conselho de fato interromperia ou redefiniria o escopo e trata a autoridade de parar antes de uma baixa contábil pública como o valor real da disciplina, e não como uma ameaça.

3. Quem recebe o produto de cada projeto como serviço em produção, e como tornamos a transferência de segurança clínica e a propriedade contínua um entregável condicionante e não um precipício? Um projeto entrega um produto; algo finito termina, mas o que ele produziu precisa ser operado, melhorado e mantido seguro muito depois de a equipe se dissolver — e a falha silenciosa mais comum é que ninguém seja dono dele do outro lado. Num sistema que toca dados de pacientes, isso não é arrumação administrativa: o caso de segurança de implantação da DCB0160, o DPIA, uma reversão testada e uma equipe receptora nomeada é que ficam entre uma entrada em produção controlada e um vácuo de propriedade em que os riscos de segurança se acumulam sem gestão. O debate deve forçar clareza sobre a transição antes de o projeto começar, e não no fim de semana da entrada em produção: que equipe operacional o assume, qual é o modelo de suporte e se essa equipe tem capacidade e modo de trabalho (conduzido por produto, conforme o Tópico 5.0) para continuar melhorando-o. Considerem entradas em produção recentes e concretas e se a transferência foi planejada ou improvisada e se "o projeto acabou" foi autorizado a significar "e agora não é trabalho de ninguém". Uma boa resposta nomeia de antemão a equipe receptora e o modelo de suporte, trata a transferência de segurança como um portão que o projeto não pode ultrapassar sem ela e atribui explicitamente a melhoria contínua do serviço em produção ao modo de trabalho certo, em vez de deixá-la à deriva.

4. Quando o triângulo de ferro aperta e escopo, tempo e custo colidem, qual restrição flexibilizamos, e a segurança do paciente alguma vez pode ser a variável que cede? Todo projeto real chega, mais cedo ou mais tarde, ao momento em que cronograma, orçamento e escopo prometido não podem se manter todos juntos, e a forma como a equipe resolve esse aperto revela o que ela de fato valoriza. Na saúde e nos cuidados, a armadilha é distintiva: como a data final é muitas vezes um precipício contratual rígido — um fornecedor retirando o suporte, um arrendamento vencendo, um data center fechando —, o tempo frequentemente não pode se mover, de modo que a pressão cai em silêncio sobre a qualidade, o que, num sistema clínico, significa cortar testes, comprimir a validação ou entrar em produção com defeitos conhecidos de mapeamento de dados. A discussão deve nomear, de antemão, qual canto do triângulo a organização protegerá e qual sacrificará, e ser explícita de que a segurança clínica e a governança da informação não são a válvula de escape, mesmo quando todo o resto está fixo. Olhem uma virada recente e perguntem o que cedeu em silêncio quando as datas se mantiveram: foi o ensaio da reversão, a janela de validação clínica, o treinamento? Considerem quem tem autoridade para mover a data de entrada em produção em vez de corroer a margem de segurança e se essa conversa acontece abertamente no conselho ou por omissão no chão de fábrica. Uma resposta honesta declara a ordem de prioridade antes do aperto, trata uma data adiada ou uma etapa replanejada como resultado legítimo e se recusa a deixar a pressão não dita do cronograma converter-se em risco clínico não registrado.

5. O nosso registro RAID é um instrumento vivo que muda o que fazemos, ou um documento que mantemos para parecer governados — e traria à tona o risco que de fato afunda o projeto? Um registro RAID só merece seu lugar se revisá-lo muda decisões; a patologia comum é um registro escrito na largada, apresentado a conselhos e nunca realmente acionado enquanto os riscos que importam amadurecem sem vigilância. Numa migração ou virada, os riscos decisivos costumam ser específicos e cognoscíveis — resultados históricos que não se mapearão limpos às novas faixas de referência, uma dependência de mudanças de firewall de outra equipe, uma premissa de que o recurso de validação clínica estará livre quando for necessário — e a pergunta é se o registro os nomeia concretamente ou se esconde atrás de entradas genéricas como "restrições de recursos". O debate deve testar se a escalação por exceção é real: o gerente de projeto atua dentro de tolerâncias acordadas e só chama a atenção do conselho quando uma é ameaçada, ou tudo ou fica em silêncio ou vira crise? Considerem se os quase-acidentes e os problemas materializados realimentam o planejamento da próxima etapa ou apenas são registrados e esquecidos. Uma boa resposta consegue apontar uma decisão que o registro RAID de fato mudou, distingue os dois ou três riscos que poderiam genuinamente parar o projeto da longa cauda dos menores e trata o registro como um controle de trabalho, e não como um artefato produzido para a garantia.

6. Depois que encerramos e dissolvemos a equipe, alguém verifica se os benefícios do caso de negócio de fato se materializaram — e saberíamos se não se materializaram? O caso de negócio promete benefícios para justificar o gasto, mas o trabalho conduzido por projeto naturalmente termina na entrada em produção e na liberação da equipe; assim, o momento da verdade — a migração de fato reduziu o risco, cortou o custo ou melhorou o cuidado — costuma cair depois que todos seguiram em frente e ninguém é responsável por confirmá-lo. Isso importa de forma aguda na saúde e nos cuidados públicos, onde o dinheiro é comprometido frente a um caso de negócio Five Case que o Parlamento, os auditores e os conselhos foram informados que entregaria resultados específicos, mas a realização de benefícios é a etapa mais frequentemente pulada porque o projeto que seria seu dono já não existe. A discussão deve decidir quem herda o acompanhamento de benefícios quando o projeto encerra, por qual período e frente a quais medições de linha de base — que precisam ser captadas antes da entrada em produção, ou se perdem. Considerem um projeto recente já concluído e perguntem com franqueza se alguém verificou depois seus benefícios prometidos e se um déficit algum dia chegaria ao conselho que o aprovou. Uma resposta honesta atribui a propriedade dos benefícios pós-encerramento a uma função permanente, e não à equipe dissolvida, capta a linha de base enquanto o projeto ainda está vivo e se dispõe a registrar que um projeto entregou o produto no prazo e dentro do orçamento, mas não entregou o valor que o justificou.

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

Um hospital de agudos precisa substituir o seu envelhecido sistema de gestão de informação laboratorial de patologia antes que o fornecedor atual retire o suporte, em 14 meses. Este é trabalho conduzido por projeto de manual: data final fixa, escopo definido, um precipício contratual rígido e agudo risco à segurança do paciente se resultados forem perdidos na migração.

O hospital escreve um caso de negócio Five Case avaliando três opções (atualizar no lugar, adquirir um novo sistema, compartilhar uma instância regional), seleciona a aquisição e monta um projeto PRINCE2 com um conselho claro: um executivo dono do caso de negócio, um usuário sênior (o cientista biomédico-chefe) e o fornecedor sênior. O trabalho é dividido em etapas gerenciais — aquisição, construção e configuração, migração de dados, testes e entrada em produção —, cada uma terminando num portão de decisão.

O gerente de projeto mantém um registro RAID. Um risco-chave é que os resultados históricos podem não se mapear limpos às faixas de referência do novo sistema; uma dependência são as mudanças de firewall da equipe de rede; uma premissa é que haverá recurso de validação clínica disponível para os testes. No portão da etapa de migração, os testes revelam que o risco de mapeamento de dados é pior do que se supunha; o conselho então usa o portão como projetado: não prossegue às cegas, mas aprova uma etapa replanejada, com uma janela de validação estendida e um plano de reversão testado, protegendo a segurança do paciente acima do cronograma original.

A entrada em produção ocorre num fim de semana controlado, com o plano de reversão de prontidão e a aprovação de segurança clínica da DCB0160. O sistema é aceito, transferido à equipe de operações que o executará, as lições são registradas e o projeto é formalmente encerrado. A equipe se dissolve — corretamente, porque o trabalho está de fato concluído. O que vem a seguir (a melhoria contínua do serviço em produção) é um modo de trabalho diferente, e o hospital tem o cuidado de não manter uma equipe de projeto completa funcionando perpetuamente para fazê-lo.

Perspectivas setoriais#

Startup#

Uma pequena empresa de saúde digital raramente conduz projetos PRINCE2 formais, mas o trabalho genuinamente finito ainda aparece — uma migração pontual de dados para uma nova plataforma de nuvem, um esforço de certificação Cyber Essentials ou DTAC, a remediação de testes de intrusão antes de um grande contrato do NHS. A startup trata isso como esforços leves e com prazo definido, com um responsável nomeado e uma definição clara de pronto, tomando de empréstimo a disciplina (escopo fixo, uma data final, um prosseguir/não prosseguir) sem a cerimônia (sem conselho de projeto formal, sem portões em cinco etapas). O financiamento é, na verdade, atenção dos fundadores e pista de caixa; o risco é, portanto, que o trabalho finito seja espremido entre os sprints de produto e nunca seja de fato encerrado. A correção é nomear um único responsável e um prazo firme e tratar a certificação ou a migração como coisa resolvida e acabada, e não perpetuamente "em andamento".

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou uma clínica de unidade única — encontra o trabalho conduzido por projeto como eventos ocasionais, mas inevitáveis: trocar de fornecedor de sistema clínico, migrar para uma nova plataforma de gestão do consultório ou substituir dispositivos em fim de vida antes que o suporte expire. A organização tem pacientes reais e operações contínuas, mas nenhuma função dedicada de projetos ou de TI; assim, a "equipe de projeto" costuma ser o gerente do consultório ou um gerente registrado fazendo isso além do trabalho diário, muitas vezes apoiando-se no fornecedor entrante para conduzir a migração. A disciplina que sobrevive ao contato com essa realidade é o núcleo leve: um estado final claro, um escopo com linha de base para que o fornecedor não o amplie em silêncio, uma pessoa responsável nomeada e uma reversão testada antes de qualquer virada que toque prontuários de pacientes. A armadilha é terceirizar não só o trabalho, mas o julgamento — aceitar a data de entrada em produção e as garantias de mapeamento de dados do fornecedor sem verificação independente —, porque os mesmos deveres de segurança clínica e de governança da informação (DCB0160, um DPIA) se aplicam seja qual for o tamanho da organização. A correção é manter internamente a propriedade da decisão de prosseguir/não prosseguir e dos critérios de aceitação, mesmo quando todos os outros pares de mãos pertencem ao fornecedor.

Grande organização#

Um grande hospital do NHS ou sistema de cuidados integrados (ICS) é onde o trabalho conduzido por projeto está mais em casa: substituições de EPR, Wi-Fi em todo o parque, saídas de data center e viradas carregam, todos, precipícios contratuais e de segurança do paciente rígidos. Aqui o aparato completo se justifica — um caso de negócio Five Case, um conselho PRINCE2 com um executivo/SRO nomeado, usuário sênior e fornecedor sênior, etapas gerenciais com portões reais e um registro RAID vivo —, porque as somas são grandes, a exposição de segurança é aguda e a auditoria interna e o conselho escrutinarão o gasto. A falha característica nessa escala é aplicar a mesma governança indiscriminadamente a serviços vivos (Tópico 5.0 — Trabalho conduzido por produto) e a trabalho finito, de modo que uma visão de portfólio (Tópico 5.3 — Gestão de portfólio corporativo de projetos) que encaminhe cada trabalho ao modo certo importa. A segurança clínica (DCB0160) e uma reversão testada são entregáveis condicionantes, e não extras opcionais.

Governo#

Em escala nacional ou de grandes projetos, o trabalho conduzido por projeto fica dentro do regime de garantia do governo: a Infrastructure and Projects Authority conduz as revisões de gateway, o Green Book do HM Treasury e o Five Case Model regem o caso de negócio e os maiores projetos entram no Government Major Projects Portfolio, com responsabilização publicada perante o Parlamento e o National Audit Office. A responsabilização é intensamente pública — o responsável sênior (SRO) responde pessoalmente e pode ser convocado perante uma comissão parlamentar —, de modo que os portões de etapa e as avaliações de opções são controles de grau estatutário, e não teatro. O financiamento é liberado em parcelas, frente a casos de negócio aprovados, e o apetite de risco é baixo, porque o fracasso vira manchete. O valor real da disciplina aqui é a autoridade de parar ou redefinir o escopo de um projeto em fracasso antes que se torne uma baixa contábil pública.

Modos de falha comuns#

• Gerir como projeto um serviço em evolução. Aplicar a um produto digital vivo uma governança de escopo fixo e dissolução ao final produz a patologia do abandono. Correção: usem o trabalho conduzido por produto (Tópico 5.0) onde o serviço é contínuo.
• O caso de negócio como bilhete único de financiamento. Escrito uma vez para liberar dinheiro e nunca mais revisitado. Correção: revisem-no em cada portão de etapa; estejam dispostos a parar.
• Portões de etapa carimbados. Portões que nunca dizem "pare" não oferecem controle. Correção: tornem parar ou replanejar uma opção genuína do conselho e usem-na.
• Aumento de escopo sem controle de mudanças. Acréscimos não controlados estouram tempo e custo. Correção: fixem a linha de base do escopo e passem toda mudança pelo controle de mudanças.
• Sem plano de transição para o serviço. O projeto termina e ninguém é dono do produto. Correção: acordem a equipe receptora e o modelo de suporte antes da entrada em produção.
• RAID como arquivo morto. Um registro escrito e nunca acionado. Correção: revisem o RAID regularmente e escalem por exceção.
• Nunca de fato encerrar. Projetos zumbis que consomem recursos sem fim. Correção: um encerramento deliberado, com aceitação, transferência e lições registradas.

Modelo de maturidade#

Lista de verificação#

• O trabalho é genuinamente finito, com escopo definido e estado final (e não um serviço contínuo)?
• Há um caso de negócio vivo (Five Case Model) revisto em cada portão de etapa?
• O escopo tem linha de base, com um processo de controle de mudanças que funciona?
• As etapas de trabalho estão definidas, cada uma terminando num portão real de decisão de parar/prosseguir?
• Os papéis do conselho do projeto estão claros — executivo/SRO, usuário sênior, fornecedor sênior?
• Mantém-se um registro RAID vivo, com escalação por exceção?
• A segurança clínica (DCB0160), o DPIA e os testes de virada/reversão são entregáveis condicionantes?
• A equipe de operações receptora e o modelo de suporte estão acordados antes da entrada em produção?
• Há um encerramento deliberado: aceitação, transferência, liberação da equipe, lições registradas?
• A melhoria contínua do serviço em produção foi atribuída ao modo de trabalho certo?

Fontes-chave#

• AXELOS / PeopleCert — Managing Successful Projects with PRINCE2 (7ª edição) e os princípios, temas e processos do PRINCE2.
• Project Management Institute (PMI) — A Guide to the Project Management Body of Knowledge (PMBOK Guide) e The Standard for Project Management.
• HM Treasury — Guide to Developing the Project Business Case (o Five Case Model / Green Book).
• Infrastructure and Projects Authority (IPA), Cabinet Office — orientações de garantia e de revisão de gateway para grandes projetos.
• NHS Digital — padrão de segurança clínica DCB0160 (implantação de sistemas de TI em saúde).
• NHS England — NHS Service Manual e Digital Service Standard (para o contexto de transição de serviço e de necessidade do usuário).

Referências#

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