Porque falham?

Porque falham os projetos?

* Este texto pode ser livremente citado e distribudo desde que identificada a
fonte/autoria.

Fernando C Barbi, PMP
fernando@gestaodeprojeto.info

Quando um projeto encerrado prematuramente, cancelado ou termina sem que
seus objetivos
tenham sido atingidos, considera-se que ele fracassou. O Gestor do Projeto (GP)
tem que se prevenir,
o que no muito difcil j que as causas so quase sempre as mesmas, uma (ou
vrias) destas:

Causa #1. Expectativas irrrealistas
Se verdade que o segredo da felicidade a administrao das expectativas, se
voc
no administrar as suas (e as do patrocinador), voc pode acabar se decepcionando
com
resultados que, sob uma outra tica, seriam considerados bons.
Seja por uma falha de compreenso do escopo ou por um cronograma muito
apertado, os projetos
que no tm slidas bases realistas tendem a falhar mais do que os projetos que
levam em conta a
cultura da empresa e as restries impostas naquele momento.
Mas como saber se as minhas expectativas so realistas? Pense em discut-las com
profissionais
mais experientes que conhecem os problemas que voc ter de resolver e que
conhecem a organizao.
s vezes o procedimento mais simples fica travado pela burocracia e quem j
passou por isso pode
ajud-lo contornar os obstculos.

Causa #2. Planejamento deficiente
Depois de estudar muita estatstica cheguei a uma concluso: planejamento
muito mais arte do que cincia.
Voc pode aprender os mais sofisticados mtodos de previso, saber calcular o
desvio-padro de uma estimativa
e usar as ferramentas mais sofisticadas e mesmo assim errar. Porqu? Em geral
por que partiu de premissas
erradas. Voc espera que determinado fornecedor entregue uma tarefa com uma
eficincia de 95% e
ele falha em 30% das vezes. Sua margem de manobra que era de 5% estourou e
voc deve acomodar
os 25% (30%-5%) que aconteceram de forma imprevisvel.
Vivemos num mundo complexo em que os eventos podem ser influenciados por
acontecimentos de uma
forma numa vez, mas por outra bem diferente na prxima ocorrncia. Quando
aproximamos um processo
tendemos a buscar uma funo com forma linear, algo como y=Ax+B. Neste
modelo, a varivel x que se
observa explica a varivel y segundo os parmetros A e B. Mas se houver outro
fator, digamos z, que
afeta y e no colocamos na equao (porque quando medimos x e y, z era
desprezvel), podemos incorrer
em grande erros nos casos em que esta varivel omitida, z, assuma valores
significativos.
Nos processos de Gesto de Riscos, deve-se identificar os fatores relevantes (no
nosso caso, x e z) e
procurar medir, ou estimar, qual o possvel impacto no resultado final (no nosso
caso, y).

Causa #3. Falha no controle de desempenho
No h nenhuma desculpa aceitvel para se perder o controle sobre o desempenho
da equipe de
projeto e de outros interessados que afetam diretamente os resultados. Alguns GPs
preferem relatrios,
outros vo para o contato cara-a-cara. No importa como, mas vital que este
processo de acompanhamento
seja permanente e regular. Se a tarefa parece cansativa, automatize-a mas faa.
As pessoas respondem de forma diferente quando so monitoradas, como nos
ensina o "efeito Hawthorne".
Neste experimento, o mero fato de estarem sendo acompanhados por
pesquisadores fazia com que os
trabalhadores de uma fbrica produzissem mais. Tentaram variar a luminosidade
do ambiente de trabalho
e descobriu-se que com mais ou menos luz, as pessoas eram mais produtivas.
Ficou ficou claro que no era
a luz que influa nos resultados, mas o ato de estar sendo monitorado que fazia o
pessoal dar duro.
Desempenho pode ser algo complicado de medir. Num projeto de software, usa-se
muito como mtrica
a quantidade de linhas de cdigo escritas. Mas um programador pode entregar mais
cdigo e ao mesmo
tempo cometer mais erros do que os outros. Um bom indicador deve ser simples,
mas no to simples
que esconda o que se deseja realmente medir, que a quantidade de cdigo de
boa qualidade.
Lembre-se da velha frmula: "tudo o que se deseja obter deve ser medido".

