TCC - Gerenciamento de Multiplos Projetos

Gerenciamento de Múltiplos Projetos TCC GP09 RJ / FGV
ROBERTO HENRIQUE NOGUEIRA PONS

ANDRÉ LUIZ CATALDO FALBO SANTO
GERENCIAMENTO DE MÚLTIPLOS PROJETOS
Monografia apresentada ao curso MBA em

Gerência de Projetos, Pós-Graduação lato-
sensu, da Fundação Getulio Vargas como
requisito parcial para a obtenção do Grau de
Especialista em Gerência de Projetos.
MONITOR: Prof. Edmarson B. Mota
Rio de Janeiro
Outubro / 2004
Todos os direitos reservados 1

RESUMO
Muito se fala, se escreve e se discute em relação ao gerenciamento de projetos

atualmente. As associações profissionais crescem rapidamente, o consciente coletivo põe em
pauta o tema nos círculos administrativos e operacionais, e vários indícios mostram que a
tendência é a discussão aumentar.
No entanto, o ambiente que se encontra nas organizações atualmente é ainda mais
complexo, em vista do crescimento absurdo das iniciativas e ações necessárias para reagir às
inúmeras mudanças que ocorrem num ritmo alucinante. A área de TI se destaca nesse
ambiente e mereceu um aprofundamento neste trabalho. O resultado disso, é claro, é o
aumento exponencial do número de projetos que as organizações têm que realizar, diga-se de
passagem, com sucesso.
Esse é na verdade o ambiente de múltiplos projetos, que proporciona um desafio
inadiável para administradores, gestores e gerentes. A questão passa ser agora não somente o
sucesso de um projeto individual, mas também o sucesso do conjunto, ou coleção de projetos
da organização.
O nosso objetivo, neste trabalho, é apresentar as diferentes visões do ambiente de
múltiplos projetos: estratégico, tático e operacional, com foco nesse último. É pensando nos
gerentes e equipes que ficam se dividindo entre os múltiplos projetos em que estão
envolvidos, que desenvolvemos este trabalho, procurando reunir conceitos e trazer novas
idéias para ajudar a vencer esse novo paradigma. Aliando uma extensa pesquisa bibliográfica
e a realização de uma pesquisa de campo à nossa experiência própria, pudemos dar a nossa
visão e sugerir técnicas e processos para ajudar essas pessoas nesse desafio.
Palavras-chave: múltiplos, projetos, gestão, gerenciamento, portfólio.

ABSTRACT
Much is said and written about project management today. Professional associations
grow at fast rates and the topic is discussed more and more in administrative and operational
circles. And the heat is on.
In addition, the organizational environment today is even more complex, in face of the
incredible growth in the number of actions necessary to deal with an ever changing world. IT
is an area especially affected by this reality, and deserves a deeper analysis in this work. The
result, of course, is the exponential increase in the number of projects that organizations must
implement, note, with success.
This is actually the picture of the multi-project environment, which poses an
unavoidable challenge to administrators and managers. The issue becomes not only achieving
success of an individual project, but the success of the group of projects of the organization.
Our objective in this work is present different views of the multi-project environment:
the strategic, tactical, and operational, with the emphasis on the latter. It was thinking on the
managers and teams that have to address the multiple projects they are involved in, that this
work was developed, looking to bring together concepts and new ideas to help overcome this
paradigm shift.
Adding an extensive bibliographical and field research to our own experience, we
believe we were able to bring our contribution to the subject, as we suggest techniques and
processes to help people with this challenge.
Key words: multiple projects, project management, administration, portfolio.

SUMÁRIO
RESUMO...............................................................................................................................2
ABSTRACT.......................................................................................................................3
LISTA DE TABELAS E FIGURAS ............................................................................................6
LISTA DE ABREVIATURA E SIGLAS......................................................................................7
1 INTRODUÇÃO ...............................................................................................................8
1.1 Cenário Atual..........................................................................................................8
1.2 Definição do Problema............................................................................................9
1.3 Relevância do Trabalho...........................................................................................9
1.4 Delimitação do Trabalho.......................................................................................10
2 METODOLOGIA...........................................................................................................11
2.1 Estruturação do Trabalho ......................................................................................11
2.2 Os Fins e os Meios ...............................................................................................12
2.3 Limitações ............................................................................................................13
3 REFERENCIAL TEÓRICO.............................................................................................14
3.1 A Teoria de Administração de Empresas...............................................................14
3.2 Evolução Histórica da Gerência de Projetos ..........................................................16
3.2.1 Raízes na História Antiga ..............................................................................16
3.2.2 A Era “Moderna” ..........................................................................................16
3.2.3 O Novo Ambiente .........................................................................................19
3.3 Tipos de Projetos ..................................................................................................20
3.3.1 Projetos Pequenos vs. Projetos Grandes.........................................................20
3.3.2 Projetos de Desenvolvimento vs. Projetos de Implantação .............................22
3.3.3 Projetos Empresariais vs. Projetos de Engenharia e Construção.....................23
3.3.4 Projetos de TI................................................................................................25
3.4 Extreme Project Management (XPM)....................................................................33
3.4.1 Conceitos XPM .............................................................................................34
3.4.2 Técnicas e Ferramentas XPM ........................................................................37
3.4.3 O Modelo de Gerenciamento XPM................................................................39
3.5 Ambientes de Múltiplos Projetos...........................................................................43
3.5.4 Gestão de Portfólio........................................................................................45
3.5.5 Gerência de Programas..................................................................................47
3.5.6 Gerenciamento de Múltiplos Projetos ............................................................49
3.5.7 Gerenciamento do Tempo..............................................................................54
3.6 O Método da Cadeia Crítica ..................................................................................57
3.6.1 A Teoria das Restrições.................................................................................57
3.6.2 CCM vs. CPM...............................................................................................58
3.6.3 CCM no Ambiente de Múltiplos Projetos ......................................................59
4 ANÁLISE DE RESULTADOS.........................................................................................60
4.1 Pesquisa de Campo I .............................................................................................60
4.1.1 Avaliação Geral da Pesquisa I .......................................................................60
4.1.2 Tabulação e Análise dos Dados – Pesquisa I..................................................61
4.2 Pesquisa de Campo II............................................................................................67

4.2.1 Sumário dos Dados Descritivos .....................................................................68

4.3 Avaliação dos Resultados e Conclusões ................................................................70
5 CONCLUSÕES .............................................................................................................70
5.1 A Importância do estudo de Múltiplos Projetos para a Organização.......................70
5.2 A Gerência de Múltiplos Projetos e a Teoria de Administração de Empresas.........72
5.3 Conceitos Básicos para Gerenciar Múltiplos Projetos com Sucesso.......................73
5.4 XPM em Múltiplos Projetos ..................................................................................75
5.5 Ferramentas para Múltiplos Projetos .....................................................................76
5.6 PMBOK e Múltiplos Projetos................................................................................78
5.7 Abordagem para Múltiplos Projetos de TI .............................................................79
5.8 Considerações Finais.............................................................................................82
6 BIBLIOGRAFIA ............................................................................................................84
7 ANEXOS ......................................................................................................................89
7.1 Anexo I – Pesquisa de Campo...............................................................................89

LISTA DE TABELAS E FIGURAS
Tabela 1 Projetos de Engenharia vs. Empresariais

Tabela 2 Tecnologia em projetos
Tabela 3 Sumário dos dados descritivos
Tabela 4 Sumario dos dados descritivos, Chaves (2004)
Figura 01 Processos do Extreme Programming
Figura 02 Fases do RUP
Figura 03 Exemplo de aplicação das “Réguas de Sucesso”
Figura 04 Estratégia Monolítica
Figura 05 Estratégia por Versões
Figura 06 Estratégia Evolutiva
Figura 07 Portfólio, Programas e Projetos
Figura 08 Segmento da Empresa
Figura 09 Tipo de Projeto
Figura 10 Atuação no Projeto
Figura 11 Quantidade de Projetos Simultâneos
Figura 12 Volume de Projetos
Figura 13 Recursos Alocados
Figura 14 Duração Média dos Projetos
Figura 15 Complexidade dos Projetos
Figura 16 Nível de Stress
Figura 17 Critério de Sucesso
Figura 18 Múltiplos Projetos no Contexto da Organização

LISTA DE ABREVIATURA E SIGLAS
AM Agile Modeling (Modelagem Ágil)

ARPANET Advanced Research Project Agency Network
BCS Balance Score Card
CASE Computer Aided Software Engineering
CCM Critical Chain Method
CPM Critical Path Method
DOD Department of Defense
JAD Joint Applications Design
JRP Joint Requirements Planning
OTAN Organização do Tratado do Atlântico Norte
P&D Pesquisa e Desenvolvimento
PERT Program Evaluation and Review Technique
PMI Project Management Institute
PMBOK Project Management Body of Knowledge
PMIS Project Management Information System
PMP Project Management Professional
PPMS Program and Portfolio Management Standard
RAD Rapid Application Development
RAP Rapid Planning
RUP Rational Unified Programming
TI Tecnologia da Informação
TOC Theory of Constraints
UML Unified Modeling Language
WBS Work Breakdown Structure
XP Extreme Programming
XPM Extreme Project Management

1 INTRODUÇÃO
A escolha do tema de Gerenciamento de Múltiplos Projetos foi influenciada por vários

fatores. Além de ser um assunto contemporâneo, aliás, muito recente nas discussões e
literatura, é um tema fortemente vivenciado pelos autores em suas atividades profissionais.
Um dos autores tem uma empresa que desenvolve uma ferramenta informatizada voltada para
esse tema, além de estar envolvido em várias outras atividades, como consultoria e
treinamento. O outro autor é especialista em desenvolvimento de projetos de software,
liderando vários projetos simultâneos em um grande provedor internet. Os desafios
encontrados nos aspectos estratégicos, táticos e operacionais do tema são objetos deste estudo,
sendo que a ênfase será na estratégia para lidar com os conflitos e as dificuldades de se
gerenciar múltiplos projetos com recursos limitados e compartilhados, sob o ponto de vista
operacional.
1.1 Cenário Atual
É de conhecimento público e notório que a velocidade de mudanças no mundo de hoje

em todas as áreas, seja empresarial, tecnológico, educacional, governamental, social, é muito
maior do que no passado, sendo que ela continua aumentando e acelerando cada vez mais. A
facilidade de comunicação, as restrições de recursos, a competição, além de vários outros
fatores que serão discutidos no decorrer deste trabalho, contribuem para essa mudança de
ambiente, colocando forte pressão nas organizações.
Existe um consenso há cerca de vinte anos sobre o conceito de Porter (1986) de que as
mudanças no ambiente forçam as organizações a se reposicionarem no mercado para garantir
a sua sobrevivência, revendo a sua estratégia competitiva e consequentemente criando novos
planos de ação para alcançar as novas metas estratégicas. Como os planos de ação se
resumem a um conjunto selecionado de projetos, fica claro o entendimento que no cenário
atual de grandes mudanças, o número de projetos necessários para acompanhar o ritmo de
mudança aumentou absurdamente, em todas as áreas.

1.2 Definição do Problema
Quando o assunto “múltiplos projetos” é discutido, é preciso entender melhor o que se

quer dizer com esse termo, pois afinal existem várias perspectivas sobre o tema. Existe a visão
estratégica, que se refere à Gestão de Portfólio, ou carteira de projetos da organização; a
visão tática que trata da Gerência dos Programas, e finalmente a visão operacional, onde
gerentes e integrantes de equipes estão alocados em vários projetos simultaneamente, que será
referido neste trabalho como Gerenciamento de Múltiplos Projetos. Todas as três visões serão
abordadas no estudo. Porém, as duas primeiras, de Portfólio e Programas, já contam com uma
discussão um pouco mais amadurecida na literatura, sendo alvo de vários estudos e com
questões mais estabelecidas. A visão operacional, no entanto, que aflige tanto os gerentes de
projetos quanto a equipe, carece de um aprofundamento ao mesmo tempo em que apresenta
grandes desafios, os quais este trabalho pretende abordar, procurando sugerir algumas
estratégias para facilitar o exercício das funções nesse ambiente.
Pretendemos ajudar a responder algumas perguntas cruciais sobre o gerenciamento de

múltiplos projetos, como:
- Quais são os fatores críticos de sucesso no gerenciamento de múltiplos projetos?
- Como minimizar os conflitos pela disputa de recursos entre projetos concorrentes?
- Quais técnicas e ferramentas devo utilizar para facilitar o processo?
- Como prevenir a alocação além da nossa capacidade de realização?
Decorrente de nossas experiências profissionais, verificamos que a área de TI tem

grande afinidade com essas questões, sendo um de nossos objetivos nesse estudo fazer um
paralelo das questões abordadas para o gerenciamento de múltiplos projetos em geral com o
ambiente específico de TI.
1.3 Relevância do Trabalho
A relevância do tema é evidente, uma vez constatada que a realidade na grande

maioria das organizações atualmente é o ambiente de múltiplos projetos, onde os recursos são
limitados e precisam ser compartilhados entre projetos e departamentos, como demonstra
Chaves (2004) em sua dissertação sobre o tema. São menos freqüentes os projetos que têm o
privilégio de receber recursos dedicados, em função de seu porte, custo, peso estratégico, ou
complexidade. Mesmo nessas organizações, existe certamente uma gama considerável de

projetos que são executados até mesmo em caráter informal e que consomem boa parte dos
recursos e tempo das pessoas envolvidas, muitas vezes sem registro e sem o devido
planejamento.
Sendo o trabalho baseado em questões presentes em praticamente todas as

organizações, o tema e os objetivos do trabalho vão ao encontro dos anseios dos envolvidos
em projetos simultâneos, seja como gerente, equipe, patrocinador ou qualquer outro
stakeholder. Com relação ao aprofundamento na área de TI, esta é uma área de atuação que
tem tido o maior crescimento na participação do mercado de gerenciamento de projetos, e
como tem forte afinidade com as melhores práticas, a qualifica para receber uma atenção
especial sobre o tema.
Como a literatura ainda apresenta poucas referências no estudo dessas questões, ainda
há muito ser percorrido sobre o tema. Procurando complementar a referência bibliográfica,
decidimos aplicar uma pesquisa de campo sobre o tema de gerenciamento de múltiplos
projetos a profissionais ligados ao assunto. Desta forma, pudemos comprovar algumas
questões teóricas e conhecer um pouco mais da realidade local. Acreditamos que este trabalho
contribui tanto para o melhor entendimento sobre o assunto como oferece alternativas de
ações para melhorar o desempenho e a maturidade das organizações em seus projetos.
1.4 Delimitação do Trabalho
Da mesma forma que o assunto é emergente na literatura e tem um grande espaço para
desenvolvimento, não temos a pretensão de esgotar a discussão nem proporcionar todos os
elementos de facilitação dos processos envolvidos. O tema em toda sua plenitude é complexo,
envolve todas as camadas organizacionais: estratégica, tática e operacional, e abrange uma
larga variedade de áreas, indústrias e stakeholders.
O foco do trabalho está no âmbito operacional, portanto, as outras visões – estratégica

e tática - são abordadas de forma descritiva, no referencial teórico do trabalho, para maior
esclarecimento do fluxo lógico e encadeamento da discussão, dando base para os argumentos
e colocando a questão principal na perspectiva correta. Não está previsto no escopo deste
trabalho, a análise da relação das características do ambiente multiprojeto com a estrutura
organizacional da empresa, que já foi abordado com competência por Chaves (2004).
Tampouco tem esse trabalho o objetivo de desenvolver metodologias específicas para
aplicação direta nas organizações, que por sua vez, devem utilizar esse estudo como mais um
insumo na criação das mesmas.

2 METODOLOGIA
Este capítulo tem por objetivo descrever a metodologia utilizada neste trabalho. De
acordo com a taxionomia sugerida pela coordenação da FGV, utilizamos a seguinte
abordagem.
2.1 Estruturação do Trabalho
Este trabalho está estruturado em 7 blocos:

1. Introdução: Este capítulo analisa o cenário atual e definindo a Definição do
Problema a ser estudado. A partir destes pontos estabelecemos os Objetivos da
Pesquisa, formulando algumas Questões a serem investigadas. Segue-se discussão
da justificativa e a Relevância do Trabalho.
2. Metodologia: Este capítulo descreve a metodologia e a estrutura do trabalho.
3. Referencial Teórico: Este capítulo procurou organizar a investigação da literatura
em 6 blocos de conceitos fundamentais para o entendimento da questão problema
do trabalho. O primeiro aborda os conceitos ligados a visão geral sobre o contexto
de administração empresarial e seu relacionamento com gerenciamento de
projetos. No segundo bloco abordamos uma visão histórica do gerenciamento de
projetos. O terceiro bloco faz uma abordagem quanto a natureza dos projetos e
seus relacionamentos. O quarto bloco aborda os conceitos fundamentais sobre
Extreme Project Management (XPM). O quinto bloco aborda os vários ambientes
de múltiplos projetos, e por fim, no sexto, é apresentada a Teoria das Restrições e
o Método da Cadeia Crítica como alternativa de gerenciamento de múltiplos
projetos.
4. Analise dos resultados da pesquisa: Este capítulo descreve o processo de
obtenção dos resultados, por meio das seguintes fases:
a. Trabalho sobre a amostra obtida, utilizando-se uma estratégia de filtragem,
seleção e processamento dos dados obtidos na pesquisa;
b. Tabulação dos dados pesquisados;
c. Análise dos resultados da pesquisa, comparação com outra pesquisa já
existente;
d. Conclusão.

5. Conclusões: Este capítulo descreve o que os autores desejam contribuir de seus

estudos e pesquisas, fazendo o relacionamento entre técnicas, ferramentas e
características de projetos com o tema de gerenciamento de múltiplos projetos.
6. Referências Bibliográficas: Relação de autores, livros, artigos e demais trabalhos
científicos utilizados no Referencial Teórico e em outras partes do trabalho.
7. Anexos: Como documento complementar está incluído no Anexo, o Modelo do
Formulário de Pesquisa utilizado.
2.2 Os Fins e os Meios
Utilizamos uma metodologia mista tanto nos fins, quanto nos meios para desenvolver
o trabalho. Quanto aos fins, temos basicamente três tipos:
o Exploratória: como o tema de gerenciamento de múltiplos projetos tem pouco
conhecimento acumulado e estruturado, procuramos explorar o assunto em várias
dimensões.
o Explicativa: como os resultados obtidos no gerenciamento de múltiplos projetos
são em geral insatisfatórios, ocorrendo fenômenos de forma sistematizada,
procuramos esclarecer os motivos dessas ocorrências e os fatores que contribuem
para o grau de insucesso existente.
o Aplicada: motivados a proporcionar uma visão mais clara da realidade dos
múltiplos projetos, procuramos também resolver o lado prático, oferecendo várias
ações e soluções para os problemas encontrados no dia a dia.
Quanto aos meios, preferimos utilizar dois principais, que são:
o Pesquisa de Campo: fizemos uso da oportunidade de realizar uma investigação
empírica com elementos representativos do tema para podermos aferir, localizar e
sedimentar o conhecimento específico que trata o tema, já que o assunto não tem
uma unanimidade acadêmica. Utilizamos também outra pesquisa realizada
anteriormente como referência adicional.
o Pesquisa Bibliográfica: Parte fundamental do trabalho, a pesquisa bibliográfica
na literatura é necessária como ponto de partida e referencial conceitual para
comprovar e inspirar as soluções apresentadas ao final.

2.3 Limitações
A maior limitação da pesquisa de campo realizada é a pouca quantidade de questões

questionadas, em função do pouco tempo disponível para o preenchimento das respostas.
Porém, acreditamos que os resultados foram bastante satisfatórios dentro do contexto em que
foi realizada, e contribui para a extensão do conhecimento sobre o assunto, procurando
auxiliar os envolvidos neste tipo de ambiente a entenderem algumas das motivações e causas
dos problemas encontrados.
Procurando minimizar a deficiência da profundidade, fizemos um paralelo com uma outra
pesquisa de campo feita recentemente sobre o mesmo tema, parte da tese de mestrado do
professor Lucio E. Chaves (A Gestão dos conflitos de recursos humanos entre os processos e
projetos, 2004), apresentados na seção seguinte, de Análise de Resultados.

3 REFERENCIAL TEÓRICO
Esta parte do trabalho procura apresentar os assuntos pertinentes ao tema em estudo

que servem como base de referência teórica encontrada na literatura científica para a evolução
e discussão do problema apresentado. Posteriormente, na conclusão do trabalho, as
referências serão usadas para fundamentar os argumentos apresentados para o avanço do
conhecimento no tema, apresentando soluções e idéias inovadoras, ou formas diferenciadas de
se abordar a questão do gerenciamento de múltiplos projetos.
3.1 A Teoria de Administração de Empresas
Os autores acreditam que existem muitas semelhanças entre os conceitos de

administração de empresas e o gerenciamento de projetos, especialmente o gerenciamento de
múltiplos projetos. Dessa forma, apresentamos uma descrição resumida da teoria de
administração empresarial e os papéis dos vários níveis de administradores, para
posteriormente fazer uma analogia com múltiplos projetos e os respectivos gerentes de
projetos. Havendo o paralelo, podemos rever as técnicas e características usadas na
administração que poderiam ser aplicados também no gerenciamento de múltiplos projetos,
especialmente quando estamos lidando com a administração de vários empreendimentos ou
organizações simultaneamente. Lundgren (1974) em sua obra Organizational Management –
Systems and Process, descreve a universalidade da filosofia, teoria conceitos da
administração organizacional, mapeando os papéis e responsabilidades nos diversos níveis da
gestão e gerência corporativa. Ele apresenta várias definições do termo administração, até
chegar à formal, que é: “Administração é a força que, através do poder de decisão baseado no
conhecimento e entendimento, integra, via processos apropriados, todos os elementos de um
sistema organizacional de uma forma planejada para atingir os objetivos da organização.”
Podemos já detectar palavras-chaves que encontram grande sinergia com o gerenciamento de
projetos – decisão, conhecimento, integração, processos, elementos, planejamento, objetivos.
A filosofia de administração é um guia genérico que determina como uma organização

