UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

ESCOLA DE ENGENHARIA
PROGRAMA DE PS-GRADUAO EM ENGENHARIA DE PRODUO

IMPLANTAO DE UM NOVO MTODO DE GERENCIAMENTO DE

PROJETOS EM UMA EMPRESA DE COMPONENTES ELETRNICOS

Fabiano Alberto Buzzetto

Porto Alegre, 2008

 Fabiano Alberto Buzzetto

IMPLANTAO DE UMA NOVA SISTEMTICA DE GERENCIAMENTO DE

PROJETOS EM UMA EMPRESA DE COMPONENTES ELETRNICOS

Dissertao submetida ao Programa de Ps-

Graduao em Engenharia de Produo da
Universidade Federal do Rio Grande do Sul
como requisito parcial obteno do ttulo
de Mestre em Engenharia de Produo,
modalidade Profissional, na rea de
concentrao em Sistemas de Produo.

Orientador: Prof. Flavio Sanson Fogliatto,

Ph.D.

Porto Alegre, 2008

 IMPLANTAO DE UMA NOVA SISTEMTICA DE GERENCIAMENTO DE
PROJETOS EM UMA EMPRESA DE COMPONENTES ELETRNICOS

Esta dissertao foi julgada adequada para a obteno do ttulo de Mestre em

Engenharia de Produo na modalidade Profissional e aprovada em sua forma final pelo
Orientador e pela Banca Examinadora designada pelo Programa de Ps-Graduao em
Engenharia de Produo da Universidade Federal do Rio Grande do Sul.

_______________________________________
Prof. Flavio Sanson Fogliatto, Ph.D.
Orientador PPGEP/UFRGS

____________________________________
Prof. Flavio Sanson Fogliatto, Ph.D.
Coordenador do Programa PPGEP/UFRGS

BANCA EXAMINADORA

Profa. Istefani de Paula, Dra. (PPGEP/UFRGS)

Profa. Marcia Echeveste, Dra. (PPGEP/UFRGS)
Prof. Maurcio Bernardes, Dr. (PGDESIGN/UFRGS)
Vencer a si prprio a maior de todas as vitrias
Plato, importante filsofo grego da antiguidade.
 AGRADECIMENTOS

Gostaria de primeiramente agradecer a Deus por mais esta oportunidade e conquista, e em

especial quero dedicar este trabalho a minha esposa Daniela pela compreenso,
companheirismo e apoio dado durante esta jornada que compreendeu desde as horas de
estudo, a leitura e montagem desta dissertao.

Quero agradecer aos meus pais, Joo Alberto e Iara, pelo o apoio incondicional a todo o
momento, pela educao e incentivo aos estudos que de alguma forma possibilitaram a
construir este trabalho.

Aos meus colegas e grandes amigos construdos no curso de Especializao e Mestrado

dentro PPGEP, e um dos meus melhores amigos, o meu irmo que sempre me ajudou e
incentivou a todas as conquistas, sendo tambm um grande companheiro e conselheiro.

Universidade Federal do Rio Grande do Sul que j me acolhe desde o incio da graduao
em 1995 e tenho maior prazer de fazer parte de sua histria, e em especial a Engenharia de
Produo e ao Programa de Ps-Graduo em Engenharia de Produo - PPGEP, pela
oportunidade e pelo ensino de qualidade que proporcionou durante o perodo de ensino e
pesquisa. Ao meu orientador, professor Flavio Fogliatto pela sua enorme dedicao, ajuda e
incentivo durante o perodo de preparao e montagem deste trabalho.

No poderia de esquecer de agradecer a empresa EDB Ltda, que de uma forma geral me
ajudou e incentivou a buscar o enriquecimento do meu conhecimento, e tambm por me
proporcionar e acreditar na aplicao do conhecimento adquirido.
 6

RESUMO

A busca da competncia em gerenciamento de projetos para o processo de desenvolvimento

de produto tem forte influncia na questo competitiva para as empresas, principalmente pela
agilidade e satisfao do cliente. Este trabalho apresenta na forma de um estudo de caso, o
mtodo e a sistemtica encontrada na empresa de componentes eletrnicos que atende
principalmente o mercado automotivo, a implantao de um sistema de gerenciamento de
projeto utilizando a base de conhecimento do PMI (Project Management Institute) voltado
para o processo de desenvolvimento, em especial o de produto. A principal contribuio deste
trabalho a criao de uma metodologia de gerenciamento de projetos, procedimentos
padres de desenvolvimento que seguem o padro do mercado automotivo - APQP atravs da
criao de projetos modelos (templates) utilizando uma ferramenta de suporte (software) para
o gerenciamento dos projetos, alm de implementar indicadores de desempenho avaliando o
tempo e custo.

Palavras-chave: Gerenciamento de Projetos; Desenvolvimento de Produto, PMI, APQP.

 7

ABSTRACT

The competence survey in projects management for product development process has a strong
influence in the competitive issue to the companies, mainly for agility and customer
satisfaction. This work shows in form of a case study the method and systematic found in an
Electronics Components Company that meets mostly the demand of the automotive market,
the implantation of a project management system using the PMI (Project Management
Institute) knowledge base in special to the product development. The main contribution in this
work is a project management methodology creation, development standard procedures that
follow the automotive market standard APQP through the creation of templates projects
using a support tool (software), as well as implementation of performance indicators in order
to evaluate the time and cost.

Key words: Project Management; Product Development, PMI, APQP.

 8

LISTA DE FIGURAS

Figura 1: Processos de gerenciamento do projeto .............................................................. p. 23

Figura 2: O ambiente do projeto ......................................................................................... p. 25

Figura 3: A meta de um projeto .......................................................................................... p. 27

Figura 4: Resumo dos fatores crticos de sucesso .............................................................. p. 29

Figura 5: Comparativo entre projetos e programas .......................................................... p. 30

Figura 6: Processo gerencial para criao do gerenciamento de portflio ........................ p. 32

Figura 7: Seleo de portflio de projetos ......................................................................... p. 33

Figura 8: Exemplo genrico do ciclo de vida de projeto ................................................... p. 39

Figura 9: Comportamento comum dos projetos ao longo de seus ciclos de vida ............. p. 39

Figura 10: Exemplos de ciclos de vida de projeto com trs e quatro fases ........................ p. 40

Figura 11: Tarefas de projeto ao longo do ciclo de vida genrico ..................................... p. 41

Figura 12: Evoluo dos principais modelos de aplicao, maturidade e excelncia de projeto
............................................................................................................................................. p. 43

Figura 13: Gesto de Projetos conforme PMI ................................................................... p. 44

Figura 14: Estrutura do modelo Project Excellence Model (PME) .................................... p. 45

Figura 15: Comparao entre os modelos de GP ............................................................... p. 46

Figura 16: Critrios para auxiliar na escolha do melhor mtodo de gesto de projetos .....p. 46

Figura 17: Mapeamento dos grupos de processos de GP e o ciclo PDCA ......................... p. 48

Figura 18: Processos de Gerenciamento de projetos .......................................................... p. 48

Figura 19: Relacionamento entre os ciclos de vida do projeto, do gerenciamento de projeto e

as reas do conhecimento ................................................................................................... p. 49

Figura 20: Mapeamento dos processos, reas do conhecimento e atividades do gerenciamento

de projetos conforme PMI .................................................................................................. p. 50

Figura 21: Relao entre reas de conhecimento e processos do gerenciamento de

projetos................................................................................................................................ p. 51

Figura 22: Processos de Gerenciamento da Integrao ...................................................... p. 53

 9

Figura 23: Contedo bsico de um plano de projeto.......................................................... p. 54

Figura 24: Tcnicas para estimativas de custos ................................................................. p. 59

Figura 25: Organograma simplificado da unidade analisada ............................................. p. 68

Figura 26: Macro fluxo dos processos da Empresa Analisada .......................................... p. 69

Figura 27: Matriz de correlao entre reas, indicadores e processos ............................ p. 70

Figura 28: Viso do processo de projeto e desenvolvimento segundo o mtodo SIPOC . p. 71

Figura 29: Processo de Iniciao ........................................................................................ p. 74

Figura 30: Processo de Planejamento.................................................................................. p. 75

Figura 31: Processo de Execuo ............ .......................................................................... p. 76

Figura 32: Processo de Monitoramento e Controle ............................................................ p. 77

Figura 33: Processo de Encerramento............................................................................... p. 78

Figura 34: Fluxograma do processo de desenvolvimento de produto ................................ p. 84

Figura 35: Indicadores de desempenho do processo de desenvolvimento...................... p. 91

Figura 36: Influncia das estruturas organizacionais nos projetos .....................................p. 106

Figura 37: Tabela de clculo dos indicadores de desempenho do projeto .........................p. 108

Figura 38: Grfico representativo do desempenho do projeto .......................................... p. 109

 10

LISTA DE TABELAS

Tabela 1: Defasagem comparativa no tempo de concluso para os projetos Tipo I ........ p. 89

Tabela 2: Defasagem comparativa no tempo de concluso para os projetos Tipo II........ p. 89

Tabela 3: Avaliao dos projetos relativa ao Processo de Iniciao ................................ p. 92

Tabela 4: Avaliao dos projetos relativa ao Processo de Planejamento ........................ p. 93

Tabela 5: Avaliao dos projetos dentro da nova sistemtica de gerenciamento ............. p. 103

Tabela 6: Avaliao comparativa dos projetos antes e depois da interveno ................. p. 103
 11

SUMRIO

1 INTRODUO......................................................................................................... p. 13
1.1 COMENTRIOS INICIAS......................................................................................... p. 13
1.2 TEMAS E OBJETIVOS ............................................................................................. p. 14
1.3 JUSTIFICATIVA DO TEMA ..................................................................................... p. 15
1.4 MTODO DO TRABALHO ...................................................................................... p. 16
1.5 LIMITAES ............................................................................................................. p. 17
1.6 ESTRUTURA .............................................................................................................. p. 18

2 REFERENCIAL TERICO ................................................................................... p. 19

2.1 CONSIDERAES INICIAIS ................................................................................... p. 19
2.2 DEFINIES DO PROJETO ..................................................................................... p. 19
2.3 O GERENCIAMENTO DE PROJETOS .................................................................... p. 21
2.3.1 Definio .................................................................................................................. p. 21
2.3.2 Histrico ................................................................................................................... p. 23
2.3.3 Partes interessadas e o ambiente de projeto ............................................................. p. 24
2.3.4 Metas do projeto ....................................................................................................... p. 27
2.3.5 Fatores crticos de sucesso ........................................................................................ p. 28
2.4 CONTEXTO SOBRE GERENCIAMENTO DE PROJETOS .................................... p. 29
2.4.1 Gerenciamento de Programas e Gerenciamento de Portflio ................................... p. 30
2.4.2 Escritrio de projetos ................................................................................................ p. 35
2.5 CICLO DE VIDA DE PROJETOS .............................................................................. p. 37
2.6 MTODOS DE GERENCIAMENTO DE PROJETO ................................................ p. 42
2.7 METODOLOGIA PMI PARA GERENCIAMENTO DE PROJETOS ...................... p. 46
2.8 PRINCIPAIS REAS DO CONHECIMENTO .......................................................... p. 51
2.8.1 Gerenciamento da Integrao .................................................................................... p. 52
2.8.2 Gerenciamento do Escopo ........................................................................................ p. 55
2.8.3 Gerenciamento do Tempo ......................................................................................... p. 57
2.8.4 Gerenciamento do Custo ........................................................................................... p. 58
2.8.5 Gerenciamento da Qualidade..................................................................................... p. 60
2.8.6 Gerenciamento dos Recursos Humanos..................................................................... p. 61
2.8.7 Gerenciamento das Comunicaes............................................................................. p. 62
2.8.8 Gerenciamento dos Riscos ........................................................................................ p. 63
2.8.9 Gerenciamento das Aquisies...................................................................................p. 65

3 MODELO PROPOSTO .......................................................................................... p. 67

3.1 CONSIDERAES INICIAIS ................................................................................... p. 67
3.2 APRESENTAO DA EMPRESA............................................................................ p. 67
3.3 FATORES MOTIVADORES DO PROJETO.............................................................. p. 71
3.4 DESENVOLVIMENTO DA PESQUISA ................................................................... p. 72
3.4.1 Fase exploratria ....................................................................................................... p. 73
3.4.2 Fase principal ............................................................................................................ p. 74
 12

3.4.3 Fase ao ................................................................................................................... p. 78

3.4.4 Fase avaliao ........................................................................................................... p. 80

4 MODELAGEM DA NOVA SISTEMTICA DE DESENVOLVIMENTO DE

PRODUTO ..................................................................................................................... p. 82
4.1 ESTRUTURA DO PROCESSO ATUAL.................................................................... p. 82
4.2 DESENVOLVIMENTO DA PESQUISA.................................................................... p. 83
4.2.1 Fase exploratria ....................................................................................................... p. 83
4.2.1.1 Apresentao do processo atual de desenvolvimento de produto .......................... p. 86
4.2.1.2 Modelo do processo de desenvolvimento .............................................................. p. 86
4.2.1.3 Avaliao sobre o processo de desenvolvimento ................................................. p. 88
4.2.1.4 Indicadores de desempenho do processo de desenvolvimento .............................. p. 90
4.2.2 Fase principal ............................................................................................................ p. 91
4.2.3 Fase ao ................................................................................................................... p. 95
4.2.4 Fase avaliao ......................................................................................................... p. 102
4.2.4.1 Avaliao das aes corretivas ............................................................................. p. 104
4.2.4.2 Novo mtodo e indicadores de avaliao dos projetos ........................................ p. 106
4.3 CONCLUSES E LIES APRENDIDAS ............................................................. p. 109

5 CONCLUSES E CONSIDERAES FINAIS ............................................ p. 112

5.1 RECOMENDAES PARA TRABALHOS FUTUROS ......................................... p. 114

APNDICE A Minuta de Projeto ................................................................................. p. 121

APNDICE B - Estrutura Analtica do Processo de Desenvolvimento de Produto ......... p. 122
APNDICE C - Estrutura Analtica do Processo de Desenvolvimento de Processo ........p. 123
APNDICE D - Estrutura Analtica do Processo de Desenvolvimento de Matria-Prima p.124
APNDICE E Cronograma Final do Projeto ..................................................................p. 125

ANEXO A - Procedimento do PQD (Planejamento da Qualidade de Desenvolvimento) p. 126

ANEXO B - Mdulo sobre Desenvolvimento de Fornecedores........................................p. 140
ANEXO C Relatrios Semanais ....................................................................................p. 156
 13

1 INTRODUO

1.1 COMENTRIOS INICIAIS

A competitividade do sistema produtivo brasileiro foi se modificando nos ltimos

anos pela abertura do mercado, e somando-se o avano da tecnologia digital, criou-se um
agressivo mercado globalizado que afeta todas as entidades nele inseridas. Perante esta
acirrada concorrncia, a questo da qualidade, agilidade e inovao tornaram-se importante
dentro do processo de desenvolvimento de produto a qual a empresa analisada est inserida.

No sculo XX, a necessidade de se gerenciar empreendimentos de forma eficiente

foi tornando cada vez maior, impulsionando com isto o desenvolvimento de tcnicas formais
de gesto de projetos conforme Kirst (2004). Na dcada de sessenta, a gesto de projetos foi
reconhecida como cincia, e o assunto passou a ser ensinado e pesquisado por universidades.
A demanda crescente por produtos de melhor qualidade, cada vez mais diferenciados,
despertou o interesse das organizaes pelo tema (PRADO, 1998). Desde ento, o
crescimento na concorrncia e os constantes desafios advindos das mudanas na organizao
da economia mundial tm levado as empresas de praticamente todos os ramos industriais a
buscarem meios de tornarem-se mais eficientes, como forma de manter sua competitividade.

O conjunto de conhecimentos em gerenciamento de projetos a soma dos

conhecimentos intrnsecos profisso de gerenciamento de projetos (PMBOK, 2004). Diante
desta premissa, o instituto americano de gerenciamento de projetos (PMI), lanou o livro com
o objetivo de divulgar o conhecimento e as melhores prticas aplicveis maioria dos
projetos, buscando atender a tudo aquilo que foi definido e planejado. Desta forma, o
PMBOK (Project Management Body of Knowledge ou Corpo de Conhecimento em
Gerenciamento de Projetos) tornou-se atualmente nas empresas um handbook (livro de mo)
para a montagem, execuo e controle dos projetos.

Baseado na metodologia para gerenciamento de projetos, e na necessidade das

empresas em criarem projetos como forma de manterem-se no mercado, como por exemplo,
os projetos de desenvolvimento de novos produtos, as entidades comearam a se planejar e
criar os projetos de forma sustentada por um mtodo de gerenciamento (PRIKLADNICKY,
2003). A aderncia ao mtodo significa que durante o ciclo de vida do projeto, algumas ou
 14

quase todas s reas do conhecimento comeam a fazer parte, e por conseqncia o sucesso
no empreendimento torna-se mais tangvel.

Especificamente no ramo de componentes eletrnicos, alm dos fatores

competitivos, a busca de novas tecnologias e inovaes para atender o mercado, torna-se vital
para uma empresa criar uma estrutura voltada ao gerenciamento de projetos. Sendo assim, os
aspectos relacionados gesto passaram a ser crticos para estas empresas que buscam
agilidade, flexibilidade e satisfao do cliente.

1.2 TEMA E OBJETIVOS

O tema deste trabalho a reestruturao do processo de desenvolvimento de

produto, processo propriamente dito e materiais atravs da implantao de um novo sistema
de gerenciamento de projetos em uma empresa de componentes eletrnicos que fabrica para
empresas que atendem ao mercado em geral e especialmente o mercado automotivo. O
processo de desenvolvimento um dos processos chave e crtico dentro da empresa, j que
esta identifica inovaes e rapidez nos desenvolvimentos como diferenciais competitivos para
atender a um mercado cada vez mais agressivo e nele se manter.

O objetivo principal deste trabalho remodelar a sistemtica de desenvolvimento

de produto, processo e matria-prima, visando reduzir o tempo de desenvolvimento e levantar
seus custos reais, atravs de um software de gerenciamento de projetos que utiliza a base de
conhecimento desenvolvida pelo PMI (Project Management Institute ou Instituto de Gesto
de Projetos).

Os objetivos especficos deste trabalho esto assim definidos:

realizar uma pesquisa bibliogrfica sobre os principais modelos de gerenciamentos

de projetos que podero ser aderentes ao processo de desenvolvimento de produto,
bem como, focar na metodologia escolhida para o gerenciamento dos projetos e
suas reas de conhecimento;

realizar um levantamento da situao atual do processo de desenvolvimento na

empresa analisada, identificando como feito o seu gerenciamento e o status atual
de seus indicadores de desempenho;
 15

criar modelos (templates) de projetos para desenvolvimento de produtos, processos

e matrias-primas utilizando recursos computacionais (software) para o
gerenciamento de projetos;

monitorar o processo de desenvolvimento de produto antes e depois da interveno

atravs de indicadores de desempenho que avaliem tempo e custo para cada
projeto;

aprimorar o processo de Desenvolvimento de Produto atravs dos registros de

lies aprendidas de forma a criar uma sistemtica, frum, para reavaliar os
registros e melhorar o procedimento sempre que necessrio, conforme requisitos
da ISO/TS 16949 no que se refere melhoria continua e tambm definido pelo
ciclo do PDCA (Plan, Do, Control, Action ou Planejar, Fazer, Controlar e Agir) e
apresentado novamente por Castro (2007).

1.3 JUSTIFICATIVA DO TEMA

O processo voltado ao desenvolvimento de produto faz parte da estratgia da

empresa em questo, pois atravs deste processo que possvel atender a necessidade do
cliente em termos das suas expectativas s caractersticas e funcionalidades do produto. Alm
disso, esse o processo que permite conquistar o mercado atravs de inovaes, agilidade e
flexibilidade.

A empresa analisada, a EdB, certificada pela norma ISO/TS 16949 a qual foi
criada para as empresas que atendem ao mercado automotivo. No ramo de atividade em que a
empresa est enquadrada, a de manufatura de componentes eletrnicos, o desenvolvimento de
produto basicamente voltado necessidade especfica dos clientes, ou seja, os projetos so
nicos, com prazos para recebimento das peas definidos pelo cliente, alm de que a empresa
analisada tomadora de preos. No ramo de atuao especfico desta empresa, o
desenvolvimento e construo de componentes eletrnicos com relao concorrncia pelo
mercado tornaram-se fortemente competitiva e inovadora a partir da abertura do mercado.

O mercado a qual a empresa analisada est inserida se divide, de forma ampla, em

dois tipos: os tipos commodity e os tipos especiais. Nos tipos commodity, tem-se uma forte
concorrncia com empresas chinesas e a nfase est no preo; j para os produtos especiais,
em particular no mercado automotivo, a concorrncia direta com as empresas japonesas que
possuem alto nvel de automao e tecnologia.
 16

Tendo em vista o cenrio em que a EdB est inserida, justifica-se o objetivo de

criar um modelo para os projetos envolvendo desenvolvimento de produto, processo, matria-
prima e/ou fornecedor que atendam as normas, que seja possvel fazer um melhor
gerenciamento deste processo, buscando reduzir o tempo de desenvolvimento, gerenciar
custos e identificar projetos alinhados estratgia da empresa, sempre almejando aumentar a
satisfao do cliente num curto espao de tempo.

1.4 MTODO DE TRABALHO

O mtodo de pesquisa que ser utilizada neste trabalho ser a pesquisa

aplicada, ou seja, voltada soluo de problemas especficos. Com relao ao procedimento a
ser adotado, o projeto utilizar a pesquisa-ao, na qual o pesquisador e membros de uma
equipe faro parte de um projeto para a soluo dos problemas.
Na primeira fase deste projeto, a fase exploratria, far-se- um diagnstico da
realidade a ser pesquisada. O objetivo desta fase aumentar o conhecimento a respeito de um
fenmeno sem comprovar hipteses (THIOLLENT, 2002). Faz-se um levantamento das
informaes, procurando investigar os problemas vivenciados, as expectativas e
caractersticas do grupo, assim como o seu mtodo de trabalho. A partir da, so traados os
objetivos da pesquisa, o planejamento das aes e como se dar a interao entre o
pesquisador e as pessoas envolvidas.

Na segunda etapa, fase de principal tem como objetivo analisar o desempenho

do processo a ser pesquisado (THIOLLENT, 2002). Aplicando a pesquisa-ao na anlise dos
processos de gerenciamento de projeto, como proposto aqui, devero ser analisados os
processo de iniciao, planejamento, execuo, controle, e encerramento.

Na terceira etapa, fase de ao tem como objetivo definir os objetivos prticos

alcanveis por meio de aes concretas, visando materializar as mudanas na organizao
(THIOLLENT, 2002). Na pesquisa aqui proposta, as aes devero ser direcionadas aos
procedimentos que gerenciam os processos dos projetos.

Na ltima etapa, fase de avaliao tem como objetivo apresentar e avaliar os

resultados obtidos aps a interveno realizada no processo. Para se fazer uma avaliao da
interveno necessria criar indicadores de desempenho que, de alguma forma, permitam
comparar os resultados anteriores e posteriores da pesquisa sobre a atuao no processo
explorado. Nesta ltima fase ser avaliada os resultados da implantao da nova sistemtica,
 17

avaliando principalmente a performance dos projetos em termos do tempo entre planejado e

realizado, comparando o antes e o depois da interveno.

1.5 LIMITAES

Importante salientar que este trabalho desenvolve-se em uma empresa de

componentes eletrnicos que possuem caractersticas prprias. A adaptao do sistema de
gerenciamento de projetos voltada ao processo de desenvolvimento de produto pode ser
praticada por outras instituies, porm, sero necessrias adaptaes devido sua cultura e o
tipo de aplicao particular a empresa analisada.
Com relao ao tipo de aplicao deste projeto, sero consideradas as reas ou
bases do conhecimento para um gerenciamento de projetos em uma empresa de grande porte.
Esta empresa voltada a projetos e fabricao de componentes eletrnicos, cujas
caractersticas dos seus desenvolvimentos so baseadas numa especificao de cliente, na
maioria dos casos, ou de novas sries de produtos buscando ultrapassar o concorrente na tica
da inovao.
As reas do conhecimento dentro da base de conhecimento do PMI que se dar
mais nfase sero os de: (i) gerenciamento do escopo; (ii) gerenciamento do tempo; (iii)
gerenciamento do custo; (iv) gerenciamento dos recursos humanos; (v) gerenciamento da
qualidade; e (vi) gerenciamento da comunicao.
Referente reviso bibliogrfica, limitar-se- sobre o processo de
desenvolvimento de produto, ao ciclo de vida dos projetos, as normas internacionais a qual a
empresa certificada, a metodologia escolhida e sua abordagem sobre gerenciamento de
projetos, apresentando as nove reas do conhecimento abordado por esta base de
conhecimentos.
Com relao ao gerenciamento da qualidade, somente sero apresentadas as
premissas para o atendimento a norma ISO/TS 16949, porm esta abordagem se limitar a no
apresentar todas as ferramentas, tcnicas necessrias para ser reconhecido como um projeto
que atende a norma especfica.
Sobre a pesquisa-ao aplicada, o trabalho est delimitado implantao dos
conceitos da reviso bibliogrfica para a criao de uma nova sistemtica de desenvolvimento
de produto, utilizando a metodologia de gerenciamento de projetos somente para a rea de
pesquisa e desenvolvimento dentro da empresa analisada.
 18

A empresa analisada utilizar um software para gerenciamento de projetos, a

partir da qual se mostrar como foi organizada a nova sistemtica a partir deste, pelo fato de
que ele aderente metodologia escolhida. Porm, o trabalho se limitar a no analisar o
software em questo, ou seja, seus pontos positivos ou negativos, mas ser mostrado como
esta ferramenta auxiliar no gerenciamento do projeto.

1.6 ESTRUTURA

Este trabalho est organizado em 5 captulos. O primeiro captulo introduz o tema

proposto e os objetivos do trabalho, justificando tanto o tema como os objetivos. So
apresentados brevemente tambm o mtodo de trabalho, a estrutura e as limitaes do mesmo.

O segundo captulo apresenta a histria sobre o desenvolvimento de produto, os

ciclos de vida dos projetos, a metodologia de gerenciamento de projetos escolhida para ser
adotada na empresa analisada, os conceitos tericos e a base de conhecimento em
gerenciamento de projetos. Alm disso, sero abordadas as principais normas internacionais
para desenvolvimento de produto principalmente para o ramo automotivo.

O terceiro captulo ser apresentado empresa analisada, o seu estgio de

maturidade sobre gerenciamento de projetos, atravs de um mtodo de pesquisa a ser
utilizado.

O quarto captulo ser mostrado a proposta do projeto, ou seja, o desenvolvimento

do trabalho na empresa analisada, a construo do modelo de gerenciamento de projetos
voltado ao processo de desenvolvimento de produto ao mercado automotivo, o
desdobramento das etapas do projeto montado, bem como os resultados obtidos e lies
aprendidas.

O quinto captulo mostra as concluses finais do trabalho praticado e

desenvolvido, as consideraes finais e as recomendaes para trabalhos futuros.
 19

2 REFERENCIAL TERICO

2.1 CONSIDERAES INICIAIS

Neste captulo, ser realizada uma abordagem sobre gerenciamento de projetos

apresentando e dividindo o tema em dois subtemas: (i) apresentao e discusso de conceitos,
e (ii) administrao do projeto voltada s necessidades organizacionais (KIRST, 2004).

O captulo assim dedicado a apresentar uma reviso bibliogrfica sobre os

pontos mencionados acima ressaltando suas influncias sobre o gerenciamento de um projeto.
Os itens 2.2 a 2.5 trazem os conceitos existentes na literatura atual para gerenciar projetos de
forma estruturada voltada ao objetivo principal, que o atendimento aos objetivos traados.
Posteriormente, nos itens 2.6 a 2.8 so levantadas questes relativas gesto de projetos
inseridos em ambientes organizacionais, sendo relatados os fatores e variveis que afetam o
seu andamento, sucesso e aspectos gerais.

2.2 DEFINIES DE PROJETO

O conceito de projeto, a partir da definio de vrios autores, consiste em um

esforo (empreendimento) com o objetivo de gerar algo, podendo ser um produto ou servio,
com incio e fim bem definidos e com uma peculiaridade que o diferencia de aes ou
operaes rotineiras: ser nico, ou seja, apresenta um resultado diferente daquilo j realizado
(PRIKLADINCKI, 2003; PMBoK, 2004; KIRST, 2004; CAVALIERI & DINSMORE, 2006).

O termo projeto, conforme usado no Brasil, designa algo mais abrangente que a
definio acima. O conceito utilizado em muitas empresas o de um desenho detalhado que
permite a elaborao de uma idia do produto e uma lista tcnica de materiais que muitas
vezes serve de base para executar um oramento. Neste caso, na literatura, recomenda-se a
utilizao da palavra design. A palavra projeto ou project (do ingls) engloba, por sua vez,
todas as atividades desde a concepo da idia at a entrega do produto ou servio final
(PRADO, 1998; KIRST, 2004).

Baseado nestas definies, os projetos possuem caractersticas importantes, tais

como: (i) so executados e gerenciados por pessoas; (ii) possuem uma demanda de custo,
prazo e qualidade, de um modo geral; (iii) envolvem a utilizao de recursos usualmente
limitados e escassos; e (iv) devem ser planejados, executados e controlados (PMBoK, 2004).
 20

Primeiramente, um projeto deve ter uma definio clara de tempo, ou seja, possuir
um incio e fim bem definidos. Um projeto considerado como pronto quando o produto ou
servio dele resultante atender as especificaes desejadas e tiver o aceite do cliente. Aps
este momento, o projeto finaliza e toda a estrutura montada desfeita e os recursos humanos
ou fsicos so dispensados. Neste momento, aquele produto ou servio lanado e inicia o seu
ciclo de vida til. Por fim, o produto final passa a ser conduzido por outras pessoas, equipe ou
organizao, que gerencia sua produo, utilizao, melhorias e descarte (KIRST, 2004;
DIAS, 2005).

Uma diferenciao deve ser feita com relao ao conceito de projeto e de

operaes rotineiras. Um projeto gera um produto ou servio nico e diferente de tudo j
realizado, seja no escopo, prazo, qualidade, custo, resultado esperado e local. Apesar de
alguns projetos possurem caractersticas semelhantes ou at idnticas, cada projeto tem suas
peculiaridades que resulta, de alguma forma, em uma necessidade de gerenciamento
individual. Cada projeto gera uma demanda e lies aprendidas que deve servir de base para
outros projetos que sero realizados (KIRST, 2004; PMBoK, 2004).

Operaes rotineiras, por outro lado, so atividades realizadas normalmente, com

os seus devidos procedimentos e executadas num perodo definido de tempo (hora, dia,
semana, ano). O controle e gerenciamento das operaes rotineiras tm como objetivo
garantir que essas sejam realizadas eficientemente, dentro dos padres desejados e
especificados, buscando atender a qualidade, custo, tempo de processamento ou demais
padres ou regras pr-definidas. Operaes rotineiras no tm fim determinado, sendo
geralmente repetidas indefinidamente, podendo ou no ser realizada da mesma forma
(PRADO, 1998).

Projetos podem ser divididos em diversos tipos dependendo do produto ou servio

a ser realizado. Como os projetos so particulares, cada projeto demanda habilidades e
tcnicas de gerenciamento especficas. Desta forma importante diferenci-los para
apresentar o cenrio em que sua gesto est inserida. Os tipos de projetos, de forma genrica,
so: (i) engenharia e/ou construo; (ii) manuteno; (iii) pesquisa e desenvolvimento; (iv)
lanamento de novos produtos; (v) tecnologia da informao; e (vi) administrativos (PRADO,
1998; KIRST, 2004).

Neste trabalho, o conceito de projeto adotado o de empreendimento. Isto

significa que um projeto necessariamente compreender todas as etapas necessrias para a
realizao do produto ou servio, desde a definio at a entrega e aprovao final ao cliente.
 21

Esta definio est em conformidade com a palavra project, usada na literatura com este
sentido (PRADO, 1998; PMBoK, 2004; KIRST, 2004).

2.3 O GERENCIAMENTO DE PROJETOS

O gerenciamento de projeto (GP) vem sendo usado, explorado, aprimorado e

difundido nas ltimas dcadas, alm do que vem sofrendo forte influncia das teorias
administrativas, incorporando ferramentas e tecnologias usadas por elas (PAULA et al.,
2006). O processo de gerenciamento de projetos era tradicionalmente realizado de uma forma
distinta e desvinculado dos outros processos, sendo visto nas organizaes como mais um
problema a solucionar. Ao longo do tempo, este processo passou a fazer parte dos processos
empresariais necessrios para o sucesso da empresa. Assim, necessrio entender como
inserir a gesto de projetos na cultura das empresas, levando em conta sua estrutura,
particularidades, forma de gerenciamento, formao de equipes, o gerenciamento de mltiplos
projetos, entre outros aspectos (KIRST, 2004).

O GP, por sua vez, resultado da formalizao de prticas de coordenao dos

esforos de projeto que vieram demonstrando sucesso ao longo da histria. Na ltima metade
do sculo XX a rea de GP tambm sofreu forte influncia das teorias administrativas
incorporando as ferramentas e tecnologias usadas por elas, mas mantm um carter ou
enfoque gerencial do projeto, o qual se preocupa com o monitoramento das aes de forma
orientada, com o objetivo de garantir a finalizao do mesmo.

2.3.1 Definio

A Gerncia de Projetos uma cincia que trata do planejamento e controle de

projetos. Gerenciar um projeto significa, resumidamente, planejar a sua execuo antes de
inici-lo e acompanh-la, posteriormente, monitorando e avaliando o previsto com relao ao
planejado. No planejamento do projeto so estabelecidas s metas (ou objetivos), as tarefas a
serem realizadas e o seu seqenciamento, com base nos recursos necessrios e disponveis. O
controle do projeto, no sentido moderno do termo, significa a medio do progresso e do
desempenho atravs de um sistema ordenado pr-estabelecido. Aes corretivas so tomadas
sempre que necessrias. As vantagens advindas de um projeto bem administrado se resumem,
basicamente, em que a execuo no diferir significativamente do planejamento. Um bom
 22

planejamento implica que um projeto poder ser executado no prazo e custo previstos e com
excelente qualidade (PRADO, 1998).

O Gerenciamento de Projetos (GP) uma aplicao de conhecimentos,

ferramentas e tcnicas s atividades do projeto a fim de atender aos seus requisitos. O gerente
de projetos a pessoa responsvel pela realizao dos objetivos do projeto. Gerenciar um
projeto inclui: (i) identificar as necessidades; (ii) estabelecer os objetivos claros e alcanveis;
(iii) balancear as demandas conflitantes de qualidade, escopo, tempo e custo; e (iv) adaptar as
especificaes dos planos e da abordagem s diferentes preocupaes e expectativas das
diversas partes interessadas (PMBoK, 2004; VALLERI e ROZENFELD, 1999).

Segundo o PMI Project Management Institute (PMBoK, 2004), o

gerenciamento de projetos requer aprimoramento da administrao de nove reas de
conhecimento vinculadas aos processos gerenciais. Estas reas se referem integrao dos
diversos elementos-chave de um projeto, alguns essenciais, outros facilitadores, os quais
foram definidos como: integrao, escopo, prazos, custos, recursos humanos, aquisies,
qualidade, riscos e comunicao do empreendimento. Estas nove reas so detalhadas na
seo 2.8.

Para facilitar seu gerenciamento, um projeto deve ser dividido em fases ou sub-
processos que constituem seu ciclo de vida de gerenciamento de projetos; so elas: (i)
iniciao, (ii) planejamento, (iii) execuo, (iv) monitoramento ou controle, e (v)
encerramento (VALLERI & ROZENFELD, 1999; PMBoK, 2004; CAVALIERI &
DINSMORE, 2006).

A iniciao refere-se aos processos relacionados ao conhecimento da necessidade

