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

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 STAKEHOLDERS 84

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

FONTE: Adaptado de PMSurvey.org, 2011, 2012 e 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

FOCO

DO

PRO

JETO

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


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

59

Por ser uma ameaça ao prazo do projeto expressa em dias o valor esperado deverá realmente

ser positivo, uma vez que somar dias ao projeto é negativo. Em contrapartida, se analisarmos

a oportunidade do recurso terminar o trabalho com 5 dias de antecedência com uma

probabilidade de 60% - o inverso do risco de ameaça – teremos um Valor Esperado negativo

indicando uma economia de tempo:

VE = 0,6 x -5 dias

VE = -3 dias

No exemplo demonstrado acima, caso o projeto apresentasse apenas estes dois riscos, o

VE dos riscos do projeto seria de 9 dias de atraso.

É comum a identificação de riscos cuja probabilidade ou impacto seja difícil de estimar

por falta de expertise no assunto, nestes casos a equipe designada para o gerenciamento de

riscos do projeto deve se reunir e discutir sobre o assunto até o consenso, sempre se utilizando

de fatos e dados. Uma técnica de mediação que pode ser utilizada é a de se anotar todas as

opiniões do grupo de maneira visível e posteriormente solicitar aos membros da equipe que

justifiquem as suas opiniões gerando um debate. Uma opinião nunca poderá ser descartada até

que os demais membros do grupo se convençam da justificativa para tal.

Após termos chegado aos valores esperados dos riscos do projeto é importante também

calcular o pior e o melhor cenário possível. Considerando o exemplo acima isoladamente a

título de exemplo, ao assumirmos como verdade todas as ameaças chegaremos ao pior cenário

que é a execução da atividade em 45 dias. Isto ocorre pois ao se tornar realidade o risco deixa

de ter probabilidade de 40% e passa a 100%, logo o VE se torna 30 dias que somados à

duração da atividade de 15 dias é igual ao pior cenário. O melhor cenário é calculado da

mesma forma onde o adiantamento da atividade em cinco dias recebe probabilidade 100% e

transforma a duração da atividade em 10 dias. Representado graficamente temos:

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

Melhor Caso Estimativa Projeto Valor Esperado Pior Caso

Figura 25: Representação gráfica dos cenários de risco sem resposta FONTE: Elaborado pelo autor.

Esta representação é uma valiosa ferramenta para verificarmos a dimensão do impacto

dos riscos no projeto. Quanto mais próximo for o valor esperado do estimado pelo projeto

60

melhor será a condição de nosso planejamento. Esta aproximação do Valor Esperado é

conseguida através da resposta aos riscos que veremos a seguir.

3.4.13. Responder aos riscos – Pilar associado: Busca da Perfeição

O perfil de resposta aos riscos deve ser avaliado de acordo com as seguintes hipóteses:

Respostas a Ameaças

Respostas a Oportunidades

Evitar Provocar

Transferir Compartilhar

Mitigar Melhorar

Aceitar Ignorar

a. Evitar e Provocar: Estas estratégias de resposta ao risco elevam ao máximo

aquilo que desejamos da situação. No caso de ameaças se podemos evitar

significa que levaremos a sua probabilidade de ocorrência a zero. No caso de

oportunidades a probabilidade se torna 100%. Esta estratégia só pode ser

adotada para riscos sobre os quais é possível ter algum tipo de controle ou

influência.

b. Transferir ou Compartilhar: Estas estratégias consistem em se unir a um

parceiro comercial para melhorar o cenário da situação. Transferir o risco não irá

evitar a ameaça ou provocar a oportunidade, porém irá potencializar as

probabilidades ou impactos no sentido desejado. O prejuízo ou benefício tornado

verdadeira é compartilhado entre as partes.

c. Mitigar ou Melhorar: Estas estratégias são aquelas sobre as quais temos controle

e sabemos que por aplica-las podemos melhorar o cenário encontrado na análise.

Da mesma forma não evitam as ameaças ou provocam as oportunidades, porém

potencializam as probabilidades e/ou impactos por ações internamente

realizadas. Não há compartilhamento de ônus ou bônus.

d. Aceitar e Ignorar: São estratégias utilizadas normalmente para os ganhos ou

prejuízos pouco significativos ou ainda para aqueles riscos sobre os quais é

61

impossível tomar uma ação. Consistem em simplesmente monitorar a

probabilidade e o impacto sem tomar ação alguma.

Um risco pode ter uma ou mais respostas associadas a ele desde que as mesmas sejam

coerentes, ou seja, que o custo de resposta ou a duração do trabalho excedente a ser executado

