Gerente de programas PgMP: estudo de caso com múltiplos projetos

O que faz, no dia a dia, um gerente de programas PgMP diante de dez ou vinte projetos que precisam andar juntos? A resposta curta é que ele não gerencia cada projeto por dentro. Ele cuida do que acontece entre os projetos: a entrega de um que atrasa o outro, o especialista disputado por três equipes, o risco que nasce num componente e estoura em outro, o benefício que só aparece quando todas as peças estão no lugar.

Para mostrar isso de forma concreta, seguem três estudos de caso ilustrativos, em tecnologia, saúde e serviços financeiros. Eles não descrevem empresas reais: foram montados para reproduzir situações típicas de programas e as decisões que o padrão do Project Management Institute (PMI) recomenda. Cada caso termina com o que ele ensina para quem se prepara para a certificação Program Management Professional (PgMP).

Múltiplos projetos não são, por si só, um programa

Antes dos casos, uma distinção que derruba muita gente na prova e na prática. Ter vários projetos ao mesmo tempo não cria um programa. Se os projetos são independentes, o que existe é uma carteira, e o trabalho é de priorização e de alocação de recursos, normalmente feito pelo portfólio ou pelo escritório de projetos.

Há programa quando os projetos (e outras atividades, como treinamento ou mudança de processo) são interdependentes e geram juntos um benefício que não gerariam separados. Nesse caso, o gerente do programa responde pelo resultado do conjunto. Os gerentes de projeto continuam responsáveis pelas suas entregas.

Se essa diferença ainda não está clara, gerente de programas: o que faz e por que o PgMP valida a função detalha o papel.

O que o gerente de programas PgMP faz entre os projetos

Nos três casos abaixo, as mesmas cinco frentes aparecem. Vale conhecê-las antes, porque são elas que distinguem o trabalho do programa do trabalho de cada projeto.

1. Dependências. Mapear quais entregas de um componente são insumo de outro e acompanhar essas datas com mais atenção do que as datas internas de cada projeto.
2. Recursos compartilhados. Decidir quem fica com o especialista, o ambiente de testes ou o fornecedor quando dois componentes precisam deles ao mesmo tempo, usando como critério o benefício do programa.
3. Riscos do programa. Tratar os riscos que atravessam componentes, como um fornecedor comum ou uma mudança regulatória, num registro do programa, separado dos registros de cada projeto.
4. Benefícios. Acompanhar se os resultados intermediários estão aparecendo, e não só se as entregas estão no prazo.
5. Governança. Levar ao comitê as decisões que mudam o programa (incluir, adiar ou encerrar componentes, mudar o roadmap) com análise e recomendação.

Os fundamentos dessas frentes estão no guia de gestão de benefícios, stakeholders e governança em programas, que é o ponto de partida da categoria.

Estudo de caso ilustrativo 1: lançamento de uma plataforma digital

Situação. Uma empresa de software decide lançar uma plataforma de pagamentos para pequenos comércios. O programa reúne sete componentes: aplicativo, sistema de retaguarda, integração com adquirentes, adequação de segurança, atendimento, campanha de lançamento e treinamento da equipe comercial. O benefício principal é a receita recorrente nos doze meses seguintes ao lançamento.

Problema. No quarto mês, a integração com adquirentes atrasa seis semanas por causa de uma exigência técnica de um parceiro. Os outros componentes estão no prazo, e os gerentes de projeto pressionam para manter a data de lançamento com uma versão sem essa integração.

Decisão do gerente do programa. Em vez de decidir sozinho, ele leva ao comitê duas opções com o efeito de cada uma no benefício. Lançar sem a integração mantém a data, mas limita a plataforma a um meio de pagamento e reduz a receita esperada no início. Adiar o lançamento empurra a receita, mas preserva a proposta completa. O comitê escolhe uma terceira via sugerida na análise: lançamento restrito a uma região, com a campanha ampla só depois da integração.

O que ensina para o PgMP. A pergunta certa não é "qual projeto está atrasado", e sim "como o atraso afeta o benefício". E decisões que mudam o roadmap vão para a governança, com recomendação do gerente do programa.

Estudo de caso ilustrativo 2: infraestrutura e tecnologia num hospital

