TCC - MBA em Gestão de Projetos - PMI da Faculdade IBTA

28.987 visualizações

Publicada em

0 comentários
9 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
28.987
No SlideShare
0
A partir de incorporações
0
Número de incorporações
13
Ações
Compartilhamentos
0
Downloads
840
Comentários
0
Gostaram
9
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

TCC - MBA em Gestão de Projetos - PMI da Faculdade IBTA

  1. 1. FACULDADES IBTA Leonardo Melo de LIMAGERENCIANDO UM PROJETO DE CONSTRUÇÃO DE UMA MONTANHA RUSSA SÃO JOSÉ DOS CAMPOS 2013
  2. 2. Leonardo Melo de LIMAGERENCIANDO UM PROJETO DE CONSTRUÇÃO DE UMA MONTANHA RUSSA Monografia apresentada à FACULDADES IBTA para a conclusão do curso MBA em Gestão de Projetos - PMI. Orientadores: Prof. John DALE e Prof. Dr. Eduardo Madeira BORGES SÃO JOSÉ DOS CAMPOS 2013
  3. 3. FICHA CATALOGRÁFICALIMA, Leonardo Melo Gerenciando um Projeto de Construção de uma Montanha Russa / Leonardo Melo deLima. São José dos Campos, FACULDADES IBTA, 2013. XIII, 26 p., il. Orientadores: John DALE e Eduardo Madeira BORGES Monografia - Trabalho de Conclusão do Curso MBA em Gestão de Projetos – PMI,FACULDADES IBTA, 2013. 1. Projeto; 2. PMBoK; 3. Decisão; 4.Montanha Russa. Tese.I. DALE, John . II BORGES, Eduardo Madeira. III. FACULDADES IBTA. Curso MBA emGestão de Projetos - PMI. IV. Título.
  4. 4. Leonardo Melo de LIMA GERENCIANDO UM PROJETO DE CONSTRUÇÃO DE UMA MONTANHA RUSSA Monografia apresentada a FACULDADES IBTA para a conclusão do curso MBA em Gestão de Projetos - PMIAprovado em 21/02/2013 BANCA EXAMINADORA ________________________________________________________ Prof. John DALE FACULDADES IBTA _________________________________________________________ Prof. Dr. Eduardo Madeira BORGES Instituto de Estudos Avançados FACULDADES IBTA __________________________________________________________ Prof. MsC. Sergio Amélio Ribeiro CINTRA FACULDADES IBTA
  5. 5. Dedico este trabalho primeiramente a Deus, poisele é o meu guia, sustentador e consolador emtodos os momentos de dificuldade. Toda honra eglória seja dada a ele.Dedico também a minha família que estevecomigo em todos os momentos.
  6. 6. AGRADECIMENTOSAgradeço a Deus por ter me dado condições de concluir este curso. Toda glória e honra sejadada ao meu Deus. Não poderia deixar de citar também minha querida esposa que se manteveao meu lado em todos os momentos dessa jornada, me dando total apoio e incentivo. Ao meufilho que muitas vezes não pude dar o tempo necessário a ele por conta de alguma atividade,meus pais que sempre me apoiaram, e aos professores que deram todo o suporte para que euchegasse até aqui.
  7. 7. “O planejamento não é uma tentativa depredizer o que vai acontecer. O planejamento éum instrumento para raciocinar agora, sobreque trabalhos e ações serão necessários hoje,para merecermos um futuro. O produto final doplanejamento não é a informação: é sempre otrabalho.” Peter Drucker
  8. 8. RESUMOO objetivo deste documento é mostrar o gerenciamento de um projeto de uma inovadoraMontanha Russa, utilizando os conceitos do PMBoK[1], focando em três específicas áreas deconhecimento: Escopo, Qualidade e Risco. São apresentados análises das tomadas de decisõesdurante o projeto bem como as lições aprendidas.Palavras-chave: Projeto; PMBoK; Decisão; Montanha Russa
  9. 9. ABSTRACTThe purpose of this document is to show the management of a project of an innovative RollerCoaster, using the concepts of PMBoK[1], focusing on three specific knowledge areas: Scope,Quality and Risk. We present analyzes of the decisions taken during the project as well aslessons learned.Key words: Project; PMBok; Decision; Roller Coaster;
  10. 10. LISTA DE FIGURASFigura 1 - Problema na Perspectiva dos Stakeholders .................................................................. 6Figura 2 - Importantes Subprojetos ............................................................................................... 7Figura 3 - Diagrama de Redes ....................................................................................................... 8Figura 4 - Montanha Russa Patenteada por Thompson ................................................................. 9Figura 5 - Situação Inicial do Projeto – EAP .............................................................................. 10Figura 6 - Evolução de Receita/Custo ......................................................................................... 20Figura 7 - Evolução de Qualidade e Tecnologia ......................................................................... 21Figura 8 - Evolução do Lucro ...................................................................................................... 21Figura 9 - Evolução do Prazo ...................................................................................................... 22Figura 10 - EAP com Caminho Crítico e Valores Finais ............................................................ 22Figura 11 - Comparativo Final .................................................................................................... 23
  11. 11. LISTA DE TABELASTabela 1- Situação Inicial do Projeto .......................................................................................... 10Tabela 2- Relação das Áreas de Conhecimento com Fases do Projeto ....................................... 13Tabela 3 - Relação entre as Decisões, Processos e Ferramental ................................................. 15
  12. 12. LISTA DE ABREVIATURAS E SIGLASEAP – Estrutura Analítica do Projeto.PMI - Project Management Institute.PMBoK - Project Management Body of Knowledge.
  13. 13. SUMÁRIO1. INTRODUÇÃO ................................................................................................................... 11.1 Objetivo ................................................................................................................................... 21.2 Estrutura do Trabalho .............................................................................................................. 22. FUNDAMENTAÇÃO DE GERENCIAMENTO DE PROJETOS ................................ 32.1 O que é o PMBoK?.................................................................................................................. 32.2 O que é Gerenciamento de Projetos? ....................................................................................... 42.3 O que é um Gerente de Projetos? ............................................................................................ 42.4O que é PMI? ............................................................................................................................ 43. COMEÇANDO O PROJETO ............................................................................................ 53.1 Como foi Criado o Projeto? ..................................................................................................... 53.2 TOPSIM .................................................................................................................................. 53.3 A Empresa Hypermax Inc ....................................................................................................... 63.4Premissas do Projeto................................................................................................................. 84. HISTÓRIA DA MONTANHA RUSSA ............................................................................. 95. APRESENTAÇÃO DOS DADOS INICIAIS .................................................................. 106. ESTRATÉGIA DO GRUPO ............................................................................................ 117. ÁREAS DE CONHECIMENTO – PMBOK ................................................................... 118. ANÁLISE DOS PACOTES ESCOLHIDOS ................................................................... 148.1 Especificação do Software (Pacote 9) ................................................................................... 168.2 Desenvolvimento do Software (Pacote 14) ........................................................................... 178.3 Teste do Software (Pacote 21) ............................................................................................... 189. RESULTADOS DO PROJETO, VIABILIDADE E LIÇÕES APRENDIDAS. .......... 209.1 Viabilidade ............................................................................................................................ 239.2 Lições Aprendidas ................................................................................................................. 2410. CONCLUSÃO................................................................................................................ 25 REFERÊNCIAS ............................................................................................................ 26
  14. 14. 11. INTRODUÇÃO Atualmente as instituições estão cada vez mais preocupadas com os custos elucros de todas as estruturas organizacionais. A procura pela redução dos custos e buscapor resultados que agregam valor é obrigatório para que uma empresa possa sobreviverem um ambiente globalizado e com forte concorrência. Com a disputa cada vez mais acirrada, novos produtos, campanhas de marketing,modificar processos internos, inovações no relacionamento com os clientes se tornammuito necessário. E para a realização de tudo isso e muitas outras coisas, as empresasprecisam de projetos. O desenvolvimento de novos produtos com o auxílio do gerenciamento deprojetos, tem conquistado ótimos resultados, e profissionais com este tipo dequalificação cada vez mais requisitados e valorizados. A principal organização direcionada para as práticas de gerenciamento de projetoé o Project Manager Institute (PMI), que através da experiência de renomadosprofissionais da área de gestão de projetos criou um guia de melhores práticasconhecido como Project Management Body of Knowledge – PMBoK[1]. Este trabalho mostra como utilizar o PMBoK[1] no gerenciamento de um projeto.O projeto trata-se de um simulador de uma montanha russa denominada RockStar.Os resultados serão mostrados neste documento assim como as práticas adotadas aolongo do projeto.
  15. 15. 21.1 Objetivo O objetivo deste trabalho é apresentar as experiências obtidas durante odesenvolvimento do projeto da montanha russa RockStar, focando em três áreas deconhecimento definidas através do PMBoK[1]. As áreas de conhecimento são: Escopo,Qualidade e Risco. Três pacotes de trabalho deste projeto serão apresentados. Os pacotes sãoreferente ao software da montanha russa: Especificação do Software, Desenvolvimentodo Software e Teste do Software.1.2 Estrutura do Trabalho O Capítulo 2 apresenta os conceitos sobre Gerenciamento de Projetos e as áreasde conhecimento escolhidas de acordo com o PMBoK[1].No Capítulo 3 é apresentada uma visão geral sobre o simulador que foi utilizado pararealizar esse trabalho, também no capítulo 3 é possível ver quais são as premissas doprojeto. O Capítulo seguinte conta a história do surgimento da montanha russa, comocomeçou, onde, sua modificações, até os dias de hoje.No Capítulo 5 são apresentados os valores iniciais do projeto antes. O Capítulo 6 mostraqual foi estratégia adotada para o projeto . No Capítulo 7 é feita uma pequena apresentação das áreas de conhecimento queforam escolhidas para este trabalho, O oitavo detalha os acontecimentos em três pacotesde trabalhos do projeto sobre a ótica das três áreas de conhecimento: Escopo, Qualidadee Risco. No Capitulo seguinte são mostrados os resultados do projeto assim como a suaviabilidade e o último capítulo traz a conclusão do trabalho com alguns detalhes doprojeto e finalizando com a utilização do PMBoK[1] no Gerenciamento de Projetos.
  16. 16. 32. FUNDAMENTAÇÃO DE GERENCIAMENTO DE PROJETOS2.1 O que é o PMBoK? O PMBoK[1] é um manual que contém um agrupamento de conhecimentos e boaspráticas do gerenciamento de projetos, atualmente encontra-se na quarta edição, e é mantidopela instituição Project Management Institute (PMI), Entende-se como boas práticas um conjunto de métodos que tiveram sucesso em outrosgrandes projetos com resultados favoráveis, porém, poderá acontecer que um desses métodosnão seja utilizável em alguns projetos. O PMBoK[1] fornece 42 processos agrupados em cinco grupos de processos e noveáreas de conhecimento, o grupo de processos e as áreas de conhecimento são mostrados logoabaixo. Grupo de Processos Iniciação Planejamento Execução Monitoramento e Controle Encerramento Áreas de Conhecimento Escopo Tempo Custo Qualidade RH Comunicações Riscos Aquisições Integração
  17. 17. 42.2 O que é Gerenciamento de Projetos? De acordo com o PMBoK[1] o gerenciamento de projetos é uma aplicação deconhecimento, ferramentas, habilidades e técnicas às atividades do projeto a fim de atenderaos seus requisitos. Não é obrigatório, porém recomendável que um Gerente de Projetos tenhaconhecimento na área no qual esta gerenciando, por exemplo: Arquiteto trabalhando em umprojeto de construção de um imóvel ou Analista de Sistemas trabalhando em um projeto deconstrução de um software, mas como foi dito anteriormente, não há nenhuma regra queobrigue um Gerente de Projetos a não atuar em alguma determinada área.2.3 O que é um Gerente de Projetos? De acordo com o PMBok[1] o gerenciamento de projetos é uma aplicação deconhecimento, ferramentas, habilidades e técnicas às atividades do projeto a fim de atenderaos seus requisitos. Não é obrigatório, porém recomendável que um Gerente de Projetos tenhaconhecimento na área no qual esta gerenciando, por exemplo: Arquiteto trabalhando em umprojeto de construção de um imóvel ou Analista de Sistemas trabalhando em um projeto deconstrução de um software, mas como foi dito anteriormente, não há nenhuma regra queobrigue um Gerente de Projetos a não atuar em alguma determinada área. Segundo Vargas[2], o gerenciamento de projetos pode ser aplicado a qualquer situaçãoonde exista empreendimento que foge ao que é fixo e rotineiro na empresa.2.4 O que é PMI? PMI (Project Management Institute), é a maior instituição sem fins lucrativos quecolabora com a criação de padrões para o gerenciamento de projetos reunindo-os em seu guiaPMBok[1] mundialmente conhecido, assim como capacitar os profissionais e organizações daárea de gerenciamento de projetos.
  18. 18. 53. COMEÇANDO O PROJETO3.1 Como foi Criado o Projeto? Este projeto foi desenvolvido na disciplina de Business Game do curso de MBA emGestão de Projetos PMI da faculdade IBTA. A finalidade do Business Game é exemplificar aos alunos como é um ambiente deprojeto real desde a fase de iniciação até a fase de encerramento, aplicando os conhecimentosadquirido em todas as disciplinas já cursadas, fazendo uso das boas práticas de gestão deprojetos segundo o PMBoK[1].3.2 TOPSIM Servindo como base para a realização desse projeto, foi utilizado uma ferramentadenominada TOPSIM.É um software criado pela empresa alemã Tata[3] Systems e sua finalidade é simular arealização do projeto com base nas boas práticas do PMBoK[1]. O objetivo do TOPSIM étornar real um projeto, proporcionando algumas experiências como: Realidade de uma empresa. Conhecimento em administração. Deparar-se com riscos e dúvidas. Trabalho em equipe Situações adversas Responsabilidades de um Gerente de Projetos. O TOPSIM também fornece algumas ferramentas utilizadas diariamente por umGerente de Projetos como: Relatório de Custo. Demonstração do caminho crítico. Projeção dos pacotes de trabalho e suas dependências.
  19. 19. 63.3 A Empresa Hypermax Inc A empresa Hypermax Inc é uma empresa que constrói maquinas mecânicas, e uma desuas especialidades é a construção de Montanhas Russas. É Composta aproximadamente por 1000 (um mil) colaboradores, e no último anoobteve um lucro de 280 milhões de Euros, porém atualmente passa por problemas financeirose teve uma queda em suas receitas. Os objetivos deste projeto são: Entregar a Montanha Russa denominada HyperCoaster no prazo estimado. Conquistar e se possível aumentar os níveis de Qualidade e Tecnologia. Evitar penalidades descritas no contrato. Stakeholders são pessoas que fazem parte direta ou indiretamente de um projeto. Podemter interesses ou não em sua realização. Neste projeto alguns stakeholders se mostraramcontrários a sua criação como ilustra a Figura 1. Figura 1 - Problema na Perspectiva dos Stakeholders
  20. 20. 7 Além do que apresenta a Figura 1, existem alguns pontos a serem destacados diante doprojeto da Hipermax Inc que são: Clientes Insatisfeitos. Frequentes mudanças que geram aumento de custo. Nenhum setor da empresa quer assumir o projeto. Alguns pontos no contrato do cliente não são claros. As datas de entrega não são cumpridas. Para amenizar esses problemas ficou acordado que o Gerente de Projetos terá seu papelreforçado, e que o próximo projeto servirá como piloto para o novo sistema. Também foram traçadas algumas metas: Ser rentável para garantir a sobrevivência da empresa. Alto nível de satisfação do cliente. Tecnologia de ponta. O Projeto piloto da montanha russa ficou dividido em alguns importantes subprojetos,como ilustrado na Figura 2 Figura 2 - Importantes Subprojetos
  21. 21. 8A Figura 3 mostra os subprojetos divididos em pacotes de trabalho. Figura 3 - Diagrama de Redes3.4 Premissas do Projeto Deve-se cumprir algumas premissas para que o projeto seja realizado de acordo com oescopo definido. Estas premissas são: O projeto deve ter no máximo 65 semanas. O valor do projeto não deve ultrapassar 10 milhões de Euros. Pontos de Tecnologia e Qualidade maiores ou iguais a 100. Vida útil do equipamento em 25 anos ou 2 milhões de corridas. Comprimento do caminho percorrido 1000 m com altura máxima faixa de 50 m. A velocidade máxima dever ser 130 km/h. 3 carrinhos na montanha-russa e 36 passageiros por carro. Importante que o passeio ocorra de forma suave. A área do parque é plana e o solo muito macio. Sistema de Som 4D 22 alto falantes a bordo por carro e 200 caixas ao longo do percurso.
  22. 22. 94. HISTÓRIA DA MONTANHA RUSSA Segundo FERRAZ[4], a montanha russa existe desde o século XVI onde pessoasbrincavam de escorregar no gelo formado em cima de montanhas na Russia, daí vem o nomede Montanha Russa. A brincadeira fez tanto sucesso, que foi sendo aprimorada comtecnologia até se tornarem populares em todo o mundo. Existem Montanhas Russas capazesde chegar a mais de 200Km/h em uma altura de mais de 130 metros. Não há nenhum relato de quando foram colocadas as rodas nos carrinhos, mas algunshistoriadores creditam aos franceses os primeiros carrinhos com rodas em 1804, tambémforam os inventores da montanha russa com looping no “Frascati Gardens" Paris em 1846. Alguns anos depois um homem chamado La Marcus Adna Thompson construiu aprimeira montanha russa fabricada no continente americano. Cada visitante pagava um níquelpelo passeio a 9,6 km/h num percurso de cerca de 200 metros de extensão e 16,5 de alturacom algumas pequenas colinas no meio. O negócio foi lucrativo a Thompsom que acabou entrando de vez no negócio dosparques de diversão onde começou a ser chamados por muitos de “O pai da gravidade”. A indústria continuou prospera. Anton Schwarzkopf foi o homem que mais projetoumontanhas russas na história. Encontra-se exemplos da sua arte em quase todos os países domundo. Ele morreu em julho de 2001. Muitos outros vieram e se interessaram pelo negócio que enxergaram ser promissor. Atualmente existem montanhas russas em que as pessoas vão sentadas, de pé, deitadasem posição de vôo, girando, sem chão e de costas. Existe montanha russas lançada, reversa,gigante. A Figura 4 apresenta a montanha russa patenteada por Thompson. Figura 4 - Montanha Russa Patenteada por Thompson
  23. 23. 105. APRESENTAÇÃO DOS DADOS INICIAIS A situação com os valores que iniciaram o projeto esta representada conforme mostraa Tabela 1 e a Figura 5 respectivamente. Tabela 1- Situação Inicial do Projeto Duração: 73 semanas Custo: 8.525,00 Euros Tecnologia: 100 Qualidade: 100 Receita: 8.050,00 Euros Lucro: -475,00 Euros Figura 5 - Situação Inicial do Projeto – EAP
  24. 24. 116. ESTRATÉGIA DO GRUPO De acordo com os objetivos do projeto, seguindo suas premissas, o grupo teve quetomar algumas decisões para priorizar alguns pontos estratégicos. Como era premissa do projeto, um alto nível de qualidade e tecnologia somando-se aofato de não extrapolar o custo máximo de 10 milhões de Euros e 65 semanas de duração, ogrupo decidiu por: Sempre que possível optar por diminuir o prazo. Ganhar pontos de qualidade e tecnologia. Não permitir um aumento considerável no custo. Ou seja, a ideia era nivelar todas essas opções para que no final o projeto cumprissecom as expectativas.Porém até semana 40, o prazo ainda estava bem maior do que foi estipulado por conta dealguns distúrbios que ocorreram no decorrer do projeto até aquela semana. Em razão disso, o grupo decidiu mudar a estratégia e começou a priorizar o prazo nointuito de concluir o projeto no tempo estimado.7. ÁREAS DE CONHECIMENTO – PMBOK No Capítulo 2 foi comentado que o PMBoK[1] possui 9 áreas de conhecimento. Nestetrabalho será mostrado apenas 3 delas, que são: Escopo: No PMBoK[1] edição 4, Capítulo 5, o Gerenciamento do Escopo do projeto inclui os processos necessários para garantir que o projeto inclua todo o trabalho necessário, e somente ele, para terminar o projeto com sucesso. Coleta dos dados necessários com os stakeholders para atingir o objetivo do projeto, definir o escopo e desenvolvendo uma descrição detalhada do projeto e do produto, criação da EAP (Estrutura Analítica do Projeto), que é o processo que divide as entregas do projeto em partes menores e mais fáceis de gerenciá-las, verificar o escopo formalizando a aceitação das entregas terminadas do projeto e controlar o escopo que monitora o progresso do escopo e gerencia as mudanças feitas na linha de base do escopo.
  25. 25. 12 Qualidade: O PMBoK[1] no capítulo 8, descreve o Gerenciamento de Qualidade como políticas e procedimentos com atividades de melhoria contínua de processos realizadas durante todo o projeto, conforme apropriado. O Gerenciamento de Qualidade tem como objetivo planejar a qualidade identificando os requisitos de qualidade e a documentação dos mesmos, realizar a garantia da qualidade por meio de auditorias e medições nos requisitos de qualidade e por fim realizar o controle da qualidade no qual através do monitoramento dos resultados as atividades são avaliadas a fim de caso necessário, haja uma recomendação para mudanças necessárias. Riscos: De acordo com o guia PMBok[1] edição 4 capítulo 11, o Gerenciamento de Riscos inclui processos de planejamento, identificação, análise, planejamento de respostas, monitoramento e controle de riscos de um projeto, no qual seu objetivo é aumentar a probabilidade e o impacto dos eventos positivos e reduzir a probabilidade e o impacto dos eventos negativos de um projeto. Faz parte do gerenciamento de riscos, planejar o gerenciamento de riscos, onde são definidas as formas de como conduzir as atividades de gerenciamento de riscos, identificar os riscos onde são determinados os riscos que podem afetar o projeto, realizar a análise quantitativa dos riscos onde é feita uma análise numérica do efeito dos riscos identificados, planejar as respostas aos riscos que desenvolve ações para reduzir as ameaças aos objetivos e por fim, monitorar e controlar os riscos onde é implantado planos de respostas aos riscos, identificação de novos riscos e tratamento dos riscos durante todo o projeto. A seguir Tabela 2 ilustra a relação destas áreas de conhecimento com as fases doprojeto.
  26. 26. 13 Tabela 2- Relação das Áreas de Conhecimento com Fases do Projeto Áreas de ConhecimentoFases do Projeto Escopo Qualidade Risco Iniciação - - - Planejar o Coletar Requisitos Planejar a Qualidade Gerenciamento de Risco Definir Escopo - Identificar os Riscos Realizar Análise Planejamento Criar EAP - Qualitativa dos Riscos Realizar Análise - - Quantitativa dos Riscos Planejar as Respostas - - aos Riscos Realizar a Garantia - - da Qualidade Execução - - - - - -Monitoramento e Verificação do Realizar o Controle Monitorar e Controle Escopo de Qualidade Controlar os Riscos Controle do Escopo Encerramento - - -
  27. 27. 148. ANÁLISE DOS PACOTES ESCOLHIDOS O projeto possuí 46 pacotes de trabalho agrupados nos subsistemas no qual já foimencionado. Para esta análise foram escolhidos 3 pacotes. São esses: Especificação do Software (Pacote 9). Desenvolvimento do Software (Pacote 14). Teste de Software (Pacote 21). Estes pacotes são sequenciais ou seja, para que um comece a ser desenvolvido, énecessário a conclusão do anterior. Os três pacotes fazem parte do subprojeto Software. A Tabela 3 apresenta as decisões tomadas em cada pacote escolhido, também mostraos processos contidos no PMBoK[1] nas três áreas de conhecimento selecionadas para estetrabalho e as ações utilizadas em cada processo para que o objetivo fosse cumprido. Asferramentas adotadas foram as mesmas para os três pacotes. Cada pacote possui 4 alternativas, sendo que a primeira é a alternativa padrão, ou seja opacote mantem a opção que se encontra, e outras três opções diferentes. Nos próximos itens serão apresentados os motivos no qual o grupo se baseou para atomada de decisão.
  28. 28. 15 Tabela 3 - Relação entre as Decisões, Processos e Ferramental Decisões Tomadas Processos Ferramental Coletar Requisitos Entrevistas com usuários Definir Escopo Termo de Abertura doPacote 9 – Integrar módulos subprojeto comque já foram utilizados em documentação dos requisitosoutros projetos. Criar a EAP Decomposição hierárquica Verificar Escopo Inspeções Controlar Escopo Análise de Variação. Planejar a Qualidade Fluxogramas e análise de custo benefício. Realizar a Garantia da Auditorias de Qualidade e Qualidade Análise de processos Realizar o Controle da Inspeções e Gráficos dePacote 14 – Contratar Qualidade Controledesenvolvedores experientes Planejar Gerenciamento de Reuniões e Análise de Riscos Planejamento Identificar os Riscos. Revisões de Documentos do Projeto, e Análise de Premissas Realizar Análise Qualitativa Categorização dos Riscos dos Riscos Realizar Análise Modelagem e Simulação.Pacote 21 - Aumentar o Quantitativa dos Riscosperíodo de testes Planejar a Respostas aos Estratégia para riscos Riscos positivos e negativos Monitorar e Controlar os Auditorias de riscos Riscos
  29. 29. 168.1 Especificação do Software (Pacote 9) A primeira atividade foi a especificação do software, que teve como responsável aequipe interna da empresa. Este pacote possui a seguinte característica: O departamento de TI poderá utilizar experiências anteriores e módulos de software jáexistentes para criação de novos modelos. Excelente documentação e “Nenhum Erro” sãoesperados. A especificação do software é muito importante para que o objetivo seja satisfeito damelhor maneira. Através dela é possível ter em mãos todos os requisitos, sejam funcionaiscomo não funcionais que são requeridos pelos stakeholders para o desenvolvimento dosoftware. Neste projeto, o software irá gerenciar o controle de pessoas (entrada e saída),controle de sinalização, gerenciamento de manutenções entre outras funcionalidades. Devido a importância deste pacote de trabalho, o grupo decidiu por integrar módulosque já foram utilizados em outros projetos, no qual são comprovadamente eficazes e nãoprecisam de muito desenvolvimento. Tomada essa decisão foram mantidos os valores detecnologia e qualidade, aumentamos o custo, porém o prazo foi diminuído. Entretanto ocorreu um problema, o grupo precisou modernizar os módulos antigos quesão utilizados no novo projeto com novas ferramentas de desenvolvimento. Com essa decisãoaumentamos o custo, em contrapartida aumentamos os valores de tecnologia e qualidade. Em relação aos processos das áreas de conhecimentos Escopo, Qualidade e Riscos sãoapresentados a seguir as justificativas por essa decisão tomada. Escopo: Como mencionado, a estratégia inicial do grupo era nivelar os valores de tecnologia e qualidade tentando diminuir o prazo para que o projeto fosse consumado em 65 semanas, por conta disso o grupo optou por diminuir o prazo para atendermos o que foi definido no escopo. Com essa decisão o grupo conseguiu reduzir o tempo em 2 semanas e não ameaçou o escopo do projeto. Qualidade: Na coleta dos requisitos que esta na fase de planejamento, o grupo reconheceu a necessidade de atualizar os módulos antigos com tecnologias atuais e modernas, essa decisão garantiu mais qualidade e tecnologia ao projeto. O controle da qualidade foi mensurado diante da compreensão dos desenvolvedores no que era para ser desenvolvido com o que foi especificado e documentado neste pacote.
  30. 30. 17 Riscos: O grupo entendeu que os módulos dos softwares de projetos antigos poderiam ser incompatíveis com a tecnologia moderna. Devido a essa tomada de decisão foram realizadas reuniões com toda a equipe onde foram identificados os riscos, agrupando-os em categorias e criado uma lista de verificação, onde foi possível ver onde os riscos seriam maiores.8.2 Desenvolvimento do Software (Pacote 14) Após o término da Especificação do Software, na semana 21, foi iniciado o pacote dedesenvolvimento do software. Esta atribuição também tem como responsável a equipe internade TI da instituição. O desenvolvimento do software é a fase onde desenvolvedores recebem especificaçõesfeitas na fase anterior de especificação do software e tem como objetivo transformar essesrequisitos em um produto real. O pacote descreve que o monitoramento, controle e sistemas de segurança devemser desenvolvidos. Serão usados módulos internos, que serão atualizados em breve. Como o desenvolvimento do software é de grande responsabilidade para o projeto, poiso mesmo irá controlar varias funcionalidades, se faz necessário que seja dada umaimportância considerável a esse pacote de trabalho. Outro motivo que gera preocupação é queserão utilizados alguns módulos internos já existentes para fazerem parte do software . Essesmódulos terão que ser atualizados para atenderem as necessidades atuais. Devido a complexibilidade o grupo optou por contratar desenvolvedores maisexperientes para esse subprojeto. Essa decisão acarretou em um aumento de custo, poremhouve diminuição de tempo. Em relação aos processos das áreas de conhecimentos Escopo, Qualidade e Riscos sãoapresentados a seguir as justificativas por essa decisão tomada. Escopo: Para que não houvessem mudanças no escopo, quando em uma outra decisão, ocasionaria em um aumento considerável no custo e perda de tecnologia e na outra possibilidade um aumento muito superior no prazo, a decisão foi tomada depois de realizadas inspeções e análise de variação onde foram constatados que o mais indicado seria priorizar novamente o prazo do projeto indo ao encontro do escopo.
  31. 31. 18 Qualidade: A decisão de contratar profissionais experientes para mesclar com a equipe interna funciona bem, dão qualidade ao projeto, surgem novas possibilidades para incrementar o pacote com profissionais que já trabalharam com esse tipo de serviço juntamente com a equipe interna que já conhece as peculiaridades desta empresa e estão envolvidos a mais tempo no projeto. Foram feitas auditorias e análise dos processos para garantir que tudo estava sendo feito de acordo com o que foi especificado. Riscos: A condição inicial do pacote apresenta um grande risco, pois a mesma necessita de uma atualização dos módulos já existentes após a sua implantação, e esta atualização pode ter um impacto indesejável no resultado do projeto. A decisão tomada também foi pensada diante dos riscos no qual estavam expostos. Desenvolvedores experientes diminuem a chance de alguma coisa sair fora do esperado, porém mesmo com essa característica, o grupo optou por categorizar esse risco, simulá- lo e monitora-lo através de auditorias de riscos.8.3 Teste do Software (Pacote 21) Os Testes de softwares tem por finalidade, garantir que o produto desenvolvido tenhaatingido aos resultados esperados, atendendo os seus requisitos. Outro objetivo do pacote de teste de software é validar a compatibilidade com outrossoftwares e também com as interfaces que farão uso de suas funcionalidades. O inicio deste pacote ocorre logo após o termino do pacote de Desenvolvimento doSoftware. O pacote tem a seguinte descrição: O módulo de software deve ser testadovalidando a interoperabilidade e compatibilidade com a interface. Devido ao grande número de atualizações e integração dos módulos de sistemas antigos,o grupo optou por aumentar o período de testes para garantir o desempenho esperado. Com essa decisão o custo e o prazo tiveram um reajuste, porem foi agregado valor aqualidade. Em relação aos processos das áreas de conhecimentos Escopo, Qualidade e Riscossão apresentados a seguir as justificativas por essa decisão tomada.
  32. 32. 19Escopo: Através de reuniões foi discutido e pensado o que seria mais favorável emrelação ao testes do software.Na semana 42 quando foi iniciado o teste do software, o prazo do projeto já estavaabaixo do estipulado no escopo, devido a mudanças que o grupo realizou em outrospacotes paralelos priorizando o prazo quase sempre que possível.Como o prazo já estava controlado, o grupo decidiu por mudar o escopo com essadecisão colocando o foco na qualidade. Com essa decisão o prazo deste pacoteaumentou em 2 semanas e o investimento realizado ficou um pouco maior do que oesperado, porém esse pacote não estava no caminho crítico, e isso fez com que nãohouvesse perda no prazo do projeto em geral.Foi realizada uma análise de variação onde foi possível observar o tamanho da mudançaa partir da baseline do escopo garantindo que a alteração não traria muitos impactos aoprojeto tornando-a viável. A alteração foi realizada após aprovação de um comitê decontrole de mudanças e inscritas no registro de mudanças. Segundo Jenny[5], o registrode mudanças é utilizado para documentar as mudanças e seu impacto no projeto.Qualidade: A própria atividade de teste já é considerado um ponto de qualidade aosprojetos. A decisão de aumentarmos o período dos testes do software aumentouconsideravelmente o valor de qualidade no projeto. A equipe realizou reuniões e análisede planejamento para verificar se era viável ou não o acréscimo do período de testes,que ficou comprovado que era considerado. Neste pacote também foram realizadasinspeções onde foram criados gráficos de controle para garantir a qualidade no teste.Risco: Um teste mal feito poderia ocasionar em um rendimento inesperado do softwaree colocando em risco algumas áreas do projeto. Em razão disso, o grupo deu umaatenção maior a esse pacote para dar mais qualidade e eliminar os riscos. Para issoutilizou-se do sub processo de “Identificação dos Riscos” que esta na fase dePlanejamento do Projeto. Para identificar e monitorar os riscos foram utilizadas astécnicas de revisões de documentos do projeto, categorização dos riscos, estratégia parariscos positivos e negativos e auditoria de riscos.
  33. 33. 209. RESULTADOS DO PROJETO, VIABILIDADE E LIÇÕES APRENDIDAS. O objetivo do Business Game é simular o dia a dia de um Gerente de Projetos. Osimulador trás desafios que podem surgir em qualquer projeto real tornando as decisõesimportantes para que no final, o projeto tenha sido concluído com sucesso. No final de cada projeto é importante revelar quais foram os números em todo o seuciclo de vida. E como o intuito desse trabalho é simular um projeto real, os resultadosconquistados podem ser vistos em imagens com gráficos comparativos do inicio ao fim doprojeto. A Figura 6 apresenta o custo do projeto. Como já foi mencionado, a partir da semana40 o projeto estava muito atrasado em relação ao escopo, em razão disso, o grupo focou noprazo fazendo com que a maioria das ações resultassem no aumento do custo do projetoporém, diminuindo o tempo como será apresentado posteriormente. Figura 6 - Evolução de Receita/Custo
  34. 34. 21 Na Figura 7 são mostrados os pontos de qualidade e tecnologia alcançados no projeto. Desde o inicio do projeto a ideia inicial foi sempre nivelar qualidade, tecnologia, custo elucro. Porém como já foi apresentado, isso não foi possível, e o grupo teve que priorizar oprazo para que o escopo de entrega em 65 semanas fosse satisfeito. Entretanto os pontos de tecnologia e qualidade ficaram acima do que foi especificadoem quase todo o ciclo do projeto. Figura 7 - Evolução de Qualidade e Tecnologia A Figura 8 representa a evolução do lucro no decorrer do projeto. Como pode ser visto,o lucro ficou negativo devido a várias disfunções que precisaram ser corrigidas durante oprojeto. Figura 8 - Evolução do Lucro
  35. 35. 22 O projeto tinha em seu escopo um prazo de 65 semanas. Devido a priorização destequesito, o grupo conseguiu ficar bem próximo do prazo estipulado, entregando o projeto em66 semanas como pode ser visto na Figura 9. Figura 9 - Evolução do Prazo A Figura 10 mostra como ficou a EAP do projeto com o caminho crítico e valoresfinais. Figura 10 - EAP com Caminho Crítico e Valores Finais
  36. 36. 23 A Figura 11 apresenta um comparativo do que era para ser feito, ou seja, o que estavano escopo do projeto, também os valores iniciais e os valores finais utilizando comoparâmetros prazo, tecnologia, qualidade custo e lucro. Figura 11 - Comparativo Final9.1 Viabilidade Apesar do orçamento ter ficado em 3.348 milhões de Euros negativos representandodéficit de 34%, em 25 anos que é o tempo no qual foi estipulado para vida útil do produto,com aproximadamente 2 milhões de corridas, se o proprietário decidir por aumentar o valordo ingresso em 35%, aproveitando-se do fato de ter um produto em uma área boa, plana, comum artefato inovador, sistema de som 4D, que não é comum neste tipo de projeto e dando umexcelente conforto aos clientes. Com uma campanha de marketing eficaz fazendo uso dasmídias sociais, redes sociais, trabalho de divulgação, promoções, sempre informando ospontos de qualidade e tecnologia, além do fato de ser a maior Montanha Russa da Europa fazcom que o projeto torna-se viável.
  37. 37. 249.2 Lições Aprendidas Diante dos resultados apresentados o grupo registrou as suas Lições Aprendidas duranteo decorrer do projeto, são estas listadas abaixo. Análise e conhecer o escopo do projeto. Entender os interesses dos stakeholders. Controlar as mudanças pois geram custos. Controlar as metas estipuladas. Manter o controle do caminho crítico do projeto. Manter o controle em situações de risco. Documentar as decisões tomadas. Relatar/Evidênciar as etapas do projeto. Fazer uso de ferramentas disponíveis para gerenciar os processos
  38. 38. 2510. CONCLUSÃO Como foi visto, o projeto foi entregue com um orçamento superior ao estiuplado, porémo grupo conseguiu atingir as metas de Qualidade e Técnologia e com atraso de somente deuma semana da quantidade estipulada no escopo onde resultou em um entusiasmo por partedos stakeholders. O conhecimento em Gestão de Projetos através das boas práticas do PMI utilizando-sedo PMBoK foi fundamental para efetivação do projeto.As lições aprendidas foram de grande importância a formação do grupo, contribuindo deforma decisiva no aprendizado na carreira de cada participante.As lições aprendidas neste projeto foram de grande valor, colaborando de maneira positiva narealização dos conceitos assimilados. Conhecer totalmente as prátcas do PMI não quer dizer que terá sucesso em todos osprojetos, é necessário conhecimento do negócio, ter contato com pessoas experientes que jápassaram por situações similares, buscar lições aprendidas de outros projetos e o principalsaber ser líder. Liderança não é somente dar ordens, a verdadeira liderança se conquista combase no serviço, saber ouvir a equipe, dar boas condições de trabalho, manter um bomambiente na equipe faz com que o Gerente de Projetos não seja visto como somente como umgerente mas sim como um verdadeiro líder.
  39. 39. 26 REFERÊNCIAS[1] Project Management Institute, Inc., PMBoK, Guia em Gerenciamento de Projetos –Quarta Edição, 2008.[2] VARGAS, Ricardo, Gerenciamento de Projetos – Estabelecendo DiferenciaisCompetitivos,Rio de Janeiro, Editora Brasport, 2005.[3] TATA Interactive Systems, TOPSIM, Disponível em http://www.topsim.com/, últimoacesso em 17/12/2012.[4] FERRAZ, Lucaz, Histórias das Montanhas-Russas, Disponível emhttp://www.cbmr.com.br/index.php/component/content/article/13-artigos/lucas/6-historiamrsúltimo acesso em 17/12/2012.[5] JENNY,Juliana, Modelo: Solicitações de , Disponível emhttp://julianakolb.com/2011/02/23/modelo-solicitacoes-de-mudancas/, último acesso em17/12/2012.

×