Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos

BRUNO EDUARDO ALVES MORALEIDA GOMES
DESENVOLVIMENTO DE UMA METODOLOGIA LEAN PARA
GERENCIAMENTO DE PROJETOS DE MELHORIA DE PROCESSOS PRODUTIVOS
Trabalho apresentado ao curso MBA em
Gerenciamento de Projetos, Pós-Graduação lato
sensu, da Fundação Getulio Vargas como
requisito parcial para a obtenção do Grau de
Especialista em Gerenciamento de Projetos.
ORIENTADOR: Prof. André Valle
Belo Horizonte
Março/2015

FUNDAÇÃO GETULIO VARGAS
PROGRAMA FGV MANAGEMENT
MBA EM GERENCIAMENTO DE PROJETOS
O Trabalho de Conclusão de Curso
Desenvolvimento de uma metodologia Lean para gerenciamento de projetos de
melhoria de processos produtivos
Elaborado por Bruno Eduardo Alves Moraleida Gomes
e aprovado pela Coordenação Acadêmica do curso de MBA em Gerenciamento de
Projetos, foi aceito como requisito parcial para a obtenção do certificado do curso de
pós-graduação, nível de especialização do Programa FGV Management.
Belo Horizonte, 18/03/2015
André Bittencourt do Valle
Coordenador Acadêmico Executivo
André Bittencourt do Valle
Professor Orientador

TERMO DE COMPROMISSO
O(s) aluno(s) Bruno Eduardo Alves Moraleida Gomes, abaixo assinado(s), do curso de MBA
em Gerenciamento de Projetos, Turma 50 do Programa FGV Management, realizado nas
dependências da IBS Business School, no período de 16/01/13 a 04/12/14, declara que o
conteúdo do Trabalho de Conclusão de Curso intitulado “Desenvolvimento de uma
metodologia Lean para gerenciamento de projetos de melhoria de processos produtivos”, é
autêntico, original e de sua autoria exclusiva.
Belo Horizonte, 18/03/2015
Bruno Eduardo Alves Moraleida Gomes

Dedicatória
Primeiramente a Deus e também a todos que amo.
Porque se não houvesse amor de nada adiantaria.

RESUMO
Este trabalho tem por objetivo desenvolver uma metodologia de gerenciamento de projetos
através da utilização do cruzamento de conceitos do Lean Manufacturing e do Guia do
Conhecimento em Gerenciamento de Projetos (Guia PMBOK) 5ª Edição. Os processos aqui
descritos estão alinhados a todos os grupos de processos e áreas do conhecimento em
gerenciamento de projetos definidos pelo Guia PMBOK 5ª Edição e também a cinco pilares
do Pensamento Lean: Valor, Cadeia de Valor, Fluxo da Cadeia de Valor, Produção Puxada e
Busca da Perfeição. Com a apresentação dos conceitos e o passo a passo de sua utilização o
Gerente do Projeto poderá aplicar facilmente a metodologia, desde que alinhado a seus pré-
requisitos: A formação de um Comitê de Gerenciamento de Projeto, a existência de uma
ferramenta de captação de ideias e aplicação de treinamentos em Lean Manufacturing como
parte da cultura empresarial. A Metodologia propõe ainda o uso da Gestão Visual e das
ferramentas da qualidade como parte de sua estrutura e processos. Por carecer ainda de testes
práticos, cabe às organizações que optarem pela utilização da metodologia o cuidado de a
manterem sob a tutela de um comitê de gerenciamento de projetos experiente que possa
atualizar as soluções propostas conforme necessário.
Palavras Chave: Gerenciamento, Projetos, Lean, Qualidade

ABSTRACT
The paper here presented has the objective of developing a project management methodology
through the crossing of Lean Manufacturing and The Project Management Book of
Knowledge 5th
edition concepts. The processes described in this work are totally aligned to
the groups of processes and knowledge areas defined by the PMBOK Guide 5th
edition and
also to five basic concepts of Lean Thinking: Value, Value Chain, Value Chain Flow, Pulled
Production and Search for Perfection. By presenting the concepts and the step by step guide to
using those, the Project Manager shall easily apply the methodology hence its organization is
aligned to the pre-requirements: gathering of a Project Management Committee, the existence
of a tool to capture new ideas and constant training in Lean Manufacturing as a part of the
culture. This methodology also proposes the use of Visual Management and quality
enhancement tools as a part of its structure and processes. Because it is still not tested
completely it’s the organizations responsibility to gather a rather experienced project
management committee so it can update it and enhance it as necessary.
Key Words: Project, Management, Lean, Quality

AGRADECIMENTOS
Aos professores da Fundação Getúlio Vargas que certamente souberam abrir minha mente
para o verdadeiro e eficaz Gerenciamento de Projetos.

SUMÁRIO
1. INTRODUÇÃO..................................................................................................... 13
2. FUNDAMENTAÇÃO TEÓRICA......................................................................... 15
2.1. PROJETOS, PROCESSOS E SUA RELAÇÃO COM O CICLO PDCA............................ 15
2.2. CICLOS DE VIDA, FASES E GRUPOS DE PROCESSOS........................................... 18
2.3. PERFIL DO GERENCIAMENTO DE PROJETOS NA INDÚSTRIA................................... 20
2.4. LEAN MANUFACTURING APLICADO A PROJETOS................................................... 24
2.4.1. Valor................................................................................................................ 25
2.4.2. Cadeia de Valor............................................................................................. 27
2.4.3. Fluxo da Cadeia de Valor............................................................................. 28
2.4.4. Produção Puxada.......................................................................................... 29
2.4.5. Busca da Perfeição ....................................................................................... 29
2.5. MAPA DE PROCESSOS DO PMBOK 5ª EDIÇÃO .................................................... 30
3. METODOLOGIA PROPOSTA ........................................................................... 32
3.1. ESTRUTURA PROPOSTA PARA A APRESENTAÇÃO DA METODOLOGIA.................... 32
3.2. REQUISITOS BÁSICOS PARA IMPLANTAÇÃO DA METODOLOGIA ............................. 32
3.2.1. Comitê de Gerenciamento de Projetos....................................................... 32
3.2.2. Ferramenta de Captação de Ideias............................................................. 33
3.2.3. Treinamentos em Lean Manufacturing........................................................ 33
3.3. GRUPO DE PROCESSOS DE INICIAÇÃO................................................................. 34
3.3.1. Ir ao “Gemba” - Pilar associado: Valor do Projeto ..................................... 34
3.3.2. Definir a Cadeia de Valor do Projeto – Pilar Associado: Cadeia de Valor
do Projeto........................................................................................................................... 36
3.3.3. Elaborar o Termo de Abertura do Projeto – Pilar associado: Valor do
Projeto................................................................................................................................ 38
3.3.4. Aprovar o Projeto – Pilar associado: Produção Puxada............................ 38
3.4. GRUPO DE PROCESSOS DE PLANEJAMENTO ....................................................... 39
3.4.1. Coletar os Requisitos de Valor – Pilar Associado: Valor do Projeto........ 40

3.4.2. Mapear os Stakeholders Prioritários – Pilar associado: Cadeia de Valor
do Projeto........................................................................................................................... 41
3.4.3. Detalhar o Escopo a Partir das Causas Raiz – Pilar associado: Fluxo da
Cadeia de Valor do Projeto.............................................................................................. 43
3.4.4. Elaborar a Estrutura Analítica do Projeto – Pilar associado: Fluxo da
3.4.5. Realizar a Análise Make or Buy – Pilar associado: Fluxo da Cadeia de
Valor do Projeto................................................................................................................. 46
3.4.6. Definir e Sequenciar as Atividades do Projeto – Pilar Associado: Fluxo da
Cadeia de Valor................................................................................................................. 47
3.4.7. Negociar a Equipe do Projeto – Pilar associado: Cadeia de Valor do
Projeto................................................................................................................................ 49
3.4.8. Estimar Recursos e Duração das Atividades – Pilar associado: Fluxo da
3.4.9. Desenvolver e Analisar o Cronograma do Projeto – Pilar associado:
Fluxo da Cadeia de Valor do Projeto .............................................................................. 52
3.4.10. Desenvolver o Orçamento do Projeto – Pilar associado: Valor do Projeto
............................................................................................................................................ 55
3.4.11. Definir os Critérios de Aceitação do Projeto – Pilar associado: Busca da
Perfeição............................................................................................................................ 56
3.4.12. Identificar e Analisar os riscos – Pilar associado: Busca da Perfeição.. 57
3.4.13. Responder aos riscos – Pilar associado: Busca da Perfeição ............... 60
3.4.14. Consolidar o Planejamento do Projeto – Pilar associado: Fluxo da
3.5. GRUPO DE PROCESSOS DE EXECUÇÃO............................................................... 62
3.5.1. Integrar a Equipe ao Projeto – Pilar associado: Cadeia de Valor do
Projeto................................................................................................................................ 63
3.5.2. Desenvolver e Atualizar a Gestão Visual para a Equipe – Pilar associado:
Fluxo da Cadeia de Valor................................................................................................. 64
3.5.3. Desenvolver e Atualizar a Gestão Visual no “Gemba” – Pilar associado:
Fluxo da Cadeia de Valor................................................................................................. 66
3.5.4. Orientar as Ações Kaizen / Kaikaku – Pilar associado: Fluxo da Cadeia
de Valor.............................................................................................................................. 66

3.5.5. Conduzir as Aquisições – Pilar associado: Fluxo da Cadeia de Valor do
Projeto................................................................................................................................ 68
3.5.6. Desenvolver Parceiros para o Projeto – Pilar associado: Cadeia de Valor
do Projeto........................................................................................................................... 68
3.5.7. Realizar Kaizen de Projeto – Pilar associado: Busca da Perfeição......... 69
3.6. GRUPO DE PROCESSOS DE MONITORAMENTO E CONTROLE ............................... 70
3.6.1. Realizar a Análise do Valor Agregado – Pilar associado: Valor do Projeto
............................................................................................................................................ 71
3.6.2. Atualizar e Revisar Riscos – Pilar associado: Busca da Perfeição.......... 74
3.6.3. Atualizar e Revisar Mapeamento de Stakeholders – Pilar associado: .... 74
3.7. GRUPO DE PROCESSOS DE ENCERRAMENTO ...................................................... 75
3.7.1. Encerrar o Trabalho – Pilar associado: Valor do Projeto .......................... 75
4. CONCLUSÕES.................................................................................................... 76
5. REFERÊNCIAS BIBLIOGRÁFICAS ................................................................. 78
6. APÊNDICES......................................................................................................... 79
6.1. APÊNDICE A – TEMPLATES DA METODOLOGIA..................................................... 79
6.1.1. A1. FORMULÁRIO DE SOLICITAÇÃO DE “GEMBA”............................... 79
6.1.2. A2. MATRIZ DE PRIORIZAÇÃO DE SOLICITAÇÕES.............................. 80
6.1.3. A3. RELATÓRIO DO “GEMBA” ................................................................... 81
6.1.4. A4. DIAGRAMA SIPOC PARA IDENTIFICAÇÃO DE STAKEHOLDERS84
6.1.5. A5. TERMO DE ABERTURA DO PROJETO ............................................. 85
6.1.6. A6. MATRIZ DE REQUISITOS DO PROJETO.......................................... 87
6.1.7. A7. MAPEAMENTO DE STAKEHOLDERS DO PROJETO...................... 88
6.1.8. A8. MAPA DE AQUISIÇÕES ....................................................................... 89
6.1.9. A9. FOLHA DE VERIFICAÇÃO DA QUALIDADE...................................... 90
6.1.10. A10. FOLHA DE APROVAÇÃO DO TRABALHO .................................... 91
6.1.11. A11. REGISTRO DE RISCOS ................................................................... 92
6.1.12. A12. PLANO DE RESPOSTA AOS RISCOS........................................... 93

