FACULDADES IBTA

Leonardo Melo de LIMA

GERENCIANDO UM PROJETO DE CONSTRUO DE UMA

MONTANHA RUSSA

SO JOS DOS CAMPOS

2013

Leonardo Melo de LIMA

GERENCIANDO UM PROJETO DE CONSTRUO DE UMA

MONTANHA RUSSA

Monografia apresentada FACULDADES IBTA

para a concluso do curso MBA em Gesto de
Projetos - PMI.

Orientadores: Prof. John DALE

e

Prof. Dr. Eduardo Madeira BORGES

SO JOS DOS CAMPOS

2013

FICHA CATALOGRFICA
LIMA, Leonardo Melo
Gerenciando um Projeto de Construo de uma Montanha Russa / Leonardo Melo de
Lima. So Jos dos Campos, FACULDADES IBTA, 2013.
XIII, 26 p., il.
Orientadores: John DALE e Eduardo Madeira BORGES
Monografia - Trabalho de Concluso do Curso MBA em Gesto de Projetos PMI,
FACULDADES IBTA, 2013.

1. Projeto; 2. PMBoK; 3. Deciso; 4.Montanha Russa. Tese.

I. DALE, John . II BORGES, Eduardo Madeira. III. FACULDADES IBTA. Curso MBA em
Gesto de Projetos - PMI. IV. Ttulo.

Leonardo Melo de LIMA

GERENCIANDO UM PROJETO DE CONSTRUO DE UMA

MONTANHA RUSSA

Monografia apresentada a FACULDADES IBTA

para a concluso do curso MBA em Gesto de
Projetos - PMI

Aprovado em 21/02/2013
BANCA EXAMINADORA
________________________________________________________
Prof. John DALE
FACULDADES IBTA
_________________________________________________________
Prof. Dr. Eduardo Madeira BORGES
Instituto de Estudos Avanados
FACULDADES IBTA
__________________________________________________________
Prof. MsC. Sergio Amlio Ribeiro CINTRA
FACULDADES IBTA

Dedico este trabalho primeiramente a Deus, pois

ele o meu guia, sustentador e consolador em
todos os momentos de dificuldade. Toda honra e
glria seja dada a ele.
Dedico tambm a minha famlia que esteve
comigo

em

todos

os

momentos.

AGRADECIMENTOS

Agradeo a Deus por ter me dado condies de concluir este curso. Toda glria e honra seja
dada ao meu Deus. No poderia deixar de citar tambm minha querida esposa que se manteve
ao meu lado em todos os momentos dessa jornada, me dando total apoio e incentivo. Ao meu
filho que muitas vezes no pude dar o tempo necessrio a ele por conta de alguma atividade,
meus pais que sempre me apoiaram, e aos professores que deram todo o suporte para que eu
chegasse at aqui.

O planejamento no uma tentativa de

predizer o que vai acontecer. O planejamento
um instrumento para raciocinar agora, sobre
que trabalhos e aes sero necessrios hoje,
para merecermos um futuro. O produto final do
planejamento no a informao: sempre o
trabalho.
Peter Drucker

RESUMO

O objetivo deste documento mostrar o gerenciamento de um projeto de uma inovadora

Montanha Russa, utilizando os conceitos do PMBoK[1], focando em trs especficas reas de
conhecimento: Escopo, Qualidade e Risco. So apresentados anlises das tomadas de decises
durante o projeto bem como as lies aprendidas.

Palavras-chave: Projeto; PMBoK; Deciso; Montanha Russa

ABSTRACT

The purpose of this document is to show the management of a project of an innovative Roller
Coaster, 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 as
lessons learned.

Key words: Project; PMBok; Decision; Roller Coaster;

LISTA DE FIGURAS
Figura 1 - Problema na Perspectiva dos Stakeholders .................................................................. 6
Figura 2 - Importantes Subprojetos ............................................................................................... 7
Figura 3 - Diagrama de Redes ....................................................................................................... 8
Figura 4 - Montanha Russa Patenteada por Thompson ................................................................. 9
Figura 5 - Situao Inicial do Projeto EAP .............................................................................. 10
Figura 6 - Evoluo de Receita/Custo ......................................................................................... 20
Figura 7 - Evoluo de Qualidade e Tecnologia ......................................................................... 21
Figura 8 - Evoluo do Lucro ...................................................................................................... 21
Figura 9 - Evoluo do Prazo ...................................................................................................... 22
Figura 10 - EAP com Caminho Crtico e Valores Finais ............................................................ 22
Figura 11 - Comparativo Final .................................................................................................... 23

LISTA DE TABELAS
Tabela 1- Situao Inicial do Projeto .......................................................................................... 10
Tabela 2- Relao das reas de Conhecimento com Fases do Projeto ....................................... 13
Tabela 3 - Relao entre as Decises, Processos e Ferramental ................................................. 15

LISTA DE ABREVIATURAS E SIGLAS

