Gerenciando uma Montanha Russa Inovadora

FACULDADES IBTA

Leonardo Melo de LIMA

GERENCIANDO UM PROJETO DE CONSTRUÇÃO DE UMA
MONTANHA RUSSA

SÃO JOSÉ DOS CAMPOS
2013


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

FICHA CATALOGRÁFICA

LIMA, Leonardo Melo

Gerenciando um Projeto de Construção de uma Montanha Russa / Leonardo Melo de
Lima. 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 em
Gestão de Projetos - PMI. IV. Título.


MONTANHA RUSSA

Monografia apresentada a FACULDADES IBTA
para a conclusão do curso MBA em Gestão de
Projetos - PMI

Aprovado 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

Dedico este trabalho primeiramente a Deus, pois
ele é o meu guia, sustentador e consolador em
todos os momentos de dificuldade. Toda honra e
glória seja dada a ele.
Dedico também a minha família que esteve
comigo em todos os momentos.

AGRADECIMENTOS

Agradeço a Deus por ter me dado condições de concluir este curso. Toda glória e honra seja
dada ao meu Deus. Não poderia deixar de citar também 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 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 eu
chegasse até aqui.

“O planejamento não é uma tentativa de

predizer o que vai acontecer. O planejamento é

um instrumento para raciocinar agora, sobre

que trabalhos e ações serão necessários hoje,

para merecermos um futuro. O produto final do

planejamento não é a informação: é 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 três específicas áreas de
conhecimento: Escopo, Qualidade e Risco. São apresentados análises das tomadas de decisões
durante o projeto bem como as lições aprendidas.

Palavras-chave: Projeto; PMBoK; Decisão; 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 - Situação Inicial do Projeto – EAP .............................................................................. 10
Figura 6 - Evolução de Receita/Custo ......................................................................................... 20
Figura 7 - Evolução de Qualidade e Tecnologia ......................................................................... 21
Figura 8 - Evolução do Lucro ...................................................................................................... 21
Figura 9 - Evolução do Prazo ...................................................................................................... 22
Figura 10 - EAP com Caminho Crítico e Valores Finais ............................................................ 22
Figura 11 - Comparativo Final .................................................................................................... 23

LISTA DE TABELAS

Tabela 1- Situação Inicial do Projeto .......................................................................................... 10
Tabela 2- Relação das Áreas de Conhecimento com Fases do Projeto ....................................... 13
Tabela 3 - Relação entre as Decisões, Processos e Ferramental ................................................. 15

LISTA DE ABREVIATURAS E SIGLAS

EAP – Estrutura Analítica do Projeto.
PMI - Project Management Institute.
PMBoK - Project Management Body of Knowledge.

SUMÁRIO

1. INTRODUÇÃO ................................................................................................................... 1
1.1 Objetivo ................................................................................................................................... 2
1.2 Estrutura do Trabalho .............................................................................................................. 2
2. FUNDAMENTAÇÃO 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. COMEÇANDO 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. HISTÓRIA DA MONTANHA RUSSA ............................................................................. 9
5. APRESENTAÇÃO DOS DADOS INICIAIS .................................................................. 10
6. ESTRATÉGIA DO GRUPO ............................................................................................ 11
7. ÁREAS DE CONHECIMENTO – PMBOK ................................................................... 11
8. ANÁLISE DOS PACOTES ESCOLHIDOS ................................................................... 14
8.1 Especificação 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 LIÇÕES APRENDIDAS. .......... 20
9.1 Viabilidade ............................................................................................................................ 23
9.2 Lições Aprendidas ................................................................................................................. 24
10. CONCLUSÃO................................................................................................................ 25
REFERÊNCIAS ............................................................................................................ 26

1
1. INTRODUÇÃO