6.1.13. A13. MAPA DE COMUNICAÇÕES ........................................................... 94
6.2. APÊNDICE B – LISTA DE SOFTWARES LIVRES E WEB-BASED DE GERENCIAMENTO
DE PROJETOS ...................................................................................................................... 95

LISTA DE FIGURAS E TABELAS
Figura 1 – Representação gráfica do Ciclo de Shewart PDCA. ..........................................22
Figura 2 – PDCA para Gerenciamento de Projetos. ..............................................................23
Figura 3 – PDCA para Gerenciamento de Portfólios, Programas e Projetos...................24
Quadro 1 – Exemplos de Fases que podem compor o Ciclo de Vida de Projetos..........25
Figura 4 – Níveis típicos de custo e pessoal na estrutura genérica do ciclo de vida. ...25
Figura 5 – Impacto das variáveis com base no tempo decorrido do projeto...................26
Figura 6 – Grupos de processos de gerenciamento de projetos. ......................................27
Figura 7 – Perfil Global de Projetos segundo PMSurvey.org 2011 a 2013........................28
Figura 8 – Perfil de Projetos das Indústrias segundo PMSurvey.org 2011 a 2013..........28
Figura 9 – Porcentagem das indústrias com PMOs de Engenharia e TI...........................29
Figura 10 – Percepção de desvios de Tempo, Qualidade e Satisfação vs. atingimento
das metas. .....................................................................................................................................30
Figura 11 – Evolução das características do pensamento industrial................................31
Figura 12 – Os cinco pilares do pensamento Lean...............................................................32
Figura 13 – Fluxo natural dos processos sem aplicação da Produção Enxuta...............33
Figura 14 – Transformação ideal de processo pela aplicação da Produção Enxuta......34
Figura 15 – Representação genérica do Fluxo da Cadeia de Valor. ..................................35
Figura 16 – Grupo de processos de gerenciamento de projetos e mapeamento das
áreas de conhecimento...............................................................................................................38
Figura 17: Fluxograma do Grupo de Processos de Iniciação.............................................42
Figura 18: Matriz de Priorização de Solicitações...................................................................43
Figura 19: SIPOC para Identificação de Stakeholders..........................................................46
Figura 20: Fluxograma do Grupo de Processos de Planejamento.....................................49
Figura 21: Exemplo de EAP organizada por fases................................................................54
Figura 22: Fluxo Decisório da Análise Make or Buy .............................................................55
Figura 23: Modelo de diagrama de precedências..................................................................57
Figura 24: Exemplo de Diagrama de Rede com Caminho Crítico. .....................................63
Figura 25: Representação gráfica dos cenários de risco sem resposta...........................69
Figura 26: Representação gráfica dos cenários de risco pós-resposta ...........................70
Figura 27: Fluxograma do Grupo de Processos de Execução............................................72
Figura 28: Matriz RACI ................................................................................................................73
Figura 29: Gráfico do VE no Tempo .........................................................................................74
Figura 30: Fluxograma do Grupo de Processos de Monitoramento e Controle..............80

13
1. INTRODUÇÃO
Este trabalho tem por objetivo desenvolver uma metodologia de gerenciamento de
projetos que permita otimizar o desempenho do Gerente de Projetos e de sua equipe através
da utilização dos conceitos do Lean Manufacturing. Trata-se, portanto, de um trabalho voltado
a projetos de diversas complexidades, com aplicabilidade em inúmeros segmentos e que
poderá ser utilizado por pessoas e organizações com diferentes níveis de maturidade em
gerenciamento de projetos.
Como tratar então tal diversidade de temas e complexidades dos projetos através de uma
única ferramenta que se adapte aos diversos cenários? Para responder essa pergunta
primeiramente é importante definir o público alvo ao qual a metodologia é direcionada. A
indústria brasileira de alimentos e bens de consumo – conforme denominação utilizada pela
pesquisa do site PMSurvey.org – assim como a indústria automobilística apresentam notórias
dificuldades de consistência de metodologia em gerenciamento de projetos e, por isso, foram
escolhidas para ter suas características estudadas e respondidas.
Basicamente, pode-se dizer que a aplicação da metodologia descrita é dependente de
três fatores. O primeiro deles é a existência de uma arquitetura organizacional
preferencialmente matricial; o segundo é uma estruturação cultural dos processos produtivos
alinhada ao Lean Manufacturing; o terceiro, finalmente, é a existência de um grupo com
conhecimento amplo das práticas de gerenciamento de projetos que seja compatível em
número de indivíduos com as dimensões da operação e o número de projetos que se deseja
desenvolver simultaneamente.
A arquitetura organizacional matricial é de extrema utilidade para organizações que têm
sua atividade principal voltada para os processos produtivos e, principalmente, os processos
industriais. Através de sua adoção as áreas funcionais são mantidas vivas e operantes e os
projetos têm condução adequada garantida por gerentes dedicados a esse fim. Apesar disso as
organizações puramente funcionais também podem ter a metodologia aplicada, necessitando
para isso de um bom nível de apoio gerencial e do devido cuidado no monitoramento e
controle de seus projetos. A rotina das áreas funcionais não deve nunca sufocar os processos
de forma a os prejudicar e os sujeitar a falhas.

14
A cultura do Lean Manufacturing como segundo pilar para aplicação da metodologia
certamente auxiliará na qualidade das sugestões apresentadas, pois as mesmas serão baseadas
em uma metodologia consistente e provadamente acertada em seus conceitos. Veremos mais
adiante que a própria metodologia sugere a utilização de ferramentas Lean como ponto de
partida para seus processos e, desta forma, é fundamental que a equipe esteja alinhada com os
conceitos apresentados.
Finalmente, com o empoderamento do pessoal técnico para decisões relativas a projetos
é preciso balancear a matriz a partir da seleção de pessoas com conhecimento específico na
área de projetos que possam auxiliar na transformação de expectativas em requisitos e,
posteriormente, em um projeto bem-sucedido. Não é imprescindível que o pessoal em questão
seja exclusivamente direcionado à prática do gerenciamento de projetos, porém é de suma
importância que os modelos e metodologias sejam amplamente conhecidos e dominados de
forma a garantir a integração dos processos utilizados.
A partir destas bases e conceitos pretende-se: propor uma metodologia que seja
amigável a pessoas que, apesar de pouca experiência com projetos, podem se tornar líderes de
iniciativas por seu conhecimento técnico profundo dos processos; apoiar a execução da equipe
do projeto através de uma ferramenta de comunicação simples e eficaz com todas as
informações necessárias disponíveis e integradas; padronizar a metodologia de gerenciamento
de projetos em todos os níveis das empresas que a adotarem através da disponibilização de
ferramentas abrangentes e de fácil entendimento.
É importante dizer neste ponto que a metodologia a ser proposta, apesar de construída
de acordo com as boas práticas apresentadas pelo Guia PMBOK e com os princípios do
Sistema Toyota de Produção altamente provados no mundo corporativo, não pretende de
maneira alguma substituir completamente quaisquer metodologias existentes devendo cada
organização e/ou equipe de gerenciamento de projetos determinar a melhor metodologia a ser
aplicada em seus trabalhos. Além disso, cabe ressaltar que a metodologia não é de
aplicabilidade imediata a qualquer organização uma vez que, para que se atinja o resultado
desejado pela mesma, é necessária uma preparação que será descrita no item 3.2 deste
trabalho.

15
2. FUNDAMENTAÇÃO TEÓRICA
2.1. Projetos, processos e sua relação com o ciclo PDCA
Uma metodologia de gerenciamento de projetos é uma personalização dos processos
adotados por uma organização para gerenciar seus projetos à luz dos conjuntos de melhores
práticas existentes no mercado como é o caso do Project Management Book of Knowledge.
Os desenvolvedores de metodologias e as organizações que as aplicam tem a liberdade de
incluir práticas, processos ou ferramentas não listadas nas melhores práticas de acordo com a
necessidade de seu ambiente ou de seus projetos. Para entendermos a construção de uma
metodologia, portanto, faz-se necessário o entendimento de alguns conceitos.
O conceito de projeto, segundo a 5ª Edição do Guia PMBOK, é caracterizado por um
“esforço temporário empreendido para criar um produto, serviço ou resultado único” (PMI,
2013, p. 3). Para o desenvolvimento deste trabalho consideraremos que o resultado único
buscado por cada projeto a ser desenvolvido com o uso da metodologia aqui proposta é o de
melhorar um processo produtivo já existente dentro da organização. Entendamos dessa forma
que o processo produtivo em si não poderá nunca ser tratado como um projeto e, portanto, a
metodologia apresentada não pode ser utilizada para seu gerenciamento diário.
Segundo o glossário do Guia PMBOK, um processo é “Uma série de atividades
sistemáticas direcionadas para alcançar um resultado final de tal forma que se aja em relação a
uma ou mais entradas a fim de criar uma ou mais saídas.” (PMI, 2013, p. 558). A partir dessa
definição é importante diferenciarmos dois grandes grupos de processos que não poderão ser
confundidos durante a leitura deste trabalho: Processos Produtivos e Processos da
Metodologia. A relação entre os grupos de processos se dá de maneira cíclica onde, as
entradas, atividades e saídas pré-projeto dos Processos Produtivos, serão as entradas para o
desenvolvimento dos Processos da Metodologia de Gerenciamento de Projetos. Em
contrapartida as atividades deste segundo grupo de processos objetivarão gerar como saídas,
melhores e/ou mais eficientes entradas, atividades e saídas para os Processos Produtivos. As
normas, padrões, políticas entre outros que podem ser usados para documentar os processos
são parte do que o PMBOK se refere como Ativos de Processos Organizacionais.

16
Figura 1 – Representação gráfica do Ciclo de Shewart PDCA.
FONTE: AGUIAR, 2002, p. 23
A relação entre os grupos de processos que introduzimos no parágrafo acima nada mais
é do que o conceito do ciclo de Shewart, também conhecido como o ciclo PDCA (Plan, Do,
Check, Act) apresentado na Figura 1. Este ciclo é o primeiro conhecimento básico para a
implantação de ciclos de manutenção, melhoria contínua ou inovação de processos de
qualquer natureza. (AGUIAR, 2002, p. 16).
Figura 2 – PDCA para Gerenciamento de Projetos.
FONTE: COGHI, 2014, p. 48.

17
Quando aplicado ao gerenciamento de projetos podemos dizer que para cada fase do
ciclo de vida deve-se executar um ciclo PDCA completo como mostra a figura 2. Cada final
de ciclo é marcado obrigatoriamente pela entrega do produto da fase, podendo o mesmo ser
aprovado ou reprovado. Caso aprovado ocorre o encerramento daquela fase; caso reprovado
inicia-se o seu retrabalho através de uma solicitação de mudança. O mesmo conceito
exemplificado pelas fases é aplicado aos projetos, programas ou portfólios como um todo
conforme apresentado na figura 3.
Figura 3 – PDCA para Gerenciamento de Portfólios, Programas e Projetos.
FONTE: COGHI, 2014, p.46.
Apenas para efeito de ilustração, uma vez que não abordaremos diretamente o tema
neste trabalho, apresentamos abaixo o conceito do PMBOK 5ª Edição para Programas:
Um programa é definido como um grupo de projetos, subprogramas e atividades de
programa relacionados, gerenciados de modo coordenado visando a obtenção de
benefícios que não estariam disponíveis se eles fossem gerenciados individualmente.
Os programas podem incluir elementos de trabalho relacionado fora do escopo dos
projetos distintos do programa. Um projeto pode ou não ser parte de um programa,
mas um programa sempre terá projetos. (PMI, 2013, p.9)
E também para Portfólios:
Um portfólio refere-se a projetos, programas, subportfólios e operações gerenciados
como um grupo para atingir objetivos estratégicos. Os projetos ou programas do
portfólio podem não ser necessariamente interdependentes ou diretamente
relacionados. [...] a empresa poderá decidir gerenciar projetos relacionados como um
programa. [...] Assim, os programas [...] tornam-se componentes integrais do
portfólio [..] (PMI, 2013, p.9)

