Você está na página 1de 101
MBAEXECUTIVO G ERENCIAMENTODE P ROJETOS Emanuel Edwan de Lima, M. Sc . Vicente Fernandes Tino,

MBAEXECUTIVO

MBAEXECUTIVO G ERENCIAMENTODE P ROJETOS Emanuel Edwan de Lima, M. Sc . Vicente Fernandes Tino, M.

GERENCIAMENTODE

PROJETOS

Emanuel Edwan de Lima, M. Sc. Vicente Fernandes Tino, M. Sc.

Aluno(a):

Curso:

Turma:

Sumário

1

PROGRAMA DA DISCIPLINA

1

1.1

EMENTA

1

1.2

CARGA HORÁRIA TOTAL

1

1.3

OBJETIVOS

1

1.4

CONTEÚDO PROGRAMÁTICO

1

1.5

METODOLOGIA

2

1.6

CRITÉRIOS DE AVALIAÇÃO

2

1.7

BIBLIOGRAFIA RECOMENDADA

3

2

TEXTO PARA ESTUDO

4

2.1

INTRODUÇÃO

4

2.2

O GERENTE DE PROJETOS

5

2.3

O CICLO DE VIDA DOS PROJETOS

6

2.4

PROCESSOS DE GERENCIAMENTO DE PROJETOS

8

2.5

ÁREAS DE CONHECIMENTO DO GERENCIAMENTO DE PROJETOS

18

2.6

ESTRUTURA ORGANIZACIONAL PARA PROJETOS

24

2.7

ESCRITÓRIO DE PROJETOS

28

2.8

ATIVIDADES DURANTE O CICLO DE VIDA DO PROJETO

29

2.9

CONCLUSÕES

49

3

MATERIAL COMPLEMENTAR

50

3.1

ESTUDO DE CASO - ÍMPAR

50

3.2

ESTUDO

DE CASO: FOX M EYER

54

3.3

ESTUDO DE CASO - GLOBALSTAR: CONECTANDO TODO MUNDO, DE TODO LUGAR

58

3.4

OURO PERDIDO

61

3.5

O EXEMPLO DA BOMBA ATÔMICA

69

3.6

VOCÊ = SEUS PROJETOS

71

3.7

COMO ACELERAR O DESENVOLVIMENTO DE NOVOS PRODUTOS

81

3.8

GERENCIAMENTO DE RISCOS EM PROJETO: M ELHORES PRÁTICAS E DESENVOLVIMENTOS FUTUROS

84

3.9

GERENTES DE M ULTIPROJETOS, QUAIS COMPETÊNCIAS SÃO NECESSÁRIAS?

89

i

1

1 Programadadisciplina

1.1 Ementa

Importância do gerenciamento de projetos. Evolução da gestão de projetos. Conceituação de projetos. Definição do papel do gerente de projetos. Processos do gerenciamento de projetos. Áreas de conhecimento do gerenciamento de projetos. Estrutura organizacional para projetos. Ciclo de vida de projetos. Importância e tipos de escritório de projeto

1.2 Carga horária total

24 horas/aula

1.3 Objetivos

Uniformizar o arcabouço conceitual básico de gestão de projetos.

Identificar os diversos aspectos envolvidos no gerenciamento de projetos;

Introduzir os diversos aspectos que devem ser levado em conta no gerenciamento de projetos;

Levar à reflexão quanto às estratégias necessárias para a condução de projetos de sucesso.

Determinar as melhores técnicas e métodos para planejamento, execução e controle de projetos.

Possibilitar a aplicação prática do conteúdo abordado na disciplina.

1.4 Conteúdo programático

Vale a pena lembrar que o conteúdo programático é o detalhamento da ementa. Veja o exemplo a seguir. Compare-o com o exemplo de ementa que lhe foi oferecido.

Importância

do

Introdução ao gerenciamento de projetos

gerenciamento

de

Caracterização de projetos de sucesso

projetos

As restrições do projeto

Evolução da gestão de projetos

Histórico do gerenciamento de projetos

O ambiente de projetos e suas características

Conceituação

de

O que é um projeto?

projetos

Diferença entre projeto e operações

2

 

Programas e projetos.

Definição do papel do gerente de projetos

Característica do gerente de projeto

Perfil do gerente de projetos

 

O

gerente de projetos na organização

Processos

 

do

Processos de iniciação

gerenciamento

de

Processos de planejamento

projetos

Processos de execução e controle

Processos de finalização

Áreas de conhecimento

Conceitos

do

gerenciamento

de

Definições

projetos

Características das áreas de conhecimento

Estrutura

 

A

cultura organizacional para projetos

organizacional

 

para

Tipos de estruturas organizacionais

projetos

Características das estruturas organizacionais

O

papel do gerente de projetos nas estruturas organizacionais

Ciclo

de

vida

de

Ciclo de vida do projeto e ciclo de vida do produto

projetos

Atividades durante o ciclo de vida do projeto

Importância e tipos de escritório de projeto

Definição de escritório de projetos

Tipos de escritórios de projetos

1.5 Metodologia

As aulas buscarão o equilíbrio entre a conceituação teórica e a aplicação prática, por meio de aulas expositivas e participativas, buscando a compartilhamento de informações.

Serão realizados estudos de casos e exercícios para demonstração da aplicação dos conceitos.

Serão realizados trabalhos individuais e em grupo, tanto em sala de aula quanto para confecção fora da sala de aula.

1.6 Critérios de avaliação

A avaliação se dará por meio de:

- Participação nos exercícios e atividades em sala de aula;

3

- Participação nosexercíciospropostospara casa, que serão apresentadosem forma de seminário com a escolha do expositor à critério do professor;

- Prova escrita individual, dos conteúdos da disciplina, realizada no final do módulo.

1.7 Bibliografia recomendada

VERZU, Eric. Gestão de Projetos. MBA Compacto. Campus, 2000.

Um Guia do Corpo de Conhecimentos em Gerenciamento de Projetos. Guia PMbok ®. PMI, 2004.

KERZNERm Harold. Project Management, a System Approach do Planning, Scheduling and Controlling. Van Nostrand Reinhold, 1998.

VARGAS, Ricardo Viana. Gerenciamento de Projetos. Brasport, 2006.

VALERIANO, Dalton. Gerencia em Projetos: Pesquisa, Desenvolvimento e Engenharia. Makron Books, 1998.

HEERKENS, Gary R. Project Management. McGraw-Hill, 2002.

NEWELL, Michael W. Preparing for the Project Management Professional (PMP®) Certification Exam. Amacon, 2002.

1.8 Curriculum resumido do professor

Emanuel Edwan de Lima é Mestre em Gestão Empresarial pela Fundação Getúlio Vargas – EBAPE – RJ, com curso de especialização em gerenciamento de manufatura pela AOTS(The Association for Technical Scholarship) – Japão e Engenheiro Eletrônico pelo Instituto de Tecnologia da Amazônia – UTAM.

Tem mais de 18 anos de experiência em manufatura de produtos eletrônicos, atuando nas áreas de Engenharia, Produção, Materiais e Gestão da Qualidade, Gerenciamento de projetos, Transferência de Tecnologia e Introdução de novos produtos. Examinador do Prêmio Nacional da Qualidade 2003, 2004 e 2005, Avaliador do Prêmio Ibero-Americano de Qualidade 2006, Examinador Líder do Projeto Excelência na Pesquisa Tecnológica da ABIPTI, além de atuação como examinador em prêmios setorias e regionais.

Vicente Fernandes Tino é mestre em Engenharia Elétrica, área de concentração Automação Industrial, pela Universidade Federal do Rio de Janeiro / COPPE, especialista em Gestão da Produção pelo Centro Integrado de Ensino Superior do Amazonas e Engenheiro Eletricista pela Universidade Federal do Amazonas. Sua experiência profissional inclui o cargo de diretor técnico da MAP Cardoso, Chefe da Secretaria de Informática do Tribunal Regional do Trabalho da 11ª Região, Diretor da MAP Motores, Pesquisador na área de eficiência energética e automação da produção da Fundação André Nunes Coelho, docência em cursos de Administração, Sistemas da Informação e Engenharia de Produção, bem como consultoria na área de Automação da Manufatura e Controle em diversas empresas.

4

2 Textoparaestudo

2.1 Introdução

Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. [PMI 2004]. Temporário significa que todos os projetos possuem um início e um final definidos. O final é alcançado quando os objetivos do projeto tiverem sido atingidos, quando se tornar claro que os objetivos do projeto não serão ou não poderão ser atingidos ou quando não existir mais a necessidade do projeto e ele for encerrado. Temporário não significa necessariamente de curta duração; muitos projetos duram vários anos. Em todos os casos, no entanto, a duração de um projeto é finita. Projetos não são esforços contínuos. [PMI 2004] Um projeto cria entregas exclusivas, que podem ser produtos, serviços ou resultados, ou seja, todo produto, serviço ou resultado gerado por um projeto é diferente de outros produtos, serviços ou resultados, mesmo que tenham semelhança ou contenham elementos repetitivos. Os projetos envolvem a realização de algo jamais realizado anteriormente e logo é único.

A elaboração progressiva é uma característica de projetosque integra osconceitosde temporário e exclusivo. Elaboração progressiva significa desenvolver em etapas e continuar por incrementos. Um projeto é progressivo porque à medida que é mais bem compreendido, ele é progressivamente elaborado, ou seja, maior é o detalhamento das características peculiares que o distinguem como único [Dinsmore e Cavalieri 2003; PMI 2003].

Os projetos diferem da operação normal de uma organização. Por meio deles podemos organizar atividadesque não podem ser abordadasdentro doslimitesoperacionaisnormaisda organização. Os projetos são, portanto, freqüentemente utilizados como um meio de atingir o plano estratégico de uma organização, seja a equipe do projeto formada por funcionários da organização ou um prestador de serviços contratado [PMI 2004]

Um projeto para ser executado necessita ser gerenciado. Segundo Koontz e O’Donnel [1980], gerenciar consiste em executar atividadese tarefasque têm como propósito planejar e controlar atividades de outras pessoas para atingir objetivos que não podem ser alcançados caso as pessoas atuem por conta própria, sem o esforço sincronizado dos subordinados. Segundo o PMI, o gerenciamento de projetosé a aplicação de conhecimento, habilidades, ferramentase técnicasàs atividades do projeto a fim de atender aos seus requisitos.

Os projetos estão sujeitos ao que se chama restrição tripla – escopo, tempo e custo – no gerenciamento das necessidades conflitantes do projeto. Ou seja, projeto de alta qualidade entregam o produto, serviço ou resultado dentro do escopo, no prazo determinado e dentro do orçamento. A relação entre esses fatores ocorre de tal forma que se um destes três fatores mudar, pelo menos um dos outros fatores provavelmente será afetado [PMI 2004].

5

2.2 O Gerente de projetos

O gerente de projetos é a pessoa responsável pela realização dos objetivos do projeto. Gerenciar

um projeto inclui:

- Identificação das necessidades

- Estabelecimento de objetivos claros e alcançáveis

- Balanceamento das demandas conflitantes de qualidade, escopo, tempo e custo

- Adaptação das especificações, dos planos e da abordagem às diferentes preocupações e expectativas das diversas partes interessadas.

Os gerentes de projetos precisam não só saber como trabalhar nos ambientes comerciais e de projetos como também necessitam estar bastante familiarizados com o campo de atuação do projeto [Verzuh 2000]. Especificamente osgerentesde projetosprecisam ter qualificaçõesem três áreas diferentes:

- Gestão de projetos – conhecimento de habilidades e técnicas para conduzir o projeto;

- Gestão de negócios – Habilidades necessárias a qualquer gerente, como negociação, finanças, recursos humanos, comunicação.

- Técnica – Conhecimento técnico do produto do projeto, ou do ambiente no qual o mesmo se desenvolve.

Ograu de exigênciade cada uma destasqualificaçõesirávariar de acordo com o tipo de projeto, a equipe envolvida, estrutura organizacional, objetivos e expectativas.

O gerente do projeto possui várias atividades e responsabilidades, como por exemplo: definir e

controlar osobjetivos do projeto; definir e controlar osrequisitos do produto; definir e controlar osriscosdo projeto; definir e avaliar osfatorescríticosde sucesso do projeto; definir e avaliar os pontos fortes e pontos fracos do projeto; definir e controlar o cronograma; verificar o esforço, avaliar o projeto e a equipe com métricas; alocar e gerenciar recursos (orçamento, materiais, pessoas); definir prioridades; coordenar interaçõesentre osenvolvidos no projeto; assegurar que

os prazos e custos estão sendo mantidos dentro do planejado; assegurar que os produtos do projeto atendam aos critérios de qualidade e que estejam de acordo com os padrões estabelecidos; formalizar a aceitação dos artefatos resultantes de cada fase do ciclo de vida do projeto; elaborar relatóriosde avaliação e de acompanhamento da situação do projeto; participar de reuniões de acompanhamento e de revisão do projeto.

O gerente de projetos atualmente ganha destaque dentro das organizações pela evolução e

relevância do gerenciamento de projetos. A profissão de gerenciamento de projetosé emergente

e bastante promissora [Martins 2003; PMI 2004]

Para Kerzner (1992) existem dez importantes habilidades inerentes ao gerente do projeto, definidas por meio de pesquisas e experiências (Tabela 1). Essas pesquisas demonstram que uma performance efetiva de gerenciamento de projetos está diretamente relacionada ao nível de competência em que estashabilidadessejam dominantes. Conforme o autor, é importante que as característicaspessoaisde gerenciamento destaquem ashabilidadesde operação, para formar um estilo de gerenciamento homogêneo.

6

Habilidades

Características

Construção

de

Capacidade de formar e gerenciar equipes de trabalho

Equipes

Liderança

Capacidade de influenciar a equipe e todos os envolvidos no projeto

Resolução de Conflito

Capacidade de identificar e resolver os conflitos no âmbito do projeto

Competência Técnica

Capacidade de coordenar as ações técnicas do projeto

Planejamento

Capacidade de elaborar planos e executá-los.

Organização

Capacidade de estabelecer os critérios de trabalho no âmbito do projeto

Empreendedor

Capacidade de gerar e gerenciar negócios para o projeto.

Administração

Capacidade de desenvolver técnicas de controle, orçamento, etc.

Suporte Gerencial

Capacidade de gerenciar as interfaces com todos os envolvidos no projeto, principalmente com a alta administração.

Alocar Recursos

Capacidade de estabelecer os recursos necessários às várias fases do projeto

Tabela 1 – Habilidades do Gerente de Projetos, segundo Kerzner (1992)

2.3 O ciclo de vida dos projetos

Para facilitar o gerenciamento do projeto ele deve ser dividido em fases que constituem seu ciclo de vida. Ociclo de vida do projeto serve para definir o início e o fim do projeto e definem quaisas atividades que devem ser realizadas em cada fase, e quais os recursos que devem estar envolvidos. Ele descreve o conjunto de processosque devem ser seguidospara que o projeto seja bem gerenciado [Dinsmore e Cavalieri 2003; PMI 2004].

Ásvezeso ciclo de vidado projeto é confundido com o ciclo de vidado produto. Ociclo de vidado produto refere-se às fases que vão desde a identificação da necessidade ou da idéia de se lançar um novo produto até a disposição final deste produto após seu uso. Portanto, o ciclo de vida do produto pode conter vários projetos, como o projeto do produto em si, o projeto de uma nova linha de produção para o produto, a campanha de marketing para lançamento.

Muitasorganizaçõesadotam a prática de determinar um modelo de ciclo vida único para todosos seus projetos, isto facilita o acompanhamento da alta direção em relação aos vários projetos executados simultaneamente.

O ciclo de vida de um projeto define as fases que conectam o inicio do projeto ao seu final.

A transição de uma fase para a outra dentro do ciclo de vida de um projeto em geral envolve e normalmente é definida por alguma forma de transferência técnica ou entrega. As entregas de uma fase geralmente são revisadas, para garantir que estejam completas e exatas, e aprovadas

7

antesque o trabalho seja iniciado na próxima fase. No entanto, não é incomum que uma fase seja iniciada antes da aprovação das entregas da fase anterior, quando os riscos envolvidos são considerados aceitáveis. Essa prática de sobreposição de fases, normalmente feita em seqüência,

é um exemplo da aplicação da técnica de compressão do cronograma denominada paralelismo [PMI 2004].

As descrições das fases do ciclo de vida podem ser muito genéricas ou muito detalhadas, isto vai depender de cada organização. Porém os ciclos de vida compartilham algumas características comuns:

- As fases geralmente são seqüenciais e existe algum documento ou evento que identifica o final de uma dada fase e o inicio da próxima.

- Os custos do projeto e alocação de pessoal são baixos no inicio, atingem o seu valor máximo durante as fases intermediarias e decrescem de forma rápida nas fases finais.

- As incertezas, e consequentemente os riscos do projeto não atingir seus objetivos, são altas no inicio do projeto e à medida que o projeto avança as certezas se tornam mais claras e se pode vislumbrar o término do projeto.

- O custo de mudanças e de correção de erros é maior conforme a continuação do projeto.

- A capacidade de influencia das partes interessadas de influenciarem nas características

finaisdo produto do projeto e no custo do projeto é maior na fase inicial e vai diminuindo

de acordo com o avanço do projeto.

Embora muitos ciclos de vida do projeto possuam nomes de fases semelhantes com entregas semelhantes, poucos ciclos de vida são idênticos. Alguns podem ter quatro ou cinco fases, mas outros podem ter nove ou mais. Áreas de aplicação isoladas reconhecidamente apresentam variaçõessignificativas. Ociclo de vida de desenvolvimento de software de uma organização pode

ter uma única fase de projeto, enquanto outro pode ter fasesdiferentespara projeto arquitetural

e detalhado. Os subprojetos também podem ter ciclos de vida do projeto distintos [PMI 2004].

De forma clássica o ciclo de vida do projeto é definido em cinco fases distintas: iniciação; planejamento; execução; controle e encerramento. A figura 1 ilustra estas fases.

Controle Controle Tempo Tempo Nível de atividade Nível de atividade Iniciação Iniciação Planejamento
Controle
Controle
Tempo
Tempo
Nível de atividade
Nível de atividade
Iniciação
Iniciação
Planejamento
Planejamento
Execução
Execução
Encerramento
Encerramento

Figura 1 – Fases do ciclo de vida do projeto

8

Fase de

É a fase inicial do projeto, quando uma necessidade é identificada e transformada em um problemas a ser resolvido pelo projeto. É onde as estratégias de condução são identificadas e selecionadas. É nesta fase que a missão e o objetivo do projeto são definidos.

iniciação

Fase de

É

onde ocorre o detalhamento do que será realizado no projeto, onde são

planejamento

elaboradososcronogramas, dependênciasentre atividades, alocação de recursos, análise de custos, etc., com o objetivo de se obter o detalhamento suficiente para que o projeto possa ser executado sem imprevisto ou dificuldades. Nesta fase também são elaborados os demais planos do projeto, como planos de comunicação, de gestão de configuração, riscos, qualidade.

Fase de

É

a fase da concretização, onde tudo o que foi planejado anteriormente toma

execução

forma. É nesta fase que aparecem os erros cometidos nas fases anteriores,

também é neste momento que ocorre a maior alocação de recursos, custo e esforço do projeto.

Fase de

Éa fase que ocorre paralelamente desde o planejamento até o encerramento do projeto. Éonde é comparado o que foi planejado com o que está sendo realizado em tremo de custo, prazos, recursos, esforço de forma a se poder tomar ações para a correção dos rumos e proporcionar um realimentação rápida do projeto, evitando que os desvios afetem o sucesso do projeto.

