Estudo de Caso

UNIVERSIDADE DO GRANDE RIO - “Prof.
José de Souza Herdy”

UNIGRANRIO - ESCOLA DE CIÊNCIA E TECNOLOGIA
ENGENHARIA DE PRODUÇÃO
Roberto Carlos Teixeira
Gerenciamento de Projetos:
Corrente Crítica (CCPM) Versus Caminho Crítico (CPM) na Produção
de Equipamentos para a Indústria
Duque de Caxias
2015
Trabalho de Conclusão de Curso apresen-

tado à Universidade do Grande Rio –
“Prof. José de Souza Herdy” como parte
dos requisitos necessários para a obten-
ção do grau de Bacharel em Engenharia
de Produção
Orientador: Prof. Rubens Aguiar Walker, M. Sc.
Duque de Caxias – RJ
2015
ii
CATALOGAÇÃO NA FONTE/BIBLIOTECA – UNIGRANRIO
T266g Teixeira, Roberto Carlos.

Gerenciamento de projetos: Corrente Crítica (CCPM) versus Caminho
Crítico (CPM) na produção de equipamentos para a indústria / Bruno Almeida
de Teixeira / Roberto Carlos Teixeira. – 2015.
119 f. : il., ; 30 cm.
Trabalho de Conclusão de Curso (graduação em Engenharia de

Produção) – Universidade do Grande Rio “Prof. José de Souza
Herdy”, Escola de Ciência e Tecnologia, 2015.
“Orientador: Prof. Rubens Aguiar Walker, M.Sc.”.
Bibliografia: f. 116-119
1. Engenharia de Produção. 2. Administração de projetos. 3. Teoria de

restrições (Administração). 4. Guia do conjunto de conhecimentos em
gerenciamento de projetos (Guia PMBOK). I. Walker, Rubens Aguiar.
II. Universidade do Grande Rio “Prof. José de Souza Herdy”. III. Título.
CDD – 658.5
“Este trabalho reflete a opinião do autor, e não necessariamente a da Associação

Fluminense de Educação - AFE. Autorizo a difusão deste trabalho”.
iii
Trabalho de Conclusão de Curso apresen-

tado à Universidade do Grande Rio –
“Prof. José de Souza Herdy” como parte
dos requisitos necessários para a obten-
ção do grau de Bacharel em Engenharia
de Produção.
Aprovado em_____de________________de______.
__________________________________________
Prof. Rubens Aguiar Walker, M. Sc.
UNIGRANRIO
__________________________________________
Prof. Fabrício da Costa, M. Sc.
UNIGRANRIO
__________________________________________
Prof. Rubens Lopes de Oliveira, D. Sc.
UNIGRANRIO
iv
DEDICATÓRIA
Aos meus pais Carlos Henrique (I.M.) e

Irody, à minha sempre fiel companheira
Elaine e meus filhos Pedro e Cristiano, e a
minha irmã Claudia Cristina e a minha so-
brinha Raisa Cristine.
v
AGRADECIMENTOS
Agradeço em primeiro lugar a Deus, Arquiteto de nossos passos, o Enge-

nheiro mestre de todas as obras, pela conclusão desta modesta lavra.
Agradeço a meu orientador, Prof. Rubens Aguiar Walker, M.Sc., que não só
foi um bom mestre e orientador, mas também um amigo que me conduziu por várias
disciplinas, até chegarmos a esse resultado, mesmo em face das dificuldades.
Agradeço aos professores que nos momentos difíceis ao longo desse curso,
deram incentivos e acreditaram em meu potencial, em especial ao nosso coordena-
dor Prof. Rubens Lopes de Oliveira, D.Sc., pelos inúmeros conselhos e infindável
paciência e incentivo para encontrar as melhores soluções; a Prof.ª Maria Cristina
Ravagnani Gonçalves, Prof.ª Aparecida Cristina Mauro, M. Sc. e Prof. Fabricio da
Costa, M. Sc., que ajudaram a construir os pilares desse projeto; por fim, agradeço
também e muito ao Prof. Leonardo Aragão Guimarães, M.Sc., pelas dicas para dire-
cionar e concluir esse trabalho e a jornada rumo a minha META - graças a ele,
mesmo enfrentando turbulentas e drásticas mudanças de curso, eu consegui supe-
rar e definir a minha CORRENTE CRÍTICA!
Agradeço os meus pais Carlos Henrique (I.M.) e Irody, pelos belos exemplos
de vida, pois mesmo com as escassas possibilidades e muito pelo sacrifício pessoal,
me propiciaram dar valor ao conhecimento e à honestidade.
Agradeço a minha fiel companheira de todas as horas Elaine, pela infinita

paciência das horas roubadas de sua convivência e pelo seu infindável incentivo a
seguir em frente! Agradeço também ao meu filho Pedro, pela inestimável ajuda na
tradução dos inúmeros textos que se não totalmente usados aqui pelo menos me
ajudaram de alguma forma a entender o enfoque da metodologia ser empregada no
Gerenciamento de Projetos pelo Método da Corrente Crítica.
Finalmente, agradeço aos colegas de faculdade, os quais me levaram a ser

um pouco mais flexível na minha forma de pensar e agir, pois este é um capital que
eu levarei comigo para o futuro.
vi
“Aqui, no entanto nós não olhamos para
trás por muito tempo, nós continuamos
seguindo em frente, abrindo novas portas
e fazendo coisas novas, porque somos
curiosos”... E a curiosidade continua nos
conduzindo por novos caminhos...
“Siga em frente!”
(Walter Elias Disney)
vii
RESUMO
O presente trabalho é o resultado de anos de experiência e vários projetos

na indústria de Óleo e Gás no Brasil, relacionados com o projeto e a produção de
sistemas de medição de vazão, e outros processos associados.
Por mais de mais de 20 anos, mesmo com o know-how existente já consoli-

dado e agregado por empresas desta área (e outras), a aplicação de ferramentas
tradicionais de Gerenciamento de Projetos na produção de equipamentos industriais
não é perceptível.
Apesar da experiência inquestionável da empresa abordada nesse estudo

em suas áreas de atuação, seu projeto e fabricação nunca foram gerenciados por
práticas de Gerenciamento de Projetos, como as apresentadas pela PMI no seu
Guia PMBOK®.
Também se verifica que por não usar adequadamente nenhuma ferramenta

de Gerenciamento de Projetos (nem o Método do Caminho Crítico da PMI e nem o
Método da Corrente Crítica da Teoria das Restrições), isto resulta em falhas no Ge-
renciamento de Tempo dos Projetos desta empresa, como será visto neste trabalho.
O propósito final deste trabalho consiste em apresentar estas ferramentas de

Gerenciamento de Projetos e explicar seu uso na solução dos problemas de gestão
do tempo descritos. Acredita-se que, após introduzi-las, todos se convencerão de
que essa meta é possível, plausível e realizável.
Palavras-chave:
Gerenciamento de Projetos; Teoria das Restrições; Corrente Crítica; PMBOK®.
viii
ABSTRACT
The present work is the result of years of experience and several projects in
the Oil industry in Brazil, related to the design and production of flow measurement
systems, and other associated processes.
For over more than 20 years, despite the existing know-how already consoli-
dated and aggregated by companies in this area (and others), the application of Pro-
ject Management traditional tools in the industrial equipment production is not notice-
able.
Despite the unquestionable experience of the company in their areas cov-

ered in this study, their designs and productions have never been managed by Pro-
ject Management practices, as presented by the PMI in its PMBOK® Guide.
It is also noted that due to not properly using any Project Management Tool
(neither the PMI Critical Path Method nor the TOC Critical Chain method); this results
in faults in the company's Project Time Management, as will be seen in this study.
The ultimate objective of this paper is to present these tools of Project Man-
agement and explain their use in the solution of the time management’s described
problems. It is believed that, after introducing them, everyone will be convinced that
this goal is possible, plausible and viable.
Keywords:
Project Management; Theory of Constraints; Critical Current; PMBOK®.
ix
LISTA DE FIGURAS
Figura 2-1 - Interações na gestão de portfólios, programas e projetos ................................................ 34
Figura 2-2 - Grupos de processos de gerenciamento de projetos........................................................ 36
Figura 2-3 - Grupos de processos interagem em uma fase ou projeto ................................................ 37
Figura 2-4 - Interações nos processos de gerenciamento de projetos ................................................. 38
Figura 2-5 - Limites do projeto .............................................................................................................. 39
Figura 2-6 - Fluxo de dados, de informações e de relatórios do projeto .............................................. 40
Figura 2-7 - Visão geral do gerenciamento do tempo do projeto.......................................................... 43
Figura 2-8 - Visão geral do desenvolvimento do cronograma .............................................................. 44
Figura 2-9 - Processo: Planejar o gerenciamento................................................................................. 45
Figura 2-10 - Processo: Definir as atividades ....................................................................................... 45
Figura 2-11 - Processo: Sequenciar atividades .................................................................................... 46
Figura 2-12 - Processo: Estimar os recursos ........................................................................................ 46
Figura 2-13 - Processo: Estimar durações ............................................................................................ 47
Figura 2-14 - Processo: Desenvolver o cronograma ............................................................................ 48
Figura 2-15 - Exemplo de método do caminho crítico .......................................................................... 49
Figura 2-16 - Exemplo de método da corrente crítica ........................................................................... 50
Figura 2-17 - Nivelamento de recursos ................................................................................................. 51
Figura 2-18 - Cronograma de barras do projeto (Diagrama de Gantt) ................................................. 53
Figura 2-19 - Cronograma de marcos do projeto .................................................................................. 53
Figura 2-20 - Cronograma de resumo do projeto (gráfico de barras) ................................................... 54
Figura 2-21 - Processo: Controlar o cronograma.................................................................................. 55
Figura 2-22 - Problemas mais frequentes em projetos. ........................................................................ 63
Figura 2-23 - Habilidades necessárias/valorizadas ao gerenciar projetos. .......................................... 64
Figura 2-24 - Principais deficiências dos gerentes de projetos. ........................................................... 64
Figura 2-25 - Frequência de problemas relacionados ao cumprimento dos prazos estabelecidos. .... 65
Figura 2-26 - Sem multitarefa X Com multitarefa.................................................................................. 69
Figura 2-27 - Curva de distribuição do tempo de atividades imaginada ............................................... 71
Figura 2-28 - Curva de distribuição do tempo de atividades real ......................................................... 71
Figura 2-29 - Efeito cascata do contingenciamento no tempo das atividades ..................................... 72
Figura 2-30 - Como as pessoas tentam se proteger pelo contingenciamento ..................................... 76
Figura 2-31 - O que efetivamente ocorre graças à Síndrome do Estudante ........................................ 76
Figura 2-32 - Probabilidade de eventos dependentes (Atividades Sequenciais) ................................. 77
Figura 2-33 - Probabilidade de eventos dependentes (Atividades Paralelas) ...................................... 78
Figura 2-34 - Probabilidade de eventos dependentes (Paralelas)........................................................ 79
Figura 2-35 - O problema da dependência de recursos compartilhados .............................................. 79
Figura 2-36 - O desafio de gerenciar múltiplos projetos ....................................................................... 83
Figura 2-37 - As Cinco Etapas de Enfoque ........................................................................................... 84
Figura 2-38 - Tarefas com segurança adicional.................................................................................... 87
Figura 2-39 - O Caminho Crítico (em vermelho) ................................................................................... 89
x
Figura 2-40 - A Corrente Critica (em vermelho) .................................................................................... 89
Figura 2-41 - Corrente Critica com Pulmões......................................................................................... 89
Figura 2-42 - Fim da tarefa e o consumo do pulmão (2º Dia) ............................................................... 90
Figura 2-43 - Fim da tarefa e consumo do pulmão (3º dia) .................................................................. 90
Figura 2-44 - O gráfico de tendência (ou gráfico “febril”) ...................................................................... 91
Figura 2-45 - Gráfico de tendências da taxa de conclusão .................................................................. 92
Figura 2-46 - Gráfico de tendências - Mudanças na Razão Crítica ...................................................... 92
Figura 3-1 - Linha do tempo da “KBR OIL & GAS LTDA.” .................................................................... 94
Figura 3-2 - Market Share da “KBR OIL & GAS LTDA.” ....................................................................... 95
Figura 3-3 - Diagrama do mercado local da “KBR OIL & GAS LTDA.”................................................. 96
Figura 3-4 - Análise SWOT da “KBR OIL & GAS LTDA.” ..................................................................... 96
Figura 3-5 - Formatos de definição dos papéis e responsabilidades ................................................. 101
Figura 3-6 - Matriz RACI ..................................................................................................................... 101
Figura 3-7 - Organograma - “KBR OIL & GAS LTDA.” ....................................................................... 102
Figura 3-8 - As sete ferramentas de gerenciamento da qualidade ..................................................... 104
Figura 3-9 - Cronograma sem Corrente Crítica - UO-SKID.01 ........................................................... 106
Figura 3-10 - Cronograma sem Corrente Crítica - UO-SKID.02 ......................................................... 107
Figura 3-11 - Gráfico dos Prazos Máximos......................................................................................... 108
Figura 3-12 - Gráfico Atrasos x Adiantamentos .................................................................................. 109
Figura 3-13 - Cronograma com Corrente Crítica - UO-SKID.01 ......................................................... 110
Figura 3-14 - Cronograma com Corrente Crítica - UO-SKID.02 ......................................................... 110
xi
LISTA DE TABELAS
Tabela 2-1 - Grupo de processos e mapa das áreas de conhecimento ............................................... 41
Tabela 3-1 - Detalhamento dos Setores de Atuação no Market Share da “KBR.” ............................... 95
Tabela 3-2 - Detalhamento dos marcadores de entregas do contrato da “KBR” com a “EPC” ............ 99
Tabela 3-3 - Impacto das Estimativas com as Contingências nos Marcos do Projeto ....................... 108
Tabela 3.4 - Amostras de aplicações do Método da Corrente Crítica ................................................ 114
xii
LISTA DE ABREVIATURAS E SIGLAS
CCPM - Critical Chain Project Management

(Gestão de Projetos pela Corrente Crítica)
CCM - Critical Chain Method (Método da Corrente Crítica)
CPM - Critical Path Method (Método do Caminho Crítico)
EMED - Estação de Medição de Vazão / Estação de Medição Fiscal
EPC - Engineering, procurement and construction
(Engenharia, Aquisições e Construção) - em resumo: Empreiteiras.
No âmbito do trabalho, empresa fictícia, contratante da “KBR”, em-
presa fictícia objeto do estudo de caso, inspirada em EPC real oriun-
da do mercado de fornecedores para o Setor de Óleo e Gás Natural.
FB - Feed Buffer ou Pulmão de Alimentação
ISP - Indústria de São Paulo - empresa fictícia inspirada em empresa real
que atuava como prestadora de serviços de fabricação de EMEDs
para a “KBR” em seus fornecimentos.
KBR - Empresa “K” brasileira - empresa fictícia inspirada em empresa real
oriunda do mercado de fornecedores do Setor de Óleo e Gás Natural.
PERT - Program Evaluation and Review Technique
(Técnica de Revisão e Avaliação de Programas)
PB - Project Buffer ou Pulmão de Projeto
PIB - Produto Interno Bruto
PMBOK® - Project Management Book of Knowledge
(Guia do Conhecimento em Gerenciamento de Projetos)
PMI - Project Management Institute
ToC - Theory of Constraints (Teoria das Restrições)
xiii
SUMÁRIO
1 INTRODUÇÃO ....................................................................................17
1.1 PROBLEMA ...................................................................................................... 24

1.2 OBJETIVOS ...................................................................................................... 25
1.2.1 Objetivo Geral .................................................................................... 25
1.2.2 Objetivos Específicos ......................................................................... 26
1.2.3 Delimitação do Estudo ....................................................................... 26
1.3 JUSTIFICATIVA ................................................................................................ 27
1.4 METODOLOGIA ............................................................................................... 28
1.4.1 Quanto aos fins .................................................................................. 28
1.4.2 Quanto aos meios .............................................................................. 29
1.4.3 Universo pesquisado .......................................................................... 30
1.4.4 Amostra .............................................................................................. 30
1.4.5 Seleção dos sujeitos .......................................................................... 30
1.4.6 Coleta de dados ................................................................................. 30
1.4.7 Tratamento dos dados ....................................................................... 31
1.4.8 Limitações do Método ........................................................................ 31
1.5 ESTRUTURA DO TRABALHO ......................................................................... 31
2 METODOLOGIA DO GERENCIAMENTO DE PROJETO .................33
2.1 DEFINIÇÕES E RELACIONAMENTOS ............................................................ 33

2.1.1 Portfólios ............................................................................................ 34
2.1.2 Programas.......................................................................................... 34
2.1.3 Projetos .............................................................................................. 34
2.2 DEFININDO O GERENCIAMENTO DE PROJETOS........................................ 35
2.2.1 Processos de Gerenciamento de Projetos ......................................... 35
2.2.1.1 Interações comuns ................................................................ 36
2.2.2 Processos de gerenciamento de projetos .......................................... 37
2.2.2.1 Processos de iniciação .......................................................... 38
2.2.2.2 Processos de planejamento .................................................. 39
2.2.2.3 Processos de execução ........................................................ 39
2.2.2.4 Processos de monitoramento e controle ............................... 39
2.2.2.5 Processos de encerramento .................................................. 40
xiv
2.2.3 Informações do projeto ...................................................................... 40
2.2.4 Papel das áreas de conhecimento ..................................................... 41
2.3 GERENCIAMENTO DO TEMPO DO PROJETO .............................................. 42
2.3.1 Planejar o gerenciamento do cronograma ......................................... 44
2.3.2 Definir as atividades ........................................................................... 45
4.1.1 Sequenciar as atividades ................................................................... 46
2.3.3 Estimar os recursos das atividades.................................................... 46
2.3.4 Estimar as durações das atividades................................................... 47
2.3.5 Desenvolver o cronograma ................................................................ 47
2.3.5.1 Método do caminho crítico .................................................... 48
2.3.5.2 Método da corrente crítica ..................................................... 49
2.3.5.3 Técnicas de otimização de recursos ..................................... 51
2.3.5.4 Ferramenta de cronograma ................................................... 52
2.3.5.5 Linha de base do cronograma ............................................... 52
2.3.5.6 Cronograma do projeto.......................................................... 52
2.3.5.7 Dados do cronograma ........................................................... 54
2.3.6 Controlar o cronograma ..................................................................... 54
2.4 ANALISANDO O PROBLEMA .......................................................................... 55
2.5 METODOLOGIA DA CORRENTE CRÍTICA ..................................................... 59
2.7 A IMPLANTAÇÃO DA METODOLOGIA ........................................................... 82
2.7.1 A Natureza dos Riscos e da Complexidade ....................................... 83
2.7.2 As Cinco Etapas de Enfoque ............................................................. 84
2.7.2.1 Explorar a restrição ............................................................... 85
2.7.2.2 Subordinar a restrição ........................................................... 85
2.7.2.3 Elevar a restrição................................................................... 86
2.7.2.4 Não permitir que a inércia se torne a restrição ...................... 87
2.7.3 O Método da Corrente Critica ............................................................ 87
2.7.4 Razão Crítica ..................................................................................... 91
3 ESTUDO DE CASO ............................................................................93
3.1 DESCRIÇÃO DA EMPRESA ............................................................................ 93

3.2 HISTÓRICO DA EMPRESA ............................................................................. 94
3.3 MERCADO DE ATUAÇÃO ............................................................................... 94
3.3.1 Estrutura do mercado ......................................................................... 95
xv
3.3.2 Análise “SWOT” ................................................................................. 96
3.4 PROBLEMAS DO GERENCIAMENTO DE PROJETO ..................................... 97
3.5 ANÁLISE DO PROBLEMA ............................................................................... 97
3.5.1 Aplicando a Corrente Crítica .............................................................. 98
3.5.2 Aspectos que impactam na gestão .................................................... 98
3.5.2.1 Objeto do contrato ................................................................. 98
3.5.2.2 Cronograma do Projeto ......................................................... 99
3.5.2.3 Requisitos e Escopo ............................................................ 100
3.6 AVALIAÇÃO DAS FERRAMENTAS DE GESTÃO ......................................... 101
3.6.1 Ferramentas de Planejamento da Gestão de Recursos .................. 101
3.6.1.1 Estrutura Organizacional ..................................................... 101
3.6.2 Ferramentas de Planejamento da Gestão da Qualidade ................. 103
3.6.2.1 Listas de verificação da qualidade....................................... 104
3.6.2.2 Realização da garantia da qualidade .................................. 104
3.6.3 Cronograma do projeto sem a corrente crítica ................................. 106
3.6.4 Cronograma do projeto com a corrente crítica ................................. 109
3.7 RESULTADOS................................................................................................ 111
3.8 FERRAMENTAS DA CORRENTE CRÍTICA EXISTENTES ........................... 112
3.9 BENEFÍCIOS DAS APLICAÇÕES DA CORRENTE CRÍTICA ........................ 113
4 CONSIDERAÇÕES FINAIS..............................................................115
4.1 PERSPECTIVA E PROPOSTAS .................................................................... 115
5 REFERÊNCIA BIBLIOGRÁFICA .....................................................116
6 BIBLIOGRAFIA RECOMENDADA ..................................................119
xvi
17
1 INTRODUÇÃO
Nos tempos atuais, nos mais diversos aspectos da vida humana, sejam eles
culturais, tecnológicos, políticos, econômicos, sociais, etc., estão ocorrendo mudan-
ças significativas e cada vez mais rapidamente. De uma maneira geral, todos asso-
ciam as mudanças ao resultado de projetos (VIEIRA, 2002). Como resultado disso,
pode-se afirmar que gerenciar projetos de uma maneira eficiente nesses tempos de
grandes mudanças é um dos maiores desafios do executivo moderno (KERZNER,
2001). Ter como meta a superação deste desafio é estar qualificado para atuar no
gerenciamento de projetos de uma forma planejada e profissional.
Dessa forma, o gerenciamento de projetos é citado por diversos autores co-

mo uma profissão de certa forma nova e emergente. A razão disto é o fato de que
várias organizações, públicas e privadas, instituições de pesquisa e ensino, entre
outras, estarem estudando, conhecendo, difundindo, capacitando, implantando e
evoluindo o conhecimento, as metodologias, as práticas e as ferramentas emprega-
das nesta área e profissão (PMI, 2000).
A atuação de qualquer profissional requer conhecimento especial e uma

preparação longa e intensiva geralmente, proporcionada através da formação aca-
dêmica em cursos de graduação e pós-graduação. O desenvolvimento das habilida-
des e a obtenção do nível de profissionalismo compatível com a função de gerente
de projetos incorrem no aprendizado de conceitos básicos, técnicas e ferramentas
de gerenciamento assim como a sua prática.
As organizações, com o objetivo de colher os benefícios esperados, devem

ser conscientizadas na adoção do gerenciamento de projetos não somente como
uma função, mas como uma metodologia pela quais os seus gerentes sejam ade-
quadamente treinados, agregando assim valor as suas experiências individuais. O
gerenciamento de projetos deve ser realizado profissionalmente e conduzido por
pessoal qualificado. Por esta razão, deve ser criada a cultura de projetos nas organi-
zações, e sua implantação serem realizada sistematicamente, com os seus princí-
pios colocados em prática da maneira mais adequada as suas necessidades.
18
As organizações modernas inseridas em um ambiente globalizado, e cada

vez mais competitivo, estando sujeitas às rápidas e grandes mudanças, precisam
mais e mais inovar os seus produtos e serviços. Assim, a preparação de profissio-
nais no menor espaço de tempo, de forma competente, com qualidade e a custos
reduzidos, para atuar com sucesso no gerenciamento de projetos aparece como
conseqüência das exigências do cenário atual.
Projeto é um instrumento fundamental para qualquer atividade de mudança

