AMARILDO RAMOS DE ALMEIDA ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS E SERVIÇOS DE TI

Universidade Estadual de Londrina AMARILDO RAMOS DE ALMEIDA ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS E SERVIÇOS DE TI LONDRINA 2008

AMARILDO RAMOS DE ALMEIDA ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS E SERVIÇOS DE TI Monografia apresentada ao Departamento de Computação da Universidade Estadual de Londrina. Orientador: Prof. Rodolfo Miranda de Barros. LONDRINA 2008

AMARILDO RAMOS DE ALMEIDA ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS E SERVIÇOS DE TI Monografia apresentada ao Departamento de Computação da Universidade Estadual de Londrina. COMISSÃO EXAMINADORA Ms. Rodolfo Miranda de Barros Universidade Estadual de Londrina Ms. Fábio Cézar Martins Universidade Estadual de Londrina Ms. Sérgio Akio Tanaka Centro Universitário Filadélfia Londrina, 11 de julho de 2008.

A Deus, meu Criador. Aos meus pais, Antonio e Zilda, em memória. A minha esposa Bet e meus filhos Janaína, Andréia e André.

AGRADECIMENTOS A Deus, por tudo o que fez na minha vida e por poder conhecer o seu imenso amor. A minha esposa Bet, que sempre me incentivou e apoiou, e aos meus filhos pela compreensão nos momentos de ausência. Ao professor Rodolfo, pela excelente orientação e incentivo. Aos professores da UEL pelo respeito e dedicação no ensino. Aos colegas de curso, pelo espírito de companheirismo e pelos laços de amizade. A todos os amigos e pessoas que contribuíram para a realização este trabalho.

Bem aventurado o homem que acha sabedoria, e o homem que adquire conhecimento. Provérbios 3.13 O temor do Senhor é o princípio da ciência. Provérbios 1.7 Só sei que nada sei. Sócrates

ALMEIDA, Amarildo Ramos de. Escritório de Gerenciamento de Projetos e Serviços de TI. 2008. 110 folhas. Monografia do Curso de Especialização em Engenharia de Software e Banco de Dados Universidade Estadual de Londrina, Londrina, 2008. RESUMO Os principais desafios enfrentados pelos desenvolvedores e gestores da área de TI são os de gerenciar efetivamente projetos e serviços sob sua responsabilidade. Pesquisas recentes mostram que apenas cerca de 30% dos projetos de TI são concluídos com sucesso, revelando o alto índice de falhas ou problemas nos projetos e a conseqüente necessidade de conduzi-los usando metodologias comprovadamente eficientes. Além disso, estima-se que manter a operação dos produtos de TI consuma em torno de 80% do tempo e dos custos totais em relação ao ciclo de vida dos mesmos, demonstrando que gerir os serviços eficazmente é também fundamental para obtenção de bons resultados. O presente estudo descreve a proposta de criação do Escritório de Gerenciamento de Projetos e Serviços (EGPS), uma unidade organizacional responsável pela coordenação dos projetos e serviços de TI sob seu controle. O trabalho apresenta também as técnicas de Gerenciamento de Projetos sugeridas no guia PMBOK, os processos e melhores práticas de Gerenciamento de Serviços definidos no modelo ITIL e o conceito de Escritório de Gerenciamento de Projetos, solução adotada por muitas organizações visando oferecer uma coordenação centralizada e especializada em ambientes que lidam com vários projetos simultâneos. Essas tecnologias compõem o EGPS de TI, o qual tem como objetivo fornecer um controle completo, integrado e abrangente aos produtos desenvolvidos e suportados pela área, a fim de aperfeiçoar os processos, aumentar a produtividade e obter melhores resultados nos negócios através da TI. Palavras-chave: Engenharia de Software, Gerência de Projetos, EGP, ITIL, EGPS.