18
2.2. Ciclos de Vida, Fases e Grupos de Processos
Devemos neste momento conceituar mais profundamente o tema dos ciclos de vida,
fases e grupos de processos de gerenciamento de projetos, pois é de fundamental importância
sua diferenciação no entendimento de seu uso na metodologia.
O Ciclo de Vida de um projeto é a estrutura básica de gerenciamento, normalmente
dividida em fases, que independe do trabalho específico desempenhado pela equipe do projeto
durante sua execução (PMI, 2013, p.38). Isso significa que os ciclos de vida podem ou não ser
padronizados por uma metodologia, porém a escolha pela padronização ou liberdade de
escolha muito tem a ver com a desenvoltura e experiência da organização e da equipe em
gerenciar projetos. Xavier et al. (2014) descrevem os conjuntos de fases apresentados no
Quadro 1 como exemplos de ciclos de vida de projetos:
Projetos de implantação de novas
tecnologias
Projetos de Desenvolvimento de Novos
Produtos
Definição Concepção
Estudo de Viabilidade Pesquisa
Pesquisa Design
Seleção de tecnologia/fornecedores Contratação
Implementação ou Construção Fabricação do protótipo
Implantação Fechamento do Projeto
Acompanhamento Inicial da Operação
Fechamento do Projeto
Quadro 1 – Exemplos de Fases que podem compor o Ciclo de Vida de Projetos
FONTE: Adaptado de Xavier Et. Al., 2014, p. 10
Observe que, não importando onde será implantada uma nova tecnologia ou qual o tipo
de produto que será desenvolvido, em inúmeros casos será possível trabalhar com os
conjuntos de fases propostos. Além disso, o ciclo de vida do projeto também é uma referência
para os níveis de custo e pessoal envolvidos em cada fase do projeto, conforme demonstrado
na Figura 4:

19
Figura 4 – Níveis típicos de custo e pessoal na estrutura genérica do ciclo de vida.
FONTE: PMI, 2013, p. 39.
Também o risco e o custo das mudanças variam com o tempo no ciclo de vida:
Figura 5 – Impacto das variáveis com base no tempo decorrido do projeto.
FONTE: PMI, 2013, p. 40.
O entendimento de que o ciclo de vida do projeto é muito mais do que simplesmente
nomear suas fases pode mudar completamente a maneira de uma equipe planejar um projeto,

20
passando a considerar algo mais do que a tripla restrição (Escopo, Tempo e Custo) e voltando
sua atenção para áreas de suma importância como Riscos e Stakeholders.
Assim como vimos que o ciclo de vida é representado por um conjunto de fases, as
fases em si são representadas por conjuntos de pacotes de trabalho, que devem ser envolvidos
em uma relação lógica e culminar com a entrega de um produto ou subproduto do projeto.
Não existem fases iguais a outras; cada uma é única e depende de um esforço diferenciado.
(PMI, 2013, p. 41).
Entende-se, portanto, que é impossível padronizar uma fase uma vez que seu produto é
único. Por isso, para geração de uma metodologia de gerenciamento de projetos é necessário
que se conheçam os processos de gerenciamento de projetos que, por sua vez, são organizados
nos chamados Grupos de Processo. Estes, sim, são passíveis de padronização uma vez que
não se tratam de atividades relacionadas ao produto e sim de uma relação lógica entre as
entradas necessárias, as ferramentas para o desenvolvimento do trabalho e as saídas que se
deseja gerar. Os cinco grandes Grupos de Processos conforme definidos pelo PMI são
apresentados na figura abaixo:
Figura 6 – Grupos de processos de gerenciamento de projetos.
FONTE: PMI, 2013, p. 50.
2.3. Perfil do gerenciamento de projetos na Indústria
Fundado em 2003 no Capítulo do PMI baseado no estado do Rio de Janeiro o site
PMSurvey.org vem desde então realizando anualmente pesquisas de mapeamento do perfil da

21
comunidade de gerenciamento de projetos. Inicialmente uma inciativa brasileira e,
posteriormente, estendida ao âmbito mundial, o PMSurvey.org hoje, com o apoio do PMI é
um dos sites mais confiáveis para coleta de informação sobre o assunto. (PMSURVEY.ORG,
2013)
Considerando como base as pesquisas realizadas pelo site nos anos de 2010 a 2013
podemos encontrar alguns dados bastante interessantes sobre a participação do setor industrial
no gerenciamento de projetos, principalmente no Brasil. No ano de 2010, por exemplo, não
houve número de participantes significativo para que se definisse um indicador voltado para
as indústrias de bens de consumo, automotiva e manufatureira – a pesquisa exige um mínimo
de 4 resultados para que se possa garantir a confidencialidade dos dados.
Nos anos de 2011 a 2013, com o aumento da participação das indústrias na pesquisa é
possível observar que o gerenciamento de projetos nas mesmas é predominantemente
realizado internamente, característica essa que difere do balanço global com leve tendência à
realização de projetos externos – em média 55%. Esta predominância indica uma dedicação
maior aos projetos de engenharia industrial onde se inserem os projetos de melhoria de
processos produtivos. O aumento significativo dos PMOs relacionadas à área confirma esta
tendência juntamente com a crescente utilização das metodologias de gerenciamento de
projetos. As figuras 7 e 8 demonstram a diferença entre os perfis global e das indústrias
específicas como traçado pelas pesquisas de 2011 a 2013 do PMSurvey.org.
Figura 7 – Perfil Global de Projetos segundo PMSurvey.org 2011 a 2013
FONTE: Adaptado de PMSurvey.org, 2011, 2012 e 2013

22
Figura 8 – Perfil de Projetos das Indústrias segundo PMSurvey.org 2011 a 2013
As áreas de Tecnologia da Informação que em 2011 sobravam à frente no quesito de
atuação com escritórios de projetos sofreram quedas consecutivas e foram alcançadas pela
Engenharia que vem em constante crescimento. Isso pode explicar também o crescimento dos
projetos realizados com a efetiva participação dos clientes internos – característicos das áreas
de atuação principal das organizações – e o descenso dos projetos realizados sem a
participação efetiva dos mesmos uma vez que os clientes internos de áreas de apoio, como TI,
na maioria das vezes não possuem o conhecimento específico para auxiliar no
desenvolvimento dos projetos. A figura 9 demonstra essa relação inversa de crescimento entre
as áreas.
Espera-se, portanto, que com o maior envolvimento dos clientes internos e a crescente
aplicação das metodologias de gerenciamento de projetos nos processos chave da indústria os
resultados dos projetos possam ser cada vez mais consistentes; porém, o que se observa em
muitos casos é o contrário. Apesar da demonstração de satisfação com o atingimento das
metas pela maioria das organizações – 61% das empresas responderam atingir suas metas a
maioria das vezes em 2013 – os desvios de tempo, qualidade e satisfação dos clientes são
percebidos cada vez mais com o passar dos anos. (FIGURA 10)

23
Figura 9 – Porcentagem das indústrias com PMOs de Engenharia e TI
Figura 10 – Percepção de desvios de Tempo, Qualidade e Satisfação vs. atingimento das
metas.
Os números apresentados sugerem então que a metodologia utilizada pelas indústrias
pode não estar adequada às suas necessidades e características, sendo um dos objetivos deste
trabalho oferecer uma alternativa a este problema.

24
2.4. Lean Manufacturing aplicado a projetos
O pensamento Lean, como é chamada a base teórica do Lean Manufacturing é o
resultado de uma evolução do pensamento industrial comandada pelos japoneses em sua luta
pela recuperação pós-guerra. Neste trabalho utilizaremos, além dos conceitos relacionados ao
Gerenciamento de Projetos apresentados acima, o referido pensamento como base para o
desenvolvimento de uma metodologia mais próxima da realidade do dia-a-dia da indústria. A
seguir apresentamos um breve histórico da evolução industrial ocorrida no mundo a partir do
século XIX.
O sistema de produção artesanal que vigorou até o final do século XIX tinha poucas
vantagens. Os níveis de padronização eram baixos e, com isso, a solução apresentada era a da
personalização dos produtos o que levava a tempos elevados de espera devido à baixa
mecanização do processo e alto grau de desperdício. No século XX, com a chegada do
sistema de produção em massa, a indústria conheceu os produtos padronizados e a
mecanização, mas a falta de organização dos processos ainda gerava desperdício significativo.
Desperdício esse que os japoneses não poderiam tolerar em um delicado momento de
reconstrução, em primeiro lugar pela escassez de recursos e, em segundo, por serem
culturalmente ligados ao senso de economia.
Figura 11 – Evolução das características do pensamento industrial
FONTE: RODRIGUES, 2014, p.14.

25
A solução encontrada foi desenvolver um pensamento que aproveitava o que havia de
melhor no passado e introduzia inovações no controle de processos e redução do desperdício.
Este pensamento foi chamado de Produção Enxuta ou Lean Manufacturing e é baseado em
cinco pilares que são representados na figura 12. (RODRIGUES, 2014)
Figura 12 – Os cinco pilares do pensamento Lean
FONTE: Rodrigues, 2014, p. 18.
É justamente a partir dos cinco pilares apresentados acima que faremos a ligação do
Pensamento Lean aos conceitos de Gerenciamento de Projetos apresentados neste trabalho. O
ponto de vista de Taiichi Ohno e Shigeo Shingo, principais influenciadores e inventores do
Sistema Toyota de Produção, é capaz de integrar as diversas áreas de conhecimento
necessárias para o bom e eficiente gerenciamento de um projeto. A intenção a seguir é
demonstrar o alinhamento dos grupos de processos do PMBOK com os cinco pilares do
Pensamento Lean.
2.4.1. Valor
“Os valores sociais mudaram. Agora não podemos vender nossos produtos a não ser
que nos coloquemos dentro dos corações de nossos consumidores, cada um dos
quais tem conceitos e gostos diferentes. Hoje, o mundo industrial foi forçado a
dominar de verdade o sistema de produção múltiplo, em pequenas quantidades”
Ohno, 1988
A consagrada frase de Taichii Ohno apresentada acima descreve perfeitamente o que
significa o Valor do Produto para o Lean Manufacturing. Nada menos do que atender

26
completamente e satisfazer toda e qualquer necessidade do seu cliente. Uma espécie de
personalização em massa, onde o sistema trabalha com um complexo conjunto de
necessidades e desejos a serem atendidos e tratados como prioridade número um. O valor é
sempre definido pelo cliente e deve ser buscado incessantemente pela organização.
Para o Pensamento Lean, tudo aquilo que não é valor é chamado de “Muda” ou
Desperdício e pode ser classificado em sete tipos: Superprodução, Transporte, Estoque,
Defeitos, Processamento, Movimento e Tempo de Espera. (RODRIGUES, 2014)
Para o Gerenciamento de Projetos os Valores são os Requisitos, Premissas e Restrições
levantados junto aos Stakeholders. Seu levantamento começa no Grupo de Processo de
Iniciação da Metodologia, é consolidado com o alinhamento das expectativas durante o
Planejamento e desenvolvido e atualizado durante toda a Execução, Monitoramento e
Controle. Ao Encerramento de uma fase, devemos ter a verificação do atendimento dos
Valores nela desenvolvidos e ao final do projeto a certeza do atendimento ao que fora
alinhado anteriormente.
O Desperdício zero objetivado pelo Lean Manufacturing é um ideal a ser perseguido,
porém não é, de fato, uma realidade. Existirão sempre “Mudas” a serem identificadas e
corrigidas e para essas correções é que se desencadeiam os projetos de melhoria de Processos
Produtivos. A figura 13 demonstra através de um diagrama SIPOC (Suppliers ou
Fornecedores; Inputs ou Entradas; Processes ou Processos; Outputs ou Saídas; Clients ou
Clientes) o fluxo natural de um processo.
Figura 13 – Fluxo natural dos processos sem aplicação da Produção Enxuta