vai ser gerenciada e afeta cada faceta de sua operação, ajudando a construir a cultura
organizacional. A organização é considerada um sistema aberto, onde o ambiente externo
exerce influencia sobre o funcionamento e a sobrevivência do sistema, que por sua vez, reage
para manter o equilíbrio do sistema. De acordo com a análise clássica de sistema, um sistema
fechado está isolado de qualquer manifestação externa e tende à entropia e à disfunção, pois

não tem a habilidade de utilizar novos recursos e energia de fora sua unidade para manter o
equilíbrio interno. Um projeto também está sempre procurando o equilíbrio de seguir o plano
original, reagindo às interferências do ambiente para chegar ao seu objetivo. Assim como em
projetos, a administração empresarial precisa a todo custo controlar os elementos que levam à
manutenção do equilíbrio dinâmico interno, e para isso precisa utilizar recursos e informações
que possibilitem ajustes necessários aos seus sistemas em resposta ás mudanças do ambiente
externo. Esse é o grande desafio da administração. Para ter sucesso nessa função, ela precisa
de informação confiável e no tempo adequado, utilizando para isso sistemas de retorno, ou
feedback.
Outra questão importante de abordar no tema de administração são os níveis de

responsabilidade dentro de uma organização, que variam de acordo com o nível hierárquico
dentro da sua estrutura organizacional. Nem todos na administração têm a mesma
responsabilidade. Existem três níveis gerenciais distintos dentro de organizações mais
complexas: a alta administração, a gerência intermediária e a gerência operacional. Na
primeira estão o presidente, vice-presidentes, diretores, superintendentes, e outros ligados ao
plano estratégico da organização. No nível gerencial intermediário estão normalmente os
gerentes funcionais, que estão mais ligados no plano tático, e no operacional se encontram os
coordenadores, chefes de seção, etc. Apesar de que a titulação de cargos não distinguir
claramente a que grupo o administrador pertence, as responsabilidades e os seus afazeres o
fazem. No nível mais alto, os administradores se confrontam com grandes doses de incertezas
e lidam diretamente com as influencias do ambiente. Estabelecem a direção e a estratégia da
empresa, determinando o seu rumo geral. A gerência intermediária coordena a produção,
serve de interface entre a operação e a alta administração. Estabelece as metas de acordo com
os objetivos mais genéricos estabelecidos pelo Plano Estratégico feito pela alta administração.
A gerencia operacional realiza o trabalho com seus recursos. Todos os três níveis são
interdependentes e se relacionam constantemente.
Vale comentar que no caso de grupos empresariais, teremos mais níveis acima do
presidente da empresa, pois pode haver um conselho administrativo do grupo, ou holding, que
revisa e agrupa os interesses comuns do grupo, em prol de uma macro-estratégia que rege
todo o grupo. A mensagem principal é que quanto maior e mais complexa for a organização,
mais níveis de administração são necessários, compartilhando a responsabilidade e
distribuindo a administração em componentes cada vez menores.

3.2 Evolução Histórica da Gerência de Projetos
Discutir as origens do tema de gerenciamento de projetos é importante para

compreender muitos dos conceitos atuais e vai ajudar no entendimento deste trabalho. A
herança cultural, os dogmas e paradigmas de cada época vão nos municiar de ricos elementos
para construir alguns dos argumentos chave da discussão que se seguirá.
3.2.1 Raízes na História Antiga
Projetos não é novidade para o ser humano. A capacidade de alterar o ambiente à seu
favor e usar da inteligência para desenvolver soluções inovadoras para os problemas e
necessidades da sociedade existe há muito tempo. Thomsett (2001) observa que o conceito do
desenvolvimento de tecnologia pode ser traçado desde o período Neolítico (~10.000 anos
atrás), que marcou a transição da caça para agricultura e domesticação de animais. Com essa
mudança, a evolução da engenharia, por assim dizer, acelerou, alcançando um primeiro pico
durante o antigo reinado do Egito antigo (3,000 bc), com o desenvolvimento de sistemas de
irrigação e esgoto, barcos, canais e claro, as inesquecíveis pirâmides. Em relação às
pirâmides, Cleland (1999) destaca as grandes proporções desse projeto, de grande esforço
humano e custo. Estima-se que cerca de 100,000 trabalhadores levaram 30 anos para
completá-las. Projetos de grande porte também eram realizados em outras civilizações, como
na Mesopotâmia, China e Grécia. Outros feitos de grandes proporções exemplificam a
evolução os projetos com a Grande Muralha da China (300 bc), as campanhas militares de
Alexandre o Grande, as realizações do Império Romano, o templo de Jerusalém e porque não
as Sete Maravilhas do Mundo Antigo?
3.2.2 A Era “Moderna”

Henry Laurence Gantt, um engenheiro mecânico fez uma grande contribuição para a
disciplina de gerenciamento de projetos em 1917 com a criação do famoso Gráfico de Gantt,
um tipo de gráfico em barras que determina o cronograma do projeto. Essa ferramenta ainda é
muito usada atualmente. Algumas fontes, como Cleland (1999) e Thomsett (2001),
mencionam que talvez o primeiro grande projeto que tenha aplicado o conceito de
gerenciamento de projetos independente foi o Projeto Manhattan, que criou a primeira bomba
atômica. Richard Rodes (The Making of the Atomic Bomb, New York, Touchstone Books,
1995) documenta que o projeto estava em grandes dificuldades até que a liderança foi
separada entre o gerenciamento do projeto (custo, prazo, escopo) liderado pelo general Leslie

Groves, e o gerenciamento técnico, liderado pelo Dr. Robert Oppenheimer. Esta distinção foi
um marco para o gerenciamento de projetos, pois até então era sempre o arquiteto ou
especialista técnico que era responsável pelo gerenciamento de todos os elementos do projeto,
o que muitas vezes provocava um conflito de interesses e causava grandes atrasos e gastos
exagerados. Em projetos complexos, como aconteceu com a Casa de Ópera de Sidney, o
arquiteto pode ficar tão envolvido com os desafios tecnológicos a serem vencidos que chegam
a ignorar o controle de prazo e custo, considerado por eles menos importante.
No entanto, o conceito do “moderno” gerenciamento de projetos, como o conhecemos,

teve suas origens mais recentemente, no final dos anos 50, em decorrência da pressão do
governo americano por uma corrida de desenvolvimento tecnológico durante a Guerra Fria.
Essa pressão foi detonada pela crise do Sputnik em 1957, quando a União Soviética lançou
com sucesso o satélite Sputnik 1, enquanto os EUA haviam falhado em dois lançamentos
anteriores. Esse fato gerou uma reação forte dos americanos, que resultou em várias
iniciativas do Departamento de Defesa (DOD), tais como:
o A corrida espacial, com a criação da NASA em 1958;
o Aumento drástico do fomento à pesquisa científica, aumentando em 1959 o orçamento
da Fundação Nacional de Ciências americana de 34 para 134 milhões de dólares;
o Criação do Programa de Mísseis Polaris, com a construção de um submarino nuclear
para diminuir a diferença em relação ao arsenal russo. O Almirante Raborn da marinha
americana tinha urgência para realizar o programa e as ferramentas de gerenciamento
de projetos tradicionais não eram suficientes para garantir a entrega do projeto. O
DOD então desenvolveu com a ajuda de Willard Frazar o PERT (Program Evaluation
and Review Technique), um sistema de sequenciamento de atividades que consegue
determinar o menor tempo para a conclusão de um projeto. A utilização do PERT se
tornou obrigatório para todos os projetos da marinha Americana.
o A Agência de Pesquisa Avançada de Projetos de Defesa do Pentágono iniciou nos
anos 60 o projeto de uma rede de computadores chamada ARPANET, que foi a
percussora da Internet de hoje.
Nesta mesma época outros avanços foram desenvolvidos no gerenciamento de

projetos. A DuPont criou o CPM (Critical Path Method), ou Método do Caminho Crítico, que
é amplamente usado atualmente, para identificar quais são as atividades críticas de um projeto
que podem atrasá-lo. O PERT foi depois estendido para o WBS (Work Breakdown Structure),
também conhecido com Estrutura Analítica do Projeto. O método tradicional do Caminho

Crítico se estendeu para a conhecida Cadeia Crítica, que é baseada na Teoria das Restrições,
criada por Eliyahu M. Goldratt.
PMI
A fundação do PMI (Project Management Institute) em 1969 é sintomática da
evolução e da formalização da disciplina nesse período. Os cinco voluntários fundadores já
reuniram naquele mesmo ano em seu primeiro simpósio realizado em Atlanta, Geórgia, 83
pessoas. Atualmente o instituto tem mais de 139 mil sócios (PMI 2004), certifica profissionais
como PMPs (Project Management Professional) no mundo inteiro, desenvolve padrões para a
profissão, como Um Guia de Conjunto de Conhecimentos de Gerenciamento de Projetos
(PMBOK) e outros, promove seminários, simpósios e congressos internacionais, publica
livros, revistas e jornais sobre o assunto e tem uma fundação educacional (PMI Educational
Foundation).
Anos 60 a 90
Esse período que caracteriza aproximadamente a duração da Guerra Fria, que
começou no ambiente pós 2ª Guerra e se encerrou no desmembramento da União Soviética
em 91, influenciou muito o rumo tomado na evolução do gerenciamento de projetos.
Já vimos como no início desse período houve uma grande demanda nos Estados
Unidos (que é o país onde se iniciou o movimento e até hoje é a mola mestre do crescimento
do tema), pelo desenvolvimento de grandes projetos tecnológicos estimulado pelo governo e
poder militar. O gerenciamento de projetos se formalizou e associações profissionais surgiram
para fomentar mais o conhecimento e a evolução do tema. No início do período, como declara
Kerzner (2001) somente as indústrias aeroespacial, construção e defesa adotaram a
formalização do gerenciamento de projetos, utilizando as técnicas recém desenvolvidas. O
restante das empresas continuou gerenciando com métodos informais, tendo como gerentes de
projetos sempre as lideranças funcionais, que mantinham a sua forma tradicional de trabalho.
Nos anos 70 e 80, cada vez mais empresas começaram a migrar para o gerenciamento
formal, devido ao aumento da complexidade e magnitude de seus projetos, a ponto de ficarem
ingerenciáveis com os métodos informais. A evolução da tecnologia também foi um fator que
influenciou muito no aumento dessa complexidade e tornou os projetos de maior risco.
Porém, as metodologias em prática nesse período refletiam os tipos de projetos que

predominavam na época, de grande porte, longa duração e altos custos, utilizando uma
estrutura tradicionalmente linear, ou monolítica de gerenciamento.
Nos anos 80, iniciou-se um movimento de mudança de percepção e novos

pensamentos surgiram. Foi a época do surgimento de Porter (1986) com sua teoria de
estratégia competitiva e de Tom Peters (1982) com a mudança de foco para as pessoas no
sucesso da empresa, e outros. Foram os precursores de um novo ambiente.
3.2.3 O Novo Ambiente
O período pós Guerra Fria trouxe uma nova era, a da Globalização, a partir dos anos
90. Com a abertura dos mercados internacionais, a evolução acelerada da tecnologia e a
facilidade da comunicação, um boom econômico aconteceu. Certamente o surgimento e a
proliferação da Internet aceleraram o processo, aumentando muito o ritmo de mudanças no
ambiente. Como coloca Thomsett (2001), novos fatores como a mudança da relação entre
funcionários e empresas, o fim da lealdade mútua como a conhecíamos no passado (ou talvez
nossos pais), o aumento da competitividade e do nível de exigência do consumidor mudaram
o jogo. O ambiente empresarial se tornou turbulento e mais caótico, demandando novos
produtos mais rápidos das empresas que quiserem sobreviver e se destacar num mercado cada
vez mais disputado.
O gerenciamento de projetos ganha novos aliados nesse período, que Kerzner (2001)
delineia com precisão. O argumento é durante a recessão americana de 1989 a 1993, quando
as dificuldades aumentaram, novas soluções apareceram, como a engenharia simultânea, que
reforçou a importância do gerenciamento de projetos. Os anos seguintes foram marcados pelo
reconhecimento que gerenciar bem projetos era estratégico para a sobrevivência das empresas
e o investimento na área tem aumentado desde então. Porém, o perfil dos projetos e a relação
entre os gerentes de projetos e a administração também mudou, evidenciando uma mudança
de paradigma, como veremos a seguir.

3.3 Tipos de Projetos
Projetos vêm em todas as cores, sabores, tipos e tamanhos. Antes de entrarmos na

discussão do gerenciamento de múltiplos projetos, vamos analisar a própria natureza dos
projetos, os vários tipos e características que possam nos ser útil no momento de discutir a
melhor forma de gerenciá-los, ainda mais de forma simultânea.
3.3.1 Projetos Pequenos vs. Projetos Grandes
Tamanho é documento? Em se tratando de projetos, podemos dizer que sim. Porém,

Thomsett (2002) diz que não existe o tal “pequeno projeto”, numa alusão de que um pequeno
projeto mal gerenciado pode se tornar um grande problema e então acaba virando um grande
projeto. Realmente, ninguém nega que muitas vezes detalhes ignorados ou simples tarefas mal
executadas podem ter um efeito dominó que trará grandes prejuízos mais tarde. Vamos ver
como a literatura trata então a gerência de pequenos projetos. Cleland e Ireland (2000)
propõem um simples protocolo de regras básicas de como pequenos projetos podem ser
gerenciados, iniciando com a identificação da necessidade, passando pelo planejamento do
projeto, coletar informações, analisar dados, desenvolver e avaliar alternativas para solucionar
o problema e finalmente apresentar recomendações. Eles observam que um pequeno projeto
deve ser gerenciado utilizando-se uma versão simplificada da maioria dos conceitos,
processos e técnicas adotadas em grandes projetos. Eles classificam pequenos projetos como
envolvendo menos que 5 pessoas, com custo entre US$ 5 mil e US$ 50 mil.
Kerzner (2001) considera pequenos projetos os de duração entre 3 e 12 meses, custos

entre US$ 5 mil e US$ 1,5 milhão em não mais do que 3 ou 4 centros de custos e que não
tenha mais do que 3 níveis na decomposição do projeto pelo WBS. Existe contínua
comunicação entre os membros da equipe, onde o gerente do projeto trabalha em contato
diário com recursos de áreas funcionais, dispensando relatórios detalhados em intervalos
curtos. O controle de custos pode ser feito manualmente em vez de por sistemas
informatizados.
Embora não exista um consenso na literatura sobre o ponto de corte de quando um

projeto deixa de ser pequeno, existe a idéia comum de que a equipe deve ser pequena, o prazo
curto, o custo baixo, assim como o esforço e a complexidade. As escalas ficam por ser
definidas particularmente, dentro da realidade de cada empresa, levando em conta o ambiente,
as naturezas de sua atuação, a indústria e outros fatores de influência.

No outro extremo, Kerzner (2001) assinala que mega-projetos têm características

particulares, como a alocação de um grande número de pessoas por períodos curtos e intensos
e possíveis re-estruturações organizacionais quando o projeto muda de fase no ciclo de vida,
podendo, por exemplo, alternar de uma estrutura matricial para projetizada. Alerta também
para o risco de uma empresa, ao pegar um grande projeto, alocar os melhores recursos para o
tal projeto, pondo em risco outros em andamento. Concentrar esforços e energia em um só
lugar também pode ser perigoso para a empresa, que fica vulnerável e instável. É normal esses
projetos demandarem esforço extra dos funcionários por tempo prolongado, o que causa perda
de produtividade e descontentamento. O conhecimento e experiência em lidar com grandes
projetos vão determinar as chances de sucesso, e a empresa tem que estar preparada para
desenvolvê-los sob o risco de colocar a sua sobrevivência em jogo.
Thomsett (2002) em seu artigo Managing Large Projects – A Special Case,

desenvolve o tema destacando que projetos de grande porte não são apenas grandes pequenos
projetos, e sim “animais de outra espécie”. Eles são mensurados em duas principais vertentes:
esforço de desenvolvimento e duração. A primeira tem um componente de recursos humanos
e outro de custo de capital. Para se ter idéia, a escala de esforço humano usada é baseada em
número de pessoas-ano (trabalho de uma pessoa dedicado o ano todo, considerando 8 horas
por dia, 210 dias por ano – cerca de 1680 hh). Projetos considerados realmente grandes
consomem cerca de 40-50 pessoas-ano, US$ 15 milhões e levam pelo menos 2 anos. Para
lidar com eles, deve-s elevar em consideração os seguintes conceitos, que deve ser revistos
para casos como esses:
o critérios de sucesso do projeto;
o técnicas especiais de gerenciamento de projetos;
o planejamento e controle em tempo real;
o organização e estrutura das equipes;
o estratégias de desenvolvimento combinadas;
o garantia da qualidade;
o ferramentas de suporte e tecnologia;
o desenvolvimento das equipes; e
o contratos e aquisições.
Para quem se interessa no assunto, vale a referência, porém para o propósito do nosso
assunto, não é necessário desenvolver mais o tema, ficando claro que existe grande diferença
entre projetos de tamanhos muito diferentes. Certamente, grandes projetos não são candidatos

ao gerenciamento múltiplo, mais adequado aos pequenos. Porém, é nos médios que paira a
incerteza, sendo necessários outros critérios para decidir.
3.3.2 Projetos de Desenvolvimento vs. Projetos de Implantação
Outra diferença relevante entre tipos de projetos é a que existe entre projetos de
desenvolvimento, também chamados de P&D (Pesquisa e Desenvolvimento), e projetos de
implantação, que estão ligados ao ambiente mais operacional, processual.
Kerzner (2001) destaca que uma das tarefas mais difíceis em uma organização é o
gerenciamento de projetos de desenvolvimento (P&D). Estes são normalmente liderados por
cientistas, engenheiros, pesquisadores e outros profissionais, tentando tornar uma idéia
inovadora em realidade dentro de prazos, custos e recursos restritos e definidos.
Naturalmente, como os projetos de P&D tipicamente têm um alto grau de incerteza, pela sua
natureza inventiva, conseguir esse feito é realmente um desafio. Os responsáveis por esses
projetos normalmente são profissionais altamente especializados e técnicos, com pouco
treinamento nas técnicas de gerenciamento de projetos. Mesmo para os melhores gerentes de
projetos, é uma tarefa muitas vezes hercúlea realizar algo inovador, lidando com tecnologia
em estado da arte ou ainda sendo desenvolvida, com pressão do pessoal de marketing,
finanças e executivos para obter sucesso num prazo determinado e com recursos limitados.
Para lidar com esse ambiente turbulento de projetos, Githens (2001) descreve em seu artigo a
técnica de rolling wave management, ou gerenciamento por ondas, que representa uma
abordagem em fases, onde se “planeja um pouquinho e executa um pouquinho”. De acordo
com os resultados obtidos, uma nova fase (ou onda) começa, é definida, planejada e
executada. E o processo se repete até que os objetivos forem atingidos, ou se descubra que de
fato eram inviáveis. O fracasso de projetos de P&D é comum, faz parte da sua natureza.
Devemos atentar para o significado de fracasso. Nesse caso, estamos nos referindo à
realização da idéia que originou o projeto, não nos cumprimentos de metas de custo e prazo.
O rolling wave tem muitas similaridades com as estratégias de planejamento em tempo real e
planejamento por cenários, discutidas posteriormente neste trabalho. A dica aqui em relação
ao nosso tema é evitar envolver o pessoal de P&D em muitos projetos simultâneos, por uma
razão restritiva: reduz drasticamente a criatividade, que é o elemento fundamental nesse tipo
de projeto.
Projetos considerados de implantação são mais previsíveis, representam a realização

de atividades que têm referências históricas, são mais lineares e necessitam de menos esforço

de planejamento, pois se utilizam de modelos existentes. São projetos mais operacionais, de

baixo risco e poucas surpresas. As equipes têm domínio sobre as atividades, estão treinadas
para realizá-las e melhoram seu desempenho a cada novo projeto do tipo que realizam.
Exemplos são instalações de redes de dados, construções padronizadas, etc. Este tipo de
projeto são os melhores para serem executados de forma simultânea.
3.3.3 Projetos Empresariais vs. Projetos de Engenharia e Construção
Em função das mudanças de ambiente já descritas, ficou em evidência uma nova

classe de projetos, com características distintas dos tradicionais de engenharia e construção,
que:
o devem ser entregues rápido;
o são de missão-crítica por natureza;
o precisam ser gerenciados em um ambiente turbulento de negócios e tecnologia, e
portanto,
o são sujeitos a constantes mudanças.
Esses tipos de projetos têm se tornado os mais comuns, devido às várias forças que
aumentam o ritmo de mudança, e podem ser chamados de projetos empresariais, ou business
projects.
Grande catalisador desse processo de mudança, a área da Tecnologia da Informação
tem influenciado fortemente a evolução do gerenciamento de projetos empresariais. Sendo
uma nova área profissional, procurou em outras áreas orientação e modelos para ajudar a
formalizar e estabelecer melhores práticas. Os modelos iniciais de desenvolvimento de
software eram muito baseados nos de engenharia e construção. A metodologia clássica de
desenvolvimento de sistemas dos anos 60, descrita nas conferências da OTAN (NATO
Software Engineering, Naur&Randaell, 1968), foi baseada no conceito tradicional de
progresso linear das fases de análise, desenho, construção, teste e implementação.
Consequentemente, os primeiros modelos formais de gerenciamento de projetos de TI
também refletiam os utilizados nas indústrias de defesa e construção.
O conceito de que o gerenciamento do projeto é uma disciplina independente do
gerenciamento técnico do projeto ficou claro na evolução histórica, especialmente no campo
da engenharia. Contudo, ainda persiste atualmente um mito que é sustentado por defensores

