You are on page 1of 162

PAULA EMIKO KUWAMOTO

A CERTIFICAÇÃO EM GERENCIAMENTO DE PROJETOS À LUZ DA TEORIA


INSTITUCIONAL – UM ESTUDO DE CASO.

Dissertação apresentada à Escola de


Administração de Empresas de São Paulo da
Fundação Getulio Vargas, como requisito para
obter o título de Mestre em Administração de
Empresas.

Campo de Conhecimento: Administração e


Análise de Tecnologia da Informação.

Orientador: Prof. Dr. Alberto Luiz Albertin.

SÃO PAULO
2008
PAULA EMIKO KUWAMOTO

A CERTIFICAÇÃO EM GERENCIAMENTO DE PROJETOS À LUZ DA TEORIA


INSTITUCIONAL – UM ESTUDO DE CASO.

Dissertação apresentada à Escola de


Administração de Empresas de São Paulo da
Fundação Getulio Vargas, como requisito para
obter o título de Mestre em Administração de
Empresas.

Campo de Conhecimento: Administração e


Análise de Tecnologia da Informação.

Data da Aprovação
___/___/___

Banca Examinadora

_______________________________
Prof. Dr. Alberto Luiz Albertin (Orientador)
EAESP - FGV

_______________________________
Profª. Drª. Maria José Tonelli
EAESP - FGV

_____________________________
Prof. Dr. Ronaldo Zwicker
FEA - USP
DEDICATÓRIA

Dedico esta dissertação aos meus pais, Fumihiro


e Taieko Kuwamoto, cujo esforço e muito
trabalho permitiram meu caminho até aqui.
AGRADECIMENTOS
Agradeço ao meu orientador, Prof. Dr. Alberto
Luiz Albertin, pelos ensinamentos, confiança,
paciência e dedicação concedidas à minha
orientação.
Agradeço a todos os colegas e professores do
CMCD da EAESP–FGV, pelo apoio,
aprendizagem e amizade, principalmente aos
amigos da linha de Administração e Análise de
Tecnologia da Informação.
Agradeço aos amigos, pelo apoio, compreensão e
auxílio, especialmente a Cláudio Santos de Brito
e Eduardo Francisco Junior, cuja ajuda foi
fundamental para consecução deste trabalho.
Por fim, agradeço ao apoio de todos aqueles que
de alguma forma auxiliaram para que este
trabalho fosse realizado, direta ou indiretamente.
“Todos somos iguais, mas alguns são mais iguais que os outros”
George Orwell – “A Revolução dos Bichos”
RESUMO

Esta dissertação reúne os principais conceitos em gerenciamento de projetos. Em destaque,


trata dos modelos de maturidade em gerenciamento de projetos, principalmente os derivados
do modelo CMM (Capability Maturity Model), e suas respectivas certificações quando
existentes.
Como perspectiva teórica para a reflexão sobre o tema, foi utilizada a Teoria Institucional,
com ênfase nos conceitos de legitimidade, isomorfismo e comportamento cerimonial.
Para buscar a comprovação de indícios das pressões do ambiente nas organizações em busca
de conformidade e legitimidade frente a um campo de atuação, em detrimento da eficiência,
foi usada uma pesquisa qualitativa explanatória, através de um estudo de caso que analisou o
processo de certificação de maturidade em gerenciamento de projetos, um campo fértil e
ainda inexplorado, principalmente ao analisarmos a situação brasileira.

Palavras-chave: gerenciamento de projetos, modelos de maturidade em gerenciamento de


projetos, certificações em gerenciamento de projetos, tecnologia de informação, teoria
institucional.
ABSTRACT

This dissertation gathers the main concepts in project management. It deals with the models of
maturity in project management, mainly the derivations of model CMM (Capability Maturity
Model), and its respective - when existing - certifications. As theoretical perspective for the
reflection on the subject, the Institutional Theory was used with emphasis on the concepts of
legitimacy, isomorphism and ceremonial behavior.
An explanatory qualitative research was performed - through a case study - to attest the
evidence of a pressuring environment which pushes organizations to conformity and
legitimacy in their performance field rather than efficiency. This study analyzed the process
of project management maturity certification which is a fertile and still unexplored field,
especially when considering the Brazil’s situation.

Keywords: project management, project management maturity model, project management


evaluations, information technology, institutional theory.
LISTA DE ESQUEMAS

Esquema 1: O contexto em gerenciamento de projetos .........................................................26


Esquema 2: Os processos em Gerenciamento de Projetos.....................................................38
Esquema 3: O modelo de processo PRINCE2........................................................................44
Esquema 4: Concepção de um processo no CMMI ...............................................................55
Esquema 6: Estrutura dos modelos de maturidade desenvolvidos pela OCG.......................66
Esquema 7: Estrutura do programa MPS.BR........................................................................72
Esquema 8: Comparação entre os níveis MPS.BR e CMMI .................................................73
Esquema 9: O modelo PMMM ...............................................................................................75
Esquema 10: O modelo OPM3................................................................................................77
Esquema 11: Processo de Institucionalização .......................................................................84
Esquema 12: A evolução da institucionalização em projetos de TI. ...................................102
Esquema 13: Estrutura da pesquisa .....................................................................................105
Esquema 14: Estrutura atual da Empresa ABC. .................................................................117
Esquema 15: Evolução do processo de certificação da Empresa ABC...............................119
Esquema 16: Processo de institucionalização do CMMI.....................................................131
LISTA DE GRÁFICOS

Gráfico 1: Evolução do número de certificações CMMI no Brasil.......................................22


LISTA DE QUADROS

Quadro 1: Diferenças entre projetos e atividades rotineiras. ................................................25


Quadro 2: Pontos críticos na gestão de projetos ....................................................................32
Quadro 3: Os “Early Warning Signs”....................................................................................33
Quadro 4: As nove áreas do conhecimento e respectivos processos......................................40
Quadro 5: Resumo da estrutura do RBC................................................................................42
Quadro 6: Estágios da maturidade em gerenciamento de projetos. ......................................51
Quadro 7: Vantagens das Representações Continuada e Estagiada.....................................57
Quadro 9: Características de maturidade no P3M3 para projetos, programas e portfólios de
projetos. ....................................................................................................................................67
Quadro 10: Dimensões e níveis de maturidade do MMGP....................................................70
Quadro11: Comparação entre modelos de maturidade .........................................................79
Quadro12: Perspectivas teóricas sobre a difusão ou rejeição de tecnologias administrativas.
..................................................................................................................................................91
Quadro 13: As cinco respostas estratégicas às pressões institucionais .................................97
Quadro 14: As trinta práticas institucionalizadas em gestão de projetos............................101
Quadro 15: Taxonomia de tipos de teoria em sistemas de informação...............................107
Quadro 16: A relação entre as condições e a estratégia de pesquisa ..................................108
Quadro 17: Processo de construção de teoria de um Estudo de Caso.................................110
Quadro 18: Nomenclatura, classificação e descrição de funções dos indivíduos
entrevistados...........................................................................................................................126
Quadro 19: Comparação entre estratégias de análise de dados. .........................................127
Quadro 20: Construção das categorias com base na revisão de literatura. ........................136
LISTA DE TABELAS

Tabela 1: Ranking do número de certificações CMMI..........................................................22


Tabela 2 : Evolução dos índices de status do CMMI .............................................................53
LISTA DE SIGLAS

ABGP – Associação Brasileira de Gerenciamento de Projetos


ABNT – Associação Brasileira de Normas Técnicas
ACM – Association of Computing Machinery
AIS – Association for Information Systems
ATM – Automatic Teller Machine
BID – Banco Interamericano de desenvolvimento
CMMI - Capability Maturity Model Integration
CMM - Capability Maturity Model
EDI – Eletronic Data Interchange
EWS – Early Warning Signs
FINEP – Financiadora de Estudos e Projetos
FUMIN – Fundo Multilateral de Investimento
ICB – International Competence Baseline
INMETRO – Instituto Nacional de Metrologia, Normalização e Qualidade Industrial
IPMA – International Project Management Association
ISO - International Organization for Standartization
KPI – Key Performance Indicators
MMGP – Modelo de Maturidade em Gestão de Projetos
MPCM – Maturity by Project Category Model
MPS.BR – Melhoria de Processo de Software Brasileiro
NCB – National Competence Baseline
OPM3 – Organizational Project Management Maturity Model
PM² - Project Management Process Maturity Model
P3M3 - Portfolio, Programme and Project Management Maturity Model
PDU - Professional Developement Unit
PM3 – Project Management Maturity Model
PMBOK – Project Management Body of Knowledge
PMI – Project Management Institute
PRINCE2 - PRojects IN Controlled Environments
RBC – Referencial Brasileiro de Competências
SCAMPI - Standard CMMI Appraisal Method for Process Improvement
SEI – Software Engineering Institute
SEPG - Software Engineering Process Group
SOFTEX – Associação para a promoção de Excelência do Software Brasileiro
SPI – Software Process Improvement
SPIN – Software Process Improvement Network
SQA – Software Quality Assurance
TQM – Total Quality Management
URA – Unidade de Resposta Audível
SUMÁRIO

Introdução e Contexto .............................................................................................................16


Objetivo ....................................................................................................................................19
Justificativa e Contribuições ...................................................................................................21
Revisão da Literatura ..............................................................................................................24
1.1. Gerenciamento de Projetos ............................................................................................... 24
1.1.1. Ciclo de vida do projeto................................................................................................................. 27
1.1.2. Os stakeholders.............................................................................................................................. 28
1.1.3. Competências em Gerenciamento de Projetos............................................................................... 29
1.1.4. Os Projetos em Tecnologia da Informação .................................................................................... 30
1.1.5. Sucesso .......................................................................................................................................... 34
1.2. As Instituições em Gerenciamento de Projetos ............................................................... 36
1.2.1. As metodologias em gerenciamento de Projetos ........................................................................... 37
1.2.1.1. O PMBOK - Project Management Book of Knowledge ...................................................... 37
1.2.1.2. O RBC - Referencial Brasileiro de Competências ............................................................... 41
1.2.1.3. O PRINCE2 (PRojects IN Controlled Environments).......................................................... 43
1.3. As certificações em Gerenciamento de Projetos ............................................................. 45
1.3.1. Certificações .................................................................................................................................. 45
1.3.2. As certificações profissionais em Gerenciamento de Projetos ...................................................... 47
1.3.3. As certificações organizacionais em Gerenciamento de Projetos.................................................. 49
1.4. A maturidade em Gerenciamento de Projetos e os modelos de maturidade ................ 50
1.4.1. O CMMI - Capability Maturity Model Integration....................................................................... 52
1.4.1.1. Origens................................................................................................................................. 53
1.4.1.2. A estrutura............................................................................................................................ 54
1.4.1.3. A implantação e a certificação ............................................................................................. 59
1.4.1.4. Motivações ........................................................................................................................... 61
1.4.1.5. As críticas............................................................................................................................. 62
1.4.2. O P3M3 - Portfolio, Programme and Project Management Maturity Model................................. 65
1.4.3. Project Management Process Maturity (PM²) Model .................................................................... 68
1.4.4. O MMGP – Modelo de Maturidade em Gestão de Projetos .......................................................... 69
1.4.5. O MPS.BR – Melhoria de Processo de Software Brasileiro.......................................................... 70
1.4.5.1. Definição.............................................................................................................................. 72
1.4.5.2. O futuro do MPS.BR............................................................................................................ 74
1.4.6. O PMMM - Project Management Maturity Model....................................................................... 74
1.4.7. O OPM3 (Organizational Project Management Maturity Model) ................................................. 76
1.5. Teoria Institucional............................................................................................................ 80
1.5.1. Processos de Institucionalização.................................................................................................... 83
1.5.1.1. Habitualização...................................................................................................................... 85
1.5.1.2. Objetificação ........................................................................................................................ 85
1.5.1.2.1. A teorização .................................................................................................................... 86
1.5.1.3. Sedimentação ....................................................................................................................... 87
1.5.2. Rituais e Cerimônias...................................................................................................................... 88
1.5.3. O Isomorfismo Institucional .......................................................................................................... 90
1.5.3.1. O isomorfismo coercitivo..................................................................................................... 93
1.5.3.2. O isomorfismo normativo .................................................................................................... 93
1.5.3.3. O isomorfismo mimético...................................................................................................... 94
1.5.4. As críticas à perspectiva institucional............................................................................................ 96
1.5.5. A perspectiva institucional no campo de estudos de Tecnologia da Informação........................... 98
1.5.6. A perspectiva institucional em Gerenciamento de Projeto em Tecnologia da Informação ......... 100
1.5.7. A Teoria Institucional e Certificações ......................................................................................... 104
1.5.8. Desenvolvimento Teórico – perspectiva Institucional nas certificações em gerenciamento de
projetos ..................................................................................................................................................... 105
Metodologia ...........................................................................................................................107
1.6. O Estudo de Caso............................................................................................................. 108
1.6.1. Instrumentos e protocolo de estudo de caso ................................................................................ 112
1.6.1.1. Protocolo de Estudo de Caso.............................................................................................. 113
O Caso ....................................................................................................................................115
1.7. A empresa ......................................................................................................................... 115
1.7.1. A estrutura ................................................................................................................................... 116
1.7.2. A certificação CMMI................................................................................................................... 118
1.7.3. A motivação................................................................................................................................. 118
1.7.4. O processo de certificação ........................................................................................................... 119
1.7.5. As barreiras.................................................................................................................................. 120
1.7.6. A pós-certificação........................................................................................................................ 123
1.7.7. As conseqüências......................................................................................................................... 124
Análise do Caso .....................................................................................................................126
1.8. Análise macro: O CMMI e a Teoria Institucional ........................................................ 129
1.9. Análise da certificação..................................................................................................... 131
1.9.1. Construção das categorias............................................................................................................ 132
Conclusões .............................................................................................................................146
1.10. Recomendações ................................................................................................................ 150
Limitações ..............................................................................................................................152
Estudos Futuros.....................................................................................................................153
Referências.............................................................................................................................154
16

INTRODUÇÃO E CONTEXTO

Durante 35 anos a disciplina de Gerenciamento de Projetos era tida como um


instrumento de implantação de inovações nas organizações, mas estava longe de ser
considerada um elemento estratégico. O uso sistemático de Gerenciamento de Projetos
ameaçava as linhas tradicionais de autoridade e, portanto, apenas cursos básicos sobre o
assunto eram ministrados e sua utilização era parcial e superficial. (KERZNER, 2002).
Em meio aos anos 90, duas recessões econômicas atingiram os Estados Unidos,
alterando o cenário e fazendo com que as organizações passassem por fortes pressões
competitivas, que as levariam a criar produtos de mais alta qualidade, com menor preço e em
menor tempo. Além disso, houve a crescente necessidade e importância em se construir e
manter relacionamentos de longo prazo com seus fornecedores. (KERZNER, 2002). Ou seja,
ocorreu um aumento da competitividade, que podemos definir como “a capacidade da
empresa de formular e implementar estratégias concorrências que lhe permitam obter e
manter a longo prazo, a posição sustentável no mercado” (ALBUQUERQUE, 1992, p.18).
A recessão espalhou-se pelo mundo, e profundas transformações atingiram
também o Brasil: a globalização gerou uma revolução tecnológica, financeira e comercial;
ocorreu a estabilização da moeda, o controle inflacionário e a abertura de mercado, sendo este
último o maior responsável pelo aumento da competitividade no país. As organizações não
podiam repassar o custo inflacionário aos seus preços, buscou-se o aumento da produtividade
como forma de sustentar a sobrevivência das organizações, e novas tecnologias foram
adicionadas ao processo de produção. Estes impactos fizeram com que as organizações
revissem suas estratégias de competição num cenário econômico muito mais dinâmico.
(LOPES, 1996).
A partir deste contexto, em que as organizações passam por mudanças cada vez
mais velozes e intensas, muitas destas mudanças estão diretamente relacionadas com o
surgimento de novas tecnologias ou novas aplicações em Tecnologia de Informação, fazendo
com que se alterem as bases operacionais estratégicas e de competitividade. Foi necessário
adquirir consciência sobre a condução de diversos conjuntos de atividades que podem e
devem ser tratados como projetos, devido as suas características inovadoras e únicas
(ALBERTIN, 2001; MENEZES, 2003).
17

Assim sendo, o Gerenciamento de Projetos tornou-se uma ferramenta importante


para o estabelecimento de mudanças e desenvolvimento dentro das empresas. Com o aumento
de sua relevância dentro do contexto das empresas, ocorreu um movimento crescente, por
parte de pesquisadores, organizações e entidades normativas, para o desenvolvimento de
competências específicas no gerenciamento de projetos, através da definição de metodologias,
modelos e normas. (BOUER; CARVALHO, 2005; MENEZES, 2003).
Devido ao aumento da importância da disciplina Gerenciamento de Projetos,
observamos o crescimento da demanda por certificações na área, sejam elas profissionais ou
corporativas. Cláusulas contratuais, com base na lógica das certificações, ditam as
contratações de pessoas ou empresas.
Profissionais que atuam na área de Gerenciamento de Projetos, seja na área
empresarial ou educacional, sentem-se pressionados a obter estas certificações, como forma
de responder às exigências do mercado. Como por exemplo, não é incomum a contratação de
profissionais certificados que não correspondem às expectativas da organização.
Quem possui alguma experiência em Gerenciamento de Projetos, geralmente tem
consciência da importância da experiência como um dos fatores mais confiáveis para um bom
gerenciamento de projetos. E é exatamente isso que as certificações em metodologias e
modelos não conseguem assegurar. (BRADIE; DAVIES; 2004)
Com base nestas observações, até que ponto um comportamento similar não ocorre
com as organizações em certificações em gerenciamento de projetos: o objetivo é realmente a
busca por consistência nos seus processos de gerenciamento de projetos? Ou funcionam tão
somente como atestados de legitimidade perante um grupo de profissionais, clientes e
fornecedores.
Em paralelo às certificações profissionais, as certificações empresariais em
modelos de maturidade, que prometem garantir a consistência na habilidade em
gerenciamento de projetos nas empresas, vêm obtendo grande notoriedade, já que prometem
como objetivo atestar que os projetos de uma organização possam ter uma consecução mais
rápida, robusta e consistente.
Reconhece-se a importância da disseminação de conhecimento sobre a disciplina
de Gerenciamento de Projetos. Este passo é fundamental no auxílio às organizações no uso de
processos de gerenciamento dos projetos, sendo esta questão particularmente problemática ao
verificarmos os índices relacionados aos projetos em Tecnologia da Informação, que em sua
grande maioria não têm uma execução condizente com suas previsões de tempo, orçamento e
18

qualidade, definidas ao início do projeto. A problemática encontra-se na supervalorização da


certificação do conhecimento em detrimento de sua aplicação.
Particularmente no Brasil, a disciplina em Gerenciamento de Projetos é um
assunto imaturo, sem forte tradição nas organizações e na academia, levando à tendência de
importação de modelos, sem análise crítica de seu uso. Assim, organizações certificam-se um
tanto a esmo, sem analisar e verificar a aderência às suas necessidades.
Nosso país vem investindo cada vez mais na tentativa de atingir padrões
internacionais em seus projetos de produção de software, inclusive com apoio do Ministério
da Ciência e Tecnologia através do Programa Brasileiro da Qualidade e Produtividade em
Software, focando principalmente a exportação do software brasileiro. (MCT, 2007). Dentre
as iniciativas do governo brasileiro está a disseminação e o apoio na consecução da
certificação CMMI (Capability Maturity Model Integration), um dos modelos de maturidade
mais populares em gerenciamento de projetos, desenvolvido pela SEI (Software Engineering
Institute) da Carnegie Mellon University..
Buscando atingir uma perspectiva institucional da teoria de certificação em
gerenciamento de projetos, este trabalho, de natureza explanatória, investiga o processo de
certificação em modelos de maturidade em gerenciamento de projetos, de uma empresa
brasileira de software, certificada com o CMMI nível 2, verificando a presença de pressões
institucionais para a obtenção da certificação.
19

OBJETIVO

Esta dissertação tem por objetivo identificar indícios da presença de pressões


institucionais no processo de certificação de gerenciamento de projetos, e apresenta como
pergunta de pesquisa: há indícios de institucionalização no processo de certificação em
gerenciamento de projetos? O objeto e foco de pesquisa será a certificação no modelo de
maturidade em gerenciamento de projetos, o CMMI, em uma empresa produtora de software
brasileira.
O CMMI é um dos modelos de maturidade em projetos de maior popularidade e
difusão mundial, tendo servido de base para outros modelos de maturidade em meio aos anos
90. Sua tradição é fundamentada na melhoria dos processos de produção de softwares, através
de melhores práticas, iniciada pelo seu antecessor, o CMM (Capability Maturity Model),
descontinuado em 2006. Embora o CMMI não seja um modelo de maturidade exclusivo para
o desenvolvimento de software, devido as suas origens, ele ainda é constantemente visto
como tal, inclusive por pesquisadores. Sua imagem está atrelada ao processo de produção de
software a tal ponto que o modelo é considerado também um SPI (Software Process
Improvement) pela literatura de Engenharia de Software.
Para o caso, foi escolhida como caso uma empresa brasileira, de maneira a se
analisar os possíveis impactos desta questão, que possui como atividade fim a produção de
sistemas de informação.
Como objetivos específicos, este trabalho busca avaliar quais são os fatores
determinantes no processo de tomada de decisão que levam uma empresa a buscar uma
certificação em um modelo de maturidade, no caso o CMMI, e se dentre estes fatores
determinantes encontram-se pressões institucionais na forma dos mecanismos de isomorfismo
institucional, processo nos quais as organizações tornam-se semelhantes umas às outras em
busca de legitimidade. O isomorfismo apresenta-se através de três formas: isomorfismo
coercitivo, isomorfismo normativo e isomorfismo mimético.
Concomitantemente, aos aspectos da Teoria Institucional, também será investigado
se o processo de certificação em CMMI possui indícios de comportamento cerimonial e
ritualístico em busca apenas da conformidade em seus campos de atuação, em detrimento de
ganhos de eficiência.
20

Por fim, sob o ponto de vista acadêmico, como objetivo específico, buscou-se
estabelecer uma perspectiva institucional sobre a implantação e certificação em
gerenciamento de projetos.
21

JUSTIFICATIVA E CONTRIBUIÇÕES

A produção acadêmica sobre Gerenciamento de Projetos e Modelos de Maturidade


em Projetos é relativamente escassa e recente quando comparada a outros campos de estudo
em Administração de Empresas. Grande parte destes trabalhos está concentrada em periódicos
específicos da área, como o Project Management Journal ou International Journal of Project
Management.
Para Leroy (2006), apesar de ser uma área de estudos muito ampla, a pesquisa em
Gerenciamento de Projetos sofre resistência, principalmente devido à elaboração de trabalhos
a respeito de elementos finitos, ou seja, como são definidos os projetos, que se dissolvem ao
seu término.
Grande parte da produção bibliográfica a respeito de gerenciamento de projetos
concentra-se em livros com foco empresarial, sem preocupações acadêmicas e voltadas à
implantação de medidas prescritivas.
Ao avaliarmos os estudos sobre modelos de maturidade, a situação torna-se ainda
mais restrita. Staples et al.(2006) levantaram em sua pesquisa cerca de 600 artigos sobre o
CMM e o CMMI, encontrando na grande maioria, estudos post hoc de implantação e
avaliação de custos e benefícios.
O campo nacional de estudo reflete as características mundiais com ainda maior
ênfase no caráter prescritivo e na comparação de modelos ou avaliação de seu uso em estudos
de caso. Isto ocorre principalmente em relação a modelos de maturidade, como o CMMI,
produzidos geralmente por cursos em Engenharia de Software ou Produção, demonstrando
uma carência de estudos sobre o tema em Administração de Empresas. (RABECHINI e
PESSÔA, 2005; SATO, 2004).
O CMMI é um dos modelos de maturidade mais populares no país, o que podemos
verificar através de um crescente índice de participação do Brasil neste tipo de certificação.
No último relatório do SEI, publicado em setembro de 2007, com dados até junho do mesmo
ano, o Brasil encontra-se em 7º lugar dentre os países com maior número de avaliações
CMMI realizadas por esse instituto, como mostra Tabela 1 abaixo.
22

Tabela 1: Ranking do número de certificações CMMI


Posição País N° de certificações (1)
1º Estados Unidos 859
2º China 321
3º Japão 197
4º França 94
5º República da Coréia 87
6º Taiwan 71
7º Brasil 58
8º Reino Unido 57
9º Espanha 55
10º Alemanha 41
Fonte: SEI, 2006(B)b; p.16.
Nota: Dez primeiras posições no ranking
(1) Em Junho/2007

De acordo com o mesmo relatório, até Junho de 2007 o Brasil possuía ao todo 58
empresas com certificação CMMI em algum nível de maturidade e que foram reportadas para
a SEI.

Número de Certificações CMMI no Brasil


Dezembro/2004 a Junho/2007

70

60

50

40

30

20

10

0
2004/Dez 2005/Jun 2005/Dez 2006/Jun 2006/Dez 2007/Jun

Gráfico 1: Evolução do número de certificações CMMI no Brasil.


Fonte: (SEI, 2007a, p.16; SEI, 2007b, p.15, SEI, 2006a, p.15; SEI, 2006c, p.15; SEI, 2005a,
p.15; SEI, 2005b, p.15)
23

Com o aumento da participação do Brasil nas certificações CMMI, surge a


necessidade de ampliarmos o campo de estudos em modelos de maturidade em projetos,
buscando uma alternativa aos estudos prescritivos. É necessária a geração de uma discussão
crítica a respeito deste tema: investigar se estes esforços na obtenção da certificação buscam
realmente a eficiência e a eficácia no gerenciamento dos projetos das empresas ou é parte de
tentativa de legitimação e conformidade em relação aos seus campos de atuação, conforme os
conceitos da Teoria Institucional.
Este trabalho busca contribuir academicamente para o corpo de conhecimento em
gerenciamento de projetos, principalmente através da análise das teorias em Gerenciamento
de Projetos e modelos de maturidade em Gerenciamento de Projetos, no caso CMMI, através
de uma perspectiva institucional, buscando o enriquecimento do corpo teórico atual, voltado
para questões de caráter técnico ou prescritivo.
Empresarialmente, este trabalho visa contribuir para uma maior consciência dos
direcionadores das tomadas de decisão por parte das empresas em relação ao processo de
certificação em Gerenciamento de Projetos e sua utilização como critério em processos de
avaliação de fornecedores.
24

REVISÃO DA LITERATURA

1.1. GERENCIAMENTO DE PROJETOS

A palavra “projetos” é uma das muitas terminologias que acabaram sendo


banalizadas no contexto das empresas, sendo muito empregadas e de maneira errônea,
fazendo com que o conceito perca sua força e significado. (MENEZES, 2003)
Para o PMI (Project Management Institute; 2004), projetos são temporários e
visam a consecução de um produto, serviço ou resultado único com desenvolvimento
progressivo, ou seja, desenvolvido por passos incrementais. Em alinhamento com o PMI,
projetos são para Kerzner1 (apud ALBERTIN, 2001, p.45): “temporários e únicos, ou seja,
eles são finitos e regulares, visando ao desenvolvimento de um novo produto ou serviço”.
Dinsmore e Cabanis-Brewin (2006) definem um conjunto de características para a definição
de projetos: são empreendimentos únicos, compostos por atividades interdependentes,
envolvendo múltiplos recursos, com uma entrega de qualidade: um produto, que não deve ser
confundido com o projeto. Segundo Menezes (2003, p.43), um projeto é: “um
empreendimento único que deve apresentar um início e um fim claramente definidos e que
conduzido por pessoas possa atingir seus objetivos respeitando os parâmetros de prazo, custo
e qualidade”.
É fundamental que uma organização saiba distinguir entre suas atividades
rotineiras e seus projetos, para que desta forma sejam empregadas técnicas e ferramentas
adequadas a cada situação. (ALBERTIN, 2001, KERZNER, 2002, MENEZES, 2003, PMI,
2004).
A tabela a baixo resume estas diferenças:

1
KERZNER, H. Project management: a systems approach to planning, schedulling and controlling. New York:
Van Nostrand Reinhold, 1995.
25

Atividades rotineiras Projetos


Os objetivos são contínuos Encerra-se quando um objetivo
Objetivos
é atingido.
O horizonte de tempo é O horizonte de tempo é
Horizonte de tempo
contínuo. limitado
Segurança e permanência em Os recursos são alocados
Recursos humanos suas posições. apenas durante a vigência do
projeto.
São repetitivas. Encerra-se com o final do
Cronologia
projeto.
Conhecimento As atividades são conhecidas O conteúdo é inovador e exige
prévio do trabalho e dominadas. estudos específicos.
Singular, com pequenas Muitas variações de
Abrangência variações. ferramentas exigindo
multidisciplinaridade.
Admitem certa flexibilidade As atividades são pré-
nos prazos. determinadas, respeitam uma
Prazos
ordem de execução e prazos
rígidos.
Ritmo de gastos uniformes. Tipos e ritmos de gastos
Orçamento
variáveis.
Uso de controles rígidos Uso de controles flexíveis,
Qualidade
definidos caso a caso.
Quadro 1: Diferenças entre projetos e atividades rotineiras.
Fonte: adaptado de MENEZES, 2003, p. 37.

O esforço organizacional organizado e administrado para execução dos projetos é


denominado Gerenciamento de Projetos. Segundo o PMI (2004) o Gerenciamento de Projetos
envolve um contexto mais amplo do que a gestão de um único projeto. Este contexto é
formado por gerenciamento de projetos e subprojetos, gerenciamento de programas e
gerenciamento de portfólios. Entres estes elementos é estabelecida uma hierarquia, conforme
figura abaixo:
26

Plano Estratégico

Portfólios

Programas

Projetos

Subprojetos

Esquema 1: O contexto em gerenciamento de projetos


Fonte: elaboração própria.

Os projetos podem ser divididos em partes gerenciáveis menores, os chamados


subprojetos. Cada subprojeto pode ser referido como um projeto e deve ser gerenciado como
tal. Geralmente subprojetos são destinados a empresas externas ou unidades organizacionais
específicas, devido à necessidade de habilidades ou tecnologias específicas. Um conjunto de
projetos relacionados e coordenados de forma a obter benefícios e controles de forma
sinérgica, é chamado de programa. Por sua vez, um conjunto de projetos ou programas
agrupados de forma a facilitar o gerenciamento e atingir os objetivos organizacionais de
forma facilitada é chamado portfólio de projetos. (PMI, 2004)
Entretanto é preciso ressaltar que esta configuração à cima não está presente em
todas as organizações, mesmo naquelas que trabalham com gerenciamento de projetos.
Em empresas sem orientação para projetos, encontramos a fragmentação do
trabalho, que dificulta a alocação apropriada de recursos quando se necessita de um
empreendimento com participação de várias unidades. Desta maneira, na realização de um
projeto podemos identificar como efeitos mais freqüentes (MENEZES, 2003):
• os projetos não possuem os mesmos requisitos, não sendo então geridos da
mesma forma, o que dificulta uma padronização que facilite a execução dos
projetos;
• dificuldade na condução de projetos de maneira participada, com resistências
por parte da organização a investir em treinamento em Gerenciamento de
Projetos;
• executivos atribulados com a “integração na pirâmide organizacional” sem
tempo para gerir seus projetos e se recusando a delegá-los;
27

• atrasos nos projetos devido ao percurso que todas as aprovações demandam


dentro da estrutura hierárquica.
• os projetos têm de competir pela atenção dos colaboradores com as atividades
rotineiras em suas áreas;
• com a concentração do grupo de projetos em determinadas áreas, a
compreensão da gerenciamento do projeto e seu andamento fica restrito a parte
da empresa;
• dependência de terceiros e agentes externos com experiência em
gerenciamento de projetos.

1.1.1. CICLO DE VIDA DO PROJETO

Projetos são definidos como empreendimentos finitos, e que, portanto possuem


início e fim definidos. Com base nesse aspecto, podemos estabelecer o conceito de um ciclo
de vida de um projeto. Conhecer o ciclo de vida de um projeto é fundamental para uma
melhor compreensão do projeto e conseqüentemente para sua melhor gestão. (MENEZES,
2003; PMI, 2004)
O ciclo de vida de um projeto demonstra a evolução dos esforços em seu
desenvolvimento, através do consumo de recursos ao longo de suas quatro fases, sendo estas:
• Conceitual: fase inicial do projeto que marca sua concepção até a aprovação de
sua proposta. Nesta fase são identificadas necessidades e oportunidades, que
são traduzidas em um problema. Este problema é equacionado e definido,
assim como os objetivos e metas relacionados à resolução deste problema. São
estimados recursos necessários, potencialidades do projeto, viabilidade dos
objetivos. É elaborada uma proposta que é apresentada e avaliada, levando ao
aceite ou não do projeto.
• Planejamento: nesta fase o foco é a estruturação do projeto, traduzindo a
proposta do projeto em um plano operacional. Aqui é escolhido o gerente de
projetos. São detalhados as metas e objetivos, e, conseqüentemente, as
atividades a serem realizadas, juntamente com a programação de tempo,
recursos humanos e financeiros necessários para a consecução destas
atividades. Também são determinados os marcos do projeto, nos quais
28

resultados tangíveis deverão ser atingidos e apresentados. Os procedimentos de


acompanhamento e controle e os sistemas de comunicação e decisão são
definidos e treina-se adequadamente todos os envolvidos no projeto. Em
resumo, estabelece-se a estrutura formal do projeto.
• Execução: fase de execução do projeto, na qual é necessário o estabelecimento
da comunicação entre os membros da equipe de projetos e os stakeholders para
realizar as atividades programadas. Entretanto, ao longo da execução,
eventualmente é necessário corrigir os planos de acordo com mudanças,
utilizando os planos iniciais como diretrizes.
• Conclusão: fase de término do projeto, na qual atividades não concluídas são
aceleradas, e há realocação de parte dos recursos humanos para outras
atividades. É imprescindível nesta fase que sejam elaborados o relatório de
memória técnica, os resultados finais e as lições aprendidas, pois estes servirão
como base para desenvolvimento de projetos futuros.
A definição do ciclo de vida de um projeto permite que haja uma previsão do
consumo de recursos por etapa e também serve como um anteprojeto, um instrumento para
aprofundar idéias. (MENEZES, 2003; PMI, 2004)

1.1.2. OS STAKEHOLDERS

Segundo o PMI (2004), os stakeholders de um projeto são definidos como


organizações ou indivíduos que estão diretamente envolvidos na execução do projeto ou cujos
interesses estão atrelados a consecução do projeto. Estas organizações ou indivíduos possuem
diferentes níveis de responsabilidade e autoridade sobre um projeto, que podem variar durante
os ciclos de vida de um projeto.
Nem sempre é fácil identificar todos os stakeholders de um projeto, o que pode
tornar-se um problema durante sua condução, já que estes podem ter influências tanto
positivas quanto negativas sobre um projeto. Stakeholders positivos são aqueles que obterão
benefícios com a consecução de um projeto, ao passo que os negativos são aqueles que
enxergam resultados negativos. Particularmente estes últimos são negligenciados pelas
equipes de projetos, o que pode acarretar sérios problemas.
29

São considerados os principais stakeholders de um projeto (PMI, 2004;


MENEZES, 2003):
• Gerente de projeto: responsável pelo gerenciamento do projeto, é o grande
condutor do processo, respondendo pelos resultados intermediários e finais do
projeto;
• Patrocinador: Pessoa ou grupo que suporta o projeto, funcionando como um
facilitador do projeto, resolvendo conflitos, garantindo sua prioridade e
importância dentro da organização e assegurando os recursos necessários ao
projeto.
• Equipe básica: profissionais responsáveis pelas atividades do projeto e pelas
atividades de gerenciamento do projeto.
• Clientes: indivíduos ou organizações que utilizarão o resultado final do
projeto.
• Influenciadores: indivíduos ou organizações que não estão envolvidos
diretamente com o uso do produto final do projeto, mas podem interferir
positiva ou negativamente em seu andamento.
A atual literatura em gerenciamento de projetos coloca o gerenciamento do
relacionamento com os stakeholders como um dos principais fatores de sucesso de um
projeto. (JUDGEV; MÜLLER, 2005)

1.1.3. COMPETÊNCIAS EM GERENCIAMENTO DE PROJETOS

O Gerenciamento de Projetos possui características próprias e requere


competências específicas. (RABECHINI; PESSÔA, 2005). Para aprimorar-se na competência
de gerir projetos é necessário um profundo conhecimento de conceitos e características
próprias e, também, das particularidades e fatores críticos de sucesso específicos a esta
finalidade. (PMI, 2004)
De acordo com Frame (1999) são três as competências em gerenciamento de
projetos:
• Competências individuais: foco nas habilidades dos indivíduos no
gerenciamento dos projetos, com ênfase na atuação do gerente de projetos;
30

• Competências de equipe: foco na capacidade dos membros da equipe de