de um projeto, bem como o comprometimento com sua execuo. O planejamento est
relacionado com a montagem da estrutura que motivou o projeto. Nesta fase h sub-processos
essenciais, com dependncias bem definidas e executadas na mesma ordem do projeto, e sub-
processos facilitadores, que dependem da natureza do projeto e so executados quando
necessrios (PMBoK, 2004; KIRST, 2004). A execuo est relacionada com a coordenao
dos recursos para a realizao do projeto. O controle relaciona-se ao monitoramento do
andamento do projeto, bem como tomada de aes corretivas, se necessrias, para garantir a
execuo dentro dos objetivos. Por fim, o encerramento est relacionado entrega do produto
final do projeto, definido pela aceitao do cliente e concluso organizada dos trabalhos
(PMBoK, 2004; KIRST, 2004).
 23

H uma forte interao entre as fases do gerenciamento de projetos. Assim,

importante haver uma administrao eficiente para balancear as demandas em relao aos
objetivos do projeto. Cada etapa ou processo do projeto possui mais processos internos e
ligado atravs dos resultados que produz. Devido natureza dinmica dos projetos, os
processos se sobrepem, porm em intensidades variveis ao longo de cada fase do projeto,
visto que cada projeto tem a caracterstica de ser nico (PRADO, 1998; PMBoK, 2004). Esta
interao pode ser observada na Figura 1.

FIGURA 1 Processos de gerenciamento do projeto

Fonte: PMBoK, 2004
Segundo Valleri e Rozenfeld (1999), o Gerenciamento de Projetos (GP) oferece
uma viso integrada de todos os fatores envolvidos em um projeto para que sejam atingidos os
objetivos assumidos. O GP apresenta um enfoque humanstico e participativo, orientado para
a obteno de resultados, com a premissa de que os resultados so atingidos por meio do
trabalho de pessoas.

2.3.2 Histrico

Projetos vm sendo realizados desde os primrdios da civilizao. A construo

das Pirmides do Egito, depois de 2780 a.C., por exemplo, foi um grande projeto. Segundo
Sisk (1998 apud Torreo, 2005), na ltima metade do sculo XIX, houve um aumento na
complexidade dos novos negcios em escala mundial, o que implicou no surgimento dos
princpios da gerncia de projetos. A Revoluo Industrial alterou profundamente a estrutura
econmica do mundo ocidental e teve como uma das suas principais conseqncias o
desenvolvimento do capitalismo industrial. As relaes de produo foram drasticamente
 24

modificadas e iniciou-se, assim, uma cadeia de transformaes que tornou cada vez mais
exigente a tarefa de gerir nas organizaes econmicas.

Nos EUA, a primeira grande organizao a praticar os conceitos de GP foi a

Central Pacific Railroad, que comeou suas atividades no incio da dcada de 1870, com a
construo da estrada de ferro transcontinental. Os lderes do negcio se depararam com a
complexa tarefa de organizar as atividades de milhares de trabalhadores, a manufatura e a
montagem de quantidades no previstas de matria-prima (TORREO, 2005).

No incio dos anos 60, o Gerenciamento de Projetos foi formalizado como cincia
(PRADO, 1998). Neste ponto, vrias organizaes comearam a enxergar o benefcio do
trabalho organizado em torno dos projetos e a entender a necessidade crtica para comunicar e
integrar o trabalho atravs de mltiplos departamentos e profisses.

Em 1969, no auge dos projetos espaciais da NASA, um grupo de cinco

profissionais de gesto de projetos, se reuniu para discutir as melhores prticas e Jim Snyder
fundou o Project Management Institute PMI (EUA). Atualmente, o PMI a maior
instituio internacional dedicada disseminao do conhecimento e ao aprimoramento das
atividades de gesto profissional de projetos (PMBoK, 2004).

Hoje, o Gerenciamento de Projetos vem se fortalecendo cada vez mais. As

organizaes identificam a necessidade de gerenciar projetos com forma de obteno de
sucesso operacional. O PMI estima que aproximadamente 25% do PIB mundial so gastos em
projetos e que cerca de 16,5 milhes de profissionais esto envolvidos diretamente com
gerncia de projetos no mundo. Este volume de projetos e as mudanas no cenrio mundial,
cada vez mais competitivo, geram a necessidade de resultados mais rpidos, com qualidade
maior e menor custo (CAVALIERI & DINSMORE, 2006).

2.3.3 Partes interessadas e o ambiente de projeto

Os indivduos, grupos ou organizaes diretamente interessados em um projeto

constituem as partes envolvidas no mesmo. So todos aqueles que podem ser afetados, de
forma positiva ou negativa, no decorrer do projeto ou aps a sua concluso. Assim, a gerncia
do projeto deve identificar estes participantes, conhecer suas expectativas e necessidades,
gerenciando e influenciando as mesmas de forma a garantir o sucesso do projeto. necessrio
identificar quem tem o poder de tomar decises a respeito do projeto e saber quais
necessidades devem ser atendidas e quais devem ser eventualmente relegadas a um segundo
plano.
 25

As principais partes envolvidas em um projeto so: o gerente de projeto, a equipe

de projeto, o patrocinador e o cliente. Em muitos casos, a gerncia funcional tambm um
participante importante (KIRST, 2004; PMBoK, 2004). Na Figura 2 apresentada, de forma
visual, o ambiente do projeto.

FORNECEDORES FORNECEDORES
DO EXECUTOR DO CLIENTE

ALTA ALTA
ADMINISTRAO ADMINISTRAO
PROJETO
EXECUTOR CLIENTE

EMPRESA EMPRESA
EXECUTORA VIZINHOS CLIENTE

FIGURA 2 O ambiente do projeto

Fonte: Prado, 1998

O gerente de projeto tem a responsabilidade de cumprir as metas estabelecidas

para o mesmo. No mbito interno do projeto, ele representa a autoridade mxima, embora na
maioria das vezes no seja da organizao, no caso de uso de escritrios de projetos externos
e desvinculados da empresa. Como responsvel pela montagem da equipe e pela interao
com as demais partes envolvidas, o gerente de projeto deve ministrar as comunicaes,
recursos humanos, contratos, materiais, execuo do trabalho e riscos. Estas responsabilidades
variam, dependendo do tipo de organizao e do porte dos projetos (PRADO, 1998; PMBoK,
2004).

Um papel importante do gerente de projeto o de planejador. Sua principal tarefa

assegurar a preparao correta do projeto, esclarecendo claramente as necessidades do
cliente, o escopo do trabalho e os recursos necessrios para sua execuo. Como organizador
e implementador, ele deve prever e mobilizar os meios, principalmente os membros de equipe
de projeto, para fazer o projeto acontecer. Alm disso, o responsvel por monitorar o
andamento e tomar decises capazes de manter o projeto dentro do previsto, ou corrigir seu
rumo de acordo com a necessidade do cliente e o objetivo estratgico da organizao, at a
 26

entrada e aceite do produto do projeto. Alm disso, o gerente de projeto o gestor de pessoas
e de conhecimento. Ele o responsvel pela montagem, conduo e desenvolvimento da
equipe (KIRST, 2004). Conforme Mller (2007), o gerente de projeto dever ser tecnicamente
competente e com foco na execuo das tarefas.

A equipe de projeto (ou membros do projeto) constituda pelas pessoas

responsveis pela execuo do mesmo. Cada indivduo que contribui com sua habilidade,
tempo e empenho para o projeto considerado membro da equipe. Estas pessoas possuem o
conhecimento tcnico especializado necessrio para realizar o produto do projeto. Sua
alocao pode ser integral ou parcial em cada projeto. Entretanto, para o sucesso do projeto, o
papel de cada membro da equipe deve ser claro para si prprio e para o resto da equipe.
funo do gerente de projeto estabelecer este papel, bem como gerenciar os aspectos
motivacionais e o desempenho dos membros da equipe (KIRST, 2004; PMBoK, 2004).

O patrocinador uma pessoa com autoridade formal da organizao para levar o

projeto adiante, delegando ao gerente de projeto esta misso. Em ltima anlise, o
responsvel final pelo projeto e seu sucesso, sendo quem aloca os recursos financeiros para a
execuo do projeto. Seu papel , atravs da autoridade que possui, apoiar o gerente de
projeto, uma vez que este normalmente no possui tal autoridade. Seu papel principal
auxiliar o gerente de projeto a superar os obstculos organizacionais, seja informando
organizao da existncia e prioridade do projeto, seja intervindo em favor do projeto quando
necessrio. Em estruturas funcionais para projeto, o apoiador a pessoa qual o gerente de
projeto se reporta e deve endossar o equilbrio de custos, prazo e qualidade apresentado pelo
gerente de projeto, cobrando deste o resultado esperado e realizando os devidos ajustes ao
longo do caminho, se necessrio (KIRST, 2004; PMBoK, 2004). Conforme Kolltveit et al.
(2007) a chave do sucesso inclui comunicao, negociao, relacionamento, influncia e
dependncia do stakeholder (parte interessada).

O cliente a pessoa, grupo ou organizao que far uso do produto do projeto. O

cliente responsvel por gerar as especificaes desejadas do produto final. Um potencial
ponto de conflito ocorre quando o cliente no tem certeza do produto que deseja receber, o
que torna o gerenciamento do escopo muito mais complicado e pode vir a trazer problemas
devido ao custo de eventuais mudanas tardias. Em geral, divergncias entre as partes
envolvidas devem ser resolvidas em favor do cliente, uma vez que, em ltima estncia,
normalmente esta parte que pagar o projeto. Isto no significa que as demais necessidades
ou expectativas devam ser desconsideradas. Encontrar as solues para tais divergncias um
 27

dos maiores desafios do gerente de projeto. Mesmo a identificao correta do cliente de um

projeto pode ser um problema, pois este papel nem sempre est claro. Existem pessoas com
autoridade final sobre as especificaes do produto e outras cuja opinio importante no
desenvolvimento das mesmas, mas que no tm poder de deciso final (KIRST, 2004;
PMBoK, 2004).

2.3.4 Metas do projeto

O estabelecimento da meta de um projeto deve ser feito durante a sua criao,

sendo aprimorada nas fases seguintes (estudo de viabilidade, definio de requisitos e design)
de modo que, na fase de execuo, no exista mais nenhuma dvida. Uma meta deve conter
um objetivo gerencial, um prazo para ser atingida e um custo correspondente. Geralmente as
metas dos projetos esto relacionadas em termos do desempenho do empreendimento
propriamente dito em termos de custo, tempo e qualidade (ATKINSON et al., 2006).

Um projeto deve conter metas intermedirias, e genericamente poder ser

atribudo duas metas, a meta final e as metas intermedirias para qualquer empreendimento. O
produto final de um projeto dever ficar pronto aps um determinado prazo e a um
determinado custo, e desta forma, medida que os projetos vo evoluindo, o grau de incerteza
nestas metas intermedirias vai aumentando. Na Figura 3, mostra a evoluo dos projetos no
tempo e custo, e o crculo ao redor da meta indica a incerteza envolvida com aquele
empreendimento. Esta uma caracterstica peculiar de projetos a qual no encontra
semelhanas em ambientes de produo repetitiva, pois no tem onde se basear (PRADO,
1998).
$ Meta
Final

Meta Intermediria
II

Meta Intermediria I

Tempo

FIGURA 3 A meta de um projeto

Fonte: Prado, 1998

 28

2.3.5 Fatores crticos de sucesso

Fatores crticos de sucesso devem ser observados durante os processos de

planejamento e execuo do projeto para minimizar seus riscos e garantir o atingimento de
sucesso (PRADO, 1998). Eles representam os aspectos mais importantes e estratgicos para o
gerenciamento de qualquer projeto, pois envolvem inmeras tarefas dentro dos processos,
desde fatores (atividades) complexos at inter-relacionamentos (BEZZERRA et al., 2005;
PRICLADNICKI, 2003). A Figura 4 resume os fatores crticos e requisitos num projeto para
maximizar o sucesso, descritos por alguns autores (PRADO, 1998; PRIKLADNICKI, 2003;
RABECHINI et al., 2002; RABECHINI et al., 2005).

Autores Fatores Crticos Requisitos

CLARKE (1999 Comunicao Quebrar as barreiras verticais (estrutura

hierrquica), horizontais (processos e
apud
integrao dos recursos), externas (clientes) e
PRIKLADNICKI, geogrficas (distncias e diferenas
culturais).
2003)
Necessrio, adequar o sistema de informao,
fluxo de informao, ligaes entre equipes,
conduo de reunies, relacionamentos
cliente-fornecedor, e ligaes com a alta
administrao.
Objetivos e escopo Deve ser claro, definido e controlado por um
claros processo formal.
Planejamento de Reunir toda documentao gerada, atualizado
projeto e monitorado freqentemente.
Estrutura Analtica de Subdividir o projeto em partes tornando mais
Projeto (EAP) gerencivel.
PRADO (1998) Gerncia Competente Possuir um nico gerente que seja experiente,
treinado, respeitado e com disponibilidade de
tempo.
Equipe Competente Deve ser constituda de pessoas
comprometidas com o projeto, de preferncia
experientes, treinadas e com disponibilidade
de tempo. A equipe dever estar focada,
motivada e apresentando perfil adequado
para enfrentar o desafio do projeto.
Planejamento e Deve ser feito constantemente e com rigor,
Controle focando sempre no atendimento das metas
estabelecidas.
 29

Levantamento dos Eliminar ou neutralizar os itens de alto

Riscos impacto ao projeto.
Ferramentas Usar ferramentas gerenciais ligadas s
Gerenciais utilizadas estratgias gerenciais mais adequadas a
ocasio.
RABECHINI et al. A misso do projeto Definio clara dos objetivos no incio do
projeto.
(2002)
Suporte gerencial Criar ou encontrar a autoridade e poder
existentes na organizao para gerenciar os
recursos do projeto.
Planejamento Estabelecer as atividades individuais do
projeto e os respectivos responsveis.
Cliente consultor Estabelecer comunicao com os clientes do
projeto.
Administrao de Fazer o recrutamento, seleo e treinamento
pessoal das necessidades do pessoal dedicado ao
projeto.
Competncias Levantar e definir as competncias para o
acompanhamento das tarefas tcnicas.
Aceite do cliente Estabelecer no estgio final do projeto a
entrega dos resultados ao cliente at o seu
aceite.
Monitoramento Dar feedback em todos os estgios do
processo.
Comunicao Estabelecer um processo de tenha forma,
freqncia e com qualidade a informao
repassada.
Gerncia conciliadora Gerentes com capacidade de superar os
inesperados conflitos.
FIGURA 4 Resumo dos fatores crticos de sucesso

Fonte: Adaptado de Clarke, 1999 apud Prikladnicki, 2003; Prado, 1998; Rabechini, 2002

2.4 CONTEXTO SOBRE GERENCIAMENTO DE PROJETOS

O Gerenciamento de Projetos existe em um contexto mais amplo que inclui o

gerenciamento de programas, o gerenciamento de portflio e o escritrio de projetos.
Freqentemente, os elementos que compem o gerenciamento de projetos se organizam em
uma hierarquia, formada pelo plano estratgico, portflio, programa, projeto e subprojeto.
Resumidamente, um programa constitudo de diversos projetos e subprojetos, os quais,
 30

associados, formaro um portflio que contribuir para o sucesso de um plano estratgico

(PMBoK, 2004).

2.4.1 Gerenciamento de Programas e Gerenciamento de Portflio

Para o entendimento do Gerenciamento de Projetos, Programas e Portflio

necessrio definir subprojetos. Conforme o PMI (2004), subprojetos so partes menores de
um projeto. Os mesmos so freqentemente divididos em componentes mais facilmente
gerenciveis, embora quando individualizados passam a ser chamados de pequenos projetos e
gerenciados como tal. Os subprojetos so normalmente contratados de uma empresa externa
ou de uma outra unidade funcional na organizao executora. Projetos muito grandes so
freqentemente segmentados, tornando-se um conjunto de subprojetos, os quais podem sofrer
desmembramentos, conforme a necessidade (PMBoK, 20004).

De acordo com o PMBoK (2004), um programa um grupo de projetos

relacionados e gerenciados de modo coordenado, com o objetivo de atingir as metas afetando
os benefcios estratgicos, sendo controlado individualmente. Um programa pode incluir
elementos de trabalho que no esto relacionados ao escopo dos projetos, podendo um
programa ser distinto a outros programas. Os programas tambm envolvem uma srie de
empreendimentos repetitivos ou cclicos (PMBoK, 2004; RABECHINI Jr. et al., 2005).

Programas so empreendimentos de longo prazo, normalmente constitudos de

vrios projetos que guardam entre si alguma afinidade, geralmente uma estratgia ou um
objetivo maior, conforme exemplifica a Figura 5. Os projetos so compostos por atividades
que so um conjunto mnimo de esforos a partir dos quais possvel definir
responsabilidades, alocar recursos e controlar custos, de forma a gerenciar sua execuo
(PRIKLADINICKY, 2004).

Projetos Programas
Um processo para produzir um resultado Uma estrutura organizada
especfico (escopo)
Durao definida Durao indefinida
Objetivos definidos Evoluem com as necessidades dos negcios
Gerente de Projeto com responsabilidade Gerente de Programas facilitam a interao
nica sobre o sucesso do projeto entre diversos gerentes
FIGURA 5 Comparativo entre projetos e programas

Fonte: Adaptado de Prikladinicky, 2004

 31

Portflio pode ser descrito como um conjunto de projetos ou programas e outros

trabalhos agrupados para facilitar o gerenciamento eficaz desse trabalho a fim de atender os
objetivos de negcios estratgicos. De acordo com Rabechini Jr. et al. (2005), a gesto do
portflio uma nova forma gerencial no mundo dos negcios, e este gerenciamento dever
ser realizado de forma sistmica, ou seja, tal que se transforme num processo dinmico onde
os projetos so constantemente alterados e revisados.

A gesto de portflio ou carteira de projetos permite que os gerentes tenham uma

viso mais ampla das alternativas de projetos e que possam maximizar os resultados de toda a
carteira (MORAES et al., 2003).

Para autores como Martinsuo et al. (2006) e Cauchik Miguel et al. (2006), o
gerenciamento de portflio significa a diviso e seleo dos recursos escassos ao grupo de
projetos ou oportunidades de negcios de uma organizao, sendo realizado sobre a
superviso de um patrocinador ou gerentes desta organizao.

Os projetos ou programas dentro de um portflio podem no ser necessariamente

interdependentes ou diretamente relacionados. possvel atribuir recursos financeiros e
suporte por tipo de categoria, tal como, linhas de negcios especficas ou tipos de projetos
genricos, como infra-estrutura e melhoria dos processos internos (PMBoK, 2004).

As organizaes gerenciam seus portflios com base em metas especficas. Uma

meta do gerenciamento de portflios maximizar o valor do portflio atravs do exame
cuidadoso dos projetos e programas candidatos para incluso no portflio e da excluso
oportuna de projetos que no atendam aos objetivos estratgicos do portflio. Outra meta est
em equilibrar o portflio entre investimentos dedicados inovao e manuteno, e para o
uso eficiente dos recursos (PMBoK, 2004). Rabechini Jr. et al. (2005) resumem o
gerenciamento de portflio em trs objetivos: (i) valor mximo ou mximo retorno
econmico; (ii) balanceamento da carteira de projetos; e (iii) alinhamento estratgico.

O gerenciamento de portflio, seguindo estes conceitos, tem sido discutido por

uma srie de autores que, em linhas gerais, enfatizam a necessidade de estabelecimento de
processos e procedimentos gerenciais distintos. Entre eles, Atkinson (2006) e Rabechini Jr. et
al. (2005) apresentam o gerenciamento de portflio visto como um processo gerencial guiado
pelos passos apresentados na Figura 6.
 32

PASSOS DETALHES

Identificao de projetos Considerao dos aspectos estratgicos;

Considerao dos aspectos tticos;
Considerao dos projetos em andamento;
Formar relao inicial de projetos.
Alinhamento de Identificao e seleo de critrios de avaliao
oportunidades s estratgias estabelecendo pesos para avaliao dos
e organizao projetos/programas;
Hierarquizao dos projetos e programas.
Avaliao de investimentos Pontos de deciso ou filtros levando-se em conta os
e recursos elementos financeiros.
Desenvolvimento do Formao do portflio;
portflio O portflio subsidiar decises sobre os projetos
considerando-se priorizao dos mesmos,
possibilidades de excluso, de incluso de recursos,
etc.;
O portflio poder ser tambm um instrumento para
reviso do escopo dos projetos.
Gerenciamento do portflio Desenvolver estruturao dos projetos em termos de
escopo, prazos e custos;
Acompanhar o andamento;
Liberar recursos;
Comunicar os interessados, entre outras aes
gerenciais.
FIGURA 6: Processo gerencial para criao do gerenciamento de portflio

Fonte: Rabechini Jr. et al., 2005

Segundo o PMI (2004), para a busca da eficcia no Gerenciamento de Projeto

necessrio promover o alinhamento estratgico, que pode ser atingido atravs de uma
adequada gesto do portflio de projetos, da implementao de uma estrutura apropriada
(estratgica) na forma de escritrios de projeto, da construo de competncias (recursos) e de
maturidade em gesto de projetos em mbito organizacional.

O gerenciamento do portflio dever prover uma base de informaes de forma a

possibilitar a tomada de deciso com relao alocao e priorizao entre diferentes tipos de
projetos (RAUTIAINEN, 2000).

A metodologia para seleo de portflios na Figura 7 mostra o processo de

seleo de carteira atravs do uso de tcnicas de avaliao de projetos em uma programao
estabelecida em trs fases: consideraes estratgicas, avaliao individual de projetos e
selees de carteiras (RABECHINI Jr. et al., 2005).
 33

Desenvolvimento
Estratgico

Proposta de Diretrizes Alocao de

Projeto Recursos

Pr- Anlise Avaliao Otimizao do Ajuste da

Avaliao Individual de Portflio Carteira
Projeto
Execuo
Banco de Dados
Projeto
de Projeto
Avaliao por
fases
Metodologia de
Avaliao Trmino

Figura 7: Seleo de portflio de projetos

Fonte: Adaptada de Rabechini Jr. et al., 2005

O gerenciamento do portflio requer estar alinhado s estratgias do negcio. Este

alinhamento estratgico deve ser construdo utilizando critrios de seleo e modelos de
priorizao dos projetos. As estratgias devem partir da alta administrao, ou seja, de forma
top-down (de cima para baixo), e na implantao devero utilizar todas as reas e ambientes
dentro da organizao (CAUCHIK MIGUEL et al., 2006; RABECHINI Jr. et al., 2005).

A eficincia no gerenciamento de portflio de projetos implica diretamente na

capacidade dos gerentes de projetos. Da mesma forma, alguns pontos so relevantes e
contribuem para o sucesso dos projetos como, por exemplo, a necessidade de definio clara
dos objetivos do escopo, cronograma, custos e recursos compartilhados com outras reas
(MARTINSUO et al., 2006).

Por outro lado, Cauchik Miguel et al. (2006) lista modos em que o gerenciamento
de portflio pode falhar, perder credibilidade ou ser de m qualidade: (i) recursos limitados
compartilhados entre muitos projetos a serem desenvolver; (ii) projetos em andamento que
no focam na estratgia do negcio; (iii) indeciso sobre a continuidade de projetos sem foco;
e (iv) a seleo ou escolha de projetos errados.
 34

Empresas devem selecionar projetos com maior potencial de faturamento e

verdadeiras vantagens competitivas. Adicionalmente, importante o balano entre os projetos
de forma a otimizar o mix de investimentos com relao aos trade-offs de risco e retorno,
manuteno e crescimento, e curto e longo prazo (CAUCHIK MIGUEL et al., 2006).

Outro aspecto importante diz respeito aos recursos para desenvolvimento de

novos produtos. Eles devero ser divididos entre linhas de produtos, de forma a montar uma
carteira de projetos segmentada por tipo de produto podendo ser desenvolvido ao mesmo
tempo (CAUCHIK MIGUEL et al., 2006).

Segundo Rabechini Jr. et al. (2005), o gerenciamento de portflio traz benefcios

s organizaes dando-lhes condies de sustentarem suas vantagens competitivas,
consistindo em evidente oportunidade de sucesso. Adicionalmente, a escolha de um portflio
de produtos essencial e um fator relevante s chances de crescimento das empresas
(CAUCHIK MIGUEL et al., 2006).

Neste aspecto, o gerenciamento de portflio proporciona aos dirigentes das

empresas um exame detalhado das dimenses estratgicas que devem nortear o
balanceamento da carteira, incentiva a avaliao e permite a adequada priorizao dos
projetos, bem como cria mecanismos de controle e descarte dos mesmos (RABECHINI Jr. et
al., 2005; MARTINSUO et al., 2006).

Martinsuo et al. (2006) definiu a mtrica da eficincia no gerenciamento de

portflio como o preenchimento ou atendimento dos objetivos dos projetos. Estes objetivos
devem estar alinhados com a estratgia organizacional. Em paralelo, os projetos devem estar
balanceados buscando a maximizao dos resultados financeiros.

De forma geral, espera-se que esta forma de gesto possa ser mais bem aplicada
quelas organizaes que geram muitos projetos e necessitam, portanto, de uma forma mais
profissional de administrar sistematicamente o conjunto de seus empreendimentos
(RABECHINI Jr. et al., 2005).

Uma grande meta no gerenciamento do portflio t-lo balanceado em termos de

parmetros chaves. Grficos visuais, tais como o grfico de bolhas ou mapa de portflio,
podem ser utilizados, pois favorecem a visualizao do balanceamento dos projetos com
relao aos parmetros estabelecidos. Nestes grficos ou mapas devem ser consideradas as
dimenses, tais como: aderncia estratgia, inovao ou importncia ao negcio,
durabilidade da vantagem competitiva, retorno econmico, impacto tecnolgico,
 35

probabilidade de sucesso, custo e tempo para concluso, e investimento de capital requerido

em marketing (CAUCHIK MIGUEL et al., 2006).

Resumidamente, um efetivo gerenciamento de portflio requer trs elementos os

quais devem ser trabalhados em harmonia: (i) a estratgia do negcio; (ii) pontos de
monitoramento dos projetos; e (iii) reviso do portflio utilizando modelos e ferramentas
gerenciais (CAUCHIK MIGUEL et al., 2006).

A prtica da gesto de portflio importante no somente para as decises

gerenciais, mas tambm para agilizar e qualificar a tomada de decises acerca dos projetos
sob responsabilidade do gerente do negcio. Manter a metodologia de gerenciar o portflio de
projeto rodando pode ser considerado como vital para a sobrevivncia da organizao
(CAUCHIK MIGUEL et al., 2006).

2.4.2 Escritrio de Projetos

medida que o gerenciamento de projetos ganha importncia nas organizaes,

torna-se necessrio centralizar, de alguma forma, a conduo, controle e gerenciamento das
informaes a respeito dos mesmos. O conceito de escritrio de projetos uma forma
moderna de organizao administrativa que surgiu a partir desta necessidade. Embora no
haja uma forma nica para sua implantao e funcionamento, o conceito genrico de
escritrio de projetos vem ganhando cada vez mais adeptos em diversas empresas do mundo
(PRIKLADNICKI, 2003; KIRST, 2004).

Um escritrio de Projetos ou Project Management Office (PMO) uma unidade

organizacional que tambm pode ser chamada de escritrio de gerenciamento de programas,
escritrio de gerenciamento de projetos ou escritrio de programas. Um PMO supervisiona o
gerenciamento de projetos, programas ou uma combinao dos dois. Alm disto, coordena o
planejamento, priorizao e execuo de projetos e subprojetos vinculados aos objetivos
gerais de negcios da matriz ou do cliente (PMBoK, 2004).

No existe um nico formato de escritrio de projetos. Ele pode ser simplesmente

um rgo gerenciador das informaes do andamento dos projetos, funcionando como uma
espcie de assessoria aos gerentes de projetos, que reporta, mas no interfere. Em outra
composio, pode ser responsvel pela gesto do conhecimento, realizando treinamentos e
implementao de metodologias de gerenciamento de projetos para diversas equipes de outras
reas da empresa, e buscando a melhoria dos processos, funcionando, assim, como consultor.
 36

Adicionalmente, o escritrio pode ser responsvel geral pela execuo dos projetos, controle
dos recursos, prazos, custos, acompanhamento e qualidade (KIRST, 2004).

O escritrio de projetos constitudo por um grupo de pessoas responsvel pela

conduo de projetos e pela promoo e desenvolvimento da cultura de gerenciamento de
projetos na organizao. Trata-se de um elo entre a alta administrao e os demais nveis
tticos e operacionais, no que diz respeito conduo dos projetos. Sua implementao
permite facilitar e otimizar o gerenciamento de projetos, geralmente a um custo baixo. So
especialmente teis em empresas que empreendem muitos projetos simultaneamente, pois
facilitam o trabalho dos gerentes de projeto ao compartilhar as tarefas de planejamento e
acompanhamento (PRIKLADNICKI, 2003; KIRST, 2004).

Os PMOs podem operar de modo contnuo, desde o fornecimento de funes de

apoio ao gerenciamento de projetos na forma de treinamento, software, polticas padronizadas
e procedimentos, at o gerenciamento direto real e a responsabilidade pela realizao dos
objetivos do projeto. Um PMO especfico pode receber uma autoridade delegada para atuar
como parte interessada integral e como tomador de decises durante o estgio de iniciao de
cada projeto, podendo ter autoridade para fazer recomendaes ou encerrar projetos, para
manter a consistncia dos objetivos de negcios. Alm disso, o PMO pode estar envolvido na
seleo, no gerenciamento e na realocao, se necessrio, do projeto compartilhado e, quando
possvel, do pessoal dedicado do projeto (PMBoK, 2004).

Algumas caractersticas e atribuies de um PMO incluem: (i) recursos

compartilhados e coordenados em todos os projetos administrados pelo PMO; (ii)
identificao e desenvolvimento de metodologia, melhores prticas e normas de
gerenciamento de projetos; (iii) centralizao e gerenciamento das informaes para polticas,
procedimentos, modelos e outras documentaes compartilhadas do projeto; (iv) escritrio
central para operao e gerenciamento de ferramentas do projeto, como software de
gerenciamento de projetos para toda a empresa; (v) coordenao central de gerenciamento das
comunicaes entre projetos; e (vi) monitoramento central de todos os prazos e oramentos do
projeto do PMO, geralmente no nvel da empresa (PMBoK, 2004).

O formato adotado depende da cultura da empresa, sua estrutura, disponibilidade

de recursos e importncia dada aos projetos. Em qualquer formato, o PMO tem o potencial de
trazer benefcios como: (i) alinhamento dos projetos com a estratgia e objetivos da
organizao; (ii) aumento da produtividade das equipes de projeto; (iii) melhor distribuio de
recursos; (iv) criao, desenvolvimento e aperfeioamento de metodologias e padres de
 37

gerenciamento de projetos, bem como a permeao da cultura de gerenciamento de projetos

na organizao; (v) melhora na comunicao entre as partes interessadas, tanto internas como
externas; (vi) maior grau de sucesso nos projetos empreendidos (KIRST, 2004; SATO et al,
2004).

A implementao de um PMO deve ser gradual, progressiva e adequada cultura

da organizao. O apoio executivo fundamental, pois a mudana a ser feita de cunho
estratgico e, como todos os processos de mudana enfrentam resistncias, por mexer nas
estruturas do poder corporativo (KIRST, 2004).

2.5 CICLO DE VIDA DE PROJETOS

O carter nico de cada projeto demanda que estes possuam um certo grau de
confiabilidade associado sua execuo. Assim, necessrio dividir cada projeto em fases,
como forma de gerenci-los ordenadamente e associar, de forma adequada, os processos
operacionais e recursos necessrios em cada fase. Tal diviso ou seqncia de fases
conhecida como o ciclo de vida do projeto (KIRST, 2004). Cada fase possui atividades
caractersticas, pontos a serem checados e, ao seu final, produtos ou resultados de trabalho a
serem entregues. O final de cada fase deve prever a reviso destes itens, permitindo
determinar se o projeto deve seguir adiante ou ser interrompido, bem como detectar e corrigir
erros quando seu custo ainda aceitvel (KIRST, 2004; PMBoK, 2004).

Vrios autores utilizam o termo de ciclo de vida de projeto pressupondo a idia de

vida. Pinto (2002) descreve a idia em termos da durao da organizao de projeto,
ressaltando que o projeto acontece em um contexto organizacional: o seu nascimento ocorre
quando a organizao aceita a responsabilidade pelo problema e decide alcanar as metas
atravs da Administrao dos Projetos; o crescimento se d atravs do planejamento e da
execuo dos esforos necessrios; o declnio inicia-se com o alcance das metas e
conseqente realocao de recursos; por fim, sua morte ocorre quando a responsabilidade pelo
novo produto repassada para a Administrao de Operaes.

Diferentes tipos de projetos possuem diferentes fases, logo se adequando a

modelos distintos de ciclo de vida (MAXIMIANO, 2002). Embora muitos ciclos de vida de
projeto possuam fases com nomes ou prazos de entrega semelhantes, poucos ciclos de vida
so idnticos. Alguns podem apresentar quatro ou cinco fases, enquanto outros podem se
estender at nove fases. Mesmo considerando produtos similares, os ciclos de vida podem ser
 38

diferentes dependendo exclusivamente do escopo de cada um, podendo ou no retirar ou

incluir novas etapas ou processos de gerenciamento (PINTO, 2002; PMBoK, 2004).

A idia de dividir o ciclo de vida em fases segue uma lgica subjacente onde
cada fase deve ser estabelecida com os propsitos de conseguir um melhor controle gerencial
sobre recursos, proporcionar o acompanhamento do desenrolar dos acontecimentos
favorecendo ajustes nos planos, e propiciar uma ligao mais adequada de cada projeto com
seus processos operacionais contnuos (PINTO, 2002; PMBoK, 2004; SAUER, 2007).

Cada fase do projeto deve ser marcada pela obteno de um ou mais deliverables
(resultados passveis de entrega; PMBoK, 2004). Cada produto de fase composto por
subprodutos, ou seja, resultados tangveis e verificveis de trabalhos especficos idealizados
para possibilitar a materializao dos propsitos j citados (PINTO, 2002).

Nesse caso, os subprodutos seriam os levantamentos das necessidades, o estudo

de viabilidade econmica e o desenho de especificao, no caso em que o projeto se encontre
na fase de design, por exemplo. As fases do ciclo de vida de um projeto devem ser
estabelecidas com base na identificao dos deliverables adequados. Procedendo desta forma,
ser criado um conjunto de fases com seqncia lgica capaz de assegurar uma apropriada
definio do produto do projeto. Adicionalmente, a concluso de cada fase ser marcada pela
reviso e avaliao dos seus subprodutos, que fornecero subsdios a decises referentes
correo de erros e definio da continuidade ou no do projeto. Logo, o conceito de ciclo
de vida do projeto consiste em um elemento fundamental para propiciar apoio suficiente na
gesto do projeto, j que fornece recursos para a concretizao das funes administrativas
(PINTO 2002).

Como diferentes tipos de projetos apresentam demandas distintas isso se refletir

em termos do ciclo de vida. Apesar da grande variao quanto ao nmero de fases no ciclo de
vida de projetos, possvel caracterizar uma descrio genrica do ciclo de vida de um
projeto conforme ilustrado na Figura 8.
 39

FIGURA 8: Exemplo genrico do ciclo de vida de projeto

Fonte: PMBoK, 2004

Algumas caractersticas em comum entre os ciclos de vida de projetos so

resumidas no Figura 9.

Caracterstica Comportamento ao longo do Ciclo de vida

Custo e Recursos As variaes so relativamente baixas no incio do projeto,

aumentam at atingir um pico e decrescem ao longo das fases
Humanos
intermedirias, reduzindo-se drasticamente durante a fase final.
Mudanas A mudana das caractersticas e custo final do produto so altas no
incio, reduzindo-se no final do desenvolvimento do projeto, e deve-
se principalmente porque o custo de mudanas e correo de erros
geralmente maior medida que o projeto se desenvolve.
Riscos e incertezas Decrescem conforme o projeto se desenvolve.

