1. UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia
Nome: Ricardo Camilo de Sousa
Pólo Água verde - Centro
Curitiba – Paraná
2011

2. UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia
NOME: RICARDO CAMILO DE SOUSA
O Projeto Integrado Multidisciplinar – PIM
parte do Programa Pedagógico dos
Cursos Superiores de Tecnologia a distância da
UNIP Interativa - Universidade Paulista como pré-
requisito para aprovação no 2º semestre no curso
de gestão de tecnologia da informação. .
Nome: Ricardo Camilo de Sousa
RA: 1018889
Curso: Tecnologia da Informação
Semestre: 2
Pólo Água verde - Centro
Curitiba – Paraná
2011

3. INSTITUTO DE CIÊNCIAS SOCIAIS E COMUNICAÇÃO
CURSO DE GESTÃO DE SISTEMAS DE INFORMAÇÃO
UNIP/Pólo Água Verde - Curitiba/2º. Semestre
Ricardo Camilo de Sousa
PROJETO INTEGRADO MULTIDICIPLINAR
COMISSÃO EXAMINADORA:
_______________________________________________________________
Examinador (1)
_______________________________________________________________
Examinador (2)
_______________________________________________________________
Coordenador do PIM – Profº
Observações:
_______________________________________________________________
___________________________________________________________________
___________________________________________________________________
_______________________________________________________
RESULTADO:
_______________________________________________________________
DATA DA APROVAÇÃO: ____ /_____ /______

4. Resumo
.
O texto a seguir tem como foco a gerência de projetos e a relação com os
custos orçamentários juntamente com a devida utilização da infraestrutura.
Teremos uma breve abordagem do setor de tecnologia da informação com
relação à economia e as tendências e previsões do mercado atual.
E também a infraestrutura terá sua referência como um dos pilares para a
área de projetos sendo demonstrada a sua utilização e referência. Logo após será
tratado da gerência de projeto, dos prazos e orçamentos que tem sido encarada
como um dos grandes desafios dos gestores de projetos, que poderá levar em
consideração a metodologia aplicada ao decorrer do texto.
Palavras chaves: gerência de projetos, custos orçamentários, infraestrutura,
economia, mercado, prazos, metodologia.

5. 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.

6. SUMÁRIO
1. INTRODUÇÃO................................................................................................ 1
2. ECONOMIA MERCADO E TI.......................................................................... 2
2.1 Retrospectiva e previsões.............................................................................. 2
2.2 Tendência...................................................................................................... 3
2.3 Computação nas nuvens............................................................................... 4
2.4 Guia de mercado TI....................................................................................... 5
3. INFRAESTRUTURA E TI ................................................................................5
3.1 Visão ..............................................................................................................5
4. GERÊNCIA E PROJETOS.............................................................................. 7
4.1 Visão geral..................................................................................................... 7
4.2 Desempenho de projetos............................................................................ 8
4.3 Orçamento no prazo..................................................................................... 12
4.4 Escolher uma metodologia........................................................................... 16
4.5 Fechamento do projeto................................................................................. 18
5. CONCLUSÃO................................................................................................. 20
6. REFERÊNCIAS............................................................................................... 21

7. 1
1. INTRODUÇÃO
Prazos estourados e orçamentos fora dos eixos têm sido uns dos grandes
problemas enfrentados na área da tecnologia da informação, nestas horas sempre
se pergunta quem deve ser o responsável pelo atraso de um determinado projeto ou
por um orçamento 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.
Então 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 realização de um projeto e como os resultados obtidos no final destes projetos
podem trazer transtornos para uma empresa ou até prejuízos. Por isso que o
gerenciamento de TI em projetos tem que ser feito com responsabilidade
Todas as fases do projeto têm que ser feita através de analise e testes, a
implantação também deve ter um sistema teste, toda a relação do projeto deve ser
destacada num time-line uma linha do tempo onde se destaca todas as fases e
atividade do projeto.
Mais além de todo este envolvimento que a TI trás para empresa, ela também
se destaca na nossa economia, e tem uma movimentação constante.