projetos em resolver problemas com alto grau de complexidade e de natureza
multidisciplinar;
• Competências da organização: habilidade da organização em desenvolver um
ambiente capaz de suportar os indivíduos e equipe para realização do
gerenciamento dos projetos de forma eficaz.
Para o PMI (2004), as competências das equipes de gerenciamento em projetos
devem abranger pelo menos cinco áreas de expertise:
• Conhecimento do PMBOK (Project Management Body of Knowledge) – um
corpo de conhecimento em gerenciamento de projetos desenvolvido pelo PMI;
• Conhecimentos, padrões e regulamentos específicos da área ao qual pertence o
projeto;
• Entender o ambiente de projetos, que envolve questões culturais e sociais,
ambiente político (internacional, regional, nacional, quando necessários) e o
ambiente físico propriamente dito;
• Conhecimentos e habilidades gerais em administração: recursos humanos,
finanças, tecnologia da informação, compras, comercial, etc.;
• Habilidades interpessoais em comunicação, influência, liderança, motivação,
negociação e resolução de problemas.
Torna-se particularmente importante a questão da capacitação em Gerenciamento
de Projetos quando as empresas passam de um estágio de projetos tradicionais para novas
linhas de negócios que exigem novas maneiras de organizar e gerenciar projetos. (BRADY;
DAVIES, 2004).

1.1.4. OS PROJETOS EM TECNOLOGIA DA INFORMAÇÃO

O desenvolvimento e implantação de projetos em Tecnologia de Informação


trazem profundas mudanças às empresas, e, para garantia do seu sucesso, é preciso que haja
planejamento e preparação. A instrumentação da TI se dá a partir da implantação de projetos.
(ALBERTIN, 2001)
31

Nesse processo de planejamento e preparação, surgem variáveis que devem ser


analisadas para garantir um cenário positivo ao gerenciamento de projetos, conforme quadro a
seguir (ALBERTIN, 1996):

O nível de utilização da Tecnologia de


Informação por parte de uma empresa é
Histórico da
constituído através de sua história ao longo do
Organização
tempo; para obter sucesso a empresa deve estar
preparada para a implementação.
A empresa deve saber aonde quer chegar e
Estratégia de
como chegar e qual o papel da Tecnologia de
Negócios
Informação na consecução deste objetivo.
A empresa deve considerar e perceber a
Cenário Importância do
Tecnologia de Informação como importante
Projeto
para a organização.
Os conflitos devem ser entendidos e
minimizados, caso contrário os projetos de
Conflitos
Tecnologia de Informação tendem a refletir
estes conflitos.
Deve haver consciência de que a implantação
de projetos em Tecnologia de Informação
Recursos demanda recursos, que devem ser controlados
tanto quanto os benefícios obtidos em sua
decorrência.
A alta gerência é responsável por manter a
continuidade e os recursos necessários para um
projeto, caso não haja seu apoio há grandes
Apoio da Alta
chances de fracasso. É preciso também que a
Gerência
alta gerência deixe de maneira clara seu apoio
ao projeto em relação a sua importância à
estratégia da empresa.
O projeto deve possuir um executivo que
demonstre a importância do projeto e garanta
Patrocinador
sua continuidade, resolvendo possíveis
Atores conflitos.
A equipe deve trabalhar coesa com o objetivo
Equipe
do projeto e também com seus patrocinadores.
A experiência e capacitação dos usuários
Usuários devem ser compatíveis com o projeto de
Tecnologia de Informação em execução.
Os envolvidos devem ter capacidade técnica e
funcional compatível com a Tecnologia de
Informação em questão ou deve haver um
Capacitação plano para desenvolvê-las em tempo hábil.
32

Os impactos devem ser previamente estudados


Impactos sociais e trabalhados, buscando esclarecer, envolver,
eliminar dúvidas e facilitar o processo.
Com base nos conhecimentos da organização e
Estratégia de
nos impactos futuros devem ser formuladas
Intervenção
estratégias de intervenção.
Planejamento Com base nos conhecimentos da organização e
impactos futuros devem ser formulados planos
da Intervenção Prevenção
contra possíveis barreiras e vencer as
existentes.
Toda a organização deve conhecer a
Esclarecimento e
importância do projeto e ser envolvida em seus
envolvimento
pontos relevantes.
O planejamento da intervenção deve
Disseminação e considerar a disseminação da Tecnologia de
desmistificação Informação, bem como sua desmistificação e
diminuição de resistências.
Quadro 2: Pontos críticos na gestão de projetos
Fonte: ALBERTIN, 1996, p. 68.

Segundo o Standish Group (2004), embora pesquisadores, instituições e empresas,


num esforço conjunto, busquem identificar meios de tornar o gerenciamento de projetos mais
eficiente, cerca de 20% dos projetos em Tecnologia da Informação são cancelados antes do
seu término, e menos de um terço são completados no tempo, orçamento e funcionalidades
previamente determinadas. Se a amostra destes projetos for restrita aos projetos considerados
mais arriscados, com cerca de 10.000 funções, a taxa de cancelamento dobra.
Com base numa survey realizada com 55 gerentes de projetos e um painel com 19
experts no assunto, Kapellman, McKeeman e Zhang (2006) obtiveram os 12 maiores fatores
de riscos em projetos em Tecnologia de Informação, com base no que os pesquisadores
chamam de EWS – Early Warning Signs, ou seja, indicadores de risco que possam indicar
dificuldades e fracassos nos projetos no futuro.
Kapellman, McKeeman e Zhang (2006) dividem os 12 EWS´s em duas categorias:
riscos relacionados a processos e riscos relacionados a pessoas, conforme quadro a seguir.
33

Riscos relacionados a pessoas Riscos relacionados a processos


Falta de apoio da Alta Gerência: os Falta de documentação de requisitos e/ou
empregados de uma organização tendem a critérios de sucesso: se requisitos
focar seus esforços em atividades que seus funcionais, de performance e confiabilidade
gestores supõem serem importantes; não estão documentados, então cada um
dos participantes do projeto (gerente de
projetos, equipe de projetos, stakeholders)
terá uma expectativa e concepção diferente
em relação ao produto final, o que pode
gerar um enorme conflito no ato da entrega
final.
Gerentes de projetos fracos: gerentes de Não há processo de controle de mudanças:
projetos que não conseguem liderar ou A mudança é inevitável, logo, todo projeto
realizar uma comunicação eficiente colocam deve ter um processo de controle de
o projeto em risco. mudanças.
Falta ou ausência de envolvimento dos Planejamento e/ou gerenciamento não é
stakeholders: os stakeholders devem estar efetivo: se os marcos do projeto e datas
informados e serem envolvidos no projeto, combinadas não são documentados, haverá
de forma a auxiliarem na garantia de que o uma série de opiniões a respeito do que
projeto receberá os recursos necessários para deve ser feito e quando. A equipe de
sua consecução no prazo, qualidade e custos projetos deve compreender que atividades
previstos. de curto prazo estão relacionadas aos
objetivos de longo prazo.
Falta de comprometimento da equipe de A comunicação é confusa entre os
projetos: se os indivíduos das equipes de stakeholders: os projetos possuem diversos
projetos não estiverem comprometidos com o stakeholders e requer a coordenação de
projeto, sempre encontrarão outras atividades diversas tarefas e recursos. A mudança é
para realizarem, comprometendo assim o inevitável durante o projeto, portanto se os
andamento do projeto. Os objetivos de um stakeholders não forem envolvidos nos
projeto devem ir ao encontro de objetivos trabalhos, o trabalho pode perder o foco, de
pessoais. acordo com os interesses de cada grupo.
Falta de conhecimentos ou habilidades de Recursos são realocados para projetos de
membros das equipes de projetos: gera maior prioridade: se os recursos forem
problemas diretos em relação à mitigação dos alocados para outros projetos, é improvável
riscos dos projetos, assim como o uso de que a consecução corra conforme
novas tecnologias e complexidades. Se o planejado. Há a opção de trabalhar com
conhecimento não existe inicialmente, é maior eficiência com os recursos restantes,
papel do gerente de projetos garantir com que se o projeto já foi definido com altos
ele seja adquirido. padrões de eficiência, esta opção torna-se
inviável.
Assuntos que demandam especialistas estão Não existe um business case do projeto: a
mal agendados: é irreal esperar que os falta de um business case para o projeto,
especialistas das áreas que vão fornecer diminui as possibilidades de apoio da alta
informações e guias para a condução dos gerência, e enfatiza a falta de critérios de
projetos conseguirão efetuar esta tarefa sucesso do projeto, diminuindo suas
enquanto trabalham em suas atividades chances em obter recursos e atenção da
rotineiras dentro de suas áreas. gerência.
Quadro 3: Os “Early Warning Signs”
Fonte: adaptado de KAPPELMAN; McKEEMAN; ZHANG, 2006, p. 32.
34

1.1.5. SUCESSO

Embora seja fácil identificar um projeto que tenha fracassado, dentro do campo de
estudos em gerenciamento de projetos não há um consenso a respeito do conceito de sucesso
em gerenciamento de projetos (BACCARINI, 1999; COOKE-DAVIES, 2002; JUDGEV;
MÜLLER, 2005; KEZNER, 2002). Inicialmente, um projeto entregue no prazo definido, no
orçamento estipulado e com a qualidade acordada era considerado bem sucedido. Entretanto,
com o tempo, esta passou a ser mais uma medida de eficácia do que propriamente de sucesso.
Para identificar o sucesso de um projeto, foi estabelecida a diferença entre o
sucesso no processo de gerenciamento de projeto, relacionado à condução do projeto em si, e
o sucesso do produto, relacionado ao produto final, resultado do projeto. (De WIT2 apud
COOKE-DAVIES, 2002) Embora haja esta diferença, Baccarini (1999) estabeleceu relações
entre o sucesso de ambos:
• projetos podem ser bem sucedidos, enquanto seu produto não, e vice-versa;
• a percepção faz com que o sucesso do gerenciamento de projetos esteja
subordinado ao sucesso do produto;
• o sucesso no gerenciamento de um projeto influi no sucesso de um produto;
• o sucesso em gerenciamento de projetos medidos em termos de custo, prazo e
qualidade tendem a atender interesses de grupos internos à organização, ao
passo que o sucesso de um produto está relacionado a grupos de interesse
externos.
Cleland e Ireland (2002) estabelecem o conceito de sucesso a partir de dois pontos:
o nível técnico no qual um projeto é realizado – em termos de custo, prazo e qualidade - e as
contribuições de um projeto para atingir a missão estratégica da empresa.
Kezner (2002) define o sucesso em projetos como um composto de fatores
primários e fatores secundários:
• fatores primários: são intrinsecamente ligados ao projeto - cumprimento do
prazo, orçamento e qualidades estipulados;

2
De Wit, A. Measurement of project success. International Journal of Project Management,
v.6, 1988.
35

• fatores secundários: relacionados a fatores externos ao projeto - aceitação por


parte do cliente, sucesso financeiro, alinhamento estratégico, saúde e
segurança, proteção ambiental, conduta ética, etc.
Para Cooke-Davies (2002), o conceito do sucesso em projetos é definido pela
resposta a três questões:
• Quais fatores são críticos para o sucesso do gerenciamento do projeto?
• Quais fatores são críticos para o sucesso individual do projeto?
• Quais fatores levarão a um sucesso constante nos projetos?
Baccarini (1999), por sua vez, estabelece que os critérios para definição do sucesso
são compostos tanto por elementos mensuráveis e objetivos quanto por critérios subjetivos. A
noção de sucesso tem relação com a percepção, pois cada stakeholder tem seu ponto de vista
dependendo de suas necessidades. O sucesso pode ser atingido parcialmente, e para o autor,
não é sempre gerenciável.
Judgev e Muller (2005), analisaram cerca de 40 anos de pesquisa sobre sucesso em
gerenciamento de projetos, apresentando uma progressão natural das pesquisas, iniciando
desde os estudos iniciais de implementação de projetos, entre os anos 60 e 80, passando pelas
listas de fatores críticos de sucesso – entre os anos 80 e 90, e os “frameworks” de fatores
críticos de sucesso – entre os anos 90 e 00, até as abordagens mais atuais, a partir do século
21, que possuem uma natureza holística.
Hoje já se sabe que o conceito de sucesso de um projeto envolve além de uma
missão comum, e do apoio da alta gerência para recursos, autoridade e poder; que os fatores
críticos de sucesso incluem o comprometimento da alta gerência em prover visão estratégia e
patrocínio; que os fatores de sucesso aplicam-se a questões internas e externas, que a alta
administração é responsável por garantir a ligação entre os planos organizacionais e as metas
e objetivos dos projetos selecionados e pelo processo criativo para um projeto. (JUDGEV;
MÜLLER, 2005)
Para os autores, nas pesquisas atuais em gerenciamento de projetos, temos quatro
condições necessárias, porém ainda não suficientes, para garantir o sucesso de um projeto:
• os critérios de sucesso devem ser definidos com os stakeholders antes do início
do projeto, e revistos ao longo dos pontos de revisão do projeto;
• deve haver um trabalho colaborativo entre o dono do projeto (ou patrocinador)
e o gerente de projetos, devendo funcionar como uma sociedade;
36

• o gerente de projetos deve ter poder para poder lidar com circunstancias
imprevistas, da melhor maneira possível, com o patrocinador guiando-o sobre
como o projeto deve ser concluído;
• o patrocinador deve ter interesse na performance do projeto.
A evolução das pesquisas em gerenciamento de projetos, rumo a uma natureza
holística, vem buscando elevar o gerenciamento de projetos de um nível tático para um nível
estratégico.

1.2. AS INSTITUIÇÕES EM GERENCIAMENTO DE PROJETOS

Com atuação global, duas grandes instituições polarizam o conhecimento em


gerenciamento de projetos no mundo: o PMI – Project Management Institute, de origem
americana e o pelo IPMA – International Project Management Association, de origem
européia. O objetivo destas instituições é a divulgação dos conhecimentos em Gerenciamento
de Projetos, a difusão das melhores práticas e a formação de uma comunidade de profissionais
da área.
O PMI foi fundado em 1969 na Pensilvânia, EUA, por cinco voluntários. No
mesmo ano ocorreu o primeiro Simpósio, em Atlanta, Geórgia, com 83 participantes. Hoje é a
principal associação mundial em Gerenciamento de Projetos com cerca de 170.000 associados
em 150 países.
O PMI funciona através de chapters (ou capítulos). Os chapters são unidades
regionais do PMI com o objetivo de criar uma comunidade em Gerenciamento de Projetos e
divulgar e fortalecer os princípios do PMI.
O Brasil teve o 1° chapter fora dos EUA, no início da década dos anos 80, mas foi
destituído em 1984. No final dos anos 90, o Brasil voltou a ter um chapter, através de São
Paulo. O país passaria, ao longo do tempo, a ter vários chapters, devido à sua proporção
continental, possuindo atualmente 13 deles.
O IPMA foi estabelecido na Suíça há 40 anos e possui forte tradição européia.
Sua estrutura é composta por Associações Nacionais que são responsáveis por
estabelecer a sua própria definição de competências, os chamados NCBs (National
Competence Baseline), as quais devem ser conformes com o ICB (International Competence
Baseline) e levarem em consideração as especificidades culturais de cada país. Também foi
37

seu objetivo harmonizar os diversos corpos de conhecimentos europeus existentes até então,
vindos do Reino Unido, França, Alemanha e Suíça.
O ICB descreve as áreas de qualificação da competência em Gerenciamento de
Projetos, bem como a taxonomia utilizada para a avaliação do conhecimento, experiência e
atitude pessoal dos profissionais de Gerenciamento de Projetos. É formado por 28 elementos
principais que não estão agrupados, mas estão num arranjo conhecido como “O girassol”, com
28 pétalas saindo de um núcleo. Estes 28 elementos são requisitos obrigatórios em cada um
dos NCBs. Há também mais 14 elementos sobre Gerenciamento de Projetos e experiências,
totalizando um total de 42 elementos;
No Brasil, o IPMA é representado pela ABGP – Associação Brasileira de
Gerenciamento de Projetos, afiliado desde Junho de 2002, que é responsável pela elaboração
do RBC – Referencial Brasileiro de Competências, versão brasileira do ICB

1.2.1. AS METODOLOGIAS EM GERENCIAMENTO DE PROJETOS

Nesta seção serão apresentadas as metodologias elaboradas pelo PMI, o PMBOK


(Project Management Book of Knowledge) e o RCB (Referencial Brasileiro de Competências)
elaborado pela ABGP (Associação Brasileira de Gerenciamento de Projetos) representante
nacional do IPMA. Além disso, será apresentada a metodologia PRINCE2 (PRojects IN
Controlled Environments) elaborada pelo governo do Reino Unido, que também serve de base
para uma certificação profissional.

1.2.1.1. O PMBOK - Project Management Book of Knowledge

Uma das principais produções do PMI é o PMBOK – Project Management Book


of Knowledge, que teve sua primeira versão lançada em 1981. De acordo com o PMI, o
PMBOK não é uma metodologia, mas um corpo de conhecimento sobre a disciplina de
Gerenciamento de Projetos, um guia contendo todas as áreas de conhecimento do
gerenciamento de projetos. As práticas estão compiladas em formato de um guia, chamado de
Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, ou Guia PMBOK.
38

Segundo o PMBOK (PMI, 2004), o gerenciamento de projetos é resultado da


interação entre um conjunto de processos. Estes processos são necessários a quaisquer
projetos, e são classificados em cinco grupos:
• Processos de iniciação: autorização para o projeto;
• Processos de planejamento: definição e seleção das ações e alternativas a
serem tomadas para o cumprimento dos objetivos estabelecidos pelo projeto;
• Processos de execução: coordenação de pessoas e recursos para condução do
projeto;
• Processos de controle: estabelecer medidas e pontos de monitoramento
regulares para verificação do andamento do projeto e definição de ações para
correção se necessários;
• Processos de finalização: aceitação formal do projeto, com cumprimento dos
objetivos.

Durante o gerenciamento de projetos, estes processos muitas vezes se sobrepõem e


interagem uns com os outros, de acordo com a figura abaixo:

Controle

Planejamento

Final
Início

Execução

Esquema 2: Os processos em Gerenciamento de Projetos


Fonte: PMI, 2004, p.40.
39

Este ciclo de processos é baseado no ciclo PDCA (Plan-Do-Control-Act)


desenvolvido por W. Shewart e William Deming, sendo hoje “um ícone para os planos de
melhoramento contínuo em operações”. Ao identificar um problema ou oportunidade de
melhoria, devem ocorrer as fases de 1) planejar – avaliação do problema, formas de resolução
e impactos; 2) fazer – implantar o plano de forma experimental; 3) controlar – avaliação do
plano implantado e 4) agir – implantação do plano com correções necessárias, em seqüência e
de maneira contínua. (CORRÊA; CORRÊA, 2004)
Cada um dos processos possui inputs e outputs, sendo ao todo 44 processos de
gerenciamento de projetos, que estão agrupados em 9 áreas do conhecimento que dividem o
Gerenciamento de Projetos: (Kerzner, 2002; PMI, 2004)
• Gerenciamento integrado de projetos: é composto por processos e atividades
que identificam, definem, combinam, unem e coordenam outros processos e
atividades no gerenciamento de projetos;
• Gerenciamento de escopo: o que está contemplado pelo projeto e o que não
está;
• Gerenciamento de prazo: quais são os prazos intermediários do projeto que
impactarão no prazo final de entrega, monitoramento e controle dos prazos;
• Gerenciamento de custo: orçamento do projeto e monitoramento e controle dos
custos;
• Gerenciamento de qualidade: definição de mecanismos de controle;
• Gerenciamento de recursos humanos: estabelecimento de funções e
responsabilidades e alocações,
• Gerenciamento de comunicação: estabelecimento da comunicação entre a
equipe de projetos e da externa, com todos os envolvidos no projeto;
• Gerenciamento de risco: estabelecimento de prioridades e avaliação de riscos;
• Gerenciamento de aquisição/compras: inclui os processos para aquisição ou
compra de produtos, serviços ou resultados necessários para a consecução do
projeto.
O quadro 4 sintetiza os processos de cada uma das nove áreas.
40

Áreas do conhecimento Processos


Desenvolvimento do Project Charter
Desenvolvimento do estatuto preliminar de escopo
Desenvolvimento do plano de gerenciamento de
Gerenciamento integrado de
projetos
projetos Direção e gerenciamento da execução do projeto
Monitoramento e controle do trabalho do projeto
Controle integrado de mudanças
Encerramento do projeto
Planejamento do escopo
Definição do escopo
Gerenciamento de escopo Criação do EAP – Estrutura Analítica de Projeto.
Verificação do escopo
Controle do escopo
Definição de atividades
Ordenação em seqüência das atividades
Gerenciamento de prazo Estimativa de recursos das atividades
Estimativa de duração das atividades
Desenvolvimento de cronograma
Controle de cronograma
Estimativa de custo
Gerenciamento de custo Estimativa de orçamento
Controle de custos
Planejamento da qualidade
Gerenciamento de qualidade Garantia da qualidade
Controle da qualidade
Planejamento de recursos humanos
Gerenciamento de recursos
Aquisição da equipe de projetos
humanos Desenvolver a equipe de projetos
Gerenciar a equipe de projetos
Planejamento da comunicação
Gerenciamento de comunicação Distribuição de informação
Reportes
Gerenciamento de stakeholders
Planejamento de risco
Identificação de riscos
Gerenciamento de risco Análise qualitativa de riscos
Análise quantitativa de riscos
Planejamento de resposta ao risco
Monitoramento e controle de riscos
Planejamento de compras e aquisições
Planejamento de contratações
Gerenciamento de
Requisitar orçamento de fornecedores
aquisição/compras Selecionar fornecedores
Administração de contrato
Encerramento de contratos
Quadro 4: As nove áreas do conhecimento e respectivos processos
Fonte: PMI, 2004, p.11.
41

Atualmente, o Guia PMBOK encontra-se na 3ª versão, lançada em 2004,


funcionando como a base de conhecimento para aquisição da certificação PMP (Project
Management Professional). O PMBOK possui alta difusão e tornou-se referência como
padrão em conhecimento em Gerenciamento de Projetos, servindo de base inclusive para
diversas outras metodologias e corpos de conhecimento em gerenciamento de projetos.
(DINSMORE; CABANIS-BREWIN, 2006)

1.2.1.2. O RBC - Referencial Brasileiro de Competências

O RBC – Referencial Brasileiro de Competências é a versão brasileira do ICB


(International Competence Baseline) e é composto por:
• elementos base: 28 ao todo, comuns a todos os NCBs (National Competence
Baseline);
• elementos adicionais: 6 pertencentes ao ICB (International Competence
Baseline);
• elementos adicionais específicos: 3 pertencentes especificamente à versão
brasileira;
• atitudes pessoais: 8 elementos relacionados a aspectos comportamentais e
características de personalidade.
Cada um dos elementos possui uma conceituação, as exigências de conhecimento
teórico sobre o elemento e as exigências de experiência prática com o elemento.

Elementos base
1. Projetos e Gerenciamento do Projeto;
2. Implementação do GP;
3. Gerenciamento por Projetos;
4. Abordagem Sistêmica e Integração;
5. Contexto do Projeto;
6. Fases e ciclo de vida do projeto;
7. Desenvolvimento e avaliação do projeto;
8. Objetivos e estratégias do Projeto;
9. Critérios de sucesso e insucesso do projeto;
10. Iniciação do projeto;
11. Encerramento do projeto;
12. Estruturas do projeto;
42

Elementos base
13. Conteúdo e escopo;
14. Programação de tempo;
15. Recursos;
16. Custos e financiamento do projeto;
17. Configurações e modificações;
18. Riscos do projeto;
19. Medidas de desempenho;
20. Controle do projeto;
21. Informação documentação e reporting;
22. Organização do projeto;
23. Trabalho em equipe;
24. Liderança;
25. Comunicação;
26. Conflitos e crise;
27. Aquisições e contratos;
28. Qualidade do Projeto.
Elementos adicionais
1. Informática em projetos;
2. Normas e regulamentações;
3. Negociações e reuniões;
4. Marketing e gerenciamento de produtos;
5. Segurança, saúde e meio ambiente;
6. Aspectos legais.
Elementos adicionais específicos
1. Gestão da cadeia de suprimentos;
2. Trabalho colaborativo à distância;
3. Gestão do conhecimento em projetos.
Atitude pessoal
1. Capacidade de comunicação;
2. Iniciativa, engajamento, entusiasmo, capacidade de motivação;
3. Capacidade de fazer contatos, mente aberta;
4. Sensibilidade, auto-controle, habilidade em reconhecer valores, prontidão
para assumir responsabilidades, integridade pessoal ;
5. Resolução de conflitos, cultura de argumentação, imparcialidade;
6. Habilidade em encontrar soluções, pensamento holístico;
7. Lealdade, solidariedade, prontidão em ajudar;
8. Capacidade de liderança.
Quadro 5: Resumo da estrutura do RBC
Fonte: adaptado de SANTOS; CARVALHO, 2006, p.16.

O Referencial Brasileiro de Competências em Gerenciamento de Projetos, segue as


normas referentes a todos os ICBs. Entretanto, numa análise comparativa a outras
metodologias em Gerenciamento de Projetos, seu foco está bastante voltado à instrumentação,
com objetivo em obter a certificação profissional.
43

1.2.1.3. O PRINCE2 (PRojects IN Controlled Environments)

O PRINCE2 (PRojects IN Controlled Environments) é uma metodologia baseada


em processos para o gerenciamento de projetos. O PRINCE2 é um padrão utilizado pelo
Governo do Reino Unido e é amplamente reconhecido no setor privado.
O PRINCE2 foi estabelecido em 1989 pelo CCTA (The Central Computer and
Telecommunications Agency), então renomeado OGC (The Office of Government Commerce).
PRINCE foi originalmente baseado no PROMPT, uma metodologia em gerenciamento de
projetos criado pela Simpact Systems Ltd em 1975. PROMPT foi adotado pela CCTA em
1979 como o padrão a ser usado por todos os projetos em sistemas de informação do
Governo.
Quando o PRINCE2 foi lançado em 1989, a metodologia PROMPT foi substituída
nos projetos governamentais. O PRINCE2 permaneceu como domínio público com direitos
autorais pertencentes a Coroa. O PRINCE2 é uma marca registrada da OGC.
O PRINCE2 foi publicado em 1996, contribuindo para um consórcio de 150
organizações européias, apresentando atualmente certificados em 52 países. A metodologia é
de domínio público, oferecendo um guia de melhores práticas em Gerenciamento de Projetos.
O Prince2 apresenta em sua metodologia:
• uma definição da estrutura organizacional para a equipe de gerenciamento de
projetos;
• abordagem baseada em produto;
• ênfase na divisão do projeto em estágios gerenciáveis e controlados;
• flexibilidade para ser aplicado a um nível apropriado ao projeto.
Estes conceitos são operacionalizados através de uma estrutura de oito processos,
cada qual com suas entradas e saídas e inter-relações, apresentadas abaixo:
44

Gerenciamento de Programas

Direcionamento de um projeto

Estabeleci- Início de um Controle de Gerenciamen- Encerramen


mento do projeto um estágio to dos limites -to de um
projeto dos estágios projeto

Gerencia-
mento da
entrega de
um produto

Planejamento

Esquema 3: O modelo de processo PRINCE2


Fonte: OGC, 2007.

• Direcionamento de um projeto: visa atender o comitê de Projetos, fornecendo


via relatórios e controles, informações necessárias às tomadas de decisões.
• Estabelecimento do projeto: primeiro processo, pré-projeto, que garante que os
pré-requisitos para o início de um projeto estejam disponíveis.
• Inicio de um projeto: processo de iniciação de um projeto;
• Controle de um estágio: processo que fornece informações a respeito do
andamento do projeto, alimentando as decisões de realinhamento do projeto;
• Gerenciamento dos limites dos estágios: processo que garante que o
monitoramento e controle do projeto verifiquem o cumprimento do curso pré-
estabelecido do projeto, e gera reação aos eventos inesperados;
• Encerramento de um projeto: processo que garante o encerramento controlado
de um projeto;
• Gerenciamento da entrega de um produto: processo que garante a criação e a
entrega de produtos conforme critérios pré-estabelecidos;
• Planejamento: processo repetitivo, que se aplica à iniciação, ao projeto em si,
aos estágios e a ao plano de exceção.
45

Estes oito processos compõem a metodologia em gerenciamento PRINCE2 que é


utilizada como base para os processos de certificação em projetos PRINCE2 Foundation e
PRINCE2 Practioneer.

1.3. AS CERTIFICAÇÕES EM GERENCIAMENTO DE PROJETOS

As certificações em Gerenciamento de Projetos podem ser profissionais ou


organizacionais. As profissionais envolvem a certificação de indivíduos com base em seus
conhecimentos em determinadas metodologias em Gerenciamento de Projetos. As
organizacionais envolvem a avaliação do nível de maturidade no qual a empresa se encontra,
e também são avaliadas de acordo com determinados modelos de maturidade disponíveis às
organizações.

1.3.1. CERTIFICAÇÕES

[A certificação] é um conjunto de atividades desenvolvidas por um


organismo independente da relação comercial com o objetivo de atestar
publicamente, por escrito, que determinado produto, processo ou serviço
está em conformidade com os requisitos especificados. Estes requisitos
podem ser: nacionais, estrangeiros ou internacionais. As atividades de
certificação podem envolver: análise de documentação, auditorias/inspeções
na organização, coleta e ensaios de produtos, no mercado e/ou na fábrica,
com o objetivo de avaliar a conformidade e sua manutenção.
(ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 2007).

A certificação não pode ser considerada uma ação isolada e pontual, mas um
processo em estágios que começa com a conscientização da necessidade da qualidade visando
sustentar a competitividade da organização e a conseqüente permanência no mercado,
passando pela utilização de normas técnicas e pela difusão dos conceitos de qualidade por
toda a organização, envolvendo desde suas operações internas até o relacionamento externo,
inclusos aí a sociedade e meio-ambiente.
Segundo o INMETRO – Instituto Nacional de Metrologia, Normalização e
Qualidade Industrial (2007) “a certificação de produtos ou serviços, sistemas de gestão e
46

pessoas é, por definição, realizada pela terceira parte, isto é, por uma organização
independente a credita para executar essa modalidade de Avaliação da Conformidade”.
A certificação dos sistemas de gestão atesta a conformidade do modelo de gestão
de fabricantes e prestadores de serviço em relação a requisitos normativos. Os sistemas
clássicos na certificação de gestão são os de gestão de qualidade, baseado nas normas ISO
9000 e os sistemas de gestão ambiental, conforme as normas ISO 14001.
A série ISO 9000 é um conjunto de padrões que estabelece um padrão de
exigências na administração de seus processos de qualidade estabelecido pela ISO
(International Organization for Standartization). Teve sua primeira versão publicada em
1987, teve uma segunda versão com uma revisão em 1994, e atualmente possui uma versão
atualizada em 2000. Cada país possui um padrão, entretanto todos os padrões são muito
semelhantes entre si. No Brasil utiliza-se a sigla NBR 9000. A certificação é realizada por
uma auditoria externa e é criado um ciclo de auditorias regulares para manutenção da
certificação. (SLACK et al.,1996; TURBAN; McLEAN; WETHERBE, 2002)
Na certificação de profissionais são avaliadas as habilidades e conhecimentos para
determinadas ocupações profissionais, podendo incluir entre outras exigências (INMETRO,
2007):
• Formação – obrigatoriedade de determinado nível de escolaridade buscando
assegurar nível de capacitação;
• Experiência Profissional – possuir experiência prática em setor específico
possibilitando desta forma uma maior compreensão dos processos envolvidos e
uma identificação rápida das oportunidades de melhorias;
• Habilidades e conhecimentos teóricos e práticos – necessidade da capacidade
de execução para atuar e desenvolver-se na atividade de forma plena.
As certificações profissionais podem exigir a apresentação de documentos para
comprovação de experiência e, invariavelmente, a realização de um teste, gerido pela
organização auditora para comprovação de habilidades e conhecimentos.
47

1.3.2. AS CERTIFICAÇÕES PROFISSIONAIS EM GERENCIAMENTO DE PROJETOS

No campo de conhecimento em Gerenciamento de Projeto a certificação mais


conhecida é a certificação de profissionais, como as certificações para PMP - Project
Management Professional - realizadas pelo PMI e a certificação em níveis pelo IPMA.
A certificação para PMP consiste na realização e aprovação de uma prova teste
baseada nos conhecimento do PMBOK. Existem dois tipos de profissionais PMP (PMI,
2007):
• Categoria I: profissionais com 3º grau completo e que possuam 4.500 horas e
36 meses de experiência em gerenciamento de projetos nos últimos 6 anos;
• Categoria II: profissionais com 2º grau completo e que possuam 7.500 horas e
60 meses de experiência em gerenciamento de projetos nos últimos 8 anos.
Para realização da prova é necessário o pagamento de uma taxa ao PMI e a
comprovação da experiência necessária para cada categoria. Entretanto, o PMI avalia apenas
alguns candidatos, a partir de uma amostra aleatória, para a verificação de documentação que
comprove as horas de experiência em Gerenciamento de Projetos. E caso o tempo de
experiência não se comprove, o candidato à certificação não pode realizar a prova.
O prazo de validade da certificação é de três anos. Deve haver uma meta, a de
acumular 60 PDUs – Professional Developement Unit (cada hora gasta em uma atividade ou
experiência de aprendizagem estruturada planejada voltada ao Gerenciamento de Projetos)
nestes três anos. A verificação dos PDUs entre todos os PMPs também é feita através de
amostragem aleatória.
Uma das grandes críticas dos profissionais da área de Gerenciamento de Projetos
ao exame PMP é o fato de que o candidato à certificação necessariamente não possui a
experiência minimamente exigida pelo próprio PMI, já que a verificação é realizada via
amostragem aleatória. Desta forma, muitos profissionais com pouca experiência na área de
Gerenciamento de Projetos, acabam certificados, o que representa um contra-senso à
profissão, na qual a experiência é uma competência altamente valorizada.
Já a certificação profissional do IPMA consiste em quatro níveis (IPMA, 2007):
• IPMA Level D - Associado em Gerenciamento de Projetos Certificado:
Conhecimentos de Gerenciamento de Projetos, com aplicação em alguns
campos da sua especialidade.
48

• IPMA Level C - Gerente de Projetos Certificado: Capacidade de gerenciar,


com razoável independência, projetos não complexos e apoiar o gestor de um
projeto complexo em todas as áreas de aplicação do Gerenciamento de
Projetos.
• IPMA Level B - Gerente de Projetos Sênior Certificado: Capacidade de
gerenciar projetos complexos com total independência.
• IPMA Level A - Diretor de Projetos Certificado: Capacidade de dirigir todos os
projetos constituintes de um programa ou todos os projetos de uma empresa ou
linha de negócio, ou ainda um projeto complexo com participantes de
diferentes culturas e geografias.
A certificação não está somente atrelada aos conhecimentos do ICB, mas a um
IPMA Certification Regulation and Guidelines, documento que rege os princípios
profissionais do IPMA. O IPMA apresenta hoje cerca de 60.000 certificados no mundo todo.
A certificação PRINCE2 possui dois níveis:
• foundation, que contempla os conceitos básicos e terminologia da metodologia
PRINCE2 com objetivo de medir se o candidato é capaz de agir como um
membro conhecedor da metodologia PRINCE2 em uma equipe de projetos,
através de:
 descrever o objetivo e conteúdo de todos os papéis, os 8 componentes e
8 processos e sub-processos, e técnicas;
 saber quais são os inputs e outputs de cada um dos 8 processos;
 saber os objetivos principais e conteúdos chave do gerenciamento de
produtos;
 estabelecer as relações ente processos, entregas, papéis e as dimensões
gerenciáveis de um projeto.
• practioneer, no qual o candidato deve exibir os conhecimentos necessários
para a qualificação foundation e mostrar que é capaz de aplicar e adaptar o
PRINCE2 de forma a atender as necessidade e solucionar problemas de um
cenário específico em projetos, através de:
 produção de explicação detalhada de todos os processos, componentes,
técnicas e exemplos apresentados em todo o PRINCE2, como seriam
aplicados em particulares circunstâncias de um dado cenário de
projetos;
49

 demonstrar entendimento das relações entre processos, componentes e


técnicas além de suas aplicações;
 demonstrar entendimento das razões por detrás dos processos,
componentes e técnicas do PRINCE2,
 demonstrar sua habilidade em adaptar o PRINCE2 a diferentes
circunstâncias de projetos.
A certificação profissional no PRINCE2 é realizada pela APM Group Limited,
uma empresa especializada em certificações e avaliações.

1.3.3. AS CERTIFICAÇÕES ORGANIZACIONAIS EM GERENCIAMENTO DE PROJETOS

As certificações organizacionais em gerenciamento estão relacionadas a um