FIGURA 9 Comportamento comum dos projetos ao longo de seus ciclos de vida

Fonte: Adaptado de Pinto, 2002

As discrepncias encontradas entre ciclos de vida referem-se diferena no

nmero de fases intermedirias: basta uma breve pesquisa bibliogrfica e encontram-se ciclos
de vida com desde uma at cinco fases intermedirias (KIRST, 2003; PINTO 2002; PMBoK
2004; PRADO, 1998; PRICLADNICKI, 2003). A Figura 10 traz alguns exemplos de ciclos
de vida de projeto encontrados na literatura.
 40

Autor Modelos de Ciclo de Vida

King (1998) 1. Definio

2. Design Fsico
3. Implementao
Kloppenberg et al. 1. Planejamento Conceitual
(1999) 2. Implementao e Controle de Projetos
3. Avaliao do Projeto
4. Melhoria do Sistema
Kruglianskas 1. Concepo e Estruturao
(1993) 2. Execuo
3. Encerramento
Maximiano (1997 1. Viabilidade (1997) ou Concepo (2002)
e 2002) 2. Planejamento & Design (1997) ou Desenho (2002)
3. Produo (1997) ou Execuo (2002)
4. Adaptao e lanamento (1997) ou Encerramento (2002)
Moris (1996) 1. Viabilidade
2. Planejamento & Design
3. Produo
4. Adaptao & Lanamento
Struckenbruch 1. Conceituao ou Iniciao
(1983) 2. Crescimento ou Organizao
3. Produo ou Operacional
4. Encerramento
Figura 10 Exemplos de ciclos de vida de projeto com trs e quatro fases

Fonte: Adaptado de Pinto, 2002

Maximiano (2002) dividiu o ciclo de vida de projeto em quatro fases (concepo,

desenho, execuo e encerramento) e definiu as caractersticas de cada fase, conforme
apresentado na seqncia.

A etapa de concepo inicia a partir de uma demanda do cliente (podendo este ser
interno ou externo) ou de uma nova idia, a partir da qual se cria a necessidade de um projeto
e o primeiro modelo desenvolvido. Neste momento, alm do conceito so necessrios
estudos de viabilidade tcnica e econmica. Na etapa de desenho ou de projeto o conceito ou
 41

a idia transformado em desenho detalhado, incluindo especificaes, com um nvel de

informao suficiente para executar ou produzir o produto. Nesta fase, o levantamento dos
custos fica mais claro e confivel. Na etapa de execuo, o desenho gerado na fase anterior
concebido at tomar sua forma final. Na entrega, ltima etapa do modelo genrico, o produto
chega at o cliente. Nela so necessrios testes, anlises e controles sobre o produto, tal que o
cliente o receba conforme desejado e o projeto seja encerrado. Maximiano (2002) ressalta
que, em alguns casos, uma fase pode iniciar-se antes do trmino da anterior (essa
sobreposio de fases designada por fast tracking).

Apesar da inexistncia de consenso quanto ao nmero ideal de fases no ciclo de

vida de um projeto, alguns autores como, Maximiano (1997) e Pinto (2002) propem um
modelo geral de quatro fases, conforme apresenta a Figura 11.

FIGURA 11 Tarefas de projeto ao longo do ciclo de vida genrico

Fonte: Adaptado de Pinto, 2002

possvel tambm encontrar ciclos de vida de projeto com mais de quatro etapas.
Cleland (1994), por exemplo, prope um ciclo com as seguintes cinco etapas: fase conceitual,
fase de definio, fase de produo ou aquisio, fase operacional e fase de despojamento.
King et al. apud Pinto (2002), por sua vez, prope o desdobramento do ciclo de vida em sete
fases: planejamento estratgico, planejamento do sistema, definio, design fsico,
implementao, avaliao e despojamento.
 42

Do exposto, pode-se concluir que no h um modelo de ciclo de vida que atenda

s necessidades de todo e qualquer projeto. No entanto, vrios modelos apresentados trazem
importantes contribuies no sentido de fornecer bases conceituais para a identificao de
deliverables e, conseqentemente, para a definio das fases do ciclo de vida do projeto,
permitindo aos gestores o controle sobre recursos e sobre os trabalhos a serem realizados,
possibilitando, tambm, a anlise de aspectos estratgicos e tticos relevantes (PINTO 2002).

Todas as etapas ou fases do modelo genrico interagem entre si ao longo do ciclo

de desenvolvimento do projeto. A interao pode ou no afetar as etapas anteriores ou
posteriores, dependendo do nvel de integrao entre elas. O PMBOK (2004) aborda sobre as
etapas do ciclo de vida no gerenciamento de projeto, na qual podem existir etapas mais
adequadas conforme o grau de integrao entre elas, das suas interaes e dos objetivos a que
atendam. No total, cinco etapas do gerenciamento de projetos podem ser identificadas: (i) o
processo de iniciao; (ii) o processo de planejamento; (iii) o processo de execuo; (iv) o
processo de monitoramento e controle; (v) e o processo de encerramento (CAVALIERI &
DINSMORE, 2006).

Analisando a interatividade entre os processos durante o ciclo de vida do projeto,

pode-se notar que o processo de controle possui uma interao ao longo do ciclo de vida com
todos os demais processos, j que utilizado para avaliar e controlar todas as etapas.

2.6 MTODOS DE GERENCIAMENTO DE PROJETO

A partir de meados da dcada de 90, devido a sua abrangncia e aplicao prtica

nas empresas, principalmente na rea de desenvolvimento de softwares, criaram-se modelos
de gerenciamento de projeto. O CMM (Capability Maturity Model ), desenvolvido pelo SEI
(Software Engineering Institute) em 1993, iniciou voltado para aplicaes na rea de
software, e evoluiu para demais reas como CMMI (Capability Maturity Model Integration)
em 2000. Para a aplicao especfica em projetos foi desenvolvido pelo GPM (German
Project Management Association) em 1997 e IPMA (International Project Management
Association) aprimorou em 2002, o modelo que foi chamado de Project Excellence Model.
A montagem de uma referncia em melhores prticas atravs do PMBoK (Project
Management Body of Knowledge), desenvolvido pelo PMI (Project Management Institute)
em 1998, tem-se destacado entre os mtodos de gesto de projetos, devido a sua abrangncia e
aplicao prtica nas empresas. Posteriormente, foram se desenvolvendo modelos de
 43

excelncia e maturidade em gerenciamento de projeto, tais como: PMMM (Project

Management Maturity Model), desenvolvido por Kerzner em 2002, e o OPM3
(Organization Project Management Maturity Model), desenvolvido pelo PMI em 2003
(REHDER, 2006). A Figura 12 mostra, de forma resumida, as caractersticas destes modelos
de gerenciamento.

Sigla Modelo Desenvolvido por Em Observaes

CMM Capability Maturity SEI Software Engineering 1993 Aplicao em

Model Institute Softwares

CMMI Capability Maturity SEI Software Engineering 2000 Modelos

Model Integration Institute Corporativos para
maturidade em GP.

PEM Project Excellence GPM German Project 1997 Excelncia de

Model Management Association Projetos

IPMA International Project 2002 Excelncia de

Management Association Projetos

PMBoK Project Management PMI Project Management 1998 Aplicao em

Body of Knowledge Institute Projetos
(Guide)

PMMM Project Management - Kerzner 2002 Modelo Corporativo

Maturity Model para maturidade de
projeto

OPM3 Organization Project PMI Project Management 2003 Modelo Corporativo

Institute para maturidade de
Management
projeto
Maturity Model

FIGURA 12: Evoluo dos principais modelos de aplicao, maturidade e excelncia de projeto

Fonte: Adaptado de Rehder, 2006

Baseado nos modelos descritos na Tabela 6 e na proposta deste trabalho, ou seja,

buscar uma metodologia para sistematizao do gerenciamento de projeto, a anlise dos
modelos ser realizada somente entre os modelos PMBoK e Project Excellence Model. Isso se
justifica j que os demais modelos esto focados exclusivamente no desenvolvimento de
software (CMM), ou na medio da excelncia e maturidade de projeto (CMMI, PMMM e
OPM3).
 44

O PMBoK (2004) apresenta uma compilao das melhores prticas no

desempenho do gerenciamento de projeto e direcionado para modelos de projetos no
integrados a um portflio de projetos, e sim de forma focada no projeto que est se
desenvolvendo propriamente dito, conforme PMI. As reas de conhecimento e grupos de
processo envolvidos na gesto de projetos, conforme modelado no PMBoK (2004) e
apresentada na Figura 13, d uma noo da abrangncia e complexidade do modelo
(REHDER, 2006).

reas de Conhecimento (9) Grupos de Processos (5)

Gerncia da Integrao de Projetos Iniciao

Gerncia do Escopo do Projeto Planejamento
Gerncia do Custo do Projeto Execuo
Gerncia de Tempos do Projeto Controle
Gerncia do Custo do Projeto Encerramento
Gerncia da Qualidade do Projeto
Gerncia de Recursos Humanos do
Projeto
Gerncia das Comunicaes do Projeto
Gerncia de Risco do Projeto
Gerncia das Aquisies do Projeto
FIGURA 13: Gesto de projetos conforme PMI

Fonte: Adaptado de Rehder, 2006

O Project Excellence Model (PEM) um modelo de excelncia e avaliao do

processo de gerenciamento de projeto. O PEM pode ser diretamente comparado ao PMBOK,
j que ambos definem como deve ser estruturado um projeto. O PEM de origem Europia e
algumas instituies utilizam-no como modelo na avaliao dos projetos; dentre elas
destacam-se a GPM (German Project Management), a IPMA (International Project
Management Association) e, mais recentemente, a EFQM (European Foundation for Quality
Management) (REHDER, 2006).

O PEM voltado ao resultado, com foco no cliente, liderana, gesto por

processos, desenvolvimento de pessoas, aprendizado, inovao e melhorias contnuas,
desenvolvimento de parcerias e responsabilidade social. A Figura 14 traz a estrutura do
modelo, conforme aplicado pelas instituies GPM e IPMA (REHDER, 2006). Alm da
 45

estrutura apresentada na Figura 14, o modelo construdo com base em 6 capacitadores: (i)
estratgia; (ii) liderana; (iii) gesto de pessoas; (iv) processos; (v) recursos; (vi) parcerias.

GESTO DO PROJETO RESULTADOS DO PROJETO

LIDERANA CLIENTES

OBJETIVOS DESEMPENHO
DO PROJETO PESSOAS PROCESSOS PESSOAS CHAVE E
RESULTADOS
DO PROJETO

RECURSOS TERCEIROS

INOVAO E APRENDIZADO

FIGURA 14: Estrutura do modelo Project Excellence Model (PME)

Fonte: Adaptado de Rehder, 2006

Comparativamente, o PMBoK um guia mais genrico, voltado ao gerenciamento

dos processos. Neste mtodo, todos os processos devem estar presentes quando da execuo
de um projeto para que se tenha sucesso. Alm disso, o conjunto de conhecimento tcnico
necessrio para o gerenciamento de projeto percorre as nove reas do conhecimento listadas
na Figura 21 (SOTILLE, 2005).

J o PEM, apesar de voltado avaliao de projetos, assume uma posio mais

estratgica sendo mais dinmico, pois est focado na gesto do projeto e seus resultados, bem
como na inovao e no aprendizado, ao contrrio do PMBoK, mais focado nos aspectos
organizacionais (REHDER, 2006).

Na Figura 15 apresentada uma comparao entre os modelos inter-relacionando

os capacitadores com as reas de conhecimento.
 46

Project Excellence Model

Capacitadores

Estratgia Liderana Gesto de Processos Recursos Parcerias

Pessoas

PMBoK
Gesto das reas do

Gesto de Gesto de Gesto de Gesto de Gesto de Gesto de

Conhecimento

escopo Integrao Comunica- Recursos Qualidade Aquisio

o Humanos Custos e
Riscos

FIGURA 15: Comparao entre os modelos de GP

Fonte: Adaptado de Rehder, 2006

A escolha do melhor modelo de gesto de projetos depende da aplicao, mas

pode pautar-se em trs fatores: (i) facilidade de implantao, (ii) disponibilidade de material
bibliogrfico para suporte terico (referncias), e (iii) aplicabilidade. A Figura 16 lista os
critrios mencionados e as caractersticas dos dois mtodos relativamente a eles. Na ltima
coluna da tabela, tem-se o resultado do comparativo para o estudo de caso a ser abordado
nesta dissertao. importante salientar a subjetividade da avaliao.

Critrios Classificao Resultado da

Escolha

Facilidade de PMBoK: Estrutura simplificada Nvel: Moderada PMBoK

Implantao
PEM: Estrutura complexa Nvel: Difcil

Referncias PMBoK: Vasta literatura sobre a base de conhecimento PMBoK

Nvel: Satisfatria

PEM: Literatura pouco difundida no Brasil Nvel:

Insatisfatria

Aplicao PMBoK: Voltada a qualquer tipo de projeto e focada no PMBoK

gerenciamento de projeto Nvel: Adequada

PEM: Voltada avaliao dos projetos utilizando critrios em

demasia Nvel: Inadequada

FIGURA 16: Critrios para auxiliar na escolha do melhor mtodo de gesto de projetos

Fonte: Autor

Baseado na avaliao na Figura 16, o mtodo a ser abordado neste trabalho ser
baseado no PMBoK (2004). Um dos critrios que teve um peso determinante na escolha foi
 47

questo da aplicao do mtodo, j que o PMBoK voltado a qualquer tipo de projeto. Alm
disso, o PMBoK possui, como principais pontos positivos, a sua abrangncia e aplicao
prtica, o que justifica sua crescente utilizao.

2.7 METODOLOGIA PMI PARA GERENCIAMENTO DE PROJETOS

O PMI uma Instituio sem fins lucrativos da rea de gerenciamento de projetos,

fundada no ano de 1969. O seu objetivo avanar a prtica, a cincia e a profisso do
gerenciamento de projetos, bem como melhorar o desempenho dos profissionais e as
organizaes nesta rea. O seu modelo de mbito genrico, sendo aplicvel ampla
diversidade de projetos (CAVALIERI & DINSMORE, 2006).

O PMI criou um guia para Gerenciamento de Projetos denominado PMBoK

(Project Management Body of Knowledge ou Corpo de Conhecimento em Gerenciamento de
Projetos). Trata-se de um guia de conhecimento e melhores prticas para a profisso de
gerncia de projetos. A base do conhecimento proposta apresenta uma definio de Projeto:
trata-se de um empreendimento nico, com incio e fim determinado, que utiliza recursos e
conduzido por pessoas, visando atingir objetivos pr-definidos (CAVALIERI & DINSMORE,
2006; PMBoK, 2004). Alm disso, projetos possuem outras caractersticas, tais como serem
feitos para um propsito, apresentarem interdependncias e serem progressivamente
elaborados.

De acordo com o PMBoK (2004), os processos de gerenciamento de projetos

podem ser classificados em 5 grupos, conforme descrito na seo 2.6. Conforme a Figura 17,
pode-se relacionar esses grupos ao ciclo PDCA (plan-do-check-act ou planejar-fazer-
monitorar-atuar), onde o grupo de processos de planejamento corresponde ao plan, o grupo
de processos de execuo corresponde ao componente do, o de monitoramento e controle
correspondem ao check e ao act, respectivamente. Os grupos de processos de iniciao e
de encerramento esto includos, uma vez que todo projeto por definio temporrio, ou
seja, com o incio e fim definidos. Como o gerenciamento de projetos possui natureza
integradora, exige a interao do grupo de processos de monitoramento e controle com todos
os aspectos dos outros grupos de processos (CAVALIERI & DINSMORE, 2006).
 48

Processo de
Monitoramento e Controle

Planejamento

Iniciao Encerramento

Planejar Fazer

A P

C D
Execuo
Agir Verificar

FIGURA 17 Mapeamento dos grupos de processos de GP e o ciclo PDCA

Fonte: Cavalieri & Dinsmore, 2006

Alm disso, os trs principais processos, de planejamento, execuo e

monitoramento, so recorrentes, isto , em certa fase do ciclo de vida do projeto ocorrem
interaes entre estes processos at a fase ser finalizada. A Figura 18 apresenta as ligaes
entre o grupo de processos em cada fase (SOTILLE, 2005; ZANONI, 2002).

INICIAO PLANEJAMENTO

CONTROLE EXECUO

ENCERRAMENTO

FIGURA 18 Processos de gerenciamento de projetos

Fonte: Sotille, 2005

O mtodo apresenta o processo de gerenciamento de projetos com dois tipos de

ciclo de vida: o ciclo de vida do projeto, que consiste no conjunto das diversas fases de um
 49

projeto, e o ciclo de vida do gerenciamento do projeto, que descreve o conjunto de processos

que devem ser seguidos para que o projeto seja bem gerenciado (CAVALIERI &
DINSMORE, 2006). A Figura 19 representa o relacionamento entre o ciclo de vida do
projeto, o ciclo de vida do gerenciamento do projeto e as reas do conhecimento em
gerenciamento de projetos.

FIGURA 19 Relacionamento entre os ciclos de vida do projeto, do gerenciamento de projeto e as reas

do conhecimento

Fonte: CAVALIERI & DINSMORE, 2006

De forma integrada, a Figura 20 mostra a viso geral dos cinco processos de

gerenciamento de projetos, apresentando as principais atividades, seqncias, inter-
relacionamento entre as atividades, bem como as nove reas do conhecimento que esto
definidas num gerenciamento de projeto (CAVALLIERE, 2006; KIRST, 2004; PMBoK,
2004; PRIKLADNICKY, 2003; SOTILLE, 2005).
 50

FIGURA 20: Mapeamento dos processos, reas do conhecimento e atividades do gerenciamento de

projetos conforme PMI

Fonte: Adaptado de Sotille, 2005

Cada processo se refere a um aspecto a ser considerado dentro da gerncia de

projetos; todos os processos devem estar presentes quando da execuo do projeto para que
este tenha sucesso. O conjunto de conhecimento tcnico de gerenciamento de projetos
necessrio para o perfeito desempenho da funo percorre as nove reas do conhecimento.
Estes conhecimentos so aplicados ao longo dos processos de forma matricial. Esta relao
entre as reas do conhecimento e os processos est representada na Figura 21.
 51

Gerenciamento de Iniciao / Execuo Controle Encerramento

Projetos Planejamento
Integrao Desenvolvimento Execuo do plano Gerenciamento
do plano de projeto de projeto integrado das
mudanas
Gerenciamento do Iniciao, Verificao e
Escopo planejamento, controle de
definio e mudanas
seqenciamento do
escopo
Gerenciamento do Estimativa de Controle de
tempo atividades Cronograma
Desenvolvimento
do cronograma
Gerenciamento de Planejamento dos Controle
Custo recursos Financeiro
Estimativa de
custos
Oramentos
Gerenciamento de Planejamento da Garantia da Controle de
Qualidade Qualidade Qualidade Qualidade
Gerenciamento de Planejamento Desenvolvimento
RH organizacional de Equipe
Montagem da
equipe
Gerenciamento de Planejamento da Distribuio da Relatrio de Encerramento
Comunicao comunicao informao Desempenho administrativo
Gerenciamento de Planejamento, Acompanhamento
Riscos Identificao, e controle de riscos
Qualificao,
Quantificao e
Respostas aos
riscos
Gerenciamento de Planejamento de Solicitao Encerramento de
Contratao contratos Seleo de contratos
(Aquisio) Planejamento da fornecedores
contratao Administrao de
Solicitao contratos
FIGURA 21: Relao entre reas de conhecimento e processos do gerenciamento de projetos

Fonte: Adaptado de Sotille, 2005

2.8 PRINCIPAIS REAS DO CONHECIMENTO

O PMI prope as reas de conhecimento com vistas ao gerenciamento de projetos,

aplicao de conhecimentos, habilidades, ferramentas e tcnicas e s atividades do projeto, a
fim de atender ao propsito para o qual ele est sendo executado. Tais reas so brevemente
introduzidas na seqncia, segundo o PMBoK (2004).
 52

A base de conhecimento para o gerenciamento de projetos se desdobra em nove

reas: (i) gerenciamento da integrao; (ii) gerenciamento do escopo; (iii) gerenciamento do
tempo; (iv) gerenciamento dos custos; (v) gerenciamento da qualidade; (vi) gerenciamento dos
recursos humanos; (vii) gerenciamento da comunicao; (viii) gerenciamento dos riscos; e (ix)
gerenciamento da aquisio. Todas estas reas esto intimamente interligadas e so
interdependentes, compondo um conjunto nico. As reas podem ser acrescidas de outros
gerenciamentos, a critrio do gerente do projeto. Nem todas as reas tm igual peso e
importncia, mas o critrio e o tipo de cada projeto determinam o valor e a intensidade do
esforo a ser despendido em cada gerenciamento (KIRST, 2004; PMBoK, 2004;
PRIKLADNICKI, 2004; VALERIANO, 2001).

2.8.1 Gerenciamento da Integrao

No gerenciamento da integrao, cada etapa do projeto deve ser posicionada de

maneira coerente e consistente, a fim de se obter o resultado final esperado. A idia que
cada etapa contribui substancialmente para o todo e, se conduzida de forma inadequada, pode
comprometer negativamente o resultado (PMBoK, 2004). Conforme Sotille (2005), o objetivo
principal deste processo realizar as negociaes dos conflitos entre objetivos e alternativas
do projeto com a finalidade de atingir ou exceder as necessidades e expectativas de todas as
partes interessadas.

A integrao envolve a tomada de decises diretamente ligadas aos objetivos do

projeto e aos processos de desenvolvimento e execuo do plano de gerenciamento do
projeto, assim como ao processo de controle de mudanas. O gerenciamento da integrao
abrange os processos de gerenciamento requeridos para que se assegure a coordenao entre
os distintos elementos do projeto (PMBoK, 2004).

Conforme PMBoK (2004), a integrao de responsabilidade do gerente ou lder

do projeto, que quem possui a viso do todo. Cabe a esta pessoa coordenar a elaborao do
Plano de Gerenciamento do Projeto, assim como sua execuo e modificaes que surjam
durante o desenvolvimento do projeto. A Figura 22 mostra os processos de gerenciamento da
integrao.
 53

Ativos de Desenvolver Termo Iniciador ou

Processos de Abertura do Patrocinador do
Projeto
Organizacionais Projeto

Fatores Desenvolver
Ambientais da Declarao do
Empresa Escopo Preliminar
do Projeto
Definio do
Escopo

Desenvolvimento Desenvolver Plano

Plano de de Gerenciamento
do Projeto
Gerenciamento do
Projeto

Orientar e
Gerenciar a
Execuo do
Projeto

Monitorar e
Controlar o
Trabalho do Projeto

Administrao de
Contrato
Controle Integrado
de Mudanas

Encerramento do
Contrato
Encerrar Projeto
Cliente

FIGURA 22 Processos de Gerenciamento da Integrao

Fonte: PMBoK, 2004

A gerncia da integrao aborda os processos necessrios para assegurar que os

diversos elementos do projeto estejam coordenados adequadamente. Isto inclui a
compensao entre objetivos e alternativas concorrentes, a fim de atingir as necessidades do
projeto. Os processos desta rea so: (i) desenvolvimento de um plano de projeto; (ii)
execuo do plano do projeto; e (iii) controle geral de mudanas (PMBoK, 2004; PRADO,
1998).

O desenvolvimento de um plano de projeto consiste em agregar os resultados dos

outros processos de planejamento em um documento (ou conjunto de documentos) consistente
que possa ser utilizado para guiar a execuo do projeto e documentar suas premissas e
decises. A partir do plano do projeto cria-se a linha de referncia (tambm chamada de
baseline ou linha de base). Ao longo do projeto o plano deve ser atualizado sempre que
houver uma alterao significativa ou for necessrio. O contedo do plano do projeto pode
 54

variar de acordo com o tamanho e com a complexidade do projeto, mas deve conter os itens
bsicos listados na Figura 23 (KIRST, 2004; PMBoK, 2004; PRADO, 1998).

Item Descrio

Project Charter ou Carta de Projeto
Escopo
Estrutura Analtica do Projeto (EAP)
Estimativa de custos
Estimativa de tempo (cronograma)
Recursos humanos (mo-de-obra)
Plano de riscos
FIGURA 23: Contedo bsico de um plano de projeto
Documento formal emitido por executivo externo
com autoridade sobre o projeto, reconhecendo a
existncia deste e a autoridade do gerente de
projeto. Deve conter os requisitos principais e
uma descrio breve do produto.
Descrio das atividades principais e os objetivos
do projeto.
Desmembramento do projeto em partes menores
definindo os entregveis de cada etapa.
Definio ou estimativa dos custos dos projetos
em termos de pessoal e aquisies.
Montagem da seqncia das atividades e tarefas
em ordem cronolgica definindo o tempo de
realizao e os responsveis.
Definio dos recursos do projeto que se tornaro
responsveis pela realizao das tarefas.
Levantamento dos riscos, restries e suposies
sobre as atividades ou tarefas, bem como
levantando as respostas planejadas em termos
quantitativos ou qualitativos sobre para cada um.

Fonte: Adaptado de Kirst, 2004

A execuo do plano de projeto o processo bsico de realizao do

gerenciamento da integrao do projeto. Consiste na coordenao e direcionamento das
interfaces tcnicas e organizacionais do projeto, pelo gerente e sua equipe de projeto. neste
processo que o produto criado. Suas entradas so o prprio plano do projeto, as polticas
organizacionais e as aes corretivas decorrentes das sadas dos diversos processos de
controle. As sadas deste processo so as prprias atividades de execuo do projeto e as
eventuais solicitaes de mudana (KIRST, 2004; PMBoK, 2004; PRADO, 1998).

O controle geral de mudanas o processo em que se busca influenciar os fatores

geradores de mudanas para assegurar que as mesmas sejam benficas, reconhecer que uma
mudana ocorreu e gerenci-la, a partir do momento de sua ocorrncia. Isto requer a
manuteno da integridade das medidas bsicas de desempenho, a garantia de que as
mudanas no escopo do produto esto refletidas no escopo do projeto e a coordenao das
 55

conseqncias das mudanas nas diferentes reas. A entrada principal do controle de

mudanas a solicitao de mudana, que pode ocorrer de diversas maneiras, de acordo com
o tamanho, complexidade do projeto e tipo de relacionamento entre as partes envolvidas. Sua
principal sada a atualizao do plano de projeto. Este processo tambm uma fonte
importante de lies para prximos projetos, sendo recomendvel o registro das lies
aprendidas (KERZNER, 2002; KIRST, 2003; PMBoK, 2004; PRADO, 1998).

2.8.2 Gerenciamento do Escopo

O gerenciamento do escopo tem como preocupao principal assegurar que o

projeto inclua todo o trabalho necessrio para realizar o seu produto de forma bem sucedida.
No entanto, deve se tomar cuidado para no desviar o projeto do seu objetivo, no agregar
atividades que no tenham relao com este nem esquecer atividades essenciais ao mesmo
(KIRTST, 2004; MAXIMIANO, 2002; PMBoK, 2004; PRADO, 1998; PRIKLADNICKY,
2003).

O escopo do produto difere do escopo do projeto. O primeiro refere-se s

funcionalidades e especificaes que devem ser includas no produto. O segundo, ao trabalho
necessrio para tornar o produto uma realidade, de acordo com as funcionalidades e
especificaes determinadas no escopo do produto. O escopo do produto pode permanecer
constante, enquanto o escopo do projeto se expande. J alteraes no escopo do produto
certamente causaro alteraes no escopo do projeto. A concluso do escopo do produto
mensurada contra as exigncias, geralmente determinadas pelo cliente. A concluso do escopo
mensurada contra o plano de projeto (PMBoK, 2004; PRADO, 1998).

Segundo Sotille (2005), o objetivo principal deste processo definir e controlar o

que deve e o que no deve estar incluso no projeto; neste caso, os seus limites de contorno.
Com base no PMBoK (2004), os processos inseridos no gerenciamento do escopo so: (i)
planejamento do escopo; (ii) definio do escopo; (iii) criao da EAP; (iv) verificao do
escopo; e (v) controle do escopo.

O planejamento do escopo um processo essencial do planejamento do projeto.

Consiste no desenvolvimento de uma declarao escrita do escopo, que servir de base para as
decises futuras do projeto e para o acordo entre a equipe do projeto e o cliente. A declarao
de escopo deve descrever as atividades principais do projeto, de modo que seja absolutamente
claro o que este se prope a desenvolver. Com isso, possvel determinar se uma atividade
nova, surgida posteriormente publicao da declarao do escopo, representa trabalho extra
 56

ou no. Deve tambm esclarecer os critrios para determinao se uma fase foi completada
com sucesso. Uma declarao completa de escopo inclui a justificativa do projeto, descrio
do produto e subprodutos e objetivos do projeto. Os objetivos do projeto devem ser,
preferencialmente, quantificveis. Objetivos no quantificveis possuem alto potencial para
gerar conflitos (PMBoK, 2004; PRADO, 1998).

A preparao de uma declarao do escopo detalhada do projeto essencial para o

sucesso do projeto e desenvolvida a partir das principais entregas, premissas e restries,
que so documentadas durante a iniciao do projeto, na declarao do escopo preliminar do
projeto. Durante o planejamento, o escopo do projeto definido e descrito mais
especificamente porque se conhecem mais informaes sobre o projeto. Necessidades, desejos
e expectativas das partes interessadas so analisados e convertidos em requisitos. A equipe do
projeto e outras partes interessadas, que possuem uma viso mais clara da declarao do
escopo preliminar do projeto, podem realizar e preparar as anlises (PMBoK, 2004).

A EAP (estrutura analtica do projeto) uma decomposio hierrquica orientada

entrega do trabalho a ser executado pela equipe do projeto, para atingir os objetivos do
projeto e criar as entregas necessrias. A EAP organiza e define o escopo total do projeto.
Nesta etapa, subdivide-se o trabalho do projeto em partes menores e mais facilmente
gerenciveis. Cada nvel descendente da EAP traz uma definio mais detalhada do trabalho
do projeto. possvel agendar, estimar custos, monitorar e controlar o trabalho planejado
contido nos componentes de nvel mais baixo, denominados pacotes de trabalho. Os
componentes que compem este processo auxiliam as partes interessadas a visualizar as
entregas do projeto (PMBoK, 2004).

A verificao do escopo o processo de execuo relacionado com a aceitao do

escopo pelas partes envolvidas. Para tal, necessria uma reviso dos resultados do trabalho e
do produto, com a inteno de verificar se tudo foi completado corretamente e de acordo com
as exigncias do cliente. Neste processo, so utilizadas ferramentas de inspeo, como
medies, auditorias e testes. A sada deste processo a aceitao formal do produto do
projeto ou da fase correspondente, podendo esta ser documentada ou no (PMBoK, 2004;
PRADO, 1998).

O processo de controle de mudanas no escopo consiste em analisar os fatores

geradores de mudana e garantir que as mesmas sejam benficas. Deve-se identificar se a
mudana ocorreu e gerenciar as mudanas que efetivamente devam ser levadas adiante. A
mudana do escopo est diretamente relacionada com a mudana nos demais processos de
 57

controle, tais como prazo, custo e qualidade. Sua entrada principal a solicitao de mudana,
que afeta a EAP. Sendo assim, deve haver um sistema de controle de mudanas de escopo
definindo os procedimentos pelo qual o escopo do projeto pode ser mudado (PMBoK, 2004;
PRADO, 1998).

2.8.3 Gerenciamento do Tempo

De todos os princpios de gerenciamento, o gerenciamento do tempo assume uma

importncia vital na implantao dos empreendimentos, por tratar-se de um recurso no
recupervel (PRADO, 1998). Para Miccoli (2004), o gerenciamento do tempo pode ser
considerado como uma corrida contra o calendrio pr-fixado, de planejamento anterior.

O gerenciamento do tempo em um projeto objetiva assegurar que o mesmo ser

executado dentro do prazo previsto (PMBoK, 2004; SOTILLE, 2005). Conforme o PMBoK
(2004), os processos associados so: (i) definio das atividades; (ii) seqenciamento das
atividades; (iii) estimativa de durao das atividades; (iv) desenvolvimento do cronograma; e
(v) controle do cronograma.

A definio das atividades envolve a sua identificao e documentao.

necessrio definir as atividades voltadas para o atingimento dos objetivos do projeto. A partir
da EAP, da declarao do escopo, das premissas e restries, se chega lista de atividades.
Esta deve incluir todas as atividades para execuo do projeto e sua descrio, sendo uma
extenso da EAP (PMBoK, 2004; PRIKLADNICKY, 2003).

O seqenciamento de atividades envolve a construo de um diagrama com as

relaes de dependncias entre as atividades. Isto permite desenvolver um cronograma
confivel. Os softwares atuais de gerenciamento de projeto incluem ferramentas de
seqenciamento baseadas nas melhores tcnicas para tal. Estas incluem, por exemplo, o
mtodo do diagrama de precedncia e o diagrama de flecha. O primeiro um mtodo de
construo de diagramas de rede que utiliza ns para indicar as atividades e setas para indicar
as dependncias. O segundo utiliza setas para representar as atividades e ns para representar
as dependncias. Em ambos, a sada um diagrama de rede que representa as atividades e
relacionamentos lgicos entre as mesmas (PMBoK, 2004; PRIKLADNICKY, 2003).

A estimativa de durao das atividades a avaliao do tempo provvel para

implementao da mesma. essencial que esta avaliao seja realizada ou aprovada por
algum com conhecimento a respeito da atividade. Como ferramentas, podem ser utilizadas
 58

analogias, avaliaes especializadas ou simulaes. A sada do processo a prpria estimativa

de durao aplicada a cada atividade (PMBOK, 2004).

O desenvolvimento do cronograma feito a partir do diagrama de rede, das

estimativas de durao das atividades e dos recursos requeridos. Esta etapa uma das
principais no processo de planejamento, pois consolida as informaes de outras reas. As
ferramentas mais utilizadas para tal incluem anlises matemticas ou de compresso da
durao (PMBoK, 2004).

As principais ferramentas de anlise matemtica calculam datas tericas de incio

e trmino das atividades, sem considerar limitaes no quadro de recursos, resultando em
perodos de tempo dentro dos quais podem ser realizadas as atividades. Em termos de
ferramentas de anlise matemtica, as tcnicas mais importantes so: (i) o mtodo do caminho
crtico (CPM Critical Path Method) e (ii) a tcnica de avaliao e reviso tcnica (PERT
Program Evaluation and Review Technique). O CPM utiliza tempos determinsticos para
estimar o tempo de durao das atividades. J o PERT utiliza mtodos probabilsticos para
determinao do tempo estimado das atividades. Atualmente, a designao PERT-CPM
utilizada genericamente como a designao da representao de projetos em redes, com
associao durao das atividades (KIRST, 2003; PMBoK, 2004; SLACK, 1997).

O cronograma do projeto possui as datas de incio e trmino esperadas para cada

atividade, podendo ser apresentado simplificadamente ou em detalhes. O cronograma
consolidado deve incluir a designao dos recursos previstos, o que exige, em paralelo, um
histograma de recursos. O formato mais conhecido para representao do cronograma o
grfico de Gantt, por ser de fcil interpretao. Ele mostra as datas de incio e trmino das
principais tarefas e duraes esperadas (KIRST, 2003; PMBoK, 2004; PRADO, 1998).

O controle do cronograma se desenvolve ao longo de todo o projeto, com o intuito

de avaliar e influenciar os fatores que geram alteraes no cronograma, de forma a garantir
que tais alteraes no afetem o andamento do projeto, e gerenciar as mudanas que
realmente ocorrem. um processo que deve estar fortemente ligado aos demais processos de
controle, gerando as atualizaes no cronograma (KIRST, 2003; PMBoK, 2004).

2.8.4 Gerenciamento do Custo

O gerenciamento do custo do projeto inclui os processos necessrios para

assegurar que o projeto seja concludo dentro do oramento aprovado (PMBoK, 2004;
 59

SOTILLE, 2005). Segundo PMBoK (2004), esse gerenciamento consiste de trs processos
bsicos: (i) estimativa de custos; (ii) oramentao de custos; (iii) controle de custos.

