UNIP INTERATIVA

Projeto Integrado Multidisciplinar

Cursos Superiores de Tecnologia

Nome: Ricardo Camilo de Sousa

Plo gua verde - Centro

Curitiba Paran
2011

UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia

NOME: RICARDO CAMILO DE SOUSA

O Projeto Integrado Multidisciplinar PIM

parte do Programa Pedaggico dos
Cursos Superiores de Tecnologia a distncia da
UNIP Interativa - Universidade Paulista como prrequisito para aprovao no 2 semestre no curso
de gesto de tecnologia da informao. .

Nome: Ricardo Camilo de Sousa

RA: 1018889
Curso: Tecnologia da Informao
Semestre: 2

Plo gua verde - Centro

Curitiba Paran
2011

INSTITUTO DE CINCIAS SOCIAIS E COMUNICAO

CURSO DE GESTO DE SISTEMAS DE INFORMAO
UNIP/Plo gua Verde - Curitiba/2. Semestre
Ricardo Camilo de Sousa

PROJETO INTEGRADO MULTIDICIPLINAR

COMISSO EXAMINADORA:
_______________________________________________________________
Examinador (1)
_______________________________________________________________
Examinador (2)
_______________________________________________________________
Coordenador do PIM Prof
Observaes:
_______________________________________________________________
___________________________________________________________________
___________________________________________________________________
_______________________________________________________
RESULTADO:
_______________________________________________________________
DATA DA APROVAO: ____ /_____ /______

Resumo

.
O texto a seguir tem como foco a gerncia de projetos e a relao com os
custos oramentrios juntamente com a devida utilizao da infraestrutura.
Teremos uma breve abordagem do setor de tecnologia da informao com
relao economia e as tendncias e previses do mercado atual.
E tambm a infraestrutura ter sua referncia como um dos pilares para a
rea de projetos sendo demonstrada a sua utilizao e referncia. Logo aps ser
tratado da gerncia de projeto, dos prazos e oramentos que tem sido encarada
como um dos grandes desafios dos gestores de projetos, que poder levar em
considerao a metodologia aplicada ao decorrer do texto.

Palavras chaves: gerncia de projetos, custos oramentrios, infraestrutura,

economia, mercado, prazos, metodologia.

ABSTRACT

The following text focuses on project management and relationship with the
budgetary cost along with the proper utilization of the infrastructure.
We will have a brief overview of the sector of information technology with
regard to the economy and the trends and forecasts the market today.
And also the infrastructure will have its reference as one of the pillars of the
project area has demonstrated their use and reference. Soon after will be handled
project management, deadlines and budgets that have been seen as a major
challenge for project managers, which should take into account the methodology
applied to the text.

Keywords: project management, budget costs, infrastructure, economy,

market, timing, methodology.

SUMRIO

1. INTRODUO................................................................................................ 1
2. ECONOMIA MERCADO E TI.......................................................................... 2
2.1 Retrospectiva e previses.............................................................................. 2
2.2 Tendncia...................................................................................................... 3
2.3 Computao nas nuvens............................................................................... 4
2.4 Guia de mercado TI....................................................................................... 5
3. INFRAESTRUTURA E TI ................................................................................5
3.1 Viso ..............................................................................................................5
4. GERNCIA E PROJETOS.............................................................................. 7
4.1 Viso geral..................................................................................................... 7
4.2

Desempenho de projetos............................................................................ 8

4.3 Oramento no prazo..................................................................................... 12

4.4 Escolher uma metodologia........................................................................... 16
4.5 Fechamento do projeto................................................................................. 18
5. CONCLUSO................................................................................................. 20
6. REFERNCIAS............................................................................................... 21

1. INTRODUO

Prazos estourados e oramentos fora dos eixos tm sido uns dos grandes
problemas enfrentados na rea da tecnologia da informao, nestas horas sempre
se pergunta quem deve ser o responsvel pelo atraso de um determinado projeto ou
por um oramento que excedeu seu valor limite? Com isso vimos o fundamental
papel do gerente de projetos e a responsabilidade que lhe incumbe num projeto a
ser realizado.
Ento para que um gerente obtenha sucesso preciso que tenha uma equipe
de sucesso, expondo para sua equipe que tem pela frente um grande desafio sendo
a realizao de um projeto e como os resultados obtidos no final destes projetos
podem trazer transtornos para uma empresa ou at prejuzos. Por isso que o
gerenciamento de TI em projetos tem que ser feito com responsabilidade
Todas as fases do projeto tm que ser feita atravs de analise e testes, a
implantao tambm deve ter um sistema teste, toda a relao do projeto deve ser
destacada num time-line uma linha do tempo onde se destaca todas as fases e
atividade do projeto.
Mais alm de todo este envolvimento que a TI trs para empresa, ela tambm
se destaca na nossa economia, e tem uma movimentao constante.

2. ECONMIA MERCADO E TI

2.1 Retrospectiva e previso