e geração de produtos e serviços. Eles podem envolver desde uma única pessoa a
milhares de pessoas organizadas em times e ter a duração de alguns dias ou vários
anos (DINSMORE e CAVALIERI, 2003).
Um projeto é um empreendimento único, com início e fim definidos, que utili-

za recursos limitados e é conduzido por pessoas, visando atingir metas e objetivos
pré-definidos estabelecidos dentro de parâmetros de prazo, custo e qualidade (PMI,
2000).
O projeto pode ser definido por características distintas como temporário, ú-

nico e progressivo. A característica de ser temporário é muito importante, pois todo
projeto tem um início e um fim definidos. O projeto termina quando os objetivos para
o qual foi criado são atingidos ou quando se torna claro que os objetivos do projeto
não serão ou não poderão mais ser atingidos ou a necessidade do projeto não existe
mais (PMI, 2000).
Ser único significa que todo produto ou serviço gerado por um projeto é dife-
rente de outros produtos e serviços. Os projetos envolvem a realização de algo ja-
mais realizado anteriormente e logo é único. Um projeto é progressivo porque a me-
dida que é mais bem compreendido, ele é progressivamente elaborado, ou seja,
maior é o detalhamento das características peculiares que o distinguem como único
(PMI, 2000). Segundo o PMI, o gerenciamento de projetos é a aplicação de conhe-
cimentos, habilidades, ferramentas e técnicas para projetar atividades que visem
atingir os requisitos do projeto.
19
Para facilitar o gerenciamento do projeto ele deve ser dividido em fases que
constituem seu ciclo de vida (DINSMORE e CAVALIERI, 2003).
A gestão de projetos envolve criar um equilíbrio entre as demandas de es-

copo, tempo, custo, qualidade e bom relacionamento com o cliente. O sucesso na
gestão de um projeto está relacionado ao alcance dos seguintes objetivos: entrega
dentro do prazo previsto, dentro do custo orçado, com nível de desempenho ade-
quado, aceitação pelo cliente, atendimento de forma controlada às mudanças de
escopo e respeito à cultura da organização (PMI, 2000).
Os projetos vêm sendo realizados desde os primórdios da civilização. A

construção das Pirâmides do Egito, depois de 2780 a.C. (VICENTINO, 1997), por
exemplo, foi um grande projeto. Os projetos têm sido planejados e executados pelas
organizações para criar novos produtos e serviços e introduzir mudanças e inova-
ções nos seus processos. Porém, para que um projeto seja realizado de forma efi-
caz, é necessária a organização do trabalho demandado (MARTINS; ALT, 2009).
O gerenciamento de projetos, em sua forma moderna, começou a se estabe-

lecer somente há algumas décadas. No início dos anos 60, as empresas começaram
a perceber o benefício de organizar o trabalho como projetos. Essa visão centraliza-
da no projeto da organização evoluiu ainda mais, à medida que as organizações
começaram a entender a necessidade crítica de seus funcionários se comunicarem
e colaborarem ao mesmo tempo em que integram seu trabalho em vários departa-
mentos e profissões e, em alguns casos, setores inteiros (MICROSOFT, 2010).
Voltando até a última metade do século XIX, quando o mundo comercial es-
tava se tornando cada vez mais complexo, pode-se saber como o gerenciamento de
projetos evoluiu a partir dos princípios básicos de gerenciamento. Grandes projetos
governamentais de larga escala foi o ímpeto para as decisões importantes que se
tornaram a base para a metodologia do gerenciamento de projetos (MICROSOFT,
2010).
20
Nos Estados Unidos, por exemplo, o primeiro projeto governamental verda-

deiramente grande foi à ferrovia transcontinental, que começou a ser construída na
década de 1860. De repente, líderes de empresas se viram diante da tarefa assus-
tadora de organizar trabalho manual de milhares de trabalhadores e processamento
e montagem de quantidades sem precedentes de matéria-prima (MICROSOFT,
2010).
Perto da virada do século, Frederick Taylor (1856–1915) iniciou seus estu-

dos detalhados do trabalho. Ele aplicou raciocínio científico ao trabalho mostrando
que a mão-de-obra pode ser analisada e aperfeiçoada com a ênfase em seus ele-
mentos fundamentais. Ele aplicou seu raciocínio às tarefas encontradas nas usinas,
como coleta de areia e levantamento e mudança de peças. Antes disso, a única ma-
neira de melhorar a produtividade era exigir trabalho mais árduo e mais horas dos
trabalhadores. Taylor introduziu o conceito de trabalhar com mais eficiência, em vez
de trabalhar mais arduamente e mais horas. A inscrição no túmulo de Taylor na Fila-
délfia comprova seu lugar na história do gerenciamento: "O pai do gerenciamento
científico" (MICROSOFT, 2010).
O sócio de Taylor, Henry Gantt (1861-1919), estudou em grande detalhe a

ordem das operações no trabalho. Seus estudos de gestão forma voltados para
construção de navios da Marinha americana durante a Primeira Guerra Mundial. Os
seus gráficos de Gantt, completos, com barras de tarefas e marcadores, delineiam a
seqüência e a duração de todas as tarefas de um processo (MICROSOFT, 2010).
Os Diagramas de Gráfico de Gantt provaram ser uma poderosa ferramenta

analítica para os gestores de tal forma que eles permaneceram praticamente inalte-
rados durante quase cem anos (MICROSOFT, 2010).
Não foi realizada qualquer alteração até a década de 90, onde linhas de li-
gação (ligações lógicas) foram acrescentadas às barras de atividades, as quais des-
crevem as dependências mais precisas entre as atividades. Hoje, o legado de Henry
Gantt é lembrado por uma medalha oferecida em seu nome pela Sociedade Ameri-
cana de Engenheiros Mecânicos (MICROSOFT, 2010).
21
Taylor, Gantt, e outros ajudaram a tornar o gerenciamento de projetos uma

função empresarial distinta que requer estudo e disciplina. Nas décadas que levaram
à Segunda Guerra Mundial, métodos de marketing, psicologia industrial e relações
humanas começaram a despontar como partes integrantes do gerenciamento de
projetos (MICROSOFT, 2010).
Durante a segunda Guerra Mundial, projetos militares e governamentais

complexos e uma mão-de-obra reduzida pela guerra exigiram novas estruturas or-
ganizacionais. Diagrama de Rede complexos, denominados gráficos de análise
PERT (Program Evaluation and Review Technique) e o Método do Caminho Crítico
(CPM) foram introduzidos, proporcionando aos gerentes mais controle sobre projetos
com muita engenharia e muito complexos (como os sistemas de armas militares com
sua grande variedade de tarefas e numerosas interações em muitos pontos no tem-
po). (MICROSOFT, 2010)
Logo, essas técnicas se espalharam por todos os tipos de indústrias, à me-

dida que os líderes empresariais buscaram novas estratégias de gerenciamento e
novas ferramentas para lidar com o crescimento em um mundo em rápida evolução
e altamente competitivo. No início dos anos 60, as empresas começaram a aplicar
teorias de sistema gerais às interações comerciais. Em seu livro, A teoria e o geren-
ciamento de sistemas, Richard Johnson, Fremont Kast e James Rosenzweig des-
creveram como uma empresa moderna é como um organismo humano, com um es-
queleto, um sistema muscular, um sistema circulatório, um sistema nervoso etc.
(MICROSOFT, 2010).
Na década de 60, o gerenciamento de projetos é formalizado como ciência.

Os negócios e outras organizações passam a perceber o benefício da organização
do trabalho com base em projetos e compreende a necessidade crítica de se comu-
nicar e se integrar este trabalho através de diversos departamentos e profissões. Em
1969, com o crescimento dos projetos espaciais da NASA, uma equipe composta
por cinco profissionais de gestão de projetos, oriundos da Philadelphia, Pensilvânia,
nos Estados Unidos, se reúne para discutir as melhores práticas e Jim Snyder funda
o Project Management Institute - PMI (EUA) (PMI, 2004).
22
O PMI é considerado a maior instituição internacional dedicada a dissemina-

ção do conhecimento e ao aprimoramento das atividades de gestão profissional de
projetos atualmente (PMI, 2004).
Hoje, o gerenciamento de projetos está se fortalecendo cada vez mais. As

organizações entendem que precisam gerenciar projetos para obterem sucesso. O
PMI estima que aproximadamente 25% do PIB mundial são gastos em projetos e
que cerca de 16,5 milhões de profissionais estão envolvidos diretamente com geren-
ciamento de projetos no mundo. Este volume de projetos e as mudanças no cenário
mundial, cada vez mais competitivo, vêm gerando a necessidade de resultados mais
rápidos, com qualidade maior e custo menor. (DINSMORE e CAVALIERI, 2003).
Para balizar o gerenciamento de projetos, o PMI ao longo dessas décadas

foi sistematizando um conjunto de processos para orientar a gestão de projetos, o
qual acabou sendo condensado em um guia completo. O PMBOK® (PMI, 2013) é
um guia de boas práticas na Gestão de Projetos idealizado e organizado pelo PMI e
considerado a base do conhecimento padrão sobre Gestão de Projetos.
O PMBOK® foi inicialmente publicado pelo PMI como uma recomendação

técnica (1983) na tentativa de documentar e padronizar as práticas que são normal-
mente aceitas na gerência de projetos. Em 2012 foi lançada a quinta edição em In-
glês, com traduções em diversos idiomas incluindo-se Português e Espanhol.
O PMBOK® identifica um subconjunto do conjunto de conhecimentos em ge-

renciamento de projetos, amplamente reconhecido como boa prática, sendo utilizado
como base pelo PMI. Isto não significa que o conhecimento e que as práticas devem
ser aplicadas uniformemente em todos os projetos, sem considerar ou não a sua
apropriação.
O PMBOK® fornece e promove um vocabulário comum para discutir, escre-

ver e aplicar o gerenciamento de projetos com o intercâmbio eficiente de informa-
ções entre os profissionais.
23
O PMBOK provê diretrizes para gerência dos projetos individualmente e de-

fine conceitos associados a gerência de projetos. Isto também descreve o ciclo de
vida do gerenciamento do projeto e seus processos relacionados, assim como o ci-
clo de vida do projeto. (PMI, 2013).
Acompanhando o desenvolvimento das técnicas de gerenciamento da pro-

dutividade nas diversas áreas, outras condições foram avaliadas como problemas
cruciais a serem resolvidos. Uma dessas condições avaliadas nesse período foi a de
como quebrar o paradigma da limitação (restrição) de produtividade quando todos os
recursos disponíveis já foram esgotados e praticamente não se conseguem encon-
trar soluções para atender a demanda cada vez maior por resultados. É nesse con-
texto que surge a Teoria das Restrições.
A Teoria das Restrições (TOC) é um paradigma de gestão que considera

qualquer sistema gerenciável como sendo limitado em alcançar a maioria de seus
objetivos por um número muito pequeno de restrições.
A TOC foi concebida para auxiliar organizações a alcançar seus objetivos

continuamente. São fundamentados em um conjunto de princípios básicos ou axio-
mas, alguns processos simples (Perguntas Estratégicas, Etapas de Foco, Efeito-
Causa-Efeito), ferramentas lógicas (o Processo de Raciocínio) e são aplicáveis atra-
vés da dedução lógica a áreas específicas como finanças, logística, gerência de pro-
jetos, administração de pessoas, estratégia, vendas, marketing e produção.
De acordo com a TOC, toda organização tem - em um dado momento no

tempo - pelo menos uma restrição que limita o desempenho do sistema (a organiza-
ção em questão) em relação a sua meta. Essas restrições podem ser classificadas
como restrições internas e restrições externas, ou de mercado.
A TOC está sendo aplicada com sucesso em diversos contextos: manufatu-

ra, logística e distribuição, cadeia de suprimentos, gerenciamento de projetos, mar-
keting e vendas, contabilidade, prestação de serviços, tecnologia da informação, en-
genharia de software, saúde, educação, vida pessoal, etc.
24
A TOC também serve como um excelente ponto de partida para outras me-
todologias de gerenciamento, como Lean e Seis Sigma.
1.1 PROBLEMA
É um fato bastante conhecido na área de Engenharia (principalmente na

produção de equipamentos para a indústria de Óleo e Gás Natural), situações que
incorrem em atrasos de projetos, quebras de contratos, etc., e que podem ser resu-
midas nesta pergunta: “Porque todo projeto acaba atrasando?”.
É preciso abordar melhor essa questão e de forma mais abrangente para

analisar a mesma com precisão e propor a implantação soluções para a mesma, a
quem ela possa ser útil. Então se percebe que ela se torna mais específica, sendo
necessário reformulá-la: “Por que os projetos atrasam e o que fazer sobre isso?”.
Diante desse paradigma, necessita-se entender que o problema apresenta-

do tem causas e consequências. Resumindo, esse problema consiste de fatos que
tem uma (ou mais) precedência(s), que levam a uma cadeia de eventos subsequen-
tes e finalmente produzem consequências que afetam o objetivo final dos projetos.
Citando ELDER (2006): “Como é possível completar mais projetos, mais rá-
pido, sem sacrificar a qualidade ou o escopo, quando seus recursos já estão mais do
que sobrecarregados?”.
O texto acima questiona se os projetos das partes interessadas sofrem de

algum dos seguintes efeitos indesejáveis:
• Atrasados.
• Recursos sobrecarregados.
• Mudanças em excesso (longos prazos).
• Recursos não disponíveis quando necessários (mesmo sendo assegurados).
• Prioridades mutáveis.
• Retrabalho.
25
Pela observação prática ao longo de anos de trabalho, prática e pesquisa na

área, foi observado que os projetos passam realmente pelas situações recorrentes
apresentadas acima.
O problema consiste de visão equivocada de gestão. As empresas dessa

área de negócios atuam com produção de baixa escala, alta variabilidade de produ-
tos e grande diversificação de projetos (cada pedido, ou negócio, é “um projeto” por
assim dizer).
Em essência, as empresas dessa área de negócios até podem atuar com

produção de larga escala e fornecer produtos feitos como projetos padronizados em
produtos, com processos próprios de fabricação, definidos, proporcionando maior
ganho efetivo, maior produtividade, e maior lucro para a empresa.
Para isto, as ferramentas de Gestão de Projeto da Engenharia de Produção,

tais como o método do Caminho Crítico (CPM) e o método da Corrente Crítica
(CCPM) podem ser uma solução efetiva de produtividade e gerenciamento.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O principal objetivo deste estudo é o de apresentar uma proposta de solução

aos problemas de gestão de prazos e de custos enfrentados por estas empresas na
gestão de projeto e produção de equipamentos para a área industrial, abordando-os
pela gestão do tempo através da comparação e/ou combinação do Método CCPM
(Corrente Crítica) versus Método CPM (Caminho Crítico).
26
1.2.2 Objetivos Específicos
Os objetivos específicos deste projeto consistirão em:
1. Propor um processo de gestão do tempo adequado as necessidades das indús-

trias e fabricantes de equipamentos para as indústrias de Óleo e Gás, de forma a
atender a demanda básica de gestão de projetos, aplicáveis para a produção de
equipamentos de processos industriais destinados ao setor de Óleo e Gás e de
outras áreas de processos industriais correlatas.
2. Detalhar diagnósticos de problemas que afetam o Gerenciamento de Projetos,

aplicando-se o Processo de Raciocínio da Teoria das Restrições, com foco no
Método da Corrente Crítica.
3. Identificar os 5 sintomas (ou arquétipos) do “mau” gerenciamento de projetos, a

saber:
• Multitarefa nociva
• Síndrome do Estudante (ou Procrastinação)
• Lei de Parkinson
• Dependência entre Tarefas
• Matemática do Gerenciamento de Projetos.
4. Apresentar os benefícios do uso da corrente crítica através de exemplos de apli-

cação de outras empresas
1.2.3 Delimitação do Estudo

Para se tratar especificamente da solução proposta para o problema dos a-
trasos em projetos aplicando-se os dados coletados sobre a empresa objeto do es-
tudo de caso serão abordados diretamente os cinco sintomas críticos citados acima
que em geral afetam o Gerenciamento do Tempo do Projeto. O enfoque dessa abor-
dagem será realizado em função da área de conhecimento do gerenciamento de
projetos delimitada pelo Gerenciamento do Tempo.
27
Não serão abordados os demais aspectos do gerenciamento de projetos a-

brangidos pelas demais áreas de conhecimento definidas pelo PMBOK® (Integra-
ção, Escopo, Custos, Qualidade, Recursos Humanos, Comunicações, Riscos, Aqui-
sições e Partes Interessadas). Oportunamente, poderão ser citados ou abordados
pontualmente para explicar algum ponto relacionado com o contexto, mas sem se
entrar nas especificidades da área(s) de conhecimento citada(s).
1.3 JUSTIFICATIVA
A justificativa do trabalho baseia-se na conclusão de que a Engenharia de

Produção pode proporcionar a todas as empresas, conhecimentos essenciais sobre
a gestão de projetos que as capacitem para a máxima eficiência. A Engenharia de
Produção pode oferecer a estas empresas ferramentas tais como Gestão de Proje-
tos, Planejamento e Controle da Produção, etc., permitindo alavancar um novo pa-
tamar de importância para aproveitamento dos profissionais da área nas empresas.
Estas ferramentas corretamente aplicadas podem ajudar a estas organiza-

ções a maximizarem resultados, eliminando desperdícios, ajustando lucratividade e
a eficiência com a melhoria do uso de recursos e apresentando produtos com quali-
dade superior.
A principal característica das empresas de engenharia é que são organiza-

ções com expressiva rotatividade de “mão-de-obra”, com pouca gestão de projetos
(como a conhecemos efetivamente), e estão mais focadas em atender exigências
contratuais e cumprir das normas de produção da Engenharia dos clientes do que
aplicar ações de melhoria dos processos de produção. Percebe-se, portanto, que as
empresas não conseguem ver a sua atuação como empreendimentos industriais.
Estas empresas se veem apenas como representantes comerciais e, como tal, atu-
am como “sponsors” e “after-sales“. Elas se identificam mais com o conceito de “pa-
trocinadoras”, pois atuam na verdade com a intermediação de vendas de equipa-
mentos de suas representadas, através de pacotes de equipamentos integrados na
forma de sistemas de medição com produção executada pelo processo “assembly-
to-order” (montagem sobre pedido de compra).
28
Portanto, a motivação para a proposta deste sistema de gestão de projeto,

visa simplificar e padronizar o processo de gestão do projeto, em todas as suas eta-
pas, culminando na conclusão do mesmo, incorporando as mais conceituadas técni-
cas de gestão (projeto, produção, manutenção, qualidade, segurança, saúde ocupa-
cional e meio ambiente) em um pacote único, modular, adaptável.
A relevância desse projeto reside no fato de que o mesmo contribui sensi-

velmente para o desenvolvimento de novas descobertas e conhecimentos da área
de gerenciamento de projetos para toda a Sociedade e Comunidade Científica, por
reforçar e embasar as mudanças necessárias na forma de se conduzir projetos, se
todas as partes interessadas puderem perceber que toda a atividade humana, do
menor ao maior porte, constitui em si própria um projeto. E que todo projeto tem um
objetivo, uma meta. E isso pode ser um excelente exercício acadêmico de aplicação
da Teoria das Restrições.
Para o autor, essa é uma excelente oportunidade de participar com os seus

próprios esforços desse desenvolvimento, contribuindo para o mesmo de forma pro-
dutiva e efetiva, apresentando a sua própria perspectiva do tema.
1.4 METODOLOGIA
1.4.1 Quanto aos fins
Nas definições de VERGARA (2014), trata-se de uma pesquisa descritiva,

por retratar através de um estudo de caso, as características gerais da empresa que
é objeto do estudo de caso, seu mercado de atuação, seu planejamento estratégico
em geral, e uma visão geral de seus processos de gerenciamento da produção de
equipamentos industriais, que servem de base para esta pesquisa.
Conforme estabelecido por VERGARA (2014), a pesquisa é explicativa por-

que tem por objetivo esclarecer os fatores que levam a ocorrência dos eventos que
produzem os efeitos indesejáveis no gerenciamento do tempo da empresa que é
objeto de estudo de caso, causando o atraso nas entregas ao longo do projeto.
29
Finalmente, ainda de acordo com a taxonomia proposta por VERGARA

(2014), à pesquisa pode ser considerada aplicada, já que é motivada pela necessi-
dade da reavaliação dos métodos e procedimentos utilizados para a gestão do proje-
to na produção de equipamentos de processos industriais.
1.4.2 Quanto aos meios
De acordo com VERGARA (2014), a pesquisa pode ser considerada como

uma pesquisa de laboratório, pois são apresentados gráficos simulados no compu-
tador, aplicando a metodologia proposta, e analisando o problema do atraso na con-
clusão de projetos, demonstrando onde se encontram as suas causas e quais são
as soluções propostas de gestão para sanar o problema.
Ainda conforme VERGARA (2014) pode-se afirmar que a pesquisa se carac-

teriza como documental, pois é baseada na investigação dos documentos dos pro-
cedimentos internos, dos registros de controles, dos relatórios, dos gráficos, dos pa-
drões, etc., implantados e aplicados pela empresa abordada no estudo de caso na
condução da gestão de seus negócios.
Segundo VERGARA (2014), este trabalho também se estrutura como biblio-

gráfico, pois é baseado em teorias e práticas fundamentadas e material publicado
sobre o gerenciamento de tempo em projetos, e em estudo sistematizado com base
nas pesquisas de diversos artigos de autores citados ao longo do texto.
Por fim, a metodologia apresenta-se como estudo de caso (VERGARA,

2014) fundamentado na metodologia aplicada pela empresa abordada no estudo de
casos para gerenciar seus projetos. Para essa finalidade, será usado como modelo
do estudo de caso, um projeto específico de fornecimento de EMEDs desta empresa
para um determinado cliente da área.
30
1.4.3 Universo pesquisado
O universo estudado é o do Gerenciamento do Tempo abordado pelas re-

comendações e boas práticas do Guia PMBOK® e as aplicações da Teoria das Res-
trições no campo da melhoria do Gerenciamento de Projetos, e de como aplicar o
mesmo na realização de projetos voltados para a área industrial de Óleo e Gás.
1.4.4 Amostra
A amostra foi definida pela acessibilidade às informações e pela tipicidade

das mesmas, já que a pesquisa foi orientada por estudo de caso realizado através
do acesso a diversos documentos disponibilizados sobre o processo de gestão do
negócio da empresa abordada no estudo de caso durante o período em que o autor
do estudo foi funcionário da mesma e com acesso autorizado a essas informações.
Todas as informações foram descaracterizadas quanto à identificação de

empresas (cliente e fornecedora), e quanto a projetos atendidos, apenas sem adulte-
ração nos dados necessários efetivamente à demonstração do problema.
1.4.5 Seleção dos sujeitos
Não houve seleção de sujeitos, uma vez que a base do estudo de caso foi
toda documental, não sendo necessária a entrevista a elementos da empresa.
1.4.6 Coleta de dados
Os dados coletados neste estudo são retirados de documentos de proprie-

dade da empresa, normas, livros, internet, dissertações, teses, artigos referentes à
área de Gerenciamento de Projetos.
31
1.4.7 Tratamento dos dados
Os dados foram tratados de forma qualitativa, quando estes foram origina-

dos da pesquisa bibliográfica e documental, e de forma quantitativa, quando foram
coletados por meio do estudo de caso, de forma a contribuir para o fornecimento de
respostas à pergunta do problema proposto neste estudo
1.4.8 Limitações do Método
A limitação do método do estudo foi pelo acesso limitado às informações da