O processo de planejamento dos recursos permite determinar o tipo (pessoas,

mquinas e materiais) de recurso necessrio, bem como suas quantidades; a cada recurso
corresponde um custo. A EAP, as informaes histricas, os recursos disponveis e a poltica
organizacional so as principais entradas do processo. Com ferramentas como avaliaes
especializadas e anlise de alternativas, chega-se descrio dos recursos requeridos e suas
quantidades, sendo o principal resultado deste processo (PMBoK, 2004; PRADO, 1998).

A estimativa de custo permite avaliar com antecedncia o custo do projeto. Para

tal, importante identificar e considerar mais de uma alternativa de custo. Quanto menos
informaes estiverem disponveis a respeito do projeto no momento da estimativa, mais
arriscada ela ser. As estimativas de custo podem ser utilizadas com finalidades to diferentes
como determinar a viabilidade de um projeto ou predizer seu custo final. Em cada caso, um
certo grau de variabilidade adicionado estimativa para indicar a probabilidade de superar
ou subestimar o custo. Uma estimativa de custos pode ser elaborada atravs das tcnicas
apresentadas na Figura 24.

Modelo Descrio

Analogia (Top dowm Conhecendo o custo de um projeto similar, define-se o oramento por
ou de cima para proporo direta de sua carga de trabalho, medida na unidade mais
baixo) apropriada a cada caso. H de se levar em conta, neste caso, o valor temporal
do dinheiro, corrigindo valores por algum ndice confivel.

Paramtrico Utilizam-se caractersticas do projeto em modelos matemticos para prever

seus custos. As variveis da frmula paramtrica quase sempre exigem
especificaes detalhadas do produto, aumentando a preciso da estimativa
com a preciso das especificaes.

Bottom Up (de baixo As atividades previstas so detalhadas e seu custo individual estimado.
para cima) Depois, os custos so sumarizados para obter o custo total estimado do
projeto. Este tipo de estimativa envolve mais trabalho, pois necessita da
abertura das atividades e conhecimento do seu custo unitrio.

FIGURA 24: Tcnicas para estimativas de custos

Fonte: Adaptado de Kirst, 2004

 60

A oramentao dos custos envolve a alocao dos custos globais aos respectivos
itens de trabalho, a fim de estabelecer uma linha de base de custos que permitir medir o
desempenho do projeto. Esta linha de base elaborada com as estimativas de custo, baseadas
na EAP e no cronograma do projeto. A linha de base pode ser demonstrada graficamente
atravs de uma curva S. A utilizao da curva S decorre da constatao que o
desenvolvimento de servios complexos, envolvendo vrios grupos de pessoas, no se d de
forma linear, e sim de acordo com uma curva de Gauss. O mesmo ocorre com os custos e o
trabalho de um projeto. O valor apropriado inicialmente pequeno, aumentando
progressivamente at atingir um mximo, que geralmente ocorre entre 50% e 60% do tempo
do projeto. Da comea novamente a diminuir, at o final do trabalho ou desembolso final
(KIRST, 2004; PMBoK, 2004).

O controle de custos o processo que monitora os fatores de mudana para que os

mesmos sejam benficos em termos de custo. Outro objetivo identificar quando as metas de
custo so alteradas e atualizar o desembolso real. Isto inclui impedir que as mudanas
incorretas ou no autorizadas sejam executadas, informar as partes envolvidas das mudanas
autorizadas e monitorar o desempenho do plano para detectar as variaes. Sua sada a
estimativa de custo revisada, que deve ser comparada com a linha de base para monitorar o
desempenho do projeto e determinar os ajustes nos outros aspectos do projeto, se necessrio
(PMBoK, 2004).

2.8.5 Gerenciamento da Qualidade

Os conceitos bsicos relacionados ao gerenciamento da qualidade adotados

pelo PMI so compatveis com a abordagem da ISO (International Organization for
Standardization) e com prticas estabelecidas de gesto da qualidade propostas pelos
principais autores da rea e documentado por Pyzdek (2000). O gerenciamento da qualidade
do projeto deve ser direcionado tanto para o gerenciamento do projeto como para o produto
ou servio resultante do mesmo.

Segundo o PMBoK (2004), um projeto com qualidade aquele concludo em

conformidade com os requisitos, especificaes e adequao ao uso, devendo satisfazer as
necessidades do cliente. O objetivo principal garantir que o projeto satisfaa as exigncias
para as quais foi contratado ou requisitado (CRUZ et al., 2006; SOTILLE, 2005). Essa
abordagem baseada na premissa de que o gerente do projeto deve detalhar as necessidades e
expectativas dos usurios em relao ao projeto, especific-las formalmente e, aps, valid-las
 61

com os clientes. Desta forma o gerenciamento do projeto ser concludo alcanado a

qualidade desejada do produto final e garantindo a satisfao dos clientes.

O planejamento da qualidade considerado, dentre os processos de planejamento,

um processo facilitador. Permite determinar quais padres de qualidade so relevantes para o
projeto e como satisfaz-los. As principais entradas para o planejamento da qualidade so a
poltica de qualidade da organizao, a declarao de escopo, padres e regulamentaes e a
descrio do produto. Como ferramentas, podem ser utilizadas tcnicas como fluxograma de
sistema ou outro tipo, que mostre como os vrios elementos de um sistema se relacionam. O
resultado do processo o plano de gerenciamento da qualidade, onde descrito como a
gerncia do projeto implementar sua poltica de qualidade (KIRST, 2004; PMBoK, 2004).

O processo de garantia da qualidade consiste nas atividades do sistema que

buscam assegurar que o projeto atender os padres relevantes de qualidade. Sua entrada o
plano de gerncia da qualidade e as ferramentas so semelhantes s do planejamento da
qualidade. A sada deste processo a melhoria da qualidade, incluindo as aes para aumentar
a efetividade e eficincia do projeto (PMBoK, 2004).

O controle de qualidade envolve o monitoramento dos resultados especficos do

projeto para determinar se os mesmos esto de acordo com os padres relevantes. Em caso de
desacordo, o controle da qualidade permite identificar como eliminar as causas de resultados
no satisfatrios, podendo utilizar para tal ferramenta como inspeo, grficos de controle,
diagramas de Pareto e fluxograma. As sadas so as melhorias da qualidade, decises de
aceitao, retrabalho e ajustes no processo, se necessrio (NBR 10006, 2000; PMBoK, 2004;
PRADO, 1998).

2.8.6 Gerenciamento dos Recursos Humanos

O gerenciamento de recursos humanos do projeto inclui os processos requeridos

para possibilitar o uso mais efetivo e melhor aproveitamento das pessoas envolvidas com o
projeto (PMBoK, 2004; SOTILLE, 2005). Este se subdivide em quatro processos (PMBoK,
2004): (i) planejamento de recursos humanos; (ii) contratao ou mobilizao da equipe; (iii)
desenvolvimento da equipe; e (iv) gerenciamento da equipe.

O processo de planejamento de recursos destina-se a identificar e documentar as

responsabilidades e as relaes hierrquicas entre as pessoas do projeto. Como as pessoas, ou
grupo, normalmente fazem parte de uma estrutura organizacional, elas devem estar sempre
vinculadas s interfaces organizacionais. O plano de gerenciamento de equipe, o organograma
 62

do projeto, bem como as atribuies de responsabilidades, so os produtos deste processo

(PMBoK, 2004; PRIKLADNICKY, 2003; VARGAS, 2002).

O processo de contratao da equipe envolve recrutar os recursos humanos

necessrios para os trabalhos do projeto. Este recrutamento pode ser realizado de forma
interna ou externa organizao. A lista dos membros de projetos e suas funes so um dos
produtos deste processo. Alm da contratao dos membros, inclui tambm a mobilizao do
grupo ou equipe para trabalhar com foco no atingimento das metas do projeto (PMBoK, 2004;
PRIKLADNICKY, 2003; VARGAS, 2002).

O processo de desenvolvimento da equipe inclui no somente desenvolver as

habilidades individuais de cada membro do time, como tambm as habilidades do grupo para
funcionar como um time. Treinamento, polticas de recompensa e atividades em grupo so as
principais ferramentas desse processo, visando sempre as melhorias no desempenho do grupo
(PMBoK, 2004; PRIKLADNICKY, 2003; VARGAS, 2002).

O processo de gerenciamento da equipe designa-se avaliar e coordenar as

mudanas, aes corretivas e preventivas, atualizaes na estrutura organizacional, e atualizar
o plano de gerenciamento do projeto. Para isto, algumas ferramentas e tcnicas, tais como
observaes e conversas, avaliao de desempenho, gerenciamento do conflito e registro de
problemas, entre outras, so utilizadas neste processo (PMBoK, 2004).

2.8.7 Gerenciamento das Comunicaes

O gerenciamento das comunicaes do projeto inclui os processos requeridos para

garantir a gerao apropriada e oportuna, a coleta, a distribuio, o armazenamento e o
controle bsico das informaes do projeto. Fornece ligaes crticas entre pessoas, idias e
informaes que so necessrias para o sucesso do projeto. Todos os envolvidos no projeto
devem estar preparados para enviar e receber comunicaes na linguagem do projeto. Este
gerenciamento divide-se em quatro processos: (i) planejamento das comunicaes; (ii)
distribuio das informaes; (iii) relatrios de desempenho; e (iv) encerramento
administrativo (PMBoK, 2004; SOTILLE, 2005).

O processo das comunicaes determina a necessidade de informaes de cada

envolvido no projeto. Determina, tambm, como essa informao ser levada at o envolvido
e qual ser o nvel de detalhe dado a cada informao (PMBoK, 2004; PRIKLADNICKY,
2003; VARGAS, 2002).
 63

O processo de distribuio das informaes torna disponveis as informaes aos

envolvidos no projeto. Estas informaes fazem com que todos recebam, no momento certo, a
informao a eles destinada (PMBoK, 2004; VARGAS, 2002).

O processo de confeco dos relatrios de desempenho e sua disseminao

relativa ao desempenho do projeto servem para que os envolvidos possam avaliar como os
recursos esto sendo utilizados para atingir os objetivos do projeto (PMBoK, 2004;
VARGAS, 2002).

O encerramento administrativo um processo que verifica e documenta os

resultados obtidos em uma determinada fase ou entrega, visando formalizar o fechamento
junto aos envolvidos. Inclui avaliaes dos resultados obtidos, de modo a confirmar que o
projeto reflete as especificaes desejadas, analisando o sucesso e a efetividade do projeto. No
encerramento administrativo faz-se o arquivamento das informaes do projeto para futuro
uso (PMBoK, 2004; VARGAS, 2002).

2.8.8 Gerenciamento dos Riscos

O Gerenciamento dos Riscos um processo sistemtico de definio, anlise e

resposta aos riscos do projeto cujo objetivo maximizar os eventos positivos e minimizar as
conseqncias dos eventos negativos (PMBoK, 2004; SOTILLE, 2005).

O processo de gerenciamento de riscos deve levar em considerao os fatores

ambientais da empresa, os processos organizacionais, a declarao do escopo do projeto e o
plano de gerenciamento do projeto. A ferramenta utilizada no levantamento destes dados a
anlise e reunies de planejamento. Ao final deste processo, dever ser criado o plano de
gerenciamento de riscos, dando origem aos demais processos (PMBoK, 2004).

O processo de identificao dos riscos tem como objetivo determinar quais riscos
so mais provveis de afetar o projeto e documentar as caractersticas de cada um. Para isto
utilizam-se algumas ferramentas e tcnicas, tais como, revises da documentao, coleta de
informaes, anlise das listas de verificao e de premissas. sada deste processo a
listagem ou registro dos riscos (PMBoK, 2004).

No processo de anlise qualitativa devero ser usadas algumas tcnicas e

ferramentas para avaliar e qualificar o levantamento dos riscos criados na etapa anterior.
Nesta avaliao dever se levantar a probabilidade e impacto de cada risco, podendo usar uma
matriz de probabilidade e impacto. O levantamento destes dados pode ser subjetivo, porm
necessrio ser montado pela equipe do projeto, ou pelo levantamento de ocorrncias em
 64

outros projetos, definindo, neste caso, a sua probabilidade de ocorrer ao projeto especfico.
Adicionalmente, dever se avaliar a qualidade dos dados sobre os riscos, classific-los ou
dividi-los por categoria, e avaliar a urgncia de cada risco abordado (PMBoK, 2004).

O processo de anlise quantitativa de riscos realizado nos riscos que foram

priorizados pelo processo de anlise qualitativa, por afetarem de forma potencial e
significativamente as demandas do projeto. Neste processo analisa-se o efeito dos eventos de
risco e atribui-se a eles uma classificao numrica. Trata-se, assim, de uma abordagem
quantitativa para a tomada de decises na presena de incertezas. Algumas tcnicas ou
ferramentas podem ser usadas, tais como a simulao de Monte Carlo e a anlise da rvore de
deciso. A resposta deste processo dever ser uma anlise probabilstica do projeto, tal como
a probabilidade de atingimento dos objetivos em termos de custo e tempo, uma lista de
prioridade de riscos quantificados e a tendncia dos resultados desta anlise (PMBoK, 2004).

Para o processo de desenvolvimento das respostas aos riscos, devem-se definir as

melhorias necessrias, as estratgias para o aproveitamento de oportunidade e resposta s
ameaas. As estratgias mais usadas para as ameaas so dos tipos preveno, transferncia
ou mitigao dos riscos. Para as oportunidades, as estratgias mais usadas so do tipo
exploratrio, compartilhamento ou melhoria (PMBoK, 2004).

O planejamento de respostas a riscos o processo de desenvolver opes e

determinar aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do
projeto. Neste, deve-se incluir a identificao e designao de uma ou mais pessoas que iro
assumir a responsabilidade sobre cada resposta dos riscos definidos. Este processo aborda os
riscos de acordo com a sua prioridade, inserindo recursos e atividades no oramento,
cronograma e plano de gerenciamento do projeto, quando necessrio (PMBoK, 2004,
VARGAS, 2002).

O monitoramento e controle de riscos o processo de identificao, anlise e

planejamento dos riscos recm-surgidos. Adicionalmente, dever se fazer o acompanhamento
dos riscos identificados e dos que esto na lista de observao, a reanlise dos riscos
existentes, o monitoramento das condies de acionamento de planos de contingncia, o
monitoramento dos riscos residuais e a reviso da execuo das respostas aos riscos bem
como a avaliao da sua eficcia. O processo de monitoramento e controle de riscos aplica
tcnicas, como a anlise das tendncias e da variao com relao ao custo e cronograma
alvo, que exigem o uso dos dados de desempenho gerados durante a execuo do projeto.
Tambm este processo executado ao longo de toda a vida do projeto (PMBoK, 2004).
 65

2.8.9 Gerenciamento de Aquisies

O gerenciamento das aquisies do projeto inclui os processos necessrios

obteno de bens e servios organizao executora. O gerenciamento de aquisies
subdivide-se em seis processos: (i) planejamento das aquisies; (ii) preparao das
aquisies; (iii) obteno de propostas; (iv) seleo de fornecedores; (v) administrao de
contratos; e (vi) encerramento dos contratos (PMBoK, 2004; SOTILLE, 2005).

O processo de planejamento das aquisies destina-se a identificar quais

necessidades do projeto so mais bem realizadas por elementos externos organizao. Este
processo descreve como os demais processos de aquisio sero executados, respondendo a
questes como: (i) tipos de contratos a serem utilizados; (ii) responsabilidades pelas
aquisies; (iii) formas de administrao dos fornecedores; (iv) padronizao de processos de
aquisio; e (v) a relao das aquisies com demais aspectos do projeto (PMBoK, 2004;
VARGAS, 2002).

O processo de preparao das aquisies envolve a prpria preparao dos

documentos necessrios para suportar todo o processo de requisio, incluindo os critrios de
avaliao de fornecedores, protegendo a organizao e o sucesso do projeto. essencial
especificar corretamente o trabalho, delinear a forma de resposta desejada e os critrios de
avaliao, de forma a permitir a comparao entre as propostas. O formato de contratao
afetado pelo tipo de controle que a organizao contratante pretende exercer sobre o mesmo
(KIRST, 2004; PMBoK, 2004).

O processo de obteno de propostas consiste em obter propostas de fornecimento

conforme apropriado a cada caso, como por exemplo, cotaes de preo, cartas-convite e
licitao. essencial possuir para tal os documentos de aquisio e a lista de fornecedores
qualificados para cada item a ser adquirido. Como resultado obtido as propostas,
descrevendo a capacidade e possibilidade de cada cotante fornecer o item desejado (PMBoK,
2004; VARGAS, 2002).

O processo de seleo de fornecedores um processo que seleciona as cotaes e

as propostas recebidas, avaliando-as segundo critrios definidos no plano de suprimentos.
Esta anlise no simples, envolvendo o balano entre fatores comerciais e o atendimento a
itens tcnicos. O menor preo pode no ser o mais adequado, se o fornecedor no atender o
prazo ou os nveis tcnicos desejados. As ferramentas utilizadas neste processo envolvem
tcnicas de anlise de propostas, conforme critrios de avaliao, e negociao, devendo
 66

garantir o atendimento completo aos requerimentos do projeto em custo, prazo e qualidade.

Os aspectos legais devem ser considerados na negociao. Como sada deste processo, as
propostas selecionadas so, nesta etapa, convertidas em contratos (KIRST, 2004; PMBoK,
2004; VARGAS, 2002).

O processo de administrao dos contratos garante o desempenho dos

fornecedores, verificando se os mesmos esto em conformidade com os parmetros
estabelecidos no contrato. neste processo que os pagamentos aos fornecedores so liberados
(PMBoK, 2004; VARGAS, 2002).

O ltimo processo, encerramento do contrato, verifica e documenta os resultados

obtidos em uma determinada fase, ou entrega de um contrato, visando formalizar seu
fechamento. Inclui avaliaes dos resultados obtidos de modo a confirmar que o projeto
reflita as especificaes desejadas para aceitao formal. Nessa fase, os contratos so
liquidados e as informaes para uso futuro, arquivadas (PMBoK, 2004; VARGAS, 2002).
 67

3 MODELO PROPOSTO

3.1 CONSIDERAES INICIAIS

A busca incessante das empresas pela manuteno e crescimento na fatia de

mercado uma marca forte no mundo dos negcios, principalmente na indstria. A forma
encontrada para isto atravs da inovao, da satisfao dos clientes no que se refere
rapidez, preo, atendimento e qualidade, objetivando sempre o lucro.

O gerenciamento de projeto enquadra-se neste contexto como uma prtica ou

ferramenta que, quando aplicada de forma adequada e sistematizada, ajuda na concluso e
conquista dos objetivos dos projetos que podem ser oriundos de clientes, ou na busca deles.

Sob um ponto de vista micro, o gerenciamento de projeto ajuda a otimizar a

utilizao dos recursos que, por conseqncia, trar uma reduo do tempo de
desenvolvimento e reduo dos custos, aumentando a confiabilidade dos resultados. Isso, por
sua vez, implicar em um aumento na qualidade do projeto e na satisfao do cliente.

Esta dissertao prope a integrao do conceito de gerenciamento de projeto em

uma indstria de desenvolvimento e produo de componentes eletrnicos. Este captulo tem
como objetivo descrever a forma utilizada para analisar o processo atual e propor alternativas
para melhorar o processo escolhido na empresa analisada.

3.2 APRESENTAO DA EMPRESA

A empresa analisada uma multinacional com sede em Munique na Alemanha,

com plantas em quatro continentes. Em 2005/2006 obteve um faturamento global de 1,3
bilhes. A empresa produz componentes eletrnicos para a maioria das aplicaes e lder no
mercado nacional na fabricao de um dos seus produtos. Est sediada na regio da Grande
Porto Alegre-RS, e a nica planta fabril na Amrica Latina que produz este tipo especfico
de componente eletrnico. Esta empresa, ser referenciada como EdB. No Brasil, possui
atualmente 1500 colaboradores e em 2006 obteve um faturamento de US$ 130 milhes, sendo
40% oriundo de transaes comerciais no mercado interno.
 68

Os clientes em geral so empresas que fabricam bens durveis, tais como

automveis, televisores, mquinas de lavar roupa e geladeiras. Seus produtos so, em sua
maioria, commodities e geralmente so fabricados em grandes volumes por pedido.

As atividades da EdB so divididas em duas mini unidades, conforme a aplicao

e a tecnologia usada em seus produtos: (i) Unidade I - KO; (ii) Unidade II - FK. O estudo de
caso aqui abordado teve lugar nas duas unidades, pois o processo de desenvolvimento de
produto corporativo e deve ser desenvolvido de forma similar entre as reas dedicadas a este
processo.

O organograma apresentado na Figura 25 mostra de forma simplificada uma das

unidades (sendo similar a estrutura para a outra unidade). O topo da pirmide a mesma, pois
a diretoria coorporativa. Para cada rea dentro do organograma so definidas as atividades e
responsabilidades designadas a cada colaborador, dentro da sua respectiva rea e
competncia.

Diretoria
Dir. Superintendente

Diretoria Diretoria
Diretor Financeiro Diretor Vendas

Gerente Unid. -FK

Gerncias das Gerente Unid. -KO
Gerente Geral
reas de Apoio Gerente Geral

... ...
Marketing PM P&D PD Fab. Folhas MF Serv. Cliente CS
Ger. Marketing Ger. Engenharia Ger. Fab. Folhas Ger. Logstica

Qualidade QA Manuteno TS Fabricao MC Suprimento BA

Ger. Qualidade Ger. Serv. Tcnicos Ger. Produo Ger. Suprimentos

FIGURA 25 - Organograma simplificado da unidade analisada

Fonte: Empresa analisada, 2006

Para aperfeioar seu desempenho, a EdB adota o gerenciamento de atividades por

processos. Em relao estrutura de avaliao departamental, esta estrutura tem como
vantagem possibilitar a medio de forma mais eficiente percepo do cliente em relao a
determinado produto ou servio. A preferncia pela gesto por processos justifica-se visto que
o cliente atendido por processos que tramitam por diversos departamentos e, apesar dos
 69

departamentos poderem apresentar resultados isolados satisfatrios, o cliente avaliar o

resultado que percebido pelo desempenho do elo mais fraco. Esta percepo de anlise
condizente com os requisitos da norma ISO/TS 16949:2002 e ISO 14000, pela qual a EdB
certificada. A Figura 26 esquematiza o macro fluxo de processos da empresa.

A matriz na Figura 27 possibilita uma visualizao da interao entre os

departamentos onde esto estabelecidos os processos, em destaque o processo de projeto e
desenvolvimento. Na matriz tambm so apresentadas as reas da empresa, bem como os
indicadores utilizados para gerenciamento da organizao.

Sistema de Gesto da Qualidade da EPCOS do Brasil Ltda.

Responsabilidade da Administrao

Anlise crtica
pela Direo

GPD Leitung

SGQT Budget

Comunicao
de cliente
G e sto de re cu rsos

Recrutamento
N ecessidad e e R ecurso s

e Seleo/ Comunicao

Sa tisfao d os clien te s
Avaliao Reclamao
Treinamento/ Interna da de clientes
Motivao
satisfao
de clientes
C lien te s

C lie ntes
Controle de
Infra-estrutura produto
Auditoria no-
interna conforme

Ao
corretiva e
preventiva
Comunicao
de cliente
Melhoria
contnua Medio, Anlise
e Melhoria

Anlise
Crtica dos Equipamentos
requisitos do de inspeo, Expedio/
Transporte
Cliente medio e Faturamento
ensaios.

Projeto e
Logstica Produo
desenvolvimento

PDA Aquisio Manuteno Homologao

Peridica

Realizao do produto

FIGURA 26 Macro fluxo dos processos da Empresa Analisada

Fonte: Empresa analisada, 2006
 70

Responsvel INDICADORES
ENGENHARIA Tempo de execuo de projetos /Tempo Planejado 1 1 1 1
ENGENHARIA N de projetos de desenvolvimento 2 2 2
ENGENHARIA N de projetos validados 2 2 2

Projeto e desenvolvimento

Anlise Crtica Alta

Melhoria Contnua
Administrao
PROCESSOS

SGQT
Core Gerenciamento
DIRETORIA
MARKETING
ENGENHARIA
FBRICA FOLHA
FABRICAO
SERVIOES TCNICOS
QUALIDADE
SERVIOS AO CLIENTE
SUPRIMENTOS
CONTROLADORIA
INFORMTICA
ESTOQUE CENTRAL
COMPRAS
RECURSOS HUMANOS
INFRA-ESTRUTURA
GESTO DA QUALIDADE
SETOR EPCOS

Processos
Relao forte 2 Eficincia
Relao mdia 1 Eficcia
Relao fraca
Process owner

FIGURA 27 Matriz de correlao entre reas, indicadores e processos

Fonte: Empresa analisada, 2006

A empresa utiliza, para visualizao dos seus processos, o mtodo SIPOC

(Supplier = Fornecedor / Input =Entrada / Process = Processo / Output = Sada / Customer =
Cliente). O SIPOC aplicado ao processo abordado neste estudo de caso, de projeto e
desenvolvimento, pode ser visualizado na Figura 28.
 71

FIGURA 28 Viso do processo de projeto e desenvolvimento segundo o mtodo SIPOC

Fonte: Empresa analisada, 2006

Os indicadores utilizados pela empresa para avaliar seu desempenho no processo

de projeto e desenvolvimento so trs: (i) tempo de execuo de projetos / tempo planejado,
(ii) nmero de projetos de desenvolvimento e (iii) nmero de projetos validados. Analisando
esses indicadores, pode-se notar que no h uma relao clara entre eles e a estratgia da
empresa, que resumidamente est estruturada em trs pilares: (i) lucro; (ii) inovao; e (iii)
satisfao do cliente. Relacionando os indicadores com a estratgia, nota-se que os
indicadores focam basicamente na qualidade do projeto e no na estratgia da empresa.

3.3 FATORES MOTIVADORES DO PROJETO

Diante da atual conjuntura de mercado e a situao da empresa com relao

perda de mercado domstico e de exportao (principalmente pela falta de inovao, rapidez e
preo nos seus novos produtos), buscou-se uma metodologia como forma de auxiliar na
minimizao destes fatores.

Outro aspecto importante a questo da falta de recursos, ou melhor, a falta de

priorizao dos projetos decorrente de uma m gesto da carteira de projetos, gerando uma
grande demanda para poucos recursos. Este efeito gerado porque os novos projetos no so
avaliados de uma forma crtica com relao ao seu grau de importncia (critrios baseados na
estratgia); parte-se do pressuposto que a demanda gerada dever ser atendida na sua
plenitude, no se priorizando os projetos.

Um outro fator importante motivador deste trabalho a sistematizao

(padronizao) do processo de desenvolvimento, a qual no existia at o momento. Uma das
conseqncias era o aumento do tempo na realizao dos projetos gerando alguns
 72

retrabalhos. Outro ponto importante era a falta de planejamento criterioso para cada projeto,
o que afetava diretamente na qualidade dos mesmos.

Adicionalmente aos fatores acima, j se tinha verificado a no valorizao dos

custos reais dos projetos, principalmente com relao ao custo de pessoal. Um dos efeitos
disso era a falta de informao para uma tomada de deciso, por exemplo, no caso de uma
definio de investimento e priorizao da carteira de projetos.

Alm da busca de um mtodo de gerenciamento de projetos, busca-se tambm

nesse estudo uma melhoria na comunicao. Este fator sempre foi considerado fraco na
empresa analisada sobre o ponto de vista da divulgao das informaes, armazenamento dos
documentos e inter-relacionamento entre as reas envolvidas de uma forma geral.

3.4 DESENVOLVIMENTO DA PESQUISA

O objetivo da presente seo descrever a metodologia empregada para a

conduo das atividades de pesquisa. O captulo procura tambm fazer uma descrio de cada
fase do processo de investigao conforme metodologia da pesquisa-ao, j mencionada na
seo 1.4.

O papel da metodologia de pesquisa no apenas o de avaliar os diversos

mtodos de investigao existentes, mas tambm guiar o processo de pesquisa esclarecendo
cada deciso necessria s diversas etapas do trabalho por meio de princpios de cientificidade
(PAIVA, 2000).

Assim, a forma como o observador interage com o ambiente pesquisado para a

deteco dos problemas ou para a proposio de solues, bem como a maneira que formula
as hipteses, adquire e processa os dados, devem estar norteadas por um mtodo especfico
que se enquadre natureza da pesquisa e realidade investigada. Desse modo, diante do
exposto, escolheu-se a metodologia da pesquisa-ao para a conduo das atividades deste
trabalho.

As fases da pesquisa-ao a serem usadas nesta pesquisa so: (i) fase exploratria;
(ii) fase principal; (iii) fase de ao; e (iv) fase de avaliao (THIOLLENT, 2002). Nas
prximas sees sero apresentados os fundamentos de cada fase.

A metodologia da pesquisa-ao foi selecionada por se ajustar aos dois objetivos

desta pesquisa, a saber: (i) resolver os problemas relativos ao processo de desenvolvimento da
 73

empresa analisada, e (ii) aprofundar o conhecimento dos meios de se organizar o processo de

desenvolvimento atravs do gerenciamento de projetos utilizando as melhores prticas
descritas no PMBOK (2004). Tal metodologia orienta o modo de se fazer a interao entre o
pesquisador e as pessoas envolvidas no problema e tambm como transformar o
conhecimento emprico, aplicado na resoluo de um problema prtico, em conhecimento
acadmico.

3.4.1 Fase Exploratria

A fase exploratria a etapa na qual se faz um diagnstico da realidade a ser

pesquisada. O objetivo desta fase aumentar o conhecimento a respeito de um fenmeno sem
comprovar hipteses (THIOLLENT, 2002). Faz-se um levantamento das informaes,
procurando investigar os problemas vivenciados, as expectativas e caractersticas do grupo,
assim como o seu mtodo de trabalho. A partir da, so traados os objetivos da pesquisa, o
planejamento das aes e como se dar a interao entre o pesquisador e as pessoas
envolvidas.

Desta forma, ao se aprofundar um processo que se deseja investigar, procura-se

seguir as etapas iniciais proposta pela metodologia, fazendo-se assim um levantamento prvio
do ambiente. No captulo 4 estaro detalhados esses aspectos e a maneira como se deu a
participao dos membros da empresa abordada no estudo de caso na resoluo das questes.

Direcionado fase exploratria, o pesquisador dever buscar todas as informaes

pertinentes ao processo a ser analisado, podendo ser atravs de bancos de dados, dilogos com
especialistas, e tambm atravs de uma pesquisa direcionada ao grupo que est envolvido
diretamente com o processo a ser estudado.

A busca das pessoas-chave, neste caso, especialistas que trabalham diretamente

com o processo a ser pesquisado, muito importante para que se possa fazer um levantamento
completo. Porm, direcionar a pesquisa somente aos especialistas pode de alguma forma
enviesar a coleta de dados. Ou seja, o entendimento sobre o processo dever ser realizado
diretamente com os especialistas, porm a busca de outras opinies, como a dos usurios do
processo, tambm faz parte da pesquisa, principalmente se o objetivo obter um diagnstico
correto dos problemas.

Aps o estudo sobre o processo e o entendimento de suas caractersticas, o

pesquisador dever criar um mtodo de trabalho, definindo, para tanto, a equipe de trabalho,
 74

as responsabilidades, as etapas marco, a freqncia e durao dos encontros com o grupo

diretamente envolvido.

De posse de todos os itens acima definidos, e principalmente das informaes

coletadas durante a fase exploratria da pesquisa, o pesquisador, em conjunto com a equipe de
trabalho, seguir para as demais fases subseqentes definidas pela metodologia da pesquisa-
ao.

3.4.2 Fase Principal

Aps a fase exploratria, entra-se na fase principal que tem como objetivo analisar
o desempenho do processo a ser pesquisado (THIOLLENT, 2002). Aplicando a pesquisa-ao
na anlise dos processos de gerenciamento de projeto, como proposto aqui, devero ser
analisados os seguintes processos: (i) iniciao, (ii) planejamento, (iii) execuo, (iv) controle,
e (v) encerramento.

A anlise do desempenho sobre o processo de iniciao dever ser feita atravs da

avaliao da forma e procedimentos previstos no termo de abertura de projeto, e o
desenvolvimento de uma declarao do escopo preliminar e/ou definitivo para cada novo
projeto. Na Figura 29 pode ser visualizado, de forma grfica, o processo de iniciao
(CAVALIERI & DINSMORE, 2006).

FIGURA 29 Processo de Iniciao

Fonte: Adaptado de Cavalieri & Dinsmore, 2006
 75

Com relao ao processo de planejamento do projeto, dever se analisar a forma,

procedimento e a maneira que so planejadas as nove reas do conhecimento, segundo a
metodologia do PMI (ver Captulo 2). A anlise dever ser feita sobre o planejamento dos
seguintes itens: (i) escopo, (ii) tempo, (iii) custos, (iv) recursos humanos, (v) qualidade, (vi)
comunicaes, (vii) riscos, (viii) aquisies, e (ix) integrao ou mudana. A anlise sobre o
planejamento destes itens ser, de forma aplicada, apresentada no Captulo 4. Na Figura 30
pode-se visualizar, de forma grfica, o processo de planejamento (CAVALIERI &
DINSMORE, 2006).

FIGURA 30 Processo de Planejamento

Fonte: Adaptado de Cavalieri & Dinsmore, 2006

Na anlise do processo de planejamento, deve-se investigar o gerenciamento das

reas do conhecimento de forma a levantar, primeiramente, a existncia dos procedimentos, e
a operacionalizao de todos os procedimentos propriamente ditos, e a maneira como os
 76

responsveis executam estas atividades. Alm disso, dever ser analisado o nvel de
maturidade do processo de desenvolvimento com relao prtica e utilizao das reas de
conhecimento dentro de processo de desenvolvimento. Todas estas questes podero ser feitas
analisando o histrico dos projetos j concludos e/ou atravs de uma pesquisa direcionada ao
grupo envolvido.

A anlise e avaliao do processo de execuo dos projetos devero ser realizadas

sobre o modo como a empresa orienta e gerencia a execuo dos projetos. Esta avaliao
dever ser feita sobre a forma como o processo de desenvolvimento e os lderes de projeto
executam os seguintes itens: (i) garantia da qualidade; (ii) controle e mobilizao da equipe
do projeto; (iii) desenvolvimento da equipe, (iv) distribuio das informaes e freqncia, e
(v) a maneira de selecionar e desenvolver os fornecedores. Analogamente ao que foi realizado
no processo de planejamento, o levantamento destas informaes poder ser feito atravs da
avaliao direta de cada projeto e/ou atravs de uma pesquisa direcionada ao grupo envolvido.
Na Figura 31 apresentado o fluxograma de etapas do processo de execuo (CAVALIERI &
DINSMORE, 2006).

FIGURA 31 Processo de Execuo

Fonte: Adaptado de Cavalieri & Dinsmore, 2006
 77

A avaliao do processo de desenvolvimento relativamente ao monitoramento e

controle dever ser realizada enfocando o modo como so controlados os principais pontos ou
indicadores de um projeto. Dentre estes, devero estar presentes: (i) controle das mudanas;
(ii) verificao e atendimento do escopo; (iii) metas e atendimento das especificaes de
qualidade; (iv) cronograma em termos do tempo (planejado versus realizado); (v) custos e
aquisies (planejado versus realizado); (vi) monitoramento dos riscos; (vii) relatrios de
desempenho; e (viii) gerenciamento das partes interessadas. Na Figura 32 apresentado o
fluxograma de etapas do processo de monitoramento e controle, segundo Cavalieri e Cavalieri
(2006).

FIGURA 32 Processo de Monitoramento e Controle

Fonte: Adaptado de Cavalieri & Dinsmore, 2006

Para o ltimo processo (de encerramento), a avaliao deve se concentrar sobre os

procedimentos de encerramento do projeto propriamente dito, e dos encerramentos dos
contratos, quando estes so necessrios em um dado projeto. Esta avaliao dever ser feita
 78

