Compreendendo o escopo, e o não escopo do projeto

Quando falamos em gerenciamento de projetos, a primeira coisa que fazemos é definir o que é um projeto. O PMI (Project Management Institute) define projeto como um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo (Guia PMBOK^® 5ª Edição, página 3). Outras instituições e organizações variam essa definição em torno do mesmo ponto: a criação de um produto, serviço ou resultado. E como tornamos tangível a definição desse produto, serviço ou resultado? A resposta a essa pergunta é fácil, simples, direta e conhecida por todos: através da definição do escopo do projeto.

A definição do escopo começa pela descrição e análise dos requisitos do projeto, passa pelo seu detalhamento, formalização e gerenciamento de mudanças, sendo acompanhado e controlado até o seu encerramento. É dever do gerente e de toda a equipe de gerenciamento do projeto definir, acompanhar e controlar o desenvolvimento, gerenciar as mudanças e garantir a execução de todo o escopo, e somente dele, para garantir o sucesso do projeto.

Até aqui, nenhuma novidade, não é? Todo mundo sabe que é preciso gerenciar o escopo do projeto, e conhece as ferramentas e processos para isso. Por isso, quero falar sobre outros assuntos relacionados ao escopo, que nem sempre são citados e, quando são, nem sempre com a devida atenção. Tão importante quando definir o escopo de um projeto é definir o não escopo. Isso mesmo! É preciso definir o que não faz parte do escopo, de forma clara e precisa, e formalizar nos documentos do projeto.

Nesse ponto você pode pensar: se defini o que é o escopo do projeto (declaração clara e detalhada do que será entregue pelo projeto), por exclusão, não defini também o que não é escopo? A resposta é: NÃO! E esse é um dos maiores perigos e fonte de problemas no gerenciamento de um projeto. Cuidado para não cair nessa armadilha!

A falta de definição clara e formal, no início do projeto, do que não faz parte do escopo causa uma série de problemas na sua execução. Esses problemas podem ser os mais diversos, como: dúvidas do gerente de projetos e sua equipe quanto ao trabalho a ser realizado, litígios que podem inviabilizar a sua execução, etc.

Para facilitar o entendimento, vou dar um exemplo. Você esta prestes a iniciar um projeto de construção de uma casa e menciona, na sua Declaração de Escopo, a pintura interna e externa da casa como uma de suas entregas. Você acha que esta definição é suficiente? É claro que não, você vai me responder. É preciso definir as cores que serão utilizadas, tanto dentro quanto fora da casa. E isso é suficiente? Ainda não. É necessário definir o tipo de tinta e a forma de aplicação. Então, podemos dizer que uma boa definição para o escopo dessa entrega do projeto seria: pintura interna na cor branca para o teto e areia para as paredes, em tinta acrílica, aplicada com rolo e recortes a pincel, e na cor gelo nas paredes externas, em tinta óleo, aplicada com rolo. Esta definição é suficiente? Aparentemente sim, mas reflita um pouco. Há alguma coisa que você não pretende fazer que pode causar dúvida durante a execução do projeto? Acredito que sua reposta seja: sim, talvez até existam várias. Por exemplo:

• não pintar muros, pisos e ferragens (portas, portões, janelas, etc.);
• não aplicar acabamentos diferenciados como texturas e tintas especiais;
• não fornecer/montar andaimes para acesso em altura;
• não refazer a pintura caso seja danificada por terceiros, entre outras.

Complexo? Sim, e parece que quanto mais você pensa, mais exceções aparecem. E esse é um exemplo simples. Imagine um megaprojeto repleto de complexidade e interfaces.

Convencido da importância de definir o não escopo? Então vamos falar de alguns conceitos que ficam entre o escopo e o não escopo e auxiliam na sua definição: as premissas, restrições e limites de bateria.

É claro e natural que ao estudarmos os requisitos de um projeto e detalharmos seu escopo (e agora que você está convencido, o não escopo), surjam dúvidas e indefinições. Muitas delas serão discutidas e esclarecidas com o cliente. Porém, sempre sobrarão algumas que, com o nível de conhecimento que se tem à época, não poderão ser eliminadas. Para esses casos utilizamos as premissas e restrições.

Premissas são hipóteses, definições o mais próximas da realidade quanto possível, que o gerente do projeto assume como verdadeiras na falta de informações precisas sobre um determinado assunto. As premissas permitem que as definições iniciais do projeto sejam elaboradas e o planejamento seja continuado.

Vamos voltar ao nosso exemplo. Se você perguntar ao cliente a cor da tinta a ser utilizada, mas ele não souber responder durante a definição do escopo, não deixe esse ponto em aberto. Adote uma premissa e a formalize nos documentos do projeto. Defina a utilização de tinta acrílica na cor branca, por exemplo. Mais tarde, durante a execução do projeto, se o cliente quiser utilizar tinta azul acetinada, você poderá caracterizar uma mudança de escopo e incluir a diferença de custo no orçamento do projeto.

Por sua vez, as restrições são limitações impostas ao gerente do projeto e sua equipe, pelo cliente/dono do projeto ou fatores técnicos da sua execução, que devem ser registradas para evitar discussões futuras.

No nosso exemplo, uma restrição ao projeto pode ser a impossibilidade de trabalho aos finais de semana por conta de regras do condomínio onde a casa será construída. Essa restrição deve ser bem documentada, pois é base para o planejamento e orçamento do projeto. Se, por algum motivo, a restrição deixar de existir e o cliente solicitar o trabalho aos sábados, se caracterizará uma mudança de escopo, permitindo ajustes de custo e prazo.

Finalmente chegamos ao limite de bateria, que define os contornos do escopo do fornecedor de um projeto. Agora você vai me perguntar: se defini o que é escopo, e o que não é, além de formalizar as premissas e restrições do meu projeto, não defini os seus limites de bateria? A resposta é: não, necessariamente. Quando gerenciamos grandes projetos, com várias interfaces e múltiplos fornecedores, é importantíssimo definir os limites de bateria entre as interfaces e fornecedores.

Imagine que, no nosso exemplo, a casa a ser construída é muito grande e o prazo para sua execução é curto. Nessa situação você se vê forçado a contratar duas equipes de pintura: uma para a parte externa e outra, para interna. Para você entender o conceito de limite de bateria, responda à seguinte pergunta: quem pinta as portas e as janelas? Depende do limite de bateria definido no projeto. Se o limite de bateria não estiver definido, as portas e janelas podem ser pintadas por dentro por uma equipe e por fora, pela outra, diminuindo a qualidade do serviço; ou podem ser pintadas duas vezes; ou pior, podem não ser pintadas por nenhuma delas, o que forçaria você a contratar outra equipe para pinta-las.

Mas, e se depois de tudo isso o cliente pede para que você execute uma tarefa ou faça uma entrega que não está no escopo do projeto? Bom, aí você vai precisar definir uma mudança de escopo e gerencia-la durante sua execução. Mas isso já é assunto para outra conversa!

Sobre o Colunista:

Alexandre Zoppa, PMP, SpP, com mais de 15 anos de experiência em gerenciamento, é engenheiro eletrônico formado pela Escola de Engenharia Mauá, pós-graduado em Administração de Empresas pela FAAP e com aperfeiçoamento em Gerenciamento de Projetos pela George Washington University. É instrutor em Gerenciamento de Projetos e colunista do PMKB. Hoje atua como coordenador de planejamento Arcadis Logos. Já foi PMO na Ambev e Líder de Planejamento na ABB S.A., entre outras. E-mail de contato: alexandrezoppa@yahoo.com.br; Skype: azoppa

Se você tem comentários, sugestões ou alguma dúvida que gostaria de esclarecer, aproveite o espaço a seguir.