UNIVERSIDADE PARA O DESENVOLVIMENTO DO ALTO VALE DO ITAJA JULIANO VICENTE

PROPOSTA PARA IMPLANTAO DE UM MODELO DE GERENCIAMENTO DE PROJETOS EM UMA FBRICA DE SOFTWARE COM BASE NO PMBOK

RIO DO SUL 2008

UNIVERSIDADE PARA O DESENVOLVIMENTO DO ALTO VALE DO ITAJA JULIANO VICENTE

PROPOSTA PARA IMPLANTAO DE UM MODELO DE GERENCIAMENTO DE PROJETOS EM UMA FBRICA DE SOFTWARE COM BASE NO PMBOK
Trabalho de concluso de curso elaborado para o Curso de Bacharel em Sistemas de Informao, rea das Cincias Naturais, da Computao e das Engenharias, da Universidade para o Desenvolvimento do Alto Vale do Itaja UNIDAVI, como requisito parcial para a obteno do grau de Bacharel em Sistemas de Informao. Prof. orientador: Fernando Bastos

RIO DO SUL 2008

JULIANO VICENTE

PROPOSTA PARA IMPLANTAO DE UM MODELO DE GERENCIAMENTO DE PROJETOS EM UMA FBRICA DE SOFTWARE COM BASE NO PMBOK

Trabalho de concluso do curso de Bacharel em Sistemas de Informao da Universidade para o Desenvolvimento do Alto Vale do Itaja, a ser apreciado pela seguinte banca examinadora, formado por:

_______________________________________ Professor Orientador: Fernando Bastos Banca Examinadora _______________________________________ Professor Fernando Bastos ________________________________________ Professor Marcondes Maaneiro _________________________________________ Professor Marco Aurlio Butzke

Rio do Sul, novembro de 2008.

minha me, pela pacincia, persistncia e amor.

AGRADECIMENTOS

Primeiramente a Deus por sua glria. Agradeo a minha me por tudo que fez e faz por mim Obrigado Dani, namorada e companheira. minha irm Deise e meu pai Amarildo, amo muito vocs Amigos, irmos, familiares e tantos queridos que o fato de no mencionar o nome no significa que no estou lembrando. Quando eu abra-los pessoalmente, vocs iro saber o quanto sou grato. Bastos, sem dvida nenhuma escolheria voc tantas vezes fosse necessrio para ser meu orientador. Delsoft Sistemas e seus diretores, colaboradores e parceiros. Enfim, sou grato!

RESUMO

Este trabalho determinado no objetivo de apresentar uma proposta de implantao de um modelo de gerenciamento de projetos baseado no PMBOK em empresas de desenvolvimento de software, visando contribuir nesta empresa para o desenvolvimento de produtos com melhor qualidade, tanto no produto final, quanto no seu processo de desenvolvimento. A empresa Delsoft Sistemas Ltda, que atua no mercado nacional no desenvolvimento de ERP foi usada como parmetro para o desenvolvimento do modelo de gerenciamento, pois como o PMBOK um guia das melhores prticas nem sempre o que aplicado em um projeto serve para o outro. Na fundamentao terica buscou-se introduzir os modernos conceitos de gerenciamento de projetos e suas aplicaes para ento formular um modelo adequado, flexvel e possvel de aplicar e implantar, tomando muito cuidado para no tornar o processo burocrtico. Viu-se a necessidade de aplicar o modelo em um projeto piloto para poder ter uma melhor dimenso do grau de complexidade e dos efetivos resultados.

Palavras chave: Gerenciamento de Projetos, PMBOK, Software.

LISTA DE FIGURAS

Figura 1 - Tripla Restrio............................................................................................................. 17 Figura 2 Chaos Report................................................................................................................ 18 Figura 3 Ciclo de Vida de um Projeto ........................................................................................ 21 Figura 4 - Relao entre as partes interessadas e o Projeto ........................................................... 22 Figura 5 reas do conhecimento do PMBOK............................................................................ 24 Figura 6 Processos de gerenciamento da integrao .................................................................. 25 Figura 7 - Viso geral gerenciamento de integrao ..................................................................... 28 Figura 8 - Viso geral do gerenciamento de Escopo ..................................................................... 31 Figura 9 - Viso geral do gerenciamento de tempo....................................................................... 34 Figura 10 - Gerenciamento de Custos ........................................................................................... 35 Figura 11 - Viso geral do gerenciamento de custos..................................................................... 36 Figura 12 - Viso geral do gerenciamento da qualidade do projeto.............................................. 39 Figura 13 - Viso geral do Gerenciamento de Recursos Humanos............................................... 42 Figura 14 - Comunicao em duas vias......................................................................................... 43 Figura 15 - Viso geral do gerenciamento das comunicaes....................................................... 45 Figura 16 - viso geral do gerenciamento de riscos ...................................................................... 47 Figura 17 - Tipos de Contratos e Riscos Associados .................................................................... 49 Figura 18 Viso geral do gerenciamento de aquisies ............................................................. 50

LISTAS DE QUADROS

Quadro 1 Mitos e conceitos revistos. ......................................................................................... 14

LISTA DE TABELAS

Tabela 1 - Custo da conformidade x custo da no-conformidade ................................................. 38

10

LISTA DE ABREVIATURAS E SIGLAS

ANSI CPPC CPPF EAP ERP FFP FPI IEEE ISO PMI PMO TI WBS

American National Standards Institute Cost Plus Percentage Cost Cost Plus Fixed Fee Estrutura Analtica do Projeto Enterprise Resource Planning Firm Fixed Price Fixed Price Incentive Institute Electrical and Electronics Engineers International Organization for Standardization Project Management Institute Project Management Officer Tecnologia da Informao Work Breakdown Structure

PMBOK Project Management Body of Knowledge

11

SUMRIO 1 2 3 3.1 3.2 4 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.3.8 4.3.9 5 5.1 5.2 6 INTRODUO........................................................................................................12 JUSTIFICATIVA .....................................................................................................13 OBJETIVOS............................................................................................................15 OBJETIVO GERAL---------------------------------------------------------------------------------15 OBJETIVOS ESPECFICOS ----------------------------------------------------------------------15 FUNDAMENTAO TERICA..............................................................................16 PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK) ----------------------16 GERENCIAMENTO DE PROJETOS------------------------------------------------------------16 Por que Gerenciar Projetos? ------------------------------------------------------------------16 Principais causas de Fracasso em Projetos ------------------------------------------------18 Fases do Projeto----------------------------------------------------------------------------------21 Partes Interessadas no projeto (Stakeholders) --------------------------------------------22 REAS DE CONHECIMENTO DO PMBOK--------------------------------------------------23 Gerenciamento da integrao-----------------------------------------------------------------24 Gerenciamento de Escopo ---------------------------------------------------------------------29 Gerenciamento de Tempo ---------------------------------------------------------------------32 Gerenciamento de Custos----------------------------------------------------------------------35 Gerenciamento de Qualidade -----------------------------------------------------------------36 Gerenciamento de Recursos Humanos------------------------------------------------------40 Gerenciamento de Comunicao -------------------------------------------------------------43 Gerenciamento de Riscos ----------------------------------------------------------------------46 Gerenciamento das Aquisies ---------------------------------------------------------------48 APLICANDO GERENCIAMENTO DE PROJETOS................................................51 TEMPLATES PARA GERENCIMENTO DE PROJETOS-----------------------------------51 RESULTADOS OBTIDOS ------------------------------------------------------------------------54 CONCLUSES .......................................................................................................55

RECOMENDAES......................................................................................................56 REFERNCIAS..............................................................................................................57 APNDICE A .................................................................................................................58

12

INTRODUO