diretamente a cada projeto executado, avaliando a forma, contedo e a existncia destes

procedimentos. Na Figura 33 apresenta-se, de forma grfica, os elementos contemplados no
processo de encerramento (CAVALIERI & DINSMORE, 2006).

FIGURA 33 Processo de Encerramento

Fonte: Adaptado de Cavalieri & Dinsmore, 2006

3.4.3 Fase Ao

Finalizada a fase principal, a fase de ao tem como objetivo definir os objetivos

prticos alcanveis por meio de aes concretas, visando materializar as mudanas na
organizao (THIOLLENT, 2002). Na pesquisa aqui proposta, as aes devero ser
direcionadas aos procedimentos que gerenciam os processos dos projetos.

A atuao sobre o processo de iniciao se faz, primeiramente sobre as definies

do procedimento de preenchimento de um termo de abertura de projeto. No termo de abertura
poder contemplar a descrio clara e sucinta do escopo do projeto. Aps a concluso da
descrio das informaes necessrias dever se submeter aprovao do escopo para as
partes interessadas (stakeholders) do projeto. A anlise da declarao do escopo deve se ater
no procedimento de montagem do escopo, criando-se regras de formao de uma declarao,
na qual devero aparecer as principais informaes do projeto em questo, tais como ttulo,
descrio, justificativa, objetivos, premissas e restries. Adicionalmente, a definio dos
responsveis pela aprovao do escopo dos projetos tambm dever estar claramente definida,
podendo ser feita, por exemplo, atravs de uma norma de procedimento.
 79

Nesta fase, as aes sobre o processo de planejamento do projeto devero ser

focadas no mtodo ou na forma como so planejadas as nove reas do conhecimento.
Conforme PMBoK (2004), a fase de planejamento a fase mais importante de um projeto,
pois nesta fase que o projeto estruturado. Caso o planejamento seja negligenciado, as
conseqncias negativas se faro notar durante o ciclo de vida do projeto. Para que um projeto
tenha sucesso, as nove reas do conhecimento (ou as principais, que uma empresa defina
como primordiais) devero aparecer no cronograma dos projetos na forma de atividades ou
tarefas especficas para algum responsvel capacitado para realiz-las adequadamente.

Com relao ao processo de planejamento, uma vez que as reas do conhecimento

estejam definidas dentro de um projeto, as aes ou tarefas ligadas diretamente a estas reas
do conhecimento, devero ser inseridas dentro do cronograma e aparecer abaixo de uma
atividade marco ou principal, neste caso podendo ser a fase de planejamento. Algumas aes
de planejamento que devero aparecer no cronograma so: (i) planejar e definir o escopo; (ii)
criar uma EAP (estrutura analtica do projeto); (iii) aprovar escopo; (iv) desenvolver o
cronograma definindo as atividades principais, responsveis, seqncia e durao; (v) definir
os recursos humanos; (vi) estimar custos e oramentos; (vii) definir as metas sobre os
requisitos de qualidade; (viii) definir o plano de comunicao entre os membros e partes
interessadas; (ix) planejar as compras e aquisies; e (x) identificar, planejar, quantificar e
qualificar os riscos.

No caso em que as aes sugeridas para a atividade de planejamento de um

projeto com relao s reas do conhecimento no estejam suficientemente claras e bem
definidas aos membros da equipe, dever se criar um procedimento para estas atividades.
Alm disso, no caso em que o grupo de trabalho ou os membros do projeto no estejam
capacitados a executar alguma atividade definida pelo lder de projeto, principalmente com
relao s aes definidas anteriormente, dever se fazer um treinamento ao grupo que ir
operacionalizar as tarefas do projeto.

As aes pertinentes ao processo de execuo devero ser criadas sobre os

procedimentos do processo de desenvolvimento. Desta forma, o procedimento a ser criado ou
revisado dever garantir que, durante a execuo do projeto, o lder ou gerente de projeto
possa verificar o atingimento do escopo, do prazo e dos custos planejados. Para isto, o
responsvel pelo projeto, dentro da sua forma de conduzir, dever gerenciar, de alguma
forma, (i) a equipe de projeto e seu desenvolvimento; (ii) a distribuio e o modo da
distribuio das informaes referente ao andamento do projeto; (iii) a seleo e
 80

desenvolvimento dos fornecedores internos e externos se existirem, e (iv) o atendimento dos

prazos de execuo das atividades ou dos contratos estabelecidos com fornecedores externos.

O processo de monitoramento e controle impe que o lder de projeto garanta o

atendimento dos seus indicadores. Novamente, alguns procedimentos bem definidos podero
ajudar neste controle, principalmente com relao ao modo de executar e monitorar qualquer
alterao de escopo, prazo ou custo do projeto. Da mesma forma, o controle sobre os
indicadores do projeto poder ser realizado criando tarefas para o lder de projeto sobre o
monitoramento dos indicadores com uma freqncia estabelecida, pois os indicadores
sinalizam o andamento do projeto.

No processo de encerramento, as aes a serem estabelecidas so similares as do

processo de planejamento. Podero ser inseridas no cronograma do projeto atividades que
definam todo o processo de encerramento, tais como: (i) finalizao e arquivamento dos
contratos, se existirem, (ii) desligamento dos membros do projeto contratados para este fim, e
(iii) criao de um evento de fechamento definitivo do projeto. Tudo isto s ser possvel
depois de obtido o atendimento do que tiver sido estabelecido no escopo de um projeto e,
principalmente, da aceitao formal por parte do cliente final.

3.4.4 Fase Avaliao

A ltima fase do mtodo de pesquisa-ao tem como objetivo apresentar e avaliar

os resultados obtidos aps a interveno realizada no processo. Para se fazer uma avaliao da
interveno necessria criar indicadores de desempenho que, de alguma forma, permitam
comparar os resultados anteriores e posteriores da pesquisa sobre a atuao no processo
explorado.

Neste tipo de interveno, ou seja, num processo de desenvolvimento, geralmente

so realizadas comparaes entre os tempos de desenvolvimento de projetos similares
(podendo ser em dias, meses, etc.), contabilizando desde a data de abertura at a data de
fechamento ou encerramento.

Nesta fase, diferentes tipos de indicadores podero ser utilizados, porm, uma vez
selecionado, o indicador dever permitir avaliar o desempenho da interveno. As maneiras
de se avaliar um desempenho podero ser atravs da reduo dos tempos decorridos de
desenvolvimento, da reduo dos custos de forma geral, da satisfao do cliente, do aumento
da fatia de mercado atravs do aumento do faturamento ou conquista de novos mercados, e
 81

etc. Existem outros indicadores de avaliao de desempenho que tambm podero ser
utilizados, dependendo do tipo de processo onde se far a interveno.
 82

4 MODELAGEM DA NOVA SISTEMTICA DE

DESENVOLVIMENTO DE PRODUTO

4.1 ESTRUTURA DO PROCESSO ATUAL

Anteriormente fase de montagem deste projeto, foi analisado a estrutura do

processo de projeto e desenvolvimento da empresa abordada no estudo do caso. Isso foi feito
com o intuito de entender o processo de desenvolvimento de produto, e permitir que a equipe
de trabalho, formada por um representante de cada rea envolvida diretamente ao processo,
uniformizasse os conhecimentos. Para proceder anlise, a equipe de trabalho consultou
especialistas da prpria empresa. Os especialistas foram s pessoas que estabeleceram os
procedimentos de desenvolvimento de produto quando a empresa se encontrava no processo
de certificao da ISO TS 16949: 2002.

Conforme levantado pela equipe em conjunto com os especialistas, o processo de

desenvolvimento na empresa est focado no desenvolvimento de produto, sendo guiado pelas
caractersticas do mercado e tipo de cliente. O processo de desenvolvimento de produto inicia
a partir de uma necessidade do cliente ou visando o atendimento de um novo nicho de
mercado ou uma aplicao em particular. No ambiente em que a empresa est inserida, pode-
se presumir que o processo de projeto e desenvolvimento de produto gera a necessidade de
outros desenvolvimentos, tais como alteraes de processos, novas matrias-primas, novos
equipamentos, etc. O desenvolvimento de produto considerado processo-chave dentro da
organizao; sendo assim, esta dissertao abordar o gerenciamento desse tipo de projeto.

Este tpico est dividido pelas fases do desenvolvimento da pesquisao: (i) fase
exploratria, atravs da apresentao do processo atual de desenvolvimento de produto; (ii)
fase principal, onde feita uma anlise sobre o modelo de gerenciamento do processo de
desenvolvimento atual; (iii) fase ao, onde apresentada a nova sistemtica de
gerenciamento do processo; e (iv) fase de avaliao, onde so apresentados os resultados
obtidos antes e depois da interveno atravs de indicadores de desempenho do processo de
desenvolvimento.
 83

4.2 Desenvolvimento da pesquisa

A pesquisa aqui reportada transcorreu no perodo de junho de 2006 a dezembro de

2007, e a equipe formada teve a participao das seguintes reas: engenharia de produto,
qualidade, informtica, compras, fbrica (produo) e engenharia de processo. Todas as nove
reas do conhecimento sero abordadas, porm as principais reas do processo de
gerenciamento de projeto que a equipe definiu, e que sero enfatizadas na pesquisa, sero:
gerenciamento do escopo, gerenciamento do tempo, gerenciamento do custo, gerenciamento
da qualidade e gerenciamento da comunicao, cujos fundamentos tericos foram
apresentados no Captulo 2.

Nas sees a seguir, apresentam-se as etapas do estudo de caso utilizadas para a

obteno da modelagem do novo processo de desenvolvimento, baseada na explorao e
anlise do estado atual do processo. As atividades realizadas durante o trabalho esto descritas
de forma seqencial. Apresenta-se, tambm, o procedimento adotado no gerenciamento de
cada projeto, baseando-se nas principais reas do conhecimento, conforme metodologia de
gerenciamento de projetos escolhida. Posteriormente, apresentada a estrutura dos projetos
modelos (templates) associada aos projetos de desenvolvimentos da empresa analisada. Na
ltima seo, so apresentados os resultados obtidos com a nova sistemtica de gerenciamento
dos projetos e o novo modelo de avaliao, atravs da medio do desempenho dos projetos
de desenvolvimento.

4.2.1 Fase exploratria

No incio da fase exploratria foi criada uma equipe multidisciplinar para

trabalhar no projeto descrito na seo anterior. Para a montagem da equipe, foram feitos
convites informais aos especialistas das reas envolvidas. Ainda nesta fase, seguindo o
procedimento definido pela empresa analisada, a equipe montou e preencheu uma carta de
projeto, modelo de carta particular a empresa analisada, como forma de documentar todos os
dados para a abertura de um projeto (APNDICE 1).

Nesta fase, definiu-se realizar diagnsticos interno e externo do processo de

desenvolvimento. Os diagnsticos foram realizados por meio de questionrios (pesquisa
direcionada), atravs de dilogos com especialistas e usurios, e atravs do levantamento e
anlise da documentao gerada por todos os projetos, formando a base de informao para a
equipe explorar e analisar o processo de desenvolvimento de produto e o seu mtodo de
 84

gerenciamento dos projetos. A anlise realizada nesta etapa foi baseada no diagnstico
interno, j que o estudo de caso est direcionado ao gerenciamento do processo de
desenvolvimento e no ao desenvolvimento de produto propriamente dito.

No diagnstico interno, foi realizada uma pesquisa direcionada obteno das

informaes especficas acerca do processo do gerenciamento de projetos da empresa. Em
reunies semanais, a equipe usou as tcnicas de brainstorming (para o levantamento dos
principais problemas encontrados) e mapeamento do processo (para refinar a compreenso do
mesmo). Essas tcnicas encontram-se descritas em Payzdek (2000).

A equipe tambm buscou levantar o desempenho dos projetos com relao a

alguns critrios pr-estabelecidos e definidos no escopo do trabalho, tais como tempo e custo
dos projetos, definio do escopo e atendimento aos requisitos de qualidade (ISO TS 16949:
2002). Na pesquisa dessas informaes, foram avaliados projetos realizados nos ltimos trs
anos, comparando o desempenho em termos do tempo total realizado.

Para realizar o mapeamento completo do processo (apresentado no Anexo A) foi

elaborado primeiramente um fluxograma simplificado (Figura 34). A montagem do
fluxograma ajudou a equipe a entender as atividades que cada rea realiza e as dificuldades ou
problemas a elas relacionadas.

Cliente

Vendas /
Marketing

Engenharia Engenharia Engenharia

de Processo de Produto de Materiais

Produo / Qualidade Logstica Compras

Fbrica

FIGURA 34 Fluxograma do processo de desenvolvimento de produto

Fonte: Empresa analisada, 2006

No fluxo do processo de desenvolvimento de produto da empresa analisada,
verificou-se uma caracterstica importante no processo em anlise: toda a criao de um novo
 85

projeto est vinculada ao atendimento da demanda. Ou seja, o incio do processo de

desenvolvimento tem origem quando existe a necessidade do cliente, e os produtos j
desenvolvidos pela empresa no atendem algumas caractersticas eltricas, dimensionais e/ou
funcionais especficas. Havendo a necessidade de se ofertar um novo produto, o cliente
encaminha diretamente pela rea de Vendas da empresa a especificao completa do produto
a ser desenvolvido.

Detalhando ainda mais o procedimento acima descrito, constata-se existir uma

diviso entre as reas de Vendas e Marketing de Produto. A rea de Marketing de Produto
recebe a solicitao do cliente atravs da rea de Vendas e analisa a necessidade de
desenvolvimento do novo produto, verificando se j existe algum produto similar para
oferecer, bem como define o preo de venda. No havendo algum produto que atenda a
necessidade do cliente, a rea de Marketing de produto envia a especificao para a rea de
Engenharia de Produto analisar e iniciar o seu desenvolvimento.

A Engenharia de Produto recebe a solicitao e faz uma anlise crtica sobre a

especificao do cliente. Nesta anlise, verifica-se o que ser necessrio desenvolver. Quando
todas as matrias-primas esto disponveis e no h necessidade de alterar ou adicionar
alguma etapa dentro do processo produtivo, o engenheiro responsvel inicia um processo de
desenvolvimento de Tipo I. Caso contrrio, quando h a necessidade de desenvolver nova
matria-prima, a necessidade encaminhada para a Engenharia de Materiais para
desenvolver. Da mesma forma, quando h a necessidade de alterar ou adicionar alguma nova
etapa dentro do processo produtivo, a necessidade encaminhada para a Engenharia de
Processo desenvolver as etapas necessrias, e tem incio um processo de desenvolvimento de
Tipo II.

Aps a criao da especificao interna do produto, das matrias-primas e do

processo, da avaliao funcional e dos testes de confiabilidade, a Engenharia de Produto
encaminha as especificaes e resultados do desenvolvimento para que outras reas faam
uma anlise crtica e tomem conhecimento do novo desenvolvimento. Neste momento, o
produto est em condies de ser produzido em escala (produo em massa).

De posse da confirmao das reas de apoio aceitando o projeto, e se preparando

para a produo do novo produto desenvolvido, a Engenharia de Produto encaminha a
especificao e o custo para a rea de Marketing de Produto, de forma a preparar o preo de
venda e encaminhar ao cliente.
 86

Dentro da fase exploratria, alm da busca e explorao das etapas do fluxo do

processo de desenvolvimento, todas as atividades de cada projeto foram avaliadas buscando-
se entender detalhes, caractersticas, dificuldades e pontos crticos do processo em anlise,
conforme sees a seguir.

4.2.1.1 Apresentao do processo atual de desenvolvimento de produto

O processo de desenvolvimento da empresa analisada est baseado nos princpios

do APQP (Advanced Product Quality Planning ou Planejamento Avanado da Qualidade do
Produto) e estruturado conforme a norma internacional ISO/TS 16949:2002, norma esta
indicada para o desenvolvimento de produto voltado a aplicao automotiva. Dessa forma, a
empresa definiu que todos os produtos a serem desenvolvidos devero seguir os mesmos
procedimentos e critrios de avaliao, independente da aplicao final.

O procedimento criado para estruturar o processo de desenvolvimento est

descrito na empresa analisada por uma norma geral, que faz parte do manual da qualidade. Na
norma especfica a este processo, o procedimento de desenvolvimento do produto foi
denominado de PQD (Planejamento da Qualidade de Desenvolvimento), o qual ser o objeto
desta anlise.

4.2.1.2 Modelo do processo de desenvolvimento

O processo de desenvolvimento criado e empregado pela empresa analisada tem

como objetivo estabelecer os procedimentos e responsabilidades para o projeto, estabelecer o
desenvolvimento e alterao dos produtos e processos de fabricao, garantindo a
conformidade do projeto e desenvolvimento dos produtos e processos com os requisitos do
cliente, com as normas e regulamentos governamentais e do meio-ambiente (ISO TS
16949:2002).

O processo de desenvolvimento est estruturado em cinco fases principais:

planejamento, projeto do produto, projeto do processo, verificao e validao. Estas fases
esto igualmente descritas no manual preparado pela equipe que desenvolveu o APQP (1994),
e so os requisitos necessrios para o desenvolvimento do produto para aplicao automotiva.

No procedimento do PQD (ANEXO A), foi estruturado um formulrio que serve

como check list para todos os itens relacionados ao desenvolvimento. Esse formulrio faz
parte da documentao do projeto e serve de folha resumo para todas as etapas do processo.
 87

Cada responsvel pelo projeto dever abrir o projeto utilizando esse formulrio, que dever
conter um nmero especfico para o projeto gerado de forma seqencial, auxiliando no
controle e monitoramento.

O procedimento de desenvolvimento ser referenciado no restante deste

documento por PQD. Esse se inicia pela fase de planejamento, etapa muito importante para o
cumprimento das metas do projeto. Nessa fase devero constar, alm de alguns pontos
especficos a esta fase, itens adicionais que devem ser incorporados devido aos requisitos ou
premissas do desenvolvimento, conforme norma que rege o processo de desenvolvimento do
produto para o mercado automotivo (ISO/TS 16949). Os itens especficos pertinentes a esta
etapa incluem: origem do projeto, requisitos relacionados ao projeto do produto, requisitos
relacionados ao processo, objetivos e metas de qualidade para o produto, controle de patentes,
e anlise crtica. Este ltimo item est baseado no cronograma do projeto e nas assinaturas das
reas envolvidas aprovando cada etapa. O responsvel por esta fase o lder ou gerente de
projeto que, na maioria das vezes, corresponde ao engenheiro de desenvolvimento de produto,
responsvel pela linha de produto em que o projeto se enquadra.

A segunda etapa do desenvolvimento o projeto do produto. Tal etapa est

baseada nos requisitos essenciais para a criao de uma especificao de produto. Os
requisitos so descritos em documentos e especificaes que seguem a norma, estando assim
definidos: Data Sheet (folha de dados); lista tcnica de materiais e quantidades;
especificaes dos materiais; DFMEA (Design Failure Mode and Effects Analysis ou Anlise
dos Modos e Efeitos de Falha de Projeto); desenhos do produto, montagens e materiais;
especificaes da embalagem; plano de controle de produto; avaliao dos impactos
ambientais do produto; e poka yokes de produto (especificao tcnica a prova de erros para a
sua construo e montagem no cliente). Todas essas etapas so de responsabilidade do
engenheiro de desenvolvimento de produto.

Na etapa de projeto do processo, necessrio definir: objetivos e metas de

capacidade, produtividade e investimento do processo; especificao dos equipamentos ou
caderno de obrigaes; definio do layout de produo; fluxograma de produo; PFMEA
(Process Failure Mode and Effects Analysis ou Anlise dos Modos e Efeitos de Falha dos
Processos); planos de controle; caractersticas especiais do processo; critrios de aceitao,
baseados nos planos de controle; e poka yokes do processo (especificao tcnica dos
dispositivos a prova de erro para o processo de fabricao). Adicionalmente a esta fase, faz-se
necessria a construo e avaliao de prottipos, com o objetivo de avaliar as caractersticas
 88

definidas para o produto e para o desempenho do processo. O responsvel pela especificao

e construo do processo o engenheiro de processo; as avaliaes so de responsabilidade
do lder do projeto.

A quarta e quinta etapas so destinadas avaliao final do produto (com relao

as suas especificaes construtivas e funcionais iniciais e aos testes de confiabilidade) e
avaliao do desempenho dos equipamentos e de todos os processos, dentro do fluxo da
cadeia produtiva. A quarta etapa, de verificao, est voltada produo do lote piloto em
condies definitivas, onde so feitas as avaliaes e anlises de todos os itens crticos e
significativos, definidos nas etapas anteriores. Posterior produo do lote piloto e avaliaes
dos resultados, segue-se para a etapa de validao, que se destina avaliao do produto em
testes de confiabilidade. Tais testes tm como objetivo avaliar o desempenho na condio
similar a da aplicao, previstos no projeto do produto. Finalizadas as etapas e estando as
avaliaes efetuadas satisfatrias e em conformidade com o especificado, o projeto
finalizado pela equipe e demais reas envolvidas, atravs da assinatura da documentao de
aprovao por parte do desenvolvimento do produto. O responsvel pela concluso destas
etapas o lder do projeto, porm, as avaliaes so feitas em conjunto pela equipe de projeto.

4.2.1.3 Avaliao sobre o Processo de Desenvolvimento

Avaliando o processo de desenvolvimento empregado na empresa analisada,

pode-se notar alguns aspectos positivos e diversas oportunidades de melhoria, os quais foram
os catalisadores para uma mudana e busca de uma nova sistemtica para o gerenciamento
dos projetos.

Os aspectos positivos identificados nos projetos analisados durante a pesquisa

referem-se basicamente ao contedo da documentao analisada. Notou-se que a equipe de
projeto conhecia as ferramentas e premissas para o atendimento da norma ISO/TS 16949. Por
outro lado, foram constatadas deficincias no planejamento e gerenciamento das tarefas, o que
compromete o atendimento aos prazos definidos pelos clientes internos e/ou externo. Esta
concluso tambm pode ser derivada da medio dos tempos de concluso dos projetos. Os
dados relativos a este levantamento utilizaram os 27 projetos finalizados para medio dos
tempos reais de concluso dos projetos, conforme apresentado na Tabela 1.

Para dimensionar a meta a ser alcanada, foi realizada uma pesquisa informal
direcionada ao grupo gerencial para definir os tempos mdios para os projetos de
desenvolvimento de produto. Esses tempos foram definidos e baseados num tempo que est
 89

dimensionado para estrutura da empresa para os dois tipos de projetos: (i) Tipo I -
desenvolvimento de um novo produto, com o processo atual e matria-prima j homologada, e
(ii) Tipo II - desenvolvimento de um novo produto, com a necessidade de se desenvolver o
processo e/ou alguma matria-prima. Alm dessas premissas, a solicitao de
desenvolvimento de um projeto do Tipo II pode ser motivada pela necessidade de
desenvolvimento de um novo fornecedor de matria-prima, alterao do processo ou o
desenvolvimento de um outro equipamento que, de alguma forma, acarrete um impacto na
funcionalidade ou caracterstica do produto. Nesses casos, o lder do projeto dever abrir um
novo projeto.

Para o projeto Tipo I, definiu-se um tempo mdio de aproximadamente 215 dias,

com desvio padro de 30 dias. Para o projeto Tipo II, definiu-se um tempo mdio de 315 dias,
com desvio padro de 30 dias. Neste tempo definido, foram considerados os tempos de
deslocamento que o caminho crtico nestes projetos, por se tratarem de matrias-primas e
equipamentos importados. Com base nesses valores, pde-se inferir, antecipadamente, que o
desempenho dos projetos, com relao ao indicador de tempo, apresentava deficincias. Na
Tabela 1 e 2, foi calculada a defasagem dos projetos em termos do tempo de concluso com
relao mdia, desvio padro e coeficiente de variao para os dois tipos de projetos dentro
de um total de 27 projetos analisados. Nesta tabela, pode se verificar que o grande desafio do
projeto est relacionado reduo do desvio padro e do coeficiente de variao dos tempos
de concluso de projetos, principalmente para os projetos Tipo I.

TABELA 1 Defasagem comparativa no tempo de concluso para os projetos Tipo I

Tipo de Projeto Tempo de Concluso Mdia Desvio Padro Coeficiente de Variao

Real 267,79 75,03 28,0%
Tipo I
Ideal 215,00 30,00 14,0%
Reduo -20% -60% -50%
Fonte: Empresa analisada, 2007

TABELA 2 Defasagem comparativa no tempo de concluso para os projetos Tipo II

Tipo de Projeto Tempo de Concluso Mdia Desvio Padro Coeficiente de Variao

Real 398,37 66,70 16,07%
Tipo II
Ideal 315,00 30,00 9,5%
Reduo -20% -55% -43%
Fonte: Empresa analisada, 2007
 90

Verificou-se que um dos motivos dos atrasos estava relacionado falta de

definio clara do escopo relativo ao projeto (em 12 dos 27 projetos analisados), conforme
Tabela 3. Alteraes eram solicitadas pelo cliente externo (por exemplo, aumento da vida til
do componente), ou mesmo por solicitaes internas (por exemplo, avaliao da capacidade
do produto ou processo para uma determinada caracterstica), sem que o impacto destas
alteraes sobre o projeto fosse discutido com o cliente. Os lderes de projeto incorporavam
todas as alteraes ao cronograma, assumindo, entretanto o mesmo prazo para finalizao e
mesmas especificaes de qualidade para o projeto.

To importante quanto o cumprimento do tempo em um processo de

desenvolvimento o custo do projeto. Analisando os dados levantados, verificou-se que no
havia uma estratificao dos custos dos projetos. Alguns custos, como os de pessoal, que so
proporcionais utilizao do recurso, no eram calculados dessa forma, sendo alocados de
forma fixa aos projetos, por rateio entre os projetos conduzidos pelo setor. Os custos
estratificados somente diziam respeito aquisio de matrias-primas e ferramentais.

A avaliao inicial mostrou que o processo de desenvolvimento de produto da

empresa analisada necessitava de uma reformulao. Os principais problemas relacionados
aos indicadores so: i) os engenheiros de desenvolvimento priorizavam atividades de apoio
linha de produo em detrimento dos projetos; ii) falhas no planejamento dos projetos levam a
equipe executora a revisitar etapas de projetos ou mesmo a retornar aos projetos j
concludos; iii) falhas no monitoramento do projeto resultam em um descaso por parte da
equipe com relao ao cumprimento de prazos; iv) o modelo de desenvolvimento em vigor
no permitia um feedback da equipe executora com vistas a alterar ou aprimorar
procedimentos previstos; v) a equipe executora trabalhava localmente em etapas do projeto
sem uma viso global do mesmo e sem participao efetiva nas etapas de planejamento; e vi)
falta de recursos humanos para conduzir os projetos no prazo.

4.2.1.4 Indicadores de desempenho do processo de desenvolvimento

Os indicadores de desempenho do processo de desenvolvimento atual da empresa

so apresentados na Figura 35. O indicador Tempo executado/Tempo planejado mensurvel
ao final de cada processo. O cenrio apresentado na Figura 27 utiliza parcialmente esse
indicador, ao considerar o tempo mdio executado dos projetos. O indicador nmero de
projetos contabilizado quando da abertura do projeto (ou seja, no incio do processo de
 91

planejamento). O indicador nmero de projetos validados mensurado ao final do processo

de validao.

Processos Indicadores Responsvel

Planejamento
Tempo executado/ Tempo
Projeto do Produto
Planejado Engenheiro de
Projeto do Processo
N de projetos Desenvolvimento de Produto
Verificao
N de projetos Validados
Validao
FIGURA 35 Indicadores de desempenho do processo de desenvolvimento
Fonte: Empresa analisada, 2006

O primeiro indicador da Tabela 14, tempo executado / tempo planejado, avalia o

desempenho do projeto no tempo. Os demais so basicamente indicadores que, se utilizados
individualmente, no avaliam o projeto na sua plenitude, nem permitem alinhar o resultado
estratgia da empresa com relao lucratividade, satisfao do cliente e inovao. Tambm
no foram encontrados planos de melhoria da sistemtica de avaliao, desde a criao do
PQD. Tal processo foi criado a partir da segunda edio da ISO/TS 16949, no ano de 2003,
com o intuito de melhor atender as necessidades dos clientes, principalmente com relao
rapidez em responder as demandas do mercado e, por conseqncia, a busca de rentabilidade
dos projetos. As nicas aes encontradas para aprimorar o PQD relacionavam-se
necessidade de treinamento dos lderes ou responsveis pelos projetos.

4.2.2 Fase principal

Finalizada a fase exploratria, a fase principal iniciou com a anlise das

informaes coletadas no diagnstico interno. Com base nos dados levantados, todos os
projetos foram analisados, de forma a avaliar o seu desempenho considerando os cinco
processos para um gerenciamento de projeto: (i) iniciao, (ii) planejamento, (iii) execuo,
(iv) controle, e (v) encerramento, conforme descrito no PMBoK (2004). No levantamento
realizado foram verificados 27 projetos de desenvolvimento concludos dentro do perodo de
janeiro de 2004 a dezembro de 2006.

Com relao ao processo de iniciao, os pontos que foram analisados foram a

existncia e conformidade com os conceitos com relao ao termo de abertura ou carta de
 92

projeto, e a declarao de escopo. Na Tabela 3 pode-se visualizar o resultado relativo aos

projetos analisados.

TABELA 3 Avaliao dos Projetos relativa ao Processo de Iniciao

reas do Conhecimento Conforme No Conforme Percentual conforme

Termo de Abertura ou 24 3 88,8%

Carta de Projeto

Declarao de Escopo 15 12 55,5%

Fonte: Empresa analisada, 2006

Na anlise realizada pode-se observar que a grande maioria (88,8%) dos projetos
possua um termo de abertura, principalmente porque dentro do procedimento atual, todo o
projeto necessariamente deveria ser iniciado utilizado o formulrio especfico do processo
PQD. Em somente trs projetos presentes no banco de dados criado pela Engenharia no foi
encontrado o documento oficial de abertura do projeto.

Ao contrrio do termo de abertura, um pouco mais da metade (55 %) dos projetos

apresentavam uma declarao do escopo. Alm disso, dos projetos analisados que possua a
declarao do escopo, todos eles apresentavam uma descrio breve, sucinta, com um grau de
profundidade muito baixo, no detalhando com clareza a justificativa, objetivos, premissas e
restries do projeto propriamente dito.

Na anlise do processo de planejamento realizada pelos membros da equipe sobre

os projetos, todos foram analisados no que se refere presena e contedo das nove reas do
conhecimento, descritos pelo modelo de gerenciamento de projeto escolhido, o PMBoK
(2004).

A tabulao dos resultados sobre a anlise realizada nos projetos est descrita na
Tabela 4. Nela, pode-se observar o contedo dos projetos sob a tica do gerenciamento de
projeto relativo ao processo de planejamento seguindo o modelo escolhido. Com relao aos
critrios de avaliao, a equipe definiu dois nveis, conforme ou no conforme. Para ser
classificado como conforme, deveria haver algum contedo e detalhamento sobre rea do
conhecimento em anlise. Por outro lado, para ser classificado como no conforme, no
deveria ser possvel correlacionar ou presenciar nenhuma prtica e documentao relativa
rea do conhecimento que est se analisando. A aderncia do contedo dos projetos ao
modelo escolhido poder ser visualizada na seo 4.2.3 (Fase ao).
 93

TABELA 4 Avaliao dos Projetos relativa ao Processo de Planejamento

reas do Conhecimento Conforme No Conforme Percentual conforme

Escopo c/ Aprovao 0 27 0,0%

Tempo 27 0 100,0%

Custo 5 22 18,5%

RH 3 24 11,1%

Qualidade 25 2 92,6%

Comunicao 0 27 0,0%

Risco 0 27 0,0%

Aquisio 5 22 18,5%

Integrao 0 27 0,0%

Fonte: Empresa analisada, 2006

O desempenho dos projetos sob a tica do processo de planejamento foi

considerado insatisfatrio dentro da viso do modelo escolhido, visto que em algumas reas,
tais como aprovao de escopo, plano de comunicao, risco e integrao, no se teve
evidncia da prtica de aplicao dos conceitos para o processo analisado. Os principais
pontos fracos no conforme esto detalhados na seqncia desta seo.

Um dos pontos verificados considerado grave foi a falta de planejamento dos

custos gerais e de pessoas. Na grande maioria dos projetos, encontrou-se somente a descrio
de custo de algum ferramental ou aquisio de matria-prima nova. Alm disso, em 100% dos
casos, no havia dados disponveis para se fazer uma anlise de viabilidade do projeto atravs
do tempo de retorno do investimento, ou EVA (Earned Value Added ou Economia de Valor
Agregado).

Na anlise dos projetos, verificou-se que o desenvolvimento dos recursos

humanos e o planejamento das aquisies no apresentavam evidncias de uma boa prtica.
Com relao ao desenvolvimento dos recursos humanos, a grande maioria dos projetos
apresentava a listagem da equipe, mas muitos dos seus participantes desconheciam a situao
do projeto. No caso do planejamento das aquisies, um percentual muito baixo dos projetos
apresentava uma definio ou um planejamento das principais aquisies previstas,
principalmente porque um projeto de desenvolvimento de produto nos moldes da empresa
 94

analisada sempre exige a aquisio de novas matrias-primas, construo de novos

ferramentais e produo de prottipos.

Por outro lado, todos os projetos analisados possuam um cronograma dividido

pelas principais fases do projeto de desenvolvimento, conforme definido pelo modelo de
desenvolvimento de produto para aplicao automotiva (APQP). Alm disso, todos os
cronogramas encontravam-se atualizados pelo gerente de projeto. Porm, em 100% dos casos
no foi possvel verificar uma anlise comparativa entre o tempo planejado e realizado, pois
todos os cronogramas analisados eram montados e atualizados manualmente sem a utilizao
de alguma ferramenta computacional para este fim.

Um ponto considerado positivo pela equipe que analisou os projetos foi o

atendimento dos requisitos de qualidade encontrado. Na grande maioria dos projetos, os
requisitos de atendimento a norma ISO TS 16949 estavam presentes, tais como o plano de
desenvolvimento seguindo as cinco fases do desenvolvimento.

Outras caractersticas analisadas nos projetos esto relacionadas existncia dos

procedimentos e sua operacionalizao. Apesar da existncia do modelo e seqenciamento
para o desenvolvimento do projeto no formulrio do PQD, na qual era seguido pelos lderes
de projeto, foi verificada no dilogo realizado com os mesmos, a falta de clareza ou definio
dos requisitos que a tarefa demandava. Muitos dos projetos que eram similares apresentavam
documentos com um formato diferente e com as caractersticas que foram avaliadas tambm
de forma diferente.

De posse das informaes coletadas e das anlises realizadas, pode-se notar um

nvel de conhecimento muito baixo com relao prtica do gerenciamento dos projetos e a
utilizao das nove reas do conhecimento. O grupo de lderes de projeto conhece as
necessidades de um projeto relacionado s questes tcnicas, mas no foi verificado o
conhecimento das melhores prticas para o gerenciamento de projetos.

Na fase de execuo do projeto na empresa analisada, a garantia de atendimento

da qualidade est relacionada a seguir e executar todas as tarefas relacionadas no formulrio
do PQD. Analisando em detalhes, somente o preenchimento dos dados referenciados no
formulrio no garantia de atendimento aos objetivos de qualidade, e sim o contedo de
cada atividade e a verificao do atendimento aos requisitos especificados.

Com relao ao desenvolvimento, controle e mobilizao da equipe de projeto

podem ser verificados no processo de planejamento que no aplicada esta tcnica nos
 95

projetos. De forma similar, o procedimento de distribuio das informaes no aplicado,

ficando todos os dados retidos com o lder de projeto.

Em projetos onde h necessidade de selecionar ou desenvolver o fornecedor, no

existe um procedimento formal. Na maioria das vezes, o desenvolvimento realizado a partir
de contato com o fornecedor, envio de uma especificao, discusso da viabilidade de atender
a especificao, solicitao de um oramento e pedido de amostras para avaliao do
processo. O procedimento de desenvolver o fornecedor, atravs de auditorias, estudos de
capacidade de processo, atendimento da demanda e assinatura de um contrato de
fornecimento no foi verificado.