empresa, restringindo-se aos dados sobre os negócios da empresa, estudos estra-
tégicos, propostas, projetos e cronogramas de um projeto, baseado em fornecimento
contratado à mesma.
Não foi autorizada a divulgação do nome da empresa, nem de sua cliente,

havendo a necessidade de total descaracterização das mesmas, ou de empresas
associadas. Fica apenas a ressalva de não terem sido descaracterizadas as suas
concorrentes, uma vez que elas participam do delineamento do mercado atendido,
mas não são cobertas pelo estudo.
1.5 ESTRUTURA DO TRABALHO
Este trabalho de conclusão de curso está estruturado na forma de uma mo-

nografia, redigida em quatro capítulos.
O Capítulo 1 apresenta esta introdução aos métodos objetos do estudo. A

apresentação do problema, descrevendo a forma como o mesmo se manifesta, sua
abrangência desde o nível local ao nível global.
Descreve as metodologias empregadas para analisar o problema e os pro-

cessos sugeridos para determinar as soluções para o mesmo. Define o objetivo glo-
bal e os objetivos específicos que perfazem o escopo desse trabalho. Apresenta a
justificativa do autor para a escolha do tema. E por fim define a estrutura funcional
do trabalho.
32
O Capítulo 2 apresenta a Fundamentação Teórica, permitindo introduzir os

conceitos de gerenciamento de projetos, em conformidade com o PMBOK®, e onde
será abordada a metodologia de gerenciamento de projetos proposta, definindo o
que é um projeto em si, suas características, objetivos, expectativas e resultados.
Também será descrita a essência do gerenciamento de projetos, as cinco etapas
que os compõem, as dimensões de conhecimento cruciais que estas etapas abran-
gem e uma visão geral dos processos envolvidos.
Aqui serão descritas as técnicas de ajuste do Gerenciamento de Projetos pe-

lo método da Corrente Crítica (CCPM) da Teoria das Restrições em comparação
com o método do Caminho Crítico (CPM) adotado pelo PMBOK®, indicando como
atuar na identificação dos sintomas dos problemas de atraso inerentes aos projetos,
e o que fazer para concluir projetos no prazo.
O Capítulo 3 apresentará a descrição detalhada e analítica dos sintomas que

causam o atraso de projetos, fazendo uma abordagem descritiva de cada um dos
mesmos desde a sua causa-raiz até o impacto gerado pelos atrasos dos projetos.
Aqui também será apresentado onde se manifestam esses sintomas pelo es-
tudo de caso do gerenciamento de projetos da empresa objeto do estudo de caso,
as suas características, o escopo de fornecimento, um resumo básico da estrutura
interna da mesma e como esta empresa obtém os seus resultados.
Finalmente no Capítulo 4 serão apresentadas as considerações finais deste

trabalho de conclusão de curso, abrangendo a avaliação do desempenho e as pos-
sibilidades de aplicação do sistema de gestão de projeto na produção de equipa-
mentos industriais para atender ao setor de Óleo e Gás e proposta para trabalhos
futuros.
33
2 METODOLOGIA DO GERENCIAMENTO DE PROJETO
O que se pode dizer sobre o Gerenciamento de Projetos? Em primeiro lugar,

é necessário entender o que é um projeto, o que define e o que estabelece um pro-
jeto, para que e onde se pode aplicar esse conhecimento e principalmente, como se
pode controlar ou gerenciar um projeto, em qualquer área, e de qualquer porte.
Segundo o PMBOK®:
Projeto é um esforço temporário empreendido para criar um produto, serviço

ou resultado único. A sua natureza temporária indica que os projetos têm
um início e um término bem definidos; a sua conclusão é alcançada quando
os objetivos do projeto são atingidos ou quando o projeto é encerrado por-
que os seus objetivos não serão ou não tem como serem alcançados, ou
quando a necessidade do projeto deixar de existir. (PMI, 2013)
Aqui o termo temporário está conectado com a ideia de engajamento do pro-

jeto e quanto à sua longevidade. Os projetos são empreendidos e executados para
serem duradouros e produzir impactos sociais, econômicos e ambientais que sobre-
vivam aos próprios projetos em si.
Como esforço de trabalho contínuo, caracteriza-se por ser um processo re-

petitivo, seguindo procedimentos existentes em uma organização.
2.1 DEFINIÇÕES E RELACIONAMENTOS
Segundo o PMBOK® (PMI, 2013), dentro do universo do Gerenciamento de

Projetos existem as seguintes subdivisões hierárquicas, da maior para a menor:
• Portfólios
• Programas
• Projetos
Estas subdivisões e seus relacionamentos serão descritos a seguir.

34
2.1.1 Portfólios
Consistem de projetos, programas e subportfólios e operações gerenciadas

em grupo, para alcançar objetivos estratégicos. Portfólio é considerado a carteira de
trabalhos na organização relacionados com os objetivos estratégicos do negócio.
2.1.2 Programas
Consistem de grupos de projetos, subprogramas e atividades relacionadas e

gerenciadas de modo coordenado para obter benefícios e controle indisponíveis se
gerenciados individualmente. Programas não são nada além de grandes projetos ou
conjuntos de projetos.
2.1.3 Projetos
Consistem de esforço temporário para criar produto, serviço ou resultado ú-

nico. Ampliando a visão sobre projeto, é possível se dizer que projeto é normalmente
definido como empreendimento colaborativo, frequentemente envolvendo pesquisa
ou design, cuidadosamente planejado para alcançar um objetivo particular. O relaci-
onamento entre portfólios, programas e projetos é tal que todos estes constituem a
carteira de projetos da empresa, representando o planejamento estratégico para a
realização de suas metas, conforme visto na Figura 2-1 a seguir.
Figura 2-1 - Interações na gestão de portfólios, programas e projetos

FONTE: PMBOK® (PMI, 2013).
35
2.2 DEFININDO O GERENCIAMENTO DE PROJETOS
É possível definir, segundo o PMBOK®, que: “Gerenciamento de Projetos é

a aplicação do conhecimento, habilidades, ferramentas e técnicas às atividades do
projeto para atender aos seus requisitos” (PMI, 2013).
Também se pode afirmar ainda que:
A gestão de um projeto normalmente inclui a identificação dos requisitos, a

abordagem das diferentes necessidades, preocupações e expectativas das
partes interessadas no planejamento e execução do projeto, o estabeleci-
mento, manutenção e execução de comunicações ativas, eficazes e colabo-
rativas entre as partes interessadas, o gerenciamento das partes interessa-
das visando o atendimento aos requisitos do projeto e a criação das suas
entregas e o equilíbrio das restrições conflitantes do projeto que incluem,
mas não se limita ao escopo, a qualidade, ao cronograma, ao orçamento,
aos recursos e aos riscos” (PMI, 2013).
As características e circunstâncias específicas do projeto podem influenciar

as restrições nas quais a equipe de gerenciamento do projeto precisa se concentrar.
Esses fatores estão relacionados de tal forma que se algum deles mudar, outro fator
provavelmente será afetado.
2.2.1 Processos de Gerenciamento de Projetos
O Gerenciamento de Projetos é a aplicação de conhecimentos, habilidades,

ferramentas e técnicas às atividades do projeto a fim de cumprir os seus requisitos.
A aplicação do conhecimento requer a gestão eficaz dos processos de gerenciamen-
to do projeto.
Processos é o conjunto de ações e atividades inter-relacionadas executadas

para criar um produto, serviço ou resultado previamente especificado. Cada proces-
so é caracterizado por suas entradas, ferramentas e técnicas que podem ser aplica-
das, e as saídas resultantes.
36
O PMBOK® descreve a natureza dos processos de gerenciamento de proje-

tos em termos da integração entre os processos, suas interações e seus objetivos.
Os processos de gerenciamento de projetos são agrupados em cinco categorias co-
nhecidas como grupos de processos de gerenciamento de projetos: processos de
iniciação, processos de planejamento, processos de execução, processos de moni-
toramento e controle e processos de encerramento (PMI, 2013).
2.2.1.1 Interações comuns
Os processos de gerenciamento de projetos são apresentados como ele-

mentos distintos com interfaces bem definidas. A natureza integrativa do gerencia-
mento de projetos requer que o grupo de processos de monitoramento e controle
interaja com os outros grupos de processos, conforme visto na Figura 2-2.
Figura 2-2 - Grupos de processos de gerenciamento de projetos

Os grupos de processos de gerenciamento de projetos estão vinculados pe-

las saídas que produzem. A saída de um processo em geral torna-se uma entrada
em outro processo ou é uma entrega do projeto, subprojeto, ou fase do projeto. Os
processos de planejamento fornecem aos processos de execução o plano de geren-
ciamento do projeto e os documentos do projeto e, à medida que o projeto avança,
ele cria atualizações no plano de gerenciamento e em seus documentos.
A Figura 2-3 ilustra como os grupos de processos interagem e mostra o nível

de sobreposição em diversas ocasiões. Se o projeto estiver dividido em fases, os
grupos de processos interagem dentro de cada fase.
37
Figura 2-3 - Grupos de processos interagem em uma fase ou projeto

2.2.2 Processos de gerenciamento de projetos
Os grupos de processos e os processos em si são frequentemente iterados

antes da conclusão do projeto e podem ter iterações dentro de um grupo e entre os
grupos (PMI, 2013).
O diagrama de fluxo da Figura 2-4 fornece um resumo do fluxo e das intera-

ções entre os grupos processos e as partes interessadas específicas. Os processos
de gerenciamento do projeto estão vinculados por entradas e saídas específicas on-
de o resultado de um processo torna-se a entrada de outro (PMI, 2013).
Conforme os projetos são separados em fases ou subcomponentes distintos

tais como desenvolvimento do conceito, estudo de viabilidade, concepção, protótipo,
construção, ou teste, etc., todos os grupos de processos seriam normalmente repeti-
dos para cada fase ou subcomponente conforme visto na Figura 2-4 (PMI, 2013).
38
Figura 2-4 - Interações nos processos de gerenciamento de projetos

2.2.2.1 Processos de iniciação
Os processos de iniciação consistem dos processos realizados para definir

um projeto ou uma fase obtendo autorização para iniciar os mesmos. Nestes pro-
cessos, o escopo é definido e recursos financeiros são comprometidos. O limite do
projeto (Figura 2-5) é definido como o momento em que início ou conclusão do proje-
to ou fase é autorizado (PMI, 2013).
39
Figura 2-5 - Limites do projeto

2.2.2.2 Processos de planejamento
Este grupo consiste dos processos realizados para estabelecer o escopo,

definir e refinar objetivos e desenvolver cursos de ação para realizar esses objetivos.
Os processos de planejamento desenvolvem o plano de gerenciamento e os docu-
mentos do projeto que serão usados para executá-lo (PMI, 2013).
2.2.2.3 Processos de execução
Este grupo consiste de processos executados para concluir o trabalho no

plano de gerenciamento e cumprir as especificações do projeto. Este grupo envolve
coordenar pessoas e recursos, gerenciar expectativas dos stakeholders, e também
integrar e executar atividades conformes ao plano de gerenciamento (PMI, 2013).
2.2.2.4 Processos de monitoramento e controle
Os processos de monitoramento e controle consistem de processos neces-

sários para acompanhar, analisar e organizar o progresso e desempenho do projeto,
identificar áreas que precisem de mudanças, e iniciar as mesmas (PMI, 2013).
40
2.2.2.5 Processos de encerramento
Este grupo consiste de processos executados para encerrar atividades de

gerenciamento do projeto, para concluir o projeto, fase, ou obrigações contratuais.
Este grupo verifica se os processos definidos estão completos em todos os grupos a
fim de encerrar o projeto ou fase do mesmo, apropriadamente, e definir o encerra-
mento destes. Este grupo também formaliza encerramentos prematuros (PMI, 2013).
2.2.3 Informações do projeto
Ao longo da vida útil do projeto, um volume significativo de informações são

coletadas, analisadas, transformadas e distribuídas para os membros da equipe pro-
jeto e outros stakeholders. Os dados do projeto são coletados como resultado dos
vários processos de execução e compartilhados no âmbito da equipe.
Os dados do projeto são continuamente coletados e analisados no decorrer

do contexto da sua execução. Como resultado, os termos, dados e informações são
frequentemente usados de forma intercambiável na prática. A Figura 2-6 ilustra o
fluxo de informações de projeto nos diversos processos usados para gerenciar o
mesmo.
Figura 2-6 - Fluxo de dados, de informações e de relatórios do projeto

41
2.2.4 Papel das áreas de conhecimento
Os processos de gerenciamento definidos no PMBOK® são agrupados em

áreas de conhecimento. As áreas de conhecimento representam conjuntos de con-
ceitos, termos e atividades que compõem campos profissionais, de gerenciamento
de projetos, ou áreas de especialização (PMI, 2013).
As equipes de projeto usam apropriadamente essas e outras áreas de co-

nhecimento na maioria dos projetos e das vezes, para atividades específicos. As
áreas de conhecimento são: Integração, Escopo, Tempo, Custos, Qualidade, Recur-
sos Humanos, Comunicações, Riscos, Aquisições e Stakeholders.
A Tabela 2-1 delimita este trabalho aos processos do Gerenciamento do

Tempo de Projeto como visto nos itens de 6.1 a 6.7 da mesma. Os itens das outras
áreas não foram apresentados por não estarem no escopo do trabalho (PMI, 2013).
GRUPOS DE PROCESSOS DO GERENCIAMENTO DE PROJETOS

ÁREA DE MONITORAMENTO
INICIAÇÃO PLANEJAMENTO EXECUÇÃO ENCERRAMENTO
CONHECIMENTO E CONTROLE
INTEGRAÇÃO
ESCOPO
6.1. Planejar o
gerenciamento do
cronograma
6.2. Definir as
atividades
6.3. Sequenciar as
atividades
6.7. Controlar o
TEMPO cronograma
6.4. Estimar os
recursos das atividades
6.5. Estimar a duração

das atividades
6.6. Desenvolver o
cronograma
CUSTOS
QUALIDADE
RECURSOS
HUMANOS
COMUNICAÇÕES
RISCOS
AQUISIÇÕES
STAKEHOLDERS
Tabela 2-1 - Grupo de processos e mapa das áreas de conhecimento

42
2.3 GERENCIAMENTO DO TEMPO DO PROJETO
O Gerenciamento do Tempo do projeto inclui os processos necessários para

gerenciar o término pontual do projeto, que são descritos abaixo e vistos com deta-
lhes na Figura 2-7:
a) Planejar o gerenciamento do cronograma - Conjunto de procedimentos neces-

sários para planejar, desenvolver, gerenciar, executar e controlar o cronograma.
b) Definir as atividades - Conjunto de procedimentos necessários para produzir as

entregas do projeto.
c) Sequenciar as atividades - Conjunto de procedimentos necessários para esta-

belecer relacionamentos e sequências entre as atividades do projeto.
d) Estimar os recursos das atividades - Conjunto de procedimentos para estima-

tiva de recursos necessários para realizar cada atividade.
e) Estimar as durações das atividades - Conjunto de procedimentos para estima-

tiva de tempo necessário para terminar atividades específicas com os recursos
estimados.
f) Desenvolver o cronograma - Conjunto de procedimentos para análise das se-

quências das atividades, durações, recursos necessários e restrições, visando
criar o cronograma do projeto.
g) Controlar o cronograma - Conjunto de procedimentos para monitoramento do

projeto, atualização do progresso e gerenciamento de mudanças na linha de ba-
se do cronograma para realizar o planejado.
O modelo do cronograma é uma representação do plano para a execução

das atividades do projeto incluindo durações, dependências, e outras informações
de planejamento, usado para produzir um cronograma de projeto juntamente com
outros artefatos do cronograma (PMI, 2013).
43
Figura 2-7 - Visão geral do gerenciamento do tempo do projeto

O plano de gerenciamento do cronograma identifica um método e uma fer-

ramenta de cronograma, e estabelece o formato e critérios para o desenvolvimento e
controle do cronograma do projeto. A metodologia de cronograma selecionada defi-
ne a estrutura e os algoritmos usados na ferramenta de cronograma para criar o mo-
delo de cronograma. As mais conhecidas incluem o Método do Caminho Crítico
(MCC ou CPM) e o Método da Corrente Crítica (CCM ou CCPM). (PMI, 2013).
O desenvolvimento do cronograma do projeto usa as saídas dos processos

para definir e sequenciar as atividades, estimar os recursos e as durações das ativi-
dades em combinação com a ferramenta de cronograma para produzir o modelo do
cronograma. À medida que as atividades do projeto são desenvolvidas, a maior par-
te do esforço na área de conhecimento de gerenciamento do tempo do projeto ocor-
rerá no processo Controlar o cronograma, visando assegurar o término pontual do
trabalho do projeto (PMI, 2013).
44
Figura 2-8 - Visão geral do desenvolvimento do cronograma

A Figura 2-8 fornece uma visão da elaboração do cronograma mostrando

como a metodologia e a ferramenta de cronograma e as saídas dos processos de
gerenciamento do tempo, interagem para criar o cronograma do projeto (PMI, 2013).
2.3.1 Planejar o gerenciamento do cronograma
Planejar o gerenciamento do cronograma é o procedimento para planejar,

desenvolver, gerenciar, executar e controlar o cronograma do projeto. O plano de
gerenciamento do cronograma define como as contingências do cronograma serão
reportadas e avaliadas (PMI, 2013). A Figura 2-9 ilustra o diagrama de fluxo de da-
dos do processo.
45
Figura 2-9 - Processo: Planejar o gerenciamento

2.3.2 Definir as atividades
Definir as atividades é o processo de identificação e documentação das a-

ções específicas a serem realizadas para produzir as entregas do projeto. Ele forne-
ce a base para estimar, programar, executar, monitorar e controlar as atividades do
projeto (PMI, 2013). A Figura 2-10 ilustra o diagrama de fluxo de dados do processo.
Figura 2-10 - Processo: Definir as atividades

46
4.1.1 Sequenciar as atividades

Sequenciar as atividades é o processo de identificar e documentar relacio-
namentos entre atividades. Todas as atividades e marcadores, com exceção do pri-
meiro e do último, devem ser conectados a um predecessor por uma relação lógica
(PMI, 2013). A Figura 2-11 ilustra o diagrama de fluxo de dados do processo.
Figura 2-11 - Processo: Sequenciar atividades

2.3.3 Estimar os recursos das atividades

Estimar os recursos das atividades é o processo de estimativa dos tipos e
quantidades de recursos necessários para realizar cada atividade (PMI, 2013). A
Figura 2-12 ilustra o diagrama de fluxo de dados do processo.
Figura 2-12 - Processo: Estimar os recursos

47
2.3.4 Estimar as durações das atividades
Estimar as durações das atividades é o processo de estimativa do tempo

das atividades necessárias para terminar atividades específicas com os recursos
estimados. A estimativa do tempo das atividades utiliza informações sobre escopo,
recursos, quantidades estimadas e calendários dos recursos (PMI, 2013). A Figura
2-13 ilustra o diagrama de fluxo de dados do processo.
Figura 2-13 - Processo: Estimar durações

2.3.5 Desenvolver o cronograma
Desenvolver o cronograma é a análise de sequências de atividades, tem-

pos, recursos e restrições visando criar o cronograma do projeto. O desenvolvimento
do cronograma aceitável é muitas vezes um processo iterativo. O modelo de crono-
grama é usado para definir datas (inicial e final) planejadas das atividades e marca-
dores do projeto com base na exatidão das entradas (PMI, 2013).
O desenvolvimento do cronograma requer a análise e revisão de estimativas

de duração e de recursos para criar o cronograma que pode servir como linha de
base para acompanhar o progresso do projeto após aprovado. A Figura 2-14 ilustra
o diagrama de fluxo de dados do processo (PMI, 2013).
48
Figura 2-14 - Processo: Desenvolver o cronograma

2.3.5.1 Método do caminho crítico
O método do caminho crítico é um método usado para estimar a duração

mínima do projeto. Esta técnica de análise de rede calcula as datas de início e tér-
mino mais cedo e mais tarde, para todas as atividades, sem considerar limitações de
recursos, analisando os caminhos de ida e de volta pela rede do cronograma, como
visto na Figura 2-15 (PMI, 2013). No exemplo, o caminho mais longo inclui as ativi-
dades A, C e D e assim, a sequência de A-C-D é o caminho crítico.
O caminho crítico é a sequência de atividades que definem o caminho mais

longo, e determinam o menor tempo possível do projeto. O método do caminho críti-
co é usado para determinar a flexibilidade de elaboração do cronograma nos cami-
nhos lógicos da rede dentro do mesmo. Em qualquer caminho, a flexibilidade do cro-
nograma é medida pelo tempo que atividades podem atrasar ou ser adiada a partir
da sua data de início mais cedo sem atrasar a data de término do projeto ou violar
restrição do cronograma, chamada de "folga total” (PMI, 2013).
49
Um caminho crítico (CCM) é caracterizado por folga total zero. Quando im-
plantados com sequenciamento do método do diagrama de precedência (MDP), ca-
minhos críticos podem ter folga total positiva, zero ou negativa, dependendo das res-
trições aplicadas (PMI, 2013). Qualquer atividade no caminho crítico é chamada de
atividade de caminho crítico. A folga total positiva é causada quando o caminho de
volta é calculado a partir de uma restrição do cronograma que é mais tarde que a
data de término mais cedo que foi calculada durante o cálculo do caminho de ida
(PMI, 2013).
A folga total negativa é causada quando uma restrição na data mais tarde é
violada por duração e lógica. As redes do cronograma podem ter múltiplos caminhos
quase críticos. Quando a folga total para um caminho da rede for calculada, a folga
livre, isto é, o tempo que atividades do cronograma podem atrasar sem atrasar a
data de início mais cedo de atividades sucessoras, ou violar restrições do cronogra-
ma, também pode ser determinada. Por exemplo, a folga total para a Atividade B na
Figura 2-15 é cinco dias (PMI, 2013).
Figura 2-15 - Exemplo de método do caminho crítico

FONTE: PMBOK® (PMI, 2013)
2.3.5.2 Método da corrente crítica
O método da corrente crítica (CCPM) é um método que permite que a equi-

pe crie “pulmões” (reservas) ao longo de caminhos do cronograma levando em conta
recursos limitados e incertezas do projeto (PMI, 2013; GOLDRATT, 1997, 2014).
50
Ele é desenvolvido a partir da abordagem do método de caminho crítico e

considera os efeitos da alocação, otimização e nivelamento de recursos, e incerte-
zas na duração de qualquer atividade do caminho crítico determinados usando o
método de caminho crítico. Para isso, o método da corrente crítica introduz o concei-
to e o gerenciamento de “pulmões” (PMI, 2013; GOLDRATT, 1997, 2014).
O método da corrente crítica usa atividades com durações sem contingên-

cias, relações lógicas e disponibilidade de recursos com reservas compostas de
margens de segurança agregadas em pontos específicos no caminho, para conside-
rar recursos limitados e incertezas do projeto. O caminho crítico restrito por recursos
é conhecido como corrente crítica (PMI, 2013; GOLDRATT, 1997, 2014).
O método da corrente crítica adiciona “pulmões” de tempo que são ativida-

des sem trabalho para gerenciar incertezas. Um “pulmão”, colocado no final da cor-
rente crítica e mostrado na Figura 2-16, é conhecido como o “pulmão” do projeto e
protege a data de término contra desvios ao longo da corrente crítica (PMI, 2013;
GOLDRATT, 1997, 2014). “Pulmões” adicionais, conhecidos como “pulmões de ali-
mentação”, são incluídos em pontos em que correntes de atividades dependentes
fora da corrente crítica alimentam ou convergem para esta. Dessa forma, os “pul-
mões de alimentação” protegem a corrente crítica contra o desvio ao longo das cor-
rentes de alimentação. O tamanho dos “pulmões” deve considerar a incerteza no
tempo da corrente de atividades dependentes que levam a eles. Uma vez que as
atividades “pulmão” do cronograma estejam determinadas, as atividades planejadas
são agendadas para as suas datas planejadas de início e de término mais tarde
possíveis (PMI, 2013; GOLDRATT, 1997, 2014).
Figura 2-16 - Exemplo de método da corrente crítica