Situação. Um hospital filantrópico de médio porte reúne num programa a reforma do centro cirúrgico, a troca do sistema de prontuário e a implantação de um novo fluxo de agendamento de cirurgias. O benefício esperado é aumentar o número de cirurgias por mês sem ampliar a equipe.

Problema. A equipe de tecnologia é a mesma para o prontuário e para o agendamento, e os dois projetos planejaram o pico de trabalho no mesmo trimestre. Além disso, a reforma exige fechar salas por períodos, o que reduz cirurgias justamente quando o benefício deveria começar a aparecer.

Decisão do gerente do programa. Ele monta um mapa de dependências e mostra que o agendamento novo só gera benefício com as salas reformadas em operação. Propõe sequenciar: primeiro o prontuário (que tem prazo regulatório), depois a reforma em etapas, e o agendamento entrando quando a primeira ala reformada reabre. Os riscos que atravessam os três componentes, como a indisponibilidade de médicos durante a transição, passam a ser tratados num registro do programa com a diretoria clínica como responsável.

O que ensina para o PgMP. Recursos compartilhados são decididos pelo benefício do conjunto, e não pela urgência de cada projeto. E componentes podem ser reordenados no roadmap; o assunto é aprofundado em componentes do programa.

Estudo de caso ilustrativo 3: transformação digital numa cooperativa de crédito

Situação. Uma cooperativa de crédito conduz um programa para levar o atendimento ao celular: aplicativo, abertura de conta digital, revisão de processos de agência e capacitação dos gerentes de relacionamento. Alguns componentes usam métodos ágeis, outros seguem planejamento preditivo.

Problema. As equipes ágeis entregam a cada duas semanas, enquanto a revisão de processos e o treinamento têm marcos trimestrais. O comitê recebe relatórios em formatos diferentes e não consegue ver se o programa está gerando o benefício: aumento das operações feitas pelo aplicativo.

Decisão do gerente do programa. Ele não tenta uniformizar os métodos. Define uma cadência comum de revisão do programa (mensal), um painel com poucos indicadores que todos os componentes alimentam e um ponto de integração por trimestre, em que as entregas ágeis acumuladas são confrontadas com a prontidão das agências. O indicador de benefício passa a abrir todas as reuniões do comitê.

O que ensina para o PgMP. O programa pode combinar abordagens diferentes nos componentes, desde que a governança e a medição de benefícios sejam comuns.

O que os três casos têm em comum

Nos três, o problema não estava dentro de um projeto. Estava na fronteira entre projetos ou entre o programa e a operação. E nos três a saída teve a mesma estrutura:

• o gerente do programa traduziu o problema em efeito sobre o benefício;
• levou opções, e não só o problema, a quem tinha autoridade para decidir;
• ajustou o roadmap ou a forma de medir, sem invadir a gestão interna dos projetos;
• registrou a decisão e o novo critério para que a situação não se repetisse.

Um roadmap visual ajuda muito nesse trabalho, porque mostra as dependências e as ondas de entrega num só lugar. A ferramenta de roadmap de programa monta essa visão a partir dos componentes e marcos.

Como usar estudos de caso na preparação para o PgMP

As questões do exame PgMP descrevem situações de programa e pedem a melhor ação do gerente. Os casos acima treinam exatamente esse raciocínio. Um roteiro de estudo:

1. Leia a situação e identifique o domínio do problema: benefício, parte interessada, governança, alinhamento estratégico, colaboração ou ciclo de vida.
2. Pergunte se a decisão cabe ao gerente do programa ou ao comitê.
3. Descarte respostas que resolvem o problema de um projeto à custa do benefício do programa.
4. Prefira ações que analisam e envolvem antes de ações que impõem.

Para praticar com questões comentadas no mesmo formato, veja PgMP perguntas e respostas.

Monte o seu próprio caso

Pegue o conjunto de projetos em que você trabalha e faça o teste: existe um benefício que só aparece quando eles se juntam? Se sim, desenhe as dependências entre eles, escolha um indicador para o benefício e descreva a última decisão que deveria ter ido ao comitê e não foi. Esse exercício vira material de estudo e também de aplicação para a certificação, que pede a descrição da sua experiência em programas. Para estudar os domínios com método e questões no estilo da prova, o Preparatório para a certificação PgMP da Projeto Diário é o próximo passo.