Usando uma EAP para estimativas de projetos

Pensando em projetos e execução de projetos, a concorrência neste mundo tornou-se tão grande e intensa que as organizações dificilmente querem correr riscos que possam colocar os seus projetos em risco e sofrer implicações negativas durante qualquer fase do projeto / programa.

Dito isto, por causa da quantidade de ferramentas e conhecimento gratuitos de projetos disponíveis nos dias de hoje, as organizações também tomam as ações corretivas necessárias antecipadamente para garantir que todos os seus programas / projetos sejam totalmente compatíveis a partir de uma perspectiva de processos, custo da qualidade, tempo, escopo e cronograma, que são obrigatórios para atender as demandas de fornecimento do cliente.

Dos fatores mencionados acima, vamos tomar o “escopo”. O escopo é uma necessidade fundamental para todos os projetos – esta é a coisa real que precisa ser entendida e implementada. Como todos nós sabemos muito bem, há várias circunstâncias em que projetos falharam ou que tiveram prejuízos pela simples razão do escopo não ter sido corretamente compreendido ou não ter sido corretamente implementado. “Escopo” é o elemento de conexão para os demais parâmetros do projeto como custo, tempo, recursos, etc. Portanto, para entender o escopo, este deve ser quebrado em pedaços menores, criando itens de escopo mais simples, que confirmem os entregáveis… e isto é chave para qualquer projeto.

Este artigo descreve uma das ferramentas mais importantes – a EAP (Estrutura Analítica do Projeto) para entender e decompor o escopo do projeto e também vários sucessos e vantagens que uma equipe de projeto pode entregar se uma EAP for bem preparada e utilizada por toda a duração do projeto.

O que é uma Estrutura Analítica do Projeto?

Simplificando, uma Estrutura Analítica do Projeto é uma decomposição hierárquica do escopo / trabalho que precisa ser estimado e executado durante o curso do projeto, a fim de concluir seus objetivos e entregáveis.

Embora pareça simples, uma EAP tem enorme força e influência para converter requisitos complexos em pequenas e mais fáceis peças para estimativa, planejamento e execução do projeto. A EAP:

-- Dá clareza sobre as necessidades do projeto em termos de entregáveis e critérios de sucesso. Ela destaca o “quê” do projeto;

-- Organiza o escopo do projeto, criando uma estrutura de decomposição definida em torno dele;

-- Dá mais simplicidade e quebra as atividades a serem realizadas usando cada nível hierárquico decomposto;

-- Sucessivamente subdivide o escopo em componentes gerenciáveis ??em termos de tamanho, duração e responsabilidade;

-- É um diagrama estruturado retratando a lista hierárquica dos requisitos gerais do projeto em níveis crescentes de detalhe;

-- Auxilia na atribuição de responsabilidades, alocação de recursos, monitoramento e controle do projeto;

-- É um importante instrumento de revisão do escopo para os stakeholders do projeto. Também dá uma visão gráfica do escopo e entregas do projeto. 

Como criar uma EAP e qual a sua importância?

Passo 1: Liste os requisitos e entregas de escopo de nível mais alto

É uma das práticas mais comuns que a primeira declaração do escopo ou o escopo do trabalho que a equipe do projeto recebe possa conter informações em um formato confuso e, portanto, não pode ser tomada como definitiva para a estimativa de projeto e sua implementação.

A equipe do projeto deve discutir o escopo com os clientes e outros stakeholders-chave para entender a necessidade do escopo mencionado e também os principais objetivos, requisitos e entregáveis que são esperados do projeto. É implícito que esses esclarecimentos de requisitos e discussões com as equipes dos clientes são necessários durante todo o curso do projeto como e quando necessário do ponto de vista de estimativas. Coloque estes objetivos / requisitos / entregas no primeiro nível da hierarquia no diagrama da EAP (ver Figura 1). Este passo dá um ponto de partida claro para o processo de estimativa do projeto através da conversão de um documento de escopo em um primeiro conjunto de requisitos de alto nível.

Um dos pontos a ter em mente é que o desenvolvimento de um diagrama hierárquico é apenas para a facilidade de entendimento e compreensão mais rápida da decomposição do escopo. Os componentes fragmentados podem ser listados e numerados em qualquer formato e em qualquer ferramenta (Word, Excel, Project, etc …) e podem ser acompanhados de várias maneiras. Não é o formato que importa, mas a conexão e ligação entre os itens “pais” e seus “filhos”, que torna a estrutura da EAP uma das ferramentas mais importantes e úteis para o processo de estimativa de projeto. 

\"\"

Figura 1: Requisitos de Alto Nível

