Gerenciamento de programas e PgMP
Componentes do programa: quando incluir ou encerrar um projeto
Decidir quais componentes do programa entram, quais saem e quando é uma das tarefas que mais separam a gestão de programas da gestão de projetos. Um gerente de projetos recebe o escopo pronto. Um gerente de programas precisa, ao longo de anos, avaliar pedidos de inclusão, perceber quando um projeto deixou de contribuir e conduzir a saída sem deixar entregas, contratos e riscos soltos.
O erro mais comum vai nos dois sentidos. Programas que aceitam qualquer projeto que precise de orçamento viram uma carteira sem foco. Programas que nunca encerram componentes carregam custo de projetos que já não servem ao benefício. Os critérios abaixo ajudam a decidir nos dois casos.
Formação relacionada
Preparatório para a certificação PgMP
Elegibilidade junto ao PMI, padrão de gerenciamento de programas e mais de 500 questões comentadas em vídeo.
O que são componentes do programa
Na quarta edição do The Standard for Program Management, o Project Management Institute (PMI) descreve os componentes de um programa como projetos, programas subsidiários e outras atividades relacionadas ao programa, necessárias para alcançar as metas e os objetivos. Na prática, isso inclui:
- Projetos, com entrega definida e ciclo de vida próprio, preditivo, ágil ou híbrido.
- Programas subsidiários, quando uma parte do programa é grande e interdependente o bastante para ter gestão de programa própria.
- Outras atividades, como capacitação contínua, gestão da mudança, operação assistida, comunicação com o público e manutenção de contratos, que não são projetos mas são necessárias para o benefício aparecer.
O terceiro grupo é o mais esquecido. Se a capacitação de quem vai usar o sistema não é componente de ninguém, ela tende a não acontecer, e o benefício não aparece mesmo com todas as entregas prontas.
Critérios para incluir um componente
| Critério | Pergunta | Evidência esperada |
|---|---|---|
| Contribuição para benefícios | O componente sustenta algum benefício do programa? | Seta no mapa de benefícios até um benefício registrado |
| Interdependência | Ele depende de outros componentes ou outros dependem dele? | Dependências identificadas no roadmap |
| Alinhamento estratégico | O objetivo que ele atende é do programa ou de outra área? | Ligação com o objetivo do business case |
| Viabilidade | Há orçamento, pessoas e capacidade de governança para absorvê-lo? | Análise de impacto em recursos e cronograma |
| Custo-benefício | O que ele custa compensa o que acrescenta ao programa? | Revisão do business case com e sem o componente |
Se o projeto não passa nos dois primeiros critérios, ele provavelmente pertence ao portfólio como projeto independente, e não ao programa. Isso não significa recusá-lo: significa que outra instância decide sobre ele. O mapa de benefícios é o instrumento mais rápido para fazer esse teste.
Como incluir um componente passo a passo
- Receba a proposta por escrito. Objetivo, benefício a que contribui, entregas principais, estimativa de custo e prazo, dependências conhecidas.
- Analise o impacto no programa. Como o componente altera o roadmap, a disputa por recursos, os riscos e o business case. Um projeto bom isoladamente pode atrasar outro mais importante.
- Leve à governança. O comitê ou o patrocinador decide com base na análise. Registre a decisão e o motivo, inclusive quando for negativa.
- Autorize formalmente. Designe o gerente do componente, defina escopo, orçamento, critérios de sucesso e, desde já, os critérios de encerramento.
- Integre ao programa. Padrões de relatório, cadência de reuniões, ferramentas, gestão de riscos e de mudanças do programa passam a valer para o componente.
- Atualize os artefatos. Mapa de benefícios, registro de benefícios, roadmap e orçamento do programa precisam refletir a inclusão no mesmo ciclo da decisão.
O passo 4 costuma ser pulado. Definir na entrada o que caracteriza a saída evita que o componente se arraste depois de cumprir o papel.
Quando encerrar, cancelar ou transferir um componente
Há três formas de um componente sair do programa, e cada uma tem gatilhos próprios:
Encerrar. O componente concluiu as entregas e elas foram transferidas para outro componente ou para a operação. É o caminho normal.
Cancelar. O componente é interrompido antes do fim porque:
- deixou de contribuir para os benefícios, por mudança de estratégia ou do próprio programa;
- o custo ou o prazo se tornaram incompatíveis com o benefício que ele gera;
- outro componente ou uma solução de mercado passou a cobrir a mesma necessidade;
- um risco se materializou e inviabilizou a entrega.
Transferir. O componente continua, mas em outro lugar: num programa diferente, porque contribui mais para os benefícios dele, ou na operação, quando o que resta é trabalho contínuo.
Em qualquer dos três casos, a decisão é da governança, e o momento natural para discuti-la são os pontos de decisão previstos no ciclo de vida do programa, como o fim de cada onda. Cancelar um componente que perdeu o sentido é boa gestão, não fracasso. A estrutura de decisão que sustenta essas escolhas está em governança de programas.
O que passar adiante na transição
Quando um componente sai, seis itens precisam de destino explícito:
| Item | Pergunta |
|---|---|
| Entregas | Quem recebe, aceita e mantém o que foi produzido? |
| Benefícios em realização | Quem continua medindo e respondendo pelo benefício? |
| Riscos e problemas abertos | Quem assume cada um e com que plano? |
| Contratos | Serão encerrados, transferidos ou mantidos? Há multas ou garantias? |
| Pessoas | Para onde vai a equipe? Algum especialista precisa ficar disponível? |
| Conhecimento | Onde ficam documentação, lições e decisões tomadas? |
Componentes encerrados sem essa lista deixam pendências que voltam ao programa meses depois, geralmente em forma de risco.
Um caso para discutir
O PMI publica, na página da certificação PgMP, uma amostra de questões baseada num cenário que trata exatamente deste assunto. Resumindo: um programa é cancelado e dois dos seus projetos, já bem avançados, são transferidos para outro programa que depende dos benefícios que eles vão gerar. Os dois projetos usam métodos, padrões de relatório e ferramentas diferentes dos do programa que os recebe.
Aplicando os passos acima, o gerente do programa receptor teria de responder a perguntas como: qual a situação real dos dois projetos? Os critérios de inclusão do programa de origem ainda valem no novo contexto? Qual o impacto em orçamento e recursos? Vale migrar os projetos para os padrões do programa agora ou só depois da entrega, considerando o quanto já avançaram? E quem formaliza a inclusão? A amostra mostra que a prova cobra esse raciocínio de programa, e não a ação típica de um gerente de projeto. Para treinar esse tipo de leitura, veja PgMP perguntas e respostas.
Sinais de que a carteira de componentes precisa de revisão
- Um componente não aparece em nenhuma seta do mapa de benefícios.
- Dois componentes entregam praticamente a mesma coisa.
- Um benefício importante não tem nenhum componente que o sustente.
- Componentes concluídos continuam com equipe e custo alocados.
- O programa cresce a cada trimestre sem que o business case seja revisto.
Se você ainda tem dúvida se o que conduz é um programa ou um conjunto de projetos em paralelo, o texto você lidera um programa ou projetos simultâneos? ajuda a fazer essa distinção, e o guia de gestão de benefícios, stakeholders e governança no PgMP mostra como os benefícios orientam todas essas decisões.
Faça hoje o teste dos critérios com os componentes do seu programa: para cada um, aponte o benefício a que contribui e o critério de encerramento. Os que ficarem sem resposta são a pauta da próxima reunião do comitê. Se você está se preparando para a certificação, o curso preparatório PgMP da Projeto Diário trabalha esses cenários com o padrão de gerenciamento de programas e mais de 500 questões comentadas em vídeo.
