Olá,
pessoal! Em uma nova série de artigos, trataremos sobre os
conceitos de gerenciamento de projetos. Porém, neste primeiro momento avaliaremos alguns pontos importantes sobre resultados alcançados
nos projetos de TI, na maioria das empresas.

Nem tudo são flores nos projetos de TI

Segundo
o Project Management Institute (PMI), uma das organizações dedicadas à
evolução da gerência de projetos, um projeto é um empreendimento
temporário almejando a criação de um produto ou serviço único. Nessa
definição, a palavra “temporário” significa que um projeto
necessariamente precisa ter um início e um fim, enquanto a palavra “único”
significa que o produto do projeto se diferenciará, de alguma forma, de
outros produtos que possam já existir no mercado.

Para
serem executados, os projetos necessariamente necessitam de um grupo de
pessoas, equipamentos e serviços que são disponibilizados por um tempo
determinado. Esses recursos atuam de forma temporária no projeto, o que
significa que, ao atingir o objetivo proposto no plano do projeto, toda a
estrutura e todos os recursos do projeto são disponibilizados para
atenderem a outra demanda ou outro projeto.

Sabemos
que o objetivo de todo projeto é satisfazer as expectativas dos
stakeholders (das partes interessadas). Para isso, precisamos
identificar cada parte interessada no projeto, mapeá-las com muita
precisão, entendendo o interesse de cada um em relação ao projeto e
buscando alinhá-las sempre que ocorrem os conflitos e “choques” de
interesses. E, por todo o projeto, perceberemos que esses conflitos
ocorrerão devido a uma série de fatores,
tais como desejo unitário, autoritarismos, egos, problemas de
relacionamentos entre as partes interessadas, entre outros.

Ao
contrário do que poderia parecer à primeira vista, o sucesso de um
projeto não é determinado somente pelo fato de seus objetivos formais
terem sido alcançados. Na maioria das vezes, existe um conjunto de
objetivos informais que são levados em consideração na avaliação do
projeto onde se definirá o grau de sucesso obtido. O que agrava ainda
mais essa situação é a falta de um padrão que possa explicitar o retorno
propiciado pela implantação de um determinado projeto. Nesses casos, é
quase inevitável que cada stakeholder apresente sua própria proposta
para a avaliação do projeto e, com isso, podemos chegar a diversos
conflitos. Para evitarmos esses problemas, precisamos unificar a forma
de avaliar o grau de satisfação de todos.

Em termos práticos, o que
vemos são alguns stakeholders se posicionando de forma contrária e
outros a favor do investimento no projeto, e isso nos força entender a
razão pela qual as partes estão a favor ou contra o projeto, levando
tempo e, certamente, tornando-se um dos fatores primordiais para o sucesso
do projeto.

Por que tantos projetos falham? 

Segundo Capers-Jones
[CAPERS-JONES,1996], algumas características para se definir se um
projeto foi bem sucedido são: término no prazo, dentro do orçamento, com
um alto nível de qualidade e, principalmente, com um alto nível de
satisfação de todas as partes interessadas. E, por outro lado,
caracaterizamos um projeto como mal sucedido ou fracassado quando: ele
foi cancelado antecipadamente, extrapola o prazo ou o orçamento
previsto, tem baixa qualidade e o nível de satisfação é baixo ou quase
nulo.

Em 1984, Tamahin e Willemon
[TAMAHIN E WILLEMON, 1984] fizeram um levantamento sobre as possíveis
causas de falhas em projetos na área de engenharia. Esse estudo mostrou
os resultados de uma entrevista realizada com mais de 300 diretores e
gerentes de projetos de empresas, avaliando os resultados de 180
projetos de porte das áreas de eletrônica, petroquímica, civil e
farmacêutica. O resultado do estudo foi surpreendente, porque os dois
grupos de profissionais concordaram sobre 15 fatores de risco mais
importantes, e a grande diferença, entretanto, está na importância que
cada um atribuiu a cada um desses fatores.

Veja tabela abaixo:

Fator de Risco	Diretores	Gerentes de Projeto
Falta de planejamento	1	10
Plano de projeto não-realista	2	3
Subestimar o escopo do projeto	3	8
Alterações no cliente ou na gerência	4	1
Falta de planejamento das contingências	5	14
Inabilidade para acompanhar o progresso	6	13
Inabilidade de detectar problemas antecipadamente	7	5
Poucos pontos de controle	8	9
Poucas pessoas na equipe	9	4
Complexidade técnica do projeto	10	2
Mudanças de prioridade	11	6
Falta de comprometimento da equipe	12	1
Falta de cooperação dos grupos de suporte	13	12
Falta de motivação da equipe	14	7
Pessoal não qualificado	15	15

