TCC_Gerenciamento de Multiplos Projetos

8/14/2019 TCC_Gerenciamento de Multiplos Projetos

1/89

Gerenciamento de Mltiplos Projetos TCC GP09 RJ / FGV

Todos os direitos reservados 1

ROBERTO HENRIQUE NOGUEIRA PONSANDR LUIZ CATALDO FALBO SANTO

GERENCIAMENTO DE MLTIPLOS PROJETOS

Monografia apresentada ao curso MBA em

Gerncia de Projetos, Ps-Graduaolato-

sensu, da Fundao Getulio Vargas comorequisito parcial para a obteno do Grau deEspecialista em Gerncia de Projetos.

MONITOR: Prof. Edmarson B. Mota

Rio de JaneiroOutubro / 2004


2/89



RESUMO

Muito se fala, se escreve e se discute em relao ao gerenciamento de projetos

atualmente. As associaes profissionais crescem rapidamente, o consciente coletivo pe em

pauta o tema nos crculos administrativos e operacionais, e vrios indcios mostram que atendncia a discusso aumentar.

No entanto, o ambiente que se encontra nas organizaes atualmente ainda mais

complexo, em vista do crescimento absurdo das iniciativas e aes necessrias para reagir s

inmeras mudanas 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 nmero de projetos que as organizaes tm que realizar, diga-se de

passagem, com sucesso.

Esse na verdade o ambiente de mltiplos projetos, que proporciona um desafioinadivel para administradores, gestores e gerentes. A questo passa ser agora no somente o

sucesso de um projeto individual, mas tambm o sucesso do conjunto, ou coleo de projetos

da organizao.

O nosso objetivo, neste trabalho, apresentar as diferentes vises do ambiente de

mltiplos projetos: estratgico, ttico e operacional, com foco nesse ltimo. pensando nos

gerentes e equipes que ficam se dividindo entre os mltiplos projetos em que esto

envolvidos, que desenvolvemos este trabalho, procurando reunir conceitos e trazer novas

idias para ajudar a vencer esse novo paradigma. Aliando uma extensa pesquisa bibliogrfica

e a realizao de uma pesquisa de campo nossa experincia prpria, pudemos dar a nossa

viso e sugerir tcnicas e processos para ajudar essas pessoas nesse desafio.

Palavras-chave: mltiplos, projetos, gesto, gerenciamento, portflio.


3/89



ABSTRACT

Much is said and written about project management today. Professional associations

grow at fast rates and the topic is discussed more and more in administrative and operational

circles. And the heat is on.

In addition, the organizational environment today is even more complex, in face of the

incredible growth in the number of actions necessary to deal with an ever changing world. IT

is an area especially affected by this reality, and deserves a deeper analysis in this work. The

result, of course, is the exponential increase in the number of projects that organizations must

implement, note, with success.

This is actually the picture of the multi-project environment, which poses an

unavoidable challenge to administrators and managers. The issue becomes not only achieving

success of an individual project, but the success of the group of projects of the organization.

Our objective in this work is present different views of the multi-project environment:

the strategic, tactical, and operational, with the emphasis on the latter. It was thinking on the

managers and teams that have to address the multiple projects they are involved in, that this

work was developed, looking to bring together concepts and new ideas to help overcome this

paradigm shift.

Adding an extensive bibliographical and field research to our own experience, we

believe we were able to bring our contribution to the subject, as we suggest techniques and

processes to help people with this challenge.

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


4/89



SUMRIO

RESUMO...............................................................................................................................2ABSTRACT.......................................................................................................................3

LISTA DE TABELAS E FIGURAS............................................................................................6LISTA DE ABREVIATURA E SIGLAS......................................................................................7

1 INTRODUO ...............................................................................................................81.1 Cenrio Atual..........................................................................................................81.2 Definio do Problema............................................................................................91.3 Relevncia do Trabalho...........................................................................................91.4 Delimitao do Trabalho.......................................................................................10

2 METODOLOGIA...........................................................................................................112.1 Estruturao do Trabalho ......................................................................................112.2 Os Fins e os Meios...............................................................................................122.3 Limitaes ............................................................................................................13

3 REFERENCIAL TERICO.............................................................................................143.1 A Teoria de Administrao de Empresas..................... ..........................................143.2 Evoluo Histrica da Gerncia de Projetos ..........................................................16

3.2.1 Razes na Histria Antiga ..............................................................................163.2.2 A Era Moderna ..........................................................................................163.2.3 O Novo Ambiente .........................................................................................19

3.3 Tipos de Projetos ..................................................................................................203.3.1 Projetos Pequenos vs. Projetos Grandes...................................... ...................203.3.2 Projetos de Desenvolvimento vs. Projetos de Implantao.......... ...................223.3.3 Projetos Empresariais vs. Projetos de Engenharia e Construo.....................233.3.4 Projetos de TI................................................................................................25

3.4 Extreme Project Management (XPM)................................................. ...................333.4.1 Conceitos XPM.............................................................................................343.4.2 Tcnicas e Ferramentas XPM .............................. ..........................................373.4.3 O Modelo de Gerenciamento XPM................................................................39

3.5 Ambientes de Mltiplos Projetos.......... .................................................................433.5.4 Gesto de Portflio........................................................................................453.5.5 Gerncia de Programas..................................................................................473.5.6 Gerenciamento de Mltiplos Projetos ............................................................493.5.7 Gerenciamento do Tempo............. .................................................................54

3.6 O Mtodo da Cadeia Crtica ........... .......................................................................57

3.6.1 A Teoria das Restries.............................................................. ...................573.6.2 CCM vs. CPM...............................................................................................583.6.3 CCM no Ambiente de Mltiplos Projetos ......................................................59

4 ANLISE DE RESULTADOS.........................................................................................604.1 Pesquisa de Campo I .............................................................................................60

4.1.1 Avaliao Geral da Pesquisa I .......................................................................604.1.2 Tabulao e Anlise dos Dados Pesquisa I..................................................61

4.2 Pesquisa de Campo II......................................................................... ...................67


5/89



4.2.1 Sumrio dos Dados Descritivos .................................................. ...................684.3 Avaliao dos Resultados e Concluses ................................................................70

5 CONCLUSES .............................................................................................................705.1 A Importncia do estudo de Mltiplos Projetos para a Organizao.......................705.2 A Gerncia de Mltiplos Projetos e a Teoria de Administrao de Empresas.........72

5.3 Conceitos Bsicos para Gerenciar Mltiplos Projetos com Sucesso.......................735.4 XPM em Mltiplos Projetos........... .......................................................................755.5 Ferramentas para Mltiplos Projetos .................................................. ...................765.6 PMBOK e Mltiplos Projetos............... .................................................................785.7 Abordagem para Mltiplos Projetos de TI ................... ..........................................795.8 Consideraes Finais................................................... ..........................................82

6 BIBLIOGRAFIA............................................................................................................84

7 ANEXOS ......................................................................................................................897.1 Anexo I Pesquisa de Campo...............................................................................89


6/89



LISTA DE TABELAS E FIGURAS

Tabela 1 Projetos de Engenharia vs. Empresariais

Tabela 2 Tecnologia em projetos

Tabela 3 Sumrio 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 aplicao das Rguas de Sucesso

Figura 04 Estratgia Monoltica

Figura 05 Estratgia por Verses

Figura 06 Estratgia Evolutiva

Figura 07 Portflio, Programas e Projetos

Figura 08 Segmento da Empresa

Figura 09 Tipo de Projeto

Figura 10 Atuao no Projeto

Figura 11 Quantidade de Projetos Simultneos

Figura 12 Volume de Projetos

Figura 13 Recursos AlocadosFigura 14 Durao Mdia dos Projetos

Figura 15 Complexidade dos Projetos

Figura 16 Nvel de Stress

Figura 17 Critrio de Sucesso

Figura 18 Mltiplos Projetos no Contexto da Organizao


7/89



LISTA DE ABREVIATURA E SIGLAS

AM Agile Modeling (Modelagem gil)

ARPANET Advanced Research Project Agency NetworkBCS 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 Organizao do Tratado do Atlntico NorteP&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 DevelopmentRAP Rapid Planning

RUP Rational Unified Programming

TI Tecnologia da Informao

TOC Theory of Constraints

UML Unified Modeling Language

WBS Work Breakdown Structure

XP Extreme Programming

XPM Extreme Project Management


8/89



1 INTRODUO

A escolha do tema de Gerenciamento de Mltiplos Projetos foi influenciada por vrios

fatores. Alm de ser um assunto contemporneo, alis, muito recente nas discusses eliteratura, 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, alm de estar envolvido em vrias outras atividades, como consultoria e

treinamento. O outro autor especialista em desenvolvimento de projetos de software,

liderando vrios projetos simultneos em um grande provedor internet. Os desafios

encontrados nos aspectos estratgicos, tticos e operacionais do tema so objetos deste estudo,

sendo que a nfase ser na estratgia para lidar com os conflitos e as dificuldades de se

gerenciar mltiplos projetos com recursos limitados e compartilhados, sob o ponto de vista

operacional.

1.1 Cenrio Atual de conhecimento pblico e notrio que a velocidade de mudanas no mundo de hoje

em todas as reas, seja empresarial, tecnolgico, educacional, governamental, social, muito

maior do que no passado, sendo que ela continua aumentando e acelerando cada vez mais. A

facilidade de comunicao, as restries de recursos, a competio, alm de vrios outros

fatores que sero discutidos no decorrer deste trabalho, contribuem para essa mudana de

ambiente, colocando forte presso nas organizaes.

Existe um consenso h cerca de vinte anos sobre o conceito de Porter (1986) de que as

mudanas no ambiente foram as organizaes a se reposicionarem no mercado para garantir

a sua sobrevivncia, revendo a sua estratgia competitiva e consequentemente criando novos

planos de ao para alcanar as novas metas estratgicas. Como os planos de ao se

resumem a um conjunto selecionado de projetos, fica claro o entendimento que no cenrioatual de grandes mudanas, o nmero de projetos necessrios para acompanhar o ritmo de

mudana aumentou absurdamente, em todas as reas.


9/89



1.2 Definio do ProblemaQuando o assunto mltiplos projetos discutido, preciso entender melhor o que se

quer dizer com esse termo, pois afinal existem vrias perspectivas sobre o tema. Existe a viso

estratgica, que se refere Gesto de Portflio, ou carteira de projetos da organizao; a

viso ttica que trata da Gerncia dos Programas, e finalmente a viso operacional, onde

gerentes e integrantes de equipes esto alocados em vrios projetos simultaneamente, que ser

referido neste trabalho como Gerenciamento de Mltiplos Projetos. Todas as trs vises sero

abordadas no estudo. Porm, as duas primeiras, de Portflio e Programas, j contam com uma

discusso um pouco mais amadurecida na literatura, sendo alvo de vrios estudos e com

questes mais estabelecidas. A viso 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

estratgias para facilitar o exerccio das funes nesse ambiente.

Pretendemos ajudar a responder algumas perguntas cruciais sobre o gerenciamento de

mltiplos projetos, como:

- Quais so os fatores crticos de sucesso no gerenciamento de mltiplos projetos?

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

- Quais tcnicas e ferramentas devo utilizar para facilitar o processo?

- Como prevenir a alocao alm da nossa capacidade de realizao?

Decorrente de nossas experincias profissionais, verificamos que a rea de TI tem

grande afinidade com essas questes, sendo um de nossos objetivos nesse estudo fazer um

paralelo das questes abordadas para o gerenciamento de mltiplos projetos em geral com o

ambiente especfico de TI.

1.3 Relevncia do TrabalhoA relevncia do tema evidente, uma vez constatada que a realidade na grande

maioria das organizaes atualmente o ambiente de mltiplos projetos, onde os recursos so

limitados e precisam ser compartilhados entre projetos e departamentos, como demonstra

Chaves (2004) em sua dissertao sobre o tema. So menos freqentes os projetos que tm o

privilgio de receber recursos dedicados, em funo de seu porte, custo, peso estratgico, ou

complexidade. Mesmo nessas organizaes, existe certamente uma gama considervel de


10/89



projetos que so executados at mesmo em carter 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 questes presentes em praticamente todas as

organizaes, o tema e os objetivos do trabalho vo ao encontro dos anseios dos envolvidos

em projetos simultneos, seja como gerente, equipe, patrocinador ou qualquer outro

stakeholder. Com relao ao aprofundamento na rea de TI, esta uma rea de atuao que

tem tido o maior crescimento na participao do mercado de gerenciamento de projetos, e

como tem forte afinidade com as melhores prticas, a qualifica para receber uma ateno

especial sobre o tema.

Como a literatura ainda apresenta poucas referncias no estudo dessas questes, ainda

h muito ser percorrido sobre o tema. Procurando complementar a referncia bibliogrfica,

decidimos aplicar uma pesquisa de campo sobre o tema de gerenciamento de mltiplos

projetos a profissionais ligados ao assunto. Desta forma, pudemos comprovar algumas

questes tericas 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

aes para melhorar o desempenho e a maturidade das organizaes em seus projetos.

1.4 Delimitao do TrabalhoDa mesma forma que o assunto emergente na literatura e tem um grande espao para

desenvolvimento, no temos a pretenso de esgotar a discusso nem proporcionar todos os

elementos de facilitao dos processos envolvidos. O tema em toda sua plenitude complexo,

envolve todas as camadas organizacionais: estratgica, ttica e operacional, e abrange uma

larga variedade de reas, indstrias e stakeholders.

O foco do trabalho est no mbito operacional, portanto, as outras vises estratgica

e ttica - so abordadas de forma descritiva, no referencial terico do trabalho, para maior

esclarecimento do fluxo lgico e encadeamento da discusso, dando base para os argumentos

e colocando a questo principal na perspectiva correta. No est previsto no escopo deste

trabalho, a anlise da relao das caractersticas do ambiente multiprojeto com a estrutura

organizacional da empresa, que j foi abordado com competncia por Chaves (2004).

Tampouco tem esse trabalho o objetivo de desenvolver metodologias especficas para

aplicao direta nas organizaes, que por sua vez, devem utilizar esse estudo como mais um

insumo na criao das mesmas.


11/89



2 METODOLOGIAEste captulo tem por objetivo descrever a metodologia utilizada neste trabalho. De

acordo com a taxionomia sugerida pela coordenao da FGV, utilizamos a seguinte

abordagem.

2.1 Estruturao do TrabalhoEste trabalho est estruturado em 7 blocos:

1. Introduo: Este captulo analisa o cenrio atual e definindo a Definio doProblema a ser estudado. A partir destes pontos estabelecemos os Objetivos da

Pesquisa, formulando algumas Questes a serem investigadas. Segue-se discusso

da justificativa e a Relevncia do Trabalho.

2. Metodologia: Este captulo descreve a metodologia e a estrutura do trabalho.3. Referencial Terico: Este captulo procurou organizar a investigao da literatura

em 6 blocos de conceitos fundamentais para o entendimento da questo problema

do trabalho. O primeiro aborda os conceitos ligados a viso geral sobre o contexto

de administrao empresarial e seu relacionamento com gerenciamento de

projetos. No segundo bloco abordamos uma viso histrica 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 sobreExtreme Project Management (XPM). O quinto bloco aborda os vrios ambientes

de mltiplos projetos, e por fim, no sexto, apresentada a Teoria das Restries e

o Mtodo da Cadeia Crtica como alternativa de gerenciamento de mltiplos

projetos.

4. Analise dos resultados da pesquisa: Este captulo descreve o processo deobteno dos resultados, por meio das seguintes fases:

a. Trabalho sobre a amostra obtida, utilizando-se uma estratgia de filtragem,seleo e processamento dos dados obtidos na pesquisa;

b. Tabulao dos dados pesquisados;c. Anlise dos resultados da pesquisa, comparao com outra pesquisa j

existente;

d. Concluso.


12/89



5. Concluses: Este captulo descreve o que os autores desejam contribuir de seusestudos e pesquisas, fazendo o relacionamento entre tcnicas, ferramentas e

caractersticas de projetos com o tema de gerenciamento de mltiplos projetos.

6. Referncias Bibliogrficas: Relao de autores, livros, artigos e demais trabalhoscientficos utilizados no Referencial Terico e em outras partes do trabalho.

7. Anexos: Como documento complementar est includo no Anexo, o Modelo doFormulrio de Pesquisa utilizado.

2.2 Os Fins e os MeiosUtilizamos uma metodologia mista tanto nos fins, quanto nos meios para desenvolver

o trabalho. Quanto aos fins, temos basicamente trs tipos:

o

Exploratria: como o tema de gerenciamento de mltiplos projetos tem poucoconhecimento acumulado e estruturado, procuramos explorar o assunto em vrias

dimenses.

o Explicativa: como os resultados obtidos no gerenciamento de mltiplos projetos

so em geral insatisfatrios, ocorrendo fenmenos de forma sistematizada,

procuramos esclarecer os motivos dessas ocorrncias e os fatores que contribuem

para o grau de insucesso existente.

o Aplicada: motivados a proporcionar uma viso mais clara da realidade dos

mltiplos projetos, procuramos tambm resolver o lado prtico, oferecendo vriasaes e solues para os problemas encontrados no dia a dia.

Quanto aos meios, preferimos utilizar dois principais, que so:

o Pesquisa de Campo: fizemos uso da oportunidade de realizar uma investigao

emprica com elementos representativos do tema para podermos aferir, localizar e

sedimentar o conhecimento especfico que trata o tema, j que o assunto no tem

uma unanimidade acadmica. Utilizamos tambm outra pesquisa realizada

anteriormente como referncia adicional.

o Pesquisa Bibliogrfica: Parte fundamental do trabalho, a pesquisa bibliogrficana literatura necessria como ponto de partida e referencial conceitual para

comprovar e inspirar as solues apresentadas ao final.


13/89



2.3 LimitaesA maior limitao da pesquisa de campo realizada a pouca quantidade de questes

questionadas, em funo do pouco tempo disponvel para o preenchimento das respostas.

Porm, acreditamos que os resultados foram bastante satisfatrios dentro do contexto em que

foi realizada, e contribui para a extenso do conhecimento sobre o assunto, procurando

auxiliar os envolvidos neste tipo de ambiente a entenderem algumas das motivaes e causas

dos problemas encontrados.

Procurando minimizar a deficincia 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 Gesto dos conflitos de recursos humanos entre os processos e

projetos, 2004), apresentados na seo seguinte, de Anlise de Resultados.


14/89



3 REFERENCIAL TERICOEsta parte do trabalho procura apresentar os assuntos pertinentes ao tema em estudo

que servem como base de referncia terica encontrada na literatura cientfica para a evoluo

e discusso do problema apresentado. Posteriormente, na concluso do trabalho, as

referncias sero usadas para fundamentar os argumentos apresentados para o avano do

conhecimento no tema, apresentando solues e idias inovadoras, ou formas diferenciadas de

se abordar a questo do gerenciamento de mltiplos projetos.

3.1 A Teoria de Administrao de EmpresasOs autores acreditam que existem muitas semelhanas entre os conceitos de

administrao de empresas e o gerenciamento de projetos, especialmente o gerenciamento de

mltiplos projetos. Dessa forma, apresentamos uma descrio resumida da teoria de

administrao empresarial e os papis dos vrios nveis de administradores, para

posteriormente fazer uma analogia com mltiplos projetos e os respectivos gerentes de

projetos. Havendo o paralelo, podemos rever as tcnicas e caractersticas usadas na

administrao que poderiam ser aplicados tambm no gerenciamento de mltiplos projetos,

especialmente quando estamos lidando com a administrao de vrios empreendimentos ou

organizaes simultaneamente. Lundgren (1974) em sua obra Organizational Management

Systems and Process, descreve a universalidade da filosofia, teoria conceitos da

administrao organizacional, mapeando os papis e responsabilidades nos diversos nveis da

gesto e gerncia corporativa. Ele apresenta vrias definies do termo administrao, at

chegar formal, que : Administrao a fora que, atravs do poder de deciso 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 organizao.

Podemos j detectar palavras-chaves que encontram grande sinergia com o gerenciamento de

projetos deciso, conhecimento, integrao, processos, elementos, planejamento, objetivos.

A filosofia de administrao um guia genrico que determina como uma organizaovai ser gerenciada e afeta cada faceta de sua operao, ajudando a construir a cultura

organizacional. A organizao considerada um sistema aberto, onde o ambiente externo

exerce influencia sobre o funcionamento e a sobrevivncia do sistema, que por sua vez, reage

para manter o equilbrio do sistema. De acordo com a anlise clssica de sistema, um sistema

fechado est isolado de qualquer manifestao externa e tende entropia e disfuno, pois


15/89



no tem a habilidade de utilizar novos recursos e energia de fora sua unidade para manter o

equilbrio interno. Um projeto tambm est sempre procurando o equilbrio de seguir o plano

original, reagindo s interferncias do ambiente para chegar ao seu objetivo. Assim como em

projetos, a administrao empresarial precisa a todo custo controlar os elementos que levam

manuteno do equilbrio dinmico interno, e para isso precisa utilizar recursos e informaesque possibilitem ajustes necessrios aos seus sistemas em resposta s mudanas do ambiente

externo. Esse o grande desafio da administrao. Para ter sucesso nessa funo, ela precisa

de informao confivel e no tempo adequado, utilizando para isso sistemas de retorno, ou

feedback.

Outra questo importante de abordar no tema de administrao so os nveis de

responsabilidade dentro de uma organizao, que variam de acordo com o nvel hierrquico

dentro da sua estrutura organizacional. Nem todos na administrao tm a mesma

responsabilidade. Existem trs nveis gerenciais distintos dentro de organizaes mais

complexas: a alta administrao, a gerncia intermediria e a gerncia operacional. Na

primeira esto o presidente, vice-presidentes, diretores, superintendentes, e outros ligados ao

plano estratgico da organizao. No nvel gerencial intermedirio esto normalmente os

gerentes funcionais, que esto mais ligados no plano ttico, e no operacional se encontram os

coordenadores, chefes de seo, etc. Apesar de que a titulao de cargos no distinguir

claramente a que grupo o administrador pertence, as responsabilidades e os seus afazeres o

fazem. No nvel mais alto, os administradores se confrontam com grandes doses de incertezas

e lidam diretamente com as influencias do ambiente. Estabelecem a direo e a estratgia da

empresa, determinando o seu rumo geral. A gerncia intermediria coordena a produo,

serve de interface entre a operao e a alta administrao. Estabelece as metas de acordo com

os objetivos mais genricos estabelecidos pelo Plano Estratgico feito pela alta administrao.

A gerencia operacional realiza o trabalho com seus recursos. Todos os trs nveis so

interdependentes e se relacionam constantemente.

Vale comentar que no caso de grupos empresariais, teremos mais nveis acima do

presidente da empresa, pois pode haver um conselho administrativo do grupo, ou holding, querevisa e agrupa os interesses comuns do grupo, em prol de uma macro-estratgia que rege

todo o grupo. A mensagem principal que quanto maior e mais complexa for a organizao,

mais nveis de administrao so necessrios, compartilhando a responsabilidade e

distribuindo a administrao em componentes cada vez menores.


16/89



3.2 Evoluo Histrica da Gerncia de ProjetosDiscutir as origens do tema de gerenciamento de projetos importante para

compreender muitos dos conceitos atuais e vai ajudar no entendimento deste trabalho. A

herana cultural, os dogmas e paradigmas de cada poca vo nos municiar de ricos elementospara construir alguns dos argumentos chave da discusso que se seguir.

3.2.1 Razes na Histria AntigaProjetos no novidade para o ser humano. A capacidade de alterar o ambiente seu

favor e usar da inteligncia para desenvolver solues inovadoras para os problemas e

necessidades da sociedade existe h muito tempo. Thomsett (2001) observa que o conceito do

desenvolvimento de tecnologia pode ser traado desde o perodo Neoltico (~10.000 anos

atrs), que marcou a transio da caa para agricultura e domesticao de animais. Com essamudana, a evoluo da engenharia, por assim dizer, acelerou, alcanando um primeiro pico

durante o antigo reinado do Egito antigo (3,000 bc), com o desenvolvimento de sistemas de

irrigao e esgoto, barcos, canais e claro, as inesquecveis pirmides. Em relao s

pirmides, Cleland (1999) destaca as grandes propores desse projeto, de grande esforo

humano e custo. Estima-se que cerca de 100,000 trabalhadores levaram 30 anos para

complet-las. Projetos de grande porte tambm eram realizados em outras civilizaes, como

na Mesopotmia, China e Grcia. Outros feitos de grandes propores exemplificam a

evoluo os projetos com a Grande Muralha da China (300 bc), as campanhas militares deAlexandre o Grande, as realizaes do Imprio Romano, o templo de Jerusalm e porque no

as Sete Maravilhas do Mundo Antigo?

3.2.2 A Era ModernaHenry Laurence Gantt, um engenheiro mecnico fez uma grande contribuio para a

disciplina de gerenciamento de projetos em 1917 com a criao do famoso Grfico de Gantt,

um tipo de grfico 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

atmica. Richard Rodes (The Making of the Atomic Bomb, New York, Touchstone Books,

1995) documenta que o projeto estava em grandes dificuldades at que a liderana foi

separada entre o gerenciamento do projeto (custo, prazo, escopo) liderado pelo general Leslie


17/89



Groves, e o gerenciamento tcnico, liderado pelo Dr. Robert Oppenheimer. Esta distino foi

um marco para o gerenciamento de projetos, pois at ento era sempre o arquiteto ou

especialista tcnico que era responsvel 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, oarquiteto pode ficar to envolvido com os desafios tecnolgicos 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 decorrncia da presso do

governo americano por uma corrida de desenvolvimento tecnolgico durante a Guerra Fria.

Essa presso foi detonada pela crise do Sputnik em 1957, quando a Unio Sovitica lanou

com sucesso o satlite Sputnik 1, enquanto os EUA haviam falhado em dois lanamentos

anteriores. Esse fato gerou uma reao forte dos americanos, que resultou em vrias

iniciativas do Departamento de Defesa (DOD), tais como:

o A corrida espacial, com a criao da NASA em 1958;

o Aumento drstico do fomento pesquisa cientfica, aumentando em 1959 o oramento

da Fundao Nacional de Cincias americana de 34 para 134 milhes de dlares;

o Criao do Programa de Msseis Polaris, com a construo de um submarino nuclear

para diminuir a diferena em relao ao arsenal russo. O Almirante Raborn da marinha

americana tinha urgncia para realizar o programa e as ferramentas de gerenciamento

de projetos tradicionais no eram suficientes para garantir a entrega do projeto. O

DOD ento 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 concluso de um projeto. A utilizao do PERT se

tornou obrigatrio para todos os projetos da marinha Americana.

o A Agncia de Pesquisa Avanada de Projetos de Defesa do Pentgono 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 avanos foram desenvolvidos no gerenciamento de

projetos. A DuPont criou o CPM (Critical Path Method), ou Mtodo do Caminho Crtico, que

amplamente usado atualmente, para identificar quais so as atividades crticas de um projeto

que podem atras-lo. O PERT foi depois estendido para o WBS (Work Breakdown Structure),

tambm conhecido com Estrutura Analtica do Projeto. O mtodo tradicional do Caminho


18/89



Crtico se estendeu para a conhecida Cadeia Crtica, que baseada na Teoria das Restries,

criada por Eliyahu M. Goldratt.

PMI

A fundao do PMI (Project Management Institute) em 1969 sintomtica da

evoluo e da formalizao da disciplina nesse perodo. Os cinco voluntrios fundadores j

reuniram naquele mesmo ano em seu primeiro simpsio realizado em Atlanta, Gergia, 83

pessoas. Atualmente o instituto tem mais de 139 mil scios (PMI 2004), certifica profissionais

como PMPs (Project Management Professional) no mundo inteiro, desenvolve padres para a

profisso, como Um Guia de Conjunto de Conhecimentos de Gerenciamento de Projetos

(PMBOK) e outros, promove seminrios, simpsios e congressos internacionais, publica

livros, revistas e jornais sobre o assunto e tem uma fundao educacional (PMI Educational

Foundation).

Anos 60 a 90

Esse perodo que caracteriza aproximadamente a durao da Guerra Fria, que

comeou no ambiente ps 2 Guerra e se encerrou no desmembramento da Unio Sovitica

em 91, influenciou muito o rumo tomado na evoluo do gerenciamento de projetos.

J vimos como no incio desse perodo houve uma grande demanda nos Estados

Unidos (que o pas onde se iniciou o movimento e at hoje a mola mestre do crescimento

do tema), pelo desenvolvimento de grandes projetos tecnolgicos estimulado pelo governo e

poder militar. O gerenciamento de projetos se formalizou e associaes profissionais surgiram

para fomentar mais o conhecimento e a evoluo do tema. No incio do perodo, como declara

Kerzner (2001) somente as indstrias aeroespacial, construo e defesa adotaram a

formalizao do gerenciamento de projetos, utilizando as tcnicas recm desenvolvidas. O

restante das empresas continuou gerenciando com mtodos informais, tendo como gerentes de

projetos sempre as lideranas funcionais, que mantinham a sua forma tradicional de trabalho.

Nos anos 70 e 80, cada vez mais empresas comearam a migrar para o gerenciamentoformal, devido ao aumento da complexidade e magnitude de seus projetos, a ponto de ficarem

ingerenciveis com os mtodos informais. A evoluo da tecnologia tambm foi um fator que

influenciou muito no aumento dessa complexidade e tornou os projetos de maior risco.

Porm, as metodologias em prtica nesse perodo refletiam os tipos de projetos que


19/89



predominavam na poca, de grande porte, longa durao e altos custos, utilizando uma

estrutura tradicionalmente linear, ou monoltica de gerenciamento.

Nos anos 80, iniciou-se um movimento de mudana de percepo e novos

pensamentos surgiram. Foi a poca do surgimento de Porter (1986) com sua teoria de

estratgia competitiva e de Tom Peters (1982) com a mudana de foco para as pessoas no

sucesso da empresa, e outros. Foram os precursores de um novo ambiente.

3.2.3 O Novo AmbienteO perodo ps Guerra Fria trouxe uma nova era, a da Globalizao, a partir dos anos

90. Com a abertura dos mercados internacionais, a evoluo acelerada da tecnologia e a

facilidade da comunicao, um boom econmico aconteceu. Certamente o surgimento e a

proliferao da Internet aceleraram o processo, aumentando muito o ritmo de mudanas no

ambiente. Como coloca Thomsett (2001), novos fatores como a mudana da relao entre

funcionrios e empresas, o fim da lealdade mtua como a conhecamos no passado (ou talvez

nossos pais), o aumento da competitividade e do nvel de exigncia do consumidor mudaram

o jogo. O ambiente empresarial se tornou turbulento e mais catico, demandando novos

produtos mais rpidos das empresas que quiserem sobreviver e se destacar num mercado cada

vez mais disputado.

O gerenciamento de projetos ganha novos aliados nesse perodo, que Kerzner (2001)delineia com preciso. O argumento durante a recesso americana de 1989 a 1993, quando

as dificuldades aumentaram, novas solues apareceram, como a engenharia simultnea, que

reforou a importncia do gerenciamento de projetos. Os anos seguintes foram marcados pelo

reconhecimento que gerenciar bem projetos era estratgico para a sobrevivncia das empresas

e o investimento na rea tem aumentado desde ento. Porm, o perfil dos projetos e a relao

entre os gerentes de projetos e a administrao tambm mudou, evidenciando uma mudana

de paradigma, como veremos a seguir.


20/89



3.3 Tipos de ProjetosProjetos vm em todas as cores, sabores, tipos e tamanhos. Antes de entrarmos na

discusso do gerenciamento de mltiplos projetos, vamos analisar a prpria natureza dos

projetos, os vrios tipos e caractersticas que possam nos ser til no momento de discutir a

melhor forma de gerenci-los, ainda mais de forma simultnea.

3.3.1 Projetos Pequenos vs. Projetos GrandesTamanho documento? Em se tratando de projetos, podemos dizer que sim. Porm,

Thomsett (2002) diz que no existe o tal pequeno projeto, numa aluso de que um pequeno

projeto mal gerenciado pode se tornar um grande problema e ento acaba virando um grande

projeto. Realmente, ningum nega que muitas vezes detalhes ignorados ou simples tarefas mal

executadas podem ter um efeito domin que trar grandes prejuzos mais tarde. Vamos ver

como a literatura trata ento a gerncia de pequenos projetos. Cleland e Ireland (2000)

propem um simples protocolo de regras bsicas de como pequenos projetos podem ser

gerenciados, iniciando com a identificao da necessidade, passando pelo planejamento do

projeto, coletar informaes, analisar dados, desenvolver e avaliar alternativas para solucionar

o problema e finalmente apresentar recomendaes. Eles observam que um pequeno projeto

deve ser gerenciado utilizando-se uma verso simplificada da maioria dos conceitos,

processos e tcnicas 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 durao entre 3 e 12 meses, custos

entre US$ 5 mil e US$ 1,5 milho em no mais do que 3 ou 4 centros de custos e que no

tenha mais do que 3 nveis na decomposio do projeto pelo WBS. Existe contnua

comunicao entre os membros da equipe, onde o gerente do projeto trabalha em contato

dirio com recursos de reas funcionais, dispensando relatrios detalhados em intervalos

curtos. O controle de custos pode ser feito manualmente em vez de por sistemas

informatizados.

Embora no exista um consenso na literatura sobre o ponto de corte de quando um

projeto deixa de ser pequeno, existe a idia comum de que a equipe deve ser pequena, o prazo

curto, o custo baixo, assim como o esforo 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 atuao, a indstria e outros fatores de influncia.


21/89



No outro extremo, Kerzner (2001) assinala que mega-projetos tm caractersticas

particulares, como a alocao de um grande nmero de pessoas por perodos curtos e intensos

e possveis re-estruturaes organizacionais quando o projeto muda de fase no ciclo de vida,

podendo, por exemplo, alternar de uma estrutura matricial para projetizada. Alerta tambm

para o risco de uma empresa, ao pegar um grande projeto, alocar os melhores recursos para otal projeto, pondo em risco outros em andamento. Concentrar esforos e energia em um s

lugar tambm pode ser perigoso para a empresa, que fica vulnervel e instvel. normal esses

projetos demandarem esforo extra dos funcionrios por tempo prolongado, o que causa perda

de produtividade e descontentamento. O conhecimento e experincia em lidar com grandes

projetos vo determinar as chances de sucesso, e a empresa tem que estar preparada para

desenvolv-los sob o risco de colocar a sua sobrevivncia em jogo.

Thomsett (2002) em seu artigo Managing Large Projects A Special Case,

desenvolve o tema destacando que projetos de grande porte no so apenas grandes pequenos

projetos, e sim animais de outra espcie. Eles so mensurados em duas principais vertentes:

esforo de desenvolvimento e durao. A primeira tem um componente de recursos humanos

e outro de custo de capital. Para se ter idia, a escala de esforo humano usada baseada em

nmero 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 milhes e levam pelo menos 2 anos. Para

lidar com eles, deve-s elevar em considerao os seguintes conceitos, que deve ser revistos

para casos como esses:

o critrios de sucesso do projeto;

o tcnicas especiais de gerenciamento de projetos;

o planejamento e controle em tempo real;

o organizao e estrutura das equipes;

o estratgias de desenvolvimento combinadas;

o garantia da qualidade;

o ferramentas de suporte e tecnologia;

o desenvolvimento das equipes; e

o contratos e aquisies.

Para quem se interessa no assunto, vale a referncia, porm para o propsito do nosso

assunto, no necessrio desenvolver mais o tema, ficando claro que existe grande diferena

entre projetos de tamanhos muito diferentes. Certamente, grandes projetos no so candidatos


22/89



ao gerenciamento mltiplo, mais adequado aos pequenos. Porm, nos mdios que paira a

incerteza, sendo necessrios outros critrios para decidir.

3.3.2 Projetos de Desenvolvimento vs. Projetos de ImplantaoOutra diferena relevante entre tipos de projetos a que existe entre projetos de

desenvolvimento, tambm chamados de P&D (Pesquisa e Desenvolvimento), e projetos de

implantao, que esto ligados ao ambiente mais operacional, processual.

Kerzner (2001) destaca que uma das tarefas mais difceis em uma organizao o

gerenciamento de projetos de desenvolvimento (P&D). Estes so normalmente liderados por

cientistas, engenheiros, pesquisadores e outros profissionais, tentando tornar uma idia

inovadora em realidade dentro de prazos, custos e recursos restritos e definidos.

Naturalmente, como os projetos de P&D tipicamente tm um alto grau de incerteza, pela sua

natureza inventiva, conseguir esse feito realmente um desafio. Os responsveis por esses

projetos normalmente so profissionais altamente especializados e tcnicos, com pouco

treinamento nas tcnicas de gerenciamento de projetos. Mesmo para os melhores gerentes de

projetos, uma tarefa muitas vezes herclea realizar algo inovador, lidando com tecnologia

em estado da arte ou ainda sendo desenvolvida, com presso do pessoal de marketing,

finanas 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

tcnica 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) comea, definida, planejada e

executada. E o processo se repete at que os objetivos forem atingidos, ou se descubra que de

fato eram inviveis. 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

realizao da idia que originou o projeto, no nos cumprimentos de metas de custo e prazo.

O rolling wave tem muitas similaridades com as estratgias de planejamento em tempo real e

planejamento por cenrios, discutidas posteriormente neste trabalho. A dica aqui em relao

ao nosso tema evitar envolver o pessoal de P&D em muitos projetos simultneos, por uma

razo restritiva: reduz drasticamente a criatividade, que o elemento fundamental nesse tipo

de projeto.

Projetos considerados de implantao so mais previsveis, representam a realizao

de atividades que tm referncias histricas, so mais lineares e necessitam de menos esforo


23/89



de planejamento, pois se utilizam de modelos existentes. So projetos mais operacionais, de

baixo risco e poucas surpresas. As equipes tm domnio sobre as atividades, esto treinadas

para realiz-las e melhoram seu desempenho a cada novo projeto do tipo que realizam.

Exemplos so instalaes de redes de dados, construes padronizadas, etc. Este tipo de

projeto so os melhores para serem executados de forma simultnea.

3.3.3 Projetos Empresariais vs. Projetos de Engenharia e ConstruoEm funo das mudanas de ambiente j descritas, ficou em evidncia uma nova

classe de projetos, com caractersticas distintas dos tradicionais de engenharia e construo,

que:

o devem ser entregues rpido;

o so de misso-crtica por natureza;

o precisam ser gerenciados em um ambiente turbulento de negcios e tecnologia, e

portanto,

o so sujeitos a constantes mudanas.

Esses tipos de projetos tm se tornado os mais comuns, devido s vrias foras que

aumentam o ritmo de mudana, e podem ser chamados de projetos empresariais, ou business

projects.

Grande catalisador desse processo de mudana, a rea da Tecnologia da Informao

tem influenciado fortemente a evoluo do gerenciamento de projetos empresariais. Sendo

uma nova rea profissional, procurou em outras reas orientao e modelos para ajudar a

formalizar e estabelecer melhores prticas. Os modelos iniciais de desenvolvimento de

software eram muito baseados nos de engenharia e construo. A metodologia clssica de

desenvolvimento de sistemas dos anos 60, descrita nas conferncias da OTAN (NATO

Software Engineering, Naur&Randaell, 1968), foi baseada no conceito tradicional de

progresso linear das fases de anlise, desenho, construo, teste e implementao.Consequentemente, os primeiros modelos formais de gerenciamento de projetos de TI

tambm refletiam os utilizados nas indstrias de defesa e construo.

O conceito de que o gerenciamento do projeto uma disciplina independente do

gerenciamento tcnico do projeto ficou claro na evoluo histrica, especialmente no campo

da engenharia. Contudo, ainda persiste atualmente um mito que sustentado por defensores


24/89



da tradicional escola de gerncia de projetos: de que projetos de engenharia e construo so

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 no pode comear antes que todas as especificaes formais sejam assinadas

pelo cliente, e assim por diante. No entanto, a natureza distinta entre projetos de novosprocessos empresariais, produtos ou sistemas e projetos de construo de prdios, mostra

claramente que outros modelos mais interativos e flexveis so necessrios 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 servios

envolvidos, certificados e com contratos

formais

Grande nmero de provedores envolvidos,

frequentemente com contratos verbais

informais

Especificaes normalmente fixas e

formalizadas

Especificaes flexveis e informais

Padro bem estabelecido de cdigo de tica

e conduta profissional

Cdigo de tica profissional mal

estabelecida

Metodologias bem estabelecidas, baseadas

em princpios matemticos e fsicos

Metodologias conflitantes baseadas em

princpios tericos e de marketing

Produtos fsicos a serem entregues com

componentes modulares

Produtos abstratos a serem entregues, de

difcil modularizao

Indicadores de desempenho claros e

mtricas precisas

Indicadores de desempenho vagos e mtricas

de difcil mensurao

Variao reduzida pelos processos

padronizados e constantes

Variao amplificada pelo individualismo e

unicidade

Tcnicas alternativas como as utilizadas nos conceitos de Extreme Project

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

empresariais.


25/89



3.3.4 Projetos de TIEm muitas organizaes, 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 so (muitos)

mltiplos projetos. Do ponto de vista da equipe, existe um fluxo interminvel de projetos emque eles tem que trabalhar, enquanto os executivos tm a percepo de um alto ndice de

insucessos relacionados aos projetos de TI. As equipes esto estressadas, sobrecarregadas, e

alocadas em vrios 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 negcios est funcionando no ritmo da Internet, alerta o Meta Group

(2002), em referncia ao ritmo acelerado de mudanas que assolam as organizaes. Para se

manterem competitivos, elas precisam responder rpido ao mercado, modificando produtos e

encurtando os ciclos de vida. Lderes de negcios esto sendo pressionados para tomardecises mais rapidamente sobre investimentos em projetos de TI que refletem em seus

negcios e querem ter mais garantias de que o resultado ser positivo.

3.3.4.1 Caractersticas dos Projetos de TIComo j mencionado, projetos de TI atualmente esto muito ligados ao negcio da

organizao e portanto esto tambm sujeitos s mesmas foras que aumentam o ritmo de

mudana, podendo tambm ser chamados de projetos empresariais.O gerenciamento de projetos de software uma tarefa de fundamental importncia no

processo de desenvolvimento de um produto de TI, sendo definido como uma primeira

camada deste processo. O gerenciamento de projeto no visto como uma etapa clssica do

processo de desenvolvimento uma vez que ele acompanha a todas as etapas, da concepo

obteno do produto. (Pressman, 1995).

O PMBOK (2000) define o gerenciamento de projeto como a aplicao de

conhecimentos, habilidades, ferramentas e tcnicas para projetar atividades a fim de satisfazer

ou superar as expectativas dos stakeholders em relao a um projeto.No entanto, so vrios os problemas relacionados ao desenvolvimento de software, os

quais so resultantes da omisso ou do mal uso de metodologias e tcnicas adequadas a esta

importante tarefa de engenharia. Chang & Christensen (1999) citam que so muitos os

problemas dos gerentes de projetos de software para a realizao de grandes sistemas,

incluindo: (i) reunir, treinar e motivar uma grande equipe; (ii) desenvolver ou adotar


26/89



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

orar e monitorar o projeto; (v) identificar e resolver conflitos de recursos e (vi) monitorar o

projeto inteiro continuamente.

Royce (1998) relata o resultado de trs importantes anlises, realizada na metade dos

anos 90, sobre o estado da engenharia de software nas empresas. As trs anlises chegaram amesma concluso, resumida em:

o Desenvolvimento de software ainda altamente imprevisvel. Somente

aproximadamente 10% dos projetos de software so entregues com sucesso

(considerando o oramento e cronograma estimado).

o Disciplina de gerenciamento mais um discriminador do sucesso ou fracasso que

uma tecnologia avanada.

o O nvel de re-trabalho um indicativo de um processo imaturo.

Pressman (1995) afirma que boa parte dos fracassos no que diz respeito aos projetosde software deve-se, principalmente, a problemas de administrao ou gerenciamento do

desenvolvimento de software.

Sommerville (1992) e OConnor (2000) atribuem a dificuldade de gerenciamento de

projetos de software diferena existente em relao a outros tipos de projetos, podendo-se

destacar 5 aspectos:

o Software no palpvel/visvel: quando o produto a ser desenvolvido uma

estrada, por exemplo, o progresso pode ser claramente verificado. No software o

progresso no visvel, o gerente de projeto depende da documentao para

verificar o progresso do projeto.

o No se tem o entendimento claro do processo de software: na engenharia de

software os modelos de desenvolvimento de software so representaes

simplificadas do processo.

o Vrios projetos de software so projetos nicos, ou seja, no h semelhana com

projetos previamente desenvolvidos. Nestes casos, a experincia histrica um

valor limitante em predizer como o projeto dever ser gerenciado.

o Complexidade: Cada dlar, peso ou euro gasto em um produto de software

contem mais complexidade que outros artefatos da engenharia. (OConnor2000).

o Flexibilidade: a facilidade com a qual um software pode ser alterado geralmente

visto como uma de suas vantagens.


27/89



3.3.4.2 Dados HistricosUma 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

tcnicas at ento utilizadas tem sido substitudas por novas abordagens que combinam

experincias de sucesso em gerenciamento de projetos com os avanos da engenharia de

software.

Para Royce (1998) um gerenciamento moderno de software est baseado em diversos

princpios, 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) mtodos de projeto devem enfatizar o desenvolvimento baseado em

componentes; (iv) estabelecer um ambiente de gerenciamento flexvel e (v) utilizao de

ferramentas automatizadas que suportam diferentes formatos.

Ainda no que se refere a uma viso histrica 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-indstrias:

sistemas de software, sistemas de informao, software comercial, outsource software,

software militar e software para usurios finais; reafirmam a importncia do gerenciamento.

Com base neste levantamento Jones (apudRoyce, 1998) relata que seis dos dezessete fatores

tecnolgicos associados com desastres no projeto de software so falhas especficas no

domnio do gerenciamento de projetos, e trs das outras tecnologias deficientes podem ser

indiretamente determinadas por prticas 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

Ausncia de dados histricos de medio dos

softwares

Precisa medio do software

Insucesso ao usar ferramentas automatizadas

de estimativa

Ferramentas de estimativa usadas facilmente

Fracasso no uso de ferramentasautomatizadas de planejamento

Uso contnuo de ferramentas de planejamento

Falhas na monitorao do progresso do Relatrio formal do progresso do projeto


28/89



projeto ou milestones

Falha no uso de uma arquitetura efetiva Planejamento formal da arquitetura

No cumprimento de um mtodo dedesenvolvimento

Mtodo formal de desenvolvimento

Gerenciamento de risco informal Gerenciamento de risco formal

Insucesso no uso formal do controle deconfigurao

Controle de configurao automatizado

Fonte: Royce (1998)

Um relatrio apresentado pelo Standish Group (apudRoyce, 1998) focado na indstria

de software comercial concluiu que:

o Companhias americanas gastariam $81 bilhes 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 distribudos

no prazo e dentro do oramento. Para mdias e pequenas empresas, os nmeros

aumentaram para 16% e 28%, respectivamente.

Assim como relatado anteriormente por Jones (apudRoyce, 1998), este relatrio cita

que a principal razo para o sucesso ou fracasso est centrada nos requisitos do processo de

gerenciamento. Desta forma, fica evidenciada e ressaltada a importncia do gerenciamento de

software para o sucesso dos projetos.

3.3.4.3 Tcnicas de DesenvolvimentoUm processo de desenvolvimento de software pode ser visto como um guia para o

desenvolvimento e deve estabelecer: as atividades a serem realizadas durante odesenvolvimento de software, sua estrutura e organizao (decomposio e precedncia de

atividades), incluindo a definio de um modelo de ciclo de vida; os artefatos requeridos e

produzidos por cada uma das atividades do processo; os procedimentos (mtodos, tcnicas e

normas) a serem adotados na realizao das atividades; os recursos necessrios para a

realizao das atividades, dentre eles recursos humanos, recursos de hardware e recursos de


29/89



software, incluindo as ferramentas a serem utilizadas para apoiar a aplicao dos

procedimentos na realizao das atividades; e roteiros para a elaborao 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, anlise, projeto, implementao, testes,implantao, operao e manuteno.

Uma vez que o software sempre parte de um sistema (ou negcio) maior, o trabalho

comea pelo estabelecimento dos requisitos para todos os elementos do sistema e, na

seqncia, procede-se a alocao 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 ProgrammingO XP um processo de desenvolvimento de software definido basicamente por quatro

atividades: Planejamento, Teste, Implementao e Desenho (veja na Figura 1). Na fase de

Planejamento os requisitos so coletados e negociados com o cliente. Em seguida, os testes

so elaborados a partir das estrias do cliente, e a codificao realizada visando atender

estes testes. Por fim, o sistema novamente desenhado (ou reconstrudo) a medida que novas

funcionalidades so incorporadas. Estas fases ocorrem iterativamente at que o produto esteja

pronto.

Figura 1. Processos do Extreme Programming

O processo XP regido por doze princpios. A seguir resumimos estes princpios:

o O jogo do planejamento: Visa rapidamente determinar o escopo da prxima

verso, combinando prioridades de negcio e estimativas tcnicas.

o Pequenas verses: Visa produzir um sistema simples rapidamente, planejando

novas verses em um ciclo muito pequeno. Os ciclos duram trs semanas

Planejamento Teste DesenhoCodificao


30/89



o Refactoring: Os programadores reestruturam o sistema sem mudar seu

comportamento para remover duplicao, melhorar a comunicao, simplificar ou

adicionar flexibilidade.

o Programao em pares: Todo o cdigo produzido escrito com dois

programadores em cada mquina. Em cada ciclo trocam-se os pares deprogramadores.

o Propriedade coletiva: Qualquer pessoa pode mudar qualquer cdigo em qualquer

tempo.

o Integrao contnua: Visa integrar e construir o sistema muitas vezes ao dia, todas

as vezes que uma tarefa tiver sido finalizada.

o 40 horas por semana: Impe que o time no trabalhe mais do que 40 horas por

semana. Mas se necessrio que no se faa horas-extras por duas semanas

seguidas.o Cliente on-site: O cliente deve fazer parte do time e estar disponvel em tempo

integral para responder perguntas.

o Metfora: Todo o desenvolvimento guiado por uma simples estria

compartilhada de como o sistema como um todo funciona. A metfora ajuda o

time a ter um mesmo entendimento sobre o vocabulrio utilizado pelo domnio do

projeto e assim ajuda-o a nomear funes e variveis apropriadamente. Cenrios

uma tcnica de modelagem de requisitos. Utilizar esta representao de cenrios

como user-stories uma proposta definida por Breitman (2002).

o Padres de codificao: Os programadores devem escrever o cdigo de acordo

com os padres definidos pelo time, dando nfase comunicao atravs do

cdigo. Assim, o cdigo a nica documentao mantida no processo. Os cenrios

apiam o desenvolvedor durante a implementao, pois esclarecem as pr e ps-

condies de cada mdulo, e facilitam a enumerao das funcionalidades

encapsuladas em cada poro de cdigo.

o Desenho simples: O sistema deve ser projetado to simples quanto possvel. A

complexidade extra removida assim que detectada.

o Teste contnuo: Os programadores continuamente escrevem unidades de teste e os

executam para que o processo de desenvolvimento continue. Em cada ciclo os

programadores apresentam uma verso testvel do software ao cliente. Os clientes

escrevem testes para validar o sistema.


31/89



3.3.4.3.2 RUP Rational Unified ProgrammingO Processo Unificado proposto pela Rational (Rational Unified Process RUP) foi

criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma sistemtica

para se obter reais vantagens no uso da Linguagem de Modelagem Unificada (Unified

Modeling Language UML). De fato, ele no exatamente um processo: uma

infraestrutura genrica de processo que pode ser especializada para uma ampla classe de

sistemas de software, para diferentes reas de aplicao, tipos de organizao, nveis de

competncia e tamanhos de projetos.

O RUP est fundamentado em trs princpios bsicos: orientao a casos de uso,

arquitetura e iterao. Ele dito dirigido a casos de uso, pois so os casos de uso que

orientam todo o processo de desenvolvimento. Com base no modelo de casos de uso, so

criados uma srie de modelos de anlise, projeto e implementao, que realizam estes casos

de uso. centrado em arquitetura, pois defende a definio de um esqueleto para a aplicao

(a arquitetura), a ganhar corpo gradualmente ao longo do desenvolvimento. Finalmente, o

RUP iterativo e incremental, oferecendo uma abordagem para particionar o trabalho em

pores menores ou mini-projetos. Esses trs conceitos so igualmente importantes. A

arquitetura prov a estrutura para guiar o desenvolvimento do sistema em iteraes, enquanto

os casos de uso definem as metas e conduzem o trabalho de cada iterao.

O ciclo de vida adotado no RUP tipicamente evolutivo. Contudo, uma forma de

organizao em fases adotada para comportar os ciclos de desenvolvimento, permitindo uma

gerncia mais efetiva de projetos complexos. Ao contrrio do tradicionalmente definido como

fases na maioria dos modelos de ciclo de vida planejamento, levantamento de requisitos,

anlise, projeto, implementao e testes, so definidas fases ortogonais a estas, a saber:

o Concepo: 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 preciso necessria 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 oplanejamento e, por conseguinte, necessrio levantar requisitos do sistema e

preliminarmente analis-los. Ao trmino dessa fase, so examinados os objetivos

do projeto para se decidir sobre a continuidade do desenvolvimento;

o Elaborao: o propsito desta fase analisar com mais refino o domnio do

problema, estabelecer uma arquitetura de fundao slida, desenvolver um plano


32/89



de projeto para o sistema a ser construdo e eliminar os elementos de projeto que

oferecem maior risco. Embora o processo deva sempre acomodar alteraes, as

atividades da fase de elaborao asseguram que os requisitos, a arquitetura e os

planos esto suficientemente estveis e que os riscos esto suficientemente

mitigados, de modo a se poder prever com preciso os custos e prazos para aconcluso do desenvolvimento.

o Construo: durante esta fase, um produto completo desenvolvido de maneira

iterativa e incremental, para que esteja pronto para a transio comunidade

usuria.

o Transio: nesta fase, o software disponibilizado comunidade usuria. Aps o

produto ter sido colocado em uso, naturalmente surgem novas consideraes que

vo demandar a construo de novas verses para permitir ajustes do sistema,

corrigir problemas ou concluir algumas caractersticas que foram postergadas.

Figura 2: Fases do RUP

importante realar que dentro de cada fase, um conjunto de iteraes, envolvendo

planejamento, levantamento de requisitos, anlise, projeto e implementao e testes,

realizado. Contudo, de uma iterao para outra e de uma fase para a prxima, a nfase sobre


33/89



as vrias 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 concepo, o foco principal recai

sobre o entendimento dos requisitos e a determinao do escopo do projeto (planejamento e

levantamento de requisitos). Na fase de elaborao, o enfoque est na captura e modelagem

dos requisitos (levantamento de requisitos e anlise), ainda que algum trabalho de projeto eimplementao seja realizado para prototipar a arquitetura, evitando certos riscos tcnicos. Na

fase de construo, o enfoque concentra-se no projeto e na implementao, visando evoluir e

rechear o prottipo inicial, at obter o primeiro produto operacional. Finalmente, a fase de

transio concentra-se nos testes, visando garantir que o sistema possui o nvel adequado de

qualidade. Alm disso, usurios devem ser treinados, caractersticas ajustadas e elementos

esquecidos adicionados.

3.4 Extreme Project Management (XPM)Recentemente surgiu uma viso diferenciada do gerenciamento de projetos, em razo

do novo ambiente dos projetos que foi discutido anteriormente. Essa nova viso trouxe um

modelo alternativo para lidar com os referidos projetos empresariais, e auxiliar aos que esto

envolvidos em projetos demais, que mudam rpido demais e tem recursos e verba de menos.

Chama-seExtreme Project Management, ou XPM, numa aluso aos conceitos e ferramentas

radicais adotadas. Uma das referncias nesse assunto Rob Thomsett, que em seu livro

Radical Project Management (2002), destaca vrios dos conceitos abordados aqui, os quais

pratica h mais de 25 anos.

Como identificamos que as caractersticas encontradas no ambiente de mltiplos

projetos so muito similares aos descritos nessa abordagem ao tema de gerenciamento de

projetos, entendemos que vrios conceitos e tcnicas utilizadas pelo XPM podem ajudar

muito no gerenciamento de mltiplos projetos. Trataremos esse paralelo na seo de

Concluses deste trabalho, sendo que o objetivo agora descrever os principais conceitos e

modelo doExtreme Project Management.

Classificamos o XPM como um bem-vindo complemento aos conceitos apresentados

pelo PMI atravs do PMBOK, que tem foco mais no gerenciamento dos projetos tradicionais

e no aborda as questes e dificuldades do gerenciamento de mltiplos projetos. Na 3 edio

do PMBOK, de 2004, o tema comea a ser discutido, porm no mbito estratgico e ttico,

desenvolvendo mais os temas de Gesto de Portflio e de Programas, e a atuao do


34/89



Escritrio de Projetos (PMO). Porm, ainda peca no aprofundamento das questes

operacionais que afloram no ambiente dos mltiplos projetos.

3.4.1 Conceitos XPMOExtreme Project Management(XPM) baseado em alguns valores fundamentais, que so:

o Participao o gerenciamento de projetos fortemente baseado na participao dos

stakeholders do projeto.

o Pr atividade um processo criativo e pr ativo de solucionar problemas.

o Transparncia tudo no projeto compartilhado com todos os stakeholders.

o Foco externo o foco do Gerente de Projetos para fora do projeto, em direo aos

stakeholders.

o Confiana a equipe do projeto tratada como profissionais em que se pode confiar.

Alm dos valores acima, o XPM aplica os seguintes conceitos:

o Contexto mais importante do que contedo. O gerente de projetos no XPM deve

estar focado nos aspectos empresariais do projeto, em vez dos aspectos tcnicos do

produto ou servio que est sendo realizado pelo projeto. Deve se preocupar mais com

os stakeholders, com os objetivos e benefcios do projeto, impacto, riscos - enfim, o

contexto do projeto, ao invs do contedo, que o aspecto mais tcnico do projeto.

Quanto menos o gerente do projeto souber dos detalhes tcnicos do projeto, melhor.

o Ciclo de vida do projeto inclui perodo ps-implantao. O que acontece aps o

projeto to importante quanto durante. Tradicionalmente, o projeto termina na

entrega do produto ou servio e o aceite do cliente, ou ento logo aps, com uma

avaliao das lies aprendidas. Porm, no XPM, o perodo de suporte implantao e

a verificao dos benefcios faz parte do projeto, que s termina depois de um perodo

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 tcnico, tem uma tendncia a

tomar decises de planejamento de forma centralizada, intuitiva e unilateral, com

pouca interao com a equipe do projeto, que as vezes somente comunicada das

estimativas de prazo, custo, riscos, etc. posteriormente. Para aumentar as chances de


35/89



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

planejamento tcnico para a facilitao e integrao do processo de planejamento, com

a participao efetiva dos stakeholders, como nas sesses RAP.

o Patrocinadores funcionam como Gerentes Executivos de Projetos. O papel dosponsor, ou patrocinador, ainda mais crtico para o sucesso de projetos empresariais.

No gerenciamento de projetos tradicional, a participao do patrocinador mais

passiva e reativa. Normalmente, ele recebe relatrios tcnicos do projeto e raramente

so alertados de problemas nos projetos a no ser quando ele se torna crtico, restando

pouco espao 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 sesses de planejamento do projeto que definem escopo,objetivos, benefcios e stakeholders;

- assistir ao Gerente de Projeto nas disputas polticas e de poder na organizao

que influenciam o projeto;

- monitorar indicadores crticos do projeto, alm das de custo e prazo.

o Planejamento por cenrios em vez de macro-planejamento. Se no puder prever o

futuro com preciso, no o detalhe no cronograma, pois apenas cria falsas

expectativas. Em muitos projetos empresariais, o nvel de incerteza to grande, assim

como o ritmo de mudanas, 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

mudanas, com envolvimento mnimo 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 mximo as

mudanas. O problema que para o tipo de projeto que estamos discutindo, as

mudanas acontecem com ou sem a nossa permisso. A soluo, nesse caso, o

planejamento por cenrios, onde eventos selecionados (o resultado de um subproduto,

um acordo, uma prova de conceito, a construo de um prottipo, etc.) definem o

caminho a seguir, ou qual cenrio desenvolver. Essa tcnica especialmente

importante para projetos de Pesquisa & Desenvolvimento, onde no se sabe se o

resultado da pesquisa ser o esperado. Deve-se ento detalhar as atividades somente


36/89



at o primeiro evento, enquanto os cenrios alternativos tm somente etapas genricas

delineadas. Esse tipo de planejamento tambm chamado de real-time planning, ou

planejamento em tempo real. Esse modelo tem sido utilizado com sucesso em aes

militares, substituindo o processo linear utilizado at a guerra do Vietn. O nvel de

incerteza e a dinmica do projeto vai determinar o detalhamento do plano, o nmerode cenrios possveis e o ritmo do acompanhamento do projeto. Normalmente, difcil

detalhar mais do que 6 meses em projetos empresariais. Se os cenrios esto

razoavelmente definidos, e houver possibilidade de estimativas para eles, deve-se usar

para referncia para o projeto a estimativa do pior caso (o mais longo ou mais caro,

dependendo do foco do projeto). A dica decidir qual cenrio seguir o mais rpido

possvel, para realinhar as bases de planejamento.

o Planejamento rpido e participativo. Em projetos empresariais muito importanteencurtar ao mximo o ciclo de vida do projeto, pela prpria 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. Porm, completude no

sinnimo de demora e o conceito de planejar com a participao ativa da equipe levou

ao desenvolvimento de tcnicas de planejamento rpido, que sero discutidas em

seguida. O conceito tambm aplicado em sesses de planejamento estratgico

empresarial. O importante, no final, que o planejamento no deve ser feito por uma

s pessoa, deve envolver os stakeholders principais e no deve conter o que no 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

experincias, conhecimento, e desenvolvendo relacionamentos de confiana, amizade

e lealdade, esto contados, se j no acabaram. A realidade no novo ambiente de

negcios a equipe formada por elementos diferentes de vrias reas da empresa,

muitas vezes de fora, dedicados parcialmente ao projeto, com pouca ou nenhuma

lealdade equipe, confiana entre os membros limitada ao respeito tcnico, pouca

troca de conhecimento, experincias, ou amizade, causada muitas vezes pela distncia

fsica e meios de comunicao virtuais. Essa a equipe virtual, que deve ser

gerenciada de forma diferente da equipe tradicional.


37/89



3.4.2 Tcnicas e Ferramentas XPMDentre as vrias tcnicas e ferramentas criadas e adotadas no XPM, algumas se sobressaem e

so mais pertinentes ao nosso tema de mltiplos projetos:

o

Sesses RAP. A necessidade de se planejar com a participao ativa da equipe deforma rpida resultou nas sesses RAP, como so chamadas. Os stakeholders

participam de reunies intensivas, sob a liderana 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 reunies de planejamento intensivo, comum

levar at meses desenvolvendo o plano com participaes pontuais e ao custo de

muitas revises e alteraes. Na necessidade de um replanejamento, por motivos de

mudana no ambiente, uma nova sesso deve ser convocada para fazer os ajustes no

plano. A durao do projeto drasticamente diminuda, aumentando o alinhamentodas expectativas de todos e fortalecendo a comunicao. Esse mtodo muito

utilizado no desenvolvimento de sistemas de informao, 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 Rguas de Sucesso. Um grande problema do gerente de projeto que deve ser

minimizado logo no incio e acompanhado durante todo o projeto o alinhamento dasexpectativas do cliente, patrocinador e outros stakeholders importantes do projeto.

Definir os critrios de sucesso de um projeto parte integrante dessas expectativas,

que tambm 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

critrios de sucesso que representam as expectativas gerais em relao ao projeto:

- A importncia de satisfazer os stakeholders principais: identificar os

stakeholders que devem ser satisfeitos (geralmente o cliente e o patrocinador) e avaliar

a importncia da satisfao pessoal deles para o sucesso do projeto; nem todos tm

que ficar satisfeitos para um projeto ser considerado de sucesso.

- Atendimento aos requisitos e escopo do projeto: o grau de importncia de se

atender todos os requisitos para que o projeto seja considerado um sucesso; muitas

vezes, o projeto no atende o escopo completamente, mas considerado um sucesso.


38/89



- Respeito ao Oramento: o quo importante ficar dentro do oramento; critrio

fcil de medir; nem todos os projetos tm um oramento fixo.

- Respeito ao Prazo: o quo importante ficar dentro do prazo; critrio fcil de

medir; nem todos os projetos do a mesma importncia questo de prazo.

- Valor Agregado (custo / benefcio): o grau de importncia dado ao valor que oresultado do projeto agrega organizao cliente, com nfase na verificao dos

benefcios trazidos pelo projeto. Os benefcios sero medidos e acompanhados aps

entrega do produto ou servio? vital para considerar o projeto um sucesso verificar

os benefcios?

- Atendimento aos requisitos de Qualidade: o grau de importncia que a qualidade

exerce no projeto; mensurvel atravs de indicadores e mtricas definidas.

- Satisfao da Equipe: o quanto a satisfao pessoal e profissional da equipe

importante para o projeto. Sacrificar a equipe em favor de outros critrios vlido?Traduzindo estes sete critrios para um conjunto de rguas onde se pode

posicionar um indicador do nvel de importncia que se quer dar a cada critrio, pode-

se ter uma viso holstica das expectativas de cada um para comparar. Veja a figura

abaixo. So quatro posies na escala da rgua: Desligado, 25%, 50%, 75% e Ligado.

Desligado significa que o critrio no importante neste projeto. Ligado significa que

crucial. Fases intermedirias traduzem o sentimento relativo entre eles. Obviamente,

deixar todos ligados no realista, pois se for necessrio decidir entre um critrio e

outro, normalmente um se destaca mais. Esse o indicador para o gerente do projeto

de onde ele no pode falhar se tiver que privilegiar algum critrio. Sero tambm as

reas mais bem acompanhadas nos relatrios e onde haver mais controle.

Figura 3 Exemplo de aplicao das Rguas de Sucesso


39/89

Gerenciamento de Mltiplos Projetos TCC

Documents

TCC_Gerenciamento de Multiplos Projetos