EAP Estrutura Analtica do Projeto.

PMI - Project Management Institute.
PMBoK - Project Management Body of Knowledge.

SUMRIO

1.

INTRODUO ................................................................................................................... 1

1.1 Objetivo ................................................................................................................................... 2

1.2 Estrutura do Trabalho .............................................................................................................. 2
2.

FUNDAMENTAO DE GERENCIAMENTO DE PROJETOS ................................ 3

2.1 O que o PMBoK?.................................................................................................................. 3

2.2 O que Gerenciamento de Projetos? ....................................................................................... 4
2.3 O que um Gerente de Projetos? ............................................................................................ 4
2.4O que PMI? ............................................................................................................................ 4
3.

COMEANDO O PROJETO ............................................................................................ 5

3.1 Como foi Criado o Projeto? ..................................................................................................... 5

3.2 TOPSIM .................................................................................................................................. 5
3.3 A Empresa Hypermax Inc ....................................................................................................... 6
3.4Premissas do Projeto................................................................................................................. 8
4.

HISTRIA DA MONTANHA RUSSA ............................................................................. 9

5.

APRESENTAO DOS DADOS INICIAIS .................................................................. 10

6.

ESTRATGIA DO GRUPO ............................................................................................ 11

7.

REAS DE CONHECIMENTO PMBOK ................................................................... 11

8.

ANLISE DOS PACOTES ESCOLHIDOS ................................................................... 14

8.1 Especificao do Software (Pacote 9) ................................................................................... 16

8.2 Desenvolvimento do Software (Pacote 14) ........................................................................... 17
8.3 Teste do Software (Pacote 21) ............................................................................................... 18
9.

RESULTADOS DO PROJETO, VIABILIDADE E LIES APRENDIDAS. .......... 20

9.1 Viabilidade ............................................................................................................................ 23

9.2 Lies Aprendidas ................................................................................................................. 24
10.

CONCLUSO................................................................................................................ 25
REFERNCIAS ............................................................................................................ 26

1. INTRODUO

Atualmente as instituies esto cada vez mais preocupadas com os custos e

lucros de todas as estruturas organizacionais. A procura pela reduo dos custos e busca
por resultados que agregam valor obrigatrio para que uma empresa possa sobreviver
em um ambiente globalizado e com forte concorrncia.
Com a disputa cada vez mais acirrada, novos produtos, campanhas de marketing,
modificar processos internos, inovaes no relacionamento com os clientes se tornam
muito necessrio. E para a realizao de tudo isso e muitas outras coisas, as empresas
precisam de projetos.
O desenvolvimento de novos produtos com o auxlio do gerenciamento de
projetos, tem conquistado timos resultados, e profissionais com este tipo de
qualificao cada vez mais requisitados e valorizados.
A principal organizao direcionada para as prticas de gerenciamento de projeto
o Project Manager Institute (PMI), que atravs da experincia de renomados
profissionais da rea de gesto de projetos criou um guia de melhores prticas
conhecido 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 sero mostrados neste documento assim como as prticas adotadas ao
longo do projeto.

1.1 Objetivo

O objetivo deste trabalho apresentar as experincias obtidas durante o

desenvolvimento do projeto da montanha russa RockStar, focando em trs reas de
conhecimento definidas atravs do PMBoK[1]. As reas de conhecimento so: Escopo,
Qualidade e Risco.
Trs pacotes de trabalho deste projeto sero apresentados. Os pacotes so
referente ao software da montanha russa: Especificao do Software, Desenvolvimento
do Software e Teste do Software.

1.2 Estrutura do Trabalho

O Captulo 2 apresenta os conceitos sobre Gerenciamento de Projetos e as reas

de conhecimento escolhidas de acordo com o PMBoK[1].
No Captulo 3 apresentada uma viso geral sobre o simulador que foi utilizado para
realizar esse trabalho, tambm no captulo 3 possvel ver quais so as premissas do
projeto.
O Captulo seguinte conta a histria do surgimento da montanha russa, como
comeou, onde, sua modificaes, at os dias de hoje.
No Captulo 5 so apresentados os valores iniciais do projeto antes. O Captulo 6 mostra
qual foi estratgia adotada para o projeto .
No Captulo 7 feita uma pequena apresentao das reas de conhecimento que
foram escolhidas para este trabalho, O oitavo detalha os acontecimentos em trs pacotes
de trabalhos do projeto sobre a tica das trs reas de conhecimento: Escopo, Qualidade
e Risco.
No Capitulo seguinte so mostrados os resultados do projeto assim como a sua
viabilidade e o ltimo captulo traz a concluso do trabalho com alguns detalhes do
projeto e finalizando com a utilizao do PMBoK[1] no Gerenciamento de Projetos.

2. FUNDAMENTAO DE GERENCIAMENTO DE PROJETOS

2.1 O que o PMBoK?

