SlideShare uma empresa Scribd logo
UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia




Nome: Ricardo Camilo de Sousa




    Pólo Á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 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
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: ____ /_____ /______
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.
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.
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
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.
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.
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;
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
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
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
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 é
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.
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
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.
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
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
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.
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.
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.
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.
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
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
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.
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.
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.
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.

Mais conteúdo relacionado

Mais procurados

PROJETO INTEGRADO MULTIDISCIPLINAR IV - PIM IV
PROJETO INTEGRADO MULTIDISCIPLINAR IV - PIM IVPROJETO INTEGRADO MULTIDISCIPLINAR IV - PIM IV
PROJETO INTEGRADO MULTIDISCIPLINAR IV - PIM IV
Henry Jackman
 
Pin 2020
Pin 2020Pin 2020
Pin 2020
Fabio Felix
 
Pim finalizando
Pim finalizandoPim finalizando
Pim finalizando
Marcus Pouza
 
A73b2bc7 5ee3-4418-bb3b-38f0a6b18060 - pim i
A73b2bc7 5ee3-4418-bb3b-38f0a6b18060 - pim iA73b2bc7 5ee3-4418-bb3b-38f0a6b18060 - pim i
A73b2bc7 5ee3-4418-bb3b-38f0a6b18060 - pim i
monicamgfcorsini
 
Pim iii unip interativa
Pim iii unip interativa Pim iii unip interativa
Pim iii unip interativa
thiroman
 
Pim
PimPim
Pim final
Pim finalPim final
PIM I _ COCA COLA INDUSTRIAS LTDA.pdf
PIM I _ COCA COLA INDUSTRIAS LTDA.pdfPIM I _ COCA COLA INDUSTRIAS LTDA.pdf
PIM I _ COCA COLA INDUSTRIAS LTDA.pdf
ManoelMessiasLeitede
 
Manual do pim III Gestão da qualidade
Manual do pim III Gestão da qualidadeManual do pim III Gestão da qualidade
Manual do pim III Gestão da qualidade
Revair Ferraresi
 
Relatório de Estágio - Marketing Digital
Relatório de Estágio - Marketing Digital Relatório de Estágio - Marketing Digital
Relatório de Estágio - Marketing Digital
Mª Luisa Pires
 
Plano de aula informática avançada marta magda
Plano de aula informática avançada marta magdaPlano de aula informática avançada marta magda
Plano de aula informática avançada marta magda
Diana Rocha
 
Sistemas Operacionais Desktop e Aplicativos.pdf
Sistemas Operacionais Desktop e Aplicativos.pdfSistemas Operacionais Desktop e Aplicativos.pdf
Sistemas Operacionais Desktop e Aplicativos.pdf
Os Fantasmas !
 
NBR ISO 37301 WORLD.docx
NBR ISO 37301 WORLD.docxNBR ISO 37301 WORLD.docx
NBR ISO 37301 WORLD.docx
DoutorgestoJaqueline
 
Serial do microsoft office professional plus 2010
Serial do microsoft office professional plus 2010Serial do microsoft office professional plus 2010
Serial do microsoft office professional plus 2010
Jameson Viana
 
Informatica Aplicada
Informatica AplicadaInformatica Aplicada
Informatica Aplicada
Ricardo de Moraes
 
Relatorio de estagio tecnico em informatica
Relatorio de estagio tecnico em informaticaRelatorio de estagio tecnico em informatica
Relatorio de estagio tecnico em informatica
LucianaFerreira163
 
Plano de negocios restaurante bom paladar
Plano de negocios restaurante bom paladarPlano de negocios restaurante bom paladar
Plano de negocios restaurante bom paladar
Josilene Silva Alves
 
RELATÓRIO DE ESTAGIO
RELATÓRIO DE ESTAGIORELATÓRIO DE ESTAGIO
RELATÓRIO DE ESTAGIO
gelcine Angela
 
Informática Básica para Concurso
Informática Básica para ConcursoInformática Básica para Concurso
Informática Básica para Concurso
Estratégia Concursos
 
Plano de Negócios
Plano de NegóciosPlano de Negócios
Plano de Negócios
ProjetoSemeandoaLeitura
 

Mais procurados (20)

PROJETO INTEGRADO MULTIDISCIPLINAR IV - PIM IV
PROJETO INTEGRADO MULTIDISCIPLINAR IV - PIM IVPROJETO INTEGRADO MULTIDISCIPLINAR IV - PIM IV
PROJETO INTEGRADO MULTIDISCIPLINAR IV - PIM IV
 
Pin 2020
Pin 2020Pin 2020
Pin 2020
 
Pim finalizando
Pim finalizandoPim finalizando
Pim finalizando
 
A73b2bc7 5ee3-4418-bb3b-38f0a6b18060 - pim i
A73b2bc7 5ee3-4418-bb3b-38f0a6b18060 - pim iA73b2bc7 5ee3-4418-bb3b-38f0a6b18060 - pim i
A73b2bc7 5ee3-4418-bb3b-38f0a6b18060 - pim i
 
Pim iii unip interativa
Pim iii unip interativa Pim iii unip interativa
Pim iii unip interativa
 
Pim
PimPim
Pim
 
Pim final
Pim finalPim final
Pim final
 
PIM I _ COCA COLA INDUSTRIAS LTDA.pdf
PIM I _ COCA COLA INDUSTRIAS LTDA.pdfPIM I _ COCA COLA INDUSTRIAS LTDA.pdf
PIM I _ COCA COLA INDUSTRIAS LTDA.pdf
 
Manual do pim III Gestão da qualidade
Manual do pim III Gestão da qualidadeManual do pim III Gestão da qualidade
Manual do pim III Gestão da qualidade
 
Relatório de Estágio - Marketing Digital
Relatório de Estágio - Marketing Digital Relatório de Estágio - Marketing Digital
Relatório de Estágio - Marketing Digital
 
Plano de aula informática avançada marta magda
Plano de aula informática avançada marta magdaPlano de aula informática avançada marta magda
Plano de aula informática avançada marta magda
 
Sistemas Operacionais Desktop e Aplicativos.pdf
Sistemas Operacionais Desktop e Aplicativos.pdfSistemas Operacionais Desktop e Aplicativos.pdf
Sistemas Operacionais Desktop e Aplicativos.pdf
 
NBR ISO 37301 WORLD.docx
NBR ISO 37301 WORLD.docxNBR ISO 37301 WORLD.docx
NBR ISO 37301 WORLD.docx
 
Serial do microsoft office professional plus 2010
Serial do microsoft office professional plus 2010Serial do microsoft office professional plus 2010
Serial do microsoft office professional plus 2010
 
Informatica Aplicada
Informatica AplicadaInformatica Aplicada
Informatica Aplicada
 
Relatorio de estagio tecnico em informatica
Relatorio de estagio tecnico em informaticaRelatorio de estagio tecnico em informatica
Relatorio de estagio tecnico em informatica
 
Plano de negocios restaurante bom paladar
Plano de negocios restaurante bom paladarPlano de negocios restaurante bom paladar
Plano de negocios restaurante bom paladar
 
RELATÓRIO DE ESTAGIO
RELATÓRIO DE ESTAGIORELATÓRIO DE ESTAGIO
RELATÓRIO DE ESTAGIO
 
Informática Básica para Concurso
Informática Básica para ConcursoInformática Básica para Concurso
Informática Básica para Concurso
 
Plano de Negócios
Plano de NegóciosPlano de Negócios
Plano de Negócios
 

Semelhante a Pim v

[IQPC] 1ª Pesquisa Iniciativas em BPM – 2008
[IQPC] 1ª Pesquisa Iniciativas em BPM –  2008 [IQPC] 1ª Pesquisa Iniciativas em BPM –  2008
[IQPC] 1ª Pesquisa Iniciativas em BPM – 2008
EloGroup
 
1ª Pesquisa Iniciativas em BPM – Evento IQPC 2008
1ª Pesquisa Iniciativas em BPM – Evento IQPC 20081ª Pesquisa Iniciativas em BPM – Evento IQPC 2008
1ª Pesquisa Iniciativas em BPM – Evento IQPC 2008
EloGroup
 
Relatorio_TIC_2012
Relatorio_TIC_2012Relatorio_TIC_2012
Relatorio_TIC_2012
Armando Gonçalves
 
EET_CTeSP AER_IntroducaoEmpreendedorismo_Ch2.pdf
EET_CTeSP AER_IntroducaoEmpreendedorismo_Ch2.pdfEET_CTeSP AER_IntroducaoEmpreendedorismo_Ch2.pdf
EET_CTeSP AER_IntroducaoEmpreendedorismo_Ch2.pdf
Ricardo Santos
 
Plano de curso mba em business intelligence at big data (mba)-20212-turma-v...
Plano de curso   mba em business intelligence at big data (mba)-20212-turma-v...Plano de curso   mba em business intelligence at big data (mba)-20212-turma-v...
Plano de curso mba em business intelligence at big data (mba)-20212-turma-v...
Ricardo Roberto MSc, MBA
 
Anteprojeto Governança de TI
Anteprojeto Governança de TIAnteprojeto Governança de TI
Anteprojeto Governança de TI
Fernando Palma
 
Portfolio unopar administração 7º periodo conceito excelente!
Portfolio unopar administração 7º periodo   conceito excelente!Portfolio unopar administração 7º periodo   conceito excelente!
Portfolio unopar administração 7º periodo conceito excelente!
Rogerio Sena
 
A importância do planejamento em projetos de tecnologia da informação
A importância do planejamento em projetos de tecnologia da informaçãoA importância do planejamento em projetos de tecnologia da informação
A importância do planejamento em projetos de tecnologia da informação
Lucivaldo Minervino
 
Sistemas integrados
Sistemas integradosSistemas integrados
Sistemas integrados
Samuel Ribeiro
 
Manuscrito Tesi Final
Manuscrito Tesi FinalManuscrito Tesi Final
Manuscrito Tesi Final
Kharylim Machado Sea
 
Manuscrito Final
Manuscrito FinalManuscrito Final
Manuscrito Final
Thadeu Henrique
 
Plano definitivo
Plano definitivoPlano definitivo
Plano definitivo
Diogo Librelon
 
Lean Construction no Brasil
Lean Construction no BrasilLean Construction no Brasil
Lean Construction no Brasil
Bernardo Etges
 
3ª Pesquisa Iniciativas em BPM – Evento IQPC 2010
3ª Pesquisa Iniciativas em BPM – Evento IQPC 20103ª Pesquisa Iniciativas em BPM – Evento IQPC 2010
3ª Pesquisa Iniciativas em BPM – Evento IQPC 2010
EloGroup
 
[IQPC] 3ª Pesquisa Iniciativas em BPM – 2010
[IQPC] 3ª Pesquisa Iniciativas em BPM –  2010 [IQPC] 3ª Pesquisa Iniciativas em BPM –  2010
[IQPC] 3ª Pesquisa Iniciativas em BPM – 2010
EloGroup
 
Tcc Adolfo Stochiero - BPM - Business Process Management
Tcc Adolfo Stochiero - BPM - Business Process ManagementTcc Adolfo Stochiero - BPM - Business Process Management
Tcc Adolfo Stochiero - BPM - Business Process Management
Adolfo Stochiero de Assis Mates
 
Microsoft - Application Lifecycle Management - Visão Geral
Microsoft - Application Lifecycle Management - Visão GeralMicrosoft - Application Lifecycle Management - Visão Geral
Microsoft - Application Lifecycle Management - Visão Geral
Alan Carlos
 
241 producaoonline 05
241 producaoonline 05241 producaoonline 05
241 producaoonline 05
Felipe Silva
 
Artigo governança ti
Artigo governança tiArtigo governança ti
[FINAL] MONOGRAFIA - DANIEL BRANDT - OS CRITÉRIOS DE SUCESSO EM PROJETOS DE S...
[FINAL] MONOGRAFIA - DANIEL BRANDT - OS CRITÉRIOS DE SUCESSO EM PROJETOS DE S...[FINAL] MONOGRAFIA - DANIEL BRANDT - OS CRITÉRIOS DE SUCESSO EM PROJETOS DE S...
[FINAL] MONOGRAFIA - DANIEL BRANDT - OS CRITÉRIOS DE SUCESSO EM PROJETOS DE S...
Daniel Brandt
 

Semelhante a Pim v (20)

[IQPC] 1ª Pesquisa Iniciativas em BPM – 2008
[IQPC] 1ª Pesquisa Iniciativas em BPM –  2008 [IQPC] 1ª Pesquisa Iniciativas em BPM –  2008
[IQPC] 1ª Pesquisa Iniciativas em BPM – 2008
 
1ª Pesquisa Iniciativas em BPM – Evento IQPC 2008
1ª Pesquisa Iniciativas em BPM – Evento IQPC 20081ª Pesquisa Iniciativas em BPM – Evento IQPC 2008
1ª Pesquisa Iniciativas em BPM – Evento IQPC 2008
 
Relatorio_TIC_2012
Relatorio_TIC_2012Relatorio_TIC_2012
Relatorio_TIC_2012
 
EET_CTeSP AER_IntroducaoEmpreendedorismo_Ch2.pdf
EET_CTeSP AER_IntroducaoEmpreendedorismo_Ch2.pdfEET_CTeSP AER_IntroducaoEmpreendedorismo_Ch2.pdf
EET_CTeSP AER_IntroducaoEmpreendedorismo_Ch2.pdf
 
Plano de curso mba em business intelligence at big data (mba)-20212-turma-v...
Plano de curso   mba em business intelligence at big data (mba)-20212-turma-v...Plano de curso   mba em business intelligence at big data (mba)-20212-turma-v...
Plano de curso mba em business intelligence at big data (mba)-20212-turma-v...
 
Anteprojeto Governança de TI
Anteprojeto Governança de TIAnteprojeto Governança de TI
Anteprojeto Governança de TI
 
Portfolio unopar administração 7º periodo conceito excelente!
Portfolio unopar administração 7º periodo   conceito excelente!Portfolio unopar administração 7º periodo   conceito excelente!
Portfolio unopar administração 7º periodo conceito excelente!
 
A importância do planejamento em projetos de tecnologia da informação
A importância do planejamento em projetos de tecnologia da informaçãoA importância do planejamento em projetos de tecnologia da informação
A importância do planejamento em projetos de tecnologia da informação
 
Sistemas integrados
Sistemas integradosSistemas integrados
Sistemas integrados
 
Manuscrito Tesi Final
Manuscrito Tesi FinalManuscrito Tesi Final
Manuscrito Tesi Final
 
Manuscrito Final
Manuscrito FinalManuscrito Final
Manuscrito Final
 
Plano definitivo
Plano definitivoPlano definitivo
Plano definitivo
 
Lean Construction no Brasil
Lean Construction no BrasilLean Construction no Brasil
Lean Construction no Brasil
 
3ª Pesquisa Iniciativas em BPM – Evento IQPC 2010
3ª Pesquisa Iniciativas em BPM – Evento IQPC 20103ª Pesquisa Iniciativas em BPM – Evento IQPC 2010
3ª Pesquisa Iniciativas em BPM – Evento IQPC 2010
 
[IQPC] 3ª Pesquisa Iniciativas em BPM – 2010
[IQPC] 3ª Pesquisa Iniciativas em BPM –  2010 [IQPC] 3ª Pesquisa Iniciativas em BPM –  2010
[IQPC] 3ª Pesquisa Iniciativas em BPM – 2010
 
Tcc Adolfo Stochiero - BPM - Business Process Management
Tcc Adolfo Stochiero - BPM - Business Process ManagementTcc Adolfo Stochiero - BPM - Business Process Management
Tcc Adolfo Stochiero - BPM - Business Process Management
 
Microsoft - Application Lifecycle Management - Visão Geral
Microsoft - Application Lifecycle Management - Visão GeralMicrosoft - Application Lifecycle Management - Visão Geral
Microsoft - Application Lifecycle Management - Visão Geral
 
241 producaoonline 05
241 producaoonline 05241 producaoonline 05
241 producaoonline 05
 
Artigo governança ti
Artigo governança tiArtigo governança ti
Artigo governança ti
 
[FINAL] MONOGRAFIA - DANIEL BRANDT - OS CRITÉRIOS DE SUCESSO EM PROJETOS DE S...
[FINAL] MONOGRAFIA - DANIEL BRANDT - OS CRITÉRIOS DE SUCESSO EM PROJETOS DE S...[FINAL] MONOGRAFIA - DANIEL BRANDT - OS CRITÉRIOS DE SUCESSO EM PROJETOS DE S...
[FINAL] MONOGRAFIA - DANIEL BRANDT - OS CRITÉRIOS DE SUCESSO EM PROJETOS DE S...
 

Pim v

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