Desenvolver a EAP – Estrutura Analítica de Projeto

A técnica para se desenvolver uma EAP é denominada decomposição, pois a proposta é quebrar o produto principal do projeto em todos os produtos ou entregáveis necessários para a entrega total do projeto.

A EAP é resultado da quebra sucessiva do trabalho a ser  feito no projeto. Muitas vezes observamos uma confusão de profissionais em relação ao EAP, que fazem a EAP pensando nas características do produto do projeto e não no trabalho a ser  feito para a realização do produto.

Ela constitui um importante instrumento de comunicação  entre todos os envolvidos no projeto. Além disso, permite  visualizar todo o escopo do trabalho a ser realizado no projeto.

Alguns conceitos importantes:

• Entregas (deliverables) – deve ser mensurável, tangível, com um resultado verificável. Uma entrega é qualquer resultado do projeto: serviço, produto ou  conjunto de funções.
• Tarefa ou Atividade – As tarefas ou atividades não são incluídas na EAP, mas serão utilizadas na decomposição da EAP quando for construído o  cronograma.
• Pacote de trabalho – É denominado pacote de trabalho  o mais baixo nível da EAP. Este provê uma lógica  básica para a definição seguinte de atividades para  a sua realização.
• Dicionário da EAP – Consiste em documentação (descritivo) dos produtos da EAP. Geralmente é feita a descrição dos pacotes de trabalho para que os seus responsáveis ou os usuários/clientes tenham entendimento do que se tratam.

Algumas regras importantes:

• A regra dos 100% - o próximo nível da decomposição  de um elemento da EAP tem que representar 100% do trabalho do seu elemento pai.
• A regra de 8-80 – Essa regra ajuda a se definir até  onde se deve quebrar os níveis de uma EAP. Para fins  de torná-lo gerenciável, considera-se que o pacote  de trabalho pode ser realizado de 8 a 80 horas (de um dia a duas semanas de trabalho). Se o pacote necessitar de um esforço maior de duração, por exemplo, 120 horas, deverá ser quebrado em dois subpacotes, sempre que possível.
• O gerenciamento do projeto – Um dos trabalhos que todo projeto tem é de gerenciamento. Portanto esse trabalho deve estar presente na EAP, geralmente no primeiro nível.
• Co-participação do time e validação do usuário/demandante – A EAP deve ser construída com a participação da equipe técnica (equipe alocada para o planejamento) e deve ser validada com outros profissionais do Serviço do projeto, bem como profissionais do Escritório de Projetos e com representantes do setor usuário/demandante.

Como construir uma EAP

A forma de se construir uma EAP pode variar de acordo com o tipo de projeto ou a vontade do gerente do projeto. Alguns tipos mais comuns são:

• Quebra por Produto – Quebra do produto principal em produtos menores. Muito utilizado em projetos com produtos mais tangíveis, tais como construção civil, desenvolvimento de software, desenvolvimento de um avião, etc.
• Quebra por Serviço – Utilizado para projetos não muito tangíveis, tais como conferência, treinamento, casamento, viagem de férias, etc.
• Quebra por Fases – Utilizado para se montar o primeiro nível da EAP, onde são expressas as fases da metodologia técnica referente a área do projeto. Exemplo de Construção Civil: Estudos dos Solos, Fundação, Construção, Acabamento.

Exemplo em desenvolvimento de Sistemas: Concepção, Elaboração, Construção, Transição. Caso a metodologia também tenha as subfases, essas também devem constar da EAP.

Pode-se ainda utilizar um misto dessas técnicas. Por exemplo, começar por fases no primeiro nível, depois produtos e serviços nos níveis seguintes.

O importante que ao final a EAP construída tenha só e somente só o escopo do projeto, não tendo nem mais nem menos do que o necessário para a realização do projeto.

Desenvolver o Cronograma

Após a definição da EAP e aprovação da mesma pelo Escritório de Projetos e pelo usuário/demandante, a etapa seguinte é detalhar a EAP com uma lista formal de atividades ou tarefas.

Os passos seguintes são:

1. Desenvolver a lista de atividades necessárias para a realização de cada pacote de trabalho.
2. Fazer as interdependências entre essas atividades (ligação entre as atividades do tipo término-começo, começo-começo, término-término e começo-término) e atrasos ou adiantamentos das atividades ou dos relacionamentos entre elas (começar depois de dois dias, começar com antecedência de 5 dias, começar após o dia tal, etc.)
3. Estimar as durações das atividades.

Conforme CARNEIRO, M. (2005) “cabe ressaltar que a forma com que planejamos ajudará no controle e monitoração do projeto”. Podemos controlar a realização dos produtos ou então a realização das atividades, que no fundo servem para a confecção dos produtos. No controle entendemos melhor a regra das 80 horas. Se tivéssemos um produto que fosse realizado em um mês e meio, por exemplo, e fizéssemos uma reunião a cada quinze dias, então ficaria muito difícil de gerenciar, pois não teríamos um ponto de controle claro, uma evidência de realização ou não do plano. Os profissionais ou os softwares informam qual o percentual de realização da atividade, o que, geralmente, não condiz com a realidade.

Os pontos de controle feitos por milestones, que geralmente são pontos que evidenciam a finalização de um produto, são importantes instrumentos de acompanhamento de projetos. 80 horas não é um número cabalístico, parece ser razoável, pois permite a visão de produtos finais a cada duas semanas no máximo. Em alguns projetos de curta duração ou que tenha muitos produtos, entretanto, talvez seja mais eficiente quebrar em pontos semanais (40 horas). Outros grandes projetos de 5,6 ou mais anos, por exemplo, podem ter pontos de controle mensais durante os primeiros dois anos de projeto, por exemplo. Um aluno reportou um projeto de telecomunicações de grande desafio, conduzido por um gerente de projetos italiano, cujo controle era diário: eram definidos produtos e atividades diárias para cumprimento desses produtos, de forma a garantir que o cronograma altamente desafiador fosse implementado dentro do esperado. Ou seja, “a regra das 80 horas é orientativa e não lei aplicável a todo projeto”.