Com o mercado cada vez mais acirrado e necessitando atender as demandas de maneira rpida e eficaz, faz-se necessrio utilizar uma ferramenta que atenda a essa nova necessidade. Nos ltimos tempos, as empresas passaram a ser reconhecidas por sua flexibilidade no atendimento aos clientes, onde praticamente no existem rotinas e sim projetos. Ento se gerenciar projetos uma vantagem e est se tornando uma necessidade faz-se necessrio um guia, alguma ferramenta que auxilie e seja comprovadamente eficaz. Mas primeiro precisamos entender que projeto um conjunto de aes, onde lidera-se pessoas e recursos, visando um objetivo claro que deve ser feito dentro de trs conceitos: Prazo, Oramento, Especificao. Gerenciamento de projetos pode ser aplicado em qualquer situao desde que no sejam trabalhos rotineiros e fixos. Temos que entender que a diferena entre projetos e atividades rotineiras est nos objetivos. Para ficar ainda mais claro, projetos diferentemente de rotinas tem tempo determinado. Aplicar gerenciamento de projetos requer empenho e a excelncia s atingida com o tempo, entretanto resultados so obtidos logo nas primeiras utilizaes. Para atender a todas as necessidades de gerenciamento temos o Project Management Body of Knowledge (PMBOK). O grande erro achar que o PMBOK uma metodologia, contudo na realidade PMBOK um guia de melhores prticas. Quando aplicado deve ser adaptado para o projeto em questo. Nos 44 processos do PMBOK nem todos necessariamente precisam ser usados e essa flexibilidade que faz do PMBOK uma ferramenta excelente para gerenciar projetos. Com tudo isso buscou-se uma fundamentao terica coerente em gerenciamento de projetos utilizando o PMBOK como referencia principal. Dentro da limitao proposta nesse trabalho conseguiu-se criar um modelo com sucesso para ser seguido em gerenciamento de projetos de pequeno porte.

13

JUSTIFICATIVA

A Delsoft Sistemas atua desde 1993 na rea de tecnologia da informao, e necessita de um modelo para definir, planejar, gerenciar, executar e concluir os projetos com as melhores prticas podendo competir com seus concorrentes. Aps o ingresso de alguns de seus funcionrios em uma ps-graduao de gerenciamento de projetos bem como a visualizao da necessidade de melhorar seus projetos conseguindo assim um maior controle dos mesmos apareceu a necessidade de utilizar um guia como PMBOK. Segundo Vargas (2005) O gerenciamento de projetos um conjunto de ferramentas gerenciais que permitem que a empresa desenvolva um conjunto de habilidades, incluindo conhecimento e capacidades individuais, destinados ao controle de eventos no repetitivos, nicos e complexos, dentro de um cenrio de tempo, custo e qualidade pr-determinados. Para entendermos gerenciamento de projetos necessrio ter bem claro o que significa projetos. Para Meredith (1995), um projeto uma atividade nica e exclusiva com um conjunto de resultados desejveis em seu trmino. Segundo Darci Prado, Um empreendimento nico e no repetitivo, de durao determinada, formalmente organizado e que congrega e aplica recursos visando o cumprimento de objetivos preestabelecidos. Com a utilizao deste modelo a Delsoft busca muitos benefcios tais quais podemos citar: 1. Evitar surpresas durante a execuo dos trabalhos; 2. Desenvolver diferenciais competitivos e novas tcnicas, tendo em vista que o modelo est sendo estruturado. 3. Antecipar situaes desfavorveis antes que estas se consolidem como problemas, trazendo aes preventivas e corretivas. 4. Disponibilizar oramentos antecipados e de forma clara e precisa; 5. Agilizar as decises, j que as informaes esto estruturadas e disponibilizadas; 6. Otimizar a alocao de pessoas 7. Documentar e facilitar estimativas para futuros projetos 8. Reduzir o retrabalho 9. Aumentar o lucro

14

10. Melhorar a qualidade do software Outro aspecto a ser considerado a crescente competio com concorrentes j consagrados no mercado levando a Delsoft a mostrar fatores decisivos em suas vendas, reduzindo o retrabalho e o risco em seus projetos. Para Kerzner (2006) o gerenciamento de projetos pode ser adotado pelos seguintes motivos: competio, padres de qualidade, reduo nas margens de lucro, resultados financeiros, fatores tecnolgicos, aspectos legais, aspectos sociais, fatores polticos, presses econmicas. Um fator importante no gerenciamento de projetos so os mitos que geralmente so associados a ele tais como segue na tabela a seguir proposta por Kerzner no quadro 1: Mitos Gerenciamento de projetos requer empresa A lucratividade pode diminuir em decorrncia dos custos de controle O gerenciamento de projetos aumenta o nmero de mudanas no escopo. O gerenciamento de projetos cria conflitos entre departamentos O gerenciamento de projetos cria problemas O gerenciamento de projetos cria problemas de poder e autoridade O gerenciamento de projetos tem como objetivo os produtos O custo de gerenciamento de projetos pode tornar a companhia menos competitiva
Quadro 1 Mitos e conceitos revistos. Fonte Kerzner (2006).

Conceitos Revisados Gerenciamento de Projetos permite ao tempo com menos pessoas A lucratividade ir aumentar devido a presena do controle O gerenciamento de projetos permite maior controle sobre as mudanas no escopo. O gerenciamento de projetos torna a mais eficiente e melhora efetivamente a relao entre os setores atravs do trabalho em equipe. O gerenciamento de projetos possibilita a soluo de problemas. O gerenciamento de projetos reduz os conflitos de poder O gerenciamento de projetos tem como objetivo as solues O gerenciamento de projetos aprimora os negcios da empresa

mais pessoas e adiciona custos indiretos a projeto realizar mais trabalho em menos

instabilidade organizacional e aumenta os organizao

15

OBJETIVOS

3.1

OBJETIVO GERAL Desenvolver uma proposta de modelo baseado nas melhores prticas em gerenciamento

de projetos para a empresa Delsoft Sistemas Ltda.

3.2

OBJETIVOS ESPECFICOS - Estudar Tcnicas e conceitos do PMBOK para desenvolver um modelo que melhor se

adapte aos processos da Delsoft Sistemas; - Montar os templates (formulrios) a serem utilizados no gerenciamento de projetos focando todas as fases de um projeto como: incio, planejamento, execuo, controle e encerramento sem ser burocrtico e de difcil aplicabilidade; - Aplicar o modelo em um projeto para anlise prtica vivenciando as dificuldades e coletando resultados para melhor adaptar o modelo; - Pesquisar conceitos de gerenciamento de projetos para ter um maior embasamento para tentar aproximar teoria da prtica.

16

4 4.1

FUNDAMENTAO TERICA

PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK) um conjunto de conhecimentos relativos a profisso de gerenciamentos de

projetos PMBOK (2004). Podemos dizer que so as melhores prticas identificadas em um livro que pode ser usado como referencia, pois amplamente reconhecido que significa que o conhecimento e as prticas descritas so aplicveis a maioria dos projetos na maior parte do tempo e que existe um consenso geral em relao ao seu valor e utilidade. Mas temos que ter em mente que o fato de ser melhores prticas no deve nos obrigar a aplicar uniformemente em todos os projetos e sim que a equipe que gerencia o projeto deve determinar o que adequado para o projeto. O PMBOK tambm cria um vocabulrio padro, o que essencial para sua utilizao genrica. A primeira edio do PMBOK foi escrita em 1987 pelo PMI (Project Management Institute) que foi fundada em 1969 e tem como participantes gerentes de projetos do mundo todo. A segunda verso (1996 e 2000) foi baseada em comentrios recebidos pelos membros. Em 1998 foi reconhecido como padro pelo American National Standards Institute (ANSI) e mais tarde pelo Institute of Electrical and Electronics Engineers (IEEE). A terceira edio do PMBOK foi publicada em 2004 com melhorias na estrutura, termos e adies aos processos. 4.2 GERENCIAMENTO DE PROJETOS

4.2.1 Por que Gerenciar Projetos? Podemos nos perguntar sobre o real valor e a aplicabilidade do Gerenciamento de Projetos na empresa. Existe um ditado popular que diz nada mais seguro de se afirmar, do que afirmar que nada mais seguro. Partindo dessa idia todos sabemos que tanto diretores quanto clientes no gostam de surpresas, e em um mundo de constante mudana nada melhor do que

17

executarmos nossos projetos com excelncia, planejando e gerenciando o mesmo a fim de chegar ao objetivo sem perder dinheiro, tempo e qualidade. Se partirmos da premissa que todo o risco carrega uma oportunidade, podemos dizer que gerenciar um projeto diminuir as incertezas, atingir a satisfao do cliente (interno ou externo) e chegar ao fim do projeto com a tripla restrio completamente executada.