Causa #4. Falta de liderana efetiva
Eu encontrei vrios GPs que vinham de organizaes matriciais fortes e acredito
que foram muito
influenciados por elas. Parece que nestas organizaes, as pessoas demoram mais
a responder
por receio de entrar numa rea alheia. No limite, a guerra entre os "feudos" impede
que boas iniciativas
inter-departamentais decolem. As pessoas esto reprimidas e, se o GP "cria da
casa", ele pode
apresentar hesitaes "inexplicveis".
Estas pessoas usualmente apostam que muitos rudos se dissipam "sozinhos", o
que obviamente no
acontece. O rudo, ie. um pequeno problema dentro da equipe, pode ser mais do
que isso. Pode ser
que no seja to pequeno mas que assim parea por uma falha de percepo do
GP. Quanto maior o
projeto, maior a inrcia (leia-se, resistncia a mudanas) e maiores as chances de
rudos.
Quanto mais rpido o problema for endereado pelo GP, melhor para todos.
Alm disso, a verdadeira liderana inspiradora e viral: um bom lder acaba
criando um ambiente propcio
ao surgimento de novos lderes a sua volta. Uma dica: se voc topar com uma
equipe cheia de pessoas
motivadas e que apresentam um claro interesse em liderar, voc tem uma boa
pista de que o
GP um bom lder.

Causa #5. Falta de skills dos membros do time de projeto
Quando contratou um profissional, o GP pode ter sido enganado pensando que o
candidato sabia fazer
uma coisa que na verdade no sabe, mas isso difcil de ocorrer se voc tomar as
devidas precaues
como estabelecer uma descrio funcional ("job description") bem detalhada e que
especifique uma srie
de habilidades que possam ser verificadas. Discutimos tcnicas para isso em outro
artigo.
Mas mesmo que voc tenha feito tudo certo, comeou o projeto, definiu e
plataforma de desenvolvimento
(digamos por exemplo, Windows), contratou experts e depois, por uma
daquelas voltas da vida, descobre
que o produto deveria ser desenvolvido em outra plataforma (por exemplo,
Unix) que sua equipe no
conhece. O que fazer? Trocar ou retreinar?
Depende dos recursos de tempo e verba disponveis mas via de regra prepare-se
para mudar boa parte
da equipe, sem se deixar levar por sentimentos de amizade ou pena. Melhor seria
especificar o pagamento
de um bnus de desligamento antes de contratar o profissional. Quanto antes ficam
claras as regras do jogo,
melhor para todos. No final, a opo simples: agir quando ainda h tempo ou ver
o barco afundar.

Causa #6. Falta de motivao do time e dos interessados
O moral da equipe sofre muito quando a gesto fraca. Imagine se o Joo, que
um gerente jnior
importante para o projeto acabou de casar e est sendo pressionado pela esposa a
procurar outro emprego
que pague mais. O GP, temendo perd-lo, lhe promete um bnus mas no pede
autorizao da direo
nem com do pessoal de RH. Ele pensa que no necessrio j que o projeto tem
oramento para isso.
Joo d duro, se esfora e o projeto um sucesso. Na hora H, o bnus no vem
como prometido e Joo
recebe um tapinha nas costas. As explicaes so as mais diversas: no temos
oramento para isso,
poltica de empresa no fazer estas coisas, voc no seguiu os procedimentos da
empresa, etc...
Isso pouco importa para quem no recebeu a devida recompensa.
O que acontecer com o desempenho de Joo depois disso? Isso para no
mencionar a perda de credibilidade.
Tenho uma regra: quando um bom profissional est entregando abaixo do
seu potencial o GP tem "culpa no
cartrio": ele deveria ter se informado sobre o que est acontecendo. No caso do
Joo, ele agora est
saindo mais cedo para ir a entrevistas de emprego em outras empresas. O GP
deveria ter tomado as devidas
medidas corretivas, como se informar sobre a possibilidade de bonificar o pessoal.
Moral de histria: se voc no puder oferecer um bnus, no o faa. Se fizer, tem
de cumprir.

