Cumprir o prazo ou seguir o processo?

Esta é uma das perguntas mais difíceis que conheço na Gestão de Projetos, pois quando consideramos cenários práticos, repletos de peculiaridades, pode representar uma dicotomia. Para alguns, seguir passos planejados não tem tanta importância quanto entregar um serviço, para outros, o mais importante é garantir a qualidade do produto gerado.

Devemos observar que os processos guiam um caminho baseado na “forma”, o conteúdo é sempre proveniente das experiências humanas. Um processo de desenvolvimento de software por exemplo, define que se levantem requisitos, desenhem diagramas e façam protótipo, mas mesmo seguindo o processo a risca, o software pode sair um desastre. A mesma situação pode ocorrer em qualquer cenários não-repetitivo, como é o caso dos projetos.

Mas seja qual for a resposta dada pelo profissional à pergunta-título, algumas premissas foram tomadas e tenho certeza de que se elas mudarem, a resposta também irá mudar. Para montar este post conversei com vários  Gerentes de Projeto e coletei suas opiniões sobre o assunto, cada um trazia consigo as experiências das empresas onde trabalhou e essa foi a parte interessante, não restringir o cenário. O planejamento contemplou o uso do processo? O cliente paga pelo processo? O processo atende às necessidades de negócio? O processo pode ser adaptado? Para todas as perguntas, respondi apenas que considerassem as premissas que desejassem. Para um trabalho acadêmico seria interessante acrescentar os cenários e pedir que respondessem, mas isso vou deixar para os trabalhos futuros.

Cases

Quero ilustrar alguns casos reais em que foi necessário tomar a decisão que dá nome este artigo:

1. Gold Plating – O orçamento do projeto fora combinado com o cliente sem horas-extras. No meio da execução o cliente solicitou a disponibilização da equipe para um apoio noturno, eles ficariam disponíveis e seriam chamados se fosse necessário.O GP solicitou um e-mail para registro, disponibilizou o time no período e o projeto foi finalizado com sucesso. O processo, no entanto, exigia a abertura de uma “Solicitação de Mudança-SM” para incluir QUALQUER coisa no escopo. Duas semanas depois, o GP abriu a SM para adicionar as horas-extras, mas na hora da aprovação o cliente respondeu: “Todas as despesas do projeto foram pagas, não vou aceitar a Requisição de Mudança”. A empresa prestadora do serviço teve que arcar com o prejuízo.
2. GP “vendido” – Durante o levantamento de requisitos de um grande projeto sob um contrato guarda-chuvas, antes de finalizar a primeira baseline de cronograma, o cliente recebe (informalmente) através de um funcionário da área de requisitos de negócio,  a informação de que o projeto seria entregue numa determinada data – antecipando prazo do projeto para o final do mês seguinte, 3 meses antes do previsto.  O cliente lançou uma publicação oficial para o Brasil inteiro, informando a data em que o produto estaria disponível. A equipe ignorou as diretrizes da empresa e executou o projeto sem processo algum, o sistema foi para o ar.
   
3. Executa e depois documenta  – O cliente abriu uma Solicitação de Serviço com um mês de antecedência (já sabendo da grande demanda e da demora no processo), no dia 30 ele precisava do serviço concluído. O GP foi alocado faltando 5 dias para o final do prazo. O projeto estava classificado como “normal”, sem urgência.
   No contato inicial com o cliente, os técnicos da equipe informam calmamente: “Você usou o formulário errado, precisa reabrir a solicitação”. O cliente responde: “Eu posso abrir o formulário que quiserem, mas preciso disso pronto em 5 dias”. Os técnicos retrucam: “Impossível”.
   A discussão dura alguns minutos até que o GP entra e diz ao cliente que vai escalar para que seja possível executar o trabalho e depois tratar a papelada. O cliente aceita, o processo é escalado e aprovado. O projeto é executado sem documentação.
4. Segurando a avalanche – Projeto contratado em regime T&M com duração de 6 semanas. Por precaução, a equipe fechou uma Declaração de Escopo. O cliente era muito amistoso e participava inclusive da execução do trabalho. Algumas mudanças pequenas foram sendo assimiladas pela equipe e documentadas pelo GP, sem aprovação oficial do cliente. Na quarta semana, as mudanças são aprovadas a contragosto pelo cliente, sob o argumento (do GP) de que não impactariam no preço.
   Na última semana, o Diretor da empresa cliente solicitou uma mudança estrutural, aumentando substancialmente o trabalho. Todos ficaram estupefatos, a equipe em conjunto com o ponto focal do cliente, tentaram assimilar o trabalho, mas ao final não foi possível terminar todo o escopo, nem o original, nem a nova baseline. Pela perspectiva de escopo o projeto foi visto como um fracasso, mas como a equipe estava respaldada, o cliente (já meio esquecido) aceitou o impacto.