Na fase de monitoramento e controle dos projetos, foram analisados os seguintes

pontos: (i) controle das mudanas, (ii) verificao e atendimento do escopo, (iii) controle do
cronograma em termos do tempo planejado comparado ao tempo realizado, (iv) controle dos
custos previstos e realizados, (v) controle e recebimento das aquisies planejadas, (vi)
monitoramentos dos riscos, (vii) relatrios de desempenho e gerenciamento das partes
interessadas.

Em todos os pontos analisados, no se observaram evidncias que havia um

monitoramento e controle pela equipe e principalmente pelo lder de projeto. O nico ponto
verificado em que havia um efetivo monitoramento era o atendimento ao cronograma, porm
no havia o controle e preocupao no que se refere ao atendimento ao prazo inicial
planejado.

Anlogo ao processo de execuo, no processo de encerramento dos projetos no

foram verificados procedimentos de encerramento dos projetos, e tambm no foram
evidenciados encerramentos de contratos, principalmente pelo fato de que os tipos de projetos
realizados na empresa no demandam contratao de uma equipe externa. Fato deve-se
principalmente pelo fato da estrutura organizacional interna existente na empresa analisada
possuindo reas de apoio e suporte bem definida e estruturada, tais como: projetistas, servios
tcnicos, oficinas aparelhadas, equipes de manuteno eltrica e mecnica. Desta forma, no
foi possvel analisar o tipo de controle realizado pelas equipes dos projetos com relao ao
processo de encerramento, principalmente com relao ao encerramento dos contratos.

Diante do quadro analisado, notava-se um alto grau de informalidade e pouca

ateno aos aspectos de gerenciamento dos projetos. Praticamente todos os projetos eram
conduzidos sem elementos bsicos de gesto, tais como EAP (Estrutura Analtica do Projeto),
 96

plano de comunicao e plano de riscos. Na sua maioria, os projetos analisados eram

baseados em cronogramas muito superficiais.

4.2.3 Fase ao

Finalizada a fase de obteno e anlise dos dados, a equipe de projeto comeou o

processo de montagem e definio do plano de ao. As prprias ferramentas utilizadas nas
fases de medio e anlise serviram de alguma forma, para direcionar e priorizar as aes que
o grupo deveria gerar para solucionar ou melhorar o processo de desenvolvimento.

Dentro da seqncia de atividades do projeto, aps o levantamento e anlises

feitas pela equipe, iniciou-se o processo de reformulao do procedimento, dando enfoque
metodologia e ao desenvolvimento das nove reas do conhecimento recomendadas e descritas
no PMBoK (2004). Posteriormente modelagem das nove reas para o gerenciamento dos
projetos, critrios e aes definidas pela equipe sero incorporados ao novo modelo de
desenvolvimento de produto, conforme definido no objetivo do trabalho. O prprio projeto de
reestruturao da sistemtica de desenvolvimento ser medido com relao sua eficincia
pelos novos indicadores de desempenho, ou seja, pelos indicadores de tempo e custo entre
planejado e realizado, aps o perodo de implantao e adaptao desta nova sistemtica.

O modelo proposto para o processo de desenvolvimento envolveu as etapas

descritas na seo 3.5. A estrutura deste novo modelo uma adaptao dos modelos de
implementao encontrados na literatura, incluindo principalmente aspectos propostos e
comentados no Captulo 2. Embora a metodologia de gerenciamento de projetos resultante da
aplicao do modelo seja especfica da empresa analisada, a abordagem de implantao pode
ser reproduzida e aplicada em outras empresas.

Os modelos para cada tipo de desenvolvimento foram criados e estruturados em

um software dedicado ao gerenciamento de projetos e modelado seguindo a estrutura no
PMBoK (2004) com as nove reas do conhecimento bem definidas. Esta ferramenta foi
adquirida pela empresa durante o projeto de mudana da sistemtica de gerenciamento dos
projetos aqui reportado. Atravs da funcionalidade do software, os lderes de projeto devero,
obrigatoriamente, buscar o projeto-modelo (template). Com este recurso, as informaes e
requisitos so migrados automaticamente do projeto modelo, tais como: EAP, atividades e
tarefas do cronograma, custos de pessoal por papel, definio dos papis e responsabilidades,
e os nveis de acesso para os papis criados no projeto.
 97

Principalmente em relao ao cronograma, todas as atividades e tarefas criadas no

modelo esto enquadradas dentro dos requisitos da norma ISO/TS 16949 e APQP (Advanced
Product Quality Planning ou Planejamento Avanado da Qualidade do Produto). Caso se
deseje criar um novo projeto a partir de um template, ser necessrio definir somente a
aplicabilidade daquela tarefa, ou seja, quando avaliada a necessidade de se realizar a tarefa no
projeto, dever se definir o responsvel, o esforo estimado, o perodo para realizao, e a
dependncia entre tarefas ou atividades.

Os modelos foram criados para os trs tipos de projetos principais definidos pela
empresa analisada, o de desenvolvimento de produto, o de processo e o de matria-prima,
podendo ser do Tipo I ou Tipo II. A estrutura de cada tipo de projeto atravs da EAP
(Estrutura Analtica do Projeto) pode ser visualizada nos Apndices B, C e D
respectivamente. Dessa forma, todos os projetos seguiro o mesmo padro. Esta foi a forma
encontrada pela equipe de projeto para padronizar o processo de desenvolvimento e criar o
mesmo critrio de avaliao.

A atuao sobre o processo de iniciao se realizou atravs da definio do

procedimento de preenchimento do termo de abertura e montagem do escopo. Atravs da
utilizao do recurso computacional (software) adquirido pela empresa, todo novo projeto
seguir o padro do projeto template. A montagem do termo de abertura ser realizada
abrindo um projeto no sistema e preenchendo todos os campos obrigatrios, tais como: nome
do projeto, lder do projeto, descrio breve sobre o projeto, tipo de projeto (Tipo I ou Tipo
II), data de incio, economia planejada e custo estimado.

Com relao atuao sobre o processo de planejamento, ficou definido (na nova
sistemtica) que, aps a abertura do projeto no sistema, o lder do projeto deve iniciar o
planejamento fazendo o gerenciamento do escopo com a incluso dos seguintes itens no
projeto: (i) definio detalhada do escopo contendo descrio, justificativa, objetivo com as
metas e os limites de contorno (delimitaes) do projeto bem como premissas e restries
para o atendimento e sucesso do projeto; (ii) EAP montada, dividida em etapas principais
(marcos) e definio dos produtos de cada etapa; (iii) envio e aprovao do escopo detalhado
junto aos stakeholders (partes interessadas no projeto). Aps esta aprovao, o projeto est
aberto oficialmente, podendo o lder de projeto dar continuidade ao seu empreendimento.

Com relao ao gerenciamento dos recursos humanos, foi definido que

inicialmente se far o planejamento dos recursos atravs da criao dos papis e
responsabilidades da equipe que executar o projeto. Aps essa definio, devero ser listados
 98

os indivduos que o executaro; para tanto, o lder do projeto deve negociar diretamente com
as chefias envolvidas a alocao dos indivduos na equipe de trabalho. Finalmente, dever ser
feito o desenvolvimento da equipe atravs de conversas informais ou, principalmente, atravs
de reunies peridicas.

O gerenciamento do tempo estar baseado no cronograma do projeto. Essa etapa

inicia-se pela definio das atividades principais (milestones ou marcos), similares quelas j
descritas na montagem da EAP. Como a maioria dos projetos ir iniciar a partir de um modelo
(template), o lder de projeto dever revisar em conjunto com a equipe se todas as atividades
esto contempladas para o novo projeto que se inicia, e se a seqncia das tarefas seguir a
mesma ordem cronolgica do projeto modelo. Na definio dos recursos para a execuo das
tarefas devero ser definidos os seus responsveis, buscando adequar a disponibilidade de
tempo para realizao da mesma. Isso poder ser feito de forma direta, perguntando ao
recurso, ou atravs da anlise da ocupao do recurso no tempo pelo prprio software, na qual
possvel visualizar a disponibilidade de cada membro do projeto no tempo para executar as
tarefas a serem delegadas. Como as atividades e tarefas j vm estabelecidas no projeto
modelo, o lder do projeto dever definir o esforo (horas de dedicao) e a janela de tempo
(perodo de execuo da tarefa, em dias) para execuo de cada tarefa. Posteriormente, sero
analisadas as relaes de precedncia entre tarefas e atividades e dever ser revisada aps a
anlise de riscos, pois poder ser necessrio incluso de novas aes.

O gerenciamento dos custos ser constitudo de um controle de gastos com

recursos humanos e de um controle dos gastos gerais. Os custos de pessoal sero calculados
automaticamente pelo software quando da criao de uma tarefa no cronograma. O valor
calculado dever corresponder quantidade de horas trabalhadas (esforo), multiplicada pelo
valor mdio da hora do executante. No controle dos gastos gerais devero ser avaliados se
todos os gastos planejados relativos ao projeto esto de acordo com os que esto sendo
realizados. A medida que as aquisies forem ocorrendo no tempo, o lder de projeto dever
registrar a data e o custo da compra. De forma complementar, o responsvel pelo projeto
dever monitorar, via relatrios de acompanhamento produzidos pelo software, as variveis
de tempo e custo, comparando valores planejados e realizados. Por fim, dever ser feito o
acompanhamento do seu indicador de custo (IDC) que apresentado na seo 4.2.4.1.

Com relao ao gerenciamento dos riscos, ser criada para cada projeto uma tarefa
no cronograma necessariamente antes da tarefa de anlise do seqenciamento, dentro da
atividade marco de planejamento, associada ao levantamento dos riscos do projeto, o que
 99

dever ser realizado em conjunto com toda a equipe. Com base nesse levantamento, dever
ser feita uma anlise quantitativa dos riscos, definindo prioridades, efeitos e a combinao
entre probabilidade de ocorrncia e seu impacto no projeto. Aps, inicia-se o planejamento
das respostas, as quais podero ser aes de eliminao, mitigao ou contingncia; tais
respostas devero ser inseridas no cronograma do projeto. O gerenciamento dos riscos poder
ser feito utilizando os recursos do software. Na fase de controle, o lder do projeto dever
acompanhar a eficcia das aes corretivas ou de conteno de riscos.

Quanto ao gerenciamento da qualidade, todos os projetos-modelo (templates)

inseridos no software foram baseados nos requisitos da ISO/TS 16949. Foram identificados,
assim, os itens que o projeto dever atender e as tarefas do cronograma, com uma descrio
clara dos seus objetivos e modo de execuo. Como uma das premissas bsicas do projeto
atender as necessidades do cliente, a especificao completa dada pelo cliente dever estar
inserida como um documento pertinente ao escopo.

O planejamento da qualidade definido como primeira atividade do projeto, no

que diz respeito ao gerenciamento da qualidade. Tal planejamento dever ser montado de
forma que o trabalho atenda a todos os padres (principalmente aqueles definidos pelo
cliente), os requisitos definidos em norma, e aqueles recomendados pela metodologia de
gerenciamento de projetos.

A garantia da qualidade est baseada no seqenciamento correto do cronograma, o

qual j foi concebido para atender a todos os requisitos de qualidade. Com relao ao controle
da qualidade, todo projeto dever ser verificado e validado no que diz respeito especificao
do projeto; ou seja, o projeto somente ser encerrado aps comprovar que atende a todos os
requisitos especificados pelo cliente. De forma complementar, o prprio software auxiliar na
etapa de controle, pois h a possibilidade de agendar auditorias de qualidade, podendo ser
definidos os itens a serem avaliados, selecionar o auditor e a data.

O gerenciamento da comunicao est baseado na distribuio das informaes

relativas ao andamento do projeto ao longo do seu ciclo de vida, utilizando as funcionalidades
do software. O lder de projeto dever utilizar os recursos do aplicativo para encaminhar s
partes interessadas (stakeholders), ou at mesmo para os recursos do projeto, alguns relatrios
de andamento pr-definidos pelo programa. Alm da escolha dos relatrios a serem enviados,
o lder do projeto poder definir os recipientes, o perodo e a freqncia de envio, que se far
por e-mail. Desta forma, o lder do projeto poder satisfazer os requisitos das partes
interessadas e receber o retorno adequado sobre seu desempenho. Os principais relatrios
 100

disponibilizados pelo software so: lista de tarefas, cronograma, grfico de Gantt, planilha de
custos geral e de pessoal, e avaliao parcial do atendimento aos indicadores de custo e prazo.

O gerenciamento da aquisio est enquadrado dentro do gerenciamento dos

custos, estando inserido nos custos gerais, sendo, porm, monitorado e definido pelo lder do
projeto.

Para o gerenciamento da integrao, a nova sistemtica no apresenta muitas

diferenas com relao ao que a empresa vinha utilizando. Porm, a sistemtica prioriza o
registro e controle das alteraes que, por ventura, venham a ocorrer ao longo do ciclo de vida
do projeto. No entanto, ficaram definidos alguns procedimentos bsicos de monitoramento,
auxiliados pelo software, relativamente listagem e controle temporal das pendncias de cada
responsvel por tarefas. O controle do projeto atravs da medio de desempenho do projeto
com relao ao tempo e custo, comparando o planejado contra o realizado tambm ajuda ao
lder de projeto para uma tomada de deciso, dando a viso do todo e possibilitando a
visualizao dos pontos a melhorar a nvel de atividade para cada projeto.

O procedimento para verificar o atendimento do escopo realizado,

primeiramente, aps o procedimento de aprovao do escopo pelas partes interessadas
(stakeholders). De forma complementar, e depois de realizado todo o planejamento do
projeto, o lder dever encaminhar ao mesmo grupo o aceite do projeto, para que o grupo faa
uma anlise crtica das atividades criadas para atendimento ao escopo do projeto. Esta
funcionalidade tambm est presente no software; esta tarefa foi colocada no cronograma dos
projetos modelos (templates), sendo obrigatria a sua realizao.

Na empresa analisada, o desenvolvimento dos recursos humanos se resume a

reunies peridicas com toda a equipe, apresentao dos objetivos, definio dos papis e
responsabilidades. O objetivo obter o comprometimento do grupo e, posteriormente, avaliar
os resultados e desempenho do projeto e do time. De forma a criar uma cultura de
desenvolvimento de equipe, foram includas no cronograma dos projetos modelos tarefas em
grupo para este fim. Um exemplo so as reunies de abertura (kick-off) que devero ser
realizadas pelo lder de projeto para apresentar a proposta do projeto e discutir com a equipe
os papis e responsabilidades.

Para a seleo e desenvolvimento dos fornecedores foi criado um representante

para esta atividade, denominado SQA (Suppplier Quality Assurance ou Qualidade Assegurada
de Fornecedor) e tem como uma das suas principais funes a atuao direta no fornecedor.
 101

De forma a padronizar o procedimento de avaliao ou desenvolvimento do fornecedor, foram

includas ao projeto-modelo tarefas exclusivas para este fim, conforme apresentado no
ANEXO B (Desenvolvimento do Fornecedor).

Em geral no h contrato de equipes externas e, por este motivo, no foram

planejadas tarefas de criao e monitoramento para tal. Porm, com relao aos contratos de
fornecimento de matria-prima, principalmente quando h necessidade do seu
desenvolvimento, ficou definido que os mesmos sero elaborados e discutidos pela equipe de
desenvolvimento e encaminhados ao fornecedor pelo responsvel pela negociao e
monitoramento do contrato, o papel do SQA.

A atuao sobre o processo de monitoramento e controle dos projetos se deu

atravs da utilizao do software, a partir do qual o lder de projeto pode acompanhar seus
indicadores de tempo e custo atravs de grficos que medem o fator de atendimento ao
planejado de forma global ou por atividade do projeto. Esses dados esto disponveis para
toda a equipe de projeto e podem ser visualizados a qualquer momento. Na seo 4.2.4.1
apresentada a forma de avaliao dos projetos.

O procedimento de alterao do escopo, no caso de haver a necessidade durante o

andamento do projeto, ser conduzido pelo lder de projeto, que cancelar a aprovao
anterior, reabrindo-a dentro do sistema. Antes de submeter o projeto nova aprovao, ser
necessrio revisar todo o planejamento, principalmente com relao ao cronograma e custos
envolvidos. Uma vez revisado quanto ao escopo, o projeto dever ser submetido nova
aprovao.

Em todos os projetos-modelo foram criadas tarefas de monitoramento dos

indicadores, como forma de criar uma cultura de controle. Para tanto, foi desenvolvida uma
funcionalidade no programa computacional que permite emitir relatrios semanais (ANEXO
C) para todos os projetos de forma individualizada, por setor da empresa. A equipe de
trabalho em conjunto com a alta administrao da empresa definiu tambm que os relatrios
de acompanhamento de todos os projetos (portflio) seriam enviados para os stakeholders
(partes interessadas) e tambm para a alta administrao da empresa. Essa ao foi definida e
implantada durante a montagem deste projeto de reestruturao do gerenciamento de projetos
na empresa analisada, como forma de envolver todos os nveis da empresa, e para que todos
tenham conhecimento do status do projeto. Outro objetivo desta ao gerar uma necessidade
de priorizao de projetos do portfolio, bem como a definio dos tempos de dedicao dos
 102

recursos aos projetos, visto que os gerentes funcionais so os responsveis pelos recursos, e
no os lderes de projeto.

O processo de encerramento dos projetos ser realizado atravs da finalizao e

arquivamento dos contratos, sob a forma de desligamento dos membros de projeto ou
contratados, e atravs de um evento de encerramento definitivo do mesmo. Todas as
atividades de encerramento de projetos foram includas no cronograma do projeto modelo. O
arquivamento e encerramento dos contratos com os fornecedores ficaram sob a
responsabilidade do SQA, e os demais contratos so de responsabilidade do lder de projeto.
O desligamento dos membros do projeto ou contratados dever ser realizado pelo lder de
projeto em um evento de confraternizao ou reunio de fechamento definitivo. A equipe
deste projeto definiu que, como padro para o encerramento, o lder de projeto dever
apresentar, neste evento, um relatrio final contendo a descrio do projeto, a equipe de
trabalho, as metas, as etapas seguidas, as principais aes, os resultados obtidos e as lies
aprendidas. A forma de realizao do fechamento definitivo do projeto, neste caso, fica a
critrio do lder de projeto.

Aps a implantao da nova sistemtica foi realizado um treinamento especfico

para cada tipo de usurio: (i) lder de projeto, (ii) membro de projeto, e (iii) stakeholders e
analista de atividades. O treinamento a todo o grupo envolvido transcorreu por um perodo de
seis meses. O treinamento abordou a metodologia de gerenciamento de projeto escolhida, as
nove reas do conhecimento descritas no PMBoK (2004), as funcionalidades do software
adquirido pela empresa atravs da forma de gesto dos projetos e seu portflio, e
principalmente a nova sistemtica de gerenciamento do processo de desenvolvimento de
produto.

4.2.4 Fase avaliao

Na ltima fase da pesquisa-ao realizou-se a avaliao dos resultados obtidos

neste projeto medindo o desempenho dos projetos aps a interveno segundo os seguintes
critrios: (i) presena e contedo do planejamento; (ii) contedo e controle do cronograma;
(iii) existncia de um plano de comunicao; (iv) montagem e controle do oramento e (v)
atendimento aos indicadores de tempo e custo entre o realizado e o planejado.

Devido ao tempo de concluso dos projetos ser relativamente longo (de seis meses
a um ano, em mdia), a avaliao do tempo final de concluso ficou restrita a um pequeno
 103

nmero de projetos (4, no total), dado o pouco tempo transcorrido entre a implantao da
nova sistemtica e a anlise dos resultados obtidos.

Os projetos concludos foram avaliados com relao aos critrios listados acima,
com resultados apresentados na Tabela 5. Nessa tabela pode-se verificar que em todos os
projetos avaliados existia um planejamento e montagem do cronograma. Na maioria dos
projetos havia um plano de comunicao e, da mesma forma, um oramento. Todos os
projetos na tabela se enquadram na classificao do Tipo I. Baseado nos resultados, pde-se
constatar uma boa prtica no gerenciamento dos projetos atravs dos valores de tempo
planejado e tempo realizado de concluso dos projetos, obtendo uma diferena percentual
mdia entre valores planejados e realizados de +3,5%.

TABELA 5 Avaliao dos projetos dentro da nova sistemtica de gerenciamento

Projeto Planejamento Cronograma Plano de Oramento Tempo Tempo

Comunicao Planejado Realizado
(dias) (dias)

Projeto A 202 205

Projeto B 218 228
Projeto C 215 224
Projeto D 224 235
Mdia: 214,7 222,2
Desvio Padro: 9,3 12,5
Fonte: Empresa analisada, 2008

O resultado dos ganhos obtidos com relao s metas definidas para os projetos
relacionados aos processos de desenvolvimento pode ser visualizado na Tabela 6. Nesta tabela
apresentada percentualmente a reduo dos tempos de concluso dos projetos, a reduo do
desvio padro e coeficiente de variao, conforme medido na Tabela 1.

TABELA 6 Avaliao comparativa dos projetos antes e depois da interveno

Tipo de Projeto Perodo de Avaliao Mdia Desvio Padro Coeficiente de Variao
Antes da Interveno 267,70 75,03 28,0%
Tipo I
Aps a Interveno 222,20 12,50 5,6%
Reduo -17% -200% -198%
Fonte: Empresa analisada, 2008

Analisando detalhadamente os resultados obtidos nos projetos, houve uma

reduo de 17% no tempo global de concluso dos projetos, porm a grande reduo est
 104

relacionada ao desvio padro, o qual reduziu-se em 200%, e o coeficiente de variao, que

reduziu-se em 198%.

Apesar de o resultado inicial ser positivo e estar sob o efeito da avaliao mais
rigorosa e freqente, a equipe de projeto no acredita neste efeito externo, e sim que o tempo
de desenvolvimento poder reduzir-se ainda mais no futuro, em virtude da adaptao dos
usurios nova sistemtica e com a operacionalizao do software de gerenciamento de
projetos. Por outro lado, cabe frisar que a reduo significativa do resultado obtido com
relao ao desvio padro e coeficiente de variao est relacionada quantidade relativamente
baixa da populao de projetos avaliados durante a fase de avaliao.

A equipe de projeto continuar monitorando o tempo de desenvolvimento e os

indicadores de todos os projetos, atravs de um relatrio semanal emitido pelo prprio
software, enviado aos usurios via e-mail. Dessa forma, a equipe de trabalho poder entender
e atuar sobre as principais causas dos desvios que, por ventura, surjam nos projetos.

4.2.4.1 Avaliao das aes corretivas

As principais aes corretivas descritas na seo 4.2.1.3 foram avaliadas de forma

a verificar a sua eficcia baseado no desempenho e na forma que foram gerenciados os
projetos. As avaliaes das principais aes esto descritas nesta seo conforme segue.

A ao realizada para melhorar a priorizao dos projetos por parte dos lderes de
projeto ao invs das atividades de apoio a linha de produo foi realizada atravs da
obrigatoriedade da abertura dos projetos no sistema dedicado ao gerenciamento de projetos, o
acompanhamento do andamento de cada projeto pela alta administrao e stakeholders, e
atravs de reunies gerenciais que so definidas as prioridades com relao carteira de
projetos. Baseado nestas aes, todos os projetos abertos que esto em andamento apresentam
os seus indicadores de tempo e custo entre bom e mediano. Para os projetos que estavam com
os indicadores ruins, foram suspensos e/ou cancelados devido a uma baixa prioridade, ou
decorrente de uma mudana de escopo e ainda se encontra em discusso com as partes
interessadas, ou pelo prprio cancelamento do projeto em conjunto com o cliente.

A utilizao de uma ferramenta de gerenciamento de projeto em conjunto com a

criao de projetos modelos que possuem etapas claramente definidas para se realizar o
planejamento, foram as aes corretivas criadas diretamente para melhorar a falta de
planejamento dos projetos que levavam a equipe executora a revisitar etapas de projetos ou
mesmo a retornar aos projetos j concludos. O resultado destas aes no pde ser
 105

devidamente avaliado pelo pouco tempo decorrido entre a implantao da nova sistemtica e
os resultados obtidos, porm, de maneira informal os lderes de projeto afirmam que em 100%
dos projetos se realiza um real planejamento, e isto resulta em ganhos de qualidade e tempo
para os projetos abertos.

Todos os controles que foram criados para o monitoramento dos projetos,

principalmente pela criao dos relatrios de acompanhamento do portfolio e dos projetos que
so enviados via sistema semanalmente para a alta administrao, stakeholders e gerncias,
reduziu drasticamente as falhas no monitoramento dos projetos que resultam em um descaso
por parte da equipe com relao ao cumprimento de prazos. A cobrana pelo atendimento dos
projetos nos dois principais indicadores, tempo e custo, obrigaram aos lderes de projeto a dar
o andamento devido aos seus empreendimentos.

Na nova sistemtica de desenvolvimento, se criou uma obrigatoriedade do

envolvimento dos membros dos projetos, principalmente pela necessidade de estar atualizado
o cronograma de tarefas e a sua apropriao de horas e custos. Desta forma, gerou uma
necessidade em virtude do modelo de desenvolvimento em vigor, a proporcionar um feedback
da equipe executora com vistas alterao ou aprimoramento dos procedimentos previstos, e
dando uma viso global e tambm da participao dos membros ao longo do todo o ciclo de
vida dos projetos.

A questo da falta de recursos para conduzir os projetos no foi resolvida

mudando a sistemtica de gerenciamento de projetos, porm a questo da priorizao dos
projetos atravs da visualizao da carteira de projetos da rea de cada gerente funcional da
empresa analisada, ajudou a balancear a demanda com relao disponibilidade dos recursos
existentes.

De forma a buscar algumas explicaes pelas quais os projetos no eram

finalizados, ou no eram corretamente planejados, a equipe de projeto buscou analisar a
estrutura organizacional da empresa. Analisando o PMBoK (2004), verificou-se que existem
estruturas organizacionais diferentes, e na empresa analisada a melhor estrutura que se
enquadra a classificao matricial fraca conforme ilustrado na Figura 36, ou seja, as reas
esto bem definidas, existindo a figura dos gerentes funcionais e, mais abaixo, a sua equipe
formando uma estrutura vertical dentro do setor.

Neste tipo de estrutura organizacional a qual a empresa foi criada, os projetos so

executados por engenheiros de desenvolvimentos subordinados aos gerentes funcionais e a
 106

necessidade dos recursos das outras reas acontece de forma horizontal. Dessa forma, a matriz
que caracteriza a estrutura organizacional da empresa acaba sendo classificada como uma
estrutura matricial fraca, conforme definido no PMBOK (2004) e ilustrada na Figura 36. A
estrutura matricial fraca tem a caracterstica dos gerentes ou lderes de projetos possurem
uma autoridade limitada comparada aos gerentes funcionais, pois geralmente so seus
subordinados.

Apesar dessa observao e avaliao feita com relao estrutura organizacional

da empresa analisada, a alterao desse conceito no fazia parte do escopo do projeto, desta
forma no sendo discutida com a alta gerncia da empresa analisada. Porm, o tipo de
estrutura organizacional existente na empresa explicava alguns motivos, para a grande
maioria dos projetos no finalizarem ou no terem um planejamento correto, pois as
prioridades no so definidas pelos lderes ou gerentes de projeto, e sim pelos gerentes
funcionais. Independente da alterao ou no da estrutura organizacional da empresa, a equipe
acredita que aps a implantao da nova sistemtica e das aes corretivas criadas, espera-se
que o resultado seja satisfatrio e tenha continuidade ao longo dos anos.

FIGURA 36 Influncia das estruturas organizacionais nos projetos

Fonte: PMBoK, 2004

4.2.4.2 Novo mtodo e indicadores de avaliao dos projetos

O novo sistema de medio do projeto adotado na empresa analisada avalia os

indicadores de tempo e custo atravs do mtodo de anlise do valor agregado (EVA). Isto , o
clculo tomar como base os valores monetrios e horas de trabalho. Para que o sistema mea
o andamento do projeto, trs informaes principais so demandadas: (i) o valor previsto, (ii)
 107

o valor realizado e (iii) o valor agregado, sempre usando os dados de horas e custo
envolvidos. A partir dessas trs informaes, os ndices de desempenho de prazo (IDP) e de
custo (IDC) so calculados.

O custo previsto calculado a partir do cronograma (custo de pessoal) e

oramento (matria-prima, projeto, aquisies e etc.) do projeto. Alguns dados devem ser
informados: a data de incio, que a data de incio prevista para cada tarefa do projeto; o
prazo previsto, que a data prevista de trmino da tarefa no projeto; as horas previstas, que
a quantidade de horas previstas para atender a tarefa em questo dentro do projeto. Para que o
sistema calcule corretamente, importante que o valor da hora do usurio responsvel esteja
registrado corretamente no cadastro de usurios, j que esse valor utilizado no clculo de
custos previstos.

O custo realizado calculado a partir das horas apropriadas de trabalho, de cada

tarefa, por cada recurso do projeto, e pela situao de cada tarefa (concluda, em andamento,
etc.).

O valor agregado a medida real de produto desenvolvido. importante no

confundir o valor agregado com tempo de trabalho ou custo realizado. O valor agregado o
tempo de trabalho ou custo previsto para o produto desenvolvido at o momento, sendo
calculado a partir das informaes de andamento (porcentagem concluda) das tarefas.

O software permite que a anlise de valor agregado (EVA) seja baseada em duas
mtricas diferentes: (i) horas de trabalho, indicada para medio de andamento do projeto e
projeo da data de concluso do mesmo (ou seja, mostra o desempenho do projeto em horas
de trabalho), e (ii) valor monetrio, indicado para verificar os custos realizados e projetar o
custo final do projeto, mostrando seu desempenho em termos de custo.

Para demonstrar o mtodo de clculo utilizado, so definidas as seguintes siglas:

PV (Planejado): o valor planejado;

EV (Agregado): o valor agregado;

AC (Realizado): o valor realizado;

CV (Variao do Custo 1 = EV-AC): o valor agregado menos o valor realizado,

em moeda atual ou em horas;

Variao do Custo 2 (CV/EV): a variao do custo 1 dividido pelo valor

agregado;
 108

SV (Variao do Cronograma 1 = EV-PV): o valor agregado menos o valor

planejado, em moeda atual ou em horas;

Variao do Cronograma 2 (SV/PV): a variao do cronograma 1 dividido pelo

valor planejado;

IDC (ndice de custo = EV-AC): o ndice de desempenho do custo, usado como

ordenada no grfico de desempenho;

IDP (ndice de tempo = EV - PV): o ndice de desempenho do cronograma

(tempo), utilizado como abscissa no grfico de desempenho.

A tabela de clculo dos indicadores de desempenho mostrada na Figura 37.

FIGURA 37 Tabela de clculo dos indicadores de desempenho do projeto

Fonte: Empresa analisada, 2007
Aps o clculo obtido para os indicadores de tempo e custo, o software apresenta
um grfico mostrando qual o posicionamento do projeto em relao aos ndices de custo
(IDC) e tempo (IDP). Alm disso, h uma classificao do desempenho do projeto em trs
nveis: bom, mdio ou ruim. Tal classificao montada a partir de alguns parmetros
definidos pela empresa e ajustveis no software. Nesse caso, dever se definir a tolerncia
aceitvel sobre a meta. No grfico, a meta atingir o alvo que dado pela interseco dos
indicadores de custo (IDC) e tempo (IDP). Nesse ponto tem o valor igual a 1 (um) ou 100%,
ou seja, o resultado da relao entre planejado e realizado mostrando o atendimento total
para os indicadores de custo e tempo.

A empresa analisada decidiu utilizar uma tolerncia de -10% nos indicadores de

projeto, sendo considerado aceitvel que o indicador resulte em at 90% do seu desempenho
mximo. No momento de montar o grfico, o indicador representado no grfico de uma
maneira visual, atravs das cores (verde, amarelo ou vermelho). Quando os indicadores
(tempo e custo) calculados forem maiores ou iguais a 0,9, o projeto classificado com um
bom desempenho e representado pela cor verde. Se os indicadores calculados (custo e tempo)
 109

estiverem menores do que 0,9, o projeto classificado como um mau desempenho e

representado pela cor vermelha. Porm se um dos indicadores estiver com o desempenho bom
(maior ou igual a 0,9) e o outro com um desempenho ruim (abaixo de 0,9), o projeto
classificado como desempenho mediano e representado pela cor amarela. A Figura 38 traz
um exemplo da classificao acima descrita.

Projeto E
Projeto D Projeto A
Projeto C Projeto B

Projeto F

FIGURA 38 Grfico representativo do desempenho do projeto

Fonte: Empresa analisada, 2007
A empresa utilizar o mtodo acima para avaliar o desempenho de seus projetos.
O mtodo, implementado em software, est aderente metodologia do PMI. Alm desta
sistemtica, est sendo criado um conselho para avaliao do portflio de projetos com
relao a sua economia, custos envolvidos, aderncia estratgica e tempo de implantao.
Diante disso, os projetos sero avaliados de forma pontual pelo seu desempenho, e de forma
geral, com relao a sua aderncia ao planejamento estratgico da empresa.
 110

4.3 Concluses e lies aprendidas

Um dos aspectos mais importantes em um projeto est relacionado s lies

aprendidas. Acontecimentos e descobertas ao longo de um projeto devem ser descritos e
devem servir de realimentao para o grupo, no intuito de melhorar ou manter a ao
relacionada lio.

Dentro deste projeto, algumas das lies aprendidas, as quais foram relatadas e
descritas no andamento do projeto pela equipe, so as seguintes:

A necessidade da prtica da Engenharia Simultnea. A criao de uma equipe

multifuncional e entre departamentos foi importante com relao a troca de
experincias e informaes durante um projeto, e deve ser constante e
prevalecer para se tirar vantagens competitivas, principalmente em relao ao
lead time de desenvolvimento.

A etapa mais importante do projeto o planejamento. O planejamento uma

etapa chave dentro de um projeto; a dedicao a esta etapa se reflete no
resultado final de um projeto.

A necessidade da quebra de alguns paradigmas. Um dos paradigmas que afeta

diretamente o andamento de um projeto buscar realizar aes que no sejam
precedidas de planejamento. Isso ocorre porque durante o planejamento da
ao, tem-se a sensao de que o projeto est parado.

O entendimento das premissas e especificaes de cliente para se realizar um

bom planejamento parte pela utilizao e conhecimento de todas as reas do
conhecimento.

A necessidade de se fazer o acompanhamento rgido dos projetos por parte do

lder de projeto de extrema importncia no seu sucesso, principalmente no
que diz respeito ao atendimento ao tempo.

Criar a cultura da busca de melhorias atravs do registro de lies aprendidas.

O conhecimento das melhores prticas e a busca por melhorias deve ser, de
alguma forma, registrada e repassada aos lderes e membros do projeto.

A busca e o conhecimento de fatores de priorizao quando se trabalha com

uma carteira (portfolio) de projetos. Em empresas ou escritrios de projetos
 111

que trabalham com um grande nmero de projetos e escassez de mo-de-obra,

a definio dos trabalhos prioritrios deve ser sistematicamente realizada.

A importncia da liderana para gerenciar projetos. Os gerentes de projetos

devem exercer com muita propriedade o seu poder de liderana, de forma a
facilitar, motivar o seu grupo e cobrar o andamento dos temas.

A criao de uma cultura em todas as reas sobre a prtica do gerenciamento

de projetos. O conhecimento das melhores prticas de gerenciamento de
projeto deve permear a organizao, para que se tenha uma linguagem nica,
para que se consiga buscar, em conjunto, as melhorias no processo, e para que
haja uma sinergia entre os membros do projeto.

Avaliar, registrar e gerar aes para os riscos potenciais de cada projeto. A

anlise dos riscos para os projetos deve ser praticada e revisada
freqentemente, com o intuito de gerar aes de preveno, eliminao ou
mitigao dos riscos, sempre com o objetivo de garantir o atendimento do
escopo do projeto.