atestado em relação ao nível de maturidade da organização em Gerenciamento de Projetos, ou
seja, a capacidade da organização em realizar o gerenciamento de projetos de forma repetível,
consistente e robusta, de maneira a minimizar possíveis problemas na gestão de seus projetos
de forma contínua.
O processo de certificação nestes modelos é geralmente realizado por um grupo de
organizações e profissionais, que envolve uma instituição certificadora, avaliadores ou
empresas avaliadoras credenciados por esta instituição e consultores também atrelados à
instituição.
Ao identificar a necessidade de uma certificação, a empresa a ser avaliada procura
um consultor que detém os conhecimentos a respeito desta certificação. Este profissional
auxiliará a empresa quanto à obtenção da certificação, servindo como um facilitador em todo
o processo. Muitas vezes o consultor é responsável por conduzir as melhorias dentro da
organização que levará a aquisição da certificação, introduzindo conceitos, estabelecendo
agendas e estruturas necessárias à obtenção da certificação.
Após este processo, um avaliador credenciado pela instituição de origem realiza o
processo de análise da organização, cada qual seguindo seus critérios e métodos. É papel do
avaliador não apenas atestar o nível de maturidade, mas também indicar guias para a melhoria
de seus processos e de seu nível de maturidade.
Os processos de certificação em maturidade de projetos de cada modelo serão
apresentados na sessão posterior.
50

1.4. A MATURIDADE EM GERENCIAMENTO DE PROJETOS E OS MODELOS DE MATURIDADE

O conceito de maturidade em Gerenciamento de Projetos tem sua raiz no conceito


de maturidade de processo, originado no movimento de TQM (Total Quality Management),
em que técnicas de controle estatístico da qualidade possibilitaram a redução da variação de
resultado dos processos e uma substancial melhoria na performance do processo.(COOKE-
DAVIES; ARZYMANOW, 2003)
Kerzner (2002) define:

“a maturidade em gestão de projetos é o desenvolvimento de sistemas e


processos que são, por natureza, repetitivos e garantem uma alta
probabilidade de cada um deles ser um sucesso. Entretanto, processos e
sistemas repetitivos não são, por si, garantia de sucesso. Apenas aumentam
a sua probabilidade.” (p.45)

Entretanto, a obtenção da maturidade depende de tempo em melhorias de seus


processos de Gerenciamento de Projetos, o que pode levar a cerca de cinco anos para assim
colher seus benefícios. Há dois fatores críticos que podem acelerar o processo de maturidade:
(KERZNER, 1987)
• primeiro: a percepção por parte da organização da necessidade de haver
gerenciamento de projetos, através da existência de projetos estratégicos,
expectativas dos clientes, ganho de competitividade, desenvolvimento de
novos produtos, eficiência e efetividade, ou até mesmo assegurar a
sobrevivência da organização.
• segundo: entendimento e comprometimento corporativo em educar e treinar
toda a organização, em todos os níveis hierárquicos, em Gerenciamento de
Projetos.
Para Cooke-Davies e Arzymanow (2003), quanto mais tempo uma indústria sofrer
pressões comerciais para obter melhor performance maior a maturidade deste setor.
A maturidade do Gerenciamento de Projetos nos auxilia a compreender vários
aspectos, entre eles, medir a competência dos profissionais em Gerenciamento de Projetos em
escalas generalizadas. Também nos auxilia a compreender o ambiente de trabalho dos
profissionais e a avaliar a aderência ao negócio para qual o projeto está sendo desenvolvido.
A maturidade em gestão de projetos também cria a oportunidade de estudar e compreender a
51

formação de excelentes gerentes de projetos, e pode nos auxiliar a compreender o mecanismo


que está por trás deste crescimento. (HARTMAN; SKULMOSKI, 1998)
Para Kezner (2002), a maturidade em projetos possui um ciclo de vida, no qual
uma empresa que tenha atingido qualquer grau de maturidade obrigatoriamente passou por
estas etapas:
Etapas Ocorrências
Há reconhecimento da necessidade
Há reconhecimento dos benefícios
Embrionária
Há reconhecimento da aplicabilidade
Há reconhecimento do que precisa ser feito
Apoio visível dos executivos
Executivos entendem a gestão de projetos
Aceitação pela gerência
Estabelece promotores no nível executivo
executiva
Está disposto a mudar a forma de conduzir o
empreendimento
Obtém apoio dos gerentes de área
Obtém comprometimento dos gerentes de área
Apoio dos gerentes de área Proporciona conhecimento aos gerentes de área
Os gerentes de área estão dispostos a liberar
funcionários para treinamento
Reconhece a utilidade das fases do ciclo de vida
Desenvolve uma metodologia em gestão de projetos
Fase de Crescimento Obtém comprometimento com o planejado
Minimiza oscilações no escopo
Define um sistema de rastreamento de projeto
Desenvolve um sistema de controle de custo e
programação
Maturidade Integra os controles de custo e programação
Desenvolve um sistema de ensino para melhorar as
competências em gestão de projetos
Quadro 6: Estágios da maturidade em gerenciamento de projetos.
Fonte: KERZNER, 2002, p. 46.

A adoção de uma metodologia em Gerenciamento de Projetos, de forma definida e


implantada, não é, por si só, um elemento suficiente para adquirir o nível de maturidade de
uma organização no gerenciamento de seus projetos. Para tanto é necessário um conjunto de
elementos que gravitam ao redor dessa metodologia: uma estrutura organizacional que
promova e suporte o gerenciamento de projetos, organizações apropriadas com a existência de
centros de excelência em gerenciamento de projetos, que, unidos à metodologia, confirmam a
efetiva maturidade organizacional. (BOUER; CARVALHO, 2005)
Os modelos de maturidade são ferramentas que têm por objetivo auxiliar as
empresas a alcançar a maturidade no gerenciamento de seus projetos, através da identificação
52

das melhores práticas, realizadas por empresas líderes de mercado. (Kerzner, 2002). Para
Hartman e Skulmoski (1998) nenhum modelo de maturidade será completo ou correto, pois a
contínua evolução do Gerenciamento de Projetos irá afetar os conceitos dos modelos.
Através do modelo CMM, desenvolvido pela SEI, o conceito de maturidade de
processos passou para a medida de uma maturidade organizacional. Como softwares são
desenvolvidos através de projetos, foi natural que o conceito de maturidade migrasse de
desenvolvimento de software para gerenciamento de projetos, gerando assim, no meio dos
anos 90, o desenvolvimento de modelos de maturidade em Gerenciamento de Projetos.
Na próxima sessão são apresentados os modelos de maturidade mais citados na
literatura de modelos de maturidade em Gerenciamento de Projetos (BOUER; CARVALHO;
2005; COOKE-DAVIES; ARZYMANOW, 2003; HARTMAN; SKULMOSKI, 1998;
RABECHINI; PESSÔA, 2005), além dos modelos desenvolvidos no Brasil, o MPCM - com
forte fundamento empresarial - e o MPS.BR, cuja importância afeta os resultados desta
pesquisa.

1.4.1. O CMMI - CAPABILITY MATURITY MODEL INTEGRATION

O CMMI (Capability Maturity Model Integration) é um dos modelos de


maturidade disponíveis no mercado, desenvolvido pela SEI - Software Engineering Institute
da Carnegie Mellon University, em Pittsburg na Pensilvânia, EUA, e é consistente com a
norma padrão internacional ISO/IEC 15504. ”O CMMI é um modelo de maturidade para
melhoria de processos de desenvolvimento de produtos e serviços. Consiste nas melhores
práticas, direcionando atividades de desenvolvimento e manutenção que cobrem o ciclo de
vida de um produto desde a sua concepção até a sua entrega e manutenção” (SEI; 2006b, p.I,
tradução própria).
Assim como um modelo de maturidade, o CMMI também é classificado como um
SPI (Software Process Improvement), ou seja, um processo de melhoria de software, embora a
SEI venha realizando um grande esforço no sentido de afastar a imagem do CMMI de um
processo de maturidade exclusivo para desenvolvimento de software, viés reproduzido
inclusive por pesquisadores em Gerenciamento de Projetos. (BOUER; CARVALHO; 2005)
O CMMI possui altos índices de difusão, que vêm crescendo ao longo do tempo,
conforme pode ser observado na tabela 2 abaixo.
53

Tabela 2 : Evolução dos índices de status do CMMI

2004/dez. 2005/jun. 2005/dez. 2006/jun. 2006/dez. 2007/jun.


Certificações 630 868 1264 1581 1964 2464
Organizações 567 782 1106 1377 1712 2140
Companhias participantes 298 438 644 840 1084 14717
Organizações re-avaliadas 65 74 130 169 208 273
Projetos 2339 3250 4771 6001 6713 10338
Organizações não
americanas 56,10% 59,00% 62% 63,80% 65,50% 67,10%
Nº de países 36 41 45 50 50 57
Fonte: adaptado de SEI, 2007a, p.16; SEI, 2007b, p.15, SEI, 2006a, p.15; SEI, 2006c, p.15;
SEI, 2005a, p.15; SEI, 2005b, p.15

1.4.1.1. Origens

Nos anos 30, Walter Shewhart deu início aos trabalhos sobre melhoria de
processos com princípios no controle estatístico da qualidade. Estes conceitos foram refinados
posteriormente por Deming, Crosby e Juran. (SEI, 2006(b))
Watts Humphrey, Ron Radice e outros expandiram os horizontes destes princípios
e passaram a aplicá-los na produção de software em seus trabalhos na IBM e na SEI, gerando
assim o livro “Managing the Software Process” em 1989, que gerou os princípios básicos e
conceitos no qual o CMM foi baseado.
O CMM foi criado com o objetivo de auxiliar o departamento de Defesa dos EUA
na escolha de parceiros fornecedores de software. (Turban et al., 2002)
Em 1995, a SEI publicou o livro “The Capability Maturity Model: Guidelines for
the Improving the Software Process”, buscando incorporar a máxima de que a qualidade de
um produto ou serviço está diretamente relacionada à qualidade dos processos para seu
desenvolvimento e manutenção.
Segundo a SEI (2006b), desde 1991, foram desenvolvidos diversos CMMs:
engenharia de sistemas, engenharia de software, aquisição de software, administração,
desenvolvimento de produtos e processos integrados. A existência de diversos modelos
mostrou ser problemática, levando à criação de um modelo integrado, composto pelos
modelos CMM de engenharia de software, engenharia de sistemas e desenvolvimento de
54

produtos e processos integrados, nascendo assim o CMMI, Capability Maturity Model


Integration. Em 2006, o modelo CMM foi descontinuado.
Atualmente o CMMI é formado por três modelos: CMMI for Development v.1.2;
CMMI for Acquisition v.1.2 e CMMI for Services. Como foco deste trabalho, utilizaremos
como base o modelo CMMI for Development. v.1.2.

1.4.1.2. A estrutura

O CMMI é composto por processos, nos quais cada um é formado por objetivos
específicos e objetivos genéricos, que por sua vez são compostos por práticas e sub-práticas:
• os objetivos específicos são um conjunto único de requisitos que devem estar
presentes para satisfazer um processo em questão;
• as práticas específicas são as descrições de um conjunto de atividades
necessárias para atingir um objetivo específico;
• os objetivos genéricos são requisitos necessários em diversos processos;
• as práticas genéricas são as descrições de um conjunto de atividades
necessárias para atingir um objetivo genérico;
• as sub-práticas são descrições detalhadas que fornecem direcionamento para
interpretar e implementar uma prática específica ou genérica;
A figura abaixo demonstra a relação entre as estruturas.
55

Processo

Objetivos Objetivos
Específicos Genéricos

Práticas Práticas
Específicas Genéricos

Sub-práticas Sub-práticas

Esquema 4: Concepção de um processo no CMMI


Fonte: adaptado de SEI, 2006b p. 17.

O CMMI utiliza o Gerenciamento de Projetos para atingir um processo repetível


que possa fornecer resultados previsíveis a partir dos esforços de trabalho. (CLELAND;
IRELAND, 2002) e apresenta duas formas de representação: a estagiada a e continuada.
A representação continuada permite à organização selecionar um processo ou um
grupo de processos para gerar sua melhoria, através do conceito de níveis de capability3 que
caracterizam a melhoria. Apresenta como grande vantagem desenvolver diferentes processos
que apresentam diferentes estágios de capability. Por capability, compreendem-se os níveis
que definem uma melhoria incremental dos processos que compõem uma área de processo.
Esta representação é composta por seis níveis de capability, do 0 ao 5:
• Nível 0 – Incompleto: são os processos que ainda não são executados ou são
parcialmente executados.
• Nível 1 – Dirigido: são os processos que satisfazem as metas específicas
estabelecidos para o processo.
• Nível 2 – Gerenciado: são os processos “dirigidos” (nível 1) que têm uma
infra-estrutura básica de suporte: são planejados e executados conforme
políticas estabelecidas; empregam pessoal com habilidade para produzir
resultados controlados; envolvem os stakeholders relevantes; são monitorados,

3
Pela ausência de uma tradução adequada ao termo “capability”, será utilizado o termo em inglês.
56

controlados e revistos; têm sua aderência avaliada em relação ao processo


descrito.
• Nível 3 – Definido: são os processos gerenciados, realizados a partir de um
guia organizacional para a consecução do processo. As principais diferenças
entre os níveis 2 e 3 estão no escopo e rigor dos padrões, descrições de
processos e procedimentos, nos quais há uma maior consistência e rigor na
descrição dos processos.
• Nível 4 – Gerenciado Quantitativamente: são os processos controlados através
de controle estatístico e outras técnicas quantitativas.
• Nível 5 – Otimizado: são os processos quantitativamente gerenciados que são
melhorados com base nas variações inerentes ao próprio processo.
Na representação estagiada a empresa pode escolher os processos que deseja
melhorar, entretanto, existe uma dependência entre os processos nas organizações. Para
auxiliar no processo de escolha, os processos são classificados em quatro categorias:
Gerenciamento de Processo, Gerenciamento de Projeto, Engenharia e Suporte.
Na representação estagiada, são previamente estabelecidos conjuntos de áreas de
processo para estabelecer um rumo de melhoria para a organização. Este rumo é determinado
através dos níveis de maturidade. Por nível de maturidade, compreende-se um estágio que
estabelece uma série de previsões dos resultados genéricos de um próximo projeto.
Esta representação ocorre através de cinco níveis de crescimento para organizar as
etapas evolutivas que estabelecerão as bases para a construção de um processo de software
pela empresa. São estes:
• Nível 1 - Inicial: O processo de desenvolvimento de software é ad hoc e até
mesmo caótico. Poucos processos são definidos e o sucesso depende de
esforços individuais; falta planejamento e controle de processos.
• Nível 2 - Repetível: Processos de gerenciamento de projetos básicos estão
estabelecidos para mensurar e controlas custos, prazos e funcionalidades
(qualidade). São firmados compromissos e é estabelecido um nível de
gerenciamento. Os processos estabelecidos permitem a repetição de sucessos
em projetos semelhantes, entretanto o sucesso depende do gerenciamento do
projeto.
• Nível 3 - Definido: O processo de desenvolvimento de software tanto técnico
quanto gerencial é documentado, padronizado, e integrado a um processo
57

padrão de desenvolvimento da empresa. Todos os projetos usam uma versão


padronizada para o desenvolvimento e manutenção de softwares. Os processos
e técnicas gerenciais são bem definidos e permitem a avaliação do processo,
com medições de desempenho, realização de auditorias de forma rotineira e
testes padrões.
• Nível 4 - Gerenciada: Mensurações detalhadas do processo de
desenvolvimento de software e qualidade dos produtos são coletadas, e o
processo é quantitativamente definido, avaliado e controlado.
• Nível 5 - Otimização: Processo de melhoria continua é estabelecido pela
quantidade de feedbacks do processo e do desenvolvimento de inovações e
tecnologias.
Para decidir qual a melhor forma de selecionar uma das duas representações, a SEI
(2006b), sugere três conceitos a serem analisados:
• fatores de negócio: os processos organizacionais devem suportar os objetivos
de negócio;
• cultura: a capacidade de a organização desenvolver um programa de melhoria;
• legado: as experiências anteriores da organização em relação a modelos.
O quadro abaixo lista as diferenças entre as representações continuada e estagiada:

Representação Continuada Representação Estagiada


Garante liberdade para selecionar uma Permite a organização ter um rumo pré-
ordem de melhoria que melhor atendas definido em sua melhoria.
aos objetivos da organização e mitiga
riscos.
Permite uma visualização do aumento da Foco num conjunto de processos que
capability em cada processo. fornece à organização um específico
capability que corresponde a um nível de
maturidade.
Permite a melhoria de diferentes Resume os resultados de melhoria de uma
processos em ritmos diferentes. forma simples – um único nível de
maturidade
Reflete uma abordagem nova, que ainda Constrói um histórico relativamente longo
não possui dados para demonstrar o que inclui estudos de caso e dados para
retorno sobre o investimento. demonstrar o retorno sobre o
investimento.
Quadro 7: Vantagens das Representações Continuada e Estagiada
Fonte: SEI, 2006b, p.11.
58

O CMMI apresenta 21 áreas de processo. Cada conjunto de processos representa a


consecução de um nível de maturidade na representação estagiada. Para equivalência entre os
níveis de maturidade e os níveis de capability, segue-se o quadro abaixo:
Área de Processo M C1 C2 C3 C4 C5
Gerência de configuração Suporte 2
Planejamento de projeto Gerenciamento de 2
Projetos
Monitoramento e controle de Gerenciamento de 2 Perfil
projeto Projetos Alvo 2

Administração de fornecedores Gerenciamento de 2


Projetos

Medidas e análises Suporte 2

Garantia da qualidade de Suporte 2


processos e produtos
Desenvolvimento de requisitos Engenharia 3

Solução técnica Engenharia 3


Integração de Produto Engenharia 3
Verificação Engenharia 3
Validação Engenharia 3 Perfil Alvo 3
Foco Organizacional Gerenciamento de 3
Processo
Definição de processos Gerenciamento de 3
organizacionais Processo
Treinamento organizacional Gerenciamento de 3
Processo
Gerenciamento de projetos Gerenciamento de 3
integrado Projetos
Gerenciamento de risco Gerenciamento de 3
Projetos
Análise de decisões e Suporte 3
resoluções
Performance organizacional Gerenciamento de 4
Processo
Gerenciamento de projetos Gerenciamento de 4 Perfil Alvo 4
quantitativo Projetos

Inovação organizacional Gerenciamento de 5


Processo Perfil Alvo 5
Análise causa e resoluções. Suporte 5
Quadro 8: Equivalência entre níveis de maturidade e capability.
Fonte: SEI, 2006b, p.49.
59

Por exemplo, para atingir o nível de maturidade 2, todas as áreas de processo


marcadas com 2 na coluna M devem atingir capability 2 ou maior e assim por diante.
No nível de maturidade 4, a empresa escolhe as áreas de processos que serão
estabilizadas de acordo com os objetivos da organização e seus processos. Devido a isso, para
atingir o nível de capability 4 e 5 (C4 e C5) não podem ser pré-determinadas as áreas de
processo.
Também no quadro à cima podemos observar o agrupamento das áreas de
processo nas quatro categorias apresentadas pelo CMMI:
• Gerenciamento de Processo: cobre as áreas relacionadas a definir, planejar,
desenvolver, implementar, monitorar, controlar, aprovar, medir e melhorar
processos;
• Gerenciamento de Projetos: cobre as áreas relacionadas a planejamento,
monitoramento, e controle de projeto;
• Engenharia: cobre as áreas de desenvolvimento e manutenção que são
compartilhadas pelas atividades de engenharia, foi escrito usando terminologia
da área;
• Suporte: cobre as atividades de suporte ao desenvolvimento e manutenção de
produto.

1.4.1.3. A implantação e a certificação

A SEI disponibiliza em seu site um conjunto completo de documentos de


orientação às empresas que desejam implantar o CMMI, ou seja, qualquer empresa pode
utilizar-se dos conceitos do modelo livremente. Além dos documentos contendo o modelo em
si, a SEI disponibiliza o “Software Engineering Process Group (SEPG) Guide”, para a
formação da equipe responsável pela definição dos processos, manutenção, melhoria e
divulgação dos mesmos entre a empresa. São objetivos da SEPG (SEI, 1990):
• obter e manter o suporte para todos os níveis de gestão;
• facilitar a avaliação dos processos de desenvolvimento de software;
60

• trabalhar com os gestores de linha, cujos projetos são afetados pelas práticas,
provendo uma perspectiva mais ampla do esforço de melhoria e auxiliando-os
a ajustar suas expectativas;
• manter um relacionamento de trabalho colaborativo com os desenvolvedores,
especialmente para obter, planejar e implantar novas práticas e tecnologias;
• engajar-se em iniciativas de treinamento ou educação continuada relacionada à
melhoria de processos;
• controlar, monitorar, e reportar os status de esforços de melhoria particulares;
• facilitar a criação e manutenção de processos, em colaboração com gestores e
equipes de desenvolvimento;
• manter um banco de dados de processo;
• prover uma fonte de consulta ao desenvolvimento de projetos e gestão de
projetos.
As empresas, ao se submeterem ao processo de avaliação, são classificadas em três
classes de capacitação:
• Classe A - que demanda altos custos, dedicação de tempos e recursos
intensivos, mas proporciona o melhor nível de garantia aos seus processos.
• Classe B – que envolve custos menores, menor dedicação em termos de tempo
e recursos e proporcionalmente menor garantia em seus processos.
• Classe C - a forma mais barata e fácil, mas também a mais precária.
Entretanto, apenas os certificados na classe A podem ser considerados certificados
em seus níveis e passarem a divulgar a certificação. Para obtenção desta certificação, é
necessário que a empresa se submeta a uma avaliação por indivíduos credenciados pela SEI.
Estes avaliadores devem seguir os preceitos do SCAMPI - Standard CMMI
Appraisal Method for Process Improvement, um documento disponibilizado pela SEI que
fornece os processos necessários às três fases que a SEI atribui a uma avaliação: preparação
para a avaliação, condução da avaliação e reporte dos resultados. Para tornar-se um avaliador
credenciado, estes profissionais também devem submeter-se a um processo de certificação
pessoal. (SEI, 2001; STAPLES et al., 2006)
61

1.4.1.4. Motivações

Em 2002, Baddo e Hall publicaram uma pesquisa com 13 empresas do Reino


Unido e cerca de 200 profissionais de software, divididos entre desenvolvedores, gerentes de
projetos e executivos seniores buscando encontrar as motivações para adoção de um SPI
(Software Process Improvement)
Um dos principais motivos apontados como motivador para adoção de um SPI é a
visibilidade do sucesso, ou seja, a possibilidade de apresentar evidências dos benefícios
atingidos pela adoção é um grande fator motivacional para os profissionais de software. Para
os pesquisadores, isto mostra a insuficiência, em termos de informação, a respeito de casos de
sucesso de SPI na indústria.
Outras motivações apontam o aumento do poder dos profissionais através do
aumento da responsabilidade sobre o processo com o qual trabalham, e também o aumento da
disponibilidade de tempo, ferramentas e recursos humanos para a adoção.
Niazi e Staples (2006) em pesquisa realizada pela NICTA, (National Information
and Communication Technology of Australia) investigaram os fatores motivacionais para
adoção do CMM e CMMI, com base em 46 artigos escritos sobre o tema. Como resultado,
encontraram que as principais motivações para adoção do CMM envolvem qualidade e
performance dos projetos e também melhorias nos processos de gestão. Em terceiro lugar
aparecem as motivações comerciais, como satisfazer consumidores e vantagens de mercado,
e, raramente, empresas adotam o modelo buscando a melhoria do ambiente de trabalho
através da capacitação e motivação de seus funcionários.
Entretanto os pesquisadores ressaltam o viés em relação à produção existente sobre
o tema, com enfoque em motivadores relacionados a processos em detrimento dos
motivadores relacionados a produto e performance organizacional. Niazi e Staples (2006)
relacionam como indícios desse viés: a diferença substancial encontrada em resultados de
pesquisas envolvendo uma única empresa e múltiplas empresas; a diferença dos motivadores
definidos entre pesquisadores de SPI e iniciativas empresariais; citações de pesquisadores de
SPI na literatura.
62

1.4.1.5. As críticas

O CMMI deriva do CMM, um modelo antigo, influente e frequentemente estudado


sobre a ótica de um SPI. Suas contribuições para a área de engenharia de software são
consideradas de grande importância. (BOLINGER; McGOWAN, 1991; NIAZI; STAPLES,
2006; O´CONELL; SAIEDIAN, 2000)
Entretanto, até mesmo devido ao seu pioneirismo, o modelo é alvo de críticas
constantes em reação à sua aplicação e ao seu modelo de avaliação. O modelo é considerado
burocrático e rígido, exige alta concentração, à custa de outros aspectos importantes para a
organização, e faz com que empresas evitem aceitar projetos arriscados de forma a atingir
melhores avaliações. (HARTMAN; SKULMOSKI, 1998)
Baddo e Hall (2003) em sua pesquisa com cerca de 200 profissionais de software
de 13 empresas do Reino Unido, através de focus groups, obtendo uma lista dos maiores
motivos para que não utilizem um SPI. Os profissionais foram analisados de acordo com seu
cargo, e divididos em três níveis hierárquicos: programadores, gerentes de projeto e gerentes
seniores. Os pesquisadores encontraram cinco fatores considerados como mais importantes
para a não adoção de um SPI:
• Recursos para SPIs - Ocorre uma grande preocupação em relação aos recursos
para adotar-se um modelo de SPI; os desenvolvedores e gerentes sênior
vislumbram cortes no orçamento, enquanto o gerente de projeto uma falta geral
de recursos.
• Pressões comerciais: As pressões comerciais também são vistas como uma
dificuldade para a implantação de um SPI, pois a necessidade da empresa de
manter sua posição no mercado, muitas vezes envolve satisfazer o cliente a
qualquer custo, fazendo com que num ambiente em que o imperativo
comercial é forte, os incentivos para uso de SPI sejam comprometidos.
• Resistência: Outro ponto importante para não adoção dos SPIs é a resistência
dos profissionais, baseada em experiências anteriores ruins, inércia e falta de
suporte geral.
• Evidências: Os pesquisadores encontraram ainda que a falta de evidências de
sucesso dos casos de SPI, também é um dos fortes motivos para não adoção de
63

SPI. Esse ponto, particularmente, é compartilhado por diversos outros


trabalhos sobre SPIs.
• Habilidades: a falta de habilidade para utilizar-se de um SPI é outro fator
citado, na opinião de gerentes seniores e desenvolvedores é crucial que existam
pessoas capacitadas para direcionar os programas de SPI nas organizações.
Para gerentes de projeto, o alto índice de rotatividade é uma das causas que
leva a um grupo inexperiente.
• Imposição: Refere-se à forma como os SPIs são adotados nas empresa, através
de imposição e comunicação inadequada, prejudicando dessa forma todo o
processo de adoção por parte dos envolvidos.
Para Brady e Davies (2004), as empresa devem ir além de caros projetos padrão
para obter “economias de repetição” executando um número maior de projetos de forma
eficiente e efetiva. Os autores criticam a dificuldade na manutenção das capabilities através
dos projetos, a dificuldade das empresas em transferir aprendizado de um projeto para outro, e
de um projeto para a organização. Existe uma falha na literatura sobre projetos, sobre como
uma empresa constrói capabilities ao longo do tempo.
Staples et al. (2006) realizaram uma pesquisa exploratória com os dados de dois
meses de uma empresa que negocia as avaliações CMMI. A partir dos dados, os
pesquisadores verificaram que os principais motivos para a não adoção do CMMI são: a
empresa é muito pequena, os custos são muito altos para implantação, a empresa não tem
tempo para aplicar o CMMI e a empresa já utiliza outro processo de SPI.
Em resumo, as empresas não adotam o CMMI porque o consideram impraticável,
fornecendo como resposta razões do tipo “não poderíamos”.
Bolinger e McGowan (1991) reconhecem o impacto e importância do modelo
CMMI para a comunidade de software e ressaltam as grandes qualidades do modelo, como a
integração de pessoas envolvidas em um projeto em forma de uma equipe de desenvolvimento
pró-ativa e coesa; a criação de um fórum aberto para a discussão de padrões de
desenvolvimento e engenharia de software, fazendo com que as pessoas apliquem o modelo
por si mesmas, e o levem a sério, e utilizem os bem concebidos conceitos e métodos de
treinamento para as pessoas que realizam as avaliações do processo. Entretanto, para os
autores, uma efetiva avaliação de processo vai além de bons métodos de registro e análise de
processo, que são utilizados pelo modelo CMMI, envolvendo também um detalhado modelo
gráfico do processo de desenvolvimento de software.
64

Bolinger e McGowan (1991) apresentam fortes críticas principalmente sobre os


métodos de avaliação do modelo. Para os pesquisadores, os níveis 2 e 3 de maturidade do
CMMI fornecem ferramentas que realmente auxiliam na obtenção de melhorias no processo
de desenvolvimento de softwares, ao passo que os níveis 4 e 5 carecem que de informações
substanciais que auxiliem a empresa a atingir o que é proposto pelo modelo. Há muitas
interpretações sobre o real significado dos níveis 4 e 5 em parte pela falta de clareza sobre
suas definições atreladas ao seu questionário de avaliação.
Para os autores o CMMI, com raiz nos conceitos de controle estatístico da
qualidade, estabelece paralelos inadequados entre uma linha de produção e o desenvolvimento
de um software, principalmente no que diz respeito ao uso de “tracebacks”, melhorias ou
otimizações pontuais, que podem levar a uma qualidade inferior ao avaliarmos o sistema
como um todo. Na opinião dos autores, o modelo CMMI é tão cheio de falhas e fadado à
obsolescência que deveria ser abandonado.
O´Connell e Saiedian (2000) também criticam os resultados dos modelos de
avaliação e seleção de fornecedores para o Departamento de Defesa dos Estados Unidos,
mesmo processo de certificação para empresas no CMMI, alegando que estes nem sempre
correspondem à realidade. Para empresas maduras, a avaliação é simples, e é de certa forma
fácil atingir um nível de maturidade. Entretanto, empresas menos maduras, devem trabalhar
muito para conseguir vender sua imagem. O próprio sistema possibilita que estas empresas
pareçam ser mais maduras na avaliação, através de quatro estratégias principais:
• Imprecisão intencional: Os avaliados utilizam-se do pouco tempo e
conhecimento limitado dos avaliadores para inflar suas qualificações.
• Detalhamento intencional: Os avaliados também podem inundar os avaliadores
de informações, em termos de quantidade e complexidade, fazendo com que o
avaliador não tenha alternativa frente ao seu tempo limitado e assuma que,
embora de forma intrincada, o avaliado está de acordo com as normas da
certificação.
• Escolha inapropriada de projetos: A SEI determina que o avaliado deve
escolher projetos para a avaliação que represente tipicamente seu processo de
implantação de software. Obviamente, o avaliado irá escolher, dentro de seu
portfólio, os projetos com o maior grau de maturidade e com as equipes
melhores qualificadas para a avaliação.
65

• Treinamento da equipe: Os funcionários que participarão das entrevistas de


avaliação são treinados para que possam fornecer as melhores respostas
possíveis em conformidade para obter a avaliação.
Os autores sugerem que o processo de avaliação seja corrigido, buscando um uso
mais consistente das avaliações através da utilização de uma equipe de avaliação mais
representativa e que saiba identificar e apreciar práticas alternativas; conduzir avaliações
técnicas in loco; requerer duas fontes de confirmação de informações; monitorar o avaliado
após a certificação; exigir que os certificados periodicamente avaliem-se entre si; e
monitoramento da performance do avaliado por parte dos contratantes.

1.4.2. O P3M3 - PORTFOLIO, PROGRAMME AND PROJECT MANAGEMENT MATURITY MODEL

O modelo de maturidade P3M3 foi desenvolvido pela OCG, Office Goverment


Commerce, a Secretaria de Compras Governamentais do Reino Unido, mesma instituição que
desenvolveu o PRINCE2. Atualmente, o P3M3 está em sua primeira versão, lançado em
Fevereiro de 2006.
O P3M3 contempla em seu conteúdo a avaliação da maturidade no gerenciamento
de projetos, portfólios e programas, e é tido como uma evolução de um modelo de maturidade
anterior desenvolvido pela OCG, o P1M3 – Project Management Maturity Model, que
possuía como escopo o gerenciamento de projetos. A partir deste modelo, a OCG desenvolveu
os modelos P2M3 - Portfolio and Project Management Maturity Model, que contempla
projetos e portfólios e o P2MM - PRINCE2 Maturity Model que contempla a maturidade no
uso da metodologia PRINCE2 em gerenciamento de projetos.
66

Portfolio, Programme and Project Management


Maturity Model – P3M3

Programme and Project Management


Maturity Model – P2M3

Project Management
Maturity Model – P1M3

Prince 2
Maturity Model
– P2MM

Esquema 6: Estrutura dos modelos de maturidade desenvolvidos pela OCG.


Fonte: APMGroup, 2006, p.3

Segundo a OCG (2006), o modelo P3M3, auxilia as empresas a direcionar


aspectos importantes no gerenciamento de portfólios programas e projetos, melhorando a
qualidade e o sucesso dos resultados, através da construção de uma infra-estrutura para uma
abordagem orientada a projetos com base em práticas gerenciais. O modelo afirma que os
níveis de maturidade indicam como as áreas de processos podem estruturar hierarquicamente
as organizações, fazendo com que as metas de melhoria sejam reais e perceptíveis.
O modelo P3M3 tem como objetivos (OGC, 2006):
• entender as práticas chaves que compõem um efetivo processo de
gerenciamento de projetos;
• identificar as práticas chaves que são necessárias à organização para atingir um
nível mais alto de maturidade;
• para que organizações possam compreender e melhorar sua capacidade de gerir
programas e projetos de forma mais efetiva;
• para que consumidores possam avaliar os riscos atrelados a questões da
capacidade de fornecedores contratados.
O P3M3 é baseado em cinco níveis de maturidade, derivado do modelo de
maturidade CMM, desenvolvido pela SEI, de acordo com a organização apresentada no
quadro abaixo:
67

Nível de
Projeto Programa Portfólio
Maturidade
Nível 1 - Os projetos são informais, sem Não há processo de controle
Inicial mecanismos de controle ou padrões. ou de reporte formais.
Nível 2 - Pode haver uma consistência limitada e alguma coordenação entre
repetível projetos.
Nível 3 - A organização deve possuir
definido um controle próprio e
centralizado de processos
A organização deve possuir um controle
em gerenciamento de
próprio e centralizado de processos em
projetos que deve ser capaz
gerenciamento de projetos que deve ser
de atender aos projetos,
capaz de atender aos projetos, mesmo
mesmo cada qual com suas
cada qual com suas particularidades.
particularidades. A
.
organização possui um
processo de gerenciamento
de portólios próprio.
Nível 4 - A organização possui
gerenciado medidas específicas de sua
performance em gestão de
A organização possui medidas
projetos e possui uma
específicas de sua performance em
gestão da qualidade para
gestão de projetos e possui uma gestão
melhor prever uma
da qualidade para melhor prever uma
performance futura. A
performance futura.
organização tem condições
de avaliar sua capacidade
em gerenciar as prioridades
dos projetos e programas.
Nível 5 - A organização possui ferramentas de melhoria contínua agindo com
Otimizado pró-atividade em relação aos seus problemas, adotando tecnologia para
projetos de forma a melhorar sua performance e otimização de
processos.
Quadro 9: Características de maturidade no P3M3 para projetos, programas e portfólios de
projetos.
Fonte: OCG, 2006, p.7.

Para cada nível de maturidade foi estabelecido um conjunto de processos, e cada


um destes processos possui uma estrutura, que ao mesmo tempo é informativa e foca em
resultados: metas do processo, abordagem, extensão, revisão, percepção e medidas de
performance. As empresas que desejam ter seu nível de maturidade para gerenciamento de
programas não poderão obter um nível de maturidade maior que o atingido no gerenciamento
de projetos, assim como o nível de maturidade atingido com portfólios não pode ser maior
que o de programas.
68

A certificação em P3M3 para empresas é conduzida pela APM Group através de


um questionário de acordo com seus processos de certificação, a mesma empresa que realiza
as certificações profissionais na metodologia em gestão de projetos PRINCE2.
O questionário de avaliação deve ser aplicado por um consultor registrado de
acordo com o processo de credenciamento da APMG. As observações e recomendações do
consultor serão avaliadas pela APMG, que irá atribuir a Avaliação de Nível de Maturidade
para a organização. Para obtenção da certificação, há um número mínimo de perguntas a
serem respondidas, e uma lista mínima de pessoas que devem responder as questões.
O objetivo da certificação vai além da avaliação, procurando também fornecer a
empresas um guia para melhoria de performance e maturidade para a organização.

1.4.3. PROJECT MANAGEMENT PROCESS MATURITY (PM²) MODEL

Inicialmente, o modelo de maturidade Project Management Process Maturity


