Recentemente estive conversando com um colega, durante um happy hour, sobre projetos bons que culminam em resultados ruins. A despeito de que em encontros de happy hour não se deveria falar de trabalho, a conversa em si rendeu algumas boas reflexões.

Se as pirâmides fossem software, as da frente seriam a versão trial

Desde a época em que cursava o colegial técnico em processamento de dados -ha longínquos treze anos atrás-, já via os números relativos a projetos de sistemas de informação serem motivo de chacota. Lembro-me que um dos meus professores da época realizava a comparação da engenharia de software com a engenharia civil, invariavelmente enaltecendo a capacidade de gestão e construção da civil em relação a de software. Pois bem, os engenheiros civis começaram construindo as pirâmides ha cinco mil anos atrás, nós mal começamos perfurando cartões a pouco mais de cinquenta anos. Historicamente, eles estão bem mais adiantados do que nós, pensava eu.

Retornando ao assunto, este meu colega comentava sobre um projeto do qual era o gerente, e que potencialmente representava uma importante evolução na Companhia, mas que por fim estava se transformando em um fracasso milionário. A minha insana curiosidade não deixou de se aguçar para entender, afinal, porque tamanha discrepância entre planejado e realizado.

O tal projeto, com orçamento de quase um milhão e meio de Reais, atendia quatro dos cinco clássicos motivos de iniciação: necessidade estratégica, demanda do mercado, solicitação do cliente e avanço tecnológico. Não se encaixando apenas no atendimento a requisitos legais. Sem querer discorrer de tantos outros detalhes, principalmente por motivos éticos, posso me limitar a dizer que o projeto objeto de nossa discussão era interessante e promissor. Mas então, o que falhou?

Chaos Report 2009

Segundo o Chaos Report de 2009 publicado por Standish Group, 32% dos projetos de TI obtiveram sucesso –dentro do prazo, orçamento, escopo e com qualidade (!). Em uma comparação com o relatório anterior publicado em 2006, o percentual caiu três pontos, quando era de 35%. Ainda assim, o cenário melhorou muito, pois na época em que eu cursava o colegial, o relatório de 1998 indicava 26% de sucesso.

Com certeza podemos apontar muitos motivos para que tantos projetos tenham falhado (se construíssemos pontes, imagine que 68% delas caíram). Aqui vamos apenas nos ater ao projeto do meu colega. De toda a triste história, o que me chamou atenção, e que poderia até ser deixado em segundo plano, foi a intervenção direta do Diretor de Informática durante o processo de seleção de fornecedores. Após definir as aquisições necessárias, e passar pelo ritual de requisição de propostas, a equipe do projeto classificou os fornecedores e identificou aquele que melhor atendia aos requisitos definidos no início do processo. Ainda que seja questionável, a decisão final sobre qual fornecedor seria contratado era do Diretor, e este decidiu pelo fornecedor com menor custo e maior risco (segundo os relatórios da equipe). É aqui que começa a minha particular análise, não para questionar a árvore decisória da companhia do meu colega –quem disse que é questionável? E sim, para traçar um paralelo a interessante teoria psicológica do “Efeito de congelamento”, fundamentada por Kurt Lewin depois da Segunda Guerra Mundial.

Kurt Lewin fundamentou a Teoria de Três Etapas

Após a decisão, pelo Diretor, de contratação do fornecedor menos apto, segundo a equipe de projeto, o trabalho de desenvolvimento do software teve início. Não demorou para que problemas de qualidade e prazo tivessem início, e num primeiro momento foram contornados dentro da gestão do projeto. Com o tempo e a insistência das ocorrências, os marcos do cronograma prosseguiam desrespeitados, e relatórios foram emitidos com soluções alternativas e seus cenários projetados definidos. Por fim, a equipe de gestão acionou diretamente o Diretor para que fosse tomada uma decisão em relação ao fornecedor. Na primeira incursão, a decisão foi pela manutenção do fornecedor, e um discreto pedido de atenção do mesmo. Ainda houve outras três ou quatro rodadas, onde o mesmo processo de identificação, criação de opções e tomada de decisão foi repetido, sempre com o resultado similar; a manutenção do fornecedor. Ou seria; a manutenção da decisão?