ALMEIDA, Amarildo Ramos de. IT Services and Projects Management Office. 2008. 110 sheets. Monografia do Curso de Especialização em Engenharia de Software e Banco de Dados Universidade Estadual de Londrina, Londrina, 2008. ABSTRACT The main challenges faced by developers and IT managers are indeed manage projects and services under their responsibility. Recent researches show that only about 30% of the IT projects are successfully completed, revealing the high rate of failures or problems in the projects and the consequent need to lead them using methodologies proven efficient. Moreover, it is estimated that maintaining the operation of IT products consume around 80% of the time and cost in comparison to their life cycle, demonstrating that effectively manage the services is also essential for obtaining good results. This study describes the proposal to establish the Services and Projects Management Office (SPMO), an organizational unit responsible for coordinating IT projects and services under its control. The work also presents techniques of Projects Management suggested in the PMBOK guide, the processes and best practices of Services Management defined in ITIL model and the concept of Project Management Office, solution adopted for many organizations seeking to provide a centralized coordination and specialized in environments that work with several simultaneous projects. Those technologies compose the IT SPMO, that has as objective to supply a complete, integrated and including control to the developed products and supported by its area, in order to improve the processes, increase productivity and achieve better results in the business through IT. Key words: Software Engineering, Project Management, PMO, ITIL, SPMO.

LISTA DE ILUSTRAÇÕES Figura 1. Situação dos projetos de TI em 1994 e 2004...16 Figura 2. Níveis de custo e pessoal ao longo do ciclo de vida do projeto....24 Figura 3. Riscos do projeto durante o ciclo de vida...24 Figura 4. Influência dos stakeholders e custo das mudanças durante o ciclo de vida do projeto....25 Figura 5. Relação entre os ciclos de vida do projeto e do produto...26 Figura 6. Relação entre os stakeholders do projeto....28 Figura 7. Ciclo PDCA....31 Figura 8. Mapeamento entre os grupos de processos e o ciclo PDCA....32 Figura 9. Fluxos e interações entre os grupos de processos de GP....37 Figura 10. Sobreposição e níveis de intensidade entre os grupos de processos de GP....38 Figura 11. Ciclo de vida estendido dos projetos...40 Figura 12. Resultados esperados com o gerenciamento simultâneo dos projetos...41 Figura 13. Estrutura da ITIL...46 Figura 14. Processos do Gerenciamento de Serviços....47 Figura 15. Acordos e documentos para o Gerenciamento de Níveis de Serviços...49 Figura 16. Atividades do Gerenciamento da Capacidade....50 Figura 17. Conceitos do Gerenciamento da Disponibilidade...51 Figura 18. Estrutura funcional da Central de Serviços....53 Figura 19. Visão geral do Gerenciamento de Incidentes, Problemas e Mudanças...54 Figura 20. Itens do Gerenciamento de Configuração...55 Figura 21. Fluxos do Gerenciamento de Mudanças...56

Figura 22. Procedimentos para Controle de Versões...57 Figura 23. Atividades do Gerenciamento de Liberações...57 Figura 24. Ciclo de Vida do Gerenciamento da Aplicação....60 Figura 25. Relacionamento entre a TI e o Negócio....61 Figura 26. Estágios do Programa de Aperfeiçoamento Ininterrupto do Serviço...63 Figura 27. Conceito de EGP...66 Figura 28. Modelo de EGP segundo CRAWFORD....70 Figura 29. Modelo de EGP segundo KATE...70 Figura 30. Modelo de EGP segundo CASEY & PECK....70 Figura 31. Árvore de decisão para avaliação do cálculo do VME de um EGP...85 Figura 32. Relação entre o foco de atuação do EGP e o valor para a organização..86 Figura 33. Campo de atuação do EGPS dentro do Ciclo de Vida do Produto....90 Figura 34. Esquema de feedback do EGPS...91 Figura 35. Modelos de EGPS...93 Figura 36. Proposta de estrutura interna do EGPS....94 Figura 37. Fases de implantação do EGPS....101 ix

LISTA DE TABELAS Quadro 1. Características do projeto em relação às estruturas organizacionais...29 Quadro 2. Organização dos processos de GP em grupos e áreas de conhecimento....39 Quadro 3. Tipos de EGP....69