para responder ao risco não excedam os seus respectivos valores esperados. Além disso,

podem ser definidas respostas de contenção ou de contingência sendo a primeira uma resposta

realizada antes da materialização do risco e a segunda após.

Revisando o exemplo utilizado na definição dos riscos podemos dizer que uma das

respostas possíveis à ameaça seria adiantar as férias do recurso de forma que o mesmo volte

antes do início das atividades. Esta resposta eliminaria a probabilidade de ocorrência do

atraso, portanto o novo valor esperado do risco é zero e o novo valor esperado da atividade

passa a ser de 12 dias, uma vez que eliminarmos o risco de atraso não elimina o risco de

terminarmos a atividade antecipadamente. Portanto, o novo diagrama seria o seguinte:

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

Valor EsperadoMelhor Caso Estimativa Projeto

Pior Caso

Figura 26: Representação gráfica dos cenários de risco pós-resposta

FONTE: Elaborado pelo autor.

Portanto, com uma resposta eficaz reduzimos a variabilidade da duração da atividade de

35 dias para apenas cinco dias agregando confiabilidade ao planejamento da atividade e

consequentemente ao projeto.

Para registro da resposta aos riscos será utilizado o Plano de Resposta aos Riscos cujo

modelo se encontra no apêndice A12.

3.4.14. Consolidar o Planejamento do Projeto – Pilar associado: Fluxo da Cadeia de

Valor do Projeto

Os documentos elaborados até aqui deverão passar minimamente por uma revisão a ser

realizada por um membro do Comitê de Gerenciamento de Projetos externo ao planejamento

do projeto para verificar a consistência dos dados. Posteriormente a essa avaliação deverá ser

realizada uma reunião com a equipe de planejamento que deverá esclarecer todas as dúvidas

62

e, caso necessário, deverá ser estipulado ali novo prazo para as correções necessárias. Ao final

das correções o trabalho deverá ser encaminhado ao Gerente Funcional para que o mesmo o

avalie e aprove.

Posteriormente à aprovação do Plano de Gerenciamento do Projeto deverá ser realizada

uma reunião com participação da equipe do projeto, dos atores do processo focal, gerente

funcional e solicitante do projeto – quando realizado a partir da ferramenta de geração de

ideias – para exposição do plano de projeto e dos objetivos do mesmo. Após a exposição do

plano deverá ser aberta oportunidade para que os participantes opinem e sugiram mudanças.

Se possível, esta reunião deve ocorrer no “Gemba”.

3.5. Grupo de Processos de Execução

Segundo o PMI (2013), o grupo de processos de execução é aquele destinado a concluir

o trabalho definido no planejamento e consequentemente atender às especificações do projeto.

Consiste também na identificação de mudanças necessárias nas linhas de base do projeto

(escopo, tempo e custo) para que o mesmo se torne mais eficaz, além de gerenciar os

stakeholders envolvidos buscando desenvolver parceiros e neutralizar influências negativas.

Neste grupo de processos da metodologia a equipe do projeto já formada estará bastante

presente no “Gemba” com foco em gerenciar as ações de Kaizen e Kaikaku definidas no

planejamento e manter a todos informados através de uma eficaz gestão visual destinada ao

processo sendo estudado e ainda outra destinada à própria equipe. A figura 27 mostra o

fluxograma do grupo de processos de execução.

63

Figura 27: Fluxograma do Grupo de Processos de Execução FONTE: Elaborado pelo Autor.

3.5.1. Integrar a Equipe ao Projeto – Pilar associado: Cadeia de Valor do Projeto

A partir da negociação e formação da equipe vista em 3.4.7 os integrantes definidos

para integrar a equipe deverão passar por um processo de integração ao projeto. Alguns

recursos podem ter sido utilizados durante o planejamento do mesmo e, por isso, já conhecem

os valores associados ao projeto e os seus objetivos, porém nem sempre isto acontecerá. Por

isso, é necessário que a equipe que se forma agora em definitivo para execução dos trabalhos

do projeto tenha total consciência do que se busca.

O primeiro passo para esta integração já foi dado em 3.4.14 com a realização da reunião

para exposição do Plano de Projeto. Agora, como segundo passo, caberá ao gerente de projeto

definir as responsabilidades de cada integrante da equipe pelo uso da Matriz RACI. Em

projetos de maior porte é recomendável que a matriz seja preenchida gradualmente, por

exemplo, por fases do projeto.

A Matriz RACI é uma ferramenta que atribui a cada membro da equipe uma

responsabilidade em cada atividade conforme abaixo:

a. R – Responsável: Pessoa designada para executar o trabalho.

