O DESAFIO DO SUCESSO EM PROJETOS DE TECNOLOGIA

DA INFORMAO

Andr B. BARCAUI, M.Sc.
Programa de Engenharia de Produo, Universidade Federal do Rio de Janeiro (UFRJ) Tel:
(21) 8115-7268, e-mail: barcaui@uol.com.br



RESUMO


De acordo com estudos recentes realizados pelo Standish Group, o setor de tecnologia da
informao apresenta uma taxa relativamente baixa de sucesso em seus projetos. O objetivo deste
artigo pesquisar as causas por trs destes ndices, moldando o prprio conceito de sucesso
segundo diferentes perspectivas e considerando as caractersticas singulares do ambiente de
tecnologia. Tambm foi realizado um breve estudo de caso com intuito de subsidiar de maneira
emprica a pesquisa e ao mesmo tempo tentar criar uma analogia dos parmetros de sucesso
levantados com a prtica de uma empresa brasileira que tem em seu cotidiano a realidade da
implantao de diversos projetos de tecnologia da informao.

Palavras-chave: Sucesso, Projetos, Tecnologia da Informao, Standish.



ABSTRACT


According to recent studies made by the Standish Group, the information technology
segment demonstrates a relatively low rate of success in its projects. The objective of this article
is to investigate the causes behind these rates, modeling the success concept itself according to
different perspectives and considering the unique characteristics of the technology environment.
A brief study case was also done in order to empirically support the research and at the same time
trying to create an analogy of the success parameters that were raised with a real project scenario
from a Brazilian company that has on its day-by-day activities the implementation of several
information technology projects.

Keywords: Success, Projects, Information Technology, Standish.





2
1.0 INTRODUO


O setor de tecnologia da informao (TI) apresenta historicamente uma grande
desvantagem em relao a segmentos mais maduros da nossa economia. Por exemplo, um dos
setores que h mais tempo trabalha de maneira formal e organizada gerncia de projetos o da
construo civil, onde muito comum que empreendimentos aconteam dentro do prazo previsto,
dentro do oramento e que no desmoronem aps sua concluso. Uma das razes conhecidas por
trs deste fato em funo do tempo que gasto com detalhes do desenho do empreendimento
antes de sua construo. O desenho tem que ficar estvel em determinado momento para que
possa ser construdo. A flexibilidade para mudanas, apesar de reconhecidamente existir, menor
durante seu desenvolvimento.


Quando nos voltamos para projetos de tecnologia da informao essa lgica no
necessariamente a mesma. At em funo das constantes mudanas que o ambiente de negcios
impe a realidade das corporaes e a velocidade da evoluo que TI teve que apresentar para
acomodar estas mudanas de uma forma mais flexvel. No existe outro setor que tenha se
desenvolvido e evoludo tanto e em um ritmo to devastador quanto o de tecnologia (IEEE,
2001). E particularmente quando nos referimos ao desenvolvimento de software esta evoluo
frentica teria que apresentar conseqncias, principalmente no que diz respeito taxa de sucesso
em projetos.


Taxa de Sucesso em Projetos de TI
Falha
15%
C/Problemas
51%
Sucesso
34%

Figura 1. Taxa de Sucesso em Projetos de TI.
Fonte: Adaptado do CHAOS Chronicles v.3 do Standish Group, 2003 pg. 215.


De acordo com a chamada Crnica do CHAOS v.3 do Standish Group a taxa de sucesso
em projetos de tecnologia da informao ainda baixa. De 600.000 projetos analisados, apenas
34% dos iniciados obtiveram sucesso entre os anos de 2001 e 2003. Uma melhoria de 100% em
relao ao mesmo relatrio em sua verso anterior, mas ainda considerada insuficiente em funo
do total de projetos da amostragem. Na mesma pesquisa, ainda mais da metade dos projetos
estavam de alguma forma apresentando problemas ligados a prazo, escopo ou oramento,
conforme pode ser observado na figura 1.

3

Se entendermos que a forma que as empresas tm de atingir seus objetivos estratgicos se
d atravs de projetos (RAD, 2002), e que a rea de TI funciona como um meio viabilizador de
diversas destas iniciativas, as taxas acima podem ser consideradas alarmantes. O chamado
departamento de informtica de uma empresa no trabalha para si prprio. Em geral
praticamente todo voltado a projetos, procurando servir as demais reas da empresa da melhor
forma possvel, atendendo as suas diversas necessidades de negcio.


