CENTRO DE FORMAÇÃO ACADÊMICA E PESQUISA CURSO DE MESTRADO EXECUTIVO
IDENTIFICAÇÃO
DA
ESTRUTURA
DE
ESCRITÓRIO
DE
GERENCIAMENTO DE PROJETOS ADEQUADA A PARTIR DA
AVALIÇÃO DO NÍVEL DE MATURIDADE EM GERENCIAMENTO DE
PROJETOS: UM ESTUDO SOBRE A ÁREA DE TECNOLOGIA DA
INFORMAÇÃO DA PETROBRAS
DISSERTAÇÃO APRESENTADA À ESCOLA BRASILEIRA DE ADMINISTRAÇÃO PÚBLICA E DE EMPRESAS PARA OBTENÇÃO DO GRAU DE MESTRE
AGRADECIMENTOS
Aos colegas da turma de Mestrado Executivo, pelos bons momentos de convívio, pelo apoio
na superação das dificuldades e pela sua amizade.
Ao professores do curso de Mestrado Executivo em Gestão Empresarial da Fundação Getulio
Vargas, por todo o conhecimento transmitido.
Ao professor Luis César Gonçalves de Araújo pela dedicação e apoio dispensados como
orientador desta dissertação.
Aos meus pais Rubem e Nilda, meus primeiros incentivadores na busca pela minha formação
acadêmica.
Ao meu esposo Márcio, pelo seu apoio, sua compreensão e seu amor.
Aos seguintes gerentes da TI da Petrobras pelo apoio e patrocínio na realização deste curso de
mestrado: Martha Gomes de Souza, Anna Maria Neville M. Nogueira, Maria Tereza Sotelino
Ramos e Jesu Guimarães.
Meus especiais agradecimentos aos colegas Ângela Ruriko Sakamoto, Carlos Roberto Soares
dos Santos, Herbet de Souza Cunha e Roberto Santos Constantino pela paciência em criticar e
“Excelência é uma habilidade conquistada através de treinamento e prática. Nós somos aquilo que fazemos repetidamente. Excelência, então, não é um ato, mas um hábito.”
RESUMO
Mudanças são implementadas através de projetos e estas vem ocorrendo cada vez mais
rapidamente e de maneira descontinuada. Com a demanda crescente de projetos, uma gestão
adequada passa a ser fundamental de forma a aumentar suas taxas de sucesso. A criação de
uma estrutura organizacional com a atribuição de concentrar o desenvolvimento de processos
e metodologias é uma iniciativa de formalização da gestão de projetos e facilitação da
disseminação de seus conceitos. Esta estrutura é o Escritório de Gerenciamento de Projetos,
que deve ser adequada ao grau de maturidade em gerenciamento de projetos da organização e
a sua estratégia.
Esta dissertação se propõe a aplicar um modelo que analise o nível de maturidade em
gerenciamento de projetos da área de Tecnologia da Informação da Petrobras e sugerir um
Escritório de Gerenciamento de Projetos adequado ao nível identificado podendo ser evoluído
ABSTRACT
Changing has been addressed by projects and it had happened in a fast and disarrenged way.
In consequence of the increasing on demand for projects, to get better success rate is essential
manage projects adequately. The creation of an organitional structure intended to concentrate
the development of process and methodologies is a great initiative to spread the projects
management concepts.
The purpose of this work is to apply a model to analyse the maturity level on project
management of the Petrobras IT Department and indicate an Project Management Office
SUMÁRIO
1 Introdução... 1
1.1 Contextualização do problema ... 1
1.2 Formulação do problema ... 2
1.3 Objetivos ... 5
1.3.1 Objetivo principal 5 1.3.2 Objetivos secundários 5 1.4 Delimitação do estudo... 6
1.5 Relevância do estudo... 6
1.6 Organização do trabalho ... 9
2 Referencial Teórico... 11
2.1 Gestão de Projeto... 11
2.2 Sucesso e Fracasso em Projetos... 20
2.3 Tipos de estruturas organizacionais ... 24
2.3.1 Estrutura funcional 25 2.3.2 Estrutura projetizada 27 2.3.3 Estrutura matricial 29 2.4 Competências em gerenciamento de projetos... 31
2.5.1 O Modelo CMM (Capability Maturity Model) 40
2.5.2 Modelo de Fincher & Levin 41
2.5.3 Modelo de Maturidade em Processos de Gerenciamento de Projetos (Project
Management Process Maturity Model) – (PM)2- modelo de Berkeley 43
2.5.4 Modelo de Maturidade de Kerzner 44
2.5.5 O Modelo do PMI – Organization Project Management Maturity Model
(OPM3) 47
2.5.6 Uma Análise Comparativa dos Modelos 51
2.6 Escritório de Gerenciamento de Projeto – PMO (Project Management Office) .. 53
2.6.1 O que é um PMO. 53
2.6.2 O papel e as funções de um PMO. 53
2.6.3 Implantação de um Escritório de Projeto 59
3 Metodologia ... 63
3.1 Pesquisa Bibliográfica... 64
3.2 Pesquisa de Campo... 64
3.2.1 Apresentação 64
3.2.2 Estrutura do Formulário 65
3.3 Limitações do Método... 74
4 Apresentação do Caso da Área de Tecnologia da Informação da Petrobras.... 75
4.1 A Petrobras ... 75
4.1.1 Histórico 75
4.1.2 Estrutura Organizacional e Atividades Desempenhadas 78
4.2 A Tecnologia da Informação ... 83
4.2.1 Histórico 83 4.2.2 Função TI 86 4.2.3 Missão, Visão e Valores da Tecnologia da Informação 88 4.2.4 Organização Geral da TI da Petrobras 89 4.2.5 Situação atual 95 5 Resultados e Análise da Pesquisa do Nível de Maturidade em Gerenciamento de Projetos ... 103
5.1 Resultados da pesquisa... 104
5.1.1 Distribuição das freqüências 105 5.2 Interpretação dos Resultados por seções da pesquisa ... 107
5.2.1 Análise das variáveis referentes à seção Institucional 107 5.2.2 Análise das variáveis referentes à seção Suporte Gerencial 108 5.2.3 Análise das variáveis referentes à seção Treinamento e Desenvolvimento110 5.2.4 Análise das variáveis referentes à seção Metodologia e Processos 117 5.2.5 Análise das variáveis referentes à seção Autoridade e Responsabilidade 123 5.2.6 Análise das variáveis referentes à seção Benchmarking 124 6 Modelo de Escritório de Gerenciamento de Projetos (PMO) proposto ... 130
7 Considerações Finais ... 137
8 Sugestões ... 141
Referências Bibliográficas ... 143
Anexo I... 150
LISTA DE TABELAS
Tabela 1. Descrição do papel do Gerente de Projeto ... 34
Tabela 2. Grid de maturidade gerencial de Crosby ... 40
Tabela 3. Modelo de Maturidade da Capacidade de Gerenciamento de Software ... 41
Tabela 4. Modelo de Maturidade em Gerenciamento de Projeto – Fincher & Levin ... 42
Tabela 5. Níveis de maturidade do modelo (PM)2de Kwak & Ibbs ... 44
Tabela 6. Níveis de maturidade de Kerzner ... 45
Tabela 7. Resumo da evolução dos modelos de maturidade. ... 51
Tabela 8. Características dos modelos de maturidade apresentados ... 52
Tabela 9. Formas e responsabilidades dos PMOs ... 58
Tabela 10. A Petrobras em números – dados referentes ao ano de 2004 ... 82
LISTA DE FIGURAS
Figura 1. Exemplo genérico de um ciclo de vida ... 14
Figura 2. Distribuição de custos e recursos ao longo de um projeto ... 14
Figura 3. Quatro categorias de projeto ... 16
Figura 4. Interligação entre os processos de gerenciamento de projeto ... 18
Figura 5. “Sucesso deve ser um cubo em vez de um ponto” ... 22
Figura 6. Exemplo de estrutura funcional ... 26
Figura 7. Exemplo de estrutura projetizada ... 28
Figura 8. Exemplo de estrutura matricial ... 30
Figura 9. Associação entre as três dimensões de competência ... 37
Figura 10. Componentes para o sucesso de um projeto ... 38
Figura 11. Níveis de maturidade e suas interações ... 46
Figura 12. Ciclo do OPM3 ... 50
Figura 13. Organograma da Petrobras ... 79
Figura 14. Cadeia de Valor da TI em 2001 ... 85
Figura 15. Matriz de Posicionamento Estratégico da TI ... 87
Figura 16. Estrutura Organizacional do Quadrante de Excelência ... 89
Figura 17. Estrutura Organizacional do Quadrante de Gestão ... 90
Figura 18. Estrutura Organizacional do Quadrante de Agilidade ... 92
Figura 19. Estrutura Organizacional do Quadrante de Serviços ... 93
Figura 20. Gráfico de distribuição de freqüências das respostas ... 105
Figura 21. Gráfico de distribuição das respostas da questão 1 ... 106
Figura 23. Gráfico de distribuição das respostas da questão 3 ... 108
Figura 24. Gráfico de distribuição das respostas da questão 4 ... 109
Figura 25. Gráfico de distribuição das respostas da questão 5a ... 110
Figura 26. Gráfico de distribuição das respostas da questão 5b ... 111
Figura 27. Gráfico de distribuição das respostas da questão 5c ... 113
Figura 28. Gráfico de distribuição das respostas da questão 13 respondidas por funcionários ... 114
Figura 29. Gráfico de distribuição das respostas da questão 13 respondidas por contratados ... 114
Figura 30. Gráfico de distribuição das respostas da questão 6 ... 116
Figura 31. Gráfico de distribuição das respostas da questão 7 ... 117
Figura 32. Gráfico de distribuição das respostas da questão 8 ... 118
Figura 33. Gráfico de distribuição das respostas da questão 9 ... 119
Figura 34. Gráfico de distribuição das respostas da questão 10 ... 120
Figura 35. Gráfico de distribuição das respostas da questão 11 ... 121
Figura 36. Gráfico de distribuição das respostas da questão 12 ... 122
Figura 37. Gráfico de distribuição das respostas da questão 14 ... 123
LISTA DE ABREVIATURAS
ANP Agência Nacional de Petróleo
BDEMQ Banco de Dados de Equipamentos e Movimentação e Qualidade BR Distribuidora Petrobras Distribuidora S.A
CENPES Centro de Pesquisa e Desenvolvimento
CEO Chief Executive Office
CFO Chief Financial Office
CMM Capability Maturity Model
CobiT Control Objectives for Information and related Tecnologies
CPO Chief Project Office
E&P Exploração e Produção
EAP Escritório de Apoio de Projeto
EGP Escritório de Gestão de Projeto
ERP Enterprise Resource Planning
GID Gestão Integrada de Demandas
OPEP Organização dos Países Exportadores de Petróleo
OPM3 Organization Project Management Maturity Model
OTC Offshore Tecnology Conference
NTI Necessidades de Tecnologia da Informação
PETROBRAS Petróleo Brasileiro S.A
(PM)2 Project Management Process Maturity Model
PMBoK Project Management Body of Knowledge
PMI Project Management Institute
PMCD Project Manager Competency Development
PMCOE Project Management Center of Excellence
PMO Project Management Office
PMP Project Management Professional
PrgMO Program Management Office
PSO Project Support Office
REDUC Refinaria Duque de Caxias
RPBC Refinaria Presidente Bernardes
SEI Software Engineering Institute
SEORG Serviço de Organização e Métodos
SEPROD Serviço de Processamento de Dados
SERINF Serviço de Informática
SOX Sarbanes-Oxley
TI Tecnologia da Informação
TI-AB Tecnologia da Informação Abastecimento
TI-E&P Tecnologia da Informação da Exploração e Produção TI-G&E Tecnologia da Informação Gás e Energia
TI-INTER Tecnologia da Informação Internacional TRANSPETRO Petrobras Transporte S.A.
UN-BC Unidade de Negócios Bacia de Campos
1 Introdução
1.1 Contextualização do problema
Em um ambiente de contínuas mudanças, as empresas, para permanecerem competitivas,
precisam responder rapidamente aos novos desafios e novas oportunidades que surgem.
Podemos dizer que projetos são o veículo por meio ao qual as empresas realizam mudanças
em seus processos, produtos ou serviços. Devido ao ritmo crescente de mudanças, cada vez
mais novos produtos e serviços são implementados pelas empresas por meio de projetos.
Neste contexto, a gestão de projetos passa a ser fundamental. As empresas precisam inovar
constantemente para continuarem a serem competitivas e estas inovações são realizadas por
meio de um ou vários projetos. Para Thiry-Cherques (2002), projetos são criados para
atender estrategicamente a um desafio. Segundo Verzuh (2000) quanto maior a mudança,
mais inovações ocorrem em resposta e mais projetos surgem.
A gerência de projetos é utilizada cada vez mais nas empresas como uma ferramenta de
auxílio à gestão e ao planejamento estratégico. Segundo Kerzner (2001b), nos últimos anos,
devido a uma demanda crescente por projetos, houve um aumento no interesse de
formalização dos processos de gerência de projetos. O rápido crescimento do quadro de
associações de membros de profissionais na área demonstra isso. O Project Management
Institute (PMI) estabeleceu-se como um instituto de referência na área. Criado em 1969,
por apenas 5 membros, atualmente conta com mais de 100.000 filiados em 125 países.
Segundo Patah (2004), o Standard Group (1999 apud Patah 2004) publicou uma pesquisa
segundo a qual, os Estados Unidos gastam US$ 275 bilhões ao ano em aproximadamente
200.000 projetos de tecnologia da informação. Este mesmo instituto publicou uma outra
pesquisa em 2003, a partir de uma amostra de aproximadamente 13.000 projetos de
tecnologia da informação em que apenas 34% dos projetos puderam ser considerados
bem-sucedidos. De acordo com os dados da pesquisa, 82% dos projetos foram completados fora
do prazo sendo que somente 52% destes foram entregues conforme as características e
funcionalidades requeridas. Apesar desta pesquisa ter sido realizada nos Estados Unidos, a
realidade brasileira não é muito diferente. O Estudo de Benchmarking em Gerenciamento
de Projetos realizado em 2004 pelo PMI – Seção Rio de Janeiro identificou que apesar do
interesse em gerenciamento de projetos nas organizações brasileiras ser cada vez maior, o
nível de maturidade em gerenciamento de projetos das mesmas ainda é baixo. Em outras
palavras, apesar das empresas utilizarem cada vez mais a gerência de projetos, o nível de
maturidade das mesmas em gerenciamento de projetos ainda deixa muito a desejar.
1.2 Formulação do problema
Em 1997, a Petrobras, empresa de economia mista com atuação na indústria de exploração
e produção, refino e comercialização de petróleo e derivados, e na distribuição de
combustíveis, passou a atuar em um novo cenário de competição instituído pela lei 9.478,
que regulamentou a emenda constitucional da flexibilização do monopólio estatal de
petróleo. Com a quebra do monopólio, a empresa viu-se diante de um novo cenário
competitivo com a entrada de novos concorrentes em suas áreas de atuação. A necessidade
condições de competição no exterior exigiu da Petrobras uma nova postura. Em resposta a
esta nova realidade, a empresa passou por um rigoroso processo de planejamento
estratégico, com a revisão de seus objetivos e missão, acompanhado de um amplo processo
de reestruturação. Esta reestruturação introduziu na Companhia o conceito de unidades de
negócio, autônomas, com orçamento e estratégias próprias alinhadas à estratégia
corporativa, voltadas para as áreas de atuação (Exploração e Produção (E&P),
Abastecimento, Gás e Energia e Internacional).
A área de Tecnologia da Informação (TI) da Petrobras, em conformidade com a revisão da
estratégia da Companhia, iniciou um trabalho de alinhamento da tecnologia da informação
da Petrobras às novas tendências da indústria, estabelecendo estruturas e mecanismos
necessários para maximizar a contribuição da informática aos objetivos de negócios da
Companhia. Este processo ocasionou na mudança de sua estrutura, processos e serviços.
Com a reestruturação, a TI passou de uma atuação mais operacional para uma atuação mais
estratégica, responsável por prover soluções que apóiem os processos de negócio
estratégicos da empresa. A TI teve um aumento de sua área de atuação ao centralizar todas
as atividades de tecnologia da informação da Petrobras. Devido à estrutura atual da TI, a
maior parte dos projetos é desenvolvida com a participação de mais de uma área funcional
e com a participação de fornecedores externos. A falta de padronização neste ambiente
dificulta a realização dos projetos pelas áreas. Somado a isso a falta de critérios de
priorização do que deve ser realizado e a falta de alinhamento dos projetos com objetivos
estratégicos da organização levam a utilização ineficiente dos recursos e afetando, por
A solução proposta ao longo deste trabalho para os problemas citados anteriormente é
adoção de uma gestão de projetos padronizada segundo os conceitos do PMI. Este trabalho
tem como objetivo identificar a forma adequada de implantar os conceitos de gerência de
projetos na organização.
Segundo autores como Block et al (1998) e Crawford (1999), a criação de uma estrutura
organizacional de projetos, também conhecida por Escritório de Gerenciamento de Projetos
ou Escritório de Projetos, com o objetivo de disseminar os conceitos de gerência de
projetos em uma organização, pode ajudar a alcançar mais rapidamente a situação desejada.
Segundo Patah et al (2003 apud Patah 2004), o Escritório de Gerenciamento de Projetos
pode se apresentar sobre diferentes formas: desde uma simples estrutura criada somente
para dar suporte administrativo aos projetos da organização até uma estrutura estratégica
responsável pelo gerenciamento de todos os projetos da organização. Os autores enfatizam
que o dimensionamento da estrutura deve estar alinhado à estratégia da organização,
levando-se em conta a relevância da atividade de gerenciamento de projeto para a mesma e
seu nível de maturidade em gerenciamento de projetos, de modo que a estrutura não se
torne onerosa e não apresente os resultados desejados. Segundo Herszon (2004), entende-se
por grau de maturidade em gerenciamento de projetos de uma organização como o nível em
que a mesma se encontra em uma escala crescente a partir de um modelo de maturidade
1.3 Objetivos
1.3.1 Objetivo principal
Identificar qual a estrutura de Escritório de Gerenciamento de Projetos é mais
adequada para a TI a partir da análise do nível atual de maturidade em gerenciamento de
projetos.
1.3.2 Objetivos secundários
Para a realização deste trabalho, torna-se necessário realizar:
• A identificação dos principais modelos de maturidade em gerenciamento de projetos
existentes na literatura;
• A identificação das principais estruturas de Escritório de Gerenciamento de
Projetos;
• A análise do nível atual de maturidade em gerenciamento de projetos da área a ser
pesquisada;
• A identificação da situação desejada;
• A identificação da estrutura de Escritório Gerenciamento de Projeto mais adequada
para o nível atual de maturidade em gerenciamento de projetos.
1.4 Delimitação do estudo
O estudo proposto identificará a estrutura de Escritório de Gerenciamento de Projetos mais
adequada a partir da análise do nível de maturidade em gerenciamento de projetos da TI.
Esta análise será efetuada a partir da percepção dos gerentes de projetos. Na TI, este
profissional é nomeado como líder de projeto podendo desempenhar esta função tanto
funcionários do sistema Petrobras quanto contratados, pessoas empregadas de empresas
terceirizadas, mas que trabalham diretamente na TI. Para não se criar um viés na análise a
ser realizada, o estudo será desenvolvido com as pessoas que trabalham diretamente com
gerenciamento de projetos, excluindo-se aquelas que possuam cargo ou função de gerência
ou direção.
1.5 Relevância do estudo
A gestão de projetos não é uma atividade recente. Empresas sempre utilizaram projetos
para implementar suas estratégias e desenvolver seus produtos e serviços. Mas os projetos
nem sempre são gerenciados de forma ordenada, acarretando em baixas taxas de sucesso
dos mesmos. Quando falamos em sucesso no resultado final de um projeto, estamos nos
referindo não só a serem entregues no prazo e com o custo planejado como também a
Em pesquisa realizada em 1999, o Gartner Group (1999 apud Herszon 2004) observou que
os projetos de desenvolvimento de software de TI, da forma como eram gerenciados,
apresentavam orçamento final de 170-180% superior ao orçamento planejado. Ainda
segundo Herszon (2004), outra pesquisa realizada pela Robbins-Giola com gerentes de
projetos identificou que 90% destes gerentes estimaram erradamente o tamanho e a
complexidade de seus projetos. Quase metade dos projetos (44%) teve um estouro de
orçamento da ordem de 10 a 40% e somente 16% destes foram entregues no cronograma
planejado. O baixo conhecimento dos conceitos de gerenciamento de projetos e a não
utilização de técnicas e metodologias adequadas contribuem para estes resultados.
Cada vez mais as empresas notam que é necessário ter uma gestão adequada de seus
projetos com o objetivo de aumentar a taxa de sucesso dos mesmos, pois as mudanças no
ambiente onde as empresas se inserem vem ocorrendo de forma cada vez mais rápida e
descontinuada, gerando uma crescente demanda por novos produtos e serviços.
As adaptações às mudanças no ambiente em que as empresas inserem podem ser realizadas
através do processo de planejamento estratégico. Kerzner (2001b) define planejamento
estratégico como o processo de formular e executar decisões acerca da futura direção da
organização. Este processo é fundamental para a sobrevivência da organização pois permite
que se tenha uma visão de alcance a longo prazo dos resultados requeridos. O planejamento
estratégico se divide no processo de definição e formulação das estratégias e no processo de
execução das mesmas. No processo de definição são decididos os resultados que devem ser
alcançados e as estratégias para obter os resultados pretendidos. No processo de execução,
estes possuem maiores chances de serem bem-sucedidos se forem executados por um
processo repetível e consistente.
Por estes motivos, nos últimos anos, houve um crescimento do interesse de formalização
dos processos de gerência de projetos e disseminação de seus conceitos.
A criação de uma estrutura organizacional voltada para a aplicação dos conceitos de
gerenciamento de projetos e para o desenvolvimento de processos e metodologias, vem ao
encontro deste anseio. Esta estrutura organizacional seria o Escritório de Projetos ou o
Escritório de Gerenciamento de Projetos. Ao implantar uma estrutura organizacional com
estas características, a empresa passa a centralizar todas as suas iniciativas de aplicação dos
conceitos de gerenciamento de projetos, facilitando sua disseminação pela organização. O
Escritório de Gerenciamento de Projetos passa a ser a estrutura responsável pela
metodologia de gerenciamento de projetos, podendo ajudar no desenvolvimento das
competências e habilidades dos gerentes de projetos, pessoas responsáveis por gerenciar
efetivamente os projetos da organização.
Uma premissa na criação desta estrutura e definição de suas atribuições é que a mesma seja
adequada à estratégia da organização e ao seu grau de conhecimento dos conceitos de
gerenciamento de projetos. Analisar o nível de maturidade de gerenciamento de projetos da
organização em relação a uma escala crescente é o passo inicial para se implantar uma
estrutura de gerenciamento de projetos. A vantagem da utilização de um modelo de níveis
de maturidade é que se pode identificar a situação atual da empresa em relação aos
conceitos de gerenciamento de projetos e a partir desta identificação planejar o alcance da
situação desejada. O alcance da situação desejada pode ser realizado de maneira gradual,
isso aumentando as taxas de sucesso dos projetos. À medida que a organização for
aperfeiçoando seu nível de maturidade, podem-se evoluir as atribuições do Escritório de
Gerenciamento de Projetos desde uma atribuição mais operacional, como responsável pelas
técnicas e metodologias, até uma atribuição mais estratégica, como responsável por todos
os projetos da organização. Independente das atribuições definidas para Escritório de
Gerenciamento de Projetos, o mesmo deve estar sempre alinhado a estratégia da
organização.
Desta forma a realização deste estudo visa aplicar um modelo que meça o nível de
maturidade em gerenciamento de projetos de uma organização e sugerir uma estrutura
organizacional de projetos adequada ao nível identificado podendo ser evoluída à medida
que o grau de maturidade da mesma for sendo aperfeiçoado.
1.6 Organização do trabalho
Este primeiro capítulo introduz o tema de gerenciamento de projetos, a formulação do
problema, os objetivos primários e secundários, a relevância e a estrutura do trabalho.
O capitulo dois apresenta a revisão da literatura em gerenciamento de projetos incluindo as
definições de conceitos relevantes, o perfil das competências em gerência de projetos, os
tipos de estrutura organizacionais existentes para gerenciamento de projetos, os modelos de
maturidade propostos pela literatura e o conceito de escritório de gerenciamento de projetos
e seu processo de implantação. Este trabalho apresenta os conceitos de gerenciamento de
uma pesquisa empírica do nível de maturidade em gerenciamento de projetos da área de
Tecnologia da Informação da Petrobras.
O capítulo três apresenta a abordagem metodológica utilizada adotada na realização da
dissertação que se constitui de um estudo de caso único onde os dados foram obtidos por
meio da aplicação de questionários, pesquisa documental e observação direta. Em seguida,
a pesquisa de campo realizada é apresentada e são descritas a forma de realização da
pesquisa, a montagem da estrutura e a distribuição dos questionários.
O capítulo quatro apresenta o caso estudado. O capítulo se inicia com a descrição da
empresa Petrobras, apresentando a área de Tecnologia da Informação (TI) e como esta se
insere no contexto da empresa. Ao final são apresentados a estrutura da TI e os fatores
internos e externos que nos mostram a necessidade da adoção de uma gestão de projetos
padronizada.
O capítulo cinco apresenta os resultados da pesquisa empírica. São apresentados e
interpretados os resultados obtidos e ao final com base no modelo utilizado como referência
é analisado o nível atual de gerenciamento de projetos da TI.
No capítulo seis é proposto o modelo de Escritório de Gerenciamento de Projetos mais
adequado para TI a partir da identificação do nível atual de gerenciamento de projetos..
No capítulo sete são apresentadas as considerações finais do trabalho e no capítulo oito são
2 Referencial Teórico
Este capítulo apresenta as principais características de um projeto, discute o conceito de
sucesso e fracasso de um projeto, apresenta o conceito de estruturas funcionais, matriciais e
projetizadas realizando uma comparação entre as mesmas, expõe as competências
requeridas por um gerente de projetos, mostra os principais modelos de maturidade em
gerência de projetos vigentes, discutindo suas origens e efetuando um comparativo entre os
pontos convergentes e divergentes dos modelos e ao final apresenta as principais estruturas
de escritório de gerenciamento de projetos indicadas na literatura.
2.1 Gestão de Projeto
Quando falamos em projeto e gestão de projeto não estamos falando em algo recém-criado.
A origem da gestão de projetos é bastante remota. Segundo Verzuh (2000), certamente, a
construção das pirâmides e dos aquedutos da antiguidade necessitaram da habilidade de
coordenação e planejamento de um gerente de projeto. Michelângelo na construção da
Basílica de São Pedro enfrentou todos os problemas enfrentados atualmente por um gerente
de projeto: especificações incompletas, mão-de-obra insuficiente, estouro de orçamento e
uma pressão constante de um cliente bastante influente. Thiry-Cherques (2002) afirma que
existem relatos sobre projetos realizados há pelo menos 6000 anos na Mesopotâmia.
Somente a partir da 2a Guerra Mundial a disciplina de gestão de projetos, como a
conhecemos atualmente, passou a ser difundida principalmente nos programas de defesa
militar americanos. Segundo Verzuh (2000), o projeto Manhattan, para construção da
modernas técnicas de gestão de projetos. Para o autor, apenas recentemente a gestão de
projetos ultrapassou os limites tradicionais dos grandes projetos de construção civil e da
indústria aeroespacial. Atualmente a disciplina encontra-se presente em todas as áreas,
desde planos de saúde às indústrias, dos projetos de software a projetos de recursos
ambientais.
O que pode ser definido como projeto? Existem várias definições para projeto. Seu conceito
vem sendo aprimorado ao longo dos anos. Uma das primeiras definições foi apresentada
por Davis (1951 apud Cleland & Ireland 2002). O autor define projeto como: “qualquer
empreendimento que tenha objetivos claros e definidos que representem valores específicos
a serem usados para satisfazer alguma necessidade ou desejo”. Kerzner (2001a) já
apresenta uma definição mais apurada. Segundo ele, um projeto é considerado como uma
série de atividades ou tarefas multifuncionais, possuindo um objetivo específico a ser
completado, dentro de um tempo definido, com prazos e recursos limitados. Para
Thiry-Cheques (2002), um projeto é definido como sendo uma organização transitória, que
compreende uma seqüência de atividades dirigidas à geração de um produto ou serviço
único em um tempo dado.
Por sua vez, o Project Management Institute, PMI (2004b), define um projeto como sendo
um esforço temporário empreendido para criar um produto ou serviço único e o
gerenciamento de projetos pode ser definido como a arte de coordenar as atividades com o
objetivo de atingir as expectativas dos clientes. Similarmente, a norma ISO 10006 (2000)
define um projeto como sendo “um processo único, consistindo de um grupo de atividades
coordenadas e controladas com datas de início e término, empreendido para um objetivo
notar que todas estas definições são similares e que um projeto possui três características
essenciais: possui um objetivo, produz um resultado único e contém início e fim
estabelecidos.
Como um projeto consiste em um grupo de atividades coordenadas, que para atingirem os
objetivos definidos ocorrem em uma ordem determinada, podemos dizer que as atividades
de um projeto estão compreendidas em um ciclo de vida, que pode ser dividido em diversas
fases. Maximiano (1997) divide o ciclo de vida de um projeto em quatro fases: preparação,
estruturação, desenvolvimento e encerramento. Cleland & Ireland (2002), por sua vez,
dividem o ciclo de vida de um projeto em cinco fases: conceituação, definição, produção ou
construção, operacional e desinvestimento.
O PMI em seu documento de referência para gerência de projeto, The Guide of Project
Management Body of Knowledge (o Guia PMBoK), não indica uma nomenclatura
específica para as diversas fases de um ciclo de vida. Segundo este guia (2004b), as
peculiaridades de cada projeto é que irão determinar as melhores escolhas para a divisão. A
Figura 1. Exemplo genérico de um ciclo de vida
Fonte: PMI (2004b:39)
Segundo o PMBoK (2004b), independentemente do número de fases de um ciclo de vida de
um projeto, durante o mesmo, seus custos e recursos não são uniformemente distribuídos.
A Figura 2 apresenta como os custos e recursos de um projeto são distribuídos durante a
ocorrência deste.
Figura 2. Distribuição de custos e recursos ao longo de um projeto.
Fonte: PMI (2004b: 36)
Podemos ver que no início do ciclo, os custos e a quantidade de pessoas envolvidas são
bastante baixos, mas o nível de risco e de incerteza é bastante alto, pois o risco do projeto
não atingir os objetivos especificados é maior neste período. Nesta fase a capacidade das
partes interessadas de interferir nas características requeridas ainda é bastante alta. À
medida que o projeto vai sendo desenvolvido, aumenta-se o número de pessoas envolvidas
e os custos, devendo-se reduzir as incertezas e as mudanças nos requisitos especificados.
Ao final do projeto, os custos e a quantidade de pessoas envolvidas se reduzem
drasticamente. (PMI, 2004b)
Segundo Patah (2004), a incerteza e complexidade inerentes aos projetos também são
questões fundamentais para se entender o conceito. Para Maximiano (1997), os projetos
desenvolvem-se naturalmente em um ambiente de complexidade e incerteza. Segundo o
autor, os projetos podem ser divididos em quatro grandes categorias segundo a incerteza e
complexidade. Quanto maior o grau de desconhecimento, maior a incerteza e o risco
associado. A complexidade de um projeto pode ser avaliada, entre outros aspectos, através
da multidisciplinaridade necessária a execução do mesmo, diversidade e volume das
informações e número de organizações envolvidas. A Figura 3 apresenta as quatro grandes
Figura 3. Quatro categorias de projeto
Fonte: Maximiano (1997:27)
Face ao apresentado, podemos notar que existem vários fatores como custos, recursos,
prazos e riscos que devem ser analisados ao se realizar um projeto.
O Guia PMBoK compreende os elementos da gerência de projetos. Ele é estruturado por
áreas de conhecimento, mas possui uma orientação por processos. Segundo o PMBoK
(2004b), o gerenciamento de projetos significa aplicação do conhecimento, habilidades,
ferramentas e técnicas às atividades do projeto a fim de atender ou superar as expectativas
que os stakeholders1possuem no projeto e é realizado através da aplicação e integração dos
seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução,
1 Stakeholders: todos os agentes que contribuem para o desempenho da organização; por exemplo:
monitoramento e controle, e encerramento. No processo de iniciação é estabelecida a base
do projeto, com a definição dos recursos, stakeholders e é obtido o compromisso dos
envolvidos para o desenvolvimento do projeto. No processo de planejamento é
desenvolvido um plano com o objetivo de orientar a execução, o controle e o encerramento
do projeto. Este plano é composto de atividades interligadas tendo como ênfase o
cumprimento das metas acordadas. O processo de execução compreende a execução das
atividades descritas no plano, coordenando os recursos do projeto, humanos e materiais,
necessários para o cumprimento das tarefas. O processo de monitoramento e controle
compreende o acompanhamento do desempenho das atividades do projeto com o objetivo
de medir se o que está sendo realizado está de acordo ao que foi planejado e o
cumprimento, se necessário, de ações corretivas para adequação da realização ao
planejamento. Por fim, o processo de encerramento compreende as atividades de
encerramento do projeto com a conclusão formal do mesmo mediante a aceitação do
Figura 4. Interligação entre os processos de gerenciamento de projeto
Fonte: PMBoK (2004b:56)
O Guia PMBoK está dividido em nove áreas de conhecimento, são elas: integração,
escopo, tempo, custo, qualidade, recursos humanos, comunicações, riscos e aquisições.
(PMI, 2004b)
A gerência de integração descreve os processos que asseguram a coordenação dos diversos
elementos de gerenciamento de projetos de modo que as áreas estejam integradas de forma
única.
A gerência de escopo deverá assegurar que apenas o trabalho necessário para desenvolver
os requisitos especificados pelo cliente esteja sendo executado, impedindo a realização de
Para que um projeto seja finalizado dentro do prazo e custo previsto, devem ser realizadas
respectivamente, as gerências de tempo e custo. Estas duas gerências estão intimamente
relacionadas com a gerência de escopo, pois uma alteração em um requisito, provavelmente
acarretará a alteração no prazo, podendo impactar em maiores custos para o projeto.
A gerência de qualidade deve garantir que as necessidades que originaram o
desenvolvimento do projeto sejam completamente satisfeitas. Em outras palavras, a
gerência de qualidade deve garantir que o resultado produzido pelo projeto atenda
satisfatoriamente ao cliente.
A gerência de recursos humanos deve assegurar o aproveitamento dos participantes da
equipe do projeto de maneira mais eficaz, ressaltando suas habilidades e competências.
Segundo Thiry-Cherques (2002), a gerência de comunicações é responsável por promover
os meios necessários à interação entre as pessoas e instituições envolvidas no projeto. Ela
compreende a coleta, armazenamento e disponibilização de forma adequada das
informações e idéias.
O PMBoK (2004b) define risco como sendo como um evento ou condição incerta que se
ocorrer pode proporcionar um resultado positivo ou negativo em pelo menos um dos
objetivos do projeto. Devido a isso, a gerência de riscos é de fundamental importância,
A gerência de aquisições deve realizar a aquisição de serviços, produtos ou resultados de
organizações externas àquela que desenvolve o projeto. Segundo o PMBoK (2004b), esta
gerência deve garantir que todos os fornecedores de produtos, serviços ou resultados façam
suas entregas dentro do prazo e condições estipuladas contratualmente.
Deve se ressaltar que para o PMI, o guia PMBoK é um documento de referência que
identifica um conjunto de conhecimento em gerenciamento de projetos. Ele tem como
objetivo padronizar termos e procedimentos para que os gerentes de projetos possam ser
orientar nas práticas mais comuns, porém segundo o guia, somente a equipe de projeto é
responsável por determinar o que é adequado a um projeto específico.
Após definirmos o que é um projeto, o item a seguir apresenta como se define o sucesso ou
o fracasso de um projeto e os fatores que contribuem para que um projeto seja considerado
ou não bem-sucedido.
2.2 Sucesso e Fracasso em Projetos
Segundo Cleland & Ireland (2002), a dificuldade em se definir sucesso ou fracasso vem da
própria dificuldade em se definir o significado dessas palavras. Para os autores, no contexto
de projetos, o sucesso de um projeto ocorre quando a entrega do mesmo acontece no prazo
certo, dentro do orçamento previsto e adequado estratégica ou operacionalmente à missão,
aos objetivos e metas da organização. O fracasso acontece quando ocorre a situação
inversa, ou seja, os resultados esperados não são alcançados. Patah (2004), similarmente,
mesmo, com os recursos orçamentários e o tempo destinados conforme o plano elaborado
para o projeto. Para o autor, um projeto pode ser considerado como um fracasso quando
não foi possível cumprir o que foi planejado e acordado. Em outras palavras, quando não
foi possível atender as necessidades dos stakeholders explicitadas nos objetivos do projeto.
Kerzner (2001a) e Pinto & Slevin (1998) destacam que as definições iniciais de sucesso no
contexto de gerência de projetos eram voltadas para atender aos requisitos internos de
prazo, custo e qualidade, chamada pelos autores de tripla restrição. Não havia preocupação
com a satisfação do cliente, o principal afetado pelos resultados produzidos pelo projeto.
Com o aumento da competitividade do mercado, o consumidor tornou-se mais exigente.
Consequentemente a satisfação do cliente passou a ser um dos pilares fundamentais, a
quarta restrição, para a identificação do sucesso ou fracasso de um projeto, levando a
definição de sucesso existente atualmente.
Para Kerzner (2001a), o sucesso de um projeto não pode ser definido como um ponto. Ou
em outras palavras, um projeto não pode ser considerado como um sucesso somente quando
ele atender completamente as expectativas de todas as partes integrantes, no prazo e custo
estabelecido e com a qualidade esperada. Poucos projetos são completados sem alterações
no seu escopo e consequentemente sem mudanças de expectativas. O autor defende que o
sucesso de um projeto deve ser definido como um cubo, podendo ser considerado como um
sucesso se conseguir atender a uma grande parte das expectativas das partes interessadas. A
Figura 5. “Sucesso deve ser um cubo em vez de um ponto”
Fonte: Kerzner (2001a:63)
Do mesmo modo, o PMI (2002) observa que o sucesso ou fracasso de um projeto pode ser
percebido de maneiras distintas pelas diversas partes integrantes do projeto e que apesar da
percepção poder variar, esta depende fortemente do grau de alcance dos objetivos
esperados. Por exemplo, pode existir um projeto que apesar de ter ultrapassado os prazos e
custos estabelecidos, ainda assim ser considerado um sucesso pelo cliente, pois produziu os
resultados esperados. Existem alguns fatores que podem evidenciar e outros que podem
contribuir para o sucesso ou fracasso de um projeto. Alguns fatores como o cumprimento
do trabalho de acordo com o prazo e orçamento previsto, cumprimento do resultado global
e atendimento das expectativas dos stakeholders evidenciam o sucesso de um projeto.
Outros fatores como planejamento detalhado de todas as fases do projeto e um
Qualidade ou escopo
Custo
acompanhamento e controle adequado dos recursos destinados ao mesmo contribuem para
o sucesso do mesmo. Por sua vez, fatores como não adequação à missão ou objetivos da
empresa ou não atendimento das necessidades explicitadas evidenciam o fracasso de um
projeto. Cleland & Ireland (2002) ressaltam que para se determinar o sucesso ou fracasso,
algumas medidas de desempenho, como por exemplo comparações entre os custos
planejados e reais de todas as atividades completadas, devem ser realizadas durante o
desenvolvimento do projeto para que possa haver uma comparação com o resultado
previsto.
Pinto & Slevin (1998) partiram do pressuposto de que o sucesso de um projeto depende do
atendimento as quatro restrições citadas acima e estabeleceram um modelo de dez fatores
críticos de sucesso, são eles:
1. Objetivos do projeto claramente definidos e compreendidos tanto pela equipe do
projeto quanto pela organização onde o projeto será realizado;
2. Suporte da gerência executiva;
3. Planejamento detalhado do projeto;
4. Participação do cliente no projeto;
5. Equipe do projeto com as habilidades e competências necessárias. Responsabilidade
e papéis bem definidos;
6. Assegurar que a equipe do projeto tenha a tecnologia necessária para realizar suas
atividades;
7. Aprovação dos resultados do projeto pelo cliente;
9. Comunicação adequada entre as partes integrantes do projeto: equipe do projeto,
clientes e organização;
10. Diagnosticar e corrigir problemas que possam vir a ocorrer no decorrer do projeto;
Segundo Kerzner (2002), apesar de alguns fatores críticos de sucesso serem genéricos, as
empresas devem definir seus próprios fatores críticos de sucesso. Em outras palavras, cada
empresa deve possuir sua própria definição de sucesso que deve estar relacionada ao seu
ambiente de negócio.
Para Patah (2004), uma forma de diminuir as chances de fracasso de um projeto é verificar,
tão logo comece a ocorrer, a impossibilidade de atender às necessidades explicitadas no
início do projeto. Verificar somente ao final do projeto pode ser muito tarde, aumentando a
chance de fracasso do mesmo. Similarmente, Kerzner (2001a) destaca que um fracasso
pode se tornar um sucesso se for descoberto cedo o bastante, de modo que os recursos
designados para o projeto possam ser redistribuídos para outras atividades mais oportunas.
2.3 Tipos de estruturas organizacionais
Kerzner (2001a) define organização ou estrutura organizacional como sendo um grupo de
pessoas que precisam coordenar suas atividades de modo que possam atender aos objetivos
da organização. Segundo o autor, as rápidas mudanças que vêm ocorrendo no ambiente
como aumento da competitividade, avanços tecnológicos e uma exigência de um maior
controle de recursos produziu, nos últimos trinta anos, uma revolução na introdução e
apresenta o conceito de organizações como sistemas abertos, ou seja, sujeitas às influências
do ambiente onde estão inseridas. Por estes motivos surgiu a necessidade das empresas de
possuírem uma organização mais flexível, mais dinâmica que possa responder rapidamente
as mudanças ocorridas no ambiente.
Segundo Patah (2004), as estruturas matriciais e projetizadas surgiram como alternativas a
rígida estrutura organizacional funcional A estrutura matricial é uma combinação da
estrutura funcional e projetizada e pode ser classificada em matricial fraca, equilibrada ou
forte.
Kerzner (2001a) destaca que não existe um tipo ideal de estrutura organizacional, existem
sim, estruturas apropriadas e não-apropriadas. Ou, em outras palavras, as estruturas devem
ser apropriadas aos objetivos da organização.
2.3.1 Estrutura funcional
As estruturas funcionais existem há mais de dois séculos. Neste tipo de estrutura, as
pessoas são agrupadas em funções ou processos de trabalho similares sendo a autoridade
exercida principalmente pelos gerentes funcionais. Daft (1999) ressalta que são aplicáveis
em ambiente estáveis com baixa incerteza, sendo suas atividades rotineiras e com baixa
interdependência. Nos últimos anos devido as constantes alterações ambientais, estas
passaram a ser questionadas principalmente devido à dificuldade em responder rapidamente
departamentos técnicos da empresa. A figura 6 apresenta um exemplo de estrutura
funcional.
Figura 6. Exemplo de estrutura funcional
Fonte: adaptado de Kerzner (2001a)
As principais vantagens desta estrutura no contexto de gerenciamento de projetos são o
controle centralizado de orçamento e custo e grande flexibilidade e disponibilidade no uso
de recursos humanos necessários ao projeto. Como o projeto é desenvolvido dentro de um
departamento técnico da empresa, tendo o gerente funcional do departamento responsável
pelo mesmo, os funcionários participantes da equipe do projeto são lotados no próprio
departamento, reportando-se com isso a somente uma pessoa. Por um outro lado, existe
uma dificuldade de responsabilização pelo resultado do projeto, pois apesar do gerente
funcional ser o responsável pelo mesmo, esta não é sua única função tendo com isso
dificuldade de acompanhar todas as atividades do projeto. Não é delegada a nenhum
funcionário a responsabilidade total pelo projeto. Uma outra desvantagem é que os
as decisões técnicas. Com isso existe uma dificuldade em responder rapidamente às
necessidades do cliente. Por último, apesar dos canais de comunicação serem verticais e
bem estabelecidos, existe uma dificuldade de integração de atividades entre áreas
funcionais distintas pois os gerentes funcionais tendem a ter problemas em ceder seus
recursos tendo que haver uma intervenção dos níveis hierárquicos superiores.
Kerzner (2001a) ressalta que apesar das desvantagens apresentadas, a estrutura funcional
pode funcionar a contento desde que as áreas funcionais se conscientizem em fornecer os
recursos necessários para a execução das atividades e que a pessoa designada como gerente
de projeto possua a autoridade e responsabilidade necessárias para que não hajam conflitos
com os gerentes funcionais das áreas dos recursos solicitados.
2.3.2 Estrutura projetizada
Segundo Patah (2004), nos últimos anos, as empresas, devido as constantes demandas do
mercado consumidor por novos produtos, atentaram para o fato de que a diversificação de
sua linha de produtos era fundamental para sua sobrevivência. Esta diversificação tem
como premissa a integração de tecnologias distintas e um rápido ciclo de desenvolvimento
de produtos desde sua concepção até a entrada no mercado. Neste cenário, surgiu a
necessidade de uma estrutura mais ágil que possibilitasse uma maior integração entre
tecnologias e áreas. Esta estrutura seria a estrutura projetizada.
Segundo Kerzner (2001a), a maior vantagem da estrutura projetizada é que somente um
todo. A principal desvantagem neste tipo de estrutura é que a organização é replicada para
cada projeto podendo haver duplicidade de esforços e dificuldade de comunicação entre
pessoas de projetos distintos, apesar dos canais de comunicação dentro do projeto serem
bastante eficazes possibilitando respostas rápidas a mudanças que possam ocorrer no
decorrer do mesmo. A figura 7 apresenta uma estrutura do tipo projetizada.
Figura 7. Exemplo de estrutura projetizada
Fonte: Patah (2004:53)
Outra vantagem desta estrutura é que ela é estruturalmente mais simples e flexível que a
estrutura funcional podendo ser implantada mais rapidamente. Além disso, todos os
participantes do projeto encontram-se sob a responsabilidade de uma única pessoa: o
gerente de projeto. Como a estrutura é criada para o projeto, existem menos conflitos entre
decisões. Apesar do número de conflito entre as áreas ser menor, existe uma baixa troca de
informações entre as mesmas desperdiçando com isso oportunidades de um maior
intercâmbio técnico. Outra desvantagem é que um especialista, uma pessoa com
conhecimentos específicos, tende a ser alocado em um projeto quando está disponível e não
quando é necessário. Sendo com isso retido no mesmo por um tempo maior que o
necessário.
2.3.3 Estrutura matricial
Segundo Kerzner (2001a), a estrutura matricial é uma tentativa de combinar as vantagens
da estrutura projetizada e da estrutura funcional. Esta estrutura existe em paralelo a
estrutura funcional sob a responsabilidade dos gerentes funcionais. São criadas equipes de
projeto com representantes das diversas áreas funcionais pertinentes sob a responsabilidade
do gerente de projeto. O gerente de projeto tem a total responsabilidade pelo sucesso do
mesmo enquanto que as gerências funcionais são responsáveis por disponibilizar os
recursos, humanos ou técnicos, necessários ao sucesso do projeto. Os membros da equipe
do projeto são lotados nas gerências funcionais e respondem tanto aos seus gerentes
funcionais quanto ao gerente de projeto durante a duração do mesmo.
A estrutura matricial pode se apresentar sob diversas formas. A primeira delas é a estrutura
matricial fraca. Ela é mais parecida com a estrutura funcional e nela os gerentes funcionais
possuem maior poder em comparação com o gerente de projeto. Outro tipo é a estrutura
matricial forte. Este tipo de estrutura se aproxima mais da estrutura projetizada onde o
gerentes funcionais. O terceiro tipo de estrutura é a estrutura matricial equilibrada onde o
gerente de projeto e os gerentes funcionais possuem o mesmo nível de influência sobre os
membros da equipe. A figura 8 apresenta uma estrutura do tipo matricial.
Figura 8. Exemplo de estrutura matricial
Fonte: Patah (2004:56)
Um dos principais problemas que pode existir em uma estrutura matricial é o grande
potencial de ocorrência de conflitos entre o gerente funcional e o gerente de projeto em
relação a disponibilização de recursos. Segundo Kerzner (2001a), neste tipo de estrutura
devem existir métodos eficientes de resolução de conflitos, pois esta pode consumir
bastante tempo da gerência executiva e tanto os gerentes funcionais quanto os gerentes de
projeto devem estar preparados para negociar os recursos necessários a um projeto. Uma
vantagem é que existe um único responsável pelo projeto como um todo, o gerente de
mesmo. Por outro lado, os funcionários participantes de equipes de projeto sentem
dificuldades de se reportarem simultaneamente a vários gerentes.
Kerzner (2001a) observa que os principais executivos de uma empresa normalmente temem
implantar uma estrutura matricial por acharem que esta acarretará em mudanças radicais na
estrutura organizacional da empresa. Segundo o autor, este temor não tem fundamento pois
a estrutura matricial nada mais é do que uma superposição horizontal sobre a estrutura
tradicional. Em outras palavras, a estrutura matricial nada mais é do que uma estrutura
temporária que é criada no início do projeto e extinta ao término do mesmo. Por ser flexível
pode ser implantada rapidamente. Ao contrário da estrutura tradicional que é uma estrutura
permanente.
Após serem explicados os principais tipos de estruturas organizacionais existentes no
contexto de gerenciamento de projetos, o item a seguir apresenta a definição de gerente de
projeto, suas principais atribuições e competências.
2.4 Competências em gerenciamento de projetos
2.4.1 O Gerente de Projeto
Gaddis (1959) foi um dos primeiros autores a utilizar o termo gerente de projeto. Apesar de
se referir somente a gerência de projetos de tecnologia avançada para a época, como
projetos de eletrônica e aeronáuticos, o autor apresenta o gerente de projeto como sendo um
profissional responsável por lidar com uma equipe de especialistas para entregar um
ressalta que as atividades exercidas pelo gerente de projeto são finitas e não repetitivas,
ocorrendo somente durante o andamento do mesmo.
Lawrence & Lorsch (1967) apesar de utilizarem o termo integrador, apresentam uma
discrição similar do que vem a ser um gerente de projeto. Segundo os autores, após a 2a
Guerra Mundial, as empresas tiverem que se especializar cada vez mais para atenderem a
demanda do mercado por novos produtos. Com isso, surgiu a necessidade de uma nova
função que seria responsável por integrar os diversos setores da empresa como produção,
vendas e pesquisa quanto à criação de um novo produto. Esta pessoa seria a interlocutora
entre estas diversas áreas, sendo responsável por tratar tanto dos problemas de
relacionamento entre as áreas quanto dos problemas que poderiam vir a ocorrer no
desenvolvimento de um produto como falta de padrão de qualidade, estouro de custo e
prazo e outros.
Crawford (1997) observa que os projetos estão se tornando cada vez mais complexos e
multi-disciplinares com mais pessoas afetadas, ou stakeholders que no passado. Neste
contexto, há um interesse crescente sobre competências em gerenciamento de projetos, pois
é necessária uma pessoa com a competência de gerenciar projetos de diferentes tipos em
um ambiente de constantes mudanças. Segundo a autora, este papel seria exercido pelo
gerente de projetos.
Para Menezes (2003), todo projeto deve ter uma pessoa para qual convirja toda a
responsabilidade pelo conjunto de atividades a ser desempenhada e sua integração. Esta
projeto. O gerente de projeto é o interlocutor do cliente, sendo responsável por fornecer
todas as informações necessárias e realizar as negociações, de prazo, custo e escopo, que
por ventura possam vir a ocorrer durante o andamento do projeto.
2.4.2 O papel do Gerente de Projeto
Para Gaddis (1959), o principal problema de qualquer projeto é a inter-relação entre a
estrutura da organização e seus indivíduos. O gerente de projeto, com seu papel de
integrador de áreas distintas, pode vir a ajudar a minimizar este problema desde que exista
uma definição clara de sua autoridade e responsabilidade. Lawrence & Lorsch (1967)
advertem que sem esta definição, o papel do gerente de projeto limita-se a um mero
interlocutor entre as áreas, não conseguindo resolver os problemas que possam vir a
ocorrer.
Gaddis (1959) destaca ainda que o papel do gerente de projeto é bastante complexo, pois
ele precisa conhecer tanto as funções administrativas quanto as funções técnicas, não
devendo ser um especialista em nenhuma das duas. A Tabela 1 abaixo apresenta uma
Tabela 1. Descrição do papel do Gerente de Projeto
Descrição do papel do Gerente de Projeto
Objetivos
• Representação dos interesses do projeto
• Garantia da realização dos objetivos do projeto
• Coordenação da equipe do projeto Posição Organizacional
• Reportar-se ao proprietário do projeto
• Ser um membro da equipe do projeto Funções no processo de iniciação do projeto
• Definição da equipe do projeto
• Entendimento dos objetivos definidos para o projeto
• Formalização do comprometimento de todos os envolvidos no projeto Funções no processo de planejamento do projeto
• Desenvolvimento de um plano de projeto com a definição de papéis e responsabilidade de cada integrante da equipe
• Avaliação dos riscos
• Definição de como será realizada a comunicação dos resultados intermediários e finais do projeto.
Funções no processo de execução do projeto
• Distribuição dos recursos para a realização das atividades do projeto Funções no processo de coordenação e controle do projeto
• Controle dos resultados das atividades e garantia da qualidade dos mesmos
• Aprovação dos resultados
• Determinação, juntamente com a equipe do projeto, da situação do mesmo
• Gerenciamento das mudanças de escopo do projeto
• Planejamento de um plano de ações corretivas
• Preparação de relatórios de acompanhamento informando os resultados do projeto para todos os envolvidos
Fonte: Adaptado de Gareis & Huemann (2000)
Apesar da definição clara do papel do gerente de projeto, algumas pesquisas indicam que as
empresas ainda estão longe de atingir a maturidade necessária ideal para seu desempenho
efetivo. Crawford (1996), em uma pesquisa realizada em duas empresas da Austrália (uma
empresa do setor de varejo e outra governamental), concluiu que a principal dificuldade
continua sendo a falta de autoridade em proporção ao excesso de responsabilidade. Em
não desfruta de autoridade suficiente. É interessante notar que isto ocorre, na pesquisa,
tanto na empresa governamental que possui uma estrutura organizacional projetizada
quanto na empresa do setor de varejo possuidora de uma estrutura organizacional funcional.
2.4.3 Competências do Gerente de Projeto
As primeiras pessoas designadas como gerentes de projeto, no início dos anos 50,
provavelmente não tinham todas as habilidades e competências necessárias para
gerenciarem adequadamente um projeto. Gaddis (1959) já ressaltava que um gerente de
projeto deveria ter um bom conhecimento de planejamento e ser flexível o bastante para ser
adaptar as mudanças que poderiam ocorrer no decorrer do projeto. Somado a isso, o gerente
de projeto deveria apresentar uma boa capacidade em lidar com pessoas. Ao longo dos
últimos 50 anos, o nível de complexidade dos projetos foi aumentando, sendo necessárias
novas competências.
Segundo Klarsfeld (2000), competência pode ser definida como uma combinação de
conhecimento, habilidades e comportamentos geradores de performance e atributos
pessoais que contribuem para a melhoria da performance individual e dos resultados da
organização. O conceito de competência surgiu a partir de uma separação do conceito de
qualificação. Enquanto o conceito de qualificação vincula-se a um cargo sendo definido
como os requisitos associados a ele, o conceito de competência vincula-se ao indivíduo.
O PMI em seu Modelo de Desenvolvimento de Competências para Gerentes de Projeto
de Parry (1998 apud PMI 2002) e define competência como “um grupo relacionado de
conhecimento, habilidades, atitudes e outras características pessoais que: afetam a principal
parte de um trabalho; são correlacionados a performance no trabalho; podem ser medidos a
partir de padrões aceitos; podem ser aperfeiçoados através de treinamento e podem ser
divididos em dimensões de competências”. O modelo PMCD desdobra competência em
três dimensões, como se segue:
§ Conhecimento em Gerenciamento de Projetos – o que o indivíduo conhece sobre
gerência de projetos.
§ Performance em Gerenciamento de Projetos – o que o individuo é capaz de fazer ou
realizar ao aplicar seu conhecimento
§ Competências Pessoais – como o indivíduo se comporta ao realizar um projeto ou
uma tarefa.
A figura 9 apresenta a associação entre as três dimensões de competência propostas pelo
Figura 9. Associação entre as três dimensões de competência
Fonte: PMI (2002:2)
Segundo Kerzner (2001a), duas partes são importantes para o sucesso de um projeto: o
gerente de projeto e a estrutura organizacional montada para o projeto. O modelo PMCD
(PMI, 2002), do mesmo modo enfatiza que o sucesso de um projeto requer tanto a
competência do gerente de projeto quanto a maturidade e capacidade da organização em
gerência de projetos. A Figura 10 mostra que tanto as competências individuais do gerente
de projeto quanto à maturidade da organização fornecem a base para o sucesso do projeto e
Figura 10. Componentes para o sucesso de um projeto
Fonte: PMI (2002:4)
O que podemos concluir é que para o sucesso de um projeto deve existir uma interligação
entre as competências individuais do gerente de projeto e a organização. Segundo Crawford
(1999), pesquisas realizadas por Thamhain (1991 apud Crawford 1999), Pettersen (1991
apud Crawford 1999) e Einsedel (1987 apud Crawford 1999) mostram que o gerente de
projeto não pode apenas ter um conhecimento nas disciplinas de gerência de projeto, ele
deve também conhecer a tecnologia em que o projeto vai ser desenvolvido, a organização
em que o projeto se localiza e o ambiente em que a organização opera.
Com o objetivo de medir a maturidade e capacidade em gerência de projeto de uma
projetos baseados no Capability Maturity Model (CMM). Com uma visão geral, serão
apresentados alguns destes modelos. Ao final, será realizada uma análise comparativa dos
modelos apresentados.
2.5 Modelos de Maturidade em Gerenciamento de Projetos
Segundo Kerzner (2001a), a excelência em gerência de projetos somente é alcançada se a
organização conseguir antes um alto nível de maturidade. Segundo o autor, somente o uso
de metodologias de gerenciamento de projetos não é suficiente para alcançar esta
excelência. Para Kerzner (2002), 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 que cada um deles seja um sucesso. O autor ressalta que sistemas e processos repetitivos
não garantem por si só o sucesso em projetos apenas aumenta sua probabilidade.
Cleland & Ireland (2002) observam que um modelo de maturidade tem como principal
objetivo fornecer a estrutura para que se possa medir o grau de desenvolvimento da
capacidade gerencial de um projeto e com isso orientar o desenvolvimento interno da
capacidade de uma organização, comparando-a com seus concorrentes. Similarmente
Kerzner (2001a) destaca que modelos ajudam as organizações a realizarem um
planejamento estratégico de gerência de projetos ao mostrarem o nível em que a
organização se encontra e sugerirem o que deve ser feito para alcançarem o nível desejado.
Existem diversos modelos de maturidade em gerenciamento de projetos (Fincher & Levin,
quatro ou cinco passos para medir a capacidade em gerenciamento de projetos de uma
organização, tendo como origem o Capability Maturity Model (CMM) do Software
Engineering Institute(SEI) da Carnegie Mellon University, EUA.
2.5.1 O Modelo CMM (Capability Maturity Model)
O Modelo CMM foi criado, em 1986 pelo SEI com o patrocínio do Departamento de
Defesa Americano, com o objetivo de aprimorar a capacidade das empresas no
desenvolvimento de software. Segundo Paulk et al (1993), o CMM fornece uma orientação
para as organizações de como controlar seus processos de desenvolvimento e manutenção
de software. Sua estrutura foi inspirada no modelo de qualidade de Crosby (1979 apud
Paulk et al, 1993) definido como Grid de Maturidade da Gerência de Qualidade (Quality
Management Maturity Grid) . O modelo de maturidade de Crosby descreve cinco estágios
ou níveis crescentes de adoção de práticas de qualidade. A Tabela 2 apresenta os cinco
níveis do modelo de Crosby.
Tabela 2. Grid de maturidade gerencial de Crosby
Nível Definição
1. Incerteza Falta de interesse pela resolução de problemas de qualidade do produto desenvolvido e do processo
2. Despertar Reconhecimento da necessidade de se resolver os problemas e do valor dos processos para o negócio
3. Esclarecimento Início de estudo e capacitação em métodos para melhoria dos processos de trabalho
4. Sabedoria Valorização do processo de melhoria contínua, por meio da participação direta dos gerentes nas ações para melhoria dos processos.
5. Certeza Gerência do processo passa a ser considerada como parte essencial do trabalho.
Segundo Cleland & Ireland (2002), o modelo CMM utiliza a gerência de projetos dentro da
sua estrutura para atingir um processo que possa ser repetido e com isso tentar obter
resultados mais previsíveis. O modelo também possui cinco estágios ou níveis
hierarquizados que podem ser resumidos segundo a tabela abaixo:
Tabela 3. Modelo de Maturidade da Capacidade de Gerenciamento de Software
Nível Definição
1. Inicial A estabilidade do processo é incerta podendo ser caótica. Existem poucos processos definidos e o sucesso é dependente de esforços individuais
2. Repetido Processos básicos de gerenciamento estão definidos principalmente os que dizem respeito a custo, tempo e funcionalidade. A disciplina do processo permite que sucessos anteriores sejam repetidos em novos projetos similares.
3. Definido Tanto o processo de gerenciamento quanto o processo de engenharia de software são documentados, padronizados e integrados a um processo padrão para desenvolvimento e manutenção de software. 4. Gerenciado São coletadas informações detalhadas do processo de software e da
qualidade do produto, sendo estas informações entendidas e controladas.
5. Otimizado Um processo de melhoria contínua é possibilitado a partir de informações empíricas dos processos e de tecnologias e idéias inovadoras
Fonte: Paulk et al (1993)
2.5.2 Modelo de Fincher & Levin
O modelo de maturidade em gerenciamento de projetos de Fincher & Levin (1997 apud
Cleland & Ireland, 2002) foi um dos primeiros modelos de maturidade adaptados para a
gerência de projetos. Ele guarda bastante similaridade com o modelo CMM. A tabela