Atualmente as instituições estão cada vez mais preocupadas com os custos e
lucros de todas as estruturas organizacionais. A procura pela redução dos custos e busca
por resultados que agregam valor é obrigatório para que uma empresa possa sobreviver
em 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 tornam
muito necessário. E para a realização de tudo isso e muitas outras coisas, as empresas
precisam de projetos.
O desenvolvimento de novos produtos com o auxílio do gerenciamento de
projetos, tem conquistado ótimos resultados, e profissionais com este tipo de
qualificaçã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 renomados
profissionais da área de gestão de projetos criou um guia de melhores práticas
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 serão mostrados neste documento assim como as práticas adotadas ao
longo do projeto.

2

1.1 Objetivo

O objetivo deste trabalho é apresentar as experiências obtidas durante o
desenvolvimento do projeto da montanha russa RockStar, focando em três áreas de
conhecimento 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ão
referente ao software da montanha russa: Especificação do Software, Desenvolvimento
do Software e Teste do Software.

1.2 Estrutura do Trabalho

O Capítulo 2 apresenta os conceitos sobre Gerenciamento de Projetos e as áreas
de conhecimento escolhidas de acordo com o PMBoK[1].
No Capítulo 3 é apresentada uma visão geral sobre o simulador que foi utilizado para
realizar esse trabalho, também no capítulo 3 é possível ver quais são as premissas do
projeto.
O Capítulo seguinte conta a história do surgimento da montanha russa, como
começ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 mostra
qual foi estratégia adotada para o projeto .
No Capítulo 7 é feita uma pequena apresentação das áreas de conhecimento que
foram escolhidas para este trabalho, O oitavo detalha os acontecimentos em três pacotes
de trabalhos do projeto sobre a ótica das três áreas de conhecimento: Escopo, Qualidade
e Risco.
No Capitulo seguinte são mostrados os resultados do projeto assim como a sua
viabilidade e o último capítulo traz a conclusão do trabalho com alguns detalhes do
projeto e finalizando com a utilização do PMBoK[1] no Gerenciamento de Projetos.

3

2. FUNDAMENTAÇÃO DE GERENCIAMENTO DE PROJETOS

2.1 O que é o PMBoK?

O PMBoK[1] é um manual que contém um agrupamento de conhecimentos e boas
práticas do gerenciamento de projetos, atualmente encontra-se na quarta edição, e é mantido
pela instituição Project Management Institute (PMI),
Entende-se como boas práticas um conjunto de métodos que tiveram sucesso em outros
grandes projetos com resultados favoráveis, porém, poderá acontecer que um desses métodos
nã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 logo
abaixo.

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

4

2.2 O que é Gerenciamento de Projetos?

De acordo com o PMBoK[1] o gerenciamento de projetos é uma aplicação de
conhecimento, ferramentas, habilidades e técnicas às atividades do projeto a fim de atender
aos seus requisitos.
Não é obrigatório, porém recomendável que um Gerente de Projetos tenha
conhecimento na área no qual esta gerenciando, por exemplo: Arquiteto trabalhando em um
projeto de construção de um imóvel ou Analista de Sistemas trabalhando em um projeto de
construção de um software, mas como foi dito anteriormente, não há nenhuma regra que
obrigue 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 de
conhecimento, ferramentas, habilidades e técnicas às atividades do projeto a fim de atender
aos seus requisitos. Não é obrigatório, porém recomendável que um Gerente de Projetos tenha
conhecimento na área no qual esta gerenciando, por exemplo: Arquiteto trabalhando em um
projeto de construção de um imóvel ou Analista de Sistemas trabalhando em um projeto de
construção de um software, mas como foi dito anteriormente, não há nenhuma regra que
obrigue 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ção
onde 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 que
colabora com a criação de padrões para o gerenciamento de projetos reunindo-os em seu guia
PMBok[1] mundialmente conhecido, assim como capacitar os profissionais e organizações da
área de gerenciamento de projetos.

5

3. COMEÇANDO O PROJETO

3.1 Como foi Criado o Projeto?

