Gerenciamento de Projetos [1 ed.] 8521208413, 9788521208419

Citation preview

TRADUÇAO DA DÉCIMA PRIMEIRA EDIÇÃO AMERICANA

GERENCIAMENTO DE

PROJETOS Uma Abordagem Sistêmica para Planejamento

Programação e Controle

Blucher

QUER SEP MAIS LIVRE? Aprenda a Pesquisar e Fazer Ebooks | Armazene arquivos de forma segura

APRENDA A FAZER EBOOKS

HTTPS://ODYSEE.COM

Seja a partir de Livro ou PDF escaneado Construa PDF pesquisável ou Epub Qualidade Profissional

Plataforma descentralizada para Reprodução e Hospedagem de arquivos Garantida por BlockChain

Rápido e Eficiente

Prática como Youtube Descentralizada e resiliente como torrent Facilitadora de transações financeiras como Bitcoin

t.me/AnonLivros

Acervo em Português Mais de 70 mil ebooks no Telegram t.me/PolemicBooks Mais de 2 mil cursos em vídeo t.me/oAcervoCursos

HTTPS://LIBGEN.IS HTTPSy/Z-LIB.ORG Portais de Ebooks e artigos científicos Mais de 2 milhões de documentos

Cursos via streaming no Telegram t.me/LivreSaber

CONTRA A PROPRIEDADE INTELECTUAL A fundamentação Teórica em favor do Conhecimento Livre https://www.mises.org.br/Ebook.aspx?id=29

t.me/AnonLivros

GERENCIAMENTO DE PROJETOS

Os 16 Itens do Dr. Kerzner poro a Maturidade em Gerenciamento de Projetos 1.

Adotar uma metodologia de gerenciamento de projetos e utilizá-la constantemente

2.

Implementar uma filosofia que conduza a empresa rumo à maturidade cm gerenciamento de projetos e comunicá-la a todos.

3.

Compromctcr-sc com o desenvolvimento de planos eficazes no início de cada projeto.

4.

Diminuir as mudanças no escopo por meio do comprometimento com objetivos realistas

5.

Reconhecer que o gerenciamento dos custos c o gerenciamento do cronograma são inseparáveis

6.

Selecionar a pessoa certa para gerente de projetos

7

Fornecer aos executivos as informações voltadas para o patrocinador do projeto, c nào as informações de gerenciamento do projeto

8

Fortalecer o envolvimento c o apoio da gerencia de linha

9

Focar nas entregas, cm vez de focar nos recursos

10 Cultivar a comunicação eficaz, a cooperação c a confiança para alcançar rápida maturidade cm gerenciamento de projetos 11

Compartilhar o reconhecimento pelo sucesso do projeto com toda a equipe do projeto e com a gerência de linha.

12 Eliminar reuniões improdutivas 13 Focar cm identificar c resolver problemas com antecedência, com rapidez c de maneira rentável

14 Medir o progresso periodicamente 15 Utilizar o software de gerenciamento de projetos como ferramenta eficaz ou às habilidades interpessoais

não como um substituto ao planejamento

16 Instituir um programa de treinamento para todos os funcionários, com atualizações periódicas baseadas nas lições aprendidas documentadas

Blucher

GERENCIAMENTO DE PROJETOS

Uma abordagem sistêmica para planejamento, programação e controle

Tradução da décima primeira edição americana

Harold Kerzner, Ph.D. Diretor Executivo Sênior para Gerenciamento de Projetos

The International Institute for Learning New York,

New York

Tradução: João Gama Neto, PMP Joyce I. Prado, PMP

Gerenciamento de projetos: uma abordagem sistêmica para planejamento, programação e controle Título original: Project management: a systems approach to planning, scheduling and controlling

Copyright © 201 3 by John Wiley & Sons, Inc. Todos os direitos reservados. © 2015 Editora Edgard Blucher Ltda.

Todos os direitos reservados. Esta tradução foi publicada sob licença da John Wiley & Sons. Inc.

Blucher Rua Redroso Alvarenga. 1245. 4° andar 04531 -934 - São Paulo - SP - Brasil Tel 55 11 3078 5366 editora9blucher.com.br vwvvv blucher.com. br

Hcha Catalográfca

Kerzncr, Harold Gerenciamento do projetos: uma atMirdagcm sistêmica para planejamento, programação e controle / Harold Kcrancr. tradução

de João Gama Neto e Joyce I. ITado. - Sào Paulo: Blucher. 2015.

Tradução da décima primeira edição americana

Segundo o Novo Acordo Ortográfico, conforme 5“ ed. do Vocabulário Ortográfico da lingua Portuguesa, Academia Brasileira de Letras, março de 2009.

ISBN 978-85-212-08-12-6 (eletrônico)

Título origina): Project management: a systems approach to planning, scheduling and controlling 1. Administração de projetos I. Título 11. Gama Neto, João 111.

É proibida a reprodução total ou parcial

por quaisquer meios, sem autorização escrita da Editora.

Todos os direitos reservados pela Editora Edgard Blucher Ltda.

Prado, Joyce I.

CDD 658.404

15-0623

índices para catálogo sistemático:

1. Administração de projetos

Para Dr. Herman Krier, meu amigo e glim, que me ensinou bem o significado da palavra “persistência ”

PREFACIO

O gerenciamento de projetos evoluiu de uma filo­ sofia de gestão restrita a poucas áreas funcionais e lem­ brada como algo interessante de se ter, para um sistema empresarial de gerenciamento de projetos que afeta cada unidade funcional da empresa. Isso dito, o gerenciamento de projetos evoluiu para um processo de negócio, em vez de, simplesmente, um processo de gerenciamento de pro­ jetos. Mais e mais companhias estão se referindo ao ge­ renciamento de projetos como obrigatório para a sobre­ vivência da empresa. Organizações que se opunham são agora suas defensoras. Professores de administração do passado, que pregavam que o gerenciamento de projetos poderia não funcionar e seria apenas mais uma mania, são agora apoiadores convictos. O gerenciamento de pro­ jetos veio para ficar. Faculdades e universidades estão ofe­ recendo pós-graduações em gerenciamento de projetos. O texto discute os princípios do gerenciamento de projetos. Estudantes que estão interessados em tópicos avançados, como o conteúdo dos Capítulos 21 a 25 desta obra, podem querer ler um de meus outros livros. Ad­ vanced project management: best practices in implemen­ tation (New York: Wiley, 2004) e Project management best practices: achieving global excellence 2a edição (Ho­ boken, NJ: Wiley and II I. Publishers, 2010). A Editora John Wiley & Sons e o International Institute for learning lançaram uma série de quatro livros sobre as melhores práticas de gerenciamento de projetos, com os autores Frank Saladis,Carl Belack e Harold Kerzner. Este livro é endereçado não apenas aos estudantes graduados e de graduação que desejam melhorar suas

habilidades em gerenciamento de projetos, mas também àqueles gerentes funcionais e executivos de alto escalão que atuam como patrocinadores de projetos e que devem forne­ cer apoio contínuo aos projetos. Durante os últimos anos, o conhecimento e o entendimento da alta administração em gerenciamento de projetos amadureceu a um ponto em que quase toda empresa está utilizando gerenciamento de projetos, de uma forma ou de outra. Essas empresas perce­ beram que o gerenciamento de projetos e a produtividade estão relacionados e que estamos agora gerindo nossos ne­ gócios como se fossem um conjunto de projetos. Os cursos de gerenciamento de projetos estão consumindo mats do que nunca o orçamento para treinamentos.

A referência geral é fornecida no texto aos engenhei­ ros. Porém, o leitor não deve considerar o gerenciamen­ to de projetos relacionado estritamente à engenharia. Os exemplos de engenharia são um resultado do fato de que o gerenciamento de projetos surgiu primeiramente nas disciplinas de engenharia, e nós devemos aprender com seus erros. O gerenciamento de projetos hoje reside em todas as profissões, incluindo sistemas de informação, saúde, consultoria, indústria farmacêutica, setor bancário e agências governamentais.

O texto pode ser utilizado tanto para cursos de gra­ duação como de pós-graduação em administração, siste­ mas de informação e engenharia. A estrutura do texto é baseada na minha crença de que gerenciamento de pro­ jetos é muito mais comportamental do que quantitativo, já que projetos são gerenciados por pessoas e não por ferramentas. Os primeiros cinco capítulos fazem parte do

VIII

Gerenciamento de Projetos

núcleo básico de conhecimentos necessários para o en­ tendimento do gerenciamento de projetos. Os Capítulos 6 a 8 tratam das funções de apoio, como gerenciar seu tempo de forma eficaz, conflitos e outros tópicos espe­ ciais. Os Capítulos 9 e 10 descrevem fatores para previsão do sucesso e apoio dos executivos. Pode parecer estranho que sejam necessários dez capítulos sobre comportamen­ to e estrutura organizacional antes dos capítulos mais pe­ sados como planejamento, programação e controle. Esses dez capítulos são necessários para a compreensão do am­ biente cultural de todos os projetos e sistemas. Eles são necessários para que o leitor entenda as dificuldades em alcançar a cooperação multifuncional nos projetos em que os membros da equipe estão trabalhando em vários projetos simultaneamente e por que as pessoas envolvi­ das, as quais possuem formações diferentes, não podem simplesmente forjar uma unidade de trabalho coesa sem atritos. Os Capítulos 11 a 20 são mais quantitativos, sobre planejamento, programação, controle de custos, estimati­ vas, aquisições e qualidade. Os cinco capítulos seguintes são tópicos avançados e tendências futuras. O Capítulo 26 é um estudo de caso aprofundado que está relacionado a quase todos os capítulos do livro.

As mudanças que foram feitas na décima primeira edição incluem:

• Uma nova seção sobre sucesso, compensações e restrições concorrentes • Uma nova seção sobre o valor adicionado • Uma nova seção sobre inteligência de negócios • Uma nova seção sobre governança de projetos • Uma atualização de seção sobre processos de su­ porte ao gerenciamento de projetos • Uma atualização de seção sobre os tipos de encer­ ramento de projeto • Uma nova seção sobre gerenciamento de projetos de “engajamento" • Uma nova seção sobre os obstáculos à implemen­ tação de gerenciamento de projetos em mercados emergentes • Uma nova seção sobre falácias na implementação de gerenciamento de projetos • Uma nova seção sobre os sistemas empresariais de gerenciamento de projetos • Uma nova seção sobre Como as Metodologias de Gerenciamento de Projetos Podem Falhar • Uma nova seção sobre o futuro do gerenciamento de projetos • Uma nova seção sobre gestão de projetos complexos • Uma nova seção sobre scope creep • Uma nova seção sobre exames de saúde do projeto • Uma nova seção sobre como recuperar um projeto problemático

Uma nova seção sobre gerenciamento de projetos públicos Uma nova seção sobre gerenciamento de projetos internacionais Uma nova seção sobre políticas de projeto Uma nova seção sobre vinte erros comuns em ge­ renciamento de projetos Uma nova seção sobre gerenciamento de projetos de inovação Uma nova seção sobre as diferenças entre melho­ res práticas e práticas comprovadas Uma seção atualizada sobre patrocínio de projeto Uma seção atualizada sobre a cultura, trabalho em equipe e confiança Uma nova seção sobre gerenciamento de relacio­ namento com partes interessadas Uma nova seção sobre liderança baseada em valor Uma atualização de seção sobre validação das pre­ missas do projeto Uma nova seção sobre validação dos objetivos de projeto Uma nova seção sobre o dicionário da Estrutura Analítica do Projeto Uma nova seção sobre validação e verificação Uma nova seção sobre linhas de base do projeto Uma nova seção sobre a matriz de rastreabilidade Uma expansão dos atributos principais da Estru­ tura Analítica do Projeto Uma expansão do uso da EAP e do dicionário da EAP para verificação Uma nova seção sobre métricas de gerenciamento de projetos Uma nova seção sobre indicadores-chave de desempenho Uma nova seção sobre métricas baseadas em valor Uma nova seção sobre dashboard de gerenciamen­ to de projetos Uma nova seção sobre gestão de portfólio Uma nova seção sobre a teoria da complexidade Uma nova seção sobre sistemas de informação de gerenciamento de projetos Uma nova seção sobre sistemas de gestão empresarial Uma nova seção sobre resolução de problemas em projetos Uma nova seção sobre brainstorming Uma nova seção sobre tomada de decisões em projetos Uma nova seção sobre a determinação do impacto de uma decisão Uma nova seção sobre escuta ativa Uma nova seção sobre gerenciamento ágil de projetos E, para coroar, um estudo de caso que pode ser usado como revisão das áreas de domínio do Guia * PMBOK 5a edição.

PREFÁCIO

O texto contém mais de 25 estudos de caso, mais de 125 questões de múltipla escolha, e cerca de 400 questões para discussão. Há também um livro de casos separado (Estudos de Caso de Gerenciamento de Projetos, 4a edi­ ção), que fornece exemplos adicionais do mundo real. Esse texto, o Guia PMBOK® e o livro de casos são ideais como ferramentas autodidáticas para o exame de Certificação PMP®, do Project Management Institute. Por esse motivo, há tabelas com referências cruzadas em cada página de abertura dos capítulos ao longo do livro que detalham as seções do livro de casos e de um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) que se aplicam ao conteúdo do capítulo. A margem esquerda das páginas do texto contém barras la­ terais que identificam a referência cruzada do material na página à(s) seção(òes) apropriada(s) do Guia PMBOK®. Ao final da maioria dos capítulos há uma seção sobre di­ cas de estudo para o exame PMP®, incluindo mais de 125 questões de múltipla escolha.

Este livro é atualmente utilizado no mercado uni­ versitário, no mercado de referência e no estudo para o exame de Certificação PMP®. Portanto, para atender às necessidades de todos os mercados, um compromisso teve que ser firmado sobre o quanto o texto seria alinhado ao Guia PMBOK® e quanto material novo seria incluído, sem duplicar o tamanho do livro. Algumas faculdades e universidades utilizam o livro para ensinar fundamen­ tos de gerenciamento de projetos sem referência ao Guia PMBOK®. O texto não contém todo o material necessá­ rio para embasar cada seção do Guia PMBOK®. Por isso, para estudar para o exame de Certificação PMP®, o Guia PMBOK® deve ser utilizado em conjunto com este livro. O texto cobre o conteúdo da maioria das áreas de conhe­ cimento do Guia PMBOK®, mas não necessariamente na profundidade que o guia apresenta.

Um manual do instrutor está disponível apenas para membros de faculdades e universidades por meio do con­ tato com o seu representante local Wiley ou por meio da visita ao website da Wiley em www.wiley.com/kerzner. Esse website inclui não apenas o manual do instrutor, mas também 500 slides em PowerPoint que seguem o conteú­ do do livro e ajudam a organizar e executar as instruções das aulas e o aprendizado em grupo. O acesso ao material do instrutor pode ser fornecido apenas por intermédio da Editora John Wiley & Sons, e não pelo autor.

IX São oferececidos seminários de um, dois ou três dias sobre gerenciamento de projetos e treinamento para a Certificação PMP® utilizando o livro, por meio do contato com Lori Milhaven,Vice Presidente Executivo do Interna­ tional Institute for I.earning, pelo telefone 800-325-1533, ramal 5121 (endereço de e-mail: [email protected]). Os exercícios e estudos de casos ao final dos capí­ tulos abrangem uma variedade de setores. Quase todos os estudos de casos abordam situações reais extraídas da minha experiência em consultorias. As respostas de cole­ gas meus, que estão utilizando o livro, proporcionaram críticas frutíferas, muitas das quais foram incorporadas à décima primeira edição. A maioria dos artigos que se tornaram clássicos so­ bre gerenciamento de projetos foi citada no livro durante os primeiros 11 capítulos. Esses artigos foram a base para muitos desenvolvimentos modernos em gerenciamento de projetos e foram, portanto, identificados ao longo do texto. Muitos colegas forneceram criticas valiosas. Espe­ cificamente, estou em dívida com os gerentes de treina­ mento de vários setores e do governo, cuja dedicação e compromisso com a capacitação e treinamento em geren­ ciamento de projetos levaram a mudanças valiosas nesta edição e nas edições anteriores. Particularmente, gostaria de agradecer a Frank Saladis, PMP®, Consultor Sênior e Instrutor no International Institute for Learning, por seus comentários construtivos, recomendações e assistên­ cia no mapeamento do texto do Guia PMBOK®, assim como pelas mudanças recomendadas em vários capítu­ los. Estou em dívida com o Dr. Edmund Conrow, PMP®, por uma década de assistência na elaboração dos capítu­ los de gerenciamento de riscos de todos os meus livros. Agradeço também ao Dr. Rene Rendon por sua revisão e recomendações de mudanças no capítulo sobre gestão de contratos.

À equipe de gestão e aos funcionários do Interna­ tional Institute for Learning, agradeço a todos pelos 20 anos de interminável incentivo, apoio e assistência em todas as minhas pesquisas e textos sobre gerenciamento de projetos.

Harold Kerzner International Institute for Learning

CONTEÚDO

1

VISÃO GERAL

1.0 1 1

Introdução

1 19

1

Gerenciamento de Projetos no Setor Público

1

Entendimento do Gerenciamento de Projetos 2

1.2

Definição de Sucesso do Projeto

1.3

Sucesso. Compensações c Restrições

Concorrentes

5

120

Gerenciamento de Projetos Internacionais

121

Engenharia Simultânea Uma Abordagem de Gerenciamento de Projetos

5

1.22

1 23

1 4 A Interface entre o Gerente de Projetos

Milor Agregado

25

Dicas de Estudo para o Exame de Certificação

1.5

Definição do Papel do Gerente de Projetos 9

Exercícios

1.6

Definição do Papel do Gerente Funcional

Estudo de Caso

1.7

Definição do Papel do Colaborador Funcional Definição do Papel do Executivo

10

25

25

cm Gerenciamento dc Projetos * PM1

c o Gerente de Linha 6

1 8

24

26

27

Williams Machine Tool Company 29

11

12

1.9

Como Trabalhar com Executivos

1.10

Govemança/Palrocimo por Comitês

111

O Gerente de Projetos como Agente

12

2

13

CRESCIMENTO DO GERENCIAMENTO DE PROJETOS: CONCEITOS E DEFINIÇÕES 31

2.0

Introdução

15

2.1

Administração Geral dos Sistemas

1.12

Campeões do Projeto

2.2

Gerenciamento dc Projetos 1945-1960

32

1)3

O Lado Negativo do Gerenciamento

2.3

Gerenciamento dc Projetos 1960-1985

33

2.4

Gerenciamento de Projetos: 1985-2012

36

2.5

Resistência a Mudanças

2.6

Sistemas. Programas e Projetos

de Planejamento

de Projetos

114

16

16

Organizações Orientadas a Projetos

c Organizações Não Orientadas a Projetos 1.15

Uma Definição

O Marketing nas Organizações Orientadas a Projetos

1.16

16

A Posição do Gerente de Projetos

118

Diferentes Visões sobre Gerenciamento 21

38

42

Gerenciam ento de Projetos: Um a Definição

20

1.17

de Projetos

31

2 7 Gerenciamento de Produtos versus

18

Classificação de Projetos

31

20

2.8

Maturidade e Excelência: Uma Definição

2.9

Gerenciamento de Projetos Informal

Uma Definição

46

44

45

XII

Gerenciamento de Projetos

2.10

As Várias Faces do Sucesso 46

2.11

.As Várias Faces do Fracasso

2.12

O Processo Stage-Gate 49

2 13

Ciclos de Vida do Projeto

2 14

Reuniões de Gate Review

3.17

em Gerenciamento de Projetos * PM1

47

Exercicios

2.16

Coronado Communications

Gerenciamento de Engajamento

2 19 2 20

4 1

58

Propriedade Intelectual em Gerenciamento

4.3

Executiva 111 Requisitos Organizacionais e Comportamenlais

da Empresa para Gerentes dc Programas c dc Projetos 114

2.22

Dicas de Estudo para o Exame de Certificação

em Gerenciamento de Projetos PMPEstudo de Caso

Criando uma Metodologia

75

3 4 Organização Linha-Staff(Coordenador

Modificação das Estruturas Matriciais

3.8

As Matrizes Forte. Fraca c Balanceada

3 9

78

79

3.7

84 86

Centro de Competências em Gerenciamento

de Projetos 87 3 10 Sobreposição Matricial

87

3 11

Seleção do Modelo Organizacional

3.12

A Estruturação da Pequena Empresa

3 13

Gerenciamento de Projetos por I,’mdades

88

91

123

O Organograma do Projeto 131 l^oblcmas Especiais 133 Seleção da Equipe de Implementação

do Gerenciamento de I’rojctos 134 Erros Cometidos por Gerentes de Projetos Inexperientes

4 15

135

Dicas de Estudo para o Exame de Certificação em Gerenciamento de Projetos PMI® 136

Exercícios

137

5 FUNÇÕES DE GESTÃO 5.0 5.1 5.2

143

Introdução 143 Controle 144 Direção 144

de Projetos em Mercados Emergentes 94

5 3 Autoridade do Projeto 147 5.4 Influências Interpessoais 152 5 5 Barreiras ao Desenvolvimento da Equipe do Projeto 154 5.6 Sugestões para Lidar com a Equipe Recém-Formada 156

Sete Falácias que Atrasam a Maturidade

5.7

Estratégicas dc Negócios (UEN) 92

3 14

Gestão de Transição

3.15

Obstáculos para Implementar Gerenciamento

3 16

4 11 4 12 4 13 4 14

77

Organização por Produtos (Projetizada)

Deveres c Descrições dc Trabalho 120 O Processo Organizacional de Seleção

4.9 O Escritório de Projetos 127 4 10 A Equipe Funcional 130

71

Modelo Organizacional Matricial

A Seleção do Gerente dc Projetos Errado 118 Gerentes de Projetos da Próxima Geração 120

dc Pessoal

3 3 Desenvolv im ento de Posições de Integração

de Projetos)

4.5 4.6

71

3 1 Fluxo Organizacional de Trabalho 72 3 2 Organização Tradicional (Clássica) 73

no Trabalho

Situações Especiais Durante a Seleção do Gerente de Projetos 117

4 7 4 8

68

ESTRUTURAS ORGANIZACIONAIS Introdução

4.4

65

Exercícios 67

3 6

110

O Gerenciamento de Mudanças Organizacionais e as Culturas Corporativas 60

Pensamento Sistêmico 64

3.5

O Ambiente de Seleção de Pessoal

Seleção do Gerente de Projetos: Uma Decisão

2.21

30

109

4.2

de Projetos 63

3

107

4 ORGANIZAÇÃO E SELEÇÃO DE PESSOAL PARA O ESCRITÓRIO DE PROJETOS

E EQUIPE 109 4 0 Introdução

56

As Metodologias Podem Falhar

105

54

Metodologias de Gerenciamento de Projetos

Uma Definição 55 2 17 Metodologias Empresariais

2 18

101

Jones and ShephardAccountants, Inc.

de Gerenciamento de Projetos

101

Estudos de Caso

50

(Encerramento do Projeto) 53

2 15

Dicas de Estudo para o Exame de Certificação

93

do Gerenciamento dc Projetos 99

A Construção da Equipe como um Processo Contínuo 157

XIII

CONTEÚDO

158

5.8

As Disfunções de uma Equipe

5.9

A Liderança em um .Ambiente de Projetos

5.10

A Liderança no Ciclo dc Vida

5.11

Liderança em Projetos Baseada em Valor

5.12

O Impacto Organizacional

5.13

Os Problemas entre o Colaborador

6.6

161 163

232

Estudo de Caso

165

Os Trabalhadores Relutantes 232

7 CONFLITOS

5.14

As Armadilhas de Gestão

5.15

As Comunicações

5 16

As Reuniões de Avaliação do Projeto

5.17

Os Gargalos do Gerenciamento de Projetos

5.18

Habilidades Transversais

5.19

Escuta Ativa

5 20

Resolução de Problemas em Projetos

521

Brainstorming

5.22

Tomada dc Decisão cm Projetos

523

Prevendo o Resultado dc uma Decisão

5 24

Facilitação

5.25

Lidando com Dinâmicas dc Equipe

168

169 174 175

175

175

233

7.0

Introdução

7.1

Objetivos

7.2

O Am biente de Conll ilo

7.3

Tipos de Conflitos

7.4

Resolução de Conflitos

7.5

Entendimento dos Conflitos de Origem

233

233 234

235 237

Superior. Subordinada e Funcional

177

183 186 191

237

7.6

O Gerenciamento dc Conflitos

77

Métodos dc Resolução dc Conflitos

7.8

Dicas dc Estudo para o Exame dc Certificação

238 239

em Gerenciamento de Projetos PMI *

192

Exercícios

240

241

Estudos de Caso

195

Programação das Instalações na Mayer

195

5 26

As .Armadilhas de Comunicação

5 27

Provérbios e Leis

5 28

Educação do Comportamento Ilumano

529

Políticas c Proccdim entos dc Gestão

5 30

Dicas dc Estudo para o Exame de Certificação

196

cm Gerenciamento de I’rojctos PMl * Exercícios

231

em Gerenciamento de Projetos PMI®

Exercícios

166

co Gerente

Negativas

160

Dicas de Estudo para o Exame de Certificação

198

Manufacturing

243

Telestar International

243

Tratamento de Conflitos no Gerenciamento

199

de Projetos

244

200

8 TÓPICOS ESPECIAIS 249

201

Estudos de Caso

O Projeto Trophy

207

8.0

Introdução

8 1

Medição do Desempenho

249 249

McRoy Aerospace

210

8.2

Compensação Financeira c Recompensas

O Funcionário Ruim

211

8.3

Questões Criticas sobre a Recompensa às Equipes dc Projetos

A Pnma-Dona 212 A Reunião de Equipe

213

8.4

Eficácia da Liderança (A)

214

Eficácia da Liderança (B)

216

257

Gerenciamento de Projetos Eficaz, na Organização de Pequeno Porte

259

8.5

Megaprojetos 261

8.6

Moralidade. Ética c Cultura Corporativa

8.7

Responsabilidades Profissionais

ADMINISTRAÇÃO DO SEU TEMPO

8.8

Parcerias Internas

265

E ESTRESSE 227

8.9

Parcerias Externas

266

8.10

Treinamento c Capacitação

8 11

Equipes Integradas de Produto/Projeto

8.12

Equipes Virtuais de Projetos

8.13

Projetos de Avanço

8.14

Gerenciando Projetos de Inovação 272 Gerenciamento Ágil de Projetos 273

Questionário Motivational

221

6.0

Introdução

61

Entendimento da Administração do Tempo 227

6.2

Ladrões de Tempo

6.3

Formulários para Administração do Tempo

6.4

Adm imstração Eficaz do Tempo

6.5

Estresse e Esgotamento

227 228

230

229

229

8 15

253

261

263

267

270

271

269

XIV

Gerenciamento de Projetos

Dicas de Estudo para o Exame de Certificação

11.2

Validando os Objetivos

em Gerenciamento de Projetos PM1®

113

Planejamento Geral

278

11.4

Fases do Ciclo de Vida

Estudo de Caso

11.5

Elaboração de Propostas

116

Reuniões de Kickoff 330

117

Entendimento dos Papéis dos Participantes

118

Planejamento do Projeto

119

A Declaração do Trabalho

8 16

Exercícios

Isso é Fraude?

274

280

9 AS VARIÁVEIS PARA O SUCESSO

283

283

9.0

Introdução

91

Como Prever o Sucesso do Projeto

9.2

A Eficácia no Gerenciamento dc Projetos

93

Expectativas

9.4

Lições Aprendidas

9.5

Entendimento das Melhores Práticas

9.6

Melhores Práticas versus

326

328 330

286

333

1111 Cronogramas dc Marcos

337

338

1112 A Estrutura Analítica do Projeto

338

1113 Problemas na Decomposição da EAP 343

288

288

1114 Dicionário de Estrutura Analítica do Projeto 345 1115 O Papel dos Executivos na Seleção de Projetos

292

346

Dicas de Estudo para o Exame de Certificação

1116 O Papel dos Executivos no Planejamento

em Gerenciamento de Projetos PMP

1117 O Ciclo de Planejamento 349

Exercícios

332

332

1110 As Especificações do Projeto

283

287

Práticas Comprovadas 9.7

325

293

348

1118 Autorização de Planejamento do Trabalho

293

1119 Por que os Planos Fracassam?

Estudo dc Caso

11 20 Interrupção dc Projetos

Radiance International 293

350

350

351

1121 Como Lidar com Finalizações c

Transferencias dc lYojctos 351

10 COMO TRABALHAR COM EXECUTIVOS 295

100

Introdução

101

O Patrocinador do Projeto

10 2

Como Lidar com as Discordâncias com

295 295

11 23 A Programação Mestre dc Produção

355

355

11.25 Planejamento Total do Projeto

358

II 26 O Termo de Abertura do Projeto

10 3

A Crença Coletiva

10 4

O Campeão dc Saída

10 5

Os Representantes Internos 304

106

352

1124 O Plano do Projeto

302

o Patrocinador

11.22 Cronogramas c Gráficos Detalhados

303 303

11.27 Linhas de Base do Projeto

1128 Verificação e Validação

360

362

364

Gerenciamento do Relacionamento

11 29 Matriz de Rastreabilidade de Requisitos

com as Partes Interessadas

11.30 Controle de Gestão

305

107

Política

10.8

Dicas de Estudo para o Exame de Certificação

366

1131 A Interface entre o Gerente de Projetos

310

cm Gerenciamento de Projetos PM1 *

Exercícios

365

311

311

c o Gerente dc Linha 11 32 Paralelismo

366

368

11.33 Gerenciamento dc Configuração

369

11 34 Metodologias dc Gerenciamento dc Projetos

Estudos de Caso

Corwin Corporation

314

Pnonzação de Projetos

da Empresa

11 35 Auditorias de Projetos

320

O Patrocinador Irresponsável

320

Introdução

111

Xâlidação das Prem issas

371

12 TÉCNICAS DE PROGRAMAÇÃO DE REDE

323

11.0

em Gerenciamento de Projetos PMI®

Exercícios 373

321

11 PLANEJAMENTO

371

11 36 Dicas dc Estudo para o Exame dc Certificação

I èndendo Executivos no Gerenciamento de Projetos

369

323

325

12.0

Introdução

12.1

Fundamentos dc Rede

381 383

381

XV

CONTEÚDO

12.2

12.3 12 4

Técnica de Avaliação e Revisão

14.5

Distribuições de Mão de Obra 433

Gráfica (GERT)

14.6

Taxas de Overhead 435

Dependências

385 386

Tempo de Folga

386

Rcplancjamcnto da Rede

12.6

Estimativa do Tempo da Atividade

12.7

Estimativa do Tempo Total do Projeto

12.8

Planejamento do PERT/CPM Total

390

14 8

Prccificação do Trabalho 438

12 11 Modelos PERT/CPM Alternativos

439

14 10 O Procedimento de Revisão da Prccificação

393

14.11 Processo Sistêmico de Prccificação

394

Apoio/Rcscrva

441

441

14 13 O Dilema da Oferta Baixa

397

443

14.14 Problem as Específicos 444

398

14 15 Armadilhas do Processo dc Estimativa 444 14 16 Como Estimar Projetos de Alto Risco

12 14 Problemas dc Programação

401

14 17 Riscos do Projeto

12 15 Os Mitos da Compressão do Cronograma

401

402

444

445

14 18 O Desastre da Aplicação da "Solução 10%”

12 16 Entendimento do Software dc Gerenciamento

nas Estimativas do Projeto

446

14 19 0 Custo do Ciclo de Vida (LCC)

449

12 17 Características de Software Oferecidas 402

14 20 Apoio Logístico

12 18 Classificação de Software

14 21 Critérios Econômicos de Seleção de Projetos

403

12 19 Problemas dc implementação

404

451

12.20 Corrente Critica 405

Orçamento de Capital 453 14 22 Periodo de Payback 453

12.21 Dicas dc Estudo para o Exame dc Certificação

14 23 O Valor do Dinheiro no Tempo

cm Gerenciamento de Projetos PMI® Exercícios

14.25 Taxa Interna dc Retomo (TIR) 414

14 28 Racionamento de Capital

O Patrocinador Invisível 416

456

14 29 Financiamento dc Projetos

em Gerenciamento dc Projetos PMI *

Introdução

13 1

Relatório para o Cliente

419

Exercícios

420

13 2

Gráfico de Barras (Gantt)

13 3

Outras Tccnicas Convencionais

424

Dicas de Estudo para o Exame de Certificação

426

cm Gerenciamento de Projetos * PMI

426

Exercícios 426 14 DEFINIÇÃO DE PREÇOS E ESTIMATIVAS

14 3 14.4

427

15.0

Introdução 463

15.1

Compreensão dc Controle

152

O Ciclo Operacional

15 3

Códigos de Contas de Custos 468

154

Orçamentos

155

O Sistema dc Medição do Valor Agregado

15 6

(EWS) 473 Variação e Valor Agregado

157

A Linha de Base dos Custos

158

Como Justificar os Custos

486

15.9

O Dilema dos Sobrccustos

488

Introdução 427 Estratégias Globais dc Prccificação

Tipos de Estimativas

460

15 CONTROLE DOS CUSTOS 463

13.5

14.2

458

O Problema de Estimativa

Redes e Diagramas Lógicos

14 1

457

Estudo de Caso

420

13 4

14 0

456

14 30 Dicas dc Estudo para o Exame dc Certificação

419

130

de Apresentação

454

14 26 Com paração entre TIR. VPL c Pay back 455 14 27 Análise de Riscos 455

Estudos de Caso Crosby Manufacturing Corporation

453

14 24 Valor Presente Liquido (VPL) 454

406

408

13 GRÁFICOS DO PROJETO

428

429

Processo de Prccificação

440

14.12 Desenvolvimento dos Custos dc

400

de Projetos

Suavização da Curva dc Homcns-Horas

do Departamento

392

12.9 Compressão dos Tempos 394 12 10 Áreas Problemáticas no PERT/CPM 396

12.13 Espera

Custos de Materiais e de Apoio 437

14.9

12.5

12 12 Redes de Precedência

14 7

431

Requisitos de Colaboração Organizacional

432

466

467

472

474 485

XVI

Gerenciamento de Projetos

17.11 Distribuições de Probabilidade e o Processo

15.10 Registro dos Custos de Materiais Utilizando

a Medição do Valor Agregado

488

de Monte Cario

563

1511 O Critério da Contabilidade de Materiais 490

17 12 Planejar Respostas aos Riscos (11.5)

1512 Xàriações de Materiais Preço e Quantidade 490

17.13 Monitorar e Controlar os Riscos (11.6)

15 13 XânaçÕcs Resumidas 491

17.14 Algumas Considerações sobre

15 14 Relatório de Andamento

Implementação

491

1515 Problemas de Controle de Custos

576

15.16 Sistemas de Informação de Gerenciamento

17.16 Dependências entre os Riscos

dc Projetos 496 1517 Sistemas de Gestão Empresarial

17.17 O Impacto das Medidas dc Tratamento de Riscos 581

496

15 18 Métricas do Projeto 496

578

17 18 Os Riscos e a Engenharia Simultânea

15.19 Indicadores-Chavc dc Desempenho

cm Gerenciamento dc Projetos PMI» Exercícios 586

15 22 Business Intelligence

Estudos de Caso

510

510

15 24 Dicas dc Estudo para o Exame dc Certificação em Gerenciamento de Projetos PMI *

Exercícios

582

17.19 Dicas dc Estudo para o Exame de Certificação

500

15 20 Métricas Baseadas cm Valor 504 15.21 Dashboards e Scorecards 508 15 23 Infográficos

574

575

1715 A Utilização das Lições Aprendidas

494

569

Teloxy Engineering (A)

591

Teloxy Engineering (B)

591

585

O Departamento de Gerenciamento

511

de Risco

512

592

Estudos de Caso O Período na "Geladeira " 521

Franklin Electronics

18 CURVAS DE APRENDIZAGEM

522

Problemas no Paraíso 523

16 ANÁLISE DE COMPENSAÇÕES EM UM

18 0

Introdução

18 1

Teoria Geral

18 2

O Conceito dc Curva dc Aprendizagem

18 3

Representação Gráfica

18 4

525

AMBIENTE DE PROJETO

595

595 595 597

Palavras-Chave Associadas com Curvas

16 0

Introdução

16 1

Metodologia para .Análise dc Compensações 527

18 5

A Curva Média Cumulativa

16 2

Os Contratos e Suas Influências em Projetos

18 6

Fontes de Experiência

18 7

Desenvolvimento de Medidas

16.3 16 4 16 5

525

de Aprendizagem

Preferências de Compensações nos Setores

Conclusão

537 537

596

598

598

599

de Inclinação 601

539

Dicas de Estudo para o Exame dc Certificação em Gerenciamento de Projetos PMI® 539

17 GERENCIAMENTO DE RISCOS

18 8

Custos Unitários e Utilização de Pontos Centrais 601

18 9

Seleção de Curvas de Aprendizagem

602

18 10 Pedidos Posteriores 603

541

170 17 1

Introdução 541 Definição de Risco

17.2

Tolerância aos Riscos

17.3

Definição de Gerenciamento de Riscos 545

18 14 .Arma Competitiva

17.4

Certeza. Risco c Incerteza

18 15 Dicas de Estudo para o Exame de Certificação

17.5 17.6

Processos dc Gerenciamento dos Riscos Planejar o Gerenciamento dos Riscos (11.1)

17 7

18 11 Paradas de Produção 603 18 12 Limitações da Curva de Aprendizagem

543

18 13 Preços e Experiência

544

545

604

605

cm Gerenciamento dc Projetos PMI *

549

604

605

Exercícios 606

549

Identificação dos Riscos (11.2)

550

19 GERENCIAMENTO DE CONTRATOS

178

.Análise dc Riscos (11.3. 11.4)

17.9

.Análise Qualitativa de Riscos (113) 558

555

1710 .Análise Quantitativa de Riscos (114)

562

19 0

Introdução 607

19.1

Aquisições 608

19.2

Planejar as Aquisições

609

607

XVII

CONTEÚDO

19.3

19 4

21 DESENVOLVIMENTOS MODERNOS EM GERENCIAMENTO DE PROJETOS

Conduzir as Aquisições Solicitar Respostas dos Fornecedores

19.5

611

A Condução das Aquisições

612

Conduzir as Aquisições Selecionar

21.0

Introdução 667

21.1

O Modelo dc Maturidade cm Gerenciamento de Projetos (PMMM)

Fornecedores 613 19.6

Tipos de Contratos 615

19.7

Contratos dc Incentivo

667

21.2

667

Desenvolvimento de uma Documentação Processual Eficaz 670

618

19 8

Tipo de Contrato versus Risco

19 9

O Ciclo de Adm inistraçâo do Contrato

19 10 Encerramento do Contrato

620 620

623

21.3

Metodologias de Gerenciamento de Projetos

21.4

Melhoria Continua

21.5

Planejamento da Capacidade

673

673

19 11 Utilização de uma Lista de Verificação

623

21.6

Modelos dc Competência 674

19 12 A Interação Entre Proposta c Contrato

624

217

Gerenciamento de Vários Projetos

21.8

Reuniões dc Revisão de Final de Fase 676

19 13 Resumo 626 19 14 Dicas dc Estudo para o Exame dc Certificação

em Gerenciamento de Projetos PMI®

llonicker Corporation

Concorrer ou não Concorrer

630

A Reserva de Gerenciamento

631

20 GERENCIAMENTO DA QI ALIDADE 20 0

Introdução 635

20 1

Definição dc Qualidade

20 2

O Movimento da Qualidade

20 3

Comparação entre os Pioneiros da

20.4

20 5

676

22 O “NEGÓCIO” DAS MUDANÇAS

O Dilema de Cmnograma 629

Qualidade

675

Estudo dc Caso

626

Estudos de Caso

672

NO ESCOPO

635

679

22.0

Introdução

22 1

Necessidade dc Conhecimento do Negócio 680

22.2

O Momento Certo para Mudanças no Escopo

22.3

636

22.4

682

A Lógica para Não Aprovar um a Mudança no Escopo

639

681

A Necessidade do Negócio por uma Mudança no Escopo

637

679

682

Estudo de Caso

A Abordagem dc Taguchi

640

Kemko Manufacturing 682

O Prêm io Nacional de Qualidade Malcom Baldrigc

642

23 O ESCRITÓRIO DE PROJETOS 685

20 6

ISO 9000 643

20 7

Conceitos dc Gerenciamento da Qualidade

20 8

O Custo da Qualidade

20 9

As Sete Ferramentas de Controle 647

da Qualidade

645

20 10 A Capacidade do Processo (Cp) 20 11 Am ostragem dc Aceitação

20.13 Lean Seis Sigma c DMAIC 20.14 Liderança da Qualidade

23.1

O Escritório dc Projetos Atual 685

23.2

Os Riscos dc Implementação

23 3

Tipos dc Escritórios de Projetos

23.4

Escritórios dc Gerenciamento de Projetos

cm Rede 23.5

659

660 660

20 19 Dicas de Estudo para o Exame de Certificação

cm Gerenciamento dc Projetos PMI *

686 687

687

Sistemas de Informação de Gerenciamento

23.6

Divulgação de Informações 689

23.7

Mentoring

23.8

Desenvolvimento de Padrões e Modelos 690

23.9

Benchmarking dc Gerenciamento dc IVojctos 691

690

23.10 O Desenvolvimento do Business Case

660

20 18 Gestão da Qualidade Total (TQM)

685

dc Projetos 688

658

659

20 17 Produção Just-in-Time (JIT)

Introdução

657

20 15 Responsabilidade pela Qualidade 20 16 Círculos de Qualidade

230

655

656

20 12 Implementação do Seis Sigma

643

663

691

23.11 Treinamento sob Medida (Relacionado a Gerenciamento dc Projetos) 692

23.12 Gerenciamento das Partes Interessadas 693

XVIII

Gerenciamento de Projetos

23 13 Melhona Continua 693 23 14 Planejamento da Capacidade

693

23.15 Os Riscos da Utilização de um Escritório de Projetos 693

26.3

O Lançamento do Empreendimento

26.4

O Sistema Indium

26.5

A Rede Terrestre e Espacial

26.6

A Iniciação do Projeto Desenvolvimento

do Business Case

23 16 Gerenciamento de Portfolio dc Projetos 694 Estudo de Caso

A Ação Judicial de Gerenciamento de Projetos

698

737

DE CRISE 24 0

26.7

O Business Case “Oculto”

26.8

O Gerenciamento dos Riscos

26.9

A Crença Coletiva

24 1

24.2 24 3

738

740

26.11 Os Anos de Intancia do Indium

740

742

26 13 O Projeto M-Star 743

701

Compreensão do Gerenciamento de Crises

Ford versus Firestone

738

739

26.12 O Financiamento da Divida

701

Introdução

737

737

26.10 O Campeão de Saida

24 GERENCIAMENTO DE PROJETOS

735

701

26 14 Um Novo CEO

743

26 15 Os Lançamentos dos Satélites

702

O Acidente do Concorde da Air France

703

744

26.16 Uma Oferta Pública Inicial (IPO)

744

24.4

A Intel e o Chip Pentium

24 5

O Submarmo Russo Kursk

24 6

Os Envenenamentos por Tylenol

24 7 24 8

O Marketing da Fórmula Infantil da Nestle 706 O Desastre do Ônibus Espacial Challenger 708

26.20 A‘“Gripe” da Indium 749 26.21 Â Procura dc um “Cavaleiro Branco"

24.9

O Desastre do Ônibus Espacial Columbia

26.22 ADcíinição do Fracasso (Outubro dc 1999)

26 17 O Cadastramento de Clientes

703 704

26 18 A Ascençào Rápida do Iridium

2619 A Queda Rápida do Indium

704

746

26.25 Epilogo

26 28 Autópsia

25 O FUTURO DO GERENCIAMENTO

25 0

751

25 1

Projetos Complexos

713

752

752

26 29 O Impacto Financeiro da Falência

713

Tempos de Mudança

751

751

26 26 Processos de Acionistas

710

750

750

26 27 A Decisão do Tnbunal de Falências DE PROJETOS

749

26 24 A Indium é Resgatada por $ 25 Milhões

709

24 12 As Implicações no Gerenciamento dc Projetos

708

745

26 23 O Plano dc Exorbitação dc Satélites

24 10 Vitimas versus Vilões 709 24.11 As Fases do Ciclo dc Vida

744

26 30 O Que Realmente Deu Errado0

753

753

26 31 Lições Aprendidas 755

716

25 2

Teoria da Complexidade

25.3

Escalada de Escopo (Scope Creep)

25.4

Avaliações da Saúde do Projeto

25.5

Gerenciando Projetos Problemáticos

26 32 Conclusão

719

720

757

26 33 Epilogo (2011)

757

723 726

Apêndice A

Soluções para o Exercício de Conflito em Gerenciamento de Projetos

26 A ASCENSÃO, QUEDA E RESSURREIÇÃO

759

Apêndice B Soluções para o Exercicio de Liderança

DO IRIDIUM: UMA PERSPECTIVA DO

Apêndice C Estudos dc Casos Dorale Products

GERENCIAMENTO DE PROJETOS

Apêndice D Soluções para os Estudos de Casos

260

Introdução

26 1

A Nomeação do Projeto “Indium”

26.2

A Obtenção de Apoio Executivo

733

Dorale Products

733

735 735

775

Apêndice E Alinhamento do Guia PMBOK * 3 ao Texto

779

767

763

VISÃO GERAL

Estudos de (oso Rdoóonodos (de Kerzner/Project livro de Exercidos Relocionodo (de Kerznef/Projecí Management Management Cose Studies, 4. ed.) Workbook and PMP /(APM íxam Study Guide, 11. ed.)

Guio PMBOK - 5. ed., Secào de Referência paro o Exame de Certificação PMP

• • • • • •

• Gerenciamento do Integrado • Gerenciamento dc Escopo • Gerenciamento des Recursos Hanonos

Kcmbs Engineering WèomsMochiie Tool Canpony’ Hyten Corporotxxi Mocon, Inc Coíiinentel Computer Caporahon Jockson Industries

1.0

• AUtyie Choice Exom

INTRODUÇÃO

Osexecutivos enfrentarão desafios cada vez mais complexos durante a próxima década. Esses desafios serào resultados de fatores da alta escalada por salários e matérias-primas, aumento das reivindicações sindicais, pressão dos acio­ nistas e a possibilidade de alta inflação em longo prazo acompanhada de uma ligeira recessão e da incapacidade de obter empréstimos nas instituições financeiras. Essas condições ambientais já existiram antes, mas não no grau em que elas existem hoje.

No passado, os executivos tentaram aliviar o impacto dessas condições ambientais ao embarcar em programas de redução massiva de custos. Os resultados comuns des­ ses programas foram aposentadorias antecipadas, dis­ pensas e uma redução da força de trabalho por meio do desgaste. À medida que os postos de trabalho ficam va­ gos, os executivos pressionam os gerentes de linha a reali­ zar a mesma quantidade de trabalho com menos recursos, seja aumentando a eficiência ou atualizando os requisitos de desempenho para uma posição mais alta na curva de

aprendizagem. Em virtude de os custos de pessoal serem mais inflacionários do que os custos de equipamentos ou instalações, os executivos estão financiando cada vez mais projetos de bens de capital na tentativa de aumentar ou melhorar a produtividade sem aumentar a mão de obra.

Infelizmente, os executivos são um pouco limitados no que diz respeito a até onde podem ir para reduzir a força de trabalho sem incorrer em um alto risco para a lu­ cratividade corporativa. Projetos de bens de capital nem sempre são a resposta. Desse modo, os executivos estão sendo forçados a procurar em outro lugar as soluções para seus problemas. Quase todos os executivos de hoje concordam que a maioria dos problemas da empresa envolve a obtenção de um controle melhor e a utilização de recursos corpora­ tivos existentes, procurando internamente pela solu­ ção, ao invés de externamente. Como parte da tentativa de conseguir uma solução interna, os executivos estão tendo um olhar crítico para as formas com as quais as

2

Gerenciamento de Projetos

atividades corporativas são gerenciadas. O gerenciamen­ to de projetos é uma das técnicas que estão sendo consi­ deradas para essa solução. A abordagem de gerenciamento de projetos é rela­ tivamente moderna. É caracterizada por métodos de re­ estruturação da administração e adaptação de técnicas especiais de gestão, com o objetivo de obter melhor con­ trole e utilização dos recursos existentes. Quarenta anos atrás o gerenciamento de projetos estava confinado aos fornecedores do Departamento de Defesa dos Estados Unidos e às empresas de construção. Hoje, o conceito por trás do gerenciamento de projetos está sendo aplicado em diversos setores e organizações, como defesa, construção, indústrias farmacêutica e química, setor bancário, hospi­ tais, contabilidade, publicidade, direito, governos muni­ cipais e estaduais e nas Nações Unidas. O ritmo rápido das mudanças, tanto em tecnologia como no mercado, criou enorme variedade nos modelos organizacionais existentes. A estrutura tradicional é alta­ mente burocrática e a experiência tem mostrado que essa estrutura não pode responder de modo suficientemente rápido a um ambiente em constante mudança. Por isso, a estrutura tradicional deve ser substituída pelo geren­ ciamento de projetos, ou outra estrutura temporária de gestão que seja altamente orgânica e que possa responder muito rapidamente conforme as situações se apresenta­ rem internamente e externamente à empresa.

O gerenciamento de projetos tem sido amplamen­ te discutido por executivos e acadêmicos como uma das possibilidades exequíveis para modelos organizacionais futuros que poderíam integrar esforços complexos e reduzir a burocracia. Todavia, a aceitação do gerencia­ mento de projetos não tem sido fácil. Muitos executivos não estão querendo aceitar a mudança e são inflexíveis quando se trata da adaptação a um ambiente diferente. A abordagem de gerenciamento de projetos exige a renún­ cia aos modelos organizacionais tradicionais de negócios que são basicamente verticais e que enfatizam uma forte relação chefe-subordinado. 1.1

ENTENDIMENTO DO GERENCIAMENTO DE PROJETOS

Para entender o gerencia­ mento de projetos, deve-se 1.2 O que c um projeto? 1.3 O que e gerenciamento de começar com a definição de projetos? projeto. Um projeto pode ser considerado como sendo quaisquer séries de ativida­ des e tarefas que: GviaPMBOK ,5. ed.

• Possuem um objetivo específico a ser atingido dentro de determinadas especificações

• Possuem datas de início e término definidas • Possuem limites de financiamento (se aplicável) • Consomem recursos humanos e não humanos (ou seja, dinheiro, pessoas, equipamentos) • São multifuncionais (isto é, cruzam diversas linhas funcionais) O gerenciamento de projetos, em contrapartida, en­ volve cinco grupos de processos, conforme identificados no Guia PMBOK®, a saber:

• Iniciação do projeto • Seleção do melhor projeto, dados os limites de recursos • Reconhecimento dos benefícios do projeto • Elaboração de documentos para autorizar o projeto • Designação do gerente do projeto • Planejamento do projeto • Definição dos requisitos de trabalho • Definição da qualidade e da quantidade de trabalho • Definição dos recursos necessários • Programação de atividades • Avaliação dos vários riscos • Execução do projeto • Negociação dos membros da equipe do projeto • Direção e gerenciamento do trabalho • Trabalho com os membros da equipe para aju­ dá-los a se aperfeiçoar • Monitoramento e controle do projeto • Rastreamento do progresso • Comparação do resultado real com o resultado previsto • Análise das variações e impactos • Realização de ajustes • Encerramento do projeto • Verificação de que todo o trabalho foi realizado • Encerramento do contrato • Encerramento financeiro dos números ordenados • Encerramento administrativo da documentação O gerenciamento de projetos bem-sucedido pode, então, ser definido como tendo cumprido com os obje­ tivos do projeto:

• Dentro do prazo • Dentro dos custos • Conforme o nível de tecnologia/desempenho de­ sejado • Com utilização eficiente e eficaz dos recursos atri­ buídos • Quando aceito pelo cliente

3

VISÃO GERAL

Os benefícios potenciais do gerenciamento de pro­ jetos são:

• Identificação de responsabilidades funcionais para garantir que todas as atividades sejam explicadas, independentemente da rotatividade de pessoal • Redução da necessidade de reporte contínuo ■ Identificação de limites de prazo para o cronograma • Identificação de uma metodologia para a análise de compensações • Medição das realizações em comparação com os planos • Identificação antecipada de problemas para que possam ocorrer ações corretivas ■ Capacidade melhorada para realizar estimativas a serem utilizadas em planejamentos futuros • Identificar quando os objetivos não podem ser al­ cançados ou quando podem ser excedidos Infelizmente, os benefícios não podem ser obtidos sem a superação de obstáculos, como:

• Complexidade do projeto • Requisitos especiais do cliente e mudanças no escopo • Reestruturação organizacional • Riscos do projeto • Mudanças na tecnologia • Planejamento e definição de preços antecipado Gerenciamento de projetos pode ter significados di­ ferentes para pessoas diferentes. Frequentemente, as pes­ soas confundem o conceito porque possuem projetos em andamento dentro de suas empresas e acham que estão utilizando o gerenciamento de projetos para controlar es­ sas atividades. Nesses casos, a seguinte definição deve ser considerada adequada:

O gerenciamento de projetos é a arte de criar a ilusão dc que qualquer resultado provém de uma série de atos deliberados predeterminados quando, na verdade, tudo ocorreu por acaso.

Embora essa possa ser a maneira pela qual algumas empresas estão gerenciando seus projetos, isso não é ge­ renciamento de projetos. O gerenciamento de projetos busca o melhor uso dos recursos existentes fazendo o tra­ balho fluir horizontal e verticalmente dentro da empresa. Essa abordagem não destrói o fluxo de trabalho vertical e burocrático, mas simplesmente exige que as organizações de linha conversem entre si horizontalmente para que o trabalho seja realizado mais suavemente em toda a or­ ganização. O fluxo vertical Guia PMBOK , S.ed. de trabalho ainda é respon­ 1.7.2 Habilidades de sabilidade dos gerentes de gerenciamento de projetos linha. O fluxo horizontal de trabalho é responsabilidade dos gerentes de projeto e seu esforço principal é comunicar e coordenar as atividades horizontalmente entre as organizações de linha. A Figura 1-1 mostra como muitas empresas são es­ truturadas. Há sempre gargalos de “classe ou prestígio” entre os vários níveis de gestão. Há também gargalos funcionais entre unidades de trabalho da organização. Se nós sobrepusermos os gargalos de gestão aos gargalos funcionais, percebemos que as empresas são feitas de pe­ quenas ilhas operacionais que se recusam a se comunicar umas com as outras por medo de que entregar informa­ ções possa fortalecer seus oponentes. A responsabilidade do gerente de projetos é fazer essas ilhas se comunicarem de forma multifuncional em direção a objetivos e metas comuns. A seguir, temos uma definição geral do gerencia­ mento de projetos:

O gerenciamento de projetos é o planejamen­ to, a organização, a direção e o controle dos re­ cursos da empresa para um objetivo de relativo curto prazo, que foi estabelecido para concluir metas e objetivos específicos. Ademais, o geren­ ciamento de projetos utiliza a abordagem sistê­ mica de gestão por meio da alocação de pessoal funcional (hierarquia vertical) para um projeto específico (hierarquia horizontal).

Guia PMBOK-, 5. ed. 2.1.3 Estrutura organizacional

M1MSUHSA)

FIGURA 1-1 Por que os sistemas são necessários?

MIMSWÍDÀ5

.KW

4

Gerenciamento de Projetos

Essa definição requer um comentário adicional. Ge­ ralmente, considera-se que a gestão clássica tem cinco funções ou princípios:

• • • • •

Planejamento Organização Seleção de pessoal Controle Direção

Você perceberá que, nessa definição, a função de se­ leção de pessoal foi omitida. Isso foi intencional, pois o gerente de projetos não seleciona o pessoal do projeto. A seleção de pessoal é uma responsabilidade da linha. O gerente de projetos tem o direito de solicitar recursos es­ pecíficos, mas a decisão final sobre quais recursos serão enviados para o projeto é do gerente de linha.

Nós também devemos comentar o que quer dizer projeto de “relativo” curto prazo. Nem todos os setores dão a mesma definição para projeto de curto prazo. Na engenharia, o projeto pode durar de seis meses a dois anos; na construção, de três a cinco anos; na indústria de componentes nucleares, dez anos; e no ramo de seguros, duas semanas. Projetos de longo prazo que consomem recursos em tempo integral geralmente são estabelecidos como uma divisão separada (se for grande o suficiente) ou simplesmente como uma organização de linha.

A Figura 1-2 é uma representação ilustrada do ge­ renciamento de projetos. O objetivo da figura é mos­ trar que o gerenciamento de projetos tem a finalidade de gerenciar ou controlar os recursos da empresa para uma dada atividade, dentro do prazo, dentro dos custos e com o desempenho esperado. Prazos, custos e desem­ penho sâo restrições de projeto. Se o projeto for realizado para um cliente externo, então possuirá uma quarta res­ trição: bom relacionamento com o cliente. O leitor deve

perceber imediatamente que é possível gerenciar um pro­ jeto internamente dentro do prazo, dos custos e com o desempenho esperado e, em seguida, afastar o cliente de tal forma que nenhum negócio futuro acontecerá. Os exe­ cutivos geralmente selecionam gerentes de projetos base­ ados em quem é o cliente e em qual tipo de relação com o cliente será necessário.

Projetos existem para produzir entregas. A pessoa fi­ nalmente designada como gerente do projeto pode muito bem ser designada com base em tamanho, natureza e es­ copo das entregas. Entregas são resultados, ou o resultado final, seja da conclusão do projeto, seja do final de uma fase do ciclo de vida do projeto. Entregas são resultados mensuráveis e tangíveis e podem ter a forma de: • Entregas físicas: são itens físicos, como uma mesa, um protótipo ou uma parte de um equipamento. • Entregas de conteúdo: são similares às entregas físicas, mas geralmente são produtos impressos, como relatórios, estudos, comunicados ou docu­ mentação. Algumas empresas não diferenciam en­ tre entregas físicas e de conteúdo. • Entregas parciais: podem ser tanto entregas físicas como de conteúdo e evoluem progressivamente conforme o projeto avança. Um exemplo pode ser uma série de relatórios provisórios que levam até o relatório final. Um outro fator que influencia a seleção do gerente de projetos são as partes interessadas. Partes interessadas são indivíduos ou organizações que podem ser impactadas favorável ou desfavoravelmente pelo projeto. Como tal, gerentes de projetos devem fazer a interface com essas partes interessadas e várias delas podem exercer influên­ cia ou pressão sobre a direção do projeto.

Algumas partes interessadas são chamadas de partes interessadas “ativas” ou “principais” que podem ter auto­ ridade para tomar decisões durante a execução do proje­ to. Cada parte interessada pode ter seu próprio conjunto de objetivos, e isso pode colocar o gerente do projeto na posição de ter de equilibrar vários interesses de partes in­ teressadas sem criar uma situação de conflito de interesse para si mesmo. Cada empresa tem seu próprio sistema de categorização para identificar as partes interessadas. Um sistema típico pode ser:

FIGURA 1-2 Visào geral do gerenciamento de projetos.

• Partes interessadas organizacionais • Executivos • Gerentes de linha • Funcionários • Sindicatos

5

VISÃO GERAL

• Partes interessadas de produto/mercado • Clientes • Fornecedores • Comitês locais • Governos (municipal, estadual e federal) « Público em geral • Partes interessadas do mercado de capitais • Acionistas • Credores • Bancos DEFINIÇÃO DE SUCESSO DO PROJETO

1.2

Na seção anterior, defini­ mos o sucesso do projeto 2.2.3 Sucesso do projeto como a conclusão de uma atividade dentro das restrições de prazo, custos e desem­ penho. Essa foi a definição utilizada nos últimos 20 anos ou mais. Hoje, a definição de sucesso do projeto foi mo­ dificada para incluir a conclusão: Guio PMBOK , 5. ed.

Dentro do período de tempo alocado Dentro do custo orçado Noníveldeespecificaçãooudesempenhoadequado Com aceitação pelo cliente/usuário Com mudanças mínimas ou mutuamente adequa­ das no escopo • Sem atrapalhar o fluxo principal de trabalho da organização • Sem modificar a cultura da empresa • • • • •

Os três últimos elementos requerem explicações adi­ cionais. Pouquíssimos projetos são concluídos dentro de seu escopo original. Mudanças no escopo são inevitáveis e têm o potencial de destruir não apenas o moral do pro­ jeto, mas o projeto inteiro. As mudanças no escopo devem ser reduzidas ao máximo e as que são realmente neces­ sárias devem ser aprovadas tanto pelo gerente do projeto como pelo cliente/usuário.

possui um padrão cultural de abertura e honestidade no tratamento com os clientes, então esse valor cultural deve permanecer para todos os projetos, independentemente de quem ê o cliente/usuário ou de quão forte ê o desejo de sucesso do gerente do projeto. Por fim, deve ser entendido que simplesmente o fato de um projeto ser um sucesso não significa que a empre­ sa como um todo seja bem-sucedida em suas iniciativas de gerenciamento de projetos. A excelência em gerencia­ mento de projetos é definida como um fluxo contínuo de projetos gerenciados de forma bem-sucedida. Qualquer projeto pode ser orientado ao sucesso por meio de uma autoridade formal e da forte interferência de um executi­ vo. Mas, para que um fluxo contínuo de projetos bem-su­ cedidos ocorra, deve existir um firme comprometimento da empresa com o gerenciamento de projetos, e esse com­ prometimento deve ser visível. 1.3

SUCESSO, COMPENSAÇÕES E RESTRIÇÕES CONCORRENTES

Embora muitos projetos sejam concluídos com sucesso, pelo menos aos olhos das partes interessadas, o critério final pelo qual o sucesso é medido pode ser diferente do critério inicial, por causa das compensações. Como exemplo, o triângulo mostrado na Figura 1-2 representa as restrições triplas em um projeto, ou seja, tempo, custo e desempenho, em que o desempenho pode ser escopo, qualidade ou tecnologia. Estes são considerados as prin­ cipais restrições e, muitas vezes, são os critérios contra os quais o sucesso de um projeto é medido.

Gerentes de projetos devem querer gerenciar (e fa­ zer concessôes/compensações, se necessário) de tal for­ ma que o fluxo principal de trabalho da empresa não seja alterado. A maioria dos gerentes de projetos se vê como empreendedora autoempregada após a autorização do projeto, e gostaria de separar seus projetos das opera­ ções da organização-mãe. Isso nem sempre é possível. O gerente de projetos deve querer gerenciar dentro das di­ retrizes, políticas, procedimentos, regras e instruções da organização-mãe.

Hoje, sabemos que pode haver várias restrições em um projeto e, em vez de usar a terminologia das restri­ ções triplas, focamos nossa atenção nas restrições con­ correntes. Por vezes, as restrições são classificadas como primárias e secundárias. Pode haver fatores secundários, como risco, relacionamento com clientes, imagem e re­ putação, que podem nos levar a desviar dos nossos crité­ rios de sucesso originais, de tempo, custo e desempenho. Isso será abordado posteriormente na Seção 2.10. Essas alterações podem ocorrer a qualquer momento durante a vida de um projeto, podendo então causar compensa­ ções nas restrições triplas, exigindo portanto que mu­ danças sejam feitas nos critérios de sucesso. Em uma situação ideal, poderiamos realizar compensações em qualquer uma ou em todas as restrições concorrentes, de forma que critérios de sucesso aceitáveis ainda seriam satisfeitos.

Todas as companhias possuem cultura corporativa e mesmo que cada projeto seja inerentemente diverso, o gerente de projetos não deve esperar que seu pessoal designado se desvie das normas culturais. Se a empresa

Como exemplo, vamos supor que um projeto foi iniciado usando o critério de sucesso das restrições tri­ plas, como mostrado na Figura 1-3. Durante o projeto, o ambiente muda, uma nova equipe de executivos chega

6

Gerenciamento de Projetos

com suas próprias prioridades, ou uma crise corporati­ va ocorre, de forma que a credibilidade da empresa está em jogo. Neste caso, as restrições concorrentes mostra­ das na Figura 1-3 podem ser mais importantes que as restrições triplas originais. Para simplificar, na Figura 1-3 foi utilizado um triângulo para mostrar as restri­ ções concorrentes. No entanto, pode haver muito mais do que três restrições concorrentes, de forma que outra figura geométrica diferente do triângulo poderia fun­ cionar melhor. Os fatores secundários também são considerados restrições e podem ser mais importantes que as restrições primárias. Por exemplo, anos atrás, na Disneylàndia e na Disneyworld, os gerentes de projetos que projetaram e construíram as atrações nos parques temáticos tiveram seis restrições:

• • • • • •

Tempo Custo Escopo Segurança Valor estético Qualidade

Na Disney, as três últimas restrições, de segurança, valor estético e qualidade, foram consideradas restrições “travadas”, que não poderíam ser alteradas durante as compensações. Todas as compensações foram feitas em tempo, custo e escopo. Algumas restrições simplesmen­ te não podem mudar, ao passo que outras podem ter flexibilidade.

Nem todas as restrições têm a mesma importância. Por exemplo, na fase inicial de um projeto, o escopo pode ser um fator crítico e todas as compensações são feitas em tempo e custo. Durante a fase de execução do projeto, tempo e custo podem se tornar mais importantes, e então as compensações serão feitas no escopo. Uma discussão mais detalhada sobre compensações pode ser encontrada no Capítulo 16.

A INTERFACE ENTRE 0 GERENTE DE PROJETOS

1.4

E 0 GERENTE DE UNHA

Afirmamos que o gerente de projetos deve controlar os 1.7.2 Habilidades de recursos da empresa dentro gerenciamento de projetos do prazo, dos custos e do desempenho esperado. A maioria das empresas possui seis recursos: Guia PMBOK5. ed.

• • • • • •

Dinheiro Mão de obra Equipamentos Instalações Materiais Informação/tecnologia

Na verdade, o gerente de projetos não controla nenhum desses recursos diretamente, exceto talvez o di­ nheiro (isto é, o orçamento do projeto)1. Os recursos sào controlados pelos gerentes de linha, gerentes funcionais, ou, como geralmente são chamados, gerentes de recur­ sos. Os gerentes de projetos devem, portanto, negociar todos os recursos para o projeto com os gerentes de linha. Quando dizemos que os gerentes de projetos controlam recursos, na verdade queremos dizer que eles controlam os recursos (que são emprestados temporariamente a eles) por meio dos gerentes de linha. Hoje, temos uma nova geração de gerentes de projetos. Anos atrás, virtualmente todos os gerentes de projetos eram engenheiros com especializações. Essas pessoas tinham o domínio da tecnologia, em vez de ape­ nas o entendimento da tecnologia. Se o gerente de linha acreditasse que o gerente do projeto possuía de fato o do­ mínio da tecnologia, então ele permitiría aos colaborado­ res funcionais designados receber orientações do geren­ te do projeto. Em consequência, os gerentes de projetos eram solicitados para gerenciar pessoas. A maioria dos gerentes de projetos hoje tem um entendimento da tecnologia em vez do domínio da tecnologia. Como resultado, a responsabilidade pelo sucesso do projeto é hoje vista como uma responsabili­ dade compartilhada entre o gerente do projeto e todos os gerentes de linha envolvidos. G>m responsabilidade compartilhada, os gerentes de linha devem ter um bom entendimento dc gerenciamento de projetos, o que ex­ plica por que os gerentes de linha estão hoje se tornando

Aqui estamos supondo que o gerente de linha e o gerente do projeto não sào a mesma pessoa. Porém, os termos “gerente de

linha" e “gerente funcional" são utilizados indiferentemente ao

FIGURA 1-3 Restrições concorrentes.

longo do texto.

7

VISÃO GERAL

s * PMP ST 1. Os gerentes de projetos hoje devem focar mais em gerenciar as entregas do projeto em vez de fornecer orientação técnica à equipe do projeto. O gerenciamento dos recursos alocados é, na maioria das vezes, uma função de linha. Outro fato importante é que os gerentes de proje­ tos são tratados mais como gerentes de parte de um ne­ gócio do que simplesmente de um projeto e, como tal, é esperado que tenham voz nas decisões de negócios, bem como nas decisões dos projetos. Gerentes de projetos de­ vem entender os princípios do negócio. No futuro, pode ser exigido que os gerentes de projetos sejam certificados externamente pelo PMI * e internamente pela empresa sobre os processos de negócio da organização. Nos últimos anos, a rápida aceleração de tecnologia forçou o gerente de projetos a se tornar mais orientado a negócios. De acordo com Hans Thamhain:

A nova geração de líderes de negócio deve li­ dar eficazmente com o amplo espectro de de­ safios contemporâneos que focam em pressões time-to-market™2* > aceleração de tecnologias, inovação, limites de recursos, complexidades técnicas, questões sociais e étnicas, dinâmicas operacionais, custos, riscos e tecnologia em si, como resumido a seguir: • Complexidade alta, riscos altos e incertezas altas nas tarefas • Mercados, tecnologias e regulamentos muito dinâmicos • Competição intensa, mercados abertos globais • Restrição de recursos, requisitos rígidos dc desempenho • Cronogramas apertados, orientados a datas de entrega • Considerações do ciclo de vida total do projeto • Organizações complexas e vínculos multi­ funcionais • Joint ventures™', alianças e parcerias, necessi­ dade de lidar com diferentes culturas e valores organizacionais

Kn Project Management Professional (PMP). Certificação criada pelo Project Management Institute (PMI) e concedida aos

profissionais dc gerenciamento dc projetos que comprovam,

através de um exame oferecido pelo PMI. conhecimento sobre o conjunto de conhecimentos e as melhores práticas em

• Processos complexos de negócios e comuni­ dades de partes interessadas • Necessidade de melhorias contínuas, atualiza­ ções e aperfeiçoamentos • Necessidade de habilidades pessoais sofistica­ das, habilidade para lidar com conflitos, po­ der e políticas organizacionais • Aumento do impacto da TI e do e-business2 O Dr. Thamhain acredita ainda que existam mudan­ ças de paradigmas nos ambientes de negócios orientados à tecnologia que afetarão os líderes de negócios do futuro, incluindo os gerentes de projetos. De acordo com o Dr. Thamhain, estamos mudando de: • processos de trabalho majoritariamente lineares para altamente dinâmicos, orgânicos e integrados aos sistemas de gestão • eficiência para eficácia • execução de projetos para gerenciamento de proje­ tos por toda a empresa • gestão da informação para a utilização total da tec­ nologia da informação • controlegerencial para responsabilidade e a utogestão • gestão de tecnologia como parte de uma especia­ lidade funcional para gestão da tecnologia como um diferente conjunto de habilidades e status’ profissional Um outro exemplo para a necessidade de um geren­ te de projetos tornar-se mais ativamente envolvido em aspectos de negócio foi identificado por Gary Heerkens. Heerkens faz várias revelações sobre o motivo de o co­ nhecimento do negócio ter se tornado importante, algu­ mas das quais são4:

• Realmente não importa o quão bem você executa um projeto, se você está trabalhando no projeto errado! • Há momentos em que investir mais dinheiro em um projeto pode ser um bom negócio - mesmo se você exceder o orçamento original! • Há momentos em que gastar mais dinheiro em um projeto pode ser um bom negócio - mesmo se o projeto for entregue depois do prazo original! • Forçar a equipe do projeto a concordar com um prazo irreal pode não ser muito inteligente, do ponto de vista empresarial.

gerenciamento de projetos, de acordo com o Guia PMBOK®.

Maiores informações em www.pmi.org (em inglês).

Kn Termo de marketing que significa o tempo entre a concepção e Kn São uma associação de empresas, provisória ou não. realizada para

explorar

determinadas

oportunidades

THAMHAIN. H. I. Management of technology. Hoboken. NJ: Wiley, 2005. p. 3-4.

o lançamento de um produto no mercado.

de

negócio,

mantendo a personalidade jurídica das empresas envolvidas.

Ver note 2; TI IAMI IAIN; p. 28.

HERRKENS, G. The business-savvyproject manager. New York: McGraw-Hill, 2006. p. 4-8.

8

Gerenciamento de Projetos

• Um portfolio de projetos que gera um fluxo de cai­ xa positivo pode não representar a melhor oportu­ nidade de investimentos para a organização.

Neste ponto, deve ficar evidente que o gerenciamen­ to de projetos bem-sucedido é muito dependente de: • Um bom trabalho de relacionamento diário entre o gerente de projetos e os gerentes de linha que de­ signam recursos aos projetos • Habilidades de colaboradores funcionais em se re­ portar verticalmente aos gerentes de linha, ao mes­ mo tempo em que se reportam horizontalmente a um ou mais gerentes de projetos Esses dois itens tornam-se críticos. No primeiro item, colaboradores funcionais que são designados a um gerente de projetos ainda recebem orientações de seus gerentes de linha. No segundo, funcionários que se reportam a múl­ tiplos gerentes sempre favorecerão o gerente que controla seus salários. Portanto, a maioria dos gerentes de projetos parece sempre estar à mercê dos gerentes de linha.

A gestão clássica é sempre definida como um pro­ cesso pelo qual o gerente não necessariamente realiza as coisas por ele mesmo, mas alcança objetivos por meio de outros em condição de grupo. Essa definição básica também se aplica ao gerente de projetos. Além disso, um gerente de projetos deve ajudar a si mesmo. Não há nin­ guém mais para ajudá-lo. Se olharmos de perto o gerenciamento de projetos, veremos que o gerente de projetos, na verdade, trabalha para os gerentes de linha, e não vice-versa. Muitos executi­ vos não percebem isso. Eles tendem a colocar uma auréola sobre a cabeça do gerente de projetos e a oferecer-lhe um bônus na conclusão do projeto quando, de fato, o crédito deveria ser dado aos gerentes de linha, que são pressiona­ dos constantemente a fazer um melhor uso de seus recur­ sos. O gerente de projetos é simplesmente o agente por meio do qual isso é alcançado. Então, por que as empresas glorificam a posição do gerenciamento de projetos?

Para ilustrar o papel do gerente de projetos, conside­ re as restrições de prazo, custos e desempenho exibidas na Figura 1-2. Muitos gerentes funcionais, caso se deixe, re­ conheceríam apenas a restrição de desempenho: “Apenas dé-me mais $ 50.000 e mais dois meses, e eu te arranjo a tecnologia ideal”.

O gerente de projetos, como parte dessas responsa­ bilidades de comunicação, coordenação e integração, re­ corda aos gerentes de linha que também há restrições de prazo e custos no projeto. Esse é o ponto de partida para um melhor controle de recursos.

Os gerentes de projetos dependem dos gerentes de linha. Quando o gerente de projetos está com problemas, o único socorro ao qual ele pode recorrer é o gerente de linha, pois quase sempre são necessários recursos adicio­ nais para aliviar os problemas. Quando um gerente de li­ nha está com problemas, ele geralmente procura primei­ ro o gerente de projetos e solicita ou um financiamento adicional ou algum tipo de autorização para mudanças no escopo. Para ilustrar esse reladonamento de trabalho entre os gerentes de linha e de projetos, considere a seguinte situação:

Gerente do projeto (dirigindo-se ao gerente de li­ nha): “Eu tenho um problema sério. Estou considerando um sobrecusto de S 150.000 no meu projeto e preciso da sua ajuda. Eu queria que você realizasse a mesma quan­ tidade de trabalho que está programada no cronograma, porém em menos 3.000 homens-hora. Visto que sua or­ ganização é cobrada em S 60/hora, isso mais do que com­ pensaria esse sobrecusto”. Gerente de linha: “Mesmo se eu pudesse, porque deveria? Você sabe que bons gerentes de linha sempre podem fazer o trabalho aumentar para cumprir com o orçamento. Vou verificar minhas curvas de mão de obra e te dou uma posição amanhã”. No dia seguinte...

Gerente de linha: “Verifiquei minhas curvas de mão de obra e tenho trabalho suficiente para manter meu pes­ soal alocado. Eu te devolverei as 3.000 horas de que você precisa, mas lembre-se que você me deve uma!”

Vários meses depois... Gerente de linha: “Acabei de ver o planejamento do seu novo projeto que está previsto para iniciar em dois meses. Você precisará de duas pessoas do meu departa­ mento. Há dois funcionários que eu gostaria de alocar no seu projeto. Infelizmente, essas duas pessoas estão dispo­ níveis agora. Se eu não selecionar esse pessoal para o seu centro de custos agora, algum outro projeto pode sele­ cioná-lo em período integral e ele não estará disponível quando o seu projeto começar”. Gerente do projeto: “Você está querendo dizer que quer que eu o deixe ocupar o meu centro de custos, sa­ bendo que não preciso dos recursos agora?” Gerente de linha: “Isso mesmo. Tentarei encontrar outros trabalhos (e centros de custos) para eles traba­ lharem temporariamente para que o seu projeto não seja cobrado totalmente. Lembre-se de que você me deve uma”.

9

VISÃO GERAL

Gerente do projeto: “Ok Sei que te devo uma, por isso vou fazer isso por vocé. Isso nos deixa empatados?” Gerente de linha: “Claro que não! Mas vocé está no caminho certo”

Quando o relacionamento entre o gerenciamento de projetos e a gerência de linha começa a se deteriorar, o projeto quase sempre sofre. Os executivos devem promo­ ver um bom relacionamento de trabalho entre a gerência de projetos e a gerência de linha. Uma das formas mais comuns de destruir esse relacionamento é perguntar: “Quem contribui para os lucros - o gerente de linha ou o gerente de projetos?" Gerentes de projetos acham que controlam os lucros porque controlam o orçamento. Os gerentes de linha, por sua vez, argumentam que eles de­ vem alocar pessoal adequado ao orçamento, fornecer os recursos no momento desejado e supervisionar o desem­ penho. Na verdade, tanto as linhas horizontais como as verticais contribuem para os lucros. Esses tipos de con­ flitos podem destruir todo um sistema de gerenciamento de projetos. Os exemplos anteriores devem indicar que o geren­ ciamento de projetos é muito mais comportamental do que quantitativo. O gerenciamento de projetos eficaz exige um entendimento de:

• Ferramentas e técnicas quantitativas • Estruturas organizacionais • Comportamento organizacional

1.5

DEFINIÇÃO DO PAPEL DO GERENTE DE PROJETOS

O gerente de projetos é o responsável pela coordena­ 2.2.1 Rirlrs interessadas Capitulo 4 gerenciamento da ção e integração das ativi­ Integração do Projeto dades por meio das várias linhas funcionais. As atividades de integração realizadas pelo gerente de projetos inclui: Guia PMBOK ,5. ed.

• Integração das atividades necessárias para desen­ volver um plano de projeto • Integração das atividades necessárias para execu­ tar o plano • Integração das atividades necessárias para realizar modificações no plano Essas responsabilidades integradoras são ilustradas na Figura 1-4, em que o gerente de projetos deve converter as entradas (isto é, recursos) em resultados de produtos, servi­ ços e, finalmente, lucros. Para fazer isso, o gerente de projetos precisa de ótimas habilidades interpessoais e de comunica­ ção, de deve se familiarizar com as operações de cada orga­ nização de linha e deve conhecer as tecnologias utilizadas. Guia PMBOK-, 5. ed. Capítulo 4 gerenciamento da

Integração do Projeto

Gerenciamento do Integração

•Ccptd•KcraiM--------------

Entradas

•fíMpcmatlB

•lwofc

FIGURA 2-12 Sucesso: ponto ou cubo?

Outro fator a considerar é que podem existir ambas as definições, primárias e secundárias de sucesso, confor­ me mostra a Tabela 2-5. As definições primárias de suces­ so sào vistas pelos olhos do cliente. As definições secun­ dárias do sucesso geralmente são benefícios intemos. Se atingir 86% das especificações for aceitável para o cliente e trabalhos posteriores forem recebidos, então o projeto original pode muito bem ser considerado um sucesso. TABELA 2-5 Fatores de sucesso

Secundários

Primários • Dentro do prazo

• Tícbdhos postenores desse dierte

• Dentre dos custos

• Utdizaf o none do diente como uno referência en suo herotura

• Daitrc dos hmrtes de

quabdede • Acerto pdo diente

• Comercioliraçõo de um produto • Mudanças minrnas e occrdodas no escopo • Ausência de perturboçao do fluxo pnncpd de trobdho • Ausência de mudanças do (uhutacorporatna

Os fatores críticos de sucesso identificam o que é ne­ cessário para cumprir as entregas desejadas pelo diente. Nós também podemos olhar para os indicadores chave de desem­ penho (KPI) , que medem a qualidade do processo utili­ zado para alcançar os resultados finais. Os KPls são medidas internas ou métricas que podem ser revisadas de forma peri­ ódica durante o ciclo de vida do projeto. KPls típicos incluem: • Utilização de metodologia de gerenciamento de projetos • Estabelecimento dos processos de controle • Utilização de métricas provisórias • Qualidade dos recursos designados versus planejados • Envolvimento do cliente

Os indicadores chave de desempenho respondem a questões como: Nós utilizamos corretamente a metodo­ logia? Nós mantivemos a administração informada, e em que frequência? Os recursos adequados foram designados ao projeto e foram utilizados de forma eficaz? Houve li­ ções aprendidas que poderíam precisar da atualização da metodologia para a sua utilização? Empresas excelentes em gerenciamento de projetos medem o sucesso interno e externo utilizando FCSs e KPls.

• hoc «olocoo dos reqwsrtos de se^jranço

AS VÁRIAS FACES DO FRACASSO1

• Fornecer eficiência e eficácia das operações

2.11

• Cumprimento dos exigências embientors. de sequronca e

Anteriormente declaramos que o sucesso poderia ser um cubo, em vez de um ponto. Se ficarmos dentro do cubo, mas errarmos o ponto, isso é um fracasso? Provavelmente não! A definição verdadeira de fracasso é quando os resul­ tados finais nào são os esperados, mesmo que as expecta­ tivas originais possam ou não ter sido razoáveis. Algumas vezes os clientes, ou mesmo os executivos internos, estabe­ lecem alvos para o desempenho que sào totalmente irreais, na esperança de se alcançar de 80 a 90%. Para simplificar, vamos definir fracasso como expectativas não alcançadas.

de saúde ocupoccnal • Manutenção de conduto ético • Fanecimerto de alinhamento estratégico • Akmutençoo do reputoçoo corporolrvo • Manutenção dos relações com os agências regulatórias

A definição de sucesso pode variar também de acor­ do com quem são as partes interessadas. Por exemplo, cada um, a seguir, pode ter sua própria definição do su­ cesso em um projeto:

Do termo em inglês Key Performance Indicator (KPI), que re­ Do termo em inglês Criticai Sucess Factor (CSF), que significa

presenta uma medição de desempenho.

o(s) elemento(s) necessário(s) para uma organização ou proje­

Adaptado de: GILBREATH, Robert D. Winning, at project ma­

to completar a sua missão.

nagement. New York: Wiley, 1986. p. 2-6.

48

Gerenciamento de Projetos

Com expectativas inalcançáveis, o fracasso é prati­ camente garantido, já que definimos fracasso como expec­ tativas não alcançadas. Isso é chamado de planejamento para o fracasso e é a diferença entre o que foi planejado e o que foi, de fato, realizado. O segundo componente do fra­ casso é desempenho ruim ou fracasso real. Essa é a diferen­ ça entre o que era alcançável e o que foi realmente realizado.

Fracasso percebido é a soma líquida do fracasso real e do planejamento para o fracasso. As Figuras 2-13 e 2-14 ilustram os componentes do fracasso percebido. Na Figura 2-13, o gerenciamento de projetos planejou um nível de realizações (C) menor do que o possível, dadas as circunstâncias e os recursos do projeto (D). Essa é uma situação clássica de falta de planejamento. As realizações reais (B), no entanto, ficaram abaixo do planejado. Mrlun

Reel

4-------

Plorepdo

FraawRtol

íktnçccel

Peí^õo

------- »

Fnxnssoro rffcneprwlon

FIGURA 2-13 Componentes do fracasso (planejamento pessimista).

Um caso levemente diferente é ilustrado na Figura 2-14. Aqui, planejamos realizar mais do que o possível. O planejamento para o fracasso é novamente garantido, mesmo se nenhum fracasso real ocorrer. F.m ambas as si­ tuações (excesso de planejamento e falta de planejamen­ to), o fracasso real é o mesmo, mas o fracasso percebido pode variar consideravelmente.

pela incapacidade do gerente de projetos para realizar um gerenciamento de riscos eficaz. Nos anos 1980, acreditávamos que o fracasso de um projeto era, em boa parte, um fracasso quantitativo devido a:

• • • • •

Planejamento ineficaz Programação ineficaz do cronograma Estimativas ineficazes Controle ineficaz dos custos Objetivos do projeto como “alvos móveis”

Durante os anos 1990, mudamos a nossa visão de fracasso de orientado quantitativamente para orientado qualitativamente. Um fracasso nos anos 1990 era em gra­ de parte atribuído a:

• • • • • • • • •

Baixo moral Baixa motivação Relações humanas deficitárias Baixa produtividade Falta de comprometimento dos funcionários Falta de comprometimento funcional Atrasos na resolução de problemas Muitas questões políticas não resolvidas Prioridades conflitantes entre executivos, gerentes de linha e os gerentes de projetos

Embora essas abordagens quantitativas e qualitati­ vas continuem a ser válidas até certo ponto, hoje acredi­ tamos que o maior componente do planejamento para o fracasso é o gerenciamento inadequado ou inapropriado dos riscos, ou ter uma metodologia de gerenciamento de projetos que não forneça nenhuma orientação para o ge­ renciamento dos riscos. Algumas vezes, o componente dc fracasso do geren­ ciamento de riscos não é prontamente identificado. Por exemplo, veja a Figura 2-15.0 desempenho real entregue pela contratada foi significativamente menor do que as expectativas do cliente. A diferença se deve à fraca ha­ bilidade técnica ou a uma combinação de incapacidade técnica e fraco gerenciamento de riscos? Hoje nós acredi­ tamos que seja uma combinação.

FIGURA 2*14 Componentes do fracasso (planejamento otimista).

Hoje, a maioria dos profissionais de gerenciamento de projetos foca no termo planejamento para o fracasso. Se esse termo puder ser comprimido ou mesmo elimi­ nado, então a magnitude do fracasso real, se ele ocorrer, seria diminuída. Uma boa metodologia de gerenciamento de projetos ajuda a reduzir esse termo. Nós agora acredi­ tamos que a existência desse termo se dá em grande parte

tempo

FIGURA 2-15 Planejamento dos riscos.

49

CRESCIMENTO DO GERENCIAMENTO DE PROJETOS

Quando um projeto é concluído, as empresas rea­ lizam uma revisão das lições aprendidas. Algumas delas são classificadas inadequadamente e a verdadeira razão para o evento de risco é desconhecida. /X Figura 2-16 mostra o relacionamento entre o pessoal de marketing e a equipe técnica na iniciativa de um projeto para desen­ volver um novo produto. Se o projeto é concluído com o desempenho real sendo menor do que as expectativas do cliente, será por causa do fraco gerenciamento dos ris­ cos pela equipe de avaliação técnica e de previsão ou por causa de uma fraca avaliação dos riscos pelo marketing? O relacionamento entre o marketing e o gerenciamento técnico dos riscos nem sempre é claro. A Figura 2-16 também mostra que as oportunidades de escolhas diminuem conforme nos aprofundamos no projeto. Há inúmeras oportunidades para compensações antes do estabelecimento dos objetivos finais para o pro­ jeto. Em outras palavras, se o projeto falha, pode ser por causa do momento em que os riscos foram analisados.

trole e comunicação sejam top-down'"1 e centralizados, características que não eram práticas para organizações que utilizam gerenciamento de projetos e um fluxo hori­ zontal de trabalho. O processo stage-gate eventualmente evoluiu para fases do ciclo de vida. Como as palavras em inglês sugerem, o processo é composto por estágios e portões. Os estágios são grupos de atividades que podem ser realizadas em série ou em paralelo, com base na magnitude dos riscos que a equipe do projeto pode aguentar. Os estágios são gerenciados por equipes multifuncionais. Os portões são pontos de decisão estruturados ao final de cada estágio. Bons processos de gerenciamento de projetos geralmente não possuem mais do que seis portões. Com mais de seis portões, a equipe do projeto foca muita atenção na preparação para as gate reviews (revisões de final de fase ou de encerramento do projeto), em vez de focar no gerenciamento real do projeto.

O gerenciamento de projetos é utilizado para geren­ ciar os estágios entre os portões e pode encurtar o tempo entre eles. Esse será um fator crítico de sucesso se o pro­ cesso stage-gate for utilizado no desenvolvimento e lança­ mento de novos produtos. Uma boa metodologia corpo­ rativa para o gerenciamento de projetos fornecerá listas de verificação, formulários e diretrizes para garantir que os passos críticos não sejam omitidos. As listas de verificação para as gate reviews sào cru­ ciais. Sem elas, os gerentes de projetos podem gastar ho­ ras preparando relatórios para as gate reviews. Boas listas de verificação focam em respostas para as questões:

Abwdorm

Opoítui d>ies pon Conpensaões

• • • • brntón

FIGURA 2-16 Eslratégios de mitigação disponíveis.

Gtiia PMBOK , 5. ed. 2A Cido dc vida c a organização do projeto

2.12 0 PROCESSO

.gate"*

STAGE-

Quando as empresas reco­ 2.1.1 Características do ddo de nhecem a necessidade de vida do projeto começar a desenvolver proc­ essos para o gerenciamento de projetos, o ponto de par­ tida é, normal mente, o processo stage-gate. Esse processo foi criado porque a estrutura organizacional tradicional foi concebida primeiramente para que gerenciamento, con­

Kno Em tradução literal da lingua inglesa, “estágio-portào".

De ou relativo ao sistema hierárquico que avança de uma uni­ dade individual para várias, múltiplas suhunidades. Em tradu­ ção literal, significa “de cima para baixo".

Onde estamos hoje (ou seja, em tempo e custos)? Onde vamos terminar (ou seja, em tempo e custos)? Quais são os riscos presentes e futuros? Qual assistência da administração será necessária?

Gerentes de projetos nunca podem atuar como seus próprios porteiros. Os porteiros ou são indivíduos (ou seja, patrocinadores) ou grupos de indivíduos designados pela alta administração e habilitados a fazer cumprir o processo estruturado de tomada de decisões. Os porteiros são autorizados a avaliar o desempenho atualizado frente aos critérios predeterminados e a fornecer à equipe do projeto informações adicionais técnicas e de negócio.

Os porteiros devem gostar de tomar decisões. As quatro decisões mais comuns são:

• Seguir para o próximo portão com base nos obje­ tivos originais • Seguir para o próximo portão com base nos obje­ tivos revisados • Atrasar a tomada de decisões em um portão até que sejam obtidas informações adicionais • Cancelar o projeto

50

Gerenciamento de Projetos

Os patrocinadores também devem ter a coragem de cancelar um projeto. O propósito dos portões não é ape­ nas obter autorização para continuar, mas identificar fa­ lhas cedo o bastante para que os recursos não sejam gas­ tos, mas, sim, designados a atividades mais promissoras.

dessas fases permite ao gerente de projetos e aos executi­ vos controlar melhor os recursos para atingir as metas.

Nós agora podemos identificar os três maiores bene­ fícios do processo stage-gate:

• Pesquisa e desenvolvimento • Introdução ao mercado • Crescimento • Maturidade • Declínio • Morte Hoje, não há consenso entre os setores, ou mesmo entre empresas do mesmo setor, sobre as fases do ciclo de vida de um projeto. Isso é compreensível em virtude da natureza complexa e da diversidade dos projetos.

• Fornecer estrutura para o gerenciamento de projetos • Fornecer possível padronização para o planejamen­ to, programação do cronograma e controle (ou seja, formulários, listas de verificação e diretrizes) • Permitir um processo estruturado de tomada de decisões As empresas embarcam no processo stage-gate com boas intenções, mas existem armadilhas que podem rom­ per o processo. Isso inclui:

• Designar porteiros e não habilitá-los para a toma­ da de decisões • Designar porteiros que tenham medo de cancelar um projeto • Negar o acesso a informações críticas à equipe do projeto • Permitir à equipe do projeto focar mais nos por­ tões do que nos estágios Deve ser reconhecido que o processo stage-gate nào é nem um resultado final, nem uma metodologia autossuficiente. Em vez disso, é apenas um de vários processos que fornecem estrutura para a metodologia global de ge­ renciamento de projetos.

Hoje, o processo stage-gate parece ter sido substituído por fases do ciclo de vida. Embora haja alguma verdade nisso, esse processo está retornando. Como ele foca mais na tomada de decisões do que nas fases do ciclo de vida, está sendo utilizado como uma ferramenta interna, de tomada de decisões, dentro dc cada uma das fases do ci­ clo de vida. A vantagem é que, enquanto as fases do ciclo de vida sào as mesmas para todos os projetos, o proces­ so stage-gate pode ser feito sob medida para cada projeto para facilitar a tomada de decisões e o gerenciamento dos riscos. O processo stage-gate é agora uma parte integrante do gerenciamento de projetos, enquanto anteriormente era utilizado primeiramente para esforços de desenvolvi­ mento de novos produtos. 2.13 CICLOS DE VIDA DO PROJETO

Todo programa, projeto ouõproduto possui certas fases 2.4 Ciclos dc vida do projeto de desenvolvimento conhe­ cidas como fases do ciclo de vida. Um entendimento claro Guia PMBOK', 5. ed.

Durante os últimos anos, tem havido concordância, ao menos parcial, sobre as fases do ciclo de vida de um produto. Elas incluem:

As definições teóricas sobre as fases do ciclo de vida de um sistema podem ser aplicadas ao projeto. Essas fases incluem:

• • • • •

Conceituai Planejamento Testes Implementação Encerramento

A primeira fase, a conceituai, inclui a avaliação pre­ liminar de uma ideia. O mais importante nessa fase é a análise preliminar de riscos e o impacto resultante nos requisitos de tempo, custos e desempenho, juntamente com o impacto potencial nos recursos da empresa. A fase conceituai também inclui um “primeiro corte” na viabi­ lidade do esforço. A segunda fase é a de planejamento. E, principal­ mente, um refinamento dos elementos da fase conceituai e demanda uma identificação firme dos recursos neces­ sários e o estabelecimento de prazos, custos e parâmetros realistas. Essa fase também inclui a preparação inicial da documentação necessária para apoiar o sistema. Para um projeto baseado em uma licitação, a fase conceituai in­ cluiría a decisão de licitar ou nào e a fase de planejamento incluiría o desenvolvimento do pacote total da proposta (isto é, tempo, cronograma, custos e desempenho). Devido à quantidade de estimativas envolvidas, ana­ lisar os custos do sistema durante as fases conceituai e de planejamento nào é uma tarefa fácil. Conforme ilustra­ do na Figura 2-17, a maioria dos custos de sistemas ou projetos pode ser dividida nas categorias: operacional (recorrentes), e de implementação (não recorrentes). Os custos de implementação incluem despesas únicas, como a construção de instalações, aquisição de equipamentos de computador ou planejamento detalhado. Os custos

51

CRESCIMENTO DO GERENCIAMENTO DE PROJETOS

operacionais incluem despesas recorrentes, como mão de obra. Os custos operacionais podem ser reduzidos, como mostra a Figura 2-17, se a equipe desempenhar em uma posição mais alta na curva de aprendizagem. A identifi­ cação da posição na curva de aprendizagem é vitalmente importante durante a fase de planejamento, quando po­ sições firmes de custos devem ser estabelecidas. F. claro, nem sempre é possível saber quais indivíduos estarão dis­ poníveis ou o quão antecipadamente eles desempenharão em uma posição mais alta na curva de aprendizagem.

A terceira fase - de testes - é predominantemente um esforço de testes e de padronização final para que as operações possam começar. Quase toda a documentação deve estar completa nessa fase. A quarta fase é a de implementação, que integra o produto ou serviço do projeto na organização existente. Se o projeto foi desenvolvido para o estabelecimento de um produto para comercialização, então essa fase in­ cluiría as fases do ciclo de vida do produto: introdução no mercado, crescimento, maturidade e parte da fase de declínio. A fase final é o encerramento e inclui a realocação dos recursos. Considere uma empresa que vende produtos. Conforme um produto entra nas fases de seu ciclo de vida de declínio e morte (ou seja, fase de desinvestimento de um sistema), novos produtos ou projetos devem ser esta­ belecidos. Essa empresa demandaria, portanto, um fluxo contínuo de projetos para sobreviver, como ilustrado na Figura 2-19. Conforme os projetos AeB entram em de­ clínio, novos esforços (projeto C) devem ser desenvolvi­ dos para a realocação de recursos. Em uma situação ideal, esses novos projetos serão estabelecidos em uma taxa, cuja receita total aumentará e o crescimento da empresa será claramente visível.

Uma vez determinado o custo total aproximado do projeto, uma análise de custo-benefício deve ser con­ duzida (veja Figura 2-18) para determinar se o valor estimado das informações obtidas do sistema excede os custos de se obtê-las. Essa análise é frequentemente in­ cluída como parte do estudo de viabilidade. Há várias situações, como nas licitações, onde o estudo de viabili­ dade é, na realidade, composto pelas fases conceituai e de definição. Por causa dos custos que podem ser incorridos durante essas duas fases, a aprovação do alto escalão é quase sempre necessária antes da iniciação de tal estudo de viabilidade.

FIGURA 2-19 Um fluxo de projetos.

A fase de encerramento avalia os esforços do sistema total e serve de entrada para as fases conceituais de novos projetos e sistemas. Essa fase final também tem um im­ pacto em outros projetos em andamento com relação à identificação de prioridades. FIGURA 2-18 Análise custo-benefício.

Até agora não houve tentativa em identificar o tama­ nho de um projeto ou sistema. Grandes projetos geralmente

52

Gerenciamento de Projetos

demandam pessoal em tempo integral, enquanto que em projetos pequenos, embora passem pelas mesmas fases do ciclo de vida, podem demandar apenas pessoal em tempo parcial. Isso quer dizer que um indivíduo pode ser responsável por vários projetos e, possivelmente, com cada projeto existindo em uma fase diferente do ciclo de vida. As questões a seguir devem ser consideradas no ge­ renciamento de vários projetos: • Os objetivos dos projetos são os mesmos? • Para o bem do projeto? • Para o bem da empresa? • Há distinção entre projetos grandes e pequenos? • Como lidamos com prioridades conflitantes? • Prioridades críticas versus projetos críticos • Prioridades críticas versus projetos não críticos • Prioridades não críticas versus projetos não críticos

A Tabela 2-6 identifica as várias fases do ciclo de vida que são comumente utilizadas. Mesmo nos setores maduros em gerenciamento de projetos como constru­ ção, alguém podería pesquisar dez empresas diferentes de construção e encontraria dez definições diferentes para as fases do ciclo de vida. TABELA 2-6 Definições de fases do ciclo de vida

Engenharia

Fabricação

Desenvolvimento

• Imodizocõc • Fcmxxão

• Coíxeitual

• Defimcoo

• Planejamento

• Acúmulo

• Pnncipd

• Produção

• Conclusão

• Desccnlinuocào gradual • Auditonofind

Construção

de Software

• Plonepmento.coleta de dodos e procedmentos

• Estudos e engenharia

• Definição e

básica

design • Imdemeitocõo

• Revtsõo principal

• Conversão

• Engenharia detalhado • Sobreposição cfa engenharia e do

Os capítulos posteriores discutem métodos de reso­ lução de conflitos e estabelecimento de prioridades. As fases de um projeto e as fases de um produto são comparadas na Figura 2-20. Repare que as fases do ciclo de vida de um produto geralmente não se intercalam, enquanto as fases de um projeto podem se intercalar e, frequentemente, intercalam-se.

construção detahodo • Ccnsnucõc • festos e comissionamento

As fases do ciclo de vida para programação de compu­ tadores, como listado na Tabela 2-6, também são mostradas

PcnecnBtfo

fncrxToi»)

FIGURA 2-20 Ciclo de vido do produto/sistemo.

53

CRESCIMENTO DO GERENCIAMENTO DE PROJETOS

na Figura 2-21, que ilustra como os recursos de mão de obra se acumulam e declinam durante um projeto. Na Figura 2-21, a sigla PMO representa o método presen­ te de operações (present method of operations), e PMO’ representa o “novo” método presente de operações, após a conversão. Esse ciclo de vida seria provavelmente re­ presentativo para uma atividade de 12 meses. A maioria dos executivos preferem ciclos de vida curtos de proces­ samento de dados porque a tecnologia da computação muda rapidamente. Um executivo de uma grande empre­ sa de serviços públicos comentou que sua empresa esta­ va tendo problemas em estabelecer como terminar um projeto de programação de computadores para melho­ rar o serviço do cliente porque, no momento em que um pacote estava pronto para a implementação total, uma versão atualizada entrava em cena. Deveria-se cancelar o projeto original e iniciar-se um novo projeto? r\ solução parecia estar na definição de fases curtas de processamen­ to de dados para o ciclo de vida do projeto, talvez por meio da implementação segmentada.

FIGURA 2-21 Definiçôo do ciclo do vido de um projeto.

A alta administração é responsável pela revisão pe­ riódica de projetos principais. Isso deve ser realizado, no mínimo, na conclusão de cada fase do ciclo de vida. Mais empresas estão preparando manuais de proce­ dimentos para gerenciamento de projetos e para a estru­ turação do trabalho utilizando fases do ciclo de vida. Há vários motivos para essa tendência: • Pode ser possível o delineamento claro do trabalho a ser realizado em cada fase • A atribuição de preços e as estimativas podem ficar mais fáceis se existirem definições de trabalho bem estruturadas • Existem pontos importantes de decisão ao final de cada fase do ciclo de vida, de modo que é possível o financiamento incrementai

Para finalizar, o leitor deve ficar ciente de que nem todos os projetos podem ser simplesmente transpostos para as fases do ciclo de vida (por exemplo, projetos de P&D). Pode ser possível (mesmo na mesma empresa) que existam definições diferentes das fases do ciclo de vida, por causa da extensão e da complexidade do cronograma, ou apenas da dificuldade em gerenciar as fases.

2.14

REUNIÕES DE

GATE REVIEW

(ENCERRAMENTO DO PROJETO)

Reuniões de gate review são uma forma de encerramen­ to do projeto. Elas podem resultar no encerramento de uma fase do ciclo de vida ou o encerramento de todo o projeto. As reuniões de gate review devem ser planejadas e isso inclui coleta, análise e disseminação das informações pertinentes. Isso pode ser feito de maneira eficaz com a utilização de formulários, modelos e listas de verificação.

Há duas formas de encerramento pertencentes às reuniões de gate review, encerramento contratual e en­ cerramento administrativo. O encerramento contratual precede o administrativo e significa a verificação e aceita­ ção de que todas as entregas necessárias para essa fase fo­ ram concluídas e que todos os itens de ação foram cum­ pridos. O encerramento contratual é de responsabilidade tanto do gerente do projeto quanto do administrador do contrato.

O encerramento administrativo é a atualização de todos os registros pertinentes necessários tanto para o cliente quanto para o contratado. Os clientes têm in­ teresse particular na documentação Uas-built” ou “as installed"' ", sobre quaisquer mudanças ou desvios das especificações. Também é necessário um arquivo de todas as mudanças acordadas no escopo durante o ciclo de vida do projeto. Os contratados possuem interesse em dados arquivados que incluem os registros do projeto, minu­ tas, memorandos, newsletters, documentação de geren­ ciamento das mudanças, documentação de aceitação do projeto e o histórico de auditorias para lições aprendidas e melhoria contínua. Um subconjunto do encerramento administrativo é o encerramento financeiro, que é o fechamento de todos os números de cobrança para o trabalho concluído. Embora o encerramento contratual possa já ter ocorrido, ainda po­ dem existir números de cobrança abertos para o reparo de KT'* Termos em inglês que cm português significam respectivamen­

te, em tradução literal, “como construído" e “como instalado". São utilizados na engenharia e/ou na tecnologia da informação

e referem-se à documentação que reflete o que foi efetivamente construído, incluindo todas as adaptações realizadas até a en­

trega do produto ou serviço.

54

Gerenciamento de Projetos

defeitos ou para a conclusão de documentação arquivada. O encerramento deve ser planejado, e isso inclui a defini­ ção de uma programação e de um orçamento. A Tabela 2-7 mostra as atividades para cada tipo de encerramento.

TABELA 2-7 Formos de encerramento do projeto Engenharia

Objetivo

Acate final do dente

Término do prcjetc

Quondo

Administrativa

Financeira

Documentação e ras-

Encerra os pacotes de

necbldade canplera

trabalhe compfetodos

Depois que o encer­

Durarte o protelo

ramento contratual

rpondo as pacotes de

esteio completo

trabalhe soo comple­

tados

Atindocfes

Verificação e voMoçõo

Conclusão de minutos,

Encerrar as ordens

memorandas, cernir

efe trabalho poro os

nicodos, relatórios, e

trabalhos comçietodes

tedas os outras formos de docunentaçõo Conformidade e • ‘Pode rtrôr de fado pao taefa e pode se» esoío o»e o»d

FIGURA 5-3 Matriz de responsabilidades de comunicação.

Outro exemplo de um OLR está ilustrado na Figura 5-3. Nesse caso, o OLR é usado para descrever como as comunicações internas e externas deverão ocorrer. Esse tipo de organograma pode ser usado para eliminar con­ flitos de comunicação. Considere um cliente que está in­ feliz por ter toda a sua informação filtrada pelo gerente do projeto e solicita que o seu próprio pessoal de linha seja autorizado a falar com o pessoal de linha do gerente do projeto, diretamente um a um. Você pode não ter es­ colha senão permitir isso, mas você deve se certificar de que o cliente entende que:

a decisão?” As perguntas só podem ser respondidas por meio de definições claras de autoridade, dever e responsabilidade:

• Autoridade é o direito de um indivíduo tomar as decisões necessárias para alcançar seus objetivos e deveres • Dever é a designação para a realização de um even­ to ou atividade específica • Responsabilidade é a aceitação do sucesso ou fracasso

• Os colaboradores funcionais não podem se com­ prometer com trabalhos ou recursos adicionais • Os colaboradores funcionais apresentam suas pró­ prias opiniões, e não a opinião da empresa • A política da empresa passa pelo escritório de projetos

WK tí JSI BUKtó X HK X W05

1

taumx T □ If-wiWM □! Robert» trtlttn D»» * KW» crcntíc ob pqtto c«$irttccri saAas aswkfctfn COWNTAIOS AOKKMAIS____________________________________

FIGURA 8-2 Avaliação da designação de trabalho do projeto.

FIGURA 8-4 Avaliaçõo da designação de trabalho do projeto.

A Figura 8-3 mostra um outro formulário típico que pode ser utilizado para avaliar um empregado. Em cada categoria, o funcionário é avaliado em uma escala subje­ tiva. A fim de diminuir o tempo c a burocracia, também é

Obviamente, os formulários de avaliação, como o mostrado na Figura 8-4, possuem limitações severas, as­ sim como uma comparação individual de todo o pessoal funcional do projeto é de pouco valor se os empregados forem de departamentos diferentes. Como um engenheiro de projetos pode ser comparado a um analista de custos?

MM 00 flMOWO

* w

itiuooortoino

NÚWtOOOCAKO

MSMCtoDOUHKtfO

IIIW tout OO EOrtKAM W HNMIO Alt0 WMMIO

1

1WO KSIAMt DO [MPftGAM M0 HW0

1 i i -8 -8 -8 1 1

1

1

Hireciraif: dotickb: Carofwxõts

Aftrjde (aaperax

ftbtaderàdx)

Cortèwoc ;om os lucras (orertóta odao-ós___________________________________________________

FIGURA 8-3 Avaliação da designação de trabalho do projeto.

Várias empresas estão utilizando esse formulário, atribuindo os coeficientes de importância para cada tó­ pico. Por exemplo, em um tópico de julgamento técnico, o engenheiro de projetos pode ter um coeficiente de im­ portância de 0,90, enquanto o coeficiente do analista de custos poderia ser de 0,25. Esses coeficientes podem ser revertidos para um tópico sobre a consciência dos custos. Infelizmente, tais comparações têm validade questioná­ vel, e esse tipo de formulário de avaliação é, normalmen­ te, de natureza confidencial.

Embora o gerente de projetos preencha uma ficha de avaliação, não há garantia de que o gerente funcio­ nal acreditará na avaliação dele. Sempre há situações nas quais o gerente de projetos e o gerente funcional entram em desacordo quanto à qualidade ou direção do trabalho.

Outro problema que pode existir é a situação em que o gerente de projetos é um “generalista”, digamos que, de

252

Gerenciamento de Projetos

categoria nível 7, e pede que o gerente funcional designe o seu melhor empregado para o projeto. O gerente funcio­ nal concorda com o pedido e designa seu melhor empre­ gado, um especialista de categoria 10. Uma solução para esse problema é que o gerente de projetos avalie o espe­ cialista apenas em certas categorias, como comunicações, hábitos de trabalho e resolução de problemas, mas não na área de sua especialidade técnica. Para finalizar, às vezes é discutido que os colabora­ dores funcionais devam ter algum tipo de participação indireta sobre a avaliação de um gerente de projetos. Isso levanta algumas questões interessantes sobre até onde podemos ir com o procedimento de avaliação indireta.

Muitos gerentes de remunerações e salários alegam que não podem conviver com um sistema de avaliação para funcionários de escritório e, portanto, têm tentado combinar os formulários de avaliações direta e indireta em um, como mostrado na Figura 8-5. Alguns gerentes têm ido tão longe ao ponto de adotar um formulário úni­ co para toda a empresa, independentemente de um indi­ víduo ser um funcionário de escritório ou um operário. O design do formulário de avaliação do empregado depende de qual método ou procedimento de avaliação está sendo utilizado. De um modo geral, há nove métodos disponíveis para a avaliação de pessoal:

• • • • • • • • •

Relatório de desempenho Escalas gráficas de classificação Pesquisa de campo Escolha e distribuição forçada Avaliação de incidentes críticos Administração por objetivos Abordagem de padrões de desempenho Métodos de classificação Centro de avaliação

1. fome ________________ 2. ttofcdMoieçx_____________ 3. feipxõo do nauho ________ 4. Ckro cr ürnr cnfoxo__________ 5. Cotejou DM ____________ 6- ^o» riTed« * fa rçegct: ________________________________ 7. lüddowjerôr □ Seção □ Pent. □ Own □ EikJIkj

I.

KtfORMMÕtSDOÂVMUDQg 1. fomed:o«fcixr_________________________________________ 2. NMdoorafaàr | | Seção | | Peart | | Own | IEjk/io

3.

Ctesfta o er.jepfc em:

*rn Fa

ViÁtar far

fcjT

Ccjaario de *ço«^DÍCDfaí 'ntatc ter ccm a o/ios Uxtí «I em reoçco o em P&ameito o rrmlo e é cocóe * em ttoio c -uiccrncs Cbíücoçm pd

4 (tsséçyoemp^jaoefiCDflan;»tosseus conos

S Ccoíi:ao»i>JHcfaemc«n(ao(Mi3$$«6(crtei(aàrBos

ícrofato pcnxap»

lii

De uma perspectiva da alta administração, o pro­ cesso de avaliação indireta traz com ele várias dores de cabeça. Gerentes de remunerações e salários prontamente aceitam a necessidade de utilização de diferentes formu­ lários de avaliação tanto para trabalhadores de escritório quanto para operários. Mas agora, temos uma situação em que pode haver mais de um tipo de sistema de ava­ liação apenas para trabalhadores de escritório. Aqueles funcionários que trabalham nos departamentos funcio­ nais orientados a projetos serão avaliados direta e indi­ retamente, mas com base em procedimentos formais. Os funcionários que contabilizam seu tempo em contas de overhead e departamentos não orientados a projetos po­ dem simplesmente ser avaliados por um único e direto procedimento de avaliação.

WFORWXQíSDOEW&IDO

I

6 (rvft-DS co cwifar_______________________________________

ÀSVKXl --------------------

II Scçno de :a>jrínoo I. fone_____________________________ Z foscão: □ Dwxmerfo □

□ (iKtfwo

3 Coxadãro | | Carjrdj | | ttaorfa 4 (oiwiW>b ______________________________________________

fcsrcvo _____________ ri Sn?rtxco e fcemwo horioi.Stocta

Mi. Visão geri do seteno i Espet faxões de design do sistema k Espedrações do ptograra k Prograrrocõo e lestes v. krdenertoçòo e fcememento

FIGURA 11-19 Estruturo analítica do projeto.

1

í

1 ’1 i:

1

i:

2001

*

3-

1

í[

PLANEJAMENTO

11 -45 Durante a recessão dc 1989-1993, a indústria au­ tomobilística começou a tomar medidas extremas de corte de custos por meio do downsizing * 121. Os esforços de downsizing cr iaram problemas de ge­ renciamento de projetos para os engenheiros dc projetos em plantas industriais. Com menos re­ cursos disponíveis, mais e mais trabalho teve de ser terceirizado, principalmentc para os serviços. As fábricas tinham anos de experiência em ne­ gociações de peças, mas experiência limitada nas negociações de serviços. Como resultado, os con­ tratos de serviços tiveram sobrecustos drásticos com mudanças de engenharia e desvios de cro­ nograma. Qual é o verdadeiro problema e qual é a sua recomendação dc solução?

kr i Termo em inglês paraa técnica da administraçãocontemporãnea

que implica na diminuição dos níveis hierárquicos e da burocracia dentro da organização, visando à agilidade na tomada de decisão. Em tradução literal,“achatamento”.

379 11-46 Quando trazer o gerente do projeto a bordo sempre foi um problema. Para cada uma das seguintes situações, identifique as vantagens e desvantagens. a. O gerente do projeto é trazido a bordo no início da fase conceituai, mas atua apenas como um observador. Ele nunca responde perguntas nem fornece suas idéias até que a sessão de brainstorming seja concluída. b. Quando o brainstorming for concluído du­ rante a fase conceituai, a alta administra­ ção nomeia um dos membros da equipe do brainstorming para atuar como o gerente do projeto.

TÉCNICAS DE PROGRAMAÇAO DE REDE

Estudos de (aso Relacionados (de Kerznef/Aoject

(ase 5/afes, 4. ed.) • (íOSÒxAWaliringCo/pofOfW *

• lhe IíwM Sponsor *

Livro de Exerados Relacionado (de Kerzner/frojecf Management

Guia PMBOK - 5. ed., Seção de Referência para o

Workbook ond PMF/UHf Exam study Guide. 11. ed.)

Exame de Certificação PMP'

• Gashing lhe Effort • Multiple Choke Exom • GosswotdhüdeonrimelScheádelMonogemeni

• Gerenciamento de tempo do Projeto

Buto de caso rrroòem cproce oo W do cqxtío.

12.0

INTRODUÇÃO

• Técnica de Avaliação e Revisào dc Programa (Pro­ gram Evaluation and Review Technique - PERT) • Método do Diagrama de Setas (Arrow Diagram Method - ADM) [Às vezes chamado de Método do

A administração está conti­ Guia PMBOK-, 5. ed. nuamente à procura de no­ Capitulo 6 Gerenciamento do vas e melhores técnicas de Tempo do Projeto controle para lidar com as complexidades, as massas de dados e os prazos apertados que sào característicos de setores altamente competitivos. Os gerentes também querem melhores métodos para a apresen­ tação de dados técnicos e de custos para os dientes. Guia PMBOK , 5. ed.

6.2.3.3 Lista dos marcos

As técnicas de programação ajudam a alcançar essas me­ tas. As mais comuns sào:

Caminho Crítico (Critical Path Method -CPM)]2 • Método do Diagrama de Precedência (Precedence Diagram Method - PDM) • Técnica de Avaliação e Revisão Gráfica (Graphical Evaluation and Review Technique - GERT)

Dentre as vantagens das técnicas de programação de rede, destacam-se:

• Gráficos de Gantt ou de barras • Gráficos de marcos Guia PMBOK', 5. ed. • Linha de equilíbrio1 6.3 Sequendar as atividades • Redes

• Elas formam a base para todo o planejamento e previ­ são e ajudam a administração a decidir como utilizar seus recursos para atingir metas de tempo e custos. • Elas fornecem visibilidade e permitem à adminis­ tração controlar programas “únicos”. • Elas ajudam a administração a avaliar alternativas, respondendo questões em relação a temas como:

A linha de equilíbrio é mais aplicável às operações de manufa­

tura para produção de atividades de linha. Contudo, pode ser utilizada no gerenciamento de projetos onde um número finito de entregas devem ser produzidas em um determinado período de tempo. O leitor pode encontrar mais informações sobre essa técnica em inúmeros textos sobre gestão da produção.

2

O texto usa o termo CPM ao invés de ADM. O leitor deve com­

preender que eles são intercambiáveis.

382

Gerenciamento de Projetos

• •

• • • • •

de que forma os atrasos influenciarão a conclusão do projeto, onde existem folgas entre os elementos e quais elementos são cruciais para cumprir a data de término. Elas fornecem uma base para a obtenção de dados para tomada de decisão. Elas utilizam uma chamada análise da rede do tem­ po como o método básico para determinar a mão de obra, os materiais e os requisitos de capital, bem como para fornecer um meio para verificar o progresso. Elas fornecem a estrutura básica para a comunica­ ção de informações. Elas revelam as interdependências das atividades. Elas facilitam os exercícios “e-se". Elas identificam o caminho mais longo ou os ca­ minhos críticos. Elas auxiliam na análise de riscos do cronograma.

A PERT foi desenvolvida originalmente em 1958 e 1959 para atender às necessidades da “era da engenharia maciça” em que as técnicas de Taylor e Gantt eram inaplicáveis. O Escritório de Projetos Especiais da Marinha dos Estados Unidos, preocupado com as tendências de desempenho em grandes programas de desenvolvimen­ to militar, introduziu a PERT no seu Sistema de iMísseis Polaris em 1958, após a técnica ter sido desenvolvida com o apoio da empresa de consultoria de gestão Booz, Allen e Hamilton. Desde aquela época, a técnica espalhou-se rapidamente em quase todos os setores. Quase ao mesmo tempo, a DuPont iniciou uma técnica similar conhecida como método do caminho crítico (CPM), que também se espalhou amplamente e é particularmente concentrada nos setores de construção e de processos. No início dos anos 1960, os requisitos básicos da PERT/tempo, conforme estabelecido pela Marinha fo­ ram os seguintes:

• Todas as tarefas individuais para completar um programa devem estar suficientemente claras para serem colocadas em uma rede, que inclui eventos e atividades, ou seja, segue a estrutura analítica do projeto. • Os eventos e as atividades devem ser sequenciados na rede em um conjunto muito lógico de regras básicas que permitem a determinação dos cami­ nhos crítico e subcrítico. As redes podem ter mais de cem eventos, mas nunca menos de dez. • As estimativas de tempo devem ser feitas para cada atividade em três pontos. Otimista, mais provável e pessimista. Os cálculos de tempo decorrido são estimados pela(s) pessoa(s) mais familiarizada(s) com a atividade.

• O caminho crítico e os tempos de folga são com­ putados. O caminho crítico é a sequência de ati­ vidades e eventos cuja realização exige o maior tempo. Uma grande vantagem da PERT está no seu planeja­ mento abrangente. O desenvolvimento da rede e a análise do caminho crítico revelam interdependências e problemas que não são óbvios com outros métodos de planejamen­ to. A PERT, dessa forma, determina onde o maior esforço deve ser feito para manter um projeto dentro do prazo. A segunda vantagem da PERT é que se pode deter­ minar a probabilidade de cumprimento dos prazos pelo desenvolvimento de planos alternativos. Se o tomador de decisão é estatisticamente sofisticado, ele pode analisar o desvio-padrão e a probabilidade dos dados de término bem-sucedido. Se existe um mínimo de incerteza, pode-se usar a abordagem de uma única vez e, é claro, mantendo a vantagem da análise de rede. Uma terceira vantagem é a capacidade de avaliar o efeito de mudanças no programa. Por exemplo, a PERT pode avaliar o efeito de uma mudança prevista de recur­ sos das atividades menos críticas para as atividades clas­ sificadas como prováveis pontos de gargalos. A PERT também pode avaliar o efeito de um desvio no tempo real necessário para uma atividade em comparação ao que havia sido previsto anteriormente.

Finalmente, a PER T permite que uma grande quan­ tidade de dados sofisticados seja apresentada em um dia­ grama bem organizado a partir do qual fornecedores e clientes podem tomar decisões conjuntas. A PER T, infelizmente, também possui desvantagens. A complexidade da técnica traz problemas de implemen­ tação. Existem mais exigências de dados para um siste­ ma de comunicação organizado pela PERT do que para a maioria dos outros.

Portanto, a PERT torna-se caro para se manter e é utilizado mais frequentemente em programas grandes e complexos. Várias empresas estão dando muita atenção à uti­ lidade da PERT em projetos pequenos. O resultado tem sido o desenvolvimento de procedimentos PERT/LOB, que podem fazer o seguinte:

Cortar custos e tempo do projeto Coordenar e agilizar o planejamento Eliminar o tempo ocioso Proporcionar uma melhor programação e contro­ le das atividades de subcontratação • Desenvolver melhores procedimentos de resolução de problemas

• • • •

383

TÉCNICAS DE PROGRAMAÇÃO DE REDE

■ Cortar o tempo necessário para as decisões roti­ neiras e permitir mais tempo para a tomada de decisão

3sar«a$

fe$feC»CÍU(fa

Mesmo com essas vantagens, muitas empresas de­ vem se perguntar se real mente precisam da PERT por­ que incorporá-la pode ser difícil e caro, mesmo com os pacotes de software de prateleira. As críticas à PERT incluem: Uso intensivo de tempo e trabalho Redução na capacidade de tomada de decisão Ausência de propriedade funcional nas estimativas Ausência de dados históricos para estimativas de tempo e custos • Considera que os recursos são ilimitados • Exige muito detalhamento

• • • •

le^ndc

—► Ahttóe

FIGURA 12-1 Nomenclatura padrão PERT.

As redes são compostas por eventos e atividades. Os seguintes termos são úteis no entendimento de redes:

• Evento: equivalente a um marco que indica quan­ do uma atividade inicia ou termina. • Atividade: o elemento de trabalho que deve ser realizado. • Duração: o tempo total necessário para completar a atividade. • Esforço: a quantidade de trabalho que realmente é realizado dentro da duração. Por exemplo, a dura­ ção de uma atividade pode ser de um mês, mas o esforço pode ser apenas um período de duas sema­ nas na duração. • Caminho Crítico: esse é o caminho mais longo através da rede e determina a duração do projeto. É também o mais curto espaço de tempo necessá­ rio para concluir o projeto.

Um estudo em profundidade de PF.RT demandaria um ou dois cursos por si só. A intenção deste capítulo é familiarizar o leitor com a terminologia, a capacidade e as aplicações de redes. 12.1

FUNDAMENTOS DE REDE

A maior discrepância com os gráficos Gantt, de mar­ 6.3 Sequenciar as atividades 6.3.2 Sequenciar as atividades cos ou de bolha, é a inca­ ferramentas c técnicas pacidade de mostrar as interdependências entre os eventos e atividades. Essas interdependências devem ser identificadas de modo que um plano mestre possa ser desenvolvido para fornecer uma fotografia atualizada das operações em todos os momentos. Guia PMBOK ,T ed.

As interdependências são mostradas por meio da construção de redes. A análise de rede pode fornecer in­ formações valiosas para o planejamento, a integração dos planos, os estudos do tempo, a programação e o gerencia­ mento de recursos. O objetivo principal do planejamento de rede ê eliminar a necessidade do gerenciamento de cri­ ses fornecendo uma representação pictórica do progra­ ma total. A gestão da informação a seguir pode ser obtida como uma representação de:

• • • • • • • • •

Interdependências de atividades Tempo de conclusão do projeto Impacto de inícios mais cedo Impacto de inícios mais tarde Compensações entre os recursos e o tempo Exercícios “e-se” Custo de um programa de emergência Desvios no planejamento/desempenho Avaliação de desempenho

A Figura 12-1 mostra a nomenclatura padrão para redes PERT. Os círculos representam eventos e as setas representam as atividades. Os números nos círculos sig­ nificam os eventos específicos ou realizações. O número sobre a seta especifica o tempo necessário (horas, dias, meses), para ir do evento 6 para o evento 3. Os eventos não precisam ser numerados em uma ordem específica. No entanto, o evento 6 deve ser realizado antes que o evento 3 possa ser concluído (ou iniciado). Na Figura 12-2A, o evento 26 deve ocorrer antes dos eventos 7,18 e 31. Na Figura 12-2B, o oposto é verdadeiro e os eventos 7, 18 e 31 devem ocorrer antes do evento 26. A Figura I2-2B é semelhante a portas “E” usadas nos diagramas lógicos.'

'

Os diagramas PERT podem, de fato, ser considerados diagra­ mas lógicos. Muitos dos símbolos usados na PERT foram adap­ tados da nomenclatura de fluxo lógico.

384

Gerenciamento de Projetos

Guia PMBOK', 5.ed. 6.322 Determinação de dependência

(A) Ponto de explosão

(B) toscçx FIGURA 12-2 Fontes PERT (pontos de explosõo) e absorções.

Guia PMBOK ', 5. ed. 6.3 Sequenciar as atividades

Na introdução deste capítulo, resumimos as vanta­ gens e desvantagens dos gráficos de Gantt e de marcos. Es­ ses gráficos, entretanto, podem ser usados para desenvolver a rede PERT, como mostrado na Figura 12-3. O gráfico de barras na Figura 12-3A pode ser convertido para o gráfico de marcos na Figura 12-3B. Então, definindo a relação en­ tre os eventos em barras diferentes no gráfico de marcos, podemos construir o gráfico PERT na Figura 12-3C.

PERT é basicamente uma ferramenta de planeja­ mento e controle gerencial. Ela pode ser considerada um roteiro para um determinado programa ou projeto em que todos os principais elementos (eventos) tenham sido completamente identificados juntamente com as suas inter-relações correspondentes. * Os gráficos PERT são geralmente construídos de trás para frente porque, para muitos projetos, a data final é fixa e o fornecedor tem maior flexibilidade no início do projeto.

Um dos objetivos da construção do gráfico PERT é determinar quanto tempo é necessário para completar o projeto. A PERT, portanto, utiliza o tempo como um denominador comum para analisar os elementos que influenciam diretamente o sucesso do projeto, ou seja, tempo, custos e desempenho. A construção da rede re­ quer duas entradas. Em primeiro lugar, os eventos repre­ sentam o início ou a conclusão de uma atividade? Con­ clusões de eventos são geralmente preferenciais. O passo seguinte é definir a sequência de eventos, como mostra a Tabela 12-1, que relaciona cada evento com seu ante­ cessor imediato. Grandes projetos podem ser facilmente convertidos em redes PERT, uma vez que as seguintes perguntas sejam respondidas: • Que trabalho precede imediatamente esse trabalho? • Que trabalho segue imediatamente esse trabalho? • Que trabalhos podem ser executados simul­ taneamente? A Figura 12-4 mostra uma típica rede PERT. A linha em negrito na Figura 12-4 representa o caminho crítico, que é estabelecido pelo período mais longo através do sis­ tema total de eventos. O caminho crítico é composto de eventos 1-2-3-5-6-7-8-9.0 caminho crítico é vital para o controle bem-sucedido do projeto, pois ele informa dois aspectos à gerência:

• Como não há tempo de folga em qualquer um dos eventos sobre esse caminho, qualquer desvio causará um desvio correspondente à data final do programa, a menos que esse desvio possa ser recu­ perado durante qualquer um dos eventos do fluxo (no caminho crítico).

4 FIGURA 12-3 Conversão do gráfico de barras para o gráfico PERT.

Esses eventos nos gráficos PERT podem ser divididos, ao menos, nos mesmos níveis definidos na estrutura analítica do projeto.

385

TÉCNICAS DE PROGRAMAÇÃO DE REDE

TABELA 12-1 Sequência de eventos

Atividade

Título

Predecessoras

Tempo do

Imediatas

Atividade, Semanas

1-2

A

—

1

2-3

8

A

5

2-4

c

A

2

3-5

D

B

2

3-7

E

B

2

4-5

F

c

2

4-8

6

C

3

5-6

H

D.F

2

6-7

1

H

3

7-8

J

EJ

3

8-9

K

GJ

2

• Como os eventos nesse caminho são os mais crí­ ticos para o sucesso do projeto, os gerentes devem dar atenção a esses eventos a fim de melhorar o programa total. Ao usar PERT, podemos agora identificar as datas mais cedo possíveis às quais podemos esperar que um

evento ocorra ou que uma atividade inicie ou termine.

Não há nada muito misterioso sobre esse tipo de cálculo, mas sem uma análise da rede as informações podem ser

difíceis de obter. Guio PMBOK \ 5. ed.

6.3 Scquenciar a» atividades

CcdpfcMrto

Connote reçooodo (ncio)

tempo Serrares

le^endo

Os gráficos PERT podem ser gerenciados tanto a partir dos eventos quanto das atividades. Para os níveis de 1 a 3 da Estrutura Analítica do Projeto (EAP), as prin­ cipais preocupações do gerente de projetos são os marcos, portanto, os eventos são de suma importância. Para os níveis de 4 a 6 da EAP, as preocupações do gerente do projeto são as atividades. Os princípios que nós discutimos até agora também se aplicam ao CPM. A nomenclatura é a mesma e ambas as técnicas são, muitas vezes, chamadas de métodos de diagramação de seta ou de redes de atividade-na-seta. As diferenças entre a PERT e o CPM sào: • A PER! usa três estimativas de tempo (otimista, mais provável e pessimista, como mostrado na Seção 12.7) para obter um tempo esperado. O CPM utiliza uma estimativa de tempo que representa o tempo normal (isto é, melhor precisão de estimativa com CPM). • A PERT é probabilística por natureza, baseada em uma distribuição beta para o tempo de cada ati­ vidade e uma distribuição normal de duração do tempo esperado (ver Seção 12.7). Isso nos permite calcular o “risco” de concluir um projeto. O CPM é baseado em uma única estimativa de tempo e é determinista por natureza. • Tanto a PERT como o CPM permitem o uso de atividades fantasmas para desenvolver a lógica. • A PERT é usada em projetos de P&D, cujos ris­ cos no cálculo de duração de tempo têm uma alta variabilidade. O CPM é usado para projetos de construção, que são dependentes de recursos e ba­ seados em estimativas exatas de tempo. • A PERT é utilizada em projetos como os de P&D, em que o percentual concluído é quase impossível de se determinar, com exceção das etapas concluí­ das. O CPM é utilizado em projetos como os de construção, em que o percentual concluído pode ser determinado com precisão razoável e o fatura­ mento do cliente pode ser realizado com base no percentual concluído.

Connote ossinodo

12.2

Aqjstoes de bngo prazo

—► Ccmnko(rtco

Cronogancs de fótrico Listo de malerôis Aqjsçôes de curo aivo

Pfcoosde produção

Especificação de material Atividade de ncobaao FIGURA 12-4 Rede PERT simplificado.

TÉCNICA DE AVALIAÇÃO E REVISÃO GRÁFICA (GERT)

A técnica de avaliação e re­ visão gráfica é similar à da 6.6.2. Análise da rede do PERT, mas tem a distinta cronograma vantagem de permitir la­ ços, desvios e múltiplos resultados finais do projeto. Com a PERT é possível mostrar facilmente que, se um teste falhar, teremos de repeti-lo várias vezes. Com a PERT, nào podemos mostrar que, com base nos re­ sultados de um teste, podemos selecionar um entre os Guia PMBOK’, 5. ed.

386

Gerenciamento de Projetos

vários desvios diferentes para continuar o projeto. Es­ ses problemas são facilmente superados usando GERT. |Para obter informações adicionais sobre a técnica GERT, ver: MEREDITH, Jack R.; MANTEL Jr.» Samuel J. Project management. 3. ed. New York: Wiley, 1995. p. 364-367.] 12.3

DEPENDÊNCIAS Guia PMBOK , 5. ed.

6.3 Sequencer as atividades Ô.3.2.2 Determinação de dependência

vidades A e B. Usando duas atividades fantasmas, uma da atividade A para a atividade D e outra da atividade B para a atividade D, podemos obter essa representação. Programas de software inserem o número mínimo de atividades fan­ tasmas e a direção da seta é importante. Na Figura 12-5, a seta deve estar apontada para cima. 12.4 TEMPO DE FOLGA

Existem trés tipos básicos de inter-relações ou de­ pendências:

• Dependências obrigatórias (ou seja, lógica rígida ou hard logic): são as dependências que não podem mudar, como erguer as paredes de uma casa antes de colocar o telhado. • Dependências arbitradas (ou seja, lógica preferen­ cial ou soft logic): trata-se de dependências que po­ dem ser definidas a critério do gerente do projeto ou podem simplesmente mudar de projeto para projeto. Como um exemplo, não é necessário completar toda a lista de materiais antes de iniciar as aquisições. • Dependências externas: dependências que podem estar fora do controle do gerente do projeto, como ter fornecedores em seu caminho crítico.

Às vezes, é impossível extrair dependências de rede sem

incluir atividades fantasmas. Atividades fantasmas são ativi­ dades artificiais, representadas por uma linha pontilhada e que não consomem recursos nem precisam de tempo. Elas são adicionadas à rede, simplesmente para completar a lógica. Na Figura 12-5, a atividade C é precedida apenas pela

atividade B. Agora, vamos supor que exista uma atividade D, precedida por ambas as atividades, A e B. Sem desenhar uma atividade fantasma (isto é, a linha tracejada), não há maneira de mostrar que a atividade D é precedida pelas ati-

Uma vez que existe apenas um caminho pela rede que é 6.6.2 Desenvolver o cronograma o mais longo, os outros ca­ 6.6.22 Método do caminho critico minhos devem ser de com­ primento igual ou inferior a ele. Portanto, devem existir eventos e atividades que podem ser concluídos antes do momento em que são realmente necessários. A diferença de tempo entre a data de conclusão prevista e a data para satisfazer o caminho crítico é chamada de tempo de folga. Na Figura 12-4, o evento 4 não é o caminho fundamental. Ir do evento 2 ao evento 5 pelo caminho crítico exige sete semanas tomando a rota 2-3-5. Se a rota 2-4-5 for tomada, apenas quatro semanas são necessárias. Portanto, o evento 4, que exige duas semanas para a conclusão, deve começar em qualquer lugar de zero a três semanas após a conclusão do evento 2. Durante essas três semanas, a gerência pode encontrar um outro uso para os recursos de pessoas, di­ nheiro, equipamentos e instalações necessárias para com­ pletar o evento 4. Guia PMB0KT, 5. ed.

O caminho crítico é vital para a programação e a alocação de recursos, porque o gerente do projeto, com a coordenação do gerente funcional, pode reprogramar esses eventos fora do caminho crítico para que sejam rea­ lizados durante outros períodos de tempo, quando a uti­ lização máxima dos recursos for alcançada, desde que o tempo do caminho crítico não seja prorrogado. Esse tipo de renegociação com o uso dos tempos folga prevê um melhor equilíbrio de recursos em toda a empresa e pode, eventualmente, reduzir os custos do projeto, eliminando tempo ocioso ou de espera.

A folga pode ser definida como a diferença entre a última data permitida e a data mais cedo prevista com base na nomenclatura abaixo: Tf = tempo mais cedo (data) em que um evento pode ocorrer Tl = tempo mais tarde (data) em que um evento

pode ocorrer sem estender a data de conclusão do projeto Tempo de folga = TL- Tt

O cálculo do tempo de folga é realizado para cada evento na rede, como apresentado na Figura 12-6, por meio da data de início mais cedo e a data de início mais tarde. Para o evento 1, TL - TE = 0.0 evento 1 serve de

387

TÉCNICAS DE PROGRAMAÇÃO DE REDE

ponto de referência para a rede e pode ser facilmente de­ finido como uma data de calendário. Como antes, o ca­ minho crítico é representado por uma linha em negrito. Os eventos no caminho crítico não têm folga (ou seja, 7't = TE) e fornecem os limites para os eventos em caminho não crítico.5 Como o evento 2 é crítico, TL = TE = ò + 7 = 10 para o evento5. O evento 6 termina o caminho crítico com um tempo de conclusão de 15 semanas.

O tempo mais cedo para o evento 3, que não está no caminho crítico, pode ser duas semanas (TE = 0 + 2 = 2), pressupondo-se que ele tenha iniciado o mais cedo possí­ vel. A data mais tarde permitida é obtida subtraindo-se o tempo necessário para completar a atividade dos eventos 3 a 5 pela data mais tarde do evento 5. Portanto, TL (para o evento 3) = 10-5 = 5 semanas. O evento 3 agora pode ocorrer em qualquer lugar entre as semanas 2 e 5 sem in­ terferir na data de término programada do projeto. Esse mesmo procedimento pode ser aplicado ao evento 4, nes­ se caso, Te = 6 e TL = 9. A Figura 12-6 contém uma rede PERT simples e, portanto, o cálculo do tempo de folga não é muito difícil. Para redes complexas, contendo vários caminhos, as datas de início mais cedo devem ser encontradas seguindo do início ao fim através da rede, enquanto a data de início mais tarde deve ser calculada por meio do caminho de volta, do fim para o início.

FIGURA 12-7 Comporoçõo de modelos poro um gráfico PERT para

as fases do tempo.

FIGURA 12-6 Rede com tempo de folgo.

Em virtude desses tempos de folga, as redes PERT muitas vezes não são representadas com uma escala de tempi. Os requisitos de planejamento, no entanto, po­ dem exigir que os gráficos PERT sejam reconstruídos com escalas de tempo, situação em que uma decisão deve ser tomada sobre se queremos requisitos de tempo mais cedo ou mais tarde para as variáveis de folga. Isso é mostrado na Figura 12-7 para comparação com os custos totais do programa e planejamento de mão de obra. Os requisitos de tempo mais cedo para variáveis de folga são utilizados nessa figura.

A importância de saber exatamente onde existe a fol­ ga não pode ser exagerada. O uso apropriado do tempo de folga permite um melhor desempenho técnico. Do­ nald Marquis observou que as empresas que fizeram uso adequado do tempo de folga eram 30% mais bem-sucedi­ das do que a média na conclusão de requisitos técnicos6.

Os tempos mais cedo e os tempos mais tarde po­ dem ser combinados para determinar a probabilidade de atender com sucesso ao cronograma. Uma amostra da informação necessária é mostrada na Tabela 12-2. Os tempos mais cedo e mais tarde são considerados como variáveis aleatórias. O cronograma original refere-se ao

Existem situações especiais cm que o caminho crítico pode in­ cluir alguma folga. Esses casos nào serão considerados aqui.

MARQUIS, Donald. Ways of Organizing Projects, Innovation, 1969.

5

388

Gerenciamento de Projetos

TABELA 12-2 Informação de saída do controle PERT

cronograma de ocorrências de eventos que foi estabele­ cido no início do projeto. A última coluna na Tabela 12-2 fornece a probabilidade de que o tempo mais cedo nào seja maior do que o tempo original programado para esse evento. O método exato para determinação dessa probabilidade, bem como as variações, é descrito na Se­ ção 12.5. No exemplo apresentado na Figura 12-6, os tempos mais cedo e mais tarde foram calculados para cada even­ to. Algumas pessoas preferem calcular os tempos mais cedo e mais tarde para cada atividade. Além disso, os tempos mais cedo e mais tarde foram identificados ape­ nas como a data esperada que um evento ocorra. Para fa­

zer uso pleno das capacidades do PERT/CPM, podemos identificar quatro valores: • O tempo mais cedo em que iniciar (ES - Early Start) • O tempo mais cedo em que terminar (EF - Early Finish) • O tempo mais tarde em que iniciar (15 - Late Start) • O tempo mais tarde em que terminar (LF - Late Finish)

uma atividade pode uma atividade pode uma atividade pode

Guia PMBOK , 5. ed. 6.3.2 Sequencer as atividades

lóertifxixx do ctwixk—,— Tempo de imb na» cedo

\

/ z— farpo de ranraro más cedo

- Tempo óefatriro más fede

farpo do okMdcde

—

farpo de rich rr® rode

FIGURA 12-8 Identificoçõo dc folgo.

Para calcular os tempos de início mais cedo, temos de fazer um caminho de idas” através da rede (ou seja, da esquerda para a direita). O tempo de início mais cedo de uma atividade sucessora é a última das datas de término mais cedo das predecessoras. O tempo de término mais cedo é a soma do tempo de início mais cedo e a duração da atividade.

uma atividade pode

A Figura 12-8 mostra os tempos mais cedo e mais tarde identificados com a atividade.

M1 Tradução oficial do termo em inglês. de acordo com o glossário da quarta edição do Guia PMBOK*, Forward Pass. Em citação à definição do glossário: “É o cálculo das datas de início mais cedo c dc término mais cedo para as partes incompletas de to­ das as atividades da rede.”

389

TÉCNICAS DE PROGRAMAÇÃO DE REDE

Para calcular os tempos mais tarde de cada atividade, temos de fazer um caminho de volta'ír2 através da rede com o cálculo do tempo de término mais tarde. Uma vez que o tempo da atividade é conhecido, o tempo de início mais tarde pode ser calculado subtraindo o tempo da ati­ vidade do tempo de término mais tarde. O tempo de tér­ mino mais tarde para uma atividade que entra em um nó é o tempo de início mais cedo das atividades que saem do nó. A Figura 12-9 mostra os tempos de início e o término mais cedo para uma rede típica.

A identificação do tempo de folga pode funcionar como um sistema de alerta antecipado para o gerente de projetos. Como exemplo, se o tempo de folga total disponível começa a diminuir de um período para o se­ guinte, isso poderia indicar que o trabalho está levando mais tempo do que o previsto ou é necessária mão de obra mais qualificada. Um novo caminho crítico pode estar se formando. A observação dos tempos de início e término mais cedo e mais tarde nos permite identificar a folga. Como exemplo, veja as duas situações a seguir: [20,261

[30,361

[24,30) Situação a

[25,31) Situação b

Na Situação a, a folga é facilmente identificada como quatro unidades de trabalho, onde as unidades de trabalho podem ser expressas em horas, dias, semanas ou até mes­ mo meses. Na Situação b, a folga é negativa em quatro uni­ dades de trabalho. Isso é chamado de folga negativa™.

O que pode levar a folga a ser negativa? Observe a Fi­ gura 12-10. Ao realizar um caminho de ida através de uma rede, trabalhamos da esquerda para a direita começando no marco inicial do cliente (posição 1). O caminho de vol­ ta, por outro lado, começa no marco da data final do clien­ te (posição 2) e não, como é frequentemente ensinado em sala de aula, onde o caminho de ida termina. Se o caminho de ida termina na posição 3, que é antes da data final do cliente, é possível ter folga no caminho crítico. Essa folga é, muitas vezes, chamada de tempo reserva e pode ser adi­ cionada a outras atividades ou preenchida com atividades como escrever relatório, de modo que o caminho de ida se estenderá até a data de conclusão do cliente.

Kn Tradução oficial do termo em inglês, de acordo com o glossário da quarta edição do Guia PMBOK®, Backward Pass. Em citação à definição do glossário: “É o cálculo das datas dc início mais

Guia PMBOIC, 5. ed. 63.2 Sequenciar as atividades

A (0,6)

((6,11)

I (18.21}

6(0.6)

5(14.19)

3(19.22)

FIGURA 12*9 Um típico gráfico PERT com tempos de folgo.

A folga negativa normalmente ocorre quando o ca­ minho de ida se estende para além da data final do cliente, conforme mostrado pela posição 4 na figura. No entanto, o caminho de volta é ainda medido a partir da data de conclusão do cliente, criando folga negativa. Isso é mais provável acontecer quando:

• O plano original é otimista demais, senão irrealista • A data final do cliente não é realista • Uma ou mais atividades derraparam durante a execução do projeto • Os recursos designados não possuem o nível de qualificação adequado • Os recursos necessários não estão disponíveis para uma data posterior

Em qualquer caso, a folga negativa é um indicador de alerta em que a ação corretiva é necessária para manter a data final do cliente.

Nesse ponto, é importante compreender o significa­ do físico de folga. A folga mede o quão cedo ou o quão tarde um evento pode iniciar ou terminar. Na Figura 126, os círculos representavam eventos e a folga foi medida nos eventos. Hoje, no entanto, a maioria das redes foca na atividade em vez de no evento1™, como mostrado na Figura 12-9. Para a atividade C na Figura 12-9, a folga é de oito unidades. Se a folga em uma atividade é zero, então é uma atividade do caminho crítico, como visto na ativi-

tarde e de término mais tarde para as partes incompletas de todas as atividades da rede, f determinado trabalhando-se em retrospectiva pela lógica de rede do cronograma, a partir da data de conclusão do projeto."

s 13 Em inglês negative slack ou negativefloat.

Kr* Quando a folga é calculada sobre a atividade, ela é nomialmente chamada na língua inglesa de float em vez de slack, mas a maioria dos gerentes de projetos usa os termos indistintamente.

390

Gerenciamento de Projetos

Commix) de ide

(errhode

1

2

teto de mi»

Dao de léer rx>

docfcerie

do cfemle

FIGURA 12-10 Tempo de folga.

dade F. Se a folga em um evento é zero, então o evento é do caminho crítico. Outro termo é folga máxima. A equação para a folga máxima é:

Folga máxima = término mais tarde - início mais cedo - duração

Para a atividade H na Figura 12-9, a folga máxima é de seis unidades. 12.5

REPLANEJAMENTO DA REDE

Uma vez construídos, os gráficos PERT/CPM forne­ 6.6.2 Desenvolver o cronograma 6.6.Z.7 (ximpressAo do cem a estrutura a partir da cronograma qual o planejamento deta­ lhado pode ser iniciado e os custos podem ser controlados e rastreados. Muitas iterações, porém, normalmente sào feitas durante a fase de planejamento antes que o gráfico PERT/CPM esteja concluído. A Figura 12-11 mostra esse processo de iteração. Os tempos de folga formam a base a partir da qual as iterações adicionais, ou o replanejamento da rede, podem ser realizados. O replanejamento da rede é feito tanto na concepção do programa, a fim de redu­ zir o comprimento do caminho crítico, quanto durante o programa, quando pode ocorrer o inesperado. Se tudo ocorresse de acordo com o cronograma, então, o gráfico original PERT/CPM ficaria inalterado durante a vigência do projeto. Mas, quantos programas ou projetos seguem um cronograma exato do início ao fim? Guia PMBOK ', 5.ed.

Suponha que as atividades de 1-2 e 1-3 na Figura 12-6 exijam mão de obra da mesma unidade funcional. Ao receber a solicitação do gerente de projetos, o geren­ te funcional afirma que pode reduzir a atividade 1-2 em uma semana se deslocar recursos da atividade 1-3 para a atividade 1-2. Caso isso aconteça, contudo, a atividade I -3 aumentará seu comprimento em uma semana. Ao re-

FIGURA 12-11 Processo de iteração para o desenvolvimento do

cronograma PERT.

construir a rede PERT/CPM como mostrado na Figura 12-12, o comprimento do caminho crítico é reduzido em uma semana e os eventos com folgas correspondentes são igualmente alterados. Existem duas técnicas de replanejamento de rede ba­ seadas quase inteiramente em recursos: nivelamento de recursos e alocação de recursos.

• O nivelamento de recursos é uma tentativa de eliminar 6.6.2.4 Nivelamento de recurvn os altos e baixos de mão de obra, suavizando os requi­ sitos de recursos período-a-período. A situação ideal é fazer isso sem mudar a data final. No entanto, na re­ alidade, a data final move-se e incorrem-se em custos adicionais são incorridos. • A alocação de recursos (também chamada de plane­ jamento de recursos limitados) é uma tentativa de encontrar o caminho crítico mais curto possível ba­ seado nos recursos disponíveis ou fixos. O problema com essa abordagem é que os funcionários podem não estar qualificados tecnicamente para realizar mais de uma atividade em uma rede. Guia PMBOK , 5. ed.

391

TÉCNICAS DE PROGRAMAÇÃO DE REDE

T(=2

mesmo se o tempo e o dinheiro estiverem disponíveis para o treinamento de novos funcionários, porque no término do projeto ele pode nào ter outros projetos para essas pessoas adicionais. No entanto, se o projeto é a construção de uma nova instalação, o fornecedor de mão de obra deve ser capaz de fornecer pessoal expe­

riente adicional.

FIGURA 12-12 Replanejamento de rede da Figura 12-6.

Infelizmente, nem todas as redes PERT/CPM permi­ tem uma reprogramação tão fácil de recursos. Os gerentes de projetos devem fazer todos os esforços para redistri­ buir recursos com o objetivo de reduzir o caminho críti­ co, desde que a folga nào seja intencionalmente planejada como uma válvula de segurança.

A transferência de recursos dos caminhos de folga para caminhos críticos é apenas um método para reduzir

o tempo esperado do projeto. Vários outros métodos es­ tão disponíveis: • Eliminação de algumas partes do projeto • Adição de mais recursos (ou seja, compressão) • Substituição de componentes ou atividades que • • • • ■

consomem menos tempo Paralelização de atividades Redução das atividades do caminho crítico Redução das atividades antecipadas Redução das atividades mais longas Redução das atividades mais laceis

A paralelização de atividades pode ser considerada como aceitação do risco, admitindo-se que um determi­ nado evento pode começar em paralelo com um segun­

do que, normalmente, estaria na sequência do primeiro. Isso é mostrado na Figura 12-13. Uma das maiores dores de cabeça, no início de qualquer projeto, é a aquisição de ferramentas e matérias-primas. Conforme apresentado na

Figura 12-13, quatro semanas podem ser economizadas ao enviar as ordens de compra após o término das negocia­ ções do contrato, porém, antes do período de espera de um mês, necessário para assinar o contrato. Aqui, o fornecedor corre um risco. Se o esforço for cancelado ou se a declara­ ção do trabalho mudar antes da assinatura do contrato, o cliente assume os custos dos gastos do cancelamento do

fornecedor. Esse risco é normalmente superado pela emis­ são de um documento de aquisição de longo prazo imedia­ tamente após as negociações do contrato.

Guio PMBOK \ 5. ed.

2.4 Características do ciclo de sida do projeto

• Redução das atividades que são menos dispendio­ sas para acelerar • Redução das atividades para as quais você tem mais recursos ■ Aumentar o número de horas de trabalho por dia Na situação ideal, as datas de início e fim do projeto são fixas e o desempenho dentro dessa escala de tempo deve ocorrer dentro das orientações definidas pela de­ claração de trabalho. Se o escopo do esforço precisar ser reduzido para cumprir outros requisitos, o fornecedor corre um sério risco de ter o projeto cancelado ou de nào ser mais possível atender as expectativas de desempenho.

A adição de recursos nem sempre é possível. Se as atividades que exigem esses recursos adicionais também exigem certa experiência, é possível que o fornecedor nào tenha pessoal qualificado ou experiente e deva evi­ tar o risco. O fornecedor poderá ainda rejeitar essa ideia.

legtnà

fepccp» á crtrlo conebás (crlJo ttsroà) Atard/fariwtj convxb

Fwthrteiw

FIGURA 12-13 Paralelização das atividades PERT.

392 Há dois outros tipos de risco que são comuns. Na primeira situação, a engenharia ainda não terminou o protótipo e a fábrica deve fazer o pedido do ferramenta! a fim de manter a data-limite fixada. Nesse caso, a enge­ nharia pode finalmente projetar o protótipo para ajus­ tar o ferramenta!. Na segunda situação, o subcontratado tem dificuldade de trabalhar de acordo com os blueprints originais. Para poupar tempo, o cliente pode autorizar o subcontratado a trabalhar sem os blueprints e modifica­ dos para representar o item final, conforme construído.

Em virtude da complexidade de grandes programas, o replanejamento de rede pode tomar-se uma tarefa qua­ se impossível quando analisado nas atividades do progra­ ma total. Muitas vezes, é melhor que cada departamento ou divisão desenvolva suas próprias redes PERT/CPM, sob aprovação do escritório de projetos e baseadas na estrutura analítica do projeto. Os gráficos PERT indivi­ duais são, então, integrados em um gráfico mestre para identificar os caminhos críticos do programa total, como mostra a Figura 12-14.0 leitor não deve inferir da Figu­ ra 12-14 que o departamento D não interage com outros departamentos ou que o departamento D é o único par­ ticipante desse elemento do projeto.

Gerenciamento de Projetos

12.6

ESTIMATIVA DO TEMPO DA ATIVIDADE

Determinar o tempo de­ Guia PMBOK ,5. ed.

6.5 Estimar as durações das atividades

corrido entre eventos exige que os gerentes funcionais

responsáveis avaliem a si­

tuação e apresentem as suas melhores estimativas. Os cálculos para os caminhos críticos e os tempos de folga nas seções anteriores foram baseados nessas melhores estimativas. Nessa situação ideal, o gerente funcional teria à sua

disposição um grande volume de dados históricos com os quais fazer suas estimativas. Obviamente, quanto mais

dados históricos disponíveis, mais confiável é a estima­

tiva. Muitos programas, no entanto, incluem eventos e atividades que não são repetitivos. Nesse caso, os gerentes funcionais devem apresentar as suas estimativas utilizan­ do três premissas de conclusão possíveis: • Tempo de condusão otimis­ Guia PMBOK , S. ed.

6.52.4 Estimativas de três pontos

Gráficos PERT segmentados também podem ser uti­ lizados quando um número de empresas trabalham no mesmo programa. Cada fornecedor (ou subcontratado) desenvolve o seu próprio gráfico PERT, lòma-se, então, responsabilidade do fornecedor principal integrar todos os gráficos PERT dos fornecedores e subcontratados para ga­ rantir que os requisitos do programa total sejam atingidos.

ta. Esse tempo pressupõe que tudo estará de acordo

com plano e com dificuldades mínimas. Isso deve ocorrer em cerca de 1% do tempo. • Tempo dc conclusão pessimista. Esse tempo

pressupõe que tudo nào ocorrerá de acordo com o plano e as dificuldades irão se desenvolver ao máximo. Isso também deve ocorrer em cerca de 1% do tempo. • Tempo de conclusão mais provável. Esse é o tem­ po que, na mente do gerente funcional, deve ocor­ rer com maior frequência caso esse esforço seja

comunicado constantemente.' Antes que os três tempos possam ser combinados em uma única expressão para um momento esperado, duas premissas devem ser estabdecidas. A primeira é que o des­ vio padrào, ô, é um sexto da variação do requisito de tem­ po. Essa premissa decorre da teoria da probabilidade, em que os pontos finais de uma curva sào três desvios-padrào

da média. A segunda premissa exige que a distribuição ne­ cessária da probabilidade do tempo para uma atividade seja expressa como uma distribuição beta.* *

’

• FIGURA 12-14 Divisõo do gráfico PERT mestre por departamento.

Supõc-se que o gerente funcional realiza toda a estimati­ va. O leitor deve estar ciente de que há exceções em que o escritório de programas ou de projetos faz a sua própria es­ timativa. Veja: HII.LIFR, F. S.; LIF.BER.MAN, G. J. Introduction to opera­ tions research. San Francisco: Holden-Day, 1967. p. 229.

393

TÉCNICAS DE PROGRAMAÇÃO DE REDE

Guia PMBOK , 5.ed. 6.5.2.4 Estimativas de três pontos

O tempo esperado entre os eventos pode ser extraído da expressão:

o + 4m + b

onde t = tempo esperado, a = tempo mais otimista, b = tempo mais pessimista, e m = tempo mais provável.

Por exemplo, se a = 3, b = 7 e m = 5 semanas, o tempo esperado ç deve ser de 5 semanas. Esse valor para Ç pode ser usado com o tempo da atividade entre dois eventos na construção do gráfico PERT. Esse método para obter melhores estimativas contém um alto grau de incerteza. Se mudarmos os tempos das variáveis para a = 2tb= 12 e ffi = 4 semanas, ç continuará sendo 5 semanas. O último caso, no entanto, tem um grau de incerteza muito mais elevado por causa da ampla difusão entre os tempos oti­ mista e pessimista. Deve-se tomar cuidado na avaliação de riscos dos tempos esperados. 12.7

ESTIMATIVA DO TEMPO TOTAL DO PROJETO

6Jtoim»rMx ic c íi :ra o4«dde$10K

410

Gerenciamento de Projetos

Orçamento do planejamento do projeto: semanas após a autorização

AUvi1

dode

3

2t

5

6

7

8

—

—

—

-

6.000

5.000

—

—

-

20.000

—

-

7.500

4

2000 2.000 2000

-

Aí

3.000 4.000 4.000 4.000

ÍD

2000 3.000 2500

TotolS

-

—

—

BF

-

-

-

2.000

3.000

4.000

CE

—

—

—

—

—

2.500

—

-

2500

DE

—

—

—

3.500

3.500

3.500

—

-

10.500

EF

—

—

—

—

—

—

3.000

-

3000

11.500

10.000

li li

7.000 9.000 8.500 9.500

1!

kti

3.000 3.000 15.000

Resumo de custos

Encerramento do semana

Custos de Atividade

Red

Ortomento

d. Verificação da alocação dos recursos e. Tamanho variável da equipe f. Separação (ou interrupção) de atividades g. Designação de recursos não utilizados h. Contabilização das prioridades do projeto 12-21 A programação da mão de obra departamen­ tal para um projeto é uma tarefa muito difícil, mesmo com tempo dc folga disponível. Muitos gerentes preferem fornecer mão de obra a um ritmo constante a constantemente transferir pessoas em um projeto. a. Usando as informações apresentadas a se­ guir, construa a rede PERT, identifique o ca­ minho crítico e determine o tempo de folga para cada nó.

Cumdativo até o momento

(Acima)

Custos de

Abaixo

Orçamento

Real

(Acima) Abaixo

AB

—

—

—

6.000

6.200

(200)

AC

4.000

4.500

(500)

15.000

12.500

2.500

AD

—

2.400

(2400)

7.500

7.400

100

Bf

2.000

2.800

(800)

2.000

4.500

(2.500)

DE

3.500

—

3.500

3.500

—

3.500

Toiol

9.500

9.700

(200)

34.000

30.600

3.400

a. A partir do final da semana 4, quanto tempo é necessário para completar o projeto (ou seja, o tempo para terminar)? b. No fina) da semana 4, você está acima/abaixo do orçamento, e em quanto, para o trabalho (parcial ou integral), que tenha sido concluído até a data? (Este náo é o custo para terminar.) c. Em que momento a decisão deve ser tomada para comprimir as atividades? d. Construa uma tabela única na qual os dados de custos e desempenho são mais facilmente vistos, ou modifique os quadros menciona­ dos acima. Para resolver esse problema, vocé deve fazer uma suposição sobre a relação entre percentual concluído c tempo/custos. Na tabela dc orça­ mento do planejamento do projeto, considere que o percentual concluído seja linear quanto ao tempo c não linear quanto aos custos (ou seja, o custo deve ser lido da tabela). 12-19 Os diagramas PERT podem ter mais profundi­ dade do que a EAP? 12-20 Estimar o tempo da atividade nào é uma tarefa fadl, especialmente se as suposições devem ser feitas. De­ clare se cada item identificado abaixo pode ser con­ tabilizado na construção de uma rede PERT/CPM: a. Consideração das condições meteorológicas b. Consideração das atividades de fim de semana c. Requisitos de mão de obra não nivelados

b. A rede que acabou dc criar é um diagrama departamental PERT. Construa um lote se­ manal de mão de obra, considerando que to­ das as atividades começam o mais cedo pos­ sível. (Nota: As horas extras nào podem ser usadas para encurtar o tempo dc atividade.) c. O gerente do departamento pretende designar oito pessoas em tempo integral durante o perí­ odo do projeto. No entanto, se um empregado nào for mais necessário no projeto, ele pode ser designado a outros lugares. Usando a base de oito pessoas, identifique o modo de espera (ou inativo), e os períodos de horas extras. d. Determine o modo de espera e os custos com horas extras, supondo que cada empre­ gado é pago $ 300 por semana e que as horas extras são pagas para o período e meio. Du­ rante o tempo ocioso o trabalhador tem o seu salário integral. e. Repita as partes cede tente considerar o tem­ po de folga, a fim dc suavizar a curva dc mão de obra. (Dica: algumas atividades devem co­ meçar o mais cedo possível, enquanto outras começam o mais tarde possível.) Identifique o nível dc mão dc obra ideal, dc modo a dimi­ nuir o tempo dc espera c os custos com horas extras. Suponha que todos os funcionários devem trabalhar em tempo integral. f. A sua resposta para as partes d e e mudaria se os empregados devessem permanecer du-

411

TÉCNICAS DE PROGRAMAÇÃO DE REDE

rantc toda a duração do projeto, mesmo que eles não sejam mais necessários? 12-22 Como um gerente decide se a estrutura analítica do projeto deve basear-se em um diagrama de “árvore” ou no diagrama PERT? TABELA 12-4 Dados para o gráfico CPM do projeto

Atividade

Tempo Normal

Precedente

(Semanas)

A

—

4

B

A

6

C

B.U.V.N

3

D

C

2

E

c

2

F

c

7

6

c

7

H

D,E

4

1

—

2

1

Atividade

J

I.R

K

J

1

l

X

2

M

l

1

N

M

1

0

N

2

P

0

1

0

—

4

R

0

1

S

—

1

T

—

1

U

s

2

V

T

2

W

—

tr

X

—

2

'Pemnece em Mo a d»cra do pKftfo ( Gimdoóe de opoc odnnffitfro

12-23 Usando a Tabela 12-4, desenhe o gráfico CPM para o projeto. Nesse caso, faça todas as identificações sobre as selas (atividades) em vez de nos eventos. Mostre que o caminho crítico é dc 21 semanas. Usando a Tabela 12-5, desenhe o gráfico de prece­ dência para o projeto, mostrando a inter-relações. Tente usar uma cor diferente ou sombrear o cami­ nho critico. Calcule o fluxo de caixa mínimo necessário para as primeiras quatro semanas do projeto, consideran­ do a seguinte distribuição.

Além disso, suponha que todos os custos são linea­ res com o tempo, e que o custo da atividade X deve ser gasto nas duas primeiras semanas. Prove que o fluxo de caixa mínimo é de S 92.000. 12-24 Para a rede mostrada na Figura PI2-24 com to­ dos os tempos indicando semanas, responda as seguintes perguntas: a. Qual é o impacto na data de término do projeto se a atividade B atrasar em duas semanas? b. Qual é o impacto sobre a data dc termino do projeto se a atividade F. atrasar cm uma semana? c. Qual é o impacto na data de término do projeto se a atividade D atrasar em duas semanas? d. Se o diente lhe ofereceu um bônus pela con­ clusão do projeto em 16 semanas ou menos, quais atividades você focaria primeiro como parte da análise de compressão (crashing)?

FIGURA PI 2-24

12-25 Para a rede mostrada na Figura P12-25 com to­ dos os prazos indicando semanas, responda as seguintes perguntas: a. Qual é o impacto sobre a data de término do projeto se a atividade F atrasar em sete semanas? b. Qual é o impacto sobre a data de término do projeto se a ativ idade E atrasar em uma semana? c. Qual é o impacto sobre a atividade H se a atividade C atrasar em duas semanas? d. Qual é o impacto na data de término do pro­ jeto se a atividade B atrasar em duas semanas?

Custo total para

Atividade

Coda Atividade

A-H

16.960

l-P

5.160

Q-V

40.960

W

67.200

X

22.940

FIGURA PI 2-25

412

Gerenciamento de Projetos

TABELA 12-5 Gráfico de precedência do projeto*

Semanas

Atividade

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

A B

C D

E

F G H

1 J K

l

M N

0 P

0 R S T

U V

w X ‘Desedie as devidas borras rc figure, (onáderonóo que (oda othxtóe mia o mots cedo possird («feitòque o Wgo). Tente nostra as inteMetaoonorrenTos. como em urro rede de

precedence.

12-26 Para a rede mostrada na figura PI2-26 com to­ dos os tempos indicando semanas, responda as seguintes perguntas: a. Qual é o impacto na data de término do pro­ jeto se a atividade I atrasar em trés semanas? b. Em quantas semanas a atividade D pode atrasar antes que a data de término seja prorrogada?

c. Se a atividade A atrasar cm uma semana, como a folga na atividade G será impactada? d. Se a atividade H puder ser de alguma for­ ma comprimida de sete semanas para duas semanas, talvez por meio da adiçào de um número significativo dc recursos, qual será o impacto, se houver, sobre a data de término do projeto?

413

TÉCNICAS DE PROGRAMAÇÃO DE REDE

Alividode

Durocõo

Inicio

Término

Inicio

Término

Mais Cedo

Mais Cedo

Mais Tarde

Mais Tarde

B C D E

FIGURA P12-26

F

12-27 Um gerente de projetos descobre que sua equipe negligenciou em completar o diagrama de rede para o projeto. O diagrama de rede é mostra­ do na Figura PI2-27. Entretanto, o gerente de projetos tem alguma informação disponível, cspecificamente a dc que cada atividade, iden­ tificada de A a G, possui durações diferentes en­ tre uma e sele semanas. Além disso, o tempo de folga para cada uma das atividades c conhecido como mostrado na Figura PI2-27 em ordem crescente. Duração (semanas)

1,2,3,4,5,6,7

Tempo de folga (semanas)

0,0,0,2,4,4,7

G

12-28 Um gerente de projetos descobre que sua equipe negligenciou em completar o diagrama de rede para o projeto. O diagrama de rede é mostrado na Figura PI2-28. Entretanto, o gerente dc projetos tem alguma informação disponíwl, cspecificamente a de que cada atividade, identificadas de A a G, possui durações diferentes entre uma c sete sema­ nas. Além disso, o tempo de folga para cada uma das atividades é conhecido como mostrado a seguir. Duração (semanas)

1,2,3,4,5,6,7

Tempo dc folga (semanas)

0,0,0,1,1,3,7

lénhro

FIGURA PI2-27

FIGURA PI 2-28

Usando as dicas abaixo, determine a duração de cada atividade, bem como o início mais cedo, término mais cedo, o início mais tarde e térmi­ no mais tarde para cada atividade.

Usando as dicas a seguir, determine a duração dc cada atividade, bem como o início mais cedo, o término mais cedo, o início mais tarde e o tér­ mino mais tarde para cada atividade.

Dicas 1. Atividade E está no caminho crítico. 2. O início mais cedo (ES) para a atividade F é de cin­ co semanas. 3. A duração da atividade B é de sete semanas. 4. Atividade D tem quatro semanas de folga, mas a ati­ vidade F tem uma maior quantidade de folga. 5. O termino mais cedo (EF) para a atividade G é 17 semanas. 6. O termino mais tarde (I.F) para a atividade E é 13 semanas.

Dicas a. A atividade E é a atividade dc mais longa duração c está no caminho crítico, que é o número do azar 13; e também só existe um caminho crítico. b. O término mais cedo (EF) para a atividade F é de 11 semanas. c. O início mais tarde (LS) para a atividade D é de nove semanas. d. Se a atividade A atrasar em uma semana, ela estará em um caminho crítico.

414

Gerenciamento de Projetos

Atividade

Duração

Inicio Mas Término Mais

Cedo

Início Mais

Término

Tarde

Mais Tarde

Cedo

■ FIGURA PI 2-29

Dicas 12-29 Um gerente de projetos descobre que sua equipe negligenciou em completar o diagrama de rede para o projeto. O diagrama de rede é mostrado na Figura P12-29. Entretanto, o gerente de pro­ jetos tem alguma informação disponível, espe­ cificamente a dc que cada atividade, identificada de A a G, possui durações diferentes entre uma e sete semanas. Além disso, o tempo de folga para cada uma das atividades é conhecido como mostrado a seguir:

a. Existe apenas um caminho crítico, e é o maior núme­ ro possível, dadas as durações possíveis mostradas. b. Atividade E tem a menor quantidade de folga que é maior que zero. c. O término mais cedo (EF) para a atividade A é de qua­ tro semanas, c isso não é igual ao tempo dc término mais tarde (LF). (Nota: nào há folga negativa na rede.) d. A folga na atividade C é de oito semanas. c. A duração da atividade de F é maior que a duração da atividade C por pelo menos duas semanas.

Duração (semanas)

Tempo de folga (semanas)

Usando as dicas a seguir, determine a duração dc cada atividade, bem como o início mais cedo, o termino mais cedo, o início mais tarde c o tér­ mino mais tarde para cada atividade.

ESTUDOS DE CASO

CROSBY MANUFACTURING CORPORATION “Convoquei esta reunião para resolver um grande problema com o nosso sistema de controle e gestão de custos”, comentou Wilfred Livingston, presidente. “Nós estamos passando por um inferno tentando alcançar a concorrência com os nossos procedimentos inade­ quados de relatório do sistema de controle e gestão de custos. No ano passado, fomos considerados não responsivos para três grandes contratos com o governo porque não podíamos aderir aos requisitos de relatórios financeiros do cliente. O governo demonstrou recente­ mente um interesse renovado na Crosby Manufacturing Corporation. Se formos capazes de informatizar o nosso procedimento de relatório financeiro do projeto, estare­ mos em grande forma para enfrentar a concorrência de frente. O cliente pode até dispensar os requisitos de re­ latório financeiro se mostrarmos a nossa intenção ime­ diata de mudar.”

A Crosby ^Manufacturing era uma empresa de fabri­ cação de componentes eletrônicos que gerava S 250 mi­ lhões por ano em 2005, momento em que Wilfred “Willy” Livingston se tornou presidente. Seu primeiro ato im­ portante foi o de reorganizar 700 funcionários, em uma estrutura matricial modificada. Essa reorganização foi o primeiro passo no plano de longo prazo de Livingston para obter grandes contratos governamentais. A matriz forneceu ao cliente uma política de ponto focal que as agências governamentais preferem. Depois de três anos, a matriz parecia estar funcionando. Agora, eles poderíam começar a segunda fase, uma política melhorada para os sistemas de controle e gestão de custos. Em 20 de outubro de 2007, Livingston convocou uma reunião com os gerentes de departamento de geren­ ciamento de projetos, contabilidade de custos, SIG, pro­ cessamento de dados e planejamento. Livingston: “Nós temos que substituir o nosso com­ putador atual por um modelo mais avançado de modo

415

TÉCNICAS DE PROGRAMAÇÃO DE REDE

a atualizar nossos procedimentos de relatório do sistema de controle e gestão de custos. Para que possamos cres­ cer, vamos ter de desenvolver capacidades de manutenção de dois ou até três diferentes conjuntos de registros para nossos clientes. Nosso computador atual não tem essa capacidade. Estamos falando de um esforço considerável em dinheiro, não necessariamente para impressionar os nossos clientes, mas para aumentar a nossa base de ne­ gócios e crescer. Precisamos de dados de custos semanais, ou mesmo diários, de forma a controlar melhor os nossos projetos.”

Gerente de SIG: “Acho que o primeiro passo para os processos de concepção, desenvolvimento e implementa­ ção seria o estudo de viabilidade. Eu preparei uma lista dos principais tópicos que são normalmente incluidos em um estudo de viabilidade desse tipo.” (Veja a De­ monstração 12-1.)

DEMONSTRAÇÃO 12-1 Estudo de viabilidade

DEMONSTRAÇÃO 12-2 Cronograma Típico (em meses) Prazo Normal

Prazo Comprimido

para Concluir

para Concluir

0

0

6

2

2

1

2

1

Fluxoçromos conduidos

2

2

Programas de aplicações conduidos

3

6

3

3

2

2

Documentação, se necessário

2

2

Mudonco (cnduido

22

TF

Atividade

Autaizoçõo da admristroçõo

liberação das especificações prefrrurores de sistema

Recebimento de propostos para as especificações Pedido de hadwore e software de

«tema

Recebimento de horàvore e software

de setema Testes e dcpuroç® realizados

■Isso pies-rre que zlç.irs ctsitata xdctr ser tedizodcser pocèk. err wz íeerr sene.

• Objets-os do estudo • Custos • Beneficies

Livingston: “Já preparamos uma lista de verificação

sobre como avaliar o vendedor?"

• Sotoçòo manual ou computadorizado? • Obietros do sistema

Gerente de Processamento de Dados: “Além do teste

• Requ&los de ertrodo

de 'benchmark’, eu preparei uma lista de tópicos que de­

• Requulos de soido

vemos incluir na avaliação de qualquer fornecedor (veja a

• Requisitos de processamento

Demonstração 12-3). Devemos planejar, convidar ou vi­

• Descrição prelimnar do sistema

sitar outras instalações que tenham comprado o mesmo

• Avdioçoo dos propostas de fornecedores

equipamento e ver o sistema em ação, infelizmente, vamos

• AímjIm finoncara • Conclusões

ter de nos comprometer bem cedo e começar a desenvol­

ver pacotes de software. Na verdade, usando o princípio da concorrência, devemos começar a desenvolver nossos

Livingston: “Que tipo de custos você está conside­ rando no estudo de viabilidade?” Gerente de SIG: “Os principais itens de custos incluem demandas de entrada-saída, processamento, armazenamento, capacidade, aluguéis, compras ou ar­ rendamento de um sistema, despesas não recorrentes; despesas recorrentes; custos de suprimento, requisitos de instalação e requisitos de treinamento. Vamos ter de obter muitas dessas informações do departamento de processamento de dados.” Gerente de Processamento de Dados: “Você deve se lembrar que, por um curto período de tempo, nós vamos ter dois sistemas de computadores em operação simulta­ neamente. Isso não pode ser evitado. No entanto, prepa­ rei por mim mesmo um cronograma típico (abreviado) (veja a Demonstração 12-2). Você notará a partir da co­ luna da direita que eu sou um pouco otimista quanto ao tempo que devemos levar.”

pacotes de software agora.” DEMONSTRAÇÃO 12-3 Fatores de avaliação do apoio dos

fornecedores • Dispombiídcde de hcrdware e de pacotes de software • Desempenho de hadwcre. entrego e histonco passado • ftourmdode do fornecedor e reçrstrc de serviços e suporto • hocedmentc de bakup de emergência • Dispoabitóode de programas aplicativos e suo compotblidode com os nossos outros

sistemas • Capoodode poro expansão • Docmentoçóo • DcspombiMcde de Consuhaes paro programação de sistoms e de treinamento gerd • Orem é responsarei pefcs custos de treinanento? • foco de obsolescent • Facilidade de uso

416 Livingston: “Por causa da importância desse proje­ to, eu vou violar a nossa estrutura normal e nomear Tim Emary, do nosso grupo de planejamento, como líder do projeto, tie não é tão conhecedor como vocês são em re­ lação aos computadores, mas ele sabe como definir um cronograma e conseguir que o trabalho seja feito. Eu te­ nho certeza que o seu pessoal dará todo o apoio necessá­ rio de que ele precisa. Lembrem-se, eu vou estar por trás desse projeto até o fim. Nós vamos nos reunir de novo em uma semana, momento em que eu espero ver uma lista detalhada com todos os marcos importantes, reu­ niões de equipe, reuniões de revisão de design etc., apre­ sentados e identificados. Eu gostaria que o projeto fosse concluído em 18 meses, se possível. Se há riscos no cro­ nograma, identifiquem esses riscos. Alguma pergunta?”

0 PATROCINADOR INVISÍVEL1 Plano de Fundo

Alguns executivos preferem microgerenciar projetos, en­ quanto outros têm medo de tomar decisões, pois se to­ marem a decisão errada isso poderia afetar suas carreiras. Neste estudo de caso, o presidente da empresa designou um dos vice-presidentes para atuar como patrocinador do projeto, em um projeto concebido para construir fer­ ramentas para um cliente. O patrocinador, no entanto, estava relutante em tomar quaisquer decisões. Designação do VP

A Moreland Company era muito respeitada como empre­ sa de design e fabricação de ferramental. A Moreland era orientada a projetos porque toda a sua renda vinha de projetos. A empresa também era razoavelmente madura em gestão de projetos.

Quando o vice-presidente de engenharia anterior se aposentou, a Moreland contratou um executivo de uma empresa de fabricação para substituí-lo. O novo vice-presidente de engenharia, Al Zink, tinha excelente conhecimento sobre engenharia de ferramental, mas ti­ nha trabalhado para empresas que não eram orientadas a projetos. Al tinha muito pouco conhecimento sobre gerenciamento de projetos e nunca tinha atuado como patrocinador. Em virtude da falta de experiência de Al como patrocinador, o presidente decidiu que ele deveria “pôr a mão na massa” o mais rápido possível, e designou-o como patrocinador em um projeto de médio porte. O gerente de projeto nesse projeto era Fred Cutler. Fred era um engenheiro com mais de 20 anos de experiência em design e fabricação de ferramental. Ele se reportava admi­ nistrativamente diretamente a Al Zink.

©2010 por Harold Kerzner. Reproduzido com permissão. Todos os direitos reservados.

Gerenciamento de Projetos

0 Dilema de Fred

Fred entendeu a situação: ele teria de treinar Al Zink so­ bre como atuar como patrocinador do projeto. Essa era uma nova experiência para Fred, porque subordinados não costumam treinar funcionários de alto escalão sobre como fazer seu trabalho. Será que Al Zink seria receptivo? Fred explicou o papel do patrocinador e sobre a existência de certos documentos do projeto que exigem as assinaturas tanto do gerente do projeto como do patro­ cinador. Tudo parecia estar indo bem, até que Fred infor­ mou a Al que o patrocinador do projeto é a pessoa que o presidente considera responsável pelo sucesso ou fracasso do projeto. Fred pode perceber que Al ficou bastante cha­ teado com essa afirmação. Al percebeu que o fracasso do projeto no qual ele era patrocinador poderia prejudicar sua reputação e carrei­ ra. Agora ele estava desconfortável por ter de atuar como patrocinador, mas sabia que poderia vir a ser designado como patrocinador em outros projetos. Ele também sabia que esse projeto tinha um risco um tanto elevado. Se pu­ desse atuar como patrocinador invisível, Al poderia evitar ter de tomar quaisquer decisões críticas. No primeiro encontro entre Fred e Al, no qual Al era o patrocinador, Al pediu a Fred uma cópia do cronogra­ ma do projeto. Fred respondeu:

Estou trabalhando no cronograma agora. Não posso terminá-lo até que você me diga se quer que eu organize o cronograma com base no me­ lhor tempo, menor custo ou menor risco. Al afirmou que iria pensar no assunto e retornar a Fred o mais breve possível. No meio da semana seguin­ te, Fred e Al encontraram-se no refeitório da empresa. Al perguntou novamente a Fred: “Como está indo o crono­ grama?” E Fred respondeu como antes:

Não posso terminar o cronograma até que você me diga se você que eu o organize com base no melhor tempo, no menor custo ou no menor risco. Al ficou furioso, virou-se e afastou-se de Fred. Fred já estava ficando nervoso com as reações de Al, e começou a se preocupar com o fato de que Al pudesse removê-lo como gerente de projeto. Mas Fred decidiu manter sua posição e fazer com que Al tomasse uma decisão. Na reunião semanal entre Fred e Al, mais uma vez Al fez a mesma pergunta, e mais uma vez Fred deu a mesma resposta de antes. Agora Al ficou bastante irritado e gritou:

Apenas me dê um cronograma baseado no me­ nor tempo.

417

TÉCNICAS DE PROGRAMAÇÃO DE REDE

Fred fez com que Al tomasse sua primeira decisão. Fred finalizou seu cronograma, e dois dias depois o cro­ nograma estava na mesa de Al aguardando sua assinatu­ ra. Mais uma vez, Al postergou e se recusou a assinar o cronograma. Al acreditava que, se demorasse em tomar a decisão, Fred tomaria a iniciativa e começaria a trabalhar no cronograma sem sua assinatura. Fred continuou enviando e-mails para Al, pergun­ tando quando pretendia assinar o cronograma ou, se algo não estava correto, quais mudanças precisavam ser feitas. Como esperado, Al não respondeu. Fred decidiu então que teria de pressionar Al de alguma forma a tomar deci­ sões em tempo hábil como patrocinador do projeto. Fred então enviou um e-mail a Al, dizendo: Eu lhe enviei o cronograma do projeto na semana passada. Se o cronograma não for assinado até sexta-feira, poderá haver impac­ to sobre a data de término do projeto. Caso você não responda até sexta-feira, de uma forma ou de outra, vou considerar que vocé

aprovou o cronograma e que posso começar a implementação.

O endereço de e-mail do presidente também estava incluído em cópia no e-mail. Na manhã seguinte, Fred encontrou o cronograma em sua mesa, assinado por Al Zink. PERGUNTAS

1. 2. 3. 4. 5.

6.

Por que alguns executivos se recusam a aluar como patrocinadores do projeto? Um executivo pode ser “forçado” a atuar como patrocinador? É correio que o patrocinador seja o responsável final pelo sucesso ou fracasso do projeto? As ações dc Al Zink eram ações dc alguém ten­ tando ser um patrocinador invisível? Será que Fred Cutler agiu adequadamente em tentar fezer com que Al Zink atuasse como patrocinador? Qual é o seu palpite sobre o que aconteceu com a relação de trabalho entre Al Zink e Fred Cutler?

GRÁFICOS DO PROJETO

Estudos de Coso Relocionodos (de Kerznef/Project

Livro de Exercícios Relacionado (de Kerzner/Project management

Guio PMBOK - - 5. ed, Secõo de Referencio poro o

Management Cose Studies,,4. ei)

workbook and PMP 7CAPM • ham Study Guide, 11. ed.)

Exome de Certificocóo PMP:

• None

| • Mdiifte Choke Exom

• Getencicnenio do lempo do Projeto • Getencicmento dos Comunicoções ** Projeto

13.0

INTRODUÇÃO

No Capítulo 11 definimos os passos envolvidos no esta­ belecimento de um plano de programa formal com cro­ nogramas detalhados para gerenciar todo o programa. Qualquer plano, cronogra­ ma, desenho ou especificação que será lido por mais de uma pessoa devem ser expressos em uma linguagem que seja compreendida por todos os destinatários. Guia PMBOK , 5. ei Capítulo 9 Gerenciamento do Tempo do Projeto Capítulo 10 Gerenciamento da» Comunicações do Projeto 6.7.1.4 Cronograma do projeto gráficos de barras

A situação ideal é construir gráficos e cronogramas em notação adequada que possam ser utilizados tanto para o controle interno quanto para o relatório de andamento para o diente. Infelizmente, isso é mais fácil na teoria do que na prática. Clientes e fornecedores estão interessados principalmente nos três parâmetros vitais de controle: • Tempo • Custos • Desempenho

Todos os cronogramas e gráficos devem conside­ rar esses três parâmetros e sua relação com os recursos corporativos.

As informações para garantir uma avaliação adequa­ da do projeto são geralmente obtidas por meio de quatro métodos:

• • • •

Observação direta Relatórios orais e escritos Reuniões de avaliação e intercâmbio técnico Demonstrações gráficas

As observações diretas são uma excelente ferramenta para a obtenção de informações não filtradas, mas elas podem nào ser possíveis em grandes projetos. Embora os relatórios orais e escritos sejam rotina, eles muitas vezes contêm detalhes demais ou insuficientes, e as informa­ ções importantes podem ser disfarçadas. As reuniões de avaliação e intercâmbio técnico fornecem comunicações face-a-face e podem resultar em acordo imediato sobre definições ou soluções de problemas, tais como a mudan­ ça de um cronograma. A dificuldade está na seleção dos representantes dos clientes e das organizações do fornece­ dor. Boas demonstrações gráficas tornam as informações fáceis de identificar e são os principais meios para contro­ lar custos, cronogramas e desempenho. Demonstrações gráficas adequadas podem resultar em:

420

Gerenciamento de Projetos

• Corte dos custos do projeto e redução do tempo de escala • Coordenação e expedição do planejamento • Eliminação de tempo ocioso • Obtenção de uma melhor programação e controle das atividades dos subcontratados • Desenvolvimento de melhores procedimentos de solução de problemas • Diminuição do tempo para as decisões de rotina, mas permissão de mais tempo para a tomada de decisões 13.1

RELATÓRIO PARA 0 CLIENTE

Há mais de 30 métodos vi­ suais para representar ativi­ 10.2.2.5 Rdalórios de desempenho dades. O método escolhido deve depender do público-alvo. Por exemplo, a alta ad­ ministração pode estar interessada nos custos e na inte­ gração de atividades, com muito pouco detalhamento. Gráficos resumidos normalmente servem para essa fina­ lidade. Os profissionais que estão no dia a dia, por outro lado, podem exigir considerável detalhamento. Para os clientes, a apresentação deve incluir os dados de custos e desempenho. Guia PMBOK', 5.ed.

Ao apresentar os dados de custos e desempenho, as figuras e os gráficos devem ser facilmente compreendidos e os diagramas deverão transmitir rapidamente a men­ sagem ou objetivo pretendido. Em muitas organizações, cada departamento ou divisão pode ter o seu próprio mé­ todo de mostrar as atividades do cronograma. Organi­ zações de pesquisa e desenvolvimento preferem mostrar a lógica das ações e não a integração das atividades que, normalmente, seriam representantes de uma unidade de produção.

primeira vez no início de 1900.0 gráfico de barras é um meio de mostrar as atividades ou eventos simples enre­ dados em tempo ou dinheiro. Uma atividade representa a quantidade de trabalho necessário para passar de um momento a outro. Os eventos são descritos como o ponto de início ou de término tanto para uma como para várias atividades.

Os gráficos de barras são mais comumente utili­ zados para a exibição do progresso do programa ou para a definição do trabalho específico necessário para cumprir um objetivo. Eles geralmente incluem itens como listagem das atividades, duração das atividades, datas de cronograma e o progresso até o momento. A Figura 13-1 apresenta nove atividades necessárias para iniciar uma linha de produção de um novo produto. Cada barra na figura representa uma única atividade. A Figura 13-1 é um típico gráfico de barras que seria desenvolvido pelo escritório de programas no início do programa. Os gráficos de barras são vantajosos na medida em que são simples de entender e fáceis de alterar. Eles são o meio mais simples e menos complexo de retratar o pro­ gresso (ou a ausência dele) e podem facilmente ser expan­ didos para identificar elementos específicos que possam estar tanto adiantados como atrasados no cronograma. Os gráficos de barras fornecem apenas uma des­ crição vaga de como todo o programa ou projeto reage como um sistema e possuem três grandes limitações. Primeiro, os gráficos de barras não mostram as interde­ pendências das atividades e, portanto, não representam uma “rede” de atividades. Esse relacionamento entre as atividades é fundamental para controlar os custos

A capacidade de comunicar é um pré-requisito para o gerenciamento bem-sucedido de um programa. As reuniões de avaliação do programa, as reuniões de inter­ câmbio técnico, as reuniões de síntese com o cliente e as reuniões internas de controle da gestão exigem diferentes modelos de representação do andamento do desempe­ nho atual do programa. O formato final do cronograma pode ser na forma de gráficos de barras, outros esquemas, tabelas, gráficos de bolhas ou diagramas lógicos. Estes es­ tão descritos nas seções que se seguem.

13.2

GRÁFICO DE BARRAS (GANTT)

O tipo mais comum de exi­ bição é o gráfico de barras gráficos dc barras ou gráfico de Gantt, nomea­ do por Henry Gantt, que utilizou esse procedimento pela Guia PMBOK’, 5. ed.

6.7.1.4 Cronograma do projeto -

FIGURA 13-1 Gráfico de barras para atividades únicas.

421

GRÁFICOS DO PROJETO

do programa. Sem esse relacionamento, os gráficos de barras tém pouco valor prognóstico. Por exemplo, a atividade de aquisições de longo prazo na Figura 13-1 exige que o contrato seja assinado antes que as aquisi­ ções possam começar? Os planos de produção podem ser escritos sem que a atividade de especificações de materiais seja concluída? /X segunda grande diferença é que o gráfico de barras não pode mostrar os resulta­ dos de um início mais cedo ou mais tarde da atividade. Como é que um desvio da atividade de cronogramas de fábrica na Figura 13-1 afeta a data de conclusão do programa? A atividade de cronogramas de fábrica pode começar duas semanas mais tarde do que é mostrado e ainda servir como uma entrada para a atividade lista de materiais? Qual será o resultado de um programa de compressão para concluir as atividades em 16 semanas depois da autorização, em vez das 19 semanas original­ mente planejadas? Os gráficos de barras não refletem o andamento verdadeiro do projeto porque os elementos por trás do cronograma não significam que o programa ou projeto esteja atrasado no cronograma. A terceira li­ mitação é que o gráfico de barras não mostra o grau de incerteza envolvido em realizar a atividade e, portanto, não se admite facilmente para a análise de sensibilidade. Por exemplo, qual é o menor temp) que uma atividade pode levar? Qual é o maior tempo? Qual é o tempo mé­ dio ou esperado para a conclusão da atividade? Mesmo com essas limitações, os gráficos de barras, de fato, servem como ferramentas úteis para a análise do programa. Algumas das limitações dos gráficos de barras podem ser superadas por meio da combinação de ativi­ dades únicas, como mostrado na Figura 13-2. O ponto fraco desse método é que o número representando cada uma das atividades nào indica se esse é o começo ou o fim da atividade. Portanto, os números devem representar

SWAW6 APÓS ÂAUTORIZAÇÃO

ttacos 1 Lteoçõo (to pedéfc deccrrfio 2 hotos fryers receidcs 3 Manas laebdos

FIGURA 13-3 Gráfico de barras/marcos.

eventos em vez de atividades, juntamente com a iden­ tificação apropriada. Como antes, nenhuma distinção é feita quanto a se o evento 2 deve ser concluído antes do início dos eventos 3 ou 4.0 gráfico também falha em definir claramente a relação entre as múltiplas atividades em uma única barra. Por exemplo, o evento 3 deve ser concluído antes do 5? Muitas vezes, gráficos de barras de atividades combinadas podem ser convertidos para grá­ ficos de barras de marcos colocando pequenos triângulos em locais estratégicos nas barras para indicar a conclusão de determinados objetivos dentro de cada atividade ou agrupamento de atividades, como mostrado na Figura 13-3. A definição exata de um marco difere de empresa para empresa, mas, geralmente, implica algum ponto em que a atividade principal ou começa ou termina, ou se os dados de custos se tornam críticos. Os gráficos de barras podem ser convertidos em grá­ ficos de inter-relacionamento parcial, indicando (com se­ tas) a ordem em que as atividades devem ser executadas. A Figura 13-4 representa o inter-relacionamento parcial das atividades nas Figuras 13-1 e 13-2. Um cronograma completo de inter-relacionamentos está incluído na dis­ cussão das redes PERT no Capítulo 12.

Uti

Efl

E □

IB

□

IB 1 2

1 4

1 6

1 8

□!

—1------ !------- 1--------- !------ 1------- 1 10 12 14 16 18 20

stmavis vós a mosukào

O---- ----------------- O—o i

1

6

â

l'o

1'2

14

16

Í8

SMAUSJtâAAUWMtt

(ódço (tos Ahndodes

1 Conta» neçoóado 2 Corte» cssrodo 3 jucás (te tojo prazo 4GN0pnEdeMrico 5 bslc de mlerc s

6 AqcÃkões de curto pnro 7 Espeoftoções de ircteiM» 8 Ptans de produção 9lrKd(roçD0

FIGURA 13-2 Gráfico de barras para atividades combinadas.

1 (ontntonegxato 2 CorWo cssririo 3 MÔSKÔG de kxigo poro 4 Cromgrcrras de fcbnco 5 listo de meterieis

6 Aqjmõbs de curto pioro 7 fspecfaoçoes de retens 8 tonos de prortoçoo 9 Inooboçõo

FIGURA 13-4 Gráfico de inter-relacionamento parcial.

422

Gerenciamento de Projetos

O método mais comum de apresentação de dados, tanto para o gerenciamento interno, quanto para o clien­ te, é por meio do uso de gráficos de barras. Devem ser to­ mados cuidados para não tornar as figuras tão complexas

que mais de uma interpretação possa existir. Uma grande quantidade de informações e cores pode ser incluída em gráficos de barras. /X Figura 13-5 mostra um gráfico de barras agrupadas, para a comparação de três projetos reali­ zados em anos diferentes. Ao utilizar técnicas de sombre-

amento diferentes, cada área deve ser facilmente definí­ vel e nenhum contraste maior deve existir entre as áreas sombreadas, exceto, possivelmente, para o projeto atual.

Quando as barras aparecem agrupadas em um gráfico, barras não sombreadas devem ser evitadas. Cada barra

deve ter algum tipo de sombreamento, seja com traços cruzados ou codificada por cores.

Áreas sombreadas contrastantes e áreas nào som­ breadas são utilizadas normalmente para comparar o progresso projetado com o progresso real, como mos­

FIGURA 13-6 Cronograma do rastreamento de custos e

desempenho.

velmente devido ao projeto 1. É geralmente aceitável que

a mesma técnica de sombreamento represente situações diferentes, desde que apareça a separação clara entre as regiões sombreadas, como na Figura 13-6.

Outro meio comum para a comparação de ativida­ des ou projetos é por meio do uso de gráficos de barras para a disposição das etapas. A Figura 13-7 mostra um gráfico de barras da disposição de etapas para uma divi­ são percentual dos custos para cinco projetos incluídos em um programa. A Figura 13-7 pode também ser utili­ zada para acompanhamento, por meio do sombreamento de certas partes das etapas que identificam cada projeto. No entanto, isso normalmente nào é feito, uma vez que esse tipo de disposição de etapas tende a indicar que cada etapa deva ser concluída antes de que a etapa seguinte possa começar.

trado na Figura 13-6. z\ linha da data de acompanha­

mento indica o momento em que os dados de custos/ dados de desempenho foram analisados. O projeto 1

está atrasado, o 2 está adiantado no cronograma e o 3 está na previsão. Infelizmente, a parte superior da Figu­ ra 13-6 não indica os custos atribuídos para o andamen­

to dos três projetos. Ao traçar o custo total do programa em relação ao mesmo eixo de tempo (como mostrado na

Figura 13-6), uma comparação entre custos e desempe­

nho pode ser feita. Na seção superior da Figura 13-6, é impossível dizer a posição atual de custos do programa. A partir da seção inferior, no entanto, torna-se evidente que

FIGURA 13-7 Gráfico de barras da disposição de etapas para o

o programa está caminhando para um sobrecusto, possi­

custo total como percentual dos cinco projetos do programa.

423

GRÁFICOS DO PROJETO

CUSTO TOTAL DO usio.ooo:

CUSTO MS WBASRMS (I$I,000)

WftHil

(MMADOf zet-owo

LLCMS

n 50 nraimw

FIGURA 13-8 Comparação de custos, 2000 versus 2002.

Os gráficos de barras nào precisam ser representa­ dos horizontalmente. /\ figura 13-8 indica a comparação entre os custos de 2000 e 2002 para todo o programa e

matérias-primas. Gráficos de barras verticais tridimen­ sionais sào frequentemente bonitos de se ver. A Figura

13-9 mostra um típico gráfico de barras tridimensional para a repartição de custos diretos e indiretos de mão de obra e de materiais.

120 110

100-1

doo^totow

FIGURA 13-10 Distribuição do custo total do programa (gráfico de

barras quantitativo-ilustrativo).

Os gráficos de barras podem ser feitos coloridos e atraentes, por meio da combinação com outras técnicas gráficas. A Figura 13-10 mostra um gráfico de barras

quantitativo ilustrado para a distribuição do custo total do programa. A Figura 13-11 mostra a distribuição dos mesmos custos, como na Figura 13-10, mas representados com a técnica de pizza comumente utilizada. A Figura 13-12

ilustra como dois gráficos de barras quantitativos podem ser utilizados lado a lado para criar uma comparação rápida.

Catenas indiretos Hòo de obra indirelo Materiais diretos Hào de obro direta

O lado direito mostra os percentuais de horas de trabalho. A Figura 13-12 funciona melhor se a escala de cada eixo for

a mesma, caso contrário, as comparações podem aparecer distorcidas quando, na verdade, das nào são.

90 80

07SCUSTCS 8

«=>

1 s 1

70 60 50 40 30 20 10

1998

1999

2000

2001

2002

FIGURA 13-9 Repartição de custos diretos e indiretos de mão de obra e materiais para todos os programas por ano.

FIGURA 13-11 Distribuição do dinheiro do programa.

As figuras apresentadas nesta seção não representam, de forma alguma, os únicos métodos de apresentação de

424

Gerenciamento de Projetos

FIGURA 13-13 Repartição de custos do programa total. FIGURA 13-12 Repartiçõo divisional de custos e horas de mão de

obra.

dados em formato de gráfico de barras. Vários outros mé­

todos são mostrados nas seções que se seguem. 13.3

OUTRAS TÉCNICAS CONVENCIONAIS DE APRESENTAÇÃO

Os gráficos de barrassão são uma ferramenta útil para a apresentação de dados em reuniões técnicas. Infelizmen­ te, os programas devem ser ganhos competitivamente ou organizados internamente antes que apresentações de reuniões técnicas possam ser feitas. As propostas con­ correntes ou as solicitações para projetos internos devem conter figuras e gráficos descritivos, não necessariamente representando as atividades, mas mostrando ou planeja­ mento, organização, monitoramento ou procedimentos técnicos projetados para o programa atual ou utilizados anteriormente em outros programas. As propostas geral­ mente contém figuras que exigem alguma interpolação ou extrapolação. A Figura 13-13 mostra a repartição dos custos totais do programa. Embora essa figura também necessite normalmente de interpretação, uma tabela mensal de custos a acompanha. Se a tabela não for muito extensa, então ela pode ser incluida na figura. Isso é mos­ trado na Figura 13-14. Durante as atividades propostas, as colunas de entregas reais e cumulativas, bem como a linha pontilhada na Figura 13-14, seriam omitidas, mas seriam incluídas após a atualização para o uso em reu­ niões técnicas de intercâmbio. Normal mente é uma boa prática a utilização de dados e tabelas anteriores, sempre que possível, porque a administração se acostuma com a maneira pela qual os dados são apresentados.

FIGURA 13-14 Rastreamento do cronograma de entregas

(linha de equilíbrio).

Outra técnica comumente utilizada é a de mode­ los esquemáticos. Gráficos organizacionais são modelos esquemáticos que mostram os inter-relacionamentos entre os indivíduos, organizações ou funções dentro de uma organização. Um organograma normalmente não basta para descrever todos os inter-relacionamentos do programa. A Figura 4-8 identificou o Programa Midas em relação a outros programas dentro da Dalton Cor­ poration. O Programa Midas é indicado pelas linhas em negrito. O gerente do programa para o Programa Midas foi colocado no topo da coluna, embora o seu programa possa ter a menor prioridade. Cada unidade principal de gerenciamento para o Programa Midas deve ser co­ locada o mais próximo possível da alta administração

425

GRÁFICOS DO PROJETO

para indicar ao cliente a “implícita” importância relativa do programa.

Forno preoqueodo

Outro tipo de representação esquemática é o fluxograma de trabalho, sinônimo da aplicação de fluxogramas para a programação de computadores. Fluxogramas são projeta­ dos para descrever, seja simbolicamente ou ilustrativamen­ te, a sequência de eventos necessários para completar uma atividade. A Figura 13-15 mostra a lógica de fluxo para a produção do molde VZ-3. Os símbolos mostrados na Figu­ ra 13-15 são universalmente aceitos por diversas indústrias.

Icsenr irote

IH Reter do bro

krr czerowo pao esfrianerro

Renxw peça de tesle

Pfeça óe tesie | box

Íírtdor pcrc anbao *

PréàoK-33

(j

* 6-0-

Ânazeroirerto pao «trdc

FIGURA 13-15 Fluxo lógico para a produção do moldo VZ-3.

Diagramas de blocos, diagramas esquemáticos, ilustra­ ções e fluxos lógicos, todos atendem a uma necessidade pre­ cisa para descrever a grande variedade de atividades dentro de uma empresa. As figuras e os gráficos são mais do que téc­ nicas descritivas. Eles também podem fornecer à adminis­ tração as ferramentas necessárias para a tomada de decisões.

SOC08D06S

mwsiuswhoío

amosnsduimm

AMOSIUSKUWMX

Q AVv de testa dos coto?

(oioíõfs of nsn FS ktMií 200: ioo 1000 80

»rç FIGURA 13-16 Malriz de lesles para amostras propelentes.

n

PMoK-36

JU.VOHH

HJrodearest io 20

\7 ÂTnaecrrwt:

l's;«ic>"a rroiíe

A representação ilustrada, embora muitas vezes um processo caro, pode adicionar cor e qualidade a qualquer proposta, e elas são mais fáceis de entender do que uma lógica ou um gráfico de bolhas. Como os clientes poderão solicitar visitas durante as atividades para se relacionarem com as figuras ilustradas, a gerência do programa deve evitar a representação ilustrada de atividades que possam ser fechadas para a visão do cliente, possivelmente em virtude da proteção ou segurança. Os diagramas de blocos também podem ser usados para descrever o fluxo de atividades. A Figuras 4-8 e 4-9 são exemplos de diagramas de blocos. Eles podem ser utilizados para mostrar como a informação é distribuída por toda uma organização, ou como um processo ou ati­ vidade é montado. A Figura 13-16 mostra a matriz de tes­ tes para amostras de propelentes. Figuras semelhantes a esta são desenvolvidas quando as visitas são programadas durante a fase de produção ou testes de um programa. A Figura 13-16 mostra ao cliente não só onde o teste será realizado, mas quais testes serão conduzidos.

QOpaoçõo

zl

426

Gerenciamento de Projetos

13.4

REDES E DIAGRAMAS LÓGICOS

Provavelmente a figura mais difícil de construir é o dia­ grama lógico. Diagramas lógicos sào desenvolvidos para ilustrar o raciocínio indutivo e dedutivo, necessário para atingir algum objetivo dentro de um prazo determinado. A maior dificuldade no desenvolvimento de diagramas ló­ gicos é a incapacidade de resposta a questões importantes como: o que acontece se algo der errado? Eu posso quanti­ ficar qualquer parte dos elementos principais do diagrama?

Diagramas lógicos são construídos da mesma forma que os gráficos de barras, na suposição de que nada vai dar errado, e normalmente são acompanhados de perguntas detalhadas, possivelmente em um formato de lista de veri­ ficação, que precisa de respostas. As seguintes perguntas se­ riam semelhantes àquelas feitas para um projeto de P&D: • Qual é a documentação liberada para iniciar a atividade descrita e, possivelmente, os elementos dentro de cada atividade? • Que informações são necessárias antes que essa documentação possa ser liberada? (Quais ativi­ dades anteriores deverão ser concluídas, trabalho projetado, estudos finalizados etc.?) • Quais são os critérios de conclusão ou sucesso para a atividade? • Quais sào as alternativas para cada fase do progra­ ma se o sucesso nào for alcançado? • Que outras atividades sào diretamente dependen­ tes do resultado dessa atividade? • Que outras atividades ou entradas sào necessárias para realizar essa atividade? • Quais sào os principais pontos de decisão, se hou­ ver, durante a atividade? • Qual documentação indica a conclusào da ativida­ de (ou seja, relatório, desenho etc.)? • Qual é a aprovação necessária da gerência para a documentação final? Esses tipos de perguntas sào aplicáveis a muitas ou­ tras formas de apresentação dos dados, nào apenas aos diagramas lógicos. 13.5

DICAS DE ESTUDO PARA 0 EXAME DE CERTIFICACÃO EM GERENCIAMENTO

DE PROJETOS PMP

Esta seção aplica-se à revisão dos princípios de apoio às áreas de conhecimento e grupos de processos do Guia . * PMBOK Este capítulo aborda:

• • • •

Gerenciamento de Tempo Gerenciamento das Comunicações Execução Controle

A compreensão dos princípios a seguir será benéfica se o leitor estiver utilizando este livro como estudo para o Exame de Certificação PMP : *

• Como identificar as diferentes formas pelas quais a informação pode ser exibida para relatar propósitos • Diferentes tipos de técnicas de geração de relató­ rios gráficos e suas vantagens e desvantagens As seguintes questões de múltipla escolha ajudarão na revisão dos conceitos deste capítulo:

1.

2.

Qual das seguintes alternativas constitui uma for­ ma válida de obter informação correta da execução do projeto? a. Observações diretas b. Relatórios orais e escritos c. Reuniões de avaliação e análise técnica d. Todas as anteriores A exibição adequada do gráfico da informação pode resultar em: a. Redução dos custos de documentação b. Redução dos custos de comunicação c. Redução do tempo para as decisões dc rotina d. Todas as anteriores

RESPOSTAS l.D

2. D

EXERCÍCIOS 13-1

13-2

13-3

Para cada tipo de cronograma definido neste ca­ pitulo, responda as seguintes perguntas: a. Quem elabora o cronograma? b. Quem atualiza o cronograma? c. Quem deve apresentar os dados para os dientes? Os clientes devem ler o direito de impor ao for­ necedor como o cronograma deve ser elaborado e apresentado? E se essa solicitação contrariar as políticas e procedimentos da empresa? Dcw ser mantido um conjunto diferente dc crono­ gramas e gráficos para relatórios externos e inter­ nos? Cronogramas separados devem ser feitos para cada nível de gestão? Existe uma forma mais eficaz para amenizar esses tipos de problemas?

14 DEFINIÇÃO DE PREÇOS E ESTIMATIVAS

Estudos de Coso Relooonodos (de Kenner/Project

Livro de Exerdcios Relocionodo (de tenet/Projetl Management

Gun PMBOK - S. ed., Seção de Referência

Management (ate Studes, 4. ed.)

Workbook and PMP-/UM fxam Study Guide,

pao o Exane de Certificação PMP

• Capitol Industries

• The Automoble Problem

• Gerenciamento da Integração do Projeto

• Polypíoducts Irxorpcroted

• lifeCycle Casting

• Gerenciamento do Escopo do Prcjeto

• Small Project Cast Estimating at Percy Canpony

• /Auftiple Choice Exum

• Gerenciamento das Custos do Projeto

II. ed.)

• Coty Electric • Camden Construction Capaahon • Payton Ccrpcrotion

• The Estimating Prcbfem'

14.0

INTRODUÇÃO

G»m as complexidades en­ volvidas, não é de estranhar â.4.2.4 Estimativa Bottom-Up 6.5.2 Estimar as durações das que muitos gerentes de negó­ atividades cios considerem a definição de preços como uma arte. A posse de informações sobre os orçamentos de custos do diente e da definição de pre­ ços competitivos certamente ajuda. No entanto, a realidade é que quaisquer informações que estejam disponíveis a um concorrente geralmente estão disponíveis para os outros. Guia PMBOK ,5. ed.

Uma abordagem disciplinada ajuda no desenvolvi­ mento de todos os insumos para uma recomendação ra­ cional de preços. Um aspecto do beneficio da utilização de um processo disciplinado de gestão é que ele leva à do­ cumentação de vários fatores e premissas envolvidos em um momento posterior. Estes podem ser comparados e analisados, contribuindo para experiências de aprendiza­ gem que compõem as habilidades gerenciais necessárias para decisões comerciais eficazes.

As estimativas nào sào pura sorte. Elas sào decisões bem pensadas baseadas tanto na melhor informação dis­ ponível, quanto em algum tipo de relação de estimativa de custos, ou em algum tipo de modelo de custos. As rela­ ções de estimativas de custos (CER)'rri sào geralmente os resultados dos modelos de custos.

Relações de estimativas de custos típicas poderíam ser • Equações matemáticas com base em análise de regressão • Relações entre custo e quantidade, tais como cur­ vas de aprendizagem • Relações entre custo e custo • Relações entre custo e nào custo, com base em ca­ racterísticas físicas, parâmetros técnicos, ou carac­ terísticas de desempenho Kn Na expressão em inglês. Cost Estimating Relationships (CER).

428

Gerenciamento de Projetos

14.1

ESTRATÉGIAS GLOBAIS DE PRECIFICAÇÃO

Estratégias específicas de preços devem ser desenvolvidas para cada situação individual. No entanto, frequentemen­ te, uma de duas situações prevalece quando estão se bus­ cando as aquisições do projeto competitivamente. Primei­ ro, a nova oportunidade negócios pode ser um programa único com pouco ou nenhum potencial posterior, numa situação classificada como tipo I de aquisição. Segundo, a nova oportunidade de negócio pode ser um ponto de entrada para um negócio posterior maior ou repetido, ou pode representar uma penetração prevista em um novo mercado. Essa aquisição é classificada como tipo 11.

Obviamente, em cada caso, temos objetivos espe­ cíficos de negócio, mas diferentes. O objetivo para uma aquisição de tipo 1 é ganhar o programa e executá-lo lu­ crativamente e satisfatoriamente, em função dos acordos contratuais. O objetivo para uma aquisição do tipo 11 é, muitas vezes, ganhar o programa e desempenhar bem, ganhando assim uma base em um novo segmento de mercado ou em uma nova comunidade de negócios, em vez de gerar lucro. Desse modo, cada tipo de aquisição possui a sua própria e única estratégia de definição de preços, conforme resumido na Tabela 14-1.

A comparação das duas estratégias de preços para as duas situações gerais (como mostra a Tabela 14-1) revela uma grande semelhança nos primeiros cinco pontos. A diferença fundamental é que, para a aquisição de um ren­ tável novo negócio, o preço de compra é determinado de acordo com o custo real, enquanto em uma situação de realização obrigatória,o preço é determinado pelas forças de mercado. Deve-se ressaltar que um dos insumos mais importantes na decisão da definição de preços é a esti­ mativa de custos da linha de base proposta. A concepção

dessa linha de base para os requisitos mínimos deve ser iniciada precocemente, de acordo com regras básicas bem definidas, modelos de custos, e metas estabelecidas de custos. Várias vezes a concepção inicial é realizada em pa­ ralelo com o desenvolvimento da proposta. No estágio da proposta é tarde demais para revisar e sintonizar a linha de base para um custo mínimo. Além disso, um início tão tardio não dá muita opção para uma decisão de oferta final. Mesmo que o preço pareça fora do alcance com­ petitivo, faz pouco sentido encerrar o desenvolvimento da proposta. Como todos os recursos foram enviados de qualquer forma, alguém poderia muito bem apresentar uma oferta, apesar da remota chance de vitória.

Claramente, a definição de preços eficaz começa mui­ to antes do desenvolvimento da proposta. Ela começa com os requisitos preliminares do cliente, aim subtarefas bem compreendidas e uma estimativa top-down com metas exequíveis. Isso permite que a organização funcional con­ ceba uma linha de base para atender as necessidades dos clientes e as metas de custos, e dá à administração tempo para revisar e redirecionar o modelo antes que a proposta seja apresentada. Além disso, oferece à administração uma oportunidade antecipada de avaliar as chances de vitória durante o ciclo de aquisição, em um pinto, quando os re­ cursos adicionais podem ser designados ou o esforço de aquisição pode ser rescindido antes que um excesso de re­ cursos esteja comprometido em um esforço desesperado. Uma sessão final de avaliação da definição de preços deve ser uma integração e revisão das informações já co­ nhecidas no seu contexto básico. O processo e as ferramen­ tas de gestão aqui descritas devem ajudar a fornecer uma estrutura e uma disciplina para as decorrentes decisões de definição de preços de uma forma ordenada e eficaz.

TABELA 14-1 Duas estratégias globais de precificaçõo

Aquisição de Tipo I: Progromo único com pouco ou nenhum negocio posterior

1. Desenvolvei o modeb de custos e ® ãretnzes de estimorivos,

conceber o Inho de base pao custos mirwnos pao o projeto/ ftogromo proposto, poro um mínimo de requisitos do (lente. 2.

Estima os custos reakticomerre poro um minmc de requisitos,

3.

limpa o Inho de bose. Retira custos desnecessários.

Detamna custos mínimos redistos. Obter o comprometimento das orgcnzocoes executa®.

Ajusta o esftmatrm de custos oos riscos.

Aâóona margens desejados. Defini o preço. Comporá o preço oo açomento do dento às informações de cistos do cooconêncD. 8.

Ofertar operas se o preço estiver dentro do faixo competitivo.

Aquisição de Tipo II: Novo progromo com potencial pao grande negócio posterior ou representando uma penetração desejada

em novos mercados

Conceber o Inho de base proposto pao o projeto/progromo odeqiodo oos requisitas do cleríe, com corocteristKOS adicionas, mas com riscos mimes. 2. Estima os custos de formo reohsto.

3. limpa o Inho de bose. Retira os custos desnecessários. Detanina custos mínimos redistos. Obter o comprometimaito das agonizoções executoras. Detanina estimativas exequíveis incluindo qustes de riscos.

6. (ompaa sua estmativo total de custa oo açomento do dente e oo preço mais provável de vitorio. 7. Detanina o margem bruto de lucro recessão poro vencer a proposta. Essa morgem pede ser negatiro! 8. Decidir se o mugem bruto é oceitúvef de ocordo com o efesqo de realzocóo otrigataria. 9. Dependent do suo forço de vontade em vença, data o preço de vitoria mas provável ou um pouco oboao.

10. Se o preço de oferta esto oboixo do custo, muitos vezes é necessário fornece ano explicação oo diente sebre de onde vrõ finonciomento adicional. A fonte pode ser os lucros do empreso cu o ccmportiíomaito de otoidodes relacionadas. Em quolqua coso, um quadro cloro dos recuses deve ser fornecido oo cliente pao

garanti o credbildcde dos custos.

429

DEFINIÇÃO DE PREÇOS E ESTIMATIVAS

14.2 TIPOS DE ESTIMATIVAS

Qualquer empresa ou cor­ poração que queira perma­ 6.5.2 Estimar as durações das necer lucrativa deve me­ atividades 7.2.2 Estimar os custos lhorar continuamente suas ferramentas e técnicas metodologias de definição de preços e estimativas. Embora seja verdade que algumas empresas têm tido sucesso sem boas definições de esti­ mativas de custos e preços, muito poucas permanecem bem-sucedidas sem elas. Guia PMBOK , 5. ed.

Boas estimativas requerem que as informações se­ jam coletadas antes do início do processo de estimativa. Informações típicas incluem: Experiência recente em trabalhos similares Material profissional e de referência Pesquisas de mercado e de setor Conhecimento das operações e processos Estimativas de software e de bases de dados, se disponíveis • Entrevistas com especialistas no assunto

■ • • • •

Os projetos podem variar de um estudo de viabili­ dade, até a modificação de instalações existentes, ou um desenho completo, aquisições e construção de um grande complexo. Como quer que o projeto seja, grande ou pe­ queno, a estimativa e o tipo de informação desejado pode diferir radicalmente.

O primeiro tipo de estimativa é uma análise de ordem de grandeza, que é feita sem quaisquer dados detalhados de engenharia. Ela deve ter uma exatidão de ± 35% den­ tro do escopo do projeto. Esse tipo de estimativa pode usar a experiência passada (não necessariamente similar), fato­ res de escala, curvas paramétricas ou estimativas de capa­ cidade (isto é, S/n° de produto ou S/kW de eletricidade). Estimativas por ordem de grandeza são estimativas top-down geralmente aplicadas para o nível 1 da EAP e, em algumas indústrias, o uso de estimativas paramêtricas é incluído. Uma estimativa paramétrica é baseada em dados estatísticos. Por exemplo, suponha que você vive em um subúrbio de Chicago e deseja construir a casa dos seus sonhos. Você entra em contato com um empreiteiro que informa que o custo paramétrico ou estatístico para uma casa nesse bairro é de S 120 por metro quadrado. Em Los Angeles, o custo pode ser de S 4.150 por metro quadrado. A seguir, há a estimativa aproximada (ou estimativa top-down), que também é feita sem dados detalhados de engenharia, e pode ter uma exatidão de ± 15%. Esse tipo de estimativa é rateada de projetos anteriores que são se­ melhantes em escopo e capacidade, e pode ser intitulada

TABELA 14-2 Padrão para estimativas de projetos Tempo

Método de

Tipo

Relodona mento

Est inativo

Genérico

coma EAP

PorométtKO

* ROM

lopdov/n

■25% o-75%-

Dias

Ardogc

Orçamento

Topdov/n

-10% o+25%

Semanas

DefiniTM)

Bottcmup

-5%o»15%

Meses

Exatidão

paro Elaborar

Engenharia (base)

■ROM = Rough Ord d Afogrtufe. Em mxJjçõo bed 'Order d> gordezo qjrotraif

como estimativa por analogia, curvas paramétricas, regra * prática 1’ e custo indexado de atividades similares ajusta­ das para a capacidade e tecnologia. Nesse caso, o analista de custos pode dizer que essa atividade é 50% mais difícil do que a anterior (ou seja, a referência) e que exige 50% a mais de tempo, homens-horas, dinheiro, materiais e as­ sim por diante.

A estimativa definitiva, ou estimativa de formação de base, é preparada a partir de dados de engenharia bem definidos, incluindo (no mínimo) as cotações dos fornecedores, planos bastante completos, especificações, preços unitários e estimativa para terminar. A estimativa definitiva, também conhecida como estimativa detalha­ da, tem uma exatidão de ± 5%.

Outro método para estimativa é o uso de curvas de aprendizagem. .As curvas de aprendizagem são represen­ tações gráficas de funções repetitivas em que as operações contínuas conduzirão a uma redução do tempo, recursos e dinheiro. A teoria por trás das curvas de aprendizagem é geralmente aplicada ás operações de produção. Cada empresa pode ter uma abordagem única para as estimativas. No entanto, para as práticas normais de gerenciamento de projetos, a Tabela 14-2 seria suficiente como ponto de partida.

Muitas empresas tentam padronizar os seus proce­ dimentos de estimativa por meio do desenvolvimento de um manual de estimativas. Ele é então utilizado para es­ tabelecer o preço do esforço, talvez tanto quanto 90%. Os manuais de estimativas geralmente fornecem melhores estimativas do que as normas de engenharia industrial, porque incluem grupos de tarefas e levam em conside­ ração itens como o tempo de inatividade, o tempo de limpeza, almoço e pausas. A Tabela 14-3 mostra o índice analítico de um manual de estimativas de construção.

Na expressão em inglês, rule ofthumb. Í-. uma abordagem práti­

ca, baseada na experiência,em vez deem um método científico

ou preciso, baseado em uma teoria.

430

Gerenciamento de Projetos

TABELA 14-3 índice analítico do manual de estimativas

TABELA 14-5 Lista de verificação para trabalho geral mente

necessário para as várias classes de estimativas (l-VI)

Introdução Propósitos e tipos (fe estimow

rin

(lasses de Estimativas

ftrácprô Fenomentos de Fsimctnos

Custas de equipamentos catalogados

l.Consuho

X

X

X

2.LegHidode

X

X

X

3. Cópias

X

X

4. Cronograma

X

X

X

5. Consultas oo fornecedor

X

X

X

6. Pacotes de subcontrato

X

X

7. Listagem

X

X

X

X

8. Visito kxd

X

X

X

X

9. Estima o moia pane

X

X

X

X

X

10. Taiasdemõodeobro

X

X

X

X

X

11. Equipamentos e sdeçõo

X

X

X

X

X

12. Impostos, seguros e dwatos autoras

X

X

X

X

X

13. Custos com escritório centrai

X

X

X

X

X

14. Custos indiretos de construção

X

X

X

X

X

15 Boses dos estimate

X

X

X

X

X

16. listo de etppanentos

X

17. Foha de resumo

X

X

X

X

X

18 AvoBoçõo do administração

X

X

X

X

X

X

19. Custo final

X

X

X

X

X

X

20. Aprovação do oànnstrocòo

X

X

X

X

X

X

21. Eslimolw computodonzodo

X

X

X

X

X

X

X

Sistema automatizado de dadas de investimento Sistema automatizado de estimations

Métodos e procedimentos computadorizados

Classes de Fsiimctiras Esnmotrro definitivo Estimativo de custo de capitel

X

Estimativo de apcopnoçõc

Estimativa de vioWdade Ordem de grandeza

X

Gráficas - qucnticfade de especifxojoes do estimativa e dietiizes poro o definição

de preços.

Dedos lieressonos Gráfico - Ccmpofoçõo dos dodos necessários pao o elaboração dos classes

deestimairos

Fspeufkoçòes fo Apresentação Procedmento de estmati.os - geral

de sdxontiotos

Piocedmento de estmati.os da estimativo definitivo

Procedmento de estmati.os pao estimativo de custo de capital Procedmento de estmati.os pao eslimotivo de oproprioçõo Procedmento de estmati.os pao eslimotivo de .lotiWcxfe

Os manuais de estimativas, como o nome indica, fornecem estimativas. z\ questão, claro, é “o quão boas sào as estimativas”. A maioria dos manuais de estimativas fornece limitações de exatidão por meio da definição do tipo de estimativa (mostrado na Tabela 14-3). Usando a Tabela 14-3, podemos criar as Tabelas 14-4, 14-5 e 14-6 que ilustram o uso do manual de estimativas.

Nem todas as empresas podem utilizar manuais de estimativas. Esses manuais funcionam melhor para tare­ fas repetitivas ou tarefas semelhantes que possam utilizar uma estimativa anterior, ajustada por um fator de grau de dificuldade. Atividades como as de P&D não se prestam ao uso de manuais de estimativas, exceto para referência, e testes repetitivos de laboratório. Os gerentes de propos­ tas devem considerar cuidadosamente se o manual de es­ timativas é uma abordagem viável. A literatura está cheia de exemplos de empresas que gastaram milhões tentando desenvolver esses manuais para situações que simples­ mente não se prestam à abordagem. TABELA 14-4 Classes de estimativas

Closse DefintMj

•5'.

1

Custe de copitd

*15% ±10

III

Aprcpíioçòo (com olgim custo de copitol)

*20% ±15

IV

ApCÇOOCOO

*25% ±20

V

Viobldode

*35% ±25

VI

Ordem de grerdeza

>±35%

X

Durante a licitação, é importante que o tipo de esti­ mativa seja consistente com os requisitos do cliente. Para projetos internos, o tipo de estimativa pode variar ao lon­ go do ciclo de vida de um projeto:

• Estágio Conceituai: orientação ao risco ou estudos de viabilidade para a avaliação do trabalho futuro. Essa estimativa é muitas vezes baseada em infor­ mações mínimas do escopo. • Estágio de Planejamento: estimativa para a auto­ rização de financiamento parcial ou total. Essas estimativas são baseadas no projeto e no escopo preliminares. • Estágio Principal: estimativa para o trabalho deta­ lhado. • Estágio de Conclusão: refazer estimativas para grandes mudanças no escopo ou variações além do limite de autorização.

431

DEFINIÇÃO DE PREÇOS E ESTIMATIVAS

TABELA 14-6 Dados necessários para a elaboração de

14.3 PROCESSO DE PRECIFICAÇÃO

estimativas

Essa atividade programa o desenvolvimento da estrutura analítica do projeto e fornece à administração dois dos três instrumentos operacionais necessários para o con­ trole de um sistema ou projeto. O desenvolvimento des­ sas duas ferramentas ê normalmente de responsabilidade do escritório de programas com a colaboração das unida­ des funcionais.

Classes de Estimativas I

II

III

IV

V

VI

Produto

X

X

X

X

X

X

Descnçoo do processo

X

X

X

X

X

X

Ccpccidcde

X

X

X

X

X

X

X

X

Geru/

Locofizoçõo - gerei

Locoiizoçõo — especíko

X

X

X

X

Criteria boskos de design

X

X

X

X

X

X

X

Especifkoções gerais de design

X

Processo Dfogromo do fluxo de bloqueio do processo

X

Diogromo do fluxo do processo (com «omonio e material rfo equpameíitc)

X

X

Tubulações e nsiromaitoçõo mecânicos

X

X

X

üsto de eqiipomentos

X

X

X

X

X

Gtfofisodor/especifkocões qurnkos

X

X

X

X

X

Condições do solo

X

X

X

X

Âpuromenfo do bcol

X

X

X

Docfos geológicos e meteorológicos

X

X

X

Estradas, pxwmertação e pasogsmc

X

X

X

Proteção do prcpriedode

X

X

X

Acessibildode oo locd

X

X

X

Frete e ccndKces de entrego

X

X

X

Loccl

Os custos mas impcnontes são ccnrabilizodos

X

X

Pnnapots fgurpamentos Jamaihos e motenas prelonares fomaihos, motenors e pertences finalizadas

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Oucnfxtode de Mcletid Aniso tocrfifKoçoc de desenhos frdirodos toonÉficoçoo (te desenhos çrelminaes

X

Encomnhomenlo de dogromas

índice de Unho de tubdoçóo

X

X

Unho elétrco único

X

X

X

Proteção contra incêndios

X

X

X

Sistemas de esgoto

X

X

X

Serviços proltssiorois - estimativa detdhodo

X

X

Serviços profrssiorois - estimate rocionodo Ojcrtifafe de cotofcadores/produlos omtkos

X

X

X

X

X

X

X

bebidos, cákdos de viagens

X

X

X

X

X

Produtividade do trabalho e pr atros da área

X

X

X

X

X

X

X

X

X

X

X

(onstMóo Remineracão da mão de obro, olimentoçõo e

Raio detdhodo de execução de construção Compos indretos - estimar rvo de talhada

A estrutura analítica do projeto e os cronogramas das atividades são precificados pelas menores unidades de precificação da empresa. Ê de responsabilidade dessas unidades, sejam elas seções, departamentos ou divisões, fornecer dados de custos precisos e significativos (com base em padrões históricos, se possível). Todas as infor­ mações são preci ficadas no menor nível de desempenho exigido, que, a partir da premissa do Capítulo 11, será o nível da tarefa. As informações de custos sào recolhidas ao nível do projeto e, em seguida, recolhidas em mais um passo para o nível do programa total.

X X

tngerfcoG Here terreno e elevaões

A integração da unidade funcional no ambiente de projetos ou do sistema ocorre por meio da atribuição de preços à estrutura analítica do projeto. Os custos totais do programa, obtidos por meio da definição de preços das atividades programadas durante o período de desem­ penho, fornecem à administração a terceira ferramenta necessária para gerenciar com êxito o projeto. Durante as atividades de definição de preços, as unidades funcionais têm a opção de consultar a gerência do programa sobre possíveis mudanças nos cronogramas das atividades e na estrutura analítica do projeto.

Compos indretos - estimotiYO raionodo

Croncgromc tempo told de execução Cronograma de eierucõj detalhado

X

X

X

Cronograma de deboroçõo de estimativas

X

X

X

X

Em condições ideais, o trabalho necessário (isto é, homens-horas) para completar uma determinada tare­ fa pode ser baseado em padrões históricos. Infelizmente, muitos setores, projetos e programas sào tão diversifica­ dos que pode não ser possível a comparação realista entre as atividades anteriores. As informações de custos obtidas de cada unidade de precificação, sejam ou não baseadas em padrões históricos, devem ser consideradas apenas como uma estimativa. Como uma empresa pode prever a estrutura salarial para três anos a partir de agora? Qual será o custo das matérias-primas em dois anos? A base do negócio (e, portanto, as taxas de overhead) muda durante a duração do programa? A resposta definitiva para essas questões mostra que os dados de custos são explicitamen­ te relacionados a um ambiente que não pode ser previsto com qualquer grau de certeza. A abordagem sistêmica de gerenciamento, no entanto, fornece uma resposta mais rá­ pida ao ambiente do que abordagens menos estruturadas. Uma vez que os dados de custos são montados, eles devem ser analisados pelo seu potencial impacto sobre os recursos de pessoas, dinheiro, equipamentos e instalações

432

Gerenciamento de Projetos

da empresa. É somente por meio de uma análise total de custos do programa que as alocações de recursos podem ser analisadas. A análise de alocação de recursos é realiza­ da em todos os níveis de gestão, que vão desde o supervi­ sor de seção até o vice-presidente e o diretor geral. Para a maioria dos programas, o executivo chefe deve aprovar os dados finais de custos e a alocação de recursos.

A análise adequada dos custos totais do programa pode fornecer à administração (tanto do programa quanto da empresa) um modelo de planejamento estratégico para a integração do programa atual com outros programas, a fim de obter uma estratégia global da empresa. Modelos signi­ ficativos de planejamento e definição de preços incluem análises para cronogramas mensais de alocação por depar­ tamento, custos mensais e anuais do total do programa, as despesas mensais com materiais e o fluxo de caixa total do programa e os requisitos de homens-horas por mês. Anteriormente, identificamos vários dos problemas que ocorrem nos nós em que a hierarquia horizontal de gerenciamento do programa se relaciona com a hierarquia vertical do gerenciamento funcional. A definição de pre­ ços da estrutura analítica do projeto fornece a base para a comunicação eficaz e aberta entre as gerências funcional e do programa, em que ambas as partes têm um objetivo co­ mum. Isso é mostrado na Figura 14-1. Depois que o esforço da definição de preços estiver concluído e o programa for iniciado, a estrutura analítica do projeto ainda constitui a base de uma ferramenta de comunicação, por meio da do­ cumentação do desempenho acordado no esforço da defi­ nição de preços, bem como no estabelecimento de critérios contra os quais os custos de desempenho serão medidos. Hecq.c f.nard

FIGURA 14-1 A comunicação vertical-horizontal.

14.4

REQUISITOS DE COLABORAÇÃO ORGANIZACIONAL

Uma vez que a estrutura analítica do projeto e os cro­ nogramas de atividades sào estabelecidos, o gerente do

programa convoca uma reunião com todas as organiza­ ções que apresentarão informações sobre a definição de preços. É imperativo que todos os representantes de cus­ teio de mão de obra ou de definição de preços estejam presentes para a primeira reunião. Durante essa reunião de kickoff, a estrutura analítica do projeto é descrita em profundidade, para que cada gerente da unidade de precificação saiba exatamente quais são as suas responsabili­ dades durante o programa. reunião de kickofftambém resolve a luta de poder entre os gerentes funcionais cujas responsabilidades possam ser semelhantes. Um exemplo disso seria as atividades de controle de qualidade. Duran­ te a fase de pesquisa e desenvolvimento de um programa, o pessoal de pesquisa pode ser autorizado a realizar seus próprios esforços de controle de qualidade, enquanto du­ rante as atividades de produção, o departamento ou divi­ são de controle de qualidade teria responsabilidade total. Infelizmente uma reunião nem sempre é suficiente para esclarecer todos os problemas. Reuniões de acompanha­ mento ou de andamento sào realizadas, normalmente, apenas com os interessados pelos problemas que surgi­ ram. Algumas empresas preferem que todos os membros compareçam às reuniões de andamento para que todo o pessoal esteja familiarizado com todo o esforço e com os problemas associados. A vantagem de nào ter todo o pessoal relacionado com o programa participando é que o tempo é fundamental para a precificaçào das atividades. Muitas divisões funcionais levam essa política um passo à frente ao ter um representante divisional, possivelmente em conjunto com os importantes gerentes de departamen­ to ou supervisores de seçào como os únicos participantes da reunião de kickoff. O representante de divisão, então, assume toda a responsabilidade em assegurar que todos os dados de custeio sejam apresentados no prazo. Essa configuração pode ser benéfica pelo fato de que o gerente do programa precisa entrar em contato com apenas um indivíduo na divisão para saber o andamento da ativida­ de, mas isso pode se tornar um gargalo se o representante falhar em manter a boa comunicação entre as unidades funcionais e o escritório de programas, ou se o indivíduo simplesmente nào estiver familiarizado com os requisitos de precificaçào da estrutura analítica do projeto.

Durante as atividades propostas, o tempo pode ser extremamente importante. Há muitas situações em que uma solicitação de proposta (RFP) exige que todos os respondentes apresentem suas propostas até uma data es­ pecífica. Em um ambiente de proposta, as atividades do escritório de programas, bem como aquelas das unidades funcionais, estão sob um cronograma estabelecido pelo gerente da proposta. O cronograma do gerente da pro­ posta tem muito pouca, ou nenhuma, flexibilidade e ge­ ralmente está sob restrições de prazos apertados para que

DEFINIÇÃO DE PREÇOS E ESTIMATIVAS

a proposta possa ser digitada, editada e publicada antes da data de apresentação. Neste caso, a RFP indiretamen­ te define quanto tempo as unidades de precificaçào têm para identificar e justificar os custos de mão de obra. A justificativa para os custos de mão de obra pode levar mais tempo do que as estimativas iniciais de custos, especial­ mente se os padrões históricos não estiverem disponíveis. Muitas propostas exigem muitas vezes que uma justificativa abrangente para a mão de obra seja apresentada. Outras pro­ postas, especialmente aquelas que solicitam resposta quase imediata, podem permitir que os fornecedores apresentem as justificativas para a mão de obra em data posterior. Em última análise, é de responsabilidade dos super­ visores das menores unidades dc precificaçào manter pa­ drões adequados, de modo que uma resposta quase ime­ diata possa ser dada a uma solicitação de precificaçào de um escritório de programas. 14.5

DISTRIBUIÇÕES DE MÃO DE OBRA

As unidades funcionais fornecem a sua contribuição ao es­ critório de programas na forma de homens-horas, como mostrado na Figura 14-2. A contribuição pode ser acom­ panhada da justificativa de mâo de obra, se for necessário. As quantidades de homens-horas sào apresentadas para cada tarefa, considerando-se que a tarefa é o menor ele­ mento dc preço, e que as tarefas estão dispostas por mês. As quantidades de homens-horas por mês para cada tarefa são convertidas para dinheiro, após a multiplicação de ta­ xas adequadas de mão de obra. As taxas de mão de obra são geralmente conhecidas com certeza durante um período de 12 meses, mas a partir daí sào apenas estimativas. Como

433 uma empresa pode prever estruturas salariais para cinco anos depois? Se a empresa subestimar a estrutura salarial, haverá aumento dos custos e diminuição dos lucros. Se a estrutura salarial for superestimada, a empresa pode não ser competitiva, se o projeto é financiado pelo governo, então, a estrutura salarial se torna um item em negocia­ ções de contratos.

O desenvolvimento das taxas de mão de obra a serem utilizadas na projeção é baseado em custos históricos na base de negócios de horas e de valores monetários para o mês ou trimestre mais recente. As taxas de média por hora são fixadas para cada unidade de mão de obra por meio de esforços diretos nas operações no nível de departamento. As taxas são apenas médias, e incluem os funcionários mais bem pagos e os funcionários menos bem pagos, juntamen­ te com o gerente do departamento e o apoio administrati­ vo1. Essas taxas de base são, então, escaladas como um fator percentual baseado na experiência passada, no orçamen­ to tal como foi aprovado pela gerência, e nas perspectivas locais e indústrias similares. Se a empresa tem uma base de negócios predominante da indústria aeroespacial ou de defesa, então, esses salários são negociados com órgãos do governo local antes da apresentação de propostas. As horas de mão de obra apresentadas pelas unidades funcionais são, muitas vezes, superestimadas por medo de que a administração irá “manipular” e reduzir as horas de mão de obra, enquanto tentará manter o mesmo esco­ po de esforço. Muitas vezes a administração é obrigada a reduzir os valores de homens-horas, ou por causa do fi­ nanciamento insuficiente, ou apenas para se manter com­ petitiva no ambiente. A redução de homens-horas muitas vezes provoca discussões acaloradas entre os gerentes fun­ cional e de programas. Os gerentes de programas tendem a pensar em termos dos interesses do programa, enquanto os gerentes funcionais inclinam-se a manter sua equipe atual.

A solução mais comum para esse conflito está com o gerente do programa. Se ele seleciona membros para a equipe do programa que conheçam os padrões de ho­ mens-horas para cada um dos departamentos, então, uma atmosfera de confiança pode se desenvolver entre o gerente do programa e o departamento funcional para que os va­ lores de homens-horas possam ser reduzidos de maneira a representar os interesses da empresa. Essa é uma das razões pelas quais membros da equipe do programa muitas vezes são promovidos de dentro das categorias funcionais.

FIGURA 14-2 Fluxo Fundonol do precificaçào.

Podem ocorrer problemas se os salários das pessoas designadas ao programa ultrapassarem as médias do departamento. .Méto­ dos para minimizar esse problema serào discutidos posterior­ mente. Também, em muitas empresas os gerentes de departa­ mento são incluídos na estrutura da taxa de overhaul, e não em mão de obra direta e, portanto, seus salários não são incluídos como parte da média do departamento.

434

Gerenciamento de Projetos

Os valores de homens-horas apresentados pelas unida­ des funcionais fornecem a base para a análise do custo total do programa e para o controle de custos do programa. Para ilustrar este processo, considere o Exemplo 14-1 a seguir. Exemplo 14-1. Em 15 de maio, a Apex Manufactu­ ring decidiu entrar em uma concorrência de licitação para a modificação e atualização de um programa de li­ nha de montagem. Uma estrutura analítica de projeto foi desenvolvida, como apresentado a seguir:

• PROGRAMA (01-00-00): Modificação de linha de Montagem • PROJETO 1 (01-01-00): Planejamento Inicial ■ Tarefa 1 (01-01-01): Controle de Engenharia • Tarefa 2 (01-01-02): Desenvolví mento de Engenharia . PROJETO 2 (01-02-00): Montagem . Tarefa 1 (01-02-01): Modificação • Tarefa 2 (01-02-02): Testes Em Io de junho, cada unidade de precificaçào rece­ beu a estrutura analítica do projeto em conjunto com o cronograma apresentado na Figura 14-3. De acordo com o cronograma desenvolvido pelo gerente de propostas para esse projeto, todos os dados de mão de obra devem ser apresentados ao escritório de programas para revisão, o mais tardar em 15 de junho. Deve-se notar aqui que, em muitas empresas, as horas de mão de obra são enviadas diretamente para o departamento de precificaçào para o envio ao computador do caso de base. Nesse caso, o es­ critório de programas iria “manipular” as horas de mão de obra somente depois que os números do caso de base estiverem disponíveis. Esse procedimento pressupõe que existe tempo suficiente para a análise e modificação do caso de base. Se o escritório de programas tem pessoal suficiente capaz dc criticar a entrada de mào dc obra an­ tes da apresentação para o caso de base, entào um tem­ po precioso pode ser economizado, sobretudo se forem necessários dois ou três dias para obter o resultado do computador para o caso de base. MESSAPÚSAAUTOWZAÇÃO

Durante as atividades da proposta, o gerente de pro­ postas, gerente de preços e o gerente do programa devem todos trabalhar juntos, apesar de o gerente do programa possuir a palavra final. /\ principal responsabilidade do gerente de propostas é integrar as atividades propostas em um sistema operacional para que a proposta seja sub­ metida ao solicitante no prazo. Um cronograma típico desenvolvido pelo gerente de propostas é apresentado na Figura 14-4. O cronograma inclui todas as atividades necessárias para ter a proposta enviada, com o primeiro grande passo sendo a apresentação de valores de homens-horas por parte das organizações de precificaçào. A Fi­ gura 14-4 também indica o rastreamento dos custos da proposta. O cronograma de atividades da proposta nor­ malmente é acompanhado de um cronograma de tempo com uma lista detalhada de verificaçào das estimativas, se a complexidade da proposta justificar. /\ lista de veri­ ficação geralmente fornece explicações detalhadas para o cronograma de atividades da proposta.

SfWAS APÔS 0 nOCOFF DA PKPOSTA

1

2

3

4

5

6

7

8

9

Gorxnrcrros dos otrttodts eetaboeçãodoW

9 Dafcs de cjstos «modos petos unttodes toncca»

Dodcsde DQuwtes enródos

Desuíões léawas ervodas [xetododepeteatomertodo P®9'°rc

íevtsã) de custos peb 9»êrxux de ixjwrç::

fatre barn basics

On

Geere to arte detab

On Gwraíc bralaMÍtf

On

Dm

FIGURA 15-15 Relatório da análise de variação da conta

de custos.

Para a análise da variação, o objetivo do gerente da

conta de custos (seja ele empregado do projeto ou empre­ gado funcional) é realizar ações que corrigirão o proble­ ma dentro do orçamento original ou justificar uma nova estimativa. Cinco questões devem ser abordadas durante a análise da variação:

• Qual é o problema que está causando a variação? • Qual é o impacto sobre tempo, custos e desem­ penho? • Qual é o impacto sobre outros esforços, se existirem?

• Qual ação corretiva está planejada ou em andamento? • Quais são os resultados esperados da ação corretiva?

Um dos principais parâmetros utilizados na análi­ se da variação é o conceito de “valor agregado”, que é o mesmo que o COTR. O valor agregado é uma variável de previsão utilizada para prever se o projeto terminará acima ou abaixo do orçamento. Como exemplo, em I de

• Assinatura do analista de custos e/ou do gerente de projetos assistente para o controle de custos • Assinatura do gerente do projeto, gerente do ele­

junho, o orçamento mostrou que 800 horas deveríam ter

mento da estrutura analítica do projeto, ou al­ guém do escritório de projetos com autoridade para assinatura

o desempenho é (800/600) x 100, ou 133%,e a tarefa está abaixo em desempenho. Se as horas reais fossem 1.000, o desempenho seria de 80% e estaria ocorrendo um excesso

sido gastas em uma dada tarefa. No entanto, apenas 600 horas apareceram no relatório de mão de obra. Portanto,

em desempenho. A maior dificuldade encontrada na determinação do PARKINSON, C N. Parkinson's law. Boston: Houghton Mi­ fflin, 1975.

COTR é a avaliação do trabalho em andamento (pacotes de trabalho que foram iniciados e que não foram concluídos no

479

CONTROLE DOS CUSTOS

momento de corte do relatório). A utilização de pacotes de trabalho de curto prazo ou o estabelecimento de mar­ cos de valores distintos dentro dos pacotes de trabalho

AMAUSE

Agentaio ICOU) Rafado iCOTR

(uffo Orçodo d: Tdcb:

reduzirão significativamente o problema da avaliação

de trabalho em andamento e os procedimentos utiliza­ dos irão variar, dependendo da extensão do pacote de

trabalho. Por exemplo, alguns fornecedores preferem

não considerar o COTR para um pacote de trabalho de curto prazo até que ele esteja concluído, enquanto outros consideram 50% do orçamento do pacote de trabalho quando ele inicia e os restantes 50% na sua conclusão. Alguns fornecedores utilizam fórmulas que aproximam o período no tempo do esforço, outros utilizam padrões

agregados, enquanto outros preferem ainda fazer ava­ liações físicas do trabalho concluído para determinar o orçamento agregado aplicável. Para pacotes de trabalho

À «gn 50/50 invert) »o notóho err onfomrro

FIGURA 15-16 Análise demonstrando o utilização da regra 50/50.

maiores, muitos fornecedores utilizam marcos distintos com orçamento preestabelecido ou valores de progresso

7«K

para medir o trabalho realizado. 600

A dificuldade na realização da análise da variação é

o cálculo do COTR porque deve-se prever o percentual

a

‘O: -

concluído. A fórmula mais simples para o cálculo do S100K 4

O IrKüAta) • tnioRed A (cndwAM) Aíondanted FTlVdoriJoVPro L-1 Reggio de

5UBIAREFA2

centual concluído. Por exemplo, poderiamos dizer que 10% dos custos devem ser “reservados” para cada 10% do intervalo de tempo. Outra técnica, e talvez a mais co­

(>

SUBUREFA3

S50K A|

SUBWÍEFA4

$

$ 140 R:

SUBWtEFA 5

4

S90K 4

Deserprho

mum, é a regra 50/50:

Metade do orçamento para cada elemento é regis­ trada no momento em que o trabalho está agendado para

começar e a outra metade, no momento em que o traba­ lho está agendado para ser concluído. Para um projeto

com um grande número de elementos, a quantidade de distorção de tal procedimento é mínima. As Figuras 15-16 e 15-17 ilustram essa técnica.

SUBWtffAÓ

SUBIARFFA 1

*

I^K

4

I

|

S10QK

SUBUREFA8

4

S 75 K 0

I

2

3

4

5

«SÍSAPdSAWTOeiAÇÀO

CTI* Orçamento no Término. Tradução oficial da versão em portu­ guês da quarta edição do Guia PMBOK * para Budget at Com­ pletion (BAC).

FIGURA 15-17 Dados de custos da tarefa 3, do Projeto Z

(contratuais).

7

8

480

Gerenciamento de Projetos

Uma vantagem de se utilizar a regra 50/50 é que ela elimina a necessidade da contínua determinação do per­ centual concluído. No entanto, se o percentual concluído pode ser determinado, então ele pode ser traçado em fun­ ção do tempo gasto, como mostra a Figura 15-18. Existem outras técnicas disponíveis, além da regra 50/50**:

• 0/100: normalmente, limitada a pacotes de traba­ lho (atividades) de pequena duração (ou seja, me­ nos de um més). Nenhum valor é agregado até que a atividade seja concluída. • Marco: é utilizado para pacotes de trabalho lon­ gos com marcos provisórios associados, ou um grupo funcional de atividades com um marco estabelecido em pontos de controle identificados. O valor é agregado quando o marco for concluído. Nesses casos, um orçamento é atribuído ao marco, e não aos pacotes de trabalho. • Percentual Concluído: normal mente recorridos para pacotes de trabalho de longa duração (ou seja, três meses ou mais), em que os marcos não podem ser identificados. O valor agregado seria o percentual relatado do orçamento. • Unidades Equivalentes: usado para vários pacotes de trabalho unitários semelhantes, em que os ganhos es­ tão nas unidades concluídas, e não no trabalha • Fórmula dc custos (80/20): Uma variação do per­ centual concluído para pacotes de trabalho de lon­ ga duração. • Nível de Esforço: esse método é baseado na passagem do tempo, muitas vezes utilizado para a supervisão e o gerenciamento de pacotes de trabalho. O valor agregado é baseado no tempo despendido ao longo do tempo total programado. F.le é medido em termos de recursos consumidos durante um determinado período de tempo e nào resulta em um produto final. • Esforço Distribuído: uma técnica raramente uti­ lizada para pacotes de trabalho especiais relacio­ nados. Como exemplo, um pacote de trabalho de produção pode ter um pacote de trabalho de inspeção distribuído de 20%. Existem apenas al­ gumas aplicações dessa técnica. Muitas pessoas tentarão utilizá-la para supervisão, o que não é uma aplicação válida. Essa técnica é utilizada para o esforço que nào é facilmente divisível em pacotes de trabalho pequenos, mas que seja proporcional a algum outro esforço medido.

Essas técnkas, além do método 50/50 para a determinação do tra­ balho em andamento, estão disponíveis cm pacotes de software.

FIGURA 15-18 Progresso físico versus lempo gosto.

De um modo geral, o conceito de valor agregeado pode não ser uma ferramenta eficaz de controle se for uti­ lizado nos níveis mais baixos da EAP. Os níveis de tarefas e os níveis acima das tarefas geralmente compensam o esfor­ ço para o cálculo do valor agregado. Como exemplo, con­ sidere a Figura 15-17, a qual mostra os dados dos custos contratuais para a tarefa 3 do projeto Z, e a Tabela 15-2, que mostra o andamento dos dados de custos, ao final do quarto mês. A seguir, um breve resumo dos dados de cus­ tos para cada subtarefa da tarefa 3 ao final do quarto mês:

• Subtarefa 1: todos os recursos financeiros contra­ tuais foram orçados. Os custos e o desempenho estavam no prazo, conforme indicado pela posição do marco, a subtarefa está concluída. • Subtarefa 2: todos os recursos financeiros contra­ tuais foram orçados. Foram obtidos sobrecustos de $ 5.000, e o marco foi concluído depois do es­ perado. A subtarefa está concluída. • Subtarefa 3: a subtarefa está concluída. Os custos ficaram abaixo em S 10.000, provavelmente por causa do início mais cedo. • Subtarefa 4: o trabalho está atrasado. Na verdade, o trabalho ainda não começou. • Subtarefa 5: o trabalho foi concluído na data pre­ vista, mas com sobrecustos de $ 50.000. • Subtarefa 6: o trabalho ainda nào começou. O es­ forço está atrasado. • Subtarefa 7: o trabalho começou e parece estar 25% concluído. • Subtarefa 8: o trabalho ainda nào começou.

481

CONTROLE DOS CUSTOS

TABELA 15-2 Andamento dos custos de dados da tarefa 3, do

Projeto Z, ao final do quarto mês (custos em milhares)

Motr Os dato corwfefcm .rrc wtoçt» 50/50 poro as vdats de c«:irert: plorepdcs e rçregodos

Para completar a nossa análise do andamento de um projeto, temos de determinar o orçamento no término (ONT) e a estimativa no término (ENT)K117. A Tabela 15-3 mostra os parâmetros para a análise da variação. • O orçamento no término é a soma de todos os or­ çamentos (COTA), atribuídos ao projeto. Isso é, muitas vezes, sinônimo de linha de base do proje­ to. Isso é quanto o esforço total deve custar. • A estimativa no término identifica tanto os dólares quanto as horas que representam uma avaliação realista do trabalho, quando realizado, É a soma de todos os custos diretos e indiretos até o momento, mais a estimativa de todo o trabalho autorizado remanescente (EAC = resultados reais cumulativos + a estimativa para terminar). TABELA 15-3 Os parâmetros para a análise da variação

Questào

Sigla

Resposta

Quente nobatc deveria ser

Custo arcado do trobdho

COU

reobzodo?

ogendade

COTR

Quente frobofro esto concluído?

Custo arcado «fo trabalho realizado

CRTR

Quente o troboho que 'esto

Custo red cfo trobdho realizado

ONT

ccreluido’ custou’

Orçamento no término (orçamento

ENToulRP”

Quente o troboho inteiro eslavo

told)

previsto custa’

Eslnotivo no término ou o Jlrno

0 quenós esperamos o partir de

eshmotivo revisado

□goro qje seja o custo de lodo o

troboho’

Utilizando as definições aqui apresentadas, podemos calcular a variação no término (VNT)wrw:

VNT = ONT-EN ífTl Estimativa no Término. Tradução oficial da rersào em português da quarta edição do Guia PMBOK» para Estimateat Completion (EAC). *”* Da expressão cm inglês. Latest Revised Estimate (LRE).

KTI* Variação no Término. Da expressão cm inglês. Variance at Completion (VAC).

A estimativa no término (ENT) é a melhor estima­ tiva do custo total na conclusão do projeto. Ela é uma avaliação periódica do andamento do projeto, geral­ mente em uma base mensal ou até que uma mudança significativa seja identificada. Frequentemente, é de res­ ponsabilidade da organização executora elaborar a F.NT.

O cálculo de uma nova ENT e a revisão posterior não implicam que uma ação corretiva tenha sido toma­ da. Considere uma tarefa de três meses que esteja 99% concluída e que foi orçada para gastar $ 400 mil (COTA). Os custos reais até o momento (CRTR) são de S 395 mil. Usando a regra 50/50, o COIR é de S 200 mil. A relação estimada do custo para terminar (ENT) é $ 395 mil/ $ 200 mil, o que significa que estamos caminhando para sobrecustos de 100%. Obviamente, esse não é o caso. Utilizando os dados da Tabela 15-4, podemos calcu­ lar a estimativa no término (ENT), por meio da expressão

ENT = (CRTR/COTR) x ONT = ONT/IDC = (360/340) x 579.000 = $613.059

onde o ONT é o valor da COTA na conclusão. /X discussão sobre qual valor a ser usado para o ONT é argumentative. No cálculo apresentado aqui, utilizamos os dólares dos encargos sociais de mào de obra direta. Algumas pessoas preferem usar mão de obra sem encar­ gos sociais com o argumento de que o gerente do projeto controla apenas horas e dólares de mão de obra direta. Além disso, o cálculo para a ENT não inclui custos de materiais ou despesas gerais e administrativas.

O cálculo da ENT, aqui apresentado, implica que nós estamos excedendo os custos de mào de obra em 6,38% e que os custos finais dos encargos sociais de mão de obra poderão ultrapassar os custos orçados de encargos sociais dc mào de obra em S 34.059. Para um cálculo mais pre­ ciso da ENT, precisaríamos incluir os custos de materiais (considerados em $ 70.000) e as despesas gerais e admi­ nistrativas. Isso nos daria um custo final, excluindo os lucros, de $ 751.365, que corresponde a um sobrecusto de $ 37.365. O lucro resultante seria $ 86.000 menos $ 37.365, ou S 48.635. A análise final é que o trabalho está sendo realizado quase dentro do cronograma, exceto pela subtarefa 4 e pela subtarefa 6, mas os custos estão sendo excedidos. A pergunta que fica é: onde os sobrecustos estão ocorrendo? Para respondê-la, devemos analisar a folha de resumo de custos para a tarefa 3, do projeto Z. A Tabe­ la 15-4 representa um caso hipotético para os elementos

482

Gerenciamento de Projetos

de custos da tarefa 3, do projeto Z. Da Tabela 15-4 nós vemos que existem variações negativas (excedentes) para dinheiro de mào de obra, dinheiro de overhead e custos de materiais. Como o overhead de mào de obra é medido como uma porcentagem de dinheiro de mão de obra di­ reta, o problema parece estar com o dinheiro de mão de obra direta. TABELA 15-4 Resumo de custos do tarefo 3, do projeto Z, para

o trabalho conduído ou em andamento (custo em milhares) Voriocõo

na Dola

de

de Prazos

Variação

Cota

COTR

CRTR

Custos

8650

6712

5061

4652

409

(46)

241

187

141

150

(9)

(64)

338

263

199

210

(ID

579

450

340

360

(20)

70

66

26

30

(4)

Contratual

Horos de mõo de obro

Cumulativo

direto

Dolores de mõo de obro drelo

Despesos gacrs de moo de obro (140%) Subtotal

Dólares an matercft Subtotal

Despesos geras e

649

65

oánintsftatwos (10%) Subtotal

Comrssõo (12%)

lotai

favorável na curva de aprendizagem), exceto pela subtarefa 4, que está nos dando um atraso no cronograma. • Os custos de mão de obra direta estão aumentan­ do com a utilização de funcionários com salários mais altos. • As taxas de overhead estão conforme o previsto. • As horas de mão de obra direta devem ser redu­ zidas ainda mais para compensar o aumento de custos ou os lucros serào drasticamente reduzidos.

714

86

800

Aíoftr kw Itòeta conudea jto elqoo de 50/50 pao os rabes de oaomerto ptoneptos e

ogtegoda

A partir da coluna contratual na Tabela 15-4, o pro­ jeto foi estimado em S 27,86 por hora de mão de obra direta ($ 241.000/8.650 horas), mas os valores reais até o momento são S 150.000/4.652 horas, ou S 32,24 por hora. Portanto, estão sendo empregadas pessoas com sa­ lários maiores do que o previsto. Esse aumento de salário é parcialmente compensado pelo fato de que existe uma variação positiva de 409 horas de mào de obra direta, indicando que esses funcionários mais bem pagos estão desempenhando em uma posição mais favorável do que o esperado na curva de aprendizagem. Como os marcos (da Figura 15-17) parecem estar no alvo, o trabalho está progredindo conforme planejado, exceto pela subtarefa 4. A taxa de overhead de mào de obra nào mudou. As taxas de overhead do contrato, do COTA e do COTR fo­ ram estimadas em 140%. Os valores reais, obtidos a partir dos relatórios de final de mês, indicam que a taxa real de overhead está como previsto. As seguintes conclusões podem ser tiradas:

• O trabalho está sendo realizado conforme planeja­ do (quase no prazo, embora em uma posição mais

Esse tipo de análise poderia ter sido realizado para um nível a mais, identificando exatamente os departa­ mentos que estavam usando os trabalhadores mais caros. Esse passo provavelmente deveria ser concluído de qual­ quer forma para verificar se funcionários com menores salários estariam disponíveis e poderíam trabalhar na posição necessária na curva de aprendizagem. Como os custos de mão de obra foram um resultado do aumen­ to nas horas de mão de obra, esse passo certamente teria sido necessário para identificar o motivo dos sobrecustos internos. Talvez uma estimativa ruim fosse a causa. Na Tabela 15-4, também aparece uma variação po­ sitiva de materiais. Isso, igualmente, deveria ser submeti­ do a uma análise mais aprofundada. A causa poderia ser resultado de equipamentos inadequadamente identifica­ dos, aumento crescente nos custos de materiais, além do que foi planejado, aumento de fatores de descarte ou uma mudança de subcontratados.

Deveria ser evidente, a partir da análise acima, que uma investigação aprofundada das causas das variações parece ser o melhor método para identificar as causas. O conceito de valor agregado, embora uma estimativa gros­ seira, identifica tendências relacionadas ao andamento de determinados elementos da EAP. Utilizando esse concei­ to, o custo orçado do trabalho agendado (COTA) pode ser chamado de valor agregado planejado (VAP)Hno, e o custo orçado do trabalho realizado (COTR) pode ser cha­ mado de valor agregado real (VAR)xni. Os valores agre­ gados são utilizados para determinar se os custos estão sendo efetuados mais rápida ou mais lentamente do que o planejado. No entanto, os sobrecustos não necessaria­ mente significam que haverá um eventual excesso, por­ que o trabalho pode estar sendo feito mais rapidamente do que o planejado.

wno Valor Agregado Planejado. Da expressão em inglês. Planned Earned Value (PEV).

ya|or Agregado Real. Da expressão em inglês. Actual Earned Value (AEV).

483

CONTROLE DOS CUSTOS

Existem várias fórmulas que podem ser utilizadas para calcular a ENT. Usando os dados mostrados a se­ guir, podemos ilustrar a forma como cada uma das trés fórmulas diferentes pode dar um resultado diferente. Su­ ponha que seu projeto consista de apenas trés atividades. CRTR da atividade

% (onduido

Cola

COTR

A B C

100 50 0

1.000 1.000 1.000

-.000 500 0

1.200 700 0

CRTR Fórmula I. ENT =---------X ONT COTR 1.900 = ------- (3.000) = S 3.800 1.500 Fórmula 11. ENT =

CK1 K

exatidão das estimativas. As técnicas de estimativa aqui utilizam apenas os custos de mão de obra. Os custos de materiais podem ser adicionados em cada equação para se obter o custo total.

Treze casos para comparar o desempenho planejado versus o real são apresentados na Tabela 15-5. Cada caso é descrito a seguir, usando as relações: • Variação de custos = valor agregado real - valores reais • Variações de desempenho e prazos = valor agrega­ do real - valor agregado planejado TABELA 15-5 Estudos de caso para análise da variação

X [trabalho concluído e

em andamento) + [todo o trabalho restante a estar no custo planejado, incluindo o trabalho restante em andamento] =

1 900

(2.000) + $ 1.000 = 5 3.533

1.500

Fórmula III. ENT = [real até o momento] + [todo o trabalho restante a estar no custo planejado, incluindo o trabalho restante em andamento] = 1.9(H) + [ 500 + 1.000 ] = $3.400

B

C

Existem vantagens e desvantagens para cada fórmu­ la. A Fórmula I presume que a taxa de queima (ou seja, CRTR/COTR) será a mesma para o restante do projeto. Essa é a fórmula mais fácil de usar. A taxa de queima é atualizada a cada período de relatório.

A Fórmula II considera que todos os pacotes de traba­ lho ainda não abertos serão concluídos ao custo planejado. No entanto, é possível que o custo planejado seja revisto com base no histórico dos pacotes de trabalho concluídos. A Fórmula III considera que todo o trabalho restante é independente da taxa de queima incorrida até agora. Isso pode ser irrealista, a não ser que todo o trabalho res­ tante possa ser novamente estimado, se necessário. Outras técnicas estão disponíveis para determinar os custos finais de conclusão4. O valor da técnica seleciona­ da é baseado no valor em dólar do projeto, nos riscos, na qualidade do sistema de contabilidade de custos, e na

FLEMING, W. Q.; Koppdman, I. M. Forecasting lhe Final Cosí and Schedule Results, PM Network, jan. 1996. p. 13-18.

Caso 1: essa é a situação ideal de planejamento, em que tudo corre conforme o cronograma. Caso 2: os custos estão atrasados no cronograma, e o programa parece estar abaixo do previsto. O trabalho está sendo realizado a menos de 100%, já que os valores reais excedem o VAR (ou o COTR). Isso indica que um sobrecusto pode ser antecipado. Essa situação piora ainda mais quando vemos que também estamos com 50% de atraso no cronograma. Esse é um dos piores casos possíveis. Caso 3: nesse caso, há boas e más notícias. A boa no­ tícia é que estamos realizando o trabalho de forma efi­ ciente (eficiência superior a 100%). A má notícia é que estamos atrasados no cronograma. Caso 4: o trabalho não está sendo realizado de acor­ do com o cronograma (ou seja, está atrasado), mas os custos estão sendo mantidos para o que foi realizado. Caso 5: os custos estão no alvo com o cronograma, mas o trabalho está 25% atrasado, porque o trabalho está sendo realizado a 75% da eficiência. Caso 6: como estamos trabalhando a uma eficiência de 125%, o trabalho está adiantado em 25%, mas dentro dos custos agendados. Estamos desempenhando em uma posição mais favorável na curva de aprendizagem.

484 Caso 7: estamos trabalhando a uma eficiência de 100% e o trabalho está sendo realizado antes do previsto. Os cus­ tos estão sendo mantidos de acordo com o orçamento.

Caso 8: o trabalho está sendo realizado corretamente e os custos estão abaixo do previsto. Caso 9: o trabalho está sendo realizado corretamen­ te, mas os custos estão acima do previsto. Caso 10: os custos estão acima do previsto, enquanto estamos realizando abaixo do previsto no plano. O traba­ lho está sendo realizado de forma ineficiente. Essa situa­ ção é muito ruim. Caso 11: o desempenho está adiantando no crono­ grama e os custos estão mais baixos do que o planeja­ do. Essa situação resulta em uma grande gratificação de Natal. Caso 12: o trabalho está sendo feito de forma efi­ ciente, e um possível excedente de custos pode ocorrer. Contudo, o desempenho está adiantado no cronograma. O resultado geral pode ficar tanto acima dos custos ou adiantado no cronograma. Case 13: embora os custos sejam maiores que os or­ çados, o desempenho está adiantado em relação ao pre­ visto e o trabalho está sendo realizado de forma muito eficiente. Essa também é uma boa situação. Em cada um desses casos, o conceito de valor agre­ gado foi utilizado para prever as tendências de custos e a análise da variação. Esse método tem seus prós e contras.

Cada uma das variações críticas (ou valores agrega­ dos) identificados normalmente requer uma análise for­ mal para determinar a causa da variação, a ação corretiva a ser tomada e os efeitos sobre a estimativa no término. Essas análises são realizadas pela organização que foi atri­ buída ao orçamento (COTA) no nível de acumulação di­ rigido pela gerência do programa. Análise em Nível Organizacional

Cada variação crítica identificada nos relatórios do MCCS organizacional pode exigir a condusão de proce­ dimentos de análise da variação do MCCS pelo super­ visor do centro de custos envolvido. Na anál ise tanto da estrutura analítica quanto da estrutura organizacional, o supervisor sistematicamente concentra seus esforços em problemas de custos e cronograma que aparecem dentro da sua organização. A análise começa pelo supervisor envolvido com o menor nível organizacional. As variações críticas são ano­ tadas na conta de custos, no relatório MCCS. Se uma va­ riação de prazos estiver envolvida e a subtarefa for com­

Gerenciamento de Projetos

posta de uma série de pacotes de trabalho, o supervisor pode referir-se a um relatório separado que divide cada conta de custos em vários pacotes de trabalho que estão adiantados ou atrasados no cronograma. O supervisor,

então, pode analisar a variação com base no pacote de trabalho envolvido e, com o auxílio de organizações de apoio, determinar a causa da variação, a ação corretiva a ser tomada ou o possível efeito sobre esforços associados planejados ou futuros. As variações de custos que envolvem a mão de obra são analisadas pelo supervisor, com base no desempenho da sua organização no cumprimento do trabalho desig­ nado, dentro do valores orçados de homens-horas e da taxa planejada de mão de obra. A causa de qualquer va­ riação para esse desempenho é determinada e a ação cor­ retiva é, então, implementada.

As variações de custos sobre os esforços não relacio­ nados à mão de obra são analisadas pelo supervisor com o auxílio do membro da equipe do programa e de outras organizações de apoio.

Todas as análises da variação de materiais são nor­ malmente iniciadas pela contabilidade de custos como um serviço para a organização usuária. Essas análises de variação são concluídas, incluindo as causas e ações corretivas, à medida que possam ser explicadas pela con­ tabilidade de custos. Elas são, então, enviadas para a or­ ganização usuária, que revê as análises e conclui as que resultam de desempenho do cronograma ou utilização. Se a variação é reconhecida como uma mudança no pre­ ço de aquisição do material, essa informação é fornecida pela contabilidade de custos à organização responsável e uma mudança na estimativa para terminar é iniciada pela organização usuária. O supervisor deve encaminhar cópias de cada for­ mulário de alteração concluído da análise da variação do MCCS/mudança na ENT ao seu gerente superior e ao membro da equipe do programa. Análise da Equipe do Programa

O membro da equipe do programa poderá receber um relatório de variação crítica da equipe que relaciona as variações na sua organização ao nível mais baixo da estrutura analítica do projeto no nível de centro de custos da divisão por elemento de custos. A pedido do gerente do programa, as análises das variações que contribuem para as variações no relatório de variação crítica da equi­ pe são resumidas pelo membro da equipe do programa responsável e revistas com o gerente do programa.

485

CONTROLE DOS CUSTOS

A elaboração dos relatórios de andamento, sejam eles para a gestão interna ou para o diente, deve, no mí­ nimo, responder a duas questões fundamentais: ■ Onde estamos hoje (em relação a tempo e custos)? • Onde vamos terminar (em relação a tempo e custos)? As informações necessárias para responder a essas perguntas podem ser obtidas das seguintes fórmulas:

• Onde estamos hoje? • Variações de custos (em dólares/hora e percen­ tual concluído) • Variações de prazos (em dólares/hora e percen­ tual concluído) • Percentual concluído • Percentual de dinheiro gasto • Onde iremos terminar? • Estimativa no término (ENT) • O caminho crítico restante • IDP (análise das tendências) • IDC (análise das tendências) Como o IDP e o IDC são utilizados para análises de tendências, podemos utilizá-los para a previsão do custo final esperado e da data de término esperada para o pro­ jeto. Podemos expressar o custo no término, ENT, como:

—s? O prazo no término usa o IDP para a previsão e pode ser expresso como:

Nova duração do projeto =

duração do inicial do projeto IDP Deve-se tomar cuidado com a utilização do IDP para calcular a nova duração do projeto porque um valor favorá­ vel para o IDP (ou seja, menor que 1,0) poderia ser o resulta­ do de pacotes de trabalho que não estão no caminho crítica

Uma vez que a ENT e a nova duração do projeto são calculadas, podemos calcular a variação no término (VNT) e o custo estimado para terminar (EPT) ™, * utili­ zando as duas fórmulas seguintes:

VNT = ONT=ENT e EPT = ENT-CRTR

KI” Da expressão cm inglês. Estimate to Complete (ETC). Tradução oficial da versão cm português da quarta edição do Guia

PMBOK® “Estimativa para Terminar (EPT)”.

O percentual concluído e o percentual de dinheiro gasto pode ser obtido das seguintes fórmulas:

Percentual concluído = SÜLJS ONT Percentual de dinheiro gasto

COTR ONT

onde ONT é o orçamento no término.

O gerente do programa usa essas informações para revisar o andamento do programa com a alta administra­ ção. Essa revisão normalmente ocorre em uma base men­ sal, em grandes projetos. Além disso, os resultados dessas análises são utilizados para explicar as variações nos rela­ tórios para o cliente exigidos contratualmente. Depois que as análises das variações foram feitas, os relatórios devem ser desenvolvidos tanto para o cliente quanto para a gerência interna (de nível superior) de ges­ tão. Os procedimentos e especificações de relatório para o cliente podem ser mais detalhados do que os relatórios internos e, muitas vezes, são regidos por contrato. As exi­ gências contratuais especificam os relatórios exigidos, a fre­ quência de envio e distribuição e o regulamento do cliente que especifica as instruções de elaboração para o relatório.

Os tipos de relatórios exigidos pelo cliente e pela ad­ ministração dependerão do tamanho do programa e da magnitude da variação. A maioria dos relatórios contém o rastreamento dos parâmetros técnicos vitais. Esses pa­ râmetros podem incluir: • Os principais marcos necessários para o sucesso do projeto • A comparação com as especificações • Tipos ou condições de testes • Correlação do desempenho técnico para a rede de atividades e da estrutura analítica do projeto

Uma nota final sobre relatórios: para poupar tempo e dinheiro, os relatórios devem consistir de apenas uma ou duas páginas ou de formulários para preenchimento. 15.7 A LINHA DE BASE DOS CUSTOS

Uma vez que o projeto é iniciado, a equipe do pro­ 7.33 Linha dc base dc custos jeto estabelece a linha de base financeira ou de custos, contra a qual o andamento será relatado e as variações serão medidas. A Figura 1519 representa uma linha de base de custos. Cada bloco representa uma conta de custos ou elemento de paco­ te de trabalho. A soma de todas as contas de custos ou Gvra PMBOK-, 5. ed.

486

Gerenciamento de Projetos

pacotes de trabalho seriam, então, iguais ao orçamento em fases do tempo. Cada pacote de trabalho, então, seria descrito por meio do formulário de autorização do tra­ balho para aquele pacote de trabalho.

Há certas características distintivas da Figura 15-20:

• O orçamento em fases do tempo, que é o orçamen­ to liberado, é a soma de todos os elementos COTA. • A linha de base de custos é a soma do orçamento em fases do tempo (ou seja, o orçamento distribuí­ do) e do orçamento não distribuído. Essa soma será igual ao orçamento no término (ONT) libe­ rado e planejado. • Os custos contratuais para concluir o projeto é a soma do custo da linha de base e da reserva de ge­ renciamento, considerando que existe uma reserva de gerenciamento. • O preço do contrato é o custo do contrato, acresci­ do do lucro, se houver. COMO JUSTIFICAR OS CUSTOS

15.8

FIGURA 15-19 A linho de base de custos.

A linha de base dc custos na Figura 15-19 é apenas parte da divisão dos custos. Uma ilustração de uma divi­ são dos custos aparece na Figura 15-20.

O preço do projeto, muitas vezes, é baseado em previ­ sões mais otimistas do que nas estimativas concretas. Isso é particularmente verdadeiro para as empresas que sobrevivem de licitação e quando o custo de elaboração de uma proposta pode variar entre $ 50.000 e $ 500.000. Se a probabilidade de vencer uma licitação é baixa, então a empresa pode gastar uma quantidade mínima de tempo e custos durante a elaboração da proposta. A Fabela 15-6 mostra um resumo típico da definição de preços do projeto. Nela, cada área funcional ou divisão pode ter sua própria taxa de overhead. Nesse resumo, a taxa de overhe­ ad para a engenharia é de 110%, enquanto a taxa de overhead para a produção é de 200%. Se a empresa é uma subsidiária de uma empresa maior, então os custos gerais e administrativos da empresa (G&A) podem ser incluí­ dos. Se o projeto é para um cliente externo, então uma margem de lucro será incluída.

Uma vez concluído o resumo dos preços do projeto, os custos devem ser justificados diante de um comitê di­ retor. Isso é mostrado na Figura 15-21.

FIGURA 15-20 Divisõo de custos no nível I do EAP.

TABELA 15-6 Resumo típico de preços do projeto

Mão de Obra Direta Deporta mento

Ençeriono

Produçõo

OVERHEAD

Dólares

%

Dólares

Horas

Taxo

1000

$42.00

42.000

110

46.200

500

$35.00

17.500

200

35.000 Totd de Mão de Obra

Outros: Subcootrotos

$10,000

Consultores

$2,000

Total de Mão de Obra e /Aatena s Custas Gereis e AAninrstroüvos do Empreso: 10% lucro: 15%

Total

$88.200 $52.500 $140.700

$ 12.000

$152.700

$15.270 $ 167.970

$25.196 $193.166

487

CONTROLE DOS CUSTOS

Lstfrcir: ias herrisscs

- Tcids de Hcd de Cbo

- Irtizoçòo de Hows Extros

-FokNesdeDesicrte

-Í5C0S

- Custos Gotos

(Se cs pendes aí» crreta e .usafccodcs. ertrx o preço fool, prcrtherrerre, esto cone*) e oceihd pen o odmirisloçõo)

FIGURA 15-21 Justificativa dos custos (e obtenção de aprovação).

Toda empresa possui seus próprios critérios de ava­ liação para o processo de aprovação do resumo de custos. Os elementos típicos que devem ser justificados ou apoia­ dos por dados concretos incluem:

• Taxas dc Mão de Obra: para fins de estimativa, as médias do departamento ou as médias ponderadas do conjunto de habilidades podem ser utilizadas. Isso às vezes é chamado de taxa mista. O cenário de melhor caso seria a estimativa do salário real ou do conjunto de habilidades dos trabalhadores a serem designados. Isso pode ser impossível durante a li­ citação, porque não sabemos quem vai estar dispo­ nível ou quem será designado, considerando que o contrato seja concedido. Além disso, se o projeto é um esforço de vários anos, podemos precisar de taxas antecipadas de preços, as quais são os salários previstos, com todos os encargos sociais, antecipa­ dos para os próximos poucos anos. Isso é ilustrado na Tabela 15-7.

para possíveis erros cometidos durante o período de horas extras em excesso. • Fatores de Descarte: se o projeto inclui a aquisição de matérias-primas, então pode ser necessário al­ gum subsídio para fatores de descarte. Esse cálculo pode ser afetado pelo conjunto de habilidades dos recursos designados e pela quantidade dos mate­ riais, pela experiência anterior com esses materiais e experiências nesses tipos de projetos. • Riscos: a análise de riscos pode ser baseada na qualidade das estimativas e na experiência daque­ les que fizeram as estimativas. Outros riscos con­ siderados incluem a capacidade da empresa em alcançar os benefícios antecipados ou os lucros de­ signados e, se ocorrer um desastre, a exposição da empresa e a responsabilidade por ações judiciais. • Custos ocultos: esses custos, alguns dos quais estão ilustrados na Figura 15-22, podem corroer toda a lucratividade esperada em um projeta Outro custo potencial mente oculto é a disponibilidade anual ou mensal da carga de trabalho. Um cálculo típico apa­ rece na Tabela 15-8. Se usarmos a Tabela 15-8 e todos os trabalhadores forem empregados em longo prazo, pode haver menos do que 1.840 horas disponíveis por ano, porque as pessoas experientes podem ter ganhado mais de trés semanas de férias por ano. TABELA 15-8 Horas disponíveis para o trabalho Haas Drsponwis pa Ano (52 x 40)

2080 horas

Fãbs (3 semanas)

•120 haas

Licença Médica (3 dias)

•24 haas

Fàos Remuneradas (11 dias)

•88 haas

Dever de Júri (1 dia)

•8 haas

1840haas (1.840 horas/ono)/12 meses = 153 haas/mês

TABELA 15-7 Taxes de preços futuros: salário (estrutura

departamental de pagamento)

Salário (Pa haa)

í

Faixa Salarial

Titulo

2009

2010-

* 2011

$53

$56

$60

9

Engenheiro Consulta

8

Engenharo Séria

48

50

53

7

Engenheiro

39

42

45

6

Engenheiro Júrta

34

36

39

5

Engenhero Aprendz

29

31

34

Cisto di Cop'd

Errtaç.e/PotfajeT

* bias peotetoóas

• Horas Extras: se os recursos sào escassos e a em­ presa não tem a intenção de contratar recursos adicionais, então alguma parte do trabalho deve ser realizada em horas extras. Isso poderia aumen­ tar o custo do projeto e um subsídio deve ser feito

Vogtre

Compaeomento err fexkes

FIGURA 15-22 Outros custos ocultos frequentes.

488

Gerenciamento de Projetos

15.9

0 DILEMA DOS SOBRECUSTOS

A sobrevivência da maioria das organizações é um flu­ xo contínuo de novos produtos ou serviços. Por causa da palavra “novo”, os dados históricos podem ser mínimos e sobrecustos são esperados. A Figura 15-23 mostra a ex­ tensão típica dos sobrecustos.

FIGURA 15-23 Exiensôo dos sobrecustos.

As estimativas por ordem de grandeza aproximada (ROM) muitas vezes são feitas de dados “subjetivos”, que podem resultar em uma ampla gama de sobrecustos, e são utilizadas na fase de iniciação de um projeto. Confor­ me passamos de dados “subjetivos” para dados “concre­ tos” e entramos na fase de planejamento de um projeto, a precisão das estimativas melhora e a extensão dos sobre­ custos diminui.

Quando ocorrem desvios, o gerente de projetos pro­ cura formas de reduzir os custos. A maneira mais simples é reduzir o escopo. Isso começa com uma busca por itens que são fáceis de cortar, ou seja, aqueles que foram mal compreendidos durante o processo de estimativa e, por­ tanto, subestimados. Os itens típicos que são cortados ou reduzidos em magnitude incluem: • • • • •

Supervisão do gerenciamento do projeto Supervisão do gerenciamento de linha Controles de processo Garantia da qualidade Testes

Se os itens de fácil corte não proporcionam redução de custos suficiente, então começa uma busca desespera­ da entre os itens de difícil corte. Esses itens incluem:

• Horas de mão de obra direta • Materiais • Equipamentos

• Instalações • Outros Se as reduções de custos forem inaceitáveis para a administração, esta deve decidir se deve ou não puxar a tomada e cancelar o projeto. Puxar a tomada pode pare­ cer uma decisão facil, mas acaba sendo uma das decisões mais difíceis para os executivos tomarem. Razões típicas para não puxar a tomada incluem:

• Razões quantitativas • Grandes barreiras de saída • Gastos significativos foram feitos e são irrecuperáveis • Cláusulas de multas • Processos por quebra de contrato • Pagamentos aos trabalhadores demitidos • Baixo valor residual de bens e propriedades ■ Custos elevados no fechamento de fábrica • Transferir as pessoas pode acabar violando acor­ dos de senior idade e de mão de obra • Razões qualitativas • Ver o fracasso como um sinal de fraqueza • Ver o fracasso como dano para a carreira • Ver o fracasso como um dano à reputação • Ver o fracasso como um obstáculo à promoção • Medo de expor os erros aos outros • Ver uma notícia ruim como um fracasso pessoal • Recusa em admitir a derrota ou o fracasso • Ver o que quer ver em vez de ver a realidade 15.10

REGISTRO DOS CUSTOS DE MATERIAIS UTILIZANDO A MEDIÇÃO DO VALOR AGREGADO

Na utilização da medição do “valor agregado”, o custo real do trabalho realizado representa aqueles custos diretos e indiretos identificados especificamente para o projeto (contrato) iminente. Tanto os custos registrados quanto os custos relatados devem incidir especificamente para esse esforço. O registro dos custos de mão de obra direta geralmente não apresenta nenhum problema, já que os custos de mão de obra geralmente são registrados confor­ me o trabalho é realizado. Portanto, a mão de obra regis­ trada e a mão de obra relatada serão as mesmas. Custos de materiais, por outro lado, podem ser re­ gistrados em vários momentos. Podem ser registrados como custos de comprometimento de materiais, despe­ sas, acréscimos e custos aplicados. Iodos fornecem infor­ mações úteis e são importantes para fins de controle. Por causa das escolhas disponíveis para a análise de custos de materiais, estes devem ser relatados separada­

489

CONTROLE DOS CUSTOS

mente do padrão de relatório de valor agregado hora de mão de obra/dólares de mão de obra. Por exemplo, as variações de custos associados com a aquisição de ma­ teriais podem ser determinadas no momento em que os pedidos de compra são negociados e realizados com os vendedores, uma vez que essa informação fornece a vi­ sibilidade mais antecipada possível de problemas poten­ ciais de variação de custos. Variações significativas nos custos previstos e reais de materiais podem ter um sério efeito sobre o custo total do contrato e devem ser refleti­ das imediatamente no custo estimado no término (ENT) e explicadas na parte narrativa do relatório de andamen­ to do projeto. A separação dos custos de mão de obra dos custos de materiais é essencial. Considere o seguinte exemplo:

Exemplo 15-1. Você tem um orçamento para gastar $ 1.000.000 em mão de obra e encargos sociais e $ 600.000 em materiais. Ao final do primeiro mês do seu projeto, a seguinte informação é disponibilizada para você:

Mão de obra: CRTR = S

90.000

COTR=$

100.000

ONT = S 1.000.000 Materiais: CRTR = $ 450.000 COTR = $ 400.000 ONT = $600.000

Para efeito de simplicidade, vamos utilizar a seguinte fórmula para a ENT: ENT = (CRTR/COTR) x ONT

Portanto,

ENT(mão de obra) = S 900.000 ENT( materiais) = $ 675.000 Se adicionarmos as duas ENTs, o custo estimado no término será de S 1.575.000, que é $ 25.000 abaixo do orçamento planejado. Se os custos são combinados antes de calcularmos a ENT, então

ENT = [($ 450.000 + S 90.000) / S 500.000] x (S 1.600.000) = S 1.728.000

que é um sobrecusto de S 128.000. Portanto, geralmente é melhor separar materiais de mão de obra no relatório de andamento.

Outro grande problema é como contabilizar os cus­ tos de materiais com pedidos de compra realizados, o que não reflete o custo do trabalho realizado e que normal­ mente não é utilizado no relatório de andamento. Para

fins de medição de desempenho, é desejável que os custos dos materiais sejam registrados no momento em que são recebidos, pagos, ou utilizados, e não no momento em que o pedido de compra é realizado. Portanto, os custos reais relatados para os materiais devem ser derivados de acordo com os procedimentos estabelecidos e normal­ mente serão registrados para fins de medição do valor agregado durante ou após o recebimento dos materiais. Além disso, os custos devem ser sempre registrados na mesma base em que os orçamentos são elaborados para tornar significativas as comparações entre os custos or­ çados e os custos reais. Por exemplo, os materiais não devem ser orçados com base em quando são utilizados e depois ter seus custos coletados/relatados com base em quando são recebidos. Considere as seguintes situações: Situação I: um fabricante de equipamento recebe um contrato para construir cinco máquinas para o mes­ mo cliente, mas cada máquina é um pouco diferente. O fabricante compra e recebe cinco dos mesmos motores elétricos, um para cada máquina. Qual é o momento mais antecipado possível em que o fabricante deve contabilizar os motores elétricos?

a. b. c. d. e.

Quando tiver feito o pedido Quando tiver recebido Quando tiver pagado Quando tiverem sido retirados do estoque Quando tiverem sido instalados

Situação II: o mesmo fabricante adquiriu grandes quantidades de chapa de aço para as cinco máquinas, bem como para máquinas de outros clientes. Ao enco­ mendar em grandes quantidades, o fabricante recebeu um desconto substancial no preço. Qual é o momento mais antecipado possível em que o fabricante deve conta­ bilizar as chapas de aço?

a. b. c. d. e.

Quando tiver feito o pedido Quando tiver recebido Quando tiver pagado Quando tiverem sido retiradas do estoque Quando tiverem sido instaladas

Situação III: suponha que o fabricante da Situação 11 compre chapas de aço para um único cliente e não para vários clientes. Qual é o momento mais antecipado possível em que o fabricante deve contabilizar as chapas de aço? a. b. c. d.

Quando tiver feito o pedido Quando tiver pagado Quando tiver recebido Quando tiverem sido aplicadas

490

Gerenciamento de Projetos

f. Deve haver contabilidade total de todos os ma­ teriais adquiridos, incluindo qualquer estoque de materiais residuais.

Nas situações I e III, a resposta recomendável é “quando tiver recebido”. Na situação 11, qualquer resposta pode ser discutida, mas a melhor resposta é “quando tive­ rem sido instaladas”. 15.11

0 CRITÉRIO DA CONTABILIDADE

Embora esta tarefa pareça ser difícil, será facilitada se a organização focar em duas áreas: 1.

DE MATERIAIS

No mínimo, o sistema de contabilidade de materiais do fornecedor deve oferecer o seguinte:

a. Acumulação exata dos custos e atribuição de custos para as contas dc custos dc forma consis­ tente com os orçamentos, utilizando técnicas de custos reconhecidas e aceitas. b. Determinação das variações de preços dos ma­ teriais, por meio da comparação dos compro­ missos planejados versus reais. c. Medição do desempenho de custos no momen­ to mais adequado para a categoria dos materiais envolvidos, mas não antes do momento do rece­ bí mento efetivo do material. d. Determinação das variações de custos dos ma­ teriais atribuíveis ao excesso de quantidade de materiais. e. Determinação dos custos unitários ou de lote, quando for o caso. f. Responsabilidade total por todos os materiais ad­ quiridos para o projeto, incluindo estoque residual.

A fim de satisfazer esses seis requisitos de sistema, as seguintes práticas contábeis devem estar aderentes: a. Os custos reais dos materiais (CRTR) devem equi­ valer aos seus planos de materiais (COTA) e ser transferidos até o nível de conta de custos da EAP. b. As variações de preços dos materiais devem ser determináveis, por meio da comparação dos comprometimentos planejados (valor estimado de materiais) com os comprometimentos reais (custos reais de materiais). c. O progresso do trabalho físico ou valor agre­ gado (COTR) deve ser determinável, mas nào antes que os materiais tenham sido recebidos. d. As variações de custos de quantidade (a ser dis­ cutido na próxima seção) deve ser determinável a partir do uso excessivo de materiais. c. Os custos unitários e/ou custos dc lote dc mate­ riais devem ser determináveis, conforme aplicável

2.

Aquelas empresas que possuem um sistema de con­ signação de materiais em uso como parte do sistema de contabilidade de materiais, geralmente são capazes de es­ tabelecer e atualizar os custos para as suas mercadorias adquiridas em vários pontos: como um passivo estimado quando a engenharia ou a produção definir os requisitos; ainda como um passivo estimado quando alguém iniciar formalmente o pedido de compra; atualizado como um passivo acumulado quando um pedido de compra for realizado, mais tarde atualizado para um passivo real quando as partes forem recebidas e aceitas; e atualizado pela última vez quando a fatura for paga e os custos regis­ trados nos livros contábeis. 15.12

VARIAÇÕES DE MATERIAIS:

PREÇO E QUANTIDADE

Um dos requisitos de um sistema de contabilidade de ma­ teriais é que ele seja capaz de determinar simplesmente por que os orçamentos dos materiais foram excedidos; isso é chamado de análise da variação. Quando os custos reais de materiais ultrapassam um orçamento de mate­ riais, normalmente há duas causas: 1.

2.

Os artigos comprados custam mais do que o plane­ jado, chamado de “variação de preço". Mais artigos foram consumidos do que o planeja­ do, chamado de “variaçào de quantidade”.

Variações de preços (PV) * 723 ocorrem quando o va­ lor do preço orçado (COTA) dos materiais é diferente

Adaptado de: FLEMING, Quentin W. Cost/chedule control sys­ tems criteria. Chicago: Probus Publishers, 1992. p. 151-152. KT-' Variações de Preços. Da expressão em inglês. Price Variances (PV).

•

Adaptado de: FLEMING, Quentin W. Cost/schedule control sys­ tems criteria. Chicago: Probus Publishers, 1992. p. 144-145.

Os planos de materiais (COTA): estes frequente­ mente começam no ponto em que a engenharia ou a produção ou outros, tenham fornecido uma definição suficiente para iniciar uma ordem para os itens, independentemente de quando tais itens serào realmente pedidos ou recebidos. Os custos reais de materiais (CRTR): este, normal­ mente, é o ponto no qual os custos das peças são registrados nos livros contábeis da empresa, isto é, quando a fatura c paga.

491

CONTROLE DOS CUSTOS

do que foi realmente vivenciado (CRTR). Essa condição pode ocorrer por causa de uma série de razões: estima­ tivas iniciais ruins, inflação, utilização de materiais dife­ rentes dos que foram planejados, muito pouco dinheiro

Boas práticas de negócios indicam que tais análises da variação ocorrem para determinar porque os custos re­ ais de materiais excedem os valores orçados de materiais.

disponível para o orçamento, e assim por diante.

15.13 VARIAÇÕES RESUMIDAS

A fórmula para a variação de preços (PV) é: PV = (Preço orçado - Preço real) x (Quantidade real)

A variação de preços é a diferença entre o custo or­ çado para a lista de materiais e o preço pago pela lista de materiais. Por sua vez, as variações de quantidade (UV) ™ * ocorrem quando é consumida uma quantidade maior de materiais do que estava previsto. A fórmula para a varia­ ção de quantidade (UV) é: UV = (Quantidade orçada = Quantidade real) X (Preço orçado)

Normalmente, as variações de quantidade são os custos decorrentes de materiais utilizados acima da quan­ tidade requerida na lista de materiais.

Considere o seguinte exemplo: o gerente de projetos estabelece um orçamento de materiais de 100 unidades (o qual inclui 10 unidades de fator de descarte) a um preço de $ 150 por unidade. Portanto, o orçamento de materiais foi lixado em S 15.000. Ao final do pequeno projeto, os custos reais dos materiais (CRTR) ficaram em S 15.950, que estava $ 950 acima do orçamento. O que aconteceu? Aplicando as fórmulas definidas anteriormente, Variação de preço (PV) = (preço COTA - preço CRTR) x Quantidade real = ($ 150 por unidade

S 145 por unidade) x 110 unidades

= $ 550 favoráveis

Variação de quantidade (UV)

(qtd. COTA - qtd. CRTR) X Preço COTA = (100 unidades - 110 unidades) x $ 150 por unidade

$ 1.500 desfavoráveis

A análise indica que seu preço de compra foi menor do que o previsto, portanto, gerando uma economia de custos. No entanto, você usou 10 unidades a mais do que o planejado, gerando, assim, uma variação de quantidade desfavorável. Uma investigação mais profunda indicou que o seu gerente de linha tinha aumentado o fator de descarte de 10 para 20 unidades.

M:* Variações de Quantidade. Da expressão em inglês, Usage Variances

(UV).

As variações resumidas podem ser calculadas tanto para a mão de obra quanto para os materiais. Considere as in­ formações mostradas a seguir: Materiais Diretos Preço/Undode Plcn^odos

S

30,00

Mão de Obro Direto $

17.853

Uridodes Reots Preço/Unidodes Recis

$

Custo Red

$554.630

31,07

|

24,30 9.000

$

26,24

$236.200

Nós agora podemos calcular a variação total de pre­ ço para os materiais diretos e a taxa da variação de custos: • Variação de preço total para os materiais diretos = Unidades reais x (COTR - CRTR)

= 17.853 x (5 30,00-$31,07) = $19.102,71 (desfavorável) • Taxa da variação de custos de mào de obra = Taxa orçada - Taxa real

= $ 24,30 - S 26,24 = $ 1,94 (desfavorável) 15.14 RELATÓRIO DE ANDAMENTO

Uma das melhores formas de reduzir a intromissão executi­ 10.2.2.5 Relatórios de va nos projetos é fornecer aos desempenho executivos relatórios de anda­ mento frequentes e significativos. A Figura 15-24 mostra um relatório de andamento relativamente simples, baseado no acúmulo de dados no formato das Figuras 15-25 e 15-26. Esses tipos de relatório de andamento devem ser curtos e concisos, contendo apenas informações pertinentes. O an­ damento também pode ser mostrado graficamente como na Figura 15-27. A diferença entre a Figura 15-27 e a Figura 15-17 éque as estimativas no término foram identificadas. Guia PMBOK; 5. ed.

Da mesma forma que o software de gerenciamen­ to de projetos disponível se torna mais sofisticado, assim também ocorre com os relatórios do projeto. Existem quatro tipos de relatórios que geralmente são impressos a partir do sistema de medição do valor agregado: • Relatórios de Desempenho: indicam a evolução física até o momento, ou seja, COTA, COTR e CRTR. O relatório também pode incluir informa­ ções sobre aquisições de materiais, entrega e quan­ tidade, mas a maioria das empresas possui relató­ rios separados sobre os materiais.

492

Gerenciamento de Projetos

• Relatórios de Andamento: identificam onde esta­

1. MUSE CA MM» (CJ5KS «r irirns

Sutarda

1 2 3 4 5 6 7 1

/ídarrerro tos Votos

(cnduàto (ordiito Ccrxtoà» Não iodado (catoxto Não rctóo Ifiofc Nõonxiodo

Tool

Gfito Orcoto doHdic fedLoío

GfitoRed

0

100 50 50 0 90 0 50 0

450

340

içenfato

100 50 50 70 90 40

Wo5

Custos

100 55 40 0 140 0 25 0

0 0 0 ■100 0 -100 0

0 -10 20 — 55.5 50

futuras. Esses relatórios enfatizam onde vamos terminar.

360

-24.4

-5.9

• Relatórios de Exceção: identificam exceções, pro­

LKSMOKOSIOS Os custa esã: sento execjoda 5,9%oãnKdoo^errodatrõodeobíodesolãiosmo6Gtos.

4.KSUM0KCKMNMA Aamkõode atawde24,4\ Míronogranose de» àsU *wlas 4 e 6, (jue onto nõo conecaarr em rrUfe óc falo de tntfefajíto e do rréroóo 50/50 pao teseno de custa As haos exnas nos tiaõo (to sdt cd aonoçrcrro. mas o um custo odao-d de 2,5% de custa de mão de dxo freta

5 KlAtóWMUAKOS

1

Coedsco Ag«fato

em itens como variações, fluxo de caixa, recursos designados e outros tópicos.

Os procedimentos de relatório para a análise da va­ riação devem ser os mais breves possíveis. A razão para

isso é simples: quanto mais curto e conciso for o relató­ rio, mais rápido o feedback pode ser gerado e as respostas

Conclusão teal

7/1/10

B

tiver de ser realizada com recursos limitados. As duas si­ tuações mais comuns que geram restrições na reprogra­

6/1/10

mação de recursos são as seguintes:

ffl

E

desenvolvidas. O tempo é crítico se uma reprogramação

• A data final está fixada • Os recursos disponíveis são constantes (ou

6 KUÍÔBOM ftWOS hotterc Atai

Irrito Pctexd

AtòoCoreirt

(o) folio de mtféèjrrro

(ocdcõc de sobeecuslo e oínsono(ioft)çctTD

Horns atas esiõo oçeritodcs fertararos rtíra pessoas car sdótos menores AsTtfacs-pira derem cheça oo perto ro pronta sema».

Pode jwasa de pfcrm o VMM, o tempo no término e custo no término ainda são usados, mas intro­ duzimos um novo termo intitulado valor (ou benefícios) no término. A determinação do valor no término deve ser feita periodicamente durante todo o projeto. No entanto, a reavaliação periódica dos benefícios e do valor no tér­ mino pode ser difícil porque: • Não pode haver nenhum processo de reexame. • A administração não está comprometida e acredi­ ta que o processo de reexame é irreal. • A administração é muito otimista e complacente com o desempenho existente. • A administração está cega por altos lucros incomuns em outros projetos (interpretações erradas). • A administração acredita que o passado é uma in­ dicação do futuro.

Uma avaliação do valor no término pode nos dizer se são necessárias compensações no valor. Razões para compensações no valor incluem: • Alterações nos fatores ambientais da empresa

508

Gerenciamento de Projetos

• Mudanças nas premissas • Melhores abordagens foram encontradas, possi­ velmente com menor risco • Disponibilidade de mão de obra altamente qualificada • Um avanço na tecnologia Como afirmado anteriormente, a maioria das com­ pensações em valor é acompanhada por um alongamen­ to do cronograma. Dois fatores críticos que devem ser considerados antes que o alongamento do cronograma ocorra são:

âmbar significava que a data-alvo de término tinha pas­ sado e o projeto ainda não estava completo. A cor roxa significava que aquele pacote de trabalho estava passando por uma mudança de escopo que poderia ter impacto so­ bre as restrições triplas. Algumas pessoas confundem dashboards com score­ cards. Há uma diferença entre dashboards e scorecards. De acordo com Eckerson18:

• Dashboards são mecanismos de apresentação visu­ al utilizados em um sistema de medição de desem­ penho orientado operacionalmente, que mede o desempenho em relação a metas e limites, utilizan­ do dados em tempo certo. • Scorecards são mecanismos de apresentação visual utilizados em um sistema de medição de desem­ penho orientado estrategicamente, que mapeiam o progresso no sentido de alcançar as metas e os objetivos estratégicos, comparando o desempenho em relação às metas e limites.

• Prolongar um projeto para um valor desejado ou adicionado pode incorrer em riscos. • Prolongar um projeto consome recursos que já podem ter sido comprometidos com outros pro­ jetos no portfolio.

Ferramentas e técnicas tradicionais podem não fun­ cionar bem em projetos orientados a valor. A criação de um VMM pode ser necessário para alcançar os resultados desejados. Um VMM pode incluir as funcionalidades de um sistema de gerenciamento de valor agregado (EViMSs) e de sistemas empresariais de gerenciamento de projetos (EPMs), mas outras variáveis devem ser incluídas para a captação, medição e comunicação de valor.

15.21

DASHBOARDS E SCORECARDS

Em nossa tentativa de migrar para o gerenciamento de projetos sem papel, a ênfase tem sido dada em apresen­ tações visuais, como dashboards e scorecards. Executivos e clientes desejam uma apresentação visual das informa­ ções de desempenho mais críticas do projeto no mínimo espaço. Técnicas simples de dashboard, tais como relató­ rios de semáforo, podem transmitir informações críticas desempenho. Como exemplo,

• Sinal vermelho: Existe um problema que pode afe­ tar tempo, custo, qualidade ou escopo. É necessá­ rio o envolvimento do patrocinador. • Sinal amarelo ou âmbar: Cautela. Talvez, no futu­ ro, poderá existir um problema potencial, se não for monitorado. O patrocinador é informado, mas nenhuma ação é necessária nesse momento. • Sinal verde: O trabalho está progredindo confor­ me o planejado. Nenhum envolvimento do patro­ cinador é necessário.

Embora o dashboard de semáforo com apenas três cores seja o mais comum, algumas empresas utilizam muito mais cores. O grupo de TI de um revendedor tinha um dashboard de oito cores para os projetos de Tl. A cor

Tanto dashboards como scorecards sào mecanismos de apresentação visual dentro de um sistema de medição de desempenho que transmitem informações críticas. A principal diferença entre eles é que dashboards moni­ toram processos operacionais, tais como os usados em gerenciamento de projetos, enquanto os scorecards ma­ peiam o progresso dos objetivos táticos. A Tabela 15-14 e a descrição seguinte mostram como Eckerson compara as características de dashboards e scorecards19. TABELA 15-14 Comparando características Coradertslko

Dashboard

Storecard

hepesrto

-Vede o desempenho

Vcpao o pioçresso

Usuários

Supervrsoces, especialistas

Executes, gerentes e pessocl

Atadizocoes

Aruduaoes em tampo certo

Fotografias penedeos

Dodos

Eventos

Sumários

Vtsuolcoçõo

Gráficos ytsucts, dodos brutos

Gráficos «uais, comentários

Dashboards. Dashboards são como painéis de automóveis. Eles permitem que especialistas operacionais e seus supervisores monitorem os eventos gerados por processos chave de negócios. Mas diferentemente de automóveis, a maioria dos dashboards de negócios não exibem os even­ tos em “tempo real”, à medida que ocorrem; eles

”

Veja a obra mencionada na nota 9, p. 293, 295. O Capítulo

12 fornece uma abordagem excelente para projetar telas dc

dashboard. ”

Veja a obra mencionada na nota 9, p. 13.

509

CONTROLE DOS CUSTOS

são exibidos em "tempo certo” à medida que os usuários precisam visualizá-los. Isto podería ser a cada segundo, minuto, hora, dia, semana ou mês, dependendo do processo de negócio, da sua vo­ latilidade, e de quão crítico é para o negócio. No entanto, a maioria dos elementos em um dash­ board é atualizada em uma base intradia, com latência medida em minutos ou horas.

Embora os termos sejam usados indistintamente, a maioria dos gerentes de projetos prefere usar dashboards e/ou relatórios de dashboard. Eckerson define três tipos de dashboards, como mostrado na Tabela 15-15 e na des­ crição a seguir0: Os dashboards operacionais monitoram pro­ cessos operacionais essenciais e são usados principalmente por trabalhadores da linha de frente e seus supervisores, que lidam direta­ mente com clientes ou gerenciam a criação ou a entrega dos produtos e serviços da organização. Os dashboards operacionais entregam essencial­ mente informações detalhadas que estão apenas levemente resumidas. Por exemplo, um comer­ ciante web pode monitorar as transações em relação ao produto, em vez de monitorá-las por cliente. Além disso, a maioria das métricas em um dashboard operacional são atualizadas em uma base intradia, variando de minutos a ho­ ras, dependendo da aplicação. Como resultado, os dashboards operacionais enfatizam o moni­ toramento mais que a análise e gerenciamento.

Os dashboards muitas vezes exibem o desem­ penho visualmente, usando tabelas ou gráficos simples, como indicadores e medidores. No entanto, os gráficos do dashboard são frequen­ temente atualizados no local, fazendo com que o gráfico “pisque” ou se altere dinamicamente. Ironicamente, as pessoas que monitoram pro­ cessos operacionais, muitas vezes acham o bri­ lho visual perturbador e preferem ver os dados em sua forma original, como números ou texto, talvez acompanhados por gráficos visuais.

Scorecards. Scorecards, por outro lado, parecem mais com gráficos de desempenho, utilizados para acompanhar o progresso em direção ao cumpri­ mento das metas. Os scorecards normalmente exi­ bem retratos mensais de dados resumidos para os executivos que acompanham os objetivos es­ tratégicos e de longo prazo, ou retratos diários e semanais de dados para os gerentes que precisam traçar o progresso do seu grupo de projeto para atingir as metas. Em ambos os casos, os dados sào bastante resumidos para que os usuários possam ver rapidamente seu status de desempenho.

Os dashboards táticos acompanham processos departamentais e projetos que são de interesse de um segmento da organização ou de um gru­ po limitado de pessoas. Gerentes e analistas de negócios usam os dashboards táticos para com­ parar o desempenho de suas áreas ou projetos a planos de orçamento, previsões, ou os resultados do último período. Por exemplo, para reduzir o número de erros em um banco de dados de cliente, um projeto pode usar um dashboard tá­ tico para exibir, monitorar e analisar o progresso durante os 12 meses anteriores até atingir 99,9% de dados de clientes livres de defeitos até 2007.

Como os dashboards, os scorecards também fa­ zem uso de tabelas e gráficos visuais para indi­ car o estado do desempenho, tendências e variância em relação às metas. Quanto mais alto são os usuários estão na organização, mais eles pre­ ferem ver o desempenho codificado visualmen­ te. No entanto, a maioria dos scorecards também contém (ou deve conter) uma grande quanti­ dade de comentários em texto, que interpretam os resultados de desempenho, descrevem a ação tomada, e as previsões de resultados futuros.

Resumo. No final, realmente não importa se você usa o termo dashboard ou scorecard, desde que a ferramenta ajude os usuários e as organizações a manterem o foco no que realmente importa. Tan­ to os dashboards como os scorecards precisam exi­ bir informações críticas de desempenho em uma única tela para que os usuários possam acompa­ nhar os resultados com uma olhada rápida.

Dashboards estratégicos monitoram a execução dos objetivos estratégicos e, muitas vezes, são implementados por meio da abordagem de Ba­ lanced Scorecard, embora a Gestão da Qualidade Total, Six Sigma e outras metodologias também sejam utilizadas. O objetivo de um dashboard estratégico é alinhar a organização em torno de objetivos estratégicos e fazer com que cada gru­ po marche na mesma direção. Para fazer isso, as organizações lançam scorecards personalizados para cada grupo na organização e, por vezes, para cada indivíduo também. Esses scorecards

28

Veja a obra mencionada na nota 9, p. 17-18.

510

Gerenciamento de Projetos

“em cascata”, que normalmente são atualizados semanalmente ou mensalmente, dão aos execu­ tivos uma ferramenta poderosa para comunicar a estratégia, ganhar visibilidade das operações e identificar os fatores chave de desempenho e o valor do negócio. Os dashboards estratégicos enfatizam o gerenciamento mais que monitora­ mento e análise.

TABELA 15-15 Trés tipos de dashboarde desempenho

Propósito

Usuónos

Operational

Tático

Estratégico

/Aomterar as operações

Medir o progresso

Executar o estratégia

Superiores,

especkftsios

Gerentes, ondrstos

Exeatws, gerentes, pessool

Escopo

Operoacnd

Deportomaiid

Empreso

Infant

Detalhada

Detdhoda/resumidc

Detofado/resucnido

Aluaíizcxóes

Inlrada

Otános/semonas

Mens®/ mmestrors

Ênfase

Moritoramenta

Análise

Gereocknento

Há três passos críticos que devem ser considerados ao se utilizar dashboards: (1) o público-alvo do dashboard, (2) o tipo de dashboard a ser utilizado, e (3) a frequência em que os dados serão atualizados. Alguns dashboards de projeto focam nos indicadores chave de desempenho que fazem parte da medição de valor agregado. Esses dash­ boards podem precisar ser atualizados diariamente ou semanalmente. Os dashboards relacionados com a saúde financeira da empresa podem ser atualizados semanal­ mente ou trimestralmente.

15.22

BUSINESS INTELLIGENCE n

As empresas têm utilizado o conceito de business intelli­ gence (BI) por mais de duas décadas. Nos últimos anos, as aplicações de business intelligence foram substituídas por aplicações de inteligência estratégica (Sl). Ambas são pro­ jetadas em torno do controle e vigilância das métricas de negócios. De acordo com Corine Cohen21:

O campo geral de vigilância abrange noções de observação, digitalização, inteligência, inte­ ligência competitiva, vigilância, inteligência de negócios, inteligência econômica, inteligência econômica e estratégica etc. Sl é definida aqui como um processo formal de investigação, coleta, processamento de informa­ ção e distribuição de conhecimento útil para o Business Intelligence (BI) pode ser traduzido como inteligência

11

de negócios, ou inteligência empresarial. COHEN, C. Business intelligence. Hoboken, NJ: Wiley c ISTE Publishers Ltd, 2009. pg. xiii.

gerenciamento estratégico. Além de sua função de informação, os principais objetivos do Sl sào antecipar ameaças e oportunidades ambien­ tais (função antecipatória), ajudar na tomada de decisões estratégicas e melhorar a competi­ tividade e o desempenho da organização. Isso requer uma estrutura de rede organizacional e recursos humanos, técnicos e financeiros. Deve ser feita uma distinção entre Strategic Wa­ tch e SI. SI vai além de Strategic Watch com a sua protividade e envolvimento mais profundo no processo de decisão estratégica. O Strategic Watch pode (e deve) indicar os impactos de um evento detectado, por exemplo. No entan­ to, apenas torna-se inteligência quando produz recomendações e fornece instruções para o des­ tinatário (e ainda mais quando as implementa). As aplicações de BI e SI nos ensinaram que a nossa forma de tentar monitorar e controlar os projetos deve mudar. Em um ambiente de gerenciamento de projetos, o BI seria representado por métricas, e o SI seria repre­ sentado por indicadores chave de desempenho (KPls). Indicadores chave de desempenho sào as métricas “estra­ tégicas” que nos fornecem informações críticas para a to­ mada de decisão informada. Métricas de BI simplesmen­ te monitoram as métricas, enquanto métricas de Sl, ou KPls, fornecem informações sobre o futuro e não apenas do presente, e indicam as mudanças que possam ser ne­ cessárias. Já que os gerentes de projeto de hoje e do futuro se tornarão mais orientados a negócios, o relacionamento entre métricas, BI e SI vai se tornar mais importante. 15.23

INFOGRÀFKOS

O crescimento da importância das métricas, KPIs, dash­ boards e aplicações de business intelligence têm sido espe­ tacular. Infelizmente, o resultado tem sido muitas vezes sobrecarga de informações, principalmente com sistemas de relatórios de dashboard. Hoje, temos a tendência de adi­ cionar mais arte do que precisamos, uma tendência que re­ sultou em um novo termo “infográfico”. Alguns problemas com o crescimento de infográficos incluem o seguinte:

• Há um foco pesado sobre design, cores, imagens e texto, em vez da na qualidade da informação que está sendo apresentada. • O declínio na qualidade da informação faz com que seja difícil para as partes interessadas utilizar os dados corretamente. • Há muitos gráficos bonitos que podem ser enga­ nosos e difíceis de entender.

511

CONTROLE DOS CUSTOS

■ O dashboard foi convertido de uma ferramenta de gerenciamento de desempenho do projeto para uma ferramenta de inarketing/vendas. • Alguns artistas gráficos não entendem ou não utilizam as melhores práticas de visualização da informação.

Devemos ter uma representação melhor e mais clara das métricas que selecionamos. 15.24

As seguintes questões de múltipla escolha ajudarão na revisão dos conceitos deste capítulo:

1. Na medição do valor agregado, o valor agregado é representado por: a. COTA b. COTR c. CRTR d. Nenhuma das anteriores 2.

Se o COTA = 1.000, COTR = 1.200 e o CRTR = 1.300, o projeto está a. Adiantado no cronograma e abaixo do orçamento b. Adiantado no cronograma e acima do orçamento c. Atrasado no cronograma e acima do orçamento d. Atrasado no cronograma c abaixo do orçamento

3.

Se o ONT = $ 20.000 e o projeto está 40% concluí­ do, então o valor agregado é: a. $5.000 b. $8.000 c. $20.000 d. Não pode ser determinado

4.

Se o ONT = $ 12.000 e o IDC = 1,2, então a varia­ ção no término é: a. -$ 2.000 b. +$2.000 C. -$ 3.000 d. +$ 3.000

5.

Se o ONT = $ 12.000 e o IDC = 0,8, então a varia­ ção no término é: a. -S 2.000 b. +$ 2.000 c. -$3.000 d. +$ 3.000

6.

Se o ONT para um pacote de t rabalho é $ 10.000 e o COTR = S 4.000, então o pacote de trabalho está: a. 40% concluído b. 80% concluído c. 100% concluído d. 120% concluído

7.

Se o IDC = 1,1 e o IDP = 0,95, então a tendência para o projeto é: a. Ficar acima do orçamento e adiantado no cronograma b. Ficar acima do orçamento e atrasado no cronograma c. Ficar abaixo do orçamento e adiantado no cronograma d. Ficar abaixo do orçamento e atrasado no cronograma

DICAS DE ESTUDO PARA 0 EXAME DE CERTIFICACÃO EM GERENCIAMENTO DE PROJETOS PMI®

Esta seção aplica-se à revisão dos princípios de apoio às áreas de conhecimento e grupos de processos do Guia PMBOK®. Este capítulo aborda: • • • • •

Gerenciamento do Escopo Gerenciamento dos Custos Iniciação Planejamento Controle

A compreensão dos princípios a seguir será benéfica se o leitor estiver utilizando este livro como estudo para o Exame de Certificação PMP®: • O que se entende por sistema de controle e gestão de custos • O que se entende por medição do valor agregado • O significado de controle • O código das contas de custos • Autorização do trabalho e sua relação com o códi­ go de contas • Fontes de financiamento para um projeto ou mu­ danças em um projeto • Quatro elementos primários de monitoramento e controle de custos: COTA, COTR, CRTR e ONT • Como calcular as variações de custos e prazos, em horas, dólares e porcentagens • Importância do IDP e do IDC na análise das tendências • Maneiras de prever o tempo e o custo no término, bem como as variações no término • Diferentes tipos de relatórios: desempenho, anda­ mento, previsões e exceção • Utilização da reserva de gerenciamento • Fatores de escalonamento e como eles afetam um projeto • O que é uma linha de base financeira ou de custos de um projeto • Diferentes formas de calcular ou COTR ou o per­ centual concluído

512

Gerenciamento de Projetos

8.

9.

15. Sc um gerente dc projetos está buscando uma recei­ ta para uma mudança de escopo de valor adiciona­ do, a primeira escolha do gerente dc projetos seria: a. A reserva de gerenciamento b. Uma mudança de escopo financiada pelo cliente c. O orçamento não distribuído d. Lucros retidos

O documento que descreve um pacote dc trabalho identifica os centros de custos autorizados a cobrar pelo pacote de trabalho c estabelece um número dc cobrança para esse pacote de trabalho é: a. O código de contas b. A estrutura analítica do projeto c. O formulário de autorização do trabalho d Nenhuma das anteriores

16. Um projeto foi programado originalmente em 20 meses. Se o IDC é 1,25, então a nova data de cro­ nograma é: a. 16 meses b. 20 meses c. 25 meses d. Não pode ser determinada

Problemas desconhecidos, como fatores dc escalo­ namento são geralmente orçados para utilizar o: a. Número dc cobrança do gerente do projeto b. Número de cobrança do patrocinador do projeto c. A reserva de gerenciamento d. A conta de custos do gerenciamento da con­ figuração

17. A linha de base financeira ou dc custos de um pro­ jeto é composta de: a. Apenas do orçamento distribuído b. Apenas dos orçamentos distribuído e não dis­ tribuído c. Apenas do orçamento distribuído, do orçamen­ to não distribuído c da reserva dc gerenciamento d. Apenas do orçamento distribuído, do orçamen­ to nào distribuído, da reserva dc gerenciamento e do lucro

10. ENT, EPT, IDP c IDC aparecem mais frequente­ mente em que tipo de relatório? a. Desempenho b. Andamento c. Previsões d. Exceção 11. Se o ONT = $ 24.000,o COTR = 12.000,o CRTR = S 10.000 e o IDC = 1,2, então o custo que falta para concluir o projeto é: a. S 10.000 b. $ 12.000 c. S 14.000 d. Não pode ser determinado

RESPOSTAS I. B 2.B 3.B 4. B 5.C 6. A 7 D 8.C 9. C II. A

12 B

15-2

13. Quando um projeto é concluído, qual das seguin­ tes alternativas deve ser verdadeira? a. ONT = CRTR b. CRTR = COTR c. VPR = 0 d. Iodas acima 14. Em março a VC = -$ 20.000 e em abril a VC = -S 30.000. Para determinar se uma situação está ou não realmente deteriorada por causa de uma grande va­ riação desfavorável dc custos, precisaríamos calcular: a. o percentual da VC b. os dólares da VPR c. O percentual da VPR d. Todas as anteriores

I4.A 15.B

16. D

10. C

I7.B

EXERCÍCIOS 15-1

12. Existem vários propósitos para a regra 50/50, mas o propósito principal da regra 50/50 é calcular: a. COTA b. COTR c. CRTR d. ONT

13.C

15-3

Os sobrecustos simplesmente ocorrem ou são provocados? Os cemitérios estão cheios de projetos que fica­ ram fora de controle. Abaixo estão várias causas que podem facilmente se transformar em con­ dições de perda de controle. Em qual fase de um projeto cada uma dessas condições deve ser de­ tectada e, se possível, remediada? a. Os requisitos do diente nào sào compreendidos b. A equipe de projeto formada após a licitação estava despreparada c. Aceitação de termos e condições incomuns d. Permissão de um prazo de carência para alterar as especificações c. Falta dc tempo para pesquisar as especificações f. Superestimaçào das capacidades da empresa A seguir estão vários fatores que podem resultar cm atrasos no projeto c desvios nos custos. Expli­ que como esses problemas podem scr superados. a. Marcos mal definidos b. Técnicas de estimativa deficientes c. Ausência de um gráfico PERT/CPM

513

CONTROLE DOS CUSTOS

d. Os gerentes funcionais não terem um enten­ dimento claro do que tem de ser feito e. Procedimentos e técnicas de programação deficientes f. Mudanças sendo feitas constantemente dentro do ciclo dc vida do projeto 15-4 Em quais circunstâncias cada uma das figuras do Capítulo 13 seriam aplicáveis para o relató­ rio ao clicntc? E para o relatório interno? E para o relatório para a alta administração? 15-5 Qual impacto havería no COTA, no COTR, no CRTR, e nas variações de custos e prazos como resultado do: a. Início mais cedo de uma atividade em um gráfico PERT? b. Início mais tarde dc uma atividade em um gráfico PERT? 15-6 A Alpha Company implementou um plano pelo qual os gerentes funcionais seriam totalmenle responsáveis por todos os sobrecustos (dos ge­ rentes funcionais) cm relação às suas estima­ tivas iniciais. Além disso, todos os sobrecustos devem sair dos orçamentos dos gerentes fun­ cionais, fossem eles overhead ou não, c não do orçamento do projeto. Quais são as vantagens c desvantagens dessa abordagem? 15-7 Karl decidiu manter uma reserva de gerencia­ mento cm um projeto dc S 400.000, que inclui um lucro de $60.000. No término do projeto, Karl descobre que a reserva de gerenciamento contém $ 40.000. Karl deveria registrar a reserva de ge­ renciamento como excedente de lucros (ou seja, $ 100.000), ou deveria registrar apenas o lucro-alvo de S 60.000 e deixar os gerentes funcionais se “protegerem” no “caixa dois” ate que ele se esgote? 15-8 A ABC (Corporation encaminhou recentemente um contraio de nove meses a um empreiteiro subcontratado. Ao final do primeiro mês, fica evidente que o subcontratado não está relatan­ do os custos de acordo com um nível adequado da EAP. A ABC Corporation pede ao subcontra­ tado para mudar seus procedimentos de relató­ rio de custos. O subcontratado declara que isso nào pode ser feito sem financiamento adicional. Esse problema também já ocorreu com outros subcontratados. O que a ABC Corporation pode fazer a respeito disso? 15-9 Qual seria o resultado se todos os gerentes de projetos decidissem reter reserva de gerencia­ mento? Quais critérios deveríam ser utilizados para a determinação de quando uma reserva de gerenciamento e necessária? 15-10 A Alpha Company, uma organização orientada a projetos, paga aos seus gerentes de departamento um bônus trimestral que é dependente de dois fatores: da taxa de overhead do departamento c do dinheiro dc mão de obra direta. O valor exato do bônus é proporcional ao quanto esses dois fa­ tores estão abaixo do planejado.

15-11

15-12 15-13

15-14

A quantidade de homens-horas do departa­ mento é estimada contra a média do depar­ tamento, que não inclui o salário do gerente do departamento. Seu salário é incluído em sua taxa de overhead do departamento, mas ele tem a opção de cobrar seu próprio tempo como mão de obra direta aos projetos para os quais deve fornecer recursos. O que você acha desse método? Trata-se de um incentivo adequado para um gerente funcional controlar os recursos mais eficazmente? Como você se sentiría, como gerente de projetos, sa­ bendo que os gerentes funcionais tem bônus trimestrais e você não tem nenhum? Muitos executivos são relutantes em permitir que os gerentes de projetos tenham o controle completo dos custos do projeto porque assim eles devem saber exatamente os salários de qua­ se todo o pessoal do projeto. Essa situação pode­ rá ser evitada se o contrato exigir o informe dos custos como reais? Como uma taxa de inflação de um país pode in­ fluenciar a política de pagamento contratual? Considere uma situação em que várias tarefas podem ter de um a dois anos em vez das 200 horas normalmente utilizadas para o nível de pacote de trabalho da EAP. a. Como isso afetará o controle dc custos? b. Ainda podemos usar a regra 50/50? c. Com que frequência os custos devem ser atualizados? Agora você deve estar familiarizado com as vá­ rias ferramentas que podem ser utilizadas para o planejamento, o controle, a programação e a direção das atividades do projeto. A Tabela 15-16 contem uma lista parcial de ferramentas e como elas se relacionam com funções espe­ cíficas de gerenciamento do projeto. Complete a tabela (usando a legenda na parte inferior) para indicar quais ferramentas são muito úteis e quais são mais ou menos úteis.

TABELA 15-16 Planejamento, controle e direção do projeto uni PARA

Mon^,men,°íon,,0,e D'e'00

Fenomento Orgonogromos dc propto Estruturo onoiirko do projeto

Descnções dos tarefas

Pacotes de trabalho

Orçamento do projeto Pleno dc projeto Grcfaos/aonogromas

Relatórios de progresso Reuniões de nroloçõc Omás ou menos úti

•muito úti

lZ«e

514

Gerenciamento de Projetos

Obviamente haverá algumas perguntas sobre o que é muito útil e o que é mais ou menos útil. Seja capaz de defender as suas respostas. 15-15 Complete a tabela a seguir e trace a ENT como uma função de tempo. Quais são as suas conclusões?

Em 27 de agosto de 2002, o comitê diretor re­ cebeu o seguinte relatório indicando o anda­ mento do projeto ao final da oitava semana: Tempo Restante Atividade

X Condado

Custo Real

AB

100

$23,500

0

AC

60

19,200

4

AO

87.5

37,500

1

BC

50

8,000

2

BE

50

5,500

1

(Semanas)

O comitê diretor não conseguiu identificar o andamento real do projeto a partir desse bre­ ve relatório. Mesmo depois de compará-lo ao orçamento do planejamento do projeto (ver Tabela 15-18), o andamento real não estava facilmente aparente. A administração incumbiu o gerente do projeto de elaborar um relatório melhor que mostrasse o verdadeiro andamento do projeto, bem como a quantidade de lucro que poderia ser esperada no término do pro­ jeto. Sua atribuição é elaborar uma tabela como a Tabela 15-12.

15-16 Utilizando as informações no Capítulo 12, Exer­ cício 12-18, preencha a Tabela 15-17. 15-17 Em 12 de junho de 2002, a Delta (Corporation re­ cebeu a concessão de um contraio de $ 160.000 para o leste de um produto. O contrato consistia de $ 143.000 para mào de obra e materiais, e os restantes $ 17.000 eram lucro. O contrato tinha uma data dc início agendada para 3 de julho. A rede lõgica, conforme definida pelo gerente do projeto e aprovada pelo cliente, consistia do seguinte: TABELA 15-17 Custos do projeto

1

2

Atividade

Peaentud Concluído

3

4

5

Casto Oriodo do

Casto Orcododo

Custo Real do

Trabalho Agendado

Trabalho Realizado

Trabaho Realizado

Total Vúrioçõo de Castos (S) = Cdu*o 4 - CoLno 5 =____________

Vcrioçõo de Prazos (S)=(djd 4 - (dum 3=____________

(jJC

Custo no isirino = toa de gosta i açanerto Md -

j

i(

) =_______________

Custo pxa lerfrrcf = (Custo no témwo) — CRTR -__________________

6

7

Variação de Custos = 4-5

Variarão de Prazos = 4-3

515

CONTROLE DOS CUSTOS

TABELA 15-18 Orçamento do planejamento do projeto

•Ma A lobdc conufe» que o percecid é Inea em terrpo e não brecr w cjsIds

15-18 O Projeto da Máquina-Ferramenta Alpha A Acme Corporation recebeu um pedido contratual para construir uma máquinaferramenta nova para a Alpha Corporation. O projeto começou há vários meses. A Tabela 15-19 representa o resumo dos custos men­ sais para junho de 2002. Algumas das entra­ das na tabela foram propositadamente omiti­ das, mas as seguintes informações adicionais sào fornecidas para ajudá-lo a responder as perguntas a seguir:

forma, 80% das economias de custos inferiores ao custo-alvo retornam para a Alpha. d. A EAP revisada é revista a partir do COTA liberado. c. O preço máximo c baseado no custo (ou seja, sem lucros). Responda as seguintes perguntas, por meio da extração dc dados do relatório de resumos men­ sal do Projeto da Máquina-Ferramenta Alpha. 1. Qual o valor-alvu total negociado do contraio? 2. Qual é o valor-alvo orçado para todo o tra­ balho autorizado sob esse contrato? 3. Qual o valor orçamentário total que a Acme tinha originalmente alocado/liberado para o Projeto Alpha? 4. Qual o valor novo/revisado orçamentário to­ tal que a Acme liberou para o Projeto Alpha?

a. Suponha que o overhead de 100% c fixo durante o período de execução. b. O relatório que você está recebendo é de um final de mês, de 30 de junho de 2002. c. A relação de divisão 80/20 diz que o cliente (ou seja, a Alpha) pagará 80% dos dólares acima do custo-alvo e até o custo máximo. Da mesma TABELA 15-19 Resumo mensal de custos - junho de 2002 Contrato:

Alpha Machine Tool

Custo Negociado:

S 2.500.000

Razão da drvisõo:

GP:

Remunerocoo-atvo: Preço-alvo:

12%

limite máximo:

Penodo do Relatório:

Gary Jones 1 de junho 30dejunhode2010

2.800.000

Contrato:

Periodo do Contrato:

1 de fev. 30 de outubro de 2010

Mês Atual, $

80/20 k t A O •• l j.uuu.uw em custos t=> * no preto; preço fixo com remuneração de incentivo

No Término, S

Cumulativo até a dota.S

MMI2

COTA

Itens do EAP

COTA

COTR

Gcranaomcnto oo

19300

19300

Program) SdrsBlaitA

23000

Subástem: 3

14000

S-bststem: C

0

0

Apoo ò proCiXDO

11600

10400

Contde do (jxfcflfe

5900

CUSTO DRETO TOTAL

ovww i oos TOTAL

COU Original

COTA

VPR

VC

COU

COTR

cure

VPR

VC

19300

0

0

108000

108000

108000

0

0

203000

200000

200000

16603

24200



158000

181700

234700

23700

250000

200000

225000

15200

16800

1203

96000

94200

93000

1200

200000

200000

230003

0

0

0

0

0

0

300000

275000

275000

12000



73000

74300

75600

1300

203300

190000

190000

6000

6000

100

0

5900

6000

6000

100

103000

130000

130000

73800

67500

78300

73800

67500

78300

1250000 1165000 1190000

147600

135000

156600

2503000 2330000 2380000

CRTR

0

0

0

Contratado liberado

Revisado

1250000 1165000 1190000

Vor.

516

Gerenciamento de Projetos

5. Quanto dinheiro, caso houvesse, a Acme teria estipulado como reserva de gerenciamento, com base no orçamento original liberado? (com encargos) 6. A reserva de gerenciamento foi revisada e, cm caso afirmativo, cm quanto? (com encargos) 7. Quais elementos do nível-2 da EAP com­ põem a reserva de gerenciamento revisada? 8. Com base nos custos de término do COTA revisado, quanto lucro a Acme pode esperar fazer com o Projeto Alpha? (Dica: nào se es­ queça da razão de partilha) 9. Quanto do orçamento distribuído que foi identificado para a realização do trabalho está atribuído apenas indiretamente para esse contrato? (ou seja, despesas gerais).

Materiais Diretos Preçc/uridode pkjne?odo

S

10,00

Unidades reors

S

9.300

Precc/uridode real

S

9,25

Custo real

$86.025,00

Mõo de Obra Direta

S

22.00 12,000

$

22.50

$270,000

15-20 Um de seus gerentes de projetos assistente for­ neceu-lhe um relatório de valor agregado que está concluído apenas parcialmenle. Você pode preencher as informações que faltam? (Todos os números são em milhares de dólares)

Responda as seguintes perguntas apenas para tnão de obra direta

10. Do esforço total direto no orçado para esse contrato, quanto trabalho a Acme programou para ser realizado este mês? 11. Quanto do trabalho programado para realiza ção este mes foi real mente agregado (ou seja, valor agregado)? 12. A Acme realizou mais ou menos trabalho do que eslava planejado para este mês? Quanto foi a variação de prazos (VPR)? [$ e %) 13. Quanto realmente custou à Acme o trabalho realizado este mês? 14. Qual é a diferença entre o montante que a Acme orçou para o trabalho realizado neste mês e o custo real? (ou seja, VC) [$ e %) 15. Quais elementos do nível-2 da EAP são as principais causas para as variações de custos e prazos deste mês? 16. Quantas variações dc custos a Acme vivenciou até o momento? [S c %] 17. Quantas variações de prazos a Acme sofreu até o momento? [5 e %) 18. A variação de custos está melhorando ou pio­ rando? 19. A variação de prazos está melhorando ou pio­ rando? 20. Parece que a data final programada será cum­ prida? 21. Qual é o novo custo estimado com encargos no término? 22. Quanto lucro/perda a Acme pode esperar do novo custo estimado no término? 23. Sc o custo total final da Acme para o programa era $ 3.150.000, quanto lucro/perda ela teria? 15-19 Calcule a variação de preços total para a mão de obra direta c a taxa da variação dc custos de mão dc obra a partir dos seguintes dados:

15-21 O seguinte problema exige uma compreensão da EAP, dos elementos da conta dc custas c da análise dc controle de custos. Suponha que to­ dos os custos estejam em milhares de dólares. Dada a EAP parcial mostrada a seguir, qual é o custo total para o elemento da F.AP 4.0? Considere que todos os custos previstos sào apenas custos diretos de mào de obra e que a taxa de overhead é de 100%.

Qual dos seguintes é o valor do elemento da EAP 4.0? a. $60.0 b. $30.0 a $24.0 d. $54.0

517

CONTROLE DOS CUSTOS

Utilizando os dados da Figura 15-29, e os cus­ tos reais fornecidos a seguir para os elementos

da EAP 5.1 a 5.4 e os elementos 4.1 e 4.2, res­ ponda as perguntas a seguir:

FIGURA 15-29 Demonstração de contas de custos.

Custos Reois

E.I-5.1

$1.0

E.I-5.3

$1.5

E2-5.2

$1.0

E2-5.4

$2.0

E.3-5.1

$1.0

E.3-5.3

$2.5

E.4-5.3

$3.0

E4-5.2

$3.5

Elemento da Elemento da Elemento da Elemento da Elemento da Elemento da

EAP 5.1 S____ EAP 5.2 S____ EAP 5.3 S____ EAP 5.4 $____ EAP 4.1 S____ EAP 4.2 S____

Elemento funcional Elemento funcional Elemento funcional Elemento funcional Elemento funcional Elemento funcional

E-l S____ E-2 S____ E-3 S____ E-4 S____ D-l S____ D-2 $____

15-22 As empresas geralmente estimam o trabalho com base na quantidade de homens-meses. Se o tra­ balho deve ser estimado em homens-semanas, a quantidade de homens-meses é então converti­

da para o homens-semanas. O problema está na determinação do número de homens-horas por mês que estão realmente disponíveis para o tra­ balho real de mão de obra direta. Sua empresa recebeu uma solicitação de propos­ ta (RFP) de um de seus clientes e a administra­ ção decidiu apresentar uma oferta. Apenas um departamento em sua empresa será necessário para realizar o trabalho e o gerente do departa­ mento estima que serão necessárias 3.000 horas dc mão dc obra direta. Seu primeiro passo é calcular o número de ho­ ras disponíveis cm um típico homens-meses. O Departamento de Recursos Humanos fornece os seguintes históricos anuais para o empregado médio na empresa: • Ferias (3 semanas) • Licença médica (4 dias) • Férias remuneradas (10 dias) • Dever de Júri (1 dia)

a. Quantas horas de mào de obra direta estão disponíveis por mês por pessoa? b. Se apenas um empregado pode ser designa­ do ao projeto, qual será a duração do esforço» cm meses? c. Sc o diente quiser que o trabalho seja con­ cluído dentro de um ano, quantos funcionários devem ser designados? 15-23 Em um relatório de andamento, os executivos querem saber nào só onde estamos hoje, mas também onde vamos terminar. O cálculo dc onde vamos terminar financeiramente nào é tào fácil como parece. A seleção da fórmula errada pode deixar os executivos e os clientes com uma impressão errada. Existem várias fórmulas disponíveis para o cál­ culo do custo estimado no término (ENT). Para simplificar, considere as três seguintes fórmulas: I. ENT = (CRTR/COTR) X (orçamento no término) II. ENT = ((CRTR/COTR) X (COTA para o trabalho concluído e em andamento)) + (custos planejados ou custos planejados revisados dos pacotes de trabalho que ainda nào iniciaram) III. ENT = (real até a data) i (todo o trabalho restante, incluindo trabalho em andamento, a ser realizado aos custos planejados ou orçados) a. Utilizando a tabela a seguir, determine o va­ lor dc ENT para cada uma das três fórmulas. Considere que A, B e C sào os únicos pacotes de trabalho no projeto, c que o COTA (Total) é o valor total para VP para cada pacote de trabalho, em vez de o VP ser para o período do relatório. Use a seguinte fórmula para cal­ cular o VA: VA = (% concluído] x COTA(Total)

518

Gerenciamento de Projetos

Atividade A B C

% Conduido 100 50 0

COTA (lotai)

CRTR

1000 1000 1000

1100 800 0

b. Considerando apenas a atividade B, se a ra­ zão para o sobrccusto c atribuída a uma ocorrência única, qual das três fórmulas seria melhor utilizar? c. Se o que provoca o sobrecusto na atividade B são salários maiores do que o esperado dos trabalhadores designados c esses mesmos trabalhadores serão designados também para a atividade C, qual das (rês fórmulas seria melhor utilizar? d. Considerando apenas a atividade B, se a ra­ zão para o sobrecusto é atribuída às horas ex­ tras c as horas extras continuarão, mas ape­ nas até a conclusão da atividade B, qual das três fórmulas seria melhor utilizar? e. Considerando suas respostas para as quatro partes anteriores, uma empresa deve estar disposta a alterar a fórmula de cálculo da ENT, durante a execução do projeto, bem como em cada periodo de relatório ou da reunião de gate review *

15-24 Os gerentes de projetos nào só devem calcular as variações, mas também determinar a causa raiz da variação. Algumas variações podem ser permitidas enquanto outras devem ser explicadas, juntamen­ te com um plano de correção para a recuperação. Na tabela a seguir, você deve demonstrar sua ca­ pacidade de calcular as variações de custos e pra­ zos, bem como determinar a causa raiz das va­ riações, sc possível. Considere a seguinte tabela, a qual mostra um relatório parcial de andamento para um projeto composto por cinco pacotes de trabalho (ou seja, atividades):

|

• Cronograma acelerado em virtude das horas extras • Cronograma acelerado em virtude de recur­ sos adicionais • Desvio por causa da falta de recursos • Desvio por causa de pessoas trabalhando cm outros projetos • Desvio em virtude de erros • As pessoas estão trabalhando, mas o progres­ so é deficiente • Dentro do cronograma • Dentro do orçamento • Acima do orçamento c. A administração quer saber o andamento total do projeto no nível I da EAP. Adicio­ ne todas as variações dc custos e prazos da atividade para determinar as variações dc custos e prazos do nível 1. Quais são as suas conclusões? d. Será que as suas conclusões sobre a parte c mudariam se as atividades B e D fossem as únicas duas atividades no caminho crítico?

15-25 Às vezes, a causa da raiz de uma variação exige que a análise da variação seja realizada tanto em horas quanto em dólares. E possível que o cálcu­ lo das variações tanto em horas quanto em dó­ lares seja a única maneira de determinar a causa raiz dc um problema. Problema: na Tabela 15-20, as variações de custos e prazos sào medidas em dólares com encargos apenas para o Centro de Custos 2834. TABELA 15-20 Centro de custos 2834, junho

COTA COTR

CRTR

a. Calcule as variações de custos e prazos, em dólares, para cada atividade.

b. Para cada atividade, qual das seguintes pode ser a causa raiz para a variação? Selecione quantas você achar que se aplicam. • Cronograma acelerado cm virtude de pessoal com maiores salários • Cronograma acelerado por causa da sobre­ posição de atividades

Dólares Horas Dólares Horas Dóbes Horas

29.750 ' 34.000 J VPR-+S4250 38.400 . VC= -$4400

Pela Tabela 15-20, você está adiantado no cro­ nograma e acima do orçamento. Há várias possíveis causas para isso, incluindo a com­ pressão do cronograma, a utilização de mão de obra com maiores salários, horas extras, recursos adicionais ou outras causas. Como podemos determinar quais dessas causas é o motivo real para as variações? A Tabela 15-21 mostra os dados de variação tanto em horas quanto em dólares.

519

CONTROLE DOS CUSTOS

TABELA 15-21 Centro de custos 2834, junho

Dólares

COIA

29750

350

Horas

Dóiares

COTR

34.000

400

Horas

Dólares

CRTR

38.400

320

Horas VC ($$$) = negetrw VC (horas)

pcsitrra

a. Calcule as variações de custos tanto cm horas quanto em dólares. Compare os resultados. Quais são suas conclusões? b. Calcule a taxa planejada de mào de obra com encargos usando o COTA (ou o COTR). c. Calcule a taxa real dc mão dc obra com encargos usando o CRTR. d. Explique as possíveis razões para as diferenças nas taxas de mão de obra e como isso afeta a sua resposta para a parle a. c. A Tabela 15-22 mostra a estrutura salarial do departamento do Centro de Custos 2834. Determine a taxa de overhead do departamento, cm porcentagem. f. Como a Tabela 15-22 afeta a sua resposta para a parte d? TABELA 15-22 Estrutura salarial do departamento

Salário Sem

Salário com

Tido

Encargos

Encargos

9

Consultor de Engenharia

$53/hxa

8

Ençerhero Sênior

48

120,00

7

Erçerhero

39

97,50

6

Erçerhero k

34

85,00

5

Ergerhero Aprendiz

29

72,50

Categoria Salarial

Situação: A empresa acaba dc ganhar um contrato dc um ano. O contrato foi planejado para começar em Io de janeiro de 2006 e estar concluído até 31 de dezem­ bro de 2006.0 trabalho que deveria ser realizado por este departamento foi estimado em 1.000 horas por més para a duração dos 12 meses do projeto usando funcionários da categoria salarial 7.0 diente informa que deseja iniciar o projeto em Io de julho, em vez de Io de janeiro, e considera que não existe impacto fi­ nanceiro sobre o custo total do projeto. O Departamento Financeiro fornece-lhe os dados do índice de preços futuros na Tabela 15-23 e informa que a taxa de overhead para 2007 deve aumentar para 155%. Existe um impacto financeiro sobre o custo total do projeto c, cm caso afirmativo, impacto dc quanto? TABELA 15-23 Estrutura salarial do departamento

(dólares/hora) Salário

(alegoria Salarial

M

2006

2007-

2008’

9

Consular de Engenharia

53

56

60

8

Engerheirc Sênior

48

50

53

7

Engenheira

39

42

45

6

Engenheira Ir.

34

36

39

5

Engenheiro Aprendz

29

31

34

15-26 Os projetos que abrangem mais de um ano ou que atravessam a data de vencimento dos aumentos de salário das empresas podem exigir a utilização dc taxas de preços futuros. As taxas de preços futu­ ros sào determinadas a partir de dados econômi­ cos, pesquisas nos setores e previsões adivinhadas. Como exemplo, considere a Tabela 15-22 no exer­ cício anterior, que mostra a estrutura salarial para um departamento de engenharia. Para simplificar, vamos considerar os seguinte pressupostos:

15-27 Precilicar uma solicitação de proposta do clien­ te é uma compensação entre tempo, custos e precisão. Se o tempo e o dinheiro nào são um problema, então poderiamos determinar uma proposta muito precisa. Mas se a empresa está relutante cm investir fortemente na elaboração da oferta, é preciso que se tenha cuidado para que nào existam custos ocultos. Situação: Você foi solicitado para precificar um projeto para um cliente, e a definição de preços é uma atividade com a qual você tem muito pou­ ca experiência anterior. A Tabela 15-24 mostra os números aos quais vocé chegou na determi­ nação de que a oferta de S 193.166 deveria ser apresentada.

• As promoções e aumentos de salários, incluindo os ajustes do custo dc vida, sejam efetivadas em 1 ° de Janeiro e, então, sào mantidas constantes durante todo o ano. • A taxa de overhead c de 150% c fixada para o ano inteiro. • Todos os projetos têm os preços estipulados utilizando o salário da categoria 7. ■ A maioria dos trabalhadores do departamento é composta por funcionários da categoria 7.

Antes que uma oferta seja enviada a um clien­ te potencial, ela deve ser analisada por um comitê de gerentes seniores que possam ques­ tionar a validade dos números, bem como procurar os custos “ocultos” que podem ter sido omitidos. Para cada uma das situações a seguir, qual item dc linha no resumo de pre­ ços seria mais provavelmente impaclado, con­ siderando que esses custos ocultos ainda não foram incluídos?

$132,50

520

Gerenciamento de Projetos

TABELA 15-24 Resumo de preços do projeto

Ao final da semana 3, o empreiteiro deve prepa­ rar um relatório de andamento de medição de valor agregado. Calcule o seguinte: COTA:______________________________________

COTR:_____________________________________

CRTR:______________________________________

ONT:_______________________________________ VPR ($):____________________________________

VC ($):_____________________________________ ENT ((CRTR / COTR] X ONT):_________________

EPT:_______________________________________

VNT:_______________________________________ % Concluído_________________________________ % $ $ Gast_________________________________________________

IDC:_______________________________________

a. A administração informa que, durante a execu­ ção do projeto, o clicntc irá querer três reuniões de interface realizadas nas instalações do clien­ te. O Grupo dc Viagem dentro da sua empresa informa que as passagens aéreas, os transportes terrestres, as refeições c a hospedagem deverão custar aproximadamente $ 2.000 por reunião. b. Um dos executivos comenta, “Os custos de transporte para as entregas, incluindo seguros, embalagens e manuseio, serão de cerca de $ 1.000. Eu não vejo isso incluído no seu resumo’'. c. A RFP para o projeto declara que o contrato se­ ria de preço fixo garantido com um pagamento do preço global no final do projeto após a aprovaçào/accitação das entregas finais. O custo dc capital deverá ser de aproximadamente $ 6.000. d. A engenharia acredita que suas horas no resumo poderiam diminuir em cerca de 10% se os riscos nas estimativas fornecidas real mente ocorressem. Os executivos acreditam que uma reserva de ge­ renciamento dc 10% deverá ser incluída no resu­ mo dos custos. c. Utilizando as informações dos itens dc a a d an­ teriores, qual preço final deveria ser apresentado para o clicntc? 15-28 Um proprietário de um imóvel contrata um em­ preiteiro para construir uma cerca de quatro la­ dos em volta de sua casa. O proprietário fornece os materiais e o empreiteiro fornece a mão de obra. O empreiteiro estima que cada lado custará $ 2.000 e demandará uma semana de duração. Ao final da semana I, o primeiro lado foi conclu­ ída a um custo de S 2.000. Durante a semana 2, o segundo lado foi concluído, mas a um custo de $ 2.400, porque o empreiteiro danificou um dulo de água, que teve de consertar. Durante a semana 3, o empreiteiro concluiu apenas metade da cerca a S 1.000 porque choveu durante a metade res­ tante da semana.

IDP:_______________________________________

15-29 Os dados identificados a seguir foram listados no mais recente relatório dc andamento dc um projeto: • COTA = S 36.000 • COTR = S 30.000 • CRTR = S 33.000 • ONT = $120.000 • Duração inicial do projeto = 10 meses Usando esses dados, calcule o seguinte: a. Quais são os valores para o IDC e para o IDP? b. Qual é o custo esperado no término (ENT)? c. Quanto dinheiro será necessário a partir do momento do relatório para terminar o projeto? d. Qual é a variação dc custos no término (VNT)? e. Usando o IDP, qual é a nova duração espera da para o projeto? 15-30 No exercício na Eigura PI 5-30,a regra 50%/50% está sendo usada para determinar o andamento do projeto. (Jonsidere que todos os valores sào em dólares.

Supondo que o CRTR = $ 40.000, determine COTA, COTR, ONT, VPR e VC. Uhfcaôo do rego 50/50

Urto do tempo

Aw.cooA

A 4 000 A

(mute

A6.00QA

A Hn.nufa

A 6 000 A

MoocA

FIGURA P15-30

CONTROLE DOS CUSTOS

521

15-31 Nas Figuras PI5-31A a P15-31C identifique o andamento parcial de um projeto utilizando a técnica gráfica (ou seja, curvas S), em vez de ta­ belas. Para cada uma das trés figuras, selecione uma das cinco opções seguintes, quanto a o que cada figura ilustra: a. Acima do orçamento b. Abaixo do orçamento c. Adiantado d. Atrasado e. O andamento não pode ser determinado

FIGURA PI 5-31A

ESTUDOS DE CASO

0 PERÍODO NA "GELADEIRA" A adjudicação do contrato Scott em 3 de janeiro de 1987 deixou a Park Industries exultante. O Projeto Scott, se administrado corretamente, oferecia enormes oportu­ nidades para trabalhos posteriores durante vários anos. A administração da Park considerava o projeto estratégico por natureza. O Projeto Scott era um empreendimento de dez me­ ses para desenvolver um novo produto para a Scott Corporation. A Scott informou à Park Industries que ocorreríam contratos de produção de fonte única na sequência, du­ rante pelo menos cinco anos, considerando que o esforço inicial de P&D se mostrasse satisfatório. Iodos os contratos posteriores seriam negociados em uma base anual.

Jerry Dunlap foi selecionado como gerente do projeto. Embora fosse jovem e ansioso, ele compreendia a impor­ tância do esforço para o crescimento futuro da empresa. Dunlap recebeu alguns dos melhores funcionários para preencher o seu escritório de projetos, como parte da or­ ganização matricial da Park. O Projeto Scott manteve um escritório de projetos de sete pessoas em tempo integral, incluindo Dunlap, durante toda a duração do projeto. Além disso, oito pessoas do departamento funcional foram

selecionadas para a representação de membros funcionais da equipe do projeto, quatro em tempo integral e quatro em meio período.

Embora a carga de trabalho oscilasse, o nível da força de trabalho para o escritório de projetos e para os mem­ bros da equipe era constante em 2.080 horas por mês du­ rante a vigência do projeto. A empresa considerava que cada hora trabalhada incorria em um custo de $ 60,00 por pessoa, com os encargos.

Ao final de junho, com quatro meses restantes do projeto, a Scott Corporation informou à Park Indus­ tries que, em virtude de um problema de fluxo de caixa projetado, o trabalho posterior não seria concedido até a primeira semana de março (1988). Isso gerou um enorme problema para Jerry Dunlap, porque ele não queria divi­ dir o escritório de projetos. Se ele permitisse que seus colaboradores-chave fossem designados a outros projetos, não haveria nenhuma garantia de que ele poderia trazê-los de volta no início do trabalho posterior. O pessoal do escritório de projetos está sempre em demanda. Jerry estimou que precisaria de S 40.000 por mês du­ rante o período na “geladeira” para apoiar e manter o seu pessoal-chave. Felizmente, o período na geladeira ocorreu durante o Natal e o Ano Novo, um momento em que a fá­

522

Gerenciamento de Projetos

brica estaria fechada por 17 dias. Entre os dias de férias de seus funcionários-chave e os pequenos projetos especiais aos quais o seu pessoal poderia estar temporariamente de­ signado a outros programas, Jerry revisou sua estimativa de $ 125.000 para todo o período na geladeira. Na reuniào semanal da equipe, Jerry disse aos mem­ bros da equipe do programa que eles teriam que “apertar os cintos”, a fim de estabelecer uma reserva de gerencia­ mento de $ 125.000. A equipe do projeto entendeu a ne­ cessidade para essa ação e começou a reprogramação e o replanejamento até que pudesse ser realizada uma reserva de gerenciamento desse tamanho. Como o contrato era de preço fixo garantido, todos os cronogramas para apoio administrativo (ou seja, escritório de projetos e membros da equipe do projeto) foram estendidos até 28 de feve­ reiro na suposição de que esse tempo adicional era ne­ cessário para a contabilidade dos dados finais de custos e documentação do relatório do programa. Jerry informou seu chefe, Frank Howard, o chefe da divisão de gerenciamento de projetos, sobre os pro­ blemas com o período de geladeira. Ele era o intermediário entre Jerry e o diretor geral. Frank concordou com a abor­ dagem de Jerry para o problema e pediu para ser mantido informado. Em 15 de setembro, ele disse a Jerry que queria “registrar” a reserva de gerenciamento de S 125.000 como lucro adicional, uma vez que isso influenciaria a sua gra­ tificação de Natal (de Frank). Ambos discutiram por um tempo, com Frank constantemente dizendo: “Não se preocupe! Vocé receberá seu pessoal-chave de volta. Cuidarei disso. Mas quero essas verbas não alocadas contabilizadas como lucro e o programa concluído em I ° de novembro."

Jerry ficou furioso com a falta de interesse de Frank em manter a adesão da organização atual. Jerry deveria recorrer ao gerente geral? O pessoal-chave deveria ser suportado pelo mrr/kwd? Sc este fosse um programa dc custos mais remu­ neração, vocé consideraria abordar o cliente com o seu problema na esperança de um alívio? Se você fosse o cliente desse programa de custos mais remuneração, qual seria a sua resposta, para financiamento adicional para o período geladeira, considerando os sobrecustos?

a. b. c.

d.

e.

f.

Sua resposta anterior mudaria se o programa tives­ se dinheiro disponível como um resultado na gas­ tos abaixo do previsto? Como você evita que essa situação se repita em to­ dos os contratos anuais posteriores?

FRANKLIN ELECTRONICS Em outubro de 2003, a Franklin Electronics ganhou um contrato de desenvolvimento de produto de 18 me­ ses de mão de obra intensiva, adjudicado pela Spoka­ ne Industries. A concessão era um contrato de custos reembolsáveis com um custo-alvo de $ 2,66 milhões e uma taxa fixa de 6,75% do alvo. Esse contrato seria a pri­ meira tentativa da Franklin em usar o gerenciamento de projetos formal, incluindo uma metodologia de gerencia­ mento de projetos recém-desenvolvida. A Franklin recebeu vários contratos anteriores da Spokane Industries, mas eram todos contratos de preço fixo, sem o requisito de usar o gerenciamento de projetos formal com relatório de valor agregado. Os termos e con­ dições desse contrato incluíam os seguintes pontos-chave:

• Era para ser utilizado o gerenciamento de projetos (formalizado). • O relatório do valor agregado para prazos e custos era um requisito. • O primeiro relatório do valor agregado era devido ao final do segundo mês do esforço e mensalmen­ te, a partir de então. • Havería duas reuniões de intercâmbio técnico, uma no fina) do 6o mês e outra no fina) do 12° mês. O relatório do valor agregado era novidade para a Franklin Electronics. fim de responder à solicitação de pro­ posta (RFP) inicial, um consultor foi contratado para rea­ lizar um seminário de quatro horas sobre o gerenciamento de valor agregado. Estavam presentes o gerente de projetos que foi designado para a à RFP da Spokane e que iria ge­ renciar o contrato após a adjudicação, todo o departamento de contabilidade de custos e dois gerentes de linha. O gru­ po de contabilidade de custos não estava contente em ter de aprender técnicas de gerenciamento de valor agregado, mas concordou relutantemente em apresentar a proposta para

Totais oo Final do Mês 3

Totais oo Final do Mês 2

Pacotes de

Trabalho

VP

VA

CR

VC

VPR

VP

VA

CR

VC

VPR

A

38K

30K

36K



86K

74K

81K



B

17K

16K

18K



55K

52K

55K



C

26K

24K

27K



72K

68K

73K



D

40K

20K

23K



86K

60K

70K



Nota COM = If COIIt = W e Cfíf = 0?

523

CONTROLE DOS CUSTOS

a RFP da Spokane. Em projetos anteriores com a Spokane Industries, eram realizadas reuniões mensais de intercâm­ bio. Parecia que, para o contrato atual, a Spokane Industries acreditava que seriam necessárias menos reuniões de inter­ câmbio porque as informações necessárias poderíam ser fa­ cilmente obtidas por meio dos relatórios de andamento de valor agregado. Eh parecia ter bastante confiança na capaci­ dade do sistema de medição de valor agregado em fornecer informações significativas. No passado, a Spokane nunca havia mencionado que estava considerando uma possível implementação de um sistema de medição de valor agrega­ do como requisito em todos os contratos futuros. A Franklin Electronics ganhou o contato por ser a pro­ posta mais baixa. Durante a fase de planejamento, uma estru­ tura analítica do projeto foi desenvolvida contendo 45 paco­ tes de trabalho, dos quais apenas quatro pacotes de trabalho ocorreríam durante os primeiros quatro meses do projeto. A Franklin desenvolveu um relatório de andamento muito simples para o projeto. A tabela a seguir contém os dados financeiros apresentados à Spokane, no final do terceiro mês.

Uma semana após o envio do relatório de andamen­ to para a Spokane Industries, o gerente de projetos da Franklin foi convidado a participar de uma reunião de emergência, solicitada pelo vice-presidente de engenha­ ria da Spokane, que estava atuando como o patrocinador do projeto. O vice-presidente estava ameaçando cancelar o projeto por causa do mau desempenho. Na reunião, o vice-presidente comentou: “No mês passado, o estouro na variação de custos aumentou 78%, de S 14.000 para S 25.000, e o desvio na variação do cronograma aumen­ tou 45%, de $ 31.000 para S 45.000. A essas taxas, esta­ mos facilmente olhando para um sobrecustos de 500% e um desvio de cronograma de pelo menos um ano. Nós não podemos permitir que esse projeto continue a essa taxa de fraco desempenho. Se não pudermos desenvolver um plano para controlar o tempo e os custos de forma melhor do que temos feito nos últimos três meses, então simplesmente vou cancelar o contrato agora, e vamos en­ contrar outro fornecedor que possa realizar.” PERGUNTAS

1.

2. 3. 4. 5.

Os comentários do vice-presidente sobre a varia­ ção dc custos e prazos estão corretos? Quais informações o vice-presidente deixou de analisar? Que informação adicional deveria ter sido incluída no relatório dc andamento? A Franklin Electronics entende a medição de valor agregado? Se não, então, o que deu errado? A Spokane Industries entende dc gerenciamento dc projetos?

6.

7.

A medição adequada dc valor agregado serve como um substituto para as reuniões de intercâmbio? O que o gerente dc projetos da Franklin deveria di­ zer em sua defesa?

PROBLEMAS N0 PARAÍSO Como recompensa por se tornar o primeiro PMP da Acme Corporation, a Acme designa ao novo PMP, Wi­ ley Coiote, o papel de liderança de um importante pro­ jeto, no qual o prazo das entregas era fundamental para o sucesso do projeto. Um atraso no cronograma poderia custar à Acme uma perda de pelo menos $ 100.000 por mês. A primeira responsabilidade de Wiley Coiote como gerente do projeto era a elaboração de um pacote de so­ licitação para a seleção de um fornecedor de engenharia. Oito empresas elaboraram propostas com base no pacote de solicitação. Wiley Coiote decidiu negociar somente com o licitante mais barato, que passou a estar a um custo final significativamente menor do que os ou­ tros candidatos. O gerente de projetos do fornecedor, Ima Papa-Léguas, trataria das negociações para o fornecedor. Era um fornecedor com o qual Wiley Coiote nunca havia trabalhado anteriormente. Wiley Coiote analisou as in­ formações críticas na oferta do fornecedor: • Todo o trabalho seria realizado pela engenharia. • O total de mão de obra com encargos era de 2.000 horas a S 120/hora. • A duração do projeto seria de aproximadamente seis meses e seria concluído em 2006 (as taxas de mão de obra poderíam ser diferentes em 2007). • A taxa aplicada de overhead do fornecedor era de 150% para a engenharia. • Todos os trabalhadores designados estariam na mesma categoria de salário e seriam designados em tempo integral durante a vigência do projeto. • O lucro solicitado era de 12,5%, mas sujeito a negociações. • O salário de Ima Papa-Léguas seria incluído na es­ trutura de overhead. • Nenhum material seria necessário.

Durante as negociações, Ima Papa-Léguas forneceu a Wiley Coiote a estrutura salarial para a engenharia, mos­ trada na Demonstração 15-1. Demonstração 15-1

Estrutura salarial do departamento

Categoria

Titulo

Sdaial

SolórioSem

Salário com

Encargos

Encargos $132,50

9

Consultor de Engenhorio

8

Engenhero Sênior

48

120,00

7

Engenhero

39

97,50

6

Engenhero Jr.

34

85,00

5

Engenhero tyrendiz

29

72,50

S53/hora

524 Wiley Coiote perguntou a Ima Papa-Léguas pelo período (ou seja, curva de mão de obra,) quando os re­ cursos seriam atribuídos. O resultado, fornecido por Ima Papa-Léguas, é mostrado na Demonstração 15-2, no for­ mato de uma curva-S, que também mostra o plano de pagamento do cliente ao fornecedor.

Gerenciamento de Projetos

Ao final do primeiro mês, Wiley Coiote recebeu o altamente simplificado relatório de andamento de valor agregado mostrado na Demonstração 15-3. Wiley Coiote ficou encantado com os resultados até o momento. Agora parecia que o projeto seria concluído pelo menos um mês antes do cronograma e significativamente abaixo do or­ çamento. Wile)’ Coiote proporcionou à Acme economias significativas de custos, escolhendo o fornecedor de me­ nor custo, reduziu a margem de lucro em 20% e, muito provavelmente, terminaria adiantado no cronograma e com economias adicionais de custos. Ele estava prestes a se tomar uma “estrela” aos olhos dos executivos da Acme. Todo mundo iria perceber que Wiley Coiote finalmente superou o Papa-Léguas. Coiote já começava a planejar como iria gastar o enorme bônus que esperava receber na conclusão do projeto.

Demonstração 15-3 Final do l8 Mês COTA

O pacote de solicitação identificava o contrato como de preço fixo com penalidades para a entrega atrasada. Ima Papa-I.éguas alegou que as cláusulas de penalidades eram injustas em sua redação atual, e que uma margem de lucro maior seria necessária para compensar o riscos. Nesse ponto, o intelecto superior de Wiley Coiote ficou evidente; ele concordou em eliminar as cláusulas de pe­ nalidade se Ima Papa-Léguas concordasse em reduzir a margem de lucro de 12,5 para 10%. Ima Papa-IZ *guas contra-argumentou que o contrato deveria então ser um contrato de preço fixo com remuneração de incentivo para que Ima Papa-Léguas pudesse compensar a perda de 2,5% de lucro, concluindo o projeto abaixo do orçamento. Am­ bas as partes concordaram com isso e o acordo foi feito. O contrato não exigia qualquer tipo de informa­ ção de valor agregado, mas Ima Papa-Léguas, que ti­ nha um conhecimento muito limitado de medição de valor agregado e que nunca havia utilizado isso an­ tes, concordou em fornecer um relatório mensal que simplesmente mostraria o valor planejado (COTA), o valor agregado (COTR) e os custo reais (CRTR). Wi­ ley Coiote concordou com isso. Afinal, agora que ele era um PMP, sabia como extrair todas as informações restantes, tais como análises de variação, o custo no término, e o custo para terminar, a partir desses três valores do relatório mensal.

Centro de Custos de Engentario

COR (RIR

Dólares

$42.000

Horas

350

Dólares

$48.000

Horas

400

Dckres

$34.000

Horas

400

Ao final do quinto mês, Ima Papa-Léguas infor­ mou Wiley Coiote as boas notícias de que o projeto seria concluído dentro dos custos, mas também havia más no­ tícias de que a data de conclusão seria no final do 8o mês, tornando o projeto dois meses atrasado e com uma perda significativa para a Acme Corporation. Os pensamentos de Wiley Coiote sobre como gastar o seu bônus eram ago­ ra substituídos com idéias criativas sobre como atualizar seu currículo. Hoje, Wiley Coiote está no circuito de pa­ lestras para discutir maneiras de identificar os sinais de alerta de um potencial desastre no projeto. Mais uma vez, o Papa-Léguas enganou Wiley Coiote. Você foi contratado como um consultor na Acme Corpo­ ration para analisar o que deu errado e elaborar uma lista de lições aprendidas para os outros gerentes de projetos. Usando as informações do caso e todas as três demons­ trações, identifique o que deu errado. Além disso, houve algum sinal de alerta precoce, especialmente no final do primeiro mês, que deveria ter avisado Wiley Coiote que o desastre poderia ser iminente?

ANÁLISE DE COMPENSAÇÕES EM UM AMBIENTE DE PROJETO “Quando tentamos pegar algo por si só, o encontramos atrelado a tudo no universo.” LEI DE MU1R

Estudos de (aso Relacionados (de Ketínet/Projeíl

livro de Exercícios Relacionado (de Kerzner/Aojecf Management

Glia PMBOK - 5. ed., Seção de Referenda para o

Management Case Studies, 4. ed.)

Workbook and PMP/CAPH Exam Study Guide, 11. ed.)

Exame de Certificação PMP

Nenhum

• Multiple Choice Exom

• Getenciomenio do Integração do Projeto • Gerenciamento dos Aquisições do Projeto • Gerenciamento do Escopo do Projeto

16.0

INTRODUÇÃO

O gerenciamento de projetos bem-sucedido é tanto uma Definição das Rcstnçôo Triplas arte quanto uma ciência e tenta controlar os recursos da empresa dentro das restrições de tempo, custos e desempenho. A maioria dos projetos é única e possui atividades exclusivas para as quais nào exis­ tem padrões razoáveis para o planejamento. Como resulta­ do, o gerente de projetos pode achar extremamente difícil permanecer dentro do triângulo tempo-custos-desempenho da Figura 16-1. O triângulo tempo-custos-desempenho é a “com­ binação mágica” que é constantemente perseguida pelo gerente de projetos ao longo do ciclo de vida do projeto. Se o projeto flui sem problemas, de acordo com o plano, pode nào haver a necessidade de uma análise de compen­ sações. Infelizmente, isso raramente acontece. As compensações são ilustradas na Figura 16-2, onde os A representam desvios em relação às estimativas ori­ ginais. Os desvios de tempo e custos são normalmente acima do previsto, enquanto os erros de desempenho sào abaixo do previsto. Nào existem dois projetos exatamen­ te iguais e a análise de compensações será um esforço Guia PMBOK -, S.ed.

contínuo durante toda a vida do projeto, continuamente influenciado tanto pelo ambiente interno quanto pelo ex­ terno. Os gerentes de projetos experientes têm pré-compensações na reserva, reconhecendo que as compensa­ ções sào parte de um processo de pensamento contínuo.

FIGURA 16-1 Visõo geral do gerenciamento de projetos.

526

Gerenciamento de Projetos

A maioria dos projetos de equipamento de capital cairia na situação A-l ou B-2, em que o tempo é a es­ sência. Quanto mais cedo o equipamento entra em pro­ dução, mais cedo o retorno do investimento pode ser obtido. Muitas vezes, há restrições de desempenho que determinam o potencial de lucro do projeto. Se o poten­ cial do projeto é determinado para ser grande, o custo será o fator de desvio, como na situação B-2.

Equipamentos que não estão em processos produti­ vos, tais como equipamentos de controle de poluição, ge­ ralmente desenvolvem um cenário em torno da situação B-3.0 desempenho é fixado pela Agência de Proteção Ambiental. O prazo para o cumprimento pode ser retar­ dado por meio de litígio, mas, caso os processos falhem, a maioria das empresas tenta a adequação com o equipa­ mento mais acessível que atenda aos requisitos mínimos.

FIGURA 16-2 Gerenciamento de projetos com compensações.

As compensações são sempre baseadas nas restrições do projeto. A Tabela 16-1 ilustra os tipos de restrições nor­ malmente impostas. As situações A e B são as compensa­ ções típicas encontradas no gerenciamento de projetos. Por exemplo, a situação A-3 retrata a maioria dos pro­ jetos de pesquisa e desenvolvimento. O desempenho de um projeto de P&D é geralmente bem definido e possui custos e tempo que podem ser autorizados a excederem o orçamento e o cronograma. A determinação de escolher o que sacrificar baseia-se nas alternativas disponíveis. Se nào há alternativas ao produto em desenvolvimento e o uso potencial é grande, então os custos e o tempo são as compensações.

A empresa de consultoria profissional atua princi­ palmente sob a situação B-l. Na situação C, a análise de compensações será completada com base nos critérios de seleção e restrições. Se tudo é fixo (C-l), não há espaço para qualquer outro resultado que não o sucesso total e se tudo é variável (C-2), não há nenhuma restrição e, por­ tanto, nenhuma compensação. Muitos fatores conduzem para a decisão de sacrificar tempo, custos ou desempenho. Convém notar, porém, que nem sempre é possível sacrificar um desses itens, sem afetar os outros. Por exemplo, reduzir o tempo poderia ter um sério impacto sobre o desempenho e sobre os cus­ tos (especialmente se as horas extras sào obrigatórias).

(owto

TABELA 16-1 Categorias de restrições Tempo

Custos

Desempenho

A Um Elemento Fixo pot Vez A-l

fixo

Variável

Variável

A-2

Vofiwel

Fixo

Vaóvd

A-3

Vonód

Vooód

Fixo

B. Dois Elementos Fixos por Vez

FIGURA 16-3 Fatores que forçam a compensação.

B-l

fixo

Fixo

Variável

B-2

fixo

Vonóvd

Fixo

fr3

Vofiwel

Fixo

Fixo

B. Tiês Elementos fixos ou Vonóvers

C-l

fixo

Fixo

Fixo

C-2

Voriwel

Vonõd

Variável

Há vários fatores, tais como os mostrados na Figura 16-3, que tendem a “forçar" as compensações. Documen­ tos mal escritos (por exemplo, declarações de trabalho, contratos e especificações) são quase sempre forças in­ ternas para o conflito em que o gerente de projetos ten­ de a procurar como ajuda no desempenho. Em muitos

ANÁLISE DE COMPENSAÇÕES EM UM AMBIENTE DE PROJETO

527

projetos, a venda e negociação iniciais, bem como a ela­ boração da especificação, são feitas por pessoas altamente técnicas que são levadas a criar um monumento em vez de atender às necessidades operacionais do cliente. Quan­ do as forças operacionais dominam a ida do projeto para o cliente, os gerentes de projetos tendem a procurar au­ xílio nos custos.

O primeiro passo, em qualquer processo de decisão, deve ser o reconhecimento e a compreensão do confli­ to. /X maioria dos projetos possui sistemas de custos e de gestão que comparam resultados reais com os planejados, examinam os resultados por meio da análise da variação e fornecem relatórios de andamento para que medidas cor­ retivas possam ser tomadas para resolver os problemas. Os gerentes de projetos devem avaliar cuidadosamente as informações sobre os problemas do projeto, pois nem sempre é o que parece ser. Perguntas típicas a fazer são:

16.1

METODOLOGIA PARA ANÁLISE DE COMPENSAÇÕES

Qualquer processo de geren­ ciamento de compensações 3.6 Grupo de Planejamento do Projeto de tempo, custos e desem­ Triângulo do Grupo de penho deve enfatizar a abor­ Planejamento do Processo dagem de sistemas, reconhe­ Capítulo 4 Gerenciamento da Integração do Projeto cendo que mesmo a menor Capitulo 5 Gerenciamento do mudança em um projeto Escopo do Projeto ou sistema pode facilmen­ te afetar todos os sistemas da organização. Um modelo de sistemas típicos é mostrado na Figura 16-4. Por causa disso, muitas vezes, é melhor desenvolver um processo de tomada de decisão/análise de compensações, em vez de manter regras rígidas para compensações. Os seis passos seguintes podem ajudar: Guia PMBOK , 5. ed.

• Reconhecimento e compreensão da base para os conflitos no projeto • Revisão dos objetivos do projeto • Análise do ambiente e do andamento do projeto • Identificação dos cursos alternativos de ação • Análise e seleção da melhor alternativa • Revisão do plano do projeto

FIGURA 16-4 A abordagem sistêmica.

• • • • • •

A informação é pertinente? A informação é atual? Os dados estão completos? Quem determinou a existência dessa situação? Como ele sabe que essa informação é correta? Se essa informação for verdadeira, quais são as im­ plicações para o projeto?

A finalidade desse primeiro passo é entender a causa do conflito e a necessidade de compensações. /\ maioria das causas pode ser classificada como erros ou falhas hu­ manos, problemas incertos e problemas totalmente ines­ perados, como mostrado a seguir: • Falhas/erros humanos • Compromissos impossíveis de cronograma • Controle pobre das alterações de design • Contabilidade deficiente dos custos do projeto • Falhas de máquina • Falhas de teste • Falha ao receber uma entrada crítica • Falha ao receber aprovação antecipada • Problemas incertos • Muitos projetos simultâneos • Vencimento do contrato de trabalho • Mudança na liderança do projeto • Possibilidade de cancelamento do projeto • Problemas inesperados • Recursos da empresa superalocados • Prioridades do projeto em conflito • Problemas de fluxo de caixa • Disputas de contrato de trabalho • Atraso no envio de material • Promoções externas ao projeto de pessoas em atividades de “paralelismo” • Devolução de colaboradores “temporários” às suas bases • Previsões originais imprecisas • Mudança nas condições de mercado • Novos padrões em desenvolvimento

528

Gerenciamento de Projetos

O segundo passo no processo de decisão é uma re­ visão completa dos objetivos do projeto como visto por vários participantes nos projetos, desde a alta administra­ ção até os membros da equipe do projeto. Esses objeti­ vos e/ou prioridades foram originalmente definidos após considerar vários fatores ambientais, alguns dos quais po­ dem ter mudado ao longo da vida do projeto. A natureza desses objetivos normalmente irá deter­ minar o grau de rigidez que foi estabelecido entre tempo, custos e desempenho. Isso pode exigir a revisão da docu­ mentação do projeto, incluindo: • Objetivos do projeto • Integração do projeto aos objetivos do patrocina­ dor e ao plano estratégico • Declaração do trabalho • Especificações de cronograma, custos e desempenho • Recursos consumidos e projetados

O terceiro passo é a análise do ambiente e do an­ damento do projeto, incluindo uma medição detalhada dos resultados de tempo, custos e desempenho reais com o plano do projeto original ou revisado. Essa etapa não deve se transformar em uma “caça às bruxas”, mas cen­ trar-se nos resultados, problemas e obstáculos do projeto. Eatores como o risco financeiro, potenciais contratos de acompanhamento, situação de outros projetos e relativas posições competitivas são apenas alguns dos fatores am­ bientais que devem ser revistos. Algumas empresas cria­ ram políticas para a análise de compensações como “nun­ ca comprometer o desempenho”. Mesmo essas políticas, no entanto, sào conhecidas por mudarem quando os fa­ tores ambientais aumentam o risco financeiro da empre­ sa. Os tópicos a seguir podem ser aplicados no passo 3: • Discutir o projeto com o escritório de gerencia­ mento de projetos para: • Determinar as prioridades relativas a tempo, custos e desempenho • Determinar o impacto sobre a rentabilidade da empresa e sobre o plano estratégico • Fazer uma avaliação da gestão (mesmo um pal­ pite quanto aos problemas) • Se o projeto é um contrato com um cliente exter­ no, reunir-se com o gerente de projetos do clien­ te para avaliar seus pontos de vista em relação ao andamento do projeto e avaliar as prioridades do cliente de tempo, custos e desempenho. • Reunir-se com os gerentes funcionais para deter­ minar seus pontos de vista sobre o problema e ob­ ter uma visão quanto ao comprometimento deles com um projeto bem-sucedido. Onde este projeto se situa na lista de prioridades deles?

• Revisar em detalhes a situação de cada pacote de trabalho do projeto. Obter uma avaliação clara e detalhada pelo pessoal do escritório de projetos responsável, quanto a: • Tempo para terminar • Custo para terminar • Trabalho para terminar • Revisar os dados passados para avaliar a credibili­ dade das informações de custos e cronograma na etapa anterior. O gerente de projetos pode ter experiência suficiente para avaliar rapidamente o significado de uma variação particular e o impacto provável dessa variação no desem­ penho da equipe do projeto. O conhecimento dos requi­ sitos do projeto (possivelmente com o apoio do patro­ cinador do projeto) geralmente ajudará um gerente de projetos a determinar se alguma ação corretiva deve ser tomada ou se o projeto deve simplesmente ser autorizado a continuar conforme concebido originalmente.

Seja ou não necessária uma ação imediata, deve-se fazer uma análise rápida do porquê de um problema po­ tencial que se desenvolveu estar em ordem. Obviamente, isto não vai ajudar a “curar os sintomas” se a “doença” em si não for resolvida. O gerente de projetos deve permane­ cer objetivo na identificação desses problemas, uma vez que ele próprio é um dos principais membros da equi­ pe do projeto e pode ser pessoalmente responsável por problemas que estão ocorrendo. /\s áreas suspeitas tipica­ mente incluem: • Planejamento Inadequado. Ou o planejamento não foi feito em detalhes suficientes ou não foram definidos controles para determinar que o projeto esteja avançando de acordo com o plano aprovado. • Mudanças de Escopo. Variações nos custos e no cronograma são uma consequência normal de mudanças de escopo que sào permitidas sem in­ corporação formal no plano de projeto ou aumen­ to dos recursos autorizados para o projeto. • Desempenho Ruim. Em virtude do elevado grau de interdependências que existe dentro de qual­ quer estrutura de equipe de projeto, o desempe­ nho inaceitável de um indivíduo pode rapidamen­ te minar o desempenho de toda a equipe. • Excesso de Desempenho. Frequentemente, um membro da equipe com excesso de zelo irá distor­ cer nào intencionalmente o equilíbrio previsto en­ tre custos, cronograma e desempenho no projeto. • Restrições Ambientais. Especialmente em proje­ tos que envolvem “aprovações de terceiros”, ou de­ pendentes de recursos extemos. Alterações, atrasos

ANÁLISE DE COMPENSAÇÕES EM UM AMBIENTE DE PROJETO

529

ou não cumprimento por partes externas à equipe do projeto pode ter um impacto adverso sobre o desempenho da equipe.

■ Haverá ganhos de valor líquido para o aumento do custeio? • Essa é a única maneira de satisfazer o desempenho? • Isso prejudicará a capacidade da nossa empresa em adquirir contratos futuros? • Essa é a única forma de manter o cronograma? • Desempenho • As especificações originais podem ser cumpridas? • Se nào, qual custo que podemos garantir atender? • As especificações são negociáveis? • Quais são as vantagens das mudanças de especi­ ficação para a empresa e para o cliente? • Quais são as desvantagens das alterações de de­ sempenho para a empresa e para o cliente? • Estamos aumentando ou diminuindo o desem­ penho? • Será que o cliente aceita uma mudança? ■ Alguma obrigação sob o produto ou empregado será contraída? • A alteração nas especificações causará uma redistribuição dos recursos do projeto? • Essa mudança prejudicará a capacidade da nossa empresa para adquirir contratos futuros?

Alguns projetos parecem estar fora de tolerân­ cia quando, na verdade, não estão. Por exemplo, alguns projetos de construção são tão carregados na fase inicial com os custos que parece haver uma grande discrepância quando ela, de fato, não existe. A carga inicial dos custos foi planejada.

O quarto passo do processo de compensação do projeto é listar os cursos alternativos de ação. Essa etapa normalmente significa levantar os métodos possíveis de realização do projeto, comprometendo uma combinação de tempo, custos ou desempenho. Espera-se que esse pas­ so refinará essas alternativas possíveis em três ou quatro cenários mais prováveis para a conclusão do projeto. Nes­ se ponto, alguma tomada de decisão intuitiva pode ser obrigada a manter a lista de alternativas em uma ordem administrável. Para identificar totalmente as alternativas, o gerente de projetos deve ter respostas concretas a questões essen­ ciais que envolvem tempo, custos e desempenho: • Tempo • O atraso de tempo é 3.6 Grupo de proceuos de aceitável para o cliente? monitoramento e controle • O atraso de tempo irá alterar a data de término para outros projetos e outros clientes? • Qual é a causa para o atraso de tempo? • Os recursos podem ser replanejados para aten­ der ao novo cronograma? • Qual será o custo para o novo cronograma? • O tempo acrescido nos trará melhorias? • Uma extensão desse projeto causará atrasos em outros projetos no cliente? • Qual será a resposta do cliente? • O tempo acrescido mudará a nossa curva de aprendizagem? • Isso prejudicará a capacidade da nossa empresa em adquirir contratos futuros? • Custos • O que está causando os sobrecustos? • O que pode ser feito para reduzir os custos res­ tantes? • O cliente aceitará um custo adicional? • Devemos absorver os custos extras? • Podemos renegociar o tempo ou padrões de de­ sempenho para permanecer dentro dos custos? • Os custos orçados para o restante do projeto es­ tão precisos? Guia PMBOK , 5. ed.

Uma vez que as respostas a essas perguntas são ob­ tidas, o melhor geralmente é plotar os resultados grafica­ mente. Os métodos gráficos foram utilizados durante as últimas duas décadas para determinar os custos de com­ pressão para encurtar a duração de um projeto. Ao usar as técnicas gráficas, devemos decidir sobre qual dos três parâmetros devemos manter fixo.

SITUAÇÃO 1: O Desempenho é a Constante Fixa (para Especificações) G»m um desempenho fixo, os custos podem ser ex­ pressos em função do tempo. Exemplos de curvas apare­ cem nas Figuras 16-5 e 16-6. Na Figura 16-5, o círculo X indica o custo-alvo e o tempo-alvo. Infelizmente, o cus­ to para completar o projeto no tempo-alvo é superior ao custo orçado. É possível adicionar recursos e horas extras de trabalho para que os prazos possam ser cumpridos. De­ pendendo da forma em que as horas extras são oneradas, é possível encontrar um ponto mínimo na curva em que os atrasos adicionais causarão a escalada do custo total. A Curva A na Figura 16-6 mostra o caso em que "tempo é dinheiro” e qualquer tempo adicional aumentará os cus­ tos para terminar. Fatores como o tempo de apoio à gestão sempre aumentarão o custo para terminar. Há, no entanto, algumas situações em que o aumento dos custos ocorre em períodos de estabilidade. Isso é mostrado na curva B da Figura 16-6. Isso poderia resultar na espera pelo condicionamento

530

FIGURA 16-5 Compensações com desempenho fixo.

Gerenciamento de Projetos

podem ter sido definidos como muito altos ou a probabilidade de sucesso exigido da equipe do pro­ jeto pode ter sido simplesmente irrealista. Reduções de custos e melhorias nos cronogramas podem nor­ malmente surgir do relaxamento nas especificações de desempenho, desde que o menor nível de quali­ dade ainda satisfaça os requisitos do cliente. • Os recursos disponíveis podem ser deslocados a fim de equilibrar os custos do projeto ou para acelerar as atividades que estão no elemento de trabalho do caminho “crítico” que está com problemas. Esse processo de replanejamento desloca elementos de atividades não críticas para atividades críticas. • Dado um problema de cronograma, pode ser neces­ sária uma alteração no diagrama de lógica para mo­ ver da posição atual para a posição desejada. Essa mudança poderia facilmente resultar em replaneja­ mento e realocação de recursos. Um exemplo disso seria converter os esforços de trabalho de “serial” para “paralelo”, o que é, muitas vezes, arriscado.

As compensações com níveis de desempenho fixos de­ vem levar em conta a confiança entre a empresa e o cliente, a prioridade do projeto dentro da empresa e o potencial para futuros negócios. A premissa básica aqui é que a em­ presa nunca pode sacrificar a sua reputação por oferecer um produto que não cumpre com as especificações. A exceção pode ser uma mudança que melhore o desempe­ nho e puxe o projeto de volta ao cronograma. Ê sempre importante investigar antes de entrar em compensações de tempo-custos.

FIGURA 16-6 Compensações com desempenho fixo.

de temperatura de um componente antes que o trabalho su­ plementar possa ser concluído ou, simplesmente, esperar que recursos nào classificados estejam disponíveis. Nesse último caso, os pontos de decisão de compensação podem estar no final de cada período de estabilidade. Com um desempenho fixo, existem quatro métodos dis­ poníveis para construir e analisar as curvas tempo-custos: • Recursos adicionais podem ser necessários. Isso geralmente eleva os custos muito rápido. Conside­ rando que os recursos estejam disponíveis, os pro­ blemas de controle de custos podem ocorrer como resultado da adição de recursos após o orçamenta­ ção do projeto inicial. • O escopo do trabalho pode ser redefinido e alguns trabalhos suprimidos, sem alterar os requisitos de desempenho do projeto. Os padrões de desempenho

O tempo e os custos estào interligados em um pro­ jeto de trabalho intensivo. Quando há desvios na entrega, os custos geralmente aumentam. O desvio dos prazos de entrega e a diminuição do crescimento dos custos geral­ mente são as alternativas recomendadas para projetos em que a confiança entre a empresa e o cliente, a prioridade do projeto dentro do fluxo de projetos da empresa e o potencial de negócios futuros em termos de vendas repre­ sentam um risco entre baixo e médio. Mesmo em algumas situações de alto risco, o fornecedor pode ter de absorver o custo adicional. Essa decisão baseia-se frequentemen­ te na estimativa dos projetos futuros para esse cliente, de modo que a perda é amortizada contra futuros negócios. Nem todos os projetos sào sucessos financeiros. A reputação da empresa pela excelência é, muitas ve­ zes, difícil de estabelecer e pode ser extremamente frágil. Ela é, provavelmente, um dos maiores ativos do fornece­ dor. Isso é particularmente verdadeiro em contratos de grande responsabilidade civil, em que as consequências do fracasso sào extremamente graves. Existem empresas

ANÁLISE DE COMPENSAÇÕES EM UM AMBIENTE DE PROJETO

531

que foram muito bem-sucedidas em adquirir contratos na indústria aeroespacial e de tecnologia avançada, mas raramente fizeram as propostas mais baixas. Quando o governo é o fornecedor, o desempenho é avaliado muito acima dos custos. Da mesma forma, as consequências de um acidente de aviação comercial são de tal magnitude que os custos e o tempo são relativamente insignificantes em comparação com o que é praticado na manufatura de precisão e confiabilidade extremamente alta. Às vezes, os projetos podem ter tempo e custos fixos, deixando apenas a variável de desempenho para compen­ sações. No entanto, como mostra o cenário a seguir, o re­ sultado final pode modificar a restrição de custos “fixos”.

O sistema de qualidade foi, então, exaustivamente es­ tudado. Constatou-se que, eliminando duas operações de inspeção redundantes, uma semana poderia ser poupada no cronograma total. Essas duas operações de inspeção consumidoras de tempo foram adicionadas quando um problema de qualidade desenvolveu-se em um contrato anterior. O problema havia sido resolvido e, com os con­ troles, não existia mais razão para acreditar que as inspe­ ções ainda seriam necessárias. Elas seriam eliminadas sem risco determinável no desempenho.

A situação hipotética envolve um subcontrato de equipamentos para o governo, com preço fixo e entrega ao fornecedor principal do governo. O fornecedor princi­ pal tinha um calendário muito apertado e o equipamento a ser fornecido possuía apenas a “janela” de uma sema­ na para a entrega ou o fornecedor principal sofreria um grande atraso. Qualquer atraso nesse momento colocaria o fornecedor geral em sérios apuros. O gerente do contra­ to do governo e o gerente de compras do fornecedor geral tinham destacado a importância de fazer o cronograma de entrega. Não havia nenhuma sanção financeira por estar atrasado, mas o gerente do contrato tinha afirmado por escrito que quaisquer contratos posteriores, fortemente esperados pela alta gerência da empresa, seriam colocados com outros fornecedores caso houvesse atraso na entrega. A qualidade (desempenho) era crítica, mas nunca tinha sido um problema sério. De fato, o desempenho tinha ultrapassado as exigências contratuais, porque era política da empresa ser a “melhor” na indústria. Essa po­ lítica tinha, às vezes, causado problemas de custos, mas garantiu pedidos posteriores.

Outras duas semanas foram compensadas com o tra­ balho de três pessoas de produção, sete dias por semana, para o restante do projeto. Isso permitiría a entrega na data especificada no contrato e permitiría uma semana para outros problemas imprevistos. Assim, havería uma alta probabilidade de entrega dentro da “janela” necessária.

O custo dos sete dias de trabalho por semana resul­ tou na redução do lucro projetado em 40%. /\o eliminar as duas operações de inspeção manteve-se 10% do lucro. O plano descrito acima atendeu ao tempo e às espe­ cificações de desempenho com custo maior que, conse­ quentemente, reduziu o lucro em cerca de 30%. A solu­ ção para essa situação foi a de que só eram custos fixos o trabalho, o material e os custos de overhead do projeto, e o fornecedor estava disposto a aceitar um lucro reduzido.

SITUAÇÃO 2: O Custo é Fixo G>m um custo fixo, o desempenho vai variar em fun­ ção do tempo, como mostrado na Figura 16-7. A decisão de aderir ou nào aos dados do cronograma previsto é geral­ mente determinada pelo nível de desempenho. Na curva A, o desempenho pode aumentar rapidamente para o nível de 90% no início do projeto. Lm aumento de 10% no tempo

Esse projeto estava em apuros no meio do caminho, no terceiro mês em um cronograma de seis meses. O últi­ mo relatório indicava que a entrega seria adiada por trés semanas. Os custos estavam dentro do previsto até a data, mas o atraso de entrega deveria resultar em custos extras equivalentes a 20% do lucro previsto.

O projeto ficou fora do cronograma quando o fluxo de matérias-primas de um grande fabricante foi interrom­ pido durante trés semanas por um problema de qualida­ de descoberto apenas quando o material foi colocado em produção. Como o tempo de fabricação era um processo controlado, foi muito difícil compensar o tempo perdido. A primeira decisão foi que tudo seria feito para fazer a entrega no prazo de uma semana do cronograma ori­ ginal. A receita potencial perdida de pedidos futuros era tão grande que a entrega deveria ser feita “a todo custo”, como costumava dizer o presidente da empresa.

FIGURA 16-7 Compensoções com custos fixos.

532

Gerenciamento de Projetos

pode dar um aumento de 20% no desempenho. Depois de certo ponto, um aumento de 10% no tempo pode forne­ cer apenas um aumento de I % no desempenho. A empresa pode não querer arriscar o tempo adicional necessário para atingir o nível de desempenho de 100%, se for possível fazêlo. Na curva C, o tempo adicional deve ser sacrificado, pois é improvável que o cliente ficará satisfeito com um nível de desempenho de 30 a 40%. A Curva B é a curva mais difícil de analisar, a menos que o cliente tenha especificado exata­ mente qual o nível de desempenho que será aceitável

Se o custo é fixo, então é imperativo que o projeto te­ nha um contrato cuidadosamente redigido e compreen­ dido com especificações claras quanto ao nível de desem­ penho exigido e declarações muito claras de inclusão e de exclusão. A atenção cuidadosa com os custos supor­ tados por causa das mudanças de clientes ou requisitos adicionais pode ajudar a reduzir a possibilidade de um sobrecusto. Experiência na contratação garante que os custos que podem ser ignorados pelo gerente de projetos inexperiente estão incluídos, minimizando, assim, a ne­ cessidade dessas compensações durante o percurso. Itens negligenciados que podem aumentar os custos incluem:

• Excesso de relatórios detalhados • Documentação desnecessária • Excesso de documentação de monitoramento de tempo, custos e desempenho • Desenvolvimento de especificações detalhadas de equipamentos que poderíam ser comprados exter­ namente por menos custo • Tipo errado de contrato para esse tipo de projeto Muitas vezes, com uma restrição de custo fixo, o pri­ meiro item sacrificado é o desempenho. .Mas essa abor­ dagem pode conter desastres escondidos sobre a vida de um projeto se o desempenho sacrificado tiver se tornado essencial para atender algum requisito não especificado, como a manutenção em longo prazo. No longo prazo, uma degradação do desempenho pode realmente aumentar os custos em vez de diminuí-los. Portanto» o gerente do proje­ to deve ter certeza que tem uma boa compreensão dos cus­ tos reais associados com compensações de desempenho.

SITUAÇÃO 3: O Tempo é Fixo A Figura 16-8 identifica a situação em que o tempo é fixo e o custo varia de acordo com o desempenho. A Figu­ ra 16-8 é similar à Figura 16-7, em que a taxa de variação do desempenho com o custo é o fator de controle. Se o desempenho está no nível de 90% do custo-alvo, o forne­ cedor pode solicitar a desobrigação de desempenho. Isso é mostrado na curva A. No entanto, se a situação atual

reflete a curva B ou C, os custos adicionais devem ser efe­ tuados com as mesmas considerações da situação 1 - a saber, qual é a importância do cliente e que ênfase deve ser colocada em seus negócios futuros?

FIGURA 16-8 Compensoções com tempo fixo.

Concluir o projeto dentro do cronograma pode ser extremamente importante em determinados casos. Por exemplo, se uma bomba de combustível de um avião não é entregue quando o motor está pronto para o embar­ que, ela pode segurar o fabricante do motor, o fabricante de estruturas e, finalmente, o cliente. Todos os três po­ dem sofrer perdas substanciais por causa do atraso de um único componente. Além disso, os clientes que pos­ suem baixo desempenho e que lidam com grandes custos imprevistos tendem a ter memórias de longo prazo. Um vice-presidente enraivecido na loja do cliente pode exter­ minar novos contratos de qualquer proporção diante da falha real de entregar dentro do prazo. As vezes, mesmo que o tempo seja supostamente fixo, pode existir liberdade sem inconvenientes para o cliente. Isso poderia acontecer porque o programa inteiro (do qual o seu projeto é apenas um subcontrato) está atrasado e o cliente não está pronto para o seu projeto particular.

Outro aspecto do fator tempo é que o “alerta pre­ coce” de um desvio de tempo muitas vezes pode atenuar os danos causados ao cliente e aumentar grandemente a resposta favorável dele. O planejamento e o acompanha­ mento cuidadosos, a coordenação estreita com todas as funções envolvidas e o tratamento realista com cronogra­ mas de tempo antes e durante o projeto podem garantir a notificação antecipada para o cliente e a possibilidade de negociação de uma compensação de tempo e dinheiro, ou mesmo, desempenho técnico. A última coisa que um

ANÁLISE DE COMPENSAÇÕES EM UM AMBIENTE DE PROJETO

533

cliente quer é ter um relatório de progresso favorável até o fim do tempo agendado e então ser surpreendido com um atraso sério de cronograma.

tempo podem agora ser analisadas para diferentes níveis de desempenho. As curvas também podem ser redese­ nhadas para vários níveis de custos (isto é, 100,120,150% do custo-alvo) e níveis de tempo.

Quando o tempo é fixo, o cliente pode achar que tem certa flexibilidade na determinação de como chegar ao nível de desempenho desejado. Como mostra a Figura 16-9, o fornecedor pode estar disposto a aceitar os custos adicionais para maximizar a segurança do empregado.

Outro método para mostrar uma família de curvas é ilustrado na Figura 16-11. Aqui, o fornecedor pode ter vários caminhos de custo diferentes para atingir o tempo desejado e as restrições de desempenho. O caminho final selecionado depende do tamanho do risco que o fornece­ dor deseja tomar.

FIGURA 16-11 Família de curvas custos-tempo-desempenho.

FIGURA 16-9 Desempenho versus custos.

SITUAÇÃO 4: Nenhuma Restrição é Fixa Outra situação comum é aquela em que nem o tempo, nem o custo, nem o desempenho sào fixos. O melhor método para mostrar graficamente as relações de compensações é o desenvolvimento de curvas paramétri­ cas, como na Figura 16-10. As compensações de custos e

Houve várias tentativas para mostrar o problema de compensação graficamente. Infelizmente, tal procedimen­ to é bastante complexo e difícil de seguir. Uma abordagem mais comum é usar algum tipo de modelo de computador e manipular a compensação, como se fosse um problema dc programação linear e programação dinâmica. Isso também é, muitas vezes, difícil de executar e gerenciar. As compensações podem também ser necessárias em qualquer momento durante o ciclo de vida dc um projeto. A Figura 16-12 identifica como a importância relativa das

FIGURA 16-12 Compensações no ciclo de vida.

FIGURA 16-10 Análise de compensação com família de curvas.

(Cronograma não necessariamente comum.)

534

Gerenciamento de Projetos

limitações de tempo, custos e desempenho podem mudar ao longo do ciclo de vida do projeto. No início do projeto, os custos não puderam ser acumulados a um ponto em que fossem importantes. Por outro lado, o desempenho do projeto pode se tornar ainda mais importante do que o previsto. Nesse ponto, os desempenhos adicionais po­ dem ser “comprados”. Quando o projeto aproxima-se do seu término, a importância relativa da restrição de custos pode aumentar drasticamente, especialmente se os lucros do projeto são a maior fonte de receita da empresa. Da mesma forma, é provável que o impacto do desempenho e do cronograma seja menor.

Uma vez que os cursos alternativos de ação são de­ terminados, o passo 5 na metodologia é empregado, a fim de analisar e selecionar as alternativas viáveis. Ao analisar as alternativas deve-se incluir a preparação dos objetivos do projeto revisados para custos, desempenho e tempo, juntamente com uma análise dos recursos necessários, os cronogramas em geral e dos planos do projeto revisados que são necessários para suportar cada cenário. É, então, a função da alta gerência, em conjunto com os gerentes de projetos e os gerentes funcionais, escolher a solução que minimize o impacto global da empresa. Esse impacto não deve ser medido apenas em resultados financeiros de curto prazo, mas deve incluir considerações estratégicas e de mercado em longo prazo.

As seguintes tarefas podem ser incluídas nessa etapa:

• Elaborar um relatório de atualização formal do projeto, incluindo os escopos de trabalho, crono­ gramas e custos alternativos a atingir. • Sobrecusto mínimo • Conformidade com os objetivos do projeto • Atraso mínimo no cronograma • Construir uma árvore de decisão, incluindo custos, objetivos de trabalho e cronogramas, bem como uma estimativa da probabilidade de sucesso para cada condição que conduz ao ponto de decisão.

• Apresentar às gerências interna e externa do proje­ to as várias alternativas juntamente com uma esti­ mativa da probabilidade de sucesso. • Com o consentimento da administração, selecio­ nar a estratégia de execução adequada e iniciar a implementação. Isso pressupõe que a administra­ ção não insistirá em uma tarefa impossível.

O último item exige mais esclarecimentos. Muitas empresas usam uma lista de verificação para estabelecer os critérios para avaliação alternativa, bem como para a avaliação do potencial de problemas futuros. As pergun­ tas a seguir podem fazer parte dessa lista como: • • • • • • • • •

Será que outros projetos serão afetados? O retrabalho será exigido em tarefas anteriores? A reparação e/ou manutenção será mais difícil? As tarefas adicionais serão necessárias no futuro? Como o pessoal do projeto reagirá? Qual é o efeito sobre o ciclo de vida do projeto? A flexibilidade do projeto será reduzida? Qual é o efeito sobre os principais funcionários? Qual é o efeito sobre o (s) diente(s)?

A probabilidade de ocorrência e a gravidade desta de­ vem ser avaliadas para todos os potenciais problemas futuros. Se há uma alta probabilidade de que o problema volte a ocor­ rer e que será grave, um plano deve ser desenvolvido para reduzir essa probabilidade. As restrições internas, tais como mão de obra, materiais, máquinas, dinheinx gerenciamento, tempo, políticas, qualidade e requisitos em mudança, podem causar problemas ao longo do delo de vida de um projeto. As restrições externas como o capital, as datas de término e as responsabilidades também limitam a flexibilidade de projeto. Um dos melhores métodos para a comparação das alternativas é listá-las e, em seguida, classificá-las em or­ dem de importância percebida em relação a determinados fatores, tais como clientes, potencial de continuidade do negócio, déficit de custo e perda da reputação. Isso é mos­ trado na Tabela 16-2. Na tabela, cada um dos objetivos é

TABELA 16-2 Ponderação das alternativas Objetivos ^5

Alternativos

Ampliar

Manter

Atingir

Atingir

Negócios

Dentro

Custo

Especificações

Maximizar

Futuros

do Prazo

Atual

Atuais

Lucros

,05

0,4

0,25

0,10

0,20

lOIh

90f
l(h

C,

í,

f.

N® poda timprir o um morto

Nível de

estala

Desempenho inoteitázel

E

D

fundjmerfd de eqiipe ou o um mtrto pnrxipd do programa

7%o

Grande deswo em um morto

Desempenho oteitawl,

*3 enenomentos por Tylenol

Visão da Opinião Púbica

Vitima

Mesilé e o Fâmulo Infontil

Vila

Expiosõo do ChcHenga

Vila

Cobntic Defiomcmertc de ó!eo do Emou Yctfez

Vila Vilã

Sibmoiro Russo tó

Vilã

Ford e Filestore

Vilãs

Concorde; Ar Rance

AS FASES DO CICLO DE VIDA

As crises podem ser mostradas por meio dos ciclos de vida ilustrado na Figura 24-1. Ao contrário das fases tradicio­ nais do ciclo de vida do gerenciamento de projetos, cada uma dessas fases pode ser medida em horas ou dias, em vez de meses. O fracasso no gerenciamento de qualquer uma dessas fases pode levar a um desastre corporativo.

Snol de flat

Effe'dTefl»

Precoce

doho&mo

Artfcçõo d» Donos

Reside

Lkões

doGise

VERSUS VILÕES

O tribunal da opinião pública em geral lança o voto deci­ sivo sobre se a empresa envolvida na crise deve ser trata­ da como uma vítima ou um vilão quanto à forma como lidou com a crise. Os dois fatores determinantes são, na maioria das vezes, a demonstração de responsabilidade social da empresa durante a crise e como a empresa lidou com a mídia.

Desastre do reentrade do

24.11

Vítima

Concorde: British Airw/s

Viõ

Iríel e o Pentium

Vilã

(ar jrtoióes (ar a faties Irtersscdcs

FIGURA 24-1 Fases do ciclo de vida do gerenciamenio de crises.

A maioria das crises é precedida por sinais de aler­ ta ou gatilhos de risco que indicam que uma crise pode ocorrer. Essa é a fase de alerta precoce. Sinais de alerta comuns podem incluir violações de protocolos de segu­ rança durante o desenvolvimento de tecnologia, avisos de agências governamentais, o descontentamento do pú­ blico, as queixas dos clientes e avisos/preocupações dos funcionários de nível mais baixo. A maioria das empresas é ruim em gerenciamento de riscos, especialmente na avaliação dos primeiros si­ nais de alerta. A Intel, o caso da Nestlé e os desastres dos ônibus espaciais foram exemplos disso. Hoje, os gerentes de projetos são treinados em conceitos de gerenciamento dc riscos, mas especificamente relacionados com o ge­ renciamento do projeto, ou com o desenvolvimento do produto. Assim que o produto é comercializado, podem aparecer os indicadores mais graves de alerta precoce e, nesse momento, o gerente do projeto pode ser designado para outro projeto. Uma outra pessoa deve, então, avaliar os sinais de alerta precoces. Sinais de alerta precoces são indicadores de riscos potenciais. Tempo e dinheiro são uma necessidade para a avaliação desses indicadores, o que exclui a possibilidade dc avaliar todos os riscos. Portanto, as empresas devem ser seletivas quanto aos riscos que consideram. A fase seguinte do ciclo dc vida é o entendimen­ to do problema que provoca a crise. Por exemplo, du­ rante os envenenamentos por Tylenol, uma vez que as

710

Gerenciamento de Projetos

mortes estavam relacionadas com as cápsulas de Tyle­ nol, a primeira preocupação era descobrir se as cápsu­ las haviam sido contaminadas durante o processo de fabricação (ou seja, um trabalho interno) ou durante a distribuição e a venda (ou seja, um trabalho externo). Sem um entendimento da crise baseado em fatos, a mí­ dia pode formular suas próprias causas do problema e pressionar a empresa a seguir o caminho errado. A terceira fase do ciclo de vida é a fase de avaliação dos danos. A magnitude dos danos normalmente determinará o método de resolução. A subestimação da magnitude dos danos e a procrastinação podem levar o problema a crescer a um ponto em que o custo de correção pode aumentar em or­ dens de grandeza. A Intel descobriu isso do jeito mais difícil.

O estágio de resolução da crise ocorre quando a em­ presa anuncia a sua abordagem para resolver a crise. A for­ ma como o público vé o tratamento da crise pela empresa tem o potencial de construir ou destruir a empresa. O estágio final, as lições aprendidas, obriga que a empresa aprenda, não apenas a partir de sua própria cri­ se, mas de como os outros trataram suas crises. Aprender com os erros dos outros é melhor do que aprender com os próprios erros. Talvez o componente mais importante na Figura 24-1 seja o que corresponde às comunicações com as partes inte­ ressadas. Quando ocorre uma crise, o gerente de projeto de­ signado pode precisar se comunicar com as partes interessa­ das, que antes eram de menor importância, como a mídia e as agencias governamentais, e todos des têm interesses con­ correntes. Esses interesses concorrentes obrigam os geren­ tes de projetos a entender as necessidades e os objetivos das partes interessadas e também a possuir fortes habilidades de comunicação, resolução de conflitos e negociação. 24.12

AS IMPLICAÇÕES NO GERENCIAMENTO DE PROJETOS

F.mbora seja verdade que cada crise tem suas características únicas, há alguns pontos comuns que podem afetar o ge­ renciamento de projetos. Algumas implicações incluem: 1. O Líder da Equipe de Crise: é importante com­ preender quem irá liderar a equipe de crise. Ê muito raro que um gerente de projetos receba a responsabilidade de gerenciar uma equipe de crise, pelo menos com a nossa definição de crise. Muitas das decisões que precisam ser tomadas não são aquelas tomadas pelos gerentes de projetos, na execução de suas funções normais. O patrocina­ dor do projeto provavelmente assumirá um duplo papel e será o líder da equipe do projeto, além de atuar como patrocinador. Já no caso do Tylenol,

é comum que o CEO assuma a responsabilidade primária de gerenciar a equipe de crise. O líder da equipe de crise deve ter total autoridade para comprometer os recursos da empresa para o pro­ jeto. O gerente de projetos, como sabemos, atuará como gerente de projetos assistente. 2. O Comitê de Crise: em tempo de crise, deveria existir um comitê de crise composto pelos mais altos níveis de gestão. O comitê de crise também deve adesão multifuncional. Os gerentes de pro­ jetos e os gerentes de projetos assistentes irão, então, reportar-se a todos os membros do comi­ tê, em vez de a um único patrocinador. 3. As Comunicações da Crise: o líder da equipe de crise será o principal porta-voz para a crise e, em última instância, responsável por todas as comu­ nicações com a mídia. A mídia não pode ser igno­ rada e tem o poder de retratar a empresa como ví­ tima ou como vilã. Os mais altos níveis de gestão, especialmente os executivos com as habilidades profissionais de comunicação, devem fazer a co­ municação da crise com a mídia. F. essencial que a empresa fale com uma voz única, acompanha­ da de rapidez, honestidade, transparência, since­ ridade e compaixão para com as vítimas e suas famílias. A informação nào deve ser omitida do público. A retenção de informações da mídia com a desculpa de que a informação está incompleta pode ser encarada como obstrução da mídia. 4. Gerenciamento das Partes Interessadas: a equipe de crise deve identificar todas as par­ tes afetadas. Isso inclui banqueiros, acionistas, empregados, fornecedores, clientes, executivos, agências governamentais e afins. Cada uma das partes interessadas pode ter um interesse diferente na forma como a crise é resolvida, como interesse financeiro, médico, ambiental, político ou social. A equipe de crise também deve estar disposta a pedir a ajuda de agências externas, como a polícia, a Agência de Prote­ ção Ambiental1™, a Agência Federal de Geren­ ciamento de Emergências’™ e a Cruz Vermelha.

'to Environmental Protection Agency (EPA), ou Agência america­ na de proteção ambiental. O órgão brasileiro equivalente seria

o IBAMA - Insituto Brasileiro do Meio Ambiente c dos Recur­ sos Naturais Renováveis. s'n Federal Emergency Management Agency (FEMA), agência do

governo americano direcionada para serviços de emergência na ocorrência de desastres naturais ou provocados pelo ho­ mem. Foi criada em 1979 e faz parte do Departamento de Se­ gurança Interna (Department of Homeland Security).

711

GERENCIAMENTO DE PROJETOS DE CRISE

5.

6.

7.

A contribuição desses agentes externos pode ser inestimável. Assumir a Responsabilidade: a empresa deve aceitar a responsabilidade por suas ações (ou omissões) imediatamente e sem precisar ser coa­ gida a fazê-lo. Isso provavelmente vai se alinhar bem com a mídia. Tempo de Resposta: em cada crise» geralmente há uma pequena janela de oportunidade em que a ação rápida e decisiva pode limitar ou mesmo reduzir os danos. Outra razão para uma resposta rápida é a mídia. Quanto mais a empresa demo­ ra a agir, maior a probabilidade de a mídia olhar para a empresa desfavoravelmente. Compaixão: o respeito pelas pessoas é obrigató­ rio. É essencial que a empresa expresse e demons­ tre compaixão por todas as partes lesadas e suas famílias, independentemente de quem realmente tenha culpa pela crise. As emoções das vítimas e de suas famílias podem estar extremadas. O pú­

8.

9.

blico espera que a empresa demonstre compai­ xão. Isso inclui também visitar a cena da crise o mais rapidamente possível. Atrasar uma visita ao cenário de crise pode ser visto como uma falta de compaixão ou, pior ainda, que a empresa está escondendo algo. Documentação: em virtude do grande número de questões jurídicas que podem ser encontra­ das durante uma crise, a maioria das decisões tomadas terá de ser claramente documentada. O gerente do projeto e os membros da equipe associados devem possuir ótimas habilidades de redação. Capturar as Lições Aprendidas: a crise pode ocorrer sem aviso prévio. As empresas devem capturar a lição aprendida de ambas as crises, internas e externas. Isso inclui a análise de gati­ lhos de riscos, o desenvolvimento de modelos de gerenciamento de riscos e, talvez, até um credo corporativo.

O FUTURO DO GERENCIAMENTO DE PROJETOS1

25.0

TEMPOS DE MUDANÇA

Por mais de 50 anos, o gerenciamento de projetos tem sido utilizado, mas talvez não em uma abrangência mundial.

O que diferenciava as empresas nos primeiros anos era se usavam ou não gerenciamento de projetos, e não como usavam. Hoje, quase todas as empresas usam gerencia­ mento de projetos, e a diferenciação é se são simplesmente boas ou se realmente se destacam em gerenciamento de projetos. A diferença entre usar gerenciamento de projetos e ser bom em gerenciamento de projetos é relativamente pequena, e a maioria das empresas pode tomar-se boa em

TABELA 25-1 Visão executiva do gerenciamento de projetos Vtsõo Antiga 0 gerenciamento de profetos e im plono

0 gerencomento de projetos é ano

de coraro

competência estratégico ou centro!

Precrsomos de nosso pessool certíicodo

Precrsomos de pessoos canficodos em

comoPMP^s

gerencomento de projetos, processos de

negóco, e possrvdmerte em outros óreas como geraxiamenlo de prcgicmos e

gerencomento (fe riscos 0 gerencomento de projetos e un processo 0 getencomento de projetos evoluiu mas

poro o frobobo de execuçõo do projeto

Empresas como IBM, Microsoft, Siemens, Hewlett-Packard (HP) e Deloitte, só para citar algumas, chegaram à conclusão de que devem se destacar em gerenciamento de projetos. A IBM tem mais de 300.000 funcionários, sendo mais de 70% fora dos Estados Unidos, isso inclui em torno de 20.000 gerentes de projeto. A HP tem mais de 8.000 gerentes de projeto e 3.500 PMP^s. A HP deseja ter 8.000 gerentes de projeto e 8.000 PMP s. *

Para informações adicionais, consulte: KERZNER. H. The

fature of project management. Disponível em: chttps:// learningcen ter. iil.com/Saba/VVeb/Main/goto/Catalog>. Copyright © 2010 pelo International Institute for Learning. New York City. Reproduzido com permissão.

como um processo de negáios do cjje como puro processo de gerenoomento

gerenciamento de projetos em um período de tempo re­ lativamente curto, especialmente se tiver apoio do nível executivo. Mas a diferença entre ser bom ou ter excelência em gerenciamento de projetos é muito grande.

Visão Now

Nossos gaenles de projeto precsom

Precisamos de treinamento especidizodo

de heromento sobre comportomento

em compatomaito orgonzocwol,

orgonzoccnol tiodiccnol

indundo temos como egupes virtuais,

gerencomento de rekxioramaiio com portes oteressodas e gestão do dwsdode

Os Executivos Mudam sua Visão sobre a Importância do Gerendamento de Projetos

As empresas mencionadas anteriormente estão rea­ lizando o planejamento estratégico para gerenciamento de projetos e estão se concentrando fortemente no futuro. Muitas das coisas que essas empresas estão fazendo serão discutidas neste capítulo, começando com a visão de futu­ ro da alta administração. Anos atrás, a alta administração dava conversa fiada ao gerenciamento de projetos. Hoje, a alta administração mantém uma visão diferente do geren­ ciamento de projetos, como pode ser visto na Tabela 25-1.

O gerenciamento de projetos não é mais considera­ do uma ocupação de tempo parcial ou até mesmo uma

714

Gerenciamento de Projetos

posição de carreira tradicional. Ele é visto agora como uma competência estratégica necessária para a sobrevi­ vência da empresa. Capacidades superiores de gerencia­ mento de projetos podem fazer a diferença entre ganhar e perder um contrato. Para ilustrar como o gerenciamen­ to de projetos é importante para os clientes, considere os cinco requisitos seguintes que agora aparecem nas solici­ tações de propostas (RFPs): Apresente-nos o número de PMP®s em sua empresa e identifique quais PMP s * irão gerenciar o presente con­ trato caso vocé for o vencedor da licitação:

• Mostre que vocé tem uma metodologia empresa­ rial de gerenciamento de projetos (EPM), que te­ nha um histórico de sucessos repetidos. • Mostre que você está disposto a personalizar a metodologia para se ajustar aos nossos processos de negócio. • Mostre o nível de maturidade em gerenciamento de projetos de sua empresa e identifique qual mo­ delo de maturidade em gerenciamento de projetos você usou para realizar a avaliação. • Mostre que você possui uma biblioteca de me­ lhores práticas para gerenciamento de projetos e sua disposição em compartilhar esse conhecimen­ to conosco, assim como as melhores práticas que você descobrir em nosso projeto. Por mais de 20 anos, tornar-se PMP® foi considera­ do uma luz no fim do túnel. Hoje, isso mudou. Tornar-se PMP® é a luz na entrada do túnel. A luz no fim do túnel pode exigir múltiplas certificações. Como exemplo, depois de tornar-se PMP®, um gerente de projetos pode desejar certificar-se em:

• Competência como analista de negócios ou em ge­ rência de negócios • Gerenciamento de programas • Processos de negócios • Gerenciamento de projetos complexos • Six Sigma • Gestão de riscos

Algumas empresas têm conselhos de certificação que se reúnem com frequência e discutem quais programas de certificação seriam de valor para seus gerentes de projetos no futuro. Programas de certificação que exigem conheci­ mentos específicos dos processos da empresa ou de proprie­ dade intelectual da empresa podem ser desenvolvidos inter­ namente e ensinados por funcionários da própria empresa. Os executivos têm chegado à conclusão de que há um retomo sobre o investimento em educação de geren­ ciamento de projetos. Assim, os executivos estão agora

investindo pesadamente em treinamento personalizado de gerenciamento de projetos, especialmente em cursos comportamentais. Como exemplo, um executivo comen­ tou que sentiu que o treinamento em habilidades de apre­ sentação era a mais alta prioridade para seus gerentes de projetos. Se um gerente de projetos faz uma apresentação altamente elegante perante o cliente, o cliente acredita que o projeto está sendo gerenciado da mesma maneira. Se o cliente faz uma apresentação pobre, então o cliente tende a acreditar que o projeto está sendo gerenciado da mesma forma. Outros programas de treinamento que os executi­ vos sentem que seriam benéficos para o futuro incluem:

• Estabelecimento de métricas, indicadores chave de desempenho (KPls) e dashboards • Gerenciamento de projetos complexos • Como realizar estudos de viabilidade e análises de custo/benefício • Como validar e revalidar as premissas do projeto • Como estabelecer governança de projeto • Como gerenciar múltiplas partes interessadas • Como conceber e implementar "fluid" ou metodo­ logias de EPM adaptáveis • Como desenvolver habilidades de enfrentamento e habilidades de gerenciamento de estresse

Nos últimos anos, os livros sobre gerenciamento de projetos estão enfatizando a necessidade de que os geren­ tes de projetos se tornem mais orientados a negócios. De acordo com Linda Krctz Zaval e Terri Wagner:

Gerentes de Projetos hoje são munidos de poder e autoridade para estabelecer, manter e prever os resultados do projeta É um processo proativo em vez de reativo. Os gerentes de projetos hoje com­ partilham com analistas de finanças e marketing a justificação financeira dos projetos. Sua contri­ buição para o resultado financeiro corporativo foz da disciplina de gerenciamento de projetos um processo de negócio essencial do século XXI. Se for usado corretamente, o processo de ge­ renciamento de projetos pode afetar as relações de receita/despesa de uma forma positiva. Ele pode reduzir despesas e ajudar a alta adminis­ tração na escolha de um projeto em detrimento de outro, fornecendo uma estrutura de custos realista e defensável projetada para aumentar a vantagem competitiva e maximizar a prosperi­ dade do acionista. Em outras palavras, o geren­ ciamento de projetos é um poupador de custos, e não um centro de custo.

L. Krctz Zaval c T. Wagner, Project Manager Street Smarts

(Wiley, Hoboken, NJ, 2009), pg. xxi.

715

O FUTURO DO GERENCIAMENTO DE PROJETOS

Gerenciando Projetos Não Tradicionais

Durante várias décadas, nos tomamos especialistas em como gerenciar projetos tradicionais. Esses projetos tradicionais podem ser tanto para clientes internos como para clientes externos. Com esses projetos, a declaração de trabalho é razoavelmente bem definida, o orçamento e o cronograma são realistas, técnicas de estimativas ra­ zoáveis são utilizadas, e a meta final do projeto é estática. Usamos uma metodologia de gerenciamento de projeto que foi desenvolvida e submetida a melhorias contínuas após o uso em vários projetos. Essa metodologia tradicio­ nal se concentra no pensamento linear; seguimos fases do ciclo de vida bem definidas e temos formulários, mode­ los, listas de verificação e diretrizes para cada fase.

Agora que nos tornamos bons nesses projetos tradi­ cionais, estamos nos concentrando nossa atenção sobre os projetos não tradicionais ou complexos. A Tabela 25-2 mostra algumas das diferenças entre gerenciamento de projetos tradicionais e não tradicionais. TABELA 25-2 Projetos tradicionais versus nào tradicionais

Gerenciando Projetos Trodeionots

Gerenciando Projetos Não Tradicionais

Patrocinio de umo único pessoa

Governança per ccmrtê

• Trabalhar com parceiros e partes interessadas que podem ter ferramentas de gerenciamento de pro­ jetos limitadas e processos antiquados que são in­ compatíveis com o kit de ferramentas do gerente de projeto • Ter canais de comunicação complexos que podem ser diferentes para cada parte interessada Novos Desenvolvimentos em Gerenciamento de Projetos

Para que as empresas tenham sucesso na gestão de projetos complexos de forma repetitiva e funcionando como uma provedora de soluções, a metodologia de ge­ renciamento de projetos e ferramentas de acompanha­ mento deve ser fluida ou adaptativa. Isso significa que você pode precisar desenvolver uma metodologia de gerenciamento de projetos diferente para fazer interface com cada parte interessada, devido ao fato de que cada parte interessada pode ter diferentes requisitos e expecta­ tivas, e ao fato de que projetos mais complexos têm maio­ res períodos de tempo. A Figura 25-1 ilustra alguns dos novos desenvolvimentos em gerenciamento de projetos.

Possivelmente uma úrico porte interessado Varias partes interessados lomodo de decisão de projeto

fornada de decisão de projeto e de negócio

Metodologia de gerenciamento de projeto ríledvel

Metodologia de gerenciamento de projeto fiexrvef ou 'fluido'

Rekíóno de stotus peviódko

Reklõno em tempo red

0 sucesso é deftndo pelos restrições inçlos 0 sucesso é defindo por restrições concorrentes e vofcr

Os KPls sõo derrvafcs do sistema de medKõo de vokí ogregodo

KPls uncomerte onentodcs o valor

Empresas como IBM, HP, Microsoft e Siemens estão in­ vest indo pesado para se tomar fornecedoras de soluções e ajudar os clientes em nível mundial no gerenciamento de projetos não tradicionais, projetos complexos. Algumas características distintivas de projetos complexos são: • Trabalhar com um grande número de partes inte­ ressadas e parceiros, todos em diferentes níveis de maturidade em gerenciamento de projetos, muitos dos quais podem nem sequer entender a tecnolo­ gia do projeto • Lidar com várias equipes virtuais localizadas em todo o mundo, nas quais as decisões sobre o proje­ to podem ser feitas em favor de política, cultura ou crenças religiosas • Trabalhar em projetos de longo prazo que se ini­ ciam com um escopo mal definido, que se subme­ tem a inúmeras mudanças de escopo, e nos quais o ponto final é um alvo em movimento e não estático

FIGURA 25-1 Alguns novos desenvolvimentos.

Os cinco itens na figura se encaixam quando aplica­ dos corretamente: • Novos Critérios dc Sucesso: No início do projeto» o gerente do projeto vai se reunir com o cliente e as partes interessadas para chegar a um acordo so­ bre o que constitui o sucesso nesse projeto. Inicial­ mente, muitas das partes interessadas podem ter sua própria definição de sucesso, mas o gerente de projetos deve moldar um acordo. • Indicadores Chave de Desempenho: Uma vez que os critérios de sucesso são acordados, o gerente do projeto e a equipe do projeto irão trabalhar com as partes interessadas para definir os KPls que cada parte interessada deseja acompanhar. F. possível que cada parte interessada tenha diferentes requi­ sitos de KPI. • Medição: A atualização de dashboards e KPls re­ quer medição. Esta é a parte mais difícil, porque

716

Gerenciamento de Projetos

nem todos os membros da equipe ou parceiros estratégicos podem ter a capacidade de rastrear to­ dos os KPls. • Dashboard Design: Uma vez que os KPls são iden­ tificados, o gerente do projeto, juntamente com os membros de equipe de projeto apropriados, irá projetar um dashboard para cada parte interessada. Alguns dos KPIs nos dashboards serão atualizados periodicamente, enquanto outros podem ser atua­ lizados em tempo real. • Governança: Uma vez que as medições são feitas, qualquer decisão necessária deve ser tomada ou supervisionada pelo conselho de governança. O conselho de governança pode incluir as principais partes interessadas, bem como partes interessadas que são apenas observadoras. Conclusões

O futuro do gerenciamento de projetos pode muito bem repousar nas mãos dos provedores de solução. Esses provedores vão personalizar metodologias de gerencia­ mento de projetos para cada cliente, e possivelmente para cada parte interessada. Eles devem ser capazes de desen­ volver habilidades de gerenciamento de projetos que vão bem além do atual Guia PMBOK® e demonstrar vonta­ de de tomar decisões de negócios bem como decisões de projeto. O futuro do gerenciamento de projetos parece muito bom, mas será um desafio. PROJETOS COMPLEXOS

25.1

Na seção anterior, afirmamos que estaremos gerenciando mais projetos complexos no futuro. Projetos complexos podem diferir de projetos tradicionais por uma infinida­ de de razões, incluindo:

• • • • • • • • • •

Tamanho Valor em moeda Requisitos incertos Escopo incerto Entregas incertas Interações complexas Credenciais incertas da força de trabalho Separação geográfica entre vários fusos horários O uso de grandes equipes virtuais Outras diferenças

Existem inúmeras definições de projeto complexo baseado nas interações entre dois ou mais dos elementos

Adaptado de: KERZNER, H.; BELACK, C. Managing complex projects. Hoboken, NJ: Wiley and I1L co-publishers, 2010,

Capitulo 1.

relacionados aqui. Os projetos que vocé gerencia dentro de sua própria empresa podem ser considerados comple­ xos se o escopo for grande e a declaração de trabalho for apenas parcialmente completa. Algumas pessoas acredi­ tam que projetos de P&D são sempre complexos, pois se você pudesse estabelecer um plano para a P&D, então provavelmente não teria um P&D. P&D é estabelecido quando você não tem 100% de certeza de para onde você está dirigindo, não sabe o que vai custar, e você não sabe quando e se vai chegar lá.

/X complexidade pode ser definida de acordo com o número de interações que devem ocorrer para que o trabalho seja executado. Quanto maior o número de uni­ dades funcionais que devem interagir, mais difícil é re­ alizar a integração. A situação se torna mais difícil se as unidades funcionais estão dispersas por todo o mundo e se as diferenças culturais tornam difícil integração. A complexidade também pode ser definida de acordo com o tamanho e comprimento. Quanto maior for o projeto em escopo e custos, e quanto maior o prazo, mais prová­ vel será a ocorrência de mudanças no escopo, afetando significativamente o orçamento e o cronograma. Projetos grandes e complexos tendem a ter grandes custos excessi­ vos e desvios de cronograma. Bons exemplos disso são o Aeroporto Internacional de Denver, o canal entre a Ingla­ terra e França, e o “Big Dig” em Boston. Compensações

O gerenciamento de projetos é uma tentativa de me­ lhorar a eficiência e eficácia na utilização dos recursos, fazendo com que o trabalho flua multidirecionalmente através de uma organização. Isso vale tanto para projetos tradicionais como para projetos complexos. Inicialmen­ te, isso pode parecer fácil de realizar, mas normalmen­ te há uma série de restrições impostas a um projeto. As restrições mais comuns são tempo, custo e desempenho (também referido como escopo ou qualidade) e sào co­ nhecidas como restrições triplas.

Do ponto de vista da alta administração, o objetivo do gerenciamento de projetos pode ser satisfizer as res­ trições triplas de tempo, custo e desempenho, mantendo boas relações com os clientes. Infelizmente, em virtude do fato de que a maioria dos projetos tem algumas carac­ terísticas únicas, estimativas altamente precisas podem não ser possíveis, e compensações entre as restrições tri­ plas ou concorrentes podem ser necessárias. A gerência executiva, a gerência funcional e as principais partes inte­ ressadas devem ser envolvidas em quase todas as discus­ sões sobre compensação para garantir que a decisão final seja tomada para servir ao melhor interesse do projeto, da empresa e das partes interessadas.

717

O FUTURO DO GERENCIAMENTO DE PROJETOS

Se múltiplas partes interessadas estão envolvidas, como ocorre em projetos complexos, então um acordo de todas as partes interessadas pode ser necessário. Os geren­ tes de projetos podem possuir conhecimento suficiente para tomar algumas decisões técnicas, mas podem não possuir conhecimento de negócios ou técnicos suficientes para determinar adequadamente o melhor curso de ação para endereçar os interesses da empresa, bem como das partes interessadas individuais do projeto. Conjunto de Habilidades

Todos os gerentes de projetos tém habilidades, mas nem todos terão as habilidades certas para os trabalhos certos. Para projetos internos de uma empresa, pode ser possível desenvolver um conjunto de habilidades ou co­ nhecimentos universais específicos da empresa. Treina­ mentos específicos podem ser criados para dar suporte a requisitos de conhecimento baseados na empresa.

Para projetos complexos, com inúmeras partes inte­ ressadas de diferentes países com diferentes culturas, en­ contrar o gerente de projetos perfeito pode ser uma tarefa impossível. Hoje, estamos na fase da infância na compre­ ensão de projetos complexos e podemos não ser capazes dc determinar o conjunto de habilidades ideal para o ge­ renciamento de projetos complexos. Devemos lembrar que o gerenciamento de projetos existe há mais de três décadas antes que o primeiro Project Management Body of Knowledge (Guia PMBOK ) * fosse criado, c mesmo agora com a última versão do Guia PMBOK , * ele ainda é refe­ rido como um “guia”. Podemos, no entanto, concluir que há certas habili­ dades necessárias para gerenciar projetos complexos. Al­ gumas habilidades adicionais que podem ser necessárias são como gerenciar equipes virtuais, compreender dife­ renças culturais, gerenciar múltiplas partes interessadas cada qual com uma agenda diferente, e compreender o impacto da política no gerenciamento de projetos. Governança

O envolvimento do usuário do início ao fim em pro­ jetos complexos é essencial. É lamentável que o envolvi­ mento do usuário possa mudar de acordo com a política e a duração do projeto. Nem sempre é possível ter a mesma comunidade de usuários ligada ao projeto do começo ao fim. Promoções, mudanças em posições de autoridade e poder devido a eleições políticas, bem como aposentado­ rias, podem causar mudanças na participação do usuário. A governança é o processo de tomada de decisão. Em grandes projetos complexos, a governança aparecerá nas mãos de muitos, em vez de nas mãos de poucos. Cada

parte interessada vai ou esperar ou exigir fazer parte de todas as decisões críticas sobre o projeto. Os canais de governança devem ser claramente definidos no início do projeto, possivelmente antes que o gerente de projetos seja designado. Mudanças na governança (que são espe­ radas quanto mais tempo o projeto dure) podem ter um sério impacto na forma como o projeto é gerenciado. Tomada de Decisão

Projetos complexos têm problemas complexos. To­ dos os problemas geralmente tém soluções, mas nem to­ das as soluções podem ser boas ou mesmo práticas. Além disso, a solução para alguns problemas pode ser mais dis­ pendiosa do que outras soluções. Identificar um proble­ ma geralmente é facil. Identificar alternativas pode exigir a participação de muitas partes interessadas, e cada uma pode ter uma visão diferente do problema real e das alter­ nativas possíveis. Para complicar a questão, alguns países têm ciclos de tomada de decisão muito longos» mesmo para a identificação do problema, bem como para a se­ leção da melhor alternativa. Cada parte interessada pode selecionar a alternativa que é melhor para si, em vez de selecionar a melhor alternativa para o projeto. Obter aprovação pode ser muito demorado, especial­ mente se a solução exigir que seja levantado capital adicio­ nal, e se a política tiver um papel ativo. Em alguns países emergentes, cada projeto complexo pode exigir a assinatura da maioria dos ministros e altos líderes do governo. As de­ cisões também podem ser baseadas em política e religião. Comparando Projetos Tradicionais e Não Tradicionais

Anteriormente, na Tabela 25-2, mostramos as dife­ renças entre projetos tradicionais e não tradicionais ou projetos complexos. O projeto tradicional, que a maioria das pessoas gerencia é geralmente de duração inferior a 18 meses. Em algumas empresas, um projeto tradicional pode ser de seis meses ou menos. A duração do projeto, geralmente, depende do setor. Na indústria automobilís­ tica, por exemplo, um projeto tradicional dura três anos.

Em projetos de 18 meses ou menos, consideramos que a tecnologia é conhecida com algum grau de confian­ ça e que o projeto será submetido a poucas mudanças ao longo da vida. O mesmo vale para as premissas. Tende­ mos a acreditar que as premissas feitas no inicio do proje­ to permanecerão intactas durante o projeto, a menos que ocorra uma crise. As pessoas que são alocadas ao projeto provavelmente irão permanecer a bordo do início ao fim. As pessoas po­ dem ser alocadas em tempo integral ou parcial. Isso inclui o patrocinador do projeto bem como os membros da equipe.

718 Em virtude do fato de o projeto durar 18 meses ou menos, a declaração de trabalho é geralmente razoavel­ mente bem definida, e o plano do projeto se baseia em estimativas razoavelmente bem compreendidas e com­ provadas. Podem ocorrer custos excedentes e desvios no cronograma, mas não no mesmo nível em que ocorrem em projetos complexos. Os objetivos do projeto, bem como os marcos críticos ou datas de entregas, são razoa­ velmente estacionários e não devem mudar, a menos que ocorra uma crise. As complexidades de projetos não tradicionais pare­ cem ser guiadas por tempo e custo. Os projetos complexos podem chegar a dez anos ou mais. Em virtude do longo prazo de duração, as premissas feitas no início do projeto provavelmente não serão válidas no seu final. As premissas deverão ser revalidadas ao longo da vida do projeto. Da mesma forma, pode-se esperar que a tecnologia mude ao longo do projeto. Mudanças na tecnologia po­ dem produzir mudanças significativas e caras no escopo, a ponto de o produto final não se parecer com a entrega inicialmente prevista.

As pessoas no comitê de governança e nos papéis de tomada de decisão são mais provavelmente pessoas sê­ niores e podem estar perto da aposentadoria. Com base no tamanho real do projeto, pode-se esperar que a estru­ tura de governança se altere no decorrer do projeto, se este tiver dez anos de duração ou mais.

Em razão de mudanças de escopo, a declaração de tra­ balho pode sofrer várias revisões ao longo do ciclo de vida do projeto. Novos grupos de governança e novas partes in­ teressadas podem ter pautas ocultas e exigir que o escopo seja alterado, caso contrário podem até mesmo cancelar seu apoio financeiro ao projeto. Finalmente, sempre que você tem um projeto complexo de longo prazo, no qual são esperadas mudanças de escopo contínuas, o alvo final pode estar se movendo. Em outras palavras, o plano de projeto deve ser construído para atingir um alvo em movimento. Dada a premissa de que gerentes de projetos estão agora mais ativamente envolvidos no negócio, devemos acompanhar as premissas da mesma forma que acompa­ nhamos os orçamentos e cronogramas. Se as premissas estão erradas ou não são mais válidas, então talvez seja necessário alterar a declaração de trabalho ou mesmo considerar o cancelamento do projeto. Também devemos acompanhar o valor esperado ao final do projeto, pois al­ terações inaceitáveis no valor final podem ser outra razão para o cancelamento do projeto.

A maioria das empresas tem ou está no processo de desenvolvimento de uma metodologia EPM. Sistemas de F.PM são geralmente processos rígidos projetados em

Gerenciamento de Projetos

torno de políticas e procedimentos e trabalham eficiente­ mente quando a declaração de trabalho é bem definida. Mas com os novos tipos de projetos previstos para a pró­ xima década, esses processos rígidos e inflexíveis podem ser um entrave.

Sistemas de EPM devem tornar-se mais flexíveis, a fim de satisfazer as necessidades de negócios. Os critérios para bons sistemas vão inclinar-se para formulários, dire­ trizes, modelos e listas de verificação, em vez de políticas e procedimentos. Mais flexibilidade será dada aos gerentes de projetos a fim de tomar as decisões necessárias para sa­ tisfazer as necessidades de negócio do projeto. A situação é mais complicada quando todas as partes interessadas ativas precisam usar a metodologia, e ter várias metodo­ logias no mesmo projeto nunca é uma boa ideia. Alguns países podem ser bastante experientes em gerenciamento de projetos enquanto outros podem ter apenas conheci­ mento superficial. No futuro, a suposição de que o plano original está correto pode ser uma suposição falha. Como as necessi­ dades de negócio do projeto mudam, a necessidade de alterar o plano também será evidente. Além disso, a to­ mada de decisão baseada inteiramente sobre as restrições triplas, com pouca atenção para o valor final do projeto, pode ser uma má decisão. Simplificando, a visão de hoje de gerenciamento de projetos é bastante diferente do que as visões no passado, e isso se deve parcialmente ao reco­ nhecimento dos benefícios do gerenciamento de projetos nas últimas duas décadas.

Talvez a principal diferença seja com quem o gerente de projetos deve interagir diariamente. F.m projetos tra­ dicionais, o gerente de projetos faz interface com o pa­ trocinador do projeto e o cliente, e ambos podem ser a única governança no projeto. Em projetos complexos, a governança é por comitê e pode haver várias partes inte­ ressadas cujas preocupações precisam ser abordadas. Em projetos complexos, o gerente de projeto precisa de uma metodologia de gerenciamento de projetos fluida ou flexível, capaz de interagir com múltiplas partes inte­ ressadas. A metodologia precisa ser mais alinhada aos pro­ cessos de negócios do que aos processos de gerenciamento de projetos, já que o gerente de projetos pode precisar to­ mar tanto decisões de negócios como decisões de projeto. Projetos complexos parecem ser ditados mais por decisões de negócios do que por puras decisões de projeto.

Projetos complexos são mais orientados pelo va­ lor final do projeto do que pelas restrições concorren­ tes. Projetos complexos tendem a demorar mais tem­ po do que o previsto e custam mais do que o orçado inicialmente, a fim de garantir que o resultado final

719

O FUTURO DO GERENCIAMENTO DE PROJETOS

terá o valor desejado pelos clientes e partes interessa­ das. Simplificando, projetos complexos tendem a ser orientados a valor, em vez de serem orientados pelas restrições triplas ou concorrentes. A razão é simples: completar um projeto dentro das restrições triplas não é necessariamente sucesso se o valor não existir na conclusão do projeto.

Durante várias décadas, o gerenciamento de projetos tem sido usado para apoiar projetos tradicionais. Projetos tradicionais são fortemente baseados no pensamento line­ ar, temos fases do ciclo de vida bem estruturadas e mode­ los, formulários, guias e listas de verificação para cada fase. Contanto que o escopo seja razoavelmente bem definido, o gerenciamento de projetos tradicional funciona bem. Infelizmente, apenas uma pequena porcentagem dos projetos dentro de uma empresa se enquadra nessa cate­ goria. /\ maioria dos projetos nào tradicionais ou com­ plexos é gerenciada “com a cara e a coragem”, pois são, em grande parte, baseados em cenários de negócios, nos quais o resultado ou as expectativas podem mudar dia a dia. Desta forma, as técnicas de gerenciamento de proje­ tos nào eram nem necessárias nem usadas nesses projetos complexos, que eram mais orientados a negócios, e ali­ nhados a planos estratégicos de cinco ou dez anos, que eram constantemente atualizados. Agora, estamos final mente percebendo que o geren­ ciamento de projetos pode ser utilizado nesses projetos complexos, mas os processos tradicionais de gerencia­ mento de projetos podem ser inadequados ou devem ser modificados. O estilo de liderança para projetos comple­ xos pode nào ser o mesmo que o utilizado em projetos tradicionais. O gerenciamento de risco é significativa­ mente mais difícil em projetos complexos, e é necessário o envolvimento de mais participantes e partes interessadas.

de projetos. A maioria das ferramentas foi criada interna­ mente com idéias descobertas por meio de lições apren­ didas e melhores práticas. 25.2

TEORIA DA COMPLEXIDADE

Os gerentes de projetos nào podem controlar projetos complexos com o mesmo estilo de gerenciamento e ferra­ mentas que sào usadas em projetos tradicionais. Práticas tradicionais de gerenciamento de projetos, especialmente se seguirmos o Guia PMBOK®, incentivam o pensamen­ to linear e muita estrutura e controle. Enquanto alguns projetos podem ter sucesso usando estrutura e rígidas metodologias de F.PM, outros projetos irào padecer.

A teoria da complexidade é um resultado da teoria do caos, e argumenta que essa estrutura nào necessaria­ mente permite a flexibilidade necessária para lidar com situações complexas ou com um ambiente em que sào necessárias interações humanas imprevisíveis. Enquanto a teoria da complexidade ainda está no estágio de infân­ cia, os livros estão começando a mostrar a aplicação da teoria da complexidade no gerenciamento de projetos. De acordo com Curlee e Gordon': A teoria da complexidade é sobre tirar proveito do caos de modo a permitir que o gerente de projetos aumente sua eficácia ou de sua equipe, permitindo certo grau de individualidade para mover um projeto para frente. Muitas vezes, per­ mitir o caminhar aleatório de um determinado indivíduo permite que um certo nível de criati­ vidade tenha sucesso. Uma equipe eficaz pode ser mais eficaz do que um indivíduo; permitir que um indivíduo abra o caminho muitas vezes pode levar a equipe mais longe e mais rápido. A complexidade é a manifestação do empoderamento e delegação de tarefas para permitir que a individualidade dê suporte à colmeia.

Todos os países do mundo tém projetos complexos, mas nem todos tém recursos qualificados para gerenciar esses projetos. Portanto, as empresas que gastaram tempo e esforço para desenvolver metodologias flexíveis de ge­ renciamento de projetos e se tornarem provedores de so­ luções, são empresas que estão competindo no mercado global. Embora essas empresas possam oferecer produtos e serviços como parte de seu negócio principal, elas po­ dem ver seu futuro como fornecedoras globais de solu­ ções para o gerenciamento de projetos complexos.

E verdade que algumas pessoas têm medo da teoria da complexidade, pois ela defende menos controle. Este argumento tem algum mérito, mas olhando para o Rela­ tório do Caos, preparado pelo Standish Group, fica óbvio que alterações na forma de gerenciar projetos complexos são necessárias, considerando que, a cada ano, nos últi­ mos 15 anos, quase 70% dos projetos de TI nào foram considerados bem-sucedidos.

Para essas empresas, serem boas em gerenciamento de projetos nào basta, elas devem se sobressair em geren­ ciamento de projetos. Devem inovar seus processos ao ponto em que todos os processos e metodologias sejam altamente fluidos. Elas têm uma extensa biblioteca de ferramentas para apoiar os processos de gerenciamento

CURLEE, W., GORDON, R. L Complexity Theory and Project Management. I loboken, NJ: Wiley, 2011), p. 9.0 capitulo 2 do livro contém uma boa discussão sobre as limitações do Guia * PMBOK quando aplicado a projetos mais complexos e as mudanças que podem ser necessárias.

720 25.3

Gerenciamento de Projetos

ESCALADA DE ESCOPO (SCOP£ O?££P)

Há três coisas que a maioria dos gerentes de projetos sabe que vai acontecer quase que inevitavelmente: a morte, os impostos e scope creep. Scope creep é a melhoria contínua dos requisitos do projeto enquanto as entregas do projeto estão sendo desenvolvidas. O scope creep é visto como o crescimento do escopo do projeto. Quanto maior e mais complexo é o projeto, maiores as chances de um aumento de escopo significativo.

Embora o scope creep possa ocorrer em qualquer pro­ jeto de qualquer setor, é mais frequentemente associado com projetos de desenvolvimento de sistemas de informa­ ção. Mudanças de escopo podem ocorrer em qualquer fase do ciclo de vida do projeto. As mudanças ocorrem porque é da natureza do ser humano não ser capaz de descrever completamente o projeto ou o plano para executar o pro­ jeto desde o início. Isto é particularmente verdadeiro em projetos grandes e complexos. Como resultado, ganhamos mais conhecimento no decorrer do projeto, e isso leva à escalada do escopo e mudanças de escopo.

O scope creep é uma ocorrência natural para gerentes de projetos. Temos de aceitar o fato de que isso vai acon­ tecer. Algumas pessoas acreditam que existem amuletos mágicos, poções e rituais que podem impedir o scope cre­ ep. Isso certamente não é verdade. Talvez o melhor que podemos fazer é estabelecer processos, tais como sistemas de gerenciamento de configuração, ou painéis de controle de mudanças para conseguir algum controle sobre o sco­ pe creep. No entanto, estes processos são projetados não tanto para evitar o scope creep, mas sim para evitar que mudanças indesejadas de escopo ocorram. Portanto, podemos afirmar que o scope creep não é apenas permitir que o escopo mude, mas uma indicação de quão bem conseguimos gerenciar as mudanças no es­ copo. Se todas as partes concordam que a mudança do es­ copo é necessária, então talvez possamos argumentar que o escopo simplesmente mudou, em vez de ter aumentado. Algumas pessoas encaram o scope creep como uma mu­ dança de escopo não aprovada pelo patrocinador ou pelo comitê de controle de mudanças.

O scope creep é muitas vezes visto como sendo pre­ judicial para o sucesso de um projeto, porque aumenta o custo e prolonga o cronograma. Embora isto seja verda-

5

Para obter informações adicionais, consulte KERZNER, 11. Managing Scope Creep. Disponível cm: . Copyright© 2010 pelo International Institutefor I.earning. New York City. Reproduzido com permissão.

de, o scope creep também pode produzir resultados favo­ ráveis, como componentes que dão ao seu produto uma vantagem competitiva. O scope creep também pode agra­ dar o cliente, se as mudanças forem vistas como um valor adicional para a entrega final. Definindo o Escopo

Talvez o passo mais crítico na fase de iniciação de um projeto seja a definição do escopo. A primeira tentativa de definição do escopo pode ocorrer tão cedo como na pro­ posta ou na fase de licitação. Nesse ponto, tempo e esfor­ ço suficientes podem não ser dedicados a uma determi­ nação precisa ou compreensão do escopo e dos requisitos do cliente. E para piorar as coisas, tudo isso pode ser feito bem antes de o gerente de projeto ser trazido a bordo.

Uma vez que o gerente de projeto for trazido a bor­ do, ele deverá familiarizar-se com os requisitos de escopo e validá-los, caso já tenham sido preparados, ou entrevis­ tar as várias partes interessadas e coletar as informações necessárias para uma compreensão clara do escopo. Ao fazer isso, preparamos uma lista do que está incluído e excluído do nosso entendimento dos requisitos. Ainda assim não importa o quão meticulosamente o gerente de projetos tente fazer isso, a clareza no escopo nunca é co­ nhecida com 100% de certeza. O objetivo do gerente de projetos é estabelecer os li­ mites do escopo. Para fazer isso, a visão sobre o projeto tanto do gerente de projetos como de cada parte interes­ sada deve estar alinhada. Também deve haver um alinha­ mento com os objetivos de negócio da empresa, pois deve haver uma razão de negócio válida para realizar esse pro­ jeto. Se os alinhamentos nào ocorrerem, então os limites para o projeto se tornarão dinâmicos ou em mudança constante, em vez de haver um limite estacionário.

A Figura 25-2 mostra os limites do projeto. O limite do projeto é concebido para satisfazer tanto aos obje­ tivos de negócio estabelecidos pela sua empresa, como aos objetivos técnicos/de escopo estabelecidos pelo seu cliente, considerando que seja um cliente externo. O gerente do projeto e as diferentes partes interessadas, incluindo o cliente, podem ter uma diferente interpre­ tação do limite do escopo e dos limites do negócio. Da mesma forma, o gerente de projetos pode focar forte­ mente na tecnologia que o cliente precisa, em vez de focar no valor do negócio que sua empresa deseja. Sim­ plificando, o gerente de projetos pode buscar exceder as especificações enquanto as partes interessadas e sua empresa querem apenas atender aos níveis mínimos de especificação no mais curto espaço de tempo.

721

O FUTURO DO GERENCIAMENTO DE PROJETOS

gamento do cronograma. Mas o scope creep é realmen­ te mau? Talvez não, é algo com o que devemos conviver como gerentes de projeto. Alguns projetos podem ter a sorte de evitar o scope creep. Em geral, quanto maior for o projeto, maior a probabilidade de que ocorra o scope creep.

A duração do projeto também impacta o scope creep. Se o ambiente de negócios é altamente dinâmico e em cons­ tante mudança, produtos e serviços devem ser desenvolvi­ dos para satisfazer as necessidades existentes ou futuras do mercado. Portanto, em projetos de longo prazo, o scope cre­ ep pode ser visto como uma necessidade para ajustar-se às demandas dos clientes, e componentes de projeto podem ser necessários para obter a aceitação do cliente.

Dependências do FIGURA 25-2

A fronteiro do projeto.

Quando ocorre o scope creep e mudanças no escopo sào necessárias, o limite do escopo pode se mover. No en­ tanto, o limite do escopo pode nào ser capaz de se movi­ mentar, caso altere a fronteira dos negócios e as expectati­ vas da empresa. Como exemplo, uma mudança de escopo que adicione valor a um produto pode nào ser aprovada, caso estenda a data de lançamento do produto ou eleve o preço do produto no mercado. É importante entender que o escopo do projeto nào é o que o cliente pediu, mas o que concordamos em en­ tregar. E o que concordamos pode ter inclusões e exclusões, em relação ao que o cliente solicitou.

Scope Creep

Muitas vezes, mudanças de escopo sào aprovadas sem avaliar o impacto subsequente que podem ter nos pacotes de trabalho que ainda não foram iniciados. Como exemplo, fazer uma mudança de escopo logo no início do projeto para alterar o design de um componente pode resultar em um aumento significativo de custo se as matérias-primas encomendadas e pagas não forem mais necessárias. Além disso, poderia haver outros fornecedores que começaram a trabalhar em seus projetos assumindo que o design ori­ ginal foi finalizado. Agpra, uma pequena mudança de es­ copo por um fornecedor pode ter um sério impacto sobre outros fornecedores subsequentes. As dependências devem ser consideradas quando da aprovação de uma mudança de escopo, pois o custo para reverter uma decisão anterior pode ter um impacto financeiro grave no projeto.

Há certos fatos que sabemos agora:

• O limite do escopo é o que o gerente de projetos se compromete a entregar. • O limite geralmente nunca é claramente definido no início do projeto. • Às vezes, o limite pode nào estar claramente de­ finido até que estejamos plenamente dentro do projeto. • Podemos precisar usar planejamento progressivo ou em ondas sucessivas para articular claramente o escopo. • Às vezes o escopo não é totalmente conhecido até que as entregas finais sejam concluídas e testadas. • Por fim, até mesmo depois da aceitação das entre­ gas pelas partes interessadas, a interpretação do limite do escopo ainda pode ser debatida.

O limite do escopo pode flutuar durante a execu­ ção do projeto, porque, conforme avançamos no projeto e mais conhecimento é adquirido, identificamos adições não planejadas para o escopo. Este fenômeno de scope creep é então acompanhado por aumentos de custo e prolon­

Causas do

Scope Creep

A fim de evitar que o scope creep ocorra, deve-se começar por compreender as causas do scope creep. As causas sào inúmeras e é uma ilusào acreditar que todas as causas podem ser prevenidas. Muitas das causas estão muito além do controle do gerente de projetos. Algumas causas estão relacionadas ao scope creep de negócios, e ou­ tras sào parte do scope creep técnico:

• Mau Entendimento de Requisitos: Isso ocorre quando aceitamos ou nos apressamos para um pro­ jeto sem entender totalmente o que deve ser feito. • Requisitos Mal Definidos: As vezes, os requisitos sào tào mal definidos que devemos fazer inúmeras suposições, e conforme entramos nas fases poste­ riores do projeto, descobrimos que algumas delas nào sào mais válidas. • Complexidade: Quanto mais complexo o proje­ to, maior o impacto do scope creep. Ser ambicioso demais e acreditar que podemos entregar mais do que podemos oferecer em um projeto complexo pode ser desastroso.

722

Gerenciamento de Projetos

• Falhar no Detalhamento: Quando um projeto é iniciado usando apenas requisitos de alto nível, o aumento do scope creep pode ser esperado quando nos envolvemos nas atividades detalhadas da es­ trutura analítica do projeto. • Má Comunicação: Falta de comunicação entre o gerente do projeto e as partes interessadas pode levar a requisitos mal definidos e má interpreta­ ção do escopo. • Incompreensão das Expectativas: Independentemente de como o escopo é definido, as partes interessadas e os clientes têm expectativas quanto aos resultados do projeto. A incapacidade de com­ preender essas expectativas antecipadamente pode levar a caras mudanças subsequentes. • Featuritis: Também é chamado de “embelezar” um projeto e ocorre quando a equipe do projeto acres­ centa por conta própria features que, muitas vezes, são desnecessárias, e funcionalidades na forma de “adereços”. • Perfeccionismo: Isso ocorre quando a equipe do projeto inicia mudanças no escopo de forma a ex­ ceder as especificações e requisitos, em vez de ape­ nas satisfazê-los. As equipes de projeto podem ver isso como uma chance de obter glória. • Avanço de Carreira: Scope creep pode exigir recur­ sos adicionais, assim talvez tornando o gerente de projetos mais poderoso aos olhos da alta adminis­ tração. O scope creep também estende os projetos e fornece aos membros da equipe uma casa tem­ porária mais duradoura caso não tenham certeza sobre sua próxima missão. • Pressão devida ao Time-to-Market: Muitos proje­ tos começam com um ponto de vista otimista. Se a empresa exerce pressão sobre o gerente de projetos para se comprometer com uma data de lançamen­ to de produto irrealista, então o gerente de pro­ jetos pode precisar reduzir funcionalidades. Isto pode ser mais ou menos dispendioso, dependendo de onde a redução de escopo ocorre. • Regulamentações Governamentais: O cumpri­ mento da legislação e mudanças de regulamenta­ ção podem causar scope creep dispendiosos. • Fraude: Às vezes, sabemos, com bastante antece­ dência, que a declaração de trabalho do cliente tem “buracos”. Em vez de informar o cliente sobre o trabalho adicional que será necessário, nós ofere­ cemos menos pelo trabalho com base no escopo original e, após a adjudicação do contrato, avança­ mos com mudanças rentáveis de escopo. • Cláusulas de Penalização: Alguns contratos tém cláusulas de penalização por atraso na entrega. Ao

empurrar mudanças de escopo (talvez desnecessá­ rias) que vão alongar o cronograma, o gerente de projetos pode ser capaz de evitar uma penalização. • Apaziguar o Cliente: Alguns clientes vão solicitar mudanças de escopo “boas, mas não necessárias” após o início do contrato. Embora possa parecer bom apaziguar o cliente, sempre dizer “sim” não garante a continuação do trabalho. • Controle de Mudanças Ruim: O objetivo de um processo de controle de mudanças é evitar mu­ danças desnecessárias. Se o processo de controle de mudanças é meramente um carimbo que aprova todos os pedidos do gerente do projeto, então o scope creep irá ocorrer continuamente. A Necessidade de Conhecimento do Negócio

Mudanças de escopo devem ser devidamente dire­ cionadas antes da aprovação e da execução, e este é o elo mais fraco, porque exige conhecimento do negócio bem como conhecimento técnico. Como exemplo, mudanças de escopo nào devem ser implementadas à custa de expo­ sição ao risco de ações judiciais de responsabilidade sobre o produto ou a questões de segurança. Do mesmo modo, mudanças de escopo exclusivamente para melhorar a imagem ou a reputação devem ser evitadas, caso possam resultar em um diente descontente. Além disso, essas mu­ danças não devem ser implementadas quando o período de payback do produto é drasticamente estendido para capturar os custos de recuperação da mudança escopo. Mudanças de escopo devem basear-se numa funda­ ção sólida de negócio. Por exemplo, desenvolver um pro­ duto de alta qualidade pode parecer bom no momento, mas devem existir clientes dispostos a pagar o preço mais alto. O resultado poderia ser um produto que ninguém quer ou pode pagar. Deve existir um propósito válido de negócio para uma mudança de escopo. Isso inclui, no mínimo, os se­ guintes fatores: • Uma avaliação das necessidades do cliente e do valor adicionado que a mudança de escopo proporcionará • Uma avaliação das necessidades do mercado, in­ cluindo o tempo necessário para fazer a mudança de escopo, o período de payback, o retorno sobre o investimento, e se o preço final de venda do produ­ to será muito caro para o mercado • Uma avaliação sobre o impacto na duração do projeto e no ciclo de vida do produto • Uma avaliação da capacidade da competição de imitar a mudança de escopo

723

O FUTURO DO GERENCIAMENTO DE PROJETOS

• Adicionar flexibilidade: É possível adicionar algu­ ma flexibilidade no orçamento e no cronograma se uma grande quantidade de scope creep é espera­ da. Isso pode aparecer como uma reserva monetá­ ria de gerenciamento/contingência para questões de custo, e uma atividade de “reserva” embutida no cronograma do projeto para as questões de tempo. • Saber quem tem autoridade de assinatura: Nem todos os membros do comitê de controle de mu­ danças do escopo possuem autoridade de assina­ tura para aprovar uma mudança de escopo. Você deve saber quem possui essa autoridade.

■ Uma avaliação sobre a responsabilidade legal so­ bre o produto, associada à mudança de escopo, e do impacto na imagem da empresa Formas de minimizar o

Scope Creep

Algumas pessoas acreditam que o scope creep deve ser evitado a todo custo. Mas não permitir que o scope creep necessário ocorra pode ser perigoso e possivelmen­ te prejudicial aos objetivos de negócio. Além disso, pode ser impossível evitar o scope creep. Talvez o melhor que possamos fazer seja controlar o scope creep, minimizando sua quantidade e extensão. Algumas das atividades que podem ser úteis incluem:

• Perceber que o scope creep vai acontecer: É quase

•

•

•

•

•

•

impossível evitar o scope creep. Em vez disso, devem ser feitas tentativas para controlar o scope creep. Conhecer os requisitos: Você deve compreender plenamente os requisitos do projeto e deve se co­ municar com as partes interessadas para se certifi­ car de que vocês têm o mesmo entendimento. Conhecer as expectativas do cliente: Seu cliente e as partes interessadas podem ter expectativas que po­ dem não estar em alinhamento com a sua interpre­ tação dos requisitos no escopo. Você deve entender as expectativas, e comunicação contínua é essencial. Eliminar a noção de que o cliente tem sempre razão: Dizer “sim" constantemente para acalmar o cliente pode causar scope creep suficiente para transformar um bom projeto em um projeto com dificuldades. Algumas mudanças provavelmente poderiam ser agrupadas e realizadas mais tarde, como um projeto de melhoria. Atuar como advogado do diabo: Não considere garantido que todos os pedidos de mudança são necessários, mesmo que sejam gerados interna­ mente pela equipe do projeto. Questione a neces­ sidade de mudança. Certifique-se de que há justi­ ficativa suficiente para a mudança. Determinar o efeito da mudança: O scope creep vai afetar cronograma, custo, escopo/requisitos e re­ cursos. Veja se algumas datas de marcos podem ou não ser movidas. Algumas datas são difíceis de mo­ ver, enquanto outras são laceis. Veja se são necessá­ rios recursos adicionais para realizar a mudança de escopo e se os recursos estarão disponíveis. Obter envolvimento do usuário no início: O en­ volvimento precoce do usuário pode evitar alguns scope creeps ou pelo menos identificar as mudanças no escopo cedo o bastante de forma que os efeitos das mudanças sejam mínimos.

Conclusões

Em geral, as pessoas que pedem mudanças no escopo não estão tentando tornar sua vida miserável. É um desejo de “agradar” por meio de uma necessidade de perfeição, para adicionar funcionalidade, ou para aumentar o valor aos olhos do cliente. Algumas mudanças no escopo são ne­ cessárias por razões de negócios, como componentes para o aumento da competitividade. O scope creep é uma neces­ sidade e nào pode ser eliminado. Mas pode ser controlado. 25.4 AVALIAÇÕES DA SAÚDE DO PROJETO

Os projetos parecem progredir rapidamente até estarem 60%-70% completos. Durante esse tempo, todos come­ moram que o trabalho que está progredindo conforme planejado. Então, talvez sem aviso, a verdade vem à tona, possivelmente em virtude de um scope creep significativo, e descobrimos que o projeto está em apuros. Isso ocorre por causa de: • Nossa descrença no valor do uso correto das mé­ tricas de projeto • Seleção das métricas erradas • Nosso medo do que as avaliações da saúde do pro­ jeto possam revelar Alguns gerentes de projeto tem uma fixação incrí­ vel com métricas e números de projeto, acreditando que métricas são o “Santo Graal" para determinar o status. A maioria dos projetos parece se concentrar em apenas duas métricas: tempo e custo. Essas são as métricas pri­ márias em todos os sistemas de gerenciamento de valor agregado (GVA, ou F.VM em inglês). Embora essas duas

•

Para informações adicionais, consulte: KERZNER, H. Project checks. Disponível em: . Copyright© 2010 pelo international Institute for Learning, New York City. Reproduzido

com permissão.

iu

Gerenciamento de Projetos

métricas possam dar-lhe uma representação razoável de onde você está hoje, usar essas duas métricas para fazer previsões para o futuro são áreas “cinzentas”, e podem não indicar áreas com problemas futuros que poderiam impedir a conclusão bem-sucedida e oportuna do proje­ to. Na outra ponta do espectro, temos gerentes que não tém fé nas métricas e, portanto, se concentram na visão, na estratégia, na liderança e em orações.

Em vez de confiar apenas nas métricas, a solução mais simples poderia ser realizar avaliações da saúde pe­ riódicas sobre o projeto. Ao fazer isso, três questões críti­ cas devem ser abordadas: • Quem vai realizar a avaliação da saúde? • Os entrevistados serão honestos em suas respostas? • A gerência e partes interessadas vão reagir mal à verdade?

O surgimento de problemas até então desconhecidos ou ocultos poderia levar à perda de emprego, rebaixamen­ tos, ou cancelamento do projeto. Desta forma, avaliações da saúde do projeto oferecem uma grande oportunidade para uma ação corretiva antecipada para salvar um pro­ jeto potencial mente falho. Elas também podem descobrir oportunidades futuras. Compreendendo Avaliações da Saúde do Projeto

As pessoas tendem a usar auditorias e avaliações da saúde de forma similar. Ambas sào projetadas para ga­ rantir resultados de projeto bem-sucedidos e repetíveis, e devem ser executadas em projetos que pareçam estar se encaminhando para um resultado de sucesso, bem como naqueles que pareçam estar destinados a fracassar. Há li­ ções aprendidas e melhores práticas que podem ser desco­ bertas a partir tanto de sucessos como de fracassos. Além disso, uma análise detalhada de um projeto que pareça ser bem-sucedido no momento pode trazer à tona questões que mostrem que o projeto está, na verdade, em apuros.

A Tabela 25-3 mostra algumas das diferenças entre auditorias e avaliações da saúde. Embora algumas das di­ ferenças possam ser sutis, vamos focar nossa atenção nas avaliações da saúde. Durante uma reunião da equipe, o gerente de pro­ jetos pergunta à equipe: “Como o trabalho está progre­ dindo?” A resposta é: “Estamos indo razoavelmente bem. Estamos apenas um pouco acima do orçamento e um pouco atrasados, mas achamos que resolveremos esses dois problemas usando recursos com salários mais bai­ xos para o próximo mês e pedindo que trabalhem horas extras. De acordo com a nossa metodologia empresarial de gerenciamento de projetos, nosso custo desfavorável e

as variações no cronograma ainda estão dentro do valor limite e a geração de um relatório de exceção para a ge­ rência não é necessário. O cliente deve ficar satisfeito com nossos resultados até agora”. TABELA 25-3

Auditorias versus exames de saúde

Variável

Auditoria

Exames de Saúde

Foco

Mo presente

No futuro

Intenção

Concordância

Eficócio da execução e entregas

Timing

Gerdmente oçerájdo e pouco frequente

Gerdmente não agendado e sob demando

Itens o serem buscados

Melwes práticas

Probemas escondidos, possrvehente destrutiws e pcs$áet> arras

Fntrevtstodrx

Gerdmente dguém interno

Consüta externo

Como a entevTSto e conduzido

Comtodoohme

Sessões individuais

Piazo

Curto prazo

Longo prazo

Profundidade do cnolrse

Sumário

Revtsao forense

Estes comentários são representativos de uma equipe de projeto que falhou em reconhecer o verdadeiro status do projeto porque estão muito envolvidos nas atividades diárias do projeto. Da mesma forma, temos gerentes de projetos, patrocinadores e executivos que estão envolvi­ dos em suas próprias atividades diárias e prontamente aceitam esses comentários com uma fé cega, deixando de ver o quadro geral. Se uma auditoria tivesse sido realiza­ da, a conclusão poderia ter sido a mesma, ou seja, que o projeto está seguindo a metodologia EPM com sucesso e que as métricas de tempo o custo estão dentro dos limites aceitáveis. Uma avaliação forense da saúde do projeto, por outro lado, poderia revelar a gravidade dos problemas.

Apenas o fato de que um projeto está dentro do tem­ po e/ou dentro do orçamento alocado nào é garantia de sucesso. O resultado final pode ser uma entrega de má qua­ lidade, de forma que seja inaceitável para o cliente. Além do tempo e custo, a saúde do projeto verifica o foco na qua­ lidade, recursos, benefícios e requisitos, apenas para citar alguns. A verdadeira medida do sucesso futuro do projeto c o valor que os clientes veem em sua conclusão. Avaliações da saúde devem, portanto, ser focadas no valor. Auditorias, por outro lado, geralmente não focam sobre o valor. As avaliações da saúde podem funcionar como uma ferramenta permanente, e serem realizados de forma aleató­ ria quando necessário, ou periodicamente ao longo das vá­ rias fases do delo de vida. No entanto, existem circunstâncias específicas que indicam que uma avaliação da saúde deve ser realizada rapidamente. Essas circunstâncias incluem:

725

O FUTURO DO GERENCIAMENTO DE PROJETOS

■ Scope creep significativo ■ Custos crescentes acompanhados por uma dete­ rioração no valor e nos benefícios • Derrapagens no cronograma que não possam ser corrigidas • Prazos não atendidos • Baixo moral acompanhado por mudanças em pes­ soas chave do projeto

ou por consultores externos. O risco de utilizar pessoal in­ terno é que eles podem ter lealdade ou relacionamento com pessoas da equipe do projeto e, portanto, não podem não ser totalmente honestos em determinar o verdadeiro status do projeto ou em decidir de quem foi a culpa.

Avaliações da saúde periódicas, se feitas corretamen­ te, eliminam a ambiguidade, de forma que o estado real pode ser determinado. Os benefícios das avaliações da saúde incluem:

• Uma infinidade de formulários, diretrizes, mode­ los e listas de verificação usadas em outras empre­ sas e em projetos semelhantes • A promessa de imparcialidade e confidencialidade • Um foco apenas nos fatos e esperançosamente li­ vres de política • Um ambiente no qual as pessoas podem falar li­ vremente e desabafar seus sentimentos pessoais • Um ambiente que relativamente livre de outros problemas do dia a dia

• Determinar do status atual do projeto • Identificar os problemas com antecedência sufi­ ciente para que exista tempo hábil para a tomada de ações corretivas • Identificar os fatores críticos de sucesso que irão apoiar um resultado bem-sucedido, ou os pro­ blemas críticos que podem impedir uma entrega bem-sucedida • Identificar as lições aprendidas, melhores práticas e fatores críticos de sucesso que podem ser utiliza­ dos em projetos futuros • Avaliação da conformidade com e melhorias para a metodologia EPM • Identificar quais atividades podem exigir ou se be­ neficiar com recursos adicionais • Identificar riscos presentes e futuros bem como possíveis estratégias de mitigação de risco • Determinar se os benefícios e o valor vão estar pre­ sentes na conclusão • Determinar se a eutanásia é necessária para tirar o projeto de sua situação • O desenvolvimento ou recomendação de um pla­ no de correção Há equívocos sobre as avaliações da saúde do proje­ to. Alguns deles são:

• A pessoa que faz a avaliação da saúde nào entende do projeto ou da cultura corporativa, desperdiçan­ do tempo desta forma. • A avaliação da saúde é muito cara para o valor que iremos receber por realizá-la. • A avaliação da saúde retém recursos críticos em entrevistas. • No momento que obtemos os resultados da avalia­ ção da saúde, ou é tarde demais para fazer mudan­ ças ou a natureza do projeto pode ter mudado. Quem Executa as Avaliações da Saúde?

Um dos desafios que as empresas enfrentam é saber se a avaliação da saúde deve ser realizada por equipes internas

Usar consultores ou facilitadores externos é, muitas vezes, a melhor escolha. Facilitadores externos podem trazer à mesa:

Fases do Ciclo de Vida da Avaliação da Saúde

Existem três fases do ciclo de vida para avaliações da saúde de projeto: • Revisão do business case e história do projeto • Pesquisa e descoberta dos fatos • Preparação do relatório da avaliação da saúde Rever o business case e a história do projeto pode exigir que o líder da avaliação da saúde tenha acesso a conhecimento proprietário de informações financeiras. O líder pode ter de assinar acordos de confidencialidade e também cláusulas de “nào competição" antes de serem autorizados a realizar a avaliação da saúde.

Na fase de investigação e descoberta, o líder prepara uma lista de perguntas que precisam ser respondidas. A lista pode ser preparada a partir das áreas de domínio ou áreas de conhecimento do Guia PMBOK®. As perguntas também podem vir do repositório de conhecimento da empresa de consultoria e podem se apresentar na forma de modelos, diretrizes, listas de verificação, ou formulá­ rios. As perguntas podem mudar de projeto para projeto e de setor para setor.

Algumas das áreas críticas que devem ser investiga­ dos incluem: • • • • • • •

Desempenho contra as linhas de base Capacidade de cumprir as previsões Benefícios e análises de valor Governança O envolvimento das partes interessadas Mitigação de risco Planos de contingência

726

Gerenciamento de Projetos

Se a avaliação da saúde requer entrevistas individu­ ais, o líder deve ser capaz de extrair a verdade dos entre­ vistados que tém diferentes interpretações ou conclusões sobre o status do projeto. Algumas pessoas vão dizer a verdade, enquanto outras ou vão falar o que acreditam que o entrevistador quer ouvir, ou vão distorcer a verdade como um meio de autoproteção.

A fase final é a elaboração do relatório. Isto deve incluir: • Uma lista dos problemas • Análises de causa raiz, possivelmente incluin­ do a identificação dos indivíduos que criaram os problemas • Análise de lacunas • Oportunidades de ação corretiva • Um plano de get-well ou fix-it

Avaliações da saúde do projeto não são atividades de Big Brother. Em vez disso, são parte da supervisão do projeto. Sem essas avaliações da saúde, as chances de fra­ casso do projeto são significativamente aumentadas. Elas também nos fornecem uma visão sobre como manter os riscos sob controle e realizar avaliações da saúde e tomar medidas corretivas precoces é certamente melhor do que ter de gerenciar um projeto em crise. 25.5

GERENCIANDO PROJETOS PROBLEMÁTICOS

Os times esportivos profissionais tratam cada nova tem­ porada como um projeto. Para alguns times, a única de­ finição de sucesso é vencer campeonatos, enquanto para outros, sucesso significa uma boa temporada. Nem todos os times podem vencer todos os campeonatos, mas uma temporada com um balanço positivo está ao alcance. Ao final da temporada, talvez metade das equipes terá ganhado mais jogos do que perdido. Mas, para a metade que perdeu, a temporada (ou seja, o projeto) terá sido um fracasso. Quando uma falha de projeto ocorre em esportes profissionais, os gestores e técnicos são demitidos, há um abalo na liderança executiva, al­ guns jogadores são negociados ou vendidos para outras equipes, e novos jogadores são trazidos a bordo. Essas mesmas táticas são usadas para recuperar projetos que falham na indústria. Há alguns fatos gerais sobre projetos problemáticos:

Para obter informações adicionais, consulte: KERZNER, H. Managing scope creep. Disponível em: . Copyright © 2010 pelo International Institute for Learning, New York City. Reproduzido com permissão.

• Alguns projetos estão fadados ao fracasso, inde­ pendentemente das tentativas de recuperação • As chances de falha em um determinado projeto podem ser maiores do que as chances de sucesso • A falha pode ocorrer em qualquer fase do ciclo de vida, o sucesso ocorre no final do projeto • Projetos problemáticos não vão do “verde” ao “vermelho” de uma hora para outra • Há sinais de alerta, mas eles, muitas vezes, sào ne­ gligenciados ou mal compreendidos • A maioria das empresas tem uma má compreensão de como gerenciar projetos problemáticos • Nem todos os gerentes de projeto possuem as ha­ bilidades necessárias para gerenciar um projeto problemático Nem todos os projetos serão bem-sucedidos. As em­ presas que tém um alto grau de sucesso de projetos pro­ vavelmente não estão trabalhando em projetos suficientes e certamente não estão assumindo muitos riscos. Esses ti­ pos de empresas, consequentemente, tornam-se seguidoras ao invés de líderes. Para as empresas que desejam ser líderes, o conhecimento sobre como reverter um projeto que está fracassando ou problemático é essencial.

Projetos não se metem em problemas do dia para a noite. Há sinais precoces de alerta, mas a maioria das empresas parece negligenciá-los ou nào compreendê-los. Algumas empresas simplesmente ignoram os sinais de alerta e continuam esperando por um milagre. Falhar em reconhecer esses sinais precoces pode tornar o custo de correções subsequentes um esforço muito caro. Além dis­ so, quanto mais tempo vocé esperar para fazer correções, mais caras as mudanças se tornam. Algumas empresas realizam avaliações de saúde pe­ riódicos do projeto. Essas avaliações de saúde, mesmo quando aplicadas a projetos com aparência saudável, po­ dem levar à descoberta de que o projeto está em apuros, mesmo que, superficialmente, pareça saudável. Consulto­ res externos muitas vezes são contratados para as avalia­ ções de saúde, a fim de obter-se uma avaliação imparcial. O consultor raramente assume o controle do projeto uma vez que a avaliação é concluída, mas pode fazer recomen­ dações para a recuperação.

Quando um projeto sai dos trilhos, o custo de re­ cuperação é enorme e muitos, ou mesmo novos, recur­ sos podem ser necessários para as correções. O objetivo final da recuperação não é mais terminar o projeto a tempo, mas terminar com benefícios e valor razoáveis para o cliente e as partes interessadas. Os requisitos do projeto podem mudar durante a recuperação para atender às novas metas, caso elas tenham mudado. Mas,

727

O FUTURO DO GERENCIAMENTO DE PROJETOS

independentemente do que é feito, nem todos os proje­ tos problemáticos podem ser recuperados. Causas Raiz do Fracasso

Existem várias causas de fracasso do projeto. Algumas causas são bastante comuns em setores específicos, como tecnologia da informação, enquanto outras podem aparecer em todos os setores. Segue a seguir uma lista ge­ nérica de causas comuns de falha:

• Partes interessadas do usuário final não envolvidas ao longo do projeto • Apoio mínimo ou nenhum apoio das partes inte­ ressadas, falta de propriedade • Plano de negócios fraco • Metas corporativas não compreendidas nos níveis organizacionais mais baixos • O plano requer muito em muito pouco tempo • Estimativas ruins, especial mente as financeiras • Requisitos das partes interessadas pouco claros • Envolvimento passivo das partes interessadas do usuário após o handoff • Expectativas pouco claras • Premissas não realistas, caso existam • Planos baseados em dados insuficientes • Falta desistematizaçãodoprocessodeplanejamento • O planejamento é realizado por um grupo de planejamento • Requisitos inadequados ou incompletos • Falta de recursos • Falta de experiência dos recursos designados • Os requisitos de pessoal não são totalmente co­ nhecidos • Constante mudança de recursos • Planejamento global do projeto ruim • Mudanças nos fatores ambientais da empresa causando escopo desatualizado • Prazos não atendidos e nenhum plano de recu­ peração • Orçamentos excedidos e fora de controle • Falta de replanejamento em base regular • Falta de atenção dada aos aspectos humanos e or­ ganizacionais do projeto • Estimativas do projeto são apostas e não baseadas em histórico ou padrões • Tempo insuficiente para estimativa adequada • Não se sabe quais são as datas exatas do marco principal ou datas de entrega de relatórios • Membros da equipe trabalhando em requisitos conflitantes • As pessoas são empurradas para dentro e para fora do projeto com pouca atenção para o cronograma

• Controle de custos ruim ou fragmentado • Cada parte interessada usa diferentes ativos de processos organizacionais, que podem ser incom­ patíveis com os ativos dos parceiros do projeto • Comunicação fraca do projeto com as partes interessadas • Má avaliação dos riscos, caso tenha sido feita • Tipo errado de contrato • Má gestão do projeto; membros da equipe pos­ suem uma má compreensão de gerenciamento de projetos, especialmente os membros de equipe virtuais • Os objetivos técnicos são mais importantes que os objetivos de negócios Essas causas de fracasso do projeto podem ser classi­ ficadas em três grandes categorias:

• Erros de gerenciamento: Estes ocorrem em virtude de falhas no gerenciamento das partes interessadas, talvez por permitir muitas mudanças de escopo desnecessárias, por falha em fornecer governança adequada, recusar-se a tomar decisões em tempo hábil, e por ignorar os pedidos de ajuda do gerente de projetos. Podem ser também o resultado de que­ rer “enfeitar” o projeto. Também são o resultado de não realizar exames de saüde do projeto. • Erros de planejamento: Estes são o resultado de má gestão do projeto, talvez por não seguir os princípios enunciados no Guia PMBOK®, não ter um “botão de emergência" oportuno no plano, não planejar auditorias de projeto ou exames de saúde, e não selecionar as métricas de acompanha­ mento adequadas. • Influências externas: Normalmente sào falhas em avaliar corretamente os fatores ambientais de en­ trada. Isto inclui o tempo para obter aprovações e autorizações de terceiros e uma má compreensão da cultura e da política do país sede Definição de Fracasso

Historicamente, a definição de sucesso em um pro­ jeto era realizar o trabalho dentro das restrições triplas e obter a aceitação do cliente. Hoje, as restrições triplas ainda são importantes, mas têm tido um papel coadju­ vante para os negócios e componentes de valor de suces­ so. Na definição de hoje, o sucesso ocorre quando o valor de negócio planejado é alcançado dentro das restrições e premissas impostas, e o cliente recebe o valor desejado. Embora pareçamos ter uma compreensão razoavel­ mente boa do sucesso do projeto, temos uma compre­ ensão medíocre sobre o fracasso do projeto. O gerente do projeto e as partes interessadas podem ter diferentes

728

Gerenciamento de Projetos

definições de fracasso do projeto. A definição do geren­ te de projetos pode ser simplesmente não satisfazer as restrições triplas ou concorrentes. As partes interessadas , por outro lado, parecem mais preocupadas com o va­ lor de negócio do que com as restrições triplas ou con­ correntes, uma vez que o projeto começa realmente. A percepção de fracasso das partes interessadas pode ser:

• O projeto tornou-se demasiadamente caro para os benefícios ou valor esperado. • O projeto será concluído muito tarde. • O projeto não vai atingir os benefícios esperados ou valor. • O projeto já nào satisfaz as necessidades das partes interessadas.

• Surpresas, identificação lenta de problemas, e re­ trabalho constante • Processo de controle de mudanças medíocre

Quanto mais cedo os sinais de alerta são descober­ tos, mais oportunidades existem para a recuperação. Este é o momento em que um exame de saúde do projeto deve ser conduzido. A identificação bem-sucedida e avaliação dos sinais de alerta podem nos dizer se o projeto: • Pode ter sucesso de acordo com os requisitos originais, mas algumas pequenas mudanças sào necessárias • Pode ser reparado, mas grandes mudanças podem ser necessárias • Não pode ter sucesso e deve ser terminado

Sinais de Alerta de Problemas

Os projetos não se tornam problemáticos do dia para a noite. Eles normalmente passam pelo “verde”, pelo “amarelo" e pelo “vermelho", e ao longo do caminho há sinais de alerta de que a falha pode ser iminente, ou de que mudanças imediatas podem ser necessárias. Sinais de alerta típicos incluem:

• Deterioração do plano de negócios • Opiniões diferentes sobre o propósito do projeto e objetivos • Partes interessadas e membros do comitê de orien­ tação descontentes/ desinteressados • Crítica contínua das partes interessadas • Alterações nas partes interessadas sem qualquer aviso • Já não há mais demanda para as entregas ou produto • Patrocínio invisível • Decisões atrasadas, resultando em perda de prazos • Reuniões de alta tensão com a equipe e as partes interessadas • Apontar culpados ou má aceitação de responsabilidade • Falta de ativos de processos organizacionais • Falhar em fechar as fases do ciclo de vida apro­ priadamente • Alta rotatividade de pessoal, em especial de traba­ lhadores críticos • Expectativas irreais • Falhar em reportar progresso • Falhas técnicas • Ter de trabalhar horas excessivas e com cargas pe­ sadas de trabalho • Marcos e outros requisitos pouco claros • Baixo moral • Tudo é uma crise • Baixa presença nas reuniões de equipe

Há três resultados possíveis no gerenciamento de um projeto problemático:

• O projeto deve ser concluído, ou seja, exigido por lei. • O projeto pode ser concluído, mas com grandes e custosas mudanças nos requisitos. • O projeto deveria ser cancelado: • Custos e benefícios ou valor nào estão mais alinhados. ■ O que antes era uma boa ideia já não tem mais qualquer mérito. Alguns projetos nào podem ser cancelados, porque sào exigidos por lei. Estes incluem o cumprimento com leis do governo sobre questões ambientais, de saúde, segurança e poluiçào. Para esses projetos, o fracasso nào é uma opçào. A decisào mais difícil de fazer é, obviamente, “apertar o botão de emergência" e cancelar o projeto. As empresas que têm um bom domínio sobre gerenciamento de proje­ tos estabelecem processos para tornar mais fácil matar um projeto que nào pode ser salvo. Muitas vezes existe uma grande dose de resistência política e cultural para matar um projeto. O gerenciamento de partes interessadas e a governança de projeto desempenham um sério papel na facilidade com a qual um projeto pode ser encerrado. Selecionando o Gerente de Recuperação de Projeto (GRP)

As empresas muitas vezes contratam consultores ex­ ternos para realizar um exame de saúde no projeto. Se o relatório indicar que deve ser feita uma tentativa para recuperar o projeto problemático, então talvez um novo gerente de projeto, com competências em recuperação de projetos, deva ser introduzido. Consultores externos normalmente nào assumem projetos problemáticos por­ que podem nào ter uma boa compreensão da cultura da

729

O FUTURO DO GERENCIAMENTO DE PROJETOS

empresa, do negócio e dos processos de gerenciamento de projetos, da política e das relações de trabalho dos empregados. Nem todos os gerentes de projeto possuem as habilidades necessárias para ser um GRP eficaz. Além de possuir conhecimentos de gerenciamento de projetos, habilidades típicas necessárias incluem: • Forte coragem política forte e experiência política • Vontade de ser totalmente honesto ao atacar e re­ latar as questões críticas • enacidade para ter sucesso, mesmo que isso exija uma mudança nos recursos • empreender que uma recuperação eficaz é baseada em informações, não em emoções • Capacidade de lidar com o estresse, pessoalmente e com a equipe

Recuperar um projeto problemático é como ganhar na “Série Mundial de Pôquer”. Além de ter as competências adequadas, também é necessário possuir certa dose de sorte. Assumir um projeto problemático não é o mesmo que iniciar um novo projeto. Gerentes de recuperação de proje­ to devem ter uma boa compreensão do que estão prestes a herdar, incluindo altos níveis de estresse. Isso inclui:

• • • •

• Forem contratados consultores que não podem ajudar ou que piorem a situação levando muito tempo para compreender as questões Fases do Gelo de Vida da Recuperação

A metodologia EPM existente de uma empresa pode nào ser capaz de ajudar a recuperar um projeto proble­ mático. Afinal de contas, a metodologia EPM padrão da empresa, que pode não ter sido apropriada para esse pro­ jeto, pode ter sido um dos fatores que contribuiu para o declínio do projeto. É um erro acreditar que qualquer metodologia é a cura milagrosa. Os projetos são gerencia­ dos por pessoas, não por ferramentas ou metodologias. Para que o projeto de recuperação tenha sucesso pode ser necessário aplicar uma abordagem diferente.

z\ Figura 25-3 mostra as fases típicas do ciclo de vida de um projeto de recuperação. Essas fases podem dife­ rir significativamente das fases do ciclo de vida padrão da metodologia da empresa. As primeiras quatro fases da Figura 25-3 sào utilizadas para aferição do problema, avaliar e esperançosamente verificar que talvez o proje­ to possa ser salvo. As duas últimas fases sào aquelas nas quais realmente a recuperação ocorre.

Uma equipe queimada Uma equipe emocional mente esgotada Moral baixo Êxodo dos membros talentosos da equipe que

sempre têm alta demanda em outros lugares • Um time que pode ter falta de fé no processo de recuperação • Clientes furiosos • Administradores nervosos • Patrocínio e governança invisíveis • Partes interessadas ou invisíveis ou altamente ativas Os gerentes de projetos que não entendem o que está envolvido na recuperação de um projeto problemá­ tico podem piorar a situação esperando por um milagre, e permitindo que a “espiral da morte” continue até um ponto em que a recuperação não seja mais possível. A es­ piral de morte continua se:

• Funcionários são forçados a trabalhar horas exces­ sivas desnecessariamente • For criado trabalho adicional desnecessário • Os membros da equipe são substituídos em um momento inadequado • O estresse e a pressão da equipe são aumentados sem entender as ramificações ■ Forem buscadas novas ferramentas “miraculosas” para resolver alguns dos problemas

FIGURA 25-3 Foses do ciclo do vido do rocuperoçõo.

Fase de Compreensão

O objetivo da fase de compreensão é que o GRP recém-designado revise o projeto e sua história. Para fazer isso, o GRP irá precisar de algum tipo de ordem ou ter­ mo de abertura, que pode ser diferente daquele do seu antecessor. Isto deve ser feito tào rápido quanto possível, porque o tempo é uma restrição, em vez de um luxo. Per­ guntas típicas que podem ser tratadas no termo incluem: • Que autoridade você terá para acessar informa­ ções proprietárias ou confidenciais? Isso inclui informações que podem nào ter estado disponíveis para o seu antecessor, tais como acor­ dos contratuais e os salários reais. • Que tipo de apoio será dado pelo patrocinador e pelas partes interessadas? Há indícios de que eles vão aceitar menos do que um desempenho ótimo e uma redução de escopo dos requisitos originais? • Você terá permissão para entrevistar os membros da equipe em confidencialidade?

730

Gerenciamento de Projetos

• As partes interessadas vão reagir exageradamente a descobertas brutalmente honestas, mesmo que os problemas tenham sido causados pelas partes interessadas e grupos de governança? Nesta fase, inclui-se o seguinte:

• Compreender a história do projeto • Rever o plano de negócios, os benefícios esperados e o valor alvo • Rever os objetivos do projeto • Rever as premissas do projeto • Familiarizar-se com as partes interessadas, suas necessidades e sensibilidades • Verificar se os fatores ambientais da empresa e ati­ vos de processos organizacionais ainda são válidos Fase de Auditoria

Agora que temos uma compreensão da história do pro­ jeto, entramos na fase de auditoria, que é uma avaliação crí­ tica do estado atual do projeto. F. parte da fase de auditoria:

Avaliar o desempenho real até a data Identificar as falhas Executar uma análise de causa raiz Procurar por pontos de falha superficiais (ou fá­ ceis de identificar) • Procurar pontos de falha ocultos • Determinar quais são as atividades ou entregas “obrigatórias”, “desejáveis”, “que podem esperar”, e “não necessárias" • Olhar para o registro de problemas e verificar se as questões são relativas a pessoas. Se houver proble­ mas de pessoas, as pessoas podem ser removidas ou substituídas? • • • •

A fase de auditoria também inclui a validação de que os objetivos ainda estão corretos, os benefícios e o valor podem ser atendidos, mas talvez em menor grau, os re­ cursos alocados possuem as competências adequadas, os papéis e responsabilidades estão atribuídos aos membros de equipe corretos, a prioridade do projeto está correta e irá apoiar os esforços de recuperação, e o apoio executivo está estabelecido. A recuperação de um projeto proble­ mático não pode ser feita isoladamente. Ela exige uma equipe de recuperação e forte apoio/patrocínio. O "timing? e a qualidade do suporte executivo ne­ cessário para a recuperação são mais comumente base­ ados na percepção do valor do projeto. Cinco questões importantes que precisam ser consideradas como parte da determinação do valor são:

• O projeto ainda é de valor para o cliente? • O projeto ainda está alinhado aos objetivos e estra­ tégia corporativa da sua empresa?

• Sua empresa está ainda comprometida com o projeto? • As partes interessadas ainda estão comprometidas? • Há motivação geral para o resgate?

Uma vez que a recuperação não pode ser realizada de forma isolada, é importante entrevistar os membros da equipe como parte da fase de auditoria. Isso pode muito bem ser realizado no início da fase de auditoria para res­ ponder às perguntas anteriores. Os membros da equipe podem ter opiniões fortes sobre o que deu errado, bem como boas idéias para uma recuperação rápida e bem-sucedida. Vocé deve obter o apoio da equipe se a recupe­ ração é para ser bem-sucedida. Isto inclui: • Analisar a cultura • Coleta de dados e avaliação envolvendo a equipe toda • Facilitar para a equipe a discussão dos problemas sem apontar o dedo ou atribuir culpa • Entrevistar os membros da equipe, talvez de um a um • Reestabelecer o equilíbrio trabalho-vida • Reestabelecer os incentivos, se possível Pode ser difícil entrevistar pessoas e obter sua opi­ nião sobre o ponto onde estamos, o que deu errado e como corrigir isso. Isto é especialmente verdadeiro se as pessoas têm agendas escondidas. Se você tem amigos próximos associados ao projeto, como vocé vai reagir se forem considerados culpados por ser parte do problema? Isto é conhecido como custo emocional.

Outro problema é que as pessoas podem querer es­ conder informações críticas, se alguma coisa deu errado e puderem ser identificadas com isso. Elas podem ver a verdade como algo impactante para suas chances de progressão na carreira. Você pode precisar de uma lista abrangente de perguntas a fazer para extrair as informa­ ções corretas.

Quando um projeto está com problemas, as pessoas tendem a fazer o “Jogo da Culpa”, tentando fazer parecer que alguém está em falta. Esta pode ser uma tentativa de turvar a água e desviar o entrevistador das questões reais. Isso é feito como parte de um senso de autopreservação. Pode ser difícil decidir quem está falando a verdade e quem está fabricando informações. Você pode concluir que certas pessoas devem ser re­ tiradas do projeto se for para ter alguma chance de recu­ peração. Independentemente do que fizeram, vocé deve permitir que saiam do projeto com dignidade. Você pode dizer, “Annie está sendo transferida para outro projeto que precisa de suas habilidades. Agradecemos a ela pela valiosa contribuição que deu a este projeto”.

731

O FUTURO DO GERENCIAMENTO DE PROJETOS

Talvez a pior situação seja quando vocé descobre que os verdadeiros problemas eram com a governança do projeto. Dizer às partes interessadas e aos grupos de governança que eles foram parte do problema pode não ser bem recebido. A preferência do autor é sempre ser ho­ nesto em definir os problemas, mesmo que isso doa. Essa resposta deve ser tratada com tato e diplomacia. Você também deve avaliar o moral da equipe. Isto inclui:

• Olhar para as coisas boas primeiro para levantar o moral • Determinar se o plano original era excessivamente ambicioso • Determinar se houve problemas políticos que le­ varam à resistência ativa ou passiva da equipe • Determinar se as horas de trabalho e as cargas de trabalho foram desmoralizantes

MM

Ato

5na

Grito Aáomto oo (khtobdho

Fase de Compensação

Neste ponto, esperemos que você tenha as informações necessárias para a tomada de decisão, bem como o apoio da equipe para a recuperação. Pode ser altamente improvável que os requisitos originais ainda possam ser satisfeitos sem algumas importantes compensações. Você deve agora tra­ balhar com a equipe para determinar as opções de compen­ sação que vai apresentar para as partes interessadas.

Quando o projeto começou, muito provavelmente, as restrições eram as triplas tradicionais. Tempo, custo e escopo eram as principais restrições e compensações teriam sido feitas sobre as restrições secundárias de qua­ lidade, risco, valor e imagem/reputação. Quando um projeto se torna problemático, as partes interessadas sa­ bem que o orçamento e cronograma original podem não mais ser válidos. O projeto pode demorar mais tempo e pode custar muito mais dinheiro do que se pensava ini­ cialmente. Dessa forma, as principais preocupações para as partes interessadas quanto à possibilidade de continu­ ar apoiando ou não o projeto podem mudar para valor, qualidade e imagem/reputação. As compensações que a equipe vai apresentar para o cliente e partes interessadas serão, então, compensações em tempo, custo, escopo e, possivelmente, risco. Uma maneira de olhar para as compensações é rever a EAP detalhada e identificar todas as atividades restantes a serem realizadas. As atividades são então colocadas na grade da Figura 25-4. Os pacotes de trabalho ou produtos “obrigatórios” e “desejáveis” sào geral mente os mais caros e mats difíceis de ser usados nas compensações. Se os for­ necedores sào obrigados a fornecer suporte a pacotes de trabalho, entào também devemos realizar compensações de fornecedores, que incluem:

FIGURA 25-4 Opções de compensoçõo.

• Avaliar os acordos contratuais de fornecedores • Determinar se o fornecedor pode resolver os problemas • Determinar se concessões e compensações de for­ necedores sào possíveis • Estabelecer novos cronogramas e preços de fornecedores Uma vez que todos os elementos sào colocados na grade da Figura 25-4, a equipe irá ajudar o GRP com as compensações, respondendo às seguintes perguntas: • • • • • • • •

Onde estào as compensações? Quais são as casualidades esperadas? O que pode e o que nào pode ser feito? O que deve ser corrigido primeiro? Podemos parar o sangramento? As prioridades das restrições mudaram? As funcionalidades mudaram? Quais sào os riscos?

Uma vez que as compensações foram descobertas, o GRP e a equipe devem preparar uma apresentação para as partes interessadas. Há duas questões principais que o GRP terá de discutir com as partes interessadas: • Vale a pena salvar o projeto? Se nào valer a pena salvar o projeto, entào você deve ter coragem de dizer isso. A menos que exista uma razão de negó­ cio válida para a continuação, você deve recomen­ dar o cancelamento. • Se valer a pena salvar o projeto, podemos esperar uma recuperação completa ou parcial, e quando?

732

Gerenciamento de Projetos

Há também outros fatores que provavelmente são preocupações das partes interessadas e devem ser abor­ dadas. Estes fatores incluem:

• Modificação de Escopo: Continue o trabalho mas com modificações conforme necessário.

Mudanças no ambiente político Processos judiciais existentes ou potenciais Mudanças nos fatores ambientais da empresa Mudanças nos ativos de processos organizacionais Mudanças no business case Mudanças nas premissas Mudanças nos benefícios esperados e no valor final

Albert Einstein disse uma vez: “Nào podemos resol­ ver problemas usando o mesmo tipo de pensamento que usamos quando os criamos”. Pode ser necessário trazer a bordo novas pessoas com novas idéias. No entanto, existem riscos. Você pode querer essas pessoas em tempo integral no projeto, mas pode ser dificil manter trabalha­ dores altamente qualificados que podem estar com altas demandas em outros lugares. Já que seu projeto provavel­ mente vai escorregar, alguns dos membros de sua equipe podem estar comprometidos com outros projetos prestes a começar. No entanto, você pode ter a sorte de ter um forte patrocínio em nível executivo e reter essas pessoas. Isso poderia permitir que você usasse uma organização de equipe coalocada.

• • • • • • •

Fase de Negociação

Neste ponto, o GRP está pronto para negociações com as partes interessadas. Os itens que devem ser abor­ dados como parte das negociações com as partes interes­ sadas incluem: • Itens importantes para as partes interessadas (por exemplo, tempo, custo, valor) • Priorizaçào das compensações • Honestidade em suas crenças para a recuperação • Nào fornecer expectativas irreais • Obter seu aval • Negociar o patrocínio necessário e apoio das par­ tes interessadas Fase de Reinicio

Considerando que as partes interessadas concor­ daram com o processo de recuperação, agora você está pronto para reiniciar o projeto. Isto inclui: • instruir a equipe sobre as negociações com as par­ tes interessadas • Garantir que a equipe aprenda com os erros do passado • Apresentar à equipe o plano de recuperação acorda­ do com as partes interessadas, incluindo os marcos • Identificar qualquer alteração à forma como o projeto será gerenciado • Engajar totalmente o patrocinador do projeto bem como as principais partes interessadas por seu apoio • Identificar qualquer alteração nos papéis e respon­ sabilidades dos membros da equipe Há três opções de para o reinicio:

• Totalmente Anestésica: Conduza todo o trabalho a uma paralisação até que o plano de recuperação seja finalizado. • Parcial mente Anestésica: Conduza parte do tra­ balho a uma paralisação até que o escopo esteja estabilizado.

Fase de Execução

Durante a fase de execução, o gerente de projetos deve se concentrar em determinados fatores de imple­ mentação de “retorno ao trabalho”. Esses fatores incluem:

• Aprender com os erros do passado • Estabilizar o escopo • Aplicar rigidamente o processo de controle dc mu­ dança de escopo • Realizar periodicamente exames críticos de saúde, usando relatórios de medição de valor agregado • Prover comunicação eficaz e essencial • Manter o moral positivo • Adotar gerenciamento proativo das partes interessadas • Não confiar ou esperar que o sistema EPM da em­ presa o salve • Não permitir a intervenções indesejadas das partes interessadas, o que aumenta a pressão • Gerenciar cuidadosamente as expectativas das partes interessadas • Isolar a equipe da política

Gerenciar projetos de recuperação nào é fácil, e nào há nenhuma garantia de que vocé pode ou irá obter su­ cesso. Você estará sob estreita supervisão e inspeção por parte de superiores e partes interessadas. Você pode até mesmo ser solicitado a explicar todas suas ações. Mas para salvar do desastre um projeto potencial mente pro­ blemático certamente vale o esforço adicional.

A ASCENSAO, QUEDA E RESSURREIÇÃO DO IRIDIUM: Uma Perspectiva do Gerenciamento de Projetos

26.0

INTRODUÇÃO

O que parece agora é um projeto científico de vários bilhões de dólares. Existem problemas fundamentais: o dispositivo de mào é grande, o serviço é caro e os clientes não foram realmente identificados.

O Projeto Iridium foi concebido para criar um sistema wireless™ mundial de telefone celular handheld™ com capacidade de se comunicar em qualquer lugar do mun­ do a qualquer momento. Os executivos da Motorola con­ sideravam o projeto a oitava maravilha do mundo. Mas, após mais de uma década, e depois do investimento de bilhões de dólares, o Iridium resolveu um problema que poucos clientes precisavam que fosse resolvido. O que deu errado? Como o projeto Iridium se transformou de uma maravilha de vanguarda técnica a um erro de vários bilhões de dólares? A potencial catástrofe poderia ter sido evitada?* 1

Kn Termo que designa a transferência de informações à distância sem a utilização de fios e cabos elétricos. Kn Termo atribuído aos dispositivos portáteis. 1 Parte do material foi adaptado de: FINKELSTEIN, Sydney, SANFORD, Shade H. I.earning from Corporate Mistakes: The Rise and Fall of Iridium. Organizational Dyantics, v. 29, n. 2, p. 138-148,2000. © 2000 por Elsevier Sciences, Inc. Reproduzido com permissão.

Chris Chaney, Analista, A. G. Edwards, 1999 Nunca houve um business case para o Iridium. Nunca houve demanda de mercado. A decisão de construir o Iridium nào foi uma decisão ra­ cional de negócios. Foi mais uma decisão reli­ giosa. O notável é que isso aconteceu em uma grande corporação e que não havia um proces­ so racional de tomada de decisões em vigor para puxar o plugue. A tecnologia pela tecnologia nào pode ser um bom business case.2 Herschel-Shosteck Consultor de Telecomunicações

2

PATERIK, Stephanie. Iridium Alive and Well. The Arizona Re public, p. D5,27 abr. 2005.

734

Gerenciamento de Projetos

O Iridium provavelmente será um dos detritos espaciais mais caros de todos os tempos. William Kidd, Analista, C.E. Lnterberg, Towbin (agora parte da Collins Stewart pic)

Em 1985, Bary Bertiger, engenheiro-chefe da divi­ são estratégica de eletrônicos da Motorola, e sua espo­ sa, Karen, estavam de férias nas Bahamas. Karen ten­ tou sem sucesso fazer uma chamada telefônica celular para sua casa, perto das instalações da Motorola em Chandler, Arizona, para fechar uma transação imobili­ ária. Sem êxito, ela perguntou ao marido por que não era possível criar um sistema de telefone que funcionasse em qualquer lugar do mundo, mesmo em locais remotos.

Nesse momento, a tecnologia celular estava em sua infância, mas era esperado que crescesse a uma velocida­ de espantosa. A AT&T havia previsto quase 40 milhões de assinantes para o ano 2000.’ A tecnologia celular era baseada na transmissão de torre a torre, como mostrado na Figura 26-1. Cada torre ou estação terrestre “gateway” alcançava uma área geográfica ou célula limitada e tinha de estar dentro da visão de campo do satélite. Os usuários de telefone celular também tinham de estar perto de um gíi/ewyque iria fazer a transmissão up/inAr^para um sa­ télite. O satélite faria então uma transmissão downlink?™ para um outro gateway que conectaria a transmissão para um sistema terrestre de telefonia. Esse tipo de comunica­ ção é, muitas vezes, chamada de arquitetura bent-pipe™. As barreiras físicas entre os emissores/receptores e os ga­ teways - como montanhas, túneis e oceanos - criavam problemas de interferência e, portanto, limitavam os ser­ viços a comunidades de alta densidade. Sendo assim, os telefones celulares não podiam sair de casa. E, se o fizes­ sem, havería cobranças “adicionais" de roaming?1*. Para piorar a situação, cada país tinha seus próprios padrões e alguns telefones celulares ficavam inoperantes em viagens a outros países. Os satélites de comunicações, em uso desde 1960, eram geralmente satélites geoestacionários que orbitavam em altitudes de mais de 35.880 quilômetros. Nessa altura, ’

BIRD, Judith Cellular Technology in Telephones, Data Proces­ sing, v. 27, n. 8, p. 37, out. 1985.

irn Parte de um link de comunicação utilizado para a transmissão

de sinais de uma estação terrestre para um satélite. s-r* Ao contrário do uplink, o downlink é a parte de um link de

FIGURA 26-1

Arquitetura típico de comunicoçõo vio satélite.

três satélites geossíncronos e apenas alguns poucos ga­ teways poderíam cobrir a maior parte da Terra. Mas, satélites nessa altitude significavam telefones grandes e irritantes atrasos de um quarto de segundo na voz. O telefone da Comsat, Planet 1, por exemplo, pesava 2,04 quilos em uma caixa do tamanho de um computador. Os satélites geossíncronos demandam sinais com uma grande dose de energia. Pequenos telefones móveis, com sinal de I watt, não poderiam funcionar com os satélites posicionados nessa altitude. Aumentar a ener­ gia de saída dos telefones celulares prejudicaria o tecido humano. A alternativa foi, portanto, mover os satélites para mais perto da Terra, de forma que seria necessária menos energia. Isso iria demandar consideravelmente mais satélites quanto mais nos aproximamos da Terra e dos gateways adicionais. Os satélites geossíncronos, que estão 100 vezes mais distantes da Terra do que os saté­ lites de baixa órbita terrestre (LEO * 77), poderiam exigir quase 10.000 vezes mais energia do que os I.EOs, se todo o resto permanecesse igual.1

Quando Bary Bertiger voltou à Motorola, reuniu-se com o Dr. Raymond Leopold e com Kenneth Peterson para ver se tal sistema mundial poderia ser desenvolvido ao mesmo tempo em que fossem superadas todas as limi­ tações da tecnologia celular. Também havia o problema de que os satélites LEO estariam orbitando a Terra rapi­ damente e passando por variações de temperatura - do calor do sol à sombra fria da Terra? Os satélites LEO pro­ vavelmente teriam de ser substituídos a cada cinco anos. Vários designs terrestres alternativos foram discutidos e abandonados. Em I987, iniciou-se uma pesquisa sobre

comunicação para a transmissão de sinais de um satélite para

uma estação terrestre. Em tradução livre,“tubo encurvado”. n'» Termo que designa a capacidade de um usuário de uma rede de telefonia em obter conectividade fora das áreas onde está cadastrado por meio de uma outra rede, como visitante.

Kr Baixa órbita terrestre. Tradução para Low Earth Orbit (LEO).

•

Ver nota 3. GERDING, Bruce. Personal Communications via Satellite: An Overview. Telecommunications, v. 30, n. 2, p.35,77, fev. 1996.

735

A ASCENSÀO, QUEDA E RESSURREIÇÃO DO IRIDIUM

uma constelação de satélites LEO que se moviam em órbitas polares e que poderiam se comunicar direta­ mente com os sistemas de telefonia no solo e uns com os outros. A inovação do Iridium estava em usar uma grande constelação de satélites de baixa órbita, aproximadamente de 643 a 724 quilômetros de altitude. Como os satélites Iri­ dium estavam mais perto da ferra, os telefones poderiam ser muito menores e o atraso de voz, imperceptível. Mas havia ainda grandes problemas de design técnico. Com o design já existente, seria necessário um grande núme­ ro de gateways, portanto, aumentando substancialmente o custo do sistema. Um dia, quando saiam do trabalho, em 1988, o Dr. Leopold propôs um elemento crítico de design. Todo o sistema seria invertido, por meio do qual a transmissão iria de satélite em satélite até que a trans­ missão atingisse o satélite diretamente sobre a pessoa que estaria recebendo a mensagem. Com essa abordagem, se­ ria necessária apenas uma estação terrestre gateway para conectar chamadas de móvel para fixo para os sistemas terrestres de telefonia. Essa foi considerada uma solução cobiçada e imediatamente foi escrita em formato de es­ boço em um quadro branco no escritório de um guarda dc segurança. Assim surgiu a ideia por trás dc um telefone celular handheld mundial e sem fio com capacidade de se comunicar em qualquer lugar e a qualquer hora. 26.1 A NOMEAÇÃO DO PROJETO "IRIDIUM"

O engenheiro de sistema de telefonia celular da Motorola, Jim Williams, das instalações da Motorola próximas a Chi­ cago, sugeriu o nome de Iridium. A constelação de 77 saté­ lites proposta o fez lembrar dos elétrons que circundam o núcleo, no modelo clássico de Bohr para o átomo. Quando ele consultou a tabela periódica dos elementos para desco­ brir qual átomo tinha 77 elétrons, ele encontrou o irídio - um nome criativo que soava bem. Felizmente, o sistema ainda não tinha sido reduzido para 66 satélites, ou então, ele poderia ter sugerido o nome Disprósio. 26.2

A OBTENÇÃO DE APOIO EXECUTIVO

Inicialmente, os colegas e superiores de Bertiger na Mo­ torola tinham rejeitado o conceito do Iridium por cau­ sa de seu custo. Originalmente, o conceito Iridium era considerado perfeito para o governo dos Estados Unidos. Infelizmente, a era dos projetos lucrativos financiados pelo governo estava chegando ao fim, e era improvável que o governo financiasse um projeto dessa magnitude. No entanto, a ideia por trás do conceito Iridium intri­ gou Durrell Hillis, o gerente geral do Grupo Espacial e de Tecnologia da Motorola. Hillis acreditava que o Iridium seria viável se pudesse ser desenvolvido como um sistema

comercial. Hillis instruiu Bertiger e sua equipe a conti­ nuar trabalhando no conceito Iridium, mas em segredo. “Eu criei um projeto ilícito com sigilo para que ninguém na empresa soubesse dele”, Hillis re­ corda. Ele estava preocupado que, se a informa­ ção vazasse, as unidades de negócio ferozmente competitivas da Motorola, todas as quais ti­ nham que lutar por financiamentos para P&D, iriam abafar o projeto com contrariedades?

Após 14 meses de novas versões sobre o plano de ne­ gócio comercializado, Hillis e os líderes da equipe Iridium apresentaram a ideia a Robert Galvin, presidente do con­ selho de administração da Motorola na época, o qual deu autorização para ir adiante com o projeto. Robert Gal­ vin, e mais tarde seu sucessor e filho, Christopher Galvin, viam o Iridium como um potencial símbolo de valentia tecnológica da Motorola e acreditavam que se tornaria a oitava maravilha do mundo. Em uma das reuniões ini­ ciais, Robert Galvin virou para John Mitchell, presiden­ te e chief operating officer da Motorola, e disse: “Se você nào preencher um cheque para isso John, eu, o farei, do meu próprio bolso”.* 7 Para os engenheiros da Motorola, o desafio do lançamento da constelação Iridium propor­ cionou uma motivação considerável. Eles continuaram o desenvolvimento do projeto que resultou em um serviço inicial em novembro de 1998, a um custo total de mais de $5 bilhões. 26.3 0 LANÇAMENTO DO EMPREENDIMENTO

Em 26 de junho de 1990, Hillis e sua equipe formalmente anunciaram o lançamento do Projeto Iridium ao público em geral. A resposta não foi muito agradável para a Mo­ torola, com ceticismo sobre o fato de que esta seria uma nova tecnologia, os mercados-alvo eram muito pequenos, o modelo de receita era questionável, a obtenção de licen­ ças para operar em 170 países poderia ser um problema e o custo de uma chamada telefônica poderia ser alto. As empresas locais de telefonia que a Motorola considerou que apoiariam o projeto viram o Iridium como um po­ tencial concorrente já que o sistema ignorava os telefo­ nes fixos tradicionais. Em muitos países, as operadoras de serviços postais, telefônicos e telegráficos (PIT) eram estatais e uma importante fonte de receitas em virtude

•

BENNAHUM, David S. The United Nations of Iridium. Wired,

7

n. 6, p. 194,10 out. 1998. HARDY, Quentin. How a Wife’s Question I^d Motorola to

Chase a Global Cell-Phone Plan. Wall Street Journal, New York, p. Al, 16 dez. 1996. Edição kstc.

736

Gerenciamento de Projetos

das elevadas margens de lucro. Outra questão era que o Projeto Iridium foi anunciado antes que fosse concedi­ da a autorização da Comissão Federal de Comunicações (FCC)N’T8 para operar nas frequências desejadas. Mitchell e Galvin, deixaram claro que a Motorola não seguiría sozinha e absorvería o risco financeiro ini­ cial pelo robusto custo de cerca de $3,5 bilhões. Os financiamenos teriam de ser obtidos a partir dos mercados públicos e investidores privados. Para diminuir a exposi­ ção da Motorola ao risco financeiro, o Iridium teria de ser estabelecido como uma empresa financiada pelo projeto. O financiamento de projetos envolve o estabelecimento de um projeto de sociedade juridicamente independen­ te, em que os fornecedores de capital são reembolsados a partir do fluxo de caixa e dos lucros, e em que os ativos da unidade (e somente da unidade) são usados como ga­ rantia para os empréstimos. O pagamento da dívida viría apenas da empresa do projeto, em vez de qualquer outra entidade. Um risco com o financiamento de projetos é que os bens de capital podem ter uma vida limitada. A restrição de uma possível vida limitada, muitas vezes, di­ ficulta conseguir financiadores para concordar com acor­ dos financeiros de longo prazo.

O motivo dos investidores é claro: eles estão tendo uma chance de possuir uma fatia de um monopólio mundial de fato. Cada um deles terá nào só uma parte da empresa, eles serão pro­ prietários dos gateways Iridium e atuarão como distribuidores locais em seus respectivos mer­ cados domésticos. Para eles é um jogo que vale a pena jogar.8 Havia ramificações políticas com a venda de ga­ teways regionais. E se no futuro o governo dos Estados Unidos proibisse a expedição de peças de reposição para determinados gateways? E se fossem impostas sanções? E se o Iridium se tornasse um instrumento político durante a diplomacia internacional por causa do número de pos­ tos de trabalho que criava?

Além de incentivos financeiros, os proprietários de gateways receberam assentos no conselho de diretores. Conforme descrito por David Bennahum, repórter da Wired: Quatro vezes por ano, 28 membros do con­ selho Iridium, de 17 países, se reuniam para coordenar as decisões gerais de negócios. Eles se reuniram ao redor do mundo, viajando en­ tre Moscou, Londres, Quioto, Rio de Janeiro e Roma, rodeados por uma comitiva de assis­ tentes e tradutores. Assemelhando-se a uma Organização das Nações Unidas em miniatura, as reuniões do conselho eram conduzidas com tradução simultânea em russo, japonês, chinês e inglês.9

Outra questão crítica com financiamento de proje­ tos, especialmente para projetos de alta tecnologia é que eles geralmente são de longo prazo. Seriam quase oito anos antes de o serviço começar e, em termos de tecno­ logia, oito anos são uma eternidade. O Projeto Iridium era certamente uma “aposta no futuro”. E se o projeto viesse a falhar, a empresa poderia não valer nada após a liquidação.

Em 1991, a Motorola estabeleceu a Iridium Limited Liability Corporation (Iridium LLC) como uma empre­ sa separada. Em dezembro de 1991, a Iridium promoveu Leo Mondale como vice-presidente da Iridium Interna­ cional. O financiamento do projeto era ainda uma ques­ tão crítica. Mondale decidiu que, em vez de ter apenas um gateway, deveria haver algo como 12 gateways regionais que se conectassem a linhas telefônicas fixas locais. Isso tornaria o Iridium um projeto verdadeiramente global, em vez de parecer um projeto baseado na América e de­ senvolvido para aproveitara fatia de mercado das empre­ sas telefônicas estatais. Isso também tornaria mais fácil obter aprovação dos órgãos reguladores para operar em 170 países. Os investidores pagariam S 40 milhões pelo direito de possuir seu próprio gateway regional. Como afirmado por Flower:

O sócio com a maior quota de capital era a Moto­ rola. Pela sua contribuição de $ 400 milhões, a empresa inicialmente recebeu uma participação acionária de 25%, e seis dos 28 lugares no conselho da Iridium. Além disso, a Motorola fez garantias de empréstimo para a Iridium de $750 milhões, com a Iridium mantendo uma opção para um empréstimo adicional de $350 milhões. Da sua parte, a Iridium concordou com S6,6 bilhões em contratos de longo prazo com a Motorola, que inclu­ íam $3,4 bilhões para o design e lançamento do satélite, e S2,9 bilhões para operações e manutenção. A Iridium também expôs a Motorola ao desenvolvimento da tec­ nologia de satélite que lhe proporcionaria um conheci­ mento técnico significativo na construção de sistemas de comunicações por satélite, bem como vasta propriedade intelectual.

ST> Federal Communications Commission (FCC), órgão regulador

da área de telecomunicações e radiodifusão nos Estados Uni­ dos, equivalente à Anatel, no Brasil.

" 9

FLOWER, Joe. Iridium. Wired, n. 1.05, nov. 1993. Ver nota 6, Bennahum, p. 136.

737

A ASCENSÃO, QUEDA E RESSURREIÇÃO DO IRIDIUM

26.4

0 SISTEMA IRIDIUM 0

O sistema Iridium é uma rede de comunicação pessoal sem fio baseada em satélite, fornecedora de um conjunto robusto de recursos de voz para praticamente qualquer destino em qualquer lugar na Terra. Possui trés componentes principais: a rede de saté­ lites, a rede terrestre e os produtos Iridium para assinan­ tes, incluindo telefones e pagers. O design da rede Iridium permite que voz e dados sejam encaminhados para pra­ ticamente qualquer lugar do mundo. Chamadas de voz e dados sào transmitidos de um satélite para outro até chegar ao satélite acima da unidade do assinante Iridium (telefone) e o sinal é retransmitido de volta à Terra.

A principal ligação entre o segmento de controle do sis­ tema, os satélites e os gateways é feita por meio de cone­ xões de alimentação de banda K e conexões cruzadas por meio da constelação de satélites.

Os gateways sào a infraestrutura terrestre que forne­ ce serviços de telefonia, mensagens e suporte às operações de rede. As principais características dos gateways sào o seu suporte e gerenciamento dos assinantes de telefonia móvel e a interligação da rede Iridium ao sistema de te­ lefonia terrestre. Os gateways também fornecem funções de gerenciamento de redes e conexões de rede para seus próprios elementos. 26.6 A INICIACÃO DO PROJETO:

26.5

A REDE TERRESTRE E ESPACIAL1

A constelação Iridium consiste de 66 satélites operacio­ nais e 11 reservas que orbitam em uma constelação de seis planos polares. Cada plano tem 11 satélites de mis­ são atuando como nós na rede de telefonia. Os 11 saté­ lites restantes orbitam como sobressalentes prontos para substituir qualquer satélite avariado. Essa constelação as­ segura que cada região do globo esteja coberta por, pelo menos, um satélite em todos os momentos.

Os satélites estão em órbita quase polar, a uma alti­ tude de 485 milhas (780 km). Eles circulam a Terra uma vez a cada 100 minutos viajando a uma velocidade de 27.088 quilômetros por hora. O peso do satélite é de 680 quilos. Cada satélite é de aproximadamente 12 metros de comprimento e 3,5 metros de largura. Além disso, cada satélite possui 48 feixes pontuais, 48 quilômetros de diâ­ metro por feixe.

Cada satélite é cruzado com outros quatro satélites: dois satélites no mesmo plano orbital e dois em um pla­ no adjacente. A rede terrestre é composta por um siste­ ma de controle de segmento e de gateways de telefonia utilizados para se conectar ao sistema de telefonia ter­ restre. O Segmento de Controle do Sistema é o compo­ nente de gerenciamento centra) para o sistema Iridium. Ele fornece suporte operacional global e serviços de controle para a constelação de satélites, fornece dados de rastreamento por satélite para os gateways e realiza a função de controle de encerramento dos serviços de mensagens. O Segmento de Controle do Sistema é for­ mado por trés principais componentes: quatro locais de rastreamento e controle de telemetria, rede de suporte operacional e o centro de operações da rede de satélites.

10

"

Esta é a versão operacional atual do sistema Iridium, tirada do website da Iridium, www.lridium.com. Ver nota 10.

DESENVOLVIMENTO DO

BUSINESS CASE

Para que o Projeto Iridium fosse um sucesso de negó­ cios em vez de apenas um sucesso técnico, teria de existir uma base de clientes estabelecida. Estudos independentes conduzidos por A.T. Kearney, Booz, Alien & Hamilton e Gallup indicaram que 34 milhões de pessoas tinham de­ monstrado uma necessidade de serviços móveis via saté­ lite, com esse número devendo crescer para 42 milhões até 2002. Desses 42 milhões, a Iridium previa que 4,2 milhões fossem assinantes apenas do serviço por satéli­ te, 15,5 milhões de assinantes de serviço por satélite e de roaming mundial terrestre, e 22,3 milhões de assinantes apenas do serviço de roaming terrestre. Uma necessidade universal na conduçào dos ne­ gócios é garantir que você nunca ficará sem contato. A Iridium proporcionaria essa solução única para os ne­ gócios com a ferramenta essencial de comunicaçào. Essa proposta de um telefone, um número com a capacidade de ser acessado em qualquer lugar e a qualquer momento era uma mensagem de que os mercados-alvo - o viajante global, os setores de mineração, rural, marítimo, o gover­ no, entidades de assistência a desastres e grupos de ajuda comunitária - iriam facilmente adotar.

Além disso, ao mesmo tempo da concepção do Iri­ dium, parecia haver outra oportunidade potencialmen­ te lucrativa no mercado de telecomunicações. Quando os usuários de celulares ou telefones móveis cruzavam fronteiras internacionais, logo descobriam que havia a ausência de padrões comuns, o que tomava alguns tele­ fones inoperantes. A Motorola via isso como uma opor­ tunidade de criar um padrão mundial que permitisse que os telefones fossem utilizados em qualquer lugar do mundo.

O equilíbrio de mercado esperado para a Iridium era estimado entre 400.000 e 600.000 clientes globais, conside­ rando uma taxa razoável de utilização por cliente por mês.

738

Gerenciamento de Projetos

Com uma data de lançamento do serviço Iridium estabe­ lecida para 1998, a Iridium esperava recuperar todo o seu investimento no prazo de um ano. Para 2002, a Iridium previa uma base de clientes de 5 milhões de usuários. O mercado-alvo inicial era o mercado vertical, de indústria, governo e agências mundiais que defendiam suas neces­ sidades e requisitos de comunicação de longo alcance. Igualmente importantes seriam os clientes industriais e do setor público. Muitas vezes, isolados em locais remotos fora da cobertura de celular, os usuários industriais deve­ ríam utilizar os serviços portáteis via satélite Iridium para complementar ou substituir os seus terminais existentes de comunicações por rádio ou satélite. Os mercados verticais para o Iridium incluiriam:

• • • • • • • • • • • •

Aviação Construção Emergência/assistência a desastres Adm in ist ração florestal Governo Viagens de lazer Marítimo Mídia e entretenimento Militar Mineração Petróleo e gás Serviços públicos

Usando seus próprios recursos de marketing, a Iri­ dium pareceu ter identificado um segmento de mercado atrativo, após ter rastreado mais de 200.000 pessoas, en­ trevistado 23.000 pessoas de 42 países e examinado mais de 3.000 empresas. /X Iridium também precisaria de parceiros estraté­ gicos regionais, não só para fins de investimento e para compartilhar os riscos, mas para fornecer serviços em seus territórios. Os parceiros estratégicos regionais ou empresas operadoras de gateways teriam direitos exclu­ sivos em seus territórios e seriam obrigados a comerciali­ zar e vender os serviços da Iridium. Os gateways também seriam responsáveis pelas vendas ao usuário final, pela ativação e desativação dos serviços Iridium, manutenção da conta e faturamento. /X Iridium precisaria que cada país concedesse licen­ ças plenas para o acesso ao sistema Iridium. /X empresa também precisaria identificar os países “prioritários” que representam a maioria do plano de negócio. Em virtude do número de países envolvidos na rede Iridium, a empresa precisaria estabelecer Centros de Atendimento ao Cliente global para serviços de supor­ te em todos os idiomas. Não importava onde um usu­ ário Iridium estivesse localizado, ele teria acesso a um

representante de serviço ao cliente em sua língua nativa. Os Centros de Atendimento ao Cliente estariam estra­ tegicamente localizados para oferecer suporte 24 horas por dia, 7 dias por semana e 365 dias por ano.

26.7

Q BUSINESS CASE "OCULTO"

A decisão da Motorola de investir pesadamente no Pro­ jeto Iridium pode ter sido impulsionada por um business case secundário ou oculto. Ao longo dos anos, a Motorola alcançou uma reputação de ser pioneira (isto é.a primeira a comercializar). Com o projeto Iridium, a Motorola esta­ va prestes a capturar a vantagem do pioneirismo na pres­ tação de serviço de telefonia global, por meio de satélites de baixa órbita terrestre. Além disso, mesmo que o Pro­ jeto Iridium nunca resultasse em prestação de serviços, a Motorola ainda teria acumulado valiosa propriedade intelectual que a tornaria possivelmente a principal parti­ cipante em comunicações via satélite nos anos seguintes. Também pode ter tido o desejo de Robert e Christopher Galvin de ter seus nomes gravados na história como pio­ neiros na comunicação via satélite. 26.8

0 GERENCIAMENTO DOS RISCOS

Bons business cases identificam os riscos que o projeto deve considerar. Para simplificar, os riscos iniciais as­ sociados ao Projeto Iridium poderiam ser classificados como se segue. Riscos de Tecnologia

Embora a Motorola tivesse alguma tecnologia dispo­ nível para o Projeto Iridium, havia ainda a necessidade de desenvolver tecnologias adicionais, especificamente a tecnologia dc comunicações via satélite. O processo de desenvolvimento deveria levar anos e, no final, resultaria em várias patentes.

Mark Gercenstein, vice-presidente de operações da Iridium, explica a complexidade tecnológica do sistema: Mais de 26 coisas completamente impossíveis tinham de acontecer primeiro e na sequência correta (antes que pudéssemos iniciar as ope­ rações) - como obtenção de capital, acesso ao mercado, espectro global, a mesma banda de frequência em cada país de operação.12

Embora ainda houvesse algum risco no desenvolvi­ mento de novas tecnologias, a Motorola tinha a reputação

GRAMS, Peter; ZF.RBIB, Patrick. Caring for Customers in a Global Marketplace. Satellite Communications, p. 25, out. 1998.

739

A ASCENSÀO, QUEDA E RESSURREIÇÃO DO IRIDIUM

de ser uma empresa high-tech, e que “fazia acontecer”. Os engenheiros da Motorola acreditavam que poderiam pro­ duzir milagres em tecnologia. A Motorola também tinha uma reputação de ser uma pioneira, com novas idéias e produtos, e que não havia nenhuma razão para acreditar que isso não aconteceria no Projeto Iridium. Não houve competição pelo Iridium, em seu início. Como o cronograma do projeto era de mais de uma década de duração, havia o risco de obsolescência tecno­ lógica. Isso exigiu que certas premissas fossem feitas com relação à tecnologia de uma década adiante. O desenvol­ vimento de um novo produto é relativamente fácil se o ambiente for estável. Mas em um ambiente de alta tecno­ logia que é tanto turbulento quanto dinâmico, é extrema­ mente difícil determinar como os clientes vão perceber e avaliar o produto dez anos depois. Riscos de Desenvolvimento

A tecnologia de comunicação via satélite, uma vez de­ senvolvida, tinha de ser fabricada, testada e instalada em sa­ télites e equipamentos terrestres. Mesmo que a tecnologia já existisse ou fosse existir, ainda havia riscos de transição ou de desenvolvimento a partir da engenharia, até a fabricação e até a implementação, o que traria problemas adicionais associados que nào foram contemplados ou previstos.

Riscos de Comercialização

Os riscos de comercialização eram certamente os maiores riscos que se apresentavam para a adesão ao Iri­ dium. Mais uma vez, os riscos são compartilhados entre seus membros, e cada membro deveria cadastrar clientes em sua área geográfica. Cada membro do consórcio tinha de ser agressivo no cadastramento de clientes para um produto que ainda não existia, não existiam protótipos a serem apresentados para os clientes, as limitações do equipamento ainda eram des­ conhecidas e poderiam ocorrer mudanças significativas na tecnologia entre o momento do cadastramento do cliente e o momento que o sistema estivesse pronto para uso. As empresas que veem a necessidade pelo Iridium, hoje, po­ dem não ver a mesma necessidade daqui a dez anos.

A motivação dos sócios do consórcio em iniciar a comercialização de imediato seria extremamente difícil, pois o material de comercialização era inexistente. Havia também o medo muito real de que a adesão ao consórcio fosse motivada mais pela tecnologia do que pelo tama­ nho necessário da base de clientes exigida.

Os riscos eram inter-relacionados. Os riscos finan­ ceiros eram altamente dependentes dos riscos de comer­ cialização. Se não pudesse ser cadastrada uma base de clientes suficiente, poderia haver dificuldade significativa no levantamento de capital.

Riscos Financeiros

O custo do projeto Iridium, mais certamente, seria medido em bilhões de dólares. Isso incluiría os custos de desenvolvimento e implementação da tecnologia, a fabri­ cação e o lançamento de satélites, a construção das insta­ lações de suporte em terra, marketing e supervisão. O le­ vantamento de dinheiro dos mercados de crédito e capital de Wall Street estava a anos de distância. Os investidores provavelmente não colocariam as necessárias centenas de milhões de dólares em uma ideia ou uma visão apenas. /X tecnologia precisava ser desenvolvida, e possivelmente acompanhada, pelo lançamento de alguns satélites antes que os mercados de crédito e de capital participassem. Os investidores privados eram uma possibilidade, mas a maior fonte de financiamento inicial teria de vir dos membros do consórcio Iridium. Embora o compar­ tilhamento de riscos financeiros entre os membros pare­ cesse apropriado, não havia dúvida de que seriam neces­ sários empréstimos bancários e linhas de crédito. Como o Projeto Iridium era basicamente uma ideia, os bancos exigiríam alguma forma de caução ou garantia para os empréstimos. A Motorola, como a maior parte interessa­ da (e também com os “bolsos mais cheios”) teria de ga­ rantir os empréstimos iniciais.

26.9 A CRENÇA COLETIVA

Embora a literatura não identifique claramente, havia pro­ vavelmente uma crença coletiva entre os trabalhadores designados para o Projeto Iridium. A crença coletiva é um desejo fervoroso e. talvez, cego, de realização, que pode per­ mear toda a equipe, o patrocinador do projeto e até os níveis mais altos de gestão. Ela pode fazer uma organização racio­ nal agir de maneira irracional.

Quando existe uma crença coletiva, as pessoas são selecionadas com base em seu apoio à crença coletiva. Os descrentes são pressionados a apoiar a crença coletiva e os membros da equipe não são autorizados a contestar os resultados. Como a crença coletiva cresce, tanto os de­ fensores quanto os descrentes são ignorados. A pressão da crença coletiva pode pesar mais que a realidade dos resultados. Há várias características da crença coletiva, razão pela qual alguns projetos grandes, de alta tecnologia, são muitas vezes difíceis de matar:

• • • •

Incapacidade ou recusa em reconhecer o fracasso Rejeição em ver os sinais de alerta Visão apenas do que se quer ver Medo de expor erros

740

Gerenciamento de Projetos

• • • •

Percepção de notícias ruins como fracasso pessoal Percepção do fracasso como sinal de fraqueza Percepção do fracasso como dano para a carreira Percepção do fracasso como dano à reputação

26.10 0 CAMPEÃO DE SAÍDA

Os campeões do projeto fazem todo o possível para tor­ nar seu projeto bem-sucedido. Mas e se os campeões do projeto, bem como a equipe do projeto, tém uma fé cega no sucesso do projeto? O que acontece se as con­ vicções firmemente defendidas e a crença coletiva des­ consideram os primeiros sinais de alerta de perigo imi­ nente? O que acontece se a crença coletiva suprime as dissidências?

ter sido alguém do conselho de administração ou mes­ mo todo o conselho de administração da Iridium. Infe­ lizmente, todo o conselho de administração da Iridium também fazia parte da crença coletiva e esquivou-se de sua responsabilidade na supervisão do Projeto Iridium. No final, a Iridium não tinha nenhum campeão de saída. Os grandes projetos incorrem em sobrecustos e grandes atrasos no cronograma. Tomar a decisão de cancelar um projeto como esse, uma vez iniciado, é muito difícil, de acordo com David Davis14: A dificuldade de abandonar um projeto depois de vários milhões de dólares terem sido com­ prometidos com ele tende a impedir a revisão objetiva e o replanejamento de custos. Por essa razão, teoricamente, uma equipe de gestão in­ dependente - não envolvida no desenvolvimen­ to do projeto - deve fazer o replanejamento dos custos e, se possível, a revisão inteira... Se os nú­ meros não se sustentarem na revisão e no repla­ nejamento dos custos, a empresa deve abando­ nar o projeto. O número de projetos ruins que chegam à fase operacional serve como prova de que os seus apoiadores, muitas vezes relutam em tal decisão...

Em tais casos, um campeão de saída deve ser de­ signado. O campeão de saída, algumas vezes, precisa ter algum envolvimento direto no projeto para ter credibili­ dade. Os campeões de saída devem estar dispostos a co­ locar sua reputação em jogo e, possivelmente, enfrentar a probabilidade de serem expulsos da equipe do projeto. Segundo Isabelle Royer' : * Às vezes, é necessário um indivíduo, em vez de evidências crescentes, para chacoalhar a crença coletiva de uma equipe de projeto. Se o pro­ blema com o entusiasmo desenfreado come­ ça como uma consequência involuntária do trabalho legítimo de um campeão do projeto, então o que pode ser necessário é uma força compensatória - um campeão de saída. Essas pessoas são mais do que advogados do diabo. Em vez de simplesmente levantar questões so­ bre um projeto, elas procuram evidências ob­ jetivas que mostrem que os problemas existem de fato. Isso lhes permite contestar - ou, dada a ambiguidade dos dados existentes, até mes­ mo concebivelmente confirmar - a viabilidade de um projeto. Elas então tomam atitudes com base nos dados.

Quanto maior o projeto e quanto maior o risco fi­ nanceiro para a empresa, mais no alto o campeão de saí­ da deve estar hierarquicamente. No Projeto Iridium, a crença coletiva se originou com Galvin, CEO da Moto­ rola. Portanto, quem poderia atuar como o campeão de saída no Projeto Iridium? Como provavelmente deveria ser alguém superior a Galvin, o campeão de saída deveria ”

ROYER, Isabelle. Why Bad Projects Are So Hard to Kill. Har­

...Os gerentes seniores precisam criar um am­ biente que recompense a honestidade e a cora­ gem e que propicie mais tomadas de decisões por parte dos gerentes de projetos. As empresas devem possuir uma atmosfera que incentive os projetos ao sucesso, mas os executivos devem permitir que eles fracassem. Quanto maior o projeto, maior a necessidade dos campeões de saída e dos patrocinadores do projeto em se certificar de que o plano de negócio possui “rampas de saída", pelas quais o projeto possa ser rescindido antes que enormes recursos sejam empenhados e consumidos. In­ felizmente, quando existe uma crença coletiva, as rampas de saída são propositadamente omitidas no projeto e nos planos de negócio. 26.11

0S ANOS DE INFÂNCIA DO IRIDIUM

Em 1992, o Projeto Iridium atraiu empresas robustas como General Electric, Lockheed e Raytheon. Algumas empresas queriam estar envolvidas para fazer parte da

14

DAVIS, David. New Projects: Beware of False Economics. Har­

vard Business Review, p. 11, fcv. 2003. Copyright © 2003 por

vard Business Review, p. 100-101, mar.-abr. 1985. Copyright

Harvard Business School Publishing Corporation. Todos os direitos reservados.

Faculdade de Harvard. Todos os direitos reservados.

1985 pelo Presidente e pelos Membros do Conselho Diretor da

741

A ASCENSÃO, QUEDA E RESSURREIÇÃO DO IRIDIUM

pessoas ao redor do mundo que pode pagar por nossos serviços irá torná-los bem-sucedidos.” O Sr. Mitchell diz que, se apenas 1% a 1,5% dos esperados 100 milhões de usuários de celulares no ano de 2000 se tornarem usuários regulares a $ 3 o minuto, a Iridium atingirá o equilíbrio. Como ele sabe disso? “Estudos de Marketing”, os quais ele nào compartilhará. O Sr. Nowacki, da TRW diz que o Odyssey cobrirá a Terra com um serviço de comunicação de voz de duas vias que custa “apenas um ligeiro prêmio” para celulares. “Com dois milhões de assinantes, podemos ob­ ter um substancial retorno sobre o nosso inves­ timento “, diz ele. “A Loral Qualcomm Satellite Services Inc. pretende ser o satélite ’amigável’ ao deixar empresas de telefonia parceiras usar e executar as estações terrestres do seu sistema", dizia o Vice-Presidente Executivo, Anthony Na­ varra. Ele dizia: “Até o ano de 2000 haverá 15 milhões de clientes não atendidos de telefonia celular no mundo”.15

revolução da tecnologia de satélites, enquanto outras ti­ veram medo de ficar para trás na curva da tecnologia. De qualquer forma, a iridium estava organizando parceiros estratégicos, mas lentamente.

O Plano da Iridium, enviado à FCC em agosto de 1992, demandava uma constelação de 66 satélites, que deveríam entrar em funcionamento em 1998, e mais po­ tentes do que o inicialmente proposto, mantendo, assim, o custo do projeto nos $3,37 bilhões estimados anterior­ mente. Mas o Projeto Iridium, embora baseado em previ­ sões elevadas de clientes disponíveis, estava agora atraindo outras empresas concorrentes pela aprovação da FCC em sistemas semelhantes de satélite, incluindo Loral Corp, TRW Inc. E a Hughes Aircraft Co., uma unidade da Gene­ ral Motors Corp. Havia pelo menos nove empresas con­ correndo pelo potencial de bilhões de dólares em receitas inexploradas a partir das comunicações via satélite. Mesmo com o aumento da concorrência, a Motoro­ la estava inscrevendo parceiros. Ela tinha fixado um pra­ zo interno até 15 de dezembro de 1992, para encontrar o financiamento necessário para a Iridium. Cartas de in­ tenção assinadas foram recebidas do governo brasileiro e da United Communications Co., de Bangkok, Tailândia, para comprar fatias de 5% do projeto, cada uma agora avaliada em cerca de S80 milhões. Os termos do acordo implicavam que o consórcio Iridium financiaria o proje­ to com cerca de 50% de capital e 50% de dívida.

Quando o prazo de 15 de dezembro chegou, a Mo­ torola estava relativamente calada quanto à inscrição de parceiros financiadores, alimentando especulações de que estava tendo problemas. A Motorola admitiu que o processo foi demorado porque alguns investidores pre­ cisavam de aprovação do governo antes de prosseguir. A empresa deveria anunciar em algum momento, talvez na primeira metade de 1993, se estava pronta para prosseguir com o passo seguinte, ou seja, o recebimento de dinheiro suficiente de seus investidores, garantias de empréstimos e compras de equipamentos para os satélites e para o grupo. Conforme a concorrência aumentava, o otimismo sobre o tamanho potencial da base de clientes também aumentava.

“Estamos falando de um negócio de geração de bilhões de dólares em receitas”, diz John E Mitchell, Vice-Chairman da Motorola. “Faça uma simples extrapolação de receita”, acrescen­ ta Edward J. Nowacki, gerente-geral da TRW Space & Electronics Group, Redondo Beach, Califórnia, que planeja um sistema de 12 saté­ lites, de $1,3 bilhões, chamado Odyssey. “Vocé conclui que mesmo uma pequena fração das

Mas, embora a Motorola e outros concorrentes esti­ vessem tentando justificar o seu investimento com “pro­ jeções de mercado infladas" e um desejo do público pela recepção maus rápida e mais clara, os analistas do merca­ do financeiro nào estavam tão benevolentes. Primeiro, os analistas de mercado questionaram o tamanho da base de clientes que estariam dispostos a pagar 5 3.000 ou mais por um telefone via satélite, além de $ 3 a $ 7 o minuto por uma chamada. Em segundo lugar, o sistema exigia uma transmissão com linha de visada, o que significava que nào funcionaria em edifícios ou em carros. Se um homem de negócios estivesse participando de uma reu­ nião em Bangkok e precisasse ligar para sua empresa, ele teria de sair do edifício, levantar a antena de seu aparelho de $ 3.000, apontar a antena para o céu e depois fazer a chamada. Em terceiro lugar, os satélites voando baixo acabariam por colidir com a atmosfera da Terra a cada cinco a sete anos, por causa do arrastamento atmosférico, e precisariam ser substituídos. Isso mais provavelmen­ te resultaria em altos custos de capital. E quarto, alguns analistas de mercado acreditavam que os custos iniciais seriam mais próximos de S 6 bilhões a $ 10 bilhões em vez dos $ 3,37 bilhões estimados pela Iridium. Além disso, o negócio de telefonia celular terrestre estava se expan­ dindo em mais países, criando, assim, uma outra ameaça competitiva para a Iridium.

'■

KELLER, John J. Telecommunications: Phone Space Race Has Fortune at Stake, Wall Street Journal, p. Bl, 18 jan. 1993. Edição leste.

742

Gerenciamento de Projetos

O business case inicial precisava ser periodicamente reavaliado. Mas com fortes crenças coletivas e nenhum campeão de saída, o medo de uma oportunidade perdida, independentemente do custo, tomou o centro do palco.

Razoavelmente certa de já contar com 18 dos 21 inves­ tidores, a Motorola esperava iniciar o lançamento de satélites de teste em 1996 e iniciar o serviço comercial em 1998. Mas os críticos argumentavam que o Iridium poderia estar obsoleto no momento em que real mente começasse a funcionar. Finalmente, a Iridium foi capaz de atrair o apoio fi­ nanceiro de 19 parceiros estratégicos:

• AIG Affiliated Companies • China Great Wall Industry Corporation (CGW1C) • Iridium Africa Corporation (baseada na Cidade do Cabo) • Iridium Canada, Inc. • Iridium India Telecom Private Ltd, (ITIL) • Iridium Italia S.p.A. • Iridium Middle East Corporation • Iridium SudAmerica Corporation • Khrunichev State Research and Production Space Center . Korea Mobile TELECOM • Lockheed Martin • Motorola • Nippon Iridium Corporation • Pacific Electric Wire & Cable Co. Ltd (PEWC) • Raytheon • STET • Sprint • Thai Satellite Telecommunications Co., Ltd. • Verbacom

Dezessete dos parceiros estratégicos, também parti­ ciparam das operações de gateway com a criação de em­ presas operacionais.

serviços de lançamento seriam concedidos ao Khruni­ chev Space Center, da Rússia e ao Great Wall Industry7 Corporation, da China, ambos membros do consórcio. Os contratos de menor custo com a Rússia e a China esta­ vam colocando uma pressão extraordinária sobre os pro­ vedores americanos para reduzir seus custos.

Além disso, ao mesmo tempo, um dos concorren­ tes da Iridium, o sistema Globalstar, que era um sistema de telefonia móvel de 48 satélites conduzido pela Loral Corporation, anunciou que pretendia cobrar 65 centavos por minuto nas áreas a que servia. Os críticos do Iridium estavam argumentando que o Iridium seria caro demais para atrair um grande volume de usuários.16 26.12 0 FINANCIAMENTO DA DÍVIDA

Em setembro de 1994, a Iridium disse que tinha concluí­ do o seu financiamento de capital, levantando um adi­ cional de S 733,5 milhões. Isso levou o capital total com­ prometido com a Iridium, por meio de financiamento, a $1,57 bilhão. z\ conclusão do financiamento de capital permitiu à Iridium entrar em financiamento de dívida para construir a rede wireless global por satélites. Em setembro de 1995, a Iridium anunciou que emi­ tiría $300 milhões em cotas seniores e subordinadas de títulos descontados com prazo de dez anos, classificadas como Caa pela Moody’s, e CCC+ pela Standard & Poor’s, por meio do banco de investimentos Goldman Sachs Inc. Os títulos foram considerados “podres”, de alto risco e alta rentabilidade, depois que os investidores concluíram que as recompensas não valeríam o risco. As agências de classificação citaram como motivos para a baixa classificação a tecnologia sofisticada ainda não comprovada e o fato de que uma parte significativa dos equipamentos do sistema estaria localizada no espa­ ço. Mas havia outras sérias preocupações:

• O custo final do Projeto Iridium seria algo como S 6 bilhões ou mais, em vez de $3,5 bilhões, e que era improvável que a Iridium recuperasse esse custo. • O Iridium seria uma hemorragia de dinheiro por vários anos antes que o serviço começasse. • O número otimista de clientes potenciais para te­ lefones via satélite poderia não escolher o sistema Iridium. • O número de concorrentes havia aumentado des­ de que o conceito Iridium foi desenvolvido pela primeira vez.

O conselho de administração da Iridium consistia de 28 executivos de telecomunicações. Todos, menos um membro do conselho eram também membros do consór­ cio. Isso tomava muito difícil para o conselho cumprir o seu dever de supervisão de forma eficaz, dado o interesse absoluto e financeiro no projeto Iridium. Em agosto de 1993, a Lockheed anunciou que recebe­ ría $ 700 milhões em receitas para a construção do satélite. A Lockheed construiría a estrutura de satélites, painéis solares, sistemas de altitude e propulsão, junto com outras peças e su­ porte de engenharia. A Motorola e a Raytheon Corp construiriam os dispositivos e as antenas de comunicação por satélite. Em abril de 1994, a McDonnell Douglas Corp rece­ beu da Iridium um contrato de S 400 milhões para lan­ çar 40 satélites para a Iridium. Outros contratos pelos

16

COLE, JeíT. McDonndl Douglas Said Io Get Contract to Laun­ ch 40 Satellites for Iridium Plan. Wall Street journal. New York, p. A4, 12 abr. 1994. Edição leste.

743

A ASCENSÃO, QUEDA E RESSURREIÇÃO DO IRIDIUM

• Se o projeto Iridium não pagasse sua dívida, os investidores poderiam reivindicar os ativos da Iri­ dium. Mas o que os investidores fariam com mais de 66 satélites no espaço, à espera da desintegração ao reentrar na atmosfera?

O Iridium foi instituído como “financiamento de projeto”, caso em que, se ocorresse uma moratória, apenas os ativos da Iridium poderiam ser confiscados. Com o fi­ nanciamento do projeto, os investidores do consórcio esta­ riam isentos de responsabilidade por qualquer dívida con­ traída a partir dos mercados de ações e títulos e poderiam simplesmente se retirar da Iridium. Esses riscos, associados ao financiamento do projeto, foram bem compreendidos por aqueles que investiram nos mercados de capital e de crédito. O Goldman Sachs & Co., lead underwriter ™ * para a oferta de títulos, determinou que, para a emissão de títu­ los ser concluída com êxito, teria de existir uma garantia de conclusão de investidores de bolsos mais cheios, como a Motorola. O Goldman Sachs citou uma oferta de S 400 milhões por um dos concorrentes da Iridium, Globalstar, que tinha uma garantia por parte do sócio-gerente, a Lo­ ral Corp.17 Por causa da preocupação dos investidores, a Iri­ dium retirou a sua oferta de debentures prevista em $ 300 milhões. Além disso, a Globalstar, mesmo com a sua garantia de empréstimo, acabou por retirar sua oferta de $ 400 milhões. Os investidores queriam tanto uma posi­ ção no capital Iridium quanto um retorno de 20%. Além disso, a Iridium teria de voltar ao seu consórcio inicial de 17 membros e se organizar para o financiamento interno.

Em fevereiro dc 1996, a Iridium tinha levantado um adicional de $ 315 milhões a partir do consórcio dc 17 membros e de investidores privados. Em agosto de 1996, a Iridium havia assegurado uma linha de crédito $ 750 milhões em 62 bancos co-organizada pela Chase Secu­ rities inc., uma unidade do Chase Manhattan Corp, e a divisão de investment banking do Barclays Bank PLC. A linha de crédito foi subscrita em excesso por mais do dobro da meta original, pois estava coberta por uma ga­ rantia financeira pela Motorola e sua classificação de cré­ dito AAA. Por causa da garantia pela Motorola, a taxa de empréstimo foi ligeiramente superior a 5,5% da linha de

base da taxa de empréstimos comerciais internacional e significativamente inferior à taxa da oferta de S300 mi­ lhões em títulos que foi, afinal, cancelada.

Apesar desse sucesso inicial, a Iridium ainda enfren­ tava obstáculos financeiros. Até o final de 1996, a Iridium planejava levantar mais de $ 2,65 bilhões de investidores. Era estimado que mais de 300 bancos de todo o mundo estivessem envolvidos, e que essa seria a maior colocação privada de debêntures da história. A Iridium acreditava que essa campanha de colocação de debêntures poderia não ser tão difícil, já que a data de lançamento dos servi­ ços Iridium estava se aproximando. 26.13 0 PROJETO M-STAR

Em outubro de 1996, a Motorola anunciou que estava tra­ balhando em um novo projeto chamado M-Star, o qual seria uma rede de $ 6,1 bilhões de 72 satélites de baixa ór­ bita com capacidade universal de voz, vídeo e conexões de dados em alta velocidade orientadas para a comunidade internacional. O projeto era separado da empresa Iridium e estava previsto para levar quatro anos para a conclusão, após a aprovação da FCC. Segundo Bary Bertiger, então vice-presidente corporativo e diretor do grupo da Motoro­ la de comunicações via satélite, “Ao contrário da Iridium, a Motorola nào tem planos de ter o M-Star como uma en­ tidade separada. Nós nào o financiaremos sozinhos, mas teremos menos parceiros do que a Iridium."”

O Projeto M-Star arrepiou os cabelos da comunidade de investimento. O Iridium empregava 2.000 pessoas, mas o M-Star tinha apenas 80. O Projeto Iridium gerou quase 1. 100 patentes para a Motorola, e essa propriedade intelec­ tual provavelmente seria transferida para o M-Star. Além disso, a Motorola tinha três contratos com a Iridium para a construção e operação do sistema de comunicação glo­ bal, proporcionando cerca de S 6,5 bilhões em pagamen­ tos para a Motorola durante um período de dez anos, que começou em 1993.0 M-Star estaria sendo desenvolvido à custa da Iridium? O M-Star poderia substituir o Iridium? O que iria acontecer ao consórcio de 17 membros da Iri­ dium se a Motorola retirasse o seu apoio em substituição ao seu próprio sistema interno concorrente? 26.14 UM NOVO CEO

F.m 1996, a Iridium começou a formar uma equipe de gestão muito forte com a contratação do Dr. Edward KW No mercado financeiro, lead underwriter c a instituição finan­ ceira que lidera a tomada firme de emissão de ações ou títulos. Também chamada de “coordenadora líder". ” HARDY, Quentin. Iridium Pulls $300 Million Bond Offer; Analysts Cite Concerns About Projects. Wall Street Journal, New York, p. A5,22 set. 1995. Edição leste.

'•

1IARDY, Quentin. Motorola Is Plotting New Satellite Project M-Star Would Be Faster Than the Iridium System, Pitched to Global Firms. Wall Street Journal, New York, p. B4,14 out. 1996. Edição leste.

744

Gerenciamento de Projetos

Staiano como CEO e Vice Chairman. Antes de entrar para a Iridium, em 1996, Staiano havia trabalhado para a Moto­ rola por 23 anos, período durante o qual desenvolveu uma reputação de ser inflexível e implacável. Durante seus últi­ mos 11 anos na Motorola, Staiano liderou o Setor de Sis­ temas Gerais da empresa para registrar os níveis de cresci­ mento. Em 1995, a divisão foi responsável por cerca de 40% das vendas totais de $ 27 bilhões da Motorola. Ao deixar a folha de pagamento da Motorola pela da Iridium, Staiano desistiu de um contrato de S 1,3 milhões por ano com a Motorola por um salário-base de S 500.000 mais opções de 750.000 em ações da Iridium que tinham sido investidos ao longo de um período de 5 anos. Staiano comentou: De qualquer maneira, eu estava gastando de 40 a 50% do meu tempo (na Motorola) com o Iri­ dium... Se eu transformar o sonho do Iridium em realidade, farei uma quantia significativa de dinheiro.”

26.15 0S LANÇAMENTOS DOS SATÉLITES

Às 11 h28 de uma manhã de sexta-feira da segunda semana de janeiro de 1997, um foguete Delta levando um Sistema de Posicionamento Global (GPS) explodiu no lançamen­ to, espalhando destroços acima de sua plataforma de lan­ çamento em Cabo Canaveral. O lançamento, inicialmente previsto para o terceiro trimestre de 1996, certamente te­ ria um impacto sobre o cronograma da Iridium, enquan­ to um conselho da indústria composto por representantes da McDonnell-Douglas e da Força Aérea determinavam a causa da explosão. Outros lançamentos já haviam sido adiados por uma variedade de razões técnicas.

Em maio de 1997, após seis tentativas fracassadas, os cinco primeiros satélites Iridium foram lançados. A Iri­ dium acreditava que a data prevista para lançamento do serviço, setembro de 1998, ainda era realizável, mas que todas as folgas do cronograma haviam sido eliminadas, em virtude dos fracassos anteriores.

A essa altura, a Motorola tinha acumulado um enor­ me conhecimento sobre a forma de produzir satélites em massa. Conforme descrito por Bennahum: A constelação Iridium foi construída em uma li­ nha de montagem, com toda a redução associada de risco e custo que se origina ao fazer algo repe­ tidamente até que já não seja mais uma arte, mas um processo. No auge desse empreendimento.

”

em vez de levar de 18 a 36 meses para construir um satélite, as linhas de produção expeliam um satélite pronto a cada quatro dias e meio, lacra­ vam-no em um contêinerecolocavam-noem um caminhão de plataforma que ia em marcha lenta para Califórnia ou Arizona, onde um Boeing 747 à espera o levava para uma plataforma de lança­ mento nas montanhas de Taiyuan, na China ou nas estepes de Baikonur, no Cazaquistâo.20

26.16

UMA OFERTA PÚBLICA INICIAL (IPO)™

A Iridium estava queimando dinheiro a uma velocidade de S 100 milhões por mês. Ela preencheu um documen­ to preliminar com a Security and Exchange Commission (SEC) para uma oferta pública inicial (IPO) de 10 mi­ lhões de ações, oferecidas a $ 19-S 21 por ação. Por causa dos atrasos no lançamento, o IPO estava atrasado.

Em junho de 1997, depois que os cinco primeiros sa­ télites foram colocados em órbita, a Iridium se registrou para um IPO de 12 milhões de ações, ao preço de S 20 por ação. Isso cobriria cerca de 3 meses de despesas ope­ racionais, incluindo os custos de aquisições e lançamento de satélites. A maioria do dinheiro iria para a Motorola. 26.17 0 CADASTRAMENTO DE CLIENTES

A realidade do conceito Iridium estava agora à mão. Tudo o que restava a fazer era cadastrar de 500.000 a 600.000 clientes, como previsto, para usar o serviço. A Iridium re­ servou $ 180 milhões para uma campanha de marketing, incluindo publicidade, relações públicas e, globalmente, esforço de mala direta. Parte da campanha de publicidade incluía mala direta traduzida em 13 línguas, comerciais de televisão e nas companhias aéreas, cabines de aeropor­ to e páginas de Internet. Como comercializar o Iridium era um desafio. As pes­ soas certamente odiariam o telefone. Segundo John Windolph, diretor executivo de comunicações de marketing da Iridium, “É enorme! Vai assustar as pessoas. É como um dispositivo do tamanho de um tijolo com uma antena pa­ recida com um palito de pão grosso. Se tivéssemos uma campanha que exibisse nosso produto, nós perderiamos”. A decisão foi focalizar no medo de estar fora de área. Assim, a campanha de marketing começou. Mas a Iridium ainda não tinha uma imagem clara de quem iria aderir ao siste­ ma. Um executivo que ganhasse S 700.000 provavelmente compraria o grande telefone, faria com que os seus assis­ tentes levassem o telefone em sua pasta, seria reembolsado

IIARDY, Quentin Staiano Is Leaving Motorola to Lead Firm’s Iridium Global Satellite Project. Wall Street Journal, New York, p. B8, 10 dez. 1996. Edição leste.

*

Ver nota 6, Bennahum, 1998. Tradução da expressão Initial Public Offering (IPO).

745

A ASCENSÃO, QUEDA E RESSURREIÇÃO DO IRIDIUM

pela sua empresa pelo uso do telefone e pagaria de $ 3 a S 7 por minuto pelas chamadas, também uma despesa de tra­ balho. Mas existem 600.000 executivos em todo o mundo que precisem do serviço?

Havia várias outras questões críticas que precisavam ser resolvidas. Como nós ocultamos ou diminuímos o preço de compra de S 3.400 do aparelho e os custos de utilização de $ 7 por minuto? Como é que vamos evitar discussões sobre os concorrentes que estão oferecendo serviços semelhantes a um custo menor? Com licenças de operação em cerca de 180 países, vamos anunciar em todos esses países? Retiramos os anúncios no Oil and Gas Daily? Anunciamos em revistas masculinas? Usamos anúncios de página inteira ou página dupla? A Iridium tinha de depender fortemente dos seus parceiros de "gateway" para a comercialização e o supor­ te pós-venda. A Iridium em si não seria capaz de atingir todo o público potencial. Será que os parceiros de ga­ teway forneceríam o marketing necessário e o suporte de vendas? Eles saberíam como vender o sistema Iridium e os produtos associados?

dos produtos Iridium é ilimitado. Os homens de negócio que viajam o mundo e querem estar em contato com suas casas e escritórios, indús­ trias que operam em áreas remotas - todos irão encontrar no Iridium a resposta às suas necessi­ dades de comunicação.”22

Em 2 de novembro de 1998, a Iridium começou a fornecer serviços. Com o sistema Iridium finalmente ins­ talado e funcionando, a maioria dos analistas financeiros emitiu recomendações para “comprar” ações da Iridium com expectativa de faturamento anual de $ 6 a S 7 bilhões dentro de cinco anos. Em 25 de janeiro de 1999, a Iridium realizou uma coletiva de imprensa para discutir seus ga­ nhos para o quarto trimestre de 1998. Ed Staiano, CF.O da Iridium anunciou:

No quarto trimestre de 1998, a Iridium fez história já que nós nos tornamos a primeira empresa verdadeiramente global de telefonia móvel. Hoje, uma única rede sem fio, a rede Iridium, cobre o planeta. E nós passamos para 1999 com uma estratégia agressiva para colo­ car um grande número de clientes em nosso sistema e, rapidamente, transformar o Iridium de um evento tecnológico para um gerador de receita. Pensamos que as perspectivas para fazer isso são excelentes. Nosso sistema está desem­ penhando em um nível acima das expectativas.

A resposta a essas questões surgiram rapidamente. Em questão de semanas, brotaram mais de um milhão de pedidos de vendas nos escritórios de vendas da Iridium. Eles foram encaminhados para os parceiros da Iridium - e muitos deles desapareceram imediatamente, afirmaram vá­ rias pessoas de dentro da Iridium. Sem nenhum canal de comercialização e poucas e preciosas pessoas de vendas a postos, a maioria dos par­ ceiros globais era incapaz de acompanhar os pedidos. Uma montanha de dicas quentes dc vendas logo se esfriou.21 26.18

O financiamento está agora em vigor por meio de positivos fluxos de caixa projetados. O inte­ resse do cliente permanece muito elevado e um número de clientes potencialmente grandes já avaliaram nossos serviços e já deram avaliações muito altas. Com tudo isso acontecendo para nós, estamos em posição para vender o serviço e é nisso justamente que estamos concentrando a maior parte de nossos esforços.25

A ASCENÇÃO RÁPIDA DO IRIDIUM

Em 1 de novembro de 1998, o sistema Iridium foi lançado oficialmente. Foi realmente um feito notável que o proje­ to de 11 anos fosse finalmente lançado com apenas pouco mais de um mês de atraso.

Na mesma conferência telefônica, Roy Grant, CFO da Iridium, acrescentou:

Após 11 anos de trabalho duro, estamos orgu­ lhosos de anunciar que estamos abertos para os negócios. O Iridium vai abrir o mundo dos negócios, do comércio, da assistência a desastres e da ajuda humanitária com o nosso serviço de comunicação global único... O uso potencial

Na semana passada a Iridium levantou apro­ ximadamente S 250 milhões por meio de uma oferta pública de ações muito bem-sucedida de S 7,5 milhões. Essa oferta teve três grandes benefícios. Ela proporcionou S 250 milhões em espécie para o nosso balanço. Aumentou

CAULEY, Leslie. Losses in Space - Iridium’s Downfall: The Ma­ rketing Took a Back Seat to Science - Motorola and Partners Spent Billions on Satellite Links for a Phone Few Wanted. Uú// Street Journal, New York, p. Al, 18 age». 1999. Ediçào leste.

“

Trechos do comunicado de imprensa da Iridium, em 1” de no­

n

vembro de 1998. Trechos da conferência telefônica da Iridium, em 25 dc janeiro de 1999.

746

Gerenciamento de Projetos

nossa reserva pública para cerca de 20 milhões de ações, e liberou as restrições colocadas em S 300 milhões dos S 350 milhões de garantias da Motorola. Essas restrições foram colocadas em um determinado nível de garantias pelos nossos banqueiros em nossa linha de crédito garantida de S 800 milhões. Com $ 250 milhões combinados aos S 350 mi­ lhões de garantias adicionais da Motorola, signi­ fica que temos cerca de S 600 milhões de fundos em excesso, entre os quais precisamos dividir o equilíbrio do fluxo de cabia. Isso proporciona uma contingência significativa para a empresa.24

Dezembro de 1998

A fim de tomar seus produtos e serviços conheci­ dos para os viajantes, a Iridium concordou em adquirir a Claircom Corporation da AT&T e a Rogers Cantei Mobile Communications por cerca de $ 65 milhões. A Claircom fornecia sistemas de telefonia para aviões para os Estados Unidos, bem como equipamentos para transportadoras internacionais. A aquisição da Claircom seria um impul­ so de mercado para a Iridium. Os problemas com grandes projetos de tecnologia de longo prazo estavam agora aparecendo na literatura. Conforme descrito por Bennahum: Esse sistema nào permite que você faça o que muita gente que se conecta por fios quer fazer”, adverte o professor Heather Hudson, que exe­ cuta o programa de telecomunicações da Uni­ versidade de Sào Francisco e estuda o negócio de comunicações sem fios. “As tecnologias dos anos 1990 estão mudando tão rápido que é difí­ cil manter-se atualizado. O Iridium foi concebi­ do a partir de uma perspectiva dos anos 1980 de um sistema mundial de celulares. Desde então, a Internet tem crescido e a telefonia celular é mui­ to mais abrangente. Há muito mais oportuni­ dades para roaming do que foi considerado em 1989. Portanto, há poucos empresários que têm necessidade de procurar por uma alternativa a um telefone celular quando estào na estrada.25

Além disso, para o final dos anos 1990, alguns ob­ servadores da indústria sentiram que a Motorola tinha um incentivo adicional para garantir que o Iridium fosse bem-sucedido, independentemente dos custos — a saber.

24

Ver nota 23.

25

Ver nota 6, Bennehum, 1998.

proteger a sua reputação. Entre 1994 e 1997, a Motorola tinha sofrido desaceleração do crescimento das vendas, uma queda no lucro líquido e margens em declínio. Ade­ mais, a empresa tinha passado por vários percalços de negócios antes, incluindo uma talha em antecipar a mu­ dança da indústria celular para celulares digitais, o que desempenhou um papel importante em mais 50% da queda de preços das ações da Motorola em 1998. 26.19 A QUEDA RÁPIDA DO IRIDIUM

Demorou mais de uma década para o Projeto Iridium ascender e apenas alguns meses para a sua queda. Na primeira semana de março, quase cinco semanas após a teleconferência de janeiro, os problemas financeiros da Iridium começaram a vir à tona. A Iridium esperava 200.000 assinantes até o final de 1998 e assinantes adicio­ nais a uma taxa de 40.000 por mês. Os acordos de títulos da Iridium declaravam uma meta de 27.000 assinantes no final de março. A falha em cumprir uma meta tão peque­ na poderia levar a confiança dos investidores a uma que­ da em espiral. A Iridium tinha apenas 10.000 assinantes. O mercado que existia dez anos antes nào era o mercado que existia entào. Além disso, dez anos antes havia pouca concorrência para Iridium.

A Iridium citou a principal causa da insuficiência de assinaturas como sendo a escassez de telefones, falhas em parte da tecnologia, problemas de software e, mais im­ portante, a falta treinamento dos canais de vendas. A Iri­ dium percebeu que teria de treinar uma equipe de vendas e que a própria Iridium teria de vender o produto, e não os seus distribuidores. /X comunidade de investidores nào parecia satisfeita com o problema de vendas que deveria ter sido tratado anos antes, e nào com quatro meses de serviço comercial. A campanha de publicidade da Iridium foi apelidada de “Calling Planet Earth”*™ e prometia que você tinha a liberdade de se comunicar a qualquer hora e em qualquer lugar. Isso não era exatamente verdade porque o sistema não poderia funcionar dentro de prédios ou até mesmo em carros. Ademais, a Iridium subestimou a quantidade de tempo que os assinantes precisariam para examinar e testar o sistema antes de assinar. Em alguns casos, seria seis meses.

Muitas pessoas culparam marketing e vendas pela queda rápida do Iridium: É verdade, a Iridium cometeu tantos erros de marketing e vendas que suas experiências po­ deriam formar a base de um livro sobre como

XIn Em português,“Chamando o Planeta Terra".

A ASCENSÃO, QUEDA E RESSURREIÇÃO DO IRIDIUM

747

não se deve vender um produto. Seus telefones começaram custando S 3.000, eram do tama­ nho de um tijolo e não funcionavam como pro­ metido. Eles nào estavam disponíveis nas lojas quando a Iridium fez uma campanha publici­ tária de $ 180 milhões. E os preços da Iridium, que variavam de S 3,00 a S 7,50 por chamada, estavam fora da realidade.26

problema: Staiano tinha cortado os custos nào essenciais da Iridium, mas não conseguiu fazer com que a Motorola reduzisse o seu lucrativo contrato de serviços de $ 500 milhões com a Iridium. Algumas pessoas acreditavam que Staiano quisesse reduzir o contrato de serviço com a Motorola em até 50%. John Richardson, o CEO da Iri­ dium África Corp, foi designado como CEO interino. A especialidade de Richardson era a reestruturação de em­ presas. Para o trimestre terminado em março, a Iridium disse que teve uma perda líquida de $ 505,4 milhões ou de $ 3,45 por quota. As ações caíram para S 15,62 por quota. A Iridium conseguiu atrair apenas 10.294 assinantes cin­ co meses após o lançamento comercial.

O plano de negócios da Iridium era falho. Com o iní­ cio do serviço em 2 de novembro de 1998, era pouco pro­ vável que houvesse 27.000 assinantes em março de 1999, dado o tempo necessário para testar o produto. O plano de negócios inicial exigia que o consórcio comercializasse e vendesse o produto antes do início do serviço. Mas ven­ der o serviço apenas a partir de uma brochura era quase impossível. Os assinantes queriam tocar o telefone, usá-lo e testá-lo antes de se comprometer com uma assinatura.

Uma das primeiras tarefas de Richardson era refor­ mular a estratégia de marketing da Iridium. A Iridium nào tinha certeza sobre em quais negócios estava inserida. Segundo Richardson:

A Iridium anunciou que estava entrando em nego­ ciações com seus credores para alterar os termos de um contrato de crédito garantido de S 800 milhões, em vir­ tude de os números de assinantes e de receita serem mais fracos do que o esperado. Os acordos no contrato de cré­ dito incluíam o seguinte:27

Doto

Receita

Receita

Número de

Acumulodo em

Recebido

Assinantes do

Numecode

Espécie

Acumulado

Telefone via

Assinantes do

(SMihões)

(SMihões)

Satélite

* Sistema

$4

$4

50 220

150 470

27.000 88000

52.000 213000 454000

31/03/1999 30/06/1999 30/09/1999

173.000

*O total de assi nanles do sistema inclui os usuários dos serviços Iridium de telefone, fax e paging.

As ações, que tinham sido comercializadas a quase $73 cada, estavam agora em, aproximadamente, $20 por ação. E, em mais outro revés, o CFO, Roy T. Grant, se demitiu. Abril de 1999

O CEO da Iridium, Ed Staiano, demitiu-se na reu­ nião do conselho de administração, em 22 de abril. Fon­ tes acreditam que Staiano se demitiu quando o conselho vetou o seu plano de solicitação de fundos adicionais para o desenvolvimento de uma equipe própria de marketing e de distribuição da Iridium, em vez de confiar em seus parceiros estratégicos. Fontes também relataram outro

A mensagem sobre o que este produto era e aonde devia ir mudava de reunião em reunião... Um dia, falávamos sobre aplicações de telefonia celular, no dia seguinte era um produto de sa­ télite. Quando lançamos, em novembro, eu nào tenho certeza se tínhamos uma ideia clara do que queríamos ser.2*

Maio de 1999

A Iridium anunciou oficialmente que nào esperava cumprir as suas metas especificadas no contrato de em­ préstimo de $ 800 milhões. Os credores concederam à Iri­ dium uma prorrogação de 2 meses. As ações caíram para S 10,44 cada, em parte por causa de um comentário da Mo­ torola que poderia se retirar da empresa em dificuldade.

Wall Street começou a falar sobre a possibilidade de falência. Mas a Iridium afirmava que estava reformulando o seu plano de negócios e que até o final do mês esperava ter traçado um novo curso para o seu financiamento. A Iridium também declarou em uma sohcitaçào regulatória que estava incerta sobre se teria dinheiro suficiente para concluir o acordo para a compra da Claircom Communi­ cations Group Inc., uma provedora de serviços em aviões, para os prometidos S 65 milhões em dinheiro e dívida. A Iridium recebeu prorrogações para os pagamentos da dívida porque a comunidade de empréstimo sabia que nào era pequena a proeza de transformar um plano de pro­ jeto em uma empresa em funcionamento. Outra razào pela qual os bancos e os credores estavam dispostos a conceder

SUROW1ECK1PP, James. The Latest Satellite Startup Lifts Off.

Will It Too Explode? Fortune, p. 237-254,25 out. 1999. Relatório anual, de 1998, da Iridium World Communications

U ninho resposta. Procure o gerente Hostil ou ewsivo

4

geral, se você nooesió (entente.

b. Eu entendo o seu problema. Vamos fazei do Aceitação

4

seu jeito. c Eu entendo o seu proüemo, mas vou fazer

Defensivo ou hostil

4

Coopertfho

4

o que é mebor paio o meu departamento. d. Vomas dscutir o proHema. Takez haja oiemafrvos. e. Deuemeexpka a KKê per que precisamos Cooperativo cu dos novos requisitos.

f. Procure os supervisores do minha seção.

4

defensivo

Evasivo

4

Hostil ou defensivo

4

Isso foi recomendação deles.

g Novos gerentes devem trazer nmos e mdhores fcimas, não devem?

Total:

Pesscd Total: Grupo

APÊNDICE A - SOLUÇÕES PARA O EXERCÍCIO DE CONFLITO EM GERENCIAMENTO DE PROJETOS

PARTE 4: RESOLUÇÃO DE CONFLITOS

Use a tabela desta página para determinar o total de pon­ tos. Insira esse total na linha 4 da planilha na página 199.

PARTE 5: ENTENDIMENTO DAS SUAS ESCOLHAS

a.

b.

c.

Embora você possa ter uma justificativa "legal” para forçar a solução ao seu modo, você deveria considerar o impacto emocional sobre a organi­ zação como resultado de hostilizar o gerente do departamento. Insira dois pontos na linha 5 da planilha. Aceitar os novos requisitos seria um caminho mais fácil se vocé estiver disposto a explicar o aumento dos custos e os atrasos no cronogra­ ma para os outros participantes. Isso certamente agradaria ao gerente do departamento, e pode até mesmo dar a ele a impressão de que ele tem uma posição de poder e que pode sempre resol­ ver os problemas dessa maneira. Atribua quatro pontos na linha 5 da planilha. Se essa situação não pode ser resolvida no seu nível, você não tem escolha a não ser pedir à alta administração para intervir. Nesse ponto você deve ter certeza de que um comprometimento é tudo, menos possível, e de que está disposto a aceitar uma posição de arriscar tudo. Insira dez pontos na linha 5 da planilha se essa foi a sua escolha.

Método

Pontuação

Pessool ou em

Grupo o. 0$ requisitos soo deosoo minto e

Imposição

4

Evasoo ou Suavizoçoo

4

Concessão ou Confronto

4

Suavização, Confronto ou

4

vanos faze» do nosso jeito.

b. Eu pensei sobre isso e você esto talo. Vomos fazer do seu jeito. c Vomos (fauiroproblemo. Tobez

hqo ohemoirvos. d. Deixeme explica por que prarsomos des novos lequsitos.

e. Procure os supervisores do minto

Imposição EfOSòo

4

Suavização ou Concessão

4

seçóo, eles estoo hotondo disso ogero. í. Eu onofsei o proUemo e devo ser

capoz de ceder em alguns dos requisitos.

Total: Pessoal

Total: Grupo

761

d. Pedir a outros gerentes de departamento para intercederem pelo seu caso não é uma boa situ­ ação. Com sorte, a alta administração irá pedir a opinião deles quando decidir sobre a forma de resolver o conflito. Insira seis pontos na linha 5, se essa foi sua escolha, e torça para que os ge­ rentes funcionais não o ameacem, se juntando contra ele. PARTE 6: INFLUÊNCIAS INTERPESSOAIS

a. Ameaçar os funcionários com poder de punição provavelmente não terá qualquer efeito em ab­ soluto, pois o seu conflito é com o gerente do departamento, que nesse momento, provavel­ mente, não poderia se desinteressar mais pela sua avaliação sobre o pessoal dele. Insira zero pontos na linha 6 da planilha se você selecionou essa opção. b. Oferecer recompensas provavelmente vai indu­ zir as pessoas à sua maneira de pensar, desde que elas considerem que você pode manter suas pro­ messas. Promoções e maiores responsabilidades são atribuições funcionais, não de um gerente de projetos. /\ avaliação do desempenho pode ser eficaz se o gerente do departamento der valor à sua opinião. Nessa situação, é duvidoso que ele vá fazer isso. Não atribua pontos para essa res­ posta e anote os resultados na linha 6 da planilha. c. O poder especialista, uma vez estabelecido, é um meio eficaz de obter respeito funcional, contan­ to que seja utilizado por um período relativa­ mente curto de tempo. Para esforços de longo prazo, o poder especialista pode facilmente criar conflitos entre o gerente do projeto e os geren­ tes funcionais. Nessa situação, embora de prazo relativamente curto, o gerente do departamento provavelmente não vai considerá-lo um espe­ cialista, e isso pode ser conduzido para os seus subordinados funcionais. Insira seis pontos na linha 6 da planilha, se essa foi a sua escolha. d. O desafio do trabalho é a melhor forma de ob­ ter apoio e, em muitas situações, pode superar choques de personalidade e discordantias. Infe­ lizmente, o problema ocorreu por causa de quei­ xas por parte do pessoal funcional e é, portanto, improvável que o desafio do trabalho seja eficaz aqui. Atribua oito pontos na linha 6 da planilha se essa foi a seu escolha. e. Pessoas que trabalham em um ambiente de pro­ jetos devem respeitar o gerente do projeto por

762

Gerenciamento de Projetos

causa da autoridade delegada a ele pelos níveis superiores de gestão. Mas isso não significa que vão seguir suas orientações. Quando em dúvida, os funcionários tendem a seguir as orientações da pessoa que assina sua ficha de avaliação, ou seja, o gerente de departamento. Contudo, o ge­ rente de projetos tem a autoridade formal para “forçar” o gerente de linha a aderir ao plano ori­ ginal do projeto. Isso deve ser feito apenas como um último recurso e, aqui, parece que pode ser a

f.

única alternativa. Atribua dez pontos, se essa foi a sua resposta e anote o resultado na linha 6 da planilha. O poder de referência não pode ser obtido da noite para o dia. Além disso, se o gerente do departamento sente que vocé está tentando competir com ele pela amizade de seus subordi­ nados, isso poderá resultar em conflitos tradicio­ nais. Insira dois pontos na linha 6 da planilha se essa era a sua escolha.

APENDICE

SOLUÇÕES PARA O EXERCÍCIO DE LIDERANÇA

SITUAÇÃO 1

Essa técnica pode funcionar se você possuir cre­ denciais comprovadas de liderança. Uma vez que três dessas pessoas nâo trabalharam para você antes, alguma ação é necessária. b. A equipe já deve estar um pouco motivada e um reforço vai ajudar. A construção da equipe deve começar mostrando aos funcionários como eles serão beneficiados. Essa é, geralmente, a melhor abordagem em projetos de longo prazo. (5 pontos) c. Essa é a melhor abordagem, se os trabalhadores já compreendem o projeto. Nesse caso, porém, você pode estar esperando muito dos funcioná­ rios cedo demais. (3 pontos) d. Essa abordagem é muito forte neste momento, uma vez que a ênfase deve estar na construção da equipe. Em projetos de longo prazo, as pes­ soas devem ter a oportunidade de se conhecer primeiro. (2 pontos)

a.

SITUAÇÃO 2

a.

Não faça nada. Não faça escândalo. Isso pode me­ lhorar a produtividade, sem prejudicar o moral.

Veja o impacto sobre a equipe primeiro. Se os outros aceitam Tom como o líder informal por­ que ele trabalhou para você anteriormente, os re­ sultados podem ser muito favoráveis. (5 pontos) b. Isso pode levar a equipe a acreditar que existe um problema quando, na verdade, não existe. c. Isso é duplicação de esforços e pode refletir so­ bre a sua capacidade como um líder. A produti­ vidade pode ser prejudicada. (2 pontos) d. Essa é uma decisão precipitada e pode levar Tom a reagir e tornar-se menos produtivo. (3 pontos) SITUAÇÃO 3

a. Você pode estar sobrecarregando a equipe, dei­ xando que eles façam um grande esforço. A mo­ tivação pode ser afetada e resultará em frustra­ ção. (1 ponto) b. Os membros da equipe esperam que o gerente de projetos seja solidário e dê idéias. Isso reforça o seu relacionamento com a equipe. (5 pontos) c. Essa abordagem é razoável, desde que a sua par­ ticipação seja mínima. Você deve permitir que a equipe evolua sem esperar uma orientação con­ tínua. (4 pontos)

764

Gerenciamento de Projetos

d.

Essa ação é prematura e pode impedir a criativida­ de futura. A equipe pode deixar que você faça tudo.

SITUAÇÃO 4

Se» de fato» o problema existe, uma ação deve ser tomada. Esses tipos de problemas não vão em­ bora por si mesmos. b. Isso vai aumentar o problema e pode torná-lo pior. Poderia demonstrar o seu apoio a um bom relacionamento com sua equipe, mas também pode sair pela culatra. (1 ponto) c. Reuniões privadas deveríam permitir a você rea­ valiar a situação e reforçar as relações com os empregados em forma individual. Você deveria ser capaz de avaliar a magnitude do problema. (5 pontos) d. Essa é uma decisão precipitada. Alterar os cro­ nogramas da equipe pode agravar o problema do moral. Essa situação implica o replanejamen­ to, e não a força. (2 pontos)

a.

SITUAÇÃO 5

A gestão de crises não funciona no gerencia­ mento de projetos. Por que esperar até que ocor­ ra uma crise e depois perder tempo tendo que replanejar? b. Essa situação pode exigir sua atenção imediata. Simpatizar com a sua equipe pode não ajudar se eles estão buscando em você a liderança. (2 pontos) c. Esse é o equilíbrio: a gestão participativa e o pla­ nejamento de contingência. Esse equilíbrio é fun­ damental para essas situações. (5 pontos) d. Isso pode aumentar seriamente o problema, a menos que tenha provas de que o desempenho está abaixo do padrão. (1 ponto)

a.

SITUAÇÃO 6

Os problemas devem ser descobertos e trazidos à superfície para a solução. É vendade que esse pro­ blema pode desaparecer, ou que Bob simplesmente não reconheça que seu desempenho é inferior. b. O feedback imediato é o melhor. Bob deve saber sua avaliação do seu desempenho. Isso mostra seu interesse em ajudá-lo a melhorar. (5 pontos) c. Isso não é um problema da equipe. Por que pe­ dir à equipe para fazer o seu trabalho? O contato direto é o melhor. d. Tal como anteriormente, esse problema é seu, não da equipe. Você poder querer pedir a contri­ buição deles, mas não pode pedir-lhes para fazer o seu trabalho.

a.

SITUAÇÃO 7

George deve estar sofrendo para term inar o outro projeto. Ele provavelmente precisa de um pouco mais de tempo para desenvolver um relatório de qualidade. Deixe-o fazer isso. (5 pontos) b. Ameaçar George pode não ser a melhor opção porque ele já entende o problema. A motivação por meio de ameaças normalmente não é boa. (3 pontos) c. Os outros membros da equipe não devem ser sobrecarregados com isso, a menos que seja um esforço de equipe. d. Tal como anteriormente, este peso não deve ser colocado sobre outros membros da equipe a menos, é claro, que eles se apresentem como voluntários. a.

SITUAÇÃO 8

Não fazer nada em momentos de crise é a pior decisão que pode ser tomada. Isso pode frustrar a equipe a um ponto em que tudo o que você tiver construído pode ser destruído. b. O problema é o adiamento de tarefas, e não o moral. Nesse caso, é improvável que eles estejam relacionados. c. A tomada de decisões em grupo pode funcionar, mas pode ser dificil com restrições apertadas de tempo. A produtividade não pode ser relaciona­ da com o desvio no cronograma. (3 pontos) d. Esse é o momento em que a equipe busca em você uma liderança forte. Nào importa quão boa a equipe seja, seus membros podem não ser capazes dc resolver todos os problemas. (5 pontos) a.

SITUAÇÃO 9

Um tapinha nas costas não vai doer. As pessoas precisam saber quando estão indo bem. b. O reforço positivo é uma boa ideia, mas talvez não por meio de recompensas monetárias. (3 pontos) c. Você forneceu à equipe um reforço positivo e de­ volveu a autoridade/responsabilidade para seus integrantes, para a fase 111. (5 pontos) d. A sua equipe tem demonstrado a capacidade de lidar com autoridade e responsabilidade, exce­ to para essa crise. A liderança dominante não é constantemente necessária. a.

SITUAÇÃO 10

a. b.

A melhor abordagem. Tudo está bem. (5 pontos) Por que perturbar uma boa relação de trabalho e um ambiente saudável? Seus esforços podem ser contraproducentes.

765

APÊNDICE B - SOLUÇÕES PARA O EXERCÍCIO DE LIDERANÇA

c.

Se os membros da equipe têm feito o seu tra­ balho, eles já procuraram por contingências. Por que fazê-los sentir que vocé ainda quer estar no controle? No entanto, se eles não analisaram o

cronograma da fase 111, esse passo pode ser ne­ cessário. (3 pontos) d. Por que perturbar a equipe? Você pode con­ vencê-los de que algo está errado ou prestes a acontecer.

Isso pode ser muito desmoralizante para a equi­ pe, porque os membros podem achar que o pro­ grama existente está prestes a ser cancelado. (3 pontos) d. Isso deve ser de inteira responsabilidade do ge­ rente de projetos. Há situações em que as infor­ mações podem ter de ser retidas, pelo menos temporariamente. (5 pontos) c.

SITUAÇÃO 14 SITUAÇÃO 11

a. Você nào pode assumir um papel passivo quan­ do o cliente identifica um problema. Você deve estar disposto a ajudar. Os problemas do cliente, geralmente acabam por ser os seus problemas. (3 pontos) b. O cliente não está vindo para a sua empresa para discutir a produtividade. c. Isso coloca um enorme peso na equipe, especial­ mente porque é a primeira reuniào. Eles preci­ sam de orientação. d. Reuniões de intercâmbio de informações com o cliente sào de sua responsabilidade e nào devem ser delegadas. Você é o ponto focal de informa­ ções. Isso requer uma liderança forte, especial­ mente durante uma crise. (5 pontos) SITUAÇÃO 12

Um papel passivo vindo de você pode deixar a equipe com a impressão de que nào há urgência. b. Os membros da equipe estào motivados e têm o controle do projeto. Eles devem ser capazes de lidar com isso por si próprios. O reforço positivo ajudará. (5 pontos) c. Essa abordagem pode funcionar, mas pode ser contraproducente, se os trabalhadores acha­ rem que você questiona a capacidades deles. (4 pontos) d. Não exerça uma liderança forte quando a equi­ pe já demonstrou sua capacidade de tomar boas decisões em grupo.

Essa ê uma forma ideal de destruir a interface entre o projeto e a área funcional. b. Isso consome muito tempo, já que cada mem­ bro da equipe pode ter uma opinião diferente. (3 pontos) C. Essa é a melhor abordagem, já que a equipe pode conhecer o pessoal funcional melhor do que você. (5 pontos) d. É altamente improvável que você consiga fazer

a.

isso. SITUAÇÃO 15

a.

b.

c.

a.

SITUAÇÃO 13

a.

b.

Essa ê a pior abordagem e pode causar a perda tanto do trabalho existente quanto de trabalhos posteriores. Isso pode resultar em excesso de confiança e pode ser desastroso se um trabalho posterior não ocorrer.

d.

Essa é a solução mais fácil, mas a mais perigosa se sobrecarregar o resto da equipe com trabalho extra. (3 pontos) A decisào deve ser sua, nào de sua equipe. Você está evitando sua responsabilidade. Consultar-se com a equipe dará apoio à sua de­ cisão. É akamente provável que a equipe queira

que Carol tenha essa chance. (5 pontos) Isso poderia causar um ambiente desmoralizante sobre o projeto. Se Carol ficar irritada, o mesmo pode acontecer com outros membros da equipe.

SITUAÇÃO 16

Essa é a melhor escolha. Você está ã mercê do gerente de linha. Ele pode facilitar um pouco se nào for perturbado. (5 pontos) b. Isso é inútil. Eles, obviamente, já tentaram isso e não tiveram sucesso. Pedir a eles para fazer isso de novo poderia ser frustrante. Lembre-se, o muro está lá há dois anos já. (3 pontos) c. Esta será, provavelmente, uma reunião perdida. Os muros geralmente nào sào permeáveis. d. Isto irá engrossar o muro e pode fazer com que a relação da sua equipe com o gerente de linha se de­ teriore. Isso deve ser usado como último recurso, apenas se as informações de andamento nào pu­ derem ser encontradas de outra forma. (2 pontos)

a.

766

Gerenciamento de Projetos

SITUAÇÃO 17

Esta é uma suposição deficiente. Carol pode nào ter falado com ele ou pode simplesmente ter dado a ele a versão dela sobre o projeto. b. O novo colaborador ainda está isolado dos ou­ tros membros da equipe. Você pode estar crian­ do duas equipes de projeto. (3 pontos) c. Isso pode deixar o novo colaborador desconfor­ tável e fazê-lo sentir que o projeto é controlado por meio de reuniões. (2 pontos) d. Os membros novos sentem-se mais confortáveis em conversas individuais, em vez de ter uma equipe que se junta contra eles. Os resumos de­ vem ser feitos pela equipe, já que o encerramen­ to e a finalização do projeto serão um esforço de equipe. (5 pontos) a.

SITUAÇÃO 18

Isso demonstra a sua falta de preocupação com o crescimento de seus funcionários. Essa é uma escolha ruim. b. Essa é uma decisão pessoal entre vocé e o emprega­ do. Contanto que o desempenho dele não seja afeta­ do, de deve ser autorizado a participar. (5 pontos) c. Isso não é necessariamente um problema aberto à discussão. Você pode querer consultar infor­ malmente o parecer da equipe. (2 pontos) d. Essa abordagem é razoável, mas pode deixar os outros membros da equipe sentirem que você está mostrando favoritismo e que simplesmente quer o consenso deles.

a.

SITUAÇÃO 19

Essa é a melhor escolha. Seus funcionários têm controle total. Não faça nada. Você tem de conside­ rar que os trabalhadores já receberam o feedback. (5 pontos) b. Os trabalhadores, provavelmente, já foram aconselhados pela sua equipe e pelo seu próprio gerente funcional. Seus esforços podem apenas afastá-los. (1 ponto) c. Sua equipe já tem a situação sob controle. Soli­ citar a eles planos de contingência, a essa altu­ ra, pode ter um efeito prejudicial. Eles podem já ter desenvolvido planos de contingência. (2 pontos) d. Um papel de liderança forte agora pode afastar a sua equipe. a.

SITUAÇÃO 20

Uma má escolha. Você, o gerente do projeto, é total mente responsável por todas as informa­ ções fornecidas para o cliente. b. O reforço positivo pode ser benéfico, mas não faz nada para garantir a qualidade do relatório. Seu pessoal pode ficar excessivamente criativo e pode fornecer informações supérfluas. c. Solicitar a contribuição deles tem algum mérito, mas a responsabilidade aqui é realmente sua. (3 pontos) d. Algum grau de liderança é necessário para todos os relatórios. As equipes de projeto tendem a fi­ car dispersas durante a redação do relatório, a não ser que sejam orientadas. (5 pontos) a.

APENDICE

ESTUDOS DE CASOS DORALE PRODUCTS

DORALE PRODUCTS (A)

ÁREA DO GUIA PMBOK® Gerenciamento da Integração do Projeto Gerenciamento do Escopo do Projeto

Areado tema Definição de um Projeto HISTÓRICO

A Dorale Products estava passando por problemas favoráveis de crescimento. Os negócios estavam indo bem. O desenvolvimento do novo produto era visto como a força condutora para o crescimento futuro da empresa. A companhia estava agora gastando significativamente mais dinheiro para o desenvolvimento de novos produ­ tos, ainda que o número de produtos novos chegando ao mercado local fosse significativamente menor do que em anos anteriores. Além disso, alguns desses produtos esta­ vam demorando mais do que o esperado para recuperar os custos de P&D, enquanto outros se tornaram obsoletos muito rapidamente.

A administração admitia que algum tipo de processo estruturado de tomada de decisões teria de ser colocado

em prática, pelo qual a administração poderia ou cancelar antecipadamente um projeto antes que grandes quantida­ des de recursos fossem comprometidas, ou redirecionar esforços para objetivos diferentes. David Mathews foi de­ signado como o gerente de projetos responsável pelo de­ senvolvimento de uma metodologia de desenvolvimento de novos produtos (gerenciamento de projetos) para a Dorale Products.

David entendeu os benefícios de uma metodologia de gerenciamento de projetos especialmente como um processo estruturado de tomada de decisões. Ele serviría como um modelo ou um processo repetitivo, de forma que o sucesso nos projetos pudesse ocorrer repetidamen­ te. A metodologia conteria seções para definição do es­ copo, planejamento, desenvolvimento do cronograma, monitoramento e controle do projeto. Havería também uma seção sobre o papel do gerente de projetos, dos ge­ rentes de linha e dos patrocinadores executivos.

Para tornar a metodologia de gerenciamento de proje­ tos fácil de usar e adaptável a todos os projetos, a metodo­ logia seria construída por meio de formulários, diretrizes, modelos e listas de verificação, em vez de políticas e proce­ dimentos mais rígidos. Isso certamente reduziría o custo

768

Gerenciamento de Projetos

de utilização da metodologia e a tomaria mais fácil de se adaptar a uma infinidade de projetos. Os gerentes de pro­ jetos poderiam, então, decidir se implementariam a meto­ dologia de maneira informal ou de maneira mais formal.

O primeiro esboço da nova metodologia estava con­ cluído e pronto para a revisão do vice-presidente (VP) de operações, que tinha sido designado como patroanador do projeto. Após uma revisão da metodologia, foi realizada uma reunião entre o patrocinador e o gerente do projeto (GP). A Reunião

“Eu li a metodologia. Você espera que a me­ todologia deva ser utilizada em todos os projetos?” GP: “Nós provavelmente poderiamos justificar o uso da metodologia em cada projeto. Isso nos daria um processo decisório muito bem estruturado.” VP: “A utilização da metodologia é cara e talvez nem todos os projetos devam precisar dela. Posso racionar o uso da metodologia em um projeto de S 500.000. Mas, e se o projeto for de apenas S 25.000 ou S 50.000? E se o projeto tiver 30 dias de duração, em vez de nossos nor­ mais 6 a 12 meses de esforço?” GP: “Eu acho que precisamos definir o limite para quando o gerenciamento de projetos deve ser usado." VP: “Eu tenho a preocupação de que devemos de­ finir não apenas quando o gerenciamento de projetos deve ser utilizado, mas também o que é um projeto. Se uma atividade permanece inteiramente em uma área funcional, ainda é um projeto de acordo com a sua definição? Deveriamos também definir um limite sobre quantos departamentos funcionais devem ser envolvidos antes de definirmos uma atividade como um projeto?” GP: “Vou voltar para o esboço e volto a falar com vocé em mais ou menos uma semana.”

VP:

Questões

1. 2.

3.

4. 5.

DORALE PRODUCTS (B)

ÁREA DO GUIA PMBOK® Gerenciamento da Integração do Projeto Gerenciamento do Escopo do Projeto

ÁREA DO TEMA Definição de um Programa Histórico

A Dorale Products tinha acabado de desenvolver uma metodologia de gerenciamento de projetos para o desenvolvimento de novos produtos. Embora a metodo­ logia tivesse sido projetada exclusivamente para o desen­ volvimento de novos produtos, o vice-presidente de ope­ rações acreditava que seriam possíveis outras aplicações para a metodologia. Foi realizada uma reunião entre o gerente de projetos responsável pelo desenvolvimento da metodologia e o vice-presidente de operações. A Reunião

VP:

GP:

VP:

GP: Qual é uma definição razoável de um projeto? Toda atividade é um projeto ou deve hawr um número mínimo de fronteiras funcionais que pre­ cisam ser cruzadas? Se sim. quantas fronteiras? Como podemos determinar quando o geren­ ciamento de projetos deve ser usado e quando uma atividade pode ser tratada de maneira efi­ caz por um grupo funcional sem o uso de ge­ renciamento de projetos? Iodos os projetos precisam de gerenciamento de projetos? Como a utilização de uma metodologia formal de gerenciamenio de projetos requer tempo e dinheiro, qual deve ser o limite “razoável” para a sua utilização?

VP:

GP:

“A empresa investiu muito tempo e dinheiro no desenvolvimento dessa metodologia. Seria uma vergonha se ela não pudesse ser aplicada em outras partes da organização. Como exemplo, deve haver uma uniformidade entre os proje­ tos de desenvolvimento de novos produtos e de sistemas de informação. Podemos utilizar essa metodologia, ou parte dela, tanto para o desen­ volvimento de novos produtos quanto para o desenvolvimento de sistemas de informação?” “Eu não tenho certeza de que possamos fazer isso. Os requisitos para projetos de sistemas de informação sào diferentes, assim como as fases do ciclo de vida. Uma metodologia de geren­ ciamento de projetos comum teria de ser al­ tamente genérica para ser aplicável a todos os tipos de projetos." “Você está me dizendo que teremos de investir mais tempo e mais dinheiro para desenvolver uma família de metodologias?” “A metodologia que nós desenvolvemos pode ser aplicada a todas as nossas atividades, exceto para esforços de tecnologia da informação. To­ dos os nossos projetos são semelhantes, ou no mesmo grupo de domínio, com exceção de Tl. O pessoal de Tl pode precisar de sua própria metodologia e eu compreendo as suas razões para quererem dessa forma.” “Suponho, pelos os seus comentários, que a nos­ sa metodologia existente aplica-se igualmente para programas e projetos. Afinal, um programa não é apenas uma continuação de um projeto?” “Não considerei a aplicação de nossa metodo­ logia tanto para programas quanto para proje­ tos. Deixe-me pensar sobre isso, e volto a falar com você.”

769

APÊNDICE C - ESTUDOS DE CASOS DORALE PRODUCTS

Questões

1.

2. 3.

Parece prático usar uma metodologia de geren­ ciamento de projetos e uma metodologia de de­ senvolvimento de sistemas simultaneamente? Qual é a definição de um programa? (x»mo se difere da definição de um projeto? /X metodologia de gerenciamento de projetos se aplica também tanto a programas quanto a projetos?

DORALE PRODUCTS (C)

ÁREA DO GUIA PMBOK * Gerenciamento da Integração do Projeto Gerenciamento do Escopo do Projeto ÁREA 1)0 TEMA Aplicações do Gerenciamento de Projetos Histórico

A Dorale Products acabou de concluir o desenvol­ vimento de uma metodologia de gerenciamento de pro­ jetos. Embora a metodologia devesse ser utilizada para desenvolvimento de novos produtos, havia uma expec­ tativa de que a metodologia pudesse ser aplicada a outros produtos também. A Reuniõo

VP:

“Nós nos restringimos quanto ao tipo de proje­ tos em que podemos usar nossa metodologia?” GP: “A resposta é sim e não! Toda atividade na empresa, independentemente da área funcio­ nal, pode ser considerada um projeto. Mas nem todos os projetos requerem o uso da metodologia ou mesmo do gerenciamento de projetos.” VP: “Quando tivemos aquelas conversas meses atrás, no início desse processo de desenvolvi­ mento, você me convenceu de que estávamos gerenciando nossos negócios por meio de pro­ jetos. Você está mudando de ideia agora?" GP: “De jeito nenhum. O requisito principal de habilidade para nossos gerentes de projetos é o gerenciamento da integração. Quanto maio­ res os requisitos de integração, maior será a necessidade do gerenciamento de projetos.” VP: “Agora estou realmente confuso. Primeiro você me diz que todos os projetos necessitam de gerenciamento de projetos, e agora você diz que nem todos os projetos precisam da utili­ zação de uma metodologia. O que não estou entendendo aqui?” Questões

I.

Iodos os projetos devem exigir a utilização dos princípios de gerenciamento de projetos?

2. Que tipo de projeto deve ou não exigir o uso de uma metodologia dc gerenciamento de projetos? 3. Como a magnitude dos requisitos de integra­ ção afeta a sua resposta à pergunta anterior? 4. Quais conclusões podem ser tiradas sobre as aplicações do gerenciamento de projetos? DORALE PRODUCTS (D)

ÁREA DO GULA PMBOK * Gerenciamento da Integração do Projeto Gerenciamento do Escopo do Projeto

ÁREA DO TEMA Processos do Gerenciamento de Projetos Histórico

A Dorale Products desenvolveu uma metodologia para o gerenciamento de projetos. O vice-presidente foi designado como o patrocinador do projeto para super­ visionar o desenvolvimento da metodologia de gerencia­ mento de projetos. Era agora o momento de o patrocina­ dor apresentar a metodologia para os níveis executivos de gestão. O vice-presidente se reuniu com o gerente do projeto para preparar as apostilas para as instruções deta­ lhadas ao comitê executivo. A Reunião

VP:

“Examinei a metodologia e estou preocupado porque não posso reconhecer facilmente a es­ trutura da metodologia. Se eu não puder iden­ tificar a estrutura, então como posso efetiva­ mente fazer uma apresentação para os outros executivos?” GP: “As boas metodologias devem ser baseadas em diretrizes, formulários e listas de verifica­ ção, em vez de em políticas e procedimentos. Temos de ter essa flexibilidade para adaptar a metodologia para uma infinidade de projetos.” VP: “Concordo com você. Mas, ainda deve haver alguma estrutura global para o processo de ge­ renciamento de projetos.” GP: “O gerenciamento da integração envolve três áreas de processo, ou seja, a integração do de­ senvolvimento do plano, a integração da exe­ cução do plano e a integração das mudanças no plano. Nossa metodologia é dividida em fases do ciclo de vida, e esses três processos de integração são incluídos em cada fase do ciclo de vida, embora não especificamente aborda­ dos. Tentei usar os princípios do PMBOK . * ” VP: “Deixe-me examinar a metodologia de novo e ver se posso identificar o que você disse.”

770

Gerenciamento de Projetos

Questões

1. O gerente de projetos está correio em sua defi­ nição das áreas do processo de gerenciamento da integração? 2. Pode ser difícil identificar essas áreas de pro­ cesso em cada fase do ciclo de vida? Se sim, então o que podemos fazer para torná-las mais visíveis? 3. O que o vice-presidente deveria dizer em sua apresentação sobre a estrutura da metodologia? DORALE PRODUCTS (E)

ÁREA DO GUIA PMBOK * Gerenciamento da Integração do Projeto Gerenciamento do Escopo do Projeto ÁREA DO TEMA Fases do Ciclo de Vida Histórico

O vice-presidente fez a sua apresentação para os ou­ tros executivos seniores sobre a metodologia. A ênfase foi colocada sobre as 10 fases do ciclo de vida. Os outros exe­ cutivos tinham várias perguntas sobre a utilização de 10 fases para o ciclo de vida. O vice-presidente voltou para o gerente do projeto para outra reunião.

Quem determina quais informações devem ser apresentadas em cada reunião de gate review? 5. A quais perguntas as informações da reunião de gate review devem estar preparadas para responder?

4.

DORALE PRODUCTS (F)

ÁREA DO GUIA PMBOK» Gerenciamento da Integração do Projeto Gerenciamento do Escopo do Projeto ÁREA DO TEMA A Definição de Sucesso Histórico

Quando o comitê executivo fez a revisão final da metodologia de gerenciamento de projetos, identificou a falta de compreensão do que constituiría o sucesso do projeto. A recomendação foi para estabelecer alguns ti­ pos de critérios que permitissem identificar o sucesso do projeto. A Reunião

VP:

GP: A Reunião

VP:’*Os executivos tém preocupações de que dez fases para o ciclo de vida são demais. Você tem dez gate reviews de final de fase, que exigem que a maioria dos nossos executivos compare­ ça. Isso parece excessivo." GP: “Concordo. Quanto mais penso nisso, mais eu acredito que dez fases são demais. Vou gastar a maior parte do meu tempo me preparando para as reuniões de gate review, em vez de ge­ renciar o projeto.” VP: “Outra preocupação de nossos executivos foi o papel e a responsabilidade deles nas reuniões de gate review. A metodologia não é clara a esse respeito.” GP:“Mais uma vez, devo concordar com vocé. De­ veriamos ter um critério estabelecido para o que constitui a aprovação em gate reviews". Questões

1. Quais são os principais benefícios para a utili­ zação de diferentes fases para o ciclo de vida? Há também desvantagens? 2. Quantas fases para o ciclo de vida são adequa­ das para uma metodologia? 3. Qual é o perigo de haver muitas reuniões de gate review?

VP:

GP:

“Temos um problema com a identificação do sucesso em um projeto. Precisamos de mais esclarecimentos.” “Considerei que o cumprimento das entregas estabelecidas pelo cliente constituía o sucesso.” “E se cumprirmos apenas 92% das especifi­ cações? Isso é um sucesso ou um fracasso? E se excedermos nosso processo de desenvolvi­ mento de novos produtos, mas trouxermos mais clientes novos? E se o projeto basica­ mente falhar, mas desenvolvermos um bom relacionamento com o cliente durante esse processo?” “Entendo o que vocé está dizendo. Talvez de­ véssemos identificar as contribuições primá­ rias e secundárias para o sucesso.”

Questões

Qual é a definição padrào de sucesso (ou seja, fatores primários)? Como isso se relaciona à restrição tripla? 2. Quais seriam os exemplos de fatores secundá­ rios de sucesso? 3. Qual seria uma definição razoável de fracasso do projeto? 4. Essas definições e fatores deveríam ser incluí­ dos em uma metodologia de gerenciamento de projetos? 5. Há algum risco em relação à inserção de fa­ tores primários e secundários de sucesso na metodologia? 1.

771

APÊNDICE C - ESTUDOS DE CASOS DORALE PRODUCTS

DORALE PRODUCTS (G)

DORALE PRODUCTS (H)

ÁREA DO GUIA PMBOK * Gerenciamento da Integração do Projeto Gerenciamento do Escopo do Projeto Gerenciamento dos Recursos Humanos do Projeto

zXREA DO GUIA PMBOK® Gerenciamento da Integração do Projeto Gerenciamento do Escopo do Projeto Gerenciamento dos Recursos Humanos do Projeto

ÁREA DO TEMA O Papel do Executivo

ÁREA DO TEMA O Papel dos Gerentes de Linha

Histórico

Embora a alta administração parecesse um pouco satisfeita com a nova metodologia, havia alguma preocu­ pação de que o papel da alta administração tivesse sido mal definido. O vice-presidente considerou que isso tinha de ser abordado rapidamente, para que outros executivos entendessem que têm um papel vital no processo de ge­ renciamento de projetos.

Histórico

A metodologia de gerenciamento de projetos estava finalmente começando a tomar forma. Contudo, embora a estrutura básica da metodologia estivesse em vigor, ain­ da havia algumas lacunas que tinham que ser preenchi­ das. Uma dessas lacunas era um papel bem definido para os gerentes de linha. A Reunião

VP:

A Reunião

“Muitos de nossos executivos não possuem co­ nhecimentos em gerenciamento de projetos e precisam de alguma orientação sobre atuar como um patrocinador de projetos. Sem o esclarecimento desse papel, alguns patrocina­ dores podem ser “invisíveis”, enquanto outros podem tender a se envolver demais. Precisa­ mos de um equilíbrio.” GP: “Compreendo as suas preocupações e concor­ do que alguma descrição de pape) é necessária. No entanto, não vejo como a descrição do pa­ pel possa impedir que alguém se torne invisí­ vel ou autoritário.” VP: “Isso é verdade, mas ainda precisamos de um ponto de partida. Podemos ter de ensiná-los a atuar como patrocinadores.” PM: “Se o patrocinador puder mudar de acordo com a fase do ciclo de vida em que estivermos, então devemos delinear o papel do patrocina­ dor em cada fase.” VP: “Bem pensado. Vamos também nos certificar de definir o papel do patrocinador nas reuniões de gate review.”

VP:

Questões

Qual deve ser o papel principal do patrocinador? O papel mudará com base nas fases do ciclo de vida? 3. É aconselhável que o patrocinador mude com base na fase do ciclo de vida? 4. A delineação do papel na metodologia força­ rá o patrocinador a desempenhar conforme o esperado? 5. Qual deve ser o papel do patrocinador durante as reuniões de gate review? 1. 2.

“Pelo que li sobre gerenciamento de projetos, no começo, é muito difícil conseguir que os ge­ rentes de linha efetivamente apoiem os projetos. Quero que nossos gerentes de linha se tomem totalmente comprometidos com o gerencia­ mento de projetos o mais rapidamente possível.” GP: “Concordo com vocé? Não é bom para um ge­ rente de linha designar as pessoas para um proje­ to e depois não ter nenhum interesse no projeto”. VP: “Acredito que os gerentes de linha têm o po­ der de construir ou destruir um projeto. Sen­ do assim, precisamos deles para compartilhar a responsabilidade depois que designarem os recursos.” GP: “Não sei exatamente como fazer isso. Nào há nenhuma forma em que eu, como um gerente de projetos, possa forçar um gerente de linha a compartilhar comigo a responsabilidade pelo sucesso ou fracasso do projeto.” VP: “Sei que isso vai ser difícil no início, mas acre­ dito que possa ser feito. A metodologia deve definir as expectativas que os executivos têm sobre o papel dos gerentes de linha em cada fase do ciclo de vida, bem como as relações de trabalho em cada fase. Veja se vocé pode con­ seguir com que alguns de nossos gerentes de linha possam ajudá-lo a esse respeito.” GP: “Na maior parte dos nossos projetos, a orien­ tação técnica aos trabalhadores ainda é for­ necida pelos gerentes de linha, mesmo após o empregado ser designado. A maioria dos nos­ sos gerentes de projetos tem uma compreen­ são da tecnologia, não um domínio da tecno­ logia. No entanto, temos alguns projetos em que o know-how técnico está com o gerente do projeto, que deve, entào, fornecer supervi­ são técnica diária. Como faço para cobrir as duas bases na concepção da metodologia?”

Ill

Gerenciamento de Projetos

VP:

“Parece-me que na primeira situação o geren­ te do projeto estaria negociando com o geren­ te de linha pelas entregas e, na segunda situa­ ção, a negociação seria por pessoas específicas. Tenho certeza de que você vai encontrar uma maneira de incorporar isso na metodologia.”

Questões

1.

2.

3.

4.

5.

Uma metodologia deve incluir também as polí­ ticas de seleção de pessoal? Em caso afirmativo, qual seria um exemplo de uma política de sele­ ção de pessoal? Quando um gerente de projetos deve negociar por pessoas, e quando o gerente de projetos deve negociar pelas entregas? Uma política de seleção de pessoal deveria tam­ bém distinguir entre as designações em tempo integral e as designações em tempo parcial? Como uma empresa deve lidar com uma situa­ ção em que os gerentes de linha se recusam a apoiar o gerenciamento de projetos, mes­ mo que isso esteja definido como parte da metodologia? As políticas de seleção de pessoal e o papel da gerência da linha deveríam ser definidos em termos de políticas e procedimentos» ou sim­ plesmente diretrizes?

DORALE PRODUCTS (I)

se o gerente de projetos precisa ou não ter um domínio da tecnologia ou compreensão da tecnologia, olhando para os requisitos do pro­ jeto. Mas as habilidades interpessoais são mais complicadas.” VP: “Não entendo o porquê. Por favor, explique!” GP: “Nomeamos gerentes de projetos para ge­ renciar as entregas, e não as pessoas. Nossos gerentes de linha estão fornecendo significati­ vamente mais orientações diárias aos colabo­ radores designados do que os nossos gerentes de projetos.” VP: “Você está me dizendo que os gerentes de pro­ jetos não precisam de nenhuma habilidade de gerenciamento ou habilidades interpessoais enquanto gerencia um projeto?” GP: “Isso não é realmente o que estou dizendo. Acredito que as habilidades necessárias para ser um gerente de projetos provavelmente são significativa men te diferentes das habilidades necessárias para ser um gerente de linha.” VP: “Concordo! Veja que tipo de lista você pode desenvolver." Questões

1.

2.

3.

ÁREA DO GUIA PMBOK® Gerenciamento da Integração do Projeto Gerenciamento do Escopo do Projeto Gerenciamento dos Recursos Humanos do Projeto

4.

ÁREA DO TEMA Habilidades Interpessoais para os Gerentes de Projetos

5.

Histórico

Com os papéis do gerente de linha e da alta adminis­ tração pouco definidos, a Dorale acreditava que apenas indivíduos com habilidades especializadas e interpessoais se tornariam os melhores gerentes de projetos. A empre­ sa contemplou a elaboração de uma lista de habilidades “universais” necessárias para atuação como um gerente de projetos.

6.

7.

A Reunião

VP:

GP:

“Gostaria de ver uma lista de características pessoais desejadas para gerentes de projetos incluída na nossa metodologia. Certamente isso pode ser feito.” “Acho que podemos definir as áreas de conhe­ cimento com mais facilidade do que as habi­ lidades interpessoais. É mais fácil decidirmos

8.

9.

Que tipos de habilidades interpessoais são ne­ cessárias para ser um gerente de projetos eficaz? Como as habilidades interpessoais de um ge­ rente de projetos diferem das habilidades ne­ cessárias para um gerente de linha eficaz? A sua resposta às duas primeiras perguntas de­ pende do fato de que no gerenciamento de pro­ jetos é necessário se reportar a vários chefes? A lista que você teria criado seria dependente de se o gerente de projetos possui ou não res­ ponsabilidade pela remuneração e salário (ou participação) dos membros da equipe? Por que muitas vezes é difícil para os gerentes de linha experientes se tornar gerentes de projetos em tempo integral? (Ou, em alguns casos, até mesmo gerentes de projeto em tempo parcial?) Alguns gerentes de projetos têm domínio da tecnologia, enquanto outros têm um entendi­ mento da tecnologia. Esse domínio ou coman­ do da tecnologia pode influenciar as habilida­ des interpessoais necessárias para um gerente de projetos? Os requisitos das habilidades interpessoais po­ dem mudar, se o gerente do projeto se concen­ trar nas entregas, em vez de nas pessoas? .Alguém com habilidades técnicas muito fortes também pode ter habilidades interpessoais in­ desejáveis de gerenciamento de projetos? Uma metodologia de gerenciamento de proje­ tos deveria identificaras habilidades interpesso­ ais desejadas de um gerente de projetos ou isso deveria somente ser feito de projeto a projeto?

773

APÊNDICE C - ESTUDOS DE CASOS DORALE PRODUCTS

DORALE PRODUCTS (J)

Questões

1.

ÁREA DO GUIA PMBOK® Gerenciamento da Integração do Projeto Gerenciamento do Escopo do Projeto Gerenciamento dos Recursos Humanos do Projeto ÁREA DO TEMA Políticas e Procedimentos de Seleção de Pessoal Para o Projeto

2.

3.

Histórico

A Dorale esperava que surgissem conflitos durante a seleção de pessoal para os projetos. Havia alguma preo­ cupação sobre se uma metodologia de gerenciamento de projetos deveria ou não conter as políticas e procedimen­ tos para seleção de pessoal para os projetos.

4.

A Reunião

5.

VP:

“Precisamos de algum tipo de orientação em nossa metodologia para a seleção de pessoal para os projetos. Se não temos políticas e proce­ dimentos a esse respeito, então não há nenhu­ ma garantia de que o gerente de projetos rece­ berá recursos de forma adequada e oportuna.” GP: “Não tenho certeza de que sei como fazer isso. Neste momento, estamos defendendo que os nossos gerentes de projetos negociem com os gerentes de linha pelas entregas, e não pelas pessoas. É, então, da responsabilidade do ge­ rente de linha fornecer recursos adequados para realizar o trabalho”. VP: “Concordo com você, mas ainda precisamos de orientação. Os gerentes de projetos devem deixar claro o que o trabalho exige especifi­ camente para que o gerente de linha ofereça os recursos adequados. Nào quero entrar em uma situação de conflito na qual o gerente de projetos culpe o gerente de linha por não fornecer os recursos adequados e o gerente de linha culpe o gerente de projetos por definir impropriamente o escopo.” GP: “Isso parece mais com aceitar a responsabili­ dade do que com seleção de pessoal.” VP: “Talvez sim, mas está relacionado com a sele­ ção de pessoal. Quero que os gerentes de linha forneçam aos projetos pessoas com os níveis de qualificação necessários para cumprir os limites orçamentais. Não podemos permitir ter projetos que estejam carregados com os trabalhadores de salários mais altos.” GP: “Essa é uma boa ideia. Também pode ser acon­ selhável ter alguma política que obrigue os ge­ rentes de projetos a liberar os trabalhadores designados conforme a sua conveniência, de modo que eles possam ser captados para ou­ tros projetos.”

6.

7.

É apropriado para uma metodologia de geren­ ciamento de projetos conter as políticas e pro­ cedimentos sobre a seleção de pessoal para o projeto? As políticas e procedimentos de seleção de pes­ soal deveriam ser direcionadas para os gerentes de projetos, gerentes de linha ou ambos? Os patrocinadores de projetos devem ser envoi vidos nas decisões que envolvem a seleção de pessoal para o projeto? Se sim, qual é especifi­ camente o seu envolvimento e para a seleção de pessoal para quais posições? Como vocé desenvolve uma política que “force” um gerente de projetos a liberar as pessoas para outros projetos, considerando que elas não se­ jam mais necessárias ao projeto já existente? A seleção de pessoal para o projeto é uma deci­ são de “responsabilidade”? Ê de responsabilidade do gerente de projetos ou do gerente de linha definir adequadamente o nível de habilidades necessário para completar uma tarefa? As políticas de seleção de pessoal devem ser aplicadas ao pessoal de tempo integral, ao pes­ soal de tempo parcial ou a ambos?

DORALE PRODUCTS (K)

ÁREA DO GUIA PMBOK® Gerenciamento da Integração do Projeto Gerenciamento do Escopo do Projeto Gerenciamento dos Recursos Humanos do Projeto ÁREA DO TEMA O Escritório de Projetos/Programas Histórico

A metodologia desenvolvida pela Dorale focava em projetos relativamente pequenos com duração de tempo inferior a 18 meses. A mesma metodologia poderá ser uti­ lizada em grandes projetos? A Reunião

VP:

“A maioria dos nossos projetos tem requisi­ tos de mào de obra de 10 a 20 pessoas com duração de tempo de 18 meses ou menos. Na semana passada, na reunião do comitê execu­ tivo, nós aprovamos vários projetos de grande porte que podem ser executados por três anos ou mais e demandam mais de 40 pessoas a tempo integral. Como vamos gerenciar esses projetos?" GP: “Presumo que você esteja falando sobre pro­ jetos que serão gerenciados por um escritório de projetos, em vez de simplesmente por um gerente de projetos.”

774

Gerenciamento de Projetos

VP:

“Em grandes projetos, o gerente de projetos é mais um gerente do escritório de projetos do que um gerente de projetos. Nossa metodologia não deve discutir também o papel de um escritório de projetos e do gerente do escritório de projetos?”

5.

6.

Questões

1. Quais critérios devem existir na decisão de quando usar um escritório de projetos em opo­ sição a apenas um gerente de projetos? 2. As responsabilidades de gerenciamento da inte­ gração de um gerente de projetos são diferentes das de um gerente de projetos? 3. O que é um escritório de projetos? 4. Qual é o papel de um gerente do escritório de projetos?

7.

8.

Os membros de um escritório de projetos po­ dem ser designados em tempo parcial ou de­ vem ser designados em tempo integral? Se os trabalhadores são designados em tempo integral para um escritório de projetos, eles po­ dem ainda se reportar administrativamente aos seus gerentes de linha? Os colaboradores designados ao escritório de projetos podem ser designados em tempo in­ tegral e o gerente de projetos ser designado em tempo parcial? As políticas de seleção de pessoal para o pro­ jeto podem ser definidas por um escritório de projetos ou devem ser especificadas pelo projeto?

APENDICE

SOLUÇÕES PARA OS ESTUDOS DE CASOS DORALE PRODUCTS

ESTUDO DE CASO (A)

1. Um projeto é uma atividade única, com um ob­ jetivo bem definido.com restrições, que consome recursos e que é, geralmente» multifuncional. O projeto geralmente fornece um único produto, serviço ou entrega. 2. Geralmente, nào há número mínimo de frontei­ ras que precisem ser cruzadas. 3. Normalmente, isso é baseado na quantidade de integração necessária. Quanto maior a quanti­ dade de integração, maior será a necessidade do gerenciamento de projetos. 4. Todos os projetos poderiam se beneficiar do uso de gerenciamento de projetos, mas, em alguns projetos muito pequenos, o gerenciamento de projetos pode não ser necessário. 5. Os limites razoáveis para a utilização da metodo­ logia de gerenciamento de projetos são baseados no valor monetário, no risco, na duração e no número de fronteiras funcionais cruzadas. ESTUDO DE CASO (B)

1. Em muitas empresas, uma metodologia corpo­ rativa de projetos pode ser impraticável. Pode

existir uma metodologia para o desenvolvimento de um produto ou serviço únicos, e outra para o desenvolvimento dc sistemas. 2. Um programa é geralmente mais longo em du­ ração do que um projeto e é composto de vários projetos. 3. Metodologias de gerenciamento de projetos sào aplicáveis tanto aos programas quanto aos projetos. ESTUDO DE CASO (0

1. Todos os projetos devem utilizar os princípios do gerenciamento de projetos, mas podem não precisar usar a metodologia de gerenciamento de projetos. 2. Os projetos que nào exigem a metodologia são aqueles que são de curta duração, baixo valor monetário e que permanecem dentro de um de­ partamento funcional. 3. Metodologias são geralmente necessárias para todos os projetos que precisam de integração em grande escala. No entanto, se o custo asso­ ciado com o uso da metodologia for baixo ou se a metodologia não for complexa, então pode-se

776

Gerenciamento de Projetos

defender que a metodologia deva ser utilizada em todos os projetos. 4. Esse é um argumento válido de que os princípios do gerenciamento de projetos deveríam ser apli­ cados a todos os projetos, independentemente das restrições. ESTUDO DE CASO (D)

1. O gerente de projeto está parcialmente correto em sua definição sobre o processo de gerencia­ mento da integração. A definição do gerente de projetos está mais alinhada com a versão do Guia PMBOK® 2000 do que com a versão de 2004. 2. Pode ser difícil identificar esses processos em cada fase do ciclo de vida. No entanto, uma boa metodologia de gerenciamento de projetos resol­ verá esse problema. 3. Uma metodologia de gerenciamento de projetos é baseada em formulários, diretrizes, modelos e listas de verificação, e é aplicável a uma variedade de projetos. Quanto mais estrutura for inserida na metodologia, tem-se um maior controle, mas isso pode levar a um resultado prejudicial de li­ mitação da flexibilidade que as equipes de proje­ tos precisam ter uma metodologia que possa ser adaptada a uma variedade de projetos. ESTUDO DE CASO (E)

1. Os principais benefícios são a padronização e o controle do processo. A desvantagem ocorre quando isso é feito com políticas e procedimen­ tos, em vez de com formulários, diretrizes, mode­ los e listas de verificação. 2. A maioria das metodologias não possui mais do que cinco ou seis fases do ciclo de vida. 3. Com demasiadas reuniões de gate review, o geren­ te de projetos passa a maior parte de seu tempo gerenciando essas reuniões, em vez dc gerenciar o projeto. 4. As partes interessadas que estão presentes nas reuniões de gate review determinam quais in­ formações devem ser apresentadas. Modelos e listas de verificação podem ser estabelecidos para as reuniões de gate review, bem como para os estágios. 5. No mínimo, as questões abordadas devem in­ cluir: (1) Onde estamos hoje? (2) Onde vamos parar? e (3) Que problemas especiais existem? ESTUDO DE CASO (F)

1. A definição padrão do sucesso é dentro do pra­ zo, do custo, do escopo ou da qualidade e aceito pelo cliente. 2. Fatores de sucesso secundários podem incluir a rentabilidade e trabalho posterior. 3. F. mais difícil definir o fracasso como oposição ao sucesso. As pessoas acreditam que o fracasso

é um cliente insatisfeito. Outros acreditam que o fracasso é um projeto que, quando concluído, não proporcionou nenhum valor ou aprendizagem. 4. Absolutamente, mas podem ser modificados para atender a um determinado projeto ou às ne­ cessidades de um determinado patrocinador. 5. Pode resultar em falta de flexibilidade. ESTUDO DE CASO (G)

1. O principal papel do patrocinador é ajudar o GP a resolver problemas que podem estar fora do controle do GP. 2. O papel do patrocinador pode e vai mudar com base na fase do ciclo de vida. 3. Há duas escolas de pensamento, alguns acreditam que a mesma pessoa deve permanecer como pa­ trocinador para a duração do projeto, enquanto outros acreditam que o patrocinador pode mu­ dar, com base na fase do ciclo de vida. Há vanta­ gens e desvantagens em ambas as abordagens e muitas vezes isso é baseado no tipo de projeto e na importância do cliente. 4. Não necessariamente, mas é um bom ponto de partida para explicar aos novos patrocinadores o seu papel e a sua responsabilidade. 5. Verificar se a fase atual foi concluída corretamen­ te e autorizar o início da próxima fase. ESTUDO DE CASO (H)

1. As boas metodologias identificam as políticas de seleção de pessoal. Por exemplo, um gerente de projetos pode ter o direito de identificar o nível de habilidades desejado para os trabalhadores, mas isso pode ser aberto às negociações. 2. Os gerentes de projetos que possuem um domí­ nio da tecnologia normalmente negociam pelas pessoas, enquanto os gerentes de projetos sem um domínio da tecnologia negociam pelas entregas. 3. Essa questão é argumentativa porque pode en­ volver uma discussão sobre o esforço versus a duração. O gerente de linha pode carregar mais peso nesse sentido do que o gerente de projetos, uma vez que isso pode muito bem estar baseado na disponibilidade de pessoal. 4. É por isso que os patrocinadores de projetos existem, para atuar como árbitros, quando há di­ vergências e para certificarem-se de que exista o apoio da gerência de linha. 5. As diretrizes sào sempre melhores do que as po­ líticas e procedimentos, pelo menos aos olhos do autor. ESTUDO DE CASO (I)

I. As habilidades essenciais incluem tomada de de­ cisões, comunicação, resolução de conflitos, ne­ gociações, orientação, facilitação e liderança sem a obtenção de autoridade.

APÊNDICE D - SOLUÇÕES PARA OS ESTUDOS DE CASOS DORALE PRODUCTS

2. As habilidades da gerência de linha, muitas ve­ zes, focam nas relações superior-subordinado, enquanto as habilidades de GP focam na cons­ trução de equipes, em que as pessoas da equipe não estão necessariamente sob o controle do GP (e podem estar, de fato, superiores ao GP na hierarquia). 3. A subordinação a vários chefes também é uma preocupação porque o controle e a supervisão do colaborador podem estar distribuídos por vários indivíduos. 4. /\ administração de salários e remunerações é um fator importante. Se o GP tiver essa responsabi­ lidade, os colaboradores vão se adaptar ao GP, porque ele/ela tem uma influência sobre a revisão do desempenho e o salário. Sem essa responsa­ bilidade, o GP pode ser forçado a adaptar-se aos colaboradores, e não vice-versa. 5. Gerentes de linha estão habituados a gerenciar com autoridade, ao passo que os gerentes de pro­ jetos, não. 6. Quando um GP tem um domínio de tecnologia, ele pode se alinhar mais próximo às habilidades de um gerente de linha, do que de um GP. 7. Os GPs geralmente negociam pelas entregas quando não têm um domínio de tecnologia e isso pode influenciar as habilidades interpessoais necessárias para um determinado projeto. 8. Sim. 9. A identificação deve ser apenas em termos ge­ rais, para que possa ser aplicável a uma variedade de projetos.

111

ESTUDO DE CASO (J)

1. Sim, mas apenas em termos gerais. 2. Ambos, de forma a minimizar os conflitos. 3. Patrocinadores geralmente exercem um papel ativo na seleção do GP, mas têm um papel passi­ vo na seleção de pessoal funcional de modo a não usurpar a autoridade de seus gerentes de Unha. 4. Não há real mente um modo eficaz de fazer isso que não seja encerrando alguns dos números de cobrança funcionais. 5. Sim, se obrigado pela alta administração. 6. O GP pode solicitar qualquer nível de habilidade desejado, mas a decisão final quase sempre fica com o gerente de linha. 7. Ambos. ESTUDO DE CASO (K)

1. O tamanho do projeto, a duração, o risco e a im­ portância do diente. 2. Elas são as mesmas e podem até ser mais detalhadas. 3. Uma equipe de gerenciamento de projetos. 4. O papel do GP é coordenar e integrar as ativida­ des da equipe de gerenciamento do projeto. 5. Eles podem estar em tempo parcial ou integral, com base nas necessidades do projeto. 6. Sim. Um exemplo disso pode ser o especialista em qualidade designado ao projeto. 7. Sim. 8. As políticas podem ser estabelecidas para a sele­ ção de pessoal de uma equipe de um escritório de projetos, mas elas podem ser específicas da em­ presa ou do cliente.

APENDICE

ALINHAMENTO DO GUIA PMBOK® AO TEXTO

Este apêndice faz uma referência cruzada das seções da quinta ediçào do Guia PMBOK® com este livro. Nem todas as seções do Guia PMBOK® sào abordadas neste livro, apenas as principais categorias.

GUIA PMBOK

PÁGINA

2.1.5

608

2.2.1

9,13,266,295

2.2.3

5

2.3

130

2.4

49,50, 88,328, 368, 391,452

GUIA PMBOK®

PÁGINA

1.0

667

1.2

2

1.3

2,44

3.0

667

1.4.1

42,114

3.4

283,355,358,638

1.4.3

18,

3.6

466,527,529

1.4.4

4.0

1.5

87,127,143,685 no 38,

9,31,600, 269, 283, 286, 295, 346, 355, 358,361,527

1.5.2

16,

1.6

143

4.1

360

1.7

326,366

4.1.1

44

1.7.2

3,6,

4.1.2

346

4.1.1.2

453,455

16, 20, 328, 452, 667

4.3.2

350

4.4

351,470

2.1.1

44,49,60

4.5

60,366,369

2.1.3

3,11,12,71

4.6

351

2.0

780

Gerenciamento de Projetos

GUIA PMBOK®

PAGINA

GUIA PMBOK®

PAGINA

5.0

323, 326, 332, 355, 358,527,679

8.1.1

635,643

8.1.2.2

645

5.1.2.1

330

8.1.2.5

640

5.23.2

365

8.1.3.1

645

5.3

283, 323, 332, 333, 337,347

8.2

644

53.2.2

347

8.2.2.2

645

5.33.1

333

8.3

647

5.4

338

8.3.2

648

5.4.2.1

344

8.3.2.1

5.6

302,363

648, 649, 650, 651, 653,654

8.3.2.2

656

6.0

227,228,338,381

Ó.2.2.2

444

9.0

6.23.2

384,400

6.2.33

381

6.3

381, 383, 384, 385, 386

10, 15,71, 109,114. 123, 130, 134, 145, 145, 216, 227, 269, 286, 287, 288, 295. 419,659

9.1

110

63.2

383,386,389

9.1.2

10, 149,152

63.2.1

398,399,400

9.1.3

147

63.2.2

386,388

9.2

123,134

6.3.23

400

9.2.1

111

6.4.2.4

427

9.3

113,146,154,161

6.4.23

402

9.3.1.1

111

6.5

392,393,595

9.3.2.1

114

6.5.2

427,429

9.4

145,233

63.2.4

392,393

9.4.2.3

233,237,238,239

6.6.2

385,390

9.3.2.6

249, 253,257

6.6.23

405

9.4

249,288

6.Ó.2.4

390

6.6.2.7

390,394

10.0

6.7.1.4

419,420

169, 173, 195, 216, 286,287,419

10.1.1.5

420

7.2.1

435, 437, 444, 449, 452

10.2

170, 172

7.2.2

429,450

10.1.3

171

7.2.2.6

441

10.1.3.2

195

73.2.1

468,470

10.2.2.4

471

7.3.2

403,474

10.2.2.5

491

73.2.4

474

10.3.2.1

173

7.3.3

485

10.4

170

7.4

463,471,494

11.0

228,444

11.2

445, 580

635, 636, 637, 642, 643,657

11.4.2.2

455,456

II.5.3.1

578

637,660

11.6

582

7.4.2

8.0 8.1

781

APÊNDICE E - ALINHAMENTO DO GUIA PMBOK® AO TEXTO

GUIA PMBOK®

PÁGINA

12.0

537,607,608

12.1

608,609

1.

12.1.1.3

620

2.

12.1.1.7

620

12.1.1.9

615,618

12.1.2.1

610

12.1.3.2

333,337,609

12.2

611

12.2.1.4

612

12.2.2.1

612

12.2.2.5

612

12.2.3.1

613,614

12.3

537,620

12.3.2.1

443

Esta seção do apêndice faz referência cruzada a algumas figuras. GUIA PMBOK®

Figura 2-3

PÁGINA

Há várias maneiras de estudar para o Exame PMP® do PMI®. O autor recomenda a seguinte abordagem:

3.

4.

Algumas das fontes mencionadas anteriormente para as questões práticas podem ajudar muito o processo de aprendizagem. Por exemplo, o software fornecido pelo International Institute for Learning permite ao usuário:

•

Figura 2-4 Figura 2-5 Figura 5-10 Figura 5-11 Figura 10-4

Leia um capítulo de uma área de conhecimen­ to específica no Guia PMBOK®. Então, leia os capítulos deste livro que corres­ pondem à área de conhecimento. Em seguida, volte a ler a área de conhecimento do Guia PMBOK® por uma segunda vez. Ge­ ralmente as coisas se encaixam melhor após a segunda leitura do Guia PMBOK®. Agora é hora de medir o que você aprendeu. Responda às perguntas de múltipla escolha no final do(s) capítulo(s) em que as informações sobre a área de conhecimento foram encon­ tradas. Colete quaisquer questões práticas que você puder encontrar, como as do caderno de exercícios que acompanha este livro. Quanto mais questões você responder, mais preparado você estará para passar no exame.

• •

Testar todas as questões em uma área de conhecimento Testar todas as questões em uma área de domí­ nio, como a iniciação do projeto Testar todas as questões relacionadas a uma seção específica do Guia PMBOK®, como a Seção 3.2.