Umas das noticias que aparecem que o setor de TI deve aumentar seu
oramento para 2011, segundo dados da IDC. O estudo nos mostra que os bancos
esto ampliando seu investimento em TI e visando a eficincia operacional e as
seguradoras a elevar da receita.
Com uma recuperao que foi meio tmida dos oramentos em TI em 2010,
aps a forte retrao em 2009 em razo da crise mundial, as instituies financeiras
brasileiras prometem retomar os investimentos neste ano de 2011, conforme revela
o estudo Brazil Financial Insights Investment, realizado pela IDC no Brasil com 33
bancos e 29 seguradoras. Em sua quinta edio, o levantamento mostra que 54%
das 62 empresas tm certeza ou claras intenes de que vo ampliar os
investimentos em TI em 2011 em relao a 2010. Os que afirmam que vo manter o
mesmo volume aplicado no ano de 2010 representam 42% do total. J os que
disseram que vo gastar menos foram 3%.
O relatrio da IDC mostra, ainda, que 61% das instituies financeiras
investiram mais em TI em 2010, 31% mantiveram seus oramentos iguais aos de
2009 e apenas 8% investiram menos. primeira vista, parece que em 2011 o
crescimento dos investimentos em TI ser menor. Porm, o crescimento do ano
passado deve-se em parte a uma recuperao de 2009, que foi um pouco mais
difcil devido crise mundial. Ou seja, impressionante ver que mais da metade das
empresas ainda vai aumentar em 2011 seus oramentos em relao ao ano
passado, que j foi bastante bom, disse Roberto Gutierrez, diretor de consultoria da
IDC Brasil.
O IDC Brazil Financial Insights Investment apontou tambm que para os
bancos a prioridade o aumento da eficincia operacional, enquanto que para as
seguradoras o aumento da receita. Segundo a pesquisa, os grandes bancos
continuam no terceirizando os sistemas 'core' da rea de TI, preferindo mant-los
sob seu controle. Por outro lado, h uma tendncia de aumento da terceirizao de
funes menos crticas, como a impresso departamental, por exemplo. Segundo o
estudo, mais de 20% das instituies pretendem aumentar a terceirizao dessa
atividade.

2.2 Tendncia

A viso encarada por Gartner em relao as tendncia do mercado de TI

que ela no deve mais ser vista como preocupao exclusiva dos CIOs e sim de
todos os funcionrios e executivos da empresa.
Para Gartner existe uma lista de prioridade na rea de TI at 2016, e so:
1. Integrar as equipes de TI com as equipes operacionais, de forma a facilitar o
gerenciamento desses grupos e aumentar a produtividade. O Gartner acredita
que os colocando juntos, os executivos podem trabalhar melhor com
oramentos apertados e estruturar melhor a verba para compra de novos
equipamentos e software;
2. Lidar com a produo e o acesso informao nas mdias sociais. A
consultoria acredita que at 2015, 80% das empresas no sabero abordar a
realidade colaborativa da internet, o que deve impulsionar os gastos nessa
rea;
3. Buscar tecnologias que identifiquem e consigam funcionar de acordo com os
padres de comportamento do mercado. O estudo acredita que os executivos
precisaro cada vez mais de ferramentas que prevejam os perodos de baixa
demanda, para que a produo possa ser ajustada;
4. As tecnologias de geolocalizao ser uma grande oportunidade para o
mercado de telecomunicaes, o qual o Gartner prev que mudar de
negcios baseados em servios para baseados em aplicaes. A consultoria
acredita que o mercado de ferramentas de geolocalizao alcanar receita
de US$ 215 bilhes at o fim de 2012, enquanto cerca de US$ 150 bilhes do
oramento de servios das operadoras de telecom sero transferidos para
aplicaes;
5. O Gartner acredita que at 2016 todas as empresas usaro computao em
nuvem. Segundo a pesquisa, nos prximos anos as relaes de consumo de
tecnologia vo se alterar e cada vez mais as companhias buscaro formas de
fornecer pela internet. A consultoria prev que at 2014 o mercado de cloud
computing ter receita de US$ 148,8 bilhes;

2.3 Computao em nuvem

Vimos que Gartner relatou que as empresas usaro computao em nuvem,

mais na realidade qual a importncia deste conceito, vamos abordar um pouco a
relao deste empreendimento.
Vamos dizer que exista um executivo de uma grande empresa. Suas
responsabilidades incluem assegurar que todos os seus empregados tenham o
software e o hardware de que precisam para fazer seu trabalho. Comprar
computadores para todos no suficiente - voc tambm tem de comprar software
ou licenas de software para dar aos empregados s ferramentas que eles exigem.
Sempre que voc tem um novo contratado, voc tem de comprar mais software ou
assegurar que sua atual licena de software permita outro usurio. Isso to
estressante que voc tem dificuldade para dormir todas as noites.
Breve, deve haver uma alternativa para executivos como voc. Em vez de
instalar uma sute de aplicativos em cada computador, voc s teria de carregar uma
aplicao. Essa aplicao permitiria aos trabalhadores logar-se em um servio
baseado na web que hospeda todos os programas de que o usurio precisa para
seu trabalho. Mquinas remotas de outra empresa rodariam tudo - de e-mail a
processador de textos e a complexos programas de anlise de dados. Isso
chamado computao em nuvem e poderia mudar toda a indstria de computadores.
No que parece a computao em nuvem esta sendo um campo emergente da
cincia da computao, a idia j se faz presente h anos e como o prprio no diz
computao em nuvem porque os dados e aplicaes existem em uma nuvem de
servidores na web.
Em um sistema de computao em nuvem, h uma reduo significativa da
carga de trabalho. Computadores locais no tm mais de fazer todo o trabalho
pesado quando se trata de rodar aplicaes. Em vez disso, a rede de computadores
que faz as vezes de nuvem lida com elas. A demanda por hardware e software no
lado do usurio cai. A nica coisa que o usurio do computador precisa ser capaz
de rodar o software da interface do sistema da computao em nuvem, que pode ser
to simples quanto um navegador web, e a rede da nuvem cuida do resto.
H uma boa chance de voc j ter usado alguma forma de computao em nuvem.
Se voc tem uma conta de e-mail com um servio baseado na web, como Hotmail,
Yahoo! ou Gmail, ento voc j teve experincia com computao em nuvem. Em

vez de rodar um programa de e-mail no seu computador, voc se loga numa conta
de e-mail remotamente pela web. O software e o armazenamento da sua conta no
existem no seu computador, esto na nuvem de computadores do servio.

2.4 Guia mercado TI

Vimos que a relao da economia e o mercado de TI so dois plos unidos

em beneficio a uma economia evolutiva e crescente num pas. Agora estamos vendo
que o mercado esta dando mais disposio para enfrent-la uma rea que tem um
grande potencial econmico.

3. INFRAESTRUTURA E TI

3.1 Viso

Numa rea porturia, por exemplo, um setor onde se um nvel de

movimentao constante, basicamente h trabalho vinte quatro horas por dia, onde

se movimente containeres e etc. Os Terminais Porturios so responsveis pela

maior parte do trabalho de movimentao e entrega de produtos negociados no
mundo. De gros a carros, todo tipo de mercadoria pode cruzar mares e oceanos
criando valor para os homens de negcio e consumidores pelo mundo todo
utilizando este modal (Oliveira & Maada, 2001). No Brasil, atualmente, 93% do
comrcio exterior so escoados por transporte martimo (Tecnologstica, agosto
2001) e conforme Caridade (2000) o futuro da gesto logstica nos terminais
porturios ser basicamente atravs do gerenciamento da informao.
Para Weill & Broadbent (2000), a infra-estrutura de TI base da capacidade
da tecnologia de informao, tida como servios confiveis compartilhados pela
empresa e coordenada centralmente, geralmente pelo grupo de sistemas de
informao.
A ateno dispendida na busca pela harmonia da Tecnologia de Informao
com a empresa pode afetar significativamente a competitividade e eficincia do
negcio. Nesta discusso, o ponto principal saber como a TI pode ajudar a
alcanar vantagem competitiva e estratgica para a empresa (Luftman et. al., 1993).
Logo, o desafio para as empresas saber qual conjunto de servios de infraestrutura so apropriados para seu contexto estratgico (Weill & Broadbent, 1996).
O conjunto de servios de infra-estrutura fornece a capacidade humana e
tcnica que alavanca a capacidade do negcio necessria para o posicionamento
competitivo da empresa. A maneira como os servios bsicos de infraestrutura so
oferecidos e utilizados variam entre diferentes empresas e so geralmente
relacionados a viso da empresa sobre o papel da infra-estrutura de TI.
Will & Broadbent (2000) utilizaram cinco conceitos para a identificao da
viso de infra-estrutura de TI: investimentos em TI com relao ao total de vendas
(ltimos 5 anos), investimentos em TI em relao ao investimento total (ltimos 5
anos); frmula de benchmark, conjunto de servios e reach and range . Porm,
optou se por utilizar apenas os dois ltimos, visto que os dois primeiros so itens de
difcil (se no impossvel) levantamento dentro das empresas nacionais e o terceiro
no se encontram bem explicado no artigo de origem. Logo, tomou-se por base que
a viso de infraestrutura pode ser identificada combinando-se dois conceitos:
conjunto de servios de infra-estrutura de TI (abordado acima) e reach and range o
qual o descreve os limites de infra-estrutura da empresa (Keen, 1991). Reach
descreve quais locais e com quem a infra-estrutura permite conectar, enquanto

range refere-se funcionalidade em termos das atividades e servios que podem

ser realizados e compartilhados automaticamente entre cada nvel de reach (Weill
& Broadbent, 2000).

4. GERNCIA E PROJETOS

4.1 Viso geral

Vamos abordar a rea de projeo, primeiramente o que um projeto? O

