FUNDAÇÃO GETULIO VARGAS
ESCOLA BRASILEIRA DE ADMINISTRAÇÃO PÚBLICA E DE EMPRESAS
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
Marta Cecília Henriques Calheiros
Rio de Janeiro, 2005
II
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
rever diversas vezes o texto desta dissertação.
III
Ao meu esposo Márcio e
aos meus pais Rubem e Nilda
IV
“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.”
Aristóteles (384-322 AC)
V
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
à medida que o grau de maturidade for sendo aperfeiçoado.
VI
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
adequated to the level found, that could be improved with the increase of the maturity level.
VII
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.4
2.5
2.3.1
Estrutura funcional
25
2.3.2
Estrutura projetizada
27
2.3.3
Estrutura matricial
29
Competências em gerenciamento de projetos......................................................... 31
2.4.1
O Gerente de Projeto
31
2.4.2
O papel do Gerente de Projeto
33
2.4.3
Competências do Gerente de Projeto
35
Modelos de Maturidade em Gerenciamento de Projetos ....................................... 39
VIII
2.6
3
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
51
Uma Análise Comparativa dos Modelos
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
Metodologia ................................................................................................................. 63
3.1
Pesquisa Bibliográfica.............................................................................................. 64
3.2
Pesquisa de Campo................................................................................................... 64
3.3
4
3.2.1
Apresentação
64
3.2.2
Estrutura do Formulário
65
Limitações do Método.............................................................................................. 74
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.1.3
A empresa em números
82
IX
4.2
5
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
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
5.2
Distribuição das freqüências
105
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
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
117
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
Anexo II .................................................................................................................................. 152
X
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)2 de 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
Tabela 11. Distribuição das freqüências ............................................................. 104
XI
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 22. Gráfico de distribuição das respostas da questão 2 ........................... 107
XII
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
Figura 38. Gráfico de distribuição das respostas da questão 15 .......................... 124
XIII
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
RLAM
Refinaria Landulfo Alves
XIV
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
UN-RIO
Unidade de Negócios Rio
1
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.
(PMI, 2005).
2
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 bemsucedidos. 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
de maior agilidade em decorrência da abertura do mercado de petróleo no país e das
3
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
conseqüência, o desempenho da TI.
4
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
adotado.
5
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 análise das lacunas existentes entre a situação atual da área e a situação desejada;
6
• 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
estarem em conformidade com os requisitos solicitados pelo cliente.
7
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,
as estratégias definidas são efetuadas. Estratégias são implementadas através de projetos e
8
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,
tornando os processos de gerenciamento de projetos da organização mais maduros e com
9
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
projetos para que estes possam ser utilizados como referencial teórico para a realização de
10
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
apresentadas as sugestões para estudos futuros.
11
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
primeira bomba atômica, é normalmente reconhecido como o primeiro projeto a utilizar as
12
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 ThiryCheques (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
conforme requisitos específicos, incluindo limitações de tempo, custo e recursos”. Podemos
13
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 apresenta um exemplo de ciclo de vida genérico de um projeto.
14
Figura 1. Exemplo genérico de um ciclo de vida
FASES
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)
15
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
categorias de projetos.
16
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 stakeholders1 possuem no projeto e é realizado através da aplicação e integração dos
seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução,
Stakeholders: todos os agentes que contribuem para o desempenho da organização; por exemplo:
funcionários de todos os níveis, acionistas, clientes, comunidades, governos federal, estadual e municipal
(Cleland & Ireland, 2002, p.2)
1
17
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
produto desenvolvido pelos clientes. A Figura 4 mostra a interligação entre os processos:
18
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
tarefas desnecessárias.
19
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,
devendo identificar, analisar, mitigar e responder aos riscos do projeto.
20
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,
define o sucesso de um projeto como o atendimento do objetivo determinado para o
21
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 apresenta como o sucesso, segundo Kerzner, deve ser definido.
22
Figura 5. “Sucesso deve ser um cubo em vez de um ponto”
Custo
Qualidade ou escopo
Tempo
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
23
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;
8. Monitoramento e controle dos recursos do projeto;
24
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
desenvolvimento de novas estruturas organizacionais. Similarmente, Morgan (1996)
25
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
a mudanças. Na estrutura funcional, os projetos são desenvolvidos dentro de um dos
26
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
departamentos onde os projetos são desenvolvidos não possuem foco no cliente priorizando
27
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
indivíduo, o gerente de projeto, mantém autoridade completa sobre o projeto como um
28
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
as áreas, permitindo que a alta gerência executiva tenha mais tempo para tomada de
29
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
gerente de projeto possui uma maior influência sobre os membros da equipe que os
30
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
projeto, que com isso mantém um máximo controle sobre todos os recursos necessários ao
31
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
produto final de acordo com o especificado dentro das limitações de prazo e custo. O autor
32
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
pessoa é o gerente de projeto que é o responsável pelos resultados parciais e globais do
33
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
descrição do papel do gerente de projeto.
34
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
outras palavras, o gerente de projeto possui um grande conjunto de responsabilidade, mas
35
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
(Project Manager Competency Development (PMCD) Framework), baseia-se na definição
36
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
modelo.
37
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
que ambos são influenciados por diversas contingências e variáveis reguladoras.
38
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
organização, foram criados nos últimos anos, modelos de maturidade em gerenciamento de
39
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,
1997; Kwak & Ibbs, 2002; Kerzner, 2001a; PMI, 2003). Todos se utilizam normalmente de
40
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
1. Incerteza
Definição
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.
Fonte: Cleland & Ireland (2002)
41
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
1. Inicial
Definição
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
abaixo apresenta os cinco níveis de maturidade do modelo.
42
Tabela 4. Modelo de Maturidade em Gerenciamento de Projeto – Fincher & Levin
Nível
1- Inicial
Definição
Não existe um processo definido. O trabalho é realizado na medida
em que é necessário. O sucesso do projeto depende de esforços
individuais. Não existe uma metodologia formal de gerência de
projetos.
2- Repetível
Os membros da equipe do projeto recebem treinamento sobre os
elementos fundamentais da gerência de projeto e sobre áreas de
conhecimento ou habilidades correlatas. Existe uma metodologia que
é aplicada.
Enfatiza-se a reprodução do processo de modo a assegurar que o
resultado do trabalho seja repetido.
3 – Definido
Todas as áreas de gerência do projeto são definidas e os processos
são documentados. Práticas de gerência de projetos são coletadas e
utilizadas para aumentar a eficiência e eficácia do projeto
4 – Gerenciado
O processo de gerência de projetos é medido e controlado. As
dificuldades do projeto são antecipadas pela gerência e soluções são
encontradas antes que os obstáculos exerçam um grande impacto
sobre o projeto
5 – Otimizado
Enfoque no aprimoramento do projeto e nos ajustes finais da
metodologia buscando se adequar ao ritmo das mudanças
tecnológicas. Os processos são utilizados adequadamente. Todos os
empregados estão treinados e desempenhando suas funções dentro
dos mais altos níveis de competência
Fonte: Fincher & Levin (1997) apud Cleland & Ireland (2002:295)
Fincher & Levin (1997 apud Cleland, 2002) ao contrário de outros autores defendem a
idéia de que não é necessário que todas as organizações busquem o mais alto nível de
maturidade para serem eficazes. Os autores sugerem que toda organização deve encontrar a
melhor combinação de competências que seja mais adequada a seus objetivos. Ou em
outras palavras, devem avaliar a relação custo-benefício de alcançar o nível mais alto de
maturidade.
43
2.5.3 Modelo de Maturidade em Processos de Gerenciamento de Projetos (Project
Management Process Maturity Model) – (PM)2 - modelo de Berkeley
O modelo (PM)2 de Kwak & Ibbs (2002) foi desenvolvido a partir de uma pesquisa
realizada pelos autores em 2000 com empresas de diversos setores como Engenharia e
Construção Civil, Telecomunicações e Sistemas de Informação. Este modelo é similar aos
modelos de Fincher & Levin (1997 apud Cleland, 2002) e Kerzner (2001b) e segue uma
abordagem incremental que se inicia com uma metodologia não-sofisticada ou inexistente
até um nível de maturidade sofisticado para os processos de gerência de projetos. Os
autores detalham os cinco níveis de maturidade para cada uma das nove áreas de
conhecimento e cada uma cinco fases do ciclo de vida do projeto, conforme abordagem do
PMI (2004b). Este detalhamento permite uma análise dos pontos fracos e fortes de uma
organização em áreas específicas da gerência de projeto. A partir desta análise, a
organização pode definir em quais áreas deve se ater para alcançar um maior nível de
maturidade. Os cinco níveis do modelo são apresentados na tabela abaixo.
44
Tabela 5. Níveis de maturidade do modelo (PM)2 de Kwak & Ibbs
Nível
1- Ad-hoc
Definição
Os processos de gerência de projetos são básicos, não sendo
avaliados consistentemente. As informações do projeto não são
coletadas e analisadas.
2- Planejado
O planejamento do projeto é individual. São definidos processos
informais, problemas são identificados e dados são coletados
3- Gerenciado no
Planejamento formal de projeto e sistemas de controle são
nível de projeto
utilizados.
4 – Gerenciado no
Planejamento e controle integrados. Surge o conceito de
nível da
gerenciamento de programas (vários projetos gerenciados
organização
paralelamente). Os dados do projeto são quantitativamente
analisados, medidos e armazenados.
5- Aprendizagem
Processos de gerenciamento de projeto são continuamente
contínua
aperfeiçoados. Todos os processos são totalmente compreendidos.
Os dados de gerência de projeto devem ser otimizados e
guardados.
Fonte: Kwak & Ibbs (2002)
2.5.4 Modelo de Maturidade de Kerzner
Kerzner (2001a) ao apresentar seu modelo ressalta que a conquista da excelência em
gerência de projetos só acontece com o reconhecimento por parte das empresas de que o
planejamento estratégico para gerência de projetos é essencial e que os gerentes de nível
médio são os principais responsáveis pela execução da estratégia planejada. O autor ressalta
que estes devem ser auxiliados pela alta gerência de forma a garantir que não ocorram
mudanças indesejadas na cultura corporativa. Os cinco níveis do modelo de maturidade de
Kerzner são apresentados na tabela abaixo:
45
Tabela 6. Níveis de maturidade de Kerzner
Nível
1- Linguagem
comum
Definição
A empresa reconhece a importância e necessidade de utilizar e
conhecer as técnicas de gerência de projetos para se chegar a uma
linguagem comum
2- Processos
A necessidade da definição e desenvolvido de processos comuns
comuns
de forma a repetir sucessos ocorridos em projetos anteriores é
reconhecida. Além disso, verifica-se que a metodologia de
gerenciamento de projetos pode ser aplicada a outras metodologias
utilizadas pela empresa
3- Metodologia
A gerência de projetos é utilizada como metodologia
única
centralizadora. A empresa reconhece os efeitos sinérgicos de
combinar todas as metodologias em uma única.
2
4 – Benchmarking
A empresa reconhece que é necessário o aprimoramento dos
processos para se manter uma vantagem competitiva. Para isso a
empresa define quem e o que deverá ser monitorado para a
realização de análises comparativas.
5- Melhoria
Constantes avaliações dos dados obtidos com o benchmarking para
contínua
decidir quais as informações irão agregar valor à metodologia
utilizada.
Fonte: Kerzner (2001a:1045-1049)
Kerzner (2001a) destaca que quando se fala sobre níveis de maturidade normalmente se
pensa que o processo deve ser realizado sequencialmente. Segundo o autor, isto não é
necessariamente verdade. Alguns níveis podem ser sobrepostos. A extensão da
sobreposição depende da quantidade de riscos que organização deseja suportar. Porém a
ordem que os níveis devem ser completados não pode ser alterada. O autor não recomenda
a sobreposição dos níveis 2 e 3, uma vez que para uma metodologia ser considerada única
outras devem ser abandonadas e isso não pode ser realizado sem a consolidação de
processos. Ao alcançar o nível 5, deve-se sempre retornar ao nível 3 e 4 de forma a se ter
Benchmarking - processo de comparação constante das práticas de uma organização com as práticas de
outras organizações com o objetivo de obter informações que possam aperfeiçoar a performance da
organização (Kerzner, 2001b)
2
46
um ciclo de melhoria continua. A figura 11 apresenta um diagrama com os níveis de
maturidade e suas interações.
Figura 11. Níveis de maturidade e suas interações
Fonte: Silva (2003:25)
Segundo Kerzner (2001a), existem riscos em cada nível do modelo. A criticidade do risco é
frequentemente associada ao impacto na cultura corporativa. Para o autor, o nível 3 é o que
apresenta maiores dificuldades de ser alcançado pois requer as maiores mudanças na
cultura corporativa. Os níveis 1 e 2 apresentam graus médios de dificuldade e os níveis 4 e
5 apresentam baixo grau de dificuldade para serem alcançados.
47
2.5.5 O Modelo do PMI – Organization Project Management Maturity Model (OPM3)
Em maio de 1998, o PMI iniciou o programa Organization Project Management Maturity
Model (OPM3) com o objetivo criar um modelo de maturidade de gerenciamento de
projetos que servisse como referência e ajudasse as organizações a alinhar diversos
aspectos de suas operações com suas estratégias de negócio. Segundo o PMI (2003), a
aplicação do OPM3 auxilia as empresas a estabelecer políticas e processos padrões para
assegurar que suas operações estão consistentes com seus objetivos estratégicos.
O modelo OPM3 foi intencionalmente projetado sem o sistema de níveis de maturidade
existentes em outros modelos. A progressão do aumento da maturidade dentro do OPM3
consiste de várias dimensões ou diferentes maneiras de se observar à maturidade de uma
organização. Para o PMI (2003), múltiplas perspectivas para avaliar a maturidade permitem
flexibilidade em se aplicar o modelo às unicidades de uma organização. O modelo OPM3
possui três dimensões a saber: o domínio do gerenciamento, o estágio do processo de
aperfeiçoamento e os processos de gerenciamento de projetos.
O domínio do gerenciamento refere-se ao nível de gerenciamento de projetos de uma
organização. O gerenciamento pode ocorrer em três níveis: Projeto, Programa ou Portfolio.
Segundo o PMI (2003), programa é definido como sendo um grupo de projetos
relacionados gerenciados de uma forma coordenada para obter benefícios e controles que
não seriam possíveis de serem obtidos individualmente. Portfolio, no contexto de
gerenciamento de projetos, é definido como uma coleção de projetos e programas que são
agrupados juntos com o intuito de facilitar o gerenciamento efetivo, de forma a alcançar os
48
objetivos estratégicos. Os projetos e programas de um porfolio não são necessariamente
dependentes ou relacionados. O estágio do processo de aperfeiçoamento se refere à escala
seqüencial de aperfeiçoamento: Padronização, Medição, Controle e Melhoria Contínua. A
seqüência implica em uma inter-relação entre os estágios em que o estágio mais avançado
Melhoria Contínua é dependente do estágio anterior e assim por diante. A última dimensão
se refere aos processos de gerenciamento de projetos definidos no Guia PMBoK: Iniciação,
Planejamento, Execução, Monitoramento e Controle e Finalização.
A maturidade organizacional em gerenciamento de projetos é descrita pelo OPM3 através
da existência de Melhores Práticas (Best Practices). Melhor Prática é definida no modelo
como um modo ideal reconhecido pela indústria de alcançar uma determinada meta ou
objetivo. Elas se estendem por diversas categorias como:
• Padronização e integração de Métodos e Processos;
• Desempenho e Métricas enfatizando os aspectos do trinômio prazo-custo-qualidade;
• Comprometimento com procedimentos de gerenciamento de projetos;
• Priorização de Projetos e Alinhamento Estratégico;
• Melhoramento contínuo;
• Estabelecimento de critérios de sucesso para continuar ou terminar projetos;
• Desenvolvimento de competências em gerenciamento de projetos;
• Alocação adequada de recursos em projetos respeitando os projetos prioritários;
• Apoio Organizacional para Projetos;
• Aperfeiçoamento do trabalho em equipe;
49
O OPM3 possui 586 melhores práticas. Cada melhor prática é mapeada no modelo em uma
ou mais dimensões. Ou seja, o modelo apresenta onde a melhor prática se encontra dentro
dos domínios do gerenciamento de projeto, programa ou portfolio e em qual estágio do
processo de aperfeiçoamento. Cada melhor prática é composta por duas ou mais
Capacidades. Capacidade é definida pelo modelo como sendo uma competência específica
que deve existir na organização para que a mesma possa executar processos de
gerenciamento de projetos e criar produtos e serviços.
A existência de uma dada capacidade na organização é demonstrada através de um ou mais
Resultados. Resultados são definidos como conseqüências tangíveis ou intangíveis da
aplicação de uma Capacidade. Uma Capacidade pode ter múltiplos resultados. Resultados
podem ser verificados através de Indicadores Chave de Desempenho. Indicadores Chave de
Desempenho são definidos pelo modelo como sendo critérios através dos quais a
organização pode determinar quantitativamente ou qualitativamente se um Resultado
associado a uma Capacidade existe e em que grau.
O modelo OPM3 é dividido em três elementos interligados:
• Conhecimento – Relacionado com as melhores práticas e como utilizar o modelo;
• Avaliação – Métodos de avaliação das melhores práticas e capacidades;
• Melhoria – Define a seqüência de capacidades a serem desenvolvidas agrupadas as
melhores práticas.
O ciclo de aplicação do modelo em uma organização é composto por cinco passos:
Preparação para Avaliação, Avaliação, Planejamento das Melhorias, Execução das
50
Melhorias e Repetição do Processo. A figura abaixo mostra como os passos do ciclo se
inserem dentro dos três elementos.
Figura 12. Ciclo do OPM3
Fonte: adaptado de PMI (2003:25)
A primeira versão do modelo OPM3 só foi liberada pelo PMI em Setembro de 2003, cinco
anos após o início do programa. É um modelo recente não sendo encontrados ainda estudos
sobre sua aplicação em organizações.
Pennypacker & Grant (2003) verificaram, em uma pesquisa realizada com empresas de
quatro diferentes setores da indústria americana, que 67% das organizações pesquisadas
ainda estão no nível maturidade 2, independente do tamanho e do setor específico. No
51
Brasil, os Estudos de Benchmarking em Gerenciamento de Projetos realizados pelo PMI –
Seção Rio de Janeiro em 2003 com 60 empresas e em 2004 com 73 empresas de diversos
setores da indústria brasileira como Construção Civil, Petróleo e Gás e Tecnologia da
Informação verificaram que as empresas brasileiras ainda estão em um nível de maturidade
baixo com um melhor desempenho nas empresas do setor de Construção Civil. Por um
outro lado, grande parte das empresas percebe de forma clara os benefícios da gerência de
projetos, acreditando que ainda tem um longo caminho a percorrer.
2.5.6 Uma Análise Comparativa dos Modelos
A Tabela 7 apresenta uma análise comparativa dos modelos apresentados.
Tabela 7. Resumo da evolução dos modelos de maturidade.
Ano
Autor
1979
Crosby
1- Incerteza
N
Í
V
E
I
S
2- Despertar
3-Esclarecimento
4- Sabedoria
5- Certeza
1986
Paulk et al
(CMM)
1-Inicial
1997
Fincher &
Levin
1-Inicial
2001
2002
Kerzner
Kwak & Ibbs
(PMMM)
(PM)2
1-Linguagem
1 –Ad hoc
Comum
2-Repetido 2-Repetível
2-Processos
2- Planejado
Comuns
3-Definido
3-Definido 3-Metodologia 3-Gerenciado
no nível de
projeto
4444-Gerenciado
Gerenciado Gerenciado Benchmarking no nível da
organização
5-Otimizado 5-Otimizado
5-Melhoria
5Contínua
Aprendizagem
contínua
Além disso, podemos avaliar resumidamente as principais características dos modelos
apresentados:
52
Tabela 8. Características dos modelos de maturidade apresentados
Crosby
•
Baseado nos princípios da qualidade do produto
Inclui o envolvimento das pessoas no processo de gerência
da qualidade
• Base para outros modelos de maturidade
CMM
• Oferece duas representações para melhorias contínuas e
pontuais;
• Fornece melhores práticas que endereçam produtividade,
performance, custos e satisfação dos stakeholders
• Foca nos problemas de processos de softwares
• Facilita um processo de melhoria abrangente na empresa
Fincher & Levin
• Um dos primeiros modelos de maturidade adaptado do
CMM
• Defende a idéia de que as organizações não precisam estar
necessariamente no nível de maturidade mais alto para serem
eficazes
Modelo de Berkeley – • Baseado na pesquisa do PMI e incorpora partes de outros
(PM)2
modelos
• Permite análise dos pontos fracos e fortes da organização em
áreas específicas da gerência de projetos
• Enfatiza o gerenciamento de programas e portfolios nos
níveis 4 e 5
Kerzner’s PMMM
• Questões genéricas que podem ser aplicadas a múltiplas
empresas
• Funcionalidade de visão executiva
• Possui um Plano de Ação detalhado
• Fornece a base para o Planejamento Estratégico em
Gerenciamento de Projetos
OPM3
• Modelo padrão do PMI
• Possui várias dimensões permitindo diversas maneiras de se
observar a maturidade de uma organização
• Possui 586 melhores práticas, cada uma composta de duas
ou mais capacidades
• Possui um plano de ação permitindo que as organizações
escolham as melhores práticas a serem aperfeiçoadas
Fonte: adaptado de Herszon (2004)
•
53
2.6 Escritório de Gerenciamento de Projeto – PMO (Project Management Office)
2.6.1 O que é um PMO.
Com o desenvolvimento do gerenciamento de projetos e a disseminação de procedimentos
e processos, tornou-se necessário, principalmente nas grandes empresas, concentrar o
desenvolvimento de padrões, reunir as atividades de avaliação dos projetos e consolidação
dos resultados dos mesmos em uma mesma estrutura organizacional. Esta estrutura é
conhecida como PMO. Existem várias definições de PMO. Segundo DAI (2001 apud
Patah 2004), o PMO pode ser definido como uma estrutura organizacional que tem como
objetivo auxiliar os gerentes de projeto e suas equipes na implementação dos princípios,
práticas, metodologias, ferramentas e técnicas de gerenciamento de projeto. Block & Frame
(1998) observam que quando um escritório de projeto é estabelecido, a organização pode
desenvolver uma abordagem consistente em gerenciamento de projetos.
2.6.2 O papel e as funções de um PMO.
Segundo Verzuh (2000), independentemente da forma como um PMO vai ser estabelecido
em uma organização, os principais fatores que devem dirigi-lo são responsabilidade e
autoridade.
Block & Frame (1998) destacam as principais funções de um PMO:
•
Fornecer suporte em gerenciamento de projetos para a equipe de projetos;
54
•
Prover a organização com consultoria e mentoring3 em gerenciamento de
projetos;
•
Desenvolver e manter metodologias e padrões em gerenciamento de projetos
para a organização;
•
Fornecer treinamento em gerenciamento de projetos para a organização;
•
Prover a organização com gerentes de projeto.
Similarmente, Verzuh (2000) apresenta as seguintes responsabilidades para um PMO:
•
Manutenção de padrões;
•
Organização de treinamentos;
•
Mentoring e Consultoria;
•
Análise de Cronogramas e Orçamento;
•
Preparação de informações de projetos;
•
Tomada de decisões em gerenciamento de projetos;
•
Cumprimento dos objetivos do projeto;
•
Fornecimento de gerentes de projetos para a organização;
•
Participação no gerenciamento do portfolio de projetos;
O autor observa que dependendo da estrutura de PMO escolhida, algumas
responsabilidades podem ou não ser exercidas.
Mentoring – O conceito de mentoring (mentor) enfatiza a idéia de que o principal trabalho do mentor não é
resolver o problema e sim orientar com sua experiência os empregados responsáveis a solucionarem os
problemas. (Block & Frame ,1998, p.18)
3
55
Dinismore (1998 apud Patah 2004) propõe cinco modelos de PMO.
•
Equipe Autônoma de Projeto;
•
Project Support Office (PSO);
•
Project Management Center of Excellence (PMCOE);
•
Program Management Office (PrgMO);
•
Chief Project Office (CPO)
Quando uma organização conduz projetos de forma autônoma, a função de gerenciamento
de projetos permanece dentro do próprio projeto. As informações sobre as práticas de
gerenciamento de projetos vêm da experiência com projetos anteriores e da experiência dos
próprios gerentes de projeto. Todas as funções de gerenciamento de projeto são realizadas
pela própria equipe do projeto. A função deste tipo de PMO é gerenciar o projeto como um
todo, residindo no gerente de projeto, a responsabilidade pelo sucesso do mesmo.
O Project Support Office (PSO) apóia diversos projetos simultaneamente. Suas principais
funções são: fornecer suporte, ferramentas e serviços de planejamento, determinar padrões
de qualidade, custo e prazo para os projetos, fornecer recursos técnicos e estabelecer
metodologias de gerenciamento de projetos. A responsabilidade pelo sucesso dos projetos
não reside no PSO e sim nos gerentes de projetos que utilizam seus serviços. O PSO é
considerado um centro de competência em projetos.
O Project Management Center of Excellence (PMCOE) é o ponto focal da experiência em
projetos, mas não assume a responsabilidade pelo resultado dos mesmos. A principal tarefa
56
do PMCOE é disseminar a disciplina de gerenciamento de projeto pela organização,
divulgando metodologias, técnicas e práticas.
O Program Management Office (PrgMO) gerencia os gerentes de projeto e é o responsável
pelo sucesso dos projetos. Em grandes corporações, o PrgMO concentra suas atividades
nos projetos estratégicos, sendo os outros projetos gerenciados por departamentos ou
unidades, recebendo o apoio do PrgMO quando necessário. O PrgMO compreende as
funções de um PMCOE e em alguns casos de um PSO.
A principal responsabilidade de um Chief Project Office (CPO) consiste em controlar o
portfolio de projetos da organização, desde fase de iniciação do projeto até o fechamento do
mesmo. Entre as atividades do CPO podemos destacar: alinhamento das estratégias de
negócio com os projetos, acompanhamento dos projetos em âmbito empresarial,
desenvolvimento da conscientização e da competência em gerenciamento de projetos dos
membros da organização, desenvolvimento de padrões, políticas e procedimentos em
gerenciamento de projetos e avaliação periódica dos projetos incluindo a decisão de
descontinuá-los.
Verzuh (2000) também apresenta uma classificação de cinco diferentes tipos de PMO:
•
Centro de Excelëncia;
•
Escritório de Apoio de Projeto (EAP) – Project Support Office (PSO);
•
Escritório de Gestão de Projeto (EGP) – Project Management Office;
•
Escritório de Gerenciamento de Programa – Program Management Office;
•
Escritório Responsável pelo Projeto – Accountable Project Office
57
Segundo o autor, o propósito principal de um Centro de Excelência é manter os padrões de
gerenciamento de projetos e promover sua utilização na organização. Apesar da equipe
freqüentemente ser solicitada a apoiar os gerentes de projetos, eles não participam da
tomada de decisões do projeto. Sua autoridade na organização origina-se exclusivamente do
seu conhecimento de gestão de projeto.
O Escritório de Apoio de Projeto (EAP), além de manter e promover os padrões e práticas
de gerenciamento de projetos, apóia ativamente uma variedade de projetos através de uma
série de atividades como a criação e atualização do plano de projeto e orçamento do
mesmo.
O Escritório de Gestão de Projeto (EGP) pode fornecer suporte na confecção de
cronogramas e orçamentos, e manter os padrões e práticas da mesma forma que o EAP. A
principal diferença é que o EGP disponibiliza gerentes de projetos para os projetos da
organização. Apesar de prover os gerentes de projetos, o EGP não é responsável pelo
resultado dos projetos.
Os programas, como já tido anteriormente, são vários projetos relacionados entre si. O
papel de um Escritório de Gerenciamento de Programas é fornecer o conhecimento técnico
de todo o programa, vinculando assim todos os projetos juntos. Como um EAP, o Escritório
de Gerenciamento de Programas não é diretamente responsável pelo cumprimento do
cronograma, seu papel é principalmente disseminar os padrões e práticas de gerenciamento
de projetos e apoiá-los. Participa da tomada de decisões do projeto e diferentemente das
58
outras formas de PMO, possui uma vida útil, ou seja, será desmontado quando ao final do
programa.
O Escritório Responsável pelo Projeto é a forma mais antiga, mas em alguns casos, o mais
radical de PMO. Ele é chamado assim, pois possui responsabilidade total pelos objetivos
de qualidade, custo e tempo sobre os projetos a ele designados. Sua equipe inclui tanto
gerentes de projetos quanto pessoal de apoio a projeto. A tabela abaixo resume as
responsabilidades dos PMOs, segundo Verzuh (2000), onde “•” significa responsabilidade
integral e “ο” significa responsabilidade parcial.
Tabela 9. Formas e responsabilidades dos PMOs
Responsabilidade
Manutenção de
padrões
Organização de
treinamentos
Mentoring e
consultoria
Análise de
Cronogramas e
Orçamento
Preparação de
informações de
projetos
Tomada de decisões
em gerenciamento
de projetos
Cumprimento dos
objetivos do projeto
Fornecimento de
gerentes de projetos
para a organização
Participação no
gerenciamento do
portfolio de projetos
Baixa
Centro de
Excelência
•
Autoridade de influência nos projetos
Escritório
de Apoio a
Projetos
•
Escritório
Escritório de
de Gestão
Gerenciamento
de Projetos de Programas
•
•
Alta
Escritório
Responsável
pelo Projeto
•
ο
ο
ο
ο
ο
ο
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ο
•
ο
ο
ο
Fonte : adaptado de Verzuh (2000)
ο
ο
•
•
•
59
Pelo que foi apresentado, existem vários tipos de PMO e o que os distinguem são os
diferentes graus de responsabilidade e autoridade. Verzuh (2000) destaca que embora os
modelos do PMO pareçam evolutivos, seria um erro sugerir que todas as empresas devam
iniciar com um modelo de Centro de Excelência e evoluir até um PMO do tipo Escritório
Responsável pelo Projeto. Segundo o autor, o escritório de projeto deve refletir a estrutura
organizacional, o estágio de maturidade da organização em gerenciamento de projetos e a
alocação dos projetos dentro da organização. A presença de um escritório de projeto, não
importando o tipo, representa um comprometimento da organização para a melhoria do
gerenciamento de projetos.
2.6.3 Implantação de um Escritório de Projeto
Segundo Litke (1995 apud Patah 2004), as principais motivações para a implantação de um
PMO em uma organização são as seguintes:
•
Grande número de atividades burocráticas sendo realizadas pelos membros das
equipes de projeto tendo consequentemente pouco tempo disponível para se
dedicarem aos projetos;
•
Processos de gerenciamento de projeto não padronizados;
•
Baixa produtividade dos projetos;
•
Aumento da complexidade dos projetos;
•
Documentação dos projetos espalhada por toda a organização.
Para Patah (2004), a implantação de um PMO pode ser vista como um projeto e como tal é
composta por fases que devem ser realizadas na seqüência adequada para que os resultados
60
previstos possam ser alcançados. Block & Frame (1998) dividem o processo de
implantação de um PMO nas seguintes fases:
•
Diagnóstico da situação atual;
•
Determinação da missão, objetivo, escopo e funções;
•
Identificação do patrocinador;
•
Estabelecimento da estrutura;
•
Preparação de plano de comunicação;
•
Realização de um projeto piloto;
•
Disseminação;
•
Avaliação e melhoria.
A avaliação da situação atual da organização tem como objetivo avaliar o nível de
maturidade em gerenciamento de projeto da mesma. Esta avaliação consiste em uma
comparação dos processos de gerenciamento da organização com os padrões aceitos no
mercado e com isso determinando a competência que a organização possui em obter e
repetir sucessos em projetos. Ao se examinar, o nível de maturidade que a organização se
encontra poderá ser realizada uma análise das lacunas existentes e a partir deste resultado
podem ser desenvolvidas ações de melhoria no processo de gerenciamento.
A partir da avaliação, devem ser definidos os objetivos, a missão e o escopo do PMO. O
PMO pode possuir duas abordagens: uma consultiva e outra centralizadora. Empresas com
baixo nível de maturidade tendem a preferir PMO com uma abordagem consultiva,
responsável por padrões, métricas e metodologias. À medida que o nível de maturidade da
61
empresa aumenta, o PMO passa a ter uma abordagem centralizadora, mais voltada ao
alinhamento estratégico.
A identificação de um patrocinador é fundamental pois os principais benefícios de ser
implantar um PMO não aparecem no início, vão surgindo com o tempo. Santosus (2003)
em uma pesquisa realizada com 450 empresas verificou que o tempo de operação de um
PMO é diretamente proporcional ao aumento da taxa de sucesso de projetos. Quanto mais
tempo de operação maiores as taxas de sucesso.
A estrutura e as características do PMO devem ser definidas com base nos passos
anteriores. Deve ser determinada a estrutura organizacional e os processos, padrões e
métricas estabelecidos. A métrica será utilizada para mensurar o sucesso e servir como
insumo para as medidas de melhoria dos processos.
Qualquer mudança por menor que seja causa resistência. O principal objetivo do plano de
comunicação é explicar detalhadamente o motivo da implantação do PMO, quais serão seus
objetivos, benefícios, funções, responsabilidades e como irá interagir com a organização. A
comunicação de todo o processo de implantação, bem como os resultados obtidos, deverá
ser realizada regularmente para que as pessoas não se sintam alijadas do processo e para
que não haja desinformação, gerando com isso expectativas infundadas referentes às
atribuições, responsabilidades e possibilidades de sucesso.
A organização deverá escolher um projeto piloto que irá utilizar o PMO recém-criado. Este
projeto deverá ser acompanhado e irá fornecer uma oportunidade de experimentar os
62
processos criados bem como realizar os ajustes necessários. A última fase do projeto piloto
é a avaliação dos resultados. Quaisquer modificações que precisem ser realizadas nos
processos ou na estrutura do PMO devem ser efetuadas antes do seu lançamento oficial.
Denomina-se por disseminação, a utilização do PMO pelos projetos da organização.
Durante o processo de disseminação, deverão ser realizados treinamentos dos gerentes de
projetos e dos membros das equipes nos processos, padrões e métricas estabelecidos.
A última fase consiste na avaliação dos resultados obtidos e revisão dos processos, padrões
e metodologias estabelecidas de forma a ser iniciado um processo de melhoria contínua.
Existem diversos fatores críticos para que a implantação de um PMO possa ser bemsucedida. Alguns como patrocínio e apoio da gerência executiva já foram citados. Outros
fatores importantes são alinhamento com os objetivos do negócio e os papéis e
responsabilidades definidos. Mas o principal fator é adequação do modelo de PMO adotado
com a estrutura da empresa. Segundo Santosus (2003), deve-se inicialmente entender a
cultura da empresa, verificar os padrões da indústria e as melhores práticas e adaptá-los a
organização. Em outras palavras, não existe um modelo padrão e sim um modelo adequado
às necessidades da organização e que possa ser aperfeiçoado à medida que estas vão sendo
modificadas.
Rodrigues et al (2002) observam que a melhor abordagem para a implantação de um PMO
é por fases. À medida que a organização for aperfeiçoando seu nível de maturidade em
gerenciamento de projetos, o PMO pode evoluir em suas atribuições de modo a estar
sempre alinhado a estratégia da organização.
63
3
Metodologia
Este capítulo apresenta as justificativas para o tipo de pesquisa realizado e os métodos
utilizados a partir de diversos autores que discorrem sobre metodologia cientifica.
Para responder as questões da dissertação, o método escolhido será o estudo de caso
individual, já que as questões estão relacionadas com situações operacionais da área. O
método de estudo de caso é apontado como o mais apropriado para estudos centrados em
questões do tipo “que”, “como” e “porque” e quando o foco se encontra em fenômenos
contemporâneos inseridos em algum contexto da vida real (Yin, 2001). A unidade de
análise será a área de Tecnologia da Informação (TI) da Petrobras e sua trajetória desde
outubro de 2000.
A pesquisa desenvolvida pode ser classificada como descritiva, uma vez que tem por
objetivo identificar o nível de maturidade em gerenciamento de projeto existente nesta área
da Petrobras e o tipo de Escritório de Gerenciamento de Projetos mais adequado ao nível
identificado.
Para alcançar o objetivo desejado, foram realizadas pesquisas bibliográfica e documental
nos assuntos apresentados no referencial teórico e uma pesquisa de campo para coleta dos
dados primários.
64
3.1 Pesquisa Bibliográfica
Na pesquisa bibliográfica foram utilizados livros, artigos publicados em revistas científicas,
teses e dissertações sobre assuntos pertinentes ao assunto pesquisado. A Internet também
foi utilizada como instrumento de pesquisa bibliográfica, principalmente os sites relativos
aos institutos especializados em gerência de projetos e a institutos de pesquisa.
3.2 Pesquisa de Campo
3.2.1 Apresentação
A pesquisa de campo foi composta primeiramente por um estudo da TI da Petrobras desde
sua reestruturação ocorrida em outubro de 2000 até os dias de hoje. Procurou-se identificar
os motivos que levaram a TI a adotar o gerenciamento de projetos, as dificuldades
encontradas na implantação e como a gestão de projetos pode ajudar a TI a maximizar seu
valor a Petrobras. Esta parte da pesquisa foi composta por coleta de dados em diversas
fontes como: memorandos internos, documentos, apresentações e informações divulgadas
na Intranet. Foram distribuídos questionários aos profissionais da TI com o objetivo de
medir o grau de maturidade em que a área se encontra. A pesquisa foi composta também
por observação direta visto que a autora atua na área pesquisada desde 2001.
O nível de maturidade em gerenciamento de projetos da TI foi analisado a partir da
percepção dos gerentes de projetos. Na TI este profissional é nomeado como líder de
projeto, sendo deste modo identificado no questionário de pesquisa, podendo desempenhar
65
esta função tanto funcionários do sistema Petrobras quanto contratados, pessoas
empregadas de firmas terceirizadas que trabalham diretamente na TI.
Para determinar a escolha dos entrevistados, foram identificados os profissionais da TI que
exercem a função de líder de projeto. Foram enviados 180 questionários sendo obtidas 61
respostas consideradas válidas e completas, o que corresponde a 33,8% da amostra
pesquisada, sendo um índice considerado bastante satisfatório.
Como os lideres de projeto estão localizados em vários centros de atuação da TI da
Petrobras distribuídos pelo território nacional, os formulários para levantamento dos dados
foram enviados como anexos de uma mensagem de correio eletrônico. Um modelo deste
formulário é apresentado como anexo neste trabalho.
3.2.2 Estrutura do Formulário
Cada questionário foi dividido em três partes: a primeira com uma carta de apresentação da
pesquisa com a identificação da pesquisadora, a segunda com a identificação do pesquisado
e a terceira com perguntas relacionadas à gerência de projetos expressas utilizando-se a
escala Likert.
Na primeira parte do questionário foi apresentado o motivo de realização da pesquisa,
nome, e-mail e telefone da pesquisadora para retirada de dúvidas. Na segunda parte foram
solicitados nome e chave de identificação com preenchimento opcional e lotação completa
66
do pesquisado. Também foi perguntado se o mesmo era funcionário do sistema Petrobras
ou funcionário de uma empresa terceirizada.
Para cada uma das questões referentes à terceira parte foi apresentada uma afirmação sobre
o assunto a ser pesquisado, sendo solicitado ao pesquisado que respondesse segundo a uma
escala com as seguintes opções: 1-Discordo totalmente; 2-Discordo; 3-Não concordo nem
discordo; 4-Concordo e 5-Concordo totalmente.
As perguntas do segmento da pesquisa referente à gerência de projetos foram preparadas
tomando-se por base o modelo de maturidade de Kerzner apresentado no capítulo 2, item
2.5 deste trabalho. Este modelo foi adotado por permitir através de seus vários níveis ou
estágios avaliar como se encontra o grau de maturidade da organização e a partir desta
identificação, o modelo fornece orientações de como se realizar um planejamento
estratégico em gerenciamento de projetos para se alcançar os resultados desejados. É um
modelo que pode ser adaptado às necessidades da organização a ser avaliada, sendo um dos
mais representativos existentes na literatura.
A terceira parte do questionário de pesquisa foi dividida por seções para identificar o grau
de maturidade da organização em gerenciamento de projetos. As seguintes seções foram
identificadas:
• Institucional – Esta seção composta pela pergunta 1, visa identificar o
reconhecimento da organização da importância do gerenciamento de projetos.
67
• Suporte Gerencial – Esta seção, composta pelas perguntas 2 e 3, avalia o
reconhecimento por parte do corpo gerencial da importância de gerenciamento de
projetos para a organização e seu nível de conhecimento dos princípios de
gerenciamento de projetos.
• Treinamento e Desenvolvimento – Esta seção, composta pelas perguntas 4, 5 e 13,
examina o grau de reconhecimento da carreira de gerência de projetos, a existência
de um programa de treinamento formal na empresa, o incentivo da TI para que seus
funcionários participem e o grau de conhecimento em gerenciamento de projetos
das pessoas que atuam como gerentes de projetos .
• Metodologia e Processos – Esta seção, composta pelas perguntas 6 a 11, examina o
grau de adequação da organização aos princípios de gerenciamento de projetos
avaliando os processos e metodologias existentes.
• Autoridade e responsabilidade – Esta seção, composta pela pergunta 12, avalia se o
gerente de projeto possui autoridade suficiente para exercer seu papel. Autoridade e
responsabilidade são os princípios básicos para o que o gerente de projeto possa
desempenhar corretamente seu papel de gerenciar todos os recursos do projeto.
• Benchmarking- Esta seção, composta pelas perguntas 14 e 15, avalia se a empresa
realiza comparações entre seus projetos e com projetos de outras áreas da
organização ou de outras empresas.
68
A seguir será apresentada a explicação de cada pergunta do formulário.
• Reconhecimento da organização – com esta variável procura-se medir o nível de
reconhecimento da organização da necessidade da gestão de projetos.
O reconhecimento da organização da necessidade da gestão de projetos e da sua
importância é o primeiro passo no alcance da maturidade em gerenciamento de
projetos. Segundo Kerzner (2001b), as empresas finalmente reconheceram a
importância e ligação entre planejamento estratégico e o gerenciamento de projetos.
Estratégias são implementadas através de projetos e estes tem mais chances de serem
bem-sucedidos se forem executados através de um processo repetível e consistente. Ao
verificar se a organização reconhece a importância da gestão de projetos, procura-se
identificar se o primeiro passo no alcance da maturidade em gerenciamento de projetos
foi realizado.
• Reconhecimento do corpo gerencial - com esta variável procura-se medir o nível de
reconhecimento do corpo gerencial da necessidade da gestão de projetos.
Não somente a organização como também seu corpo gerencial deve reconhecer a
importância de gerenciamento de projetos. O suporte do corpo gerencial, incluindo
todos os níveis da gerência, é uma das bases para a implantação efetiva de
gerenciamento de projetos. O não reconhecimento dificulta a implantação, pois a
organização não vislumbra nenhum esforço do seu corpo gerencial tornando com isso
seu uso esporádico ou somente por algumas áreas.
69
• Conhecimento da gerência intermediária – esta questão busca avaliar o
conhecimento das gerências intermediárias, também conhecidas como gerentes de
linha, dos princípios de gerenciamento de projetos.
Os gerentes da organização devem não apenas reconhecer a importância do
gerenciamento de projetos como também conhecer seus princípios. Segundo o nível 2 Processos comuns, do modelo de maturidade de Kerzner, o suporte em gerenciamento
de projetos deve ocorrer em todos os níveis e este suporte inclui tanto o
reconhecimento da importância de gerenciamento de projetos quanto o conhecimento
de seus princípios.
• Existência do cargo de gerente de projeto – com esta variável procura-se verificar o
reconhecimento da carreira de gerenciamento de projetos pela organização
.
O reconhecimento da carreira de gerente de projeto é um passo importante na
implantação do gerenciamento de projetos. Por isso procurou-se identificar a existência
da carreira específica de gerenciamento de projetos na organização.
• Programa de treinamento em gerenciamento de projetos
Esta pergunta foi dividida em duas partes sendo solicitado ao pesquisado funcionário
da Petrobras que respondesse as questões a) e b) e ao pesquisado contratado de uma
firma terceirizada que respondesse a questão c).
70
§ Existência do programa de treinamento em gerenciamento de projetos – esta
variável avalia a existência de um programa de treinamento formal na
empresa.
A existência de um programa formal de treinamento em gerenciamento de
projetos demonstra a importância do gerenciamento de projetos para a
organização.
§ Participação dos funcionários no programa de treinamento - esta variável
complementa a pergunta anterior ao avaliar se os funcionários da Petrobras
que exercem a função de gerente de projetos são incentivados a participar do
programa de treinamento existente, permitindo o incremento de seus
conhecimentos e habilidades.
§ Existência do programa de treinamento em gerenciamento de projetos na
empresa contratada – esta variável avalia a existência de um programa de
treinamento em gerenciamento de projetos na empresa contratada.
• Metodologia única – esta variável procura identificar a existência de uma
metodologia única de gerência de projetos, conhecida por todos e efetivamente
utilizada.
A existência de uma metodologia única em gerenciamento de projetos, conhecida e
utilizada por todos é um dos principais passos na conquista da maturidade em
71
gerenciamento de projetos. A metodologia deve ser única, pois a existência de
várias metodologias compromete o uso das mesmas já que passam a ser utilizadas
por áreas separadas da organização dificultando sua integração. Desta forma
procurou-se identificar a existência de uma metodologia única na organização e se a
mesma estava suficientemente divulgada a ponto de ser conhecida pelos
pesquisados.
• Existência de planejamento – esta variável procura avaliar se os conceitos de
planejamento de projetos são utilizados
Avalia se os projetos desenvolvidos pela TI estão sendo realizados com
planejamento inicial das atividades e alocação dos recursos. Um planejamento das
atividades que serão realizadas em um projeto com a correta alocação dos recursos,
tanto humanos quanto materiais que serão utilizados, viabiliza uma correta previsão
dos custos e prazos que serão realizados.
• Gerência de riscos – esta variável procura identificar a utilização do gerenciamento
de riscos em projetos
Avalia se está sendo realizado o gerenciamento de riscos em projetos. O
gerenciamento de riscos é um dos principais itens em gerenciamento de projetos.
Segundo Kerzner (2001a), o gerenciamento de risco não-apropriado ou nãoadequado é uma das maiores causas para o fracasso de um projeto.
72
• Controle de mudanças - esta variável procura identificar a utilização de um processo
de controle de mudanças
Avalia a existência de um processo de controle de mudanças. A não existência de
um processo formal de controle de mudanças permite que sejam realizadas
mudanças no escopo do projeto que podem comprometer os prazos e custos
acordados levando ao fracasso do mesmo.
• Seleção dos projetos – esta variável procura identificar a existência de critérios para
a seleção dos projetos a serem desenvolvidos.
Avalia a existência de um critério de seleção dos projetos a serem desenvolvidos. Se
a organização realiza a seleção estratégica de projetos a serem desenvolvidos
segundo critérios como lucratividade, importância estratégica para o cliente,
alinhamento ao planejamento estratégico da organização, risco, tecnologia, etc.
Procura identificar se a organização realiza a seleção e priorização dos projetos a
serem desenvolvidos.
• Documentação das lições aprendidas – esta variável analisa se existe preocupação
da organização em documentar seus processos de forma a assimilar as lições
aprendidas.
73
O objetivo desta pergunta é avaliar se as lições aprendidas são documentadas de
forma a aumentar a eficácia e eficiência do processo. Assimilar as lições aprendidas
é uma forma de melhorar o processo para que os erros não se repitam.
• Autonomia dos gerentes de projetos – esta variável avalia se o gerente de projeto
possui plena autoridade para exercer seu papel.
Autoridade e responsabilidade são os princípios básicos para o que o gerente de
projeto possa desempenhar corretamente seu papel de gerenciar todos os recursos do
projeto incluindo recursos humanos e materiais.
• Conhecimento dos gerentes de projetos – esta variável procura identificar se os
gerentes de projetos possuem conhecimento adequado para realizarem seu papel
• Benchmarking interno – esta variável procura verificar se são realizadas
comparações entre os projetos executados pela TI.
• Benchmarking externo – esta variável procura verificar se são realizadas
comparações dos projetos executados pela TI com projetos de outras áreas da
companhia ou com projetos de outras empresas.
Segundo Silva (2003), aprender lições com os próprios erros é importante, mas é
necessário também aprender lições com os erros dos outros. Em outras palavras,
74
deve-se buscar comparar os resultados e lições dos projetos com os resultados de
outros projetos executados pela organização como também com outros projetos de
outras áreas ou com projetos de outras empresas. A realização de benchmarking é
um esforço contínuo de aprimoramento e evolução do processo de gerenciamento de
projetos.
3.3 Limitações do Método
A metodologia escolhida para esta pesquisa apresenta algumas limitações em relação à
coleta e o tratamento dos dados.
Segundo Silva (2003 apud Richardson 1999), a não obtenção de retorno de 100% da
amostra pode acarretar o surgimento de vieses importantes pois os respondentes podem não
ser os mais representativos dos grupos selecionados.
O método de observação direta se por um lado permite, devido maior facilidade de
obtenção de dados, um estudo mais aprofundado e abrangente da área a ser pesquisada, por
outro lado pode acarretar um viés na análise dos dados obtidos visto que a pesquisadora
encontra-se imersa no universo pesquisado.
75
4
Apresentação do Caso da Área de Tecnologia da Informação da Petrobras.
4.1 A Petrobras
4.1.1 Histórico
A Petróleo Brasileiro S.A (PETROBRAS) é uma empresa de economia mista criada em 3
de outubro de 1953, por meio da Lei 2.004, cujo principal acionista é o Governo Federal. A
empresa atua verticalmente 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.
A Petrobras iniciou suas atividades com o acervo recebido do antigo Conselho Nacional do
Petróleo (CNP), que manteve sua função fiscalizadora sobre o setor. Este acervo continha:
• Reservas recuperáveis de 15 milhões de barris;
• Campos de petróleo com capacidade de prospecção de 2700 barris por dia (bpd),
que correspondiam a 27% do consumo brasileiro;
• Refinarias de Mataripe (BA), atual Refinaria Landulfo Alves (RLAM) com
capacidade de processamento de 5000 bpd;
• Refinaria em fase de montagem, em Cubatão (SP), atual Refinaria Presidente
Bernardes (RPBC) que também incluía uma fábrica de fertilizantes;
• Mercado com consumo de derivados de 137.000 bpd, sendo maior parte
importados;
• Vinte petroleiros que podiam transportar 221mil toneladas.
76
Ao longo de cinco décadas, enfrentou uma série de desafios, tornando-se líder em
distribuição de derivados no País e colocando-se entre as quinze empresas maiores
petrolíferas na avaliação internacional.
Nos anos 50, com apoio político e financeiro do governo brasileiro, foi possível aumentar a
produção, ampliar o parque de refino, melhorar a capacidade de transporte e incrementar a
pesquisa. Ao final da década, a produção de petróleo já se elevava a 65 mil barris diários, as
reservas somavam 617 milhões de barris, enquanto as obras em andamento no setor
industrial prometiam, para a década seguinte, a auto-suficiência do parque de refino na
produção de derivados básicos.
No início dos anos 60, a Petrobras alcançou um de seus objetivos principais: a autosuficiência na produção dos principais derivados, com o início de funcionamento da
Refinaria Duque de Caxias (REDUC), no Rio de Janeiro. Somado a isso, dois importantes
marcos de produção foram alcançados nos anos 60: os 100 mil barris diários de produção,
em 1962, e a primeira descoberta de petróleo no mar, em 1968 levando a iniciar os estudos
para exploração em águas profundas.
Na década de 70, houve uma implosão no consumo interno impulsionado por altas taxas de
crescimento, além da crise do petróleo devido à elevação dos preços internacionais pela
Organização dos Países Exportadores de Petróleo (OPEP). Estes motivos levaram a
empresa a concentrar esforços para aumentar a participação do petróleo nacional no
consumo brasileiro, intensificando a pesquisa por novas jazidas e o desenvolvimento de
novas fontes de energia capazes de substituir os derivados do petróleo. Uma dessas
77
iniciativas foi a criação do Programa Nacional do Álcool com o incentivo do uso de álcool
carburante como combustível automotivo.
Na década de 80, o desafio foi atingir a produção de 500 mil barris por dia. Assim, as ações
foram direcionadas para o desenvolvimento da tecnologia para produção de petróleo em
águas profundas com participação crucial do seu Centro de Pesquisas e Desenvolvimento
(CENPES), criado em 1966 e atualmente o maior centro de pesquisas da América Latina.
Os esforços foram recompensados. Em 1988, a empresa superava seu próprio recorde
produzindo petróleo a 492 metros e em dezembro de 1989, a produção atingia a marca de
675.135 barris diários.
Na década de 90, a empresa intensificou a produção de petróleo na Bacia de Campos em
campos localizados em águas profundas. Em 1992 foi premiada pela primeira vez pela
Offshore Tecnology Conference (OTC) pela sua notável contribuição para o avanço da
tecnologia de produção em águas profundas. Prêmio recebido novamente em 2001.
Em 1997, o Brasil por meio da Petrobras, ingressou no seleto grupo de 16 países que
produzem mais de 1 milhão de barris de óleo por dia. Neste mesmo ano foi promulgada a
Lei 9.478 que regulamentou a emenda constitucional de flexibilização do monopólio estatal
do petróleo, abrindo as atividades da indústria petrolífera do Brasil à iniciativa privada.
(PETROBRAS, 2005)
Com a lei foram criados a Agência Nacional do Petróleo (ANP), encarregada de regular,
contratar e fiscalizar as atividades do setor e o Conselho Nacional de Política Energética, o
78
órgão formulador da política pública de energia. 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 de maior agilidade em decorrência da abertura do mercado
de petróleo no país e das 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).
Desde então a Petrobras dobrou sua produção e em 2003 ultrapassou a marca de 2 milhões
de barris de óleo e gás natural por dia. A previsão da empresa é que a auto-suficiência da
produção de petróleo seja alcançada em dezembro de 2005, quando atingirá a produção de
cerca de 1,85 milhão de barris diários, gerando com isso uma economia imediata de 3
bilhões de reais (PETROBRAS, 2005)
4.1.2 Estrutura Organizacional e Atividades Desempenhadas
A Petrobras atua em toda a cadeia produtiva da indústria de petróleo, desde a exploração
até a entrega de produtos derivados ao consumidor final passando pelo refino e
abastecimento. Em sua reestruturação ocorrida em 2000, foram definidas quatro áreas de
negócio (Exploração e Produção (E&P), Abastecimento, Gás e Energia e Internacional),
79
duas áreas de apoio (Financeira e Serviços) e as unidades corporativas ligadas diretamente
ao presidente, conforme apresentado na figura 13.
Figura 13. Organograma da Petrobras
Fonte: Petrobras (2005)
As unidades de negócio operam com mais autonomia nas decisões e independência para
gerir orçamento e investimento, tendo seu desempenho aferido por metas e
responsabilização por resultados.
80
A Área de Exploração e Produção é responsável pela pesquisa, localização, identificação,
desenvolvimento, extração, produção e incorporação de reservas de óleo e gás natural. Este
conjunto de atividades é denominado, no ramo da indústria de petróleo de Upstream.
Possui tecnologia própria para exploração em águas profundas que é considerada como o
estado da arte em prospecção em águas profundas e ultra-profundas.
A Área de Abastecimento é responsável pelas atividades de refino, transporte e
distribuição, atividades denominadas como Downstream.
• Refino - responsável pelo processamento da produção de óleo no Brasil, vem
buscando se adaptar às mudanças de mercado, batendo seguidos recordes de
produção e expandindo suas atividades na América Latina.
• Transporte – atividade desempenhada por uma subsidiária, a Petrobras
Transporte S.A (Transpetro), fornece serviços de transporte e armazenagem de
óleo e gás, tanto no mercado interno, quanto no mercado externo.
• Distribuição – atividade desempenhada por uma subsidiária, a Petrobras
Distribuidora S.A (BR), é responsável pela distribuição de derivados de petróleo
para diversos segmentos da indústria como o automotivo, marítimo, ferroviário
e aviação.
81
A Área de Gás e Energia abrange atividades relativas ao desenvolvimento de produtos que
substituem outros derivados de petróleo, a um custo menor e sem restrições ambientais,
sendo responsável pela comercialização do gás natural nacional e importado.
A Área Internacional é responsável pelo desenvolvimento de diversas atividades no exterior
como a exploração e compra e vendas de petróleo, tecnologia, equipamentos, materiais e
serviços.
As áreas de apoio prestam suporte a toda a companhia, sendo que a área Financeira possui
um papel mais consultivo e consolidador. Enquanto que a área de Serviços possui um
intenso contato com as demais áreas da companhia atuando como uma área de suporte e
buscando prover soluções que agreguem resultados às atividades da Companhia. Dentro da
área de Serviços, destacamos o órgão de Tecnologia da Informação, objeto do estudo deste
trabalho.
Desde 2000, o modelo foi sendo aprimorado com as áreas sofrendo alguns ajustes, sem
porém alterar as diretrizes da reestruturação.
82
4.1.3 A empresa em números
A Petrobras apresenta os seguintes dados nas áreas de exploração, produção, abastecimento
entre outros:
Tabela 10. A Petrobras em números – dados referentes ao ano de 2004
RECEITAS (R$ mil)
R$ 108.201.479
LUCRO LÍQUIDO (R$ mil)
R$ 17.860.754
INVESTIMENTOS (em bilhões de reais)
R$ 21,8
ACIONISTAS
161.143
EXPLORAÇÃO
50 sondas de perfuração (31 marítimas)
4
RESERVAS (CRITÉRIO SEC )
11,85 bilhões de barris de óleo e gás
equivalente (boe)
POÇOS ATIVOS
13.821 (665 marítimos)
PLATAFORMAS DE PRODUÇÃO
98 (72 fixas; 26 flutuantes)
PRODUÇÃO DIÁRIA
1.661 mil barris por dia - bpd de petróleo e
LGN
359 mil barris de gás natural
REFINARIAS
16
RENDIMENTO DAS REFINARIAS
1.797 mil barris por dia – bpd
DUTOS
30.318 km
FROTAS DE PETROLEIROS
120 (46 de propriedade da Petrobras)
POSTOS
6.154 Ativos (631 próprios)
FERTILIZANTES
2 Fábricas: 1.852 toneladas métricas de
amônia e 1.598 toneladas métricas de uréia
Fonte: Petrobras (2005)
4
Critério SEC – Critério da U.S. Securities and Exchange Commission. Diz respeito ao volume de óleo cuja
recuperação será economicamente viável. É o mais adequado em termos de análise econômica (GasNet, 2005)
83
4.2 A Tecnologia da Informação
4.2.1 Histórico
A Tecnologia da Informação - TI é a denominação atual do órgão central de tecnologia da
informação da Petrobras. A existência de uma estrutura central de informática na Petrobras
data da década de 60, quando o então Serviço de Organização e Métodos (SEORG) tinha
como responsabilidade a gestão da organização e administração dos serviços de informática
em toda a Petrobras. O SEORG era o órgão responsável pelo planejamento, controle e
execução das atividades de processamento de dados corporativos. Por dados corporativos
entenda-se processamento de folha de pagamento, processamento contábil/financeiro e
comercial. Os processamentos científicos, relacionados às atividades de exploração e
produção de petróleo, não eram de responsabilidade do SEORG. Aliado a isto, cada órgão
da empresa podia ter sua própria área de processamento de dados, sendo responsável por
operar seus próprios sistemas e serviços.
Em 1979, o SEORG deu origem ao Serviço de Processamento de Dados (SEPROD),
responsável exclusivamente pela administração e fornecimento dos serviços de informática.
Em 1990, o SEPROD foi substituído pelo Serviço de Informática (SERINF), através da
fusão das atividades de informática e telecomunicações em um único órgão. O SERINF
passou a fornecer os serviços de desenvolvimento de sistemas de informação, incluindo
modelos de apoio à decisão e gerência dos serviços de informática. Além das atribuições da
área de informática, foram incorporados os processos de gerência de serviços de
telecomunicações e projetos de engenharia de telecomunicações.
84
Como parte do processo de revisão organizacional da Petrobras, em abril de 2000 foi
aprovada pela diretoria a criação da unidade de Tecnologia da Informação (TI),
desmembrando novamente as atividades de informática e telecomunicações. No período de
maio a julho de 2000, foi elaborada uma nova estrutura organizacional para a área recémcriada. Esta nova estrutura surgiu com a necessidade do alinhamento da estratégia da
tecnologia da informação às estratégias de negócio da Companhia e com a constatação do
nível elevado de gastos em informática de toda a Empresa. Somada a esta constatação, a
descentralização de funções acarretava uma série de problemas como:
• Redundância de recursos: os recursos de informática eram comprados ou
contratados segundo as necessidades locais, ocasionando perdas de escala em
contratações e maior necessidade de espaço físico;
• Falta de padronização: as características dos equipamentos, programas de
computador e as metodologias para desenvolvimento de projetos de informática
variavam bastante entre os diversos órgãos;
• Dificuldade de acesso às informações: havia uma grande dificuldade em integrar as
informações dos diversos órgãos, devido à ausência de padronização, dificultando a
comunicação entre as diversas áreas.
85
A estrutura organizacional da TI era composta pelos seus três centros: Rio de Janeiro, São
Paulo e Bahia, atendendo principalmente as áreas corporativas. As áreas de negócio
continuavam a possuir suas próprias áreas de informática.
Visando otimizar suas operações e aumentar a satisfação dos seus clientes, a TI realizou
uma redefinição de seus processos e mapeamento da cadeia de valor, com o objetivo de
eliminar redundâncias e sobreposição de tarefas. A cadeia de valor é apresentada na figura
abaixo, sendo que as definições dos macro-processos são apresentadas no anexo II.
Figura 14. Cadeia de Valor da TI em 2001
Fonte: SINPEP (2005)
Com a instituição do modelo de processos padronizados em seus três centros, a TI passou
por um novo desafio: a obtenção da certificação ISO 9001:2000. Em julho de 2002, a TI
obteve essa certificação, dos seus serviços de Prover Soluções, Apoiar Usuários, Gerir
Relacionamento com os Clientes e Gerir Infra-estrutura conforme os macro-processos
vistos anteriormente.
86
4.2.2 Função TI
Como desdobramento da revisão da estratégia da empresa, no final de 2002, iniciou-se
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 área de informática aos objetivos de negócios da Petrobras. Como resultado
desta estratégia teve início o processo de centralização das atividades de informática. Este
processo foi nomeado como Função TI. Foram integradas a TI Corporativa, as atividades
da Tecnologia da Informação da Exploração e Produção (TI-E&P) Sede, Unidade de
Negócios Bacia de Campos (UN-BC) e Unidade de Negócios Rio (UN-RIO). Com a
integração da TI-E&P foi adicionado à cadeia de valor da TI, um novo macro-processo
específico para atendimento às unidades de negócios do E&P, Gerir Informação Técnica,
que consiste na coleta, processamento, divulgação, recuperação e disponibilização das
informações e documentos técnicos para o E&P.
Uma das conseqüências da incorporação das atividades e órgãos de informática das demais
áreas da companhia foi a necessidade de se reajustar a estrutura organizacional da TI.
Iniciou-se então, o processo de reestruturação da TI com o envolvimento das diversas áreas
da companhia. Como parte deste processo, foi realizada uma pesquisa constituída de
entrevistas com os clientes da TI, pertencentes a diversas áreas da empresa. Como resultado
desta pesquisa, constatou-se que apesar dos esforços na definição de uma estratégia com
foco no Cliente, estes ainda não se sentiam plenamente atendidos. A visão dos clientes em
relação a TI era que existia uma grande duplicação de atividades e responsabilidades, e que
não possuía foco no cliente. Por outro lado verificou-se uma grande fidelidade dos clientes
87
a TI, apesar de poderem contratar serviços de tecnologia da informação de empresas
externas.
Como resultado do processo de reestruturação, um novo modelo de gestão e uma nova
estrutura organizacional da TI foram desenhados tendo como principais objetivos aumentar
a eficiência e agilidade e tornar a TI um parceiro estratégico de negócio. A nova estrutura,
implantada em janeiro de 2004, é baseada em uma matriz de posicionamento estratégico
com os seguintes quadrantes:
Figura 15. Matriz de Posicionamento Estratégico da TI
Excelência
Gestão
Serviços
Agilidade
Papel
Estratégico
Operacional
Tecnologia
Foco
Negócio
Fonte: TI (2005)
• Gestão: orientado ao alinhamento com os imperativos de negócio e maximização
do valor agregado pela TI;
• Excelência: orientado ao desenvolvimento de conhecimento de novas tecnologias
de informação apropriadas para o negócio dos clientes;
88
• Serviços: orientado à excelência operacional dos serviços prestados associados a
uma gestão eficiente dos ativos de infra-estrutura de TI;
• Agilidade: orientado ao conhecimento dos processos de negócios dos Clientes de
modo a possibilitar o pronto atendimento às suas necessidades, oferecendo soluções
que agreguem valor ao negócio.
4.2.3 Missão, Visão e Valores da Tecnologia da Informação
Após a reestruturação, houve revisão da Missão, Visão e Valores da área da Tecnologia da
Informação, definidas da seguinte forma:
A Contribuição da TI para a Missão da Companhia: Prover serviços e soluções de
tecnologia da informação voltados à excelência estratégica e operacional e à integração dos
processos de negócio, com qualidade, agilidade, segurança e ética.
A Contribuição da TI para a Visão da Companhia: Ser agente de maximização do valor que
as soluções de TI agregam ao Sistema Petrobras.
Valores da TI:
• Comprometimento com os objetivos da Petrobras;
• Valorização das pessoas;
• Integração e cooperação;
• Ética e responsabilidade social;
89
• Excelência, agilidade e segurança.
Fonte: TI (2005)
4.2.4 Organização Geral da TI da Petrobras
Para facilitar o entendimento da estrutura organizacional da TI, a mesma foi sub-dividida
em quadrantes, conforme figuras a seguir:
4.2.4.1 Excelência
A figura a seguir, exibe a estrutura organizacional do quadrante de Excelência:
Figura 16. Estrutura Organizacional do Quadrante de Excelência
Fonte: TI (2005)
Este quadrante possui as seguintes políticas:
• Adoção pelas áreas de serviço e agilidade de arquiteturas tecnológicas aprovadas
pela TI;
90
• Estudo de tecnologias com aplicação direta em soluções de negócio;
• O conjunto de arquiteturas, diretrizes e padrões para os produtos e serviços de TI na
companhia devem seguir referenciais de mercado;
• Busca do uso efetivo de meta-dados visando à integração e o re-uso de
componentes;
• Sistematização da rede de competências de profissionais especialistas em TI da
Companhia.
4.2.4.2 Gestão
A figura a seguir, exibe a estrutura organizacional do quadrante de Gestão:
Figura 17. Estrutura Organizacional do Quadrante de Gestão
Fonte: TI (2005)
91
Este quadrante possui as seguintes políticas:
• Evitar a proliferação de diferentes soluções para um mesmo objetivo;
• Ter foco permanente na melhoria da ambiência;
• Seguir os padrões de qualidade do mercado para o gerenciamento de níveis de
serviço e otimização de recursos de infra-estrutura;
• Prestar contas aos clientes da TI através de processo simples, claro e objetivo
negociados de forma única;
• Buscar as fontes mais adequadas no provimento de produtos e serviços, com
contratação de serviços, consolidação de contratos, regionalização de fornecimento
e foco nas atividades mais valiosas para a companhia;
• As áreas e unidades de negócio devem participar do estabelecimento de metas para
o sistema de conseqüências da TI;
• Os projetos de TI devem ser gerenciados segundo uma metodologia única;
• Atuar nas áreas de negócio em conformidade com as práticas administrativas de
cada área;
• As medidas de desempenho de TI devem estar alinhadas com as métricas
empresariais da companhia.
92
4.2.4.3 Agilidade
A figura a seguir, exibe a estrutura organizacional do quadrante de Agilidade:
Figura 18. Estrutura Organizacional do Quadrante de Agilidade
Fonte: TI (2005)
93
Este quadrante possui as seguintes políticas:
• Manter as organizações de TI nos segmentos de negócio, visando o suporte aos
processos específicos de negócio;
• O processo decisório da TI deve estar próximo ao cliente para aumentar a agilidade;
• Propor soluções que mantenham o alinhamento com o negócio, garantindo a maior
contribuição para a companhia;
• O processo de provimento de soluções deve sempre seguir os padrões tecnológicos
da TI, mesmo quando houver desenvolvimento externo;
• Todo projeto de TI deve ter um cliente como responsável principal e com o nível de
competência para assumir compromissos compatíveis com os custos do
empreendimento;
• Manter os especialistas em soluções próximos aos respectivos usuários gestores;
• Prover soluções de forma integrada, internamente e com os clientes;
• Priorizar a aplicação de seus recursos nas soluções que representem diferenciação
competitiva para a Companhia.
4.2.4.4 Serviços
A figura a seguir, exibe a estrutura organizacional do quadrante de Serviços:
Figura 19. Estrutura Organizacional do Quadrante de Serviços
94
Fonte: TI (2005)
Este quadrante possui as seguintes políticas:
• No processo de provimento de soluções, a TI deve priorizar as soluções existentes
no mercado;
• Minimizar a adequação de pacotes adquiridos no mercado;
• Avaliar sistematicamente a opção de terceirização para atividades operacionais;
• Os serviços de TI devem ser regularmente acompanhados, avaliados e comparados
com referenciais de excelência do mercado;
• As operações de TI devem ser realizadas visando os ganhos de escala, a eficiência e
os níveis de serviço acordados;
95
• A infra-estrutura de TI deve ser provida de forma segura e compatível com a
arquitetura tecnológica padrão.
4.2.5 Situação atual
Face ao que foi exposto anteriormente, podemos verificar que desde da mudança da
estrutura organizacional da Petrobras e, consequentemente, a criação da área da Tecnologia
da Informação, a expectativa da atuação da TI foi modificada. A TI deixou de ser
originalmente vista como atividade de suporte aos processos administrativos (Recursos
Humanos, Contabilidade, etc) que apoiavam a operação da empresa passando a ser vista
como parte integrante do negócio, responsável por prover soluções que apóiem os
processos de negócio estratégicos da empresa. Isto confirma o observado por Fagundes
(2005). Segundo o autor, atualmente nenhuma grande empresa consegue se destacar sem o
apoio de uma forte área de sistemas de informações. Cada vez mais, o negócio fim da
empresa é dependente da tecnologia da informação.
Com a reestruturação, as áreas de informática que antes estavam vinculadas às diversas
áreas da empresa foram incorporadas à nova estrutura da TI (TI-AB, refino e
comercialização; TI-G&E, Gás & Energia; TI-INTER, Área Internacional). A nova
estrutura organizacional é o resultado da mais abrangente reorganização da área de TI na
Companhia.
Com a centralização de toda a área de informática a TI viu-se diante de um novo cenário,
pois passou a atender todos os tipos de serviços (Apoio ao Usuário, Infra-estrutura,
96
Consultoria e Provimento de Soluções, Prospecção de Tecnologias) para todas as áreas da
Empresa. Com a integração a TI triplicou seu número de funcionários, passando para quase
4.000 pessoas, sendo aproximadamente 1.200 empregados Petrobras e o restante da força
de trabalho terceirizada.
O grande desafio da reestruturação foi centralizar, em uma mesma área, tanto o suporte a
operação da empresa, por meio das atividades essenciais de tecnologia da informação como
apoio ao usuário e serviços de infra-estrutura quanto à identificação de soluções de
tecnologia da informação com potencial de aprimorar o negócio da Petrobras. Para isso a TI
teve sua estrutura organizacional dividida em duas principais áreas ou quadrantes:
§ Agilidade, estruturada em gerências separadas por áreas de negócio, tendo em
cada gerência profissionais conhecedores dos processos de negócios dos clientes
podendo com isso apresentar soluções que agreguem resultados às atividades da
Companhia
§ Serviços, dividida em seis centros de atendimento, todos atendendo demandas
solicitadas por qualquer gerência da Agilidade e podendo utilizar fornecedores
externos no desenvolvimento dos produtos e serviços solicitados.
A necessidade de uma gestão de projetos padronizada tornou-se premente, pois a TI passou
a ter diversas áreas internas e parceiros externos atuando no desenvolvimento e suporte de
seus produtos e serviços.
Como as diversas áreas incorporadas trabalhavam de forma distintas, algumas já utilizando
conceitos de gerenciamento de projetos, iniciou-se a padronização dos processos de
97
desenvolvimento de projetos com a adoção de uma ferramenta única para o
acompanhamento e realização dos projetos. Esta ferramenta, nomeada como Gestão
Integrada de Demandas (GID), foi implantada em setembro de 2004 e ainda não está sendo
utilizada por toda a TI. Apesar de ter sido constatada a necessidade de priorização e seleção
de projetos a serem desenvolvidos, foi adotada a estratégia de inicialmente concentrar a
realização de todos os projetos desenvolvidos em um local único para depois ter início a
implantação do processo de priorização. Na área de Serviços, optou-se por estender o
modelo de processos padronizados já existente nos centros do Rio de Janeiro, São Paulo e
Bahia para os outros centros.
Com a mudança organizacional ocorrida em 2000 na Petrobras iniciaram-se os estudos para
implantação de um Sistema de Gestão Integrada (ERP - Enterprise Resource Planning) na
companhia. O sistema ERP tem como proposta concentrar em uma única base todo o
conhecimento padrão dos processos principais de operação de uma empresa (Recursos
Humanos, Materiais, Financeiro, Vendas) podendo ser adequado às necessidades
específicas da mesma.
O projeto de implantação do ERP no sistema Petrobras, chamado Projeto Sinergia foi
criado em março de 2000, depois de estudos de viabilidade, tendo início com a adequação
do sistema às necessidades da companhia. O Projeto Sinergia foi estruturado nos mesmos
moldes do modelo Agilidade/Serviços. Uma área, chamada funcional, responsável pela
definição junto aos profissionais das áreas de negócio do grau de adequação do sistema e de
soluções específicas, como por exemplo, Logística de transporte e integração com o Banco
98
de Dados de Equipamentos de Movimentação e Qualidade (BDEMQ) da empresa. E outra
área responsável pela infra-estrutura, apoio e desenvolvimento das soluções especificadas.
O sistema ERP integra no sistema Petrobras as operações dos processos de Vendas e
Distribuição (SD), Gestão de Materiais e Serviços (MM), Planejamento da Produção (PP),
Gestão da Qualidade (QM), Manutenção e Inspeção (PM), Recursos Humanos (HR),
Gestão Financeira (FI), Controladoria (CO), Gestão de Ativo Fixo (AM) e Gestão de
Empreendimentos (PS). Sua implantação foi realizada em etapas, sendo implantado na BR
Distribuidora em julho de 2002 , na Refinaria Alberto Pasqualini (Refap) em julho de 2004
e em todo o sistema Petrobras em 4 de outubro de 2004, concretizando uma das maiores
implantações de um sistema integrado de gestão no mundo. Foram investidos em torno de
US$ 260 milhões e a estimativa é que a empresa tenha, em um prazo de cinco anos, uma
economia de cerca de US$ 450 milhões, principalmente nas atividades de exploração e
produção, manutenção, comercialização, gestão de estoques, compra de bens e serviços e
gestão de empreendimentos. (SINERGIA, 2005)
Dentre os diversos benefícios econômicos e estratégicos vislumbrados com a implantação
de um sistema de gestão integrada, podemos destacar: disponibilidade de informações em
tempo real e em um único sistema, possibilitando melhores condições de gerenciamento;
padronização de procedimentos e agilização do processo decisório.
A TI também está sendo impactada por fatores externos à companhia, em conseqüência de
sua estratégia de internacionalização e abertura de capital. A Lei Sarbanes-Oxley (SOX) foi
promulgada em 25 de julho de 2002 após os escândalos na bolsa americana envolvendo
grandes empresas como: Enron, WorldCom, Adelphia, Tyco, etc. Estes escândalos
99
abalaram a credibilidade do mercado de capitais americano e provocaram a falência de
várias empresas. A lei SOX surgiu com objetivo de reverter a imagem do mercado de
capitais, buscando promover a transparência, eqüidade (fairness), prestação de contas e
responsabilidade corporativa das empresas com ações negociadas na bolsa americana.
A aderência à SOX implica em assegurar que os processos de negócio associados às
atividades primárias da cadeia de valor da companhia atendem aos requisitos de governança
corporativa5 e são suportados por aplicações seguras de TI. Os requisitos mínimos de
governança corporativa são baseados na tríade: transparência, prestação de contas
(accountability) e eqüidade. Essa tríade requer que nas diretrizes de gestão da empresa o
Conselho de Administração, representante dos proprietários do capital (acionistas ou
cotistas), exerça seu papel na organização, que consiste em: estabelecer estratégias para a
empresa, eleger a Diretoria, fiscalizar e avaliar o desempenho da gestão e escolher a
auditoria independente. Grande parte dos problemas ocorridos nas empresas são
decorrentes de abusos de poder (do acionista controlador sobre minoritários, da Diretoria
sobre o acionista ou dos administradores sobre terceiros), erros estratégicos (decorrentes de
muito poder concentrado em uma única pessoa, normalmente o executivo principal) ou
fraudes (uso de informação privilegiada em benefício próprio, atuação em conflito de
interesses). (IBCG,2005)
5
Governança corporativa é o sistema pelo qual as sociedades são dirigidas e monitoradas, envolvendo os
relacionamentos entre Acionistas/Cotistas, Conselho de Administração, Diretoria, Auditoria Independente e
Conselho Fiscal. As boas práticas de governança corporativa têm a finalidade de aumentar o valor da
sociedade, facilitar seu acesso ao capital e contribuir para a sua perenidade. (IBGC,2005)
100
A lei enfoca a importância da organização possuir controles que garantam o atendimento
aos requisitos de governança, tornando explícita a responsabilidade dos CEO (Chief
Executive Office – Diretor Executivo) e do CFO (Chief Financial Office – Diretor
Financeiro) pela existência e adequado funcionamento das estruturas de controle sob risco
de penas de reclusão de até 20 anos.
A Petrobras possui ações na bolsa de Nova York desde agosto de 2000, estando desde 2002
compromissada com os princípios da lei SOX. A TI como órgão de tecnologia da
informação da Petrobras é responsável pelos sistemas que dão apoio aos processos de
negócios essenciais da Petrobras que também serão auditados. No que diz respeito, a
auditoria de sistemas de informação a lei SOX indica o CobiT.6 Segundo Fagundes (2005),
o CobiT é orientado ao negócio e fornece informações detalhadas para gerenciar processos
baseados em objetivos de negócio. É composto por 34 processos dividido em quatro
domínios: planejamento e organização, aquisição e implementação, entrega e suporte e
monitoração. Os conceitos de gerenciamento de projetos do PMBoK permeiam os
domínios do CobiT, principalmente nas disciplinas de gerência de projetos, gerenciamento
de riscos e controle de mudanças de escopo.
Para dimensionar o esforço da TI para adequação ao SOX, foi realizado levantamento dos
sistemas de informação existentes que dão suporte aos processos de negócio essenciais da
empresa. Nesta primeira avaliação, foram identificados cerca de 35 sistemas. Dos sistemas
identificados, a grande maioria tem como clientes, áreas de negócio como Finanças,
Contabilidade, E&P e Abastecimento. As aplicações desenvolvidas após a certificação de
6
CobiT – Control Objectives for Information and related Tecnologies (Objetivos de Controle para
Informação e Tecnologias relacionadas), guia para gestão de TI recomendado pelo ISACF (Information
Systems Audit and Control Foundation – Associação de Controle e Auditoria de Sistemas de Informação).
101
processos obtida em julho de 2002, estão quase em sua totalidade aderentes à SOX, porém
as aplicações legadas (aplicações desenvolvidas antes desta data), cerca de 75% das
aplicações identificadas na avaliação, requerem grande esforço extra em sua adequação. Na
avaliação dos processos de desenvolvimento de sistemas da TI, em relação às práticas
recomendadas pelo CobiT, poucos pontos de melhoria foram recomendados. Este fato ficou
evidenciado com a avaliação do domínio de aquisição e implementação do CobiT quando
dos 175 itens avaliados em menos de 10% foram indicados alguns pontos de melhoria.
Os diversos fatores apresentados nos mostram que somente com uma gestão de projetos
padronizada que permita o planejamento e acompanhamento de seus projetos é que a TI
conseguirá atender a todas as expectativas tanto internas, sendo uma parceira estratégica e
provendo soluções que agreguem resultados às atividades da Companhia, quanto externas,
através da aderência à SOX. Isto vai ao encontro do destacado por Kerzner (2002).
Segundo ele, dentre as principais motivações que levam uma empresa a adotar o
gerenciamento de projetos encontram-se o atendimento às expectativas dos clientes e a
fatores externos.
Em 1 de julho de 2005, houve uma reorganização da estrutura organizacional da TI com a
incorporação do projeto Sinergia. Esta integração tem como objetivo consolidar a visão da
Tecnologia da Informação no sistema Petrobras. A nova estrutura organizacional está
prevista para durar apenas um ano, e encontra-se em fase de avaliação de seu
funcionamento. Por este motivo, esta nova estrutura organizacional não será objeto de
102
estudo desta dissertação. A mesma terá, como objeto de estudo, a estrutura organizacional
da TI da Petrobras que vigorava até 30 de junho de 2005.
103
5
Resultados e Análise da Pesquisa do Nível de Maturidade em Gerenciamento de
Projetos
Conforme apresentado no capítulo 4, a TI para atender demandas solicitadas pelos seus
clientes foi estruturada organizacionalmente em duas áreas: Agilidade, responsável pelo
contato com o cliente e Serviços, responsável pelo desenvolvimento do produto solicitado.
Desta forma foram criados dois responsáveis, um em cada área, conforme atribuições a
seguir:
O Líder de Projeto, encontra-se nas gerências do quadrante Agilidade, sendo responsável
por:
• Elaborar o plano de projeto, criando a estrutura analítica do trabalho, com os
produtos que compõem o projeto;
• Gerenciar os riscos, prazos, custos e recursos do projeto junto ao cliente;
• Gerenciar o escopo do projeto, interagindo com o cliente nas solicitações de
mudança do projeto.
• Gerenciar as solicitações de mudanças do projeto, interagindo com o cliente;
• Obter as validações e aceites dos produtos do projeto junto ao cliente.
O Líder de Produto, encontra-se nas gerências do quadrante de Serviços, tem as seguintes
responsabilidades:
• Estabelecer o plano para construção do produto, criando uma estrutura analítica do
trabalho com as fases, iterações e sub-produtos;
• Executar o plano de projeto para a construção do produto;
104
• Controlar os recursos, prazos e custos acordados com o Líder de Projeto para a
execução e entrega do produto;
• Reportar ao Líder de Projeto os possíveis desvios e riscos atrelados à construção do
produto;
• Garantir a qualidade do produto entregue;
• Garantir a manutenibilidade e documentação do produto entregue.
Fonte (SINPEP, 2005)
O Líder de Projeto possui as responsabilidades correspondentes a um Gerente de Projeto. O
Líder de Produto é o Responsável Técnico, pertence a equipe de projeto sendo responsável
pelo desenvolvimento do produto. Por este motivo a pesquisa de levantamento do nível de
maturidade de gerenciamento de projeto foi realizada com os líderes de projeto nas
gerências do quadrante de Agilidade.
5.1 Resultados da pesquisa
Os dados oriundos dos formulários recebidos foram lançados no programa Excel da
Microsoft para tratamento e realização da análise estatística. Os resultados de cada questão
serão apresentados nesta seção, sendo realizada a interpretação dos resultados obtidos no
próximo item deste trabalho.
105
5.1.1 Distribuição das freqüências
De forma a melhor analisar os dados obtidos, estes foram consolidados. A tabela abaixo
apresenta os números de observações obtidas para cada variável.
Tabela 11. Distribuição das freqüências
Não
concordo
nem
Discordo
Concordo
totalmente
Discordo
discordo
Concordo
totalmente
Total
Reconhecimento da Organização
1
3
1
29
27
61
Reconhecimento do corpo gerencial
0
4
13
25
19
61
Conhecimento da gerência intermediária
1
3
10
25
22
61
Existência do cargo de gerente de projeto
10
19
21
6
5
61
4
4
12
14
2
36
2
2
12
9
4
29
contratada
8
8
5
3
1
25
Metodologia única
6
26
18
9
2
61
Utilização da metodologia
13
22
18
7
1
61
Gerência de riscos
9
19
21
9
3
61
Controle de mudanças
3
20
21
13
4
61
Seleção dos projetos
11
15
23
8
4
61
Documentação das lições aprendidas
10
26
16
7
2
61
Autonomia dos gerentes de projetos
11
23
16
11
0
61
Conhecimento dos gerentes de projetos
1
12
29
18
1
61
Benchmarking interno
7
22
21
10
1
61
Benchmarking externo
11
28
16
5
1
61
Variáveis
Existência do programa de treinamento em
gerenciamento de projetos
Participação dos funcionários no programa de
treinamento
Existência do programa de treinamento em
gerenciamento de projetos na empresa
106
Partindo desta tabela é possível observar que as respostas dos respondentes tendem a se
dividir basicamente entre os que não concordam com as afirmações apresentadas e aqueles
que se posicionam de forma neutra sem concordar nem discordar.
As variáveis Reconhecimento da Organização, Reconhecimento do corpo gerencial e
Conhecimento da gerência intermediária obtiveram um número expressivo de respostas
positivas (Concordo e Concordo totalmente). Deve se destacar que estas variáveis
compõem o segmento da pesquisa relativo às seções Institucional e Suporte gerencial.
O gráfico foi baseado nos valores apresentados na tabela 11 e apresenta a distribuição de
freqüências de cada resposta da pesquisa.
Figura 20. Gráfico de distribuição de freqüências das respostas
Distribuição de frequências
35
30
25
Discordo Totalmente
20
Discordo
Não concordo nem discordo
15
Concordo
Concordo totalmente
10
5
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
107
O gráfico mostra a predominância de respostas positivas (Concordo e Concordo totalmente)
para as três primeiras afirmações e a predominância de respostas que discordam com as
afirmativas apresentadas nas outras questões.
5.2 Interpretação dos Resultados por seções da pesquisa
5.2.1 Análise das variáveis referentes à seção Institucional
Questão 1: A TI, como órgão de Tecnologia da Informação da Petrobras, reconhece a
necessidade da gestão de projetos
Figura 21. Gráfico de distribuição das respostas da questão 1
Questão 1 - Reconhecimento da organização
2%
5%
Discordo totalmente
2%
Discordo
44%
Não concordo nem discordo
47%
Concordo
Concordo totalmente
108
O alto percentual (91%) de respostas positivas (Concordo e Concordo totalmente) na
variável Reconhecimento da organização indica uma percepção da importância do
gerenciamento de projetos para a TI. Esta importância pode ser confirmada na própria
política da organização e na participação da TI como patrocinadora em diversos eventos
ligados a gerenciamento de projetos, como por exemplo, os eventos coordenados pela seção
PMI-Rio de Janeiro entre outros. A organização estimula a participação de funcionários e
contratados nestes eventos.
5.2.2 Análise das variáveis referentes à seção Suporte Gerencial
Questão 2: A necessidade da gestão de projetos é reconhecida em todos os níveis da
gerência, incluindo a gerência executiva
Figura 22. Gráfico de distribuição das respostas da questão 2
Questão 2 - Reconhecimento do corpo gerencial
0% 7%
31%
21%
Discordo totalmente
Discordo
Não concordo nem discordo
Concordo
Concordo totalmente
41%
109
O alto número de respostas positivas (Concordo e Concordo totalmente) na variável
Reconhecimento do corpo gerencial indica a percepção do corpo gerencial da importância
do gerenciamento de projetos para a TI. Este resultado está em conformidade com o
resultado apresentado na questão 1, demonstrando desta forma, o alinhamento das
percepções do corpo gerencial e da organização como um todo.
Questão 3: Meu gerente/coordenador conhece os princípios de gerenciamento de projetos
Figura 23. Gráfico de distribuição das respostas da questão 3
Questão 3 - Conhecimento da gerência intermediária
2% 5%
16%
Discordo totalmente
36%
Discordo
Não concordo nemdiscordo
Concordo
Concordo totalmente
41%
O percentual (77%) de respostas positivas (Concordo e Concordo totalmente) nessa
variável indica que o corpo gerencial da TI conhece os conceitos de gerenciamento de
projetos.
O percentual de respostas neutras (Não concordo nem discordo) em ambas as variáveis,
21% e 16% respectivamente, indicam que o trabalho de conscientização do corpo gerencial
em relação à importância do gerenciamento de projetos ainda não está completo, sendo um
ponto de atenção para a TI.
110
5.2.3 Análise das variáveis referentes à seção Treinamento e Desenvolvimento
Questão 4: Existe uma carreira específica para gerente de projeto na TI.
Figura 24. Gráfico de distribuição das respostas da questão 4
Questão 4 - Existência do cargo de gerente de
projeto
8%
16%
10%
Discordo totalmente
Discordo
Não concordo nem discordo
31%
35%
Concordo
Concordo totalmente
As respostas desta variável mostram uma contradição quanto à percepção da carreira de
gerente de projeto na TI. Apesar de haver uma percepção positiva da existência do cargo de
gerente de projeto na TI, existe um alto índice de respostas neutras e de respostas que
discordam da afirmação apresentada.
Entende-se como carreira específica, a existência de um plano de carreira específico com
benefícios, salários e treinamentos exclusivos para a carreira. Na TI, o cargo de gerente de
projeto, nomeado como líder de projeto, apesar de poder ser exercido tanto por funcionários
quanto por empregados de empresas terceirizadas, não possui uma carreira específica.
No caso de funcionários que exercem o cargo, podem ser incluídas em suas metas a serem
alcançadas durante o ano, metas específicas ao seu desempenho como líder de projeto. O
resultado do cumprimento das metas é um dos fatores que habilitam o funcionário
111
concorrer a uma promoção. Mas não existem salários ou benefícios específicos por exercer
o cargo. No caso de empregados de empresas terceirizadas, estes são contratados para
exercerem o cargo de líder de projeto não havendo plano de carreira específico.
Podemos supor então que o alto índice de respostas neutras e respostas negativas são de
respondentes que apesar de exercerem perante a organização o cargo de gerente de projeto,
não se sentem reconhecidos como tal., o que vem ao encontro a não existência de uma
carreira específica. É interessante notar que as respostas negativas foram tanto de
contratados quanto de funcionários.
Questão 5a: Existe na Companhia um programa de treinamento em gerenciamento de
projetos acessível a todos os funcionários.
Figura 25. Gráfico de distribuição das respostas da questão 5a
Questão 5a - Existência do programa de treinamento
em gerenciamento de projetos
6%
11%
Discordo totalmente
11%
Discordo
Não concordo nem discordo
39%
Concordo
Concordo totalmente
33%
112
A questão 5 do formulário foi subdividida em três questões a serem respondidas
separadamente por funcionários e empregados de empresas terceirizadas. As respostas da
variável 5a indicam tendência positiva (45%) no reconhecimento por parte dos funcionários
da existência de um programa de treinamento de gerenciamento de projetos.
Estas respostas demonstram o conhecimento do programa de treinamento de gerenciamento
de projetos existente na empresa, em sua unidade denominada Universidade Petrobras. Este
programa é exclusivo para funcionários do sistema Petrobras e abrange vários níveis desde
conhecimentos básicos em gerenciamento de projetos, preparação para a certificação
Project Management Professional (PMP) até cursos de pós-graduação lato-sensu em
Gerenciamento de Projetos.
O percentual (33%) de respostas neutras (Não concordo nem discordo) indica que a TI deve
investir na comunicação interna dos programas de treinamento existentes .
Questão 5b: A TI incentiva a participação de seus funcionários no programa de
treinamento em gerenciamento de projetos.
Figura 26. Gráfico de distribuição das respostas da questão 5b
Questão 5b - Participação dos funcionários no
programa de treinamento
14%
7%
7%
Discordo totalmente
Discordo
Não concordo nem discordo
31%
41%
Concordo
Concordo totalmente
113
Como foi solicitado que somente respondessem a questão 5b aqueles que concordassem
com a questão anterior, o número de respostas das duas questões não foi o mesmo,
apresentando uma pequena diferença mas não significativa no resultado final devido ao alto
índice de respostas positivas na questão 5a.
O número de respostas positivas, 45%, na questão 5b indica a percepção da importância
para a gerência da participação dos funcionários nos programas de treinamento. Segundo
dados da gerência de Recursos Humanos da TI, durante o ano de 2004, foram treinados 110
funcionários em cursos de gerenciamento de projetos.
O percentual (41%) de respostas neutras (Não concordo nem discordo) indica que apesar de
terem conhecimento da existência do programa de treinamento, os respondentes não se
sentem incentivados a participar do mesmo. Este é um ponto de atenção para TI, pois
segundo Kerzner (2001b) a não percepção pelo funcionário da importância para a gerência
de sua participação nos treinamentos pode acarretar em resistência ao uso de gerenciamento
de projetos.
114
Questão 5c: Existe um programa de treinamento em gerenciamento de projetos na empresa
pela qual sou contratado
Figura 27. Gráfico de distribuição das respostas da questão 5c
Questão 5c - Existência do programa de treinamento
em gerenciamento de projetos na empresa contratada
12%
4%
32%
Discordo totalmente
Discordo
Não concordo nem discordo
20%
Concordo
Concordo totalmente
32%
O alto índice (64%) de respostas negativas (Discordo e Discordo totalmente) indica a não
existência na maior parte das empresas terceirizadas de um programa de treinamento em
gerenciamento de projetos.
115
Questão 13: Os líderes de projetos demonstram ter conhecimento adequado para exercer
seu papel
Figura 28. Gráfico de distribuição das respostas da questão 13 respondidas por funcionários
Questão 13 - Conhecime nto dos gerente s de projetos
Respondida por funcionários
0%
3%
19%
22%
Discordo totalmente
Discordo
Não concordo nem discordo
Concordo
Concordo totalmente
56%
Figura 29. Gráfico de distribuição das respostas da questão 13 respondidas por contratados
Questão 13 - Conhecimento dos gerentes de projetos
Respondida por contratados
7%
13%
Discordo totalmente
33%
Discordo
Não concordo nem discordo
20%
Concordo
Concordo totalmente
27%
116
É interessante notar que a grande parte dos respondentes que se posicionaram de forma
neutra e de forma negativa a esta afirmação são funcionários (gráfico 28), um resultado
discrepante em relação aos resultados obtidos nas questões 5a e 5b, Podemos supor que
apesar de perceberem a existência de treinamento em gerenciamento de projetos e o
incentivo pela TI na participação dos funcionários nos mesmos, os respondentes ou não
realizaram o treinamento ou apesar de terem sido treinados não se sentem com
conhecimento suficiente para exercer o cargo de gerente de projeto. Para um melhor
entendimento desta discrepância seria necessário um maior aprofundamento nos resultados
obtidos nos treinamentos em gerenciamento de projetos, o que está fora do escopo deste
trabalho. Porém é necessário ressaltar que esta evidência poderá servir como indicador para
pesquisas futuras.
Por um outro lado, a maior parte das respostas positivas foram respondidas por contratados
(gráfico 29) apesar das respostas da questão 5c indicarem a não existência de um programa
de treinamentos em gerenciamento de projetos na maior parte das empresas contratadas.
117
5.2.4 Análise das variáveis referentes à seção Metodologia e Processos
Questão 6: Existe uma metodologia única de gerência de projetos, conhecida por todos e
efetivamente utilizada
Figura 30. Gráfico de distribuição das respostas da questão 6
Questão 6 - Metodologia única
3%
15%
10%
Discordo totalmente
Discordo
Não concordo nem discordo
30%
42%
Concordo
Concordo totalmente
A maioria (52%) de respostas negativas (Discordo e Discordo totalmente) mostra uma
tendência em não concordar com a existência de uma única metodologia de gerência de
projetos na TI. Isto pode ser explicado pelo fato de diversas áreas incorporadas pela TI em
sua reestruturação possuírem padrões próprios. Existe um forte investimento na
implantação na TI de uma metodologia única com padrões, procedimentos e ferramentas
que suportem a mesma. A implantação da metodologia teve início em setembro de 2004,
mas ainda existem áreas que não a utilizam, o que confirma o resultado apresentado.
O alto índice (30%) de respostas neutras (Não concordo nem discordo) indica a falta de
percepção da existência de uma metodologia única e deve ser um ponto de atenção para a
118
TI podendo ser um subsídio para a avaliação da implantação da metodologia, o que está
fora do escopo deste trabalho.
Questão 7: Para todo o projeto é construída uma WBS (Work-Breakdown Strucuture).
Figura 31. Gráfico de distribuição das respostas da questão 7
Questão 7 - Existência de planejamento
11%
2%
21%
Discordo totalmente
Discordo
Não concordo nem discordo
30%
Concordo
36%
Concordo totalmente
Os resultados desta questão, ao apresentarem uma forte tendência de respostas que não
concordam com a afirmativa (57%), incluindo o alto índice de respostas neutras (30%),
demonstram a pouca utilização dos conceitos de planejamento de projetos.
Não efetuar um planejamento das atividades que serão realizadas em um projeto inviabiliza
a correta alocação dos recursos, tanto humanos quanto materiais, que serão utilizados e uma
previsão dos custos e prazos que serão realizados. Somado a isso, a falta de planejamento
acarreta dificuldade de acompanhamento do projeto pois não se consegue comparar o que
foi realizado como o que foi planejado e com isso realizar os ajustes que possam vir a
serem necessários. A falta de planejamento é um dos principais aspectos que pode
comprometer o sucesso de um projeto
119
Não podemos inferir que este resultado se complementa ao resultado da questão anterior
pois a não existência de uma metodologia única não inviabiliza a existência de padrões e
procedimentos.
Questão 8: A gerência de riscos na TI é suportada por processos para identificação,
qualificação e quantificação dos riscos.
Figura 32. Gráfico de distribuição das respostas da questão 8
Questão 8 - Gerência de riscos
5%
15%
15%
Discordo totalmente
Discordo
Não concordo nem discordo
31%
34%
Concordo
Concordo totalmente
120
Questão 9: Existe um processo formal de controle de mudanças sendo utilizado e
respeitado
Figura 33. Gráfico de distribuição das respostas da questão 9
Questão 9 - Controle de mudanças
7%
5%
Discordo totalmente
21%
Discordo
33%
Não concordo nem discordo
Concordo
Concordo totalmente
34%
Os resultados destas duas questões estão coerentes com os resultados apresentados nas
questões
anteriores.
Existem
padrões
e
procedimentos
para
quantificação
e
acompanhamento dos riscos e para controle de mudanças de escopo que possam surgir
durante ao desenvolvimento do projeto. Estes procedimentos e padrões fazem parte da
metodologia de gerenciamento de projetos que começou a ser implantada em setembro de
2004. A não percepção da existência destes padrões, ou em outras palavras, a não
percepção da existência do processo de gerência de riscos e de controle de mudanças de
escopo ratifica o resultado encontrado na questão 6 da não percepção da existência de uma
metodologia única.
Assim como na questão 6, o significativo índice de respostas neutras (Não concordo nem
discordo) nas questões 8 e 9, 34% e 34% respectivamente, ratifica a falta de percepção da
121
existência de processos e padrões sendo mais um subsídio para a avaliação da implantação
da metodologia.
Questão 10: Existem critérios formais e bem-definidos para a seleção dos projetos a serem
desenvolvidos.
Figura 34. Gráfico de distribuição das respostas da questão 10
Questão 10 - Seleção dos projetos
7%
18%
13%
Discordo totalmente
Discordo
Não concordo nem discordo
25%
Concordo
Concordo totalmente
37%
O percentual (43%) de respostas negativas (Discordo e Discordo totalmente) acrescentado
ao percentual (37%) de respostas neutras (Não concordo nem discordo) indicam a falta de
percepção da existência de um processo formal de seleção dos projetos a serem
desenvolvidos. Este resultado era esperado pois conforme apresentado anteriormente no
capítulo 4, apesar da TI reconhecer a necessidade de critérios formais para seleção de
projetos, optou-se por inicialmente concentrar a centralização de todos os projetos
desenvolvidos e partir da visibilidade dos projetos a serem atendidos, desenvolver critérios
para priorização dos mesmos.
122
Em agosto de 2005 teve início a implantação de uma ferramenta chamada de Necessidades
de Tecnologia da Informação (NTI) que tem como objetivo suportar o processo de seleção
e priorização dos projetos a serem realizados e uma correta previsão dos recursos que
devem estar disponíveis para atendimento dos mesmos. Esta ferramenta tem a previsão de
ser implantada em toda a TI.
Questão 11: Ao final de cada projeto, as lições aprendidas são discutidas e documentadas.
Figura 35. Gráfico de distribuição das respostas da questão 11
Questão 11- Documentação das lições aprendidas
11%
3%
16%
Discordo totalmente
Discordo
Não concordo nem discordo
26%
Concordo
44%
Concordo totalmente
A maioria das respostas (60%) com tendência negativa incluindo as respostas neutras
(26%) está de acordo com o resultado esperado pois atualmente não existe na TI a
obrigatoriedade de documentar as lições aprendidas ao final de cada projeto.
Na metodologia de gerenciamento de projetos, que começou a ser implantada em setembro
de 2004, existe a obrigação da confecção de um relatório ao final do projeto onde são
informadas as lições aprendidas, mas não existe uma forma de consulta a estas lições.
123
Como a metodologia ainda não foi implantada em todas as áreas da TI, este relatório não é
confeccionado para todos os projetos desenvolvidos.
5.2.5 Análise das variáveis referentes à seção Autoridade e Responsabilidade
Questão 12: Os líderes de projetos possuem plena autonomia na condução de seus
projetos, incluindo equipe, recursos materiais, etc.
Figura 36. Gráfico de distribuição das respostas da questão 12
Questão 12 - Autonomia dos gerentes de projetos
18%
0%
18%
Discordo totalmente
Discordo
Não concordo nem discordo
Concordo
26%
38%
Concordo totalmente
O índice (56%) de respostas negativas (Discordo e Discordo totalmente) incluindo o índice
(26%) de respostas neutras indicam a falta de autonomia dos gerentes de projetos na
condução de seus projetos. Uma das principais funções do gerente de projeto é, segundo
Gareis & Huemann (2000), coordenar a equipe do projeto para que os objetivos
estabelecidos para o projeto sejam alcançados. Sem a possibilidade de poder alocar os
recursos necessários que serão utilizados nas atividades do projeto, o gerente de projeto não
124
consegue planejar adequadamente os custos e prazos que serão realizados, prejudicando
com isso a realização do projeto podendo comprometer o seu resultado final.
5.2.6 Análise das variáveis referentes à seção Benchmarking
Questão 14: Os projetos da minha área são medidos, controlados e comparados com os
demais projetos da área.
Figura 37. Gráfico de distribuição das respostas da questão 14
Questão 14 - Benchmarking interno
16%
2%
11%
Discordo totalmente
Discordo
Não concordo nem discordo
Concordo
37%
Concordo totalmente
34%
As respostas negativas (48%) incluindo as respostas neutras (34%) indicam a não
realização de comparações entre os projetos desenvolvidos pelas diversas áreas da TI. Esta
resposta corrobora com a resposta da questão 11 que informa que as lições aprendidas não
são discutidas e documentadas. Documentar as lições aprendidas com os projetos realizados
é um dos passos para realizar a comparação entre os mesmos.
Outro fator que dificulta a realização de benchmarking interno é a inexistência de
indicadores aplicados a todos os projetos realizados.
125
Questão 15: Os projetos da minha área são medidos, controlados e comparados com outros
projetos de outras áreas ou empresas
Figura 38. Gráfico de distribuição das respostas da questão 15
Questão 15 - Benchmarking externo
8% 2%
18%
Discordo totalmente
Discordo
26%
Não concordo nem discordo
Concordo
Concordo totalmente
46%
A resposta quanto à inexistência de comparação entre os projetos realizados pela TI e
projetos realizados por áreas da Petrobras ou por outras empresas é esperada ao se verificar
na questão anterior que não são realizadas comparações internas. Cabe ressaltar que a
realização de comparações tanto internas quanto externas ocorre em empresas com um alto
nível de maturidade em gerenciamento de projetos.
Podemos destacar dentre todos os resultados apresentados que:
• Existe uma tendência geral dos respondentes em não concordarem com as
afirmações apresentadas com exceção das três primeiras afirmações que discorrem
sobre o reconhecimento da importância da gerência de projetos tanto pela
organização quanto pela gerência executiva;
126
• Identificou-se na percepção dos respondentes que seus gerentes imediatos ou
coordenadores possuem conhecimentos dos conceitos de gerenciamento de projetos;
• Identificou-se na percepção dos respondentes que apesar de exercerem o cargo de
gerente de projeto, nomeado como líder de projeto, os mesmos não se sentem
reconhecidos como tal;
• A existência de um programa de treinamento em gerenciamento de projetos e o
incentivo pela gerência para a participação neste são reconhecidos por uma grande
parte dos funcionários da Petrobras que exercem o cargo de líder de projeto na TI.
Mas estas questões tiveram um alto índice de respostas neutras o que deve ser um
ponto de atenção para a TI;
• A maior parte das empresas terceirizadas não oferece programa de treinamentos em
gerenciamento de projetos para seus funcionários embora os mesmos se sintam
capacitados a exercerem o cargo de líder de projeto na TI;
• Existe uma percepção positiva pelos respondentes do conhecimento em
gerenciamento de projeto dos líderes de projeto, sendo esta percepção maior no caso
dos respondentes que são contratados;
127
• A existência de uma metodologia única de gerenciamento de projetos com
procedimentos e padrões para gerência de riscos e controle de mudanças de escopo
não está sendo percebida pelos líderes de projeto;
• Existem projetos que estão sendo desenvolvidos sem o planejamento inicial de suas
atividades e alocação de recursos, comprometendo com isso a previsão dos prazos e
custos que serão realizados;
• Não existem critérios para seleção e priorização dos projetos o que leva a
dificuldade de previsão dos recursos que devem ser disponibilizados para
atendimento dos mesmos;
•
A autonomia dos líderes de projeto quanto à condução de seus projetos não foi
percebida pelos respondentes;
• Os processos de benchmarking tanto internos quanto externos não são executados
de acordo com os respondentes;
Face ao que foi apresentado e comparando os resultados com o modelo de maturidade de
Kerzner, utilizado como base para a pesquisa, podemos concluir que a TI ao apresentar o
reconhecimento tanto pela organização quanto pelos todos os níveis da gerência da
importância do gerenciamento de projetos e ao desenvolver processos e padrões para o
efetivo uso de gerenciamento de projeto possui características identificadas pelo modelo
como pertencentes ao nível 2 – Processos Comuns.
128
Mas apesar de possuir características do nível 2 (Processos Comuns) do modelo de
Kerzner, a TI ainda encontra uma grande resistência aos conceitos de gerenciamento de
projetos nos níveis operacionais. Vários fatores apresentados nos resultados da pesquisa nos
levam a esta conclusão. Dentre eles: a falta de autonomia dos gerentes de projetos na
condução de seus projetos, a falta de planejamento dos projetos, a percepção por partes dos
respondentes da falta de conhecimento adequado para exercer o cargo de líder de projeto
apesar da existência de programas de treinamento.
A resistência do nível operacional quanto à utilização do gerenciamento de projetos vem da
falta de visibilidade do suporte do corpo gerencial. Os respondentes apesar de perceberem o
reconhecimento da importância do gerenciamento de projetos tanto pela a organização
quanto pelo corpo gerencial, não percebem o suporte para a utilização do gereciamento de
projetos. O alto índice de respostas negativas e neutras nas questões que dizem respeito a
utilização da metodologia e de seus processos e padrões nos levam a concluir que os
investimentos que estão sendo realizados quanto a implantação do gerenciamento de
projetos não estão sendo percebidos pelo corpo operacional.
Kerzner (2001b) destaca que o nível 2 do modelo pode e deve sobrepor o nível 1. Para o
autor, uma organização pode apresentar características de um nível superior sem
obrigatoriamente apresentar todas as características de um nível inferior. Segundo ele, não
existe razão para esperar treinar todos aqueles que utilizarão gerenciamento de projetos
para depois desenvolver processos e metodologias. Quanto mais cedo a metodologia for
desenvolvida maior a possibilidade de apresentá-la no treinamento. Mas ressalta que uma
129
organização somente pode ser avaliada como pertencente a um nível superior se ela
apresentar todas as características do nível inferior.
Podemos concluir que a TI encontra-se no nível 1 – Linguagem Comum de maturidade em
gerenciamento de projetos mas com diversas características do nível imediatamente
superior. O resultado encontrado encontra similaridade com os estudos de benchmarking
realizados pelo PMI-Seção Rio de Janeiro em 2003 e 2004 baseados no modelo de Kerzner.
Segundo estes estudos, realizados com empresas de diversas áreas como construção,
tecnologia da informação e telecomunicações, petróleo e gás, entre outras, a grande maioria
das empresas pesquisadas encontra-se no nível 1 de maturidade em gerenciamento de
projetos.
130
6
Modelo de Escritório de Gerenciamento de Projetos (PMO) proposto
Conforme apresentado no capítulo 2 – Referencial Teórico deste documento, para se
implantar um Escritório de Gerenciamento de Projeto (PMO) adequado a uma organização,
deve-se inicialmente avaliar o nível de maturidade em gerenciamento de projetos da
mesma. Após a análise do nível de maturidade em gerenciamento de projetos da TI
apresentada no capítulo anterior, podemos então indicar com base na literatura estudada, a
estrutura de Escritório de Gerenciamento de Projetos mais adequada.
A partir da análise do nível de maturidade de gerenciamento de projetos da TI, tendo como
base o modelo de maturidade de Kerzner, concluímos que a TI encontra-se no nível 1 –
Linguagem Comum do modelo, mas possuindo algumas características do nível 2 –
Processos Comuns. Segundo Verzuh (2000), o PMO deve refletir a estrutura organizacional
e o estágio de maturidade da organização em gerenciamento de projetos. O autor destaca
que a presença de um escritório de gerenciamento de projetos, não importando o tipo,
representa um comprometimento da organização para a melhoria do gerenciamento de
projetos.
Block & Frame (1998) destacam diversas funções que o PMO pode ter como: fornecer
suporte em gerenciamento de projetos para a equipe de projetos, prover a organização com
consultoria e mentoring em gerenciamento de projetos, desenvolver e manter metodologias
e padrões, fornecer treinamento em gerenciamento de projetos, entre outras. Verzuh (2000)
destaca, além destas funções, a função de participar do gerenciamento do portfolio de
projetos da organização.
131
Segundo Kendall & Rollins(2003), o PMO não deve focar apenas em metodologia, dados
operacionais e ferramentas sem se preocupar com o valor estratégico dos projetos. Os
autores destacam que 90% dos PMO não conectados com a gerência executiva e sem
métrica importantes a eles falham. Para ser bem-sucedido e sobreviver, o PMO tem que
prover um valor significativo para a gerência executiva. Este valor é percebido através de
informações estratégicas, recomendações, entre outros. Segundo os autores o PMO, por
mais simples que seja, deve ser estabelecido para atender não somente ao nível operacional
como ao nível executivo. O PMO que não influencia a seleção e priorização dos projetos
prioritários possui um alto risco de perder o suporte executivo.
Os resultados apresentados na pesquisa realizada indicam quais as funções que o PMO
inicialmente deve possuir.
A maioria das respostas negativas e o alto índice de respostas neutras nas questões da seção
Metodologia e Processos da pesquisa composta pelas questões 6 a 11, média de 43% a 60%
de respostas negativas e 26% a 37% de respostas neutras, nos levam a concluir a falta de
percepção da existência de uma metodologia em gerenciamento de projetos na TI e a baixa
utilização da mesma. A implantação da metodologia de gerenciamento de projetos iniciada
em setembro de 2004 ainda não foi percebida por todas as áreas da organização. Centralizar
o desenvolvimento e manutenção da metodologia e processos em uma única estrutura, no
caso o PMO, facilita sua disseminação pela organização. Somado a isso, o PMO passa a ser
responsável pela avaliação da implantação e de sua utilização.
132
O alto índice de respostas negativas (57%) e o índice de respostas neutras (30%) na questão
Existência de planejamento (questão 7) nos levam a concluir que grande parte dos projetos
desenvolvidos pela TI estão sendo realizados sem planejamento inicial das atividades e
alocação dos recursos, dificultando uma previsão correta dos custos e prazos que serão
realizados. Este resultado demonstra a baixa utilização dos conceitos de gerenciamento de
projetos, apesar de um resultado positivo principalmente por parte dos contratados, na
questão Conhecimento dos gerentes de projetos (questão 13) que diz respeito a percepção
do conhecimento dos líderes de projeto. Isto indica que o conhecimento teórico não está
sendo empregado na prática, não estando totalmente assimilado.
Uma das funções do PMO seria fornecer consultoria e coaching7 em gerenciamento de
projetos. Porém, devido a extensa área de atuação da TI, com grande número de projetos
desenvolvidos, sugere-se a criação da figura do multiplicador dos conceitos e da
metodologia de gerenciamento de projetos nas gerências da Agilidade e Áreas de Serviço.
O multiplicador pertenceria funcionalmente ao PMO e estaria alocado fisicamente nas
gerências da Agilidade e Áreas de Serviço, sendo responsável por disseminar os conceitos
de gerenciamento de projetos, metodologias e padrões e avaliar a situação dos projetos. O
multiplicador seria também o centralizador das dúvidas dos líderes de projeto na condução
de seus projetos além de fornecer suporte nas ferramentas de gerenciamento de projetos
utilizadas pela TI tanto para o líder de projeto quanto para os membros da equipe de
projeto. Com isso o multiplicador seria o ponto focal do PMO na gerência. Esta seria uma
forma de diminuir a resistência do nível operacional na utilização das metodologias,
7
Coaching - Processo utilizado pela liderança quando se quer melhorar o comportamento no trabalho ou
perfil do colaborador (Brocato, 2003)
133
padrões e ferramentas. Para esta alternativa ser bem-sucedida, o patrocínio das gerências
das áreas é fundamental. Inicialmente os gerentes das áreas podem achar que não é
necessária a existência de um representante do PMO alocado diretamente em sua área.
Caberá ao PMO conscientizá-los dos benefícios da utilização da abordagem de
multiplicadores.
O resultado da pesquisa relativo às questões da seção Treinamento e Desenvolvimento
composta pelas questões 4, 5 e 13, demonstram que apesar dos funcionários que exercem o
cargo de líder de projeto na TI reconhecerem a existência de um programa de treinamento
em gerenciamento de projetos e o incentivo pela gerência para a participação neste,
consideram que não possuem conhecimento suficiente para exercerem o cargo. Como uma
estrutura organizacional voltada para o desenvolvimento de uma abordagem consistente em
gerenciamento de projetos, uma das funções do PMO seria a organização dos treinamentos
de gerenciamento de projetos, sendo ser responsável pela ementa dos treinamentos, escolha
dos instrutores e avaliação dos resultados dos mesmos. Os treinamentos poderiam ter como
base o Modelo de Desenvolvimento de Competências para Gerentes de Projeto do PMI
apresentado no item 2.4.3 deste trabalho. Estes treinamentos consistiriam desde
treinamentos nos conceitos de gerenciamento de projetos até treinamentos nas
metodologias, processos e ferramentas utilizadas pela TI.
O percentual de respostas negativas (43%) e o percentual de respostas neutras (37%) na
questão Seleção dos projetos (questão 10) da pesquisa indicam a falta de percepção da
existência de critérios de seleção e priorização dos projetos a serem desenvolvidos. Sem um
planejamento estratégico do que deve ser feito e em que ordem, os projetos são realizados
134
ao mesmo tempo e como conseqüência levam muito mais tempo que o necessário. Uma das
funções do PMO é ajudar a gerência executiva a definir o processo de seleção e priorização
e a executá-lo. Apesar de não ser responsável por definir quais são os projetos prioritários e
estratégicos que devem pertencer ao portfolio de projetos, é responsabilidade do PMO
acompanhá-los. A responsabilidade da gerência executiva é assegurar que os objetivos
estratégicos serão cumpridos.
Face ao exposto e a partir do nível de maturidade identificado sugerimos uma estrutura
organizacional de Escritório de Gerenciamento de Projetos para TI com inicialmente as
seguintes funções:
• Ser responsável pelo desenvolvimento e manutenção de metodologias e padrões de
gerenciamento de projetos;
• Fornecer consultoria e coaching em gerenciamento de projetos;
• Fornecer suporte em gerenciamento de projetos a equipe de projetos;
• Fornecer suporte ao treinamento em gerenciamento de projetos;
• Acompanhar os projetos tidos como prioritários e estratégicos;
Não é necessário que todos os projetos desenvolvidos se reportem ao PMO. O PMO deve
se preocupar em acompanhar os projetos tidos como prioritários e estratégicos. Por outro
lado, o PMO deve periodicamente avaliar a situação dos projetos que estão sendo
realizados para verificar a utilização da metodologia e aprimorá-la. Este acompanhamento
deverá ser feito pelo multiplicador alocado nas gerências da Agilidade e de Serviços.
135
Segundo Kendall & Rollins (2003), o PMO tem que ser visto como um aliado não como
uma ameaça. Ele deve funcionar de forma independente, não devendo ser visto como uma
estrutura que apóia uma área específica e sim como uma estrutura que apóia a organização
como um todo. Sendo assim, o PMO deve estar vinculado diretamente à gerência executiva
da TI, e não a nenhuma das gerências da Agilidade ou das Áreas de Serviço, seus principais
clientes. Embora esteja vinculado diretamente à gerência executiva, por ter sido criado com
o objetivo de apoiar toda a organização, o PMO deve ter a preocupação de atender não
somente a gerência executiva como também aos níveis operacionais.
Kendall & Rollins (2003) indicam, para organizações com níveis de maturidade mais baixo,
um modelo de PMO mais centralizador com responsabilidade de desenvolver metodologias
e padrões, avaliar situação dos projetos. À medida que a organização for aperfeiçoando seu
nível de maturidade em gerenciamento de projetos, o PMO pode ter uma atribuição mais
consultiva.
Ao ser implantar o PMO com as funções sugeridas, deve se tomar o cuidado de não
estabelecê-lo com uma abordagem concentradora obrigando a todos a utilizarem as
metodologias e processos desenvolvidos. Esta abordagem só leva a uma forte rejeição
daqueles que deveriam ser os beneficiados com a implantação do PMO, os líderes de
projeto e membros das equipes de projeto. Os líderes de projeto devem entender os
benefícios de se ter uma gestão padronizada dos projetos desenvolvidos com a utilização de
processos e metodologias. Conforme apresentado no item 2.6.3 do referencial teórico, a
comunicação de todo o processo de implantação, bem como os resultados obtidos, deverá
136
ser realizada regularmente para que não haja resistência e expectativas infundadas
referentes às atribuições, responsabilidades e possibilidades de sucesso.
Rodrigues et al (2002) indica que o processo de implantação do PMO seja dividido em
estágios de forma que seja possível mensurar os benefícios da implantação. Um plano
detalhado de implantação deve ser desenvolvido com a finalidade de alcançar os objetivos
definidos para o PMO.
Os autores sugerem que dentro de cada estágio de implantação seja efetuado um ciclo
iterativo que consiste na avaliação das atribuições existentes e da maturidade da
organização, plano para aprimoramento das atribuições baseado na avaliação realizada,
execução do plano e repetição do processo a partir da avaliação do resultado das
modificações implementadas. No ciclo iterativo, a figura do multiplicador passa a ser
fundamental no recebimento de críticas e sugestões das áreas e disseminação das
modificações.
Rodrigues et al (2002) observa que a evolução das atribuições do PMO deverá sempre estar
alinhada à estratégia da organização.
137
7
Considerações Finais
A área de Tecnologia da Informação (TI) da Petrobras vem concentrando esforços para se
desenvolver como uma parceira estratégica das atividades fins da Companhia atuando no
provimento de soluções que apóiem os processos de negócio estratégicos da empresa. Para
atender a esta expectativa a área sofreu, desde 2000, reestruturações que culminaram na
criação de uma estrutura organizacional dividida em duas principais áreas: Agilidade,
estruturada por áreas de negócio e responsável por apresentar soluções que agreguem
resultados às atividades da Companhia e Serviços, responsável por prover as soluções
demandadas pelas gerências da Agilidade.
Devido ao porte da TI, tornou-se freqüente a realização de projetos com a participação de
mais de uma gerência funcional e de fornecedores externos. Neste ambiente, a falta de
padronização é o principal fator a dificultar o desenvolvimento de uma solução. Somado a
isso, vários indícios demonstram a inexistência de um efetivo planejamento estratégico.
Podemos citar dentre eles: mesmo recurso sendo alocado em vários projetos ao mesmo
tempo, o início de desenvolvimento de um projeto sem a avaliação ou planejamento de
recursos disponíveis e a falta de alinhamento dos projetos desenvolvidos com objetivos
estratégicos da organização. Como conseqüência os recursos são utilizados de forma
ineficaz, afetando o desempenho da TI. Uma estratégia para reduzir os problemas
apresentados é a adoção de uma gestão padronizada de gerenciamento de projetos segundo
os conceitos do PMI.
O presente trabalho se propôs a avaliar o nível de maturidade em gerenciamento de projetos
da TI e a partir desta avaliação identificar a estrutura de PMO mais adequada. As
138
atribuições do PMO deverão ser aprimoradas à medida que o grau de maturidade for sendo
aperfeiçoado.
Algumas iniciativas estabelecidas desde setembro de 2004 na TI como a criação de
metodologia em gerenciamento de projetos e o desenvolvimento de um processo de seleção
e priorização de projetos demonstram que a TI encontra-se no caminho certo para alcançar
níveis superiores em maturidade de gerenciamento de projetos e com isso poder atender ao
objetivo de ser parceira estratégica das áreas de negócio da Petrobras desenvolvendo
soluções que agreguem resultados às atividades da Companhia. A criação do PMO visa
facilitar o alcance deste objetivo.
Por outro lado, somente a implantação do PMO não ajudará a TI aumentar seu nível de
maturidade. Na estrutura organizacional da TI, um projeto é realizado com a participação
de membros de diversas gerências funcionais, podendo ser considerado como uma estrutura
matricial temporária. Pelo resultado encontrado na questão Autonomia dos gerentes de
projetos (questão 12) da pesquisa realizada, concluímos que o líder de projeto não possui
autonomia suficiente apesar de possuir grande conjunto de responsabilidades. Ao mesmo
tempo a TI possui uma estrutura organizacional hierárquica, o que dificulta o
gerenciamento de projetos que envolvam mais de uma área. Para que a estrutura matricial
montada para o projeto possa funcionar a contento, o trabalho em equipe é muito
importante, somado ao apoio não somente da gerência executiva, quanto das gerências
funcionais. Em outras palavras, deve haver uma maior integração entre as áreas de
Agilidade e Serviços. O suporte da gerência executiva para que esta integração ocorra
efetivamente é fundamental para o alcance de um maior nível de maturidade.
139
A pesquisa também identificou que os respondentes, apesar de exercerem o cargo de líder
de projeto, não se sentem reconhecidos como tal e não se sentem plenamente capacitados.
Apesar do resultado das seções Institucional e Suporte Gerencial da pesquisa, composta
pelas questões reconhecimento da organização, reconhecimento do corpo gerencial e
conhecimento da gerência intermediária, indicarem a percepção da importância do
gerenciamento de projetos tanto pela organização quanto por todos os níveis da gerência
incluindo a gerência executiva, o suporte não é visível. Somente com o suporte visível dos
gerentes é que os líderes de projeto se sentirão reconhecidos. Podemos supor que este
resultado possa ser devido ao modelo Agilidade/Serviços ter sido implantado há menos de
dois anos e que a percepção da falta de reconhecimento possa ser modificada com o tempo.
Em relação à capacitação, poderá ser indicado, em comum acordo com as gerências das
áreas, que os funcionários que exerçam o cargo de líder de projeto sejam capacitados para
se certificarem como Project Management Professional (PMP) do Project Management
Institute (PMI). O Estudo de Benchmarking em Gerenciamento de Projetos, realizado em
2004, ressalta a prática adotada por diversas empresas de exigirem em seus contratos
apenas profissionais com certificação PMP para exercem o cargo de gerente de projeto.
Sugere-se ao invés disso, treinar os contratados que o exerçam o cargo de líder de projeto
na TI para obterem a certificação PMP, pois esses profissionais já possuem conhecimento
técnico nas suas áreas de atuação e conhecimento da organização.
140
Por fim, pode-se dizer que a TI, apesar de estar no caminho certo, ainda tem uma jornada a
percorrer no alcance de níveis de maturidade mais avançados. Este objetivo só será
alcançado com o esforço de todos os seus membros.
141
8
Sugestões
A nova estrutura organizacional implantada em julho de 2005 propõe a criação de um
Escritório de Gerenciamento de Projeto. O estudo realizado poderá servir como base para a
comparação entre o Escritório de Gerenciamento de Projeto proposto e o a ser implantado.
Uma sugestão para pesquisa futura é avaliar o resultado do PMO a ser implantado. Nesta
avaliação poderia ser pesquisada não somente a percepção do líder de projeto como
também dos líderes de produto e os membros da equipe do projeto.
Este estudo também pode ser aprofundado por meio de uma pesquisa mais ampla,
comparando o Escritório de Gerenciamento de Projetos a ser implantado com outros
Escritórios de Gerenciamento de Projeto implantados em áreas de tecnologia da informação
de empresas subsidiárias da Petrobras. Por exemplo, a realização de uma pesquisa
comparando o PMO a ser implantado na TI e o PMO existente na área de TI da Petrobras
Argentina S/A (PESA), seus objetivos, responsabilidades e resultados.
Sugere-se também estudos comparativos entre PMO existentes em empresas da mesma área
de negócios da Petrobras, visto que estudos anteriores como os Estudos de Benchmarking
de 2003 e 2004 utilizaram empresas de diversos setores.
Além do enfoque técnico necessário para implantar o PMO ficou evidente, pelos resultados
apresentados na pesquisa realizada, que o aspecto humano deve ser trabalhado. A
integração entre as áreas de Agilidade e Serviços requer forte trabalho no desenvolvimento
142
de equipes. Sugere-se a criação de grupos inter-áreas que possam trabalhar as diferenças e
resistências existentes.
A TI, por ser uma área técnica, possui classicamente gerentes com formação técnica que e
com isso acabam desenvolvendo enfoque mais técnico do que o humano. Deve haver um
envolvimento maior da área de Recursos Humanos da própria TI de modo a desenvolver
alternativas de visibilidade do suporte gerencial requerido pelos técnicos.
Este trabalho tem como objetivo ser um trabalho embrionário no sentido de promover uma
base sólida para implementação de um PMO efetivo na TI.
143
Referências Bibliográficas
BCB. Banco Central do Brasil. Disponível em [http://www.bcb.gov.br/glossario.asp].
Acessado em 18 ago 2005
BLOCK, Thomas R. & FRAME, J. Davidson. The Project Office. Best Management
Practices, Crisp Management Library, 1998, 83p.
BROCATO, R. Coaching for Improvement: An Essential Role for Team Leaders and
Managers. The Journal for Quality and Participation: Cincinnati, 2003.
CLELAND, David L.; IRELAND, Lewis R. Gerência de Projetos. Rio de Janeiro:
Reichmann & Affonso Editores, 2002.
CRAWFORD, J.Kent. The Strategic Project Office: A Guide to Improving
Organization Performance. Project Management Inc.
CRAWFORD, Lynn. Project Manager Competence: Putting the PMBOK to Work. In:
Project Management Institute 27 th Annual Seminar/Symposium. Boston, Massachusetts,
1996
_____________.
Project Manager Competence for Next Century. In: Project
Management Institute 28 th Annual Seminar/Symposium. Chicago, Illinois, 1997
144
_____________. In search of competent project manager. In: Proceedings of the
Australian Institute of Project Management National Conference. Melbourne, Australia,
1999
DAFT, Richard L. Teoria e projeto das organizações. Rio de Janeiro: LTC - Livros
Técnicos e Científicos, 1999.
FAGUNDES, Eduardo. CobiT – um kit de ferramentas para a excelência na gestão de
TI. Disponível em [http:// www.efagundes.com/]. Acessado em 20 jun 2005.
GADDIS, P O. 1959. The project manager. Harvard Business Review 37 (3):89-97.
GASNET.
O
site
do
Gás
Natural.
Disponível
em
[http://www.gasnet.com.br/artigos/artigos_view2.asp]. Acessado em 16 ago 2005.
GAREIS, Roland; HUEMANN, Martina. Project Management Competences in the
Project-oriented Organization. In TURNER, J.R; SIMISTER, S.J. The Gower Handbook
of Project Management , Aldershot, 2000, p 709-721.
HALLOWS, Jolyon E. The Project Management Office Toolkit. American Management
Association.
145
HERSZON, Leon F. Análise da Gestão de Projetos com ênfase na sua maturidade:
Uma survey multi-setorial. Dissertação de Mestrado. Área de Sistemas de Gestão pela
Qualidade Total da UFF (Universidade Federal Fluminense), Niterói, 2004
HUMPREY, Wates S. Managing the Software Process. Software Engineering Institute,
1990
IBCG.
Instituto
Brasileiro
de
Governança
Corporativa.
Disponível
em
[http://www.ibgc.org.br]. Acessado em 17 ago 2005
KENDALL, Gerald I; ROLLINS, Steven C. Advanced Project Portfolio Management
and the PMO – Multiplying ROI at Warp Speed. International Institute for Learning:
J.Ross Publishing, 2003
KERZNER, Harold. Project management: a system approach to planning, scheduling
and controlling. New York: John Wiley & Sons, 2001a
_____________. Strategic Planning for Project Management using a Project
Management Maturity Model. New York: John Wiley & Sons, 2001b
_____________. Gestão de Projetos: As Melhores Práticas. Porto Alegre: Bookman,
2002.
146
KLARSFELD, A.. La compétence : ses définitions, ses enjeus. Paris : Gestion 2000,
maravril, 2000.
KWAK, Young Hoon; IBBS, C. William. Assessing Project Management Maturity.
Project Management Journal, Vol. 31, p 32-43, Mar-2002.
_____________. Project Management Process Maturity (PM)2 Model. Journal of
Management in Engineering, Vol. 18, p 150-155, Jul/Aug. 2002.
LAWRENCE, Paul R; LORSCH, Jay W. New management job: the integrator. Harvard
Business Review, Vol. 45, p.142-151, Nov/Dez-1967.
MAXIMIANO, Antonio Cesar Amaru. Administração de Projetos: como transformar
idéias em resultados. São Paulo: Atlas, 1997
MENEZES, Luis Cesar de Moura. Gestão de Projetos. São Paulo: Atlas, 2003
MORGAN, Gareth. Imagens da Organização. São Paulo: Ed. Atlas, 1996
NBR ISO 10006:2000, Gestão da qualidade - Diretrizes para a qualidade no
gerenciamento de projetos. Associação Brasileira de Normas Técnicas, ABNT/CB-25 –
Comitê Brasileiro da Qualidade; International Standard, International Organization for
Standardization; 29-01-2001
147
PATAH, Leandro A. Alinhamento Estratégico de Estrutura Organizacional de
Projetos: Uma análise de múltiplos casos. Dissertação de mestrado. Escola Politécnica da
Universidade de São Paulo, São Paulo, 2004
PAULK, M.C. et al. Capability Maturity Model for Software, Version 1.1. Software
Engineering Institute. Carnegie Mellon University, Pittsburgh, 1993.
PENNYPACKER, James S.; GRANT, Kevin P. Project Management Maturity: An
Industry Benchmark. Project Management Journal. Vol. 34, p. 4-11, Mar-2003.
PETROBRAS
(Petroleo
Brasileiro
S.A).
A
Petrobras.
Disponível
em
[http://www.petrobras.com.br/portal/Petrobras.htm]. Acessado em 22 jul 2005
PINTO, Jeffrey K; SLEVIN, Dennis P. Project Management Handbook.
Project
Management Institute, 1998
PMI (Project Management Institute).
Project Manager Competence Development
(PMCD) Framework. Project Management Institute, 2002, p. 2-6.
_____________. Organizational Project Management Maturity Model (OPM3).
Project Management Institute, 2003.
_____________. Rio de Janeiro. Estudo de Benchmarking em Gestão de Projetos,
2004a. Rio de Janeiro: Project Management Institute – Seção Rio de Janeiro.
148
_____________. A guide to the Project Management Body of Knowledge (PMBOK
Guide). Project Management Institute, 2004b
_____________. Introduction to the Project Management Institute (PMI ). Disponível
em: [http://www.pmi.org/info/AP_IntroOverview.asp]. Acessado em 26 jan 2005
RODRIGUES, Ivete; Gonsalez, Fábio L; Sbragia, Roberto. Escritório de Gerenciamento
de Projetos: Teoria e Prática. XXII Simpósio de Gestão de Inovação Tecnológica, Nov2002
SANTOSUS, Megan. Office Discipline: Why you need a Project Management Office.
Issue of CIO Magazine, Jul. 1, 2003
SILVA, Leonardo L. N. A influência da maturidade em Gerência de Projetos para uma
atuação com maior responsabilidade ambiental: Um estudo de caso sobre
profissionais de SMS da Unidade de Negócios Bacia de Campos da Petrobras.
Dissertação de Mestrado. EBAPE (Escola Brasileira de Administração Pública e de
Empresas) da FGV (Fundação Getúlio Vargas), Rio de Janeiro, 2003
SINERGIA. Projeto Sinergia de Tecnologia da Informação. Disponível em
[http://www.sinergia.petrobras.com.br]. Acessado em 25 jul 2005
149
SINPEP. Sistema Integrado de Padronização Eletrônica da Petrobras. Disponível em
[http://www.ti.petrobras.com.br/sinpepti]. Acessado em 21 jun 2005
THIRY-CHERQUES, Hermano Roberto. Modelagem de Projetos. São Paulo: Atlas,
2002.
TI (Tecnologia da Informação). Portal da Tecnologia da Informação. Disponível em
[http://www.ti.petrobras.com.br]. Acessado em 20 jun 2005
VERZUH, E. MBA Compacto – Gestão de Projetos. Rio de Janeiro: Campus, 2000
YIN, Robert K. Estudo de Caso: Planejamento e Métodos. 2a ed. Ed. Bookman, 2001
150
Anexo I
Formulário de Pesquisa
Caro(a) Líder de Projeto,
Agradeço a sua disponibilidade em responder este rápido questionário sobre o nível
de maturidade em gerenciamento de projetos da TI da Petrobras.
As informações fornecidas serão usadas somente para o escopo de um trabalho
acadêmico, mantendo o sigilo e anonimato sobre os respondentes.
Caso tenha alguma dúvida, por favor entre em contato comigo.
Obrigada!
Marta Cecília Henriques Calheiros.
1.
Identificação do Entrevistado.
1.1. Nome (opcional):
1.2. Chave (opcional):
1.4. Lotação:
2.
1.3. (_ ) Funcionário
( ) Contratado
Em cada questão, marque com um X o nível mais apropriado em uma escala de 1 a 5 (5 = Concordo
totalmente; 4 = Concordo; 3 = Não concordo nem discordo; 2 = Discordo; 1 = Discordo totalmente)
2.1 A TI, como órgão de Tecnologia da Informação da Petrobras,
reconhece a necessidade da gestão de projetos
1
2
3
4
5
2.2 A necessidade da gestão de projetos é reconhecida em todos os
níveis da gerência, incluindo a gerência executiva.
1
2
3
4
5
2.3 Meu gerente/coordenador conhece os princípios de gerenciamento
de projetos.
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
2.4 Existe uma carreira específica para gerente de projeto na TI.
2.5 Caso seja funcionário, por favor responda as questões a) e b). Caso
seja contratado, por favor responda a questão c).
a)
Existe na Companhia um programa de treinamento em
gerenciamento de projetos acessível a todos os funcionários.
151
Caso você concorde, por favor responda a questão b).
b) A TI incentiva a participação de seus funcionários no
programa de treinamento em gerenciamento de projetos.
1
2
3
4
5
Existe um programa de treinamento em gerenciamento de
projetos na empresa pela qual sou contratado
1
2
3
4
5
2.6 Existe uma metodologia única de gerência de projetos, conhecida
por todos e efetivamente utilizada
1
2
3
4
5
2.7 Para todo o projeto é construída uma WBS (Work-Breakdown
Strucuture).
1
2
3
4
5
2.8 A gerência de riscos na TI é suportada por processos para
identificação, qualificação e quantificação dos riscos.
1
2
3
4
5
2.9 Existe um processo formal de controle de mudanças sendo
utilizado e respeitado.
1
2
3
4
5
2.10 Existem critérios formais e bem-definidos para a seleção dos
projetos a serem desenvolvidos.
1
2
3
4
5
2.11 Ao final de cada projeto, as lições aprendidas são discutidas e
documentadas.
1
2
3
4
5
2.12 Os líderes de projetos possuem plena autonomia na condução de
seus projetos, incluindo equipe, recursos materiais, etc.
1
2
3
4
5
2.13 Os líderes de projetos demonstram ter conhecimento adequado
para exercer seu papel.
1
2
3
4
5
2.14 Os projetos da minha área são medidos, controlados e
comparados com os demais projetos da área.
1
2
3
4
5
2.15 Os projetos da minha área são medidos, controlados e
comparados com outros projetos de outras áreas ou empresas.
1
2
3
4
5
c)
152
Anexo II
Processo
Finalidade
Planejar e Controlar
Planejar a estratégia, a distribuição de recursos e o Sistema de
Gestão da Qualidade da TI, além de garantir o controle, os
recursos e a operação dos demais processos.
Gerir Infra-estrutura
Disponibilizar os ambientes tecnológicos necessários à
prestação dos serviços de responsabilidade da TI com os graus
de
segurança,
disponibilidade,
confiabilidade
e
custo
previamente acordados com os Clientes.
Prover Soluções
Prover soluções de TI aos clientes, levando em conta critérios
de prazo, qualidade e custo previamente acordados.
Apoiar Usuários
Apoiar os usuários no uso da infra-estrutura básica e nas
soluções de TI implementadas, levando em conta os níveis de
serviço acordados.
Gerir
Relacionamento Tem por finalidade a identificação, a conquista e a manutenção
com os Clientes
de Clientes, através do atendimento aos requisitos acordados e
na busca por serviços de maior valor agregado.
Prover Novos Serviços e Dispor à Companhia de tecnologias de informação compatíveis
Novas Tecnologias
com os padrões internacionais observados na indústria de
petróleo.
Gerir Recursos Humanos
Tornar a força de trabalho da TI compatível com as
competências requeridas pelos processos executados pelo
referido Órgão.
Gerir
Aquisição
de Proporcionar à Companhia as melhores práticas que conduzam
Produtos e Serviços
à contratação de produtos e serviços de TI com qualidade e
menores custos.
Fonte: SINPEP (2005)