controle

Fase de

É

quando ocorre a entrega dos últimos produtos do projeto, os contratos,

encerramento

documentos e livros são encerrados, onde ocorre a verificação do projeto por terceiros ou internamente. Também nesta fase ocorre o levantamento das lições aprendidas, ou seja, o que deu errado e pode ser melhorado e o que deu certo e deve ser repetido em projetos futuros.

Conforme mostrado na Figura 1 as fases não são estanques, havendo sobreposição entre elas, e também muitasvezesum projeto inicia uma nova fase sem que a anterior tenha sido oficialmente encerrada, desde haja a segurança com relação aos riscos envolvidos no projeto.

2.4 Processos de gerenciamento de projetos

Os processos de gerenciament o de projet os são apresent ados como element os dist int os, com interfaces bem definidas. O Guia PMBOK®descreve a natureza dos processos de gerenciamento de projetos em termos da integração entre os processos, das interações dentro deles e dos objetivos a que atendem. Esses processos são agregados em cinco grupos, definidos como os grupos de processos de gerenciamento de projetos:

- Grupo de processos de iniciação. Define e autoriza o projeto ou uma fase do projeto.

- Grupo de processos de planejamento. Define e refina os objetivos e planeja a ação necessária para alcançar os objetivos e o escopo para os quais o projeto foi realizado.

9

- Grupo de processos de execução. Integra pessoas e outrosrecursos para realizar o plano de gerenciamento do projeto para o projeto.

- Grupo de processos de monitoramento e controle. Mede e monitora regularmente o

progresso para identificar variações em relação ao plano de gerenciamento do projeto, de forma que possam ser tomadas ações corretivas quando necessário para atender aos

objetivos do projeto.

- Grupo de processos de encerramento. Formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.

Os grupos de processos necessários e seus processos constituintes são orientações para a aplicação do conhecimento e dashabilidadesde gerenciamento de projetosadequadosdurante o projeto. Além disso, a aplicação dos processos de gerenciamento de projetos a um projeto é

iterativa e muitosprocessossão repetidos e revisadosdurante o projeto. Ogerente de projetose

a equipe do projeto são responsáveis pela determinação de que processos dos grupos de

processos serão empregados e por quem, além do grau de rigor que será aplicado à execução desses processos para alcançar o objetivo desejado do projeto [PMI 2004]

Um grupo de processosinclui osprocessosde gerenciamento de projetosconstituintesque estão ligados pelas respectivas entradas e saídas, ou seja, o resultado ou o produto de um processo se torna a entrada de outro processo. Os grupos de processos não são fases do projeto. Quando projetos grandes ou complexos podem ser separados em fases ou subprojetos distintos, como estudo de viabilidade, desenvolvimento de conceitos, projeto, elaboração de protótipo, construção, teste, etc., todos os processos do grupo de processos seriam normalmente repetidos para cada fase ou subprojeto [PMI 2004].

A Figura 2 mostra a interação de alto nível entre os grupos de processos.

10

10 Figura 2 – Resumo de alto nível da interação entre os grupos de processos –

Figura 2 – Resumo de alto nível da interação entre os grupos de processos – fonte: PMI 2004

2.4.1 Grupo de processos de iniciação

O Grupo de processos de iniciação é constituído pelos processos que facilitam a autorização formal para iniciar um novo projeto ou uma fase do projeto. Por meio dos processos são desenvolvidas descrições claras dos objetivos do projeto, incluindo as razões pelas quais um projeto específico se constitui na melhor solução alternativa para satisfazer os requisitos.

11

Em projetoscom váriasfases, osprocessosde iniciação são realizadosdurante fasessubseqüentes para validar as premissas e as decisões tomadas anteriormente. O Grupo de processos de iniciação (Figura abaixo) inicia um projeto ou uma fase do projeto e as saídas definem a finalidade do projeto, identificam os objetivos e autorizam o gerente de projetos a iniciar o projeto.

O Grupo de processos de iniciação inclui os seguintes processos de gerenciamento de projetos:

Desenvolver o termo de abertura do projeto

Este processo trata principalmente da autorização do projeto ou, em um projeto com várias fases, de uma fase do projeto. É o processo necessário para documentação das necessidades de negócios e do novo produto, serviço ou outro resultado que deve satisfazer esses requisitos.

Desenvolver a declaração do escopo preliminar do projeto

Este é o processo necessário para produzir uma definição preliminar de alto nível do projeto usando o termo de abertura do projeto junto com outras entradas para os processos de iniciação. Este processo aborda e documenta os requisitos do projeto e da entrega, os requisitos do produto, os limites do projeto, os métodos de aceitação e o controle de alto nível do escopo.

2.4.2 Grupo de processos de planejamento

O objetivo deste grupo de processos é desenvolver o plano de gerenciamento do projeto. Esses

processostambém identificam, definem e amadurecem o escopo do projeto, o custo do projeto e agendam as atividades do projeto que ocorrem dentro dele. À medida que forem descobertas novasinformaçõessobre o projeto, asdependências, osrequisitos, osriscos, asoportunidades, as premissas e as restrições adicionais serão identificados ou resolvidos.

A equipe do projeto deve usar as partes interessadas no planejamento do projeto, pois elas

possuem habilidades e conhecimento que podem ser aproveitados no desenvolvimento do plano de gerenciamento do projeto e em quaisquer planosauxiliares. Aequipe do projeto deve criar um ambiente no qual as partes interessadas possam contribuir de forma adequada.

OGrupo de processosde planejamento facilita o planejamento do projeto entre váriosprocessos. O Grupo de processos de planejamento inclui os seguintes processos de gerenciamento de

projetos:

Desenvolver o plano de gerenciamento do projeto

Este é o processo necessário para definir, preparar, integrar e coordenar todos os planos auxiliares em um plano de gerenciamento do projeto. O plano de gerenciamento do projeto se torna a principal fonte de informações de como o projeto será planejado, executado, monitorado e controlado, e encerrado.

Planejamento do

Este é o processo necessário para criar um plano de gerenciamento do escopo do projeto que documenta como o escopo do projeto será definido, verificado e controlado e como a estrutura analítica do projeto será criada e definida.

escopo

Gerenciamento de projetos

12

Definição do escopo

Este é o processo necessário para desenvolver uma declaração do escopo detalhada do projeto como base para futuras decisões do projeto.

Criar EAP

Este é o processo necessário para subdividir as principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.

Definição da

Este é o processo necessário para identificar asatividadesespecíficasque precisam ser realizadas para produzir as várias entregas do projeto.

atividade

Seqüenciamento de atividades

Este é o processo necessário para identificar e documentar as dependências entre as atividades do cronograma.

Estimativa de

Este é o processo necessário para estimar o tipo e as quantidades de recursos necessários para realizar cada atividade do cronograma.

recursos da

atividade

 

Estimativa de duração da atividade

Este é o processo necessário para estimar o número de períodos de trabalho que serão necessários para terminar atividades do cronograma específicas.

Desenvolvimento do cronograma

Este é o processo necessário para analisar os recursos necessários, restrições do cronograma, durações e seqüências de atividades para criar o cronograma do projeto.

Estimativa de custos

Este é o processo necessário para desenvolver uma aproximação dos custos dos recursos necessários para terminar as atividades do projeto.

Orçamentação

Este é o processo necessário para agregar os custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base dos custos.

Planejamento da

Este é o processo necessário para identificar os padrões de qualidade relevantes para o projeto e determinar como satisfazê-los.

qualidade

Planejamento de recursos humanos

Este é o processo necessário para identificar e documentar funções, responsabilidades e relações hierárquicas do projeto, além de criar o plano de gerenciamento de pessoal.

Planejamento das comunicações

Este é o processo necessário para determinar as necessidades de informação e de comunicação das partes interessadas no projeto.

Planejamento do gerenciamento de riscos

Este é o processo necessário para decidir como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto.

13

Identificação de

Este é o processo necessário para determinar os riscos que podem afetar o projeto e documentar suas características.

riscos

Análise qualitativa de riscos

Este é o processo necessário para priorizar riscos para análise ou ação adicional subseqüente através de avaliação e combinação de sua probabilidade de ocorrência e impacto.

Análise quantitativa de riscos

Este é o processo necessário para analisar numericamente o efeito dos riscos identificados nos objetivos gerais do projeto.

Planejamento de respostas a riscos

Este é o processo necessário para desenvolver opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto.

Planejar compras e aquisições

Este é o processo necessário para determinar o que comprar ou adquirir e quando e como fazer isso.

Planejar

Este é o processo necessário para documentar os requisitos de produtos, serviços e resultados e identificar possíveis fornecedores.

contratações

2.4.3 Grupo de processos de execução

OGrupo de processosde execução é constituído pelosprocessosusadospara terminar o trabalho definido no plano de gerenciamento do projeto a fim de cumprir os requisitos do projeto. Este grupo de processos envolve a coordenação das pessoas e dos recursos, além da integração e da realização das atividades do projeto de acordo com o plano de gerenciamento do projeto. Este grupo de processos também aborda o escopo definido na declaração do escopo do projeto e implementa as mudanças aprovadas.

As variações normais de execução exigirão algum replanejamento. Essas variações podem incluir durações de atividades, produtividade e disponibilidade de recursos, e riscos não esperados. A maior parte do orçamento do projeto será gasta na realização dos processos do Grupo de processos de execução. O Grupo de processos de execução inclui os seguintes processos de gerenciamento de projetos:

Orientar e gerenciar a execução do projeto

Este é o processo necessário para orientar asdiversasinterfacestécnicase organizacionais que existem no projeto para executar o trabalho definido no plano de gerenciamento do projeto.

Realizar a garantia da qualidade

Este é o processo necessário para aplicar as atividades de qualidade planejadas e sistemáticas para garantir que o projeto emprega todos os processos necessários para atender aos requisitos.

Contratar ou mobilizar a equipe do projeto

Este é o processo necessário para obter os recursos humanos necessários para terminar o projeto.

Desenvolver a

Este é o processo necessário para melhorar as competências e a interação

Gerenciamento de projetos

14

equipe do projeto

de membros da equipe para aprimorar o desempenho do projeto.

Distribuição das

Este é o processo necessário para colocar as informações à disposição das partes interessadas no projeto no momento oportuno.

informações

Solicitar respostas de fornecedores

Este é o processo necessário para obter informações, cotações, licitações, ofertas ou propostas.

Selecionar

Este é o processo necessário para revisar ofertas, escolher entre possíveis fornecedores e negociar um contrato por escrito com o fornecedor.

fornecedores

2.4.4 Grupo de processos de monitoramento e controle

OGrupo de processosde monitoramento e controle é constituído pelosprocessosrealizadospara observar a execução do projeto, de forma que possíveis problemas possam ser identificados no momento adequado e que possam ser tomadas ações corretivas, quando necessário, para controlar a execução do projeto.

Esse monitoramento contínuo permite que a equipe do projeto tenha uma visão clara da saúde do projeto e destaca as áreas que exigem atenção adicional. O Grupo de processos de monitoramento e controle, além de monitorar e controlar o trabalho que está sendo realizado dentro de um grupo de processos, também monitora e controla todo o esforço do projeto.

O Grupo de processos de monitoramento e controle inclui os seguintes processos de gerenciamento de projetos:

Monitorar e controlar o trabalho do projeto

Este é o processo necessário para coletar, medir e disseminar informações sobre o desempenho e avaliar as medições e as tendências para efetuar melhorias no processo. Este processo inclui o monitoramento de riscos paragarantir que osriscossejam identificadosno início, que o andamento seja relatado e que planosde risco adequadosestejam sendo executados. Omonitoramento inclui emissão de relatóriosde andamento, medição do progresso e previsão. Os relatórios de desempenho fornecem informações sobre o desempenho do projeto em relação a escopo, cronograma, custo, recursos, qualidade e risco.

Controle integrado de mudanças

Este é o processo necessário para controlar os fatores que criam mudançaspara garantir que essasmudançassejam benéficas, determinar se ocorreu uma mudança e gerenciar as mudanças aprovadas, inclusive o momento em que ocorrem. Esse processo é realizado durante todo o projeto, desde a iniciação até o encerramento do projeto.

Verificação do

Este é o processo necessário para formalizar a aceitação das entregas do projeto terminadas.

escopo

15

Controle do escopo

Este é o processo necessário para controlar asmudançasfeitasno escopo do projeto.

Controle do

Este é o processo necessário para controlar as mudanças feitas no cronograma do projeto.

cronograma

Controle de custos

Oprocesso de influenciar osfatoresque criam asvariaçõese controlar as mudanças no orçamento do projeto.

Realizar o controle da qualidade

Este é o processo necessário para monitorar resultados específicos do projeto a fim de determinar se eles estão de acordo com os padrões relevantes de qualidade e identificar maneiras de eliminar as causas de um desempenho insatisfatório.

Gerenciar a equipe do projeto

Este é o processo necessário para acompanhar o desempenho de membros da equipe, fornecer feedback, resolver problemas e coordenar mudanças para melhorar o desempenho do projeto.

Relatório de

Este é o processo necessário para coletar e distribuir informaçõessobre o desempenho. Isso inclui relatório de andamento, medição do progresso e previsão.

desempenho

Gerenciar as partes interessadas

Este é o processo necessário para gerenciar a comunicação a fim de satisfazer os requisitos das partes interessadas no projeto e resolver problemas com elas.

Monitoramento e controle de riscos

Este é o processo necessário para acompanhar os riscos identificados, monitorar os riscos residuais, identificar novos riscos, executar planos de respostas a riscos e avaliar sua eficiência durante todo o ciclo de vida do projeto.

Administração de

Este é o processo necessário para gerenciar o contrato e a relação entre o comprador e o fornecedor, analisar e documentar o desempenho atual ou passado de um fornecedor e, quando adequado, gerenciar a relação contratual com o comprador externo do projeto.

contrato

2.4.5 Grupo de processos de encerramento

O Grupo de processos de encerramento inclui os processos usados para finalizar formalmente todasasatividadesde um projeto ou de uma fase do projeto, entregar o produto terminado para outrosou encerrar um projeto cancelado. Este grupo de processos, quando terminado, verifica se os processos definidos estão terminados dentro de todos os grupos de processos para encerrar o projeto ou uma fase do projeto, conforme adequado, e estabelece formalmente que o projeto ou uma dada fase está concluída.

16

O Grupo de processos de encerramento inclui os seguintes processos de gerenciamento de projetos:

Encerrar o projeto

Este é o processo necessário para finalizar todas as atividades em todos os gruposde processospara encerrar formalmente o projeto ou uma fase do projeto.

Encerramento do

Este é o processo necessário para terminar e liquidar cada contrato, inclusive a resolução de quaisquer itens em aberto, e encerrar cada contrato aplicável ao projeto ou a uma fase do projeto.

contrato

2.4.6 Interações entre processos

Os grupos de processos de gerenciamento de projetos estão ligados pelos objetivos que produzem. Em geral, as saídas de um processo se tornam entradas para outro processo ou são entregas do projeto. O Grupo de processos de planejamento fornece ao Grupo de processos de execução um plano de gerenciamento do projeto e uma declaração do escopo do projeto documentado, e freqüentemente atualiza o plano de gerenciamento do projeto conforme o projeto se desenvolve.

Além disso, osgruposde processosraramente são eventosdistintosou únicos; elessão atividades sobrepostas que ocorrem em diversos níveis de intensidade durante todo o projeto. A Figura 3 ilustra como os grupos de processos interagem e o nível de sobreposição em momentos diferentes dentro de um projeto. Se o projeto estiver dividido em fases, osgruposde processosirão interagir dentro de uma fase do projeto e também poderão atravessar várias fases do projeto [PMI 2004].

poderão atravessar várias fases do projeto [PMI 2004]. Figura 3 - Interação de grupos de processos

Figura 3 - Interação de grupos de processos em um projeto. Fonte: PMI 2004

17

2.4.7 Mapeamento do processo de gerenciamento de projetos

A Tabela 2, a seguir, reflete o mapeamento dos 44 processos de gerenciamento de projetos nos cinco grupos de processos de gerenciamento de projetos e nas nove áreas de conhecimento em gerenciamento de projetos. Cada um dos processos de gerenciamento de projetos necessário é mostrado no grupo de processos no qual ocorre a maior parte da atividade. Por exemplo, quando um processo que normalmente ocorre durante o planejamento é reexaminado ou atualizado durante a execução, ele ainda é o mesmo processo que foi realizado no processo de planejamento, e não um novo processo adicional.

   

Grupos de processos de gerenciamento de projetos

 

Áreas do

         

conhecimento

Processos de

iniciação

Processos de

planejamento

Processos de

execução

Processos de

monitoramento e

controle

Processos de

encerramento

Gerenciamento

-Desenvolver o termo de abertura do projeto

-Desenvolver o

-Orientar o e gerenciar a execução do projeto

-Monitorar e controlar o trabalho do projeto

-Encerrar o

de integração

plano de

projeto

do projeto

gerenciamento do

-Desenvolver a

projeto

-Controle integrado

declaração do

 

de mudanças

escopo preliminar

do projeto

Gerenciamento do escopo do projeto

 

-Planejamento do

 

-Verificação do

 

escopo

escopo

-Definição do

-Controle do

 

escopo

escopo

-Criar EAP

Gerenciamento de tempo do projeto

 

-Definição de

 

-Controle do

 

atividades

cronograma

-Seqüenciamento

 

de atividades

-Estimativa de

recursos da

atividade

-Estimativa de

duração da

atividade

-Desenvolvimento

do cronograma

Gerenciamento de custos do projeto

 

-Estimativa de

 

-Controle do custo

 

custos

-Orçamentação

Gerenciamento

 

-Planejamento da

-Realizar a garantia da qualidade

-Controle da

 

da qualidade

qualidade

qualidade

do projeto

 

Gerenciamento de projetos

18

Gerenciamento

-Planejamento dos

-Contratar ou mobilizar a equipe do projeto

-Gerenciar a equipe do projeto

 

de recursos

recursos humanos

humanos do

 

projeto

-Desenvolver a equipe do projeto

Gerenciamento

-Planejamento das

-Distribuição das

-Relatório de

 

das

comunicações

informações

desempenho

comunicações

-Gerenciar as

do projeto

partes interessadas

Gerenciamento de riscos do projeto

-Planejamento do

 

-Monitoramento e controle de riscos

 

gerenciamento de

riscos

 

-Identificação de

 

riscos

-Análise qualitativa

de riscos

-Análise

quantitativa de

riscos

-Planejamento de respostas a riscos

Gerenciamento

-Planejar compras e aquisições

-Solicitar respostas

-Administração de

-Encerramento do

de aquisições

de fornecedores

contrato

contrato

do projeto

-Planejar

-Selecionar

contratações

fornecedores

Tabela 2 – Mapeamento entre os processos de gerenciamento de projetos e os grupos de processos de gerenciamento de projetos e as áreas de conhecimento. Fonte: PMI 2004

2.5 Áreas de conhecimento do gerenciamento de projetos