27
FONTE: Elaborado pelo autor
Os projetos de melhoria de Processos Produtivos podem ser desempenhados em
diversos níveis de detalhamento desde uma visão macro do processo visando melhorar um
indicador que é comum aos seus subprocessos, até um projeto bastante específico buscando
melhorar a eficiência de uma determinada etapa do processo ou subprocesso. Na figura 14 é
apresentada a transformação ideal de um processo pelo Lean Manufacturing onde, ao final, o
mesmo gera unicamente Valor.
Figura 14 – Transformação ideal de processo pela aplicação da Produção Enxuta
FONTE: Elaborado pelo autor
2.4.2. Cadeia de Valor
Para o Lean Manufacturing a Cadeia de Valor é o conjunto de etapas e ações que devem
ser realizadas para construção dos Valores definidos para o produto. Isso envolve diversos
atores do processo, sendo eles: fornecedores, organização focal, distribuidores, varejistas e o
próprio cliente final como último elo da cadeia. (RODRIGUES, 2014)
Sob o ponto de vista do Gerenciamento de Projetos a Cadeia de Valor pode ser definida
como a escolha dos milestones ou entregas que devem ser realizadas de forma a criar o Valor
maior do projeto, ou seja, o Ciclo de Vida do projeto. Os Stakeholders do projeto, além de
definir os Valores, podem também ser parte da Cadeia e participar do desenvolvimento das
atividades do projeto. Estas definições são rudimentares durante a Iniciação do projeto ou da

28
fase, e ganham forma definitiva a partir do Planejamento. Dificilmente a Cadeia de Valor de
um projeto irá mudar a partir de sua execução, podendo sofrer alterações apenas em seu fluxo
que veremos a seguir.
2.4.3. Fluxo da Cadeia de Valor
Cada ator do processo, seja ele interno ou externo à organização, tem a sua Cadeia de
Valor individual que, quando unidas, formam o Fluxo da Cadeia de Valor daquele produto
que se deseja gerar. A Organização Focal atua como cliente na Cadeia de Valor de seus
fornecedores externos puxando a produção a partir da sua demanda e têm por sua vez a
programação da sua produção puxada pelos clientes finais, conforme ilustrado na figura 15.
Os atores colocados entre a Organização Focal e o Cliente devem ter sua Cadeia de Valor
incorporada no lead time para atendimento da demanda do cliente final.
Figura 15 – Representação genérica do Fluxo da Cadeia de Valor.
FONTE: RODRIGUES, 2014, p. 20.
O Fluxo da Cadeia de Valor de um projeto está ligado à sua execução e é representado
pelos pacotes de trabalho definidos durante o planejamento quando devem ser definidos os
participantes e responsáveis por cada etapa do Fluxo.

29
2.4.4. Produção Puxada
No Pensamento Lean, parte-se do princípio que nenhum processo pode produzir algo
sem que o seu cliente interno ou externo o solicite, ou seja, o valor do cliente representado por
um pedido é que define qualquer início de trabalho. Este é o significado da Produção Puxada.
Quando associada a projetos, pode-se dizer que está associada à identificação do valor
do cliente através da solicitação de um projeto por parte do mesmo e da constante validação
do escopo do projeto entre fases que autorizará o início da próxima etapa.
2.4.5. Busca da Perfeição
A busca da perfeição está associada a dois conceitos do Lean: “Kaizen” e “Kaikaku”.
Os “Kaizen” são pequenos ciclos de melhoria realizados diariamente no processo e que
objetivam minimizar ou eliminar os pequenos desperdícios. O “Kaikaku”, também conhecido
como Kaizen de Fluxo é direcionado aos desperdícios mais significativos e depende de uma
ruptura com o processo antigo e a instauração de um novo modelo para que atinja seu
resultado.
Neste caso, então, para o gerenciamento eficaz dos projetos devem ser feitos “kaizen”
ou controles diários das atividades para que as mesmas não gerem desperdícios de esforço,
tempo ou custo e “kaikaku” para aqueles problemas que necessitam das solicitações de
mudança no fluxo ou pacotes de trabalho já definidos.
Os conceitos apresentados acima são apoiados por práticas e metodologias que foram se
incorporando ao Lean Manufacturing com o tempo e que serão incorporadas à metodologia no
decorrer do seu desenvolvimento com adaptações que permitam sua aplicabilidade a um
projeto. O objetivo disso é aproximar a realidade do Gerenciamento de Projetos ao que a
indústria vive diariamente no controle e gerenciamento de seus processos e ainda apresentar
resultados gerenciais satisfatórios àqueles que nem sempre compreendem os conceitos do
Lean Manufacturing.
Para o Gerenciamento de Projetos a busca da melhoria também se relaciona aos
processos de Gerenciamento da Qualidade.

30
2.5. Mapa de processos do PMBOK 5ª Edição
O mapa de processos do PMBOK 5ª Edição será apresentado como a base para a
correlação da metodologia proposta com os processos sugeridos pelas boas práticas. Neste
sentido, como forma de apresentação inicial, o demonstramos abaixo exatamente como
apresentado em sua versão original.

31
Figura 16 – Grupo de processos de gerenciamento de projetos e mapeamento das áreas de
conhecimento
FONTE: PMI, 2013, p. 61.

32
3. METODOLOGIA PROPOSTA
3.1. Estrutura proposta para a apresentação da Metodologia
Para apresentação da metodologia serão utilizados Modelos gráficos apresentando as
etapas de cada grupo de processo propostas e posteriormente seus conceitos. Os processos
serão sequenciados de acordo com a lógica dos grupos de processos do PMBOK e terão em
seu título a referência do Pilar Lean Associado.
3.2. Requisitos básicos para implantação da Metodologia
3.2.1. Comitê de Gerenciamento de Projetos
Este capítulo irá descrever a Metodologia proposta neste trabalho através da ótica de um
Comitê de Gerenciamento de Projetos (CGP) que tem em sua formação o primeiro requisito
para a implantação bem sucedida da Metodologia.
A organização deve definir, de acordo com a complexidade de seu cenário, a melhor
formação para o seu CGP. Em organizações de estrutura organizacional matricial o CGP pode
ser formado pelos Gerentes de Projeto designados na estrutura, podendo ou não ser
adicionados ao grupo pessoas de alto nível técnico para suporte. Em organizações funcionais
é sugerido um extenso treinamento na metodologia de um grupo multidisciplinar, contando
com membros de todas as áreas funcionais ligadas à Cadeia de Valor do Produto, podendo
ser: Manufatura, Engenharia, Qualidade, Operações, dentre outros. Em ambos os casos, a
designação de representantes dos fornecedores chave para acompanhamento dos projetos que
se fizerem necessários é recomendada. O CGP deve se reunir regularmente para discutir as
solicitações de projeto e o status dos projetos em andamento.
Caso a organização julgue necessário, o CGP poderá ser subdividido de acordo com a
necessidade ou especialidade. No caso de organizações matriciais deve-se levar em
consideração para essa escolha a existência de outros projetos não ligados aos Processos
Produtivos

33
3.2.2. Ferramenta de Captação de Ideias
Para o bom funcionamento da Metodologia proposta é essencial que esteja à disposição
de todos dentro da organização, independentemente do seu nível hierárquico e envolvimento
nos processos, uma ferramenta de captação de ideias para projetos de melhoria que a partir de
agora chamaremos de Convite ao Gemba.
Gemba é uma palavra japonesa que significa o “lugar real”. A ideia do Gemba é muito
disseminada no gerenciamento de processos através do Lean, onde os responsáveis pelas
decisões são convidados a ir ao local onde as coisas acontecem e verificar a situação que está
sendo relatada pelos solicitantes da melhoria ou autores da reclamação. O Gemba pode ser
qualquer lugar que apresente um problema a ser resolvido ou uma solução que pode ser
aplicada a algum outro ponto do processo. Pode estar em qualquer ponto da Cadeia de Valor,
seja ele um fornecedor, cliente ou na própria organização focal. Um projeto pode ter a
necessidade de várias idas ao Gemba para verificar diferentes focos de problema.
A ferramenta a ser disponibilizada depende da disponibilidade de recursos da
organização, podendo ser um endereço de e-mail ou um formulário padrão utilizado com uma
caixa de sugestões ou ainda uma reunião periódica onde os funcionários são convidados a dar
as suas sugestões e ideias. O ideal, no entanto, é ter uma ferramenta que possa ser a mais
próxima e de fácil acesso possível, preferencialmente distribuída em vários pontos, e que
permita a captação da ideia o mais rapidamente possível.
3.2.3. Treinamentos em Lean Manufacturing
É recomendado à organização que sejam oferecidos treinamentos regulares nos
fundamentos, práticas, ferramentas e conhecimentos relacionados à Produção Enxuta em
todos os níveis. Estes conhecimentos são essenciais para que possam servir como o primeiro
filtro de seleção dos projetos.
Conforme descrito anteriormente a Metodologia propõe colocar à disposição de todos
dentro da organização o Convite ao Gemba. O conhecimento preliminar do Pensamento Lean
pode aumentar significativamente o aproveitamento das ideias geradas pelo Gemba e, com
isso, otimizar o trabalho do CGP que será responsável pela realização da ida ao Gemba e da
documentação da visita.

34
3.3. Grupo de Processos de Iniciação
A Iniciação de um projeto é marcada pelo desenvolvimento de um documento com as
informações básicas que justifiquem o projeto. Este documento será submetido à análise e
aprovação do patrocinador do projeto e apenas após a aprovação deste documento estará
autorizado o início do planejamento das fases. Ao final de cada fase os processos de iniciação
podem ser revisitados para garantir o alinhamento do projeto ao acordado inicialmente.
Figura 17: Fluxograma do Grupo de Processos de Iniciação
FONTE: Elaborado pelo Autor
3.3.1. Ir ao “Gemba” - Pilar associado: Valor do Projeto
Todo projeto a ser estudado e trabalhado de acordo com a Metodologia proposta neste
trabalho deve necessariamente ser iniciado por uma visita ao “Gemba”. O objetivo de levar os
representantes do Comitê a estarem presentes no processo é trazer como prioridade o
entendimento da real situação do Processo Produtivo que possibilitará o estudo do Projeto.
Não se deve confundir a ida ao “Gemba” aplicado a Projetos com o “Gemba” rotineiro
sugerido pelo Lean, este último é uma forma de ver e agir sobre os problemas do dia-a-dia,
enquanto o primeiro é uma forma de conhecimento do processo para um melhor planejamento
de uma solução para um Desperdício.
A visita a ser realizada no processo pode ser motivada pelos próprios atores do processo
por meio da utilização da Ferramenta de Captação de Ideias ou ainda pela observação de uma