8. 2
2. ECONÔMIA MERCADO E TI
2.1 Retrospectiva e previsão
Umas das noticias que aparecem é que o setor de TI deve aumentar seu
orçamento para 2011, segundo dados da IDC. O estudo nos mostra que os bancos
estão ampliando seu investimento em TI e visando a eficiência operacional e as
seguradoras a elevar da receita.
Com uma recuperação que foi meio tímida dos orçamentos em TI em 2010,
após a forte retração em 2009 em razão da crise mundial, as instituições 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 edição, o levantamento mostra que 54%
das 62 empresas têm certeza ou claras intenções de que vão ampliar os
investimentos em TI em 2011 em relação a 2010. Os que afirmam que vão manter o
mesmo volume aplicado no ano de 2010 representam 42% do total. Já os que
disseram que vão gastar menos foram 3%.
O relatório da IDC mostra, ainda, que 61% das instituições financeiras
investiram mais em TI em 2010, 31% mantiveram seus orçamentos iguais aos de
2009 e apenas 8% investiram menos. ‘À primeira vista, parece que em 2011 o
crescimento dos investimentos em TI será menor. Porém, o crescimento do ano
passado deve-se em parte a uma recuperação de 2009, que foi um pouco mais
difícil devido à crise mundial. Ou seja, é impressionante ver que mais da metade das
empresas ainda vai aumentar em 2011 seus orçamentos em relação ao ano
passado, que já foi bastante bom’, disse Roberto Gutierrez, diretor de consultoria da
IDC Brasil.
O IDC Brazil Financial Insights Investment apontou também que para os
bancos a prioridade é o aumento da eficiência operacional, enquanto que para as
seguradoras é o aumento da receita. Segundo a pesquisa, os grandes bancos
continuam não terceirizando os sistemas 'core' da área de TI, preferindo mantê-los
sob seu controle. Por outro lado, há uma tendência de aumento da terceirização de
funções menos críticas, como a impressão departamental, por exemplo. Segundo o
estudo, mais de 20% das instituições pretendem aumentar a terceirização dessa
atividade.

9. 3
2.2 Tendência
A visão encarada por Gartner em relação as tendência do mercado de TI é
que ela não deve mais ser vista como preocupação exclusiva dos CIOs e sim de
todos os funcionários e executivos da empresa.
Para Gartner existe uma lista de prioridade na área de TI até 2016, e são:
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
orçamentos apertados e estruturar melhor a verba para compra de novos
equipamentos e software;
2. Lidar com a produção e o acesso à informação nas mídias sociais. A
consultoria acredita que até 2015, 80% das empresas não saberão 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
padrões de comportamento do mercado. O estudo acredita que os executivos
precisarão cada vez mais de ferramentas que prevejam os períodos de baixa
demanda, para que a produção possa ser ajustada;
4. As tecnologias de geolocalização será uma grande oportunidade para o
mercado de telecomunicações, o qual o Gartner prevê que mudará de
negócios baseados em serviços para baseados em aplicações. A consultoria
acredita que o mercado de ferramentas de geolocalização alcançará receita
de US$ 215 bilhões até o fim de 2012, enquanto cerca de US$ 150 bilhões do
orçamento de serviços das operadoras de telecom serão transferidos para
aplicações;
5. O Gartner acredita que até 2016 todas as empresas usarão computação em
nuvem. Segundo a pesquisa, nos próximos anos as relações de consumo de
tecnologia vão se alterar e cada vez mais as companhias buscarão formas de
fornecer pela internet. A consultoria prevê que até 2014 o mercado de cloud
computing terá receita de US$ 148,8 bilhões;