O gerenciamento de projetos de acordo com o Guia PMBOK®3ª. edição [PMI 2004], identifica e descreve asprincipaisáreasde conhecimento e práticas. Cada uma destasáreas(no total de 9) é descrita atravésde processos(no total de 39), e se refere a um aspecto a ser considerado dentro da gerência de projetos. As áreas de conhecimento de gerenciamento são: Gerenciamento de Integração do Projeto, Gerenciamento de Escopo do Projeto, Gerenciamento do Tempo do Projeto, Gerenciamento do Custo do Projeto, Gerenciamento da Qualidade do Projeto, Gerenciamento de Recursos Humanos do Projeto, Gerenciamento de Comunicação do Projeto, Gerenciamento do Risco do Projeto e Gerenciamento de Contratação do Projeto. A não execução de processos de uma área afeta negativamente o projeto, pois o projeto é um esforço integrado. Por exemplo, uma mudança de escopo quase sempre afeta o custo do projeto. Entretanto, ela pode ou não afetar a moral da equipe e a qualidade do produto [PMI 2004].

19

2.5.1 Gerenciamento de integração do projeto

O gerenciamento de integração do projeto inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar os diversos processos e atividades de gerenciamento de projetos dentro dos grupos de processos de gerenciamento de projetos. No contexto do gerenciamento de projetos, a integração inclui características de unificação, consolidação, articulação e açõesintegradorasque são essenciaispara o término do projeto, para atender com sucesso às necessidades do cliente e das partes interessadas e para gerenciar as expectativas. Os processos de gerenciamento de integração do projeto incluem:

Desenvolver o termo de abertura do projeto

- desenvolvimento do termo de abertura do projeto que autoriza formalmente um projeto

Desenvolver a declaração do escopo preliminar do projeto

desenvolvimento da declaração do escopo preliminar do projeto que fornece uma descrição de alto nível do escopo

-

Desenvolver o plano de gerenciamento do projeto

-

documentação dasaçõesnecessáriaspara definir, preparar, integrar e

coordenar todos os planos auxiliares em um plano de gerenciamento do

projeto

Orientar e gerenciar a execução do projeto

-

execução do trabalho definido no plano de gerenciamento do projeto

para atingir os requisitos do projeto definidos na declaração do escopo do projeto

Monitorar e controlar o trabalho do projeto

- monitoramento e controle dos processos necessários para iniciar, planejar, executar e encerrar um projeto para atender aos objetivos de desempenho definidos no plano de gerenciamento do projeto

Controle integrado de mudanças

revisão de todas as solicitações de mudança, aprovação de mudanças e controle de mudanças nas entregas e nos ativos de processos organizacionais

-

Encerrar o projeto.

finalização de todas as atividades entre todos os grupos de processos do projeto para encerrar formalmente o projeto

-

2.5.2 Gerenciamento do escopo do projeto

Ogerenciamento do escopo do projeto inclui osprocessosnecessáriospara garantir que o projeto inclua todo o trabalho necessário, e somente ele, para terminar o projeto com sucesso. O gerenciamento do escopo do projeto trata principalmente da definição e controle do que está e do que não está incluído no projeto. Os processos de gerenciamento do escopo do projeto incluem:

20

Planejamento do

-

criação de um plano de gerenciamento do escopo do projeto que

escopo

documenta como o escopo do projeto será definido, verificado e controlado e como a estrutura analítica do projeto (EAP) será criada e definida

Definição do escopo

desenvolvimento de uma declaração do escopo detalhada do projeto como a base para futuras decisões do projeto

-

Criar EAP

subdivisão dasprincipaisentregasdo projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis

-

Verificação do escopo

- formalização da aceitação das entregas do projeto terminadas

Controle do escopo

- controle das mudanças no escopo do projeto.

2.5.3 Gerenciamento de tempo do projeto

O gerenciamento de tempo do projeto inclui os processos necessários para realizar o término do projeto no prazo. Os processos de gerenciamento de tempo do projeto incluem:

Definição da atividade

identificação das atividades específicas do cronograma que precisam ser realizadas para produzir as várias entregas do projeto

-

Seqüenciamento de atividades

identificação e documentação das dependências entre as atividades do cronograma

-

Estimativa de recursos da atividade

estimativa do tipo e das quantidades de recursos necessários para realizar cada atividade do cronograma

-

Estimativa de duração da atividade

estimativa do número de períodos de trabalho que serão necessários para terminar as atividades individuais do cronograma

-

Desenvolvimento do cronograma

análise dos recursos necessários, restrições do cronograma, durações e seqüências de atividades para criar o cronograma do projeto

-

Controle do

-

controle das mudanças no cronograma do projeto.

cronograma

2.5.4 Gerenciamento de custos do projeto

O gerenciamento de custos do projeto inclui os processos envolvidos em planejamento, estimativa, orçamentação e controle de custos, de modo que seja possível terminar o projeto dentro do orçamento aprovado. Os processos de gerenciamento de custos do projeto incluem:

21

Estimativa de custos

desenvolvimento de uma aproximação dos custos dos recursos necessários para terminar as atividades do projeto

-

Orçamentação

agregação dos custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base dos custos

-

Controle de custos

controle dos fatores que criam as variações de custos e controle das mudanças no orçamento do projeto.

-

2.5.5 Gerenciamento da qualidade do projeto

O gerenciamento da qualidade do projeto inclui os processos e as atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o projeto atenda àsnecessidadesque motivaram sua realização. Ele implementa o sistema de gerenciamento da qualidade atravésda política e dosprocedimentos, com atividadesde melhoria contínua dos processos conduzidas do início ao fim, conforme adequado. Os processos de gerenciamento da qualidade do projeto incluem:

Planejamento da qualidade

identificação dos padrões de qualidade relevantes para o projeto e determinação de como satisfazê-los

-

Realizar a garantia da qualidade

aplicação das atividades de qualidade planejadas e sistemáticas para garantir que o projeto emprega todos os processos necessários para atender aos requisitos.

-

Realizar o controle da qualidade

-

monitoramento de resultados específicos do projeto a fim de

determinar se eles estão de acordo com os padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um desempenho insatisfatório.

2.5.6 Gerenciamento de recursos humanos do projeto

Ogerenciamento de recursoshumanosdo projeto inclui osprocessosque organizam e gerenciam a equipe do projeto. Aequipe do projeto é composta de pessoascom funçõese responsabilidades atribuídaspara o término do projeto. Embora seja comum falar-se de funçõese responsabilidades atribuídas, osmembrosda equipe devem estar envolvidosem grande parte do planejamento e da tomada de decisões do projeto. O envolvimento dos membros da equipe desde o início acrescenta especialização durante o processo de planejamento e fortalece o compromisso com o projeto. O tipo e o número de membros da equipe do projeto muitas vezes podem mudar conforme o projeto se desenvolve. Os membros da equipe do projeto podem ser chamados de pessoal do projeto. Os processos de gerenciamento de recursos humanos do projeto incluem:

22

Planejamento de recursos humanos

-

identificação e documentação de funções, responsabilidades e

relações hierárquicas do projeto, além da criação do plano de

 

gerenciamento de pessoal

Contratar ou mobilizar a equipe do projeto

-

obtenção dos recursos humanos necessários para terminar o projeto

Desenvolver a equipe do projeto

melhoria de competências e interação de membros da equipe para aprimorar o desempenho do projeto

-

Gerenciar a equipe do projeto

-

acompanhamento do desempenho de membros da equipe,

fornecimento de feedback, resolução de problemas e coordenação de

 

mudanças para melhorar o desempenho do projeto.

2.5.7 Gerenciamento das comunicações do projeto

O gerenciamento das comunicações do projeto inclui os processos necessários para garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação final das informações sobre o projeto de forma oportuna e adequada. Os processos de gerenciamento das comunicações do projeto fornecem as ligações críticas entre pessoas e informações que são necessárias para comunicações bem-sucedidas. Os gerentes de projetos podem gastar um tempo excessivo na comunicação com a equipe do projeto, partes interessadas, cliente e patrocinador. Todos os envolvidos no projeto devem entender como as comunicações afetam o projeto como um todo. Os processos de gerenciamento das comunicações do projeto incluem:

Planejamento das comunicações

determinação das necessidades de informações e comunicações das partes interessadas no projeto

-

Distribuição das

informações

colocação das informações necessárias à disposição das partes interessadas no projeto no momento oportuno

-

Relatório de

coleta e distribuição das informações sobre o desempenho, inclusive relatório de andamento, medição do progresso e previsão.

-

desempenho

Gerenciar as partes interessadas

gerenciamento das comunicações para satisfazer os requisitos das partes interessadas no projeto e resolver problemas com elas.

-

2.5.8 Gerenciamento de riscos do projeto

O gerenciamento de riscos do projeto inclui os processos que tratam da realização de identificação, análise, respostas, monitoramento e controle, e planejamento do gerenciamento de riscos em um projeto. Os objetivos do gerenciamento de riscos do projeto são aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto dos eventos adversos nos objetivos do projeto. Os processos de gerenciamento de riscos do projeto incluem:

23

Planejamento do gerenciamento de riscos

decisão de como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto

-

Identificação de riscos

determinação dos riscos que podem afetar o projeto e documentação de suas características

-

Análise qualitativa de riscos

-

priorização dos riscos para análise ou ação adicional subseqüente

através de avaliação e combinação de sua probabilidade de ocorrência

 

e

impacto

Análise quantitativa de riscos

análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto

-

Planejamento de respostas a riscos

-

desenvolvimento de opções e ações para aumentar as oportunidades

e

reduzir as ameaças aos objetivos do projeto

Monitoramento e controle de riscos

-

acompanhamento dos riscos identificados, monitoramento dos riscos

residuais, identificação dos novos riscos, execução de planos de respostas a riscos e avaliação da sua eficácia durante todo o ciclo de vida do projeto.

2.5.9 Gerenciamento de aquisições do projeto

O gerenciamento de aquisições do projeto inclui os processos para comprar ou adquirir os produtos, serviçosou resultadosnecessáriosde fora daequipe do projeto pararealizar o trabalho. Este capítulo apresenta duasperspectivasde aquisição. Aorganização pode ser o comprador ou o fornecedor do produto, serviço ou resultados sob um contrato.

Ogerenciamento de aquisiçõesdo projeto inclui osprocessosde gerenciamento de contratose de controle de mudanças necessários para administrar os contratos ou pedidos de compra emitidos por membros da equipe do projeto autorizados. O gerenciamento de aquisições do projeto também inclui a administração de qualquer contrato emitido por uma organização externa (o comprador) que está adquirindo o projeto da organização executora (o fornecedor) e a administração de obrigaçõescontratuaisestabelecidaspara a equipe do projeto pelo contrato. Os processos de gerenciamento de aquisições do projeto incluem:

Planejar compras e aquisições

-

determinação do que comprar ou adquirir e de quando e como fazer

isso

Planejar contratações

documentação dos requisitos de produtos, serviços e resultados, e identificação de possíveis fornecedores

-

24

Solicitar respostas de fornecedores

obtenção de informações, cotações, preços, ofertas ou propostas, conforme adequado

-

Selecionar

- análise de ofertas, escolha entre possíveis fornecedores e negociação de um contrato por escrito com um fornecedor.

fornecedores

 

-

gerenciamento do contrato e da relação entre o comprador e o

Administração de contrato

fornecedor, análise e documentação do desempenho atual ou passado de um fornecedor a fim de estabelecer ações corretivas necessárias e fornecer uma base para futuras relações com o fornecedor, gerenciamento de mudanças relacionadas ao contrato e, quando adequado, gerenciamento da relação contratual com o comprador externo do projeto

Encerramento do contrato

término e liquidação de cada contrato, inclusive a resolução de quaisquer itens em aberto e o encerramento de cada contrato.

-

2.6 Estrutura organizacional para projetos

A estrutura organizacional determina como os projetos serão desenvolvidos dentro das organizações, estes arranjos são influenciados principalmente pela natureza e pelos negócios da organização, onde temos por um lado organizações que só fazem trabalhos de projetos, como empresas de construção onde seus departamentos dedicam-se a projetos exclusivos, ou organizações que são montadas para a viabilização de um evento específico como o Pan- Americano, que após a realização do mesmo são desfeitas e também existem as empresas de produção contínua, onde impera a operação rotineira. Entretanto, as maiorias das organizações conduzem operações rotineiras e projetos.

As organizações que possuem uma estrutura funcional, ou não baseada em projetos, são principalmente aquelas voltadas para a fabricação de um bem ou para a execução de um determinado serviço. Nestas organizações os projeto são voltados para implementação de um novo produto ou serviço, ou seja, os projetos são visto como atividades de suporte. Nestas organizações, geralmente, o gerente de projeto tem dificuldades para conduzir seus trabalhos, pois os projetos não fazem parte da lista de prioridades da organização.

Nasorganizaçõesbaseadasem projetoso trabalho é totalmente voltado para projetos, e cada um destes projetos tem o seu próprio sistema de controles. A organização atua como um grande organizador de projetos. Nestas organizações os gerentes de projetos têm disponibilidade para atuarem em projetos, pois sua função principal é gerenciar projetos. Todos os funcionários da organização atuam em algum projeto e os gerentes de projetos têm total autoridade inclusive funcional sobre os membros de sua equipe.

Nasestruturasorganizacionaismistasou matriciais, podem existir setoresou departamentoscom a hierarquia totalmente funcional e ao mesmo tempo setores inteiros com estruturas voltadas completamente para projetos. Nestas organizações as pessoas são alocadas nas operações e nos projetos, porém a distribuição de forçasentre o gerente funcional e o gerente do projeto varia de acordo com o tipo de organização, a importância dos projetos, o grau de especialização exigido e a

Gerenciamento de projetos

25

complexidade do projeto. Os gerentes de projetos nestas organizações podem ser membros de times funcionais ou até mesmo gerentes de projetos em tempo integral que respondem para o gerente de gerentes de projetos.

Na tabela 3 podemos ver o grau de influência da estrutura organizacional nos projetos.

 

Estrutura

   

Matricial

 

organizacional

     

Características

 

Funcional

Fraca

Balanceada

Forte

Por projeto

do projeto

Autoridade do gerente de projetos

Pouca ou

 

Baixa a

Moderada a

Alta e quase total

nenhuma

Limitada

moderada

alta

Disponibilidade

de

Pouca ou

 

Baixa a

Moderada a

Alta e quase total

recursos

nenhuma

Limitada

moderada

alta

Quem

controla

o

         

orçamento

projeto

do

Gerente

funcional

Gerente

funcional

Misto

Gerente de

projetos

Gerente de

projetos

Função

do

gerente

         

de projetos

 

Tempo parcial

Tempo parcial

Tempo integral

Tempo integral

Tempo integral

Equipe

         

administrativa

do

gerenciamento

de

Tempo parcial

Tempo parcial

Tempo parcial

Tempo integral

Tempo integral

projetos

Tabela 3 – Influências da estrutura organizacional nos projetos. Fonte: PMI 2004

A organização funcional clássica, mostrada na Figura 4, é uma hierarquia em que cada funcionário possui um superior bem definido. Os funcionários são agrupados por especialidade, como produção, marketing, engenhariae contabilidade, no nível superior. Nasorganizaçõeso escopo do projeto geralmente é restrito aos limites da função. O departamento de engenharia em uma organização funcional fará o seu trabalho do projeto de modo independente dos departamentos de produção ou de marketing. Quando é realizado o desenvolvimento de um novo produto em uma organização puramente funcional, a fase de projeto do produto inclui somente pessoal do departamento de engenharia. Em seguida, quando surgirem questões sobre produção, elas serão passadas para o chefe de departamento no nível hierárquico superior da organização, que irá consultar o chefe do departamento de produção. O chefe do departamento de engenharia então passará a resposta de volta para o gerente funcional de engenharia, no nível hierárquico inferior o que pode causar atrasos, perda de foco e falta de prioridade para o projeto.

26

26 Figura 4 – Organização funcional Na organização por projetos, mostrada na Figura 5, a seguir,

Figura 4 – Organização funcional

Na organização por projetos, mostrada na Figura 5, a seguir, os membros da equipe geralmente são colocados juntos. A maior parte dos recursos da organização está envolvida no trabalho do projeto e os gerentes de projetos possuem grande independência e autoridade. As organizações por projeto em geral possuem unidades organizacionais denominadas departamentos, mas esses gruposse reportam diretamente ao gerente de projetos ou oferecem serviços de suporte para os diversos projetos.

ou oferecem serviços de suporte para os diversos projetos. Figura 5 – Organização projetizada As organizações

Figura 5 – Organização projetizada

As organizações matriciais, conforme mostrado nas Figuras 6, são uma combinação de características das organizações funcional e por projeto. As matrizes fracas mantêm muitas das características de uma organização funcional e a função do gerente de projetos é mais parecida com a de um coordenador ou facilitador que com a de um gerente. De modo semelhante, as matrizes fortes possuem muitas das características da organização por projeto, e podem ter gerentes de projetos em tempo integral com autoridade considerável e pessoal administrativo trabalhando para o projeto em tempo integral. Embora a organização matricial balanceada reconheça a necessidade de um gerente de projetos, ela não fornece ao gerente de projetos autoridade total sobre o projeto e os recursos financeiros do projeto.

27

27 Figura 6 – Organização matricial fraca. Fonte: PMI 2004 Figura 7 – Organização matricial balanceada.

Figura 6 – Organização matricial fraca. Fonte: PMI 2004

Figura 6 – Organização matricial fraca. Fonte: PMI 2004 Figura 7 – Organização matricial balanceada. Fonte:

Figura 7 – Organização matricial balanceada. Fonte: PMI 2004

7 – Organização matricial balanceada. Fonte: PMI 2004 Figura 8 – Organização matricial forte. Fonte: PMI

Figura 8 – Organização matricial forte. Fonte: PMI 2004

A maioria das organizações modernas envolve todas essas estruturas em vários níveis, conforme mostrado na Figura 9 (Organização composta). Por exemplo, até mesmo uma organização fundamentalmente funcional pode criar uma equipe de projeto especial para cuidar de um projeto crítico. Essa equipe pode ter muita das características de uma equipe de projeto em uma

28

organização por projeto. A equipe pode incluir pessoal de diferentes departamentos funcionais trabalhando em tempo integral, pode desenvolver seu próprio conjunto de procedimentos operacionais e pode operar fora da estrutura hierárquica formal padrão.

e pode operar fora da estrutura hierárquica formal padrão. Figura 9 – Organização composta. Fonte: PMI

Figura 9 – Organização composta. Fonte: PMI 2004

2.7 Escritório de projetos

Hoje em dia muitas organizações procuram centralizar e coordenar o gerenciamento de seus vários projetos por meio da utilização de um escritório de projetos (PMO – Project Management Office do Inglês). O PMO também pode ser chamado de “escritório de gerenciamento de programas”, “escritório de programas” ou “quartel general”. A função do PMO é supervisionar o gerenciamento de projetos, programas ou uma combinação de ambos.

Os PMOs podem operar de modo contínuo, desde o fornecimento de funções de apoio ao gerenciamento de projetos na forma de treinamento, software, políticas padronizadas e procedimentos, até o gerenciamento direto real e aresponsabilidade pela realização dosobjetivos do projeto. Um PMO específico pode receber uma autoridade delegada para atuar como parte interessada integral e um importante tomador de decisõesdurante o estágio de iniciação de cada projeto, pode ter autoridade para fazer recomendações ou pode encerrar projetospara manter a consistência dos objetivos de negócios. Além disso, o PMO pode estar envolvido na seleção, no gerenciamento e na realocação, se necessário, do pessoal compartilhado do projeto e, quando possível, do pessoal dedicado do projeto [PMI 2004].

De acordo com a estrutura organizacional o PMO pode ser basicamente de três níveis [Vargas

2002]:

- Projeto autônomo – O escritório de projetos é separado das funções de operação da