35
tendência negativa de indicadores do processo. Em qualquer das hipóteses, no entanto, uma
Solicitação de “Gemba” (Apêndice A1) deve ser preenchida para formalizar o início do
estudo de um projeto. Este documento deve ser padronizado, de fácil entendimento e
preenchimento e conter informações que sejam suficientes para informar quanto ao
alinhamento da ideia aos objetivos da empresa, sejam eles estratégicos, táticos ou
operacionais.
As respostas às solicitações enviadas deverão ser dadas de acordo com sua priorização
que pode ser realizada através de uma matriz como demonstra a figura 17. Nesta matriz
relacionam-se o foco do projeto, onde a qualidade do produto é o fator mais importante para
atendimento ao valor do cliente, e o impacto do mesmo em um indicador de resultado onde,
em consonância com o pensamento Lean, os indicadores de satisfação dos clientes são
considerados os mais importantes. Ambos os fatores são medidos em uma escala de 1 a 4 e o
resultado do quadrante é representado pela média simples arredondada.
1 2 3 4
FOCODOPROJETO
INDICADOR DE RESULTADO
1
OPERACIONAL TÁTICO ESTRATÉGICO
SATISFAÇÃO
CLIENTES
1 2 2 3
3
2 2 3 3 2
3 3 4 4 4PRODUTO
CUSTO
EFICIÊNCIA
PESSOAS
2 3 3 4
Figura 18: Matriz de Priorização de Solicitações
FONTE: Elaborado pelo Autor.
A partir da priorização sugere-se que sejam dados prazos para o atendimento das
solicitações enviadas, por exemplo, para solicitações do tipo quatro – de maior importância –
deverão ser atendidas dentro de 24 horas úteis; para solicitações do tipo um – de menor
importância – deverão ser atendidas dentro de 30 dias. Estes prazos deverão ser definidos de
acordo com a demanda e a realidade da organização. Poderão também ser definidos os
participantes da visita. Ao final do processo de priorização, deverão ser remetidas ao

36
solicitante e demais participantes convocações, por meio adequado de comunicação,
informando a data e horário previstos para a realização da visita.
O planejamento da visita através da busca de informações nos ativos dos processos
organizacionais, a observação crítica profunda e o respeito aos atores do processo através de
seu envolvimento e captação de opiniões são os fatores primordiais para uma ida ao “Gemba”
com sucesso.
Após a visita um relatório (Apêndice A3) deve ser elaborado com foco no
desperdício que está sendo estudado. Caso outros desperdícios de qualquer natureza sejam
identificados na visita os mesmos devem ser documentados e estudados de forma conjunta
com o projeto sendo desenvolvido ou mesmo através de novas solicitações. Ao final deste
relatório a equipe que realizou a visita, juntamente com o solicitante, deve entrar em um
consenso pela necessidade ou não do projeto e justificar a sua decisão com base nos fatos
observados.
Relatórios anteriores relacionados ao mesmo “Gemba”, ou local, podem servir como
base para o planejamento de uma nova ida ao “Gemba”, porém nunca devem eliminar a
necessidade de uma nova visita.
3.3.2. Definir a Cadeia de Valor do Projeto – Pilar Associado: Cadeia de Valor do
Projeto
A Cadeia de Valor do Projeto é parte integrante, porém, não é na maioria das vezes
idêntica à Cadeia de Valor da Organização ou mesmo do Processo. É preciso distinguir cada
uma delas, pois a Cadeia de Valor do Projeto será definida pelos membros das Cadeias da
Organização e dos Processos que tiverem participação, influência ou forem influenciados pela
realização do projeto. Em outras palavras, a Cadeia de Valor do Projeto é definida por seus
Stakeholders.
Para ilustrar graficamente esta cadeia foi eleito o diagrama SIPOC que conforme já
explicado anteriormente define um processo com base em seus Suppliers (Fornecedores),
Inputs (Entradas), Processos, Outputs (Saídas) e Clientes. Os Fornecedores, os Processos
estudados e os seus envolvidos e também os clientes são os Stakeholders com o mais alto grau
de interesse no projeto, porém restam ainda os Stakeholders externos ao processo que por um
motivo ou por outro podem ter interesses ou influências sobre sua execução ou produto. Estes

37
Stakeholders propõe-se representar em uma área externa do SIPOC de maneira próxima ao
ponto da Cadeia de Valor à qual se relaciona. (Apêndice A4)
Muitas empresas já adotam a diagramação SIPOC tradicional ou outros tipos de
diagramação de processos que naturalmente não precisariam ser refeitas, apenas atualizadas
com as informações adicionais relevantes ao Projeto, por exemplo, o nome das organizações
fornecedoras de insumo, o responsável pelo processo focal e os Stakeholders externos ao
Processo. Como os projetos em questão tem foco na redução de desperdícios é recomendável
que se represente os mesmos no diagrama como Outputs do processo correspondente,
lembrando sempre que apesar do Output de um processo poder ser sequencialmente
representado como Input da próxima etapa os desperdícios não podem ser representados como
entradas de um processo, afinal os mesmos não tem proveito algum. A figura 18 representa
um exemplo de SIPOC para Identificação de Stakeholders num Projeto para redução de
geração de resíduos e redução de quebras no transporte.
Figura 19: SIPOC para Identificação de Stakeholders
FONTE: Elaborado pelo autor.
Observe que se estudássemos apenas o processo de Produção e não a Cadeia de Valor
como um todo talvez poderiam ser buscadas apenas soluções para o desperdício gerador de
excesso de resíduos no processo, porém existem outros fatores relevantes como a quebra
excessiva no transporte que pode estar ligada à mesma causa raiz: uma embalagem de baixa
resistência.

38
3.3.3. Elaborar o Termo de Abertura do Projeto – Pilar associado: Valor do Projeto
Taiichi Ohno, idealizador do sistema Toyota de Produção uma vez disse “dados são
importantes, mas dou maior ênfase aos fatos”.
O Termo de Abertura do Projeto (TAP) (Apêndice A5) visa transformar os fatos
encontrados no “Gemba” em um documento estruturado com dados de cunho gerencial que
possam servir para tomada de decisões quanto ao investimento de recursos no projeto
proposto. Trata-se de consolidar dados através de fatos. Nunca o contrário. Ele deve ser
preferencialmente elaborado pelo Patrocinador do Projeto (Gerente Funcional) em conjunto
com o Gerente de Projetos.
Devem estar contidos neste documento a designação do Gerente do Projeto; as
justificativas e os objetivos SMART (Specific, Measurable, Achievable, Relevant, Time-
Framed) definidos para o Projeto, sempre baseados nos desperdícios encontrados no
“Gemba” e no seu principal indicador relacionado; o escopo preliminar do Projeto relatando
as principais etapas que deverão ser percorridas e o que se deve e, muito importantemente,
não se deve esperar do produto do Projeto. É importante constar também um cronograma dos
deliverables do projeto que deve ser tão detalhado quanto à complexidade do projeto exigir
num momento de planejamento preliminar – isto será definido pelo Gerente do Projeto em
momento oportuno – e os critérios básicos de aceitação do projeto.
Em projetos de baixa complexidade e cujo tema seja de domínio do solicitante o
Gerente de Projeto designado poderá solicitar ao Patrocinador a inclusão do solicitante como
Sub-Gerente do Projeto devendo nesse caso haver detalhamento das responsabilidades e
autoridades de cada um.
Elementos opcionais que podem enriquecer o Termo de Abertura do Projeto são, entre
outros: restrições e premissas do projeto, riscos identificados e orçamento preliminar.
Este TAP será posteriormente avaliado e aprovado pelas Gerências Funcionais das
áreas envolvidas.
3.3.4. Aprovar o Projeto – Pilar associado: Produção Puxada
“A produção puxada é que define o início de todo o processo produtivo no Sistema
Lean: não se deve produzir sem que o cliente do processo posterior, interno ou
externo, solicite, ou seja, puxe.” (Rodrigues, 2014)

39
As aprovações dos projetos ou fases numa metodologia Lean são as definidoras da
Produção Puxada. Significam dizer que a área cliente do projeto enxerga produção de Valor
naquilo que está sendo realizado e quer que seja dada continuidade.
Para aprovação dos projetos e fases realizados com a presente metodologia sugere-se
que sejam analisadas, de forma racional, a cada aprovação as evidências de valor potencial em
cada esfera da Cadeia de Valor através da avaliação de três perguntas. Caso a resposta para ao
menos duas delas seja sim o balanço do valor na Cadeia está positivo e deve-se prosseguir,
caso contrário não deverá ser aprovado o projeto ou fase.
a. Do ponto de vista dos Fornecedores: As alterações sugeridas/realizadas afetam
positivamente o Valor que entrego ao Processo Focal?
b.Do ponto de vista dos Processos: É possível entregar mais valor aos meus clientes
externos e internos através das alterações sugeridas/realizadas?
c. Do ponto de vista dos Clientes: Podemos esperar maior qualidade no produto final
por conta das alterações sugeridas/realizadas no processo?
Quanto maior a complexidade do Projeto, maior a necessidade de se realizar uma
análise profunda dessas três questões e, para isso, podem ser utilizado brainstorms coletivos
ou confidenciais, entrevistas, simulações numéricas, entre outras ferramentas de mediação que
se julgarem adequadas ao momento.
3.4. Grupo de Processos de Planejamento
A lenta mas coerente tartaruga causa menos perda e é muito mais desejável do que a
lebre veloz que corre na frente e pára de vez em quando para cochilar. O sistema
Toyota de produção só pode funcionar quando todos os funcionários se tornam
tartarugas (Taiichi Ohno)
Com o Termo de Abertura do Projeto aprovado é chegado o momento de realizar o
planejamento profundo do projeto. Não há projeto, por mais simples que aparente ser que
possa ser realizado sem um detalhamento de escopo, tempo, custo e qualidade envolvidos.
Todo projeto deve ter uma equipe com responsabilidades bem definidas, principalmente em
organizações matriciais onde um membro do projeto pode ter seu calendário dividido entre
suas funções originais e o projeto em desenvolvimento.
As áreas de Gerenciamento de Riscos, Comunicações e Aquisições também não podem
ser esquecidas. Comunicações lidera o ranking de problemas mais comuns em Projetos pelo

40
terceiro ano consecutivo com citação por mais de 60% das empresas que responderam a
pesquisa do PMSurvey.org e a área de riscos apresenta média de 50%, apesar de tendência de
queda no indicador através dos anos.
O Grupo de Processos de Planejamento da Metodologia proposta seguirá o seguinte
fluxograma:
Figura 20: Fluxograma do Grupo de Processos de Planejamento
FONTE: Elaborado pelo Autor
3.4.1. Coletar os Requisitos de Valor – Pilar Associado: Valor do Projeto
Para a coleta dos requisitos de Valor do Projeto será necessário novamente praticar a ida
ao “lugar onde as coisas acontecem”, o “Gemba”. Dessa vez, porém, a abordagem utilizada
poderá ser menos formal, sem dependências de documentos ou solicitações. A idéia é que
uma vez o projeto aprovado, por seu tempo determinado, o Gerente do Projeto – e
posteriormente sua equipe - deverá vivenciar o local onde as coisas acontecem em toda a
Cadeia de Valor. Fazer reuniões e visitas a fornecedores, entrevistar ou simplesmente
acompanhar o trabalho dos atores do processo focal são exemplos da rotina de contato com o
“Gemba” que devem ser aproveitada para realizar a coleta dos Requisitos de Valor do Projeto.
O Gerente do Projeto deverá identificar e mapear os Requisitos de Valor do Projeto
sempre fazendo referência individual ao Stakeholder que o levantou, mesmo que isso
signifique algumas repetições na Matriz. Esta interligação entre o requisito e o Stakeholder
ajudará posteriormente a definir o grau de interesse dos Stakeholders no Projeto facilitando o