10. 4
2.3 Computação em nuvem
Vimos que Gartner relatou que as empresas usarão computação em nuvem,
mais na realidade qual a importância deste conceito, vamos abordar um pouco a
relação 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 não é suficiente - você também tem de comprar software
ou licenças 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 licença de software permita outro usuário. Isso é tão
estressante que você tem dificuldade para dormir todas as noites.
Breve, deve haver uma alternativa para executivos como você. Em vez de
instalar uma suíte de aplicativos em cada computador, você só teria de carregar uma
aplicação. Essa aplicação permitiria aos trabalhadores logar-se em um serviço
baseado na web que hospeda todos os programas de que o usuário precisa para
seu trabalho. Máquinas remotas de outra empresa rodariam tudo - de e-mail a
processador de textos e a complexos programas de análise de dados. Isso é
chamado computação em nuvem e poderia mudar toda a indústria de computadores.
No que parece a computação em nuvem esta sendo um campo emergente da
ciência da computação, a idéia já se faz presente há anos e como o próprio no diz
computação em nuvem porque os dados e aplicações existem em uma nuvem de
servidores na web.
Em um sistema de computação em nuvem, há uma redução significativa da
carga de trabalho. Computadores locais não têm mais de fazer todo o trabalho
pesado quando se trata de rodar aplicações. 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 usuário cai. A única coisa que o usuário do computador precisa é ser capaz
de rodar o software da interface do sistema da computação em nuvem, que pode ser
tão 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 computação em nuvem.
Se você tem uma conta de e-mail com um serviço baseado na web, como Hotmail,
Yahoo! ou Gmail, então você já teve experiência com computação em nuvem. Em

11. 5
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 não
existem no seu computador, estão na nuvem de computadores do serviço.
2.4 Guia mercado TI
Vimos que a relação da economia e o mercado de TI são dois pólos unidos
em beneficio a uma economia evolutiva e crescente num país. Agora estamos vendo
que o mercado esta dando mais disposição para enfrentá-la uma área que tem um
grande potencial econômico.
3. INFRAESTRUTURA E TI
3.1 Visão
Numa área portuária, por exemplo, é um setor onde se um nível de
movimentação constante, basicamente há trabalho vinte quatro horas por dia, onde

12. 6
se movimente containeres e etc. Os Terminais Portuários são responsáveis pela
maior parte do trabalho de movimentação e entrega de produtos negociados no
mundo. De grãos a carros, todo tipo de mercadoria pode cruzar mares e oceanos
criando valor para os homens de negócio e consumidores pelo mundo todo
utilizando este modal (Oliveira & Maçada, 2001). No Brasil, atualmente, 93% do
comércio exterior são escoados por transporte marítimo (Tecnologística, agosto
2001) e conforme Caridade (2000) o futuro da gestão logística nos terminais
portuários será basicamente através do gerenciamento da informação.
Para Weill & Broadbent (2000), a infra-estrutura de TI é à base da capacidade
da tecnologia de informação, tida como serviços confiáveis compartilhados pela
empresa e coordenada centralmente, geralmente pelo grupo de sistemas de
informação.
A atenção dispendida na busca pela harmonia da Tecnologia de Informação
com a empresa pode afetar significativamente a competitividade e eficiência do
negócio. Nesta discussão, o ponto principal é saber como a TI pode ajudar a
alcançar vantagem competitiva e estratégica para a empresa (Luftman et. al., 1993).
Logo, o desafio para as empresas é saber qual conjunto de serviços de infra-
estrutura são apropriados para seu contexto estratégico (Weill & Broadbent, 1996).
O conjunto de serviços de infra-estrutura fornece a capacidade humana e
técnica que alavanca a capacidade do negócio necessária para o posicionamento
competitivo da empresa. A maneira como os serviços básicos de infraestrutura são
oferecidos e utilizados variam entre diferentes empresas e são geralmente
relacionados a visão da empresa sobre o papel da infra-estrutura de TI.
Will & Broadbent (2000) utilizaram cinco conceitos para a identificação da
visão de infra-estrutura de TI: investimentos em TI com relação ao total de vendas
(últimos 5 anos), investimentos em TI em relação ao investimento total (últimos 5
anos); fórmula de benchmark, conjunto de serviços e “reach and range” . Porém,
optou se por utilizar apenas os dois últimos, visto que os dois primeiros são itens de
difícil (se não impossível) levantamento dentro das empresas nacionais e o terceiro
não se encontram bem explicado no artigo de origem. Logo, tomou-se por base que
a visão de infraestrutura pode ser identificada combinando-se dois conceitos:
conjunto de serviços 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