5. Scope creep – Projeto em regime T&M com duração de 2 anos. O projeto era de migração de um sistema complexo, a ser usado por centenas de milhares de pessoas simultaneamente. O cliente não tinha domínio dos detalhes de sistemas e a equipe que manutenia o sistema anterior foi segregada, para que continuasse dando manutenção até a migração terminar.
   A equipe de projeto tentou delinear o escopo do projeto, mas por mais que seguisse os processos de Engenharia de Software, não tinha como extrair as regras em detalhes, pois a segregação das equipes gerou conflito e falta de colaboração.
   Após meses de análise de requisitos, a equipe definiu um Documento de Casos de Uso com cerca de 500 páginas, com todos os fluxos normais e alternativos e protótipos de tela. O cliente se negou a assinar a especificação, pois sabia que não tinha domínio das regras de negócio. A equipe começou o desenvolvimento sem baseline aprovada.
   Independente disso, as regras de negócio foram mudando ao longo dos 24 meses, muitas e muitas vezes, drasticamente. Iniciaram-se conflitos com o cliente, entre as equipes e dentro da própria equipe de projeto. Todos procuravam um culpado onde não havia nenhum, era característica do sistema mudar. O sistema não conseguia ser liberado para manutenção, pois não tinha versão estável. Semanalmente várias versões eram lançadas, correções de dados e implementações de emergência. Algum tempo depois, o gerente da área foi demitido como bode expiatório, pois o cliente estava insatisfeito com a instabilidade e incompletude do resultado.

Alguns depoimentos de GPs entrevistados

“A resposta para esta pergunta deve estar alinhanda com um bom gerenciamento de risco onde vc vai poder medir qual solução iria impactar menos negativamente o projeto como um todo” (Gerente de Projetos, empresa multinacional)

“Na minha opinião, se for um cliente que está sempre perto da equipe existe a possibilidade de priorizar o projeto, ou seja, cumprir prazo” (Gerente de Projetos, empresa regional)

“Cumprir o minimo do processo e atrasar o minimo do prazo” (Gerente de projetos, empresa internacional)

“Infelizmente muitas vezes temos que selecionar a primeira opção” (Gerente de projetos, empresa multinacional)

“O ideal é ter disponível um processo flexível de modo que a estimativa de entrega seja proxima da planejada ou que diminua a os riscos negativos do projeto frente ao patrocinador” (PMO líder, empresa nacional)

“Não podes deixar o processo totalmente de lado, mas pode cumprir apenas parte dele que julgar importante. Mas o prazo sempre será mais importante.” (Gerente de Qualidade, empresa regional)

“Se o descumprimento do processo não acarretar em uma forte diminuição da qualidade do entregável, opte por entregar ao invés de satisfazer o processo e ter que negociar prazo com cliente muito próximo da data de entrega acordada.” (Gerente de projetos, empresa nacional)

“Resposta ‘Ecologicamente correta’: Cumprir o processo dentro do prazo. Resposta que o sponsor quer: Entregue o projeto no prazo. Agora, entendendo que a pergunta pressupõe que processo utilizado já não mais atende às necessidades de negócio (timing) da empresa, eu responderia: Entregue o projeto no prazo e reestruture seu processo (ou as áreas de suporte)” (Gerente de projetos, empresa multinacional)

“O processo é algo que existe para ajudar a atingir os objetivos do projeto (boas práticas, templates, estrutura lógica de ações, etc.). A partir do momento em que este se torna tão importante que começa a afetar os objetivos que ele deveria suportar, o conceito está sendo deturpado. No entanto, como a maior “carga” de trabalho resultante da decisão de seguir ou não o processo fica sob responsabilidade do Gerente de Projetos, teoricamente o desempenho do time não seria tão afetado.” (Gerente de projetos, empresa multinacional).

Seguir ou não o processo?

Sucesso ou fracasso, seguir ou não seguir processos, no final das contas acaba sendo mais importante a satisfação e a assinatura final do cliente. Mas seria leviano aconselhar que não sigam processos, pois cada empresa é uma composição de várias partes e precisa trabalhar de forma síncrona para continuar sobrevivendo. É um organismo e desse modo, precisa que as “conexões” entre os “órgãos” seja respeitada, por isso cada aprovação, cada check, cada documento tem sua importância.

Além disso, se cada Gerente de projetos se empenhasse em modificar processos, nunca haveria processo algum e  todo conhecimento seria perdido sempre que alguém saísse. Em síntese, o conhecimento se tornaria efêmero e a gestão seria dificultada.

Li uma análise do Giovani Faria chamada “Processo tem prazo de validade?”, em que faz questionamentos sobre tempo de mudar um processo, se deveríamos usar processos inovadores ou conservadores etc. Acredito que a questão de adaptar  os processos às necessidades de negócios em um ciclo de análise contínua (uma espécie de PDCA) seria uma boa forma de tentar minimizar a dicotomia, mas quero ressaltar também o Tailoring. Processos estanques tipicamente não atendem a  realidade de projetos, por isso o próprio PMI invés de definir uma metodologia se ateve a um guia de boas práticas. As empresas, no entanto, insistem em definir e auditar processos rígidos para engenharia e gestão. O tailoring é a possibilidade de adaptar os processos à realidade de um projeto tendo anuência da área de qualidade.

Como se pode ver acima, não há uma resposta absoluta. As vezes é preciso fugir à regra e as vezes fugir dela é suicídio. Cabe a cada GP analisar a situação e assumir riscos quando julgar necessário. Nestas horas não bastam os PMIismos, é preciso jogo de cintura para alcançar resultados.

Obrigado a todos que participaram!

Eli Rodrigues