projeto seria algo que tem inicio e fim determinado, e entre o lapso do inicio do fim
utilizamos um esforo com a finalidade de criar um produto ou servio nico onde o
resultado diferenciado entre alguns aspectos.
Os projetos por ter finalidade e aspetos diferenciados, alguns exemplos de
projetos pode ser o desenvolvimento de um novo produto ou servio, ou
desenvolvimento de um modelo de veiculo ou at mesmo uma campanha para
algum cargo poltico e tambm o desenvolvimento e aquisio de um sistema.
A pessoa que tem por competncia de seu desenvolvimento o gerente de
projetos, no qual ele tem o objetivo de desenvolver o produto ou servio esperado
dentro do prazo, custos, e nvel de qualidade desejada.
As figuras importantes num projeto so os stakeholders; so indivduos e
organizaes envolvidos no projeto que sero afetadas positivamente ou
negativamente pelo resultado final. Podemos destacar o chefe, a organizao, a
equipe, o cliente, o patrocinado e gerente do projeto.
As operaes so conjuntos de aes cujo resultado, em um dado perodo,
contribui para o atendimento de uma necessidade administrativa ou operacional da
organizao. Elas so caracterizadas por ter um objetivo que pode ser medido
qualitativamente ou financeiramente e dar condio de um funcionamento normal.
A semelhana entre projetos e operaes se encontra no recurso limitado e
restrito onde so planejados executados e controlados por pessoas. J se
diferenciam por as operaes possuem atividades repetitivas e continuas j nos
projetos so atividades temporrias e nicas.
J os programas so uns grupos de projetos designados a alcanar um
objetivo estratgico mais abrangente e caracterizado por ter um termo mais
utilizado em governos tal como o projeto limitado no tempo, mas sua durao

bem maior (anos e anos). Os projetos constituem a execuo do programa para

atingir os seus objetivos por terem um longo perodo, podem incluir operaes.

4.2 Desempenho de projetos

Um conceito de sucesso percebido que os projetos que no atingiram suas

metas originais de custo, prazo e qualidade no eram, necessariamente,
reconhecidos como projetos fracassados pelas pessoas envolvidas em seu
desenvolvimento. Assim, o sucesso de um projeto estaria ligado percepo que os
envolvidos (stakeholders) tm do sucesso/fracasso do projeto. Pinto e Slevin (1986)
apresentam uma definio de desempenho de projetos que considera tanto os
aspectos internos como os externos.

Fatores internos
Custo grau de atendimento ao
oramento inicial do projeto
Prazo cumprimento dos prazos
inicialmente estabelecidos
Desempenho tcnico grau em que o
projeto atende as especificaes
tcnicas implcitas e explcitas

Fatores externos
Uso se o projeto usado de acordo
com sua proposta original
Satisfao a satisfao com o
processo pelo qual o projeto est sendo
ou foi realizado
Eficcia o projeto ir beneficiar
diretamente seus usurios

Fonte: adaptado de Pinto e Slevin (1986)

Lim e Mohamed (1999) tambm reconhecem a importncia da percepo de

sucesso. Eles destacam que a percepo de sucesso no , necessariamente, a
mesma para os diferentes atores envolvidos com o projeto. Eles trazem viso de
desempenho em duas categorias: macro e micro. Do ponto de vista macro, o
sucesso do projeto s pode ser obtido em sua fase operacional, quando do uso do
produto gerado pelo projeto. Assim, o macro sucesso depende dos usurios,
principalmente. Do ponto de vista micro, o sucesso do projeto ir depender da
execuo das tarefas e etapas do projeto. Assim, essa diviso micro e macro
volta-se para avaliaes de processo e de produto, respectivamente. Essa viso de
produto e de processo compartilhada por outros autores.

Cooke-Davis (2000) trabalha com dois conceitos separados. O primeiro

chamado de sucesso do projeto medido atravs do grau de consecuo dos
objetivos globais do projeto. Por exemplo, um projeto tem como objetivo gerar, por
meio do lanamento de um produto mais moderno, o aumento da participao de
mercado, ou desenvolver competncias em tecnologias especficas, etc. O segundo
conceito o de sucesso da gesto de projeto, cuja medio feita com indicadores
de cumprimento de prazos, oramentos e conformidade com padres de qualidade
estabelecidos para o projeto.
Baccarini (1999) utiliza, tambm, dois conceitos distintos de desempenho:
sucesso da gesto do projeto (viso de processo) e sucesso do produto (viso de
produto). O sucesso do processo est ligado aos aspectos clssicos de
desempenho (prazo, custo e especificaes de qualidade tcnica), satisfao dos
stakeholders como desenvolvimento, e a qualidade do processo de gesto.
Apesar de reconhecer a importncia ltima do sucesso do produto, Baccarini
(1999) lembra que o sucesso da gesto do projeto (processo) tende a influenciar
(positivamente) o sucesso do produto. Ele destaca que, como a avaliao do
desempenho depende de quem avalia e do instante da avaliao, importante
estabelecer, a priori, os critrios de sucesso que sero utilizados em um projeto em
particular.
O conceito de sucesso utilizado por Dvir et al (1998) possui duas dimenses:
benefcios percebidos pelo consumidor e cumprimento de metas de projeto (design),
o que sugere, tambm, uma diviso do conceito de sucesso medida que os
benefcios percebidos pelo consumidor s podem ser avaliados aps algum tempo
de uso do produto do projeto, ao contrrio do cumprimento das especificaes, que
pode ser avaliado durante o desenvolvimento e ao trmino do projeto.

