Stakeholders
O que é um stakeholder?
Um stakeholder é qualquer pessoa, grupo ou organização que pode afetar ou ser afetado pelo projeto — direta ou indiretamente. Identificá-los cedo é uma das decisões mais importantes do gestor de projeto.
A tendência natural é focar nos stakeholders visíveis — o cliente, a equipa, o patrocinador. Os problemas surgem com os invisíveis: o departamento jurídico que bloqueia no final, o utilizador final que nunca foi consultado, o fornecedor crítico que ninguém mapeou.
Mapeamento — Matriz Poder × Interesse
A ferramenta mais usada para mapear stakeholders é a matriz Poder × Interesse, que coloca cada stakeholder em um de quatro quadrantes:
Alto poder, alto interesse — Gerir de perto
São os stakeholders mais críticos. Tomam decisões, têm opinião forte e estão envolvidos. Exigem comunicação frequente, envolvimento nas decisões-chave e atenção às suas preocupações. Exemplos: patrocinador do projeto, diretor da área cliente.
Alto poder, baixo interesse — Manter satisfeitos
Podem impactar significativamente o projeto mas não querem ser sobrecarregados com detalhes. Comunicação periódica, focada em impacto e resultados, não em processo. Exemplos: administração, direção financeira.
Baixo poder, alto interesse — Manter informados
Acompanham de perto mas têm pouca influência formal. Podem ser aliados importantes ou fontes de resistência. Merecem comunicação regular e transparente. Exemplos: utilizadores finais, equipas operacionais afetadas.
Baixo poder, baixo interesse — Monitorizar
Envolvimento mínimo. Informar apenas quando há decisões que os afetam diretamente. Exemplos: departamentos periféricos, fornecedores secundários.
Envolvimento por fase do projeto
O erro mais comum é tratar todos os stakeholders da mesma forma em todas as fases. O envolvimento deve ser calibrado — quem decide, quem valida, quem é apenas informado, e quando.
Fase de Início
- Patrocinador: decide o go/no-go, aprova o charter do projeto
- Direção: alinha expectativas estratégicas, define restrições
- Gestor de projeto: facilita, documenta, compromete recursos
- Utilizadores finais: primeiras entrevistas para levantamento de necessidades
- Equipa técnica: avaliação preliminar de viabilidade
Fase de Planeamento
- Patrocinador: aprova o plano, o orçamento e o âmbito
- Clientes/utilizadores: validam requisitos, confirmam prioridades
- Equipa: estima esforço, identifica dependências e riscos
- Departamentos de suporte (jurídico, compras, IT): identificar constrangimentos cedo
- Stakeholders externos: mapear integrações e dependências
Fase de Execução
- Equipa: comunicação diária, remoção de impedimentos
- Cliente/product owner: validação de entregas parciais, decisões de âmbito
- Patrocinador: escalamento de bloqueios críticos, aprovação de mudanças significativas
- Utilizadores: testes e feedback contínuo
Fase de Controlo
- Patrocinador e direção: relatórios de progresso periódicos — estado do prazo, custo e âmbito
- Cliente: revisão de desvios e aprovação de ajustes
- Equipa: retrospetivas e ajustes ao plano
- Stakeholders periféricos: comunicação de impactos relevantes
Fase de Fecho
- Patrocinador: aceita formalmente as entregas, libera recursos
- Utilizadores: validação final, formação e transição
- Equipa: lições aprendidas, documentação
- Direção: avaliação de benefícios realizados vs esperados
Comunicação diferenciada
Cada stakeholder precisa de informação diferente, no formato certo, na frequência certa.
Executivos e administração: dashboard de uma página, semáforo de estado (verde/amarelo/vermelho), desvios de prazo e custo, riscos críticos. Sem detalhe técnico. Frequência: quinzenal ou mensal.
Patrocinador: relatório de progresso com decisões pendentes claramente identificadas. O patrocinador não quer saber o que está a acontecer — quer saber o que precisa de decidir ou desbloquear.
Cliente e product owner: estado das entregas, o que foi concluído, o que vem a seguir, questões abertas que precisam de resposta. Frequência: semanal.
Equipa de projeto: reuniões curtas e frequentes, foco em impedimentos e dependências. O que fizemos, o que vamos fazer, o que está a bloquear.
Utilizadores finais: comunicação em linguagem simples, focada no impacto para o seu trabalho. O que vai mudar, quando, e como serão suportados na transição.
Gestão de resistência
A resistência de stakeholders é normal e previsível. O erro é ignorá-la ou tratá-la como obstáculo a contornar.
As causas mais comuns de resistência são: falta de informação, medo de perda de controlo ou relevância, experiências negativas com projetos anteriores, perceção de que não foram ouvidos, e impacto real no seu trabalho que não foi reconhecido.
A abordagem mais eficaz passa por identificar a resistência cedo — antes de se tornar bloqueio formal — ouvir genuinamente as preocupações, envolver o stakeholder resistente na solução sempre que possível, e ser transparente sobre o que vai mudar e porquê.
Um stakeholder que resiste mas foi ouvido é muito mais fácil de gerir do que um que resiste porque se sentiu ignorado.
Ligação à gestão da mudança
A gestão de stakeholders e a gestão da mudança são inseparáveis. A mudança acontece através de pessoas — e as pessoas só mudam quando entendem o porquê, confiam no processo e se sentem parte da solução.
O mapa de stakeholders deve ser um documento vivo, atualizado ao longo do projeto. As posições mudam, os interesses evoluem, novos stakeholders emergem. Um mapeamento feito apenas no início e esquecido não serve o projeto.
Atualizado em: 25/05/2026