As pessoas tendem a aderir às suas próprias decisões, promovendo a manutenção do comprometimento com a primeira decisão, em uma escalada de decisões. Isto ajuda a explicar o motivo pelo qual o Diretor manteve sua decisão pelo fornecedor, mesmo tendo acesso a relatórios que o desaconselhavam. A decisão pela seleção do fornecedor foi livremente dele. Esta primeira decisão é o alicerce do efeito de “Escalada de comprometimento” (Barry M. Staw, 1976). Segundo a teoria psicológica, a decisão inicial congela o sistema de escolhas possíveis do individuo, fazendo com que ele mantenha o foco em comprometer-se com o comportamento que mais faz sentido à sua decisão. Afinal, este é o comportamento comum e esperado das pessoas, pois em uma sociedade organizada o que aconteceria se todos passassem a se comportar de uma maneira, após se comprometer com outra? Portanto, este efeito é um bloco básico da construção da personalidade.

Do mesmo modo que o processo de Efeito de congelamento explica a atitude do Diretor em manter sua decisão, também explica o motivo pelo qual a equipe de gerenciamento do projeto, após analisar o desempenho do fornecedor, foi capaz de buscar soluções e sugerir até mesmo a substituição do fornecedor: a decisão inicial não foi deles. Sem o comprometimento com a decisão, a equipe estava livre para utilizar de forma racional as informações obtidas. É especialmente interessante entender que este fenômeno psicológico existe e como ele funciona, pois assim podemos gerencia-lo e buscar formas de impedir seus efeitos perversos, explorando e maximizando suas virtudes.

Naturalmente o episódio do meu colega não é uma exceção, como os números do Chaos Report comprovam. Com mais certeza ainda não são todos os projetos que possuem problemas com fornecedores. Projetos de sistemas de informação possuem tantos pontos de atenção, que um gerente de projetos de TI deveria ser promovido a um deus (um pouco de chauvinismo). O que interessa extrair deste conto é a lição.

Assim como o Efeito de congelamento compreende a Escalada de comprometimento, também estão relacionados outros dois conceitos: a Despesa irreversível e a Armadilha.

Posso imaginar que em determinado momento, ao apresentar-se ao Diretor, a equipe de gerenciamento do projeto sugeriu a substituição do fornecedor. Este por sua vez deve ter argumentado –com mais ou menos emoção- que o projeto já havia despendido recursos financeiros com o tal fornecedor e, portanto, não seria prudente o substituir. Este é um exemplo do julgamento pela Despesa irreversível, o fenômeno que ocorre quando o individuo persiste na decisão porque investiu anteriormente, dinheiro, tempo, esforço, em detrimento de outras decisões potencialmente mais vantajosas.

Vale lembrar que o hipotético manual do bom gerenciamento de projetos diz que não se deve considerar, ao decidir pela continuidade do projeto, esforços já realizados (na norma contábil, estes são custos afundados). Portanto, por si só, um bom gerenciamento do projeto já deveria ser suficiente para evitar que o fenômeno da Despesa irreversível contaminasse a tomada de decisão.

E quanto aos marcos de cronograma, uma de suas funções não é a de servir como ponto de verificação para ajudar a controlar o projeto? Sim. Mas, talvez não foram utilizados de forma satisfatória. O último fenômeno, a Armadilha, pode ajudar a entender como melhorar o uso dos marcos.  Quem sabe no projeto do meu colega, este conceito poderia ter ajudado na correção do rumo, e garantido que o resultado final fosse o almejado.

E agora?

Uma experiência realizada em 1979 por Joel Brockner, Myril C. Shaw e Jeffrey Z. Rubin, mostrou que jogadores expostos a oportunidade de decisão para continuar ou parar de apostar, perdiam menos quando eram obrigados a decidir por continuar. Por outro lado, aqueles que, na mesma oportunidade, apenas agiriam caso decidissem parar, perdiam mais.

O marco de cronograma geralmente funciona como no primeiro caso da experiência citada. Há um marco, onde a oportunidade de decisão ocorre. Caso não seja tomada uma enérgica decisão, o projeto continua por inércia. Assim como o apostador que perde mais, o projeto permanece consumindo mais recursos, ainda que esteja fora de controle. A lição aprendida entra aqui, pois bastaria mudar a forma como o marco do cronograma funciona, para que a Armadilha da decisão inicial seja controlada. Desse modo, em cada marco do projeto, se não houver uma decisão, o projeto então é interrompido. Radical? Talvez. Agora pense nos recursos economizados em contrapartida a um gerenciamento mais agressivo.

Nesta conversa de botequim com meu colega, e por consequência na reflexão do caso que ele apresentou, não esperava descobrir a pedra filosofal da gestão de projetos. Mas fiquei contente por termos entendido um pouco mais da psicologia humana, e como ela nos conduz de forma sutil e transparente.