organização. Ele é designado para o gerenciamento de um projeto ou programa especifico e tem toda a responsabilidade quanto ao sucesso do projeto.

- Project Support Office – Éo PMO que atua na esfera departamental, apoiando diversos

projetos simultaneamente, fornecendo serviços, ferramentas, controles de prazo, custo e qualidade. Algumas vezes tem a responsabilidade de fornecer os recursos técnicos, metodologia de gerenciamento, compartilhamento do conhecimento, interface organizacional, buscando com que a organização possua um centro de competências em projetos.

29

- Enterprise Project Support Office - PMO que atua corporativamente, buscando tanto o

alinhamento dos projetos com a estratégia corporativas quanto o gerenciamento estratégico dos projetos da organização. Suas funções, além das anteriores, são o planejamento estratégico dos

projetos, a gestão dos projetos corporativos e interdepartamentais, a gestão do conhecimento, além da interface entre as partes interessadas nos projetos.

Um PMO pode existir em qualquer uma das estruturas organizacionais, inclusive nas que apresentam uma organização funcional, sendo que a probabilidade de ocorrência aumenta quanto mais projetizada for a estrutura organizacional.

2.8 Atividades durante o ciclo de vida do projeto

Como forma de ajudar no estabelecimento dasatividadese no fluxo de açõesque devem ocorrer durante o ciclo de vida de um projeto, a seguir são demonstradasasprincipaisatividadesa serem desenvolvidas durante cada fase. Estas atividades, apesar de estarem exemplificadas de forma seqüencial, podem ocorrer mais de uma vez durante o projeto. Como exemplo isto, podemos afirmar que as fases de planejamento, execução e controle são cíclicas até o fim do projeto.

2.8.1 Fase de definição

2.8.1.1 DEFINIÇÃO DO PROBLEMA

Todo projeto tem como origem um problema ou uma oportunidade, ou seja, o projeto pode ser definido como o caminho que leva de um ponto Apara um ponto B, onde este ponto Apode ser a situação atual da empresa, o modo de vida, o local onde se está, e o ponto seria o novo nível de produção, uma nova situação de vida, o local onde se quer chegar. Desta forma a definição consiste em elicitar o problema a ser resolvido pelo projeto. Esta definição é crítica, pois muitas vezes os projetos chegam a uma solução correta para um problema errado. A partir da definição do problema é que se pode chegar às possíveis soluções.

2.8.1.2 CRIAR O TERMO DE ABERTURA DO PROJETO (OU PROJECT CHARTER)

O termo de abertura do projeto é o documento que autoriza formalmente um projeto. O termo de

abertura do projeto concede ao gerente de projetos a autoridade para aplicar os recursos organizacionais nas atividades do projeto. Um gerente de projetos é identificado e designado o

mais cedo possível no projeto. O gerente de projetos sempre deve ser designado antes do início do planejamento e, de preferência, enquanto o termo de abertura do projeto estiver sendo desenvolvido [PMI 2004]. Ele serve como uma linha de base para o trabalho do gerente do projeto. Contém diversasinformaçõessobre o projeto, incluindo asestimativasiniciaisem relação

a custos, prazos, recursos necessários. Estes dados são geralmente preliminares e descritos em alto nível pelos executivos da organização, identificando as necessidades e interesses.

Segundo o PMI (2004), o termo de abertura do projeto, diretamente ou referenciando outros documentos, deve abordar as seguintes informações:

- Requisitos que satisfazem as necessidades, desejos e expectativas do cliente, do patrocinador e de outras partes interessadas;

- Necessidades de negócios, descrição de alto nível do projeto ou requisitos do produto para o qual o projeto é realizado;

30

- Objetivo ou justificativa do projeto;

- Gerente de projetos designado e nível de autoridade atribuída;

- Cronograma de marcos sumarizado;

- Influência das partes interessadas;

- Organizações funcionais e sua participação;

- Premissas organizacionais, ambientais e externas;

- Restrições organizacionais, ambientais e externas;

- Caso de negócios justificando o projeto, incluindo o retorno sobre o investimento;

- Orçamento sumarizado.

2.8.1.3 IDENTIFICAR E SELECIONAR O GERENTE DO PROJETO

Nesta etapa deve ser designado o gerente do projeto, e a partir deste momento ele passa a ser o condutor do projeto e, por conseguinte de todos os processos que ocorrerão no durante o projeto.

2.8.1.4 DEFINIR O OBJETIVO, JUSTIFICATIVA, O PRODUTO E AS ENTREGAS DO PROJETO.

Todo projeto deve ter seu objetivo bem definido, assim como a justificativa para a realização do mesmo. Também devem ser especificados os produtos do projeto e as entregas a serem feitas.

O objetivo – é aquilo que se quer chegar com termino do projeto. É mensurável e controlável.

Normalmente o objetivo é definido por verbos de ação, acompanhados de definições numéricas de tempo, custo e prazos.

A justificativa – é a razão de ser do projeto, ou seja, o porquê a organização está iniciando o

projeto, quais os benefícios que se obterão do projeto, pode também ser denominado de missão do projeto.

Produtose entregas– Oproduto é o resultado obtido na conclusão do projeto, pode ser um bem físico (uma casa em um projeto de construção cível) ou um intangível (um software) porém que pode ser medido e verificado. Asentregasrepresentam osresultadosparciaisobtidosao longo do projeto. Têm a finalidade de avaliar o progresso do projeto. Normalmente são definidos em termos de marcos ou etapas no cronograma.

2.8.1.5 DESENVOLVER A DECLARAÇÃO DO ESCOPO DO PROJETO

A declaração do escopo do projeto é a definição do projeto—o que precisa ser realizado. A

declaração do escopo do projeto aborda e documenta as características e limites do projeto e seus

produtos e serviços associados, além dos métodos de aceitação e controle do escopo. Uma declaração do escopo do projeto inclui:

- Objetivos do produto e do projeto

- Características e requisitos do produto ou serviço

- Critérios de aceitação do produto

- Limites do projeto

- Entregas e requisitos do projeto

Gerenciamento de projetos

31

- Restrições do projeto

- Premissas do projeto

- Organização inicial do projeto

- Riscos iniciais definidos

- Marcos do cronograma

- EAP inicial

- Estimativa aproximada de custos

- Requisitos de gerenciamento de configuração do projeto

- Requisitos de aprovação.

A declaração do escopo preliminar do projeto é desenvolvida a partir das informações fornecidas

pelo iniciador ou pelo patrocinador. A equipe de gerenciamento de projetos refina mais a declaração do escopo preliminar do projeto para obter a declaração do escopo do projeto. O conteúdo da declaração do escopo do projeto irá variar dependendo da área de aplicação e complexidade do projeto e poderá incluir alguns ou todos os componentes identificados acima. Durante as fases subseqüentes de projetos com várias fases, a declaração do escopo preliminar do projeto valida e refina, se necessário, o escopo do projeto definido para essas fases.

2.8.2 Fase de Planejamento

2.8.2.1 DESENVOLVER O PLANO DE GERENCIAMENTO DO PROJETO

O processo Desenvolver o plano de gerenciamento do projeto inclui as ações necessárias para definir, coordenar e integrar todos os planos auxiliares em um plano de gerenciamento do

projeto

Esse processo resulta em um plano de gerenciamento do projeto que é atualizado e

revisado por meio do processo Controle integrado de mudanças.

O

plano de gerenciamento do projeto define como o projeto é executado, monitorado, controlado

e

encerrado. Ele pode ser um documento único ou ser composto de váriosplanos, de acordo com

organização. Oconteúdo do plano de gerenciamento do projeto irá variar dependendo da área de

aplicação e complexidade do projeto. Esse plano inclui:

- Os processos de gerenciamento de projetos selecionados pela equipe de gerenciamento de projetos

- O nível de implementação de cada processo selecionado

- As descrições das ferramentas e técnicas que serão usadas para realizar esses processos

- Como os processos selecionados serão usados para gerenciar o projeto específico, inclusive as dependências e interações entre esses processos e as entradas e saídas essenciais.

- Como o trabalho será executado para realizar os objetivos do projeto

- Como as mudanças serão monitoradas e controladas

- Como o gerenciamento de configuração será realizado

32

- Como a integridade das linhas de base da medição de desempenho será mantida e utilizada

- A necessidade e as técnicas de comunicação entre as partes interessadas

- O ciclo de vida do projeto selecionado e, para projetos com várias fases, as fases associadas do projeto

- As principais revisões de gerenciamento em relação a conteúdo, extensão e tempo para facilitar a abordagem de problemas em aberto e de decisões pendentes.

O plano de gerenciamento do projeto pode ser sumarizado ou detalhado e pode ser constituído

por um ou mais planos auxiliares e outros componentes. Cada um dos planos auxiliares e componentesé detalhado até o nível necessário para o projeto específico. Essesplanos auxiliares incluem, mas não se limitam a:

- Plano de gerenciamento do escopo do projeto

- Plano de gerenciamento do cronograma

- Plano de gerenciamento de custos

- Plano de gerenciamento da qualidade

- Plano de melhorias no processo

- Plano de gerenciamento de pessoal

- Plano de gerenciamento das comunicações

- Plano de gerenciamento de riscos

- Plano de gerenciamento de aquisições.

Esses outros componentes incluem, mas não se limitam a:

- Lista de marcos.

- Calendário de recurso.

- Linha de base do cronograma.

- Linha de base dos custos.

- Linha de base da qualidade.

- Registro de riscos.

2.8.2.2 CRIAR A ESTRUTURA ANALÍTICA DO PROJETO – EAP (WBS – WORK BREAKDOWN STRUCTURE)

A EAP tem como finalidade definir as entregas e os pacotes de trabalho do projeto, com o objetivo

de definir e organizar o escopo do projeto. A EAP subdivide o trabalho do projeto em partes menores e mais facilmente gerenciáveis, em que cada nível descendente da EAPrepresenta uma definição cada vez mais detalhada do trabalho do projeto. A EAP representa o trabalho especificado na declaração do escopo do projeto atual aprovada. Os componentes que compõem

a EAP auxiliam as partes interessadas a visualizar as entregas do projeto. Na figura 10 está exemplifica a decomposição da EAP até o nível de pacote de trabalho.

33

Algumas das características da EAP são:

- permitir a visualização da contribuição de cada pacote de trabalho (work package) para o projeto principal;

- permite o direcionamento das equipes, dos recursos e das responsabilidades;

- determina quais materiais serão necessários para a execução de cada pacote;

- determina o custo fina do projeto a partir do custo de cada pacote ou entrega.

O nível de pacote de trabalho é o nível mais baixo na EAP e é o ponto no qual o custo e o cronograma do trabalho podem ser estimadosde forma confiável. Onível de detalhe dospacotes de trabalho irá variar de acordo com o tamanho e complexidade do projeto.

variar de acordo com o tamanho e complexidade do projeto. Figura 10 – Exemplo de EAP

Figura 10 – Exemplo de EAP com ramos decompostos até o nível de pacote de trabalho

Para a correta elaboração da EAP, Xavier [2003] recomenda seguir os dez mandamentos da EAP:

1- Cobiçarás a EAP do teu próximo – Antes da elaboração da EAP do projeto deve ser verificada a forma de estruturação da EAP de projetos semelhantes, outros projetos da organização, literatura e também devem ser consultados outros profissionais de gerenciamento de projetos.

2- Todos os subprodutos devem estar explicitamente incluídos na EAP, inclusive os necessários ao gerenciamento do projeto – O subproduto que não estiver explicito na EAP não faz parte do escopo do projeto. O conceito de subproduto do projeto também inclui os serviços (treinamento, teste, alinhamento, instalação, etc.). Devemos verificar se os subprodutos necessários para o gerenciamento do projeto foram inclusos na EAP.

34

3- Não usarásnomesem vão – Não devem ser utilizados nomes vagos para os elementos

da EAP, que gerem duvidas semânticas a respeito de qual subproduto está sendo implementado.

Não deve ser indicado o processo de geração dos mesmos, mas sim o resultado desse processo.

4- Guardarása descrição dospacotesde trabalho no dicionário da EAP- Os subprodutos devem ser claramente definidos no dicionário da WBSpara que fique bem explícito o trabalho a ser realizado. O dicionário da EAP é o documento que define ou descreve o trabalho a ser realizado em cada pacote de trabalho da EAP.

5 – Decomporás até um nível de detalhe (pacote de trabalho) que permita o

planejamento e controle do trabalho necessário para sua entrega – O planejamento e controle incluem: escopo, tempo, custo e risco.

6 – Não decomporásem demasia de forma a que oscustosde planejamento e controle

não tragam o benefício correspondente – Planejar e controlar em seu tempo e custo associado a este trabalho. Assim a decomposição deverá ser feita de acordo com a necessidade de cada projeto.

7 – Honrarás o pai - Cada elemento da WBS deve contribuir para o subproduto do

elemento pai ao qual está subordinado. Verifique se os elementos filhos são realmente partes do elemento pai.

8 – Decomporásde forma que ao descer um nível na EAP, a soma dossubprodutosdos

elementosfilhoscorresponde ao subproduto do elemento pai (regra dos100%) – Ao decompor um subproduto nenhuma parte dele deve ser esquecida. Asoma dosprodutoscomponentesdeve

ser equivalente ao subproduto que foi decomposto.

9 – Não decomporás em somente um subproduto - Um elemento da EAP não pode ter

somente um filho, caso isto ocorra, deve ser verificado o esquecimento de algum elemento, cão não haja esquecimento é desnecessária a representação do elemento filho.

10 – Não repetirás o mesmo elemento como componente de mais de um subproduto -

Um elemento filho não pode ter mais de um pai. Podemos ter elementos com o mesmo nome compondo subprodutos diferentes, mas cada um com significado diferente.

Criar o dicionario da EAP

O dicionário da EAP é um documento complementar da EAP. O conteúdo detalhado dos

componentescontidosem uma EAP, inclusive pacotes de trabalho e contas de controle, pode ser

descrito no dicionário da EAP. Para cada componente da EAP, o dicionário da EAP inclui um código

do identificador de conta, uma declaração do trabalho, a organização responsável e uma lista de

marcos do cronograma. A informação adicional sobre um componente da EAP pode incluir informações de contrato, requisitos de qualidade e referências técnicas para facilitar o desempenho do trabalho. A informação adicional sobre uma conta de controle poderia ser um número de cobrança. A informação adicional sobre um pacote de trabalho pode incluir uma lista dasatividadesassociadasdo cronograma, osrecursosnecessáriose uma estimativade custos. São feitas referências cruzadas de cada componente da EAP, conforme adequado, para outros componentes da EAP no dicionário da EAP.

35

2.8.2.3 DEFINIÇÃO DE ATIVIDADES PARA OS ELEMENTOS DA EAP

Após a definição da EAPdevem ser geradas as atividades ou tarefas necessárias para a execução

de

cada pacote de trabalho.

As

atividades são os componentes de trabalho fundamentais de um projeto. Elas são menor nível

da EAP e, em conseqüência, é a menor subdivisão necessária para completar um projeto. São

executasde acordo com a natureza do projeto. Asatividadespodem ocorrer de forma seqüencial

ou

simultaneamente.

Os

principais tipos de atividades são:

- Atividades do cronograma (Activity) – São as atividades relacionadas diretamente ao trabalho

executado dentro do projeto, estasatividadesestão associadasàsestimativasde custo, recursose

duração.

- Marcos (Milestones) – São atividades que representam um evento, o término ou inicio de uma

fase do projeto. Serve também para identificar asentregas. Elasnão possuem duração, recursose custos.

- Atividade-resumo (Summary Activities) – São atividades que agregam um dado grupo de

atividades, também chamadas de subatividades. Servem para fazer a totalização de custos, datas e recursos das atividades a elas pertencentes.

- Atividades de supervisão (Level of Effort) – São atividades utilizadas para alocar os recursos destinados a coordenação ou gerenciamento do projeto. Nestas atividades são relacionados

somente os recursos, e elas não influenciam no planejamento, são atividades cuja duração varia

de acordo com a duração do projeto.

2.8.2.4 DEFINIR A DURAÇÃO DAS ATIVIDADES

A determinação da duração das atividades consiste em estimar a quantidade de esforço

necessário para a execução da mesma. Otempo de duração do projeto será resultado da soma de todas as durações das atividades componentes do mesmo.

A definição de duração da atividade exige que a quantidade de esforço de trabalho necessária para terminar a atividade do cronograma seja estimada, que a quantidade prevista de recursos a ser aplicada para terminar a atividade do cronograma seja estimada e que o número de períodos de trabalho necessário para terminar a atividade do cronograma seja determinado. Todos os dados e premissas que dão suporte à estimativa de duração são documentados para cada estimativa de duração da atividade.

Na definição de duração da atividade deve-se levar em conta o tipo de atividade e qual a influencia do recurso na mesma. Existem atividades denominadas Atividades Orientadas para Recursos (Resource dependent) – são atividade cujo número de recursos alocado influencia na duração da mesma, por exemplo, se um pedreiro constrói uma parede em 10 dias, ao colocarmos dois pedreiros ela provavelmente será construída em 5 dias, ou seja, a duração da mesma dependerá da disponibilidade dos recursos, é utilizada quando os recursos podem trabalhar de forma independente em uma mesma atividade. Outro tipo de atividade é chamada de Atividade de Duração Fixa (Task dependent) – são as atividades que independente do número de recursos alocados ela terão a mesma duração, por exemplo, um treinamento de cinco dias de duração, demorará o mesmo tempo com cinco ou dez alunos em sala de aula. Ou ainda, se uma mulher leva

36

nove meses para dar a luz a uma criança, não adianta colocarmos nove mulheres que a criança não nascerá em um mês. Este tipo de atividade é utilizada quando múltiplos recursos necessitam trabalhar juntos para a execução da mesma.

Estimativa por analogia

Edeterminação da duração de uma atividade por analogia significa a utilização da duração real de uma atividade anterior semelhante de um cronograma como base para a estimativa da duração de uma atividade futura. Ela é freqüentemente usada para estimar a duração do projeto quando existe uma quantidade limitada de informações ou poucos detalhes sobre o projeto. Para a execução deste tipo de estimativa deve ser utilizada a opinião de especialistas, a base histórica de projetosdaorganização e a própriaequipe de projeto, que deve ter a especialização e experiência necessária.

Estimativa paramétrica

A estimativa das durações das atividades pode ser determinada quantitativamente multiplicando a quantidade de trabalho a ser realizado pelo valor da produtividade. Por exemplo, a quantidade de paginasque uma impressora imprime por hora é a produtividade a ser utilizada paradeterminar o tempo de impressão de uma quantidade de publicaçõesou o tempo para se construir um muro é determinado a partir a quantidade de metros que podem ser executados por hora por pedreiro. As quantidades totais de recursos são multiplicadas pelas horas de mão-de-obra por período de trabalho ou pela capacidade de produção por período de trabalho e divididas pelo número de recursos que está sendo aplicado para determinar a duração da atividade em períodos de trabalho.

Análise de PERT (What-if Analysis)

Aanálise de PERT, ou What-if analysis, consiste na estimativa de duração dasatividades, por meio de cenários otimistas, pessimistas e mais prováveis. A duração da atividade se dará por meio do calculo da média ponderada das três estimativas.

Os pesos de cada estimativa podem variar de acordo com o projeto, com o conhecimento do produto do projeto e com a experiência dos estimadores. A relação mais comum é de 1, 4 e 1 para as respectivas estimativas otimista, mais provável e pessimista.