Model (PM²) teve o nome de “The Berkeley Project Management Process Maturity Model”, já
que foi desenvolvido pelo professor Youg Hoon Kwak, da Berkeley University, juntamente
com o professor C. William Ibbs, da George Washington University.
Este modelo de maturidade resultou de dois processos: do estudo e comparação de
diversos modelos de maturidade em projetos e em desenvolvimento de produto, e do
benchmarking dos processos e práticas em gestão de projetos em 43 empresas.
O PM² adota a integração dos diversos modelos de maturidade em empresas de
quaisquer setores, e divide as práticas em gerenciamento de projetos em nove áreas do
conhecimento e cinco processos, de acordo com as práticas do PMBOK. Como a maioria dos
modelos de maturidade mais conhecidos, o PM² adota também os cinco níveis de maturidade
e o conceito de melhoria contínua comum à grande maioria dos modelos de maturidade
(KWAK; IBBS, 2002). Segundo Hartman e Skulmoski (1998), o PM² tem ligeira semelhança
com o modelo CMMI da SEI.
Segundo Kwak e Ibbs (2000), as grandes contribuições do modelo PM² estão
exatamente na possibilidade de uso do modelo em empresas dos mais diferentes setores e
também na força que o modelo possui em relação à área financeira, através de medição da
efetividade financeira de acordo com dados reais relacionados a gestão do projeto, são
checadas a relação entre efetividade do projeto e performance do projeto e é estabelecido um
69

retorno do investimento do projeto (PM/ROI) , derivado da mensuração e projeção dos


benefícios potenciais do investimento no projeto.

1.4.4. O MMGP – MODELO DE MATURIDADE EM GESTÃO DE PROJETOS

O MMGP (Modelo de Maturidade em Gestão de Projetos) ou MPCM (Maturity by


Project Category Model) foi desenvolvido de 1999 a 2002, pelo consultor brasileiro Darci
Prado, com base em sua experiência profissional como consultor. Sua criação teve como
objetivo inicial auxiliar a equipe de gerenciamento de projetos da Consultoria INDG no
diagnóstico do estágio de maturidade em que se encontravam as empresas para as quais
prestavam serviços.
Embora possa ser aplicada a toda uma organização, o modelo MMPG é conhecido
como setorial, ou seja, é aplicado separadamente em cada setor de uma organização, tomando
por base a teoria de que cada área da empresa possui diferentes níveis de maturidade.
(PRADO, 2005)
O MMPG utiliza-se de dois conceitos chaves, os níveis de maturidade e as
dimensões da maturidade. São seis dimensões da maturidade, sendo estas: conhecimento de
gerenciamento - que compreende: conhecimento de gerenciamento de projetos e
conhecimento de outras práticas de gerenciamento empregadas na empresa; uso prático de
metodologias; informatização; relacionamentos humanos; estrutura organizacional e
alinhamento com os negócios na organização.
Os cinco níveis de maturidade do modelo MMGP são:
• Inicial (ad hoc): baixo conhecimento, uso da intuição, inexistência de
metodologia;
• Conhecido: aumento no nível de conhecimento, iniciativas isoladas;
• Padronizado: mapeamento de processos, uso de metodologia e informatização,
alinhamento com a estratégia, e uso de padrões pelos gerentes de projeto;
• Gerenciado: processos e padrões são aceitos e praticados, causas de erros
identificadas e eliminadas, relacionamentos humanos eficientes.
• Otimizado: otimização de custos, prazos, qualidades e processos de
gerenciamento.
As seis dimensões permeiam os cinco níveis, de acordo com o quadro abaixo:
70

Dimensões da Níveis de Maturidade


Maturidade Inicial Conhecido Padronizado Gerenciado Otimizado
Conhecimento Disperso Básico Básico Avançado Avançado
Tentativas Implantada e
Metodologia Não há Melhorada Estabilizada
isoladas padronizada

Tentativas Tentativas
Informatização Implantada Melhorada Estabilizada
isoladas isoladas
Estrutura
Não há Não há Implantada Melhorada Estabilizada
Organizacional
Relacionamentos Boa Algum Algum
Avanço Motivadas
Humanos vontade avanço avanço
Alinhamento
com as Não há Não há Não há Alinhado Alinhado
estratégias
Quadro 10: Dimensões e níveis de maturidade do MMGP.
Fonte: Prado, 2005

O nível de maturidade da empresa é determinado pelo preenchimento de um


questionário de 40 questões no qual é atribuída uma pontuação de acordo com suas respostas.
De acordo com Prado (2005), o MMGP apresenta como grandes contribuições sua
simplicidade e facilidade de uso, além de aderência à realidade das empresas brasileiras, já
que foi elaborado a partir de informações das mesmas, além de permitir que seja estabelecido
às empresas avaliadas um plano de crescimento.

1.4.5. O MPS.BR – MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO

O MPS.BR não é definido como um modelo de maturidade, entretanto, utiliza-se


de conceitos semelhantes ao CMMI e outros modelos de maturidade, e influencia nos
resultados desta pesquisa.
O programa Melhoria de Processo de Software Brasileiro é um programa
mobilizador, resultado do esforço contínuo nas duas últimas décadas para a melhoria da
qualidade da produção de software no Brasil.
Por programa mobilizador podemos compreender:

um programa capaz de arregimentar, aglutinar organizar e por em


movimento, ou criar o potencial necessário para uma ação política que vise
o desenvolvimento econômico, social e/ou militar, por meio do domínio,
71

uso, aperfeiçoamento ou geração de conhecimento empíricos, intuitivos,


científicos e tecnológicos ou inovações que resultem em processos,
produtos sistemas ou serviços novos ou substancialmente melhorados. Ele
é, em geral, composto por um conjunto articulado de projetos de pesquisa
básica, pesquisa aplicada, de desenvolvimento experimental, de engenharia
não rotineira e de comercialização pioneira, conduzido, cooperativamente,
por empresas, órgãos governamentais, universidades, centros e institutos de
pesquisa, e outros atores da área científica e tecnológica. (LONGO, 2005,
p.1535)

O MPS.BR foi iniciado pela Associação para a Promoção da Excelência do


Software Brasileiro (SOFTEX) e envolveu universidades, centros de pesquisa, organizações
atuantes na área de melhoria de processo de software, instituições implementadoras e
instituições avaliadoras. Também é apoiado pelo Ministério da Ciência e Tecnologia, e pela
FINEP – Financiadora de Estudos e Projetos. A partir de 2005, passou a contar com o apoio
do BID – Banco Interamericano de Desenvolvimento, através do FUMIN – Fundo
Multilateral de Investimento.
Com o objetivo de melhoria no processo de produção do software brasileiro, o
MPS.BR possui duas grandes metas estabelecidas, uma sendo técnica, e outra de
disseminação do programa no mercado brasileiro, divididas em macroatividades: (WEBER et
al, 2006)

Meta 1 – técnica
• Criação e aprimoramento do programa MPS. BR;
• Capacitação por meio de programas de treinamento, composto de cursos,
provas e workshops a um custo viável;
• Credenciamento de instituições implementadoras;
• Credenciamento de instituições avaliadoras.

Meta 2 – disseminação
• Criação e aprimoramento de um modelo de negócios para o MPS.BR;
• Implementação do MPS.BR em pequenas e médias empresas a um custo
viável;
• Avaliação do MPS.BR nas empresas a um custo viável.

O MPS.BR é composto de um Modelo de Referência e um Método de Avaliação


que estão em conformidade com a as normas ISO/IEC 122007 e ISO/IEC 15504, são
72

compatíveis com o CMMI e com foco na realidade das empresas brasileiras. Além destes dois
componentes, o MPS.BR possui um Modelo de Negócio. Cada um dos componentes é
composto por outros documentos conforme a figura abaixo.

Modelo MPS
ISO/IEC 12207
ISO/IEC 15504
CMMI

Modelo de Modelo de Modelo de


Referência Avaliação Negócio
(MR- MPS) (MA- MPS) (MN- MPPS)

Guia Guia de Guia de Documento do


Geral Aquisição Avaliação Programa

Esquema 7: Estrutura do programa MPS.BR


Fonte: WEBER et al, 2006, p.3.

1.4.5.1. Definição

O MPS.BR é composto por níveis de maturidade, patamares de evolução de


processos, seqüenciais e cumulativos. São sete os níveis de maturidade, numa escala
decrescente de maturidade: A (Em otimização), B (Gerenciado Quantitativamente), C
(Definido), D (Largamente Definido), E (Parcialmente definido), F (Gerenciado), G
(Parcialmente Gerenciado). (Weber et. al, 2004)
Segundo Weber et al.(2006), a graduação em sete níveis permite uma
implementação e um reconhecimento mais gradual da melhoria do processo de produção de
software e uma visualização de resultados em prazos mais curtos, o que facilitaria a sua
aquisição por parte de pequenas e médias empresas.
Os níveis do MPS.BR tem relação com os níveis do CMMI, conforme quadro
abaixo:
73

2 3 4 5 CMMI

G F E D C B A MPS.BR

Menor Maior
maturidade maturidade

Esquema 8: Comparação entre os níveis MPS.BR e CMMI


Fonte: elaboração própria

Os níveis E e D são intermediários aos níveis 2 e 3 do CMMI e o G é


intermediário aos níveis 1 e 2 do CMMI.
O relacionamento entre o MPS.BR e o CMMI foi proposital, de maneira a permitir
às organizações que os esforços utilizados na melhoria de seus processos sejam reconhecidos
por diversas avaliações.
O MPS.BR é composto por quatro documentos (Weber et. al, 2006):
• Guia Geral: contém a descrição geral do MPS.BR, e apresenta os conceitos
necessários para o entendimento e aplicação do programa.
• Guia de avaliação: apresenta o Método de Avaliação do MPS.BR e apresenta
basicamente o processo de avaliação, o método de avaliação e a qualificação
necessária para os avaliadores.
• Guia de Aquisição: apresenta um processo de aquisição de software e serviços
em conformidade com a norma ISO/IEC 12207, e o relacionamento entre esta
norma e o MPS.BR.
• Modelo de Negócios: O modelo de negócio do MPS.BR é formado por três
esferas: a gestão do programa, pela SOFTEX, as instituições implementadoras
e avaliadoras, empresas e grupos de empresas. O documento MN-MPS
(Modelo de Negócios-MPS), é formado por um modelo de negócio cooperado
nos quais várias pequenas e médias empresas usufruem dos processos de
melhoria de software ou um modelo de negócio específico, no qual uma única
empresa usufrui das melhorias.
74

1.4.5.2. O futuro do MPS.BR

Segundo Weber (2007), até junho de 2007, o Brasil contava com cerca de 40
empresas com certificação em MPS.BR, a meta até o final de 2008 é atingir 100 certificadas.
Também em 2008, o grupo que conduz os trabalhos do MPS.BR pretende divulgar resultados
quantitativos evidenciando os resultados do modelo de maturidade em termos de custo, prazo,
produtividade, qualidade, satisfação do consumidor e retorno sobre o investimento.
Também é planejada a expansão do modelo para os países da América Latina e
para outros paises com estrutura de produção de software semelhante ao Brasil.

1.4.6. O PMMM - PROJECT MANAGEMENT MATURITY MODEL

O PMMM (Project Management Maturity Model) foi desenvolvido pelo


pesquisador Harold Kerzner em 2001, e é uma combinação dos conceitos do PMBOK e do
CMM, antecessor do CMMI. Este modelo introduz a ferramenta do benchmarking para
mensuração do seu nível de maturidade com cinco fases (RABECHINI e PESSÔA, 2005,
KERZNER, 2002):
• linguagem comum: primeiro estágio de reconhecimento por parte de uma
organização sobre a necessidade de uma metodologia em gerenciamento de
projetos;
• processos comuns: segundo estágio, no qual há a necessidade de processos
comuns objetivando repetir o sucesso obtido em projetos passados, e evitar
erros cometidos;
• metodologia singular: terceiro estágio, em que as várias metodologias em
gerenciamento de projeto existentes na organização são combinadas sob um
único eixo;
• benchmark: quarto estágio, no qual a empresa estabelece comparações entre
suas práticas gerencias com a de outras empresas, buscando obter informações
que possibilitem a melhoria na condução de seus projetos;
75

• melhoria contínua: as informações obtidas no nível anterior são utilizadas e


implementadas, buscando a melhoria contínua nos processos de condução dos
projetos.

Nível 5
SOBREPOSIÇÃO Melhoria
Contínua
Nível 4
Benchmark

Nível 3
Metodologia
Singular
FEEDBACK
Nível 2
Processos
Comuns
Nível 1
Linguagem
SOBREPOSIÇÃO
Comum

Esquema 9: O modelo PMMM


Fonte: KERZNER, 2002, p.197.

Conforme figura à cima, o modelo pressupõe a sobreposição entre níveis:


• Sobreposição entre os níveis 1 e 2 – durante o estabelecimento de processos
comuns, a empresa pode ainda aprimorar a linguagem comuns;
• Sobreposição entre os níveis 3 e 4 – enquanto a empresa desenvolve a
metodologia, o benchmarking pode auxiliar no aprimoramento dessa
metodologia;
• Sobreposição entre os níveis 4 e 5 – à medida que a empresa evolui o
benchmarking e a melhoria contínua passa a fazer parte de um processo
rotineiro, a velocidade das mudanças aumenta, e faz com os haja uma
sobreposição e feedback do nível 5 para os níveis 3 e 4, aumentando a
sobreposição, propiciando uma evolução contínua ao longo do tempo.
Para Kerzner (2002), o nível 3 representa o nível de maior risco e maior grau de
dificuldade para a organização. Após atingi-lo, os níveis 4 e 5 possuem um baixo grau de
dificuldade, entretanto, para atingir o nível 3, a empresa deve passar por drásticas mudanças
culturais.
76

1.4.7. O OPM3 (ORGANIZATIONAL PROJECT MANAGEMENT MATURITY MODEL)

O OPM3 (Organizational Project Management Maturity Model) é o modelo de


maturidade em gerenciamento de projetos desenvolvido pelo PMI, com início de sua
elaboração em 1998. Foi lançado em 2003 e tem como foco o gerenciamento sistemático de
projetos, programas e portfólios, associado aos objetivos estratégicos.
Para seu desenvolvimento, foram recrutados mais de 800 profissionais voluntários
da área de Gerenciamento de Projetos para a análise de 27 modelos de maturidade além de
alinhamento completo com o PMBOK resultando nas 600 melhores práticas, avaliadas através
de 151 questões de respostas fechadas, que compõem as principais capacidades inerentes ao
gerenciamento de projetos (RABECHINI; PESSÔA, 2005). Expostos a seguir:
• Padronização e integração de métodos e processos - visando estabelecimento
de uma linguagem comum a todos os envolvidos com gerenciamento de
projetos, atingida pela padronização de documentos;
• Desempenho e métricas - estabelecimento de medidas de desempenho, com
ênfase em custos, prazos e qualidade;
• Comprometimento com procedimentos de gerenciamento de projetos – criação
de políticas de gerenciamento atreladas a metas;
• Priorização de projetos e alinhamento estratégico – geração de projetos que
sustentem as estratégias da empresa;
• Melhoramento contínuo – garantia de formação de um banco de conhecimento
dos projetos, que permita evitar falhas em projetos futuros;
• Estabelecimento de critérios de sucesso – identificar projetos com valores
adequados às estratégias da empresa;
• Pessoas e competências - criação de ferramentas formais de avaliação de
competências das equipes de projetos;
• Alocação pessoal – auxiliar no estabelecimento de prioridades dos projetos de
acordo com as estratégias da empresa,
• Aspectos organizacionais – formação das estruturas das equipes de projetos de
acordo com a estrutura organizacional vigente;
• Equipes - formação de uma cultura de projetos que permita estabelecer em
conjunto níveis de inovação e criatividade.
77

Este modelo de maturidade é composto por quatro conceitos chaves: best pratices,
capabilities, outcomes, e KPIs (key performance indicators). Cada best pratice é formada por
um número de capabilities. Cada capability é formada por um outcome, a evidência de que a
capability existe ou foi atingida pela organização. O KPI é uma métrica quantitativa ou
qualitativa indicativa deste outcome. (FAHRENKROG et al, 2003)
As best pratices podem ter relação entre si, assim como as capabilities de uma
best pratice e de outra, conforme figura abaixo:
PRATICES
BEST

A B

A3 OUTCOME
B3
KPI
CAPABILITIESS

A2 OUTCOME
B2
KPI

A2 OUTCOME
B2
KPI

Esquema 10: O modelo OPM3


Fonte: FAHRENKROG et al, 2003 p.3.

No exemplo acima, a best pratice A só é atingida com a obtenção das capabilities


A1, A2 e A3, cada qual formada por uma outcome e seu respectivo KPI. Para obtenção da
best pratice B, é necessário obter a best pratice A e para obter a capability B3 é necessário
conseguir a capability A2, demonstrando a relação de dependência entre as best pratices e
suas capabilities.
O modelo também utiliza os conceitos de níveis, utilizando-se de quatro níveis
(padronizado, medido, controlado e melhoria contínua) cruzado com os Grupos de Processos
de Gerenciamento de Projetos (PMI, 2004):
• processos de iniciação: autorização para o projeto;
• processos de planejamento: definição e seleção das ações e alternativas a
serem tomadas para o cumprimento dos objetivos estabelecidos pelo
projeto;
78

• processos de execução: coordenação de pessoas e recursos para condução


do projeto;
• processos de controle: estabelecer medidas e pontos de monitoramento
regulares para verificação do andamento do projeto e definição de ações
para correção se necessários;
• processos de finalização: aceitação formal do projeto, com cumprimento
dos objetivos.
Assim, cada best pratice encaixa-se num ponto de uma matriz tridimensional que
se localiza dentro de um cruzamento entre os Grupos de Processo de Gerenciamento de
Projetos, os níveis de maturidade, e se estamos tratando de gestão de projetos, gestão de
programas ou gestão de portfólios.
No OPM3, a empresa se auto-diagnostica e se auto-desenvolve em ciclos
evolutivos constantes. Isso ocorre devido a necessidade de uma organização de
(FAHRENKROG et al, 2003):
• saber quais são as práticas específicas em gestão de projetos (conhecimento,
habilidades, ferramentas e técnicas) que sejam mais desejadas ou úteis para seu
funcionamento;
• um método que possibilite contrapor seu atual status em gerenciamento de
projetos em relação as práticas desejadas;
• saber como melhorar a si mesma contra determinadas capabilities identificadas
como necessidade de melhoria.
No quadro a seguir são comparados os diferentes modelos de maturidade expostos
aqui:
CMMI MPS.BR OPM3 P3M3 PM² PMMM MMCP
Origem CMM
CMM CMM PMI CMM CMM CMM
PMI
Representação Estagiada
Estagiada Contínua Estagiada Estagiada Estagiada Estagiada
contínua
Abrangência Projetos Projetos
Projetos Projetos Programas Programas Projetos Projetos Projetos
Portfólios Portfólios
Certificação? SIM SIM NÃO SIM NÃO NÃO NÃO
Resumo Um dos modelos Modelo Não existe O modelo afirma Possibilidade de Este modelo Modelo
pioneiros, trouxe brasileiro. certificação, a que os níveis de uso do modelo introduz a brasileiro.
grandes Possui amplo empresa realiza o maturidade em empresas ferramenta do Construído
contribuições para a apoio por processo de indicam como a as dos mais benchmarking através da
área de engenharia parte do diagnóstico e áreas de processos diferentes para experiência em
de software, governo. avaliação de si podem estruturar setores. Forte mensuração do consultorias é
amplamente Possui mais mesma; hierarquicamente em relação à seu nível de aplicado
difundido e níveis de Foca o as organizações, área financeira maturidade. separadamente
conhecido maturidade gerenciamento fazendo com que através de O modelo em cada setor
mundialmente. que o CMMI, sistemático de as metas de medição da pressupõe a de uma
Devido à sua buscando uma projetos, programas melhoria sejam efetividade sobreposição organização,
utilização inicial evolução mais e portfólios, reais e financeira de entre níveis. tomando por
atrelada a produção consistente. associado aos perceptíveis. acordo com É apresentado base a teoria
de software têm tido Procura objetivos dados reais como um dos deque cada área
dificuldade para conquistar estratégicos. relacionados a modelos de da empresa
ampliar seu leque de pequenas e É apontando como gestão do maturidade possui
aplicações. médias modelo promissor projeto pioneiros para diferentes
empresas. devido ao seu aplicação níveis de
vínculo com o PMI genérica em maturidade.
e a metodologia projetos, e não
PMBOK. apenas em
software.
Quadro 11: Comparação entre modelos de maturidade
Fonte: Elaboração própria

79
80

1.5. TEORIA INSTITUCIONAL

A Teoria Institucional é definida como:

O resultado da convergência de influências de corpos teóricos originários


principalmente da ciência política, da sociologia e da economia, que
buscam incorporar em suas sobreposições a idéia de instituições e de
padrões de comportamento, de normas e de valores, de crenças e
pressupostos, nos quais se encontram imersos indivíduos, grupos e
organizações. (MACHADO-DA-SILVA E GONÇALVES, 1998,
p.221)

Devido a esta variedade de níveis de análise e ao objetivo das teorias sob o título
de Teoria Institucional ocorre a ausência de consenso entre os principais conceitos, métodos e
formas de mensuração nas pesquisas sob abordagem. (MACHADO-DA-SILVA E
GONÇALVES, 1998).
Dois elementos definem a institucionalização em organizações: um como uma
regra, um fato social, qualidade de um padrão organizado de ações e uma incorporação nas
estruturas formais; outro como um aspecto formal da organização que não está ligado a atores
particulares. (ZUCKER, 1977)
O trabalho de Meyer e Rowan (1977): Institucionalized organizations: formal
structure as myth and ceremony, publicada no “American Journal of Sociology” é tratado
como um grande marco dentro do pensamento vigente a respeito das estruturas das firmas na
época. Neste trabalho, Meyer e Rowan fornecem às estruturas um revestimento de significado
social compartilhado, sendo utilizado para informar um público interno ou externo sobre o
caráter da empresa.( TOLBERT; ZUCKER, 1998).
Apesar de outros autores já terem citado a presença de fatores simbólicos dentro
das organizações, o trabalho de Meyer e Rowan contribuiu no sentido de impor um “esforço
sistemático para compreender as implicações do uso da estrutura formal para propósitos
simbólicos, particularmente no sentido de ressaltar as limitações de explicações de cunho
mais racional da estrutura”. (TOLBERT; ZUCKER, 1998, p.200).
O estudo de Meyer e Rowan (1977) gerou três grandes implicações:
• Quanto mais mitos racionais institucionalizados um ambiente possuir, mais
eles farão parte de uma organização formal, como por exemplo, muitos
programas, políticas e procedimentos das empresas que são exigidos pela
81

opinião pública, pelo conhecimento legitimado, pelo sistema educacional,


pelas leis ou pelo prestígio social. Uma estrutura formal pode ser adotada
independentemente de existirem problemas específicos envolvendo
coordenação e controle das atividades dos membros que a ela pertencem.
• As premissas anteriormente existentes, relacionando o desempenho e a
estrutura formal, nos quais as organizações ineficientes são eliminadas dentro
de seu ambiente competitivo, e a premissa de que a forma condiz com as
demandas dos seus ambientes produtivos, como forma de sobrevivência, caem
por terra. Empresas que incorporam mitos institucionalizados são mais
legítimas, mais bem sucedidas e mais predispostas à sobrevivência. A
avaliação social de uma empresa (e conseqüentemente sua sobrevivência) pode
estar mais vinculada à observação de suas estruturas formais internas, que
podem ser funcionais ou não, do que propriamente ao resultado das tarefas
desempenhadas pela firma.
• Os comportamentos dos membros de uma empresa e suas estruturas formais
em relação às atividades do dia-a-dia podem ser negligenciados. Em ambientes
mais institucionalizados, são dedicados mais tempo e esforços para gerenciar a
imagem e o status da organização.
Estes argumentos impactaram diretamente as relações pré-estabelecidas por teorias
anteriores entre as estruturas e os comportamentos racionais dos membros pertencentes a ela,
como forma de controle e coordenação das atividades. (TOLBERT; ZUCKER, 1998)
Produtos, serviços, técnicas, políticas e programas funcionam como poderosos
mitos, e muitas organizações os adotam de maneira cerimonial, o que conflita com os
objetivos de eficiência, coordenação e controle. Para manutenção do ato cerimonial, as
empresas utilizam-se de recursos para manter uma estrutura formal desconforme às suas
atividades de trabalho. (MEYER; ROWAN, 1977).
Tecnologias são institucionalizadas e tornam-se mitos atrelados a organizações:
procedimentos técnicos de produção, contabilidade, seleção pessoal e processamento de dados
são aceitos como corretos para o cumprimento dos objetivos organizacionais, estabelecendo,
portanto, que a organização é apropriada, racional e moderna. O crescimento de estruturas
racionais institucionais torna as organizações formais mais comuns, fáceis de criar e mais
necessárias, de forma a evitar ilegitimidade. (MEYER; ROWAN, 1977).
Para Machado-da-Silva, Fonseca e Crubellate (2005) a legitimidade é o elemento
que permite a manutenção ou a mudança das instituições. Dúvidas quanto à adequação de
82

práticas, normas ou procedimentos devido a pressões internas ou externas podem não permitir
o processo de institucionalização, causando a perda de legitimidade.
Conforme as conexões nas sociedades tornam-se mais intensas, cresce o número
de mitos. Os mitos desenvolvidos por organizações e difundidos pelas redes relacionais têm
sua legitimidade baseada na efetividade. Entretanto, ocorre o crescimento de técnicas
ambíguas e variáveis com resultados difíceis de serem mensurados, fazendo com que
participantes internos e externos utilizem regras institucionalizadas baseadas apenas em
confiança em resultados. (MEYER; ROWAN, 1977).
Os esforços para moldar um ambiente organizacional ocorrem através de duas
dimensões: primeiro, poderosas organizações forçam empresas em seu âmbito de relações a
alterarem suas estruturas e relações; segundo, poderosas organizações tentam desenvolver
seus objetivos e necessidades diretamente como regras institucionais. Os ambientes
organizacionais podem ser definidos como um agregado de organizações que constituem uma
área institucional reconhecida, como fornecedores-chave, consumidores, agências de
regulamentação, e outras organizações que produzem serviços e produtos semelhantes.
(DiMAGGIO; POWELL, 1983; MEYER; ROWAN, 1977)
Ambientes institucionalmente elaborados tornam-se sensíveis a critérios externos
de valor, geralmente apresentados através de mecanismos cerimoniais de avaliação, que
demonstram a adequação social daquela organização, garantindo assim sua capacidade de
captação de recursos e aumentando suas chances de sobrevivência. Entretanto, esta garantia
de sobrevivência só é possível em ambientes altamente institucionalizados. (MEYER;
ROWAN, 1977)
Zucker (1987) vincula a existência de um ambiente institucionalizado a três
princípios:
• Processos institucionais derivam de um desvio sobre a racionalização;
• Instituições estão comumente ligadas a fatores externos à organização;
• Institucionalização gera ineficiência, devido a adequações da estrutura interna
para atender aos processos institucionais.
De forma a resolver os conflitos existentes entre a eficiência e a adoção de mitos
institucionalizados, as organizações buscam proteger suas estruturas formais através da
avaliação e inspeção de naturezas cerimoniais, além de demonstrações elaboradas de
confiança, satisfação e boa fé, interna e externamente. (MEYER; ROWAN, 1977)
83

1.5.1. PROCESSOS DE INSTITUCIONALIZAÇÃO

Berger e Luckmann (2005), partindo de trabalhos de tradição fenomenológica,


citam a institucionalização como um processo central na criação e perpetuação de grupos
sociais duradouros. A legitimação não se faz necessária numa primeira fase de
institucionalização, isto acontece apenas quando surge a necessidade de transmissão da ordem
institucional para gerações futuras, quando o caráter das instituições não pode mais ser
sustentado pelo indivíduo. Para sua manutenção é necessário que haja explicações e
justificativas, mecanismo pelo qual se dá a legitimação. Há uma ênfase sobre a legitimação
das regras institucionais, mitos e crenças como formadores da realidade social. São
apresentados quatro níveis de legitimação:
• Primeiro nível: legitimação inicial, presente nas primeiras experiências
humanas com a lingüística, como por exemplo, quando uma criança aprende
que outra criança é um “primo”, fazendo com que, de forma inerente e
imediata, se legitime a conduta com relação aos primos ao mesmo tempo.
• Segundo nível: proposições teóricas de forma rudimentares, altamente
pragmáticas, como por exemplo: provérbios, máximas morais, lendas, etc.
• Terceiro nível: contém teorias explícitas de um setor legitimado em termos de
um corpo diferenciado de conhecimento, que são transmitidas por pessoas
especializadas que as transmitem por meio de procedimentos de iniciação
padronizados, devido ao seu alto grau de complexidade, afastando-se da
realidade em direção à teoria pura;
• Quarto nível: universos simbólicos, no qual a legitimação não pode ser
experimentada na vida cotidiana, mas através de “experiência teóricas”, ocorre
a criação de um universo paralelo ao real, legitimado.
O resultado do processo de institucionalização é uma tipificação de ações tornadas
habituais por tipos específicos de atores. Desta maneira, estas ações habituais são resultados
de comportamentos utilizados por certo grupo de atores sociais de maneira recorrente na
solução de problemas da mesma natureza. Com o tempo, estas ações são utilizadas para
tomada de decisões de maneira habitual como resposta a estímulos particulares. O
desenvolvimento recíproco de definições compartilhadas ou significadas, vinculados a estes
comportamentos habituais, resulta no conceito de tipificação. (BERGER; LUCKMAN, 2005).
84

Dentro do processo de institucionalização, são desenvolvidos dois processos em


seqüência: a habitualização - o desenvolvimento de comportamentos padronizados para a
solução de problemas e sua associação destes aos estímulos particulares; e a objetificação - o
desenvolvimento de significados gerais socialmente compartilhados ligados a estes
comportamentos, transpondo ações para contextos fora de sua origem.
Os processos seqüenciais (habitualização, objetificação e sedimentação)
pressupõem a existência de diversos níveis de institucionalização, com diferentes graus de
avaliação crítica, modificação e até mesmo eliminação, resultado do quanto certos
comportamentos estão enraizados nos sistemas sociais das empresas. (TOLBERT; ZUCKER,
1998).
Complementarmente, Berger e Luckmann (2005) criam o conceito de
exterioridade, que trata do grau em que as tipificações são vividas como detentoras de
realidade própria, relacionada a continuidade histórica das tipificações, incluindo a sua
transmissão aos novos membros da organização. Ou seja, ocorre desta maneira um processo
de sedimentação. A exterioridade dos comportamentos facilita a sua transmissão e em
conseqüência o nível de institucionalização.

Legislação

Mudanças Forças de
tecnológicas mercado

Inovação

Habitualização Objetificação Sedimentação

Monitoramento Teorização Impactos Defesa de grupo


interorganizacional positivos de interesse

Resistência
de grupo

Esquema 11: Processo de Institucionalização


Fonte: TOLBERT; ZUCKER, 1998, p.207.
85

1.5.1.1. Habitualização

A habitualização trata do processo de geração de novos arranjos estruturais em


resposta a questões específicas, bem como da formalização dos arranjos sob a forma de
políticas e procedimentos em organizações ou conjunto delas que se deparam com problemas
semelhantes. As estruturas assim geradas podem ser consideradas como pertencentes a um
período de pré-institucionalização. Nesta fase, as estruturas serão provavelmente adotadas por
um número pequeno de empresas similares, envolvidas num contexto de problemáticas muito
semelhantes.

1.5.1.2. Objetificação

A objetificação trata de um movimento no sentido de consolidação dos arranjos,


no qual os processos e procedimentos encontram-se num estado mais permanente e difundido.
Ocorre o desenvolvimento de um “consenso social entre os decisores da organização a
respeito do valor da estrutura, e a crescente adoção pelas organizações com base nesse
consenso”. (TOLBERT; ZUCKER,1998, p.207)
Aguarda-se que os resultados de determinadas mudanças tornem-se generalizáveis,
e o resultado da adoção por determinados grupos de empresas pode ser determinante para sua
adoção por outras. Assim, a objetificação seria fruto do monitoramento das empresas em
relação às outras em seu ambiente competitivo, já que a relação custo e benefício já pode ser
mensurada na prática. Adaptar velhas invenções sociais se torna menos complicado e custoso
do que a criação de novas estruturas. (TOLBERT; ZUCKER,1998)
A tipificação leva a classificação dos atores aos quais as ações estão associadas,
porém, ao longo do processo de institucionalização, as ações habituais acabam por se
desvincular dos atores específicos da ação original, resultando na objetificação (Zucker;
1977).
O processo de monitoramento pode ser realizado através de evidências coletadas
por meio de várias fontes, como noticiários e observação direta para avaliação dos riscos de
adoção da estrutura. A existência de categorias culturais, como por exemplos fóruns, expande
86

a interação entre os membros e amplifica o monitoramento. A difusão, gerada por categorias


culturais, é acelerada e redirecionada através da teorização.

1.5.1.2.1. A teorização

Strang e Meyer (1993) definem a teorização como o desenvolvimento e a


especificação de categorias abstratas e a formação de relações padrões como causa e efeito,
que podem abranger desde simples conceitos e tipologias para modelos altamente abstratos,
complexos e ricos. Quanto maior o nível de complexidade e abstração, mais rápido e
universal se torna a difusão, e mais se facilita a comunicação entre atores socialmente
distantes. Legitimados como teóricos estão cientistas, intelectuais, analistas de políticas e
profissionais.
O uso de modelos ou esquemas simplifica o processo cognitivo: pessoas tendem a
capturar de maneira mais eficiente as informações mais relevantes a partir de um esquema, a
relembrar informações de um esquema de maneira mais rápida e mais precisa. Entretanto,
pessoas podem depreender fatos dos esquemas que não correspondem à realidade.
(DiMAGGIO, 1997)
Durante o processo de escolha de estrutura, pode ocorrer a aparição de grupos de
interesse material por determinadas estruturas, ou seja, grupos que advogam por determinadas
escolhas. Estes grupos terão maior probabilidade de existir em ambientes com grande
potencial para inovação, e devem buscar cumprir duas regras de teorização: (STRANG;
MEYER, 1993)
• Definir um problema organizacional generalizável que permita definir um
grupo de atores organizacionais caracterizados por este problema;
• Justificar um arranjo formal particular com fundamentação lógica e empírica
para a resolução do problema.
Ao avaliar de forma positiva que o novo arranjo estrutural formal fornece uma
resolução ao problema, a teorização faz com que a estrutura obtenha legitimidade cognitiva e
normativa. Para aumentar o nível de persuasão, a teorização também deve apresentar
evidências de que a mudança estrutural também é bem sucedida em outros casos, de forma a
prover exemplos para outros que possam considerar adotar a estrutura. (STRANG; MEYER,
1993).
87

Todo processo de teorização leva à homogeneidade entre população ou categorias,


pois todo e qualquer modelo é uma simplificação da realidade. A teorização de práticas de
inovação também aumenta sua difusão em potencial, pois simplificam e abstraem suas
propriedades, além de especificar e explicar os resultados que produzem. Enquanto algumas
investigações teóricas verificam falhas e efeitos colaterais de uma inovação, existe um outro
grupo de investigações, em maior número, exaltando as virtudes da inovação, advogando em
nome da eficiência, justiça ou progresso. (STRANG; MEYER, 1993).
A teorização faz com que os atores enxerguem em meio a uma confusa massa de
evidências e destaquem os padrões de “sucesso”, fazendo com que a escolha de uma estrutura
torne-se uma escolha racional.
Estas estruturas disseminadas podem ser descritas como parte de um estágio de
semi-institucionalização, em que os adotantes são ainda de caráter heterogêneo, e
caracterizando a disseminação mais como normativa do que imitativa. Exemplos destes tipos
de estrutura estão nos círculos de qualidade, programas de desenvolvimento organizacional e
gerencial, consultores internos, etc.

1.5.1.3. Sedimentação

A continuidade histórica de uma estrutura leva à institucionalização total, como


resultado do processo de sedimentação. Este processo é caracterizado pela difusão total das
estruturas por todo grupo de atores que em teoria seriam os “adotantes adequados” e também
pela propagação da estrutura por período de tempo considerado longo.
O processo de sedimentação pode ser interrompido caso, mesmo com ausência de
oposição, não demonstre resultados vinculados à estrutura. Uma relação fraca entre estruturas
e resultados pode impactar negativamente o processo de difusão e manutenção da estrutura.
(TOLBERT; ZUCKER,1998)
As taxas de difusão podem variar de acordo com os níveis de interação entre os
pioneiros e adotantes potenciais. Se a prática adotada tem socialmente menor significado, a
proximidade física pode ser um dos fatores para a sua transmissão. Quando a prática tem
maior significado, entendimentos são compartilhados, explorando-se as conseqüências da
inovação através da troca de experiências entre si. (STRANG; MEYER, 1993).
88

A inércia existirá enquanto os resultados mantiverem-se positivos, e a