Passo 2: Fragmente cada requisito de alto nível em principais categorias de entregáveis 

Uma vez que os requisitos de alto nível estão definidos, tal como explicado na etapa 1 acima, para cada um destes requisitos, as equipes devem então tomar cada um deles um por um e começar a explorar os próximos níveis de produtos que devem ser criados / modificados / implementados para atingir os requisitos. É bastante possível que, para determinados requisitos de alto nível, mudanças possam ser necessárias para diversos sistemas, processos e componentes diferentes, cada um dos quais poderiam ser implementados de forma independente. Como parte desta etapa, a equipe deve manter-se perguntando a si mesma – “o que precisa ser feito” para atingir esse requisito? Eles precisam ter certeza de que o próximo nível de sub-divisão sendo criado se relacione a produtos e atividades que precisam ser mais detalhados (ver Figura 2).

\"\"

Figura 2: requisitos de alto nível fragmentados em subcategorias

Passo 3: Fragmente cada entrega principal em atividades mensuráveis ??simples ou múltiplas

O próximo passo é pegar cada entrega identificada no Passo 2 e criar atividades definidas ou produto(s) de trabalho para cada uma delas com informação relacionada ao esforço necessário para cada uma das atividades, além do risco e complexidade de cada uma.

Uma coisa que precisa ser lembrada é que, na medida em que nós descemos a estrutura EAP, as atividades devem ficar refinadas até que elas atinjam uma atividade razoável e mensurável. Agora a pergunta é “qual é a regra para uma atividade mensurável?”. Eu diria que não existe tal regra geral, e isso depende principalmente do tipo, tamanho e complexidade do projeto, processo de organização e também o nível de fragmentação com que a EAP está sendo construída.

Normalmente, uma atividade com duração de 40 horas ou até o máximo de 80 horas é considerada como uma atividade mensurável, pois essas durações são razoáveis ??o suficiente para um líder de projeto ou um gerente de projeto monitorar. As atividades mensuráveis ??assim criadas são algumas vezes denominadas como pacotes de trabalho e um dos princípios de uma EAP é que os requisitos precisam ser continuamente decompostos até chegarmos a uma lista final dos pacotes de trabalho que podem ser monitorados. É bem possível que cada entrega principal que começamos nesta etapa possa ter mais pacotes de trabalho e, em alguns casos, pode ser necessário decompor a entrega atual em mais subníveis até que um pacote de trabalho definido seja alcançado. Nesse caso, a Estrutura Analítica do Projeto vai entrar em subníveis mais profundos, o que está tudo bem, pois o objetivo de levar a cabo o exercício da EAP é garantir que cada requisito seja compreendido com sucesso até sua respectiva entrega / pacote de trabalho final (ver Figura 3).

\"\"

Figura 3: Principais Entregas divididas em pacotes mensuráveis de ??atividades / trabalho

Passo 4: Reveja os pacotes de trabalho para a integralidade da cobertura de escopo.

O passo final neste processo é o de assegurar que a numeração correta seja aplicada a cada um dos níveis, e que cada requisito está adequadamente detalhado com seus respectivos entregáveis, mapeando todos os componentes da EAP. Cada componente dentro de cada nível de uma EAP deve ser numerado conforme ele é criado.

Nesta etapa, os componentes da EAP são revisados ??de cima para baixo para garantir que o requerimento de nível superior tem seus números hierárquicos de entregáveis para cada um dos níveis claramente indicados e também garantir que nenhum dos requisitos de alto nível ou entregas intermediárias sejam perdidos no processo.

Esta etapa também garante que a implementação de componentes listados ou conclusão de ações listadas conduzirão aos resultados esperados. Esta listagem final da EAP também dá uma boa orientação para os gerentes de projeto quando eles estão criando o cronograma do projeto, pois a EAP fornece informações detalhadas sobre as atividades antecessoras e sucessoras de cada componente.

A EAP é necessária para cada projeto?

Eu diria “sim” – mas não necessariamente como um requisito obrigatório. Apenas depende das necessidades do projeto, do processo de organização e do tipo, tamanho e complexidade do projeto.

Dito isto, independente se utilizarmos a EAP como um procedimento padrão no âmbito do projeto ou não, é imperativo que os princípios da EAP sejam sempre usados por todos que estimam um projeto importante. Caso contrário, como eles iriam chegar às estimativas? Se for por mera tentativa e erro, as chances de fracasso do projeto são extremamente elevadas.