LISTA DE ABREVIATURAS E SIGLAS ANO ANS BDGC BSD CA CCTA DHD EGP EGPS GP GS IC ITIL ITSMF OGC PAIS PDCA PMBOK PMI PMO PQS RDM RUP SPMO TCO TI VE VME WBS Acordo de Nível Operacional Acordo de Nível de Serviço Banco de Dados de Gerenciamento da Configuração Biblioteca de Software Definitiva Contrato de Apoio Central Communications and Telecom Agency (Agência Central de Comunicações e Telecomunicações) Depósito de Hardware Definitivo Escritório de Gerenciamento de Projetos Escritório de Gerenciamento de Projetos e Serviços Gerenciamento de Projetos Gerenciamento de Serviços Item de Configuração Information Technology Infrastructure Library (Biblioteca de Infraestrutura em Tecnologia da Informação) Information Technology Service Management Fórum (Fórum de Gerenciamento de Serviços de TI) Office of Government Commerce (Escritório de Comércio do Governo) Programa de Aperfeiçoamento Ininterrupto do Serviço Plan-Do-Check-Act (Planejar, fazer, verificar e agir) Project Management Body Of Knowledge (Base de Conhecimento em Gerenciamento de Projeto) Project Management Institute (Instituto de Gerenciamento de Projeto) Project Management Office (Escritório de Gerenciamento de Projetos) Plano de Qualidade de Serviço Requisição de Mudança Rational Unified Process (Processo Racional Unificado) Service and Project Management Office (Escritório de Gerenciamento de Projetos e Serviços) Total Cost of Ownership (Custo Total de Propriedade) Tecnologia da Informação Valor Esperado Valor Monetário Esperado Work Breakdown Structure (Estrutura Analítica do Projeto)

SUMÁRIO LISTA DE ILUSTRAÇÕES...viii LISTA DE TABELAS...x LISTA DE ABREVIATURAS E SIGLAS...xi SUMÁRIO...xii 1 INTRODUÇÃO...14 2 OBJETIVOS...18 3 JUSTIFICATIVAS...19 4 METODOLOGIA...20 5 GERENCIAMENTO DE PROJETOS SEGUNDO O PMBOK...21 5.1 PROJETO...22 5.2 CICLO DE VIDA DE UM PROJETO...23 5.3 ORGANIZAÇÃO DO PROJETO...27 5.4 GERENCIAMENTO DE PROJETOS...29 5.5 PROJETOS E A ESTRATÉGIA DE NEGÓCIOS...40 6 GERENCIAMENTO DE SERVIÇOS COM A ITIL...42 6.1 GOVERNANÇA DE TI...43 6.2 GERENCIAMENTO DE SERVIÇOS DE TI...44 6.3 ITIL...45 6.3.1 Gerenciamento de Serviços...46 6.3.1.1 Entrega de Serviços...47 6.3.1.2 Suporte ao Serviço...52 6.3.2 Gerenciamento de Segurança...58 6.3.3 Gerenciamento da Infra-estrutura de TI...58 6.3.4 Gerenciamento da Aplicação...59 6.3.5 A Perspectiva do Negócio...60 6.3.6 Planejamento para Implementar o Gerenciamento de Serviços...61 7 ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS...64 7.1 CONCEITO DE EGP...65 7.2 MOTIVOS PARA IMPLEMENTAR UM EGP...67 7.3 TIPOS OU MODELOS DE EGP...69 7.3.1 EGP de Nível 1...71 7.3.2 EGP de Nível 2...71 7.3.3 EGP de Nível 3...72 7.4 FUNÇÕES DE UM EGP...73 7.5 ESTRUTURA DE UM EGP...75 7.6 IMPLANTAÇÃO DE EGP...77 7.6.1 Fases de implantação...77 7.6.1.1 Fase de Projeto ou Planejamento...78 7.6.1.2 Fase de Implantação...78 7.6.1.3 Fase de Operação...79 7.6.1.4 Fase de Melhoria Contínua...80 7.6.2 Outra abordagem de implantação...80 7.7 FATORES DE SUCESSO NA IMPLANTAÇÃO DE EGP...82 7.8 BENEFÍCIOS COM A IMPLANTAÇÃO DE EGP...84 7.9 O EGP E O ALINHAMENTO ESTRATÉGICO...86 8 ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS E SERVIÇOS DE TI...88