O PMBoK[1] um manual que contm um agrupamento de conhecimentos e boas

prticas do gerenciamento de projetos, atualmente encontra-se na quarta edio, e mantido
pela instituio Project Management Institute (PMI),
Entende-se como boas prticas um conjunto de mtodos que tiveram sucesso em outros
grandes projetos com resultados favorveis, porm, poder acontecer que um desses mtodos
no seja utilizvel 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 so mostrados logo
abaixo.

Grupo de Processos
Iniciao
Planejamento
Execuo
Monitoramento e Controle
Encerramento

reas de Conhecimento
Escopo
Tempo
Custo
Qualidade
RH
Comunicaes
Riscos
Aquisies
Integrao

2.2 O que Gerenciamento de Projetos?

De acordo com o PMBoK[1] o gerenciamento de projetos uma aplicao de

conhecimento, ferramentas, habilidades e tcnicas s atividades do projeto a fim de atender
aos seus requisitos.
No obrigatrio, porm recomendvel que um Gerente de Projetos tenha
conhecimento na rea no qual esta gerenciando, por exemplo: Arquiteto trabalhando em um
projeto de construo de um imvel ou Analista de Sistemas trabalhando em um projeto de
construo de um software, mas como foi dito anteriormente, no h nenhuma regra que
obrigue um Gerente de Projetos a no atuar em alguma determinada rea.

2.3 O que um Gerente de Projetos?

De acordo com o PMBok[1]

o gerenciamento de projetos uma aplicao de

conhecimento, ferramentas, habilidades e tcnicas s atividades do projeto a fim de atender

aos seus requisitos. No obrigatrio, porm recomendvel que um Gerente de Projetos tenha
conhecimento na rea no qual esta gerenciando, por exemplo: Arquiteto trabalhando em um
projeto de construo de um imvel ou Analista de Sistemas trabalhando em um projeto de
construo de um software, mas como foi dito anteriormente, no h nenhuma regra que
obrigue um Gerente de Projetos a no atuar em alguma determinada rea.
Segundo Vargas[2], o gerenciamento de projetos pode ser aplicado a qualquer situao
onde exista empreendimento que foge ao que fixo e rotineiro na empresa.

2.4 O que PMI?

PMI (Project Management Institute), a maior instituio sem fins lucrativos que
colabora com a criao de padres para o gerenciamento de projetos reunindo-os em seu guia
PMBok[1] mundialmente conhecido, assim como capacitar os profissionais e organizaes da
rea de gerenciamento de projetos.

3. COMEANDO O PROJETO

3.1 Como foi Criado o Projeto?

Este projeto foi desenvolvido na disciplina de Business Game do curso de MBA em

Gesto de Projetos PMI da faculdade IBTA.
A finalidade do Business Game exemplificar aos alunos como um ambiente de
projeto real desde a fase de iniciao at a fase de encerramento, aplicando os conhecimentos
adquirido em todas as disciplinas j cursadas, fazendo uso das boas prticas de gesto de
projetos segundo o PMBoK[1].

3.2 TOPSIM

Servindo como base para a realizao desse projeto, foi utilizado uma ferramenta
denominada TOPSIM.
um software criado pela empresa alem Tata[3] Systems e sua finalidade simular a
realizao do projeto com base nas boas prticas do PMBoK[1]. O objetivo do TOPSIM
tornar real um projeto, proporcionando algumas experincias como:
Realidade de uma empresa.
Conhecimento em administrao.
Deparar-se com riscos e dvidas.
Trabalho em equipe
Situaes adversas
Responsabilidades de um Gerente de Projetos.

O TOPSIM tambm fornece algumas ferramentas utilizadas diariamente por um

Gerente de Projetos como:
Relatrio de Custo.
Demonstrao do caminho crtico.
Projeo dos pacotes de trabalho e suas dependncias.

3.3 A Empresa Hypermax Inc

A empresa Hypermax Inc uma empresa que constri maquinas mecnicas, e uma de
suas especialidades a construo de Montanhas Russas.
Composta aproximadamente por 1000 (um mil) colaboradores, e no ltimo ano
obteve um lucro de 280 milhes de Euros, porm atualmente passa por problemas financeiros
e teve uma queda em suas receitas.
Os objetivos deste projeto so:
Entregar a Montanha Russa denominada HyperCoaster no prazo estimado.
Conquistar e se possvel aumentar os nveis de Qualidade e Tecnologia.
Evitar penalidades descritas no contrato.
Stakeholders so pessoas que fazem parte direta ou indiretamente de um projeto. Podem
ter interesses ou no em sua realizao. Neste projeto alguns stakeholders se mostraram
contrrios a sua criao como ilustra a Figura 1.

Figura 1 - Problema na Perspectiva dos Stakeholders