da tradicional escola de gerência de projetos: de que projetos de engenharia e construção são

do mesmo tipo que projetos empresariais, e, portanto, podem ser gerenciado com os mesmos
modelos. Utilizando por exemplo, o tradicional modelo em cascata (waterfall model), onde o
planejamento não pode começar antes que todas as especificações formais sejam assinadas
pelo cliente, e assim por diante. No entanto, a natureza distinta entre projetos de novos
processos empresariais, produtos ou sistemas e projetos de construção de prédios, mostra
claramente que outros modelos mais interativos e flexíveis são necessários para o
desenvolvimento do primeiro tipo de projetos.
Na tabela a seguir, podemos ver melhor os contrastes entre os dois tipos de projetos:
Tabela 1 – Projetos de Engenharia vs. Empresariais
PROJETOS DE ENGENHARIA PROJETOS EMPRESARIAIS
Numero pequeno de provedores de serviços Grande número de provedores envolvidos,

envolvidos, certificados e com contratos frequentemente com contratos verbais
formais informais
Especificações normalmente fixas e Especificações flexíveis e informais
formalizadas
Padrão bem estabelecido de código de ética Código de ética profissional mal
e conduta profissional estabelecida
Metodologias bem estabelecidas, baseadas Metodologias conflitantes baseadas em
em princípios matemáticos e físicos princípios teóricos e de marketing
Produtos físicos a serem entregues com Produtos abstratos a serem entregues, de
componentes modulares difícil modularização
Indicadores de desempenho claros e Indicadores de desempenho vagos e métricas
métricas precisas de difícil mensuração
Variação reduzida pelos processos Variação amplificada pelo individualismo e
padronizados e constantes unicidade
Técnicas alternativas como as utilizadas nos conceitos de Extreme Project

Management, que veremos mais tarde, foram desenvolvidas para lidar com os projetos
empresariais.

3.3.4 Projetos de TI
Em muitas organizações, a área de TI está envolvida tanto em atividades operacionais

do dia-a-dia como em projetos. O problema, com deixa claro Parth (2004), é que são (muitos)
múltiplos projetos. Do ponto de vista da equipe, existe um fluxo interminável de projetos em
que eles tem que trabalhar, enquanto os executivos têm a percepção de um alto índice de
insucessos relacionados aos projetos de TI. As equipes estão estressadas, sobrecarregadas, e
alocadas em vários projetos que mudam de prioridade e foco a todo o momento. Acaba
faltando tempo para fazer um planejamento adequado, o que é uma receita para o desastre.
O mundo de negócios está funcionando no “ritmo da Internet”, alerta o Meta Group
(2002), em referência ao ritmo acelerado de mudanças que assolam as organizações. Para se
manterem competitivos, elas precisam responder rápido ao mercado, modificando produtos e
encurtando os ciclos de vida. Líderes de negócios estão sendo pressionados para tomar
decisões mais rapidamente sobre investimentos em projetos de TI que refletem em seus
negócios e querem ter mais garantias de que o resultado será positivo.
3.3.4.1 Características dos Projetos de TI
Como já mencionado, projetos de TI atualmente estão muito ligados ao negócio da

organização e portanto estão também sujeitos às mesmas forças que aumentam o ritmo de
mudança, podendo também ser chamados de projetos empresariais.
O gerenciamento de projetos de software é uma tarefa de fundamental importância no
processo de desenvolvimento de um produto de TI, sendo definido como uma primeira
camada deste processo. O gerenciamento de projeto não é visto como uma etapa clássica do
processo de desenvolvimento uma vez que ele acompanha a todas as etapas, da concepção à
obtenção do produto. (Pressman, 1995).
O PMBOK (2000) define o gerenciamento de projeto como “a aplicação de
conhecimentos, habilidades, ferramentas e técnicas para projetar atividades a fim de satisfazer
ou superar as expectativas dos stakeholders em relação a um projeto”.
No entanto, são vários os problemas relacionados ao desenvolvimento de software, os
quais são resultantes da omissão ou do mal uso de metodologias e técnicas adequadas a esta
importante tarefa de engenharia. Chang & Christensen (1999) citam que são muitos os
problemas dos gerentes de projetos de software para a realização de grandes sistemas,
incluindo: (i) reunir, treinar e motivar uma grande equipe; (ii) desenvolver ou adotar

processos de gerenciamento e engenharia; (iii) desenvolver e manter requisitos; (iv) planejar,

orçar e monitorar o projeto; (v) identificar e resolver conflitos de recursos e (vi) monitorar o
projeto inteiro continuamente.
Royce (1998) relata o resultado de três importantes análises, realizada na metade dos
anos 90, sobre o estado da engenharia de software nas empresas. As três análises chegaram a
mesma conclusão, resumida em:
o Desenvolvimento de software ainda é altamente imprevisível. Somente
aproximadamente 10% dos projetos de software são entregues com sucesso
(considerando o orçamento e cronograma estimado).
o Disciplina de gerenciamento é mais um discriminador do sucesso ou fracasso que
uma tecnologia avançada.
o O nível de re-trabalho é um indicativo de um processo imaturo.
Pressman (1995) afirma que boa parte dos fracassos no que diz respeito aos projetos
de software deve-se, principalmente, a problemas de administração ou gerenciamento do
desenvolvimento de software.
Sommerville (1992) e O’Connor (2000) atribuem a dificuldade de gerenciamento de
projetos de software à diferença existente em relação a outros tipos de projetos, podendo-se
destacar 5 aspectos:
o Software não é “palpável”/visível: quando o produto a ser desenvolvido é uma
estrada, por exemplo, o progresso pode ser claramente verificado. No software o
progresso não é visível, o gerente de projeto depende da documentação para
verificar o progresso do projeto.
o Não se tem o entendimento claro do processo de software: na engenharia de
software os modelos de desenvolvimento de software são representações
simplificadas do processo.
o Vários projetos de software são “projetos únicos”, ou seja, não há semelhança com
projetos previamente desenvolvidos. Nestes casos, a experiência histórica é um
valor limitante em predizer como o projeto deverá ser gerenciado.
o Complexidade: “Cada dólar, peso ou euro gasto em um produto de software
contem mais complexidade que outros artefatos da engenharia.” (O’Connor2000).
o Flexibilidade: a facilidade com a qual um software pode ser alterado é geralmente
visto como uma de suas vantagens.

3.3.4.2 Dados Históricos
Uma significante reengenharia do processo de desenvolvimento de software ocorreu

nos últimos 20 anos, motivada pelo aumento da demanda de softwares produzidos mais
rapidamente e custos reduzidos. Desta forma, muito do gerenciamento convencional e
técnicas até então utilizadas tem sido substituídas por novas abordagens que combinam
experiências de sucesso em gerenciamento de projetos com os avanços da engenharia de
software.
Para Royce (1998) um gerenciamento moderno de software está baseado em diversos
princípios, podendo-se priorizar: (i) processo baseado em uma abordagem em que
primeiramente deve-se definir a arquitetura; (ii) estabelecer um processo de desenvolvimento
iterativo; (iii) métodos de projeto devem enfatizar o desenvolvimento baseado em
componentes; (iv) estabelecer um ambiente de gerenciamento flexível e (v) utilização de
ferramentas automatizadas que suportam diferentes formatos.
Ainda no que se refere a uma visão histórica do gerenciamento de projetos de
software, um comparativo realizado por Jones (apud Royce, 1998) entre tecnologias que
levaram ao sucesso ou insucesso 1000 (mil) projetos agrupados dentro de seis sub-indústrias:
sistemas de software, sistemas de informação, software comercial, outsource software,
software militar e software para usuários finais; reafirmam a importância do gerenciamento.
Com base neste levantamento Jones (apud Royce, 1998) relata que “seis dos dezessete fatores
tecnológicos associados com desastres no projeto de software são falhas específicas no
domínio do gerenciamento de projetos, e três das outras tecnologias deficientes podem ser
indiretamente determinadas por práticas pobres de gerenciamento”. O Quadro abaixo retrata
os fatores relacionados com o gerenciamento de projetos.
Tabela 2 – Tecnologia em projetos
Tecnologia em projetos mal sucedidos Tecnologia em projetos bem sucedidos

Ausência de dados históricos de medição dos Precisa medição do software
softwares
Insucesso ao usar ferramentas automatizadas Ferramentas de estimativa usadas facilmente
de estimativa
Fracasso no uso de ferramentas Uso contínuo de ferramentas de planejamento
automatizadas de planejamento
Falhas na monitoração do progresso do Relatório formal do progresso do projeto

projeto ou milestones
Falha no uso de uma arquitetura efetiva Planejamento formal da arquitetura
Não cumprimento de um método de Método formal de desenvolvimento

desenvolvimento
Gerenciamento de risco informal Gerenciamento de risco formal
Insucesso no uso formal do controle de Controle de configuração automatizado

configuração
Fonte: Royce (1998)
Um relatório apresentado pelo Standish Group (apud Royce, 1998) focado na indústria
de software comercial concluiu que:
o Companhias americanas gastariam $81 bilhões em projetos de softwares
cancelados em 1995.
o 31% dos projetos de software estudados foram cancelados antes deles serem
completados.
o 53% dos projetos de software passam do limite em mais de 50%.
o Somente 9% dos projetos de software das companhias grandes foram distribuídos
no prazo e dentro do orçamento. Para médias e pequenas empresas, os números
aumentaram para 16% e 28%, respectivamente.
Assim como relatado anteriormente por Jones (apud Royce, 1998), este relatório cita
que a principal razão para o sucesso ou fracasso está centrada nos requisitos do processo de
gerenciamento. Desta forma, fica evidenciada e ressaltada a importância do gerenciamento de
software para o sucesso dos projetos.
3.3.4.3 Técnicas de Desenvolvimento
Um processo de desenvolvimento de software pode ser visto como um guia para o

desenvolvimento e deve estabelecer: as atividades a serem realizadas durante o
desenvolvimento de software, sua estrutura e organização (decomposição e precedência de
atividades), incluindo a definição de um modelo de ciclo de vida; os artefatos requeridos e
produzidos por cada uma das atividades do processo; os procedimentos (métodos, técnicas e
normas) a serem adotados na realização das atividades; os recursos necessários para a
realização das atividades, dentre eles recursos humanos, recursos de hardware e recursos de

software, incluindo as ferramentas a serem utilizadas para apoiar a aplicação dos

procedimentos na realização das atividades; e roteiros para a elaboração dos principais
documentos (artefatos) gerados no desenvolvimento.
De maneira geral, o ciclo de vida de um software envolve, pelo menos, as atividades
de planejamento, levantamento de requisitos, análise, projeto, implementação, testes,
implantação, operação e manutenção.
Uma vez que o software é sempre parte de um sistema (ou negócio) maior, o trabalho
começa pelo estabelecimento dos requisitos para todos os elementos do sistema e, na
seqüência, procede-se a alocação para software de algum subconjunto destes requisitos. Esta
etapa é a Engenharia de Sistemas e antecede a todas as demais relacionadas.
3.3.4.3.1 XP – Extreme Programming
O XP é um processo de desenvolvimento de software definido basicamente por quatro

atividades: Planejamento, Teste, Implementação e Desenho (veja na Figura 1). Na fase de
Planejamento os requisitos são coletados e negociados com o cliente. Em seguida, os testes
são elaborados a partir das estórias do cliente, e a codificação é realizada visando atender
estes testes. Por fim, o sistema é novamente desenhado (ou reconstruído) a medida que novas
funcionalidades são incorporadas. Estas fases ocorrem iterativamente até que o produto esteja
pronto.
Planejamento Teste Codificação Desenho
Figura 1. Processos do Extreme Programming
O processo XP é regido por doze princípios. A seguir resumimos estes princípios:

o O jogo do planejamento: Visa rapidamente determinar o escopo da próxima
versão, combinando prioridades de negócio e estimativas técnicas.
o Pequenas versões: Visa produzir um sistema simples rapidamente, planejando
novas versões em um ciclo muito pequeno. Os ciclos duram três semanas

o Refactoring: Os programadores reestruturam o sistema sem mudar seu

comportamento para remover duplicação, melhorar a comunicação, simplificar ou
adicionar flexibilidade.
o Programação em pares: Todo o código produzido é escrito com dois
programadores em cada máquina. Em cada ciclo trocam-se os pares de
programadores.
o Propriedade coletiva: Qualquer pessoa pode mudar qualquer código em qualquer
tempo.
o Integração contínua: Visa integrar e construir o sistema muitas vezes ao dia, todas
as vezes que uma tarefa tiver sido finalizada.
o 40 horas por semana: Impõe que o time não trabalhe mais do que 40 horas por
semana. Mas se necessário que não se faça horas-extras por duas semanas
seguidas.
o Cliente on-site: O cliente deve fazer parte do time e estar disponível em tempo
integral para responder perguntas.
o Metáfora: Todo o desenvolvimento é guiado por uma simples estória
compartilhada de como o sistema como um todo funciona. A metáfora ajuda o
time a ter um mesmo entendimento sobre o vocabulário utilizado pelo domínio do
projeto e assim ajuda-o a nomear funções e variáveis apropriadamente. Cenários é
uma técnica de modelagem de requisitos. Utilizar esta representação de cenários
como ‘user-stories’ é uma proposta definida por Breitman (2002).
o Padrões de codificação: Os programadores devem escrever o código de acordo
com os padrões definidos pelo time, dando ênfase à comunicação através do
código. Assim, o código é a única documentação mantida no processo. Os cenários
apóiam o desenvolvedor durante a implementação, pois esclarecem as pré e pós-
condições de cada módulo, e facilitam a enumeração das funcionalidades
encapsuladas em cada porção de código.
o Desenho simples: O sistema deve ser projetado tão simples quanto possível. A
complexidade extra é removida assim que detectada.
o Teste contínuo: Os programadores continuamente escrevem unidades de teste e os
executam para que o processo de desenvolvimento continue. Em cada ciclo os
programadores apresentam uma versão testável do software ao cliente. Os clientes
escrevem testes para validar o sistema.

3.3.4.3.2 RUP – Rational Unified Programming
O Processo Unificado proposto pela Rational (Rational Unified Process – RUP) foi
criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma sistemática
para se obter reais vantagens no uso da Linguagem de Modelagem Unificada (Unified
Modeling Language – UML). De fato, ele não é exatamente um processo: é uma
infraestrutura genérica de processo que pode ser especializada para uma ampla classe de
sistemas de software, para diferentes áreas de aplicação, tipos de organização, níveis de
competência e tamanhos de projetos.
O RUP está fundamentado em três princípios básicos: orientação a casos de uso,
arquitetura e iteração. Ele é dito dirigido a casos de uso, pois são os casos de uso que
orientam todo o processo de desenvolvimento. Com base no modelo de casos de uso, são
criados uma série de modelos de análise, projeto e implementação, que realizam estes casos
de uso. É centrado em arquitetura, pois defende a definição de um esqueleto para a aplicação
(a arquitetura), a ganhar corpo gradualmente ao longo do desenvolvimento. Finalmente, o
RUP é iterativo e incremental, oferecendo uma abordagem para particionar o trabalho em
porções menores ou mini-projetos. Esses três conceitos são igualmente importantes. A
arquitetura provê a estrutura para guiar o desenvolvimento do sistema em iterações, enquanto
os casos de uso definem as metas e conduzem o trabalho de cada iteração.
O ciclo de vida adotado no RUP é tipicamente evolutivo. Contudo, uma forma de
organização em fases é adotada para comportar os ciclos de desenvolvimento, permitindo uma
gerência mais efetiva de projetos complexos. Ao contrário do tradicionalmente definido como
fases na maioria dos modelos de ciclo de vida – planejamento, levantamento de requisitos,
análise, projeto, implementação e testes, são definidas fases ortogonais a estas, a saber:
o Concepção: nesta fase, é estabelecido o escopo do projeto e suas fronteiras,
determinando os principais casos de uso do sistema. Esses casos de uso devem ser
elaborados com a precisão necessária para se realizar estimativas de prazos e
custos. As estimativas devem ser globais para o projeto como um todo e
detalhadas para a fase seguinte. Assim, a ênfase nesta etapa recai sobre o
planejamento e, por conseguinte, é necessário levantar requisitos do sistema e
preliminarmente analisá-los. Ao término dessa fase, são examinados os objetivos
do projeto para se decidir sobre a continuidade do desenvolvimento;
o Elaboração: o propósito desta fase é analisar com mais refino o domínio do
problema, estabelecer uma arquitetura de fundação sólida, desenvolver um plano

de projeto para o sistema a ser construído e eliminar os elementos de projeto que

oferecem maior risco. Embora o processo deva sempre acomodar alterações, as
atividades da fase de elaboração asseguram que os requisitos, a arquitetura e os
planos estão suficientemente estáveis e que os riscos estão suficientemente
mitigados, de modo a se poder prever com precisão os custos e prazos para a
conclusão do desenvolvimento.
o Construção: durante esta fase, um produto completo é desenvolvido de maneira
iterativa e incremental, para que esteja pronto para a transição à comunidade
usuária.
o Transição: nesta fase, o software é disponibilizado à comunidade usuária. Após o
produto ter sido colocado em uso, naturalmente surgem novas considerações que
vão demandar a construção de novas versões para permitir ajustes do sistema,
corrigir problemas ou concluir algumas características que foram postergadas.
Figura 2: Fases do RUP
É importante realçar que dentro de cada fase, um conjunto de iterações, envolvendo

planejamento, levantamento de requisitos, análise, projeto e implementação e testes, é
realizado. Contudo, de uma iteração para outra e de uma fase para a próxima, a ênfase sobre

as várias atividades muda, como mostra a figura 2, em que a cor preta indica grande ênfase,
enquanto a cor branca indica muito pouca ênfase. Na fase de concepção, o foco principal recai
sobre o entendimento dos requisitos e a determinação do escopo do projeto (planejamento e
levantamento de requisitos). Na fase de elaboração, o enfoque está na captura e modelagem
dos requisitos (levantamento de requisitos e análise), ainda que algum trabalho de projeto e
implementação seja realizado para prototipar a arquitetura, evitando certos riscos técnicos. Na
fase de construção, o enfoque concentra-se no projeto e na implementação, visando evoluir e
rechear o protótipo inicial, até obter o primeiro produto operacional. Finalmente, a fase de
transição concentra-se nos testes, visando garantir que o sistema possui o nível adequado de
qualidade. Além disso, usuários devem ser treinados, características ajustadas e elementos
esquecidos adicionados.
3.4 Extreme Project Management (XPM)
Recentemente surgiu uma visão diferenciada do gerenciamento de projetos, em razão

do novo ambiente dos projetos que foi discutido anteriormente. Essa nova visão trouxe um
modelo alternativo para lidar com os referidos projetos empresariais, e auxiliar aos que estão
envolvidos em projetos demais, que mudam rápido demais e tem recursos e verba de menos.
Chama-se Extreme Project Management, ou XPM, numa alusão aos conceitos e ferramentas
radicais adotadas. Uma das referências nesse assunto é Rob Thomsett, que em seu livro
Radical Project Management (2002), destaca vários dos conceitos abordados aqui, os quais
pratica há mais de 25 anos.
Como identificamos que as características encontradas no ambiente de múltiplos
projetos são muito similares aos descritos nessa abordagem ao tema de gerenciamento de
projetos, entendemos que vários conceitos e técnicas utilizadas pelo XPM podem ajudar
muito no gerenciamento de múltiplos projetos. Trataremos esse paralelo na seção de
Conclusões deste trabalho, sendo que o objetivo agora é descrever os principais conceitos e
modelo do Extreme Project Management.
Classificamos o XPM como um bem-vindo complemento aos conceitos apresentados
pelo PMI através do PMBOK, que tem foco mais no gerenciamento dos projetos tradicionais
e não aborda as questões e dificuldades do gerenciamento de múltiplos projetos. Na 3ª edição
do PMBOK, de 2004, o tema começa a ser discutido, porém no âmbito estratégico e tático,
desenvolvendo mais os temas de Gestão de Portfólio e de Programas, e a atuação do

Escritório de Projetos (PMO). Porém, ainda peca no aprofundamento das questões

operacionais que afloram no ambiente dos múltiplos projetos.
3.4.1 Conceitos XPM
O Extreme Project Management (XPM) é baseado em alguns valores fundamentais, que são:
o Participação – o gerenciamento de projetos é fortemente baseado na participação dos

stakeholders do projeto.
o Pró atividade – é um processo criativo e pró ativo de solucionar problemas.
o Transparência – tudo no projeto é compartilhado com todos os stakeholders.
o Foco externo – o foco do Gerente de Projetos é para fora do projeto, em direção aos
stakeholders.
o Confiança – a equipe do projeto é tratada como profissionais em que se pode confiar.
Além dos valores acima, o XPM aplica os seguintes conceitos:
o Contexto é mais importante do que conteúdo. O gerente de projetos no XPM deve
estar focado nos aspectos empresariais do projeto, em vez dos aspectos técnicos do
produto ou serviço que está sendo realizado pelo projeto. Deve se preocupar mais com
os stakeholders, com os objetivos e benefícios do projeto, impacto, riscos - enfim, o
contexto do projeto, ao invés do conteúdo, que é o aspecto mais técnico do projeto.
Quanto menos o gerente do projeto souber dos detalhes técnicos do projeto, melhor.
o Ciclo de vida do projeto inclui período pós-implantação. O que acontece após o

projeto é tão importante quanto durante. Tradicionalmente, o projeto termina na
entrega do produto ou serviço e o aceite do cliente, ou então logo após, com uma
avaliação das lições aprendidas. Porém, no XPM, o período de suporte à implantação e
a verificação dos benefícios faz parte do projeto, que só termina depois de um período
suficiente para verificar o resultado do projeto.
o O Gerente de Projetos é mais um facilitador e integrador do que um gerente. O

