PMBOK: Técnicas para Ultrapassar o Descontrolo de Âmbito / Escopo (Scope Creep)

Controlar o âmbito do projeto é um dos processos centrais da gestão de projeto uma vez que as alterações ao plano são inevitáveis e, em certo sentido desejáveis, mas tem de existir um processo que permita o seu controlo, de forma a assegurar que todas as alterações solicitadas, e propostas de correção recomendadas, se processam no âmbito do processo integrado de controlo de alterações.

O “Scope Creep / Descontrolo do Âmbito ou Escopo” é essencialmente uma perda de foco, no cliente, e naquilo que devem ser os objetivos do projeto. Acontece quando, durante a execução do projeto, os pedidos de alteração não são devidamente controlados ou geridos. Assim, e ao contrário do que muitas pessoas pensam, o “Scope Creep” não decorre do excesso de alterações mas sim de um deficiente processo de gestão dessas mesmas alterações.

Dado que o “Scope Creep / Descontrolo do Âmbito ou Escopo” é sempre algo de indesejável em qualquer projeto a forma de o evitar passa pela aplicação correta as técnicas e os processos definidos nas metodologias de gestão de projetos, e em particular no PMBOK.

De acordo com a definição do PMBOK, o Scope Creep / Descontrolo de Âmbito consiste no adicionar funções e funcionalidades aos projeto sem avaliar previamente os efeitos dessa alteração no calendário, nos custos e nos recursos do projeto, ou adicionar funções e funcionalidades ao projeto sem a aprovação do cliente (o que na terminologia do PMBOK é conhecido como Gold-Plating). Veja aqui um artigo sobre O que é o Gold-Plating e Qual o Impacto que pode ter no Projeto).

O verdadeiro perigo por detrás do Scope Creep / Descontrolo de Âmbito é que ele não representa uma mudança de âmbito e de dimensão imediata, mas sim pequenas e sucessivas alterações graduais que, a principio, passam despercebidas e que por isso tendem a ser aceites sem uma perceção correta do seu impacto.

A melhor forma de evitar o Scope Creep / Descontrolo de Âmbito passa por definir, desde o início do projeto, qual o processo de aprovação de pedidos de alterações, não esquecendo de incluir nesse processo a obrigatoriedade de quantificar o impacto da alteração pretendida (custos, calendário, recursos, risco, ect.). Dizer a tudo que sim, pode ser uma atitude simpática e que, no inicio, cativa o cliente. No entanto não se esqueça que o seu cliente vai sempre cobrar-lhe, quando você for incapaz de entregar o que está prometido, ou quando for obrigado a pedir um reforço do financiamento porque, as alterações pedidas, e aceites sem qualquer tipo de controlo ou validação, aumentaram o âmbito/escopo daquilo que inicialmente tinha sido proposto fazer.

O processo de gestão de alterações deve ser simples e expedito, adequado à natureza concreta do projeto, e mandatório para decidir sobre todos os pedidos de alteração. Para isso é importante formalizar o processo através de um documento de projeto, e publicita-lo por todos os interessados no projeto (veja o artigo: PMBOK: 4.5 - Realizar a Gestão Integrada das Alterações).

Um eficaz processo de decisão e gestão de alterações, inicia-se sempre pela quantificação da alteração em termos de custos e benefícios para o cliente e para o projeto. Para que os custos possam ser devidamente estimados é importante que tenhamos uma EAP / WBS bem construída e, conforme é dito no PMBOK, que essa EAP / WBS seja orientada aos entregáveis do projeto. Quanto todos os requisitos estão devidamente mapeados na EAP/WBS, é mais simples avaliar qualquer pedido de alteração, relacionando-a com os requisitos definidos.

Quando algum dos interessados do projeto faz um pedido de alteração, a primeira coisa a fazer é alerta-lo para o facto de que, para que essa alteração possa ser implementada, ela necessita de obedecer a dois requisitos:

1.  Que existe um processo objetivo de análise e decisão para pedidos de alteração, que tem de obrigatoriamente ser concluído, antes que a alteração possa ser executada. Esse processo foi definido no no decurso do processo do PMBOK 4.5 - Realizar a Gestão Integrada as Alterações, e deve ser conhecido e ter sido aprovado por quem executa o projeto e pelo cliente
2. Que, conforme o que deverá estar definido nesse processo, no decurso da fase de execução do projeto, só serão implementas alterações que, após análise custo / beneficio, se revelem ser benéficas para o cliente.

Os projetos têm múltiplos Interessados (Stakeholders), alguns muito importantes, e com um peso determinante no sucesso do projeto. Contudo, a definição desde o inicio do projeto, de quem é o cliente (que pode ser um indivíduo, ou um grupo de indivíduos) do nosso projeto, é essencial para o sucesso do projeto.

Detalhando um pouco mais esses dois requisitos.

O processo de gestão de alterações deve ser adaptado à realidade do projeto, isto é, o seu grau de formalização e os níveis de decisão devem ser adaptados à dimensão e complexidade do projeto e à estrutura e cultura da organização na qual o projeto está a ser realizado. Por exemplo, processos muito complexos, que envolvam muitos interessados e/ou com muito impacto nos resultados da organização, devem ter um processo de decisão mais formal, mas o processo de decisão deve ser simples e rápido para alterações de pequeno impacto, aumentando o seu grau de formalização de forma proporcional á complexidade e ao impacto da alteração solicitada.

Esta necessidade de adaptação do processo de decisão para pedido de alterações obriga a que, para todos os pedidos de alteração, seja devidamente quantificado o respectivo impacto em termos dos planos do projeto. O gestor de projeto deve ter sempre presente que a maioria dos interessados não tem consciência concreta do impacto das alterações que solicitam, sendo responsabilidade do gestor de projeto trabalhar com quem faz a solicitação, no sentido de concretizar, em termos de custo e calendário, o impacto dessa alteração.

Quando isto é feito o cliente compreende, e abandona, muitas das solicitações iniciadas. Proceder assim permite ao gestor de projeto dizer não de uma forma elegante, não criando mau ambiente entre o gestor de projeto e as partes interessadas que são relevantes para o sucesso do projeto.

A identificação concreta do “cliente do projeto” é essencial para que se limite o foco do projeto. Depois de sabermos quem são os nossos clientes, podemos começar a conversar com eles, a perceber as ideias que têm em relação ao produto ou serviço que o projeto irá criar, para daí extrair o conjunto de funcionalidades que depois irão ser transformadas, pela equipa de projeto, em requisitos.

Como alguém disse em tempos “O Scope Creep é um assassino dos projetos. Temos que o matar antes do nosso projeto começar.

Clique aqui para saber mais sobre esta anomalia que está na base de muitos dos problemas com que os projetos se deparam.

Grp2ALL