b. A – Aprovador: Pessoa designada para revisar e aprovar o trabalho.

64

c. C – Consultor: Pessoa designada para fornecer informações relevantes para o

trabalho sem estar envolvida diretamente nele.

d. I – Informado: Pessoa que deve buscar se informar e ser informado do

andamento daquela atividade. Em linhas gerais todos os que não se enquadrarem

nos perfis citados acima serão marcados como “informados” na matriz.

Abaixo um exemplo de Matriz RACI:

Figura 28: Matriz RACI FONTE: PMI, 2013, p. 262

No início de cada fase, com a definição da Matriz RACI pronta, a equipe do projeto

deverá retornar ao “Gemba” buscando informações relevantes à suas atividades e, caso

possível, já executando-as.

3.5.2. Desenvolver e Atualizar a Gestão Visual para a Equipe – Pilar associado:

Fluxo da Cadeia de Valor

A Gestão Visual é um dos principais métodos utilizado pelo sistema Lean para

explicitar problemas e também para gerar soluções. Para projetos é uma forma de explicitar o

fluxo da cadeia de valor - aquilo que deve ser realizado para que se atinja o objetivo do

projeto; e também quão bem o fluxo está sendo seguido.

A Gestão Visual desenvolvida para a Equipe deverá estar localizada em local de fácil

acesso à equipe e contemplar as áreas de conhecimento de Escopo, Tempo, Custo, Qualidade

e Riscos. O quadro, ou outra forma definida, deverá ser atualizado de acordo com a

65

frequência definida pelo Gerente do Projeto. As informações mínimas a serem dispostas são

as seguintes:

a. Escopo: Objetivos SMART com seus indicadores atuais e metas e EAP do

Projeto

b. Tempo: Cronograma de Gantt do projeto com marcação de avanço das atividades

previsto e realizado

c. Custo: Valor geral do orçamento do projeto e valor consumido do orçamento

d. Qualidade: Índice de cumprimento dos requisitos da Folha de Verificação de

Qualidade (Conformes/Avaliados) e Índice de Aprovação do Trabalho

(Aprovados/Submetidos).

e. Riscos: Gráfico da variação do Valor Esperado dos Riscos no Tempo permitindo

ver inflexões causadas pela identificação de novos riscos e também a variação

por conta da materialização ou não de riscos existentes. A figura 29 mostra um

exemplo.

Figura 29: Gráfico do VE no Tempo

FONTE: Elaborado pelo Autor.

Deverão ser realizadas reuniões periódicas convocadas pelo Gerente do Projeto para

avaliação das atualizações da Gestão Visual pela equipe do projeto e análise crítica das

variações e causas. Todas as demais reuniões do projeto deverão, a medida do possível, ser

realizadas com o auxílio da gestão visual.

66

3.5.3. Desenvolver e Atualizar a Gestão Visual no “Gemba” – Pilar associado: Fluxo

da Cadeia de Valor

A gestão visual deverá ser praticada também no “Gemba” abordando os mesmos temas

de interesse utilizados para a equipe com algumas modificações na abordagem.

a. Escopo: Objetivos SMART com seus indicadores atuais e metas e EAP do

Projeto

b. Tempo: Cronograma de Marcos do projeto com indicações de Kaizens e

Kaikakus a serem realizados.

c. Custo: Valor total investido no “Gemba” onde está localizada a Gestão Visual.

Caso haja mais de um processo sendo estudado o valor deverá ser dividido de

forma que os atores do processo percebam o quanto está sendo investido no seu

local de trabalho.

d. Qualidade: Índice de cumprimento dos requisitos da Folha de Verificação de

Qualidade no processo em questão (Conformes/Avaliados).

e. Riscos: a área de Riscos poderá ser abordada através da disponibilização de uma

ferramenta de sugestões de melhoria no projeto. A partir destas sugestões a

equipe de riscos irá avaliar se o exposto é um risco ou uma necessidade de

mudança imediata formalizando uma solicitação de Kaizen de Projeto (3.5.7)

3.5.4. Orientar as Ações Kaizen / Kaikaku – Pilar associado: Fluxo da Cadeia de

Valor

Durante o planejamento das atividades do projeto a técnica da decomposição foi

utilizada para definir as atividades e pacotes de trabalho que gerarão pequenas mudanças no

processo existente (Kaizen) e também que gerarão novos processos (Kaikaku). Estes pacotes

de trabalho tiveram suas estimativas de tempo e custo feitas mais apuradamente e com isso

ganharam maior precisão de planejamento.

No momento da execução destas atividades não basta que se apliquem as melhorias