Partindo desta premissa, no razovel que um setor apresente to baixas taxas de
sucesso. O risco para as diversas iniciativas de uma corporao enorme. Ou existe um erro na
expectativa estabelecida; onde neste caso a prpria definio de sucesso teria que ser revisada, ou
alguma coisa tem que ser feita com objetivo de aumentar estes ndices.



2.0 CONCEITO DE SUCESSO


Um projeto por definio um empreendimento temporrio, com objetivo de criar um
produto, servio ou resultado nico (PMI, 2004). Mas como se define sucesso? A busca por essa
definio talvez seja um dos temas mais discutidos na rea de gerncia de projetos.
Particularmente em tecnologia da informao, onde at mesmo as prprias mtricas que
permitiriam a medio de sucesso tm que ser acordadas.


Segundo o dicionrio Michaelis, a palavra sucesso tem o seguinte significado: su.ces.so:
sm (lat successu): 1 resultado bom ou mau de um negcio. 2 concluso. 3. xito, resultado
feliz.. Em gerncia de projetos, normalmente, existem quatro fatores primrios a serem
analisados relativos definio de sucesso:

Escopo: projeto entregou ou no toda a especificao prevista;
Custos: projeto dentro ou no do oramento previsto;
Tempo: projeto dentro ou no do cronograma previsto;
Qualidade: projeto entregue ou no com qualidade esperada.

Mas nada disso adianta se no agregarmos tambm a satisfao do cliente e sua viso de
como o projeto foi entregue. Curiosamente, os quatro fatores acima podem ser obtidos sem que o
projeto tenha sido considerado um sucesso do ponto de vista do cliente. E o contrrio tambm
vlido: alguns dos pontos acima podem no ser atingidos, mas o cliente ainda sim pode
considerar o projeto um sucesso. Segundo Shenhar (1997), um engenheiro poderia achar que
determinado projeto obteve sucesso tcnico, enquanto que o departamento de finanas poderia
achar que contabilmente o projeto no foi satisfatrio em termos de seu resultado financeiro. O
gerente de recursos humanos poderia achar que houve muito desgaste do time envolvido
enquanto que o diretor da empresa poderia interpretar que o projeto foi um sucesso porque
agregou valor em relao aos seus objetivos estratgicos.

4
Em outras palavras, a medio de sucesso no trivial e depende muito de quem esteja
analisando o projeto. Alm disso, o sucesso pode ser visto de maneira diferente em funo do
tempo e do momento em que estiver sendo analisado (CLELAND, 1999). Estas e outras
caractersticas da medio sugerem que as mtricas de sucesso so fortemente dependentes de
variveis muitas vezes difceis de serem analisadas e muito alm da tradicional medio
envolvendo: escopo, tempo, custo e qualidade.


Em seu artigo, com base em uma pesquisa com mais de 182 empresas de diferentes
segmentos, Shenhar (1997) prope um modelo de visualizao do sucesso em projetos,
considerando dimenses bem definidas envolvendo o grau de importncia de projeto em funo
de seu impacto estratgico e tambm o tempo de anlise de seu resultado. Este modelo procura
agrupar algumas das mtricas j vistas em quatro grandes pilares: eficincia do projeto (escopo,
tempo, custo, qualidade), impacto no cliente (satisfao, resultado), sucesso nos negcios
(retorno de investimento, taxa de retorno, etc.) e preparao para o futuro (suporte a infra-
estrutura, evoluo, etc.), conforme reproduzido no grfico da figura 2.



Figura 2. Importncia relativa das dimenses de sucesso.
Fonte: Adaptado do artigo de Mapping the Dimensions of Project Success de Aaron
Shenhar, 1997 - Pag. 12.


Observando as mtricas de sucesso em funo de sua importncia em cada dimenso e do
tempo em que analisado, comea a ficar mais claro porque to difcil obter um sentimento
completo de sucesso em um projeto. Ainda mais em um ambiente como o de TI que tem que
trabalhar em constante clima de mudana para acomodao dos diversos desafios impostos hoje
por clientes, mercado e sociedade. E a rea de TI acaba funcionando em muitas empresas como
verdadeira espinha dorsal de novas iniciativas. Tanto do ponto de vista de sistemas que traduzam
em realidade as necessidades de negcio, como tambm do ponto de vista de inovao.



5
Mesmo no sendo considerada uma rea-fim (com exceo de empresas que tenham como
objetivo de negcio a prpria tecnologia), TI acaba se tornando uma espcie de elo entre projetos
das mais diversas ordens. Quase tudo que desenvolvido na corporao passa de alguma forma
pela rea de sistemas da informao.