Alm do que apresenta a Figura 1, existem alguns pontos a serem destacados diante do
projeto da Hipermax Inc que so:
Clientes Insatisfeitos.
Frequentes mudanas que geram aumento de custo.
Nenhum setor da empresa quer assumir o projeto.
Alguns pontos no contrato do cliente no so claros.
As datas de entrega no so cumpridas.

Para amenizar esses problemas ficou acordado que o Gerente de Projetos ter seu papel
reforado, e que o prximo projeto servir como piloto para o novo sistema.
Tambm foram traadas algumas metas:
Ser rentvel para garantir a sobrevivncia da empresa.
Alto nvel de satisfao 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

A Figura 3 mostra os subprojetos divididos em pacotes de trabalho.

Figura 3 - Diagrama de Redes

3.4 Premissas do Projeto

Deve-se cumprir algumas premissas para que o projeto seja realizado de acordo com o
escopo definido. Estas premissas so:
O projeto deve ter no mximo 65 semanas.
O valor do projeto no deve ultrapassar 10 milhes de Euros.
Pontos de Tecnologia e Qualidade maiores ou iguais a 100.
Vida til do equipamento em 25 anos ou 2 milhes de corridas.
Comprimento do caminho percorrido 1000 m com altura mxima faixa de 50 m.
A velocidade mxima 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.

4. HISTRIA DA MONTANHA RUSSA

Segundo FERRAZ[4], a montanha russa existe desde o sculo XVI onde pessoas
brincavam de escorregar no gelo formado em cima de montanhas na Russia, da vem o nome
de Montanha Russa. A brincadeira fez tanto sucesso, que foi sendo aprimorada com
tecnologia at se tornarem populares em todo o mundo. Existem Montanhas Russas capazes
de chegar a mais de 200Km/h em uma altura de mais de 130 metros.
No h nenhum relato de quando foram colocadas as rodas nos carrinhos, mas alguns
historiadores creditam aos franceses os primeiros carrinhos com rodas em 1804, tambm
foram os inventores da montanha russa com looping no Frascati Gardens" Paris em 1846.
Alguns anos depois um homem chamado La Marcus Adna Thompson construiu a
primeira montanha russa fabricada no continente americano. Cada visitante pagava um nquel
pelo passeio a 9,6 km/h num percurso de cerca de 200 metros de extenso e 16,5 de altura
com algumas pequenas colinas no meio.
O negcio foi lucrativo a Thompsom que acabou entrando de vez no negcio dos
parques de diverso onde comeou a ser chamados por muitos de O pai da gravidade.
A indstria continuou prospera. Anton Schwarzkopf foi o homem que mais projetou
montanhas russas na histria. Encontra-se exemplos da sua arte em quase todos os pases do
mundo. Ele morreu em julho de 2001.
Muitos outros vieram e se interessaram pelo negcio que enxergaram ser promissor.
Atualmente existem montanhas russas em que as pessoas vo sentadas, de p, deitadas
em posio de vo, girando, sem cho e de costas. Existe montanha russas lanada, reversa,
gigante.
A Figura 4 apresenta a montanha russa patenteada por Thompson.

Figura 4 - Montanha Russa Patenteada por Thompson

10

5. APRESENTAO DOS DADOS INICIAIS

A situao com os valores que iniciaram o projeto esta representada conforme mostra
a Tabela 1 e a Figura 5 respectivamente.
Tabela 1- Situao Inicial do Projeto

Durao:

73 semanas

Custo:

8.525,00 Euros

Tecnologia:

100

Qualidade:

100

Receita:

8.050,00 Euros

Lucro:

-475,00 Euros

Figura 5 - Situao Inicial do Projeto EAP

11

6. ESTRATGIA DO GRUPO

De acordo com os objetivos do projeto, seguindo suas premissas, o grupo teve que
tomar algumas decises para priorizar alguns pontos estratgicos.
Como era premissa do projeto, um alto nvel de qualidade e tecnologia somando-se ao
fato de no extrapolar o custo mximo de 10 milhes de Euros e 65 semanas de durao, o
grupo decidiu por:
Sempre que possvel optar por diminuir o prazo.
Ganhar pontos de qualidade e tecnologia.
No permitir um aumento considervel no custo.

Ou seja, a ideia era nivelar todas essas opes para que no final o projeto cumprisse
com as expectativas.
Porm at semana 40, o prazo ainda estava bem maior do que foi estipulado por conta de
alguns distrbios que ocorreram no decorrer do projeto at aquela semana.
Em razo disso, o grupo decidiu mudar a estratgia e comeou a priorizar o prazo no
intuito de concluir o projeto no tempo estimado.
7. REAS DE CONHECIMENTO PMBOK

No Captulo 2 foi comentado que o PMBoK[1] possui 9 reas de conhecimento. Neste

