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

Comentários

Postagens mais visitadas deste blog

9 Programas de Software Grátis para Gestão de Projetos

PMBOK: Ferramentas e Técnicas - Estimar Custos do Projeto

Como Fazer o Plano de Comunicação do Projeto