Este projeto foi desenvolvido na disciplina de Business Game do curso de MBA em
Gestão de Projetos PMI da faculdade IBTA.
A finalidade do Business Game é exemplificar aos alunos como é um ambiente de
projeto real desde a fase de iniciação até a fase de encerramento, aplicando os conhecimentos
adquirido em todas as disciplinas já cursadas, fazendo uso das boas práticas de gestão de
projetos segundo o PMBoK[1].

3.2 TOPSIM

Servindo como base para a realização desse projeto, foi utilizado uma ferramenta
denominada TOPSIM.
É um software criado pela empresa alemã Tata[3] Systems e sua finalidade é simular a
realizaçã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 um
Gerente de Projetos como:
Relatório de Custo.
Demonstração do caminho crítico.
Projeção dos pacotes de trabalho e suas dependências.

6

3.3 A Empresa Hypermax Inc

A empresa Hypermax Inc é uma empresa que constrói maquinas mecânicas, e uma de
suas especialidades é a construção de Montanhas Russas.
É Composta aproximadamente por 1000 (um mil) colaboradores, e no último ano
obteve um lucro de 280 milhões de Euros, porém atualmente passa por problemas financeiros
e 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. Podem
ter interesses ou não em sua realização. Neste projeto alguns stakeholders se mostraram
contrários a sua criação como ilustra a Figura 1.

Figura 1 - Problema na Perspectiva dos Stakeholders

7

Além do que apresenta a Figura 1, existem alguns pontos a serem destacados diante do
projeto 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 papel
reforç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

8

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

9

4. HISTÓRIA DA MONTANHA RUSSA

Segundo FERRAZ[4], a montanha russa existe desde o século 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.
Não há nenhum relato de quando foram colocadas as rodas nos carrinhos, mas alguns
historiadores creditam aos franceses os primeiros carrinhos com rodas em 1804, também
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 níquel
pelo passeio a 9,6 km/h num percurso de cerca de 200 metros de extensão e 16,5 de altura
com algumas pequenas colinas no meio.
O negócio foi lucrativo a Thompsom que acabou entrando de vez no negócio dos
parques 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 projetou
montanhas russas na história. Encontra-se exemplos da sua arte em quase todos os países do
mundo. 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é, deitadas
em 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

10

5. APRESENTAÇÃO DOS DADOS INICIAIS

A situação com os valores que iniciaram o projeto esta representada conforme mostra
a 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

11

6. ESTRATÉGIA DO GRUPO

De acordo com os objetivos do projeto, seguindo suas premissas, o grupo teve que
tomar algumas decisões para priorizar alguns pontos estratégicos.
Como era premissa do projeto, um alto nível de qualidade e tecnologia somando-se ao
fato de não extrapolar o custo máximo de 10 milhões de Euros e 65 semanas de duração, o
grupo 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 cumprisse
com as expectativas.
Porém até semana 40, o prazo ainda estava bem maior do que foi estipulado por conta de
alguns 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 no
intuito 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. Neste
trabalho 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.

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 do
projeto.

13

Tabela 2- Relação das Áreas de Conhecimento com Fases do Projeto
Áreas de Conhecimento
Fases 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 - - -

14

8. ANÁLISE DOS PACOTES ESCOLHIDOS

O projeto possuí 46 pacotes de trabalho agrupados nos subsistemas no qual já foi
mencionado. 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 mostra
os processos contidos no PMBoK[1] nas três áreas de conhecimento selecionadas para este
trabalho e as ações utilizadas em cada processo para que o objetivo fosse cumprido. As
ferramentas adotadas foram as mesmas para os três pacotes.
Cada pacote possui 4 alternativas, sendo que a primeira é a alternativa padrão, ou seja o
pacote 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 a
tomada de decisão.

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 do
Pacote 9 – Integrar módulos subprojeto com
que já foram utilizados em documentação dos requisitos
outros 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 de
Pacote 14 – Contratar Qualidade Controle
desenvolvedores 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 Riscos
período de testes
Planejar a Respostas aos Estratégia para riscos
Riscos positivos e negativos
Monitorar e Controlar os Auditorias de riscos
Riscos

