FUNDAO GETULIO VARGAS

ESCOLA BRASILEIRA DE ADMINISTRAO PBLICA

CENTRO DE FORMAO ACADMICA E PESQUISA
CURSO DE MESTRADO EXECUTIVO

ESTUDOS DE CASO: IMPLANTAO DE

SISTEMAS ERP - UMA ANLISE CRTICA
LUZ DA METODOLOGIA DE PROJECT
MANAGEMENT

DISSERTAO APRESENTADA ESCOLA BRASILEIRA DE ADMINISTRAO

PBLICA E DE EMPRESAS PARA OBTENO 00 GRAU DE MESTRE

MARIA GABRIELA SOBRAL GIL

Rio de Janeiro 2002

FUNDAO GETULIO VARGAS

ESCOLA BRASILEIRA DE ADMINISTRAO PBLICA
CENTRO DE FORMAO ACADMICA E PESQUISA
CURSO DE MESTRADO EXECUTIVO

TTULO

ESTUDOS DE CASO: IMPLANTAO DE SISTEMAS ERP - UMA ANLISE

CRTICA LUZ DA METODOLOGIA DE PROJECT MANAGEMENT

DISSERTAO DE MESTRADO APRESENTADA POR:

MARIA GABRIELA SOBRAL GIL

APROVADO EM 26 / 11 / 2002
PE A COMISSO EXAMINADORA

DOUTOR EM PESQUISA OPERACION

DoUTOR EM PLANEJAMENTO

DOUTOR EM ENGENHARIA DA PRODUO

IV

Ao meu marido, famlia e amigos que de alguma forma contriburam para a concluso deste
estudo.

AGRADECIMENTOS

Ao professor Alexandre Linhares pela sua coragem ao ter aceito o desafio de, distancia, me
ajudar a finalizar este trabalho e por todo o incentivo e dicas que me deu.

Ao Jos Paulo e equipe da secretaria do mestrado pela ajuda que sempre me deram, sem ela,
eu no estaria escrevendo estas palavras hoje. Muito Obrigada pela ajuda.

Aos membros da banca examinadora, por participarem de um momento to especial como

este para mim.

Ao meu marido Marcelo e minha famlia querida, pelas horas que deixei de lhes dar a
ateno merecida para poder estudar e preparar este trabalho.

Ao meu amigo Ulysses pelas horas dedicadas s discusses dos fundamentos de Project
Management.

A todos aqueles no mencionados anteriormente que, de alguma maneIra, direta ou

indiretamente, contriburam para a realizao desta dissertao.

VI

"Descobri como bom chegar

quando se tem pacincia.
E para se chegar a qualquer lugar,
descobri que no necessrio dominar a fora e sim a razo.
Descobri que acima de tudo necessrio
querer"

AmyrKlink

vii

suMRIo
Pgina
LISTA DE FIGURAS

Xl

LISTA DE TABELAS

Xll

LISTA DE TERMOS E SUAS DEFINIES

Xlll

RESUMO

XVI

ABSTRACT

XVll

1. INTRODUO

1.1. Contextualizao do problema

1.2. Relevncia do estudo

1.3. Delimitao do estudo

1.4. Objetivo

1. 5. Organizao do Estudo

2. REFERENCIAL TERICO

2.1. A metodologia de Project Management e os sistemas de ERP

2.1.1. A metodologia de Project Management

9
9

2.1.1.1. O que Projeto

2.1.1.2. O gerenciamento de projetos e suas reas de conhecimento

12

2.1.1.3. O processo de Project Management

19

2.1.1.4. Principais grupos envolvidos no projeto

26

2.1.2. Sistema de ERP

27

2.1.3. Um projeto de implantao de um sistema de ERP

32

2.2. Formao de Equipes e a Liderana

2.2.1. A formao de equipes de projeto

35
35

2.2.1.1. A estrutura da equipe de projeto

38

2.2.1.2. Criando uma identidade para a equipe de projeto

41

2.2.1.3. Processos motivacionais

42

V111

Pgina

2.2.1.4. Criando uma equipe de projeto de alta performance - uma

equipe de sucesso

43

2.2.1.5. A tomada de deciso na equipe

46

2.2.1.6. Conflitos na equipe de projeto

47

2.2.1.7. A desmobilizao da equipe

49

2.2.2. Liderana

51

2.2.2.1. Principais caractersticas da Liderana

51

2.2.2.2. Liderana e Poder

54

2.2.2.3. Diferena entre gerentes de Projetos e Lderes

55

2.2.2.4. A liderana como diferencial na Gesto de Projetos

57

2.2.2.5. Algumas competncias para um Lder de Projeto

58

2.3. A Mudana, o Change Management e algumas consideraes sobre

Cultura Organizacional
2.3.1. Identificando os fatores motivadores da Mudana

63
63

2.3.1.1.Como a mudana na estrutura organizacional vem sendo tratada

pelos estudiosos

64

2.3.2. O que Change Management

67

2.3.2.1. Fator Mudana

68

2.3.2.2. Um projeto de mudana e o processo de Change Management

70

2.3.2.3. Identificao dos Stakeholders

71

2.3.2.4. A comunicao

73

2.3.2.5. A formao de equipe e o Change Management

75

2.3.2.6. Outras consideraes sobre liderana e a formao da equipe

~~~

2.3.2.7. Problemas maIS comuns encontrados em um projeto de

mudana
2.3.3. Consideraes sobre a Cultura Organizacional

79
83

2.3.3.1. A Cultura de uma Organizao

83

2.3.3.2. A Cultura e os Projetos

84

IX

Pgina
2.3.3.3. A Cultura das Equipes de Projeto

86

2.3.3.4. Alguns impactos negativos da Cultura Organizacional em

projetos

87

3. METODOLOGIA

89

3.1. Introduo

89

3.2. Universo e Amostra

90

3.3. Seleo dos Sujeitos

91

3.4. Coleta de Dados

91

3.5. Tratamento dos Dados

91

4. DESCRIO DOS CASOS

92

4.1. Empresa A

93

4.1.1. Dados Gerais

93

4.1.2. Histrico da Implantao

93

4.1.3. Os fatores da Mudana, a seleo do Produto e as mudanas que a

implantao do sistema exigiu da empresa

95

4.1.4. A Influncia da Cultura da Empresa no Projeto, na Gerncia e na

Equipe de Projeto

98

4.1.5. A metodologia de Formao da Equipe de Trabalho

100

4.1.6. Os Gerentes de Projeto e a Liderana

105

4.1.7. O processo de Change Management

111

4.1.8. A Finalizao do Projeto

113

4.1.9. Os Resultados do Projeto

114

4.2. Empresa B

117

4.2.1. Dados Gerais

118

4.2.2. Histrico da Implantao

118

4.2.3. Os fatores da Mudana, a seleo do Produto e as mudanas que a

Pgina
implantao do sistema exigiu da empresa

120

4.2.4. A Influncia da Cultura da Empresa no Projeto, na Gerncia e na

Equipe de Projeto

121

4.2.5. A metodologia de Formao da Equipe de Trabalho

122

4.2.6. Os Gerentes de Projeto e a Liderana

124

4.2.7. O processo de Change Management

128

4.2.8. A Finalizao do Projeto

130

4.2.9. Os Resultados do Projeto

131

5. ANLISE DAS INFORMAES COLETADAS

133

5.1. Histrico da implantao nas duas empresas

133

5.2. Os fatores da mudana, a seleo do produto e as mudanas que essa

implantao exigiu da empresa

134

5.3. Influncia da cultura das empresas no projeto, na gerncia e na equipe de

projeto

135

5.4. Aspectos da metodologia utilizada por cada uma das empresas na

formao das equipes de trabalho

137

5.5. O perfil dos gerentes de projeto e da alta administrao, os conflitos e os

aspectos de liderana no projeto

138

5.6. O processo de Change Management - a comunicao, a integrao das

equipes e o treinamento

140

5.7. Os resultados obtidos pelo projeto - o processo de finalizao e os

resultados obtidos em termos de escopo, prazos e custo.

140

6. CONCLUSES E RECOMENDAES

142

REFERNCIAS BIBLIOGRFICAS

155

ANEXO - QUESTIONRIOS PARA ENTREVISTAS

158

xi

LISTA DE FIGURAS

Pgina
Figura I - Restrio Tripla

10

Figura 11 -reas de Atuao do Project Management

14

Figura III - Ciclo de Vida de um Projeto

20

Figura IV - Inter-relacionamento entre os grupos de processos no desenvolvimento

~~~~

Figura V - Sobreposio de grupos de processos dentro das fases do projeto

25

Figura VI - Processo de gerenciamento e suas funes

25

Figura VII - Viso Geral do ERP

29

Figura VIII - Estrutura Proposta para um Projeto de ERP

33

Figura IX - Processo Decisrio

47

Figura X - Detalhamento da estrutura de problemas mais comuns do encerramento

de um projeto

50

Figura XI - Carter Organizacional

66

Figura XII - Mapeamento do apoio dos Stakeholders com referncia mudana

pretendida

72

Figura XIII - Estrutura de equipe peso pesado

78

Figura XIV - Equipe do Projeto de ERP da empresa A

107

Figura XV - Equipe do Projeto de ERP da empresa B

125

Xli

LISTA DE TABELAS

Pgina
Tabela A - Caractersticas de Equipes de Projeto de Sucesso

44

Tabela B - Principais diferenas entre Gerentes e Lderes

56

Tabela C - Anlise comparativa entre Bons e Maus Lderes

60

Tabela D - Principais concluses:

142

Tabela E - Principais Recomendaes

153

xiii

LISTA DE TERMOS E SUAS DEFINIES

Best Practices - Como so conhecidas as melhores prticas de negcio.

Change Management - Tcnicas que permitem o gerenciamento de projetos onde o processo

de mudana e transio ocorre, objetivando reduzir resistncias e comprometer os recursos
envolvidos com o sucesso do projeto.

CPD - Centro de Processamento de Dados

Empowerment - processo no qual se criam condies e habilitam-se as pessoas de todos os

nveis da empresa para assumirem responsabilidades.

ERP - So sistemas integrados de software que integram todos os processos, regras e

aplicaes para automatizar toda a cadeia de suprimentos; so baseados em tecnologia que
viabiliza a atuao e controle por processos em contraponto a atuao e controles
departamentais; fornecem uma arquitetura de informaes que une toda a empresa, inclusive
suas diversas plantas e pases. Por integrar as informaes de todas as plantas, negcios e
departamentos da empresa atravs de uma base contbil nica. Entre outras coisas, o ERP
viabiliza anlises em tempo real de diversas questes fundamentais para a gesto de uma
empresa.

Fast Tracking - Com se chama o processo em que produtos (Deliverables) de uma fase de
projeto so iniciados quando outros ainda no foram concludos. Isto ocorre quando os riscos
envolvidos no projeto so aceitveis

Gap 's - Como so chamadas as diferenas existentes entre o "modelo" sistmico desejado e o
disponvel. Para minimizar tais diferenas, necessrio que o projeto recorrer a programao
adicional, conhecidas como customizaes.

Go Live - como se chama o momento em que o sistema, aps parametrizado e testado,

posto em funcionamento.

XIV

IT OU IT - Tecnologia de Informao

Kick Of! - Como so chamados os eventos onde se d oficialmente por iniciado o projeto,
onde so apresentados os membros da equipe e so apresentados os objetivos do projeto.

Learning Meetings - como so chamados os encontros de aprendizado realizados entre

todos os membros da equipe ao trmino do projeto (reunies de encerramento), cujo objetivo
avaliar permanentemente o aprendizado obtido com o mesmo.

Overheads - excesso de mo de obra.

Projetos - Um projeto pode ser entendido como uma combinao de recursos da organizao
que, uma vez reunidos, permitiro a criao de algo inexistente previamente. Ele permitir
empresa, alcanar seus objetivos operacionais (no curto prazo), estratgicos (no longo prazo) e
organizacionais. Possuem ciclos de vida distintos e comeam com uma idia, definio do
desenho, execuo e implantao.

Projetos de mudana - Projeto de mudana constitui-se em justificativas persuasivas em

favor de modificaes que justifiquem seu esforo. Um projeto de mudana dever ser claro,
conciso, articulado, lgico, bem documentado e motivador. Deve trazer um senso de urgncia.
Deve incentivar as pessoal envolvidas a agir.

Project Management - Project Management so um conjunto de tcnicas e processos que

permitem gerenciar Projetos. Segundo definio do Instituto de Project Management "a arte
de dirigir e coordenar recursos humanos e financeiros".

PMI - The Project Management Institute

PMBOK - Project Management Book of Knowledge - referncia bibliogrfica bsica para os

estudiosos de Project Management, editada e atualizada periodicamente pelo PMI,
compilando informaes e dados resultados de pesquisa e pratica vivenciadas em projetos em
geral que se utilizam das tcnicas de Project Management.

xv

Stakeholders - Stakeholders so indivduos ou grupos que, em algum momento durante o

ciclo de mudana de um projeto, afetaro ou sero afetados pelo processo.

Sponsor - como chamado o patrocinador do projeto.

Standard - tenno em ingls para a palavra padro.

Supply Chain - tenno em ingls para o conceito de cadeia logstica integrada

Team Building - Construo de um esprito de Equipe

Trade Of!- tenno em ingls para a palavra troca em portugus.

xvi

RESUMO

Este documento constitui-se em uma dissertao de mestrado, requisito parcial para a

obteno do grau de Mestre em Gesto Empresaria e Pblica.

Este estudo procura mostrar que a adoo dessa nova tecnologia atravs de projetos de
implantao de sistema de ERP no s mudam processos administrativos como tambm
produtos, servios e estruturas organizacionais e que a sua implantao se constitui em um
grande projeto que envolve um nmero considervel de recursos e tempo das organizaes.
Este estudo procurar mostrar tambm que os impactos que tais projetos trazem, so mais
fortemente sentidos ou no pela organizao de acordo com uma srie de fatores, entre eles, a
resistncia mudana e o quanto a organizao est preparada para enfrentar essas mudanas,
o medo da perda do emprego pela adoo de uma nova tecnologia, problemas com a falta de
comunicao das mudanas, questes relacionadas cultura organizacional vigente, a falta de
envolvimento da alta administrao, entre outras. Para gerenciar todas essas variveis, as
organizaes modernas adotam tcnicas para garantir o sucesso da implantao dessas novas
tecnologias.

estudo aqui proposto tem como objetivo determinar at que ponto a utilizao de

metodologias e de tcnicas de Project Management o suficiente para que esses projetos

alcancem o sucesso esperado pelas organizaes. A quantidade de variveis que influenciam o
resultado de um projeto so muitas e cada uma delas possui um papel importante que deve ser
avaliado.
As concluses desta pesquisa demonstram que o sucesso de um projeto nem sempre se resume
a atingir os objetivos inicialmente propostos, relativos ao cumprimento do prazo, escopo e
custo de um projeto, conforme define a metodologia de Project Management. Outros aspectos
considerados por essa metodologia, se melhor ou pior aplicados, tambm contribuem para o
sucesso ou fracasso de um projeto de implantao de um sistema de ERP sendo o seu fracasso
traduzido ou no, no cumprimento do prazo, do escopo inicialmente previsto ou no custo
inicialmente calculado. Outros aspectos que no apenas a aplicao correta da metodologia de
Project Management contribuem para os resultados alcanados pelo projeto.

XVll

ABSTRACT

This document constitutes a thesis for a partial fulfillment for getting a master's degree in
Public and Business Management.

Our subject is an analysis of two case studies about ERP's system implementation and the
techniques of Project Management used as a methodology for their implementation. The study
states that the use of the Project Management methodology by itself is not enough to
guarantee the success of an ERP's system implementation. Other issues, such as the way the
organization deals with change, the Change Management methodology presented on projects,
the project team management, as well as the building of a project team is dealt within a
project affects the success ofan ERP's system implementation. AIso, some cultural features of
the organization influence the results obtained as well as leadership of its project managers.

The main results of this study are the theoretical building of the thematic support conceming
ERP' s system implementation. The use of interviews aiming at verifying the way the issues
treated in this study are dealt on ERP' s system implementation projects and how those aspects
influence positively or negatively on the success of those projects.

The conc1usions from this research show that not only the use of the Project Management
methodology is enough to guarantee the success of such projects. The success is not always
reached by meeting the initial expectations of cost, time and budget as the Project
Management methodology states primarily. Other features treated in this research also
contribute to its failure or success such as the project team building, leadership, the Change
Management techniques as well as cultural elements.

INTRODUO

1.1 Contextualizao do problema

As organizaes modernas se vem envolvidas num ambiente dinmico e de incertezas, onde

mudanas ocorrem diariamente em uma velocidade no antes imaginada. "As sociedades em
geral (os indivduos, as famlias) e no apenas as organizaes, tm sofrido os impactos do
vendaval de mudanas que est sendo chamado de idade da informao, terceira onda,
sociedade ps-industrial, era da comunicao, sociedade de servios ou ainda sociedade do
conhecimento" (Freitas, 1999:30). Estar preparado para essas mudanas o desejo da maioria
dessas organizaes.

A evoluo da tecnologia de informao tem contribudo significativamente, no s como um

estmulo, mas tambm como uma ferramenta que possibilita essa mudana, permitindo s
empresas se prepararem para um futuro de incertezas. Temos acompanhado o processo vivido
mundialmente por organizaes que tm procurado, como soluo para as presses
provocadas pelas mudanas de mercado e pela concorrncia, os sistema integrados de gesto
ou seja, sistemas de Enterprise Resource Planning (ERP) devido necessidade que elas tem
de serem mais geis no s no acompanhamento do seu negcio, como tambm no
lanamento de novos produtos, na avaliao de alternativas de negcio, na incorporao de
outras empresas adquiridas e na troca de informaes com seus clientes e fornecedores. Os
sistemas de ERP so uma resposta da tecnologia de informao a esses desafios. A
substituio dos antigos pacotes de software no integrados por modernos sistemas de
informao e gesto integrados, cada vez mais ocupar espao nas estratgias das
organizaes modernas. Essas substituies, na maioria das vezes, no se restringem apenas a
mudanas de tecnologia. Com elas, as organizaes so levadas a mudar processos, pessoas,
estruturas e culturas. Como gerenciar simultaneamente todos esses aspectos?
A metodologia de Project Management l tem sido uma grande e importante ferramenta que
veio possibilitar e ajudar as organizaes no gerenciamento dessas mudanas. O conceito de

Project Management, de acordo com Cleland (1999), "surgiu na dcada de 60. Inicialmente
presente na construo civil, foi em seguida incorporado a projetos em outras reas como, por
exemplo, na construo de armamentos militares,,2.

Inicialmente "reconhecido como uma filosofia, um processo de gerenciamento de atividades

em organizaes caracterizadas por possurem distintos ciclos de vida e que, alm disso,
possussem um sistema de gerenciamento que se utilizasse de uma complexa matriz
organizacional,,3. A partir de 1957, outras tcnicas especficas de planejamento, controle e
seqnciamento de atividades surgiram, entre elas, destacamos o PER~, CPM5, etc. Sistemas
de informao e de controle de custos foram desenvolvidos para auxiliar no controle desses
projetos e at mesmo sistemas computacionais mais complexos passaram a ser utilizados
como ferramentas de gesto de projetos, como por exemplo, o MS Project da Microsoft.

o gerenciamento de projetos passou a ter tambm um papel estratgico no gerenciamento de

longo prazo e, em conjunto com outros elementos tais como estratgias funcionais, polticas,
procedimentos e planos de ao, permite que seja um elemento extremamente til no
gerenciamento estratgico da empresa.

Atualmente, a metodologia de Project Management serve de referencial terico para as

metodologias desenvolvidas por empresas de consultoria, especializadas na implantao de
sistemas de ERP.
Segundo 1. LeRoy Ward, em seu livro Project Management Terms - a working glossary, o Project
Management definido como a aplicao de conhecimentos, habilidades, ferramentas e tcnicas nas atividades
de um projeto de forma a alcanar ou superar as necessidades dos Stakeholderss e as expectativas previstas
para um projeto.
M
2 CLELAND , David I. Project Management. Strategic Design and Implementation. 3 Edition. Singapore:
McGraw-Hill,1999.
3 Idem.
4 Segundo 1. LeRoy Ward, em seu livro Project Management Terms - a working glossary, PERT significa
Program Evaluation and Review Technique. Tcnica orientada a eventos, em tcnicas de analise de uma rede
de eventos baseada em probabilidades, usadas para estimar a durao de um projeto quando existe um elevado
grau de incerteza em relao durao das atividades de um indivduo. PERT aplica o mtodo do caminho
crtico para mensurar uma estimativa de durao das atividades.
5 Segundo J. LeRoy Ward, em seu livro Project Management Terms - a working glossary, CPM significa
Criticai Path Method sendo uma tcnica utilizada para prever a durao de um projeto atravs da anlise de
uma seqncia de atividades que possuem pouca flexibilidade de tempo para serem concludas.
1

1.2 Relevncia do estudo

o presente estudo justifica-se a partir das seguintes constataes:

As organizaes, ao optarem pela implantao de um sistema de ERP, acreditam que pelo
simples fato de selecionarem o melhor sistema disponvel no mercado bem como uma
consultoria experiente que lhe d suporte metodolgico para a implantao desse sistema de
ERP, embasado em metodologia de Project Management, possuem as condies suficientes
para garantir o sucesso do projeto.

Entretanto, essas organizaes se esquecem de atentar para outros fatores como, por exemplo,
se a organizao est preparada para a mudana, se a metodologia de Project Management
est sendo bem empregada, se a consultoria est adotando as tcnicas de Change Management
adequadas, entre outros. Fatores como esses, podero contribuir para a obteno de melhores
ou piores resultados quando nos referimos a um projeto de implantao de um sistema de
ERP.

Ao estudar as variveis implcitas no Project Management, acreditamos estar contribuindo

para o aprendizado dessa tcnica bem como para a melhoria dos processos de implantao de
projetos que se utilizam de alguma forma ou em algum grau, da metodologia de Project
Management.

1.3 Delimitao do estudo

As tcnicas de Project Management incorporam um srie de fases relacionadas ao seu

processo, organizao e estrutura. O presente trabalho no pretende se aprofundar no
detalhamento de todas as fases do Project Management. As principais fases sero
apresentadas apenas para elucidar o assunto queles que no possuem domnio do tema.

Nossa abordagem ir procurar atentar para questes que tem despertado grande interesse de
estudo como: Gerenciamento da Mudana, Formao de Equipes, Liderana, Change

Management, bem como aspectos relacionados a Cultura Organizacional entre outros.

Nosso estudo ir se limitar a projetos de implantao de software ERP, uma vez que este tipo
de projeto implica, na sua maioria, em mudanas no desenho organizacional e no desenho de
processos das organizaes o que por si s pode provocar profundas mudanas em uma
organizao. Procuremos focar igualmente, que estratgias esto sendo adotadas pelas
organizaes para suavizar o processo natural de mudana que se estabelece no momento em
que a empresa implanta um sistema de ERP.

Da mesma forma, a implantao de sistemas ERP, adotada pelas organizaes como um

diferencial competitivo, envolve a alterao de seus processos, polticas internas e prticas de
gesto. Ela requer um tratamento especfico dentro do contexto de transformao
organizacional uma vez que alcanar o sucesso na implantao desses sistemas, lhe confere
um diferencial competitivo, uma medida de sucesso ou fracasso na estratgia da organizao

Como um desses instrumentos e com o objetivo de garantir o sucesso na implantao de

sistemas de ERP, que as organizaes passaram a adotar metodologias especficas de
gerenciamento de projetos. Estas metodologias foram adaptadas por diversas empresas de
Consultoria de Empresas, constituindo-se na base metodolgica para suportar a implantao
de sistemas de ERP. Embora cada uma dessas metodologias adote um nome especfico, de
acordo com empresa de consultoria que a aplica, todas elas possuem uma origem comum, a
metodologia de Project Management.

Este trabalho no tem como objetivo analisar detalhadamente cada uma dessas metodologias
nem compar-las metodologia do PMI6 Mas sendo esta a base metodolgica que suporta as
demais metodologias utilizadas para a implantao de sistemas de ERP, faremos uma reviso

The Project Management Institute

da bibliografia de Project Management existente de forma a permitir homogeneizar os seus

principais conceitos aos leitores deste trabalho.

1.4 Objetivo

Este trabalho tem como objetivo estudar casos reais de implantao de sistemas de ERP, que
utilizaram metodologias baseadas em tcnicas de Project Management, com o intuito de
melhor compreender os problemas que estariam supostamente surgindo devido s falhas na
aplicao dessas tcnicas, por parte da organizao. At que ponto a utilizao das tcnicas de
Project Management pode ser considerado o fator determinante que permitir garantir o

sucesso da implantao de projetos de ERP.

o presente trabalho prope uma anlise crtica dessas tcnicas levando-se em considerao,
por exemplo, que fatores levam as organizaes a mudar, como a Organizao trata a

Mudana, como o Gerenciamento da Mudana e o Gerenciamento da Comunicao afetam

o bom andamento e o sucesso de projetos de ERP. Adicionalmente, como a Formao de

Equipes importante para garantir o sucesso de projetos de ERP. Se a questo da Liderana

um fator crtico de sucesso para os projetos de ERP e por fim, como a Cultura

Organizacional pode influenciar um projeto de implantao de um sistema de ERP.

Ao longo do estudo, sero discutidas outras variveis que afetam os resultados de projetos
gerenciados com base nas tcnicas de Project Management.

Sero tambm apresentados os beneficios qualitativos do Project Management para o sucesso

de projetos de implantao de software ERP.

1.5 Organizao do Estudo

Este estudo foi desenvolvido em 6 captulos, estruturados da seguinte forma:

Captulo 1, introdutrio, onde o trabalho contextualizado. Onde os objetivos so

apresentados, seguidos da justificativa do estudo e da delimitao das suas fronteiras.

O captulo 2 apresenta uma reviso do referencial terico da dissertao. Esta reviso inclui os
principais fatores motivadores das mudanas dentro das organizaes, uma reviso das
principais tcnicas de Change Management e a importncia da aplicao destas em um projeto
que envolve um elevado grau de mudana. Essa reviso aborda tambm os principais
conceitos de Project Management, a importncia da formao das Equipes de Projeto e o fator
Liderana presente na equipe de projeto e nas caractersticas pessoais dos gestores e lderes de
projeto. A seguir, fazem-se consideraes sobre a cultura dentro da organizao, dentro do
projeto em si e dentro da prpria equipe de projeto.

No captulo 3, descrita a Metodologia adotada, isto , como o estudo foi feito, indicando o
desenho e o mtodo da dissertao. Mais especificamente, este captulo busca esclarecer e
justificar o mtodo utilizado, identificar os tipos e as fontes de informaes necessrias para
responder s questes da dissertao e os procedimentos para analisar as informaes
coletadas.

No captulo 4, so apresentados dois estudos de casos, relatando caractersticas e situaes

ocorridas em de projetos de implantao de sistema de ERP em duas empresas. Esses casos
foram montados atravs de entrevistas com pessoas que tiveram uma participao ativa na
implantao desses sistemas nas 2 empresas analisadas. A empresa A uma empresa do ramo
de papel e celulose. O sistema de ERP foi implantado nessa empresa em 1997 enquanto que a
empresa B do setor de telecomunicaes e esse mesmo sistema foi implantado em 1999.

No captulo 5, objetiva-se a analisar as informaes coletadas atravs desses estudos de caso,

buscando relacionar semelhanas e diferenas de padro em cada uma dessas implantaes.

Finalmente o captulo 6 conclui e encerra o estudo, propondo recomendaes para empresas

que pretendem implementar sistemas de ERP bem como trata de apontar situaes e fatos que
merecem ser estudados com uma maior profundidade em pesquisas futuras.

Seguem-se as referencias bibliogrficas e um anexo contendo o questionrio utilizado nas

entrevistas realizadas, base para a elaborao dos estudos de caso.

REFERENCIAL TERICO

Neste captulo so apresentadas as contribuies de alguns dos principais estudiosos acerta

dos temas relacionados. Inclumos tambm bibliografia de autores no diretamente
relacionados metodologia de Project Management mas que em seus estudos relatam temas
profundamente relacionados com a abordagem que este estudo procura dar ao tema gesto de
projeto de implantao de sistemas de ERP.

estudo dos tpicos que integram o presente trabalho estabelece um referencial terico

fundamental para a pesquisa e consolidao dos objetivos propostos neste trabalho. Sua
construo busca fornecer a compreenso necessria para a anlise dos fatores relacionados
com o sucesso ou fracasso de projetos de implantao de sistemas de ERP.

Este captulo est estruturado em 3 sees. Na primeira seo, faremos a fundamentao

terica deste trabalho, assente na metodologia de Project Management, e por isso iniciamos a
reviso bibliogrfica por este tema. Tambm apresentaremos uma conceituao sobre sistema
de ERP e faremos uma breve apresentao de um tpico projeto de implantao de um sistema
deERP.

Em seguida, abordaremos questes relacionadas com a formao de equipes e como esta

questo influencia no sucesso de projeto de implantao de ERP. A seguir, trataremos o tema
Liderana, como a liderana dentro do projeto, principalmente relacionada gesto e
coordenao de projeto, funciona como um diferencial no s para a equipe como para o
projeto em si.

Em seguida, iremos rever o que a teoria nos fala sobre a mudana e a resistncia que esta
enfrenta dentro das organizaes, principalmente nas organizaes que se encontram em
processo de implantao de um sistema de ERP juntamente com uma anlise das tcnicas
Change Management e como a utilizao destas tcnicas vai contribuir para facilitar o

processo de mudana e a comunicao interna e externa ao projeto de ERP. Faremos tambm

algumas consideraes sobre como a Cultura Organizacional vista pelos estudiosos do
assunto e como ela afeta o projeto de implantao de sistemas de ERP.

2.1 A metodologia de Project Management e os sistemas de ERP

Esta seo tem como objetivo mostrar como se compe a estrutura, organizao e
operacionalizao de um projeto bem como qualificar as principais fases do Project
Management. Nesta seo apresentamos tambm uma conceituao sobre sistemas de ERP e

apresentamos um tpico projeto de implantao de um sistema de ERP.

2.1.1

2.1.1.1

A Metodologia de Project Management

O que Projeto

De acordo com o PMBOK, um projeto um empreendimento temporrio com o objetivo de

criar um produto ou servio nico. 7 Sua caracterstica temporria por possuir incio, meio e
fim muito bem definidos e por seguir uma seqncia clara e lgica de eventos, os quais so
conduzidos por pessoas sempre respeitando os parmetros de prazo, custo e qualidade. Estes
parmetros tambm so conhecidos por "restrio tripla"s, de forma que so representados por
um tringulo conforme mostrado na Figura I - Restrio Tripla, a seguir:

7
8

Guia do PMBOK, 2000 Project Management Institute - PMI

FRAME, J. Davidson. Gerenciando Projetos nas Organizaes. 2001.

10

Custo

Qualidade

Figura I - Restrio Tripla9

Qualquer variao em um desses parmetros influenciar o outro.

Um projeto chega ao seu fim quando os objetivos propostos em sua fase de concepo so
alcanados ou no momento em que a organizao identifique que os objetivos no podero ser
atingidos por alguma razo, como por exemplo, que o projeto no est mais de acordo com as
novas necessidades ou com a estratgia da empresa. Nesse momento, o projeto encerrado
antecipadamente.

Os projetos so desenvolvidos em todos os nveis da organizao. Eles podem envolver uma

nica pessoa ou centenas delas. Podem envolver uma unidade isolada ou atravessar as
fronteiras organizacionais.

Os projetos envolvem algo que nunca foi desenvolvido antes, portanto so considerados
nicos e por isso, possuem um certo grau de incerteza. Eles so utilizados para capturar uma
oportunidade em um novo produto ou servio e para aumentar a competitividade garantindo o
futuro e a sobrevivncia da organizao alm de ser a forma pela qual as estratgias so
implementadas.

Idem.

11

Na fase de concepo, fundamental a definio clara do seu objetivo de forma que os

participantes possam ter a mesma referncia e somar seus esforos em uma nica direo. Os
parmetros prazo, custo e qualidade devero servir de direcionadores permanentes durante
todo o desenvolvimento do projeto.

Atend-los no somente uma tarefa do gerente de projeto seno de todos os envolvidos nele.
Direcionar os esforos para que isso ocorra fundamental. De acordo com o PMBOK IO , um
projeto se caracteriza por:

Estar constitudo por um conjunto determinado de trabalhos;

No ser repetitivo;

Possuir objetivos claros e bem definidos;

Dispor de tempo limitado;

Dispor de oramento fixo;

Ser realizado por um grupo de pessoas ou uma equipe temporria que, ao final do
projeto, normalmente liberada ou realocada em outras atividades ou diferentes
projetos.

Os objetivos do projeto devem ser claros e conhecidos assim como as alternativas devem ser
identificadas e as atividades devem ser descritas claramente. Um projeto constitudo por
uma srie de tarefas. A cada tarefa so atribudas responsabilidades para simplificar o seu
controle e assim poder se verificar, passo a passo, o cumprimento e a concluso das tarefas
atribudas. O resultado um produto, servio ou capacitao de um processo organizacional,
alinhado s necessidades operacionais da organizao do ponto de vista do curto prazo e que,
se visto do ponto de vista do longo prazo, estratgico. De acordo com o PMBOK, em
resumo, um projeto envolve:

Tarefas

Responsabilidades

Oramento (custos e tempo)

10

Guia do PMBOK, 2000 Project Management Institute - PMI

12

Recursos: financeiros e humanos

Projetos ficaram conhecidos pelos diferentes ciclos de vida e sistemas de gerenciamento que
forneciam uma formal e legtima integrao de recursos atravs da organizao. Linhas de
comando, motivao, liderana e tcnicas de controle, surgiram para suportar os projetos
dentro da estrutura organizacional.

2.1.1.2

o gerenciamento de projetos e suas reas de conhecimento

Instituto de Project Management ll define "Project Management como a arte de dirigir e

coordenar recursos materiais e humanos, durante o ciclo de vida de projetos, atravs do uso de
tcnicas modernas de gesto que permitam alcanar objetivos predeterminados de escopo,
custo, tempo, qualidade e satisfao dos participantes"

12.

Gerncia de projetos a aplicao de conhecimentos, habilidades, ferramentas e tcnicas

destinadas ao controle de aes e atividades no repetitivas, nicas e complexas dentro de um
cenrio de custo, tempo e qualidade determinado. Alm disso, administrar projetos significa
tomar decises e realizar aes de planejamento, organizao e execuo e que possibilitam o
desenvolvimento do ciclo de vida de projeto. Cada um destes cinco processos administrativos
-project process J3 , necessrio para todo o projeto ou em cada uma de suas fases.

De acordo com o PMBOK podemos destacar alguns dos beneficios do Gerenciamento de

Projetos:

Evita surpresas durante a execuo dos trabalhos;

Permite desenvolver diferenciais competitivos e novas tcnicas;

Antecipa as situaes desfavorveis;

Adapta os trabalhos ao mercado consumidor e ao cliente;

The Project Management Institute - PMI

Brochure, Project Management Institute, 4 campus Blvd, Newtown Square, PA 19073
13 Guia do PMBOK, 2000 Project Management Institute - PMI
11

12

13

Agiliza as decises;

Aumenta o controle gerencial;

Facilita e orienta as revises da estrutura;

Melhora a capacidade de adaptao;

Otimiza a alocao de pessoas, equipamentos e materiais;

Estrutura os custos de implantao;

Documenta e facilita as estimativas para futuros projetos.

A utilizao da metodologia de Gerenciamento de Projetos poder ser aplicada sempre que a

empresa a julgue aplicvel na consecuo de sua estratgia. Projetos so para implementar
estratgias organizacionais, alcanar objetivos e contribuir para a realizao da misso da
organizao. A gerncia de projetos est inserida em um ambiente mais amplo do que o
projeto propriamente dito, ou seja, a gerncia de atividades dirias do projeto necessria mas
no o suficiente para alcanar o sucesso.
David I. Cleland (1999) 1\ em seus estudos, identificou que poucos livros retratavam o Project

Management como ferramenta de gesto dentro das organizaes, ou seja, desde o desenho at
execuo de projetos, que viabilizassem as estratgias organizacionais.
No seu livro Project Management. Strategic Design and Implementation 15, o autor nos
apresenta uma conceituao moderna sobre o que seja Project Management, a qual ser
utilizada como parte do referencial terico neste trabalho. A Figura 11 - reas de Atuao
do Project Management demonstrada a seguir, resume as reas de conhecimento do Project

Management e seus processos.

14

15

Ph.D. e professor de Engenharia da Universidade de Pittsburgh

(CLALAND, 1999)

14

Scope
Management

\
Integration
Management
~

Time
Management

I
Cost
Management

Project
Management
Quality
Management

Procurement
Management

Risk

Human
Resources
Management

Management Communication
Management

Figura 11- reas de Atuao do Project Management (Cleland (1999

As reas de conhecimento da Gerncia de Projetos descrevem os conhecimentos e prticas

em gesto de projetos em termos dos processos que as compe. Estes processos foram
organizados em nove reas de conhecimentos detalhadas a seguir:

Integration Management ou Gerncia da Integrao do Projeto - Descreve o processo

necessrio para garantir que os vrios elementos do projeto se encontram devidamente

coordenados de forma a executar a fase de planejamento, a fase de execuo e o controle de
mudanas do projeto. Envolve fazer compensaes entre objetivos e alternativas com o
objetivo de atingir ou superar necessidades e expectativas dentro do projeto. Os processos
principais so:

15

Desenvolvimento do plano do projeto - consiste em agregar resultados de outros

processos de planejamento e construir a documentao do projeto;

Execuo do plano do projeto - dar seqncia ao projeto de acordo com o que foi
planejado;

Controle integrado de mudana - coordenar as mudanas atravs do projeto.

Uma das tcnicas utilizadas, tanto para interagir vrios processos quanto para medir o
desempenho, desde a iniciao at a concluso, a gerncia de valor agregado (Earned Value
Management - EMV).

Scope Management ou Gerncia do Escopo do Projeto - Descreve o processo necessrio para

assegurar que o projeto inclui todas as fases e trabalho necessrio para concluir o projeto de
forma satisfatria, atingindo os objetivos (escopo) propostos. Sua preocupao principal
definir e controlar o que foi previamente definido e no agregar novos objetivos ao projeto. Os
principais processos so:

Iniciao - consiste em autorizar o projeto ou fase em questo;

Planejamento do escopo - desenvolver documentao do escopo para servir de base

para a tomada de decises futuras que envolvem o projeto;

Detalhamento do escopo - consiste em subdividir os principais subprodutos do projeto

em componentes menores e facilmente manejveis;

Verificao do escopo - formalizao da aprovao do escopo do projeto;

Controle de mudanas do escopo - controlar as mudanas de escopo no projeto.

Time Management ou Gerncia do Prazo do Projeto - Descreve o processo necessrio para

garantir que o projeto seja concludo no prazo estipulado. Os principais processos so:

Definio das atividades - consiste em identificar as atividades especficas que devem

ser realizadas para produzir os subprodutos do projeto;

seqnciamento das atividades - documenta e identifica as relaes de dependncia

entre as atividades;

16

Estimativa da durao das atividades - estima a quantidade de perodos de trabalho

que sero necessrios para a implementao de cada atividade;

Desenvolvimento do cronograma - analisa a seqncia das atividades, sua durao, e

os requisitos de recursos para criar o cronograma do projeto;

Controle do cronograma - controla as mudanas que se faam necessrias no

cronograma do projeto.

Cost Management ou Gerncia do Custo do Projeto - A gerncia do custo do projeto envolve

os processos necessrios para assegurar que o projeto ser concludo dentro do oramento
aprovado,

consistindo

fundamentalmente

nos

custos

dos

recursos

necessrios

implementao das atividades do projeto. Em muitas reas de aplicao, prever e analisar a

perspectiva de desempenho financeiro do produto do projeto uma atividade que feita fora
do ambiente do projeto. J em outras, a gerncia de custo executa este trabalho. Quando as
previses so concludas, a gerncia do custo inclui processos adicionais e diversas tcnicas
de administrao como previso de retomo de investimento, fluxo de caixa, entre outras. Os
principais processos so:

Planejamento dos recursos - determinar quais recursos e sua quantidade devem ser
aplicados para executar as tarefas do projeto;

Estimativa de custos - estimar aproximadamente os custos dos recursos necessrios

para executar as atividades do projeto;

Oramento dos custos - alocar as estimativas de custos globais aos itens individuais de
trabalho;

Controle dos custos - controlar as mudanas no oramento do projeto.

Quality Management ou Gerncia da Qualidade do Projeto - Descreve o processo necessrio

para garantir que as necessidades que originaram seu desenvolvimento foram atendidas. Os
principais processos so:

Planejamento da qualidade - consiste em identificar que padres de qualidade so

relevantes para o projeto e determinar a melhor forma de atend-los.

17

Garantia da qualidade - proporciona a avaliao peridica do desempenho do projeto

visando assegurar a satisfao dos padres de qualidade relevantes.

Controle da qualidade - consiste em supervisionar os resultados do projeto

determinando se esto de acordo com os padres de qualidade. Alm disso deve-se
identificar as formas para eliminar as causas de desempenhos insatisfatrios.

Human Resources Management ou Gerncia dos Recursos Humanos do Projeto - O

gerenciamento dos recursos do projeto inclui os processos necessrios para tomar mais efetiva
a utilizao dos recursos humanos envolvidos no projeto. Os principais processos so:

Planejamento organizacional -

identificar, documentar e designar os papis,

responsabilidades e os relacionamentos de reporte no projeto;

Montagem da equipe - conseguir que os recursos humanos necessrios sejam

designados e trabalhem no projeto;

Desenvolvimento da equipe - desenvolver competncias individuais e de grupo para

elevar o desempenho do projeto.

Communication Management ou Gerncia das Comunicaes do Projeto - A gerncia das

comunicaes no projeto inclui os processos necessrios que visam garantir a regular a
apropriada gerao, coleta, disseminao, armazenamento e descarte final das informaes do
projeto. Promove os relacionamentos entre a equipe, troca de idias e informaes necessrias
para obteno do sucesso no projeto. Os principais processos so:

Planejamento das comunicaes - determina as informaes e comunicaes

necessrias s partes envolvidas. Define quem necessita das informaes, quando
sero necessrias e como sero fornecidas;

Distribuio das informaes - consiste em tomar as informaes acessveis s partes

envolvidas no projeto;

Relato de desempenho - coleta e dissemina as informaes de desempenho. Inclui

relatrios de posicionamento, progresso do projeto e previses;

Encerramento administrativo - consiste em gerar, reunir e disseminar informaes

para formalizar a concluso de uma fase ou do projeto.

18

Risk Management ou Gerncia dos Riscos do Projeto - um processo sistemtico para

identificar, analisar e responder aos riscos do projeto. Inclui maximizar a probabilidade e
conseqncia de eventos positivos e minimizar a probabilidade de eventos adversos aos
objetivos do projeto. Os principais processos so:

Planejamento da gerncia de risco - consiste em decidir como abordar e planejar a

gerncia de risco no projeto;

Identificao dos riscos - determina os riscos provveis do projeto e documenta suas

caractersticas;

Anlise qualitativa de riscos - analisa qualitativamente os riscos e condies para

priorizar seus efeitos nos objetivos do projeto;

Anlise quantitativa de riscos - mensura a probabilidade e impacto dos riscos e estima

suas implicaes nos objetivos do projeto;

Planejamento da resposta aos riscos - desenvolve procedimentos e tcnicas para

aumentar oportunidades e para reduzir a ameaa de riscos para os objetivos do projeto;

Controle e monitoramento de riscos - monitora os riscos residuais, identifica novos

riscos, executa os planos de reduo de risco e avalia sua efetividade durante todo o
ciclo de vida do projeto.

Procurement Management ou Gerncia das Aquisies do Projeto - A gerncia das

aquisies do projeto inclui os processos necessrios aquisio de bens e servios externos
organizao. Os principais processos so:

Planejamento das aquisies - determina o que se deve contratar e quando;

Preparao das aquisies - documenta os requerimentos do produto e identifica os

possveis fornecedores;

Obteno de propostas - obtm as propostas dos fornecedores;

Seleo de fornecedores - elege entre possveis fornecedores;

Administrao de contratos - gerencia o relacionamento com os fornecedores;

Encerramento do contrato - liquida o contrato incluindo a resoluo de qualquer ponto

pendente.

19

2.1.1.3 O processo de Project Management

Aps entendermos quais so as reas de atuao do Project Management, podemos entender

melhor o seu processo.

Para Cleland (1999), o processo de Project Management define a tnica da gerncia de

projetos ou seja, a conceituao, o planejamento e a execuo de um projeto, seus mtodos e
polticas bem como o comprometimento dos recursos nele envolvidos. Entre o incio e o seu
fim, o projeto sofre todo um desenvolvimento, estruturao, implantao e concluso. Para
facilitar o controle gerencial do projeto, ele dividido em vrias fases proporcionando uma
melhor ligao com os processos operacionais, tambm conhecidos por ongoing operations.

Cleland (1999) chama essas fases de Ciclo de Vida de um projeto. Ao se elaborar o Ciclo de
Vida de um projeto, possvel prever o consumo de recursos demandados por ele, etapa por
etapa, durante todo o tempo. Permite-nos tambm criar um anteprojeto, um estudo de
viabilidade sobre o que se pretende desenvolver, sendo um instrumento valioso para
aprofundar idias e conceitos a serem implementados. O Ciclo de Vida de um projeto
representa seu nascimento, desenvolvimento e consolidao at o seu encerramento conforme
demonstrado na Figura lU - Ciclo de Vida de um Projeto, a seguir:

20

R
e

c
u
r

s
O

Figura IH - Ciclo de Vida de um Projeto

16

Cada fase marcada pela concluso de um ou mais produtos (deliverables). Os produtos de

uma fase normalmente so aprovados antes do incio da fase seguinte. Entretanto, quando os
riscos so aceitveis, possvel iniciar a fase subsequente antes da aprovao dos produtos da
fase precedente. Esta tcnica chamada de fas! tracking. A seguir so descritas as principais
atividades em cada fase.

A Fase I, a fase de Concepo, a fase inicial que marca o surgimento da necessidade de

projeto pelo usurio. Ela compreende o perodo desde o seu nascimento at a aprovao da
proposta para a sua execuo. Nessa etapa, as principais atividades so:

Identificao de necessidades e/ou oportunidades;

Traduo dessas necessidades e/ou oportunidades em um problema;

Equacionamento e definio do problema;

Anlise do ambiente do problema;

Determinao dos objetivos e metas a serem alcanados;

Definio do gerente do projeto;

Anlise das potencialidades ou recursos disponveis;

BIBLIOTECA MARIO HENRIQUE SIMONSE"

FUNDACAO GETULIO VARGAS

21

Avaliao da viabilidade de atingimento dos objetivos;

Estimativa dos recursos necessrios;

Elaborao da proposta e venda da idia;

Avaliao e seleo com base na proposta submetida;

Deciso quanto execuo do projeto.

Para Menezes (2001) 17, na fase de concepo, as aes criadas a partir desse processo visam
dar uma viso de futuro do que se deseja obter do projeto. Desta forma quanto mais recursos
em termos de tempo, anlise e planejamento forem dedicados a esta fase, maior ser a
oportunidade de alcanar o xito no futuro, alm do fato de poder se planejar melhor a
formao da "equipe bsica" do projeto e consequentemente promover a integrao entre os
seus membros.

A Fase II a fase de Planejamento e tem como preocupao central a estruturao e

viabilizao operacional do projeto. A proposta de trabalho detalhada por meio de um plano
de execuo operacional cujas principais atividades so:

Detalhamento das metas e objetivos a serem alcanados, com base na proposta

aprovada;

Detalhamento das atividades e a estrutura de diviso de trabalho (WBS - Work

Breakdown Structure);

Programao das atividades no tempo disponvel e/ou necessrio (atravs da

elaborao de Cronograma);

Determinao dos marcos ou milestones a serem alcanados durante a

execuo do projeto;

Programao da utilizao e aprovisionamento dos recursos humanos e

materiais necessrios ao gerenciamento e execuo do projeto (alocao dos
recursos);

CLELAND (1999), David I. Project Management. Strategic Design and Implementation. 3rd. Edition.
Singapore: McGraw-HiII, 1999.
17 MENEZES, Luis Csar de Moura. Gesto de Projetos. 10 Edio. So Paulo: Editora Atlas, 2001.

16

22

Delineamento dos procedimentos de acompanhamento e controle a serem

utilizados na implantao do projeto (inclusive controle de custos);

Estabelecimento da estrutura orgnica formal a ser utilizada para o projeto

(formao da equipe e matriz de responsabilidades);

Estruturao do sistema de comunicao e de deciso a ser adotado (plano de

Comunicao);

Designao e comprometimento dos tcnicos que participaro do projeto

(Atividades de Change Management);

Treinamento dos envolvidos com o projeto.

Em linha com o que diz Cleland (1999), Menezes (2001) complementa a anlise nos dizendo
que a fase de planejamento permite detalhar o escopo do projeto e ainda as atividades
seguintes incluindo custo, prazo e qualidade. Ainda possvel, nesta fase, trabalhar no
planejamento da equipe, no detalhamento dos riscos e na identificao de aes para
minimiz-los assim como no planejamento da comunicao do projeto, no plano de contratos
com fornecedores e identificao dos suprimentos requeridos para essas contrataes.

J a Fase lI!, a fase de Execuo, refere execuo do trabalho propriamente dito. Quase
sempre so necessrios ajustes ao longo do trabalho com o objetivo de seguir o plano inicial
no que se refere a prazos e oramento. Nesta fase, as principais atividades so:

Ativar a comunicao entre os membros da equipe do projeto (pondo em

prtica o Plano de Comunicao e dando manuteno s atividades de Change
Management);

Executar as etapas previstas e programas de trabalho (atividades de controle);

Utilizar os recursos humanos e materiais, sempre que possvel, dentro do que

foi programado;

Efetuar reprogramaes no projeto segundo seu status quo, adotando os planos

e programas iniciais como diretrizes mutveis.

Garantir a qualidade mediante avaliaes regulares do desempenho geral do

projeto de acordo com os padres de qualidade estabelecidos (Quality
Assurance);

23

Administrao de contratos.

Complementando essa anlise, podemos dizer que a fase de execuo consiste em coordenar
pessoas e demais recursos para realizar o plano de ao simultaneamente com a fase de
controle. Nessa fase so necessrias no s habilidades tcnicas mas tambm de
relacionamento humano, assim como o gestor do projeto deve possuir caractersticas de
liderana. Conhecer a equipe, suas necessidades e limites muito importante. O controle
realizado com acompanhamento das atividades, podendo-se utilizar diversas fontes: prazo,
custos, qualidade, escopo e riscos. Paralelamente, monitorar sistemas de garantia da qualidade
dos resultados e de controle do desenvolvimento do escopo so tarefas relevantes que ocorrem
durante esse perodo. Ao mesmo tempo, a disseminao das informaes no projeto
importante e no ocorre somente com a implementao de um Plano de Comunicao mas
tambm pela identificao e mapeamento do Stakeholders, com o emprego de tcnicas e
feedback necessrio junto equipe de projeto, aos prprios Stakeholders e organizao

como um todo.

A Fase IV, de Concluso, a fase que corresponde ao trmino do projeto, fase visivelmente
identificada pelo desligamento gradual de pessoas e empresas envolvidas no projeto. Nesta
fase, as principais atividades que ocorrem so:

Acelerao das atividades que no tenham sido concludas;

Realocao dos recursos humanos para outras atividades ou projetos;

Elaborao da memria tcnica do projeto (finalizao da documentao do

projeto);

Elaborao de relatrios e transferncia dos resultados finais (Lessons

Learned);

Emisso de avaliaes globais sobre o desempenho da equipe do projeto e

resultados alcanados;

Encerramento dos contratos.

24

A fase de concluso ou fechamento, refere-se aceitao formal do projeto e encerramento

deste, de forma organizada, incluindo o encerramento com os fornecedores e subcontratados.
Diversas outras atividades so importantes, como por exemplo, sesses de lies aprendidas,
avaliao e documentao final do projeto.

Na Figura IV - Inter-relacionamento entre os grupos de processos no desenvolvimento

de um projeto abaixo, as setas indicam a troca de informaes entre os diversos processos.

~ceP~~------

Figura IV - Inter-relacionamento entre os grupos de processos no desenvolvimento de

um projeto. I8

Alm disso, esses grupos de processos no so separados ou descontnuos assim como

tambm no ocorrem uma nica vez. Eles so formados por atividades que se sobrepe,
ocorrendo em intensidade varivel ao longo de cada projeto. A Figura V - Sobreposio de
grupos de processos dentro das fases do projeto abaixo, ilustra como os grupos de
processos se sobrepem e variam dentro de cada uma das fases do projeto.

18

MENEZES, Lus Csar de Moura. Gesto de Projetos. 1 Edio. So Paulo: Editora Atlas, 2001.

25

v
m

Processos de

A
t

execulo
Processos de
planejamento
Processos de
fechamento

Tempo

Figura V - Sobreposio de grupos de processos dentro das fases do projeto

(Menezes(2001

A viso macroscpica do Ciclo de Vida de um projeto muito importante pois atravs dela os
envolvidos podem avaliar as dimenses do projeto pretendido. Nesse contexto, as funes
demonstradas na Figura VI - Processo de gerenciamento e suas funes devem ser
analisadas ao se falar em Project Management.

Control

o;"",lIng

r=!5

ManagementJ
Process
Motivation ~
Organization

Figura VI - Processo de Gerenciamento e suas funes (Cleland (1999

Todos estes fatores so interdependentes, tanto em uma organizao como na gerncia de um

projeto. Durante a fase de planejamento (Planning), a organizao dever estabelecer e
determinar a misso, os objetivos, as metas e as estratgias do projeto. A organizao
(Organization), refere-se aos recursos envolvidos, sejam eles humanos ou financeiros e como

esses recursos sero usados ou estaro alinhados ao projeto. A definio da autoridade

(Directing) e responsabilidades mantero o curso do projeto. A motivao (Motivation) vista

26

como o fator que permite trazer tona o que h de melhor nas pessoas. Monitoramento,
avaliao e controle (Controlling) fornecem os meios para determinar o quanto os projetos e
as estratgias organizacionais esto sendo bem utilizadas no atingimento dos objetivos e
metas no emprego de predeterminada estratgia.

2.1.1.4

Principais grupos envolvidos no projeto

Dentre as pnnClpalS pessoas envolvidas em um projeto, Cleland (1999)19 destaca os

Stakeholders, indivduos ou empresas envolvidas no projetos ou aqueles cujos os interesses
podem ser afetados no decorrer do projeto ou at mesmo aps sua concluso.

Tm-se tambm a equipe de projeto, cujo processo de formao muito importante pois seus
membros estaro relacionando-se entre si durante o perodo de desenvolvimento do projeto.
Sua interao importante para o atingimento dos objetivos. Os membros da equipe do
projeto so conhecidos como especialistas e so os responsveis pela execuo das tarefas do
projeto, na sua rea de especializao tcnica.

O Cliente indivduo ou grupo que far uso do projeto.

Em todo projeto esto igualmente envolvidos o patrocinador do projeto ou Sponsor, indivduo

ou grupo dentro da organizao executora que prov os recursos financeiros para o projeto.
Como parte integrante do projeto, o patrocinador passa a ser um estimulador das negociaes
entre as partes, incentivando o dilogo e a participao na identificao do problema e na
busca da soluo. Tambm responsvel pela posta em prtica das decises acordadas.

O gerente do projeto o indivduo responsvel pela conduo do projeto e dever possuir uma
viso integrada do mesmo. o ponto focal de uma rede de comunicao entre os membros do
projeto, que pode envolver pessoas internas e externas empresa, conhecidos como

19

CLELAND (1999), David I. Project Management. Strategic Design and Implementation. 3rd. Edition.
Singapore: McGraw-Hill, 1999.

27

Stakeholders. Ele tambm responsvel por diversos elementos chave oriundos das atividades
do projeto, so eles:

Organizar a equipe e demais recursos para suportar o objetivo do projeto, as metas e as

estratgias;

Planejar a utilizao dos recursos nas diversas fases do ciclo de vida do projeto;

Identificar e utilizar informaes relevantes para gerenciar o projeto;

Liderar os membros da equipe do projeto;

Conduzir avaliaes peridicas dos resultados obtidos e redirecionar ou reprogramar

os recursos conforme a necessidade mantendo o projeto conforme o planejamento
inicial;

Utilizar modernas ferramentas e tcnicas de gesto visando facilitar o processo de

gerenciamento;

Manter o usurio informado;

Manter o proprietrio do projeto informado do andamento do projeto de forma que

tenha a conscincia de quanto o projeto est em conformidade com as estratgias da
organizao.

O gerente funcional ser responsvel pode ceder os recursos ou especialistas para participarem
do projeto. Possui a responsabilidade reduzir o impacto das mudanas trazidas pelo projeto
para a empresa, redistribuindo os recursos restantes de sua rea e suas respectivas atividades
aos recursos remanescente na reas funcionais.

2.1.2

Sistemas de ERP

O conceito de ERP (Enterprise Resource Planning) passou a ser o novo paradigma que
direcionou o desenvolvimento de sistemas aplicativos. Empresas industriais e comerciais
passaram a adotar esta tecnologia to rpido quanto possvel. Lozinsky (l996io, destacou os
seguintes beneficios mais perceptveis:

2LOZINSKY, SERGIO, Software: Tecnologia do Negcio, Imago Editora Ltda, So Paulo, Brasil, 1996

28

habilidade de suportar a reviso de processos;

maior visibilidade e controle sob a cadeia de suprimentos;
consistncia e robustez dos sistemas do ponto de vista tecnolgico;
reduo dos custos diretos com tecnologia de informao.

No existe uma nica definio formal para sistemas ERP. Jones (1997)21 os define como
sistemas integrados de software que:

integram todos os processos, regras e aplicaes para automatizar toda a cadeia de

suprimentos;
so baseados em tecnologia viabilizadora da atuao e controle por processos em
contraponto atuao e controles departamentais;
fornecem uma arquitetura de informaes que une toda a empresa, inclusive suas
diversas plantas e pases.

Alguns dos fatores que levam os sistema de ERP a ser um dos tpicos mais discutidos nesse
momento, independente da indstria, foram: maior competio, necessidade de incrementos
de qualidade e variedade nos produtos, bem como a reduo dos tempos e dos custos de
desenvolvimento de novos aplicativos, no custo da tecnologia, na reduo do volume de
pessoal (tanto em nveis gerenciais e como nos overheads).
Outro fator relevante que propiciou a migrao para sistemas de ERP, foi o aumento das
fuses e aquisies observado em praticamente todas as indstrias. As empresas necessitam
de tecnologias que possibilitem rapidamente acomodar este tipo de mudana, que possam ser
rapidamente aplicadas s suas novas divises, plantas ou negcios.

2I J ONES,

C., Planning Guidelines for Implementing ERP, Part 1 & 2,Gartner Group Research, Stanford, CT,
USA,27/03/97

29

Processos Operacionais

;1

Troca
Eletrnica de
Documentos

roca
Eletrnica de
Documentos

Processos de Suporte

Figura VII - Viso Geral do ERP22

medida que o tempo passa, observa-se que os sistemas de ERP incorporam maIS
caractersticas que permitem anlises em tempo real, previso de tendncias e otimizao de
processos, rotas de distribuio (Logstica) e controles. Por integrar as informaes de todas as
plantas, negcios e departamentos da empresa, atravs de uma base contbil nica, o ERP
viabiliza anlises em tempo real de diversas questes fundamentais para o negcio da
organizao como a quantidade e qualidade dos produtos, dos insumos em estoque, a
satisfao dos clientes, os nveis de rentabilidade por produto e segmento de clientes, entre
outros.

Alguns sistemas de ERP permitem tambm a realizao de simulaes dessas variveis, muito
antes do planejamento da produo ser realizado. Mdulos financeiros e de planejamento
recebem informaes diretamente dos mdulos de manufatura, distribuio e suprimentos
permitindo que decises sejam tomadas de modo rpido e eficiente.

Para suportar este sonho de integrao, os fornecedores de software foram obrigados a valerse do que h de melhor em termos de tecnologia de software. Em 1994, segundo Bond

22

LOZINSKY, SERGIO, Software: Tecnologia do Negcio, Imago Editora Ltda, So Paulo, Brasil,1996

30

(1996)23, as palavras de ordem eram Cliente-Servido~4 e Interface Grfica com Usuri025

(GUI). A partir de 1995 essas tecnologias continuaram dominando o mercado e absorvendo
parte significativa dos investimentos dos produtores de software. Mas uma nova tecnologia
passou a ser o maior foco de ateno dos fornecedores deste tipo de produto: a orientao a
objeto. Fornecedores que no concentraram seus esforos em adaptar seus produtos a estas
tecnologias provavelmente no esto no mercado hoje nem estaro nos prximos anos 26 . A
tecnologia utilizada pelo fornecedor deve ser um fator determinante no produto de ERP a ser
utilizado por uma empresa. Provavelmente o direcionador mais claro para adoo de sistemas
de ERP tenha sido, de acordo com Bond (1996), o conceito de cadeia logstica integrada
(Supply Chain). Porter (1992)27, no mesmo livro que enuncia este conceito, prope que um

dos requisitos para se obter vantagens atravs da utilizao desse conceito justamente a
utilizao de sistemas integrados de gesto. Porter (1992) define a cadeia logstica integrada,
ou cadeia de valor, como o "instrumento que representa uma empresa atravs das suas
atividades estratgicas e de suporte e que usado para compreender o comportamento dos
custos, as fontes desses custos e os potenciais de diferenciao da empresa,,28. Isto , um
modelo que representa as atividades da empresa com a finalidade de compreender seu
relacionamento e interao e otimiz-los na busca de vantagens competitivas. De acordo com
Porter (1992), para alcanar a vantagem competitiva atravs deste instrumento seriam
necessrios, o entendimento e difuso do conceito e estratgia de gerenciamento por processos
(atividades) em contraposio ao gerenciamento por departamentos, a reviso das formas de
acompanhamento e controle da empresa em funo da nova viso - "Administrao por
Processos", a reviso da estrutura organizacional para "quebrar" ou abrandar as barreiras
departamentais, a integrao com fornecedores e clientes e a integrao dos sistemas de
informao.
23BOND, B., ERP Market Trends: Vendors Struggle to Stay Competitive, Gartner Group Research, Stanford,
CT, USA, 18/11196
24Tecnologia pela qual se torna possvel conectar diversos computadores e distribuir ordenadamente as tarefas a
serem realizadas entre eles. Pode-se por exemplo ter um SERVIDOR de banco de dados, ie um computador
que gerencia e mantm o banco de dados, conectado a uma estao (computador) CLIENTE que tem os
programas que permitem a consulta e manipulao desses dados.
250 padro anterior para interao do usurio com os sistemas era a interface orientada a caracteres, onde o
usurio compunha suas instrues e recebia suas respostas exclusivamente atravs de textos. A interface grfica
permite a utilizao de cones, janelas, imagens para que o usurio interaja com seus sistemas.
26 B OND , obra cit.
27pORTER, Michael E., Vantagem Competitiva: criando e sustentando um desempenho superior, Editora
Campus, Rio de Janeiro, 1992.

31

Toda cadeia logstica se inicia no relacionamento com fornecedores e termina no

relacionamento com os clientes. No passado, as empresas se esforavam por isolar os seus
clientes do seu processo de produo mantendo-os, no mximo, ao nvel do seu servio de
atendimento a clientes. Hoje as empresas, para manterem sua competitividade, buscam maior
integrao com seus parceiros de negcios. Adicionalmente, a necessidade de sincronizao
dos processos de suporte aos processos operacionais da empresa um fator de incentivo
adoo dos sistemas do ERP. Anteriormente, os executores dos processos de suporte como
contabilidade, tesouraria, planejamento financeiro, entre outros, no estavam diretamente
integrados ao processo de produo e distribuio dos produtos da empresa. Com os sistemas
ERP esses grupos passaram a ter uma viso mais ampla do processo produtivo a partir da
disponibilizao de informaes que antes estavam disponveis apenas para o pessoal
"operacional". A implantao de sistema de ERP portanto, rompe barreiras departamentais e
exige freqentemente mais mudanas do que apenas a troca de tecnologia29 .

Outro fator que contribui para o sucesso das ferramentas de ERP foi a necessidade de
ferramentas adequadas para o gerenciamento da distribuio de produtos. Os sistemas de ERP
so teis, no sentido que permitem a considerao de todos os fatores de custos, necessidades
de transporte para todas as ordens e disponibilidade de canais de distribuio. Os sistemas de
ERP permitem, por exemplo, determinar se prefervel atender pedidos a partir de estoques
existentes ou utilizando a capacidade ociosa de uma planta para produzir o pedido a partir do
zero.

Para implementar o conceito de ERP, tanto possvel adquirir os diversos componentes

(mdulos) de mais de um fornecedor, escolhendo possivelmente os melhores produtos para
cada funcionalidade (contabilidade, planejamento de produo, comercializao, suprimentos,
qualidade, etc.), quanto optar por um fornecedor nico, privilegiando a integrao a aquisio
da melhor em cada rea. Um nmero cada vez maior de empresas vem fazendo a segunda
opo, contratando seu sistema de ERP de um nico fornecedor.

28

29

Idem p.33
KELLER, E., The Four R's ofERP, Gartner Group Research, Stanford, CT, USA, 29/11/95

32

Naturalmente, decises sobre investimentos desta natureza no se limitam a estudos

financeiros. Usualmente consideram tambm aspectos estratgicos e tecnolgicos do negcio.
Entretanto, na maior parte das vezes, tais decises implicam em mudanas na estrutura
organizacional e nos processos de negcio da empresa, provocando mudanas nas rotinas e,
eventualmente, na sua cultura. Nem sempre a organizao est preparada para enfrentar e lidar
com essas mudanas. Atualmente, os processos de mudana "constituem uma dinmica
prpria de cada organizao,,3o e costumam ser subestimados quanto importncia que a
contnua mudana nos processos tm sobre a dinmica prpria de cada Organizao.

2.1.3

Um projeto de implantao de um sistema de ERP

A implantao de solues de ERP requer o apoio de empresas especializadas de consultoria.

Essas empresas atuam no s no aporte de conhecimento tcnico sobre o produto, mas
principalmente na orientao metodolgica e no gerenciamento do projeto. A metodologia a
ser empregada no projeto em questo prev que o esforo de implantao seja organizado em
sete frentes de trabalho sendo elas:

A equipe de infra-estrutura tecnolgica, responsvel por implantar os meios fisicos para

operao do sistema (servidores, redes, canais de comunicao, microcomputadores, etc.), os
procedimentos para sua operao, controle e manuteno e selecionar eventualmente o
software necessrio para complementar a funcionalidade do sistema de ERP (ferramentas para
usurio final, por exemplo). A equipe de desenvolvimento ser responsvel pelo
desenvolvimento de programas de interface, converso de dados, relatrios, adaptaes e
complementos para o sistema de ERP. A equipe funcional ser responsvel pela realizao da
reviso dos processos de negcio e da configurao do sistema de ERP. A equipe de
gerenciamento de mudana que tratar da integrao do time de trabalho e da resoluo de
problemas interpessoais, do plano de comunicao, da elaborao e execuo do treinamento,
da reviso da estrutura organizacional, da reviso de cargos e salrios e da administrao de

30 Mudana

Mudana.

e Transformao Organizacional, Prof. Dra. Rosa Maria Fisher - Mudando os Paradigmas da

33

expectativas e ansiedades dos principais Stakeholders afetados pelo projeto. A equipe de

gerenciamento de riscos associados ao sistema que ser responsvel por identificar e gerenciar
os riscos associados s mudanas de processo sugeridas e s interfaces com outros sistemas.
Especificar e implementar os mecanismos de controle de acesso do sistema de modo a
garantir o respeito a normas de aprovao de documentos e a segregao de funes entre
funcionrios. O grupo de garantia da qualidade, que acompanhar o desenvolvimento das
atividades das frentes de trabalho anteriores, comparando-as com as melhores prticas na
implantao de sistemas de ERP. Avaliar tambm o grau de cumprimento das tarefas e da
qualidade da documentao do projeto e acompanhar a evoluo de indicadores de qualidade
do projeto, fornecendo subsdios para decises da gerncia de projeto. E por fim, a gerncia de
projeto que ser responsvel pela gesto dos recursos do projeto de modo a concluir as tarefas
necessrias com qualidade, no prazo e no custo estimados. Garantir tambm a integrao e o
sincronismo das tarefas das demais equipes.

Cada uma destas frentes de trabalho sero formadas por: consultores, representantes das reas
usurias, representantes da rea de informtica e/ou representantes da sistema de ERP.

Uma estrutura tradicional de um projeto de ERP, numa fase inicial de projeto pode ser
representada pela Figura VIII - Estrutura Proposta para um Projeto de ERP, a seguir:

Gerncia de Projeto

Gerncia Geral e de Integrao

Infraestrutura
Tecnolgica

Gerenciamento
da Mudana

Gerenciamento
de Riscos de
Sistema

Garantia da
Qualidade

.lnfonnic.

Cliente

CllenCe - Usuirtos

eo...ultItrN

l1li 'A.

34

Figura VII - Estrutura Proposta para um Projeto de ERP31

Nota: Cada quadrado colorido no grfico representa um profissional.

Em um projeto de implantao de software, como em qualquer outro, a equipe precisa ser

capacitada para exercer suas atividades. Em um projeto de implantao de sistema de ERP, a
capacitao assume um papel ainda mais relevante. Conhecer um software da sua magnitude
exige o investimento de diversas semanas em cursos formais e muito auto-estudo. Os
consultores alocados ao projeto, por exemplo, passam por um mnimo de cinco semanas de
treinamento tcnico e ao termino desse perodo participam de um exame de proficincia
aplicado pelo fornecedor do software para se habilitarem a participar. A isso deve-se ainda
acrescentar treinamento na localiza032 do software, quando o caso, na metodologia e
ferramentas de trabalho e um perodo mnimo de treinamento de campo. O treinamento da
equipe do cliente usualmente menos profundo do que o dos consultores. Deve entretanto
abordar outros aspectos que no somente o conhecimento do software, metodologia e
ferramentas: trabalho em equipe, gerncia de projetos, habilidades de comunicao e tcnicas
de apresentao, por exemplo.

O gerenciamento de um projeto requer que o foco interfuncional e interorganizacional seja

estabelecido dentro da organizao. Tanto a liderana e a capacidade gerencial so necessrias
para a concluso com sucesso de um projeto assim como o sucesso de um projeto est
relacionado ao atingimento dos parmetros estabelecidos para a performance tecnolgica,
custo e prazos (e devem estar alinhados com os objetivos e/ou propsitos operacionais e
estratgicos de uma organizao.

31

32

LOZINSKY, SERGIO, Software: Tecnologia do Negcio, Imago Editora Ltda, So Paulo, Brasil, 1996
Tambm conhecido no meio como tropicalizao

35

2.2 Formao de Equipes e a Liderana

Entendidos os principais conceitos de Project Management, vamos agora nos aprofundar na

reviso bibliogrfica de temas especficos relacionados metodologia apresentada na seo
anterior e que iro constituir o foco da anlise crtica deste estudo como a formao de
equipes e a questo da liderana.

2.2.1 A formao de equipes de projeto

Formar uma equipe para a implantao de um projeto, no um tarefa fcil. A formao da

equipe, um fator muito importante para garantir o sucesso de um projeto. Ela geralmente
ocorre no incio do processo de planejamento do projeto. Esses recursos tendem a ser um dos
fatores mais escassos em um projeto. De acordo com Frame (1995)33, um projeto
normalmente no falha por falta do emprego de tcnicas e sim por que o nvel de qualificao
da equipe do projeto no era o apropriado para as necessidades desse mesmo projeto ou
porque a gerncia dava instrues irrealistas para a equipe de projeto ou porque havia ainda,
falta de liderana na implantao do projeto.

Ainda segundo Frame (1995), a equipe definida como a reunio de indivduos que trabalham
juntos para atingir um objetivo comum e, para que eles trabalhem juntos, os esforos
individuais devem ser bem coordenados. No processo de planejamento de um projeto, em
determinado momento, necessrio "identificar e quantificar a quantidade de pessoas
necessrias para executar o projeto, suas atribuies e funes, as suas responsabilidades e os
recursos materiais necessrios".34 De acordo com Valeriano (1998), antes de se iniciar a
contratao dos recursos humanos importante, no mnimo, que as tarefas e atividades
bsicas do projeto estejam definidas (fase de planejamento, de acordo com a metodologia de
Project Management) para que seja possvel no s "comunicar as necessidades do projeto, as
33 FRAME,

J. Davidson, Managing Project in Organizations, How to make the best use oftime, techniques and
People, Jossey-Bass Inc. San Francisco, California, 1995.

36

responsabilidades e a estrutura de reporte entre os membros da equipe bem como para

gerenciar a expectativa que normalmente se cria antes do incio do projeto,,35

o processo

de "aquisio do pessoal pode ocorrer na prpria organizao ou fora dela. A

maior preocupao deve ser a de obter as pessoas com os exatos requisitos necessrios para o
projeto... se as pessoas pertencem organizao, o gerente do projeto dever proceder s
negociaes com seus chefes ou gerentes funcionais e com as prprias pessoas para obter o
seu consentimento e garantir a sua conseqente participao no projeto. Nos casos em que a
organizao no disponha do perfil necessrio, o pessoal que ir compor a equipe dever ser
suprido mediante contrataes extemas,,36.

A pressa e presso imposta pelo prprio projeto na escolha da equipe normalmente

responsvel pela qualidade da performance dessa mesma equipe e, o resultado da escolha de
pessoal, no necessariamente mais adequados para as tarefas a serem efetuadas, poder
resultar na perda de qualidade do projeto.

Para Frame (1995)37, as pessoas em um projeto so o seu ativo mais importante. Ele menciona
o fato de um vice presidente de um empresa americana, da lista das 500 maiores empresas
mencionadas em edies da revista Fortune, comentar que se orgulhava da sua capacidade
para selecionar os recursos para seus projetos. Seu segredo estava no fato de sempre
selecionar aqueles profissionais que estavam mais ocupados naquele especfico momento. Por
alguma razo, essas pessoas sempre conseguiam fazer as coisas acontecerem e por isso, seus
servios eram sempre demandados para novos projetos. Colocaes deste tipo nos fazem
refletir sobre a importncia da seleo dos melhores recursos humanos para um projeto.

34 y

ALERIANO, Dalton L., Gerenciamento Estratgico e Administrao de Projetos, Makron Books, So Paulo,
SP,2001.
35 HANS J. Thamhain em CLALAND, David I. Project Management. Strategic Design and Implementation. 3,d.
Edition. Singapore: McGraw-Hill, 1999.
36y ALERIANO, Dalton L., Gerenciamento Estratgico e Administrao de Projetos, Makron Books, So Paulo,
SP,2001.
37 FRAME, J. Davidson, Managing Project in Organizations, How to make the best use oftime, techniques and
People, Jossey-Bass Inc. San Francisco, Califomia, 1995.

37

Independentemente de se identificar os recursos para a equipe de projeto dentro da prpria

organizao ou fora dela, atravs de contrataes, a seleo dos recursos poder ser feita
atravs da anlise dos Tipos Psicolgicos38 .

Testes desse tipo, entretanto, podem falhar por no conseguirem medir a inteligncia, a
motivao ou a competncia tcnica dos recursos a serem selecionados. Alm do mais, de
acordo com Frame (1995), no prtico confiar cegamente nesses testes para alocar os
recursos a um projeto quando muitos so os fatores - incluindo disponibilidade de pessoal e
problema polticos - que precisam ser levados em considerao ao se lecionar tal equipe.

Na impossibilidade de se encontrar o recurso perfeito para cada projeto, os gerentes de projeto

devero utilizar uma srie de ferramentas para extrair o melhor de cada um dos recursos
disponveis, atravs da aplicao de mtodos e ferramentas que faam a produtividade da
equipe aumentar.

De acordo com Menezes (2001 )39, existem quatro categorias bsicas de profissionais que se
envolvem desde o incio do projeto sendo elas: o gerente geral, o gerente funcional, o gerente
de projeto e os especialistas. Cada um deles possui um conjunto de atribuies especficas
sendo elas:

Gerente Geral, visto como o patrocinador do projeto, cabendo a ele ser o rbitro dos
conflitos que no puderam ser solucionados pelos demais gerentes (funcionais e de projeto).
Ele incentiva o dilogo e a negociao entre as partes. Ele tambm pode assumir o papel de
Sponsor do projeto.

"Carl Yung, o famoso psicanalista suo se interessou em categorizar as pessoas no que ele chamou de Tipos
Psicolgicos. Em 1923 ele publicou um trabalho descrevendo esses tipos. Seu trabalho foi melhorado com
pesquisa posterior realizada por Katharine C. Bridges, que pegou a teoria Junguiana e a complementou com
suas idias. Por fim, suas idias foram refinadas por sua filha, Isabel Brigs Myers. O resultado final foi o
Indicador de Tipos Myers-Briggs, que operacionalizado em uma srie de testes psicolgicos criados para
determinar o tipo psicolgico de uma pessoa" in FRAME, J. Davidson, Managing Project in Organizations,
How to make the best use oftime, techniques and People, Jossey-Bass Inc. San Francisco, California, 1995.
39 MENEZES, Luiz Csar de Moura, Gesto de Projetos, Atlas, So Paulo, SP, 2001
38

38

Gerente do Projeto, o responsvel pela sua conduo, tendo uma viso integrada do mesmo.
Procura assegurar que os recursos que iro participar de seu projeto estejam disponveis nas
reas funcionais e de apoio. Seu poder de influncia limitado, reservado normalmente aos
assuntos da coordenao, integrao das atividades, ao cumprimento dos prazos e ao
cumprimento dos oramentos, requerendo dele capacidade de relacionamento interpessoal
com todas as pessoas da equipe e da organizao.

Gerente Funcional, o principal responsvel pela execuo das atividades de sua rea
especfica de conhecimento. Seu papel o de amortecer as excessivas demandas sobre os
executantes, procurando distribuir e compartilhar os recursos existentes. Ele absorve parte das
presses que poderiam recair sobre os seus subordinados, executantes das tarefas.

Especialistas, so aqueles encarregados de executar as tarefas do projeto na rea de sua

especialidade tcnica.

2.2.1.1

A estrutura da equipe de projeto

o principal objetivo na hora de se definir a estrutura da equipe de projeto poder obter dela a
maior eficincia possvel. De acordo com Menezes (2001), uma estrutura de equipe que
melhor se adapta estrutura de projetos a matricial. Esta estrutura conceituada como uma
forma que permite manter as unidades funcionais, atravs da criao de relaes horizontais
que agilizam a comunicao entre elas Segundo ele, numa estrutura matricial, identificam-se
baixo nvel de formalizao, multiplicidade de comando, diversificao elevada e
comunicao horizontal, vertical e diagonal. Sua implantao exige preparo por parte das
pessoas que estaro trabalhando dentro desse tipo de desenho organizacional. Sua implantao
deve ser acompanhada de uma srie de aes sobre sistemas de comunicao e sistemas de
tomada de deciso. Uma estrutura matricial tambm conhecida como Matricial-Projetos (ou
matriz forte) quando, em geral, proveniente de uma estrutura organizada por projetos em que
o gerente tem um elevado grau de poder dentro da equipe bem como sobre os gerentes

39

funcionais da organizao. Nessas circunstncias, embora exista um desequilibro de poderes,

fica facilitada a obteno de resultados para o projeto." 40

Para Frame (1995)41, projetos utilizando a estrutura matricial freqentemente carregam em si

alguma ineficincia. Por exemplo, a falta de continuidade da equipe de projeto funciona como
um fator desmotivador da equipe, contribuindo para o aumento da falta de comprometimento
desta para com o projeto. Ele identifica tambm os problemas de comunicao como fatores
que geram ineficincia em um projeto por meio da burocratizao das comunicaes,
medida que aumentam os canais de comunicao dentro do projeto, assim como a
comunicao tambm fica prejudicada pela existncia de mensagens truncadas. Por ltimo,
Frame (1995) menciona o fato desse tipo de projeto proporcionar pouca integrao entre os
membros da equipe, sendo importante fomentar a criao de mecanismos que propiciem a
integrao entre as partes envolvidas.

Uma forma de se estimular a equipe dentro de uma estrutura matricial atravs de um sistema
de recompensas. A recompensa pode ser financeira, uma oportunidade de desenvolvimento de
carreira dentro da organizao, o simples reconhecimento por um bom trabalho realizado, a
simples satisfao no emprego ou muitos outros valores pessoais tangveis e intangveis. Mas
as recompensas para serem verdadeiras dentro de um projeto, devero estar baseadas em
metas e indicadores que permitam medir o grau de cumprimento dessas mesmas metas. "Nada
capaz de atrapalhar mais o esforo da mudana organizacional do que o conflito entre os
objetos (metas) e seus indicadores"42.

Frame (1995) ressalta que o sistema de recompensas, em uma estrutura matricial, nem sempre
encoraja a equipe de projeto. Ao invs do sistema de recompensas, Frame (1995) sugere que a
implementao de outras aes como a criao do horrio flexvel como recompensa pelo
bom trabalho realizado e o esforo extra dedicado ao projeto. Sugere tambm que se faa o
reconhecimento publicamente do bom trabalho realizado por determinado membro da equipe

MENEZES, Luiz Csar de Moura, Gesto de Projetos, Atlas, So Paulo, SP, 2001
FRAME, J. Davidson, Managing Project in Organizations, How to make the best use oftime, techniques and
People, Jossey-Bass Inc. San Francisco, Califomia, 1995.
42THE PRICE WATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995.
40

41

40

e/ou que, ao trmino do projeto, o gerente escreva cartas de recomendao a serem enviadas
para os supervisores desses membros da equipe to logo estes retomem a seus postos de
origem, entre outros.

Complementando a anlise de Frame (1995), fazemos referncia ao mencionado por Menezes

(2001) quando este diz que o sucesso da estrutura matricial em um projeto depende de fatores
intrnsecos organizao como por exemplo, caractersticas intangveis da equipe e seus
membros das quais podemos destacar a capacidade e autoridade por parte dos membros da
equipe, da cooperao das pessoas com o projeto na quantidade certa e no momento adequado
para poder obter os melhores resultados. Da capacidade dos membros da equipe para se
adaptarem a novos grupos pois os projetos so finitos e por vezes as pessoas devem
desempenhar seus papis em vrios projetos simultaneamente. Os membros da equipe devem
tambm ter capacidade para desempenhar mltiplos papis haja vista que nos projetos, dentro
de uma estrutura matricial, no so exigidos unicamente conhecimentos que lhes permitam
executar o trabalho mecanicamente mas sim fazer um balano do trabalho realizado e avaliar
os resultados que esto sendo obtidos. Tambm devem ter atitude de colaborao pois a
canalizao de esforos fundamental para a obteno de resultados para o projeto. A equipe
deve ter preferncia por abrangncia de tarefas pois mesmo sendo composta por especialistas,
o colaborador passa a ter que entender mais da interface de seu trabalho com a de outros
colaboradores, alm ser necessrio possuir experincia matricial para melhor entender a
distribuio de responsabilidades e poder entender tambm a autonomia que existe em uma
estrutura desse tipo. Alm disso, a equipe do projeto precisa ter habilidade poltica, pois em
inmeras circunstncias so exigidas do participante, e ainda mais do gerente do projeto,
habilidades polticas na negociao de recursos e de prazos rumo obteno de resultados.
Deve ter capacidade para suportar ambigidades pois existem inmeras subordinaes em
estruturas matriciais e isso provoca, especialmente nos executores, muito estresse. Ressalta-se
a capacidade de comunicao para o contato e transmisso de informaes sobre o
desenvolvimento e o estado do projeto. E por fim, a liderana deve estar presente na gerncia
do projeto para poder fazer o projeto acontecer por meio dessas pessoas.

Vergara (1999) entretanto alerta para o fato de que "a liderana no necessariamente precisa
ser sempre a mesma, ... , natural que os diferentes membros da equipe assumam a liderana,

41

conforme a tarefa que se lhes coloca,,43. Com esta afirmao, Vergara (1999) refora o fato do
poder, em uma equipe, necessitar ser compartilhado para garantir a obteno de melhores
resultados no projeto.

Vergara (1999) ressalta tambm a importncia de se identificar nos membros da equipe,

quando se trabalha em equipes, as seguintes caractersticas: a negociao, a humildade
intelectual (reconhecimento de que preciso aprender sempre), o comportamento tico (que
desestimula uma pessoa a guardar informaes fundamentais aos processos de trabalho por
medo de perder o poder e o controle) e o estimulo para avaliar situaes em conjunto com os
demais membros da equipe e a buscar formas de corrigir erros, aprender com eles e a
aperfeioar acertos.

2.2.1.2

Criando uma identidade para a equipe de projeto

Alm de se pensar em como selecionar os membros de uma equipe de projeto, importante

pensar de que forma se conseguir criar uma identidade para essa equipe uma vez que ela
constituda pelos mais distintos tipos de pessoas, com as mais variadas experincias e
conhecimentos.

o que muitas vezes une as pessoas em um projeto a capacidade que o gerente de projeto tem
de, com sua personalidade e seu especial estilo pessoal ou da experincia que possui em
projetos anteriores, unir o grupo num objetivo comum. Dessa forma, a equipe se sentir
honrada em trabalhar com essa pessoa.

Frame (1995)44 menciona que dar um nome ao time bem como promover encontros informais
entre os membros da equipe, uma forma de que todos percebam que no esto trabalhando
sozinhos. Por isso importante realizar sempre um evento de kick-off do projeto e com
freqncia realizar reunies para reviso do status do projeto onde cada membro da equipe

43

VERGARA, Sylvia Constant. Gesto de Pessoas. So Paulo: Atlas, 1999.

J. Davidson, Managing Project in Organizations, How to make the best use oftime, techniques and
People, Jossey-Bass Inc. San Francisco, Califomia, 1995.

44 FRAME,

42

possa comentar suas necessidades, problemas ocorridos, solues adotadas, bem como entre o
grupo, podero ser solucionados problemas que individualmente seriam mais diflceis de se
solucionar por si s.

Ter a equipe trabalhando toda junta em um local comum tambm facilita o processo de
identidade do grupo. Menezes (2001)45 tambm entende que a existncia de um local de
trabalho especfico para a equipe de projeto um fator que deve ser considerado pois,
proporcionando adequado local de trabalho e dispondo de meios e modos para que a
comunicao (formal e, principalmente, a informal) seja favorecida, far com que a equipe se
sinta bem, fazendo parte de um ambiente de franca cooperao e facilitando assim o processo
de integrao da mesma. O resultado obtido quando se favorece o trabalho em equipe, ser
medido atravs de avaliaes de desempenho pessoal de cada um dos membros da equipe.

2.2.1.3

Processos motivacionais

A motivao algo intrnseca ao ser humano e as razes que levam uma pessoa a se motivar
diferem de pessoa para pessoa. Mudanas no ambiente externo do projeto, podero afetar a
motivao da equipe. Lidar com essas diferenas uma habilidade que deve possuir um bom
gestor de projetos. Antes de mais nada o gestor precisa aceitar a existncia dessas diferenas.
O gestor, como lder do projeto, precisa estar atento a essas mudanas dentro da equipe de
forma a reagir prontamente com aes que garantam a continuidade motivacional da equipe de
projeto.

A motivao est diretamente relacionada ao reconhecimento pelo esforo empreendido em

uma tarefa, um trabalho ou um projeto. Saber dar reconhecimento equipe pelo trabalho
realizado ou at mesmo dar feedback durante o processo de elaborao do projeto, garante a
continuidade e a qualidade do resultado a ser obtido. importante fazer com que as pessoas se
orgulhem daquilo que fazem. Portanto, estimular e exigir da equipe e seus membros a busca
por altos padres qualidade, estipulando altas medidas de desempenho tambm os estimula a

45

MENEZES, Luiz Csar de Moura, Gesto de Projetos, Atlas, So Paulo, SP, 2001

43

desenvolver e mostrar todo o seu potencial, funcionando como um fator motivacional para
todo o grupo.

Quando se realiza um determinado trabalho e no se recebe uma recompensa ou se

reconhecido pelo esforo empreendido, ocorre normalmente um processo de frustrao. Para
essa frustrao, as pessoas criam mecanismos de defesa que vo desde mecanismos
psicolgicos at qumicos. Ao contrrio, quando ocorre o reconhecimento, ocorre a plenitude,
a liberao de talentos, as pessoas extravasam caractersticas pessoais ocultas que no tinham
conhecimento de que as possuam. Manter as pessoas motivadas no tarefa fcil. Identificar
que aes ou que circunstncias fazem com que uma pessoa ou uma equipe se mantenha
motivada, uma tarefa e um objetivo que deve ser perseguido pelo lder do projeto.

A motivao pode vir atravs de uma recompensa financeira, pelo simples desejo de sentir-se
competente executando o seu trabalho, pelo fato de saber que est desenvolvendo tarefas e
atividades altamente complexas e desafiadoras, enfim, as motivaes so vrias e diferem de
pessoa para pessoa. As equipes de projeto so formadas por pessoas as quais so
freqentemente retiradas das suas rotinas operacionais e levada para formar parte dessa equipe
de projeto, por um determinada perodo de tempo que, de acordo com a necessidade, poder
ser curto ou longo ou podem at mesmo participar simultaneamente de vrios projetos ao
mesmo tempo. Essa alternncia poder fazer com que elas no se sintam efetivamente parte da
equipe, tenham dificuldade para desenvolver um Team Building. Tambm poder fazer com
que se comprometam menos com os resultados do projeto. Se isto ocorrer, ir dificultar
bastante o trabalho do gerente de projeto.

2.2.1.4

Criando uma equipe de projeto de alta performance - uma equipe de sucesso

Cleland (1999) menciona que "uma equipe de sucesso e de alta performance apresenta no seu
cerne uma srie de aspectos culturais que representam um diferencial de sucesso em um
projeto. Normalmente se encontra nessas equipes um tipo de performance onde no se
sobressaem os egos, onde seus membros compartilham os mesmo interesses e onde se

44

identifica uma grau de confiana muito elevado entre eles,,46. "Equipes de alta performance
devem desenvolver uma forte confiana entre os seus membros, devem confiar no prximo,
contar com o apoio de todos, confiar no constante compromisso dos demais membros da
equipe e prometer apenas o que pode ser efetivamente entregue,,47.

Thamhain(1999) 48 identifica caractersticas chave presentes em uma equipe de sucesso. Essas

caractersticas so resumidas na Tabela A - Caractersticas de Equipes de Projeto de
Sucesso apresentada a seguir:

Tabela A - Caractersticas de Equipes de Projeto de Sucesso

Caractersticas do Lder da
Caractersticas dos Membros da
Equipe
Equipes
Dever estar confortvel com. Devero ter a habilidade de
Alta Performance
Os
um ambiente de incertezas
rapidamente se adequar s
membros
da
equipe
mudanas
consistentemente
trabalham
duro e demonstram um alto
Dever estar orientado
grau de interesse, dedicao e
soluo
de
problemas. Devero ser tolerantes e ter
motivao no projeto, junto a
(tcnicos, administrativos, de
motivao e muita energia
seus colegas
cronograma e custos) e deve
obter satisfao pela resoluo. Devero ter uma performance
desses problemas
consistente
Bem Organizada - Papis e
responsabilidades, autoridade
Dever ter uma postura. Devero ser organizados
e fluxo de informao so bem
positiva e a habilidade de
definidos e entendidos por
demonstrar
entusiasmo
e . Possuir uma viso otimista das
todos. Alm disso, existe
energia
coisas
pouco ou nenhum conflito
relacionado
com
os
Dever ter experincia e . Estar interessados no seu
procedimentos do projeto e
conhecimento da organizao,
desenvolvimento
e
sua administrao
do mercado e da tecnologia
crescimento pessoal
envolvida no projeto assim
como de princpios de gesto,
Possuir uma vida pessoal
Bem Planejada - O projeto
sistemas e metodologias de
possui objetivos claramente
estvel
gesto de projetos
definidos e planos bem
estabelecidos assim como,
cronogramas,
oramento,. Dever
ter
qualificaes
sistemas de monitoramento e
suficientes e aplicar seu
conhecimento e expertise ao
reporting
projeto e seus problemas
Boa Interdependncia da

Caractersticas da Equipe

46CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd. Edition. Singapore:
McGraw-Hill, 1999.
47 Idem.
48HANS J.Thamhain professo de Administrao no Bentley College em Massachusetts e o redator do
Captulo 17 - Trabalhando com Equipes de Projeto, em CLALAND, David I. Project Management. Strategic
Design and Implementation. 3rd. Edition. Singapore: McGraw-Hill, 1999.

45

Caractersticas da Equipe

Caractersticas do Lder da
Equipe

Caractersticas dos Membros da

Equipes

Equipe - Os membros da
equipe esto comprometidos
com os objetivos do projeto e
metas,
demonstram
um
elevado grau de confiana e
promovem um ambiente que
propicia um bom fluxo de
informao e comunicao.
Fonte: J. Tuman, Jr., Success Modeling: A Technique for Building a Winning Project Team, paper apresentado
no Seminrio/Simpsio do Project Management Institute, Montreal, Canada, Setembro de 1986, p.97.

De acordo com Thamhain (1999t 9 um fator de diferenciao para uma equipe de sucesso o
Team Building50, sendo um processo contnuo que requer qualidades de liderana e
entendimento da organizao, suas interfaces, autoridade, estruturas de poder e fatores
motivacionais, crucial em ambientes onde atividades multidisciplinares complexas requerem a
integrao de qualificaes de muitos especialistas funcionais bem como sustentam grupos
com diversas culturas organizacionais e valores. Antes de 1980, os estudos sobre a dinmica
de formao de grupos de trabalho e critrios para formao de equipes de alta performance
levavam em considerao apenas o comportamento dos membros da equipe dando ateno
limitada para questes como ambiente organizacional e liderana de equipes. De l para c,
esses estudos se aprofundaram em questes como planejamento, treinamento, estrutura
organizacional, natureza e complexidade das tarefas e suporte da gerncia snior entre outros,
passando a serem melhor analisadas.

A criao de equipes de alta performance est intimamente ligada capacidade dos lderes de
projeto criarem um ambiente que atenda s necessidades da equipe bem como promovam um
ambiente de trabalho e uma cultura dentro da equipe que permita a obteno dos melhores
resultados dentro do projeto. Isto por, sua vez, vai requerer dos prprios gestores e lderes de
projeto, habilidades cada vez maiores para lidar com este tipo de situao. Eles no
necessitam apenas possuir excelentes qualidades tcnicas e boa liderana mas ser necessrio,
49 HANS

J. Thamhain professo de Administrao no Bentley College em Massachusetts e o redator do

Captulo 17 - Trabalhando com Equipes de Projeto, in CLALAND, David I. Project Management. Strategic
Design and Implementation. 3rd Edition. Singapore: McGraw-Hill, 1999.
50Esprito de equipe para Thamhain pode ser descrito como um processo onde se renem uma srie de indivduos
com diferentes necessidades, histricos e experincias a transform-los em um grupo integrado, em uma fora
tarefa eficaz.

46

por parte da organizao, facilitar o ambiente organizacional adequado para gerenciar essas
equipes de forma eficiente.

Thamhain (1999) menCIOna o fato de hoje, o Team Building ser considerado por muitos
especialistas em gesto de projetos uma das mais crticas caractersticas e qualidades
necessrias para a o sucesso de um projeto, dependendo em grande parte no s do esforo
posto na montagem da equipe bem como na integrao das atividades dos diversos
especialistas funcionais.

2.2.1.5

A tomada de deciso na equipe

A tomada de deciso dentro de uma equipe de projeto algo que nem sempre fica muito claro.
As decises em uma equipe, acabam sendo tomadas por uma srie de indivduos, acaba sendo
algo compartilhado pela prpria equipe de acordo com a fase em que o projeto se encontra.
Por exemplo, o incio ou no de um projeto normalmente definido pelo Comit Executivo
do Projeto. J decises durante a fase de planejamento normalmente so realizadas pelas
equipes funcionais, especialistas em temas especficos do projeto. Enquanto que, na fase de
implantao do projeto em si, a tomada de decises est nas mos do gerente de projeto.
Delegar responsabilidades e poder em um projeto, entretanto, tem um impacto positivo no seu
prprio andamento. Portanto, na opinio de Cleland (1999), "sempre que as decises a serem
tomadas individualmente no gerem um impacto maior no oramento, cronograma e na
utilizao dos recursos disponveis e alm disso, se elas no criarem maiores problemas
polticos,,51, podero ser tomadas pelos especialistas membros da equipe do projeto. Apenas
as questes mais cruciais devero requer o envolvimento direto do gerente de projeto.

Frame (1995)52 tambm compartilha dessa opinio e caracteriza esse processo atravs da
Figura IX - Processo Decisrio53 apresentada a seguir:

51CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd. Edition. Singapore:
McGraw-Hill, 1999.
52FRAME, J. Davidson, Managing Project in Organizations, How to make the best use of time, techniques and
People, Jossey-Bass Inc. San Francisco, Califomia, 1995.

47

Especialista da
Equipe de Projeto
Haver mudana
significativa
no cronograma?
No
Haver mudana
significativa
no oramento?

Gerente do Projeto

No
Havero desvios
significativos nas
especificaes originais?
No
A deciso em questo
pode se tornar
um problema poltico?
No
Tome a Deciso

Figura IX - Processo Decisrio (Frame(1995

2.2.1.6

Conflitos na equipe de projeto

Quando um grupo de pessoas se rene em um projeto, considerando-se as caractersticas dessa

equipe - normalmente formada por pessoas das mais diversas especialidades e reas da
organizao - e do processo de sua constituio, o surgimento de conflitos inevitvel. Os
conflitos podem surgir por diversas razes, pela dificuldade de especialistas comunicarem aos
demais membros da equipe, o modo como as coisas deveriam ser feitas, pelo fato de certas
pessoas no quererem ou no gostarem de se relacionar com outras da mesma equipe por
preconceito, ou por outra razo qualquer. Lidar entretanto com esse tipo de conflito tarefa do
gerente de projeto. "Estudos mostram que o gestor de projetos passa aproximadamente 20%

53 Idem.

48

do seu tempo lidando com os conflitos dentro da equipe"s4. possvel entretanto, para o
gerente de projeto, extrair algum tipo de beneficio desse conflito. Atravs da discusso das
causas desse conflito podem surgir formas alternativas de resolve-los e se poder aprender de
que forma se trabalhar melhor em equipe.

De acordo com Cleland (1999), o prprio conflito ajuda a desenvolver uma cultura dentro da
equipe na qual existe uma motivao em se trabalhar juntos na busca do consenso. O conflito
por sua vez, ajuda a equipe a se acostumar com o habitual e dinmico andamento do projeto e
com as demandas que so impostas pelos Steakholders do projeto.

Algumas das tpicas causas de conflitos so, de acordo com Cleland (1999), a competio
pelos recursos disponveis, a no compreenso dos papis a serem desempenhados
individualmente e coletivamente pela equipe de projeto, a discordncia quanto aos objetivos,
metas e estratgias do projeto bem como a quebra de etiqueta e protocolo pelos membros da
equipe. Existem tambm os preconceitos pessoais, ticos e morais ou atitudes que
comprometem ou quebram o bom relacionamento interpessoal. A falta de entendimento do
sistema e metodologia de gerenciamento do projeto que est sendo usada como referncia para
o projeto em andamento tambm influencia significativamente o bom andamento deste e
potencializa o surgimento de conflitos. A no concordncia ou inexistncia de sistema de
recompensas e promoes para os bons resultados obtidos no projeto tambm gera conflitos
entre os membros da equipe. A falta ou precariedade dos canais de comunicao bem como a
falta de entendimento da estrutura matricial da organizao so mais alguns dos fatores que
tipicamente propiciam o surgimento de conflitos nos projetos.

O surgimento do conflito normalmente gera frustrao ou um profundo sentimento de

insegurana e insatisfao principalmente quando este no solucionado. Quando no
resolvido, as pessoas tendem a se preocupar com os caminhos que esse conflito possa tomar.
Mesmo no momento em que uma soluo para o conflito encontrada, sempre fica um
resduo emocional no ar pois as pessoas nem sempre conseguem esquecer ou perdoar as

54

K.W. Thomas and W.H Schmidt, "A Survey of Managerial Interests with Respect to Conflict", Academy of
Management Joumal, 10, 1976, pp.315-318 em CLALAND, David I. Project Management. Strategic Design
and Implementation. 3rd Edition. Singapore: McGraw-Hill, 1999.

49

questes que levaram ao conflito. Pinto e Kharbanda (1995)55 sugerem alguns modos de
solucionar ou tratar os conflitos e eles devem ser avaliados e implementados pelo gestor do
projeto. So eles evitar o conflito ignorando as causas de sua existncia permitindo que ele
continue sob circunstncias controlveis. No prestar ateno ao conflito, limitar a sua
interao no conflito ou apenas separar fisicamente os causadores do conflito. Deixar esfriar,
ou seja, dar tempo ao tempo at que as partes envolvidas consigam tratar o conflito de uma
forma mais racional. Confrontao atravs de encontros frente a frente com os envolvidos no
conflito para um "acerto de contas" ou "lavagem de roupa suja". Cada um dos mtodos
acima dever ser utilizado de acordo com a circunstncia apresentadas em cada projeto. Sua
opinio que o envolvimento da alta gerencia do projeto nestas questes no deve ser
freqente pois normalmente ela no est inteiramente a par dos detalhes que geraram o
conflito, valendo a pena deixar a equipe, que est mais envolvida, funcionar como um
intermediador na busca da soluo para esse conflito.

2.2.1.7

A desmobilizao da equipe

A desmobilizao da equipe consiste no retomo das pessoas s suas reas funcionais de

origem, quando os recursos so internos organizao ou o encerramento de contratos, com a
conseqente dispensa da equipe alocada ao projeto para que esta possa ser realocada a outros
projetos, quando os recursos so externos. Sendo tanto os recursos internos como externos,
faz parte do processo de encerramento a elaborao de relatrios de desempenho e a
comunicao ifeed back) aos membros da equipe do projeto do desempenho obtido durante o
mesmo. Esta etapa s vezes dificil pois gera muita ansiedade e expectativa nos membros da
equipe quanto ao seu futuro e possvel realocao nas reas de origem ou em novos projetos,
devendo o gestor do projeto ser muito cauteloso e estar muito atento s reaes da equipe
nesse momento. Quando o processo de encerramento ocorre em etapas, necessrio ter
cuidado adicional para que as atividades remanescentes a serem desempenhadas sejam
concludas e para que a equipe que permanece no perca o interessa por elas.

55

JEFFREY K. Pinto e OM P. Kharbanda, "Project Management and Conflict Resolution", Project Management
Joumal, Dezembro de 1995, pp. 45-54

50

Outras situaes que podem ocorrer segundo Cleland (1999), so a perda da identidade da
equipe, o medo pela possibilidade de no ser novamente integrado no local de origem ou a um
novo projeto, entre outras. A seguir, apresentamos na Figura X - Detalhamento da estrutura
de problemas mais comuns do encerramento de um projeto, onde Cleland (1999) resume
esses problemas.

Figura X - Detalhamento da estrutura de problemas mais comuns do encerramento de

um projeto
Problemas da
Tenninao
de Projetos

I
Emocionais

Equipe

Medo de no ter
trabalhos futuros
Perda do interesses nas
atividades
remanescentes
Perda da motivao no
projeto
Perda de identidade da
equipe
Metodologia de
realocao de pessoas

I
Cliente

I
I

Mudana de atitude
Perda de interesse no
projeto
Indisponibilidade de
pessoas chave

Internos

I
Intelectuais

Identificao dos
produtos restantes a
serem entregues
Controle dos custos do
projeto
Encerramento de ordens
de trabalho ou pacotes
de trabalho (tarefas
remanescentes)
Recompilao da
documentao do
projeto

I
Externos

Acordos com o cliente

sobre produtos
pendentes de serem
concluidos
Comunicao do
encerramento do
projeto organizao e
fornecedores externos
Fechamento das
instalaes fisicas do
projeto

Diviso de esforos
Seleo dos recursos a
serem realocados

De acordo com Valeriano (1998), esse processo deve ser feito "com critrio, sem traumas nem
ressentimentos a fim de no prejudicar formaes futuras de equipes.,,56

Durante o processo de encerramento do projeto e desmobilizao da equipe, normalmente

ocorrem os chamados learning meetings 57, ou encontros de aprendizado, como so chamadas
as reunies que ocorrem durante o encerramento do projeto e cujo objetivo avaliar
VALERIANO, Dalton L., Gerenciamento Estratgico e Administrao de Projetos, Makron Books, So Paulo,
SP,2001.
57 MENEZES, Luiz Csar de Moura, Gesto de Projetos, Atlas, So Paulo, SP, 2001
56

51

permanentemente o aprendizado obtido com o mesmo. Nelas so analisados os erros

cometidos, por exemplo, no gerenciamento do projeto, no cumprimento dos prazos e dos
custos do projeto, na qualidade, escopo e os riscos pelos quais passou o projeto. Tambm so
propostos planos de ao para a eliminao de situaes insatisfatrias que tenham ocorrido
no projeto. Essas reunies so importantes, de acordo com Menezes (200 I), para que possam
ser analisados os erros e os acertos cometidos e cada fase do projeto. No so eventos fceis
pois costumam haver "ataques" por parte dos membros da equipe como uma forma de defesa
para possveis erros cometidos. Alternativamente, possvel a aplicao de questionrios ao
invs de reunies. Essas reunies so teis no s durante o prprio projeto como tambm
para evitar que se cometam os mesmo erros em projetos futuros.

2.2.2 Liderana
At agora discutimos a formao da equipe de projeto e as responsabilidades do gerente de
projeto na gesto dessa equipe. Entretanto, o processo de montagem da equipe e do
desenvolvimento de um Team Building vai requerer do gerente do projeto capacidades que
vo alm das tradicionalmente necessrias para a gesto de um projeto. Passaremos agora a
discutir como a questo da liderana influencia na gesto de pessoas e de equipes e a sua
influncia nos resultados dos projetos. Como a varivel Liderana ir funcionar como
diferencial de sucesso.

2.2.2.1

Principais caractersticas da Liderana

Existem uma srie de definies para a palavra liderana. Entretanto, o Professor Thamhain
(1999)

58

ressaltou que, em se referindo questo gesto de projetos, um lder precisa possuir

atributos e habilidades em 3 reas especficas, sendo elas: relaes interpessoais, qualidades

tcnicas e administrativas.

58HANS

J. Thamhain, "Deve1oping Project Management Skills", Project Management Joumal, September 1991,
pagina 39-44.

52

Enquanto alguns estudiosos tratam a questo da liderana referindo-se figura de um lder

como um super heri, outros vem a liderana como sendo uma questo de caractersticas
pessoais que um indivduo possui, ou seja, caractersticas como carisma, inteligncia, energia,
estilo, comprometimento, entre outras. Lderes so pessoas que possuem habilidades para
promover mudanas no s em indivduos bem como em grupos de pessoas ou nas prprias
organizaes. A caracterstica de liderana fica mais ressaltada no momento em que as
pessoas e a organizaes apresentam resistncia mudana proposta, fazendo com que seja
dada mais nfase na liderana democrtica e participativa.

De acordo com McGregor (1960)59, existem quatro caractersticas que esto diretamente
relacionadas com a questo da liderana e delas depender a performance alcanada pelo lder
do projeto. As caractersticas pessoais do prprio lder, as atitudes, necessidades e outras
caractersticas pessoais dos seus seguidores (membros da equipe, etc.), as prprias
caractersticas da organizao como por exemplo, seus objetivos como empresa, a sua
estrutura organizacional e a natureza das tarefas a serem desenvolvidas e o ambiente social,
econmico e poltico no qual o projeto est inserido. Olhando por este aspecto, podemos
perceber que "a questo da liderana, no uma questo de propriedade de um indivduo
especfico e sim uma complexa inter-relao de variveis,,6o

Outro enfoque que pode ser dado para explicar a questo liderana, so os tipos de
comportamento dos lideres tratados pela Teoria dos Estilos de Liderana61 . Esses
comportamentos podem ser Ditatorial, Autocrtico, Democrtico e Laissez-faire.
O lder Ditatorial62 aquele que consegue que o trabalho seja realizado pela presso e pela
imposio e o medo.

O lder Autocrtico aquele que centraliza as decises na sua pessoa, no se interessa, por
exemplo, no feedback da equipe de projeto. Embora ele possa manter uma poltica de portas
59 DOUGLAS McGregor, the Human Side ofEnterprise, New York: McGraw-Hill, 1960
6I dem.
61YERGARA, Sylvia Constant. Gesto de Pessoas. So Paulo: Atlas, 1999.
62CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd. Edition. Singapore:
McGraw-Hill,1999.

53

abertas e escutar todas as opinies da equipe, ele no as utiliza na sua tomada de deciso.
Frame (1995) 63 de opinio que se formos analisar este estilo, "vendo pelo lado positivo, o
estilo autocrtico apropriado em um projeto rotineiro, de baixo risco, aonde a equipe
simplesmente tem a funo de executar as tarefas exatamente como especificado ... quando
deciso rpidas so necessrias e, uma vez que os autocratas no esto preocupados em obter
o consenso da equipe nem em reunir uma quantidade suficiente de informaes para basear as
suas decises, eles mesmos podem decidir rapidamente,,64.

o lder Laissez-faire aquele que atribui ao grupo a responsabilidade de estabelecer as suas

prprias metas e tomar as suas prprias decises. O estilo Laissez-faire poder ser eficaz em
um projeto onde o estado da arte impera, onde os gerentes necessitam deixar a equipe criar.
Em equipes que no podem ou no gostam de estar sob constante superviso esse estilo
produz resultados bastante satisfatrios, entretanto esse estilo de liderana poder ser um total
fiasco quando se requer uma rpida tomada de deciso.

O lder Democrtico aquele que descentraliza o processo decisrio e "busca o input da

equipe para a tomada de deciso ... o qual aumenta o comprometimento da equipe na execuo
das decises tomadas uma vez que ela mesma participou do processo decisrio".65

O estilo democrtico mais permissivo, busca consenso e participao da equipe, est mais
centrado nas pessoas enquanto que o estilo autocrtico est mais centrado nas tarefas, sendo
este mais restritivo e socialmente distante. Cada uma destas caractersticas apresenta pontos
positivos e negativos. Enquanto os estilos democrtico e o laissez-faire tendem a manter o
grupo coeso, eles no necessariamente garantem o aumento da produtividade enquanto o
autoritrio sim. Entretanto este tende a desmotivar a equipe. Em resumo, no uma tarefa
fcil manter um equilbrio desses dois fatores.

FRAME, J. Davidson, Managing Project in Organizations, How to make the best use of time, techniques and
People, Jossey-Bass Inc. San Francisco, Califomia, 1995.
64 I dem.
65 FRAME, J. Davidson, Managing Project in Organizations, How to make the best use oftime, techniques and
People, Jossey-Bass Inc. San Francisco, Califomia, 1995.
63

54

Estabelecer quais devem ser as caractersticas de um verdadeiro lder em um projeto, no

realmente uma tarefa simples, entretanto, algumas caractersticas se mostraram, ao longo do
tempo e aps diversos estudiosos analisarem e compararem os estilos de liderana de diversos
gestores de projetos, reincidentes e valem a pena ser mencionadas.

So elas, por exemplo, a ambio pessoal do lder e que o leva a obter o sucesso
simultaneamente conquista do sucesso da sua empresa, ou seja, coincidem ambos objetivos,
os da empresa e os seus objetivos pessoais. Os lderes esto presentes para suas equipes e
ningum duvida de quem est no comando, eles escutam, debatem, e esto prontos a executar
o que tiver que ser feito para alcanar os objetivos. O verdadeiro lder identifica e premia os
vencedores, evita fazer ou tomar as coisas complexas, justo e paciente, humano ... pois
reconhece que lder apenas porque seus subordinados assim o permitem manter-se no papel
de lder e trabalha duro para garantir os recursos necessrios para que o projeto alcance os
resultados esperados.

Em um projeto, o lder deve estar consciente e atento para o fato de que ele dever se
relacionar no s com seus superiores bem como com seus subordinados e pares e com todo o
resto da organizao. Alm disso, precisa estar atento a fatores como durao do projeto,
cronograma, metas, disponibilidade de recursos, entre outros. Acima de tudo ele, como lder,
precisa ser flexvel e possuir a capacidade de se adaptar a diversos cenrios e circunstncias e
principalmente dever estar atento e perceptivo s necessidades de seus liderados uma vez que
seu comportamento e sua performance, por tabela, tambm afeta a equipe liderada por ele.

2.2.2.2

Liderana e Poder

Existe uma linha tnue entre liderana e poder. Segundo Vergara (1999)

66,

no mundo atual,

uma nova forma de ver e lidar com o poder se faz necessria, o que implica mudanas nos
modelos mentais. O mundo atual est a exigir o compartilhamento assumido e construtivo do

66

VERGARA, Sylvia Constant. Gesto de Pessoas. So Paulo: Atlas, 1999.

55

poder. Compartilhar poder mais do que delegar. O gestor amplia seu poder quando libera as
pessoas para serem o que elas podem ser.

Nos dias de hoje, a palavra que mais se aproxima do conceito de compartilhamento de poder
empowerment, um processo no qual se criam condies e habilitam-se as pessoas de todos os

nveis da empresa para assumirem responsabilidades na satisfao de seus clientes.

Compartilhar poder significa abrir-se para o dilogo.

2.2.2.3

Diferena entre gerentes de Projetos e Lderes

Frame (1995) comenta que se perguntassem a cada gerente de projeto quaIs as suas
responsabilidades, ele provavelmente responderia que so: "executar o trabalho no prazo,
dentro do oramento e de acordo com as especificaes. Mas claro que as atribuies de um
gerente de projeto vo alm disso. Ele tambm responsvel pelo desenvolvimento da equipe,
serve de intermedirio entre a alta administrao e a equipe de projeto e transmite
organizao as lies aprendidas durante o projeto,,67.

A gerencia de projeto uma atividade muito mais ampla. Um gerente de projeto possui muito
mais atribuies e responsabilidades do que somente liderar. J a liderar, parte da gesto de
projetos. Por sua vez, enquanto de um gerente se espera que faa o planejamento e organize as
tarefas do projeto, garantindo a sua execuo, de um lder se espera que ele faa os outros o
seguirem. "Liderana a habilidade de persuadir o grupo a perseguir os objetivos traados
com entusiasmo. o fator humano que rene o grupo e o motiva para alcanar os objetivos
estabelecidos. Atividades gerenciais so casulos adormecidos at o momento em que o poder
da motivao guia as pessoas em direo aos objetivos.,,68 Pode-se dizer que um gerente faria
as coisas bem feitas (com eficincia) enquanto um lder faria a coisa certa (com eficcia).
Entretanto, gestores de projetos no podem ser apenas gestores, eles precisam ser tambm
lderes.

67FRAME, 1. Davidson, Managing Project in Organizations, How to make the best use of time, techniques and
People, Jossey-Bass Inc. San Francisco, California, 1995.
68KEITH Davis, Human Relations at Work, 3rd ed. New York, McGraw-Hill, 1967

56

De acordo com Cleland (1999)69, podemos resumir na Tabela B - Principais diferenas

entre Gerentes e Lderes, a seguir, as principais caractersticas que diferenciam gerentes de
lderes de projetos:

Tabela B - Principais diferenas entre Gerentes e Lderes

Gerentes
Colabora com o desenho, desenvolvimento e
operacionalizao dos sistemas que iro suportar
o projeto.

Lderes
Encontra ou desenvolve uma viso de futuro para
o projeto e a vende para a equipe de projeto e os
demais Stakeholder.

Mantm o controle sobre a eficincia e a eficcia

dos recursos utilizados no projeto e os sistemas
de controle que suportam o uso desses recursos.

Constri uma rede de interesses com os

Stakeholders, desenvolvendo estratgias que
garantam o seu apoio ao projeto.

Desenha e executa as operaes de planejamento,

organizao e controle do projeto.

D o direcionamento geral ao projeto.

Preocupa-se com a eficincia no uso dos recursos

do projeto.

Promove condies necessrias volta do projeto

que motivam e garantem o comprometimento dos
Stakeholders com o projeto.

Mantm os Stakeholders informados

progresso ou atraso do projeto.

Toma-se um smbolo do projeto e seus objetivos.

Realoca recursos onde necessrio para garantir o

suporte equipe de projeto.

Constri um ambiente de suporte poltico para o

projeto entre os Stakeholders.

Assegura o bom funcionamento do sistema de

comunicao utilizado no projeto.

Mantm constante preocupao com o uso

eficiente dos recursos do projeto.

Prov monitoramento, treinamento e outros.

meios que permitam o desenvolvimento
individual e coletivo das competncias
necessrias equipe do projeto.

capaz de tomar decises.

do.

Fonte: CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd Edition.
Singapore: McGraw-Hill, 1999

Nem todas as caractersticas mencionadas acima sero encontradas em um gestor de projetos

mas quantas mais dessas caractersticas ele possuir, maior probabilidade haver de que o
projeto alcance os objetivos esperados quando da sua concluso.
69CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd Edition. Singapore:
McGraw-Hill, 1999.

57

2.2.2.4

A liderana como diferencial na Gesto de Projetos

De acordo com Cleland (1999), o fator que impulsiona a equipe de projeto e no limite
determina qual projeto ir falhar ou ir obter sucesso, a liderana implcita no projeto em
todos os nveis da organizao. Quando um projeto est em processo de implantao, a chave
para fazer com que ele acontea a qualidade da sua Liderana.

Quando um lder possui uma viso ampliada do projeto, ele se antecipa identificando as
possveis necessidades de recursos para o projeto, prov inspirao e motivao para a equipe.
Trabalha e organiza o projeto de forma a que os objetivos de tempo, escopo e custo sejam
satisfatoriamente alcanados ao trmino do projeto.

Warren Banis em seus estudos, identificou certas competncias de liderana que fazem
substancial diferena quando identificadas em gestores de projetos. Para ele, o gerente precisa
ser capaz de gerenciar a ateno da equipe. Com isso, ele quer dizer que os lideres de sucesso
tem a capacidade de atrair a ateno da equipe em relao ao objetivo do projeto. Devem
possui a capacidade de visualizar e principalmente transmitir essa viso e envolver as pessoas
com os objetivos do projeto. O gerente de projeto precisar tambm ser capaz de dar um
sentido ao projeto e correlacion-lo com os objetivos estratgicos da empresa. Isso quer dizer
dar um sentido, uma razo ao projeto. Dessa forma, no s ficar mais fcil para a
organizao aceitar e "comprar" esse projeto como tambm para a equipe de projeto.
Confiana outra caracterstica que dever estar presente nos gestores de projetos. Ele dever
transmitir confiana pois nele tambm ser depositada a confiana da organizao bem como
a confiana da equipe de projeto. Essa confiana poder ser transmitida atravs do
estabelecimento, por ele, de altas medidas de performance as quais espera que sejam atingidas
pela equipe de projeto que, estimulada, reaja a essa solicitao prontamente.

Mas acima de tudo, tanto gestor quanto equipe necessitam demonstrar estar comprometidos
com os resultados estabelecidos para o projeto. E por fim, outra caracterstica importante dos
gestores, ser capaz de gerenciar a si mesmos. Manter-se motivado e demonstrar motivao e

58

comprometimento com os resultados do projeto crtico. Como diz Bennis (1984) "Como
mdicos incompetentes, gerentes incompetentes podem at tomar a vida pior do que ela j ,
podem fazer as pessoas ficarem doentes ... alguns gerentes provocam ataques cardacos e crises
nervosas a si mesmos e o que pior, nos membros de suas equipes,,7o. Erros podem ser
cometidos mas os verdadeiros lderes aprendem com eles e rapidamente recomeam
novamente.

Como mencionado por Bennis (1984), em projetos onde so encontrados lderes, as pessoas se
sentem parte do um todo, cada uma faz diferena no sucesso do projeto ou da organizao. O
aprendizado e a competncia fazem a diferena, no existem erros mas sim a aceitao desses
erros e o aprendizado que se obtm atravs deles. As pessoas fazem parte do conjunto, como
uma grande famlia e o trabalho se toma excitante, estimulante, desafiador e principalmente
divertido.

2.2.2.5

Algumas competncias para um Lder de Projeto

Alm de todas as caractersticas j mencionadas Bennis (1984) adiciona ainda que um lder de
projeto deve entender a tecnologia envolvida no projeto. Mas a que nvel de profundidade
alguns podem se perguntar, o suficiente para fazer as perguntas certas e avaliar se as respostas
dadas apresentam ou no coerncia. Se um grau mais profundo de conhecimento for
necessrio, o lder de projeto dever se valer da ajuda dos especialistas que, com certeza,
fazem parte da equipe de projeto. Dever ter conhecimento do processo de gesto ou seja, ter
conhecimentos e experincia bsica em cargos de gerencia. Ter noes de planejamento,
organizao de tarefas, tcnicas motivacionais, direo e controle bem como a habilidade para
visualizar o contexto do sistema a ser implantado dentro da estratgia do projeto. Um projeto
composto de um seqnciamento de subprojetos e atividades e uma alterao, atraso ou
problema ocorrido em um desses subprojetos, ir afetar os demais. Ao identificar problemas,
o gestor de projetos precisa saber tomar decises dentro do contexto do projeto. Necessita
saber coletar dados suficientes para poder avaliar as possveis decises e implement-las.

70

WARREN Bennis, "Good Managers and Good Leaders", Across the Board, October 1984.

59

Precisa saber considerar meios alternativos para atingir os objetivos do projeto e entregar
produtos que agreguem valor para os clientes, traduzidos em produtos, processos ou servios.
Dever sempre ter uma atitude positiva, nas horas boas e principalmente nas horas ms do
projeto. Precisa saber estimular a equipe e os Stakeholders, enfim, ser o mentor da equipe, seu
professor, seu coacher. s vezes ele acaba por fazer mais o papel de facilitador, trabalhando
focado na equipe e nos Stakeholders para alcanar os resultados.

necessrio ter habilidade para assumir riscos na gesto do projeto. Quanto mais complexo o
projeto, maior o seu risco. importante identificar dentro do projeto aqueles membros na
equipe capazes de avaliar e mensurar apropriadamente o risco bem como trabalhar com
especialistas em desenhar estratgias que reduzam esse risco. Deve ser persistente porm
tendo o cuidado de no gerar um abismo entre a realidade e o sonho.

Um gestor de projeto dever possuir atributos favorveis ao relacionamento interpessoal que o

tomem capaz de no s selecionar a equipe de projeto, bem como trabalhar com esta e os
demais Stakeholders do projeto, estabelecendo uma cultura de comprometimento, lealdade,
respeito, confiana e dedicao. Dever ter a capacidade de trabalhar atravs e com pessoas,
ganhando delas a confiana e o suporte em todas as circunstncias do projeto. Um dos fatores
que causam a maior parte das falhas dos gerentes de projeto o fato deles no possurem
habilidades de relacionamento interpessoal.

sucesso de um projeto, dependente em grande grau da interatividade entre equipe de

projeto, Stakeholders e a Organizao. Muitas vezes a rede de relacionamentos existente na

organizao uma varivel que conta quando se necessita ter algo feito e vai muitas vezes
alm da autoridade do gestor de projetos. No inicio do projeto, o lder de projeto dedica uma
boa parte do seu tempo alm do planejamento, criao de uma rede de relacionamentos,
identificando pessoas que ele entenda que possam ser teis em algum momento do projeto
para fazer as coisas acontecerem. Estas atividades esto ligadas tambm a atividades de

Change Management, especificamente no mapeamento dos Stakeholders, tema que ser

tratado com mais detalhes na seo 2.5.

60

Por fim, a habilidade mais esperada de um gestor e lder de projetos, a capacidade de

produzir resultados atingindo os objetivos propostos no tempo, dentro do custo e dentro do
escopo.

A pessoa que gerencia um projeto necessita ser simultaneamente, um bom lder e um bom
gerente, reunindo o maior nmero de caractersticas mencionada at aqui.
Cleland (1999) em seu livr07l comenta que em um encontro de gerentes seniores experientes
em gesto de projetos de uma empresa de sistemas, nove participantes foram solicitados a
escrever em palavras ou frases, as caractersticas que eles observaram em bons lderes de
projetos com os quais eles se depararam durante suas carreiras. Outros 8 desses mesmos
gerentes foram solicitados em seguida, a comentar as caractersticas observadas em maus
lderes de projetos. Os resultados dessa anlise apresentamos na Tabela C - Anlise
comparativa entre Bons e Maus Lderes a seguir:

Tabela C - Anlise comparativa entre Bons e Maus Lderes

Bons Lderes de Projetos

Maus Lderes de Projetos

Possuem atitude positiva.

Se utilizam do cargo e da autoridade para orientar

a equipe.

Possuem interesse nos aspectos pessoais dos

membros da equipe.

No aceitam sugestes e/ou rejeitam sugestes

no politicamente corretas.

Antecipam-se aos problemas antes de que eles se

tomarem evidentes.

Mudam o direcionamento do projeto e/ou o

escopo pela sua prpria vontade culpando os
outros pelo que foi feito de errado.

Comunicam claramente a viso de futuro que o

projeto necessita alcanar e comunicam essa
viso para a equipe envolvida no projeto,
permitindo que esta faa contribuies para o
alcance dos objetivos.

No pedem ajuda, no do o exemplo e

desconhecem os aspectos tcnicos do processo.

So tambm gerentes orientados a resultados.

No parabenizam, apenas criticam. No sabem

dar os parabns por um trabalho bem feito.

Orientam seus subordinados no direcionamento.

do trabalho permitindo o seu crescimento focado

No transmitem a viso de futuro e no explica o

porque.

71CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd. Edition. Singapore:
McGraw-Hill, 1999.

61

Maus Lderes de Projetos

Bons Lideres de Projetos

em objetivos.

Exercem o papel de mentor e no de mestre.

No se posicionam com relao aos problemas

quando eles surgem.

Escutam sugestes e idias dos seus subordinados

membros da equipe.

No escutam novas idias, no sabe com o fazer

crticas construtivas. Esperam a perfeio.

Pedem sugestes e idias sobre como solucionar

problemas.

Esto pouco interessado nas pessoas.

Enfatizam o trabalho em equipe.

So sensveis ao efeito que certas decises

provocam na equipe envolvida com o projeto.

Reconhecem as contribuies individuais e as do

grupo.

Saem do escritrio e vo ao campo acompanham

o projeto in loco.

Permitem aos seus subordinados a participao

em subprojetos de sua escolha.

So completamente focados na autopromoo.

Se comunicam com a equipe utilizado termos
negativos, gritando e gesticulando.

Fonte: CLALAND, David I. Project Management. Strategic Design and Implementation. 3,d. Edition.
Singapore: McGraw-Hill, 1999

Vergara (1999) em seu livro "Gesto de Pessoas"n descreve resume uma lista de aes que
um gestor pode fazer para provocar a motivao das pessoas. Curiosamente, a maioria dessas
aes esto diretamente relacionadas com as caractersticas s quais os gerentes seniores e
experientes gerentes de projeto apontaram como caractersticas dos bons lideres. Isso refora o
fato de que procurar ter atitudes como aquelas as mencionadas pelos experientes gestores de
projetos, realmente faz uma grande diferena durante a implantao de um projeto ou na
realizao de um trabalho.

Complementando o que foi mencionado anteriormente, adicionamos algumas outras

caractersticas de lderes de projeto mencionada por Vergara (1999)

72
73

VERGARA, Sylvia Constant. Gesto de Pessoas. So Paulo: Atlas, 1999.

Idem.

73:

62

Reconhecer o trabalho realizado. s vezes basta um simples parabns;

Explicitar as recompensas individuais e as grupais oferecidas pela empresa em um

processo de reconhecimento pelo esforo despendido;

Aceitar as possibilidades e os limites das pessoas. Todos ns, indistintamente, temos

foras e fraquezas;

Compartilhar autoridade. As pessoas tem a tendncia de delegar tarefas sem compartilhar

a autoridade necessria para a sua realizao, desprezando assim a fora do
comprometimento

embutida

na

autoridade.

Comprometimento

funciona

como

cumplicidade na busca e na realizao dos objetivos empresariais;

Permitir que as pessoas errem e incentiv-las a aprenderem com os erros. A questo

crucial no errar mas insistir no erro;

Respeitar o tempo das pessoas;

Educar, sobre tudo dando o exemplo. O exemplo , indubitavelmente, a forma mais eficaz
de educar;

Nunca constranger uma pessoa na frente da outra. Isso di muito, humilha e fere a autoestima.

Dar s pessoas o direto de expressar os seus sentimentos.

Fazer com que o discurso corresponda a uma ao. Quando as palavras correm para um
lado e as aes para outro, o que se transmite incoerncia, desconfiana e insegurana.

63

2.3 A Mudana, o Change Management e algumas consideraes sobre Cultura

Organizacional

Nas sees anteriores foram apresentadas conceituaes relativas a Project Management,

sistemas de ERP e foi apresentado um tpico projeto de implantao de sistemas de ERP. Foi
tambm discutida a importncia da formao da equipe de projeto e foram apresentados temas
relacionados com a questo da Liderana relacionadas aos gestores de projetos. Nesta Seo
vamos fazer uma reviso sobre a Mudana, os fundamentos da metodologia de Change
Management e faremos tambm algumas consideraes sobre a Cultura Organizacional das

empresas e dos projetos.

2.3.1 Identificando os fatores motivadores da Mudana

A globalizao e tudo o que ela trs consigo, tem provocado, no s nas sociedades como
tambm nas organizaes modernas, grandes mudanas. As organizaes tm procurado se
preparar para um novo ambiente onde a concorrncia e a constante busca pela produtividade
as tm levado a dedicar grandes esforos no sentido adaptar suas estruturas organizacionais e
mecanismos de produo s novas demandas. O domnio da informao representa, cada vez
mais, uma nova forma de poder. Aquele que detm a informao, possui uma vantagem
competitiva. Para isso, as empresas se interligam, em todo o mundo, atravs de redes e cabos,
para dominar a informao e conquistar uma eficincia cada vez maior. A organizao
moderna, ganhou uma enorme eficincia com a inovao tecnolgica. A implantao de novos
sistemas de gesto como os sistemas de ERP- Enterprise Resource Planning, tomou-se uma
prtica comum nas grandes organizaes como varivel na garantia de um diferencial
competitivo. Para as empresas serem bem sucedidas diante dessa realidade, necessitam de
sistemas de informao flexveis, capazes de atender quilo que o mercado determina em
tempos compatveis com a velocidade em que o negcio muda. Esta a justificativa para a
proliferao de sistemas de ERP a partir da dcada de 90. Cada vez com mais freqncia,
pacotes de software como solues integradas so vistos pelas empresas como a resposta s
suas necessidades de informatizao por diversos fatores. Dentre esses fatores, podemos
destacar a reduo do tamanho e do custo da rea de informtica pela uniformizao de

64

ambientes de processamento e terceirizao do desenvolvimento e manuteno de sistemas

informticos, a descentralizao do processamento das informaes e da reduo da
dependncia do CP074.

Tambm, a necessidade de simplificao das funes contbeis, financeiras, fiscais,

administrativas e de confeco de relatrios gerenciais bem como a necessidade de reduzir
custos operacionais necessrios e o desejo de manter os processos e gesto do negcio sob
controle bem como o abastecimento das reas de vendas, de compras e de assistncia tcnica
so outros fatores que favoreceram a proliferao de sistemas de soluo integrada.

Evitar duplicidades, assegurar sinergias e gerar indicadores que permitam avaliar melhor o
desempenho do negcio, assim como o desejo de padronizar procedimentos e tecnologias nas
diversas unidades de negcio da organizao e de suas filiais em diversos pases, pela
utilizao de um mesmo sistema de informao que suportasse as operaes da empresa em
todos esses locais, facilitando assim o atendimento das exigncias de seus principais clientes
na troca de informaes e pedidos bem como na simplificao do processo de obteno de
informaes e na utilizao dos mesmos sistemas de informao que eles. E mais do que tudo,
ser pioneiro na utilizao de novas tecnologias, ou aplicar tecnologia similar quela utilizada
por seus principais concorrentes.

Esta tendncia se consolidou a partir do incio dos anos 90, suportada pela disponibilidade
cada vez maior de produtos desta natureza (para todos os tipos de aplicaes, plataformas de
hardware e ambientes operacionais e capacidades de investimento) e pela presso crescente
para a reduo de custos, necessidade de rapidez na resposta s demandas de diversas reas de
negcio e seus usurios e pela incorporao de Best Practices aos sistemas de informao
comercializados.

2.3.1.1

Como a mudana na estrutura organizacional vem sendo tratada pelos

estudiosos

74

CPD - Centro de Processamento de Dados

65

De acordo com a Prof. Fisher (2002), a escola de administrao cientfica (Taylor e Ford),
genericamente considerada o bero do surgimento da administrao como teoria, d um
tratamento superficial e desinteressado ao tema "Mudana Organizacional". Esta linha de
pensamento tem uma viso mecanicista, onde as peas de uma engrenagem so substitudas
ou racionalmente alteradas para apresentarem um desempenho o mais prximo possvel do
esperado. Ou seja, aes de mudana consistem em alterar a configurao de processos de
trabalho com o objetivo de aumentar a sua racionalidade. Elas so tratadas como um projeto
especfico.

J a escola de Relaes Humanas (Mayo ; McGregor), muda "o foco da gesto para as pessoas
e suas relaes com o ambiente organizacional, contrapondo-se viso mecanicista, tendo
sido enriquecida com o surgimento da abordagem scio-tcnica que compatibiliza os
determinantes tcnicos do trabalho com a configurao das relaes sociais, a qual possibilita
a criao de tcnicas e mtodos inovadores de gerenciamento da mudana, baseada em
conhecimentos adquiridos sobre a dinmica dos pequenos grupos - Team Building (Escola de
Desenvolvimento Organizacional). Seu mrito est em associar o conceito de mudana ao
conceito de desenvolvimento, removendo, em parte, as caractersticas negativas - de crise e
conflito, o caos dificil de ser administrado - que o conceito carregava em sua origem,,75.

Mas foi na dcada de 70 e 80, que o avano tecnolgico, a competitividade e o novo

comportamento

dos

consumidores,

fatores

externos

organizao,

motivaram

redirecionamento estratgico das empresas, levando-as a mudanas organizacionais, que

exerceram um papel determinante nos fatores motivadores da mudana. Esta, passou a ser
vista como uma estratgia empresarial, provocando profundas transformaes organizacionais
e obrigando as organizaes empresariais a reverem os seus modelos de gesto pois as
empresas deixaram de viver processos nos quais as mudanas no eram apenas lineares e
incrementais mas abrangentes e transformadoras pois no afetavam apenas algumas reas
organizacionais mas sim os seus processos como um todo.

75

Mudana e Transformao Orghanizacional, Prof. Dra. Rosa Maria Fisher - Mudando os Paradigmas da
Mudana.

66

"Impressionados com a amplitude desses processos de mudana, alguns autores dos anos 70 e
80 conceituaram-nos como Mudanas de Larga Escala definindo-as como uma transformao
durvel no carter organizacional que altera significativamente a performance da
organizao,,76. Quando falam deste carter organizacional, conforme demonstrado na Figura
XI - Carter Organizacional, os autores desta linha de pensamento esto se referindo ao que

se poderia denominar de "Caractersticas Genticas da organizao: a natureza dos produtos

ou servios que justificam a sua existncia; os processos produtivos que adotam para realizlos assim como os procedimentos administrativos e prticas gerenciais com que conduzem
tais atividades, a distribuio de responsabilidades, os critrios de integrao, coordenao e
diferenciao com os quais determinam os padres de relaes internas; os canais de
relacionamento que estabelecem com o ambiente em que esto inseridas, com os Stakeholders
com os quais interagem e com as comunidades sociais que esto em seu entorno,,77.

Cartiter Ol1lt:m;t.llc;onlll

Caracterlsticas Geneticas tia OrgallizaiJo

Produtos
e Servios

Processo
Produtivos

Atribuies e
Responsabilidades

I
Prticas
Gerenciais

Relaes com
Stakeholders

Figura XI - Carter Organizacional

Considerando todos estes aspectos, constata-se que a mudana organizacional no poder ser
encarda como uma projeto isolado que ocorre esporadicamente no cotidiano organizacional.
Sendo to abrangente, profunda e multidimensional, a mudana necessita ser conceituada,
concebida e gerenciada como um processo de transformao contnuo. A transformao
organizacional, como um dos processos organizacionais, est diretamente relacionada
76 LA WER

I1I, E.E. et aI.. The Phenomenon ofLarge Scale Organizational Change. In Lawer III E.E. (org.) Large
Scale Organizational Change. San Francisco. CA. Jossey-Bass Inc. 1989.
77Mudana e Transformao Organizacional, Prof. Dra. Rosa Maria Fisher - Mudando os Paradigmas da
Mudana.

67

dinmica de funcionamento de uma organizao bem como s suas estratgias de ao. Ela
funciona como um processo contnuo de aprimoramento de seus sistemas, processos, polticas
e prticas de gesto, entre outros e deve ser gerenciada e modelada com instrumentos que
asseguram a sua intemalizao por todos os nveis e esferas da organizao.

2.3.2 O que Change Management

Com o aumento dos processos de mudana ocorridos nas empresas, a partir dos anos 90,
muito passou a se estudar sobre este tema. Da primeira onda de projetos que envolviam
mudanas de alguma forma, sejam essas mudanas de processos ou de sistemas, muito se
pode aprender sobre os erros e acertos desse processo.

De acordo com a equipe de consultores da PWC, o Change Management o processo de

gerenciamento da transio em qualquer tipo de projeto que envolva alguma forma de
mudana, objetivando reduzir resistncias e obter o maior comprometimento por parte dos
envolvidos de alguma maneira com essa mudana. A equipe de Change Management tem a
responsabilidade de captar dentro da organizao e da equipe de projeto, quais as percepes
dos seus membros quanto s mudanas tratadas pelo projeto. E durante todo o perodo do
projeto, implementar aes e atividades que tem como objetivo reduzir as barreiras desses
indivduos s mudanas propostas no decorrer do projeto.

Se a mudana for gerenciada, ela ser implementada com mais sucesso gerando menos
desespero nos envolvidos.

o Change Management aborda as seguintes atividades durante o projeto:

Identificar e gerenciar os Stakeholders;

Elaborar o Plano de Comunicao;

68

Transferir habilidades e conhecimento atravs da implementao do Plano de

Treinamento contemplando habilidades e conhecimentos tcnicos trazidos pelo projeto;

Dar apoio e suporte gerencia do projeto na identificao dos perfil dos recursos
necessrios para o projeto, na seleo desses mesmos recursos e na integrao da equipe
do projeto; e

Acompanhar a liderana do projeto durante o seu desenvolvimento.

2.3.2.1

Fator Mudana

Nem todas as mudanas provocadas pela implantao de um projeto so facilmente aceitas

pela organizao principalmente porque esses projetos alteraram a forma como cada indivduo
est acostumado a se relacionar com o seu trabalho e as suas rotinas dirias. Alterar esse status
quo, na maior parte das vezes, provoca fortes movimentos de resistncia mudana. Os
fatores so muitos mas podemos dizer que o medo das mudana, da perda que vir com ela,
so as principais razes que geram resistncia.
A equipe de Change Integration78 da Price Waterhouse 79 , elaborou um trabalho consolidando
uma srie de observaes relativas a experincias adquiridas durante a implantao de
projetos relacionadas ao processo de mudana enfrentado pelas organizaes nas quais
implantou, entre outros, sistemas de ERP. Como resultado desse trabalho, codificaram uma
srie de situaes que se repetiam em seus projetos e que valem a pena ser analisadas e
consideradas como material de anlise neste trabalho, sendo importante lev-las em
considerao quando se tiver interesse em garantir o sucesso de projetos de mudana como
por exemplo, um projeto de implementao de sistemas de ERP.

O primeiro deles diz respeito aceitao do fato de que as empresas nos dias de hoje no so
imutveis, a mudana uma constante e que o fato das organizaes estarem constantemente
buscando maior produtividade, faz com que internamente suas estruturas sejam

PRICE W ATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995.
79Antes da fuso com a Coopers & Lybrand

78 THE

69

freqentemente remodeladas e ajustadas s novas necessidades do negcio, modificando

assim processos e implantando novas ferramentas de trabalho e de gesto.

A preparao do terreno para a mudana se inicia buscando consenso dentro da organizao.

Normalmente este processo se inicia com a alta administrao e, em seguida, baixa-se para o
escalo inferior da companhia. Se a alta administrao der o exemplo com o seu
comprometimento com o projeto, obter o mesmo comprometimento das demais esferas da
organizao se toma uma tarefa mais fcil.

A mudana deve estar sustentada por uma gesto forte. A alta administrao dever estar
comprometida e profundamente envolvida nos projetos internos devendo dar apoio ao lder do
projeto fazendo ver ao resto da organizao o quanto este ou aquele projeto prioritrio e
quanto esforo as diversas reas da empresa devero concentrar nessa empreitada. Dever
procurar medir e melhorar o desempenho das reas mais importantes da organizao definindo
o escopo de atuao dessas reas pois a mudana trazida com o projeto, far com que seja
necessrio rever o atual sistema de avaliao de desempenho da organizao.

Dentro de toda organizao formam-se grupos de interesse, interesses esses que nem sempre
so compartilhados por todas as reas da organizao. Se esses grupos no estiverem
comprometidos com a mudana, podero representar um srio obstculo para o sucesso do
projeto. importante mapear o terreno identificando quem so esses grupos e quais os seus
motivos para apoiarem ou no o projeto para ento definir uma estratgia de ao sobre esses
grupos (mapeamento dos Stakeholders).

A organizao necessita no s concentrar esforos aonde o retomo for maior, bem como
precisa definir suas prioridades. No tentar implantar simultaneamente milhares de projetos
que afetam profundamente a organizao sob a pena de terem no s esses projetos mas
tambm a performance da organizao prejudicada.

Com a implantao, por exemplo, de um projeto de ERP, reas que antes pouco se
relacionavam entre si, passam a ser obrigadas a se comunicar pois os processos antes
executados individualmente, claramente passam a se interrelacionar fazendo com que cada

70

vez mais cada uma das reas da organizao dependam umas das outras. Portanto, a
capacidade que a organizao, seus altos executivos e seus multiplicadores tiverem para
aceitar a mudana, ser a chave do sucesso na implantao de um sistema de ERP nessa
organizao. Essa mudana precisa e deve ser gerenciada e para isso so estabelecidos
Projetos de Mudana. Se a organizao deixar o cliente (interno e externo) conduzir a
mudana, se eles perceberem que a mudana trazida pelo projeto vem ao encontro das suas
necessidades, eles sero os primeiros a conduzir a prpria mudana.

A comunicao feita organizao e queles envolvidos direta ou indiretamente com o

projeto fundamental para que o projeto d certo. Em um projeto de implantao de um
sistema de ERP por exemplo, a comunicao, medida que as mudanas ocorrem, deve ser
uma constante. As mudanas que surgem com os projetos alteram o status quo da empresa,
permitindo mostrar onde esto os velhos problemas e revelar aonde podem estar as novas
solues. Incentivar a equipe a pensar grande e a inovar, a externar suas idias importante.

Novas tecnologias e ferramentas de gesto requerem pessoas mais qualificadas para manuselas, tirando delas o maior proveito possvel portanto, investir no capital humano, desenvolver
habilidades nos recursos da organizao, em todos os nveis, principalmente daqueles que
esto na linha de frente do projeto, fundamental.

E acima de tudo, necessrio planejar a mudana detalhadamente atravs da elaborao de

um plano de ao detalhado, registrando as mudanas de processos, de sistemas, de pessoas e
necessidades de treinamento.

2.3.2.2

Um projeto de mudana e o processo de Change Management

o processo

de Change Management constitudo por uma srie de etapas comeando pela

identificao das necessidades de mudana. "Um projeto de mudana constitudo

basicamente por uma justificativa poderosamente persuasiva em favor das modificaes a que

71

se prope. Deve trazer consigo um senso de urgncia e deve estimular as pessoas a agirem"so.
Como por exemplo, em uma organizao, a identificao da necessidade da troca de sistemas
no integrados por sistemas de sistema de ERP como conseqncia da necessidade de
melhorar os processos da organizao ou melhorar a produtividade. Em seguida, necessrio
preparar o terreno para uma mudana dessa magnitude. Preparar a cabea da organizao e
faz-la ver que uma mudana como essa necessria. "Um terreno bem preparado para a
mudana apresenta uma proposta clara e persuasiva do direcionamento estratgico juntamente
com as medidas especficas de suporte"Sl. Em paralelo criao de uma equipe de projeto
para a implantao de um sistema de ERP, dever se criar uma equipe de Change
Management. Essa equipe ser responsvel pela gesto da mudana originada pelo projeto

dentro da organizao.

2.3.2.3

o apoio

Identificao dos Stakeholders

dos grupos de interesse (Stakeholders) o maior obstculo que se entrepe entre o

um projeto de mudana na teoria e o que efetivamente na prtica est sendo implementado.

Motivar pessoas para que defendam o projeto como se fosse delas, no uma tarefa fcil
principalmente em funo do nmero de pessoas envolvidas no projeto e, principalmente, se
houver um histrico de fracasso em projetos ocorridos anteriormente na organizao.
Identificar os Stakeholderi 2, seus desejos e necessidades uma atribuio da equipe de
Change Management e uma condio necessria para garantir o seu compromisso com

relao mudana trazida pelo projeto. Desta forma, na fase inicial do projeto, importante
identificar um conjunto inicial de pessoas envolvidas no projeto (os Stakeholders), procurando
compreender como elas percebem a mudana proposta pelo projeto. Esses Stakeholders
podem ser empregados, acionistas, diretores e gerentes, eles podem ser inclusive fornecedores
SOTHE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Better Change: Best Practices for
Transforrning your Organization. USA: Irwin Professional Publishing, 1995.
slIdem.
S2Stakeholder pode ser entendido como indivduo ou grupo que em algum momento durante o ciclo de mudana,
afetaro ou sero afetados pelo processo de mudana (estes podero ser entendidos como: empregados,
clientes, acionistas, fornecedores e outros parceiros de negcio) in THE PRICE WATERHOUSE CHANGE

72

e clientes. Ser importante identificar aqueles que apostam na mudana bem como aqueles
que sero mais ou menos afetados pela mudana, pois dependendo do grau que a mudana
proposta pelo projeto venha a afetar esses Stakeholders, eles tero uma postura positiva ou
negativa para com o projeto. A equipe da PWC sugere a utilizao da matriz abaixo para
mapear os Stakeholders. A lista de Stakeholders pode ser dividida em dois grandes grupos,
conforme ilustrado na Figura XII - Mapeamento do apoio dos Stakeholders com
referncia mudana pretendida, a seguir:

...... ..10_"__
p............

AlIo

Figura XII - Mapeamento do apoio dos Stakeholders com referncia mudana

pretendidas3
Em primeiro lugar, necessrio entender os objetivos e caractersticas dos Stakeholders.
Existem duas classes de Stakeholders. Aqueles que apoiam a mudana e os so motivados
pela mudana. Os primeiros, podero se transformar em agentes de mudana e iro buscar e
lutar por obter o compromisso de toda a organizao. Os segundos, expressaro suas
percepes negativas, ficaro distantes e tentaro minar os projetos. Existe ainda o grupo de
pessoas que j participou de projetos semelhantes, entretanto mal executados e mal sucedidos
e que se mostram contra os demais projetos. Essas pessoas precisaro ser trabalhadas,
preparadas para aceitas o projeto.

INTEGRA TION TEAM. Better Change: Best Practices for Transforming your Organization. USA: Irwin
Professional Publishing, 1995.
8\n THE PRICE WATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforrning your Organization)

73

Ser necessrio identificar cada um dos Stakeholders de acordo com o alto ou baixo impacto
em que as mudanas contempladas em um projeto o afetaro e o quanto se avalia que eles o
apoiaro quanto s mudanas pretendidas pelo projeto. Como base nesse mapeamento,
devero ser pensadas aes para trazer e comprometer esses Stakeholders com o projeto e
acompanhar os resultados e a evoluo dessas aes.

medida que o projeto avana, a equipe de projeto ir i~entificar as barreiras que

provavelmente iro interferir na velocidade e no andamento do projeto. O grau de esforo
necessrio para romper essas barreiras ser considervel. Quanto mais rpido se identificar
junto aos Stakeholders quais so essas barreiras, mais rapidamente o projeto ir para a frente.

Uma tcnica valorizada a de fazer presso contnua ignorando algumas dessas barreiras.
Entretanto, conveniente manter-se um certo limite poltico e de preferncia, com sustentao
do patrocinador, para no criar mais resistncias e barreiras na organizao. A melhor forma
de garantir o apoio envolver um executivo chave para cada processo envolvido no projeto de
forma a exercer influencia junto aos demais membros da organizao.

Para que tudo isso possa surtir resultados, "o gestor de um projeto de mudana dever
procurar estar assessorado por uma equipe altamente credenciada e respeitada dentro da
empresa, para que o acesso a esses grupos e sua influencia sobre eles possa ser considervel"s4

2.3.2.4

A comunicao

O processo de mudana deve ser difundido por toda a empresa. Desde a alta administrao at
o funcionrio de menor nvel hierrquico. Deve ser bem comunicado, com franqueza, atravs
de canais formais e informais, pois um empregado no modificar seu comportamento
enquanto a administrao no prometer honestamente melhorar a situao e comunicar
convincentemente que o projeto de mudana que est a caminho parte da soluo para esse
prprio indivduo. A credibilidade a base da comunicao eficiente devendo-se evitar a
84 THE PRICE WATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pg.73

74

disseminao de informaes enganosas, independente de interesses polticos ou operacionais,

sob o risco de denegrir a imagem e confiana no processo de comunicao do projeto. As
melhores mensagens so simples e diretas. " sensato avaliar o grau de confiana que os
interessados depositam nos patrocinadores e nos lderes executivos do projeto. Se a
credibilidade for baixa, a estratgia de comunicao deve ser mais voltada para o exemplo do
que para as palavras. As aes devem ser cuidadosamente selecionadas, visando sustentar a
mensagem que se pretende transmitir e demonstrar que a administrao age conforme prega.
Empregados precisam sentir confiana na administrao, porm, o exemplo e no as palavras
que a base de tudO.,,85

Nada de segredos. Na maior parte das vezes, os segredos resultam em comprometimento da

verdade e resultam na "diminuio do compromisso e da motivao do interessados".86 A
rdio corredor uma realidade e se no for bem administrada poder minar o projeto.
Entretanto, ser possvel se valer da radio corredor se atravs dela for transmitida a mensagem
do que a empresa est fazendo e o que pretende fazer. "Comunicao a sombra por trs de
tudo o que se faz no processo de transformao: no o primeiro elemento que existe na
mente de uma pessoa, mas no se pode ir a lugar nenhum sem ela. Comunicao
fundamental na produo da mudana.,,87

Um programa de comunicao bem formulado deve dirigir-se para as preocupaes das

pessoas envolvidas de alguma forma com o projeto, comunicar o progresso conseguido,
sustentando o entusiasmo das pessoas da equipe de projeto e da organizao. O programa
precisa transmitir uma mensagem clara, com contedo e que focalize a lgica da mudana.

THE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Betler Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pg. 98
86 "Um fabricante de video-games descobriu a futilidade de guardar segredos ao planejar demisses. A
administrao ameaou processar qualquer membro da equipe de planejamento que deixasse vazar qualquer
tipo de informao. Todas as reunies eram encerradas com uma sesso de destruio de papis, visando
minimizar a possibilidade de exposio acidental. Quando as demisses foram finalmente anunciadas, todos
ficaram boquiabertos aos saber que os empregados j sabiam de tudo havia muito tempo - incluindo detalhes,
como nome e quantidade de empregados a ser demitidos! No final, a administrao saiu perdendo por trs
motivos: causou estresse desnecessrio a seus membros, perdeu credibilidade junto fora de trabalho, que se
inteirou das notcias indiretamente, e qualquer beneficio relacionado oportunidade da divulgao foi
perdido." In THE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Better Change: Best
Practicesfor Transformingyour Organization. USA: Irwin Professional Publishing, 1995, Pg. 100
87 THE PRICE W ATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995.Pg. 94
85

75

importante entretanto, entender que "a eficincia da comunicao est intimamente

relacionada cultura organizacional de empresa.

88

Existem algumas qualidades para a elaborao de um plano de comunicao eficiente sendo

elas honestidade, apresentao do panorama geral juntamente com a relevncia do projeto
para a organizao, a adoo por parte da empresa de uma postura construtiva, a garantia de
uma consistncia verbal, escrita e de comportamento e a garantia da continuidade, reforando
constantemente o compromisso com a iniciativa de mudana.

2.3.2.5

A formao da equipe e o Change Management

A contribuio da equipe de Change Management na formao da equipe de projeto est

relacionada com o acompanhamento da definio da estrutura do projeto, da formao do
comit gestor do projeto e no monitoramento constante do cliente dentro do comit.

Adicionalmente, ela apoia o gestor na definio do perfil dos recursos necessrios para a
equipe, procurando-os dentro da prpria organizao, com aderncia ao perfil definido, com o
conhecimento tcnico ou do negcio necessrios para participar da equipe de projeto, pela
durao deste. Ela ajudar tambm a definir a quantidade de recursos necessria.

Em seguida, a equipe de Change Management coordena o processo de integrao dos

membros selecionados equipe do projeto. Sua participao vai desde o convite

88

"quando uma grande fabricante de brinquedos decidiu introduzir laptops para assistir a fora de vendas no
desenvolvimento de pedidos planejados, vendedores muito experientes acharam que a administrao estava
pretendendo alterar a sua maneira de trabalhar. Para se livrar da resistncia e da negatividade que
provavelmente surgiram, o presidente da empresa decidiu transformar a entrega dos laptops em um evento,
associando-o feira anual de brinquedos, a exposio mais importante do setor. Os vendedores ficaram
encantados com a demonstrao do sistema, A participao nessa demonstrao fez com que cada vendedor
recebesse um botton com os dizeres: EU VI FUNCIONANDO ! Os que concordaram em experimentar a
ferramenta nova e fazer a encomenda de uma unidade recebiam outro botton que dizia: ADOREI! Em muitos
outros ambientes essa abordagem poderia ter parecido banal, para essa fora de vendas em particular,
funcionou". In THE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Better Change: Best
Practicesfor Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pg. 99

76

confirmao da aderncia deste perfil s necessidade iniciais, continuando com os eventos de

integrao at o final do projeto.

Os eventos mais comuns realizados pela equipe de Change Management so o Kick OjJ, onde
a equipe participa do primeiro evento de integrao, bem como eventos de integrao
peridicos. Ela dever participar tambm da fase de encerramento fazendo o acompanhamento
do desligamento da equipe de projeto.

2.3.2.6

Outras consideraes sobre liderana e a formao da equipe de projeto

Embora estes temas j tenham sido bastante analisados em sees anteriores, aonde
analisamos detalhadamente cada um desses conceitos e revisamos a bibliografia existente
sobre o tema, complementamos sua anlise fazendo referencia a questes comentadas
especificamente pelos especialistas em Change Management da Price Waterhouse, como
resultado de sua anlise de projetos de mudana.

Em projetos de implantao de sistema de ERP, que envolvem uma grande mudana,

necessrio que os gestores possuam habilidades e experincia compatveis com a tarefa em
questo. "A habilidade poltica um requisito bsico, vindo em seguida uma certa
combinao de inteligncia, experincia, formao e pulso firme. Os lideres da mudana
escolhidos precisaro ser capazes de estudar as linhas de processo, ser profissionais com seu
foco bastante voltado para o cliente, ... , devero ser capazes de perceber problemas e
oportunidades de maneira singular. Respeitaro o fato de que as decises tomadas por eles
afetaro a sorte de toda a empresa mas sabem que esse impacto no dever impedi-los de
tomar tal deciso nem dever tom-los egocntricos" 89. Identificar, designar e conservar um
time de gerentes de primeira classe vital - mas no menos crtico do que a estrutura da
equipe do projeto em si.

89

THE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pg. 34.

77

Desta forma, a formao da equipe deve levar em considerao a qualidade e formao do

grupo de trabalho pois "a implantao de mudanas abrangentes requer combinao de
habilidades tcnicas, influencia interna, e estilos pessoais"90. Alm disso, necessrio pensar
que poder ser preciso mudar a equipe de trabalho ao longo do projeto, dependendo de
necessidades ou habilidades especficas que se faam necessrias. A prpria durao do
projeto faz com que por vezes a troca seja uma questo relevante visto que normalmente esses
projetos tem durao superior a 1 ano. comum a troca de membros da equipe de
implantao embora no seja recomendvel mudanas constantes uma vez que se perde um
pouco a continuidade do projeto.

Com relao composio dos membros da equipe, os especialistas da Price Waterhouse

comentam que ela poder contar tambm com membros internos da organizao desde que "a
maioria da equipe seja formada por indivduos respeitados na organizao. Consultores
podem ser teis, mas no devem dominar o grupO,,91. A consultoria trs a experincia
adquirida em outros projetos mas a equipe interna da organizao fundamental para garantir
a aceitao do projeto e das mudanas trazidas por este dentro da organizao. "Quando o
grupo formado inteiramente por pessoas de fora, os Stakeholders tendem a perceber a
mudana como algo imposto ao invs de uma iniciativa que brotou a partir dos conhecimentos
internos e das necessidades organizacionais - e nesse caso, esto pouco propensos aceit-Ia,,92.

A equipe formada por membros do cliente patrocinador do projeto dever ser logo posta a
trabalhar e, de preferncia, em um local novo, longe de seus antigos locais de trabalho e do
ambiente ao qual estavam acostumados. Isso fortalecer os laos da equipe, favorecendo o
processo de integrao entre os membros e diminuir o vnculo de lealdade com a
organizao, que normalmente durante o projeto tender a atrapalhar o andamento do trabalho
uma vez que essas pessoas no conseguem desvincular as necessidades do projeto dos
interesses da organizao. Essa distncia facilita o processo de implantao e estabelece o
foco nas necessidades do projeto.

Idem Pg. 165

THE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pg 169
92 THE PRICE WATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Idem. Pg. 35
90

91

78

Os membros da equipe tanto interna como externa93 , devero ser encorajados a pensar
abertamente e sugerir. Constantemente pensar "E se... ". importante dar a chance equipe
de projeto de propor inovaes de processos e de mtodos de trabalho entre outros.
Estabelecer metas de desempenho agressivas para a equipe de projeto possibilita melhores
resultados. As pessoas se sentem mais motivadas quando se vem diante de uma meta
desafiadora.

A equipe da Price Waterhouse prope uma estrutura de projeto ideal para a administrao de
projetos de mudana complexa e multifuncional e a chamou de "Estrutura de Equipe Peso
Pesado,,94, conforme demonstrada na Figura XIII - Estrutura de Equipe Peso Pesado, a

seguir:

Figura XIII - Estrutura da Equipe Peso Pesado 9S

Nela, o gerente de projeto " um profissional de nvel snior, um indivduo bem respeitado.
Essa pessoa liberada da estrutura funcional e se reporta diretamente ao responsvel pelo
projeto".96

Equipe externa considerada com a equipe de consultores externos.

Idem. Pg. 35
95 THE PRICE WATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Idem Pg. 170
93

94.

79

Outro aspecto importante na formao de equipes internas a delegao de poderes, ou seja,

"a criao de um ambiente em que os empregados da organizao, de todos os nveis, sintam
que exercem influncia verdadeira sobre os padres de qualidade e eficcia de negcios,
dentro de suas reas de responsabilidade,,97. Todos os empregados envolvidos no processo de
mudana que participam do projeto, tem poder para influenciar na qualidade dos produtos e
processos da organizao. Os membros da equipe necessitam ter este conceito claro dentro do
processo de Change Management. A delegao de poderes aos membros da equipe, por sua
vez, provoca mudanas de comportamento uma vez que o indivduo passa a se sentir
fortalecido pela responsabilidade que lhe foi atribuda.

2.3.2.7

Problemas mais comuns encontrados em um projeto de mudana

Todo projeto precisa ter uma vs de comando da mudana, ou seja, um lder, um responsvel
que tem a responsabilidade de integrar projeto e as mudanas e inseri-las na mente das
pessoas e da organizao. Se essa pessoa no estiver completamente envolvida e
comprometida, o sucesso do projeto poder estar comprometido. Essa vs de comando deve
possuir todo o suporte da alta administrao.

importante analisar tambm um outro aspecto, as pessoas tendem a encarar as mudanas em

nvel pessoal e por essa razo resistem ainda mais a elas. portanto necessrio, o mais rpido
possvel, comunic-las das vitrias ou beneficios que estas tero acesso como resultado das
mudanas propostas. Se elas conseguirem rapidamente visualizar esse ganho, deixaro de
constituir-se numa barreira resultando assim num grande ganho para o projeto.

A falta de definio de prioridades bem como fazer de tudo uma prioridade so causas que
levam um projeto ao fracasso bem como a existncia de projetos concorrentes como
Qualidade Total, Reengenharia entre outros, e a omisso da alta administrao em conciliar e
integrar projetos concorrentes entre si, poder levar ao desperdcio de recursos financeiros e
humanos bem como de tempo precioso da equipe e da organizao. "A energia e lealdade de
96
97

Idem Pg. 169

Idem Pg. 121

80

profissionais valiosos que competem uns com os outros, com o objetivo de manter sua rea de
influncia e/ou seus programas, constitu-se em um desperdcio. A destruio causada por
batalhas dessa natureza, pode ser to prejudicial que nenhum outro projeto atinge o resultado
pretendido,,98.

Um participante de uma conferncia realizada na Harvard Business School, sobre

"administrao de Negcios em Transformao" analisou que a prpria existncia de esforos
mltiplos uma problemtica para a empresa, muitas vezes eles so conflitantes entre si e
confusos alm de mal compreendidos pelos empregados. Neste caso, faz-se necessrio um
agente de mudana experiente para priorizar as metas, racionalizar atividades e tomar
decises, mesmo que essas decises sejam dificeis. "Deve-se trabalhar para garantir que os
melhores recursos sejam canalizados para os melhores projetos em prol da empresa como um
todo,,99 delegando responsabilidades aos demais lderes de projetos no s para que assumam
a liderana dentro do seu campo de domnio como tambm na misso mais ampla de integrar
esforos.

Adicionalmente, "a omisso em formar uma equipe talentosa e diversificada que represente
todos os interesses, a causa do fracasso de muitos projetos. Equipes eficientes na conduo
da mudana devem ser formadas por conhecidos inovadores e no pessoas comuns"IOO.
Devem ter diversidade de estilo e formao mas, acima de tudo, devem ter disposio para
cooperar. Treinar essa equipe, dedicar-lhe tempo e prepar-la para que esta assuma um papel
de integrador de esforo em seus projetos bem como em outros projetos que, por ventura,
possam estar em curso na organizao.

Obter o apoio de grupos de pessoas envolvidas de alguma forma com a mudana trazida pelo
projeto, um dos principais obstculos para o sucesso de um projeto. Os prprios
Stakeholders se desmotivam a determinada altura do projeto. Existem algumas ferramentas e

mtodos, que foram identificados e desenvolvidos no decorrer de projetos que procuram

98THE

PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pg. 39
99 idem Pg. 147
100 THE PRICE W ATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Idem Pg. 42

81

facilitar esse processo de motivao e o envolvimento dos Stakeholders. Um dos maIS

comuns, a formao de grupos de discusso. Eles faro com que os interessados contribuam
para o processo de mudana pessoalmente. Nesse momento ser possvel identificar mudanas
de postura em relao ao projeto ou seja, os pr-ativos podero se tomar medida que o
projeto avana, em reativos e vice versa.

Foi mencionado anteriormente o problema que surge quando os envolvidos assumem uma
postura pessoal em relao s mudanas. Nesse caso, uma das possveis solues
transformar o membro problemtico em um multiplicador, ou seja, atribuir-lhe a
responsabilidade por mais 3 ou 4 pessoas do grupo, com a responsabilidade de que ele se
relacione com eles e divulgue o projeto de mudana, pois os indivduos motivados, adotam
uma postura pr-ativa e geram um efeito multiplicador.

A pacincia outra ferramenta que deve estar presente em todos os projetos. Em um projeto
de mudana, necessrio dedicar tempo e ateno aos Stakeholders, eliminando neles os
possveis focos de ansiedade que podero surgir com o decorrer do projeto. Para evitar a
inrcia, importante manter sempre ativos os canais de comunicao. Manter as pessoas da
equipe e os multiplicadores envolvidos. Convid-los para se engajar em tarefas do projeto, em
aes que se faam necessrias durante o processo outra possibilidade. medida que um
projeto de mudana avana, as pessoas experimentam algo parecido com a dinmica da curva
de mudana. Essa curva apresenta 6 estgios pelos quais passa uma pessoa envolvida em um
processo de mudana. A primeira fase a da Pr Conscientizao, fase na qual surge a
sensao de que algo precisa ser feito mas no se sabe exatamente o qu. Em seguida, vem a
fase da Conscientizao onde se identifica que as mudanas so necessrias mas ainda no se
sabe como e aonde se quer chegar. A terceira fase, a da Preocupao Pessoal, a fase onde os
detalhes da mudana passam a ser conhecidos e quando surge a verdadeira preocupao:
"como que isto vai me afetar?" Em algum ponto entre o auto questionamento e a busca de
solues, comea o processo de aceitao. A quarta fase, a de Tentativa Mental, quando se
nota que as mudanas comeam a ser percebidas como inevitveis, quando se tenta imaginar
como a mudana pode funcionar a seu favor. A quinta fase, a das Mos Obra, a fase dos

82

pilotos. O ponto sem retomo surge entre esta e a fase seguinte, a sexta fase, onde ocorre a
Aceitao e o novo ambiente aceito e implantado"lOl. No incio, este processo requer um

esforo maior da equipe de projeto e da equipe de Change Management. "O verdadeiro

indicador de aceitao o momento em que as pessoas mudam o modo de realizar seus
trabalhos e os resultados mensurveis so atingidos,,102.

No caso da perda ou reduo do envolvimento e do interesse, por parte dos envolvidos no

projeto, durante a evoluo, o que pode ocorrer e normalmente ocorre em projeto de maior
durao que no se deve fingir que no houve uma queda no entusiasmo da organizao ou
da prpria equipe. importante trazer novamente o Stakeholder para dentro do processo,
envolvendo-o novamente nas atividades do projeto montando novamente grupos de discusso.

Nesse momento importante procurar saber o que os membros da equipe e da organizao

acham. A equipe da PWC sugere nesse caso que se crie um "terremoto" 103 , ou seja, que se
comunique algo na empresa que faa com que as pessoas acordem para a situao atual. As
atividades de Change Management em um projeto devem ser vistas como um investimento a
longo prazo pois o retomo dessas aes poder levar mais tempo do que o previsto para surtir
o resultado esperado no so resultados que possam facilmente ser percebidos no curtssimo
prazo.

101

102
103

THE PRICE WATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995.
Idem Pg. 86
Terremoto neste caso refere-se criao de um problema maior que procure abalar o status quo e trazer
novamente as pessoas realidade, fazendo com que elas "despertem" da situao anterior.

83

2.3.3 Consideraes sobre a Cultura Organizacional

Apesar do emprego de modernas tcnicas de gesto de projetos e todo o enfoque dado

questo da liderana, da formao de equipes e a questes relacionadas a Change
Management, temos observado que grande parte dos projetos de implantao de sistemas de

ERP, desde o seu boom na dcada de 90, no obtiveram o sucesso esperado.

Algumas das possveis razes para tal fato possam ser a m aplicao da metodologia, ou at
mesmo o fato das prprias organizaes no estarem ou no se terem preparado para a
mudana que tais implantaes trazem para os processos, polticas e as prticas de gesto da
Organizao como um todo. Ou at mesmo porque as consultorias contratadas para gerir o
projeto no tenham sido capazes gerenci-lo bem. Adicionalmente, observamos que o
processo de mudana envolvido em um projeto de implantao de um sistema de ERP nem
sempre leva em considerao algo to importante dentro de uma organizao como a sua
Cultura.

Transformar e modernizar uma organizao com a implantao de um sistema ERP, mesmo

utilizando as tcnicas do Project Management, no garante o sucesso dessa implantao se a
prpria organizao no encontrar o modo mais adequado de como mudar e o que mudar.
"Este como mudar, prprio das especificidades de cada organizao e do desejo de mudana
expresso em seus objetivos estratgicos. Por isso, o como mudar passa, necessariamente, pelo
desenvolvimento das pessoas, pela capacidade que elas tenham para compreender e
internalizar os valores da mudana, transformando-os em prticas organizacionais que
concretizem o desejo de transformao" 104. Organizaes mais reativas a processos de
transformao organizacional, tendem a dificultar e criar barreiras ao processo de implantao
de sistemas de ERP, influenciando diretamente no seu sucesso ou fracasso.

2.3.3.1

104

A Cultura de uma Organizao

Mudana e Transformao Organizacional, Prof. Dra. Rosa Maria Fisher - Mudando os Paradigmas da
Mudana.

84

Como definir Cultura? Poderamos dizer que Cultura um conjunto de refinados

comportamentos que as pessoas possuem em sociedade. De acordo com o antropologista E. B.
Taylor (1958), "Cultura inclui uma totalidade de conhecimentos, crenas, moral, leis,
costumes e outras capacidades e hbitos adquiridos pelos indivduos como membros de uma
sociedade,,105. Adaptando melhor esse conceito s organizaes, poderamos dizer que

Cultura a sinergia que se estabelece no compartilhamento de idias e crenas associadas

com o modo de vida de uma organizao. De acordo com Cleland (1999), Cultura
Organizacional consiste em acordos explcitos ou implcitos compartilhados pelos membros
dessa organizao, os quais so expressos em valores, crenas e padres bem como prticas
sociais e gerenciais. A Cultura desenvolvida, e que se toma caracterstica dessa organizao,
afeta o planejamento estratgico, sua implementao e consequentemente, a gesto de projetos
dentro da organizao. " possvel identificar aspectos Culturais comuns que influenciam
positiva ou negativamente a prtica gerencial e a conduo de questes tcnicas em uma
organizao, como por exemplo: o exemplo dado pelos seus lderes, as atitudes demonstradas

versus as praticadas, as competncias gerenciais e profissionais de seus recursos humanos, as

caractersticas percebidas a respeito da organizao, a qualidade e quantidade de recursos
disponveis para alcanar a misso, objetivos, metas e estratgias, os padres de comunicao,
os papis formais e informais, entre outros" .106

A Cultura Organizacional pode ser mudada de acordo com as modificaes estruturais que se
produzem na organizao. Ao estabelecer a sua misso, uma organizao procura refletir ou
at mesmo s vezes criar uma identidade. Essa identidade por sua vez se expressa atravs da
sua Cultura, sendo esta uma forma poderosa de se manter uma Empresa unida.

2.3.3.2

105

106

A Cultura e os Projetos

Trecho extrado de E.B. Taylor, The Origins of Culture (New York: Harper & Row, 1958) em CLALAND,
David I. Project Management. Strategc Desgn and Imp/ementaton. 3rd. Edition. Singapore: McGraw-Hill,
1999.
CLALAND, David I. Project Management. Strategc Desgn and Imp/ementaton. 3rd. Editon. Singapore:
McGraw-Hill,1999.

85

Projetos podem falhar ou ser bem sucedidos de acordo coma a Cultura de uma organizao.
quase impossvel implementar um projeto que no seja consistente com a Cultura da
organizao bem como ela tem um grande impacto no sucesso de qualquer coisa que a
organizao queira fazer, muito mais do que qualquer Best Practice gerencial possa dar jeito.
Tanto a Cultura da empresa como a Cultura de um projeto dentro de uma empresa, so
mutuamente interdependentes influenciando um ao outro, de acordo a fase do seu
desenvolvimento.

Cada projeto possui uma cultura distinta embora esta seja reflexo de uma cultura universal
encontrada em todos os projetos. Cleland (1999) relaciona uma srie de aspectos culturais
universais encontrados em quase todos os projetos. Segundo ele, alm da equipe de projeto
"possuir um propsito comum, que a entrega dos resultados esperados do projeto em termos
de cumprimento de prazos e oramento, de forma a garantir o alcance das estratgias
organizacionais estabelecidas, ela deve ser constituda e organizada como uma fora tarefa
orientada melhoria contnua e inovao dos processos organizacionais, produtos e servios
como forma de garantir a prpria sobrevivncia da organizao"I07.

Podemos dizer ento que ocorre uma mudana cultural na empresa toda a vez que foras de
mudana aparecem na organizao, foras que prope mudanas no seu status quo como por
exemplo, projetos de implantao de ERP ou projetos de reengenharia 108 os quais resultam em
reduo da estrutura organizacional bem como realinhamento de processos. O maior desafio
para o gerente de projetos, nestes casos, conseguir avaliar o quanto a mudana proposta em
cada um desses projetos ir afetar ou impactar a Cultura dessa organizao, facilitando dados

alta administrao para que esta possa prever as aes que iro contrabalanar esses
impactos

Adicionalmente, essas mudanas tambm iro afetar a equipe de projeto e, sendo assim,
tambm responsabilidade do gerente de projeto avaliar de que forma o projeto ir impactar a
107CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd Edition. Singapore:
McGraw-Hill, 1999.
108 Tradicionalmente, projetos de implantao de sistemas de ERP so precedidos ou so implementados em
paralelo com projetos de reengenharia de processos os quais preparam o terreno, atravs da reviso e
melhoria dos processos organizacionais, para a entrada do novo sistema de ERP.

86

prpria equipe do projeto. Em conjunto com especialistas e demais gerentes de projeto, poder
avaliar que tipo de orientao ser necessrio dar organizao (como por exemplo,
necessidades de treinamento) e prpria equipe de projeto para melhorar a adaptao s
conseqncias trazidas pelo projeto de implantao do sistema de ERP.

2.3.3.3

A Cultura das Equipes de Projeto

A equipe de projeto formada por um grupo de pessoas advindas de vrias reas de atividade
de uma organizao, com diferentes especialidades e experincias. No incio do projeto existe
em comum entre elas apenas o objetivo de criar algo que ainda no existe e dessa forma, a
equipe de projeto ir necessitar criar uma cultura prpria. A forma como os empregados da
empresa se associam entre si, por sua vez, poder influenciar a cultura da equipe de projeto.
Uma vez desenvolvida a cultura na equipe de projeto, esta os manter unidos. "A Cultura de
uma equipe de projeto um padro de interao social que surge do compartilhamento de
interesses, obrigaes mtuas, desafios, cooperao e amizades"I09. Para melhorar cada vez
mais a cultura da equipe de projeto, de acordo com Cleland (1999), o gerente de projeto
dever manter os membros da equipe regularmente informados sobre o status do projeto,
inclusive reportando as boas e a ms notcias, com uma certa regularidade. Precisar
promover a troca de idias, problemas, oportunidades e interesses entre os membros da
equipe, principalmente aqueles novatos no projeto, o que lhes d uma sensao de pertencer
quele grupo de trabalho desde o seu incio. Dever encorajar tambm atividades sociais como
almoos, coffee breaks e jantares entretanto, sem super envolver a equipe nessas atividades de
forma que elas no ultrapassem os limites do prprio projeto e comecem a interferir na vida
pessoal de cada membro. bom cultivar o uso dos primeiros nomes de cada membro da
equipe ou apelidos, reduzindo as formalidades no lidar com os membros da equipe.
109

CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd . Edition. Singapore:
McGraw-HiII, 1999.

87

o objetivo aqui manter a equipe motivada e razoavelmente feliz, permitindo que as pessoas
atinjam seus objetivos pessoais e aspiraes bem como os objetivos do projeto. Uma
caracterstica entretanto que Cleland (1999) ressalta como sendo uma questo chave para a
cultura de uma equipe de projeto a confiana, "a segurana que se sente em relao
habilidade, integridade e o carter das pessoas associadas com o projeto") lO. Essa confiana
no se d apenas entre os membros da equipe mas tambm entre a equipe e a alta gerncia

o desenvolvimento de uma Cultura na equipe,

ir facilitar no processo de "criar ideais que

ajudaro a guiar o comportamento do grupo"))) e "ajudar a alinhar objetivos e metas

individuais e organizacionais,,))2

2.3.3.4

Alguns impactos negativos da Cultura Organizacional em projetos

Freqentemente ocorrem casos onde seria melhor abandonar ou encerrar um projeto ao invs
de dar-lhe continuidade. Por exemplo, gerentes com histrias de sucesso que se recusam a
encerrar ou sugerir o encerramento ou abandono do projeto simplesmente porque esto
acostumados a vencer e simplesmente no conseguem aceitar a perda, investindo cada vez
mais tempo e recursos em projetos que esto fadados ao fracasso. Algumas das razes que
levam gerentes e/ou organizaes a darem continuidade a esses projetos esto relacionadas a
questes culturais presentes tanto na cultura preexistente das equipes de projeto ou na prpria
cultura da organizao. Em outras circunstncias, o projeto passa a se tomar parte da rotina da
organizao e esta no consegue d-lo por terminado ou desmobilizar a equipe envolvida no
projeto por que j se acostumou a ele.

Esses so exemplos em que a Cultura da empresa ou da equipe de projeto funcionam como

fator negativo na gerencia de projeto.
110

111

CLALAND, David I. Project Management. Strategic Design and Implementation. 3'd. Edition. Singapore:
McGraw-Hill, 1999.
M.R.LOUIS, "Organization as Cultural Bearing Milieux", em CLALAND, David I. Project Management.
Strategic Design and Implementation. 3rd. Edition. Singapore: McGraw-Hill, 1999.

88

112

R. HARlSSON, "Strategies for a New Age" in CLELAND (1999), David I. Project Management. Strategic

Design and Implementation. 3rd. Edition. Singapore: McGraw-Hill, 1999.

89

METODOLOGIA

3.1 Introduo

o objetivo deste captulo documentar o desenho e os mtodos da dissertao que serviram

de base para a elaborao desta pesquisa sobre Sistemas ERP - a metodologia de gesto de
projetos como fator determinante para o sucesso ou o fracasso na implantao de sistemas de
ERP, a partir de uma anlise comparativa entre dois projetos de implantao de sistemas de
ERP.

Para a realizao dos objetivos propostos nesta pesquisa, utilizou-se um mtodo estruturado
em duas etapas. De acordo com a classificao proposta por Vergara (1998), esta pesquisa
pode ser classificada, quanto aos fins em:

a) Pesquisa descritiva, pois este estudo pretende expor caractersticas de projetos de

implantao de sistemas de ERP, estabelecendo uma correlao entre as caractersticas
semelhantes existentes nesses projetos atravs da observao das tcnicas de Project
Management, utilizadas nesses projetos de implantao de software ERP, que

contriburam para o sucesso de sua implantao. E ainda, procurar mostrar a

correlao dessas tcnicas com as demais variveis analisadas neste estudo.
b) Pesquisa explicativa, pois visa esclarecer quais os fatores que contriburam, de alguma
forma, para o sucesso ou fracasso de projetos de implantao de sistemas de ERP.
Como por exemplo, de que forma as tcnicas de Project Management utilizadas e as
demais variveis analisadas contribuem, de alguma forma, para o sucesso ou fracasso
da implementao de projetos.

Quanto aos meios de investigao, a pesquisa pode ser classificada como pesquisa
bibliogrfica e estudo de caso.

A escolha da pesquisa bibliogrfica teve como objetivo levantar as contribuies atuais sobre
a metodologia de Project Management, Gesto de Pessoas, Gesto da Mudana, Liderana e

90

Cultura Organizacional, entre outros, a projetos em geral bem como aos projetos de
implantao de sistemas de ERP.
Dentro da abordagem da pesquisa qualitativa, so utilizados os estudos de caso, onde, a partir
de fontes internas e levantamento feito in loco, so apresentadas informaes aprofundadas
sobre as empresas participantes da amostra.

Segundo YIN (1994), para estudos de caso so especialmente importantes cinco componentes
de um projeto de pesquisa:

i)

questes para um estudo, quando so necessrias respostas a perguntas do tipo:

"Qual(is)", "Como" e "Por que";

ii)

suas suposies, se existirem;

iii)

sua unidade de anlise;

iv)

a lgica que une as informaes s proposies; e

v)

o critrio para interpretar os resultados.

YIN (1994) argumenta que o estudo de caso, apesar da sua ampla divulgao e utilizao na
comunidade cientfica, apresenta uma srie de limitaes, como a possibilidade de introduo
de vis por parte do pesquisador, no haver tratamento estatstico na amostra a ser estruturada,
alm de no ser possvel a generalizao dos resultados obtidos.

3.2 Universo e Amostra

O universo da pesquisa so dois projetos onde ocorreu a implantao de sistemas de ERP. As

empresas selecionadas so classificadas doravante de A e B. A empresa A, do setor de
telecomunicaes, teve seu sistema de ERP implantado em 1999 enquanto na empresa B, uma
empresa do ramo de papel e celulose, o sistema de ERP foi implantado em 1997. Essas duas
empresas foram escolhidas para o presente estudo em funo do critrio de acessibilidade e
pelo fato de seus projetos de implantao terem apresentado caractersticas relevantes para o
estudo em questo.

91

3.3 Seleo dos Sujeitos

Os sujeitos da pesquisa foram consultores e membros da equipe de projeto diretamente

envolvidos nos projetos de implantao do sistema de ERP nas empresas.

3.4 Coleta de Dados

O procedimento adotado para a coleta de dados foi:

a. pesquisa bibliogrfica em livros, artigos, teses, dissertaes, internet e peridicos

especializados; e
b. entrevistas focadas nos temas propostos, atravs da aplicao de um questionrio contendo
perguntas estruturadas e no estruturada e abertas para que os participantes dos projetos
selecionados pudessem manifestar a sua opinio a respeito dos temas do estudo em
questo.

3.5 Tratamento dos Dados

As informaes coletadas atravs das entrevistas, foram tratadas, organizadas e ordenadas

para facilitar a anlise e interpretao dos dados. Em seguida, foram construdos estudos de
caso relativos a cada uma das implantaes nas empresa A e B que permitissem ao leitor deste
estudo entender as questes identificadas em cada um dos projetos de implantao de sistemas
de ERP analisados.

92

4 DESCRIO DOS CASOS

Este captulo contm informaes referentes s duas empresas selecionadas na pesquisa e

relata de que forma as questes tratadas neste estudo foram abordadas nos projetos de
implantao de sistemas de ERP das empresas A e B. Em cada um dos estudos de caso so
descritas caractersticas especficas de cada implantao e como foram abordadas nesses
projetos, questes do tipo: que motivos levaram a organizao a mudar e se a escolha da
seleo do sistema foi precedida por um levantamento tcnico da aderncia desse sistema s
necessidades da empresa. Aborda tambm consideraes sobre a cultura da organizao bem
como o processo de seleo das equipes, no s de consultores como tambm da equipe de
projeto interna da empresa e do seu treinamento. Aborda a questo da liderana no grupo
gestor do projeto e temas relacionados a Change Management como a Comunicao. Por fim,
so comentados os resultados alcanados nos projetos em questo.

Nossos entrevistados so pessoas que tiveram uma participao efetiva nos projetos em ambas
empresas assim como o autor deste estudo teve participao nesses projetos de implantao de
sistemas de ERP. Na empresa A, sua participao limitou-se a o papel de usurio final do
projeto, acompanhando o processo de implantao do sistema. Na empresa B, seu papel foi de
consultor de um dos mdulos implantados. Entretanto, sua participao no aconteceu at o
final do projeto tendo se limitado a apenas 30% do tempo inicial de sua durao.

Na empresa A, nossos entrevistados so um consultor interno da empresa, da rea de

Tecnologia ClT) e um gerente de projeto. A metodologia de coleta de dados foi atravs de uma
entrevista pessoal e gravada para ambos os entrevistados.

J na empresa B, nosso entrevistado foi o lder do mdulo de finanas da equipe interna da

empresa. A metodologia de coleta dos dados foi atravs do envio do questionrio Cem Anexo)
via Internet que o entrevistado respondeu por escrito tendo utilizado o mesmo meio de envio
em virtude da distncia e a pouca disponibilidade de tempo.

Ambas as entrevista ocorreram no ms de agosto de 2002.

93

4.1 EMPRESAA

4.1.1

Dados Gerais

A empresa, do ramo de telecomunicaes, possui filiais na Europa, Marrocos e Amrica

Latina e se encontra entre as primeiras companhias de telefonia celular no mundo, com
operaes em mais de 14 pases e que representam um mercado potencial de 514 milhes de
habitantes. Ao final de Setembro de 2002 ela contava com 33,4 milhes de clientes
gestionados em todo o mundo.
Ela presta uma completa gama de servios na rea de comunicaes que inclui desde telefonia
fixa transmisso de dados e outros servios de valor agregado bem como solues
corporativas, acesso a Internet, servios de CRM e contedo. Se considerarmos todas as suas
linhas de negcio e no apenas a de telefonia mvel, podemos dizer que esta possui mais de
80 milhes de clientes em todo o mundo. Seu nmero de empregados se situa em
aproximadamente 161,5 mil em todo o mundo.
No Brasil, a empresa se agrupa em 3 companhias em 5 estados. No decorrer do ano de 2001,
ela concentrou os seus esforos na expanso e modernizao das redes de telefonia mvel e no
desenvolvimento de mais servios de qualidade para seus clientes garantindo com isso um
crescimento de 5,6 milhes de cientes no final de 2001. Em 2002, seus esforos esto voltados
para um crescimento mais rentvel, baseado em aes de fidelizao de clientes e otimizao
de seus processos operacionais.

4.1.2

Histrico da Implantao

A empresa "A" iniciou o processo de implantao do seu sistema ERP em 1999. O sistema foi
implantado nas suas 3 unidades formadas por 5 empresas espalhadas por todo territrio
nacional. Ela implantou os mdulo de materiais, vendas, controladoria, finanas e projetos. A

94

empresa de Consultoria contratada para a implantao foi a Arthur Andersen que utilizou a
metodologia de implantao de sistemas e gesto de projetos ASAP. A implantao durou
aproximadamente 7 meses tendo entrado em produo em Janeiro de 2000. A arquitetura
bsica do sistema envolve 3 mquinas independentes, uma para cada unidade regional, que
fisicamente se encontram localizadas no Rio de Janeiro. A rea de desenvolvimento,
responsvel pela manuteno do aplicativo bem como dos novos desenvolvimento tambm se
encontra fisicamente localizado no Rio de Janeiro.

A utilizao de uma metodologia de gesto de projetos dentro da empresa fato recente (com
incio no final de 200 I), quando a empresa passou a treinar seus usurios chave, tanto de reas
funcionais como da rea de IT I13 , na metodologia PMI para ser aplicada a todos os projetos
em curso na organizao. Essa metodologia tambm dever ser aplicada ao projeto, que ser
iniciado em breve, de migrao da verso atualmente implantada do sistema de ERP para uma
verso mais recente.

No incio da implantao do sistema de ERP a empresa no tinha nenhuma diretriz especfica

para que fosse utilizada uma metodologia em particular, fato comum na poca com grande
parte das empresas que comeavam a implantar sistemas de ERP. Tendo identificado essa
carncia por parte das empresas e dado a complexidade da implantao de um sistema de
ERP, a empresa fornecedora desenvolveu uma metodologia que mostrava os caminhos mais
curtos 114 para se configurar o sistema. Ela funciona como um guia para se implantar as
funcionalidades bsicas do sistema, ou seja, as funcionalidades standard. Esta ferramenta no
se adapta a implantaes que requeiram desenvolvimentos e customizaes adicionais, mais
complexas. Portanto, a condio fundamental para utilizar essa metodologia e por prpria
recomendao da empresa fornecedora, que a empresa implante o standard do sistema de
ERP, no se distanciando muito do que lhe oferecido nos mdulos standard. Algo mais
especfico que seja necessrio desenvolver dever ser desenvolvido em linguagem de
programao prpria, sem que se altere muito o mdulo standard. Caso a empresa opte por

113IT - Infonnation Technology, tambm conhecido por TI - Tecnologia da Infonnao

114Com base em fonnulrios especficos, onde o usurio marcava as funcionalidades que desejava implantar, os
resultados mostravam o caminho dentro do sistema e o que precisava ser configurado para que essas
funcionalidades selecionadas pudessem ser utilizadas.

95

modificaes que alterem a verso standard, sem o prvio conhecimento e consentimento da

empresa fornecedora, esta deixa de garantir a qualidade e as funcionalidades do produto.

4.1.3

Os fatores da Mudana, a seleo do Produto e as mudanas que a implantao

do sistema exigiu da empresa

Se as empresas nos dias de hoje optassem por desenvolver seus prprios sistemas,
principalmente sistemas do porte de um sistema de ERP, demorariam muito tempo para o
fazer l15 e teriam um custo bastante elevado. Por sua vez, desenvolver sistemas independentes
implica na construo de interfaces entre eles para interlig-los e isto era justamente o que
existia antes do surgimento dos sistemas de ERP; era esse exatamente o cenrio do qual as
grandes e mdias empresas procuravam distanciar-se, no s pelo alto custo de sua
manuteno como pela falta de capacidade para incorporar todas as novas funcionalidades,
novas prticas de gesto, ou seja, as Best Practices l16 que sistemas integrados de ERP
fornecem automaticamente no prprio processo de atualizaes peridicas (upgrades) de
novas verses, includas nos pacotes.

risco de desenvolver internamente, por sua vez, levava a empresa a no ter garantia dos

prazos de desenvolvimento desse sistema, o que elevaria consideravelmente o custo de

desenvolvimento de um sistema desse porte. Alm disso, a manuteno desses sistemas
envolvia o emprego de um elevado nmero de funcionrios especficos para essa atividade, o
que tambm elevava os custos operacionais da empresa.

No caso da empresa em questo, os sistema existentes anteriormente no eram integrados, o

que obrigava a empresa a realizar muitos trabalhos manuais de digitao de dados, gerando
retrabalho e requerendo um elevado volume de mo de obra para seus trabalhos rotineiros. E

115Estima_se que o desenvolvimento de um aplicativo com as funcionalidades de um sistema de ERP demande

aproximadamente 5 anos para ser concludo.
116 Best Practices - Melhores Prticas

96

ainda, a situao anterior no garantia a qualidade e confiabilidade dos dados imputados nos
sistema legados 117

o sistema anterior atendia em parte s necessidades da empresa, pois ele havia sofrido uma
srie de adaptaes para atender s suas necessidades operacionais porm, dado ao volume
crescente de operaes da empresa, o custo de sua manuteno e a carncia de funcionalidades
especficas que atendessem s novas necessidades do negcio que foram surgindo, ele deixou
de atender empresa. Portanto, havia necessidade de substituir esse sistema.

o sistema escolhido para substituir o anterior foi considerado pelo entrevistado como uma boa
opo embora no tenham sido utilizadas na empresa todas as funcionalidades disponveis que
poderiam ser implementadas 118.

Para o entrevistado, o melhor ou pior uso de sistemas dessa natureza ocorre de acordo com o
treinamento ou com o interesse que a organizao desperta por esse sistema. Aproveitando o
prprio momento do projeto, a empresa aproveitou para rever seus processos, selecionar seus
melhores recursos com o perfil mais adequado para manusear esse sistema bem como passou
a investir mais na sua qualificao. Desta forma, pde tirar mais proveito do sistema de ERP
implementado.

Conforme nos comentou o entrevistado, os fatores levados em considerao para a seleo

desse sistema foram o fato do sistema em questo j ser um sistema corporativo, ou seja, ele
era o aplicativo selecionado como diretriz corporativa, j tendo sido previamente comparado a
outras solues diferentes pela rea de sistema da holding internacional.

Entretanto, houve um estudo tcnico das qualidades do sistema em dois momentos, o

primeiro, quando este foi definido como soluo corporativa para o grupo e, posteriormente
no Brasil, nas Fases I e 11 do projeto local, onde se analisaram as qualidades do sistema em

117
118

Sistemas legados so considerados os sistema que existiam previamente implantao do novo sistema.
Por exemplo, o mdulo de controladoria no foi como completamente utilizado.

97

relao s necessidades da empresa e se fez um Gap Analysis JJ9 Tambm foram consultadas
empresas que j fossem usurias desse sistema, bem como foram feitas visitas a essas
empresas, j usurias do sistema, para poder avaliar o seu desempenho, alm dos responsveis
pela implantao terem participado de congressos e debates com outras empresas com
processos de implantao e caractersticas semelhantes, para comparar e trocar impresses a
respeito do produto e dos beneficios (ou no) desta soluo para os seus respectivos negcios.
Os pontos que geraram mais polmica na altura foram: a complexidade do sistema, o grau de
treinamento requerido para o manuseio do sistema pelos usurios, a qualidade do trabalho das
consultorias com pouca experincia para implantar o sistema que, na ocasio, era muito
questionvel, a prpria metodologia de formao da equipe de projeto era uma questo que
preocupava a organizao e as empresas consultadas. Todo esforo necessrio para
programao adicional ao mdulo standard do sistema, a subsequente necessidade de
manuteno e, principalmente, os projetos deveriam estar restritos ao mdulo standard do
sistema. Para selecionar o sistema em questo, tambm foram feitas apresentaes de
demonstrao pelo fornecedor e pela consultoria que iria implantar o sistema.

Ao ser questionado sobre a existncia de um estudo/levantamento prvio, suficientemente

profundo e abrangente, relativo aos requisitos funcionais do sistema e sua aderncia s
necessidades operacionais da organizao, o entrevistado comentou que na prtica, este tipo
de estudo acaba por ser esquecido, uma vez que a estratgia comercial do fornecedor apela
para o fato de que o sistema que a empresa est adquirindo j ser um sistema testado e
utilizado por uma srie de empresas em todo o mundo, e que ele carrega em si todos os
desenvolvimentos adicionais feitos para essas empresas bem como j contempla as melhores
prticas de negcio. Sendo assim, essa apresentao acaba por dispensar, de certo modo, uma
anlise mais profunda dos requisitos funcionais do sistema. Alm disso, ele acaba
direcionando a implantao para a adoo de sua prpria metodologia, a qual refora a idia
de que no o sistema que dever se moldar s necessidades da empresa e sim a empresa que
dever rever os seus processos para se adequar ao sistema que, em si mesmo, j trs o que h
de melhor em termos de prticas gerenciais, tendo sido testado e aprovado por vrias das
maiores e melhores organizaes em todo o mundo.
119

Anlise comparativa entre as necessidades da empresa e do negcio e as funcionalidades disponveis no

sistema de ERP.

98

Questionado sobre a realizao de um levantamento prvio dos processos da empresa e da

necessidade de readequao desses processos ao novo sistema, o entrevistado comentou que
no caso da empresa em questo, por se tratar de uma empresa muito nova, seus processos
ainda no estavam completamente definidos. Portanto, uma srie de procedimentos novos
foram criados simultaneamente ao desenvolvimento do projeto, aproveitando-se inclusive as
prprias funcionalidades existentes na ferramenta bem como o fluxo de processos standard
disponvel no sistema, sem que houvesse a necessidade de se fazer uma grande reengenharia
de processos. Apenas em casos muito especficos a empresa necessitou rever alguns de seus
processos para se adaptar nova ferramenta.

4.1.4 A Influncia da Cultura da Empresa no Projeto, na Gerncia e na Equipe de

Projeto

Na opinio do entrevistado, ao ser questionado sobre o fato da empresa ter uma cultura
voltada para a promoo de mudanas, de estar costumada a estar na vanguarda de novos
processos de gesto, bem como na adoo de novas ferramentas tecnolgicas, sua opinio foi
de que, apesar de ser uma empresa de alta tecnologia, internamente ela no primava por estar
na vanguarda de novos processos de gesto nem na adoo de novas ferramentas tecnolgicas
focadas em questes gerenciais. Talvez por ser ainda uma empresa muito nova e de criao
muito recente e recm privatizada. Quando estatal, esta no recebia grandes investimentos por
parte do governo. Como empresa privatizada, poca, ainda no tinha havido tempo para a
alta administrao se atentar para essas questes administrativas. A iniciativa de se implantar
um sistema de ERP foi o incio do processo de busca por novas metodologias e modernas
ferramentas gerenciais. A escolha e execuo desse projeto foi resultado de um processo
natural de adequao da empresa no Brasil ao padro das demais empresas do grupo no
exterior.

Mas aos olhos dos funcionrios, internamente, a cultura da empresa fica mais caracterizada
como sendo mais reativa do que pr-ativa, no que diz respeito inovao.

99

Quanto aceitao das mudanas, por parte da organizao (funcionrios, gerentes e alta
administrao), a opinio do entrevistado de que em geral, em qualquer empresa, qualquer
processo de mudana como o que promovido pela implantao de um sistema de ERP,
sempre um pouco traumtico. Ao analisar as reaes de cada um desses grupos dentro da
empresa, o entrevistado nota que culturalmente a empresa reage negativamente mudana
num primeiro momento. O pensamento dos funcionrios da empresa, no incio do projeto, foi
de que eles iriam perder os seus empregos, o que criou uma barreira de resistncias contra o
prprio projeto. Mas com a continuidade do projeto, quando os funcionrios comearam a ver
que eles estavam tendo acesso e manuseando uma nova tecnologia de vanguarda como o
caso de sistema de ERP, percebiam que ao mesmo tempo elas tambm estavam se
qualificando e se valorizando como profissionais e essa resistncia com o tempo foi
desaparecendo.

No caso dos gerentes, o que se percebe que o medo est no fato de que o conhecimento que
eles haviam adquirido com os processos anteriores seria perdido pela entrada de uma nova
ferramenta. Dessa forma, a questo est mais voltada para o medo da perda do poder pela
perda do domnio da informao. A informao deixa de estar centralizada em apenas uma
cabea. O sistema passa a dominar a informao como um todo e ela passa a estar disponvel e
a ser acessvel a mais pessoas dentro da organizao.
A prpria entrada de um sistema to "poderoso" como um sistema de ERP, exige por sua vez,
mais qualificaes do prprio gerente para poder lidar no s com a nova ferramenta como
com as dificuldades e angstias que, no incio, surgem dentro da sua equipe. Isto para ele
tambm acaba sendo um grande desafio e, de cara, faz com que ele resista mudana. Mas a
tendncia que com o tempo, essa resistncia desaparea. J para a alta administrao, a
mudana foi vista com bons olhos. Questionado sobre se a alta administrao fomenta na
organizao mudanas de processos e mtodos de trabalho, o entrevistado respondeu que no,
que ela no se envolve muito com o operacional. Entretanto, neste projeto, verificou-se que
apenas o Sponsor do projeto, devido s suas caractersticas pessoais, acabou tendo uma
participao mais detalhista e no a alta administrao como um todo.

100

Perguntado se a organizao (alta administrao, funcionrios e gerentes) busca e prope

mudanas como melhorias de processos, novas metodologias e ferramentas de trabalho, o
entrevistado respondeu que no existe a cultura de todos os setores e departamentos da
empresa proporem, generalizadamente, mudanas, a no ser a existncia de aes isoladas de
uma ou outra diretoria e no da organizao como um todo. E at mesmo essas pequenas
mudanas no so bem aproveitadas como base para mudanas maiores. Uma das falhas, na
sua opinio, que faz falta que um usurio se dedique especificamente a identificar
constantemente oportunidades de mudana nos processos de negcio e de gesto no sistema.
Uma pessoa que esteja fora das rotinas operacionais dirias, que possa se ocupar
exclusivamente da busca e identificao de oportunidades de melhoria atravs de propostas de
pequenas ou grandes mudanas, sejam de procedimentos sejam de ferramentas de trabalho.

4.1.5 A metodologia de Formao da Equipe de Trabalho

A equipe de projeto na empresa foi formada por membros das reas funcionais e da rea de IT
da prpria empresa e por uma equipe de consultores com as seguintes caractersticas:
especialistas em IT, especialistas em programao, especialistas em processos e um
especialista em Change Management.

A equipe formada para o projeto de implantao do sistema de ERP apresentou caractersticas

peculiares, distintas dos demais projetos empresa. Na empresa, de forma geral, os projetos
envolvem apenas usurios da rea de IT. No caso da implantao do sistema de ERP, por
iniciativa da prpria gerente geral do projeto e da recomendao do prprio fornecedor do
sistema de ERP que fossem envolvidos usurios das reas funcionais, pois se entendeu ser
impossvel que em um projeto desse porte, a empresa fosse cumprir o cronograma quando o
projeto em si envolvia uma sria de mudanas que impactavam direta e profundamente as
rotinas dos usurios de reas funcionais sem que eles mesmos tivessem uma participao
direta e efetiva no projeto. Ainda hoje, a empresa no possui a cultura de montar equipes

101

multi funcionais como essa em todos os seus projetos, o que o entrevistado lamenta, em funo
dos benefcios obtidos.

Com relao escolha da Equipe de consultores, ao ser questionado sobre os fatores que
foram levados em considerao para a seleo da equipe que participou e/ou conduziu o
processo de implantao do sistema de ERP, o entrevistado respondeu que foi devido ao
relacionamento preexistente entre a Consultoria e a Organizao. A consultoria selecionada j
era, na poca, a consultoria da empresa em todo o mundo.

Em relao qualidade e preparao da equipe de consultores ou staff, comentou que de

praxe solicitar o currculo dos consultores que sero alocados ao projeto e com base nele,
analisar sua experincia anterior, por quantos projetos j passaram, em que reas atuaram e
principais atividades executadas. Mas que na prtica, isso acaba sendo muito difcil de
acontecer, pois normalmente a consultoria mistura, em uma mesma equipe, recursos mais
experientes com outros menos experientes para que estes possam aprender e treinar durante o
prprio projeto. No ocorreu nada diferente no projeto em questo. Quanto gerencia, o nvel
foi considerado razovel.

Com relao ao fato da consultoria possuir experincia anterior em outros projetos de

implantao de sistemas de ERP, nos foi dito que sim, que j tinham implantado o sistema em
outras empresas, entretanto, em segmentos de atividades distintos.

Quanto equipe formada por membros internos da empresas, foi comentado que houve a
preocupao em se reunir uma pessoa de cada rea funcional da empresa para cada um dos
mdulos a serem implantados (eram 5 empresas em 3 regies operacionais) e mais uma
pessoa de IT l2o .

120

Particularidade da Empresa A - a rea de informtica, dentro da Empresa e dentro da estrutura de

desenvolvimento de projetos, desempenha ainda hoje um papel de integrador das 3 empresas, principalmente
no que diz respeito aos novos desenvolvimento e melhorias ou customizaes que tm sido necessrio fazer
aps a implantao do sistema, uma vez que os usurio das reas funcionais das trs empresas no tem a
cultura de se comunicarem previamente para discutir um processo nico ou uma soluo nica a ser
implantada que venha a atender simultaneamente s 3 empresas. Isto ocorre na Empresa A porque dentro da
rea de informtica existe uma equipe especfica cuja responsabilidade dar apoio rea usuria nas
melhorias e modificaes que se faam necessrias na ferramenta. Se essa estrutura desaparecesse, e pelo fato

102

A negociao dos recursos foi feita diretamente pelo gerente do projeto com os gerentes e
diretores das reas funcionais. Mas em alguns casos, notou-se uma certa resistncia e medo
por parte da pessoa selecionada em participar do projeto. A razo identificada era o medo que
ela tinha, a incerteza do que iria ocorrer quando terminasse o projeto e ela tivesse que retomar
rea de origem aps o trmino do projeto. O que iria acontecer com ela?

Com relao contribuio dada pela participao de membros de reas funcionais na equipe
de projeto, a opinio do entrevistado foi que essa participao contribuiu positivamente para o
sucesso do projeto. Mesmo que ele (recurso indicado, oriundo da rea funcional) no tenha
sido a pessoa mais indicada para participar do projeto, porque nem sempre possvel trazer
para a equipe do projeto a pessoa mais indicada, com certeza ela pde contribuir para o
projeto, dando mais confiabilidade ao que estava sendo proposto e implementado. A
credibilidade decorre do fato de que a empresa, na figura de seus empregados, percebe que
uma pessoa que depois de participar do projeto e que estar manuseando o prprio sistema,
sendo ele futuramente o prprio usurio desse sistema, no poderia estar propondo
modificaes ou processos inviveis de serem operacionalizados.

Com relao ao processo de seleo dos membros da equipe internos organizao, este foi
feito pelo responsvel da rea usuria. As pessoas selecionadas deveriam ser pessoas
experientes e conhecedoras do trabalho despenhado na rea e que normalmente acabavam
sendo escolhido(s) o(s) melhor(es) funcionrio(s) dessa rea, devendo ter qualificaes acima
da mdia para assim poder contribuir positivamente com o projeto. Desta forma os
responsveis mostravam resistncia em liberar o funcionrio uma vez que eles sabiam que
iriam perder um recurso especializado. Por sua vez, como temiam tambm que aps o trmino
do projeto no poderiam mais contar com aquele recurso, inicialmente demonstraram
resistncia em ceder o funcionrio.

de existirem 5 empresas e 3 mquinas diferentes, se perderia o controle das modificaes feitas no sistema
como um todo.

103

A comunicao da sada desses membros das reas funcionais equipe em que eles estavam
inseridos foi realizada diretamente pelo Sponsor do projeto. Houve o apoio da equipe de rea
de Recursos Humanos da Organizao nesse momento pois havia demasiada insegurana
relativa, principalmente, ao retomo s reas de trabalho ao trmino do projeto e perspectivas
futuras de existirem outras atividades ou no para eles ao trmino do projeto. Surgiram
tambm questes como a equiparao salarial com toda a equipe de projeto, uma vez que
haviam diferenas substanciais entre os salrios dos recursos de informtica e das reas
funcionais envolvidas. O entrevistado manifestou sua opinio quanto importncia da
participao ativa de rea de Recursos Humanos da Organizao nesse processo e da definio
de um plano de ao comunicando equipe de projeto como sero os procedimentos de
movimentao dos recursos humanos durante o projeto, entendendo tambm que no caso de
persistirem as dvidas dentro da organizao, seria interessante a realizao de um workshop
especfico para debater os temas com todos os envolvidos, no deixando que permaneam
dvidas a respeito do tema, no decorrer do projeto. J a aceitao pelos demais membros do
grupo, da sada dessa pessoa para a equipe do projeto provocou, em algumas reas, frustrao
para os que ficaram.

Questionado quanto ao processo de integrao entre a equipe de projeto da empresa e a equipe

de projeto da consultoria, o entrevistado nos respondeu que houve apenas um evento de Kick

Oi!'21 no incio do projeto, coordenado pela equipe de Change Management, onde durante
uma tarde, fora das instalaes da empresa, mais especificamente num salo de um hotel,
ocorreu um encontro de apresentao das equipes e nada mais.

Com relao existncia de equipes mistas, o entrevistado da opinio que, de uma forma
geral, o resultado positivo, pois a existncia de um consultor externo, que trs consigo a
experincia de outros projetos, adicionada experincia da equipe de TI, que possui um
conhecimento no s dos sistemas da empresa como o seu negcio, assim como os usurios
das reas funcionais (que tem a responsabilidade de passar para os consultores as suas

121

Kick-Of! - Como chamado o evento de lanamento do projeto, ou seja, quando se d oficialmente o incio
do projeto.

104

necessidades, que sero transmitidas para os novos processos a serem implantados com a nova
ferramenta), agrega bastante valor ao projeto de implantao do sistema de ERP.

Com relao existncia de conflitos, o entrevistado foi questionado quanto aos tipos de
conflito que ocorrem no projeto pela existncia de equipes mistas. Sua resposta foi que ao
longo do projeto ocorreram conflitos. Sempre ocorrem conflitos, como por exemplo, ser
solicitado pela equipe ou gerente de projeto da empresa, a substituio de consultores que no
esto agregando valor ao projeto. O conflito tambm surge da cobrana, por parte da
consultoria, aos membros da equipe funcional da empresa (no tanto da equipe de IT da
empresa pois estes j possuem por natureza um sentido de autonomia em funo das
caractersticas de seu trabalho) quanto ao cumprimento das tarefas do cronograma. Essa
cobrana, por sua vez, decorrncia da necessidade que a consultoria tem de cumprir prazos e
manter o projeto dentro do custo previsto.

comum ocorrer tambm, por parte da equipe funcional da empresa, uma sensao de
dependncia futura em relao prpria consultoria pois, em virtude do volume de atividades
que ocorrem no projeto, nem sempre a equipe funcional da empresa consegue estar atenta e
acompanhar tudo o que a consultoria faz. E um dia, a consultoria ir embora e quem ficar
para dar manuteno e continuidade no manuseio do sistema ser a equipe de projeto da
empresa.

J com relao ao fato da existncia de conflitos de interesses pela existncia de equipes

mistas, o entrevistado de opinio que com certeza esse conflito existe. Normalmente os
membros da equipe das rea funcionais da empresa bem como os membro TI, esto muito
preocupados com a qualidade e os detalhes do que est sendo parametrizado e planejado
enquanto os consultores esto mais preocupados em fazer uma implantao bsica e rpida
para atender ao cronograma e a viabilidade financeira do projeto. Nem sempre esses objetivos
coincidem, o que gera conflitos. Embora o objetivo comum a todos eles seja concluir de forma
satisfatria do projeto, cumprindo os objetivos propostos inicialmente pelo projeto, os
caminhos a serem trilhados para se alcanarem esses objetivos nem sempre so os mesmos
para cada um dos membros da equipe.

105

Em relao forma como foram administrados os conflitos, o entrevistado nos comentou que
na maioria das vezes esses conflitos foram resolvidos internamente na equipe contando no
mximo com o apoio do lder do mdulo, no sendo necessrio envolver o gerente. Ele nos
disse que o que se acaba percebendo que nesse momento, cada grupo recorre ao seu lder ou
gerente, ou seja, o grupo de pessoas da equipe funcional da empresa recorre ao responsvel da
empresa enquanto que o grupo da consultoria recorre ao lder ou gerente da consultoria. E
quando a equipe de Change Management chamada a interferir por fim, o acaba fazendo no
para buscar as causas ou as origens do problema mas sim, para dar a soluo final, a
substituio do causador do conflito. Ou seja, no se envolve muito na preveno dos
conflitos e sim, apenas em solues rpidas e imediatas.

Na opinio do entrevistado, o fato de existirem esses conflitos, se acaba sendo benfico ou

prejudicial ao projeto, ele entende que quando discutidos abertamente dentro da equipe, os
conflitos se mostraram benficos pois, aps serem solucionados pela prpria equipe, verificase uma melhora no relacionamento entre seus membros e no prprio andamento do projeto.
Mas quando no se encontra uma soluo para os conflitos, ele se mostra malfico pois vai
deteriorando o ambiente dentro do projeto e a soluo final acaba por ser a eliminao does)
causador(es) do conflito.

Mesmo assim, o entrevistado favorvel existncia de equipes mistas em todos os projetos

de implantao de sistema de ERP.
4.1.6

Os Gerentes de Projeto e a Liderana

Gerentes de Projeto Externos

A equipe de gerentes externos era composta por 3 gerentes sendo um deles operacional,
participando full time do projeto e com responsabilidades mais operacionais dentro deste. O
segundo era responsvel pelas atividades comerciais do projeto ou seja, acompanhamento das
necessidades adicionais de recursos e seu subsequente faturamento, responsvel pela
identificao de oportunidades de venda de projetos adicionais e complementares ao projeto

106

principal, etc. O terceiro gerente tinha a responsabilidade das atividades de Change

Management porm, no tinha participao full time no projeto, apenas quando necessrio.

Os trabalhos eram distribudos entre a equipe de gerentes da seguinte maneira: a gerente mais
experiente da empresa tinha como responsabilidade participar dos Comits Executivos do
Projeto bem como participava de algumas atividades operacionais do projeto. O gerente mais

jovem tinha as responsabilidades operacionais do projeto, tinha uma participao full time
sendo ele tambm o canal de comunicao com os Comits Executivos.

Entretanto, devido enorme carga de trabalho, todas as equipes possuam lderes que eram
chefes do projeto em seu mdulo especfico, o que apoiava bastante aos gerentes nas
atividades operacionais e dirias do projeto.

A formao da Equipe de Projeto descrita na Figura XIV - Equipe do Projeto de ERP da

empresa A, a seguir:

107

Nivel de Deciso

I
Nivel de Coordenao

~entes da Equipe
da Empresa

Nivel de Execuo

Figura XIV - Equipe do Projeto de ERP da empresa A

Analise do Perfil da gerencia da equipe de consultores

Quando questionado sobre a capacidade do gerente da consultoria se relacionar com a sua

equipe, o entrevistado respondeu que era "razovel". Ficou claro para ele que a gerncia da
consultoria somente exerce algum tipo de influncia sobre a sua prpria equipe enquanto que,
por sua vez, a equipe da empresa apenas responde gerncia da prpria empresa, no
aceitando muito bem a liderana do gerente de consultoria. J em relao ao relacionamento
do gerente da equipe da consultoria com a mdia gerncia da empresa (seus contrapartes), ele
mencionou que no havia um bom relacionamento, pois constantemente se observavam
reclamaes de ambas as partes. Em resumo, haviam atritos. Com a alta administrao da
empresa, devido ao relacionamento prvio da consultoria e com a organizao, nunca foi

108

observado nenhum problema, caraterizando-se assim um bom relacionamento entre a gerencia

do projeto e a alta administrao da empresa.

Entretanto, com relao s suas habilidades e conhecimentos tcnicos a respeito do projeto

que estava sendo implantado, o entrevistado comentou que o gerente da equipe de consultores
possua mais experincia tcnica do que necessariamente habilidades gerenciais para
administrar o projeto como um todo. Quando ocorriam dificuldades como, por exemplo,
pequenas alteraes no cronograma que no impactavam no conjunto do projeto, as mesmas
terminavam por ser tratadas diretamente pela equipe. Apenas os grandes atrasos identificados
eram apresentados ao gerente, o que fazia com que ele no se envolvesse muito no dia a dia
do projeto. Quando ocorriam crises entre as equipes da empresa e os consultores, ele tambm
pouco se envolvia pois os problemas acabavam sendo resolvidos dentro do prprio grupo.

Ele tambm no era uma pessoa carismtica para sua prpria equipe assim como para a
empresa, embora demonstrasse interesse e comprometimento com os objetivos do projeto.
Quando queria conseguir que as tarefas fossem executadas, tendia a usar a negociao, mas s
vezes era realmente necessrio usar a fora e o poder que tinha como gerente para que as
tarefas fossem cumpridas.

Ele costumava delegar responsabilidades aos demais membros da equipe, mesmo porque num
projeto desse porte, na opinio do entrevistado, era impossvel no se delegar
responsabilidades, pois o gerente acabava por no ser capaz de dar conta de todas as
atividades e obrigao para com o projeto.

o gerente da equipe de consultores, embora com pouca freqncia, negociava metas e prazos
para o projeto com os demais membros das equipes multifuncionais.

As necessidades de treinamento foram identificadas no incio do projeto e foram ministradas.

Ao ser questionado sobre o fato do gerente premiar os resultados obtidos, o entrevistado

respondeu que este no o fazia, bem como no estava atento s necessidades e problemas
pessoais de sua equipe.

109

Com relao aos canais de comunicao, o nico canal formal estabelecido pela gerncia da
consultoria era com sua prpria equipe e com o gerente da equipe da empresa. Problemas
rotineiros identificados na equipe acabam sendo tratados ou delegado pelo prprio gerente aos
seus subordinados para que os resolvessem entre si, o que gerava desconforto para a prpria
equipe que se sentia meio desamparada pelo gerente para resolver os conflitos no projeto.

Analise do Perfil da gerncia de equipe da empresa

Ao ser questionado se ela demonstrava que o sucesso do projeto que ela coordenava garantiria
o seu prprio sucesso e ascenso na organizao, o entrevistado respondeu positivamente.
Como haviam dois gerentes, um mais experiente e outro mais iniciante, aquele iniciante
conseguia visualizar os frutos que poderia colher de um bom trabalho realizado no projeto, o
que acabou acontecendo. Quanto ao gerente mais experiente, portanto com menos
expectativas de desenvolvimento de carreira, tal fato no impediu que tambm se dedicasse
com a mesma garra ao projeto. Eles escutavam as necessidades da equipe e, sempre que
possvel, tentavam atender.

Entretanto, com relao ao reconhecimento e agradecimento pelos resultados obtidos pela

equipe e sua respectiva premiao e recompensas, eles eram muito frios. A premiao era
muito rara.

Ao ser questionado sobre o desenvolvimento, durante o projeto, de uma rede de

relacionamentos com as demais reas da empresa ou para conseguir atingir os objetivos ou
completar tarefas exigidas pelo projeto, o entrevistado respondeu que sim, que foram criadas
redes de relacionamento. Sem esse bom relacionamento, algumas tarefas simplesmente no
aconteciam, principalmente no momento de se obter o comprometimento e a colaborao das
reas funcionais da empresa.

Adicionalmente, comentou que durante o projeto criou-se um canal de comunicao com a

equipe e demais gerentes do projeto embora esses canais no tenham sido utilizados na

110

soluo de conflitos. Eles tambm acabavam delegando para a equipe algumas tarefas que se
entendia serem deles prprios, constrangendo os membros da equipe e deixando-os em uma
dificil posio frente aos outros membros da equipe da consultoria e s vezes da prpria rea
funcional. s vezes, repassavam ao membro de sua equipe a responsabilidade de cobrar pelo
andamento de certas tarefas, cobrana essa que cabia a eles fazerem como gerentes de projeto.
Entretanto, eram geis na tomada de decises. Estavam sempre atentos s necessidades do
projeto, demonstrando interesse e comprometimento com os objetivos gerais do mesmo.

Quando surgia um problema na equipe, no conseguiam identificar rapidamente uma soluo

e implant-la. Dessa forma, se observou a formao de pequenos grupos dentro das equipes.
Havia o grupo da equipe dos consultores e o grupo da equipe da empresa. Eventuais 'broncas'
eram dadas pelos respectivos gerentes a suas equipes enquanto que cada vez que era
necessrio se discutir algum problema, eram os gerentes da consultoria e da empresa que se
falavam entre si e dessa conversa, cada um deles saa para transmitir o resultado das reunies
para suas equipes. Ou seja, no havia muita integrao entre as equipes de consultoria e da
empresa.

Como observado na equipe de gerentes dos consultores, a equipe de gerentes da empresa

tambm no premiava os resultados alcanados pela sua equipe.

Analise do perfil da alta administrao

Quando questionamos ao entrevistado se a alta administrao conseguiu transmitir equipe a

importncia do projeto para a estratgia escolhida pela organizao, ele mencionou que
durante o projeto houve pouca comunicao entre a alta administrao, Sponsor e
Stakeholders do projeto, com a equipe funcional. O dilogo era limitado aos gerentes do

projeto, tanto por parte da consultoria quanto por parte da organizao e como mantinha
contato apenas com a gerncia do projeto, no demonstrava muita preocupao
especificamente com as necessidades da equipe.

111

Entretanto, a alta administrao defendia o projeto junto s demais reas da empresa afetadas
por este. Fez algumas visitas a outras empresas usurias do sistema bem como, durante o
projeto, desenvolveu com estas uma rede de relacionamentos para obter beneficios para o
projeto.

A alta administrao era tambm muito cobrada por mais recursos, por parte da gerncia de
projeto, e quando era chamada a resolver questes especficas, atendia com prontido sendo
bastante eficaz. Assim como os gerentes da equipe de consultores e da prpria empresa, no
agradecia nem premiava ou recompensava os esforos e os resultados obtidos pela equipe.

4.1.7 O processo de Change Management

A Comunicao

No projeto da Empresa "A", a comunicao ficou a cargo da equipe de Change Management

que, adicionalmente, se envolveu tambm em questes ligadas a treinamento.

Quando questionado sobre a forma como as novidades em geral eram comunicadas na

organizao, o entrevistado comentou que na sua opinio, elas tardavam um pouco e quando
acontecia eram utilizados canais como Intranet, Jornal Interno, etc.

Em relao ao projeto, ele comentou que a comunicao da aquisio de um novo sistema foi
feita atravs dos canais tradicionais da empresa e que no foi feito muito alarde.

Quanto comunicao da formao da equipe de trabalho do projeto, comentou que esta foi
feita individualmente, de forma formal e fria, sem aproveitar a ocasio para envolver e
comprometer a equipe no projeto como um todo, com os resultados esperados. Foi tambm
publicada a formao da equipe no jornal da empresa. Para comunicar o andamento do
projeto(em todas as suas fases), foi criado um site na Intranet onde eram divulgadas
constantemente as informaes relacionadas ao projeto bem como o andamento do mesmo,
tendo esses canais sido considerados eficientes.

112

A Integrao da Equipe

Como comentado anterionnente, a equipe de Change Management participou apenas do KickOff do projeto, no tendo participado do processo de reintegrao dos membros da equipe da
empresa s suas reas de origem.

o Treinamento
Ao ser questionado sobre a qualidade do treinamento recebido pela equipe funcional da
empresa para operar e parametrizar o sistema a ser implantado, o entrevistado respondeu que
este foi adequado. A equipe recebeu treinamento no apenas no prprio mdulo em que iria
trabalhar como tambm em outros mdulos e outras funcionalidades para que pudessem ter
uma viso geral do sistema e assim, propor solues integradas entre os demais mdulos.
Quanto aos demais funcionrios da empresa, estes receberam treinamento apenas no final do
projeto, quando nonnalmente ocorre a fase de treinamento de todos os usurios que iro
manusear o sistema especfico para as atividades.

Quando questionado se foi desenvolvido e implantado um processo de treinamento peridico

na empresa para os novos funcionrios ou se o treinamento era feito on the job por seus
demais colegas, o entrevistado nos contou que a empresa no implantou esse procedimento.
Nonnalmente os novos funcionrios recebem um treinamento ministrado pelos prprios
colegas. Eventualmente, treinamentos adicionais podem ser solicitados por um ou outro
gerente que identifique uma necessidade especifica, nonnalmente aps um processo de grande
turn over de funcionrios na rea. Nosso entrevistado entende que, como conseqncia, as

pessoas se acostumam a usar maio sistema e s vezes isso gera erros que tendem a se agravar
com o tempo. No caso, a empresa implantou um Help Desk para tirar dvidas e dar
atendimento imediato aos problemas mais emergenciais. O que se verifica que a falta de
treinamento das pessoas acaba sobrecarregando o trabalho desse Help Desk, que passa a no

113

mais ser consultado esporadicamente e sim, comea a ser fonte de consulta constante devido
carncia de treinamento dentro da prpria organizao.

4.1.8 A Finalizao do Projeto

Quanto ao acompanhamento, por parte do fornecedor e da consultoria de implantao durante

o incio da utilizao do software - Go Live, o entrevistado respondeu que sim, que houve
suporte no processo de Go Live . Neste momento, importantssimo o acompanhamento da
consultoria para garantir que os problema que possam por ventura ter passado desapercebidos
antes desse momento, possam ser corrigidos. O tempo que a consultoria permaneceu na
empresa aps Go Live foi considerado suficiente.

Foi tambm elaborado material e documentao adequados para administrar treinamento

organizao. Entretanto, esse material no freqentemente utilizado pela organizao.
Embora a equipe de IT, responsvel pela manuteno do sistema de ERP na empresa, tenha o
cuidado de constantemente estar atualizando o material de treinamento, o mesmo no
divulgado na organizao, ficando este guardado apenas para eventual consulta.

Com relao reintegrao desses membros, aps o trmino do projeto, equipe anterior, nos
foi dito que houve muita ansiedade, por parte dos participantes do projeto, quanto sua volta.
Mas de uma forma geral, no caso da empresa analisada, ao final do projeto acabam ocorrendo
diversas situaes com por exemplo:

a) Alguns membros da equipe foram recebidos novamente em suas reas de origem,

retomando s suas antigas funes s que agora, manuseando a nova ferramenta e
assumindo o papel de multiplicadores da nova tecnologia dentro de suas reas;
b) Outros foram promovidos e/ou transferidos para outras reas, expostos a novos
desafios profissionais;
c) Outros no quiseram retomar rea funcional. Preferiram continuar fazendo parte da
equipe de IT que passou a dar manuteno ao sistema e a implementar as melhorias
que se seguiram ao projeto original;

114

d) Outros no se adaptaram e foram dispensados logo aps o trmino do projeto ou meses

depois.

4.1.9

Os Resultados do Projeto

Escopo

Questionado quanto proposta inicial do projeto ter sido atendida, o entrevistado entende que
sim, que a proposta era de uma implantao rpida e simples, com as funcionalidades bsicas
que permitissem empresa dar continuidade s suas atividades sem impactar no seu dia a dia.
No foi prevista nenhuma grande customizao no projeto, pois o objetivo era que fosse
realizada uma implantao, num curto espao de tempo. E, dessa forma, os objetivos
comunicados no incio do projeto foram alcanados.

Quando perguntamos se tudo o que inicialmente foi previsto fazer foi feito ou se foi deixada
alguma parte para uma fase posterior, o entrevistado respondeu que, na verdade, como a
proposta inicial era se fazer apenas o bsico, os desenvolvimentos mais complexos e as
melhorias necessrias ocorreriam numa fase posterior. Normalmente, a implantao de um
sistema de ERP se divide em fases ou "ondas". No caso da empresa A, optou-se por fazer o
bsico e, com as manutenes subsequentes, foram-se incluindo as melhorias necessrias e os
desenvolvimentos adicionais l22 . Isso aconteceu porque no eram prioridades para o
funcionamento bsico da empresa a implementao de todas as funcionalidades do sistema
selecionado. Na opinio do entrevistado, tal procedimento no foi prejudicial (nem benfico)
ao projeto porque naquele momento no era indispensvel para o funcionamento bsico da
empresa a implantao de todas as funcionalidades disponveis no sistema. Alm do mais,
importante se limitar o escopo da implantao se no ela se toma interminvel.

122

Nas "ondas" seguintes podero ser includos mdulos como Anlise de Rentabilidade, Gesto de Caixa,
Recursos Humanos, etc.

115

Questionamos o entrevistado quanto ao fato das mudanas nos processos da empresa e no seu
prprio negcio terem continuado a exigir que fossem feitos desenvolvimentos contnuos no
sistema, posteriores ao encerramento, e o mesmo nos respondeu que sim.

Continuam havendo pequenos novos projetos como conseqncia do primeiro projeto. Foram
includas novas funcionalidades, foram adicionados e integrados outros mdulos, j que so
sempre identificadas necessidades de melhoria. Algo que se leva em considerao a prpria
necessidade que a empresa tem de se acostumar nova ferramenta e aos poucos, quando
aprende a manuse-la e j a domina melhor, passa-se a implementar novas funcionalidades.

Nos disse que as pessoas acabam ficando mais crticas e, conhecendo melhor o seu negcio,
elas passaram a exigir mais qualidade nos processos da empresa, propondo mais melhorias e
novos desenvolvimentos.

Neste momento a empresa se prepara para a migrao da verso implantada em 1999 para
uma mais recente, por orientao da prpria empresa fornecedora. Neste momento, as pessoas
esto mais vidas por mudanas maiores e por isso, preciso conter um pouco as expectativas
da empresa para no correr o risco de tornar o projeto to complexo dificultando a sua prpria
migrao no prazo previsto (dead line previsto para janeiro de 2003)

Prazo

Questionado quando ao cumprimento do prazo previsto para o projeto, nosso entrevistado

comentou que foi praticamente concludo no prazo. O prazo inicial era Novembro de 1999 e
foi concludo em Janeiro de 2000. Segundo ele, dado o tamanho do projeto, se poderia dizer
que o atraso foi pequeno.

Por menor que tenha sido, ocorreu em parte devido ao grande volume de coisas que se props
implantar no prazo inicialmente determinado. Isso fez com que a fase de testes, muito
importante para evitar que problemas ocorram na fase de produo, fosse subestimada, no
tendo sido suficiente para fazer todos os testes integrados, o que provocou o atraso no projeto.

116

Em resumo, todas as tarefas foram cumpridas, sendo o tempo requerido subestimado para
elas.

Custo

Quanto ao custo, o que se pode identificar que no foi cumprido, em funo de se ter
subestimado o custo dos equipamentos.

117

4.2 EMPRESA B

4.2.1

Dados Gerais

A Empresa B uma empresa brasileira do ramo de papel e celulose, que produz e

comercializa celulose de eucalipto branqueada e papel de imprimir e escrever. A empresa
oferece dois tipos de celulose ao mercado: standard e ECF (livre de cloro elementar). Os
papis produzidos pela empresa so de alta qualidade com elevadas alvura e opacidade.
Fabricados, desde julho de 2000, com colagem alcalina, so oferecidos em bobinas de
dimenses industriais (com gramatura desde 56 at 110 gramas por metro quadrado) ou
cortados em folhas (folio size).
A empresa atualmente possui aes negociadas na Bolsa de Valores de So Paulo e nos
Estados Unidos por intermdio de programa ADR nvel 1.
A organizao atenta para a qualidade dos produtos fabricados, em sintonia com o conceito de
desenvolvimento sustentvel, bem como os nveis de servio oferecidos so atestados pela
ampla aceitao e reputao em todos os mercados e o estabelecimento de relaes duradouras
com importantes clientes.
A organizao conhecida por algumas caractersticas que defende como por exemplo, a
produtividade florestal, a auto-suficincia em madeira, a gerao prpria de energia, a
proximidade dos plantios em relao fbrica (distncia mdia de 61 km), a aplicao de
modernas tecnologias e padres internacionais de gesto da qualidade e do meio ambiente ISO 9002 e ISO 14001, possuindo um centro de pesquisa e desenvolvimento, com servios
direcionados ao atendimento das necessidades dos seus clientes.

Sua unidade industrial, localizada no extremo sul do Estado da Bahia, produz celulose e papel
a partir da madeira do eucalipto, matria-prima obtida por meio de plantios prprios. Dos 130
mil hectares de sua rea total, 76 mil so reservados cultura do eucalipto, cujo plantio est
distribudo em reas descontnuas, em nove municpios, nos estados da Bahia e Esprito
Santo. As reas destinadas preservao de matas nativas e mananciais totalizam 46 mil

118

hectares. Seu compromisso com a preservao ambiental est presente desde a concepo do
projeto e tem sido reconhecido internacionalmente pelas certificaes e prmios conquistados,
desde 1995, quando tomou-se a primeira empresa do setor, no mundo, a obter a certificao
pela norma inglesa BS 7750 (Environmental Management System), mantendo tambm um
sistema integrado de gesto da qualidade, com certificao pelas normas ISO 9002 e ISO
14001.

A empresa tem especial ateno com seus recursos humanos e dentro de seus objetivos inclui
aes de desenvolvimento e capacitao de equipes, de melhoria contnua de seus processos e
da comunicao na organizao, buscando sempre ser uma empresa atrativa para se trabalhar.
Encontra-se em processo de definio de um modelo de competncias a ser aplicado a todos
os nveis hierrquicos da empresa. Possui programas de treinamento e desenvolvimento,
programas de MBA para os executivos bem como realizou em 2001 seu primeiro programa de
"trainees" tendo contado com a participao de 2.500 candidatos para 8 vagas disponveis.

4.2.2

Histrico da Implantao

A empresa B iniciou o processo de implantao do sistema ERP em Julho de 1997. Ela

implantou os mdulo de materiais, vendas, controladoria, financeiro, planejamento da
produo, planejamento de materiais e recursos humanos, exceo da folha de pagamento,
work flow e gerao de relatrios e informaes gerenciais A implantao durou
aproximadamente 18 meses, tendo entrado em produo em Maro de 1999, incluindo um
ms de suporte ps implantao. A verso implantada j havia sido "localizada" para as
necessidades brasileiras.

A empresa B no possua uma metodologia especfica para gerenciar o projeto de implantao

do sistema ERP. Sendo assim, contou com a experincia e o apoio metodolgico de uma
empresa de consultoria assim como, eventualmente, com o suporte metodolgico da prpria
empresa fornecedora. A metodologia utilizada foi a SAP Enable Reengineering da Ernst &
Young Consulting que se divide em 3 fases: Fase I - Planejamento e Levantamento da
Situao Atual, Fase 11 - Viso de Futuro (que contempla o Desenho e Modelagem da Viso

119

de Futuro) e a Fase

m - Implantao

e Acompanhamento (que contempla o Suporte Ps-

implantao).

A metodologia prev tambm a avaliao do risco do projeto, levando em considerao 5

tpicos. O primeiro deles refere-se extenso do projeto (cujo grau de risco calculado foi
66%), a experincia (cujo grau de risco calculado foi 64%), a tecnologia (cujo grau de risco
calculado foi 54%), a organizao do projeto (cujo grau de risco calculado foi 35%) e as
condies operacionais (cujo grau de risco calculado foi 40%). Na mdia, o projeto alcanou
um score de 49% de risco como um todo, sendo considerado um projeto de mdio risco.

O projeto previa tambm o treinamento para a equipe de projeto bem como para toda a
organizao que estaria manuseando a ferramenta. O treinamento era considerado um prrequisito para motivar os funcionrios no uso efetivo do novo sistema bem como na
transferncia de know-how.

Como premissas para o sucesso do projeto, era necessrio um bom planejamento do mesmo, a
clara definio das responsabilidade entre os membros da equipe de projeto bem como dos
gerentes, a clara priorizao das tarefas programadas no cronograma de implantao, bem
como era primordial que a equipe estivesse dedicada full-time ao projeto, no sendo aceitvel
o envolvimento da equipe de funcionrios chave com as atividade rotineiras da empresa.

A implantao teve como premissa a customizao ZERO, restringindo as necessidades de

customizao ao mnimo, permitido apenas as customizaes padro do sistema. Algo mais
especfico que fosse necessrio desenvolver deveria ser desenvolvido na prpria linguagem de
programao do sistema para que no se alterasse muito o mdulo standard. No caso das
empresas que compram o sistema optarem por modificaes que alterem o sistema standard,
sem o prvio conhecimento e consentimento da empresa fornecedora, esta deixa de garantir a
qualidade e funcionalidades do produto.

O projeto previa tambm, dentro das atividades de Change Management, um Plano de

Comunicao detalhado para garantir a fluidez da comunicao durante o projeto.

120

4.2.3 Os fatores da Mudana, a seleo do Produto e as mudanas que sua implantao

exigiu da empresa.

Ao ser questionado sobre os motivos que levaram a organizao a buscar um sistema de ERP,
o entrevistado nos contou que foi a busca pela integrao das informaes da empresa,
buscando-se eliminar o retrabalho e garantindo uma maior agilidade e confiabilidade aos
processos da organizao. Na organizao, no existia sistema semelhante anteriormente. Os
sistemas legado/ 23 eram independentes, alguns deles inclusive, contavam com interfaces
desenvolvidas para integr-los entre si. Esses sistemas, de acordo com o entrevistado, no
atendiam s necessidades da empresa, tanto que foram substitudos pelo novo sistema de ERP.

De acordo com o entrevistado, havia uma real necessidade de substituio do sistema anterior,
alguns sistemas j estavam muito 'retalhados' e necessitavam de uma reviso ou atualizao
de verso ou ainda no atendiam plenamente s necessidades dos usurios. O custo envolvido
nesse processo estimulava a empresa a partir para um produto mais moderno, reconhecido
pelo mercado e pela concorrncia como um sistema que atenderia melhor s necessidades da
organizao.

Quando questionado sobre o que achava da opo pelo sistema selecionado, ele acredita que
tenha sido uma boa escolha. Para a seleo desse sistema, o entrevistado nos contou que o
fator primordial levado em considerao foi a necessidade de integrao. Buscava-se a
simplificao de processos, que eliminassem o retrabalho existente dentro da organizao,
dando-lhe assim maior competitividade.

Com relao existncia de um estudo prvio das qualidades do sistema, o entrevistado nos
contou que inicialmente selecionaram-se alguns sistemas de ERP e por fim, optou-se por um
deles. Foram consultadas outras empresas usurias do sistema selecionado. Entretanto, de
acordo com o entrevistado, no segmento de negcio em questo (Papel e Celulose), j quase
todas as grandes organizaes concorrentes estavam optando pelo sistema de ERP em questo
123

Sistemas Legados so aqueles sistema que existiam previamente ao sistema que se est implantando.

121

como soluo tecnolgica portanto, suas opinies foram consideradas na hora de se optar pelo
sistema de ERP selecionado.

Entretanto, em ralao existncia de um estudo/levantamento suficientemente profundo e

abrangente dos requisitos funcionais do sistema e da sua aderncia s necessidades
operacionais da organizao, o entrevistado nos respondeu que no necessariamente houve
esse estudo. O que aconteceu que existia uma necessidade de mudana e a escolha do
sistema de ERP era uma condio para que essa mudana ocorresse j que esse ERP, no seu
bojo, trazia em si embutidas as melhores praticas de negcios em voga. Dessa forma, a
organizao estava preparada para se adaptar ao novo sistema e no ao contrrio. Entretanto,
foi feito um levantamento prvio dos processos em uso e da necessidade de readequao
desses processos ao novo sistema. Os processos em uso foram mapeados e, posteriormente,
foram redesenhados novos processos.

4.2.4 A Influncia da Cultura da Empresa no Projeto, na Gerncia e na Equipe de

Projeto

Na opinio do entrevistado, a empresa possui uma cultura de promover mudanas, e est

acostumada a estar na vanguarda de novos processos de gesto bem como na adoo de novas
ferramentas tecnolgicas. Na sua opinio, a empresa est sempre em processo de mudana,
buscando sempre o que h de melhor no mercado. A organizao procura envolver os
funcionrio nessas mudanas uma vez que eles so sempre chamados a participar das
mudanas. Desta forma, as mudanas so encaradas como uma coisa natural, til e necessria
dentro da organizao. A alta administrao fomenta na organizao mudanas de processos e
mtodos de trabalho assumindo um papel de patrocinadores em todas as questes de mudana
propostas pelos empregados. Por sua vez a organizao, na figura de seus funcionrios e
gerentes, aceita bem a implantao de novos procedimentos de trabalho e novas ferramentas
de trabalho, principalmente ferramentas tecnolgicas como as de ERP. Muitas dessas
mudanas partem dos prprios donos dos processo, ou seja, das prprias reas usurias. A
organizao busca e prope melhorias de processos, novas metodologias e ferramentas de
trabalho pois para ela a mudana vista como uma questo de sobrevivncia.

122

Mas ao ser questionado se os usurios se sentiram ameaados pela entrada do novo sistema, o
entrevistado nos contou que sim embora esse medo tenha acabado durante o projeto.

4.2.5 A metodologia de Formao da Equipe de Trabalho

A equipe de projeto foi formada por membros das rea funcionais e da rea de IT da prpria
empresa, conhecedores dos sistemas legados e dos processos de negcio da empresa. Esses
membros de IT tambm adquiriram habilidades, atravs de treinamentos especficos de
programao na linguagem prpria do sistema para dar-lhe suporte e manuteno. A equipe de
consultores contou com profissionais com as seguintes caractersticas: especialistas em
Processos e um especialista em Change Management. Pontualmente, era envolvido um ou
outro especialista em IT.

A equipe de Change Management teve uma formao diferenciada pois contou com vrios

membros de Recursos Humanos da empresa e com um consultor externo de RH, especializado

em temas como na integrao de equipes, contratado especialmente pela empresa para
participar do projeto nas atividades relacionadas a Change Management. A consultoria
tambm disponibilizou um recurso especializado em Recursos Humanos para a formao do
grupo de Change Management.

Com relao escolha da equipe de consultores, o entrevistado nos contou que os fatores que
foram levados em considerao na sua seleo foram a experincia prvia e a qualificao dos
profissionais da consultoria. O entrevistado considera a qualidade e preparao da equipe de
consultores um fator muito importante para o alcane dos objetivos iniciais do projeto, caso
contrrio ele pode se estender por muito tempo e cair em descrdito dentro da organizao.
Entretanto, preferiu no comentar a qualidade da equipe de projeto e da gerncia da empresa
de consultoria.

Com relao experincia que a empresa de consultoria possua em outros projetos de

implantao de sistemas de ERP, o entrevistado nos comentou que esta possua pouca

123

experincia porque na poca (em 1997), haviam poucos projetos implantados ou em processo
de implantao.

A seleo dos membros da equipe internos organizao ocorreu da seguinte maneira:

"escolhemos os melhores de cada rea e negociamos com os respectivos gestores a liberao
dos mesmos para o projeto. A comunicao de sua entrada na equipe foi feita com a
recomendao de que deveriam se dedicar exclusivamente a esse trabalho e que deveriam
mudar o que fosse necessrio mudar, focando sempre a simplificao e otimizao dos
processos". Uma vez comunicado que o mesmo participaria do projeto, suas atividades foram
repassadas para outras pessoas e ele se incorporou fisicamente, junto com os demais membros
da equipe, ao projeto para o incio dos trabalhos. O entrevistado acredita que o processo de
comunicao e a transio das pessoas equipe de projeto foi tranqilo e que dessa forma
tenha sido satisfatrio.

Com relao ao processo de aceitao pelos demais funcionrios das reas funcionais, da
sada dessa pessoa para a equipe do projeto, nos comentou que este foi tranqilo, mesmo
porque em algum momento os demais funcionrios iriam ser envolvidos no projeto e dariam a
sua parcela contribuio e ajuda para o projeto.

Em relao equipe de projeto de TI, na sua opinio, a participao de usurios da empresa na

equipe de projeto contribuiu positivamente para o alcance dos objetivos iniciais do projeto,
sem a presena deles, o entrevistado acredita que no se teria alcanado os objetivos
inicialmente proposto para o desenho e a implementao do sistema.

Na opinio do entrevistado, a existncia de equipes mistas bastante til, inclusive necessria

para a continuidade do processo ps implantao, atravs da identificao das melhorias nos
processos de negcio. Alm disso, com a existncia de uma equipe mista, permite que a
consultoria por um lado aporte ao projeto o conhecimento tcnico do sistema e por outro, a
equipe funcional da empresa aporte ao projeto o conhecimento do negcio. essa associao
que faz o sucesso do projeto. Na sua opinio, todos os projetos de implantao de ERP

124

deveriam contar com equipes mistas. Sem isso, no h como incorporar novas
funcionalidades, mesmo que a equipe interna tenha conhecimento do sistema e consiga fazer a
implantao sozinha.

Ele alerta entretanto, que importante levar em considerao que, para o desenvolvimento do
projeto, o primordial ter planejamento e acompanhar o cronograma e isso melhor
gerenciado por uma equipe de consultores externos com experincia em gesto de projetos.

Sobre se a existncia de equipes mistas gerar conflitos de interesses durante o projeto, na sua
opinio de que tal fato no deveria existir. Caso ocorra, a gerncia responsvel pelo projeto
deveria interferir para correo de rota do projeto. No caso do projeto em questo, ele nos
comentou que sempre que foi identificado um conflito e que houve necessidade de uma
interveno da equipe gestora, prevaleceu o bom senso. Em casos mais drsticos, a soluo foi
mudar as pessoas da equipe envolvidas no conflito.

Sobre a sua opinio quanto aos benefcios ou malefcios do surgimento de conflitos no

projeto, nos comentou que tais conflitos provocam sempre uma mudana no curso do projeto.
E as mudanas, sempre que necessrias, devem acontecer preservando sempre o objetivo
principal do projeto.

4.2.6

O Gerente de Projeto e a Liderana

A formao da Equipe de Projeto descrita na Figura XV - Equipe do Projeto de ERP da

empresa B, a seguir:

125

Nivel de Deciso

I
Nivel de Coordenao

~rentes de Equipe

da Empresa

Nivel de Execuo

Figura XV - Equipe do Projeto de ERP da empresa B

Analise do Perfil da gerencia da equipe de consultores

A diviso de trabalho e das tarefas entre a equipe de Coordenao o Comit Executivo da

equipe era a seguinte: o gerente interno cuidava das questes relacionadas a processos,
comunicao e o cumprimento do cronograma. Cuidava tambm para que a unidade da equipe
estivesse sempre preservada. O gerente da consultoria, por sua vez, atentava para as questes
tcnicas do sistema, resolvendo problemas como, por exemplo, a no aderncia do sistema s
necessidades da empresa - os gaps - e atividades ligadas ao controle geral do projeto.

O entrevistado comentou que o projeto envolvia a organizao como um todo e portanto,

havia a necessidade de se manter a comunicao com os demais membros da equipe sempre.

126

Entretanto, ocorre que o gerente de consultoria do projeto em questo vinha de uma outra
empresa, no tendo experincia prvia em consultoria e isso foi um pouco complicado se
relacionar com a equipe da empresa. Se no houver uma sintonia entre gerncia de projeto,
equipe e gestores das reas funcionais, o projeto perde sua importncia e deixa de existir
comprometimento por parte dos gestores como um todo. Dessa fonna, o gerente do projeto
tem que ser uma pessoa fortemente agregadora.

Com relao s suas habilidades e conhecimentos tcnicos a respeito do projeto que estava
sendo implantado, o entrevistado entende que ele sabia da importncia do projeto e tinha
conscincia de sua responsabilidade porm como era uma experincia nova para ele, o
andamento do projeto o colocava prova a todo instante.

Com relao sua capacidade de administrar as atividades inerentes ao projeto como

cronograma, recurso humanos e financeiros, crises entre os diversos membros da equipe e/ou
entre equipe de consultoria e da empresa, o entrevistado nos disse que de fonna geral, todas as
dificuldades inerentes ao projeto no tocante sua administrao foram solucionadas de
maneira coerente e com bastante participao dos patrocinadores, que eram os diretores da
organizao.

Para ele, na maioria das vezes, o gerente do projeto da consultoria era uma pessoa carismtica
para a equipe e para o cliente mas quando era obrigado a tomar decises, a situao mudava
de figura. Demonstrava interesse e comprometimento com os objetivos do projeto e
costumava delegar responsabilidades aos demais membros da equipe. Sempre que necessrio,
solicitava treinamento, embora os participantes de um projeto de implementao de ERP
estejam sempre sendo treinados pelo fato de estarem contribuindo para as mudanas na
organizao.

Com relao aos canais de comunicao, comentou que a comunicao no projeto se realizava
atravs de reunies especficas para tratar de questes relativas ao projeto. Nessas reunies, as
pessoas comunicavam suas dificuldades, apreenses e davam sugestes.

127

o gerente da equipe de consultores era gil na tomada de decises. Em um projeto, no se

pode demorar para tomar decises, o cronograma no pra, as coisas tm que ser decididas
rapidamente, independentemente da vontade da equipe. As decises relativas ao projeto
sempre eram tomadas em conjunto com o gerente da empresa e tinham que ser geis. Ao
identificar um obstculo ou problema, este negociava os novos rumos compartilhando as
decises com a equipe e os donos do processo.

Quando questionado quanto ao fato do gerente da equipe de consultores ter o hbito de

premiar os resultados obtidos, ele nos disse que no.

Analise do Perfil da gerncia da equipe da empresa

Ao ser questionado se ele demonstrava que o sucesso do projeto que ele coordenava garantiria
o seu prprio sucesso e ascenso na organizao, o entrevistado respondeu positivamente. Isso
era imprescindvel para o seu sucesso. A garra, motivao e empenho so fundamentais para a
carreira profissional.

Quanto a escutar as necessidades da equipe, nos disse que isso ocoma sempre que era
possvel, embora no auge do projeto as coisa tivessem ficado um pouco tumultuadas em
funo das tarefas terem que ser executadas em um curto espao de tempo. O agradecimento e
a premiao costumavam acontecer sempre que a equipe merecia. De uma maneira ou de
outra, acontecia o reconhecimento.

Sempre que necessrio, desenvolveu uma rede de relacionamentos com as demais reas da
empresa e com outras empresas para conseguir atingir os objetivos ou completar tarefas
exigidas pelo projeto. Criou um canal de comunicao com a equipe e demais gerentes do
projeto pois isso era fundamental, sem essa comunicao o projeto no atingiria seu objetivo.

128

Analise do Perfil da alta administrao

Quando o questionamos se a alta administrao conseguiu transmitir equipe a importncia

do projeto para a estratgia escolhida pela organizao, ele mencionou que sim. Alm disso,
tanto a equipe do projeto como o gerente tinham um canal aberto com a alta administrao.
Durante o projeto criou-se um canal de comunicao permanente com a equipe e gerentes do
projeto atravs da realizao de reunies peridicas para discutir-se assuntos relacionados
com o projeto.

A rede de relacionamentos com as demais rea da empresa ou outras empresas para conseguir
atingir os objetivos ou completar tarefas exigidas pelo projeto tambm foi sempre uma
constante por parte da alta administrao.

Poderamos dizer que o projeto contou com um grande patrocnio da alta administrao da
empresa. O seu apoio foi de suma importncia para o sucesso do projeto. Sem isso, ficaria
quase impossvel o comprometimento de todos dentro da organizao. Sempre que era
solicitada, a alta administrao era gil na tomada de decises

A alta administrao sempre demonstrava preocupao com as necessidades da equipe e dos

gerentes do projeto pois tinha o maior interesse de que tudo desse certo. Na medida do
possvel, lutava por mais recursos para o projeto.

Quanto a agradecer e premiar os esforos e os resultados obtidos pela equipe, nos disse que
isso pratica comum na organizao. As equipes so premiadas por resultados satisfatrios.

4.2.7 O processo de Change Management

Na Comunicao

129

De acordo com o entrevistado, a comunicao na empresa se d normalmente atravs do

jornal interno, por publicaes especficas e ou reunies entre empresa e funcionrio, e na sua
opinio, tem funcionado satisfatoriamente. Com relao ao projeto especificamente, a
comunicao da aquisio do novo sistema se deu primeiro atravs de uma reunio de
diretoria com os gerentes e em seguida a notcia foi repassada para a equipe.

Durante o andamento do projeto, em todas as suas fases, a comunicao ocorreu atravs de

um jornal interno especfico sobre o projeto ou atravs de reunies com as reas envolvidas.
Este canal foi considerado eficiente pelo entrevistado embora ele tenha sugerido outros como
a Intranet, a Internet e a participao da equipe em eventos corporativos.

o Treinamento
Sobre a qualidade do treinamento recebido pela equipe funcional para operar e parametrizar o
sistema a ser implantado o entrevistado comentou que, na sua opinio, os treinamentos
costumam ser ministrados esperando-se obter o melhor resultado para a equipe, mas nem
sempre acontecesse o melhor, ou seja, no tempo disponvel para os treinamentos da equipe
funcional nem sempre se conseguem os melhores resultados. s vezes, o membro da equipe
no consegue absorver todo o conhecimento necessrio para sozinho implantar o sistema. Por
isso, a equipe mista sempre bem vinda.

Quanto ao fato dos demais usurios, em todas as reas da organizao afetadas pela
implantao do ERP, terem sido treinados para manusear o novo software, o entrevistado nos
comentou que estes receberam treinamento porm sempre falta muito a aprender. Quando os
usurios se deparam com as rotinas do dia-a-dia que identificam que ainda h muito a
aprender. Por isso, importante treinar novamente a equipe aps alguns meses do sistema ter
entrado em produo. Porm, durante o projeto, foi elaborado material e documentao
adequados para administrar treinamento Organizao atravs de manuais de usurios, e esse
material freqentemente utilizado pela organizao.

130

Quanto ao desenvolvimento e implantao de um processo formal de treinamento peridico

na empresa, para os novos funcionrios, nosso entrevistado nos comentou que o treinamento
para novos usurios sempre ministrado pela prpria rea, ou seja, o seu treinamento feito

on the job por seus demais colegas. Questionado sobre o fato desse procedimento afetar a
qualidade do trabalho e a utilizao das funcionalidades do sistema, na sua opinio, o
entrevistado entende que s vezes prejudicial, por que essa forma de transmitir o
conhecimento carrega os vcios previamente existentes na rea. Mas o mesmo observa que na
prtica, na maioria das vezes, tem dado certo.

o entrevistado nos disse que houve um acompanhamento dos usurios e do sistema, aps a
implantao por parte da prpria empresa. Entretanto, em relao consultoria, como
estipulado em contrato quanto tempo ela ficar no perodo de ps-implantao, esta no
permaneceu dando suporte por muito mais tempo.

A Integrao

Durante todo o projeto, o entrevistado nos contou que para proporcionar a integrao entre a
equipe de projeto da empresa e da consultoria, foram ministrados diversos cursos internos e
eventos de integrao com todos os participantes.

4.2.8 A Finalizao do Projeto

Com relao volta dessas pessoas s suas funes rotineiras aps a concluso e
encerramento do projeto, o entrevistado nos contou que poucos voltaram s suas rotinas.
Alguns ficaram em TI e outros retomaram para as reas em funes diferentes, com olhos
voltados s melhorias que deveriam ocorrer aps o fim da primeira "onda" de mudanas
implementadas pelo projeto.

131

Segundo o entrevistado, agora essas pessoas possuam mais responsabilidade j que agora eles
tinham a misso de estar com os olhos voltados para a identificao de oportunidades de
melhorias contnuas dentro de suas respectivas reas.

4.2.9 Os resultados do Projeto

Escopo

Com relao proposta inicial do projeto ter sido atendida, o entrevistado entende que o
projeto atingiu aproximadamente 70% os resultados esperados. No deu tempo de fazer tudo o
que foi comunicado nem foi possvel implantar todas as funcionalidades do sistema. Foi
apenas possvel implantar o que havia sido comunicado em termos de funcionalidades.

Foi deixada alguma coisa para se fazer aps o projeto entrar em produo. Por exemplo, toda
a rea florestal foi postergada porque no era possvel postergar a entrada em operao.
Entretanto, ressaltou que as coisas que ficaram pendentes no prejudicaram a entrada do
sistema em operao. Na opinio do entrevistado, o atraso tambm aconteceu por que foram
identificadas novas oportunidades de melhoria, no decorrer do projeto, que eram impossveis
de ser implementadas no prazo determinado para a sua concluso. Ao ser questionado sobre
tal procedimento ter sido prejudicial ou benfico ao projeto, na sua opinio o projeto no foi
afetado pela no incluso de alguns processos.

Desde a concluso do projeto, continuam havendo vrios pequenos projetos pois aps a
implantao foram identificadas vrias oportunidades de melhoria, que foram implementadas
aps o incio da entrada em operao do sistema. Na opinio do entrevistado, isto ocorre
porque, na medida em que se conhece melhor as potencialidades do sistema, o escopo vai se
alterando. Porm, sua aplicabilidade acaba sendo postergada para uma fase posterior. No caso
da empresa B, foi isso que aconteceu.

132

Prazo

Quanto ao cumprimento do prazo previsto para o projeto, houve atraso de 2 meses. O atraso
ocorreu em primeiro lugar devido ao fato da equipe funcional e dos prprios consultores no
conhecerem suficientemente o sistema. Em segundo lugar devido pouca experincia da
equipe, tanto funcional como da de consultores, em projeto de implementao de sistemas de
ERP em empresas de grande porte na poca. Em terceiro lugar, o atraso tambm foi
influenciado pelas modificaes que foram ocorrendo no escopo do projeto.

133

5 ANLISE DAS INFORMAES COLETADAS

o escopo deste captulo analisar os dois casos descritos anteriormente tendo como base o
modelo proposto na reviso bibliogrfica. Objetiva-se fazer anlises comparativas entre as
duas empresas pesquisadas, buscando identificar semelhanas e diferenas de padro nas
implantaes de sistemas de ERP ocorridas nessas duas empresas.

Seguindo a linha de formatao da apresentao dos estudos de caso, a anlise destes dois
casos ser dar em seis partes, sendo a primeira, uma comparao entre o histrico da
implantao nas duas empresas. Em seguida, compararemos os fatores da mudana, a seleo
do produto e as mudanas que essa implantao exigiu da empresa, como a se deu a influncia
da cultura das empresas no projeto, na gerncia e na equipe de projeto, os aspectos da
metodologia utilizada por cada uma das empresas na formao das equipes de trabalho,
faremos uma comparao entre perfil dos gerente de projeto em cada uma delas, os conflitos e
os aspectos de liderana observados em cada uma das implantaes bem como faremos uma
anlise comparativa entre o perfil da alta administrao em cada uma delas. Como o processo
de Change Management, ou seja, o treinamento, a comunicao e a integrao das equipes foi
abordado em cada uma das empresas e por fim, os resultados obtidos pelo projeto, ou seja, o
processo de finalizao e os resultados obtidos em termos de escopo, prazos e custo.

5.1

Histrico da implantao nas duas empresas

Embora as duas empresas tenham optado pelo mesmo sistema, a empresa A optou pela
implantao de uma quantidade menor de funcionalidades - mdulos, do que a empresa B o
que, em termos de durao e riscos para o projeto, aumenta medida que aumentam as
funcionalidades selecionadas para essa implantao.

A poca na qual ocorreram essas implantaes tambm um diferencial que deve ser levado
em considerao uma vez que quanto mais cedo ocorriam as implantaes mais difcil era
dispor de recursos treinados e conhecedores das funcionalidades do sistema, o que elevava

134

consideravelmente o risco do projeto. Embora dois anos de diferena entre cada um dos
projetos possa parecer para os leigos pouco tempo, na prtica o que se observa que medida
que o tempo passava, e mais projetos no Brasil iam acontecendo, mais e mais pessoas
passavam a conhecer o produto, incluindo at mesmo o prprio fornecedor do sistema, e mais
curtos se tomavam os projetos subsequentes.

Da mesma forma, as verses utilizadas em cada uma das implantaes, incluam, dependendo
da poca, mais ou menos "Tropicalizaes,,124 e portanto, mais aderncia possua o produto s
necessidades da empresa e menos customizaes eram necessrias.

Poderamos dizer que o tempo de durao dos projetos analisados depende diretamente da
quantidades de funcionalidades ou mdulos do sistema implantados.

Outra concluso a que se pode chegar comparando os dois casos que as empresas no
possuam conhecimentos nem metodologias apropriadas para a implantao de um sistema to
amplo e complexo como esse e por isso, ambas necessitaram do apoio de uma empresa de
consultoria externa, com a metodologia, recursos e conhecimento necessrios para suportar o
projeto de implantao do sistema de ERP.

Ambas tiveram como premissa para essa implantao, customizao ZERO, condio
fundamental para reduzir os riscos e a complexidade do projeto.

5.2

Os fatores da mudana, a seleo do produto e as mudanas que essa implantao

exigiu da empresa

Embora os objetivos das duas empresas ao selecionar o sistema de ERP possam parecer
diferentes se comparadas as respostas dadas pelos entrevistados, por trs dessa seleo havia a

124

Tropicalizaes como ficam conhecidas as adaptaes necessrias ao produto original uma vez que o
sistema de ERP em questo, no teve sua origem no Brasil e adaptaes a questes tributrias e processos
especficos do Brasil, por exemplo, foram necessrios para que o produto melhor se adaptasse s
necessidades das empresas s quais era oferecido e vendido.

135

necessidade principal de se reduzir custos. A escolha desse sistema especificamente, envolve

tambm questes e desejos intangveis com por exemplo, a empresa B queria ter o mesmo
sistema utilizado por suas concorrentes enquanto a empresa A tinha esse sistema definido
como uma diretriz corporativa. Fato que o sistema em questo era o sistema mais vendido e
mais comercializado na poca, portanto o mais caro e de implantao mais cara, como
conseqncia do volume de recursos humanos envolvidos, da necessidade do suporte de
consultorias e dependendo das customizaes necessrias, o mais arriscado e mais demorado.

Os gaps identificados entre o sistema e as necessidades da empresa, em ambos os casos,

foram

resolvidos

com

customizaes

atravs

da

programao

de

interfaces

ou

desenvolvimento de aplicativos adicionais que substitussem ou complementassem as

necessidades adicionais da organizao, utilizando, como pr-condio, a mesma linguagem
de programao do sistema. Em ambos os casos, foram as empresas que se adaptaram ao
sistema e no o sistema que se adaptou s empresas.

5.3

Influncia da cultura das empresas no projeto, na gerncia e na equipe de projeto

Neste aspecto, podemos observar duas atitudes completamente distintas entre as duas
empresas analisadas. A empresa A no possui tradio e cultura voltada para a mudana, o
que parece estranho se formos pensar que esta uma empresa da rea de telecomunicaes,
segmento onde novos desenvolvimentos tecnolgico, que envolvem um elevado grau de
mudana, so uma constante e uma premissa para o seu core business.

J para a empresa B, a mudana fazia parte de sua cultura, do seu contexto. Ressalta-se o fato
de no s a equipe do projeto como todos os funcionrios da fabrica da Bahia possurem
histrias de motivao por terem aceitado o desafio de sair de So Paulo para estabelecer a
nova fbrica no interior da Bahia. So portanto pessoas motivadas e dispostas a inovar e a
aceitar as mudanas. E que no caso do projeto de implantao do sistema, estavam muito
motivadas com a possibilidade de mudana.

136

A empresa B no projeto em questo, delegou aos membros da equipe o poder para decidir e
mudar o que fosse necessrio para que se obtivessem os melhores resultados do projeto. Esta
delegao de responsabilidades os estimulou a buscar e a extrair os melhores resultados do
sistema de ERP e do projeto em si.

Entretanto, nem toda esta motivao na empresa B foi suficiente para que as pessoas
envolvidas no projeto no tivessem medo de perderem seus empregos ou suas funes dentro
da organizao aps a entrada em produo do novo sistema, como ocorreu na empresa A. Em
todos os casos, aps a entrada em produo dessa nova ferramenta, as pessoas, tanto
funcionrios quanto gerentes, acabaram por ver que, sendo ela inevitvel, eles tinham agora
pela frente o desafio de dominarem esse novo conhecimento. Pois dominar esse novo
conhecimento era a garantia tambm da sua permanncia na empresa e por isso, precisava
conhecer e desenvolver mais seus conhecimentos nessas novas funcionalidades, j que eles
no poderiam ficar para trs sob a pena de ficarem ultrapassados e de serem, futuramente,
substitudos pela prpria organizao. Neste momento, a equipe de Change Management tem
um papel fundamental no processo, reduzindo as expectativas das pessoas, montando um bom
plano de comunicao do projeto para a organizao.

No caso da alta administrao, em ambos os casos, percebemos que ela acaba tendo uma viso
mais estratgica do quanto a inovao, com a implantao do novo sistema, ser benfica para
a organizao como um todo e, por isso, ela fomenta a mudana. Entretanto foi comentado
pelo entrevistado na empresa A que s vezes a alta administrao no conseguiu visualizar os
impactos que a mudana proposta pelo sistema de ERP trazia para a empresa, como por
exemplo no caso da empresa A, o impacto que a implantao do mdulo de Vendas, pelo fato
deste estar integrado com a rea financeira, teria diretamente nas atividades da rea financeira
e ela, por sua vez, deveria estar preparada para a mudana e no estava.

A organizao naturalmente leva um certo tempo para se adaptar. O que acaba ocorrendo
que depois da primeira "onda" de mudanas trazidas pelo novo sistema, normal que em
projeto subsequentes sejam incorporadas novas funcionalidades mais especficas e complexas
que traro mais mudanas, num ciclo contnuo.

137

5.4

Aspectos da metodologia utilizada por cada uma das empresas na formao das
equipes de trabalho

Nos dois casos analisados, a equipe de projeto contou com membros internos da organizao
em cada equipe. Este procedimento difere de outros tipos de projeto, como comentado pelo
entrevistado na empresa A. Mas ambos entrevistados foram da opinio de que a existncia de
equipes mistas foi fundamental para os bons resultados obtidos pelos respectivos projetos.

Entretanto, na empresa A, pde-se reparar que houve mais resistncia, por parte dos gerentes
funcionais da empresa, em liberar recursos para o projeto, por medo de perder esses recursos
ou do desaparecimento de suas vagas.

Outro aspecto ressaltado pelo dois entrevistados, tanto na empresa A quanto na empresa B, foi
a volta rea de origem aps o trmino do projeto. Do ponto de vista daqueles que deixaram
suas reas para participar do projeto, foi identificado nos dois projetos, que houve por parte
dessas pessoas, medo de que ao trmino do projeto elas no mais tivessem condies de serem
recolocadas nas suas respectivas reas ou funes anteriores. E como pde ser observado,
houve pouca contribuio por parte da equipe de Change Management do projeto da empresa
A para reverter essa sensao nas pessoas que foram participar do projeto. O entrevistado da
empresa A deu exemplos inclusive de como essa volta acaba sendo um pouco traumtica,
dando com o exemplo algumas situaes como por exemplo, o medo de voltar equipe antiga
depois de tanto tempo, das piadas relacionadas com o sistema implantado por parte daqueles
que ficaram cada vez que ocorre um erro no sistema como se o fato de ter ocorrido um erro
fosse culpa da pessoa que esteve participando no projeto. Para a pessoa que retoma rea
acaba sendo um pouco mais dificil a readaptao. Nem todas voltam como foi comentado no
estudo de caso da empresa A. Mas ambos so da opinio que, em geral, a participao em um
projeto desse porte uma grande oportunidade para quem participa dele e depende de cada um
o resultado que pessoa poder obter dessa participao.

138

Enquanto no projeto B, no se comenta a qualidade dos recursos selecionados, no projeto A o

entrevistado mencionou que os recursos disponibilizados para o projeto no foram os
melhores disponveis na empresa, ressaltando entretanto que mesmo assim, os resultados
foram bons.

Com relao equipe de consultores participante do projeto, o entrevistado da empresa B

preferiu no manifestar a sua opinio quanto qualidade destes recursos. Desta forma, o que
se pode concluir, atravs das opinies manifestadas e identificadas nos dois casos analisados,
que a equipe de consultoria possua pouca experincia em projetos desse porte.

Com relao ao comprometimento da equipe com os resultados do projeto, o entrevistado da

empresa A comentou que esse comprometimento, por parte da equipe de consultores, nem
sempre o mais adequado e sugeriu que uma forma de melhorar o grau de comprometimento
desses consultores seria o estabelecimento de bnus e premiaes vinculados aos resultados
dos trabalho. Como comentado na reviso bibliogrfica especfica sobre o tema, so sugeridas
outras alternativas.

5.5

O perfil dos gerentes de projeto e da alta administrao, os conflitos e os aspectos

de liderana no projeto

Foi identificada a existncia de conflitos nos dois projetos. O entrevistado da empresa A fez
uma anlise das razes para os conflitos entre, principalmente, a equipe funcional da empresa
e a equipe de consultoria, focando principalmente a existncia de objetivos distintos entre
esses dois grupos. Os consultores necessitam otimizar o custo, o cronograma e a rentabilidade
do projeto e para isso, acabam reduzindo o escopo, ao contrrio da equipe composta por
membros da empresa, que est disposta a garantir a qualidade e a manuteno do escopo,
penalizando um pouco mais a rentabilidade do projeto, principalmente se o projeto tiver para a
empresa um custo fixo no atrelado sua durao e sim a pacotes de atividades concludas, o
que normalmente ocorre em projeto desse tipo. A soluo dos conflitos, em ambos os casos,
foi alcanada com a substituio das pessoas envolvidas no conflito.

139

Por sua vez, ficou mais caracterizada a falta de caractersticas de liderana na equipe gestora
do projeto da empresa A, enquanto que a inexistncia dessas mesmas caractersticas nos
gestores da empresa B passou um pouco mais desapercebida. Mas de uma forma geral, pdese concluir que, nos dois casos, a equipe gestora carecia de habilidades gerenciais.

No caso da empresa A, essa carncia foi um pouco minimizada pelo fato de, na formao das
equipes, cada mdulo a ser implantado contar com um recurso experiente e conhecido da
organizao. Para o entrevistado da empresa A, o diferencial na questo da liderana que os
lderes das equipes de projeto venham das reas usurias, ou seja, que sejam pessoas
respeitadas por seu know how e experincia, e que os membro de TI dentro da equipe
funcionem, neste caso, apenas como uma equipe de suporte, que intervm nas questes mais
tcnicas do sistema sempre que necessrio.

Nos dois casos, observou-se que os gerentes delegavam responsabilidades aos lderes ou
responsveis pelas equipes funcionais. Mas em ambos os casos ressaltado o fato de que, em
funo do volume de tarefas compreendidas no projeto, essa delegao era uma exigncia do
prprio projeto.

Foi observado que a gerncia da consultoria da empresa A no premiava ou recompensava a

equipe pelos resultados obtidos. Apenas o gerente da equipe funcional da empresa B tinha
essa atitude, reforada pela prpria cultura da empresa de premiar os resultados alcanados.

A comunicao dos lderes de projeto com o resto da equipe identificada mais na empresa B
do que na empresa A. A equipe de projeto teve mais acesso alta administrao na empresa B
do que na empresa A, cujo acesso alta administrao estava restrito ao gerente de projeto
mais experiente. Em ambos os casos, os gerentes de projeto tinham acesso alta
administrao.

Nos dois casos, tambm foi formada uma rede de relacionamentos interdepartamental e entre
empresas que se encontravam em processo de implantao ou que j tinham passado por esse
processo visando melhorar no s o relacionamento entre eles e a troca de experincias como
tambm garantir melhores resultados para o projeto.

140

5.6

O processo de Change Management - a comunicao, a integrao das equipes e o

treinamento

A participao da equipe de Change Management na empresa A se limitou ao evento de Kick-

Of! do projeto e preparao do plano de comunicao e do treinamento. Foi considerada uma

participao limitada, com pouco envolvimento nos momentos de conflito e com pouco
suporte equipe de projeto. Conforme comentado pelo entrevistado, a participao da rea de
Recursos Humanos da prpria empresa por vezes substituiu a equipe de Change Management
nesse papel integrador.

Com relao empresa B, a participao da equipe de Change Management foi mais ativa
porm assim o foi porque a rea de Recursos Humanos da empresa atuou intensamente
contando inclusive com o apoio de um consultor externo, contratado por esta, nos processos e
principalmente nos eventos de integrao das equipes.

Nos dois casos, ficou evidente que o processo de treinamento na empresa A se limitou quele
realizado previamente entrada do sistema em produo e que, embora o material tenha sido
preparado para esse momento especfico, no se definiu um procedimento posterior como
rotina para a reviso dos conhecimentos do sistema atravs da formalizao de um
treinamento peridico na empresa visando a reciclagem de seus usurios.

Nos dois casos, foram criados canais formais de comunicao dos resultados do projeto
organizao.

5.7

Os resultados obtidos pelo projeto - o processo de finalizao e os resultados

obtidos em termos de escopo, prazos e custo.

Ficou evidente que nos dois casos, as empresas comearam o projeto com uma diretriz clara
de limitarem o escopo do seu projeto s funcionalidades standard do sistema como forma de

141

garantir a concluso do mesmo dentro do prazo e do custo pretendidos. Conforme j

comentamos, a diretriz dada foi customizao ZERO.

Entretanto, um dos fatos comentados pelo entrevistado da empresa A com respeito sua
opinio sobre os fatores que afetaram o resultado do projeto da empresa A, ele destacou que
este se distanciou das funcionalidades standard disponveis no sistema, no tendo seguido a
diretriz inicial de customizao ZERO, tendo sim realizado customizaes em excesso.

J no caso da empresa B, esta comentou que foi uma opo deixar de implementar certas
funcionalidades e deixar de efetuar desenvolvimentos adicionais visando garantir o
cumprimento dos prazos, deixando essas funcionalidades para serem implementadas em
projetos futuros, para no estender mais o projeto inicial.

Em ambos os casos, a falta de experincia da consultoria e da equipe de projeto foi ressaltada

como um fator que limitou o desenvolvimento e aplicao de novas funcionalidades no
projeto e foi apontado como justificativa para o fato do projeto no ter sido concludo no
prazo.

Consequentemente ambos no cumpriram o custo inicialmente previsto.

Nos dois casos, continuaram havendo novos projetos como conseqncia do primeiro projeto
onde ento foram includas novas funcionalidades por que sempre so identificadas
necessidades de melhoria como uma conseqncia do prprio processo de implantao.

Novamente, cabe lembrar que, como restries e limitaes apresentadas neste estudo,
destacam-se a pequena amostragem, o no tratamento estatstico dos dados, a possibilidade de
introduo de vis tanto por parte do entrevistado quando do entrevistador, alm de no ser
possvel a generalizao dos resultados obtidos. Entretanto, tais fatores limitantes no
invalidam este estudo de carter exploratrio que poder servir como ponto de referncia para
futuras implantaes de sistema de ERP e estudos subsequentes, devendo constituir, portanto,
elementos encorajadores para novos estudos nesta fascinante rea de gesto de projetos.

142

CONCLUSESERECOMENDAES

As anlises comparativas das empresas entrevistadas para os estudos de caso, escopo principal
deste estudo e apresentadas no captulo anterior, evidenciam pontos importantes no que diz
respeito implantao de sistemas de ERP.

presente estudo sobre a utilizao de metodologias de Project Management como um

diferencial na implantao de sistemas de ERP evidenciou que o simples fato do projeto

utilizar uma metodologia de gerenciamento de projetos, atravs da contratao de uma
consultoria, contratada pelo seu know how e metodologia de gesto de projeto e
conhecimentos tcnicos do sistema, no garante o que ao termino do projeto, todos os
objetivos previsto inicialmente no que diz respeito ao cumprimento do prazo, escopo e custo
previstos, sejam alcanados sem que um trade of! ocorra. Os resultados obtidos ao final do
projeto de implantao do sistema de ERP so afetados por uma srie de outros fatores que
esto mais ligados a questes relacionadas com as variveis ressaltadas neste estudo como
liderana, formao de equipes, as tcnicas de Change Management adotadas e os aspectos da
cultura da organizao. A utilizao da metodologia garante sim que o projeto chegue ao seu
final, entretanto, esses outros fatores sero o diferencial de "sucesso ou fracasso" dos projetos
de implantao de sistemas de ERP.

Desta forma, algumas concluses podem ser tiradas deste estudo. Na Tabela D - Principais
Concluses a seguir, relacionamos as principais concluses obtidas neste estudo e a seguir

faremos alguns comentrios e resumiremos a principais concluses alcanadas.

Tabela D - Principais concluses:

PRINCIPAIS CONCLUSES

As empresas no possuem metodologia nem conhecimento suficientes para

implantar um sistema de ERP de grande porte sozinhas;
Algumas empresas selecionam o sistema objetivando alcanar um status na sua rea de
atuao;

143

PRINCIPAIS CONCLUSES

Contratam consultoria por acreditar que esta possui no s uma metodologia de Gesto
de Projeto adequada como tambm experincia em implantao desses sistemas de ERP;
Entretanto, ficou claro que quanto mais cedo ocorreram essas implantaes, menos
conhecimento e experincia possuam as empresas de consultoria assim como menores
eram as Tropicalizaes do sistema resultando assim em maiores atrasos e maior
quantidade de problemas ocorreram nos projeto;
Os riscos e tempo de durao do projeto aumentam medida que aumenta a quantidade
de mdulos a serem implantados assim como aumentam os gap's entre as necessidades da
empresa e as funcionalidades disponveis no modulo standard devendo-se antes de se
iniciar o projeto, fazer um Gap Analysis. Dependendo desse resultado, aumenta-se ou se
diminui a quantidade de customizaes (programaes especficas adicionais). O
fornecedor sugere customizao ZERO para minimizar o tempo e os riscos dos projetos;
O Gap Analysis normalmente acontece depois de contratada a consultoria, fazendo parte
das atividades do projeto, quanto o preo (custo do projeto) j foi negociado bem como
tempo de durao deste. Aps a analise de gap 's que ser possvel ter uma real noo se
o projeto cumprir o tempo e o custo planejado ou se ter que se comprometer, por
exemplo, o seu escopo;

A facilidade com que a empresa encara a mudana vaI facilitar o processo de

implantao do sistema de ERP;

A equipe se forma com Consultores (alguns experientes e outros inexperientes) e

membros da empresa como forma de minimizar o abismo entre o conhecimento
necessrio do negcio, o tempo disponvel para a implantao bem como a falta do
domnio tcnico do sistema a ser implantado por parte da empresa que o est
implantando;

A participao de membros internos da empresa, das reas funcionais e especialistas

no processo de negcio que est sendo implantando, permite obter melhores resultados na
implantao da ferramenta, de forma mais alinhada s necessidades da empresa. Sua
participao tambm encurta o tempo necessrio para o entendimento das atividades e
permite agilizar o processo de parametrizao do sistema;

Os membros da equipe interna da empresa funcionam ao mesmo tempo como

multiplicadores e como "quebra-gelo" na divulgao da nova ferramenta dentro da
empresa, dando mais confiabilidade ao novo sistema e processo que est sendo
implantado;
Inexperincia e desconhecimento da Consultoria interfere nos resultados do projeto;

144

PRINCIPAIS CONCLUSES
Equipes Mistas e projetos complexos como as implantaes de sistemas de ERP
requerem: um gerente com caractersticas de lder, muito trabalho e a realizao de
atividades de Change Management (Kick Off, eventos de integrao, reunies de
posicionamento e de status, treinamento, mapeamento e tratamento dos Stakeholders,
etc .. );

Tanto na seleo quanto no encerramento e retorno dos participantes s suas reas

funcionais, a participao da equipe de Change Management (RH) funciona como um
facilitador do processo. Nem sempre isso ocorre;
A sada e retorno dos membros da equipe funcional, traz insegurana ao membros
internos da organizao, participantes do projeto pois: no sabem se teriam de volta suas
vagas, se ainda teriam espao na empresa, se teriam equiparao salarial entre os demais
membros da equipe, entre outros medos;

A existncia de um plano de comunicao ativo facilita o processo de divulgao das

aes do projeto e das mudanas em curso na organizao, decorrentes do prprio
projeto;

Atividades de Integrao entre a equipe de consultores e a equipe funcional tambm

facilita e melhora o relacionamento e permite obter melhores resultados no projeto;
Se no houver bastante interveno ou aes de Change Management sobre as equipes
de consultores e as equipes funcionais nos projetos, essas equipes tendem a se
distanciar entre si formando 2 grupos separados, que respondem apenas aos seus
gerentes diretos, aumentando assim a probabilidade de surgimento de conflitos e
comprometendo assim os resultados do projeto;

O conflito acontece e nos casos analisados foi tratado com pouca interveno da equipe
de Change Management. A origem do conflito normalmente est na divergncia de
objetivos do projeto em termos de prazo x custo x qualidade (escopo). Embora todos
tenham um objetivo comum: concluir o projeto com sucesso, o problema reside nos
meios utilizados;

Em relao postura dos Gerentes de projeto:

1. a premiao e o reconhecimento pelo esforo e trabalho da equipe influencia os
resultados e a dedicao desta ao projeto (o que nem sempre ocorre);
2. delegar responsabilidade e concomitantemente autoridade e "poder" equipe
funcional, garante maior cobrana em termos de qualidade dos resultados obtidos
pelo projeto (como no caso da empresa B e como mencionado por Vergara 125
125

"Compartilhar autoridade. As pessoas tem a tendncia de delegar tarefas sem compartilhar a autoridade
necessria para a sua realizao, desprezando assim a fora do comprometimento embutida na autoridade.

145

PRINCIPAIS CONCLUSES
(1999), a delegao de poder permitiu a obteno de melhores resultados na
implantao do sistema de ERP);
3. a no identificao rpida dos problemas e a respectiva tomada de deciso por
parte do gerente, potencializa os problemas propiciando o aumento de conflitos;

Em relao ao perfil dos Gerentes de projeto, caracterizou-se:

1. a falta de caractersticas de liderana;
2. se apoiam na figura do especialista da rea funcional, lder de mdulo por ser
este uma pessoa com muito know how e respeitada na organizao;

Em relao postura da Alta Administrao:

1.

2.

possuem viso mais estratgica da importncia da mudana e da implantao

desse sistema mas no acompanham as mudanas no ambiente micro da
empresa;
o maior acesso da equipe de projeto alta administrao aumenta o
comprometimento e facilita a divulgao de mensagens e os objetivos do
projeto;

A inexistncia de treinamento peridico para reciclagem e treinamento de novos

usurios no manuseio do sistema compromete os resultados obtidos do sistema e
potencializa a repetio e manuteno de erros no manuseio deste;

Principais fatores responsveis pelos resultados insatisfatrios nos projeto:

1. inexperincia dos consultores;
2. excesso de funcionalidades implantadas num primeiro momento;
3. grande volume de customizaes (distanciamento da sugesto dada pelo prprio
fornecedor da soluo: customizao ZERO);

Com relao seleo da equipes, de acordo com Frame (1995)126, um projeto falha
normalmente no pela falta do emprego de tcnicas e metodologias mas sim, pela falta de
qualificao da equipe de projeto. Como mencionado, a equipe de Change Management, junto
com a gerencia do projeto, devem identificar o perfil dos recursos necessrios para o projeto e
Comprometimento funciona como cumplicidade na busca e na realizao dos objetivos empresariais" in
VERGARA, Sylvia Constant. Gesto de Pessoas. So Paulo: Atlas, 1999.
126

FRAME, 1. Davidson. Gerenciando Projetos nas Organizaes. 2001.

1
146

identificar dentro da organizao ou fora dela, aqueles recursos que apresentem a melhor
aderncia s necessidades do projeto. Pelo que foi observado nos estudos de caso, os projetos
em questo contaram com pessoas inexperientes e com pouco conhecimento do sistema que
estava sendo implantado, principalmente da consultoria. Tentou-se minimizar essa carncia
atravs de treinamento e trazendo para o projeto, a participao de pessoas conhecedoras dos
processos da empresa onde o sistema estava sendo implantado, pessoas vistas como lderes
em suas reas de atuao e que talvez tenha sido esse o diferencial que fez com que o projeto
no tenha fracassado logo desde o seu incio. Como comentado pelos entrevistados, nem
sempre puderam ser selecionados os melhores recursos humanos, por no estarem disponveis
mas, ainda assim, os recursos selecionados puderam contribuir para o sucesso do projeto,
dando mais confiabilidade ao que estava sendo proposto e implementado, pois seus colegas
percebiam que uma pessoa que posteriormente estaria manuseando o prprio sistema, sendo
ele o seu prprio usurio no futuro, no poderia estar propondo modificaes nos processos ou
implementado funcionalidades inviveis de serem operacionalizadas.

perfil de especialistas em implantao de sistemas e o conhecimento metodolgico, no

disponveis na organizao, foi obtido atravs da contratao de empresas de consultoria com

know how e experincia em projeto dessa natureza. A prpria consultoria, nos dois casos
analisados, no dispunha de recursos 100% treinados, tendo formado sua equipe com pessoas
experientes e outras menos experientes, que necessitaram de um acompanhamento mais direto
por parte dos consultores mais experientes. Esta inexperincia, em muitos casos, fez com que
o cronograma ficasse comprometido, pois treinamento adicional foi necessrio inclusive tendo
sido necessrio enviar consultores ao estrangeiro, no caso da empresa B, para se
especializarem em funcionalidades que precisavam ser implantadas.

De forma a garantir que a equipe e seus recursos dessem o melhor de si, foi necessria muita
comunicao. Haviam reunies peridicas de acompanhamento do projeto onde os problemas
eram apresentados, onde as solues pudessem ser encontradas em conjunto, pois faz parte da
metodologia empregada pelas empresas de consultoria contratadas, a existncia de reunies
especficas para essas discusses.

147

Tambm foi apontado por Frame (1995)127 a necessidade de existirem canais de comunicao
abertos entre a equipe e a gerncia como fatores para reduzir a ineficincia em projetos. Foi
identificado que esses canais existiam nos casos analisados, tendo contribudo positivamente
para os resultados dos projetos embora nem sempre os problemas especficos de um ou outro
membro da equipe tenham podido ser sempre resolvidos.

As recompensas tambm so apontadas por Frame (1995)128 como uma forma de estimular a
equipe. No caso da empresa A, a inexistncia de recompensas foi apontada como um fator que
desestimulou a equipe a dar o melhor de si no projeto. O estabelecimento de metas e
consequentemente de recompensas pelo seu atingimento deve ser pensado pelos gestores de
projetos como um diferencial que deve ser considerado em futuros projetos de implantao de
sistemas de ERP.

Na reviso bibliogrfica, foi mencionada a importncia de se criar uma identidade na equipe

de Projeto. Essa identidade obtida com eventos de integrao das equipes. Como observado
nos dois projetos, a realizao desses eventos era uma responsabilidade da equipe de Change
Management. Enquanto que na empresa B esses eventos ocorreram com freqncia, na

empresa A houve apenas um evento de Kick Off. Podemos observar que as questes
relacionadas a conflitos entre os membros da equipe foi mais abordada na entrevista com a
empresa A e assim, observar que o conflito, dentro da equipe, ressaltado sempre que existe
menos integrao entre os seus membros. Projetos dessa natureza geram naturalmente
conflitos decorrentes do volume de trabalho existente, da falta de domnio de 100% das
funcionalidades disponveis no sistema, da urgncia em se cumprirem prazos e do prprio
conflito de interesses existente entre a equipe de consultores e a equipe da empresa 129. Se na
empresa A tivessem havido mais eventos de integrao coordenados pela equipe de Change
Management, talvez no tivessem ocorrido tantos conflitos entre os membros da equipe de

consultores e membros das equipes funcionais como de fato ocorreu, no sendo necessria a

FRAME, J. Davidson. Gerenciando Projetos nas Organizaes. 2001.

Idem.
129 Como mencionado, a equipe de consultores est mais preocupada com a rentabilidade do projeto, querendo se
limitar s funcionalidade standard enquanto que a equipe funcional da empresa est mais preocupada com a
qualidade e a adoo de funcionalidades mais avanadas, na tentativa de tirar melhores resultados do sistema
a ser implantado
127
128

148

substituio de pessoas, fator que tambm compromete a qualidade e continuidade do projeto

como comentado na reviso bibliogrfica.

A motivao foi abordada na reviso bibliogrfica como sendo algo que est diretamente
relacionado com o reconhecimento pelo esforo empreendido em uma tarefa ou um trabalho
em um projeto. Nas entrevistas, tomou-se claro que no projeto da empresa A, esse
reconhecimento no acontecia nem na equipe funcional nem na equipe de consultores. J na
empresa B, o reconhecimento acontecia apenas por parte da gerncia funcional, como parte da
cultura da prpria organizao, conforme foi ressaltado pelo prprio entrevistado. Nesse caso,
onde havia a prtica de premiao, os resultados obtidos foram mais satisfatrios.

Uma grande preocupao ressaltada por Frame (1995)\3, o fato das equipes de projeto
serem formadas por pessoas as quais so freqentemente retiradas das suas rotinas
operacionais e levadas para formar parte dessa equipe de projeto, por um determinado perodo
de tempo que, de acordo com a necessidade, poder ser curto ou longo, ou podem at mesmo
participar simultaneamente de vrios projetos ao mesmo tempo. Essas pessoas precisam ser
trabalhadas pela equipe de Change Management tanto no momento da retirada das reas
funcionais como tambm no momento do seu retomo. E precisam da ateno especial dos
gerentes de projeto no sentido de motiv-las. Em ambos os casos, vimos que a equipe de

Change Management pouco participou do processo de retirada da pessoas das suas atividades
nas reas de origem e na sua integrao com o projeto, bem como os gerentes no primaram
pela ateno e motivao de suas equipes.
A equipe de projeto mista foi um diferencial positivo para os resultados alcanados pelos
projetos, conforme confirmado pelos entrevistados das empresas A e B.

Como ressaltado por Cleland (1999)J3J, a delegao de responsabilidades em um projeto tem

um impacto positivo no seu prprio andamento e, na sua opinio, sempre que as decises a
serem tomadas individualmente no gerem um impacto maior no oramento, cronograma e na
utilizao dos recursos disponveis e alm disso, se elas no criarem maiores problemas
130

FRAME, 1. Davidson. Gerenciando Projetos nas Organizaes. 2001.

149

polticos, podero ser tomadas pelos especialistas membros da equipe do projeto. Apenas as
questes mais cruciais devero requerer o envolvimento direto do gerente de projeto. Desta
forma, o fato da alta administrao ter delegado poderes equipe do projeto B para buscar os
melhores resultados do projeto atravs da simplificao de processos internos e a adoo das
melhores praticas e processos mais aderentes s funcionalidades do sistema, fez com que
fosse possvel implantar mais mdulos e obter melhores resultados no projeto. s vezes foi
at necessrio conter a ansiedade de alguns de seus membros pois acabavam querendo o
impossvel de ser alcanado o que por sua vez tambm faz aumentar os riscos no projeto.

A metodologia de Project Management ressalta a importncia do processo de anlise e

seleo do sistema na fase de concepo do projeto. Quando este processo no feito com o
critrio adequado, acaba sendo substitudo, depois que o sistema comprado, por um processo
anlise de gaps. Nesse processo, so identificadas as diferenas entre as necessidades da
empresa e as funcionalidades disponveis no sistema. A partir desta anlise so planejados os
desenvolvimentos adicionais que necessitam ser efetuados no sistema atravs de
customizaes. Desta forma, o projeto j se inicia com o prazo comprometido pois
normalmente a anlise de gap 's feita aps a contratao do projeto empresa de consultoria
que normalmente acaba por subestimar o prazo necessrio para a implantao do sistema.

No estudo de casos tanto da empresa A quanto da empresa B, foi dito que essa anlise de gaps
aconteceu em algum momento. Mesmo sendo o sistema na empresa A considerado como
corporativo, em algum momento a sua aderncia s necessidades da organizao foi
considerada. Entretanto, no foi feito um estudo mais profundo dos requisitos funcionais do
sistema antes de adquirir o produto no Brasil. Esse fato tomou necessrio o desenvolvimento
de customizaes adicionais, fazendo com que o projeto se desviasse do curso inicial.
Segundo o entrevistado, na Empresa A, a reviso de processos especificamente no se refletiu
em um verdadeiro problema para o projeto pois pelo fato da empresa no estar com seus
processos bem definidos, essa necessidade acabou por promover uma melhoria nos processos
ao invs de prejudicar o andamento dos trabalhos. Mas no caso de ser uma empresa mais

13l

CLELAND (1999), David I. Project Management. Strategic Design and Implementation. 3rd. Edition.
Singapore: McGraw-Hill, 1999.

150

estruturada e com seus processos mais amadurecidos, a falta de anlise desses requisitos
versus processos, pode prejudicar muito mais do que facilitar o processo.

Uma forma de minimizar esses efeitos limitar o projeto implantao das funcionalidades
standard do sistema, diretriz dada equipe de projeto nos dois casos. Entretanto, no caso da

empresa A, nosso entrevistado confirmou que o atraso do projeto deu-se tambm ao fato da
empresa ter excedido a quantidade de customizaes necessrias.

A partir da reviso bibliogrfica, identificou-se a importncia que a gerncia do projeto tem

como diferencial para o sucesso de projeto de implantao de sistemas de ERP. Comparando
as caractersticas existentes nos gestores dos projetos das empresas A e B com aquelas
apontadas pelos estudiosos do tema, vemos que existe um grande abismo entre os dois.
Nossos entrevistados apontaram a pouca experincia gerencial dos gerentes do projeto, tanto
da consultoria como dos gerentes funcionais. Tal fato, acreditamos, contribuiu negativamente
para os resultados do projeto. Atravs da anlise dos estudos de caso ficou caracterizada a
inexistncia de caractersticas de liderana nos gerentes de projeto das empresas A e B.

A reviso bibliogrfica da metodologia de Change Management nos explica as principais

atividades de uma equipe de Change Management em um projeto como sendo a identificao
e gerenciamento dos Stakeholders, a elaborao do plano de comunicao, a elaborao de um
plano de treinamento e o apoio gerncia do projeto na identificao do perfil, seleo e
integrao desses membros bem como possui um papel importante no apoio liderana do
projeto durante a execuo do mesmo.

Observamos que a equipe de Change Management, em ambos os projetos, teve participao

na concepo tanto do plano de comunicao quanto do plano de treinamento. Apenas teve
uma participao mais efetiva nas atividades de integrao de equipes na empresa Bonde
realizou mais eventos de integrao, o que fez uma diferena na hora de conseguir obter os
melhores resultados da equipe de projeto bem como na soluo de conflitos.

Com relao a treinamento, existem diferentes momentos em que as necessidades de

treinamento so identificadas no projeto. O primeiro destes durante o prprio projeto,

151

quando se identifica a necessidade de capacitar os membros da equipe de implantao no

manuseio da ferramenta para proceder sua configurao. Com relao a esse tipo de
treinamento, foi identificado que eles no so suficientes para capacitar uma pessoa da rea
funcional da empresa a parametrizar o sistema sozinha. Esses treinamentos apenas do ao
membro da equipe de projeto da rea funcional da empresa uma viso geral do mdulo para
poder fazer contribuies de forma mais eficaz durante a parametrizao do sistema. E sendo
assim, se faz mais necessria a participao de consultores experientes no projeto.

segundo momento ocorre j no final do projeto, quando o sistema est para entrar em

produo. quando todos os funcionrios da empresa que iro manusear a ferramenta devero
receber treinamento especfico para o poder fazer. responsabilidade da equipe de Change
Management, junto com o gerente do projeto e os gerentes das reas funcionais da empresa,

identificar quais sero os usurios que devero receber o treinamento e em quais mdulos.
Acontece que nem sempre o usurio de determinada atividade recebe o treinamento adequado
ou seja, no se consegue identificar que tipo de treinamento necessrio para um ou outro
funcionrio especificamente. Acabam por ocorrer erros na alocao de treinamento s pessoas
da empresa por falha, na hora de selecionar quem dever ser treinado, da equipe de Change
Management ou dos prprios gerentes. Normalmente porque a alocao dos funcionrios aos

treinamentos feita por pessoas que no conhecem de ante mo o que ser ensinado em cada
um desses treinamentos. Uma forma de minimizar essas falhas fazer com que o lder de
equipe funcional de cada mdulo, que conhece tambm as atividades de cada rea, sugira essa
alocao.

E finalmente, o terceiro momento aquele em que a equipe de Change Management prepara o

material de treinamento e deixa a empresa responsvel pela sua atualizao e a sua aplicao
atravs da implantao de um plano formal de treinamento. Neste caso, a equipe de Change
Management teve uma participao mais limitada no que diz respeito questo do

treinamento tanto na empresa A quanto na empresa B, no tendo deixado um plano de

treinamento definido, contemplando a reciclagem peridica dos usurios do sistema atravs de
procedimentos formais de reviso de processos e treinamento, o que acaba comprometendo a
qualidade e os resultados a serem extrados do sistema por parte dos usurios. A falta de
treinamento peridico nas novas funcionalidades do sistema, que vo mudando aps as

152

melhorias implementadas nas fases seguintes ao projeto, faz com que vcios adquiridos
anteriormente se mantenham. E que erros cometidos no manuseio do sistema pelos atuais
funcionrios acabem se repetindo quando so os prprios colegas de trabalho que terminam
por dar treinamento aos novos funcionrios.

No que diz respeito ao mapeamento e gerenciamento dos Stakeholders, as duas equipes de

Change Management no realizaram nenhuma atividade subsequente nesse sentido. Foi

apenas feito um mapeamento inicial e nada mais foi desenvolvido.

As probabilidades de que se obtenham melhores resultados de um projeto que envolve um

elevado grau de mudana na organizao aumentam ou diminuem em funo da clareza, do
compromisso compartilhado por todos, da justificativa para as modificaes propostas e do
processo como essa mudana conduzida. Aps implementada a mudana e concludo o
projeto, ao olhar para trs e analisar o que foi feito, com certeza se ver que muito ainda est
por fazer, muito ainda poderia ser melhorado, que algo sempre se poderia ter feito de outra
maneira. Entretanto, s vezes, algumas funcionalidades tm que ser deixadas para fases
seguintes, quando a empresa j tem mais cultura e domnio sobre a ferramenta implantada. A
empresa tem de se acostumar nova ferramenta e, aos poucos, quando aprende a manuse-la e
j a domina melhor, poder implementar novas funcionalidades, pois se insistir em
implementar cada vez mais funcionalidades na primeira onda ou fase do projeto, se no se
detiver no escopo inicialmente previsto, o projeto no ser concludo nunca. Sempre existiro
novos projetos como decorrncia do projeto original pois o sistema amplo e assim o permite.

A empresa B tinha muitas expectativas com relao aos resultados e s potencialidades

disponveis no sistemas ERP que estava sendo implantado. Entretanto, dada a inexperincia
tanto da equipe de consultores nas funcionalidades existentes como da equipe funcional,
foram deixando de lado aquelas funcionalidades mais complexas para um momento futuro,
para quando tanto os usurios estivessem mais ambientados na ferramenta, como quando
houvesse conhecimentos por parte dos especialistas nos sistemas para implantar tais
funcionalidades, passando a se deterem mais nas funcionalidades standard para no
comprometer o projeto como um todo. Suas expectativas eram altas por que sua cultura estava
voltada para aceitar e propor mudanas com mais facilidade do que a empresa A. E por isso, a

153

empresa sempre exigiu muito tanto dos consultores como dos seus funcionrios, participantes
do projeto, bem como uma maior dedicao e os melhores resultados. Entretanto, teve que
fazer um trade of! pois para alcanar esses objetivos teria que comprometer prazo e o custo do
projeto.

Como tambm comentado pelo entrevistado da empresa A, este disse que a partir do primeiro
projeto, as pessoas ficaram mais crticas e, conhecendo melhor o seu negcio, elas passaram a
exigir mais qualidade nos processos da empresa e passaram a propor mais melhorias e novos
desenvolvimentos que se sucederam primeira onda da implantao do sistema de ERP.

A partir do que foi comentado anteriormente, possvel resumirmos na Tabela E Principais Recomendaes a seguir, algumas recomendaes importantes que podero ser
consideradas por aqueles interessados em implantar sistemas de ERP futuramente.

Tabela E - Principais Recomendaes:

PRINCIPAIS RECOMENDAES

importante dedicar tempo e ter critrio na seleo da equipe (interna e de

consultores), no tendo pressa na sua formao. importante definir previamente o
perfil necessrio da equipe para o projeto;

A constituio de equipes mistas minimiza a distncia entre o conhecimento do

negcio por parte dos consultores e o desconhecimento de metodologias de gesto de
projetos e do sistema a ser implantado por parte da empresa, favorecendo os resultados
a serem obtidos pelo Projeto de Implantao de sistemas de ERP;

importante investir na preparao da equipe (treinamento e desenvolvimento) pois

ela ser o futuro usurio e multiplicador do conhecimento do sistema dentro da
organizao;

Investir no desenvolvimento gerencial do gerentes de projeto buscando despertar

neles caractersticas de lderes;

A delegao de poder favorece os resultados do projeto e incentiva o

desenvolvimento gerencial dos lderes e da equipe;

O estabelecimento de metas claras e o seu atingimento dever ser compensado

com recompensas durante o andamento do projeto como forma de motivar a

154

PRINCIPAIS RECOMENDAES
equipe;

Se o projeto no for bem planejado e se forem identificados muitos gap's aps o

incio deste, ser necessrio fazer um trade off entre escopo, tempo e custo e deixar as
melhorias e funcionalidade mais complexas para projetos futuros;

importante buscar o apoio da equipe de Change Management que possui um perfil

e foco em gesto de pessoas, para esse trabalho (definio de perfil, seleo,
treinamento, acompanhamento durante o projeto e devoluo do membro da equipe
sua rea quando do encerramento do projeto);

O retorno dos membros da equipe interna da empresa de volta s suas reas aps o
encerramento do projeto necessita de acompanhamento da equipe de Change
Management, apoiada pelo RH da empresa de forma a minimizar os impactos desses
membros na reincorporao s suas antigas posies ou nos novos desafios;

Proporcionar diversos em eventos de integrao entre as equipes do projeto permitir

obter melhores resultados durante o mesmo;

Investir num bom plano de Comunicao favorece a obteno de melhores resultados

no projeto no s em relao equipe de projeto como em relao empresa onde o
sistema est sendo implantado, minimizando as resistncias para com o projeto a partir
de clara comunicao das metas e objetivos a serem alcanados com o mesmo;

A identificao dos Stakeholders ajuda a mapear as reas de resistncia mudanas

trazidas pelo projeto e permite propor aes e atividades para romper essas barreiras e
envolver a organizao e seus membros nas mudanas e objetivos do projeto;

Como concluso, poderamos dizer que a utilizao da metodologia de Gesto de Projeto

garante sim que o projeto chegue ao seu final, entretanto, outros fatores com os comentados
anteriormente sero o diferencial de sucesso ou fracasso dos projetos de implantao de
sistemas de ERP.

155

REFERNCIAS BIBLIOGRFICAS

BOND, B., ERP in 1996: Transition Begins and Risk Acce1erates, Gartner Group Research,
Stanford, CT, USA, 28/01/97
BOND, B., ERP Market Trends: Vendor Conso1idation, Gartner Group Research, Stanford,
CT, USA, 18/11/96
BOND, B., and ERP Markets Trends: Vendors Strugg1e to Stay Competitive, Gartner Group
Research, Stanford, CT, USA, 18/11/96
BOND, B., ERP Vendor Guide 1997: Overview and Reference, Gartner Group Research,
Stanford, CT, USA, 23/06/97
BOND, B., The ERP Midmarket: Questions and Answers, Part 1 & 2,Gartner Group
Research, Stanford, CT, USA, 19/07/96
BOND, B., ERP Vendor Guide 1995, Parts 1-5,Gartner Group Research, Stanford, CT, USA,
19/12/95
CARVALHAL, Eugnio et FERREIRA, Geraldo. Ciclo de Vida das Organizaes:

peopleware,

liderana transformadora e desenvolvimento de equipes de alto

desempenho. Rio de Janeiro: Editora Fundao Getlio Vargas, 1999.

l CLELAND, David I. Project Management. Strategic Design and Implementation. 3rd. Edition.
Singapore: McGraw-Hill, 1999.
DAFT, Richard L. Teoria e Projeto das Organizaes. Rio de Janeiro: LTC-Livros Tcnicos e
Cientficos Editora S.A, 1999.
FISHER, Prof. Dra. Rosa Maria. Mudana e Transformao Organizacional, - Mudando os

Paradigmas da Mudana, 2002.

FRAME, J. Davidson, Managing Project in Organizations, How to make the best use of time,
techniques and Peop1e, Jossey-Bass Inc. San Francisco, Ca1ifomia, 1995.
FREITAS, Maria Ester de. Cultura Organizacional: Identidade, Seduo e Carisma? Rio de
Janeiro: Editora FGV, 1999.
Qfl GUIA DO PMBOK, Project Management Institute, PMI, 2000

JONES,

c., Custom ERP Functiona1ity: A Tactica1 Strategy, Gartner Group Research,

Stanford, CT, USA, 19/06/96

1
156

JONES,

c.,

Deploying ERP: Compromise for Large/Complex Enterprises, Gartner Group

Research, Stanford, CT, USA, 29/04/97

JONES,

c.,

ERP Scalability: Not a Given, Gartner Group Research, Stanford, CT, USA,

29/04/97
JONES,

c., Larger-User ERP Market Update:

Improved Execution, Gartner Group Research,

Stanford, CT, USA, 29/05/97

JONES, C., Larger-User ERP Market: 3Q96 Review, Part 1 & 2,Gartner Group Research,
Stanford, CT, USA, 11/10/96
JONES,

c.,

The ERP Market Had Growing Pains During 1995,Gartner Group Research,

Stanford, CT, USA, 17/01/96

JONES, C., Do ERP Vendors Have Re-engineering Functionality? Gartner Group Research,
Stanford, CT, USA,27/12/95
JONES,

c., Planning Guidelines for Implementing ERP, Part 1 &

2,Gartner Group Research,

Stanford, CT, USA, 27/03/97

KELLER, E., A Moming With SAP's Chairman, Gartner Group Research, Stanford, CT,
USA, 28/05/97
KELLER, E., Enterprise Wide Applications 1998: The "No Growth" Year?, Gartner Group
Research, Stanford, CT, USA, 25/09/96
KELLER, E., Enterprise Wide Applications 1998-2001: Shake-Out Time, Gartner Group
Research, Stanford, CT, USA, 25/09/96
KELLER, E., ERP 1996: Increased Focus and Competition, Gartner Group Research,
Stanford, CT, USA, 24/01/96
KELLER, E., Microsoft and SAP: Best of Friends?, Gartner Group Research, Stanford, CT,
USA, 20/03/97
KELLER, E., Revision: ERP Strategic Matrix: A 4Q95 Review, Gartner Group Research,
Stanford, CT, USA, 20/12/95
KELLER, E., SAP's Long-Term Focus: Market Domination, Gartner Group Research,
Stanford, CT, USA, 15/05/96

157

KELLER, E., SAP's Short-Tenn Focus: Client Satisfaction, Gartner Group Research,
Stanford, CT, USA, 15/05/96
KELLER, E., The Four R's ofERP, Gartner Group Research, Stanford, CT, USA, 29/11/95
LOZINSKY (1996), SERGIO, Administrao do escopo do Projeto, Marketing SAP Brasil,
So Paulo, Brasil, SAPerspectiva, junho 97
LOZINSKY (1996), SERGIO, Software: Tecnologia do Negcio, Imano Editora Ltda., So
Paulo, Brasil, 1996
MARTINS, Gilberto de Andrade. Manual para Elaborao de Monografias e Dissertaes.
So Paulo: Atlas, 1994.
.

MOTTA, Paulo Roberto. Gesto Contempornea: a cincia e a arte de ser dirigente. Rio de
Janeiro: Record, 1999.
MOTTA, Paulo Roberto. Transformao Organizacional. A teoria e a prtica de inovar. Rio
de Janeiro: Qualitymark, 1999.
PFEFFER, Jeffrey. Vantagem Competitiva atravs de Pessoas. So Paulo: Makron Books,
1994.
PORTER, MICHAEL E., Vantagem Competitiva: criando e sustentando um desempenho
superior, Rio de Janeiro, Editora Campus, 1992,
SOARES, T. Diana. Prticas Gerenciais das Empresas Lderes no Brasil. Rio de Janeiro:
Qualitymark, 1996.
THE PRICE W ATERHOUSE CHANGE INTEGRATION TEAM. Befter Change: Best

Practices for Transforming your Organization. USA: Irwin Professional Publishing,

1995.
VERGARA, Sylvia Constant. Gesto de Pessoas. So Paulo: Atlas, 1999.
VALERIANO, Dalton L., Gerenciamento Estratgico e Administrao de Projetos, Makron
Books, So Paulo, SP, 2001.VERGARA, Sylvia Constant. Projetos e Relatrios de

Pesquisa em Administrao. So Paulo: Atlas, 1998.

~YIN,

R.K. Case study research: design AND METHODS.2.ED.London:Sage,1994.

W ARD, J. LeRoy. Project Management Tenns - A Working Glossary. Arlington, Virginia.

ESI International, 1999.

l
158

ANEXO - QUESTIONRIOS PARA ENTREVISTAS

Data da entrevista: _ _ _ _ _,/_ _ _ _ _--'/_ _ _ _ __

Horrio: Incio:
Fim:- - - - - - - - Empresa: _________________________________
Nome da Pessoa Entrevistada:- - - - - - - - - - - - - - - - - - - - - - - - - - Posio do entrevisto no Projeto: ________________________

PERGUNTAS
I.

Os motivos

Responda o que voc acha sobre:

1.
2.
3.
4.
5.

11.

Que levou a organizao a mudar (no sentido de buscar um sistema ERP)?

Existia na organizao sistema semelhante anteriormente?
Havia necessidade da substituio do sistema anterior?
O que voc acha da opo pelo sistema selecionado?
Que fatores voc acha que foram levados em considerao para a seleo desse sistema
(atribuies tcnicas, o fato dele possuir um nome reconhecido pelo mercado, etc .. )

Levantamento tcnico das necessidades

Na sua opinio, voc acha que:

1. Houve um estudo prvio das qualidades do sistema?
2. Foram consultadas empresas que j fossem usurias desse sistema?
3. Qual foi a opinio manifestada por elas? Qual o feedback e quais as recomendaes que elas
fizeram?
4. As opinies dessas empresas foram consideradas na hora de se optar pelo sistema ERP?
5. Foi feito um estudo/levantamento suficientemente profundo e abrangente dos requisitos
funcionais do sistema e sua aderncia s necessidades operacionais da organizao?
6. Foi feito um levantamento prvio dos processos em uso e da necessidade de readequao
desses processos em vigor ao novo sistema?
Se suas respostas forem negativas, na sua opinio, de que forma voc acha que esses fatores
possam ter influenciado negativamente no resultado do projeto?

111.

A cultura da empresa

Responda o que voc acha sobre:

1. Se a sua empresa costuma estar na vanguarda de novos processos de gesto, na adoo de
novas ferramentas tecnolgicas?
2. A organizao (funcionrios, gerentes e alta administrao) aceita bem as mudanas? (Se
necessrio, analise separadamente cada um dos 3 grupos de usurios envolvidos).
3. A alta administrao fomenta na organizao mudanas de processos e mtodos de trabalho?

1
159

4. A organizao (funcionrios e gerentes) aceitam bem a implantao de novos procedimentos

de trabalho e novas ferramentas, principalmente tecnolgicas como as ferramentas de ERP?
5. A organizao (alta administrao, funcionrios e gerentes) busca e prope melhorias de
processos, novas metodologias e ferramentas de trabalho?
6. Os funcionrios se sentiram ameaados pela entrada do novo sistema?

A METODOLOGIA DE PLANEJAMENTO, FORMAO E GESTO DO PROJETO

IV.

A escolha da Equipe de Consultores

Comente o que voc acha sobre:

1. Os fatores que foram levados em considerao na seleo da equipe de consultores que
participou e/ou conduziu o processo de implantao do sistema de ERP
2. A qualidade e preparao da equipe de consultores
equipe funcional (consultores)
gerencia
3. A consultoria possua experincia em outros projetos de implantao de sistemas de ERP?
Aproximadamente quantos?

V.

A equipe de Projeto
1. Na sua opinio, como foi o processo de formao da equipe de projeto?
2. A equipe contou com membros internos organizao?
3. Caso positivo, voc acha que essa participao contribuiu positiva ou negativamente para
o sucesso do proj eto?
4. Como foi o processo de seleo dos membros da equipe internos organizao?
5. Como foi a comunicao da sada desses membros equipe em que eles estavam
inseridos?
6. E como foi o processo de aceitao dos demais membros do grupo sada dessas pessoas
para a equipe do projeto?
7. Aps o trmino do projeto, como foi o processo de reintegrao desses membros equipe
anterior?
Durante o projeto,
8. Como foi a integrao entre a equipe de projeto do cliente e a equipe de projeto da
consultoria?
9. Existiu algum "movimento formal" para a integrao das equipes?
10. Qual a sua opinio a respeito dessas equipes mistas?
11. De que forma a existncia de equipes mistas influencia (positiva ou negativamente) no
resultado dos projetos?
12. A existncia de equipes mistas gera conflitos de interesses durante o projeto? (equipe do
cliente x equipe de consultores)?
13. Como foram administrados os conflitos?
14. Na sua opinio, de que forma esses conflitos foram benficos ou prejudiciais ao projeto?
15. Na sua opinio, todos os projetos de implantao de ERP deveria contar com equipes
mistas?

l
160

VI.

Treinamento

Na sua opinio, comente:

1. A equipe funcional da empresa recebeu treinamento adequado para operar e parametrizar o
sistema a ser implantado?
2. Os demais usurios, em todas as reas da organizao afetadas, foram treinados para
manusear o novo software?
3. Houve acompanhamento por parte do fornecedor e da consultoria de implantao durante o
incio da utilizao do software?
4. Foi elaborado material e documentao adequados para administrar treinamento
organizao?
5. Esse material freqentemente utilizado pela organizao?
6. Foi desenvolvido e implantado um processo de treinamento peridico na empresa, para os
novos funcionrios ou o seu treinamento feito on the job por seus demais colegas?
7. Em que esse procedimento afeta a qualidade do trabalho e a utilizao das funcionalidades do
sistema?

VII.

A Gerencia de Projetos e a Liderana

Gerentes de Projeto Externos

D a sua opinio, em relao ao (s) gerente (s) de projeto, a respeito de:

1. Quantos gerentes existiam no projeto?
2. Descreve um pouco a diviso de trabalho/tarefas entre eles caso houvesse mais de um
gerente.
3. Como voc via o gerente de projeto em relao sua capacidade de se relacionar com:
a equipe
a mdia gerncia do cliente (seus contrapartes)?
a alta administrao do cliente
4. Suas habilidade e conhecimentos tcnicos a respeito do projeto que estava sendo
implantado?
5. Sua capacidade de administrar as atividades inerentes ao projeto como cronograma,
recurso humanos e financeiros, crises entre os diversos membros da equipe e/ou entre
equipe de consultoria e cliente?
6. Ele era uma pessoa carismtica para a equipe e para o cliente?
7. Demonstrava interesse e comprometimento com os objetivos do projeto?
8. Qual era o seu estilo para conseguir que as tarefas fossem executadas (pela foraDitatorial, pela negociao)?
9. Ele costumava delegar responsabilidades aos demais membros da equipe?
10. Negociava metas e prazos para o projeto com os demais membros das equipes
multifuncionais?
11. Premiava os resultados obtidos?
12. Lutava por mais recursos (humanos, financeiros, etc.) para o projeto?

161

13. Solicitava treinamento e proporcionava o continuo desenvolvimento dos membros da

equipe e subordinados atravs no s de treinamentos como tambm atravs da
participao em outros subprojetos do seu interesse?
14. Estava atento s necessidades e problemas pessoais da equipe?
15. Durante o projeto criou um canal de comunicao com a equipe e demais gerentes do
projeto?
16. Era gil na tomada de decises?
17. Ao identificar um obstculo ou problema, conseguia identificar rapidamente uma soluo
e implant-la?
Caso suas respostas tenham sido negativas, de que forma voc acha que esses fatores
influenciaram o projeto (negativa ou positivamente)?

Gerentes de Projeto da empresa

1. Ele demonstrava que o sucesso do projeto que ele coordenava garantiria o seu prprio
sucesso e ascenso na organizao?
2. Escutava as necessidades da equipe?
3. Agradecia e premiava/recompensava os esforos e os resultados obtidos pela equipe?
4. Desenvolveu durante o projeto um rede de relacionamentos com as demais rea da
empresa ou outras empresas para conseguir atingir os objetivos ou completar tarefas
exigidas pelo projeto?
5. Durante o projeto criou um canal de comunicao com a equipe e demais gerentes do
projeto?
6. Era gil na tomada de decises?
7. Demonstrava interesse e comprometimento com os objetivos do projeto?
8. Premiava os resultados obtidos?
9. Lutava por mais recursos (humanos, financeiros, etc.) para o projeto?
10. Ao identificar um obstculo ou problema, conseguia identificar rapidamente uma soluo
e implant-la?
11. A alta administrao - Stakeholders
12. Conseguia transmitir equipe a importncia do projeto para a estratgia escolhida pela
organizao?
13. Defendia o projeto junto s demais reas da empresa afetadas por este?
14. Demonstrava preocupao com as necessidades da equipe e gerentes do projeto (tanto
gerentes e equipe externa quanto equipe interna da organizao)?
15. Lutava por mais recursos para o projeto?
16. Agradecia e premiava/recompensava os esforos e os resultados obtidos pela equipe?
17. Desenvolveu durante o projeto uma rede de relacionamentos com as demais rea da
empresa ou outras empresas para conseguir atingir os objetivos ou completar as tarefas
exigidas pelo projeto?
18. Durante o projeto criou um canal de comunicao com a equipe e gerentes do projeto?
19. Era gil na tomada de decises?

VIII.

A Comunicao

Na sua opinio, o que voc acha:

1. Da forma como as novidades so comunicadas na organizao?

162

2.
3.
4.
5.

Da forma como foi comunicada na empresa a aquisio de um novo sistema?

Da forma como foi comunicada a formao da equipe de trabalho do projeto?
Da forma como foi comunicado o andamento (em todas as suas fases) do projeto?
Da forma como foi o processo de retomo dessa equipe s suas funes rotineiras aps a
concluso e encerramento do projeto?
6. Do formato do Canal de Comunicao utilizado pela empresa para divulgar as notcias do
projeto e o seu andamento?
7. Na sua opinio ele era eficiente?
8. O que voc poderia sugerir como um bom Canal de Comunicao?

IX.

O resultado

Na sua Opinio, como foram os Resultados alcanados pelo Projeto em termos de:

Escopo
1. A proposta inicial do projeto foi atendida?
2. Os objetivos comunicados no incio do projeto foram alcanados?
3. Ao concluir o projeto, tudo o que inicialmente foi previsto fazer foi feito ou foi
deixada alguma parte para uma fase posterior?
4. Na sua opinio, porqu isso aconteceu?
5. Foi prejudicial ou benfico ao projeto?
6. Continuam havendo pequenos novos projetos como consequencia do projeto
inicial? Por que motivo? Porque ficou faltando fazer alguma coisa ou por qu uma
coisa puxa a outra e se identificou ser necessrio estender algumas
funcionalidades do sistema e us-las no dia a dia?
7. Na sua opinio, as mudanas nos processos da empresa e no seu prprio negcio,
continuaram exigindo que fossem feitos desenvolvimentos contnuos no sistema,
posteriores ao encerramento,

Prazo
1. O projeto foi concludo no prazo?
2. Porqu (do atraso ou do cumprimento do prazo)?

Custo
1. O projeto foi concludo dentro do custo previsto?
2. Qual o percentual de desvio entre o custo inicial e o efetivamente cumprido?
3. Porqu?