O Planejamento do Escopo do Projeto

Em aulas e palestras, quando o assunto é o planejamento do escopo do projeto, sempre recomendo o livro “Gerenciamento de Projetos – como definir e controlar o escopo do projeto”, de Carlos Magno da Silva Xavier, publicado pela editora Saraiva. Do autor destacamos esse trecho do mencionado livro:

“Quando se vai gerenciar um projeto, um grande desafio é definir claramente os produtos e/ou serviços relacionados aos seus objetivos, que, por sua vez, serão entregues ao patrocinador/cliente, estabelecendo o escopo do trabalho que deverá ser realizado pela equipe. O PMBOK sugere quais processos devem ser executados durante o gerenciamento de projetos, indicando “o que” deve ser feito, mas não “como” implementar esses processos”.

Na 5ª. edição do PMBOK, de 2013, o gerenciamento do escopo do projeto é tratado com seis processos descritos abaixo nas suas linhas gerais:

Gerenciamento do plano de escopo – é o processo que cria o plano de gerenciamento do escopo que documenta como o escopo do projeto será definido, validado e controlado.

Coletar requisitos – é o processo de determinação, documentação e gerenciamento dos requisitos do projeto e das necessidades dos stakeholders para atender os objetivos do projeto.

Definir o escopo – é o processo do desenvolvimento de uma descrição detalhada do projeto e do produto a ser criado pelo projeto.

Criar a EAP (Estrutura Analítica de Projeto) – é o processo de decomposição das entregas e do trabalho a ser realizado no projeto em componentes menores e mais facilmente gerenciáveis.

Validar o escopo – é o processo de aceitação formal das entregas do projeto.

Controlar o escopo – é o processo de monitoramento do progresso do escopo do projeto, do escopo do produto que está sendo criado pelo projeto e do gerenciamento das mudanças feitas na linha de base do escopo.

A figura 1 ilustra os quatro primeiros processos acima citados, destacando as principais entradas e saídas de cada um deles. Por uma questão de simplificação, não vou mencionar aqui –nem na figura 1 - os ativos de processos organizacionais e os fatores ambientais da empresa, mesmo sabendo que os mesmos devem ser levados em conta.

 

É importante notar que a declaração de escopo (scope statement) – saída do processo de Definir o escopo – é vital para a criação da EAP, sendo, portanto, uma entrada do processo de Criar a EAP.

Uma breve comparação do PMBOK/5ª. edição, com a versão anterior – do ponto de vista dos processos de gerenciamento do escopo do projeto - mostra que na versão mais recente foi introduzido o processo de gerenciamento do plano de escopo, que não existia na 4ª. versão. Os outros cinco processos permaneceram com os mesmos nomes e respectivas definições.

A declaração de escopo do projeto é a base para o acordo entre a equipe de gestão do projeto e o cliente, identificando o que está incluso e o que não está incluso nos trabalhos a serem desenvolvidos, os objetivos e os principais produtos intermediários do projeto. A declaração do escopo deve incluir a declaração explícita do que “não é escopo”, ou seja, declarar o que o projeto não fará e que características não serão incorporadas ao produto do projeto.

A declaração de escopo proporciona uma base documentada para futuras decisões no projeto, pois desenvolve ou confirma um entendimento comum do escopo do projeto entre os envolvidos e associa entrega de produtos (deliverables) aos objetivos do projeto, definindo sempre os atributos de medida e valor para a comprovação da realização dessas entregas. Este documento pode necessitar ser revisado ou refinado com o avanço do projeto, para refletir modificações nas necessidades do projeto. Para a elaboração da declaração de escopo a equipe de projeto, com a direção do gerente de projeto, deve considerar elaborar ou ter acesso aos seguintes itens:

·         Justificativa do projeto: contendo os objetivos de negócio que o produto do projeto pretende atender.

·         Descrição do produto do projeto: texto contendo o melhor detalhamento possível do produto do projeto.

·         Entregas: descrição das entregas intermediárias  (deliverables) do projeto.

·         Não-escopo ou exclusões: descrição, quando possível, das características do produto do projeto que não fazem parte do escopo.

·         Objetivos do projeto: retratados através de critérios quantificáveis a serem observados no projeto para que este seja considerado um sucesso. Devem ser incluídos, pelo menos, objetivos associados ao custo, prazo e qualidade.

A declaração de escopo deve apresentar as seguintes informações:

·         Descrição do produto a ser entregue pelo projeto;

·         Definição das entregas parciais e finais do projeto no ciclo de vida;

·         Definição dos critérios de sucesso das entregas quanto a prazo, custo e qualidade.

O próximo passo no tratamento do escopo do projeto é a decomposição detalhada do escopo e criação da EAP, que contempla a subdivisão do trabalho a ser realizado no projeto em componentes menores, mais facilmente gerenciáveis.

O processo de Criar a EAP recebe como entradas o plano de gerenciamento do escopo, a declaração de escopo e a documentação de requisitos, referências utilizadas para decompor o trabalho a ser realizado e obter um documento contendo o detalhamento do escopo, e assim, oferecer instrumentos para melhorar as estimativas de prazo, custo e recursos necessários, definir uma referência para medir e controlar o desempenho do projeto durante a execução, e facilitar a atribuição das responsabilidades.