41
gerenciamento do seu engajamento. Outro ponto positivo é a priorização que pode ser feita
dos Requisitos baseado na repetição e afinidade dos temas, permitindo um planejamento de
atividades melhor direcionado. Além disso, o direcionamento das comunicações poderá ser
feito de acordo com os maiores interesses do público-alvo. O Apêndice A6 mostra um
exemplo de Matriz de Requisitos que pode ser usada pelo Gerente do Projeto onde é possível
também compactar as repetições de requisitos em grupos tornando mais fácil o estudo dos
requisitos posteriormente.
É importante lembrar que a coleta de requisitos pode ser feita de maneira direta, por
contato com o stakeholder, ou indireta, pela leitura de documentos ou leis, por exemplo. Os
requisitos podem ser também divididos entre Requisitos Construtivos e Requisitos de
Bloqueio, ou seja, o que devemos fazer para que o objetivo do projeto aconteça e o que não
devemos fazer e que pode apresentar riscos para o atingimento dos objetivos do projeto.
Apesar de ser o primeiro passo do planejamento a coleta de requisitos se estende
durante todo o ciclo de vida do projeto tornando a Matriz de Requisitos um documento vivo e
sujeito a mudanças. Não é recomendável, no entanto, realizar exclusões na matriz, mas apenas
comentários que expliquem as variações identificadas para os requisitos. Isto muitas vezes
ajudará a perceber a evolução do engajamento dos stakeholders.
3.4.2. Mapear os Stakeholders Prioritários – Pilar associado: Cadeia de Valor do
Projeto
A partir da Matriz de Requisitos elaborada os Stakeholders prioritários do Projeto
deverão ser definidos por três fatores: a quantidade de requisitos relacionados na Matriz ao
Stakeholder nos dará a informação de quanto Valor o Stakeholder percebe no projeto; a
quantidade destes mesmos requisitos levantados de maneira direta (pessoalmente) nos dará a
informação sobre o engajamento do Stakeholder no projeto; e finalmente, o balanço entre
Requisitos Construtivos e Requisitos de Bloqueio nos dará a informação sobre o interesse do
Stakeholder no projeto, ou seja, se ele quer que o mesmo prospere ou fracasse.
Estes dados serão tratados a partir de uma matriz simples que posteriormente
possibilitará o rankeamento dos stakeholders nas seguintes categorias: Valor Acima da Média
(VAM); Maior Valor Direto (MVD); Maior Valor Indireto (MVI); Predominantemente
Construtivos (PC); Predominantemente Bloqueadores (PB). Aqueles Stakeholders que

42
figurarem em três das categorias acima simultaneamente serão considerados os Stakeholders
Prioritários e deverão ser acompanhados definindo-se estratégias de acordo com as
combinações abaixo.
a.VAM + MVD + PC: São os maiores apoiadores do projeto e devem ser
trabalhados para conseguir maior apoio e recursos e também para garantir que
essa posição se mantenha.
b.VAM + MVI + PC: São aqueles que têm grande potencial de apoiar o projeto
porém não se envolveram, ou não foram envolvidos, suficientemente até agora.
Devem ser trabalhados de forma a trazê-los mais próximos do projeto.
c. VAM + MVD + PB: São Stakeholders que apresentam maior ameaça aos
objetivos do projeto, pois estão próximos do mesmo e são predominantemente
bloqueadores. As estratégias devem ser definidas para afastá-los do projeto e/ou
minimamente neutralizar suas posições.
d.VAM + MVI + PB: São Stakeholders que apresentam ameaça potencial aos
objetivos do projeto, pois apesar de não estarem próximos do mesmo são
predominantemente bloqueadores. As estratégias devem ser definidas para
mantê-los afastados do projeto e/ou minimamente neutralizar suas posições.
Caso o número de Stakeholders identificados para priorização seja muito alto poderão
ser aplicados pesos de acordo com a posição do Stakeholder na Cadeia de Valor de acordo
com a tabela abaixo:
Posição na Cadeia de Valor Peso
Externo à Cadeia de Valor 1
Fornecedor Externo 2
Fornecedor Interno 2
Ator do Processo Focal 3
Cliente Interno / Intermediário 2
Cliente Final 4
Influenciadores da Cadeia de Valor 2
Autoridades / Governos 5
O Apêndice A7 mostra um exemplo de mapeamento de Stakeholders.

43
3.4.3. Detalhar o Escopo a Partir das Causas Raiz – Pilar associado: Fluxo da Cadeia
de Valor do Projeto
O processo de detalhamento do Escopo deve revisitar todos os processos já realizados,
pois deverá levar em conta os desperdícios a serem combatidos, os objetivos definidos para o
projeto e também os requisitos de valor definidos pelos seus stakeholders. Deve-se consolidar
estas informações e enriquecê-las de forma a alinhar a melhor maneira de atender às
expectativas levantadas.
Recomenda-se segmentar o detalhamento do escopo por desperdício identificado,
facilitando desta forma o entendimento do que deverá ser realizado para cada objetivo. As
ações com objetivos compartilhados como treinamentos ou visitas ao “Gemba” necessárias
para observação do processo como um todo deverão ser relatadas em um escopo
compartilhado para evitar repetições gerando um relatório mais enxuto.
Antes da elaboração do Escopo Detalhado, no entanto, deverá ser realizado o
levantamento das causas raiz dos desperdícios, objetivando um melhor detalhamento das
atividades a serem executadas. Este levantamento deverá ser realizado por meio de um
diagrama de Causa e Efeito auxiliado pela técnica dos Cinco Porquês e do Brainwriting
(Brainstorming de forma escrita). Para auxiliar nesta fase podem ser convidados os
Stakeholders prioritários definidos como Predominantemente Construtivos, bem como o
solicitante do projeto e lideranças da área. A seguir descrevemos brevemente a forma de
utilização das ferramentas:
a. Definir no diagrama de Causa e Efeito os braços relativos aos 6M: Método,
Máquina, Mão de obra, Medição, Meio Ambiente e Material.
b.Definir o Desperdício estudado como o Efeito no diagrama
c. Descrever brevemente as evidências do Desperdício no “Gemba”
d.Solicitar aos participantes que escrevam o maior número possível de causas
potenciais do Desperdício sem identificações, em letra de forma para evitar
diferenciações e durante um tempo curto acordado entre o grupo.
e. Distribuir as causas potenciais nos braços do diagrama a partir de um consenso
entre o grupo.

44
f. Aplicar a técnica dos Cinco Porquês para cada uma das causas. Note que em geral
os cinco porquês são suficientes para a identificação da causa raiz, porém, os
porquês devem ser repetidos sucessivamente até a sua conclusão.
Vale ressaltar que a escolha do Brainwriting como alternativa ao Brainstorming é uma
maneira de prevenir possíveis erros na metodologia – preconceitos e julgamentos de ideias –
que podem ser causados por equipes com baixo grau de maturidade na utilização da
ferramenta. À medida que o Gerente do Projeto tiver maior certeza sobre a maturidade dos
participantes, este processo poderá ser revertido gerando maior interação e, possivelmente,
mais apontamentos.
Aplicada a metodologia descrita acima teremos a redução do número de causas a apenas
aquelas consideradas fundamentais para solução do Efeito. Sobre essas deverão ser
elaborados os detalhamentos do escopo considerando-se as restrições e premissas aplicáveis e
os resultados dos indicadores relacionados.
Recomenda-se disponibilizar os diagramas de estudo da Causa e Efeito na Gestão
Visual do Projeto. Esta iniciativa pode fazer com que outras pessoas que não as participantes
em seu desenvolvimento levantem novos questionamentos e ideias importantes para o
planejamento e execução do Projeto e, consequentemente, Kaizens para melhoria da
documentação e planejamento do Projeto.
3.4.4. Elaborar a Estrutura Analítica do Projeto – Pilar associado: Fluxo da Cadeia
de Valor do Projeto
A Estrutura Analítica do Projeto (EAP) poderá ser construída de maneira gráfica
buscando facilitar o entendimento do trabalho a ser realizado para atingimento de cada um
dos objetivos do projeto, afinal uma imagem vale mais do que mil palavras (SOTILLE et al.,
2010). Esta representação poderá ser utilizada como elemento principal para construção da
Gestão Visual do Projeto que será apresentada mais a frente como forma de transparência e
interação com os atores do processo focal estudado.
Para iniciar o seu desenvolvimento é necessário que primeiramente se determinem as
Fases do Projeto a serem cumpridas, o que pode ser conseguido tendo como base o
cronograma de marcos iniciais definidos no Termo de Abertura do Projeto. Posteriormente

45
cada um dos pacotes de trabalho definidos na declaração de escopo detalhada deverá ser
alocado de maneira lógica abaixo de sua fase correspondente.
Não é necessário alocar os pacotes de trabalho em sequência de execução uma vez que
isto nem sempre será possível, porém é imperativo que se possa enxergar em cada um dos
pacotes de trabalho um entregável menor necessário à composição do entregável maior
(marco) definido para aquela fase. Os entregáveis menores serão monitorados e controlados
pela equipe do projeto através dos processos de Gerenciamento da Qualidade do Projeto, já o
entregável maior deverá ser validado e aceito pelo patrocinador do Projeto.
É importante que se diferencie um pacote de trabalho de uma atividade. O pacote de
trabalho é representado por um conjunto de atividades que deve ser realizado para a
composição de um entregável. As atividades não deverão ser representadas na EAP uma vez
que serão detalhadas mais a frente quando iniciado o planejamento do tempo do projeto.
Para que se possa visualizar o atendimento aos requisitos do projeto é importante que se
retorne neste ponto à Matriz de Requisitos e, nela, sejam referenciados os pacotes de trabalho
que estão relacionados àqueles valores declarados pelos Stakeholders. Para isso é necessário
que a EAP apresente um sistema numérico de rastreamento que facilitará este trabalho. Este
sistema numérico será também importante para os demais planejamentos subsequentes. Um
exemplo de EAP é fornecido pela figura 21.
Figura 21: Exemplo de EAP organizada por fases
FONTE: PMI, 2013, p. 130

46
A construção gráfica da EAP é feita de maneira muito mais rápida quando realizada
por meios digitais e seu resultado pode ser integrado de maneira a facilitar o
desenvolvimento dos passos seguintes, por isso, recomenda-se realizar este processo com o
auxílio de um software de Gerenciamento de Projetos – para referências de softwares livres
disponíveis no mercado para Gerenciamento de Projetos consulte o Apêndice B.
3.4.5. Realizar a Análise Make or Buy – Pilar associado: Fluxo da Cadeia de Valor
do Projeto
Apesar da característica do projeto nas indústrias, como visto anteriormente, ser
predominantemente interno é preciso amadurecer a análise do que se deve fazer e do que se
deve comprar ou contratar. Para isto existe a Análise “Make or Buy” que poderá decidir pela
terceirização de etapas ou até mesmo do projeto como um todo com base nas competências da
empresa e também dos custos envolvidos na compra ou arrendamento de um produto ou
serviço. O fluxo decisório a ser considerado na Análise é o seguinte:
Figura 22: Fluxo Decisório da Análise Make or Buy
FONTE: Elaborado pelo autor. Adaptado de Xavier et al., 2013 p. 58
Liker (2005) elege como um dos quatro principios do Sistema Toyota de Produção a
parceria. Segundo Liker, o desenvolvimento de líderes e equipes tem o mesmo grau de
importância que o desenvolvimento de parceiros comerciais e fornecedores. Isto mostra que,
para o Lean Manufacturing, existe a hora de executar e existe a hora de terceirizar como
forma de melhorar a qualidade dos resultados e o valor agregado ao processo.
Realizada a decisão por comprar ou contratar o pacote de trabalho deverá ser
preenchido o mapa das aquisições que servirá de base para os compradores realizarem as

