Proteja seu projeto contra Scope Creep


projeto-scope-creep

Eu recentemente estava revisando o projeto de outra gerente de projetos e notei que o documento de requisitos não tinha sido aprovado.

“Quando você está espera ter os requisitos aprovados?”, eu perguntei a ela.

“Oh, nós estamos apenas atualizando-os à medida que avançamos”, respondeu ela. “O cliente não sabe realmente o que ele quer, então estamos sendo flexíveis.”

Isso disparou o alarme comigo. Há uma diferença entre ser flexível e criar problemas para si e para a equipe. Deve haver um ponto no projeto em que você cria uma linha de base para o que é necessário e começa a construí-lo. Claro, você pode fazer mudanças depois isso, mas você tem que saber de onde está partindo. Caso contrário, como você vai saber se você já terminou?

Mudanças que escorregam para dentro do projeto, sem ser devidamente gerenciadas, são o que levam a aumento gradual do escopo (Scope Creep). Isto é, quando o escopo do seu projeto se expande sem ser controlado. Aumento do escopo significa trabalho extra para sua equipe, provavelmente sem expectativa de dinheiro extra para o projeto ou tempo extra para realizar as tarefas. Então, todo mundo se carrega mais, e porque você acomodou uma pequena mudança no projeto, o cliente acha que é não há problema em sugerir mais um par. Chega um ponto em que você não pode entregar a tempo e seu projeto nunca termina, porque há sempre “apenas mais um” ajuste ou alteração a fazer.

Isso pode parecer gerenciável no início de um projeto, mas é sempre mais fácil (e mais rentável) fazer alterações naquele momento. As dificuldades realmente começam quando você avança mais no projeto e os entregáveis estão quase concluídos. Fazer uma mudança neste momento pode ser muito caro, pois envolve uma grande quantidade de retrabalho.

Aqui estão algumas maneiras pelas quais você pode proteger o seu projeto contra o aumento do escopo.

Defina os requisitos

Você tem que começar com um conjunto detalhado de requisitos. Use um software de monitoramento de tarefas para controlar cada um dos requisitos. Você terá que gastar um pouco de tempo de brainstorming para capturar as diferentes necessidades de diferentes stakeholders, e não se esqueça de envolver sua equipe nisto também. Quanto mais informações você obtiver neste ponto, é menos provável que tarefas importantes serão esquecidas. Em seguida, você pode priorizar os requisitos e certificar-se de que você pode conseguir tudo no prazo desejado.

Quando você tiver uma lista final, obtenha de seu cliente a aprovação formal. Explique que eles podem fazer alterações, mas estas também serão controladas formalmente.

Use um sistema de controle de mudanças

Use um sistema de gestão de mudanças de modo que você possa controlar as alterações. Seria raro ver um projeto que não tenha ao menos algumas mudanças, então é melhor você estar preparado com o seu processo de controle de mudanças para quando você precisar dele!

Registre cada mudança conforme ela chega, avalie seu impacto e, em seguida, obtenha a aprovação ou rejeição por seu patrocinador ou cliente, com base no impacto e como aquela mudança se encaixa com o resto do trabalho do projeto.

Não exceda os requerimentos (Gold Plating)

Pode ser tentador para as equipes de projeto adicionar funcionalidade extras, mesmo se o cliente não as pediu. Este é particularmente o caso com projetos de software. Se os desenvolvedores encontram recursos interessantes que podem construir, eles poderiam ir em frente na implementação e apresentá-los para o cliente como um benefício extra adicionado.

Em princípio, isto soa bem, mas na realidade leva a equipe longe de satisfazer os requisitos essenciais e aumenta os custos do projeto. E o cliente pode não querer este recurso extra de qualquer maneira. Se sua equipe identificar alguma oportunidade fora dos requisitos, converse com o cliente sobre se eles querem que você a inclua no projeto.

Eduque sua equipe

Certifique-se de que sua equipe conhece o processo de gestão de mudanças para que não sejam pegos de surpresa, se um stakeholder se aproxima deles diretamente e pede uma mudança. Nenhum membro da equipe deve jamais aprovar uma mudança ou dizer sim a um novo requisito sem que tenha passado pelo processo de mudança em primeiro lugar.

Converse com sua equipe sobre como eles devem lidar com este tipo de pedido e como eles devem responder. Eles também podem se envolver com o processo de estimativas para a preparação de uma análise de mudança, já que estarão em melhor posição para dizer se é ou não uma mudança que tem um grande impacto sobre os outros resultados, metas e orçamento.

Eduque seu patrocinador

Além de trabalhar com sua equipe para se certificar de que eles entendem os processos de gerenciamento de mudanças do projeto, fale com o seu patrocinador também. Ele pode não perceber o impacto que as mudanças terão no prazo e no orçamento do projeto. Ele também terá a confiança de saber que há um processo robusto para gerenciar mudanças de uma forma profissional.

Eles, é claro, ainda poderão apresentar alterações, assim como qualquer outra pessoa da equipe ou do grupo de stakeholders, mas eles devem estar cientes de que estas serão avaliadas e uma decisão será tomada, ao invés de simplesmente ser implementadas imediatamente.

Eu perguntei a minha colega se ela percebeu que sua abordagem flexível levaria a aumento de escopo e, provavelmente, significa que o projeto iria ser entregue com atraso e acima do orçamento. Ela não tinha pensado tão longe, porque no ponto de nossa conversa as mudanças tinham sido menores e fáceis de realizar. Ela não tinha considerado o que aconteceria se uma das mudanças fosse mais complexa, ou se ocorresse em um ponto muito tarde no projeto para ser viável.

Eu a vi novamente um par de semanas mais tarde, em uma grande reunião de equipe, e ela fez questão de vir falar comigo. “Eu consegui que o cliente aprovasse os requisitos”, disse ela. “Já estamos vendo a diferença – a equipe pode se concentrar em suas tarefas sem se distrair com novos pedidos.”

Artigo publicado originalmente pela equipe do ProjectManager.com

Publicidade