51
2.3.5.3 Técnicas de otimização de recursos
Os exemplos de técnicas de otimização de recursos a serem usadas para

ajustar o modelo do cronograma devido à oferta e procura de recursos incluem:
• Nivelamento de recursos - Técnica onde datas de início e término é ajustada

com base em restrições de recursos, para equilibrar demanda com disponibilida-
de. É usada quando recursos compartilhados ou críticos estão disponíveis ape-
nas em certas épocas, em quantidades limitadas, ou foram distribuídos demais
(exemplo, em caso de multitarefa como visto na Figura 2-17) ou para manter o
seu uso em nível constante. O nivelamento de recursos pode causar mudança do
caminho crítico, inclusive aumentando-o (PMI, 2013).
Figura 2-17 - Nivelamento de recursos

• Estabilização de recursos - Técnica que ajusta as atividades do cronograma de

modo que os requisitos de recursos não excedam limites pré-definidos. Na esta-
bilização, ao contrário do nivelamento, o caminho crítico do projeto não é mudado
e a data de conclusão não pode ser adiada. Ou seja, as atividades só podem ser
adiadas dentro da folga livre e total. Assim, a estabilização de recursos pode não
melhorar o uso de todos os recursos (PMI, 2013).
52
2.3.5.4 Ferramenta de cronograma
Ferramentas automatizadas para o desenvolvimento do cronograma contêm

o cronograma e aceleram o desenvolvimento do mesmo, gerando datas de início e
término baseadas nas entradas das atividades, diagramas de rede, recursos e dura-
ções, usando a análise de rede do cronograma. Uma ferramenta de elaboração do
cronograma pode ser usada em conjunto com outros softwares de gerenciamento de
projetos assim como com métodos manuais (PMI, 2013).
2.3.5.5 Linha de base do cronograma
A linha de base do cronograma é a versão aprovada do cronograma que po-

de ser mudado apenas mediante procedimentos de controle formais, e é usada co-
mo uma base para comparação com os resultados reais. É aceita e aprovada pelas
partes interessadas como a linha de base do cronograma com datas de início e de
término da linha de base. Durante o monitoramento e controle, as datas aprovadas
da linha de base são comparadas com as datas reais de início e fim para determinar
a ocorrência de variações. A linha de base do cronograma é um componente do pla-
no de gerenciamento do projeto (PMI, 2013).
2.3.5.6 Cronograma do projeto
As saídas de um modelo são apresentações do cronograma. O cronograma

do projeto é uma saída de um modelo que apresenta a conexão de atividades com
datas, durações, marcadores e recursos planejados. O cronograma do projeto inclui
pelo menos uma data de início e de término planejadas para cada atividade. Se o
planejamento de recursos for feito no início, então o cronograma permanece prelimi-
nar até as designações dos recursos serem confirmadas e as datas de início e tér-
mino estabelecidas. Esse processo acontece antes do fim do plano de gerenciamen-
to do projeto. O cronograma final de projeto também pode ser realizado com as da-
tas de início e de término alvo definidas para cada atividade. O cronograma do proje-
to pode ser apresentado de forma resumida (cronograma mestre ou de marcos), ou
apresentado detalhadamente (PMI, 2013).
53
Embora um cronograma de projeto possa ser apresentado em formato tabu-

lar, ele é geralmente apresentado graficamente, em um ou mais destes formatos,
classificados como apresentações, como vistos nas Figuras 2.18, 2.19 e 2.20:
• Gráficos de barras - Também conhecidos como Diagramas de Gantt, represen-

tam informações do cronograma onde as atividades são listadas na vertical, da-
tas são mostradas na horizontal, e os seus tempos aparecem como barras hori-
zontais posicionadas conforme as datas inicial e final. Os gráficos de barras são
de leitura fácil e geralmente são usados em apresentações gerenciais.
Figura 2-18 - Cronograma de barras do projeto (Diagrama de Gantt)

• Gráficos de marcos - Assemelham-se aos gráficos de barras, porém identificam

apenas o início ou término agendado para as entregas mais importantes e inter-
faces externas chaves.
Figura 2-19 - Cronograma de marcos do projeto

54
• Diagramas de rede do cronograma do projeto - Esses diagramas são geral-

mente apresentados no formato de diagrama de atividade no nó mostrando ativi-
dades e relações sem escala de tempo (diagrama de lógica pura), ou no formato
de diagrama de rede do cronograma com escala de tempo (gráfico de barras ló-
gico).
Figura 2-20 - Cronograma de resumo do projeto (gráfico de barras)

Esses diagramas, com informações sobre as datas das atividades, normal-

mente mostram tanto a lógica da rede do projeto como suas atividades de crono-
grama de seu caminho crítico (PMI, 2013).
2.3.5.7 Dados do cronograma
Os dados para o modelo do cronograma do projeto são o conjunto de infor-

mações usadas para descrever e controlar o cronograma. As informações do crono-
grama podem incluir itens tais como:
• Requisitos de recursos por período de tempo (histogramas de recursos)

• Cronogramas alternativos e de pedidos e entregas.
• Alocação de reservas para contingências e projeções de fluxo de caixa
2.3.6 Controlar o cronograma
Controlar o cronograma é o processo de monitoramento do andamento do

projeto para atualização do progresso e gerenciamento de mudanças na linha de
base deste para realizar o planejado. A Figura 2-19 ilustra o diagrama de fluxo de
dados do processo.
55
Figura 2-21 - Processo: Controlar o cronograma

2.4 ANALISANDO O PROBLEMA
Existe uma situação comum na produção de equipamentos das indústrias de

Óleo e Gás Natural e outras, identificada pelos inúmeros escândalos de atrasos de
projetos, quebras de contratos, estouros de verbas, corrupção, etc., publicados na
mídia, e resumidos em uma pergunta: Porque todo projeto acaba atrasando?
Primeiro é necessário entender porque os projetos atrasam. Conforme citado

por Thomas Mochal:
Se você já participou de uma reunião de encerramento em um projeto que

teve grandes problemas, são boas as chances de que um dos principais te-
mas discutidos foi “devíamos ter passado mais tempo planejando”. Muitos
gerentes de projetos pensam que precisam pular direto para o projeto, reu-
nindo os requisitos de negócios. Eles acreditam que se fizeram um bom tra-
balho nesta etapa, estarão prontos para executar o projeto. Isso simples-
mente não é verdade. Na verdade, deve-se completar um processo de defi-
nição e planejamento antes de começar a reunir os requisitos de negócio
(MOCHAL, 2003).
Isso indica que projetos não são apenas conjuntos de ideias, desenhos, es-
quemas e listas de materiais. Eles relacionam avaliações criteriosas de processos
envolvidos na sua realização. A gestão de tempo e prazos não se trata do controle
sistemática de “marcadores” em Diagramas de Gantt.
56
Representa monitorar os tempos estimados corretamente estabelecidos e

saber se as atividades estão sendo executadas no ritmo esperado e sem imprevis-
tos. Thomas Mochal acrescenta:
Um dos principais aspectos da definição de um projeto é definir o escopo de

alto nível. Se não definir e obtiver um acordo sobre o escopo, vai descobrir
que será muito difícil gerenciar o escopo de forma eficaz durante todo o pro-
jeto. Pode-se evitar esse erro investindo tempo de antemão em boa defini-
ção e planejamento, que acaba levando muito menos tempo e esforço do
que ter que corrigir os problemas quando o projeto está em andamento
(MOCHAL, 2003).
Em artigo da Revista ÉPOCA com o título “Por que tudo atrasa no Brasil?” é
abordada a questão dos projetos malfeitos, licitações irreais, aditamentos, liminares
e corrupção, esta perversa combinação de fatores que legou ao nosso país a alcu-
nha de “Terra do Nunca Fica Pronto” (BOMBIG, et al 2013).
O fenômeno é tão conhecido que pode ser considerado como parte da cultu-
ra brasileira. Conforme Aldo Rebelo, ministro do esporte, citado na reportagem, e
responsável por obras da Copa do Mundo e dos Jogos Olímpicos do Rio de Janeiro,
informa: “O atraso é um dos nossos problemas civilizatórios, faz parte da nossa cul-
tura. Até reunião ministerial atrasa no Brasil”. Mas o que leva a essa “cultura do atra-
so em projetos”? Isso é um fenômeno localizado, ou acontece em outros lugares do
mundo? É de fato uma questão cultural? (BOMBIG, et al 2013).
Considerando o universo de obras públicas no Brasil, existe uma “cultura da

obra de curto prazo” ou “eleitoreira”. Definindo melhor, “obra boa é aquela que fica
pronta a tempo de ser inaugurada em ano eleitoral”. Governantes e políticos ficam
insatisfeitos quando a obra demora na fase de projeto. Como exemplo disso, vejam
o que o diretor do Departamento de Infraestrutura do Instituto de Engenharia de São
Paulo, Roberto Kochen, afirma na reportagem: “... Os governantes falam: “não quero
projeto, quero obras””. Paradoxalmente, essa mesma premissa é um dos maiores
fatores de atraso (BOMBIG, et al 2013).
57
Por não se conduzir estudos técnicos de qualidade, acabam acontecendo

imprevistos na sua execução (contingências). Quando isso ocorre, é necessário a
revisão de prazos e o orçamento. Como resultado disso, as atividades ou o projeto
acaba se tornando mais dispendiosos e demorados, para não dizer atrasados. Esse
pensamento de curto prazo é uma característica da política brasileira, uma vez que
os eleitos precisam apresentar resultados através de obras, para se perpetuarem na
política.
Citando exemplos de aprendizado de gerenciamento de projetos em outros

países, Roberto Kochen, afirma na reportagem que “nos Estados Unidos e em boa
parte da Europa, primeiro é conduzido todo um planejamento estratégico antes da
execução da obra, o qual pode levar anos”. Como exemplo prático, cita-se uma das
obras mais famosas recentes, o Eurotúnel, que interliga a França e a Inglaterra por
baixo do Canal da Mancha. Este projeto levou 7 anos para ser concluído. A sua eta-
pa de planejamento levou bem mais de 10 anos (BOMBIG, et al 2013).
O processo de licitação das empresas é outro grande motivo de atraso. Pelo

modelo atual, as empresas são privilegiadas por critério de eliminação baseado no
menor custo ofertado. Apesar de ser um princípio correto, isto se torna motivo para
inúmeras distorções. Para obter menores preços e cumprir as metas de entrega nos
prazos eleitorais, editais de licitação são malfeitos, com números irreais. Em resumo,
o parâmetro de base e referência são obras de porte e características funcionais si-
milares, estimando-se variações para mais ou menos das atualizações financeiras e
monetárias.
Essa premissa é equivocada, por deixar de contemplar avaliações criteriosas

e detalhadas que evitariam retrabalhos, paralisações e correções de escopo, custos
e requisitos, que impactam em mudanças no planejamento estratégico da obra, mui-
tas vezes a inviabilizando (BOMBIG, et al 2013).
Outro problema observado é a forma como o Governo Federal interfere in-

devidamente na licitação, estabelecendo limite de lucro no orçamento, causando
desinteresse nas empresas devido ao lucro menor que as taxas de rendimentos de
qualquer investimento seguro (BOMBIG, et al 2013).
58
Esse problema é crônico e persiste sistematicamente no Brasil, consideran-

do-se que querer limitar o lucro de uma empresa é a pior forma de tentar atrair capi-
tal e interesse por obras e projetos. Isso acaba produzindo mais atrasos em agendas
de projetos em pauta (BOMBIG, et al 2013).
Mais problemas ocorrem quando a análise de custos das licitações prende-

se apenas ao preço. Muitas vezes, vencem empresas sem condições técnicas de
conduzirem a obra até o fim, e que desistem no meio de execução, por limitações
operacionais. Em outros países, são adotadas práticas como a “performance bond”,
uma espécie de apólice de seguro com cobertura integral da obra. Caso a empresa
responsável pelo projeto quebre, seja declarada inidônea ou não possua garantias
de que possa concluir o projeto, caberá à seguradora dar prosseguimento ao mesmo
e concluir o serviço (BOMBIG, et al 2013).
Infelizmente aqui, o procedimento é inviável por favorecer as grandes em-

presas do setor, e concorrências saudáveis são cruciais para a lisura dos contratos e
redução dos custos. Por outro lado, o efeito dessa concorrência entre grandes e pe-
quenos pode ser até o oposto, porque muitas empresas acabam formando cartéis,
para vencer com preços abaixo dos valores necessários. Isso leva a outra prática
comum do empresariado brasileiro: a cultura do aditamento (BOMBIG, et al 2013).
O processo funciona assim: empresa “X” vence a concorrência oferecendo

um preço. Começa a realizar o projeto, alega que os custos calculados estão aquém
da realidade, sendo maiores que o previsto. A empresa então solicita o aditamento,
com suplementação de verbas. Resultado? O preço original que ganhou a licitação
fica apenas no papel. Os pedidos de aditamento de verbas incluem também prorro-
gação do prazo de entrega, uma vez que se refere a “procedimentos que não esta-
vam previstos no projeto original”, resultando em mais atrasos (BOMBIG, et al 2013).
Para prevenir essas circunstâncias, governos vêm se protegendo adotando

práticas burocráticas, para selecionar melhor as empresas. Isso leva a uma recla-
mação dos empresários, em relação a essa burocracia toda, a qual acaba emper-
rando o processo. Os documentos exigidos para o processo de licitação de projetos
incluem atestado de capacitação, certidões de liquidez, etc. (BOMBIG, et al 2013).
59
Ocorre que o problema não é a documentação; nesse caso é a pouca dispo-

nibilidade de pessoal para analisar rapidamente a documentação exigida. Fica evi-
dente que se os atrasos nas obras e fornecimentos públicos eram causados por in-
terferência política, falta de dinheiro ou incapacidade técnica das empresas concor-
rentes, hoje, eles decorrem da morosidade e da burocracia dos órgãos públicos
(BOMBIG, et al 2013).
Observando-se todas estas circunstâncias, conclui-se que como fenômeno

cultural, o atraso sistemático de projetos se deve a vários fatores. Não se trata de
eliminar ou reduzir exigências nem fiscalização, mas sim de tornar os procedimentos
mais ágeis. Como sugestões para as etapas posteriores podem ser citadas:
• Elaboração de projetos melhores, com tempo adequado dedicado às etapas

de planejamento, gestão do escopo, riscos, tempo de execução, aquisição de
insumos e da gestão dos recursos.
• Elaboração de licitações realistas, com gerenciamento da comunicação e de

stakeholders eficiente, contínua e cooperativa.
Além disso, com todas as etapas de gestão do projeto sendo conduzidas

com precisão e continuidade consegue-se inibir a cultura do aditamento.
2.5 METODOLOGIA DA CORRENTE CRÍTICA
Após décadas de testes de campo e aperfeiçoamento, o método da Corrente

Crítica está amadurecido e pode oferecer ajuda a esse respeito (GOLDRATT, 1997).
O produto deste exercício modelo de criação é geralmente conhecido como

plano de agendamento, cronograma ou projeto. Esse modelo em geral, reflete os
requisitos explícitos, e as hipóteses sobre as condições nas quais o projeto será rea-
lizado (ROBINSON; RICHARDS, 2010).
60
Por outro lado, nos ambientes de gerenciamento de projetos existe, em ge-

ral, um considerável grau de incerteza relativo às condições exatas nas quais o pro-
jeto será realizado. Essa incerteza descreve a dificuldade de previsão de qualquer
resultado específico antes que aconteça. Fatores que aumentam a incerteza de pre-
visão nos ambientes de projeto, em geral incluem (ROBINSON; RICHARDS, 2010):
• A quantidade de resultados possíveis para determinado elemento do plano

• As “dimensões” do projeto
• A quantidade de recursos ou entidades envolvidos na entrega do projeto
• O nível de interdependência que existe entre as várias atividades do projeto.
No âmbito geral, na medida em que esses fatores variam para mais, a capa-
cidade de previsão com certeza quanto tempo será dispendido ou qual será o custo
do projeto, reduz-se significativamente, ou seja, são inversamente proporcionais. Em
outras palavras, o grau de incerteza aumenta na medida em que o número de fato-
res de contingenciamento aumente (ROBINSON; RICHARDS, 2010).
Para assumir compromissos seguros quanto ao resultado de um projeto, não

obstante a existência da incerteza se prevê no modelo que se acomode certa quan-
tidade de "contingências”. Em geral, esta provisão é feita como tempo e de orçamen-
to extra. Para tornar realísticos os compromissos assumidos em face da incerteza, o
planejamento do projeto deve conter contingência. Simplificando, a incerteza é ate-
nuada pela contingência. E é essa a razão para se dedicar mais tempo a essa fase,
o que em geral não é feito, pela urgência de se por o projeto em andamento para
realizá-lo no tempo desejado pelos stakeholders.
Este é o problema crônico mais verificado em projetos conduzidos por em-

presas da área, e em diversos casos, é a principal causa para atrasos dentro do Ge-
renciamento de Projetos. A inclusão de contingências desnecessárias, no entanto,
aumenta significativamente o tempo previsto e o custo do projeto. Portanto, existe
pressão para minimizar contingência adicionada a projetos.
61
Como resultado disto, para garantir a existência de proteção suficiente em

planejamento de projetos, tornando as metas realizáveis, as práticas de gerencia-
mento de projetos evoluíram para disfarçar desperdícios de tempo como aparentes
proteções. Simplificando novamente, “a incerteza exige contingências, mas a pres-
são promove dissimulação” (ROBINSON; RICHARDS, 2010).
As boas práticas de gerenciamento de projetos específicos funcionam da

seguinte forma: os blocos de construção básicos dos modelos de requisitos são as
atividades, que consomem tempo e recursos, e produzem saídas usadas por outras
atividades. Existem relações explícitas e implícitas entre atividades que, juntas,
compõem o modelo global da logística do projeto. Desse modelo, se derivam os re-
quisitos de orçamento, duração e data de entrega. Para disfarçar as contingências
necessárias de forma a atender requisitos reais, normalmente se insere segurança
suficiente em cada atividade para garantir que suas chances de ser concluída no
tempo e no orçamento sejam elevadas (ROBINSON; RICHARDS, 2010).
A quantidade de contingência por atividade para garantir que seu desempe-

nho seja confiável não é trivial. Pode se afirmar que quanto mais incerto o ambiente
e mais significativas às consequências da falha de requisito, maior a importância
dada à segurança incorporada no planejamento (ROBINSON; RICHARDS, 2010).
A partir dessa premissa, pergunta-se: "Se os projetos que falham têm uma
considerável contingência embutida nestes, por que ainda assim falham?”.
Conforme GOLDRATT (1997):
... Projetos falham a execução dentro do prazo e do orçamento estipulados

pelos requisitos, apesar dos próprios requisitos já incluírem contingências
consideráveis, porque a existência destas contingências leva a adoção de
comportamentos específicos pelos membros da equipe do projeto.
GOLDRATT (1997).
Estas situações conseqüentemente resultam em efeitos negativos não inten-

cionais em relação ao desempenho do projeto.
62
Como exemplo concreto das razões pelas quais as contingências causam

impactos nas decisões da equipe, só por se saber que há mais tempo e dinheiro
disponível que o necessário, a equipe se influencia quanto às decisões de rotina a
serem tomadas sobre a realização do trabalho.
Essa é uma situação “onipresente” em diversas atividades conduzidas e in-

terligadas com outras atividades de projetos. Elaboração de documentos de Enge-
nharia, revisão de propostas, solicitação de cotações, confirmação de pedidos de
compra, comunicação com fornecedores, confirmação de despachos de importa-
ções, etc., todas as atividades sem exceção, sempre incluem contingências (e as
consomem mesmo desnecessariamente) desde a iniciação até a entrega final do
projeto ao cliente. Em cada etapa desse processo sempre fica evidenciado o mau
uso das contingências incluídas.
Exercitando o exemplo, a existência de contingências proporciona a cada

entidade individual ou organizacional da equipe, graus significativos de flexibilidade
na escolha de como organizar e executar tarefas, o que motiva um comportamento
de gerenciamento e uso de recursos. Esta flexibilidade é a única e mais importante
ferramenta que gerentes dispõem para ajudá-los a reagir e lidar com evoluções não
programadas, diariamente, e, como tal, sua existência é segredo guardado a sete
chaves. Mas, para manter “o segredo”, os gerentes, e os recursos desenvolvem
condutas arquetípicas comuns aos ambientes de gerenciamento de projetos.
Devido aos efeitos negativos destas condutas reverterem nos projetos como
consequências involuntárias de ações isoladas, no entanto, quando bem-
fundamentadas, a presença desses efeitos não é facilmente detectável nas organi-
zações.
Em outras palavras, na maioria das vezes, os mesmos passam despercebi-

dos, principalmente quando mascaram desperdícios não detectáveis de tempo e
custo, já cobertos pelas contingências.
63
2.6 OS ARQUÉTIPOS DO MAU GERENCIAMENTO DE PROJETO
Citando ELDER (2006), existe uma importante questão a responder nesse

caso: “Como é possível completar mais projetos, mais rápido, sem sacrificar a quali-
dade ou escopo, quando os recursos já estão muito sobrecarregados?”. Primeiro,
precisa-se saber se os projetos estão sofrendo de algum desses efeitos indesejáveis
(ou mais de um deles combinado):
• Atrasados
• Recursos sobrecarregados
• Mudanças em excesso (devido aos longos prazos do projeto)
• Recursos não disponíveis quando necessários (mesmo quando prometidos)
• Prioridades mutáveis e/ou retrabalho
Conforme ELDER (2006) descreve, “projetos sofrem de destinos similares”.

Pesquisando-se inúmeros livros, artigos e sites sobre gerenciamento de projetos é
possível descobrir que sobre gestão de projetos, sempre são identificadas os mes-
mos problemas, como visto na Figura 2-22.
Figura 2-22 - Problemas mais frequentes em projetos.

FONTE: PMSURVEY.ORG (2014)
Através dos anos os projetos sofrem os mesmos efeitos. Qual a razão para
isso? O que pode causar tais falhas, universalmente, e por tanto tempo?
64
Mesmo acreditando que seu trabalho é diferente, descobrirá que “não impor-
ta em qual tipo de projetos se atue ou se gerencie; projetos de energia, militares, de
TI, de construção e de inúmeros outros campos sofrem de destino idêntico: Todos
estão sujeitos ao atraso” (ELDER, 2006). Como visto nas Figuras 2-23 a 2-25 a se-
guir, isso impacta nas exigências, expectativas e julgamentos feitos sobre os profis-
sionais de gerenciamento de projeto pelas empresas fazem em função de expectati-
vas não atendidas na condução, gerenciamento e realização dos projetos. Por fim,
temos a indicação do grau de satisfação do cliente quanto aos prazos de entrega.
Figura 2-23 - Habilidades necessárias/valorizadas ao gerenciar projetos.

Figura 2-24 - Principais deficiências dos gerentes de projetos.

65
Figura 2-25 - Frequência de problemas relacionados ao cumprimento dos prazos estabelecidos.

Conforme GOLDRATT (1997), as cinco principais causas para atrasos na