Deste modo,

Onde

Duração

Opt = duração otimista

Est = duração mais provável

Pes = duração pessimista

1

Est = duração mais provável Pes = duração pessimista 1 Opt . 4 Est 1 Pes

Opt.

duração mais provável Pes = duração pessimista 1 Opt . 4 Est 1 Pes 6 A

4

mais provável Pes = duração pessimista 1 Opt . 4 Est 1 Pes 6 A análise

Est

mais provável Pes = duração pessimista 1 Opt . 4 Est 1 Pes 6 A análise

1

mais provável Pes = duração pessimista 1 Opt . 4 Est 1 Pes 6 A análise

Pes

6

A análise PERT permite uma maior precisão nas estimativas de duração das atividades.

37

2.8.2.5 DEFINIR O SEQÜENCIAMENTO DAS ATIVIDADES

O objetivo do seqüenciamento das atividades é identificar e documentar os relacionamentos lógicos entre as atividades para a determinação do cronograma. As atividades do cronograma podem ser seqüenciadas logicamente usando as relações de precedência adequadas, além de antecipações e atrasos intencionalmente provocados, para dar suporte ao desenvolvimento posterior de um cronograma do projeto realista e alcançável.

Tipos de inter-relacionamento

As atividades podem se relacionar de várias formas, as mais usuais são:

- Termino para início (finish to start) – A iniciação da atividade sucessora depende do

término da atividade predecessora. Por exemplo, só podemos erguer as paredes de uma casa após

o término das fundações. Este é o tipo mais comum de relacionamento.

Predecessora
Predecessora

Sucessora

- Término para término (finish to finish) - O término da atividade sucessora depende do

término da atividade predecessora. Por exemplo, pode-se decidir começar o projeto antes da sua aprovação, porém o projeto só poderá terminar após a aprovação do mesmo.

Predecessora Sucessora
Predecessora
Sucessora

- Início para início (start to start) - A iniciação da atividade sucessora depende da iniciação

da atividade predecessora. Por exemplo, em uma pintura de varias salas de um prédio, após a preparação da primeira sala, tanto a equipe de preparação quanto a equipe de pintura podem trabalhar simultaneamente. Este tipo de reposição de tarefas reduz a duração total do projeto.

Predecessora Sucessora
Predecessora
Sucessora

38

- Início para término (start to finish) - O término da atividade sucessora depende da iniciação da atividade predecessora. Por exemplo, quando se esta instalando uma central telefônica nova, somente podemos começar a atividade de desligar a central antiga, após a central nova estiver em pleno funcionamento. Esta relação é pouco usual nos projetos.

Predecessora

Predecessora
Predecessora
Predecessora
Esta relação é pouco usual nos projetos. Predecessora Sucessora Antecipação e atraso entre atividades Diversas

Sucessora

Antecipação e atraso entre atividades

Diversas atividades em um projeto necessitam de um intervalo de tempo para seu inicio após o término da atividade predecessora. Por exemplo, atividades de secagem, cura, envelhecimento, necessitam de um tempo para a execução das atividades restantes. Este atraso é chamado de lag.

Outrasatividadespodem ser antecipadaspara se conseguir ganhar tempo no projeto, permitindo a realização de atividade em paralelo. A técnica de reduzir a duração do projeto por meio de adiantamentos é chamada de fast tracking.

Rede PERT

Um modo de demonstrar graficamente os inter-relacionamentos entre as atividades se dá por meio das redes PERT (Program Evaluation and Review Technique). A utilização da rede PERT permite o entendimento do relacionamento e da interdependência entre as atividades de uma forma simples. Porém pode apresentar dificuldades para projetos muitos grandes e não mostra a relação visual entre as durações das atividades.

Existem duas abordagens diferentes para a representação das atividades de um projeto por meio da rede PERT.

AOA (Activity on Arrow) – neste diagrama asatividadessão representadaspor setasque ligam um estado inicial a um estado final.

39

39 Figura 11 – Rede PERT AOA AON ( Activity on Node ) - Asatividadesneste diagrama

Figura 11 – Rede PERT AOA

AON (Activity on Node) - Asatividadesneste diagrama são representadaspor nósentre assetas. É o digrama mais utilizado, sendo gerado pelos programas de computador destinados ao gerenciamento de projetos.

de computador destinados ao gerenciamento de projetos. Figura 12 – Rede PERT AON Diagrama de Gantt

Figura 12 – Rede PERT AON

Diagrama de Gantt

Odiagrama de Gantt, ou diagrama de barras, é uma forma de representação do cronograma que utiliza barras horizontais em uma escala de tempo. O comprimento das barras está relacionado à duração das atividades e as linhas ligando as barras representam as relações entre as atividades.

40

A utilização do diagrama de Gantt permite um entendimento simples do projeto, dentro de uma escala de tempo bem definida, assim como permite a visualização de atrasos.

definida, assim como permite a visualização de atrasos. Figura 13 – Diagrama de Gantt Alocar recursos

Figura 13 – Diagrama de Gantt

Alocar recursos nas atividades

Apóso seqüenciamento dasatividadesé necessário identificar, selecionar e alocar osrecursosnas

atividades. Recursos são todas as pessoas, materiais de consumo e equipamentos necessários para

a realização da atividade. Os recursos são geralmente divididos em recursos humanos

(engenheiros, pintores, programadores, etc.), recursosmateriais(areia, componenteseletrônicos, papel, material de consumo, etc.) e equipamentos (computadores, escavadeira, fogão, etc.).

Quando da escolha do recurso deve se levar em conta a disponibilidade do mesmo, seu custo, a capacidade e qualidade, entre outros requisitos.

Osrecursosdevem ser alocadosa cada atividade do projeto, esta alocação servirá de base para o cálculo de orçamentos e custos do projeto, assim como esta é a única maneira de gerenciar a disponibilidade e a alocação de cada recurso no projeto.

Conciliação de recursos

Após a alocação dos recursos nas atividades existe a necessidade de verificar se os mesmos não estão com sua carga de trabalho superior ao seu limite máximo, esta verificação é importante para

se ter o cronograma maisrealista possível e também para garantir que osrecursosalocadosterão

capacidade para realizar suas atividades.

Para se resolver o problema de superalocação do recurso pode-se optar pela substituição de mesmo por outro, que possua qualificação equivalente para a realização de trabalho e que esteja

disponível no período de conflito. Uma outra forma é a troca de escala de trabalho ou a alocação

do recurso em regime de horas-extras durante o período de superalocação, porém em qualquer

41

destas duas alternativas deve-se levar em conta a perda de produtividade em decorrência do cansaço, os aspectos legais e os custos adicionais.

A forma mais comum de conciliação é atrasar as atividades segundo critérios de prioridades,

restriçõesou duração com vistasa deixar a utilização dosrecursosem um nível constante durante períodos de tempo do trabalho do projeto. Este nivelamento frequentemente resulta no atraso do

término do projeto.

Não existe a melhor maneira de se conciliar os recursos. Cada situação deve ser estudada e buscada a melhor estratégia para a resolução dos conflitos.

2.8.2.6 CÁLCULO DO CAMINHO CRÍTICO (CPM – CRITICAL PATH METHOD)

O caminho crítico do projeto é constituído pelas atividades mais importantes do projeto. Qualquer

atraso nasatividadesconstituintesdo caminho crítico leva ao atraso no projeto. Uma outra forma de definirmoscaminho crítico é como o caminho com folga de tempo zero. Ocaminho crítico, em uma rede, é o caminho mais longo do projeto.

As atividades que compõem o caminho crítico são chamadas de atividade críticase, caso sofram algum atraso, inevitavelmente levarão a atrasos no projeto. As atividades não críticas, não têm efeito direto sobre a duração do projeto, desde que seu atraso não ultrapasse a folga determinada da mesma.

Data de início mais cedo – IMC (ES - Early Start Date).

Édata de início maiscedo possível na qual uma atividade pode ser iniciada, com base na lógica de rede do cronograma, na data dos dados e nas restrições do cronograma. As datas de início mais cedo podem mudar conforme o projeto se desenvolve e o plano de gerenciamento do projeto é alterado.

Data de início mais tarde – IMT (LS - Late Start Date).

É o momento mais tarde possível no qual uma atividade do cronograma pode ser iniciada com

base na lógica de rede do cronograma, na data de término do projeto e em quaisquer restrições atribuídas às atividades do cronograma sem, entretanto, levar ao atraso na data de término do projeto.

Data de término mais cedo – TMC (EF - Early Finish Date)

Éo momento mais cedo possível no qual uma atividade do cronograma pode ser terminada, com base na lógica de rede do cronograma, na data dos dados e nas restrições do cronograma. As datas de término mais cedo podem mudar conforme o projeto se desenvolve e o plano de gerenciamento do projeto é alterado.

TMC = IMA + D

Onde,

TMC

= Término mais cedo

IMA

= Início mais cedo

D

= Duração estimada

42

Data de término mais tarde – TMT (LF - Late Finish Date).

Éo momento mais tarde possível no qual uma atividade do cronograma pode ser terminada com base na lógica de rede do cronograma, na data de término do projeto e em quaisquer restrições atribuídas às atividades do cronograma sem levar ao atraso na data de término do projeto.

TMT = IMT + D

Onde,

TMT

= Término mais tarde

IMT

= Início mais tarde

D

= Duração estimada

Folga livre – FL (FF - Free Float)

Éo tempo permitido para atraso de uma atividade do cronograma sem atrasar o início mais cedo de qualquer uma das atividades sucessoras do cronograma.

Folga total – FT (TF - Total Float)

Éo atraso total permitido para a data de início de uma atividade do cronograma sem atrasar a data de término do projeto ou violar uma restrição do cronograma, podendo a mesma causar atrasos no início mais cedo das atividades sucessoras do cronograma, desde que estas não estejam no caminho crítico. Écalculada pela diferença entre asdatasde início maiscedo e asdata de término mais cedo, ou seja:

FT = TMT – IMC - D

Onde,

FT

= folga total

TMT

= Término mais tarde

IMC

= Início mais cedo

D

= Duração estimada

Após se determinarem todas as datas do cronograma e as folgas, é então construído o caminho crítico, que são as atividades com folga zero.

43

2.8.2.7 DESENVOLVER O CRONOGRAMA DO PROJETO

Após o estabelecimento dos recursos, durações e relações de interdependência entre as atividades, pode-se então determinar qual a data de início e término das mesmas por meio do estabelecimento do cronograma do projeto.

Este cronograma pode ser apresentado de diversas formas, as mais comuns são:

- Rede PERT

- Tabelas com lista de atividade e seqüências

- Gráficos de Gantt

- Gráfico de marcos

O cronograma pode ser desenvolvido utilizando softwares para gerenciamento de projetos, que

permitem as várias visualizações ou combinação das mesmas.

2.8.2.8 CÁLCULO DE CUSTOS DAS ATIVIDADES E DO PROJETO

A orçamentação é o processo de agregar os custos estimados das atividades individuais ou dos

pacotes de trabalho para a determinação dos custos do projeto. O custo de uma dada atividade será a composição dos custos dos recursos envolvidos na atividade, chamados de custos diretos, com os custos de supervisão, instalações e outros, chamados de custos indiretos.

Ocálculo doscustosdo projeto pode ser feito por meio do uso da EAP. Ocusto de uma fase ou de um pacote de trabalho será asoma doscustosdasatividadesnecessáriaspara esta fase ou pacote de trabalho. O custo total do projeto será então a soma dos custos de suas fases ou pacotes de trabalho, esta estimativa é chamada de estimativa Botton Up.

$ 23500 $ 7600 $ 3000 $ 12900 $ 4400 $ 3200 $ 7500 $
$ 23500
$ 7600
$ 3000
$ 12900
$ 4400
$ 3200
$ 7500
$ 5400
$ 1900
$ 2500
$
3000
$ 4500
$ 1200
$ 700

Figura 14 - Utilização da EAP para cálculo do custo do projeto

44

2.8.3 Fase de Execução e Controle

2.8.3.1 REALIZAR A REUNIÃO DE LANÇAMENTO DO PROJETO

A

reunião de lançamento do projeto pode ser considerada como o marco do fim do planejamento

e

início da execução do projeto. Mesmo o planejamento ocorrendo várias vezes durante o projeto,

este primeiro planejamento serve de linha de base para todo o projeto. Nesta reunião devem estar presentes todos os envolvidos no projeto, os planos são apresentados, os papéis definidos, as estratégias de gerenciamento e de comunicação são explicitadas. Esta reunião pode também ser chamada de reunião de kick off.

2.8.3.2 EXECUÇÃO DOS PACOTES DE TRABALHO

A execução dos pacotes de trabalho se dá por meio da execução das atividades relativas a cada

pacote, é a etapa de materialização do planejamento, todas as falhas que o ocorreram nas fases

anteriores se tornarão evidentes.

A execução do pacote de trabalho é considerada concluída quando ocorre a entrega (delivery). A

entrega é qualquer resultado do trabalho que pode ser verificável, sendo facilmente mensurável, tangível pelosexecutantese tem sua conclusão identificável de maneira simplese direta. Quando todos os pacotes de trabalho são finalizados e suas respectivas entregas são realizadas, então têm- se o fim do projeto.

Execução de atividades de suporte

Juntamente com as atividades relacionadas a execução dos pacotes de trabalho, são necessárias outras atividades para que o projeto possa ser executado e acompanhado com eficácia. Segundo o PMBOK ® [PMI 2004], algumas das atividade de suporte são:

Comunicações – O gerente do projeto passa 90% de seu tempo se comunicando durante o projeto, por isto é importante o cuidado com o fluxo de informações, a distribuição da informação ao público necessitado no momento certo, da maneira correta e pelo meio correto, de acordo com

o plano de comunicações do projeto.

Recursos Humanos – Nesta etapa deve ser dada prioridade ao desenvolvimento da equipe, por meio de treinamentos, capacitações, planosde carreirase recompensas, atividadesadequadasao perfil, estilo de liderança de acordo com a situação encontrada e com a maturidade do subordinado, levando que o sucesso do projeto seja o sucesso das pessoas que compõem o time do projeto.

Qualidade – Nesta etapa do projeto ocorre o que foi planejado no plano de qualidade, havendo atividades de controle de qualidade, com a finalidade de verificar os produtos do projeto e as atividades de garantia da qualidade, com a finalidade de termos a correta execução dos processos.

Suprimentos – Na fase de execução é realizada a maioria das atividades relacionadas ao suprimento, com a ocorrência da seleção de fornecedores, qualificação dos mesmos, execução e controle dos contratos, de acordo com o plano de gerenciamento de suprimentos.

45

2.8.3.3 AVALIAR O DESEMPENHO DO PROJETO

O desempenho do projeto pode ser acompanhado de diversas maneiras, por meio de variância e

tendências, por exemplo. A análise do valor agregado (Earned Value Analysis) é um das melhore técnicas de avaliação. Ela é responsável pelo acompanhamento financeiro de todo o projeto,

A análise do valor agregado tem como foco a relação entre os custos reais consumidos e o

trabalho realizado no projeto, buscando comparar o que foi atingido pelo projeto em relação ao gasto financeiro pra atingir aquele resultado. Esta análise ajuda o gerente a controlar os custos

juntamente com o cronograma do projeto, pois o acompanhamento por só uma desta variáveis deixa o gerente com só metade da visão do projeto.

O controle do desempenho por meio da análise do valor agregado apresenta vários termos, como:

COTA - Custo orçado do trabalho agendado (Budgeted Cost of Work Scheduled - BCWS) – É o orçamento autorizado atribuído ao trabalho agendado que será realizado para a atividade do cronograma ou componente da estrutura analítica do projeto, ou seja, é o custo do orçamento que deveria ter sido gasto até a data em que se está calculando o projeto.

COTR - Custo orçado do trabalho realizado (Budgeted Cost of Work Performed - BCWP) – Éo valor do trabalho terminado expresso em termos do orçamento aprovado atribuído a esse trabalho para uma atividade do cronograma ou componente da estrutura analítica do projeto. É quanto do orçamento deveria ter sido gasto até o momento em que se está calculando o projeto, levando em conto o trabalho que foi realizado até o momento. Também é chamado de Valor Agregado (Earned Value – EV).

CRTR - Custo real do trabalho realizado (Actual Cost of Work Performed - ACWP) – São os custos totais realmente incorridos e registrados na realização do trabalho executado durante um determinado período de tempo para uma atividade do cronograma ou um componente da estrutura analítica do projeto. O custo real às vezes pode representar somente as horas de mão- de-obra direta, somente os custos diretos ou todos os custos, inclusive custos indiretos.

Análise de variação de custo e prazo

VC - Variação de custos (Cost Variance - CV). É a diferença algébrica entre o valor agregado (VA) ou custo previsto (COTR) e o custo real (CRTR). VC = COTR - CRTR. Um valor positivo indica uma condição favorável, ou um custo abaixo do previsto, e um valor negativo indica uma condição desfavorável, ou seja, o projeto está atrasado em termos de custo.

46

COTA CRTR COTR
COTA
CRTR
COTR

Figura 15 – Comportamento do CRTR, COTA e COTR ao longo do tempo para um dado projeto.

VP - Variação de prazos (Schedule Variance - SV). – É a medida do desempenho de prazos em um

projeto. É a diferença algébrica entre o valor agregado (VA), ou COTR e o valor planejado, ou COTA. VP = COTR - COTA. Se VP for positivo o projeto está adiantado em termos de custos, se for negativo o projeto estará atrasado em termos de custos.

Esses dois valores, a VC e o VP, podem ser convert idos em indicadores de eficiência para reflet ir o desempenho de custos e de prazos de qualquer projeto.

IDC - Índice de desempenho de custos (Cost Performance Index - CPI) - Éa medida da eficiência de custosem um projeto. Éa relação entre o valor agregado (VA) e oscustosreais(CR). Um valor de IDCmenor que 1.0 indica um estouro noscustosestimados. Um valor de IDCmaior que 1.0 indica custos estimados não atingidos.

IDC

VA

ou

IDC

COTR

CR

CRTR

IDP - Índice de desempenho de prazos (Schedule Performance Index - SPI) - É a medida da eficiência do cronograma em um projeto. É a relação entre o valor agregado (VA) e o valor planejado (VP). Um IDPmaior ou igual a 1.0 indica uma condição favorável e um valor menor que 1.0 indica uma condição desfavorável. O IDP é usado, em adição ao andamento do cronograma, para prever a data de término e às vezes é usado junto com o IDCpara prever as estimativas de término do projeto.

IDP

VA

ou

IDP

COTR

VP

COTA

47

2.8.3.4 PREVISÕES

A previsão inclui a realização de estimativasou prognósticosde condiçõesfuturasdo projeto com

base nas informações e no conhecimento disponíveis no momento da previsão. As previsões são geradas, atualizadas e refeitas com base nas informações sobre o desempenho do trabalho fornecidas conforme o projeto é executado e desenvolvido. Para as atividades de previsão são utilizados os seguintes conceitos:

PAC (Plan at Completion) – É a duração prevista para o projeto (baseline project finish).

TAC(Time at Completion) – Éa duração projetada para o projeto, é a relação entre a data prevista PAC e o SPI.

TAC

PAC

SPI

DAC (Delay at Completion) – É a diferença entre a duração prevista PAC e a duração projetada TAC para o projeto.

DAC = PAC - TAC

BAC (Budget at Completion) – É o custo orçado para o projeto (baseline budget)

EAC (Estimate at Completion) – É o custo previsto final para o projeto.