estudadas no planejamento, devem ser realizadas ações que padronizem o processo melhorado

ou criado e que ensinem aos responsáveis do processo focal a importância e o impacto

67

daquelas melhorias garantindo sua durabilidade. Para que isso aconteça as seguintes

premissas relacionadas ao ciclo PDCA devem ser respeitadas:

a. (P) Demonstrar a origem da melhoria antes de aplica-la: Durante o processo

de planejamento das atividades do projeto a equipe do processo focal foi

convidada a participar da geração de ideias e a ensinar à equipe de planejamento

sobre o processo. Demonstrar que esta é a origem das melhorias propostas

agrega confiança ao projeto e reúne aliados.

b. (D) Aplicar a melhoria a quatro mãos: A equipe do projeto nunca deve atuar

apenas como observadora do processo de mudança. A orientação deve ser feita

colocando em prática a melhoria juntamente com a equipe do processo focal.

c. (C) Gerar ferramentas de monitoramento de resultados: Todo processo

melhorado deve ser validado antes de sua padronização, para isso podem ser

aplicadas ferramentas como check-lists, cartas ou gráficos de controle,

fluxogramas, folhas de verificação ou ainda outras ferramentas adequadas para

monitoramento do processo após as melhorias. Caso seja possível utilizar

ferramentas semelhantes ou até mesmo iguais às utilizadas anteriormente para

controle isto é recomendado.

d. (A) Definir as correções necessárias: Em processos de melhoria é necessário

ouvir a voz de quem está à frente do processo e levar em consideração suas

dificuldades e sugestões. Este é um dos princípios da ida ao “Gemba” como

vimos acima: Demonstrar respeito aos atores do processo. Não se pode

considerar que o planejado é a verdade absoluta, porém também é preciso ter o

cuidado de identificar os stakeholders predominantemente construtivos e os

predominantemente bloqueadores corretamente para evitar que os bloqueios

venham disfarçados de correções.

e. (S) Padronizar o processo: Após termos rodado o ciclo PDCA completo deve ser

iniciado o ciclo SDCA, ou o ciclo de manutenção da qualidade do processo.

Deverão ser criados ou revisados os padrões operacionais e as instruções de

trabalho referente aos processos internos e gerados acordos de serviço ou

contratos para os processos externos. Desta forma é possível garantir a

manutenção das melhorias implementadas.

68

Todas as ações do projeto devem ser documentadas juntamente com seus resultados e

levadas às reuniões periódicas da equipe do projeto conforme definido em 3.5.2. Nestas

reuniões poderão ser alinhadas as solicitações de Kaizen de Projeto (3.5.7)

3.5.5. Conduzir as Aquisições – Pilar associado: Fluxo da Cadeia de Valor do Projeto

As aquisições do projeto devem seguir a política de compras da Organização e o mapa

de aquisições definido em 3.4.5. Deve-se ter o cuidado de designar a pessoa responsável por

iniciar o processo a tempo da execução das atividades de acordo com o cronograma. No caso

da aquisição de serviços deverá ser realizada uma Solicitação de Proposta Técnica Comercial

pela equipe do projeto e encaminhada ao fornecedor por parte do setor de compras. A mesma

deverá ser aprovada pela equipe do projeto antes do prosseguimento com a aquisição. Não

havendo formalmente um setor de compras definido a equipe do projeto deverá definir um

membro que ficará fixo a essa função.

3.5.6. Desenvolver Parceiros para o Projeto – Pilar associado: Cadeia de Valor do

Projeto

O desenvolvimento apropriado de parcerias com os Stakeholders do projeto está

bastante associado às formas de comunicação escolhidas pela equipe para se relacionar com

eles e à resposta esperada por parte deles. Os Stakeholders que foram priorizados em 3.4.2

deverão ter um mapa de comunicação montado para que os potenciais construtivos sejam

maximizados e os potenciais destrutivos neutralizados.

O mapa das comunicações deverá constar os Stakeholders por grupo ou individualmente

dependendo da necessidade do projeto; o evento do projeto que deverá gerar uma

comunicação; o meio de comunicação mais apropriado – que pode variar de um e-mail até a

comunicação pessoal por parte de um Stakeholder mais influente; o emissor da mensagem e a

ação esperada por parte do stakeholder.

Os eventos do projeto que deverão ser sempre considerados são:

a. Eventos de Escopo

Solicitação de Mudanças (Kaizen de Projeto)

69

Aprovação / Rejeição de Mudanças

b. Eventos de Cronograma

Início do Projeto / Fase

Atraso no Projeto / Fase

c. Eventos de Custo

Necessidade de recurso adicional para atividade

