Compartilhar!

Uma WBS bem elaborada através de técnicas simples, porém aprimoradas, pode ser a chave para seu projeto com escopo definido.

Esse tema já vem sendo comentado há anos pelos mais diferentes especialistas e esmiuçada através das mais variadas formas. Apesar de parecer um assunto batido, ainda parece ser desconhecido por muitos profissionais de gerenciamento de projetos, iniciantes ou especialistas.

A gestão de projetos vem avançando bastante e muitos temas alcançaram patamares elevados de entendimento e aplicação. Mas alguns, tão básicos como uma WBS, ainda carecem em alguns casos de um aprofundamento.

Vamos então juntar opiniões, sugestões e experiências para aplicar de forma descomplicada as melhores técnicas na confecção de uma WBS. Com isso proporcionaremos uma melhor compreensão do escopo para contribuir com o sucesso dos projetos.

WBS e as entregas menores e mais gerenciáveis

Em meu artigo Gestão de Escopo me referi à WBS como a ferramenta mais importante da gestão de escopo. A tradução de WBS ou Work breakdown Structure para português é EAP ou Estrutura Analítica do Projeto. No entanto, em minha opinião essa tradução não expressa a amplitude desta ferramenta.

Através de uma WBS bem definida é possível estruturar e comunicar adequadamente todo o escopo do produto e do projeto.

Segundo o Guia PMBOK® a WBS é a representação gráfica do escopo do produto e do projeto, subdivididos em entregas menores e mais gerenciáveis. Seguir essa definição é importante para manter o nível adequado de informação e a utilidade da ferramenta para o gerenciamento.

A subdivisão do projeto em entregas vai até o nível de pacote de trabalho. A subdivisão do pacote de trabalho não é mais em entregas menores, mas sim em atividades, conectando-se ao cronograma.

Portanto, para ser eficiente e útil uma WBS deve conter tudo o que é preciso para o entendimento do escopo, sem deixar de ser simples. A subdivisão do escopo tem que produzir entregas MENORES e MAIS GERENCIÁVEIS.

Representando todo o escopo do produto e do projeto

Há um entendimento comum que se está na WBS faz parte do projeto, caso contrário é exclusão de escopo. Isso é verdade, desde que a estrutura contenha, mesmo que resumidamente, TUDO o que o projeto precisa que seja feito. Ela deve representar tudo o que vai ser entregue na forma de produto ou serviço.

Portanto é importante que a WBS consiga representar as partes que irão compor a entrega final do projeto. É o escopo do produto. Mas também tudo o que precise ser feito para sua conclusão e será entregue de alguma forma. É o escopo do projeto.

No entanto, uma das entregas mais esquecidas, mesmo por especialistas, na hora de estruturar uma WBS é a própria gestão de projetos. Termo de Abertura, Plano do Projeto, relatórios de status, atas de aceitação, aprovações de mudanças, são entregas da gestão do projeto. Junto com o termo de encerramento e outros documentos da finalização compõe as entregas absolutamente necessárias para uma boa gestão do projeto.

A inclusão da gestão do projeto na WBS proporciona ainda a visibilidade e inclusão dessas atividades em outras áreas que poderiam ser esquecidos. Desta forma, para prover todas essas entregas de gestão são necessários recursos, tempo, despesas etc. A visão dessas entregas faz com que as tarefas e recursos sejam planejados, assim como seus respectivos custos.

Na prática o que acontece na maioria das vezes é que tudo isso é negligenciado. Tanto as atividades, quanto a alocação de recursos e apontamento dos custos para o gerenciamento são simplesmente esquecidos. Desta forma, o resultado do projeto fica comprometido pela falta destas atividades nas estimativas do projeto.

A WBS e o método da decomposição

O método apresentado pelo PMI para quebrar o projeto em entregas menores é a decomposição. Além da subdivisão do escopo há também modelos que proporcionam melhores resultados, facilitando o entendimento do projeto e a gestão.

Os modelos mais conhecidos para o desenho da WBS são por entrega, por fase e por equipe:

O modelo mais comum é a WBS por entrega. Nela cada uma das caixinhas representa uma parte do produto e do esforço para sua execução. Mas todos os modelos podem ser aplicados conforme o tipo do projeto e as necessidades de gerenciamento.