47
negociações conseguindo as corretas especificações, com as melhores condições comerciais e
no prazo correto. O Apêndice A8 traz o modelo de Mapa de Aquisições.
3.4.6. Definir e Sequenciar as Atividades do Projeto – Pilar Associado: Fluxo da
Cadeia de Valor
Para definir as atividades do Projeto, agora sim, devemos levar a decomposição das
fases do projeto além dos pacotes de trabalho definidos na EAP. Nesta etapa é importante
buscar realizar as decomposições de maneira segura, consultando especialistas no assunto e
trabalhando com fatos ao invés de presumir necessidades.
Caso haja a impossibilidade de definir a totalidade das atividades relacionadas a um
pacote de trabalho o mesmo deverá ser decomposto até onde possível e definido um prazo
para aprofundamento no estudo do tema. Em casos extremos onde se verificar alterações
significativas no planejamento do projeto (Escopo, Tempo, Custo ou Qualidade) devido à
realização deste estudo poderá haver a redefinição da análise Make or Buy do pacote de
trabalho saindo de Fazer para Comprar, devendo nesse caso ser refeita toda a Análise descrita
em 3.4.5 e registrado no Mapa de Aquisições.
A definição das atividades acrescenta clareza sobre quais os pacotes de trabalho serão
referentes a melhorias no processo existente e quais os pacotes de trabalho voltados à
inovação do processo. Os primeiros deverão receber neste momento a identificação de Kaizen
o que permitirá àqueles que visualizarem a EAP e a lista de atividades a compreensão de que
aquele processo não será radicalmente alterado. Aqueles pacotes de trabalho voltados à
inovação de um ou mais processos deverão ser identificadas como Kaikaku dando a entender
a todos que tiverem acesso à gestão visual que se pretende alterar o processo existente. O
simples fato de realizar esta indicação permite que desde o início do projeto os atores do
processo e outros envolvidos na cadeia de valor expressem suas opiniões e agreguem
informações valiosas ao planejamento e execução destas atividades.
Como saída da definição das atividades deverá ser gerada uma Lista de Atividades do
Projeto que servirá como base para a formação do cronograma posteriormente. Antes disso,
no entanto é necessário realizar o sequenciamento das atividades que permitirá entender as
relações e dependências existentes.

48
É muito comum em projetos de melhoria de processos, especialmente os de pequeno
porte, que se definam as atividades em um “plano de ação” do tipo 5W2H (Who, What,
Where, When, Why, How, How Much) e que sejam dados prazos a essas atividades sem
considerar a sua sequência lógica ou dependências. A falta de sequenciamento, no entanto,
pode levar a diminuição da eficiência dos projetos (PMI, 2013) e gerar uma falsa impressão
de inatividade do mesmo quando na realidade existem apenas dependências ou esperas
necessárias. O processo de sequenciamento, portanto, é imprescindível para uma boa
estimativa de tempo e recursos do projeto.
Para realização do sequenciamento deverá ser utilizado o diagrama de precedências com
a representação das atividades em caixas e as setas para indicar os tipos de relações. Setas
com início à direita da caixa representam relações do tipo “Término para” e setas com início
na esquerda da caixa “Início para”. A mesma lógica se aplica à ponta da seta que quando
chega à esquerda representa “para Início” e quando à direita “para Término”. Tempos de
espera ou antecipação entre as atividades devem ser indicados.
Figura 23: Modelo de diagrama de precedências
FONTE: PMI, 2013, p. 160
O processo de decomposição dos pacotes de trabalho é imensamente facilitado pela
integração dos recursos digitais de construção da EAP com a formação básica do
cronograma em softwares especializados. A formação do diagrama de rede muitas vezes
também é feita automaticamente, poupando o tempo da equipe do projeto, por isso,
recomenda-se realizar este processo com o auxílio de um software de Gerenciamento de
Projetos – para referências de softwares livres disponíveis no mercado para Gerenciamento
de Projetos consulte o Apêndice B.

49
3.4.7. Negociar a Equipe do Projeto – Pilar associado: Cadeia de Valor do Projeto
Este processo poderá ocorrer simultaneamente ou após a finalização da estimativa de
recursos e duração do projeto dependendo do tempo disponibilizado e da urgência associada
ao tema. Em projetos com histórico de lições aprendidas se torna mais viável a realização das
etapas simultaneamente. Em projetos sem histórico é recomendada a realização inicial da
estimativa para posterior negociação evitando o retrabalho.
A definição do processo foi realizada para adequar a metodologia à realidade das
empresas com características matriciais. Conforme explanado anteriormente, nestes ambientes
a autoridade é compartilhada entre Gerentes Funcionais e Gerentes de Projetos e os recursos
disponíveis nas áreas funcionais são os mesmos recursos que serão alocados nos projetos em
andamento. Isto significa dizer que os calendários dos recursos dificilmente serão
integralmente dedicados ao projeto causando a necessidade de negociação entre os Gerentes
Funcionais e o Gerente do Projeto da disponibilidade e do calendário a ser aplicado para os
recursos.
Os fornecedores e outras partes interessadas da Cadeia de Valor também podem
disponibilizar recursos durante o tempo do projeto. Note, neste caso, que estes recursos não
são os recursos alocados nos pacotes definidos por Comprar na Análise Make or Buy e sim
recursos de apoio aos pacotes definidos por Fazer. Nos pacotes do tipo Comprar o fornecedor
elegido para execução do serviço deverá designar seus recursos de acordo com a necessidade
disposta na Matriz de Aquisições.
Os temas desta negociação incluem, mas não se limitam a:
a. Necessidade vs. Disponibilidade de Recursos
b.Conhecimentos técnicos necessários aos Recursos
c. Calendário a ser utilizado
d.Datas de início e término previstas
e. Horários de trabalho
É importante que os acordos firmados em negociação sejam formalizados por um
documento assinado por ambas as gerências e também pelo colaborador alocado.

50
3.4.8. Estimar Recursos e Duração das Atividades – Pilar associado: Fluxo da Cadeia
de Valor do Projeto
Neste processo trataremos inicialmente sobre a estimativa de recursos humanos para o
Projeto o que é de extrema importância neste ponto quando a equipe está sendo negociada e
formada.
A primeira pergunta a ser respondida neste momento é se o projeto, fase, pacote de
trabalho ou atividade tem restrição de data para entrega definida ou se sua duração dependerá
exclusivamente do planejamento realizado e da aprovação do Patrocinador. Caso exista uma
restrição, por exemplo, o projeto deverá ser entregue no dia da visita anual da diretoria, o
mesmo deverá ser estimado com base no trabalho envolvido nas atividades. Caso o objeto de
estudo não sofra com tais restrições poderá, então, ser estimado pela sua duração.
Planejamento com restrição de data:
Para estimar recursos com restrição de data é preciso primeiro definir qual o tempo ideal
de trabalho disponível para aquela atividade. Em se tratando de um projeto este tempo é
determinado pela diferença entre a data da restrição (Entrega Final) e a aprovação do TAP ou
autorização de início do projeto. Da mesma forma com as fases do projeto o tempo ideal é a
diferença de tempo encontrada entre os entregáveis definidos pelo cronograma inicial. Para os
pacotes de trabalho e atividades este indicador será dado pelas precedências definidas no
diagrama de rede. Todos estes tempos deverão considerar o calendário oficial da organização
com 100% de disponibilidade dos recursos para o projeto.
Em seguida definiremos o grau de certeza que se deseja atingir com os cálculos do
trabalho das atividades baseados na criticidade das atividades contidas no seu pacote de
trabalho, sendo eles:
Cálculo % Criticidade da atividade
PERT 50 Pacote de Trabalho Simples
PERT + 1 Desvio-Padrão 84,1 Pacote de Trabalho Kaizen
PERT + 2 Desvio-Padrão 97,7 Pacote de Trabalho Kaikaku
Dessa forma, o cálculo dos trabalhos relacionados às mudanças mais importantes ganha
mais precisão e permite que o trabalho do projeto seja melhor distribuído de acordo com as
prioridades.

51
O cálculo a ser realizado para estimativas de trabalho segue abaixo:
PERT (para atividades) = O + 4xMP + P
6
Desvio Padrão (para atividades) = O – P
6
Variância (para atividades) = (Desvio-Padrão)²
PERT (para projetos) = ΣO + 4xΣMP + ΣP
6
Desvio Padrão (para projetos) = ΣVar1/2
A seguir determinaremos qual a forma de escolha dos dados de cada atividade para
aplicação na fórmula. Para que se possa aprimorar o processo é possível realizar esta etapa do
planejamento juntamente com a definição das atividades (3.4.6):
a. Com Opinião Especializada: Cálculo diretamente com base na opinião
especializada.
b.Sem Opinião Especializada: Utilizar ferramentas de mediação entre três ou mais
pessoas escolhidas de formação multidisciplinar até o atingimento do consenso
para cada um dos pontos: otimista, mais provável e pessimista. Aplicar o cálculo
após consenso. Visitas ao “Gemba” motivador da atividade podem ajudar a
enriquecer o processo.
O trabalho total da atividade deverá então ser comparado ao tempo ideal, juntamente
com a análise das premissas de calendário definidas em 3.4.7 para validação da quantidade de
recursos necessária para realização da atividade. Atividades que exigem multidisciplinaridade
devem ser analisadas de acordo com os calendários individuais dos recursos.
Alternativas de redução da duração das atividades podem ser: a alocação de mais
recursos, a automatização de parte do processo ou a antecipação de atividades de dependência
Término para Início também chamado de fast-tracking. Este é um ponto onde muitos riscos
podem ser identificados, dentre outras. (Barcaui et al, 2010)
Planejamento sem restrição de data:

52
Os planejamentos sem restrição de datas deverão ser realizados pelos mesmos cálculos à
exceção do tempo ideal que não é aplicável ao cenário. Os cálculos deverão ser realizados de
acordo com a lógica do sequenciamento de atividades e deverão respeitar a disponibilidade
descrita nas premissas de calendário da mesma forma. Ao final deverão ser revisados para
identificar ameaças e oportunidades potenciais.
Planejamento de atividades de duração fixa:
Atividades que têm restrição de duração fixa associada não dispensam a estimativa do
trabalho para estimativa dos recursos e viabilidade da execução.
A quantidade e o tipo de recursos necessários deverão ser juntados à lista de
atividades, função esta que é bastante facilitada pelos softwares de gestão atuais.
Recomenda-se utilizá-los – para referências de softwares livres disponíveis no mercado para
Gerenciamento de Projetos consulte o Apêndice B.
3.4.9. Desenvolver e Analisar o Cronograma do Projeto – Pilar associado: Fluxo da
Cadeia de Valor do Projeto
Deverão ser desenvolvidos dois modelos de cronograma para o projeto. O cronograma
de Marcos que já foi preliminarmente apresentado no Termo de Abertura do Projeto deverá
ser revisado de forma a garantir a visualização das entregas mais significativas. Além das
entregas de fases, deverão também constituir marcos os finais dos pacotes de trabalho do tipo
Kaizen e Kaikaku. Este cronograma simplificado será disponibilizado na Gestão Visual do
projeto como forma de fomento à interação dos atores do processo focal com a equipe do
projeto e à transparência quanto às possíveis mudanças no processo.
A segunda forma do cronograma é o gráfico de Gantt que será amplamente utilizado
pela equipe do projeto no seu gerenciamento. Ele consiste na correlação entre a lista de
atividades na vertical, as datas na parte superior em sentido horizontal e barras indicando a
duração das tarefas e atividades. É recomendável que se construa o gráfico de Gantt com o
auxílio de softwares apropriados para Gerenciamento de Projetos não só pela facilidade
apresentada de geração automática após a definição de atividades, sequenciamento e durações
mas pela grande possibilidade de alterações do mesmo. Os softwares disponíveis no mercado

53
oferecem a possibilidade de se gerar versões do cronograma sendo a versão zero chamada de
Linha de Base do cronograma.
A Linha de Base do cronograma nunca deve ser alterada, pois ela é a forma de se
verificar as variações entre o planejado e o realizado de um projeto. Isto possibilita também
um estudo dos riscos associados à atividade e o levantamento de lições aprendidas.
O desenvolvimento do cronograma do projeto é comumente tratado em organizações
com baixo nível de maturidade em Gerenciamento de Projetos como a primeira etapa do
planejamento de um projeto, porém, como já foi demonstrado, muitas coisas precedem esse
passo. Deve-se evitar que o desenvolvimento de cronograma seja baseado simplesmente na
lista de atividades e em seus prazos, sem considerar as demais informações que são
necessárias e, principalmente, sem definir informações importantíssimas como o caminho
crítico do projeto.
O caminho crítico do projeto é o que vai garantir o monitoramento da entrega do Valor
do cliente relacionado ao prazo – sua urgência. Para sua definição será necessário
inicialmente utilizarmos o diagrama de rede associado aos tempos de duração das atividades.
Importante ressaltar que falamos de duração e não de trabalho como calculamos no item 3.4.8,
isto significa que ao trabalho já adicionamos as premissas de calendário e disponibilidade de
recursos negociados em 3.4.7. Um diagrama de rede com caminho crítico aplicado é mostrado
na figura 24.
Figura 24: Exemplo de Diagrama de Rede com Caminho Crítico.
FONTE: PMI, 2013, p. 177