A EAP é apenas um instrumento ou uma ferramenta para decompor um grande ou hipotético escopo em um conjunto de atividades ou tarefas definíveis, estruturadas e mensuráveis ??que são associadas às respectivas entregas do projeto. Em adicional, já que uma EAP dá uma ideia do esforço necessário para cada um dos pacotes de trabalho em conjunto com o risco associado e informações de complexidade, ela também poderia ser usada como um meio para priorizar requisitos ou entregáveis, com base no esforço necessário, o risco associado, número de incógnitas e complexidade envolvidas.

Assim, a EAP é usada às vezes, por exemplo, como um ponto de conexão entre as equipes de vendas, marketing e implementação, uma vez que os auxilia na tomada de decisões de escopo rapidamente e com mais precisão, reduzindo assim o risco de perder algumas funcionalidades no produto que de outra forma teria sido mais benéfico para o cliente.

Outras Considerações

Atividade de construção de equipe:

O processo de criação de uma EAP deve ser considerado como uma atividade de construção de equipe. Para projetos de tamanho normal, uma EAP não pode ser criada por um membro da equipe sozinho. É necessária a participação de várias pessoas, quem assumam cada requisito de alto nível, discutam sobre isso com outras pessoas na equipe e, em seguida, preparem os detalhes fragmentados dos pacotes de trabalho relacionados com esse requisito específico.

Da mesma forma, os detalhes das atividades chegam aos outros membros da equipe, e a liderança do projeto consolida todas as informações de entrega recebidas e as reúne de volta a uma EAP totalmente fundida que pode ainda ser processada para as próximas etapas de cronograma e planejamento do projeto.

Não é um cronograma do projeto:

Uma EAP não é um plano de projeto ou um cronograma do projeto. Ela só fornece informações detalhadas sobre determinado escopo e sobre os resultados finais que precisam ser implementados para atingir as metas e objetivos do projeto. Deve ser entendido que a EAP ajuda a dar uma entrada precisa para a criação de um cronograma por meio da informação dos pacotes de trabalho e atividades. 

\"\"

Não entre em muitos detalhes:

As equipes de projeto geralmente assumem que, como parte da criação de uma EAP, eles precisam entrar em detalhes a partir do requisito de alto nível – o que é correto. Mas é preciso entender que este detalhamento do requisito de alto nível não deve ser levado para o mais baixo nível imaginável de detalhe, que torna a EAP complicada até para os próprios membros da equipe do projeto, dificulta o monitoramento e leva ao microgerenciamento pelos gerentes de projeto, o que não é saudável para qualquer projeto.

As equipes de projeto devem começar a pensar a respeito da EAP como um instrumento que pode ser adaptado para atender às necessidades específicas de escopo do projeto. Não há nenhuma regra fixa e rápida que diga que é preciso fragmentar um requisito em três níveis ou quatro níveis. Cabe às equipes de projeto e gerente do projeto decidirem sobre o grau em que um determinado requisito / escopo precisa ser fragmentado, a fim de torná-lo significativo e razoável para a o sucesso da implementação, do acompanhamento e da entrega. Pode haver alguns requisitos que são simples e que não levaria duas semanas para implementá-los – então, nesse caso, o próprio requisito pode ser assumido como um pacote de trabalho abrangendo toda a duração de duas semanas e a saída do produto final também é claramente entendida, desde que o requisito original defina isso com precisão.

Comunicação com o cliente e stakeholders:

Outro aspecto vital que as equipes de projeto precisam ter em mente é o de garantir que eles sempre mantenham um canal aberto de comunicação com o cliente e os vários stakeholders do projeto ao longo do processo de criação da EAP. Não se deve presumir que, uma vez que a equipe está fragmentando o escopo em elementos menores e criando uma EAP, a discussão com os stakeholders não seja necessária – o que seria um dos maiores erros.

No final das contas, como alguém poderia subdividir um escopo maior em elementos menores, a menos que ele consiga associá-lo ao produto final esperado para o projeto, que deve ser aceito pelo cliente? Fragmentar o escopo em atividades menores não vai ajudar a menos que se tenha clareza sobre a saída real desejada pelos clientes, a partir dos requisitos apresentados.

Para concluir, se um processo estruturado de EAP é seguido, as chances de um sucesso da estimativa, do planejamento e da implementação do projeto são muito maiores, o que ajudaria as equipes globais de projeto a minimizar os riscos do projeto e também evitar discussões desnecessárias de mudança do escopo, com seus consequentes atrasos e custos, que são alguns dos problemas evitáveis ??mais comuns que persistem no mundo de gerenciamento de projetos hoje.

 

 

Autor: Ambadapudi Sridhara Murthy, PMI-SP, PMP | Project Times - http://www.projecttimes.com

Artigo publicado originalmente no site Stakeholdernews