13. 7
“range” refere-se à funcionalidade em termos das atividades e serviços que podem
ser realizados e compartilhados automaticamente entre cada nível de “reach” (Weill
& Broadbent, 2000).
4. GERÊNCIA E PROJETOS
4.1 Visão geral
Vamos abordar a área de projeção, 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 esforço com a finalidade de criar um produto ou serviço ú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 serviço, ou
desenvolvimento de um modelo de veiculo ou até mesmo uma campanha para
algum cargo político e também o desenvolvimento e aquisição de um sistema.
A pessoa que tem por competência de seu desenvolvimento é o gerente de
projetos, no qual ele tem o objetivo de desenvolver o produto ou serviço esperado
dentro do prazo, custos, e nível de qualidade desejada.
As figuras importantes num projeto são os stakeholders; são indivíduos e
organizações envolvidos no projeto que serão afetadas positivamente ou
negativamente pelo resultado final. Podemos destacar o chefe, a organização, a
equipe, o cliente, o patrocinado e gerente do projeto.
As operações são conjuntos de ações cujo resultado, em um dado período,
contribui para o atendimento de uma necessidade administrativa ou operacional da
organização. Elas são caracterizadas por ter um objetivo que pode ser medido
qualitativamente ou financeiramente e dar condição de um funcionamento normal.
A semelhança entre projetos e operações se encontra no recurso limitado e
restrito onde são planejados executados e controlados por pessoas. Já se
diferenciam por as operações possuem atividades repetitivas e continuas já nos
projetos são atividades temporárias e únicas.
Já os programas são uns grupos de projetos designados a alcançar um
objetivo estratégico mais abrangente e é caracterizado por ter um termo mais
utilizado em governos tal como o projeto é limitado no tempo, mas sua duração é

14. 8
bem maior (anos e anos). Os projetos constituem a execução do programa para
atingir os seus objetivos por terem um longo período, podem incluir operações.
4.2 Desempenho de projetos
Um conceito de sucesso percebido é que os projetos que não atingiram suas
metas originais de custo, prazo e qualidade não eram, necessariamente,
reconhecidos como projetos fracassados pelas pessoas envolvidas em seu
desenvolvimento. Assim, o sucesso de um projeto estaria ligado à percepção que os
envolvidos (stakeholders) têm do sucesso/fracasso do projeto. Pinto e Slevin (1986)
apresentam uma definição de desempenho de projetos que considera tanto os
aspectos internos como os externos.
Fatores internos Fatores externos
Custo – grau de atendimento ao Uso – se o projeto é usado de acordo
orçamento inicial do projeto com sua proposta original
Prazo – cumprimento dos prazos Satisfação – a satisfação com o
inicialmente estabelecidos processo pelo qual o projeto está sendo
Desempenho técnico – grau em que o ou foi realizado
projeto atende as especificações Eficácia – o projeto irá beneficiar
técnicas implícitas e explícitas diretamente seus usuários
Fonte: adaptado de Pinto e Slevin (1986)
Lim e Mohamed (1999) também reconhecem a importância da percepção de
sucesso. Eles destacam que a percepção de sucesso não é, necessariamente, a
mesma para os diferentes atores envolvidos com o projeto. Eles trazem visão 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 usuários,
principalmente. Do ponto de vista micro, o sucesso do projeto irá depender da
execução das tarefas e etapas do projeto. Assim, essa divisão – micro e macro –
volta-se para avaliações de processo e de produto, respectivamente. Essa visão de
produto e de processo é compartilhada por outros autores.