8.1 CONCEITO DE EGPS DE TI...89 8.2 ATRIBUIÇÕES DE UM EGPS...91 8.3 MODELOS DE EGPS...93 8.4 ESTRUTURA DO EGPS...94 8.4.1 Papéis executivos e gerenciais...95 8.4.2 Papéis da Gerência de Projetos...97 8.4.3 Papéis da Gerência de Serviços...97 8.5 IMPLANTAÇÃO DO EGPS...100 8.5.1 Fases de implantação...101 8.5.1.1 Fase de Planejamento...101 8.5.1.2 Fase de Implantação...102 8.5.1.3 Fase de Operação...102 8.5.1.4 Fase de Melhoria Contínua...103 9 CONCLUSÃO...105 REFERÊNCIAS...108 xiii

1 INTRODUÇÃO No mundo atual é cada vez maior o número de organizações dependentes de sistemas de software e de Tecnologia da Informação (TI) em todos os ramos da sociedade. O software está presente na gestão de empresas, automação de produtos, controle de sistemas e em praticamente toda a atividade humana. Os principais desafios enfrentados pela indústria de software e gerentes de TI são gerar produtos que atinjam às expectativas dos clientes, obedecendo a prazos, custos e critérios de qualidade, e garantir a operação destes no ambiente corporativo, por meio de processos que dêem suporte às estratégias de negócio, agilize a tomada de decisão, reduzam a ineficiência operacional e ofereçam um diferencial competitivo à organização. Porém, há uma complexidade inerente ao desenvolvimento de software e os problemas que podem surgir nessa atividade desencadearam o que muitos observadores chamaram de crise ou aflição crônica do software. Segundo Pressman (1995, p. 23), os problemas mais comuns que afligem a área de desenvolvimento são: (1) a dificuldade de cumprir o cronograma e entregar o produto dentro do prazo; (2) o software geralmente é entregue com custo maior do que o estimado inicialmente; (3) baixa produtividade dos profissionais da área em relação à crescente demanda por novos produtos e serviços; (4) insatisfação do cliente com produtos que não atendem às suas reais necessidades e com altos índices de erros, ocasionando falta de confiança quanto à qualidade; (5) documentação precária ou inexistente acarretando problemas e impondo alto custo de manutenção. Para superar a crise, Pressman aponta a adoção de uma abordagem de engenharia ao desenvolvimento de software, aliada a uma contínua

15 melhoria de técnicas e ferramentas associadas. Uma das técnicas adotadas pela Engenharia de Software é o Gerenciamento de Projetos (GP). Pressman (1995, p. 55) afirma que para conduzir um projeto de software bem-sucedido é necessário compreender o escopo do trabalho a ser feito, os riscos envolvidos, os recursos exigidos, as tarefas que deverão ser executadas, os marcos de referência a serem acompanhados, o esforço ou custo despendido e a programação a ser seguida. Resende (2006) observa que tais projetos são importantes, todavia possuem natureza de alto risco. Para Sommerville (2003, p. 60), gerenciar projetos é necessário porque a Engenharia de Software profissional está sempre sujeita às restrições de orçamento e prazo. Se as atividades de GP forem aplicadas é possível que o projeto cumpra essas restrições e seja concluído com sucesso. Por outro lado, a falta de gerenciamento geralmente resulta no fracasso do mesmo. Em uma pesquisa realizada em 1994 pelo The Standish Group (1995) sobre a situação dos projetos de TI nos Estados Unidos, observou-se que apenas 16% destes foram bem-sucedidos, ou seja, entregues dentro do prazo, custo e especificações, 53% tiveram problemas e 31% falharam completamente. A partir de então, mais segmentos da indústria passaram a aplicar as técnicas de GP em suas atividades. Dados mais recentes da mesma pesquisa (2004) mostram que o número de projetos bem-sucedidos subiu para 29%, os índices dos que falharam caiu para 18%, porém, 53% continuaram a ter problemas com relação a funcionalidades, atrasos ou acima orçamento. A figura 1 compara as duas fases da pesquisa (THE STANDISH GROUP INTERNATIONAL, 2004).