Causa #7. Falta de apoio dentro da organizao
Apoio aqui a fora poltica que um diretor, scio ou presidente pode dar ao
projeto. A figura mais importante
para o projeto a do patrocinador que deve comunicar aos demais membros da
organizao a importncia da
iniciativa para a empresa, cobrando deles a ateno necessria para que as tarefas
sejam concludas.
Por exemplo, imagine instalar um sistema financeiro numa empresa pequena com
um grande nmero de pedidos
processados manualmente todos os dias. Haver uma sobrecarga do pessoal do
departamento pelo tempo
necessrio ao teste e implantao do projeto.
Esse tempo extra pode exigir a contratao de pessoal temporrio para fazer
as tarefas do dia-a-dia
enquanto o pessoal da casa usa a nova ferramenta. Sem apoio de algum com
poder de deciso
pode ser difcil contratar esta equipe para ajudar na transio ou para fazer
o pessoal do departamento
financeiro separar duas horas do seu dia para testar e aprender a usar a nova
ferramenta.

Causa #8. Falta de recursos
Apesar de algumas pessoas no tomarem o cancelamento de um projeto por falta
de fundos como um
fracasso, entendo que de alguma forma o GP poderia ter se antecipado ao
problema. Qualquer companhia
pode enfrentar momentos difceis, que exijam a reduo rpida de custos. No
entanto, isso dificilmente
acontece do nada (como, por exemplo, na mini-crise de 11 de setembro de 2001).
Em geral os sinais esto por toda parte e cabe ao GP estar ligado neles. Por
exemplo, se parte dos recursos
para um projeto ainda devem ser captados no mercado e os juros (leia-se, a taxa
Selic) sobem, provvel
que surjam dificuldades para realizar esta captao.
E como tratar o problema com a equipe? melhor abordar o tema claramente
numa reunio do que deixar
os rumores de demisses tomarem conta das mentes de pessoas que deveriam
estar concentradas em
obter resultados.
Se haver um corte de oramento, o GP deve se antecipar e planejar como se
poderia reduzir custos e seguir
com o projeto. No limte, ele deveria pensar em encerrar o projeto deixando
resultados palpveis, mesmo
que no os originalmente esperados. A partir de algo concreto mais provvel que
se possa retomar
o projeto quando o ambiente econmico melhorar.
Mas se os recursos faltarem porque a empresa est vendo outros projetos como
prioritrios, o GP deve
lutar por seu projeto e mostrar o que j se ganhou com ele e quanto ainda deve
ganhar se complet-lo.
Se o patrocinador receber um plano para seguir com o projeto com custos
reduzidos, isso pode evitar a
suspenso/cancelamento do projeto.

Concluso
Sejam quais forem as causas do cancelamento do projeto, recomendo que sempre
se faa uma reunio
de encerramento para se discutir o que se pode aprender com essa
experincia. Quando h confiana
e respeito mtuo a equipe enfrenta as consequncias do fracasso de forma
unida. Cabe ao GP informar
aos demais os propsitos da reunio, seno corre-se o risco dos mais exaltados
buscarem culpados,
o que cria um clima desagradvel que impede o dilogo.
Sugiro que cada um faa o seu mea culpa, levantando apenas os pontos em que
deveria ter agido de outra
forma, sem tentar explicar seus atos em resposta a erros dos outros. Assumindo
que o grupo fez tudo o que
podia ser feito para evitar o fracasso, o GP deve tirar as lies devidas e resumi-las
para todos. Assim
aumenta-se as chances de sucesso no prximo projeto.
De toda forma, planejamento e comunicao so as duas atribuies crticas que o
GP no deve delegar.

Conceitos Importantes



Os primeiros conceitos que voc precisa conhecer so: Projeto, Risco, Escopo e
Patrocinador.

Um Projeto um empreendimento que se caracteriza por ser evento temporrio e
ter um objetivo nico e bem definido. O projeto no se confunde com tarefas
rotineiras
de operao normal da empresa.

Quando ocorre esta confuso, o projeto corre riscos desnecessrios.
Um risco todo evento que pode impactar o projeto, para o bem e para o mau.
Se o risco pode benfico ao projeto, chama-se oportunidade.
Normalmente associamos a palavra "risco" a conseqncias negativas,
por isso uma das nove reas de conhecimento recebe o nome de "Gesto de
Riscos".

