Como identificar stakeholders do projeto: técnicas e perguntas

Saber como identificar stakeholders é saber onde o projeto vai ser surpreendido. A parte interessada esquecida não some: ela aparece no meio da execução, com uma exigência que muda o escopo, um parecer que trava a obra ou uma reclamação que chega à diretoria antes de chegar a você. Quase sempre alguém da equipe sabia que ela existia, mas ninguém perguntou.

A identificação funciona melhor quando combina várias técnicas, porque cada uma enxerga um pedaço diferente da organização. A seguir estão seis técnicas práticas, perguntas específicas para os tipos de projeto mais comuns, as partes que costumam ficar de fora e como registrar o resultado para a etapa seguinte.

O ciclo completo, da identificação ao monitoramento do engajamento, está no guia de gestão de stakeholders. Aqui o foco é só o primeiro passo: chegar a uma lista completa.

Quem conta como stakeholder

O Project Management Institute (PMI) define parte interessada como o indivíduo, grupo ou organização que pode afetar, ser afetado ou se perceber afetado por uma decisão, atividade ou resultado do projeto. Três consequências práticas:

• Quem se sente afetado conta, mesmo que você acredite que o projeto não o afeta.
• Grupos contam. "Usuários do sistema de compras" é uma parte interessada legítima.
• Na fase de identificação, inclua em vez de excluir. Quem tem pouco poder e pouco interesse vai ficar no quadrante de monitorar, sem custar esforço. O erro caro é a omissão.

Como identificar stakeholders: seis técnicas

1. Análise de documentos

Leia com uma pergunta na cabeça: quem aparece aqui? Termo de abertura, business case, contratos, editais, normas internas, organogramas, atas de projetos anteriores parecidos. Contratos são uma fonte rica: cada cláusula de aprovação, fiscalização ou garantia revela alguém. Se o projeto ainda não tem um termo de abertura escrito, o gerador de termo de abertura ajuda a montar um, e o próprio preenchimento já revela patrocinador, aprovadores e áreas envolvidas.

2. Brainstorming estruturado

Reunir a equipe e perguntar "quem são os stakeholders?" produz uma lista óbvia. Estruture a sessão por categorias e trate uma de cada vez:

• quem decide e quem paga;
• quem usa o resultado;
• quem opera e mantém depois;
• quem fornece;
• quem fiscaliza, regula ou audita;
• quem é afetado de fora (vizinhos, comunidade, clientes finais).

Uma variação útil é o brainwriting: cada participante escreve sua lista em silêncio por cinco minutos antes da discussão. Pessoas mais reservadas e mais novas na empresa contribuem mais, e a lista não fica presa às primeiras ideias de quem fala primeiro.

3. Entrevistas em bola de neve

Comece pelo patrocinador e pelas partes já conhecidas. No fim de cada conversa, pergunte: "quem mais deveria estar sabendo deste projeto?" e "quem pode ficar incomodado com ele?". Cada entrevista indica novos nomes. Pare quando as indicações começarem a se repetir.

Um exemplo ilustrativo, num projeto de troca do sistema de folha de pagamento: o diretor de RH indica a gerente de folha; ela lembra do contador terceirizado que gera as obrigações acessórias; ele aponta o banco que recebe o arquivo de pagamento; e o banco revela que o sindicato acompanha o calendário de crédito dos salários. Nenhum desses quatro estava na primeira lista da equipe, e qualquer um deles poderia travar o primeiro pagamento no sistema novo.

4. Caminhada pelo ciclo de vida do resultado

Imagine o resultado do projeto do começo ao fim da vida útil dele e anote quem toca cada etapa: quem especifica, quem constrói, quem testa, quem aprova, quem implanta, quem treina, quem usa, quem dá suporte, quem mede o desempenho, quem um dia vai desativar. Essa técnica revela principalmente as áreas de operação e suporte, as mais esquecidas no início.

5. Direções de influência

O Guia PMBOK 6ª edição sugere olhar as partes interessadas pela direção da influência em relação ao projeto. Use as quatro direções como checklist:

A direção lateral é a mais esquecida. O gerente de outro projeto que usa a mesma equipe de TI tem poder real sobre o seu cronograma, e o gerente da área vizinha que vai receber parte do trabalho redistribuído também. Uma conversa curta no início, para combinar prioridades, evita a disputa de recursos no meio da execução.

6. Lista de verificação da organização

Com o tempo, o PMO ou a própria equipe pode manter uma lista padrão das áreas que sempre devem ser consultadas: jurídico, compras, segurança da informação, encarregado de dados pessoais, comunicação interna, RH, saúde e segurança do trabalho. Revisar essa lista leva cinco minutos e evita esquecimentos repetidos de projeto para projeto.

Perguntas por tipo de projeto

As perguntas gerais (quem decide, quem paga, quem usa) valem para tudo. Estas ajudam a ir além em cada contexto:

Projeto de TI ou implantação de sistema

• Quais sistemas trocam dados com o novo, e quem é dono de cada um?
• Quem dá suporte depois do go-live: equipe interna, fornecedor ou ambos?
• Há dados pessoais envolvidos? Quem responde pela proteção deles?

Obra ou reforma

• Quem vai ocupar e manter o espaço?
• Que licenças, alvarás ou vistorias são necessários, e de quais órgãos?
• Quem é vizinho e vai conviver com ruído, poeira ou desvio de trânsito?

Evento

• Quem aprova orçamento de viagens e hospitalidade, e há política de compliance para isso?
• Quem são os fornecedores críticos (local, alimentação, transmissão)?
• Quem precisa liberar os participantes da rotina?

Projeto em órgão público

• Quem assina os atos e quem dá parecer jurídico?
• Quais órgãos de controle interno e externo acompanham esse tipo de contratação?
• Que servidores perdem atribuições ou ganham novas com o projeto?

Lançamento de produto

• Quem precisa aprovar rótulo, embalagem ou comunicação por exigência regulatória?
• Quais canais de venda precisam aceitar o produto?
• Quem atende o cliente quando surgir a primeira reclamação?

Partes interessadas que quase sempre ficam de fora

• Quem perde algo com o projeto: o coordenador que controlava a planilha que o sistema substitui, a área que perde orçamento.
• Suporte e operação: a equipe que vai atender os chamados depois da entrega.
• Áreas de controle: auditoria interna, compliance, segurança da informação.
• Gestores de outros projetos que disputam as mesmas pessoas.
• Representantes de trabalhadores, quando o projeto mexe em jornada, função ou quadro de pessoal.
• O cliente do cliente: em projetos de prestação de serviço, quem usa o que o seu cliente entrega.

Como registrar o que foi identificado

A lista sai da identificação e vai para um registro de partes interessadas. Para cada parte, anote no mínimo:

• nome ou grupo, com o papel no projeto;
• área ou organização, interna ou externa;
• principal expectativa e principal preocupação;
• como foi identificada (documento, entrevista, oficina), o que ajuda a validar depois;
• quem da equipe vai cuidar da relação.

Os campos completos e um modelo para copiar estão no artigo sobre o registro de stakeholders. Com a lista registrada, o passo seguinte é analisar poder, interesse e atitude de cada parte, seja seguindo o roteiro de análise de partes interessadas, seja montando direto o mapa de stakeholders.

Quando repetir a identificação

A identificação feita no início fica desatualizada rápido. Repita:

• em cada mudança de fase;
• quando o escopo mudar;
• quando entrar um fornecedor novo ou sair um gestor importante;
• quando alguém aparecer com uma exigência que ninguém previu. Nesse caso, pergunte também quem mais pode estar na mesma situação.

Comece agora

Separe uma hora nesta semana: leia o termo de abertura e os contratos com a pergunta "quem aparece aqui?", rode o brainstorming por categorias com a equipe e marque três entrevistas terminando com "quem mais deveria saber disso?". Depois leve a lista para a ferramenta gratuita de mapa de stakeholders da Projeto Diário, que classifica cada parte por poder e interesse, mostra quem resiste e ajuda a montar o plano de comunicação.