16 Figura 1. Situação dos projetos de TI em 1994 e 2004. Fonte: Braxis IT Services. Apesar dos dados apontarem uma evolução quanto ao número de projetos bem-sucedidos, observa-se que ainda é alto o índice de falhas ou problemas. O gerenciamento de projetos não deve ser praticado de forma arbitrária, mas conforme técnicas reconhecidamente eficientes, dentre as quais se destacam as recomendações do Project Management Institute (PMI) no Project Management Body Of Knowledge (PMBOK). O PMBOK é um guia de orientação que descreve um conjunto de conhecimentos e melhores práticas em GP. Segundo o guia, ao empregar corretamente essas diretrizes aumentam as chances de sucesso dos projetos. O método pode ser aplicado a todas as áreas que lidam com a atividade, incluindo a produção de software (PMI, 2004). O gerenciamento dos projetos de uma organização pode ser suportado por uma unidade organizacional denominada Escritório de Gerenciamento de Projetos (EGP). Fatores como a demanda por um gerenciamento mais eficaz, a multiplicação do número de projetos e a crescente complexidade dos mesmos, justificam a implantação do EGP. Este exerce a função de consolidar as atividades

17 de GP da organização, mediante a padronização de processos, divulgação de melhores práticas e fornecimento de uma infra-estrutura para o gerenciamento corporativo de projetos, diminuindo os índices de falhas e priorizando os mais importantes (ANSELMO, 2002). Além de gerenciar os projetos sob sua responsabilidade, a área de TI está cada vez mais preocupada em buscar processos que garantam a efetividade dos serviços por ela prestados. Pesquisas apontam que, dentro do ciclo de vida dos produtos de TI, a operação demanda cerca de 80% do tempo e dos custos totais. Assim, processos eficientes de Gerenciamento de Serviços (GS) são fundamentais para obtenção de bons resultados. Ademais, os serviços de TI também devem ser gerenciados de modo a estarem alinhados aos objetivos estratégicos da organização. Dentre as diversas abordagens de GS, uma das mais reconhecidas e utilizadas pela indústria de software atualmente é a Information Technology Infrastructure Library (ITIL), criada pelo Office of Government Commerce (OGC). O modelo consiste em um conjunto de melhores práticas de GS de TI, e descreve os processos necessários para gerenciar a infra-estrutura de TI de modo a garantir os níveis de serviço acordados com os clientes de forma eficaz (MANSUR). Este trabalho propõe a integração das técnicas de GP e GS em um novo conceito de EGP, denominado EGPS Escritório de Gerenciamento de Projetos e Serviços de TI. O modelo visa contribuir para que os responsáveis pelo desenvolvimento de software e gestores da área de TI obtenham maior sucesso em suas atividades, com a aplicação de uma abordagem sistêmica aos processos da organização, possibilitando à mesma, maior retorno nos investimentos em TI.

2 OBJETIVOS O objetivo principal deste trabalho é definir um modelo de Escritório de Gerenciamento de Projetos e Serviços de TI, o qual consiste em uma unidade responsável por apoiar a implementação das atividades de gerenciamento de projetos e serviços no contexto das áreas de Desenvolvimento de Software e Tecnologia da Informação, auxiliando os responsáveis desses setores a controlar seus projetos e serviços satisfatoriamente. Para atingir o objetivo principal serão cumpridos os seguintes objetivos específicos: (1) descrever as melhores práticas de GP recomendadas pelo PMBOK; (2) identificar os processos de GS de TI segundo o modelo de referência ITIL; (3) conceituar e detalhar o funcionamento de um EGP; (4) Descrever o conceito e apresentar diretrizes para implantação do Escritório de Gerenciamento de Projetos e Serviços de TI nas organizações.