Dimenso do sucesso

Medidas/variveis utilizadas

Comprimentos de metas no projeto

Especificaes funcionais
Especificaes tcnicas
Prazo
Oramento
Cumprimento das metas de aquisio
Cumprimento dos requisitos
operacionais
Produto entrou em operao

10

Benefcios percebidos pelo consumidor

Chegou a tempo aos usurios finais

O produto foi utilizado durante um
perodo substancial de tempo
O produto melhorou substancialmente o
nvel de operao do usurio
Usurio satisfeito com o produto
Fonte: Dvir et al (1998)

Shenhar et al (2001) no reconhecem a existncia de dois conceitos distintos de

sucesso de projeto e sucesso de produto e defendem a idia de que a importncia
relativa das dimenses do sucesso do projeto muda com o passar do tempo. Esses
autores identificaram as seguintes dimenses do sucesso:

Eficincia do projeto (cumprimento de prazos e oramentos);

Impacto no consumidor (satisfao do cliente e qualidade do produto);

Sucesso do negcio (gerao de receita, lucro, share e outros benefcios para

a organizao me); e

Preparao para o futuro (desenvolvimento de infra-estrutura organizacional

e/outecnolgica para o futuro).

Contudo, a proposta desses autores, tambm, reconhece que a avaliao de

cada dimenso no pode ser feita todas no mesmo instante. Elas tm horizontes
diferentes (figura 3).
A importncia relativa de cada dimenso varia com o tempo e com a incerteza
tecnolgica. No curtssimo prazo, a eficincia do projeto a mais importante e
tambm a nica passvel de ser medida com uma preciso confivel. Com o uso do
produto desenvolvido, torna-se possvel e relevante a avaliao das demais
dimenses.

11

Em projetos de baixa incerteza tecnolgica, as expectativas em relao ao

projeto esto muito mais ligadas a contribuies marginais em que a eficincia do
desenvolvimento fator determinante. Por exemplo, ao fazer uma atualizao de um
produto, o interesse est em manter o produto de acordo com as especificaes de
mercado e no se espera que isso v alterar o ciclo de vida do produto. Quando se
trabalha com grandes inovaes e com grandes incertezas tecnolgicas, as
organizaes se tornam mais tolerantes a uma baixa eficincia do projeto. Isso
porque existe a expectativa de que o projeto possa, eventualmente, gerar uma
competncia interna em uma nova e emergente tecnologia.
Como pode se observar pelos autores comentados acima, existe uma
variao em termos de indicadores de desempenho apesar de haver uma certa
convergncia em relao s dimenses do desempenho de projetos. Uma diferena
marcante entre as propostas apresentadas refere-se discusso em torno da
questo da quantidade de conceitos relacionados ao desempenho. Enquanto alguns
(LIM e MOHAMED,1999, COOKE-DAVIES, 2000, BACCARINI,1999,MUNNS 1997)
referem-se a dois conceitos distintos sucesso da administrao de projeto (foco no
processo de desenvolvimento) e sucesso do projeto (foco no produto resultante do

12

projeto) outros (SHENHAR et al., 2001; BAKER et al. 1983; PINTO e SLEVIN,
1988) entendem que existe um elemento nico em discusso que possui
caractersticas multidimensionais, em que a relevncia de cada dimenso varia com
o tempo.

Dimenso do sucesso

Medidas/variveis utilizadas

Eficincia do projeto

Meta de prazo
Meta de oramento

Impacto no consumidor

Desempenho funcional
Conformidade s especificaes tcnicas
Preenchimento das necessidades do cliente
Resoluo dos problemas do cliente
Uso do produto pelo cliente
Satisfao do cliente

Sucesso do negcio

Sucesso comercial
Aumento ou criao de participao de mercado

Preparao para o futuro

Criao de novo mercado

Criao de nova linha de produto
Desenvolvimento de nova tecnologia
Fonte: Shenhar et al (2001)

4.3 Oramento no prazo

Na maioria das vezes grandes projetos remetem a grandes problemas, no

importando qual ferramenta, metodologia utilizada ou equipe. Vemos prazos
estourados, oramentos muito alm do limite e os resultados no correspondendo s
expectativas dos stakeholders.
Como uma tendncia forte, a Tecnologia da Informao e os Sistemas de
Informao tornaram-se cada vez mais importantes para a estratgia empresarial.
Em conseqncia, os investimentos em TI tendem a formar uma parte
substancial da carteira de investimentos das empresas. Entretanto, parte desses
investimentos no tem trazido o resultado esperado para os negcios, porque muitos
dos projetos de TI que so iniciados em empresas de todo porte simplesmente
falham.
Falhas nos projetos de TI, como atrasos, escalada de custos e falta de
qualidade, tm sido apontadas como os grandes viles pela incapacidade de

13

contribuio desses projetos aos objetivos finais do negcio. Em decorrncia dessas