VAC (Variation at Completion) – É a diferença entre o custo orçado BAC e o custo final do projeto EAC.

VAC = BAC - EAC

Existem três maneiras de se avaliar os custos finais de um projeto.

A primeira não leva em conta os resultados anteriores, e que a partir deste momento o projeto

retornará ao seu orçamento. Neste caso a previsão de custo final do projeto será:

EAC = Orçamento – COTR + CRTR

A segunda forma considera que a tendência identificada no IDC (CPI) se manterá nas atividades restantes. A fórmula utilizada para esta estimativa é:

EAC

Orçamento

COTR

IDC

utilizada para esta estimativa é: EAC Orçamento COTR IDC CRTR A terceira maneira de avaliação considera

CRTR

A terceira maneira de avaliação considera tanto o índice de desempenho de custos (IDC ou CPI),

quanto o índice de desempenho de prazos (IDP ou SPI), sendo mais sensível a variações, tanto

para mais quanto para menos nestes índices. Esta estimativa é calculada da seguinte forma:

EAC

Orçamento

COTR

é calculada da seguinte forma: EAC Orçamento COTR IDCxIDP CRTR 2.8.3.5 C ONTROLAR AS MUDANÇAS DO

IDCxIDP

CRTR

2.8.3.5 CONTROLAR AS MUDANÇAS DO PROJETO

Todo o controle do projeto giraem torno desta etapa. Oobjetivo destaetapaé garantir que o que foi planejado está sendo executado, e caso ocorram mudanças no plano, o papel do gerente é garantir que as mesmas tragam benefícios para o projeto. As mudanças devem ser controladas para que possa ser mantida a integridade das linhas de base de desempenho do projeto e devem ser coordenadas para garantir o beneficio do todo.

Gerenciamento de projetos

48

A organização necessita ter um processo estabelecido para controle de mudanças, visando

garantir a rastreabilidade da mudança exigida com os pacotes de trabalho em execução ou já entregues, os custos associados à mudança, o nível de exigência da aprovação de acordo com a

criticidade da mudança solicitada.

A cada solicitação de mudança a equipe do planejamento deve ser envolvida para análise de

impacto da mesma e para a decisão de sua viabilidade de execução.

2.8.3.6 VERIFICAR A CONCLUSÃO DE TODOS OS PACOTES DE TRABALHO

Nesta etapa são verificadas se todas as atividades dos pacotes de trabalho foram realizadas e se todas as entregas foram processadas. Caso não haja mais nenhum pacote de trabalho para ser entregue, procede-se à fase de finalização. Caso contrário, realiza-se o próximo pacote de trabalho.

2.8.4 Fase de finalização

2.8.4.1 VALIDAR O RESULTADO DO PROJETO COM O CLIENTE

Apósa entrega de todosospacotesde trabalho, parte-se paraavaliar o resultado do projeto junto

ao cliente para obter o aceite do mesmo.

Esta avaliação busca verificar se o resultado do projeto corresponde com o que foi especificado para o mesmo, fornecendo desta forma um subsídio para o aceite do projeto.

Existem diversasformasde se proceder esta avaliação, podem ser feitasauditoriasde primeira ou de segunda parte, testes de aceitação, acompanhamento de lote piloto ou outras formas concordadas durante a fase de planejamento do projeto.

Como resultado desta fase obtém-se um documento formal declarando o aceite do projeto por parte de cliente, garantindo o fim da responsabilidade do executante sobre o produto do projeto, exceto para os casos de garantia e assistência técnica previsto em contratos.

2.8.4.2 REALIZAR O LEVANTAMENTO DAS LIÇÕES APRENDIDAS

Esta etapa é de grande importância para a equipe do projeto, pois proporciona o aprendizado, neste evento são levantados os problemas detectados quando do aceite do projeto, para que se investiguem ascausase se possam tomar açõescorretivaspara evitar a reincidência do problema em futuros projetos. Podem ser utilizadas folhas de verificação para o levantamento de questões como o que não se sabia antes do projeto e que foi aprendido? O que se faria da mesma forma? O que se faria de forma diferente? Quais as dificuldades superadas? O que deu certo de deve ser repetido? O que deu errado e deve ser evitado?

A lista de perguntas deve ser extensa tanto quanto a cultura de aprendizado está presente na

organização.

2.8.4.3 ENCERRAR CONTRATOS

Antes do encerramento do projeto, todos os contratos celebrados durante o mesmo devem ser encerrados. Este tipo de procedimento evita que pendências do projeto fiquem ativa após o encerramento do mesmo.

49

2.8.4.4 DESMOBILIZAR O TIME DO PROJETO

Deve-se desmobilizar todo o time do projeto antes do encerramento do mesmo, com sua respectiva estrutura de suporte, este passo deve ser dado com relativas atenção, pois não podemos deixar pessoas alocadas no projeto após o término de suas atividades para não onerar os custos desnecessariamente, e também manter o foco do time no projeto quando o mesmo está chegando ao final e o pessoal já está preocupado ou começando a tomar contatoscom o próximo projeto em que vai atuar, este equilíbrio exige muita atenção do gerente de projeto.

Encerrar o projeto

Após todas as atividades de encerramento terem sido concluídas, cabe ao gerente do projeto, tomar providenciaspara que se guarde a memória do projeto, nosrepositóriosda organização e o projeto seja arquivado no rol dos casos de sucesso da organização.

2.9 Conclusões

O gerenciamento não deve ser praticado de maneira ad hoc, mas por meio da aplicação de conhecimentos, habilidades, ferramentas e técnicas, onde se destacam as recomendações do PMI, através do Guia PMBOM ®. Com o uso de metodologias, a implantação da cultura de projetos pode ser realizada paragarantir a aplicação dosprincípiosde gerenciamento de projetosde forma padronizada buscando atender da melhor forma às necessidades das organizações.

Segundo Kerzner [2001] alcançar a excelência de gerenciamento de projetos ou mesmo a maturidade pode não ser possível sem o uso de processos repetitivos que podem ser usados no projeto. Estes processos repetitivos são referidos como a metodologia de gerenciamento de projetos, onde o contínuo uso desta metodologia aumentará drasticamente as chances de sucesso de uma organização.

Gerenciar projetoscom eficiência constitui-se não apenasum grande desafio dosdiasatuais, mas é o fator crítico para o sucesso e para a sobrevivência das empresas. Gerenciar projetos com eficiência requer um esforço de conscientização das empresas em adotar metodologias de gerenciamento de projetos e treinar sua equipe e principalmente os seus gerentes dos projetos. Estas organizações, se possível, devem manter e suportar uma única metodologia para gerenciamento de projetos.

Neste cenário, o gerente do projeto, capacitado, é aquele que tem melhores condições de ver as necessidades do projeto. Ele deve ser um profissional treinado para usar uma metodologia de gerenciamento de projetos e aplicá-la de forma eficiente. Ele deve ser alocado o mais cedo possível ao projeto. Ao gerente devem ser dados autorização formal e apoio visível da alta administração para que ele possa desempenhar bem o seu papel de gestor buscando o sucesso do projeto e a excelência no gerenciamento.

50

3 Material Complementar

3.1 Estudo de caso - ÍMPAR

O projeto Papagaio trata-se do desenvolvimento de um novo rádio de comunicação tática que

será utilizado pelo exército em campo. Trata-se de um rádio tipo manpack. O mesmo possui um mecanismo de criptografia via software e sua mecânica deve suportar grandes impactos. Para o seu desenvolvimento foi contratada a Ímpar Serviços Tecnológicos.

Trimestralmente na ímpar ocorre a reunião de revisão de projetos, onde o Diretor de Engenharia

reúne-se com os gerentes e líderes de grupos de projetos e com os gerentes funcionais para saber

o andamento dos projetos de grande porte, que são considerados estratégicos para a empresa. É

uma oportunidade que os gerentes têm para o compartilhamento do conhecimento, discussão dos

problemas que causam impactos aos projetos, os riscos e as oportunidades. O relatório de situação de projeto é apresentado à alta direção, utilizando um modelo de apresentação corporativo que deve ser seguido por todos.

O Sr. Carlos Costa, Diretor de Engenharia, é conhecido na empresa pela sua objetividade, senso

crítico e por exigir um alto nível de desempenho de seus colaboradores. Esta reunião era muito importante para o André Campos, gerente do projeto Papagaio, poissendo este projeto o foco da reunião, ele sabia que todososolhosestariam voltadospara ele. Para isto, ele havia se preparado muito bem, revisado junto com sua equipe a planilha de acompanhamento de custos e o cronograma. Estava tudo sob controle.

André iniciou sua exposição lembrando da importância do projeto para a empresa e também para

o país, pois ele implicava na absorção de uma nova tecnologia que tornaria o país independente

da tecnologia estrangeira e possibilitaria a exportação desta nova tecnologia. Em seguida, discorreu sobre o andamento do projeto, mostrando que todos os milestones (marcos) tinham sido atingidos na data planejada e que as despesas estavam 4,7 % abaixo do orçado para a fase em que se encontrava. Na seqüência, apresentou os principais eventos e as lições aprendidas nos últimos meses. André encheu o peito e afirmou que provavelmente esta era a primeira vez que um projeto dentro daÍmpar estavaabaixo do orçamento e dentro do cronograma, considerando a execução de mais de 60% do mesmo.

Ográfico de Gant mostrava uma linha de corte na data da reunião com osmarcosalcançadosem azul marinho. Ao término de sua exposição, André concluiu que o projeto não podia estar em

melhor forma, sem problemase totalmente sob controle. OSr. Carlostirou seusóculose esfregou

os olhos com o polegar e indicador, sinal este que revelava quando ele estava satisfeito, e então

afirmou que era um alívio saber que pelo menos um projeto estava sob controle.

A seguir, o Sr. Geraldo Coelho, chefe do departamento de projetos mecânicos, se pronunciou e,

antes de começar a passar seus slides, afirmou que achou bastante estranho o fato de André informar que o projeto estava em dia, pois havia duas semanas que ele estava esperando os desenhos das placas e as especificações para que sua equipe pudesse elaborar o projeto mecânico do rádio. Na verdade, até poucos instantes, antes de entrar na reunião, o seu grupo não havia recebido qualquer desenho do grupo de hardware, responsável pelo desenho das placas e,

segundo Juliana Dias, responsável pela equipe do lay out, estes desenhos somente estariam

51

prontos talvez em três semanas. André lançou um olhar fulminante em direção à Juliana, que foi logo se defendendo, dizendo para André não olhar para ela, mas sim para Mário Jorge, pois até aquele momento o pessoal de Mário não havia liberado o esquema elétrico para que ela conseguisse começar a trabalhar no lay out. Mario Jorge fingiu-se de morto e evitou olhar para André.

Prevendo o que viria pela frente, Juliana afirmou que se Mário entregasse o esquema elétrico nesta semana, seu grupo tentaria priorizar o Papagaio, em detrimento de outros projetos, para conseguir entregar a documentação completa para o pessoal da mecânica em duas semanas.

Geraldo continuou sua exposição mostrando asconseqüênciasadvindasdo atraso, porém afirmou que se o pessoal do Mário e da Juliana conseguisse terminar o esquema elétrico e entregar o layout em duas semanas, seria possível recuperar duas semanas com o pessoal trabalhando em horas extras. A cada slide que Geraldo apresentava André parecia mais enfurecido e encarando seus colaboradores Juliana e Mário, que tentavam ignorar a pressão do chefe.

Carlos: – André, quero saber se estas atividades estão no caminho crítico, pois no mês que vem tenho a reunião com o comando do exército para mostrar a situação do projeto – já fechando o rosto e passando a mão na cabeça, em sinal de começo de explosão. – Evocê Mário, vai conseguir entregar o esquema elétrico nesta semana para que a Juliana faça o lay out e possa enviar para o pessoal da mecânica?

Mário: – Quando chegar a minha vez de expor eu exponho a situação

Carlos: – Então acho melhor você começar a falar!

Geraldo: – Esperem um pouco, por favor! Tem mais um ponto que quero esclarecer, antes de passar a palavra para o Mário.

Juliana: – Eu, de minha parte, vou dar meu jeito para cumprir o prazo. Só não posso fazer milagres!

Geraldo: – É que a gente não pode esquecer que todo este atraso vai acarretar um aumento do orçamento da minha ordem de serviços em torno de $ 20 mil em horário normal e $ 32 mil, se tivermos que utilizar horas-extras.

André: – Como é que é isso?

Geraldo: – Ora camarada, estou com quatro engenheiros alocados para este projeto, que estão há duas semanas só olhando para o vento, e pelo jeito eles vão passar mais quatro semanas só esperando. Faça aí o cálculo a $ 18 a hora

André: – Mas quer dizer que você está querendo me cobrar por pessoas que não estão trabalhando no projeto?

Geraldo: – Claro, quando você me passou a solicitação de serviço, liberei a ordem de serviço da minha equipe a partir da data em que você mostrou no cronograma que necessitaria dosserviços delese lembre-se que você enfatizou naquela ocasião a importância estratégica do projeto. Oquê que eu poderiafazer?Garanto que você não gostaria que eu colocasse o pessoal em outro projeto e ficássemos sem ninguém para executar o seu. Não tenho gente sobrando e nem folga no meu orçamento para ficar segurando o pessoal indefinidamente. Meu irmão! Você solicitou, eu disponibilizei o pessoal para o projeto, portanto, o projeto paga por eles. Eu não tenho culpa se vocês não liberam os desenhos ou qualquer coisa para que o meu pessoal possa trabalhar?

52

Carlos: – André, pelo que entendi estes gastos não foram contabilizados. Então o seu projeto não anda tão bem financeiramente

Mário: – Bom pessoal da Juliana

André: – Mas como? Se na reunião de duas semanas atrás vocês reportaram que tanto o esquema elétrico quanto o lay out estavam em dia? Tenho aqui comigo os relatórios e agora tenho uma surpresa destas!

Juliana: – É verdade, mas você vira uma fera e faz um escândalo cada vez que a gente ultrapassa uma data-alvo, exige relatórios escritos, planos de contingência, reuniões e reuniões

Mário: – Sem falar no palavreado pouco educado. Mas não lhe informamos porque estávamos certos que conseguiríamos eliminar o ruído provocado pelo circuito de RF. Na simulação funcionou bem! Se tivesse funcionado na prática, estaríamos “barrigando” só uma semana ou duas.

Juliana: – E o nosso pessoal poderia tentar recuperar este atraso e liberar para a mecânica.

André: – Você está me dizendo que ainda não terminou a implementação do circuito de RF?

Mário: – É, eu sei. Pensava que a solução deste problema fosse trivial e, o mais importante, que fosse trabalhar no esquema e no circuito de controle.

André: – Caramba! Você está me dizendo que aquele ruído ainda persiste? Você me disse que o problema havia sido resolvido há mais de um mês?

Mário: – Eu não imaginava que este problema fosse tão cabeludo, nós estávamos mais preocupados em liberar o esquema elétrico, e também que esse ruído fosse por causa do micro controlador que estávamos utilizando e da protoboard, mas mesmo com o novo circuito micro controlador o problema ainda persiste.

André: – Mas você garantiu que com a adição deste novo circuito o problema seria resolvido

Mário: – É, na modelagem e na simulação a solução parecia perfeita.

André: – Pô! Quer dizer que aumentamos o custo da B.O.M. em $ 5 e não resolvemos o problema?

Carlos: – André, ninguém me informou que o produto ficaria mais caro. Nós sabemos que o cliente limitou o custo da B.O.M. e não aceita nenhum aumento!

André: – É que eu não queria deixá-lo preocupado, pensava que depois dos testes de protótipo poderíamos trabalhar na redução dos custos do produto.

Geraldo: – Ei! Não podemos esquecer que qualquer alteração após o teste do protótipo pode acarretar na alteração da mecânica e consequentemente

Juliana: – Eu sei, mas estamos trabalhando para que as alterações elétricas não acarretem em alterações nas dimensões das placas.

Mário: – Mas não podemos afirmar isto até resolvermos o problema do circuito de RF.

André: – Estou vendo que tenho muitos pontos a serem fechados

Juliana: – Se você pagar horas extras creio que o nosso pessoal consiga reduzir o tempo de confecção do layout.

antes de mais nada, realmente eu ainda não passei o esquema elétrico para o

53

Mário: – Só quero lembrar, antes que me peguem para Cristo, o que eu disse quando estávamos na fase de estimativas. Que necessitaríamosde maistempo, pelo menosmaisdoismesesalém do que você tinha estimado. Trata-se de uma nova tecnologia que não dominávamose que ascoisas poderiam dar errado.

André: – Lá vem você! Sempre é a mesma coisa: necessita do dobro do tempo e de mais pessoas. Se eu fosse atender cada um de vocês, o Papagaio só falaria depois que meu filho de dois anos entrasse no exército!

Carlos: – Chega! Pelo que estou vendo este Papagaio está mais para periquito e não vai falar é nunca! Pessoal, agora é hora de vocêsse juntarem e acharem a solução. Quero uma prestação de contas detalhada, juntamente com o relato da situação real do projeto e um plano para ver se salvamos este paciente. Espero ver tudo isto daqui a uma semana, quando continuaremos esta reunião.

Após a saída de Carlos da sala, os demais foram saindo em silêncio. André foi o último a sair, caminhou até sua sala tentando entender onde foi que ele errou. Como é que aquele que seria o seu melhor dia virou um pesadelo.

QUESTÕES PARA DEBATE

1)

Qual a atitude de André em relação aos seus colaboradores Mário e Juliana?

2)

André tem culpa pelas falhas de Mário?

3)

Geraldo está agindo corretamente ao cobrar de André um serviço que não foi executado?

4)

O que você faria se fosse André?

5)

O que você faria se fosse o Sr. Carlos Costa?

54

3.2 Estudo de Caso: Fox Meyer

Adaptado de: The FoxMeyer Drugs' Bankruptcy: Was it a Failure of ERP?

Judy E. Scott, The University of Texas at Austin, Judy.Scott@bus.utexas.edu

Sumário

Este é um estudo de caso interpretativo da implantação do ERP das FoxMeyer Drugs é baseado em estruturasempíricase nosmodelosde riscosem projetosde software e de escalasde projetos. As implicações do estudo oferecem sugestões em como evitar a falha na implantação de ERPs.

Introdução

A FoxMeyer Drugs era uma companhia de $5 bilhões e o quarto maior distribuidor de produtos

farmacêuticos dos Estados Unidos antes do fiasco. Com o objetivo de usar a tecnologia para aumentar a eficiência, foi iniciado em 1993 o projeto Delta III. A FoxMeyer conduziu uma pesquisa de mercado e avaliação de produtose decidiu pela compra do SAPR/3 em dezembro desse ano. A FoxMeyer também decidiu pela compra da solução de automatização de armazéns de um fabricante chamado Pinnacle, e escolheu a Andersen Consulting para a integração e implementação dos dois sistemas. A execução do projeto Delta III ocorreu durante o período de 1994 e 1995.

De acordo com Christopher Cole, CIOda Pinnacle, o fracasso da FoxMeyer “não foi uma falha da automatização. Não foi uma falha do software comercial por si mesmo. Foi uma falha da gerenciamento” (Jesitus, 1997). Talveza gerência tivesse expectativasirreais. A gerência esperava que a tecnologia fosse “uma bala de prata”?(Markuse Benjamin 1997a, 1997b). Na realidade, era