A obrigatoriedade da aprovao do escopo pelas partes interessadas do projeto

reduzindo os riscos do no atendimento das especificaes do produto ou
servio. A aprovao do escopo uma prtica compulsria e deve ser realizada
sempre pelas partes interessadas do projeto, garantindo que aquilo que est se
prometendo fazer seja, realmente, a necessidade do cliente.

Gerentes funcionais se transformarem em gerentes de projetos. Mudar o tipo

de estrutura organizacional de fraca para balanceada ou forte conforme
influncia das estruturas organizacionais nos projetos (PMBoK, 2004),
utilizando melhor o poder de definio dos gerentes funcionais, tornando-os
gerentes de projetos e no somente utiliz-los como stakeholder ou partes
interessadas.

Aps todas as etapas do projeto concludas, as lies aprendidas registradas e

discutidas com a equipe do trabalho e os resultados obtidos, o cronograma foi totalmente
cumprido, conforme apresentado no APNDICE E. Dessa forma, a equipe do projeto deu o
trabalho por encerrado.
 112

5 CONCLUSES E CONSIDERAES FINAIS

A busca pelas melhores prticas no gerenciamento de projeto tornou-se uma

prtica muito difundida nos ltimos anos, atravs da busca pelo sucesso no atendimento das
metas de cada projeto. Essa prtica est baseada no conjunto de conhecimentos das reas que
envolvem o gerenciamento de projetos, conhecimentos esses que foram as competncias
essenciais de um Gerente de Projetos. Esse conjunto de conhecimentos inclui prticas
tradicionais e inovadoras que vm surgindo ao longo dos anos.

A realizao deste trabalho permitiu chegar a algumas concluses com relao

aplicao do gerenciamento de projetos no processo de desenvolvimento de produto na
empresa analisada. A partir da aplicao deste trabalho, foi possvel verificar a viabilidade da
extenso desta prtica a outros trabalhos futuros.

O principal objetivo deste trabalho foi desenvolver uma metodologia de

gerenciamento de projetos baseado no modelo escolhido PMBoK (2004), para uma empresa
de grande porte. A empresa, alm de ser um centro de desenvolvimento e fabricante de
componentes eletrnicos para todas as aplicaes e em especial para o mercado automotivo,
possui certificao ISO TS 16949:2002 e segue o processo de desenvolvimento de produto
guiado pelo modelo APQP (Advanced Product Quality Planning).

A situao em que a empresa analisada se encontra marcada por um cenrio em

que a concorrncia externa, principalmente asitica, torna o seu mercado de atuao altamente
competitivo e s vezes desfavorvel financeiramente. Assim, a questo da qualidade no
desenvolvimento dos novos produtos torna-se o diferencial competitivo para os mercados
mais exigentes. Desta forma, este trabalho demonstrou que possvel obter o sucesso em
empresas em dificuldades econmicas, financeiras e inovao, utilizando a base de
conhecimento para o Gerenciamento de Projetos como uma base para atingir os resultados
desejados.

O trabalho utilizou o mtodo de pesquisa-ao e os resultados aplicados

mostraram a efetividade das aes para atingir os objetivos propostos. A base do
conhecimento para o gerenciamento de projetos principalmente nos processos de integrao,
escopo, tempo, custo, qualidade e comunicao, em conjunto com a Engenharia Simultnea,
agregaram as ferramentas e tcnicas adequadas para o ambiente de manufatura por
 113

encomenda. Em relao aos objetivos secundrios estabelecidos, os mesmos foram assim

cumpridos:

i) a identificao do processo chave a ser estudado como potencial de melhoria,

visualizando a busca de maior competitividade no mercado para o processo de
desenvolvimento de produto foi detalhado no Captulo 1;

ii) a elaborao de uma reviso bibliogrfica sobre gerenciamento de projetos

focando nas nove reas do conhecimento descritas principalmente no PMBoK (2004),
apresentado no Captulo 2;

iii) a anlise do processo atual do gerenciamento de projetos na empresa

analisada, focando nas dificuldades e melhorias necessrias atravs do uso de uma
metodologia para melhor fazer a gesto do processo de desenvolvimento de produto est
descrito no Captulo 4;

iv) a aplicao de uma metodologia de gerenciamento de projetos, desenvolvida

no Captulo 4, a qual foi desenvolvida para uma empresa de grande porte e centro de
desenvolvimento e fabricante de componentes eletrnicos para todas as aplicaes, em
especial para o mercado automotivo com o grande grau de exigncia.

O estudo de uma metodologia de gerenciamento de projetos aplicado ao processo

de desenvolvimento de produto utilizando como guia o PMBoK (2004), principalmente
atravs da montagem dos projetos modelos (templates), que esto baseadas nas principais
reas do conhecimento como forma de gerenciamento dos projetos, e estruturados seguindo os
critrios do modelo de desenvolvimento de produto da indstria automobilstica APQP,
trouxe resultados significativos na reduo dos tempos de desenvolvimento, melhoria da
qualidade dos projetos e o real levantamento dos custos dos projetos, conforme apresentado
no Captulo 4.

Apesar dos resultados obtidos e apresentados no Captulo 4, alguns pontos de

melhoria foram verificados e necessitam ser revistos na empresa analisada. A falta de
priorizao e recursos dedicados aos projetos so algumas das dificuldades encontradas. Esta
caracterstica pode estar atrelada estrutura organizacional matricial fraca, descrita na seo
4.2.4.1, bem como falta de um gerente de portflio e ainda a no utilizao do conceito de
escritrio de projetos, cujos conceitos de gesto esto descritos no Captulo 2, conceito este
largamente aplicado atualmente nas empresas. A presena de gerentes funcionais como
gerentes de projeto e a criao de um gerente de portflio utilizando o conceito de escritrio
 114

de projetos podero trazer mais comprometimento e senso de priorizao aos projetos de

desenvolvimento, reduzindo e otimizando o tempo e custo de cada um dos seus
empreendimentos.

5.1 Recomendaes para Trabalhos Futuros

No desenvolvimento deste trabalho verificou-se que os conceitos de

gerenciamento de projetos so extensveis e podem ser aplicados em todos os ambientes onde
se realizam projetos, no necessariamente no desenvolvimento do tipo de produto abordado
neste estudo. Alguns dos temas a serem abordados em trabalhos futuros dentro da empresa
analisada so:

Projetos de infra-estrutura e construo de mquinas;

Projetos para expanso de linhas de produo;

Projetos de transferncia de linhas entre plantas situadas em pases diferentes;

Projetos de melhorias dos principais indicadores para reas de apoio: Diretoria

(DIR), Recursos Humanos (HR); Controladoria (ACF), Logstica (CS),
Informtica (IT); Qualidade (QM) e demais reas existentes dentro da
empresa.

Apesar da possibilidade de estender a prtica de gerenciamento de projeto para

outras reas, a metodologia poder ser ampliada e melhorada com uso de tcnicas e
ferramentas como forma de facilitar a gesto do processo de desenvolvimento de produto, a
qual no foi foco nesta fase de implantao da nova sistemtica desenvolvida neste trabalho.

Focando em algumas das principais reas do conhecimento difundida pela base do

conhecimento do PMI (Project Management Institute): escopo, tempo e custo; e logo aps a
consolidao prtica da nova sistemtica de gerenciamento de projeto descrita neste trabalho,
o aperfeioamento do modelo poder ser realizado usando algumas tcnicas: i) escopo
Gerenciamento por Objetivos; ii) tempo Estimativas da Durao das Atividades; iii) custo
Tcnica anloga ou Top Down para estimativa de custos.

Ambas as tcnicas descritas acima, como outras que podero ser utilizadas
posteriormente ao processo de gerenciamento dos projetos, como forma de aprimorar a prtica
do gerenciamento de projeto baseado na prtica da melhoria contnua e amplamente pregada
na norma internacional ISO TS 16949, esto amplamente difundidas e descritas nas
 115

referncias usadas neste trabalho, tais como, Kerzner (1992), PMBoK (2004), Cavalieri &
Dinsmore (2006).
 116

REFERNCIAS

ADVANCED PRODUCT QUALITY PLANNING AND CONTROL PLAN (APQP).

Reference manual, EUA: AIAG Publications, 1994

ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBR ISO 10006: Gesto da

Qualidade Diretrizes para a Qualidade no Gerenciamento de Projetos. Rio de Janeiro,
2000

ATKINSON, R..; CRAWFORD, Lynn; WARD, Stephen. Fundamental uncertainties in

projects and the scope of project management. International Journal of Project Management
24, p.687-698, 2006

BEZERRA, Nelson R. de A; FILHO, Jos R. de F. Ferramentas para controle do prazo de

projetos. IV Seminrio Fluminense de Engenharia - Niteri, 2005

CASTRO, Silvio W. Aurlio. Falso Controle de Projetos, como evitar. Revista mundo PM,
Curitiba, N 2 ano 1, p. 14 19, Editora Mundo, 2007

CAUCHIK MIGUEL, Paulo A.; SEGISMUNDO, Andr. An analysis of portfolio

management in new product development: a case study in a truck company. Universidade de
So Paulo, Product: Management & Development, v. 4 n.2, dez. 2006

CAVALIERI, Adriane; DINSMORE, Paul C. Gerenciamento de Projetos. Rio de Janeiro:

Qualitymark Editora ltda, 2006

CLELAND, Davis I. Project management: strategic design and implementation. 2nd ed.
Boston: MacGraw-Hill, 1994

CRUZ, Amaury B.; FERNANDES, Elton; LIMA, Solange; ARAJO, Renato S.B. Uma
abordagem comparativa do gerenciamento da qualidade do Projeto. XXVI ENEGEP
Fortaleza CE - BRASIL 2006

DIAS, Marisa V. Bas. Um novo enfoque para o Gerenciamento de Projetos de

Desenvolvimento de Software. So Paulo: Universidade de So Paulo Departamento de
Administrao da Faculdade de Economia. Dissertao de Mestrado, 2005
 117

EMPRESA ANALISADA. Projeto e Qualidade do Desenvolvimento (PQD). Empresa

Analisada: Gravata, 2006 Manual

KERZNER, Harold. Project Management: a systems approach to planning, scheduling and

controlling. New York: Van Nostrand Reinhold, 1992

KIRST, Ronald W. Implementao de Gerenciamento de Projetos em uma Empresa

Petroqumica de 2 Gerao. Porto Alegre: Universidade Federal do Rio Grande do Sul
Escola de Engenharia Dissertao de Mestrado Profissionalizante, 2004

KOLLTVEIT, Bjorn J., KARLSEN, Jan T., Gronhaug, Kjell; Perspective on project
management. International Journal of Project Management 25, 3-9, 2007

MARTINSUO, Miia; LEHTONEN, Paivi. Role of single-project management in achieving

portfolio management efficiency. International Journal of Project Management 25, p.56-65,
2006

MAXIMIANO, Antnio.C. O Gerente de Projetos: um "ator" com vrios personagens.

Revista de Administrao, So Paulo 1997

MAXIMIANO, Antonio C. Administrao de Projetos. So Paulo: Atlas, 2002.

MICCOLI, Wilson R.V. Sistematizao das Metodologias atuais de Gerenciamento de

Projetos nas Indstrias de Grande Porte da Grande Curitiba: Um estudo de multi-casos -
Curitiba: Universidade Federal do Paran - Engenharia Mecnica - Dissertao de Mestrado,
2004

MORAES, Renato de O.; LAURINDO, Fernando J. Barbin. Um estudo de caso de gesto

de portfolio de projetos de tecnologia a informao. Gesto e Produo, v.10, n.3, p.311-328,
dez. 2003

MLLER, Ralf; TURNER, J. Rodney. Matching the project managers leadership style to
project type. International Journal of Project Management 25, 21-32, 2007

PAIVA, E.; FENSTERSEIFER, J. Estratgias de Produo. Porto Alegre: Escola de

Engenharia - Universidade Federal do Rio Grande do Sul - Mestrado Profissional 2000.

PAULA, Istefani C. de; SANTANNA, ngelo M. O.; BIASOLI, Patrcia K.; RIBEIRO,
DUARTE, Jos L. Anlise da metodologia Seis Sigma e Gesto de Projetos. XXVI ENEGEP
Fortaleza CE - BRASIL - 2006
 118

PINTO, Ricardo L. Evoluo da estrutura organizacional ao longo do ciclo de vida do

projeto: um estudo de caso. So Paulo: Universidade de So Paulo - Faculdade de Economia,
Administrao e Contabilidade - Dissertao de Mestrado, 2002

PRADO, Darci Santos do. Planejamento e Controle de Projetos. Belo Horizonte, MG:
Editora de Desenvolvimento Gerencial, 1998

PRIKLADNICKY, Cecilio. Gerenciamento de Projetos Aplicado em Pequenas e Mdias

Indstrias de Bens de Capital Sob Encomenda. Porto Alegre: Universidade federal do Rio
Grande do Sul - Escola de Engenharia - Dissertao de Mestrado Profissionalizante, 2003

PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of

Knowledge (PMBOK 2004 Guide). Pennsylvania: Project Management Institute Inc., 2004.

PYZDEK, Thomas. Quality Engineering Handbook. Nova York: 2000

RABECHINI JR., Roque; CARVALHO, Marly Monteiro de; LAURINDO, Fernando

Jos Barbin. Critical Factors for implementation of project management: a research
organization case. Revista Produo, vol.12, no.2, p.28-41. ISSN 0103-6513, 2002

RABECHINI JR., Roque; PESSA, Marcelo S. de Paula. Um modelo estruturado de

competncias e maturidade em Gerenciamento de Projetos. Revista Produo, vol. 15, no. 1,
p. 034-043, 2005

RAUTIAINEN, Kristian; NISSINEN, Maarit; LASSENIUS, Casper. Improving Multi-

Project Management in Two Product Development Organizations. Proceedings of the 33rd
Hawaii International Conference on System Sciences - Helsinki University of Technology -
2000

REHDER, Haroldo. Fatores crticos de Sucesso de projetos automotivos com fornecedores:

estudo de casos de desenvolvimento sucessivos de painis para veculos comerciais. So
Paulo: Universidade de So Paulo - Escola Politcnica da Universidade. Dissertao de
Mestrado, 2006

REIS, Delmar A. F. dos; Interpretao e Implantao ISO/TS 16949:2002. Empresa

Analisada: Gravata, 2003

SATO, Carlos E. Y.; DERGINT, Dario E. A.; HATAKEYAMA, Kazuo. A utilizao do

escritrio de projetos como instrumento para a melhoria da produtividade sistmica das
organizaes. Centro Politcnico da UFPR Paran - 2004
 119

SAUER, C.; REICH, B.H. What do we want from a theory of project management? A
response to Rodney Turner. International Journal of Project Management 25, p.1-2, 2007

SLACK, N.; CHAMBERS, S; HARLAND, C.; HARRISON, A.; JOHNSTON, R.

Administrao da Produo. So Paulo: Atlas, 1997. 726p

SOTILLE, Mauro. Gerenciamento de Projetos na Engenharia de Software. Disponvel em

http://www.pmtech.com.br acesso em 19/06/2007

THIOLLENT, M. Metodologia da Pesquisa-Ao. So Paulo: Atlas, 2002

TORREO, Paula G. B. Coellho. Ambiente Inteligente de Aprendizado para Educao em

Gerenciamento de projetos. Recife: Universidade Federal de Pernambuco - Centro de
Informao. Dissertao de Mestrado, 2005

VALERI, Sandro Giovanni; ROZENFELD, Henrique. Gerenciamento de Projetos -

Conceitos Bsicos. 11/11/1999. Disponvel em:
http://www.numa.org.br/conhecimentos/conhecimentos_port/pag_conhec/Gerenciamento_Pro
jetosv2.html. Acesso em: 18/07/2007

VALERIANO, D. L. Gerncia Estratgica e Administrao por Projetos. So Paulo:

Makron Books do Brasil, 2001, 295p

VARGAS, R. V. Gerenciamento de Projetos. Rio de Janeiro: Brasport Livros e Multimdia,

2002, 260p

ZANONI, Roberto; AUDY, Jorge L. Nicolas. Project management model for a physically
distributed software development environment. Computer Society, Proceedings of the 36th
Hawaii International Conference on System Sciences, IEE, 2002
 120

REFERNCIAS SUPLEMENTAR

CLARK, A. A Practical use of key success factors to improve the effectiveness of project
management. International Journal of Project Management. Conventry, v.17, n.3, p. 139-145,
1999

MUNDIM, Ana P.F.; ROZENFELD, Henrique; AMARAL, Daniel C.; SILVA, Sergio
L.; GUERRERO, Vander; HORTA, Lucas C. da. Aplicando o Cenrio de
desenvolvimento de Produtos em um caso prtico de Capacitao profissional. Gesto &
produo, So Paulo, v.9, n.1, p.1-16, abr. 2002

PRADO, Darci; ARCHIBALD, Russel. Pesquisa sobre Maturidade em Gerenciamento de

Projetos. Maturity by Project Category Model (MPCM) - Maturidade Brasil 2005 - Relatrio
anual 205, v.2, mai, 2006

SILVA, Sergio L.; ROZENFELD, Henrique. Modelo de avaliao da gesto do

conhecimento na processo de desenvolvimento do produto: Aplicao em um estudo de caso.
Revista produo, v.3, n.2, 2003

THIOLLENT, M. Pesquisa-Ao nas Organizaes. So Paulo: Atlas, 1997. 164p

VALERIANO, D. L. Gerncia em Projetos. So Paulo: Makron Books do Brasil, 1998, 438p

 121

APNDICE A Minuta de Projeto

COMPETE Project Charter

Division: BU: KO A Site: Date: 18/ dez 06

Project title Implantao de um novo mtodo de gerenciamento de projetos atravs de uma Div. project no.:
reestruturao do processo de desenvolvimento de produto.
KO_Buzzetto5
Time line Start date: 18/dez/06 Projected completion date: 30/nov/07
name: business unit or department: e-mail:
Project manager Mr. Buzzetto KO fabiano.buzzetto@epcos.com

Deputy project manager

Champion / Executive Mr. de Rose KO D ricardo.derose@epcos.com

Financial representative Mr. Batistela BA ACF luis.batistela@epcos.com

Master Black Belt Mr. Boer QM renato.boer@epcos.com

name department name department

Project team Fabiano Buzzetto KO Edmundo Werner Neto FK EDC
Rafael Preisig KO D Luciano Pedroso FK EDC
Daniel Barbosa KO D Jefferson Corrent OIL
Hermann Sagmeister KO BA P Digenes Sartor FK EAC
Marcos Goerl KO MC Alexandre Pedott QM
Gustavo Tonding KO MC Eduardo Drehmer FK BA P

Description and impact

Problem description or Atrasos e longos tempos de desenvolvimento das matrias-primas, processo e produto.
status at EPCOS

Goal / Objective Reduzir os tempos mdios de desenvolvimento de produto para 215 dias (Projetos tipo I) e 315 dias (Projetos tipo
(if applicable: explicit II).
avoidances)

Affected products and product: process:

processes Todos Matri-prima, processo e produto

Projected business benefits or Aumentar a satisfao do cliente e a reduo do tempo para introduo de novos produtos.
strategic relevance

Impact on customer: on supplier:

Melhoria no tempo de resposta Melhoria no tempo de resposta

Preliminary risk assessment Atrasar o projeto devido a necessidade do apoio e dedicao das diferentes reas da empresa.

Interaction with other projects No

Metrics supporting data now to be

unit available (initial value) (target value) comment
Time (Projeto tipo I) dias 270 215
Time (Projeto tipo II) dias 400 315
Other:
Project Authorization (name, date, signature)
Mr. de Rose Mr. Batistela Mr. Buzzetto Mr. Boer

Champion / Executive Financial representative Project manager Master BB

 122

APNDICE B Estrutura Analtica do Processo de Desenvolvimento de Produto

 123

APNDICE C Estrutura Analtica do Processo de Desenvolvimento de Processo

 124

APNDICE D Estrutura Analtica do Processo de Desenvolvimento de Matria-Prima

 125

APNDICE E Cronograma Final do Projeto

 126

ANEXO A Procedimento do PQD (Planejamento da Qualidade de Desenvolvimento)

1. Objetivos

Estabelecer os procedimentos e responsabilidades para o projeto, desenvolvimento e alterao

dos produtos e processos de fabricao da EdB.
Garantir a conformidade do Projeto e Desenvolvimento dos produtos e processos com os
requisitos do cliente, com as normas e regulamentos governamentais e do meio-ambiente.

2. mbito de Validade

Projeto e desenvolvimento dos produtos e processos de fabricao da EDB .

3. Referncias Normativas
ISO TS 16949.
ISO 14001
Manual do APQP, AIAG.
Manual do PPAP, AIAG.
Manual da Qualidade da EDB.
Mdulo 301 Anlise Crtica dos Requisitos de Cliente.
Mdulo 303 Controle de Documentos.
Mdulo 304 Aquisio.
Mdulo 307 Controle de Processo.
Mdulo 311 Manual do RL.
IDP 128 PPAP.
IDP 222 Requisitos sobre Substncias Perigosas
GQ 69 FMEA e Plano de Controle

4. Definies

Aes de Melhoria do Sistema da Qualidade So as aes planejadas para corrigir ou prevenir a

ocorrncia de no-conformidades internas ou externas.
Alterao de Matria-prima a modificao das caractersticas de qualidade da Matria-prima que
impactam na forma, ajuste, ou funo do produto, incluindo desempenho e vida til.
Alterao de Processo a modificao de equipamentos e ferramentas do processo de fabricao
que impactam a realizao do produto.
Alterao de Produto a modificao das caractersticas de qualidade que impactam na forma,
ajuste, ou funo do produto, incluindo desempenho e vida til.
Anlise Crtica Atividade realizada para determinar a pertinncia, a adequao e a eficcia do que
est sendo examinado, para alcanar os objetivos estabelecidos.
Prova de Erro Projeto e desenvolvimento de produto e de processo de fabricao para prevenir a
fabricao de produtos no-conformes.
Avaliao Ambiental Prvia Atividade realizada para determinar a utilizao de novos insumos, a
gerao de resduos, emisses atmosfricas, efluentes e outros aspectos ambientais significativos.
Caractersticas Especiais So caractersticas de produto ou parmetros de processo de fabricao
que podem afetar a segurana ou conformidade com regulamentos, ajuste, funo, desempenho ou
processamento subseqente do produto.
Ensaios de Confiabilidade o conjunto de ensaios aplicados ao produto para reproduzir ou acelerar
as condies de uso. Ver Mdulo 311 Manual do Laboratrio de Confiabilidade (RL).
 127

FMEA Anlise dos modos de falhas e efeitos potenciais de um produto ou processo. Ver
procedimento para FMEA GQ 69.
Famlia de Produtos um conjunto de partes ou grupos de sries de produtos com processo de
fabricao e aplicao semelhante.
Inspeo de Lay-out a medio de todas as dimenses do capacitor especificadas no desenho,
conforme Plano de Controle do TPA.
LAIA Levantamento de Aspectos e Impactos Ambientais.
Lote Piloto/Srie Piloto um conjunto de produtos fabricados a partir de condies definitivas do
processo, de onde podem ser obtidos dados confiveis sobre o produto e o processo.
PA Produkt Anfrage o sistema para anlise crtica de contrato de um Produto Novo ou Similar
ver Mdulo 301 Anlise Crtica dos Requisitos de Cliente.
Plano de Controle do Processo o documento que relaciona os controles estabelecidos para as
caractersticas especiais do produto e processo de fabricao
Plano de Controle do Produto o documento que relaciona os controles estabelecidos para as
caractersticas especiais do projeto do produto.
PQD Plano de Qualidade no Desenvolvimento o documento que identifica os estgios, as
interfaces, as responsabilidades e as anlises crticas do Projeto e Desenvolvimento.
Processo Novo o processo que necessita desenvolvimento para atender aos requisitos do cliente.
Produto Existente um produto com cadastro e fabricao corrente.
Produto Novo um produto cuja as caractersticas de qualidade esto fora do espectro das sries
ou famlias de produtos existentes (homologados).
Produto Similar um produto cuja as caractersticas de qualidade esto dentro do espectro das
sries ou famlias de produtos existentes (homologados).
Prottipo um produto fabricado a partir de condies provisrias, para verificao do projeto.
Sries de Produtos um conjunto de produtos que utilizam o mesmo processo construtivo e
apresentam caractersticas eltricas e dimensionais similares.
Verificao a comprovao de que os requisitos especificados foram atendidos.
Validao a comprovao de que os requisitos para a aplicao ou uso foram atendidos.

5. Controle de Documentos
Os documentos originados no Projeto e Desenvolvimento dos produtos e processos so
controlados de acordo com o mdulo de controle de documentos da EDB Mdulo 303.

Numerao do PQD A identificao e controle dos PQDs deve ser feita atravs de uma
ordenao numrica, por departamento de Engenharia.

6. Planejamento da Qualidade no Desenvolvimento PQD

O departamento de Engenharia deve designar um lder ou responsvel pelo projeto, que

dever formar uma equipe multidisciplinar e promover a integrao dos diferentes estgios do projeto,
seguindo o roteiro do formulrio do PQD.

Um PQD deve ser iniciado sempre que houver:

O desenvolvimento de um produto novo a partir de uma PA;
O desenvolvimento de um processo novo a partir de uma PA, ou do Plano de
Racionalizaes, ou do Plano de Investimentos;
Alterao de Matria-prima a partir de uma ao de melhoria, ou do Plano de
Racionalizaes, que impactam a realizao do produto.
 128

Alterao de Processo existente a partir de uma ao de melhoria, ou do Plano de

Racionalizaes, que impactam a realizao do produto.
Alterao de Produto existente a partir de uma PA, ou de uma ao de melhoria, ou do Plano
de Racionalizaes;

O processo de aprovao do produto e do processo de fabricao reconhecido pelo cliente

deve ser aplicado aos fornecedores de matrias-primas, nos seguintes casos:
Novos projetos, com requisito especfico do cliente;
Novos projetos, com materiais crticos definidos pela Engenharia.
Nos demais casos, deve-se utilizar o mtodo definido no Mdulo 304 Aquisio.

Estgios do Projeto e Desenvolvimento

Incio
Entradas de Projeto e Desenvolvimento
Liberao do Projeto e Desenvolvimento
Liberao do Prottipo
Planejamento do Produto Liberao do Lote Piloto
Desenvolvimento do Produto Liberao da Produo
Desenvolvimento do Processo

Verificao / Validao

Fabricao do Produo da Produo em srie

prottipo srie piloto
Troca de informaes entre os participantes e, onde aplicvel, ajustes no fluxo do processo.

Gerenciamento e Monitoramento dos Estgios do Projeto e Desenvolvimento

Os projetos e desenvolvimentos devem ser gerenciados e monitorados para permitir visualizar a

situao de cada projeto em relao ao planejado. O mtodo deve identificar o estgio atual dos
projetos em andamento e indicar o risco para o cumprimento dos requisitos planejados, conforme
modelo de planilha em anexo.

Processo Indicadores Responsvel

Planejamento
Projeto do Produto Tempo executado /
Tempo Planejado
Eng. Produto/
Projeto do Processo
N de projetos Processo
Verificao N de projetos
Validados
Validao
 129

Controle de Alterao de Projetos Notificao de Alterao de Produto ou Processo PCN

(Product or Process Change Notification)

O controle das alteraes que impactam a realizao do produto segue a mesma sistemtica
do PQD.
O Cliente dever ser notificado, ou com antecedncia mnima de trs meses, ou conforme
requisitos especficos, sobre as seguintes alteraes:
Todas as alteraes no produto ou processo que afetem suas especificaes;
Todas as alteraes de produto ou processo que afetam as caractersticas dimensionais,
aparncia e embalagem;
Todas as alteraes que, potencialmente, podem afetar a capabilidade de processamento do
produto, tais como soldabilidade, resistncia contra solventes e lavagem;
Todas as alteraes que influenciam negativamente os dados de qualidade e confiabilidade
do produto;
Mudana da planta de produo;
Mudanas nas matrias-primas, peas ou ferramentas fornecidas e mudanas no processo
de fabricao ou mtodos de inspeo e teste exceto quando, atravs de anlise crtica,
ficar assegurado que no haver impacto sobre o produto.

A informao ao cliente dever ser encaminhada atravs do formulrio PCN, anexo.

A PCN dever ser aberta pela Engenharia de Produto e identificada com o mesmo n do PQD
que a originou.
A responsabilidade pelo envio da notificao do Marketing de produto. A PCN deve ser
encaminhada para o Marketing Corporativo e Escritrio de Comunicao, para publicao.
Nos casos em que houver acordo, a PCN dever ser encaminhada para assinatura do cliente.
O registro da PCN deve ser arquivado e mantido por, pelo menos, cinco anos.

Para descontinuao do fornecimento de produtos, o cliente deve ser avisado, por escrito, com
antecedncia mnima de 12 meses.
 130

6.1 Planejamento do Produto e Processo

O PQD pode ser iniciado a partir de:

PA (Solicitao de Desenvolvimento Produkt Anfrage),
Entrada do responsabilidade do Marketing.
Planejamento Aes de Melhorias dos Sistemas de Gesto Ambiental e
Qualidade, responsabilidade da Engenharia.
Plano de Racionalizaes, responsabilidade da Engenharia.
Plano de Investimentos, responsabilidade da Engenharia.

Dados de Entrada:
PA, Normas, Desenhos e Acordos de Fornecimento do Cliente.
Requisitos Estatutrios, Regulamentares e Ambientais.
Determinar os Requisitos Requisitos de certificao de produto.
do Cliente Caractersticas Especiais designadas pelo Cliente.
Requisitos especficos do processo de fabricao
Os requisitos para os projetos de alteraes, de iniciativa da
EdB, devem ser os mesmos do projeto original.
Devem-se manter os registros dos requisitos aplicveis.
Resp. Engenharia de Produto.

Os
N
Requisitos
Resp. Engenharia de Produto.
esto
claros?

S Definir metas para confiabilidade (p. e. FIT, PPM, CPK) e

Definir Objetivos e vida til do produto.
Metas para Qualidade Resp. Engenharia de Produto.

Identificar a necessidade para proteo de propriedade

Verificar situao de industrial. Se necessrio, encaminhar solicitao ao QM.
Patente Resp. Engenharia de Produto.

1
 131

O Anlise Crtica do Planejamento

projeto N Resp. Engenharia de Produto.
vivel?

S
Para o caso do PQD originado num PA.
Informar o Marketing Resp. Engenharia de Produto.

Encerrar Projeto Resp. Engenharia de Produto.

Realizar a Avaliao Preencher o formulrio do anexo

Ambiental Prvia Resp. Engenharia de Produto.

N Revisar o Laia caso alguma resposta da Avaliao

Revisar o
LAIA? Prvia tenha sido respondida com Sim.
Resp. Engenharia de Produto.

Conforme IDP 164.

Emitir / Revisar o LAIA Resp. Engenharia de Produto.

Elaborar um plano de todas as aes necessrias para atender os

Elaborar Plano do Projeto requisitos especificados pelo cliente, incluindo os requisitos da
e Desenvolvimento ISO TS 16949. Anexar o Cronograma ao PQD.
Para planos de alteraes de produto ou processo, emitir a PCN.
Resp. Engenharia de Produto.

Iniciar Projeto
Iniciar estgio seguinte.
 132

6.2 Projeto e Desenvolvimento do Produto e Processo

Objetivos; Requisitos do Cliente; PA (incluindo objetivo

de custo do produto);
Plano do Projeto e Desenvolvimento;
Entrada do Caractersticas especiais designadas pelo cliente;
Projeto Requisitos ambientais e estatutrios;
Registros de projetos anteriores.
Resp. Engenharia de Produto.
1

Reunir equipe multidisciplinar, conforme GQ 69.

Designar as caractersticas especiais do produto.
Elaborar / Revisar a FMEA Incluir aes priorizadas para reduzir o risco de
do Produto falhas, no Plano de Projeto e Desenvolvimento.
Anexar ou referenciar o DFMEA ao PQD.
Resp. Lder do Projeto

Dados de sada para o Produto:

Especificaes: NICAP, desenhos, estrutura de materiais,
Emitir documentao do Data Sheet; Poka Yokes do Produto;
Produto Especificaes para matria-prima;
DFMEA, caractersticas especiais do produto;
Plano de Controle do Produto e Critrios de Aceitao;
LAIA do Produto.
Atualizar o Plano de Projeto e Desenvolvimento.
Resp. Engenharia de Produto.

O projeto N Verificao do produto.

atende aos 1 Resp. Engenharia de Produto.
requisitos de
Emitir especificaes para fornecedores e Exame
S
de Amostra.
Considerar requisitos estatutrios e ambientais
aplicveis.
Solicitar amostras para o fornecedor
Materiais N Testar e aprovar a matria-prima, conforme Md.
Desenvolver a
e Fornecedores 304.
matria-prima /
Desenvolvidos Identificar a necessidade de exigncia de um
fornecedores
? PPAP, conforme o prescrito pelo cliente, e
encaminhar o pedido ao fornecedor, quando
S necessrio.
Registrar as aes no Plano de Projeto e
Desenvolvimento
2 Resp. Engenharia de Produto.
 133

2
Dados de entrada:
Dados de sada do produto;
Requisitos especficos do processo;
Metas de produtividade, capabilidade e Investimentos;
Registros de projetos anteriores.
Elaborar / revisar o Fluxograma do Processo.
Elaborar a FMEA e o PC
Reunir equipe multidisciplinar, conforme GQ 69.
de Processo
Designar as caractersticas especiais do processo.
Incluir aes priorizadas para reduzir o risco de falhas, no Plano
de Projeto e Desenvolvimento.
Resp. Lder do Projeto.

Identificar as aes necessrias para desenvolver ou alterar o processo.

Dados de sada para o processo:
Caderno de Especificaes do processo;
Fluxograma, Lay-out e Capacidades de fabricao
PFMEA, caractersticas especiais do processo;
Plano de Controle do Processo e Critrios de Aceitao os critrios de
Desenvolver o Processo aceitao, bem como os mtodos de rpida deteco de no-
conformidades so descritos nos PCs do processo.
Quando apropriado, relacionar os Poka Yokes do processo.
LAIA do Processo.
Atualizar o Plano de Projeto e Desenvolvimento
Considerar requisitos estatutrios e ambientais.
Resp. Engenharia de Processo.

Estabelecer os objetivos para a qualidade, confiabilidade,

Definir dados para manutenibilidade, e viabilidade de medio do processo.
qualidade do processo Resp. Engenharia de Processo.

Preparar amostra a partir dos processos e

Preparar Prottipo materiais disponveis, a fim de verificar o projeto
Resp. Lder do projeto.

Caracterizar amostra.
Testar Prottipo Os dados do produto so provisrios.
Resp. Lder do projeto.

3
 134

Desenvolver Embalagem Projetar, desenvolver e especificar a embalagem final.

Resp. Engenharia de Produto.

O prottipo N
atende aos Anlise Crtica do Prottipo
requisitos de Resp. Engenharia.
entrada?

S
O N Para o caso do PQD
projeto Informar o Marketing originado num PA.
vivel?
Resp. Engenharia.

S
Encerrar Projeto Resp. Engenharia.
1

Elaborar procedimentos de Verificar a necessidade emitir novos

produo, inspeo e teste documentos, ou de atualizar os existentes.
Verificar a necessidade de treinamento.
Resp. Engenharia / QAs / Produo

N Matria-
Verificar a disponibilidade de materiais,
prima e
processo e documentao para fabricao
processo
do lote/srie piloto.
ok?
Resp. Lder do Projeto.
S
Aplicar nos sistemas de medio das
Analisar o Sistema de caractersticas significativas do PC.
Medio Resp. Engenharia.

VERIFICAO
 135

6.3 Verificao e Validao

VERIFICAO

Utilizar as condies mais prximas

Produzir Lote Piloto possveis da situao definitiva de produo
Resp. Engenharia / Produo

Elaborar estudo de capabilidade preliminar do processo,