trabalho ser mostrado apenas 3 delas, que so:
Escopo: No PMBoK[1] edio 4, Captulo 5, o Gerenciamento do Escopo do projeto
inclui os processos necessrios para garantir que o projeto inclua todo o trabalho
necessrio, e somente ele, para terminar o projeto com sucesso.
Coleta dos dados necessrios com os stakeholders para atingir o objetivo do projeto,
definir o escopo e desenvolvendo uma descrio detalhada do projeto e do produto,
criao da EAP (Estrutura Analtica do Projeto), que o processo que divide as entregas
do projeto em partes menores e mais fceis de gerenci-las, verificar o escopo
formalizando a aceitao das entregas terminadas do projeto e controlar o escopo que
monitora o progresso do escopo e gerencia as mudanas feitas na linha de base do
escopo.

12

Qualidade: O PMBoK[1] no captulo 8, descreve o Gerenciamento de Qualidade como

polticas e procedimentos com atividades de melhoria contnua 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 documentao
dos mesmos, realizar a garantia da qualidade por meio de auditorias e medies nos
requisitos de qualidade e por fim realizar o controle da qualidade no qual atravs do
monitoramento dos resultados as atividades so avaliadas a fim de caso necessrio, haja
uma recomendao para mudanas necessrias.

Riscos: De acordo com o guia PMBok[1] edio 4 captulo 11, o Gerenciamento de

Riscos inclui processos de planejamento, identificao, anlise, 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 so definidas as formas de como conduzir as
atividades de gerenciamento de riscos, identificar os riscos onde so determinados os
riscos que podem afetar o projeto, realizar a anlise quantitativa dos riscos onde feita
uma anlise numrica do efeito dos riscos identificados, planejar as respostas aos riscos
que desenvolve aes para reduzir as ameaas aos objetivos e por fim, monitorar e
controlar os riscos onde implantado planos de respostas aos riscos, identificao de
novos riscos e tratamento dos riscos durante todo o projeto.

A seguir Tabela 2 ilustra a relao destas reas de conhecimento com as fases do

projeto.

13
Tabela 2- Relao das reas de Conhecimento com Fases do Projeto

Fases do Projeto
Iniciao

Planejamento

Escopo
-

reas de Conhecimento
Qualidade
-

Coletar Requisitos

Planejar a Qualidade

Definir Escopo

Criar EAP

Execuo
Monitoramento e
Controle
Encerramento

Verificao do
Escopo
Controle do Escopo
-

Risco
Planejar o
Gerenciamento de
Risco
Identificar os Riscos
Realizar Anlise
Qualitativa dos
Riscos
Realizar Anlise
Quantitativa dos
Riscos
Planejar as Respostas
aos Riscos

Realizar a Garantia
da Qualidade
Realizar o Controle
de Qualidade

Monitorar e
Controlar os Riscos

14

8. ANLISE DOS PACOTES ESCOLHIDOS

O projeto possu 46 pacotes de trabalho agrupados nos subsistemas no qual j foi

mencionado. Para esta anlise foram escolhidos 3 pacotes. So esses:

Especificao do Software (Pacote 9).

Desenvolvimento do Software (Pacote 14).
Teste de Software (Pacote 21).

Estes pacotes so sequenciais ou seja, para que um comece a ser desenvolvido,

necessrio a concluso do anterior. Os trs pacotes fazem parte do subprojeto Software.
A Tabela 3 apresenta as decises tomadas em cada pacote escolhido, tambm mostra
os processos contidos no PMBoK[1] nas trs reas de conhecimento selecionadas para este
trabalho e as aes utilizadas em cada processo para que o objetivo fosse cumprido. As
ferramentas adotadas foram as mesmas para os trs pacotes.
Cada pacote possui 4 alternativas, sendo que a primeira a alternativa padro, ou seja o
pacote mantem a opo que se encontra, e outras trs opes diferentes.
Nos prximos itens sero apresentados os motivos no qual o grupo se baseou para a
tomada de deciso.

15
Tabela 3 - Relao entre as Decises, Processos e Ferramental

Decises Tomadas

Processos
Coletar Requisitos
Definir Escopo

Pacote 9 Integrar mdulos

que j foram utilizados em
outros projetos.
Criar a EAP
Verificar Escopo
Controlar Escopo
Planejar a Qualidade
Realizar a Garantia da
Qualidade
Realizar o Controle da
Pacote 14 Contratar
Qualidade
desenvolvedores experientes Planejar Gerenciamento de
Riscos
Identificar os Riscos.

Pacote 21 - Aumentar o
perodo de testes

Realizar Anlise Qualitativa

dos Riscos
Realizar Anlise
Quantitativa dos Riscos
Planejar a Respostas aos
Riscos
Monitorar e Controlar os
Riscos

Ferramental
Entrevistas com usurios
Termo de Abertura do
subprojeto com
documentao dos requisitos
Decomposio hierrquica
Inspees
Anlise de Variao.
Fluxogramas e anlise de
custo benefcio.
Auditorias de Qualidade e
Anlise de processos
Inspees e Grficos de
Controle
Reunies e Anlise de
Planejamento
Revises de Documentos do
Projeto, e Anlise de
Premissas
Categorizao dos Riscos
Modelagem e Simulao.
Estratgia para riscos
positivos e negativos
Auditorias de riscos

16

8.1 Especificao do Software (Pacote 9)

A primeira atividade foi a especificao do software, que teve como responsvel a

equipe interna da empresa. Este pacote possui a seguinte caracterstica:
O departamento de TI poder utilizar experincias anteriores e mdulos de software j
existentes para criao de novos modelos. Excelente documentao e Nenhum Erro so
esperados.
A especificao do software muito importante para que o objetivo seja satisfeito da
melhor maneira. Atravs dela possvel ter em mos todos os requisitos, sejam funcionais
como no funcionais que so requeridos pelos stakeholders para o desenvolvimento do
software. Neste projeto, o software ir gerenciar o controle de pessoas (entrada e sada),
controle de sinalizao, gerenciamento de manutenes entre outras funcionalidades.
Devido a importncia deste pacote de trabalho, o grupo decidiu por integrar mdulos
que j foram utilizados em outros projetos, no qual so comprovadamente eficazes e no
precisam de muito desenvolvimento. Tomada essa deciso foram mantidos os valores de
tecnologia e qualidade, aumentamos o custo, porm o prazo foi diminudo.
Entretanto ocorreu um problema, o grupo precisou modernizar os mdulos antigos que
so utilizados no novo projeto com novas ferramentas de desenvolvimento. Com essa deciso
aumentamos o custo, em contrapartida aumentamos os valores de tecnologia e qualidade.
Em relao aos processos das reas de conhecimentos Escopo, Qualidade e Riscos so
apresentados a seguir as justificativas por essa deciso tomada.

Escopo: Como mencionado, a estratgia 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 deciso o grupo conseguiu reduzir o tempo em 2
semanas e no ameaou o escopo do projeto.

Qualidade: Na coleta dos requisitos que esta na fase de planejamento, o grupo

reconheceu a necessidade de atualizar os mdulos antigos com tecnologias atuais e
modernas, essa deciso garantiu mais qualidade e tecnologia ao projeto. O controle da
qualidade foi mensurado diante da compreenso dos desenvolvedores no que era para
ser desenvolvido com o que foi especificado e documentado neste pacote.

17

Riscos: O grupo entendeu que os mdulos dos softwares de projetos antigos poderiam
ser incompatveis com a tecnologia moderna. Devido a essa tomada de deciso foram
realizadas reunies com toda a equipe onde foram identificados os riscos, agrupando-os
em categorias e criado uma lista de verificao, onde foi possvel ver onde os riscos
seriam maiores.

8.2 Desenvolvimento do Software (Pacote 14)

Aps o trmino da Especificao do Software, na semana 21, foi iniciado o pacote de

desenvolvimento do software. Esta atribuio tambm tem como responsvel a equipe interna
de TI da instituio.
O desenvolvimento do software a fase onde desenvolvedores recebem especificaes
feitas na fase anterior de especificao do software e tem como objetivo transformar esses
requisitos em um produto real.
O pacote descreve que o monitoramento, controle e sistemas de segurana devem
ser desenvolvidos. Sero usados mdulos internos, que sero atualizados em breve.
Como o desenvolvimento do software de grande responsabilidade para o projeto, pois
o mesmo ir controlar varias funcionalidades, se faz necessrio que seja dada uma
importncia considervel a esse pacote de trabalho. Outro motivo que gera preocupao que
sero utilizados alguns mdulos internos j existentes para fazerem parte do software . Esses
mdulos tero que ser atualizados para atenderem as necessidades atuais.
Devido a complexibilidade o grupo optou por contratar desenvolvedores mais
experientes para esse subprojeto. Essa deciso acarretou em um aumento de custo, porem
houve diminuio de tempo.
Em relao aos processos das reas de conhecimentos Escopo, Qualidade e Riscos so
apresentados a seguir as justificativas por essa deciso tomada.

Escopo: Para que no houvessem mudanas no escopo, quando em uma outra deciso,
ocasionaria em um aumento considervel no custo e perda de tecnologia e na outra
possibilidade um aumento muito superior no prazo, a deciso foi tomada depois de
realizadas inspees e anlise de variao onde foram constatados que o mais indicado
seria priorizar novamente o prazo do projeto indo ao encontro do escopo.

18

Qualidade: A deciso de contratar profissionais experientes para mesclar com a equipe

interna funciona bem, do qualidade ao projeto, surgem novas possibilidades para
incrementar o pacote com profissionais que j trabalharam com esse tipo de servio
juntamente com a equipe interna que j conhece as peculiaridades desta empresa e esto
envolvidos a mais tempo no projeto. Foram feitas auditorias e anlise dos processos
para garantir que tudo estava sendo feito de acordo com o que foi especificado.

