tcc multiplos projetos-rp

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


FUNDAÇÃO GETULIO VARGAS

PROGRAMA FGV MANAGEMENT

MBA EM GERÊNCIA DE PROJETOS

TURMA GP09-RJ

O Trabalho de Conclusão de Curso

Gerenciamento de Múltiplos Projetos

elaborado por Roberto Henrique Nogueira Pons e André Luiz Cataldo Falbo Santo

e aprovado pela Coordenação Acadêmica do curso de MBA em Gerência de Projetos, foi

aceito como requisito parcial para a obtenção do certificado do curso de pós-graduação, nível

de especialização do Programa FGV Management.

Rio de Janeiro, 21 de Outubro de 2004.

Prof. Carlos A. C. Salles Jr.

Coordenador Acadêmico

Prof. Edmarson B. Mota



TERMO DE COMPROMISSO

Os alunos André Luiz Cataldo Falbo Santo e Roberto Henrique Nogueira Pons, abaixo

assinados, do curso de MBA em Gerência de Projetos, Turma GP9 do Programa FGV

Management, realizado nas dependências da FGV, no período de 15/04/03 a 21/10/04, declara

que o conteúdo do Trabalho de Conclusão de Curso intitulado Gerenciamento de Múltiplos

Projetos, é autêntico, original, e de sua autoria exclusiva.

Rio de Janeiro, 21 de Outubro de 2004.

Roberto Henrique Nogueira Pons

André Luiz Cataldo Falbo Santo



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 u m 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, management, administration, portfolio.



SUMÁRIO

TERMO DE COMPROMISSO ................................................................................................. 3

RESUMO ................................................................................................................................... 4 ABSTRACT........................................................................................................................... 5

LISTA DE TABELAS E FIGURAS............................................................................................... 8

LISTA DE ABREVIATURA E SIGLAS........................................................................................ 9

1 INTRODUÇÃO................................................................................................................. 10 1.1 Cenário Atual ........................................................................................................... 10 1.2 Definição do Problema............................................................................................. 11 1.3 Relevância do Trabalho............................................................................................ 11 1.4 Delimitação do Trabalho.......................................................................................... 12

2 METODOLOGIA .............................................................................................................. 13 2.1 Estruturação do Trabalho ......................................................................................... 13 2.2 Os Fins e os Meios .................................................................................................. 14 2.3 Limitações ................................................................................................................ 15

3 REFERENCIAL TEÓRICO................................................................................................ 16 3.1 A Teoria de Administração de Empresas................................................................. 16 3.2 Evolução Histórica da Gerência de Projetos ............................................................ 18

3.2.1 Raízes na História Antiga................................................................................. 18 3.2.2 A Era “Moderna” ............................................................................................. 18 3.2.3 O Novo Ambiente ............................................................................................ 21

3.3 Tipos de Projetos...................................................................................................... 22 3.3.1 Projetos Pequenos vs. Projetos Grandes .......................................................... 22 3.3.2 Projetos de Desenvolvimento vs. Projetos de Implantação.............................. 24 3.3.3 Projetos Empresariais vs. Projetos de Engenharia e Construção ..................... 25 3.3.4 Projetos de TI ................................................................................................... 27

3.4 Extreme Project Management (XPM)...................................................................... 35 3.4.1 Conceitos XPM ................................................................................................ 36 3.4.2 Técnicas e Ferramentas XPM .......................................................................... 39 3.4.3 O Modelo de Gerenciamento XPM.................................................................. 41

3.5 Ambientes de Múltiplos Projetos ............................................................................. 45 3.5.4 Gestão de Portfólio........................................................................................... 47 3.5.5 Gerência de Programas..................................................................................... 49 3.5.6 Gerenciamento de Múltiplos Projetos .............................................................. 51 3.5.7 Gerenciamento do Tempo ................................................................................ 56

3.6 O Método da Cadeia Crítica..................................................................................... 59 3.6.1 A Teoria das Restrições.................................................................................... 59 3.6.2 CCM vs. CPM.................................................................................................. 60 3.6.3 CCM no Ambiente de Múltiplos Projetos........................................................ 61

4 ANÁLISE DE RESULTADOS............................................................................................ 62 4.1 Pesquisa de Campo I ................................................................................................ 62

4.1.1 Avaliação Geral da Pesquisa I.......................................................................... 62 4.1.2 Tabulação e Análise dos Dados – Pesquisa I ................................................... 63



4.2 Pesquisa de Campo II ............................................................................................... 69 4.2.1 Sumário dos Dados Descritivos ....................................................................... 70

4.3 Avaliação dos Resultados e Conclusões .................................................................. 72

5 CONCLUSÕES ................................................................................................................. 72 5.1 A Importância do estudo de Múltiplos Projetos para a Organização....................... 72 5.2 A Gerência de Múltiplos Projetos e a Teoria de Administração de Empresas ........ 74 5.3 Conceitos Básicos para Gerenciar Múltiplos Projetos com Sucesso ....................... 75 5.4 XPM em Múltiplos Projetos..................................................................................... 77 5.5 Ferramentas para Múltiplos Projetos........................................................................ 78 5.6 PMBOK e Múltiplos Projetos .................................................................................. 80 5.7 Abordagem para Múltiplos Projetos de TI............................................................... 81 5.8 Considerações Finais................................................................................................ 84

6 BIBLIOGRAFIA................................................................................................................ 86

7 ANEXOS........................................................................................................................... 91 7.1 Anexo I – Pesquisa de Campo.................................................................................. 91



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

envolvidos, certificados e com contratos

formais

Grande número de provedores envolvidos,

frequentemente com contratos verbais

informais

Especificações normalmente fixas e

formalizadas

Especificações flexíveis e informais

Padrão bem estabelecido de código de ética

e conduta profissional

Código de ética profissional mal

estabelecida

Metodologias bem estabelecidas, baseadas

em princípios matemáticos e físicos

Metodologias conflitantes baseadas em

princípios teóricos e de marketing

Produtos físicos a serem entregues com

componentes modulares

Produtos abstratos a serem entregues, de

difícil modularização

Indicadores de desempenho claros e

métricas precisas

Indicadores de desempenho vagos e métricas

de difícil mensuração

Variação reduzida pelos processos

padronizados e constantes

Variação amplificada pelo individualismo e

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

softwares

Precisa medição do software

Insucesso ao usar ferramentas automatizadas

de estimativa

Ferramentas de estimativa usadas facilmente

Fracasso no uso de ferramentas automatizadas de planejamento

Uso contínuo de ferramentas 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 desenvolvimento

Método formal de desenvolvimento

Gerenciamento de risco informal Gerenciamento de risco formal

Insucesso no uso formal do controle de configuração

Controle de configuração automatizado

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.

Codificação Desenho Teste Planejamento

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:

- Nível de Satisfação dos Stakeholders (identificar os principais que devem ser

satisfeitos, geralmente o cliente e o patrocinador)

- Atendimento aos requisitos do projeto (o grau de importância de se atender

todos os requisitos para considerar o projeto um sucesso)

- Respeito ao Orçamento (fácil de medir)

- Respeito ao Prazo (fácil de medir)

- Valor Agregado (o grau de importância dado ao valor que o projeto agrega à

organização, com ênfase na verificação dos benefícios trazidos pelo projeto)



- Atendimento aos requisitos de Qualidade (mensurável através de indicadores e

métricas definidas)

- Satisfação da Equipe (o quanto a satisfação profissional da equipe é importante

para o projeto)

Traduzindo estes sete grupos de 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 e 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çadas 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 deprojetos

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 a 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 sub-projetos? Muitas vezes não é claro e ambos termos são usados

em situações similares. Porém, se seguirmos com a definição do PMI, podemos distinguir

programas e projetos em alguns fatores básicos:

a) Programas podem incluir atividades operacionais que não são partes de nenhum

programa, 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 rum 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.

Existem questões no gerenciamento de múltiplos que devem ser endereçadas para se

beneficiariam enormemente de avanços e adequações nas metodologias.

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 todos 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 %

Equipe = 30,2 %

Forte predominância de

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

projetos

6 meses > 50% Baixa duração dos

projetos

Complexidade dos

projetos

Baixa > 50% Maior concentração de

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%

Satisfação do Cliente > 31 %

Visão voltada ao cliente.

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

10,08%

28,68%

2,33%

15,50%

10,85%

4,65%

27,91%

0,00%

5,00%

10,00%

15,00%

20,00%

25,00%

30,00%

35,00%

Industria TI Telecom Petroleo eGas

Serviços Finanças Outros

Figura 8 - Segmento da Empresa



4.1.2.3.2 Quanto ao Tipo de Projeto

47,29%

11,63% 11,63%

16,28%13,18%

0,00%

5,00%

10,00%

15,00%

20,00%

25,00%

30,00%

35,00%

40,00%

45,00%

50,00%

TI Organizacional DesenvProdutos

Prestação deServiços

Outros

Figura 9 – Tipo de Projeto

4.1.2.3.3 Quanto a Atuação no Projeto

69,77%

30,23%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

Gerente Equipe

Figura 10 – Atuação no Projeto



4.1.2.3.4 Quanto a Quantidade de Projetos Simultâneos

4,65%

62,79%

12,40%

20,16%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

1 2 - 5 5 - 10 > 10

Figura 11 – Quantidade de Projetos Simultâneos

4.1.2.3.5 Quanto ao Volume de Projetos

61,24%

0,78%

37,98%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

Aumento Diminuído Estável

Figura 12 – Volume de Projetos



4.1.2.3.6 Quanto aos Recursos Alocados

Figura 13 – Recursos Alocados

25,58%

56,59%

17,83%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

< 5 5 - 20 > 20

4.1.2.3.7 Quanto a Duração Média dos Projetos

13,18%

32,56%

54,26%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

< 3 3 - 6 > 6

Figura 14 – Duração Média dos Projetos (meses)



4.1.2.3.8 Quanto a Complexidade dos Projetos

Figura 15 – Complexidade dos Projetos

29,46%

69,77%

0,78%0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

Alta Média Baixa

4.1.2.3.9 Nível de Stress

86,82%

10,08%3,10%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%

Mais Igual Menos

Figura 16 – Nível de Stress



4.1.2.3.10 Quanto ao Critério de Sucesso

33,33%

12,40%

6,20%

31,01%

17,05%

0,00%

5,00%

10,00%

15,00%

20,00%

25,00%

30,00%

35,00%

Terminar noPrazo previsto

Ficar dentro doOrçamento

Cumprir aQualidadeesperada

Satisfazer oCliente

Traz oBenefício a que

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

Média de projetos individuais: 5,2

Média de projetos múltiplos: 4,6

Informantes com

experiência média nos

dois tipos de

gerenciamento

Gerenciamento

simultâneo

de 2 a 3 projetos = 51%

de 4 a 6 projetos = 26%

Taxas razoáveis de

gerenciamento de

multiprojetos a nível

individual

Negócio principal das

organizações

Serviços + Informática = 51%

Indústria = 25%

Forte concentração em

áreas ligadas a serviços

(> 50%)

Características dos

projetos individuais

Sistemas + Prest. de Serviços =

62%

Forte predominância de

projetos "soft" em

relação a outros tipos

Grau de complexidade Nível Médio = 53,8%

Nível Alto = 40,6%

Forte grau de

complexidade dos

projetos

Grau de Incerteza de

prazos e custos

Nível Médio = 62,3%

Nível Alto = 25,5%

Alto grau de

complexidade dos

projetos

Índice de sucesso em

prazo

Baixo + Médio = 80% nos

projetos grandes

Índice pouco satisfatório

Piora na medida que

cresce o porte do projeto


custos

Baixo + Médio = 78% nos

projetos grandes

Índice pouco satisfatório

Piora na medida em que

cresce o porte do projeto


qualidade

Médio + Alto = 90% nos projetos

médios e grandes

Índice satisfatório

Não varia muito em

função do porte do



Projeto

Interdependência técnica

e de recursos entre

projetos

Nível Médio + Alto = 75% Altos índices de

interdependências entre

projetos

Recursos alocados "full-

time"

10 a 25% = 40% dos projetos Baixa taxa de dedicação

dos recursos em tempo

integral aos projetos

Agrupamento dos

projetos do Portfólio

Por Produto + Por Estratégia =

63%

Agrupamento com

enfoque voltado a

resultados

Estrutura organizacional Matriz Projetizada + Time de

projeto = 50% das empresas

Tendência para o

enfoque de times de

projeto, poucas

estruturas funcionais

Níveis de planejamento

de Portfólio

Médio Prazo (eventual + sempre)

= 76%

Longo Prazo (eventual + sempre )

= 50%

Maior foco em curto em

médio prazo

Metodologia de Gerência

de Projeto

Modelo específico de cada

Departamento = 15 %

Maior foco no Gerente

do projeto ou corporativa

Prioridade dos projetos

do Portfólio

Benefício Estratégico = 56% Visão estratégica é

predominante

Uso de Gerente auxiliar

para multiprojetos

Não = 60% Taxa média/baixa de uso

Conceito de Gerência de

Portfólio

Eventual + regular = 74 % Aplicação do conceito

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.


http://www.stage-gate.com/pdfs/Working Paper 11.pdf


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:

2. Qual o tipo predominante de projetos em que você atua?

3. Qual é a sua atuação predominante nos projetos:

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

5. Esse número tem:

6. Quantas pessoas em média participam desses projetos?

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

8. Qual é a complexidade média dos projetos em que participa?

9.

10. Ordene os critérios de sucesso mais valorizados na sua empresa, ranking de 1 a 5:

Terminar no Prazo previsto 1 - maior valorFicar dentro do Orçamento 5 - menor valorCumprir a Qualidade esperada

Satisfazer o Cliente

Traz o Benefício a que se propõe

Como se compara o nível de stress na participação de Múltiplos Projetos com a participação em Projetos Únicos?

Industria TI Telecom Petróleo e Gás Serviços Finanças Outros

Gerente Equipe

1 2 - 5 5 - 10 > 10

Aumentado Diminuído Permanecido Estável

OrganizacionalTI Desenv. de Produtos Prestação de Serviços Outros

< 5 5 - 20 > 20

< 3 3 - 6 > 6

Alta Média Baixa

IgualMais estressante Menos estressante

tcc multiplos projetos-rp

Documents

eventual sempre

rio de janeiro

fcil de medir

levantamento

segmento de

este captulo

project management

project management