15. 9
Cooke-Davis (2000) trabalha com dois conceitos separados. O primeiro
chamado de sucesso do projeto é medido através do grau de consecução dos
objetivos globais do projeto. Por exemplo, um projeto tem como objetivo gerar, por
meio do lançamento de um produto mais moderno, o aumento da participação de
mercado, ou desenvolver competências em tecnologias específicas, etc. O segundo
conceito é o de sucesso da gestão de projeto, cuja medição é feita com indicadores
de cumprimento de prazos, orçamentos e conformidade com padrões de qualidade
estabelecidos para o projeto.
Baccarini (1999) utiliza, também, dois conceitos distintos de desempenho:
sucesso da gestão do projeto (visão de processo) e sucesso do produto (visão de
produto). O sucesso do processo está ligado aos aspectos clássicos de
desempenho (prazo, custo e especificações de qualidade técnica), satisfação dos
stakeholders como desenvolvimento, e a qualidade do processo de gestão.
Apesar de reconhecer a importância última do sucesso do produto, Baccarini
(1999) lembra que o sucesso da gestão do projeto (processo) tende a influenciar
(positivamente) o sucesso do produto. Ele destaca que, como a avaliação do
desempenho depende de quem avalia e do instante da avaliação, é importante
estabelecer, a priori, os critérios de sucesso que serão utilizados em um projeto em
particular.
O conceito de sucesso utilizado por Dvir et al (1998) possui duas dimensões:
benefícios percebidos pelo consumidor e cumprimento de metas de projeto (design),
o que sugere, também, uma divisão do conceito de sucesso à medida que os
benefícios percebidos pelo consumidor só podem ser avaliados após algum tempo
de uso do produto do projeto, ao contrário do cumprimento das especificações, que
pode ser avaliado durante o desenvolvimento e ao término do projeto.
Dimensão do sucesso Medidas/variáveis utilizadas
Especificações funcionais
Especificações técnicas
Comprimentos de metas no projeto
Prazo
Orçamento
Cumprimento das metas de aquisição
Cumprimento dos requisitos
operacionais
Produto entrou em operação

16. 10
Chegou a tempo aos usuários finais
O produto foi utilizado durante um
Benefícios percebidos pelo consumidor
período substancial de tempo
O produto melhorou substancialmente o
nível de operação do usuário
Usuário satisfeito com o produto
Fonte: Dvir et al (1998)
Shenhar et al (2001) não reconhecem a existência de dois conceitos distintos de
sucesso de projeto e sucesso de produto – e defendem a idéia de que a importância
relativa das dimensões do sucesso do projeto muda com o passar do tempo. Esses
autores identificaram as seguintes dimensões do sucesso:
• Eficiência do projeto (cumprimento de prazos e orçamentos);
• Impacto no consumidor (satisfação do cliente e qualidade do produto);
• Sucesso do negócio (geração de receita, lucro, share e outros benefícios para
a organização mãe); e
• Preparação para o futuro (desenvolvimento de infra-estrutura organizacional
e/outecnológica para o futuro).
Contudo, a proposta desses autores, também, reconhece que a avaliação de
cada dimensão não pode ser feita todas no mesmo instante. Elas têm horizontes
diferentes (figura 3).
A importância relativa de cada dimensão varia com o tempo e com a incerteza
tecnológica. No curtíssimo prazo, a eficiência do projeto é a mais importante e
também a única passível de ser medida com uma precisão confiável. Com o uso do
produto desenvolvido, torna-se possível e relevante a avaliação das demais
dimensões.

17. 11
Em projetos de baixa incerteza tecnológica, as expectativas em relação ao
projeto estão muito mais ligadas a contribuições marginais em que a eficiência do
desenvolvimento é fator determinante. Por exemplo, ao fazer uma atualização de um
produto, o interesse está em manter o produto de acordo com as especificações de
mercado e não se espera que isso vá alterar o ciclo de vida do produto. Quando se
trabalha com grandes inovações e com grandes incertezas tecnológicas, as
organizações se tornam mais tolerantes a uma baixa eficiência do projeto. Isso
porque existe a expectativa de que o projeto possa, eventualmente, gerar uma
competência interna em uma nova e emergente tecnologia.
Como pode se observar pelos autores comentados acima, existe uma
variação em termos de indicadores de desempenho apesar de haver uma certa
convergência em relação às dimensões do desempenho de projetos. Uma diferença
marcante entre as propostas apresentadas refere-se à discussão em torno da
questão 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 administração de projeto (foco no
processo de desenvolvimento) e sucesso do projeto (foco no produto resultante do

18. 12
projeto) – outros (SHENHAR et al., 2001; BAKER et al. 1983; PINTO e SLEVIN,
1988) entendem que existe um elemento único em discussão que possui
características multidimensionais, em que a relevância de cada dimensão varia com
o tempo.
Dimensão do sucesso Medidas/variáveis utilizadas
Eficiência do projeto Meta de prazo
Meta de orçamento
Impacto no consumidor Desempenho funcional
Conformidade às especificações técnicas
Preenchimento das necessidades do cliente
Resolução dos problemas do cliente
Uso do produto pelo cliente
Satisfação do cliente
Sucesso do negócio Sucesso comercial
Aumento ou criação de participação de mercado
Preparação para o futuro Criação de novo mercado
Criação de nova linha de produto
Desenvolvimento de nova tecnologia
Fonte: Shenhar et al (2001)
4.3 Orçamento no prazo
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 conseqüê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

19. 13
contribuição desses projetos aos objetivos finais do negócio. Em decorrência 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 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 conseqüência dessa falta de controle. Todos os envolvidos podem
solicitar mudanças no projeto, mas é necessário que se tenham critérios para
analisar o impacto e a viabilidade 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.

20. 14
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
patrocinador 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 tenham essas respostas,
não podemos deixar de fazer o acompanhamento do projeto. Precisamos
monitorar e controlar todo o principal 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.

21. 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 número tão alto de fracassos nesses
projetos. Vejam 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 à
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 alto desempenho 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.
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.

22. 16
4.4 Escolher uma metodologia
Uma metodologia é um processo a seguir que dá maior controle sobre os
recursos que serão 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
práticas que levam ao insucesso e com isso reproduzir o sucesso.
A falta comunicação, os boatos e outras formas de ruídos tomam seu lugar.
Na falta de versão oficial, ficam circulando informações que podem minar a moral da
equipe e levantar suspeita sem fundamento. O gerente de projeto deve evitar esse
tipo de prática, dando informações claras e confiáveis 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 não só falar sobre ele, mas também informar que
está trabalhando na solução, e não apenas comunicar que o problema existe.
Problemas sem uma perspectiva de solução são angustiantes e causam um
desconforto na equipe que muitas vezes é desnecessário.
A criação de relatórios de progresso do projeto ajuda no processo de
comunicação, 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 informação vinda de um relatório em que a data de
término real de uma tarefa está em branco: objetivamente a situação é a mesma, o
indivíduo não fez a sua parte, mas no caso do email a pessoa envolvida pode se
melindrar. No relatório, temos um dado objetivo, que salta aos olhos, mas que não
gera ressentimentos.
Definir um escopo do projeto é o trabalho que deve ser realizado para se
obter um produto ou serviço com determinadas características e recursos. Comece
por definir o que deve ser feito e o que não deve. Esse processo nos permite
entender os contornos do projeto e traçar uma linha divisória entre o que deve ser
feito e o que não deve ser pelo menos neste momento. Muitos novatos se perdem
em discussões intermináveis 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 próximo, o “bom”, é que temos mais chance de conseguir atingir.

23. 17
Em paralelo, deve ser elaborado um orçamento levando em conta quantas horas de
cada profissional serão necessárias. Veja um modelo simples:
Profissional Tarefa 1 Tarefa 2 Tarefa 3 T.Total (h) Custo/h Custo
Gerente de projeto 20 0 3 23 150,00 3.450,00
Líder de projeto 10 3 2 15 80,00 1.200,00
Analista Sênior 20 0 0 20 50,00 1.000,00
Programador 0 40 20 60 30,00 1.800,00
Testador/Documentador 0 20 30 50 15,00 750,00
Total - - - 168 - 8.200,00
Gerenciamento de projetos tem que ter a devida proteção do escopo. Projetos
que ficam mudando o escopo durante sua execução têm sérias dificuldades em
cumprir o cronograma e estouram o orçamento. 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 orçamento não serão tão “elásticos” quanto
as exigências. Devemos sempre contar com uma determinada margem de manobra,
mas nos tempos atuais, em que eficiência é a palavra que está na ordem do dia, os
compromissos assumidos pelo gerente podem se transformar num sacrifício, muitas
vezes desnecessário, para toda a equipe.
Em projetos de software, o “scope creep” é uma situação tão comum que não
dá para começá-los sem tomar algumas precauções. O primeiro cuidado é negociar
a forma de remuneração: fixa ou variável. Se for fixa, o risco das mudanças está
toda com o gerente do projeto, se for variável, 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 precaução, 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 características e com que recursos.
Ele é um “quase-contrato”, mas não traz as cláusulas de rescisão e as penalidades.
Neste momento, tudo está bem e todos concordam. Só que, na cabeça de cada um,
há uma imagem diferente do que será o produto final. Á medida que este produto vai

24. 18
tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou “não é
bem aquilo” e podem começar as decepções.
É importante que o gerente do projeto conheça os interesses de todos os
envolvidos. Imagine como é arriscado contar com um membro da equipe que não
está disposto a colaborar. Ele pode ser um problema mais do que uma solução
dentro do grupo: sabendo disso, melhor pensar em chamar outra pessoa. Eu passei
por uma situação destas quando fui destacado para gerenciar um projeto onde havia
um colaborador mais antigo e que entendia que ele é quem deveria estar
gerenciando. Eu não percebi seu ressentimento a princípio e à medida que o projeto
avançava esta pessoa se tornava um problema cada vez maior, na medida em que,
não só ele não fazia a sua parte, como minava os demais membros da equipe contra
minhas decisões.
4.5 Fechamento do projeto
O início do projeto é um momento solene. O patrocinador deve formalizar a
todos os envolvidos que o projeto está iniciado e o cronômetro está correndo. Muita
gente não gosta de se preocupar com isso, mas imagine que haja resistência de
setores da empresa que se opõem ao projeto. Sem um documento que atesta que o
projeto começou, o gerente pode não conseguir apoio algum. Além disso, este
documento funciona como um “cumpra-se” de uma autoridade da empresa: não
cabe discutir a ordem, o projeto começou 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á concluído e que novas necessidades serão atendidas
em um novo projeto. Qualquer extensão ou alteração deverá ser orçada e todo o
ciclo se inicia novamente. Com relação à manutenção do sistema entregue não se
pode considerá-lo um projeto na medida em que, a princípio, trata-se de um
processo contínuo. O que pode ocorrer é definir-se projetos ao longo da vida útil do
sistema com o objetivo de melhorá-lo. Por exemplo, a atualização dos equipamentos
eletrônicos (“aviônicos”) de um avião para auxílio ao vôo é um projeto que se
distingue da sua manutenção rotineira.
Ao final faz-se também uma reunião de avaliação dos erros e acertos da
equipe. Chamadas de reuniões "post-mortem", elas servem para se gerar uma lista

25. 19
de "melhores práticas" contribuindo para a formação de uma base de conhecimento
que poderá ser muito útil em projetos futuros. Da minha experiência pessoal, posso
dizer que tirei grandes lições quanto às "piores práticas", atitudes e decisões 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 aplicações e momentos do projeto todos relacionados entre si.

26. 20
5. CONCLUSÃO
Conduzir um projeto para o sucesso certamente é uma tarefa difícil para
qualquer gerente, os imprevisto, riscos sempre vão aparecer, e a única forma de se
obter algum proveito é implantando planos de controle e prevenção de riscos.
Porque o tempo nunca é nosso aliado, e se não 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 responsáveis pelo sucesso do projeto.
A principal qualidade do gerente de projeto é saber se comunicar bem com
todos. Ele é o ponto focal das informações, nele convergem às informações que ele
depois deverá processar e divulgar para todo o restante da equipe.
Acima de tudo, gerenciar projetos é planejar e acompanhar a execução
sempre atendo em todos os detalhes. O gerente do projeto deve se manter alerta e
flexível com os acontecimentos do dia-a-dia, mas deve estar sempre se reportando
ao plano inicial para não perder o controle.

27. 21
6. REFERÊNCIAS
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 re-
examination. IN International Journal of Project Management vol. 17, no. 4, pp. 243-
248, 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. & Maçada, A. C. G.(2000). Fatores que afetam os investimentos em
Tecnologia de Informação: O caso de um Terminal de “Containers”. XX Encontro
Nacional de Engenharia de Produção (ENEGEP). São 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.

28. 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.