condução de projetos, denominadas como “sintomas” (referindo-se às mesmas co-
mo se analisasse as causas de uma “doença” nos procedimentos de gerenciamento
de projetos), e que autores recentes descrevem como arquétipos comportamentais
dos gerentes de projeto e os recursos são estas:
• Multitarefa Nociva
• Síndrome do Estudante (ou Procrastinação)
• Lei de Parkinson
• Dependência entre Tarefas
• Matemática do Gerenciamento de Projetos
Porque as organizações devem se preocupar com esses cinco “sintomas”?

Simplesmente porque esses sintomas atrasam os benefícios e resultados dos proje-
tos para as mesmas e os stakeholders. Esses sintomas também atrasam o fluxo de
caixa de projetos finalizados e permitem a equipe e ao cliente encontrar janelas de
oportunidades para fazerem mudanças que ameacem o próprio projeto. Pode-se
imaginar a redução de pedidos de alteração, se os projetos fossem completados
mais rápido. É importante ter em mente que, se a organização continuar a fazer o
que sempre fez, ela continuará obtendo o que sempre obteve, ou seja, nesse caso,
seus projetos estarão sempre atrasados (ELDER, 2006; GOLDRATT, 1997).
66
2.6.1 Arquétipo Nº 1 - A Multitarefa Nociva
O gerente de projetos ou “recursos” enfrentam constantemente prioridades

que mudam, interrompendo atividades e se concentrando em outras? Existe algum
stakeholder esperando pelo output da sua atividade para que ele possa fazer a sua
própria? Esta é a definição direta da Multitarefa Nociva (ELDER, 2006; GOLDRATT,
1997).
Dito isto, nem toda multitarefa é nociva. Quando ninguém está esperando
por inputs não há nada de errado em comutar entre várias tarefas. Mas por que as
pessoas fazem multitarefas? Para alguns é por causa do tédio de se trabalhar em
uma coisa por vez. A mente humana exige níveis de estimulação maiores, logo, to-
dos mudam constantemente seu foco. Geralmente a culpada é a nossa má prioriza-
ção de tarefas (ELDER, 2006; GOLDRATT, 1997).
Pedem-nos para iniciar várias tarefas simultaneamente e cada uma delas

possui um stakeholder esperando por sua saída. Cada stakeholder quer que a sua
atividade progrida e constantemente pergunta “já terminou?”, forçando aos recursos
comutarem repetidamente para a atividade deles para que algo seja feito e se possa
reportar o progresso. Enquanto estão trabalhando nesta atividade, outros stakehol-
ders pedem os status das suas respectivas atividades. Este ciclo força aos recursos
a comutarem atividades repetidamente (ELDER, 2006; GOLDRATT, 1997).
Naturalmente, ao trabalhar numa atividade o recurso não está fazendo pro-

gresso em nenhuma outra. Se seus stakeholders contam com entregas rápidas, eles
levarão seus projetos para outro lugar. Para alguns stakeholders só o progresso já é
suficiente. Não é necessário que seja rápido, desde que esteja sendo feito. Porém,
mesmo que a organização tenha competência e sorte o bastante para manter tais
clientes, qual é o impacto na mesma? Qualquer quantidade de tempo que não está
se trabalhando em alguma atividade significa que a atividade está sendo mais atra-
sada do que estaria se atrasando se o recurso associado à atividade estivesse
100% dedicado a sua conclusão (ELDER, 2006).
67
Dessa forma, a multitarefa sempre faz com que atividades acabem levando
mais tempo do que deveriam. Entre os fatores que se somam está o tempo de racio-
cínio que leva para “voltar ao foco”. Para tarefas de engenharia, programação e re-
dação esse tempo pode ser uma parte significativa do tempo total da tarefa quando
se faz multitarefa. Em trabalhos manuais isto equivale ao tempo de ajuste (setup) da
máquina, de preparação das ferramentas e dos equipamentos apropriados e colocá-
los de volta em seus lugares (ELDER, 2006).
Existem tarefas onde o tempo de ajuste é desprezível e não é fator, mas es-
sas são poucas no mundo do trabalho intelectual. Estimativas indicam que o tempo
de raciocínio, pode igualar ou até exceder o tempo real, para tarefas altamente cog-
nitivas. A forma mais rápida de completar a atividade é começá-la e fazê-la até ter-
miná-la. O recurso pode, então, concentrar-se na atividade e no seu stakeholder. É
mais rápido e fornece o melhor serviço a ele. Ninguém reclama, a menos que a fila
fique muito grande. Quando se faz a comutação de tarefas, o risco de haverem pro-
blemas com a qualidade também aumenta. Acaba-se esquecendo do que foi e do
que não foi feito. Entra-se numa corrida para retornar a outra tarefa. Acaba-se pas-
sando por cima de pequenos detalhes em nosso ajuste. E são os pequenos detalhes
que podem acabar fazendo grandes diferenças (ELDER, 2006).
A pressão dos stakeholders irritados inclui estresse ao trabalho, deixando os

recursos menos satisfeitos e cada vez mais sujeitos a negligenciar um bom serviço.
O envolvimento da gerência aumenta, para se lidar com stakeholders “importantes”,
e a aceleração começa a tornar-se uma forma de lidar com eles. Conforme mais
stakeholders comecem a exigir serviços mais rápidos, a gerência passa a focar em
métodos complexos de priorização de atividades para satisfazer a todos e para man-
ter os empregados focados em “fazer a coisa certa” (ELDER, 2006).
A multitarefa nociva força as pessoas a dar estimativas maiores que o ne-

cessário para as tarefas. Se o recurso sabe que não será permitido a ele iniciar uma
atividade, e trabalhar nela até terminá-la e depois passar para a próxima, este será
forçado a dar estimativas maiores (incluir contingências para se preservar) sobre o
tempo que levará para completar a atividade (ELDER, 2006).
68
Se ele sabe que levará dois dias para completar uma tarefa, mas também
sabe que será interrompido (contingência), ele incluirá o tempo de interrupção na
estimativa. Agora, uma tarefa de dois dias passa a ser estimada em 10 dias. Consi-
dere então essa circunstância: “O cliente esperará dez dias?”. O gerente então terá
que decidir. “Será que o cliente ficaria mais motivado a fazer negócio com a organi-
zação se o gerente prometesse dois dias em vez de dez?” (ELDER, 2006).
Imagine a vantagem competitiva de se comprometer com um prazo de me-

nor duração. Imagine o melhor ambiente de trabalho criado para os membros da e-
quipe quando o gerente elimina métodos complicados de priorização, a aceleração,
os clientes zangados e a constante vigilância da gerência (ELDER, 2006).
Para demonstrar efeitos da multitarefa nociva podem ser simulados projetos

reais, onde os recursos realizem projetos (3) com multitarefa. Os efeitos criados por
esta simulação serão caóticos: confusão, quantidade enorme de ordens e atividades
adicionais de “gerenciamento” (ELDER, 2006).
Ao terminar essa etapa da simulação, os recursos serão desafiados a fazer

duas vezes mais projetos (6) em menos tempo que os originais. Isso é possível? A
diferença é que nesse caso será removida toda a multitarefa nociva, mantendo-se o
foco; na prática, os recursos sempre realizam duas vezes mais projetos em menos
tempo e sem caos, gritaria, e estresse (ELDER, 2006).
A única diferença entre os dois eventos é a multitarefa nociva. Quando uma

equipe está fazendo multitarefa isso exige uma sobrecarga maior de gerenciamento.
Alguém precisa manter registro do que está sendo feito, o status, o tempo previsto
de término, e atualizar o cliente repetidamente. Cada parte dessa sobrecarga pode
ser eliminada (ELDER, 2006). Se a experiência da empresa é parecida com isso, o
gerente ganhará muito removendo esse obstáculo. Se o objetivo é conseguir produ-
zir duas vezes mais, no mesmo tempo, e reduzir o estresse, o gerente terá que eli-
minar a multitarefa. A Figura 2-26 a seguir fornece um exemplo gráfico dos resulta-
dos da sequência multitarefa versus a sequência não multitarefa.
69
Figura 2-26 - Sem multitarefa X Com multitarefa

FONTE: ELDER (2006)
Pode se observar o término antecipado devido à remoção do tempo de ajus-

te (raciocínio). Também é possível observar o prazo de entrega de cada atividade.
Mesmo que as duas situações levem o mesmo tempo total (tempo de ajuste zero), a
vantagem de não fazer multitarefa é significativa. Se algum stakeholder está espe-
rando pelo resultado da Tarefa-A antes de realizar a própria, é fácil ver que sem a
multitarefa a próxima tarefa vai começar mais cedo. Pode-se notar ainda que com
multitarefa as 3 atividades são concluídas quase que juntas. Se os resultados das
atividades forem para o mesmo recurso, este agora herdou a carga da multitarefa.
Isto cria uma pilha de trabalho concluído que se move a jusante, como um excesso
de trabalho em produção. E mais, pode-se ter perdido tempo enquanto o próximo
recurso esperava pelo output. Este pode ficar “ocupado com trabalho”, para não ser
pego desocupado (e acabar demitido). O tempo gasto em “ocupação com trabalho”
não avança o projeto e pode até mesmo ter atrasado o mesmo (ELDER, 2006).
O gerente pode ser questionado sobre o “tempo morto” entre atividades.

Uma resposta para essa pergunta seria: “É para se supor que se fique sentado, sem
fazer nada, quando chegar a um ponto de atividades onde esteja esperando pelo
resultado de outros recursos?” Evidentemente que não. Para isso se espera que
uma pessoa nesta posição tenha pelo menos algum grau de pró-atividade em sua
atitude pessoal (ELDER, 2006).
70
2.6.2 Arquétipo Nº 2 - Lei de Parkinson
Como observado no tópico anterior, a multitarefa nociva leva membros da

equipe a embutir contingência nas estimativas de atividades. É necessário examinar
melhor a estimação de atividades e avaliar a validade e o prejuízo causados por se
inflacionar a contingência nas estimativas de tempo das atividades (ELDER, 2006).
Quando se atribui uma atividade a um recurso, a primeira pergunta feita é:

“Quanto tempo você vai levar para concluir?” Nesse caso, pode-se concordar que as
pessoas possuem uma tendência a incluir “proteção” (contingenciar) na estimativa
de tempo dessas atividades, para que possam incluir “fatores externos” (“Murphy” e
multitarefa)? Pense então em atividades recentes que alguém tenha estimado. Qual
foi o nível de certeza? 100%? Provavelmente não, pois algo pode acontecer e impe-
dir a conclusão da atividade e, portanto, estimar 100% de certeza, é algo que não é
realizável (ELDER, 2006).
Que tal 50%? Mesmo neste nível de certeza o recurso estará atrasado em 5
de cada 10 vezes. Talvez a oferta tenha ficado próxima a 90%. Isto significa que 9
em cada 10 vezes se está no prazo. Isto parece razoável? Qual o nível de certeza
exigida das equipes? Foi exigido que as estimativas fossem sempre precisas? Ou
são aceitos atrasos em 5 de cada 10 vezes? A maioria dos gerentes exige que os
recursos forneçam “estimativas precisas”, o que não faz o menor sentido científico
porque uma estimativa, por definição, é apenas uma aproximação (ELDER, 2006).
Nesse caso todos, intelectualmente, entendem que as estimativas não são

exatas. E ainda assim, todos as exigem. Por quê? A questão é que nesse caso, exis-
te a crença subjacente de que se pode determinar precisamente o tempo de cada
atividade, e por extensão, de que de se assegurar que cada atividade será termina-
da “no prazo”, então o projeto terminará no prazo. Porém, também sabem que o ob-
jetivo não é terminar a atividade no prazo, mas completar o projeto no prazo. A reali-
dade inerente do trabalho de qualquer projeto é que a incerteza existe e, portanto, o
tempo das atividades não pode ser determinado, apenas estimado. Como resultado
imediato da exigência feita de se apresentar estimativas precisas é que estas esti-
mativas de duração são convertidas em compromissos (ELDER, 2006).
71
Assim, para fornecer uma estimativa realista é preciso levar em conta todas
as coisas que podem impactar na duração da tarefa, embutindo segurança. Quando
se adiciona segurança às estimativas elas são consideradas razoáveis porque, men-
talmente, essa segurança é adicionada pensando-se em distribuição normal do tem-
po. Em uma distribuição normal do tempo, 50% estão de um lado e 50% estão do
outro lado da média. Assim, passar de 50% para 80% de probabilidade não parece
ser significativo, como visto na Figura 2-27 (ELDER, 2006).
Figura 2-27 - Curva de distribuição do tempo de atividades imaginada

FONTE: ELDER (2006)
Porém, leve-se em conta que tempos de atividades não são “normais”. Na

prática, não existe essa definição de “normal”. A distribuição normal ocorre apenas
na matemática, com números, e não na vida real. Pelo Teorema do Limite Central,
se for usado um número de amostras grande o suficiente, pode se ter a distribuição
“normal”. Tempos de atividades não seguem a curva normal. Em vez disso, eles co-
meçam em algum lugar além do zero (toda atividade levar algum tempo) e então a
probabilidade de concluí-la no prazo aumenta rápido, e em seguida, diminui numa
longa cauda, como visto na Figura 2-28 abaixo (ELDER, 2006).
Figura 2-28 - Curva de distribuição do tempo de atividades real

FONTE: ELDER (2006)
72
Quando se compara os dois gráficos observa-se que aquela “pequena” se-

gurança embutida é, na realidade, bem grande. Quanto maior a incerteza da tarefa,
maior fica a cauda. O resultado é uma tarefa com aproximadamente metade da sua
duração estimada sendo segurança. É viável afirmar com certeza absoluta que os
únicos a incluírem segurança são os membros individuais da equipe? Nunca. Poste-
riormente, o gerente toma as atividades estimadas com segurança e adiciona a sua
própria segurança. A cada nível de gerência mais segurança é embutida, conforme
visto na Figura 3-9 abaixo (ELDER, 2006).
Figura 2-29 - Efeito cascata do contingenciamento no tempo das atividades

FONTE: ELDER (2006)
A segurança adicional adia a data de término do projeto sem necessidade e,

na verdade, não protege contra a incerteza. Outro problema ocorre porque todos
inflacionam as estimativas sabendo que o gerente irá cortá-las. Já que o recurso não
sabe quanto será arbitrariamente cortado, ele “estima” quanto inflacionar o tempo. O
gerente não tem idéia da contingência adicionada, e “retira” a mesma, “estimando” o
quanto acha que foi adicionada. Têm-se então os seguintes questionamentos: “Se
há tanta segurança embutida em cada tarefa, por que as tarefas continuam a atra-
sar? Nesse caso elas não deveriam terminar no prazo, ou antes?”.
73
Se concordarmos que a segurança é embutida para se considerar as “con-

tingências desconhecidas” (Murphy), e que estas não ocorrem em todas as ativida-
des como foi previsto, então a maioria das atividades não deveria terminar no prazo.
Elas deveriam terminar bem antes do tempo previsto. Apenas atividades ocasionais,
com todos os possíveis imprevistos imaginados durante a estimação, com sorte mui-
to pior, poderiam atrasar. Se as atividades não estão terminando antes na maior par-
te do tempo, então a segurança está sendo perdida. Mesmo as atividades que ter-
minam no prazo são inaceitáveis, pois aproximadamente metade do tempo estimado
para elas estava reservada para eventos que nunca ocorreram (ELDER, 2006).
O mais notável ainda é que as pessoas se esforçam para cumprir o pedido

absurdo de fornecer estimativas precisas. Por quê? Essa é uma pergunta bem sim-
ples de se responder. É possível se concordar que a maioria das pessoas quer ser
considerada confiável? Se esse é o caso, isto significa que todos tentam cumprir
compromissos, certo? E se é verdade, o resultado é que se adicionam contingências
e se luta para impedir que essas contingências sejam removidas por outros. Se exis-
te “segurança extra” que não é necessária, então o “tempo extra” é usado para fazer
um trabalho melhor, em vez de reportar a conclusão antecipada. Afinal, se foram
exigidas 6 semanas e foi entregue em 4 semanas, qual será a “recompensa” por se
entregar antes, na próxima em vez que se pedir 6 semanas para uma atividade? A
segurança será cortada. Isto pode fazer com que os recursos falhem em seus com-
promissos, se atrasando e se tornando não confiáveis (ELDER, 2006).
Este fenômeno é tão predominante que possui seu próprio nome: Lei de
Parkinson. Esta lei expressa que:
“O trabalho se expande para preencher o tempo disponível para a sua reali-

zação.”
Cyril Northcote Parkinson, The Economist, UK, Novembro de 1955.
Agora todos devem concordar que as pessoas realmente adicionam segu-

rança, mas ela não está sendo usada apropriadamente. Sua prova é que a maioria
das tarefas não termina antes, como seria esperado (ELDER, 2006).
74
2.6.3 Arquétipo Nº 3 - Procrastinação ou Síndrome do Estudante
Procrastinação é o diferimento ou adiamento de uma ação. Embora a pro-

crastinação seja considerada normal, ela torna-se um problema quando impede o
funcionamento normal das ações. A Síndrome do Estudante, também conhecida
como Procrastinação, refere-se aqui ao fenômeno de que a maioria dos estudantes,
só começa a se dedicar inteiramente a uma tarefa logo antes do prazo final. O termo
foi cunhado originalmente por GOLDRATT (1997) no livro Corrente Crítica.
A grande diferença na comparação com o ambiente corporativo são as ra-

zões para adiar o trabalho. Procrastinar nesse caso é ser preguiçoso ou ser irres-
ponsável. A Síndrome do Estudante é um mecanismo de defesa natural. Significa
adiar o trabalho até o último momento possível, não por ser preguiçoso, pelo contrá-
rio, esta se trabalhando duro. Todos caem presas da Síndrome do Estudante ocasi-
onalmente. Esse “sintoma” (ou arquétipo) ganhou esse nome pela forma como os
estudantes lidam com o dever de casa (GOLDRATT, 1997).
Imagine um professor dizendo ao aluno que ele tem uma prova final em 19
semanas. O professor dá ao aluno a matéria que cairá na prova, indica o livro, os
objetivos que serão testados e a data. Quando é que o aluno começa a estudar? Na
véspera da prova. Por quê? Ele tem tempo, é por isso. Outras tarefas pressionam
mais e, portanto, o aluno atrasa o início da tarefa de estudar para a prova até o últi-
mo momento, para lhe dar tempo de completar outras atividades, muito provavel-
mente também sendo feitas no último momento (ELDER, 2006).
Em geral, todos dizem que não sabem estimar com precisão o tempo que
uma tarefa irá durar. Essa é uma afirmação da qual se pode discordar veemente-
mente. A evidência para esta afirmação é que as pessoas realmente sabem o último
minuto possível que elas têm para iniciar uma tarefa, ou arriscar atrasar. Quando foi
a última vez em que se adiou algo até o último minuto e ainda assim foi-se capaz de
escolher o último minuto real? Trabalhou-se a noite toda para concluir a tarefa e im-
primir o resultado exatamente antes da grande reunião. O papel ainda está morno
na entrega, mas conseguiu-se (ELDER, 2006).
75
Esse problema torna-se mais sério quando se consideram os riscos do

mesmo na qualidade do que é feito. Pode se escolher o último momento possível
para completar a atividade, mas qual é a conseqüência potencial sobre a qualidade?
E se algo dá errado? Não há tempo hábil para consertar. Portanto, pode-se concluir
que a maioria das pessoas realmente sabe exatamente quanto tempo uma tarefa irá
demorar a ser concluída quando elas podem se dedicar a ela (ELDER, 2006).
Se o que se quer são estimativas precisas (nunca exatas!), é preciso definir

a data de entrega e perguntar: “Se esta atividade for iniciada no último minuto,
quando é que esse minuto aconteceria?” Agora se tem a estimativa do tempo da
tarefa. A dificuldade em estimar o tempo de atividades não é saber o tempo que vai
demorar a ser concluída, mas “calcular” quais fatores considerar, já que se sabe que
não será permitido trabalhar nesta sem interrupção. Se o recurso está inseguro so-
bre o tempo que levará, provavelmente é porque não sabem quando terão todos os
inputs necessários para realmente começar a atividade, sem interromper e coletar
mais informações. O gerente deve lembrar aos recursos que estão estimando e que
ele só quer saber o tempo para concluir as atividades sem interrupções, com todas
as entradas necessárias disponíveis (ELDER, 2006).
Deverá documentar entradas necessárias para garantir que não será pedido
aos recursos que iniciem atividade sem as entradas estarem sob sua posse. O tra-
balho do gerente é garantir que os recursos tenham o necessário para realizar o seu
trabalho. Enquanto o gerente sobrecarregar recursos com atividades e permitir que
estes inflacionem seus prazos para acomodar outras tarefas, ele perpetuará a Sín-
drome do Estudante. Isso é ampliado pela multitarefa. O gerente tem a equipe traba-
lhando em múltiplas atividades com tempos inflados e espera que esta priorizem tais
atividades. As atividades urgentes terão precedência sobre as importantes. Isto en-
coraja a inclusão de contingencias nas atividades, aumentando o tempo mais que o
realmente necessário, então os recursos atrasam o início das atividades até terem
absolutamente o que começar, devido às demandas concorrentes. E o que acontece
quando a atividade realmente encontra um problema? Onde está a segurança? (A
pergunta correta é: “Quando é que se usa a segurança?”). A segurança ficou no
passado. Não se pode usá-la mais, como pode se vê nas Figuras 2-30 e 2-31 (EL-
DER, 2006).
76
Figura 2-30 - Como as pessoas tentam se proteger pelo contingenciamento

FONTE: ELDER (2006)
Figura 2-31 - O que efetivamente ocorre graças à Síndrome do Estudante

FONTE: ELDER (2006)
Nota-se, na figura, que quando se inclui segurança, mentalmente, se coloca

a proteção no final da atividade. Porém, devido à Síndrome do Estudante, os recur-
sos não começam a atividade imediatamente e, sim mais tarde. Quando o problema
ataca, a segurança com a qual se conta já não está mais disponível (ELDER, 2006).
A maioria das pessoas enfatizará que estas afirmações não são verdadeiras.
Na verdade as equipes fornecem estimativas que quase sempre cumprem. Entretan-
to, ela é verdade porque é uma profecia auto-realizável. A atividade torna-se vítima
das questões mencionadas anteriormente, fazendo com que seja completada como
previsto, porque as pessoas querem ser vistas como confiáveis. Como se percebe,
se a atividade é iniciada logo e não há problemas sérios, a segurança adicionada é
consumida pela Lei de Parkinson. Se a atividade não é iniciada logo e ocorrem pro-
blemas, esta acaba atrasada. Se a atividade inicia atrasada (Síndrome do Estudan-
te) e nada dá errado, a tarefa é completada “no prazo”. De um jeito ou de outro, toda
a segurança é gasta. Esse é um tempo que faz a duração do projeto ser estimada
além do necessário. Isso também torna o projeto menos competitivo. E isto afeta a
produtividade da empresa que é a sua META (ELDER, 2006).
77
2.6.4 Arquétipo Nº 4 - Dependência Entre Tarefas
Em projetos, todas as atividades dependem umas das outras. Frederick Bro-

oks, no seu livro (BROOKS, 1975), respondeu à pergunta sobre como os projetos
atrasam: “Um dia por vez”. Já observaram que se a data final do projeto se desloca
no cronograma, é praticamente impossível recuperá-la? Também já observaram o
quão fácil é atrasar, mas o quanto é difícil adiantar? Se for o caso, então já entende
os problemas criados pela dependência entre tarefas (ELDER, 2006).
Um efeito negativo causado pela dependência entre tarefas é explicado no

seguinte exemplo. Tem-se uma atividade estimada em 5 dias, já incluso aí a segu-
rança, e esta é iniciada logo concluindo-se a mesma “mais cedo”. O recurso que re-
ceberá esta “saída” está pronto para usá-la? Geralmente não. Portanto, se os resul-
tados forem entregues nos próximos 3 dias, o próximo recurso não vai sequer tocá-
los nos 2 dias adicionais subsequentes, porque ele não está agendado para come-
çar sua atividade até aquele dia. Assim, a segurança embutida é perdida, mesmo
com a tarefa concluída antes. Para superar esse problema é preciso ter um sistema
de projetos que garanta que todas as atividades iniciem, não quando estão agenda-
das para começar, mas quando os inputs estiverem disponíveis. Isso é vital com as
tarefas no caminho crítico ou na corrente crítica (ELDER, 2006).
Outro efeito negativo causado pela dependência entre tarefas é bem conhe-
cido na Teoria da Probabilidade como a “Probabilidade de Eventos Dependentes”.
Essa teoria afirma que “o tempo total requerido para eventos dependentes, em ter-
mos de probabilidade, é o produto da probabilidade de todos os eventos dependen-
tes”. Veja como isso impacta a organização na Figura 2-32 a seguir.
Figura 2-32 - Probabilidade de eventos dependentes (Atividades Sequenciais)

FONTE: ELDER (2006)
78
Se você tem três tarefas que são dependentes uma da outra, e cada uma
tem uma chance de 90% de ser terminada no prazo, qual é a probabilidade das três
serem completadas no prazo? Cerca de 73%! Calcula-se a probabilidade de terminar
a Tarefa-1 (90%) e depois a probabilidade de terminar a Tarefa-2, dada a depen-
dência desta com a Tarefa-1 (90% x 90% = 81%). Como se observa, a probabilidade
de terminar a Tarefa-1 e a Tarefa-2 no prazo é de apenas 81%. Calcula-se a proba-
bilidade de terminar a Tarefa-3, dada à dependência da Tarefa-1 e da Tarefa-2 ter
sido completadas no prazo (90% x 90% x 90% ≈ 73%). Ou seja, com apenas três
tarefas, e cada uma com 90% de chance de terminar no prazo existe apenas uma
chance de 73% de terminar, de fato, todas as três no prazo (ELDER, 2006).
Não são necessárias muitas tarefas para obter probabilidade zero de se ter-
minar o projeto no prazo. Nesse ponto todos afirmarão: “Nesta empresa não existe
esse problema, porque as atividades são realizadas em paralelo, em vez de em sé-
rie.” Examine-se esta solução como visto na Figura 2-33 a seguir.
Figura 2-33 - Probabilidade de eventos dependentes (Atividades Paralelas)

FONTE: ELDER (2006)
Se cada tarefa possui uma chance de 90% de ser feita como planejado, qual
é a chance do projeto terminar no prazo? A primeira resposta pode ser 90%, mas, já
que o término do projeto depende do término de todas as tarefas, usa-se o produto
de cada evento dependente para calcular o tempo de término. Assim, multiplica-se
90% de cada tarefa em paralelo, obtendo a mesma chance de 73% de término no
prazo. Agora se vê porque tentar fazer que cada tarefa termine no prazo não signifi-
ca que o projeto termine no prazo. É necessário que todas as tarefas dependentes
sejam concluídas no prazo, para que o projeto termine no prazo (ELDER, 2006).
79
Isso faz que os gerentes de projetos concluam que a única forma de findar
um projeto no prazo é garantir que todas as tarefas, realmente, terminem no prazo.
Tal solução exige que tarefas sejam estimadas com 100% de precisão. Ainda que
fosse possível, isso faz os tempos das tarefas durarem inimaginavelmente. Examine
a Figura 2-34 a seguir para entender como atrasos são passados adiante, mas adi-
antamentos não. Este projeto é planejado para durar 17 dias. Se a primeira tarefa
acabar cinco dias adiantada o quanto adiantado ele poderia acabar? Os mesmos 17
dias. A razão é que se dependem do término de todas as cinco tarefas. Portanto,
mesmo quando tarefas estão adiantadas, o projeto não termina adiantado em nada.
E se as primeiras quatro tarefas terminam 5 dias antes? A duração do projeto ainda
é de 17 dias. Agora pense na duração do projeto se apenas uma tarefa atrasar 5
dias: o projeto agora leva 22 dias (ELDER, 2006).
Figura 2-34 - Probabilidade de eventos dependentes (Paralelas)

FONTE: ELDER (2006)
Como observado, adiantamentos em geral, não são passados adiante, mas

os atrasos sempre são. Dependência adicional não discutida, e geralmente proibida
na Metodologia do Caminho Crítico, é a dependência de recursos. Na Figura 2-35 a
seguir, pode-se observar um projeto com dependências de tarefas e recursos. Veja
que as atividades A e D requerem o recurso “programador” (ELDER, 2006).
Figura 2-35 - O problema da dependência de recursos compartilhados

FONTE: ELDER (2006)
80
Para completar as tarefas C e D tem que se completar A e B. Para iniciar a

tarefa D também se precisa completar a tarefa A, devido à dependência de recurso.
Dado que cada tarefa possui probabilidade de terminar no prazo de 90%, qual é a
probabilidade do projeto terminar no prazo? Apenas 73%! Embora não exista uma
seta interligando a tarefa A com a D, a dependência entre os recursos permanece.
Nessa dependência se acham todos os problemas descritos antes (ELDER, 2006).
Então se examine o círculo vicioso de lógica que ocorre por se converter es-
timativas em requisitos. Lembra-se de que as pessoas querem ser vistas como con-
fiáveis e, portanto, todas tentam completar as tarefas o mais próximo possível do
prazo. Este fato impede a remoção da contingência das estimativas futuras e as fa-
zem sentirem-se confiáveis. Mas quando o projeto atrasa, qual é a resposta típica
que se tem? Conduza uma atividade simulada pelas lições aprendidas e identifique
as atividades que atrasam o projeto (ELDER, 2006).
Qual é o comportamento criado por essa descoberta? Como se observa isso

vira um “loop” negativo. Ocorrem atrasados culpam-se as atividades, incluem-se
mais contingências, ficam atrasados novamente, culpam-se as atividades, incluem-
se mais contingências, e assim sucessivamente. Assim, os stakeholders procurarão
a concorrência, porque seus projetos demoram demais e custam muito. Quem de-
terminará o quanto pode aumentar o cronograma e os custos por conta de gerenci-
amento deficiente são os stakeholders da organização. E geralmente os cortes são
inevitáveis (ELDER, 2006).
A última questão é relacionada com atividades que se integram umas com

as outras. Qualquer lugar em que há integração de atividades há riscos adicionais.
As coisas nem sempre se encaixam entre si conforme o esperado. O que acontece
quando atividades que se integram apresentam problemas? O projeto é atrasado.
Colocam-se contingências nesses pontos, mas ela é desperdiçada como descrito.
Os problemas podem ser superados por métodos de agendamento que considerem
a variação e a incerteza nos tempos das atividades e não apenas declarando que os
recursos “devem” terminar no prazo. O método de gerenciamento de projetos que
cuida da gestão dessas questões é chamado de Corrente Crítica (ELDER, 2006).
81
2.6.5 Arquétipo Nº 5 - Matemática do Gerenciamento de Projetos
No gerenciamento de projetos as coisas nem sempre são o que parecem.

Esse efeito negativo é simples, embora na maioria das vezes ele seja negligenciado.
Se há um projeto com duas tarefas, cada uma com 2 dias de duração, quanto tempo
ele leva? Sem considerar as questões acima, a resposta acima seria 4 dias.
Mas, sabe-se que a probabilidade é menor do que se pensa. Observe: está

se trabalhando na Tarefa-1 e os outputs vão para o recurso que irá realizar a Tarefa-
2. Assuma-se que o recurso é “preciso” e que este começa as atividades no prazo,
trabalha duro nelas até concluírem, sem multitarefa, e completam as mesmas no
final do dia 2, no prazo. O normal é completar o trabalho, imediatamente levar os
resultados para o próximo recurso e entregar-lhe para ele começar sua parte? Não
(ELDER, 2006).
Porém, foi concluído no prazo, então se comunica o fim da atividade para se

receber o crédito de ter cumprido o prazo e encerra-se o dia. Na manhã seguinte
chega-se, lê e-mails e se faz outras atividades pendentes. Então pega os resultados
de ontem e entregam ao próximo recurso na fila. Foi perdida metade de um dia. A
seguir: “Será que o recurso para quem foram entregues os resultados parou imedia-
tamente o que estava fazendo, limpou a mesa e começou a trabalhar no próximo
passo para esse entrega?” Não (ELDER, 2006).
Ele agradece a entrega, provavelmente comenta que estão no prazo e am-

bos conversarão. O recurso reconhece que não há pressa de começar imediatamen-
te, já que existe uma rede de contingências embutida nas estimativas de tempo. A-
gora é a hora do almoço. O recurso retorna a sua sala, realiza outro trabalho, e pen-
sa em iniciar a sua atividade, mas, já é o final do dia, e que seria melhor iniciar ama-
nhã. Agora, outro meio dia está perdido. Quando o recurso começar a atividade na
manhã seguinte, já está um dia atrasado, causando atraso a outros, e agora o proje-
to está irremediavelmente atrasado. E é dessa forma que funciona a Matemática do
Gerenciamento de Projetos: ou seja, é como uma tarefa de 2 dias mais uma de 2
dias resulta em 5 dias (ELDER, 2006).
82
Será argumentado que o segundo recurso provavelmente irá acelerar e ter-

minar em um dia, e o projeto não ficará atrasado. Isto pode até acontecer. Prova-
velmente acontece com freqüência. Mas isso determina que a atividade não seja
mesmo uma atividade de dois dias, mas uma atividade de um dia com mais um dia
de contingência, a qual foi perdida, atrasando o projeto. Isso pode facilmente ser
superado garantindo que cada nome de tarefa inclua a transferência. Por exemplo,
em vez de “Concluir o relatório” como uma atividade, poderia ser “Marketing recebe
o relatório concluído”. Agora o recurso que realizou a tarefa não vai ganhar o crédito
por concluí-la até que esteja nas mãos do próximo recurso (ELDER, 2006).
Além disso, o recurso que realizou a tarefa não pode marcar a sua própria
atividade como terminada. Apenas o recurso que precisa da sua entrega pode vali-
dar que você “concluiu”. Isto impede entregas atrasadas assim como fornece ao pró-
ximo recurso na fila, à oportunidade de rejeitar resultados com má qualidade, que
impactem seu trabalho. Este método foi denominado de efeito “papa-léguas” por
GOLDRATT (1997). O efeito é similar à corrida de revezamento, onde se deve ter
certeza que a próxima pessoa na fila está sempre pronta para iniciar o trabalho nu-
ma tarefa do projeto quando entregue (ELDER, 2006).
2.7 A IMPLANTAÇÃO DA METODOLOGIA
As duas grandes questões que surgem sobre o gerenciamento de projetos

são o Planejamento dos Recursos e a Gestão dos Riscos. Os métodos tradicionais
tem se mostrado capazes de lidar com a questão do planejamento de recursos, mas
não fornecem absolutamente nenhuma resposta simples para a gestão dos riscos na
execução. A Gestão de Projetos pela Corrente Critica, com o Método de Gerencia-
mento de Pulmão, dá ao gerente de projeto alto grau de visibilidade, foco e controle
sobre as tarefas específicas através de uma infinidade de projetos que requerem a
sua atenção diariamente (HODES, 2009).
Apresenta-se aqui uma visão geral do significado da Corrente Critica, do Ge-

renciamento de Pulmão, do Recurso de Ritmo, da Razão Crítica e como todos estes
itens se encaixam para fornecer uma solução simples, elegante e de bom senso pa-
ra gestão da complexidade de múltiplos projetos.
83
2.7.1 A Natureza dos Riscos e da Complexidade
É fato da vida que em todos os esforços diários, nada é mais certo do que a
própria incerteza. Na área de Gerenciamento de Projetos isso se manifesta assim:
• Desempenho do fornecedor não confiável.

• Esforço necessário para completar tarefas desconhecido.
• Tempo para completar tarefas (mesmo as bem conhecidas) pode variar.
• Entrega dos recursos necessários é incerta.
• Disponibilidade de pessoas (com competências adequadas) não garantida.
Quando a incerteza é combinada com como se faz gestão das organizações,

geralmente baseada na responsabilidade funcional de atividades específicas, tais
como projeto, compras, operações, distribuição, marketing e vendas, então a com-
plexidade do gerenciamento de projetos torna-se esmagadora. Nesses casos, essa
complexidade é gerenciada dividindo as organizações em setores para controlar e
fazer com que cada setor seja responsável pelo próprio desempenho. Em geral, isto
se baseia na suposição da melhoria da soma do esforço das partes resultando na
melhoria da empresa, como um todo. A figura 2-36 abaixo mostra como o desafio de
gerenciar múltiplos projetos, através de uma gestão de recursos funcional, torna-se
mais complexo sob a influência da incerteza (HODES, 2009).
Figura 2-36 - O desafio de gerenciar múltiplos projetos

FONTE: HODES (2009)
84
Todos concordam que o fluxo de valor aos olhos do cliente é agregado atra-
vés das funções da empresa. Se a empresa atribui comando e controle da organiza-
ção dentro de setores, conflitos inerentes surgem entre gerentes de setor e os de
projeto sobre o uso dos recursos específicos em alta demanda. O gerente de setor
quer melhorar sua produtividade ou seu centro de custo e, simultaneamente, os de
projeto pressionam o cumprimento dos cronogramas. Como é que este conflito é
resolvido? Os métodos atuais são suficientes em um mundo mais e mais competiti-
vo? Deve-se encaminhar cada conflito à camada de gestão superior para ser resol-
vido? Como a “camada superior” decide qual é o melhor interesse para a empresa?
Que impacto as decisões arbitrárias têm sobre desempenho do projeto, percepção
de valor pelo cliente e moral do pessoal? (HODES, 2009).
2.7.2 As Cinco Etapas de Enfoque
A Teoria das Restrições, da qual o Gerenciamento de Projeto pela Corrente

Critica (CCPM) faz parte, é uma metodologia de melhoria contínua da produtividade
organizacional. É regra aceita da TOC que qualquer sistema tem dentro de si restri-
ções. Se assim não fosse, o sistema iria produzir uma quantidade infinita de resulta-
dos. Simplificando, uma restrição é qualquer coisa que impede o sistema de conse-
guir alcançar sua meta. Na linguagem de Gerenciamento de Projetos, “restrição é
qualquer coisa que impeça aos projetos conseguirem prazos de entrega nulos”
(HODES, 2009; GOLDRATT, 1997, 2014). A fim de melhorar o desempenho de um
sistema ou projeto, é necessário adotar as cinco etapas de enfoque da Teoria das
Restrições:
Figura 2-37 - As Cinco Etapas de Enfoque

FONTE: HODES (2009) / GOLDRATT (1997)
85
O que impede que projeto individual apresente prazo de entrega nulo é o

maior conjunto de eventos dependentes ao longo do projeto, considerando a prece-
dência de tarefas e a disponibilidade de recursos. Esta é definida como a Corrente
Critica.
E o Caminho Crítico? A definição do Caminho Crítico trata apenas da prece-

dência da tarefa. Se alguém opera em ambiente de recursos infinitos, a duração de
projetos é quase sempre prorrogada por contenção de recursos - diferentes tarefas
competindo pelos mesmos recursos. A definição da Corrente Critica considera a dis-
ponibilidade de recursos (HODES, 2009).
Quando projetos são adicionados em uma carteira da empresa, os recursos

mais utilizados em relação à capacidade disponível governarão o ritmo da carteira. A
CCPM chama este recurso de recurso de ritmo (HODES, 2009).
2.7.2.1 Explorar a restrição
O termo “explorar” se refere aos meios para obter o máximo possível dos re-
cursos de determinação de velocidade na rede do projeto. Em projetos individuais, o
gerente deve entender como a engenharia paralela, questões sobre validade de de-
pendências de precedência e a integridade de estimativas de tempo podem ser ana-
lisadas, para definir o menor plano possível para concluir o projeto. Ao lidar com múl-
tiplos projetos, se a empresa pode entregá-los apenas à razão do recurso crítico
mais restrito, então o bom senso determina que tal recurso seja tratado de forma
diferenciada dos outros (HODES, 2009).
2.7.2.2 Subordinar a restrição
Se aceito que a taxa de transferência de um sistema é regida por restrições,

então se conclui que as “não restrições” não são totalmente usadas. Na linguagem
do projeto, isto é visto nos caminhos que não são a Corrente Critica e são responsá-
veis pela criação de folgas ou floats (HODES, 2009).
86
As implicações de ter recursos não restritos em um projeto, no entanto, vai

ao cerne da operação da maioria das empresas, tenham elas ou não disciplinas for-
mais do projeto em andamento. O uso “eficiente” de recursos é o meio pelo qual os
gerentes governam projetos, na busca incessante de eliminar desperdícios. Mas de
que serve aprimorar o “uso” de recursos em nome da eficiência, quando não se a-
grega valor ao tempo do projeto? Como pode a equação padrão ligando atividade a
valor ser quebrada? Como podem todos os níveis dentro da empresa se sentirem
confortáveis com a idéia de que “quando não há nada a fazer, a melhor coisa a fazer
é nada?” (HODES, 2009).
Que métrica deve ser posta em prática para mudar o comportamento de me-
lhoria de conclusão da tarefa aprimorando a conclusão do projeto? E, finalmente,
que sinais os recursos do projeto devem receber para garantir que estão alinhados
nos esforços para fazer continuamente o certo para reduzir o lead time do projeto? A
postura necessária para melhorar desempenho em demandas da Corrente Critica é
que recursos não presentes na Corrente Crítica “sejam subordinados” às suas exi-
gências. Se subordinar significa garantir que a Corrente Critica não é alimentada,
mesmo significando que as atividades da corrente não crítica demorem mais tempo.
Assim, enquanto os recursos da corrente não crítica parecerem estar fazendo o que
não é melhor para si próprio, eles estarão fazendo o que é melhor para o projeto
como um todo. No ambiente multiprojeto, isso significa se subordinar às exigências
do recurso de ritmo (HODES, 2009).
2.7.2.3 Elevar a restrição
Assim que tenham sido feitos os esforços para reduzir a duração de projeto
individual até o mais próximo possível de zero que o planejamento prudente permita,
é hora de “elevar” recursos limitados. Em geral, isso é um passo estratégico e exige
a adição de recursos para melhorar a taxa de transferência do projeto ou “pipeline”
da empresa (HODES, 2009).
87
2.7.2.4 Não permitir que a inércia se torne a restrição
Mais uma vez, o bom senso dita que se há sempre uma restrição em um sis-
tema estas restrições não vão desaparecer com a etapa de elevação, elas vão sim-
plesmente aparecer em outro lugar. É importante quando se considera e se introduz
a etapa de elevação para determinar onde a nova restrição vai aparecer, e se este é
o lugar onde você quer que ela esteja. Se todos os sistemas têm restrições, então
realmente há apenas duas opções - ou você gerencia as restrições, ou controla-as.
Entender essa proposição permite que a empresa escolha onde vá querer que a sua
restrição (também conhecido como ponto de controle ou acelerador) fique e, assim,
controlar o seu próprio processo de melhoria contínua (HODES, 2009).
2.7.3 O Método da Corrente Critica
O método da Corrente Critica é único na forma como trata e mede a variabi-

lidade dentro de projeto e multiprojeto, para que os efeitos da variabilidade sejam
minimizados, o desempenho aprimorado e confiabilidade melhorada. Antes de ape-
nas aceitar tal afirmação, é preciso entender como a variação determina comporta-
mentos sob os modos de operação e como a introdução do conceito de pulmões e
de gerenciamento de pulmão pode mudar esses comportamentos (HODES, 2009).
Figura 2-38 - Tarefas com segurança adicional

FONTE: Hodes (2009)
A Figura 2-38 acima mostra uma típica rede de projeto com as barras sólidas
coloridas representando estimativas de 50% de nível de confiança de tempo da tare-
fa e as barras vazias associadas representando o preenchimento necessário para
levar cada estimativa até o nível de confiança de 90%.
88
A maioria dos participantes do projeto, acostumados com a ideia de serem

mensurados na conclusão de tarefas (melhoria local), e incertos onde surgirão pro-
blemas, tendem a incluir o máximo de contingência nas tarefas com a qual possam
razoavelmente consigam cobrir as estimativas. Deste modo, eles não serão vistos
como causa de atrasos para o progresso de todo o projeto (HODES, 2009). O pre-
enchimento das estimativas causa os seguintes problemas:
• Projetos parecem mais longos do que o necessário

• Trabalho se expande para preencher tempo disponível (Lei de Parkinson)
• O trabalho adiado até a última hora (Síndrome do Estudante) 1
• Com preenchimento de cada tarefa não há tempo disponível para multitarefa 2
A multitarefa aumenta significativamente o risco de não estar disponível para

trabalhar no que é do melhor interesse do projeto quando necessário. Efeito negati-
vo adicional da multitarefa é que muito mais tarefas estão abertas que o necessário,
resultando em altos níveis de trabalhos em processo. Isso cria um ambiente difícil
para o gerente de projeto controlar.
O método da Corrente Critica aborda a questão da estimativa do tempo da

tarefa trazendo todas as estimativas de tarefas para o nível de confiança de 50%.
Em termos práticos, isto significa fazer a pergunta: “Se todos os recursos necessá-
rios para concluir a atividade estiverem disponíveis, e não houver interrupção por
outras atividades, qual é o melhor palpite de quanto tempo esta tarefa levará?” O
equilíbrio de contingência que leva até a estimativa de 90% de confiança não é per-
dido. Em vez disso, ele é devolvido e colocado à disposição do gerente do projeto,
fora do alcance dos recursos. Esta contingência agregada é referida como “pulmão”
(HODES, 2009). As Figuras 2-39 a 2-41 mostram a transição do cronograma de
Caminho Crítico, através da programação da Corrente Critica (nivelamento de recur-
sos) e, finalmente, com a programação da Corrente Critica com “pulmões”. Existe
apenas um recurso de cada tipo A, B, C e D (HODES, 2009).
1
O tempo previsto para concluir a tarefa ultrapassa o esforço real necessário.
2
Prevenção contra multitarefa no âmbito do projeto ou de múltiplos projetos.
89
Embora a duração total do projeto permaneça semelhante, usando as regras

de gerenciamento de “pulmão”, a probabilidade d o projeto ser entregue no prazo
citado é significativamente melhor. Como isso é possível? Em primeiro lugar, pela
redução das tarefas ao seu nível de confiança de 50% (valor P50), ficando pouco
tempo disponível para ceder a Lei de Parkinson ou a Síndrome do Estudante. O re-
quisito de proteger as estimativas iniciais é eliminado, uma vez que os recursos de-
vem finalizar a tempo na metade de todos os casos. O foco passa da conformidade
da tarefa para o desempenho do projeto. A ênfase é colocada sobre o que precisa
ser feito para manter o fluxo do projeto em movimento (HODES, 2009).
Figura 2-39 - O Caminho Crítico (em vermelho)

FONTE: Hodes (2009)
Figura 2-40 - A Corrente Critica (em vermelho)

FONTE: Hodes (2009)
Figura 2-41 - Corrente Critica com Pulmões

FONTE: Hodes (2009)
90
Como é a Corrente Critica que determina a duração total do projeto, qual-

