PMBOK v5: 5.6 Controlar Âmbito / Escopo do Projeto


O processo de controlo do âmbito tem por objetivo influenciar os fatores que criam alterações ao âmbito do projeto, controlando o impacto dessas alterações. O controlo de âmbito assegura que todas as alterações solicitadas e propostas de correção recomendadas são feitas e processadas no âmbito do processo integrado de controlo de alterações.

As alterações são inevitáveis, logo tem que existir um processo que permita o seu controlo. Alterações não controladas são referidas na terminologia de gestão de projetos como “Scope Creep / Descontrolo de Âmbito ou Escopo”.



A ferramenta usada no controlo de âmbito é a análise da variância. A medição sistemática do desempenho do projeto é usada para avaliar a magnitude da variação. Um importante aspeto do controlo do âmbito do projeto inclui a determinação da causa da variância em relação à linha base de âmbito e a decisão sobre a necessidade de ações corretivas.

Na Declaração de Âmbito / Escopo deve ser definido, com exatidão, o produto ou serviço que deve ser feito para responder às necessidades do cliente. Mas dela deve igualmente constar aquilo que não será feito.

A Declaração de Âmbito / Escopo define os limites do que deve ser feito. Depois de aprovada é um instrumento fundamental para a realização das estimativas de prazo e custo e para a criação das linhas base do projeto. É ela que garante que o projeto inclui todo o trabalho que é necessário, e somente o trabalho necessário, para gerir o projeto e para criar o produto ou serviço em causa.

No entanto todos os planos estão sujeitos a alterações (porque se altera o contexto, porque temos necessidade de introduzir conhecimento entretanto adquirido, etc.), as quais devem ser controladas no âmbito dos processos de gestão de alterações. O “Scope Creep / Descontrolo do Âmbito ou Escopo” acontece quando os projetos são sujeitos, durante a execução, a demasiados pedidos de alterações e quando estes não são devidamente controlados e geridos. O “Scope Creep” é essencialmente uma perda de foco, no cliente e naquilo que devem ser os objetivos do nosso projeto.

Dependendo da razão porque ocorrem, as alterações podem ser benéficas ou prejudiciais. Alterações prejudiciais são as que tem origem em deficiências de planeamento, por exemplo necessidade de incluir novas atividades que não tinham sido identificadas ou, num processo de coleta de requisitos, efetuado de forma incompleta. Alterações benéficas são aquelas que decorrem da necessidade de incorporar no projeto novo conhecimento entretanto obtido ou que visam adaptar o projeto a mudanças do contexto entretanto acontecidas.

Se as alterações podem ser benéficas ou prejudiciais já o “Scope Creep” é sempre um problema. No entanto, ao contrário do que frequentemente é dito o “Scope Creepnão decorre do excesso das alterações mas sim de um deficiente processo de gestão das mesmas o qual não consegue fazer a triagem entre os pedidos de alteração que devem ser implementados e os que devem ser recusados.

Alterações são necessárias e serão sempre pedidas, no entanto se os pedidos de alteração fugirem ao controlo o resultado serão derrapagens nos prazos e nos custo, um produto sem qualidade, um cliente insatisfeito e nenhuma compensação ou reconhecimento pelo esforço efetuado.

Existe uma máxima que o PMBOK defende. Qualquer alteração introduzida no projeto deve ser benéfica para o cliente do projeto. Quando esta máxima não é respeitada caímos no “Scope Creep / Descontrolo do Âmbito ou Escopo”.

O Processo do PMBOK, Controlo do Âmbito / Escopo do Projeto tem o seguinte diagrama de fluxo de dados:
 

SCOPE CREEP: Aspetos a Reter ou Dicas Úteis:
  • Evite os “Achismos”. Baseie-se em factos e não em suposições. Fale com o seu cliente, ouça-o e anote as suas expetativas. Eu acho que... Não é a melhor forma de gerir projetos, e quando a coisa acaba mal geralmente termina em Eu tinha quase a certeza que...
  • Não aceite prazos antes de avaliar o que tem de ser feito. Não raramente, a primeira coisa que o promotor diz, ao gestor de projeto que acaba de nomear, é a data em que o projeto tem de ficar concluído. Salvo quando existem razões que o justifiquem, questione sempre e não se comprometa antes de analisar com mais de detalhe o que tem de ser feito;
  • Formalize os documentos mais importantes do projeto e obtenha a aprovação do promotor e do cliente. Por menor que seja o seu projeto, ele precisa de um acordo mínimo;
  • Se o âmbito / escopo se alterar, avise as partes interessadas sobre as novas linha base de prazo e custo;
  • Crie, junto com o seu cliente, uma lista de prioridades. Se ela mudar, avise-o sobre prazo e custo.
  • Não tenha medo de informar. Por exemplo, informe que aquele campo adicionado à última da hora ao formulário de criação de encomendas obriga a alterar o modelo de dados e que, por isso, irá demorar 20 horas para ser criado e testado;
  • Lembre-se: não é preciso usar metodologias complexas para evitar problemas. A maior parte dos problemas, conflitos e mal-entendidos evitam-se com um processo de comunicação eficaz e eficiente;
  • Como gestor do projeto aprenda a dizer não.
 
 




Postagens mais visitadas deste blog

PMBOK v6: 7.4 Controlar os Custos do Projeto

PMBOK v6: 5.2 Coletar os Requisitos