predisposição à mudança quando da deterioração prolongada dos indicadores de desempenho.
(JOHNSON4, 1994 apud MACHADO-DA-SILVA; GONÇALVES; 1998). Entretanto, provar
a relação existente entre a estrutura e os resultados, demonstrando seus impactos, é um
processo bastante difícil.
Podemos, então, concluir que a total institucionalização se dá devido à baixa
resistência às estruturas, promoção e apoio cultural continuado e correlação positiva com
resultados esperados.
Para Zucker (1987) a implementação de ações institucionalizadas consiste num
paradoxo nos quais as ações legitimam as rotinas existentes, gerando estabilidade, ao mesmo
tempo em que se criam elementos novos que poderão tornar-se institucionais com o tempo.

1.5.2. RITUAIS E CERIMÔNIAS

Dentro das fronteiras da Teoria Institucional, é aceito que as organizações adotam


técnicas e práticas gerenciais muito mais por questões de marketing do que propriamente para
ganho de eficiência. A despeito da possível eficiência, técnicas institucionalizadas
estabelecem que a empresa é adequada, racional e moderna, demonstrando responsabilidade e
evitando a negligência em se tornarem obsoletas. (MEYER; ROWAN, 1977). Ou seja, a
submissão às práticas institucionalizadas (ou “mitos”) pode trazer legitimidade às empresas,
mas podem ser, na realidade, ineficientes ou impraticáveis pelas organizações. Em alguns
casos, a empresa pode se submeter aos rituais e elementos simbólicos de inovação e técnicas,
sem se aprofundar no processo. (CALDAS; VASCONCELOS, 2002).
De acordo com certos teóricos, há países, comunidades ou empresas com
influência global em um determinado campo institucionalizado, e estarão sujeitos a importar
comportamentos socialmente normatizados (vindos ou imitados de fora), procurando manter
sua legitimidade em determinado campo.
Na prática, a adoção de técnicas e discurso de melhores práticas não implica
necessariamente em mudanças de comportamento. Algumas correntes teóricas afirmam que

4
JOHNSON, G. Strategic change: managing cultural process. In: FAHEY, L., RANDALL, R. The portable
MBA in strategy. New York: John Wiley and Sons, 1994
89

estas certificações estão muito mais relacionadas à imagem do que à substância


(ALVESSON5 apud CALDAS; VASCONCELOS, 2002).
A imagem pode ser definida como a percepção dos membros de uma organização
sobre como externos enxergam a organização. Identidade é o que os membros acreditam ser
as características centrais da organização à qual pertencem. A manipulação de ambos
demonstra que empresas podem atender as pressões institucionais através de respostas que
reflitam os interesses das organizações. (DUTTON; DUCHERICH´S, 1991)
Encontramos na literatura argumentos e evidências da existência do
comportamento cerimonial em empresas. Lees (1992) reconhece a cerimônia como uma das
chamadas faces do desenvolvimento empresarial, como forma de legitimar e confirmar o
progresso social dos gestores pela organização. Os rituais possuem a função de certificar a
capacidade do gestor anteriormente a sua confirmação através da função em si. Também
possuem a função social mais ampla de atrelar o gestor à organização, através da celebração
pública das dimensões críticas da cultura que o supõem ser o que o gestor representa. A
literatura de “excelência”, em particular, é repleta de exemplos de conferências, convenções,
prêmios que servem para reforçar os totens da cultura corporativa.
Entretanto, o caráter cerimonial do desenvolvimento gerencial vai além da
encenação de procedimentos sem crença ou convicção em seu conteúdo ou propósito. O
simbolismo tem sua função externa, na qual presta o papel de um rito de passagem e celebra
os valores e benefícios da organização, e uma função interna, gerando nos gestores o
significado de reconhecimento e aumento de prestígio, sentimento de satisfação e a
confirmação de uma potencial imagem de si mesmo, na qual pensamentos funcionais ou
performance são os últimos a serem considerados.(LEES,1992)
Howard, Nash e Ehrenfeld (2000) observam que muitas organizações adotam de
maneira voluntária medidas ambientais, de saúde ou segurança, não buscando gerar mudanças
efetivas, mas para criar formas de agradar aos constituintes institucionais. Em sua pesquisa,
Hackman e Wageman (1995) encontraram distâncias significativas entre a teoria desenvolvida
e os resultados obtidos nas organizações nas implantações dos programas de TQM (Total
Quality Management).
Meyer6 (1981 apud DiMAGGIO; POWELL, 1983) aponta a atitude de empresas
em mercados emergentes tender a um comportamento mimético, numa assimilação de

5
ALVESSON, M. Organization: from substance to image. Organization Studies. v.11, n.3, 1990.
6
MEYER, J. W. Remarks at ASA Session “The present crisis and the Decline in world Hegemony”. Toronto.
Canadá, 1981
90

conceitos e modelos produzidos fora de seus contextos. Tais organizações bebem direta ou
indiretamente de fontes estrangeiras, fazendo com que seus contextos empresariais resultem
num campo de trabalho e pesquisa importado. A adoção de tecnologia estrangeira por estes
países comprova um baixo grau de julgamento crítico nas empresas e uma baixa auto-estima
por parte de seus administradores e acadêmicos. (CALDAS; VASCONCELOS, 2002).

1.5.3. O ISOMORFISMO INSTITUCIONAL

Segundo os teóricos, existem dois tipos de isomorfismo, o isomorfismo


institucional e o isomorfismo competitivo. Segundo Hannan e Freeman7 (1977 apud
DiMAGGIO; POWELL, 1983), o isomorfismo competitivo ocorre em campos de competição
livre e aberta, nos quais a racionalidade está voltada para o mercado de competição e
mudança de nicho. Entretanto, Aldrich8 (1979 apud DiMAGGIO; POWELL, 1983) diz que as
empresas não competem por consumidores e recursos, mas por poder e legitimidade para um
ajuste social e econômico, resultando no isomorfismo institucional.
Mignerat e Rivard (2005) alertam para a constante confusão entre os dois tipos de
isomorfismo em pesquisas institucionais, enfatizando o fato de que nem todo processo de
imitação venha de pressões institucionais.
Abrahamson (1991) apresenta quatro perspectivas de imitação das quais nem todas
estão associadas a pressões institucionais:
• Escolha eficiente: nesta situação, devido à escassez de recursos, agentes
racionais escolhem uma inovação por permitir resultados através de uma
produção eficiente, para atingir os objetivos organizacionais;
• Seleção forçada: situação gerada pelo ambiente institucional, através dos
mecanismos de isomorfismo;
• Mania: nesta situação, a difusão de inovações ocorre entre empresas
pertencentes a um mesmo grupo;

7
HANNAN, M. T., FREEMAN, J. H., “The population ecology of organizations”. American Journal of
Sociology. 82: 929-64, 1977.
8
ALDRICH, H. Organizational and environments. Englewood Cliffs, NJ. Prentice Hall, 1979
91

• Moda: o foco das organizações está mais voltado para quais organizações
imitar do que quais tecnologias elas deve adotar. (ABRAHAMSON, 1991)
coloca as escolas de negócios e as empresas de consultoria nesta categoria. As
empresas que estabelecem modas não têm poder coercitivo, mas possuem o
poder de influenciar a origem de modas, através de sua capacidade de inspirar
organizações a confiar em suas escolhas de tecnologia e imitá-las.

O quadro abaixo apresenta a relação entre as perspectivas.

Imitação
Processo de Processo de
imitação não imitação estimula a
estimula a difusão difusão ou a
ou a rejeição rejeição
Grupo de
organizações
determina a difusão Escolha eficiente Mania
e rejeição dentro do
grupo
Influência externa
Organizações
determinam a
difusão e rejeição Seleção forçada Moda
dentro de outros
grupos.
Quadro 12: Perspectivas teóricas sobre a difusão ou rejeição de tecnologias administrativas.
Fonte: ABRAHAMSON, 1991. p.591.

Abrahamson (1991) diferencia as perspectivas de moda e mania dos mecanismos


de isomorfismos institucionais através da questão sobre incerteza. Nas abordagens
institucionais há uma total incerteza a respeito da eficiência das práticas, ou seja, elas podem
ser consideradas tanto eficientes quanto como não eficientes. Na perspectiva de moda ou
mania, entretanto, a adoção ocorre devido a incerteza em relação às eficiências das práticas.
92

Tolbert e Zucker (1998) conceituam as estruturas que não sobrevivem ao estágio


de objetificação, como moda ou mania, devido a sua duração relativamente curta ao longo do
tempo e não sedimentação.
A mudança isomórfica institucional pode ocorrer através de três mecanismos: o
isomorfismo coercitivo, o isomorfismo mimético e o isomorfismo normativo. (DiMAGGIO;
POWELL, 1983)
À medida que a atuação de uma empresa cresce, também crescem as pressões para
que suas ofertas de produtos e serviços (internos ou externos) sejam semelhantes às oferecidas
por outras organizações, o que acaba por encorajar o processo de mimetismo
Como as empresas devem assumir certas posturas como forma de ganho de
legitimidade frente ao seu campo de atuação institucionalizado, cria-se um conflito entre o
desejo de legitimidade e as exigências técnicas que buscam de forma primordial a eficiência.
Para explicar o processo de como as características organizacionais são adequadas para que se
pareçam cada vez mais com as características ambientais, a teoria a respeito da
institucionalização utiliza-se do conceito de isomorfismo institucional. (ROSSETO;
ROSSETO, 2005)
Segundo DiMaggio e Powell (1983), o isomorfismo é definido como um processo
restritivo que força uma unidade a se equiparar com outras unidades que estão sob os mesmos
conjuntos de condições ambientais. Esta abordagem sugere que há uma alteração das
configurações organizacionais no sentido de aumentar a compatibilidade com as
configurações ambientais, o número de organizações em uma população é função da
capacidade ambiental projetada e a diversidade das formas organizacionais é isomórfica à
diversidade ambiental.
O fator motivador para que as empresas adotem esta postura isomórfica em relação
às empresas líderes de seu grupo de atuação é buscar soluções em relação a problemas criados
por elas mesmas, desenvolvendo processos semelhantes de forma a facilitar sua interação
interorganizacional a partir de regras socialmente aceitas. É importante salientar que o
isomorfismo ocorre sem as expectativas de ganho de eficiência, sua razão principal reside na
idéia de que uma organização será recompensada por ser semelhante a outras em seu
ambiente organizacional (ROSSETO; ROSSETO, 2005).
O isomorfismo institucional torna-se um mecanismo importante para a
compreensão das políticas e cerimônias correntes nas organizações modernas e se apresenta
nas três formas a seguir.
93

1.5.3.1. O isomorfismo coercitivo

O isomorfismo coercitivo é resultado das forças coercitivas do ambiente, como as


regulamentações governamentais. A homogeneidade é resultado das pressões formais e
informais das outras organizações do mesmo contexto ambiental e pelas expectativas culturais
da sociedade em que estão inseridas. (DiMAGGIO; POWELL, 1983)
As empresas também mantêm formas que são institucionalizadas e legitimadas
pelo Estado, as mudanças organizacionais sendo, em alguns casos, frutos de ordens
governamentais e/ou legais, como políticas ambientais. Entretanto, o isomorfismo coercitivo
pode se dar através de mecanismos mais sutis e menos explícitos.
Quando Estados racionalizados e outras grandes organizações racionais expandem
seus domínios, as estruturas organizacionais tendem a cada vez mais refletir as regras
institucionais e legitimadas por eles e dentro deles, resultando em organizações cada vez mais
homogêneas dentro de seus campos de atuação e cada vez mais arraigadas a rituais de
conformidade. (MEYER; ROWAN, 1977)

1.5.3.2. O isomorfismo normativo

A fonte deste tipo de isomorfismo vem da profissionalização, definida como a luta


coletiva de membros de uma ocupação para definir condições e métodos de seus trabalhos e
para estabelecer uma base cognitiva e legitimação para sua autonomia ocupacional. O
crescimento da profissionalização se dá através de organizações profissionais, gerentes
particulares, e equipes especializadas de grandes corporações. As profissões estão sujeitas às
mesmas forças cognitivas e miméticas às quais estão as organizações. (DiMAGGIO;
POWELL, 1983)
Para a profissionalização, dois aspectos fundamentais são: o apoio formal à
educação e a legitimidade das bases cognitivas formadas por universitários especialistas, e a
formação e crescimento de redes profissionais por cujos meandros novos modelos são
difundidos de maneira rápida. Universidades e centros de treinamento profissional são
importantes meios de formação de normas entre gestores profissionais e suas equipes.
94

Estes mecanismos criam um grupo em que quase se permite intercambiar


indivíduos que ocupam posições semelhantes entre as empresas ao longo do ambiente. Outro
importante mecanismo na criação do isomorfismo normativo está na contratação de
profissionais, na qual muitos ambientes organizacionais contratam profissionais de
organizações da mesma indústria, o recrutamento de instituições de treinamento, através da
promoção de práticas comuns; e da necessidade de habilidades específicas em trabalhos
particulares.
O profissionalismo da gestão tende a caminhar juntamente com a estruturação de
um ambiente organizacional e poucas grandes e centrais organizações servem como modelos:
suas políticas e estruturas serão imitadas.

1.5.3.3. O isomorfismo mimético

A incerteza, fruto de objetivos ambíguos, novas tecnologias ou até mesmo do


próprio ambiente, acaba por gerar nas organizações o encorajamento da imitação, modelando-
se a outras organizações. A incerteza é um elemento comumente presente no ambiente inter-
organizacional, ainda mais em um ambiente no qual há mais empresas com pouca informação
do que bem informadas, tomando decisões estratégicas a luz das estratégias de outros.
(GALASKIEWICZ e WASSERMAN; 1989)
Ocorrem imitações de práticas, em que as empresas tentam se modelar de acordo
com empresas que consideram bem sucedidas ou mais legítimas dentro do seu campo de
atuação. A difusão destes modelos pode ocorrer de forma não intencional através da
transferência de profissionais dentro de um ambiente organizacional ou, intencionalmente,
através das empresas de consultorias e associações de comércio. Estes círculos possuem uma
série de rotinas e soluções aceitáveis para certos problemas organizacionais, que estão
arraigadas na sub-cultura das profissões. (DiMAGGIO; POWELL, 1983 ; GALASKIEWICZ;
WASSERMAN; 1989)
Embora haja uma busca pela diversidade, na realidade existem poucas variações a
serem escolhidas. Como exemplo pode-se citar o pequeno número de grandes empresas de
consultoria, que difundiram seus modelos organizacionais por grandes corporações. Tais
modelos de mudança organizacional são poderosos por terem visibilidade ao contrário de
mudanças políticas ou estratégicas, bem menos visíveis.
95

Esta imitação também possui aura ritualística, na qual uma organização tenta
adquirir legimitidade frente a seus pares e demonstrando que ao menos estão em busca de
melhorias em sua atuação garantindo assim uma imagem de “sucesso”.
De acordo com DiMaggio e Powell (1983) a onipresença de certos tipos de arranjo
é mais creditada à universalidade de processos miméticos do que a qualquer evidência
concreta de que os modelos adotados garantam eficiência. E quanto maior for a população de
empregados no processo ou clientes atendidos pela organização, maiores serão as pressões
para a conformidade.
Para Galaskiewicz e Wasserman (1989), as organizações tendem a imitar outras
que consideram conhecer e confiar, e é através das redes de relacionamentos pessoais que os
mecanismos de conhecimento e confiança se dão. As redes pessoais formadas pelo alto grau
de profissionalização e interação social gerados pela educação formal, workshops,
treinamentos, seminários, revistas especializadas, transcendem para o ambiente
organizacional.

DiMaggio e Powell (1983) estabelecem doze hipóteses relacionadas aos


mecanismos de isomorfismo: seis hipóteses vinculadas às condições da organização, e seis
hipóteses vinculadas ao campo de atuação da organização.
As organizações apresentam variação na extensão e no grau em que se tornam
mais parecidas com seus pares: algumas respondem mais depressa, outras resistem à
mudança. Em relação às condições da organização, os pesquisadores apresentam as seguintes
hipóteses:
Hipóteses 1 e 2 – relacionadas ao isomorfismo coercitivo:
H1. Quanto maior a dependência de uma organização em relação a outra, mais
similares elas se tornam em termos de estrutura, clima e comportamento;
H2. Quanto mais centralizadas forem as fontes de suprimentos de uma
organização, mais ela sofrerá transformação isomórfica.
Hipóteses 3 e 4 – relacionadas ao isomorfismo mimético:
H3. Quanto maior a incerteza, maior é a probabilidade de a empresa espelhar-se
em outras organizações que considera bem sucedidas;
H4. Quanto maior a ambigüidade nos objetivos da organização, maior será o
processo de imitação.
Hipóteses 5 e 6 – relacionadas ao isomorfismo normativo:
96

H5. Quanto maior a confiança em credenciais acadêmicas na escolha de gestores e


equipe, maior a similaridade entre as empresas em um campo de atuação;
H6. Quanto maior a participação de gestores em associações profissionais, mais
parecidas as empresas serão ou se tornarão em seus campos de atuação.

As outras seis hipóteses tratam dos efeitos esperados das múltiplas características
dos ambientes organizacionais na extensão do isomorfismo em um ambiente específico.
Hipóteses 1 e 2 – relacionadas ao isomorfismo coercitivo:
H1. Quanto maior a dependência da organização em relação a uma única (ou
algumas semelhantes) fonte de recursos vitais, maior o nível de isomorfismo;
H2. Quanto maior o número de transações com agências do Estado, maior a
extensão do isomorfismo no ambiente como um todo;
Hipóteses 3 e 4 – relacionadas ao isomorfismo mimético:
H3. Quanto menos alternativas em relação a modelos organizacionais, maior a
rapidez com que se instala o isomorfismo nesse ambiente;
H4. Quanto maior a extensão da incerteza tecnológica ou de objetivos ambíguos
no campo de atuação como um todo, maior a taxa de mudança isomórfica.
Hipóteses 5 e 6 – relacionadas ao isomorfismo normativo:
H5. Quanto mais o ambiente torna-se profissionalizado, maior a taxa de mudança
isomórfica;
H6. Quanto mais o campo torna-se mais estruturado, maior o grau de isomorfismo.

1.5.4. AS CRÍTICAS À PERSPECTIVA INSTITUCIONAL

A Teoria Institucional, a despeito de sua falta de consenso em conceitos, métricas


e métodos vêm ao longo do tempo sofrendo diversas críticas no campo de estudo das
organizações.
Machado-da-Silva, Fonseca e Crubellate (2005) atribuem as fortes críticas sofridas
pela teoria institucional, inclusive por parte de seus próprios teóricos, ao enfoque dado por
Tolbert e Zucker (1998) a um processo de institucionalização unidirecional, através dos
processos de habitualização, objetificação, e sedimentação reforçando as características
determinísticas atribuídas à mudança organizacional e aos processos de institucionalização.
97

Para os autores, a teoria institucional deve ser analisada a partir de um ponto de


vista multi-paradigmático, no qual as referências do ambiente institucional não impactam de
uma maneira linear, direta do ambiente externo para os agentes, o que torna o processo de
institucionalização dinâmico. Sob este ponto de vista, a estrutura e os agentes estão
conectados de forma recursiva, com simultaneidade em práticas sociais, desenvolvimento e
manutenção do processo ao longo do tempo.
Oliver (1991) expôs os principais pontos de críticas à institucionalização em seu
trabalho, ao afirmar que a busca pela conformidade e pela legitimidade não é fruto apenas das
pressões institucionais. Aliadas a estas pressões ambientais, a autora crê em respostas
estratégicas das organizações às pressões institucionais, nos quais as empresas podem avaliar
em termos de resistência, pró-atividade, estar alertas e de acordo com interesses próprios,
gerando cinco estratégias:
Seguir o invisível, normas
Habituar-se
aceitas como verdade.
Imitar modelos
Submeter-se Imitar
institucionais.
Obedecer a regras e aceitar
Conformidade
normas.
Equilibrar as expectativas
Equilibrar
dos múltiplos participantes.
Aplacar e acomodar os
Compromissar-se Pacificar
elementos institucionais.
Negociar com os
Barganhar
stakeholders institucionais.
Mascarar a não
Ocultar
conformidade.
Perder os vínculos
Evitar Dividir
institucionais.
Mudar metas, atividade ou
Escapar
domínios.
Ignorar normas e regras
Dispensar
explícitas.
Contestar regras e
Desafiar Contestar
requerimentos.
Atacar a fonte de pressão
Atacar
institucional.
Importar participantes
Cooptar
influentes.
Manipular Influenciar Formar valores e critérios.
Dominar participantes
Controlar
institucionais e processos.
Quadro 13: As cinco respostas estratégicas às pressões institucionais
Fonte: OLIVER, 1991, p.152.
98

Estas cinco estratégias auxiliam a compreensão das respostas das organizações às


pressões institucionais de forma a controlar a sua legitimidade em seus campos de atuação.
(MIGNERAT; RIVARD, 2005; OLIVER, 1991). Para Machado-da-Silva, Fonseca e
Crubellate (2005), o trabalho de Oliver demonstra que existem muitos elementos a serem
desenvolvidos dentro do campo da teoria institucional. Anteriormente às teorias de Oliver
(1991), Scott (1987) observa a diversidade dos conceitos dentro da teoria institucional com
otimismo, declarando a adolescência da Teoria Institucional, que, a despeito da “estranheza e
acne típicas do período”, é cheia de energia e promessas, fornecendo espaço para o
crescimento e desenvolvimento nas pesquisas desta perspectiva.

1.5.5. A PERSPECTIVA INSTITUCIONAL NO CAMPO DE ESTUDOS DE TECNOLOGIA DA


INFORMAÇÃO

Avgerou (2000) busca desafiar o pensamento corrente nas pesquisas em


Tecnologia de Informação, no qual a TI é vista como um fator de mudança organizacional de
forma a atender aos objetivos da organização, através da perspectiva institucional. Para a
autora, a inovação em TI e as práticas organizacionais funcionam como instituições, cada qual
com seus mecanismos e elementos de legitimação, interagindo à medida que a
institucionalização da TI cresce e ocorre a desinstitucionalização das práticas e estruturas em
práticas nas organizações.
A tecnologia da informação tornou-se um mito racional (MEYER; ROWAN,
1977) nos quais as aplicações da TI são aceitas como corretas no contexto das organizações
modernas.
Alguns indícios sobre a Tecnologia de Informação como instituição:
• o valor estabelecido da tecnologia e conhecimento como os principais pilares
da sociedade pós-industrial;
• uma rede de indústrias - composta por fabricantes de hardware, provedores de
serviços de telecomunicações, produtores de software, consultores – formando
uma unidade complexa que detêm os recursos materiais e conhecimento para o
processamento de informações;
• um elaborado grupo de profissionais para o desenvolvimento e uso de
aplicações de TI;
99

• um conjunto de regulamentos para o desenvolvimento e uso da TI, como


códigos de ética, direitos autorais, liberdade de informação;
• sociedades profissionais que promovem padrões de tecnologias e práticas.
O amplo uso das metodologias também envolve elementos de legitimidade, com
práticas nem sempre racionais. Metodologias implicam em padrões, uma forma de estabelecer
regulamento num ambiente de atores e empresas descentralizados, buscando atingir objetivos
institucionais. Potenciais adotantes relutam em adotar inovações “não padronizadas”, devido
às dificuldades que terão em realizar negócios no futuro e aos esforços que terão para fechar
contratos. (AVGEROU, 2000; KING, 1994).
Apesar desses fatos, o uso de metodologias não é irracional, possibilitando a
profissionalização dos desenvolvimentos de sistemas, determinando papéis com habilidades
pré-definidas, como analistas, programadores, gerentes de projeto e profissionais
especializados para sustentar uma indústria crescente. (AVGEROU, 2000). Entretanto, há
pouca pesquisa a respeito do quanto as metodologias auxiliam na construção de sistemas que
melhor atendam as organizações e poucas evidências a respeito de que sistemas com
desenvolvimento baseado em metodologias necessitem menor manutenção. (AVGEROU,
2000).
Outro indício de institucionalização da TI é a evolução da prática e da teoria na
avaliação econômica de sistemas ao longo dos anos. A avaliação de sistemas de TI passou de
uma simples e útil avaliação de investimento para um ritual cerimonial. As avaliações
tornaram-se meios para legitimar decisões de desenvolvimento com base em intuição e em
particulares setores de interesse. (AVGEROU, 2000).
Avgerou (2000) argumenta que os processos relacionados à inovação em sistemas
de informação e a busca por uma nova estrutura organizacional são desequilibrados em seus
elementos institucionais. Enquanto o uso da TI é amplamente difundido e apoiado por
diversos setores e segmentos sociais nas organizações e carregado de valor, as mudanças nas
estruturas organizacionais são questionadas. Contribui para este viés, o fato de que muitas
destas mudanças são apenas modas com, portanto, um período curto de vida.
(ABRAHAMSON, 1991). Enquanto o desenvolvimento da TI é incremental e cumulativo, as
transformações organizacionais apresentam caráter errático, buscando superar as
características de moda e a resistência cultural do regime anterior.
Como teste empírico a suas proposições, Avgerou (2000) apresenta o estudo de
caso da Pemex, uma empresa de petróleo mexicana. Na pesquisa, a organização não
apresentou questionamentos a respeito do potencial do uso da TI e a conseqüente manutenção
100

de investimentos. Entretanto, a transição de uma estrutura estatal para uma privada, com
orientação para o mercado mostrou-se um árduo processo de desinstucionalização
A adoção das inovações em TI por parte das organizações pode ocorrer de modo
descuidado, no qual novas formas de inovação não são exploradas, e outras são utilizadas
apenas porque outras organizações estão adotando, gerando assim legitimidade. Este tipo de
adoção responde a pressões coercitivas, normativas e miméticas. (MIGNERAT; RIVARD,
2005)
O governo apresenta um papel fundamental na geração das pressões coercitivas,
seja através de regulamentação, seja através de programas de desenvolvimento de
conhecimento, subsídios e estabelecimento de padrões e diretrizes. Estas intervenções
governamentais são comuns em países em desenvolvimento de forma a acelerar a inovação
em TI. Nestes países, há maior incerteza em relação a políticas adequadas para a difusão da
TI, sinalizando uma deficiência nas pesquisas buscando compreender os fatores institucionais
que geram a inovação, em particular a de TI. (KING et al, 1994)
As pressões miméticas e normativas se dão através de educação e socialização de
indivíduos, articulação de pontos de vista particulares e provisão de recursos para atividades
sociais. (KING et al, 1994)

1.5.6. A PERSPECTIVA INSTITUCIONAL EM GERENCIAMENTO DE PROJETO EM TECNOLOGIA DA


INFORMAÇÃO

O uso do termo “institucionalização” é amplamente difundido em meio aos


conceitos de modelos de maturidade, como no caso do CMMI, por exemplo. Entretanto, a
maior parte destes estudos refere-se a instituições como parte do conceito de Teoria
estruturalista e não a Teoria Institucional, utilizada neste estudo. (LIENBERG, 2005)
Mignerat e Rivard (2006) buscaram indícios da institucionalização das práticas de
gerenciamento de projetos nos projetos de sistemas de informação. Como base para a
pesquisa, as pesquisadoras recorreram a entrevistas com gerentes de projetos e membros do
PMI; de manuais utilizados em cursos de gerenciamento de projetos em TI, documentos
gerados pelo PMI (PMBOK) e pela SEI (SWEbok), currículos publicados na sessão
Communication of the ACM (Association of Computing Machinery) e Communication of the
AIS (Association for Information Systems) e na literatura de sistemas de informação.
101

Como resultados, as pesquisadoras chegaram a 60 práticas de gerenciamento de


projetos, das quais 30 delas (expostas no quadro a seguir) podem ser consideradas como
institucionalizadas, dado que eram percebidas como quase norma por parte dos gerentes de
projeto.
Gestão dos stakeholders Gestão dos prazos Relatórios de andamentos
Formulário de aprovação
Suporte a da Alta direção Definição do Baseline
do cliente
Identificação de um Definição dos marcos de Controle de mudanças de
champion projeto escopo
Identificação de um Metodologia em gestão de
Gestão de contratos
patrocinador projetos
Participação e
Análise de custos/benefício Project Charter
envolvimento dos usuários
Software para
Reunião de início Gestão dos custos
gerenciamento de projetos
Reuniões de
Análise de requisitos Estudo viabilidade
acompanhamento
Método do caminho crítico Gestão do Escopo Licitações/orçamentos
Diagrama de Gantt Lista de atividades Gestão de risco
Estrutura Analítica de
Folha de tempos Gestão da mudança
Projetos
Quadro 14: As trinta práticas institucionalizadas em gestão de projetos.
Fonte: adaptado de MIGNERAT; RIVARD (2006), p.19.

Partindo do aumento da popularidade do assunto gerenciamento de projetos,


percebido através da multiplicação de publicações, abundância na oferta de cursos e
consultoria, desenvolvimento de associações profissionais, difusão de referenciais, normas e
modelos ditos de maturidade, Leroy (2007) corrobora a pesquisa de Mignerat e Rivard (2006)
ao investigar indícios de institucionalização do gerenciamento de projetos por parte das
empresas na França, através de uma pesquisa de 10 anos, no qual encontrou as seguintes
premissas:
• quanto mais ocorrer a institucionalização do gerenciamento de projetos, maior
o significado conceitual de projetos ao longo do tempo;
102

• a gestão de projetos é uma resposta à ambigüidade dos objetivos e incertezas


tecnológicas e simbólicas, pois quanto maior a institucionalização da
orientação a projetos, maior o posicionamento dos projetos como produtos de
engenharia com métodos conhecidos e objetivos claros;
• a institucionalização do gerenciamento de projetos conduz a uma forte
utilização das ferramentas de gerenciamento de projetos;
• as empresas orientadas a projeto internalizam as pressões normativas através
da adoção de softwares de gerenciamento de projetos, formação comum,
formalização de documentação, formalização de papéis nos projetos, acesso a
consultores, etc.
Mignerat e Rivard (2006) projetaram o processo de institucionalização nas práticas
em gerenciamento de projetos de TI ao longo do tempo.

1945 1965 1980 1990 2000 ...

Abalos Pré – Teorização Difusão Plena


Institucionalização?
Instititucionalização

Esquema 12: A evolução da institucionalização em projetos de TI.


Fonte: adaptado de MIGNERAT; RIVARD, 2006. p.12.

Fase 1 – Abalo: surgimento e aumento das necessidades computacionais por parte


das organizações;
Faze 2 – Pré-institucionalização: aumentam as expectativas em relação à
necessidade da TI; ocorre a evolução das disciplinas em sistemas de informação e aumento do
interesse acadêmico pelas práticas em gestão de projetos;
Fase 3 – Teorização: ocorre uma violenta multiplicação de publicações buscando
solucionar ou explicar problemas constatados pela prática. Das 30 práticas estabelecidas como
institucionalizadas, 80% delas surgiram nesta fase;
103

Fase 4 - Difusão: o contexto era próprio para a difusão das práticas: o bug do
milênio levou muitos sistemas à obsolescência, exigindo sua troca ou modificação. Nesta fase
também ocorreu o crescimento da influência das metodologias de consultorias e da atuação de
instituições como o PMI;
Fase 5 – Plena Institucionalização? – práticas mais antigas, principalmente
relacionadas à gestão de custo, prazos e qualidades são apresentadas como institucionalizadas,
ao passo que técnicas mais recentes ou sofisticadas ainda não o são. Outro aspecto é que,
atualmente, práticas consideradas institucionalizadas por gerentes de projeto juniores não são
assim consideradas por gerentes de projetos seniores.
As práticas consideradas menos institucionalizadas por alguns gerentes de projetos
tiveram explicações interessantes, como por exemplo, em relação à gestão da comunicação e
mudança: alguns gerentes de projeto compreendem estas práticas como não sendo de sua
responsabilidade, já que as responsabilidades dos gerentes é um fator de alta variabilidade em
contextos organizacionais. Também foram encontradas diferenças entre as práticas européias
e norte-americanas, entretanto há bastante coerência dos resultados dentro dos grupos
geográficos.
Também foram encontradas evidências de que os gerentes de projetos estão cientes
das pressões institucionais do ambiente, mas voluntariamente eles cedem a estas pressões de
maneira a garantir a sua legitimidade. (MIGNERAT; RIVARD, 2006)
Machado-da-Silva e Gonçalves (1998, p 226) ressaltam a importância de se levar
em consideração o contexto institucional de referência: local, regional, nacional e
internacional, que traz

à tona a distinção analítica entre ambientes técnicos e institucionais em


diferentes níveis de análise, enriquece sobremaneira a abordagem da
dinâmica de transformação organizacional. Em sociedades mais
homogêneas as distinções podem ser pequenas, até irrelevantes. Entretanto,
em sociedades em que a diversidade de competição e mercado [...], como
parece ser o caso da sociedade brasileira, a consideração das pressões
institucionais em diferentes níveis pode propiciar interpretações mais
adequadas do fenômeno da estabilidade e da mudança organizacional.

Ayres (2003) analisa as influências institucionais especificamente nos mecanismos


de controle pelas equipes de desenvolvimento de software da Força Aérea Americana,
obtendo que diferentes perfis institucionais suportam diferentes tipos de adoção formal de
controle, quando um perfil apresentado por uma equipe de software é consistente com o perfil
institucional dominante, o uso dos mecanismos de controle será fiel a esse perfil, caso sejam
104

conflitantes, o uso de mecanismos de controle será uma mistura de cerimonial e de fidelidade.


Quanto mais antiga for a equipe de software, mais as práticas serão consistentes com antigos
contextos institucionais, e, por fim, o nível de equivalência entre os gerentes de projetos com
determinado perfil institucional terá relação positiva com a adição de controle de mecanismos
formais consistentes com esse perfil.

1.5.7. A TEORIA INSTITUCIONAL E CERTIFICAÇÕES

As pesquisas encontradas sobre certificações apresentam a relação da Teoria


Institucional com as certificações.
Caldas e Vasconcelos (2002) realizaram uma pesquisa exploratória com cerca de
70 certificações ISO 9000 no Brasil, buscando estabelecer indícios de comportamento
cerimonial e como ele ocorre.
A pesquisa tinha por metas: entender os objetivos, motivos e resultados da
certificação ISO 9000 no contexto brasileiro; investigar a presença de comportamento
cerimonial entre as empresas que se certificaram; explorar qual a maior causa deste
comportamento cerimonial, se existir, e se este comportamento se paga ao final do processo.
Como resultados os pesquisadores encontraram indícios de comportamento
cerimonial, com impactos negativos na performance, concluindo, assim, que o investimento
nas certificações não compensa.
Em 2000, Vasconcelos e Vasconcelos apresentam uma pesquisa avaliando o
processo de certificação ISO 9000 no estudo de dois casos da indústria francesa de
computadores. Foram constatadas duas formas de implementar a ISO 9000: implantação em
profundidade, compromissada com a efetividade organizacional e ainda legitimação externa, e
outra, de forma meramente instrumental, com foco apenas no ganho de legitimidade externo.
Entretanto, os autores chamam a atenção para o fato de que nem uma e nem outra
certificação gerou relevância social: na implantação em profundidade, já existia um ambiente
propício à implantação das normas e, na implantação instrumental, houve resistência e boicote
às normas, fazendo com que não houvesse “mudança na estrutura dos sistemas sociais,
práticas cotidianas, nos seus padrões culturais e jogos de poder” (VASCONCELOS;
VASCONCELOS, 2000, p.11), e que, portanto, implicam em limites às pressões normativas
em busca do isomorfismo.
105

1.5.8. DESENVOLVIMENTO TEÓRICO – PERSPECTIVA INSTITUCIONAL NAS CERTIFICAÇÕES EM


GERENCIAMENTO DE PROJETOS

O desenvolvimento teórico desta pesquisa apresenta a estrutura apresentada,


conforme no esquema abaixo:

Domínio conceitual
Domínio
TEORIA INSTITUCIONAL metodológico
Legitimidade
Isomorfismo Institucional Estudo de Caso
Rituais e Cerimônias

Resultados
da Pesquisa

Domínio substantivo

GERENCIAMENTO DE PROJETO
Modelos de Maturidade
Certificações em Modelos de
Maturidade.

Esquema 13: Estrutura da pesquisa


Fonte: adaptado de STRICKLER, 1999.

Compreendemos por domínio conceitual uma perspectiva que guia o trabalho do


pesquisador dando significado a um conteúdo, um conjunto de conceitos abstratos e
relacionamentos entre estes conceitos. Neste caso estamos utilizando como domínio
conceitual a perspectiva da Teoria Institucional, que fornece sua ótica para análise dos
conceitos do domínio substantivo. Da Teoria Institucional, utilizamos-nos principalmente dos
conceitos de legitimidade, de isomorfismo institucional, através dos seus três mecanismos:
106

coercitivo, normativo e mimético, e dos conceitos relacionados a comportamentos