quer aumento do tempo dessa corrente será, por definição, a causa de atraso no
projeto. O esforço a fazer é proteger o cliente do projeto das variações negativas ao
longo da Corrente Critica, e proteger a Corrente Critica de variações negativas ao
longo das correntes não críticas, ou correntes de alimentação. Qualquer tarefa pode
ser adiada, mas seria muito incomum, todas serem adiadas. Algumas podem até
terminar mais cedo. O gerente, portanto, precisa de um mecanismo “amortecedor”
para sinalizar quando as correntes estão em perigo e usar este sinal como meio de
priorizar alocação de recursos. Os pulmões cumprem esta função. O consumo dos
pulmões pode ser visto nas figuras 2-42 e 2-43, a seguir (HODES, 2009).
Figura 2-42 - Fim da tarefa e o consumo do Figura 2-43 - Fim da tarefa e consumo do
pulmão (2º Dia) pulmão (3º dia)
FONTE: Hodes (2009) FONTE: Hodes (2009)
Neste exemplo, a data de status é representada pela linha pontilhada. A Cor-

rente Critica é representada por tarefas sombreadas em vermelho. O pulmão de pro-
jeto (PB) foi consumido (sombreado amarelo) e o pulmão de alimentação (FB) tam-
bém foi consumido. A Tarefa 1 é a mais crítica a se trabalhar, porque um atraso aqui
causa o consumo imediato do PB. O papel do recurso na tarefa 4 (da cadeia de ali-
mentação) é subordinar às exigências da tarefa 1 (na Corrente Critica), embora seu
próprio pulmão de alimentação tenha sido penetrado devido ao início tardio do traba-
lho. Uma demora a mais na Tarefa 4 não irá causar qualquer atraso para a duração
do projeto em si até que o pulmão de alimentação inteiro ser consumido (HODES,
2009).
91
2.7.4 Razão Crítica
O que acontece quando as redes de programação são mais complexas que

a mostrada acima e muitas correntes têm pulmões consumidos? Como determinar o
mecanismo de priorização para alocar recursos? Isso é feito pelo conceito de Razão
Crítica. Esse número identifica ao gerente qual tarefa é mais importante a ser traba-
lhada em qualquer ponto específico no tempo. É calculada dividindo-se a porcenta-
gem da corrente concluída pela porcentagem de pulmão consumido pela corrente
(HODES, 2009).
Assim, se uma corrente específica foi 50% concluída e seu pulmão foi 50%
consumido, não há motivo para alarme ou atenção da administração. No entanto, se
90% do pulmão foi consumido, e apenas 10% da corrente que ele suporta estão
concluídas, então este deve ser foco de atenção, uma vez que está atuando para
bloquear o fluxo de trabalho por todo o projeto e comprometerá a data de conclusão.
Esta Razão Crítica, ou taxa de consumo do pulmão, é a pedra angular da gestão de
risco. Dentro de ambiente multiprojeto é o meio pelo qual os gerentes ganham visibi-
lidade e controle sobre a multiplicidade de tarefas que percorrem o pipeline da orga-
nização. A Razão Crítica fornece um sistema claro e objetivo de medição para de-
terminar que recursos subordinar ao que em momento. A Razão Crítica pode ser
mapeada diariamente em um gráfico de tendência (ou “febril”), como na figura 2-44.
O ideal é que a Razão Crítica deva tender dentro da área do gráfico de tendência
em amarelo, o que significa que o trabalho na cadeia mais longa esta sendo conclu-
ído em um taxa proporcional ao consumo de pulmão de projeto (HODES, 2009).
Figura 2-44 - O gráfico de tendência (ou gráfico “febril”)

FONTE: Hodes (2009)
92
As Figuras 2-45 e 2-46 usam os mesmos dados, como mencionado anteri-

ormente para mostrar como a Razão Crítica é calculada e representada graficamen-
te. O gráfico de tendência na figura 2-35 mostra que a taxa de conclusão da cadeia
mais longa está ficando para trás do consumo do pulmão de projeto. O projeto pare-
ce ter parado na primeira tarefa na Corrente Critica, apesar de um bom começo. Isso
indica medidas devem ser tomadas agora para subordinar à tarefa consumidora - a
Tarefa 1 da Corrente Critica (HODES, 2009).
Figura 2-45 - Gráfico de tendências da taxa de conclusão

FONTE: Hodes (2009)
Figura 2-46 - Gráfico de tendências - Mudanças na Razão Crítica

FONTE: Hodes (2009)
O gráfico de tendência na figura 2-46 demonstra que a Razão Crítica está se
movendo em direção a uma tendência mais saudável; no entanto, o plano de recu-
peração do pulmão deve continuar: subordinando os recursos não restritos à tarefa
consumidora atual e o recurso que o está consumindo (HODES, 2009).
93
3 ESTUDO DE CASO
O presente estudo de caso foi realizado na empresa de nome fictício “KBR

OIL & GAS LTDA.”. A “KBR OIL & GAS LTDA.” é uma empresa brasileira atuante no
mercado de equipamentos para a indústria de Óleo e Gás, fornecendo estações de
medição de vazão (EMEDs) para aplicações de hidrocarbonetos derivados de petró-
leo e gás natural, etanóis e biocombustíveis em geral. Será apresentada a empresa
e descrita suas principais características, modus operandi e atividades desenvolvi-
das, estudando a gestão de projeto e produção e descrevendo suas deficiências.
A seguir será apresentado um resumo descritivo da identificação da empre-

sa objeto do estudo de caso, no qual se pretende delinear com o máximo detalha-
mento possível o seu mercado, cadeia de valor, e demais informações necessárias
para o estudo de caso.
3.1 DESCRIÇÃO DA EMPRESA
A atividade econômica principal da “KBR OIL & GAS LTDA.” é a fabricação

de equipamentos hidráulicos e pneumáticos, peças e acessórios, exceto válvulas. As
atividades econômicas secundárias são o comércio atacadista de máquinas e equi-
pamentos, partes, peças e acessórios, de uso industrial e geral, além de outras não
especificadas.
A empresa atua ainda na manutenção e reparação de máquinas e aparelhos

para a indústria do plástico e de outras para usos industriais não especificados, em
serviços de engenharia, e finalmente, no treinamento de seus clientes.
A “KBR OIL & GAS LTDA.” foi fundada em maio de 2003, por profissionais
atuantes no mercado com experiência adquirida de mais de 20 anos, e é estabeleci-
da no Rio de Janeiro. A empresa surgiu como uma solução na prestação de serviços
voltados para a indústria de petróleo e gás natural, e atua na representação técnica
e comercial de empresas líderes no campo da medição de vazão e válvulas especi-
ais.
94
A “KBR OIL & GAS LTDA.” foi criada inicialmente para atuar como uma divi-
são de suporte técnico de outra empresa, atendendo a sua demanda de assistência
técnica. Construindo expertise própria, conquistou posição de destaque, acumulando
experiência e melhorando soluções e serviços, atendendo com qualidade as exigên-
cias do mercado. Além disso, atua em serviços especializados de instalação, manu-
tenção e calibração. Os principais processos de suporte são a Engenharia Conceitu-
al e Básica, Engenharia de Detalhamento e Marketing de Sistemas e Produtos.
3.2 HISTÓRICO DA EMPRESA
A “KBR OIL & GAS LTDA.” surgiu com objetivo de diferenciação no merca-
do, apresentando-se como empresa de serviços especializados em instrumentação
e controle, não importando fabricante do equipamento. Iniciou suas atividades como
divisão de assistência técnica terceirizada e, depois, passou a atuar com parceria
comercial de representação. Sua linha do tempo pode ser vista na Figura 3.1.
Figura 3-1 - Linha do tempo da “KBR OIL & GAS LTDA.”

Fonte: “KBR OIL & GAS LTDA.” (2014)
3.3 MERCADO DE ATUAÇÃO
O “core business” da “KBR OIL & GAS LTDA.” são soluções integradas em
equipamentos e serviços orientados para a indústria de óleo e gás, nestas áreas:
empresas de Exploração & Produção de óleo e gás natural; refinarias e petroquími-
cas, empresas de transporte de petróleo, gás natural e derivados do petróleo; distri-
buidoras de combustíveis; e finalmente, empresas de construção e montagem
(EPC), de engenharia e estaleiros.
95
O detalhamento dos setores cobertos pelas representações da “KBR” pode

ser visto a seguir na Figura 3-2 e na Tabela 3-1.
Figura 3-2 - Market Share da “KBR OIL & GAS LTDA.”

Legenda da figura:
1) Plataforma de Produção Offshore (Óleo e Gás Natural) 16) Gasodutos (Transferência de Custódia)
2) Plataforma de Transferência Offshore/Onshore (Concentradora) 17) Terminal de Unidades Separadoras de Teste
3) Unidade Flutuante de Produção, Armazenamento e Descarregamento (FPSO) 18) Produção Onshore de Gás Natural
4) Terminal de Carregamento/Descarregamento de GNL 19) Estação de Recompressão de Gás Natural
5) Terminal de Carregamento de Petroleiros 20) Terminais de Transferência de Custódia Automática Arrendados (LACT)
6) Terminal Concentrador Marítimo (Paiol de Carregamento/Descarregamento) 21) Unidades Individuais de Separadores de Teste
7) Carregamento/Distribuição para Aviação Civil/Militar 22) Refinarias de Óleo Cru
8) City Gate (Estação Fiscal de Distribuição de Gás Natural) 23) Refinarias de Gás Natural / Plantas de Processamento Petroquímico
9) Caminhões-Tanque para Suprimento doméstico (não existe no Brasil) 24) Entrada de Terminais/Plantas (Sistemas de Automação e Acesso)
10) Postos de Abastecimento e Serviço (Distribuidoras) 25) Carregamento de GLP (Transferência de Custódia Móvel)
11) Terminal de Distribuidoras (Derivados de Petróleo, Etanóis e Biocombustíveis) 26) Descarregamento de Etanóis & Biocombustíveis (Transferência de Custódia Móvel)
12) Produção Onshore de Petróleo e Gás 27) Envase de Óleo Lubrificante
13) Oleodutos para Transporte de Óleo Cru (Transferência de Custódia) 28) Terminais de Abastecimento e Desembarque de Balsas/Navios-Tanque
14) Oleodutos para Transporte de Derivados (Transferência de Custódia) 29) Carregamento Ferroviário (Transferência de Custódia Móvel)
15) Armazenamento Subterrâneo de Gás (não existe no Brasil)
Tabela 3-1 - Detalhamento dos Setores de Atuação no Market Share da “KBR.”

3.3.1 Estrutura do mercado
Em uma visão bastante resumida, o mercado local da “KBR” pode ser dia-
gramado desta forma (Figura 3-3):
96
Figura 3-3 - Diagrama do mercado local da “KBR OIL & GAS LTDA.”
FONTE: “KBR OIL & GAS LTDA.” (2014)
3.3.2 Análise “SWOT”
Após um estudo interno mediante a análise SWOT sobre a “KBR OIL & GAS
LTDA.” e sua relação com o mercado se chegou aos seguintes resultados, vistos na
Figura 3.4:
Figura 3-4 - Análise SWOT da “KBR OIL & GAS LTDA.”

97
3.4 PROBLEMAS DO GERENCIAMENTO DE PROJETO
O gerenciamento de projeto do projeto da “KBR” lida com questões amplas

como planejamento, organização, gestão e recursos para realizar a conclusão bem-
sucedida das metas e objetivos específicos do projeto. O gerenciamento de projetos
é realizado efetivamente sobre como fazer e manter os compromissos nas condi-
ções de moderada a extrema incerteza acompanhados por níveis significativos de
complexidade e interdependência. No ambiente de gerenciamento de projeto da
empresa, verifica-se que os compromissos formais são geralmente realizados nas
três dimensões distintas de um projeto antes do início do projeto:
1) Programação ou cronograma.
2) Recursos ou orçamento.
3) Objetivos de escopo, qualidade ou desempenho.
Quando ocorre falha no atendimento de qualquer um desses compromissos

distintos isso resulta em falha na condução dos projetos, com as concomitantes con-
sequências negativas para os interessados. No entanto, como será observado no
estudo de caso, é necessário se encontrar abordagens eficazes para o gerencia-
mento de projetos em um domínio amplo e diversificado e que esta possa ser ensi-
nada e aplicada com sucesso pela maioria dos gerentes de projeto.
3.5 ANÁLISE DO PROBLEMA
Conforme abordado no capítulo 2, onde se falou sobre os arquétipos que fa-

zem os projetos atrasarem, é necessário identificar sua presença e remover os
mesmos, e por isso é preciso primeiro identificar a ocorrência e parar a multitarefa
nociva.
Em seguida precisa ser desenvolvido um sistema que permita que tarefas
adiantadas e atrasadas se compensem entre si, considerando-se a probabilidade de
eventos dependentes entre si, e eliminar os efeitos da Lei de Parkinson, garantindo
que quando as atividades forem concluídas, os outputs sejam levados quase que
instantaneamente para o próximo recurso/atividade na fila, e que se interrompa a
prática de se adicionar contingência a cada tarefa.
98
A seguir será demonstrado onde os problemas citados no estudo de caso

ocorrem, usando como base um projeto protótipo da “KBR”. Cabe frisar que o projeto
em questão foi descaracterizado como forma de manter a privacidade e a confiden-
cialidade inerentes ao mesmo e a empresa e seu cliente em questão.
3.5.1 Aplicando a Corrente Crítica
Para aplicar conceitos delineados nesse trabalho, será analisado o conteúdo

adquirido na pesquisa bibliográfica de projeto-protótipo realizado pela “KBR”. Serão
usados dados retirados de contrato entre a empresa “fictícia” denominada como
“EPC CONTRATANTE S.A.” (o nome da empresa foi descaracterizado no escopo
desse trabalho devido à cláusula de confidencialidade do contrato) e a “KBR”.
O contrato em questão foi estabelecido para produção de 6 EMEDs de óleo

cru para cliente final da “EPC”. Esses projetos foram contratados como “turn-key” e
para fornecê-los, a “KBR” terceirizou a fabricação e parte da engenharia de detalha-
mento do produto à empresa “fictícia” “ISP MONTADORA” (denominada assim por
critério de confidencialidade), responsável por 90% do escopo do projeto, cabendo a
“KBR” atuar como sua “sponsor” e “stakeholder”. A “KBR” coube o escopo de contra-
tar por representação, a compra e importação (quando necessário) de insumos não
fornecidos localmente, e efetuar a aquisição do conteúdo local.
3.5.2 Aspectos que impactam na gestão
Será abordado aqui da forma mais sucinta possível itens críticos do contrato
que nortearão a análise do problema.
3.5.2.1 Objeto do contrato
O objeto do contrato entre a “EPC” e a “KBR” é o fornecimento dos equipa-

mentos e serviços detalhados, relativos ao fornecimento de seis "skids de medição
de petróleo" (EMEDs), conforme documentação técnica do contrato incluindo enge-
nharia, fabricação de componentes e aquisição de terceiros, transporte, supervisão
de montagem, comissionamento, treinamento, testes e inspeções.
99
3.5.2.2 Cronograma do Projeto
O prazo do projeto a partir da sua assinatura foi estabelecido abaixo. Com

base na tabela 3.2 fornecida a seguir, foi possível construir os cronogramas de exe-
cução das etapas do projeto, e executar as análises individuais das mesmas e a
global do projeto como um todo, pois esta fornece marcadores de controle das eta-
pas de cada uma das entregas. Por essas referências, é possível avaliar o projeto
contratado como um todo se chegando à conclusão do mesmo como um portfólio de
multiprojeto. Conforme as cláusulas do contrato a “KBR” deveria executar as ativida-
des listadas, nos prazos indicados, contados a partir da assinatura do contrato:
Tabela 3-2 - Detalhamento dos marcadores de entregas do contrato da “KBR” com a “EPC”
100
3.5.2.3 Requisitos e Escopo
Os requisitos e escopo do contrato no âmbito do gerenciamento dos projetos

são os resumidos a seguir:
a) Executar o projeto objeto do contrato.
b) Disponibilizar equipamentos embalados para transporte e preservação.
c) Fornecer supervisão técnica e administrativa e mão-de-obra direta e indireta.
d) Nomear um Gerente de Projeto qualificado para a execução do projeto.
e) Fornecer entrega as documentações e manuais na linguagem técnica usual
f) Indicar o tipo de armazenamento recomendável.
g) Responsabilizar-se pela qualidade do projeto e suas garantias técnicas.
h) Realizar os testes necessários para o aceite do projeto.
i) Fornecer os certificados de calibração dos instrumentos utilizados.
j) Fornecer sobressalentes necessários aos equipamentos do projeto.
k) Permitir o acesso para o acompanhamento das etapas do projeto.
l) Garantir o acesso à documentação e aos certificados técnicos emitidos.
m) Fornecer treinamento de operação e manutenção do projeto objeto do contrato.
n) Submeter à aprovação do contratante, no prazo máximo de 30 (trinta) dias de-

pois da assinatura deste contrato: Plano de Gestão da Qualidade, Plano de Ins-
peção e Testes, Qualquer documentação aplicável ao fornecimento.
101
3.6 AVALIAÇÃO DAS FERRAMENTAS DE GESTÃO
3.6.1 Ferramentas de Planejamento da Gestão de Recursos
3.6.1.1 Estrutura Organizacional
Existem várias formas de documentar papéis e responsabilidades dos mem-

bros da equipe. A maioria dessas corresponde a um dos três tipos: hierárquicos, ma-
triciais e em formatos de texto (ver Figura 3-5). Independentemente do método usa-
do, o objetivo é garantir que cada atividade tenha um responsável definido, e que
todos os membros da equipe entendam os seus papéis e responsabilidades.
Figura 3-5 - Formatos de definição dos papéis e responsabilidades

• Gráficos hierárquicos - A estrutura de organograma tradicional (EAO) pode ser

usada para mostrar posições e relações em formato gráfico de cima para baixo.
• Gráficos matriciais - A matriz de responsabilidades (MR) é uma tabela que mos-

tra os recursos do projeto alocados a cada atividade. Um exemplo de MR é um
gráfico RACI (Responsável pela execução, responsável pela Aprovação, é Con-
sultado e Informado), vide Figura 3-6.
Figura 3-6 - Matriz RACI

102
A Estrutura Analítica Organizacional da “KBR” apresenta-se como exibido

abaixo em seu organograma funcional (Figura 3-7). Isso permite conhecer-se em
parte o seu mapeamento de fluxo de valor. Em análise preliminar, percebe-se que a
“KBR” possui organização matricial balanceada, porém fraca, porque seu departa-
mento de Engenharia não tem estrutura organizacional projetizada e nem forte, sen-
do limitado a interagir através do departamento comercial com os seus clientes e
pelo departamento de produção com a área de produção externa, em projetos de
grande porte subcontratados.
Figura 3-7 - Organograma - “KBR OIL & GAS LTDA.”

Assim, por não estarem diagramadas por uma matriz de responsabilidades

mais clara, as interações das atividades com os recursos não fica clara, deixando
indefinidos os escopos de atividades dos recursos disponíveis, e dificultando dessa
forma a mensuração do uso dos mesmos e da sua disponibilidade no tempo. Uma
solução para esse aspecto seria repensar procedimentos internos que definem a
estrutura organizacional da empresa, dentro do seu plano da qualidade, manual da
qualidade e demais documentos associados que definem o funcionamento da estru-
tura da empresa.
103
3.6.2 Ferramentas de Planejamento da Gestão da Qualidade
Segundo o PMBOK®:
O gerenciamento da qualidade do projeto inclui os processos e as ativida-

des da organização executora que determinam as políticas de qualidade, os
objetivos e as responsabilidades, de modo que o projeto satisfaça as ne-
cessidades para as quais foi empreendido (PMI, 2013).
O gerenciamento da qualidade do projeto usa políticas e procedimentos para

implantação, no seu contexto, do sistema da qualidade da organização e, dá suporte
às atividades de melhoria do processo contínuo no interesse da organização execu-
tora. O gerenciamento da qualidade trabalha para garantir que requisitos do projeto,
incluindo os do produto, sejam cumpridos e validados. Além disso, o gerenciamento
da qualidade aborda o gerenciamento do projeto e suas entregas. Ele se aplica a
todos os projetos, independente da natureza das suas entregas. As medidas e técni-
cas de qualidade são específicas do tipo de entrega produzida pelo projeto. A equipe
de gerenciamento deve determinar níveis adequados de exatidão e precisão para
uso no plano de gerenciamento da qualidade. Precisão é uma medida de exatidão.
Exatidão é uma avaliação de correção (PMI, 2013).
Analisando-se os procedimentos e plano da qualidade, a “KBR” está de a-

cordo com o escopo de sua certificação da qualidade. Entretanto as metas de avali-
ação do desempenho de seu Sistema de Gestão da Qualidade não são devidamente
balizadas por métricas que sustentem ou auxiliem o seu processo de gerenciamento
de projeto, principalmente com relação ao atendimento à satisfação do cliente em
relação aos atrasos no cumprimento dos prazos das entregas.
As métricas da qualidade descrevem atributos de projeto ou produtos e co-

mo o processo de controle da qualidade o medirá. A medição é um valor real. A tole-
rância define as variações aceitáveis na métrica. As métricas da qualidade são usa-
das nos processos de garantia e de controle da qualidade. Alguns exemplos de mé-
tricas da qualidade incluem desempenho dentro do prazo, controle dos custos, etc.
104
3.6.2.1 Listas de verificação da qualidade
Listas de verificação são ferramentas estruturadas, específicas, usadas para

verificar se um conjunto de etapas necessárias foi executado. As listas de verificação
da qualidade devem incorporar os critérios de aceitação incluídos na linha de base
do escopo. A “KBR” faz uso de listas de verificação em atividades dos processos de
realização do produto, mas acabam não servindo de parâmetro significativo, com
exceção ao gerenciamento de custo do produto, que tem sido usado de forma efi-
caz. Essas listas gerariam resultados significativos no escopo do gerenciamento do
tempo de projeto e de realização do produto abrangido aqui.
3.6.2.2 Realização da garantia da qualidade
O processo de realização da garantia da qualidade usa as ferramentas e

técnicas dos processos de planejamento do gerenciamento da qualidade e de con-
trole da qualidade. Além disso, as ferramentas incluem (Figura 3-8):
Figura 3-8 - As sete ferramentas de gerenciamento da qualidade

105
• Diagramas de afinidades - O diagrama de afinidades é semelhante às técnicas

de mapeamento mental porque é usado para gerar ideias que podem ser conec-
tadas para formar padrões organizados de pensamento sobre um problema.
• Gráfico do programa do processo de decisão (GPPD) -. O GPPD é útil como

um método para o planejamento de contingências, porque ele ajuda as equipes a
antecipar as etapas que poderiam prejudicar o alcance da meta.
• Diagramas de inter-relacionamentos - O diagrama de inter-relacionamento po-

de ser desenvolvido a partir de dados gerados em outras ferramentas tais como o
diagrama de afinidade, o diagrama de árvore, ou o diagrama de Ishikawa (pode
ajudar a detectar causas de problemas e a reduzir a necessidade de contingenci-
amentos).
• Diagramas de árvore - Também conhecidos como diagramas sistemáticos, po-

dem ser usados para representar hierarquias de decomposição tais como a EAP,
a EAR, e EAO; são úteis como árvores de decisão para estabelecer valores para
número limitado de relacionamentos dependentes (resolve a interdependência en-
tre recursos).
• Matriz de priorização -. Identificam questões e alternativas adequadas a priorizar

como critérios; estes são ponderados antes de se aplicar alternativas para obter
escore matemático classificando as opções (resolvem a Multitarefa Nociva, a Lei
de Parkinson e a Síndrome do Estudante).
• Diagramas de rede das atividades - Os diagramas de atividades de rede são

usados com a técnica de avaliação e revisão de programa (PERT), o método do
caminho crítico (MCC) e o método de diagrama de precedência (MDP). Não se
resolvendo o problema, parte-se daqui para a implantação do método da corrente
crítica (CCPM).
• Diagramas matriciais - Uma ferramenta de gerenciamento e controle de qualida-

de usada para executar a análise dos dados dentro da estrutura organizacional
criada em matriz. Já descrita acima em Matriz de Responsabilidades.
106
3.6.3 Cronograma do projeto sem a corrente crítica
A análise do projeto começa pela apresentação simplificada do mesmo atra-

vés do seu gráfico de Gantt, esboçado nas figuras 3-9 a 3-10. Foram usadas apenas
duas das unidades a serem realizadas no projeto, a título de simplificação. É possí-
vel observar que as introduções de contingências na duração das atividades cruciais
do projeto são bem visíveis à primeira vista, sem precisar entrar-se em análises de-
talhadas:
Figura 3-9 - Cronograma sem Corrente Crítica - UO-SKID.01

É possível observar que o projeto possui diversas tarefas repetitivas e que

compartilham tempos que podem ser otimizados e encadeados de formas mais eco-
nômicas e eficazes, reduzindo o impacto em atividades subjacentes e reduzindo cus-
tos operacionais. É evidente que as atividades consideradas mais trabalhosas ou as
que mais geram comunicação entre as partes interessadas e fornecedores são as
que mais recebem contingências e serão exatamente nestas que serão aplicados
ajustes significativos visando à implantação da Corrente Crítica.
107
Figura 3-10 - Cronograma sem Corrente Crítica - UO-SKID.02

Ficou comprovado pelo estudo de caso, o efeito nefasto dos sintomas (ou
arquétipos) do mau gerenciamento do tempo no âmbito geral do gerenciamento de
projeto. Mesmo com o esforço considerável de cumprir metas para atender as de-
mandas dos marcadores do projeto, é evidente que a “KBR” inflacionou os tempos
de documentação e de compra com evidentes contingenciamentos. Basta olhar a
Tabela 3-3 e as Figuras 3-11 e 3-12, para perceber isso.
108
Tabela 3-3 - Impacto das Estimativas com as Contingências nos Marcos do Projeto
Figura 3-11 - Gráfico dos Prazos Máximos

109
Figura 3-12 - Gráfico Atrasos x Adiantamentos
3.6.4 Cronograma do projeto com a corrente crítica
A análise do projeto prossegue agora pela apresentação do seu gráfico de

Gantt revisado, através da aplicação dos conceitos sobre as Técnicas de Enfoque
da Teoria das Restrições, com vistas à implantação do Gerenciamento de Projetos
pela Corrente Crítica, esboçado abaixo nas figuras 3-26 a 3-27.
É possível constatar que através da remoção do preciosismo técnico, das

contingências exageradas na duração das atividades e da simplificação e da otimi-
zação da sequência de tarefas repetitivas ou de uso de recursos compartilhados é
visível à primeira vista, a melhoria do desempenho do cronograma, com uma eviden-
te redução de tempo total do projeto:
110
Figura 3-13 - Cronograma com Corrente Crítica - UO-SKID.01

Figura 3-14 - Cronograma com Corrente Crítica - UO-SKID.02

111
Infelizmente, as informações e os recursos disponíveis usados para a im-

plantação do Método da Corrente Crítica não foram suficientes para permitir um tra-
balho mais elaborado e uma demonstração mais eficaz do mesmo. Por não dispor-
mos dos plug-ins necessários à ferramenta MS-Project, ou por não dispor de ferra-
mentas mais elaboradas para o gerenciamento de projetos, não é possível fornecer
apresentação mais detalhada e completa dos recursos para a análise e gestão dos
riscos e incertezas e para a utilização mais eficaz dos conhecimentos proporciona-
dos pela Teoria das Restrições e do total potencial da Corrente Crítica.
Por isto fica aqui a proposta do desenvolvimento desse recurso através de

programação VBA na ferramenta MS-Project ou do desenvolvimento de uma aplica-
ção específica e aprimorada de gerenciamento de projeto, em língua portuguesa e já
incorporando os recursos de gestão combinada do Caminho Crítico com a Corrente
Crítica e norteada pelas recomendações do Guia PMBOK® como escopo para um
futuro projeto de mestrado.
3.7 RESULTADOS
Constata-se que a “KBR OIL & GAS LTDA.” além de não usar de forma ade-
quada as ferramentas de Gerenciamento de Projetos, baseia os seus processos de
gestão de projetos apenas nos procedimentos da qualidade e normas dos clientes,
orientando desta forma a sua produção em conformidade com estes requisitos. Des-
ta forma, deixa de se beneficiar de meios que ampliariam sua produtividade. A apli-
cação da Corrente Crítica permitiria a redução no tempo de projeto, eliminando o
contingenciamento do tempo de execução, estipulando-se realisticamente os “lead
times” e reduzindo as estimativas usadas no tempo de cada atividade.
Como consequência, a “KBR OIL & GAS LTDA.” está sujeita aos arquétipos
responsáveis por atrasos, e que podem ser eliminados mediante o uso correto da
ferramenta MS-Project (ou similar) e da aplicação das técnicas dos métodos do Ca-
minho Crítico (PMBOK®) e da Corrente Crítica (Teoria das Restrições) no tratamen-
to dos sintomas identificados no seu Gerenciamento de Projetos.
112
3.8 FERRAMENTAS DA CORRENTE CRÍTICA EXISTENTES
Existem vários projetos implantados de software de Corrente Crítica. Os

principais softwares disponíveis estão listados abaixo em ordem alfabética:
• Aurora-CCPM desenvolvido pela Stottler Henke Smarter Software Solutions dis-

ponível em http://www.stottlerhenke.com/Products/Aurora-CCPM.
• CCPM+ desenvolvido pela Advanced Projects Inc. (Lean Project Management) e
está disponível em http://www.advanced-projects.com/.
• cc-Pulse & cc-MPulse desenvolvidos originalmente pela Spherical Angle, agora
disponível em http://sourceforge.net/projects/cc-mpulse/
• Concerto, desenvolvido pela Realization Technologies Inc., sistema disponível
em http://www.realization.com/.
• ProChain Project Scheduling, desenvolvido pela ProChain Solutions, Inc., siste-
ma disponível em http://www.prochain.com/.
• PS8, desenvolvido pela Sciforma Corporation, disponível em
http://www.sciforma.com/.
Alguns dos softwares acima funcionam como extensão para Microsoft Pro-
ject. Estes incluem: CCPM+, cc-Pulse, Concerto & Prochain. Infelizmente, não há
muitos comentários disponíveis sobre os diferentes pacotes e há ainda menos com-
parações.
No entanto, a maioria dos projetos de implantações da Corrente Crítica co-

meça com o reconhecimento do poder e da eficiência que a aplicação do Gerencia-
mento de Projetos pela Corrente Crítica irá proporcionar. Em seguida, as especifici-
dades da aplicação conduzem a escolha de software. Ou seja, os benefícios de de-
cidir aplicar a Corrente Crítica superam os benefícios de qualquer escolha de softwa-
re, desde que o software suporte todos os aspectos necessários do projeto.
Citando como exemplo, a Boeing utiliza vários pacotes de software de Cor-

rente Crítica que vão desde PS8 no limiar inferior de recursos e requisitos até o Au-
rora-CCPM para as aplicações mais complexas. Em todos os casos a decisão de
alavancar a Corrente Crítica é a decisão que fornece o maior benefício.
113
3.9 BENEFÍCIOS DAS APLICAÇÕES DA CORRENTE CRÍTICA
Há muitos exemplos documentados do mundo real que mostram as melhori-

as possíveis através da Corrente Crítica. Alguns deles são apresentados abaixo.
• Proctor & Gamble antes da Corrente Crítica completava três projetos por trimes-
tre com 25 projetos no sistema. Após implantar a Corrente Crítica, em um ano e-
les completaram oito projetos por trimestre com 41 projetos no sistema. Com me-
lhorias no sistema eles ampliaram para concluir mais de 12 projetos por trimestre
(SMITH, 2009).
• A Speed to Market Engines (Realization) desenvolve aplicações industriais na

área de ciências da vida onde os prazos de entrega foram reduzidos de 8 a 12
semanas para tipicamente três semanas, uma redução de cerca de 70%. Além
disso, cerca de 50 estudos (sem o uso de recursos adicionais) foram concluídos
por mês, um aumento de rendimento de 150% (SOOD, 2015).
• KENDALL (2006) cita exemplos, incluindo a Divisão de Manutenção de Aerona-

ves de Israel, que cortou a média de tempo de conversão de aeronaves de fuse-
lagem larga de 3 meses para 2 semanas. A Seagate Technologies reduziu o
tempo de desenvolvimento de novos produtos pela metade.
• O grupo de TI da Lord Corporation passou de 100% de seus projetos concluídos

atrasados para uma conclusão antecipada ou no tempo de 85%. O Arsenal do
Corpo de Fuzileiros Navais Americanos mais do que triplicou a carga de trabalho
concluído, utilizando os mesmos recursos.
114
Tabela 3.4 - Amostras de aplicações do Método da Corrente Crítica

FONTE: (ROBINSON; RICHARDS, 2010)
115
4 CONSIDERAÇÕES FINAIS
4.1 PERSPECTIVA E PROPOSTAS
A Teoria das Restrições ainda é uma área de estudo jovem e promissora e

tem apresentado propostas inovadoras de ferramentas de raciocínio aplicadas ao
gerenciamento e ao planejamento estratégico as quais ainda não foram amplamente
exploradas.
De fato a própria ferramenta de Gerenciamento de Projetos pela Corrente

Critica é um campo bastante promissor na realização de projetos mais eficazes, com
menor tempo de realização e custos associados e uma área repleta de possibilida-
des de pesquisa para futuros gerentes de projeto.
Associada com as demais ferramentas disponíveis tanto aos gestores de

projeto quanto aos diligenciadores e recursos associados, mas principalmente aos
Engenheiros de Produção, como Lean Management, Six Sigma, FMEA, entre outras,
a Corrente Crítica e a Teoria das Restrições poderá ser de grande valia em um futu-
ro cada vez mais incerto face ao risco das restrições dos sistemas interligados.
Precisa-se atentar para essa questão: Nenhum recurso é ilimitado! Tudo tem
a sua restrição, e para que se mantenha o foco na principal meta da humanidade
que é a sobrevivência humana em um planeta com recursos cada vez mais escas-
sos, é necessário se usar todas as ferramentas disponíveis.
É preciso se lembrar de que a própria raça humana ainda é um projeto em

fase de acabamento. Urge então colocarmos esse projeto sob o crivo de nossa pró-
pria Corrente Crítica.
Fica aqui então a proposta de futuros desenvolvimentos e projetos envol-

vendo a ferramenta que foi estudo de caso desse projeto: ou como um plug-in a ser
incorporado ao MS-Project, 100% brasileiro, ou mesmo uma ferramenta de software
100% nacional. Essa será a próxima meta!
116
5 REFERÊNCIA BIBLIOGRÁFICA
BOMBIG, Alberto; PINHO Angela; GORCZESKI, Vinicius (2013). Por que tudo atrasa
no Brasil? 13 de maio de 2013, Revista ÉPOCA. Rio de Janeiro, Ed. Globo. Disponí-
vel em: http://revistaepoca.globo.com/tempo/noticia/2013/05/por-que-tudo-atrasa-no-
brasil.html. Acessado em 19/03/2015.
BROOKS, Frederick (1995). O Mito do Homem-Mês: Ensaios sobre Engenharia de

Software (The Mythical Man Month: Essays on Software Engineering). Addison-
Wesley Publishing Company, ISBN 0-201-83595-9. Disponível em http://valbonne-
consulting.com/papers/classic/Brooks_75-The_Mythical_Manmonth.pdf. Acessado
em 07/06/2015.
DINSMORE, C. e CAVALIERI, A. (2003). Como se Tornar um Profissional em Ge-

renciamento de Projetos: Livro-Base de “Preparação para Cerfiticação PMP® - Pro-
ject Management Professional”. Rio de Janeiro. QualityMark.
ELDER, Allan (2006). As Cinco Doenças do Gerenciamento de Projetos (The Five

Diseases of Project Management). Original em inglês disponível em
http://www.nolimitsleadership.com/images/The%20Five%20Diseases%20of%20Proje
ct%20Management.pdf. Acessado em 30/05/2015.
GOLDRATT, Eliyahu M. (1997). Corrente Crítica (Critical Chain). Great Barrington,

MA: River North Press Publishing Corporation.
GOLDRATT, Eliyahu M. (2014). Corrente Crítica - Teoria das Restrições em Gestão

de Projetos (Critical Chain - A Business Novel). 2014, 5ª Edição, ISBN 978-85-213-
1835-4. São Paulo, Nobel.
HODES, D. (2009). Superando Incertezas em Ambientes Multiprojeto - A Questão da

Corrente Crítica (Taming Uncertainty in the Multi-project Environment: The Critical
Chain Difference). Disponível em http://ensembleconsultinggroup.com/wp-
content/uploads/2014/06/Critical-Chain-White-Paper1.pdf. Acessado em 07/06/2015.
117
KENDALL, G. I. (2006). Corrente Crítica e Caminho Crítico - Qual é a diferença?

(Critical Chain and Critical Path - What’s the Difference?). Disponível no endereço
http://www.tocinternational.com/pdf/Critical%20Path%20vs.%20Critical%20Chain.pdf
Acessado em 07/06/2015.
KERZNER, H. (2001). Gerenciamento de Projetos - Uma Abordagem dos Sistemas

de Planejamento, Programação e Controle (Project Management - A Systems Ap-
proach to Planning, Scheduling, and Controlling). New York NY, John Willey & Sons.
MARTINS, Petrônio Garcia; ALT, Paulo Renato Campos (2011). Administração de

Materiais e Recursos Patrimoniais. 2011. 3ª Edição. ISBN 978-85-020-8023-2. São
Paulo. Ed. Saraiva.
MICROSOFT (2010). Um histórico rápido do gerenciamento de projetos (History of

project management). Disponível em: https://support.office.com/en-us/article/History-
of-project-management-a2e0b717-094b-4d1e-878a-fcd0978891cd?ui=en-US&rs=en-
US&ad=US. Acessado em 07/06/2015.
MOCHAL, Thomas (2003). Falta de planejamento é o erro número um do gerencia-

mento de projetos (Poor planning is project management mistake number one).
TechRepublic. Disponível no website: http://www.techrepublic.com/article/poor-
planning-is-project-management-mistake-number-one/. Acessado em 19/03/2015.
PMI - Project Management Institute (2000). Project Management Institute. PMBOK®

- Um Guia do Conhecimento em Gerenciamento de Projetos. (PMBOK® - A guide to
the Project Management Body of Knowledge). Newtown Square, PA: Project Mana-
gement Institute Inc., 2000. Disponível em: http://www.pmi.org. Acessado em
01/06/2015.
PMI - Project Management Institute (2004). Project Management Institute. PMBOK®

- Um Guia do Conhecimento em Gerenciamento de Projetos. (PMBOK® - A guide to
the Project Management Body of Knowledge). 3rd Edition. Newtown Square, PA:
Project Management Institute Inc., 2004. Disponível em: http://www.pmi.org. Acessa-
do em 01/06/2015.
118
PMI - Project Management Institute (2013). PMBOK® - Um Guia do Conhecimento

em Gerenciamento de Projetos. (PMBOK® - A guide to the Project Management
Body of Knowledge). 5ª Edição, 2014, ISBN 978-85-02-22372-1, São Paulo, Ed. Sa-
raiva.
ROBINSON, H., RICHARDS, R. (2010). Gerenciamento de Projetos pela Corrente

Crítica: Motivação & Visão Global (Critical Chain Project Management: Motivation &
Overview). Afinitus Group LLC e Stottler Henke Associates Inc. Disponível em
http://www.stottlerhenke.com/papers/IEEE_Aerospace_2010_critical_chain.pdf. A-
cessado em 07/06/2015.
SMITH, M. (2009). CCPM - Uma Estratégia da Sustentação na Procter & Gamble

Farmacêutica (CCPM - A Sustaining Strategy at Procter & Gamble Pharmaceuticals).
Texto disponível em http://www.pharmpro.com/articles/2009/03/ccpm-150-sustaining-
strategy-procter-gamble-pharmaceuticals. Acessado em 07/06/2015.
SOOD, S. (2015). O sistema de pulmão da Corrente Crítica: Uma abordagem inova-

dora que faz o fluxo de trabalho de P&D funcionar como uma fábrica de projeto (Cri-
tical Chain Buffering: A breakthrough approach that makes R&D workflow run like a
project factory). Texto disponível em http://www.docin.com/p-22686783.html. Aces-
sado em 07/06/2015.
VERGARA, Sylvia C., (2014). Projetos e Relatórios de Pesquisa em Administração.

15ª Edição, 2014, ISBN 978-85-224-9099-8. São Paulo, Ed. Atlas.
VIEIRA, E. (2002). Gerenciando Projetos na Era de Grandes Mudanças - Uma breve

abordagem do panorama atual. PMI Journal – PMI-RS 3, pp. 7-16. Disponível em
http://www.emc.ufg.br/~lguedes/moodle/get/gp_pmi.pdf. Acessado em 01/06/2015.
VICENTINO, Cláudio (1997). História Geral. São Paulo. Editora Scipione

119
6 BIBLIOGRAFIA RECOMENDADA
ALVES, Alessandro Pereira; SILVA, Tatiane Gomes; ALMEIDA, Rodrigo Santana de;
COGAN, Samuel (2010). Utilizando os Passos da Teoria das Restrições para a Me-
lhoria Contínua da Produção: um Estudo Aplicado a uma Fábrica de Jeans. Revista
do Mestrado em Administração e Desenvolvimento Empresarial da Universidade Es-
tácio de Sá – Rio de Janeiro. Revista ADM. MADE, ano 11, v.15, n.1, p.93-114, ja-
neiro/abril, 2011.
LUCHI, Olivio (2006) - A Contribuição da Teoria das Restrições para o Processo de

Compras das Organizações Militares do Exército Brasileiro. 30º Encontro da ANPAD
MARCANTONIO, Maria Isabel Palmerio (2010). A Corrente Critica Aplicada na Fer-

ramenta de Gestão de Projetos MS Project. XXX Encontro Nacional de Engenharia
de Produção
MOELLMANN, Artur Henrique; ALBUQUERQUE, Alexandre Saul; CONTADOR, Jo-

sé Luiz; MARINS, Fernando Augusto Silva (2006) - Aplicação da Teoria das Restri-
ções e do Indicador de Eficiência Global do Equipamento para Melhoria de Produti-
vidade em Uma Linha de Fabricação, Universidade Tecnológica Federal do Paraná -
UTFPR, Revista Gestão Industrial.
QUELHAS, Prof. Osvaldo, D.Sc; BARCAUI, Prof. André B., M.Sc.; (2004). A Teoria
das Restrições aplicada a Gerência de Projetos: Uma Introdução à Corrente Crítica.
Disponível em http://www.pmtech.com.br/newsletter/. Acessado em 18/05/2015
SOARES, Mariana Costa Mattos; PAVÃO, Sabrina Pereira. (2009). Uma Proposta
para a Melhor Gestão de Projetos: Um Estudo de Caso de Projetos de Consultoria
em Empresas Estatais. Projeto Fim de Curso - Universidade Federal do Rio de Ja-
neiro, Escola Politécnica, Departamento de Engenharia Industrial, Curso de Enge-
nharia de Produção.

Estudo de Caso

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Estudo de Caso

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE DO GRANDE RIO - “Prof.

José de Souza Herdy”

Roberto Carlos Teixeira

Trabalho de Conclusão de Curso apresen-

Orientador: Prof. Rubens Aguiar Walker, M. Sc.

T266g Teixeira, Roberto Carlos.

Trabalho de Conclusão de Curso (graduação em Engenharia de

1. Engenharia de Produção. 2. Administração de projetos. 3. Teoria de

“Este trabalho reflete a opinião do autor, e não necessariamente a da Associação

Trabalho de Conclusão de Curso apresen-

Aos meus pais Carlos Henrique (I.M.) e

Agradeço em primeiro lugar a Deus, Arquiteto de nossos passos, o Enge-

Agradeço a minha fiel companheira de todas as horas Elaine, pela infinita

Finalmente, agradeço aos colegas de faculdade, os quais me levaram a ser

O presente trabalho é o resultado de anos de experiência e vários projetos

Por mais de mais de 20 anos, mesmo com o know-how existente já consoli-

Apesar da experiência inquestionável da empresa abordada nesse estudo

Também se verifica que por não usar adequadamente nenhuma ferramenta

O propósito final deste trabalho consiste em apresentar estas ferramentas de

Despite the unquestionable experience of the company in their areas cov-

CCPM - Critical Chain Project Management

1.1 PROBLEMA ...................................................................................................... 24

2 METODOLOGIA DO GERENCIAMENTO DE PROJETO .................33

2.1 DEFINIÇÕES E RELACIONAMENTOS ............................................................ 33

3 ESTUDO DE CASO ............................................................................93

3.1 DESCRIÇÃO DA EMPRESA ............................................................................ 93

4.1 PERSPECTIVA E PROPOSTAS .................................................................... 115

5 REFERÊNCIA BIBLIOGRÁFICA .....................................................116

6 BIBLIOGRAFIA RECOMENDADA ..................................................119

Dessa forma, o gerenciamento de projetos é citado por diversos autores co-

A atuação de qualquer profissional requer conhecimento especial e uma

As organizações, com o objetivo de colher os benefícios esperados, devem

As organizações modernas inseridas em um ambiente globalizado, e cada

Projeto é um instrumento fundamental para qualquer atividade de mudança

Um projeto é um empreendimento único, com início e fim definidos, que utili-

O projeto pode ser definido por características distintas como temporário, ú-

A gestão de projetos envolve criar um equilíbrio entre as demandas de es-

Os projetos vêm sendo realizados desde os primórdios da civilização. A

O gerenciamento de projetos, em sua forma moderna, começou a se estabe-

Nos Estados Unidos, por exemplo, o primeiro projeto governamental verda-

Perto da virada do século, Frederick Taylor (1856–1915) iniciou seus estu-

O sócio de Taylor, Henry Gantt (1861-1919), estudou em grande detalhe a

Os Diagramas de Gráfico de Gantt provaram ser uma poderosa ferramenta

Taylor, Gantt, e outros ajudaram a tornar o gerenciamento de projetos uma

Durante a segunda Guerra Mundial, projetos militares e governamentais

Logo, essas técnicas se espalharam por todos os tipos de indústrias, à me-

Na década de 60, o gerenciamento de projetos é formalizado como ciência.

O PMI é considerado a maior instituição internacional dedicada a dissemina-

Hoje, o gerenciamento de projetos está se fortalecendo cada vez mais. As

Para balizar o gerenciamento de projetos, o PMI ao longo dessas décadas

O PMBOK® foi inicialmente publicado pelo PMI como uma recomendação

O PMBOK® identifica um subconjunto do conjunto de conhecimentos em ge-

O PMBOK® fornece e promove um vocabulário comum para discutir, escre-

O PMBOK provê diretrizes para gerência dos projetos individualmente e de-

Acompanhando o desenvolvimento das técnicas de gerenciamento da pro-

A Teoria das Restrições (TOC) é um paradigma de gestão que considera

A TOC foi concebida para auxiliar organizações a alcançar seus objetivos

De acordo com a TOC, toda organização tem - em um dado momento no

A TOC está sendo aplicada com sucesso em diversos contextos: manufatu-

É um fato bastante conhecido na área de Engenharia (principalmente na

É preciso abordar melhor essa questão e de forma mais abrangente para

Diante desse paradigma, necessita-se entender que o problema apresenta-

O texto acima questiona se os projetos das partes interessadas sofrem de

Pela observação prática ao longo de anos de trabalho, prática e pesquisa na