BRUNO EDUARDO ALVES MORALEIDA GOMES
DESENVOLVIMENTO DE UMA METODOLOGIA LEAN PARA
GERENCIAMENTO DE PROJETOS DE MELHORIA DE ...
FUNDAÇÃO GETULIO VARGAS
PROGRAMA FGV MANAGEMENT
MBA EM GERENCIAMENTO DE PROJETOS
O Trabalho de Conclusão de Curso
Desenvol...
TERMO DE COMPROMISSO
O(s) aluno(s) Bruno Eduardo Alves Moraleida Gomes, abaixo assinado(s), do curso de MBA
em Gerenciamen...
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 cr...
ABSTRACT
The paper here presented has the objective of developing a project management methodology
through the crossing of...
AGRADECIMENTOS
Aos professores da Fundação Getúlio Vargas que certamente souberam abrir minha mente
para o verdadeiro e ef...
SUMÁRIO
1. INTRODUÇÃO........................................................................................................
3.4.2. Mapear os Stakeholders Prioritários – Pilar associado: Cadeia de Valor
do Projeto.....................................
3.5.5. Conduzir as Aquisições – Pilar associado: Fluxo da Cadeia de Valor do
Projeto.........................................
6.1.13. A13. MAPA DE COMUNICAÇÕES ........................................................... 94
6.2. APÊNDICE B – LISTA D...
LISTA DE FIGURAS E TABELAS
Figura 1 – Representação gráfica do Ciclo de Shewart PDCA. .......................................
13
1. INTRODUÇÃO
Este trabalho tem por objetivo desenvolver uma metodologia de gerenciamento de
projetos que permita otimi...
14
A cultura do Lean Manufacturing como segundo pilar para aplicação da metodologia
certamente auxiliará na qualidade das ...
15
2. FUNDAMENTAÇÃO TEÓRICA
2.1. Projetos, processos e sua relação com o ciclo PDCA
Uma metodologia de gerenciamento de pr...
16
Figura 1 – Representação gráfica do Ciclo de Shewart PDCA.
FONTE: AGUIAR, 2002, p. 23
A relação entre os grupos de proc...
17
Quando aplicado ao gerenciamento de projetos podemos dizer que para cada fase do
ciclo de vida deve-se executar um cicl...
18
2.2. Ciclos de Vida, Fases e Grupos de Processos
Devemos neste momento conceituar mais profundamente o tema dos ciclos ...
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 ...
20
passando a considerar algo mais do que a tripla restrição (Escopo, Tempo e Custo) e voltando
sua atenção para áreas de ...
21
comunidade de gerenciamento de projetos. Inicialmente uma inciativa brasileira e,
posteriormente, estendida ao âmbito m...
22
Figura 8 – Perfil de Projetos das Indústrias segundo PMSurvey.org 2011 a 2013
FONTE: Adaptado de PMSurvey.org, 2011, 20...
23
Figura 9 – Porcentagem das indústrias com PMOs de Engenharia e TI
FONTE: Adaptado de PMSurvey.org, 2011, 2012 e 2013
Fi...
24
2.4. Lean Manufacturing aplicado a projetos
O pensamento Lean, como é chamada a base teórica do Lean Manufacturing é o
...
25
A solução encontrada foi desenvolver um pensamento que aproveitava o que havia de
melhor no passado e introduzia inovaç...
26
completamente e satisfazer toda e qualquer necessidade do seu cliente. Uma espécie de
personalização em massa, onde o s...
27
FONTE: Elaborado pelo autor
Os projetos de melhoria de Processos Produtivos podem ser desempenhados em
diversos níveis ...
28
fase, e ganham forma definitiva a partir do Planejamento. Dificilmente a Cadeia de Valor de
um projeto irá mudar a part...
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 c...
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
co...
31
Figura 16 – Grupo de processos de gerenciamento de projetos e mapeamento das áreas de
conhecimento
FONTE: PMI, 2013, p....
32
3. METODOLOGIA PROPOSTA
3.1. Estrutura proposta para a apresentação da Metodologia
Para apresentação da metodologia ser...
33
3.2.2. Ferramenta de Captação de Ideias
Para o bom funcionamento da Metodologia proposta é essencial que esteja à dispo...
34
3.3. Grupo de Processos de Iniciação
A Iniciação de um projeto é marcada pelo desenvolvimento de um documento com as
in...
35
tendência negativa de indicadores do processo. Em qualquer das hipóteses, no entanto, uma
Solicitação de “Gemba” (Apênd...
36
solicitante e demais participantes convocações, por meio adequado de comunicação,
informando a data e horário previstos...
37
Stakeholders propõe-se representar em uma área externa do SIPOC de maneira próxima ao
ponto da Cadeia de Valor à qual s...
38
3.3.3. Elaborar o Termo de Abertura do Projeto – Pilar associado: Valor do Projeto
Taiichi Ohno, idealizador do sistema...
39
As aprovações dos projetos ou fases numa metodologia Lean são as definidoras da
Produção Puxada. Significam dizer que a...
40
terceiro ano consecutivo com citação por mais de 60% das empresas que responderam a
pesquisa do PMSurvey.org e a área d...
41
gerenciamento do seu engajamento. Outro ponto positivo é a priorização que pode ser feita
dos Requisitos baseado na rep...
42
figurarem em três das categorias acima simultaneamente serão considerados os Stakeholders
Prioritários e deverão ser ac...
43
3.4.3. Detalhar o Escopo a Partir das Causas Raiz – Pilar associado: Fluxo da Cadeia
de Valor do Projeto
O processo de ...
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 par...
45
cada um dos pacotes de trabalho definidos na declaração de escopo detalhada deverá ser
alocado de maneira lógica abaixo...
46
A construção gráfica da EAP é feita de maneira muito mais rápida quando realizada
por meios digitais e seu resultado po...
47
negociações conseguindo as corretas especificações, com as melhores condições comerciais e
no prazo correto. O Apêndice...
48
É muito comum em projetos de melhoria de processos, especialmente os de pequeno
porte, que se definam as atividades em ...
49
3.4.7. Negociar a Equipe do Projeto – Pilar associado: Cadeia de Valor do Projeto
Este processo poderá ocorrer simultan...
50
3.4.8. Estimar Recursos e Duração das Atividades – Pilar associado: Fluxo da Cadeia
de Valor do Projeto
Neste processo ...
51
O cálculo a ser realizado para estimativas de trabalho segue abaixo:
PERT (para atividades) = O + 4xMP + P
6
Desvio Pad...
52
Os planejamentos sem restrição de datas deverão ser realizados pelos mesmos cálculos à
exceção do tempo ideal que não é...
53
oferecem a possibilidade de se gerar versões do cronograma sendo a versão zero chamada de
Linha de Base do cronograma.
...
54
Posteriormente serão calculadas as datas possíveis de início e término da atividade com
base no sequenciamento do diagr...
55
3.4.10. Desenvolver o Orçamento do Projeto – Pilar associado: Valor do Projeto
Para desenvolvimento do Orçamento do Pro...
56
motivo, já deverão ter sido executados diversas vezes até aqui. Isto possibilita que a formação
da reserva de contingên...
57
Os Apêndices A9 e A10 apresentam modelos das Folhas de Verificação da Qualidade e Folha
de Aprovação do Trabalho respec...
58
vencimento para cinco dias antes da data de entrega prevista do trabalho. A princípio, não é
possível adiantar o início...
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Desenvolvimento de uma Metodologia Lean para Gerenciamento de Projetos de Melhoria de Processos Produtivos
Próximos SlideShares
Carregando em…5
×

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

1.233 visualizações

Publicada em

Trabalho de Conclusão de Curso para obtenção do Grau de Especialista em Gerenciamento de Projetos pela FGV.

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.233
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
44
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. Dedicatória Primeiramente a Deus e também a todos que amo. Porque se não houvesse amor de nada adiantaria.
  5. 5. 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
  6. 6. 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
  7. 7. AGRADECIMENTOS Aos professores da Fundação Getúlio Vargas que certamente souberam abrir minha mente para o verdadeiro e eficaz Gerenciamento de Projetos.
  8. 8. 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
  9. 9. 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 Cadeia de Valor do Projeto.............................................................................................. 44 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 Cadeia de Valor do Projeto.............................................................................................. 50 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 Cadeia de Valor do Projeto.............................................................................................. 61 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
  10. 10. 3.5.5. Conduzir as Aquisições – Pilar associado: Fluxo da Cadeia de Valor do Projeto................................................................................................................................ 68 3.5.6. Desenvolver Parceiros para o Projeto – Pilar associado: Cadeia de Valor do Projeto........................................................................................................................... 68 3.5.7. Realizar Kaizen de Projeto – Pilar associado: Busca da Perfeição......... 69 3.6. GRUPO DE PROCESSOS DE MONITORAMENTO E CONTROLE ............................... 70 3.6.1. Realizar a Análise do Valor Agregado – Pilar associado: Valor do Projeto ............................................................................................................................................ 71 3.6.2. Atualizar e Revisar Riscos – Pilar associado: Busca da Perfeição.......... 74 3.6.3. Atualizar e Revisar Mapeamento de Stakeholders – Pilar associado: .... 74 3.7. GRUPO DE PROCESSOS DE ENCERRAMENTO ...................................................... 75 3.7.1. Encerrar o Trabalho – Pilar associado: Valor do Projeto .......................... 75 4. CONCLUSÕES.................................................................................................... 76 5. REFERÊNCIAS BIBLIOGRÁFICAS ................................................................. 78 6. APÊNDICES......................................................................................................... 79 6.1. APÊNDICE A – TEMPLATES DA METODOLOGIA..................................................... 79 6.1.1. A1. FORMULÁRIO DE SOLICITAÇÃO DE “GEMBA”............................... 79 6.1.2. A2. MATRIZ DE PRIORIZAÇÃO DE SOLICITAÇÕES.............................. 80 6.1.3. A3. RELATÓRIO DO “GEMBA” ................................................................... 81 6.1.4. A4. DIAGRAMA SIPOC PARA IDENTIFICAÇÃO DE STAKEHOLDERS84 6.1.5. A5. TERMO DE ABERTURA DO PROJETO ............................................. 85 6.1.6. A6. MATRIZ DE REQUISITOS DO PROJETO.......................................... 87 6.1.7. A7. MAPEAMENTO DE STAKEHOLDERS DO PROJETO...................... 88 6.1.8. A8. MAPA DE AQUISIÇÕES ....................................................................... 89 6.1.9. A9. FOLHA DE VERIFICAÇÃO DA QUALIDADE...................................... 90 6.1.10. A10. FOLHA DE APROVAÇÃO DO TRABALHO .................................... 91 6.1.11. A11. REGISTRO DE RISCOS ................................................................... 92 6.1.12. A12. PLANO DE RESPOSTA AOS RISCOS........................................... 93
  11. 11. 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
  12. 12. 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. 13. 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. 14. 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. 15. 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. 16. 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. 17. 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. 18. 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. 19. 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. 20. 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. 21. 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. 22. 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. 23. 23 Figura 9 – Porcentagem das indústrias com PMOs de Engenharia e TI FONTE: Adaptado de PMSurvey.org, 2011, 2012 e 2013 Figura 10 – Percepção de desvios de Tempo, Qualidade e Satisfação vs. atingimento das metas. FONTE: Adaptado de PMSurvey.org, 2011, 2012 e 2013 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. 24. 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. 25. 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. 26. 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. 27. 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. 28. 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. 29. 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. 30. 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. 31. 31 Figura 16 – Grupo de processos de gerenciamento de projetos e mapeamento das áreas de conhecimento FONTE: PMI, 2013, p. 61.
  32. 32. 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. 33. 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. 34. 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. 35. 35 tendência negativa de indicadores do processo. Em qualquer das hipóteses, no entanto, uma Solicitação de “Gemba” (Apêndice A1) deve ser preenchida para formalizar o início do estudo de um projeto. Este documento deve ser padronizado, de fácil entendimento e preenchimento e conter informações que sejam suficientes para informar quanto ao alinhamento da ideia aos objetivos da empresa, sejam eles estratégicos, táticos ou operacionais. As respostas às solicitações enviadas deverão ser dadas de acordo com sua priorização que pode ser realizada através de uma matriz como demonstra a figura 17. Nesta matriz relacionam-se o foco do projeto, onde a qualidade do produto é o fator mais importante para atendimento ao valor do cliente, e o impacto do mesmo em um indicador de resultado onde, em consonância com o pensamento Lean, os indicadores de satisfação dos clientes são considerados os mais importantes. Ambos os fatores são medidos em uma escala de 1 a 4 e o resultado do quadrante é representado pela média simples arredondada. 1 2 3 4 FOCODOPROJETO INDICADOR DE RESULTADO 1 OPERACIONAL TÁTICO ESTRATÉGICO SATISFAÇÃO CLIENTES 1 2 2 3 3 2 2 3 3 2 3 3 4 4 4PRODUTO CUSTO EFICIÊNCIA PESSOAS 2 3 3 4 Figura 18: Matriz de Priorização de Solicitações FONTE: Elaborado pelo Autor. A partir da priorização sugere-se que sejam dados prazos para o atendimento das solicitações enviadas, por exemplo, para solicitações do tipo quatro – de maior importância – deverão ser atendidas dentro de 24 horas úteis; para solicitações do tipo um – de menor importância – deverão ser atendidas dentro de 30 dias. Estes prazos deverão ser definidos de acordo com a demanda e a realidade da organização. Poderão também ser definidos os participantes da visita. Ao final do processo de priorização, deverão ser remetidas ao
  36. 36. 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. 37. 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. 38. 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. 39. 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. 40. 40 terceiro ano consecutivo com citação por mais de 60% das empresas que responderam a pesquisa do PMSurvey.org e a área de riscos apresenta média de 50%, apesar de tendência de queda no indicador através dos anos. O Grupo de Processos de Planejamento da Metodologia proposta seguirá o seguinte fluxograma: Figura 20: Fluxograma do Grupo de Processos de Planejamento FONTE: Elaborado pelo Autor 3.4.1. Coletar os Requisitos de Valor – Pilar Associado: Valor do Projeto Para a coleta dos requisitos de Valor do Projeto será necessário novamente praticar a ida ao “lugar onde as coisas acontecem”, o “Gemba”. Dessa vez, porém, a abordagem utilizada poderá ser menos formal, sem dependências de documentos ou solicitações. A idéia é que uma vez o projeto aprovado, por seu tempo determinado, o Gerente do Projeto – e posteriormente sua equipe - deverá vivenciar o local onde as coisas acontecem em toda a Cadeia de Valor. Fazer reuniões e visitas a fornecedores, entrevistar ou simplesmente acompanhar o trabalho dos atores do processo focal são exemplos da rotina de contato com o “Gemba” que devem ser aproveitada para realizar a coleta dos Requisitos de Valor do Projeto. O Gerente do Projeto deverá identificar e mapear os Requisitos de Valor do Projeto sempre fazendo referência individual ao Stakeholder que o levantou, mesmo que isso signifique algumas repetições na Matriz. Esta interligação entre o requisito e o Stakeholder ajudará posteriormente a definir o grau de interesse dos Stakeholders no Projeto facilitando o
  41. 41. 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. 42. 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. 43. 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. 44. 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. 45. 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. 46. 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. 47. 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. 48. 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. 49. 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. 50. 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. 51. 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. 52. 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. 53. 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. 54. 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. 55. 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. 56. 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. 57. 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. 58. 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

×