A visão clássica de projetos e gerenciamento de projetos, é que o projeto termina quando as entregas são realizadas.

Mas as equipes de projeto devem ter pelo menos algum nível de responsabilidade quando se trata de garantir que não só eles entregaram o que foi acordado, mas que o cliente foi deixado em posição de ser capaz de receber esses benefícios daqui para frente.

Perguntas simples como: o cliente está sendo preparado e treinado? As pessoas que irão fazer uso do projeto (solução, produto, etc.) estão treinadas? Vamos entregar o projeto de uma única vez ou aos poucos em “doses homeopáticas”? Todas estas perguntas precisam ser feitas e respondidas. “

As organizações estão garantindo que seus gerentes de projeto pensem por que eles estão fazendo esse projeto, em primeira instância, e em segundo lugar, como a organização vai levar o projeto adiante”, diz Phill Vale, instrutor ESI INTERNATIONAL.

A chave para isso é definir o que é o escopo do projeto e quem faz o quê. Em algumas organizações, com por exemplo, o Ministério da Defesa, o estilo ou o ciclo de vida do projeto vai muito mais além do que o de iniciação, planejamento, entrega e encerramento.

A equipe do projeto tem um grau de envolvimento após a implementação – da introdução para a manutenção de uma entrega. Mas a definição do escopo e da responsabilidade para um projeto além de sua entrega é apenas uma das possíveis abordagens. Outra abordagem seria dar aos gerentes de projetos seus bônus não apenas no momento da entrega do projeto, mas seis meses ou quem sabe antes disso, após a entrega, quando o cliente afirma que tudo foi instalado/implementado com sucesso e os benefícios do projeto foram alcançados.

Phil explica: “A partir de uma perspectiva de negócios de gerenciamento de projeto, o benefício é que se a entrega do projeto foi uma boa experiência, isso significa que outros projetos poderão ser desempenhados pela mesma organização da próxima vez. “Outra razão importante pela qual os gerentes de projetos precisam se tornar mais conscientes das origens do projeto, é porque muitas vezes eles se encontram trabalhando em um ambiente onde um projeto é “despejado no colo” sem ser dito o porquê – o que poderia ter implicações negativas no resultado.

“Muitos dos projetos em que eu trabalho são enviados a mim com um número limitado de informação, mas à medida que eu a avanço e questiono, eu descubro e entendo mais e mais, e muitas vezes identifico coisas que o cliente não percebe – alguma coisa que pode afetar o business case original e a expectativa do cliente em termos de benefícios.” “Se não fizermos isso, eu não acho que estamos nos comportando profissionalmente como gerentes de projeto. Explicar porque alguma coisa não vai funcionar ou que não deve ser feita se torna uma conversa difícil, mas é muito mais fácil conversar neste momento do que mais tarde quando o cliente se encontra diante de algo que não era o que ele estava esperando.

Quanto mais tarde você sinalizar o problema, maior será o risco no projeto e em sua reputação”. A melhor maneira de evitar esse cenário é voltar e fazer as perguntas: ‘Por que você está fazendo isso?` e `Onde eles estão olhando para obter os benefícios?`. Isto pode ser feito, pedindo para ver o business case original em que o projeto foi justificado e de onde iniciou. Talvez você não consiga que o business case completo seja compartilhado com você mas no mínimo você entenderá o porquê está fazendo isso.

É por isso que o gerenciamento de requisitos é tão importante. Entender como o seu projeto vai satisfazer as necessidades do negócio mais adiante vai impactar em como você construirá a solução, sua implementação e definir quando exatamente seu projeto vai efetivamente se encerrar.

Fonte: Blog do PMO da ESI INTERNATIONAL – Centro de Excelência ESI http://www.esi-intl.co.uk/blogs/pmoperspectives/index.php/2013/12/when-should-a-project-actually-end/