PMBOK v5: 5.6 Controlar Âmbito / Escopo do Projeto
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 Creep” nã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:
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 Creep” nã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.
- Entradas
- Plano de Gestão do Projeto
- Informações sobre o Desempenho do Trabalho
- Documentação de Requisitos
- Matriz de Rastreabilidade dos Requisitos
- Ativos de Processos Organizacionais
- Ferramentas e Técnica
- Análise de Variância
- Resultado
- Medições de Desempenho do Trabalho
- Atualizações dos Ativos de Processos Organizacionais
- Pedidos de Alteração
- Atualizações do Plano de Gestão do Projeto
- Atualizações dos Documentos do Projeto.
