Mudança de visão: Aceitar o Replanejamento durante o Projeto


Olá, outro dia estava lendo uma reportagem sobre o replanejamento das atividades nos projetos e achei interessante a seguinte visão: todos comentam que uma coisa que se tem certeza em um projeto é de que haverão mudanças. 

O que fazer com essas mudanças? Devemos Trata-las, evita-las, até que ponto devemos levantar informações e fazer estudos sobre os impactos destas mudanças?

Pelo PMBOK e as boas práticas do PMI é recomendado que na parte de planejamento de um projeto seja feito um estudo sobre as possíveis mudanças no projeto, o impactos dos riscos, os caminhos de tratamento dessas mudanças, mitigando , aceitando ou evitando as mudanças em relação ao escopo planejado. Este tipo de planejamento é muito bem aceito quando tratamos de projetos em que sabemos exatamente o que deve ser feito e como deve ser feito. São projetos em que se tem conhecimento claro do objetivo, requisitos e características. 

Nesse tipo de projeto é mais fácil considerar as possíveis mudanças, antecipar e tratar suas consequências em busca de se manter o objetivo final.

Em alguns projetos, como projetos de software, por mais que seja feita uma analise preliminar do escopo, levantamento de requisitos, objetivos do projetos, normalmente ocorrem muitas mudanças desde da parte do contratante, tecnologias aplicadas, objetivos finais, etc. Esses tipos de projetos em que normalmente não há um conhecimento afundo do objetivo, conhecimento de negócio e conhecimento da tecnologia possuem um nível de mudanças muito maior, e normalmente para que essas mudanças não tragam uma diferença muito grande no final do projeto em relação a prazos e custos costumamos colocar uma margem grande “gordura” aumentando o custo total do projeto o que não agrada clientes , onde muitas vezes a própria empresa se responsabiliza com esses custos e acaba dando um tiro no pé.

Para projetos deste tipo o mais interessante seria trabalhar sabendo de que o escopo final pode mudar, sabendo que as mudanças vão aparecer e terão que ser tratadas. Nesse casso o mais interessante é quebrar a definição do escopo em blocos de atividades se for possível, e quebrar as entregas alinhando com o contratante que a forma de trabalho será essa. 

Com entregar antecipadas de parte menores do projeto alguns problemas de tecnologia e visão de negócio podem ser antecipados e alguns problemas que ocorreriam várias etapas do projeto podem ser vistos antecipadamente desde que as lições aprendidas e a comunicação (relatórios e reuniões de acompanhamento) sejam feitas periodicamente.

Para quem trabalha com Scrum sabe que antecipando as entregas em partes menores (período das sprints) e trabalhando a mudança junto ao cliente se possível evitam que requisitos que no inicio pareciam importantes sejam criados (e depois nunca são usados pelos clientes) e que correções e modificações necessárias sejam verificadas o quanto antes , pois quanto mais tarde verificado no projeto mais caro sai a correção .

Tudo isso vai depender do seu projeto e do bom senso, pelo PMBOK a idéia é planejar da forma mais detalhada possível as informações para evitar problemas na execução, porém atualmente para determinados tipos de projetos sabemos que trabalhar com entregas menores, acompanhamentos constante e buscando resolver as mudanças o quanto antes diminui os impactos negativos e antecipa possíveis problemas de discordâncias de requisitos por parte dos contratantes.

Marcus Machado

Comentários

Postagens mais visitadas deste blog

Riscos Inevitáveis

Conhecimentos Necessários do Gerente de Projetos

A Batata quente!