d. Eventos de Qualidade

Ocorrência de não conformidades do projeto

e. Eventos de Risco

Identificação de novos riscos

Riscos descartados

Riscos materializados

f. Monitoramento e Controle do Projeto

Reporte de Análise do Valor Agregado

g. Outros a critério do Gerente do Projeto

O modelo de mapa de comunicações pode ser encontrado no Apêndice A14.

3.5.7. Realizar Kaizen de Projeto – Pilar associado: Busca da Perfeição

O Kaizen de Projeto é a ferramenta para processar as solicitações de mudança do

projeto. É de responsabilidade da equipe do projeto, principalmente dos responsáveis

identificados na Matriz RACI o levantamento, solicitação e justificativa da mudança proposta.

Estes levantamentos podem ser realizados nas reuniões periódicas da equipe, ou ainda,

quando urgentes encaminhados ao Gerente do Projeto que deverá designar uma equipe de três

pessoas, incluindo o solicitante, para analisar as causas raiz do problema em no máximo dois

dias úteis e verificar se a mudança apresentada é a mais adequada ao projeto.

O processo para identificação das causas raiz do problema a ser seguido deverá ser o

mesmo descrito para o detalhamento do escopo do projeto em 3.4.3 utilizando o diagrama de

70

causa e efeito, os cinco porquês e o brainwriting. Neste caso, porém, para o diagrama de causa

e efeito podem ser utilizadas algumas ou todas as áreas do conhecimento (escopo, tempo,

custo, qualidade, integração, comunicações, aquisições, RH, stakeholders e riscos) ao invés

dos 6M, buscando relacionar possíveis causas do problema no planejamento de cada uma

delas.

Após a finalização do estudo a equipe deverá apresentar o seu parecer sobre a mudança

aprovando, reprovando ou sugerindo nova mudança. Este parecer deve chegar ao Gerente do

Projeto para aprovação em 24 horas e sendo aprovado deverá ser encaminhado ao Gerente

Funcional. Os quadros de gestão visual do projeto deverão ser atualizados com as mudanças

relevantes aos mesmos imediatamente após aprovação. A equipe deverá também atualizar

toda a documentação do projeto em prazo definido pelo Gerente do Projeto que não deverá

ultrapassar a finalização da fase em andamento.

3.6. Grupo de Processos de Monitoramento e Controle

O grupo de processos de Monitoramento e Controle visa garantir que o andamento da

execução das atividades do projeto está conforme acordado e identificar variações nos riscos e

engajamento dos stakeholders da Cadeia de Valor. Sua principal ferramenta será a Analise do

Valor Agregado.

Figura 30: Fluxograma do Grupo de Processos de Monitoramento e Controle


71

3.6.1. Realizar a Análise do Valor Agregado – Pilar associado: Valor do Projeto

A Análise do Valor Agregado é uma técnica de monitoramento do desenvolvimento do

projeto pelo cálculo de índices baseados na realidade financeira do projeto. Ao contrário do

que se pode imaginar a Análise do Valor Agregado não se atem apenas aos resultados

financeiros, mas permite também calcular índices de cronograma e através destes estabelecer

uma análise do desempenho do projeto. Para cálculo dos índices são utilizados os seguintes

conceitos:

a. Valor Planejado (VP): é o valor estimado de custo de uma determinada atividade

no planejamento do projeto.

b. Valor Agregado (VA): é o valor correspondente ao valor planejado do trabalho

concluído do projeto. Por exemplo, observe o detalhamento do projeto abaixo:

Fase Fase 1 Fase 2 Fase 3 Projeto

VP R$ 50 mil R$ 35 mil R$ 15 mil R$ 100 mil

Se analisarmos o Valor Agregado ao final da primeira fase, independentemente

do valor efetivamente gasto para sua conclusão, teremos VA = R$ 50 mil. Ao

final da fase dois VA = R$ 85 mil e ao final do projeto VA = R$ 100 mil. O

valor efetivamente dispensado será medido pelo Custo Real (CR). Vale dizer

que se mudarmos a abordagem de análise, deixando de analisar o final de uma

fase e passando a analisar uma data específica no tempo, por exemplo a data

planejada para o fim da fase, o Valor Agregado poderá não ser igual ao Valor

Planejado, portanto, o mais correto é realizar a Análise do Valor Agregado com

base em datas previstas para marcos ou atividades do projeto e não pela

conclusão do trabalho.


Conclusão Prevista 01/05 13/07 25/10 25/10


VA R$ 45 mil R$ 90 mil R$ 97 mil R$ 97 mil

c. Custo Real (CR): É o valor efetivamente gasto para conclusão do trabalho do