falhas e respectivas causas, projetos de TI tem sido alvo de muitos estudos.
De acordo com o PMI, a maioria dos projetos de TI tem seus custos
excedidos e cerca de 88% deles ultrapassam o planejamento, o oramento ou
ambos.
Sabemos que a TI complexa e suas incertezas aumentam muito o risco
daqueles que executam e planejam TI. Portanto, um processo tecnolgico 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. Porm existem razes mais comuns que levam ao
fracasso o maior nmero de projetos.
Fergus O`Connell, em sua obra "How to Run sucessful Hig-Tech ProjectBased Organizations (Artech House, 1999)", apresenta uma relao dos dez
principais motivos que levam os projetos de TI ao fracasso e eu os comento abaixo.
So eles:
1. Os objetivos do projeto no so bem definidos e/ou os envolvidos

no so

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 prope desenvolver.
2. Os objetivos do projeto so definidos de forma apropriada, mas as mudanas
no so identificadas: no gerenciar as mudanas nos projetos faz com que o
escopo pr-definido se perca e muitas das vezes o estouro do prazo se
dar em conseqncia dessa falta de controle. Todos os envolvidos podem
solicitar mudanas no projeto, mas necessrio que se tenham critrios para
analisar o impacto e a viabilidade e, somente depois, aprov-las.
3. O projeto no planejado de forma apropriada: o planejamento

fundamental para o sucesso do projeto, no se pode esperar muito de um

projeto que no fora estudado e que no tenha seus objetivos claros.

4. O projeto no gerenciado de forma apropriada: no mnimo, preciso que se

tenha na equipe pessoas qualificadas e com o conhecimento de alguma
metodologia e nas melhores prticas de gerenciamento de projetos.

14

5. O projeto planejado de forma apropriada, porm seus recursos no so

gerenciados: o que acham disso? claro que qualquer recurso envolvido em
uma atividade e que no possua uma coordenao

ou direcionamento

ter dificuldades em cumprir os prazos propostos.

6. No so criados planos de contingncia: quando no se tem um bom plano
de contingncia para os possveis riscos do projeto, inevitavelmente o que
ocorrer quando eles aparecerem ser uma paralisao no projeto. Atuar de
forma corretiva no a melhor soluo, portanto, procure avaliar os possveis
riscos e montar as contingncias para caso eles ocorram.
7. As expectativas dos envolvidos com relao ao projeto no

so

gerenciadas: o que no podemos esquecer que cada envolvido no projeto

tem suas prprias expectativas. O desenvolvedor tem suas expectativas em
relao documentao 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 no
monitorado e controlado, e.
9. Relatrios de progresso so inadequados ou inexistentes: imaginem s um
patrocinador do projeto lhe perguntando em que ponto o projeto se encontra.
Qual a evoluo dos trabalhos no projeto? O projeto est dentro do prazo,
escopo e custo planejado? Para que se tenham essas respostas,
no podemos deixar de fazer o acompanhamento do projeto. Precisamos
monitorar e controlar todo o principal marcos do projeto para que possamos
responder as questes com segurana e confiana 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
contingncia

um

bom

mapeamento

dos

possveis

riscos

do

projeto. No podemos achar que todos os problemas que podem surgir em

um projeto so problemas simples e que, portanto, no precisamos nos
preocupar com eles.

15

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 nmero to alto de fracassos nesses
projetos. Vejam alguns deles:

Complexidade: os projetos de software so normalmente mais complexos que

os projetos em outras reas, talvez por isso eles sejam mais suscetveis
falhas;

Requisitos incompletos: levantar requisitos para construir um software uma

tarefa difcil, exige pessoas especializadas no assunto sobre o que trata o
software e uma grande contribuio por parte dos usurios para passarem
seus processos e necessidades;

Tecnologia muda rapidamente: em nenhuma outra rea temos uma evoluo

to rpida como na tecnologia da informao. Isso implica em manter uma
equipe treinada e atualizada para que se consiga manter alto desempenho e
qualidade no processo de desenvolvimento dos softwares.

Mudanas so consideradas fceis: porm, no se avalia os impactos da

mudana do escopo e os resultados que essas mudanas podem trazer ao
projeto como um todo.
Como vimos vrios desses itens apontados acima so conhecidos por todos

os gestores de projetos, porm, a pergunta que ainda se faz : por que mesmo
conhecendo todos esses fatores, os projetos de TI ainda falham em uma escala
to grande?
Sabemos que gerenciar esses projetos uma tarefa difcil, porm,
precisamos nos atentar para os motivos que podem lev-los ao fracasso. Com isso,
fica evidenciado que a indstria de software, mais do que qualquer outra, necessita
aprimorar suas tcnicas de gerenciamento de projetos.
Acredito que se nos atentarmos para esses e alguns outros pontos em nossos
prximos projetos, teremos grandes chances de melhorarmos os resultados dos
projetos na rea de TI, atendendo a todas as expectativas e principalmente
promovendo um retorno satisfatrio para os patrocinadores que investem ou
pretendem investir em inovaes tecnolgicas.

16

4.4 Escolher uma metodologia

Uma metodologia um processo a seguir que d maior controle sobre os

recursos que sero utilizados no projeto. Controlando melhor o processo a equipe
ser mais eficiente, pois entregar o projeto com maior grau de acerto em termos de
prazos e custos. O bom uso de uma metodologia importante porque permite evitar
prticas que levam ao insucesso e com isso reproduzir o sucesso.
A falta comunicao, os boatos e outras formas de rudos tomam seu lugar.
Na falta de verso oficial, ficam circulando informaes que podem minar a moral da
equipe e levantar suspeita sem fundamento. O gerente de projeto deve evitar esse
tipo de prtica, dando informaes claras e confiveis sobre o status do projeto.
Certamente esta uma rea em que a diplomacia essencial. Se h um problema,
o gerente de projetos pode e deve no s falar sobre ele, mas tambm informar que
est trabalhando na soluo, e no apenas comunicar que o problema existe.
Problemas sem uma perspectiva de soluo so angustiantes e causam um
desconforto na equipe que muitas vezes desnecessrio.
A criao de relatrios de progresso do projeto ajuda no processo de
comunicao, sobretudo por que torna o processo impessoal e mais objetivo.
Imagine o efeito de um email onde se critica um membro da equipe pelo atraso do
projeto. Imagine a mesma informao vinda de um relatrio em que a data de
trmino real de uma tarefa est em branco: objetivamente a situao a mesma, o
indivduo no fez a sua parte, mas no caso do email a pessoa envolvida pode se
melindrar. No relatrio, temos um dado objetivo, que salta aos olhos, mas que no
gera ressentimentos.
Definir um escopo do projeto o trabalho que deve ser realizado para se
obter um produto ou servio com determinadas caractersticas e recursos. Comece
por definir o que deve ser feito e o que no deve. Esse processo nos permite
entender os contornos do projeto e traar uma linha divisria entre o que deve ser
feito e o que no deve ser pelo menos neste momento. Muitos novatos se perdem
em discusses interminveis sobre recursos do produto final que o tornariam
perfeito. Sempre me lembro de um amigo muito experiente que, ante a minha nsia
em acertar todos os detalhes logo de cara, me dizia que o timo inimigo do bom,
ou seja: enquanto perseguimos o timo nos distanciamos de algo que est bem
mais prximo, o bom, que temos mais chance de conseguir atingir.

17

Em paralelo, deve ser elaborado um oramento levando em conta quantas horas de

cada profissional sero necessrias. Veja um modelo simples:
Profissional

Tarefa 1

Tarefa 2

Tarefa 3

T.Total (h)

Custo/h

Custo

Gerente de projeto

20

23

150,00

3.450,00

Lder de projeto

10

15

80,00

1.200,00

Analista Snior

20

20

50,00

1.000,00

Programador

40

20

60

30,00

1.800,00

Testador/Documentador

20

30

50

15,00

750,00

Total

168

8.200,00

Gerenciamento de projetos tem que ter a devida proteo do escopo. Projetos

que ficam mudando o escopo durante sua execuo tm srias dificuldades em
cumprir o cronograma e estouram o oramento. O risco mais comum o que se
chama de scope creep, quando o escopo vai crescendo medida que o cliente vai
entendendo suas necessidades e reformulando seus objetivos.
O gerente do projeto deve ter calma e analisar com cuidado cada demanda:
ao rejeitar um pedido, ele pode se indispor com o cliente, mas se aceitar ele pode
estar se prejudicando , j que o prazo e oramento no sero to elsticos quanto
as exigncias. Devemos sempre contar com uma determinada margem de manobra,
mas nos tempos atuais, em que eficincia a palavra que est na ordem do dia, os
compromissos assumidos pelo gerente podem se transformar num sacrifcio, muitas
vezes desnecessrio, para toda a equipe.
Em projetos de software, o scope creep uma situao to comum que no
d para come-los sem tomar algumas precaues. O primeiro cuidado negociar
a forma de remunerao: fixa ou varivel. Se for fixa, o risco das mudanas est
toda com o gerente do projeto, se for varivel, o cliente assume os custos extras.
Mesmo neste caso, o gerente do projeto deve cuidar para que o cliente seja
informado a priori dos novos custos. Por precauo, eu sempre redijo um adendo ao
escopo colocando o que ser feito, em quanto tempo e a que custo.
Documentar meticulosamente o escopo do projeto muito importante. Este
documento resume o que ser feito, com que caractersticas e com que recursos.
Ele um quase-contrato, mas no traz as clusulas de resciso e as penalidades.
Neste momento, tudo est bem e todos concordam. S que, na cabea de cada um,
h uma imagem diferente do que ser o produto final. medida que este produto vai

18

tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou no
bem aquilo e podem comear as decepes.
importante que o gerente do projeto conhea os interesses de todos os
envolvidos. Imagine como arriscado contar com um membro da equipe que no
est disposto a colaborar. Ele pode ser um problema mais do que uma soluo
dentro do grupo: sabendo disso, melhor pensar em chamar outra pessoa. Eu passei
por uma situao destas quando fui destacado para gerenciar um projeto onde havia
um colaborador mais antigo e que entendia que ele quem deveria estar
gerenciando. Eu no percebi seu ressentimento a princpio e medida que o projeto
avanava esta pessoa se tornava um problema cada vez maior, na medida em que,
no s ele no fazia a sua parte, como minava os demais membros da equipe contra
minhas decises.

4.5 Fechamento do projeto

O incio do projeto um momento solene. O patrocinador deve formalizar a

todos os envolvidos que o projeto est iniciado e o cronmetro est correndo. Muita
gente no gosta de se preocupar com isso, mas imagine que haja resistncia de
setores da empresa que se opem ao projeto. Sem um documento que atesta que o
projeto comeou, o gerente pode no conseguir apoio algum. Alm disso, este
documento funciona como um cumpra-se de uma autoridade da empresa: no
cabe discutir a ordem, o projeto comeou e todos os arrolados devem participar.
Outro momento importante o do encerramento do projeto. preciso
formalizar o final para que fique claro para todos os envolvidos, especialmente para
o cliente, que o projeto est concludo e que novas necessidades sero atendidas
em um novo projeto. Qualquer extenso ou alterao dever ser orada e todo o
ciclo se inicia novamente. Com relao manuteno do sistema entregue no se
pode consider-lo um projeto na medida em que, a princpio, trata-se de um
processo contnuo. O que pode ocorrer definir-se projetos ao longo da vida til do
sistema com o objetivo de melhor-lo. Por exemplo, a atualizao dos equipamentos
eletrnicos (avinicos) de um avio para auxlio ao vo um projeto que se
distingue da sua manuteno rotineira.
Ao final faz-se tambm uma reunio de avaliao dos erros e acertos da
equipe. Chamadas de reunies "post-mortem", elas servem para se gerar uma lista

19

de "melhores prticas" contribuindo para a formao de uma base de conhecimento

que poder ser muito til em projetos futuros. Da minha experincia pessoal, posso
dizer que tirei grandes lies quanto s "piores prticas", atitudes e decises que se
mostraram ruins e que devem ser evitadas em projetos futuros.
A tabela logo a abaixo serve para finalizar nosso texto, e como um guia a ser
seguida por um gerente de projetos, ela mostra o pontos detalhados do projeto com
todas as aplicaes e momentos do projeto todos relacionados entre si.

20

5. CONCLUSO

Conduzir um projeto para o sucesso certamente uma tarefa difcil para

qualquer gerente, os imprevisto, riscos sempre vo aparecer, e a nica forma de se
obter algum proveito implantando planos de controle e preveno de riscos.
Porque o tempo nunca nosso aliado, e se no houver planejamento bem
elaborado e um bom controle e gerenciamento com certeza o projeto ira sair dos
trilhos. O segredo envolver a equipe, cliente e fornecedores de tal forma que todos
se sintam diretamente responsveis pelo sucesso do projeto.
A principal qualidade do gerente de projeto saber se comunicar bem com
todos. Ele o ponto focal das informaes, nele convergem s informaes que ele
depois dever processar e divulgar para todo o restante da equipe.
Acima de tudo, gerenciar projetos planejar e acompanhar a execuo
sempre atendo em todos os detalhes. O gerente do projeto deve se manter alerta e
flexvel com os acontecimentos do dia-a-dia, mas deve estar sempre se reportando
ao plano inicial para no perder o controle.

21

6. REFERNCIAS
COOKE-DAVIES, T. The real success factors on projects. IN International Journal of
Project Management vol. 20, pp. 185-190, 2000.

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

Keen, P. G. W.(1991). Shaping the Future: Business Design Through Information

Technology. Cambridge, MA.

LIM, C. S. & MOHAMED, M. Z. Criteria of project success: an exploratory reexamination. IN International Journal of Project Management vol. 17, no. 4, pp. 243248, 1999

Luftman, J. N. et. al.(1993). Transforming the enterprise: The alignment of business

and information technology strategies. IBM Systems Journal, vol. 32, n 1, p.198-221.

MUNNS, A. K. & BJEIRMI, B. F. The role of project management in achieving project

success. IN: International Journal of Project Management vol 14 no. 2 pp. 81-87,
1997.

O`Connell, Fergus How to Run sucessful Hig-Tech Project-Based Organizations

(Artech House, 1999)

Oliveira, R. M. & Maada, A. C. G.(2000). Fatores que afetam os investimentos em

Tecnologia de Informao: O caso de um Terminal de Containers. XX Encontro
Nacional de Engenharia de Produo (ENEGEP). So Paulo.

PINTO, J. K. & SLEVIN, D. P. Project Success: Definitions and Measurement

Techniques IN: International Journal of Project Management , 1988

PMI. Project Management Body of Knowledge (PMBoK). Project Management

Institute. Newton Square, PA. EUA, 2004.

22

SHENHAR, A. et all Project success: a multidimensional strategic concept. IN Long

Range Planning, no. 34, pp. 699-725, 2001

Stepanek George Software Project Secrets (Apress, 2005)

Weill, P. & Broadbent, M.(2000). Managing IT Infrastructure: A Strategic Choice.

In.:ZMUD, R.. Framing the Domains of IT Management. Malloy Lithographing, Inc.,
Ann Arbor, Michigan.