Testar Lote Piloto para caractersticas especiais do PC.
Demonstrar a adequao da embalagem
Resp. Lder do projeto.

Os
requisitos e N
metas foram VERIFICAO.
atendidos? Resp. Engenharia.

O N
Para o caso do PQD
projeto Informar o Marketing originado num PA.
vivel?
Resp. Engenharia.

S
Encerrar Projeto Resp. Engenharia.
1

Processo N Submeter o produto ao processo de

Aprovar produto
de aprovao aprovao prescrito pelo cliente.
conforme processo
EPCOS Para o PPAP utilizar a IDP128.
do cliente
? Resp. Engenharia de Produto.

4
 136

Encaminhar amostra de teste ao RL,

Realizar ensaios de conforme extenso do projeto.
confiabilidade Resp. Engenharia.

Produto N VALIDAO Quando autorizado ou aprovado pelo

atende aos cliente o projeto pode ser validado antes da concluso dos
requisitos de ensaios de confiabilidade.
uso? Resp. Engenharia.

O N
S Para o caso do PQD
projeto Informar o Marketing originado num PA.
vivel?
Resp. Engenharia.

S
Encerrar Projeto Resp. Engenharia.
1
N Alterao
afeta produto
certificado?

Para alteraes de produtos certificados / homologados por

organismos independentes do cliente (CIDET, VDE, UL,
por exemplo), deve-se
Submeter aprovao ao submeter o projeto de alterao aprovao dessas
organismo Certificador instituies.
Resp. Engenharia.

N O N
Alterao projeto Informar o Marketing
Aprovada ? vivel?

S S
Encerrar Projeto
1

Autorizar o incio da produo

em srie Anlise crtica final do projeto e desenvolvimento.
Liberao para a produo.
Emitir relatrio com a capabilidade preliminar das
caractersticas especiais de produto e processo do PC
Resp. Engenharia.
Final do Projeto e
desenvolvimento
 137

PLANEJAMENTO DA QUALIDADE NO DESENVOLVIMENTO PQD

N PQD: DATA: RESP./LDER:

PLANEJAMENTO

1.1 Origem do Projeto:

PA Ao de Melhoria Plano de Racionalizao Plano de Investimentos
OBJETIVO: Produto Materiais Processo Novo Alterao de Processo
Descrio:
1.2 Requisitos Relacionados ao Produto
Requisitos do Cliente: PA N: Contrato Requisitos Especficos anexos
Processo de Aprovao de Pea: EDB Especfico do Cliente:

Aplicao:

Item de aparncia: No Sim Inspeo de Lay-out:: No Sim

Caractersticas Especiais designadas pelo cliente: No Sim,
Requisitos Estatutrios: No Sim,

Requisitos Ambientais: IDP 222 Outros:

1.3 Requisitos Relacionados ao Processo

Requisitos do Cliente:
Sries de Produtos:
1.4 Objetivos e metas da Qualidade do Produto
Capacitncia Tenso Tolerncia Dimenso Categoria Climtica

Cdigo do Produto Custo PPM CPK Vida til FIT

1.5 Controle de Patente: No Sim,

1.6 Liberao para o Projeto e Desenvolvimento
Projeto Vivel Projeto Invivel
Data Lder do Projeto Marketing Engenharia

Prazo de execuo:
Plano de Desenvolvimento, conforme cronograma anexo.
 138

PROJETO E DESENVOLVIMENTO

Produto (Marcar os documentos anexos ou referenciados)

Data Sheet NICAP Estrutura de Materiais Especificaes de Materiais
FMEA de Produto N Desenhos N: Cdigo Embalagem N
Plano de Controle de Produto N: Critrio de Aceitao:
Caractersticas Especiais do Produto: LAIA N:
Poka Yokes de Produto: No Sim,
2.1.1 Verificao do Produto: Os dados de sada do produto atendem aos requisitos do cliente.
Data Lder do Projeto Engenharia

Materiais (Relacionar os itens novos ou alterados) ver Mdulo 304 - Aquisio

Matria-prima existente Alterao de materiais Matria-prima nova
Item NIFOR N EA Aprovado Necessita PPAP? Requisitos Estatutrios
e Ambientais
No Sim No Sim,
No Sim No Sim,
2.2.1 Verificao da Matria-prima: Matria-prima desenvolvida.
Data Lder do Projeto Compras Logstica

Processo
2.3.1 Definio dos objetivos
Capabilidade: Produtividade: Investimentos:
Descrio:
Dados de sada: (Marcar os documentos anexos ou referenciados)
Caderno de Especificaes Lay-out de fabricao
Fluxograma do processo N FMEA de Processo N
Plano de Controle de Processo N Critrio de Aceitao:
Caractersticas Especiais do Processo: LAIA N:
Poka Yokes de Processo: No Sim,
2.3.2 Dados para qualidade e confiabilidade do processo:
Equipamento MTBF MTTR MSA
 139

2.4 Prottipo
Relatrio de teste do Prottipo.

2.4.1 Anlise Crtica do Prottipo: O prottipo atende aos requisitos do cliente.

Data Lder do Projeto Engenharia de Produto Engenharia de Processo

2.5 Procedimentos de Produo, Inspeo e Teste ( Listar os procedimentos necessrios)

Procedimento Data de emisso reviso Necessidade de treinamento N S, data

VERIFICAO E VALIDAO
3.1 Lote Piloto
Relatrio de teste do Lote Piloto . EPPs de Processo.
Relatrio de ensaio de confiabilidade.

3.2 VERIFICAO:
O Lote Piloto atende aos requisitos e metas do projeto. Projeto Invivel
Data Lder do Engenharia Engenharia Marketing Logstica Produo QA
Projeto Produto Processo

3.3 VALIDAO:
Projeto APROVADO , liberado para produo em srie Projeto REPROVADO
Data Lder do Engenharia Engenharia Marketing Logstica Produo QA
Projeto Produto Processo

Observaes:
 140
ANEXO B Mdulo sobre Desenvolvimento de Fornecedores

1. OBJETIVO
Estabelecer sistemtica para aquisio de materiais e desenvolvimento de fornecedores.

2. MBITO DE VALIDADE
Este procedimento vlido para matrias primas adquiridas pela EdB.
Servios e outros materiais possuem sistemtica prpria.

3. REFERNCIAS
- Manual EdB
- Mdulo 302 Controle de Projeto
- Mdulo 309 - Inspeo e Ensaio de Recebimento
- Mdulo 316 - Manuseio, Armazenagem, Embalagem, Preservao e Entrega Manual de Procedimentos BA
WS
- Mdulo 318 Auditorias Internas
- IDP 105 Logstica
- IDP 128 PPAP
- Manual de Gesto Ambiental da EdB
- IDP 164 Avaliao de Aspectos e Impactos Ambientais
- IDP 166 Instruo de Procedimento para Gesto de Substncias Perigosas
- IDP 222 Procedimento Ambiental para atendimento aos requisitos sobre Substncias Perigosas
- IDP 285 Sistema de suprimentos Supply Chain
- Manual de avaliao de fornecedores SAP
- Contratos de fornecedores

4. DEFINIES

4.1 Fornecedores Classe I

A EdB possui dois tipos de fornecedores: os classe I e os demais sero includos na classe de outros fornecedores.:
So fornecedores a serem priorizados para um trabalho de acompanhamento e desenvolvimento. Esta definio de
priorizao realizada em reunio de fornecedores e mantida na relao de Fornecedores Classe I (Registro de
Qualidade).
A definio de Fornecedor Classe 1 baseada em critrios de avaliao interna, como a relevncia do material para
os demais processos da EdB, a dependncia do fornecedor (nica fonte) e Qualidade e Logstica apresentado
(ndice de Falhas).

A definio dos fornecedores classe I de responsabilidade do QM SQA.

4.2 Fornecedores crticos para o SGA

Sero considerados fornecedores crticos para o SGA:
- Fornecedores de insumos significativos, conforme IDP 164, ou seja, fornecedores fabricantes de produtos
qumicos nacionais cujas compras ultrapassam o valor de 500 kg/ms com verificao no incio do ano
calendrio, os quais a empresa exerce influncia.

4.5 Dados Gerais do Fornecedor

Manual de procedimento DATA: xx/xx/xx

QM SQA
x/15 EDIO: yy
EdB Ltda
 141
Informaes gerais do fornecedor, como por exemplo: razo social, principais fornecedores, principais clientes,
capacidade produtiva, etc.

4.6 Dados Tcnicos Sistema da Qualidade e Ambiental

Informaes relativas a Qualidade, Meio Ambiente e Sade Ocupacional da empresa. Check-list define questes
como Prioritrias (P) e Desejveis (D). A estas so atribudos os valores de (2) e (1) respectivamente.

5. RESPONSABILIDADES
Cabe ao chefe do setor e/ou pessoa por ele indicada o desenvolvimento das atividades definidas neste mdulo.
As responsabilidades para o processo de aquisio encontram-se definidas na Tabela a seguir:

Atividade BA SO QM ENG. CS FAB. QM HR

SQA KO/FK KO/FK GA

Solicitar e aprovar os dados gerais do fornecedor, no X

desenvolvimento do fornecedor

Verificar critrios da rea comercial (preo, prazo de entrega, X X

etc.)
Solicitar dados tcnicos atravs de check-list dos Sistemas de X
Qualidade e Ambiental do fornecedor

Analisar os materiais respondidos e definir plano especfico, se X X X X

necessrio

Manter os requisitos de qualidade pertinentes a serem X

atendidos pelos fornecedores devidamente atualizados

Manter os requisitos ambientais pertinentes a serem atendidos X

pelos fornecedores devidamente atualizados

Enviar documentao (NIFor, desenhos, etc.) ao fornecedor X

potencial

Realizar exame de amostra X X

Avaliar exame de amostra X X

Enviar resultado do exame de amostra ao fornecedor X X

Definir os fornecedores Qualidade Assegurada /QA e Sem X X

Teste para o Sistema da Qualidade

Adquirir materiais / produtos considerados crticos na X X

qualidade para produto final e significativos para o meio
ambiente de fornecedores devidamente homologados

Manual de procedimento DATA: xx/xx/xx

QM SQA
x/15 EDIO: yy
EdB Ltda
 142
Acompanhar o desempenho de qualidade dos fornecedores X
Classe I para o Sistema da Qualidade

Acompanhar o desempenho ambiental dos fornecedores X

crticos para o Sistema de Gesto Ambiental

Realizar auditorias de qualidade nos fornecedores, quando X

aplicado

Realizar auditorias ambientais nos fornecedores, quando X

aplicado

Definio de Classes I para o sistema de qualidade X X X

6. PROCESSO DE AQUISIO
O processo de aquisio est estruturado em cinco fases, como seguem:
Homologao de Fornecedores
Dados de aquisio
Acompanhamento do Fornecedor
Desenvolvimento
Qualidade Assegurada

6.1 HOMOLOGAO DE FORNECEDORES

O processo de homologao de fornecedores se d pela necessidade de se desenvolver um novo fornecedor e/ou

material.

6.1.1 Sistema da Qualidade

Ser encaminhado aos fornecedores definidos como estratgicos para o SGQ (classe I) uma Correspondncia
padro (Anexo I) ou similar, definindo os requisitos pertinentes a serem atendidos pelos mesmos, juntamente com os
seguintes documentos:
- Dados Gerais do fornecedor
- Dados Tcnicos - Check-list de Avaliao do Sistema da Qualidade e Ambiental

Os formulrios encontram-se disponvel na rede de informtica Intranet/Aplicaes/Formulrios padro.

a) Classificao para o Sistema da Qualidade - check-list

Sero avaliados do item 1 ao 25 e 40 a 42 e a classificao final ter como base o somatrio conforme a
seguinte frmula:
RA = Resultado da Avaliao
PP = Pontos prioritrios
PD = Pontos desejveis

RA = PP * 2 + PD * 1
RA = 22 * 2 + 9 * 1
RA = 53 pontos totais.

6.1.2 Sistema de Gesto Ambiental

Para o SGA, somente sero homologados fornecedores de insumos significativos, ou seja, aqueles que fornecero
acima de 500 kg/ms de produtos qumicos oriundos do mercado nacional e fabricante dos mesmos, os quais a
empresa exerce influncia.
Para estes potenciais fornecedores, dever ser encaminhada a correspondncia padro (Anexo I), definindo os
requisitos pertinentes a serem atendidos pelos mesmos, juntamente com os seguintes documentos:

Manual de procedimento DATA: xx/xx/xx

QM SQA
x/15 EDIO: yy
EdB Ltda
 143
- Dados Gerais do fornecedor
- Dados Tcnicos - Check-list de Avaliao do Sistema da Qualidade e Ambiental
Os formulrios encontram-se disponvel na rede de informtica Intranet/Aplicaes/Formulrios padro.
Obs.: No sero homologados ambientalmente os demais fornecedores, os quais a empresa no possui influncia,
bem como os fornecedores de produtos qumicos utilizados para testes. Para estes fornecedores, no h restries
para compra para o Sistema de Gesto Ambiental.

a) Classificao para o Sistema Ambiental - check-list

Sero avaliados os seguintes critrios:
1. Embalagens
2. Devoluo de substncias perigosas e/ou resduos
3. MSDS/FISPQ (Dados de segurana do Produto fornecido)
4. Licena de Funcionamento/Operao do rgo Ambiental competente
5. Resultado do check-list
Na avaliao do check-list do item 26 a 39 e a classificao final ter como base a metodologia abaixo:

RA = PP * 2 + PD * 1
RA = 2 * 2 + 12 * 1
RA = 16 pontos totais.

O modelo de tabela para Avaliao da pontuao ambiental final est estabelecido no Anexo II deste procedimento.

6.1.3 Anlise crtica dos dados tcnicos

Para a classificao do fornecedor quanto ao atendimento dos Sistemas da Qualidade e Ambiental dever ser
utilizada a matriz abaixo:

5-3 <3 0 MEIO AMBIENTE

A 33 53 A R1
B 15 32 R2 R1 + R2
C 0 14 NA NA

QUALIDADE

Legenda:
A atende: fornece sem a necessidade de plano de ao
R1 atende com restrio: fornece apresentando plano de ao para o Sistema Ambiental com cpia da Licena de
Operao expedida pelo rgo Ambiental competente vlida ou Protocolo de renovao de licenciamento ambiental
R2 atende com restrio: fornece apresentando plano de ao para o Sistema de Qualidade com implementao
em um ano para itens estabelecidos.
NA no atende: no fornece at o atendimento aos requisitos mnimos.
Obs.: Para o Sistema Ambiental caso no seja constatado a pontuao mxima no critrio n 4 Licena de
funcionamento/operao do Anexo II, necessrio um plano de ao com prazo estabelecido para que o fornecedor
seja homologado.

A lista dos fornecedores crticos para o SGA ser atualizada sempre que houverem novos fornecedores
homologados que obtiveram a mnima pontuao necessria nos critrios ambientais e de qualidade.
OBS.: Quando algum fornecedor crtico no estiver fornecendo a mais de um ano, este ser retirado da lista de
fornecedores crticos para o SGA, conforme informao obtida junto ao setor BA SO na verificao anual.

A lista de fornecedores ambientalmente homologados ser disponibilizada para as reas de Compras pelo HR GA.

6.1.4 Exame da Amostra Aprovado:

- O fornecedor passa a ter dado de QM INFO aprovado no SAP liberando compras por item.
- O fornecedor recebe a documentao definitiva (normas/ desenhos) enviados pela engenharia correspondente.

Manual de procedimento DATA: xx/xx/xx

QM SQA
x/15 EDIO: yy
EdB Ltda
 144
- OBS.: Para Clientes que formalmente solicitarem a TS 16949 verificaremos se h lista de fornecedores
aprovados e qual o mtodo de aprovao de amostras que foi solicitado pelo cliente que deve ser o mesmo
utilizado para os fornecedores.

Exame da Amostra Rejeitado:

- Engenharia ou QM SQA informa o fornecedor e solicita aes corretivas.
OBS.: Os procedimentos adotados para avaliao dos materiais e EAs encontram-se descritos no Mdulo 309
(inspeo e ensaio de recebimento). Se o EA estiver rejeitado, engenharia ou QM SQA informa o fornecedor e emite
EA para o prximo lote/amostras.

6.2 DADOS DE AQUISIO

Aps aprovao do EA (exame de amostra), o item estar liberado para compra, conforme necessidade da fbrica.

Os materiais so adquiridos, conforme procedimentos especficos NIFor - Normas de Fornecimento e desenhos

elaborados pela reas de Engenharia. A NIFor descreve quais so as especificaes que o produto deve atender e
os critrios para sua avaliao. Alteraes em especificaes (normas e desenhos) que afetem o fornecedor, sero
informadas pela Engenharia correspondente a estes, atravs do envio de especificaes atualizadas, objetivando
que os fornecedores utilizem apenas dados atualizados.

Manual de procedimento DATA: xx/xx/xx

QM SQA
x/15 EDIO: yy
EdB Ltda
 145

6.3 ACOMPANHAMENTO DO FORNECEDOR

6.3.1 Sistema da Qualidade

O acompanhamento do desempenho do fornecedor ser feito da seguinte forma:

Teste dos lotes na Inspeo de Recebimento, conforme Mdulo 309;

Processo de levantamento dos indicadores de qualidade de todos fornecedores (Pontualidade e Conformidade)
com periodicidade trimestral,
Processo de acompanhamento de Indicadores de qualidade de fornecedores classe I, ocorre como descrito abaixo:

itens automticos e manuais/ exceto desenvolvimento e cooperao, periodicidade trimestral.

Para os Fornecedores Classe I e outros a serem definidos pelo QM SQA a avaliao de Conformidade se dar
atravs do sistema Supplier Evaluation System conforme descrito no anexo 3 deste mdulo.
Aos demais fornecedores, ser mantido o valor calculado pelo SAP.
Os fornecedores Classe I e outros definidos pelo QM SQA, recebero trimestralmente um relatrio descrevendo seu
desempenho nos indicadores de Conformidade e Pontualidade.

Critrio Peso rateio

Qualidade 29,4% 0 20 40 60 80 100
Inspeo de recebimento 20% Automtico ME63
Retestagem Matria
Prima (fbrica) 20% Automtico ME63
Reao a reclamaes
(SPF) 20% insatisfatrio Satisfatrio Bom Excelente

No possui
Certificao (Sistema de certificao de Certificao Certificao ISO Certificao QS 9000 ou
qualidade) 20% qualidade em preparao 9000:2000 ISOTS16949:2002

QSV/STS (Auditoria) 20% Conforme pontuao de auditoria

Economia 23,5% 0 20 40 60 80 100

Nvel de preo, tendncia Preos
de preos, custos parcialmente
otimizados 100,0% Preos no aceitas aceitos Preos totalmente aceitos

Logstica 29,4% 0 20 40 60 80 100

Entrega no prazo 25,0% Automtico ME63
Adrencia a data
confirmada 25,0% Automtico ME63
Confiana de quantidade 25,0% Automtico ME63

Recusado/ no Definido/ acordo Definido/ Acordo e

cumprimento do Em recente (6 estoque mnimo sendo
Estoque consignado 25,0% estoque estipulado negociao meses) cumprido

Manual de procedimento DATA: xx/xx/xx

QM SQA
x/15 EDIO: yy
EdB Ltda
 146

Ecologia 17,6% 0 20 40 60 80 100

Parte
reciclvel e
parte no
No reciclvel,
reciclvel, reciclagem e Material Material
No reciclvel, disposio disposio enviado para enviado para
disposio feita feita pelo feitas pela reciclagem reciclagem pelo
Embalagem 33,3% pela EdB fornecedor EdB pela EdB fornecedor Embalagem retornvel
Fornecedor
recebe Fornecedor
produto/resdu recebe
Fornecedor no o de produto/resduo
recebe substncias de substncias
produto/resduo de perigosas com perigosas sem Produto fornecido no
Retorno/ eliminao de substncias custos para custos para /gera substncia(s)
substncias perigosas 33,3% perigosas EdB EdB perigosa(s)
No possui Possui LO em vigor ou
LO, mas est Declarao de iseno
ECO-Audit. providenciand Possui LO da necessidade de ter
(Licena de Operao) 33,3% No possui LO o vencida a LO

Responsabilidades e providncias relativas ao processo de acompanhamento de fornecedores Classe I:

Atividade QM BA SO QM HR GA
SQA
Insero de dados manuais no SAP para classe I (periodicidade trimestral). X

Envio de relatrio de acompanhamento para fornecedores (periodicidade trimestral). X

Levantamento, anlise e tomada de aes itens de Qualidade:
Inspeo de recebimento (CO) X
Retestagem Matria Prima (RMP) X
Reao a reclamaes (SPF) X
Certificao (SGQ) X
QSV/STS (Auditoria SGQ) X
Levantamento, anlise e tomada de aes item de Economia :
Nvel de preo, tendncia de preos, custos otimizados X
Levantamento, anlise e tomada de aes item de Logstica :
Entrega no prazo X
Adrencia a data confirmada X
Confiana de quantidade X
Estoque consignado X
Levantamento, anlise e tomada de aes item de Ecologia :
Embalagem X
Retorno/ eliminao de substncias perigosas X
ECO-Audit (Licena de Operao) X

A avaliao geral dos fornecedores determina as aes necessrias:

Avaliao geral Classificao Aes necessrias

Manual de procedimento DATA: xx/xx/xx

QM SQA
x/15 EDIO: yy
EdB Ltda
 147
>/= 90% - 100% Pr requisito para fornecedor Aes necessrias para manuteno do
preferencial cumprimento dos pr-requisitos para
um fornecedor preferencial (meta >
95%)
>/= 80% - < 90% Fornecedor normal Aes necessrias com objetivo de
atender os pr-requisitos para um
fornecedor preferencial
>/= 60% - < 80% Fornecedor satisfatrio para a maioria Aes urgentes necessrias para
dos requisitos melhorar sua classificao
< 60% Fornecedor no satisfatrio Aes urgentes necessrias para
melhorar sua classificao. Fornecedor
passvel de desomologao.

6.3.1.1 Desomologao
O fornecedor poder ser desomologado quando, analisando a sua importncia e a do material fornecido, ficar
caracterizado o no cumprimento dos requisitos tcnicos e comerciais acordados. Esta deciso tomada pelas
reas BA SO, QM SQA, ENG KO/FK ou HR GA.

6.3.2 Sistema Ambiental

O acompanhamento dos fornecedores crticos para o SGA ser realizado atravs de planilha especfica, onde
as informaes sero gerenciadas pelo HR GA.

Caso seja necessrio plano de ao ou informaes adicionais, cabe ao HR GA solicitar estas aos setores de
compras.

Quando o HR GA julgar necessrio, sero realizadas auditorias ambientais nos fornecedores considerados crticos
para o SGA, verificando sua adequao a legislao ambiental aplicvel.

Casos crticos sofrero anlise do HR GA.

6.4 DESENVOLVIMENTO

Para solicitaes de cotao e amostras sero enviados ao fornecedor o formulrio RQF (Requisitos de
qualidade ao fornecedor) contendo as informaes referentes a qualidade necessria do produto. No pedido
de amostra tambm ser referenciado o nmero do RQF. Nos demais pedidos so informados o desenho e
NIFOR.

Caso ocorra alguma mudana nas exigncias de qualidade, ser feita uma nova verso do documento
necessrio, RQF, NIFOR ou desenho e informado o fornecedor.

Consideramos como forma de desenvolvimento dos fornecedores as seguintes aes:

Outros Fornecedores - ocorre atravs do acompanhamento na Inspeo de Recebimento atravs de teste/skip-
lot, certificados de anlise e feed back da produo (retestagem de matria-prima - RMP). As no-conformidades
detectadas so tratadas via Solicitao de Providncias ao Fornecedor - SPF e/ou Request of Supplier
Preventive Measures - RSPM, conforme Mdulo 309.

Fornecedores Classe I alm do descrito para outros fornecedores, pode ser realizada uma auditoria de
processo ou sistema da qualidade e/ou ambiental, utilizando como base os check-list`s que avalia itens ISO
9001/2000 e TS 16949. A execuo da auditoria deve ser feita por uma ou mais pessoas, desde que esta

Manual de procedimento DATA: xx/xx/xx

QM SQA
x/15 EDIO: yy
EdB Ltda
 148
possua experincia tcnica no produto em questo. necessrio que ela esteja habilitada como auditor
interno do Sistema da Qualidade e/ou Ambiental e ter realizado no mnimo 1 auditoria interna acompanhado de
um auditor lder. A periodicidade das auditorias ser a cada 2 anos e avaliaremos a evoluo do fornecedor com
base na pontuao do check-list.
Para os fornecedores classe I poder ser solicitado os planos de controle dos itens comprados pela
EDB para aprovao, os quais sero analisados pelas respectivas engenharias com base em nossas especificaes
(NIFor e/ou Desenho).

A definio dos fornecedores e/ou materiais a serem priorizados definida pelo QM SQA.

A responsabilidade do processo de auditoria em fornecedores do QM SQA e do HR GA.

6.5 QUALIDADE ASSEGURADA QA /SEM TESTE

O objetivo da Qualidade Assegurada o recebimento de lotes de materiais sem teste na Inspeo de Recebimento
avaliamos periodicamente o % de itens QA.

- Pr-condies para ser QA: (Responsvel - QM`s)

Poder ser considerado um fornecedor/material com qualidade assegurada quando este atender os critrios abaixo:

Nmero de lotes fornecidos nos ltimos 12 meses maior ou igual a 6;

Sem problemas de qualidade nos ltimos 12 meses;

- Perda do status de QA:

Os materiais que apresentarem queda do nvel de qualidade, via RMP, perdero o status QA e sero
acompanhados (via laudo ou inspeo) por 6 lotes consecutivos, caso no seja verificado nenhum problema de
qualidade, volta ao status QA.

- Pr condies para ser Sem teste: (Responsvel- Engenharias )

Os itens aps aprovao do EA e sob avaliao da engenharia podem passar a sem teste desde que atendam
um dos critrios a seguir:
_ Recebimento e avaliao de dados estatsticos do fornecedor.
_ Inspeo e/ou ensaios no recebimento (ex.:amostragens baseada no desempenho do
fornecedor.
_ Avaliaes ou auditorias de 2 ou 3 parte nas instalaes dos subcontratados em conjunto
com registros de desempenho aceitveis de qualidade.
_ Avaliao de peas por laboratrios de ensaio credenciados.

Os itens classificados como QA e sem teste devem a cada 2 anos serem reavaliados pelos responsveis, para
sem teste ser feito pela engenharia de acordo com os critrios preestabelecidos e para QA ser realizado pelo
QM executando os testes descritos na NIFOR.

Manual de procedimento DATA: xx/xx/xx

QM SQA
x/15 EDIO: yy
EdB Ltda
 149

LOGO

Anexo I

Gravata , __/__/__

Prezado Fornecedor,

Os Sistemas de Qualidade e de Gesto Ambiental EdB estabelecem, em conformidade com as normas ISO
TS-16949 e NBR ISO 14001, que fornecedores e prestadores de servio atendam as legislaes de meio
ambiente, sade, segurana e requisitos da qualidade aplicveis a suas atividades, produtos, bens e servios.
Os requisitos de qualificao ambiental dos fornecedores da EdB leva em considerao os seguintes
requisitos:
Embalagem;
Retorno de substncias perigosas e/ou resduos;
MSDS;
Licena de funcionamento;
Preenchimento do check-list.

Para tanto, solicitamos a V. Sras. o preenchimento do questionrio em anexo, enviando-o para :

EdB Ltda
Rua xxx
Cidade/Estado CEP xxxxx-xxx

A.C.:

Cabe salientar que a no devoluo no prazo estabelecido implicar em resultado nulo neste quesito, sendo
considerado um resultado insatisfatrio para o nosso sistema de avaliao de fornecedores.

Agradecemos desde j a Vossa participao e colocamo-nos a disposio para os esclarecimentos que se

fizerem necessria. Salientamos que todas as informaes prestadas sero tratadas como de carter
confidencial.

Atenciosamente.

EdB Ltda

p.p. p.p.

Prazo para devoluo: 15 dias aps o recebimento deste.

EdB Ltda
 150

LOGO

Annex I

Gravata , __/__/__

Dear Supplier,

The EDBs Quality and Environmental Management Systems established in accordance to standards TS-16949
and ISO 14001 that suppliers and external companies respect the environmental, occupational health and
safety legal requirements AND Quality requirements that are applicable to its activities, products and services.

Therefore, we apply the answer of the questionnaire in annex and send to:

EdB Ltda
Rua xxx
Cidade/Estado CEP xxxxx-xxx

Att.:

We stand out that if you dont return until the establishment date bellow, your company receive zero points in
this inquiry. This is a bad result in our assessment and approval environmental system.

At once, thanks for your attention. We are available to anwer your doubts if this will be necessary.
All the information here supplies will be attending like confidential.

Best regards,

EdB Ltda

p.p. p.p.

Time to return: 15 days after to receive.

EdB Ltda
 151

LOGO Avaliao de Fornecedores (ANEXO II)

Empresa: Grupo de Avaliao:: 1.______________ 3. ________________ 5. ___________

2.______________ 4. ________________ 6. ___________
Data:
Meio Ambiente
Critrio 0 1 2 3 4 5 No avaliado Avaliao
(mximo 25
pontos)
1.Embalageem EDB faz a X X EDB recicla a X Embalagem
disposio da embalagem 100%
embalagem retornvel ao
fornecedor
2. Retorno de No aceita Aceita retorno Aceita retorno
substncias perigosas nenhum retorno com repasse sem repasse
e/ou resduos X X dos custos para X dos custos para
a EDB a EDB
3. MSDS (Material No forneceu Forneceu
Safety Data Sheet) MSDS MSDS
Dados de segurana do X X X X
produto fornecido
4. Licena de No possui Avaliando Entrou com Possui Licena Possui Licena Possui Licena
Funcionamento documentao pedido junto ao de de de
para protocolo rgo Ambiental Funcionamento, Funcionamento Funcionamento
junto ao rgo porm est atualizada, mas atualizada e
Ambiental vencida no enviou enviou cpia
cpia
5. Preenchimento do <2 2-<6 6 - < 10 10 - < 14 14 - 16 Certificado
Check-list (SQ/SGA)
(1) N. de critrios avaliados: (Mximo 5) Resultado (2) (1): (Mximo 5) (2) Soma de Pontos: (Mximo 25)

EdB Ltda.
 152

Sistema de Avaliao de Fornecedores Anexo III

LOGO

Sistema de Avaliao de Fornecedores EdB Ltda

1 - OBJETIVO

Descrever os mtodos e processos para pontuao do desempenho de qualidade do fornecedor.

Estabelecer meta e monitorar o desempenho dos fornecedores.

2 - ABRANGNCIA

Este procedimento aplica-se as atividades relativas ao monitoramento do desempenho dos fornecedores.

3 - HISTRICO

VERSO/REVISO DATA ALTERAO AUTOR/DEPART APROVADO POR

01/01 02/04/2007 Emisso Alex Melo/QM SQA Marcelo Braga

Inicial Fbio Dulinski /BA SO SQA Eduardo Drehmer

4 FLUXOGRAMA

No Aplicvel

5 DETALHAMENTO

5.1 Supplier Evaluation System

Este sistema permite avaliar os fornecedores baseado em deteco de problemas

de qualidade atravs do processo da EdB LTDA, o que chamamos de Quality Gates. Estas
etapas esto divididas em:
 153

-Inspeo de Recebimento (INCOMING INSPECTION);

-Linha de produo (PRODUCTION LINE);

-Teste de produto acabado (OUTGOING INSPECTION);

-Cliente final (FINAL CUSTOMER);

O nvel de criticidade do problema, bem como a pontuao inerente aumenta a

medida que a deteco do problema gerado pelo fornecedor flua pelo processo.

A pontuao funciona da seguinte forma:

-INSPEO DE RECEBIMENTO = 3 pontos

-LINHA DE PRODUO = 5 pontos
-TESTE DE PRODUTO ACABADO = 7 pontos
-CLIENTE FINAL = 10 pontos

Os fornecedores monitorados via Supplier Evaluation System sero informados de seu

desempenho mensalmente (via Depto de Compras - SQA). Partindo destas premissas, a pontuao
por fornecedor ser registrada e destes resultados ser feito um ranking dos fornecedores da EdB
LTDA e deste ranking todas as aes para melhoria da qualidade de fornecimento sero planejadas.

5.2 Sistema de Auditoria e melhoria contnua de fornecedores

Os fornecedores monitorados atravs do Supplier Evaluation System estaro sujeitos a

auditorias de processo de acordo com as premissas da ISO TS 16949 mesmo no sendo certificados
por esta norma.

A EdB far auditorias em fornecedores durante o ano fiscal 2006/2007 de acordo com as
seguintes premissas:

O sistema de auditoria ser baseado no ranking de fornecedores da EdB, onde os 5

piores fornecedores em desempenho, ou seja, os fornecedores que possurem a maior pontuao ao
final do primeiro semestre fiscal (outubro/2006 a maro/2007) sero indicados para uma auditoria de
processo nos modos de falhas com maior incidncia detectada na EdB (inspeo de recebimento,
linha de produo, teste de produto acabado ou cliente final).

Os outros fornecedores que faro parte do plano de auditoria sero escolhidos de acordo
com a posio estratgica e criticidade para a EdB. Estes fornecedores sero indicados pela equipe
composta pela engenharia, compras, logstica e qualidade para uma auditoria de sistema com foco
para novos desenvolvimentos e melhoria de procedimentos do fornecedor.

5.3 Metas:
 154

Todos os fornecedores recebero metas de pontuao mxima a contar da divulgao

dos resultados, tanto para o restante do ano fiscal 2006/2007 quanto para o prximo ano fiscal
2007/2008.

As metas sero estudadas caso a caso e ser definida pela EdB conforme regras e
procedimentos internos.

5.4 Supplier Rating Card:

Aos fornecedores ser enviado um arquivo contendo os grficos de acompanhamento do

fornecedor durante os meses medidos e o pareto de falhas detectadas pela EdB.

5.5 Classificao:

Os fornecedores sero divididos em faixas, conforme a pontuao que atingirem durante

os meses do ano fiscal. A classificao se dar em faixas como segue abaixo e ser considerada
apenas no critrio qualidade do semestre.

A avaliao considera o primeiro semestre do ano fiscal (Out/06 at Mar/07) e o nmero

de reclamaes est associada pontuao conforme item 5.1:

Faixas de pontuao Classe Penalizao

>200 pontos
Entre 101 - 200 pontos
Entre 51 - 100 pontos
Entre 11 - 50 pontos
< 10 pontos
E Fornecedor Crtico 2
D Fornecedor Crtico 1
C Fornecedor Homologado
B Fornecedor Aprovado
A Fornecedor Preferencial
 155

5.5.1 - Detalhamento:

Fornecedor Preferencial: Fornecedor que tem preferncia para novas cotaes e projetos.

Fornecedor Aprovado: Fornecedor participa de novas cotaes e projetos, ficando em segundo

plano com relao ao fornecedor preferencial.

Fornecedor Homologado: Fornecedor necessita de melhorias para se manter na base de

fornecedores. Pode participar de novas cotaes, desde que apresente um plano de ao para as
melhorias com aes, prazos e responsveis de modo que melhor sensivelmente seu desempenho de
qualidade nos meses seguintes. Est sujeito a auditorias de processo.

Fornecedor Crtico 1: Fornecedor necessita de melhoria dos indicadores de qualidade e est

sujeito a auditorias de processo por parte da EdB. No participa de novas cotaes e projetos. Neste
caso, um novo fornecedor deve comear a ser desenvolvido pela EdB e sua participao no volume de
compras ser revista.

Fornecedor Crtico 2: Fornecedor necessita de melhorias urgentes de processo e est incluso no

plano de auditorias por parte da EdB. No participa de novas cotaes e corre o risco de perder o status
de fornecedor homologado, correndo ainda o risco de perder o negcio com a EdB.

Estas regras valem at o final do ano fiscal 2006/2007 e em caso de modificao sero comunicadas
pela EdB apropriadamente.
 156

ANEXO C Relatrios Semanais