At pelo grau de automatizao de processos e operaes hoje existente. Dado que a
quantidade de recursos para desenvolvimento e manuteno destes projetos no infinita, este
fenmeno pode induzir muitas vezes a determinados gargalos operacionais e insatisfao de
usurios, o que levaria tambm ao insucesso.



3.0 FATORES CRTICOS DE SUCESSO EM TI


De acordo com o estudo do Standish Group (2003), alguns fatores podem ser
considerados crticos para que o projeto obtenha o sucesso esperado. importante notar que
segundo seu relatrio, a presena simples destes fatores no garante o sucesso por si s, mas
tende a aumentar suas chances. Um resumo destes fatores de sucesso pode ser observado no
quadro 1 abaixo:



Fatores de Sucesso Percentual
Envolvimento do Usurio 17%
Suporte Executivo 15%
Gerente de Projeto Experiente 14%
Objetivos claros de negcio 14%
Escopo detalhado 12%
Processo gil de requerimentos 7%
Infra-estrutura padro 6%
Metodologia Formal 5%
Estimativas confiveis 5%
Equipe eficiente 5%

Quadro 1. Fatores de Sucesso em Projeto.
Fonte: Adaptado do CHAOS Chronicles v.3 do Standish Group, 2003 - pg 219.


Uma anlise de cada fator apresentado nos leva a crer que um projeto de TI, assim como
qualquer outro projeto, extremamente dependente de pessoas. Sendo assim, os trs primeiros
fatores crticos de sucesso apontam diretamente para uma varivel das mais difceis de serem
controladas: seres humanos.



6
O envolvimento do usurio considerado fundamental no s porque ele ser obviamente
o consumidor final do produto do projeto, mas tambm para que possam participar ao mximo do
planejamento relativo ao sistema ou equivalente que ser desenvolvido. muito comum usurios
considerarem a rea de TI muito cara ou muito lenta para suas necessidades (HALLOWS, 1998).
Na medida em que participam desde a idia do projeto at a sua concluso passando por todas as
etapas do ciclo de vida de seu desenvolvimento, no s a impresso muda, como novas formas
criativas de implantao so descobertas. Neste processo fundamental que os usurios certos,
que realmente entendem do problema a ser resolvido, sejam envolvidos.


Historicamente, a rea de tecnologia conhecida por dar solues prprias e por vezes
no corretamente integradas com o negcio da empresa. Por outro lado, a rea de TI tambm
sofre por receber pedidos de sistemas de determinados clientes internos que no necessariamente
sero os usurios finais de seus produtos. Este fato pode gerar conflitos que levem ao fracasso do
projeto. Sendo assim, sem o correto envolvimento do usurio, fica muito difcil mensurar o que
ou no importante de ser implantado. A comunicao entre o gerente de projeto, a equipe e os
usurios de fundamental importncia para anlise de requisitos e planejamento do projeto,
assim como tambm servir de base para posterior controle de sua implantao, gerncia de
mudanas e manuteno.


Outro ponto fundamental trata do suporte executivo aos projetos de TI. De acordo com o
relatrio do Standish Group (2003), a correta identificao e apoio dos chamados patrocinadores
do projeto garantem a prpria viabilidade do mesmo. Isso porque so estas pessoas que vo
autorizar o incio e passar a viso do projeto. Patrocinadores no podem assumir o papel de
gerentes. Mas devem acompanhar seu andamento, direcionar os gerentes sempre que necessrio,
acompanhar seu desenvolvimento e ao mesmo tempo zelar pela sade dos objetivos do projeto
(CLELAND, 1999).


Tambm no que diz respeito disputa de recursos, a atuao dos patrocinadores crucial.
Gerentes de projeto normalmente enfrentam o problema de ter a responsabilidade por
determinada iniciativa, mas no necessariamente a autoridade sobre os recursos necessrios a
essa iniciativa. Fatos como estes que poderiam comprometer o sucesso de um projeto, podem ser
amenizados e corrigidos atravs da correta atuao do corpo executivo suportando e arbitrando
em relao a possveis disputas por recursos em uma organizao (PMI, 2004). Ainda mais em
empresas com estruturas organizacionais no-projetizadas, formadas por estruturas matriciais
fracas ou mesmo funcionais.


Ter um gerente de projetos experiente tambm considerado fator crtico de sucesso
segundo o relatrio do Standish Group (2003). Na verdade, segundo o mesmo relatrio, a
comunidade de TI ainda est comeando a entender o verdadeiro papel do gerente de projetos.
Em outras palavras, porque no deixar que programadores desenvolvam o produto e que usurios
o utilizem? Para que incluir mais uma varivel de valor duvidoso, que certamente trar mais
burocracia e menos velocidade ao projeto?