54
Posteriormente serão calculadas as datas possíveis de início e término da atividade com
base no sequenciamento do diagrama de rede e calculadas a folga total das atividades. Os
conceitos seguem abaixo em ordem de determinação na metodologia.
a.Início do projeto (IP): Definido pelo cronograma de Marcos.
b.Início mais cedo (IMC): Para as primeiras atividades planejadas é a data de
início do projeto, para as demais é a maior data de término mais cedo dentre as
atividades anteriores. Normalmente é representada no campo superior esquerdo
da atividade.
c. Término mais cedo (TMC): Deve-se somar a duração estimada da atividade ao
Início mais cedo para encontrar o Término mais cedo. Normalmente é
representado no campo superior direito da atividade.
d. Término do Projeto (TP): É definido pelo maior valor de Término mais cedo
dentre as últimas atividades do projeto.
e. Término mais tarde (TMT): Para as últimas atividades do projeto é igual à data
de término do projeto, para as demais é igual ao menor valor de Início mais tarde
da atividade posterior. Normalmente é representado no campo inferior direito da
atividade.
f. Início mais tarde (IMT): Deve-se subtrair a duração estimada da atividade ao
Término mais tarde para encontrar o Início mais tarde. Normalmente é
representado no campo inferior esquerdo da atividade.
g.Cálculo da Folga Total:
Folga Total = TMT - TMC
A Folga Total representa a quantidade de dias que uma determinada atividade pode
atrasar sem comprometer a entrega do projeto no prazo. O Caminho Crítico por sua vez é
determinado pela escolha das atividades sequenciadas com as menores folgas totais. Em
grande parte das vezes a folga do caminho crítico é igual à zero.
Conforme mencionado acima todo o processo descrito neste item da metodologia pode
ser automatizado com a utilização de softwares adequados de Gerenciamento de Projetos.
Recomenda-se utilizá-los – para referências de softwares livres disponíveis no mercado para
Gerenciamento de Projetos consulte o Apêndice B.

55
3.4.10. Desenvolver o Orçamento do Projeto – Pilar associado: Valor do Projeto
Para desenvolvimento do Orçamento do Projeto consideraremos duas fases: estimativa
dos custos e definição das reservas de contingência. A primeira fase será desenvolvida a partir
das estimativas bottom-up e paramétricas, cujos conceitos serão explicados logo a seguir, e a
segunda será desenvolvida com base nos processos iterativos de gerenciamento de riscos que
serão descritos em 3.4.12, 3.4.13 e gerarão as reservas de contingência do projeto. Além das
estimativas descritas abaixo podem ainda ser utilizadas as estimativas baseadas em opiniões
especializadas; por analogia e de três pontos. (Barbosa et al., 2011)
a. Estimativa Bottom-up: é a estimativa baseada na definição dos custos partindo
do maior nível de detalhamento (micro) em direção ao menor nível de
detalhamento (macro). Poderão ser utilizados dados históricos e/ou atuais
devendo sempre cuidar para que a estimativa realizada seja condizente com o
nível de precisão definido na estimativa de recursos para cada pacote de
trabalho (vide 3.4.8). Para garantir que isso aconteça os cálculos de PERT
devem ser igualmente aplicados aos recursos financeiros. Esta análise é
destinada primordialmente à definição de custos de pacotes tipo “Fazer” da
análise Make or Buy.
b. Estimativa Paramétrica: é a estimativa baseada em dados estatísticos como,
por exemplo, custo da diária de um carro alugado e o custo da gasolina por
quilômetro rodado. Se para realização do trabalho da atividade será necessário
viajar 200 km em um dia saberemos então o custo apenas aplicando os
parâmetros. É uma estimativa de maior aplicabilidade a pacotes de trabalho do
tipo “Comprar” da análise Make or Buy, pois é dependente de estatísticas
confiáveis como preços fixados em contrato, por exemplo.
Para que se defina a reserva de contingência de um projeto é necessário que sejam
identificados e analisados os riscos do mesmo, bem como definidas as suas respostas. Estes
processos gerarão as informações de Valor Esperado (VE) dos riscos que posteriormente
poderão ser transformados na reserva de contingência. Mais detalhes sobre esta definição
serão dados no detalhamento do gerenciamento de riscos do projeto.
Neste ponto do planejamento do projeto, é importante que fique claro, que os processos
de identificação, análise e resposta aos riscos são considerados processos iterativos e, por este

56
motivo, já deverão ter sido executados diversas vezes até aqui. Isto possibilita que a formação
da reserva de contingência inicial seja realizada no mesmo momento da definição do
orçamento das atividades.
3.4.11. Definir os Critérios de Aceitação do Projeto – Pilar associado: Busca da
Perfeição
Tendo como base todo o planejamento anteriormente realizado a definição dos critérios
de aceitação do projeto deverá ser iniciada, ou seja, deverão ser formalizados os níveis
mínimos aceitáveis de resultado que serão tidos como satisfatórios pelo aprovador das fases
e/ou do projeto para que não haja retrabalho ou solicitações de mudança.
Os indicadores da qualidade não serão necessariamente os mesmos definidos pelos
objetivos do projeto uma vez que projetos de melhoria de processo podem ter resultados
esperados em longo prazo e o projeto pode ter que ser finalizado com as previsões indicativas
de sucesso e não com o objetivo final alcançado. Os indicadores da qualidade poderão ser do
tipo quantitativo ou qualitativo, medindo resultados ou simplesmente execução
respectivamente. Sendo quantitativos os indicadores deverão ter períodos de medição
compatíveis com o desenvolvimento e a duração das fases às quais se relacionam, caso
contrário, o aprovador não terá resultados consistentes para avaliar o sucesso do trabalho.
Basicamente podem se dividir os critérios de aceitação em dois grandes grupos: do
produto e do projeto (JUNIOR et al., 2010). Por exemplo, um projeto busca eliminar um
desperdício advindo de defeitos de produção sem que haja redução em sua eficiência e
produtividade. Neste caso os critérios de qualidade do produto poderão estar relacionados à
redução da quantidade de defeitos encontrada em uma determinada amostra à eficiência da
linha de produção. Como critérios de qualidade do projeto poderão ser listados a manutenção
do balanceamento da linha de produção e a realização de análises de qualidade em 100% dos
lotes de matéria prima recebidos. Se forem apresentados resultados de redução de defeitos na
amostra, porém for identificada menor eficiência significa que o trabalho do projeto não foi
conduzido de maneira adequada e, por isso, não poderá ser aceito.
Os critérios de qualidade do projeto serão acompanhados por meio da Folha de
Verificação da Qualidade e os critérios de qualidade do produto serão avaliados a partir da
Folha de Aprovação do Trabalho. A Folha de Verificação deverá apresentar a forma de
monitoramento do trabalho para garantir o resultado final e a Folha de Aprovação deverá
apresentar o trabalho realizado e o resultado alcançado com suas justificativas para aprovação.

57
Os Apêndices A9 e A10 apresentam modelos das Folhas de Verificação da Qualidade e Folha
de Aprovação do Trabalho respectivamente.
***
A partir do tópico 3.4.12 serão detalhados os processos de planejamento que são
iterativos, ou seja, aqueles que, por natureza, se repetem dependendo das circunstâncias
externas e internas ao processo gerando produtos parciais que servirão como base para as
próximas iterações. É o caso principalmente do gerenciamento de riscos.
3.4.12. Identificar e Analisar os riscos – Pilar associado: Busca da Perfeição
O conceito de riscos é algo que muitas vezes não é bem compreendido e, por isso,
precisa ser muito bem definido antes de se iniciar um processo de gerenciamento dos mesmos.
Riscos são eventos incertos que podem impactar no andamento das atividades conforme
foram planejadas. Independentemente de sua característica ser positiva ou negativa, incertezas
serão sempre riscos. Portanto, quando falamos em identificar riscos, falamos sempre de
identificar ameaças ou oportunidades para o projeto (SALLES JR et al, 2010).
A palavra riscos quando mal interpretada conduz à ideia de que riscos são influências
advindas de componentes externos e que podem prejudicar a organização ou o projeto. O
próprio dicionário Michaelis nos conduz a esta análise ao conceituar risco como
“Possibilidade de perigo, incerto mas previsível, que ameaça de dano a pessoa ou a coisa”.
Este conceito precisa ser substituído pelo demonstrado acima para que o gerenciamento de
riscos seja mais eficaz e possa conduzir o projeto a melhores resultados.
Todo risco identificado deve ser composto de um fator incerto, sua probabilidade de
ocorrência, normalmente expressa em porcentagem, e seu impacto no projeto que pode ser
expresso em qualquer unidade quantificável de recursos e passível de formação de reserva de
contingência.
A identificação de riscos pode ocorrer de forma natural através da execução dos
processos de planejamento do projeto ou ainda pela formação de cenários que possam
influenciar no andamento de atividades críticas do projeto.
Por exemplo: um pacote tipo Make do caminho crítico com 15 dias de duração tem
apenas um recurso qualificado para executá-lo e o mesmo tem férias programadas por

58
vencimento para cinco dias antes da data de entrega prevista do trabalho. A princípio, não é
possível adiantar o início do trabalho devido à sua dependência do término da atividade
anterior. Segundo o especialista a probabilidade do trabalho não ser concluído antes de suas
férias é de aproximadamente 40% e o impacto disso seria de 30 dias no prazo de entrega (25
dias de férias + 5 dias para término das atividades).
Este cenário de risco poderá ser facilmente identificado durante o planejamento do
cronograma do projeto e constitui uma ameaça de atraso para o mesmo caso o recurso alocado
não consiga termina-lo a tempo.
Um risco similar poderia ser identificado por meio da análise de cenários, por exemplo,
assumindo a possibilidade de o recurso alocado ter de se afastar por motivos médicos
perdendo uma semana de trabalho. Obviamente sua probabilidade e impacto seriam diferentes
e também suas tratativas. Além disso, é importante notar que os riscos não são excludentes e
podem ser trabalhados juntos, porém é preciso que os riscos advindos de cenários desenhados
pela equipe sejam baseados na melhor estimativa possível, de preferência com embasamento
histórico de dados. Ou seja, se o recurso em questão está há muitos anos na empresa e nunca
apresentou um atestado de mais do que um dia de trabalho seria um tanto quanto baixa a
probabilidade da ocorrência de um cenário como este. Neste caso melhor seria redefinir o
cenário ou criar cenários alternativos.
Quanto maior a importância de uma atividade, melhor será para seu planejamento que
os seus riscos sejam detalhados a fundo. Isto trará uma segurança maior para o planejamento
através do estabelecimento das reservas de contingência. Nesta metodologia propomos a
definição para cada risco da sua probabilidade de ocorrência e de seu impacto em custo e
cronograma para o projeto.
Para que se possa estabelecer o valor esperado dos riscos é preciso primeiro registrar os
riscos e suas características. Isto pode ser feito através do Registro de Riscos. O Apêndice
A11 traz um modelo que pode ser utilizado. Para cálculo da coluna do valor esperado do
risco, basta multiplicar a probabilidade de ocorrência pelo impacto estimado. No exemplo
demonstrado acima o cálculo do Valor Esperado (VE) seria:
VE = Probabilidade x Impacto
VE = 0,4 x 30 dias
VE = 12 dias

Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos

Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos

Similar a Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos (20)

Último

Último (20)

Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos