Estamos já cansados de ouvir que 90% do tempo do gerente de projetos é dedicado a comunicação e que mais de 70% dos projetos que falham tem a comunicação como o seu maior problema.
Até onde a comunicação pode ser uma entidade abstrata, onde entendemos sua importância mas não sabemos como interagir para garantir resultados adequados? Até onde o entendimento dos envolvidos, a criação de matrizes de responsabilidade e planos de comunicação podem assegurar melhores resultados em projetos?
Como diria qualquer bom consultor, "DEPENDE...". E aí, para cada projeto, para cada tipo de cliente, para cada situação de projetos teríamos regras, necessidades e objetivos bem distintos em relação a comunicação que precisa ser feita.
De forma prática. Como podemos fazer a diferença? Gerenciando INTERFACES.
Sinceramente não sei se pesquei o termo em alguma leitura específica sobre o assunto. Não posso dizer se o termo foi já abordado por alguém, mas há alguns anos eu defino como crucial em meus projetos o controle sobre INTERFACES e faço este controle explicitando em meus cronogramas a minha relação com terceiros.
Neste contexto, ao decompor meu projeto em sua EAP, no primeiro nível vou ter elementos específicos do produto que pretendo entregar e também um item dedicado à gestão. Em algumas empresas com quem já trabalhei ou acompanho suas atividades, é comum neste segundo nível da EAP (considerando o projeto completo como o primeiro nível) que utilizem áreas da empresa para então definirem as partes dos produtos que serão elaboradas.
Ilustrando este caso, teríamos que para a entrega de um sistema de transporte de carvão, no primeiro nível teríamos o projeto em si e no segundo nível teríamos: gestão, engenharia, suprimentos, fabricação, transportes, montagem e pré-operação. Se olharmos a seco as "melhores práticas em EAP" preconizadas pelo PMI, teríamos um foco em entregas de produto, quebrando o segundo nível talvez em torres, galerias, etc. De fato, isso pouco importa e poderemos tratar isso em outro blog... Precisamos sim ter a nossa EAP direcionada a entregas, mas estas entregas não precisam ser necessariamente resultados visíveis para o cliente (a torre) e podem eventualmente ser resultados visíveis para a equipe (a engenharia da torre, a montagem da torre, etc).
E as interfaces? Bom, não importa como foi feita a EAP, estamos imaginando que há um pacote de trabalho definido como "gestão de projeto" e este pacote ou nível será novamente decomposto em outros elementos. É aí onde entram as interfaces:
+ GESTAO
---+ INTERFACES
--------+ COM Fornecedor A
--------+ COM Fornecedor B
--------+ COM O CLIENTE
-------------+ REUNIOES PERIÓDICAS
-------------+ DEPENDÊNCIAS EXTERNAS
------------------= Licença Ambiental Fornecida
------------------= Liberação de entrada para iniciar atividades
------------------= Autorização para supressão vegetal na Área X
------------------= Autorização para supressão vegetal na Área Y
(etc)
E o que é tão importante nestas interfaces?
- Precisamos explicitar as condições externas que podem ou não prejudicar o andamento normal de meus trabalhos. Não adianta reportar que estou atrasado por que não me liberaram o acesso se eu não deixo explícito o momento em que esta liberação deveria ter ocorrido e quando de fato ela veio ocorrer. É a diferença entre estas datas que me favorecem o pleito de prazo junto ao cliente, mediante uma explícita relação de dependências que precisam ser criadas para que venham a refletir no caminho crítico do meu projeto.
Se no início do projeto bastava uma única autorização para entrar no local de trabalho e cuidar do que está acontecendo, então esta autorização tem data certa no meu cronograma e eventuais atrasos serão reportados com as medições de projeto. Em um dado instante, dentro da área em que se esperava trabalhar há subdivisões espaciais que podem ou não serem acessadas pela minha equipe por uma série de razões (uma área tem acesso restrito por conta de alguma instrução do cliente, uma outra área tem um problema de acesso, outra há elementos externos que não permitem o trabalho, etc). Neste momento, torna-se necessário ir a área de Interfaces com o cliente e trazer novos marcos de controle com novas condições externas que irão impactar o meu trabalho no futuro.
Aqui não importa se estamos falando de projetos de engenharia ou de software (ou qualquer outro, desde que façamos a abstração necessária do conceito). Em um projeto de software não é comum que não se possa entrar em uma determinada área por estar interditada por alguma razão, mas é comum não se conseguir acesso a um determinado tipo de cliente ou a uma determinada reunião por razões antes não documentadas.
Ao explicitar em INTERFACES aquelas dependências que consideramos externas e amarrarmos elas à outras atividades de projeto, nós conseguimos algumas coisas importantes:
A) Explicitamos informações que irão apoiar a identificação de quem é a responsabilidade por atrasos;
B) Chamamos a atenção do cliente para os itens que estão travando o nosso trabalho e consideramos de sua responsabilidade;
C) Detectamos impactos e com isso podemos calcular outras alternativas e ajustes em cronogramas para reduzir os impactos;
D) Lidamos com os problemas de forma pró-ativa e clara, ampliando os canais de comunicação e trazendo os clientes a atuarem como parceiros na resolução dos mesmos.
Devemos pensar que após explicitar em nossa área de interfaces que um determinado item passa a repercutir em atraso para o nosso projeto, mesmo que o cliente não concorde com aqueles elementos expostos que afirmamos atrapalhar o nosso projeto nós estamos no LUCRO.
Conflitos são naturais em qualquer projeto. O que precisamos é atuar de forma pró-ativa com eles e solucioná-los o mais cedo possível. Se entendemos que uma dada autorização é necessária para a execução de nossos trabalhos e ao deixar isso explícito no cronograma o cliente afirma que a lógica de dependências não está correta, duas coisas podem então acontecer:
A) Vamos começar com os trabalhos sob responsabilidade do cliente pois ele mesmo disse que aquela dependência não deveria ser considerada;
B) Vamos ter o cliente correndo atrás do problema para que não fique explícito no cronograma que cada adia de atraso é oriundo de suas dificuldades internas e não necessariamente de nossa equipe de projeto.
Ou seja: Dado o conflito, qualquer resolução é favorável ao projeto. Não fazer nada é que seria o problema.
Em um certo cenário em um projeto de menor porte na empresa onde estou trabalhando, o GP do outro projeto veio me contar que tinha um problema de atraso com o cliente e que ele o estava ameaçando de multas. O cliente dizia que uma dada entrega de materiais tinha ocorrido em diversas etapas (em diferentes semanas) e por isso o projeto estava atrasado. O GP dizia que mesmo com o material em campo, não poderia ter seguido com os trabalhos por que dependia de liberações de bases civis de responsabilidade do cliente.
Ao quebrarmos as suas atividades de execução em blocos menores, cada um deles amarrado a sua própria necessidade de materiais e à liberação das bases por parte do cliente, o que conseguimos foi evidenciar que para cada base o material de fato estava à tempo e que os atrasos estavam vinculados à construção civil que não era de nossa responsabilidade, no lugar da chegada de materiais como alegava o cliente.
Explicitar estes elementos não são agradáveis. O cliente de fato vai ficar mal-humorado em ver em uma seção do cronograma um conjunto de atividades que são de SUA responsabilidade. Isso gera conflito, mas é um conflito que favorece a resolução de problemas em favor do projeto (logo a ambas as partes). Esconder as dependências ou não explicitá-las e trazer para o GP o risco exclusivo de arcar com todos os problemas de projetos.
Dai a César o que é de César e dai ao cliente o que é do cliente. Transparência de ações e uma adequada amarração de dependências externas e internas em um cronograma são elementos-chave para o sucesso de qualquer projeto.
Em resumo: No contexto apresentado, INTERFACES é uma seção especial de um cronograma, devidamente estruturada na EAP do projeto, onde deixamos de forma explícita as dependências externas do projeto oriundas de fornecedores e cliente, desde a chegada de um material, a liberação de um documento ou o fornecimento de algum elemento crítico para o projeto. Reuniões, emissões de documento e até mesmo correspondências enviadas e recebidas podem eventualmente fazer parte destas INTERFACES, conforme o GP definir em seu plano de projeto e de comunicação.