o oposto. A FoxMeyer foi à falência em 1996, e iniciou em 1998 um processo responsabilizando a SAP, vendedor de ERP, assim como a Andersen Consulting, seu integrador do SAP, pela sua falência e exigindo $500 milhões de cada (Caldwell 1998, Stein 1998).

Riscos do projeto

O projeto Delta III da FoxMeyer Drugs era um projeto de alto risco por diversas razões. Para

análise dos risco vamos utilizar a estrutura desenvolvida para identificar riscos de projetos de software (Keil, Cule, Lyytinenand Schmidt 1998), esta estrutura classifica os riscos do projeto da FoxMeyer em (1) patrocínio do cliente, (2) escopo e requisitos, (3) execução e (4) ambiente.

Primeiramente, o patrocínio do cliente baseia-se no compromisso da alta gerência e dosusuários. Na FoxMeyer, embora o compromisso da gerência sênior fosse elevado, os depoimentos colhidos revelaram que alguns usuários não estavam comprometidos. De fato, havia um problema de moral entre os empregados dos armazéns. Isto não era surpresa, uma vez que a automatização dos armazéns, feita pela Pinnacle, integrada com a implementação do SAPR/3 representava uma ameaça para seus empregos. Com o fechamento de três armazéns, o início da operação do primeiro armazém automatizado foi um desastre. Os trabalhadores desmotivados não prestavam atenção ao controle do inventário e as ordens não eram preenchidas corretamente. E, para piorar, oserrosocorreram enquanto o novo sistema enfrentava problemascom o volume de transações. Nesta operação perdeu-se em torno de $34 milhões de inventário(Jesitus 1997).

55

Em segundo lugar , o escopo do projeto representava um risco. A FoxMeyer era o que chamamos de “early adopter” do SAPR/3, ou seja, ela era um dos clientes que utilizam os produtos na sua fase prematura. Depois que o projeto começou, a FoxMeyer assinou um contrato grande para fornecer para o University Health System Consortium (UHC), um volume de negóciosem torno de $1 bilhão ao ano. Este contrato exacerbou a necessidade para um volume sem precedentes de transações no R/3. Embora, antes do contrato, os testes indicavam que o R/3, rodando em uma plataforma HP9000, teria capacidade de lidar com altos volumes de transações, em 1994 o R/3 conseguia processar somente 10.000 ordens de clientes por noite, comparado aos 420,000 do sistema original do mainframe da FoxMeyer (Jesitus 1997).

Em terceiro lugar, a execução do projeto era um problema devido à falta de pessoal com conhecimento e habilidade. A FoxMeyer não tinha as competências internas necessárias e estava confiando à Andersen Consulting a implementação do R/3 e a integração do ERPcom um sistema de automatização de armazéns da Pinnacle. Embora durante a execução do projeto houvesse cerca de 50 consultores na FoxMeyer, muitos deles eram inexperientes e o turnover era elevado (Computergram International 1998).

Finalmente, no quadrante do ambiente da estrutura do risco, pode ser encontrado o excesso de problemas que a gerência do projeto tinha pouco ou nenhum controle (Keil, Cule, Lyytinenand Schmidt 1998). Embora a FoxMeyer tivesse percebido que o projeto estava com problemas, sua dependência dos consultores e do fornecedor impedia que ela conseguisse enxergar como poderia retomar o controle do mesmo. Uma vezque a FoxMeyer estava competindo em termosde preço, ela necessitava de um volume elevado de transações para ser rentável. Contudo, com o contrato do UHC“o foco do projeto mudou dramàticamente”, contribuindo para o aumento dos custosdo mesmo (eventualmente, um estouro de $100 milhões), baixando as margens já estreitas da FoxMeyer e corroendo sua rentabilidade.

Dado o elevado nível de risco, por que a FoxMeyer iniciou o projeto? Além disso, por que deixaram o projeto ganhar proporções de modo a contribuir com a bancarrota da FoxMeyer?

Escalabilidade do projeto

Os sistemas do mainframe da FoxMeyer estavam tornando-se inadequados para seu crescente volume de negócios. Além disso, seu sistema Unisys estava defasado e necessitava ser substituído.

O projeto Delta foi previsto como uma solução cliente/servidor R/3 integrada com armazéns

automatizados, com a finalidade de acomodar o crescimento futuro da companhia. Um modelo de fatores que promovem a escalabilidade de um projeto sugere que: (1) fatores de projeto, (2) fatores psicológicos, (3) fatores sociais e (4) fatores organizacionais contribuíram ao mesmo tempo

para a continuação do projeto apesar de toda a sinalização negativa disponível (Keil 1995).

A implementação parecia estar com problemas desde seu começo. Apesar dos avisos da Woltz

Consulting, durante os estágios iniciais do projeto, de que um planejamento para que a execução

inteira estivesse terminada em 18 meses era totalmente irreal, o projeto Delta da FoxMeyer foi adiante (Jesitus 1997).

Fatores do projeto

O aumento das dimensões do projeto é mais provável quando há uma expectativa que a

continuação dos investimentos poderia produzir um maior retorno. A FoxMeyer esperava que com o projeto Delta conseguisse economizar até $40 milhões por ano. A Andersen Consulting e a SAP também estavam motivados a continuar o projeto. De acordo com a FoxMeyer, a Andersen

56

utilizou estagiários (Caldwell 1998) e usou o projeto Delta como um “campo de treinamentos” para os “consultores novatos " (Computergram International 1998). Similarmente, a FoxMeyer reivindicou que a SAP a tratou como a “sua própria cobaia de pesquisa e desenvolvimento " (Financial Times 1998). Além disso, os recuos do projeto pareciam ser temporários. Por exemplo, existiam algumas métricas que mostravam que os sistemas poderiam executar o volume de transações requerido pela FoxMeyer.

Fatores psicológicos

A Andersen e a SAP tinham um histórico de sucesso que os incentivava a continuar o projeto. A

Andersen afirmou “nósentregamosum sistema eficaz, da mesma forma que fazemospara outros milhares de clientes” (Computergram International 1998). O CIO da FoxMeyer, Robert Brown, tinha havia colocado um elevado grau de responsabilidade pessoal no projeto ao afirmar que, “nós estamos apostando nossa companhia neste projeto.” (Cafasso 1994). Além disso, ele expressou

toda sua carga emocional no projeto quando enfatizou a respeito de que um sistema integrado computadorizado de $65 milhões, construído em SAP R/ 3 melhoraria de forma radical as operações críticas da companhia. Entretanto, a FoxMeyer colocou uma carga maior do que ela poderia suportar, uma vez que faltavam usuários disponíveis na equipe de funcionários com a sofisticação necessária para assegurar uma instalação rápida. Também, a decisão de utilizar dois fornecedores diferentes para dois dos sistemas mais importantes do negócio da companhia era “um erro em se tratando de processamento de informações” (Keil 1995). Isto adicionou ainda mais complexidade a uma situação já desafiadora (Jesitus 1997).

Fatores sociais

Éprovável que a Andersen Consulting e a SAPtivessem necessidade de justificar externamente o projeto Delta. Provavelmente não consideraram reduzir a escala do projeto, uma vez que o abandono do mesmo não seria uma boa publicidade. Além disso, suas“normaspara consistência” (Keil 1995) eram tais que a perseverança em lidar com problemas de projetos lhes traria a compensação necessária.

Fatores Organizacionais

Tanto o CEO quanto o CIO da FoxMeyer eram patrocinadores fortes do projeto. Entretanto em fevereiro de 1996, Thomas Anderson, o presidente e CEO da FoxMeyer Health (e executivo responsável pelos projetos de integração da companhia e automatização dos armazéns) foi solicitado a renunciar devido ao atraso do novo armazém e àsfalhasem concretizar aseconomias previstas pelo sistema SAP. Uma mudança na gerência é frequentemente motivo para a redução da escala do projeto (Montealegre e Keil 1998). Mas já era muito tarde para a FoxMeyer.

Os relatórios pareciam indicar que a FoxMeyer afrouxou os controles gerenciais, demonstrado pelo fato que a gerência não controlou o escopo do projeto Delta. Por exemplo, originalmente, a FoxMeyer esperava que a Andersen projetasse um sistema que poderia “despachar em um número X de horas”. Embora a Andersen tivesse projetado um sistema capaz de fazer isto, posteriormente a FoxMeyer queria estar pronta para despachar entre um terço e a metade deste tempo (Jesitus 1997). Também, com o contrato do UHC, a capacidade de processamento do sistema SAPteve que ser aumentada substancialmente. Além disso, a FoxMeyer não teve políticas

e procedimentos adequados de gerenciamento de mudanças. Por exemplo, seus problemas

trabalhistas explodiram quando os trabalhadores começaram a deixar e trabalho em massa nos seus três armazéns de Ohio, que foram programados para serem substituídos pelo Centro

57

Automatizado de Controle de Washington. Por causa “de um problema de debilidade moral entre os trabalhadores que estavam saindo, muitas das mercadorias foram despejadas nos caminhões e chegaram ao Centro de Controle de Washington com suas embalagens danificadas ou abertas ou de outra maneira inadequadas para serem utilizadas como um produto novo, [tendo por resultado] uma redução enorme de inventário” (Jesitus 1997).

Questões para discussão

- Quais as principais falhas no gerenciamento do projeto Delta III?

- Neste caso temos o exemplo dos riscos envolvidos na adoção de novas tecnologias, como a FoxMeyer poderia minimizar estes riscos?

- Quais seriam as melhores estratégias para cada tipo de risco analisado pela estrutura adotada (patrocínio do cliente; escopo e requisitos; execução e ambiente)?

- Como poderiam ser atacados os fatores que levaram ao aumento da escala do projeto?

Referências

Cafasso, R. "Success strains SAP support", Computerworld, 28(36), September 5, 1994.

Caldwell B. "Andersen Sued On R/3", InformationWeek, July 6, 1998.

Computergram International "FoxMeyer Plus Two Sue Andersen for SAP Snafus", Computergram

International, July 20, 1998.

Financial Times "SAP in $500m US lawsuit", Financial Times, Surveys, September 2, 1998, 2.

Jesitus, J. "Broken Promises?; FoxMeyer 's Project was a Disaster. Was the Company Too Aggressive or was

it Misled?", Industry Week, November 3, 1997, 31-37.

Keil, M., Cule, P.E., Lyytinen, K., and Schmidt, R.C. "A framework for identifying software project risks",

Communications of the ACM, 41(11), November 1998, 76-83.

Keil, M. "Pulling the plug: Software project management and the problem of project escalation", MIS

Quarterly, 19(4), December 1995, 421-447.

Markus, M. L. and Benjamin, R. I. "The magic bullet theory in IT-enabled transformation", Sloan Management Review, 38(2), Winter 1997a, 55-68.

Markus, M. L. and Benjamin, R. I. " Are you gambling on a magic bullet?", Computerworld, 31(42), October 20 1997b, C1-C11.

Montealegre, R. and Keil, M. "Denver International Airport'sAutomated Baggage Handlingsystem:

A Case

Study of De-escalation of Commitment", Academy of Management Proceedings, August 1998.

Stein T. "SAP Sued Over R/3", InformationWeek, August 31, 1998.

58

3.3 Estudo de Caso - Globalstar: conectando todo mundo, de todo lugar

Um anúncio surpreendente

No dia 25 de agosto de 1999, os leitores do Wall Street Journal e de outros jornais importantes ficaram surpresosao se deparar com um anúncio que traziauma cartade John Richardson, o novo diretor-presidente da Iridium. A Iridium era um sistema de telefonia global, baseado em satélite e sem fio que a empresa tinha lançado há apenas nove meses. Na carta, Richardson dizia:

Pioneiros, entretanto, deparam-se com desafiosúnicos, e cometemosalgunserrosno lançamento de nosso serviço. Reconhecemos nossos erros e estamos trabalhando diligentemente para corrigi- los. Nossa principal meta é oferecer um serviço de classe mundial para nossos clientes.

Para alcançar nossos objetivos, devemos colocar nossa situação financeira em ordem. A Iridium LLCrecentemente entrou com pedido de reorganização, Capítulo 11, num esforço para concluir

uma reestruturação financeira em um processo ordenado e supervisionado (

para nossosclientes, investidorese parceiros do mundo todo que a Iridium continuará a oferecer seu serviço de telecomunicações global pioneiro e de alta qualidade sem interrupção. Ainda

estamos na ativa, normalmente.

Saindo de órbita

Os desenvolvedores de telecomunicações por muito tempo sonharam com uma rede de satélites em órbita ao redor da Terra que permitisse que uma pessoa fizesse ligações telefônicas de qualquer lugar do mundo. A Iridium e seus financiadores — como a Motorola e a Kyocera, uma fabricante de componentes japonesa — demoraram mais de 12 anos e investiram mais de cinco bilhõesde dólarespara fazer desse sonho uma realidade. Como uma empresa tão festejada pôde falir tão drasticamente, de maneira tão rápida?

Quero deixar claro

)

Os engenheiros da Iridium desenvolveram um sistema que contava com 66 satélites para unir uma rede de telefonia celular em terra que combinava 200 serviços oferecidos em 90 países. A empresa organizou seus membros em 15 gateways (pontos de contato) regionais, que eram responsáveispor promover osserviçosda Iridium nessasáreas. Os gatewayseram ossistemasde transferência em terra que recebiam e direcionavam as chamadas de e para os satélites.

Os financiadores da Iridium achavam que havia um grande mercado potencial para esse serviço de telefonia. Na verdade, um estudo da Merrill Lynch previu que em 2007 32 milhões de assinantes em todo o mundo estariam pagando quase 32 bilhõesde dólarespor ano pelo serviço de telefonia via satélite. O estudo apontou que 65 por cento dos lares no mundo não tinham telefone. Mostrou também que o serviço de telefonia celular não tinha penetrado em muitospaísesdesenvolvidose que mesmo nos Estados Unidos e na Europa grandes áreas não tinham cobertura para celular.

A agência de propaganda Ammirati Puris Lintas (APL) trabalhou com a Iridium no desenvolvimento da estratégia de marketing. A APL deslocou oito gerentes de seus escritórios em 77 países para trabalhar com os gerentes da Iridium. A equipe da APL apresentou uma análise de 600 viajantes globais, pessoas importantes que percorriam o mundo fazendo negócios. A pesquisa da APL apontou que essas pessoas se preocupavam em estar fora de contato quando viajavam para lugares distantes. Temiam perder os acontecimentos na empresa ou de estar fora de contato e,

59

conseqüentemente, fora do controle. Eles se preocupavam também em negligenciar a família. Essas pessoas tinham altos cargos e no mínimo 35 anos, ou eram pessoas que tinham ocupações diferentes, como exploradores de petróleo ou produtores de filmes.

A Iridium já tinha o produto que acalmava esses medos dos executivos e ia ao encontro de seu

desejo por status. Entretanto, o único modelo de telefone que a empresa desenvolveu se parecia com um tijolo e tinha uma antena parecida com uma bisnaga. Junto com o telefone, o executivo teria que carregar uma maleta recheada de uma desconcertante quantidade de acessórios e adaptadores. Além disso, para utilizar o telefone, o executivo teria que ter certeza de que a antena estava voltada para a direção certa, em direção ao satélite, e de que não havia nada bloqueando o sinal. Assim, o cliente não poderia utilizar o telefone dentro de prédios ou carros. A Iridium oferecia um serviço de roaming, de modo que os clientes tinham que acessar as redes de celular ao redor do mundo e pagar pelo serviço. Os clientes tinham apenas um número de telefone para todos esses serviços ao redor do mundo e recebiam apenas uma conta.

A Iridium estava preocupada em rever seu investimento. Além disso, seguiu uma política de

determinação de preços para o mercado de elite, cobrando mais de três mil dólares por um aparelho e maisde sete dólarespor minuto de ligação. Adeterminação de preçostambém ajudou

a posicionar o telefone como um símbolo de status e atraiu pessoas dispostas a pagar um alto preço para ser a primeira a ter o novo telefone.

Sob a estrutura organizacional da Iridium, as organizações regionais de gateway eram responsáveis por desenvolver a distribuição e planos de marketing para suas áreas. Entretanto, a data de lançamento planejada, setembro de 1998, aproximava-se e poucas tinham feito isso. Faltava, a alguns dos parceiros, experiência com telecomunicações.

Muitos gerentes achavam que era essencial posicionar a Iridium como uma marca global o mais rápido possível. Assim, para promover o projeto, a Iridium alocou 125 milhões de dólares para uma campanha que foi lançada em 50 países. Anúncios de duas páginas em grandes revistas diziam que os executivos bem-sucedidos precisavam estar conectados, em contato e no controle. Os anúncios, os comerciaise as malas diretas bajulavam e assustavam os executivos. Um anúncio de jornal dizia: “Se você quer ser o dono do mundo, precisará de um telefone que possa acompanhá-lo”. A APL variou suas promoções de acordo com a região (em cerca de 20 idiomas), mas o tema universal era o entusiasmo e a ansiedade com o sucesso global.

A propaganda começou três meses antes do lançamento, para provocar desejo pelo produto. Em

poucas semanas, mais de um milhão de clientes enviou perguntas sobre a Iridium. A empresa transmitiu essas perguntas para os parceiros regionais, mas a maioria não estava preparada para

respondê-las. Além disso, quando a empresa finalmente lançou seus serviços, em novembro de 1998, os telefones não estavam funcionando 100 por cento. Em agosto de 1999, a empresa

admitiu que tinha somente 20 mil assinantes, um número bem inferior ao que tinha sido previsto

e aos 500 mil clientes de que ela precisava para cobrir seu um bilhão de dólares em custos

operacionais anuais e para pagar a dívida junto aos bancos. A empresa entrou em estado de

emergência — marchava para a falência e buscava a reorganização.

A Globalstar pode se dar bem?

Uma dasrazõesda impetuosidade da Iridium foi saber que osconcorrentesestavam logo atrás. A Globalstar, a ICO Global Communications, a Teledesic e a Ellipso estavam preparadas para

60

construir sistemas de telefonia via satélite. A ICO, entretanto, seguiu a Iridium em direção à falência.

A Globalstar, situada em San Jose, na Califórnia, tinha como objetivo ser lançada em 1999 e

planejava investir 3,8 bilhõesde dólaresem um sistema de 48 satélites. Osprimeirosinvestidores da Globalstar foram a Lora Space and Communications e a Qualcomm.

A equipe da Globalstar está tentando não incorrer nos mesmos erros da Iridium. Enquanto a

Iridium mirava os importantes executivos que estavam sempre viajando, a Globalstar procura oferecer serviços domésticos em países desenvolvidos. Segundo Bernard Schwartz, diretor- presidente da Globalstar e da Loral, os principais clientes são as pessoas que não possuem telefone e que vivem em áreas onde não há serviço de celular. Essas pessoas estão integradas, por meio de seus negócios ou de outros relacionamentos, com os centros de negócios mais populosos. Apesar de os executivos poderem utilizar os serviços da Globalstar, Schwartz quer ter como alvo

pessoas que vivem no mundo semimoderno, mas que sentem falta de comunicação instantânea. Schwartz acredita que México, Canadá, Brasil, Índia, China, Indonésia e Rússia constituem mercados-chave. Outro executivo da Globalstar sugere que os mercados verticais, como as empresas de recursos naturais, as plataformas de exploração de petróleo e as empreiteiras constituem mercados importantes.

A Globalstar projetou telefonesque permitem aosusuáriosescolher entre o serviço por satélite e