Gerente de Projetos que possui um forte componente técnico, tem uma tendência a
tomar decisões de planejamento de forma centralizada, intuitiva e unilateral, com
pouca interação com a equipe do projeto, que as vezes é somente comunicada das
estimativas de prazo, custo, riscos, etc. posteriormente. Para aumentar as chances de

sucesso de um projeto empresarial, o gerente de projeto deve mudar o foco do

planejamento técnico para a facilitação e integração do processo de planejamento, com
a participação efetiva dos stakeholders, como nas sessões RAP.
o Patrocinadores funcionam como “Gerentes Executivos de Projetos”. O papel do

sponsor, ou patrocinador, é ainda mais crítico para o sucesso de projetos empresariais.
No gerenciamento de projetos tradicional, a participação do patrocinador é mais
passiva e reativa. Normalmente, ele recebe relatórios técnicos do projeto e raramente
são alertados de problemas nos projetos a não ser quando ele se torna crítico, restando
pouco espaço para que o patrocinador possa ajudar. No XPM, os patrocinadores
devem ser quase que “Gerentes Executivos de Projetos”, devendo ter as seguintes
responsabilidades adicionais:
- participar das sessões de planejamento do projeto que definem escopo,
objetivos, benefícios e stakeholders;
- assistir ao Gerente de Projeto nas disputas políticas e de poder na organização
que influenciam o projeto;
- monitorar indicadores críticos do projeto, além das de custo e prazo.
o Planejamento por cenários em vez de macro-planejamento. Se não puder prever o

futuro com precisão, não o detalhe no cronograma, pois apenas cria falsas
expectativas. Em muitos projetos empresariais, o nível de incerteza é tão grande, assim
como o ritmo de mudanças, que fazer um planejamento detalhado de todas as fases do
projeto é um convite para o retrabalho intensivo e constante de replanejamento. O
modelo de planejamento tradicional foi criado numa época de poucas e lentas
mudanças, com envolvimento mínimo do cliente. Consiste em criar um plano inicial
detalhado para todas as fases do projeto (macro-planejamento), congelar os requisitos
definidos pelo cliente e seguir à risca o plano, tentando evitar ao máximo as
mudanças. O problema é que para o tipo de projeto que estamos discutindo, as
mudanças acontecem com ou sem a nossa permissão. A solução, nesse caso, é o
planejamento por cenários, onde eventos selecionados (o resultado de um subproduto,
um acordo, uma prova de conceito, a construção de um protótipo, etc.) definem o
caminho a seguir, ou qual cenário desenvolver. Essa técnica é especialmente
importante para projetos de Pesquisa & Desenvolvimento, onde não se sabe se o
resultado da pesquisa será o esperado. Deve-se então detalhar as atividades somente

até o primeiro evento, enquanto os cenários alternativos têm somente etapas genéricas
delineadas. Esse tipo de planejamento também é chamado de real-time planning, ou
planejamento em tempo real. Esse modelo tem sido utilizado com sucesso em ações
militares, substituindo o processo linear utilizado até a guerra do Vietnã. O nível de
incerteza e a dinâmica do projeto vai determinar o detalhamento do plano, o número
de cenários possíveis e o ritmo do acompanhamento do projeto. Normalmente, é difícil
detalhar mais do que 6 meses em projetos empresariais. Se os cenários estão
razoavelmente definidos, e houver possibilidade de estimativas para eles, deve-se usar
para referência para o projeto a estimativa do pior caso (o mais longo ou mais caro,
dependendo do foco do projeto). A dica é decidir qual cenário seguir o mais rápido
possível, para realinhar as bases de planejamento.
o Planejamento rápido e participativo. Em projetos empresariais é muito importante

encurtar ao máximo o ciclo de vida do projeto, pela própria natureza das necessidades
do projeto e do ambiente em que se encontra. A fase de planejamento é crucial em
qualquer projeto, devendo ser feita de forma completa. Porém, completude não é
sinônimo de demora e o conceito de planejar com a participação ativa da equipe levou
ao desenvolvimento de técnicas de planejamento rápido, que serão discutidas em
seguida. O conceito também é aplicado em sessões de planejamento estratégico
empresarial. O importante, no final, é que o planejamento não deve ser feito por uma
só pessoa, deve envolver os stakeholders principais e não deve conter o que não pode
ser previsto.
o Equipes virtuais em vez de equipes tradicionais. Os dias onde uma equipe era
mantida unida por anos, trabalhando junta no mesmo lugar, compartilhando
experiências, conhecimento, e desenvolvendo relacionamentos de confiança, amizade
e lealdade, estão contados, se já não acabaram. A realidade no novo ambiente de
negócios é a equipe formada por elementos diferentes de várias áreas da empresa,
muitas vezes de fora, dedicados parcialmente ao projeto, com pouca ou nenhuma
lealdade à equipe, confiança entre os membros limitada ao respeito técnico, pouca
troca de conhecimento, experiências, ou amizade, causada muitas vezes pela distância
física e meios de comunicação virtuais. Essa é a equipe virtual, que deve ser
gerenciada de forma diferente da equipe tradicional.

3.4.2 Técnicas e Ferramentas XPM
Dentre as várias técnicas e ferramentas criadas e adotadas no XPM, algumas se sobressaem e

são mais pertinentes ao nosso tema de múltiplos projetos:
o Sessões RAP. A necessidade de se planejar com a participação ativa da equipe de
forma rápida resultou nas sessões RAP, como são chamadas. Os stakeholders
participam de reuniões intensivas, sob a liderança do gerente de projeto, que podem
durar de um a cinco dias (dependendo do tamanho do projeto), para sair com o plano
do projeto aprovado por todos. Sem as reuniões de planejamento intensivo, é comum
levar até meses desenvolvendo o plano com participações pontuais e ao custo de
muitas revisões e alterações. Na necessidade de um replanejamento, por motivos de
mudança no ambiente, uma nova sessão deve ser convocada para fazer os ajustes no
plano. A duração do projeto é drasticamente diminuída, aumentando o alinhamento
das expectativas de todos e fortalecendo a comunicação. Esse método é muito
utilizado no desenvolvimento de sistemas de informação, sendo conhecida como JRP
(Joint Requirements Planning) e JAD (Joint Applications Design). Em conjunto com
ferramentas CASE (Computer Aided Software Engineering), o processo leva o nome
de RAD (Rapid Application Development), como descrito por Steve McConnell
(1996).
o “Réguas de Sucesso”. Um grande problema do gerente de projeto que deve ser
minimizado logo no início e acompanhado durante todo o projeto é o alinhamento das
expectativas do cliente, patrocinador e outros stakeholders importantes do projeto.
Definir os critérios de sucesso de um projeto é parte integrante dessas expectativas,
que também envolvem o escopo do projeto. Qual o foco que o gerente deve dar ao
projeto? Onde ele deve investir mais energia? Thomsett (2001) indica sete grupos de
critérios de sucesso que representam as expectativas gerais em relação ao projeto:
- A importância de satisfazer os stakeholders principais: identificar os
stakeholders que devem ser satisfeitos (geralmente o cliente e o patrocinador) e avaliar
a importância da satisfação pessoal deles para o sucesso do projeto; nem todos têm
que ficar satisfeitos para um projeto ser considerado de sucesso.
- Atendimento aos requisitos e escopo do projeto: o grau de importância de se
atender todos os requisitos para que o projeto seja considerado um sucesso; muitas
vezes, o projeto não atende o escopo completamente, mas é considerado um sucesso.

- Respeito ao Orçamento: o quão importante é ficar dentro do orçamento; critério

fácil de medir; nem todos os projetos têm um orçamento fixo.
- Respeito ao Prazo: o quão importante é ficar dentro do prazo; critério fácil de
medir; nem todos os projetos dão a mesma importância à questão de prazo.
- Valor Agregado (custo / benefício): o grau de importância dado ao valor que o
resultado do projeto agrega à organização cliente, com ênfase na verificação dos
benefícios trazidos pelo projeto. Os benefícios serão medidos e acompanhados após
entrega do produto ou serviço? É vital para considerar o projeto um sucesso verificar
os benefícios?
- Atendimento aos requisitos de Qualidade: o grau de importância que a qualidade
exerce no projeto; mensurável através de indicadores e métricas definidas.
- Satisfação da Equipe: o quanto a satisfação pessoal e profissional da equipe é
importante para o projeto. Sacrificar a equipe em favor de outros critérios é válido?
Traduzindo estes sete critérios para um conjunto de “réguas” onde se pode
posicionar um indicador do nível de importância que se quer dar a cada critério, pode-
se ter uma visão holística das expectativas de cada um para comparar. Veja a figura
abaixo. São quatro posições na escala da régua: Desligado, 25%, 50%, 75% e Ligado.
Desligado significa que o critério não é importante neste projeto. Ligado significa que
é crucial. Fases intermediárias traduzem o sentimento relativo entre eles. Obviamente,
deixar todos ligados não é realista, pois se for necessário decidir entre um critério e
outro, normalmente um se destaca mais. Esse é o indicador para o gerente do projeto
de onde ele não pode falhar se tiver que privilegiar algum critério. Serão também as
áreas mais bem acompanhadas nos relatórios e onde haverá mais controle.
Figura 3 – Exemplo de aplicação das “Réguas de Sucesso”

3.4.3 O Modelo de Gerenciamento XPM
No XPM, segundo Thomsett (2002), o gerenciamento envolve as etapas: Estudo de

Viabilidade, seguido da Aprovação e Priorização, Planejamento, Acompanhamento, Relato e
Controle de Mudanças e finalmente a Verificação dos Benefícios. Destaca-se a técnica de
planejamento chamada de RAP, mencionada anteriormente. Thomsett, baseado na aplicação
de mais de 500 sessões RAP em seus clientes, acredita que esta seja a forma mais efetiva de
planejamento, obtendo consenso nos temas críticos como escopo e objetivos do projeto, no
tempo mais rápido. Embora tenha objetivos similares, de oferecer uma referência para a
execução do projeto, a estrutura do plano resultante do RAP no XPM difere um pouco do
Plano do Projeto indicado pelo PMBOK, sendo as principais etapas:
1. Definir os critérios de Sucesso do projeto (de acordo com as expectativas dos
stakeholders)
2. Definir Escopo, Objetivos e analisar Stakeholders
3. Analisar os Benefícios esperados e o Valor Agregado do projeto
4. Definir critérios e requerimentos de Qualidade
5. Selecionar uma Estratégia de Desenvolvimento
6. Analisar Riscos
7. Desenvolver Lista de Atividades
8. Estimar esforço e prazo
9. Desenvolver o Cronograma com Alocação de Recursos
10. Desenvolver Retorno do Investimento (ROI)
Para o nosso contexto, vale destacar o item 5 - Selecionar uma Estratégia de

Desenvolvimento, a ser discutido em mais detalhes.
Após a definição do escopo, objetivos e dos stakeholders do projeto, o próximo passo
mais importante é analisar e escolher, junto com a equipe, a estratégia de desenvolvimento do
projeto. De que forma o projeto será desenvolvido afetará o desempenho, quanto à prazo,
custo e risco do projeto, mas não deve ser confundido com metodologia, que pode ser
aplicada em qualquer estratégia de desenvolvimento. Thomsett (2002) agrupa as estratégias
em diferentes tipos:
o Monolítica (ou Cascata - Waterfall)
Essa é certamente a estratégia mais antiga, sendo utilizada até hoje nos projetos
tradicionais, principalmente nas indústrias de engenharia e construção. Consiste na realização

do projeto em fases lineares e distintas, onde uma fase só começa quando a fase anterior
termina, como em uma linha de montagem. Vamos imaginar o projeto de desenvolvimento de
um novo produto. O planejamento só pode iniciar após todos os requisitos terem sido
levantados e analisados. A construção do produto, por sua vez, depende dos planos estarem
concluídos e aprovados. Terminado o produto por completo, pode-se então implementá-lo ou
disponibiliza-lo. (veja fig. 4).
Figura 4 – Estratégia Monolítica
Essa estratégia tem vantagens e desvantagens, que valem ser consideradas. A sua
maior vantagem é a simplicidade e facilidade de sequenciamento e acompanhamento, tendo
sido o pilar para a maioria das abordagens de planejamento das últimas décadas, adotado por
todas as ferramentas de gerenciamento de projetos e escolas de gerenciamento tradicionais.
As desvantagens, no entanto, são inúmeras para projetos no ambiente empresarial caótico e
orientado ao cliente de hoje em dia. Primeiro, o produto só estará disponível para os clientes
na fase final do projeto, dando muito pouca margem para manobras se as expectativas não
foram bem alinhadas. Segundo, é uma estratégia inadequada para resolver freqüentes
mudanças nos requisitos. As mudanças têm apenas duas alternativas no projeto. Ser ignorada,
ficando para um próximo projeto, ou obrigar a volta à fase ou fases anteriores. Permitir esse
retorno na estratégia monolítica põe em risco o próprio projeto, pois as fases finais se
estendem perigosamente, já que a cada mudança, o projeto deve voltar para as outras fases e o
retrabalho aumenta bastante. Essa questão leva ao terceiro problema, que é a longa duração
para concluir os projetos. A equipe começa a se questionar no meio do projeto se o mesmo vai
conseguir terminar com sucesso, tornando ainda mais difícil a tarefa do gerente de projeto de
motivar a equipe por um período muito longo. Quanto mais longo o projeto, mais exposto ele
fica às mudanças do ambiente e requerimentos do negócio, pondo em risco o seu término.

o Incremental, ou por Versão

Esta estratégia, de desenvolver o produto de forma incremental, por versões, procurar
eliminar algumas desvantagens da estratégia monolítica abreviando o ciclo de vida do projeto.
Ela se apresenta em duas variações: desenvolvimento seqüencial ou simultâneo.
No desenvolvimento seqüencial, o produto é decomposto em duas ou mais versões,
sendo que a primeira deve ser suficiente para fornecer os requisitos ou funcionalidades
fundamentais do produto, para uso imediato, deixando as versões seguintes para as
funcionalidades não essenciais ou suplementares. Isso não quer dizer que não seja necessário
conhecer os requisitos adicionais. Por exemplo, na construção de uma casa, na primeira
versão seriam entregues os quartos, a sala, cozinha e banheiros, essenciais para a moradia. Na
segunda versão, se constrói a garagem coberta, as dependências dos empregados e o muro. Na
terceira versão, é a vez da piscina, churrasqueira e a sauna. Todos nós já vimos isso acontecer.
A eficácia da estratégia vai depender da disposição do cliente em utilizar as versões
preliminares. Porém, ninguém pode negar a vantagem de se poder mudar algo no projeto da
piscina, por exemplo, antes de se começar a terceira versão da casa. É claro que o espaço da
piscina está planejado desde o início. Porém, nem sempre é aceitável particionar o produto em
versões.
Figura 5 – Estratégia por Versões
O desenvolvimento simultâneo é a tentativa de se abreviar ainda mais a duração do

projeto, trabalhando com equipes maiores divididas em múltiplas versões que são
desenvolvidas em paralelo, com o máximo de independência uma da outra. Porém, o custo de
gerenciamento e o risco aumentam nessa variação. É inevitável uma troca de dados mais
dinâmica entre as equipes, sendo que uma alteração em uma versão pode provocar impacto e

retrabalho nas outras versões. Essa alternativa requer uma atenção especial do gerente do
projeto, que deve ser mais experiente, além de um esforço maior de gerenciamento.
o Evolutiva, ou Fast Track

A estratégia evolutiva envolve a produção de uma versão ou protótipo de um produto
o mais rápido possível. Para acelerar o ciclo de vida do projeto, utiliza-se uma tecnologia ou
premissas que permitam uma degradação planejada do nível de qualidade do produto em sua
primeira entrega. No desenvolvimento de software, por exemplo, poderia ser a utilização de
uma plataforma de desenvolvimento menos nobre, como Visual Basic, porém mais rápida,
para uma entrega antecipada do sistema. Em seguida, o projeto sofre uma reengenharia
usando então outras plataformas, geralmente incluindo novas funcionalidades e alcançando o
nível de qualidade estabelecida anteriormente. Formas de acelerar o projeto podem incluir
adiar documentação, treinamento, ou diminuir a fase de testes. Estabilizando o produto depois
de lançado, pode-se substituí-lo no mercado. Devido ao aumento da competitividade, a
pressão aumenta cada vez mais para antecipar o prazo de lançamento, ou time-to market, dos
produtos, sendo essa estratégia uma das mais usadas atualmente. Embora essa estratégia seja
amplamente utilizada pela indústria de software, deve ficar claro, que o custo final é bem
superior, pois envolve suporte e redesenvolvimento ao mesmo tempo. Porém, cabe ao
empresário avaliar o retorno e o valor de ter o produto mais cedo no mercado.
Figura 6 – Estratégia Evolutiva
Evidentemente, o gerente de projetos pode misturar as várias estratégias para compor

aquela que melhor atende a necessidade do projeto, onde o limite é a sua imaginação. Por
exemplo, ele pode combinar a incremental, por versões com a evolutiva, acelerando ainda

mais a entrega da primeira versão, e enquanto ele a estabiliza, pode estar já desenvolvendo as
próximas de forma simultânea. E por aí vai.
Existe uma relação forte entre a estratégia a ser utilizada no desenvolvimento e o nível
de risco do projeto. Embora possa parecer que quanto mais alto o risco do projeto, mais
conservador devesse ser a estratégia escolhida, a recomendação é justamente o oposto.
Projetos de alto risco devem utilizar estratégias mais radicais, menos ortodoxas, justamente
para abreviar seu desenvolvimento e validar as premissas ou resultados o mais rapidamente
possível, evitando descobrir só no final do projeto que ele não vai prover os benefícios
esperados, após grande investimento.
3.5 Ambientes de Múltiplos Projetos
Quando se pensa em múltiplos projetos, podem vir múltiplas idéias sobre o assunto.
Afinal, se uma organização tem pelo menos alguns projetos para realizar, não teria ela então
múltiplos projetos? Do ponto de vista matemático, certamente. Porém, existem várias formas
de se tratar do tema. O PMI lançou em 2003 o modelo OPM3 que tem como objetivo
principal tratar do gerenciamento de projetos a nível organizacional, sendo uma ferramenta
para avaliar o nível de maturidade da organização no tema e prover um direcionamento para a
melhoria de seus processos no que se refere ao gerenciamento de projetos. O OPM3 veio
também como uma primeira iniciativa para suprir uma necessidade de se lidar com ambientes
de múltiplos projetos, que foge do escopo do PMBOK, padrão para gerenciamento de projetos
individuais. Embora não esgote o assunto e necessite de evolução e aprofundamento, ele
certamente introduz o conceito, apresentando o gerenciamento de projetos em três domínios
diferentes: portfólio, programas e projetos. São visões diferentes de como lidar com
projetos e múltiplos projetos. Vamos discutir a seguir como são essas visões e como se
relacionam com o gerenciamento de múltiplos projetos que discutimos neste trabalho. Para
situar a apresentação dos conceitos, apresentamos na figura 7 como esses três domínios se
relacionam dentro da organização.

Figura 7 – Portfólio, Programas e Projetos
Vale ressaltar, antes de avançarmos na discussão, que existe ainda um grande debate
no meio sobre os papéis e definições que cercam programas e portfólios, como descreve o
Program Charter do PPMS (2003). Existem correntes de pensamento diferentes, com grupos
que:
o acham que há pouca diferença entre projetos, programas e portfólios;
o acham que há realmente uma diferença entre projetos e programas, como é
definido no PMBOK, e que gerência de portfólio é muito similar a de programas,
exceto que portfólio lida com projetos não relacionados entre si, ou com uma
relação bem solta;
o concordam com a diferença entre projetos e programas e dividem a questão de
portfólio em dois campos: o tático, que é muito similar a abordagem de gerência
de programas, e o estratégico, que lida mais com a gestão de projetos, em um nível
mais alto na organização, decidindo sobre o alinhamento estratégico dos projetos
ao plano da organização.
No detalhamento das 3 dimensões mencionadas, resolvemos adotar os termos gestão,
para portfólio, gerência, para programas, e gerenciamento, para projetos, ilustrando as
diferenças de visão dos pontos de vista estratégico, tático e operacional, respectivamente.

3.5.4 Gestão de Portfólio
Portfólio é também um termo usado de forma diversa, tanto no meio de gerenciamento

de projetos, quanto em outras áreas, como finanças e arte. Embora exista relação entre os
significados, vamos procurar definir como o Portfólio de Projetos será referido neste trabalho.
Vamos iniciar com a definição clássica do PMI, encontrada no OPM3 (2003), que diz que o
“portfólio é uma coleção de projetos, programas e outros trabalhos que são agrupados para
facilitar o controle efetivo das ações sendo feitas para alcançar objetivos estratégicos. Os
projetos ou programas do portfólio não precisam ser interdependentes ou diretamente
relacionados.” Dye e Pennypacker (2000) consideram o portfólio como um “conjunto de
investimentos. Uma coleção de projetos que, na soma, constitui a estratégia de investimentos
da organização. A gestão de portfólio é a arte e a ciência de aplicar conhecimento,
competências, ferramentas e técnicas a uma coleção de projetos com o objetivo de atingir ou
superar as expectativas da estratégia de investimentos de uma organização.” Ficou claro
dentro dessas definições, que a gestão de portfólio é um ambiente de múltiplos projetos,
porém em uma dimensão estratégica, ligada à alta administração da organização, zelando pelo
cumprimento do seu plano estratégico. As perguntas que devem ser feitas nesse nível são,
como Burke (2004) coloca: “Estamos fazendo os projetos CERTOS? Estamos investindo nas
áreas CERTAS? Nós temos o suficiente dos recursos CERTOS?”
O recente interesse pela gestão de portfólio de projetos foi estimulado pelo ambiente
criado pós-estouro da bolha das ponto-com, onde o mercado se voltou para os tradicionais
valores de investimento mais seguro baseado em análise de retorno de investimento, segundo
Sommer (1998) e Woodward (2003). As empresas não podem mais se dar ao luxo de investir
em qualquer idéia atraente, mas sim nas mais lucrativas ou que tragam maior valor à empresa.
Portanto, os portfólios de projetos devem ser geridos com o mesmo rigor, equilíbrio e
liderança que as empresas estão acostumadas a dedicar aos seus portfólios de investimento
financeiro. A gestão de portfólio se preocupa em atingir o equilíbrio, o mix certo na carteira
de projetos em questões como risco e retorno, crescimento e manutenção, curto e longo prazo,
devendo ser dinamicamente revisada e atualizada num constante processo de tomada de
decisão. Novos projetos são avaliados, selecionados, priorizados, enquanto projetos existentes
podem ser acelerados, desacelerados, alterados e até cancelados. Recursos podem ser re-
alocados e novas prioridades colocadas.

Projetos devem competir por recursos dentro da organização, já que normalmente não
recursos disponíveis para todos os projetos que aparecem. É preciso procurar maximizar o
resultado geral ao invés de focar no sucesso individual de um projeto ou programa.
Empresas de pequeno e médio porte geralmente possuem apenas um único portfólio
de projetos. Porém, grandes organizações podem precisar se organizar através de múltiplos
portfólios, normalmente derivados de unidades organizacionais (diretorias, unidades de
negócios, etc.), mas os projetos e programas podem ser agrupados em portfólios por outros
critérios, como linhas de produtos. Nesses casos, os processos incluem iniciação e
encerramento dos portfólios.
Em falando de processos e fases, o OPM3 (2003) descreve os grupos de processos
envolvidos na gestão do portfólio de forma bastante similar aos de gerenciamento de projetos,
ordenando-os em 5 grupos: iniciação, planejamento, execução, controle e encerramento,
estendendo o mesmo framework que o PMBOK (2000) utiliza com projetos. Embora a
iniciativa seja válida, existe a percepção de que o paralelo com os processos de gerenciamento
de projetos foi um pouco excessivo, questão esta que está sendo endereçada no
desenvolvimento dos padrões específicos de programas e portfólio (PPMS). Outras linhas de
pensamento colocam as fases da gestão de portfólio de outra forma. O whitepaper da Pacific
Edge (2004) apresenta 4 grupos de processos que são compartilhadas de forma semelhante
por outros autores:
1) Inventário – Nesta fase é feito um inventário completo de todos os investimentos
do portfólio, entre projetos e outras iniciativas, de forma que se possa ter uma
visão completa da carteira atual e dos projetos candidatos a entrarem no portfólio.
As informações que devem ser compiladas aquis são no nível gerencial, de forma
resumida. Além do inventário de projetos é também feito um inventário de
recursos, humanos e materiais, com informações pertinentes como custo e
competências.
2) Análise – Com base no inventário, começa o processamento das informações do
ponto de vista de gestão empresarial, quando devem ser analisados os projetos sob
a luz dos critérios de seleção que a empresa adotar. As perspectivas podem ser:
Potencial de Realização, que julga a capacidade do projeto ser executado com
sucesso; Alinhamento Estratégico, que avalia como as iniciativas estão
contribuindo para a realização das metas e objetivos estratégicos; Equilíbrio, que
avalia o balanceamento e diversificação dos projetos dentro de um critério, que
pode baseado no Balance Score Card; e Valor, que mede os benefícios esperados

pela realização do projeto. Podem entrar outros elementos, como Urgência, que
geralmente faz par com Importância, como demonstrado por Dobson (1999), para
se chegar ao um índice numérico de mérito do projeto.
3) Otimização – O objetivo desta fase é maximizar os benefícios do portfólio. É um
processo iterativo que revisa continuamente os critérios descritos acima para
manter o portfólio equilibrado, aderente ao plano estratégico, realizável e
agregando o máximo de valor. É nesta fase que as decisões de seleção de projetos
são tomadas e alterações nos projetos do portfólio são recomendadas.
4) Mobilização – fase em que as decisões tomadas na fase anterior são levadas a
cabo e comunicadas ao nível de projetos, iniciando, alterando e cancelando
projetos. Recursos são alocados e re-alocados, e medições sobre a situação são
feitas.
Uma recomendação importante feita por Cooper e Edgett (2001) é quanto ao número
certo de projetos no portfólio. É comum ter um número excessivo de projetos, o que prejudica
a distribuição de recursos e põe me risco a realização dos mesmos. Nesse ponto é fundamental
poder fazer o planejamento de capacidade de sua organização em função dos recursos
disponíveis.
Embora a gestão de portfólio ofereça inúmeros benefícios, deve-se ter em mente que
existem alguns pontos potencialmente negativos para tomar ciência, como a tendência de
depender de uma ferramenta de análise e processamento para tomar decisões e o aumento do
nível de burocratização da organização.
3.5.5 Gerência de Programas
O ambiente de múltiplos projetos que compõe os programas se dá a nível tático-

operacional dentro da organização. É ainda uma área de estudo emergente que não encontra
uma unanimidade quanto à sua definição nem quanto á sua gerência. Vamos então iniciar pela
definição do termo “programa”. O OPM3 (2003) define um programa como um “grupo de
projetos relacionados e gerenciados de uma forma coordenada para obter benefícios e controle
que não seria possível gerenciando os projetos de forma independente,” e complementa que
“programas podem incluir elementos de trabalho fora do escopo dos projetos do programa.”
Thiry (2000) segue na mesma linha, definindo um programa como “uma coleção de ações de
mudança (projetos e atividades operacionais) agrupada propositalmente para realizar
benefícios táticos ou estratégicos para a organização.” Já Dobson (1999) se refere ao

conjunto de projetos interdependentes, que caracteriza um programa, de “portfólio”, e trata

desse portfólio como se fosse um grande projeto, na tentativa de simplificar a estratégia de
seu gerenciamento. Realmente, nem sempre é fácil distinguir entre o que é um programa e um
grande projeto. Qual a diferença entre um programa com vários projetos interligados e um
grande projeto dividido em subprojetos? Muitas vezes não é claro e ambos os termos são
usados em situações similares. Porém, se seguirmos com a definição do PMI, podemos
distinguir programas de projetos por alguns fatores básicos:
a) Programas podem incluir atividades operacionais que não são partes de nenhum
projeto, ou seja, podem incluir trabalho rotineiro, mais caracterizado como processuais,
enquanto que projetos não têm essa característica. Por exemplo, um programa pode ser um
novo modelo de automóvel, que contem vários projetos relacionados, como o
desenvolvimento de um protótipo, preparação da linha de produção, campanha de
lançamento, etc. Sendo o carro lançado, o programa não necessariamente é encerrado,
podendo continuar verificando os resultados do novo modelo, acompanhando as vendas,
dando suporte, etc. por um longo período até a transição definitiva para os processos
administrativos da empresa. Mesmo durante o desenvolvimento, atividades de suporte ao
programa, não pertencentes a nenhum projeto específico, podem existir.
b) Programas têm ciclos de vidas distintos dos projetos. Enquanto um projeto termina
na conclusão de suas atividades relacionadas, entregando o produto ou serviço que se propôs a
realizar, o programa vai distribuindo os benefícios durante o seu ciclo de vida, na medida em
que seus projetos vão se realizando e encerrando, enquanto outros se iniciam.
c) Um programa não tem necessariamente uma data final para terminar quando ele se
inicia, ao contrário de um projeto. Um programa pode ser estendido indefinidamente,
enquanto os benefícios a que se propõe continuam sendo desejados, como o Programa Fome
Zero, do governo federal. Enquanto não acabar com a fome no país (é possível?) ele pode ser
sustentado.
Se seguirmos essa definição, fica mais claro distinguir a diferença não só entre
programas e projetos, mas também entre a gerência de programas e o gerenciamento de
múltiplos projetos, embora seja inegável que ambos são ambientes legítimos de múltiplos
projetos. Algumas destas diferenças chaves podem ser resumidas abaixo:
o A gerência de programas foca no sucesso de se atingir um objetivo maior que está
ligado ao plano tático-estratégico da organização, sendo que os projetos
envolvidos têm uma relação forte entre si e contribuem para o mesmo objetivo. Já
o gerenciamento de múltiplos projetos não tem essa característica, sendo os

projetos independentes um do outro podendo servir a objetivos totalmente

diferentes, sendo apenas gerenciados de forma simultânea por outros motivos que
serão discutidos na próxima seção.
o Os programas têm um responsável, o Gerente do Programa, que coordena as
diretrizes do mesmo e supervisiona o andamento dos projetos e o trabalho dos
gerentes desses projetos. É comum haver também um conselho diretor para um
programa, que exerce atividades de governança, o que não acontece com o
gerenciamento de múltiplos projetos, que tem um só gerente de projetos
encarregado de vários projetos simultaneamente.
o Como diz Thiry (2000), gerenciamento de projetos tem como objetivo atingir a
entrega de vários resultados com o mínimo de recursos possíveis, enquanto que a
gerência de programas se concentra em conseguir o máximo de benefícios com os
recursos disponíveis. Podemos dizer que projetos focam na eficiência enquanto
programas na eficácia.
3.5.6 Gerenciamento de Múltiplos Projetos
Muitas técnicas e metodologias foram desenvolvidas para uso em grandes projetos, o

que é compreensível, já que estes detêm o maior grau de risco, maior dificuldade de
gerenciamento e têm a maior chance de ter problemas, de acordo com Parth (1998). Contudo,
é muito mais comum no mundo empresarial que o gerente de projetos esteja envolvido em
vários projetos menores, de forma simultânea, em fases diferentes de seu ciclo de vida.
O gerenciamento de múltiplos projetos em uma organização com estrutura matricial
ainda é mais crítica, com mostra Knutson (1994), pois o gerente de projetos tem que atuar em
mais de um projeto em um ambiente onde tipicamente ele não tem muita autoridade oficial.
Isso torna tudo mais difícil e a disputa por recursos precisa ser travada sem que vire uma
batalha política de poder.
Como colocam Dye e Pennypacker (2000), é comum confundir ou caracterizar o
gerenciamento de múltiplos projetos, que compartilha recursos durante o seu ciclo de vida,
com gestão de portfólio, como alguns também chamam um programa de projetos relacionados
de portfólio. O gerenciamento de múltiplos projetos é simplesmente o gerenciamento de
vários projetos independentes com seus objetivos próprios que por necessidade são obrigados

a compartilhar recursos, que podem estar ou não diretamente alinhados com a estratégia de
investimento a longo prazo da organização.
Diferentemente do ponto de vista estratégico e tático da gestão do portfólio e dos
programas, o gerenciamento de múltiplos projetos que pretendemos discutir aqui envolve o
aspecto operacional, do ponto de vista do gerente e das equipes dos projetos. Vamos
apresentar várias características e fatores que influenciam o ambiente de gerenciamento de
múltiplos projetos, a forma como o tema tem sido abordado e os elementos complementares
ao assunto.
Na abordagem de Kerzner (2001) ao tema, ele acredita que a organização deve se
adaptar nos seguintes aspectos para conseguir gerenciar múltiplos projetos com sucesso:
o Priorização – cuidado com o processo de priorização de projetos. Se há um sistema
que prioriza projetos, o gerente de múltiplos projetos pode favorecer os de maior
prioridade comprometendo outros, sendo que nem todos os projetos necessitam de
uma priorização. Priorização por si só já é um processo que consome tempo e esforço.
o Mudanças de Escopo – mudanças de escopo em múltiplos projetos põem em risco os
mesmos, sob o argumento que o tempo gasto por um gerente de projeto administrando
a mudança em um projeto pode limitar ou prejudicar a sua atuação nos outros projetos.
A alternativa de acomodar mudanças somente através de novos projetos de evolução
pode não ser satisfatória para alguns tipos de projetos, como vimos anteriormente.
o Metodologia – as metodologias desenvolvidas para o gerenciamento de múltiplos
projetos devem ter um grau de liberdade, o que não deve ser confundido com não
seguir uma metodologia. O cuidado deve ser no que diz respeito a evitar o excesso de
burocracia muitas vezes imposto por rígidas metodologias.
o Ciclo de Vida – uma coisa é certa no que se refere a se gerenciar múltiplos projetos:
evitar que o mesmo gerente de projetos seja responsável por projetos na mesma fase
do ciclo de vida. É fato que projetos demandam o tempo do gerente de forma diferente
dependendo da fase em que se encontra em seu ciclo de vida. Ou seja, o ideal é que os
projetos desse gerente não iniciem ao mesmo tempo.
o Estrutura Organizacional – é provável que a empresa que adota o gerenciamento de
múltiplos projetos tenha uma estrutura organizacional do tipo matricial fraca, já que os
gerentes de projetos são mais generalistas do que especialistas e parte da
responsabilidade cai nas lideranças funcionais.

Agrupamento por Tipos de Projetos
Cleland e Ireland (2000) acreditam no gerenciamento de múltiplos projetos como

forma de otimizar os recursos e obter ganhos de escala utilizando processos e metodologia
padronizada de acordo com afinidades entre os projetos. Geralmente de porte menor, pela sua
maior simplicidade, os projetos podem ser agrupados por alguns princípios básicos, descritos
a seguir:
o Prioridade – projetos agrupados por prioridades semelhantes estão menos suscetíveis
ao risco do gerente dar pouca atenção e recursos para projetos menos prioritários em
seu grupo de projetos. A idéia é que se houver priorização de projetos, estes devem ser
agrupados com prioridades semelhantes.
o Porte – projetos de um mesmo grupo devem ter tamanhos similares, dentro da medida
que foi aplicada, se duração, valor ou recursos necessários. Misturar projetos de portes
diferentes pode desequilibrar a distribuição de recursos entre eles. Os projetos mais
indicados para sofrerem gerenciamento múltiplo são os de curta duração com poucos
recursos envolvidos.
o Ciclo de Vida – projetos agrupados devem ter o mesmo ciclo de vida, facilitando a
adoção de uma mesma metodologia para gerenciá-los, embora idealmente eles devam
estar em fases diferentes do ciclo.
o Complexidade – os projetos mais indicados para se gerenciar de forma compartilhada
devem ter relativa simplicidade, evitando misturar projetos muito complexos com
outros mais simples, pois provavelmente o esforço do gerente será direcionado para os
complexos.
o Tecnologia – projetos gerenciados de forma simultânea devem compartilhar também a
mesma tecnologia, maximizando os esforços com competências semelhantes.
Projetos em Pequenas Empresas

O ambiente de gerenciamento de projetos em pequenas empresas tem características
próprias que afetam o papel do gerente de projetos. Kerzner já identificava em 1982 em seu
livro Project Management for Executives, as diferenças entre os ambientes de gerenciamento
de projetos de grandes e pequenas empresas, como:
o O gerente de projetos tem vários chapéus, sendo muitas vezes gerentes funcionais
também;

o O gerente de projetos está envolvido em múltiplos projetos, com prioridades

diferentes;
o Os recursos para os projetos são mais limitados;
o Maior necessidade para habilidades interpessoais;
o Maior vulnerabilidade ao fracasso de um único projeto;
o Pode haver controle financeiro mais rígido, porém com técnicas menos sofisticadas;
o Maior interferência da alta administração nos projetos, devida à maior proximidade
com a gerência operacional;
o Resolução de conflitos pode ser mais fácil ou mais difícil, sendo mais afetado pela
personalidade dos envolvidos;
o O número de projetos compartilhados pela equipe é maior.
Pode ser mais difícil implementar o gerenciamento de projetos em empresas pequenas
pelos papéis múltiplos que as pessoas devem assumir. É mais provável também que o gerente
de um projeto seja recurso de outros projetos, alternando posições e papéis de acordo com a
situação e o projeto. Quando o gerente funcional veste o chapéu de gerente de projetos, deve-
se ter uma atenção especial, pois a tendência é que ele escolha os melhores recursos para o
seu projeto, potencialmente desguarnecendo outros projetos. È difícil ter o equilíbrio de
dedicação tanto no plano horizontal (projetizado) quanto no vertical (funcional) quando os
gerentes vestem ambos chapéus.
Planejamento da Capacidade
Na medida em que as organizações amadurecem no gerenciamento de projetos, os

benefícios de se conseguir realizar mais em menos tempo e com menos recursos começam a
aparecer. No entanto, a grande questão é saber quanto mais de trabalho pode uma organização
ou equipe realizar com os recursos que dispõe levando em consideração as restrições a que
estão sujeitas? Esse conceito de conhecer e planejar a capacidade de realização, também
conhecido como capacity planning, é importante quando se discute o gerenciamento de
múltiplos projetos. Kerzner (2001) alerta que normalmente as empresas costumam planejar o
seu “poder de fogo” apenas em termos de recursos humanos, fazendo uma previsão de
crescimento de mão de obra em razão dos recursos necessários previstos nas propostas de
projetos externos e requisitos de projetos internos. No entanto, ele sugere um método que
envolve outras dimensões de recursos. Após a seleção dos projetos que serão incluídos no
portfólio da empresa, é necessária a identificação distinta dos objetivos do projeto em termos
empresariais (negócios) e técnicos. Desta forma fica mais fácil identificar restrições de ambas

correntes. Em seguida é importante identificar o objetivo principal do plano do projeto, não

confundindo com o objetivo do projeto. Organizações mais maduras sabem que o foco deve
ser em uma vertente do plano: menor prazo, custo, ou risco? As menos maduras tem a idéia de
que podem conseguir todos esses objetivos igualmente, o que é irreal. Determinando o foco,
as restrições correspondentes vão aparecer com mais clareza para se chegar à capacidade de
realização que ela permite. Um projeto pode ter vários caminhos críticos de naturezas diversas
que não seja somente de prazo. Restrições envolvendo disponibilidade de pessoas,
instalações, fluxo de caixa, e até tecnologia podem prover dimensões diferentes da capacidade
de realização da organização em determinado momento. Por exemplo, a empresa pode ter
recursos humanos suficiente para realizar vários novos projetos, mas não ter capital de giro
para financiar o desenvolvimento de nenhum outro projeto que precise de investimento.
Não se pode esquecer, como Whitten (2002) faz questão de alertar em seu artigo de
título original, 1 + 1 + 1 = 2, que as equipes pagam um preço no que se refere à sua
produtividade quando estão envolvidas em múltiplos projetos. Normalmente, a produtividade
de uma pessoa é maior quando ela está focada em uma única atividade. Ele recomenda que as
equipes devam ser alocadas tempo integral em projetos singulares, permitindo que os
executores foquem predominantemente em uma atividade de cada vez Porém, esse luxo
muitas vezes não é possível no ambiente competitivo de hoje.
Modelos de Competência
Outro fator importante de considerar no ambiente de gerenciamento, também ligado à
capacidade de realização, o que afeta a condição de se gerenciar múltiplos projetos são os
modelos de competência existentes nas organizações. Kerzner (2001) defende a utilização
desses modelos para o conhecimento do material humano que se tem para trabalhar na
organização e para a evolução e crescimento de seus recursos humanos.
Os recursos humanos devem ter suas competências mapeadas de acordo com as
necessidades da empresa e das atividades que exercem. Por exemplo, gerentes de projetos
devem desenvolver habilidades técnicas, gerenciais e de processos. Uma vez definidos os
modelos de competência, fica muito mais eficiente o uso do tempo de trabalho, com menos
retrabalho e distrações. Facilita direcionar a capacitação para suprir as deficiências
localizadas, permitindo a customização e personalização dos treinamentos. É o caminho para
a excelência, e aumenta a capacidade de realização, dotando as equipes de profissionais mais
completos e flexíveis. O resultado: mais projetos simultâneos.

3.5.7 Gerenciamento do Tempo
O tema de gerenciamento de tempo é fundamental na discussão de gerenciamento de

múltiplos projetos. Para muitos, tempo é um fator de restrição. Aprender a gerenciar bem o
tempo é a arte de transformá-lo em recurso. Porém, é um recurso que será consumido, sendo
bem usado ou não. Kerzner (2001) descreve fatores importantes que influenciam o bom
gerenciamento do tempo, que vamos discutir aqui, que são: os ladrões de tempo, reuniões, a
questão das horas extras, ciclos de energia no dia e na semana, stress, produtividade e
delegação.
O gerente de projetos deve aprender a ter disciplina no gerenciamento de seu próprio
tempo. Se esse fator é crítico para o gerente de um projeto, ele é vital para o gerente de
múltiplos projetos. O gerente de projetos inexperiente normalmente tende a trabalhar longas
horas extras sistematicamente, achando que é a única forma de conseguir dar conta de todo o
trabalho. Com o tempo e conhecimento, ele deve começar a aprender a colocar em prática
princípios eficazes de gerenciamento de tempo e delegar parte do trabalho para outros.
Existem vários elementos no ambiente de projetos que “roubam” o tempo dos gerentes
e da equipe, os chamados “ladrões de tempo”. Alguns desses elementos são:
o Retrabalho
o Decisões adiadas
o Comunicação fraca
o Telefonemas
o Espera por pessoas
o Visitas inesperadas
o Interrupções constantes
o Falta de delegação
o Sistema falho de recuperação de informações
o Falta de apoio administrativo
o Excesso de emails
o Informação mal formatada
o Muitas pessoas trabalhando em um ambiente pequeno
o Excesso de conversa casual no escritório
o Excesso de mudança
o Excesso de reuniões
o Falta de direcionamento
o Desorganização
o Excesso de deslocamentos
o Falta de ferramentas adequadas
o Excesso de burocracia
o Excesso de carga de trabalho, muitos projetos

Com tantos elementos que desperdiçam o nosso tempo útil de trabalho, é importante
tomar algumas precauções para não diminuir a produtividade além da perda normal, que é de
20% a 30%. Assim, das oito horas de trabalho, a média de produtividade é de seis horas úteis
de trabalho. O ambiente pode ser mais ou menos favorável, permitindo que os fatores
mencionados acima “roubem” menos ou mais tempo dos envolvidos no projeto. É sabido que
a produtividade também cai no cumprimento de horas extras.
Outro fator importante que impacta no desempenho é o stress que envolve o gerente e
equipe do projeto. Os sintomas principais são: sentimento de cansaço, depressão, exaustão
física e mental, aprisionamento, impotência, indecisão, ansiedade, entre outros. Embora o
stress em projetos é inevitável e muitos gerentes gostam de trabalhar com uma certa pressão,
o excesso de stress ou longos períodos sob pressão tem um efeito muito negativo no
desempenho geral dos envolvidos. No ambiente de múltiplos projetos, a tendência é aumentar
o nível e o impacto do stress, o que pode ser verificado nos resultados de nossa pesquisa de
campo apresentada neste trabalho.
Pesquisas feitas com várias indústrias mostram que existem picos de energia durante a
jornada de trabalho, influenciados por elementos como fadiga, concentração, volume de
trabalho, disposição e ansiedade. Normalmente são dois picos, um pela manhã, entre 9 e 11, e
outro à tarde, entre 14 e 16 horas, com algumas variações entre indústrias. O nível de energia
no pico da manhã geralmente é maior do que o da tarde. Similarmente, existe um ciclo
também para os dias da semana, onde o pico de energia aparece nas 4as feiras, seguidas das
5as. Reconhecer os picos de energia das pessoas envolvidas e registrar particularidades
pessoais ajuda na questão da produtividade, se direcionar o trabalho mais crítico para os
momentos de pico.
Reuniões são inevitáveis e muito importantes para o gerenciamento do projeto. Porém,
cuidados especiais devem ser tomados para que não virem “ladrões de tempo”. O gerente do
projeto é responsável por zelar que as reuniões sejam as mais produtivas possíveis, estando
alerta para não se estender em itens triviais. Não deve esquecer de enviar uma pauta
antecipada aos participantes, nem deixar de convidar as pessoas que tem autoridade para
decidir as questões em discussão. A quantidade de reuniões não deve ser nem insuficientes
nem excessivas.
O maior desafio de um gerente de projetos muitas vezes é conseguir delegar de forma
eficiente aos seus subordinados. Quanto mais ele consegue delegar, dentro da capacidade de
realização de suas equipes, mais apto ele estará para gerenciar múltiplos projetos. Quem tem

dificuldade de delegar com autoridade, praticando o chamado empowerment, não consegue

gerenciar mais de um projeto, e possivelmente terá dificuldades com o próprio, ficando
sobrecarregado e sem tempo para mais nada.
Além de todos os problemas e desafios mencionados acima em relação ao
gerenciamento de tempo, alia-se ao fato de que na maioria das organizações, os gerentes de
múltiplos projetos ainda dividem seu tempo com trabalho processual de seus cargos
funcionais, como atesta Dobson (1999). A estrutura organizacional mais comum ainda é a
hierárquica funcional, com algumas tendências para matricial fraca. Nessa estrutura, as
pessoas estão muito ligadas às suas funções corporativas e gastam boa parte de seu tempo
diário com atribuições ligadas ao seu cargo, como gerenciar um departamento, ou resolver
questões do dia a dia da empresa. Dobson sugere que cada um faça um registro diário
detalhado de como o seu tempo é gasto durante uma ou duas semanas para descobrir quanto
tempo se tem para gastar com os projetos. Ele separa o tempo em três categorias: a) deveres
rotineiros, que são dos tipos de tempo-fixo (reuniões marcadas, entrega do relatório semanal
do departamento, etc.) ou tempo-variável (podem ser feitas na data mais adequada, com
flexibilidade) e compõe as atividades rotineiras do escritório; b) gerenciamento de crises ou
problemas, que são os incêndios que têm que ser apagados imediatamente, interrompendo o
seu fluxo normal de trabalho, e as questões inesperadas que aparecem diariamente e devem
ser resolvidas; e finalmente a c) reserva estratégica, que é o tempo que se tem para
planejamento e organização de seu trabalho. É nessa reserva que muitas vezes os projetos têm
que ser gerenciados. Se sua reserva é apenas 10 a 20% de seu dia, certamente horas extras
serão rotina se existem projetos para serem gerenciados, mesmo os pequenos. O desfio passa
a ser maximizar o seu tempo de reserva estratégica para fazer o gerenciamento dos projetos,
usando todas as técnicas e ferramentas para minimizar os outros dois tipos. Poucos são os
profissionais que são totalmente dedicados aos projetos. Mesmos os que têm o cargo oficial
de Gerente de Projeto e sua função principal seja o gerenciamento de um ou mais projetos,
eles precisam participar do sistema funcional burocrático da empresa, como nas relações com
seus superiores e seguindo procedimentos processuais da empresa. Além do mais, não estão
imunes às emergências inesperadas e aos “ladrões de tempo”.

3.6 O Método da Cadeia Crítica
Não podemos deixar de abordar uma outra abordagem de gerenciamento de projetos

que tem forte apelo para o tema de múltiplos projetos, que é o gerenciamento pelo Método da
Cadeia Crítica, derivado da conhecida Teoria das Restrições, ou TOC (Theory of Constraints).
Vamos descrevê-lo a seguir, mas primeiro vamos discutir o conceito por trás do método.
3.6.1 A Teoria das Restrições
Desenvolvido pelo físico Eliyahu M. Goldratt, a TOC se baseia no conceito de

melhoria do desempenho, ou throughput, utilizando ferramentas e processos para focar em
elementos, ou “restrições”, que impedem e restringem a possibilidade de melhoria. Muito
popular na indústria de manufatura, o conceito passou a ser aplicado ao gerenciamento de
projetos recentemente, com bons resultados na diminuição das durações de projetos e
aproveitamento dos recursos. Em outras palavras, a TOC descreve que todo sistema tem uma
ou mais restrições, que é o gargalo que impede o resultado, ou desempenho, de melhorar. As
restrições podem ser de recursos, físicos ou políticos. No caso de projetos, geralmente são de
recursos. A idéia é que o todo deve melhorar, e os elementos devem ser somente bons o
suficiente para manter o desempenho no seu máximo, o que geralmente é limitado pelo
elemento restritivo. Como descreve Newbold (2002), de nada adianta investir na otimização
de outros elementos que ficam ociosos, além do que restringe o desempenho total. São cinco
os passos recomendados para se atingir a melhoria desejada:
1) Identificar a restrição, também chamada de ponto de alavancagem;
2) Alavancar a restrição, explorando ao máximo o seu potencial. Pode ser através de
treinamento, melhoria de processos ou simplesmente minimizar o desperdício atual
do recurso, tornando-o mais produtivo.
3) Ajustar os outros elementos e processos para apoiar o ponto de alavancagem. Mantê-
los prontos e produzindo o suficiente para alimentar e maximizar o desempenho do
elemento de restrição.
4) Elevar a restrição. Significa eliminar a restrição, torná-la um elemento não restritivo.
Pode ser aumentando os recursos disponíveis, terceirizar, ou investir mais na
atividade para eliminar o gargalo.
5) Melhoria contínua. Uma vez eliminada a antiga restrição, o que acontece é que uma
nova vai aparecer. Então, volte ao passo 1.

3.6.2 CCM vs. CPM
O Método da Cadeia Crítica (CCM) é uma extensão do Método do Caminho Crítico

(CPM). Na verdade, se não houvesse recursos limitados ou restrições, a cadeia crítica seria
igual ao caminho crítico do projeto. Porém, como isso normalmente não acontece, a cadeia
crítica inclui outras atividades, levando em conta não só as dependências relativas ao tempo,
mas também levando em consideração as dependências de recursos, como mostra Visitacion
(2000).
O CCM também se destaca quando o nível de incerteza na realização das atividades é
mais alto. O CPM praticamente não leva em conta possíveis variações ou flutuações nos
prazos e durações das atividades. As durações são calculadas normalmente como as mais
prováveis, muitas vezes de forma agressiva e otimista, com risco dos prazos não serem
cumpridos (como não são em 50% das vezes). Coloque em seqüência várias dessas atividades,
resultando no caminho crítico do projeto, e o que você tem como resultado é o risco
multiplicado, com grandes chances do projetos atrasar. Se for colocada uma folga embutida
na duração das atividades, para o caso de imprevistos ou riscos detectados, como é prática
comum nos processos de estimativa de muitas empresas, nos deparamos com dois fenômenos
do comportamento humano que geralmente anulam essa precaução: a Lei de Parkinson e a
Síndrome do Estudante. A Lei de Parkinson diz que a pessoa tende a usar todo o tempo que
está disponível a ela para realizar o trabalho. Ou seja, se tiver mais tempo, ela simplesmente o
usará e será menos produtiva. É como sair de um quarto pequeno para um quarto grande com
os mesmos pertences – o espaço maior será todo ocupado, da mesma forma. Assim é com o
tempo. A Síndrome do Estudante se refere à situação em que quando o estudante tem muito
tempo para estudar para uma prova, ele normalmente inicia devagar, adia, procrastina, até o
último limite, onde então ele intensifica o ritmo de estudos até a última hora da prova.
Portanto, não adiantou ter tido mais tempo para estudar. Assim, colocar folgas embutidas nas
durações calculadas no CPM não protege o prazo final do projeto. Já na cadeia crítica, essas
folgas que são calculadas para cada atividade se somam no que são chamados de pulmões, ou
buffers do projeto. Em vez de colocados em cada atividade, os pulmões são distribuídos pelo
projeto de forma ordenada. As folgas provenientes das atividades da cadeia crítica são
colocadas ao final da última atividade crítica, formando o pulmão do projeto, que protege a
data de entrega do projeto. Se forem de atividades que alimentam uma atividade integrante da
cadeia crítica, são colocadas antes da entrada da cadeia crítica, formando pulmões de
alimentação, ou feeding buffers, que protegem as atividades pertencentes à cadeia crítica.

Possíveis variações nas atividades são aceitas e passam a consumir parte dos pulmões
que estão reservados. Neste caso, o acompanhamento do desempenho do cronograma não é
tanto pelo cumprimento do prazo de cada atividade do projeto, mas sim por quanto dos
pulmões já foram usados, em comparação com quanto do projeto já foi realizado.
3.6.3 CCM no Ambiente de Múltiplos Projetos
Em um ambiente de múltiplos projetos, seja na realização de programas ou apenas de

vários projetos simultaneamente, o CCM pode ser muito útil, como mostra Patrick (1998).
Quando se têm vários projetos, o normal é se ter várias atividades que requerem a sua atenção
ao mesmo tempo. O impulso natural é de iniciar todas o mais cedo possível, na percepção de
que, fazendo assim, se terá mais tempo para conseguir terminá-las no prazo. Essa situação
leva ao que se chama de multitasking, ou um comportamento multitarefa, onde a pessoa faz
um pouquinho de uma atividade, muda para outra, depois volta e fica se dividindo entre as
várias atividades que está alocado. Como todas seguem a política do início mais cedo, vira um
caos. Na verdade, esta prática deve ser evitada ao máximo, pois na troca de atividades, perde-
se o foco e a concentração, levando-se mais tempo para se concentrar na outra atividade até
ganhar um ritmo bom, quando por sua vez a atividade é interrompida também para dar
seqüência a outra ainda. Além do tempo maior que acaba sendo necessário para terminar a
primeira atividade, outras que podem depender desta não podem começar, o que acaba
atrasando o projeto e frustrando a percepção de que terminaria mais cedo se começasse mais
cedo. O melhor seria fazer uma atividade de cada vez, passando de uma para outra quando a
primeira acabasse. Não quer dizer que não se pode realizar mais de um projeto ao mesmo
tempo, mas que não devemos alocar o mesmo recurso em mais de uma atividade ao mesmo
tempo. Com o uso dos pulmões, se torna viável aguardar o início de uma segunda atividade
enquanto a primeira na lista estiver sendo feita. Desta forma, a primeira é liberada de vez
rapidamente para dar seqüência ao projeto, enquanto o recurso ataca a segunda atividade.
Com múltiplos projetos, este é um grande desafio.
Outro grande desafio é a implantação do Método de Cadeia Crítica nas organizações,
de acordo com Newbold (2004), pois para funcionar bem, deve ter o envolvimento e forte
patrocínio superior e toda a empresa entender e mudar fortes culturas. Se mudar hábitos já é
difícil, culturas organizacionais nem se fala.

4 ANÁLISE DE RESULTADOS
4.1 Pesquisa de Campo I
Neste capítulo serão analisados os resultados da pesquisa de campo realizada por meio
do questionário apresentado no Anexo I.
4.1.1 Avaliação Geral da Pesquisa I
Os participantes da pesquisa foram extraídos do público que assistiu à palestra realizada

no 2º Encontro Nacional de Profissionais em Gerenciamento de Projetos, que ocorreu nos dias
24 e 25 de junho deste ano na sede da FIRJAN, no Rio de Janeiro. O evento recebeu cerca de
1.500 profissionais, entre participantes das palestras e painéis e visitantes da Exposição. O
fato de a pesquisa ter sido realizada com profissionais de gerenciamento de projetos já pré-
selecionados pelo evento, os colocou como elementos altamente representativos do mercado
alvo de nosso trabalho.
Este fórum possibilitou uma intensa troca de experiências com profissionais que se
destacam na área, bem como a discussão sobre melhores práticas, tendências em
gerenciamento de projetos e a análise de casos reais, vivenciados por importantes
organizações.
Os questionários, distribuídos para um público de cerca de 250 participantes, tinham,
portanto, a possibilidade de alcançar esse número de indivíduos com atividades diretamente
ligadas a projetos. Considerando-se o retorno efetivo de 129 questionários, contendo dados de
informantes que se identificaram como atuantes em atividades de projetos indicam que a
amostra obtida representou 51% dos informantes potencialmente habilitados a fornecerem
informações.
Com relação ainda ao público alvo, a palestra favoreceu a concentração de profissionais
especializados. Profissionais e altos executivos atuantes em empresas que trabalham com
projetos, em especial das indústrias de:
o Telecomunicações
o Tecnologia
o Energia
o Petróleo e Gás
o Construção

o Serviços
o Farmacêutica
4.1.2 Tabulação e Análise dos Dados – Pesquisa I
Os 129 questionários recebidos foram inicialmente examinados em termos de validade

dos dados informados e grau de preenchimento das respostas. Deste total não houve
questionários com problemas de preenchimentos, com todos os dados preenchidos
corretamente.
4.1.2.1 Análise descritiva dos Dados Pesquisados
A Análise descritiva dos dados, apesar de não possuir o rigor estatístico das análises
estatísticas não-paramétricas, permitiu desenvolver interessantes e importantes constatações
relacionadas com as questões do estudo, as quais podem ser usadas como ponto de partida
para pesquisas complementares para um entendimento ainda mais profundo do ambiente
organizacional pesquisado.
4.1.2.2 Sumário dos dados descritivos
Na Tabela 3 apresentamos um sumário das principais constatações obtidas da tabulação

e compilação dos dados descritivos das organizações pesquisadas.
Tabela 3 - Sumário dos dados descritivos
Tipo de Dados Valores mais significativos Constatações

Segmento Profissional TI + Serviços = 39,5 % Maior concentração na
área de serviços e TI.
Tipo de Projeto TI = 47% Forte concentração de
projetos de TI.
Atuação Predominante Gerente = 68,8 % Forte predominância de
Equipe = 30,2 % Gerentes.
Projetos simultâneos 2-5 > 60 % Predominância de
número baixo de
projetos simultâneos.
Quantidades de projetos Aumentando > 60% Índices de projetos
simultâneos aumentando

Recursos por projetos 5-20 > 56 % Predominância de

projetos de alocação
média de recursos
Duração média dos 6 meses > 50% Baixa duração dos
projetos projetos
Complexidade dos Baixa > 50% Maior concentração de
projetos projetos de baixa
complexidade
Nível de stress Mais estressante > 86% Alto nível de stress em
projetos simultâneos.
Critérios de Sucesso Preocupação com Prazo > 33% Visão voltada ao cliente.
Satisfação do Cliente > 31 %
4.1.2.3 Resultados por Tipo de Dados
Este tópico apresenta os resultados separadamente por Tipo de Dados, realizados na

pesquisa.
4.1.2.3.1 Quanto ao Segmento da Empresa
35,00%
30,00% 28,68% 27,91%
25,00%
20,00%
15,50%
15,00%
10,08% 10,85%
10,00%
4,65%
5,00%
2,33%
0,00%
Industria TI Telecom Petroleo e Serviços Finanças Outros
Gas
Figura 8 - Segmento da Empresa

4.1.2.3.2 Quanto ao Tipo de Projeto
50,00% 47,29%
45,00%
40,00%
35,00%
30,00%
25,00%
20,00%
16,28%
15,00% 13,18%
11,63% 11,63%
10,00%
5,00%
0,00%
TI Organizacional Des env Pres tação de Outros
Produtos Serviços
Figura 9 – Tipo de Projeto
4.1.2.3.3 Quanto a Atuação no Projeto
80,00%
69,77%
70,00%
60,00%
50,00%
40,00%
30,23%
30,00%
20,00%
10,00%
0,00%
Gerente Equipe
Figura 10 – Atuação no Projeto

4.1.2.3.4 Quanto a Quantidade de Projetos Simultâneos

70,00%
62,79%
60,00%
50,00%
40,00%
30,00%
20,16%
20,00%
12,40%
10,00%
4,65%
0,00%
1 2-5 5 - 10 > 10
Figura 11 – Quantidade de Projetos Simultâneos
4.1.2.3.5 Quanto ao Volume de Projetos
70,00%
61,24%
60,00%
50,00%
40,00% 37,98%
30,00%
20,00%
10,00%
0,78%
0,00%
Aumento Diminuído Estável
Figura 12 – Volume de Projetos

4.1.2.3.6 Quanto aos Recursos Alocados
60,00% 56,59%
50,00%
40,00%
30,00% 25,58%
20,00% 17,83%
10,00%
0,00%
<5 5 - 20 > 20
Figura 13 – Recursos Alocados
4.1.2.3.7 Quanto a Duração Média dos Projetos
60,00%
54,26%
50,00%
40,00%
32,56%
30,00%
20,00%
13,18%
10,00%
0,00%
<3 3-6 >6
Figura 14 – Duração Média dos Projetos (meses)

4.1.2.3.8 Quanto a Complexidade dos Projetos
80,00%
69,77%
70,00%
60,00%
50,00%
40,00%
29,46%
30,00%
20,00%
10,00%
0,78%
0,00%
A lta Média Baixa
Figura 15 – Complexidade dos Projetos
4.1.2.3.9 Nível de Stress
100,00%
90,00% 86,82%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,08%
10,00% 3,10%
0,00%
Mais Igual Menos
Figura 16 – Nível de Stress

4.1.2.3.10 Quanto ao Critério de Sucesso
35,00% 33,33%
31,01%
30,00%
25,00%
20,00% 17,05%
15,00% 12,40%
10,00%
6,20%
5,00%
0,00%
Terminar no Ficar dentro do Cumprir a Satisf azer o Traz o
Prazo previsto Orçamento Qualidade Cliente Benef ício a que
esperada se propõe
Figura 17 – Critério de Sucesso
4.2 Pesquisa de Campo II
No intuito de aumentar a profundidade da Pesquisa de Campo I, procuramos fazer um

cruzamento com os resultados da pesquisa realizada pelo professor Lúcio Edi Chaves em sua
tese de mestrado - A Gestão dos conflitos de recursos humanos entre os processos e
projetos.
Segundo Chaves (2004), os questionários foram distribuídos para um público de cerca
de 1200 alunos de pós-graduação e profissionais do mercado, com a possibilidade de alcançar
em torno de 600 indivíduos com atividades diretamente ligadas a execução de projetos.
Considerando-se o retorno efetivo de 120 questionários, contendo dados de informantes que
se identificaram como atuantes em atividades de projetos, a amostra obtida representou 20%
dos informantes potencialmente habilitados a fornecerem informações.

4.2.1 Sumário dos Dados Descritivos
Tabela 4: Sumario dos dados descritivos, Chaves (2004)
Tipo de Dados Valores mais significativos Constatações

Experiência profissional Media do total: 13,5 anos Informantes com
Média de projetos individuais: 5,2 experiência média nos
Média de projetos múltiplos: 4,6 dois tipos de
gerenciamento
Gerenciamento de 2 a 3 projetos = 51% Taxas razoáveis de
simultâneo de 4 a 6 projetos = 26% gerenciamento de
multiprojetos a nível
individual
Negócio principal das Serviços + Informática = 51% Forte concentração em
organizações Indústria = 25% áreas ligadas a serviços
(> 50%)
Características dos Sistemas + Prest. de Serviços = Forte predominância de
projetos individuais 62% projetos "soft" em
relação a outros tipos
Grau de complexidade Nível Médio = 53,8% Forte grau de
Nível Alto = 40,6% complexidade dos
projetos
Grau de Incerteza de Nível Médio = 62,3% Alto grau de
prazos e custos Nível Alto = 25,5% complexidade dos
projetos
Índice de sucesso em Baixo + Médio = 80% nos Índice pouco satisfatório
prazo projetos grandes Piora na medida que
cresce o porte do projeto
Índice de sucesso em Baixo + Médio = 78% nos Índice pouco satisfatório
custos projetos grandes Piora na medida em que
cresce o porte do projeto
Índice de sucesso em Médio + Alto = 90% nos projetos Índice satisfatório
qualidade médios e grandes Não varia muito em
função do porte do

Projeto
Interdependência técnica Nível Médio + Alto = 75% Altos índices de
e de recursos entre interdependências entre
projetos projetos
Recursos alocados "full- 10 a 25% = 40% dos projetos Baixa taxa de dedicação
time" dos recursos em tempo
integral aos projetos
Agrupamento dos Por Produto + Por Estratégia = Agrupamento com

projetos do Portfólio 63% enfoque voltado a
resultados
Estrutura organizacional Matriz Projetizada + Time de Tendência para o
projeto = 50% das empresas enfoque de times de
projeto, poucas
estruturas funcionais
Níveis de planejamento Médio Prazo (eventual + sempre) Maior foco em curto em
de Portfólio = 76% médio prazo
Longo Prazo (eventual + sempre )
= 50%
Metodologia de Gerência Modelo específico de cada Maior foco no Gerente
de Projeto Departamento = 15 % do projeto ou corporativa
Prioridade dos projetos Benefício Estratégico = 56% Visão estratégica é
do Portfólio predominante
Uso de Gerente auxiliar Não = 60% Taxa média/baixa de uso
para multiprojetos
Conceito de Gerência de Eventual + regular = 74 % Aplicação do conceito
Portfólio ainda em nível
intermediário

4.3 Avaliação dos Resultados e Conclusões
Os resultados revelam claramente que as organizações pesquisadas, nos vários ramos da

indústria e de serviços, estão envolvidas fortemente com o ambiente de múltiplos projetos,
nos quais os líderes/gerentes de projetos são submetidos à responsabilidade de gerenciamento
simultâneo de vários projetos.
Verifica-se uma forte tendência do segmento de TI, na prática de Gerenciamento de
Múltiplos Projetos.
O perfil de projetos nesse ambiente mostrou que são em sua grande maioria de
pequeno e médio porte, com duração curta para média (de até 6 meses), baixa a média
complexidade, equipe alocada de porte pequeno a médio e com a maioria dos gerentes
responsável por até 6 projetos simultâneos.
Uma importante constatação feita foi em relação ao nível de stress respondida no
questionário. O fato do nível de complexidade dos projetos não serem altos não reduz o nível
de stress, nos levando a concluir que o nível de stress está fortemente relacionado à
quantidade de projetos simultâneos realizados, sendo que a tendência mostrada pela pesquisa
é que essa quantidade está aumentando.
5 CONCLUSÕES
Apresentamos, no decorrer do trabalho, uma extensa pesquisa bibliográfica sobre

conceitos, técnicas, ferramentas e características do ambiente de múltiplos projetos e das
questões relativas ao seu gerenciamento, que por si só já vão ajudando a responder algumas
das questões mais problemáticas sobre o tema. Vamos discutir agora, como esses elementos
se relacionam visando avançar o entendimento do assunto e auxiliar no desempenho dessa
função.
5.1 A Importância do estudo de Múltiplos Projetos para a Organização
Primeiramente é importante destacar a participação vital dos projetos no desempenho

da organização, sendo a base para seu futuro, como descreve Dye (2000). Tendo a noção de
como os múltiplos projetos que toda organização tem em andamento se relacionam dentro do
ciclo do negócio, fica evidente a necessidade de se dar especial atenção ao tema. A figura 18

descreve com clareza como uma organização funciona, do ponto de vista de transformar
estratégias em resultados.
Figura 18 – Múltiplos Projetos no Contexto da Organização

O ambiente de múltiplos projetos que inclui o portfólio completo, com todos os

programas e projetos independentes, formam o plano de ação que materializa a estratégia da
organização, produzindo os resultados que vão reposicioná-la no mercado.
5.2 A Gerência de Múltiplos Projetos e a Teoria de Administração de Empresas
Na discussão do referencial teórico, apresentada anteriormente, ficou claro que há uma

estreita relação entre os princípios da administração de empresas e o gerenciamento de
múltiplos projetos. As similaridades são muitas, desde a constatação que uma empresa, assim
como um projeto, é um sistema aberto, que é influenciado pelo ambiente externo, até a
estratégia de distribuição das responsabilidades. Na empresa, essa distribuição se dá através
dos cargos funcionais, seguindo uma hierarquia na estrutura organizacional para diferenciar a
abrangência das responsabilidades e os afazeres de cada nível funcional. Com essa estrutura
piramidal, os gestores delegam questões, metas e trabalho para os escalões subordinados, que
por sua vez repetem o processo para os próximos níveis até chegar a última unidade
operacional da estrutura. Essa estratégia permite que poucas pessoas, senão uma (o
presidente) consiga gerir uma organização complexa e abrangente.
Levando esse conceito para o gerenciamento de projetos, quanto maior e mais
complexo for o projeto, ou no caso de múltiplos projetos, quanto mais projetos estão sob a
responsabilidade do mesmo gerente, mais ele terá que aplicar o conceito do gerenciamento
distribuído. Bhend (1999) já alertava que gerenciar vários projetos diferentes ao mesmo
tempo requer uma abordagem diferenciada, onde o gerente precisa compartilhar o controle do
projeto e conhecimento com sua equipe para conseguir vencer esse desafio. Não há duvida
que essa gerente precisa de uma equipe confiável, para quem ele possa delegar metas
específicas em relação ao projeto, deixando que eles façam a sua parte como líderes de
projetos. Ajani (2002), um dos defensores do XPM, deixa esse conceito bem claro. Ele sugere
que o gerente de múltiplos projetos mantenha a WBS em nível macro, delegando para líderes
de suas equipes o gerenciamento do segundo nível da WBS, transferindo para eles a
responsabilidade, como se fosse um subprojeto. “Se não puder confiar em seus líderes,
troque-os”, é a recomendação que ele dá.
A conclusão fundamental aqui é que para que seja possível gerenciar bem múltiplos
projetos, é preciso delegar. Criar funções de líderes, ou coordenadores de projetos para o nível
logo abaixo do gerente é uma forma de deixar claro essa prática. No final, o que importa é
sobrar tempo para que o gerente possa administrar também os outros projetos, assim com

acontece com os gestores na estrutura organizacional de uma empresa, ou grupo de empresas.

Essa é uma verdade também aplicada na gerência de programas e na gestão de portfólio.
5.3 Conceitos Básicos para Gerenciar Múltiplos Projetos com Sucesso
Após a discussão de tantos elementos influenciadores no desempenho de um bom

gerenciamento de múltiplos projetos, precisamos reunir os conceitos básicos que devem ser
levados em consideração para se ter sucesso nessa empreitada.
Os “Pequenos”
A questão dos pequenos projetos merece uma atenção especial. Embora a literatura
defenda o gerenciamento dos pequenos projetos de forma estruturada, com as devidas
adaptações, como vimos anteriormente, nossa experiência pessoal nas empresas por onde
passamos e em clientes que temos contato, nos mostra que existe uma grande quantidade de
pequenos projetos que não são gerenciados formalmente. Na maioria das vezes, são
planejados e executados de acordo com a metodologia particular de cada responsável, ficando
seus resultados à mercê de sua capacidade e experiência pessoal em lidar com esse tipo de
projeto, muitas vezes sem gerar nenhum relato formal de seus resultados. Quando o resultado
não é positivo e toma maiores proporções, aparece uma infinidade de razões e justificativas
que isentam o responsável de qualquer débito em relação aos resultados. Nesse ponto é
comum ter que se formalizar um projeto para resolver o “novo” problema. Defendemos a
necessidade de se gerenciar de forma estruturada mesmo os pequenos projetos de uma
empresa, que reunidos representam uma parte substancial do tempo e recursos alocados da
empresa, agrupando-os e aplicando uma metodologia adequada, utilizando técnicas de
gerenciamento de múltiplos projetos. A importância dos inúmeros pequenos projetos de uma
empresa para a sua prosperidade, é análoga ao papel das micro e pequenas empresas na
economia de um país, onde juntas são responsáveis por parte significativa do PIB e da
geração de empregos. Ignorá-las ou não ter uma política apropriada é como o país dar um tiro
no próprio pé. Assim também acontece com a organização que ignora seus pequenos
projetos.
Treinamento
Para se ter sucesso no gerenciamento de múltiplos projetos, o investimento no

treinamento deve ser forte, pois não bastam os gerentes de projetos serem capacitados, mas

também as equipes e as lideranças funcionais. Se tivermos que aplicar o gerenciamento

distribuído, como fazê-lo sem que a equipe tenha competência para desempenhar o seu papel?
Como foi discutido anteriormente, utilizar modelos de competência para mapear a
qualificação dos recursos humanos nos pontos que influenciam o bom andamento dos
projetos, como habilidades de planejamento, comunicação, relações interpessoais, técnicas de
gerenciamento de projetos, metodologia da empresa, etc. e atuar no crescimento dessas
competências são fatores críticos de sucesso. Para compartilhar o poder com a equipe, é
preciso qualificá-la e capacitá-la. Em qualquer esporte coletivo, um time que não treina e não
tem bons fundamentos, não ganha o jogo. Em projetos isso também é verdade.
Nível de Controle do Projeto
Uma questão crucial que determina a sua capacidade de gerenciar múltiplos projetos é
o tempo e o esforço necessários para manter o controle do mesmo. A freqüência com que as
atividades são acompanhadas, ou o intervalo entre os pontos de controle do projeto, vão
determinar o quanto de atenção, e conseqüentemente, do tempo do gerente do projeto será
destinado para supervisionar o projeto. Um controle detalhado por parte do gerente de projeto
vai absorver boa parte de sua capacidade de realização, impedindo-o de dar atenção para
outros projetos.
Algumas questões influenciam muito nessa demanda por controle, sendo as principais:
o Risco do Projeto: é claro que quanto mais risco envolver o projeto, mais
suscetível ele estará para variações nos resultados, mudanças de escopo, problemas
inesperados e logicamente mais controle deve haver sobre ele. Portanto, será
necessário aumentar a granularidade do acompanhamento, obrigando um maior
detalhamento das atividades e um intervalo menor entre os pontos de controle para
que haja tempo de tomar medidas corretivas, se necessário.
o Experiência da Equipe: quanto mais experiente for a equipe, menos
particionamento das atividades será necessário, permitindo que a equipe
desenvolva e reporte o projeto em níveis mais altos da hierarquia de lista de
atividades. Por exemplo, se uma equipe nunca fez um tipo de projeto, ou seus
membros tem pouca experiência de trabalho, será necessário um controle maior,
quebrando as atividades em sub-atividades ainda menores para manter um controle
mais rígido.
o Nível de Confiança na Equipe: quanto mais se confia na equipe, menos
supervisão e conseqüentemente menos detalhamento das atividades é necessário.

Para gerenciar múltiplos projetos, o ideal é ter uma equipe confiável, onde se possa
delegar responsabilidade, como já foi comentado. Maior maturidade das equipes,
mais projetos simultâneos podem ser gerenciados.
5.4 XPM em Múltiplos Projetos
Conceitos e técnicas desenvolvidas pelo Extreme Project Management tem muita

sinergia e utilidade no gerenciamento de múltiplos projetos. O XPM surgiu como uma
alternativa ao tradicional gerenciamento de projetos para lidar com projetos contemporâneos,
empresariais, frutos de um ambiente turbulento e em constante mudança. Ficou claro concluir
que os projetos que são normalmente gerenciados de forma simultânea se beneficiariam muito
das soluções propostas pelo XPM. Técnicas que dão mais flexibilidade ao gerente,
economizam seu tempo e encurtam o ciclo de vida do projeto facilitam bastante a vida do
gerente de múltiplos projetos. Vejamos os momentos onde podemos aplicar os conceitos e
técnicas do XPM em múltiplos projetos de forma mais produtiva.
Seleção de Estratégias de Desenvolvimento
O importante na hora de escolher a estratégia é identificar o que é mais importante

para cada projeto. Voltar às origens, aos critérios de sucesso, às restrições e à análise do
ambiente. Qual é o foco do cliente ou do patrocinador: prazo, custo, qualidade, benefícios?
Afinal, se o projeto não puder ser entregue no prazo com a qualidade esperada, o que é mais
importante, focar no prazo ou na qualidade? Pode-se degradar a qualidade de forma acordada
para cumprir o prazo para depois elevar a qualidade, mesmo tendo mais custos (estratégia
evolutiva)? Isso vai maximizar os benefícios para a empresa ou cliente? Dependendo das
respostas para essas perguntas, deve-se então escolher a estratégia a ser adotada, ou uma
combinação apropriada. Interessante notar que, para projetos de curta duração, equipe
pequena, baixo risco e complexidade, a melhor estratégia pode bem ser a monolítica. Dentro
desse raciocínio, a estrutura monolítica pode ser usada também para parte do desenvolvimento
de uma versão ou componente do projeto, compondo uma estratégia diferenciada mais ampla.
Especificamente para o gerente de múltiplos projetos, ele deve tomar cuidado ao
escolher uma estratégia que requer muito esforço e tempo de gerenciamento, procurando
evitar a estratégia incremental de desenvolvimento por múltiplas versões simultâneas, a não
ser que as equipes tenham alto grau de maturidade e autonomia. Embora a estratégia de
desenvolvimento de um projeto deva ser escolhida em função do sucesso do mesmo, o gerente

também tem que ter uma boa noção de sua própria capacidade de realização para não
comprometer o sucesso de vários projetos, adotando ma estratégia complexa num ambiente
desfavorável. Neste caso, ele deve discutir com o gestor do portfólio ou gerentes dos
programas afetados para redistribuir a carga de trabalho ou designar recursos adequados aos
projetos envolvidos.
5.5 Ferramentas para Múltiplos Projetos
Ferramentas são definidas como utensílios ou elementos usados para auxiliar na

execução de um trabalho. No caso de gerenciamento de projetos, podem ser de dois tipos: de
informática ou não. As informatizadas contam com programas de apoio ao trabalho em geral
como planilhas, processadores de texto, email, navegadores de internet, etc. e incluem
também uma ferramenta importante para o bom desenvolvimento de projetos, que são os
Sistemas de Informação de Gerenciamento de Projetos, também conhecidos como PMIS
(Project Management Information Systems). As ferramentas não informatizadas são também
muito importantes como o WBS para definir o escopo, o Diagrama de Rede para descrever o
sequenciamento das atividades, o Cronograma para planejar e controlar o prazo do projeto, e
várias outras. Vamos discutir aqui as características das ferramentas que mais influenciam no
gerenciamento de múltiplos projetos, para que a vida do gerente desses projetos possa ser
facilitada.
Das ferramentas não informatizadas, além das tradicionais já mencionadas, úteis em
qualquer ambiente de projetos, podemos destacar algumas de XPM mencionadas por
Thomsett (2001), particularmente úteis para múltiplos projetos, pois abreviam o ciclo de vida
e economizam muito tempo. No planejamento, a ferramenta mais útil são as sessões de RAP,
ou planejamento rápido. Conseguir reunir de uma só vez os stakeholders importantes do
projeto para alinhar critérios de sucesso e fazer o plano do projeto,de forma intensiva e
completa, faz toda a diferença na economia de tempo e de futuros conflitos no projeto. Se
múltiplos projetos significam menos tempo ainda disponível, mais crítica se torna a aplicação
desta técnica. Porém, antes do planejamento, na fase de definição do projetos e alinhamento
dos critérios de sucesso, a ferramenta mais importante certamente são as “réguas de sucesso”,
que conseguem traduzir as expectativas subjetivas dos stakeholders com clareza, como
discutido anteriormente. Se os múltiplos projetos não têm necessariamente relação entre si,
então o gerente de projetos terá que se relacionar com grupos distintos de stakeholders,
alinhando expectativas de todos eles. Uma ferramenta como essa certamente facilita

documentar esse alinhamento que vai direcionar os esforços de cada projeto, economizando
tempo e minimizando retrabalho.
Quanto às ferramentas informatizadas, vamos discutir apenas os PMIS. Badir (2003)
descreve a importância de sistemas baseados na WEB para gerenciar grandes projetos a nível
global que possibilite a monitoração, controle e coordenação da execução de múltiplos fluxos
de informação que atravessam as organizações. O sistema deve gerenciar a informação desde
o momento em que ela é criada até o seu arquivamento final, compartilhando seu conteúdo
com todos os envolvidos no projeto, construindo uma rede colaborativa que une equipe,
cliente, fornecedores e qualquer outro stakeholder pertinente ao projeto. Porém, não é
somente os grandes projetos que podem se beneficiar desses sistemas. Castle, Boone e Nunn
já alertavam em 1994 para a necessidade de utilizar um PMIS para vencer o desafio de se
gerenciar múltiplos projetos de pequeno porte. Nesse caso, eles valorizam a importância do
sistema ser simples de se usar, porém poderosa o suficiente para lidar com um grande número
de projetos simultaneamente e estar acessível em rede para disseminação das informações
para os envolvidos, principalmente em razão do compartilhamento de recursos.
Atualmente, dentro de tudo que já foi apresentado neste trabalho, ficou claro que um
PMIS que se proponha a auxiliar no gerenciamento de múltiplos projetos precisa ser
desenvolvido com foco também na equipe e não somente no gerente de projetos. Vimos que é
importante compartilhar as informações, distribuir o gerenciamento, responsabilidades, tudo
de forma rápida ágil e simples. Vimos também que a equipe hoje em dia é mais virtual,
heterogênea, multidisciplinar, e trabalha de forma assíncrona, no tempo e no espaço.
Características essenciais para os sistemas desse tipo são: visão simultânea dos projetos,
ênfase na comunicação pró-ativa, multi-usuário e certamente conectada na Internet (ou
Intranet), que é um padrão de fato de comunicação organizacional. Em suma, deve
acompanhar a mudança de paradigma que se instalou no ambiente de gerenciamento de
projetos.
Por mais que um sistema seja útil, no auxílio ao gerenciamento de projetos, temos que
ter em mente, como explica Clark (2000) em seu artigo, que pacotes de software não
gerenciam projetos, pessoas sim. Soluções de software são exatamente isso: soluções,
específicas para necessidades de gerenciamento de informações. Empresas que tem
maturidade em gerenciamento de projetos devem seu sucesso às melhores práticas e
experiência adquirida, e normalmente utilizam uma variedade de soluções, inclusive as mais
modernas. Porém, sem o conhecimento, o aproveitamento das ferramentas seria muito baixo e
não levaria a empresa a bons resultados.

5.6 PMBOK e Múltiplos Projetos
O PMBOK (Project Management Body of Knowledge), compilado pelo PMI reúne as

melhores práticas de mercado no gerenciamento de projetos, resultado de décadas de
exercício de técnicas e processos. Como foi discutido na evolução histórica do gerenciamento
de projetos, é forte a influência dos projetos tradicionais de grande porte provenientes das
indústrias militares, engenharia e construção na evolução desta base de conhecimento e
práticas que é o PMBOK, até pela própria história e origens do PMI. Obviamente, a aplicação
dos conceitos apresentados no PMBOK não é obrigatória em todas as circunstâncias, como
se fosse uma metodologia universal de gerenciamento de projetos. É importante que fique
claro que a metodologia de gerenciamento de projetos deve ser desenvolvida (ou adotada de
terceiros) pela organização, de acordo com o ciclo de vida de seus projetos, o contexto e a
indústria em que se encontra, como preconiza o próprio PMBOK.
O PMBOK aborda muito timidamente a questão dos ambientes de múltiplos projetos.
A sua versão mais recente, de 2004, desenvolve um pouco mais o tema, incluindo até uma
subseção sobre Escritórios de Projetos, mas ainda é superficial. A razão principal desse fato é
que o PMBOK é um padrão desenvolvido pelo PMI para o gerenciamento de projetos
individuais. Para ambientes de múltiplos projetos, à nível organizacional, o PMI desenvolveu
o modelo OPM3, que inclui também as dimensões de Programa e Portfólio, fazendo um
alinhamento com a dimensão do gerenciamento individual de projetos. Evoluindo o trabalho
iniciado com o OPM3, estão em desenvolvimento pelo PMI padrões específicos nos domínios
de Programas e Portfólio, chamado de PPMS, Program and Portfolio Management Standard,
que resultará na publicação de padrões separados nos moldes do PMBOK. A publicação das
primeiras versões para exposição está prevista para o segundo bimestre de 2005 e a versão
final para o início de 2006.
Porém, a visão de gestão de programas e portfólio apresentada pelo PMI em geral não
é a mesma que discutimos neste trabalho, que foca mais o gerenciamento de múltiplos
projetos independentes, no plano operacional. No entanto, é importante entender que antes de
se gerenciar múltiplos projetos, é preciso dominar o gerenciamento de um projeto individual,
sendo as técnicas e conceitos que funcionam para um projeto a base para o gerenciamento de
múltiplos projetos.

5.7 Abordagem para Múltiplos Projetos de TI
Tomando por base as nossas e outras pesquisas de campo, concluímos que o segmento
mais emergente em relação a múltiplos projetos é o de TI, especialmente projetos de
desenvolvimento de software.
Porém, uma pergunta deve feita neste momento. Será que o segmento de TI, em
especial o de desenvolvimento de software, está se preparando para lidar com múltiplos
projetos?
A resposta é claramente que sim. Analisando algumas técnicas de desenvolvimento,
vimos que esta tendência está se materializando com novos processos de desenvolvimento de
software.
Em nosso referencial teórico, destacamos dois dos processos mais populares utilizados
atualmente: RUP e XP. Fazendo um vínculo com os conceitos básicos para se gerenciar
múltiplos projetos com sucesso, tanto o RUP quanto o XP usam técnicas particulares de
desenvolvimento para múltiplos projetos.
Ambos defendem a idéia de fazer pequenos projetos ou iterações durante todo o
processo, desenvolvendo uma abordagem evolucionária para múltiplos projetos. Mas nem
sempre foi assim. Originalmente, os projetos eram feitos de forma ad hoc, sem muita
disciplina. Para combater essa informalidade na criação dos projetos, as pessoas começaram a
estrutura-los na forma tradicional. Os projeto eram criados no inicio da mesma forma como os
grandes projetos de construção, como o de uma ponte. Nesse caso, os requisitos são
conhecidos ou podem ser conhecidos desde o início, pois existem processos comprovados
para projetar e construir pontes. Com software é diferente. Se você está criando seu vigésimo
sistema contábil, pode projetá-lo certo ou pelo menos muito próximo de certo. Entretanto, se o
sistema é novo, personalizado ou é o primeiro do tipo, não há como saber com antecedência
quais serão todos os requisitos.
Outra técnica que facilita gerenciar múltiplos projetos usados por RUP e XP é
Modelagem Ágil (AM). A AM é uma metodologia baseada na prática para o modelo e
documentação dos sistemas de software. Os modelos ágeis são mais efetivos do que os
modelos tradicionais, porque são apenas suficientemente bons e não precisam se perfeitos.
Podemos usar uma abordagem de AM para os requisitos, a análise, a arquitetura e o projeto.

A AM promove:
o Os indivíduos e as interações em vez dos processos e das ferramentas: As
pessoas e as comunicações são o mais importante.
o O software de trabalho em vez da documentação abrangente: O objetivo de
um esforço de desenvolvimento de software é desenvolver o software. O
objetivo do desenvolvimento de software não é produzir documentação, essa
pode ser uma das tarefas que suporta o software.
o A colaboração com o cliente em vez da negociação de contrato: Muito mais
progresso é feito se a colaboração for usada no lugar da simples negociação. A
equipe não pode manter um modelo dinâmico e mutável sem o envolvimento
constante do cliente. Usar apenas a negociação significa criar todos os
requisitos desde o início em um processo de “toma-lá-dá-cá” entre equipe e o
cliente. Se houver uma colaboração mais próxima com o cliente, este pode
alterar os requisitos imediatamente, a equipe pode discutir os requisitos com o
cliente, buscar esclarecimentos e obter outras informações que sejam
necessárias.
o Responder à mudança em vez de seguir um plano: Para que um software
atenda ás necessidades do cliente, ele deve ser desenvolvido em um ambiente
que mude e que responda aos requisitos da mudança.
Por fim, veremos alguns valores e práticas usadas no XP e no RUP para

melhor gerenciar múltiplos projetos.
Valores
o Comunicação: A comunicação efetiva é necessária entre todos aqueles
envolvidos no projeto: desenvolvedores, gerentes e clientes. Uma das
principais finalidades de criar os modelos é a comunicação.
o Honestidade: A comunicação é inútil, até mesmo prejudicial, se ela não for
honesta: os desenvolvedores devem ser honestos em suas estimativas, por
exemplo. Se a comunicação for aberta e honesta, as pessoas podem confiar
uma nas outras e podem avançar muito mais rápido.
o Simplicidade: Fazer a coisa mais simples que possa funcionar é o maior valor
de todos e se aplica da mesma forma aos modelos e aos códigos.

o Feedback: O feedback constante é imperativo para ter certeza de que você está
fazendo a coisa certa e para fazer uma correção assim que possível, caso haja
desvios.
o Humildade: Você precisa sempre se lembrar de que pode estar errado. Muito
bem, isso não é tão ruim. Entretanto, você tem de estar aberto para o fato de
que o restante da equipe também tem idéias válidas, e algumas delas serão
melhores que a sua. Esteja preparado para fazer as coisas certas, independente
de onde veio a idéia.
Práticas:
o Criar o modelo para entender: Crie os modelos de forma a explorar um
problema e seu espaço de solução. Planeje jogar fora alguns dos seus modelos
porque eles são apenas etapas no caminho do esclarecimento.
o Criar o modelo para se comunicar: Seja conciso, mas expressivo. Assim
como é importante selecionar nomes bons, você deve criar seus modelos para
se comunicar de forma mais sucinta possível.
o Criar modelos simples: Não tente criar o modelo de todos os modelos. Em
vez disso, faça pequenos modelos que são visões pequenas de partes
específicas do sistema. Existe um lugar para o quadro mais amplo, mas não
quando você está tentando entender uma parte específica dele.
o Usar ferramentas simples: Os quadros são bons, assim como lápis e o papel.
Para traduzir isso em termos técnicos, use a ferramenta mais simples que possa
fazer o trabalho. Existem algumas ferramentas tecnológicas, mas muitas delas
criam os modelos por criar. Não faça isso!
o Criar os modelos com um parceiro: Isso é uma extensão natural da
programação em pares (XP). Todos os benefícios de ter duas pessoas
escrevendo o código se aplicam a ter duas pessoas criando o modelo.
o Criar o modelo com um grupo: Às vezes, é bom fazer com que toda equipe
(ou algum subconjunto grande dela) crie o modelo. Isso é mais útil quando
você explora um problema em larga escala que tem repercussões amplas ou
quando você não consegue fazer progresso e quer que o problema seja visto
com outros olhos.
o Usar um mural para o modelo: Pode ser útil publicar seus modelos em
algum lugar, seja colocando cópias físicas em um local específico, criando um

quadro que contém o modelo, ou tendo um lugar na sua intranet no qual podem
ser publicados.
5.8 Considerações Finais
Os objetivos deste trabalho foram descrever os vários ambientes de múltiplos projetos

nas organizações e oferecer auxílio para os gerentes responsáveis por vários projetos
simultâneos, no plano operacional, atuarem com mais esclarecimento e chances de sucesso.
Fizemos um paralelo com os conceitos clássicos da administração, demonstramos as origens
do tradicional gerenciamento de projetos e mostramos porque ele não é o mais adequado para
o desafio de múltiplos projetos, descrevemos o perfil dos projetos atuais, apresentamos
alternativas de gerenciamento através do XPM e outras linhas de pensamento, como a Teoria
de Restrições e o Método da Cadeia Crítica, e fizemos uma análise mais aprofundada para
projetos de TI, que são muito representativos do tema. Para alinhar os conceitos e teorias à
realidade local, utilizamos pesquisas de campo para ratificar os argumentos encontrados no
referencial bibliográfico. Após toda a discussão do tema, procuramos resumir parte do
resultado prático do trabalho em uma lista de fatores críticos de sucesso para o gerenciamento
de múltiplos projetos, a seguir.
Fatores Críticos de Sucesso para o Gerenciamento de Múltiplos Projetos:

1. Identificar e selecionar os tipos de projetos mais adequados
2. Agrupar os projetos de forma a facilitar o gerenciamento
3. Utilizar uma metodologia adequada
4. Utilizar a estratégia de desenvolvimento mais adequada à situação
5. Encurtar o ciclo de vida dos projetos
6. Manter o controle a nível macro
7. Distribuir a responsabilidade e o gerenciamento
8. Ter consciência dos limites de capacidade de realização do gerente e das equipes
9. Focar na comunicação
10. Escolher uma equipe em que se pode confiar
11. Capacitar toda a equipe, não somente os gerentes
12. Eliminar a burocracia excessiva
13. Minimizar o comportamento multitarefa (multitasking)
14. Utilizar um sistema de gerenciamento de projetos voltado para a equipe

15. Decidir com rapidez

16. Aprender a dizer não
17. Minimizar os “ladrões de tempo”
18. Envolver os stakeholders
19. Simplificar o máximo possível
Em resumo
O trabalho mais difícil é descobrir o que fazer num mundo de opções infinitas, já dizia
Bill Jensen (2000). Em se lidando com múltiplos projetos, simplicidade é poder. Poder de
fazer menos do que não interessa e mais do que interessa. Porém, simples não quer dizer fácil.
Tornando as coisas simples, fica mais fácil, mas muitas vezes o difícil é conseguir tornar as
coisas simples.
Vimos aqui que gerenciar múltiplos projetos com sucesso não é tarefa fácil, porém
precisamos torná-la mais simples para obter sucesso. Ter atitude, disciplina, exercer a
liderança, adotar técnicas adequadas, desenvolver competências e acumular experiência, são
todos fatores importantes para o sucesso que o gerente de múltiplos projetos deve perseguir.
Como sugestões e recomendações para desdobramentos sobre o tema para futuros
trabalhos, seria acompanhar um estudo de caso em que os elementos aqui levantados tivessem
sido colocados em prática e fazer uma análise dos resultados e dificuldades.
Esperamos ter podido colaborar com o nosso trabalho para a evolução do tema.

6 BIBLIOGRAFIA
1. A Guide to the Project Management Body of Knowledge (PMBOK Guide), 3rd

Edition (EXPOSURE DRAFT). Newton Square, Pennsylvania: Project Management
Institute, 2004
2. AJANI, Shaun. Extreme Project Management, New York, Writers Club Press, 2002.
3. BADIR, Yuosre F., FOUNOU, Remi, STRICKER, Claude, BOURQUIN, Vincent.

Management of global large-scale projects through a federation of multiple web-based
workflow management systems. Project Management Journal, Pennsylvania, PMI, v.
34, n. 3, pgs. 40-47, setembro 2003.
4. BECK, K. Extreme Programming explained. 1st edition. Addison-Wesley Publishing

Company, 1999.
5. BHEND, Marcel. Shared project management. Proceedings: Project Management Institute

Seminar/Symposium (30th), Philadelphia, Pennsylvania, 1999.
6. BREITMAN, K., Leite, J. Managing User Stories. International Workshop on Time

Constrained Requirements Engineering, 2002. [Breitman02]
7. BURKE, Eric Getting Started with Portfolio Management. Portfolio Knowledge,

Bellevue, WA, disponível em:
http://www.portfolioknowledge.com/news/process/articles.asp?id=burke Acesso em:
12/09/2004.
8. CANDÉAS, A.J.; LOPES, C.C.N. Estimativa: Uma ferramenta para agilizar o

dimensionamento de projetos no SERPRO com base na metodologia de análise de pontos
por função. In: Simpósio Brasileiro de Engenharia de Software. Caderno de
Ferramentas, 13, Florianópolis, 1999.
9. CASTLE, James P, BOONE, Brian, NUNN, John O.H. Management of multiple small
projects live software demonstration. Proceedings: Project Management Institute.
Seminar/Symposium (25th), Vancouver B.C., Canada, pgs. 18-24, 1994.
10. CHANG, C. K.; CHRISTENSEN, M. A Net Practice for Software Project Management.

11. CHAVES, Lucio E. A Gestão dos conflitos de recursos humanos entre os processos e
projetos. Dissertação do Curso Stricto-Sensu em Sistemas de Gestão, Niterói:
Universidade Federal Fluminense, 2004
12. CLARK, Curtis W. Software packages don’t manage projects--people do! Proceedings:
Project Management Institute. Seminar/Symposium (31st). Houston, Texas, 2000
13. CLELAND, David I. Project Management: Strategic Design and Implementation,

3a edição, New York: McGraw Hill International Editions, 1999.
14. CLELAND, David I.; IRELAND, Lewis R. Gerência de Projetos. Rio de Janeiro:
Reichmann & Affonso Editores, 2002.
15. COOPER, Robert, EDGETT, Scott. Portfolio Management for New Products: Picking the
Winners. Working Paper No. 11, Product Development Institute, Ontario, Canadá.
Disponível em www.stage-gate.com/pdfs/Working%20Paper%2011.pdf . Acessado em
10 out 2004.
16. DINSMORE, Paul Campbell; CAVALIERE, Adriane. Como de tornar um profissional

em gerenciamento de projetos: livro-base de “Preparação para Certificação PMP –
Project Management Professional”. Rio de Janeiro: Qualitymark Editora, 2003.
17. DOBSON, Michael Singer. The juggler’s guide to managing multiple projects. Newton
Square, Pennsylvania: Project Management Institute, 1999.
18. DYE, Lowell D.; PENNYPACKER, James S. Project portfolio management and
managing multiple projects: two sides of the same coin? Proceedings, PMI, 2000.
19. GITHENS, Gregory D. Manage innovation programs with a rolling wave. PM Network,
Pennsylvania, PMI, v. 15, n. 5, p. 35-39, maio 2001.
20. HELDMAN, Kim. Gerência de projetos: guia para o exame oficial do PMI. Rio de
Janeiro, Elsevier Editora, 2003.
21. IEEE SOFTWARE. V. 16, n. 6, p. 80 -88, nov./dec. 1999.
22. JENSEN, Bill. Simplicidade. Rio de Janeiro, Campus, 2000.
23. KERZNER, Harold. Project Management: A systems Approach to Planning,

Scheduling and Controlling. 7a edição, New York: John Wiley & Sons, 2001.
24. KERZNER, Harold. Project Management for Executives. New York: Van Norstrand
Reinhold Company, 1982.

25. KNUTSON, Joan. Managing multiple projects in a matrixed organization. Proceedings:

Project Management Institute. Seminar/Symposium (25th), Vancouver B.C., Canada,
pgs. 454-458, 1994.
26. KRUCHTEN, Philippe. The Rational Unified Process - An Introduction. Second

Edition., 2000.
27. LUNDGREN, Earl F. Organizational Management – Systems and Process. New York,
NY, Harper & Row, 1974.
28. McCONNELL, Steve. Rapid Development. Redmond, WA, Microdoft Press, 1996.
29. NEWBOLD, Robert C. Critical Chain Multi-Project Implementation. ProChain

Solutions. Disponível em www.prochain.com/articles/CCMultiprojImplementation.asp.
Acessado em 12 out 2004.
30. NEWBOLD, Robert C. Introduction to Critical Chain Project Management. ProChain

Solutions, Inc Disponível em www.prochain.com/articles/CriticalChainArticle.asp,.
Acessado em 12 out 2004.
31. O’CONNOR, R. An Architecture for an Intelligent Assistant System for use in

Software project Planning. Ph.D. Thesis, City University. Londres, 2000.
32. O’CONNOR, R.; JENKINS, J. Using Agents for Distributed Software Project
Management. IEEE 8th International Workshop on Enabling Technologies: Infrastructure
for Collaborative Enterprises. Palo Alto, 16-18 jun., 1999.
33. Organizational Project Management Maturity Model (OPM3): Knowledge

Foundation. Newton Square, Pennsylvania: Project Management Institute, 2003
34. PARTH, Frank R. Categorization of small projects. Proceedings: Project Management

Institute Seminar/Symposium (29th), Long Beach, California, Vol II, pgs. 1382-1385,
1998.
35. PARTH, Frank R. Managing projects in a multitasking environment. Proceedings:

Project Management Institute Global Congress - Europe, 2004.
36. PATRICK, Francis S. Program Management -Turning Many Projects into Few Priorities
with TOC. Project Management Institute Symposium. Philadelphia, October, 1999.
Disponível em http://www.focusedperformance.com/articles/TOCMulti.pdf

37. PMI Member Fact Sheet (August 2004), Disponível em

http://www.pmi.org/info/GMC_MemberFACTSheet.asp, Acessado em 11 out 2004.
38. PORTER, Michael E. Estratégia Competitiva: Técnicas para análise de indústrias e

da concorrência, 7ª ed., Rio de Janeiro: Editora Campus, 1986.
39. PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995. ISBN 85-
346-0237-9.
40. Program/Portfolio Management Standard (PPMS): Project Charter. Disponível em

http://www.pmi.org/prod/groups/public/documents/info/PP_ProgPortMgmtStndChrtr.asp,
Acesso em 10 out 2004.
41. Project Portfolio Management: Definition and Process Overview, Whitepaper,

Pacificedge Software, 2004, disponível em
http://www.pacificedge.com/solutions/whitepapers.asp#meta. Acessado em 10 out 2004.
42. SOFTWARE PRODUCTIVITY RESEARCH. Disponível em: <http://www.spr.com/>.

Acesso em: 05 set. 2004.
43. Sommer, Renee J. Portfolio management for projects--a new paradigm.

Proceedings: Project Management Institute Seminar/Symposium (29th), Long Beach,
California, Vol. I, pgs. 462-464, 1998.
44. SOMMERVILLE, I. Software Engineering. 4 ed. USA: Addison-Wesley

Publishers,1992.
45. SOMMERVILLE, I. Software Engineering. 5 ed. USA: Addison-Wesley

Publishers,1996.
46. Thiry, Michel. A learning loop for successful program management. Proceedings:
Project Management Institute Seminar/Symposium (31st), Houston, Texas, 2000.
47. THOMSETT, Rob. Managing large projects – a special case. The Thomsett Company,
2000. Newport, VIC, disponível em:
http://www.thomsett.com.au/main/articles/largeprojects/managing_large_projects.pdfAces
so em: 26/09/2004.
48. THOMSETT, Rob. Radical Project Management. New Jersey: Prentice Hall PTR, 2002
49. Um Guia do Conjunto de Conhecimento do Gerenciamento de Projetos: PMBOK

Guide. Newton Square, Pennsylvania: Project Management Institute, 2000

50. VERGARA, Sylvia. Projetos e Relatórios de Pesquisa em Administração. Ed.Atlas.

1990.
51. VIEIRA, Marconi F. Gerenciamento de Projetos de Tecnologia da Informação. 1ª ed.,

Rio de Janeiro: Editora Campus, 2003.
52. VISITACION, Margo. Common Sense Help for E-Business Projects: Critical Chain
Project Management. Planning Assumption, Cambridge, MA, Giga Information Group,
2000.
53. WHITTEN, Neal. 1 + 1 + 1 = 2. PM Network, Pennsylvania, v. 16, n. 4, p. 20, abr. 2002.
54. WOODWARD, Hugh. Winning in a world of limited project spending.

Proceedings: PMI Global Congress, 2003.

7 ANEXOS
7.1 Anexo I – Pesquisa de Campo
1. Segmento da sua empresa:

Industria TI Telecom Petróleo e Gás Serviços Finanças Outros
2. Qual o tipo predominante de projetos em que você atua?

TI Organizacional Desenv. de Produtos Prestação de Serviços Outros
3. Qual é a sua atuação predominante nos projetos:

Gerente Equipe
4. Quantos projetos, em média, você participa simultaneamente?

1 2-5 5 - 10 > 10
5. Esse número tem:

Aumentado Diminuído Permanecido Estável
6. Quantas pessoas em média participam desses projetos?

<5 5 - 20 > 20
7. Qual é a duração média (em meses) dos projetos em que participa?

<3 3-6 >6
8. Qual é a complexidade média dos projetos em que participa?

Alta Média Baixa
9. Como se compara o nível de stress na participação de Múltiplos Projetos com a participação

em Projetos Únicos?
Mais estressante Igual Menos estressante
10. Ordene os critérios de sucesso mais valorizados na sua empresa, ranking de 1 a 5:
Terminar no Prazo previsto 1 - maior valor

Ficar dentro do Orçamento 5 - menor valor
Cumprir a Qualidade esperada
Satisfazer o Cliente
Traz o Benefício a que se propõe

TCC - Gerenciamento de Multiplos Projetos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC - Gerenciamento de Multiplos Projetos

Enviado por

Direitos autorais:

Formatos disponíveis

Gerenciamento de Múltiplos Projetos TCC GP09 RJ / FGV

ROBERTO HENRIQUE NOGUEIRA PONS

GERENCIAMENTO DE MÚLTIPLOS PROJETOS

Monografia apresentada ao curso MBA em

MONITOR: Prof. Edmarson B. Mota

Todos os direitos reservados 1

Muito se fala, se escreve e se discute em relação ao gerenciamento de projetos

Palavras-chave: múltiplos, projetos, gestão, gerenciamento, portfólio.

Todos os direitos reservados 2

Key words: multiple projects, project management, administration, portfolio.

Todos os direitos reservados 3

Todos os direitos reservados 4

4.2.1 Sumário dos Dados Descritivos .....................................................................68

Todos os direitos reservados 5

LISTA DE TABELAS E FIGURAS

Tabela 1 Projetos de Engenharia vs. Empresariais

Todos os direitos reservados 6

LISTA DE ABREVIATURA E SIGLAS

AM Agile Modeling (Modelagem Ágil)

Todos os direitos reservados 7

A escolha do tema de Gerenciamento de Múltiplos Projetos foi influenciada por vários

1.1 Cenário Atual

É de conhecimento público e notório que a velocidade de mudanças no mundo de hoje

Todos os direitos reservados 8

1.2 Definição do Problema

Quando o assunto “múltiplos projetos” é discutido, é preciso entender melhor o que se

Pretendemos ajudar a responder algumas perguntas cruciais sobre o gerenciamento de

- Quais são os fatores críticos de sucesso no gerenciamento de múltiplos projetos?

- Como minimizar os conflitos pela disputa de recursos entre projetos concorrentes?

- Quais técnicas e ferramentas devo utilizar para facilitar o processo?

- Como prevenir a alocação além da nossa capacidade de realização?

Decorrente de nossas experiências profissionais, verificamos que a área de TI tem

1.3 Relevância do Trabalho

A relevância do tema é evidente, uma vez constatada que a realidade na grande

Todos os direitos reservados 9

Sendo o trabalho baseado em questões presentes em praticamente todas as

1.4 Delimitação do Trabalho

O foco do trabalho está no âmbito operacional, portanto, as outras visões – estratégica

Todos os direitos reservados 10

2.1 Estruturação do Trabalho

Este trabalho está estruturado em 7 blocos:

Todos os direitos reservados 11

5. Conclusões: Este capítulo descreve o que os autores desejam contribuir de seus

2.2 Os Fins e os Meios

Todos os direitos reservados 12

A maior limitação da pesquisa de campo realizada é a pouca quantidade de questões

Todos os direitos reservados 13

Esta parte do trabalho procura apresentar os assuntos pertinentes ao tema em estudo

3.1 A Teoria de Administração de Empresas

Os autores acreditam que existem muitas semelhanças entre os conceitos de

A filosofia de administração é um guia genérico que determina como uma organização

Todos os direitos reservados 14

Outra questão importante de abordar no tema de administração são os níveis de

Todos os direitos reservados 15

3.2 Evolução Histórica da Gerência de Projetos

Discutir as origens do tema de gerenciamento de projetos é importante para

3.2.1 Raízes na História Antiga

3.2.2 A Era “Moderna”

Todos os direitos reservados 16

No entanto, o conceito do “moderno” gerenciamento de projetos, como o conhecemos,

Nesta mesma época outros avanços foram desenvolvidos no gerenciamento de

Todos os direitos reservados 17

Todos os direitos reservados 18