projeto. Pode ser maior, menor ou igual ao planejado. No exemplo acima o

Custo Real poderia ser o seguinte:

72





CR R$ 60 mil R$ 92 mil R$ 102 mil R$ 102 mil

Os três conceitos acima deverão ser primeiramente analisados em termos de duas

variações conforme abaixo:

a. Variação do Custo (VC): É a comparação entre o Valor Agregado e o Custo

Real. Em outras palavras, estamos comparando o planejamento do projeto ao

efetivamente realizado em termos de custo. Sua fórmula básica é VC = VA –

CR, portanto valores negativos indicam que o projeto está gastando mais do que

o planejado. Vejamos a aplicação no exemplo:





VC - R$ 15 mil - R$ 2 mil - R$ 5 mil - R$ 5 mil

Este projeto, portanto, gastou mais do que deveria durante sua primeira e terceira

fase, porém a economia feita na segunda fase não foi suficiente para regularizar

a situação e a sua Variação do Custo foi sempre negativa.

b. Variação do Cronograma (VCr): É a comparação do Valor Agregado ao Valor

Planejado para execução até a data específica. Sua fórmula básica é a seguinte

VCr = VA – VP. Se o Valor Agregado pelas atividades executadas for maior que

o Valor Planejado para aquele momento do tempo significa então que o

cronograma do Projeto está adiantado, caso for menor significa então que o

cronograma está atrasado.

73





VCr - R$ 5 mil R$ 5 mil - R$ 3 mil - R$ 3 mil

Após o entendimento das variações de custo e cronograma é possível calcular os índices

de desempenho:

a. Índice de Desempenho de Custo (IDC): Demonstra para cada real gasto com o

projeto quanto efetivamente se torna valor para o mesmo. Sua fórmula básica é

IDC = VA / CR.





IDC 0,75 0,98 0,95 0,95

b. Índice de Desempenho de Cronograma (IDCr): Demonstra a qual percentual

do cronograma planejado o projeto se encontra. Sua fórmula básica é a seguinte

IDCr = VA / VP.





IDCr 90% 106% 97% 97%

Até agora foi possível visualizar de forma bastante simples o desempenho do projeto e

suas variações percebidas. No entanto, para que sejam fornecidas informações para análise

gerencial a técnica de Análise do Valor Agregado ainda oferece mais algumas ferramentas

que permitem prever o desempenho final do projeto.

74

a. Estimativa de Custo no Término (ECT): é utilizada para prever com base nas

variações atuais do custo o quanto o projeto pode custar até o seu fim. Para que

se utilize essa ferramenta é preciso considerar algumas premissas que devem ser

explicitadas no relatório.

Se a variação atual é considerada coerente e a equipe prevê que ela deve

ocorrer até o final do projeto então: ECT = VPtotal / IDC

Se a variação atual indica ser advinda de condições atípicas e pode ser

desconsiderada para o futuro então: ECT = CR + VPtotal – VA

b. Estimativa para Terminar (EPT): é o valor necessário de agora em diante para

conclusão das atividades do projeto. Ou seja: EPT = ECT – CR

Com estas duas ferramentas em mãos o Gerente do Projeto juntamente com a Gerência

Funcional da área deverão avaliar a continuidade do projeto e se será necessário solicitar

mudanças (Kaizens) no planejamento do mesmo (3.5.7). Estas informações devem ser de

conhecimento da equipe de projeto e da gerencia funcional da área e o seu reporte deve estar

previsto no plano de comunicação do projeto.

3.6.2. Atualizar e Revisar Riscos – Pilar associado: Busca da Perfeição

A cada entrega concluída a equipe responsável pelo Gerenciamento de Riscos do

projeto deverá revisar o registro de riscos de forma a descartar as probabilidades dos riscos

que não se manifestaram; revisar as probabilidades dos riscos que podem vir a ocorrer, bem

como seus impactos; e acrescentar riscos que possam ter sido identificados durante a

execução do projeto, bem como suas respostas planejadas. Para isso o mesmo processo

descrito em 3.4.12 e 3.4.13 deve ser respeitado.

3.6.3. Atualizar e Revisar Mapeamento de Stakeholders – Pilar associado:

O andamento das atividades do projeto pode influenciar significativamente na

percepção do projeto por parte dos Stakeholders da Cadeia de Valor. Por esse motivo, sugere-

se revisitar o mapeamento de Stakeholders descrito em 3.4.2 no mínimo a cada entrega de

fase.

75

Naturalmente, a reclassificação de um Stakeholder de um grupo prioritariamente