Riscos: A condio inicial do pacote apresenta um grande risco, pois a mesma necessita
de uma atualizao dos mdulos j existentes aps a sua implantao, e esta atualizao
pode ter um impacto indesejvel no resultado do projeto.
A deciso tomada tambm foi pensada diante dos riscos no qual estavam expostos.
Desenvolvedores experientes diminuem a chance de alguma coisa sair fora do esperado,
porm mesmo com essa caracterstica, o grupo optou por categorizar esse risco, simullo e monitora-lo atravs de auditorias de riscos.

8.3 Teste do Software (Pacote 21)

Os Testes de softwares tem por finalidade, garantir que o produto desenvolvido tenha
atingido aos resultados esperados, atendendo os seus requisitos.
Outro objetivo do pacote de teste de software validar a compatibilidade com outros
softwares e tambm com as interfaces que faro uso de suas funcionalidades.
O inicio deste pacote ocorre logo aps o termino do pacote de Desenvolvimento do
Software. O pacote tem a seguinte descrio: O mdulo de software deve ser testado
validando a interoperabilidade e compatibilidade com a interface.
Devido ao grande nmero de atualizaes e integrao dos mdulos de sistemas antigos,
o grupo optou por aumentar o perodo de testes para garantir o desempenho esperado.
Com essa deciso o custo e o prazo tiveram um reajuste, porem foi agregado valor a
qualidade. Em relao aos processos das reas de conhecimentos Escopo, Qualidade e Riscos
so apresentados a seguir as justificativas por essa deciso tomada.

19

Escopo: Atravs de reunies foi discutido e pensado o que seria mais favorvel em
relao ao testes do software.
Na semana 42 quando foi iniciado o teste do software, o prazo do projeto j estava
abaixo do estipulado no escopo, devido a mudanas que o grupo realizou em outros
pacotes paralelos priorizando o prazo quase sempre que possvel.
Como o prazo j estava controlado, o grupo decidiu por mudar o escopo com essa
deciso colocando o foco na qualidade. Com essa deciso o prazo deste pacote
aumentou em 2 semanas e o investimento realizado ficou um pouco maior do que o
esperado, porm esse pacote no estava no caminho crtico, e isso fez com que no
houvesse perda no prazo do projeto em geral.
Foi realizada uma anlise de variao onde foi possvel observar o tamanho da mudana
a partir da baseline do escopo garantindo que a alterao no traria muitos impactos ao
projeto tornando-a vivel. A alterao foi realizada aps aprovao de um comit de
controle de mudanas e inscritas no registro de mudanas. Segundo Jenny[5], o registro
de mudanas utilizado para documentar as mudanas e seu impacto no projeto.

Qualidade: A prpria atividade de teste j considerado um ponto de qualidade aos

projetos. A deciso de aumentarmos o perodo dos testes do software aumentou
consideravelmente o valor de qualidade no projeto. A equipe realizou reunies e anlise
de planejamento para verificar se era vivel ou no o acrscimo do perodo de testes,
que ficou comprovado que era considerado. Neste pacote tambm foram realizadas
inspees onde foram criados grficos de controle para garantir a qualidade no teste.

Risco: Um teste mal feito poderia ocasionar em um rendimento inesperado do software

e colocando em risco algumas reas do projeto. Em razo disso, o grupo deu uma
ateno maior a esse pacote para dar mais qualidade e eliminar os riscos. Para isso
utilizou-se do sub processo de Identificao dos Riscos que esta na fase de
Planejamento do Projeto. Para identificar e monitorar os riscos foram utilizadas as
tcnicas de revises de documentos do projeto, categorizao dos riscos, estratgia para
riscos positivos e negativos e auditoria de riscos.

20

9. RESULTADOS DO PROJETO, VIABILIDADE E LIES APRENDIDAS.

O objetivo do Business Game simular o dia a dia de um Gerente de Projetos. O

simulador trs desafios que podem surgir em qualquer projeto real tornando as decises
importantes para que no final, o projeto tenha sido concludo com sucesso.
No final de cada projeto importante revelar quais foram os nmeros em todo o seu
ciclo de vida. E como o intuito desse trabalho simular um projeto real, os resultados
conquistados podem ser vistos em imagens com grficos comparativos do inicio ao fim do
projeto.

A Figura 6 apresenta o custo do projeto. Como j foi mencionado, a partir da semana

40 o projeto estava muito atrasado em relao ao escopo, em razo disso, o grupo focou no
prazo fazendo com que a maioria das aes resultassem no aumento do custo do projeto
porm, diminuindo o tempo como ser apresentado posteriormente.

Figura 6 - Evoluo de Receita/Custo

21

Na Figura 7 so mostrados os pontos de qualidade e tecnologia alcanados no projeto.