o da telefonia celular, oferecendo a elestotal cobertura a um preço maisbaixo. Otelefone possui acessórios que permitem que seja utilizado em carros ou em navios. Além da comunicação vocal, a Globalstar oferece serviços de roaming, posicionamento, fax e transmissão de dados. A empresa fixou o preço de seu telefone em cerca de 1 250 dólares, com os serviços custando aproximadamente 1,25 dólar por minuto. Apesar de esses preços ainda estarem muito altos — os celulares da Nokia saem por 200 dólares e os serviços custam dez cents por minuto —, a Globalstar tem como alvo os clientes que não têm essa opção.

Para construir sua infra-estrutura de serviços, a Globalstar vende acesso a seu sistema para empresasde serviço de telefonia locaise regionaisdo mundo inteiro. Essasempresasse associam

a outras empresas locais para oferecer o sistema de telefonia que melhor se encaixa às

necessidades dos clientes locais. Complementando as redes de telefonia em terra, em vez de competir com elas, a Globalstar acredita que encontrará novos mercados e levará o serviço de telefonia para novas áreas.

A empresa calcula que precisa de apenas 200 mil assinantes para atingir o ponto de equilíbrio.

Entretanto, conseguir esses 200 mil clientes não é fácil. Schwartz e outros administradores deparam-se com inúmeros desafios. Colocar 48 satélites em órbita não é tarefa pequena. Em setembro de 1998, um foguete feito na Ucrânia partiu do complexo de lançamento Baikonur, no Cazaquistão, com 12 dos satélites da Globalstar. O foguete caiu e pegou fogo, destruindo cem milhões de dólares em satélites. O acidente atrasou o lançamento da Globalstar, uma vez que eram necessários32 satélitesem órbitaparaaempresainiciar seusserviços. No dia11 de outubro de 1999, a empresa anunciou o lançamento oficial de seus serviços, que ela planejava operar regionalmente em áreas do mundo atendidas por seus nove gateways operacionais.

Para completar, em 22 de novembro de 1999, a Globalstar anunciou que tinha colocado quatro satélites adicionais, atingindo um total de 48 em órbita. Com isso, ela poderia iniciar seu serviço comercial completo no início de 2000, após quatro satélites de reserva adicionais estarem no lugar.

Gerenciamento de projetos

61

Mesmo com os satélites em órbita, a Globalstar ainda tem que entrar em acordo com mais de cem agências governamentais, lidar com as crises monetárias e concluir a construção de seus 36 gateways. Talvez, entretanto, a tarefa mais difícil, depois da falência da Iridium, seja persuadir os investidores a empatar bilhões de dólares para apoiar o empreendimento.

Isso é que é chamada de longa distância! O fracasso da Iridium levou os analistas a questionar se realmente existe mercado para serviços de telefonia via satélite. Émelhor a Globalstar responder a esses questionamentos provando que as pessoas de todos os lugares querem estar conectadas.

3.4 Ouro Perdido

Phydia de Athayde

Fonte: Carta Capital no. 433 – Fev. 2007

Com o custo aumentado em dez vezes, e sem trazer melhorias estruturais para a cidade, os Jogos do Rio são uma metáfora do Brasil que não sabe crescer

Faltam menos de 150 dias para o início dos XV Jogos Pan-Americanos, dia 13 de julho, no Rio de Janeiro. Tempo curto se comparado ao que a cidade teve para se preparar. Também curto para obrasque já não podem maisatrasar, como vinha acontecendo, sob o risco de simplesmente não ficarem prontas.

Mas o tempo é mais do que suficiente para que todos os envolvidos na organização passem a repetir, quando o assunto for o Pan-Americano, “estamos na última volta do ponteiro”, “é a reta final”. Agora vai. Agora que o orçamento cresceu maisde dezvezese que o medo de um vexame internacional justifica tudo, agora vai.

A menos de cinco meses dos jogos, as disputas políticas amainaram, o dinheiro apareceu e

algumas obras estão perto de ficar prontas. Éhora de garantir ao País que tudo vai bem, que é o

melhor momento já vivido pelo esporte nacional, que o Brasil está a um passo de se tornar sede

de Olimpíadas, da Copa do Mundo de 2014, e assim por diante.

Por trás de tanto otimismo repousam, porém, fatos e atitudes capazes de arruinar as pretensões brasileiras de sediar grandes eventos esportivos internacionais. Ou, ainda, fazer com que aconteçam sem que tragam um mínimo de benefícios ao País. A maneira como o esporte é administrado, o descaso com a explosão nos custos e a displicência quanto ao planejamento urbano são alguns desses pontos.

O Comitê Olímpico Brasileiro (COB) é presidido por Carlos Arthur Nuzman desde 1995. Formado

em Direito, Nuzman foi jogador da Seleção Brasileira de Vôlei de 1962 a 1968. Pouco depois, em 1975, elegeu-se presidente da Confederação Brasileira de Voleibol e lá permaneceu durante 20 anos. À frente do vôlei, Nuzman aproximou o marketing do esporte e, com esse capital, pavimentou o caminho para as vitórias que a modalidade conquistou desde então. Mérito inequívoco.

O mesmo espírito de empreendedor aliado ao marketing levou Nuzman à presidência do COB,

onde está há mais de 12 anos. Ao todo, são 32 anos como dirigente esportivo. Nas últimas eleições para a presidência da entidade, em 2004, nem sequer havia concorrentes. Nuzman reelegeu-se

62

com facilidade, tal como deverá fazer em 2008. Écriação dele, por sinal, uma cláusula que exige que qualquer candidato à presidência do COB esteja há pelo menos cinco anos na entidade. Na prática, dois mandatos.

Esse modelo que facilita a perpetuação de dirigentes é criticado por atletas como Oscar Schmidt, o maior craque que o basquete brasileiro já teve:

– Ospresidentesentram, não têm salário e não querem maissair. No nosso sistema votam clubes,

federações e confederações, só quem não vota é a parte mais importante do esporte, o atleta. O atleta não manda nada, não é respeitado e fazem o que querem dele.

O distanciamento entre a realidade do atleta e a realidade dos dirigentes também pode ser visto

sob outro aspecto. Das 33 confederações de esportes que estarão no Pan, a maioria (42%) tem sede no Rio de Janeiro. Em São Paulo estão 27%dessas entidades, embora o estado abrigue 45% dosatletasque treinam para o Pan. Muitos, inclusive, são esportistasque tiveram de abandonar o Rio em busca de patrocínio e apoio financeiro, itens cada vez mais escassos nos clubes cariocas.

Mesmo perdendo atletas, o fato de o Rio concentrar as sedes de confederações ajuda a explicar sua vitória nas votações para escolher a candidata ao Pan-2007. São Paulo, que foi sede do Pan- Americano em 1963, concorreu e foi derrotada. A capital fluminense é, por extensão, a fortaleza política de Nuzman.

Atletas de esportes olímpicos referem-se ao presidente do COB como “Deus”, tamanho o seu poder. Uma das raras exceções a esse temor misturado com adulação está em Magic Paula, ou Maria Paula Gonçalves da Silva, uma das maiores jogadoras de basquete do País. Em 2003, ela pediu exoneração da Secretaria Nacional de Alto Rendimento, no Ministério do Esporte, por não concordar com a relação promíscua entre Nuzman e o então ministro Agnelo Queiroz.

Os custos da estadia de Paula e Queiroz na República Dominicana, durante o Pan-Americano de 2003, foram pagospelo COB. Apenasuma dasmuitascortesiasda entidade a quem lhe interessa. Além de não concordar com esse comportamento, Paula critica a falta de planejamento do ministério e o abandono das categorias de base no esporte. Ela falou a CartaCapital sobre o que significa um Pan no Brasil:

– O problema do esporte brasileiro é mais embaixo. Não é um Pan-Americano aqui que vai

solucioná-lo. Além do mais, esse é um gasto absurdo. Com muito menos dinheiro daria para estruturar o esporte no País. O Pan é importante para dar visibilidade ao esporte e seria bom se tivéssemos base, se tivéssemos estrutura para os atletas se manterem e trabalharem. Fico preocupada com os atletas depois que tudo acabar e eles voltarem a viver na corda bamba.

Paula dizque um dosfatoresque perpetuam asmazelasdo esporte é focar ospatrocíniosapenas nos atletas de ponta, esquecendo da base:

– Na formação de atletas mesmo, pouca gente está interessada. Só interessa quem já está lá em

cima. Não existe política esportiva para o País, então cada um faz à sua maneira. Quando o governo cria uma lei de incentivo que não exige contrapartida social, os beneficiados serão os mesmos de sempre.

Paula refere-se à Lei de Incentivo ao Esporte, sancionada pelo presidente Lula em 29 de dezembro de 2006. Formulada nos moldes da Lei Rouanet, a lei prevê a renúncia de parte do Imposto de Renda para ser investida no esporte. A exemplo do que já acontece com a Lei Rouanet, teme-se

63

que os benefícios fiscais acabem indo para projetos que ofereçam grande visibilidade e beneficiem, sobretudo, quem goze de ótimo trânsito nas ante-salas de marketing.

Para 2007, estima-se que 300 milhõesde reaissejam destinadosa projetosligadosao esporte em razão da nova lei. No Brasil, desde 2001, a Lei Agnelo-Piva destina 2%da arrecadação dasloterias para o esporte olímpico. O COB recebe esse dinheiro e trata de repassá-lo para as confederações e para si mesmo. No ciclo olímpico para os Jogos de Atenas, a entidade recebeu 158 milhões de reais.

Boa parte desse montante é usada para custear viagens internacionais dos atletas, feitas sempre através da agência de viagens oficial do COB, a Tamoyo Internacional.

A verba também ajuda a manter as instalações do COB, na Barra da Tijuca, e do Comitê

Organizador dos Jogos Pan-Americanos do Rio de Janeiro (CO-Rio), no mesmo prédio. No CO-Rio trabalham mais de dez ex-atletas olímpicos. Paula Andrade e Paula Hernandez, do vôlei. Agberto Guimarães e Rafael Gonçalves, do atletismo. Christiane Paquelet e Ricardo Prado, da natação. Ricardo Trade, do handebol. Sebástian Pereira, do judô. Soraya Carvalho, da ginástica, e Cecília Marques, do pólo aquático, entre outros, como o ex-atleta do remo e vice-presidente do CO-Rio, André Richer.

Não é essencialmente condenável que ex-atletas trabalhem nos comitês olímpico e pan- americano. Grave é quando integrantesdo COBtrabalham em empresas que prestam serviços ao próprio COB. Ochefe da delegação brasileira nasOlimpíadasde Atenase Pequim, MarcusVinícius Freire, ex-atleta do vôlei, até o ano passado era diretor de marketing da seguradora Aon Brasil. Por anos a Aon, de Freire, serviu ao COB, de Nuzman.

A delegação brasileira nas Olimpíadas de Atenas usou uniformes assinados pela estilista Mônica

Conceição, que é cunhada de Nuzman. Aos amigos, tudo.

Há maisrelatosde condutaspouco louváveis, para não dizer escandalosas, como o assédio a uma empresa do setor de alimentação. Um emissário do COB contatou-a oferecendo intermediação para o processo de licitação pública. A empresa recusou a oferta. E declinou da licitação.

Outro relato trata de um fornecedor de painéis eletrônicos convidado a oferecer seus produtos por um valor acima do preço normal. A empresa recusou o convite. Em seguida, surge uma segunda empresa, disposta a comprar os equipamentos da primeira e a revendê-los pelo preço sugerido.

Críticos do COB dizem que o Pan-Americano tornou-se um “balcão de negócios”. Não se depender das palavras do secretário-geral do CO-Rio, Carlos Roberto Osório, para quem “nenhuma

instituição no Brasil é tão controlada quanto o CO-Rio” (entrevista abaixo). Osório explica que toda

a movimentação financeira para os Jogos Pan-Americanos é sujeita à aprovação dos Tribunais de Contas do Município, do Estado e da União, além de cumprir “procedimentos administrativos aprovados pelo nosso conselho-executivo baseados na legislação em vigor”.

Mesmo assim, só não dá para ignorar que os Jogos Pan-Americanos no Brasil custarão dez vezes mais que o programado. Há muitas versões para essa explosão de gastos. Nuzman devolve a pergunta: “Que país cumpriu um orçamento inicial?” É verdade que faz parte da história de Olimpíadas estourar orçamentos (histórico dos Jogos nesta página). Só não se tem notícia de um orçamento que tenha decuplicado. Ainda mais de um Pan-Americano.

64

Antes de seguir, convém lembrar que Jogos Pan-Americanos são tradicionalmente pouco significantesno cenário mundial. Em toda a história das14 ediçõesdo Pan, somente dezrecordes mundiais foram quebrados. Nas Olimpíadas de Atenas, para ter uma idéia, foram batidas 21 marcas mundiais. Juca Kfouri observou em sua coluna, na Folha de S.Paulo, que desde 1979 não se bate um recorde mundial em Pan-Americanos. Além do mais, “a gastança desenfreada que jornais vêm denunciando é criminosa”, denuncia Kfouri, e identificaa“chantagem que era previstadiante do fato consumado e da necessidade de salvar o País”.

Faz cinco anos que o Rio de Janeiro foi escolhido para ser a sede do Pan-Americano de 2007. Agora, a pouco mais de cinco meses do início dos Jogos, o temor de um fracasso justifica gastos emergenciais. O discurso oficial repete que tudo está sob controle, mas há apreensão no ar.

Na terça-feira 6, o presidente Lula esteve no Rio de Janeiro para a primeira inauguração de algo relacionado ao Pan. OCentro de OperaçõesTecnológicascompilará todososdadosreferentesaos Jogos e custou 112 milhões de reais aos cofres do governo federal. Ao lado do ministro do Esporte, Orlando Silva, do governador do Rio, Sérgio Cabral, e de representantes do Comitê Olímpico e do município, Lula frisou querer um “acompanhamento milimétrico” das obras de agora até julho. Repetindo a tese do COB, voltou a ligar o sucesso do Pan às chances de o Brasil ser sede das Olimpíadas de 2016:

– A responsabilidade dos entes federativos é decisiva para a imagem que o Brasil quiser mostrar.

Os Jogos Pan-Americanos serão uma espécie de vest ibular para a nossa compet ência em organizar

eventos esportivos. O Brasil não medirá esforços para que os Jogos Pan-Americanos sejam os melhores já realizados nesta América.

É mesmo bom serem os melhores Jogos Pan-Americanos da América, já que o governo federal investiu, sozinho, 1,5 bilhão de reais. Dez vezes além do previsto inicialmente, vale relembrar. O que faz um orçamento decuplicar? Talvez ambição. Ou pretensão. O Brasil candidatou-se para receber Jogos Pan-Americanos. Assim que foi escolhido, passou-se a tratar os Jogos como uma pré-candidatura olímpica. Essa tese, defendida pelo COB, foi bem costurada e é defendida nas três esferas de governo, como se verá. O secretário-executivo do Comitê Gestor das Ações Federais para o Pan-Americano, Ricardo Leyser, falou a CartaCapital:

– Há 30 anos não se fazem investimentos de porte em equipamentos esportivos no Brasil. Se o

investimento é feito, ele não pode visar só um evento. Éimportante que capacite o Paíspara uma Olimpíada, para um Mundial. O Brasil é candidato a sede dos Jogos Mundiais Militares de 2011, por exemplo. É mais caro, mas não valeria a pena não fazer.

Leyser, no entanto, critica a forma como o orçamento foi apresentado inicialmente pelo COB:

– Originalmente, essa divisão de recursos foi mal planejada. Não foi realista. A conta do governo federal multiplicou por 10, o que é significativo. Alguns itens não estavam previstos, como os investimentos em segurança. Estamos comprando 27 aeronaves, algumas ficarão no Rio, outras serão distribuídas. Mais de 1,1 mil viaturas ficarão no Rio, isso é legado.

O investimento federal em segurança, estimado em 385 milhões de reais, visa dar tranqüilidade aos cariocas, aos turistas e aos atletas. Convém levar em conta a questão das milícias que proliferam no Rio. Essasorganizaçõesvêm tomando asfavelas, especialmente no entorno dasvias de acesso, como a Linha Amarela, ou dos complexos esportivos. A chance de estourarem revides violentos, inclusive durante os Jogos, não é baixa.

65

Ruy César Miranda Reis, secretário especial do município para o Pan, evitou o tema segurança. Preferiu falar de orçamento:

– Se fosse apenas para o Pan-Americano, os Jogos custariam 300 milhões de reais e a prefeitura

entraria com 172 milhões. Hoje, nossos custos passam de 1 bilhão de reais. Os Jogos tinham um valor, mas, com a candidatura para a Olimpíada, isso cresceu. Esse centro tecnológico, por

exemplo, seria importante para o Pan-Americano, mas não é fundamental. É um salto de pretensão e de qualidade.

No governo do estado, entra Sérgio Cabral e saem os Garotinho. O novo secretário estadual de Esportes e Turismo, Eduardo Paes, falou a CartaCapital da situação das obras:

– Encontramos um débito monstruoso, obras quase paradas ou muito atrasadas, como as do

Maracanãzinho. Só este ano, o governo estadual liberará 250 milhõesde reais, a maior parte para

obras no complexo do Maracanã. É um esforço enorme.

Nem o esforço dos governos estadual, federal e municipal será capaz de oferecer à cidade algo além dos locais de competição. A saber: o setor de transporte público seria, de acordo com o projeto de candidatura, o maior beneficiado com os Jogos. Previam-se novas linhas de metrô (duas delas constavam no caderno de encargos da candidatura), a implantação de corredores de ônibus e até de uma linha de barca marítima que ligaria a Barra da Tijuca ao centro da cidade (quadro ao lado). Nada saiu do papel. As propostas mofam no plano diretor de transportes da cidade, publicado no Diário Oficial do Município em maio de 2006.

Além de não haver melhora no transporte público, a cidade ainda terá de absorver osmilharesde turistase garantir que atletase oficiaisligadosao Pan cheguem aoslocaisde competição a tempo. Como? Coube à prefeitura o deslocamento da chamada Família-Pan (equipes e oficiais). A despeito doscongestionamentosque a cidade já enfrenta diariamente, o prefeito Cesar Maia não se alarma:

– Épreciso levar em conta que 70%doseventosacontecerão na Barra. Eosdeslocamentospara a

zona sul, para Deodoro e para o Maracanã serão feitos em corredores exclusivos durante a

passagem pela Lagoa-Barra.

A ligação Lagoa-Barra já é uma das mais congestionadas da cidade. Ao público restará enfrentar

engarrafamentos ou tentar o transporte público disponível ou, ainda, as linhas circulares que estão para ser criadas. Ao redor dos locais de competição não será permitido estacionar veículos particulares.

O caos anunciado nas avenidas cariocas levou o ministro do Esporte, Orlando Silva, a fazer a

primeira crítica às oportunidades perdidas com o Pan. “Em infra-estrutura poderíamos ter algo a mais. Sobretudo, para quem acalenta o sonho olímpico, precisaríamos de um transporte melhor”, pontuou. Silva também lembrou que as mesmas deficiências no transporte contribuíram para a derrota do Rio à candidatura olímpica para 2008.

A menos de cinco meses dos Jogos Pan-Americanos, é visível que a prioridade de investimentos foi

para as instalações esportivas, enquanto a cidade foi deixada em segundo plano.

A candidatura também previa a despoluição da Baía de Guanabara, onde acontecerão as competições de vela, e da Lagoa Rodrigo de Freitas, área de remo e canoagem. Não vão acontecer. Aos atletas da vela, restará deslizar sobre dejetos. “É tanto lixo que tenho medo de arrebentar