cerimoniais.
Por domínio substantivo, compreendemos o conteúdo de interesse, um fenômeno
ou contexto a ser compreendido. No caso desta pesquisa, o fenômeno de interesse está na
prática em gerenciamento de projetos, mais precisamente envolvendo modelos de maturidade
em gerenciamento de projetos e a certificação obtida pelas empresas atestando um suposto
nível de maturidade.
Por fim, compreendemos o domínio metodológico como técnicas e procedimentos
através dos quais o domínio conceitual e o domínio substantivo serão estudados, um conjunto
de técnicas de coleta e análise de dados. Este trabalho, de natureza qualitativa, será
operacionalizado através de um estudo de caso em acordo com Strickler (1999).
Com base na estrutura acima, busca-se comprovar indícios de institucionalização
no processo de certificação de uma organização em gerenciamento de projetos, através da
análise de um caso de certificação de uma empresa produtora de software, certificada no
CMMI, nível 2.
Assim, os aspectos envolvendo as teorias em gerenciamento de projetos,
maturidade em gerenciamento de projetos, e certificações em gerenciamento de projetos, não
serão observados apenas sob a ótica deste corpo de conhecimento, que busca justificar o uso
de gerenciamento de projetos e a obtenção da maturidade em seu uso, para adquirir ganhos de
escala em projetos, obtendo consistência e robustez no gerenciamento de projetos, através de
normas e padronizações atestadas via certificações.
Estes aspectos também serão analisados à luz da Teoria Institucional, buscando-se
analisar, além dos aspectos da eficiência, indícios de tentativa de ganhos de legitimidade em
seu campo de atuação, pressões institucionais gerando isomorfismo, e a presença de
características cerimoniais, em detrimento de ganhos de eficiência reais, que denotam a
institucionalização do processo de certificação.
Desta forma, procura-se gerar um diálogo entre a teoria em gerenciamento de
projetos de tecnologia de informação e a teoria institucional, fornecendo uma perspectiva
institucional à certificação das organizações em modelos de maturidade em gerenciamento de
projetos.
107

METODOLOGIA

Este trabalho é de natureza explanatória, de acordo com a “Taxonomia de tipos de


teoria em sistemas de informação”, de Gregor (2006). Neste caso, a teoria busca explicar
como, por que e quando os fenômenos acontecem, buscando promover uma compreensão e
geração de insights para terceiros sobre o fenômeno de estudo. O quadro abaixo apresenta um
resumo das características dos cinco tipos de teorias em Sistemas de Informação:
Tipo de Teoria Atributos Distintos
Analítica Diz o que é.
A teoria não vai além de análise e descrição.
Não são especificadas relações causais e previsões não são
realizadas.
Explanatória Diz o que é, como, quando e onde.
A teoria provê explanação, mas não objetiva prever com precisão.
Não há proposições a serem testadas.
Preditiva Diz o que é e o que será.
A teoria provê previsões e tem proposições para ateste, mas não
tem justificativas bem construídas de explicações causais.
Explanatória e Diz o que é, como, quando e onde e o que será.
Preditiva (EP) Provê predições e possui ambas: proposições e explicações
causais.
Design e ação Diz como fazer algo.
A teoria fornece prescrições explícitas (Por exemplo: métodos,
técnica, princípios de forma e funcionamento) para a construção
de um artefato.
Quadro 15: Taxonomia de tipos de teoria em sistemas de informação
Fonte: GREGOR, 2006, p.620.

De acordo com Gregor (2006), as teorias explanatórias podem pertencer a pelo


menos dois subtipos: uma teoria usada como um dispositivo sensitivo, de forma a gerar
descobertas e gerar novos insights e outra como forma de fornecer como e por que certas
situações ocorrem em uma situação particular e específica do mundo real. Muitos estudos de
caso seguem esta última classificação, caso desta pesquisa.
108

A teoria ou conjecturas desenvolvidas através da teoria explanatória devem ser


novas e interessantes ou explanar algo que antes estava mal explicado ou mal compreendido.
Em estudos de caso é esperado mais que uma história, mas as conclusões devem levar a
alguma generalização, desde que haja justificativa, credibilidade, plausibilidade, consistência
e transferência no caso estudado.

1.6. O ESTUDO DE CASO

Um estudo de caso é uma estratégia de pesquisa que foca no entendimento das


dinâmicas presentes em configurações únicas (EISENHARDT, 1989) . Yin (2001) estabelece
três condições para a escolha da estratégia de pesquisa: o tipo de questão que motiva a
pesquisa, o nível de controle que o pesquisador possui sobre os eventos comportamentais e a
ênfase em eventos contemporâneos. A relação entre as condições e a estratégia de pesquisa é
resumida no quadro abaixo:

Há controle sobre Ênfase em eventos


Como opera a
Estratégia eventos contemporâneos ou
questão de pesquisa?
comportamentais? históricos?
Experimento Como, Por que Sim Sim
Pesquisa de Como, O que Onde,
Não Sim
campo Quanto
Análise de Como, O que, Onde,
Não Sim/Não
arquivos Quanto
Histórico Como, Por que Não Não

Estudo de caso Como, Por que Não Sim


Quadro 16: A relação entre as condições e a estratégia de pesquisa
Fonte: YIN (2001), p. 24.

Por sua vez, Bensabat, Goldstein e Mead (1987) elaboraram em seu trabalho um
quadro sumarizando diversas teorias contendo as características-chave de um estudo de caso:
• O fenômeno é examinado numa configuração natural;
• Os dados são coletados por meios múltiplos;
109

• Uma ou poucas entidades (pessoas, grupos ou organizações) são examinadas;


• Alta complexidade da unidade de análise;
• Estudos de caso são adequados a exploração, classificação e formulação de
hipóteses no processo de construção do conhecimento;
• Não há controle ou manipulação de experimentos;
• A investigação pode não especificar as variáveis dependentes e independentes;
• Os resultados dependem muito das habilidades de integração do pesquisador;
• Mudanças na escolha do local e métodos de coletas de dados podem levar à
geração de novas hipóteses;
• Estudos de caso são úteis no estudo de por que e como;
• O foco está em fenômenos contemporâneos.

Yin (2001) e Bensabat, Goldstein e Mead (1987) corroboram o argumento,


apresentado por Gregor (2006), de que estudos de caso são apropriados para o
desenvolvimento de uma teoria explanatória, operacionalizando as perguntas: o que, como por
que, onde e quando.
Eisenhardt (1989) apresenta em seu trabalho “Building Theories From a Case
Reasearch” um processo de construção de teoria a partir de um estudo de caso, resumido no
quadro a seguir:

Passo Atividade Razão


Definir questão de pesquisa. Focar esforços.
Início
Desenvolver construtos a priori. Fornece uma base melhor para
medidas de construtos.
Sem basear-se na teoria ou em Assegura flexibilidade teórica.
hipóteses.
Seleção de
População específica. Força variação externa e constrói
casos validade externa
Teórico, não aleatório, amostra. Focaliza esforços em casos
válidos teoricamente
Múltiplos métodos de coleta de Fortalece a base da teoria por
Elaboração de dados triangulação de evidências.
instrumentos e Combinar dados qualitativos e Visão com sinergia de evidências
quantitativos
protocolos Múltiplos investigadores Estimula diferentes perspectivas e
fortalece a base.
110

Passo Atividade Razão


Sobrepor coleta de dados e Acelera análises e revela ajustes
análise, incluindo anotações de que auxiliam a coleta de dados.
Entrada no campo.
Métodos de coleta de dados Permite ao investigador
campo
flexíveis e oportunistas. aproveitar-se de temas
emergentes e aspectos únicos do
caso.
Análise dentro do caso. Ganhar familiaridade com os
dados e generalizações de teoria
Análise de preliminares.
Buscar padrões entre casos Força os investigadores a olhar
dados
usando técnicas divergentes. além das impressões iniciais e das
evidências, através de múltiplas
lentes.
Tabulação interativa de Dá ênfase à definição de
evidência para cada construto. construtos, validade e medição.
Elaboração de
Replicar Confirma, estende e dá ênfase à
hipóteses
teoria.
Procurar evidência do porquê Constrói validade interna.
por trás dos relacionamentos.
Comparação com a literatura Constrói validade interna,
conflitante. aumenta o nível teórico.
Abrangência
Comparação com literatura Dá ênfase à generalização,
da literatura similar. melhora a definição de
construtos, e aumenta o nível
teórico;
Encerramento Saturação teórica quando Finalizar o processo quando a
possível. melhoria marginal for pequena.
Quadro 17: Processo de construção de teoria de um Estudo de Caso
Fonte: EISENHARDT, 1989, p. 533

Conforme apresentado anteriormente, a produção científica sobre gerenciamento


de projetos é comparativamente escassa e nova, em relação a outras disciplinas em
Administração de Empresas. Trabalhos de enfoque menos prescritivo são ainda mais raros
dentro deste campo de conhecimento específico, principalmente no Brasil. Isto conduz à
realização de uma pesquisa de natureza investigativa, sem condições de estabelecer relações
causais entre variáveis dependentes e independentes, alinhando-se dessa maneira aos
conceitos de estudo de caso de Yin (2001) e Bensabat, Goldstein e Mead (1987).
O objetivo desta pesquisa é investigar indícios do mimetismo institucional na
certificação de maturidade em gerenciamento de projetos, estudando os processos de tomada
de decisão de uma empresa ao certificar-se no CMMI. Através do problema de pesquisa,
buscamos compreender através do estudo de caso como e por que uma organização decide por
111

certificar-se, enquadrando o estudo como um estudo de caso tanto na matriz de Yin (2001)
quanto no quadro de Bensabat, Goldstein e Mead (1987). Também obtemos essa confirmação
através do argumento de que tratamos de um assunto cujo controle sobre os eventos
comportamentais não existe, e cujos eventos são atuais (BENSABAT; GOLDESTEIN;
MEAD, 1987; YIN, 2001).
No Brasil, até 2006, existiam apenas 21 empresas certificadas com algum nível
CMMI, representando um universo bastante reduzido de empresas a serem pesquisadas,
corroborando a natureza exploratória de qualquer estudo realizado sobre o assunto no Brasil,
contribuindo para a construção de conhecimento a respeito do fenômeno no país.
Yin (2001) estabelece cinco argumentos lógicos para estabelecer um estudo de
caso único:
• caso decisivo: para base de comprovação de um teoria bem formulada, na qual
o estudo de caso satisfaz todas as condições para comprovar, contestar ou
estender a teoria;
• caso raro ou extremo: são casos extremamente raros que justificam a
elaboração de um caso único;
• caso representativo ou típico: situações comuns, cotidianas, nas quais se parte
do pressuposto que o caso fornece um conjunto grande de informações a
respeito da situação analisada;
• caso revelador: estudos sobre um fenômeno que até então permanecia
inacessível à investigação científica;
• caso longitudinal: estudo do mesmo caso ao longo de uma escala temporal,
verificando possíveis alterações do fenômeno.
Esta pesquisa se aplica ao seu terceiro fundamento lógico: trata-se de um caso
representativo ou típico, de uma empresa de software no Brasil, de capital nacional. O caso a
ser estudado é o processo de certificação em CMMI, nível 2, ocorrido em 2005, de uma
empresa que atua nos setores de tecnologia e informática, nas áreas de comunicação de dados,
internet, desenvolvimento de sistemas e novas tecnologias, consultoria e suporte técnico há
mais de 20 anos, no Brasil, com sede no Estado de São Paulo, Capital.
A escolha deste caso deve-se ao fato de o objeto de estudo ser o processo de
certificação em gerenciamento de projetos que, embora venha crescendo em popularidade,
ainda foi concluído por poucas empresas no país. Como a certificação envolve os processos
para o desenvolvimento de software, foi escolhida uma empresa cuja atividade fim é
112

exatamente a atividade de desenvolvimento e implantação de projetos de software. A seleção


do caso não buscou apoiar-se em teorias, de forma a assegurar flexibilidade teórica. Foi
coletada uma amostra não aleatória de uma população específica, de forma a obter-se validade
externa (EISENHARDT, 1989).
Outro fator relevante para escolha do caso foi a existência de contatos dentro da
organização, que permitirão explorar o caso de forma mais consistente.
A definição das unidades de análise é diretamente influenciada pela pergunta de
pesquisa. (BENSABAT; GOLDESTEIN; MEAD, 1987; YIN, 2001). As unidades de análise
definem se um estudo é holístico – neste caso, as unidades de análise são globais (Exemplo:
uma organização como um todo, um processo) ou se é incorporado – no caso de haver
subunidades de análise (Exemplo: diversas áreas de uma organização, diversos indivíduos de
uma área).
Nesta pesquisa existirá inicialmente uma unidade de análise: o processo de
certificação em modelos de maturidade em projetos, composto por três subunidades: o grupo
de indivíduos tomadores de decisão, o grupo de indivíduos participante do processo de
certificação, e o grupo de indivíduos responsável pela operação pós-certificação. Portanto, a
pesquisa configura um estudo de caso incorporado.
Foram utilizados múltiplos métodos de coleta de dados, garantindo dessa maneira
a triangulação dos dados (DUBÉ; PARÉ, 2003; EINSENHARDT, 1989; YIN, 2001). A
principal forma de coleta dos dados foi composta por entrevistas, com roteiros semi-
estruturados, gravados e transcritos literalmente. Também foram utilizados documentos
internos da organização, documentos internos da empresa de consultoria que participou do
processo de certificação e documentos externos, obtidos através de pesquisa na Internet.

1.6.1. INSTRUMENTOS E PROTOCOLO DE ESTUDO DE CASO

Foram definidos um processo de coleta de dados e um protocolo de estudo de


caso. O roteiro de entrevistas é semi-estruturado, de maneira a manter uma coleta de dados
flexível e oportunista, buscando assim capturar temas emergentes (DUBÉ; PARÉ, 2003;
EISENHARDT, 1989). Seguindo esta lógica, foi realizada uma primeira entrevista preliminar,
buscando-se investigar de maneira macro o processo de certificação, e buscando-se
estabelecer quais seriam os indivíduos a serem entrevistados em cada uma das subunidades de
113

análise. Uma dificuldade encontrada foi o fato de que muitos participantes do processo já não
pertencem mais à organização.

1.6.1.1. Protocolo de Estudo de Caso

Definição de roteiro aberto para entrevista exploratória com área contato:


• coleta de informações sobre a empresa;
 principais clientes;
 principais fornecedores;
 principais concorrentes;
 principais parceiros;
• coleta de informações sobre o processo de certificação;
• identificação dos indivíduos participantes no processo de tomada de decisão
pela certificação (subunidade de análise 1);
• identificação dos indivíduos participantes do processo de certificação
(subunidade de análise 2);
• identificação dos indivíduos responsáveis pelos processos pós-certificação
(subunidade de análise 3).

Definição de roteiro aberto para entrevista exploratória com subunidade de análise


1, os tomadores de decisão:
• Quais foram os motivadores para a tomada de decisão pela certificação?
• Quão importante consideram a certificação?
• Quais as vantagens da certificação?
• Há planos para subir de nível?
 Em caso positivo, como estão os planos?
 Em caso negativo, por que não?
• Os principais concorrentes possuem a certificação?
• Como foi o processo de certificação? (durante)
• Como avalia o papel da consultoria?
• Como está a pós-certificação? (depois)
114

• As expectativas foram atendidas?

Definição de roteiro aberto para entrevista exploratória com subunidade de análise


2, os participantes do processo de certificação:
• Em qual parte do processo de certificação estiveram envolvidos?
• Quais foram os motivadores para a tomada de decisão pela certificação?
• Como foi o processo de certificação? (durante)
• Como avalia o papel da consultoria?
• Como está a pós-certificação? (depois)
• As expectativas foram atendidas?

Definição de roteiro aberto para entrevista exploratória com subunidade de análise


3, os responsáveis pelo processo pós-certificação:
• Em qual parte do processo de certificação estiveram envolvidos?
• Quais foram os motivadores para a tomada de decisão pela certificação?
• Como foi o processo de certificação? (durante)
• Como está a pós-certificação? (depois)
• As expectativas foram atendidas?
115

O CASO

1.7. A EMPRESA

A empresa analisada nesta pesquisa não autorizou a divulgação de seu nome.


Segundo Yin (2001), o anonimato é justificável para preservar o caso e seus participantes em
um caso polêmico. O autor ainda aponta que o anonimato prejudica a condução do estudo de
caso, principalmente por eliminar a possibilidade de uma contextualização maior. Entretanto,
houve um esforço na tentativa de não prejudicar a análise do caso, buscando outras
informações de contexto que também não prejudiquem a questão da identidade da empresa.
Assim sendo, para fins deste trabalho, a empresa cujo processo de certificação era analisado
será denominada como ABC.
A ABC iniciou suas operações em 1986, com sede na cidade de São Paulo. Hoje
conta, além da sede, com unidades no interior do Estado de São Paulo, na cidade de Ourinhos
e em outros estados e Brasília - Distrito Federal, com atuação em todo o Brasil. Há cerca de
um ano, a ABC tem negociado um de seus produtos também no Japão, com um escritório de
representação no país.
A empresa ABC faz parte do ABC Corp Group, formada por quatro empresas:
• ABC: atua nos setores da tecnologia e informática, nas áreas de comunicação
de dados, internet, desenvolvimento de sistemas e novas tecnologias,
consultoria, suporte técnico e alocação de recursos humanos especializados.
• Empresa 2: foco na atuação como Data Center.
• Empresa 3: fabricante de leitores e terminais de cheque, código de barras,
cartão de crédito e smart card.
• Empresa 4: foco em soluções de call center, suporte e logística.
Hoje a ABC é reconhecida no mercado principalmente no segmento de captura de
transações, e possui em seu portfólio de produtos sistemas de captura e consulta de cheques,
assinatura e autenticação de pagamento eletrônico, troca de arquivos via internet, compra e
venda de ações, auditoria das transações de ATMs (Automatic Teller Machine ou Caixas
Eletrônicos), gestão e monitoramento de ATMs, soluções de computação móvel, sistemas
116

eletrônicos de compra via internet, help desk, URA (Unidade de Resposta Audível), entre
outros.
Seus clientes atuam nos mais diferentes segmentos, sendo eles:
• instituições financeiras - bancos, seguradoras, administradoras de cartões de
crédito, financeiras, corretoras e assessores de investimento;
• comércio - redes de postos de gasolina, restaurantes, lojas;
• setores de produção e serviços - distribuidores, revendas, varejo, atacado e
indústrias;
• área de auditoria e inspetoria;
• área de atendimento a clientes;
• laboratórios farmacêuticos, entre outros.
A concentração dos principais clientes de sua carteira está na área financeira. O
ABC Corp Group detém cerca de 70% do mercado de EDI (Eletronic Data Interchange)
financeiro (dados da empresa) e 90% do mercado de leitores de cartão, e obteve um
faturamento de US$ 13 milhões em 2005.
A ABC conta hoje com cerca de 600 funcionários, sendo que parte destes
encontra-se alocada como mão de obra especializada em seus clientes. Atualmente a empresa
encontra-se em meio a cerca de 20 novos projetos de desenvolvimento.
Para realização de suas atividades, a ABC conta com empresas parceiras como
Microsoft, Sun Microsystems, IBM e PowerLogic.

1.7.1. A ESTRUTURA

A empresa conta hoje com duas grandes diretorias: Operações e Negócios, e uma
série de áreas reportando diretamente à Presidência, conforme mostrados no Organograma
abaixo.
Esquema 14: Estrutura atual da Empresa ABC.

117
118

1.7.2. A CERTIFICAÇÃO CMMI

A ABC obteve a certificação CMMI nível 2 em Setembro de 2005, com validade


de três anos, sendo que em Setembro de 2008 deverá passar por um novo processo de
avaliação.
Para fins dessa pesquisa iremos nos referir a empresa como certificada no CMMI
nível 2. Entretanto, colocando rigorosamente, a empresa possui apenas três unidades
organizacionais avaliadas pela SEI com nível de maturidade CMMI 2.

1.7.3. A MOTIVAÇÃO

Devido à concentração de suas atividades na área financeira, a empresa ABC


possui células de negócios voltadas inteiramente para projetos em bancos públicos e entidades
governamentais, participando dessa forma de um grande número de licitações. Embora
questionadas pelo Tribunal de Conta da União (QUEIROZ, 2007), a certificação em selos de
qualidade acrescenta pontos para as empresas participantes dos processos de licitação,
classificando-as num melhor ranking para vencer o processo.
As células de negócios são áreas de relacionamento com o cliente, e são divididas
por segmento de atuação: corretoras, mobilidade e laboratórios, por exemplo. Há casos
também nos quais o porte do cliente foi o fator gerador de uma célula de negócios. Cada uma
destas unidades conta com um gerente de contas com subgerentes focados em seus
determinados segmentos de negócios.
No passado, as células de negócio eram menos enxutas, possuindo estruturas
próprias e grande representatividade em termos de número de analistas e programadores.
Atualmente, a Divisão de Tecnologia fornece a maior parte dos serviços e profissionais para
as células de negócio, entretanto, existem poucas exceções em que a célula possui uma
unidade própria de desenvolvimento.
Em paralelo a esta necessidade, em 2003, foi criado dentro da empresa ABC um
comitê de estudos em metodologias, visando melhorar os processos internos da organização.
119

Partindo da necessidade das células de negócios, aliada à tendência organizacional


de preocupação com a melhoria da qualidade de seus processos, foram iniciados os trabalhos
em busca da certificação no CMM nível 2.
No início de 2005, em meio aos trabalhos para obtenção da certificação, a empresa
foi notificada pela consultoria responsável no auxílio para obtenção do selo, que o CMM nível
2 seria descontinuado pela sua criadora - a SEI, e recebeu a orientação para que os trabalhos
fossem migrados para obtenção da certificação em CMMI nível 2.
Segundo os envolvidos no processo, essa transição não significou mudanças
drásticas na condução dos trabalhos, nem gerou grandes problemas, pois os modelos CMM e
CMMI eram bastante semelhantes.

CMM CMMI

2003 2004 2005 SET/ 2005

Esquema 15: Evolução do processo de certificação da Empresa ABC


Fonte: elaboração própria.

1.7.4. O PROCESSO DE CERTIFICAÇÃO

Após a definição da busca pela certificação CMMI, a empresa buscou diversas


empresas de consultoria para auxílio na condução dos trabalhos, assinando contrato com a
empresa XYZ Consultores, que permanece até hoje nos processos de manutenção da
certificação CMMI e MPS.BR.
Após a contratação da empresa de consultoria, foi estabelecido o SEPG (Software
Enginnering Processs Group), um grupo de trabalho responsável pela definição dos
processos, manutenção, melhoria e divulgação dos mesmos entre a empresa. A equipe por
cerca de dez funcionários de diversas áreas.
A idéia inicial para composição da SEPG era selecionar um profissional de cada
área, de forma que este possuísse tempo de trabalho suficiente na organização de modo a
120

dominar os principais conceitos e processos da ABC. Assim, todas as áreas teriam


representantes e estariam envolvidas na certificação, o que facilitaria também o papel de
replicadores que estes indivíduos deveriam desempenhar em suas áreas, após a certificação, o
que não se comprovaria na prática.
Após a formalização dos processos, foi desenvolvido um portal disponibilizado na
Intranet, contendo todos os processos segundo os preceitos do CMMI, como forma de
consulta a todos os funcionários envolvidos.
Foram realizados diversos testes com projetos para que fossem analisadas quais
alterações seriam necessárias para que os processos funcionassem adequadamente na prática.
Também foram realizados treinamentos entre os gerentes de projeto, analistas e
programadores buscando disseminar os conceitos, entretanto, os primeiros treinamentos
mostraram-se cansativos e muito pouco efetivos.
O papel de replicadores dos indivíduos da SEPG em suas áreas de trabalho
também se mostrou pouco eficaz, já que uma vez inseridos no contexto de suas áreas, estes
indivíduos assumiam outros papéis e responsabilidades e não conseguiam manter seu status
como participantes da SEPG.
Na reta final dos trabalhos, ocorreu uma pressão por parte da Alta Gerência para
aceleração do processo e obtenção do selo, o que acabou por gerar uma insegurança geral em
todos envolvidos. Durante esta fase, o papel da consultoria foi fundamental para tranqüilizar a
equipe, realizando simulações com diversas situações, que se mostraram mais difíceis do que
as situações reais de uma avaliação.
O processo de avaliação em si foi considerado bastante tranqüilo, em contrapartida
às semanas que antecederam a auditoria, e a ABC obteve três unidades organizacionais
certificadas pela SEI em nível 2.

1.7.5. AS BARREIRAS

O processo para obtenção da certificação da ABC foi considerado longo pelos


vários participantes. Um dos principais motivos apontados para a demora no processo de
certificação foi o grau de maturidade no qual a empresa se encontrava. Apesar de, na época,
ter quase 20 anos de existência, a empresa é definida como resultado de um esforço coletivo e
121

orgânico de diversos profissionais, sem nunca ter tido antes alguma preocupação com a
estruturação dos processos de desenvolvimento de softwares.
A empresa não possuía nenhum tipo de metodologia ou organização em seus
processos de desenvolvimento de software, o que constantemente gerava problemas em seus
projetos, principalmente por estar aliado a um alto índice de rotatividade de seus funcionários.
Outro ponto agravante era a própria capacidade técnica da empresa, em termos de
infra-estrutura, que não era capaz de suportar operações mais robustas. Em determinados
pontos do processo de certificação, a empresa teve de interromper os trabalhos, para que
determinados projetos técnicos fossem implantados, para assim viabilizar a continuação dos
trabalhos de certificação.
Desta forma, a empresa teve um grande esforço em organizar-se internamente para
atingir um determinado nível, enquanto ocorriam os trabalhos para obtenção da certificação
nível 2, o que acabou por estender os prazos para conclusão do trabalho.
Outro fator observado que contribuiu para o atraso nos trabalhos foi o apoio da
Alta Gerência. Embora a Alta Gerência tenha dado seu aval em relação à certificação e tenha
patrocinado o projeto financeiramente, observa-se que sua atuação foi limitada.
O projeto para obtenção da certificação nunca teve uma posição clara dentro das
prioridades da empresa. Com a escassez de recursos, diversos profissionais diretamente
envolvidos nos trabalhos de definição dos processos eram requisitados para outros projetos.
Isto tornava a estrutura das reuniões semanais improdutivas, já que a ausência de uma ou duas
pessoas nas reuniões invalidava as decisões tomadas na semana anterior.
De maneira natural, o SEPG foi moldando-se ao melhor formato e número de
participantes de forma a evitar o problema das ausências, havendo uma revisão do conceito
inicial de composição do grupo – um indivíduo de cada área.
Inicialmente também, os profissionais atuantes na SEPG tinham formalmente
definido em suas agendas de trabalho as reuniões semanais, que funcionavam como encontros
para a discussão de temas. A preparação dos materiais e as leituras para estas reuniões
deveriam ser feitas durante o horário de seu expediente regular somadas às suas atribuições
diárias em suas respectivas áreas. Ou seja, embora o grupo tivesse uma definição formal, não
havia uma formalização dos trabalhos do grupo SEPG. Assim, cada indivíduo contava com a
compreensão de cada líder de área em relação à sua dedicação ao projeto de certificação.
Todo o trabalho para a certificação foi conduzido basicamente entre a SEPG e a
consultoria contratada, não havendo registro de uma participação formal de indivíduos da Alta
Gerência.
122

Posteriormente esta situação modificou-se: a área de SQA é responsável por todas


as atividades relacionadas à qualidade do trabalho, trabalhando juntamente com a SEPG.
Portanto, todo o material utilizado para a discussão nas reuniões semanais da SEPG é
produzido pelo SQA. A manutenção dos processos de avaliação das diversas certificações da
empresa (CMMI, ISO 9000, MPSBR) é responsabilidade desta área, assim como a geração de
relatórios gerenciais de produtividade e qualidade.
Estas mudanças são atribuídas em grande parte à troca do Gerente da Divisão de
Tecnologia. A nova gerência trouxe uma nova postura à área, o que possibilitou a aceleração
dos trabalhos de certificação, e a manutenção de seus processos.
Sob o ponto de vista do consultor, a existência de “vales”, períodos de baixa na
condução dos trabalhos, durante o processo de obtenção das certificações é bastante comum,
entretanto, é nessa fase que a atuação da Alta Gerência se faz necessária. Embora tenham
ocorrido situações exógenas que contribuíram para estes vales, incluindo um incêndio que
paralisou os trabalhos por três meses, na opinião do consultor responsável pelos trabalhos,
houve falta de uma atuação mais incisiva por parte da alta Gerência, o que contribuiu para o
longo processo para obtenção da certificação.
Outro fator que contribuiu para os atrasos dos trabalhos foi o tempo de
aprendizado da própria SEPG sobre os conceitos do CMMI, já que a maioria dos membros
não tinha familiaridade com modelos ou conceitos de melhoria contínua ou trabalhavam
dentro de algum tipo de metodologia comum à empresa.
Houve inclusive um período de adaptação entre as expectativas da SEPG em
relação ao trabalho da consultoria, pois não havia ficado claro para o grupo de trabalho o
limite das responsabilidades na condução dos trabalhos, sendo que o desenvolvimento dos
processos estaria diretamente em suas mãos, e que eles receberiam apenas orientação sobre o
modelo em si.
Às vésperas da certificação a empresa sofreu uma baixa no número de projetos
grandes o suficiente que coubessem no modelo do CMMI, em termo de número de horas,
dificultando o processo de seleção de projetos para submissão à avaliação.
Outro problema enfrentado pela SEPG era a resistência de gerentes de projetos e
analistas/programadores em relação à adoção do modelo CMMI. O principal argumento
utilizado por eles era a de que seguir todos os passos exigidos pelo modelo encareceria o
projeto e tornava o projeto mais longo. O contra-argumento da SEPG era de que, embora num
primeiro momento os projetos antigos parecessem mais baratos e mais rápidos, estes
acabariam por mostrar-se mais caros se somados os problemas futuros com manutenção.
123

Como resultado dessa questão, muitas áreas retiraram seus representantes da


SEPG, alegando que a implantação do CMMI implicaria em burocratização do trabalho.
Esta resistência inicial foi minada aos poucos, devido aos trabalhos da SEPG,
entretanto, ainda hoje, seguem na empresa alguns focos de resistência entre gerentes de
projeto, que acreditam que o CMMI foi utilizado como desculpa para um aumento
generalizado no preço de seus produtos e serviços.

1.7.6. A PÓS-CERTIFICAÇÃO

Atualmente, a empresa conta com um sistema de apadrinhamento, conduzida pela


área de SQA (Software Quality Assurance), em que a cada novo projeto da empresa, um
indivíduo da área fica responsável como tutor do gerente de projetos, com responsabilidade de
sanar dúvidas a respeito dos processos ou até mesmo verificar a necessidade de realinhamento
de processos.
A empresa contava com apenas um auditor de projetos, que inclusive fez a
avaliação dos projetos submetidos ao avaliador oficial da SEI. Hoje a empresa vem testando a
estratégia de treinar seus gerentes de projetos como auditores uns dos outros, ou seja, gerentes
de projetos trocam de projetos no momento da auditoria.
Logo após a divulgação da certificação no CMMI nível 2, a empresa ABC
divulgou através de press release que no ano seguinte, em 2006, subiria o nível de sua
certificação para o nível 3, informação que foi desacreditada pelos próprios funcionários da
empresa. Este fenômeno demonstra o descolamento da Alta Gerência em relação à realidade
do processo de certificação, pois, segundo os participantes do processo, as dificuldades
encontradas no processo para o nível 2 haviam sido tão grandes que um prazo tão curto para a
obtenção do nível 3 era irreal.
Passados dois anos após a certificação CMMI nível 2, a empresa ABC ainda não
obteve a certificação nível 3. Isto se deve ao fato de que a empresa alterou sua estratégia em
certificações e em Agosto de 2006 obteve a certificação ISO 9000. Também optou, em
Fevereiro de 2007, certificar-se no MPSBR (Melhoria de Processos do Software Brasileiro)
nível E, já que em termos de pontuação em licitações o MPSBR passava a contar tanto quanto
o CMMI.
124

Os próximos planos da ABC contavam com a certificação MPS.BR nível D,


entretanto, com o término do prazo de validade da avaliação CMMI nível 2, a empresa têm
considerado alterar novamente esta estratégia, e certificar-se no CMMI nível 3, em Setembro
de 2008.

1.7.7. AS CONSEQÜÊNCIAS

A empresa ABC não contava com nenhuma metodologia na condução de seus


projetos e processos. Não havia uniformidade na documentação de seus projetos, em algumas
áreas, por iniciativa própria, estabeleciam-se documentações, em outras a documentação
sequer existia.
Somado ao alto índice de rotatividade da empresa, muitos projetos permaneciam
perdidos, sem referências ou documentações, gerando sérios problemas em suas manutenções.
Novos projetos acabavam gerando estouros nos custos e prazos previstos em orçamento.
O processo de certificação acabou por gerar obrigatoriamente um movimento de
reestruturação por parte da empresa, não se restringindo aos processos, mas também à sua
capacidade de infra-estrutura técnica.
Como benefícios quantitativos a empresa cita:
• Estabelecimento de um procedimento para contagem de Pontos de Função para
tamanho de software
• Redução de 77% no erro estimado para esforço de projeto
• Redução de 62% no esforço de retrabalho em projetos
• Redução de 35% na quantidade de ocorrência de riscos não planejados em
projeto
A certificação inseriu a empresa ABC e seus profissionais em novos grupos e
comunidades, é consenso que a empresa tornou-se mais conhecida no mercado.
Freqüentemente seus profissionais são chamados para palestras sobre a experiência de
certificação, e atualmente fazem parte da comunidade SPIN (Software and Process
Improvement Network) Brasil, uma comunidade mundial, formada por organizações locais de
profissionais envolvidos com a melhoria no processo de desenvolvimento de software.
A certificação CMMI foi a primeira à qual a empresa ABC se submeteu e, por
conseqüência, foi o processo mais complexo e custoso. A empresa divulgou ter gasto mais de
125

R$500.000,00 para obtenção da certificação. Após a certificação no CMMI a empresa já


possuía uma estrutura mínima, que facilitou a obtenção dos certificados de ISO 9000 e
MPSBR nível E.
Apesar de todos os benefícios, há questionamentos sobre o momento da
certificação. Profissionais da empresa acreditam que a certificação ocorreria com o tempo,
seria um caminho natural na evolução da empresa e que tentar obtê-la em 2003 foi
precipitado.
Como indício dessa precipitação, há o fato de que a empresa não conhecia todos os
benefícios potenciais da certificação, principalmente os institucionais, antes da certificação
em si. A empresa desconhecia a amplitude e significado da certificação até o momento em
que ela ocorreu.
Como decorrência desse desconhecimento, um dos grandes desafios da empresa
vem sendo seu reposicionamento no mercado. A empresa possui em sua carteira um grande
número de clientes de pequeno porte com projetos pequenos de baixo valor.
Estes clientes não estão respondendo bem ao aumento de preços dos produtos e
projetos da ABC, embutidos com os custos envolvendo as novas metodologias, e, em
decorrência, a empresa vem perdendo projetos. Concomitantemente a empresa ainda tem tido
dificuldades em vencer licitações ou orçamentos maiores e vem perdendo projetos.
126

ANÁLISE DO CASO

Dubé e Parré (2003) argumentam que uma das fragilidades atribuídas ao uso de
Estudos de Caso em Sistemas de Informação envolve a não elucidação dos processos de
análise de dados. Para garantir uma maior confiabilidade, seguem abaixo os procedimentos
adotados para as análises dos dados.
Foram entrevistados sete indivíduos envolvidos no processo de certificação,
conforme o quadro abaixo.

Nomenclatura Subunidade de Função


Análise
Anteriormente ao processo de
certificação, fez parte de um comitê de
Analista 1 – SEPG Participante estudos em metodologia. Faz parte da
SEPG desde o início dos trabalhos, e
atualmente tem dedicação exclusiva ao
grupo.
Atuou desde o início do processo de
Analista 2 – SEPG
Participante certificação com o SEPG, mas atualmente
encontra-se alocado com dedicação
exclusiva em outro projeto.
Atuou no início do processo de
Analista 3 – SEPG Participante certificação, mas atualmente não participa
mais do grupo SEPG, estando alocado em
outro sítio da empresa.
Participa dos trabalhos da SEPG desde o
Tomador de início do processo de certificação, e hoje
Coordenador – SQA é coordenador da área responsável pela
Decisão
manutenção dos processos de melhoria
contínua, certificações e qualidade.
Participou do processo de certificação, e
Analista – SQA Pós-certificação atuou até recentemente como auditor
interno dos projetos.
Gerente de Projetos com dois projetos
Gerente de Projetos
Pós-certificação auditados no ato da avaliação. Há 6 meses
– GP desligou-se da empresa e atualmente
trabalha num cliente da ABC.
Consultor responsável pela condução dos
Consultor Participante trabalhos de certificação da empresa
ABC, com atuação no mercado de
certificações desde 2000.
Quadro 18: Nomenclatura, classificação e descrição de funções dos indivíduos entrevistados.
Fonte: elaboração própria.
127

Segundo Langley (1999), as dificuldades são grandes ao analisar e manipular