Desde o inicio do projeto a ideia inicial foi sempre nivelar qualidade, tecnologia, custo e
lucro. Porm como j foi apresentado, isso no foi possvel, e o grupo teve que priorizar o
prazo para que o escopo de entrega em 65 semanas fosse satisfeito.
Entretanto os pontos de tecnologia e qualidade ficaram acima do que foi especificado
em quase todo o ciclo do projeto.

Figura 7 - Evoluo de Qualidade e Tecnologia

A Figura 8 representa a evoluo do lucro no decorrer do projeto. Como pode ser visto,
o lucro ficou negativo devido a vrias disfunes que precisaram ser corrigidas durante o
projeto.

Figura 8 - Evoluo do Lucro

22

O projeto tinha em seu escopo um prazo de 65 semanas. Devido a priorizao deste

quesito, o grupo conseguiu ficar bem prximo do prazo estipulado, entregando o projeto em
66 semanas como pode ser visto na Figura 9.

Figura 9 - Evoluo do Prazo

A Figura 10 mostra como ficou a EAP do projeto com o caminho crtico e valores
finais.

Figura 10 - EAP com Caminho Crtico e Valores Finais

23

A Figura 11 apresenta um comparativo do que era para ser feito, ou seja, o que estava
no escopo do projeto, tambm os valores iniciais e os valores finais utilizando como
parmetros prazo, tecnologia, qualidade custo e lucro.

Figura 11 - Comparativo Final

9.1 Viabilidade

Apesar do oramento ter ficado em 3.348 milhes de Euros negativos representando

dficit de 34%, em 25 anos que o tempo no qual foi estipulado para vida til do produto,
com aproximadamente 2 milhes de corridas, se o proprietrio decidir por aumentar o valor
do ingresso em 35%, aproveitando-se do fato de ter um produto em uma rea boa, plana, com
um artefato inovador, sistema de som 4D, que no comum neste tipo de projeto e dando um
excelente conforto aos clientes. Com uma campanha de marketing eficaz fazendo uso das
mdias sociais, redes sociais, trabalho de divulgao, promoes, sempre informando os
pontos de qualidade e tecnologia, alm do fato de ser a maior Montanha Russa da Europa faz
com que o projeto torna-se vivel.

24

9.2 Lies Aprendidas

Diante dos resultados apresentados o grupo registrou as suas Lies Aprendidas durante
o decorrer do projeto, so estas listadas abaixo.

Anlise e conhecer o escopo do projeto.

Entender os interesses dos stakeholders.
Controlar as mudanas pois geram custos.
Controlar as metas estipuladas.
Manter o controle do caminho crtico do projeto.
Manter o controle em situaes de risco.
Documentar as decises tomadas.
Relatar/Evidnciar as etapas do projeto.
Fazer uso de ferramentas disponveis para gerenciar os processos

25

10. CONCLUSO

Como foi visto, o projeto foi entregue com um oramento superior ao estiuplado, porm
o grupo conseguiu atingir as metas de Qualidade e Tcnologia e com atraso de somente de
uma semana da quantidade estipulada no escopo onde resultou em um entusiasmo por parte
dos stakeholders.

O conhecimento em Gesto de Projetos atravs das boas prticas do PMI utilizando-se

do PMBoK foi fundamental para efetivao do projeto.
As lies aprendidas foram de grande importncia a formao do grupo, contribuindo de
forma decisiva no aprendizado na carreira de cada participante.

As lies aprendidas neste projeto foram de grande valor, colaborando de maneira positiva na
realizao dos conceitos assimilados.

Conhecer totalmente as prtcas do PMI no quer dizer que ter sucesso em todos os
projetos, necessrio conhecimento do negcio, ter contato com pessoas experientes que j
passaram por situaes similares, buscar lies aprendidas de outros projetos e o principal
saber ser lder. Liderana no somente dar ordens, a verdadeira liderana se conquista com
base no servio, saber ouvir a equipe, dar boas condies de trabalho, manter um bom
ambiente na equipe faz com que o Gerente de Projetos no seja visto como somente como um
gerente mas sim como um verdadeiro lder.

26

REFERNCIAS

[1] Project Management Institute, Inc., PMBoK, Guia em Gerenciamento de Projetos

Quarta Edio, 2008.
[2] VARGAS, Ricardo, Gerenciamento de Projetos Estabelecendo Diferenciais
Competitivos,
Rio de Janeiro, Editora Brasport, 2005.
[3] TATA Interactive Systems, TOPSIM, Disponvel em http://www.topsim.com/, ltimo
acesso em 17/12/2012.
[4] FERRAZ, Lucaz, Histrias das Montanhas-Russas, Disponvel em
http://www.cbmr.com.br/index.php/component/content/article/13-artigos/lucas/6-historiamrs
ltimo acesso em 17/12/2012.
[5] JENNY,Juliana, Modelo: Solicitaes de , Disponvel em
http://julianakolb.com/2011/02/23/modelo-solicitacoes-de-mudancas/, ltimo acesso em
17/12/2012.