DevSecOpsARTIGO

EXPECTATIVA: o segredo do sucesso em projetos – Parte 2

No artigo anterior ficamos no planejamento do projeto, onde as variáveis ESCOPO, TEMPO e CUSTO foram definidas e as expectativas iniciais do cliente/patrocinador foram formadas. Nessa segunda parte nosso objetivo é ilustrar, com exemplos práticos, como as mudanças que ocorrem nessas variáveis do projeto impactam diretamente nas expectativas dos clientes e como essas deverão ser administradas até o final do projeto, para que possamos atender os anseios dos interessados. Estão preparados?

Vamos recapitular as informações que foram definidas no planejamento do nosso projeto:

Escopo do Produto:

  • Módulo de Cadastramento de Projetos
  • Módulo para Inclusão de Atividades no Projeto
  • Módulo de Alocação de Recursos e Estimativas
  • Relatório de Controle de Atividades Semanais
  • Relatório de Avaliação Mensal dos Projetos

Recursos a serem alocados nesse projeto (stakeholders principais):

VT – Cliente / Sponsor

AB – Gerente de Projeto / Analista

TA – Arquiteto / Desenvolvedor

Custo do Projeto: R$ 43.680,00

Duração Total do Projeto: 60 dias (início: 02/06/2008 e término: 22/08/2008)

Ainda nessa fase de iniciação e planejamento do projeto, deve ser acordado com o cliente uma decisão importante: qual das três restrições são inegociáveis?

A depender do projeto, o cliente pode ter as seguintes necessidades:

restrição de tempo (prazo): “o sistema tem que acabar nesse prazo, pois deve funcionar quando a fábrica for inaugurada em 01 de Janeiro de 2009” ou “o sistema vai atender uma lei federal que entra em vigor no dia 01 de Março de 2010”;

restrição de escopo (funcionalidades): “o prazo ou o custo iremos negociar, mas esse projeto deve conter todas as funcionalidades que preciso e nenhuma pode faltar!”;

restrição de recursos: “meu orçamento é limitado e não posso gastar mais do que o valor que acordamos. Com isso, poderemos negociar escopo ou prazo em algum imprevisto”.

Abrindo um parênteses rapidamente, nesse momento você deve estar pensando: “E se meu cliente afirmar que deseja que o escopo, prazo e custo sejam esses até o final do projeto e solicitar que nada seja alterado?”. Você deve argumentar, negociar, usar sua capacidade de persuasão como gerente de projeto, mostrando que isso não é possível, que mudanças acontecem e que, em algum momento, algumas dessas variáveis serão impactadas e terão que ser administradas e os acordos deverão ser refeitos. Se você sempre partir do pressuposto que isso nunca vai acontecer, seus projetos serão sérios candidatos a “engordarem” as estatísticas de projetos fracassados. Pense nisso.

Continuando, no nosso projeto FGP, o cliente foi claro e afirmou que a restrição inegociável nesse projeto seria ESCOPO (ele deseja que o produto entregue tenha as funcionalidades solicitadas e o tempo ou custo serão negociados).

Com essa definição, o contrato foi assinado e o projeto está autorizado a ter sua execução iniciada. Na sequência, vamos simular diversas situações nos projetos e apresentar que atitudes podem ser tomadas, com o objetivo de administrar as expectativas e conduzir os rumos do projeto.

Situação atual do cronograma do projeto:

Situação 1:

O projeto iniciou a Iteração 0 com a atividade “Mapear processo com cliente” com duração de 6 dias. A atividade foi concluída dentro do previsto. Entretanto, ao iniciar a atividade “Homologar o Processo Especificado”, o cliente informou que iria fazer uma viagem a negócios e só retornaria no dia 02/07. Alerta! Mudança está ocorrendo. Essa tarefa estava prevista para ser executada nos dias 30/06 e 01/07 e só será feita nos dias 02 e 03/07. Nesse momento, o que a maioria dos gerentes de projetos pensam: “Ah! São apenas 2 dias. Depois recuperamos isso em outra atividade”. Aí mora o perigo! A probabilidade de você atrasar outras atividades é muito maior do que você adiantar (o histórico em projetos mostra isso, principalmente quando vamos nos aproximando do seu final).

Portanto, aqui uma decisão deve ser tomada: estamos mudando a restrição TEMPO (prazo da tarefa) e ESCOPO é uma restrição fixa (inegociável). Qual alternativa que teremos que propor ao sponsor: “Temos uma mudança no tempo, o que faremos: faremos hora extra para mantermos o projeto no tempo previsto (mudança no CUSTO) ou alteramos o prazo dessa tarefa e, consequentemente, do projeto (mudança no TEMPO)?”. Imaginemos que o sponsor toma a seguinte decisão: “Vamos mudar o prazo final do projeto, pois já estou com outros compromissos e não vou poder me dedicar a isso nesse momento em outros horários não combinados”. A partir dessa decisão, o projeto apresenta o seguinte cenário, atualizado em 01 de Julho (atentar para cronograma com alteração do prazo acordado com sponsor):