3 JUSTIFICATIVAS De forma geral, os profissionais responsáveis pelo desenvolvimento de software têm percebido a importância de aplicar as técnicas, metodologias e ferramentas de Gerenciamento de Projetos como base para a obtenção de sucesso em seus empreendimentos. Da mesma forma, com a exigência cada vez maior por parte das corporações do retorno nos investimentos em TI e a necessidade de focar os objetivos dos projetos aos objetivos estratégicos da organização, ganha espaço na indústria de software a adoção de modelos de Gerenciamento de Serviços. Além dos motivos citados acima, a ampliação do número de projetos de TI, a crescente complexidade dos mesmos e a necessidade de agregar valor aos projetos, alinhando-os aos objetivos de negócio das corporações, destacam a importância da implantação do EGP no seio das organizações. Com a descrição do funcionamento de um Escritório de Gerenciamento de Projetos e Serviços e o detalhamento das melhores práticas de GP e de GS, espera-se apresentar diretrizes para que as organizações possam se basear e iniciar (ou mesmo aperfeiçoar) as práticas de GP e GS, e assim obterem mais sucesso em suas atividades e o retorno esperado dos investimentos em TI.

4 METODOLOGIA O presente estudo foi desenvolvido utilizando a abordagem de pesquisa qualitativa, a qual se baseia na busca pela compreensão do contexto do fenômeno a ser investigado utilizando várias fontes de dados que são descritas e interpretadas indutivamente. Para isso, empregou-se também o método de pesquisa descritiva, que consiste, segundo Cruz & Ribeiro (2004), no estudo, análise, registro e interpretação dos fatos do mundo físico sem a interferência do pesquisador. Para o levantamento de dados foram escolhidos os procedimentos de pesquisa bibliográfica e documental. De acordo com Marconi & Lakatos (2003, p. 158), a pesquisa bibliográfica consiste em um apanhado geral sobre os principais trabalhos já realizados, dotados de considerável importância e capazes de fornecer subsídios atualizados para o entendimento do tema em estudo. Um dos documentos pesquisados foi o PMBOK, publicado pelo PMI, o qual trata da metodologia e melhores práticas de Gerenciamento de Projetos. Outro documento consultado foi o guia introdutório da biblioteca ITIL, publicado OGC, órgão responsável pelo desenvolvimento do modelo de referência ITIL. A pesquisa bibliográfica complementou os conteúdos documentais, além de fundamentar o conceito de EGP. Após a coleta de dados e fundamentação teórica, passou-se para a análise e interpretação dos mesmos. Esta atividade representa a aplicação lógica dedutiva e indutiva do processo de investigação (MARCONI & LAKATOS, 2003), a qual culminou com a proposta de definição do EGPS de TI, fruto da correlação entre os temas estudados: GP, GS e EGP.

5 GERENCIAMENTO DE PROJETOS SEGUNDO O PMBOK A disciplina de Gerenciamento de Projetos (GP) surgiu como ciência a partir da década de 60, com a indústria bélica e aeroespacial americana. Por sua eficácia, passou a ser adotada em diferentes áreas da engenharia. Atualmente é aplicada em diversos setores da economia, incluindo a indústria de software. Com a criação do Project Management Institute (PMI), em 1969, sua disseminação passou a ocorrer com maior intensidade (MARTINS, 2005, p. 3). O PMI é uma entidade internacional que reúne os profissionais da área de GP e tem como objetivos promover o profissionalismo e desenvolver o estado da arte na gestão de projetos. O principal documento produzido pelo PMI é o Project Management Body Of Knowledge (PMBOK), um manual de procedimentos que visa uniformizar a teoria associada à gestão de projetos (MARTINS, 2005, p. 3). O PMBOK fornece uma visão geral sobre um conjunto de conhecimentos e melhores práticas em GP. Amplamente reconhecido, promove um vocabulário comum para se discutir, escrever e aplicar a atividade de GP de forma adequada. O guia busca identificar os conceitos e práticas envolvidas, e padronizar as terminologias e os processos empregados para esse fim (PMI, 2004, p. 3). Este capítulo apresenta os fundamentos e práticas de GP recomendadas pelo PMI através do PMBOK. Inicialmente é abordado o conceito de projeto, seguido pela descrição de seu ciclo de vida e organização. Na seqüência, busca-se compreender o que é GP e quais os processos que o compõem. Por fim, observa-se a relação entre os projetos e as estratégias de negócio das organizações.