Um risco constante que sejam feitas alteraes no escopo do projeto.
O escopo (scope) tudo o que deve ser feito para se atingir o objetivo do projeto,
o que o projeto deve entregar.

Os entregveis (deliverables) so documentos, prottipos e todos os demais
intangveis (tais como treinamento e homologao) que o projeto deve entregar
quando
for completado. Escopo no "tudo o que o cliente quer" poque muitas vezes ele
no
sabe tudo o que deve ser feito!

O GP deve alinhar o escopo com o patrocinador do projeto.
O patrocinador (sponsor) quem apia o projeto dentro da organizao.
Pode ser um diretor que tambm autoriza os pagamentos, ou um gerente que
se reporta diretoria, o importante que ele ou ela apie o projeto tanto
em termos financeiros quanto com respaldo poltico, garantindo os recursos
(verba e tempo do pessoal) quando necessrio.

O patrocinador um interessado (stakeholder) do seu projeto, assim
como so os membros da equipe que o executa, os usurios que como clientes
demandam o produto que o projeto deve entregar. Os terceirizados que
participam do projeto ofertando servios para se fazer este produto tambm so
interessados. No caso de uma obra de engenharia civil que ter impacto na
vizinhana, como o caso de uma represa, os moradores do lugar afetado tambm
devem ser considerados como interessados e seus questionamentos devem ser
endereados. Veja mais sobre Anlise de Stakeholders.

Para que o projeto acontea dentro de padres previsveis preciso que parta
de uma metodologia de trabalho. A metodologia o conjunto de processos,
documentos e regras para o desenvolvimento do trabalho. A empresa pode j
dispor
de um conjunto de regras operacionais que o projeto pode usar para criar a sua
prpria metodologia. O importante que haja um conjunto formalizado de regras
de trabalho.

Tambm importante formalizar os objetivos, intermedirios e finais, do projeto.
So os marcos (milestones) do projeto: eventos de completamento de uma etapa.
Usa-se o conceito de marco para criar visibilidade dentro do processo. Atrasos na
entrega de um marco devem indicar problemas no projeto ou na sua conduo, j
que esta deveria ter incorporado os atrasos ao planejamento, possivelmente
revendo
tambm cronograma e oramento.

Um cronograma (schedule) uma sequncia de datas de execuo das tarefas
necessrias para
a realizao do escopo do projeto, listadas no WBS. O WBS (Work Breakdown
Structure)
o detalhamento de todas as atividades do projeto. Normalmente se faz numa
planilha e fica
a cargo do responsvel pela tarefa identificar todas as subtarefas que deve realizar
para que
determinado objetivo seja atingido. O oramento (budget) a relao de custos
associados s
tarefas especificadas no WBS.

Tanto o cronograma o quanto oramento devem ter um baseline de referncia.
O baseline um modelo, um guia do que foi planejado j com todas as alteraes
aprovadas. O benchmark um tipo de baseline aceito na indstria como
um padro a
ser seguido. Para se chegar a um desempenho de benchmark, costuma-se seguir
as melhores
prticas. As melhores prticas (best practices) um conjunto de procedimentos
entendidos como ideais para realizar uma determinada atividade.

Quando uma mudana solicitada, o GP deve verificar o impacto que ter sobre
o seu baseline. Se o impacto for significativo ele deve submeter o pedido de
mudana
a um comit de controle. O comit de controle de mudana (change control
board
ou CCB) o grupo autorizado a estudar e aprovar as solicitaes de mudana no
projeto.
Este grupo pode ser composto apenas do patrocinador, se este tiver as condies
para
assumir o nus da mudana.

Numa empresa com maior maturidade em Gesto de Projetos costuma-se
encontrar um PMO.
O PMO (Project Management Office) um grupo que excerce desde funes de
treinamento e padronizao das metodologias at efetivamente gerenciar os
projetos.
A existncia de um PMO indica um alto nvel de maturidade da empresa em
gerenciamento de
projetos uma vez que ela busca, ao estabelecer um PMO, otimizao
pelo compartilhamento
de recursos e aumento da qualidade da gerncia pela especializao de funes.
Normalmente, num PMO cada profissional cuida de um determinado aspecto de
todos os projetos
da organizao, como finanas, planejamento, aquisio, pessoal, etc...