16

8.1 Especificação do Software (Pacote 9)

A primeira atividade foi a especificação do software, que teve como responsável a
equipe 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ão
esperados.
A especificação do software é muito importante para que o objetivo seja satisfeito da
melhor maneira. Através dela é possível ter em mãos todos os requisitos, sejam funcionais
como não funcionais que são requeridos pelos stakeholders para o desenvolvimento do
software. 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ódulos
que já foram utilizados em outros projetos, no qual são comprovadamente eficazes e não
precisam de muito desenvolvimento. Tomada essa decisão foram mantidos os valores de
tecnologia e qualidade, aumentamos o custo, porém o prazo foi diminuído.
Entretanto ocorreu um problema, o grupo precisou modernizar os módulos antigos que
são utilizados no novo projeto com novas ferramentas de desenvolvimento. Com essa decisão
aumentamos 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ão
apresentados 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.

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 de
desenvolvimento do software. Esta atribuição também tem como responsável a equipe interna
de TI da instituição.
O desenvolvimento do software é a fase onde desenvolvedores recebem especificações
feitas na fase anterior de especificação do software e tem como objetivo transformar esses
requisitos em um produto real.
O pacote descreve que o monitoramento, controle e sistemas de segurança devem
ser desenvolvidos. Serão usados módulos internos, que serão atualizados em breve.
Como o desenvolvimento do software é de grande responsabilidade para o projeto, pois
o mesmo irá controlar varias funcionalidades, se faz necessário que seja dada uma
importância considerável a esse pacote de trabalho. Outro motivo que gera preocupação é que
serão utilizados alguns módulos internos já existentes para fazerem parte do software . Esses
módulos terão que ser atualizados para atenderem as necessidades atuais.
Devido a complexibilidade o grupo optou por contratar desenvolvedores mais
experientes para esse subprojeto. Essa decisão acarretou em um aumento de custo, porem
houve diminuição de tempo.
Em relação aos processos das áreas de conhecimentos Escopo, Qualidade e Riscos são
apresentados 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.

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 tenha
atingido aos resultados esperados, atendendo os seus requisitos.
Outro objetivo do pacote de teste de software é validar a compatibilidade com outros
softwares 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 do
Software. O pacote tem a seguinte descrição: O módulo de software deve ser testado
validando 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 a
qualidade. Em relação aos processos das áreas de conhecimentos Escopo, Qualidade e Riscos
são apresentados a seguir as justificativas por essa decisão tomada.

19

Escopo: Através de reuniões foi discutido e pensado o que seria mais favorável em
relação 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 mudanças que o grupo realizou em outros
pacotes paralelos priorizando o prazo quase sempre que possível.
Como o prazo já estava controlado, o grupo decidiu por mudar o escopo com essa
decisão colocando o foco na qualidade. Com essa decisão o prazo deste pacote
aumentou em 2 semanas e o investimento realizado ficou um pouco maior do que o
esperado, porém esse pacote não estava no caminho crítico, e isso fez com que não
houvesse perda no prazo do projeto em geral.
Foi realizada uma análise de variação onde foi possível observar o tamanho da mudança
a partir da baseline do escopo garantindo que a alteração não traria muitos impactos ao
projeto tornando-a viável. A alteração foi realizada após aprovação de um comitê de
controle de mudanças e inscritas no registro de mudanças. Segundo Jenny[5], o registro
de 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 aos
projetos. A decisão de aumentarmos o período dos testes do software aumentou
consideravelmente o valor de qualidade no projeto. A equipe realizou reuniões e análise
de 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 realizadas
inspeçõ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 software
e colocando em risco algumas áreas do projeto. Em razão disso, o grupo deu uma
atenção maior a esse pacote para dar mais qualidade e eliminar os riscos. Para isso
utilizou-se do sub processo de “Identificação dos Riscos” que esta na fase de
Planejamento do Projeto. Para identificar e monitorar os riscos foram utilizadas as
técnicas de revisões de documentos do projeto, categorização dos riscos, estratégia para
riscos positivos e negativos e auditoria de riscos.