Tabela 1 – Fatores de risco de Tamahin e Willemon

O
fator mais importante que podemos observar nesse estudo é a constatação
de que as falhas de projetos são causadas por fatores conhecidos e, de
certa maneira, controláveis. De certa forma, o resultado nos traz um
conforto, pois, a partir do momento em que conseguimos identificar os
fatores de risco a que um projeto está exposto, como também as
consequências que cada fator pode trazer ao projeto, podemos nos
prevenir e planejar melhor  cada ação para as possíveis causas de
problemas no decorrer do projeto.

E por que os projetos de TI ainda falham?

Na maioria das vezes
grandes projetos remetem a grandes problemas, não importando qual
ferramenta, metodologia utilizada ou equipe. Vemos prazos estourados,
orçamentos muito além do limite e os resultados não correspondendo às
expectativas dos stakeholders.

Como uma tendência forte, a
Tecnologia da Informação e os Sistemas de Informação tornaram-se cada
vez mais importantes para a estratégia empresarial. Em consequência, os
investimentos em TI tendem a formar uma parte substancial da carteira de
investimentos das empresas. Entretanto, parte desses investimentos não
tem trazido o resultado esperado para os negócios, porque muitos dos
projetos de TI que são iniciados em empresas de todo porte simplesmente
falham.

Falhas
nos projetos de TI, como atrasos, escalada de custos e falta de
qualidade, têm sido apontadas como os grandes vilões pela incapacidade de
contribuição desses projetos aos objetivos finais do negócio. Em
decorrência dessas falhas e respectivas causas, projetos de TI têm sido
alvo de muitos estudos. Um estudo realizado por Capers-Jones, em mais de
500 empresas norte-americanas em mais de 6000 projetos, identificou que a
taxa de falhas nos projetos de TI são considerados atividades de alto
risco, chegando a ser maior que 50%.

Em outro estudo realizado
recentemente, o Standish Group International aponta que o sucesso dos
projetos de TI ainda não atingiu um número que pudesse nos alegrar. O
“Chaos Report 2009” nos mostra uma queda no percentual dos projetos com
sucesso, atingindo apenas 32% dos projetos entregues no prazo, no
orçamento com recursos e funções planejados, 44% dos projetos estão
atrasados, com o orçamento estourado e poucas funcionalidades
requeridas inicialmente, e 24% dos projetos foram cancelados antes de
sua conclusão ou entregues e nunca foram usados pelas empresas.

De acordo com o PMI, a
maioria dos projetos de TI tem seus custos excedidos e cerca de 88%
deles ultrapassam o planejamento, o orçamento ou ambos.

Sabemos que a TI é complexa
e suas incertezas aumentam muito o risco daqueles que executam e
planejam TI. Portanto, um processo tecnológico tem maior possibilidade
de falhar quando comparado com os de outras áreas. Por esses motivos, o
fracasso de um projeto torna-se o grande pesadelo das equipes de
projetos, dos stakeholders e principalmente dos patrocinadores, que
esperam um retorno de seus investimentos. Porém existem razões mais
comuns que levam ao fracasso o maior número de projetos.