dados obtidos por análise de processos. Para facilitar o processo de análise desse tipo de dado,
a pesquisadora nos fornece sete estratégias: narrativa, grounded theory, agrupamento em
fases, mapa visual, estratégia sintética, quantificação e simulação computacional.
Três dimensões são avaliadas em relação às estratégias: acuracidade, simplicidade
e generalização, nas quais há uma relação de concessão entre as dimensões em cada
abordagem.

Estratégia Acuracidade Simplicidade Generalização


Alto Baixo Baixo
Narrativa
Grounded Theory
Agrupamento em fases
Mapa Visual
Estratégia Sintética
Quantificação
Simulação Computacional
Baixo Alto Alto
Quadro 19: Comparação entre estratégias de análise de dados.
Fonte: LANGLEY, 1999, p. 706.

Para compensar as dimensões entre as estratégias, podemos utilizá-las de maneira


combinada. Esta pesquisa busca efetuar uma análise em dois níveis, sendo no primeiro nível
uma análise macro sobre os indícios do CMMI como prática institucionalizada. Nesta etapa é
utilizada a estratégia de grounded theory, na qual as evidências extraídas da análise da
literatura envolvendo estudos sobre o CMMI são analisadas através da teoria institucional da
perspectiva institucional em TI e em gerenciamento de projetos.
No próximo nível, está a análise do caso, buscando-se verificar os indícios de
institucionalização no processo de certificação de uma empresa brasileira produtora de
software. Para isso foram utilizadas as estratégias de narrativa e estratégia sintética.
(LANGLEY, 1999).
A estratégia narrativa envolve a construção de uma história, e particularmente
nesta pesquisa é utilizada como uma forma preliminar de preparar uma cronologia para
subseqüente análise. Devido ao seu foco em um detalhe contextual, esta abordagem funciona
melhor com um ou poucos casos.
A partir da transcrição das entrevistas, foi desenvolvida uma narrativa abordando
todo o processo de certificação, suas conseqüências e sua situação atual.
128

Na estratégia sintética, os dados são processados de forma a transformar uma


história em variáveis que sintetizam seus componentes críticos. Os construtos são construídos
através de exploração indutiva e codificação de casos narrativos, o que exige um alto número
de casos para comparação. (LANGLEY, 1999). Caso o número de casos seja baixo, há a
necessidade de haver uma forte explanação das relações através da literatura, de forma a
adquirir credibilidade e possibilitar validade externa. (EISENHARDT, 1989). Assim, com
base nos dados coletados nas entrevistas, foi gerado um quadro classificando o conteúdo da
transcrição das entrevistas em categorias geradas a partir da revisão da literatura. Miles e
Huberman (1984) compartilham desta visão sugerindo que o primeiro passo na análise de
dados gerados qualitativamente seja a redução, através de processos de seleção, enfoque,
simplificação e abstração.
Os próximos passos são encontrar uma forma de apresentação dos dados
reduzidos, de maneira organizada, que permita o encaminhamento para as conclusões, que
pode ser realizada através de uma matriz descritiva, utilizada nesta pesquisa para demonstrar a
formação das categorias e uma matriz explanatória, buscando convergir o conteúdo das
entrevistas às categorias. Por fim, é necessária a condução da análise na busca de atribuir
sentido aos dados reduzidos e apresentados, através da busca de padrões, explanações e
possíveis configurações, fluxos causais e proposições, que devem ser verificadas para garantir
robustez e validade à pesquisa. (MILES e HUBERMAN, 1984)
Em complemento, foi utilizada a triangulação (JICK, 1979), através da
confrontação de análise de documentos internos e externos e o conteúdo das entrevistas.
Busca-se, assim, corroborar informações fornecidas pelas entrevistas. Para Denzin9 (1978, p.
291 apud JICK, 1979, p.612), triangulação é a combinação de metodologias no estudo de um
mesmo fenômeno. A técnica fornece uma forma de avaliação, clareando consistências e
inconsistências encontradas nos pontos de vistas fornecidos pelas diversas perspectivas,
permitindo avaliar o fenômeno do ponto de vista de diversos stakeholders. (DUBÉ; PARRÉ,
2003; PATTON, 1990).

9
DENZIN, N. K. The research act. 2nd edition. NY: McGraw Hill. 1978.
129

1.8. ANÁLISE MACRO: O CMMI E A TEORIA INSTITUCIONAL

A criação do antecessor ao CMMI, o CMM, pela SEI (Software Enginnering


Institute) estava vinculada ao problema de seleção de fornecedores de software por parte do
Departamento de Defesa dos Estados Unidos, o que levou à criação do sistema de avaliação e
certificação. (SEI, 2006b). O processo de certificação atribuiu ao CMMI o caráter de norma e
regra, reforçando o isomorfismo, forçando organizações do segmento de software a
uniformizarem seus procedimentos de produção. (DiMAGGIO; POWELL, 1983, TOLBERT;
ZUCKER, 1998)
O isomorfismo institucional gerado pelo CMMI, foi desenvolvido através dos três
mecanismos: coerção, normas e mimetismo. O Departamento de Defesa dos Estados Unidos
foi a primeira entidade governamental a exigir avaliação em níveis de maturidade do CMMI
de seus fornecedores, gerando assim o isomorfismo coercitivo. Este critério foi amplamente
adotado por outros órgãos governamentais americanos e de outros países, reforçando assim o
caráter de coerção, o que caracteriza fortemente o isomorfismo institucional gerado pela
prática do CMMI, diferenciando-o do isomorfismo competitivo (BOLINGER; McGOWAN,
1991; DiMAGGIO; POWELL, 1983; KING et al, 1994; MEYER; ROWAN, 1977;
O´CONNELL; SAIEDIAN, 2000)
A SEI é um instituto de pesquisa vinculada a Carnegie Mellon University, uma
fonte primária de educação formal, necessária ao isomorfismo normativo. O próprio
estabelecimento das práticas propostas pelo CMMI na organização gera a necessidade da
formação de um grupo de profissionais especializados nas formas de SEPGs (Software
Enginneering Process Group) e de SQAs (Software Quality Assurance). Ocorre o processo de
treinamento dos indivíduos envolvidos no processo: analistas, programadores, gerentes de
projeto. Há ainda o fomento ao estabelecimento de comunidades de práticas destes grupos,
através de palestras, fóruns e eventos promovidos pela SEI ou por instituições vinculadas à
melhoria de processo de software, como o SPIN. Soma-se a isso a difusão do modelo através
das empresas de consultoria, responsáveis pela condução dos trabalhos para obtenção da
certificação, contribuindo para a formação de um forte contexto institucional, reforçando
assim o isomorfismo normativo. (DiMAGGIO; POWELL, 1983; SEI, 2006b)
A literatura crítica sobre o CMMI e outros SPIs (Software Process Improvement)
ressalta a falta de evidências sobre os resultados e casos de sucesso de implantação destes
modelos. (BADOO e HALL, 2002; BADOO e HALL; 2003). Apesar deste ambiente de
130

incertezas em relação à eficiência ou não das práticas do CMMI e também frente às


necessidades de legitimação, de forma a obterem contratos de empresas que exigiam a
certificação CMMI para garantir sua sobrevivência, empresas adotaram e adotam o modelo,
imitando o comportamento de empresas que julgam bem sucedidas, gerando o isomorfismo
mimético. (DiMAGGIO; POWELL, 1983)
Confirmamos também o caráter cerimonial e ritualístico do CMMI, no qual
evidências de sucesso não foram amplamente pesquisadas e difundidas pelas pesquisas
acadêmicas, nas quais há indícios de diferenças de resultados sobre motivações para a adoção
do CMMI entre pesquisas realizadas por acadêmicos e outras conduzidas por empresas, e nas
quais o processo de avaliação pode levar empresas a aparentar maior maturidade do que
efetivamente possuem, gerando resultados que não correspondem à realidade de melhoria e
ganho de eficiência que o modelo tanto prega. Entretanto, o CMMI continua sendo
amplamente difundido e implementado mundialmente. (CALDAS; VASCONCELOS, 2002;
DUTTON; DUCHERICH´S, 1991; MEYER; ROWAN, 1977; O´CONNELL; SAIEDIAN,
2000; SEI, 2006b; STAPLES et al, 2006)
O CMMI deriva de dois campos de estudos, a Tecnologia de Informação e o
Gerenciamento de Projetos, nos quais foram encontradas evidências de institucionalização.
(AVGEROU, 2000; KING et al, 1994; LEROY, 2007; MIGNERAT; RIVARD, 2005,
MIGNERAT; RIVARD, 2006)
O caráter de modelo de uma estrutura é indicado como um facilitador do processo
cognitivo na fase de teorização, durante o processo de institucionalização de uma estrutura.
Quanto mais complexo e abstrato o modelo, mais rapidamente universal ele se torna.
(STRANG e MEYER, 1993, DiMAGGIO, 1997). O CMMI é considerado um modelo
complexo, burocrático e rígido, além de possuir pouca clareza, principalmente no que se
refere aos níveis mais altos de maturidade. Há muitas interpretações sobre como uma empresa
atinge os níveis 4 e 5 de maturidade, devido à falta de definições. (BOLINGER; McGOWAN,
1991; HARTMAN; SKULMOSKI, 1998)
A estrutura deste modelo de maturidade deriva de muitas práticas em
gerenciamento de projetos, consolidadas sob forma de metodologias em gerenciamento de
projetos, indicadas como institucionalizadas pela pesquisa de Mignerat e Rivard (2006).
Avgerou (2000) ressalta o caráter de padronização das metodologias como gerador de
legitimidade, no qual práticas não padronizadas são rejeitadas por participantes de um
ambiente institucional, pelo receio de não conseguirem realizar negócios.
131

INOVAÇÃO HABITUALIZAÇÃO OBJETIFICAÇÃO SEDIMENTAÇÃO

1989 - Criação do 1991 – Desenvolvimento Até hoje - Departamento de


livro “Managing the dos CMMs. Defesa dos estados Unidos
Software Process”. utiliza a avaliação CMM/
1995 - SEI publica o CMMI para seleção de
livro “The Capability fornecedores.
Maturity Model:
Guidelines for the O mesmo critério expande-
Improving the Software se pelo mundo.
Process”.

Esquema 16: Processo de institucionalização do CMMI


Fonte: elaboração própria

O CMMI (e o CMM) apresenta um alto índice de difusão como conceito de


modelo de maturidade. Isto pode ser comprovado pela sua influência em outros diversos
modelos de maturidade para os quais serviu de base, além dos índices de adoção da
certificação apresentados pela SEI, o que nos leva à conclusão que o CMMI encontra-se
atualmente na última fase de institucionalização, a sedimentação, sem indícios de que este
processo seja interrompido no médio prazo. (HARTMAN; SKULMOSKI, 1998; KEZNER,
2002; KWAK; IBBS, 2002; OGC, 2007; PRADO, 2005; SEI, 2007(b), WEBER et al, 2006)

1.9. ANÁLISE DA CERTIFICAÇÃO

A partir da revisão da literatura foram desenvolvidas categorias para a


classificação do conteúdo das entrevistas realizadas com os indivíduos participantes do
processo de certificação. Aqui se buscou não apenas investigar os indícios do mimetismo
institucional no processo de certificação, mas também investigar indícios de melhorias de
processo ou melhoria contínua prometidas pela adoção dos modelos de maturidade, buscando-
se assim confronto com a literatura conflitante ao objetivo da pesquisa, de maneira a adquirir
validade interna. (EISENHARDT, 1989)
132

1.9.1. CONSTRUÇÃO DAS CATEGORIAS

As categorias foram desenvolvidas a partir da teoria institucional e a teoria em


gerenciamento de projetos e modelos de maturidade em gerenciamento de projetos.

• Modelos de Maturidade em Gestão de projetos


o Maturidade em gestão de projetos: indícios de maturidade comprovados ou
gerados pelo processo de certificação;
o Gerenciamento de Projetos: indícios de comprovação ou melhoria nos
processos de gerenciamento de projetos gerados pela certificação;
• Teoria Institucional
o Legitimidade: indícios de mecanismos de legitimidade gerada pela
certificação;
o Isomorfismo: indícios de homogeneização da empresa em seu ambiente,
através das pressões institucionais, apresentado sob a forma dos três
mecanismos de isomorfismo:
 Isomorfismo coercitivo;
 Isomorfismo mimético;
 Isomorfismo normativo.
o Rituais e cerimônias: indícios da presença de rituais e cerimônias envolvendo o
processo de certificação CMMI.
133

Categorias Autores
Maturidade em A maturidade em gestão de projetos é o desenvolvimento de
Gestão de Projetos processos e sistemas que são, por natureza, repetitivos e garantem
uma alta probabilidade de cada um deles seja um sucesso.
Entretanto, a obtenção destes benefícios depende de tempo em
melhorias de seus processos de gerenciamento de projetos.
(KEZNER, 2002).

O CMMI é um modelo de maturidade para melhoria de processos


de desenvolvimento de produtos e serviços. Consiste nas melhores
práticas direcionando atividades de desenvolvimento e
manutenção que cobrem o ciclo de vida de um produto desde a sua
concepção, à sua entrega e manutenção. (SEI, 2006b).

A maturidade em gestão de projetos nos auxilia a compreender


vários aspectos, entre eles, medir a competências dos profissionais
em gerenciamento de projetos em escalas generalizadas. Também
nos auxilia a compreender o ambiente de trabalho dos
profissionais e a avaliar a aderência ao negócio para qual o projeto
está sendo desenvolvido. A maturidade em gestão de projetos
também nos cria a oportunidade de estudar e compreender o
crescimento de excelentes gerentes de projetos, e pode nos auxiliar
a compreender o mecanismo que está por trás deste crescimento.
(HARTMAN; SKULMOSKI, 1998).
Gerenciamento de A obtenção da maturidade depende de tempo em melhorias de
Projetos seus processos de gerenciamento de projetos. (KERZNER, 1987).

Segundo o PMBOK, o gerenciamento de projetos é resultado da


interação entre um conjunto de processos de iniciação,
planejamento, execução, controle e finalização. (PMI, 2004).

A adoção de uma única metodologia de gestão de projetos,


definida e implementada não é por is só um elemento suficiente
para comprovar o nível de maturidade de uma organização no
gerenciamento de projetos. (BOUER; CARVALHO, 2004).
134

Categorias Autores
Legitimação [A legitimação é necessária] quando surge a necessidade de
transmissão da ordem institucional para gerações futuras, quando
o caráter das instituições não pode mais ser sustentado pelo
indivíduo. Para sua manutenção é necessário que haja explicações
e justificativas, mecanismo pelo qual se dá a legitimação. Há uma
ênfase sobre a legitimação das regras institucionais, mitos e
crenças como formadores da realidade social. (BERGER;
LUCKMAN, 1967)

Tecnologias são institucionalizadas e tornaram-se mitos atrelados


a organizações: procedimentos técnicos de produção,
contabilidade, seleção pessoal e processamento de dados são
aceitos como corretos para o cumprimento dos objetivos
organizacionais, estabelecendo, portanto, que a organização é
apropriada, racional e moderna. O crescimento de estruturas
racionais institucionais torna as organizações formais mais
comuns, fáceis de criar e mais necessárias, de forma a evitar
ilegitimidade. (MEYER; ROWAN, 1977)

O uso de modelos ou esquemas simplifica o processo cognitivo:


pessoas tendem a capturar de maneira mais eficiente as
informações mais relevantes a partir de um esquema, a relembrar
informações de um esquema de maneira mais rápida e mais
precisa. Entretanto, pessoas podem depreender fatos dos esquemas
que não correspondem a realidade. (DiMAGGIO, 1991)

O amplo uso das metodologias também envolve elementos de


legitimidade, com práticas nem sempre racionais. Metodologias
implicam em padrões, uma forma de estabelecer regulamento num
ambiente de atores e empresas descentralizados, buscando atingir
objetivos institucionais. Potenciais adotantes relutam em adotar
inovações “não padronizadas”, devido às dificuldades que terão
em realizar negócios no futuro, e aos esforços que terão para
fechar contratos. (AVGEROU, 2000; KING, 1994).
135

Categorias Autores
Isomorfismo [...] resultado das forças coercitivas do ambiente, como as
coercitivo regulamentações governamentais. A homogeneidade é resultado
das pressões formais e informais das outras organizações do
mesmo contexto ambiental e pelas expectativas culturais da
sociedade em que estão inseridas (DiMAGGIO; POWELL, 1983).

Quando Estados racionalizados e outras grandes organizações


racionais expandem seus domínios, as estruturas organizacionais
tendem a cada vez mais refletir as regras institucionais e
legitimadas por eles e dentro deles, resultando em organizações
cada vez mais homogêneas dentro de seus campos de atuação e
cada vez mais arraigadas a rituais de conformidade. (MEYER;
ROWAN, 1977).

O governo apresenta um papel fundamental na geração das


pressões coercitivas seja através de regulamentação ou através de
programas de desenvolvimento de conhecimento, subsídios e
estabelecimento de padrões e diretrizes. Estas intervenções
governamentais são comuns em países em desenvolvimento de
forma a acelerar o a inovação em TI. (KING et al, 1994)
Isomorfismo A incerteza, fruto de objetivos ambíguos, novas tecnologias ou até
Mimético mesmo do próprio ambiente, acaba por gerar nas organizações o
encorajamento da imitação, modelando-se a outras organizações.
Ocorrem imitações de práticas, em que as empresas tentam
modelar-se de acordo com empresas que consideram bem
sucedidas ou mais legítimas dentro do campo de atuação. A
difusão destes modelos pode ocorrer de forma não intencional
através da transferência de profissionais dentro de um ambiente
organizacional ou intencionalmente através das empresas de
consultorias e associações de comércio. (DiMAGGIO; POWELL,
1983).

As pressões miméticas e normativas se dão através de educação e


socialização de indivíduos, articulação de particulares pontos de
vista e provisão de recursos para atividades sociais. (KING et al,
1994).
136

Categorias Autores
Isomorfismo A fonte deste tipo de isomorfismo vem da profissionalização [...]
Normativo O crescimento da profissionalização se dá através de organizações
profissionais, gerentes particulares, e equipes especializadas de
grandes corporações. (DiMAGGIO; POWELL, 1983).

As pressões miméticas e normativas se dão através de educação e


socialização de indivíduos, articulação de particulares pontos de
vista e provisão de recursos para atividades sociais. (KING et al,
1994).
Rituais e [...] organizações adotam técnicas e práticas gerenciais muito mais
Cerimônias por questões de marketing do que propriamente para ganho de
eficiência. A despeito da possível eficiência, técnicas
institucionalizadas estabelecem que a empresa é adequada,
racional e moderna, demonstrando responsabilidade e evitando a
negligência em se tornarem obsoletas.(MEYER; ROWAN, 1977)

[...] a submissão às práticas institucionalizadas (ou “mitos”) pode


trazer legitimidade as empresas, mas podem ser, na realidade,
ineficientes ou impraticáveis pelas organizações. Em alguns casos,
a empresa pode se submeter aos rituais e elementos simbólicos de
inovação e técnicas, sem levar aprofundar-se no processo.
(CALDAS; VASCONCELOS, 2002)

A imagem pode ser definida como a percepção dos membros de


uma organização sobre como externos enxergam a organização.
Identidade é o que os membros acreditam ser as características
centrais da organização ao qual pertencem. A manipulação de
ambos demonstra que empresas podem atender as pressões
institucionais através de respostas que refletem os interesses das
organizações. (DUTTON; DUCHERICH´S, 1991)
Quadro 20: Construção das categorias com base na revisão de literatura.
Fonte: elaboração própria.
137

O quadro abaixo classifica evidências encontradas no conteúdo das entrevistas


dentro de categorias determinadas pela Revisão de Literatura.

Categorias Autores Transcrição


Maturidade em HARTMAN; “Eu vejo a empresa de um modo geral mais madura.
Mais ou menos assim, ainda temos falhas, mas
Gestão de SKULMOSKI, 1998
sabemos onde elas estão. A gente pode até não estar
Projetos KEZNER, 2002 resolvendo isso agora, mas a gente sabe onde está.
[...] Não vejo o modelo como a gente tinha antes, com
SEI, 2006b
tudo descentralizado, sem processo formal, não vejo
como a gente estaria trabalhando hoje” - Analista 1 –
SEPG

“Eu acho que a gente evoluiu pra caramba. Hoje a


gente fala de áreas que não tem indicadores a gente
fica preocupado com isso. Indicadores! Era um
negócio absurdo pra se falar antes do CMMI. Mesmo
na época do comitê de metodologia. [...] Hoje a gente
fala de indicadores, relatórios gerenciais, medição,
gerência de configuração” Analista 1 – SEPG

“Não adianta você querer melhorar alguma coisa,


se o processo tá “louco”, variável. Você tem que
estabilizar o seu processo para poder melhorar.” –
Consultor

“[O CMMI] tem uma lógica muito grande dele.


Não é um modelo mal estruturado, é um modelo
muito bem estruturado, tem uma lógica por trás da
estruturação dele.” – Consultor
Gerenciamento BOUER; “Inicialmente a gente não tinha metodologia
nenhuma na empresa, não tinham documentação de
de Projetos CARVALHO, 2004
nada, cada uma fazia da sua forma, acho que o mais
KEZNER, 2002 agravante é que assim, às vezes, ocorria que como
não tinha nada documentado, e não tinha até a
PMI, 2004
comunicação interna. Então às vezes tinha o
departamento responsável pela BP [Banco Público],
que cuidava dos projetos da BP, fazendo uma
documentação que até tava bacana, e um
departamento responsável pelo BPR [Banco
Privado] fazendo uma outra documentação ou nem
sabia como fazer, precisava de uma referência, mas
nem sabia que aqui dentro mesmo tinha uma aqui
dentro e nem sabia como fazer e era tudo
engavetado, tudo perdido, nada era controlado,
cada um fazia do seu jeito. Não tinha controle
nenhum, não tinha controle de tempo e de horas,
era tudo muito solto” Analista 2 – SEPG
138

Categorias Autores Transcrição


“Então, assim, eles conseguem acompanhar e no
final, tem aquele relatório, lições aprendidas: Nesse
projeto a gente pecou, porque a gente não previu
determinado risco que era essencial e impactou no
nosso projeto. No próximo projeto já tem que mais
ou menos numa situação semelhante a gente já tem
que prever. Hoje já tem esse fim, hoje a gente
consegue perceber essas coisas.Então acho que pras
áreas ainda não ter chegado no ponto de: ‘consegui
que meus projetos saiam no tempo que eu estimei,
no custo que eu estimei’, ainda não tá nesse nível,
mas a gente já tá conseguindo ver a onde a gente tá
errando pelo menos está tendo esse
acompanhamento” Analista 2 – SEPG

“Por sermos uma consultoria de TI e nosso foco é


desenvolvimento de software [sistemas], nosso
principal capital é código fonte e ele [o CMMI] nos
ajudou a organizar e otimizar nossos trabalhos.[...]
[Os maiores benefícios do CMMI] organização,
rastreabilidade de documentos/código e a criação
de um rico histórico de projetos já trabalhados.” -
Analista 3 – SEPG

“[Benefício] seria a clareza de todos os envolvidos,


do que tá sendo feito, a responsabilidade de cada
um. Até mesmo ele traz um pouco de, qual é a
palavra, “estímulo” pras pessoas do projeto. Tem
uma reunião semanal, que a gente tá verificando, o
que ta se passando de uma semana pra outra, o que
a gente evoluiu, o que a gente não evoluiu, porque
não evoluiu. Leva a gente a ter mais
comprometimento com o projeto. Esse achei a
maior vantagem do projeto.Enquanto antes a gente
não tinha todo o lado do processo. Eu tinha a
página, eu tinha a modelagem, mas eu não sei quem
tá fazendo o quê.” - Gerente de Projetos – GP

“Tem muito benefício. Eu tinha uma variação de


50% de custo, hoje eu tenho no máximo uma
variação de 10%. Sei o que eu to vendendo pra você,
sei quanto é o custo, controle melhor o custo, a parte
de prazo também começa a melhorar. Se eu deixava
de chutar [sic] como eu chutava antes ... to falando
mais no nível 2, tá. [...] que é mais gerencial, por
isso ele foca no prazo, custo, principais problemas
de configuração, então começa ter muita vantagem a
empresa.” – Consultor
139

Categorias Autores Transcrição


Legitimação AVEGEROU, 2000 “Dá a impressão que a ABC mais gente sabe que
existe [...] A gente tá mais conhecido, a gente tá
BERGER e
mais no mercado, vamos dizer assim, a gente
LUCKMAN, 1967 tem mais dificuldade pra orçar e fazer projetos
pra clientes pequenininhos, pra cliente pequeno
DiMAGGIO;
e que a gente tem bem mais facilidade em atuar
POWELL, 1983 em projeto grande, pra cliente grande.” -
Analista 1 – SEPG
KING et al, 1994
MEYER; ROWAN, “Hoje de consultoria, o pessoal [fala]: ‘ah ABC’,
você vai num evento: ‘ah ABC, sim, que tem de
1977;
cliente [a empresa] não sei o quê’. Isso eu
TOLBERT; percebi que melhorou.” – Analista 1 – SEPG
ZUCKER, 1998
“Teve a motivação comercial e a qualidade. Era
mais comercial. Porque vamos supor, se você
que... Se vê bem que é comercial, porque você
não precisaria tirar a certificação para área estar
dentro do processo. Ou se você tirar a
certificação, é porque você quer. Você pode
estar dentro do processo sem tirar a
certificação.” - Analista – SQA

“[Benefícios] pra área comercial, sem dúvida


nenhuma, continua sendo uma porta de entrada
pro pessoal. Tá no cartãozinho do pessoal, ABC
– CMMI” - Gerente de Projetos – GP

“Modelo é modelo, não se pode esquecer disso.


Ele é um mundo ideal, ele pega algumas
experiências e coloca no modelo. Então você
também tem que ter um pouco de flexibilidade
para entender que você não pode seguir ao pé da
letra.” - Consultor

Isomorfismo DiMAGGIO; “E começaram a sinalizar, o MPS.BR tá


ganhando força, as instituições do governo já
coercitivo POWELL, 1983
estão começando a colocar isso nas licitações,
KING et al, 1994 como pontuação já estão aceitando a avaliação
do MPS.BR como um item pra pontuação em
MEYER; ROWAN,
licitações, isso a gente também já tinha do
1977; nosso comercial, a gente alinhou isso com
nossos comercial, e aí, tá aparecendo mesmo
nas licitações, a gente tem uma lá do ministério
de não sei o quê que tem uma, eles já pontuam
igual ao CMMI e uma lá que tá pontuando o
MPSBR mais do que o CMMI.
140

Categorias Autores Transcrição


Ah legal, então, o que a gente vislumbrou que com,
isso foi informação da consultoria, como elas eram
bastante semelhantes os dois modelos, eles tinham
uma linha muito parecida, quase um pra um em
todos os processos, a gente, valeria a pena fazer um
trabalho conjunto, então SEPG trabalharia sempre
com CMMI e MPS.BR, mais partiria para uma
avaliação de MPS.BR que colocaria a gente com
um investimento menor com o mesmo nível de
qualidade de produtos, de processo, nossos
processos de desenvolvimento com o mesmo nível
de qualidade de um CMMI a um custo menor, a
gente viu vantagem, viu um lado positivo, e o
resultado final é equivalente.

A gente já enxerga possibilidades de usar o


MPSBR pra pontuar em vários tipos de licitação
que a agente participa, então porque ir pra um
CMMI agora, se a gente pode fazer uma avaliação
de MPSBR. O motivador foi mais ou menos esse.
Ter um resultado equivalente a um custo menor, e
ampliar o horizonte de participações em licitações.
Licitações que pontuam com o CMMI, a gente tem,
as que pontuam em MPS.BR, a gente tem
também.” – Coordenador SQA

“A meu ver, [uma motivação] partiu de uma célula


específica, que a célula P, que trabalha com a BP,
que trabalha com clientes de maior poder
aquisitivo, maiores clientes, para que eles pudessem
justificar os custos do projetos: a ABC tem preço e
tem qualidade. Outro (ponto de motivação) seria
ganhar das outras consultorias em licitações
públicas e concorrências.” - Gerente de Projetos –
GP

“Um dos grandes motivos que levou a certificação,


porque como a gente mexe com BD, BP, tudo mais,
eles pegaram e decidiram que eles querem projetos
seguindo o CMMI. Eu acho que esse foi o grande
motivo de tirar a certificação. Acho que com isso
conseguimos fechar vários projetos com BD, BP.” -
Analista – SQA

“Como o mercado está entrando nessa parte de


gestão, hoje os próprios clientes tem exigido isso,
têm exigido essa documentação, é requisito dos
próprios clientes.” – Analista 2 - SEPG
141

Categorias Autores Transcrição


“Não tinha tanto a preocupação da certificação
na época [de prospecção de consultorias]. Eles
perguntaram várias coisas da certificação, mas
o ponto não era tanto a certificação em si logo
no começo. Depois se tornou. Mas era mais
para organizar a empresa que eles tavam
perdidos, eles tavam com a área toda
desorganizada, eles precisavam disso, e sabiam
que essa história do CMM, na época foi pelo
CMM que chamaram a gente, tava evoluindo no
Brasil e tava começando a ser uma exigência do
mercado, e eles queria se preparar. [...] Depois
teve a motivação da certificação sim, tá, porque
daí viram que precisava disso aí, também da
certificação.Porque tem a motivação pra órgãos
do governo, eles fornecem para a BP. A BP faz
a licitação pontuando CMMI ou MPS.BR
equivalente.Então eles tem a motivação, além
de organizar a casa lá, ter a certificação
também é estratégico para eles” – Consultor
Isomorfismo DiMAGGIO; “A gente passou a estar mais no mercado, até a
consultoria levou a gente pro SPIN, pro grupo de
Normativo POWELL, 1983
melhorias de processos. [...] A gente fez palestra, eu
KING et al, 1994 fiz palestra, o S [Coordenador do SQA] fez palestra, o
pessoal veio aqui ver palestra, então dá a impressão
que a ABC mais gente sabe que existe [palestras
sobre a experiência na SEPG]” – Analista 1

“É, lá na ABC chamam o grupo de SEPG [Software


Enginnering Process Group] também [este nome é
atribuído pela SEI]” – Consultor

“Foi criado o grupo SEPG que era responsável por


conduzir os trabalhos da certificação” - Coordenador
SQA

“Fui treinado pelo cara que era SQA de projetos, e


conhecia todo o portal de processos, que é onde fica
todos os processos da ABC e tudo mais. Você tem
que decorar praticamente tudo porque, como você
que vai auditar todo processo, você tem que conhecer
basicamente quase tudo ou tem que saber aonde ta
para poder auditar.. – Analista SQA

“Já teve umas palestras de SQA e falam que todos os


SQAs tem problema. [...]Tem o SEI, no Sei teve algum
palestras sobre SQA, que você conhece SQAs de outra
empresa e contam sobre o processo de certificação,e aí
falam as condições de um SQA” – Analista SQA
142

Categorias Autores Transcrição


Isomorfismo DiMAGGIO; “O maior deles [motivação para a certificação] foi a
exigência do mercado por fornecedores de serviços
Mimético POWELL, 1983
com a certificação e nós não poderíamos deixar de
KING et al, 1994 lado esse indicador.” - Analista 3 – SEPG

“Um dos diretores disse após o processo, a


avaliação que o processo de certificação não
precisava ter ocorrido naquele momento, mas que
poderia ter vindo mais tarde, acompanhando o
crescimento natural da empresa” – Coordenador
SQA

“A gente ouve também: ‘eu preciso porque tem a


concorrência, eu preciso porque o mercado, pô, tá
evoluindo esse negócio, ta ficando uma realidade.
Acho que meu cliente vai cobrar mais pra frente’.”
- Consultor

“Eu acho uma realidade (o CMMI no Brasil). Eu


acho não, eu tenho certeza que é uma realidade. Se
não for o CMMI é o MPS.BR que é um
equivalente, uma forma nacional. É uma realidade
porque tá crescendo demais isso, o crescimento é
muito grande. Ainda é pouco se a gente for ver todo
o mundo de desenvolvimento de software que tem
no Brasil. Ainda é pouco, mas eu acho que uma
empresas que não se organizar, não se aperfeiçoar
um pouco, com o tempo a tendência é cair. Eu acho
uma realidade sim.” – Consultor
Rituais e CALDAS; “[O CMMI] tem muitas vantagens sim, que são
percebidas ao longo das empresas. Que levam a
Cerimônias VASCONCELOS,
sério. [...] eu falo ‘levar a sério’ porque tem muita
2002; empresa na época, não vou nem falar de CMMI, da
ISO 9000. ‘ah, essa norma aí não serviu de nada pra
DUTTON;
mim, não deu resultado nenhum’.Não deu resultado
DUCHERICH´S, porque não soube aplicar corretamente. Fez um
processo pra ter certificação. Daí não dá resultado
1991
mesmo” - Consultor
MEYER; ROWAN,
“Então atualmente eu tô em projetos de
1977;
manutenção, então eles são só manutenção então
ele não segue o processo. Que entra no projeto no
CMMI são projetos maiores, assim que tem alto
consumo de horas. Como é manutenção, coisa
pequena, que já estava funcionando, não entra no
processo CMMI. Você segue as práticas, mas não é
aquele processo todo de auditoria e tudo mais. Tem
uma certa quantidade de horas pra entrar no
processo do CMMI” - Analista – SQA
143

Categorias Autores Transcrição


“Na medida em que quando apresentaram o modelo
e você compra essa idéia do modelo, você quer que
isso se torne realmente a metodologia da empresa, e
não é bem isso que acontece” - Gerente de Projetos
– GP

“Pelo menos no nível 2, ficou tranqüilo da gente


levar o projeto. Isso foi um ponto muito bom. Ponto
que até dava pra ser colocado, não todo o processo,
mas muito dele em todos os projetos, seria
interessante até mesmo pra empresa não apagar
essa chama do CMMI. Ah, a gente não vai fazer
todo, mas vamos fazer um pouquinho. Já é uma
etapa que você vai fazer com ou sem CMMI, então
faça com o processo definido” - Gerente de
Projetos – GP

“[A consultoria] fizeram simulações muito mais


difíceis do que na hora que veio o avaliador oficial.
A gente passou tranqüilo em todas elas. – Analista
1 - SEPG

“Eles investiram bastante e não tão aplicando uma


coisa que poderia ser aplicada na empresa inteira
[...] Algumas áreas não querem aplicar” - Consultor

A unidade organizacional é definida pela empresa


para ser certificada [na representação por níveis do
CMMI] [...] é que elas falam empresa porque aí é o
“marketing”. No caso a ABC eram 3 áreas que
foram avaliadas, compondo uma unidade
organizacional que tinham projetos para apresentar
[na avaliação] [...] o diploma sai com o nome
dessas áreas. É lógico que o marketing vai falar que
é a ABC. O próprio SEI, se você vai lá no SEI
[site], você vai achar o nome ABC” e não ABC
área alguma coisa.”- Consultor

“A maioria dos clientes ou do mercado não sabe


desse direito que ele mesmo tem [verificar qual
área organizacional foi avaliada pelo SEI]. Ele tem
direito total de conferir. - Consultor

Então num processo de licitação, com nível 2


CMMI valendo 1 ponto, e aí ele atribui este ponto,
mas a unidade organizacional que irá produzir para
ele não é certificada... – Pesquisadora.
144

Categorias Autores Transcrição


Exatamente. Pode acontecer e deve acontecer
bastante. Não é só a ABC, eu tô falando do
mercado. O mercado não sabe disso. Não sabe
porque também não consulta, porque tá aberto no
SEI, você pode exigir. Eu acho que o mercado
nosso não cobra, muito pouco se cobrar. Ninguém
está errado. A ABC não está errada. Eles aplicam
de acordo com as restrições que eles têm. Mas
marketing é marketing, né?”– Consultor

“Eles pegaram nível 2 a [ABC], eles conseguiram a


avaliação, mas sabiam também que não tava tão
bem aplicado na empresa. ‘Tão bem’ no sentido de,
não tava “institucionalizada” realmente. Tava nível
2, mas aquele nível 2 que ainda precisava
amadurecer. Quer dizer, ele tinha que rodar um
pouco mais, tanto que a continuidade dos trabalhos
foi nesse sentido, de rever o 2, com uma visão mais
de nível 2, mas reviu, fez toda a revisão, tanto que
eles estão revisando processos do nível 2 até hoje
ainda, algumas coisas.” – Consultor
Quadro 21: Classificação dos conteúdos das entrevistas nas categorias elaboradas.
Fonte: elaboração própria.

Outros indícios, além do conteúdo das entrevistas, reforçam o caráter de