A EAP (Estrutura Analítica do Projeto), ou o termo em inglês WBS (Work Breakdown Structure), é uma subdivisão lógica do projeto em vários níveis de detalhamento, até que sejam obtidos pacotes de trabalho claramente identificáveis, mensuráveis e controláveis.

A decomposição do trabalho em pacotes mais detalhados é obtida através dos seguintes passos:

·         Identificar os principais produtos intermediários, utilizando como referência as fases do ciclo de vida do projeto e incluindo, também, as atividades associadas ao gerenciamento do projeto.

·         Decidir se o nível de detalhe alcançado já permite estimativas adequadas de custos e prazos para cada componente.

·         Se necessário decompor os componentes em elementos menores e mais tangíveis que permitam clara verificação de resultados, de maneira a facilitar a avaliação de desempenho do projeto durante a execução.

·         Verificar a exatidão da decomposição, analisando a necessidade e suficiência dos itens do nível mais baixo da decomposição para a conclusão do item decomposto, devendo-se adicionar, suprimir ou revisar os itens.

·         Verificar a clareza na descrição dos itens revisando e complementando a descrição dos itens.

·         Verificar a possibilidade de estimar prazo, custo e atribuir responsabilidade a cada item, revisando até que a decomposição permita controle adequado de cada item.

A decomposição do escopo, representada na EAP, é um procedimento sistematizado que configura o projeto como um todo, caracterizando o relacionamento existente entre os elementos que formam o escopo do projeto, através de uma representação gráfica que facilita a comunicação e evidencia os componentes e as atividades necessárias para a conclusão do projeto. O processo de criação da EAP permite atribuir tarefas e responsabilidades aos pacotes de trabalho, identificar as interfaces existentes entre os vários elementos do projeto, programar e controlar o projeto, orientar o fluxo de informações e, principalmente, atuar como instrumento de comunicação e apresentação do trabalho a ser realizado no projeto, ou seja, seu escopo.

O PMBOK, na edição atual e nas anteriores, menciona as regras básicas de criação de uma EAP, incluindo alguns exemplos. Mas, a informação mais detalhada sobre esse tema está fora do PMBOK. Para conhecer as regras, dicas e procedimentos mais detalhados para elaboração de uma EAP, recomenda-se consultar o documento de 111 páginas, chamado “Practice Standard for Work Breakdown Structures – second edition” (Prática Padrão para Estruturas Analíticas de Projeto - segunda edição), publicado pelo PMI em 2006. É possível baixar o mencionado documento na Internet, bastando para isso usar o Google, fazendo uma simples pesquisa por nome. No texto em inglês, absolutamente atual, será possível encontrar um conjunto de regras de definição de uma EAP, a importância da EAP, como definir a qualidade de uma EAP, o que deve ser considerado quando se está criando uma EAP, além de exemplos e ilustrações. Boa parte do conteúdo desse documento é mencionado no livro citado no início desse post.

Vamos apresentar agora algumas dessas regras e dicas que auxiliam bastante na tarefa de criação da estrutura analítica do projeto.

Uma estrutura orientada à entregas – A EAP deve conter todas, sem faltar nenhuma, as entregas do projeto, proporcionando o entendimento sobre o que precisa ser feito. As entregas deverão ser decompostas até um nível de pacote de trabalho que permita o planejamento e o controle do trabalho necessário para a sua execução, incluindo o esforço, o prazo, a qualidade, o responsável e o custo.

O dicionário da EAP – Deve ser usado para melhor especificar as entregas e pacotes de trabalho, incluindo estimativas e uma descrição.

Evitando excessos – Para a grande maioria dos projetos, a EAP não deverá conter mais do que 3 ou 4 níveis de decomposição.

Evitando burocracia – O custo de gerenciar um pacote de trabalho não deve ser maior que 10% (ou, em casos especiais, no máximo 15%) do custo do próprio pacote de trabalho.

Subordinando um elemento Pai a vários elementos Filho – Os elementos Filho na EAP (geralmente, pacotes de trabalho) devem ser componentes de um único elemento Pai (geralmente, uma entrega). Em outras palavras, um elemento Filho (pacote de trabalho) não pode ter mais do que um elemento Pai (entrega).

Sim, mas alguém poderia questionar: - E no caso de entregas que são subdivididas em duas ou mais entregas, e essas então decompostas em pacotes de trabalho? A regra se aplica da mesma forma. Um elemento Filho (entrega X1) não pode ter mais o que um elemento Pai (entrega X). Para compreender melhor esse comentário, reveja a figura 2.

A regra dos 100% - Ao decompor uma entrega (elemento Pai) em pacotes de trabalho (elementos Filho) devemos nos certificar que todos os pacotes de trabalho reunidos representam a totalidade da entrega (elemento Pai). Nenhum pacote de trabalho dependente deverá ser esquecido.

Não usar um elemento Filho único – Não fazer a decomposição com apenas um elemento. Decompor uma entrega em apenas um pacote de trabalho equivale, na prática, a definir esse pacote de trabalho (elemento Filho único) igual a entrega (elemento Pai).

Vivendo e aprendendo – É muito válido usar modelos de EAPs de projetos similares como ferramenta auxiliar na construção de uma nova EAP. Nessa linha, recomenda-se consultar outros projetos, estudar a literatura disponível e trocar experiências com outros profissionais que passaram por situações semelhantes.