7

Essas e outras perguntas certamente ainda se perpetuam em diversas organizaes que
ainda no reconheceram o real papel do gerente como integrador, organizador e principal
responsvel pelo projeto. Mas este cenrio est gradualmente mudando. A importncia da figura
do gerente torna-se cada vez mais evidente, na medida em que no se trata de conhecimento
tcnico pura e simplesmente, mas principalmente de caractersticas como: habilidades
interpessoais, conhecimento de negcio, metodologia e competncia gerencial (FRAME, 1999).
importante passar o senso de prioridade de cada tarefa no projeto, assim como tambm o
sentido da realizao e o incentivo ligado propriedade pelo trabalho a ser desenvolvido.


Esta atividade at certo ponto ingrata no sentido em que o sucesso do projeto ligado ao
desempenho da equipe, mas o fracasso normalmente imputado ao gerente, como responsvel
final pela implantao. Por isso, quanto maior a experincia, habilidade e vivncia do gerente do
projeto, maiores as chances de sucesso.


Outros fatores que tambm foram levantados na pesquisa apontam que objetivos claros,
requerimentos, infra-estrutura, processos e padres tambm so de vital importncia para o
sucesso de projetos. A juno destes fatores em um ambiente de TI pode ser caracterizada atravs
do nvel de maturidade que este ambiente apresenta. Quanto maior a maturidade, em tese, maior a
probabilidade de sucesso em projetos (KERZNER, 2003).


Em outras palavras, um ambiente mais maduro pressupe a presena de determinados
controles e procedimentos que fazem diferena e que podem ajudar no aumento da taxa de
sucesso em projetos de TI. Para melhorar, preciso antes conhecer o ambiente, saber com ele
funciona e passar a medir de maneira sistemtica sua evoluo. Um modelo que permita medir
esta maturidade e traar metas de evoluo pode ajudar muito o desenvolvimento de uma
empresa em relao aos seus projetos de tecnologia da informao (FIORINI, 2002).



4.0 CMM



No caso de projetos envolvendo desenvolvimento de software, muito comum que sejam
adotadas mtricas ligadas ao prprio ciclo de vida do projeto (HORCH, 1996). Hoje em dia
possvel encontrar diversas corporaes que, formalmente ou no, passaram inclusive a adotar o
CMM (Capability Maturity Model), desenvolvido pela SEI (Software Engineering Institute) da
CMU (Carnegie-Mellon University) como forma de alavancar a desempenho de seus sistemas e
aumentar conseqentemente as chances de sucesso de seus projetos.




8


Figura 3. Modelo CMM resumido e suas ACPs (Key Process Areas).
Fonte: Engenharia de Software com CMM de Soeli Fiorini, 2002. Pg. 20.


O CMM funciona na forma de um modelo de maturidade prescrevendo princpios bsicos
para um desenvolvimento de sistemas efetivo. Seu formato compreende 5 nveis evolutivos que
incorporam determinadas reas chave para o processo (ACPs) de desenvolvimento. Estas reas
chave dentro de cada nvel tm que estar endereadas na organizao para que seja possvel a
evoluo dentro do modelo.


O nvel chamado Inicial corresponde a um ambiente onde o processo de software
caracterizado ocasionalmente como catico e com poucos processos definidos, dependendo
muito de esforos individuais. J o nvel 2 pressupe processos bsicos de gerenciamento j
estabelecidos, controlando custos, cronograma e funcionalidades. Foi chamado Repetitivo porque
a disciplina necessria aos processos permite repetir o sucesso em outros projetos com aplicaes
semelhantes. Um grande salto qualitativo dado quando se sai do nvel 1 de maturidade para o
nvel 2 no CMM (FIORINI, 2002).


No nvel 3 (Definido) o processo de software para as atividades de gerenciamento e
engenharia so padronizados, documentados e integrados em um processo padro de software
para a organizao. O nvel 4 (Gerenciado) pressupe medies detalhadas do processo de
software e da qualidade do produto. Os processos de desenvolvimento e do prprio produto so
quantitativamente entendidos e controlados. O ltimo nvel (5 Otimizado) responsvel pela
melhoria contnua do processo atravs de feedbacks quantitativos e da aplicao de novas idias e
tecnologias.



9
O objetivo deste artigo no analisar o modelo CMM em profundidade, mas apenas
mencion-lo como referncia de aplicao ligada ao sucesso em projetos de tecnologia.
possvel observar que o nvel 2 (Repetitivo) compreende ACPs diretamente ligadas gerncia de
projeto. Tanto do ponto de vista de planejamento quanto de controle. Estas caractersticas,
estando presentes, no so garantias de sucesso, mas tendem a criao e manuteno de um
ambiente mais estvel.



5.0 O DESAFIO DA GERNCIA DE MUDANAS EM TI


Mas at que ponto a estabilidade pode ser garantida em ambientes de TI? De acordo com
a pesquisa realizada por Meyer (2003) e com base em dados do mesmo relatrio do Standish
Group (2003), a taxa de insucesso em projetos de TI aumenta drasticamente quando so
introduzidas mudanas em sistemas. Mesmo em ambientes que respeitem padres e definies
previstas no CMM, a entrada de novas variveis tende a dificultar o controle e desestabilizar
aplicaes. Considerando esta premissa, e que ao mesmo tempo, a realidade aponta para o fato de
que mudanas so inevitveis em qualquer tipo de projeto, preciso garantir de alguma forma
que as diversas alteraes que sejam necessrias, sejam corretamente acomodadas no processo de
gerncia do projeto.

O nome tcnico desta disciplina gerncia de mudanas (PMI, 2004), que no caso de TI
pode ser definida como uma srie de processos e tarefas inter-relacionadas que efetivamente
gerenciam a mudana antes, durante e depois de ocorrerem.


interessante observar que normalmente projetos de TI, e particularmente de
desenvolvimento de software, so muito difceis de serem estimados e planejados desde o incio.
Ou melhor, muito difcil se obter uma correta definio de todas as variveis que podero
influenciar o projeto ao longo de toda a sua execuo. Muitas vezes, at mesmo o produto final
pode no estar 100% claro. E quanto mais longo o projeto, mais difcil se tornam estas
estimativas. Por este motivo mudanas acabam sendo inevitveis.


A conscientizao e a participao de todos os envolvidos em um processo de gerncia de
mudanas consistente catalisa e maximiza as chances de sucesso em projetos de TI (Meyer,
2003). Ainda segundo o mesmo autor, alguns fatores seriam fortes inibidores de uma gerncia de
mudanas efetiva. muito comum, por exemplo, que se considere que um bom sistema de
controle de mudanas automatizado caro ou desnecessrio. Ou que a prpria organizao no se
sinta preparada para gerenciar mudanas adequadamente. Ou ainda o mais comum: achar que o
processo de gerncia de mudanas formal demora muito, e que a organizao no tem tempo para
passar por todos os procedimentos requeridos.



10
Devem ser mencionados tambm os possveis impactos culturais que a introduo de
projetos de TI pode vir a ocasionar. Segundo Cooper (1994), possvel observar uma srie de
fatores que podem levar a uma inibio natural ou at mesmo rejeio de uma nova tecnologia.
Dentre alguns citados pelo autor, esto as mudanas nas tarefas e responsabilidades, mudanas
nas competncias, mudanas no acesso ao poder e aos recursos, na prpria poltica gerencial e
nas modalidades do uso de TI.


Mudanas to profundas e com potenciais de desgaste to elevados na organizao,
deveriam ter um plano de gerncia de mudanas extremamente bem elaborado. Segundo Kotter
(1996), este plano de mudanas passaria dentre outras coisas, por um processo de comunicao
consistente. preciso preparar a organizao para mudanas promovidas por TI em seu
ambiente. So necessrias adaptaes e at mesmo a criao ou re-inveno de antigos processos
para suportar mudanas visando uma evoluo natural da empresa. E se projetos de tecnologia da
informao so hoje cones da promoo desta viso, no razovel ignorar seus impactos, uma
vez que sem isso, no existe a menor perspectiva de inovao.


Enfim, existe um paradoxo formado no sentido em que a mudana em projetos de TI
uma constante. A prpria razo de existir de projetos de TI s faz sentido a partir da premissa de
evoluo e de preparao da empresa para o futuro (Shenhar, 1997). A evoluo s existe atravs
de mudanas, e quanto mais organizao estiver preparada para lidar com esta varivel, maiores
suas chances de sucesso.




6.0 ESTUDO DE CASO



Com o objetivo de tentar estabelecer uma analogia com os pontos explorados at aqui, foi
conduzida uma pesquisa
1
de campo em uma empresa multinacional, sediada no So Paulo, com
matriz nos Estados Unidos, com faturamento anual de U$ 300 milhes e mais de 4000
funcionrios.

A empresa lder no seu setor de atuao, com foco voltado ao setor de indstria e
processos, mas com espinha dorsal extremamente dependente de tecnologia da informao e dos
diversos sistemas que compe seu portflio interno de aplicaes. Em um ambiente deste tipo,
no difcil imaginar a importncia relativa que o setor de TI acaba assumindo.


1
Este pesquisador reconhece que este estudo de caso tem limitaes em funo no somente de sua abrangncia, mas
tambm em funo de seu foco, uma vez que a imensa maioria dos projetos estudados estava relacionada ao
desenvolvimento de sistemas e no representam diversas outras naturezas de projetos de TI. Novas pesquisas seriam
necessrias para que concluses mais profundas possam ser tiradas. O objetivo, portanto, foi to somente o
estabelecimento de uma analogia com a referncia bibliogrfica analisada.

11
Quase nenhum tipo de iniciativa concretizado sem a devida interao com o
departamento de sistemas. Aps 1 ano de anlise deste ambiente, foi possvel observar uma
composio de portflio de projetos segundo as figuras 4 e 5 a seguir.


Tempo Mdio de Projetos
66%
24%
10%
1 a 3 meses 4meses a 1 ano Mais de 1 ano

Figura 4. Tempo mdio dos projetos estudados.


Custo Mdio dos Projetos
45%
51%
4%
at 300 m Entre 301 m e 1M Acima de 1M

Figura 5. Custo mdio dos projetos estudados.


Esta anlise considera todos os projetos finalizados at Dezembro de 2004, de um total de
150 do portflio de TI da organizao. possvel observar que a maioria dos projetos
implantados apresenta pouco tempo de durao (66%). Este cenrio importante para anlise e
analogia com os fatores de sucesso apresentados anteriormente, uma vez que o tempo de
implantao de projetos baixo. Assim sendo, o tempo para acomodao de mudanas e
manobras tambm menor.


Outra varivel fundamental que grande parte dos sistemas desenvolvidos so
terceirizados pela empresa (cerca de 80%). O que significa que a dependncia externa muito
grande. A gerncia de projeto fica por conta da contratante. A empresa no aplica diretamente os
conceitos do CMM, mas exige de seus fornecedores, muitos deles fbricas de software, que
detenham a certificao correspondente a um nvel superior a 2 no modelo de maturidade.

12


A empresa pesquisada tambm valoriza muito sua metodologia de gerncia de projetos.
De origem americana, mas adaptada para facilitar aceitao de forma progressiva na organizao,
a metodologia dita e orienta os passos em todas as iniciativas consideradas como projetos pela
empresa. Considerada como estando ainda em fase de maturao, a metodologia adotada
funciona como um conjunto de processos e ferramentas para todos os gerentes de projeto que
coordenam projetos de TI no departamento. So aproximadamente 40 profissionais, que usam um
mesmo padro para concepo, planejamento, execuo, controle e finalizao de seus projetos.


Analisando os resultados apresentados pelos projetos deste portflio segundo os mesmos
critrios do Standish Group, foi possvel chegar a seguinte concluso conforme a figura 6 abaixo.

Anlise do Portflio (Estudo de Caso)
Sucesso Total
20%
Falha
12%
C/Problemas
68%

Figura 6. Anlise do portflio de projetos segundo sua taxa de sucesso.


Os projetos considerados de sucesso (20%) apresentaram resultados dentro do oramento,
dentro do prazo, com todas as especificaes entregues e com a qualidade esperada pelo cliente.
Este resultado foi obtido atravs da anlise de diversos relatrios de medio de projeto, previstos
na metodologia utilizada na empresa atravs de seu processo de garantia da qualidade.


Por outro lado, projetos que de alguma forma apresentaram problemas dentro das
variveis expostas representam a grande maioria do portflio (66%). Essa tendncia vem de
encontro ao grfico apresentado tambm pelo Standish Group. Ou seja, em um ambiente com as
caractersticas de projetos de TI, continua sendo muito difcil a obteno do sucesso total.


Isso sem considerar as dimenses de tempo e complexidade propostas por Shenhar
(1997), que por enquanto ainda no podem ser completamente revistadas em funo ao tempo de
implantao dos mesmos. A metodologia de gerncia de projetos da empresa estudada prev uma
reviso de projetos ps-implantao que normalmente realizada 1 ano ou mais aps o projeto
implantado. A finalidade desta reviso justamente verificar como o ambiente se comporta aps
determinado tempo de implantao e se o retorno do investimento foi realmente o esperado.

13
Apenas 12% dos projetos apresentaram o que o Standish Group considera como falha por nunca
terem sido executados ou por serem cancelados durante sua implantao.


Ainda como parte da pesquisa, procuramos entender o porqu dos problemas enfrentados
e confront-los com as causas de problemas at ento apontadas neste artigo. O quadro 2 resume
as principais causas de problemas segundo reporte final de projeto de seus respectivos gerentes.


importante ressaltar que a relao de causas por projeto no linear. Em outras
palavras, um mesmo projeto pode ter apresentado mais de uma causa de insucesso. Todas as
causas reportadas foram contabilizadas. No foi levado em considerao o tipo da causa versus o
tipo de impacto no projeto, podendo ser este um objeto de estudo para outra pesquisa.


Causas Reportadas de Insucesso Percentual
Mudanas em Prioridades 25%
Falta de apoio Executivo 20%
Requisitos mal-definidos 18%
No comprometimento do usurio final 13%
Expectativas no-realistas 9%
Falta de controle de mudanas 8%
Outros 7%

Quadro 2. Causas de Insucesso Reportadas.


De acordo com a pesquisa, a grande causa por trs do insucesso de projetos estaria na
mudana de prioridades passada aos gerentes de projeto. Mais especificamente, em uma gerncia
de portflio mal administrada, dado que apesar de ser aceitvel que mudanas de prioridade
aconteam, no razovel que isso se torne uma regra no ambiente.


E este item que vem apontado em primeiro lugar, vem logo de perto seguido por outro
que est totalmente ligado a ele, sob o ponto de vista da alta adminstrao: a falta de apoio
executivo. Assim como reportado no relatrio do Standish Group (2003), esta tambm uma das
maiores causas de insucesso em projetos. Ou seja, a participao executiva, no s no
direcionamento da viso, mas principalmente no suporte do ponto de vista de alocao de
recursos humanos e materiais ponto fundamental em projetos de TI.


Os prximos trs itens que aparecem na lista: requisitos mal definidos, no
comprometimento do usurio e expectativas no realistas passam por um mesmo eixo: baixo
envolvimento do usurio no projeto. Este fato foi passvel de observao a partir de alguns dos
relatrios finais de avaliao de projetos, onde o prprio cliente ou usurio final dava sua
perspectiva sobre o resultado do projeto, alm do gerente.

14
Em alguns casos, at mesmo a empresa contratada para desenvolvimento de algum
produto tambm era encorajada a dar a sua opinio sobre o ocorrido. Normalmente, o escopo
pretendido no tinha sido bem compreendido ou bem repassado. De alguma forma, a pea
principal, o usurio do produto, no estava participando 100% do processo desde seu incio. O
que levava quase sempre a retrabalho ou problemas na execuo, conforme tambm apontava o
relatrio do Standish Group.


Outro fenmeno que no pode ser ignorado na pesquisa o de origem cultural e at
mesmo poltico de toda corporao. Este fenmeno corrobora com as observaes de Cooper
(1994) feitas em seu artigo sobre o impacto da cultura em implantaes de projetos de tencologia
da informao. Este deveria ser o ponto onde o corpo executivo deveria mais atuar para
minimizar efeitos negativos em projetos.


A empresa estudada apresenta fortes traos de uma cultura extremamente voltada para
resultados. At mesmo pela prpria presso de mercado e do segmento em que atua. Isso de certa
forma facilita o comprometimento com os objetivos dos projetos com as caractersticas dos
estudados, mas ao mesmo tempo inibe processos focados em metodologia que sugerem
documentao e acompanhamento. Isso muitas vezes passa a ser considerado uma espcie de
burocracia desnecessria que pode conduzir a atrasos. Existe ainda uma forte visvel resistncia
a qualquer processo de mudana que de alguma forma possa restringir movimentos rpidos e de
improvisao.


De certa forma, a forte caracterstica focada em resultados da empresa e de seus
funcionrios aliada aos seus fortes valores corporativos estipulados desde sua poca de fundao,
faz com que os projetos de TI aconteam. Mas no necessariamente da maneira tima ou com
uma preocupao ligada coleta, armazenamento e disseminao de lies aprendidas. Existe
uma conscincia de que preciso estar sempre inovando. E esta viso, aliada a uma caracterstica
de investimento constante em educao, tem permitido a empresa seguir lder em seu ramo de
atuao.



7.0 CONCLUSES



Projetos em TI so meios de se alcanar objetivos que de alguma forma esto ligados a
uma estratgia de negcio. Se analisarmos o quadro de projetos de sucesso em um ambiente to
complexo quanto o de tecnologia, possvel afirmar que muito ainda existe por ser feito para que
riscos sejam minimizados, usurios fiquem mais satisfeitos, investimentos sejam justificados e
taxas maiores de sucesso sejam alcanadas.