22 5.1 Projeto De acordo com o PMBOK (2004, p. 5), um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. O fato de ser temporário indica que todo projeto tem início e fim bem definidos, isto é, não são esforços contínuos, mas finitos, ainda que possam demorar vários anos até serem concluídos. Um projeto é encerrado quando seus objetivos são atingidos, quando se observa que não será possível atingi-los ou quando não existir mais a necessidade do mesmo (PMI, 2004, p. 5). Por outro lado, o produto, serviço ou resultado criado pelo projeto geralmente é duradouro e exclusivo, ou seja, singular. Isso significa que, por mais que os projetos desenvolvidos sejam parecidos, difere-se de alguma forma de outros já executados e cada qual em particular é único. Essa característica denota que fatores como incerteza e risco são inerentes a todo projeto (PMI, 2004, p. 5). O PMBOK (2004, p. 6) aponta que há diferença entre os projetos e o trabalho operacional de uma organização. O segundo consiste em operações contínuas e repetitivas, enquanto que o primeiro em atividades temporárias e exclusivas. Além disso, os projetos buscam atingir seus objetivos e em seguida são terminados, ao passo que as operações têm a mesma finalidade, mas continuam mantendo o negócio. Apesar de distintos, projetos e operações compartilham várias características, como o fato de serem realizados por pessoas, limitados por prazos, custos e escopo, além de necessitarem de planejamento, execução e controle. Ainda segundo o PMBOK (2004, p. 7), projetos são freqüentemente utilizados como um meio de atingir o plano estratégico da organização, como

23 atender uma demanda de mercado, uma necessidade organizacional, o pedido de um cliente, um avanço tecnológico ou mesmo um requisito legal. 5.2 Ciclo de Vida de um Projeto Um projeto pode ser subdividido em fases para oferecer melhor controle gerencial aos responsáveis pela sua execução. O ciclo de vida define as fases que conectam o início do mesmo ao seu final (PMI, 2004, p. 19). Martins (2005, p. 6) esclarece que os ciclos definem a natureza das atividades a serem realizadas em cada fase, como especificação, design, construção e outras. Além disso, a transição de uma fase para outra normalmente culmina com a entrega de artefatos, que geralmente são revisados e submetidos à aprovação para garantir que estejam completos e exatos. Esses artefatos são elementos mensuráveis e verificáveis, como uma especificação, um relatório, um documento, um arquivo executável ou um protótipo. Geralmente, os insumos gerados por uma fase são empregados nas fases seguintes. Todavia, uma fase pode ser iniciada antes da aprovação de entregas anteriores, caso os riscos envolvidos sejam considerados aceitáveis (PMI, 2004, p. 20). O PMBOK (2004, p. 20) aponta determinadas características que podem ser observadas durante o andamento do ciclo de vida do projeto. Uma dessas características indica que os níveis de custo e gasto com pessoal são baixos no início, aumentam e atingem o valor máximo durante as fases intermediárias e caem conforme o projeto vai sendo finalizado. A figura 2 ilustra esse comportamento.

24 Figura 2. Níveis de custo e pessoal ao longo do ciclo de vida do projeto. Fonte: PMI, 2004. Por outro lado, o risco de não atingir os objetivos é maior no início do projeto, principalmente devido às incertezas. Conforme este avança e se adquire mais conhecimento sobre o mesmo, o risco diminui progressivamente (MARTINS, 2005, p. 6). Figura 3. Riscos do projeto durante o ciclo de vida. Fonte: MARTINS, 2005.

