Escopo: uma pequena introdução



O escopo de um projeto poderia ser definido de uma forma simples como o que deverá ser entregue ao término do projeto. Só que isso é muito simplório. Na verdade o escopo, por diversas vezes, tem que definir o que não deve ser feito também.

Apesar de curioso, por diversas vezes nem mesmo o cliente sabe exatamente o que ele deseja. Então tentar entender o que o cliente deseja e não só o que ele está dizendo o que quer é muitas vezes a chave para definir o escopo do projeto.

Em um projeto existem normalmente dois escopos: o escopo do produto e o escopo do projeto. O primeiro tem a ver diretamente com o que deve ser entregue; o segundo está diretamente relacionado com o que deve ser feito para que o escopo do produto seja totalmente alcançado, ou em outras palavras, as atividades que irão serão executadas para que o produto final seja entregue dentro dos requisitos do cliente.

Uma dos processos mais difíceis de ser evitado seja talvez o chamado GOLD PLATING. Ou seja, a promessa de entrega de uma funcionalidade que não estava prevista. Isso, além de diminuir a rentabilidade do projeto é um constante fato gerador de insatisfação por parte do cliente porque além de "não custar nada" é freqüentemente motivo para atraso no cronograma.

E a forma de evitar os GOLD PLATING é conscientizar a equipe, primeiramente sobre o real escopo do projeto. E também mostrar a eles sobre os riscos e eventuais penalidades que o projeto pode sofrer em função dessa prática.

É comum que dúvidas sobre o escopo surjam constantemente durante o projeto. Uma das saídas também dessa etapa de definição do escopo do projeto é uma que eu particularmente considero uma das mais importantes: o gerenciamento do controle do escopo.

Um bom processo de controle do escopo do projeto promove não só o sistema de controle de mudança como também um processo de verificação do que é ou não é parte do escopo do projeto. Porque uma alteração no escopo do projeto promove conseqüentemente uma alteração na WBS do projeto, uma provável mudança na sua linha base. Isso pode trazer conseqüências na área de recursos humanos (contratação de mão de obra especializada para atender a essa nova demanda), qualidade, tempo (linha base) e conseqüentemente custo.

De uma forma resumida, se um projeto começa mal ele não precisa necessariamente acabar mau. Mas que o processo de gerenciamento é muito mais "doloroso", isso não resta dúvida. E todo projeto começa pela área de escopo, certo!

Autor: Carlos Bassalo


Artigos Relacionados


Uma VisÃo Geral Sobre Projetos

Cronoanálise E O Seis Sigma.

Scrum - Manisfesto Ágil

Softteria - Software Para Gerenciamento De Projetos

A Teoria Das Ideias De PlatÃo Aplicada Ao NÍvel De DefiniÇÃo Dos Componentes De Um Projeto

A Satisfação Sob O Ponto De Vista Do Ambiente De Projetos.

O Princípio Da Unicidade Sindical E A Base Territorial Mínima