Principais características de uma WBS

Uma das principais características, e normalmente razão de muitos erros, é que a WBS não é um fluxo. Os relacionamentos entre as entregas representam apenas as subdivisões e não (necessariamente) a sequência de execução.

Outra característica importante é o fato dela ser atemporal. Ou seja, não representa o tempo do projeto, deixando essa função e o sequenciamento da execução para o cronograma.

Ainda que um dos modelos represente a separação das entregas por fases, a característica principal é a divisão do trabalho e não a sequência propriamente dita.

O modelo de WBS por equipe, embora menos comum, pode ser aplicado em algumas situações mais específicas, onde o direcionamento das entregas deve ser feito para grupos distintos, tendo cada um com suas respectivas responsabilidades.

Independente do modelo adotado, a gestão do projeto deve estar sempre presente para garantir que suas entregas sejam compreendidas, calculadas e medidas quanto à sua eficiência.

Dividindo corretamente as entregas

Um conceito bastante conhecido nos meios de gerenciamento de projetos é a Regra 8 ou 80. Ela define que cada pacote de trabalho deve consumir entre 8 horas e 80 horas para ser produzido. No entanto, essa regra pode ser genérica demais. Essa relação, na verdade, depende muito do tipo de projeto, das características do produto e da duração do cronograma.

O uso do bom senso é sempre a melhor regra, lembrando que você terá que gerenciar tudo isso depois.

Uma boa prática é utilizar um importante conceito Ágil, formatando pacotes de trabalho que caibam entre os pontos de medição. Assim, cada pacote de trabalho se pareceria com uma sprint, com entregas coerentes com a duração total do projeto.

Ou seja, para um projeto de seis meses a um ano com necessidade de medição e comunicação do andamento semanal. Nesse caso o melhor é quebra a WBS em pacotes que demandem no máximo 40 horas. Para projetos mais longos e com medição e comunicação mensal, os pacotes podem ter 80 horas ou até mais. Já para os projetos muito pequenos é possível trabalhar com pacotes menores, dede que não comprometam a gestão.

O ideal é ajustar o tamanho dos pacotes aos períodos de análise do andamento do projeto. A subdivisão deve ser feita de tal forma que eles sejam iniciados e terminados dentro de um mesmo período. Assim, é possível ter medidas melhores e evitar que os indicadores de desempenho e estimativas de término sejam apenas chutes.

Projetos muito complexos e com muitas entregas normalmente são subdivididos por fases. Neste caso é aconselhável tornar cada fase um projeto independente dentro de um programa, facilitando a gestão e o controle.

Quando menos é mais

Há várias sugestões sobre como desenvolver uma WBS que podem ser encontrados facilmente em livros e blogs. Todos as sugestões podem ser úteis na hora de quebrar o projeto em entregas menores e mais gerenciáveis. Mas a minha dica adicional deve sempre estar presenta não apenas na WBS, mas em toda boa gestão de projeto. Estou me referindo à simplicidade. Como mencionei no meu post Gestão de Escopo, foi comprovado por estudos científicos que nosso cérebro é limitado e só consegue lidar com quatro ou cinco coisas simultaneamente. Assim, de nada adianta uma WBS muito detalhada, com várias entregas simultâneas, se isso dificultar o monitoramento e controle.

Mantenha apenas as divisões necessárias. Cinco entregas principais de produto mais uma de gestão são suficientes para a maioria dos projetos. Decomponha cada uma destas entregas principais em no máximo três ou quatro pacotes de trabalho e pronto, todo seu projeto estará coberto.

Baixe um modelo padrão de WBS para ser preenchido com post its.

Agora quero saber sua opinião

Espero que você já esteja convencido da importância de uma WBS para a boa gestão de projetos. Ela é um excelente complemento à declaração de escopo, acrescentando um componente visual aos registros em textos.

Que tipo de estrutura mais se adapta aos seus projetos, por entregas por fases, e por equipes?

Deixe seu comentário e compartilhe com a gente suas experiências com essa importante ferramenta da gestão de escopo de projeto.

Artigo publicado originalmente em 03 de setembro de 2017

Bons Projetos e bons negócios.

Paulo Mei

Compartilhar!