Por Paulo Mei

Olá, como vai? Você com certeza já sabe que esse ano teremos um Guia PMBOK® novo. Talvez até já tenha lido meu post do ano passado onde comentei sobre as principais mudanças esperadas. Se ainda não leu acesse agora o artigo “O que esperar do Guia PMBOK® 6ª Edição”. A partir de hoje vou fazer uma série de publicações falando sobre cada uma das áreas de conhecimento, tratando não apenas as mudanças, mas também os aspectos mais peculiares e, é claro, trazendo uma visão descomplicada de como aplicar os processos e as melhores técnicas de cada assunto para obter sucesso nos seus projetos.

E pra começar vamos falar sobre Escopo, essa área de conhecimento que toma uma dimensão ainda maior no contexto waterfall, onde o planejamento de cada um dos pontos da gestão de projetos se desdobra a partir de uma boa definição do que será produzido.

O escopo no contexto waterfall toma uma dimensão ainda maior

Um erro comum que tomou força a partir da proliferação dos métodos ágeis é achar que nos métodos derivados do waterfall todos os detalhes precisam estar 100% definidos antes de se iniciar o projeto. Quem ainda acha isso não conhece as características do waterfall e nem do agile, e nem mesmo ouviu falar do Roling Wave Planing, ou planejamento em ondas sucessivas, onde os detalhes são incluídos no planejamento em momentos oportunos, conforme as informações são disponibilizadas ou acessíveis. Um exemplo típico é o da construção civil. Para um bom planejamento é preciso ter a planta do imóvel a ser construído para o cálculo estrutural. Importante saber o número de andares, tipo de construção, quantidade e divisão dos cômodos etc. Mas dá para se fazer um ótimo planejamento desse projeto mesmo sem saber ainda que revestimento será utilizado, que tipo de piso, quantas tomadas, que padrão de janelas etc. É possível começar o projeto e ir definindo os detalhes conforme a obra avança, incluído as informações no planejamento.

É um erro achar que todos os detalhes precisam estar 100% definidos antes de se iniciar o projeto

A ferramenta mais importante da gestão de escopo é, sem dúvida alguma, a WBS ou Work breakdown Structure. Em português a tradução ficou EAP ou Estrutura Analítica do Projeto, e não expressa, em minha opinião, tudo o que essa ferramenta representa. Trata-se de uma visão estruturada do escopo do projeto, subdividindo o produto ou serviço em entregas menores e mais gerenciáveis. Essa definição é importante para a sugestão de simplificação que quero falar. A subdivisão tem que produzir entregas MENORES e MAIS GERENCIÁVEIS.

WBS é a quebra do projeto em entregas menores e mais gerenciáveis

Ou seja, não adianta ser apenas menor se a quantidade de entregas não facilitar a boa gestão e o controle do que está sendo produzido. Além disso estudos de neurociência indicam que nosso cérebro só consegue lidar com quatro ou cinco coisas simultaneamente. Portanto se sua WBS estiver repleta de entregas sendo executadas ao mesmo tempo, pode ter certeza que alguma coisa vai escapar de seu controle. Fique com no máximo cinco entregas principais, cada uma com três ou quatro pacotes de trabalho que, com certeza já basta para a maioria dos casos. A estas você pode adicionar mais uma, que é justamente a entrega gestão do projeto, com os pacotes de trabalho representando o ciclo de vida com os ritos indispensáveis como Termo de Abertura, Plano do Projeto, ações de Monitoramento e Controle, gestão de mudanças, aceitações e finalização do projeto.

Clique aqui e baixe um modelo padrão de WBS para ser preenchido com post its.

Para projetos maiores e mais complexos, que não se encaixem na estrutura enxuta que acabei de sugerir, aconselho que o escopo seja quebrado em projetos menores e acomodados em um programa. Muitos projetos grandes que são executados em fases podem ter cada fase tratada como um projeto separado, propiciando aumento de foco naquilo que está sendo executado no momento e facilitando o controle, uma vez que serão menos entregas para gerenciar. No caso de projetos muito complexos, daqueles com muitas entregas executadas simultaneamente, tente encontrar uma maneira de quebrá-los em dois ou mais projetos juntando as entregas por similaridade, equipe dedicada, área de implantação etc. Por exemplo, para um grande projeto de implantação de ERP, uma possibilidade é quebrar por módulo do sistema. Uma grande reforma pode ser quebrada por área ou departamento e assim por diante. Colocando esses projetos em um programa, o gerente do projeto será o mesmo, porém cada um poderá ter sua equipe, com alguns ou todos os membros exclusivos, alguns stakeholders podem ter interesses no programa como um todo, mas outros podem focar em um projeto específico, assim todos se beneficiam dessa divisão de escopo, tornando cada projeto mais gerenciável e com mais chances de sucesso.

Uma questão sempre muito esquecida quando se fala em escopo é a gestão de requisitos. Primeiro é preciso entender que quem define os requisitos são os stakeholder. O time de engenharia pode sugerir características e funcionalidades, mas são os principais interessados no produto ou serviço do projeto quem de fato assina embaixo, formalizando o que vai fazer parte do projeto ou não.

Quem define os requisitos são os stakeholders

Para não se perder, o bom gerente de projeto precisa criar alguma forma de rastreabilidade entre os requisitos, seus demandantes, as entregas ou pacotes de trabalho que irão produzi-los, bem como os padrões de qualidade, as restrições, premissas e riscos envolvidos na sua execução. No momento da entrega é importante que o mesmo stakeholder que demandou algum requisito ou alguém formalmente delegado por ele participe da aceitação, verificando as especificações, atestando a qualidade e formalizando a entrega para que não haja dúvida quanto a sua finalização.

Como vê, a gestão do escopo é fundamental. No contexto ágil o escopo vai sendo definido e produzido de forma iterativa e as partes finalizadas vão sendo colocadas em funcionamento. Já no contexto waterfall, embora os detalhes possam ser definidos ao longo do projeto, o produto só entra em funcionamento após a finalização do mesmo. Mas o que é mais importante entender é que independente do escopo, se é um serviço ou um produto, o fundamental é que esteja alinhado com as expectativas de valor por parte dos clientes e que produza os resultados de negócio esperados pelos patrocinadores, agradando a todos os principais interessados.

O mais importante é que o escopo esteja alinhado com os resultados de negócio esperados

Você tem gerenciado bem o escopo de seus projetos? Aplica corretamente e oportunamente os conceitos de escopo iterativo dos métodos ágeis e planejamento em ondas sucessivas dos métodos waterfall? Consegue discernir e aplicar corretamente cada um dos métodos, entendendo que são ferramentas diferentes para necessidades distintas?

Bons Projetos!

Sobre o autor

Paulo Mei, MBA, PMP. Consultor, instrutor e professor em gestão de projetos e portfólios, além de membro da diretoria do PMI de São Paulo atuando no Conselho de Governança. Graduado em Administração de Empresas com ênfase em finanças, MBA pela FAAP e mestrando em Empreendedorismo pela FEA/USP. Foi responsável nos últimos vinte anos por grandes projetos no Brasil e no exterior (projetos offshore) e pela implantação de Escritórios de Projetos para empresas de vários segmentos.

É autor dos livros Gerenciamento da Integração em Projetos (Elsevier; 2013) e PM Mind Map® – A gestão descomplicada de projetos (Brasport; 2015).

Contato: paulomei@paulomei.com.br ou contato@pmmindmap.com.br

Gostou?? Compartilhe!!