Fergus O`Connell, em sua
obra “How to Run sucessful Hig-Tech Project-Based Organizations (Artech
House, 1999)”, apresenta uma relação dos dez principais motivos que levam
os projetos de TI ao fracasso e eu os comento abaixo. São eles:

1. Os objetivos do projeto não são bem definidos e/ou os
   envolvidos não são identificados: este é um dos pecados capitais no
   planejamento de um projeto. Precisamos evitar as surpresas,
   identificando bem todos os envolvidos para que possamos definir de forma
   clara e realista a necessidade de todos para o projeto que se propõe desenvolver.
2. Os objetivos do projeto são definidos de forma apropriada, mas as mudanças não são identificadas: não gerenciar as mudanças nos projetos faz com que o escopo pré–definido se perca e muitas das vezes o estouro do prazo se dará em consequência dessa falta de controle. Todos os envolvidos podem
   solicitar mudanças no projeto, mas é necessário que se tenha critérios para analisar o impacto e
   a vialibilidade e, somente depois, aprová–las.
3. O projeto não é planejado de forma
   apropriada: o planejamento é fundamental para o sucesso
   do projeto, não se pode esperar muito de
   um projeto que não fora estudado e que não tenha seus objetivos claros.
4. O projeto não é gerenciado de forma
   apropriada: no mínimo, é preciso que se tenha na
   equipe pessoas qualificadas e com o conhecimento de alguma metodologia e
   nas melhores práticas de gerenciamento de
   projetos.
5. O projeto é planejado de forma
   apropriada, porém seus recursos não são gerenciados: o que acham disso? É claro que qualquer recurso
   envolvido em uma atividade e que não possua uma coordenação ou direcionamento terá dificuldades em cumprir os prazos propostos.
6. Não são criados planos de
   contingência: quando não se tem um bom plano de
   contingência para os possíveis riscos do projeto, inevitavelmente o que ocorrerá quando eles aparecerem será uma paralisação no projeto. Atuar de forma corretiva não é a melhor solução, portanto, procure avaliar os possíveis riscos e montar as contingências para caso eles ocorram.
7. As expectativas dos envolvidos com relação ao projeto não são gerenciadas: o que não podemos esquecer é que cada envolvido no
   projeto tem suas próprias expectativas. O
   desenvolvedor tem suas expectativas em relação à documentação que ele receberá para o desenvolvimento do
   projeto. O analista tem suas expectativas quanto à receptividade do
   cliente para que ele possa levantar todas as necessidades e possa traduzi–las para os desenvolvedores, e portanto, precisamos gerenciá–las.
8. O projeto é planejado de forma
   apropriada, mas seu progresso não é monitorado e controlado,
   e
9. Relatórios de progresso são inadequados ou inexistentes: imaginem só um patrocionador do projeto lhe perguntando em que ponto o
   projeto se encontra. Qual a evolução dos trabalhos no projeto? O projeto está dentro do prazo, escopo e
   custo planejado? Para que se tenha essas respostas, não podemos deixar de fazer o acompanhamento do projeto.
   Precisamos monitorar e controlar todos os principais marcos do
   projeto para que possamos responder as questões com segurança e confiança de que o projeto está sob controle.
10. Quando ocorrem problemas no projeto, as
    pessoas acreditam que os mesmos podem ser resolvidos de forma simples: como disse acima, só conseguimos resolver os
    problemas de um projeto quando temos um bom plano de contingência e um bom mapeamento dos possíveis riscos do projeto. Não podemos achar que todos os
    problemas que podem surgir em um projeto são problemas simples e que, portanto, não precisamos nos preocupar com eles.

Em seu livro Software
Project Secrets (Apress, 2005), George Stepanek apresenta alguns
motivos que, para ele, poderiam tornar os projetos de TI diferentes de
outras áreas e que poderia justificar o número tão alto de fracassos
nesses projetos. Veja alguns deles:

• Complexidade: os projetos de software são normalmente mais complexos que os projetos em outras áreas, talvez por isso eles
  sejam mais suscetíveis a falhas;
• Requisitos incompletos: levantar requisitos para construir um
  software é uma tarefa difícil, exige pessoas
  especializadas no assunto sobre o que trata o
  software e uma grande contribuição por parte dos usuários para passarem seus processos e necessidades;
• Tecnologia muda rapidamente: em nenhuma outra área temos uma evolução tão rápida como na tecnologia da informação. Isso implica em manter uma equipe treinada e atualizada para
  que se consiga manter alta performance e qualidade no processo de desenvolvimento dos softwares.
• Mudanças são consideradas fáceis: porém, não se avalia os impactos da mudança do escopo e os resultados que essas mudanças podem trazer ao projeto como um todo.

Como vimos, vários desses
itens apontados acima são conhecidos por todos os gestores de projetos,
porém, a pergunta que ainda se faz é: por que mesmo conhecendo todos
esses fatores, os projetos de TI ainda falham em uma escala tão grande?

Sabemos que gerenciar esses
projetos é uma tarefa difícil, porém, precisamos nos atentar para os
motivos que podem levá-los ao fracasso. Com isso, fica
evidenciado que a indústria de software, mais do que qualquer outra,
necessita aprimorar suas técnicas de gerenciamento de projetos.

Fica aqui meu desafio!
Acredito que se nos atentarmos para esses e alguns outros pontos em
nossos próximos projetos, teremos grandes chances de melhorarmos os
resultados dos projetos na área de TI, atendendo a todas as expectativas
e principalmente promovendo um retorno satisfatório para os
patrocinadores que investem ou pretendem investir em inovações
tecnológicas.

Pensem nisto e até mais!