Escolar Documentos
Profissional Documentos
Cultura Documentos
Rio de Janeiro
Outubro / 2004
RESUMO
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.
SUMÁRIO
RESUMO...............................................................................................................................2
ABSTRACT.......................................................................................................................3
LISTA DE TABELAS E FIGURAS ............................................................................................6
LISTA DE ABREVIATURA E SIGLAS......................................................................................7
1 INTRODUÇÃO ...............................................................................................................8
1.1 Cenário Atual..........................................................................................................8
1.2 Definição do Problema............................................................................................9
1.3 Relevância do Trabalho...........................................................................................9
1.4 Delimitação do Trabalho.......................................................................................10
2 METODOLOGIA...........................................................................................................11
2.1 Estruturação do Trabalho ......................................................................................11
2.2 Os Fins e os Meios ...............................................................................................12
2.3 Limitações ............................................................................................................13
3 REFERENCIAL TEÓRICO.............................................................................................14
3.1 A Teoria de Administração de Empresas...............................................................14
3.2 Evolução Histórica da Gerência de Projetos ..........................................................16
3.2.1 Raízes na História Antiga ..............................................................................16
3.2.2 A Era “Moderna” ..........................................................................................16
3.2.3 O Novo Ambiente .........................................................................................19
3.3 Tipos de Projetos ..................................................................................................20
3.3.1 Projetos Pequenos vs. Projetos Grandes.........................................................20
3.3.2 Projetos de Desenvolvimento vs. Projetos de Implantação .............................22
3.3.3 Projetos Empresariais vs. Projetos de Engenharia e Construção.....................23
3.3.4 Projetos de TI................................................................................................25
3.4 Extreme Project Management (XPM)....................................................................33
3.4.1 Conceitos XPM .............................................................................................34
3.4.2 Técnicas e Ferramentas XPM ........................................................................37
3.4.3 O Modelo de Gerenciamento XPM................................................................39
3.5 Ambientes de Múltiplos Projetos...........................................................................43
3.5.4 Gestão de Portfólio........................................................................................45
3.5.5 Gerência de Programas..................................................................................47
3.5.6 Gerenciamento de Múltiplos Projetos ............................................................49
3.5.7 Gerenciamento do Tempo..............................................................................54
3.6 O Método da Cadeia Crítica ..................................................................................57
3.6.1 A Teoria das Restrições.................................................................................57
3.6.2 CCM vs. CPM...............................................................................................58
3.6.3 CCM no Ambiente de Múltiplos Projetos ......................................................59
4 ANÁLISE DE RESULTADOS.........................................................................................60
4.1 Pesquisa de Campo I .............................................................................................60
4.1.1 Avaliação Geral da Pesquisa I .......................................................................60
4.1.2 Tabulação e Análise dos Dados – Pesquisa I..................................................61
4.2 Pesquisa de Campo II............................................................................................67
1 INTRODUÇÃO
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.
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.
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.
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.
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.
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
3 REFERENCIAL TEÓRICO
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.
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.
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?
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.
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.
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.
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.
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.
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
3.3.4 Projetos de TI
projeto ou milestones
Falha no uso de uma arquitetura efetiva Planejamento formal da arquitetura
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.
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
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.
O Extreme Project Management (XPM) é baseado em alguns valores fundamentais, que são:
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 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.
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).
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.
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.
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.
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.
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.
Projetos devem competir por recursos dentro da organização, já que normalmente não
recursos disponíveis para todos os projetos que aparecem. É preciso procurar maximizar o
resultado geral ao invés de focar no sucesso individual de um projeto ou programa.
Empresas de pequeno e médio porte geralmente possuem apenas um único portfólio
de projetos. Porém, grandes organizações podem precisar se organizar através de múltiplos
portfólios, normalmente derivados de unidades organizacionais (diretorias, unidades de
negócios, etc.), mas os projetos e programas podem ser agrupados em portfólios por outros
critérios, como linhas de produtos. Nesses casos, os processos incluem iniciação e
encerramento dos portfólios.
Em falando de processos e fases, o OPM3 (2003) descreve os grupos de processos
envolvidos na gestão do portfólio de forma bastante similar aos de gerenciamento de projetos,
ordenando-os em 5 grupos: iniciação, planejamento, execução, controle e encerramento,
estendendo o mesmo framework que o PMBOK (2000) utiliza com projetos. Embora a
iniciativa seja válida, existe a percepção de que o paralelo com os processos de gerenciamento
de projetos foi um pouco excessivo, questão esta que está sendo endereçada no
desenvolvimento dos padrões específicos de programas e portfólio (PPMS). Outras linhas de
pensamento colocam as fases da gestão de portfólio de outra forma. O whitepaper da Pacific
Edge (2004) apresenta 4 grupos de processos que são compartilhadas de forma semelhante
por outros autores:
1) Inventário – Nesta fase é feito um inventário completo de todos os investimentos
do portfólio, entre projetos e outras iniciativas, de forma que se possa ter uma
visão completa da carteira atual e dos projetos candidatos a entrarem no portfólio.
As informações que devem ser compiladas aquis são no nível gerencial, de forma
resumida. Além do inventário de projetos é também feito um inventário de
recursos, humanos e materiais, com informações pertinentes como custo e
competências.
2) Análise – Com base no inventário, começa o processamento das informações do
ponto de vista de gestão empresarial, quando devem ser analisados os projetos sob
a luz dos critérios de seleção que a empresa adotar. As perspectivas podem ser:
Potencial de Realização, que julga a capacidade do projeto ser executado com
sucesso; Alinhamento Estratégico, que avalia como as iniciativas estão
contribuindo para a realização das metas e objetivos estratégicos; Equilíbrio, que
avalia o balanceamento e diversificação dos projetos dentro de um critério, que
pode baseado no Balance Score Card; e Valor, que mede os benefícios esperados
pela realização do projeto. Podem entrar outros elementos, como Urgência, que
geralmente faz par com Importância, como demonstrado por Dobson (1999), para
se chegar ao um índice numérico de mérito do projeto.
3) Otimização – O objetivo desta fase é maximizar os benefícios do portfólio. É um
processo iterativo que revisa continuamente os critérios descritos acima para
manter o portfólio equilibrado, aderente ao plano estratégico, realizável e
agregando o máximo de valor. É nesta fase que as decisões de seleção de projetos
são tomadas e alterações nos projetos do portfólio são recomendadas.
4) Mobilização – fase em que as decisões tomadas na fase anterior são levadas a
cabo e comunicadas ao nível de projetos, iniciando, alterando e cancelando
projetos. Recursos são alocados e re-alocados, e medições sobre a situação são
feitas.
Uma recomendação importante feita por Cooper e Edgett (2001) é quanto ao número
certo de projetos no portfólio. É comum ter um número excessivo de projetos, o que prejudica
a distribuição de recursos e põe me risco a realização dos mesmos. Nesse ponto é fundamental
poder fazer o planejamento de capacidade de sua organização em função dos recursos
disponíveis.
Embora a gestão de portfólio ofereça inúmeros benefícios, deve-se ter em mente que
existem alguns pontos potencialmente negativos para tomar ciência, como a tendência de
depender de uma ferramenta de análise e processamento para tomar decisões e o aumento do
nível de burocratização da organização.
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.
Planejamento da Capacidade
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.
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
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.
4 ANÁLISE DE RESULTADOS
Neste capítulo serão analisados os resultados da pesquisa de campo realizada por meio
do questionário apresentado no Anexo I.
o Serviços
o Farmacêutica
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.
35,00%
25,00%
20,00%
15,50%
15,00%
10,08% 10,85%
10,00%
4,65%
5,00%
2,33%
0,00%
Industria TI Telecom Petroleo e Serviços Finanças Outros
Gas
50,00% 47,29%
45,00%
40,00%
35,00%
30,00%
25,00%
20,00%
16,28%
15,00% 13,18%
11,63% 11,63%
10,00%
5,00%
0,00%
TI Organizacional Des env Pres tação de Outros
Produtos Serviços
80,00%
69,77%
70,00%
60,00%
50,00%
40,00%
30,23%
30,00%
20,00%
10,00%
0,00%
Gerente Equipe
50,00%
40,00%
30,00%
20,16%
20,00%
12,40%
10,00%
4,65%
0,00%
1 2-5 5 - 10 > 10
70,00%
61,24%
60,00%
50,00%
40,00% 37,98%
30,00%
20,00%
10,00%
0,78%
0,00%
Aumento Diminuído Estável
60,00% 56,59%
50,00%
40,00%
30,00% 25,58%
20,00% 17,83%
10,00%
0,00%
<5 5 - 20 > 20
60,00%
54,26%
50,00%
40,00%
32,56%
30,00%
20,00%
13,18%
10,00%
0,00%
<3 3-6 >6
80,00%
69,77%
70,00%
60,00%
50,00%
40,00%
29,46%
30,00%
20,00%
10,00%
0,78%
0,00%
A lta Média Baixa
100,00%
90,00% 86,82%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,08%
10,00% 3,10%
0,00%
Mais Igual Menos
35,00% 33,33%
31,01%
30,00%
25,00%
20,00% 17,05%
15,00% 12,40%
10,00%
6,20%
5,00%
0,00%
Terminar no Ficar dentro do Cumprir a Satisf azer o Traz o
Prazo previsto Orçamento Qualidade Cliente Benef ício a que
esperada se propõe
Projeto
Interdependência técnica Nível Médio + Alto = 75% Altos índices de
e de recursos entre interdependências entre
projetos projetos
Recursos alocados "full- 10 a 25% = 40% dos projetos Baixa taxa de dedicação
time" dos recursos em tempo
integral aos projetos
5 CONCLUSÕES
descreve com clareza como uma organização funciona, do ponto de vista de transformar
estratégias em resultados.
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
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.
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.
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.
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.
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.
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
2. AJANI, Shaun. Extreme Project Management, New York, Writers Club Press, 2002.
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
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.
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.
24. KERZNER, Harold. Project Management for Executives. New York: Van Norstrand
Reinhold Company, 1982.
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.
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.
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
39. PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995. ISBN 85-
346-0237-9.
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
52. VISITACION, Margo. Common Sense Help for E-Business Projects: Critical Chain
Project Management. Planning Assumption, Cambridge, MA, Giga Information Group,
2000.
7 ANEXOS