institucionalização, como por exemplo, para divulgar a adoção de um modelo complexo e
mundialmente aceito, a ABC utilizou-se de mecanismos naturais através da interação social
da empresa e de seus membros em eventos ou através do uso de mecanismos forçados, como
por exemplo, a ampla divulgação de sua certificação: seja via press release em sites da área
de tecnologia de informação e sistemas, seja via seu próprio site, e também a inclusão do
logotipo CMMI nos cartões profissionais de seus empregados e também na tela inicial de seu
site.
Esta exposição levou a um ganho de legitimidade perante o mercado, que é
encarado de maneira positiva pelos entrevistados, argumentando que através da avaliação
CMMI, a empresa obteve maior visibilidade e, portanto, tornou-se mais conhecida pelo
mercado.
Entretanto, também segundo os entrevistados, há um grande número de projetos
que não estão incluídos no processo CMMI por não atenderem ao número mínimo de horas
requeridas ou por serem manutenção de sistemas, e que, portanto, não compensariam
financeiramente ao serem enquadrados nos processos CMMI.
145

Soma-se a isso a dificuldade da organização em estabelecer um novo


posicionamento de mercado, atendendo clientes maiores em detrimento dos menores, ainda
hoje significativos em seu portfólio. Estes clientes pequenos participam de uma fatia de
mercado com interesse principal em preço e, portanto, não podem ou não querem arcar com o
aumento dos preços dos projetos da ABC.
A manutenção da capability nos processos de desenvolvimento da maturidade ao
longo dos projetos é questionada por alguns autores (BRADY E DAVIES, 2004) devido ao
processo de desmobilização de equipes ao final dos projetos. Este processo de manutenção e
acúmulo de conhecimentos, experiências e vivência fica particularmente prejudicado com o
alto índice de rotatividade de funcionários apresentados pela ABC, que também é apontado
como um dificuldade por parte dos entrevistados como para manter a continuidade no uso dos
processos.
Com a criação de arranjos estruturais sugeridos pela SEI (Software Enginnering
Institute), ao se implantar o CMMI, como o grupo SEPG e a existência de auditores internos
de programas na forma de SQAs, ocorre a especialização profissional, a inserção de
profissionais em comunidades de prática. A implantação do CMMI também levou a ABC a
exigir de novos contratados a educação formal através de conhecimentos em CMMI, de
acordo com anúncios de vagas de emprego disponíveis em sites de colocação profissional,
aumentando assim as pressões normativas para geração do isomorfismo.
146

CONCLUSÕES

Esta pesquisa parte da seguinte proposição: há indícios de institucionalização no


processo de certificação em gerenciamento de projetos? Com base nas análises realizadas
podemos concluir que no caso de certificação da empresa ABC há indícios de
institucionalização no seu processo de certificação CMMI.
A despeito da institucionalização, os benefícios em termos de melhoria de
processos trazidos pelo processo de certificação CMMI pela ABC são aparentes. Todos os
entrevistados citaram algum tipo de melhoria no processo de produção de software da
organização e reforçaram vantagens e pontos positivos trazidos pela implantação do CMMI.
Entretanto, podemos encontrar determinados vieses em relação a estes benefícios.
O processo de certificação do CMMI trouxe para ABC a coordenação,
monitoramento, controle e reação ao seu processo de desenvolvimento. Entretanto, estes são
considerados os processos básicos de gestão: planejar, coordenar, controlar e monitorar.
Independente do processo de certificação ou da implantação do CMMI, a ABC teria de
realizar a estruturação de suas atividades, ao buscar alçar patamares maiores de
competitividade.
O fato dos processos conforme o CMMI não terem sido implantados em todas as
áreas que envolvem desenvolvimento de software também é um ponto que mascara os reais
efeitos desses benefícios para a organização.
Também há indícios de que a empresa aumentou o seu nível de maturidade ao
realizar o processo de implantação do CMMI. Na literatura crítica a respeito do CMMI
encontramos dois tipos de empresas: empresas maduras que não têm problemas em atingir os
níveis de maturidade no processo de avaliação, e empresas imaturas, que devem realizar
trabalhos hercúleos para obter resultados positivos na avaliação, e que podem fazer uso de
mecanismos para burlar o processo de avaliação, de forma a se certificarem. (O´CONNELL;
SAIEDIAN, 2000).
Posicionamos a ABC na segunda categoria de empresas: a necessidade de
organização de seus processos foi muito grande, gerando um trabalhoso e longo processo para
obtenção da certificação. A ABC contou com forte auxílio da empresa de consultoria
realizando simulados do processo de avaliação, facilitando assim o processo verdadeiro. O
147

próprio consultor assume que o nível de maturidade da ABC, mesmo após a aquisição
certificação, não estava concretizado.
Isto contradiz uma das definições de maturidade, um paralelo entre a vida e o
processo de gerenciamento de projetos: maturidade significa cabelos brancos, traduzidos em
anos de experiências e vivências acumuladas. (KERZNER, 1987)
O isomorfismo institucional apresenta-se fortemente no caso de certificação da
ABC. O principal motivo apresentado para a obtenção da certificação CMMI foram as
pressões coercitivas de órgãos do governo e empresas de grande porte em pontuar o CMMI
em seus processos de aquisição de software.
Esta conclusão fica evidente, ao identificarmos como principal motivo para a
realização da certificação as pressões de órgãos governamentais e outros grandes clientes,
realizadas através da atribuição de pontuações em seus processos de contratação de
fornecimento de software a empresas que possuam tal certificação.
Vasconcelos e Vasconcelos (2000) questionam o caráter de isomorfismo
institucional em implantações instrumentais, feitas de maneira superficial, com alta resistência
de participantes, já que não há alteração nas estruturas dos sistemas sociais, práticas
cotidianas, nos seus padrões culturais e jogos de poder.
Entretanto na ABC, embora tenha ocorrido a resistência de algumas equipes e a
não implantação de todos os processos CMMI em toda a organização, podemos observar que
ocorreram mudanças nos sistemas sociais, através da implantação das área de SEPG e da
auditoria na forma de SQA. Embora a atuação destes membros seja mais forte nos grupos que
desenvolvem dentro dos processos determinados pelo CMMI, posteriormente a implantação
de uma área de SQA – Software Quality Assurance, alterou os sistemas sociais e práticas
cotidianas, já que esta área estendeu sua atuação não somente a projetos vinculados a
certificações, mas a todos os projetos de desenvolvimento da empresa.
Os mecanismos gerados pelo processo de certificação CMMI reforçam a geração
de procedimentos de caráter cerimonial. A própria avaliação tem aura de um rito de
passagem, permitindo à empresa acessar um “clube exclusivo” de organizações bem
sucedidas e muito preocupadas com a melhoria de seus processos de desenvolvimento de
software.
A atribuição da certificação à empresa como um todo, por parte da mídia em geral,
e até mesmo pela especializada em TI (que na sua grande maioria das vezes não corresponde
à realidade, já que são avaliadas unidades organizacionais) corrobora o caráter cerimonial.
Alguns entrevistados demonstraram insatisfação, pois, após o engajamento com o projeto de
148

certificação, perceberam que nem toda a empresa estava ou seria enquadrada nos modelos do
CMMI. De forma geral, apenas núcleos que operam grandes contas - na qual o CMMI pontua
para a escolha de um fornecedor de software - utilizariam da melhoria dos processos.
Mais agravante ainda é o fato de muitas vezes uma empresa ser contratada com
base em informações não verdadeiras - a unidade organizacional certificada pelo CMMI não é
a mesma que irá realizar o desenvolvimento – devido até à falta de monitoramento de
contratantes, o que também reforça a característica de cerimônia.
Encontramos, assim, indícios de comportamento cerimonial no processo de
certificação da empresa ABC, buscando de forma prioritária, portanto, a legitimidade frente a
seu campo de atuação, em detrimento de ganhos de eficiência e melhoria de processo.
Embora a ABC soubesse de suas necessidades na melhoria de seus processos
internos, as principais motivações para a certificação CMMI partiram de elementos externos à
organização, principalmente as pressões institucionais de órgãos governamentais e empresas
grandes, através da atribuição de pontos em processos de licitação ou concorrência para
fornecedores detentores de certificação.
A ABC cedeu a estas pressões e iniciou o processo de certificação. Entretanto,
podemos perceber que esta decisão foi pouco planejada: a empresa desconhecia os impactos
que a certificação traria para a organização e não estava preparada para tratar destas
conseqüências. Ou seja, só à medida que surgiam, é que os impactos eram tratados, o que
levou a um processo de certificação longo, trabalhoso e até traumático pelos envolvidos.
Entretanto, analisando esta situação específica encontramos uma situação
paradoxal: não era possível exigir da empresa ABC uma melhor avaliação de suas
necessidades ou realização de um planejamento quanto à obtenção da certificação, já que,
conforme analisado no caso, os processos básicos de gestão não existiam na organização.
Estas avaliações e planejamentos só se tornaram possíveis após a certificação, inclusive com o
estabelecimento da área de SQA, que atualmente também é responsável por coordenar todos
os aspectos que envolvem as certificações da organização.
Ao analisarmos o portfólio da ABC podemos perceber que a empresa atua com
dois nichos de mercado muito distintos: grande empresas e pequenas empresas. Entretanto, a
ABC tomou como decisão ceder às pressões das grandes empresas e mimetizar práticas de
empresas que atuam nesse nicho, dificultando dessa maneira a sua atuação no nicho das
pequenas empresas, que não enxergam valor na certificação CMMI, sendo seu critério de
escolha o fator preço. Entretanto, isso acabou por gerar a adoção de estruturas que não
149

atendem a toda a organização, com grande resistência inicial, e que ainda gera
questionamentos internos.
Em contraponto, a adoção da certificação leva a empresa à necessidade de um
reposicionamento no mercado de desenvolvimento de software. Se antes a ABC fornecia tanto
para pequenos clientes quanto aos grandes, há agora a necessidade de um direcionamento de
suas atividades para os clientes maiores, de forma tanto a justificar seus gastos com a
certificação quanto a obter desenvolvimentos de projetos que justifiquem o uso das
metodologias.
Neste caso, comprovamos a necessidade de avaliação dos processos de
institucionalização dentro de seus contextos, avaliando-se a pressão institucional em
diferentes níveis (MACHADO-DA-SILVA; GONÇALVES, 1998), pois a ABC encontrava-se
em meio a dois ambientes distintos: o das grandes empresas, imersas num contexto
institucional que valoriza as certificações e padronizações como sinônimas de qualidade e
eficiência de processos, e num outro contexto composto por pequenas empresas, nos quais as
relações comerciais baseiam-se em preço e confiança. A falta de uma melhor avaliação destes
dois ambientes levou a empresa a tomar uma decisão sem ter como resguardo ações que
garantissem o equilíbrio de seus negócios no longo prazo.
Em resumo, podemos concluir que conseguimos identificar indícios de
institucionalização no processo de certificação em CMMI da empresa ABC, respeitados os
parâmetros do contexto no qual está inserida, objetivo principal desta pesquisa.
Observamos, também, que o principal motivador do processo de tomada de
decisão foram as pressões institucionais, verificadas sob a forma de isomorfismo coercitivo,
mas com presenças do isomorfismo normativo e mimético, buscando-se assim legitimidade,
conformidade, obtidas inclusive através de comportamento cerimonial. Outras motivações
identificadas estão relacionadas à necessidade de melhorias em seus processos de
gerenciamento de projetos, cumprindo assim os objetivos específicos desta pesquisa.
Do aspecto diverso da realidade que nos leva a analisar as forças institucionais
dentro de diferentes contextos, extraímos a maior contribuição deste trabalho para o mundo
empresarial, através de uma visão multi-paradigmática da Teoria Institucional. As pressões
institucionais existem e são uma realidade, entretanto não representam uma realidade estática,
nem funcionam unidirecionalmente. Portanto, embora mergulhadas em modelos,
metodologias e conceitos que pregam a racionalidade, as organizações devem compreender a
existência das pressões institucionais, aprender a analisá-las e compreendê-las dentro do
150

ambiente institucional do qual fazem parte, para que assim possam tomar suas decisões
estratégicas como respostas adequadas. (OLIVER, 1991).
Também é fundamental que as empresas compreendam a força das pressões
institucionais como forma de se precaver contra a supervalorização de selos de certificações
como ícones de qualidade, ao se selecionarem parceiros e principalmente fornecedores de
produtos e serviços. Fundamentar suas escolhas de contratação baseadas apenas na crença da
garantia de qualidade apresentada via uma certificação pode mostrar-se desastroso no futuro.
Por fim, a identificação de indícios de institucionalização no processo de
certificação em CMMI da empresa ABC, respeitados os parâmetros do contexto no qual esta
inserida, contribui para o enriquecimento no campo de conhecimento em modelos de
maturidade em gerenciamento de projetos, fornecendo uma perspectiva institucional.

1.10. RECOMENDAÇÕES

Através da análise do caso de certificação da empresa ABC, podemos extrair


algumas recomendações.
Umas das conseqüências de maior impacto que a certificação trouxe para a
organização certamente é a mudança de posicionamento no mercado. Passados mais de dois
anos após a certificação, a empresa ainda tenta buscar sua identidade e lugar dentro do
mercado de desenvolvimento de software. Esta situação contribuiu para o questionamento da
certificação, se era realmente necessária ou se era realmente o momento propício para a
obtenção.
Conforme dito a pouco, os processos de gestão necessários para avaliar-se a
certificação só vieram após a certificação, com a estruturação de seus processos, a utilização
de mecanismos de planejamento, monitoramento e controle, que resultaram inclusive na
criação da área SQA, responsável pelos assuntos tangentes às certificações da ABC.
Faz-se necessário agora que esta área efetivamente cumpra seu papel de avaliação
das certificações, inclusive sensibilizando a Alta Direção a respeito de tomadas de decisões
estratégicas em relação a certificações, que envolvam o planejamento e direcionamento dos
negócios com base na aquisição de novas certificações.
É de extrema importância que as organizações tenham maior consciência a
respeito das pressões institucionais, sobretudo dos impactos de suas estratégias de respostas a
151

estas pressões, sobretudo no Brasil, no qual convivemos com uma grande diversidade de
competição e mercados. Conforme citado anteriormente, é fundamental que uma organização
conheça sua posição em relação às pressões institucionais, e saiba responder adequadamente,
bem como busque investigar para saber a situação de seus parceiros e fornecedores, de forma
a evitar que comportamentos cerimoniais de outros, em detrimento da eficiência, venham a
afetar seus negócios.
Sob o ponto de vista acadêmico, conforme a literatura revisada, verificamos a
carência de estudos de caráter menos prescritivo no campo de gerenciamento de projetos e
modelos de maturidade, principalmente no Brasil. A evolução do estudo em gerenciamento de
projetos no Brasil ainda caminha a passos lentos, seguindo as tendências de pesquisa
americanas e européias, cujas evidências sobre os resultados efetivos da adoção de modelos
de maturidade também são insuficientes.
Com a crescente popularização deste tema no país e crescentes índices de adoção
das certificações em modelos de maturidade, abre-se um extenso e fértil campo de estudos a
pesquisadores, no qual a realidade das organizações brasileiras ainda permanece mal
explorada. Faz-se necessária a construção de um conhecimento envolvendo gerenciamento de
projetos e modelos de maturidade mais críticas e mais aderentes à realidade nacional,
inclusive com a utilização de diferentes perspectivas, contribuindo, desta forma, para a
construção de uma alternativa à linha de pensamento vigente, baseada em supostos
pragmatismos e racionalidades.
152

LIMITAÇÕES

Como limitações para esta pesquisa podemos citar uma particularidade da


empresa: o alto índice de rotatividade dos empregados da organização dificultou o acesso a
muitos profissionais que participaram do processo de certificação em 2003. Certamente, esta
restrição de acesso gerou perdas de informações que poderiam contribuir e enriquecer o
estudo de caso.
Outra limitação da pesquisa refere-se ao domínio da pesquisadora em línguas
estrangeiras. Foram encontrados artigos em alemão sobre estudo em modelos de maturidade
em projetos, entretanto não puderam ser utilizados. O uso dos artigos em francês também foi
limitado pelo mesmo motivo. A pesquisa foi basicamente construída por artigos, sites e
documentos em inglês e português.
Embora os procedimentos de garantia de validade interna e externa estejam
contemplados, o estudo de caso único traz restrições à generalização, próprias de sua
natureza, o que também limita este estudo. Entretanto, a elaboração do desenvolvimento
teórico busca atingir um grau mais alto de generalização, contemplando o processo de
certificação em gerenciamento de projetos.
A elaboração da análise macro, baseada na literatura em modelos de maturidade,
CMMI e Teoria Institucional, busca analisar a perspectiva institucional do CMMI
estabelecendo fundamentos para a análise, de forma a obter maior grau de generalização.
153

ESTUDOS FUTUROS

Futuramente, esta pesquisa pode ser estendida buscando se estabelecer um maior


índice de generalização. Isto pode ser obtido buscando-se realizar estudos de casos múltiplos
com outras empresas desenvolvedoras de software no Brasil, estabelecendo comparações com
empresas de mesmo nível de maturidade, bem como com empresas com níveis de maturidade
diferentes.
O uso do CMMI como modelo de certificação de estudo também permite a
comparação com casos fora do país, estabelecendo semelhanças e diferenças com empresas de
países em desenvolvimento e países com base em CMMI já estabelecida, buscando
principalmente comprovar o papel coercitivo do governo em países em desenvolvimento, cujo
cenário tecnológico possui maior grau de incertezas.
Também podemos verificar indícios de institucionalização na implantação de
outros modelos de maturidade em gerenciamento de projetos.
Por fim, podemos ampliar os estudos sobre modelos de maturidade em
gerenciamento de projetos, buscando a comprovação de resultados positivos e numéricos em
relação à sua adoção e certificação.
154

REFERÊNCIAS

ABRAHAMSON, E. Managerial fads and fashion: the diffusion and rejection on innovations.
Academy of Management Review, v.18, n.3, p.586-612, Jul.1991.

ALBERTIN, A. L. Aumentando as chances de sucesso no desenvolvimento e implementação


de sistemas de informações. Revista de Administração de Empresas, v.36, n. 3, p. 61-69,
Jul./Set. 1996.

ALBERTIN, A. L. Valor Estratégico dos projetos de tecnologia de informação. Revista de


Administração de Empresas, v.41, n.3, p.42-50, Jul./Set. 2001.

ALBUQUERQUE, L.G. Competitividade e recursos humanos. Revista de Administração,


v.27, n.4, São Paulo, p.16-29, 1992.

APMG. Measure Your organisation’s maturity with the APM Group’s P3M3 assessment.
Disponível
em:http://www.apmgroup.co.uk/nmsruntime/saveasdialog.asp?lID=732&sID=200. Acesso
em: 21 de Dezembro de 2007.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS - ABNT. Certificação. Disponível


em: http://www.abnt.org.br/certif_body.htm.Acesso em: 15 de Julho de 2007.

AVGEROU, C. IT and organizational change: an institutional perspective. Information


Technology and People, v.13, n. 4, p.234-262, 2000

AYRES, B. J. Institutional influences and control of software development projects: an


examination of Air Force Software Project Teams. 2003. 202 f. Dissertation (Doctor of
Philosophy) - The Florida State University College of Business.

BACCARINI, D. The logical framework method of defining project success. Project


Management Journal, v.30, n.4, p.25-32, Dec. 1999.

BADOO, N., HALL, T. Motivators of Software Process Improvement: an analysis of


practioners’ views. The Journal of System and Software, v.62, p. 85-96, 2002.
155

BADOO, N., HALL, T. De- motivators of Software Process Improvement: an analysis of


practioners’ views. The Journal of System and Software, v. 66, p. 85-96, 2003.

BENSABAT, I., GOLDESTEIN, D.K., MEAD, M. The case research strategy in studies of
information systems. MIS Quarterly, v.11, n.3, p.369-386, Set. 1987.

BERGER, P. L., LUCKMANN, T. A construção social da realidade. 25.ed. São Paulo:


Editora Vozes, 2005.

BOLINGER, T.B.; McGOWAN, C. A critical look at software capability evaluations. IEEE


Software, v.8 n.4, p.25-41, 1991.

BOUER, R., CARVALHO, M.M. Metodologia singular de gestão de projetos: condição


suficiente para a maturidade em gestão de projetos. Revista Produção, v.15, n.3, p.347-36,
Set/Dez 2005.

BRADY, T., DAVIES, A. Building project capability: from exploration to exploitation.


Organization Studies, v. 25, n. 9, p. 1601-1621, 2004.

CALDAS, M. P., VASCONCELOS, F. C. Ceremonial behavior in organization intervention:


the case of ISO 9000 diffusion in Brazil. ENCONTRO ANUAL DA ASSOCIAÇÃO
NACIONAL DE PÓS-GRADUAÇÃO EM ADMINISTRAÇÃO, 26., 2002, Salvador. Anais.
Salvador: ANPAD, 2002.

CLELAND, D. I., IRELAND.I., R. Project Management: strategic design and


implementation. New York: McGrall-Hill, 2002

COOKE-DAVIES, T. The “real” success factors on projects. International Project


Management, n.20, p.185-190, 2002.

COOKE-DAVIES, T., ARZYMANOW, A. The maturity of project management in different


industries: An investigation into variations between project management models.
International Project Management, n.21, p.471-478, 2003.

CORRÊA, H.L., CORRÊA, C.A., Administração da produção e operações. Manufatura e


Serviços: uma Abordagem Estratégica. 1.ed. Editora Atlas: São Paulo. 2004.
156

DiMAGGIO, P.J., POWELL, W.W. The iron cage revisited: institutional isomorphism and
collective rationality in organizational fields. American Sociological Review, v. 48, n. 2, p.
147-160, Apr. 1983.

DiMAGGIO, P. Culture and cognition. Annual Review of Sociology, v. 23, p. 263-287, 1997.

DINSMORE. P. C., CABANIS-BREWIN, J. The AMA handbook of project management.


2.ed. New York: The AMACOM – American Management Association, 2006.

DUBÉ, L. PARRÉ, G., Rigor in information systems positivist case research: current pratices,
trends, and recommendations. MIS Quarterly, v. 27, n. 4, p. 597-635, Dec. 2003.

DUTTON, J. E., DUCHERICHS, J. M. Keeping eye in the mirror: image and identity in
organizational adaptation. Academy of Management Journal., v.34, n.3, p.517-554, 1991.

EISENHARDT, K. M., building theories from case study research. Academy of Management
Review, v. 14, n. 4, p. 532-550, 1989.

FAHRENKROG, S., WESMAN, P. R., ANDOWSKI, A. KEUTEN, T., Project Management


Institute´s Organizational Project Management Maturity Model (OPM3). WORLD
CONGRESS ON PROJECT MANAGEMENT. 17., 2003, Moscow. Proceedings. Moscow:
PMI, Jun. 2003.

FRAME, D. J.; Project Management competence: building skills for individuals, teams and
organizations. San Francisco: Jossey-Bass, 1999.

GALASKIEWICZ, J., WASSERMAN, S. Mimetic process within an interorganizational


field: an empirical test. Administrative Science Quarterly, v.34, n.3, p.454-479, 1989.

GREGOR, S. The nature of theory in information systems. MIS Quarterly, v. 30, n. 3. p.


6111-642, Sep. 2006.

HACKMAN, J. R., WAGEMAN, R. Total quality management: empirical, conceptual, and


practical issues. Administrative Science Quarterly, v. 40, p.309 – 342, 1995.

HARTMAN, F., SKULMOSKI, G., Project management maturity. Project Management


Journal, v.4, n1, p.74-78. 1998.
157

HOWARD J. NASH J, EHRENFELD, J. Standard or smokescreen? Implementation of a


voluntary environmental code. California Management of Review, v. 42, n. 2, p. 63-80,
Winter 2000.

INTERNATIONAL PROJECT MANAGEMENT ASSOCIATION - IPMA. Disponível em:


http://www.ipma.ch/Pages/IPMA.aspx .Acesso em 15 de Julho de 2007.

INSTITUTO NACIONAL DE METROLOGIA, NORMALIZAÇÃO E QUALIDADE


INDUSTRIAL. Certificação. Disponível em:
http://www.inmetro.gov.br/qualidade/certificacao.asp. Acesso em: 15 de Julho de 2007.

JICK, Todd D. Mixing qualitative and quantitative methods: Triangulation in Action.


Administrative Science Quarterly, v. 24, n. 4, p. 602-611, Dec. 1979.

JUDGEV, K.; MÜLLER, R., A Retrospective look at our evolving understanding of project
success. Project Management Journal, vol. 36, n. 4, Dec. 2005.

KAPPELMAN, L. A., McKEEMAN, R., ZHANG, L. Early warning signs of IT project


failure: the dominant dozen. Information Systems Management, v. 4, n. 23, p. 31-36, fall
2006.

KERZNER, H. Strategic planning for project management using a project management


maturity model level. New York: John Wiley and Sons, 2001.

KERZNER, H. Gestão de projetos: as melhores práticas. Porto Alegre. Bookman.2002.

KERZNER, H. In search of excellence in project management. Journal of Systems


Management ,v.2, n.38, p. 30-39, Feb 1987.

KING, J.L. et al. Institutional factors in information technology innovation. Information


Systems Research, v. 5, n. 2, p.139-169, 1994.

KWAK, Y. H., IBBS, C. W. The Berkeley Project Management Process Maturity Model:
measuring the value of project management. ENGINNERING MANAGEMENT SOCIETY,
2000, Albuquerque. Proceedings. Albuquerque: IEEE. 2000.

KWAK, Y. H., IBBS, C. W. Project Management Process Maturity (PM²) Model. Journal of
Management in Engineering, v. 18, n. 3, p. 150-155, Jul. 2002.
158

LANGLEY, A. Strategies for theorizing from process data. Academy of Management Review,
v. 24, n.4, p. 691-710, 1999.

LEES, S. Ten faces of management development. Management Education and Development,


v. 23, p. 89-105, 1992.

LEROY, D.; O rumo das pesquisas em gerenciamento de projetos.Revista Mundo PM,


n.8.,p.54-61. Abr/Mai 2006.

LEROY, D., Institutionnalisation du mode project en France: reperages et interprétations.


CONFERENCE INTERNATIONALE DE MANAGEMENTE STRATEGIQUE, 16., 2007.
Montreal. Anais. Montreal: AIMS, Jun. 2007.

LIENBERG, E. Institutionalisation of software process improvement : a structurationalist


approach.2005. 150f. Dissertação (Mestrado - Faculty of Engineering and Information
Technology - School of Information and Communication Technology Griffith University),
Queensland.

LONGO, W. P., Programas Mobilizadores. Parcerias Estratégicas, n. 20, p.1535-1555, Jun


2005.

LOPES, J. C., Quem tem medo da competitividade?. Cadernos de Pesquisa em


Administração, São Paulo, v.1, n.3, p.1-4, 2º sem/1996.

MACHADO-DA-SILVA, C. FONSECA. V. S. CRUBELLATE, J. M. Unlocking the


institutionalization process: insights for as institutionalization approach. BAR – Brazilian
Administration Review, v.2, n.1, p.1-20, jan/june 2005. Disponível em:
http://anpad.org.br/bar/vol_02/dwn/bar_v2_n1_cms.pdf. Acesso em: 20 de Novembro de
2006.

MACHADO-DA-SILVA, C. GONÇALVES, S.A. Nota técnica: a teoria institucional. In:


CLEGG, S. R.; NORD, W. R.; HARD, C. Handbook de estudos organizacionais - Modelos
de análise e novas questões em estudos organizacionais. São Paulo: Atlas.1998.

MENEZES, L. C. de M. Gestão de Projeto. 2.ed. São Paulo: Editora Atlas. 2003.

MEYER, J. W., ROWAN, B. Institutionalized organizations: formal structure as myth and


ceremony. American Journal of Sociology, v. 83, n. 2, p.340-363, set.1977.
159

MIGNERAT, M., RIVARD, S. Positioning the institutional perspective in information


technology research. CONFERENCE OF ADMINISTRATIVE SCIENCE ASSOCIATION
OF CANADA, Mai. 2007, Toronto. Proceedings. Toronto: ASAC, May. 2005.

MIGNERAT, M., RIVARD, S. L’institutionnalisation des pratiques de gestion de projet


dans les projets de systèmes d’information. CONFERENCE OF ADMINISTRATIVE
SCIENCE ASSOCIATION OF CANADA, Mai. 2007, Banff. Proceedings. Banff: ASAC,
Jun. 2006.

MILES, M. B., HUBERMAN, A. M., Drawing valid meaning from qualitative data: toward a
shared craft. Educational Researcher. v. 13, n.5, p. 20-30, May 1984.

MINISTÉRIO DA CIÊNCIA E TECNOLOGIA. Tecnologia da Informação – Qualificação.


Disponível na Internet: http://ftp.mct.gov.br/Temas/info/Dsi/qualidad/CMM.htm. Acesso em
15 de março de 2007.

NIAZI M., STAPLES, M. Systematic review of organizational motivations for adopting


CMM-based SPI. Technical Report PA005957, National ICT, Australia, 2006.

O´CONELL, E, SAIEDIAN, H. Can you trust software capability evaluation?. Computer, Los
Alamitos, v.33, n.2, p.28-35, Feb 2000.

OFFICE OF GOVERNMENT COMMERCE - OGC. Portfolio, Programme & Project


Management Maturity Model (P3M3). Version 1.0, 2006.

OLIVER, C. Strategic responses to institutional processes. Academy of Management Review,


v. 6, n. 1, p.145-180, 1991.

ORWELL, G. A revolução dos bichos. São Paulo: Companhia das Letras, 2006.

PATTON, M. Q. Qualitative evaluation and research methods. 2.ed. Newbury Park: Sage
Publications,1990.

PRADO, D., MMPG – Um modelo brasileiro de maturidade em gerenciamento de projetos.


Revista MundoPM, v.1. n. 3. Jun./Jul. 2005.

PROJECT MANAGEMENT INSTITUTE – PMI . PMBOK – Project Management Book of


Knowledge. 3.ed. PMI, 2004.
160

PROJECT MANAGEMENT INSTITUTE – PMI. Disponível em:


http://www.pmi.org/info/default.asp. Acesso em: 15 de Julho de 2007.

QUEIROZ, L. O polêmico uso dos selos de qualidade nas licitações públicas.


CONVERGÊNCIA DIGITAL. 23/04/2007. Disponível em:
http://www.convergenciadigital.com.br/cgi/cgilua.exe/sys/start.htm?infoid=6971&sid=10&tpl
=printerview . Acesso em: 15 de Dezembro de 2007.

RABECHINI, R. PESSÔA, M. S. P. Um modelo estruturado de competências e maturidade


em gestão de projetos. Revista Produção, v.15, n.1, p. 34-43, Jan-Abr 2005.

ROSSETO, C. R. ROSSETO, A. M. Teoria institucional e dependência de recursos na


adaptação organizacional: uma visão complementar. RAE-eletrônica, São Paulo, v.4, n.1,
jan./jul.2005. Disponível em: http://www.rae.com.br/redirect.cfm?ID=1869. Acesso em:

SANTOS J.A., CARVALHO, H. G., Referencial Brasileiro de Competência em


Gerenciamento de Projetos. 2006. Disponível em:
http://www.abgp.org.br/novo/images/stories/docsdownloads/rbc_abgp_ipma_jan_2005.pdf
Acesso em: 01/12/2007.

SATO. C. E. Y.; Gestão corporativa de projetos para instituições de pesquisa tecnológica:


Caso Lactec. 2004. Dissertação (Mestrado em Tecnologia) - Centro Federal de Educação
Tecnológica do Paraná, Curitiba.

SCOTT, W.R. The adolescence of institutional theory. Administrative Science Quarterly,


v.32, n.4, p.493-511, Dec.1987.

SLACK, N. et al. R. Administração da produção. 1.ed. São Paulo: Editora Atlas, 1996.

SOFTWARE ENGINNERING INSTITUTE - SEI. Software Engineering Process Group


(SEPG) Guide, 1990. Disponível em:
http://www.sei.cmu.edu/pub/documents/90.reports/pdf/tr24.90.pdf. Acesso em: 28 de
Dezembro de 2007.

SOFTWARE ENGINNERING INSTITUTE - SEI. Standard CMMI Appraisal Method for


Process Improvement (SCAMPI),Version 1.1: Method Definition Document, 2001.
Disponível em: http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06hb002.pdf. Acesso
em: 28 de Dezembro de 2007.
161

SOFTWARE ENGINNERING INSTITUTE - SEI . Process Maturity Profile - CMMI®


SCAMPI Class A Appraisal Results
2005 End-Year Update, Mar 2005a. Disponível em: http://www.sei.cmu.edu/appraisal-
program/profile/pdf/CMMI/2005marCMMI.pdf.. Acesso em: 15 de Novembro de 2007.

SOFTWARE ENGINNERING INSTITUTE - SEI . Process Maturity Profile - CMMI®


SCAMPI Class A Appraisal Results
2005 Mid-Year Update, Sep 2005b. Disponível em: http://www.sei.cmu.edu/appraisal-
program/profile/pdf/CMMI/2005sepCMMI.pdf. Acesso em: 15 de Novembro de 2007.

SOFTWARE ENGINNERING INSTITUTE - SEI . Process Maturity Profile - CMMI®


SCAMPI Class A Appraisal Results 2006 End-Year Update, Mar 2006a. Disponível em:
http://www.sei.cmu.edu/appraisal-program/profile/pdf/CMMI/2006sepCMMI.pdf.. Acesso
em: 15 de Novembro de 2007.

SOFTWARE ENGINNERING INSTITUTE - SEI.. CMMI for Development v.1.2, Aug.


2006b. Disponível em: http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf.
Acesso em: 01 de Setembro de 2007.

SOFTWARE ENGINNERING INSTITUTE - SEI . Process Maturity Profile - CMMI®


SCAMPI Class A Appraisal Results 2006 Mid-Year Update, Sep 2006c. Disponível em:
http://www.sei.cmu.edu/appraisal-program/profile/pdf/CMMI/2006sepCMMI.pdf. . Acesso
em: 15 de Novembro de 2007.

SOFTWARE ENGINNERING INSTITUTE - SEI . Process Maturity Profile - CMMI®


SCAMPI Class A Appraisal Results 2007 End-Year Update, Mar 2007a. Disponível em:
http://www.sei.cmu.edu/appraisal-program/profile/pdf/CMMI/2007marCMMI.pdf. Acesso
em: 15 de Novembro de 2007.

SOFTWARE ENGINNERING INSTITUTE - SEI . Process Maturity Profile - CMMI®


SCAMPI Class A Appraisal Results 2007 Mid-Year Update, Sep 2007b. Disponível em:
http://www.sei.cmu.edu/appraisal-program/profile/pdf/CMMI/2007sepCMMI.pdf. Acesso
em: 15 de Novembro de 2007.

STANDISH GROUP. CHAOS Report. West Yarmouth, MA: Standish Group International
Inc., 2004.

STAPLES, M. et al. An exploratory study of why organizations do not adopts CMMI. The
Journal of Systems and Software, v.80, n.6, p.883- 895, out. 2006.
162

STRICKLER, Z. Elicitation methods in experimental design research. Design Issues, v.15,


n.2, p. 27-39, Summer, 1999.

STRANG, D., MEYER J. W. Institutional conditions for diffusions. Theory and Society, v.22.
n. 44, p. 487-511, Aug.1993.

TOLBERT, Z. ZUCHER, L. G. A institucionalização da teoria institucional. In: CLEGG, S.


R., NORD, W. R., HARD, C. Handbook de estudos organizacionais - Modelos de análise e
novas questões em estudos organizacionais. São Paulo: Atlas.1998.

TURBAN, E., McLEAN, E., WETHERBE, J. Tecnologia da informação para gestão –


transformando os negócios na economia digital. 3.ed. Porto Alegre: Editora Bookman, 2002.

VASCONCELOS, F. C., VASCONCELO, I. F.F.G. Isomorfismo estrutural e os limites da


normalização: dois estudos de caso sobre a implantação das normas ISO 9000 em empresas
de informática na França. ENCONTRO NACIONAL DE ESTUDOS ORGANIZACIONAIS.
1,.2000, Curitiba. Anais. Curitiba: ANPAD, 2000.

WEBER, K. et al. Melhoria de Processo do Software Brasileiro (MPS.BR): um Programa


Mobilizador. 2006. Disponível em:
http://golden.softex.br/portal/softexweb/uploadDocuments/26.pdf Acesso em: 15 de
Novembro de 2007.

WEBER, K. C., et al. Modelo de Referência para Melhoria de Processo de Software: uma
abordagem brasileira, CONFERENCIA LATINOAMERICANA DE INFORMATICA.30.
2004, Arequipa. Anais. Arequipa: CLEI, 2004.

WEBER, K. C. et al. MPS Model-Based Software Acquisition Process Improvement in


Brazil. QUALITY OF INFORMATION AND COMMUNICATIONS TECHNOLOGY. 6.,
2007. Lisboa. Proceedings. Lisboa: QUATIC, September 2007.

YIN, R. K. Estudo de Caso – Planejamento e Método. 3.ed.. Porto Alegre: Editora Bookman,
2001.

ZUCKER, L., The role of institutional in cultural persistence. American Sociological Review,
v. 14, p. 726-743, Oct. 1977.

ZUCKER, L., Institutional theories of organization. Annual Review of Sociology, v. 13, p.


443-464, 1987.