25 Outra característica refere-se à capacidade dos stakeholders de influenciar as características finais do produto do projeto e o custo final do mesmo. Esta é mais alta no início, diminuindo conforme o trabalho avança. Ao contrário, o custo de implementação de mudanças e correções é baixo inicialmente e aumenta com o andamento do projeto. Figura 4. Influência dos stakeholders e custo das mudanças durante o ciclo de vida do projeto. Fonte: PMI, 2004. O PMBOK (2004, p. 22) esclarece que as fases do ciclo de vida fazem parte de um processo seqüencial criado para garantir o controle adequado do projeto e atingir seu objetivo. Em certas circunstâncias, as fases podem ser divididas em subfases, por motivo de restrições de tamanho, complexidade, riscos ou custo. Normalmente, cada subfase possui artefatos a serem produzidos, relacionados à fase principal, como requisitos, projeto, construção, teste, implantação e outros. Ainda conforme o PMBOK (2004, p. 22), a conclusão de uma fase ocorre com a revisão do trabalho realizado e dos artefatos produzidos, visando assegurar a conformidade dos mesmos e validar o encerramento da mesma.

26 Todavia, pode-se decidir iniciar a próxima fase sem que a atual esteja completamente concluída, realizando as atividades em paralelo. É possível ainda tomar a decisão de encerrar a fase e não iniciar as outras, caso o projeto tenha chegado ao fim ou o risco de continuar e não atingir os objetivos seja considerado grande demais. Além disso, a definição do ciclo de vida do projeto identificará as ações a serem tomadas para fazer a transição deste e implementar seus resultados às operações em andamento da organização. O PMBOK (2004, p. 24) frisa que é necessário distinguir o ciclo de vida do projeto do ciclo de vida do produto. O primeiro pode ser uma parte do segundo, o qual é composto por outras fases que abrangem desde a identificação da necessidade comercial do produto até o acompanhamento dos resultados após a implantação do mesmo, como por exemplo, elaboração do Plano de Negócios, comercialização e atualização. A figura 5 ilustra a relação entre os ciclos de vida do projeto e do produto. Figura 5. Relação entre os ciclos de vida do projeto e do produto. Fonte: PMI, 2004.

27 5.3 Organização do Projeto Segundo o PMBOK (2004, p. 24), os stakeholders e a organização executora, com seu sistema de GP, cultura, estilo, estrutura organizacional e EGP podem exercer influência sobre os objetivos e resultados do projeto. O guia recomenda que a equipe de GP identifique as partes interessadas, suas necessidades, expectativas, responsabilidades e autoridade, e controle o nível de influência dos mesmos, tanto positiva quanto negativamente, em relação aos objetivos do projeto. Os stakeholders mais comuns são: Gerente do projeto: responsável pelo gerenciamento do projeto; Cliente ou usuário: pessoa ou organização que fará uso do produto ou serviço do projeto; Organização executora: empresa responsável pela execução do projeto; Equipe do projeto: colaboradores que executarão o trabalho do projeto; Equipe de gerenciamento do projeto: encarregados diretamente envolvidos nas atividades de gerenciamento do projeto; Patrocinador: Fornece os recursos financeiros para a realização do projeto; Influenciadores: Pessoas ou grupos que podem influenciar positiva ou negativamente o andamento do projeto; EGP: Pode ter responsabilidade direta ou indireta pelo resultado do projeto, caso exista na organização executora.

28 Figura 6. Relação entre os stakeholders do projeto. Fonte: PMI, 2004. A maturidade da organização executora também exerce influência sobre a realização do projeto. Organizações cujos sistemas organizacionais são baseados em projetos normalmente possuem sistemas de gerenciamento coordenados para dar suporte às necessidades dos mesmos de modo efetivo, enquanto que as que não são não os possuem. Da mesma forma, a cultura da organização quanto a normas, crenças, expectativas, valores compartilhados, políticas, procedimentos, hierarquia, visão ética e sistema funcional interferem diretamente no curso do projeto. A estrutura da organização, por sua vez, afeta também diversas características deste, dependendo se esta é funcional, matricial ou por projeto (PMI, 2004, p. 27-31). O quadro 1 mostra algumas dessas características e a relação destas com as diferentes estruturas organizacionais.