Cronograma AtualCronograma Atual

EAP do ProjetoEAP do Projeto

EVA

<h3> do Projeto”><span class=EVA

do Projeto

*Até 1º. de Julho, estavam planejadas 6 tarefas e foram realizadas 5.

Com essa decisão, o prazo final do projeto passou do dia 22/08 (sexta) para dois dias após (26/08, terça). Portanto, aqui o sponsor/cliente concordou e sua expectativa em relação ao prazo final do projeto acaba de ser alterada.

Situação 2:

A execução do projeto foi transcorrendo e houve uma avaliação no dia 18/07. A tarefa em execução “Adicionar Atividades” prevista para 6 dias, está com 3 dias realizados e com apenas 37,5% realizada (era para estar com 50% realizada, pois já se passou 50% do tempo previsto). Conclui-se que, no ritmo que segue, essa tarefa vai levar 8 dias (2 dias a mais, pois faltam 62,5% da tarefa) (1). Nesse momento, o gerente que acompanha o projeto aciona o sponsor para tomar uma decisão: “Temos uma tarefa que estimamos para 6 dias, mas, ao executá-la, estamos observando que ela vai levar mais tempo em função de complexidade não prevista! Com isso, temos um problema com prazo. Qual a decisão: mudamos o prazo final do projeto para mais 2 dias por causa desse atraso não previsto (mudança na variável TEMPO) ou fazemos hora extra (2) para compensarmos esse atraso (mudança no CUSTO)?”. O sponsor define: “Não vamos alterar o prazo do projeto! Negocie com o recurso para que sejam feitas horas a mais para encerrar esse trabalho na data prevista”. O gerente alinhou com o recurso como poderia ser feito esse trabalho extra e ficou definido o seguinte: utilizar o Sábado (manhã e tarde) e na Segunda e Terça com mais 4 horas após o expediente normal (8 horas do sábado com 8 horas da segunda e terça, totalizam os 2 dias de trabalhos extras).

Você pode estar pensando: “Existem tarefas que não é possível fazer uma análise de realizado nesse formato percentual!”. Você está correto! Aqui, só estou procurando fazer uma analogia utilizando percentual, para você entender matematicamente o motivo da decisão para o aumento dos dias para executar a tarefa. Numa situação real, isso vai depender do conhecimento tácito do gerente com a equipe para avaliar o realizado e determinar quanto tempo a mais será preciso.

A depender da natureza do projeto e da atividade, outra alternativa para essa mudança de custo seria alocar mais um recurso no projeto (somente quando for possível fazer paralelismo, uma das técnicas de compressão de cronograma, pois existem casos em que isso não é possível).

Como houve uma mudança no CUSTO aprovada pelo sponsor, a tarefa foi estimada em R$ 3.840,00 e com a mudança passou para R$ 5.120,00 (diferença de R$ 1.280). Com isso, o projeto, nesse momento, está passando a custar R$ R$ 44.960,00!

Na sequência, a tarefa “Alocar Recursos” foi desenvolvida conforme o previsto.

Após a situação 2, segue posição do projeto (atualizado em 01/08):

Cronograma do ProjetoCronograma do Projeto

EAP do ProjetoEAP do Projeto

EVA do ProjetoEVA do Projeto

Com essa decisão, o EVA mostra que a quantidade de tarefas prevista para concluir até 01/08 é igual ao que foi realizado (9 tarefas). Apesar do EVA mostrar um bom resultado, observe que já tivemos mudança do prazo final do projeto e do orçamento previsto, como mostrado nas duas situações ocorridas. Entretanto, tudo foi acordado com o sponsor que teve suas expectativas redefinidas.

Na próxima e última parte desse artigo, simularemos mais situações, discutiremos novamente as decisões tomadas e faremos a finalização do projeto. Será que o sponsor e o cliente ficarão satisfeitos? Será que muitas mudanças ainda estão por vir?

Até o próximo encontro…

é Gerente de Projetos, Professor Universitário e Mentor em Produtividade Pessoal (gestão projeto de vida e finanças pessoais - tempo e dinheiro). Possui 11 anos de experiência na área de desenvolvimento de projetos de software, atuando como desenvolvedor, analista e líder de equipe. Atualmente, é Gerente de Projetos/Scrum Master e lidera o PMO (Escritório de Gerenciamento de Projetos) da área de TI de um grupo empresarial. É Professor Universitário há 6 anos, lecionando disciplinas relacionadas às áreas de Engenharia de Software e Gerenciamento de Projetos em cursos de graduação e pós-graduação. É Certified SCRUM Master (CSM) pela Scrum Alliance, especialista em Melhoria de Processo de Software pela Universidade Federal de Lavras (UFLA-MG), especialista (MBA Executivo) em Gestão Empresarial pela Fundação Getúlio Vargas (FGV-RJ), graduado em Processamento de Dados pela Universidade Tiradentes (UNIT-SE) e técnico em informática pelo IFS (ex-CEFET-SE). É filiado PMI Chapter Bahia desde 2008. É possível encontrá-lo em @alercio.

Ver perfil