ads:
1
UNIVERSIDADE DE TAUBATÉ
Nestor Nogueira de Albuquerque
ESCRITÓRIO DE GERENCIAMENTO DE
PROJETOS: Um Estudo de Caso de Implementação
Dissertação apresentada como exigência
para obtenção do título de Mestre pelo
curso de Gestão e Desenvolvimento
Regional do Departamento de Economia,
Contabilidade e Administração da
Universidade de Taubaté.
Área de Concentração: Planejamento e
Desenvolvimento Regional
Orientador: Prof. Dr. Marco Antonio
Chamon
Taubaté – SP
2006
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
2
Ficha catalográfica elaborada pelo
SIBi – Sistema Integrado de Bibliotecas / UNITAU
A345e ALBUQUERQUE, Nestor Nogueira de
Escritório de gerenciamento de projetos: um estudo de
caso de implementação / Nestor Nogueira de Albuquerque. -
2006.
153f. : il.
Dissertação (Mestrado) - Universidade de Taubaté,
Departamento de Economia, Contabilidade e Administração,
2006.
Orientação: Prof. Dr. Marco Antonio Chamon,
Departamento de Economia, Contabilidade e Administração.
Formatado: Fonte: 11 pt
ads:
Nestor Nogueira de Albuquerque
ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS:
Um Estudo de Caso de Implementação
Dissertação apresentada como exigência
para obtenção do título de Mestre pelo
curso de Gestão e Desenvolvimento
Regional do Departamento de Economia,
Contabilidade e Administração da
Universidade de Taubaté.
Área de Concentração: Planejamento e
Desenvolvimento Regional
Orientador: Prof. Dr. Marco Antonio
Chamon
Data: 03 de Abril de 2006.
Resultado: _APROVADO_
BANCA EXAMINADORA
Prof. Dr. Marco Antonio Chamon, Orientador UNIVERSIDADE DE TAUBATÉ
Assinatura _______________________________
Profa. Dra. Gládis Camarini UNIVERSIDADE DE TAUBATÉ
Assinatura _______________________________
Prof. Dr. Roque Rabechini Júnior UNIVERSIDADE DE SÃO PAULO
Assinatura ________________________________
Para minha família, que me deu a motivação e de
quem tirei um tempo precioso para esta jornada!
AGRADECIMENTOS
No estudo de gerenciamento de projetos aprende-se, principalmente, o valor do trabalho
em equipe e a importância do papel de cada pessoa no trabalho. Sendo assim, eu não
poderia deixar de expressar meus mais sinceros agradecimentos às pessoas e
organizações que contribuíram para o sucesso deste projeto. Primeiramente, agradeço
especialmente à minha família, dos quais precisei tirar um tempo precioso de
convivência para que pudesse realizar a pesquisa. À Empresa e aos profissionais que me
receberam, agradeço por compartilharem suas experiências, agora disponíveis à
comunidade de Gerenciamento de Projetos. Um agradecimento também é dirigido aqui
aos professores e professoras do Mestrado, em particular ao meu Orientador, Prof. Dr.
Marco Antonio Chamon, cujo apoio ao longo de todo o desenvolvimento deste trabalho
foi fundamental para o resultado alcançado. Em especial, agradeço a meus pais, pelo
apoio incondicional que desde a infância me estimula a buscar e superar desafios.
Finalmente e mais importante, agradeço a Deus pelas condições de aprendizado de que
me dotou e me permitiram concluir este trabalho.
“Felix, qui potuit rerum cognoscere causas.”
“Feliz o que pode conhecer as causas das coisas.”
Virgílio, 29 A.C.
ALBUQUERQUE, Nestor N. de. Escritório de Gerenciamento de Projetos: Um Estudo
de Caso de Implementação. 2006. 153 f. Dissertação (Mestrado em Gestão e
Desenvolvimento Regional) – Departamento de Economia, Administração e Contabilidade,
Universidade de Taubaté, Taubaté.
Resumo
A elaboração de projetos para a implementação das estratégias de negócios das
organizações, seja para aumentarem sua lucratividade, ampliarem sua participação nos
mercados em que atuam ou simplesmente garantir sua sobrevivência, justifica-se a cada
dia, dado o grau de competitividade com que essas empresas têm que atuar. Assim,
saber a forma como os projetos são executados para poder controlar seus resultados é
fator de relevância para o sucesso da gestão das empresas e motiva, cada vez mais, a
implementação de Escritórios de Gerenciamento de Projetos (PMO) nas empresas. Este
estudo de caso descreve como transcorreu uma implementação real de PMO em uma
área de Tecnologia da Informação de um empresa e apresenta tópicos de atenção aos
que planejam implementar estruturas semelhantes para controle de projetos. Pretende-
se com o trabalho que as empresas possam conhecer e comparar os resultados obtidos
com as recomendações encontradas na literatura sobre o assunto, para que possam
planejar melhor suas próprias implementações. O estudo mostrou que são fatores de
sucesso para a implementação do PMO tratar a implementação como um projeto,
utilizar profissionais com experiência em implementações similares e, principalmente,
promover a conscientização prévia dos executivos, gestores, profissionais envolvidos
com projetos Um cuidado especial deveria ser tomado também com relação ao
esclarecimento de usuários e clientes, internos ou externos, e outros a respeito dos
resultados esperados e possíveis riscos. Sem isso, provavelmente a implementação pode
não ser bem sucedida.
Palavras-chave: administração. gestão. maturidade. organizações. projetos.
ALBUQUERQUE, Nestor N. de. Project Management Office: An Implementation Case
Study. 2006. 153p. Dissertation (Master in Management and Regional Development) –
Department of Economics, Accounting and Administration, University of Taubaté,
Taubaté, BRAZIL.
Abstract
The use of projects for implementing business strategies, whether to increase
profitability, broaden market share or even guarantee their survival, has been justified
every day, given the degree of competitiveness to which these companies have to
achieve. Thus, to know how projects are conducted and the ability to control their
results is a factor of relevance for the success of managing businesses, and this has
increasingly been a strong driver for the implementation of Project Management
Offices (PMO) within companies. This study describes how a real PMO
implementation was conducted in a company’s IS/IT department, and presents attention
points for those who plan similar implementations. It is this research’s intention that
companies can know and compare the achieve benefits with those found in specific
literature, so they can better plan their own implementations. Principal research
findings shows that treating the PMO implementation as a project itself, use
professionals with a background on similar implementations, and promote the
acquaitance of executives, line managers and other personel involved with projects are
all success factors for a PMO implementation. Special care should also be taken with
regards of stakeholders’ awareness about what can be accomplished and associated
risks. Without that, it is possible that the project will not succeed.
Keywords: administration. management. maturity. organizations. projects.
Lista de Quadros
Quadro 1 Tipos de estruturas organizacionais (PMI, 2004, p. 28) ................................55
Quadro 2 Estratégias de Pesquisa - adaptado de Yin (2001, p. 24). ..............................82
Lista de Figuras
Figura 1 Três níveis de PMO (CRAWFORD, 2002, p. 56)...........................................39
Figura 2 Estrutura organizacional “Funcional” (PMI, 2004, p. 29)...............................48
Figura 3 O PMO na estrutura organizacional “Funcional”............................................49
Figura 4 Estrutura organizacional “por Projeto” (PMI, 2004, p. 29).............................50
Figura 5 O PMO nas estruturas matriciais, adaptado de PMI (2004)............................52
Figura 6 O PMO Nível 1, segundo Crawford (2002, p. 56)............................................58
Figura 7 O PMO Nível 2, adaptado de Crawford (2002, p. 56)......................................59
Figura 8 O PMO Nível 3, adaptado de Crawford (2002, p. 56)......................................60
Figura 9 O “Competency Continuum”, adaptado de Hill (2004, p. 46).........................61
Figura 10 Opções de software pelo mercado brasileiro (PINTO, 2005, p.109).............74
Figura 11 Quadrante Mágico Gartner (GARTNER, 2005, p. 3)....................................75
Figura 12 Fornecedores de software para gestão de portfólio – adaptado de Visitacion
(2006, p. 8)......................................................................................................................76
Figura 13 Pontos a Explorar nas Entrevistas .................................................................86
Figura 14 Organograma da área de T.I. na época da implementação do PMO ..............96
Lista de Gráficos
Gráfico 1 Problemas mais freqüentes em projetos (PINTO, 2005, p. 119) ...................35
Gráfico 2 Percepção da aplicabilidade do PMBOK (Filiados PMI)..............................72
SUMÁRIO
1 INTRODUÇÃO ...........................................................................................................14
1.1 Objetivos da pesquisa ............................................................................................20
1.1.1 Objetivo Geral .................................................................................................20
1.1.2 Objetivos Específicos......................................................................................20
1.2 Delimitação da Pesquisa........................................................................................20
1.3 Relevância da Pesquisa..........................................................................................21
1.4 Estrutura do Trabalho ............................................................................................21
2 ORGANIZAÇÃO DA LITERATURA .......................................................................24
2.1 Visão geral das fontes de referência ......................................................................24
2.2 Projetos no ambiente corporativo ..........................................................................26
2.3 Conceituação de PMO ...........................................................................................30
2.4 Importância Estratégica do PMO...........................................................................39
2.5 O PMO na Estrutura Organizacional.....................................................................46
2.5.1 Estrutura Funcional Pura.................................................................................48
2.5.2 Estrutura Projetizada .......................................................................................49
2.5.3 Estruturas Matriciais........................................................................................51
2.5.4 Comparação das Estruturas .............................................................................55
2.6 Tipos, Níveis e Funções do PMO..........................................................................57
2.7 Processos de Gerenciamento de Projetos...............................................................70
2.8 Modelos e Ferramentas..........................................................................................73
2.9 Implementação de um PMO ..................................................................................76
3 MÉTODO DA PESQUISA..........................................................................................82
3.1 Seleção do método de pesquisa .............................................................................82
3.2 Seleção da forma de coleta dos dados ...................................................................83
3.3 Tratamento dos dados e apresentação de resultados..............................................89
4 RESULTADOS E ANÁLISE ......................................................................................90
4.1 Histórico.................................................................................................................90
4.1.1 A primeira tentativa de implementação do PMO............................................92
4.1.2 A segunda tentativa de implementação do PMO ............................................95
4.2 Resultados............................................................................................................100
4.2.1 Motivadores para a implementação do PMO................................................101
4.2.2 Reflexos positivos da implementação do PMO ............................................102
4.2.3 Pontos negativos e fatores dificultadores da implementação do PMO .........104
4.2.4 Fatores facilitadores da implementação do PMO..........................................110
4.3 Síntese do processo de implementação do PMO.................................................115
4.4 Lições Aprendidas ...............................................................................................122
4.5 Comparação dos resultados: Empresa x Literatura..............................................127
5 CONCLUSÕES .........................................................................................................132
REFERÊNCIAS............................................................................................................135
ANEXO A – TERMO DE CONSENTIMENTO PARA A PESQUISA......................143
ANEXO B – AUTORIZAÇÃO DO COMITÊ DE ÉTICA..........................................144
ANEXO C – AUTORIZAÇÃO PARA TRABALHO EM CAMPO ...........................145
APÊNDICE A – ROTEIRO PARA A ENTREVISTA ................................................146
APÊNDICE B – MENTORIA ......................................................................................147
APÊNDICE C – FUNÇÕES MAIS COMUMS DE SUPORTE A PROJETOS..........149
APÊNDICE D – PROPOSTA DE PROJECT CHARTER PARA PMO.......................151
14
1 INTRODUÇÃO
No curso normal de seus negócios, as empresas executam diariamente operações
administrativas, produtivas, de marketing e comercialização de seus produtos e serviços.
No decorrer desss atividades, novas oportunidades são identificadas e devem ser
aproveitadas e riscos podem ser identificados e devem ser tratados. Além disso, à
medida que os mercados se expandem, novos competidores entram em cena, o que
exige constante monitorização do desempenho da empresa e que as deficiências
observadas nos processos administrativos e produtivos sejam prontamente corrigidas.
Outras restrições podem ocorrer, e devem igualmente ser consideradas, para a adoção de
medidas cabíveis: leis, normas e regulamentos são alterados freqüentemente, os clientes
tornam-se mais exigentes e mudam seus requisitos e os recursos disponíveis tornam-se
escassos e difíceis de serem obtidos.
Assim, com o intuito de se adequarem a essas demandas de negócio, as empresas
planejam iniciativas a partir do acompanhamento e análises criteriosas dos cenários
interno e externo, em que identificam suas forças e suas fraquezas face às oportunidades
e ameaças do ambiente de negócios em que atuam. Essas iniciativas – que se
denominam “projetos” – são posteriormente avaliadas e aprovadas para comporem o
planejamento estratégico da empresa (MORRIS; JAMIESON, 2004, p.1).
Projetos normalmente caracterizam-se por serem “esforços temporários para
criar um produto, serviço ou resultado exclusivo” (PMI, 2004, p. 5) e devem ser
previamente planejados em termos de custos, recursos e esforços necessários. Para se
evitar a dispersão ou uso incorreto de recursos, as informações obtidas e geradas no
processo de planejamento dos projetos são avaliadas em conjunto com os benefícios
15
esperados, e só então esses projetos podem ser executados.
Cuidados adicionais devem ser considerados, entre eles: capacitação das equipes
de projetos, relacionamento com o público externo, definição de padrões e normas
internas para condução de projetos.
Finalmente, devem ser tratados também os aspectos gerenciais, como por
exemplo: histórico de projetos anteriores e seus resultados (previne incorrer-se em erros
do passado e permite identificar as oportunidades, para melhor aproveitá-las); situação
dos projetos em andamento (para se balancear corretamente os recursos necessários) e a
demanda a ser atendida (a fim de se concentrar nas necessidades reais dos clientes e
outros interessados).
Os vários conceitos que regem o gerenciamento de projetos já têm mais de meio
século, com origens nos esforços de desenvolvimento de tecnologias militares da II
Guerra Mundial, como citam Crawford (2002) e Kerzner (2002). Segundo esses autores,
a importância dos projetos nos dias de hoje justifica-se pelas constantes diminuições nos
prazos que as empresas têm para introduzir seus produtos no mercado e reagir, assim, às
estratégias de seus competidores.
Para suprir essas demandas de negócios, os projetos devem ser planejados e
implementados de forma estruturada e o Escritório de Gerenciamento de Projetos, ou
PMO (Project Management Office), como é mais comumente referenciado na literatura
especializada, é a estrutura que as organizações podem implementar para incrementar
sua capacidade de gerenciamento de projetos (BLOCK; FRAME, 1998).
O PMO, então, é “uma unidade organizacional que centraliza e coordena o
gerenciamento de projetos sob seu domínio” (PMI, 2004, p. 17). Para Valeriano (2005),
o PMO é “um órgão cuidadosamente implantado em uma organização e que tem sob sua
responsabilidade o apoio e a coordenação de vários projetos” (VALERIANO, 2005, p.
16
99)
Outra atribuição dessa estrutura é auxiliar os gerentes de projetos e suas equipes
na implementação de princípios, práticas, ferramentas e técnicas do gerenciamento de
projetos (DAI, 2001 apud CARVALHO, 2005). O uso repetitivo desse conjunto de
práticas define a metodologia da organização para o gerenciamento de projetos. Kerzner
(2001) destaca que
atingir a excelência em gerenciamento de projetos, ou mesmo sua
maturidade, pode não ser possível sem um processo repetitivo que possa ser
usado em todo e cada projeto. ... o uso contínuo da metodologia aumentará
drasticamente as chances de sucesso de uma companhia [e] para atingir esse
estágio de maturidade, as companhias devem manter e apoiar uma
metodologia única para gerenciamento de projetos... e boas metodologias
integram outros processos à metodologia de gerenciamento de projetos
(KERZNER, 2001, p. 83).
A implementação de PMOs, então, que formalizam e padronizam práticas,
processos e operações de gerenciamento de projetos numa organização, contribui para
se concluir os projetos com resultados consistentes e repetíveis, com maior
probabilidade de sucesso, conforme adiantado por Frame (1987):
Ao entrar a economia dos Estados Unidos na fase pós-industrial, os gestores
norte-americanos descobriram que muitas das orientações de gestão
estabelecidas para uma economia industrial não mais lhes serviam bem em
uma economia de informações. No ambiente de manufatura, a ênfase é
colocada em previsibilidade e atividades repetitivas e a administração está
fortemente preocupada com a padronização e racionalização dos processos de
produção. Numa economia [baseada em] informações, a singularidade de
eventos substituiu a repetição. A própria informação é dinâmica e sempre em
mutação. Flexibilidade é a palavra chave da nova ordem e gerenciamento de
projetos é a chave para essa flexibilidade. (FRAME, 1987, p.nestor).
Para a alta administração, o valor do PMO será mostrado com a melhoria da taxa
de sucesso dos projetos e a visibilidade da situação dos projetos. Operacionalmente, o
PMO deve prover suporte aos gerentes de projetos (administrativo, operacional e
organizacional) e também organizar o processo de gerenciamento de projetos, com a
definição de padrões e modelos, consultoria e treinamento (DINSMORE, 2004).
Assim, com o tempo, o PMO tende a assumir uma posição de influência no
17
processo de tomada de decisão da empresa, através da geração de informações mais
precisas, oportunas e confiáveis, sem, contudo, substituir as funções gerenciais
tradicionais (CLELAND; IRELAND, 2002).
Para ser bem sucedida, porém, essa estrutura deve ser formalmente definida,
estabelecida e suportada pela direção da empresa, que deve apoiar na obtenção do
comprometimento das pessoas a serem envolvidas no processo [de implementação do
PMO] (BEER, 2002).
A regra principal que se deve sempre ter em mente é que essa é uma iniciativa
de mudança cultural, e que deve ser tratada como um projeto com objetivos de longo
prazo. A meta desse projeto é, na realidade, mudar a forma como as pessoas fazem
gerenciamento de projetos, o que implica em mudar a cultura vigente na organização.
Segundo Daft (2002), a cultura de uma organização compreende os “modos de pensar
compartilhados pelos seus membros”, cuja força se faz notar “quando se tenta
implementar novas estratégias ou programas” (DAFT, 2002, p. 293-300).
Essa “força” de uma cultura organizacional geralmente se manifesta
contrariamente à implementação de grandes mudanças:
projetos referem-se a incomodar o status quo e fazer as coisas por novos
meios, enquanto os gerentes de operações tentam preservar o status quo
porquê é assim, como vimos acima (sic), que eles alcançam sua eficiência
sempre crescente (TURNER; KEEGAN, 1999).
Daí a importância do suporte da alta administração, pois será necessária uma
grande mobilização das pessoas no projeto. Da alta administração devem vir as
declarações de visão e missão do PMO, o alinhamento com os planos estratégicos da
organização e a determinação de urgência na mudança.
Para Paul Glen (2005), o primeiro passo para melhoria de produtividade das
equipes de projetos é o esclarecimento do estado futuro desejado para a organização na
18
forma como ela gerencia seus projetos. Essa fase, segundo ele, é usualmente ignorada
no tratamento de assuntos organizacionais por duas razões: primeiro, porque gerentes
são cobrados por serem pessoas de ação, o que os torna efetivos perante seus líderes;
segundo, existe uma diversidade muito grande de opções em termos de conceitos,
metodologias e ferramentas (software) e, sem um objetivo claramente definido, corre-se
o risco da seleção errônea de se definir ações ineficazes e até mesmo destrutivas
(GLEN, 2005).
Fora do contexto puramente literário, uma pesquisa realizada pelo CBP (Center
for Business Practices), envolveu 60 executivos seniores num fórum sobre
gerenciamento de projetos e a dúvida que ficou evidente foi o porquê de mais empresas
e seus CIOs
1
não adotarem imediatamente o gerenciamento de projetos, apesar de ser
algo tão obviamente oportuno. Uma das razões, segundo a pesquisa, é que isso requer
uma mudança cultural, a vontade para adotar novas formas de fazer as coisas e um
entendimento significativo dos conceitos do gerenciamento de projetos. Isso requer
tempo e esforço (CRAWFORD; PENNYPACKER, 2002).
O sucesso do PMO, portanto, somente poderá ser medido após a empresa
conseguir absorver a nova cultura e forma de trabalhar, pela adoção efetiva dos
processos de gerenciamento de projetos e quão melhor sejam os resultados dos projetos.
Uma pesquisa feita pela revista eletrônica CIO
2
e o PMI – Project Management
Institute
3
entre 303 profissionais de Tecnologia da Informação (executivos e
1
CIO: sigla para o cargo de Chief Information Office, ou Diretor de Tecnologia da Informação – o mais
alto executivo responsável pelos sistemas de tecnologia da informação em uma organização.
2
A revista eletrônica CIO é direcionada ao público gestor de Tecnologia da Informação (T.I.) e possui
versão impressa para quinze países. Está disponível na internet em http://www.cio.com.
3
O PMI é atualmente a mais referenciada fonte sobre práticas e conhecimentos em Gerenciamento de
Projetos, constituído por mais de 200 mil profissionais filiados em 125 países. Entidade sem fins
lucrativos, cuja missão é promover o Gerenciamento de Projetos como fator de sucesso para os negócios
em qualquer área da atuação humana, o PMI organiza-se em Capítulos (escritórios locais nos diversos
países e estados), Grupos de Interesses Especiais (Special Interest Groups - SIGs), e Universidades
19
profissionais operacionais) filiados ao PMI mostrou
4
76% de referência a PMOs com
até 3 anos de existência e 50% mencionaram melhorias nos índices de desempenho dos
projetos (apenas 22% não controlam esses indicadores) e que os principais benefícios
foram: ter implementado padrões de gerenciamento de projetos (62%), melhoria na
satisfação de clientes internos (38%), aumento na produtividade dos funcionários
(39%), redução de custos (27%) e melhoria na satisfação de clientes externos (25%). A
grande maioria dos entrevistados (42%) mencionou que seus PMOs são “PSOs –
Project Support Organizations – ou sejam oferecem serviços de suporte a múltiplos
projetos em atividades administrativas, controle de cronogramas, relatórios de
desempenho e outros assuntos” e são de âmbito corporativo (39%), divisional (27%) ou
funcional/de área de negócios (27%).
Em termos de funções desempenhadas pelo PMO, as cinco mais citadas foram:
85% - executam o controle e relatório de andamento e desempenho dos projetos e
processos; 80% - possuem apoio ou patrocínio da alta administração; 79% - garantem
que projetos similares sejam executados de forma consistente, com processos repetíveis;
74% - provêm treinamento e facilitação com mentoring de projetos; 74% - conduzem
análises pós-encerramento de projetos, comunicam e incorporam as lições aprendidas e
73% contribuem para o desenvolvimento das competências chave para o gerenciamento
de projetos (WARE, 2003).
Em relação à sua localização na estrutura da empresa, a Revisão da Literatura
mostrará que há uma série de possibilidades e recomendações, mas não determina uma
posição correta, ou mais indicada. O importante é que o PMO seja estruturado de acordo
com as necessidades da organização, e evolua segundo essas necessidades (CLELAND;
(EUA), onde se encontram os filiados para discussões de padrões, troca de informações e experiências e
compilação de “melhores práticas”.
4
Resultados não exclusivos: para cada questão, uma ou mais alternativas poderiam ser escol``hidas.
20
IRELAND, 2002).
1.1 Objetivos da pesquisa
1.1.1 Objetivo Geral
O objetivo geral da pesquisa é responder à questão: “Como transcorreu a
implementação de um ‘Escritório de Gerenciamento de Projetos’ na área de Tecnologia
da Informação de uma empresa da região do Vale do Paraíba orientada a projetos?”.
1.1.2 Objetivos Específicos
Identificar por que a Empresa investiu nesse empreendimento, quais foram os
fatores que facilitaram e fatores que dificultaram a implementação do PMO e identificar
quais os ganhos que se percebeu com a implementação.
1.2 Delimitação da Pesquisa
A pesquisa foi realizada numa empresa de grande porte, que atua no ramo
metalúrgico, voltada a projetos de alta tecnologia. O departamento alvo da pesquisa foi
a área de Tecnologia da Informação (T.I.) que empreende projetos, mas também executa
as operações e outras atividades rotineiras típicas de uma área de serviços em empresa
de grande porte.
O objetivo do departamento, ao decidir pela implementação do PMO, foi
melhorar a visibilidade, o controle e a eficiência especificamente sobre os projetos de
desenvolvimento e manutenção de sistemas informatizados.
A pesquisa abordou o PMO pelo ponto de vista de gestão estratégica e como
metodologia e tecnologias de gerenciamento de projetos, geralmente definidas e
implementadas por um PMO, podem contribuir para a otimização do uso dos recursos
21
de uma organização em seus projetos de implementação de estratégias de negócio.
Estão apresentados os resultados alcançados com a formalização do processo de
controle sobre os projetos, embora outros fatores, além da implantação do PMO,
possam ter influenciado a obtenção desses resultados.
1.3 Relevância da Pesquisa
A pesquisa concentra-se em descrever um caso específico da área de T.I., porém,
também pode ser útil às demais áreas profissionais, uma vez que em todas é possível
executar-se projetos que tenham por objetivo por em prática planos ou estratégias de
empreendimentos diversos, de fins lucrativos ou não.
Os resultados apresentados e o processo que permitiu obtê-los podem servir de
orientação a empresas ou organizações que pretendem implementar estratégias ou
desenvolver produtos com uso de uma estruturação formal de gerenciamento de
projetos.
1.4 Estrutura do Trabalho
Este trabalho está estruturado como segue:
Neste capítulo 1 apresentamos os principais motivadores para o trabalho: a
importância atual do assunto no meio profissional de projetos, justificativas para a
pesquisa e principais resultados esperados. O tema "Escritório de Projetos" tem sido
divulgado como de importância relevante no suporte à formulação e implementação das
estratégias das empresas, que no ambiente atual de alta competição e escassez contínua
de recursos exige delas cada vez mais agilidade e eficiência no uso desses recursos para
22
a sustentação de seus negócios.
O Capítulo 2 discorre sobre a literatura atual sobre PMO, das origens às mais
recentes discussões sobre os aspectos gerenciais e estratégicos a serem considerados
numa implementação. Consultamos referências de pesquisas científicas recentes, mas
também procuramos pelas obras históricas no assunto. Não poderíamos também excluir
consultar fontes normalmente aceitas como referências, publicadas na Internet. Essas
fontes, apesar de não serem consideradas como de produção científica, são editadas por
profissionais e organizações envolvidos com o assunto “gerenciamento de projetos”, e
muitas vezes contêm a importante observação da prática no assunto, a qual
consideramos relevante para os propósitos deste trabalho.
No Capítulo 3 detalharemos como a pesquisa foi elaborada e aplicada ao público
alvo selecionado, composto pelos gestores de T.I. da empresa. Esse público compreende
os profissionais diretamente interessados e afetados pela implementação do PMO. As
futuras iniciativas que possam vir a conduzir para atender às demandas das áreas da
empresa a que atendem teriam, necessariamente, que ser estruturadas como “projetos de
T.I.”.
Nossa discussão e considerações a respeito das respostas às entrevistas estão no
Capítulo 4. A partir das variáveis da pesquisa, apresentamos os pontos procurados na
pesquisa (fatores facilitadores e dificultadores da implementação do PMO) e as
considerações de como julgamos que estes possam ser mais eficientemente aproveitados
(facilitadores) ou como poderiam ser evitados ou minimizados (difcultadores).
Finalmente, no Capítulo 5, procuramos resumir os resultados encontrados e
apresentar os pontos que encontramos como de oportunidade para estudos posteriores
sobre o assunto, que possam contribuir com a geração de conhecimento da comunidade
de profissionais de Gerenciamento de Projetos e executivos em geral.
23
24
2 ORGANIZAÇÃO DA LITERATURA
Esta revisão destina-se a apresentar conceitos e definições da literatura atual
sobre PMO, desde as obras históricas de suas origens, em sua maioria anteriores a 1980,
às mais recentes pesquisas científicas e discussões sobre os aspectos gerenciais e
estratégicos a serem considerados numa implementação.
Nas fontes consultadas encontra-se uma diversidade de formas de organização
dos textos a respeito de PMO. Assim, uma contribuição importante que este trabalho
pretende oferecer é sugerir uma forma de organizar essa literatura disponível numa
lógica que permita ao leitor partir dos conceitos importantes sobre PMO até
informações sobre a implementação de tal estrutura.
Para essa revisão de literatura, consideramos também que não deveriam ser
excluídas da consulta as fontes atualmente aceitas como referências válidas, publicadas
na Internet. Essas, apesar de não poderem ser todas consideradas como “produção
científica”, são mantidas por pessoas e entidades profissionalmente envolvidas com o
assunto “gerenciamento de projetos”. Muitas vezes essas fontes contêm a importante
observação da prática no assunto, razão pela qual consideramos relevante para os
propósitos deste trabalho apresentar e discorrer sobre essas fontes.
2.1 Visão geral das fontes de referência
Com relação à literatura disponível, vários autores citam as origens do
gerenciamento de projetos como sendo da década de 1950 (BLOCK; FRAME, 1998, p.
1; CRAWFORD, 2002, p. 1; KERZNER, 2002, p. 143; PARTINGTON, 1996, p. 13-
21). Segundo Cleland e Ireland (2002), essa área de administração evoluiu e hoje “a
25
disciplina ganhou uma posição importante no léxico da gestão e na prática das
organizações modernas” (CLELAND; IRELAND, 2002, p. 3).
Ives (2005) relaciona várias referências sobre como o gerenciamento de projetos
tem se consolidado como “uma abordagem poderosa e genérica de gestão, com ampla
aplicação, além de projetos” (HEBERT, 2002; LASZLO, 1999; PINTO;
ROUHIAINEN, 2001 apud IVES, 2005).
As áreas de conhecimento do gerenciamento de projetos, como planejamento,
gerenciamento de comunicações, análises de riscos, gestão de recursos humanos,
viabilidade econômico-financeira de projetos, entre outras, contam vasta referência.
Para essas áreas, já se construiu uma grande quantidade de conhecimento e
documentada, incluindo pesquisas científicas e outros estudos formais.
Contudo, uma revisão do conteúdo de três anos (1994 a 1996) das principais
publicações científicas sobre gerenciamento de projetos (International Project
Management Journal, inglês, e o Project Management Journal, norte-americano),
revela que, até 1996, apenas 20% dos artigos abordam tópicos sobre o “escritório de
gerenciamento de projetos” (PARTINGTON, 1996, p. 13-21).
Mais recentemente, Henrie e Souza-Poza (2005) analisaram 770 artigos e 93
livros em uma pesquisa de revisão literária, e descobriram que até mesmo os aspectos
de cultura empresarial e corporativa de gerenciamento de projetos são pouco
explorados, apesar de serem críticos para o sucesso de qualquer iniciativa dessa
natureza (HENRIE; SOUZA-POZA, 2005).
Hobbs e Aubry (2005), numa pesquisa por internet, respondida por 255
representantes de PMOs, observaram que a maior parte da literatura disponível sobre o
assunto provém de consultores que implementaram PMOs e a variedade de formas e
funções de PMOs é grande; isso se deve, segundo eles, a três fatores principais: "1) o
26
assunto é relativamente novo; 2) comparar PMOs de empresas diferentes seria como
'comparar laranjas com maçãs' (sic) e 3) não existe um volume significativo em
pesquisa sistemática sobre o assunto; apesar de diferirem bastante entre si, os PMOs
parecem compartilhar dois pontos: são 'jovens' (têm menos de 3 anos) e suas equipes
são 'enxutas' (menos de 4 pessoas, sendo maioria de 2 a 3 pessoas por PMO). ... A causa
desse porte é a (ainda) visão de que o PMO é uma sobrecarga
5
administrativa, e a
questão de custos orienta essa formação reduzida” (HOBBS; AUBRY, 2005).
A literatura recente apresenta já alguma variedade de fontes de referência,
porém, os conceitos e definições relativas ao PMO ainda não se consolidaram, apesar de
haver alguma convergência dos autores em relação a essas definições. Além disso,
grande parte do conhecimento disponível provém de empresas e profissionais de
consultoria especializados na definição, implementação e por vezes prestação de
serviços de gerenciamento de PMOs, cada qual também com suas definições e padrões
próprios.
2.2 Projetos no ambiente corporativo
Uma questão chave dos negócios de uma empresa é sua capacidade para
implementar a estratégia e produzir resultados melhores do que com operações
rotineiras, e já há o reconhecimento de que essa capacidade está fortemente relacionada
à capacidade que a empresa tem de gerenciar seus projetos e programas (TURNER,
1993; CRAWFORD, 2004; CARVALHO, RABECHINI JR., 2005, p. 17).
As empresas não podem mais se pautar pelo “gerenciamento acidental”, mas
devem enfrentar ativamente desafios e explorar oportunidades (BLOCK; FRAME,
1998). Entre esses resultados geralmente estão a redução do ciclo de produção, redução
5
Do original em inglês overhead.
27
de custos e melhoria da qualidade dos produtos (CRAWFORD, 2002).
Prado (2004, p. 181) cita ainda cinco grandes áreas de ação das empresas, a
serem atendidas por projetos de estratégia: melhoria dos resultados econômico-
financeiros (pelo aumento de produtividade ou inovação – conquista de novos
mercados), acompanhamento do mercado e concorrentes (benchmarking), conservação
e melhoria da imagem, conservação e ampliação da capacidade técnica, social e
gerencial e o crescimento do nível tecnológico da empresa.
Para essas e outras ações, as empresas devem gerar, a partir de seus planos
estratégicos, uma “carteira de ações”, das quais advirão projetos, vistos nas empresas
nos últimos anos como “veículos para implementação de estratégias” e o interesse pelo
assunto tem levado a um melhor entendimento de como essas estratégias podem ser
melhor implementadas e como o gerenciamento de projetos pode e deveria ajudar no
processo, mesmo que essas disciplinas se desenvolvam separadamente (GRUNDY,
1998).
As metodologias de gerenciamento de projetos servem, portanto, naturalmente
ao processo de gestão estratégica de praticamente todo tipo de empresa. Grundy (1998)
destaca ainda que o gerenciamento de projetos tem sido aplicado fora do domínio
principal de “melhorar o hardware competitivo do negócio para o software competitivo
e o processo de implementação de mudanças”. Ele propõe uma estrutura, ou modelo,
para “enriquecimento do gerenciamento de projetos”, baseado em quatro etapas:
definição, diagnóstico, planejamento e implementação, e lições e encerramento
(GRUNDY, 1998).
Devido à sua natureza temporária e única, projetos sempre contém uma dose de
incerteza e risco (TURNER, 1993). As metodologias de gerenciamento de projetos
enfatizam a necessidade do ciclo planejar-executar-controlar, destacam a necessidade de
28
se estudar e planejar ações para minimizar os riscos inerentes aos projetos. Para garantia
do sucesso dos projetos, essas metodologias preocupam-se também com os processos de
comunicação no ciclo de vida dos projetos.
É importante, portanto, que os projetos sejam administrados de forma
estruturada. O Gerenciamento de Projetos compreende todas aquelas atividades de
coordenação de desenvolvimento dos projetos, da concepção à sua conclusão (algumas
vezes também o acompanhamento pós-execução).
Na sua definição mais comumente aceita, dada pelo PMI (2004), “o
gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e
técnicas às atividades do projeto a fim de atender aos seus requisitos.” (PMI, 2004, cap.
1, p. 8).
Em termos de negócios, uma definição encontrada na The Hutchinson
Encyclopedia (2002) define gerenciamento de projetos como a “técnica para relacionar
os recursos disponíveis (prazos, dinheiro e pessoas) aos objetivos dos projetos de
negócio (melhor prazo para conclusão, custos finais, etc.)” (HUTCHINSON, 2002).
As estratégias empresariais abordam diversos aspectos da administração e é
comum que sua implementação seja realizada por diversos projetos, grande parte das
vezes postos em execução simultaneamente. Assim, esses projetos devem ser avaliados,
selecionados, priorizados, balanceados e acompanhados de uma forma mais organizada
e controlada. A esse conjunto de projetos de uma empresa denomina-se portfólio de
projetos.
Há que se fazer aqui uma diferenciação entre 'portfólio' e 'programa', uma vez
que ambos os termos são comumente utilizados para se designar um conjunto de
projetos.
Programas são conjuntos de projetos inter-relacionados que visam um objetivo
29
comum, que não atingiriam se fossem gerenciados isoladamente (LYCETT et. al., 2004)
e podem incluir elementos de trabalho fora do escopo dos projetos individuais
pertencentes ao programa (PRADO, 2004, p.189).
Em gerenciamento de projetos, o termo 'portfólio' foi adaptado a partir do uso
em economia e finanças, onde originalmente significava um conjunto de investimentos
ou “carteira de títulos” (HOUAISS, 2004). Assim, se os projetos podem ser vistos como
investimento de recursos da empresa (financeiro, pessoal e material), o termo se aplica.
Portfólio de projetos é, portanto, o conjunto de programas e/ou projetos de uma
organização, quer estejam em fase de análise, quer estejam em execução, não
necessariamente inter-relacionados ou interdependentes, cujas características são
analisadas e utilizadas para as tomadas de decisão sobre seleção, priorização, execução
e remoção do portfólio (PRADO, 2004, p. 193; DE REYCK et. al., 2005).
Ghasemzadeh e Archer (2000) relacionam as dificuldades associadas com a
seleção de projetos no portfólio com vários fatores, entre eles:
• Existem múltiplos objetivos, normalmente conflitantes (por ex.: melhoria na
taxa de disponibilidade de um sistema x redução de custos operacionais);
• Alguns dos objetivos são qualitativos (por ex.: melhoria no índice de
satisfação de clientes);
• Incertezas e riscos podem afetar os projetos (por ex.: cenário
macroeconômico às vésperas de eleições nacionais);
• O portfólio selecionado pode ter que ser equilibrado em termos de fatores
importantes, como risco e prazos para conclusão (por ex.: atendimento de
exigências legais, reguladoras ou normativas);
• Alguns projetos podem ser interdependentes (por ex.: implementação de um
30
novo sistema de comércio eletrônico e a conclusão de uma fusão entre
companhias); e
• O número de portfólios possíveis normalmente é muito grande
(GHASEMZADEH; ARCHER, 2000).
Uma das referências mais citadas, Archibald (1976) descreve com propriedade o
ambiente de múltiplos projetos (hoje comumente descrito como portfólio de projetos) e
os fatores de conflitos que o gerente de projetos normalmente encontra nesse ambiente.
Na seqüência, ele descreve as possibilidades e recomendações para estruturação de um
PMO com tais atribuições (ARCHIBALD, 1976, cap. 4, cap. 5).
Prado (2005) destaca a importância da correta composição do portfólio de
programas e projetos quando o Planejamento Estratégico da organização é definido e se
estabelecem as metas dessa organização, segundo o seu horizonte de planejamento
(PRADO, 2004).
2.3 Conceituação de PMO
Quando a quantidade de projetos em uma organização (empresa, unidade de
negócios ou departamento) adquire um volume significativo, fica evidente que a
disciplina de gerenciamento de projetos deve ser abordada por uma maneira mais
consciente, e ao nível corporativo devemos saber como apoiar aqueles que conduzem os
projetos (BLOCK; FRAME, 1998). Torna-se necessária, então, uma estrutura de
controle suficiente para registrar e acompanhar os projetos. A essa estrutura
convencionou-se chamar de “Escritório de Projetos”, ou como é mais comumente
citado, PMO (Project Management Office).
Uma das primeiras referências a projetos e sua aplicação em diversas indústrias
31
que encontramos é de Cleland e King (1968). Nela os autores citam Kast e Rosenzweig
(1963) sobre como “rápidos avanços tecnológicos, mudanças nos complexos industriais,
o surgimento de uma força mundial adversa e tempos críticos de entrega” já
influenciavam, na época, a adoção do conceito de programas e projetos (KAST;
ROSENZWEIG, 1963 apud CLELAND; KING, 1968, p. 135-136). Os autores
adiantam também um destaque que o assunto teria, mas que somente nos últimos dez
anos se tornou evidente:
... O gerenciamento de projetos tem sido usada em agências governamentais e
indústrias envolvidas com o governo ... por algum tempo. ... A manutenção
de uma força efetiva de defesa, a pesquisa que tem sido conduzida na área de
viagem espacial e o crescente envolvimento do Governo Federal em outros
assuntos econômicos do país indica que as atividades governamentais
continuarão a expandir-se e que as técnicas de gerenciamento de projetos
também expandir-se-ão (CLELAND; KING, 1968).
Cleland e King (1968) introduzem os “escritórios de projetos” ao apresentar o
assunto de estruturas especialmente organizadas para o gerenciamento de projetos:
Mais e mais durante as últimas duas décadas, empreiteiros que trabalham
para agências governamentais têm estabelecido escritórios especiais, cada
qual responsabilizado pelo gerenciamento de um único projeto. ... Onde
múltiplos projetos são executados, alguma reorientação da organização
funcional se faz necessária. ... Pessoas de diferentes funções – tanto de linha
quanto administrativas – são reunidas para atingir um objetivo comum.
Pouco tempo depois, Archibald (1976) cita o PMO como organização para o
gerenciamento de projetos nas empresas e ressalta a importância que a função de
gerenciamento de projetos para as organizações. Para ele, essa forma de organização das
atividades de projetos permite uma maneira evolucionária de atribuir funções e definir
padrões. Isso permitiria à organização uma adaptação mais ágil às mudanças em
mercados, com estabilidade e eficiência. (ARCHIBALD, 1976, p. 17). Ao definir o
PMO, Alvin Toffler (apud ARCHIBALD, 1976, p. 16-17) teria dado “um nome bonito
e descritivo da estrutura organizacional que combina orientações funcional e por
projetos”:
32
“Estamos testemunhando não o triunfo, mas o desmembramento da
burocracia. Estamos, de fato, testemunhando a chegada de um novo sistema
organizacional que irá desafiar crescentemente, e eventualmente suplantar, a
burocracia. Esta é a organização do futuro, que eu chamo de Adrocracia. [...]
A alta taxa de rotatividade (em relações organizacionais) é mais
dramaticamente simbolizada pelo surgimento rápido do que os executivos
chamam de gerenciamento de 'projetos' ou 'força-tarefa'. [...] De fato, o
gerenciamento de projetos tornou-se reconhecida como uma arte executiva e
há um bando pequeno mas crescente de gerentes, tanto nos Estados Unidos
quanto na Europa, que migra de projeto para projeto, de companhia para
companhia, sem nunca envolver-se em rotinas ou operações de longo prazo.”
(TOFFLER apud. ARCHIBALD, 1976).
Sobre o ambiente multi-projetos, Archibald comenta:
“Planejamento centralizado e escritórios de controle têm sido estabelecidos
em algumas companhias para prover o necessário planejamento de
instalações de engenharia e produção e controle mestre de cronogramas, onde
esse ambiente multi-projetos existe. A coordenação desses planos e
cronogramas mestres e o acompanhamento adequado para garantir aderência
[aos planos] são executados por um gerente de planejamento que se reporta a
um gerente geral de divisão. Esses escritórios são úteis no treinamento e
desenvolvimento de indivíduos com habilidades especiais requeridas para
suporte ao gerenciamento de projetos nos maiores projetos.” (ARCHIBALD,
1976, p. 61).
Mais recentemente, Englund et. al. (2003) definem o PMO como ...
“Uma equipe dedicada a melhorar as práticas de gerenciamento de projetos
na organização” e que “agrega valor à organização, garantindo que os
projetos sejam conduzidos segundo procedimentos em alinhamento com a
estratégia organizacional e completados de forma a adicionar valor
econômico à organização” (ENGLUND et. al., 2003, p. xi-xii).
Outro autor também bastante referenciado em artigos de pesquisa na área de
projetos, Miranda (2003) define o PMO como “uma função de negócios responsável
pela coordenação de todos os trabalhos de projetos na organização e prover a infra-
estrutura e competência necessárias para o gerenciamento de múltiplos projetos”
(MIRANDA, 2003). O objetivo dessa estrutura, segundo ele, é garantir que os projetos
sejam completados conforme os objetivos da organização; sua função é operacional e
não apenas de geração de políticas.
Projetos, porém, segundo Mulally (2001), em geral apresentam problemas
comuns: ainda não são concluídos nos prazos e orçamentos, estão fora do processo de
gestão organizacional, sofrem da falta de abordagem consistente e de processos únicos,
33
seus gerentes de projetos não têm o devido reconhecimento em termos de autoridade e o
suporte da alta administração ainda é insuficiente ou mesmo inexistente. Dessa forma,
completa Mullaly, as empresas procuram estabelecer PMOs que:
“Atuem como pontos focais para projetos, criem consistência nas práticas de
gerenciamento de projetos, garantam as promessas de entregas dos projetos
nos prazos e orçamentos, permitam visualizar o cumprimento de prazos e
resultados e, ao mesmo tempo, 'isolem' as organizações desse ambiente de
projetos” (MULALLY, 2001).
Em uma pesquisa com 55 participantes (entre diretores, gerentes e equipes de
projetos) da indústria do que chamaram de “projetos de alta velocidade”, Milosevic e
Patanakul (2005) concluíram que:
1) uma certa padronização das habilidades de liderança em projetos e a definição
de processos em nível corporativo mostraram-se de grande interesse na padronização,
porque influenciaram mais no sucesso dos projetos que outras variáveis estudadas,
como comprovaram seus resultados de pesquisa. As habilidades de liderança
mostraram-se necessárias devido ao ambiente de projetos estudados, geralmente
empreendidos em estruturas matriciais, onde os gerentes de projetos tinham pouca ou
nenhuma autoridade sobre os membros das equipes, mas ainda mantinham a
responsabilidade pelo sucesso dos projetos. A padronização dos processos de
gerenciamento de projetos justifica sua importância devido à característica do ambiente
estudado, de grande quantidade de projetos sucessivos. Em tal ambiente, repetibilidade
geralmente significa mais previsibilidade e qualidade na entrega de resultados. As
métricas em projetos foram relacionadas como parte necessária dos processos
padronizados, mas de menor relevância. Finalmente, uma padronização da cultura de
projetos foi dada parte da cultura das empresas e como pertencente mais aos executivos
do que às equipes de projetos e, portanto, de menor relevância para essas equipes;
2) aquelas variáveis de alto interesse (liderança e padronização de processos) são
34
tipicamente ajustadas para alinhar-se aos propósitos estratégicos das empresas, uma vez
que uma das descobertas principais da pesquisa foi a de que não se pode padronizar os
processos de forma a atender a todas as empresas, pois suas estratégias diferem umas
das outras;
3) as empresas tendem a padronizar apenas até um certo nível suas práticas de
gerenciamento de projetos. Segundo descobriram, existe um ponto de inflexão, a partir
do qual a padronização pode ter o efeito contrário, isto é, de prejudicar o desempenho
dos projetos. Deve-se ter o cuidado de deixar uma margem de adaptação às diferentes
situações que os projetos podem enfrentar.
Na pesquisa de Milosevic e Patanakul (2005) foram estudadas 31 empresas do
setor de computação (desenvolvimento de software) e 24 da indústria eletrônica, que
apresentaram 37% de projetos com orçamentos superiores a US$ 5 milhões, 28% acima
de US$ 500 mil e 35% até US$ 500 mil.
Problemas semelhantes foram encontrados no Brasil, revelados em estudo do
PMI-RJ (“Benchmarking em Gerenciamento de Projetos Brasil: Relatório 2004”, (PMI,
2005, p. 119)), ilustrado no Gráfico 1, a seguir. O estudo cita problemas mais comuns
para o gerenciamento de projetos nas empresas como sendo: “falta de recursos
financeiros”, citado por 27% dos respondentes, “não cumprimento de orçamento”
(53%), “recursos humanos insuficientes” (60%), “recursos humanos sem as
competências necessárias” (33%), “problemas políticos / culturais, produtos mal
especificados, expectativas de clientes desalinhadas com a realidade de projeto” (em
média, aproximadamente 40%) e o problema “Número 1” para projetos: não
cumprimento de prazos, citado por 66% dos respondentes
6
(PINTO, 2005, p.119).
Prado (2004, p. 66-67) define o PMO como sendo “um pequeno grupo de
6
Nessa pesquisa do PMI-RJ, os respondentes poderiam citar mais de uma opção como resposta.
35
pessoas que têm relacionamento com todos os projetos da empresa” e cita suas
principais funções: prestar consultoria e treinamento, auditoria e acompanhamento de
desempenho. Tal definição, porém, é complementada por outros autores, e também as
funções desempenhadas, conforme veremos adiante. Além disso, nessa definição de
Prado, ele mostra uma preocupação com o fato de o PMO trazer consigo uma
sobrecarga administrativa para a empresa, apesar de reconhecer a necessidade de se ter
tal sobrecarga, dados os benefícios que esta pode trazer. Esse receio, porém, é negado
por Bernstein (2000), para quem “implementado corretamente, o PMO pode ser um
aliado no complicado processo de se conseguir atingir os objetivos principais dos
projetos”.
0% 10% 20% 30% 40% 50% 60% 70%
Não cumprimento dos prazos estabelecidos
Mudanças de escopo constantes
Problemas de comunicação
Recursos humanos insuficientes
Riscos não avaliados corretamente
Mudanças de prioridade constantes
Escopo do projeto com nível de detalhe insuficiente
Não cumprimento do orçamento estabelecido
Problemas na administração do trabalho/contratos de terceiros
Recursos humanos sem as gerências funcionais e o gerente de projetos
Problemas políticos
Produtos mal especificados
Expectativa do cliente desalinhada com a realidade do projeto
Problemas culturais
Falta de autoridade do gerente de projetos
Recursos humanos sem as competências necessárias
Recursos financeiros insuficientes
Falta de apoio da Alta Administração
Gráfico 1 Problemas mais freqüentes em projetos (PINTO, 2005, p. 119)
Kerzner (2002) cita que a idéia de uma estrutura formal dentro das organizações,
voltada ao desenvolvimento do gerenciamento de projetos, vem desde o final da década
de 1950 e o início da década seguinte, nas indústrias aeroespacial, militar e de
construção civil, que organizavam equipes completas para administrar os grandes
36
projetos de então. Exemplos dos projetos originados na área militar foram os projetos
Atlas, Polaris, Minuteman e Apollo, “em resposta à necessidade de desenvolver novos
mísseis balísticos, num regime de urgência, para combater supostas ameaças soviéticas”
(MORRIS, 2004, p. 2). Esses departamentos de controle dos projetos, porém, serviam a
apenas um projeto em especial, e cada projeto tinha sua própria estrutura de
gerenciamento, o que não é diferente nos dias de hoje para os grandes projetos. Na
década de 1970, o advento dos grandes computadores e software sofisticados para
cálculo de estimativas, cronogramas, redes de atividades, etc., fez surgir a necessidade
por especialistas no apoio às áreas de projetos no uso desses software, e “o papel do
departamento de projetos estava prestes a mudar”, segundo Kerzner (2002). Na década
seguinte, já com bastante dados e experiências acumuladas, a comunidade envolvida
com gerenciamento de projetos viu surgir uma grande quantidade de publicações que
orientavam a mudança de processos e metodologias, e os produtos de software
tornaram-se mais acessíveis e simples de serem usados. Na década de 1990 essa gama
de conhecimento recebeu destaque e popularização consideráveis, sendo então
reconhecida como estrategicamente importante para a boa condução de negócios
competitivos.
Cleland e Ireland (2002, p.61) ressaltam que o PMO não deve ter a intenção de
substituir os gestores no processo de tomada de decisão a respeito dos projetos, mas
contribuir fornecendo informações que apóiam esse processo. Segundo os autores, o
PMO “é o que a organização quer que ele seja [...] definido pelas necessidades de
negócio da organização e cresce com aquelas necessidades”. Um exemplo disso é o caso
do PMO do New York Times: criado ao final da década de 1990 para tratar das
implicações da virada de milênio, o PMO foi desfeito em janeiro de 2000, para ser
novamente reestruturado posteriormente no estilo “virtual”, com o suporte aos gerentes
37
de projeto sendo prestado via uma intranet. Segundo o vice-presidente executivo,
Michael Williams, o primeiro PMO era “centralizado e mão-de-ferro”, o que era
adequado para aquela ocasião, mas não adequado à cultura colaborativa da empresa. Já
o segundo PMO é mais adequado a esse estilo de trabalho (CIO, 2000b).
Em apenas duas pequenas seções (1.6.4 e 2.3.4), o PMBOK
7
(PMI, 2004)
discorre de forma muito genérica sobre a estrutura do PMO e não classifica nem tipifica
PMOs, deixando em aberto a série de atribuições, responsabilidades e autoridades de
um PMO com relação aos programas e projetos, sejam esses corporativos ou
departamentais. Na versão 2000 do mesmo PMBOK, encontramos apenas uma pequena
referência ao PMO, mencionando que ele pode operar desde funções de suporte aos
gerentes de projetos até a total responsabilidade sobre os resultados dos projetos (PMI,
2000, p. 17). Na sua 3ª Edição, de 2004, o PMBOK coloca o PMO com
responsabilidade executiva sobre todos os projetos da organização e que ele “centraliza
o gerenciamento de projetos sob seu domínio [e que ...] o PMO concentra-se em
coordenar o planejamento, priorização e execução de projetos e subprojetos que estão
diretamente ligados ao objetivo geral de negócios da organização ou do cliente” (PMI,
2004, p.17).
Crawford (2002, p. 55-59) considera que “o gerenciamento estratégico de
projetos é uma evolução das práticas de uma organização, praticamente paralela à
evolução dos negócios”. Para ele, a complexidade dos negócios surge com o
crescimento dos negócios e isso leva à necessidade de mudanças na organização. Com
essa crescente complexidade, os projetos começam a se inter-relacionar e influenciar
mutuamente, e níveis crescentes de integração entre os projetos começam a aparecer.
7
PMBOK: Project Management Body of Knowledge – obra publicada pelo PMI que contém um
compêndio do conhecimento em Gerenciamento de Projetos obtido a partir das trocas de experiências e
sessões de estudo promovidas pelo PMI em seus vários projetos e Capítulos nos diversos países.
38
Nesse cenário, é necessário um trabalho mais complexo para padronizar o processo de
gerenciamento de projetos e publicar uma metodologia, e esse trabalho deve ser função
de um escritório, departamento ou local central – “real ou virtual” – com pessoal
especializado para auxiliar a organização em suas necessidades de Gerenciamento de
Projetos. Para Crawford, os escritórios de projetos começaram com a criação de
estruturas para melhor planejar e controlar os projetos militares, na década de 1950. Daí
o enfoque inicial, segundo o autor, do Gerenciamento de Projetos em planejamento e
controle, apesar da estrutura tipo comando-e-controle militar ser um dos impedimentos
ao desempenho nos projetos, devido (entre outros fatores) à dificuldade de comunicação
e até mesmo de autoridade dos gerentes de projetos. O autor cita três níveis em que um
PMO pode situar-se, não mutuamente excludentes, uma vez que uma organização mais
complexa pode ter mais de um PMO: PMO Nível 1, ou Escritório de Projeto, para
gerenciamento de um único projeto; PMO Nível 2, ou Departamental, para
gerenciamento dos projetos de uma unidade organizacional (unidade de negócios,
divisão ou departamento) e o PMO Nível 3, ou Estratégico, para apoio ao
gerenciamento dos projetos de uma organização (empresa, filial ou corporação). Esses
três níveis de PMO estão ilustrados na Figura 1, adiante.
Esses três níveis são condizentes com os níveis também descritos por Englund,
Graham e Dinsmore (2003), e sobre qual nível de PMO é mais adequado a uma
empresa, Crawford propõe, entre outros, o estudo dos seguintes pontos: porte e
complexidade da empresa, grau de interdependência dos projetos entre as unidades de
negócios e funções, disponibilidade de recursos e competências de gerenciamento de
projetos já adquiridas ou desenvolvidas. Porém, independente do nível de PMO
escolhido, praticamente todos os escritórios de projetos desempenham algumas funções
comuns, que serão descritas adiante, e outras específicas a cada nível.
39
Figura 1 Três níveis de PMO (CRAWFORD, 2002, p. 56)
Em resumo, o PMO é a estrutura com que os gerentes de projetos podem contar,
em termos de processos e controles, para melhoria de seu desempenho (BERNSTEIN,
2000). O PMO também promove a evolução das práticas de gerenciamento de projetos,
ajuda a garantir que esses sejam executados segundo procedimentos padrão (alinhados
com a visão de futuro, estratégia organizacional e completados de forma a adicionar
valor à organização). Além disso, ele colabora também com o desenvolvimento da
maturidade do gerenciamento de projetos na empresa (ENGLUND; GRAHAM;
DINSMORE, 2003; CRAWFORD; PENNYPACKER, 2002).
2.4 Importância Estratégica do PMO
Como dissemos antes, projetos são “veículos de mudanças” (BLOCK; FRAME,
1998), pelos quais as empresas implementam suas estratégias, buscando formas de
melhorar seu desempenho e lucratividade. Essa melhora é conseguida quando se
consegue mais valor dos projetos, pela definição de uma prática padrão de
40
gerenciamento de projetos como uma filosofia gerencial corporativa, cujos objetivos de
negócios são suportados por um conjunto de projetos simultâneos, que devem ser
tratados de forma sistêmica (ENGLUND; GRAHAM; DINSMORE, 2003). Nessa
mesma linha de pensamento, Cleland e Ireland (2002) citam que “a tarefa de gestão é
facilitada quando o trabalho pode ser definido em projetos. A atribuição de deveres é
mais precisa, o controle é simplificado e quem executa o trabalho pode sentir seu
cumprimento” (CLELAND; IRELAND, 2002, p. 4). Projetos, para esses autores, são “a
combinação de recursos organizacionais reunidos para criar algo que não existia
previamente e que proverá uma capacidade de desempenho na definição e
implementação de estratégias organizacionais” (CLELAND; IRELAND, 2002, p. 4).
Além disso, projetos podem ser também a forma recomendada de como as empresas
pode não apenas resolver seus problemas técnicos, mas também lidar com mudanças
em seus ambientes de negócios (McELROY, 1996).
O interesse por processos de gerenciamento de portfólio, devido à penetração do
Gerenciamento de Projetos como forma de organizar o trabalho em muitas
organizações, tem crescido bastante e refletido até mesmo na quantidade de software
disponível.
Essa importante função do PMO (gerenciamento do portfólio de projetos)
consiste, resumidamente, em ter uma visão geral dos projetos em andamento e
potenciais, e decidir quais devem ser empreendidos, quais requerem ações imediatas
(gerenciamento de riscos, ações corretivas para qualidade, controle de custos, etc.) e
quais devem ser descontinuados.
Essa estruturação, segundo Crawford e Pennypacker (2002), pode ser feita em
três passos, considerando-se:
a) adequação dos projetos – considera como os projetos encaixam-se ao escopo
41
dos objetivos estratégicos da empresa, revisando a ambos: projetos atuais e o plano
estratégico;
b) utilidade dos projetos – que define o valor e o escopo dos projetos; isso deve
ser feito com o envolvimento de todos os principais envolvidos (stakeholders dos
projetos) para se desenvolver em conjunto os critérios de seleção e priorização dos
projetos;
c) equilíbrio do conjunto – envolve o estabelecimento do portfólio de projetos,
propriamente dito; trata de definir o processo pelo qual efetivamente será construído o
portfólio, considerando inclusive como os dados serão coletados, mantidos e analisados,
dadas as condições vigentes de sistemas de informação na companhia (CRAWFORD;
PENNYPACKER, 2002).
Podemos dizer, então: enquanto o Gerenciamento de Projetos preocupa-se com
“fazer certo os projetos”, o Gerenciamento de Portfólio concentra-se em “fazer os
projetos certos”, tomando em consideração o conjunto de projetos de uma organização e
o inter-relacionamento de seus resultados.
O Gerenciamento de Portfólio diferencia-se, ainda, do Gerenciamento de
Programas, que visa administrar um conjunto de projetos inter-relacionados, seja pela
comunalidade dos recursos que empregam, seja por alinhamento estratégico de alguma
forma.
O objetivo do Gerenciamento de Portfólio, portanto, é analisar esse conjunto de
projetos e decidir quais devem ser priorizados, quais podem ser postergados e até
mesmo quais devem ser removidos do portfólio (DE REYCK et. al., 2005).
Johnston (2001) cita que, sendo um dos meios que as empresas têm para melhor
se organizarem para a execução desses projetos, o PMO é também a estrutura que pode
propiciar uma vantagem competitiva e melhora no desempenho, se construído para ter a
42
visibilidade, responsabilidade e autoridade suficientes para conduzir as melhorias.
Numa definição resumida, Block e Frame (1998, p. 5) dizem que o PMO é
“composto por profissionais que servem às necessidades de gerenciamento de projetos
de sua organização”, além de também “promover o crescimento e o desenvolvimento do
profissionalismo do gerenciamento de projetos”; porém, a decisão de implementá-lo
requer apoio da alta administração, o que também é defendido de forma unânime pelos
autores do assunto. Dai e Wells (2004), citam Dinsmore, Fleming e Koppelman e
Knutson que concordam em que o PMO é implementado para “melhorar a eficácia do
gerenciamento de projetos ao propiciar a aquisição de conhecimento de falhas e
sucessos anteriores e ao prover uma ampla gama de suporte e serviços facilitadores”
(DAI; WELLS, 2004).
Para ilustrar a importância estratégica que pode chegar a ter um PMO,
analisamos uma pesquisa realizada pela revista eletrônica CIO Magazine (CIO, 2003).
A pesquisa, a que responderam 303 profissionais de diversos ramos da indústria, teve
participação de executivos de tecnologia, vice-presidentes e profissionais membros do
PMI, sendo que 52% das empresas têm faturamentos superiores a US$ 1 bilhão, 21%
faturam entre US$ 100 mil e US$ 1 milhão e apenas 18% têm faturamento inferior a
US$ 100 mil.
Naquela época, 21% dos respondentes informaram ter PMOs há mais de 3 anos,
portanto já no período de maturação daqueles PMOs, segundo Kerzner (2002), 21% não
tinham ainda 1 ano de PMO, mas a grande maioria, 53%, relatou ter PMOs entre 1 e 3
anos, à época da pesquisa.
A pesquisa revelou que ainda é um desafio para os profissionais de projetos
obterem o apoio da alta administração e a autoridade necessária para cumprir seus
objetivos. Além disso, a implementação de metodologias, padrões e práticas de
43
gerenciamento de projetos ainda enfrenta séria resistência nas empresas, e os dirigentes
que conseguiram definir PMOs em nível corporativo (39%) ou de divisão (27%) e
incluir nos comitês de projetos altos executivos (mais de 63%) conseguiram reduzir
essas barreiras.
Porém, os respondentes das empresas em que se implementou PMOs relatam
taxas de sucesso maiores em seus projetos que os provenientes de empresas que não o
fizeram (50% declararam que seus projetos melhoraram até 46% em termos de sucesso
– foram completados no orçamento e/ou no prazo e/ou nas especificações contratadas).
Nesses casos, os projetos assumidos pelos PMOs são também mais numerosos,
vultuosos e de maior importância estratégica, o que demonstra o grau de confiança que
os PMOs adquirem com tal suporte executivo.
Estão também entre os benefícios auferidos com a implementação de PMOs a
melhoria na satisfação de seus clientes (38%), redução de custos (27%), aumento na
produtividade dos funcionários (39%) e melhoria na satisfação dos clientes externos
(25%).
Permanecem, porém, alguns desafios, como: carga de trabalho excessiva (52%),
falta de autoridade do PMO (43%) e falta de suporte executivo (42%), para citar os três
maiores.
Em uma pesquisa feita no Brasil, pelo Capítulo Rio de Janeiro do PMI em 2004,
verificou-se: “dentre as organizações que participaram do estudo, a maior parte (34%)
cita o cargo de Diretor como responsável pelo gerenciamento do conjunto de projetos na
Organização” (PINTO, 2005, p. 43), o que confirma a crescente percepção das empresas
de que o PMO é importante em seu processo estratégico.
Entretanto, a pesquisa também revelou que praticamente a metade (49%) das
empresas consultadas ainda não havia estabelecido PMOs até aquela época, mas 37%
44
estavam com o processo de implementação em andamento (com previsão para
conclusão no mesmo ano), outros 29% instalariam em até 24 meses e somente 33%
mencionaram não ter planos para implementar um PMO.
Dos grupos de destaque na pesquisa, o setor de Construção mostra que pouco
mais de 80% das empresas tem pelo menos um PMO, seguido pelo setor de Tecnologia
da Informação e Comunicações, com pelo menos um PMO em aproximadamente 50%
das empresas.
Outra pesquisa, de Dai e Wells (2004), identificou, entre outros, três principais
motivadores para a adoção de PMOs: melhoria geral dos aspectos de gerenciamento de
projetos, visando uma redução global de “projetos problemáticos”, obtenção de uma
abordagem comum para os projetos e atingir um melhor uso dos recursos humanos e
materiais num ambiente de projetos múltiplos.
A conclusão a que chegaram os autores foi a de que existe, sim, uma diferença
positiva de desempenho nos projetos nas organizações com PMO, porém, essa diferença
não é estatisticamente significativa.
As áreas em que as organizações com PMO mostraram melhor desempenho
foram: definição de padrões e metodologias, manutenção de arquivos históricos,
treinamento em gerenciamento de projetos e consultoria e mentoring.
Não houve, porém, diferença estatística suficiente para dizer se o fato das
empresas terem ou não PMOs influiu quanto a resultados em suporte administrativo aos
projetos, administração de recursos humanos e relatório de desempenho de projetos.
A pesquisa conclui ainda que os PMOs em estágios iniciais de sua
implementação não mostram o que realmente se pode obter com essas estruturas, e as
pesquisas deverão ser melhor projetadas para obter essas informações.
45
Considerando a integração dos sistemas de gerenciamento de uma empresa,
Sato, Dergint e Hatakeyama (2004) fizeram uma correlação do uso de PMOs também
com o propósito de melhorar a produtividade sistêmica em uma organização, conforme
a teoria de Ludwig von Bertalanffy (“Teoria Geral de Sistemas”, 1951).
Um sistema pode ser definido como um “conjunto, composição ou combinação
de partes e coisas que forma um todo complexo ou unitário” e pelo ponto de vista do
conceito de sistemas, portanto, considera-se que toda organização é um sistema,
composto de partes que têm, cada uma, seus próprios objetivos. (CLELAND; KING,
1968, p. 10-11).
Assim, ao considerar-se que os projetos são uma parte da empresa, consideram-
se os efeitos do uso de recursos por esses projetos, suas implicações nas demais
operações e projetos da empresa e suas possíveis influências nas relações da empresa
com o ambiente exterior em que ela está inserida. Essa forma de pensar, e de
administrar projetos, leva, segundo Sato, Dergint e Hatakeyama, o PMO a contribuir
ainda mais com a gestão da empresa como um todo. Os objetivos dessa organização
seriam mais bem atingidos, mesmo que a sacrifício dos objetivos de determinadas áreas
da empresa, “uma vez que o que é melhor para o todo não é, necessariamente, o melhor
para cada componente do sistema” (CLELAND; KING, 1968, p. 11).
Ao discorrer sobre a importância estratégica do PMO, Archibald (2003b) define
que projetos são empreendimentos complexos que criam produtos novos, instalações,
serviços e eventos, entre outras coisas, realizam mudanças organizacionais e
recuperações de desastres naturais ou causados pelo homem. Para ele, a disciplina de
gerenciamento de projetos evoluiu dos princípios e métodos mais tradicionais para
gerenciar organizações funcionais clássicas.
Esses métodos, contudo, não funcionam tão bem para gerenciamento de
46
programas e portfólios, que são como desafios para as empresas com relação a executar
com sucesso os projetos certos em prazos certos e ainda prover um local de desenvolver
as diversas habilidades necessárias para os especialistas que contribuem com os
projetos. Em relação aos projetos, Archibald cita duas grandes classificações das
empresas: as que são orientadas a projetos, ou seja, aquelas em que o negócio é feito de
projetos, e as dependentes de projetos, cujos negócios dependem de projetos para
crescimento, já que sua função principal é gerar produtos ou prover serviços
(ARCHIBALD, 2003b).
Para as empresas orientadas a projetos, cujos exemplos podem ser as
empreiteiras, desenvolvedoras de software ou firmas de consultoria. Suas estratégias de
são caracterizadas pelo tipo, porte e natureza dos projetos, bem como as escolhas de
como os recursos para esses projetos são obtidos.
Na empresas dependentes de projetos, os projetos são geralmente financiados
internamente, para suporte às principais linhas de negócios. São exemplos desse tipo de
empresa: bancos, indústrias de manufatura, transporte, comunicações e serviços
públicos, entre outras.
2.5 O PMO na Estrutura Organizacional
No que diz respeito à sua organização para o gerenciamento de projetos, as
empresas podem ser orientadas a projetos ou tradicionais, mais orientadas a operações.
Ambas podem planejar e implementar ações por projetos, mas nas primeiras a principal
fonte de renda provém dos projetos que executam (PMI, 2004, p. 27).
O PMO, quando instituído formalmente, é uma camada de controle entre a alta
administração e os gerentes de projetos, podendo ser responsável desde projetos
47
isolados até conjunto de projetos, ou programas, constituindo-se, assim, parte integral
da estrutura de governança e gerenciamento de projetos (BERNSTEIN, 2000).
A definição de Block e Frame (1998, p. 78), é mais simples: “o PMO deve ser
localizado onde faça mais sentido [para a organização]”. Eles citam o exemplo dos
bancos e grandes empresas imobiliárias, onde os PMOs geralmente estão junto às áreas
de tecnologia da informação, pela necessidade de comunicação eletrônica entre pessoas
e organizações envolvidas.
Várias pesquisas, entretanto, reforçam a necessidade do apoio da alta
administração como “fator crítico de sucesso” (por exemplo, SOFIAN (2003, p.4) e
STANLEIGH (2005, p. 14)) e relatos de consultorias que implementaram PMOs
indicam que o PMO que se situa no nível mais próximo da alta administração
geralmente tem mais chances de sucesso (McMAHON; BUSSE, 1999 apud
ARCHIBALD, 2003, p. 155-156; p. 195).
O PMO atua como agente de seleção e priorização dos vários projetos propostos
pelas diversas áreas de negócio de uma organização e nessa situação uma quantidade de
conflitos é natural.
A implementação do PMO é uma tarefa de longo prazo e requer dedicação de
vários níveis gerenciais ao longo do projeto. O responsável pelo PMO necessita de uma
demonstração constante de que possui autoridade e autonomia para planejar e
implementar as mudanças necessárias (TURNER, 1993).
Além disso, quando está mais formalmente envolvida no processo de gestão do
PMO, a autoridade superior tem mais subsídios para deliberar quando não se alcança o
consenso entre os gestores envolvidos ou as decisões a serem tomadas requerem maior
nível de alçada.
Para essa integração do PMO na estrutura organizacional, deve-se considerar,
48
antes, qual é a estrutura vigente: funcional pura, matricial fraca, matricial balanceada,
matricial forte ou orientada a projetos (projetizada), descritas a seguir.
2.5.1 Estrutura Funcional Pura
Na estrutura funcional pura (Figura 2), a hierarquia de comando é clara e cada
funcionário reporta-se a apenas um gestor.
Figura 2 Estrutura organizacional “Funcional” (PMI, 2004, p. 29)
Nessa estrutura os profissionais são reunidos em departamentos conforme sua
especialidade e os projetos que eles empreendem estão restritos às funções dos
departamentos. Quando é necessário ir além dessas fronteiras, deve-se percorrer a
hierarquia para se chegar aos outros especialistas (PMI, 2004, p. 28).
Mesmo apresentando vantagens, como a economia de escala dentro de
departamentos funcionais e o maior desenvolvimento de conhecimentos e habilidades
(DAFT, 2002, p.88), esse ambiente altamente hierarquizado não é favorável ao trabalho
de gerenciamento de projetos, pois estes são de natureza multidisciplinar, o que exige
coordenação horizontal e ágil (DINSMORE, 1990).
49
Para essas estruturas, o PMO poderia ser alocado como assessoria ao executivo-
chefe nas funções mais voltadas à visibilidade dos projetos em andamento. Coordenar
os projetos com um PMO assim poderia trazer conflitos com gestores funcionais,
principalmente se o responsável pelo PMO não tiver cargo de gestor na estrutura
hierárquica da empresa. A Figura 3 mostra a localização desse PMO.
Figura 3 O PMO na estrutura organizacional “Funcional”.
2.5.2 Estrutura Projetizada
Na estrutura projetizada (Figura 4), a maioria dos profissionais trabalha em
projetos e respondem diretamente aos gerentes de projetos, que têm autoridade e
independência para obter junto aos demais departamentos os recursos de que necessitam
(PMI, 2004, p. 29).
50
Figura 4 Estrutura organizacional “por Projeto” (PMI, 2004, p. 29)
Dinsmore (1990, p. 99) referencia a estrutura projetizada como “estrutura tipo
'força-tarefa'“, ideal para o trabalho de projetos, em que o gerente de projetos trabalha a
partir de um Termo de Abertura de Projeto (Project Charter) que lhe confere autoridade
e responsabilidade e, às vezes, até prestígio.
Sobre essa estrutura, Dinsmore (1990, p. 100) cita também que ela “é orientada a
tarefas, a equipes e não fica presa pelas restrições normalmente impostas pelas
organizações externas [ao projeto] e ainda fica livre de conflitos externos”, mas o autor
ressalta também que essa forma de organização apresenta algumas desvantagens: devido
à natureza temporária dos projetos, mobilizar e desmobilizar pessoal é uma tarefa difícil
e é difícil manter o nível de qualificação do pessoal, pois atividades em atividades
funcionais mais estáveis podem atrair os especialistas.
O PMO nessa estrutura poderia ser o mesmo ilustrado para a estrutura funcional
(Figura 3), uma vez que ainda temos a função de coordenação dos projetos sob a
responsabilidade dos gerentes de projetos, que cuidam, cada qual, de mais de um projeto
51
simultaneamente. O PMO seria, assim, um facilitador a esses gerentes de projetos nas
tarefas de reporte da situação de cada projeto e dos portfólios de cada gerente.
Frame (1987) comenta as estruturas projetizadas e fala sobre um forte consenso
existente entre os profissionais de projetos, de que esses deveriam ser executados fora
das organizações a que servem, e que isso é irrealista. Para ele, é preciso entender essas
limitações e trabalhar com elas, ao invés de se lutar contra elas. As limitações impostas
aos gerentes de projetos, continua Frame, são naturais e decorrem da natureza
temporária e única dos projetos, além desses serem verdadeiros sistemas, com muitas
interfaces e uma rotatividade natural nas equipes, devido às mudanças nas necessidades
de habilidades e capacidades em cada etapa do projeto.
Valeriano (1998, p. 79) menciona que nessa estrutura, além dos problemas
citados, há também uma dificuldade de manutenção da capacitação profissional:
"Há o risco de que os profissionais, uma vez afastados por longo tempo fora
de sua base 'técnico-científicas' (seus órgãos funcionais), venham a se
desatualizar, pois se acham devotados a transformar seus potenciais em
trabalho produtivo." (VALERIANO, 1998, P. 79).
2.5.3 Estruturas Matriciais
As estruturas matriciais são estruturas organizacionais mistas das duas acima, e
podem ser: fraca, balanceada ou forte, conforme a autoridade dos gerentes de projetos,
seu tempo de dedicação aos projetos, alocação de pessoal e o suporte administrativo aos
projetos (PMI, 2004, p. 30). Segundo Valeriano (1998, p. 82), a organização matricial
procura conciliar as vantagens da convivência departamental com o desempenho nos
projetos, apesar de estudos mencionarem vulnerabilidades das matrizes organizacionais,
devido ao conceito errôneo de que estão relacionadas com o processo decisório em
grupo e de sua tendência às disputas de poder e anarquia (,).
Para essas as estruturas matricial fraca e matricial balanceada, o PMO poderia
52
localizar-se como ilustrado na Figura 3, porém, com mais autonomia sobre os projetos
individuais. O responsável pelo PMO teria condições, por exemplo, para agir sobre a
priorização e seleção do portfólio de projetos.
As duas últimas estruturas matriciais (forte e composta) admitem a existência de
um departamento exclusivamente encarregado da coordenação de projetos.
O PMO indicado, nesses casos, poderia ser o "estratégico" ou "corporativo" (v.
Figura 5), com autonomia para a negociação de prioridades com as áreas da empresa.
Além disso, esse PMO teria o controle (autoridade) sobre as equipes durante os projetos
e os gerentes de projeto são seus funcionários, alocados conforme suas capacitações e
habilidades. Para esses gerentes de projetos, o PMO é o responsável pelo plano de
carreira.
Figura 5 O PMO nas estruturas matriciais, adaptado de PMI (2004).
Em relação à dificuldade que se encontra para implementar estruturas matriciais,
Dinsmore (1990) alerta que nem sempre é possível (ou viável). Segundo ele, devem ser
53
atendidas pelo menos duas de três condições para justificar o uso de estruturas
matriciais, com o que concorda Daft (2002, p. 94-95):
1) existe pressão externa para concentração de esforços em dois ou mais
produtos críticos (necessidade de se atender a determinada demanda de cliente por uma
só pessoa como porta-voz, mesmo que internamente à empresa que empreende o projeto
as soluções sejam obtidas por diversas especialidades profissionais);
2) pressão por uma alta capacidade de coordenação e processamento de
informações (a característica de horizontalidade das matrizes lhe conferem vantagem
sobre as demais estruturas em termos de como as informações são transmitidas entre os
membros dos projetos) e
3) pressão por compartilhamento de recursos (a matriz se mostra mais eficiente
no uso dos recursos que as demais estruturas organizacionais).
Em um estudo de caso sobre a implementação e uso de uma organização
matricial no Bureau de Engenharia da Prefeitura Municipal de Los Angeles, Kuprenas
(2003), relaciona as seis principais dificuldades encontradas e como essas foram
vencidas:
1) a confusão na definição de papéis e responsabilidades entre gestores
funcionais (que lideram as equipes de desenvolvimento) e os gerentes de projeto (que
supervisionam o desempenho dos projetos) foi resolvida com a criação de listas
sumarizadas de papéis e responsabilidades para cada função;
2) a dificuldade de monitorar o grau de comprometimento dos gestores
funcionais com os projetos em que são envolvidos compreendeu um modelo de relatório
de custos, além de um novo sistema de reporte;
3) influências políticas sobre a atribuição de recursos, que levam a atrasos e
54
mudanças nos projetos e alteram a priorização dos projetos, foram minimizadas com a
introdução de um protocolo de priorização de projetos aprovado pelo Secretário de
Obras e posterior adoção do protocolo como padrão pelo bureau;
4) necessidades de adequação dos profissionais à nova estrutura, que
compreende ambigüidade de autoridade (hierarquia), aumento nas interfaces de
comunicação e maior necessidade de habilidade de trabalho em equipe, foram supridas
com treinamento específico em mudança, comunicação e trabalho em equipe;
5) necessidade de um programa contínuo de desenvolvimento dos gerentes de
projetos, de forma a se atingir uma linguagem comum e uniformidade no entendimento
do processo de gerenciamento de projetos: sessões semanais de mentoria
8
foram
conduzidas, tanto para equipes funcionais quanto para as equipes de projetos e
mensalmente os gerentes de projetos eram reunidos para uma sessão de troca de
experiências e problemas;
6) para que o lado funcional não se fortalecesse em relação ao lado de projetos,
gestores funcionais começaram a ser avaliados com relação a: consecução dos
objetivos; indicadores de número de projetos que completam e horas de trabalho
despendidas para isso, com base em um processo anual de planejamento das atividades.
Em nível de projeto, não se identificou diferenças significativas de custos de
desenvolvimento dos projetos e em nível de programas e portfólio houve ganho em
termos de valor agregado ao município, pois o desempenho na entrega dos projetos
melhorou após a introdução da organização matricial, o que otimiza os gastos da verba
municipal (KUPRENAS, 2003).
8
Vide Apêndice C – Mentoria.
55
2.5.4 Comparação das Estruturas
O PMBOK (PMI, 2004, p. 28) ilustra a comparação entre os tipos de estruturas
organizacionais, no âmbito de gerenciamento de projetos:
Quadro 1 Tipos de estruturas organizacionais (PMI, 2004, p. 28)
Em uma pesquisa sobre a influência do uso de estruturas totalmente projetizadas
ou somente funcionais, Might e Fischer (apud DAI; WELLS, 2004) concluíram que
nenhum dos extremos tem correlação direta com o desempenho dos projetos. Contudo,
os modelos intermediários (matriz fraca, forte e balanceada) mostraram alguma relação
positiva nesse sentido.
Para Crawford (2002, p.65), as empresas organizadas em matriz forte ou
projetizada experimentaram mais sucesso que aquelas que adotaram organizações
funcionalmente ou matrizes fracas. Segundo Daft (2002), isso se dá pela facilidade que
a estrutura matricial confere à organização para alocar recursos aos projetos e a
capacidade de adaptação dessa estrutura às mudanças nas exigências externas.
Mudanças na estrutura de gerenciamento de um projeto em andamento, porém,
apresentam efeitos negativos significativos no desempenho dos projetos, seja esta
56
formada só com o gerente de projeto ou por uma equipe de administração exclusiva do
projeto, conforme descrito por Parker e Skitmore (2005). Segundo eles, sob o ponto de
vista do gerenciamento dos projetos, seis pontos são de relevância, na análise da
rotatividade: 1) momento da saída (dos gestores de projetos); 2) transferências internas;
3) diferenças de sexo; 4) os próprios resultados dos projetos; 5) perda de conhecimento
organizacional e 6) os efeitos da chegada de novos gestores. A maioria dos respondentes
da pesquisa considerou que essas mudanças afetam os projetos negativamente, sendo
que a promoção ou transferência interna ao projeto diminui esses efeitos negativos
(PARKER; SKITMORE, 2005).
Com relação à autoridade do PMO, a pesquisa de Hobbs e Aubry mostrou outra
grande variedade entre os PMOs: 41% deles são de nenhuma ou pouca autoridade para
tomada de decisão, sendo inferior a 15% os que têm 'autoridade muito significativa'.
Isso pareceu conduzir a outra constatação interessante: há também bipolaridade na
questão 'o PMO mantém os Gerentes de Projetos': 34% dos PMOs analisados mantém a
totalidade dos GPs e 29% disseram não ter os GPs em seus quadros.
Essa autoridade do PMO, o padrão de comunicação nos projetos e a
diferenciação de cargos na organização, foram utilizadas por Vasconcelos e Hemsley
(2002) para propor um “índice de matricialidade” da organização, com o qual ela
poderia melhor decidir sobre que tipo de estrutura gerencial e de controles adotar e
assim reduzir as eventuais resistências à implementação de uma das estruturas
matriciais para o gerenciamento de seus projetos (VASCONCELLOS; HEMSLEY,
2002 apud. RABECHINI JR., 2002, p. 10-14).
O estudo do Capítulo Rio de Janeiro, do PMI (PMI-RJ), (PINTO, 2005, p. ),
mostra que, 41% das empresas pesquisadas organizam-se em estrutura funcional e 28%
em matriz fraca. A estrutura projetizada foi relatada por 20% dos respondentes
57
(mencionada por
2
/
3
das empresas de construção) e a matricial forte por apenas 11%.
2.6 Tipos, Níveis e Funções do PMO
Os tipos possíveis de PMO são variados, de empresa para empresa, e também é
possível também que se tenha mais de um PMO numa mesma organização. Hobbs e
Aubry (2005), identificaram em uma pesquisa que, em termos de definição [de seus
PMOs], 60% das organizações denominam os escritórios de projetos como PMO
mesmo, já feita a diferença para 'PO - Project Office', que é a estrutura para administrar
um projeto complexo. A grande maioria (55%) disse que seu PMO é único (central) na
organização, mas 25% disseram ter 'mais de um PMO' na organização. Os 20%
restantes disseram que seu PMO se relaciona com pelo menos outro PMO na empresa.
(HOBBS; AUBRY, 2005).
Crawford define três tipos para um PMO: Escritório de Controle de Projetos,
Escritório de Projetos como Unidade de Negócio e Escritório Estratégico de Projetos
(2002, p. 55-59). O PMO Tipo 1 (v. Figura 6, abaixo) é um PMO típico para projetos
únicos ou grandes (como os projetos do Ano 2000 foram para várias empresas),
geralmente com vários cronogramas a integrar, constituindo-se, assim, num programa.
Pode ter vários gerentes de projetos, cada qual responsável por um projeto completo do
programa, atuando independentemente, mas com objetivos que devem ser atingidos
coordenadamente. Além disso, normalmente compartilham recursos e os custos devem
ser controlados de maneira única, para se encaixarem no orçamento previsto para o
programa a que atendem. O gerente do PMO é o gerente de todos os projetos, e deve
apresentar os resultados quanto ao alcance de metas, custos, prazos, etc. Dessa forma, o
PMO Tipo 1 é o responsável por construir eficiência no projeto, através da aplicação
58
das práticas de gerenciamento de projetos: o plano do projeto, cronograma e todos os
demais planos (comunicações, riscos, suprimentos, etc.) tornam-se efetivamente em
ferramentas de comunicação do projeto com o restante da empresa.
Figura 6 O PMO Nível 1, segundo Crawford (2002, p. 56).
O PMO Tipo 2 (v. Figura 7, adiante) é uma estrutura de apoio a uma unidade de
negócios ou departamento, através da integração de vários projetos e da coordenação do
uso de recursos comuns. Esse PMO provê a visibilidade de comprometimentos de
recursos e do andamento dos projetos em geral. Além das atribuições do Tipo 1, o PMO
Tipo 2 provê à organização um ganho com a excelência em gerenciamento de projetos
para um departamento, unidade de negócios ou uma organização inteira, ao invés de se
concentrar em apenas um grande projeto. Ele introduz o conceito do gerenciamento
multiprojetos, com coordenação do uso de recursos e gerenciamento das
interdependências entre as áreas funcionais. Adicionalmente, o PMO Tipo 2 trata do
gerenciamento de grandes mudanças culturais na organização e leva o gerenciamento de
59
projetos a uma audiência mais ampla e distribui mais a especialidade de gerenciamento
de projetos pelas demais áreas da empresa. Por exemplo, Cicmil (apud IVES, 2005) cita
que “a cultura e o comportamento organizacionais deveriam ser considerados um
elemento do projeto [de mudança]”, pois, para ele, o gerenciamento de um projeto de
mudança é bem diferente do gerenciamento de um projeto operacional, como uma
construção, por exemplo. A diferença estaria, segundo Cicmil, nas competências
necessárias, pois as mudanças lidam essencialmente com as pessoas.
Figura 7 O PMO Nível 2, adaptado de Crawford (2002, p. 56)
O PMO Tipo 3 (v. Figura 8, adiante), chamado por Crawford de “Escritório
Estratégico de Projetos”, serve como centro de suporte corporativo aos projetos, com
um repositório central de processos, padrões e metodologias. Este PMO coordena o
gerenciamento do portfólio de projetos de acordo com as estratégias das organizações.
Nesse PMO surge o conceito de um “comitê gestor de projetos”, composto pelo gestor
do próprio PMO e demais executivos, representantes das unidades de negócios e
departamentos funcionais. Em organizações com múltiplas unidades de negócios,
60
múltiplos departamentos de suporte e vários projetos em andamento simultaneamente,
em cada unidade de negócios, um PMO Tipo 2 teria dificuldades em exercer autoridade
corporativa sobre o gerenciamento de recursos entre os projetos, incluindo o alcance de
metas corporativas, como margens de lucro a obter, estratégias de penetração de
mercado, expansão de linhas de produtos, expansão geográfica, entre outros. Um PMO
Tipo 3 tem esse nível corporativo de autoridade, necessário à seleção, priorização e
monitoramento dos projetos e recursos que implementam a estratégia corporativa, agora
tratando os projetos em um portfólio abrangente. Essa definição de Crawford concorda
com a de Miranda (2003), que defende um PMO que “atua como um agente para a alta
administração, provendo consultoria, coordenação e supervisão ... responsável pela
execução dos projetos, sem ser substituto de gestores ou patrocinadores com relação à
priorização dos projetos e seu controle final”.
Figura 8 O PMO Nível 3, adaptado de Crawford (2002, p. 56)
Contudo, independente de onde se situe na organização da empresa, o gerente do
PMO deveria, na visão de Miranda (2003), “ter acesso direto ao mesmo nível de
61
gerenciamento que os donos dos recursos”. Isso se justifica por que lhe “ajudaria a
manter a atenção dos esforços do PMO nos interesses da organização como um todo, ao
invés dos interesses de uma área em particular”. Essa é a autoridade que o gerente do
PMO deveria ter para resolver conflitos quando projetos entrem em competição por
recursos comuns (MIRANDA, 2003).
Uma visão com um pouco mais de detalhes sobre a estruturação do PMO é a de
Hill (2004), que define o PMO numa organização como uma estrutura com
competências evolutivas e funcionalidades a serem assumidas ao longo do tempo, em
cinco estágios:
Figura 9 O “Competency Continuum”, adaptado de Hill (2004, p. 46)
Nesse modelo, cada nível subentende um escopo particular de capacidade
funcional; os estágios superiores implicam em haver-se previamente conquistado as
competências dos estágios anteriores; porém, mesmo devendo esses estágios ser
62
obrigatoriamente escalados um por um, a organização pode executar atividades em mais
de um nível, num dado instante. Assim, pode-se ter vários Project Offices e um Centro
de Excelência corporativo simultaneamente.
É crítico, portanto, que se identifique claramente qual o nível de PMO que
atenderá melhor às necessidades em Gerenciamento de Projetos da empresa, bem como
se ela deve ter apenas um, corporativo, centralizador ou vários, conforme as
necessidades de suas unidades de negócio. As funções recomendadas para um PMO
serão, então, adicionadas e adaptadas conforme essas necessidades. Normalmente, o
Estágio 3 será suficiente para a maioria das empresas, uma vez que o custo para atingir
o Estágio 5 pode ser muito superior aos benefícios auferidos. Esses níveis encontram
descritos a seguir:
• Estágio 1, “O Escritório de Projeto”, é de responsabilidade de um gerente
de projeto, responsável por um ou mais projetos. Nele estão definidas as
práticas preferenciais de gerenciamento de projetos que compõem os padrões
de excelência para o gerenciamento de cada projeto individual.
• Estágio 2, “PMO Básico”, é o primeiro a lidar com a consolidação da
supervisão e controle dos projetos da organização, visibilidade de status,
desempenho e análises, padronização dos processos e estabelecimento da
disciplina de Gerenciamento de Projetos.
• Estágio 3, PMO Padrão, concentra-se em otimizar o desempenho de pessoas
e dos projetos, podendo evoluir do PMO Estágio 2 ou ser construído
inteiramente novo. Requer pessoal em tempo integral, capacitado para
definir, implementar e facilitar o uso das funcionalidades de um PMO.
• Estágio 4, PMO Avançado, tem a missão principal de integrar as
necessidades de negócios ao ambiente de projetos, o que requer que o PMO
63
não seja novo, mas que tenha evoluído dos níveis anteriores – a cultura de
Gerenciamento de Projetos já deve ter sido absorvida pela empresa.
• Estágio 5, o Centro de Excelência, tem uma responsabilidade de âmbito
corporativo sobre as operações de gerenciamento de projetos e concentra-se
em interesses estratégicos de negócios. Pode ser evolução dos demais níveis
ou criado separadamente, independente de quantos PMOs existam na
empresa, a fim de coordená-los com orientação estratégica.
A maioria da literatura disponível sobre o assunto, como mostra uma análise da
literatura feita por Kloppenborg e Opfer (2002), em que revisaram mais de 3.500
artigos, journals e papers determinou que, no estado da arte da disciplina estão os
seguintes assuntos:
• Padronização de processos e ferramentas
• Mais uso de tecnologias de internet para comunicação e colaboração
corporativas
• Uso das práticas e filosofias mais aceitas para o gerenciamento de projetos
• Mais contratação (outsourcing) de gerenciamento de projetos pelas grandes
corporações
• Aumento na ocorrência de projetos “não tradicionais”, como voluntariado,
campanhas de arrecadação de fundos, etc.
• Evolução da demonstração, pelos gerentes de projetos, de suas capacidades
de liderança, e não apenas de gestão;
• Movimento em oposição aos “super-projetos”;
• Refinamento do escopo dos projetos, com mais ênfase aos requisitos de
negócio e benefícios mensuráveis;
64
• Evolução da seleção e priorização dos projetos como questão chave
• Aumento da ênfase na formação e treinamento formais em gerenciamento de
projetos
• Mais ênfase no gerenciamento de riscos em geral e mais oportunidades para
os gerentes de projetos receberem treinamento no assunto
• Aumento de ênfase nas comunicações em projetos, planejamento de
comunicações, em particular gerenciamento de stakeholders.
Na pesquisa de Hobbs e Aubry (2005), com relação aos papéis organizacionais
exercidos pelos PMOs, cinco grupos de funções puderam ser identificados, nessa ordem
de importância:
• Monitorização e controle de desempenho dos projetos
• Desenvolvimento de metodologias e competências dos GPs:
• Gerenciamento estratégico de projetos:
• Gerenciamento de multi-projetos:
• Aprendizado organizacional:
Além dessas funções, outros quatro grupos foram identificados, porém com
presença estatística menos destacada. Também em ordem de importância verificada:
• Prover um conjunto de ferramentas padronizadas, porém não impostas:
• Monitorizar e controlar o desempenho do PMO
• Executar tarefas especializadas para os GPs;
• Gerenciar as interfaces com clientes/usuários dos projetos;
É claro que, no mundo real, praticamente não se consegue tal separação clara de
funções e autoridades em relação aos projetos, e os PMOs normalmente são
composições híbridas dessas funções.
65
Contudo, o maior erro que se tem notado é querer definir um PMO de
abrangência corporativa (PMO Estratégico) e dotá-lo apenas com pessoal inexperiente e
pouca influência na organização (nível de projeto). Deve-se, portanto, decidir antes
quais são seus objetivos e então definir a estrutura do PMO de acordo com o porte da
organização e aqueles objetivos.
Dai e Wells (2004) mencionam que o PMO é um importante candidato na
contínua jornada para a promoção e sustentação da melhoria do desempenho dos
projetos, sendo a definição de padrões e métodos para projetos os dois principais fatores
dessa melhoria. Na pesquisa, esses autores identificaram diferenças nos conceitos de
PMO, para os quais há vários nomes (PMO, PO – Project Office, SPO – Strategic
Project Office, etc.), e preferiram usar o conceito de “presença do PMO”, ao invés de
especificamente um nome entre esses. Nesse conceito, sua revisão de literatura indicou
seis categorias de serviços e funções do PMO:
• Desenvolvimento e manutenção de padrões e métodos para o gerenciamento
de projetos;
• Desenvolvimento e manutenção do histórico de projetos centralizados;
• Suporte administrativo aos projetos;
• Auxílio na composição de recursos humanos dos projetos;
• Consultoria e 'mentoring';
• Treinamento em gerenciamento de projetos.
Para Block e Frame (1998), o PMO desempenha funções variadas por
organização, mas nos últimos anos essas funções têm convergido e os PMOs atualmente
executam tipicamente uma ou mais das seguintes funções:
• Fornecer suporte ao gerenciamento de projetos para as equipes de projetos;
66
• Consultoria e 'mentoring' em gerenciamento de projetos (v. Anexo C);
• Desenvolvimento e manutenção de metodologias e padrões;
• Treinamento em gerenciamento de projetos;
• Prover à organização os gerentes de projetos;
Crawford (2002, p. 70) define que um PMO pode ter seis elementos principais:
O primeiro elemento é o conjunto de funções principais de suporte a projetos – a
chamada “arte” de gerenciar projetos lida com assuntos como liderança, negociação,
motivação, formação de equipes, facilitação, análise, criação de projetos (chartering),
criação de incentivos e outros. Essas especialidades possuem influência significativa no
desempenho dos projetos e levam tempo para serem desenvolvidas e reter e estão
aderentes aos padrões de processos e abordagens da função de suporte ao gerenciamento
de projetos. Entre essas funções, encontramos as descritas no Apêndice D.
Considerando-se a atual dependência das empresas em ferramentas de software,
que agilizam os processos e facilitam o gerenciamento de grandes quantidades de dados,
Crawford sugere que o PMO centralize as atividades de implementação e manutenção
do software de gerenciamento de projetos, o que incluiria a padronização de formatos,
para que os cronogramas e demais relatórios gerados nos diversos projetos possam ser
integrados e sumarizados para escalonamento aos níveis de gestão solicitados. O grupo
de suporte a projetos deve, então, identificar necessidades na área de software, facilitar
ou executar o uso e integração desses produtos, manterem sua utilização e monitorar o
desempenho de cada componente, garantindo que o conjunto seja compatível entre si.
Processos, padrões e metodologias são o terceiro elemento do PMO, que deve
desenvolver e manter uma biblioteca de recursos para projetos, que incorpore, inclusive,
as técnicas e ferramentas para lições aprendidas. No mínimo uma metodologia de
67
gerenciamento de projetos deve estar disponível aos gerentes e equipes de projetos, com
modelos de documentos, listas de verificação e formulários (que podem ser eletrônicos
ou não, baseados em sistemas de informação ou não), a fim de aliviar a carga de
trabalho burocrático dos projetos. Se também houver processos básicos padronizados,
será mais fácil comparar e priorizar os projetos no trabalho de gerenciamento de
portfólio.
As definições feitas, porém, devem ser constantemente comparadas ao mercado
atual, a fim de se identificar corretamente melhores práticas a adotar. Os arquivos de
lições aprendidas, documentações de processos e métodos usados nos projetos podem
servir no futuro de referências para poupar tempo e aprimorar a qualidade dos projetos.
Treinamento: o quarto elemento recomendado por Crawford (2002) para o PMO.
Sendo uma estrutura de apoio à execução da política de gerenciamento de projetos na
empresa, o PMO tende, com o tempo, a ser visto como o “ponto focal” para treinamento
dos gerentes e participantes de projetos. Ele atuaria, assim, na identificação de
necessidades, acompanhamento dos fornecedores, seleção de instrutores e adaptação
dos programas de treinamento à cultura e metodologias aplicadas na organização.
Assim, o PMO é também o local para se avaliar os gerentes e participantes de projetos.
O quinto elemento, a Consultoria, é exercido no caso de algum departamento
preferir conduzir por si mesmo seus projetos, ou algum projeto específico. Nesse caso, o
PMO serve como apoio ao início dos projetos ou fonte de consultoria em seu
desenvolvimento. Uma vez que é possível que os consultores não sejam chamados a
menos que surjam problemas, esse pessoal deve ser especialmente mais habilitado e
experiente como gerentes de projetos, devem conhecer mais sobre o negócio e o
mercado, para quando os projetos enfrentarem desafios eles possam auxiliar no
desenvolvimento de planos de contorno.
68
Eventualmente, os especialistas do PMO podem trabalhar com gerentes de
projetos e pessoal de marketing ou vendas para a elaboração de propostas de projetos
externos. Uma vez que essas propostas geralmente possuem pequenas margens para
negociação, as estimativas de prazos e custos devem ser mais precisas, o que garantirá
que a lucratividade projetada para os contratos tenha maior grau de precisão.
Finalmente, para Crawford, o sexto elemento do PMO é o “repositório” de
Gerentes de Projetos. Uma quantidade de profissionais capacitados e experientes em
gerenciamento de projetos, que podem assumir uma ampla gama de portes e
complexidade de projetos, e para reduzir ou eliminar influências funcionais sobre esses
profissionais, é uma boa alternativa alocá-los em tempo integral no PMO. Assim, o
escritório mantém uma base de dados de suas capacitações e especializações, podendo
melhor recomendá-los nas atribuições a projetos específicos. Seu desenvolvimento,
contudo, estaria a cargo de um gerente de gerentes de projetos ou do gestor do PMO,
para avaliação, consultoria e desenvolvimento de desempenho, tanto dos gerentes de
projetos quanto das equipes de projetos.
A integração do PMO às atividades da organização, ao nível corporativo, porém,
é o que garante, segundo Crawford, o uso mais efetivo dessa estrutura estratégica. O
Tipo 3 de PMO (Escritório Estratégico de Projetos) “é o lugar adequado para
acompanhar as tendências corporativas [...] com dados para decisões sobre contratar ou
terceirizar” (CRAWFORD, 2002, p. 80).
Numa pesquisa sobre os efeitos do planejamento de projetos sobre o sucesso
desses, Dvir et. al. (2003) mencionam que, apesar não terem encontrado correlação do
índice de sucesso dos projetos com o nível de implementação dos processos e
procedimentos de gerenciamento, nas estruturas investigadas, o sucesso de projetos
parece apresentar uma correlação positiva com os investimentos feitos na definição de
69
requisitos e no desenvolvimento de especificações técnicas.
A definição tradicional de projetos (PMI, 2004) considera que o nível de
desempenho e os objetivos do projeto devem ser previamente bem conhecidos, o que na
maioria das vezes não acontece. O PMI ressalta também que, se não há dúvidas de que
um mínimo de planejamento aumenta as chances de sucesso dos projetos, a sua falta,
por outro lado, garante a falha (PMI, 2004). E citam ainda que, ironicamente, mesmo
sendo completados no prazo, no orçamento e gerando produtos dentro das
especificações acordadas com o cliente, alguns projetos são logo reconhecidos como
fracassos, uma vez que, concluídos, não geraram lucro para o cliente, nem produziram
os benefícios esperados.
Adicionalmente, Bates (apud DAI; WELLS, 2004) acrescenta as tarefas de
avaliação de riscos, verificação dos projetos pós-implementação e condução da cultura
da organização para o trabalho por projetos.
Da pesquisa feita, portanto, podemos resumir uma lista mais comum de funções
que um PMO deveria desempenhar numa organização, conforme os vários autores:
• Redução do ciclo de produção, por processos estruturados e repetíveis;
• Redução de custos, pela otimização do uso de recursos;
• Melhoria na qualidade dos produtos gerados;
• Melhoria nos resultados econômico-financeiros;
• Conservação e melhoria da imagem (área de negócios ou empresa);
• Conservação e melhoria da capacidade de execução de projetos;
• Suporte aos gerentes de projetos;
• Estrutura do acompanhamento e controle dos projetos e do portfólio;
• Prover a infra-estrutura tecnológica para o Gerenciamento de Projetos;
70
• Prover as competências necessárias ao gerenciamento de projetos;
• Definição dos processos de Gerenciamento de Projetos;
• Desenvolvimento de habilidades de gerentes de projetos;
• Gerenciamento de riscos de projetos.
2.7 Processos de Gerenciamento de Projetos
O PMBOK (PMI, 2004, p.41) apresenta, em seu capítulo 3, a informação
contextual essencial para o entendimento do que o PMI chamada de “moderno
gerenciamento de projetos”. Atualmente reconhecido como uma das melhores
referências para padrões e processos para planejamento de projetos, o guia contém uma
série de recomendações para as diversas fases de um projeto, classificadas em
“processos” e “grupos de processos” e é destinado aos profissionais de gerência de
projetos.
Essas orientações provém de profissionais associados ao instituto e de suas
experiências no campo do gerenciamento de projetos e constituem um conjunto de
regras e definições do ambiente de projetos comumente aceitas, o que significa que tal
conhecimento não se aplica uniformemente a todos os projetos, mas que podem ser ou
não aplicadas aos projetos reais conforme a situação e o conhecimento da equipe de
projeto.
O PMBOK, contudo, não é completo e nem conclusivo, segundo o próprio PMI
destaca (PMI, 2004). Além disso, ele não contém uma metodologia definida para
gerenciamento de projetos. No dicionário, encontramos que “metodologia:
procedimento, técnica ou meio de se fazer alguma coisa, especialmente de acordo com
um plano; ordem, lógica ou sistema que regula uma determinada atividade” (HOUAISS,
71
2003). Para ser uma metodologia, portanto, o conteúdo do PMBOK deveria incluir os
modelos de documentos (procedimentos), indicar ferramentas (técnicas) e apresentar as
tarefas detalhadas para o gerenciamento de projetos (ordem, lógica ou sistema). Assim,
o guia é uma das boas referências para gerenciamento de projetos, mas a metodologia
que cada organização ou gerente de projeto individual vai aplicar é de sua livre escolha,
e o mercado de gerenciamento de projetos está hoje repleto de metodologias para se
escolher.
Resumidamente, o PMBOK (PMI, 2004) organiza o que chama de “moderno
gerenciamento de projetos” como um conjunto integrado de 44 processos, que são
reunidos em cinco grupos. Ao testar seus conhecimentos em gerenciamento de projetos,
o PMI se refere a esses processos como “grupos de competência”. Os cinco grupos de
processos são:
• Processos de Iniciação – reconhecem que um projeto ou fase pode começar
e estabelece o compromisso necessário para prosseguir;
• Processos de Planejamento – definem e mantém um esquema exeqüível de
trabalho para atingir as necessidades de negócio a que o projeto se propõe;
• Processos de Execução – coordenam pessoas e outros recursos para
implementação do plano;
• Processos de Monitoramento e Controle – garantem que os objetivos do
projeto sejam atingidos, pelo monitoramento e medição do progresso,
tomando medidas corretivas quando necessário;
• Processos de Encerramento – formalizam a aceitação do projeto ou fase
deste, trazendo-o a um final ordenado.
O PMBOK (PMI, 2004) descreve os processos individuais decompondo-os em:
• Entradas – o quê se utiliza como subsídio para planejamento e ação;
72
• Técnicas e Ferramentas – conhecimentos, métodos, normas, políticas e
outras regras, mecanismos ou sistemas que se pode aplicar às entradas nos
processos de gerência de projetos;
• Saídas – o quê se obtém de resultados da aplicação das técnicas e
ferramentas às entradas.
Em relação à aplicabilidade dos processos completos do PMBOK (PMI, 2004),
uma pesquisa respondida por 124 filiados ao PMI (2005) mostrou que existe uma
confiança bastante grande da comunidade de Gerenciamento de Projetos na
aplicabilidade dos processos em projetos reais (mais de 80% dessas pessoas
responderam que vêm aplicabilidade do PMBOK em 20% a 80% dos projetos que
empreendem), como mostra o Gráfico 2 a seguir:
QUANTO À APLICABILIDADE DO PMBOK À REALIDADE DA G.P. NAS EMPRESAS ...
8
42
59
15
47,58%
33,87%
6,45%
12,10%
Menos de 20% De 20% a 50% De 50% a 80% Mais de 80%
# respostas
Gráfico 2 Percepção da aplicabilidade do PMBOK (Filiados PMI)
73
2.8 Modelos e Ferramentas
O primeiro dos benefícios que se espera de um PMO é a padronização do
trabalho de gerenciamento de projetos na organização, chamados por Valeriano (1998,
p. 97-98) de “denominador comum”: procedimentos e rotinas de uso comum,
detalhados ao nível operacional e que os gerentes de projetos podem adotar conforme as
especificidades de seus projetos o exigirem.
Além de servir como fator de otimização de tempo dos gerentes de projetos e
participantes das equipes de projetos, a padronização unifica a linguagem utilizada nos
projetos – todos usam termos comuns e conhecem seus significados, reduz os formatos
de documentos para coleta de informações – todos reconhecem os modelos de
documentos e podem preenchê-los com mais facilidade (uma vez que são conhecidos de
projeto para projetos), e uniformiza a forma de apresentação de resultados – os
patrocinadores, principais envolvidos, clientes e equipes identificam com mais
facilidade as informações contidas nessas apresentações. Conforme observa Valeriano:
Se por um lado a inexistência de procedimentos uniformes e dos planos
orientadores é perniciosa, 'deixando o barco à deriva', o rigor, o detalhe
excessivo e a inflexibilidade desses procedimentos poderão sufocar a
organização em uma camisa de força. O trabalho participativo para a geração,
aplicação, análise e melhoramento e atualização dos planos e das
metodologias é o caminho indicado para o bom resultado (Valeriano, 1998, p.
97-98).
A definição e manutenção de ferramentas visam prover ferramentas que foram
cuidadosamente analisadas e extensivamente verificadas quanto à sua aplicabilidade,
participação no mercado, facilidade de uso, disponibilidade de treinamentos, suporte ao
usuário e assistência técnica e custos de aquisição, instalação e manutenção. Da mesma
forma como os modelos, as ferramentas definidas pelo PMO se tornam padrão para os
projetos, e fornecem benefícios semelhantes quanto à otimização de tempo, unificação
da linguagem utilizada em projetos, apresentação de resultados e ainda adicionam as de
74
disponibilidade de uso, suporte e treinamento.
No mercado brasileiro, uma amostra de utilização de produtos para
gerenciamento de projetos, coletada pela pesquisa do PMI-RJ (PINTO, 2005, p.109),
cita três produtos mais utilizados, além de sistemas desenvolvimentos internamente às
empresas usuárias e outros:
Figura 10 Opções de software pelo mercado brasileiro (PINTO, 2005, p.109)
Uma busca em links indicados pelo PMI, para mecanismos de Internet
especializados de busca por software para gerenciamento de projetos e programas,
indica mais de 550 produtos no mercado
9
, que poderiam ser objeto de avaliação por
trabalhos posteriores, e fogem do escopo deste trabalho.
Vale ilustrar, porém, uma pesquisa do Gartner (GARTNER, 2005, p. 3), bastante
conhecida no âmbito da T.I. como “Quadrante Mágico” (v. Figura 11, adiante), pela
forma como dispõe os concorrentes em relação a dois componentes principais:
completude de visão (identificação das necessidades e tendências do mercado) e
habilidade para execução (capacidade para fazer aquilo a que se propõem). Esses
componentes são dispostos em um quadrante que designa sua tendência de inovação ou
atuação em nichos de mercado, liderança ou desafiadores. Na pesquisa de 2005, o
9
Inclui produtos não necessariamente apenas de gerenciamento de portfólio e programas.
75
Gartner identifica os seguintes produtos para gerenciamento de projetos e portfólio (v.
gráfico na próxima página):
Figura 11 Quadrante Mágico Gartner (GARTNER, 2005, p. 3)
Em uma pesquisa do Forrester, Forrester Wave®: Project Portfolio
Management, Visitacion (2006) ressalta o quão crítica é a disciplina de Gestão de
Portfólio é para a consecução de objetivos da T.I.. Segundo a consultora, “as
organizações de T.I. devem dominar a capacidade de visualizar os requisitos, determinar
as melhores combinações de novos projetos e sistemas existentes, a fim de obterem um
correto balanceamento de recursos e controle de investimentos” (VISITACION, 2006).
Numa avaliação de fornecedores de software para Gestão de Portfólio de projetos, o
Instituto Forrester utilizou 94 critérios de avaliação de fornecedores, e concluiu que “os
tradicionais melhores competidores ainda dominam o mercado”. Para eles, Primavera e
PlanView possuem profundidade funcional, abrangência e atendimento específico a
tipos de problemas ou ramos de indústria que excedem em muito os requisitos genéricos
76
de gestão de serviços de T.I. Um gráfico comparativo dos produtos avaliados encontra-
se a seguir, na Figura 12:
Figura 12 Fornecedores de software para gestão de portfólio – adaptado de Visitacion (2006, p. 8)
2.9 Implementação de um PMO
Uma das definições exemplo de vissão de um PMO é a dada por Englund,
Graham e Dinsmore (2003), de que o PMO é uma estrutura que deve “agir como
veículo de mudança organizacional para o aprimoramento do gerenciamento de projetos
na organização através da padronização dos processos [e que isso deve] ficar claro
desde o início [de seu projeto de implementação]” (ENGLUND; GRAHAM;
DINSMORE, 2003).
Segundo Kotter (RODRIGUEZ, 2005), formalizar essa visão, de que
implementar o PMO é uma iniciativa de definir uma nova maneira de trabalhar, é uma
77
das oito etapas necessárias à conclusão bem sucedida de uma mudança nas
organizações. As outras sete etapas, complementa Kotter, são: estabelecer o senso de
urgência para o projeto, formar uma aliança forte de lideranças, comunicar a visão ao
restante da organização, prover a devida autoridade aos funcionários envolvidos, definir
objetivos atingíveis no curto prazo, consolidar as melhorias e produzir mais mudanças e
institucionalizar as novas abordagens, pela sua incorporação aos procedimentos para
atividades regulares da empresa.
Para isso, porém, é necessário que haja o entendimento pela alta administração
sobre o projeto e seus objetivos, pois essas pessoas são o principal cliente e interessado
no projeto. Assim, seu efetivo engajamento em termos de apoio formal e
comprometimento com seus resultados é fator crítico de sucesso na implementação do
PMO (TURNER, 1993, p. 62-63; KERZNER, 1997, cap. 9; CARVALHO;
RABECHINI JR., 2005, p. 41, 86; RABECHINI, 2005, p. 25). A importância desse
apoio é destacada pelo PMI, que adicionou um processo de comunicação no PMBOK 3ª
Edição (PMI, 2004, p. 235). Esse entendimento, que leva ao comprometimento com o
sucesso do projeto, reduz prováveis impactos no processo de implementação e é uma
das forças motrizes da maturidade em gerenciamento de projetos (KERZNER, 2002,
cap. 2-3).
Em seu artigo para o portal Gantthead (2002), o profissional e autor Mark
Mullaly, PMP, resume o primeiro e mais importante passo na implementação do PMO
numa organização: responder à questão “Que papel desempenha o PMO na
organização?” e, para completar o desafio, a organização deveria também saber
responder “porquê [o PMO] está sendo criado?”. Ainda segundo Mullaly, a primeira
pergunta continuará válida mesmo após o PMO ter sido criado e continuar a evoluir. A
“busca pela identidade”, que dá título ao artigo, se daria, segundo o autor, pelo PMO
78
tentar ser tudo para todos, “lutando com seu propósito para existir”.
Para Mullaly (2002), o PMO, para ser corretamente criado, deveria ter uma
missão clara, definida conforme as necessidades de seus clientes, que precisam ser
identificados mesmo antes da missão. O plano de estabelecimento do PMO deveria,
então: ser iniciado a partir de uma avaliação inicial do estado do gerenciamento de
projetos na organização; ter os objetivos do PMO totalmente alinhados aos da empresa;
ser criado a partir de um plano claro e convincente para a mudança proposta; contar
com um plano detalhado para a melhoria do processo de gerenciamento de projetos na
empresa e ser implementado conforme os princípios de mudança organizacional.
Isso lembra exatamente a fase de concepção de um projeto, e como tal deveria
ser tratada a implementação do PMO. Essa seria a oportunidade para sua equipe inicial
mostrar como um projeto bem gerenciado deveria ser.
Block e Frame (1998, p. 76) concordam com os questionamentos acima, pois
também reconhecem a ampla gama de serviços e funções que um PMO pode
desempenhar. Porém, adicionam uma terceira questão, ao se decidir pela implementação
de um PMO: “onde se situará o PMO, organizacional e fisicamente?”. Sua resposta,
contudo, é simplista (“onde quer que faça mais sentido”) e depende do tipo de empresa
que o implementará.
De acordo com a pesquisa de Hobbs e Aubry (op. cit., p. 76), “PMOs são
desfeitos na mesma grande velocidade com que são criados”. O ponto que lhes dá mais
legitimidade (e garante sua sobrevivência) é justamente a melhoria no desempenho dos
projetos e programas. Mas essa legitimidade também mostrou ser dependente (de forma
circular) da maturidade em GP da empresa (uma leva à outra). Outro fator que contribui
é o limite de autoridade dos PMOs, que por sua vez também é dependente dos outros
dois fatores citados.
79
Em sua pesquisa, Dai e Wells (2004) perceberam uma quantidade surpreendente
de PMOs que tiveram sua aprovação pela alta administração (presidências e diretorias) e
a ela se subordinam, sendo muito poucos os que foram aprovados pela média gerência e
igualmente poucos se reportam a esse nível de gerência. O grupo de profissionais
pesquisados
10
, em sua composição mista permitiu enriquecer os resultados da pesquisa,
em que se comprovou o grande número de empresas que recentemente começaram a
estabelecer PMOs, o que demonstra confiança, por parte dos gestores, nessa inovação
em termos de administração. Além disso, ficou evidente que ter padrões e métodos
comuns para gerenciamento de projetos está muito correlacionado com a melhoria do
índice de sucesso dos projetos, e que essa função deveria ser priorizada em relação às
demais. A manutenção e uso de históricos de projetos mostrou a mesma correlação e os
pioneiros na implementação de PMOs estão hoje em condições de recomendar que
políticas e documentos deveriam acompanhar a implementação de um PMO.
Uma vez que é recomendado que o PMO seja estabelecido conforme as
necessidades da organização, seus clientes e o perfil de projetos que são empreendidos,
é importante uma análise do portfólio de projetos em andamento, ao momento da
decisão de se implementar o PMO (KENDALL; ROLLINS, 2003, cap. 19).
Um fator que não se deve ignorar é a questão importante da cultura
organizacional. A cultura organizacional é parte do ambiente interno da empresa e ela se
apresenta como uma importante vantagem competitiva (DAFT, 1999), devendo assim
ser considerada na definição e na implementação de quaisquer mudanças, como é o caso
da implementação de um PMO.
10
Divididos em dois grupos pelos pesquisadores: 1.000 profissionais filiados ao PMI, selecionados
aleatóriamente entre 35.880 voluntários com 23,4% de resposta, e 96 profissionais selecionados entre
participantes do PMI Annual Symposium 2000 e do curso Master of Science in Project Management, da
George Washington University, todos selecionados por declararem estar em empresas que possuíam um
PMO (qualquer "versão"). No total, 330 responderam à pesquisa.
80
Outro aspecto, igualmente importante a ser considerado, é o chamado “clima
organizacional” em que o projeto de implementação do PMO será empreendido. Uma
pesquisa (GRAY, 2001) mostrou o quanto as ameaças ambientais e de objetivos que um
projeto sofre lhe são prejudiciais ao bom desempenho. A atitude dos gestores, e
principalmente do patrocinador do PMO, portanto, deveriam ser fortemente orientadas a
eliminar tais ameaças.
A equipe encarregada de implementar o PMO deve também estar consciente de
que atualmente é muito comum, e tudo indica que será ainda mais, o uso de “equipes
virtuais”, ou seja, grupos de trabalho em que os integrantes estão geograficamente
dispersos (ainda que dentro da mesma cidade ou mesmo dentro da própria empresa).
Assim, o PMO deve ser projetado de forma a lidar com essa forma de trabalho. Ela
implica não mais em problemas de comunicação, como a definição de equipes virtuais
leva a crer, pois as tecnologias de informação estão suficientemente desenvolvidas para
minimizar tais dificuldades. Ao invés disso, o PMO deve concentrar-se nos problemas
gerenciais que a formação de tais equipes compreende; por exemplo, deve-se estar
preparado para lidar com pessoas em diferentes fusos horários no mesmo projeto
(BLOCK; FRAME, 1998).
Finalmente, no processo de estruturação da atividade por projetos numa
empresa, deve-se levar em conta tanto as considerações teóricas quanto as práticas, o
que inclui aspectos relacionados à estrutura organizacional e ao desenvolvimento de
competências em gerenciamento de projetos (CARVALHO et. al., 2005). Para a
avaliação de competências existem hoje diversos “modelos de maturidade, inspirados
em Humprey (1989), que identificou níveis de maturidade de processo de
desenvolvimento de projetos de T.I. baseado, sobretudo, nas atitudes gerenciais
encontradas nas empresas” (LAURINDO; CARVALHO; SHIMIZU, 2003 apud
81
CARVALHO et. al., 2005).
No estudo de Carvalho et. al. (op. cit.), nesses modelos concentra-se na
avaliação da institucionalização do gerenciamento de projetos nas empresas, mas “há
carência no que concerne à avaliação das competências e dos recursos a serem
construídos pela organização, no âmbito do indivíduo, da equipe e da organização”.
Assim, concluem os autores, “como a literatura dessa área [de avaliação da maturidade
em gerenciamento de projetos] é ainda recente, existe demanda por desenvolvimento de
pesquisas que aprofundem o processo de construção da excelência em projetos”
(CARVALHO; RABECHINI JR; SHIMIZU, 2005).
82
3 MÉTODO DA PESQUISA
3.1 Seleção do método de pesquisa
Para a escolha da método da pesquisa, partimos da declaração dos objetivos
específicos e geral, que deveriam permitir responder à questão da pesquisa: “como
transcorreu a implementação do Escritório de Gerenciamento de Projetos (PMO) na
área de Tecnologia da Informação de uma grande empresa ?”. No quadro apresentado
por Yin (2001, p. 24) para seleção de método de pesquisa, os elementos acima levaram
à escolha do “Estudo de Caso”:
Estratégia
Forma da questão de
pesquisa
Exige controle sobre
eventos
comportamentais?
Focaliza
acontecimentos
contemporâneos?
Experimento Como, por que Sim Sim
Levantamento Quem, o que, onde
quantos, quanto
Não Sim
Análise de Arquivos Quem, o que, onde
quantos, quanto
Não Sim/Não
Pesquisa Histórica Como, por que Não Não
Estudo de Caso Como, por que Não Sim
Quadro 2 Estratégias de Pesquisa - adaptado de Yin (2001, p. 24).
De fato, o objetivo geral da pesquisa proposta aponta para uma formulação do
tipo “como transcorreu a implementação”, em condições não controladas e tratando de
eventos de um passado recente.
Nas palavras de Martins (2006, p. 69), a opção pelo Estudo de Caso mostrou-se
adequado às intenções desta pesquisa, uma vez que esse método, de características
peculiares, define-se como uma “estratégia de pesquisa em profundidade de um caso,
que possibilita o estudo de fenômenos contemporâneos, [...] em que o pesquisador tem,
geralmente, pouco controle sobre os eventos comportamentais” (MARTINS, 2006, p.
Excluído:
adequada
Excluído:
da
Excluído:
em
83
69). Além disso, cita Martins que os eventos pesquisados no Estudo de Caso inserem-se
em “algum contexto da vida real” (como é nosso caso, do PMO da área de T.I.
pesquisada) e para o qual “não são apropriadas formulações de objetivos e hipóteses”.
Nossa interpretação, porém, a respeito dessa última afirmação, diverge um
pouco, pois achamos necessário manter a definição de objetivo da pesquisa mencionada
no Capítulo 1.
3.2 Seleção da forma de coleta dos dados
A coleta de informações envolveu consulta aos registros referentes à
organização do ambiente de projetos da área analisada e aos principais profissionais
envolvidos na implementação. Esses registros incluem dados sobre os projetos gerados
no período 2000-2005.
A maior, e mais importante, fonte de informação foram as entrevistas realizadas
com os gestores área de T.I., pelo seu envolvimento no processo e por serem esses os
maiores afetados pelos resultados da implementação. Vários autores sugerem a
entrevista como forma mais recomendada de coleta de dados em pesquisas sociais e o
cuidado com alguns pré-requisitos no planejamento e execução da entrevista (GIL,
1998, p. 123-125; LAKATOS; MARCONI, 2001, 97-98; YIN, 2001, p. 112-115):
• Planejamento da entrevista com base nos objetivos a serem alcançados, com
um roteiro específico com as questões mais importantes;
• Questões formuladas de forma a permitir a compreensão imediata pelo
entrevistado, evitar constrangimento, não antecipar implicitamente respostas
e em uma ordem que mantenha o interesse do entrevistado;
• Oportunidade da entrevista (local e hora adequados para garantir a realização
84
da entrevista sem interrupções);
• Preparação antecipada dos entrevistados, por comunicação escrita ou contato
pessoal, a respeito do assunto a ser tratado: finalidade da visita, objetivo da
pesquisa, importância das informações que forneceriam, contribuições à
comunidade e garantias de anonimato, garantia de confidencialidade das
respostas e preservação da identidade de cada entrevistado.
Para elaboração e posteriormente execução das entrevistas, alguns
procedimentos foram cumpridos:
Procedimentos de campo – alguns preparativos foram necessários (YIN, 2001,
p. 91): requisitar autorização da diretoria da área em que trabalham os entrevistados
para realização das entrevistas e posterior publicação dos resultados, solicitar à área de
Segurança Corporativa a autorização para porte e uso de gravador durante as entrevistas
e acesso físico aos locais de trabalho dos entrevistados (vide Figura 11, no Anexo C) e
agendar previamente o horário com cada pessoa. Essa preparação não significava,
porém, a garantia de sucesso (ou mesmo da ocorrência) das entrevistas conforme
planejado. Como lembra Martins, “a coleta deve ser pautada por um plano formal;
todavia, informações relevantes para o estudo podem ser coletadas mesmo não sendo
previsíveis” e mesmo com algum rigor no planejamento, “geralmente, a realidade acaba
por surpreender, e diante de situações não previstas, o pesquisador precisa[rá] mostrar
habilidades para reverter o ocorrido em favor da pesquisa” (MARTINS, 2006, p. 73).
Foi próximo disso o que vivemos, em constantes reagendamentos ou “agilização” do
questionamento ou resposta de algumas perguntas, sempre com a interrupção dos
motivos habituais de um ambiente de trabalho complexo como o da área em
pesquisamos.
85
Protocolo do estudo – instrumento “orientador e regulador da condução da
estratégia da pesquisa” (MARTINS, 2006, p. 73) o protocolo desta pesquisa constituiu-
se das seguintes etapas:
Preparativos: a fim de se obter autorizações para acesso à empresa e às áreas
envolvidas, fizemos breve apresentação da pesquisa ao Diretor da área (o CIO da
empresa), que também se prontificou em responder à pesquisa; uma série de
agendamentos prévios de reuniões, uma com cada gestor de T.I., foi necessária para
obtermos o compromisso inicial de todos com a pesquisa;
Definição das questões e objetivos do Estudo de Caso: conforme descrevemos
no Capítulo 1, a principal questão proposta para o estudo e objetivo da pesquisa, era
descobrir “Como transcorreu a implementação de um ‘Escritório de Gerenciamento de
Projetos’ na área de Tecnologia da Informação de uma empresa da região do Vale do
Paraíba orientada a projetos?”. Como objetivos secundários, visou-se também
“Identificar por que a Empresa investiu nesse empreendimento, quais foram os fatores
facilitadores e dificultadores encontrados durante a implementação do PMO e
identificar quais os ganhos que se percebeu com a implementação”.
Determinação das possíveis fontes de evidências: alguns registros de atividades
da área de Tecnologia da Informação, às quais talvez ainda não se pudesse denominar
“projetos”, foram pré-selecionados como possíveis fontes de informação; esses, porém,
posteriormente vieram a ser descartados, em função de não se mostrarem relevantes às
análises da pesquisa, exceto pelo fato de que comprovam a não existência de métodos e
políticas de tratamento das demandas da área em relação a seus clientes internos, ou
seja, os usuários das soluções e sistemas implementados pela área de T.I.. As entrevistas
vieram, assim, a se configurar como a mais relevante fonte de informações a partir das
quais se poderiam inferir as conclusões que são apresentadas nos Capítulos 4 e 5. As
Formatado: Recuo: Primeira
linha: 1,25 cm, Sem
marcadores ou numeração
86
questões das entrevistas são descritas a seguir.
Estruturação da entrevista – considerando os objetivos específicos, o roteiro
de entrevista elaborado deveria visa buscar a identificação do contexto de
gerenciamento de projetos na área de T.I. da empresa, antes e depois de se haver
implementado o PMO. Assim, foi necessário estruturar a pesquisa que, conforme as
definições de Gil (1998, p. 120-121), Lakatos e Marconi (2001, p. 96), e Merton et. al.
(apud. YIN, 2001, p. 113), poderia ser qualificada como pouco além da “Entrevista
Focalizada”, “por Pautas” (GIL, 1998, p. 120) ou mesmo “Despadronizada ou Não
Estruturada” (LAKATOS; MARCONI, p. 96), em que pontos de interesse foram
elaborados de forma a poder-se, posteriormente, analisar as respostas em uma certa
lógica objetiva, ilustrada na Figura 13:
Figura 13 Pontos a Explorar nas Entrevistas
Segundo essa estrutura, a entrevista começa por identificar o cenário anterior à
implementação do PMO na área de T.I. “1) Antes da implementação de processos e
Formatado: Fonte: Negrito
87
padrões para gerenciamento de projetos na área, qual era, em sua opinião, a forma de
condução dos projetos de T.I.?” Isso serviu de base para podermos traçar paralelo com a
situação atual da área.
Em seguida, pergunta-se a respeito dos fatores que levaram a organização a
iniciar essa implementação: (“2) Quais foram os fatores motivadores e principais
objetivos para a implementação do gerenciamento de projetos na área, àquela época?”).
Do conjunto de respostas, pode-se identificar o grau de entendimento entre os gestores
sobre os objetivos do PMO, conforme este foi idealizado.
A terceira questão proposta foi “3) Como transcorreu, na sua visão, a
implementação do gerenciamento de projetos na área?”. Ela visou a obter as impressões
pessoais dos envolvidos principais, cuja experiência no processo pode contribuir para a
formação do conhecimento a respeito de mudanças significativas numa organização,
como é a introdução de um PMO ou outra estrutura administrativa.
A próxima pergunta questionou sobre fatores facilitadores e dificultadores: “4)
O que você considera que tenha facilitado ou dificultado o processo de implementação
do PMO?”. Ela buscava informações sobre o que pode ter facilitado ou dificultado o
processo, no ponto de vista dos entrevistados, para completar o conhecimento a respeito
do processo e permitir um melhor planejamento para futuras implementações
semelhantes.
Na quinta questão procurou-se uma “5) O que você acha que a organização (área
de T.I.) ganhou ou perdeu com a implementação?”. Essa visão a posteriori das
mudanças também serviu para a comparação entre os objetivos pretendidos com a
implementação do PMO e os resultados efetivamente obtidos dessa implementação.
Por fim, três perguntas visavam a extrair informações a respeito da formação de
conhecimento que a implementação do PMO possa ter trazido à organização: “6) Qual
88
era seu conhecimento sobre projetos e gerenciamento de projetos, antes da
implementação do PMO?”; “7) Como você classificaria seu conhecimento sobre esses
assuntos hoje? Houve influência na forma como conduz seus projetos?”; e “8) No caso
de ter adquirido conhecimento a respeito, você atribui essa aquisição como efeito
positivo da implementação do PMO?”.
Seleção dos entrevistados – tendo-se como premissa que o PMO implementado
classifica-se como de cunho estratégico/gestão, a seleção das pessoas a serem
entrevistadas foi feita com base nos seguintes critérios: os gestores da área de T.I. são as
pessoas mais diretamente interessadas pela implementação do PMO (que poderia ser um
auxílio à sua organização para tratar as demandas a serem atendidas) e também afetadas
pelos resultados do PMO (por esse é que seus resultados em relação à execução dos
projetos seriam comunicados à direção de T.I. e demais áreas da empresa, envolvidas ou
atendidas pelos projetos); essas pessoas contam com uma experiência acumulada em
gestão de T.I. suficiente para receberem e responderem às perguntas que a pesquisa
apresentaria; todos demonstram total acessibilidade, disponibilidade e interesse em
participar.
Com base nesses critérios, foram entrevistas 9 pessoas, gestores de T.I., com
idades entre 35 e 55 nos, formação acadêmica variada (Análise de Sistemas ou Ciência
da Computação, Engenharias – Elétrica, Eletrônica ou Mecânica e Administração de
Empresas) e especializações diversas em gestão (pós-graduações latu sensu ou MBA e
uma pessoa com Mestrado). Em termos de experiência profissional, esse grupo atua em
T.I. há pelo menos 20 anos e conta com no mínimo 13 anos de experiência só em
gestão.
Formatado: Fonte: Negrito
89
3.3 Tratamento dos dados e apresentação de resultados
As respostas das entrevistas foram analisadas à luz do contexto em que cada
entrevistado se encontrava (em relação ao assunto “implementação do PMO de T.I.”),
para que se pudesse entender o que foi dito sobre pontos em particular “e permitir
destacar diferenças e semelhanças entre os discursos dos entrevistados [a respeito
daqueles pontos]” (MINAYO, 2000, p. 200; GHIGLIONE; MATALON, 1985, p. 162
apud CHAMON, 2005).
Sem caracterizar complemente o uso da técnica da Análise de Conteúdo, a
análise das respostas visou principalmente a síntese das respostas de cada pessoa sobre
os objetivos da pesquisa: percepção sobre os fatores que motivaram a implementação;
opinião sobre como transcorreu o processo de implementação; identificação de fatores
que dificultaram e que facilitaram a implementação; percepção de resultados obtidos
com a implementação. O resultado dessa análise está apresentado no Capítulo 4, a
seguir.
90
4 RESULTADOS E ANÁLISE
4.1 Histórico
A área de T.I. da Empresa existe há pelo menos 15 anos, época em que o
processamento de dados baseava-se principalmente nos sistemas executados em
computador de grande porte (mainframe), cujo acesso pelos usuários se dava por
terminais chamados “dedicados” e com recursos limitados para funções de manipulação
de dados, impressão e outras facilidades.
Os sistemas utilizados àquela época eram comercializados pelo fabricante dos
computadores e terminais ou desenvolvidos especificamente para a Empresa, por
pessoal especializado externo à Empresa, com base em definições e requisitos obtidos
em reuniões com as equipes operacionais e de gestão. Assim, a Empresa tinha pouca
necessidade de definir e manter um sistema próprio de gerenciamento de projetos.
Posteriormente, a área de T.I. assumiu a tarefa de desenvolver e modificar
internamente os sistemas de processamento de dados, porém, sem uma formação
específica nos conhecimentos de gerenciamento de projetos, como esses são conhecidos
atualmente. Assim, até o início dos trabalhos de implementação do PMO, por volta do
final do ano de 2000, o assunto “gerenciamento de projetos” era ainda uma novidade
entre os analistas de sistemas e até mesmo entre os líderes dessas equipes e seus
gestores.
Nessa época, o gerenciamento das atividades de T.I. era “informal, sem
condições de se estabelecer prazos e definir recursos” (entrevistado 03) e tal fragilidade
ficou mais evidente quando o executivo responsável pela área, chamado a compor o
quadro abrangente de informações sobre os projetos em andamento na empresa à época,
91
não conseguia fornecer uma visão razoavelmente precisa sobre os que a área de T.I.
tinha sob sua responsabilidade.
A implementação do PMO iniciou, então, para “tentar usar uma metodologia
comum para todos os projetos da área de T.I.”, uma vez que “cada um desenvolvia o
projeto da sua maneira”. O objetivo do PMO era descobrir “como é que estava
funcionando o portfólio dos projetos ... Para poder priorizar melhor a alocação de
recursos.” (entrevistado 02). Essa seria uma resposta da área de T.I. a uma fase de
crescimento acelerado da empresa, quando “nenhuma atividade poderia ser gargalo para
os objetivos da empresa” (entrevistado 02).
Por essa razão é que os registros referentes aos projetos da área de T.I.,
anteriores à implementação do PMO, não foram úteis nesta pesquisa. Esses registros
eram mantidos em uma base de dados do sistema Lotus Domino, gerenciada por uma
aplicação desenvolvida em Lotus Notes, e servia para o registro de demandas das áreas
usuárias para a área de T.I.. O maior problema relacionado a essa aplicação era seu livre
acesso pelos usuários, que “podiam incluir demandas não avaliadas pela área de T.I.,
com prazos muitas vezes inexeqüíveis e com requisitos obscuros” (entrevistado 04).
Da mesma forma os dados de projetos à época do início da implementação do
PMO não se mostraram úteis para o entendimento do processo de gerenciamento de
projetos naquela época, uma vez que se encontravam incompletos ou não corretamente
preenchidos e atualizados, razão pela qual foram descartados da pesquisa.
As maiores contribuições para a pesquisa foram, portanto, as declarações dadas
durante as entrevistas, que expõem melhor o pensamento dos gestores de T.I. a respeito
do processo e resultados da implementação do PMO. Esses detalhes são analisados nas
seções seguintes deste capítulo, em que duas tentativas que aconteceram de
implementação do PMO serão descritas.
92
4.1.1 A primeira tentativa de implementação do PMO
Na primeira tentativa de implementação do PMO, realizada entre o final do ano
de 2000 e meados de 2001, e buscou-se a orientação de pessoas com experiência em
empreendimentos similares em outras empresas e áreas com igual complexidade
organizacional à da área de T.I. em questão. Nesse processo de seleção participaram
empresas e consultores especializados em projetos, dos quais um consultor
independente foi selecionado.
O consultor deveria desenvolver um plano específico para a área de T.I.
contratante, segundo o qual um processo de gerenciamento de projetos padronizado
seria implementado e difundido pelas equipes de análise e desenvolvimento de sistemas
de T.I. Também constariam do plano o treinamento dos profissionais da área, definição
do ambiente tecnológico de suporte necessário às atividades de gerenciamento de
projetos de T.I. e sessões de conscientização dos principais usuários dos serviços de
T.I., com o objetivo de minimizar os reflexos eventualmente negativos dos projetos
durante essa mudança de processos de T.I..
O consultor, apesar de experiente no assunto, não obteve o sucesso esperado,
devido à baixa receptividade das pessoas ao seu plano, que na época não estavam
preparadas (entrevistado 07). Havia um viés de conhecimento a respeito de
gerenciamento de projetos, segundo o qual a área esperava outro resultado com a
estruturação de projetos: “Antes de mais nada, a gente queria um cronograma. ... a gente
não conseguia [fazer] com que os nossos analistas pensassem começo, meio e fim.”
(entrevistado 07).
Essa falta de preparo das pessoas mostrava que o gerenciamento de projetos na
93
época “era de uma forma bastante informal. Cada um cuidava do seu próprio assunto ...
não tinha controle da carga/capacidade, ... não tinha como fixar prazos e ... honrar os
prazos combinados. ... Cada um fazia o máximo que podia, mas de uma forma
desordenada, sem negociar prioridades, sem alocar recursos de uma forma conveniente
e tal.” (entrevistado 03).
Essa primeira fase durou aproximadamente 18 meses e nesse período alguns
analistas receberam o treinamento básico em gerenciamento de projetos e padrões para
controle das atividades dos projetos começaram a ser desenvolvidos.
A participação nos treinamentos, porém, não foi efetiva, e muitas vezes as
sessões eram canceladas por falta de quorum. Havia também a dificuldade de se
envolver os gestores, cuja agenda não priorizava esse treinamento, o que não lhes
permitia ver os benefícios que se poderia obter com essa capacitação e a aplicação
efetiva dos conceitos de gerenciamento de projetos.
Os padrões para documentação do planejamento e controle de projetos, baseado
em software específico, tiveram alguma aceitação no início, quando alguns cronogramas
foram feitos e centralizados em uma base única, gerenciada por um segundo produto. A
função desse produto seria prover uma visão integrada e instantânea do portfólio, com
as situações dos projetos em um dado instante, a partir de dados atualizados pelos
próprios gerentes de projetos, sem a dependência de pessoa no PMO com essa
atribuição.
Porém, com o decorrer de algumas semanas, o hábito de atualizar os
cronogramas não foi completamente adquirido pelos gerentes de projetos, que
desempenhavam também a função de interface com os usuários dos projetos sob sua
responsabilidade e de liderança ou mesmo execução de desenvolvimento de sistemas.
Assim, com seu tempo dividido entre atender demandas, definir requisitos com
94
os usuários, atuar no desenvolvimento das soluções e executar tarefas administrativas de
gerenciamento dos projetos, era comum que essa última atividade fosse preterida em
função das demais, e os cronogramas apresentavam defasagens nas informações.
Além disso, existe uma cultura forte na Empresa, de que determinados
solicitantes (executivos de áreas usuárias) podem, a qualquer momento, alterar
prioridades sem maiores justificativas, a despeito de todos os estudos de viabilidade e
estimativas que tenham sido feitos para se priorizar um portfólio.
Sem julgar o mérito de tais atitudes, o efeito sobre os gerentes de projetos era a
sensação de que “para quê que eu vou ficar fazendo cronograma, se essa atividade na
semana seguinte vai estar desatualizada ou então vão mudar a prioridade?” (entrevistado
07). Com isso, as informações sobre o andamento dos projetos ficavam a cada dia mais
defasadas.
Da parte dos gestores, havia também a preocupação de que, com uma carteira de
projetos formalizada e publicada em alguma ferramenta de visibilidade a outros gestores
e clientes internos, uma nova dificuldade surgiria:
Você tem que dar explicações do porque o projeto atrasou, [...] porque o
levantamento inicial não foi correto, [...] porque que você não voltou no
usuário para ver aquilo, [...] porque você não deu treinamento [...] As pessoas
não gostam muito de dar explicações sobre o que fazem. [...] Então o gestor
tem uma cobrança muito forte por manter no ar uma operação e aquilo para
ele é só um trabalho a mais. (entrevistado 07).
Aliada à não priorização dessas atividades de gerenciamento de projetos pelos
próprios gestores, essa defasagem crescente das informações na base de projetos a
levou, gradativamente, ao desuso, até finalmente ser descontinuada.
Ao término do contrato (por tempo pré-determinado) com o consultor, os
trabalhos realizados foram avaliados como insuficientes, em termos de resultados
percebidos, razão pela qual o contrato foi finalizado e não renovado. Posteriormente, a
percepção que ficou foi que o esforço até “trouxe uma série de insights (sic) para o
95
pessoal, mas não levou a uma maturidade suficiente para as pessoas, para os líderes
avaliarem realmente os riscos de cada projeto, terem uma visão mais gerencial. ... uma
percepção melhor do que é gerenciar projetos ... e uma visão mais estruturada [do
portfólio]” (entrevistado 02).
Terminava, assim, uma primeira tentativa de implementação do PMO, sem
sucesso, o que é atribuído a vários fatores, entre os quais: a) falta de capacitação das
equipes e gerências para o gerenciamento de projetos, ainda que em nível básico; b)
falta de um planejamento de mais longo prazo que descrevesse os objetivos do projeto e
os papéis que as equipes desempenhariam no processo; c) apoio executivo não
claramente demonstrado; d) opção equivocada pela tentativa de instalação de uma
solução tecnológica sem uma solução organizacional que a suportasse, antes de se ter o
processo idealizado de gestão da demanda e de projetos; e) falta de comunicação dos
objetivos e metas do projeto de implementação do PMO, entre outros.
Por alguns meses, ao longo dos quais outras mudanças estruturais da empresa
ganharam a prioridade dos gestores, o assunto gerenciamento de projetos permaneceu
intocado, tendo os projetos, então, voltado a serem conduzidos como antes: conforme o
conhecimento, priorização e dedicação individual de cada gerente de projetos, até a
segunda tentativa de implementar o PMO, descrita a seguir.
4.1.2 A segunda tentativa de implementação do PMO
A segunda tentativa de implementação do PMO se deu em um cenário de
negócios pouco diferente, em que a empresa se recuperava de uma crise mundial em seu
ramo de negócios e “o foco depois da mudança [de executivo da área] foi mais controle.
... o crescimento já não estava tão acentuado e havia uma preocupação em colocar as
96
finanças em ordem. ... Uma visão mais orçamentária, uma visão de verificar como é que
você pode utilizar melhor os recursos existentes, o que se pode racionalizar nesse
sentido.” (entrevistado 02).
Nessa época, uma reestruturação organizacional da área de T.I., representada na
Figura 14 abaixo, criou equipes reduzidas de Analistas de Negócios
11
, o que, por sua
vez, gerou uma necessidade de se estruturar melhor a forma como as demandas de áreas
usuárias seriam tratadas e também de informar os usuários sobre o andamento dos
projetos.
Figura 14 Organograma da área de T.I. na época da implementação do PMO
Nessa estrutura, as áreas de Negócios de T.I. (Administrativos, Comerciais,
Engenharia, Operações e Logística) comportam os Analistas de Negócios, que têm a
atribuição de manter contato com as respectivas áreas usuárias, a fim de entender seus
11
Os Analistas de Negócios são, para a Empresa, os Analistas de Sistemas que fazem o contato com as
áreas usuárias de produtos e serviços de T.I. A responsabilidade deles é entender os processos das áreas,
auxiliar aos usuários na definição de requisitos para desenvolvimento ou alteração em sistemas de T.I.
para atendimento de novas demandas ou melhorias dos processos das áreas usuárias quanto ao uso dos
recursos de T.I..
97
processos, conhecer suas demandas e propor soluções de T.I. (que mais tarde podem vir
a ser desenvolvidas por projetos) para essas necessidades. A área de Planejamento
exerce assessoria ao Diretor de T.I. e mantém o PMO. A área de Desenvolvimento de
Sistemas contém os Analistas de Sistemas, que projetam e desenvolvem as soluções de
T.I., sejam elas resultado de projetos de novos sistemas ou correções nos sistemas
existentes. As demais áreas compõem o chamado “back office”, ou seja, áreas de
suporte operacional às áreas de Sistemas e Negócios.
Essa necessidade veio a somar-se à necessidade que o executivo da área teve de
demonstrar melhor como os recursos de T.I. eram empregados e que resultados
apresentavam, dados os números de vulto da área quanto ao orçamento e efetivo (tanto
interno quanto subcontratado).
Diferentemente da primeira tentativa de implementação do PMO, porém, nessa
segunda fase tratou-se de envolver mais os gestores no processo. Esses, com uma visão
mais administrativa e menos técnica sobre os projetos, perceberam que mais importante
para a área seria definir um processo pelo qual as demandas deveriam ser recebidas pela
área de T.I. (entrevistado 04), pois dependendo de como se fizesse esse tratamento é que
seria composto o portfólio de projetos e, consequentemente, os compromissos de T.I.
com as áreas usuárias.
Desenvolvido ao longo de uma série de reuniões dos gestores de T.I. com a
gerência de Planejamento (de T.I.), o processo incluía reuniões semanais formalizadas
nas agendas dos gestores, quando se discutiria não apenas o processo em si, mas a
forma como os projetos de T.I. deveriam ser priorizados e conduzidos. Em algumas
semanas após o início dos trabalhos, já era possível dizer o que se queria controlado nos
projetos, da sua concepção ao início da execução.
Com essas definições, partiu-se para a criação de uma ferramenta de T.I. que
98
pudesse atender às principais demandas do processo interno de gerenciamento do
portfólio de projetos da área. Inicialmente, essa ferramenta foi uma pasta de planilhas
eletrônicas, adaptada para as necessidades de T.I. a partir de uma versão que havia sido
implementada pouco antes na área de produção. Foram criadas planilhas e campos nessa
pasta para as definições que os Analistas de Negócios deveriam criar com os usuários
para cada projeto: um project charter
12
, orçamento, lista de resultados intermediários e
finais, equipe envolvida/necessária, plano de comunicações, plano de gestão de riscos,
etc.
Uma pasta dessas deveria ser criada para cada projeto e submetida a um comitê
interno de T.I. que faria sua avaliação, aprovação e priorização da demanda para
execução. O conjunto das planilhas que correspondiam aos projetos em proposta e em
execução num dado instante eram consolidados numa outra planilha, de uso do
Planejamento, que sumarizava os dados dos projetos, separados por gerência de T.I.
proponente (áreas de negócios de T.I.). Assim se conseguia uma visão do portfólio
sobre a qual se podia deliberar a respeito de cada proposta de projeto.
A solução vigorou por pouco mais de um ano, quando a quantidade de projetos
em proposta, em andamento e encerrados tornou-se grande demais para manipulação
por planilhas e decidiu-se então partir para o desenvolvimento de uma ferramenta,
também automatizada, com base em banco de dados ou similar, que pudesse facilitar o
registro e acompanhamento dos projetos por todos os envolvidos, incluindo usuários,
patrocinadores e executivos.
Apesar de considerada de difícil operação, a ferramenta foi considerada como
12
O project charter é um documento que informa dados básicos de um projeto, como a descrição da
necessidade de negócios a ser atendida, prazo em que o projeto deve estar concluído e com seus
resultados implementados, estimativas de custos, recursos e equipamentos necessários, equipe inicial,
gerente do projeto, clientes e patrocinadores, riscos inerentes ao projeto, riscos da não implementação da
solução, ganhos e benefícios esperados, etc. Um modelo de Project Charter para um PMO encontra-se no
Apêndice D.
99
útil e necessária pelos Analistas de Negócios (que recebem as demandas dos usuários e
devem registrá-las na base de dados da aplicação) e também de Sistemas (que atuam
como Gerentes de Projetos e têm que informar os dados de andamento dos projetos).
Um dos problemas com a ferramenta, por exemplo, é o preenchimento
tempestivo das atividades e custos associados. Em projetos de grandes quantidades de
tarefas, a tendência é de mais atraso, pois esses projetos normalmente requerem atenção
mais concentrada dos Gerentes de Projeto.
Contudo, várias foram as opiniões de que o uso da ferramenta foi considerado
necessário pelos gestores, pois assim podiam ter melhor visão do que estava em
andamento por suas equipes (entrevistados 03, 04 e 08). Isso não mudou, porém, o fato
de que o preenchimento das informações no sistema ainda é um problema. Seja pela
dificuldade de preenchimento, falta de condições de fornecer estimativas ou ainda
dificuldades de envolvimento de usuários chave dos sistemas, parar e preencher os
dados nas telas da aplicação é um desafio para alguns porque requer que se anote todas
as atividades e seus resultados ou dificuldades, porque os Analistas de Negócios ainda
alegam não ter o tempo necessário ou ainda por que são centralizadores e deixam tudo
para si mesmos. Com a sobrecarga de cada pessoa, dificuldade de envolver os
interessados com mais poder de decisão ou ainda pela simples indisciplina pessoal de
cada funcionário, o preenchimento de apenas algumas telas de informação na aplicação
torna-se um desafio até para analistas com maior tempo de experiência.
A análise das entrevistas, a seguir, visa relacionar os pontos de vista dos gestores
de T.I. sobre o processo de implementação do PMO, considerando os objetivos da
pesquisa: identificar os fatores facilitadores e dificultadores da implementação.
100
4.2 Resultados
Nas entrevistas, foram ouvidos nove gestores de T.I. (entrevistados 01 a 09) e as
entrevistas surpreenderam, de certa forma, quanto à riqueza de detalhes das informações
obtidas e pela disponibilidade de todos para o relato de suas experiências.
Com relação ao conhecimento em Gerenciamento de Projetos, os entrevistados
demonstraram, de forma geral, possuir algum conhecimento prévio (à implementação
do PMO) e todos citaram haver aprendido pelo menos um pouco mais a respeito durante
a implementação do PMO.
Os entrevistados mostraram, também, que compartilham das mesmas
dificuldades de gestores de outras empresas para a implementação de mudanças como
essa em um ambiente de negócios. Entre essas dificuldades, citaram: limitação de
recursos, principalmente verbas, pessoas (tanto numérica quanto qualitativamente),
prazos a serem cumpridos, capacitação para Gerenciamento de Projetos e técnicas de
negociação para melhor discutir e obter consenso com as áreas solicitantes de produtos
e serviços de T.I. a respeito de requisitos, custos e prazos.
Finalmente, quanto a terem adquirido algum conhecimento novo sobre
Gerenciamento de Projetos após a implementação, todos mencionaram ter ganhado
conhecimento a respeito do assunto.
Obtidas essas primeiras informações a respeito dos entrevistados, as entrevistas
seguiram o roteiro descrito no Anexo A. Estruturado em uma forma lógica que visa a
conduzir o entrevistado do momento em que se iniciou a implementação do PMO até os
dias atuais, o roteiro identifica os pontos de vista dos respondentes em relação a como
era o ambiente de gerenciamento de projetos na área estudada antes da implementação
do PMO, os motivadores para a implementação do PMO, como transcorreu o processo,
101
que ganhos e eventuais perdas a área poderia ter percebido e como ficou o
gerenciamento de projetos na área após essa implementação.
Das respostas, identificam-se os seguintes tópicos: a) motivadores para a
implementação do PMO, b) reflexos positivos trazidos à área, c) ferramentas
introduzidas ou utilizadas no processo, d) pontos negativos (ou para melhoria) do
processo e e) fatores que dificultaram ou facilitaram o processo como um todo.
4.2.1 Motivadores para a implementação do PMO
Em relação aos motivadores para implementação do PMO, foi praticamente
unânime entre os entrevistados que o maior fator motivador do PMO foi uma
determinação do alto executivo da área a que pertence a estrutura de T.I. da Empresa
para que a área pudesse emitir uma visibilidade mais precisa e completa do seu portfólio
de projetos.
A principal instrução desse executivo havia sido que se desse, em apresentações
mensais de resultados das várias diretorias sob sua responsabilidade, uma visibilidade
sobre a demanda que a área de T.I. tinha e alguns indicadores mínimos: quantidade de
pedidos em aberto, pedidos em andamento e fila de espera. Essa instrução veio em
resposta às constatações, por parte da diretoria de T.I., de que seus recursos eram
insuficientes para suprir aquela demanda, apesar do orçamento alocado e a quantidade
de pessoas, equipamentos e sistemas em operação.
Seguindo essa determinação, a área de planejamento de T.I. iniciou, então, a
implementação do PMO, com a inclusão de objetivos secundários, que auxiliavam os
gestores na condução de seus próprios projetos: descrever a demanda, determinar os
principais pontos de escassez de recursos, prover uma base para negociação de
102
prioridades e melhorar a capacidade de entrega dos projetos (cumprir prazos, reduzir
custos e melhorar a qualidade dos produtos finais – sistemas e infra-estrutura).
Uma pesquisa entre membros do PMI, apesar de estatisticamente não
conclusiva, apresenta a mesma tendência de objetivos ao se implementar o PMO: pelo
menos uma de cinco opções foi citada: a) controlar ou cortar custos em projetos, b)
melhorar a priorização do portfólio de projetos, c) melhorar a visibilidade do portfólio e
d) melhorar a alocação de recursos, sendo a mais citada foi a quinta, “d) todas as
alternativas acima” (PMI, 2005).
4.2.2 Reflexos positivos da implementação do PMO
Os reflexos positivos (ou ganhos) que o processo trouxe mais comentados
foram:
• permitiu obter melhor conhecimento da demanda, uma vez que se obriga o
registro dessa demanda para posterior tratamento;
• para novos projetos, levou a uma melhor definição de escopo (“definir certo”
os projetos: mais envolvimento dos usuários, formalização das aprovações
necessárias e melhor estimativa dos recursos necessários), o que permite
estabelecer compromisso com os usuários (clientes internos dos projetos) e
evita cobranças do que não está no escopo dos projetos, quando de sua
avaliação (final ou intermediária) (entrevistado 06);
• com isso, o processo ajudou a ter uma visão mais realista do conjunto dos
projetos que entraram em andamento, quais estão ou não alinhados com a
estratégia da área e da empresa, quais estão em situação comprometedora e
devem ser cancelados ou, pelo menos, completamente replanejados;
103
• conseqüentemente, o processo facilitou a seleção dos projetos (executar os
“projetos certos”);
• permitiu mais controle e visibilidade do portfólio e, com isso, mais
integração entre as áreas, para uma melhor alocação dos recursos de forma
geral (entrevistados 01 e 08);
• pela implementação gradual e envolvimento dos gestores na definição do
processo de gestão da demanda, facilitou o aceite dos profissionais de T.I. ao
longo do processo;
• também pela implementação gradual, o aprendizado, em conjunto, do
conhecimento básico sobre gerenciamento de projetos e gerenciamento de
portfólios foi facilitado (entrevistado 04);
• permitiu uma ferramenta para melhor negociação com os usuários: mais
recursos para questionamento sobre os motivos para cada projeto e mostrar
aos usuários quanto a T.I. estava trabalhando para cada um em particular.
Sobre as ferramentas utilizadas e introduzidas, na visão de gestores, as planilhas
inicialmente criadas e posteriormente refinadas eram simples e atendiam ao necessário
para gerenciamento das áreas de T.I. e visão do portfólio que cada analista deveria
gerenciar.
O sistema também ocasiona, segundo alguns, demora por parte do Analista de
Negócios no preenchimento dos requisitos da solicitação e existe ainda uma demora
excessiva da área de Sistemas nas respostas sobre estimativas de prazos e recursos
necessários. Também foi considerada difícil a atualização dos dados de projetos em
andamento, o que na maioria das vezes causa inserção de dados sem critérios, “para
cumprir tabela” (entrevistado 01).
104
O índice de projetos original, também baseado em planilha eletrônica, estava
melhor, e ainda falta no sistema a “visão consolidada dos projetos por área (para melhor
visualização pelo gestor dos projetos sob sua responsabilidade)” (entrevistado 03).
Contudo, já ter-se um ambiente centralizado e com mais controle sobre atualizações das
informações facilita a integração das áreas, que podem discutir, com base em
informações comuns, os projetos em que estão simultaneamente envolvidas
(entrevistado 06).
Foi também apontado que ainda falta mais aceitação por parte dos usuários,
possivelmente devido à falta de divulgação ou divulgação incorreta das funções e
benefícios não apenas da ferramenta, mas do processo em que ela é utilizada
(entrevistados 02 e 03).
4.2.3 Pontos negativos e fatores dificultadores da implementação do PMO
Os pontos negativos do processo identificados, ou em que ele ainda poderia ser
melhorado, uma vez que a implementação do PMO não está concluída, foram:
• não foi visto o lado das diversas áreas de T.I., ou seja, de quem operaria o
sistema, quando se “decretou” que era obrigatório incluir e atualizar certos
dados dos projetos;
• ainda não há “publicação formal” do portfólio para os clientes (dar-lhes
visão simples do que solicitaram, para que possam priorizar melhor os
pedidos feitos – novos e alterações);
• o processo de Gerenciamento da Mudança ainda não está claramente
definido (é necessário definir e organizar melhor as passagens de fases dos
projetos);
105
• falta ainda uma capacitação mais adequada dos analistas e gerentes de
projetos, incluindo o uso da aplicação de registro e acompanhamento dos
projetos; até porque esses profissionais, apesar de lidarem naturalmente em
“projetos”, não viam a atividade com essa perspectiva, ou seja, é natural para
o Analista de Sistemas que o produto a ser gerado o seja feito de forma
estruturada (análise, definição de requisitos, desenvolvimento de diagramas
de relacionamento, projeto da base de dados, formas de acesso, codificação,
testes, implementação e acompanhamento), mas não o projeto em si: definir
escopo (do projeto, não só do produto), planejar recursos, estimar custos,
prazos e entregas, providenciar controles sobre os testes e aceitação formal
dos usuários (clientes internos) sobre o que for entregue e encerrar
pendências (contratos, sessões de equipamentos ou software, devolução de
pessoas às áreas de origens, recolher documentação, etc.);
• uma melhor capacitação (e experiência) que teria sido um diferencial,
também, seria que o processo todo fosse conduzido por alguém com
experiência em tais implementações, com conhecimento sobre os entraves
mais comuns e as formas mais eficazes de contorno para esses obstáculos
(entrevistado 06);
• o sistema atual para registro e acompanhamento das demandas, projetos e
portfólio “complicou o processo” (entrevistado 01), pois introduziu muitos
detalhes no cadastramento dos projetos, cuja finalidade e forma de
preenchimento não ficou clara a quem opera o sistema pela primeira vez;
além disso, ao se desenvolver a ferramenta que substituiu o esquema
anterior, de controle feito com planilhas, aparentemente perdeu-se o
aprendizado do uso das planilhas, ou seja, um novo projeto, desenvolvido do
106
começo, não considerou o que havia de bom com as planilhas e ainda
acrescentou problemas que as planilhas não tinham (entrevistado 01);
• ainda não é obrigatório o registro de todas as atividades das áreas (pendentes
e em execução), o que influi nas atividades de condução de projetos (devido
à priorização de esforços entre “projetos” e “atividades da área”);
• organizar melhor a pauta do CITI
13
, para melhorar a análise sistêmica dos
pedidos (sistemas que afetam outros sistemas) e só envolver as pessoas
necessárias, incluindo infra-estrutura e segurança, quando necessário (e não
obrigatoriamente em todas as reuniões do comitê);
• dar ainda mais rigor na definição de escopo e negociação de requisitos:
demonstrar aos clientes o valor do processo (ganhos para eles, como
priorização e visibilidade), melhorar a conexão com o Plano de Ação da
diretoria e aprimorar a gestão de riscos e a gestão de custos de uma forma
geral (item pouco valorizado no processo até o momento de conclusão desta
pesquisa) (entrevistado 01);
• definir um processo de revisão dos projetos concluídos (controle de
qualidade, lições aprendidas, revisão do processo, gerar informações para
melhoria de capacitações ou contratações com base nos resultados da
revisão, etc.).
Em relação a como se deu o processo de implementação do PMO, as entrevistas
analisadas mostram que houve uma falha clara em termos de comunicação do propósito
da implementação.
Por exemplo, muitos analistas não sabiam do que se tratava já no primeiro
13
CITI-Comitê Interno de T.I. – comitê composto pelos gestores de T.I., administrador de recursos de
desenvolvimento de sistemas e responsável pelo PMO, reunido semanalmente para análise das propostas
de projetos, priorização do portfólio e outros assuntos relativo ao portfólio de projetos de T.I.
107
contato com a equipe de treinamento básico; vários nem tinham sido convocados para
as sessões de esclarecimento e treinamento; os gestores aparentaram não ter dado a
devida importância ao projeto (não porque não apoiassem a idéia, mas principalmente
por terem sido, eles mesmos, mal informados a respeito de como o processo deveria
transcorrer e, principalmente, qual seria o seu papel no projeto).
A estratégia adotada, de pequenas conquistas sucessivas com vistas ao objetivo
principal (ter o PMO implementado) dificultou um planejamento adequado, mais
abrangente, com visão das metas intermediárias e definitivas mais claras, funções chave
para o PMO e seus integrantes e apoios requeridos, entre outros requisitos de um bom
projeto. Com isso, para muitos a imagem que se teve foi de um conjunto de iniciativas
desconexas, aumento não justificado da carga administrativa de trabalho, dificuldade de
negociar prazos para responder aos usuários solicitantes de alterações e novos
desenvolvimentos de soluções de T.I., etc.
Algumas respostas, porém, indicaram a percepção de que o processo apenas
introduziu burocracia. Por parte dos clientes dos projetos, a percepção de alguns foi de
que teriam mais dificuldade no atendimento de suas solicitações (dificuldades para
explicar as necessidades, impor alternativas preferenciais, limitar custos, etc.).
Como fatores que dificultaram o processo, identificamos nas respostas os
seguintes:
• o planejamento da implementação foi incompleto e pouco divulgado, o que
dificultava, de início, o entendimento de todos sobre o que se pretendia;
assim, a confiança na solução, por parte dos analistas e demais envolvidos,
ficou comprometida;
• esse planejamento, se feito com mais amplitude de visão futura, poderia ter
providenciado que o processo todo fosse incorporado gradativamente aos
108
procedimentos normais de trabalho das equipes para, assim, garantir sua
evolução contínua (entrevistado 06);
• assim, teria sido melhor trabalhar mais a comunicação para obter mais
envolvimento de todos, principalmente escalões superiores (diretoria e vice-
presidências envolvidas) e também os clientes internos dos projetos de T.I.
(entrevistados 03 e 06); dos primeiros, é sempre necessário o apoio na
obtenção de recursos (quer sejam humanos, materiais ou mesmo tempo –
renegociação de prazos) e dos últimos sempre será necessário poder-se
negociar prazos e requisitos, conforme as disponibilidades de recursos para
atendê-los sofram variações que afetem o que havia sido combinado e
definido nos projetos;
• a capacitação do pessoal foi insuficiente e ter continuado e aprofundado o
conhecimento de todos em tópicos importantes, como análise de viabilidade,
definição e controle de custos, planejamento de cronogramas, etc., poderia
ter contribuído para uma melhor assimilação de todos sobre o processo e a
importância de se manter a documentação dos projetos atualizada;
• sobre o processo em si, teria sido um facilitador comunicar mais claramente
aos envolvidos que os controles a serem estabelecidos visavam à melhor
gestão do ambiente de projetos, e não à comparação ou classificação do
desempenho individual das pessoas (entrevistado 04);
• a burocracia, entendida como necessária, ainda é vista como redutora de
agilidade (deveria haver, por exemplo, um “processo simplificado” para os
“pedidos pequenos ou urgentes e emergenciais”, que não necessitam de todas
as definições e formalidades dos projetos mais complexos);
• essa burocracia ajuda a reforçar o conceito vigente na empresa, em relação às
109
áreas de apoio – como o são a T.I., a infraestrutura, a segurança corporativa,
entre outras – da “cultura do atender” (entrevistado 06), segundo a qual essas
áreas devem ser “ágeis”, o que frequentemente é traduzido em “tem que
fazer, vamos fazer”; isso diminui a importância das atividades de
planejamento e documentação e pode afetar o processo decisório;
• ainda é necessário mais controle da qualidade sobre as informações
registradas no sistema (evitaria o preenchimento “para cumprir tabela”, ao
trabalhar mais com a conscientização da necessidade da correta
documentação, ao invés de apenas tornar essa documentação obrigatória);
• um dos pontos positivos do esquema anterior (controle com planilhas) que se
perdeu com a nova ferramenta foi a questão dos sumários de projetos – uma
visão consolidada, geral ou por gerência de T.I., em que os projetos eram
vistos como um conjunto, que permitia compará-los, classificá-los, etc. –
simplificação, enfim, do sistema;
• não há clareza na definição de que o PMO formalmente acompanha os
projetos ou apenas “cobra o preenchimento das informações”;
• em relação ao processo completo de gestão da demanda, incluindo discussão
das propostas no comitê e casos “emergenciais” ou “simples”, este deveria
ser revisto em termos de agilizar o que for possível, para realmente agregar
valor (pelo controle adequado e suficiente) e não limitar o atendimento das
demandas (com entraves meramente burocráticos, que atrasam o processo);
• definição de papéis e responsabilidades, inclusive com separação, se
possível, das atividades de análise e desenvolvimento de sistemas e
gerenciamento de projetos, muitas vezes executadas pela mesma pessoa, no
mesmo projeto (o que deve fazer e o que se espera dos Analistas de
110
Negócios, Analistas de Sistemas, Gerentes de Projetos, sponsors, gestores
funcionais e executivos – também deveria haver mais definição dos critérios
para a seleção dessas pessoas quanto aos projetos) (entrevistados 04 e 07);
• essa definição poderia reduzir o impacto negativo em termos de prazos nas
etapas por que passa uma análise e aprovação de um atendimento de
demanda ou proposta de projeto: ao saberem mais exatamente qual sua
função no processo, as pessoas poderiam deliberar com mais rapidez nas
etapas em que são envolvidas (entrevistado 08);
• a reestruturação da área, que redistribuiu as pessoas nas áreas de sistemas de
T.I., trouxe alguma incerteza quanto ao resultado das mudanças,
permanência das pessoas na área ou mesmo nos empregos, aceitação por
parte dos clientes internos, etc.;
• o Plano de Ação (da área e de cada gerência) ainda é “vago” em termos de
objetivos específicos a serem atingidos por projetos;
• o “momento” vivido pela área com o projeto de ampliação do sistema SAP
(este agiu como o “grande divisor de esforços”, altamente prioritário,
demandante de modificações no restante da estrutura de sistemas e infra-
estrutura, o que deixou poucos recursos para se falar sobre projetos);
4.2.4 Fatores facilitadores da implementação do PMO
Os fatores que facilitaram o processo, mais mencionados, foram:
• uma boa parte dos profissionais que gerenciam projetos percebeu a
necessidade e as vantagens de se organizar a condução dos projetos na área
de T.I. da Empresa e, com isso, melhorar o relacionamento com as áreas
111
usuárias das soluções de T.I. que esses projetos implementam;
• a oportunidade de aprender uma nova técnica, como é praticamente qualquer
assunto sobre Gerenciamento de Projetos atualmente (Gerenciamento de
Configuração, Gerenciamento de Mudança, Gerenciamento de Riscos, etc.),
aliada à possibilidade de ascender a atribuições de maior relevância foi, para
alguns, um motivador importante;
• apesar da burocracia inerente aos processos de controle de qualquer estrutura
como a do PMO, os profissionais que estavam sob forte pressão de prazos,
falta de recursos e excesso de carga de trabalho viram no PMO uma
possibilidade de, pelo menos, organizar essa carga excessiva e evitar os
conflitos das constantes renegociações de prazos com usuários finais dos
sistemas em desenvolvimento ou manutenção na área de T.I.;
• para os gestores, sem dúvida ficou evidente a melhora significativa em
relação à visibilidade do portfólio de projetos; hoje, se não está
completamente organizado e priorizado, pelo menos está definido em termos
de quantos projetos se tem em execução, inclusive estratificado por
tecnologia (plataforma de hardware e software necessária) e área usuária;
com isso, algumas solicitações por recursos podem ser mais bem respaldadas
e defendidas por esses gestores e o executivo encarregado;
• ainda para os gestores, está pendente a questão de controle de custos dos
projetos, mas com a melhora da visibilidade do portfólio vem também a
percepção da necessidade de se estabelecer melhores formas de orçamento e
controle de custos dos projetos.
Por outro lado, houve entrevistados que perceberam, na estratégia, uma
impressão inversa: a de que, aos poucos, cada objetivo cumprido (as “pequenas
Excluído:
¶
112
conquistas”) permitia “melhor assimilação de cada conceito, processo ou etapa de
processo em definição pela sua experimentação gradual” (entrevistado 06). De fato,
pudemos perceber que algumas metas intermediárias, como o fluxo das reuniões
semanais de apresentação e defesa de projetos, puderam ser mais enfatizados em termos
de objetivos, seqüência de ações em que cada participante deveria participar,
aprendizado dos critérios de julgamento para aprovação ou reprovação de projetos, etc.
Isso levou ao refinamento de alguns detalhes em forma de consenso entre as áreas de
T.I. envolvidas: sistemas, negócios, suporte e infra-estrutura e segurança da informação
(essas três últimas conhecidas como áreas de “backoffice”).
A primeira tentativa de estabelecer um PMO na área de T.I. da Empresa deixou
isso claro, além de evidenciar um viés natural dos profissionais de tecnologia, quando se
refere à implementação de novas soluções para problemas técnicos ou administrativos: a
de se concentrar esforços, já no começo das atividades, em alguma ferramenta de
software para apoio aos trabalhos de entrada de dados, registro, processamento e
armazenamento de informações, emissão de relatórios ou criação de apresentações de
suporte a reuniões de discussão ou relatório de andamento de projetos, etc. Na segunda
tentativa, deixou-se essa mesma impressão em alguns, apesar do recomeço ter sido um
pouco melhor.
Nessa tentativa, buscou-se primeiro definir um processo pelo qual seriam mais
bem analisadas e priorizadas as várias solicitações que chegam de praticamente todas as
áreas da empresa. Esse processo deveria fazer com que a lista de pedidos de alterações
em sistemas existentes, a inclusão de novos sistemas ou interfaces entre esses e a
exclusão ou substituição de aplicativos obsoletos ou desacordo com alguma norma ou
lei. A esse processo deu-se o nome de “Processo de Gestão da Demanda de T.I.”, e na
literatura encontramos o tema mais comumente como “Gerenciamento de Portfólio de
113
Projetos”. As primeiras versões do controle dessa demanda eram relacionadas em
planilhas, não consolidadas e sem interface entre si. A primeira providência foi
padronizar o documento eletrônico a utilizar. Um modelo proveniente de uma das áreas
de Engenharia da Empresa foi adaptado às necessidades da área de T.I. e do Vice-
presidente ao qual ela estava subordinada na época da pesquisa.
Esse modelo, inclusive, deveria ter servido para aprimorar o processo pelo qual
todo Analista de Negócios de T.I. definiria o escopo “macro” do projeto, inclusive com
informações de custos e riscos. Na opinião do executivo da área, porém, esse objetivo
não foi ainda alcançado, mesmo após o segundo ano de uso do processo. Segundo o
entrevistado, “havia poucas diferenças em relação à situação atual, onde ainda falta mais
planejamento para os projetos, tanto em termos de estratégia (justificativa e seleção de
projetos) quanto de detalhamento dos projetos (definição de escopo, atividades,
recursos, prazos e métricas, etc.)” (entrevistado 04). Com isso, as mudanças de escopo
ainda são constantes e significativas para o desempenho em projetos, há perda de
recursos, na medida em que tempo e pessoas não são mais bem aproveitados e,
principalmente, a “cultura de gerenciamento de projetos ainda não está completamente
instalada na área” (entrevistado 07). Na opinião de ambos acima, ainda é necessário
completar a capacitação dos gerentes de projetos.
A análise do processo de implementação do PMO na Empresa também mostrou
pontos de concordância com os resultados da pesquisa de Hobbs e Aubry (op. cit.), que
identificou como pontos para melhoria, algumas funções críticas para o sucesso dos
PMOs, agrupadas da seguinte forma:
• desenvolvimento e implementação de metodologias: o PMO da Empresa
ainda precisa concluir o desenvolvimento da metodologia padrão de
planejamento de projetos e comunicar esse padrão aos gerentes de projetos e
114
principais intervenientes (usuários, fornecedores e gestores das áreas
envolvidas ou servidas pelos projetos);
• monitorização e controle de desempenho dos projetos: a ferramenta
implementada recentemente para monitorização e indicação de desempenho
e andamento dos projetos ainda requer melhorias e definições mais
completas, que têm sido feitas conforme a necessidade e conforme a cultura
de Gerenciamento de Projetos se difunde na área de T.I. Ainda é necessário
que os gestores definam os parâmetros pelos quais medem desempenho de
seus projetos e que informações lhes são necessárias para controlar as
atividades desenvolvidas e a concluir e reportar corretamente sobre o
andamento de seus projetos.
• assumir coordenação dos projetos: o PMO em estudo não tem, por definição
de sua criação, a tarefa de assumir o gerenciamento efetivo dos projetos de
que mantém visibilidades. Contudo, é função de um PMO estar preparado,
em termos de pessoal e outros recursos, para assumir projetos problemáticos,
para trazê-los a termo em condições satisfatórias para todos os
intervenientes. Essa capacidade para orientar gerentes de projetos em
dificuldades ainda é limitada, devido à pequena equipe que compõe o PMO
em questão.
• mentoria para gerentes de projetos: nesse ponto, o PMO estudado está em
condições apenas de auxiliar aos gerentes de projetos iniciantes, visto que as
necessidades destes são mais simples; porém, com gerentes de projetos mais
experientes, ou para projetos mais complexos, é possível que haja escassez
de recursos ou tempo hábil para coordenar as ações para vários gerentes de
projetos simultaneamente.
115
• implementação de sistemas de informação para o gerenciamento de
projetos: a questão de tecnologia de informação para suporte às atividades do
PMO e dos projetos sob sua administração ainda não foi completamente
resolvida. Até o ponto de conclusão deste trabalho, a orientação da diretoria
da Empresa nesta questão é que seja utilizado o módulo de gerenciamento de
projetos do sistema SAP R/3 v. 4.7 (PS), cuja implementação não havia sido
concluída até a data de conclusão deste trabalho.
• desenvolvimento de competências e recrutamento dessas competências:
devido a diversas restrições sobre a área de T.I. da Empresa, os recursos
necessários para esse desenvolvimento tem sido escassos, e quaisquer
adições ao quadro de pessoal ou contratações de serviços externos (como
consultorias, por exemplo) devem aguardar aquela atualização de sistema
para poderem ser postuladas junto à direção da empresa.
• comunicação do valor do investimento em um PMO: também tem sido um
ponto de difícil solução para a área de T.I. da Empresa. Tradicionalmente
naquela empresa, os investimentos em organização e definição de
metodologias e padrões são vistos como despesa adicional, e o pessoal de
projetos da área de T.I. deve refinar a forma como faz tais comunicações. É
preciso desenvolver mais massa crítica para demonstrar o valor do PMO,
com melhores índices de desempenho dos projetos e como o PMO tem
influenciado na melhoria desses índices.
4.3 Síntese do processo de implementação do PMO
A primeira pergunta da entrevista (“Antes da implementação de processos e
Formatado: MGDR-Parágrafo
normal, Espaço Antes: 0 pt,
Depois de: 0 pt
Excluído:
¶
116
padrões para gerenciamento de projetos na área, qual era, em sua opinião, a forma de
condução dos projetos de T.I.?”) visava identificar o grau de conhecimento médio dos
entrevistados em relação à disciplina de gerenciamento de projetos.
Conforme se percebeu pelo conjunto de respostas, não havia, à época do início
dos trabalhos, gestor naquela área de T.I. com experiência anterior em implementação
de PMO. Essa pode ter sido a causa de algumas das dificuldades encontradas durante o
processo, em que alguns conceitos específicos de gerenciamento de projetos, portfólio e
PMO não terem sido completamente absorvido por esses gestores.
As respostas à segunda pergunta da entrevista (“Quais foram os fatores
motivadores e principais objetivos para a implementação do gerenciamento de projetos
na área, àquela época?”) permitem constatar-se que o principal motivo pelo qual se
decidiu implementar o PMO estudado foi o de prover visibilidade sobre os projetos em
andamento à época. Era necessário não apenas prover essas informações para o diretor
de T.I. da Empresa, mas também aos gestores da área que tinham projetos sob sua
responsabilidade. Para o diretor, essa visibilidade poderia fornecer subsídios para a
tomada de decisões a respeito das operações de T.I., sobre as estratégias a serem
adotadas e os resultados pretendidos, além de permitir a definição de planos de ação
para se negociar recursos, prazos, etc.
Para os gestores, o benefício principal seria o de terem à disposição, de maneira
mais tempestiva, as informações mais detalhadas sobre a alocação de seu pessoal nos
projetos, os resultados obtidos com esses projetos e conhecer melhor as dificuldades
encontradas, além de poder identificar alternativas, implementar correções em um prazo
menor, pelo menos suficiente para minimizar ou, eventualmente, eliminar eventuais
perdas.
O apoio, além de determinação formal do diretor da área para que se organizasse
117
o gerenciamento de projetos da área de T.I. é freqüentemente citado na literatura como
“fator crítico de sucesso” para projetos de tal complexidade (ENGLUND; GRAHAM;
DINSMORE, 2003, p. 11; CRAWFORD, 2002, p. 83; KENDALL; ROLLINS, 2003,
cap. 1). Segundo a maioria dos autores, a iniciativa “de cima para baixo” deixaria como
desafio apenas o convencimento da estrutura organizacional, teoricamente mais fácil se
os níveis superiores já estivessem convencidos da necessidade da solução. Esse apoio,
porém, apesar de essencial como fator de sucesso para a implementação de um PMO,
não se mostrou suficiente.
Esse grande objetivo seria o de evitar o “gerenciamento acidental”, comentado e
condenado por Block e Frame, que dificulta às empresas enfrentar os desafios e explorar
as oportunidades (BLOCK; FRAME, 1998). Esse gerenciamento acidental, descrito por
Block e Frame, foi inclusive mencionado como informal: “A priorização, o andamento,
o custo e demais ‘atributos’ (sic) estavam diretamente atrelados ao poder de persuasão
de seus solicitantes. ... existia uma grande insistência dos gestores na falta de pessoas
para fazer frente a tanta demanda, mas não se sabia dizer exatamente de que se
tratavam.” (entrevistado 03). Os resultados finais que se pretendia podem, então ser
descritos em termos de redução do ciclo de produção (tempo médio para o
desenvolvimento de sistemas e correções ou melhorias), redução de custos e melhoria
da qualidade dos produtos conforme citado por Crawford (2002).
Esse “gerenciamento acidental”, porém, como já dissemos, não pode ser
confundido com o “informal”, muitas vezes necessário. As definições formais,
permitem esse entendimento e podem agilizar a comunicação (RABECHINI JR, 2003).
Além disso, os empregados que entendem a estrutura organizacional em que atuam
podem trabalhar melhor (KERZNER, 1999 apud. RABECHINI JR, 2003).
A situação da área de T.I. pesquisada, naquela época, praticamente foi descrita
118
por Schneidmuller e Balaban, ao descreverem como emergiu a idéia de PMO na AT&T,
entre as décadas de 1980 e 1990, em que os gerentes de projetos não tinham uma forma
única e consistente de gerenciamento de seus projetos, não tinham apoio organizacional
suficiente, eram avaliados por seus respectivos gestores com critérios independentes e
poucos haviam sido treinados em gerenciamento de projetos, além de exercer essa
função apenas em tempo parcial (SCHNEIDMULLER; BALABAN, 2000, p.1, apud
ENGLUND; GRAHAM; DINSMORE, 2003, p. 9).
O PMO que se pretendeu implementar seria, então, condizente com o que a
literatura define como “estratégico” que visa controlar o andamento dos projetos a fim
de se obter resultados melhores para os negócios em termos do portfólio de projetos, e
não necessariamente em termos de projetos individuais. Essa capacidade que a empresa
tem de gerenciar seus projetos e programas já foi fortemente relacionada com a sua
capacidade de implementar suas estratégias de negócios, ou seja, melhorar a capacidade
de gerenciamento de projetos melhora os resultados dos negócios (CRAWFORD, 2004;
TURNER, 2003). Finalmente, podemos ainda identificar nesses objetivos iniciais do
PMO estudado uma forte correlação com as áreas de ação das empresas atendidas por
projetos estratégicos, definidas por Prado (2004, p. 181):
• melhoria dos resultados econômico-financeiros: certamente a área de T.I. em
questão não tinha como objetivo a conquista de novos mercados, mas ainda
havia correlação com melhorar os índices econômico-financeiros da área.
Uma maneira de se conseguir isso é pelo aumento da produtividade ou
inovação, e isso exige melhor conhecimento sobre os resultados finais dos
projetos; assim, seria preciso começar por controlá-los de forma mais
metódica e detalhada;
• acompanhamento do mercado e concorrentes (benchmarking): apesar de
119
alguns paralelos que se poderia fazer entre a área de T.I. da Empresa e esses
assuntos, não foi essa uma área que tivesse relação muito significativa com a
área estudada;
• conservação e melhoria da imagem: nesse ponto, a área de T.I. estudada
precisava de um forte trabalho de melhoria da imagem, pois sofria com o
estigma de ser área “de despesa e não de resultado”, comum à maioria das
áreas de T.I. nas empresas; para isso, sempre devia provar “por que deve ser
tão grande”, “por que tem orçamento tão alto”, etc.; assim, organizar-se
melhor para conhecer e mostrar os resultados dos projetos era (e sempre
será) relevante;
• conservação e ampliação da capacidade técnica, social e gerencial: da
mesma forma que o item anterior, poder emitir demonstrações mais precisas
e tempestivas de resultados dos projetos deveria resultar em
desenvolvimento profissional dos envolvidos na gestão da área, o que em
grande parte das vezes resulta nesse “desenvolvimento social” (no âmbito da
empresa) em forma de melhor relacionamento com as áreas usuárias das
soluções e recursos de T.I., e isso facilita negociações desde o escopo de
cada projeto até a exposição de resultados desses projetos, ainda que não
satisfatório como os usuários esperassem;
• crescimento do nível tecnológico da empresa: sem dúvida isso foi
observado; na época em que se decidiu pelo PMO, a empresa experimentava
um crescimento vertiginoso, resultado de uma nova linha de produtos, até
então com apenas um concorrente internacional, mas com qualidade,
desempenho e aceitação pelo mercado muito mais forte que o concorrente;
como resultado disso, a infra-estrutura de T.I. como um todo (sistemas,
120
tecnologia e pessoal) teve que, rapidamente, se expandir para tentar atender à
demanda crescente em um tempo que não comprometesse os resultados de
negócio planejados pela Administração.
•
Partindo-se, então, dessa idéia válida de visão e objetivos para o PMO, a
próxima fase foi a atribuição da tarefa a uma profissional com formação e experiência
anterior na condução de projetos compatíveis com o que se esperava em termos de
desenvolvimento da organização do trabalho com projetos na área de T.I. Essa pessoa,
ao entrar para a área de T.I. da Empresa, percebeu inicialmente que “o plano de ação da
diretoria era sustentado pelos projetos, mas não havia efetivamente 'gerenciamento de
projetos'“ (Entrevistado 07); o máximo que havia implementado ali era um sistema
aplicativo, desenvolvido internamente, onde os analistas cadastravam os pedidos de
áreas usuárias que ainda estavam por ser atendidos, daí o nome da aplicação: backlog.
Para auxiliar a essa profissional, foi contratado um consultor de projetos, com
recomendações e experiência, que conhecia bastante sobre estruturação de projetos. Até
então, segundo eles a principal preocupação “era ter os cronogramas feitos; os analistas
não tinham a visão de começo-meio-fim para projetos ... não havia controle do
andamento, mas apenas registro do andamento dos projetos, sem padronização de
nomes, fórmulas e formas de atualização. Os registros estavam sempre desatualizados, e
só era registrado o que era cobrado” (Entrevistado 07). O trabalho mostrava, então, que
implementar um ambiente de gerenciamento de projetos seria, principalmente, uma
questão de mudança cultural na área. Conforme Rabechini observa em sua tese sobre a
institucionalização do gerenciamento de projetos numa organização, “um programa
desta natureza deve contemplar mudanças em procedimentos, em estratégia, em
comportamento e em postura gerencial. Isto realmente é um processo extremamente
Formatado: Fonte: Itálico
Formatado: Com marcadores
+ Nível: 1 + Alinhado em:
1,25 cm + Tabulação após:
1,89 cm + Recuar em: 1,89
cm
121
complexo e longo.” (RABECHINI JR., 2003).
Em razão da necessidade de ser ter uma visão mais clara a respeito de projetos e
seus impactos, a área iniciou a busca por uma solução de software que fizesse as
funções de cadastro e exibição, de forma ordenada, do portfólio de projetos. Um
ambiente de avaliação foi montado especificamente para esse fim, onde se
experimentou um produto baseado em software
14
“servidor” com um banco de dados
que poderia ser acessado pelos envolvidos nos projetos e seus gestores a partir de suas
estações de rede da empresa, com uma interface “cliente”. Tendo os testes sido
considerados bem sucedidos em termos de avaliação das funcionalidades do produto,
sua aquisição, porém, foi recusada pelo responsável pela T.I. à época, devido aos
elevados custos de aquisição, implementação e manutenção; o treinamento também
deveria ser completo a todo o efetivo de T.I. e o custo seria alto, além do tempo
necessário para contemplar a todos que trabalhavam em projetos
15
.
Uma segunda tentativa foi feita, ainda com o intuito de se organizar a
visibilidade de projetos em andamento, seus cronogramas e situação atual. Uma solução
baseada em web
16
foi localizada e experimentada localmente, em princípio com
condições de atender a área. Seu uso era relativamente simples, apesar de requerer um
servidor com banco de dados, onde seriam armazenadas informações provenientes de
cronogramas individuais
17
. As configurações iniciais tomaram em torno de uma semana,
mas puderam ser documentadas sem dificuldades. O uso pelos analistas que conduziam
projetos, porém, levou mais tempo, devido às tradicionais dificuldades de agenda e
14
Optou-se pelo sistema da Microsoft, na época a versão Project Central, que acompanhava o Microsoft
Project 2000 e para o qual, por contrato corporativo, a Empresa já dispunha de suporte técnico e
comercial.
15
Como acontece nas demais áreas de T.I. em outras empresas, a da Empresa pesquisada não executa
apenas projetos, pois é responsável também pela operação e suporte ao ambiente de tecnologia para a
empresa. Assim, nem todos os funcionários da área teriam que passar pelo treinamento.
16
Project Repórter, da Cogentex, relativamente desconhecido no mercado brasileiro.
17
No formato de arquivos gerado pelo Project, da Microsoft.
122
resistência, apesar de ser um produto de tecnologia.
Novamente ocorreu com essa solução algo muito parecido com a anterior:
devido à necessidade de optar entre atender à crescente demanda e manter cronogramas
atualizados, os analistas freqüentemente deixavam essa tarefa em segundo plano. Com
isso, as informações disponíveis no sistema nem sempre estavam atualizadas e úteis, o
que levou, gradativamente, ao uso de alternativas tradicionais para apresentações de
resultados. O uso do software para visibilidade do portfólio de projetos foi, então,
novamente descontinuado e por um período de aproximadamente um ano a área voltou
à situação anterior – coletas tempestivas de informações de última hora e elaboração de
gráficos a partir de dados baseados em planilhas para geração de apresentações com
slides.
4.4 Lições Aprendidas
Entre as principais lições aprendidas com o processo, os responsáveis pela
implementação e vários dos que foram posteriormente envolvidos concordam que o
processo de comunicação do projeto deveria ter sido melhor considerado. Esclarecer os
objetivos e metas do projeto, além de informar às pessoas sobre o que vai acontecer,
pode ser crítico para a obtenção do apoio e engajamento necessários. As opiniões
coletadas mostraram que muitos dos problemas percebidos referiam-se a essa
comunicação entre a equipe de implementação, os gestores afetados e demais
envolvidos. Algumas expectativas erroneamente assumidas poderiam ter sido
minimizadas ou melhor explicadas pela equipe de implementação, evitando conflitos e
atrasos que o processo sofreu. Por exemplo, no caso do ambiente de software
centralizado de controle de projetos, ou na estratégia de uso de planilhas eletrônicas
123
vinculadas ou ainda na ferramenta de sistema de registro da demanda e dos projetos
(mais recente), várias pessoas esperavam mais facilidade nas operações de registro e de
acompanhamento da demanda até o final do projeto; outros, porém, viram facilidades
nessas ferramentas, mas esperavam menos entraves nos processos de apresentação,
defesa e aprovação das demandas e projetos.
A definição mais clara do escopo do projeto, e da própria atuação do PMO no
conjunto de projetos da área, é fundamental para se obter esse nível adequado de
comunicações sobre os objetivos do PMO. Com essa definição pode-se chegar a uma
melhor programação de prazos, recursos necessários e custos envolvidos, além de
permitir a definição dos parâmetros de medição de resultados do projeto (métricas).
Essa definição de escopo, porém, não é completa sem uma fase anterior, de análise da
situação atual da área com relação ao gerenciamento de projetos (nível de maturidade
em gerenciamento de projetos), definição da estrutura de PMO que se melhor atende à
organização (a área considerada ou mesmo a Empresa) e comprometimento da
Administração para com as mudanças culturais que estão por vir, ao implementar-se um
PMO. (CRAWFORD, 2002, p.109). Sobre mudanças culturais, Englund, Graham e
Dinsmore (2003) também citam que as pessoas que tiveram dificuldades na
implementação de escritórios de projetos geralmente concluem que deveriam ter
adotado a abordagem de gerenciamento de mudança desde o início. Ou seja, eles
geralmente começaram por concentrar-se nas funções do escritório em si, ao invés de
concentrar-se no processo de mudança necessário para implementar tal escritório. Esses
autores lembram também que “as falhas na implementação do escritório de projetos
geralmente originam-se de uma combinação de fatores como falha de suporte da alta
administração, subestimativa do escopo de mudança organizacional necessária, falta de
metodologia para o gerenciamento de projetos e gerenciamento inadequado do processo
124
de mudança” (ENGLUND; GRAHAM; DINSMORE, 2003).
Deveria fazer parte da estratégia de implementação do PMO também uma
definição mais clara de papéis e responsabilidades que os membros do PMO teriam a
desempenhar, pois em algumas ocasiões não ficava claro quem deveria fazer o quê.
Ter processos mais claramente definidos também é algo com que uma
organização que pretenda ter um PMO deveria se preocupar desde o início dos trabalhos
de definição dessa estrutura.
Com relação à organização da área, ainda permanece uma questão a ser
discutida, em relação à estrutura – se matricial ou mista – e à composição dessa
estrutura em termos de requisitos para cada função. A dificuldade para essa definição
parece comum a algumas áreas consultadas em outras empresas, onde normalmente se
conduz tanto operações quanto projetos. Parte do problema pareceu estar encaminhado
para uma solução em breve, devido à descoberta (pelo menos entre os analistas de
sistemas) de pessoas com tendência ou interesse para assumir a função de gerente de
projetos, o que certamente deve facilitar a organização de equipes chave. Os demais
podem trazer o benefício de se saber, de antemão, onde estão as melhores capacidades
de execução das tarefas mais comuns no ambiente de tecnologia da informação.
Em relação à padronização da documentação de projetos, essa é uma
recomendação amplamente mencionada nas referências consultadas. Notamos, durante a
pesquisa e em encontros informais com o pessoal da área estudada, que a importância
mais acentuada recairia sobre os cronogramas e os documentos de definição dos
projetos. Para essas definições de projetos, eram preenchidos campos de planilhas
eletrônicas, na primeira versão, e agora, na versão mais recente do sistema de controle
de demanda, preenchem-se folhas de entrada de dados para um sistema de colaboração e
documentação. Em termos de documentos para apresentações de resultados, o padrão na
125
Empresa é mesmo um software de geração de “slides eletrônicos”, o que torna
desnecessário despender tempo em criação de documentos alternativos e que requeiram
ainda outro software para sua edição, impressão e exibição em salas de reunião. O
restante da documentação completa, sugerida na literatura, vários entrevistados
consideraram de menor importância no momento ou que tornaria necessário ter-se
especialistas em várias áreas ao mesmo tempo.
Igualmente importante também é a consideração da capacitação técnica e
administrativa, no assunto Gerenciamento de Projetos, de todos os envolvidos na
estruturação do gerenciamento de projetos de uma organização:
• equipe do PMO: essa equipe deveria, preferencialmente, possuir experiência
prévia ou receber capacitação em conhecimentos e técnicas de administração
geral (documentação, organização, apresentação de relatórios e
procedimentos administrativos da empresa) e gerenciamento de projetos
propriamente dito (domínio mínimo das técnicas de análise, planejamento,
programação, acompanhamento e controle de projetos, relacionamento com
fornecedores e prestadores de serviços); além disso, é recomendável que
esses profissionais sejam dotados de habilidades sociais, essenciais para o
relacionamento com as pessoas integrantes de equipes de projetos, gerentes
de projetos, gestores da área – detentores dos recursos comuns – e
intervenientes em geral;
• profissionais candidatos a gerentes de projetos: tradicionalmente escolhidos
entre os mais tecnicamente competentes, esses profissionais nem sempre
passaram pela formação mínima ou mesmo experiência necessárias para o
gerenciamento de pessoas, planejamento e condução de atividades,
requeridas do gerente de projeto; algumas atividades a serem desenvolvidas
126
podem também requerer conhecimentos específicos para o gerenciamento
dos projetos, como análise de viabilidade técnica, econômica e financeira,
projeção e controle de custos, gerenciamento de riscos, gerenciamento de
aquisições e contratações, etc., previstas no currículo de formação de
especialistas em gerenciamento de projetos.
• integrantes de equipes de projetos: quando não desempenham funções de
coordenação ou liderança nos projetos, esses profissionais devem, pelo
menos, entender os processos e razões pelos quais os controles existem e
como devem exercê-los de maneira eficaz; um mínimo de instrução em
relação à gerenciamento de riscos também auxiliaria na pró-atividade em
relação a manterem gestores e gerentes de projetos ao par de situações
potencialmente prejudiciais aos projetos;
• clientes dos projetos: no caso da área pesquisada, são os usuários das
soluções geradas pelos projetos e seus gestores, incluindo executivos;
• gestores diretamente envolvidos nos projetos e demais possíveis
intervenientes
18
: sem o objetivo de impingir a esses os detalhes de uma área
de atuação que não lhes compete, o treinamento em gerenciamento de
projetos (ainda que apenas em nível básico) para essas pessoas poderia trazer
o benefício de entenderem como o processo funciona, desde a análise de um
pedido, sua validação e aprovação, execução e encerramento. Com isso,
esses intervenientes conheceriam a importância de seu apoio para o bom
andamento dos projetos e consecução dos objetivos setoriais e corporativos
que esses projetos visam atender, além de entenderem os principais pontos
de atenção no processo, em que possam colaborar no gerenciamento de
18
Adaptado do termo “stakeholders”, usualmente encontrado na literatura sobre gerenciamento de
projetos.
127
riscos dos projetos.
•
Não necessariamente o processo trouxe melhoria imediata ou em curto prazo em
termos de cumprimento de datas de entrega e custos (a opinião quanto a ter-se
conseguido esses objetivos é contestada por alguns e defendida por outros).
4.5 Comparação dos resultados: Empresa x Literatura
Conforme se viu na revisão da literatura, ainda são poucas as pesquisas no Brasil
que permitam comparar estratégias das empresas em relação ao gerenciamento de
projetos. Alguns pontos importantes da pesquisa do PMI-RJ (PINTO, 2005), porém,
merecem comentários, pois encontram paralelos próximos na área estudada:
• A maioria das empresas participantes do estudo é de T.I./Telecomunicações,
o que garante certa familiaridade com a área pesquisada; outras consultas em
listas de discussão, fóruns, páginas internet e eventos especializados
confirmam essa freqüência;
• Nas empresas do estudo, mais de 70% mencionam pouca ou nenhuma
resistência ao tema Gerência de Projetos; no que se pode perceber dos
gestores entrevistados, a Empresa também tem essa característica, e poucos
são os que apresentam alguma resistência (no estudo do PMI-RJ, nas
empresas de T.I./Telecomunicações, essa resistência é inversamente
proporcional ao valor dos projetos).
• Em relação à importância com que a alta administração trata o assunto, mais
de 70% dos respondentes da pesquisa do PMI-RJ disseram dar “alta ou
altíssima” importância; na empresa pesquisada, apesar de haver o apoio
Formatado: Com marcadores
+ Nível: 1 + Alinhado em:
1,25 cm + Tabulação após:
1,89 cm + Recuar em: 1,89
cm
128
declarado de alguns executivos, apesar de, em alguns casos, ter-se percebido
uma certa falta de apoio executivo e delegações de poderes aos gerentes de
projeto quanto à autonomia necessária sobre os assuntos e problemas
referentes aos projetos sob sua responsabilidade;
• Em termos de reconhecimento do Gerenciamento de Projetos, porém, a
maioria das empresas o consideram como profissão (56%); para algumas,
atividade em tempo parcial (35%) e apenas 9% mencionaram nem ter a
função de Gerentes de Projeto em seus quadros funcionais; destaca-se no
estudo, porém, que 67% das empresas declaram que seus Gerentes de Projeto
são profissionais subcontratados (“terceirizados”); na empresa pesquisada
nota-se a participação dos gerentes de projetos nas mesmas três modalidades
de contratação (tempo integral, parcial ou subcontratados).
• O PMO da empresa pesquisada parece ter tido sua estrutura instalada como
identificado nas empresas respondentes da pesquisa do PMI-RJ, pois 41%
das empresas descrevem a estrutura de seus PMOs como “matricial fraca”
(28% disseram ter estruturas tradicionais e departamentalizadas, ou
“funcionais puras”, como o PMBOK descreve (PMI, 2004)). Isso pode ter
sido a causa mais provável para uma série de dificuldades, como o insucesso
de alguns projetos da T.I. da empresa, pois nessas estruturas existe uma
prevalência grande de autoridade dos gestores funcionais sobre os gerentes
de projetos e pouca autonomia desses quanto aos recursos necessários;
assim, esses recursos tornam-se, com certa freqüência, críticos para o
sucesso desses projetos;
• Dessas empresas do estudo, 55% disseram praticar o gerenciamento de
portfólio com algum método, sendo que nas de T.I./Telecomunicações esse
129
número é de 66%. É o que fez a área de T.I. da empresa pesquisada, com a
definição de pelo menos um processo para controlar as demandas de áreas
usuárias por serviços e produtos de T.I.;
• Finalmente, o fato da T.I. da Empresa ainda estar com seu PMO em
implementação é algo condizente com o que se viu no mercado: no estudo,
realizado entre setembro e novembro de 2004, mais de 57% das empresas
estavam com o PMO em implementação ou pretendiam implementar um em
até o ano seguinte.
•
A literatura recomenda amplamente que se estabeleça, de alguma forma, vínculo
forte entre o ambiente de projetos e o planejamento estratégico das empresas
(CARVALHO, RABECHINI JR., 2005, p. 17; CRAWFORD, 2004; PRADO, 2004;
PRADO, 2005; TURNER, 1993;).
Nesta pesquisa percebeu-se que ainda existe necessidade da área de T.I. estudada
trabalhar essa questão. Existe a dificuldade da direção da área e seus gestores de serem
envolvidos mais imediatamente na definição de planos estratégicos e metas das demais
áreas da empresa. A falta desse envolvimento com freqüência gera dificuldades na
obtenção dos recursos necessários para os projetos de T.I. atenderem às demandas das
demais áreas, além de dificultar a priorização da alocação e uso desses recursos.
Também a justificativa do volume de recursos necessários à manutenção do ambiente
instalado enfrenta resistência por parte da alta administração.
O principal objetivo desse alinhamento estratégico seria que, considerando o
ambiente de incerteza e risco em que se inserem os projetos (TURNER, 1993), os
objetivos de negócio definidos pela alta administração pudessem ser atendidos de
maneira mais satisfatória, pelo uso mais racional dos recursos destinados aos projetos
Formatado: Com marcadores
+ Nível: 1 + Alinhado em:
1,25 cm + Tabulação após:
1,89 cm + Recuar em: 1,89
cm
130
(sejam esses recursos humanos, materiais, financeiros ou mesmo intangíveis).
Para essa organização dos projetos e recursos necessários, considerando-se os
objetivos estratégicos da empresa, recomenda-se que atenção especial seja dedicada
pela equipe encarregada de gerenciar o ambiente de projetos a pontos de conflitos e
dificuldades que podem surgir nas equipes e que vão comprometer o resultado dos
projetos (ARCHIBALD, 1976, cap. 4 e 5; GHASEMZADEH; ARCHER, 2000;
PRADO, 2004; TURNER, 1993).
No ambiente pesquisado, um possível descolamento entre o planejamento
estratégico corporativo e o planejamento dos objetivos e metas de T.I. pode ter levado
dificuldades quanto à priorização dos projetos, obtenção dos recursos necessários,
integração entre os projetos e o próprio desenvolvimento organizacional e sistemas de
gestão que pudessem ampliar a eficiência e eficácia com que são conduzidos os projetos
de T.I. Em face de urgências verificadas durante a pesquisa, notou-se que as várias
gerências da área tinham dificuldades em estabelecer um plano integrado de ataque a
essas dificuldades, e o comportamento dos funcionários em geral foi bastante
prejudicado, com demonstrações de frustação e ansiedade.
O processo de organização do ambiente de projetos poderia ser facilitado com a
aplicação dos processos de várias propostas de modelos e melhores práticas para o
gerenciamento de projetos como, citam por exemplo, Crawford (2002), Grundy (1998),
Prado (2005), Turner (1993) e Hutchinson (2002), entre outros, e que o PMI reuniu em
seu PMBOK (PMI, 2004).
As condições relatadas anteriormente não facilitaram a elaboração de estratégias
da área de T.I. para a definição e aplicação dessas práticas. Pequenos progressos
puderam ser verificados em relação à visibilidade do portfólio de projetos, porém a
confiabilidade das informações foi questionada por algumas pessoas. Capacitação em
131
gerenciamento de projetos é também outro ponto de atenção fortemente verificado.
132
5 CONCLUSÕES
Conforme a maioria da literatura indica, a área de T.I. envolvida nesta pesquisa
parece sofrer das mesmas necessidades e deficiências de suas correspondentes em
outras empresas, como está amplamente divulgado em notícias do setor, na mídia
impressa ou na Internet.
Inicialmente, o trabalho de se reunir para o projeto o corpo gerencial da empresa,
com apoio dos principais profissionais (líderes e outros mais antigos, que contam com a
confiança dos demais), é importante para o sucesso do projeto. O que se deve ter em
mente é que implementar um PMO pode (e certamente o fará) implicar mudanças (por
vezes radicais) na forma de gerenciamento da empresa, e é importante ter-se
conhecimento dessas implicações para o dia-a-dia da empresa (PRADO, 2005).
A seguir, se o PMO será uma estrutura do ambiente de Controles Internos, é
necessário dizer-se qual será o nível de controle que o PMO exercerá, o que se define
após o processo de planejamento.
Outro dos principais fatores identificados que podem determinar o sucesso da
implementação do PMO é a capacitação dos profissionais envolvidos na mudança. Não
apenas os gerentes de projetos (ou candidatos a receber essa atribuição), mas os demais
participantes de projetos (gestores funcionais da área, executivos e clientes dos projetos)
deveriam receber alguma instrução básica sobre Gerenciamento de Projetos.
Os executivos e alta gerência compreendem o principal público interessado nos
resultados dos projetos em uma organização, e sua importância e apoio constituem fator
crítico de sucesso na implementação do PMO. Assim, é importante que esses gestores
entendam o que se pode obter da estrutura em termos de informações a cerca das
133
atividades desenvolvidas em suas áreas de responsabilidade. Igualmente importante é
que saibam, também, o que se espera deles como patrocinadores, autorizadores e
aprovadores dos projetos. De posse desse entendimento, esses executivos terão
melhores condições para decidir sobre os investimentos necessários à consecução de
seus objetivos de negócio, formalmente estabelecidos com a alta administração em seus
planos de ação.
Para os gerentes de projetos, atuais e candidatos, bem como para os demais
profissionais participantes dos projetos, uma formação nas técnicas de gerenciamento de
projetos é essencial. Isso é naturalmente mais evidente, uma vez que são eles os
responsáveis finais pela execução dos projetos e apresentação de seus resultados aos
gestores, porém, nem sempre é considerado importante.
Os gestores tendem a crer que excelentes técnicos são também excelentes
gerentes de projetos, e isso nem sempre é verdade, pois as habilidades pessoais
necessárias a cada atividade são bastante diferentes (KERZNER, 1997, CAP. 12;
DISNSMORE, 1990, P. 40, 54-56; RABECHINI JR., 2005, cap. 4). Assim, além do
treinamento tradicionalmente fornecido aos que vão gerenciar projetos, como
identificação de requisitos, planejamento de atividades e elaboração de cronogramas e
controles de custos, é necessário que esses profissionais sejam orientados nas
habilidades lógicas (solução de problemas) e sociais (relacionamentos), necessárias ao
cumprimento das atividades técnicas.
Especial atenção deveria ser dada no que se refere a definir os papéis e
responsabilidades de todos no processo de implementação de uma estrutura formal para
gerenciamento dos projetos. Deve-se ter em mente que implementar o PMO é também
um projeto e, como tal, este pode vir a ter a composição de sua equipe alterada ao longo
do trabalho, tanto quanto sua equipe pode ser alterada ao longo da vida do PMO,
134
conforme suas funções são expandidas ou ajustas à necessidade da empresa em dado
instante. Desta forma, são válidas também para a implementação e futura gestão do
PMO as recomendações do Cap. 9 do PMBOK (PMI, 2004, p. 199), que prevê a criação
do Plano de Gestão de Recursos Humanos, onde se estabelece os procedimentos para a
composição do projeto (nesse caso, o PMO): como se define os recursos necessários,
como obter essa equipe, capacitá-la e acompanhar e comunicar o desempenho.
Dada a importância da Gestão dos Recursos Humanos no projeto de
implementação (e posteriormente na manutenção) do PMO, identifica-se no estudo
oportunidades de pesquisas futuras a respeito do aspecto humano da implementação do
PMO, a fim de se evitar o estresse causado pelas altas expectativas em relação aos
resultados e expectativas não realistas de profundidade com que o assunto foi tratado.
Tecnicamente, porém, vários pontos ainda poderiam ser explorados em
pesquisas subseqüentes, dentre os quais citamos os que mais foram mencionados:
treinamento (desde a referência a manuais, procedimentos e outras formas documentais
até a instrução detalhada sobre o uso de matérial) e comunicações (a respeito do projeto,
planejamento inicial, ganhos obtidos até o presente, etc.).
Esperamos, portanto, com o trabalho apresentado, ter apresentado informações
suficientes para a reflexão a respeito de pontos a considerar numa implementação de
PMO, e que essas informações possam contribuir com implementações futuras.
135
REFERÊNCIAS
ARCHIBALD, R. D. Managing High-technology Programs and Projects. Nova
Iorque: John Wiley & Sons, 1976.
______ Managing High-tech Projects. 3 ed., Hoboken (EUA): John Wiley & Sons,
2003.
______ State of the Art of Project Management: 2003b, partes 1-1, 2-1. Disponível
em <http://www.pmforum.org/pmwt/archives/pmwt04/papers04-01more.htm>,
acessado em 18/out/2004.
BARBER, E. Benchmarking the Management of Projects: A Review of Current
Thinking. International Journal of Project Management, v. 22, n. 4, 2004, p. 301-
307.
BEER, M. (org.) Gerenciando Mudança e Transição/ trad. Managing Change and
Transition. Rio de Janeiro: Record, 2002.
BERNSTEIN, S. Project Offices in Practice. Project Management Journal,
Richmond, EUA, v. 31, n. 4, 2000, p. 4-6.
BLOCK, T. R.; FRAME, J. D. The Project Office – A Key to Managing Projects
Effectively. Menlo Park: Crisp Publications, 1998.
BOLLES, D. Building Project Management Centers of Excellence. Nova Iorque
(EUA): AMACOM Books, 2002.
CARVALHO, M. M.; RABECHINI JR., R.; PESSÔA, M. S. de P.; LAURINDO, F. J.
B. Equivalência e Completeza: Análise de Dois Modelos de Maturidade em Gestão de
Projetos. RAE-Revista de Administração de Empresas, São Paulo: USP, 2005, v. 40,
n. 3, p.289-300, jul/ago/set.2005.
CHAMON, M. A. Análise de Dados em Ciências Sociais. In: SOUZA, C. M.;
CHAMON, E. M. Q. de O. (Org.). Estudos Interdisciplinares em Ciências Sociais.
Taubaté, 2005.
GLEN, Paul. “Making Change”. CIO Magazine, 2005. Disponível em
http://www.cio.com, acessado em 15.jul.2004.
CLELAND, D. I.; IRELAND, L. R. Gerência de Projetos. Rio de Janeiro: Reichmann
136
& Affonso, 2002, p. 60-61.
______. Project Management – Strategic Design and Implementation. Nova Iorque:
McGraw Hill, 2002, p. 3-4.
CLELAND, D. I.; KING, W. R. Project Management Handbook. Hoboken (EUA):
John Wiley & Sons. 2 ed, 1988.
______ Systems Analysis and Project Management. Nova Iorque (EUA): McGraw-
Hill Book Company. 1968, p. 10-11.
CRAWFORD, J. K. The Strategic Project Office – A Guide to Improve
Organizational Performance. New York, NY: Marcel Deker, 2002, cap. 1.
CRAWFORD, J. K.; PENNYPACKER, J. S. Put an End to Project Mismanagement –
Get your IT projects done on time and on budget. OPTIMIZEMAG, 2002. Disponível
em <http://www.optimizemag.com>, acessado em 30.jun.2005.
CRAWFORD, L. Supporting Delivery Capability: The Many Faces of Project Support
in Organisations. In: INTERNATIONAL PROJECT MANAGEMENT
ASSOCIATION (IPMA) World Congress, 18., 2004, Budapest. Anais... Budapest:
IPMA, 2004. 1 CD-ROM.
______ Senior management perceptions of project management competence.
International Journal of Project Management, v. 23, n. 1, 2005, p. 7-16.
DAFT, R. L. Administração. Trad. Morales, F. G. Rio de Janeiro: LTC, 1999.
______. Organizações – Teoria e Projetos. São Paulo: Pioneira Thomson Learning,
2002.
DAI, C. X.; WELLS, W. G. An exploration of project management office features and
their relationship to project performance. International Journal of Project
Management, v. 22, n. 7, 2004, p. 523-532.
DAVIS, S. M.; LAWRENCE , P. R. Problems of Matrix Organizations. Harvard
Business Review, maio.1978, p.
DE REYCK, B. ; GRUSHKA-COCKAYNE, Y.; LOCKETT, M.; CALDERINI, S. R.;
MOURA, M.; SLOPPER, A. The impact of project portfolio management on
information technology projects. International Journal of Project Management. V.
23, n. 7, 2005, p. 524-537.
137
DINSMORE. P. C. Human Factors in Project Management. Nova Iorque:
AMACOM, 1990.
DINSMORE, P. C.; SILVEIRA NETO, F. H. Gerenciamento de Projetos – Como
Gerenciar seu Projeto com Qualidade, Dentro do Prazo e Custos Previstos. Rio de
Janeiro: Qualitymark, 2004, p. 30-31.
ENGLUND, R. L.; GRAHAM, R. J.; DINSMORE, P. C. Creating the Project Office
– A Manager's Guide to Leading Organizational Change. San Francisco, CA: Joseey-
Bass, 2003.
McELROY, W. Implementing Strategic Change Through Projects. International
Journal of Project Management, v. 14, n. 6, 1996, p. 325-329.
VISITACION, M. The Forrester Wave: Project Portfolio Management, Q1 2006.
FORRESTER RESEARCH, INC., 2006. Disponível em
http://www3.ca.com/solutions/collateral.aspx?CID=84989&ID=, acessado em
29.mar.2006.
FRAME, J. D. Managing projects in organizations – How to Make the Best Use of
Time, Techiques and People. São Francisco (EUA): Jossey-Bass Publishers, 1987.
LIGHT, M.; STANG, D. B. Magic Quadrant for IT Project and Portfolio Management.
GARTNER INSTITUTE, 2005, disponível em http://www.gartner.com.
GHASEMZADEH, F.; ARCHER, N.P. Project portfolio selection through decision
support. Decision Support Systems, n. 29, 2000, p. 73–88.
GIL, A. C. Métodos e Técnicas de Pesquisa Social. São Paulo: Atlas, 1998.
GLEN, Paul. “Making Change”. Projects@Work, 2005. Disponível em
http://www.projectsatwork.com/article.cfm?ID=225767&authenticated=1, acessado em
18.jul.2005.
GRAY, R. Organizational climate and project success. International Journal of
Project Management, v. 19, n. 2, 2001, p. 103-109.
GRUNDY, T. Strategy Implementation and Project Management. International
Journal of Project Management, v. 16, n. 1, 1998, p. 43-50.
HENRIE, M; SOUZA-POZA, A. Project Management: A Cultural Literary Review.
138
Project Management Journal, v. 36, n.1, 2005, p. 5-14.
HILL, G. M. Evolving the Project Management Office: A Competency Continuum.
Information Systems Management, v. 21, n. 4, 2004, p. 45-51.
HOBBS, B.; AUBRY, M. A Realistic Portrait of PMOs: The Results of an Empirical
Investigation. In: PMI Global Congress 2005 – North America; 2005, Toronto, CA.
Anais... Toronto: PMI, 2005.
HOUAISS, A. (Ed.). Dicionário Eletrônico da Língua Portuguesa. São Paulo:
Objetiva, v.1.0.5a, nov.2002. CD-ROM.
HUTCHINSON. The Hutchinson Encyclopedia 2002. 8 ed., Hutchinson (ed.), Helicon
Publishing: Oxfordshire (G.B.), 1988. CD-ROM.
IVES, MARK. Identifying the Contextual Elements of Project Management within
Organizations and their Impact on Project Success. Project Management Journal,
v.36, n.1, 2005, p. 51-50.
JOHNSTON, R. Project Offices Done Right. PMI-PMO Special Interest Group, in:
Insight, Fall, 2001. Disponível em <http://www.pmi-pmosig.org/Newsletters.htm>,
acessado em 22.ago.2004.
KAST, F. E.; ROSENZWEIG, J. E. Science, Technology and Management in
Proceedings of the National Advanced-Technology Conference. 4 a 7.set; 1962,
Seattle (EUA) in CLELAND, D. I.; KING, W. R. Systems Analysis and Project
Management. Nova Iorque (EUA): McGraw-Hill Book Company. 1968, p. 135.
KENDALL, G. I.; ROLLINS, S. C. Advanced Project Portfolio Management and
the PMO – Multiplying ROI at Warp Speed. Boca Raton: J. Ross Publishing e
International Institute for Learning, 2003.
KERZNER, H. In Search of Excellence in Project Management: Successful Practices
in High Performance Organizations. Nova Iorque: Van Nostrand Reinhold, 1997.
______. Project Management – A Systems Approach to Planning, Scheduling, and
Controlling. 7 ed., Nova Iorque: John Wiley & Sons, 2001.
______. Gerenciamento de Projetos – As Melhores Práticas / trad. Borges, M. A.V.;
Klippel, M.; Borba, G. S. de. Porto alegre: Bookman, 2002.
______. Strategic Planning for a Project Office. Project Management Journal, v. 34,
139
n. 2, p. 13-25, jun. 2003.
KOTTER, J. P. Como Liderar a Mudança: Por que os esforços de transformação
fracassam. In: RODRIGUEZ, M. V. R. (Org.) Gestão da Mudança. Rio de Janeiro:
Elsevier, 2005, p. 9-25.
KUPRENAS, J. A. Implementation and performance of a matrix organization structure.
International Journal of Project Management. v. 21, n. 1, 2003, p. 51-62.
LAKATOS, E. M.; MARCONI, M. A. Técnicas de Pesquisa. São Paulo, Ed. Atlas.
5.ed, 2002.
LAURINDO, F. J. B.; CARVALHO, M. M.; SHIMIZU, T. Information Technology
Strategy Alignment: Brazilian Cases. In: KANGAS, Kale (Org.). Business Strategies
for Information Techonolofy Management. Hershey: Idea Group, 2003, p. 186-199.
LYCETT, M.; RASSAU, A.; DANSON, J. Programme management: a critical review.
International Journal of Project Management, v. 22, n. 4, 2004, p. 289-299.
MARTINS, G. de A. Estudo de Caso: Uma Estratégia de Pesquisa. São Paulo: Ed.
Atlas, 2006.
MEREDITH, J. R., MANTEL, S. J. Jr. Project Management: A Managerial Approach.
4 ed., Hoboken (EUA): John Wiley & Sons, 2000.
MILOSEVIC, D.; PATANAKUL, P. Standardized project management may increase
development projects success. International Journal of Project Management, v. 23,
n. 3, 2005, p. 181-192.
MIRANDA, E. Running the Successful Hi-Tech Project Office. Artech: Nova Iorque,
2003, cap. 3.
MORRIS, P. W. G. Science, objective knowledge, and the theory of project
management. 2004. Disponível em
http://www.bartlett.ucl.ac.uk/research/management/mgmt_papers.htm, acessado em
15.jan.2005.
MORRIS, P.; JAMIESON, A. Translating Corporate Strategy into Project Strategy.
Project Management Institute: Newton Square (EUA), 2004.
MULLALY, M. The Effective Project Management Office: Strategies for Building,
Selling & Setting Up PMOs. Disponível em <http://www.gantthead.com>, acessado em
140
12.dez.2004.
______ Defining the Role of the PMO: The Quest for Identity, 2002. Disponível em
<http://www.gantthead.com>, acessado em 18.dez.2004.
NEW ECONOMICS FOUNDATION (NEF). Entrepreneurial Mentoring: A Key to
Business Success. 2005. Disponível em <http://www.neweconomics.org>, acessado em
22.jun.2005.
PARKER, S. K.; SKITMORE, M. Project Management turnover: causes and effects on
project performance. International Journal of Project Management, v. 23, n. 3, 2005,
p. 205-214.
PARTINGTON, D. The project management of organizational change. International
Journal of Project Management, v. 14, n. 1, 1996, p. 13-21.
PINTO, A. (Org.) Benchmarking em Gerenciamento de Projetos Brasil: Relatório 2004.
Rio de Janeiro: Ed. SENAI, 2005.
PRADO, D. dos S. Gerenciamento de Programas e Projetos nas Organizações. Nova
Lima: INDG, 3. ed, 2004.
PROJECT MANAGEMENT INSTITUTE (PMI). Um Guia do Conjunto de
Conhecimentos em Gerenciamento de Projetos. 3 ed., Newtown Square: Project
Management Institute, 2004.
______. Member Community Surveys. 2005. Acessível (para filiados) em
http://member.pmi.bluestep.net/shared/survey/surveys.jsp?_event=view&_id=200001_
U126961__137919.
QUELHAS, O.; BARCAUI, A. B. Perfil de Escritórios de Gerenciamento de Projetos
em Organizações Atuantes no Brasil. Rio de Janeiro: UFF. 2003.
RABECHINI JR., R. Competências e Maturidade em Gerenciamento de Projetos:
Uma Perspectiva Estruturada. São Paulo, 2003. 286p. Tese (Doutorado) – Escola
Politécnica da Universidade de São Paulo. Departamento de Produção.
______. O Gerente de Projetos na Empresa. São Paulo: Ed. Atlas, 2005.
RIBEIRO, M. J. F. X. Metodologia da Pesquisa Científica, Taubaté: UNITAU, 2004.
RUDIO, F. V. Introdução ao Projeto de Pesquisa. 31 ed., Petrópolis:Vozes, 1986.
141
SALGUES, L. J .V.; DIAS, S. M. R. C.; MORAES, I. C. Processos de Mentoria:
Existência de Múltiplos Mentores e as Características de uma Relação de Mentoria. In:
XXVIII ENCONTRO DA ANPAD-Associação Nacional de Pós-Graduação e
Pesquisa em Administração. 28.; 2004, Curitiba. Anais... Curitiba: ANPAD, 2004.
Disponível em <http://www.anpad.org.br/frame_enanpad2004.html>, acessado em
15.mar.2005.
SANTOSUS, M. Office Discipline: Why do You Need a Project Management Office.
CIO MAGAZINE. Disponível em < http://www.cio.com/archive/070103/office.html>,
acessada em 12.maio.2004.
SATO, C. E. Y.; DERGINT, D. E. A.; HATAKEYAMA, K. A Utilização do Escritório
de Projetos como Instrumento para Melhoria da Produtividade Sistêmica das
Organizações. In: SEMANA DE TECNOLOGIA: TECNOLOGIA PARA QUEM E
PARA QUÊ? 2003, Curitiba. Disponível em
< http://www.ppgte.cefetpr.br/semanatecnologia/>, acessado em 15/ago/2004.
SERVIÇO NACIONAL DA INDÚSTRIA (SENAI). Benchmarking em
Gerenciamento de Projetos Brasil: Relatório 2004. Pinto, A. (org.). Rio de Janeiro:
Ed. SENAI, 2005.
SHEA, Gordon F. Mentoring: Como desenvolver o comportamento bem sucedido do
mentor. Rio de Janeiro: Qualitymark, 2001.
SIMSEK, Z. Sample surveys via electronic mail: a comprehensive perspective. RAE-
Revista de Administração de Empresas, São Paulo: USP, 1999, v. 39, n. 1, p.77-83.
SOFIAN, A. Project Success in Relation with Organizational Roles and
Capabilities and Project Manager’s Skills and Capabilities. Project Management
Institute Survey Results, 2003. Disponível em
http://www.pmi.org/prod/groups/public/documents/info/PP_Sofian.pdf, acessado em
15.jun.2005.
STANLEIGH, M. The Impact of Implementing a Project Management Office.
Project Management Institute Survey Results, 2005. Disponível em
http://www.pmi.org/prod/groups/public/documents/info/pp_surveyresults.asp, acessado
em 25.maio.2005.
STUCKENBRUCK, L. (Ed.) The Implementation of the Project Management.
PROJECT MANAGEMENT INSTITUTE: Addison-Wesley, 1996, p. 13-14.
THOMAS, J.; DELISLE, C.; JUGDEV, K.; et al.. Selling project management to
senior executives: what's the hook?. In: SLEVIN, D.P.; CLELAND, D.I.; PINTO,
142
J.K. (ed.). The frontiers of project management research. Newtown Square: Project
Management Institute; 2002. p. 309 a 328.
TURNER, J. R. The Handbook of Project-based Management: Improving the
processes for achieving strategic objectives. Berkshire: MacGraw-Hill, 1993.
TURNER, J. R.; KEEGAN, A. The Versatile Project-based Organization: Governance
and Operational Control. European Management Journal, v. 17, n. 3, 1999, p. 296–
309.
VALERIANO, D. L. Gerenciamento em Projetos. São Paulo: Makron Books, 1998,
cap. 4.
______. Gerenciamento Estratégico e Administração por Projetos. São Paulo:
Makron Books, 2001, p. 108.
______. Moderno Gerenciamento de Projetos. São Paulo: Prentice Hall, 2005, cap. 5.
VERZUH, E. MBA Compacto. Gerenciamento de Projetos / trad. André de L. Cardoso.
Rio de Janeiro: Campus, 2000.
WARE, L. C. BEST PRACTICES FOR PROJECT MANAGEMENT OFFICES.
2003. In: CIO.com, 1994-2006. Portal na internet publicado por CXO Media Inc. e
dirigido às necessidades de informação dos CIOs (Chief Information Officers – diretores
e executivos de Tecnologia da Informação) e outros executivos. Disponível em
http://www2.cio.com/research/surveyreport.cfm?id=58, acessado em 25.maio.2005.
YIN, R. K. Estudo de Caso: Planejamento e Métodos / trad. Daniel Grassi. 2 ed., Porto
Alegre: Bookman, 2001.
Formatado: Fonte: Negrito
143
ANEXO A – TERMO DE CONSENTIMENTO PARA A PESQUISA
O “Termo de Consentimento Livre e Esclarecido” é um requisito da
Universidade em pesquisas com pessoas, e visa apresentar o trabalho e as condições em
que as respostas serão mantidas, além de oferecer aos participantes a liberdade de
reverem, ou mesmo retirarem suas opiniões.
TERMO DE CONSENTIMENTO LIVRE E ESCLARECIDO
Esta pesquisa está sendo realizada por aluno do Programa de Pós-Graduação em Administração
(PPGA) da Universidade de Taubaté. O tema da pesquisa é a implementação de Escritórios de
Gerenciamento de Projetos (PMO). Seu objetivo é levantar informações sobre o processo de
implementação de um PMO em uma área desta empresa. Os resultados dessa pesquisa serão utilizados
apenas para fins acadêmicos.
Seguindo os preceitos éticos, informamos que sua participação será absolutamente sigilosa, não
constando seu nome ou qualquer outro dado referente à sua pessoa que possa identificá-lo no relatório
final ou em qualquer publicação posterior sobre esta pesquisa. Pela natureza da pesquisa, sua participação
não acarretará em qualquer dano a sua pessoa.
Você tem a total liberdade para recusar sua participação, assim como solicitar a exclusão de seus
dados, retirando seu consentimento sem qualquer penalidade ou prejuízo, quando assim o desejar.
Agradeço sua participação, enfatizando que a mesma em muito contribui para a formação e para
a construção de um conhecimento atual nesta área.
Taubaté, maio de 2005.
__________________________________________________________
Prof. Dr. Marco Antonio Chamon
Orientador da Pesquisa
Tendo ciência das informações contidas neste Termo de Consentimento Livre e Esclarecido, eu
________________________________________________, portador do RG n
0
_________________
autorizo a utilização, nesta pesquisa, dos dados por mim fornecidos.
_______________________________ Taubaté, __ / __ / 2005.
Assinatura
144
ANEXO B – AUTORIZAÇÃO DO COMITÊ DE ÉTICA
145
ANEXO C – AUTORIZAÇÃO PARA TRABALHO EM CAMPO
146
APÊNDICE A – ROTEIRO PARA A ENTREVISTA
O roteiro para entrevista tem as seguintes questões chave aos entrevistados:
Antes da implementação de processos e padrões para gerenciamento de projetos na área,
qual era, em sua opinião, a forma de condução dos projetos de T.I.?
Quais foram os fatores motivadores e principais objetivos para a implementação do
gerenciamento de projetos na área, àquela época?
Como transcorreu, na sua visão, a implementação do gerenciamento de projetos na
área?
O que você considera que tenha facilitado ou dificultado o processo de implementação
do PMO?
O que você acha que a organização (área de T.I.) ganhou ou perdeu com a
implementação?
Qual era seu conhecimento sobre projetos e gerenciamento de projetos, antes da
implementação do PMO?
Como você classificaria seu conhecimento sobre esses assuntos hoje? Houve influência
na forma como conduz seus projetos?
No caso de ter adquirido conhecimento a respeito, você atribui essa aquisição como
efeito positivo da implementação do PMO?
147
APÊNDICE B – MENTORIA
Com a crescente necessidade de profissionais para as estruturas “projetizadas”, o
local mais apropriado para se alocar esses profissionais é o PMO. uma das funções que
o PMO deveria assumir, mencionada por vários autores, é a de mentoria, ou orientação
profissional. Segundo a pesquisa das autoras Salgues, Dias e Moraes (2004), mentoria
não é um tema novo:
A expressão “mentor” é derivada da mitologia grega. Segundo Shea (2001),
tem sua origem na lendária guerra de Tróia, quando Odisseu, Rei de Ithaca,
foi para frente de batalha e conferiu os cuidados de sua família à figura do
escravo Mentor, que trabalhava como mestre e conselheiro de seu filho
Telêmaco. A função de Mentor não era apenas de tutelar Telêmaco, mas de
orientar e contribuir para melhor desenvolvê-lo e prepará-lo para que ele
pudesse enfrentar as responsabilidades que teria de assumir posteriormente.
É daí que a palavra Mentor passou a significar “orientador, conselheiro, amigo,
tutor, professor e homem sábio” (SHEA, 2001). Em gerenciamento de projetos,
mentoria é “prover aconselhamento e esclarecimento conceitual quando necessário” e
essa função pode ser provida para os gerentes de projetos do PMO ou de outras áreas, se
for escolha dessas áreas gerenciar os próprios projetos (CRAWFORD, 2002, p. 78).
Mas essa relação de parceria no trabalho depende do bom relacionamento entre
os mentores e as pessoas a quem elas atendem (LIANG et. al., 2002 apud Salgues, Dias
e Moraes).
Essa relação de parceira é importante devido às funções que o mentor
desempenha junto aos profissionais de projetos: aconselhamento de experiência, auxílio
na definição de visão dos projetos, orientação para o planejamento, guia para equipes de
projetos, facilitação ou negociação e suporte ,
Para isso, o mentor deveria ser um profissional experiente em competência no
gerenciamento de projetos, com forte capacidade de liderança e resolução de conflitos,
formação de equipes e capacidade de articulação política (CRAWFORD, 2002).
148
A diferença entre mentoria e coaching é que esses dois termos diferem na forma
e objetivos do acompanhamento da pessoa que se objetiva formar, capacitar ou de quem
se quer aprimorar conhecimentos e habilidades.
149
APÊNDICE C – FUNÇÕES MAIS COMUMS DE SUPORTE A
PROJETOS
Segundo Crawford (2002), são essas as principais funções desempenhadas pelo
PMO,
Documentação: o grupo de suporte a projetos desempenha um papel mais
“científico” no gerenciamento de projetos, com atribuições como orçamento,
estimativas de custos, confecção de cronogramas e WBS , identificação de caminhos
críticos nas redes de projetos, etc. A quantidade de informações que os projetos geram é
significativa e é essencial ao controle do projeto.
Controle de mudanças: as funções de suporte a projetos são críticas para o
controle de mudanças. Cada mudança deve ser documentada e minutas da comissão
controle de mudanças devem ser registradas e disseminadas. O PMO desempenha papel
chave na facilitação dessa tarefa dos gerentes de projetos, deixando-os mais livres para
as demais atividades dos projetos.
Repositório de projetos: suporte aos projetos inclui manter seus registros, com
toda a documentação e histórico, que servem de referência aos que assumem os
projetos, no caso de saída dos gerentes de projetos ou outros membros de equipes, e
àqueles que elaboram projetos novos.
Acompanhamento e relatórios: manter registro de problemas e itens de ação
também toma tempo dos gerentes de projetos. As informações de cada projeto são
resumidas para as áreas funcionais e posteriormente compõem painéis informativos para
os demais níveis de gestão. O PMO é responsável pelo “painel de controle” que contém
essas informações, de preferência em publicações sucintas, que mostram se os projetos,
150
no geral, estão em conformidade com os planos e, se não estiverem, como se pode
encontrar informações sobre os problemas que causam esses desvios. •
Gerenciamento de riscos: após a identificação dos riscos em cada projeto, o
PMO deve reunir esses riscos e as correspondentes ações, para garantir que essas sejam
executadas oportunamente. Como essa função pode requerer especialização no uso de
ferramentas e técnicas, os especialistas de riscos deveriam estar alocados no PMO, na
função de suporte a projetos.
Repositório de recursos: organizações de qualquer porte deveriam manter
registros de seus recursos, humanos e materiais, disponíveis aos projetos. O PMO,
especialmente no nível 3, pode agir como agenciador desses recursos entre os projetos e
as áreas funcionais, a fim de garantir que os recursos certos estejam alocados ao
projetos certos, na hora certa.
Acompanhamento de custos: organizações com mais maturidade em processos
de gerenciamento de projetos podem ter alterado seus sistemas contábeis para fornecer
informações reais de custos diretamente aos gerentes de projetos, através de software de
gerenciamento de projetos em uso. Contudo, essas alterações são dispendiosas e
complexas, devido à natureza desses sistemas, mas sem essa integração, qualquer
tentativa de avaliar custos correntes e futuros “é mera ilusão”, segundo Crawford. É
quando o PMO pode auxiliar aos gerentes de projetos, pois essa atividade lhes
consumiria um tempo que talvez não tenham.
Suporte de software: o PMO é responsável pelo software de gerenciamento de
projetos adotado pela empresa, o que pode incluir desde a administração de servidores à
configuração dos navegadores de internet. Esse assunto pode ser tão complexo que o
autor o separa em um dos componentes principais da atuação do PMO.
151
APÊNDICE D – PROPOSTA DE PROJECT CHARTER PARA PMO
PROJETO: Implementação do PMO
CLIENTE: Empresa Fictícia S.A. – Resp.: Sr. Fulano de Tal
INTRODUÇÃO
OBJETIVO DO PROJETO
ESCOPO
DESCRIÇÃO DO PRODUTO FINAL
152
ORÇAMENTO PREVISTO
Recursos Custo Estimado (R$) Total
Humanos
Materiais e
Equipamentos
Serviços
ORÇAMENTO TOTAL ESTIMADO
GERENTE DO PROJETO
O profissional abaixo identificado est[a autorizado a conduzir o planejamento e a
execução do projeto, e responderá por seus resultados perante este comitê diretor.
Nome do gerente do projeto: ______________________________________________
- Sigla: _____________
APROVAÇÕES
Nome/sigla:
Cargo:
Nome/sigla:
Cargo:
LOCAL: ____________________________, ____ de _________________ de _______.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