20

9. RESULTADOS DO PROJETO, VIABILIDADE E LIÇÕES APRENDIDAS.

O objetivo do Business Game é simular o dia a dia de um Gerente de Projetos. O
simulador trás desafios que podem surgir em qualquer projeto real tornando as decisões
importantes 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 seu
ciclo de vida. E como o intuito desse trabalho é simular um projeto real, os resultados
conquistados podem ser vistos em imagens com gráficos 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 relação ao escopo, em razão disso, o grupo focou no
prazo fazendo com que a maioria das ações resultassem no aumento do custo do projeto
porém, diminuindo o tempo como será apresentado posteriormente.

Figura 6 - Evolução de Receita/Custo

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 e
lucro. Porém como já foi apresentado, isso não foi possível, 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 - 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 o
projeto.

Figura 8 - Evolução do Lucro

22

O projeto tinha em seu escopo um prazo de 65 semanas. Devido a priorização deste
quesito, o grupo conseguiu ficar bem próximo do prazo estipulado, entregando o projeto em
66 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 valores
finais.

Figura 10 - EAP com Caminho Crítico 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, também os valores iniciais e os valores finais utilizando como
parâmetros prazo, tecnologia, qualidade custo e lucro.

Figura 11 - Comparativo Final

9.1 Viabilidade

Apesar do orçamento ter ficado em 3.348 milhões de Euros negativos representando
dé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 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 não é comum neste tipo de projeto e dando um
excelente conforto aos clientes. Com uma campanha de marketing eficaz fazendo uso das
mídias sociais, redes sociais, trabalho de divulgação, promoções, sempre informando os
pontos de qualidade e tecnologia, além do fato de ser a maior Montanha Russa da Europa faz
com que o projeto torna-se viável.

24

9.2 Lições Aprendidas

Diante dos resultados apresentados o grupo registrou as suas Lições Aprendidas durante
o 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

25

10. CONCLUSÃO

Como foi visto, o projeto foi entregue com um orçamento superior ao estiuplado, porém
o grupo conseguiu atingir as metas de Qualidade e Técnologia 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 Gestão de Projetos através das boas práticas do PMI utilizando-se
do PMBoK foi fundamental para efetivação do projeto.
As lições aprendidas foram de grande importância a formação do grupo, contribuindo de
forma decisiva no aprendizado na carreira de cada participante.

As lições aprendidas neste projeto foram de grande valor, colaborando de maneira positiva na
realização dos conceitos assimilados.

Conhecer totalmente as prátcas do PMI não quer dizer que terá sucesso em todos os
projetos, é 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 principal
saber ser líder. Liderança não é somente dar ordens, a verdadeira liderança se conquista com
base no serviço, saber ouvir a equipe, dar boas condições de trabalho, manter um bom
ambiente na equipe faz com que o Gerente de Projetos não seja visto como somente como um
gerente mas sim como um verdadeiro líder.

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 Diferenciais
Competitivos,
Rio de Janeiro, Editora Brasport, 2005.

[3] TATA Interactive Systems, TOPSIM, Disponível em http://www.topsim.com/, último
acesso em 17/12/2012.

[4] FERRAZ, Lucaz, Histórias das Montanhas-Russas, Disponível 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: Solicitações de , Disponível em
http://julianakolb.com/2011/02/23/modelo-solicitacoes-de-mudancas/, último acesso em
17/12/2012.

Gerenciando uma Montanha Russa Inovadora

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Gerenciando uma Montanha Russa Inovadora

Semelhante a Gerenciando uma Montanha Russa Inovadora (20)

Gerenciando uma Montanha Russa Inovadora