15
As mtricas propostas pelo Standish Group, apesar de comprovadas no estudo de caso
realizado, podem variar dependendo da cultura e da maturidade da empresa analisada. Empresas
que investem em seu aumento de maturidade tendem a ser mais previsveis e apresentarem
melhores resultados.


Ainda em relao ao estudo de caso, o departamento de TI da organizao estudada vem
crescendo a uma taxa mdia de 10% ao ano. Tanto em nmero de funcionrios quanto de
oramento. Isso sem contar suas fortes ligaes com projetos de sua matriz e que so gerenciados
de maneira global. O investimento em aperfeioamento e controles, atravs de metodologias,
credenciamento de fornecedores e treinamento, vem crescendo acompanhando o ritmo e a
evoluo de projetos cada vez mais complexos.


Isso no necessariamente se traduz em sucesso com foi visto nas taxas apresentadas, mas
sugere uma forte preocupao com seu constante desenvolvimento. Estes fatores esto
extremamente ligados adminstrao da empresa como um todo, que demonstra uma forte
dependncia de tecnologia de informao para manuteno de sua sobrevivncia. A empresa
investe porque vislumbra ser este o nico caminho para um desencontvolvimento sustentvel de
longo prazo. E se a forma de crescer atravs de projetos de TI, no existe razo para no
implant-los da melhor maeneira possvel, aumentando a taxa de sucesso total, que hoje de
20%. Isso vale para a empresa estudada, mas vale tambm para toda e qualquer empresa que
possua projetos de TI em desenvolvimento e com as baixas taxas apontadas pelo Standish Group
em sua pesquisa.


Conforme a anlise da referncia bibliogrfica estudada, o caminho para o sucesso em
projetos de tecnologia da informao envolve no somente TI, mas toda a empresa. No existe
uma receita nica ou mesmo um mapa para esta preparao, porque depende muito de cada caso.
Estas observaes levam a crer que a busca pelo sucesso em projetos de TI no reside somente na
tcnica, mas envolve tambm processos, ferramentas, metodologia e principalmente pessoas. Esta
concluso pode ser tirada no s a partir da anlise dos fatores crticos propostos pelo Standish
Group, mas tambm pelo modelo proposto pelo CMM e por todos os demais autores analisados.


O ambiente de mudanas constante dificulta ainda mais a gerncia de projetos. Mas
devidamente encarado como oportunidade, pode passar a ser um instrumento importante de
controle e melhoria continua em direo a satisfao do usurio e aos objetivos de longo prazo da
empresa.








16
REFERNCIAS BIBLIOGRFICAS



CLELAND, David. Project Management - Strategic Design and Implementation 3a edio.
McGraw-Hilll. New York, 1999.

COPPER, Randolph B. The inertial impact of culture on IT implementation. College of
Businesse Administration, University of Houston, Huston, TX. EUA, 1994.

FIORINI, Soeli; STAA, Arndt von; BAPTISTA, Renan. Engenharia de Software com CMM.
Brasoft, Rio de Janeiro, RJ. 2002.

FRAME, David. Project Managament Competency: Building Key Skills for Individuals,
Teams and Organizations. Jossey-Bass Publishers. San Fransisco, CA. EUA, 1999.

HALLOWS, Joylon. Information Systems Project Management. Amacon, Brodway, NY.
EUA, 1998.

HORCH, John. Practical Guide to Software Quality Management. Artech House Publishers.
Norwood, MA. EUA. 1997.

IEEE. Software Engineeirng Body of Knowledge (SWEBoK). Institute of Electrical and
Electronics Engineers. Computer Society, Los Alamitos, California, EUA, 2001.

KERZNER, Harold. Project Management: A Systems Approach to planning, scheduling, and
controlling 8
th
ed. John Wiley & Sons, Inc. Hoboken, NJ. EUA, 2003.

KOTTER, John. Leading Change. Harvard Business School Press. New York, NY. USA, 1996.

MEYER, Bob. IT Change Management: Preparing your IT infrastructure for project
management success . Proceedings of the Project Management Institute Annual Seminars and
Symposium. Houston, TX. EUA, 2003.

PMI. Project Management Body of Knowledge (PMBoK). Project Management Institute.
Newton Square, PA. EUA, 2004.

RAD, Parviz; LEVIN, Ginger. The Advanced Project Management Office: a comprehensive
look at function and implementation. Florida: CRC Press, 2002.

SHENHAR, Aaron. Mapping the Dimension of Project Succes. School of Technology
Management, Stevens Institute of Technology. Hoboken, NJ, EUA, 1997.TANDISH GROUP.
Chaos Chronicles 3.0. The Standish Group International, Inc. EUA, 2003.