Figura 1 - Tripla Restrio

Fonte: PMBOK (2004)

Segundo a pesquisa de Benchmarking em Gerenciamento de Projetos de 2005, desenvolvida pelo PMI-RJ, ainda existe em torno de 20% da empresas de TI (Tecnologia da Informao) que possuem resistncia ao tema gerenciamento de projetos. Em outras reas, certamente encontraremos um percentual de resistncia ainda maior que a rea de TI. Mas conhecendo melhor a pesquisa, principalmente ao longo dos anos que a ela aconteceu, percebemos que a resistncia est diminuindo. Para se ter noo o Standish Group, em seu relatrio CHAOS Report, de 2004, Mostra que 53% dos projetos foram entregues com problema, 18% falharam e apenas 29% foram concludos com sucesso. Se analisarmos 71% dos projetos tiveram problemas e isso refora mais a idia de gerenciamento de projetos.

18

60% 50% 40% 30% 20% 10% 0%

53%

29% 18%

Projetos com Problemas Projetos que Falharam Projetos de Sucesso

PROJETOS

Figura 2 Chaos Report

Fonte: Standish Group (2004)

4.2.2 Principais causas de Fracasso em Projetos Mesmo com todos os benefcios muitos projetos falham e no chegam aos objetivos propostos no escopo. Existem dois tipos de obstculos. Os naturais/externos que seriam mudanas no cenrio poltico por exemplo, ou mudanas na estrutura organizacional da empresa e o segundo tipo de falha que seriam as gerenciais, que podem ser evitadas, enumeradas de acordo com Dahis: Metas e Objetivos mal estabelecidos: Quando temos metas/ Objetivos superficiais ou desfocados o escopo acaba por tambm ser mal definido podendo causar o insucesso do projeto. Outro ponto que quando a equipe no sabe o real objetivo do projeto acaba ficando desmotivada e no comprometida com o mesmo; Muitas atividades e pouco tempo para realiz-las: O tempo em projetos SEMPRE uma restrio. Entretanto quando aplicado gerenciamento de tempo corretamente possvel otimizar at bem prximo do ideal, entretanto, h necessidade de sempre se deixar claro que

19

ningum mgico e se o tempo curto e o projeto no pode ter atrasos deve-se negociar com o Cliente/Patrocinador; Informaes insuficientes ou inadequadas: Pior do que informaes insuficientes so informaes incorretas. Nesse ponto um bom gerenciamento das comunicaes importantssimo para corrigir e evitar esses problemas; Tempo insuficiente para planejamento: quando nos fazem uma pergunta simples do tipo Quanto tempo voc leva para fazer esse projeto?. Normalmente nossa resposta baseada somente na execuo. Dificilmente acrescentamos planejamento nesse clculo. Outro erro que quando temos pouco tempo para resolver um problema, vamos direto para a execuo e achamos que planejar perda de tempo. E ai que mora o perigo. Projetos falham nos detalhes, mas que somados causam um problema muito grande; Os produtos finais no estavam bem definidos: entrai ai uma grande questo, um projeto entregue dentro do prazo, tempo, custo, especificao poderia ser considerado de sucesso caso o produto ou servio atendesse a necessidade do cliente. Entretanto produtos mal definidos causam perdas para as empresas prejudicando assim um projeto que poderia ser de sucesso; Cronogramas no realistas: um cronograma no uma obra de arte feita para agradar nosso cliente ou a expectativa das partes interessadas. Sempre deve-se fazer um cronograma realista. Podemos ter vrios problemas em cronogramas. Alguns deles podemos citar: EAP mal definida, causando erros nas tarefas a serem realizadas, Tarefas com prazos muito curtos ou por outro lado, tarefas com prazos muito longos. Por exemplo, quando pedimos a algum que faam uma tarefa normalmente essa pessoa coloca uma margem de segurana para garantir o cumprimento da mesma. Mas ainda assim, estoura o prazo. Podemos aplicar uma tcnica de pulmo para o projeto. mais ou menos como tirar das tarefas/atividades um percentual de tempo definido conforme o critrio do gerente de projetos. E esse tempo fica como uma contingncia no final do projeto para ser usado caso haja necessidade; Padres de trabalho no foram estabelecidos: falta de padro sempre foi um problema, pois fica difcil de controlar algo que no segue uma determinada linha. A aplicao do PMBOK tem esse objetivo, padronizar para poder controlar; M relao com os stakeholders (pessoas ou grupos interessadas no projeto) do projeto: stakeholders por definio livre so partes interessadas no projeto, mas quando no esto de acordo podem gerar um grande problema. Imaginamos um gerente de TI que tem recursos que

20

voc precisa para um projeto. E ele sente que no est ficando a par das informaes do projeto e assim acaba dificultando alocando recursos para outras atividades e no se comprometendo com o projeto. Sendo assim uma boa gesto de comunicao e recursos humanos pode ajudar a evitar e controlar esses problemas; Planejamento insuficiente: quanto mais detalhado planejarmos mais vamos trabalhar da forma ideal que a preventiva e no s reativa apagando incndios; Falta de participao da equipe na tomada de decises: sempre importante envolver a equipe nas tomadas de deciso. Ou deixar claro para os que no esto participando o porqu da reunio. Pessoas excludas podem se sentir desvalorizadas e consequentemente desmotivadas. Causando assim um srio problema ao projeto; O projeto baseado no feeling dos envolvidos: ter uma informao mais acertado do que acreditar em opinies. Um projeto que depende somente do feeling pode se tornar um insucesso devido a uma de suas caractersticas que algo no rotineiro; Pouca compreenso da complexidade do projeto: falta de compreenso gera um no comprometimento e certo descaso com o projeto; As estimativas financeiras so pobres e incompletas: um projeto com estimativas incompletas e pobres com certeza ir estourar o oramento, causando um srio problema para o gerente de projetos; O sistema de controle inadequado ou no feito: planejar preciso controlar uma necessidade. Pouco adianta ter um cronograma perfeito, se o controle dos prazos no est sendo feito e estes no esto sendo cumpridos conforme planejado. Outro problema so controles ineficientes e superficiais; Falta de alinhamento com os objetivos estratgicos da organizao: um projeto sempre deve estar alinhado com os objetivos, metas e valores da empresa, caso contrrio eles seguiro para caminhos contrrio causando problemas tanto nos resultados quando no decorrer do projeto. Imaginamos uma empresa que produz papel que tem por objetivo reduzir o corte de arvores em 20% para conseguir crditos de carbono e o gerente de um projeto novo desconhece esse objetivo faz todo um planejamento e comea a executar o projeto de um novo tipo de material que para sua origem necessita de um aumento no corte de rvores. Isso com certeza alteraria o resultado inviabilizando o projeto;

21

Falta de liderana do gerente de projetos: equipes precisam ser lideradas e se o gerente de projetos no o faz, a equipe se sente desnorteada e acaba cada um indo para um lado ao invs de todos caminharem para o mesmo objetivo; Falta de gerenciamento das mudanas: mudanas uma parte delicada de um projeto, pois pode alterar prazos, custos e at escopo, causando srios problemas ao projeto; Ferramenta de gerenciamento de projetos inadequada ou mau uso da mesma: no gerenciamento de projetos existem vrias ferramentas que podem ajudar desde a tomada de deciso at o controle. Entretanto, quando o conceito no totalmente entendido ou interpretado de forma errnea pode causar problemas e dar falsas informaes do projeto podendo causar insucessos e at inviabilizar o mesmo; Como podemos notar com algumas das informaes a cima o posicionamento reativo na maioria dos projetos pode causar os insucessos. Ou seja, se trabalharmos de forma preventiva estaremos nos antecipando, estando sempre um passo a frente; 4.2.3 Fases do Projeto Um projeto parte de uma idia passando pelo planejamento ento executado e concludo. Podemos ento genericamente segundo o PMBOK definir o ciclo de vida de um projeto conforme a figura 2:

Figura 3 Ciclo de Vida de um Projeto

Fonte: PMBOK (2004)

22

Fase Iniciao: Fase esta onde se identifica a necessidade e transformada em um problema estruturado passvel de soluo. Nesta fase, a misso e o objetivo do projeto so definidos. Fase de Planejamento: a fase responsvel por detalhar tudo que ser realizado (cronogramas, interdependncias entre atividades, alocao de recursos envolvidos, anlise de custos, etc.) Nessa fase so desenvolvidos os planos de riscos, qualidade, aquisio, e recursos humanos. Fase de Execuo: a fase que se coloca em prtica tudo o que foi planejado anteriormente. normalmente nessa fase que aparecem os erros. Oramento e esforo so maiores nessa fase. Fase de controle: uma fase paralela que acontece ao planejamento e execuo. Visa acompanhar e tomar aes corretivas e preventivas quando ocorre uma anormalidade. Comparase o previsto com o realizado do projeto. Fase de finalizao: Quando o projeto chega ao fim os documentos so encerrados e feita uma avaliao das lies aprendidas e o produto do projeto entregue.

4.2.4 Partes Interessadas no projeto (Stakeholders) Partes interessadas so pessoas e organizaes envolvidas no projeto cujo resultado do mesmo os afeta direta ou indiretamente. Conforme mostra figura 3:

Figura 4 - Relao entre as partes interessadas e o Projeto

Fonte: PMBOK (2004)

23

Principais partes interessadas conforme o PMBOK: Gerente de Projetos: A pessoal responsvel pelo gerenciamento de projetos; Cliente/Usurio: A pessoa ou organizao que utilizar o produto do projeto; Organizao Executora: A empresa cujos funcionrios esto mais diretamente ligados a execuo do trabalho do projeto; Membros da Equipe do Projeto: O grupo que est executando o trabalho do projeto; Equipe de gerenciamento de projetos: equipe que est diretamente ligada as atividades do projeto; Patrocinador: A pessoa ou grupo que fornece recursos financeiros, em dinheiro ou espcie, para o projeto; Influenciadores: Pessoas ou grupos que podem influenciar negativamente ou positivamente no projeto e que normalmente utilizaro o produto do projeto; PMO (Project Management Officer): se existir na organizao poder ser uma parte interessada se tiver responsabilidades diretas ou indiretamente com o Projeto.

4.3

REAS DE CONHECIMENTO DO PMBOK Conforme o PMBOK (2004) so nove reas de conhecimento e cada rea abrange

diversos processos. As reas so divididas como mostra a figura 4:

24

Figura 5 reas do conhecimento do PMBOK

Fonte: PMBOK (2004)

4.3.1 Gerenciamento da integrao Como o prprio nome diz o Gerenciamento da integrao engloba as outras reas para assegurar que todos os elementos sejam adequadamente coordenados e que estejam integrados. Segundo o PMBOK (2004) A rea de conhecimento em gerenciamento de integrao do projeto inclui os processos e as atividades necessrias para identificar, definir, combinar, unificar e coordenar os diversos processos e atividades de gerenciamento de projetos dentro dos grupos de processos de gerenciamento de projetos., ou seja, como podemos ver o gerenciamento da integrao o ncleo do gerenciamento de projetos. Ele responsvel por fazer com que todas as partes do projeto funcionem juntas, transformando tudo em um modelo funcional. Esta rea tambm responsvel pela integrao dos processos com as operaes normais da empresa bem como escopo do produto e do projeto. Conforme PMBOK temos como principais produtos dessa rea: Termo de abertura do projeto;

25

Declarao preliminar de escopo do projeto; Plano de gerenciamento do projeto; Reparos de eventuais defeitos ou desvios do projeto; Produto, servio ou resultado final do projeto; Documentao do encerramento administrativo do projeto.

Na figura 5, podemos ver o fluxo dos processos de gerenciamento da integrao:

Figura 6 Processos de gerenciamento da integrao

Fonte: Campbell e Cavalieri, 2005, modificado.

26

No processo de iniciao segundo o PMBOK temos: Termo de abertura do projeto: obter o comprometimento da organizao para o incio da prxima fase do projeto e desenvolver documento especfico autorizando formalmente o projeto ou uma de suas fases. Desenvolver a declarao de escopo preliminar do projeto: desenvolver documento especfico para formalizar, validando inicialmente com o patrocinador do projeto. Este documento uma descrio de alto nvel do escopo. Processo de Planejamento: Desenvolvimento do Plano do Projeto: agregar os resultados dos outros processos de planejamento construindo um documento coerente e consistente. Documentao das aes necessrias para a preparao e coordenao de todos os planos do projeto. Processo de Execuo: Orientar e Gerenciar a execuo do plano do projeto: levar a cabo o plano do projeto atravs da realizao das atividades nele includas para atingir os requisitos do projeto definidos na declarao do escopo. Processos de Monitoramento e controle: Monitorar e controlar o trabalho do projeto: monitoramento e controle dos processos exigidos para iniciar, planejar, executar e encerrar o projeto de formar a alcanar os objetivos definidos no plano de gerenciamento do projeto. Controle integrado de mudanas: coordenar as mudanas atravs de todo o projeto. Revisando todos os pedidos, aprovaes e controle das mudanas nas entregas e nos ativos de processos organizacionais (diretrizes, normas, procedimentos, polticas, processos definidos, informaes histricas, lies aprendidas). Processos de Encerramento:

27

Encerramento do Projeto: gerar, reunir e disseminar informaes para formalizar o trmino da fase ou do projeto, incluindo avaliaes do projeto e compilao das lies aprendidas para uso em planejamentos de futuros projetos ou fases.

28

Figura 7 - Viso geral gerenciamento de integrao

Fonte: PMBOK (2004)

29

4.3.2

Gerenciamento de Escopo O PMBOK 2004 descreve gerenciamento de escopo como processos envolvidos na

verificao de que o projeto inclui todo o trabalho necessrio e apenas o trabalho necessrio para que seja concludo com sucesso. Podemos entender escopo de uma maneira simples como o que ser feito tanto do trabalho quanto do produto. Um fato importante a diferenciao que deve ser estabelecida entre o projeto e o produto, Kerzner afirma que a maior parte dos ciclos de vida de produtos e projetos so similares, exceto por: o projeto tem ciclo de vida predefinido, j o produto enquanto for interessante para a organizao. Portanto podemos dizer que o escopo do projeto definido como o trabalho que precisa ser desenvolvido para garantir a entrega de um determinado produto dentro das especificaes e funes. J o escopo do produto so justamente as especificaes e funes. Esses dois escopos produto e projeto devem estar bem integrados para no haja problemas nos resultados. No escopo no pode haver nenhuma informao subentendida ou do tipo obvio, nada deve ser deixado de lado. Pois no escopo em que desejos, expectativas so transformadas em documento formal e no pode haver falhas nesse momento. Uma frase de um autor annimo exemplifica a dificuldade em montar o escopo Eu sei que voc acredita que entendeu o que voc pensa que eu disse, mas eu no estou certo de que voc compreendeu que o que voc ouviu no o que eu quis dizer. Quando se trata de mudanas pode existir sim vida aps as mudanas no escopo mas para tanto necessrio que seja muito bem definido junto ao cliente ou patrocinador um nico canal de comunicao para solicitaes. Definir uma pessoa, no caso o gerente de projetos como o responsvel para receber, avaliar os impactos, e tomar as medidas para a solicitao. Pois nem sempre o cliente tem noo que solicitaes fora do escopo influenciam nos resultados dos projetos, nos custos, no prazo e na qualidade. E sempre ter o bom senso de que quando a mudana pode comprometer o projeto devemos adi-las para projetos futuros.

30

Segundo Vargas (2005) podemos subdividir o escopo em: Escopo Funcional: Conjunto de caractersticas funcionais do produto, ou servio, a ser desenvolvido pelo projeto. Normalmente so direcionados ao cliente e so denominados requisitos funcionais; Escopo Tcnico: caractersticas tcnicas do projeto, destacando os padres e as Especificaes a serem utilizados, normas legais, ISO etc. Normalmente so direcionados para a equipe e comumente denominados requisitos tcnicos; Escopo de Atividades: trabalho a ser realizado para prover os escopos tcnicos e funcional do produto, ou servio, do projeto, normalmente evidenciado na EAP (Estrutura Analtica do Projeto). O escopo tambm dividido em processos conforme o PMBOK: Planejamento do Escopo: Garante que o esforo gasto nas atividades de determinao do escopo esteja de acordo com as exigncias do projeto, com relao complexidade, importncia e tamanho. Bem como, defini-se a fonte de dados, metodologia e os processos a serem utilizados. O nvel de detalhamento depende da complexidade do projeto. Definio do escopo: Documento muito importante, pois nele que esto descritos com detalhes o objetivo do projeto, cronograma e custo estimados. Neste documento detalhado o escopo preliminar do projeto e serve como guia durante todo o projeto. Criao da EAP: a estrutura analtica do projeto (EAP) tambm conhecida como WBS (Work Breakdown Structure) uma ferramenta no gerenciamento de escopo que decompe de forma hierrquica orientada entrega do trabalho a ser executado pela equipe do projeto. O detalhamento depende da complexidade normalmente indo at um pacote de trabalho. Verificao do Escopo: aceitao formal pelas partes interessadas do escopo do projeto terminado e entregas associadas. Controle do Escopo: garante que o trabalho que est sendo executado est definido no escopo bem como controlar as mudanas e estimar os impactos da mesma e garantir que essas mudanas sejam tratadas pelo controle integrado de mudana.

31

Figura 8 - Viso geral do gerenciamento de Escopo

Fonte: PMBOK (2004)

32

4.3.3 Gerenciamento de Tempo O principal objetivo dessa rea que o projeto seja entregue dentro do prazo determinado. uma definio simples, mas o importante lembrar que o tempo tem uma caracterstica nica chama inexorabilidade. Tempo no se recupera. Sabemos que se um projeto atrasa, normalmente ir consumir capital no previsto e claro se previsto ser das contingncias, comprometendo o custo e podendo causar srias conseqncias ao produto ou servio. Um velho paradigma do gerenciamento de projetos : Porque nenhum projeto consegue terminar no prazo?. Num estudo feito pelo Standish Group Internacional, avaliando projetos de TI, foi levantado que 88% dos projetos apresentam atrasos no cronograma. Como se trata de uma previso, dificilmente mesmo o mais experiente dos planejadores acertaro 100%. O que precisa ser feito tentar aumentar ao mximo o ndice de acertos e justamente nesse ponto que uma boa utilizao das ferramentas de gerenciamento de tempo pode ajudar. Segundo Cleveland (1999) quanto o maior o planejamento maior vai ser as chances de sucesso. O problema quando os cronogramas representam mais desejos e imposies de entregas do que efetivamente prazos reais para execuo das atividades. E claro com isso os projetos acabam atrasando e o cumprimento das atividades no prazo pode se tornar um insucesso. Um fato interessante e que dificilmente considerado nos planejamentos a disponibilidade do recurso para o projeto. Por motivos diversos, pessoais, fisiolgicos, podemos estimar que a produo real de um recurso gire em torno de 60% a 70%. Nos processos de gerenciamento de tempo segundo o PMBOK temos: Definio da atividade: identificao das atividades que precisam ser realizadas para produzir vrias entregas do projeto. Sequenciamento de atividades: Identificao e documentao das dependncias entre as atividades. Estimativas de recursos da atividade: Estimativa do tipo e quantidade de recursos necessrios para cada atividade.

33

Estimativa da durao das atividades: Estimativa do nmero de perodos de trabalho necessrio para que se concluam as atividades. Desenvolvimento do cronograma: Anlise de restries, recursos, durao e seqncias de atividades. Controle do cronograma: controle das mudanas do cronograma do projeto. Deve estar evidente que ao tratarmos de gerenciamento de tempo que nenhum cronograma perfeito, mas deve-se tentar chegar o mais prximo disso porque em parte o cronograma determina o oramento do projeto. O nvel de detalhamento do cronograma igual ao grau de complexidade do projeto. E claro sempre devemos estimar o tempo com o pior e melhor cenrio imaginado.

34

Figura 9 - Viso geral do gerenciamento de tempo

Fonte: PMBOK (2004)

35

4.3.4 Gerenciamento de Custos A definio de gerenciamento de custos to simples quanto a de tempo, nada mais do que fazer com que o projeto seja executado dentro do oramento aprovado para o mesmo. Projetos sempre enfrentam desafios financeiros e econmicos e nesse ponto que gerenciamento de custos entra, pois medida que o projeto anda os fundos orados e as despesas realizadas tem que ser controlados para no comprometer o sucesso do projeto.

Figura 10 - Gerenciamento de Custos

Fonte: PMBOK (2004)

O PMBOK subdivide o gerenciamento de custos em trs processos: Estimativa de custos: Desenvolvimento de uma estimativa de custos dos recursos para se concluir as atividades do projeto. Oramentao: Estabelece uma linha de base dos custos estimando valores das atividades individuais ou pacotes de trabalho. Controle de custos: Controla as mudanas no oramento de projeto e fatores que criam variaes nos custos.

36

Figura 11 - Viso geral do gerenciamento de custos

Fonte: PMBOK (2004)

4.3.5 Gerenciamento de Qualidade Primeiramente precisamos definir qualidade, segundo American Society for Quality (2000) qualidade o grau at o qual um conjunto de caractersticas inerentes satisfaz as necessidades. Crosby (1986) define a qualidade como o cumprimento dos requisitos, ou seja, entregar o que os clientes internos ou externos querem, necessitam, esperam.

37

Gerenciar qualidade nunca foi to importante, as empresas cada vez mais precisam de um diferencial, que seus produtos atendam as necessidades de clientes cada vez mais exigentes. Ferreira (1986) diz que a qualidade capaz de distinguir as coisas e lhes determinar a natureza. De fato a qualidade realmente diferencial, tanto para pessoas quanto para produtos. Mas o que no podemos nos enganar com o chamado Gold Plating ou algo a mais. Quando falamos em qualidade no podemos achar que acrescentar um bnus algo que no estava previsto no escopo ao cliente ter mais qualidade no servio. uma clara prtica de m gesto de projetos. Podemos exemplificar da seguinte forma: imaginamos que um cliente solicite um projeto e no escopo esteja especificado que o produto, um motor a vapor deva ter 90 cavalos de potncia. O gerente de projetos ao analisar os dados tcnicos viu que com o oramento previsto era possvel construir um motor de 130 cavalos e assim o fez. Colocou ento o projeto a perder, pois o motor no servia para o produto do cliente que estava configurado para 90 cavalos. O que no esta no escopo no deve ser feito medida que pode realmente comprometer o sucesso do projeto. Com todas essas colocaes o objetivo mais importante dessa rea garantir que a necessidades de todos os envolvidos sejam atendidas, garantindo assim a qualidade desejada. Segundo Vargas (2005) a qualidade envolve inmeras dimenses. Citando as seguintes: Defeito Zero: No existe tolerncia a erros dentro do sistema. A meta que, em todos os processos, no existam falhas e que o ambiente seja isento de erros. O cliente o prximo elemento do processo: Conceito baseado na necessidade de desenvolvimento de um sistema que seja capaz de garantir o produto ou servio seja transferido para o cliente de maneira correta, Faa correto da primeira vez: O processo de correo vrias vezes mais caro que o processo de planejamento, ou seja, meta do gerenciamento da qualidade garantir que cada ao do projeto seja desenvolvida corretamente da primeira vez. Melhoria continua: Conceito que reconhece que o mundo est em constante mutao e que a qualidade hoje pode no ser a de amanh.

38

Tabela 1 - Custo da conformidade x custo da no-conformidade

Custo da Conformidade Planejamento; Treinamento; Controle de processos; Testes; Auditoria de qualidade; Manuteno.
Fonte: Vargas (2005)

Custo da No-Conformidade Refugos; Retrabalho; Reparos na Garantia; Aes corretivas no produto; Atrasos no cronograma.

Segundo PMBOK os processos da qualidade so divididos em: Planejamento da qualidade: identificao dos padres de qualidades inerentes ao projeto e a determinao de como satisfaz-los. Realizar a garantia da qualidade: aplicao das atividades de qualidade planejadas e sistemticas para garantir que todos os processos foram empregados para atender aos requisitos. Realizar o controle de qualidade: monitorar os resultados e especficos do projeto e determinar se esto de acordo com os padres estabelecidos e eliminar as causas de desempenho insatisfatrio.

39

Figura 12 - Viso geral do gerenciamento da qualidade do projeto

Fonte: PMBOK (2004)

40

4.3.6 Gerenciamento de Recursos Humanos Segundo Vargas (2005) Gerenciamento de Recursos humanos tem como objetivo central fazer o melhor uso dos indivduos envolvidos no projeto. Em gerenciamento de projetos pessoas so o recurso mais importante. Todos os resultados dos projetos so frutos das relaes humanas e suas habilidades interpessoais. Gerenciar esse recurso o maior fator de sucesso para o alcance do objetivo proposto no projeto. Podemos usar o conceito de organizao vejamos: quando um grupo de pessoas se une para atingir um objetivo em comum chamamos esse agrupamento de organizao. O projeto nada mais do que uma organizao temporria que visa um produto ou servio nico. Em um modo simples podemos dizer que o gerenciamento de recursos humanos um meio de alinhar os objetivos e as expectativas das pessoas e da organizao. Devemos escolher no gerenciamento de recursos humanos como sero tratadas as pessoas. Sero recursos ou parceiros?. Como recursos, requerem um nvel maior de gerenciamento j como parceiro o desempenho tende a ser maior e com menos gerenciamento. Segundo Galbraith (1995) temos duas premissas que sustentam que o sucesso ou fracasso de um projeto dependem do gerenciamento de recursos humanos, so elas: 1 - Pessoas influenciam diretamente o sucesso e o fracasso do projeto; 2 - Os problemas do projeto somente podem ser resolvidos por pessoas. Temos ai um paradoxo onde pessoas so a causa e a soluo nos problemas em projetos. Sendo assim h necessidade de um forte planejamento na rea de recursos humanos para que o projeto transcorra da melhor forma possvel. Os processos do gerenciamento de recursos humanos so subdivididos conforme o PMBOK: Planejamento de recursos humanos: Identificao e documentao de funes, responsabilidades e relaes hierrquicas do projeto. Criao do plano de gerenciamento de pessoal; Contratar ou mobilizar a equipe do projeto: Obteno de recursos humanos para terminar o projeto;

41

Desenvolver a equipe do projeto: melhoria de competncias e interao de membros da equipe para aprimorar o desempenho do projeto; Gerenciar a equipe do projeto: acompanhamento do desempenho da equipe de projeto, fornecimento de feedback (retorno de informao) e aplicar melhorias e mudanas para melhorar o desempenho da equipe.

42

Figura 13 - Viso geral do Gerenciamento de Recursos Humanos

Fonte: PMBOK(2004)

43

4.3.7 Gerenciamento de Comunicao O Gerenciamento das comunicaes consiste na reunio de todos os elementos necessrios para a apropriada gerao, coleta, disseminao e armazenamento das informaes do projeto. Para termos um efetivo processo de comunicao a informao deve chegar s pessoas no tempo certo e de maneira economicamente vivel e claro de maneira clara e correta. Cleland (1999) define a comunicao como um processo pelo qual a informao transferida entre os indivduos atravs de smbolos, sinais e outros.

Figura 14 - Comunicao em duas vias

Fonte: Vargas (2005)

Existem responsabilidades inerentes ao emissor e receptor, so elas: Emissor: Responsvel por produzir uma informao clara, facilitando sua compreenso; Receptor: Responsvel por tornar claro que a informao foi recebida e completamente compreendida. Para se ter noo uma equipe com 20 pessoas formam 190 canais de comunicaes. Para chegar a esse valor usamos a formula (N * (N-1))/2 onde N o nmero de integrantes da equipe de projeto. Os processos do gerenciamento das comunicaes ficam divididos segundo PMBOK em: Planejamento das comunicaes: determinao das necessidades de informaes e comunicaes das partes interessadas no projeto;

44

Distribuio das informaes: disponibilizao das informaes as partes interessadas no momento adequado; Relatrio de desempenho: inclui relatrio de andamento, medio de progresso e previso. Cabe nesse momento coletar e distribuir essas informaes; Gerenciar partes interessadas: satisfazer os requisitos das partes interessadas no projeto (stakeholders) e resolver os problemas com elas.

45

Figura 15 - Viso geral do gerenciamento das comunicaes

Fonte: PMBOK (2004)

46

4.3.8 Gerenciamento de Riscos Segundo o PMBOK (2004) gerenciamento de riscos so processos que tratam da realizao de identificao, anlise, respostas, monitoramento, controle e planejamento dos riscos em um projeto. Risco vem da palavra em latim riscu ou risicu que significa ousar. Risco seria a chance de algo dar errado, mas em conceitos mais modernos envolve a qualificao e quantificao da incerteza tanto de ganhos quanto de perdas. Bernstein (1996) disse que riscos no precisam ser to temidos, administr-los tornou-se sinnimo de desafio e oportunidade. Como objetivo principal o PMBOK ressalta que gerenciamento de riscos do projeto visam aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto dos eventos adversos ao projeto entendendo dessa forma gerenciamento de riscos toma proporo muito maior. Todo o risco necessita ser avaliado sob a tica de dois aspectos: probabilidade de ocorrncia e gravidade das conseqncias. Se multiplicarmos a probabilidade por sua gravidade temos o conceito fundamental na anlise dos riscos denominado VALOR MONETRIO ESPERADO. O PMBOK subdivide o gerenciamento de riscos da seguinte forma: Planejamento do gerenciamento de riscos: deciso de como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto; Identificao de riscos: determinao dos riscos que podem afetar o projeto e documentao de suas caractersticas; Anlise qualitativa de riscos: priorizao dos riscos para anlise ou ao adicional subseqente atravs de avaliao e combinao de sua probabilidade de ocorrncia e impacto; Anlise quantitativa de riscos: anlise numrica do efeito dos riscos identificados nos objetivos gerais do projeto; Planejamento de respostas a riscos: desenvolvimento de opes e aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto.

47

Monitoramento e controle de riscos: acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificao dos novos riscos, execuo de planos de respostas a riscos e avaliao da sua eficcia durante todo o ciclo de vida do projeto.

Figura 16 - viso geral do gerenciamento de riscos

Fonte: PMBOK (2004)

48

4.3.9 Gerenciamento das Aquisies

Segundo Vargas (2005) objetivo do gerenciamento das aquisies dar garantia ao projeto de que todo elemento externo participante do projeto ir garantir o fornecimento de seu produto, ou servio, para o projeto. O gerenciamento de aquisies abrange processos relacionados a compras de mercadorias ou servios em fornecedores externos, contratados e distribuidores. A relao entre o fornecedor e projeto determinada usualmente pela quantidade de riscos incorporados pelas partes. Por causa desse fator de risco, muitas vezes o custo no o nico elemento a ser analisado na negociao. O tipo de contrato tambm passa a determinar papel fundamental. Vejamos alguns tipos de contratos segundo Vargas (2005): Contrato de preo fixo global: Esta modalidade de contrato envolve um preo fixo total para produtos bem definidos; Contrato de preo fixo global com incentivo: Tipo de contrato em que o comprador paga ao vendedor uma quantia fixa, e o vendedor poder ganhar uma quantia adicional se ele satisfazer os critrios estabelecidos de desempenho. Contratos de Custo (administrao) com incentivo sobre os resultados: essa modalidade engloba o pagamento (reembolso) para o vendedor de seus custos reais acrescidos de um prmio por economia, isto , quanto mais o fornecedor economizar, maior ser o bnus sobre o resultado, dentro de um limite mnimo e mximo de remunerao. Contratos de Custo (administrao) com prmios fixos: esta modalidade engloba o pagamento (reembolso) para o vendedor de seus custos reais acrescidos de um valor fixo adicional como forma de remunerao. Contratos por administrao: essa modalidade engloba o pagamento (reembolso) para o vendedor de seus custos reais acrescidos de um percentual desse custo como forma de remunerao. Contrato por preo unitrio: modalidade de contrato em que o vendedor recebe um montante por unidade de servio e o valor total do contrato est em funo das quantidades necessrias para concluir o trabalho.

49

Figura 17 - Tipos de Contratos e Riscos Associados

Fonte: Vargas (2005)

O PMBOK subdivide o gerenciamento de aquisies em seis processos: Planejar comprar e aquisies: determinao do que comprar e adquirir e de quando e como fazer isso. Planeja contrataes: documentao dos requisitos de produto, servios e resultados e identificao de possveis fornecedores. Solicitar respostas de fornecedores: obteno de informaes, cotaes, preos, ofertas e propostas, conforme adequado. Selecionar fornecedores: anlises de oferta, escolha entre possveis fornecedores e negociao de um contrato por escrito com cada fornecedor. Administrao de contratos: gerenciamento do contrato e da relao entre o comprador e o fornecedor, anlise e documentao do desempenho atual ou passado de um fornecedor a fim de estabelecer aes corretivas necessrias e fornecer uma base para futuras relaes com o fornecedor.

50

Figura 18 Viso geral do gerenciamento de aquisies

Fonte: PMBOK (2004)

51

APLICANDO GERENCIAMENTO DE PROJETOS

Neste captulo falaremos sobre a aplicao do modelo de gerenciamento na empresa Delsoft Sistemas bem como seus resultados obtidos. Primeiramente temos que ter bem claro que o PMBOK um guia de melhores prticas. Sendo assim dependendo do projeto podem ser usadas algumas tcnicas deixando fora outras. Quando uma empresa est utilizando uma tcnica no muito focada em resultados e a equipe passa a maior parte do tempo apagando fogo, adotar um guia de melhores prticas em gerenciamento de projetos para alguns pode soar como perda de tempo. A obteno da excelncia na gesto de projetos pode levar poucos anos ou algumas dcadas. A excelncia no ser alcanada sem mudanas, e a rapidez que estas ocorrem um fator fundamental. Primeiramente temos que enxugar e definir quais os processos se aplicam a empresa. Se temos 44 processos nem todos precisam ser aplicados. Por exemplo, se em um projeto no haver aquisies ento so seis processos a menos. Outra tcnica que usaremos suprimir processos, ou seja, juntamos alguns formando um nico. Em primeira linha temos que pensar em um gerenciamento com trs vertentes: fcil, prtico e direto. Por que seno o custo do gerenciamento no justifica o objeto gerenciado. Entretanto o que no justificvel no gerenciar e fazer as atividades empiricamente. Pois um grande problema composto de pequenos problemas, detalhes que fazem diferena.

5.1

TEMPLATES PARA GERENCIMENTO DE PROJETOS

Para definio de escopo utilizaremos modelos de documentos modificados para a realidade da Delsoft Sistemas onde teremos: Cabealho: ser informado no cabealho do projeto Nome do Projeto, Nome de quem preparou o documento e data do documento bem como sua verso.

52

Contatos: quadro com Nome, E-mail, Telefone e rea de todos os envolvidos no projeto. Forma de Comunicao: Quadro definindo qual forma de comunicao a ser utilizada. Descrio do Projeto: Descrio bsica do projeto. Objetivos: objetivos a serem alcanados com o projeto. Justificativa: o porqu da necessidade do projeto. Produto do Projeto: qual ser o produto ou servio do projeto. Expectativas do cliente/Patrocinador: Descrio do que esperado pelo cliente ou patrocinador Fatores de sucesso do projeto: Descrio de mtricas para sucesso do projeto Restries: Restries que podem causar insucesso do projeto Premissas: Fatores considerados verdadeiros para sucesso do projeto Limites do projeto e excluses especficas: Deixa claro quais pontos no esto nos objetivos do projeto. EAP (Estrutura analtica do projeto): Descrio das atividades/tarefas a serem executadas. O grau de exploso da EAP proporcional a complexidade do projeto. Como primeiramente sero projetos pequenos normalmente ser feita at terceiro nvel. Principais atividades e estratgias do projeto: Descrio de estratgias que sero usadas para o sucesso do projeto.

53

Principais entregas do projeto: Descrio sem datas, mas que sero utilizadas como marcos do projeto. Plano de entregas e marcos do projeto: Detalhamento com datas (otimista e final) separados por fases com nome de cada entrega. Riscos do projeto: Principais Riscos do projeto que podem causar insucesso do mesmo. Deve-se nesse momento aplicar pesos de aos riscos Probabilidade x Gravidade e aplicar em matriz para validar seu impacto. Para cada risco deve-se elencar as aes corretivas ou preventivas. Cronograma Baseado na EAP: Utilizando a EAP colocar as respectivas datas para que o projeto possa ser acompanhado. Controle de Mudanas: Como ser documentado e como ser feita as mudanas no projeto. Termo de encerramento e aceitao: Neste documento feito o encerramento e o aceite do projeto por parte do cliente. Lies aprendidas: Documento importante onde descrito as experincias aprendidas com o projeto melhoramento da aplicao da metodologia.

A estrutura da Delsoft formada por lideres e desenvolvedores. Os responsveis por desenvolver esse documento so justamente os lderes da rea, que so responsveis diretos pelo controle dos projetos.

54

5.2

RESULTADOS OBTIDOS

O modelo proposto foi aplicado em um projeto na Delsoft Sistemas e com excelentes resultados. O modelo segue no apndice A. Para preencher todo o documento levou-se cerca de quatro horas, entretanto para o projeto que tinha mais ou menos 128 horas a parte de planejamento correspondeu a 3% do total de horas. Com esse planejamento no houve problemas que em projetos sem a aplicao do modelo de gerenciamento tiveram tais como, escopo no definido consequentemente ocasionando retrabalho, projetos sem cronograma que acabaram atrasando, comunicao falha, faltas de acompanhamento e controle. No modelo proposto podemos ver a facilidade e a flexibilidade com que gerenciamento de projetos pode ser aplicado independente do tamanho do projeto. Basta adaptar as melhores prticas as necessidades.

55

6 CONCLUSES Gerenciamento de projetos est se tornando uma qualidade bastante desejada. Atuando na diminuio dos riscos bem como o aumento da qualidade o gerenciamento de projetos baseado no PMBOK vem provando a vantagem que se tem em utilizar essas melhores prticas. Sendo assim, esse trabalho conseguiu atingir seus objetivos criando uma forma flexvel e simples para gerenciar os projetos com resultados visveis. Tinha-se a preocupao de que projetos pequenos no compensariam ser gerenciados, mas com o decorrer dos estudos tanto de gerenciamento de projetos quando do prprio guia PMBOK verificou-se que todos os projetos podem e devem ser gerenciados. Se olharmos pela tica do desempenho, ainda faltaria a capacitao dos funcionrios chaves para entender a real importncia em gerenciar projetos. Mas da forma em que o modelo foi formado fica fcil at mesmo para algum que nunca gerenciou projetos executar tal funo. O grande erro pensar em gerenciamento de projetos como uma camisa de fora onde tudo deve ser aplicado em todos os projetos. Podemos notar que isso no verdadeiro. Cada projeto por suas caractersticas nicas e seus graus de complexidades distintos faz com que o modelo de gerenciamento tenha que ser adaptado. H necessidade de mudar a forma de pensar. Hoje, planeja-se muito pouco e executase muito mais em virtude de retrabalhos e falhas no previstas. As empresas trabalham de uma forma muito reativa e pouco ou quase nada preventiva. E esse pensamento que o gerenciamento de projetos tenta mudar. E fica claro que gerenciar no mais diferencial e sim cada vez mais uma necessidade. Realmente tenho total interesse em que esse novo modelo consiga ser implantado na Delsoft Sistemas e que os resultados sejam os mais positivos e que como em outras empresas a cultura seja a de gerenciar projetos com sucesso.

56

RECOMENDAES

Dada a delimitao do estudo, no foram explorados outros possveis temas de pesquisa relacionados gesto de projetos, que podem dar continuidade e complementaridade ao estudo realizado, sugerindo-se para trabalhos futuros Gesto de portiflio; Implantao de um escritrio de projetos; Gesto de programas; Liderana e desenvolvimento de equipes de projetos.

57

REFERNCIAS

A Guide to the Project Management Body of Knowledge. 3. ed. Newton Square: Project Management Institute, 2004. BERNSTEIN, Peter. The New Religion of Risk Management. Boston: Harvard Business Review. 1996. CLELAND, David. Project Management: Strategic Design and Implementation. New York: McGraw-Hill, 1999.
CROSBY, Phipip B. Qualidade sem Lgrimas. 3.ed. Rio de Janeiro: Olympio, 1994.

DAHIS, Abrao. Disponvel em http://pontogp.wordpress.com/2007/09/27/a-gerencia-intuitiva/ acesso em 01 novembro 2008.

FERREIRA, A. B. H. Novo dicionrio da lingua portuguesa. 2.ed. Rio de Janeiro: Nova Fronteira, 1986.

PRADO, Darci. Administrao de projetos com PERT/CPM. Editora UFMG. 2 Edio. Belo Horizonte, 1988. GALBRAITH, Jay R. Designing Organizations: An Executive Briefing on Strategy. Structure and Process. San Francisco: Jossey-Bass Publishers, 1995. KERZNER, Harold. Gesto de projetos: as melhores prticas. 2. ed. Porto Alegre: Bookman, 2006 MEREDITH, Jack R. Project Management: A Managerial approach. New York: John Wiley and Sons, 1995. Standish Group International, Inc., The. 2001. Extreme Chaos. Disponvel em: www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf acessado em novembro de 2008. VARGAS, Ricardo Viana. Gerenciamento de projetos, estabelecendo diferenciais competitivos. Rio de Janeiro: Brasport, 2005 XAVIER, Carlos Magno da Silva. Metodologia de gerenciamento de projetos. Rio de Janeiro: Brasport, 2005.

58

APNDICE A

PROJETO VARIAO CAMBIAL

DECLARAO DE ESCOPO PRELIMINAR DO PROJETO Preparado por: Juliano Vicente Verso: 1.1 Data: 18/03/2008

1. Contatos Nome E-MAIL: fhelfenstein@delsoftsistemas.com.br FONE: (47) 9994-7864 Juliano Vicente MSN: julianocjmrsl@hotmail.com E-MAIL: jvicente@delsoftsistemas.com.br FONE: (47) 9991-7824 Christian Buzatta MSN: clbuzatta@hotmail.com E-MAIL: cbuzatta@delsoftsistemas.com.br Ana Cludia Garcia MSN: anangarcia@hotmail.com E-MAIL: agarcia@delsoftsistemas.com.br 2. Forma de comunicao no projeto Dever ser usado e-mail como forma de comunicao padro. Consultora Consultor Desenvolvedor E-mail/Telefone rea Lder da rea Financeira

Fernando Helfenstein MSN: fjh_rsl@hotmail.com

59

3. Descrio do projeto O projeto envolve toda a anlise e desenvolvimento do novo clculo da variao cambial, preparando o sistema financeiro para a funcionalidade de exportao tratando moeda estrangeira ou moeda de negcio dependendo da necessidade. 4. Objetivo do projeto Alterar as rotinas j existentes no ERP delsoft, para o novo clculo da variao cambial, analisando os pontos que necessitam de alterao sem comprometer os processos j existentes no CONTAS A RECEBER. 5. Justificativa do projeto Necessrio para que o mdulo de exportao seja integrado perfeitamente com o mdulo financeiro. 6. Produto do projeto Mdulo Financeiro integrado com mdulo de exportao bem como todas as funcionalidades da Moeda estrangeira, implementadas e homologadas. 7. Expectativa do cliente/patrocinador Projeto entregue dentro do prazo e homologado; Projeto em conformidade com os objetivos descritos. 8. Fatores de sucesso do projeto Comunicao efetiva dentro dos envolvidos no projeto; Comprometimento dos setores envolvidos. 9. Restries O tempo limitado; Envolvidos no estarem dedicados somente a este projeto. 10. Premissas

60

Haver o apoio de todos os envolvidos no projeto; Dedicao Integral do desenvolvedor no projeto; Os integrantes faro a comunicao via e-mail, listados no item 1.

11. Limites do projeto e excluses especficas O projeto no tem como objetivo homologar o mdulo de exportao; No tem como objetivo inicial implantar o processo no CONTAS A PAGAR em virtude do prazo e das necessidades iniciais do cliente.

12. EAP preliminar (3 nveis) 1 Projeto Variao Cambial 1.1 1.2 Iniciao do projeto Planejamento das atividades 1.2.1 1.2.2 1.2.3 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 1.4 1.5 1.4.1 1.5.1 1.5.2 Levantamento de requisitos Cronograma do desenvolvimento Aceitao do escopo Desenvolvimento das rotinas (Programao) Testes locais Desenvolvimento da documentao Testes com consultores Correes e melhorias Homologao no cliente Aceite do cliente Documentao das lies aprendidas

Execuo das atividades

Implantao no cliente Encerramento do projeto

13. Principais atividades e estratgias do projeto

61

1. Iniciao do projeto 1. Ser desenvolvida por todos os envolvidos no projeto. 2. Descrio detalhada das necessidades do cliente. 2. Planejamento das atividades 3. -Que servios o sistema tem que fornecer? -Qual o desempenho exigido pelo sistema? -Quais as regras de negcio (Com deve ser a forma de Clculo da variao cambial, como contabilizar as Variaes ms a ms e na Baixa) Desenvolver o cronograma para melhor controle do projeto, bem como datas X entrega do desenvolvimento e testes contnuos durante o decorrer do projeto Descrio do escopo e aceitao junto aos consultores. 14. Principais entregas do projeto Aceitao do escopo; Desenvolvimento das rotinas e testes locais; Testes dos consultores; Correes e melhorias; Homologao no cliente. 15. Plano de entregas e marcos do projeto A execuo dos trabalhos iniciar em 16 de Abril de 2008 e deve durar em torno de 4 semanas. Entrega Descrio Trmino Otimista 25/03/2008 25/03/2008 26/03/2008 26/03/2008 25/04/2008 25/04/2008 Trmino 25/03/2008 25/03/2008 26/03/2008 26/03/2008 30/04/2008 30/04/2008

Fase de iniciao Levantamento Inicial Escopo definido Fase planejamento Fase execuo de Declarao do escopo aprovada Cronograma definido de Desenvolvimento das rotinas Testes locais

62

Correes, melhorias e documentao Testes com consultores Correes e melhorias

28/04/2008 05/05/2008 07/05/2008

05/05/2008 09/05/2008 11/05/2008

Testes finais com consultores

12/05/2008

16/05/2008

16. Riscos iniciais do projeto 1 - Pouca disponibilidade de tempo dos membros da equipe; 2 - Falta de Comprometimento; 3 - Realocao do Desenvolvedor em outras atividades; Pesos de 1 a 9 Risco 1 Probabilidade = 3 Risco 1 Impacto = 7 Nvel = Mdio Ao/Preveno: estudar cronograma e aprovar com todos os evolvidos. Risco 2 Probabilidade = 2 Risco 2 Impacto = 4 Nvel = baixo Ao/Preveno: Conversar com todos os envolvidos e envolver diretoria. Risco 3 Probabilidade = 5 Risco 3 Impacto = 9 Nvel = Alto Ao/Preveno: Analisar projetos concorrentes, envolver se preciso diretoria.

63

17. Cronograma do projeto Vide item 15

18. Controle de Mudanas As mudanas devero ser encaminhadas por e-mail. Estas sero analisadas, documentadas e anexadas ao projeto; As mudanas sero divididas em: Simples, O lder ter total autonomia para execut-las; Complexa, O lder obrigatoriamente dever envolver o cliente para executar a mesma. 19. Lies aprendidas Neste projeto, vimos como foi importante passar este documento para todos os envolvidos deixando todos inteirados e assim comprometidos; necessrio avaliar a forma de comunicao por telefone que foi usada e no funcionou por no haver registro da informao passada;

64

20. Encerramento e Aceite Para encerramento e o aceite necessita assinatura do cliente junto ao consultor em papel timbrado.