bloqueador para um grupo prioritariamente construtivo, ou vice versa, poderá trazer mudanças

significativas ao planejamento das comunicações do projeto e também à facilidade de

obtenção de recursos para o mesmo, dependendo do grau de influência do Stakeholder. Por

esse motivo, neste ponto deveremos também revisar o Mapa de Comunicações do Projeto

descrito em 3.5.6. Lembrando sempre que uma comunicação eficaz com os Stakeholders pode

ajudar a transformar suas opiniões sobre o projeto. É bastante recomendável que se tenha na

equipe do projeto representantes das áreas de comunicação da empresa que possam auxiliar

no desenvolvimento da estratégia.

3.7. Grupo de Processos de Encerramento

3.7.1. Encerrar o Trabalho – Pilar associado: Valor do Projeto

O encerramento do trabalho da fase ou do projeto deve ser marcado pela validação do

Gerente Funcional às atividades executadas e o registro das lições aprendidas por parte da

equipe. Este encerramento deve ser conduzido em conjunto pelo Gerente do Projeto e Gerente

Funcional na mesma forma que foi dado o início ao projeto, por meio de uma reunião entre

toda a equipe do projeto e também os atores do processo focal. Após a apresentação pela

equipe do trabalho realizado e os resultados obtidos deverão ser apontadas as principais

mudanças ocorridas no projeto desde o seu início e, para cada uma delas, definida uma lição

aprendida a ser registrada em formulário próprio, referenciando o formulário de solicitação de

mudança e o projeto correspondente como forma de rastreamento. As lições aprendidas

deverão ser assinadas por toda a equipe do projeto e catalogadas por tipo de projeto e área do

conhecimento.

76

4. CONCLUSÕES

Este trabalho teve como objetivo desenvolver uma metodologia de gerenciamento de

projetos que permitisse aperfeiçoar o desempenho do Gerente de Projetos e de sua equipe

através da utilização dos conceitos do Lean Manufacturing e das ferramentas da qualidade por

ele amplamente utilizadas. A partir da relação entre os pilares do Lean Manufacturing e os

processos de gerenciamento de projetos foi possível perceber o alinhamento das ferramentas e

também sua grande eficácia em trabalhar juntos.

A Metodologia trabalha amplamente o conceito da presença no “Gemba” como forma

de verificar a realidade do processo e buscar soluções mais consistentes e alinhadas à

realidade. Além de verificar também a eficácia das ações do projeto e aproximar a equipe dos

atores do processo através da execução conjunta das atividades, da constante colaboração e da

transparência nas informações do projeto.

O conceito de Valor é provadamente relacionado através da Metodologia ao

desenvolvimento do Escopo do Projeto tendo como foco principal o cliente interno e externo

e buscando eliminar aquilo que é considerado “Muda” (desperdício) para os mesmos. Valor

também é relacionado ao respeito aos fornecedores e órgãos reguladores e suas premissas e

restrições existentes para o projeto buscando manter o equilíbrio do processo em todas as suas

dimensões. Com esta visão é possível entender os requisitos de produto e projeto com a visão

de toda a Cadeia de Valor do Processo buscando a formação do escopo mais completo

possível e o melhor investimento dos recursos financeiros disponíveis ao projeto.

O estudo do Valor associado à Cadeia de Valor do Processo também possibilita a

formação da Cadeia de Valor do Projeto e seu Fluxo. Estes conceitos permitem a identificação

dos Stakeholders prioritários levando em consideração o grau de influência no projeto e

também no processo, bem como identificar as melhores estratégias de “Make or Buy”

baseados no Core Business da empresa e na expertise da equipe e dos parceiros envolvidos no

projeto. O balanceamento das atividades, alocando os recursos corretos, no tempo correto para

garantir a melhor execução dos pacotes de trabalho e maximizar o Valor Agregado também é

beneficiado pelo entendimento destes temas.

A Busca da Perfeição é o conceito Lean que nos permite entender com maior amplitude

a qualidade e os riscos associados ao projeto, buscando o constante aprimoramento do projeto

através da realização de ações de mudança (Kaizen e Kaikaku) não apenas no processo, mas

77

também no próprio planejamento do projeto. Este conceito é bastante auxiliado pelo conceito

da Produção Puxada representado em todas as avaliações periódicas do processo e suas

respectivas aprovações para início, continuação ou término de suas atividades. Para que

possamos reduzir as “Mudas” no processo é preciso minimizar ao máximo as “Mudas”

também no projeto.

A aplicação do conceito da Gestão Visual no projeto com focos diferenciados para a

equipe e para os atores do processo focal ajuda a selecionar as informações da melhor maneira

possível e personalizar o entendimento do projeto o que ajuda a melhorar o alinhamento de

todos para atingimento dos objetivos.

A Metodologia proposta perpassa todos os grupos de processos e todas as áreas do

conhecimento de Gerenciamento de Projetos demonstrando assim a perfeita integração entre

as duas ferramentas e pensamentos. Apesar disso, a Metodologia é passível de melhorias uma

vez que foi desenvolvida, porém ainda não é completamente testada. Cabe às organizações

que optarem por sua utilização 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.

78

5. REFERÊNCIAS BIBLIOGRÁFICAS

AGUIAR, Silvio Integração das Ferramentas da Qualidade ao PDCA e ao Programa

Seis Sigma Belo Horizonte: Editora de Desenvolvimento Gerencial, 2002.

BARBOSA, Christina, et al. Gerenciamento de custos em projetos 4.ed. Rio de Janeiro:

Editora FGV, 2011.

BARCAUI, André B., et al. Gerenciamento do tempo em projetos 3.ed. Rio de Janeiro:

Editora FGV, 2010.

COGHI, Marco Gerenciamento da Integração Belo Horizonte: IBS Business School /

FGV, 2014. 57 f. Apostila.

JUNIOR, Isnard M., et al. Gestão da Qualidade 10.ed. Rio de Janeiro: Editora FGV,

2010.

LIKER, Jeffrey K., O Modelo Toyota Porto Alegre: Bookman, 2005.

Project Management Institute Um Guia do Conhecimento em Gerenciamento de

Projetos (Guia PMBOK®) 5.ed. Newton Square: PMI Publications, 2013.

RODRIGUES, Marcus V. Entendendo, Aprendendo e Desenvolvendo – Sistema de

Produção Lean Manufacturing Rio de Janeiro: Elsevier, 2014

SALLES JR, Carlos A. C., et al. Gerenciamento de riscos em projetos 2.ed. Rio de

Janeiro: Editora FGV, 2010.

SOTILLE, Mauro A., et al. Gerenciamento do escopo em projetos 2.ed. Rio de


XAVIER, Carlos M. S. , et al. Gerenciamento de aquisições em projetos 3.ed. Rio de


XAVIER, Carlos M. S., et al. Metodologia de Gerenciamento de Projetos

METHODWARE: Abordagem prática de como iniciar, planejar, executar, monitorar,

controlar e encerrar projetos. 3.ed. Rio de Janeiro: Brasport, 2014.

79

6. APÊNDICES

6.1. Apêndice A – Templates da Metodologia

6.1.1. A1. FORMULÁRIO DE SOLICITAÇÃO DE “GEMBA”

80

6.1.2. A2. MATRIZ DE PRIORIZAÇÃO DE SOLICITAÇÕES

81

6.1.3. A3. RELATÓRIO DO “GEMBA”

84

6.1.4. A4. DIAGRAMA SIPOC PARA IDENTIFICAÇÃO DE STAKEHOLDERS

85

6.1.5. A5. TERMO DE ABERTURA DO PROJETO

87

6.1.6. A6. MATRIZ DE REQUISITOS DO PROJETO

88

6.1.7. A7. MAPEAMENTO DE STAKEHOLDERS DO PROJETO

89

6.1.8. A8. MAPA DE AQUISIÇÕES

90

6.1.9. A9. FOLHA DE VERIFICAÇÃO DA QUALIDADE

91

6.1.10. A10. FOLHA DE APROVAÇÃO DO TRABALHO

92

6.1.11. A11. REGISTRO DE RISCOS

93

6.1.12. A12. PLANO DE RESPOSTA AOS RISCOS

94

6.1.13. A13. MAPA DE COMUNICAÇÕES

95

6.2. Apêndice B – Lista de Softwares Livres e Web-Based de Gerenciamento de

Projetos

1. Artia (Módulo gratuito até 3 usuários e 5 projetos)- http://artia.com/produto/

2. DotProject - http://www.dotproject.net/

3. GPWeb - http://gpweb.sistemagpweb.org/#app

4. OpenProj - http://sourceforge.net/projects/openproj/

5. Open Project – http://www.openproject.org

6. Otmma3 - http://www.otmma3.com.br/

7. Runrun it (Módulo gratuito até 5 usuários) - https://secure.runrun.it/pt-BR

8. Trello (Controle de atividades baseado no KanBan) - https://trello.com/

9. WBSTool (Construção da EAP) - http://www.wbstool.com/

10. Wrike (Módulo gratuito até 5 usuários) - https://www.wrike.com/pt_BR/

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

Education

Transcript of Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos...