Tcc_gerenciamento De Multiplos Projetos

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

ROBERTO HENRIQUE NOGUEIRA PONS ANDRÉ LUIZ CATALDO FALBO SANTO

GERENCIAMENTO DE MÚLTIPLOS PROJETOS

Monografia apresentada ao curso MBA em Gerência de Projetos, Pós-Graduação latosensu, da Fundação Getulio Vargas como requisito parcial para a obtenção do Grau de Especialista em Gerência de Projetos.

MONITOR: Prof. Edmarson B. Mota

Rio de Janeiro Outubro / 2004

Todos os direitos reservados

1

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

2

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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.

Todos os direitos reservados

3

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

4

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

4.2.1 Sumário dos Dados Descritivos .....................................................................68 4.3 Avaliação dos Resultados e Conclusões ................................................................70 5

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

6

BIBLIOGRAFIA ............................................................................................................84

7

ANEXOS ......................................................................................................................89 7.1 Anexo I – Pesquisa de Campo...............................................................................89

Todos os direitos reservados

5

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

LISTA DE TABELAS E FIGURAS

Tabela 1

Projetos de Engenharia vs. Empresariais

Tabela 2

Tecnologia em projetos

Tabela 3

Sumário dos dados descritivos

Tabela 4

Sumario dos dados descritivos, Chaves (2004)

Figura 01

Processos do Extreme Programming

Figura 02

Fases do RUP

Figura 03

Exemplo de aplicação das “Réguas de Sucesso”

Figura 04

Estratégia Monolítica

Figura 05

Estratégia por Versões

Figura 06

Estratégia Evolutiva

Figura 07

Portfólio, Programas e Projetos

Figura 08

Segmento da Empresa

Figura 09

Tipo de Projeto

Figura 10

Atuação no Projeto

Figura 11

Quantidade de Projetos Simultâneos

Figura 12

Volume de Projetos

Figura 13

Recursos Alocados

Figura 14

Duração Média dos Projetos

Figura 15

Complexidade dos Projetos

Figura 16

Nível de Stress

Figura 17

Critério de Sucesso

Figura 18

Múltiplos Projetos no Contexto da Organização

Todos os direitos reservados

6

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

LISTA DE ABREVIATURA E SIGLAS

AM

Agile Modeling (Modelagem Ágil)

ARPANET

Advanced Research Project Agency Network

BCS

Balance Score Card

CASE

Computer Aided Software Engineering

CCM

Critical Chain Method

CPM

Critical Path Method

DOD

Department of Defense

JAD

Joint Applications Design

JRP

Joint Requirements Planning

OTAN

Organização do Tratado do Atlântico Norte

P&D

Pesquisa e Desenvolvimento

PERT

Program Evaluation and Review Technique

PMI

Project Management Institute

PMBOK

Project Management Body of Knowledge

PMIS

Project Management Information System

PMP

Project Management Professional

PPMS

Program and Portfolio Management Standard

RAD

Rapid Application Development

RAP

Rapid Planning

RUP

Rational Unified Programming

TI

Tecnologia da Informação

TOC

Theory of Constraints

UML

Unified Modeling Language

WBS

Work Breakdown Structure

XP

Extreme Programming

XPM

Extreme Project Management

Todos os direitos reservados

7

Gerenciamento de Múltiplos Projetos

1

TCC GP09 RJ / FGV

INTRODUÇÃO

A escolha do tema de Gerenciamento de Múltiplos Projetos foi influenciada por vários fatores. Além de ser um assunto contemporâneo,

aliás, muito recente nas discussões e

literatura, é um tema fortemente vivenciado pelos autores em suas atividades profissionais. Um dos autores tem uma empresa que desenvolve uma ferramenta informatizada voltada para esse tema, além de estar envolvido em várias outras atividades, como consultoria e treinamento. O outro autor é especialista em desenvolvimento de projetos de software, liderando vários projetos simultâneos em um grande provedor internet.

Os desafios

encontrados nos aspectos estratégicos, táticos e operacionais do tema são objetos deste estudo, sendo que a ênfase será na estratégia para lidar com os conflitos e as dificuldades de se gerenciar múltiplos projetos com recursos limitados e compartilhados, sob o ponto de vista operacional.

1.1

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

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

Todos os direitos reservados

8

Gerenciamento de Múltiplos Projetos

1.2

TCC GP09 RJ / FGV

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

quer dizer com esse termo, pois afinal existem várias perspectivas sobre o tema. Existe a visão estratégica, que se refere à Gestão de Portfólio, ou carteira de projetos da organização; a visão tática que trata da Gerência dos Programas, e finalmente a visão operacional, onde gerentes e integrantes de equipes estão alocados em vários projetos simultaneamente, que será referido neste trabalho como Gerenciamento de Múltiplos Projetos. Todas as três visões serão abordadas no estudo. Porém, as duas primeiras, de Portfólio e Programas, já contam com uma discussão um pouco mais amadurecida na literatura, sendo alvo de vários estudos e com questões mais estabelecidas. A visão operacional, no entanto, que aflige tanto os gerentes de projetos quanto a equipe, carece de um aprofundamento ao mesmo tempo em que apresenta grandes desafios, os quais este trabalho pretende abordar, procurando sugerir algumas estratégias para facilitar o exercício das funções nesse ambiente. Pretendemos ajudar a responder algumas perguntas cruciais sobre o gerenciamento de múltiplos projetos, como: - Quais são os fatores críticos de sucesso no gerenciamento de múltiplos projetos? - Como minimizar os conflitos pela disputa de recursos entre projetos concorrentes? - Quais técnicas e ferramentas devo utilizar para facilitar o processo? - Como prevenir a alocação além da nossa capacidade de realização? Decorrente de nossas experiências profissionais, verificamos que a área de TI tem grande afinidade com essas questões, sendo um de nossos objetivos nesse estudo fazer um paralelo das questões abordadas para o gerenciamento de múltiplos projetos em geral com o ambiente específico de TI.

1.3

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

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

Todos os direitos reservados

9

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

projetos que são executados até mesmo em caráter informal e que consomem boa parte dos recursos e tempo das pessoas envolvidas, muitas vezes sem registro e sem o devido planejamento. Sendo o trabalho baseado em questões presentes em praticamente todas as organizações, o tema e os objetivos do trabalho vão ao encontro dos anseios dos envolvidos em projetos simultâneos, seja como gerente, equipe, patrocinador ou qualquer outro stakeholder. Com relação ao aprofundamento na área de TI, esta é uma área de atuação que tem tido o maior crescimento na participação do mercado de gerenciamento de projetos, e como tem forte afinidade com as melhores práticas, a qualifica para receber uma atenção especial sobre o tema. Como a literatura ainda apresenta poucas referências no estudo dessas questões, ainda há muito ser percorrido sobre o tema. Procurando complementar a referência bibliográfica, decidimos aplicar uma pesquisa de campo sobre o tema de gerenciamento de múltiplos projetos a profissionais ligados ao assunto. Desta forma, pudemos comprovar algumas questões teóricas e conhecer um pouco mais da realidade local. Acreditamos que este trabalho contribui tanto para o melhor entendimento sobre o assunto como oferece alternativas de ações para melhorar o desempenho e a maturidade das organizações em seus projetos. 1.4

Delimitação do Trabalho Da mesma forma que o assunto é emergente na literatura e tem um grande espaço para

desenvolvimento, não temos a pretensão de esgotar a discussão nem proporcionar todos os elementos de facilitação dos processos envolvidos. O tema em toda sua plenitude é complexo, envolve todas as camadas organizacionais: estratégica, tática e operacional, e abrange uma larga variedade de áreas, indústrias e stakeholders. O foco do trabalho está no âmbito operacional, portanto, as outras visões – estratégica e tática - são abordadas de forma descritiva, no referencial teórico do trabalho, para maior esclarecimento do fluxo lógico e encadeamento da discussão, dando base para os argumentos e colocando a questão principal na perspectiva correta. Não está previsto no escopo deste trabalho, a análise da relação das características do ambiente multiprojeto com a estrutura organizacional da empresa, que já foi abordado com competência por Chaves (2004). Tampouco tem esse trabalho o objetivo de desenvolver metodologias específicas para aplicação direta nas organizações, que por sua vez, devem utilizar esse estudo como mais um insumo na criação das mesmas.

Todos os direitos reservados

10

Gerenciamento de Múltiplos Projetos

2

TCC GP09 RJ / FGV

METODOLOGIA Este capítulo tem por objetivo descrever a metodologia utilizada neste trabalho. De

acordo com a taxionomia sugerida pela coordenação da FGV, utilizamos a seguinte abordagem.

2.1

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

Todos os direitos reservados

11

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

5. Conclusões: Este capítulo descreve o que os autores desejam contribuir de seus estudos e pesquisas, fazendo o relacionamento entre técnicas, ferramentas e características de projetos com o tema de gerenciamento de múltiplos projetos. 6. Referências Bibliográficas: Relação de autores, livros, artigos e demais trabalhos científicos utilizados no Referencial Teórico e em outras partes do trabalho. 7. Anexos: Como documento complementar está incluído no Anexo, o Modelo do Formulário de Pesquisa utilizado.

2.2

Os Fins e os Meios Utilizamos uma metodologia mista tanto nos fins, quanto nos meios para desenvolver

o trabalho. Quanto aos fins, temos basicamente três tipos: o Exploratória: como o tema de gerenciamento de múltiplos projetos tem pouco conhecimento acumulado e estruturado, procuramos explorar o assunto em várias dimensões. o Explicativa: como os resultados obtidos no gerenciamento de múltiplos projetos são em geral insatisfatórios, ocorrendo fenômenos de forma sistematizada, procuramos esclarecer os motivos dessas ocorrências e os fatores que contribuem para o grau de insucesso existente. o Aplicada: motivados a proporcionar uma visão mais clara da realidade dos múltiplos projetos, procuramos também resolver o lado prático, oferecendo várias ações e soluções para os problemas encontrados no dia a dia. Quanto aos meios, preferimos utilizar dois principais, que são: o Pesquisa de Campo: fizemos uso da oportunidade de realizar uma investigação empírica com elementos representativos do tema para podermos aferir, localizar e sedimentar o conhecimento específico que trata o tema, já que o assunto não tem uma unanimidade acadêmica. Utilizamos também outra pesquisa realizada anteriormente como referência adicional. o Pesquisa Bibliográfica: Parte fundamental do trabalho, a pesquisa bibliográfica na literatura é necessária como ponto de partida e referencial conceitual para comprovar e inspirar as soluções apresentadas ao final.

Todos os direitos reservados

12

Gerenciamento de Múltiplos Projetos

2.3

TCC GP09 RJ / FGV

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

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

Todos os direitos reservados

13

Gerenciamento de Múltiplos Projetos

3

TCC GP09 RJ / FGV

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

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

A Teoria de Administração de Empresas Os autores acreditam que existem muitas semelhanças entre os conceitos de

administração de empresas e o gerenciamento de projetos, especialmente o gerenciamento de múltiplos projetos. Dessa forma, apresentamos uma descrição resumida da teoria de administração empresarial e os papéis dos vários níveis de administradores, para posteriormente fazer uma analogia com múltiplos projetos e os respectivos gerentes de projetos. Havendo o paralelo, podemos rever as técnicas e características usadas na administração que poderiam ser aplicados também no gerenciamento de múltiplos projetos, especialmente quando estamos lidando com a administração de vários empreendimentos ou organizações simultaneamente. Lundgren (1974) em sua obra Organizational Management – Systems and Process, descreve a universalidade

da filosofia, teoria conceitos da

administração organizacional, mapeando os papéis e responsabilidades nos diversos níveis da gestão e gerência corporativa. Ele apresenta várias definições do termo administração, até chegar à formal, que é: “Administração é a força que, através do poder de decisão baseado no conhecimento e entendimento, integra, via processos apropriados, todos os elementos de um sistema organizacional de uma forma planejada para atingir os objetivos da organização.” Podemos já detectar palavras-chaves que encontram grande sinergia com o gerenciamento de projetos – decisão, conhecimento, integração, processos, elementos, planejamento, objetivos. A filosofia de administração é um guia genérico que determina como uma organização vai ser gerenciada e afeta cada faceta de sua operação, ajudando a construir a cultura organizacional. A organização é considerada um sistema aberto, onde o ambiente externo exerce influencia sobre o funcionamento e a sobrevivência do sistema, que por sua vez, reage para manter o equilíbrio do sistema. De acordo com a análise clássica de sistema, um sistema fechado está isolado de qualquer manifestação externa e tende à entropia e à disfunção, pois

Todos os direitos reservados

14

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

não tem a habilidade de utilizar novos recursos e energia de fora sua unidade para manter o equilíbrio interno. Um projeto também está sempre procurando o equilíbrio de seguir o plano original, reagindo às interferências do ambiente para chegar ao seu objetivo. Assim como em projetos, a administração empresarial precisa a todo custo controlar os elementos que levam à manutenção do equilíbrio dinâmico interno, e para isso precisa utilizar recursos e informações que possibilitem ajustes necessários aos seus sistemas em resposta ás mudanças do ambiente externo. Esse é o grande desafio da administração. Para ter sucesso nessa função, ela precisa de informação confiável e no tempo adequado, utilizando para isso sistemas de retorno, ou feedback. Outra questão importante de abordar no tema de administração são os níveis de responsabilidade dentro de uma organização, que variam de acordo com o nível hierárquico dentro da sua estrutura organizacional. Nem todos na administração têm a mesma responsabilidade. Existem três níveis gerenciais distintos dentro de organizações mais complexas: a alta administração, a gerência intermediária e a gerência operacional. Na primeira estão o presidente, vice-presidentes, diretores, superintendentes, e outros ligados ao plano estratégico da organização. No nível gerencial intermediário estão normalmente os gerentes funcionais, que estão mais ligados no plano tático, e no operacional se encontram os coordenadores, chefes de seção, etc. Apesar de que a titulação de cargos não distinguir claramente a que grupo o administrador pertence, as responsabilidades e os seus afazeres o fazem. No nível mais alto, os administradores se confrontam com grandes doses de incertezas e lidam diretamente com as influencias do ambiente. Estabelecem a direção e a estratégia da empresa, determinando o seu rumo geral. A gerência intermediária coordena a produção, serve de interface entre a operação e a alta administração. Estabelece as metas de acordo com os objetivos mais genéricos estabelecidos pelo Plano Estratégico feito pela alta administração. A gerencia operacional realiza o trabalho com seus recursos. Todos os três níveis são interdependentes e se relacionam constantemente. Vale comentar que no caso de grupos empresariais, teremos mais níveis acima do presidente da empresa, pois pode haver um conselho administrativo do grupo, ou holding, que revisa e agrupa os interesses comuns do grupo, em prol de uma macro-estratégia que rege todo o grupo. A mensagem principal é que quanto maior e mais complexa for a organização, mais níveis de administração são necessários, compartilhando a responsabilidade e distribuindo a administração em componentes cada vez menores.

Todos os direitos reservados

15

Gerenciamento de Múltiplos Projetos

3.2

TCC GP09 RJ / FGV

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

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

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

16

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

Groves, e o gerenciamento técnico, liderado pelo Dr. Robert Oppenheimer. Esta distinção foi um marco para o gerenciamento de projetos, pois até então era sempre o arquiteto ou especialista técnico que era responsável pelo gerenciamento de todos os elementos do projeto, o que muitas vezes provocava um conflito de interesses e causava grandes atrasos e gastos exagerados. Em projetos complexos, como aconteceu com a Casa de Ópera de Sidney, o arquiteto pode ficar tão envolvido com os desafios tecnológicos a serem vencidos que chegam a ignorar o controle de prazo e custo, considerado por eles menos importante. No entanto, o conceito do “moderno” gerenciamento de projetos, como o conhecemos, teve suas origens mais recentemente, no final dos anos 50, em decorrência da pressão do governo americano por uma corrida de desenvolvimento tecnológico durante a Guerra Fria. Essa pressão foi detonada pela crise do Sputnik em 1957, quando a União Soviética lançou com sucesso o satélite Sputnik 1, enquanto os EUA haviam falhado em dois lançamentos anteriores. Esse fato gerou uma reação forte dos americanos, que resultou em várias iniciativas do Departamento de Defesa (DOD), tais como: o A corrida espacial, com a criação da NASA em 1958; o Aumento drástico do fomento à pesquisa científica, aumentando em 1959 o orçamento da Fundação Nacional de Ciências americana de 34 para 134 milhões de dólares; o Criação do Programa de Mísseis Polaris, com a construção de um submarino nuclear para diminuir a diferença em relação ao arsenal russo. O Almirante Raborn da marinha americana tinha urgência para realizar o programa e as ferramentas de gerenciamento de projetos tradicionais não eram suficientes para garantir a entrega do projeto. O DOD então desenvolveu com a ajuda de Willard Frazar o PERT (Program Evaluation and Review Technique), um sistema de sequenciamento de atividades que consegue determinar o menor tempo para a conclusão de um projeto. A utilização do PERT se tornou obrigatório para todos os projetos da marinha Americana. o A Agência de Pesquisa Avançada de Projetos de Defesa do Pentágono iniciou nos anos 60 o projeto de uma rede de computadores chamada ARPANET, que foi a percussora da Internet de hoje. Nesta mesma época outros avanços foram desenvolvidos no gerenciamento de projetos. A DuPont criou o CPM (Critical Path Method), ou Método do Caminho Crítico, que é amplamente usado atualmente, para identificar quais são as atividades críticas de um projeto que podem atrasá-lo. O PERT foi depois estendido para o WBS (Work Breakdown Structure), também conhecido com Estrutura Analítica do Projeto. O método tradicional do Caminho

Todos os direitos reservados

17

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

18

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

predominavam na época, de grande porte, longa duração e altos custos, utilizando uma estrutura tradicionalmente linear, ou monolítica de gerenciamento. Nos anos 80, iniciou-se um movimento de mudança de percepção e novos pensamentos surgiram. Foi a época do surgimento de Porter (1986) com sua teoria de estratégia competitiva e de Tom Peters (1982) com a mudança de foco para as pessoas no sucesso da empresa, e outros. Foram os precursores de um novo ambiente.

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

Todos os direitos reservados

19

Gerenciamento de Múltiplos Projetos

3.3

TCC GP09 RJ / FGV

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

discussão do gerenciamento de múltiplos projetos, vamos analisar a própria natureza dos projetos, os vários tipos e características que possam nos ser útil no momento de discutir a melhor forma de gerenciá-los, ainda mais de forma simultânea. 3.3.1 Projetos Pequenos vs. Projetos Grandes Tamanho é documento? Em se tratando de projetos, podemos dizer que sim. Porém, Thomsett (2002) diz que não existe o tal “pequeno projeto”, numa alusão de que um pequeno projeto mal gerenciado pode se tornar um grande problema e então acaba virando um grande projeto. Realmente, ninguém nega que muitas vezes detalhes ignorados ou simples tarefas mal executadas podem ter um efeito dominó que trará grandes prejuízos mais tarde. Vamos ver como a literatura trata então a gerência de pequenos projetos. Cleland e Ireland (2000) propõem um simples protocolo de regras básicas de como pequenos projetos podem ser gerenciados, iniciando com a identificação da necessidade, passando pelo planejamento do projeto, coletar informações, analisar dados, desenvolver e avaliar alternativas para solucionar o problema e finalmente apresentar recomendações. Eles observam que um pequeno projeto deve ser gerenciado utilizando-se uma versão simplificada da maioria dos conceitos, processos e técnicas adotadas em grandes projetos. Eles classificam pequenos projetos como envolvendo menos que 5 pessoas, com custo entre US$ 5 mil e US$ 50 mil. Kerzner (2001) considera pequenos projetos os de duração entre 3 e 12 meses, custos entre US$ 5 mil e US$ 1,5 milhão em não mais do que 3 ou 4 centros de custos e que não tenha mais do que 3 níveis na decomposição do projeto pelo WBS. Existe contínua comunicação entre os membros da equipe, onde o gerente do projeto trabalha em contato diário com recursos de áreas funcionais, dispensando relatórios detalhados em intervalos curtos. O controle de custos pode ser feito manualmente em vez de por sistemas informatizados. Embora não exista um consenso na literatura sobre o ponto de corte de quando um projeto deixa de ser pequeno, existe a idéia comum de que a equipe deve ser pequena, o prazo curto, o custo baixo, assim como o esforço e a complexidade. As escalas ficam por ser definidas particularmente, dentro da realidade de cada empresa, levando em conta o ambiente, as naturezas de sua atuação, a indústria e outros fatores de influência.

Todos os direitos reservados

20

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

No outro extremo, Kerzner (2001) assinala que mega-projetos têm características particulares, como a alocação de um grande número de pessoas por períodos curtos e intensos e possíveis re-estruturações organizacionais quando o projeto muda de fase no ciclo de vida, podendo, por exemplo, alternar de uma estrutura matricial para projetizada. Alerta também para o risco de uma empresa, ao pegar um grande projeto, alocar os melhores recursos para o tal projeto, pondo em risco outros em andamento. Concentrar esforços e energia em um só lugar também pode ser perigoso para a empresa, que fica vulnerável e instável. É normal esses projetos demandarem esforço extra dos funcionários por tempo prolongado, o que causa perda de produtividade e descontentamento. O conhecimento e experiência em lidar com grandes projetos vão determinar as chances de sucesso, e a empresa tem que estar preparada para desenvolvê-los sob o risco de colocar a sua sobrevivência em jogo. Thomsett (2002) em seu artigo Managing Large Projects – A Special Case, desenvolve o tema destacando que projetos de grande porte não são apenas grandes pequenos projetos, e sim “animais de outra espécie”. Eles são mensurados em duas principais vertentes: esforço de desenvolvimento e duração. A primeira tem um componente de recursos humanos e outro de custo de capital. Para se ter idéia, a escala de esforço humano usada é baseada em número de pessoas-ano (trabalho de uma pessoa dedicado o ano todo, considerando 8 horas por dia, 210 dias por ano – cerca de 1680 hh). Projetos considerados realmente grandes consomem cerca de 40-50 pessoas-ano, US$ 15 milhões e levam pelo menos 2 anos. Para lidar com eles, deve-s elevar em consideração os seguintes conceitos, que deve ser revistos para casos como esses: o critérios de sucesso do projeto; o técnicas especiais de gerenciamento de projetos; o planejamento e controle em tempo real; o organização e estrutura das equipes; o estratégias de desenvolvimento combinadas; o garantia da qualidade; o ferramentas de suporte e tecnologia; o desenvolvimento das equipes; e o contratos e aquisições. Para quem se interessa no assunto, vale a referência, porém para o propósito do nosso assunto, não é necessário desenvolver mais o tema, ficando claro que existe grande diferença entre projetos de tamanhos muito diferentes. Certamente, grandes projetos não são candidatos

Todos os direitos reservados

21

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

22

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

de planejamento, pois se utilizam de modelos existentes. São projetos mais operacionais, de baixo risco e poucas surpresas. As equipes têm domínio sobre as atividades, estão treinadas para realizá-las e melhoram seu desempenho a cada novo projeto do tipo que realizam. Exemplos são instalações de redes de dados, construções padronizadas, etc. Este tipo de projeto são os melhores para serem executados de forma simultânea.

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

Todos os direitos reservados

23

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

da tradicional escola de gerência de projetos: de que projetos de engenharia e construção são do mesmo tipo que projetos empresariais, e, portanto, podem ser gerenciado com os mesmos modelos. Utilizando por exemplo, o tradicional modelo em cascata (waterfall model), onde o planejamento não pode começar antes que todas as especificações formais sejam assinadas pelo cliente, e assim por diante. No entanto, a natureza distinta entre projetos de novos processos empresariais, produtos ou sistemas e projetos de construção de prédios, mostra claramente que outros modelos mais interativos e flexíveis são necessários para o desenvolvimento do primeiro tipo de projetos. Na tabela a seguir, podemos ver melhor os contrastes entre os dois tipos de projetos:

Tabela 1 – Projetos de Engenharia vs. Empresariais PROJETOS DE ENGENHARIA

PROJETOS EMPRESARIAIS

Numero pequeno de provedores de serviços Grande número de provedores envolvidos, envolvidos, certificados e com contratos frequentemente formais

com

contratos

verbais

informais

Especificações

normalmente

fixas

e Especificações flexíveis e informais

formalizadas Padrão bem estabelecido de código de ética Código e conduta profissional

de

ética

profissional

mal

estabelecida

Metodologias bem estabelecidas, baseadas Metodologias em princípios matemáticos e físicos

conflitantes

baseadas

em

princípios teóricos e de marketing

Produtos físicos a serem entregues com Produtos abstratos a serem entregues, de componentes modulares Indicadores

de

difícil modularização

desempenho

métricas precisas Variação

reduzida

claros

e Indicadores de desempenho vagos e métricas de difícil mensuração

pelos

padronizados e constantes

processos Variação amplificada pelo individualismo e unicidade

Técnicas alternativas como as utilizadas nos conceitos de Extreme Project Management, que veremos mais tarde, foram desenvolvidas para lidar com os projetos empresariais.

Todos os direitos reservados

24

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

3.3.4.1

Características dos Projetos de TI Como já mencionado, projetos de TI atualmente estão muito ligados ao negócio da

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

Todos os direitos reservados

25

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

26

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Tecnologia em projetos bem sucedidos

Ausência de dados históricos de medição dos Precisa medição do software softwares Insucesso ao usar ferramentas automatizadas Ferramentas de estimativa usadas facilmente de estimativa Fracasso no uso de ferramentas automatizadas de planejamento

Uso contínuo de ferramentas de planejamento

Falhas na monitoração do progresso do

Relatório formal do progresso do projeto

Todos os direitos reservados

27

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

projeto ou milestones Falha no uso de uma arquitetura efetiva

Planejamento formal da arquitetura

Não cumprimento de um método de desenvolvimento

Método formal de desenvolvimento

Gerenciamento de risco informal

Gerenciamento de risco formal

Insucesso no uso formal do controle de configuração

Controle de configuração automatizado Fonte: Royce (1998)

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

3.3.4.3

Técnicas de Desenvolvimento Um processo de desenvolvimento de software pode ser visto como um guia para o

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

Todos os direitos reservados

28

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

3.3.4.3.1

XP – Extreme Programming

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

Planejamento

Teste

Codificação

Desenho

Figura 1. Processos do Extreme Programming

O processo XP é regido por doze princípios. A seguir resumimos estes princípios: o O jogo do planejamento: Visa rapidamente determinar o escopo da próxima versão, combinando prioridades de negócio e estimativas técnicas. o Pequenas versões: Visa produzir um sistema simples rapidamente, planejando novas versões em um ciclo muito pequeno. Os ciclos duram três semanas Todos os direitos reservados

29

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

30

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

31

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Figura 2: Fases do RUP É importante realçar que dentro de cada fase, um conjunto de iterações, envolvendo planejamento, levantamento de requisitos, análise, projeto e implementação e testes, é realizado. Contudo, de uma iteração para outra e de uma fase para a próxima, a ênfase sobre

Todos os direitos reservados

32

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

3.4

Extreme Project Management (XPM) Recentemente surgiu uma visão diferenciada do gerenciamento de projetos, em razão

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

Todos os direitos reservados

33

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

Escritório de Projetos (PMO). Porém, ainda peca no aprofundamento das questões operacionais que afloram no ambiente dos múltiplos projetos.

3.4.1 Conceitos XPM O Extreme Project Management (XPM) é baseado em alguns valores fundamentais, que são: o Participação – o gerenciamento de projetos é fortemente baseado na participação dos stakeholders do projeto. o Pró atividade – é um processo criativo e pró ativo de solucionar problemas. o Transparência – tudo no projeto é compartilhado com todos os stakeholders. o Foco externo – o foco do Gerente de Projetos é para fora do projeto, em direção aos stakeholders. o Confiança – a equipe do projeto é tratada como profissionais em que se pode confiar. Além dos valores acima, o XPM aplica os seguintes conceitos: o Contexto é mais importante do que conteúdo. O gerente de projetos no XPM deve estar focado nos aspectos empresariais do projeto, em vez dos aspectos técnicos do produto ou serviço que está sendo realizado pelo projeto. Deve se preocupar mais com os stakeholders, com os objetivos e benefícios do projeto, impacto, riscos - enfim, o contexto do projeto, ao invés do conteúdo, que é o aspecto mais técnico do projeto. Quanto menos o gerente do projeto souber dos detalhes técnicos do projeto, melhor. o Ciclo de vida do projeto inclui período pós-implantação. O que acontece após o projeto é tão importante quanto durante. Tradicionalmente, o projeto termina na entrega do produto ou serviço e o aceite do cliente, ou então logo após, com uma avaliação das lições aprendidas. Porém, no XPM, o período de suporte à implantação e a verificação dos benefícios faz parte do projeto, que só termina depois de um período suficiente para verificar o resultado do projeto. o O Gerente de Projetos é mais um facilitador e integrador do que um gerente. O Gerente de Projetos que possui um forte componente técnico, tem uma tendência a tomar decisões de planejamento de forma centralizada, intuitiva e unilateral, com pouca interação com a equipe do projeto, que as vezes é somente comunicada das estimativas de prazo, custo, riscos, etc. posteriormente. Para aumentar as chances de

Todos os direitos reservados

34

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

sucesso de um projeto empresarial, o gerente de projeto deve mudar o foco do planejamento técnico para a facilitação e integração do processo de planejamento, com a participação efetiva dos stakeholders, como nas sessões RAP. o Patrocinadores funcionam como “Gerentes Executivos de Projetos”. O papel do sponsor, ou patrocinador, é ainda mais crítico para o sucesso de projetos empresariais. No gerenciamento de projetos tradicional, a participação do patrocinador é mais passiva e reativa. Normalmente, ele recebe relatórios técnicos do projeto e raramente são alertados de problemas nos projetos a não ser quando ele se torna crítico, restando pouco espaço para que o patrocinador possa ajudar. No XPM, os patrocinadores devem ser quase que “Gerentes Executivos de Projetos”, devendo ter as seguintes responsabilidades adicionais: - participar das sessões de planejamento do projeto que definem escopo, objetivos, benefícios e stakeholders; - assistir ao Gerente de Projeto nas disputas políticas e de poder na organização que influenciam o projeto; - monitorar indicadores críticos do projeto, além das de custo e prazo. o Planejamento por cenários em vez de macro-planejamento. Se não puder prever o futuro com precisão, não o detalhe no cronograma, pois apenas cria falsas expectativas. Em muitos projetos empresariais, o nível de incerteza é tão grande, assim como o ritmo de mudanças, que fazer um planejamento detalhado de todas as fases do projeto é um convite para o retrabalho intensivo e constante de replanejamento. O modelo de planejamento tradicional foi criado numa época de poucas e lentas mudanças, com envolvimento mínimo do cliente. Consiste em criar um plano inicial detalhado para todas as fases do projeto (macro-planejamento), congelar os requisitos definidos pelo cliente e seguir à risca o plano, tentando evitar ao máximo as mudanças. O problema é que para o tipo de projeto que estamos discutindo, as mudanças acontecem com ou sem a nossa permissão. A solução, nesse caso, é o planejamento por cenários, onde eventos selecionados (o resultado de um subproduto, um acordo, uma prova de conceito, a construção de um protótipo, etc.) definem o caminho a seguir, ou qual cenário desenvolver. Essa técnica é especialmente importante para projetos de Pesquisa & Desenvolvimento, onde não se sabe se o resultado da pesquisa será o esperado. Deve-se então detalhar as atividades somente Todos os direitos reservados

35

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

até o primeiro evento, enquanto os cenários alternativos têm somente etapas genéricas delineadas. Esse tipo de planejamento também é chamado de real-time planning, ou planejamento em tempo real. Esse modelo tem sido utilizado com sucesso em ações militares, substituindo o processo linear utilizado até a guerra do Vietnã. O nível de incerteza e a dinâmica do projeto vai determinar o detalhamento do plano, o número de cenários possíveis e o ritmo do acompanhamento do projeto. Normalmente, é difícil detalhar mais do que 6 meses em projetos empresariais.

Se os cenários estão

razoavelmente definidos, e houver possibilidade de estimativas para eles, deve-se usar para referência para o projeto a estimativa do pior caso (o mais longo ou mais caro, dependendo do foco do projeto). A dica é decidir qual cenário seguir o mais rápido possível, para realinhar as bases de planejamento. o Planejamento rápido e participativo. Em projetos empresariais é muito importante encurtar ao máximo o ciclo de vida do projeto, pela própria natureza das necessidades do projeto e do ambiente em que se encontra. A fase de planejamento é crucial em qualquer projeto, devendo ser feita de forma completa. Porém, completude não é sinônimo de demora e o conceito de planejar com a participação ativa da equipe levou ao desenvolvimento de técnicas de planejamento rápido, que serão discutidas em seguida. O conceito também é aplicado em sessões de planejamento estratégico empresarial. O importante, no final, é que o planejamento não deve ser feito por uma só pessoa, deve envolver os stakeholders principais e não deve conter o que não pode ser previsto.

o

Equipes virtuais em vez de equipes tradicionais. Os dias onde uma equipe era mantida unida por anos, trabalhando junta no mesmo lugar, compartilhando experiências, conhecimento, e desenvolvendo relacionamentos de confiança, amizade e lealdade, estão contados, se já não acabaram. A realidade no novo ambiente de negócios é a equipe formada por elementos diferentes de várias áreas da empresa, muitas vezes de fora, dedicados parcialmente ao projeto, com pouca ou nenhuma lealdade à equipe, confiança entre os membros limitada ao respeito técnico, pouca troca de conhecimento, experiências, ou amizade, causada muitas vezes pela distância física e meios de comunicação virtuais.

Essa é a equipe virtual, que deve ser

gerenciada de forma diferente da equipe tradicional.

Todos os direitos reservados

36

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

3.4.2 Técnicas e Ferramentas XPM Dentre as várias técnicas e ferramentas criadas e adotadas no XPM, algumas se sobressaem e são mais pertinentes ao nosso tema de múltiplos projetos: o Sessões RAP.

A necessidade de se planejar com a participação ativa da equipe de

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

Todos os direitos reservados

37

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Figura 3 – Exemplo de aplicação das “Réguas de Sucesso”

Todos os direitos reservados

38

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

3.4.3 O Modelo de Gerenciamento XPM No XPM, segundo Thomsett (2002), o gerenciamento envolve as etapas: Estudo de Viabilidade, seguido da Aprovação e Priorização, Planejamento, Acompanhamento, Relato e Controle de Mudanças e finalmente a Verificação dos Benefícios. Destaca-se a técnica de planejamento chamada de RAP, mencionada anteriormente. Thomsett, baseado na aplicação de mais de 500 sessões RAP em seus clientes, acredita que esta seja a forma mais efetiva de planejamento, obtendo consenso nos temas críticos como escopo e objetivos do projeto, no tempo mais rápido. Embora tenha objetivos similares, de oferecer uma referência para a execução do projeto, a estrutura do plano resultante do RAP no XPM difere um pouco do Plano do Projeto indicado pelo PMBOK, sendo as principais etapas: 1. Definir os critérios de Sucesso do projeto (de acordo com as expectativas dos stakeholders) 2. Definir Escopo, Objetivos e analisar Stakeholders 3. Analisar os Benefícios esperados e o Valor Agregado do projeto 4. Definir critérios e requerimentos de Qualidade 5. Selecionar uma Estratégia de Desenvolvimento 6. Analisar Riscos 7. Desenvolver Lista de Atividades 8. Estimar esforço e prazo 9. Desenvolver o Cronograma com Alocação de Recursos 10. Desenvolver Retorno do Investimento (ROI) Para o nosso contexto, vale destacar o item 5 - Selecionar uma Estratégia de Desenvolvimento, a ser discutido em mais detalhes. Após a definição do escopo, objetivos e dos stakeholders do projeto, o próximo passo mais importante é analisar e escolher, junto com a equipe, a estratégia de desenvolvimento do projeto. De que forma o projeto será desenvolvido afetará o desempenho, quanto à prazo, custo e risco do projeto, mas não deve ser confundido com metodologia, que pode ser aplicada em qualquer estratégia de desenvolvimento. Thomsett (2002) agrupa as estratégias em diferentes tipos: o Monolítica (ou Cascata - Waterfall) Essa é certamente a estratégia mais antiga, sendo utilizada até hoje nos projetos tradicionais, principalmente nas indústrias de engenharia e construção. Consiste na realização

Todos os direitos reservados

39

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

do projeto em fases lineares e distintas, onde uma fase só começa quando a fase anterior termina, como em uma linha de montagem. Vamos imaginar o projeto de desenvolvimento de um novo produto. O planejamento só pode iniciar após todos os requisitos terem sido levantados e analisados. A construção do produto, por sua vez, depende dos planos estarem concluídos e aprovados. Terminado o produto por completo, pode-se então implementá-lo ou disponibiliza-lo. (veja fig. 4).

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

Todos os direitos reservados

40

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Figura 5 – Estratégia por Versões O desenvolvimento simultâneo é a tentativa de se abreviar ainda mais a duração do projeto, trabalhando com equipes maiores divididas em múltiplas versões que são desenvolvidas em paralelo, com o máximo de independência uma da outra. Porém, o custo de gerenciamento e o risco aumentam nessa variação. É inevitável uma troca de dados mais dinâmica entre as equipes, sendo que uma alteração em uma versão pode provocar impacto e

Todos os direitos reservados

41

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Figura 6 – Estratégia Evolutiva Evidentemente, o gerente de projetos pode misturar as várias estratégias para compor aquela que melhor atende a necessidade do projeto, onde o limite é a sua imaginação. Por exemplo, ele pode combinar a incremental, por versões com a evolutiva, acelerando ainda

Todos os direitos reservados

42

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

mais a entrega da primeira versão, e enquanto ele a estabiliza, pode estar já desenvolvendo as próximas de forma simultânea. E por aí vai. Existe uma relação forte entre a estratégia a ser utilizada no desenvolvimento e o nível de risco do projeto. Embora possa parecer que quanto mais alto o risco do projeto, mais conservador devesse ser a estratégia escolhida, a recomendação é justamente o oposto. Projetos de alto risco devem utilizar estratégias mais radicais, menos ortodoxas, justamente para abreviar seu desenvolvimento e validar as premissas ou resultados o mais rapidamente possível, evitando descobrir só no final do projeto que ele não vai prover os benefícios esperados, após grande investimento.

3.5

Ambientes de Múltiplos Projetos Quando se pensa em múltiplos projetos, podem vir múltiplas idéias sobre o assunto.

Afinal, se uma organização tem pelo menos alguns projetos para realizar, não teria ela então múltiplos projetos? Do ponto de vista matemático, certamente. Porém, existem várias formas de se tratar do tema. O PMI lançou em 2003 o modelo OPM3 que tem como objetivo principal tratar do gerenciamento de projetos a nível organizacional, sendo uma ferramenta para avaliar o nível de maturidade da organização no tema e prover um direcionamento para a melhoria de seus processos no que se refere ao gerenciamento de projetos. O OPM3 veio também como uma primeira iniciativa para suprir uma necessidade de se lidar com ambientes de múltiplos projetos, que foge do escopo do PMBOK, padrão para gerenciamento de projetos individuais. Embora não esgote o assunto e necessite de evolução e aprofundamento, ele certamente introduz o conceito, apresentando o gerenciamento de projetos em três domínios diferentes: portfólio, programas e projetos. São visões diferentes de como lidar com projetos e múltiplos projetos. Vamos discutir a seguir como são essas visões e como se relacionam com o gerenciamento de múltiplos projetos que discutimos neste trabalho. Para situar a apresentação dos conceitos, apresentamos na figura 7 como esses três domínios se relacionam dentro da organização.

Todos os direitos reservados

43

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

44

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

45

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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 Todos os direitos reservados

46

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

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

Todos os direitos reservados

Já Dobson (1999) se refere ao 47

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

48

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

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

Todos os direitos reservados

49

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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.

Todos os direitos reservados

50

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

Agrupamento por Tipos de Projetos Cleland e Ireland (2000) acreditam no gerenciamento de múltiplos projetos como forma de otimizar os recursos e obter ganhos de escala utilizando processos e metodologia padronizada de acordo com afinidades entre os projetos. Geralmente de porte menor, pela sua maior simplicidade, os projetos podem ser agrupados por alguns princípios básicos, descritos a seguir: o Prioridade – projetos agrupados por prioridades semelhantes estão menos suscetíveis ao risco do gerente dar pouca atenção e recursos para projetos menos prioritários em seu grupo de projetos. A idéia é que se houver priorização de projetos, estes devem ser agrupados com prioridades semelhantes. o Porte – projetos de um mesmo grupo devem ter tamanhos similares, dentro da medida que foi aplicada, se duração, valor ou recursos necessários. Misturar projetos de portes diferentes pode desequilibrar a distribuição de recursos entre eles. Os projetos mais indicados para sofrerem gerenciamento múltiplo são os de curta duração com poucos recursos envolvidos. o Ciclo de Vida – projetos agrupados devem ter o mesmo ciclo de vida, facilitando a adoção de uma mesma metodologia para gerenciá-los, embora idealmente eles devam estar em fases diferentes do ciclo. o Complexidade – os projetos mais indicados para se gerenciar de forma compartilhada devem ter relativa simplicidade, evitando misturar projetos muito complexos com outros mais simples, pois provavelmente o esforço do gerente será direcionado para os complexos. o Tecnologia – projetos gerenciados de forma simultânea devem compartilhar também a mesma tecnologia, maximizando os esforços com competências semelhantes. Projetos em Pequenas Empresas O ambiente de gerenciamento de projetos em pequenas empresas tem características próprias que afetam o papel do gerente de projetos. Kerzner já identificava em 1982 em seu livro Project Management for Executives, as diferenças entre os ambientes de gerenciamento de projetos de grandes e pequenas empresas, como: o O gerente de projetos tem vários chapéus, sendo muitas vezes gerentes funcionais também;

Todos os direitos reservados

51

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

o O gerente de projetos está envolvido em múltiplos projetos, com prioridades diferentes; o Os recursos para os projetos são mais limitados; o Maior necessidade para habilidades interpessoais; o Maior vulnerabilidade ao fracasso de um único projeto; o Pode haver controle financeiro mais rígido, porém com técnicas menos sofisticadas; o Maior interferência da alta administração nos projetos, devida à maior proximidade com a gerência operacional; o Resolução de conflitos pode ser mais fácil ou mais difícil, sendo mais afetado pela personalidade dos envolvidos; o O número de projetos compartilhados pela equipe é maior. Pode ser mais difícil implementar o gerenciamento de projetos em empresas pequenas pelos papéis múltiplos que as pessoas devem assumir. É mais provável também que o gerente de um projeto seja recurso de outros projetos, alternando posições e papéis de acordo com a situação e o projeto. Quando o gerente funcional veste o chapéu de gerente de projetos, devese ter uma atenção especial, pois a tendência é que ele escolha os melhores recursos para o seu projeto, potencialmente desguarnecendo outros projetos. È difícil ter o equilíbrio de dedicação tanto no plano horizontal (projetizado) quanto no vertical (funcional) quando os gerentes vestem ambos chapéus. Planejamento da Capacidade Na medida em que as organizações amadurecem no gerenciamento de projetos, os benefícios de se conseguir realizar mais em menos tempo e com menos recursos começam a aparecer. No entanto, a grande questão é saber quanto mais de trabalho pode uma organização ou equipe realizar com os recursos que dispõe levando em consideração as restrições a que estão sujeitas? Esse conceito de conhecer e planejar a capacidade de realização, também conhecido como capacity planning, é importante quando se discute o gerenciamento de múltiplos projetos. Kerzner (2001) alerta que normalmente as empresas costumam planejar o seu “poder de fogo” apenas em termos de recursos humanos, fazendo uma previsão de crescimento de mão de obra em razão dos recursos necessários previstos nas propostas de projetos externos e requisitos de projetos internos. No entanto, ele sugere um método que envolve outras dimensões de recursos. Após a seleção dos projetos que serão incluídos no portfólio da empresa, é necessária a identificação distinta dos objetivos do projeto em termos empresariais (negócios) e técnicos. Desta forma fica mais fácil identificar restrições de ambas Todos os direitos reservados

52

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

53

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

3.5.7 Gerenciamento do Tempo O tema de gerenciamento de tempo é fundamental na discussão de gerenciamento de múltiplos projetos. Para muitos, tempo é um fator de restrição. Aprender a gerenciar bem o tempo é a arte de transformá-lo em recurso. Porém, é um recurso que será consumido, sendo bem usado ou não. Kerzner (2001) descreve fatores importantes que influenciam o bom gerenciamento do tempo, que vamos discutir aqui, que são: os ladrões de tempo, reuniões, a questão das horas extras, ciclos de energia no dia e na semana, stress, produtividade e delegação. O gerente de projetos deve aprender a ter disciplina no gerenciamento de seu próprio tempo. Se esse fator é crítico para o gerente de um projeto, ele é vital para o gerente de múltiplos projetos. O gerente de projetos inexperiente normalmente tende a trabalhar longas horas extras sistematicamente, achando que é a única forma de conseguir dar conta de todo o trabalho. Com o tempo e conhecimento, ele deve começar a aprender a colocar em prática princípios eficazes de gerenciamento de tempo e delegar parte do trabalho para outros. Existem vários elementos no ambiente de projetos que “roubam” o tempo dos gerentes e da equipe, os chamados “ladrões de tempo”. Alguns desses elementos são: o o o o o o o o o o o o o o o o o o o o o o

Retrabalho Decisões adiadas Comunicação fraca Telefonemas Espera por pessoas Visitas inesperadas Interrupções constantes Falta de delegação Sistema falho de recuperação de informações Falta de apoio administrativo Excesso de emails Informação mal formatada Muitas pessoas trabalhando em um ambiente pequeno Excesso de conversa casual no escritório Excesso de mudança Excesso de reuniões Falta de direcionamento Desorganização Excesso de deslocamentos Falta de ferramentas adequadas Excesso de burocracia Excesso de carga de trabalho, muitos projetos

Todos os direitos reservados

54

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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 Todos os direitos reservados

55

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

56

Gerenciamento de Múltiplos Projetos

3.6

TCC GP09 RJ / FGV

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

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

Todos os direitos reservados

57

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

58

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

Possíveis variações nas atividades são aceitas e passam a consumir parte dos pulmões que estão reservados. Neste caso, o acompanhamento do desempenho do cronograma não é tanto pelo cumprimento do prazo de cada atividade do projeto, mas sim por quanto dos pulmões já foram usados, em comparação com quanto do projeto já foi realizado.

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

Todos os direitos reservados

59

Gerenciamento de Múltiplos Projetos

4

4.1

TCC GP09 RJ / FGV

ANÁLISE DE RESULTADOS

Pesquisa de Campo I Neste capítulo serão analisados os resultados da pesquisa de campo realizada por meio

do questionário apresentado no Anexo I.

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

60

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Tabela 3 - Sumário dos dados descritivos Tipo de Dados Segmento Profissional

Valores mais significativos TI + Serviços = 39,5 %

Constatações Maior concentração na área de serviços e TI.

Tipo de Projeto

TI = 47%

Forte concentração de projetos de TI.

Atuação Predominante Projetos simultâneos

Gerente = 68,8 %

Forte predominância de

Equipe = 30,2 %

Gerentes.

2-5 > 60 %

Predominância de número baixo de projetos simultâneos.

Quantidades de projetos

Aumentando > 60%

Índices de projetos simultâneos aumentando

Todos os direitos reservados

61

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

Recursos por projetos

5-20 > 56 %

Predominância de projetos de alocação média de recursos

Duração média dos

6 meses > 50%

Baixa duração dos

projetos

projetos

Complexidade dos

Baixa > 50%

Maior concentração de

projetos

projetos de baixa complexidade

Nível de stress

Mais estressante > 86%

Alto nível de stress em projetos simultâneos.

Critérios de Sucesso

Preocupação com Prazo > 33%

Visão voltada ao cliente.

Satisfação do Cliente > 31 %

4.1.2.3 Resultados por Tipo de Dados Este tópico apresenta os resultados separadamente por Tipo de Dados, realizados na pesquisa. 4.1.2.3.1 Quanto ao Segmento da Empresa 35,00% 28,68%

30,00%

27,91%

25,00% 20,00% 15,50% 15,00% 10,85%

10,08% 10,00%

4,65%

5,00%

2,33%

0,00% Industria

TI

Telecom

Petroleo e Gas

Serviços

Finanças

Outros

Figura 8 - Segmento da Empresa

Todos os direitos reservados

62

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

4.1.2.3.2 Quanto ao Tipo de Projeto

50,00%

47,29%

45,00% 40,00% 35,00% 30,00% 25,00% 20,00% 16,28% 15,00%

11,63%

11,63%

Organizacional

Des env Produtos

13,18%

10,00% 5,00% 0,00% TI

Pres tação de Serviços

Outros

Figura 9 – Tipo de Projeto 4.1.2.3.3 Quanto a Atuação no Projeto

80,00% 69,77% 70,00% 60,00% 50,00% 40,00% 30,23% 30,00% 20,00% 10,00% 0,00% Gerente

Equipe

Figura 10 – Atuação no Projeto

Todos os direitos reservados

63

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

4.1.2.3.4 Quanto a Quantidade de Projetos Simultâneos 70,00% 62,79% 60,00% 50,00% 40,00% 30,00% 20,16% 20,00% 12,40% 10,00%

4,65%

0,00% 1

2-5

5 - 10

> 10

Figura 11 – Quantidade de Projetos Simultâneos

4.1.2.3.5 Quanto ao Volume de Projetos 70,00% 61,24% 60,00% 50,00% 37,98%

40,00% 30,00% 20,00% 10,00% 0,78% 0,00% Aumento

Diminuído

Estável

Figura 12 – Volume de Projetos

Todos os direitos reservados

64

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

4.1.2.3.6 Quanto aos Recursos Alocados

60,00%

56,59%

50,00%

40,00%

30,00%

25,58% 17,83%

20,00%

10,00%

0,00% <5

5 - 20

> 20

Figura 13 – Recursos Alocados

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

60,00% 54,26% 50,00%

40,00% 32,56% 30,00%

20,00% 13,18% 10,00%

0,00% <3

3-6

>6

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

Todos os direitos reservados

65

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

4.1.2.3.8 Quanto a Complexidade dos Projetos

80,00% 69,77% 70,00% 60,00% 50,00% 40,00% 29,46% 30,00% 20,00% 10,00% 0,78% 0,00% A lta

Média

Baixa

Figura 15 – Complexidade dos Projetos 4.1.2.3.9 Nível de Stress

100,00% 90,00%

86,82%

80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,08% 10,00%

3,10%

0,00% Mais

Igual

Menos

Figura 16 – Nível de Stress

Todos os direitos reservados

66

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

4.1.2.3.10 Quanto ao Critério de Sucesso

35,00%

33,33% 31,01%

30,00% 25,00% 20,00%

17,05%

15,00%

12,40%

10,00% 6,20% 5,00% 0,00% Terminar no Prazo previsto

Ficar dentro do Orçamento

Cumprir a Qualidade esperada

Satisf azer o Cliente

Traz o Benef ício a que se propõe

Figura 17 – Critério de Sucesso 4.2

Pesquisa de Campo II No intuito de aumentar a profundidade da Pesquisa de Campo I, procuramos fazer um

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

Todos os direitos reservados

67

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

4.2.1 Sumário dos Dados Descritivos Tabela 4: Sumario dos dados descritivos, Chaves (2004) Tipo de Dados Experiência profissional

Valores mais significativos

Constatações

Media do total: 13,5 anos

Informantes com

Média de projetos individuais: 5,2

experiência média nos

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

dois tipos de gerenciamento

Gerenciamento

de 2 a 3 projetos = 51%

Taxas razoáveis de

simultâneo

de 4 a 6 projetos = 26%

gerenciamento de multiprojetos a nível individual

Negócio principal das

Serviços + Informática = 51%

Forte concentração em

organizações

Indústria = 25%

áreas ligadas a serviços (> 50%)

Características dos

Sistemas + Prest. de Serviços =

Forte predominância de

projetos individuais

62%

projetos "soft" em relação a outros tipos

Grau de complexidade

Nível Médio = 53,8%

Forte grau de

Nível Alto = 40,6%

complexidade dos projetos

Grau de Incerteza de

Nível Médio = 62,3%

Alto grau de

prazos e custos

Nível Alto = 25,5%

complexidade dos projetos

Índice de sucesso em

Baixo + Médio = 80% nos

Índice pouco satisfatório

prazo

projetos grandes

Piora na medida que cresce o porte do projeto

Índice de sucesso em

Baixo + Médio = 78% nos

Índice pouco satisfatório

custos

projetos grandes

Piora na medida em que cresce o porte do projeto

Índice de sucesso em

Médio + Alto = 90% nos projetos

Índice satisfatório

qualidade

médios e grandes

Não varia muito em função do porte do

Todos os direitos reservados

68

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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 dos recursos em tempo

time"

integral aos projetos Agrupamento dos

Por Produto + Por Estratégia =

Agrupamento com

projetos do Portfólio

63%

enfoque voltado a resultados

Estrutura organizacional

Matriz Projetizada + Time de

Tendência para o

projeto = 50% das empresas

enfoque de times de projeto, poucas estruturas funcionais

Níveis de planejamento

Médio Prazo (eventual + sempre)

Maior foco em curto em

de Portfólio

= 76%

médio prazo

Longo Prazo (eventual + sempre ) = 50% Metodologia de Gerência Modelo específico de cada

Maior foco no Gerente

de Projeto

Departamento = 15 %

do projeto ou corporativa

Prioridade dos projetos

Benefício Estratégico = 56%

Visão estratégica é

do Portfólio Uso de Gerente auxiliar

predominante Não = 60%

Taxa média/baixa de uso

Eventual + regular = 74 %

Aplicação do conceito

para multiprojetos Conceito de Gerência de Portfólio

ainda em nível intermediário

Todos os direitos reservados

69

Gerenciamento de Múltiplos Projetos

4.3

TCC GP09 RJ / FGV

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

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

5

CONCLUSÕES

Apresentamos, no decorrer do trabalho, uma extensa pesquisa bibliográfica sobre conceitos, técnicas, ferramentas e características do ambiente de múltiplos projetos e das questões relativas ao seu gerenciamento, que por si só já vão ajudando a responder algumas das questões mais problemáticas sobre o tema. Vamos discutir agora, como esses elementos se relacionam visando avançar o entendimento do assunto e auxiliar no desempenho dessa função.

5.1

A Importância do estudo de Múltiplos Projetos para a Organização Primeiramente é importante destacar a participação vital dos projetos no desempenho

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

Todos os direitos reservados

70

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

descreve com clareza como uma organização funciona, do ponto de vista de transformar estratégias em resultados.

Figura 18 – Múltiplos Projetos no Contexto da Organização

Todos os direitos reservados

71

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

O ambiente de múltiplos projetos que inclui o portfólio completo, com todos os programas e projetos independentes, formam o plano de ação que materializa a estratégia da organização, produzindo os resultados que vão reposicioná-la no mercado.

5.2

A Gerência de Múltiplos Projetos e a Teoria de Administração de Empresas Na discussão do referencial teórico, apresentada anteriormente, ficou claro que há uma

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

72

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

acontece com os gestores na estrutura organizacional de uma empresa, ou grupo de empresas. Essa é uma verdade também aplicada na gerência de programas e na gestão de portfólio.

5.3

Conceitos Básicos para Gerenciar Múltiplos Projetos com Sucesso Após a discussão de tantos elementos influenciadores no desempenho de um bom

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

seus pequenos

projetos. Treinamento Para se ter sucesso no gerenciamento de múltiplos projetos, o investimento no treinamento deve ser forte, pois não bastam os gerentes de projetos serem capacitados, mas

Todos os direitos reservados

73

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

também as equipes e as lideranças funcionais. Se tivermos que aplicar o gerenciamento distribuído, como fazê-lo sem que a equipe tenha competência para desempenhar o seu papel? Como foi discutido anteriormente, utilizar modelos de competência para mapear a qualificação dos recursos humanos nos pontos que influenciam o bom andamento dos projetos, como habilidades de planejamento, comunicação, relações interpessoais, técnicas de gerenciamento de projetos, metodologia da empresa, etc. e atuar no crescimento dessas competências são fatores críticos de sucesso. Para compartilhar o poder com a equipe, é preciso qualificá-la e capacitá-la. Em qualquer esporte coletivo, um time que não treina e não tem bons fundamentos, não ganha o jogo. Em projetos isso também é verdade. Nível de Controle do Projeto Uma questão crucial que determina a sua capacidade de gerenciar múltiplos projetos é o tempo e o esforço necessários para manter o controle do mesmo. A freqüência com que as atividades são acompanhadas, ou o intervalo entre os pontos de controle do projeto, vão determinar o quanto de atenção, e conseqüentemente, do tempo do gerente do projeto será destinado para supervisionar o projeto. Um controle detalhado por parte do gerente de projeto vai absorver boa parte de sua capacidade de realização, impedindo-o de dar atenção para outros projetos. Algumas questões influenciam muito nessa demanda por controle, sendo as principais: o Risco do Projeto:

é claro que quanto mais risco envolver o projeto, mais

suscetível ele estará para variações nos resultados, mudanças de escopo, problemas inesperados e logicamente mais controle deve haver sobre ele. Portanto, será necessário aumentar a granularidade do acompanhamento, obrigando um maior detalhamento das atividades e um intervalo menor entre os pontos de controle para que haja tempo de tomar medidas corretivas, se necessário. o Experiência da Equipe: quanto mais experiente for a equipe, menos particionamento das atividades será necessário, permitindo que a equipe desenvolva e reporte o projeto em níveis mais altos da hierarquia de lista de atividades. Por exemplo, se uma equipe nunca fez um tipo de projeto, ou seus membros tem pouca experiência de trabalho, será necessário um controle maior, quebrando as atividades em sub-atividades ainda menores para manter um controle mais rígido. o Nível de Confiança na Equipe:

quanto mais se confia na equipe, menos

supervisão e conseqüentemente menos detalhamento das atividades é necessário. Todos os direitos reservados

74

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

Para gerenciar múltiplos projetos, o ideal é ter uma equipe confiável, onde se possa delegar responsabilidade, como já foi comentado. Maior maturidade das equipes, mais projetos simultâneos podem ser gerenciados.

5.4

XPM em Múltiplos Projetos Conceitos e técnicas desenvolvidas pelo Extreme Project Management tem muita

sinergia e utilidade no gerenciamento de múltiplos projetos. O XPM surgiu como uma alternativa ao tradicional gerenciamento de projetos para lidar com projetos contemporâneos, empresariais, frutos de um ambiente turbulento e em constante mudança. Ficou claro concluir que os projetos que são normalmente gerenciados de forma simultânea se beneficiariam muito das soluções propostas pelo XPM. Técnicas que dão mais flexibilidade ao gerente, economizam seu tempo e encurtam o ciclo de vida do projeto facilitam bastante a vida do gerente de múltiplos projetos. Vejamos os momentos onde podemos aplicar os conceitos e técnicas do XPM em múltiplos projetos de forma mais produtiva. Seleção de Estratégias de Desenvolvimento O importante na hora de escolher a estratégia é identificar o que é mais importante para cada projeto. Voltar às origens, aos critérios de sucesso, às restrições e à análise do ambiente. Qual é o foco do cliente ou do patrocinador: prazo, custo, qualidade, benefícios? Afinal, se o projeto não puder ser entregue no prazo com a qualidade esperada, o que é mais importante, focar no prazo ou na qualidade? Pode-se degradar a qualidade de forma acordada para cumprir o prazo para depois elevar a qualidade, mesmo tendo mais custos (estratégia evolutiva)? Isso vai maximizar os benefícios para a empresa ou cliente? Dependendo das respostas para essas perguntas, deve-se então escolher a estratégia a ser adotada, ou uma combinação apropriada. Interessante notar que, para projetos de curta duração, equipe pequena, baixo risco e complexidade, a melhor estratégia pode bem ser a monolítica. Dentro desse raciocínio, a estrutura monolítica pode ser usada também para parte do desenvolvimento de uma versão ou componente do projeto, compondo uma estratégia diferenciada mais ampla. Especificamente para o gerente de múltiplos projetos, ele deve tomar cuidado ao escolher uma estratégia que requer muito esforço e tempo de gerenciamento, procurando evitar a estratégia incremental de desenvolvimento por múltiplas versões simultâneas, a não ser que as equipes tenham alto grau de maturidade e autonomia. Embora a estratégia de desenvolvimento de um projeto deva ser escolhida em função do sucesso do mesmo, o gerente

Todos os direitos reservados

75

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

também tem que ter uma boa noção de sua própria capacidade de realização para não comprometer o sucesso de vários projetos, adotando ma estratégia complexa num ambiente desfavorável. Neste caso, ele deve discutir com o gestor do portfólio ou gerentes dos programas afetados para redistribuir a carga de trabalho ou designar recursos adequados aos projetos envolvidos.

5.5

Ferramentas para Múltiplos Projetos Ferramentas são definidas como utensílios ou elementos usados para auxiliar na

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

76

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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. Todos os direitos reservados

77

Gerenciamento de Múltiplos Projetos

5.6

TCC GP09 RJ / FGV

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

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

Todos os direitos reservados

78

Gerenciamento de Múltiplos Projetos

5.7

TCC GP09 RJ / FGV

Abordagem para Múltiplos Projetos de TI Tomando por base as nossas e outras pesquisas de campo, concluímos que o segmento

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

Todos os direitos reservados

79

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

A AM promove: o Os indivíduos e as interações em vez dos processos e das ferramentas: As pessoas e as comunicações são o mais importante. o O software de trabalho em vez da documentação abrangente: O objetivo de um esforço de desenvolvimento de software é desenvolver o software. O objetivo do desenvolvimento de software não é produzir documentação, essa pode ser uma das tarefas que suporta o software. o A colaboração com o cliente em vez da negociação de contrato: Muito mais progresso é feito se a colaboração for usada no lugar da simples negociação. A equipe não pode manter um modelo dinâmico e mutável sem o envolvimento constante do cliente. Usar apenas a negociação significa criar todos os requisitos desde o início em um processo de “toma-lá-dá-cá” entre equipe e o cliente. Se houver uma colaboração mais próxima com o cliente, este pode alterar os requisitos imediatamente, a equipe pode discutir os requisitos com o cliente, buscar esclarecimentos e obter outras informações que sejam necessárias. o Responder à mudança em vez de seguir um plano: Para que um software atenda ás necessidades do cliente, ele deve ser desenvolvido em um ambiente que mude e que responda aos requisitos da mudança. Por fim, veremos alguns valores e práticas usadas no XP e no RUP para melhor gerenciar múltiplos projetos. Valores o Comunicação: A comunicação efetiva é necessária entre todos aqueles envolvidos no projeto: desenvolvedores, gerentes e clientes. Uma das principais finalidades de criar os modelos é a comunicação. o Honestidade: A comunicação é inútil, até mesmo prejudicial, se ela não for honesta: os desenvolvedores devem ser honestos em suas estimativas, por exemplo. Se a comunicação for aberta e honesta, as pessoas podem confiar uma nas outras e podem avançar muito mais rápido. o Simplicidade: Fazer a coisa mais simples que possa funcionar é o maior valor de todos e se aplica da mesma forma aos modelos e aos códigos.

Todos os direitos reservados

80

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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 Todos os direitos reservados

81

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

quadro que contém o modelo, ou tendo um lugar na sua intranet no qual podem ser publicados.

5.8

Considerações Finais Os objetivos deste trabalho foram descrever os vários ambientes de múltiplos projetos

nas organizações e oferecer auxílio para os gerentes responsáveis por vários projetos simultâneos, no plano operacional, atuarem com mais esclarecimento e chances de sucesso. Fizemos um paralelo com os conceitos clássicos da administração, demonstramos as origens do tradicional gerenciamento de projetos e mostramos porque ele não é o mais adequado para o desafio de múltiplos projetos, descrevemos o perfil dos projetos atuais, apresentamos alternativas de gerenciamento através do XPM e outras linhas de pensamento, como a Teoria de Restrições e o Método da Cadeia Crítica, e fizemos uma análise mais aprofundada para projetos de TI, que são muito representativos do tema. Para alinhar os conceitos e teorias à realidade local, utilizamos pesquisas de campo para ratificar os argumentos encontrados no referencial bibliográfico. Após toda a discussão do tema, procuramos resumir parte do resultado prático do trabalho em uma lista de fatores críticos de sucesso para o gerenciamento de múltiplos projetos, a seguir. Fatores Críticos de Sucesso para o Gerenciamento de Múltiplos Projetos: 1. Identificar e selecionar os tipos de projetos mais adequados 2. Agrupar os projetos de forma a facilitar o gerenciamento 3. Utilizar uma metodologia adequada 4. Utilizar a estratégia de desenvolvimento mais adequada à situação 5. Encurtar o ciclo de vida dos projetos 6. Manter o controle a nível macro 7. Distribuir a responsabilidade e o gerenciamento 8. Ter consciência dos limites de capacidade de realização do gerente e das equipes 9. Focar na comunicação 10. Escolher uma equipe em que se pode confiar 11. Capacitar toda a equipe, não somente os gerentes 12. Eliminar a burocracia excessiva 13. Minimizar o comportamento multitarefa (multitasking) 14. Utilizar um sistema de gerenciamento de projetos voltado para a equipe Todos os direitos reservados

82

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

Todos os direitos reservados

83

Gerenciamento de Múltiplos Projetos

6

TCC GP09 RJ / FGV

BIBLIOGRAFIA

1. A Guide to the Project Management Body of Knowledge (PMBOK Guide), 3rd Edition (EXPOSURE DRAFT). Newton Square, Pennsylvania: Project Management Institute, 2004 2. AJANI, Shaun. Extreme Project Management, New York, Writers Club Press, 2002. 3. BADIR, Yuosre F., FOUNOU, Remi, STRICKER, Claude, BOURQUIN, Vincent. Management of global large-scale projects through a federation of multiple web-based workflow management systems. Project Management Journal, Pennsylvania, PMI, v. 34, n. 3, pgs. 40-47, setembro 2003. 4. BECK, K. Extreme Programming explained. 1st edition. Addison-Wesley Publishing Company, 1999. 5. BHEND, Marcel. Shared project management. Proceedings: Project Management Institute Seminar/Symposium (30th), Philadelphia, Pennsylvania, 1999. 6. BREITMAN, K., Leite, J. Managing User Stories. International Workshop on Time Constrained Requirements Engineering, 2002. [Breitman02] 7. BURKE, Eric Getting Started with Portfolio Management. Portfolio Knowledge, Bellevue, WA, disponível em: http://www.portfolioknowledge.com/news/process/articles.asp?id=burke

Acesso

em:

12/09/2004. 8.

CANDÉAS, A.J.; LOPES, C.C.N. Estimativa: Uma ferramenta para agilizar o dimensionamento de projetos no SERPRO com base na metodologia de análise de pontos por função. In: Simpósio Brasileiro de Engenharia de Software. Caderno de Ferramentas, 13, Florianópolis, 1999.

9. CASTLE, James P, BOONE, Brian, NUNN, John O.H. Management of multiple small projects live software demonstration. Proceedings: Project Management Institute. Seminar/Symposium (25th), Vancouver B.C., Canada, pgs. 18-24, 1994. 10. CHANG, C. K.; CHRISTENSEN, M. A Net Practice for Software Project Management.

Todos os direitos reservados

84

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

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

CLELAND, David I.; IRELAND, Lewis R. Gerência de Projetos. Rio de Janeiro: Reichmann & Affonso Editores, 2002.

15. COOPER, Robert, EDGETT, Scott. Portfolio Management for New Products: Picking the Winners. Working Paper No. 11, Product Development Institute, Ontario, Canadá. Disponível em www.stage-gate.com/pdfs/Working%20Paper%2011.pdf . Acessado em 10 out 2004. 16. DINSMORE, Paul Campbell; CAVALIERE, Adriane. Como de tornar um profissional em gerenciamento de projetos: livro-base de “Preparação para Certificação PMP – Project Management Professional”. Rio de Janeiro: Qualitymark Editora, 2003. 17. DOBSON, Michael Singer. The juggler’s guide to managing multiple projects. Newton Square, Pennsylvania: Project Management Institute, 1999. 18. DYE, Lowell D.; PENNYPACKER, James S. Project portfolio management and managing multiple projects: two sides of the same coin? Proceedings, PMI, 2000. 19. GITHENS, Gregory D. Manage innovation programs with a rolling wave. PM Network, Pennsylvania, PMI, v. 15, n. 5, p. 35-39, maio 2001. 20. HELDMAN, Kim. Gerência de projetos: guia para o exame oficial do PMI. Rio de Janeiro, Elsevier Editora, 2003. 21.

IEEE SOFTWARE. V. 16, n. 6, p. 80 -88, nov./dec. 1999.

22.

JENSEN, Bill. Simplicidade. Rio de Janeiro, Campus, 2000.

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

Todos os direitos reservados

85

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

25. KNUTSON, Joan. Managing multiple projects in a matrixed organization. Proceedings: Project Management Institute. Seminar/Symposium (25th), Vancouver B.C., Canada, pgs. 454-458, 1994. 26. KRUCHTEN, Philippe. The Rational Unified Process - An Introduction. Second Edition., 2000. 27. LUNDGREN, Earl F. Organizational Management – Systems and Process. New York, NY, Harper & Row, 1974. 28. McCONNELL, Steve. Rapid Development. Redmond, WA, Microdoft Press, 1996. 29. NEWBOLD, Robert C. Critical Chain Multi-Project Implementation. ProChain Solutions. Disponível em www.prochain.com/articles/CCMultiprojImplementation.asp. Acessado em 12 out 2004. 30. NEWBOLD, Robert C. Introduction to Critical Chain Project Management. ProChain Solutions, Inc Disponível em www.prochain.com/articles/CriticalChainArticle.asp,. Acessado em 12 out 2004. 31.

O’CONNOR, R. An Architecture for an Intelligent Assistant System for use in Software project Planning. Ph.D. Thesis, City University. Londres, 2000.

32. O’CONNOR, R.; JENKINS, J. Using Agents for Distributed Software Project Management. IEEE 8th International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises. Palo Alto, 16-18 jun., 1999. 33. Organizational Project Management Maturity Model (OPM3): Knowledge Foundation. Newton Square, Pennsylvania: Project Management Institute, 2003 34. PARTH, Frank R. Categorization of small projects. Proceedings: Project Management Institute Seminar/Symposium (29th), Long Beach, California, Vol II, pgs. 1382-1385, 1998. 35. PARTH, Frank R. Managing projects in a multitasking environment. Proceedings: Project Management Institute Global Congress - Europe, 2004. 36. PATRICK, Francis S. Program Management -Turning Many Projects into Few Priorities with TOC. Project Management Institute Symposium. Philadelphia, October, 1999. Disponível em http://www.focusedperformance.com/articles/TOCMulti.pdf

Todos os direitos reservados

86

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

37. PMI Member Fact Sheet (August 2004), Disponível em http://www.pmi.org/info/GMC_MemberFACTSheet.asp, Acessado em 11 out 2004. 38. PORTER, Michael E. Estratégia Competitiva: Técnicas para análise de indústrias e da concorrência, 7ª ed., Rio de Janeiro: Editora Campus, 1986. 39.

PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995. ISBN 85346-0237-9.

40.

Program/Portfolio Management Standard (PPMS): Project Charter. Disponível em http://www.pmi.org/prod/groups/public/documents/info/PP_ProgPortMgmtStndChrtr.asp, Acesso em 10 out 2004.

41. Project Portfolio Management: Definition and Process Overview, Whitepaper, Pacificedge Software, 2004, disponível em http://www.pacificedge.com/solutions/whitepapers.asp#meta. Acessado em 10 out 2004. 42.

SOFTWARE PRODUCTIVITY RESEARCH. Disponível em: . Acesso em: 05 set. 2004.

43. Sommer,

Renee

J.

Portfolio

management

for

projects--a

new

paradigm.

Proceedings: Project Management Institute Seminar/Symposium (29th), Long Beach, California, Vol. I, pgs. 462-464, 1998. 44. SOMMERVILLE,

I.

Software

Engineering.

4

ed.

USA:

Addison-Wesley

I.

Software

Engineering.

5

ed.

USA:

Addison-Wesley

Publishers,1992. 45.

SOMMERVILLE, Publishers,1996.

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

Todos os direitos reservados

87

Gerenciamento de Múltiplos Projetos

TCC GP09 RJ / FGV

50. VERGARA, Sylvia. Projetos e Relatórios de Pesquisa em Administração. Ed.Atlas. 1990. 51. VIEIRA, Marconi F. Gerenciamento de Projetos de Tecnologia da Informação. 1ª ed., Rio de Janeiro: Editora Campus, 2003. 52. VISITACION, Margo. Common Sense Help for E-Business Projects: Critical Chain Project Management. Planning Assumption, Cambridge, MA, Giga Information Group, 2000. 53. WHITTEN, Neal. 1 + 1 + 1 = 2. PM Network, Pennsylvania, v. 16, n. 4, p. 20, abr. 2002. 54. WOODWARD,

Hugh.

Winning

in

a

world

of

limited

project

spending.

Proceedings: PMI Global Congress, 2003.

Todos os direitos reservados

88

Gerenciamento de Múltiplos Projetos

7

TCC GP09 RJ / FGV

ANEXOS

7.1

Anexo I – Pesquisa de Campo

1. Segmento da sua empresa: Industria

TI

Telecom

Petróleo e Gás

Serviços

Finanças

Outros

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

Organizacional

Desenv. de Produtos

Prestação de Serviços

Outros

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

Equipe

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

2-5

5 - 10

> 10

5. Esse número tem: Aumentado

Diminuído

Permanecido Estável

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

5 - 20

> 20

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

3-6

>6

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

Média

Baixa

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

Igual

Menos estressante

10. Ordene os critérios de sucesso mais valorizados na sua empresa, ranking de 1 a 5: Terminar no Prazo previsto Ficar dentro do Orçamento

1 - maior valor 5 - menor valor

Cumprir a Qualidade esperada Satisfazer o Cliente Traz o Benefício a que se propõe Todos os direitos reservados

89