Gerenciamento de Projetos-DarkMode [1 ed.] 8521208413, 9788521208419

Citation preview

TRADUÇAO DA DECIMA PRIMEIRA EDIÇAO AMERICANA

GERENCIAMENTO DE

PROJETOS Uma Abordagem Sistêmica para Planejamento

Programação e Controle

KERZNER, Ph.D

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 para 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 em 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 dc 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 dc maneira rentável

14 Medir o progresso periodicamente

15. Utilizar o software dc gerenciamento dc projetos como ferramenta eficaz ou às habilidades interpessoais

não como um substituto ao planejamento

16 Instituir um programa dc 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 Pedro so Alvarenga. 1245. 4° andar

04531 -934 - São Paulo - SP - Brasil Tel 55 11 3078 5366 editora9blucher.com.br vasv/

blucher.com. br

Ficha Catalográftca Krrzncr. Harold Gerenciamento rio projetos: uma abordagem sistêmica para planejamento, programação e controle / Harold Krrzncr. 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.

É proibida a reprodução total ou parcial

ISBN 978-85-212-0842-6 (eletrônico) Título origina): Project management: a systems approach to planning, scheduling and controlling

I. Administração de projetos I. Título 11. Gama Neto, João 111. Prado, Joyce I.

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

Todos os direitos reservados pela Editora Edgard Blucher Ltda.

15-0623

CDD 658.404

í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 podería 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 portfolio 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 learning, 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 críticas 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 10

1 1

Introdução

1 19

1

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 1 4

5

Gerenciamento de Projetos Internacionais

121

Engenharia Simultânea Uma Abordagem de Gerenciamento de Projetos

1.22

5

1 23

A Interface entre o Gerente de Projetos

Definição do Papel do Gerente de Projetos 9

1 6

Definição do Papel do Gerente Funcional

1 7

Definição do Papel do Colaborador Funcional

1 8

Definição do Papel do Executivo

12

1 9

Como Trabalhar com Executivos

12

1.10 Govemança/Palrocimo por Comitês

1)3

114

25

Dicas de Estudo para o Exame de Certificação

Exercícios

10

26

27

Estudo de Caso

Williams Machine Tool Company 29

11 2

13

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

O Gerente de Projetos como Agente

2.0

Introdução

de Planejamento

2.1

Administração Geral dos Sistemas

2.2

Gerenciamento dc Projetos 1945-1960

32

O Lado Negativo do Gerenciamento

2.3

Gerenciamento dc Projetos 1960-1985

33

de Projetos

2.4

Gerenciamento de Projetos: 1985-2012

36

2.5

Resistência a Mudanças 38

2.6

Sistemas. Programas e Projetos

15

Campeões do Projeto

16

16

Organizações Orientadas a Projetos e Organizações Não Orientadas a Projetos

1.15

Xfalor Agregado

25

25

cm Gerenciamento dc Projetos * PMl

1.5

1.12

24

120

c o Gerente de Linha 6

111

Gerenciamento de Projetos

16

Uma Definição

O Marketing nas Organizações Orientadas a Projetos

42

Gerenciam ento de Projetos: Um a Definição

20

Classificação de Projetos

1.17

A Posição do Gerente de Projetos

118

Diferentes Visões sobre Gerenciamento 21

31

2 7 Gerenciamento de Produtos versus

18

1.16

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

47

2.12

O Processo Stage-Gate 49

2 13

Ciclos de Vida do Projeto

2 14

Reuniões de Gate Review

3.17

cm Gerenciamento de Projetos * PM1

Exercicios

Coronado Communications

Gerenciamento de Engajamento

2 16

Metodologias de Gerenciamento de Projetos

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 PMP-

Estudo de Caso

Criando uma Metodologia

4 4

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

4.5 4.6

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

65

Exercícios 67

4 7 4 8

68

Introdução

Desenvolvimento de Posições de Integração 75

3 4 Organização Linha-Staff(Coordenador

dc Projetos) 3 6

Modelo Organizacional Matricial

Modificação das Estruturas Matriciais

3.8

As Matrizes Forte. Fraca c Balanceada

3 9

3.12 3 13

84 86

Centro de Competências em Gerenciamento

dc Projetos 87 3 10 Sobreposição Matricial 3 11

78

79

3.7

87

Seleção do Modelo Organizacional

88

A Estruturação da Pequena Empresa

91

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

Gerenciamento de Projetos por I,’mdades

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)

123

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

71

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

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

ESTRUTURAS ORGANIZACIONAIS 71

3.5

110

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

Pensamento Sistêmico 64

3.3

O Ambiente de Seleção de Pessoal

4.2

2.21

30

109

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

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

Uma Definição 55 Metodologias Empresariais

de Gerenciamento de Projetos 2 19

101

Jones and ShephardAccountants, Inc.

2 15

2 18

101

Estudos de Caso

50

(Encerramento do Projeto) 53

2 17

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

co Gerente

6.6

163

232

Estudo de Caso

Os Trabalhadores Relutantes 232

165

7 CONFLITOS

166

As Armadilhas de Gestão

5.15

.As Com umcaçÕcs

5 16

As Reuniões de Avaliação do Projeto

517

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

74

Resolução de Conflitos

7.5

Entendimento dos Conflitos de Origem

177

233 233

183

235 237

186 191

237

76

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 dc Projetos PMI *

192

Exercícios

240

241

Estudos de Caso

195

Programação das Instalações na Mayer

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 de Estudo para o Exame de Certificação

195

196

cm Gerenciamento dc I’rojctos PM1 *

198

Manufacturing

243

Telestar International

243

Tratamento de Conflitos no Gerenciamento

199

de Projetos

244

200 8 TÓPICOS ESPECIAIS

201

Estudos de Caso

O Projeto Trophy

234

Superior. Subordinada e Funcional

5 26

Exercícios

231

em Gerenciamento de Projetos PMI®

Exercícios

161

5.14

Negativas

160

Dicas de Estudo para o Exame de Certificação

207

249

8.0

Introdução

81

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

A Pnma-Dona 212

às Equipes dc Projetos

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

Megaprojelos 261

86

Moralidade. Ética c Cultura Corporativa

87

Responsabilidades Profissionais

ADMINISTRAÇÃO DO SEU TEMPO

88

Parcerias Internas

265

E ESTRESSE 227

8.9

Parcerias Externas

266

60

Introdução

8.10

Treinamento c Capacitação

61

Entendimento da Administração do Tempo 227

8 11

Equipes Integradas de Produto/Projeto

6.2

Ladrões de Tempo

8.12

Equipes Virtuais de Projetos

63

Formulários para Administração do Tempo

8.13

Projetos de Avanço

8.14

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

Questionário Motivational

221

227

228

6.4

Adm imstração Eficaz do Tempo

65

Estresse e Esgotamento

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

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

em Gerenciamento de Projetos * PMI

Exercícios

Isso é Fraude?

274

280

9 AS VARIÁVEIS PARA O SUCESSO

283

9.0

Introdução

9.1

Como Prever o Sucesso do Projeto

9.2

A Eficácia no Gerenciamento dc Projetos

9.3

Expectativas

9.4

Lições Aprendidas

9.5

Entendimento das Melhores Práticas

9.6

Melhores Práticas versus

283

286

328 330 332

332

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

Dicas de Estudo para o Exame de Certificação em Gerenciamento de Projetos PMP

Exercícios

326

1110 As Especificações do Projeto

283

287

Práticas Comprovadas 9.7

325

293

346

1116 O Papel dos Executivos no Planejamento

348

1117 O Ciclo de Planejamento 349 1118 Autorização de Planejamento do Trabalho

293

Estudo dc Caso

1119 Por que os Planos Fracassam? 11 20 Interrupção dc Projetos

Radiance International 293

350

350

351

1121 Como Lidar com Finalizações c

10 COMO TRABALHAR COM EXECUTIVOS 295

100

Introdução

101

O Patrocinador do Projeto

10 2

295 295

Como Lidar com as Discordancies com

o Patrocinador

Transferencias dc lYojctos 351 11.22 Cronogramas e Gráficos Detalhados

352

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

355

1124 O Plano do Projeto

355

11.25 Planejamento Total do Projeto

302

10 3

A Crença Coletiva

10 4

O Campeão dc Saída

358

II 26 O Termo de Abertura do Projeto

303 303

11 27 Linhas dc Base do Projeto

360

362

10.5

Os Representantes Internos 304

11 28 Verificação e Validação

106

Gerenciamento do Relacionamento

11 29 Matriz dc Rastrcabilidade dc Requisitos

com as Partes Interessadas

11 30 Controle de Gestão 366

305

107

Política

10.8

Dicas de Estudo para o Exame de Certificação

365

1131 A Interface entre o Gerente de Projetos

310

em Gerenciamento de Projetos PM1 *

Exercícios

364

311

311

c o Gerente dc Linha 11 32 Paralelismo

366

368

11.33 Gerenciamento dc Configuração

369

11 34 Metodologias dc Gerenciamento de Projetos

Estudos de Caso

Corwin Corporation

3 14

Pnonzação de Projetos

da Empresa

11 35 Auditorias de Projetos

320

O Patrocinador Irresponsável

320

Introdução

ill

Xâlidação das Prem issas

371

12 TÉCNICAS DE PROGRAMAÇÃO DE REDE

323

11.0

em Gerenciamento de Projetos PMT®

Exercícios 373

321

11 PLANEJAMENTO

371

11 36 Dicas dc Estudo para o Exame de 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 Overíiead 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

445

nas Estimativas do Projeto

402

444

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

12 16 Entendimento do Software dc Gerenciamento

446

14 19 0 Custo do Ciclo de Vida (LCC)

449

12 17 Características dc 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 12 20 Corrente Critica

404

cm Gerenciamento de Projetos * PMI

451

Orçamento de Capital 453 14 22 Período de PqyòflcF 453

405

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

Exercícios

14 23 O Valor do Dinheiro no Tempo

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

Estudos de Caso 4 14

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

de Apresentação 13.5

15 CONTROLE DOS CUSTOS 426

Dicas de Estudo para o Exame de Certificação 426

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

14 0

Introdução 427

14 1

Estratégias Globais dc Prccificação

14 3

14.4

Tipos de Estimativas

458

O Problema de Estimativa

424

Redes e Diagramas Lógicos

427

428

429

Processo de Precificação

457

Estudo de Caso

420

cm Gerenciamento de Projetos * PMI

14.2

456

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

13 GRÁFICOS IX) PROJETO 419

13 4

454

14.25 Taxa Interna dc Retomo (TIR)

Crosby Manufacturing Corporation

453

14 24 Valor Presente Liquido (VPL) 454

406

408

130

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

460

463

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

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

de Monte Cario

488

563

1511 O Critério da Contabilidade de Materiais 490

1712 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 15 17 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®

511

Teloxy Engineering (A)

591

Teloxy Engineering (B)

591

de Risco

O Período na "Geladeira " 521

592

18 CURVAS DE APRENDIZAGEM

522

Problemas no Paraíso 523

16 ANÁLISE DE COMPENSAÇÕES EM UM AMBIENTE DE PROJETO

525

595

18 0

Introdução

18 1

Teoria Geral

18 2

O Conceito dc Curva dc Aprendizagem

18 3

Representação Gráfica

18 4

Palavras-Chave Associadas com Curvas

595 595

Introdução

16 1

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

18 5

16 2

Os Contratos e Suas Influências em Projetos

18 6

Fontes de Experiência

18 7

Desenvolvimento de Medidas

16 4 16 5

525

Preferências de Compensações nos Setores

Conclusão

537

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

17 0 Introdução 541 17 1 Definição de Risco

598

599

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

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

543

18 13 Preços e Experiência

17.2

Tolerância aos Riscos 544

17.3

Definição de Gerenciamento de Riscos

17.4

Certeza. Risco c Incerteza

17.5 17.6

Processos dc Gerenciamento dos Riscos Planejar o Gerenciamento

dos Riscos (11.1)

de Aprendizagem 598 A Curva Média Cumulativa

de Inclinação 60)

539

17 GERENCIAMENTO DE RISCOS

17 7

537

596

597

16 0

16.3

585

O Departamento de Gerenciamento

Exercícios 512 Estudos de Caso Franklin Electronics

582

17.19 Dicas dc Estudo para o Exame dc 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

545

18 14 .Arma Competitiva

604

604

605

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

545

cm Gerenciamento dc Projetos PMI *

549

605

Exercícios 606

549

Identificação dos Riscos (11.2)

19 GERENCIAMENTO DE CONTRATOS

550

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

A Condução das Aquisições

21 DESENVOLVIMENTOS MODERNOS EM

GERENCIAMENTO DE PROJETOS

Conduzir as Aquisições Solicitar Respostas dos Fornecedores

19.5

611

612

Conduzir as Aquisições Selecionar

Introdução 667

21.1

O Modelo dc Maturidade cm Gerenciamento de Projetos (PMMM)

Fornecedores 613 19.6

Tipos de Contratos 615

19.7

Contratas dc Incentivo

667

21.0

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 dc Fase 676

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

em Gerenciamento de Projetos PMI®

Ilonicker Corporation

Concorrer ou não Concorrer

NO ESCOPO

630

A Reserva de Gerenciamento

22.0

631

22 1 20 GERENCIAMENTO DA QI ALIDADE

Introdução 635

20 1

Definição dc Qualidade

20.2

20 3

22.2

635

22.3

636

22.4

Comparação entre os Pioneiros da

O Momento Certo para Mudanças 681

A Necessidade do Negócio por uma Mudança

682

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

682

Estudo de Caso

20 4

A Abordagem dc Taguchi

20 5

O Prcm 10 Nacional de Qualidade Malcom

640

Kemko Manufacturing

642

682

23 O ESCRITÓRIO DE PROJETOS

20 6

ISO 9000 643

20 7

Conceitos dc Gerenciamento da Qualidade

20 8

O Custo da Qualidade

645

As Sete Ferramentas de Controle

da Qualidade

Necessidade dc Conhecimento do Negócio 680

no Escopo

Qualidade 639

20 9

679

Introdução 679

no Escopo

O Mov im ento da Qual idade 637

Baldrigc

676

22 O “NEGÓCIO” DAS MUDANÇAS

O Dilema de Cmnograma 629

20 0

647

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

20 13 Lean Seis Sigma c DMAIC

230

Introdução 685

23 1

O Escritório dc Projetos Atual

23.2

Os Riscos dc Implementação

23.4

Escritórios dc Gerenciamento de Projetos

657

659

660 660

20 19 Dicas de Estudo para o Exame de Certificação cm Gerenciamento dc Projetos PMI *

Sistemas de Informação de Gerenciamento 688

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 Projetos 691

690

23.10 O Desenvolvimento do Business Case

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

20 18 Gestão da Qualidade Total (TQM)

687

dc Projetos

659

685 686

Tipos de Escritórios dc Projetos 687

cm Rede

658

685

23 3

23.5

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

643

655

656

20 12 Implementação do Seis Sigma 20 14 Liderança da Qualidade

675

Estudo dc Caso

626

Estudos de Caso

672

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

23 16 Gerenciamento de Portfolio dc Projetos 694

do Business Case

737

737

O Business Case “Oculto”

A Ação Judicial de Gerenciamento

26.8

O Gerenciamento dos Riscos

de Projetos 698

26.9

A Crença Coletiva

24 GERENCIAMENTO DE PROJETOS

DE CRISE

738

740

26.11 Os Anos de Intancia do Indium

26.12 O Financiamento da Divida

701

Introdução

738

739

26.10 O Campeão de Saida

24 0

737

26.7

Estudo de Caso

26 13 O Projeto M-Star

701

24 1

Compreensão do Gerenciamento de Crises

24 2

Ford versus Firestone

701

26 14 Um Novo CEO

740

742

743 743

26 15 Os Lançamentos dos Satélites

702

735

744

26.16 Uma Oferta Pública Inicial (IPO)

24 3

O Acidente do Concorde da Air France

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 Iridium 749 26.21 Â Procura dc um “Cavaleiro Branco"

24 9

O Desastre do Ônibus Espacial Columbia

26.22 ADcfinição do Fracasso (Outubro dc 1999)

703

26 17 O Cadastramento de Clientes

703

26.19 A Queda Rápida do Indium

704

708

745

746

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

24 10 Vitimas versus Vilões 709

26.25 Epilogo

25 O FUTURO DO GERENCIAMENTO 25 0 25 1

26 28 Autópsia

751

Tempos de Mudança Projetos Complexos

26 30 O Que Realmente Deu Errado0

713

752

752

26 29 O Impacto Financeiro da Falcncia

713

751

751

26 26 Processos dc 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

744

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

704

24.11 As Fases do Ciclo dc Vida

744

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 Exercício de Liderança

DO IRIDIUM: UMA PERSPECTIVA DO

Apêndice C Estudos dc Casos Dorale Products

GERENCIAMENTO DE PROJETOS

733

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

735

Apêndice E Alinhamento do Guia PMBOK * 3

260

Introdução

26 1

A Nomeação do Projeto “* Indium ’

26.2

A Obtenção de Apoio Executivo

Dorale Products

733 735

ao Texto

779

775

767

763

VISÃO GERAL

Estudos de (oso Relocionodos (de Ketn\e?iãs\

MIMSUHSIO FIGURA 1-1

Por que os sistemas são necessários?

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).

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.

FIGURA 1-3

Restrições concorrentes.

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. Com responsabilidade compartilhada, os gerentes de linha devem ter um bom entendimento de 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 longo do texto.

VISÀO GERAL

s * PMP sl 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 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 o lançamento de um produto no mercado. Kn São uma associação de empresas, provisória ou não. realizada para explorar determinadas oportunidades de negócio, mantendo a personalidade jurídica das empresas envolvidas.

7 • 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 • controle gerencial para responsabilidade e autogestâ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 Heerkcns. 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. THAMHAIN. H. I. Management of technology. Hoboken. NI: Wiley, 2005. p. 3-4. Ver note 2; TI IAMI IAIN; p. 28. HF.RRKENS, 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 relacionamento 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 $ 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 selecioná-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:

1.5

DEFINIÇÃO DO PAPEL DO GERENTE DE PROJETOS

O gerente de projetos é o responsável pela coordena­ 2.2.1 Rirtrs 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. Capitulo 4 gerenciamento da

Integração do Projeto

Gerenciamento do Integração

•Ccped —

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

•MMfc------------------------- ► Mito

• [(MpcmailB Entiodos •lwohmpany, se recusaram a reco­ nhecer a necessidade dessa mudança, na crença de que os dias de glória de outrora retornariam ao final da recessão. Em 1995, a recessão já acabara havia pelo menos dois anos e a Williams Company ainda não tinha novas linhas de produtos. A receita estava baixa, as vendas para o produto padrão (com e sem modificações) estavam di­

29

minuindo e os funcionários ainda resistiam à mudança. As demissões eram iminentes.

Em 1996, a empresa foi vendida para a Crock En­ gineering. A Crock possuía uma divisão própria e expe­ riente de máquinas-ferramenta e entendia do negócio. A Williams Company foi autorizada a funcionar como uma entidade separada de 1995 a 1996. Em 1996, a tinta ver­ melha apareceu nos balanços da Williams Company. A Crock substituiu todos os gerentes seniores da Williams por seu próprio pessoal. Ela anunciou a todos os funcio­ nários que a Williams se tornaria uma fabricante de espe­ cialidades de máquinas-ferramenta e que os “bons e ve­ lhos tempos” nunca retornariam. A demanda de clientes por produtos especiais triplicou apenas nos últimos 12 meses. A Crock deixou claro que os funcionários que não apoiassem essa nova direção seriam substituídos. A nova alta administração da Williams reconheceu que 85 anos de gestão tradicional haviam chegado ao fim para a empresa, então comprometida com produtos espe­ ciais. A cultura da empresa estava prestes a mudar, enca­ beçada pelo gerenciamento de projetos, pela engenharia simultânea e pela gestão da qualidade total.

O compromisso da alta administração com a gestão dc produto era evidente pelo tempo e dinheiro gastos com a capacitação dos empregados. Infclizmentc, os ve­ teranos de mais de 20 anos ainda não apoiavam a nova cultura. Reconhecendo os problemas, a administração forneceu apoio contínuo e visível ao gerenciamento dc projetos, além de contratar um consultor dc gerencia­ mento de projetos para trabalhar com as pessoas. O con­ sultor trabalhou na Williams de 1996 a 2001. De 1996 a 2001, a Williams Division, da Crock En­ gineering, amargou prejuízos durante 24 trimestres con­ secutivos. O trimestre finalizado em 31 de março de 2002 foi o primeiro trimestre lucrativo em mais de sets anos. Muito do crédito foi dado ao desempenho e maturida­ de do sistema de gerenciamento de projetos. Em maio de 2002, a Williams Division foi vendida. Mais de 80% dos funcionários perderam seus empregos quando a empresa mudou para um local distante mais dc 2.400 quilômetros.

CRESCIMENTO DO GERENCIAMENTO DE PROJETOS: Conceitos e Definições

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

Estudos de (aso Relacionados (de Kerzner/Project

Imo de Exercícios Relacionado (de Kermet/Project Management

Guia PMBOK

Management (ase Studies, 4. ed.)

Workbook and PMP /(APM Exam Study Guide, 11. ed.)

Exame de (erliíicoçõo PMP

• Goshe Corporation

• Gerenciamento da Integração

• Multiple Choice Exam

• MIS ftqect Management at Erf Notond Bonk

• Gerenciamento do Escopo

• Cordow Research Group • (cnez Plastics • L P Atoning Corporation • Project firecracker • Apache Metals, Inc. • Hoflet Special'/Manufoctixrg

•

Creating a /Aelhodobgy"

'fstodo de ft

fapVnc

Jcós

Wa»

Smifcwg

twçnSTC

•

•

Benchmarking é um processo sistemático c continuo de ava­ liação dos produtos, serviços e processos de trabalho das or­ ganizações que sâo reconhecidas como representantes das me­ lhores práticas com a finalidade dc comparar desempenhos c identificar oportunidades de melhoria na organização que está realizando (ou monitorando) o benchmarking. Fonte: http:// pt.wikipedia.org/wiki/Benchmarking.

tvrisw

ft * :«e

(kit de

totes

toNru

*w$ e(er

njíxw

kto

. © 2012 pelo International Institute for

learning. New York City. Reproduzido com permissão.

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

• Gerenciamento dos Recursos Humanos • Planejamento • Seleção de Pessoal para o Projeto

O que se entende por uma equipe de projetos O processo e o ambiente de seleção de pessoal O papel do gerente de linha na seleção de pessoal O papel do executivo na seleção de pessoal As habilidades necessárias para ser um gerente de projetos • Que o gerente do projeto é responsável por ajudar os membros da equipe a crescer e aprender en­ quanto trabalham no projeto • • • • •

No Apêndice C, os seguintes miniestudos de caso Dorale Products se aplicam: • Dorale Products (G) [Gerenciamento dos Recur­ sos Hu manos | • Dorale Produtos (H) (Gerenciamento dos Recur­ sos Humanos] • Dorale Products (I) |Gerenciamento dos Recursos Humanos] • Dorale Produtos (J) (Gerenciamento dos Recursos Humanos] • Dorale Produtos (K) (Gerenciamento dos Recur­ sos Humanos] As seguintes questões de múltipla escolha ajudarão na revisão dos conceitos deste capítulo:

1. Durante a seleção de pessoal para o projeto, o princi­ pal papel da alta administração está na seleção de: a. Gerente do projeto b. Gerentes de projetos assistente c. Equipe funcional d. Executivos nào se envolvem na seleção de pessoal 2. Durante a seleção de pessoal para o projeto, o princi­ pal papel da gerência de linha é: a. Aprovação da seleção do gerente do projeto b. Aprovaçào da seleção dos gerentes de projetos assistentes c. A designação de recursos funcionais com base em quem estiver disponível

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

d. A designação dc recursos funcionais com base na disponibilidade e no conjunto de habilidades necessárias 3. Um gerente de projetos tem muito mais probabilida­ de de êxito se ficar óbvio para todos que: a. Ele possui domínio da tecnologia. b. Ele está em uma categoria de salário mais elevada do que todo mundo na equipe. c. Ele tem mais de 45 anos de idade. d. A administração executiva nomeou oficialmente o gerente do projeto. 4. A maioria das pessoas acredita que a melhor manei­ ra dc treinar alguém em gerenciamento dc projetos é por meio de: a. Treinamento prático b. Seminários universitários c. Pós-graduações cm gerenciamento dc projetos d. Seminários e reuniões profissionais 5. Durante as negociações com o gerente dc linha para a seleção de pessoal, você identifica um pacote de tra­ balho que requer um conjunto de habilidades dc um funcionário de categoria 7.0 gerente de linha infor­ ma que irá designar um funcionário dc categoria 6 c outro de categoria 8. Você deve: a. Se recusar a aceitar o empregado de categoria 6, porque você não é responsável pelo treinamento b. Solicitar duas pessoas diferentes c. Pedir ao patrocinador para interferir d. Ficar feliz! Você tem dois trabalhadores. 6. Você preciíicou um projeto em 1000 horas, conside­ rando que um empregado dc categoria 7 fosse desig­ nado. O gerente de linha designa um funcionário de categoria 9. Isso resultará cm sobrecusto significativo. O gerente do projeto deve: a. Rcagcndar a data dc início do projeto com base na disponibilidade de um empregado de categoria 7 b. Solicitar ao patrocinador uma maior prioridade para o seu projeto c. Reduzir o escopo do projeto d. Verificar se o empregado de categoria 9 pode fa­ zer o trabalho em menos tempo 7. Conforme um projeto começa a diminuir o ritmo, o gerente do projeto deve: a. Liberar lodo o pessoal não necessário, para que possam ser designados a outros projetos b. Esperar até que o projeto esteja oficialmente con­ cluído antes dc liberar qualquer pessoa G Aguardar até que o gerente de linha oficialmente solicite que o pessoal seja liberado d. Conversar com outros gerentes de projetos, para ver quem deseja o seu pessoal RESPOSTAS l.A

2. D

3. D

4. A

5. D

6. D

7. A

137

EXERCÍCIOS 4-1

1

De S. K. Grinnell e II. P. Apple (When Two Bosses Are Better Than One. Machine Design, jan. 1975. p. 84-87):

138

Gerenciamento de Projetos

4-4

4-5

4-6

4-8

deve tomar, de forma independente ou em con­ junto. (Que decisões cada um pode tomar inde­ pendentemente ou em conjunto?) Tanto o cliente quanto o pessoal de projetos do fornecedor devem estar dispostos a tomar deci­ sões o mais rápido possível. C. Ray Gullet (Personal Management in Project Organization. Personnel Administration/Public Personnel Review, p. 17-22, nov.-dez. 1972) iden­ tificou cinco problemas de pessoal. Como você, como um gerente de projetos, lida com cada problema? Os níveis de alocação são mais variáveis em um ambiente dc projetos. A avaliação do desempenho é mais complexa e mais sujeita a erros em um modelo de organiza­ ção matricial. Os salários e as categorias salariais são mais di­ fíceis dc serem mantidos em um modelo de or­ ganização matricial. As descrições de cargos são, muitas vezes, dc menor valor. O treinamento e o desenvolvimento são mais complexos c, ao mesmo tempo, mais necessários no modelo de organização de projetos. Problemas com o moral são potcncialmcntc maiores em uma organização matricial. Algumas pessoas acreditam que um gerente dc projetos funciona, em alguns aspectos, como um medico. Há alguma validade nisso? Paul é um gerente de projetos de um esforço que requer 12 meses. Durante os meses sétimo, oitavo e nono ele precisa de dois indivíduos com qualifi­ cações especificas. O gerente funciona) prometeu que essas pessoas estarão disponíveis dois meses antes de serem necessárias. Se Paul não designálas ao seu projeto nesse momento, elas serão de­ signadas para outro lugar e ele terá de lidar com quem estiver disponível mais tarde. O que Paul deve fazer? Você tem de fazer qualquer considera­ ção para defender sua resposta. Alguns dos motivos mais fortes para a promoção dos engenheiros funcionais a engenheiros de pro­ jetos são: Melhores relacionamentos com colegas pesquisadores Melhor prevenção da duplicação dc esforços Melhor promoção do trabalho em equipe Essas razões gcralmentc são aplicadas cm situa­ ções de P&D. Poderíam também ser aplicadas a outras fases do ciclo dc vida do produto, além dc P&D? /\ seguir, foram apresentadas qualificações para um gerente de projetos bem-sucedido para pro­ jetos de alta tecnologia:

• • • • •

4-9

4-10

4-11

4-12

Sua carreira evoluiu pelos escalões técnicos É conhecedor em muitos campos da engenharia Compreende o significado da filosofia da rentabi­ lidade c do gerenciamento geral É interessado em treinar e ensinar seus superiores Sabe como trabalhar com os perfeccionistas Essas mesmas qualificações podem ser modifica­ das para o gerenciamento de projetos não relacio­ nados à P&D? Sc sim, como? W. J. Taylor e T. E Wading (Successful project ma­ nagement, London: Business Books. 1972. p. 32) declaram: É frequentemente o caso, portanto, que o Gerente de Projetos seja mais conhecido por seu conhecimento em técnicas degestào, a sua capacidade de "fazer com que as coisas sejam feitas” e sua capacidade em "lidar com as pessoas” do que pela sua simples proeza técnica. No entanto, pode ser perigoso minimizar esse último ta­ lento ao escolher Gerentes de Projetos dependentes do tipo e tamanho do projeto. O Gerente de Projetos deve ser preferencialmente um especialista, seja na área do projeto ou em um assunto relacionado a ela. O quào perigoso pode ser se esse último talento for minimizado? Será perigoso cm todas as circunstâncias? Frank Boone é o engenheiro mais experiente em tubulação da empresa. Durante cinco anos a em­ presa recusou seu pedido de transferência para a engenharia de projetos c para o gerenciamento dc projetos, afirmando que ele é muito valioso para a empresa em sua posição atual. Se você fosse um gerente de projetas, gostaria de ter esse indivíduo como parte de sua equipe funcional? Como uma organização deve lidar com essa situação? Tom Weeks é gerente do grupo de isolamento. Durante uma recente reunião dc grupo. Tom comentou: “A empresa está em apuros. Como sabem, estamos em licitação de três programas agora. Sc vencermos apenas um deles, provavel­ mente podemos manter o nosso nível de trabalho atual. Sc, por alguma chance pequena, nõs ven­ cermos todos os três, vocês todos se tornarão ge­ rentes amanhã." A empresa ganhou todos os três programas, mas o grupo de isolamento não con­ tratou ninguém e não houve promoções. Como você, como um gerente de projetos em um dos novos projetos, esperaria que fossem as suas rela­ ções de trabalho com o grupo de isolamento? Você é um engenheiro de projetos em um pro­ grama de alta tecnologia. Conforme o projeto vai terminando, o seu patrão lhe pede para escrever um paper para que ele possa apresentá-lo em uma reunião técnica. O nome dele aparecerá primei­ ro no paper. Isso deve ser parte de seu trabalho? Como você se sente sobre essa situação?

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

4-13 Pesquisas indicaram que a estrutura matricial é frequentemente confusa porque requer múltiplas funções para as pessoas, com consequentes con­ fusões sobre esses papéis (DAVIS, Keith. Human relations at work. New York: McGraw-Hill, 1967. р. 296-297). Infelizmenle, nem todos os gerentes de programas, gerentes de projetos e engenheiros de projetos possuem as habilidades necessárias para operar nesse ambiente. Stuckenbruck decla­ rou: “O caminho para o sucesso é coberto com os corpos de gerentes de projetos que originalmente eram gerentes de linha funcional e, em seguida, foram para o gerenciamento de projetos”. (STU­ CKENBRUCK, Linn. The effective project mana­ ger. Project Management Quarterly, mar. 1976. v. VII, n. 1, p. 26-27.). O que você acha que é a prin­ cipal causa dessa queda dogerente funcional? 4-14 Para cada um dos modelos organizacionais apre­ sentados abaixo, quem determina quais recursos sào necessários, quando sào necessários e como eles serão utilizados? Quem tem a autoridade e a responsabilidade de mobilizar esses recursos? a. Organização tradicional b. Organização matricial с. Organização de linha de produtos d. Organização de projetos linha-staff 4-15 Você concorda ou discorda que os modelos or­ ganizacionais de projetos incentivam as comuni­ cações entre os pares e a resolução dinâmica de problemas? 4-16 A Companhia XYZ opera em uma estrutura tra­ dicional. A empresa acaba de receber um contra­ to para desenvolver uma nova linha de produtos para um grupo especial de clientes. Ela decidiu extrair o pessoal selecionado a partir dos depar­ tamentos funcionais e criar uma única estrutura organizacional de produtos para operar em para­ lelo com os departamentos funcionais. a. Estabeleça o organograma. b. Você acha que essa configuração pode funcio­ nar? A sua resposta depende de quantos anos esta situação deve existir? 4-17 Você é o engenheiro de um programa similar a outro que você dirigiu anteriormente. Você deve tentar obter o mesmo pessoal administrativo c/ ou técnico que leve anteriormente? 4-18 Uma pessoa designada ao seu projeto está de­ sempenhando de forma insatisfatória. O que você deve fazer? Será que vai fazer diferença se ela estiver no escritório de projetos ou como colaboradora funcional? 4-19 Você foi designado para o escritório de projetos como um engenheiro dc projetos assistente. Você deve se reportar ao engenheiro chefe do projeto que se reporta formalmente ao gerente do pro­ jeto e informalmente ao vice-presidente de enge­

4-20

4-21

4-22

4-23 4-24

4-25

4-26 4-27

4-28

4-29 4-30

139

nharia. Você nunca trabalhou com o engenheiro chefe desse projeto antes. Durante a execução do projeto, íica claro para você que o engenheiro chefe do projeto está tomando decisões que nào parecem ser do melhor interesse para o projeto. O que você deve fazer em relação a isso? Os indivíduos devem ser promovidos ao geren­ ciamento de projetos porque estão no topo da categoria funcional? Um departamento funcional pode ler a permissão de “emprestar” (numa base temporária) pessoas de outro departamento funcional, a fim de cumprir os requisitos de mão de obra do projeto? Isso deve ser permitido se estiverem envolvidas horas extras? Um gerente de projetos deve ser pago pelo de­ sempenho ou pelo número de pessoas que supervisiona? Um gerente de projetos deve tentar atualizar o seu pessoal? Por que um gerente funcional deve designar seus melhores recursos para você em um projeto de longo prazo? Uma empresa de carvão adotou a filosofia de que o gerente de projetos para projetos de inicializa­ ção de novas minas será o indivíduo que acabará por se tornar o superintendente da mina. A em­ presa acredita que esse tipo de filosofia de “pro­ priedade" é boa. Você concorda? Um gerente de projetos pode ser considerado um “mercenário”? Organizações produtoras estão usando gerencia­ mento de projetos/engenharia de projetos estrita­ mente para dar aos novos funcionários exposição a todas as operações da empresa. Depois de trabalhar em um ou dois projetos, cada um com cerca de um a dois anos de duração, o empregado é transferi­ do para a gerência de linha de sua carreira e para oportunidades de crescimento. Pode uma situação como essa, em que não existe plano de carreira nem em gerenciamento de projetos nem na enge­ nharia de projetos, ser bem-sucedida? Poderia ha­ ver algum efeito negativo sobre os projetos? Um gerente de projetos pode criar dedicação e um verdadeiro espírito vencedor e ainda ser odia­ do por todos? Qualquer pessoa pode ser treinada para ser um gerente de projetos? Uma companhia de luz e energia possui geren­ ciamento de projetos em tempo parcial, no qual um indivíduo alua como um gerente de projetos e como colaborador funcional, ao mesmo tempo. A empresa de serviços públicos afirma que esse processo impede que um empregado fique “tec­ nicamente obsoleto” e que, quando o empregado retorna aos seus deveres funcionais em tempo in­ tegral, ele é uma pessoa mais bem desenvolvida.

140

Gerenciamento de Projetos

4-31

4-32

4-33

4-34

4-35

4-36

Vocc concorda ou discorda? Quais são as vanta­ gens e desvantagens dessa configuração? Alguns setores consideram o principal critério para a promoção c o crescimento como sendo cabelos grisalhos e/ou calvície. Esse tipo de matu­ ridade é vantajoso? Na Figura 4-8 mostramos que a Al Tandy e Don Davis (assim como outros profissionais do es­ critório de projetos) se reportavam diretamente ao gerente do projeto e indiretamente à gerência funcional. Essa situação poderia ser revertida, com o pessoal do escritório dc projetos se repor­ tando indiretamente ao gerente do projeto e direlamenle à gerência funcional? A maioria das organizações possui “estrelas * pesso­ as que geralmente são identificadas como aqueles indivíduos que são a chave para o sucesso. Como é que um gerente de projetos identifica essas pes­ soas? Elas podem estar no escritório de projetos ou devem ser colaboradores ou gerentes funcionais? Considerando seu próprio setor, quais fatores relacionados ao cargo ou ao colaborador você gostaria dc saber antes dc escolher alguém para ser um gerente dc projetos ou um engenheiro dc projetos em um esforço no valor de: a. $30.000? b. $300.000? c. $3.000.000? d. $30.000.000? Uma das grandes polêmicas que ocorrem no ge­ renciamento de projetos é sobre se o gerente de projetos precisa dominar a tecnologia para ser eficaz. Considere a seguinte situação: Você é o gerente de um projeto de pesquisa e de­ senvolvimento. O departamento dc marketing o informa que encontraram um cliente para seu produto e que você deve fazer grandes modifi­ cações para atender aos requisitos do cliente. Os gerentes funcionais de engenharia lhe dizem que essas modificações são impossíveis. Um gerente dc projetos sem o domínio da tecnologia pode tomar uma decisão viável sobre arriscar recursos financeiros adicionais e apoiar a comercialização, ou acreditar nos gerentes funcionais e dizer ao departamento de marketing que as modificações são impossíveis? Como um gerente dc projetos, com ou sem domínio da tecnologia, pode dizer se os gerentes funcionais estão lhe dando um pare­ cer otimista ou pessimista? Como um colaborador funcional, você demons­ tra que possui habilidades excepcionalmente boas de redação. Você é, então, promovido ao cargo de assistente especial do gerente da divisão c é avisa­ do de que deve assumir total responsabilidade por todo o trabalho de propostas que deve fluir pela

4-37

4-38

4-39

4-40

4-41

4-42 4-43

4-44

sua divisão. Como você se sente sobre isso? É uma promoção? Para onde você pode ir a partir daí? Os formuladores das políticas governamentais ale­ gam que apenas indivíduos altamente classificados (dc alto grau dc categoria) podem ser gerentes dc projetos, pois um bom gerente de projetos preci­ sa de “peso” suficiente para fazer o projeto seguir adiante. No governo, o gerente dc projetos geralmcntc possui o salário mais alto da equipe do projeto. Como os problemas de salário podem ser superados? A política do governo é eficaz? Uma grande empresa de serviços públicos está pre­ ocupada com gerentes dc projetos promovendo colaboradores funcionais. Em um projeto de oito meses, que emprega 400 empregados de projeto cm tempo integral, os gerentes dc departamento instalaram pessoas para “verificação” cuja respon­ sabilidade é checar se os colaboradores funcionais não possuem designações dc trabalho (ou seja, não foram aprovados pelo gerente funcional) para de­ signações acima do seu nível e categoria atuais. Esse sistema pode funcionar? E se o trabalho estiver em uma posição abaixo dc seu nível c categoria? Uma grande empresa dc serviços públicos come­ ça cada projeto de TI com um estudo de viabi­ lidade em que uma análise de custo-beneficio é realizada. Os gerentes dc projetos sc reportam a uma divisão de gerenciamento de projetos e rea­ lizam o estudo de viabilidade sem qualquer apoio funcional. Os colaboradores funcionais argu­ mentam que o estudo dc viabilidade c impreciso porque os “especialistas" funcionais não estão en­ volvidos. Os gerentes de projetos, por outro lado, argumentam que nunca possuem tempo ou di­ nheiro suficiente para envolver os colaboradores funcionais. Essa situação pode ser resolvida? Como você procedería no treinamento de indiví­ duos dentro da sua empresa ou setor para serem bons gerentes de projetos? Quais suposições você está fazendo? As equipes de projetos deveríam ter permissão para evoluírem por si mesmas? Em qual momento ou fase do cido de vida de um projeto um gerente de projetos deve ser nomeado? A alta administração geralmente possui duas escolas de pensamento em relação a gerencia­ mento de projetos. Uma escola que afirma que o gerente de projetos deve ser utilizado como um meio para a coordenação das atividades que atravessam vários departamentos funcionais. A segunda escola afirma que o cargo de geren­ ciamento de projetos deve ser usado como um meio para a criação de futuros gerentes gerais. Qual escola de pensamento está correta? Alguns executivos acham que o pessoal que trabalha em um escritório de projetos deva ser

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

treinado cm diversas funções de assistência ao gerenciamento de projetos. O que você pensa sobre isso? 4-45 L’ma empresa tem uma política a qual se os cola­ boradores pretendem ser gerentes de projetos de­ vem primeiro passar de um ano a um ano e meio no lado do colaborador funcional da casa, para que possam chegar a conhecer os colaboradores e a política da empresa. O que você acha disso? 4-46 O seu projeto cresceu de tal forma que já exis­ tem três vagas em tempo integral para gerente de projetos assistente. Infelizmentc, não há pessoal experiente disponível. Você foi avisado pela alta gerência de que irá preencher essas três posições por meio de promoções internas. Onde você deve procurar dentro da organização? Durante uma entrevista, quais perguntas você deve fazer aos candidatos em potencial? É possível que você possa encontrar candidatos que estejam qualifi­ cados para serem promovidos vcrticalmcntc e não horizontalmcnte? 4-47 Um colaborador funcional demonstrou os atri­ butos necessários de um potencial gerente de projetos de sucesso. A alta administração pode:

141

• Promover o indivíduo em salário e catego­ ria e transferi-lo para o gerenciamento de projetos. • Transferir lateralmente o trabalhador para gerenciamento de projetos, sem qualquer aumento de salário ou categoria. Se, depois de três a seis meses, o empregado demons­ trar que pode desempenhar, ele receberá um aumento adequado de salário e categoria. • Dar ao empregado ou um aumento de ca­ tegoria sem qualquer aumento salarial, ou um pequeno aumento salarial sem aumento de categoria, sob a condição de que recom­ pensas adicionais serão fornecidas no final do período de observação, admitindo que o empregado possa manter a posição. Se você estivesse na alta administração, qual método você preferiría? Se você não gosta das três escolhas aci­ ma, desenvolva sua própria alternativa. Quais são as van­ tagens e desvantagens de cada escolha? Para cada opção, discuta as ramificações, caso o trabalhador não consiga lidar com a posição no gerenciamento de projetos.

FUNÇÕES DE GESTÃO

Estudos de (aso Relacionados (de Kerinet/Project Imo de Exercícios Relocionodo (de Kef met/Project Management Management (me Studies, 4. ed.) Workbook and Exam Study Guide, 11. ed.)

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

• Wym Computa Equpment (WG)

• The CommiriKoton Problem

• Gerenciamento dos Raursos Humanos

• 0 Projeto Trophy’

• Meetings, Meeéngs, ord Meetings

• Gerenciamento dos Comunkoçoes

• FobosdeComunkoçõo

• The Empowerment Pioblem

• McRcyAadspoce’

• Project Monogemail Psychology

• OFuncionónoRuim *

• Multiple Choke Exom

• APhrnoDonno *

• Crossword Puzzle on Humon Resource Monoganent

• A Reuniõo de Equipe

• Crossword Puzzle on Commmkotions Monogement

‘ ísixfc de aso tjmbêm opcrece no M do ca*yb

5.0

INTRODUÇÃO

Como já dissemos, o gerente de projetos mede seu sucesso 1.7.2 Habilidades de gerenciamento de projetos pela maneira como pode ne­ 1.4.4 Papel do PMO gociar com a alta administra­ ção e com a gerência funcional pelos recursos necessários para atingir o objetivo do projeto. Além disso, o gerente de proje­ tos pode ter muita autoridade delegada, mas pouquíssimo poder. Assim, as habilidades gerenciais das quais ele necessita para o bom desempenho podem ser drasticamente diferentes das habilidades dos seus colegas da gerência funcional.

Guia PMBOK5. ed.

O aspecto difícil do ambiente de gerenciamento de projetos é que os indivíduos na interface entre o projeto e o departamento funcional devem se reportar a dois chefes. Os gerentes funcionais e os gerentes de projetos, em virtude de seus diferentes níveis de autoridade e responsabilidade, tra­ tam o seu pessoal de maneiras diferentes, dependendo das filosofias de suas “escolas de administração”. Há geralmente cinco escolas de administração, conforme descrito a seguir

• A Escola Clássica / Tradicional: administração é o processo de fazer as coisas (isto é, atingir os objeti­ vos), trabalhando com e por meio de pessoas que operam em grupos organizados. A ênfase é dada ao item final ou objetivo, com pouca consideração pelas pessoas envolvidas. • A Escola Empírica: as habilidades de administra­ ção podem ser desenvolvidas por meio do estudo das experiências de outros gerentes, indiferente­ mente a situações serem semelhantes ou não. • A Escola Comportamental: duas classes são consi­ deradas dentro dessa escola. Primeiro, temos a classe das relações humanas, na qual destacamos o relacio­ namento interpessoal entre os indivíduos e seu tra­ balho. A segunda dasse inclui o sistema social do in­ divíduo. A administração é considerada um sistema de relações culturais que envolve a mudança social. • A Escola da Teoria da Decisão: a administra­ ção é uma abordagem racional para a tomada de

144

Gerenciamento de Projetos decisões utilizando um sistema de modelos mate­ máticos e processos, tais como investigação opera­ cional e ciência da administração. • A Escola Sistêmica da Administração: adminis­ tração é o desenvolvimento de um modelo de sis­ temas, caracterizado pela entrada, processamento e saída, e identifica diretamente o fluxo de recur­ sos (dinheiro, equipamentos, instalações, pessoal, informações e materiais) necessários para obter algum objetivo, seja pelo aumento ou pela dimi­ nuição de alguma função do objetivo. A escola sistêmica da administração também inclui a teoria da contingência, que enfatiza que cada situação ê única e deve ser otimizada separadamente dentro das restrições do sistema.

Em um ambiente de projetos, os gerentes funcionais são geralmente praticantes das três primeiras escolas de ad­ ministração, enquanto os gerentes de projetos utilizam as duas últimas. Isso impõe dificuldades tanto nos represen­ tantes dos gerentes de projetos quanto nos representantes dos gerentes funcionais. O gerente de projetos deve motivar os representantes funcionais para a dedicação ao projeto na linha horizontal, utilizando a teoria sistêmica da adminis­ tração e ferramentas quantitativas, muitas vezes com pouca consideração com o empregado. Afinal, o colaborador pode ser designado para um esforço de prazo muito curto, en­ quanto o item final é o objetivo mais importante. O gerente funcional, no entanto, manifesta mais interesse pelas neces­ sidades individuais do colaborador na utilização das escolas tradicionais ou comporta mentais de administração.

Os profissionais modernos ainda tendem a identifi­ car as responsabilidades e habilidades de gestão em ter­ mos dos princípios e funções desenvolvidas nas escolas iniciais de administração, a saber: • • • • •

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

Embora essas funções de gestão tenham sido geral­ mente aplicadas às estruturas tradicionais de gerencia­ mento, elas foram recentemente redefinidas para cargos temporários de gestão. Seus significados fundamentais permanecem os mesmos, mas as aplicações são diferentes. 5.1

CONTROLE

O controle é um processo de três etapas de medição do progresso em direção a um objetivo, avaliando o que resta

a ser feito e tomando as ações corretivas necessárias para alcançar ou exceder os objetivos. Essas três etapas de medi­ ção, avaliação e correção são definidas conforme a seguir: • Medição: determinar, por meio de relatórios for­ mais e informais, o grau do progresso que está sen­ do feito em direção aos objetivos. • Avaliação: determinar a causa e as possíveis for­ mas de agir sobre desvios significativos do desem­ penho planejado. • Correção: tomar ação de controle para corrigir uma tendência desfavorável ou tirar vantagem de uma tendência excepcionalmente favorável. O gerente de projetos é responsável por garantir a realização de metas e objetivos de grupo e organizacio­ nais. Para isso, ele deve ter um conhecimento profundo das normas e políticas de controle de custos e dos pro­ cedimentos para que seja possível a comparação entre os resultados operacionais e os padrões preestabelecidos. O gerente de projetos deve, então, tomar as ações corretivas necessárias. Os últimos capítulos fornecem uma análise mais profunda do controle, especialmente a função de controle de custos.

No Capítulo I, afirmamos que os gerentes de proje­ tos devem entender o comportamento organizacional, a fim de serem eficazes, e devem possuir sólidas habilidades interpessoais. Isso é especialmente importante durante a função de controle. Os gerentes de linha podem ter o luxo de possuir tempo para construir relacionamentos com cada um dos seus colaboradores. Mas, para um ge­ rente de projetos, o tempo é uma restrição e nem sempre é fácil prever o quão bem ou mal um indivíduo vai intera­ gir com o grupo, principalmente se o gerente do projeto nunca trabalhou com esse empregado antes. A compre­ ensão do comportamento fisiológico e social sobre como as pessoas atuam em um grupo não pode ser alcançada da noite para o dia. 5.2

DIREÇÃO

Direção ê a implementação e execução (por meio dos ou­ tros) dos planos aprovados que são necessários para al­ cançar ou exceder objetivos. Dirigir envolve etapas como:

• Seleção de Pessoal: verificar se uma pessoa qualifi­ cada foi selecionada para cada posição. • Treinamento: ensinar os indivíduos e grupos a cumprirem seus deveres e responsabilidades. • Supervisão: fornecer instruções, orientações e disciplina diárias aos outros, conforme a neces­ sidade, para que possam cumprir seus deveres e responsabilidades.

145

FUNÇÕES DE GESTÀO

• Delegação: designar trabalho, responsabilidade e autoridade para que outros possam fazer utiliza­ ção máxima de suas capacidades. • Motivação: incentivar os outros a atuar por meio da satisfação ou apelo às suas necessidades. • Aconselhamento: realizar discussões privadas com o outro sobre como ele poderia realizar um tra­ balho melhor, resolver um problema pessoal, ou realizar suas ambições. • Coordenação: verificar se as atividades são reali­ zadas com relação à sua importância e com um mínimo de conflito. A direção de subordinados nào é uma tarefa facil, tanto por causa da curta duração do projeto quanto pelo fato de que os empregados ainda podem estar designados a um gerente funcional ao mesmo tempo em que estejam designados temporariamente ao seu projeto. O luxo de “conhecer” os subordinados de alguém pode nào ser pos­ sível em um ambiente de projetos.

Os gerentes de projetos devem ser decisivos e devem avançar rapidamente sempre que forem necessárias ins­ truções. F melhor decidir uma questão e estar 10% erra­ do do que esperar pelos últimos 10% de colaboração para um problema e causar um atraso no cronograma e um uso indevido de recursos. As instruções são mais eficazes quando a regra KISS (keep it simple, stupid)™' é aplicada. As instruções devem ser escritas com um objetivo simples e claro para que os subordinados possam trabalhar de for­ ma eficaz e fazer as coisas direito na primeira vez. Ordens devem ser emitidas de um modo que presuma a adequação imediata. Se as pessoas vão ou não obedecer a uma ordem depende principalmente da quantidade de respeito que tenham por você. Portanto, nunca emita uma ordem que nào se possa fazer cumprir. Ordens verbais e instruções de­ vem ser disfarçadas de sugestões ou solicitações. O solicitante deve pedir ao receptor para repetir as ordens verbais para que não haja nenhum mal-entendido. Gerentes de projetos devem compreender o comporta­ Capitulo 9 Gerenciamento do» Recursos Humanos do Projeto mento humano, a fim de 9.4 Gerenciar a equipe do projeto motivar as pessoas rumo à realização bem-sucedida dos objetivos do projeto. Dou­ glas McGregor defendeu que a maioria dos colaboradores podem ser categorizados de acordo com duas teorias* 1. A Gti» PMBOK ', 5. ed.

primeira, muitas vezes chamada de Teoria X, pressupõe que o trabalhador médio é inerentemente preguiçoso e exige supervisão. A Teoria X supõe ainda que:

• O trabalhador médio não gosta de trabalho e evita trabalhar sempre que possível. • Para induzir o esforço adequado, o supervisor deve ameaçar de punição e exercer supervisão cuidadosa. • O trabalhador médio evita o aumento da respon­ sabilidade e tenta ser dirigido.

O gerente que aceita a Teoria X normalmente exer­ ce o tipo de controle autoritário sobre os trabalhadores e permite pouca participação no processo decisório. Os funcionários da Teoria X geralmente favorecem a falta de responsabilidade, especialmente na tomada de decisões. Segundo a Teoria Y, os funcionários estão dispostos a fazer o trabalho sem supervisão constante. A Teoria Y ainda supõe que:

• O trabalhador médio quer ser ativo e acha satisfa­ tório o esforço fisico e mental no trabalho. • Grandes resultados vêm da participação voluntária, que tendem a gerar um autodirecionamento rumo aos objetivos sem o uso de coerçào e controle. • O trabalhador médio busca a oportunidade de melhoria pessoal e o respeito próprio.

O gerente que aceita a Teoria Y normalmente defen­ de a participação e um relacionamento entre a gerência e o colaborador. No entanto, no trabalho com os profissio­ nais, principalmente com engenheiros, cuidados especiais devem ser tomados, pois esses indivíduos, muitas vezes, se orgulham de sua capacidade em encontrar um caminho melhor para atingir o resultado final, independentemente dos custos. Se isso ocorre, os gerentes de projetos devem se tornar líderes autoritários e tratar os colaboradores da Teoria Y como se fossem da Teoria X. William Ouchi identificou uma Teoria Z, que enfa­ tiza os valores culturais japoneses e o comportamento dos trabalhadores japoneses '. * De acordo com a Teoria Z, existem diferenças significativas entre a cultura japonesa e a cultura norte-americana e a maneira como os traba­ lhadores sào tratados. Os japoneses focam no emprego para a vida toda enquanto os americanos buscam por empregos de curto prazo. Os japoneses focam na tomada de decisões coletiva, tal como nos círculos de qualidade.

NTI Em tradução livre, “mantenha simples, estúpido". É um princí­ pio que valoriza a simplicidade e deténde que toda complexi­

dade desnecessária seja evitada. 1

2

OUCHI, W. G.; JAEGER, A. M. Type Z organization: stability

MCGREGOR, Douglas. The human side of enterprise. New

in the midst of mobility. Academy ofManagement Review, abr.

York: McGraw-Hill, 1960. p. 33-34.

1978. p. 305-314.

146

Gerenciamento de Projetos

já os americanos focam na tomada de decisões indivi­ dual. Os japoneses enfatizam o controle administrativo informal, enquanto os americanos inclinam-se para um controle mais formal. Empresas japonesas colocam os trabalhadores em carreiras não especializadas com ava­ liações e promoções lentas, ao passo que os americanos preferem oportunidades em carreiras especializadas com avaliações e promoções rápidas. Finalmente, os gerentes japoneses têm mais interesse na vida pessoal dos seus tra­ balhadores do que os gerentes americanos. Muitos psicólogos têm de­ monstrado a existência de Capitulo 9 Gerenciamento dos Recursos Humanos do Projeto uma hierarquia priorizada 9.5 Desenvolver a equipe das necessidades que moti­ vam os indivíduos ao desempenho satisfatório. Maslow foi o primeiro a identificar essas necessidades’. A hierarquia das necessidades de Maslow está ilustrada na Figura 5-1.0 primeiro nível é o das necessidades básicas ou fisiológicas, ou seja, alimentos, água, vestuário, abrigo, sono e satisfação sexual. Falando simplesmente, o desejo primordial humano para satisfazer essas necessidades básicas motiva o indivíduo a fazer um bom trabalho. Guia PMBOK , 5. ed.

FIGURA 5-1 Hierarquia das necessidades de Maslow.

Depois que o empregado atendeu às suas neces­ sidades fisiológicas, ele se vira para a outra necessidade menor, a segurança. Necessidades de segurança incluem segurança econômica, contra danos, doença e violência. Segurança também pode incluir proteção. F. importante que os gerentes de projetos percebam isso porque esses gerentes podem achar que conforme um projeto se apro­ xima da conclusão, os colaboradores funcionais estão mais interessados em encontrar um novo papel para si do que em dar o seu melhor à situação atual.

O nível seguinte contém as necessidades sociais, in­ cluindo amor, participação, união, aprovação e associação no grupo. Nesse nível, a organização informal desempenha

•*

MASLOW, Abraham. Motivation and personality. New York Harper and Brothers, 1954.

um papel dominante. Muitas pessoas recusam promoções para gerenciamento de projetos (como gerentes de proje­ tos, membros do escritório de projetos ou representantes funcionais) porque temem perder sua “participação” na organização informal. Esse problema pode ocorrer mesmo em projetos de curta duração. Em um ambiente de proje­ tos, os gerentes de projetos geralmente não pertencem à qualquer organização informal e, portanto, tendem a olhar para fora da organização para cumprir essa necessidade. Os gerentes de projetos consideram autoridade e recursos financeiros muito importantes para conseguir apoio para o projeto. A equipe funcional, entretanto, prefere a amizade e as designações de trabalho. Em outras palavras, o gerente de projetos pode utilizar o próprio projeto como um meio de ajudar a atender ao terceiro nível para os funcionários de linha (isto é, o espírito de equipe).

As duas necessidades mais altas são autoestima e autorrealização. A estima inclui autoestima (autorrespeito), reputação, estima dos outros, reconhecimento e autocon­ fiança. Profissionais altamente técnicos, muitas vezes, não são felizes a menos que as necessidades de estima sejam satisfeitas. Por exemplo, muitos engenheiros se esforçam para publicar e inventar coisas como forma de satisfazer essas necessidades. Essas pessoas, muitas vezes, recusam promoções para o gerenciamento de projetos porque acreditam que não podem satisfazer suas necessidades de estima nessa posição. Ser chamado de gerente de projetos não traz tanta importância como ser considerado pelos seus pares um especialista em sua área. A necessidade mais alta é a autorrealização e inclui fazer o que se pode fazer melhor, o desejo de utilizar o próprio potencial, a reali­ zação total do potencial próprio, o autodesenvolvimento constante e um desejo de ser verdadeiramente criativo. Muitos bons gerentes de projetos acham que esse nível é o mais importante e consideram cada novo projeto como um desafio pelo qual podem alcançar a autorrealização.

Frederick Herzberg e seus colaboradores realizaram os estudos da pesquisa motivacional•* 4. Herzberg concluiu que os três níveis mais baixos de Maslow (fisiológico, se­ gurança e necessidades sociais) eram fatores de higiene que estavam satisfeitos ou insatisfeitos. Os únicos fatores motivacionais reais eram as necessidades de autoestima e de autorrealização. Herzberg acreditava que as necessida­ des fisiológicas eram fatores de higiene e eram necessidades extremamente de curto prazo. Autoestima e autor realiza­ ção são necessidades mais a longo prazo e poderíam ser potencializadas por meio do rodízio de funções, que in­ clui o enriquecimento do trabalho.

4

HERZBERG, F.; MAUSNER, B.; SNYDERMAN, B. B. The mo­ tivation to work. New York John Wiley & Sons, 1959.

147

FUNÇÕES DE GESTÀO

Outra técnica motivacional pode ser relacionada ao conceito da teoria da expectativa (também conheci­ da como organização imatura-madura), a qual foi de­ senvolvida pelo behaviorista Chris Argyris. A teoria da expectativa diz que quando as necessidades da organi­ zação e as necessidades do indivíduo são congruentes, ambas as partes se beneficiam e a motivação aumenta. Quando há incongruência entre as necessidades do in­ divíduo e as necessidades da organização, o indivíduo vai experimentar:

• • • •

Frustração Fracasso psicológico Perspectivas de curto prazo Conflito

Os gerentes de projetos devem motivar os indivíduos temporariamente designados apelando aos seus desejos de atender aos dois níveis mais baixos, mas não fazendo promessas que não possam ser cumpridas. Os gerentes de projetos devem motivar, fornecendo:

• Um sentimento de orgulho e satisfação para o pró­ prio ego • Segurança de oportunidade • Segurança de aprovação • Segurança de progresso, se possível • Segurança da promoção, se possível • Segurança do reconhecimento • Um meio de fazer um trabalho melhor e não um meio de manter o emprego

Motivar os funcionários para que eles se sintam segu­ ros no trabalho não é fácil, especialmente porque um pro­ jeto tem uma duração finita. Métodos específicos para a ge­ ração de segurança em um ambiente de projetos incluem: • Permitir que as pessoas saibam o porquê de estarem onde estão • Fazer os indivíduos sentirem que pertencem onde estão • Colocar as pessoas em posições para as quais estão devidamente treinadas • Permitir que os funcionários saibam como os seus esforços se encaixam no quadro geral

Uma vez que os gerentes de projetos não podem motivar por meio de promessas de ganhos materiais, eles devem apelar para o orgulho de cada pessoa. As orienta­ ções para a devida motivação são: • • • • •

Existem várias formas de motivar o pessoal do pro­ jeto. Algumas maneiras eficazes incluem: • • • • • • •

Compreender as necessidades profissionais é um fa­ tor importante para ajudar as pessoas a perceber seu ver­ dadeiro potencial. Tais necessidades incluem: • Um trabalho interessante e desafiador • Um ambiente de trabalho profissionalmente estimulante • Crescimento profissional • Liderança total (capacidade de liderar) • Recompensas tangíveis • Conhecimento técnico (dentro da equipe) • Assistência da gerência na resolução de problemas • Objetivos claramente definidos • Controle adequado de gestão • Segurança no emprego • Apoio da alta administração • Boas relações interpessoais • Planejamento adequado • Definição clara de papéis • Comunicações abertas • Mudanças mínimas

Adotar uma atitude positiva Não criticar a administração Não fazer promessas que não possam ser mantidas Circular os relatórios do cliente Dar a cada pessoa a atenção de que ela necessita

5.3

Atribuir responsabilidades que ofereçam desafios Definir claramente as expectativas de desempenho Fazer a crítica devida, bem como dar o devido crédito Fazer avaliações honestas Proporcionar um bom ambiente de trabalho Desenvolver uma atitude de equipe Mostrar a direção correta (mesmo para o caso de Teoria Y) AUTORIDADE DO PROJETO

As estruturas de gerencia­ mento de projetos criam 9.1.3 Desenvolver o plano de uma teia de relações que recursos humanos podem causar o caos na de­ legação de autoridade e na estrutura interna de autorida­ de. Quatro questões devem ser consideradas na descrição da autoridade do projeto: Guia PMBOK ', 5.ed.

• O que é autoridade do projeto? • O que é poder e como ele é alcançado? • Quanta autoridade deve ser concedida ao gerente de projetos? • Quem resolve os problemas de interface da autori­ dade do projeto?

Um modelo de autoridade para o gerente de pro­ jetos pode ser definido como o poder legal ou legítimo

148

Gerenciamento de Projetos

de comandar, atuar ou dirigir as atividades dos outros. A autoridade pode ser delegada pelos superiores. O poder, por outro lado, é concedido a um indivíduo por seus su­

bordinados e é uma medida de seu respeito por ele. A au­ toridade de um gerente é uma combinação de seu poder e influência de tal forma que seus subordinados, pares e colegas aceitem de bom grado o seu julgamento. Na estrutura tradicional, o espectro de poder é per­ cebido por intermédio da hierarquia; enquanto, na estru­ tura de projetos, o poder vem da credibilidade, do conhe­ cimento, ou em ser um tomador de decisões seguro. A autoridade é a chave para o processo de gerencia­ mento de projetos. O gerente de projetos deve gerenciar por meio das linhas funcionais e organizacionais, reunin­ do atividades necessárias para o cumprimento dos obje­ tivos de um projeto específico. A autoridade do projeto fornece a lógica necessária para unificar todas as ativi­ dades organizacionais para a realização do projeto, inde­ pendentemente de onde elas estão localizadas. O gerente de projetos que não consegue construir e manter suas alianças, em breve encontrará oposição ou indiferença para com os requisitos do seu projeto. A quantidade de autoridade conferida ao gerente de projetos varia de acordo com o tamanho do projeto, a filosofia da administração e a interpretação da admi­ nistração sobre os conflitos potenciais com os gerentes funcionais. De modo geral, um gerente de projetos deve ter mais autoridade do que a sua responsabilidade demanda, com o grau exato de autoridade geralmente dependendo do grau de risco que ele deve correr. Quanto maior o risco, maior o grau de autoridade. Um bom gerente de projetos sabe onde termina a sua autoridade e não mantém um empregado responsável por funções que ele (o gerente do projeto) não tem autoridade para fazer cumprir. Al­ guns projetos são dirigidos por gerentes de projetos que só possuem autoridade para o monitoramento. Esses ge­ rentes de projetos são chamados de gerentes de projetos de influência.

A seguir, as fontes mais comuns de problemas de po­ der e autoridade em um ambiente de projetos:

• Autoridade mal documentada ou não formalizada • O poder e a autoridade percebidos de forma incorreta • Dupla responsabilidade de pessoal • Dois chefes (que muitas vezes discordam) • A organização do projeto incentivando individualismo

• Relações subordinadas mais fortes do que as rela­ ções entre colegas ou superiores • xMudança da lealdade dos empregados das linhas verticais para as linhas horizontais • A tomada de decisões em grupo com base no gru­ po mais forte • Capacidade de influenciar ou administrar recom­ pensas e punições • Compartilhamento de recursos entre vários projetos

O gerente de projetos não possui autoridade uni­ lateral no esforço do projeto. Ele frequentemente ne­ gocia com o gerente funciona). Ele possui a autoridade para determinar o “quando” e o “o quê" das atividades do projeto, enquanto o gerente funcional possui auto­ ridade para determinar “como o apoio será fornecido”. O gerente de projetos realiza seus objetivos trabalhando com pessoal altamente profissionalizado. Para o pessoal profissionalizado, a liderança do projeto deve incluir a explicação da lógica do esforço, bem como as funções mais óbvias de planejamento, organização, direção e

controle. Existem algumas regras básicas para o controle da autoridade, por meio das negociações:

• As negociações devem ocorrer no nível mais baixo de interação • A definição do problema deve ser a primeira prioridade: • A questão • O impacto • A alternativa • As recomendações

O fracasso em estabelecer relações de autoridade pode resultar em: • Canais de comunicação ruins • Informações enganosas • Antagonismo, principalmente da organização informal • Relações ruins de trabalho com superiores, subor­ dinados, pares e associados • Surpresas para o cliente

o

•

autoridade de nível superior deve ser utiliza­ da se, e somente se, um acordo não puder ser alcançado

A fase crítica de qualquer projeto é o planejamento. Isso inclui mais do que apenas o planejamento das ativi­

149

FUNÇÕES DE GESTÀO

• Quem deve ser notificado • Quem deve aprovar

dades a serem realizadas, mas também o planejamento e o estabelecimento de relacionamentos de autoridade que devem existir para a duração do projeto. Como o am­

biente de gerenciamento de projetos é um ambiente em constante mutação, cada projeto estabelece suas próprias políticas e procedimentos, uma situação que pode final­ mente resultar em uma variedade de relacionamentos de autoridade.

Assim, é possível para os colaboradores funcionais possuírem responsabilidades diferentes em projetos dife­

rentes, mesmo que as tarefas sejam as mesmas. Durante a fase de planejamento, a equipe do proje­

to desenvolve uma matriz de responsabilidades (MR)KT2, que contém elementos tais como: • A responsabilidade pelo gerenciamento geral • A responsabilidade pelo gerenciamento das operações • A responsabilidade especializada • Quem deve ser consultado • Quem pode ser consultado

/X matriz de responsabilidades (MR) é, muitas vezes, chamada de organograma linear de responsabilidade (OLR)n. Os organogramas lineares de responsabilidade identificam os participantes e em que grau uma atividade será realizada ou uma decisão será tomada. O OLR bus­ ca esclarecer as relações de autoridade que podem existir quando as unidades funcionais compartilham trabalhos em comum.

A Figura 5-2 mostra um típico organograma linear de responsabilidade. As linhas, que indicam as atividades, res­ ponsabilidades ou funções necessárias, podem ser todas as tarefas na estrutura analítica do projeto. As colunas identi­ ficam tanto posições, títulos ou mesmo as próprias pessoas. Se o organograma será fornecido a um cliente externo, en­ tão apenas os títulos devem aparecer, ou o cliente contatará os colaboradores diretamente, sem passar pelo gerente do projeto. Os símbolos indicam os graus de autoridade ou de responsabilidade existentes entre as linhas e as colunas.

Guia PMBOKx, 5. ed. 9.1.2 Desenvolver o plano

«MXJSKÕfS» Muíwnuu Pepaor c Irsto de mate»»

frreretaes

□

Visíor foreeedores hepaor ordem de carpio

O

Ajtxitd 05 QOSlOS

A A O O □

ünjreçor ordens de compra bnpeãonor as irdénas0ras fce de cortnle de qtddode ALdra ori?jr« de iwtáo

□ □ A

Piepaor tekfóéo de «rrenlCM

□

Retira materra

O O O A □ A A A A A O

A □ □

□

O O o o 0

LfGEKDA O

d: cdonstKõo 9i':l

O

especdnxfc

A

tew ser consdtdo

A

Pode ser ccn$ut:do

□

tese sa nolfkodo

□

tewoprowr

FIGURA 5’2 Organograma linear de responsabilidade (matriz de responsabilidades).

NI’ Responsibility and assignment matrix (RAM), em tradução ofi­

cial da quarta edição do Guia PM BOKx, “Matriz de Responsa-

----------------------------------

bilidades (MR)".

1,13 Tradução para “1-inear Responsability Chart (LRC)".

150

Gerenciamento de Projetos

Exiavo :qí\te)'

& —

co o

Gerente do pcqeto Es(1ÚK defers

2

f

Atenta do

Marbos de àpotfoirerto (okbatdues *O6 fjXJO

Gererie do dmsoo AdrairJioçoo

-11-S o

2& n

11

£ ij

k A o o o A O o ♦ 0 A o o A A o o A

ts A

o

A

A

▲ A

is

li

13-S

£ 3 F

A O A A

it 11 e& 0 : — 43-S --è

o o o o □ □ IS.

■ □ o □ ■ n A

A

ií

£ 11

□ □ □

ts ts □ A A A

L ts ts A A A A

ií ca-o

□ ■ □ □ □

i-S P

ts

□ □

□

n a a □ □

A A

ts A

A □

k

•tào ndj reutaes de rtexomta ogeoiodas iegJonretile

• ‘Pode «ah de raeio pao taefa e pode se esirío ore ad ODotane-fe

♦ $era>:bnrte O Mersofcrerte a (ocfotme nweswfcde tslrfamol ■ kíKO

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 [( 3SI BUKtó M !:►$ X MOS £

n X

X

2

tebnKdenx»

X

X

As Figuras 5-4 e 5-5 são exemplos de OLRs modifi­ cados. A Figura 5-4 é usada para mostrar a distribuição de itens de dados, e a Figura 5-5 identifica a distribuição de competências no escritório de projetos.

3

(■■os tt «c d» nr

X

X

4

Ufa^denMb

x

X

X

X

A matriz de responsabilidades tenta responder a perguntas como: “Quem tem autoridade para assi­ nar?” “Quem deve ser notificado?” “Quem pode tomar

5

f
jur

X

X

X

X

FIGURA 5-4 Matriz de distribuição de dados.

X

X

X

X

151

FUNÇÕES DE GESTÀO

NmoonMiu

2

MftSHMOOMB KÍOMCUttflO CO •
l

m

0

0

b

b

*

—3 s ar

S

g

0

b

b

(

d

d

d

e

e

h

h

h

i

i

i

i

■

1

k

k

1

1

0

k

m

0

k

ffi

n

n

0

i

1

k

■

0

i

i

k 1

1

9

ei n

hepaam do espectapo

0

d

9

i

k

0

o

1

1 i

x

3 —*

(

e

h

z

c

d

9

i

ã

0

( d

s *

í

RatiónodoprojM)

Dewj'do sfJarc

s

(

1

PfcnejxwTo e projnfnxõo do actkcçremo

***

0

c

Safares de erage

Tüwkxõo eaixxo do day

o

CO

2

CS

at

sJ

0

n •

FIGURA 5-5 Matriz das habilidades pessoais.

O organograma linear dc responsabilidade, apesar de ferramenta valiosa para a gestão, tem um ponto fraco que é não descrever como as pessoas interagem dentro do programa. O OLR deve ser considerado com a organi­ zação para um pleno entendimento de como ocorrem as interações entre os indivíduos e as organizações. Os organogramas lineares de responsabilidade po­ dem resultar de requisitos impostos pelo cliente que es­ tejam acima e além das operações normais. Por exemplo, o cliente pode exigir, como parte de seu controle de qua­ lidade, que um determinado engenheiro fiscalize e apro­ ve todos os testes de certo item ou que outro indivíduo aprove todos os dados divulgados para o cliente, acima e além da aprovação do escritório de programas. Tais re­ quisitos do cliente necessitam de OI.Rs e podem causar rupturas e conflitos dentro de uma organização.

Diversos fatores importantes afetam a delegação de autoridade e dos deveres, tanto da alta administração para o gerenciamento de projetos quanto do gerencia­ mento de projetos para o gerenciamento funcional. Esses fatores incluem: • A maturidade da função do gerenciamento de projetos

• • • •

1 amanho, natureza e base de negócios da empresa Tamanho e natureza do projeto O ciclo de vida do projeto As capacidades de gestào em todos os níveis

Uma vez que se chegou a um acordo quanto à au­ toridade e o dever do gerente de projetos, os resultados devem ser documentados para delinear claramente seu papel no que se refere a: • Sua posição focal • Conflitos entre o gerente de projetos e os gerentes funcionais • Influência para atravessar as linhas funcionais e organizacionais • Participação na gestào principal e nas decisões técnicas • Colaboração na seleção do pessoal do projeto • Controle sobre a alocação e aplicação de recursos financeiros • Seleção de empresas terceiras • Direitos na resolução de conflitos • Voz na manutenção da integridade da equipe de projeto • Estabelecimento de planos de projeto

152

Gerenciamento de Projetos • Fornecimento de um sistema de informações eco­

5.4

nômico para o controle • Fornecimento de liderança na elaboração de re­

Existeumavariedadederelações (embora elas nem sem­ 9.1.2 Desenvolver o plano de recursos humanos: ferramentas pre sejam claramente defi­ etécnicas níveis) entre poder e auto­ ridade. Essas relações geralmente são medidas pelo poder “relativo” de decisão como uma função da estrutura de autoridade e são fortemente dependentes do modelo or­ ganizacional do projeto.

quisitos operacionais • Manutenção da ligação e do contato primários

com o cliente • Promoção de melhorias tecnológicas e gerenciais • Estabelecimento da organização do projeto duran­

te a vigência • Redução da burocracia

Talvez a melhor maneira de documentar a autorida­ de do gerente de projetos seja por meio do termo de aber­ tura do projeto, que é um dos três métodos, ilustrado na Figura 5-6, pelo qual o gerente de projetos obtém autori­ dade. Documentar a autoridade do gerente de projetos é necessário porque:

• Todas as interfaces devem ser mantidas da forma

mais simples possível • O gerente de projetos deve possuir autoridade para “forçar” os gerentes funcionais a renunciar aos padrões existentes e, eventualmente, estarem sujeitos a riscos • O gerente de projetos deve receber autoridade so­

bre os elementos de um programa que nào este­ jam sob seu controle. Isso normalmente acontece

por meio do respeito recebido dos indivíduos em questão • O gerente de projetos não deve tentar descrever

completamente a autoridade e os deveres exatos do seu pessoal do escritório de projetos ou dos membros da equipe. Como alternativa, ele deve incentivar a resolução de problemas, em vez da de­ finição de papéis

FIGURA 5-6 Tipos de autoridode do projeto.

INFLUÊNCIAS INTERPESSOAIS Guia PMBOK ,5. ed.

Considere as seguintes afirmações feitas por gerentes de projetos: • “Eu tenho tido boas relações de trabalho com o departamento X. F.les gostam de mim e eu gosto deles. Eu geralmente consigo avançar com qual­ quer coisa antes do prazo." • “Eu sei que é contra a política do departamento, mas os testes devem ser conduzidos de acordo com esses critérios ou então o resultado não fará senti­ do” (observação feita a um membro da equipe por um cientista pesquisador que foi promovido tem­ porariamente ao gerenciamento de projetos para um projeto de tecnologia avançada). Os gerentes de projetos geralmente são conhecidos por terem uma grande quantidade de autoridade delega­ da, mas pouquíssimo poder formal. Eles devem, portan­ to, fazer com que o trabalho seja realizado por meio do uso de influências interpessoais. Existem cinco influên­ cias interpessoais:

• O Poder Legítimo: a capacidade de obter o apoio porque o pessoal do projeto vê o gerente do projeto como oficialmente autorizado a emitir ordens. • O Poder de Recompensa: a capacidade de obter apoio porque o pessoal do projeto vê o gerente do projeto como capaz de, direta ou indiretamente, distribuir recompensas organizacionais importan­ tes (ou seja, salário, promoção, bônus, designações para trabalhos futuros). • O Poder de Punição: a capacidade de obter apoio porque o pessoal do projeto vê o gerente do pro­ jeto como capaz de, direta ou indiretamente dis­ tribuir punições que eles querem evitar. O poder de punição normalmente deriva da mesma fonte que o poder de recompensa, com um sendo uma condição necessária para o outro. ■ O Poder Especialista: a capacidade de obter apoio porque o pessoal vê o gerente do projeto como dono de um conhecimento especial ou como um especialista (o que os colaboradores funcionais consideram importante).

153

FUNÇÕES DE GESTÀO

• O Poder de Referência: a capacidade de obter apoio porque o pessoal do projeto se sente pessoal mente atraído pelo gerente do projeto ou pelo seu projeto. Os poderes especialista e de referência sào exem­ plos de poder pessoal que vem das qualidades ou carac­ terísticas pessoais às quais os membros da equipe são atraídos. Os poderes de recompensa, legítimo, e de pu­ nição são muitas vezes citados como exemplos de poder pela posição, os quais estão diretamente relacionados a uma posição dentro da organização. Os gerentes de li­ nha geralmente detêm grande poder pela posição. Mas em um ambiente de projetos, esse poder pode ser difícil de alcançar. Segundo Magenau e Pinto5:

Dentro da arena de gerenciamento de proje­ tos, toda a questão do poder pela posição fica mais problemática. Em muitas organizações, os gerentes de projetos atuam fora do padrão da hierarquia funcional. Embora essa posição permita-lhes certa liberdade de ação sem super­ visão direta, ela possui algumas desvantagens importantes e concomitantes, principalmente no que diz respeito ao poder pela posição. Pri­ meiro, porque os relacionamentos multifuncio­ nais entre o gerente do projeto e outros depar­ tamentos funcionais podem ser mal definidos, os gerentes de projetos rapidamente descobrem que possuem pouco ou nenhum poder legíti­ mo para simplesmente forçar as suas decisões pelo sistema organizacional. Os departamentos funcionais geralmente não têm de reconhecer os direitos dos gerentes dc projetos de interferir nas responsabilidades funcionais; consequen­ temente, os gerentes de projetos iniciantes que esperam contar com o poder pela posição para implementar os seus projetos são rapidamente desiludidos. Como um segundo problema no uso do po­ der pela posição, em muitas organizações, os gerentes de projetos possuem autoridade mí­ nima para recompensar os membros da equipe que, em virtude de serem subordinados tem­ porários, mantêm laços diretos e lealdade aos

5

seus departamentos funcionais. Na realidade, os gerentes de projetos podem nem mesmo ter a oportunidade de concluir uma avaliação de desempenho sobre esses membros temporários da equipe. Igualmente, por razões semelhantes, os gerentes de projetos podem ter pouca autori­ dade para punir comportamentos inadequados.

Portanto, eles podem descobrir que não podem nem oferecer a cenoura, nem ameaçar com o chicote. Como resultado, além do poder pela posição, muitas vezes é necessário que os geren­ tes de projetos eficazes procurem desenvolver as suas bases de poder pessoal. As seis situações seguintes são exemplos dc poder de referência (as duas primeiras são também poder de recompensa):

• O colaborador pode ser capaz de obter favores pes­ soais do gerente do projeto • O colaborador sente que o gerente do projeto é um vencedor e que as recompensas serão repassadas a ele. • O colaborador e o gerente do projeto têm laços fortes, como as duplas de golfe durante as partidas * foursome 1* • O colaborador gosta da forma como o gerente do projeto trata as pessoas • O colaborador quer identificação com um deter­ minado produto ou linha de produto • O colaborador tem problemas pessoais e acredita que pode obter empatia ou compreensão do ge­ rente do projeto Assim como o poder relativo, as influências inter­ pessoais podem ser identificadas com vários modelos organizacionais de projeto quanto ao seu valor relativo. Isso pode ser visto na Figura 5-7.

Para qualquer estrutura temporária de gerencia­ mento ser eficaz, deve haver um equilíbrio racional de poder entre o gerenciamento funcional e de projetos. Infelizmente, um equilíbrio de poder em igualdade é, mui­ tas vezes, impossível de se obter, pois cada projeto é ine­ rentemente diferente de outros, e os gerentes de projetos possuem diferentes habilidades de liderança.

O alcance desse equilíbrio é um desafio sem fim para a administração. Se as restrições de tempo e custos

MAGENAU, John M.; PINTO, Jeffrey K. Power. Influence, and ne­

No golfe, a partidafoursome (quarteto, em tradução livre), é uma

gotiation in project management. In: MORRIS, Peter G.; PINTO,

competição entre duas equipes que consistem de dois jogadores

Jeffrey (eds.). Project organization and project competencies. Wiley.

cada. Os jogadores alternam os buracos, mas cada dupla com­

2007. p. 91. Reproduzido com permissão da John Wiley.

partilha a mesma bola.

154

Gerenciamento de Projetos

de um projeto não puderem ser cumpridas, a influência

do projeto na tomada de decisões aumenta, como pode ser visto na Figura 5-7. Se as restrições de tecnologia ou desempenho precisarem de reavaliações, então prevalece­ rá a influência funcional no processo decisório.

Independentemente de quanta autoridade e poder um gerente de projetos desenvolva ao longo do curso do projeto, o fator principal na sua capacidade de con­ seguir com que o trabalho seja realizado é o seu estilo de liderança. O desenvolvimento de laços de confiança, amizade e respeito com os colaboradores funcionais pode promover o sucesso.

BARREIRAS AO DESENVOLVIMENTO DA EQUIPE

5.5

DO PROJETO

A maioria das pessoas nas organizações orientadas e 9.3 Desenvolvera equipe do não orientadas a projetos projeto tem diferentes pontos de vista sobre o gerenciamento de projetos. A Tabela 5-1 compara os pontos de vista funcionais e de projetos em relação ao gerenciamento de projetos. Esses diferentes pontos de vista podem criar barreiras cruéis para as ope­ rações bem-sucedidas do gerenciamento de projetos. Guia PMBOK , 5. ed.

*

K— iiant ----------- w-Jit» w--------- 3UC» --------- ► hirttthcvd boi tantteAM*

ÉfriT

Frams

w

K-iW’it’nite-H * brefiwK > M

c

^

Frorui

M— ífitx ------------------ üíwQüiíe facdétan IrinuiBthft

--------- 'rtwíe —> litfrzh:»:

FIGURA 5-7 O leque de alternativas.

Fonto GALBRAITH, Jay R. Matrix organization designs. Reproduzido com o permissão de Buúneu Hoózont. lev 1971. p. 37. Copyright O 1971 pelo Conselho de Curadores do Universidade de Indiana.

A compreensão de barreiras à construção da equipe do projeto pode ajudar no desenvolvimento de um ambiente propício para o trabalho eficaz em equipe. As seguintes bar­ reiras são comuns em muitos ambientes de projetos. Perspectivas, Prioridades e Interesses Diferentes: existe uma grande barreira quando os membros da equi­

TABELA 5-1 Comparação dos pontos de vista funcional e de projetos Fenômenos

Ponto de Vista de Projetos

Ponto de Visto Funcional

faotome orgenizoeionol Unhostoff

Vestiges do modele hierárqukc permanecem: as funções de linho são

As funções de fcnho possuem responscbikdode dreta peto reoizoçoo

colocadas em uma posição de apoio. Há uma Ibo de autorMiodee

dos objetivos; o Imlu comando e a assessors (stdf) oconseba.

responscUidode

Princípio escolar

Rekxoo chefesubcrdmodo

Otjetr/os orgorizacionois

Existem elementos da codeio verticd, mas o ênfase pnncpd é dada oo

A codeto dos relocionomentos de ajtondode ocorre do superior para

fluxo de trabalho horizontal e doçend. 0 trobdho importante é conduzido

o subordinado em toda a organização. 0 trebelho centrd, crucol e

conforme a legitimidade do tarefo exige.

importante e conduzido poro cimo e pora baxo no hierorqito verlkol.

Retoconcmentos entre pores, entre gerente e especialistas técnicos, entre

Essa é o rebçoo mas importante; se monhdo sodn, baverá sucesso.

colaboradores etc. Os relocionomentos são utiizodcs poro conduzir boo

Iodos os negóccs importantes são ccnduzdcs em uma estruturo

pane dos negócios proeminentes.

pranidol de chefes e subordnodos.

0 gerenciamento de um projeto se torno uma joint venture de vaias

Os objetivos do orgarização são buscados pelo unidode pnrcipol

organizações retotivomwte independentes. Dessa formo, o objetivo se

(um conjunto de subocganizoçóes) que trobolho em seu ombiente. 0

torno muhilaterol.

objetivo é urtoterol.

0 gerente de pqetos gerencio por intermédio das Irias organizacionais e

0 diretor gerd atuo como um chefe único poro um grupo de atividades

funcionais paro alcança im objetivo intacrçanizocicnol comum.

que estão no mesmo plano.

Paxkxfe de cutoridode e

Existem eporturidodes consideráveis poro (pe os responseblidades do

Consistente com o gerenciamento funcional. o integidode do

respcnscbilidcde

gerente de projetos excedam o suo outocidode. Os profissionais de opao

reknooomento chefwubcrdrodo é mantido pa mero do outondode

gerolmente respenefem o outros gerentes (funcionais) quanto o solene,

funcionei e dos serviços de occnselhcmerto do ossesseno (staff).

Urxkxfe de (fireçõo

rebtórios de desempenho, promoções etc.

Duroçoo de terrpe

0 projeto (e, consequentemente, o suo orgcnizococ) é finito em suo

Terde o se perpetuar pro fornecei apoio fociitodor cortínuc.

duração.

Fonte. CLELAND, David I. Project Monogemenr. In: CLELAND, David I.; KING, Wiliam R. (eds.|. Syttemt orgontzokont. onotyvs. monogement o book of reodmgs. New

York: McGraw-Hill, 1969. p. 281-290. © 1969 por McGraw-Hill Reproduzido com permissão da editora.

FUNÇÕES DE GESTÀO

pe têm objetivos e interesses profissionais que são dife­ rentes dos objetivos do projeto. Esses problemas são agra­ vados quando a equipe precisa apoiar organizações que têm interesses e prioridades diferentes.

Conflitos de Papéis: os esforços de desenvolvimen­ to da equipe são frustrados quando existem conflitos de papéis entre os membros da equipe, como ambiguidade sobre quem faz o quê dentro da equipe do projeto e nos grupos externos de apoio.

Objctivos/Resultados do Projeto não Claros: objetivos não daros de projeto frequentemente geram conflitos, am­ biguidades e lutas por poder. Torna-se difícil, senão impossí­ vel, definir claramente os papéis e as responsabilidades.

Ambientes Dinâmicos de Projeto: muitos projetos operam em um estado constante de mudança. Por exem­ plo, a alta administração pode ficar mudando o escopo, os objetivos e a base de recursos do projeto. Em outras situações, mudanças regulatórias ou demandas do clien­ te podem afetar drasticamente as operações internas de uma equipe de projeto.

Competição Pela Liderança da Equipe: os líderes de projetos frequentemente mencionaram que essa barreira ocorre preferencialmente nas fases iniciais de um projeto ou se o projeto estiver com graves problemas. Obviamente, tais casos de desafio da liderança podem resultar em bar­ reiras à construção da equipe. Frequentemente, esses são desafios disfarçados para a capacidade do líder do projeto. Falta de Definição da Equipe e de Estrutura: mui­ tos diretores se queixam de que o trabalho em equipe é severamente prejudicado porque não há deveres clara­ mente definidos das tarefas e estruturas de subordina­ ção. Encontramos essa situação mais prevalentemente em ambientes de trabalho dinâmicos e desestruturados organizacionalmente, tais como em projetos de sistemas de informação e P&D. Um padrão comum é que um de­ partamento de apoio é encarregado de uma tarefa, mas nenhum líder é claramente delegado para o dever. Como consequência, alguns funcionários estão trabalhando no projeto, mas não estão total mente esclarecidos sobre a ex­ tensão dos seus deveres. Em outros casos, os problemas resultam quando um projeto é apoiado por vários depar­ tamentos, sem coordenação interdisciplinar. Seleção do Pessoal da Equipe: essa barreira se de­ senvolve quando os colaboradores se sentem tratados injustamente ou ameaçados durante a seleção de pessoal para um projeto. Em alguns casos, o pessoal do projeto é designado a uma equipe pelos gerentes funcionais, e o gerente do projeto pode oferecer pouca ou nenhuma contribuição ao processo de seleção. Isso pode impedir os esforços de desenvolvimento da equipe, principal­ mente quando o líder do projeto recebe o pessoal que

155 está disponível, em vez dos melhores membros, escolhi­ dos a dedo. A designação de “pessoal disponível” pode causar vários problemas (por exemplo, baixos níveis de motivação, membros de equipe descontentes e descompromissados). Descobrimos que, via de regra, quanto mais poder o líder do projeto tem sobre a seleção dos membros de sua equipe e, quanto mais houver acordos negociados relativos às tarefas designadas, maior será a probabilidade de que os esforços de construção da equi­ pe sejam frutíferos.

Credibilidade do Líder do Projeto: os esforços de construção da equipe sào prejudicados quando o líder do projeto tem baixa credibilidade na equipe ou entre os outros gerentes. Em tais casos, os membros da equipe muitas vezes são relutantes em se comprometer com o projeto ou com o líder. Problemas de credibilidade po­ dem vir de habilidades gerenciais ruins, decisões técnicas ruins, ou falta de experiência relevante para o projeto.

Falta de Comprometimento dos Membros da Equi­ pe: falta de comprometimento pode ter várias fontes. Por exemplo, os membros da equipe possuem interesses pro­ fissionais em outros lugares, o sentimento de insegurança que está associado aos projetos, a natureza pouco clara das recompensas que podem vir após a conclusão bem-sucedi­ da e conflitos interpessoais intensos dentro da equipe. A falta de comprometimento dos membros da equipe pode ser resultado de atitudes suspeitas existentes entre o líder do projeto e um gerente funcional de apoio, ou entre dois membros da equipe pertencentes a dois departamentos funcionais em guerra. Itor fim, baixos níveis de comprome­ timento podem ocorrer quando uma “estrela”“exige" esfor­ ço demasiado de outros membros ou exige muita atenção do líder da equipe. Um líder dc equipe colocou dessa ma­ neira: “Muitas equipes possuem suas estrelas e você aprende a viver e trabalhar com elas. Elas podem ser fundamentais para o sucesso global. Mas algumas estrelas podem ser tão exigentes com todo mundo que acabam minando a moti­ vação da equipe”. Problemas de Comunicação: não surpreendentemen­ te, a má comunicação é um inimigo importante para o desenvolvimento de equipes eficazes. A má comunicação existe em quatro níveis principais: problemas de comuni­ cação entre os membros da equipe, entre o líder do projeto e os membros da equipe, entre a equipe do projeto e a alta administração e entre os líderes do projeto e o cliente. Mui­ tas vezes, o problema é causado por membros da equipe que simplesmente não mantêm os outros informados so­ bre importantes desenvolvimentos do projeto. No entanto, os porquês de padrões ruins de comunicação são muito mais difíceis de determinar. O problema pode ser resultado

156

Gerenciamento de Projetos

de baixos níveis de motivação, baixo moral ou descuido. Também foi descoberto que padrões ruins de comunicação

entre a equipe e os grupos de apoio geram graves proble­ mas de construção da equipe, bem como má comunicação com o cliente. Práticas ruins de comunicação muitas vezes levam a objetivos obscuros e a deficiências no controle, na coordenação e no fluxo de trabalho do projeto.

Ausência de Apoio da Alta Administração: os líde­ res de projetos, muitas vezes sugerem que o apoio e o comprometimento da alta administração não são claros e estão sujeitos a crescer e a minguar durante o ciclo de vida do projeto. Esse comportamento pode causar uma sensação desconfortável entre os membros da equipe e diminuir os níveis de entusiasmo e comprometimento com o projeto. Dois outros problemas comuns são que a alta administração muitas vezes não ajuda a definir o ambiente certo para a equipe do projeto no início, nem forneça à ela feedbacks periódicos sobre o seu desempe­ nho e suas atividades durante a vida do projeto.

Os gerentes de projetos que estão realizando com su­ cesso o seu papel não só reconhecem essas barreiras, mas também sabem quando elas são mais suscetíveis a ocor­ rer durante o ciclo de vida do projeto. Além disso, esses gerentes realizam ações preventivas e, normalmente, pro­ movem um ambiente que contribui para o trabalho em

equipe. O construtor eficaz da equipe é geralmente um arquiteto social que compreende a interação das variáveis organizacionais e de comportamento e que pode fomen­ tar um clima de participação ativa e de conflito mínimo. Isso requer habilidades cuidadosamente desenvolvidas em liderança, administração, organização e conhecimen­ to técnico sobre o projeto. Contudo, além das competên­ cias delicadamente equilibradas de gestão, a sensibilidade do gerente de projetos para as questões fundamentais subjacentes a cada barreira pode ajudar a aumentar o sucesso no desenvolvimento de uma equipe eficaz para o projeto. As sugestões específicas para a construção da equipe são antecipadas na Tabela 5-2. 5.6

SUGESTÕES PARA LIDAR COM A EQUIPE

RECÉM-FORMADA

O maior problema enfrentado por muitos líderes de pro­ jetos é gerenciar a ansiedade que comumente se desen­ volve quando uma nova equipe é formada. A ansiedade vivida pelos membros da equipe é normal e previsível, mas é uma barreira para conseguir ter uma equipe rapi­ damente focada na tarefa.

Essa ansiedade pode vir de várias fontes. Por exemplo, se os membros da equipe nunca trabalharam com o líder do projeto, eles podem estar preocupados com o seu esti­ lo de liderança. Alguns membros da equipe podem estar preocupados com a natureza do projeto e se o projeto irá condizer com seus interesses e capacidades profissionais, ou se ajudará ou prejudicará suas aspirações de carreira. Além disso, os membros da equipe podem estar altamente preocupados com rupturas do estilo de vida/estilo de tra­ balho. Conforme um gerente de projetos observou, “mu­ dar a mesa de um membro da equipe de um lado da sala para o outro, às vezes, pode ser quase tão traumático como deslocar alguém de Chicago para Manila.”

Outra preocupação comum entre as equipes recém- formadas é se haverá uma distribuição equitativa da carga de trabalho entre os membros da equipe e se cada membro será capaz de carregar o seu próprio peso. Em algumas equipes recém-formadas, os membros não só devem realizar o seu próprio trabalho, como também devem treinar outros membros da equipe. Com certeza, isso é suportável, mas quando se torna demais, aumenta a ansiedade.

Certas medidas tomadas no início da vida de uma equipe podem diminuir os problemas aqui citados. Primeiro, recomendamos que o líder do projeto converse com cada membro da equipe, um de cada vez, sobre o seguinte: 1. Quais são os objetivos do projeto. 2. Quem estará envolvido e por quê. 3. A importância do projeto para a organização ge­ ral ou unidade de trabalho. 4. Por que o membro da equipe foi selecionado e designado para o projeto. Qual o papel que ele vai desempenhar. 5. Quais vantagens poderíam ser concretizadas se o projeto for concluído com sucesso. 6. Quais problemas e restrições podem ser encon­ trados. 7. As regras do caminho que será seguido no ge­ renciamento do projeto (por exemplo, reuniões periódicas de avaliação do andamento). 8. Quais são as sugestões do membro da equipe para alcançar o sucesso. 9. Quais são os interesses profissionais dos mem­ bros da equipe. 10. Qual desafio o projeto vai apresentar aos mem­ bros individuais e à toda a equipe. 11. Por que o conceito de equipe é tão importante para o sucesso do gerenciamento do projeto e como ele deve funcionar.

157

FUNÇÕES DE GESTÀO

TABELA 5-2 Borreiras à construção eficaz do equipe e abordagens sugeridos de tratamento

Boneira

Sugestões poro o Gerenciamento Eficaz dos Barreiras (Como Diminuir ou Biminar as Barreiras)

Diferentes perspectivas, prcndades,

Fozer um esforço no irício do «Io de vido do projeto para descobri essas diferenças corfitantes. Explica tctolmente o esccpo do projeto e as

interesses e julgamentos dos

recompensas que pedem surgir no conclusão bem sucedido do projeto. Promover c conceito de 'equipe' e explka as responsobíidodes. fenlar

membros do equipe

combinar os interesses ixhiduois com os objetivos gerais do projeto.

Ccnfttos de popas

0 mois cedo possível, perguntar oos membros da equipe aide des se veem no projeto. Detamba como lodo o projeto pede sa dviddo em

subsrstemas e taefos (ou sejo, a estrutura cnolika do projeto). Designer/negocia papas. Conójzir reuniões regubres de andamento para

manter a equipe irformodo sobre o progresso e fica alento para ontecipor ccnfttos de popas oo longo do vido cfo projeto. Objerivos/resuhodos de projeto

nõo daras

Garartir que todos as portes compreendam os objetivos geras e intadsciplnoies do piejeto. A ccmunkoçòo cloro e frequente com a aha

edminisiração e com o dierte se torna crtiaimente importaite. As reuniões de ovdioçõo do ondanento pedan ser uílzodas paro feedback.

Firdmente, um nome adequado para a eqjipe pode ejuder o reforçar as objetivas do projeto.

Ambientes dinâmcos de projetos

0 grande efesdio é estebiea as rifbênoas enemas, ftanaro, cobborodcwes mportonss devem agoniza um ocorch sobre o dieçm çrncçol do

prqero e 'pranova' essa dreçoc pora todo o equipe. Tarrbém, ectoca a dto odmrtstioçòo e o dierte sebre os caisequênoas çrepdoas efe mudanças nõo jjshfradas. É extiananate impcrtorte çreva o 'ambiente' dento do qud o projeto será desewdvido. Desarvote pianos de caiingênco.

Ccmpetcoo peto lidaonço do equipe

A alto adminrslracoo deve quda o estobdeca o papel de liderança do gerente do projeto. Por outro lodo, o gaenle do projeto de«e cumprir as

expectativas das membros do equpe. A definição doto de popd e respcnsobàdode matos vezes diminui o competição peb Waonço. Fdto de definição do equpe e de estruturo

Os líderes de protetos devem 'pranova' o concalo de equipe pora o oh odminisfioçoo, bem como pao os membros. Reuniões regubres roo

reforçar o sentido de equpe, assim como tarefas, popas e lesponsobtóodes doremenre definidos. Também, o visbilidode de memorandos e

outros formulários escritos, assim como o paticipoçòo do oho odministioçòo e do diente, pedem uníica o equipe. Seleçoo do pessod poro o projeto

Terta negoaor as designações do poplo can os potenciais membros do eqj pe. Drscuhr daomerte com eks sebre o mportôncD do projeto, o pepd de

e as

codo um, qjas reccmpaisas podem resulta cpás o caxlusõo 'regas gerais do togo' pao o gerencnmento do prqeto. Finohate, se as menbros do eqjpe pamcraaem desnlaessodos, ertòo de * ser considerado o siteíluição.

GedNidode do Her do proieto

A credbilidode do lida do projeto ertre os membros do equipe é enxtai 6o cresce com o imogem de um tomodor de decisões seguro, tonto no

gestóo gad, (ponto no conhecimento técnico de rekvcndo. A crediMidode pode oumentor owes do idocionamento do lidei do projeto com outros gaentes inportontes que opoian os esforços do equipe. Foh de comprometimento do membro do equipe

fentor deteimnar o fdto de comprometimento do membro do equipe no inicio do vida do projeto e tentar mudai possíveis visões negativos. Muitos vezes, o inseguaiço é o principal motivo pao o fdto de comprometimento; rental determina pa que elo existe e,

aitoo, trabobor no diminuçoo dos receios dos membros do equipe. Os ccnfttos com outros membros podem sei outro motivo pao o falto de comprometimento. É importante que o lidei do projeto ntervenha e intermedeie o confiro rapidamente. Finolmente, se os intaesses profissronas de um membro da equipe estiverem em outro lugar, o líder do projeto deve procurar moreiras de satisfazer porte desses

interesses ou considaa o substituição. PrcWemas de comumcoçòo

0 líder do protelo deve dedica cm tempo considerável pora o canunicoção com os membros indviduors do equpe sobre as suas necessidades e

preocupoçoes. Além cfcso, ele deve prover umo formo de sessões penõócos pora ncentrva as comunkoçóes entre os contribuintes mdviduas do equ Na expressão em inglês. Arrow Diagramming Method (ADM). KT* Na expressão em ingles. Precedence Diagramming Method (PDM).

344 As estruturas analíticas de projeto podem ser utili­ zadas para estruturar o trabalho para o alcance de tais objetivos, como redução de custos, redução do absenteísmo, aumento do moral e diminuição dos fatores de descarte. A menor subdivisão agora se torna um item final ou subobjetivo, não necessariamente um pacote de trabalho, conforme descrito aqui. No entanto, uma vez que estamos descrevendo o gerenciamento de projetos, para o restante do texto vamos considerar como o nível mais baixo o pacote de trabalho.

Uma vez que a F.AP está estabelecida e que o pro­ grama é iniciado, torna-se um procedimento muito dis­ pendioso tanto adicionar quanto excluir atividades, ou modificar os níveis de relatório, por causa do controle de custos. Muitas empresas não dão atenção preventiva à importância de uma EAP adequadamente desenvol­ vida, e, finalmente, arriscam-se a ter problemas de con­ trole de custos mais adiante. Um uso importante da EAP é que ela serve como um padrão de controle de custos para quaisquer atividades futuras que possam se seguir ou que apenas podem ser parecidas. Um erro comum cometido pela administração é a combinação de ativida­ des de apoio direto com atividades administrativas. Por exemplo, o gerente do departamento de engenharia de produção pode ser obrigado a fornecer apoio adminis­ trativo (possivelmente por meio da participação em reu­ niões de equipe) durante toda a duração do programa. Se o apoio administrativo for estendido a cada um dos projetos, é obtida uma falsa imagem quanto às horas re­ ais necessárias para realizar cada projeto no programa. Se um dos projetos for cancelado, então a quantidade de homens-horas de apoio para o programa total seria re­ duzida quando, na verdade, as funções administrativas e de apoio podem ser constantes, independentemente do número de projetos e tarefas.

Gerenciamento de Projetos

no gerenciamento de programas sem o uso de estrutu­ ras analíticas de projeto, especialmente em programas de tipo repetitivo. Como foi o caso com a DT, também exis­ tem orientações para a elaboração da EAP *: • Desenvolva a disposição da EAP, por meio da subdivisão do esforço total em subelementos dis­ tintos e lógicos. Normalmente um programa se divide em projetos, sistemas principais, subsiste­ nces principais e vários níveis inferiores, até que um nível de elemento de tamanho gerenciável seja alcançado. Podem ocorrer grandes variações, de­ pendendo do tipo de esforço (por exemplo, desen­ volvimento de grandes sistemas, serviços de apoio etc.). Incluir mais de um centro de custos e mais de um fornecedor, se isso refletir a situação real. • Verifique a EAP proposta e os esforços contem­ plados quanto à integralidade, compatibilidade e continuidade. • Determine que a EAP atenda tanto aos requisitos funcionais (engenharia/produção/testes) quanto aos requisitos de programa/projeto (equipamen­ tos, serviços etc.), incluindo os custos recorrentes e não recorrentes. • Verifique para determinar se a EAP fornece a sub­ divisão lógica de todo o trabalho do projeto. • Estabeleça a designação de responsabilidades para todos os esforços identificados para as organiza­ ções específicas. • Verifique a EAP proposta em relação aos requisitos de relatório das organizações envolvidas.

Gvio PMBOK , S. ed.

5.42.1 EAI’

• Desenvolva uma EAP preliminar nào inferior aos três níveis superiores para propósitos de solicita­ ção (ou inferior se for considerado necessário por alguma razão especial). • /\ssegure-se de que o fornecedor seja obrigado a estender a EAP preliminar em resposta à solicita­ ção, para identificar e estruturar todo o trabalho do fornecedor como sendo compatível com sua organização e sistema de gerenciamento. • Na sequência das negociações, a estrutura da de­ composição do trabalho contratado EAP do con­ trato) incluída no contrato, normalmente não deve se estender além do terceiro nível.

Muitas vezes as estruturas analíticas de projeto que acompanham as RFPs do cliente contêm muito mais es­ copo do trabalho, como especificado pela declaração do trabalho, do que o financiamento existente irá suportar. Isso é feito intencionalmente pelo cliente na esperança de que um fornecedor possa querer aceitar. Se o preço do fornecedor exceder as limitações de financiamento do cliente, então o escopo do trabalho deve ser reduzido, por meio da eliminação de atividades da EAP. Por intermé­ dio do desenvolvimento de um projeto separado para as atividades administrativas e indiretas de apoio, o cliente pode facilmente modificar os seus custos, eliminando as atividades diretas de apoio do trabalho cancelado.

Antes de prosseguirmos, deve haver uma breve dis­ cussão sobre a utilidade e a aplicabilidade do sistema da EAP. Muitas empresas e indústrias têm sido bem-sucedidas

Há também listas de verifi­ cação que podem ser utiliza­ das na elaboração da EAP9:

*

Handbookforpreparation of work breakdown structures, XH B5610.1,

Agência Espacial Norte-Americana, fev. 1975. ’

Ver nota 8.

345

PLANEJAMENTO

• Assegure-se de que a estrutura da decomposição do trabalho contratado negociada seja compatível com os requisitos de relatório. • Assegure-se de que a estrutura da decomposição do trabalho contratado negociada seja compatível com a organização e com o sistema de gerencia­ mento do fornecedor. • Reveja os elementos da estrutura da decomposição do trabalho contratado para garantir a correlação com: • A árvore de especificações « Os itens de linha do contrato • Os itens finais do contrato • Os itens de dados necessários • As tarefas da declaração do trabalho • Os requisitos do gerenciamento de configuração • Defina os elementos da estrutura da decomposi­ ção do trabalho contratado até o nível em que tais definições sejam significativas e necessárias para fins de gerenciamento (dicionário da EAP). • Especifique os requisitos de relatório para os ele­ mentos selecionados da estrutura da decompo­ sição do trabalho contratado, se forem desejadas variações dos requisitos padronizados de relatório. • Assegure-se de que a estrutura da decomposição do trabalho contratado abranja esforços, níveis de esforço, esforços divididos e subcontratos mensu­ ráveis, se aplicável. • Assegure-se de que os custos totais de um deter­ minado nível serão iguais à soma dos custos dos elementos constituintes do nível imediatamente inferior. Em projetos simples,a EAP pode ser construída como um “diagrama de árvore” (ver a Figura 11 -5), ou de acordo com o fluxo lógico. Na Figura 11-5, o diagrama dc árvore pode acompanhar o trabalho ou mesmo a estrutura or­ ganizacional da empresa (ou seja, divisão, departamento, seção, unidade). O segundo método é criar um fluxo lógi­ co (ver Figura 12-21) e agrupar determinados elementos para representar tarefas e projetos. No método de árvo­ re, as unidades funcionais de nível mais baixo podem ser atribuídas a um, e somente um, elemento de trabalho; en­ quanto no método do fluxo lógico, as unidades funcionais de nível mais baixo podem servir vários elementos da EAP.

Existe uma tendência para desenvolver diretrizes, políticas e procedimentos para o gerenciamento de pro­ jetos, mas não para o desenvolvimento da EAP. Algumas empresas têm sido ligeiramente bem-sucedidas no desen­ volvimento de uma metodologia “genérica” para os níveis 1,2 e 3 da EAP para aplicar em todos os projetos. As dife­ renças aparecem nos níveis 4,5 e 6.

1

Quánito

Mecôiico Délro FIGURA 11-5 Diagrama de árvore da eap.

A tabela a seguir mostra os três métodos mais co­ muns para a estruturação da EAP: Método

Nível

Fluxo

Gelo de Vido

Orgonáotóo

Progromo Projeto Wo Subtorefo Pocote de Trcbalho Nível de Esforço

Programo Sistema Subsistemo Pessoas Pessoas Pessoa

Propano GdodeVidj Sstema Subsistemo Pesscas Pesscas

Programo Divisão Deporfomento Seçõo Pessoas Pessoas

O método do fluxo divide o trabalho em sistemas e subsistemas principais. Esse método é adequado para projetos de menos de dois anos de duração. Para proje­ tos mais longos, usamos o método do ciclo de vida, que é semelhante ao método de fluxo. O método da orga­ nização é usado para projetos que podem ser repetiti­ vos ou exigir muito pouca integração entre as unidades funcionais. 11.14

DICIONÁRIO DE ESTRUTURA ANALÍTICA DO PROJETO

As estruturas analíticas do projeto (EAP) são na verdade sistemas de numeração como o da última coluna da Tabe­ la 11 -3. Muitas vezes, textos são adicionados à EAP para dar clareza. Como exemplo, softwares de gerenciamento de projetos tratam a EAP como um sistema de numera­ ção, mas podem pedir uma descrição do pacote de tra­ balho e o nome ou as iniciais da pessoa responsável por aquele pacote de trabalho.

Talvez a melhor maneira de entender o significado e a intenção de cada pacote de trabalho seja usar um di­ cionário da EAP. Para cada elemento na EAP, o dicionário fornece uma breve descrição, o nome da pessoa ou do cen­ tro de custos responsável por aquele elemento, tal como numa matriz de responsabilidade, de marcos do elemento

346

Gerenciamento de Projetos

e a entrega final. O dicionário da EAP pode também iden­ tificar o custo associado àquele elemento, o número de co­ brança a ser utilizado, e os recursos necessários, por nome ou nível de habilidade. O dicionário também pode forne­ cer uma descrição técnica detalhada de cada elemento e listagem cruzada com outros elementos da EAP, requisitos de qualidade e documentação contratual. O dicionário da EAP também é ligado ao formulário de autorização de tra­ balho do projeto, discutido no Capítulo 15. A EAP e o dicionário da EAP podem ser usados para embasar o processo de verificação do escopo. Norman, Brotherton, e Fried afirmam que10:

Durante a execução do projeto, a validação das entregas pode ser feita referenciando as entre­ gas da forma como foram descritas na EAP e no Dicionário da EAP. Uma vez que a EAP e Dicio­ nário da EAP descrevem as entregas do projeto, incluindo os critérios de aceitação e conclusão, estes se tornam então o ponto de referência para a validação e aceitação das entregas con­ cluídas. A EAP e o Dicionário da F.AP, muitas vezes são utilizados adicionalmente como linha de base para monitorar e medir “desejos” e “ne­ cessidades” versus o escopo do projeto que foi acordado. Isso garante que o projeto não tente produzir resultados que não estão incluídos nos requisitos. A F.AP e o Dicionário da F.AP aju­ dam a garantir que a equipe do projeto tente entregar resultados ou qualidade que nào ex­ cedam os limites dos requisitos, enquanto tam­ bém contêm c controlam o scope creep. A EAP e o Dicionário da EAP ajudam a apoiar as comunicações entre o gerente do projeto, a equipe de projeto, o(s) patrocinador(es) e as partes interessadas, em relação ao conteúdo e aos critérios de conclusão para as entregas do projeto. Sem antes desenvolver a EAP, frequen­ temente os critérios para aceitação e conclusão da entrega são mal definidos, levando a mal-en­ tendidos e discordância sobre a conclusão dos resultados específicos do projeto. À medida que o trabalho prossegue no pro­ jeto, a EAP pode ser usada como uma lista de verificação para determinar quais entregas foram ou nào foram concluídas ou aceitas. Quando comunicada por meio do relató­ rio de status ou por meio de outros veículos

10

Veja nota 7, p. 338.

constantes no Plano de Comunicação do pro­ jeto, isso ajuda a garantir que todas as partes interessadas do projeto entendem claramente o estado atual do projeto.

Ao final do projeto, a verificação do escopo apoia a transição do projeto para operações continu­ adas, bem como o encerramento de quaisquer contratos ou subcontratos em aberto. Aqui, no­ vamente, a EAP é usada como a base para verifi­ cação e como entrada chave para os processos de encerramento de contrato e de projeto. 11.15

0 PAPEL DOS EXECUTIVOS NA SELEÇÃO

DE PROJETOS

Uma responsabilidade pri­ mordial da alta adminis­ Capitulo 4 Integração 4.1.2 Desenvolver o termo de tração (e possivelmente dos abertura do projeto: ferramenus patrocinadores de projetos) etécnicas é a seleção de projetos. A maioria das organizações possui critérios de seleção esta­ belecidos, que podem ser subjetivos, objetivos, quantitati­ vos, qualitativos ou simplesmente uma aposta baseada na intuição. Em qualquer caso, deve haver um motivo válido para a seleçào do projeto. Guia PMBOK’, 5. ed.

De uma perspectiva financeira, a seleção de proje­ tos é basicamente um processo de duas partes. Primeiro, a organização irá realizar um estudo de viabilidade para determinar se o projeto pode ser realizado. A segunda parte é realizar uma análise de custo-beneficio para ver se a empresa deve realizá-lo.

O objetivo do estudo de viabilidade é confirmar que o projeto atende às viabilidades de custos, tecnológica, de segurança, de comercialização e facilidade para a execu­ ção dos requisitos. A empresa pode usar consultores ex­ ternos ou especialistas SME para ajudar tanto nos estudos de viabilidade quanto nas análises de custo-benefício. Um gerente de projetos não pode ser designado até que o es­ tudo de viabilidade esteja concluído.

Como parte do processo de viabilidade durante a seleção de projetos, a alta administração muitas vezes solicita a participação de SM Es e de gerentes de nível inferior pelos modelos de classificação. Os modelos de classificação normalmente identificam as empresas e/ ou critérios técnicos em relação ao qual as classificações serão feitas. A Figura 11-6 mostra um modelo de escala para um único projeto. A Figura 11-7 mostra um siste­ ma de classificação de lista de verificação para avaliar três projetos ao mesmo tempo. A Figura 11-8 mostra um modelo de pontuação para vários projetos utilizan­ do as médias ponderadas.

347

PLANEJAMENTO

(SOJA

Fl

-1 |

cwcs

CBTttCS

x

x"X-

___________

Fl fagr» sofre

_______

H Perqfotttajrc___________ M hgoxeg'fclSrgr________

~I

____

1 OfawiiàAdetegd________ I {ooaeaes________

X

4

(BI90S KP0«tK/O s

R____________ | —

X

POHIUJW fOMlXJfl DOSiMMS-

PtOMTOS

X

m QIAWCE« Xj

(CMOS: .2-EXEIH1E «UMM C-WO&L -UtUtt luaiúfli

5

3

2

7

7

- UO AMJWÍI

FIGURA 11-6 Ilustração de um modelo de escala para um projeto.

PtMIOO

10

6

4

3

69

PtOMTOE

5

10

10

5

75

PtOJEIOF

3

7

10

10

63

^iumo low

Souder, Wiliam E. Project selection and economic appraisal, p 66

Se o projeto for considerado viável e com urn bom ajuste ao plano estratégico, então o projeto é priorizado para desenvolvimento, juntamente com outros projetos. Uma vez que a viabilidade está determinada, uma análise de custo-benefício é realizada para confirmar que o projeto, se executado corretamente, fornece os benefícios financeiros e nào financeiros exigidos. As análises de custo-benefício exigem significativamente mais informações para serem examinadas do que geralmente estão disponíveis durante um estudo de viabilidade. Isso pode ser uma proposta cara.

l:pww) ws cuitoos i ’íwmo ws artoos)

FIGURA 11-8 Ilustração de um modelo de pontuação.

Projeto A Forno

uai -

•tsaa io-Exam i - imcbtAyh

Font»:

Souder, Wiliam. Project selection and economic appraisal, p. 69.

Guia PMBOK ,5. ed.

5.3 Definir o escape 5.3.22 Análise do produto

A estimativa dos benefícios e dos custos de forma opor­ tuna é muito difícil. Os be­ nefícios são frequentemente

definidos como:

e Benefícios tangíveis para os quais o dinheiro pode

ser razoavelmente quantificado e medido, • Benefícios intangíveis que podem ser quantifica­ dos em unidades diferentes da monetária ou po­ dem ser identificados e descritos subjetivamente.

348

Gerenciamento de Projetos

Os custos sào significativamente mais difíceis de quantificar. Os custos mínimos que devem ser determi­ nados são aqueles que são utilizados especificamente para comparação com os benefícios. Isso inclui:

contribuição para o processo de seleção de projetos. Ele pode ser útil durante a seleção de projetos, fornecendo conhecimento do negócio, incluindo:

• Opções de oportunidades (volume de vendas, par­ ticipação de mercado e negócios posteriores) • Requisitos dos recursos (requisitos do conjunto de conhecimentos e habilidades da equipe) • Custos refinados do projeto • Economias refinadas • Benefícios (financeiros, estratégicos,* payback 110) • Métricas do projeto (indicadores-chave de desem­ penho e fatores críticos de sucesso) • Realização de benefícios (consistência com o pla­ no corporativo de negócios) • Riscos • Estratégias de saída • Prontidão e pontos fortes organizacionais • Cronograma/marcos • Complexidade geral • Complexidade tecnológica e restrições, se houver11

• Os custos atuais de operação ou os custos de ope­ ração nas circunstâncias de hoje. • Custos de períodos futuros que sào esperados e que podem ser planejados. • Custos intangíveis que podem ser difíceis de quan­ tificar. Esses custos são muitas vezes omitidos se a quantificação contribuir pouco para o processo decisório.

Deve haver uma documentação cuidadosa de todas as restrições e premissas conhecidas que foram feitas no desenvolvimento dos custos e dos benefícios. Premissas irrealistas ou nào reconhecidas sào frequentemente a causa de benefícios irreais. A decisão go/no-go de conti­ nuar com um projeto poderia muito bem se basear na confirmação das premissas. A Tabela 11-4 mostra as principais diferenças entre os estudos de viabilidade e as análises de custo-benefício.

TABELA 11-4 Estudo de viobilidade e análise de custabenefício Analise de

Estudo de Viabiidade

Custo-Benefkio

Questão Bcskc

Podemos fazer?

Devemos fazer?

Fase do Ckko de Vido

Preccnceifud

Concerfuol

GPsel«»orcdo

Geroimente oindo nõo

Analise

toalíofea

Oudititatiro

Fataes (rilKOS poro o

• Técnicos

. Voior preswte Injuedo

fo/Hoço

• Custos

• Fluxo de coixo descaitodo

. Quádade

• Taxo interno de retorno

• Segurança

• Retomo sobre o investimento

• Focifcdode de desempenho

• Probotdidode de sucesso

• fconôrmcos

• Reoiidode das premissas e

Geroimente identificado, mas com enchimento parcial

• legais Critérios de deosoo dos executivos

Aderência estrtféçko

11.16 0 PAPEL DOS EXECUTIVOS

NO PLANEJAMENTO

Executivos são responsáveis pela seleção do gerente do projeto, e a pessoa escolhida deve possuir conhecimentos em planejamento. Nem todos os especialistas técnicos sào bons planejadores. Da mesma forma, algumas pessoas que sào excelentes na execuçào possuem habilidades mínimas de planejamento. Os executivos devem ter certe­ za de que quem for designado como o gerente do proje­ to possua tanto habilidades de planejamento quanto de execuçào. Além disso, os executivos devem ter um papel ativo durante as atividades de planejamento do projeto, especialmente se eles funcionam também como patroci­ nadores de projetos.*12

Os executivos nào devem arbitrariamente definir marcos irreais e, em seguida, “forçar” os gerentes de linha

restrições Os benefícios excedem os custas

N,wTermo de finanças que representa o tempo decorrido entre o

pila margem engida

momento do investimento inicial e aquele no qual o lucro lí­

quido acumulado se iguala ao valor do investimento.

Hoje, o gerente de projetos pode acabar participan­ do do processo de seleção de projetos. No Capítulo 1, dis­ cutimos a nova classe de gerente de projetos, ou seja, uma pessoa que tem excelentes habilidades para negócios, bem como competências em gerenciamento de projetos. Essas habilidades para os negócios agora nos permite tra­ zer o gerente de projetos a bordo no projeto no começo da fase de iniciação, em vez de no final dessa fase, porque o gerente de projetos pode agora fornecer uma valiosa

"

Para fatores adicionais que podem influenciar a tomada dc de­

cisões na seleção de projetos, ver: MEREDITH. I. R.; MANTEL Jr., S. J. Project management. 3. cd. New York: Wiley, 1995. p. 44-46. 12

Embora essa seção se chame “O Papel dos Executivos no Plane­ jamento" ela também se aplica à gerência de linha, se o patro­ cínio do projeto for direcionado para o nível da média gerencia ou inferior. Isso é bastante comum em organizações altamente

maduras em gerenciamento de projetos, onde a alta adminis­ tração possui confiança suficiente na capacidade da gerência de

linha cm atuar como patrocinadores dc projetos.

349

PLANEJAMENTO

zq ÍUIUWWO

IIBEKAÍÃO

WIU&HO HSfl

y

FASE 1

(Q00Í

/_________ làl coiwxí

zl /_______

WIKUHKH ftüJffOCÜS | (USOS «CUSTOS

J

F

^^1

«CUSTOS

HSfnr

HSfl

Z| /_________ CUEME E

K1AT0WS FASE»

rmrpfwnnui

FIGURA 11-9 Fases de um sistema de controle e gestão de custos.

a cumpri-los. Tanto o gerente do projeto quanto o gerente de linha devem tentar aderir a marcos irreais, mas se um gerente de linha disser que nào pode, os executivos devem concordar porque o gerente de linha é, supostamente, o especialista.

• Maximizar os benefícios de cada projeto em rela­ ção a todos os outros projetos • Avaliar os riscos

11.17 0 CICLO DE PLANEJAMENTO

Em projetos de longo prazo, o estabelecimento de fa­ ses pode ser excessivo, resultando em custos extras e atra­ sos. Para evitar isso, muitas empresas orientadas a proje­ tos recorrem a outros tipos de sistemas, como um sistema de controle e gestão de custos' ™. * Nenhum programa ou projeto pode ser eficientemente organizado e gerenciado, sem algum tipo de sistema de controle e gestão de cus­ tos. A Figura 11-9 mostra as cinco fases desse sistema. A primeira fase constitui o ciclo de planejamento, e as qua­ tro fases seguintes identificam o ciclo operacional.

Anteriormente, dissemos que talvez a razão mais impor­ tante para a estruturação de projetos em fases do ciclo dc vida é fornecer à administração um controle dos pontos críticos de decisão, a fim de:

A Figura 11-10 mostra as atividades incluídas no ciclo de planejamento. A estrutura analítica do proje­ to serve como controle inicial da qual emana todo o planejamento. A EAP atua como uma artéria vital para as

Os executivos devem se relacionar com o pessoal do projeto e de linha durante a fase de planejamento, a fim de definir os requisitos e estabelecer prazos razoáveis. Os executivos devem perceber que a criação de prazos irra­ cionais pode exigir a redefinição das prioridades e, na­ turalmente, a mudança de prioridades pode atrasar os marcos.

• Evitar o comprometimento de grandes recursos prematuramente • Preservar opções futuras

Nm Na expressão em inglês.

(MCCS).

FIGURA 11-10 Ciclo de planejamento de um sistema de controle e gestão de custos.

Management Cosí and Contrai System

350

Gerenciamento de Projetos

comunicações e operações em todas as fases. Uma análise compreensiva dos sistemas de controle e gestão de custos é apresentada no Capítulo 15. 11.18 AUTORIZACAO DE PLANEJAMENTO DO TRABALHO

Após o recebimento de um contrato, alguma forma de 432 Orientar e gerenciar a autorização é necessária execução do projeto antes que o trabalho pos­ sa começar, mesmo no estágio de planejamento. Tanto a autorização do trabalho quanto a autorização de pla­ nejamento do trabalho são usadas para liberar recursos, mas para propósitos diferentes. A autorização de planeja­ mento do trabalho libera recursos (principalmente para a gerência funcional), de modo que a programação do cronograma, os custos, os orçamentos e todos os outros tipos de planos possam ser elaborados antes da liberação dos recursos do ciclo operacional, que doravante serão chamados simplesmente de autorização do trabalho. Ambas as formas de autorização exigem os mesmos documentos. Em muitas empresas, essa autorização do trabalho é identificada como uma descrição do trabalho '™, * subdivido' que é uma descrição narrativa do esforço a ser realizado pelo centro de custo (nível mínimo de divi­ são). Esse pacote estabelece o trabalho a ser executado, o período de desempenho e, possivelmente, o número má­ ximo de horas disponíveis. A descrição do trabalho sub­ dividido tem propósitos múltiplos, de forma que pode ser usada para liberar verbas do contrato, autorizar o plane­ jamento, descrever atividades identificadas na EAP e, por último, mas não menos importante, para a liberação do trabalho. A descrição do trabalho subdivido é um dos ele­ mentos principais no planejamento de um programa como mostrado na Figura 11-10. O controle e a ad­ ministração do contrato liberam os recursos por meio da emissão de uma descrição do trabalho subdividido, que estabelece os requisitos contratuais gerais e autori­ za a gerência do programa a prosseguir. A gerência do programa emite uma descrição do trabalho subdivido para estabelecer as diretrizes e os requisitos contratuais para as unidades funcionais. Essa descrição do trabalho subdividido especifica como o trabalho será realizado, as organizações funcionais que serão envolvidas e quem possui quais responsabilidades específicas e autoriza a utilização dos recursos dentro de um determinado pe­ ríodo de tempo. Guia PMBOK , 5. ed.

s_r,: Na expressão em inglês. Subdivided Work Description.

A descrição do trabalho subdivido autoriza tanto a equipe do programa quanto a gerência funcional a come­ çar o trabalho. Como mostra a Figura 11-10, ela fornece uma entrada direta para a Fase II do sistema de controle e gestão de custos. A Fase I e a Fase II podem funcionar e funcionam simultaneamente, porque geralmente é im­ possível para o pessoal do escritório do programa estabe­ lecer planos, procedimentos e cronogramas sem a parti­ cipação das unidades funcionais. O pacote da descrição do trabalho subdividido é utilizado pelas organizações operacionais para subdivi­ dir ainda mais o esforço definido pela EAP em pequenos segmentos ou pacotes de trabalho.

iMuitas pessoas alegam que se os dados no documen­ to de autorização do trabalho são diferentes do que foi originalmente definido na proposta, o projeto está com problemas logo no início. Esse pode não ser o caso, porque a maioria dos projetos é estimada considerando recursos “ilimitados”, enquanto as horas e os valores monetários no documento de autorização do trabalho se baseiam em recursos “limitados”. Essa situação é comum para as em­ presas que prosperam em concorrências de licitações. 11.19

POR QUE OS PLANOS FRACASSAM?

Não importa o quanto tentemos, o planejamento não é per­ feito, e às vezes os planos fracassam. Razões típicas incluem:

• As metas corporativas não sào compreendidas nos níveis inferiores da organização • Os planos englobam muita coisa em muito pouco tempo • As estimativas financeiras são deficitárias • Os planos sào baseados em dados insuficientes • Nenhuma tentativa está sendo feita para sistemati­ zar o processo de planejamento • O planejamento é realizado por um grupo de planejamento • Ninguém conhece o objetivo final • Ninguém conhece as necessidades de pessoal • Ninguém sabe as datas dos marcos principais, in­ cluindo relatórios escritos • As estimativas do projeto são suposições e nào sào baseadas em padrões ou no histórico • Não foi dado tempo suficiente para estimativas adequadas • Ninguém se preocupou em verificar se haverá pes­ soal disponível com as habilidades necessárias • /\s pessoas nào estão trabalhando para as mesmas especificações • As pessoas são constantemente arrastadas para dentro e para fora do projeto, com pouca conside­ ração ao cronograma

351

PLANEJAMENTO

Por que essas situações ocorrem? Se os objetivos da empresa nào sào compreendidos, é porque os executivos da empresa têm sido negligentes no fornecimento de informações estratégicas necessárias e no feedback. Se um plano fracassa por causa de otimismo extremo, en­ tão a responsabilidade recai tanto sobre o gerente do projeto quanto sobre o gerente de linha por não ava­ liar os riscos. Os gerentes de projetos devem perguntar aos gerentes de linha se as estimativas sào otimistas ou pessimistas, e devem esperar uma resposta honesta. Es­ timativas financeiras erradas são de responsabilidade do gerente de linha. Se o projeto fracassa por causa de uma má definição dos requisitos, então o gerente do projeto está totalmente em falta. Às vezes, planos de projetos fracassam porque deta­

lhes simples são esquecidos ou ignorados. Exemplos disso podem ser:

• Negligência em dizer a um gerente de linha an­ tecipadamente o bastante que o protótipo não está pronto e que é necessária uma mudança no cronograma • Negligência em verificar se o gerente de linha ainda pode fornecer os funcionários adicionais para as próximas duas semanas, como foi possível fazê-lo há seis meses Às vezes, os planos fracassam porque o gerente do

projeto “dá o passo maior que a perna” e, então, algo acontece, como ele ficar doente. Muitos projetos fracassa­ ram porque o gerente do projeto era o único que sabia o que estava acontecendo e, então, ele ficou doente.

Hoje a maioria das razões pelas quais os projetos não são concluídos dentro do prazo e dos custos é compor la­ mentai e não quantitativa. Essas razões incluem:

• • • •

Moral ruim Relações humanas ruins Baixa produtividade de trabalho Não há comprometimento dos envolvidos no projeto

O último item parece ser a causa dos três primeiros itens em muitas situações. Uma vez que as razões para o cancelamento são defi­ nidas, o problema seguinte diz respeito a como interrom­ per o projeto. Algumas das formas são:

• Conclusão planejada ordenadamente • “Machadinho” (retirada de recursos financeiros e remoção de pessoal) • Transferência de pessoas para tarefas de maior prioridade • Redirecionamento dos esforços para objetivos diferentes • Enterrá-lo ou deixá-lo morrer na videira (ou seja, não tomar qualquer medida oficial) Existem três problemas principais a serem conside­ rados na interrupção de projetos: • Moral do trabalhador • Transferência de pessoal • Documentação adequada e conclusão 11.21

COMO LIDAR COM FINALIZAÇÕES E TRANSFERÊNCIAS DE PROJETOS

Por definição, os projetos (e até mesmo as fases do ciclo 4.4 Monitorar e controlar o de vida) têm um ponto fi­ trabalho do projeto nal. O encerramento é uma fase muito importante no ciclo de vida do projeto, que deve seguir disciplinas e procedimentos específicos com o objetivo de: Guio PMBOK , 5. ed.

11.20

INTERRUPÇÃO DE PROJETOS

Guia PMBOK ,5. ed.

4.6 Encerrar projetos

Há sempre situações em que os projetos têm de ser interrompidos. Nove razões

para a interrupção sào:

• Realização final dos objetivos • O mau planejamento inicial e o prognóstico do mercado ■ Uma alternativa melhor é encontrada • Uma mudança no interesse e na estratégia da empresa • O tempo alocado for excedido • Os custos orçados forem excedidos • Pessoas importantes deixam a organização • Caprichos pessoais da administração • O problema é complexo demais para os recursos disponíveis

• Eficazmente levar o projeto para o encerramento, de acordo com o acordado nos requisitos do contrato • Preparar a transição do projeto para a fase operacio­ nal seguinte, tal como da produção para a instalação em campo, operação de campo, ou de treinamento • Analisar o desempenho global do projeto em rela­ ção aos dados financeiros, cronogramas e esforços técnicos • Encerrar o escritório do projeto, e transferir ou vender todos os recursos originalmente designados ao projeto, incluindo pessoal • Identificar e buscar negócios resultantes

352

Gerenciamento de Projetos

Embora a maioria dos gerentes de projetos esteja to­ talmente ciente da necessidade de planejamento adequa­ do para o início do projeto, muitos deles negligenciam o planejamento do encerramento do projeto. O planeja­ mento do encerramento do projeto inclui: • Transferência de responsabilidade • Conclusão dos registros do projeto • Relatórios históricos • Análise pós-projeto • Documentação dos resultados para refletir o pro­ duto ou a instalação "as built” • Aceitação pelo patrocinador/usuário • Satisfação dos requisitos contratuais • Liberação dos recursos • Novas designações para os membros da equipe do escritório do projeto • Disposição do pessoal funcional • Disposição de materiais • Encerramento de ordens de trabalho (liquidação financeira) • Elaboração de pagamentos financeiros

O sucesso ou o fracasso do projeto depende muitas vezes da capacidade da administração em lidar adequada­ mente com as questões dc pessoal durante essa fase final. Se as designações de trabalho além do projeto atual pare­ cem indesejáveis ou incertas para os membros da equipe do projeto, pode se desenvolver uma grande dose de an­ siedade e conflitos que desviam a energia necessária para a caça ao emprego, atrasos ou até mesmo sabotagem. O pessoal do projeto pode se envolver na busca de empre­ go por conta própria e pode deixar o projeto prematuramente. Isso cria um vazio evidente que, muitas vezes, é difícil de corrigir. Dada a realidade empresarial, é difícil a transferência de pessoal do projeto sob condições ideais. As sugestões a seguir podem aumentar a eficácia organizacional e di­ minuir o estresse do pessoal quando do encerramento de um projeto:

• Planejar cuidadosamente o encerramento do pro­ jeto por parte de ambos os gerentes, funcional e do projeto. Usar uma lista de verificação para elaborar o plano. • Estabelecer um processo simples de encerramento do projeto que identifique as principais etapas e responsabilidades. • Tratar a fase de encerramento como qualquer ou­ tro projeto, com tarefas claramente delineadas, res­ ponsabilidades, cronogramas, orçamentos e itens de entregas ou resultados acordados.

• Compreender a interação de elementos comporta­ mentais e organizacionais, a fim de construir um ambiente favorável para o trabalho em equipe du­ rante essa fase final do projeto. • Enfatizar as metas, aplicações e utilidades gerais do projeto, bem como seu impacto nos negócios. • Garantir o envolvimento e o apoio da alta administração. • Estar ciente dos conflitos, da fadiga, das mudanças de prioridades, e dos problemas técnicos ou logís­ ticos. Tentar identificar e lidar com esses proble­ mas assim que eles começarem a se desenvolver. A comunicação do progresso por meio de reuniões regulares de andamento é a chave para o gerencia­ mento desses problemas. • Manter o pessoal do projeto informado sobre as próximas oportunidades de trabalho. Os gerentes de recursos devem discutir e negociar novas desig­ nações com o pessoal e envolver as pessoas que já estão no próximo projeto. • Estar ciente dos boatos. Se uma reorganização ou demissão for inevitável, a situação deve ser descri­ ta de forma profissional ou, então, as pessoas irão presumir o pior. • Designar um administrador do contrato dedicado aos projetos orientados à empresa. Ele vai proteger a sua posição financeira e os interesses de negócio, buscando as aprovações do cliente e o pagamento final. 11.22 CRONOGRAMAS E GRÁFICOS DETALHADOS

A programação das atividades é o primeiro requisito principal do escritório de programas após a autorização do programa. O escritório de programas normalmente assume total responsabilidade pela programação se a ati­ vidade não for muito complexa. Para programas de gran­ de porte, a participação da gerência funcional é necessária antes que a programação possa ser concluída. Dependen­ do do tamanho do programa e dos requisitos contratuais, o escritório de programas pode ter um agente, cuja única responsabilidade é continuamente desenvolver e atualizar os cronogramas das atividades para rastrear o trabalho do programa. A informação resultante é fornecida ao pessoal do escritório de programas, à gerência funcional, aos membros da equipe e ao cliente. A programação de atividades é provavelmente a fer­ ramenta mais importante para determinar como os re­ cursos da empresa devem ser integrados. Os cronogramas de atividades são inestimáveis para a projeção dos requi­ sitos de utilização de recursos ao longo das fases, forne­ cendo uma base para rastrear visualmente o desempenho

PLANEJAMENTO

e as estimativas de custos. Os cronogramas servem como planos principais a partir dos quais tanto o cliente quan­ to a administração possuem um quadro atualizado das operações. Algumas orientações devem ser seguidas na elabora­ ção dos cronogramas, independentemente da utilização projetada ou da complexidade:

• Todos os eventos e datas principais devem ser cla­ ramente identificados. Se uma declaração do tra­ balho é fornecida pelo cliente, as datas indicadas nos cronogramas associados devem estar incluí­ das. Se, por qualquer motivo, as datas dos marcos do cliente não puderem ser cumpridas, o cliente deve ser notificado imediatamente. • A sequência exata de trabalho deve ser definida por meio de uma rede, na qual as relações entre os eventos possam ser identificadas. • Os cronogramas devem ser diretamente relacionáveis com a estrutura analítica do projeto. Se a EAP é desenvolvida de acordo com uma sequência espe­ cífica de trabalho, então torna-se uma tarefa facil identificar as sequências de trabalho nos cronogra­ mas, utilizando o mesmo sistema de numeração da F.AP. O requisito mínimo deve ser mostrar onde e quando todas as tarefas iniciam e terminam. • Todos os cronogramas deverão identificar as res­ trições de tempo e, se possível, os recursos neces­ sários para cada evento. Embora essas quatro orientações se refiram à elabo­ ração do cronograma, elas não definem o quão complexos os cronogramas devem ser. Antes de elaborar os crono­ gramas, três questões devem ser consideradas: • Quantos eventos ou atividades cada rede deveria ter? • O quanto de divisão técnica detalhada deve ser incluído? • Quem é o público-alvo desse cronograma? A maioria das organizações desenvolve vários cro­ nogramas: cronogramas resumidos para a administração e para os planejadores e cronogramas detalhados para os executores e para o controle dos níveis mais baixos. Os cronogramas detalhados podem ser estritamente para atividades interdepartamentais. A gerência do programa deve aprovar todos os cronogramas até os três primeiros níveis da estrutura analítica do projeto. Para cronogra­ mas de níveis mais baixos (ou seja, interdepartamentais detalhados), a gerência do programa pode ou não solici­ tar um sinal de aprovação.

353 Um dos problemas mais difíceis de identificar nos cronogramas é uma posição de cobertura. Uma posição de cobertura é uma situação em que o fornecedor pode não ser capaz de atender um marco do cliente sem ficar sujeito a um risco, ou pode não ser capaz de atender aos requisitos da atividade, de acordo com a data de um mar­ co, em virtude dos requisitos contratuais. Para ilustrar uma típica posição de cobertura, considere o Exemplo 11-1 a seguir. Exemplo 11-1. A Condor Corporation está atual­ mente trabalhando em um projeto que tem três fases: de­ sign, desenvolvimento e qualificação de um determinado componente. Os requisitos contratuais com o cliente es­ pecificam que nenhum componente será fabricado para a fase de desenvolvimento até que a reunião de revisão de design seja realizada após a fase de design. A Condor de­ terminou que, caso nào comece a fabricação de compo­ nentes antes da reunião de revisão de design, então, as fa­ ses 2 e 3 atrasarão. A Condor está disposta a aceitar o risco de que se as especificações forem inaceitáveis durante a reunião de revisão de design, estará sujeita aos custos as­ sociados com a prê-autorização de fabricação. Como isso deve ser mostrado em um cronograma? (Os problemas associados com a realização de trabalhos não autorizados nào estão sendo considerados aqui.)

A solução nào é fácil. A Condor deve mostrar no pla­ no mestre de produção que a fabricação de componentes começará antecipadamente, no risco do fornecedor. Isso deve ser acompanhado por uma carta contratual, na qual tanto o cliente quanto o fornecedor entendam os riscos e as implicações.

Cronogramas detalhados são desenvolvidos para quase todas as atividades. É de responsabilidade do escritório de programas unir todos os cronogramas detalhados em um cronograma mestre para verificar que todas as atividades possam ser concluídas conforme o planejado. A sequência de elaboração para cronogra­ mas (e também para planos do programa) é apresentada na Figura 11-11. O escritório de programas apresenta uma solicitação para cronogramas detalhados aos ge­ rentes funcionais e esses preparam cronogramas resu­ midos, cronogramas detalhados e, se o tempo permitir, cronogramas interdepartamentais. Cada gerente fun­ cional, então, revisa os seus cronogramas com o escritó­ rio de programas. Este, juntamente com os membros da equipe funcional do programa, integra todos os planos e cronogramas e verifica que todas as datas contratuais podem ser cumpridas.

Antes de os cronogramas serem submetidos para publicação, os rascunhos de cada cronograma e de cada

354

Gerenciamento de Projetos

FIGURA 11-11 Sequência de elaboração para cronogramas e planos de programas.

plano devem ser revistos com o cliente. Esse procedimen­ to realiza o seguinte:

O pessoal do projeto deve ter em mente o porquê de o cronograma ter sido desenvolvido. O principal objetivo

• Verifica que nada passou despercebido • Evita revisões imediatas de um documento publi­ cado e pode evitar momentos constrangedores • Reduz os custos de produção, por meio da redução

é geralmente coordenar as atividades para concluir o pro­ jeto com:

do número de revisões antecipadas • Mostra aos clientes no início do programa que você recebe bem a sua ajuda e contribuição para a fase de planejamento Depois que o documento é publicado, ele deve ser distribuído a todo o pessoal do escritório de programas, aos membros da equipe funcional, à gerência funcional

e ao cliente. Exemplos de cronogramas detalhados são

mostrados no Capítulo 13. Além dos cronogramas detalhados, o escritório de programas.com contribuição da gerência funcional, deve desenvolver os organogramas. Eles mostram quem tem

responsabilidade por cada atividade e mostram as linhas formais (e muitas vezes informais) de comunicação. Exemplos foram mostrados na Seção 4.11.

• O melhor prazo • Os menores custos • O mínimo de riscos Há também objetivos secundários da programação do cronograma: • Estudo de alternativas • Desenvolvimento de um cronograma ideal

• Utilização eficaz de recursos • Comunicação • Refinamento dos critérios para as estimativas • Obtenção de um bom controle do projeto • Viabilização de revisões fáceis Os grandes projetos, especialmente os esforços de longo prazo, podem precisar de uma war room™' *. As war rooms geralmente possuem apenas uma porta e nenhuma janela. Todas as paredes são cobertas com

O escritório de programas também pode criar orga­ nogramas lineares de responsabilidade (OI.R). Apesar das

grandes cronogramas, talvez impressos em papel foto­ gráfico, e cada parede pode ter vários painéis deslizantes. Os cronogramas e gráficos em cada parede podem ser

melhores tentativas da administração, muitas funções em uma organização podem se sobrepor entre as unidades funcionais. Além disso, a administração pode desejar ter a

atualizados diariamente. A sala pode ser utilizada para reuniões de instrução com o cliente, reuniões de equipe, e quaisquer outras atividades relacionadas especifica­

responsabilidade por determinadas atividades designadas

mente a esse projeto.

a uma unidade funcional que normalmente não teria essa responsabilidade. Isso é uma ocorrência comum em pro­ gramas de curta duração, em que a administração deseja diminuir custos e burocracia.

Em tradução literal,“sala de guerra". Termo militar que repre­

senta o centro de comando e controle, que serve como ponto de controle para as atividades militares.

355

PLANEJAMENTO

11.23 A PROGRAMAÇÃO MESTRE DE PRODUÇÃO' :

A liberação das descrições do trabalho subdividido pla­ nejadas, como mostrado na Figura 11-10, autoriza as uni­ dades de produção a elaborar um plano mestre de produ­ ção a partir do qual uma análise detalhada da utilização dos recursos da empresa pode ser vista e rastreada. A programação mestre da produção não é um con­ ceito novo. Sistemas recentes de controle de materiais utilizavam um “sistema de pedidos trimestrais” para ela­ borar um programa mestre de produção - PMP (Master Production Schedule - MPS) para a produção da fábri­ ca. Esse sistema utiliza o acúmulo de pedidos de clien­ tes para desenvolver um plano de produção ao longo de um período de três meses. O plano de produção ê, en­ tão, desmembrado manualmente para determinar quais partes devem ser compradas ou fabricadas no momento adequado. No entanto, requisitos do cliente em constan­ te mudança e tempos de espera flutuantes, combinados com uma resposta lenta a essas mudanças, podem resul­ tar na interrupção da programação mestre da produção1'.

• Conciliar as necessidades de marketing e produção • Fornecer uma medida geral de desempenho • Fornecer dados para o planejamento de materiais e de capacidade

O desenvolvimento de um programa mestre de produção é um passo muito importante em um ciclo de planejamento. Eles unem diretamente pessoal, materiais, equipamentos e instalações, conforme mostra a Figura 11-12. Eles também identificam importantes datas para o cliente, caso ele queira visitar o fornecedor durante pe ríodos operacionais específicos.

í I

; OtoiwB « • leroitwaeo; jciertsidoicm; • ;

irsxnn àrtfcvos

11 •

■ ;

; PK(CK TOCOS ;

O^knõMJ

(es«strode

Objetivos da Programação Mestre de Produção

Os objetivos da programação mestre de produção sào:

• Fornecer à alta administração um meio de autori­ zar e controlar os níveis de mão de obra, o investi­ mento em inventário e o fluxo de caixa • Coordenar as atividades de marketing, produção, engenharia e finanças por meio de um objetivo co­ mum de desempenho

CTU Termo cm inglês, Master Production Scheduling (MPS). n

O programa mestre de produção é discutido aqui por causa de sua importância no ciclo de planejamento. Ele não pode ser

plenamente utilizado sem procedimentos eficazes de controle de inventário.

••11

osxrtnvrs kttao:

■•11

1

Definição de Programa Mestre de Produção

Um programa mestre de produção é uma decla­ ração do que será produzido, quantas unidades serão produzidas, e quando serão produzidas. É um plano de produção, e não um plano de vendas. O programa mestre de produção considera a demanda total de recursos de uma fábrica, incluindo as vendas de produtos acabados, necessidades de peças sobressalentes (reposição) e neces­ sidades internas da fábrica. O PMP também deve con­ siderar a capacidade da fabrica e os requisitos impostos aos fornecedores. As provisões sào feitas no plano global para cada operação das instalações de produção, lodo o planejamento de materiais, mão de obra, fábrica, equipa­ mentos e financiamento para a instalação é impulsionado pelo plano mestre de produção.

NranaMeste fePodxõ)

1 •1

1 1

■

Ciorojwne CO frfít’

.Vmerj

; AzadjQoetow) i o [1at) twn dt

hraanu di PcatjireMis ±6 NeasáfodB Ce Mcteos

■

•

1

**

1 1 11 1 ;eqdMMK.iú) ■ ; diaMsmcftfCB •

As wesudodis de x»os

1 1o 1I 1 • •

ano (feweerftuB

FIGURA 11-12 Inter-relacionomentos do planejamento de

necessidades de materiais.

11.24

0 PLANO DO PROJETO

Um plano de projeto é fun­ damental para o sucesso ( jpítuki 5 Gerenciamento do Bcopo do Projeto de qualquer projeto. Para < apituk» 4 (>erenciamento da projetos grandes e muitas Integração do Projeto 3.4 Grupo de processos de vezes complexos, os clien­ planejamento tes podem exigir um plano de projeto que documente todas as atividades dentro do programa. O plano do projeto, então, serve como uma orientação para a vida do projeto e pode ser revisado com frequência de uma vez por mês, dependendo das circuns­ tâncias e do tipo de projeto (ou seja, projetos de pesqui­ sa e desenvolvimento exigem mais revisões ao plano do projeto do que projetos de produção ou construçào). O plano do projeto fornece a seguinte estrutura: Guia PMBOK *

5.»i

• Elimina os conflitos entre os gerentes funcionais • Elimina os conflitos entre a gerência funcional e a gerência do programa • Fornece uma ferramenta de comunicação padrão durante toda a vigência do projeto (ele deve ser orientado para a estrutura analítica do projeto) • Fornece a confirmação de que o fornecedor enten­ de os objetivos e requisitos do cliente • Fornece um meio para a identificação de inconsis­ tências na fase de planejamento

356

Gerenciamento de Projetos • Fornece um meio para a identificação antecipada de problemas e riscos para que não ocorram sur­ presas no caminho • Contém todos os cronogramas definidos na Seção 11.18 como uma base para a análise e o relatório do progresso

O desenvolvimento de um plano de projeto pode ser demorado e dispendioso. Todos os níveis da organização participam. Os níveis superiores fornecem informações re­ sumidas, e os níveis inferiores fornecem os detalhes. O plano do projeto, como os cronogramas das atividades, não impede que os departamentos desenvolvam seus próprios planos. O plano do projeto deve identificar como os recur­ sos da empresa serão integrados. O processo é similar à sequência de eventos para a elaboração do cronograma, apresentado na Figura I l-l I. Como o plano do projeto deve explicar os eventos na Figura 11-11, são necessárias iterações adicionais, o que pode provocar mudanças no projeto. Isso pode ser visto na Figura 11-13.

O plano do projeto é um padrão, a partir do qual o desempenho pode ser medido pelo cliente e por ambos os gerentes, funcional e do projeto. O plano funciona como um livro de receitas ao responder essas perguntas para todo o pessoal identificado com o projeto:

• • • • •

O que será realizado? Como será realizado? Onde será realizado? Quando será realizado? Por que será realizado?

As respostas para essas perguntas forçam tanto o for­ necedor quanto o cliente a dar uma boa olhada:

• • • • • • •

Nos requisitos do projeto No gerenciamento do projeto Nos cronogramas do projeto Nos requisitos das instalações No apoio logístico No apoio financeiro Na força de trabalho e na organização

O plano do projeto é mais do que apenas um con­ junto de instruções. É uma tentativa de eliminar as crises, impedindo que qualquer coisa passe despercebida. O pla­ no é documentado e aprovado pelo cliente e pelo forne­ cedor para determinar os dados que estiverem faltando, se for o caso, e o provável efeito resultante. Conforme o projeto amadurece, o plano do projeto é revisado para contabilizar novos dados ou dados em falta. As razões mais comuns para a revisão de um plano são:

• Compressão * ™ de atividades para atender às da­ tas de término • Decisões sobre compensações que envolvem re­ cursos humanos, programação do cronograma e desempenho • Ajuste e nivelamento de solicitações de mão de obra A composição do plano do projeto pode variar de fornecedor para fornecedor14. A maioria dos planos de projetos pode ser subdividida em quatro seções princi­ pais: introdução, sumário e conclusões, gerenciamento e

íí,,s Tradução oficial da versão em português da quarta edição do Guia PMBOK* para a técnica dc compressão do cronograma.

Do termo oficia) em inglês. Crashing.

w

Cleland e King definem 14 subseções para o plano de um progra ma. Esse detalhe parece mais aplicável aos conteúdos técnicos c ge­

renciais de uma proposta. Eles, no entanto, fornecem um quadro mais detalhado do que o apresentado aqui. Ver CLELAND, David 1.; KING, William R. Systems analysis and project management.

FIGURA 11-13 Iterações para o processo de planejamento.

New York: McGraw-Hill, 1975. p. 371 -380.

357

PLANEJAMENTO

técnica. A complexidade das informações geralmente fica a critério do fornecedor, contanto que os requisitos do cliente, conforme pode estar especificado na declaração do trabalho, sejam satisfeitos.

A seção introdutória contém a definição do projeto e as principais partes envolvidas. Se o projeto vem depois de outro, ou é um resultado de atividades similares, isso é indicado, juntamente com um breve resumo do histórico por trás do projeto. A seção de resumo e conclusão identifica as metas e os objetivos do projeto e inclui o “discurso” necessário sobre como o projeto será bem-sucedido e como todos os pro­ blemas podem ser superados. Essa seção deve incluir tam­ bém o cronograma mestre do projeto, mostrando como todos os projetos e atividades estão relacionados. O cro­ nograma mestre de todo o projeto deve incluir o seguinte:

• Um sistema adequado de programação (gráficos de barras, gráfico de marcos, rede etc.) • Uma listagem das atividades no nível do projeto ou inferior • As possíveis inter-relações entre as atividades (po­ dem ser realizadas por meio de redes lógicas, redes de caminho crítico, ou redes PERT) • Estimativas de tempo das atividades (um resultado natural do item anterior)

O capítulo de resumo e conclusão geralmente é a segunda seção do plano do projeto, de modo que a alta administração do cliente possa ter uma visão completa do projeto sem ter de procurar nas informações técnicas.

A seção de gerenciamento do plano do projeto contém procedimentos, gráficos e cronogramas,conforme a seguir: • A designação de funcionários importantes para o projeto é indicada. Isso normalmente se refere ape­ nas ao pessoal do escritório de projetos e aos mem­ bros da equipe, já que sob operações normais estes serão os únicos a se relacionar com os clientes. • A força de trabalho, o planejamento e o treinamen­ to sào discutidos para garantir aos clientes que pes­ soas qualificadas estarão disponíveis a partir das unidades funcionais. • Um organograma linear de responsabilidades tam­ bém pode ser incluído para identificar aos clientes as relações de autoridade que existirão no programa.

A seção técnica pode incluir quase de 75 a 90% do plano do programa, principalmente se inclui o esforço de pesquisa e desenvolvimento, e pode exigir atualizações constantes, conforme o projeto amadurece. Os seguintes itens podem ser incluídos como parte da seção técnica:

• Uma divisão detalhada dos gráficos e cronogramas utilizados no cronograma mestre do projeto, pos­ sivelmente incluindo estimativas de cronograma e custos. • Uma listagem dos testes a serem realizados para cada atividade. (Ê melhor incluir as matrizes exa­ tas de testes.) • Procedimentos para a realização dos testes. Isso também pode incluir uma descrição dos elemen­ tos principais dos planos de operações ou de pro­ dução, bem como uma listagem dos requisitos de instalações e de logística. • Identificação de materiais e especificações de ma­ teriais. (Isso também pode incluir especificações de sistema.) • Tentativa de identificar os riscos associados aos requisitos técnicos específicos (normalmente nào incluída). Essa avaliação tende a assustar o pesso­ al da administração que nào estiver familiarizado com os procedimentos técnicos, portanto, deve ser omitida, se possível.

O plano do projeto, como usado aqui, contém uma descrição de todas as fases do projeto. Para muitos projetos, especialmente os grandes, o planejamento de­ talhado é necessário para todos os eventos e atividades principais. A Tabela 11-5 identifica o tipo de planos indi­ viduais que podem ser exigidos no lugar de um plano de projeto (total). Esses planos sào frequentemente chama­ dos de planos auxiliares. TABELA 11-5 Tipos de planos Tipo de Plano Orçamento Gerencomento da (odigxccoo

Instalações Apoio Logistko

Gestão Produção

Destrkào Quanto dinheiro esta olocodo para rodo evento?

Como as mudanças técnicas são feitas? Quais recursos de instalações estão disponíveis?

Como as substituições seroo trotadas? Como esta organizado o esaiteno do programo? Quais são os eventos periódicos da produção? Quais são as minhas fontes? Devo fazer ou comprar?

Existem situações em que a seção de gerenciamen­ to pode ser omitida da proposta. Para um programa de acompanhamento, o cliente não precisará dessa seção se os cargos de gestão mantiverem-se inalterados. As se­ ções de gerenciamento também não são necessárias se as informações de gerenciamento foram fornecidas an­ teriormente na proposta ou se o cliente e o fornecedor possuem transações comerciais contínuas.

AquBkões

Se os fcrrecedores não estiverem qudíxodos, como deve qcolifkóTos?

Gcrcntio da Qualidade

Pesqurso/DesemoMmentc Progrtmoçõo do Cronograma

Como goraihiei que as especfaoções seroo aladdas? Quais são as aí nêdodes técnicas?

Todas os datas criticas estão contobízadas?

Fenomentd

Quais são os reqjisitos periódicos de fenomental?

Treinamento

Como monterei o pessoal qualificado?

Transporte

Como as mercodonas e serviços serão entregues?

358

Gerenciamento de Projetos

FIGURA 11-14 Alívidades de direção do projeto.

O plano do projeto, uma vez aprovado pelo forne­ cedor e pelo diente, é então utilizado para dar orienta­ ção ao projeto. Isso é apresentado na Figura 11-14. Se o plano do projeto é escrito de forma clara, então qualquer gerente ou supervisor funcional deve ser capaz de iden­ tificar o que é esperado dele. O plano do projeto deve ser distribuído a cada membro da equipe do projeto, a todos os gerentes e supervisores funcionais que se relacionam com o projeto, e a todos os principais colaboradores funcionais. Uma nota final precisa ser mencionada sobre a le­ galidade do plano do projeto. Ele pode ser especificado contratualmente para satisfazer determinados requisi­ tos, conforme identificados na declaração do trabalho do cliente. O fornecedor se reserva o direito de decidir como realizar isso, a não ser, claro, que isso também este­ ja identificado na DT. Se a DT especifica que os testes de garantia da qualidade serão realizados em 15 itens finais da linha de produção, então 15 é o número mínimo que deve ser testado. O plano do projeto pode mostrar que 25 itens estão para ser testados. Se o fornecedor desenvolve problemas de sobrecustos, ele pode querer reverter para DT e testar apenas 15 itens. Contratual mente, ele pode fazer isso sem informar o cliente. Na maioria dos casos, no entanto, o cliente é notificado e o projeto é revisado.

11.25 PLANEJAMENTO TOTAL DO PROJETO Guia PMBOK ,5. ed.

Capítulo 5 (ierenciamcnto do Escopo do Projeto Capítulo 4 Gerenciamento da Integração do Projeto 3.4 Grupo dc processos dc planejamento

A diferença entre o gerente de projetos bom e o ruim é muitas vezes descrita em uma palavra: planejamento. O planejamento do proje­ to envolve o planejamento

para:

O desenvolvimento do cronograma O desenvolvimento do orçamento A administração do projeto (ver Seção 5.3) Estilos de liderança (influências interpessoais; ver Seção 5.4) • Gerenciamento de conflitos (ver Capítulo 7) • • • •

Os dois primeiros itens envolvem aspectos quantita­ tivos do planejamento. O planejamento para a adminis­ tração do projeto inclui o desenvolvimento do organo­ grama linear de responsabilidade.

Embora cada gerente de projetos possua a autori­ dade e a responsabilidade de estabelecer políticas e pro­ cedimentos para o projeto, eles devem estar dentro das diretrizes gerais definidas pela alta administração.

359

PLANEJAMENTO

Os organogramas lineares de responsabilidade po­ dem resultar de requisitos impostos pelo cliente que es­ tejam acima e além das operações normais. Por exem­ plo, o cliente pode exigir como parte de seu controle de qualidade, que um determinado engenheiro fiscalize e aprove todos os testes de um determinado item, ou que um outro indivíduo aprove todos os dados divulgados para o cliente, além e acima da aprovação do escritório de programas. Os requisitos do cliente semelhantes aos identificados aqui exigem OI.Rs e podem causar rupturas e conflitos dentro de uma organização. Diversos fatores importantes afetam a delegação de autoridade e responsabilidade, tanto da alta administra­ ção para o gerenciamento de projetos, quanto do geren­ ciamento de projetos para a gerência funcional. Esses fa­ tores incluem:

• A maturidade da função de gerenciamento de projetos • O tamanho, a natureza e a base de negckios da empresa • O tamanho e a natureza do projeto • O ciclo de vida do projeto • As capacidades da administração em todos os níveis Uma vez que se chegou a um acordo sobre a autori­ dade e a responsabilidade do gerente do projeto, os resul­ tados podem ser documentados para delinear esse papel no que diz respeito a: • Posição focal • Conflito entre o gerente de projetos e os gerentes funcionais • Influência para atravessar linhas funcionais e orga­ nizacionais • Participação nas principais decisões gerenciais e técnicas • Colaboração na seleção do pessoal do projeto • Controle sobre a alocação e a aplicação dos recur­ sos financeiros • Seleção de subcont ratados • Direitos na resolução de conflitos • Participação em manter a integridade da equipe do projeto ■ Estabelecimento de planos de projeto • Fornecimento de um sistema de informações ren­ tável para o controle ■ Fornecimento de liderança na elaboração de re­ quisitos operacionais • Manutenção de ligação e contato com o cliente principal • Promoção de melhorias tecnológicas e gerenciais • Estabelecimento da organização do projeto duran­ te a vigência • Eliminação de burocracia

A documentação da autoridade do gerente de proje­ tos é necessária em algumas situações, porque:

• Todas as interfaces devem ser mantidas o mais simples possível. • O gerente de projetos deve ter a autoridade para “for­ çar” os gerentes funcionais a abandonar os padrões existentes e, eventualmente, ficar sujeitos a riscos. • É essencial possuir a autoridade sobre os elemen­ tos de um programa que não estão sob o controle do gerente de projetos. Isso é normalmente reali­ zado por meio da obtenção do respeito dos indiví­ duos envolvidos. • O gerente de projetos não deve tentar descrever completamente a autoridade e a responsabilidade exatas do pessoal do escritório de projetos ou dos membros da equipe. Deve ser incentivada a resolu­ ção de problemas, em vez da definição de papéis.

Embora a documentação da autoridade do projeto seja indesejável, ela pode ser necessária, principalmente se a iniciação e o planejamento do projeto exigem uma termo de abertura formal. Nesse caso, uma carta como a apresentada na Tabela 11-6 pode ser suficiente.

Poder e autoridade são frequentemente discutidos como se andassem de mãos dadas. A autoridade vem de pessoas acima de você, talvez, por delegação, ao passo que o poder vem de pessoas abaixo de você. Você pode ter au­ toridade sem poder ou o poder sem autoridade. Em uma estrutura organizacional tradicional, a maioria dos indivíduos mantém o poder do cargo. Quan­ to mais acima você estiver, mais poder você tem. Mas, no gerenciamento de projetos, o nível de subordinação do projeto pode ser irrelevante, especialmente se houver um patrocinador do projeto. No gerenciamento de projetos, a base de poder do gerente de projetos emana de seu (sua):

• Conhecimento (técnico ou de gestão) • Credibilidade com empregados • Capacidade sólida de tomada de decisões

O último item é geralmente preferido. Se o gerente de projetos é considerado como um tomador de decisões se­ guro, então, os funcionários normalmente dão ao gerente de projetos uma grande quantidade de poder sobre eles. Os estilos de liderança se referem aos modos de influência interpessoal que um gerente de projetos pode utilizar. Os gerentes de projetos podem ter de usar vários es­ tilos de liderança diferentes, dependendo da composição do pessoal do projeto. O gerenciamento de conflitos é impor­ tante porque, se o gerente de projetos puder prever quais conflitos ocorrerão e quando eles estarão mais propensos a ocorrer, ele pode ser capaz de planejar para uma resolução dos conflitos por meio da administração do projeto.

360

Gerenciamento de Projetos

TABELA 11-6 Termo de abertura do projeto

Guia PMBOK’, 5. ed.

4.1 Dsenvolver o Termo de Abertura do Projeto ElfTROOYNAMICS 120okMnue

Cleveland, Ohio 44114 11 de jurho de 2008

Poro: Distribuição De: I. While, Vice-Presidente Executo Assunto: termo de abertirc do projeto poro o Projeto Arme

0 Sr. Rcbat L James foi designado como gerente do projeto poro o Projeto Arme.

Respcíisdiilidode

0 Sr. Janes será responsável per assegurar que todos os marcos impotentes sejam alcançados dentro do prazo, dos custos e dos restnçoes de desempenho de seu

projeto, enquanto aderindo oos padrões de controle de quoUode cproçnodos. Além disso, o gerente do projeto deve trabalha em estreito cdabcraõc com os gerentes de linho poro garantí que todos os recursos designados sqam utilizados de formo

eficoz e eficiente, e que o projeto estojo deádanente olocodo. Adkionalmente, o gerente do projeto será responsável por 1. Todas as comumcoções formais ertre o dente e o fornecedor

2. E labcracoo de um plano de projeto que seja redisto e ocatóvel tonto pelo cliente quanto pelo fornecedor.

3. Boboroçõo de todos os itens de dodos th projeto. 4. Manter o odminisioçõo executo informada quanto oo andamento tfo projeto, por

meio de rdatorios de ondanento semanais (detalhados) e mensas (resumidos). 5. Assegurar que todos os coloborodores e gerentes funcionas sejam irfamados quanto a sins responsobibdodes no projeto e quanto a todas as revisões impostos pelo ciente ou organização principal.

6. Comparação de custos e desempenho rears e previstos, e tanodo de oçoes corretos, quando necessário.

7. Mamtençóo de um plano que exi» contimomerte os prazos, cistos e desemperho do projeto, bem como os comprometimentos de recursos feitos pelos gerentes finaonois

Autondode Poro garantir que o projeto okaxe seus objetnos, o sr. Janes está autorizado o

gerenenr o prepto e emtir os instruções, em confamklode com o seção de pofitKOS

A Figura 11-15 mostra a fase de planejamento to­ tal do projeto para as partes quantitativas. O objetivo, é claro, é desenvolver um plano de projeto que mostre a distribuição completa dos recursos e dos custos corres­ pondentes. /X figura representa um processo iterative. O gerente do projeto começa com um diagrama de rede grosseiro (diagrama de setas) e, em seguida, decide sobre a estrutura analítica do projeto. A EAP é essencial para o diagrama de setas e deve ser construída de modo que os elementos e os níveis de subordinação sejam facilmen­ te identificáveis. Eventualmente, haverá um diagrama de setas e um gráfico detalhado para cada elemento da EAP. Se não houver muitos detalhes, o gerente do projeto pode refinar o diagrama, por meio da combinação de toda a lógica em um plano e pode, então, decidir sobre as desig­ nações de trabalho. Existe aqui um risco que, por meio da condensação dos diagramas tanto quanto possível, pode haver uma perda de clareza. Como mostra a Figura 11-15, todos os diagramas e cronogramas podem ser integrados em uma figura em nível de resumo. Isso pode ser reali­ zado em cada nível da EAP até que o plano desejado seja alcançado.

Finalmente, as gerências de projeto, de linha e executi­ va devem analisar outras variáveis internas e externas antes de finalizar esses cronogramas. Essas variáveis incluem:

• • • • • • •

Introdução ou aceitação do produto no mercado Disponibilidade atual ou prevista da força de trabalho Restrições econômicas do projeto Grau de dificuldade técnica Disponibilidade da força de trabalho Disponibilidade de treinamento de pessoal Prioridade do projeto

e ficcedrnentos do manual de gerencomento de projetos do empreso. Instruções

odeonas podem ser emitidas por meio do escritório do Yxepresxfente executivo. A autondode do gerente do progromo também inchi:

1.

0 ocesso dreto oo dierle sobre todos os assuntos relativos ac projeto oeme

2.

Acesso dretoòodmmislioçòo executo da Electrodynamics sobre todos os

3.

assuntos rebtivos oo Projeto Acme.

11.26 0 TERMO DE ABERTURA DO PROJETO

Ccrtde e (fcrixiçac de todas as tdaes meretrias do projeto, rxbnfo oqusções,

O conceito original do ter­ mo de abertura do projeto 4.1 Desenvolver o termo dc era documentar a autorida­ abertura do projeto de e a responsabilidade do gerente do projeto, especialmente para projetos imple­ mentados fora do escritório. Hoje, o termo de abertura do projeto é mais um documento legal interno que iden­ tifica aos gerentes de linha e ao seu pessoal a autoridade e responsabilidade do gerente do projeto e o escopo do projeto aprovado pelo cliente e/ou pela administração.

ccntrto cpe as Imitações de flu® de ca» do enpeso e do propto sqan (espetadas

4.

Revisor o plano do projeto, conforme necessão e com o oprovaçoo do ciente.

5.

Exigir relaáios periódeos funcionais de ondomento.

6.

Akritow as olwidades de tempo, custos edesempmhocfasdeporiomertosfindcnjse

gaarti qu? Iodas as pdfenas sejan çiutfunrente dertfiodas, rebtaJas e rescMas.

7.

Atra«essa todas as ínhos funcionais e interagir com todos os rtois da odmirrstroçòo, conforme o necessidade, pao atender oos requisitos do projeto.

8. 9.

Em empresas e projetos pequenos, alguns itens na Figura 11-15 podem ser omitidos, como o OI.R.

Renegocia com gerentes fincooas pelas mudanças nas designações de pessod.

Delega responsabilidades e autondode oo pessod funcional, desde que o

gerente de linha aprove que o empregado possa lidar com esse nhd de outeridaJe/iespcnsobidode.

4

Guia PMBOK ,5. ed.

OuoRQjer dúridas quarto ãs pohcas oamo derem ser àecicnodas pao o assinado abaixo.

L White

KTI6 Tradução oficial da versão em português da quarta edição do

Vice-Presidente Executo

Guia PMBOK * para Project Charter.

F IG U R A 1 1 - 1 5 Planejam ento

d o projeto.

PLANEJAMENTO

361

362

Gerenciamento de Projetos

Teoricamente, o patrocinador elabora o termo de abertura e afixa sua assinatura, mas, na verdade, o gerente do projeto pode elaborá-lo para a assinatura do patroci­ nador. No mínimo, o termo de abertura deve incluir: • zX identificação do gerente do projeto e de sua au­ toridade para aplicar recursos para o projeto • zX finalidade do negócio que o projeto foi feito para atender, incluindo todas as premissas e restrições • Uma síntese das condições de definição do projeto • zX descrição do projeto • Os objetivos e as restrições do projeto • O escopo do projeto (inclusões e exdusões) • As principais partes interessadas e seus papéis • Os riscos • O envolvimento de algumas partes interessadas

O Guia PMBOK * fornece uma estrutura para o ter­ mo de abertura do projeto. O que é um pouco lamentável é que cada empresa parece ter sua própria ideia do que deve ser incluído em um termo de abertura. O conteúdo de um termo de abertura é, muitas vezes, dependente de onde, na evolução e no ciclo de vida de um projeto, o termo de aber­ tura é elaborado. (Ver: KER7.NER, Harold. Advanced pro­ ject management: best practices on implementation. New York: John Wiley & Sons, 2004. p. 101-102, 120,629-630.) Algumas empresas como a Computer Associates utiliza tanto um termo de abertura completo (alinhado ao Guia ), * PMBOK quanto um termo de abertura resumido, com base na dimensão e complexidade do projeto. O termo de abertura é um acordo “legal” entre o geren­ te do projeto e a empresa. Algumas empresas complemen­ tam o termo de abertura com um “contrato” que funciona como um acoido entre o projeto e as organizações de linha.

Algumas empresas têm convertido o termo de aber­ tura em um documento altamente detalhado, contendo: • A linha de base do cscopo/declaração do escopo • Escopo e objetivos do projeto (DT) • Especificações • EAP (modelo de níveis) • Gerenciamento do tempo • Plano de gastos (curva S) • O plano de gerenciamento • Requisitos de recursos e de alocação de mão de obra (se conhecido) • Currículo das principais pessoas • Relacionamentos e estrutura organizacionais • Matriz de responsabilidades • Apoio necessário de outras organizações • Políticas e procedimentos do projeto • Plano de gerenciamento de mudanças • Aprovação da administração para os itens acima

Quando um termo de abertura do projeto contém uma linha de base do escopo e o plano de gerenciamento, o termo de abertura do projeto pode funcionar como o plano do projeto. Esse não é realmente um uso eficaz do termo de abertura, mas pode ser aceitável em certos tipos de projetos para clientes internos. 11.27 LINHAS DE BASE D0 PROJETO

Executivos e clientes esperam que os gerentes de projeto monitorem e controlem projetos de forma eficaz. Como parte do monitoramento e controle, os gerentes de pro­ jeto devem preparar relatórios de progresso, status e de previsão que articulem claramente o desempenho do projeto. Mas, para medir o desempenho é necessário um ponto de referência ou linha de base a partir da qual po­ dem ser feitas as medições. A necessidade de uma linha de base é clara:

• Sem uma linha de base, o desempenho não pode ser medido. • Se o desempenho não pode ser medido, não pode ser gerenciado. • O desempenho que pode ser medido é vigiado. • O que é vigiado é realizado. Para que um projeto possa ser controlado, ele deve ser organizado como um sistema fechado. Isto requer que sejam estabelecidas linhas de base para escopo, tempo e custo, no mínimo. Sem essas linhas de base, o projeto é considerado fora de controle, e pode ser impossível de se rastrear o que mudou sem saber por onde você começou. Unha de Base da Medição de Desempenho

O ponto de referência para a medição do desempenho é a linha de base de medição de desempenho Ela serve como uma referência métrica contra a qual o desempenho é medido em termos de tempo, custo e es­ copo. Ê também usada como base para o rastreamento de valor comercial. As principais razões para a criação, aprovação, con­ trole e documentação da PMB são:

• Garantir que os objetivos do projeto sejam atingidos • Gerenciar e monitorar o progresso durante a exe­ cução do projeto • Garantir informações precisas sobre o cumpri­ mento das entregas e requisitos • Estabelecer critérios de medição de desempenho

OT,; Sig/tf para Performance Measurement Baseline (PMB), em português. Unha de Base da Medição de Desempenho.

363

PLANEJAMENTO

O PMB é finalizado no término da fase de planeja­ mento, uma vez que os requisitos tenham sido definidos, os custos iniciais desenvolvidos e aprovados, e o crono­ grama definido. Uma vez estabelecido, o PMB serve como um ponto de referência a partir do qual é possível me­ dir e avaliar o andamento do projeto. A linha de base é usada para medir o progresso real quando comparado ao desempenho planejado. A medição de desempenho pode nào ter sentido sem uma referência precisa como ponto de partida. Infelizmente, os gerentes de projeto tendem a criar linhas de base com base apenas nos elementos de trabalho que consideram importantes, e isso pode ou nào estar em alinhamento total com as necessidades do cliente. A linha de base é o que o gerente do projeto planeja fazer, não necessariamente o que o cliente pediu. O PMB pode ser exibido em formato de planilha ou como um gráfico. Em notação gráfica, é representado como uma curva em S, ou curva de gastos. O PiMB pode ser combinado com o sistema de medição de valor agre­ gado para destacar o desempenho medido contra os pla­ nos originais para o custo e o cronograma. O resultado irá exibir qualquer custo e/ou variações de cronograma, que sào um desvio do plano. O desvio pode ser favorável ou desfavorável. Isto será explicado mais detalhadamente no Capítulo 15. A decisào de realizar ou aceitar um projeto é o dese­ jo de atingir algum objetivo comercial ou alvo. Também pode ser um objetivo técnico ou alvo técnico. Acertar o alvo bem no centro pode ser impossível. Mas chegar perto do centro pode ser aceitável. Em outras palavras, desvios negativos podem nào exigir uma açào corretiva ou alte­ rações de escopo, desde que estejam dentro de valores-li­ mite aceitáveis dos alvos. Se desempenharmos abaixo (ou em alguns casos, até mesmo acima) dos valores-limite, devemos determinar se as metas de desempenho eram ex­ cessivamente agressivas, e neste caso pode ser necessária uma alteração na linha de base de desempenho.

Atualização das Linhas de Base Guia PMBOK ,5. ed.

5.6 Controlar escopo

(Rebaselining)

Projetos sofrem alterações de escopo por várias razões, incluindo:

• Solicitações de alterações do cliente ou de com­ ponentes • Solicitações de alterações da equipe ou de com­ ponentes • Mau entendimento inicial ou má interpretação dos requisitos do cliente • Desempenho mal definido ou linha de base falha • Variações desfavoráveis que não podem ser corrigidas

Quando mudanças à linha de base são solicita­ das, passamos por um comitê de controle de mudan­ ças (CCM), composto por partes interessadas tanto do cliente como das empresas fornecedoras. Nessa reunião do comitê de controle de mudanças, sào abordadas, no mínimo, as três seguintes questões: • O custo da mudança • O impacto sobre o cronograma • O valor adicionado para o cliente Se o CCM aprova a alteração, então o primeiro docu­ mento a ser atualizado é a linha de base de desempenho. Isto é conhecido como “rebaselining" do projeto. Uma vez que o rebaselining ocorre, a nova linha de base é redefini­ da como a original, ou como linha de base anterior mais as mudanças aprovadas. Registros de todas as alterações são mantidas em arquivos para mostrar como o plano foi alterado ao longo do tempo. É importante lembrar que os projetos raramente são executados exatamente conforme o planejado e a rastreabilidade das mudanças é essencial. Desenvolvendo a PMB

Os seguintes passos mostram uma abordagem lógica para a criação de uma PMB:

• Rever business case do projeto e acompanhar as res­ trições epremissas: Esta é uma necessidade, a fim de compreender os limites de negócio da PMB. • Estabelecer uma linha de base de requisitos: Acontece a partir de uma revisão dos requisitos do cliente e da declaração contratual de trabalho * ™. (CSOW) A linha de base de requisitos é o que o gerente dc projetos pretende alcançar e pode conter inclusões e exclusões da documentação original de requisi­ tos do cliente. Isto estabelece o limite técnico para a PMB e alimenta a declaração do escopo do projeto. • Converter a linha de base de requisitos em uma EAP: Decompor o trabalho em pacotes de trabalho. Cada pacote de trabalho deve ter marcos mensu­ ráveis de forma que a realização das entregas e o desempenho possam ser medidos. Criar um di­ cionário da EAP. A linha de base de escopo agora pode ser definida como a declaração do escopo, mais a EAP, mais o dicionário da EAP. • Organizar os pacotes de trabalho em uma rede lógica de atividades: Isso se torna, então, a linha de base do cronograma.

KTI* Sigla cm inglês para Contractual Statement of Work (CSOW) -

Declaração Contratual de Trabalho.

364

Gerenciamento de Projetos • Preço fora da programação cíclica, incluindo custos diretos e indiretos: Isso se torna o orçamento dis­ tribuído. Se o projeto for plurianual, então o tra­ balho para os anos seguintes pode não ser dividido em pacotes de trabalho ainda, apesar de um orça­ mento ter sido estabelecido para cada ano. Isso é chamado de orçamento não distribuído. A soma dos orçamentos distribuídos e não distribuídos compõem a linha de base de custo para o projeto. • A linha de base de custo não inclui a reserva de gerenciamento. A linha de base de custos é basea­ da em orçamentos distribuídos e nào distribuídos que vocé está planejando gastar ao longo da vida do projeto. A reserva de gerenciamento é um di­ nheiro que você espera não gastar. • Finalizar a PMB: A PMB é a soma do escopo, cro­ nograma e linhas de base de custo. • Preparar uma matriz de rastreabilidade de requisi­ tos (RTM)™'9: A RTM liga os requisitos de projeto àEAPeàPMB. • Identificar as principais métricas ou indicadores chave de desempenho (KPls): Essas métricas sào o que será monitorado para determinar o desempe­ nho e cumprimento de requisitos e entregas.

Uma vez que, hoje, se espera que os gerentes de pro­ jeto tomem tanto decisões de negócios como decisões técnicas, devemos ter KPls técnicos e de negócios que indiquem a conformidade com esses dois limites. Se o projeto é de longo prazo e o ambiente de negócios ê di­ nâmico, os KPls relacionados a negócios estão sujeitos a mudanças, e podem indicar que o limite de negócios deve se mover, causando mudanças no escopo na PMB. Essas linhas de base são uma necessidade para a mudança/controle de versào. Sem essas linhas de base, o status e a medição do progresso podem tornar-se sem sentido. E se a medição nào puder ser determinada com algum grau de precisão, então nenhuma informação ob­ jetiva poderá ser encontrada, e poderá ser impossível de­ terminar o verdadeiro valor do que foi realizado.

Embora a linha de base sirva como um excelente ponto de referência, os projetos ainda podem descarriIhar, resultando em mudanças contínuas na PMB. As cau­ sas típicas incluem: • Falhar em administrar as ordens de trabalho corre­ tamente • Falhar em controlar o orçamento

SI’* Sigla em inglês para Requirements Traceability Matrix (RTM) Matriz dc Rastreabilidade de Requisitos.

• Ter um sistema de informação de gerenciamento de projetos que não fornece dados significativos • Compreensão e uso inadequado do sistema de me­ dição de valor agregado • Uso inadequado da reserva de gerenciamento • Constante replanejamento e flutuações da linha de base • Mudanças desnecessárias ou indesejadas por parte da gerência Tipos de Linhas de Base

Anteriormente, discutimos três linhas de base: de esco­ po (também conhecida como a linha de base técnica), de custo, e de programação. No entanto, com base em prá­ ticas de negócios da empresa e tipo de setor, pode haver outras linhas de base. Uma breve lista inclui:

• Linha de Base Funcional: Sistema e/ou requisitos funcionais, tais como especificações, contratos etc. • Linha de Base Alocada: Estado dos produtos de trabalho uma vez que os requisitos são aprovados • Linha de Base do Desenvolvimento: Estado do trabalho e produtos durante o desenvolvimento • Linha de Base do Produto: Características funcio­ nais e físicas do projeto • Linha de Base de Recursos: Número e qualidade dos recursos ao longo da duração do projeto • Linha dc Base Fixa: Linha de base que permanece fixa durante a vigência do projeto • Linha de Base Revisável: Linha de base que pode variar ao longo da vida do projeto • Linha de Base de Projeto Específico: Linha de base projetada para um e apenas um projeto • Linha de Base de Multiprojetos: Linha de base que pode ser aplicada a vários projetos similares 11.28 VERIFICAÇÃO E VALIDAÇÃO

Os termos verificação e validação (V&V) são, muitas vezes, utilizados em conjunto com a PMB. Segundo a Wikipedia, a enciclopédia livre, o processo de verificação e validação envolve verificar se um produto, serviço ou sistema atende às especificações e cumpre com sua finalidade. Algumas vezes, isto é realizado por um terceiro imparcial.

A verificação, algumas vezes, é vista como um pro­ cesso de controle de qualidade que é utilizado para ava­ liar se um produto, serviço ou sistema está ou não em conformidade com regulamentações, especificações, ou condições impostas no início da fase de desenvolvimento. A verificação pode ocorrer no desenvolvimento, na ex­ pansão ou na produção. Geralmente, é um processo de avaliação realizado intemamente.

365

PLANEJAMENTO

TABELA 11-7 Comparação entre verificação e validação Verificocão

VoÜdacõo

Estamos (cnstruirdo o produto

Estimes construindo o produto certo? corretomente?

Redizodo rtemanente, possivelmente peto Reoizodo intemomente e pelo diente

equpe do projeto

a validação devem ser realizadas para assegurar que o sistema ou entrega estão operacionais. Na conclusão da verificação e da validação, muitas vezes obtemos um cer­ tificado ou garantia por escrito de que o sistema, compo­ nente ou entrega está em conformidade com os requisi­ tos especificados e é aceitável para uso da operação.

Mede o adequação e o conformdote com Mede a conformidade com os critérios de as especifKOcoes, requisitas, regulamentos

11.29

MATRIZ DE RASTREABILIDADE DE REQUISITOS

ocátaçõo dc ciente e outras condições impostas

Uso de inspeções, auditorias, revisões,

Testodc pelo ciente ou pdos usuáres

homologações e análises

quanto à funóondidode da entrego

A verificação é, na verdade, a aceitação das entregas ao passo que o controle de qualidade refere-se à correção das entregas. Por vezes, a verificação e o controle de qua­ lidade podem ser feitos em paralelo, mas é mais comum que o controle de qualidade venha primeiro.

A validação é um processo de garantia de qualidade que estabelece evidências ou garantias de que um pro­ duto, serviço ou sistema irá corresponder aos requisitos pretendidos. Isso, muitas vezes, envolve atingir critérios de aceitação ou adequação à finalidade. Ao fornecer uma lista dos requisitos do projeto, as partes interessadas e os clientes podem fornecer critérios de aceitação do produ­ to, que estabelecem critérios e processos para aceitar as entregas finalizadas. Os critérios de aceitação podem in­ cluir informações sobre:

• • • • • • • • • • •

Prazos funcionalidade Aspecto Níveis de desempenho Facilidade de uso Capacidade Disponibilidade Facilidade de manutenção Confiabilidade Custos operacionais Segurança

Costuma-se dizer que a verificação pode ser expres­ sa pela pergunta “Você está construindo certo a coisa?” E validação por “Você está construindo a coisa certa?” “Construir a coisa certa” remete às necessidades do usu­ ário, enquanto “construir certo a coisa” verifica que as especificações estão implementadas corretamente pelo sistema. Em alguns contextos, é necessário ter requisitos escritos para ambos, bem como procedimentos formais ou protocolos para determinar a conformidade. A verificação não necessariamente detecta especi­ ficações de entrada incorretas. Por isso, a verificação e

Existem muitas razões pe­ las quais uma linha de base 52.32 Matriz de Rastreabilidade pode mudar. Se a mudança de Requisitos é o resultado de requisitos alterados, então devemos identificar quando e por que a mudança ocorreu. Isso é feito usando-se uma matriz de rastreabilidade. De acordo com a Wikipedia:

Gào PMBOK3,5. «4.

A matriz de rastreabilidade é um documento, geralmente sob a forma de tabela que correla­ ciona dois documentos quaisquer que tenham linha de base e que requeiram uma relação de “muitos para muitos”para determinara integri­ dade da relação. É frequentemente usada com requisitos de alto nível (estes, muitas vezes, con­ sistem de requisitos de marketing) e os requisi­ tos detalhados do produto de software para as partes correspondentes do design de alto nível, design detalhado, plano de teste e casos de teste. Por exemplo, uma matriz de rastreabilidade de requisitos é usada para verificar se os requisitos atuais do projeto estão sendo cumpridos, e para ajudar na criação da solicitação de proposta, vá­ rios documentos de entrega e planos de tarefa do projeto.

Para facilitar a criação de matrizes de rastrea­ bilidade, é aconselhável adicionar as relações com os documentos fonte, tanto para a rastre­ abilidade “regressiva” como “progressiva”. Em outras palavras, quando um item é alterado em um documento com linha de base, é fácil ver o que precisa ser mudado no outro. A forma mais comum de rastreabilidade é a Ma­ triz de Rastreabilidade de Requisitos. Ela pode ser usada em todas as fases de um projeto para determinar se requisitos estào sendo cumpridos ou não. É também uma ferramenta importante para os processos de validação e verificação. Anteriormente, nos passos necessários para criar uma PMB, afirmamos a necessidade de criar uma matriz de rastreabilidade de requisitos que ligue os requisitos do projeto para o PMB e para a EAP. Como um exemplo

366

Gerenciamento de Projetos

de uma matriz de rastreabilidade, vamos supor que você tenha sido colocado no comando de um projeto para criar uma metodologia empresarial de gerenciamento de projeto, em que os funcionários devem entrar com suas horas trabalhadas a cada dia para os pacotes de trabalho nos quais trabalharam. Requisitos de usuário são defini­ dos como “UR”, seguido por uma designação numérica, e os requisitos do sistema são designações numéricas pre­ cedidas por “SR”. A Tabela 11-8 mostra os requisitos de usuário, e a Tabela 11 -9 mostra os requisitos do sistema. Se rastrearmos a SR-22 de volta para os requisitos funcionais, fica evidente que um erro foi cometido. Temos de corrigir a rastreabilidade ou reescrever/eliminar os re­ quisitos do usuário ou do sistema no qual o erro ocorre. TABELA 11-8 Requisitos do usuário Número de

Rastreabilidade

Requisitos do Usuário Identificocõo

Progressiva 0 usuónc deverá processar suas horas ticbchxte

SR-18, SR-19,

centra um deternwioda pacote de trobefe

SR-20, SR-22

UR-7

0 usuóno de«w processor requsiçoes de

SR-21

UR-8 aquisição por ordem de trobolho

TABELA 11-9 Requisitos do usuário

Número EAP

Todas as organizações e indivíduos funcionais que trabalham direta ou indiretamente em um programa são responsáveis pela identificação, ao gerente do pro­ jeto, de problemas de cronograma e planejamento que exigem ação corretiva, tanto durante o ciclo de plane­ jamento quanto durante o ciclo de operação. O gerente do programa tem a responsabilidade final e definitiva pela identificação de requisitos para ações corretivas. As políticas e diretivas da administração são escritas espe­ cificamente de forma a ajudar o gerente do programa na definição dos requisitos. Sem definições claras durante a fase de planejamento, muitos projetos percorrem di­ versas direções.

iMuitas empresas estabelecem políticas de gestão de planejamento e de cronograma para os gerentes de proje­ tos e gerentes funcionais, bem como uma breve descrição de como devem se relacionar. A Tabela 11-10 identifica uma típica política de gestão para o planejamento e para os requisitos, e a Tabela 11-11 descreve políticas de gestão da programação do cronograma. 11.31

Rostreabíidode

Número de

diretrizes da administração devem ser estabelecidas em uma base ampla pela empresa para alcançar a unidade e coerência.

A INTERFACE ENTRE 0 GERENTE DE

PROJETOS E 0 GERENTE DE LINHA

Requisitos funcionais

Identificação

Regressivo

A utilização de controles de gestão, tais como aqueles 1.7 I labilidades interpessoais descritos na Seção 11.25, não necessariamente garante o planejamento de projeto bem-sucedido. O bom planejamento do projeto, assim como outras funções de projeto, requer uma boa relação de trabalho entre o gerente do projeto e o gerente de li­ nha. Nessa interface: Gvia PMBOK , 5. ed.

1-3-8

SR-18

0 sistema deve ocertor

UR-7

números de dentificoçoo dos empregados e regrstvcr as horas nobobodos nesse

número de cobrança 1-3-12

SR-19

0 sistema deve avolcr se c

UR-7

número de dertificoçoo é koido poro este número de

cobrança

1-3-17

SR-20

0 sistema deve cakutar os

UR-7

valores faturados contra este

número de cobrança SR-21

145

0 sistema deve resume os

UR-8

compras de maténas-pnmcs pao esse demento EAP 1-5-9

SR-22

0 sistema deve determinar

UR-7

o lucro paro os pacotes de

trubobo fechodos

11.30

CONTROLE DE GESTÃO

Como a fase de planejamen­ to fornece diretrizes funda­ 4.5 Realizar o contrvlc integrado dc mudanças mentais para o restante do projeto, o controle cuidadoso da gestão deve ser estabelecido. Além disso, uma vez que o planejamento é uma atividade contínua piara uma variedade de programas diferentes, as

• O gerente de projetos responde a estas perguntas: • O que deve ser realizado? (usando a DT, a EAP) • Quando a tarefa será realizada? (usando o cro­ nograma resumido) • Por que a tarefa deve ser realizada? (usando a DT) • Quanto dinheiro está disponível? (usando a DT) • O gerente de linha responde estas perguntas: • Como a tarefa será realizada? (ou seja, os crité­ rios técnicos) • Onde a tarefa será realizada? (ou seja, os critérios técnicos) • Quem realizará a tarefa? (ou seja, o pessoal)

Guia PMBOK-, 5. ed.

Os gerentes de projetos podem ser capazes de dizer aos gerentes de linha “como” e “onde”, desde que as in­ formações apareçam na DT como um requisito para o projeto. Mesmo assim, o gerente de linha pode se opor, com base em sua experiência técnica.

367

PLANEJAMENTO

TABELA 11-10 Políticas de planejamento e de requisitos Gerente do Programa

Gerente Funcional

Relacionamento

Solicita a ebboroção dos cronogramas mestres do programo

Deser»d»e os detdhes dos plars e requisites do proçrcttmj em

0 planejamento e o programarão do acnoginna do programo

e os fornece poro integração aos cronogranos compostos

cajirto can o gerente do progoma Fornece ação proposta

é irra especioidode funciond; o gerente rb programa

do divisão. Define o trobaho o ser reoizodo por meio

ancpaoojsrEqjBtostfc gererte do peyoroeoo

utiiza cs serviços dos organizações especidtstos.

da ebboroção do pacote da descrição do trobdho

cicnognmo mestre do programo.

Os especiofctos montem seus próprios canais com o gerente geral, mas devem mailer o gerente do programo

subdwddo.

infamado. Fornece orientação e dreção para a ebboroção dos planos

Com orientação fornecido pelo gerente do programa,

0 pbnepmento (b progioma é tombem urm opercçcc

do programa qre estdrebcem os custas, o cronogromo

participa da elaboração dos planos, cronogramas e

consultem e as drefrizes são fanecifas peb gerente b

e o desempenho técnico e define os pnncipm eventos e

documentos de Iberaçoc do trabaho do programo, que

programo. As organizações fine onas inrian as planos

lerdas poro garantir o progresso regular do pogromo.

cobrem os custos, cronogromo e desempenho técnico,

de apoio pero aprovação rb gerente do programa, cu

e que definem os principais eventos e torefas. Fanece

reagem pao modfior as planos para manter o caso.

planos e cronogramas detohodos de apoia

As organizações fiiKbnais também ridom os estudas de ptanejamento que envolvem compensações e cursos dternctiícs de ação poro apresentação oc gerente do

Estabelece as pocododes no ômbto do programa. Obtém

Negocio as prioridades com os gerentes efe programas

programo. 0 gerente do programo e os membros da equpe do

pnondodes rebtrvas do programo entre os proganas

poro eventos e tarefas a serem realizados pelo suo

programa são cnertodos pao o seu pragma, enqmnto

gerenciados por outros programas do óretor, do

organização.

as agonizoçôes funcionais e os gerentes f inciocoès sõo

gerência de programas, do oámnslrodor, de maketing

orientados o 'funções' e o váios programas. A aiertoçõo

e desenvolvimento de produtos, ou do gerente geral,

de coda dieta, gerente, e membro de equpe de/e ser

conforme especifkocb pela politico.

mutoanente reconhecida paro evitar demandas iracionois e prioridades conflitantes. Os conflitos de pnadades que

noc puderem ser resoMdos derem ser lerocbs oo gerente

Aprovo os requisitas de dados contratuais do programo.

Conduz o onófee dos requisitos de dodos contratuais.

geral.

Desenvolve pianos de dodos, indumdo o feto de reqjisitos de dodos do fornecedor e obtém o oprovoçoo do gerente

doprogrerno. Permanece alerto o novos reqursitos de contrato,

Permanece alerto a novos requisitos de contrato,

regulamentações e instruções governamentais que

reguiomeríoçoes e retrações govemomentots que

possam afetar o tobolho, os custos ou o gerenciamento

possam ofetor o nababo, os custos ou o gerenciamento

do programa Fornece definições prévias de requisitos teemeas e substance

de suo agonizoçôo ou de qualquer programo

Fanece os dodos necessários de fazer ou ccmpra;

os recomendações de fazer ou canprar. Pomcpa

substancio os estimate e recomendações no área de

da formulaeàc do plano de fazer ou comprar paro o

espeodidode funciond

A concordância e os oprovoçoes sobre fazer ou compra são

obtidas de ocado can os Políticas e Procedmentos atuais.

programo

Aprovo afeto de mofenors para o pogromo paro o

Preparo o feto de materois do programo.

necessidade e odegucxóo as necessdodes e oes reqwsrtos do programa. Dirige o gerencomento dos dodos, ndundo a marutençoo

de arquivos atoais e htslõncos sobre os requisíos de dodos ccntratuois programados

TABELA 11-11 políticas de programação do cronograma Gerente do Programo

Gerente Funciond

Relodona mento

Fanece reqjsrtos de dodos controtods e orientações pao o

A direção dos operações deve construir o cronogromo

A direção das operoçoes consta o aonogramo meslie do

coratrução dos cronogramas mestres do progoma.

mestre do programa. Os dodos devem incluir, mas não

pogramo com os dados recebidos das organizações

se limita a plenos de engenharia, de produção, de

funcionais e com o dreção do gererte do programa

aquisições, de testes e de qudidode, e devem fornecer

As operoçoes devem coordenar o cronogromo mestre

intervalos de tempo pao o leobzoçóo dos elementos

tb progoma com os organizações funcionais e

de trobobo definidos no estrutura analítico do projeto

garanti oc gerente do programo a oprovoçoo antes

em nível de definição visível no poccte planejado da

do Iberaçoc.

desençoe do trabalho subdmdido. (crstra cronogramas de progoma detabodos e cronogramas

0 gererte do programo mentora os cronogramas

de trabalho em consonância com o crcnogoma mestre tb

efetabados das orgaiizoções funcioneis pao o

programo aprovado pelo frente do gogema. Gorarte

aieqjoçõc oo crcnogramo mestre do programo e

necessánc, sempre que uma agonizoçôo funcional fdho em

concordância oc gerente do programa e encaminho cópias

idato oo diretor, ou oo gerenãamertc de projetos, os

atender ns reqjNtas (fo ciaiogomo mestre do progoma

oo gerente do programa

Coopero com o construção de crcnogramas detalhados petas

orgaiizoções funcionais. Fanece decisões e orientações sobre ações corretivas, conforme

ou quanefo, pa andise, o desemperho inâcodo peb

monitoramento do aonogramo detabodo ameaça impactor o aonogramo mestre do programa

itens de vorioçõo que pessan importer as cpaccóes

da drvisõo.

368

Gerenciamento de Projetos

11.32

PARALELISMO"’70

Às vezes, não importa o quão bem nós planejamos, 2.4 Características do ciclo de acontece algo que gera con­ vida do projeto fusão no projeto. Esse é o caso quando o cliente ou a administração modificam as restrições do projeto. Considere a Figura 11-18 e vamos supor que o tempo de execução para a construção do projeto é de um ano. Elaborar os desenhos técnicos e as especificações até o nível 5 da EAP exigiría um adicional de 35% ao tempo de execução esperado e, se for neces­ sário um estudo de viabilidade, então, um adicional de 40% será acrescentado. Em outras palavras, se a fase de execução do projeto é de um ano, então o projeto inteiro é de quase dois anos. Guia PMBOK ,5. ed.

FIGURA 11-16 A parede de ti jobs.

n

nw vtoxmioo oo um*o n c«snuçtó

FIGURA 11-17 Modificação da parede de tijobs.

As Figuras 11-16 e 11-17 mostram o que pode acontecer quando os gerentes de projetos ultrapassam os seus limites. Na Figura 11-16, o gerente de produção construiu uma parede de tijolos para manter os gerentes de projetos longe de seu pessoal porque aqueles estavam dizendo a este como fazer o trabalho. Na Figura 11-17, os gerentes dos subprojetos (para simplificar, equivalen­ te aos engenheiros de projetos) teriam, em sua carreira, promoções para gerentes de projetos assistentes. Infe­ lizmente, os gerentes de projetos assistentes ainda acha­ vam que eram competentes o suficiente para dar uma orientação técnica, e isso criou um caos para os gerentes de engenharia.

A solução mais simples para todos esses problemas é que o gerente de projetos forneça orientação técnica por intermédio dos gerentes de linha. Afinal, os geren­ tes de linha são supostamente os verdadeiros especialistas técnicos.

FIGURA 11-18 A explosão das informações. Widemon, R. M. CoV tontol oí capUol ptojecb, Vancouver, B.C.: A.E.W. Services of Canada, 1983. p. 22. . * fon

Agora, vamos supor que a administração preten­ da manter a data de término fixa, mas a data de início é atrasada em virtude da falta de financiamento adequado. Como isso pode ser realizado sem sacrificar a qualidade? A resposta é aplicar o paralelismo ao projeto. O parale­ lismo em um projeto significa que as atividades que nor­ malmente são feitas em série serão feitas em paralelo. Um exemplo disso é quando a construção começa antes que o desenho detalhado esteja concluído (ver Capítulo 2, Ta­ bela 2-5, sobre fases do ciclo de vida). Aplicar o paralelismo a um trabalho pode acelerar o cronograma, mas exige correr riscos adicionais. Se os riscos

Tradução oficial da versão em português da quarta edição do

Guia PMBOK0 para a técnica dc compressão do cronograma.

Termo oficial cm inglês. Fast tracking.

369

PLANEJAMENTO

se materializarem, então, ou a data final será atrasada, ou será necessário um dispendioso retrabalho. Quase todas as empresas orientadas a projetos empregam o paralelismo, mas é perigoso quando ele se toma rotina. 11.33 GERENCIAMENTO DE CONFIGURAÇÃO

Uma ferramenta crucial em­ pregada pelo gerente de pro­ 4.5 Realizar o controle integrado jetos é o gerenciamento de de mudanças configuração ou o controle de mudanças de configuração. Conforme os projetos pro­ gridem através das várias fases do ciclo de vida, os custos das mudanças de engenharia podem crescer ilimitadamen­ te. Não é incomum para as empresas ofertarem propostas em 40% abaixo de seu próprio custo, na esperança de fa­ zer a diferença adiante, com as mudanças de engenharia. É também muito comum que os executivos “incentivem” os gerentes de projetos a procurarem as mudanças de enge­ nharia em virtude de sua rentabilidade. Guia PMBOK ', 5. ed.

O gerenciamento de configuração é uma técnica de controle, por meio de um processo ordenado, para revi­ são e aprovação formal das alterações na configuração. Se for devidamente implementado, o gerenciamento de configuração proporciona:

• Níveis adequados de revisão e aprovação de mudanças • Pontos focais para aqueles que procuram fazer mudanças • Um único ponto de entrada para os representantes contratuais dos escritórios do cliente e do fornece­ dor para mudanças aprovadas No mínimo, o comitê de controle da configuração deve incluir a representação do cliente, do fornecedor e do grupo da linha a iniciar a mudança. As discussões de­ verão responder as seguintes perguntas:

• • • • •

Qual é o custo da mudança? As mudanças melhoram a qualidade? O custo adicional por essa qualidade é justificável? A mudança é necessária? Existe um impacto sobre a data de entrega?

Mudanças custam dinheiro. Portanto, é imperativo que o gerenciamento de configuração seja implementa­ do corretamente. Os seguintes passos podem melhorar o processo de implementação:

• Definir o ponto de partida ou “linha de base” da configuração ■ Definir as “classes" de mudanças • Definir os controles necessários ou limitações tan­ to do cliente quanto do fornecedor

• Identificar as políticas e os procedimentos, tais como • Presidente do comitê • Votantes/alternativas • Hora da reunião • Agenda • Fóruns de aprovação • Processos passo a passo • Processos de expedição em caso de emergências

O controle eficaz da configuração agrada tanto ao cliente quanto ao fornecedor. Dentre os benefícios glo­ bais, destacam-se: • • • • • •

Melhor comunicação entre os funcionários Melhor comunicação com o cliente Melhor inteligência técnica Reduzida confusão por mudanças Triagem de mudanças frívolas Evidências escritas

Como nota final, deve ser entendido que o controle de configuração, como usado aqui, não é um substitu­ to para as reuniões de revisão de design ou reuniões de interface com o cliente. Essas reuniões ainda são partes integrantes de todos os projetos. 11.34

METODOLOGIAS DE GERENCIAMENTO DE PROJETOS DA EMPRESA

As metodologias de gerenciamento de projetos da empre­ sa podem melhorar o processo de planejamento do pro­ jeto, bem como fornecer algum grau de padronização e consistência. As empresas começaram a perceber que as metodo­ logias de gerenciamento de projetos da empresa funcio­ nam melhor se forem baseadas em modelos, em vez de políticas e procedimentos rígidos. O International Insti­ tute for learning criou a Unified Project Management Me­ thodology (UPMMTM), uma metodologia unificada de gerenciamento de projetos com modelos categorizados de acordo com as áreas de conhecimento" do Guia PMBOK®: Comunicações

Termo de Abertura do Projeto

Documento de Procedimentos do Projeto Registro de Solicitações de Mudança no Projeto

Relatório de Andamento do Projeto

Unified Project Management Methodology (UPMM)™ é re­

gistrada, possui direitos autorais e é de propriedade do Inter­ national Institute for learning, Inc. ft 2005. Reproduzido com

permissão.

370

Gerenciamento de Projetos Relatório de Garantia da Qualidade do GP

Documento de Aceitação do Produto

Resumo do Gerenciamento das Aquisições

Termo de Abertura do Projeto

Registro de Questões do Projeto

Lista de Verificação da Avaliação do

Plano de Gerenciamento do Projeto

Relatório de Desempenho do Projeto Custos

Processo de Encerramento Relatório de Arquivos do Projeto Aquisições

Cronograma do Projeto

Termo de Abertura do Projeto

Plano de Resposta aos Riscos e Registro dos Riscos

Declaração do escopo

Estrutura Analítica do Projeto (EAP)

Estrutura Analítica do Projeto (EAP)

Pacote de Trabalho

Plano de Aquisições

Documento de Estimativas de Custos Orçamento do Projeto

Lista de Verificação do Planejamento de Aquisições

Lista de Verificação do Orçamento do Projeto Recursos Humanos

Declaração do Trabalho da Aquisição (DT) Esboço do Documento de Solicitação de Proposta

Registro de Solicitações de Mudança no Projeto

Termo de Abertura do Projeto

Lista de Verificação para a Constituição de Contrato

Estrutura Analítica do Projeto (EAP) Plano de Gerenciamento das Comunicações

Resumo do Gerenciamento das Aquisições

Organograma do Projeto Diretório da Equipe do Projeto

Qualidade

Termo de Abertura do Projeto

Matriz de Responsabilidades (MR)

Visão Geral dos Procedimentos do Projeto

Plano de Gerenciamento do Projeto Documento de Procedimentos do Projeto

Plano da Qualidade do Trabalho

Lista de Verificação da Reunião de Kickoff

Estrutura Analítica do Projeto (EAP)

Avaliações do Desempenho da Equipe do Projeto

Relatório de Garantia da Qualidade do GP

Avaliações do Desempenho do Gerente do Projeto

Documento de Lições Aprendidas

Integração

Plano de Gerenciamento do Projeto

Feedback do Desempenho do Projeto

Visão Geral dos Procedimentos do Projeto

Avaliações do Desempenho da Equipe do Projeto

Proposta do Projeto

Documento de Melhoria de Processos do GP

Plano de Gerenciamento das Comunicações Plano de Aquisições Orçamento do Projeto Documento de Procedimentos do Projeto Cronograma do Projeto Matriz de Responsabilidades (MR)

Plano de Resposta aos Riscos e Registro dos Riscos Declaração do Escopo

Riscos

Plano de Aquisições Termo de Abertura do Projeto

Documento de Procedimentos do Projeto Estrutura Analítica do Projeto (EAP)

Plano de Resposta aos Riscos e Registro dos Riscos Escopo

Estrutura Analítica do Projeto (EAP)

Declaração do Escopo do Projeto

Plano de Gerenciamento do Projeto

Estrutura Analítica do Projeto (EAP)

Registro de Solicitações de Mudança no Projeto

Pacote de Trabalho

Registro de Questões do Projeto

Termo de Abertura do Projeto

Registro de Mudanças no Plano de

Gerenciamento do Projeto

Tempo

Planilha de Estimativa da Duração da Atividade

Relatório de Desempenho do Projeto

Documento de Estimativas de Custos

Documento de Lições Aprendidas

Plano de Resposta aos Riscos e Registro

Feedback do Desempenho do Projeto

Intermediário dos Riscos

371

PLANEJAMENTO

Estrutura Analítica do Projeto (EAP)

11.36

Pacote de Trabalho

DE PROJETOS PMP

Cronograma do Projeto

Lista de Verificação da Revisão do Cronograma do Projeto 11.35 AUDITORIAS DE PROJETOS

Nos últimos anos, a necessidade por uma revisão estru­ turada independente das várias partes de um negócio, incluindo projetos, tem assumido um papel mais im­ portante. Parte disso pode ser atribuída às exigências de conformidade da Lei Sarbanes-Oxley. Essas revisões in­ dependentes sào auditorias que incidem sobre qualquer descoberta ou tomada de decisão. As auditorias podem ser programadas ou aleatórias e ser realizadas por pessoal interno ou examinadores externos. Existem vários tipos de auditorias. Alguns tipos co­ muns incluem: • Auditorias dc Desempenho: utilizadas para avaliar o progresso e o desempenho de um determinado projeto. O gerente do projeto, o patrocinador do projeto, ou um comitê diretor pode realizar essa auditoria. • Auditorias dc Conformidade: normalmen­ te realizadas pelo escritório de gerenciamento de projetos (PMO) para confirmar se o projeto está utilizando a metodologia de gerenciamen­ to de projetos adequadamente. Normalmente, o PMO possui autoridade para realizar a audito­ ria, mas pode não ter autoridade para garantir o cumprimento. • Auditorias de Qualidade: garantem que a qualida­ de planejada do projeto está sendo cumprida e que todas as leis e regulamentações estão sendo segui­ das. O grupo de garantia da qualidade realiza essa auditoria. • Auditorias de Saída: geralmente sào para os pro­ jetos que estão em dificuldades e que podem pre­ cisar ser cancelados. Pessoal externo ao projeto, como um campeão de saída ou um comitê diretor, conduz essa auditoria. • Auditorias de Melhores Práticas: podem ser rea­ lizadas no final de cada fase do ciclo de vida ou no final do projeto. Algumas empresas descobri­ ram que os gerentes de projetos podem não ser os melhores indivíduos para realizar a auditoria. Em tais situações, a empresa pode ter facilitadores profissionais treinados na condução de revisões de melhores práticas.

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

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 Iniciação Planejamento Execução Monitoramento Encerramento

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®:

• Necessidade de planejamento eficaz • Componentes de um plano de projeto e planos auxiliares • Necessidade de componentes de uma declaração do trabalho (tanto de proposta, quanto contratual) • Como desenvolver uma estrutura analítica do pro­ jeto e as vantagens e desvantagens de níveis alta­ mente detalhados • Tipos de estruturas analíticas de projeto • Propósito de um pacote de trabalho • Propósito do gerenciamento de configuração e do papel do comitê de controle de mudanças • Necessidade de um termo de abertura do projeto e os componentes de um termo de abertura do projeto • Necessidade de a equipe do projeto ser envolvida nas atividades de planejamento do projeto • Que as mudanças no plano ou na linha de base de­ vem ser gerenciadas

No Apêndice C, os seguintes miniestudos dc caso Dorale Products se aplicam: • Dorale Products (C) (Gerenciamento do Escopo) • Dorale Products (D) (Gerenciamento do Escopo] • Dorale Products (E) (Gerenciamento do Escopo] As seguintes questões de múltipla escolha ajudarão na revisão dos conceitos deste capítulo:

1. O documento que oficialmente autoriza o projeto é: a. Termo de abertura do projeto b. Plano do projeto c. Estudo dc viabilidade d. Análise de custo-beneficio 2. Os “pontos de controle" da estrutura analítica do projeto para o gerenciamento de um projeto são: a. Marcos

372

Gerenciamento de Projetos

b. Pacotes dc trabalho c. Atividades d. Restrições 3. Uma das razões mais comuns pelas quais os proje­ tos são submetidos a mudanças no escopo é a. Estrutura analítica do projeto deficitária b. Declaração do trabalho mal definida c. Falta de recursos d. Falta de financiamento 4. Qual dos itens seguintes geralmente não pode ser validado usando uma estrutura analítica do projeto? a. Controle do cronograma b. Controle dos custos c. Controle da qualidade d. Gerenciamento dos Riscos Responda às questões 5-8 usando a estrutura analítica do projeto (EAP) a seguir (números em parênteses indi­ cam o valor monetário para um determinado elemento):

1.00.00

5.

6.

7.

8.

9.

1.1.0 (S25K) 1.1.1 1.1.2 ($ 12K) 1.2.0 1.2.1 (S16K) 1.2.2.0 1.2.2.1 ($ 20K) 1.2.2.2 ($ 30K) O custo do elemento da EAP 1.2.2.0 é: a. S 20K b. S 30K c. $ 50K d. Nào pode ser determinado O custo do elemento da EAP 1.1.1 é a. S 12K b. S 13K c. S25K d. Nào pode ser determinado O custo dc todo o programa (1.00.00) é: a. S 25K b. S66K c. S91K d. Nào pode ser determinado Os pacotes dc trabalho da EAP estão no(s) nível(is) da EAP: a. 2 apenas b. 3 apenas c. 4 apenas d. 3e4 A linha de base da medição do desempenho é mais frequentemente composta por três linhas de base: a. Linhas de base de custo, cronograma e risco b. Linhas de base dc custo, cronograma c escopo c. Linhas de base dc custo, risco e qualidade d. Linhas de base de cronograma, risco e qualidade

10. Qual (Quais) das seguintes c (são) bcncfi'cio(s) dc se desenvolver uma EAP ate os níveis mais baixos? a. Melhor estimativa de custos b. Melhor controle c. Menos provável que algo vá passar despercebido d. Todas as anteriores 11. As linhas de base, uma vez estabelecidas, identificam: a. O que o cliente e o contratado acordaram b. O que o patrocinador c o diente acordaram c. O que o diente quer que seja feito, mas não ne­ cessariamente o que o gerente de projetos pla­ neja fazer d. O que o gerente de projetos planeja fazer, mas não necessariamente o que o cliente pediu 12. O encerramento financeiro, que é muitas vezes parte seguinte do processo de verificação do esco­ po, é utilizado para: a. Encerrar todos os números de cobrança b. Encerrar todos os números de cobrança para o trabalho realizado e concluído c. Alterar os formulários de autorização do tra­ balho d. Nenhuma das anteriores 13. Um de seus fornecedores lhe enviou um e-mail so­ licitando que sejam autorizados apenas oito testes, em vez dos dez exigidos pela especificação. O que o gerente do projeto deve fazer primeiro? a. Alterar a linha de base do escopo b. Pedir ao fornecedor para publicar uma solicita­ ção de mudança c. Procurar por cláusulas de penalizaçáo no contrato d. Pedir a opinião do seu patrocinador 14. Um de seus fornecedores lhe envia, por e-mail, uma solicitação para utilizar matérias-primas de alta qualidade em seu projeto, declarando que isso será valor adicionado e que melhorará a qualidade. O que o gerente do projeto deve fazer primeiro? a. Alterar a linha de base do escopo b. Pedir ao fornecedor para publicar uma solicita­ ção de mudança c. Pedir a opinião do seu patrocinador d. Mudar a EAP 15. Qual é o número máximo de planos auxiliares que um plano de gerenciamento do programa pode conter? a. 10 b. 15 c. 20 d. Número ilimitado 16. O comitê dc controle dc mudanças, do qual você é um membro, aprova uma mudança significativa no escopo. O primeiro documento que o gerente do projeto deveria atualizar seria o (a): a. Linha dc base do escopo b. Cronograma c. EAP d. Orçamento

373

PLANEJAMENTO

RESPOSTAS I. A

II. D

2. B

3. B

12. B

4. C

13 B

5.C

14. B

6. B 15. D

7.C

8. D

9. B

10. D

16. A

11-18

EXERCÍCIOS 11-1

a. b. c. d. 11-2

11-3

11-4 11-5

11 -6 11-7

118

11 -9 11-10

11 -11

11-12 11-13 11-14

11-15

11-16

11-17

Sob quais condições cada uma das seguintes alternativas não estaria disponível ou não seria necessária para fins de planejamento inicial? Estrutura analítica do projeto Declaração do trabalho Especificações Cronogramas de marcos Que medidas de planejamento devem preceder a programação do cronograma total do progra­ ma? Quais passos são necessários? Como é que um gerente de projetos determina a complexidade de fazer um plano de programa ou quantos cronogramas incluir? Os objetivos podem ser sempre identificados e programados? Uma EAP pode ser sempre estabelecida para atingir um objetivo? Quem determina o trabalho necessário para re­ alizar um objetivo? Quais papéis um gerente funcional desempenha no estabelecimento dos três primeiros níveis da EAP? A duração de um programa deveria ter um im­ pacto sobre o estabelecimento de um projeto separado ou de tarefas de apoio administrativo? E quanto às matérias-primas? í- possível que a EAP seja projetada de modo que a alocação dc recursos seja mais fácil dc identificar? Sc o escopo do esforço de um projeto muda du­ rante a execução das atividades, qual deve ser o papel do gerente funcional? Que tipos de conflitos podem ocorrer durante o ciclo de planejamento, e quais modos devem ser utilizados para a resolução desses conflitos? Qual seria a eficácia da Figura 11 -3 se os pacotes de trabalho fossem substituídos por tarefas? Sob quais circunstâncias ou projetos a autorização de planejamento do trabalho não será necessária? Em que tipos de projetos as posições de cober­ tura poderiam ser facilmente identificadas cm um cronograma? As atividades 5 e 6 da Figura 11-11 podem ser eliminadas? Quais sào os riscos a que um ge­ rente de projetos está sujeito se essas atividades forem eliminadas? Quando, no ciclo de planejamento, os organo­ gramas de responsabilidade devem ser prepa­ rados? Você consegue identificar esse ponto na Figura 11-11? Para cada um dos pontos de decisão na Figura 11-13, quem toma a decisão? Quem deve fornecer

11-19

11-20

11-21

11-22

11 -23

11-24

11 -25

11-26

informações? Qual c o papel do gerente funcional e do membro da equipe funcional? Onde estão identificadas as variáveis estratégicas? Considere um projeto em que todo o planeja­ mento seja realizado por um grupo. Após todo o planejamento ser concluído, incluindo o plano do programa e os cronogramas, um gerente de projetos é selecionado. Há algo de errado com essa configuração? Isso pode funcionar? Como c que o cliente e o fornecedor sabem se cada um tem plena consciência da declaração do trabalho, da estrutura analítica do projeto e do plano do programa? Um bom plano de projeto deveria formular mé­ todos para antecipar problemas? Alguns gerentes dc projetos agendam reuniões dc equipe como o principal meio para o plane­ jamento c o controle. Você concorda com esta filosofia? Paul Mali (Managemet by objectives. New York: John Wiley, 1972. p. 12) define a APO como um processo de cinco etapas: • Descobrimento do objetivo • Definição do objetivo • Validação do objetivo • Implementação do objetivo • Controle c relatório dc andamento do objetivo (Somo pode a estrutura analítica do projeto ser utilizada para realizar cada um dos passos aci­ ma? Você concordaria ou discordaria que quan­ to mais níveis a EAP tiver, maior a compreensão c a clareza dos passos necessários para comple­ tar os objetivos? Muitos livros dc administração declaram que você deve planejar como trabalha, fazendo uma coisa dc cada vez. Essa mesma prática pode ser aplicada ao nível dc projeto, ou um gerente de projetos deve planejar todas as atividades de uma vez? É verdade que os gerentes dc projetos estabele­ cem os marcos c os gerentes funcionais esperam poder atendê-los? Você foi convidado a desenvolver uma estrutura analítica para um projeto. Como você deve pro­ ceder para realizar isso? A EAP deve ser baseada nas fases do tempo, dos departamentos, das di­ visões ou em alguma combinação? Você acaba dc ser encarregado de elaborar um cronograma para a introdução dc um novo produto no mercado. /\ seguir estão os ele­ mentos que devem aparecer em seu cronogra­ ma. Organize esses elementos em uma estru­ tura analítica dc projeto (até o nível 3) c, cm seguida, desenhe o diagrama dc seta. Fique à vontade para acrescentar tópicos adicionais, conforme necessário.

374

Gerenciamento de Projetos

layout ác Produção Testes de mercado Análise do custo de venda Análise das reações dos clientes Armazenagem e custos de embarque Seleção dc vendedores Treinamento de vendedores Treinamento de distribuidores Material impresso para os vendedores Material impresso para os distribuidores Impressão de material Promoção de vendas Manual de vendas Anúncio comercial Revisão dos custos de fábrica Seleção de distribuidores layout da arte Aprovação da arte Apresentação cm uma feira Distribuição para vendedores Estabelecimento do procedimento para faturamento • Estabelecimento do procedimento para crédito • Revisão do custo de produção • Revisão do custo de venda • Aprovações * • Reuniões dc revisão’ • Especificações finais • Requisições de material (‘tarifa de omwóo e da Kvtío qwetw unes ivk) • • • • • • • • • • • • • • • • • • • • •

11-27 Assim que um projeto começa, um bom geren­ te de projetos criará pontos de controle. Como isso deve ser realizado? A duração do projeto importará? Os pontos dc controle podem ser integrados cm um cronograma? Sc sim» como eles devem ser identificados? 11-28 Os cronogramas detalhados (pelos níveis 3, 4, 5... da EAP) são elaborados pelos gerentes fun­ cionais. Esses cronogramas devem ser apresen­ tados para o cliente? 11-29 A fase de lançamento do projeto está completa c agora você está pronto para finalizar o plano operacional. A seguir estão seis passos que geral­ mente fazem parte do processo de finalização. Coloque-os na ordem apropriada. 1. Desenhar diagramas para cada demento in­ dividual da EAP. 2. Estabelecer a estrutura analítica do pro­ jeto e identificar os elementos c níveis de subordinação. 3. Criar um diagrama de rede grosseiro (dia­ grama de setas) e decidir sobre a EAP. 4. Refinar o diagrama por meio da combinação de toda a lógica em um plano. Em seguida, decidir sobre as designações de trabalho.

5. Sc necessário, tentar condensar o diagrama ao máximo, sem perder a clareza. 6. Integrar os diagramas em cada nível, até que reste apenas um nível. Então, começar a in­ tegração dos níveis mais elevados da EAP até que o plano desejado seja alcançado. 11-30 A seguir, são listados sele fatores que devem ser considerados antes da finalização de um cro­ nograma. Explique como o cronograma de um caso dc base pode mudar como resultado de cada um destes: • Introdução ou aceitação do produto no mercado • Disponibilidade atual e prevista de pessoal • Restrições econômicas do projeto • Grau de dificuldade técnica • Disponibilidade da mão de obra • Disponibilidade dc treinamento dc pessoal • Prioridade do projeto

11-31 Você é o gerente de projetos de um esforço de nove meses. Você está agora no quinto mês do projeto c está mais de duas semanas atrasado, com muito pouca esperança de recuperação. A barragem rompe cm uma cidade perto de você c ocorrem inundações enormes c deslizamentos dc terra. Quinze dos seus principais colabora­ dores funcionais solicitam tirar (rês dias a partir da semana seguinte para ajudar os membros da igreja a cavar. O gerente funcional deseja-lhes boa sorte e deixa toda a decisão a seu critério. Você deveria deixá-los ir? 11 -32 Uma vez que o gerente funcional e o gerente do projeto concordam com um cronograma do projeto, quem é responsável por realizar o tra­ balho? Quem é o responsável por ter o trabalho realizado? Qual é a diferença, se houver? 11 -33 Discuta a validade das seguintes declarações so­ bre autoridade: a. Um bom gerente de projetos terá mais auto­ ridade do que a sua responsabilidade exige. b. Um bom gerente de projetos nào deve res­ ponsabilizar um subordinado por deveres os quais dc (o gerente do projeto) não possui autoridade para impor. 11 -34 A seguir, há 12 instruções. Quais são mais bem descritas como planejamento c quais são mais bem descritas como previsão? a. Dê uma definição completa do trabalho. b. Eslabdeça um cronograma proposto. c. Estabeleça marcos do projeto. d. Determine a necessidade por recursos diferentes. e. Determine as competências necessárias para cada tarefa ou elemento da EAP.

PLANEJAMENTO

f. Altere o escopo do esforço e obtenha no­ vas estimativas. g. Estime o tempo total para completar o tra­ balho necessário. h. Considere a mudança dc recursos. i. Designe pessoal adequado para cada elemento da EAR j. Programe novamente os recursos do projeto. k. Comece a programação dos elementos da EAP. l. Altere as prioridades do projeto. 11 -35 Uma empresa dc serviços públicos possui um grupo de planejamento, que elabora orçamen­ tos (com a ajuda de grupos funcionais) e sele­ ciona os projetos a serem concluídos dentro dc um determinado período. Você está designado como gerente de projetos para um dos projetos e descobre que ele deveria ter sido iniciado no “mês passado” a fim dc cumprir a data de con­ clusão. O que você, o gerente do projeto, pode fazer a respeito disso? Você deve atrasar o início do projeto para rcplancjar o trabalho? 11 -36 O diretor de gerenciamento dc projetos o chama em seu escritório e informa que um de seus cole­ gas gerentes de projetos teve um ataque cardíaco grave no meio do projeto. Você será encarrega­ do do projeto dele, que está bem atrasado e com sobrecustos. O diretor de gerenciamento de pro­ jetos, então, “ordena" que você termine o proje­ to dentro do prazo c dos custos. Como você se propõe a fazer isso? Por onde você começa? Você deve interromper o projeto para replanejá-lo? 11 -37 Planejamento ê frequentemente descrito como estabelecimento, orçamento, programação e alocação de recursos. Identifique esses quatro elementos na Figura 11-1. 11-38 Uma empresa está empreendendo um grande projeto de desenvolvimento que exige que uma enorme “impressão da árvore do projeto" seja desenvolvida. Que tipo de esboço da EAP seria o melhor para minimizar o impacto de ter dois sistemas, um para impressão e um para o traba­ lho da EAP? 11-39 Uma empresa permite que cada organização de linha execute suas próprias atividades de aquisições (por meio de um escritório centra­ lizado de aquisições), contanto que recursos financeiros de aquisições tenham sido alocados durante a fase de planejamento do projeto. O escritório de projetos não autoriza essas requisi­ ções de aquisições funcionais e podem até mes­ mo desconhecê-las. Esse sistema pode funcio­ nar eficazmente? Se sim, sob quais condições? 11-40 Como parle de um estudo de viabilidade, você é solicitado a elaborar, com o auxílio de

375 gerentes funcionais, um cronograma e um re­ sumo de custos para um projeto que irá ocor­ rer três anos adiante, se o projeto for mesmo aprovado. Suponha que em três anos o pro­ jeto seja aprovado. Como ê que o gerente do projeto consegue fazer com que os gerentes funcionais aceitem o cronograma e a soma de custos que eles mesmos prepararam três anos atrás? 11-41 “Esperando por problemas”. Bons gerentes de projetos sabem que tipo de problema pode ocorrer nas diferentes etapas de desenvolvimen­ to de um projeto. As atividades na lista numera­ da a seguir indicam as várias fases de um proje­ to. A lista com as letras que se segue identifica os principais problemas. Para cada fase do projeto, selecione e liste todos os problemas que lhe são aplicáveis. 1. Solicitação de proposta________________ 2. Apresentação para o cliente____________ 3. Concessão do contrato_________________ 4. Reuniões de revisão de design___________ 5. Teste do produto______________________ 6. Aceitação do cliente___________________

a. A engenharia não solicita a contribuição da produção para a produtibilidade do item final. b. A estrutura analítica do projeto está mal definida. c. O cliente não percebe totalmente o impacto que uma mudança técnica terá sobre os custos e sobre o cronograma. d. As restrições de tempo e custos nào sào compatíveis com o estado da arte. e. A interface entre o projeto e a área funcional ê deficitária. f. A integração inadequada de sistemas gerou conflitos e um colapso nas comunicações. g. Vários gerentes funcionais não perceberam que eram responsáveis por determinados riscos. h. O impacto das mudanças de design não é sistematicamente avaliado. 11-42 A Tabela 11-12 identifica 26 passos no planeja­ mento e controle do projeto. A seguir, há uma descrição de cada um dos 26 passos. Usando essa informação, preencha nas colunas 1 e 2 (a coluna 2 é uma resposta do grupo). Após o seu instrutor lhe fornecer a coluna 3, preencha o restante da tabela. 1. Desenvolver o organograma linear de res­ ponsabilidade. Esse gráfico identifica a es­ trutura analítica do projeto e atribui autoridade/responsabilidade específica a vários indivíduos como grupos, para garantir que todos os elementos da EAP sejam contabi­ lizados. O organograma linear de respon­ sabilidade pode ser elaborado tanto com

376

Gerenciamento de Projetos 4. Determinar os meios para a medição do progresso. Antes que o plano do projeto seja finalizado e que a execução do projeto possa começar, o gerente do projeto deve identifi­ car os meios para a medição do progresso; especificamente, o que se entende por con­ dição “fora de tolerância” e quais são as tolerâncias/variações/ limites para cada elemen­ to do caso de base da EAP? 5. Elaborar o relatório final. Esse é o relatório final a ser elaborado na finalização do projeto. 6. Autorizar os departamentos a começar o trabalho. Isso autoriza os departamentos a iniciar a real execução do projeto, e não o planejamento. Essa etapa ocorre geralmente depois que o plano do projeto foi estabeleci­ do, finalizado e, talvez, até mesmo aprovado pelo cliente ou grupo de usuários. Esse é o início das ordens de trabalho para a imple­ mentação do projeto.

os títulos como com os nomes das pessoas. Suponha que ele seja elaborado após você negociar pessoal qualificado, de modo que você possa saber ou os nomes ou as capaci­ dades dos indivíduos que serão designados. 2. Negociar por pessoal funcional qualificado. Uma vez que o trabalho tenha sido decidi­ do, o gerente de projetos tenta identificar as qualificações para o pessoal desejado. Isso se torna, então, a base para o processo de negociação. 3. Desenvolver as especificações. Esse é um dos quatro documentos necessários para definir inicialmente os requisitos do projeto. Suponha que se tratem de especificações de desempenho ou de material, c sejam forne­ cidas a você no estágio de planejamento ini­ cial, tanto pelo cliente quanto pelo usuário. TABELA 11-12 Passos no planejamento e controle do projeto

Descrição

Atividade

Desenvolver o organograma Ireor de responsddicfode

2.

Negocia por pessoal furocrol quáihcoá

3.

Desenvolver as especifnocoes

4.

Determinar os meios para a mediçoo do progresso

5.

Elaborar o relatório final

6.

Autorizar os departamentos o começa o trabalho

7.

Desenvolver o estruturo anolitxo do projeto

8.

Encenar os ordens de Irobot» fincionois

9.

Desenvolver o dedoroçoo do escopo e estabelecer objetivos

10.

Desenvolvei o crorogoma gerd

11.

Desenvolver as priondodes pota cada elemento do projeto

12.

Desenvolvei cursos dterrotrros de oçòo

13.

Desenvolvei o rede PERT

14.

Desenvolvei cronogramas detdhodos

Estabelecer quolíkoções paro o pessoal funcional

9»

Coordenar as atmdodes em ondamento

17.

Determinar os reqursitos de recursos

18.

Mf o progresso

19.

Deciór sobre um curso básico de oçoo

20.

Estabelecer os custos de coda demento do EAP

21.

Revisor os custos da EAP com codo gerente funcional

22.

Estabelecer um plano do projeto

23.

Estabelecer as variações de custos poro os dementas do coso de base

24.

Estimei o EAP

25.

Estabelecer umo rede lógico com pontos de controle

26.

Reveres custos do caso de base com o diretor

Coluno 1: Suo sequência

Colimol Sequência do Grupo

Coluno 3: Sequência do Especdrsro

Coluno 4: Diferença entre 1 e 3

Coluno 5 Diferenço ente 2e3

PLANEJAMENTO

7. Desenvolver a estrutura analítica do projeto. Esse é um dos quatro documentos necessá­ rios para a definição do projeto no início do estágio de planejamento do projeto. Supo­ nha que a EAP seja construída usando uma abordagem bottom-up. Em outras palavras, a EAP é construída a partir da rede lógica (diagrama de setas) e dos pontos de controle que eventualmenle se tornarão a base para os diagramas PERT/CPM (ver Atividade 25). 8. Encerrar as ordens de trabalho funcionais. £ quando o gerente do projeto tenta evitar a cobrança excessiva para seu projeto, en­ cerrando as ordens de trabalho funcionais (ou seja. Atividade 6), conforme o trabalho termine. Isso inclui o cancelamento de todas as ordens de trabalho, exceto aquelas neces­ sárias para administrar o encerramento do projeto e a elaboração do relatório final. 9. Desenvolver a declaração do escopo e esta­ belecer objetivos. Essa é a declaração do tra­ balho e é um dos quatro documentos neces­ sários, a fim de identificar os requisitos do projeto. Normalmente, a EAP é a estrutura­ ção da declaração do trabalho. 10. Desenvolver o cronograma geral. Esse é o cronograma resumido ou de marcos neces­ sários no início do projeto, a fim de definir os quatro documentos de requisitos para o projeto. O cronograma geral inclui datas inicial e final (se conhecidas), outros marcos importantes e itens de dados. 11. Desenvolver as prioridades para cada ele­ mento do projeto. Depois que o caso de base for identificado e os cursos alternativos de ação considerados (isto é, planejamento de contingência), a equipe do projeto realiza uma análise de sensibilidade para cada elemento da EAP. Isso pode exigir atribuir prioridades para cada elemento da EAP e as prioridades mais altas podem nào necessariamente ser atribuí­ das a elementos do caminho crítico. 12. Desenvolver cursos alternativos de ação. Uma vez que o caso de base é conhecido e que os cursos de açào detalhados (ou seja, o cronograma detalhado) estejam elaborados, os gerentes de projetos conduzem os jogos “e se" para desenvolver possíveis planos de contingência. 13. Desenvolver a rede PERT. Essa é a finaliza­ ção da rede PERT/CPM e se torna a base do cronograma detalhado que será realizado. A lógica para a rede PERT pode ser realiza­ da no início do ciclo de planejamento (ver

377 Atividade 25), mas a finalização da rede, juntamente com as durações de tempo, ge­ ralmente se baseia em quem foi (ou será) designado, e a autor idade/responsabilidade resultante do indivíduo. Em outras palavras, a duração do tempo da atividade é uma fun­ ção, não apenas de padrão de desempenho, mas também de conhecimento técnico do indivíduo e autoridade/responsabilidade. 14. Desenvolver cronogramas detalhados. Esses são os cronogramas de projeto detalhados, e sào construídos do diagrama PERT/CPM e das capacidades dos indivíduos designados. 15. Estabelecer qualificações para o pessoal funcional. Uma vez que a alta administração revisa os custos do caso de base c aprova o projeto, o gerente do projeto começa a tare­ fa de conversão de planejamento geral para planejamento detalhado. Isso inclui a identi­ ficação dos recursos requeridos e, em segui­ da, das respectivas qualificações. 16. Coordenar as atividades em andamento. São as atividades em curso para a execução do projeto e não para o planejamento do projeto. Essas são as atividades que foram autorizadas a começar na Atividade 6. 17. Determinar os requisitos dc recursos. De­ pois que a alta administração aprova os custos estimados do caso de base durante o planejamento global, o planejamento de­ talhado começa por meio da determinação dos requisitos dc recursos, incluindo recur­ sos humanos. 18. Medir o progresso. Conforme a equipe do projeto coordena as atividades em andamen­ to durante a execução do projeto, a equipe monitora o progresso e elabora relatórios de andamento. 19. Decidir sobre um curso básico de ação. Uma vez que o gerente do projeto obtém as estimativas aproximadas dc custos para cada elemento da EAP, ele reúne todas as peças e determina o curso básico dc ação. 20. Estabelecer os custos de cada elemento da EAP. Depois de decidir sobre o caso de base, o gerente do projeto estabelece os custos do caso de base para cada elemento da EAP, a fim de preparar-se para a reunião de avalia­ ção da precificação com a alta administra­ ção. Esses custos são normalmente os mes­ mos daqueles que foram fornecidos pelos gerentes de linha. 21. Revisar os custos da EAP com cada gerente funcional. Cada gerente funcional recebe a

378

Gerenciamento de Projetos EAP c c avisado para determinar seu papel c estimar o seu envolvimento funcional. O ge­ rente do projeto, em seguida, revê os custos da EAP para se certificar de que tudo foi con­ tabilizado e sem duplicação de esforços. 22. Estabelecer um plano do projeto. Este é o úl­ timo passo no planejamento detalhado. Após essa etapa, começa a execução do projeto. (Ig­ norar a situação em que o desenvolvimento do plano do projeto possa ser executado con­ comitantemente com a execução do projeto.) 23. Estabelecer as variações de custos para os elementos do caso de base. Uma vez que as prioridades são conhecidas para cada ele­ mento do caso de base, o gerente do projeto define as variações admissíveis de custos que serão utilizadas como um meio para a me­ dição do progresso. O relatório dos custos é mínimo, contanto que os custos reais perma­ neçam dentro dessas variações admissíveis. 24. Estimar a EAP. Isso é feito quando o geren­ te do projeto fornece a EAP a cada gerente funcional para a prccificação inicial das atividades. 25. Estabelecer uma rede lógica com pontos de controle. E a abordagem bottom-up, que muitas vezes c utilizada como base para o desenvolvimento tanto da EAP quanto mais tarde - da rede PERT/CPM. 26. Rever os custos do caso de base com o di­ retor. Aqui o gerente do projeto reúne os

11 -43

11-44

a.

b.

hoKoLMf.S Tordo i. Vuo geri do sisiemc i [spec hopes de design do sistema ü Espedcoções do peograro

1

i

j1

d

I

i

2001

I

2000

] -

custos aproximados obtidos durante a prc­ cificação funcional da EXP, revisa-os e busca a aprovação da administração para iniciar o planejamento detalhado. Considere a estrutura analítica do projeto apre­ sentada na Figura 11-19. O projeto pode ser gerenciado a partir dessa única folha de papel presumindo-se que, ao final de cada mês, o ge­ rente do projeto recebe também um resumo dos custos e do percentual concluído? Durante 1992 e 1993, a General Motors economi­ zou mais de S 2 bilhões, cm virtude dos esforços de corte de custos do Sr. Lopez. Rumores se espalha­ ram por toda a indústria automobilística de que a General Motors estava considerando um plano para oferecer às subcontratadas contratos dc dez anos em troca de uma redução de 20% nos custos. Esses contratos de longo prazo forneceram tanto à GM quanto às subcontratadas a chance dc desenvolver uma relação informal dc geren­ ciamento de projetos com base na confiança, na comunicação eficaz e nos requisitos míni­ mos de documentação. Ê concebível que as economias dc custos dc 20% pudessem ler sido percebidas tolalmente com a diminuição de documentação formalizada? Filosoficamente, o que você acha que aconteceu quando o Sr. Lopez saiu da GM na primavera de 1993, por um alto cargo na Volkswagen? O seu sistema de gerenciamento de projetos informal continuou sem dc? Explique sua resposta.

i 11 i li 1 ii 1

■

—1 3

i

■■■■ ■

■

k Progicrrxco e lestes *. krdemertopo e lerawto

Pw»c i tortete de lebre Tordo i. Veôo geri do sistema iEspethopesde design do sistema

■ Espedcoções do pngraro k hogmrnxõo e lestes *. irr^emertopo e fcwonero

horioi Sfcxker Tordo i. Vbõo geri do sclent i Esper hopes de design do sistema

k Espedroções do proçrtrro k Pioçictcgo e leses v. kr fiemertopo e fcemenento

FIGURA 11-19 Estruturo analítica do projeto.

■ ^^B

■

■

1 j ! ís

PLANEJAMENTO

11 -45 Durante a recessão de 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 de projetos em plantas industriais. Com menos re­ cursos disponíveis, mais e mais trabalho teve de ser terceirizado, principalmentc para os serviços. As fabricas tinham anos de experiência em ne­ gociações de peças, mas experiência limitada nas negociações de serviços. (Somo resultado, os con­ tratos de sendç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/ftojed Livro de Exeraãos Relacionado (de Kerzner/frojecf Management Management Case Studies, 4. ed.) Workbook ond PMf/CAPIf Exam study Guide, 11. ed.) •

Crosby Manufatuing Corpofotwi'

• Crashing the Effort

•

lhe Invisible Sponsor *

• Multiple Choke Exom

Glia PMBOK - 5. ed., Seção de Referência para o Exame de Certificação PMP'

• Gerenciamento de tempo do Piojelo

• Crossword Puzzle on lime (Schedule) Monogemen

12.0

INTRODUÇÃO

• Técnica de Avaliação e Revisão de 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 clientes.

----Guia PMBOK , 5. ed. ---6.2.3.3 Lista dos marcos ----

As técnicas de programação ajudam a alcançar essas metas. 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 Sequenciar 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. /\ 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«as

fesfccotdudj

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 • • • •

lejendc

—► AhdcCe

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. FUNDAMENTOS DE REDE

12.1

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 e 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. GwtaPMBOK^S.W.

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.

6322 Determinação de dqxndência

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

Guia PMBOK ', 5. ed.

63 Sequencer 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.0 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. F.m 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

1-2 2-3 2-4 3-5 3-7 4-5 4-8 5-6 6-7 7-8 8-9

A 8 C D E F 6 H 1 J K

Predecessors Imediatas

Tempo do Atividade, Semanas

A A B B c c D.F H EJ GJ

1 5 2 2 2 2 3 2 3 3 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. Guia PMBOK ,5. ed.

6.3 Scquenciar as atividades

Tempo Serrares

Connote reçooodo Crido)

legendo

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

Aqjstoes de bngo prazo

—► Atafcxfe —► (cmntocriiKD

12.2

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

Cronogancs de fótréo Listo de materiais Aqjsçôes de axto «azo

Pfcícsde produção Especificação de material Atividade de riciofroçõo

FIGURA 12-4 Rede PERT simplificada.

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.]

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.3

12.4

DEPENDÊNCIAS Guia PMBOK , S. ed.

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

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. As 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-

TEMPO DE FOLGA

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 crítico 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 PMBOK7, 5. ed.

O caminho crítico é vital para a programação e a alocação dc 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 tempo mais tarde (data) em que um evento pode ocorrer sem estender a data de conclusão do projeto Tl =

Tempo de folga = TL- Tk

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’, = 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 (7'£ = 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.

g i I

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.

75

hercto Red

2

4

6

8

10

12

14

16

Terrpo. sercrcs

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 tempt. 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­

MARQUIS, Donald. Ways of Organizing Projects, Innovation,

cluir alguma folga. Esses casos nào serão considerados aqui.

1969.

5

388

Gerenciamento de Projetos

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

Número

TençoMobCedo

Tempo M05T0.de

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

Mobíidode de Alende.

Guia PMBOK , 5. ed. 6.3.2 Sequencer as atividades

IderfifMOiKdoolMWe—,— Tempo de há mots cedo \

,— farpo de rarano m® cedo

-Tempo de fatrino m Tradução oficial, dc acordo com o glossário da quarta edição

do Guia PMBOK*, onde o termo equivalente em inglês é Lag. Em citação ao glossário, a definição dc espera é: “Uma modi­ ficação de um relacionamento lógico que gera um atraso na atividade sucessora."

de 2 dias após o toirino de A

FIGURA 12-26 Gráficos de precedência com espera.

A folga é medida dentro das atividades enquanto a espera é medida entre as atividades. Como exemplo, veja a Figura 12-26A. Suponha que a atividade A termine no final da primeira semana de março. Uma vez que este é um gráfico de precedência término para início, seria de esperar que o início da atividade B estivesse no início da segunda semana de março. Mas, se a atividade B não pode começar até o início da terceira semana de março, isso indicaria uma semana de atraso entre a atividade A e a atividade B, embora ambas as atividades possam ter folga na atividade. Conforme a definição, a folga é medida no interior das atividades enquanto a espera é medida entre as atividades. A espera pode ser o resultado de limitações de recursos.

401

TÉCNICAS DE PROGRAMAÇÃO DE REDE

Um termo comum é antecipaçãoNI7. Novamente, ao observar a Figura 12-26A, suponha que a atividade A ter­ mina em 15 de março, mas o gráfico de precedência mos­ tra a atividade B com início em 8 de março, sete dias antes da realização da atividade A. Neste caso, E = -7, um valor negativo que indica que o início da atividade B antecipa a conclusão da atividade A em sete dias. Para ilustrar como isso pode acontecer, considere o seguinte exemplo: o ge­ rente de linha, responsável pela atividade B, prometeu-lhe que os recursos estarão disponíveis em 16 de março, um dia após o término esperado para a atividade A. Então, o gerente de linha informa que esses recursos estarão dispo­ níveis em 8 de março e se você não alocá-los ao seu núme­ ro de cobrança naquele momento, eles podem ser designa­ dos para outro lugar e não estar mais disponíveis no dia 16. A maioria dos gerentes de projetos tomaria recursos nos dias 8 e encontraria algum trabalho para eles, embora a ló­ gica diga que o trabalho não pode começar até que a ativi­ dade A esteja concluída. 12.14

Há uma tendência de os gerentes serem agressi­ vamente positivos em seu pensamento no início de um projeto, acreditando que as técnicas de compressão podem ser aplicadas de forma efi­ caz. Conforme discutido por GreyH: Há uma tendência comum, especialmente entre as pessoas que foram convencidas que devem "pen­ sar positivo”, de não estarem dispostas a aceitar que uma atividade pode levar mais tempo do que o planejado. A pergunta "Qual é o tempo máximo que a atividade pode ser realizada?” elas respon­ dem com: “Ela será finalizada no tempo previsto, pois não permitiremos que leve mais tempo”, ou palavras com o mesmo efeito. As palavras “não permitiremos que leve mais tempo” ou “não deve levar mais tempo” são tão consistentes que devem refletir uma característica comum da forma como as empresas gerenciam seus funcionários. Enquanto a maioria das pessoas está disposta a aceitar que os custos possam exceder as expecta­ tivas, e teria um prazer perverso em relatar exem­ plos do passado, o mesmo nào é verdade em re­ lação aos prazos. Isso é devido provavelmente ao fato de que sobrecustos são resolvidos em casa, enquanto as questões de cronograma estão aber­ tas e visíveis para o cliente.

PROBLEMAS DE PROGRAMAÇÃO

Toda técnica de programação possui vantagens e desvan­ tagens. Alguns problemas de programação são o resulta­ do de indecisão organizacional, tal como ter um patro­ cinador que se recusa a fornecer ao gerente de projeto orientação sobre se o cronograma deve ser baseado em um objetivo de programação de menor tempo, menor custo ou menor risco. Como resultado, tempo precioso é desperdiçado em ter de refazer os cronogramas. No entanto, existem alguns problemas de programação que podem impactar todas as técnicas de programação. Es­ ses problemas incluem: • Uso de estimativas irrealistas para o esforço e a duração • Incapacidade de lidar com desequilíbrios de carga de trabalho do empregado • Ter de compartilhar recursos críticos em vários projetos • Recursos superalocados • Reajustes contínuos na EAP, principalmente a par­ tir de mudanças no escopo • Gargalos imprevistos 12.15

Pode haver maneiras pelas quais um crono­ grama possa ser mantido, não importa o que aconteça. Tarefas de estudo são quase sempre concluídas no tempo, pois o escopo do traba­ lho pode variar de acordo com o que o estudo encontrou. No entanto, essa é a exceção e não a regra. Em geral, você pode ter a certeza de que uma tarefa será concluída a tempo se:

• O escopo de trabalho for flexível, pelo menos em certa medida • For possível calibrar a tarefa da parte inicial do trabalho para dizer se o ritmo de trabalho previsto é adequado • Você puder elevar o ritmo de trabalho e/ou re­ duzir o escopo do trabalho para trazer a tarefa de volta ao alvo no tempo restante após perce­ ber que ela está caminhando para um atraso

OS MITOS DA COMPRESSÃO DO CRONOGRAMA

Simplesmente pelo fato de as técnicas de compressão de cronograma existirem não significa que elas vão funcionar.

CT’ Tradução oficial, de acordo com o glossário da quarta edição

Existem cinco técnicas comuns de compressão de cronograma e cada técnica tem limitações importantes que podem torná-la mais um mito do que realidade. Isso é mostrado na Tabela 12-3.

do Guia PMBOK*, em que o termo equivalente em inglês é Lead. Em citação ao glossário, a definição de antecipação é:

“Uma modificação dc um relacionamento lógico que permite uma antecipação da atividade sucessora."

14

GREY, Stephen. Practical risk assessment for project manage­ ment. West Sussex, England: Wiley, 1995. p. 108-109.

402

Gerenciamento de Projetos

TABELA 12-3 Mitos e verdades sobre a compressão do

cronograma

Técnico de Compressõo liizoçõo de h:«s erfrcs

Mio

Verdade

0 tnbofco segura no

0 itnodo proçesso é mera nas

nesrrc rir: ras hotes

hons eifcs; podem a ara mois

ertas.

mos, horas erfrm

pricqjodcs

p:den conduÁ m esgactrento.

Wiça»dt“reisieatnos

0 r tiro de efeserrperfo

lew tempo poro encorta

(ou sep, compeessõol

Ourratara po' causo dos

reusos: lew tempo pora que

e.its:s ^loocüdos

eés ernem ro rirmo; as tK-rsos ulLodes poro heranerto deeerr wdastetjsos asiectes.

hdu'ocdeevopo (ou

0 dente sanpee sdrito

0(lfntep«Mdetofcscstmfcs

sep. neressitede de

ra trcbdho do Q>e:

oedafas -a dabaoo dc trido.

redjçõo de furconctode;

eo'me'fe necessóno

A qujtafcde do r:tohc dos T«cenzoçôo

íxftler »ács

foreceáxes pode p«eudeor a suo

fcxraedoes g^ifucdos

ftp-ttõo. o fornecedor pode soí

do regáo, e o fcrecedor pode derronsínr poao iletesse p?bs seus pesos proparrodos

Redcoçoo tfc wotolbo em

Umo afrdodt pode meet

Os tscos amertotr e o itfrtíofro

sete etr paoék

antes que flUMdode

se torro tao. poc pode enrote

cnlerax tenha lermraio

m Aptos atríhdes

• Capacidades de gerenciamento de dados e de in­ formação de relatórios • /Xnálise do caminho crítico • Formatos de relatórios padronizados e específicos • Rastreamento de vários projetos • Elaboração de sub-redes • Análise de impacto (e se...) • Sistemas de alerta rápido • Análise on-line de alternativas de recuperação • Representação gráfica de dados de custos, tempo e de atividades • Planejamento e análise de recursos • Análise de custos, análise da variação • Calendários múltiplos • Nivelamento de recursos

Além disso, muitos dos pacotes de software mais sofisticados já estão disponíveis para computadores pes­ soais e utilizam principalmente as redes de precedência. Isso proporciona às grandes e pequenas empresas muitas vantagens que vão desde a interação real do usuário ao pronto acesso e disponibilidade, a interfaces mais sim­ ples e amigáveis e a custos de software consideravelmente menores. 12.17

CARACTERÍSTICAS DE SOFTWARE

OFERECIDAS

12.16 ENTENDIMENTO DO SOFTWARE DE GERENCIAMENTO DE PROJETOS

O gerenciamento de proje­ tos eficiente exige mais do 6.4.2.S Software de que um bom planejamen­ gerenciamento de projetos to, exige que informações relevantes sejam obtidas, analisadas e revisadas de for­ ma oportuna. Isso pode fornecer um alerta antecipado de problemas pendentes e avaliações de impacto sobre outras atividades, o que pode levar a planos alternativos e ações de gestão. Hoje, os gerentes de projetos têm um grande conjunto de software disponível, capaz de ajudar na difícil tarefa de rastreamento e controle de projetos. Embora seja claro que mesmo os pacotes de software mais sofisticados não são um substituto para a liderança competente do projeto - e que por si só não identificam ou corrigem quaisquer problemas relacionados com a ta­ refa -, podem ser uma ajuda fantástica para o gerente de projetos no rastreamento das muitas variáveis e tarefas in ter-rei acionadas que entram em jogo em um projeto. Exemplos específicos dessas capacidades são: Guio PMBOK , 5. ed.

• Resumo de dados do projeto: despesas, acompa­ nhamento do tempo e atividade • Capacidades de gerenciamento de projetos e gráfi­ cos de negócio

As capacidades e as características do software de ge­ renciamento de projetos variam bastante. No entanto, a variação é mais na profundidade e sofisticação das ca­ racterísticas, como armazenamento, disposição, análise, interoperabilidade e facilidade de uso, em vez de no tipo de recursos oferecidos, os quais são muito semelhantes para a maioria dos programas de software. A maioria dos pacotes de software de gerenciamento de projetos oferece as seguintes características: 1. Planejamento, rastreamento e monitoramen­ to. Essas características possibilitam o planeja­ mento e rastreamento das atividades, recursos e custos dos projetos. O formato de dados para a descrição do projeto para o computador é ge­ ralmente baseado em tipologias padronizadas de rede, como o Método do Caminho Crítico (CPM), Técnica de Avaliação e Revisão de Pro­ grama (PERT) ou o Método do Diagrama de Precedência (PDM). Os elementos de tarefas, com seus tempos estimados de início e término, seus recursos designados e dados reais de cus­ tos, podem ser inseridos e atualizados no decor­ rer do projeto. O software fornece uma análise dos dados e documenta o andamento técnico e financeiro do projeto em comparação com o seu cronograma e com o plano original. Normal-

403

TÉCNICAS DE PROGRAMAÇÃO DE REDE

mente, o software também fornece avaliações de impacto dos desvios ao plano e projeções de re­ cursos e cronograma. Muitos sistemas também fornecem o nivelamento de recursos, uma carac­ terística que calcula a média dos recursos dispo­ níveis para determinar a duração da tarefa e gera um cronograma nivelado para comparação. 2. Relatórios. Os relatórios do projeto geralmente são obtidos por meio de um sistema gerador de relatórios orientado por um menu que permite ao usuário solicitar diversos relatórios-padrão em um formato-padrão. O usuário também pode modificar esses relatórios ou criar relató­ rios novos. Dependendo da sofisticação do sis­ tema e de seus equipamentos periféricos, esses relatórios são apoiados por uma gama completa de gráficos de Gantt, diagramas de rede, resumos tabulares e gráficos de negócio. As capacidades de informação de relatórios incluem: • Custo orçado para o tra­ Guio PMBOK , 5. ed. balho agendado (BCWS) 7.3.2 Controhr os custos: ou valor planejado do ferramentas e técnicas trabalho (PV) • Custo orçado para o trabalho realizado (BCWP) ou valor agregado do trabalho (EV) • Despesas reais versus planejadas • Análise de valor agregado • índices de desempenho de custos e de prazos • Fluxo de caixa • Análise do caminho crítico • Pedido de mudança • Relatórios governamentais padronizados (De­ partamento de Defesa, Departamento de Ener­ gia, NASA), formatados para o sistema de moni­ toramento de desempenho (PMS)NW Além disso, muitos pacotes de software possuem um gerador de relatórios orientado ao usuário, com formato livre para relatórios de projeto sob medida. 3. Calendário do projeto. Permite ao usuário esta­ belecer semanas de trabalho com base nos dias úteis reais. Assim, o usuário pode especificar pe­ ríodos sem trabalho, tais como finais de semana, feriados e férias. O calendário do projeto pode ser impresso em formato detalhado ou resumido e é automaticamente a base para toda a progra­ mação de recursos assistida por computador. 4. Análise e-se. Alguns softwares sào projetados para simplificar a análise e-se. É estabelecido um banco de dados duplicado do projeto e as mudanças desejadas são inseridas. Então, o software realiza uma análise comparativa e apre-

senta o novo plano do projeto, em comparação ao antigo, na forma tabular ou gráfica para uma rápida e fácil análise e revisão da gerência. 5. Análise de vários projetos. Alguns dos softwares mais sofisticados possuem um banco de dados único e abrangente que facilita a análise cruzada dos projetos e dos relatórios. Módulos de custos e cronograma compartilham arquivos comuns que permitem a integração entre os projetos e minimizam os problemas de inconsistências de dados e redundâncias. 12.18

CLASSIFICAÇÃO DE SOFTWARE

Para fins de uma fácil classificação, os produtos de soft­ ware de gerenciamento de projetos foram divididos em três categorias com base no tipo de funções e característi­ cas que eles fornecem.1' Softwares de nível I. Projetados para o planejamento de um único projeto, esses pacotes de software são sim­ ples, fáceis de usar e suas saídas são fáceis de entender. Eles preveem, no entanto, apenas uma análise limitada dos dados. Eles nào fornecem um reagendamento auto­ mático baseado nas alterações específicas. Portanto, os desvios do plano do projeto original exigem um replanejamento completo do projeto e uma entrada completa de novos dados no computador. Softwares de nível II. Projetados para gerenciamento de projetos individuais, esses pacotes de software auxiliam os líderes de projeto no planejamento, rastreamento e re­ latórios de projetos. Eles fomecem uma análise detalhada do projeto, relatórios de progresso e revisões no plano, com base no desempenho real. Esse tipo de software é projetado para gerenciar projetos além do estágio de planejamento e para fornecer controle semiautomático do projeto. Softwares de nível III. Esses pacotes apresentam o planejamento, o monitoramento e o controle de múlti­ plos projetos, utilizando um banco de dados comum e um software sofisticado de informação de relatórios e monitoramento através dos projetos.

A maioria dos pacotes de software em níveis II e III tem as seguintes capacidades extensivas para o monitora­ mento e controle dos projetos: 1. Capacidade do sistema. O número de ativida­ des e/ou número de sub-redes que podem ser utilizadas.

’’

Alguns padrões foram inicialmente estabelecidos pela revista PC Magazine, Project Management with the PC, v. 3, n. 24,11

KTS Na expressão em inglês. Performance Monitoring System (PMS).

dez. 1984.

404

Gerenciamento de Projetos 2.

3.

4.

5.

6.

7.

8.

9.

10.

11. 12.

13.

12.19

Desenhos de rede. São o relacionamento e/ou o diagrama de atividade (AD) e/ou a relação de precedência (PRE). Datas dc calendário. Um calendário interno fica disponível para programar as atividades do pro­ jeto. As variações e opções de diferentes algorit­ mos de calendário são numerosas. Gráficos dc barras ou Gantt. Está disponível uma exibição gráfica do resultado da produção em uma escala de tempo, se desejado. Gerador de relatório flexível. O usuário pode especificar os formatos de saída, dentro das di­ retrizes definidas. Atualização. O programa aceitará estimativas revisadas de tempo e datas de conclusão e irá re­ calcular o cronograma revisado. Controle dc custos. O programa aceita valores de custos orçados para cada atividade e, em se­ guida, o custo real incorrido, e resume os valores orçados em reais em cada atualização executada. O objetivo principal é ajudar a gerência a produ­ zir um plano de custos realista, antes que o pro­ jeto seja iniciado, e auxiliar no controle das des­ pesas do projeto, conforme o trabalho progride. Datas agendadas. Uma data é especificada para a realização de qualquer uma das atividades para fins dc planejamento e controle. Os cálculos são realizados com essas datas como restrições. Ordenação. O programa lista as atividades em uma sequência especificada pelo usuário. Alocação dc recursos. O programa tenta alocar recursos dc forma ideal por meio da utilização dc um dos muitos algoritmos heurísticos. Disponibilidade do plotter. Um plotter fica dis­ ponível para imprimir o diagrama de rede. Requisitos de máquina. São os requisitos míni­ mos de memória dc hardware para o programa (em unidades dc bytes). Custo. Indica se o programa é vendido e/ou alugado e o preço de compra e/ou da locação (quando disponível). PROBLEMAS DE IMPLEMENTAÇÃO

De modo geral, os pacotes de software de mainframe são mais difíceis de implementar do que pacotes meno­ res, porque todos são solicitados a usar o mesmo pacote, talvez até mesmo da mesma forma. A seguir estão dificul­ dades comuns durante a implementação: • A alta administração pode não gostar da realidade do resultado. O resultado normalmente mostra à alta administração que são necessários mais tem­

•

•

•

•

•

•

•

•

•

po e recursos do que previsto originalmente. Isso também pode ser uma nota positiva para o gerente do projeto, que é forçado a lidar com severas res­ trições de recursos. A alta administração pode não usar os pacotes para planejamento, orçamentação e tomada de decisões. O pessoal da alta administração, em ge­ ral, prefere os métodos mais tradicionais ou sim­ plesmente se recusa a olhar a realidade por cau­ sas políticas. Como resultado, os planos que eles enviaram para a diretoria são baseados em uma abordagem de agradar aos olhos, visando uma rá­ pida aceitação, em vez de baseados na realidade. Os planejadores de projetos do dia a dia podem não utilizar os pacotes para os seus próprios pro­ jetos. Os gerentes de projetos frequentemente con­ fiam em outros métodos e ferramentas de plane­ jamento de designações anteriores. Eles confiam muito em instinto e em tentativa e erro. A alta administração pode não demonstrar o apoio e comprometimento para treinamento. O treinamento contínuo e personalizado é obrigató­ rio para a implementação bem-sucedida, embora cada projeto possa variar. O uso de software de mainframe demanda fortes linhas de comunicação internas para o apoio. Os gerentes que compartilham recursos devem con­ versar uns com os outros continuamente. Relatórios claros e concisos estão ausentes. Gran­ des pacotes de mainframe podem gerar volumes de dados, mesmo se os pacotes possuírem um pa­ cote de gerador de relatórios. Os pacotes de mainframe nem sempre fornecem o cruzamento imediato das informações. Esse é frequentemente o resultado de não entender como utilizar os novos sistemas. A entidade empresarial pode não ter qualquer pa­ drão de gerenciamento de projetos em vigor antes da implementação. Isso se refere à falta de esque­ mas de numeração da EAP, ausência de fases no ciclo de vida e uma má compreensão das depen­ dências entre as tarefas. A implementação pode destacar a inexperiência da média gerencia no planejamento dc projetos e em competências organizacionais. O medo de seu uso é um fator-chave para a não obtenção de apoio adequado. O ambiente de negócios e a estrutura organiza­ cional podem não ser adequados para atender as necessidades de gerenciamento de projetos/planejamento. Se existe compartilhamento extensivo dos

405

TÉCNICAS DE PROGRAMAÇÃO DE REDE

recursos, então, a estrutura organizacional deve ser uma matriz formal ou informal Se a organização está profundamente enraizada em uma estrutura tradicional, então, há uma incompatibilidade organi­ zacional e o sistema de software pode não ser aceito.

• A condução de cada projeto até a sua conclusão de forma mais rápida • Um afundamento de mais projetos pela organiza­ ção, sem adição de recursos

• São necessários recursos vastos/suficientes (pes­ soal, equipamentos etc.). Grandes pacotes de mainframe consomem uma quantidade significa­ tiva de recursos na fase de execução.

A Corrente Crítica é uma metodologia de gerencia­ mento de projetos destinada a resolver as duas últimas me­ tas. Ela é baseada em uma metodologia de melhoria geral chamada de Teoria das Restrições, que aborda a primeira meta executiva - escolha dos melhores projetos. A escolha dos melhores projetos faz parte do planejamento estraté­ gico, que é discutido em profundidade em outros livros. ’

• A entidade empresarial deve determinar a exten­ são e o uso adequado dos sistemas dentro da orga­ nização. Eles devem ser usados por todas as orga­ nizações? Devem ser utilizados apenas em projetos de alta prioridade? • O sistema pode ser visto como um substituto para as várias habilidades interpessoais demandadas pelo gerente de projetos. Os sistemas de software não substituem a necessidade de gerentes de projetos com fortes habilidades de comunicações e negociação. • A implementação do software tem menor proba­ bilidade de êxito se a organização não tiver treina­ mento suficiente nos princípios de gerenciamento dc projetos. Essa barreira ê talvez o problema sub­ jacente a todas as outras barreiras. 12.20

CORRENTE CRÍTICA

A seleção e a conclusão dc projetos suficientes para me­ 6.6.2.3 Desenvolver o cronogranu - método da lhorar a organização são, corrente critica muitas vezes, uma questão dc sobrevivência para os executivos. Veja a estatística da empresa dc terceirização Drake, Beam, Morin, afirmando que 57% das 367 grandes empresas pesquisadas substi­ tuíram seus CEOs nos últimos três anos.*17 Os executi­ vos usam os projetos como principal meio para atingir suas metas. Portanto, podemos supor que muitos desses executivos foram incapazes de concluir projetos suficien­ tes de forma bem-sucedida, em um período de tempo de medição para manterem seus empregos. Gtih PMBOK , 5. ed.

Na tentativa de atingir suas metas, os executivos fre­ quentemente descrevem três grandes desafios cm geren­ ciamento de projetos:

Conforme os executivos tentam deliberar novos projetos na organização, frequentemente ouvem recla­ mações de que as pessoas estão sobrecarregadas. Inevi­ tavelmente, eles enfrentam um conflito entre a transfe­ rência de recursos para o novo projeto e a permissão para os recursos continuarem trabalhando nos projetos em vigor. As pessoas na organização também podem instar o executivo a adiar o início do novo projeto, enquanto ele se sente obrigado a seguir em frente. A maioria dos executivos aceita esse conflito como um fato da vida. Eles acreditam que seu papel é pressio­ nar as pessoas o máximo que puderem para desempenha­ rem em padrões elevados. Como resultado, a reação de muitos executivos para o conflito de recursos é a de exigir que os projetos existentes sejam concluídos mais cedo, de modo que os seus novos projetos possam começar mais cedo. Essas exigências deixam os gerentes de projetos com um conflito próprio enorme. A fim de concluir um proje­ to mais cedo, a maioria dos gerentes de projetos acha que é forçada a reduzir o escopo ou qualidade, ou adicionar recursos, o que vai ultrapassar o orçamento. Nenhuma dessas alternativas é aceitável para os executivos. O comportamento resultante, que agora é prevalente em muitas organizações, é o assunto para uma nova abor­ dagem chamada Gerenciamento de Projetos por Corrente Crítica (CCPM)HT’. Quando os gerentes de projetos e de recursos não conseguem convencer os executivos a atra­ sar o início de um novo projeto, eles muitas vezes tomam três ações que levam a muitos outros efeitos negativos:

• Muhitarefas de recursos • Trabalhar para reduzir as estimativas de tarefas • Gerenciar as pessoas muito de perto para garantir que elas cumpram as suas datas devidas

• A escolha dos projetos certos dentre um grande conjunto de projetos

*•

Autor da Seção: Gerald 1. Kendall, PMP, Diretor, TOC Inter­ national, www.tocinternational.com, e-mail

Gerrykendallí'

cs.com, 850-939-9006. 17

Scandals, Setbacks Topple CEOs Formerly Golden Image. USA Today, p. Bl, 8 abr. 2002.

'•

Ver: KENDALL, Gerald 1. Viable vision. Boca Raton, FL J. Ross Publishing, 2004.

K,v Na expressão em inglês, Critical Chain Project Management (CCPM).

406

Gerenciamento de Projetos

Uma vez que os executivos são uma parte impor­ tante do sistema de projetos dentro das organizações, a Corrente Crítica reconhece que os executivos são parte do problema. Para resolver o problema e ter um grande impacto nos resultados do projeto, os executivos devem, portanto, ser parte da solução. A solução da Corrente Crítica para a programação e o gerenciamento de projetos foi derivada de uma meto­ dologia chamada de Teoria das Restrições. O Dr. Eliyahu M. Goldratt é o indivíduo mais frequentemente creditado pela criação e aprimoramento dessa metodologia ao lon­ go dos últimos 25 anos. Para obter a solução da Corrente Crítica, Goldratt aplicou os cinco passos de focalização, identificados em seus textos.19 Esses passos são:

1. 2. 3. 4. 5.

Identificar a restrição do sistema. Decidir como explorar a restrição. Submeter todo o resto à decisão acima. Elevar a restrição do sistema. Se, em um passo anterior, a restrição do sistema for quebrada, voltar para o passo 1.

Dentro de qualquer projeto, a Corrente Crítica é de­ finida como a maior cadeia de eventos dependentes onde a dependência está relacionada ou a tarefas ou a recursos. Essa definição pressupõe que a corrente mais longa é a que tem maior probabilidade de impactar negativamen­ te a duração total do projeto. A Corrente Crítica não é necessariamente equivalente à duração do projeto, dado que, algumas vezes, existem tarefas não críticas que come­ çam antes da Corrente Crítica.

A solução da Corrente Crítica reconhece a Corren­ te Crítica como o ponto de alavancagem para a redução da duração do projeto. O primeiro passo de focalização, identificar, reconhece que os gerentes colocam práticas em jogo que bloqueiam a redução da Corrente Crítica. Os passos explorar e subordinar implementam mudan­ ças para condensar a corrente crítica (em outras palavras, para encurtar a quantidade de tempo que leva para con­ cluir um projeto). A Corrente Crítica implementa importantes mu­ danças comportamentais nos gerentes de projetos, geren­ tes de recursos, membros da equipe e executivos. A única maneira de tantas pessoas em uma organização poderem aceitar tais mudanças fundamentais é por meio de uma profunda compreensão dos comportamentos atuais, dos novos comportamentos necessários e dos benefícios. Isso é normalmente realizado por meio da educação de executivos, gerentes de projetos, gerentes de recursos e

”

GOLDRATT, Eliyahu M. Theory ofconstraints. Croton-on-I ludson, NY: North River Press, 1990.

membros da equipe, seguido por mudanças políticas e de medição. Essas mudanças incluem:

• Um fim à prática de medir as pessoas de alguma forma pela exatidão das suas estimativas. • Um fim à prática de medir as pessoas quanto ao cumprimento das datas devidas para tarefas indi­ viduais do projeto. • Uma substituição das duas práticas anteriores pela “ética de trabalho da corrida de revezamento”, ex­ plicada mais adiante neste capítulo. • Um sistema, acordado por todos os executivos e gerentes seniores, de autorização para que novos projetos comecem apenas quando um “recurso es­ tratégico” estiver disponível. • O reconhecimento da necessidade de proteger es­ trategicamente projetos das variações de tempo das tarefas, utilizando pulmões devidamente colo­ cados. Isso se encaixa na filosofia de W. Edwards Deming, o advogado de grande qualidade, sobre a manipulação da variação e da previsibilidade da “causa comum” e da “causa especial". • A redução significativa da prática de multitarefas, por meio do avanço de trabalho dedicado nas ta­ refas de projeto. • A implementação de software multiprojetos, com os dados realmente sendo usado por executivos, gerentes de recursos e gerentes de projetos. Os re­ latórios da Corrente Crítica um quadro comum e preciso dos projetos da organização e uma manei­ ra sistemática e lógica para gerenciar as variações. • A implementação do gerenciamento dos pulmões como um importante processo executivo e de ge­ renciamento para a identificação de problemas do projeto durante a execução. A implementação bem-sucedida da Corrente Crítica tem resultado em melhorias significativas nas organiza­ ções, cujos exemplos estão documentados nos estudos de caso neste Capítulo. A fim de compreender a magnitude da mudança cultural e dos problemas a serem superados, esta Seção explica os fundamentos da abordagem da Cor­ rente Crítica, tanto nos ambientes individuais dos proje­ tos quanto por toda a organização. 12.21 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 de Tempo • Planejamento • Controle

407

TÉCNICAS DE PROGRAMAÇÃO DE REDE

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 os três tipos de técnicas de progra­ mação e suas respectivas vantagens e desvantagens • A diferença entre redes de atividade-na-seta e re­ des de atividade-no-nó • Os quatro tipos de redes de precedência • Terminologia básica de rede, tal como atividades, eventos, caminho critico e folga (slack ou float) • A diferença entre folgas positivas e negativas • Técnicas de compressão de cronograma, como compressão e paralelismo (engenharia simultânea) • Importância da estrutura analítica do projeto no desenvolvimento da rede • Os passos, e sua ordem, para o desenvolvimento de uma rede • Os três tipos de dependências • Como é possível executar um caminho de ida e um caminho de volta • Nivelamento de recursos • Planejamento de recursos limitados • Diferença entre esforço e duração • Qual técnica de rede utiliza estimativas otimista, mais provável e pessimista • Uso de atividades fantasmas • Espera • Diferença entre o planejamento/programação de recursos ilimitados versus limitados As seguintes questões de múltipla escolha ajudarão na revisão dos conceitos deste capítulo:

1.

2.

3.

O menor tempo necessário para concluir todas as atividades cm uma rede é chamado dc: a. Extensão dc duração das atividades b. Caminho critico c. Caminho dc folga máxima d. Caminho dc compressão Qual dos itens seguintes nào pode ser identificado após a realização de um caminho de ida e de um caminho de volta? a. Atividades fantasma b. Tempo de folga c. Atividades do caminho crítico d. Quantas horas extras foram planejadas Qual das seguintes não é uma técnica comumente usada para a compressão dc cronograma? a. Redução de recursos b. Redução de escopo c. Atividades paralelas d. Uso de horas extras

Um cronograma baseado cm rede tem quatro cami­ nhos, ou seja, 7,8,9 e 10 semanas. Se o caminho de 10 semanas for comprimido para 8 semanas, então: a. Agora temos dois caminhos críticos. b. O caminho dc 9 semanas agora c o caminho crítico. c. Somente o caminho de 7 semanas possui folga. d. Não há informação suficiente fornecida para fa­ zer uma determinação. 5. A principal desvantagem do uso de gráficos de bar­ ras para gerenciar um projeto é que os gráficos de barras: a. Não mostram as dependências entre as atividades b. São ineficazes para projetos com menos de um ano de duração c. Sào ineficazes para projetos de menos de $ 1 milhão d. Nào identificam as datas de início e término de um cronograma 6. O primeiro passo no desenvolvimento de um cro­ nograma é um(a): a. Listagem das atividades b. Determinação de dependências c. Cálculo de esforços d. Cálculo das durações 7. A redução dc altos c baixos nas designações dc pes­ soal, a fim dc obter uma curva rclativamente suave de mão dc obra, chama-se: a. Alocação dc mão dc obra b. Nivelamento dc mão dc obra c. Alocação dc recursos d. Planejamento dc comprometimento dc recursos 8. Atividades sem tempo dc duração sào chamadas: a. Atividades reserva b. Atividades fantasma c. Atividades com folga zero d. Atividades dc supervisão 9. Prazos otimistas, pessimistas c mais prováveis dc uma atividade estão associadas com: a. PERT b. GERI c. PDM d. ADM 10. O relacionamento ou “restrição” mais comum cm uma rede de precedência é: a. Início-para-início b. Início-para-Término c. Término-para-Início d. Término-para-Término 11. Uma técnica baseada cm rede que permite a rami­ ficação c o looping é: a. PERT b. GERT c. PDM d. ADM

4.

408

Gerenciamento de Projetos 12. Sc uma atividade no caminho crítico leva mais tempo do que o previsto, então: a. As atividades que não estão no caminho crítico possuem folga adicional b. As atividades que não estão no caminho crítico possuem menos folga c. Aparecerão atividades adicionais no caminho crítico d. Nenhuma das anteriores 13. Qual das seguintes não é um dos três tipos de dependências? a. Obrigatórias b. Arbitradas c. Internas d. Externas 14. Você tem uma atividade em que o início mais cedo é na semana 6, o término mais cedo é na se­ mana 10, o início mais tarde é na semana 14, e o término mais tarde é na semana 18. A folga desta atividade é: a. 4 semanas b. 6 semanas c. 8 semanas d. 18 semanas

RESPOSTAS I.B

2D

12. A

4D

3.A

13. C

5A

6A 7.B

8B

9.A

10. C

II. B

14. C

EXERCÍCIOS 12-1

12-2

12-3 12 4

12-5

12-6 12-7

12-8

12-9

Uma rede PERT/CPM deveria se tornar um meio de compreensão de relatórios e cronogra­ mas, ou deveria ser o contrário? Antes de os diagramas PERT serem elaborados, a pessoa que executa o trabalho deve ter uma clara definição dos requisitos e objetivos, tanto principais quanto de apoio? Isso é uma necessi­ dade absoluta? Quem elabora os diagramas PERT? Quem é res­ ponsável pela integração dos diagramas? As redes PERT devem seguir a estrutura analíti­ ca do projeto? Como uma rede PERT pode ser utilizada para aumentar a capacidade funcional de se relacio­ nar com o programa total? Quais problemas estão relacionados com a apli­ cação de PERT em programas pequenos? O desenho da rede PERT deve ser dependente do número de elementos na estrutura analítica do projeto? Os gráficos de barras e os diagramas PERT po­ dem ser utilizados para suavizar os requisitos dc mão de obra departamental? Os marcos principais devem ser estabelecidos em pontos onde as compensações são mais pro­ váveis de ocorrer?

12-10 Você concorda ou discorda que os custos da aceleração de um projeto aumentam de forma exponencial, especialmente conforme o projeto se aproxima da conclusão? 12-11 Quais são as principais dificuldades com PERT, e como podem ser superadas? 12-12 As estimativas PERT/custos são projetadas para identificar desvios de cronograma críticos e so­ brecustos cedo o suficiente para que ações cor­ retivas possam ser tomadas? 12-13 Desenhe a rede e identifique o caminho crítico. Também calcule os prazos mais cedo e mais tar­ de de início e término para cada atividade:

Atividade

A B C D E F 6 H 1

Atividade Predecessoro

— — — A B B C D.E F.6.H

Tempo (semanas)

7 8 6 6 6 8 4 7 3

12-14 Desenhe a rede e identifique o caminho crítico. Também calcule os prazos mais cedo e mais tar­ de dc início c término para cada atividade:

Atividade

A B C 0 E F G H 1

Atividade Predecessoro — — A.B B B C D D.E F.G.H

Tempo (semanas)

4 6 7 8 5 5 7 8 4

12-15 Considere a seguinte rede para um pequeno projeto de manutenção (todos os prazos estão cm dias; a rede segue do nó 1 ao nó 7): a. Desenhe um diagrama de setas que repre­ sente o projeto. b. Qual é o caminho crítico e o tempo associado? c. Qual é o tempo de folga total na rede? d. Qual é o tempo esperado para os limites dc conclusão dc 68%, 95% e 99%? e. Se a atividade G tivesse um tempo estima­ do de 15 dias, qual impacto teria sobre a sua resposta para a parte b?

409

TÉCNICAS DE PROGRAMAÇÃO DE REDE

Arnic percebeu que o diente queria o trabalho concluído em menos lempo. Após discussões com os gerentes funcionais, Arnic desenvolveu a tabela a seguir:

Rede Atividade de Nó Nó Inicial Trabalho Final

A B c D E F G H 1 J K L

2 4 3 6 4 4 5 6 7 5 7 7

1 1 1 2 2 3 3 4 4 4 5 6

Tempo Otimista

Tempo Pessmista

Mais Provável

1 4 4 2 1 2 7 4 6 1 2 6

3 6 6 4 3 4 15 6 14 3 4 14

2 5 5 3 2 3 9 5 10 2 3 10

12-16 Identifique o caminho crítico para a rede a se­ guir para um pequeno projeto de sistema de in­ formação (todos os prazos estão em dias; a rede segue do nó 1 ao nó 10):

Rede

Atividade de Trabdho

Nó Ink id

Nó find

Tempo Eslimodo

A B C D E F 6 H 1 J K L M N 0

1 1 1 2 2 3 3 3 4 4 5 6 7 8 9

2 3 4 5 9 5 6 7 7 8 6 9 9 9 10

2 3 3 3 3 1 2 3 5 3 3 4 4 3 2

12-17 Em 1 de maio, Arnie Watson enviou um memo­ rando a seu chefe, o diretor dc gerenciamento dc projetos, afirmando que o projeto MX exigiria 13 semanas para a conclusão de acordo com a figura mostrada a seguir.

Normal Atividade lempo

A B C 0 E F

3 5 5 4 2 3

Compressão

Custos

Tempo

Custos

6.000 12.000 16.000 8.000 6.000 14.000 $62.000

2 4 3 2 1 1

8.000 13.000 22.000 10.000 7.500 20.000

Custo/Semona Adoonal (Compressão) 2.000 1.500 3.000 1.000 1.500 3.000

a. Segundo o contrato, há um pagamento de penalidade de $ 5.000 por semana para cada semana ao longo dc seis semanas. Qual c o valor mínimo de financiamento adicional que Arnie deve solicitar? b. Suponha que a sua resposta à parte A for­ neça o mesmo custo adicional mínimo tan­ to para um projeto de oito semanas quanto para um projeto dc nove semanas. Quais os fatores que você consideraria antes de se decidir sobre realizar o projeto em oito ou nove semanas? 12-18 Em Io de março, o gerente do projeto recebeu três relatórios de andamento indicando a utili­ zação dc recursos até o momento. Os três relató­ rios estào expostos abaixo, bem como o diagra­ ma PERT.

Relatório do percentual de condusõo

Tempo pao Termina

Data Inkioda

% Concluído

2/1 2/1 2/1 Nõo moda 2/14

100% 60% *1 100 — 40%

2 3 3

* Note fr xtoà OB pãtde, cs mw jrj0 dhda> S rã

ipríia tt*3/14

Atividade AB AC AD * DE BF

Aarre»:i enrc ae so ».t>t psi sa(«mtc oe ts sercrs >x ix* 'em c ji: ofcaddeSlOKi

410

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

Aívv 1 2t 3 4 5 dode — JB 2000 2.000 2000 Aí 3.000 4.000 4.000 4.000 5.000 — JD 2000 3.000 2500 BF - - - 2.000 3.000 — — — — — CE OE — — — 3.500 3500 — — — — — EF

6

7

8

TotolS

— — - 6.000 — — - 20.000 — — - 7.500 4.000 3.000 3.000 15.000 2.500 — - 2500 — 3.500 - 10.500 — 3.000 - 3.000

li li

1!

ktí 7.000 9.000 8.500 9.500 11.500 10.000 Resumo de custos

Encerramento do semana Atividade

AB Aí AD BF DE Total

Custos de Orcomento — 4.000 — 2.000 3.500 9.500

Red — 4.500 2.400 2.800 —

9.700

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 de 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 (Acima) Real Abaixo Orçamento Abaixo — 6.000 6.200 (200) (500) 15.000 12500 2.500 (2400) 7.500 7.400 100 (800) 2.000 4.500 (2.500) — 3.500 3.500 3.500 (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. ( instrua 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 oída 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

Atividade

Semanas

A-B A-C B-D B-E C-E D-F E-F

5 3 2 3 3 3 6

Pessod Necessário Tempo integral 3 3 4 5 5 5 3

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 c 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 dc folga, a fim de 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

A B C D E F G H 1 J K l M N 0 P 0 R $ T U V w X

Atividade Precedente

Tempo Normal (Semanas)

— A B.U.V.N C c c c D,E — I.R J K l M N 0 —

4 6 3 2 2 7 7 4 2 1 1 2 1 1 2 1 4 1 1 1 2 2 tr

0 — — s T — —

'Ptfmmct em toda a tbarao do popto

2

É oMtcbde de opoc adnnffictoio

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, lente 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.

Atividade A-H l-P Q-V W

X

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 de 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 atividade 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 Coda Atividade 16.960 5.160 40.960 67.200 22.940 FIGURA PI 2-25

412

Gerenciamento de Projetos TABELA 12-5 Gráfico de precedência do projeto * Semanas Atividade

A

G

1

2

3

4

5

8

9

10

II

12

13

14

15

16

17

18

19

20

21

■■■■■■■■■■■■■■■■■■■■■ ■■■■■■■■■■■■■■■■■■■■■ ■■■■■■■■■■■■■■■■■■■■■ ■■■■■■■■■■■■■■■■■■■■■

■■■■■■■■■■■■■■■■■■■■■ P

0

‘Desedie as devidas banas rc figuic, (onsidaando que (0.Msium

Ccd»y te fendes 1 ConlroX) rrçwjio 2 Corto» nsrodo

6 Aquisições de exto poro 1 Espeoftoções de irtíenos

1 (ontnto negxoto 2 Comoro assinado

6 ÀQjiúôes de curto proro 7 Especfaoçoes de retens

3 k)jsíões de teço peozo 4 CiorognnYB de tóbreo

8 Plans de produção 9 Inkofaxõo

3 Aj.isiíte de longo p-azo 4 Gomgraras de toinro

8 Hiros de p-atoçõo 9 l-rxjfreçoe

5 Listo de mclerios

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

5 listo de meterieis

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

422

Gerenciamento de Projetos

FIGURA 13-5 Gráfico de barras agrupadas para comparação de desempenho.

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. A 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 de 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. A linha da data de acompanha­

mento indica o momento em que os dados de custos/

"oro

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­

noroj

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

rwiV4

em relação ao mesmo eixo de tempo (como mostrado na

NOWS

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

nho pode ser feita. Na seção superior da Figura 13-6, é

)SRHUa0VA.\MUU

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

CUSTO MS MtíÉBAS«MS

(i$i,ooo)

(«sio.ooo:

Pfííllínw D0Í15I010U4

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.

FIGURA 13-10 Distribuiçõo do custo total do programa (gráfico de borras 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.

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 distoradas quando, na verdade, das nào sào.

1998

1999

2000

2001

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

ffiOMpO

FNMAS

PfSSOíi

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

obro.

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 normal men te 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.

Faro p«eoqueodc

Operoçõo

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.

^7 Embaque Irsei oroide

H Inspeção Retia do famo

Irspeóora irote

Arrozerorxnro pao resfriemerro

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 dc 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.

Remei

fyo de teste

1

n 1 Prà *oK-33

MoK-36

[fftóoi pee anbao *

(j Aceto;õo da G.Q.

Anazeromerto pao «urde

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

Diagramas de blocos, diagramas esquema 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.

coioíõfs o( nsn 200:

100

20 1000 80 »íÇ

FIGURA 13-16 Malriz de lesles para amostras propelentes.

de teste

Rcox

__________QAIctic de resta dos codoc

io

Imaencrrwto

1

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 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 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­ pítulo, 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 de 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 Kerzner/Projecf

Livro de Exercícios Relacionado (de Ker zner/Project Management

Guia PMBOK7 - S. ed.. Seção de Referência

Management (oie Studies, 4. ed.)

Workbook and PMP'-/CAPM- bam Study Guide, II. ed.)

para o Exome de Certificação PMP

• Capitol Industries

• The Automoble Problem

• Gerenciamento da Integração do Projeto

• PoF/píoducts Incorporated

• lifeCycle Casting

• Gerenciamento do Escopo do Projeto

• Small Project Cost Estimating ot Percy Ccmpony

• Multiple Choice From

• Gerenciamento das Castos do Projeto

• Cory Electric

• Camden Construction Corporation • Paytcn Ccrpcrohon • The Estimating Problem’

14.0

INTRODUÇÃO

Gim as complexidades en­ volvidas, não é de estranhar 6.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 cliente 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 poderiam 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 PRECIFKAÇÃ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 ponto, 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 II: Aquisição de Tipo I: Novo programo com potencial pao grande negócio posterior ou representando uma penetração desejada

Programa único com pouco ou nenhum negocio posterior em novos mercados Conceber o into de base proposto pao o projeto/progromo adequado oos requisitas do cberíe, com

1.

Desenvolvei o modeb de custos e as ãretnzes de estimotrras, coracteristKOS adieionas, nus com riscos mínrnos.

ccrceber o into de base pao custos mínimos pora o projeto/

programo proposto, pora um mínimo de requisitos do (lente.

2. 3.

Estima os custos reoEnccmente pora um mínmc de reqjisitos.

Estima os custos de formo reafrsto limpa o into de bose. Retia os custos desnecessários.

Detanina custos mínimos redistos. Obter o comprometimento das agonizoções executoras.

Limpa a Inta de base. Retirar custos desnecessárias. Detanina estimativas exequwts incluindo qustes de riscos. Determna custos mínimos redistos. Obter o comprometimento

das orgcnizocoes executa®. Ajusta o esfimatrm de custos oos riscos.

6. 7.

2. 3.

Aóacnor magens desejados. Definir o preço. Comporá o preço ao açomenlo do dente òs informações de

6. 7. 8. 9.

Compaa sua estmoirra total de custa oo orçamento do ciente e oo preço mais provável de vrtoria.

Detanina o morgem buto de lucro recessão poro vencer a proposto. Esso morgem pede ser negotw! Decidir se o mugem bruto é ocertovel de ocordo com o efesqo de realzoçõo otrigotoria.

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 abaixo do custo, muitos vezes é necessário fornece uno explicação oo diente

cistos do concarêncb.

8.

sebre de onde vrá financiamento odkbncl. A fonte pode sa os lucros da empresa ou o ccmpartiíamaita de

Ofertar operas se o preço estiver dentro do faixo competitivo. otnrdocfes rekxcnodos. Em quolqua coso, um quodra cloro dos recuses deve ser fanecido oo diente 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.

TABELA 14-2 Padrão para estimativas de projetos

Método de Estinativo

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étri­ cas é 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

Tipo Genérico

Relacionamento como EAP

Exatidão

Tempo paro Elaborar

Poromélnco ROM’ Topdov/n -25%o+75fr Dias Ardogio Topdov/n Orçamento -l(ho+25% Semanas Engaihcno DdiiitM) Bottcmup Meses (base) ■5%od5% ■ROM = Rough Ord«d Atogriufe. Em ttdjçõo Iteicl. 'Oder d» goràzo cprosmodf

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.

“T *

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

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

Intíodxõo Propósitos e tipos de estimativas ftrácprô

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

1

II

III

IV

V

VI

1. Consulta

X

X

X

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. Pocotes de subcontrao

X

X

/.listagem

X

X

X

X

8. Visita kxd

X

X

X

X

9. Estima o moia pane

X

X

X

X

X

10. Taxas de mõo de obro

X

X

X

X

X

11. Equipamentos e seiecõc

X

X

X

X

X

12. Impostos, seguros e duetos outorors

X

X

X

X

X

13. Custos com escritório central

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 eqwpanentos

X

17. Fofa de resumo

X

X

X

X

X

18. Avoloçõo do administração

X

X

X

X

X

X

19. Custo final

X

X

X

X

X

X

20. Aprovação do oánnstracòo

X

X

X

X

X

X

21. Estimdw computadonzcdo

X

X

X

X

(lasses de Estimativas

Ferramentas de Estimativas

Custas de equipamentos catalogados

Sistema automatizado de dadas de investimento Sistema autcmaí zodo de estimatr.as Métodos e procedimentos computadorizados

Classes de Esimcfws Estimatrvo definitiva Estimotivo de custo de capitel

X

Estimatrra de apropnoçõc Estimotivo de viabilidade

Ordem de grandeza

X

Gráfica - quantidade de especifxrçoes do estimotivo e dretrizes poro o definição de preços.

DcddS liÊíeSSGfUK Gráfico - Ccmporoçõo dos dodos necessários pao o elobcaxôo dos dosses de estimaws

Espeafaoçòes à) Apresentarão Procedmento de estmoti.os - geral

de siixontratos

Procedmento de estmohvos do estimotivo definitivo Procedrnento de estwolrvos pao estimotivo de custo de capital Procedimento de estrnoti.os pao estimotivo de oprcpccóo

Procedmento de estmon.os pao estimotivo de nobibdode

Os manuais de estimativas, como o nome indica, fornecem estimativas. A 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

Tipos

Exatidão

1

OefiíitMj

1

Custe de copitd

±10%15%

III

Aprcpnoçòo (com olgim custo de capital)

±15%20%

IV

AptCptlOCOO

±20%25%

V

WoNidode

±25%35%

VI

Ordem de grerdezo

>±35%

•5'.

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 dc 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 ■a

III

IV___ _V_ VI

X X X

X X X

X X X

X X X

X X X

X X X

X X X

X X X

Geral Produto

Descnçoo do processo

Ccpcódcde

Loccfizoçõo — getoi Locofizoçõo — esperifao Critérios básicos de

design design

Espaificocòes gerais de

X X X X

X X X X

Processo

X

Diogromo do fluxo de bloqueio do processo Diogromo do fluxo do processo

(com tomanto e material do equpcmentc) Tubulações e nstnjmaitaõo mecânicos

Lista de equipamentos Catofcodor/especíicoções qumicas

X X X

X X X

X X X

X X X X X X X

X X X X X X X

X X X X X X X

X

X

X X

X X

Ltxcl Condições à) solo

Apor emento do bed Dadas geológicos e meteorológicos Estradas, poámerloção e pasogrsmc

Proteção do pepriedode

Acessòitóode oo locd Frete e condições de entrego

X

X

Os custos mas importantes sõo ccntcbilizodcs

X

Pnndpos bjurpanentos X

X

X

X

X X

X X

X X X X X

X X X X X X X

X X X

X

X

X

X

X X

X X

X X X X

X X X X

X

X

X

X

X

X

X

X

tamanhos e motenas prebnmores

tamanhos, motenors e pertences firolizodos

X

X

X

Oucnf/dode de Mcletid Avulso

X

Qucntibcoçoc de desenhos frdzodos

Qucntificoçoc de desenhos pelminares

X

íngentena Here terreno e elevar óes

X

Fncomnhomailo de diagramas

bdice de Unho de tubdoção Unho elétnco único Ptcíeçõo contra incêndios Srstemas de esgoto

Series profrssjcnors - estimativa detdhodo Services profrssiorois - estimativa racionado

Ojortifafa de catofcafcres/prcdutus (jmikos

(onStMGO Remuneração da mão de obro, alimentação e

bebidas, colcdos de viagens

Produtividade do trabalho e práticas da área Here detdhecfo de execução de construção Compos indvetos — estimei ivo detolhedo

Compos indretos - eslimativo rocKcodo

Goncgronc lempo totd de execução Crcnoçrama de execuçtE detalhado

Cronograma de eleboroçõe de estimativas

X X

X X

X X

X

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. A estrutura analítica do projeto e os cronogramas das atividades são precificados pelas menores unidades de prccificaçã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 precificadas 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.

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 prccificaçã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-prima-s 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. H«ciq.c Lnard

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

433

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 de 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

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.

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 overhead, e não em mão de obra direta e, portanto, seus salários não são incluídos FIGURA 14-2 Fluxo Fundonol do precificaçào.

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 • PROJETO1 (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. ME5B APÓS A AUTORIZAÇÃO

**

**

Cortotedeengertai

**

—

■ — 1= —9 =

SEMANAS APÓS OBOCOFF DA PROPOSTA

1

2

3

4

5

6

7

8

9

12

1

«modos pecs

urdodes Er«xas


Business Intelligence (BI) pode ser traduzido como inteligência

de negócios, ou inteligência empresarial. 11

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 SI 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 Sl. 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ÁFICOS

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 marketing/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. -S 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 = $ 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 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 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.

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

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 dc gerenciamento d. A conta de custos do gerenciamento da con­ figuração

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 = $ 10.000 e o IDC - 1,2, então o custo que falta para concluir o projeto é: a. $ 10.000 b. $ 12.000 c. $ 14.000 d. Não pode ser determinado

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 de 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

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 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 RESPOSTAS

I. B 2.B 3. B 4. B 5.C 6. A 7. D 8.C 9. C 10. C II. A 12 B 13.C I4.A 15.B 16.0 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

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. Iodas as anteriores

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. Ealta 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 e desvios nos custos. Expli­ que como esses problemas podem ser 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 cliente? E para o relatório interno? E para o relatório para a alta administração? 15-5 Qual impacto haveria 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 e desvantagens dessa abordagem? 15-7 Karl decidiu manter uma reserva de gerencia­ mento cm um projeto de 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 dc 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 exalamente 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 c quais sào mais ou menos úteis.

TABELA 15-16 Planejamento, controle e direção do projeto

uni PARA pl, ■ t r n1 n Rdoci onomentos nonejamemo Lonnoic uiictoo Intcrfocc Fenomento Organogrames do propto

Estrutura onaifKO do projeto

Descnções dos tarefas

Pocotes de trobolho Orçamento do projeto

Pleno dc projeto Grcfaos/cforcgrcmos Reiotónos de progresso Reuniões de avokxõo

Orneis ou menos úti •muito úti

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 c trace a ENT como uma função de tempo. Quais são as suas conclusões? Custo Cumulativo (em míhares)

Semana 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

COTR 50 60 80 105 120 135 150 175 220 260 295 340 360 395 460

(OTA 50 70 90 120 130 140 165 200 250 270 300 350 380 420 460

(RTR 25 40 67 90 115 130 155 190 230 270 305 340 370 400 450

Tempo (Semanas) AB AC AD BC BE CF DF EF FG

Variação $

hazos

Custos

ENT

10 8 4 2 3 5 2 1

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:

Atividade AB AC AD BC BE

% Conduido 100 60 87.5 50 50

Custo Real 523.500 19,200 37.500 8,000 5,500

Tempo Restante (Semanas) 0 4 1 2 1

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 dc 2002, a Delta (Corporation re­ cebeu a concessão de um contrato 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 diente, consistia do seguinte: TABELA 15-17 Custos do projeto

1

2

3

4

5

6

7

Atividade

Peaentud Conduido

Custo Orçado do Trabalho Agendado

Custo Orcodo do Trabalho Realizado

Custo Real do Trabaho Realizado

Variação de Custos = 4-5

Variação de Prazos = 4-3

Total Vcrioçõo de («tos (5) = (duro 4 - (olno 5 =_________ Vcrioçõo de Prazos (S) - (djd 4 - (dum 3=_________ (jjc5 Custo no làirino - laa de gostas ■ ortonenD Md 4 x ( )= Custo pxa lerrrírcf = (Cusío no femmo) - CR1R -____________

515

CONTROLE DOS CUSTOS TABELA 15-18 Orçamento do planejamento do projeto

Semana

8

9

10

4000

2000

2000

1000

3000

BC

1000 3000

4000

4000

BE

6000

6000

Atividade AB

AC AD

1 2000 3000

2

3

4

5

6

7

2000

3000

3000

4000

4000

3000

3000

3000

4000

4000

4000

SOCO

5000

6000

4000

4000

4000

0 DF

3000

3000

EF

12

13

14

2000

3000

3000

3000

4000

4000

2000

2000

11

15

5000

FG

3000

foftr A rcié: .'o-sxfee que o percertoi é Inecr em tearpo e não brecr em cztos 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 dc resumos men­ sal do Projeto da Máquina-Ferramenta Alpha. 1. Qual o valor-alvu total negociado do contrato? 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 u cliente (ou seja, a Alpha) pagará 80% dos dólares acima do custo-aho e até o custo máximo. Da mesma TABELA 15-19 Resumo mensal de custos - junho de 2002

Contrato: GP: Penodo do Relatório: Penodo do Controlo:

Alpha Machine Tool Gary Jones 1 de junho-30 de junho de 2010 1 de fev. 30 de outubro de 2010

Custo Negociado: Remuneracoo-atvo: Preço-alvo:

MêsAtuol, S Mvel2 Itens da EAP Gcf-njarcnto co Proçrorro SctotslaicA Subãslenxj B SdisrslencC Apoo à produção Confide do quebrie

CUSTO DRETO TOTAL

oram i oos TOTAL

Razão do divisão: Limite máximo: Contrato.

Cumulativo até o data. S

COTA 19300

COTR 19300

CRTR 19300

23000 14000 0 11600 5900

16600 15200 0 10400 6003

24200 16800 1200 0 0 0 12000 6000 100 0

73800 73800 147600

67500 67500 135000

78300 78300 156600

S 2.500.000 12% 2.800.000

VPR 0

W 0

80/20 j.uuu.uw em custos t=> m no preto j preço íixo com remuneração de incentivo No Término. S (0U COTA Onginol COTA Cairotodo Liberado Reráodo 200000 200(00 200000

(0U 108000

COTR 108030

(RIR 108000

158000 96000 0 73000 5900

181700 94200 0 74300 6000

234700 23700 250000 93000 1200 200000 0 0 0 300000 75600 1300 200000 6000 100 0 100000

VPR 0

V( 0

200000 200000 275000 190000 100000

Vor.

225000 200000 275000 190000 100000

1250000 1165000 1190000 1250000 1165000 1190000 2500000 2330000 2380000

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). 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 e %] 17. Quantas variações de prazos a Acme sofreu até o momento? |$ 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 eh 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 dc mão dc obra a partir dos seguintes dados:

Preço/unidode [fonejodo Unidades reais Pie(c/urid)de real Custo real

Materiais Diretos S 10,00 $ 9.300 S 9,25 $86.025,00

Mão de Obro Direta $ 22.00 12,000 $ 22.50 $270,000

15-20 Um de seus gerentes de projetos assistente for­ neceu-lhe um relatório dc valor agregado que está conduido apenas parcialmenle. Você pode preencher as informações que faltam? (Todos os números são em milhares de dólares)

Pacotes de Trabalho do EAP

COTA

COTR

CRTR

VPR

A B

103 0

115 —

—

40

12 —

—

C D

42 66 87

12 —

33 94

189

77 —

116 184

10

161



—

—

H

P

VC

$ 473

—

15-21 O seguinte problema exige uma compreensão da EAP, dos elementos da conta dc custas c da análise dc controle dc 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 c. $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.

E.I-5.1 f.1-5.3 E2-5.2 E2-5.4 E.3-5.1 L3-5.3 L4-5.3 E4-5.2 Elemento da Elemento da Elemento da Elemento da Elemento da Elemento da

$1.0 $1.5 $1.0 $2.0 $1.0 $2.5 $3.0 $3.5

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 $____ 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 de mão de obra direta. Seu primeiro passo é calcular o número de ho­ ras disponíveis em 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 (l 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 cliente 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. F.NT = (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 (lòtol) 1000 1000 1000

• 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

CRTR 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 dc 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): Atividade A B C D E

COTA $800 1200 800 1200 1000

COTR $1000 1000 1000 1000 1000

CRTR $1100 900 700 1100 800

VPR

VC

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

c. A administração quer saber o andamento total do projeto no nível I da EAP. Adicio­ ne todas as variações de 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

Dólares Horas Dolores Horas Dolores Horas

29.750 )

VPR = +$4250 34.000 J 38.4001

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

COTA

Dotas 29.750 Horas 350 Dolores 34.000 Horas 400 Dotas 38.400 Horas 320 VC (SSS) = negotiw VC (boras) =-positivo

COTR

CRTR

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

Categoria Salarial 9 8 7 6 5

Titulo Corwfor de Engenharia Engenheiro Sênior Engenhero Engerhero k Engenhero Açxendiz

Salário Sem Encargos $53/hora 48 39 34 29

Salário com Encargos $132,50 120,00 97.50 85,00 72,50

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 cliente 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)

1

Salário Categoria Salarial 9 8 7 6 5 'feris putts

Titulo Consufcor de Engenharia Engenheiro Sênior Engenheiro Engenheiro k Engenheiro Aprenóz

2006 53 48 39 34 29

200756 50 42 36 31

200860 53 45 39 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 $ 193.166 deveria ser apresentada.

• As promoções e aumentos de salários, incluindo os ajustes do custo dc vida, sejam efetivadas em Io 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?

520

Gerenciamento de Projetos TABELA 15-24 Resumo de preços do projeto

Departamento Erçerac hoduiõo

Mõo de Obra Direta Overhead Horas Taxo Dolores X Dolores 1.000 $ 42.00 42.000 110 46200 500 $35,00 17500 200 35.000 *teo fotalde àOtro Ojtns: $ijk:oe

Mudados no

pao o (Sente

• ALdoncns ■aswr

flxodecouB

■ esr.po

oSlUIOS

• Prswsõo (pebkíoçõo

1* 01 nõo doo •Fohdeopoo

■ :

; ; óo odmostoçoo;

(onpntc) •MódeSnçoo

• dew®

Mudmçosno OOTOçnroa (edamdode

t I

«xi cs nonros

:

aníxecteede

segurc»xo do •obolho

; oexpeor»

;

1

A-sraode yslennsde (ortole

FIGURA 17-5 Análise de riscos no ciclo de vida.

Uma abordagem estruturada para a identificação de riscos inclui uma ou mais abordagens de alto nível, juntamente com uma ou mais abordagens de baixo nível. Algumas abordagens de alto nível comuns são descritas a seguir, seguidas por abordagens de baixo nível. Abordagens comuns de alto nível incluem a estru­ tura analítica do projeto (EAP), processos chave, e re­ quisitos chave. Para ajudar na identificação dos riscos, elementos, processos e requisitos do programa devem ser quebrados a um nível em que avaliações válidas possam ser realizadas. (As informações necessárias para fazer isso variam de acordo com a fase do programa. Durante as fases iniciais, os documentos de requisitos e de escopo e os planos de aquisições podem ser os únicos dados es­ pecíficos do programa disponíveis.) Uma abordagem é baseada na EAP do projeto e é usada para avaliar elementos/produtos. Uma segunda abordagem é a abordagem de processos, que é utilizada para avaliar os processos fundamentais (por exemplo, design, produção e testes). Uma terceira abordagem utiliza o fluxo descendente das informações de requisitos em uma tentativa de isolar es­ pecificações que provavelmente serão difíceis de cumprir. A abordagem da EAP utiliza a EAP em um nível ade­ quado de endentação através do projeto. Normalmente,

os riscos do projeto tenderão a existir em dois ou trés agrupamentos dos níveis da EAP. O primeiro é o nível 1 ou 2 da EAP, abrangendo riscos de nível de sistema (ou riscos de alto nível). (Por exemplo, o risco associado com a disponibilidade do sistema, em virtude da utilização de uma tecnologia fundamental não testada). Muitos riscos de alto nível simplesmente não existirão nos níveis infe­ riores da EAP e podem ser difíceis de definir. Para ser efi­ caz na identificação de tais riscos, é necessário utilizar a proverbial “visão ampliada” do projeto. O segundo agru­ pamento de riscos potenciais em um projeto com escala de médio a grande normalmente existirá nos níveis de 3 a 6 da EAP. Aqui, por exemplo, os subsistemas indivi­ duais, caixas, códigos de software (por exemplo, item de configuração de software de computador), ou montagens poderão incluir riscos potenciais. Nesse nível mais baixo da EAP (frente aos riscos de alto nível), mais pessoas do projeto devem possuir conhecimentos específicos sobre os riscos potenciais. Embora isso possa ser muito útil, é importante não excluir os riscos potenciais por meio de uma análise míope que esteja intencional mente ou inade­ quadamente excluindo determinados riscos. Finalmente, os riscos podem existir mesmo em níveis ainda mais bai­ xos da EAP (por exemplo, do nível 7 para baixo), mas esses riscos, muitas vezes, são muito difíceis de se iden­ tificar, a não ser que existam informações específicas que apontem para os componentes adequados. (Por exemplo, um componente eletrônico foi definido separadamente como tendo questões de confiabilidade.)

A abordagem de processos avalia os riscos associados a alguns processos fundamentais (por exemplo, design, produção e testes), que existirão em um projeto4. A estru­ tura é voltada para programas que estão do meio para o final na fase de desenvolvimento, mas que, com modifica­ ções, poderíam ser utilizados para outros programas. Os modelos são utilizados para cada atividade técnica prin­ cipal. Cada modelo identifica áreas potenciais de risco. A sobreposição de cada modelo em um projeto permite a identificação de áreas incompatíveis, que são identifica­ das como “em risco” e, portanto, riscos candidatos.

4

Informações sobre essa abordagem estão contidas na Diretiva

4245.7-M do Departamento de Defesa do Governo Americano, Transition from development to production, de setembro de 1985,

que fornece uma estrutura padrão para a identificação de áreas

técnicas de risco na transição do desenvolví mento para a produ­

çào. Nota: O material desse documento é, de certa forma, anti­ go, mas, ao menos parcialmente, aplicável aos programas atuais. Além disso, o material foi desenvolvido antes de o Departamento de Defesa adotar as equipes integradas dc produto (IPTs) nos

anos 1990, o que pode, em alguns casos, proporcionar maior foco a processos fundamentais do programa.

553

GERENCIAMENTO DE RISCOS

A abordagem de requisitos incorpora o fluxo des­ cendente das informações de requisitos para isolar espe­ cificações que provavelmente serão difíceis de cumprir. Por exemplo, um computador necessário para ter um au­ mento de dez vezes na taxa de processamento versus uma unidade de última geração que pode ter questões desafia­ doras relacionadas com escalabilidade, arquitetura, design de componentes, design da embalagem, produção, e assim por diante. O seguinte exemplo hipotético demonstra ainda mais esse tipo de análise. Suponha que um veículo aeroespacial deve ser concebido para voar em velocidade muito alta, em uma altitude relativamente baixa. Nesse caso, em que a resistência do ar é potencialmente muito elevada, é necessária uma usina de energia de alta pres­ são para superar essa resistência. Além disso, a alta velo­ cidade adicionará consideráveis requisitos de resfriamen­ to térmico para a parte eletrônica do veículo devido ao aquecimento aerotérmico na atmosfera. Isso pode levar a restrições de design e tecnologia, por causa da necessidade de refrigeração e afins (todo o resto mantido constante). A chave para realizar esse tipo de identificação de riscos é possuir um fluxo descendente exato, daro e potencial­ mente abrangente das informações de requisitos, junta­ mente com pessoal de projeto experiente que possa com­ parar aspectos importantes dos requisitos contra possíveis soluções do nível de arquitetura para o nível de tecnologia.

Exemplos de abordagens de baixo nível de identifica­ ção de riscos incluem, mas não estão limitadas a:

• • • • • • • • • • • • • ■ • • •

Afinidade Análise das premissas Estimativas de custos da linha de base Brainstorming Diagramas de causa/efeito Listas de verificação Análise de custos Caminho crítico e quase crítico (análise de crono­ grama) Condutores de decisões Técnicas de diagramação (por exemplo, diagramas de influência) Análise de valor agregado Opinião/julgamento especializado * 412 Análise de falhas Diagramas de influência Lições aprendidas de programas análogos Análise do custo do ciclo de vida Avaliações de saúde da logística

Kn Opinião especializada. Tradução oficial.de acordo com a quinta

edição do Guia PMBOK* para a técnica Expert Judgment.

• • • • • • • •

• • • • •

Métricas Modelos Decomposição do plano/EAP Investigações de causas raiz Análise do cronograma Pontos fortes, pontos fracos, oportunidades e ameaças (SWOT™) Documentação de engenharia de sistemas Medição/planejamento/análise do desempenho técnico Análise da tecnologia Projetos de desenvolvimento/inserção de tecnologia Análises/estudos de mercado Perguntas gatilho Gatilhos de escalas de risco

Como mencionado aqui, uma ou mais abordagens de alto nível e uma ou mais abordagens de baixo nível devem ser usadas em conjunto para fornecer uma meto­ dologia de identificação de riscos estruturada e abrangen­ te. Por exemplo, com a abordagem de F.AP, um produto (por exemplo, computador) é decomposto em monta­ gens de nível inferior, como a placa-mãe, placa de vídeo, fonte de alimentação e sistema de arrefecimento. A placa-mãe pode ainda ser decomposta em uma variedade de circuitos integrados, tais como o processador, memória, circuitos dc entrada/saída, e modem. Essa decomposição de alto nível (EAP neste caso) juntamente com uma ou mais abordagens de baixo nível (neste caso, os resulta­ dos da análise de falhas e lições aprendidas de programas análogos) são, então, usadas para examinar se os riscos potenciais estão presentes.

Usar apenas abordagens de alto nível ou de baixo nível aumenta a chance de riscos potenciais não serem identificados porque a avaliação é frequentemente re­ alizada de forma ad hoc. não abrangente, e/ou de for­ ma não estruturada. Da mesma forma, uma mistura das abordagens alto nível e baixo nível é provavelmente melhor do que a utilização de qualquer método único. Note, entretanto, que a utilização de qualquer método na forma de “livro de receitas” pode fazer com que as­ pectos únicos dos riscos do projeto sejam ignorados, e o gerente do projeto deve revisar os pontos fortes e fracos da abordagem e identificar outros fatores que possam introduzir riscos técnicos, de cronograma, de custos, de programa e outros.

Análise SWOT (Strengths = Pontos fortes. Weaknesses = Pontos

fracos. Opportunities = Oportunidades, Threats = Ameaças).

554

Gerenciamento de Projetos

As técnicas de opinião especializada são aplicáveis não apenas para a identificação de riscos, mas também para a previsão e tomada de decisões. Duas técnicas de opinião especializada são o método Delphi * 74 e a técnica de grupo nominal * 75. O método Delphi tem as seguintes etapas gerais:

Passo 1: um painel de especialistas é selecionado, tanto dentro como fora da empresa. Os especialistas nào interagem face a face e podem nem mesmo saber quem mais participa no painel. Passo 2: cada especialista é convidado a fazer uma previsão anônima sobre um assunto particular. Passo 3: cada especialista recebe um feedback com­ posto das respostas do painel inteiro e é convidado a fazer novas previsões com base no feedback. O processo é, en­ tão, repetido conforme necessário. Intimamente relacionada com o método Delphi está a técnica de grupo nominal, que permite contato face a face e comunicação direta. Os passos na técnica de grupo nominal são os seguintes:

Passo I: um painel é convocado e solicitado para ge­ rar idéias por escrito. Passo 2: as idéias são listadas em um quadro ou em um flip chart. Cada ideia é discutida entre os debatedores. Passo 3: cada debatedor prioriza as idéias, que são, então, ordenadas por classificação. Os passos 2 e 3 podem ser repetidos, conforme necessário. As técnicas de opinião especializada tém o poten­ cial de parcialidade na identificação e na análise de ris­ cos, bem como na seleção das estratégias de resposta aos riscos. Essas parcialidades variam caso a caso, e podem afetar diferentemente as estimativas da probabilidade de ocorrência e da consequência da ocorrência.

Fatores cognitivos podem introduzir uma parciali­ dade e/ou condição de ruído que podem afetar a identifi­ cação de risco e/ou os resultados da análise de risco. Esses fatores cognitivos incluem, mas nào estào limitados a: • • • • • •

Ajustes a partir de um valor inicial Ancoragem (com tendência para o valor inicial) Disponibilidade (de eventos passados) Adequar evidências ambíguas em predisposições /\ feita de sensibilidade para o problema ou risco Motivação

Excesso de confiança na confiabilidade da análise Excesso de confiança na própria capacidade Proximidade com o projeto Relacionamento com outros especialistas Representatividade (o grau em que A se asseme­ lha a B) • Sistematicamente omitir componentes de risco

• • • • •

Os riscos candidatos resultantes sào então devida­ mente documentados em um registro de riscos ou ou­ tro relatório apropriado. Enquanto a documentação não deve ser enciclopédica por natureza, deve, no entanto, fornecer informações suficientes para permitir que os tomadores de decisão determinem com precisão quando ou não um risco candidato deve ser aprovado. Por exem­ plo, um formulário de identificação de riscos que tem de meia a uma página de comprimento pode fornecer um detalhamento amplo sobre o risco potencial para que os tomadores de decisão avaliem sem que isso seja pesado demais para ser concluído. A documentação de identificação de riscos deve con­ ter uma declaração de risco clara e cuidadosamente es­ crita, idealmente no formato “se-entào”; especificamente: “se” o risco ocorrer, “então” qual será o impacto (conse­ quência da ocorrência)?5. Para o exemplo do computa­ dor discutido anteriormente uma declaração “se-entào" candidata poderia ser: Se uma capacidade insuficiente de refrigeração do computador está presente, então o pro­ cessador e outros circuitos de consumo dc alta potência podem exceder a temperatura de operação segura, levan­ do a um aumento da taxa fàilure-in-time (HT) * 16.

Às vezes é mais fecil admitir uma probabilidade = 1 para a parte “se” da declaração ao desenvolver a parte “en­ tão” da declaração. Utilizar esta abordagem evita confu­ são relacionada ao nível de probabilidade de ocorrência (e seus componentes) e consequência da ocorrência (custo, desempenho técnico, cronograma). (Nota: As estimativas

’

Modificações ã declaração comumentc usada “sc-cntão” são

possíveis, tais como “se-cntão-porquc" [que pode apontar para a(s) causas (s) raiz). Enquanto que declarações expandidas para além do “se-entào" podem ser úteis, tais declarações podem também confundir os entrevistados e levar à diminuição da

qualidade da declaração de risco. Por exemplo, incluir termo

“porque" para resolver a potencial causa raiz, levou em alguns casos a respostas que eram uma explicação adicional do termo

Método Delphi. Em tradução da expressão em inglês, Delphi

“então", apesar dc treinamento específico a respeito da natureza

Method. No Guia PMBOK* - 4. ed., o termo utilizado é Delphi

dos componentes da declaração “se-então-porque".

Technique, e a tradução oficial Técnica Delphi.

A taxa Faiiures-in-time (FIT), ou “falhas no tempo" em

Técnica de Grupo Nominal. Em tradução oficial, de acordo

português, é o número de falhas que podem ser esperadas em

com a quarta edição do Guia PMBOK*, para Nomina! group

um bilhão de horas de operação de um dispositivo. Este termo

technique.

é utilizado principalmente pela indústria de semicondutores.

555

GERENCIAMENTO DE RISCOS

de probabilidade e consequência devem ser realizadas como parte da análise de risco se o risco candidato iden­ tificado for aprovado pela gerência e não for incluído na identificação de riscos).

Os itens que devem ser incluídos na documentação de identificação de risco incluem, mas não estão limi­ tados a: (1) Número do risco, (2) data de identificação inicial, (3) atual proprietário do risco, supervisor, e or­ ganização; (4) declaração “se”, (5) declaração “então”; (6) causa(s) potencial ou causa(s) raiz (quando conhecida)'1, (7) categorias de risco relevantes; (8) informações de fun­ do (incluindo quaisquer ações de tratamento realizadas até a data), (9) relação de todos os (outros) riscos exis­ tentes; (10) fase do projeto; (11) status de aprovação de riscos, e (12) data de aprovação do risco. A documentação do risco deve ser atualizada conforme justificado, quando existirem mudanças significativas em qualquer um dos itens relacionados aqui.

Uma vez que um risco candidato é identificado, o risco é o primeiro revisto pelo nomeador e pela gerência adequada (por exemplo, o gerente de riscos) e a docu­ mentação de identificação do risco (ou banco de dados) é atualizada conforme necessário. O risco deve então ser revisto pela gerência de projetos adequada, que então determina se o risco será aprovado ou nào, e quem será designado ou aprovado como proprietário do risco (que pode ser ou nào o nomeador de risco). Potenciais resul­ tados da decisão no que diz respeito ao risco candidato incluem, mas nào estão limitados a: deferido, penden­ te, necessita informações adicionais, aprovado, fechado, rejeitado, ação do gerenciamento e item de processos/ prática de engenharia. (Todas as decisões associadas aos riscos candidatos e outras ações devem ser documentadas e mantidas para fornecer um registro de gerenciamento de risco durante o projeto e programa associado). Muitas vezes os riscos candidatos serão na verdade ações de ge­ renciamento potenciais (por exemplo, atenção necessária para fornecer recursos, requisitos completos) ou itens de processos/práticas de engenharia (trabalho de engenharia normal) que podem não subir para o nível risco, mas no entanto, precisam ser tratados para garantir que não afe­ tarão negativamente o programa7.*2

Em alguns casos a(s) causa(s) raiz exata(s) pode(m) nunca

Finalmente, é importante que todo o pessoal do projeto esteja envolvido com a identificação de riscos. A designação de um pequeno grupo de pessoas para reali­ zar a identificação de riscos, quase sempre diminui os re­ sultados, tanto técnicos (número de riscos identificados válidos) quanto da perspectiva comportamental (envia a “mensagem errada” para outros funcionários do projeto) e pode levar à diminuição da eficácia do gerenciamento dos riscos. Essa prática deficiente de identificação de ris­ cos deve ser evitada sempre que possível. (Nota: isso é di­ ferente de ocasionalmente ter um pessoal de fora trazido para auxiliar o projeto de forma independente na identi­ ficação de riscos candidatos, o que se mostra benéfico em projetos desafiadores.) 17.8 ANÁLISE DE RISCOS (11.3,11.4)

A análise de riscos é um processo sistemático para estimar o nível de risco para os riscos identificados e aprovados. Isso envolve a estimativa da probabilidade de ocorrência e da consequência da ocorrência e a conversão dos resul­ tados em um nível de risco correspondente. A abordagem utilizada depende da disponibilidade dos dados e dos re­ quisitos levantados no projeto. A forma mais comum de abordagem qualitativa é a utilização de escalas de proba­ bilidade de ocorrência e de consequência de ocorrência, juntamente com uma matriz de mapeamento de riscos para converter os valores para níveis de risco. Abordagens quantitativas incluem, mas não estão limitadas a, valor es­ perado | também conhecido como valor (monetário) espe­ rado para cálculos baseados em custos), análise da árvore de decisão (com ramos especificados pelas probabilidades específicas e/ou distribuições), matrizes de pagamentos, e modelagem e simulação. É de fundamental importância a utilização de uma metodologia aprovada, estruturada e reproduzível, em vez de uma abordagem subjetiva, que possa render resultados incertos e/ou inexatos. A análise de riscos começa com uma avaliação de­ talhada dos riscos que foram identificados e aprovados pelos tomadores de decisão para avaliação futura. O obje­ tivo é reunir informações suficientes sobre os riscos para estimar a probabilidade de ocorrência e a consequência de ocorrência, e converter valores resultantes para um nível de risco correspondente. (Nota: É importante que apenas riscos aprovados sejam analisados para evitar que

ser conhecida(s), apesar de enormes quantidades de recursos gastos durante as investigações.

no entanto, um item que pode ser categorizado regularmente).

Tanto as ações de gerenciamento como os itens de processos/

Se qualquer um destes componentes se tornarem “quebrados"

práticas de engenharia devvm ter (1) proprietário atribuída

(por exemplo, o proprietário nào está disponível ou o plano

(2) plano de fechamento sumarizado desenvolvido, e (3) uma

de fechamento ou a data não são mais válidos), a ação da

data dc encerramento prevista. Esta informação deve ser do­

gerência ou itens de processos/práticas de engenharia devem

cumentada em um “rastreador de ação’ ou equivalente (menos

ser reavaliados como risco candidato, para impedir que o item

formal do que uma base de dados de gestão de risco, mas,

acabe se tornando uma questão ou problema.

556

Gerenciamento de Projetos

os recursos sejam gastos em questões que possam não ser realmente riscos.) As análises de riscos baseiam-se frequentemente em informações detalhadas que podem vir de uma variedade de técnicas, incluindo, mas nào limitadas a:

• • • • • • • • •

Análise dos planos e documentos relacionados Comparações com sistemas similares Dados de engenharia ou de outros modelos Experiência e entrevistas Modelagem e simulação Estudos relevantes das lições aprendidas Resultados do desenvolvimentode testes e protótipos Análise de sensibilidade de alternativas e de insumos Opiniões de especialistas e peritos

Cada categoria de risco (por exemplo, custos, de­ sempenho técnico, e cronograma) inclui um conjunto de tarefas de avaliação e está relacionada a outras duas categorias. Esse relacionamento requer análise de apoio entre as áreas para garantir a integração do processo de avaliação. Algumas características de avaliações de custos, cronograma e avaliações técnicas são:

Avaliação de Custos • Baseia-se nos resultados de avaliações técnicas e de cronograma • Traduz riscos técnicos e de cronograma em custos • Deriva a estimativa de custos por meio da integra­ ção de riscos técnicos, riscos de cronograma e dos impactos da incerteza da estimativa de custos so­ bre os recursos • Prioriza os riscos pelo impacto no programa • Documenta a base e os riscos de custos para a ava­ liação de riscos

Avaliação de Cronograma • Avalia as entradas de cronograma na linha de base • Reflete a base técnica, a definição das atividades, e as entradas das áreas técnicas e de custos • Incorpora as avaliações técnicas e de custos e as entradas de incerteza no cronograma do modelo de cronograma do programa • Realiza a análise da programação no cronograma do programa • Prioriza os riscos pelo impacto no programa • Documenta a base e os riscos de cronograma para a avaliação de riscos

Avaliação Técnica • Fornece base técnica • Identifica e descreve os riscos do programa (por exemplo, de tecnologia)

• Analisa os riscos e os relaciona a outros riscos in­ ternos e externos • Prioriza os riscos pelo impacto no programa • Analisa entradas para a avaliação de custos e de cronograma • Analisa as atividades de programa associadas à du­ ração de tempo e aos recursos • Documenta a base e os riscos técnicos para a ava­ liação de riscos /\ descrição e quantificação de um risco específico e sua magnitude normalmente exigem alguma análise ou modelagem. Ferramentas típicas para utilização nas aná­ lises qualitativa e/ou quantitativa de riscos sào:

• Análise dos planos e de outros documentos para estimar as variações • Análise da decisão (incluindo árvores de decisão, valor esperado etc.) • Técnicas Delphi • Relações das estimativas • Opinião especializada • Análise do modo e efeito de falha (relacionada com a confiabilidade) • Análise de árvore de falhas (relacionada com a confiabilidade) • Análise gráfica • Análise do custo do ciclo de vida • Análise lógica • Análise de rede • Matrizes de pagamentos • Análise proba bilísti ca dos riscos (relacionada à con­ fiabilidade) • Modelos de processos (por exemplo, Diretiva 4245,7-M do Departamento de Defesa) • Análise de impacto da taxa/quantidade de reação rápida • Escalas de risco (normalmente “probabilidade” ordinal e escalas de consequência) • Matriz de mapeamento dos riscos com resultados de escala dos riscos • Análise do cronograma • Análise de sensibilidade • Simulação (por exemplo. Monte Cario) para cus­ tos, desempenho técnico e cronograma • Tendências do estado da arte em tecnologia • Análise dos custos totais de avaliação dos riscos "* (TRACE) 7 • Simulação da estrutura analítica do projeto

Da expressão em inglês, (TRACE).

Total

risk-assessing

cost

analysis

557

GERENCIAMENTO DE RISCOS

Após realizar uma análise de riscos, muitas vezes é necessário converter os resultados em níveis de risco. Quando uma metodologia de análise quantitativa de ris­ cos é utilizada, os resultados podem ser agrupados por risco de custos, risco de cronograma, ou limites de riscos técnicos existentes que foram especificamente adaptados para o programa, ou pela realização de uma análise de cluster (estatística) sobre os resultados.

MINTO PROVÁVEL -

OPíOmUDADÍ-

CHANG MUITO BOA -

provável MAIS WW IAM PtOBAHUOAM V/DAÀ16UAUCHMG 4 «

Quando uma análise qualitativa dos riscos é rea­ lizada, as classificações dos riscos podem ser utilizadas como uma indicação da importância potencial dos ris­ cos de um programa. Essas classificações são, normal­ mente, uma medida da probabilidade de ocorrência e das consequências de ocorrência e, muitas vezes são expressas em baixo, médio e alto (ou, eventualmente, baixo, médio baixo, médio, médio alto e alto). A seguir, um conjunto representativo (capcioso) das definições de classificação de riscos: • Risco Alto: impacto substancial nos custos, no desempenho técnico ou no cronograma. São ne­ cessárias ações substanciais para aliviar a ques­ tão. F. necessária a atenção de alta prioridade da administração. • Risco Médio: algum impacto nos custos, no de­ sempenho técnico ou no cronograma. Pode re­ querer uma ação especial para aliviar o proble­ ma. Pode ser necessária uma atenção adicional da administração. • Risco Baixo: impacto mínimo nos custos, no de­ sempenho técnico ou no cronograma. É suficiente uma supervisão normal da administração.

F. importante usar as definições acordadas (como as definições “capciosas” apresentadas aqui) e procedimen­ tos para estimar os níveis de risco, em vez de atribuí-los subjetivamente, uma vez que cada pessoa poderia facil­ mente ter um entendimento diferente das palavras nor­ malmente usadas para descrever tanto probabilidade quanto risco (por exemplo, baixa |o],média|o] e alta [o]). A Figura 17-6 mostra o que algumas declarações sobre probabilidade significam para pessoas diferentes. (Esta figura é um subconjunto de resultados Conrow obtidos a partir de uma pesquisa de 50 declarações de probabili­ dade subjetivas comuns com 151 pesquisas concluídas). Existe um intervalo de probabilidade não trivial entre os percentis 5 e 95 (por exemplo, 0,4 ou mais) para 9 das 11 declarações apresentadas. No entanto, são possíveis inter­ valos de probabilidade maiores do que os mostrados na Figura 17-6.

BJJXA PRUKWUUUt 4 ■ PERGNTtS

PEOJEKA ttOBABlLW. 4

51O2S

SOJSWrt

1--------- 1--------- 1--------- 1--------- 1--------- 1--------- 1--------- 1--------- 1--------- 1

0

10

20

30

40

SO

60

70

80

90

100

PROBABIllOtí)EAI0BUÍOÂ(M

FIGURA 17-6 O que os decloroçòes de incerteza significam para

diferentes pessoas.

Por exemplo, 49 das 50 declarações subjetivas sobre probabilidade tiveram um intervalo de respostas (máximo-mínimo) maior ou igual a 0,70! Isso enfatiza o ponto em que as declarações subjetivas de probabilidade podem ter significados substancial mente diferentes para pesso­ as diferentes e escalas de probabilidade baseadas nessas declarações devem ser evitadas para reduzir as chances

de má classificação. Sempre que possível, escalas de pro­ babilidade ordinal (por exemplo, Figura 17-6) devem ser desenvolvidas e utilizadas como alternativa . * A priorização dos riscos do programa deve ser rea­ lizada depois que uma abordagem estruturada de classi­ ficação dos riscos tenha sido aplicada. Aqui, muitas vezes serão necessárias as contribuições de gerentes e técnicos para separar os riscos analisados dentro de um nível de classificação (por exemplo, priorizar vários riscos altos). A metodologia utilizada para gerar a lista priorizada de riscos irá variar um pouco com a metodologia utilizada. Por exemplo, com escalas de risco, a classificação dos ní­ veis de risco dependerá da probabilidade e da consequ­ ência de ocorrência mais, eventualmente, da frequência de ocorrência, do tempo de impacto, e das inter-relações com outros riscos. Para uma análise dos do custo do ris­ co usando uma simulação de Monte Carlo, a classificação pode envolver a magnitude percentual do custo do risco no nível de confiança desejado (por exemplo, 70° percentil). Para os resultados da análise de decisão envolvendo

Veja Conrow, 2003, Nota 1, Apêndice), pg. 491-513.

558 o valor monetário esperado (EMV)”™, a classificação pode ser simplesmente uma lista de resultados do maior resultado positivo para o menor resultado negativo. Ne­ nhum desses métodos de geração de uma lista priorizada de riscos é necessariamente superior a qualquer outro - todos eles são potencialmente úteis. O desafio, nesses casos, é integrar eficazmente os resultados do que pode ser um conjunto diversificado de resultados em uma lista de riscos única. Não há um “melhor” algoritmo para re­ alizar isso em um projeto do mundo real. Os gerentes de projetos devem derivar essa lista a partir de um consenso associado a uma avaliação estruturada dos resultados da análise de riscos e, na medida do possível, documentar a sua lógica. Um risco visto como facilmente gerenciável por parte de alguns gerentes pode ser considerado difícil de gerenciar por gerentes menos experientes ou com me­ nos conhecimento. Consequentemente, os termos risco “alto”, “médio” ou “baixo”, são um pouco relativos, mes­ mo quando comparados às definições “capciosas”. Alguns gerentes podem ser avessos ao risco e escolher evitar os riscos reconhecidos a todo custo possível. Outros geren­ tes podem ser propensos ao risco e realmente preferir utilizar uma abordagem mais arriscada. Os termos risco “alto", "médio” ou “baixo" podem mudar com a rotativi­ dade dos gerentes e de seus superiores, tanto quanto com os eventos do projeto. Os gerentes de programas podem utilizar as classifi­ cações de riscos para identificar problemas que requerem gerenciamento prioritário (por exemplo, planos de res­ posta ao risco podem ser necessários para todos os riscos médios ou altos). As classificações de riscos também aju­ dam a identificar as áreas que devem ser relatadas, dentro e fora do programa. /\ssim, é importante que as classifi­ cações sejam retratadas da forma mais precisa possível.

Gerenciamento de Projetos

ou o prazo do projeto, (4) probabilidade de não cumprir os requisitos de desempenho do projeto, (5) resultados da análise da decisão, (6) modos e efeitos de falha (con­ fiabilidade), (7) caminhos de falha (confiabilidade), e (8) probabilidade de falha (confiabilidade). 17.9

ANÁLISE QUALITATIVA DE RISCOS (11.3)

Uma metodologia comumente utilizada de análise qua­ litativa de riscos envolve escalas de risco (modelos) para estimar a probabilidade de ocorrência e a consequência de ocorrência, juntamente com uma matriz de mapea­ mento de riscos. O risco é avaliado por meio de opinião especializada contra todas as escalas de probabilidades de ocorrência relevantes, bem como contra as três conse­ quências das escalas de ocorrência (custos, desempenho técnico e cronograma), e os resultados são, então, trans­ feridos para uma matriz de mapeamento de riscos para conversão em um nível de risco correspondente. O risco é incluído em uma lista priorizada, com base no nível de risco, bem como em outras considerações (por exemplo, a frequência de ocorrência, momento de impacto e inter-relações com outros riscos). Existem várias classes diferentes de escalas de risco9.0 primeiro tipo de escala é nominal, detentora de coeficien­ tes sem significado matemático e os valores são geralmente variáveis (por exemplo, números de autoestrada). As esca­ las nominais não são utilizadas nas análises de risco. O segundo tipo de escala é de intervalo. Escalas de intervalo, como Fahrenheit e Celsius, sào cardinais por natureza. No entanto, as escalas não possuem nenhum ponto zero significativo, e as relações entre escalas seme­ lhantes nào sào equivalentes. As escalas de intervalo nào sào comumente usadas em análises de riscos.

É possível que exista várias saídas diferentes para ambas as análises qualitativa e/ou quantitativa dos riscos. Essas saídas incluem, mas não estão limitadas a: (1) uma avaliação do risco global do projeto, (2) uma lista priori­ zada de riscos, (3) a probabilidade de exceder os custos e/

O terceiro tipo de escala é ordinal. Escalas ordinais têm níveis que sào apenas ordenados por classificação eles nào têm significado cardinal porque os valores reais de intervalo da escala são desconhecidos. Nào há justifica­ tiva probabilística ou matemática para executar operações matemáticas (por exemplo, adição, multiplicação, média) nos resultados obtidos a partir de escalas ordinais, e quais­ quer resultados podem ter grandes erros. Por exemplo, foram desenvolvidos exemplos relativamente simples que contêm erros de 600% ou mais na comparação dos coefi­ cientes reais versus os coeficientes considerados na escala ordinal10. Essa escala ordinal pode ser usada para represen­ tar os diferentes aspectos da probabilidade de ocorrência (por exemplo, tecnologia, design, produção) e da conse-

sl> Valor Monetário Esperado. Tradução oficial da versão em

*

As áreas de alto risco podem refletir em falta de ca­ pacidades na organização do gerente do projeto ou nas organizações de apoio. Elas também podem refletir as dificuldades técnicas no design ou no processo de desen­ volvimento. Em ambos os casos, o “gerenciamento” de riscos envolve a utilização de ativos de gerenciamento do projeto para reduzir o nível de riscos presentes.

Monetary Value (EMV).

Esta seção é derivada de: CONROW, 2003. Nota I, p. 237-245. ©

2003, Edmund 11. Conrow. Utilizado com permissão do autor.

português da quarta edição do Guia PMBOK5 para Expected 10

Ibidem, p. 258-268.

559

GERENCIAMENTO DE RISCOS

quência de ocorrência (por exemplo, custos, cronograma e aspectos técnicos). As escalas ordinais são comumente usadas em análises de riscos. Tais escalas e uma matriz de mapeamento de riscos correspondente podem ser uma metodologia útil para estimar os riscos. No entanto, pelas razões discutidas aqui, deve ser tomado muito cuidado na utilização dessa abordagem. O quarto tipo de escala é ordinal calibrado. São escalas ordinais cujos coeficientes de nível de escala são estimados por meio da avaliação de uma função de utilidade aditiva (ou abordagem similar). Esses coeficientes cardinais estima­ dos substituem os valores variáveis ordinais. Sào possíveis operações matemáticas limitadas que rendem resultados válidos. No entanto, os valores são, muitas vezes, relativos e não absolutos, e o ponto zero pode nào ser significativo. Escalas ordinais calibradas nào sào comumente utilizadas na análise de riscos, em parte, por causa da dificuldade em estimar com precisão os coeficientes associados. O quinto tipo de escala é de razão. Escalas de razão, como Kelvin e Rankine, possuem coeficientes cardinais, indicam posição e importância absoluta e o ponto zero é significativo. Além disso, os intervalos entre as escalas são consistentes e os valores da relação entre as escalas sào sig­ nificativos. Operações matemáticas podem ser realizadas em escalas de razão e rendem resultados válidos. Embo­ ra as escalas de razão sejam as ideais para utilização em análises de riscos, elas raramente existem ou sào utiliza­ das. [Alegações de que as escalas de probabilidade e con­ sequência sào escalas de razão verdadeiras ou de que os resultados sào derivados de escalas de razào sào quase uni­ versalmente falsas. Por exemplo, em um caso amplamente distribuído os coeficientes sào alegadamente derivados de um impacto (escala de razào), mas a relação matemática entre os coeficientes está quase certamente incorreta e nào é representante de uma escala de razão significativa.) O sexto tipo de escala é baseado em estimativas sub­ jetivas atribuídas a diferentes declarações de probabilida­ de (por exemplo, alta), aqui denominada de estimativa de probabilidade. Escalas de estimativa de probabilidade podem ser ordinais (mais comuns) ou cardinais (menos comuns) por natureza, dependendo da origem dos da­ dos de base e da estrutura da escala. No pior dos casos, as estimativas de probabilidade são pontuais ou intervalos desenvolvidos pelo autor da escala, sem qualquer base ri­ gorosa para fundamentar os valores. No melhor dos ca­ sos, as estimativas de probabilidade sào derivadas de uma análise estatística dos dados da pesquisa de um número substancial de entrevistados e incluem as estimativas pontuais e intervalos em tomo das estimativas para cada declaração de probabilidade. As escalas de estimativas de probabilidade às vezes sào utilizadas em análises de ris­

cos. No entanto, esse tipo de escala nunca deve ser a pri­ meira escolha ao realizar-se uma análise de riscos porque as diferentes pessoas podem atribuir diferentes valores de probabilidade para a mesma palavra subjetiva. Isso pode levar a erros não triviais, tanto no valor de probabilidade estimada como no nível de risco resultante.

Uma matriz de mapeamento de riscos é normal­ mente usada para converter a probabilidade ordinal de ocorrência e os valores de escala da consequência de ocorrência a um nível de risco correspondente. Embora não haja nenhum tamanho predefinido para essa matriz, suas dimensões devem ser menores ou iguais ao número dos níveis de escala usado nas duas dimensões, de proba­ bilidade e consequência. Com escalas de dnco níveis de probabilidade de ocorrência e de consequência de ocor­ rência, isso corresponde a uma matriz 5 x 5 ou menor. (Isso é ilustrado no Exemplo 17-2). Embora as matrizes de mapeamento de riscos sejam valiosas para converter as pontuações de probabilidade e consequência em riscos, elas possuem várias limitações e, se não forem cuidadosamente utilizadas, podem levar a erros11. Primeiro, tais matrizes são geralmente ilustradas com o triângulo superior, e nào o triângulo inferior refle­ tido, como definido por uma linha desenhada da origem para a localização da probabilidade e consequência mais alta. A lógica para a utilização de limites assimétricos é, por exemplo, que a célula de menor probabilidade e maior consequência tenha a garantia de ser um risco médio e nào um risco baixo. Ainda, essa abordagem viola a teoria de utilidade, a qual exigiría que os limites entre aho/médio e médio/baixo deveríam ser similares no formato. Segundo, nào há melhor forma de mapear os resultados de escala de probabilidade e consequência na matriz se houver mais dc uma escala de probabilidade e/ou escala dc consequência. Embora a escolha do resultado máximo para cada catego­ ria seja uma resposta conservadora, nào é necessariamente a resposta correta. (E, lembre-se, como essas escalas sào or­ dinais, você nào pode tirar a média da probabilidade e da consequência e inserir esses valores na matriz.)

Terceiro, as preferências de utilidade sào diferentes en­ tre compradores e vendedores, e até mesmo diferentes entre diferentes tipos de compradores e vendedores. Pôr isso, nào fica claro quais preferências de utilidade a matriz representa. Quarto, as organizações sào avessas, neutras ou propensas ao risco? E, o mais importante, qual é o comportamento de ris­ co dos participantes nessas organizações? Isso é importante*

"

CONROW, Edmund H. Risk Analysis for Space Systems. Pro­ ceedings of the space systems engineering and risk managment symposium 2008. Los Angeles, 28 fev. 2008. © 2008, Edmund 11.

Conrow. Utilizado com permissão do autor.

560 porque diferentes organizações e seus indivíduos podem ter diferentes preferências de utilidade, o que pode levar a va­ riações nos limites alto/médio e médio/baixo e/ou a erros de pontuação dos resultados. Quinto, a ordenação dos riscos contidos dentro das células de uma matriz de mapeamento de riscos 5 x 5, ou em qualquer outra, é apenas ordinal e não pode ser cardinal. Tentativas para incluir probabilidade fracionada e/ou consequência de resultados em escala ordinal (por exemplo, 3.4, quando existirem valores ordinais de 1 a 5) em uma matriz ordinal de mapeamento de risco, mui­ tas vezes levará a resultados errados, caso a célula da matriz seja escolhida de forma incorreta, e no pior caso, esta célula incorreta pode cruzar um limite de nível de risco (por exem­ plo, médio a alta). Em razão destes e de outros problemas si­ milares, sob nenhuma circunstância resultados fracionários obtidos a partir de escalas ordinais devem ser incluídos em uma matriz ordinal de mapeamento de riscos.

Existem duas limitações adicionais para o mapea­ mento de matrizes, quando aplicadas a oportunidades. Primeiro, é necessário um conjunto diferente de escalas de consequência para oportunidade versus risco. Como consequência, nào fica claro o que essas escalas de conse­ quência devem representar, uma vez que (como mencio­ nado na Seção 17.1) não existe uma definição universal de oportunidade e, assim, uma consequência de ocor­ rência (ou equivalente) associada a ela. Portanto, a pró­ pria natureza de uma matriz de oportunidade é imatura e problemática por causa da dificuldade subjacente na especificação da dimensão das consequências. Isso pode levar a resultados errados. Em segundo lugar, da teoria da perspectiva (Seção 17.1), as pessoas tendem a valori­ zar o mesmo nível de ganhos e perdas de forma diferente. Ainda, é errada a criação de matrizes de oportunidades e riscos que sejam idênticas umas às outras ou espelho umas das outras e pode levar a decisões erradas. Uma questão final sobre a utilização de uma matriz de mapeamento de riscos está relacionada à priorizaçào dos resultados. É evidente que os riscos baixos versus mé­ dios versus altos podem facilmente ser priorizados. No en­ tanto, a priorizaçào de resultados dentro de um nível de risco (por exemplo, médio) não é tão simples. Isso porque as células contidas na matriz quase sempre possuem limi­ tes ordinais, não cardinais. Isso é particularmente impor­ tante para as células que têm valores similares idênticos (por exemplo, P = 4, C = 3 versus P = 3, C = 4). Esses casos requerem atenção adicional da gerência para priorizar os riscos. É claro que, se os resultados são obtidos a partir de escalas ordinais calibradas, então o fator de risco resultan­ te, RF = P x C classifica diretamente os riscos sem a neces­ sidade de uma matriz de mapeamento de riscos. Outros fatores como frequência de ocorrência, tempo de impacto (quando o plano de resposta aos riscos deve ser iniciado

Gerenciamento de Projetos

ou quando o risco irá ocorrer), e as inter-relações com os outros riscos também podem ser levadas em conside­ ração pela gerência quando do desenvolvimento de uma lista priorizada de riscos, a partir de uma matriz de ma­ peamento de riscos. (Quando escalas ordinais calibradas são utilizadas, essas considerações podem se tornar “de­ sempates” para as pontuações dos fatores de risco que são muito próximas ou idênticas umas às outras). O exemplo simples a seguir ilustra o uso de escalas or­ dinais de probabilidade de ocorrência e escalas ordinais de consequência de ocorrência, uma matriz de mapeamento de riscos na análise de riscos do projeto fornece algumas recomendações para a correta representação dos resulta­ dos12. Observe que essas escalas não devem ser usadas em seu projeto - elas sào fornecidas apenas como ilustração.

17-2. Uma única escala de “probabilidade” de ocorrência, relacionada à maturidade tecnológica é usada e apresentada na Tabela 17-6. (Notai Uma vez que as escalas ordinais de probabilidade quase nunca repre­ sentam a probabilidade verdadeira, mas apenas um indi­ cador de probabilidade, as pontuações derivadas de tais escalas são indicadas como valores de “probabilidade”). Na realidade, o risco técnico normalmente envolverá um número de categorias adicionais de risco além da matu­ ridade da tecnologia, como design, e manufatura. No en­ tanto, o uso de uma única categoria de risco simplifica os cálculos posteriores e é suficiente para fins de ilustração. Para a escala de “probabilidade” de maturidade da tecno­ logia, considere que baixa = níveis de escala A e B, média = níveis de escala C e D e alta = nível de escala E. (Nota: Essa informação nào corresponde ao risco baixo, médio e alto e é apenas um indicador de onde as interrupções ocorrerão quando utilizadas no desenvolvimento da ma­ triz de mapeamento de riscos mais adiante, nesta seção. Letras são fornecidas para os níveis de escala, em vez de números, para desencorajá-lo a tentar executar operações matemáticas inválidas sobre os resultados.) EXEMPLO

TABELA 17-6

Exemplo de escala ordinal de “probabilidade"

relacionada à maturidade de tecnologia Definição

Nivel de Estalo

Pnncipws bóskos observadas

E

Design rontatuol pao o desempenho molisodo

D

Validaõo dos protóhpas trecdxwd e ínjssóardnos ambientes

C

relevantes 0 protótipo passo nos testes de desempenho

B

Hem implaitodo e em operoçoo

A

Este exemplo é derivado de Conrow, 2003, Nota 1, Apêndice I, p. 485-489. Copyright © 2003, EH. Conrow.

Usado com permissão do autor.

561

GERENCIAMENTO DE RISCOS

Três escalas de consequência das ocorrências - para custos, cronograma e aspectos técnicos são usadas e apre­ sentadas na Tabela 17-7. Para cada uma das três escalas de consequência de ocorrência, considere que baixo = níveis de escala A e B, médio = níveis de escala C e D, e alto = ní­ vel de escala E. (Nota: Essa informação não corresponde ao risco baixo, médio e alto e é apenas um indicador de onde as interrupções ocorrerão quando utilizadas no de­ senvolvimento da matriz de mapeamento de riscos mais adiante nesta seção.)

como a Tabela 17-8, a não ser que existam informações específicas, precisas e quantitativas que justifiquem uma matriz assimétrica.) TABELA 17-8

A

B

C

D

E

1

M

M

A

A

A

D

B

M

M

A

A

C

B

B

M

M

A

B

B

B

B

M

M

A

B

B

B

B

M

o

TABELA

técnicos Nrvel de

>10%

N® poder arnpnt o um morto

Desempenho inoteiláel

E

Desempenho oteitówl.

D

maço printipd (fo progromo Grande deswo em um morto

Irwin, 1987. p. 26.

662

Gerenciamento de Projetos

TABELA 20-8 Estratégias primárias de melhoria empregadas

• Desenvolver clientes fiéis, não apenas agradan­ do-os, mas excedendo suas expectativas • Trabalhar em estreita colaboração com os fornece­ dores para melhorar a qualidade e a produtividade do seu produto/serviço • Utilizar tecnologia da informação e da comunica­ ção para melhorar o serviço ao cliente • Desenvolver a organização em unidades gerenciá­ veis e focadas no intuito de melhorar o desempenho • Utilizar engenharia concorrente ou simultânea. • Incentivar, apoiar e desenvolver programas de for­ mação e treinamento dos funcionários • .Melhorar a oportunidade de todos os ciclos de operação (minimizar todos os tempos de ciclo) • Eoco em qualidade, produtividade e a lucratividade • Foco em qualidade, oportunidade e flexibilidade

pelas corporações listadas

Estratégia Pl

P2

P3

P4

P5

P6

P7

X

Asea, Brown. Bc.en

AT&T

X

X

Ctgro X

DuPont X

Eastman Kodak

Eaton Corp.

X

Fad Meta Co.

X

X

X

X

X

Geraci Motors

Goodyea Tire

X

X

IBM Rochester iaft

X

Johnson Controls

X X

Motorola New Ergland Corp. New Yak life

X X

Pratt and Whitney Xerox Corp.

X X X

fomt. PEGEIS, C Carl lotai quoky managotnort. Danvers, MA Boyd & Fraser,

1995. p. 21.

a seguir. Um resumo das sete principais principais estra­ tégias de melhoria mapeadas em 17 empresas é mostrado na Tabela 20-8.

É difícil a obtenção de informações sobre a me­ lhoria da qualidade das corporações. A maior parte das empresas considera essa informação confidencial e não gosta de publicar por medo de oferecer uma vantagem para seus concorrentes. Como resultado, as informações TABELA 20-9 Estratégias secundárias de melhoria

empregadas pelas corporações listadas

Estratégias primárias: • Solicitar dos empregados idéias de melhoria • Incentivar e desenvolver equipes para identificar e resolver problemas • Incentivar o desenvolvimento da equipe para rea­ lizar operações e atividades de serviços, resultando em liderança participativa • Realizar benchmarking de cada atividade principal na organização para garantir que ela seja feita da forma mais eficiente e eficaz • Utilizar técnicas de gestão de processos para melho­ rar o serviço ao cliente e reduzir o tempo de ciclo • Desenvolver e treinar o pessoal do cliente para ser empreendedor e inovador, a fim de encontrar ma­ neiras de melhorar o serviço ao cliente • Implementar melhorias para que a organização possa qualificar-se como um fornecedor ISO 9000

Estratégia SI

AMP tap.

S2

X

X

*eri Bc

X

X

British telecom

X

S3

S4

S5

56

Estratégias secundárias: • .Manter contato permanente com os clientes; com­ preender e antecipar as suas necessidades

S8

S9

S10

X

X

X

X

Aseo, Brown,

X X

Chrysler Corp.

X

CocoColo Corninfl

Eastman Kodak

X X X

Eaten Corp.

Fidelity Investment

X

X

X

Ford Motor Co.

Fujitsu Systems

X

X

X

X X

General /.Sotors Holiday Inns

IBM Rochester

X

ICLPk

Johnson Controls

X

X

X

X

X

X

X X

New York Life

X

X

Pratt and Whitney

X

Procter & Gamble

X

X

X

X X

VF Corp. Xerox Corp.

X

X

New England Cap.

lhe Forum Corp.

X

X

Motorola

Também existem estratégias secundárias que, no longo prazo, focam nas operações e na lucratividade. Estratégias secundárias comuns são mostradas a seguir e a Tabela 20-9 identifica estratégias secundárias de melho­ ria pelas empresas listadas.

S7

X

X

filter PEGEIS, C Cod Total quo&y 1995.

Danve^S MA Boyd & tra$ef.

663

GERENCIAMENTO DA QUALIDADE

na Tabela 20-10 são um esboço. É simplesmente uma fo­ tografia de um número limitado de melhorias quantita­ tivas de desempenho que foram realizadas por empresas como parte de seus programas de gestão de qualidade total. Um resultado digno de nota é a redução da Ford

TABELA 20-10 Ilustrações resumidas das melhorias quantificadas alcançadas AMP Entregas no prazo melhoradas de 65% para 95% e produtos AMP possuem disponibilidade nacional dentro de três dias ou menos em 50% das vendas da AMP.

Aseo, Brown, Boveri. Cada meta de melhoria a qual os clientes solicitaram - melhor entrega, responsividade na qualidade, e assim por diante - foi atendida.

em homens-horas para construir um veículo de 15 para 7,25. Embora isso tenha levado dez anos para acontecer, ainda é um excelente exemplo de melhoria da produti­ vidade. Na IBM de Rochester, Minnesota, a redução de defeitos por milhão por um fator de 32 ao longo de um período de quatro anos também é notável. E a capacidade da Chry sler e da General Motors de reduzir os tempos de desenvolvimento de design para os veículos novos de 60 e 48 meses para os atuais 33 e 34 meses, respectivamente, é uma conquista que indica o retorno da competitividade para a indústria automobilística dos Estados Unidos. 20.19 DICAS DE ESTUDO PARA 0 EXAME DE CERTIFICACÃO EM GERENCIAMENTO DE PROJETOS PMP

Chrysler. Novos veículos agora estào sendo desenvolvidos em 33 meses versus quase 60 meses há dez anos atrás. Eaton. Aumento nas vendas por empregado de $ 65.000 em 1983 para quase $ 100.000 em 1992.

Fidelity Lida com 200.000 chamadas de informação em quatro centrais telefônicas; 1.200 representantes lidam com 75.000 chamadas, e o equilíbrio é automatizado. Ford. Utilização de 7,25 homens-horas de mão de obra por veículo versus 15 homens-horas em 1980; os parachoques do Ford Taurus utilizam 10 peças comparados às 100 peças dos carros similares da GM.

General Motors Novos veículos agora são desenvolvidos em 34 meses versus os 48 meses durante a década de 1980. IBM Rochester As taxas de defeitos por milhão são 32 vezes menores do que há quatro anos atrás e em alguns produtos, excede o seis sigma (3,4 defeitos por milhão). Pratt & Whitney. A taxa de defeitos por milhão foi diminuída pela metade; um processo de ferramental foi reduzido de dois meses para dois dias; o lempo de espera das peças foi reduzido em 43%. VF Corp. O sistema de resposta do mercado permite uma taxa de estoque de 97% para as lojas de varejo comparadas com 70% da média do setor.

NCR. O terminal do caixa foi projetado em 22 meses versus 44 meses e continha 85% menos peças do que o seu antecessor. AT&T.O redesenho de um computador com central telefônica em 18 meses versus 36 meses; defeitos de fabricação reduzidos em 87%. Deere & Co. Tempo de cido de alguns de seus produtos reduzido em até 60%, economizando 30% dos custos normais de desenvolvimento. Forte: PEGELS, C. Carl. Total quolty management (Danvers, MA: Boyd & Froser,

1995|, p. 27.

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 da Qualidade 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®: • Contribuições dos pioneiros da qualidade • Conceito de gestão da qualidade total (TQM) • Diferenças entre o planejamento da qualidade, a garantia da qualidade e o controle da qualidade • Importância da auditoria da qualidade • Ferramentas de controle de qualidade • Conceito de custo da qualidade As seguintes questões de múltipla escolha ajudarão na revisão dos conceitos deste capítulo: 1. Qual das seguintes alternativas nào faz parte da opinião geralmente aceita hoje sobre qualidade? a. Os defeitos devem ser ressaltados e trazidos à superfície b. Podemos inspecionar a qualidade c. A melhoria da qualidade economiza dinheiro e aumenta o negócio d. A qualidade é focada no cliente 2. Na visão atual sobre qualidade, quem define a qua­ lidade? a. alta administração do fornecedor b. O gerenciamento de projetos c. Os trabalhadores d. Os clientes 3. Qual das seguintes representam ferramentas de controle da qualidade? a. Tabelas de amostragem b. Gráficos de processos c. Técnicas estatísticas e matemáticas d. Todas as anteriores

664

Gerenciamento de Projetos

4.

5.

6.

7.

8.

9.

10.

11.

Qual das seguintes alternativas c verdadeira sobre o gerenciamento moderno da qualidade? a. A qualidade ê definida pelo cliente b. A qualidade se tomou uma arma competitiva c. A qualidade é agora parte integrante do pla­ nejamento estratégico d. Todas são verdadeiras Uma empresa dedicada à qualidade geralmente fornece treinamento para: a. A alta administração e os gerentes dc projetos b. Os trabalhadores horistas c. Os trabalhadores assalariados d. Todos os trabalhadores Qual dos seguintes gurus da qualidade acreditam que o “zero defeito” é atingível? a. Deming b. Juran c. Crosby d. Todos os citados Quais são os componentes da trilogia de Juran? a. Melhoria da Qualidade, Planejamento da Qua­ lidade e Controle da Qualidade b. Melhoria da Qualidade, Zero Defeito e Con­ trole da Qualidade c. Melhoria da Qualidade, Planejamento da Qualidade c Gráficos PERT d. Melhoria da Qualidade, Inspeções da Quali­ dade e Controle da Qualidade Qual das seguintes alternativas nào representa um dos Quatro Absolutos da Qualidade dc Crosby? a. Qualidade significa conformidade aos requisitos b. Qualidade vem da prevenção c. Qualidade é medida pelo custo de conformidade d. Qualidade significa que o desempenho padrào é “zero defeito” De acordo com Deming, qual percentual dos cus­ tos da qualidade é geralmente atribuível à gerência? a. 100% b. 85% c. 55% d. 15% A inspeção: a. É uma forma adequada de garantir a qualidade b. É cara e demorada c. Reduz o retrabalho c os custos gerais d. É sempre eficaz em impedir que produtos de­ feituosos alcancem o cliente As filosofias do Método Taguchi se concentram em melhorar a qualidade durante a: a. Fase Conceituai b. Fase de Projeto c. Fase de Implementação d. Fase de Encerramento

12.

13.

14.

15.

16.

17.

18.

19.

Uma declaração bem escrita dc política sobre a qualidade: a. Será uma declaração de como, nào do quê ou do porquê b. Promoverá a coerência por toda a organiza­ ção e por todos os projetos c. Fornecerá uma explicação de como os clien­ tes veem a qualidade em suas próprias organizações d. Fornecerá disposições para a alteração da po­ lítica apenas em uma base anual A garantia da qualidade inclui: a. A identificação dos objetivos c normas b. A realização de auditorias da qualidade c. O planejamento para a coleta contínua de dados d. Iodas as anteriores Qual é a ordem das quatro etapas do Ciclo de De­ ming para a Melhoria Contínua? a. Planejar, Fazer, Verificar e Agir b. Fazer, Planejar, Agir c Verificar c. Verificar, Fazer, Agir c Planejar d. Agir, Verificar, Fazer e Planejar As auditorias da qualidade: a. Sào desnecessárias se você fizer isso logo na primeira vez b. Devem ser realizadas diariamente para cada processo c. Sào caras e, portanto, nào vale a pena fazer d. Sào necessárias para a validação de que a políti ca de qualidade está sendo seguida e respeitada Qual das seguintes alternativas sào ferramentas comuns do controle estatístico de processo? a. Análise de Pareto b. Análise de causa e efeito c. Gráficos de controle de processo d. Todas as anteriores Qual dos métodos a seguir é mais adequado para identificar os “poucos contribuintes vitais?" a. Análise dc Pareto b. Análise dc causa c efeito c. Análise das tendências d. Gráficos de controle de processo Quando um processo é idealmente configurado, os limites superior e inferior dc especificação gcralmente sào: a. Definidos igual ao limite superior e inferior dc controle b. Definidos fora dos limites superior c inferior de controle c. Definidos dentro do limite superior e inferior de controle d. Definidos a uma distância igual a partir do valor da média Os limites superior e inferior de controle são ge­ ralmente definidos: a. A um desvio padrão da média em cada sentido b. A 3a (três sigma) da média em cada sentido

665

GERENCIAMENTO DA QUALIDADE

20.

c. Fora dos limites superior e inferior de espe­ cificação d. Para detectar e sinalizar quando um processo pode estar fora de controle Qual das seguintes alternativas não é indicativo da visão atual sobre o processo dc gerenciamento da qualidade aplicado a um determinado projeto? a. Os defeitos devem ser ressaltados e trazidos à superfície b. A responsabilidade pela qualidade está princi­ palmente com a alta gerência ou com o patro­ cinador. mas todos devem estar envolvidos c. Qualidade economiza dinheiro d. A identificação do problema leva a soluções cooperativas

21.

Sc os valores gerados a partir de um processo são normalmente distribuídos em torno do valor da média, qual a percentagem de pontos de dados gerados pelo processo que não cairá dentro de mais ou menos três desvios padrão da média? a. 99,7% b. 95,4% G 683% d. 0,3%

RESPOSTAS 1. B I2.B

2. D 13.D

3. D

4 D 5. D

14.A

15.D

6. C

16. D

7. A

17.A

B.C

9. B

10. B

II B

18. B

I9.B

20.B

21.D

21 DESENVOLVIMENTOS MODERNOS EM GERENCIAMENTO DE PROJETOS

Estudos de Coso Relacionados (de tenet/Project Livro de Exercícios Relacionado (de tenet/Project Management Workbook and PMP /UPM' Exam Study Guide, 11. ed.) Management Cose Studies, 4. ed.)

Guio PMBOK3 - 5. ed., Secõo de Referendo poro o Exame de Certificação PMP

• • • •

• Nenhuno Reference

Ides Automotive Fems Heolíxofe, inc. Clock Faucet Company Honecker Corporation *

• fsido dt caso

21.0

• Project Management Maturity Questonroire . Mjlnpie Choke Exam

«oeca/ vrte oo M do coprfdo.

INTRODUÇÃO

Conforme mais setores acei­ tam o gerenciamento de pro­ (1.2 c 3 do PMBOK jetos como caminho, a mu­ dança nas práticas de gerenciamento de projetos ocorrem a um ritmo espantoso. Mas o que é ainda mais importante é o fato de que essas empresas estão compartilhando suas conquistas com outras empresas durante atividades de Guia PMBOK5. ed.

benchmarking. Oito áreas de interesse recente estão incluídas neste capítulo:

• O modelo de maturidade de gerenciamento de projetos (PMMM)vri • O desenvolvimento de documentação processual eficaz • As metodologias de gerenciamento de projetos • A melhoria contínua

• O planejamento da capacidade

Da expressão em inglês. Project Management Maturity Model (PMMM).

• Os modelos de competência • O gerenciamento de vários projetos • As reuniões de revisão de final de fase 21.1

0 MODELO DE MATURIDADE

EM GERENCIAMENTO DE PROJETOS (PMMM)

Todas as empresas desejam a excelência no gerenciamen­ to de projetos. Infelizmente, nem todas elas reconhecem que o prazo pode ser encurtado por meio da realização de planejamento estratégico para o gerenciamento de pro­ jetos. A simples utilização de gerenciamento dc projetos, mesmo que por um longo período de tempo, não conduz à excelência. F.m vez disso, pode resultar em erros repeti­ tivos e, o que é pior, aprender com seus próprios erros e não com os erros dos outros. O planejamento estratégico para o gerenciamento de projetos é diferente de outras formas de planejamento estratégico na medida em que é mais frequentemente rea­ lizado no nível médio de gestão, e não pelos executivos. Os executivos ainda são envolvidos, principal mente em um papel de apoio, e proveem o financiamento em con­ junto com a liberação do tempo do empregado para o

668

Gerenciamento de Projetos

esforço. O envolvimento dos executivos será necessário para garantir que o que for recomendado pela média ge­ rência não resulte em mudanças indesejadas para a cul­ tura corporativa. As organizações tendem a realizar um planejamento estratégico para novos produtos e serviços por meio da disposição de um plano bem pensado e, então, executá-lo com a precisão de um cirurgião. Infelizmente, o planeja­ mento estratégico para o gerenciamento de projetos, se for realizado de alguma forma, é feito na base da prova de fogo. No entanto, existem modelos que podem ser utilizados para auxiliar as corporações na realização do planejamento estratégico de gerenciamento de projetos e no alcance da maturidade e excelência em um período razoável de tempo.

A base para alcançar a excelência em gerenciamento de projetos pode ser mais bem descrita como o modelo de maturidade de gerenciamento de projetos (PMMM), que é composto de cinco níveis, como mostrado na Figura 21-1. Cada um dos cinco níveis representa um grau diferente de maturidade em gerenciamento de projetos.

gerenciamento de projetos podem ser aplicados a outras metodologias empregadas pela empresa, bem como apoiá-las.

• Nível 3 - Metodologia Singular: nesse nível, a or­ ganização reconhece o efeito sinérgico da combi­ nação de todas as metodologias corporativas em uma metodologia singular, no centro da qual está

o gerenciamento de projetos. Os efeitos sinérgicos também tornam o processo de controle mais facil com uma metodologia única do que com várias metodologias. • Nível 4 - Benchmarking: esse nível contém o re­ conhecimento de que é necessária a melhoria do processo para manter uma vantagem competitiva. O benchmarking deve ser realizado de forma con­ tínua. A empresa deve decidir de quem e do quê

realizar o benchmarking. • Nível 5 - Melhoria Contínua: nesse nível, a orga­

nização avalia as informações obtidas por meio da análise comparativa e deve, então, decidir se essas informações irão ou não melhorar a metodologia singular.

Quando falamos de níveis de maturidade (e até mes­ mo das fases do ciclo de vida), existe uma descrença co­ mum de que todo o trabalho deve ser realizado sequen­ cialmente (ou seja, em série). Isso nào é necessariamente verdade. Determinados níveis podem e sobrepõem-se. A magnitude da sobreposição é baseada na quantidade de risco que a organização está disposta a tolerar. Por exemplo, uma empresa pode iniciar o desenvolvimento de listas de verificação de gerenciamento de projetos para apoiar a metodologia ao mesmo tempo em que ainda fornece treinamento em gerenciamento de projetos para a força de trabalho. Uma empresa pode criar um centro FIGURA 21-1

O$ cinco níveis de maturídode.

• Nível 1 - Linguagem Comum: nesse nível, a orga­ nização reconhece a importância do gerenciamen­ to de projetos e a necessidade de uma boa compre­ ensão do conhecimento básico em gerenciamento de projetos, juntamente com a linguagem/terminologia que o acompanha. • Nível 2 - Processos Comuns: nesse nível, a or­ ganização reconhece que precisam ser definidos e desenvolvidos processos comuns de forma que os êxitos em um projeto possam ser repetidos em outros projetos. Nesse nível também está inclu­ ído o reconhecimento de que os princípios de

de excelência em gerenciamento de projetos antes que o benchmarking seja realizado.

Apesar de ocorrer sobreposição, a ordem na qual as fases são concluídas não pode mudar. Por exemplo, ape­

sar de os níveis 1 e 2 poderem se sobrepor, o Nível 1 ainda deve ser concluído antes do Nível 2. A sobreposição de vá­ rios níveis pode ocorrer, como mostrado na Figura 21-2. • Sobreposição do Nível 1 e do Nível 2: ocorrerá porque a organização pode começar o desenvolvi­ mento de processos de gerenciamento de projetos ainda enquanto os refinamentos estiverem sen­ do feitos para a linguagem comum, ou durante o treinamento.

669

DESENVOLVIMENTOS MODERNOS EM GERENCIAMENTO DE PROJETOS

O Nível 2 e o Nível 3 geralmente não se sobrepõem. Pode ser possível começar parte do trabalho do Nível 3 antes que o Nível 2 esteja concluído, mas isso é altamente improvável. Uma vez que uma empresa está comprome­ tida com uma metodologia singular, o trabalho em outras metodologias geralmente termina. Além disso, as empre­ sas podem criar um Centro de Excelência em gerencia­ mento de projetos no início do processo do ciclo de vida, mas não receberão todos os benefícios até mais tarde. Os riscos podem ser atribuídos a cada nível do PMMM. Para simplificar, os riscos podem ser rotulados como baixo, médio e alto. O nível de risco é mais fre­ quentemente associado com o impacto na cultura cor­ porativa. As seguintes definições podem ser atribuídas a esses três riscos:

FIGURA 21-2

Níveis de sobreposição.

• Sobreposição do Nível 3 e do Nível 4: ocorre por­ que, enquanto a organização está desenvolvendo uma metodologia singular, os planos estão sen­ do realizados quanto ao processo de melhoria da metodologia. • Sobreposição do Nível 4 e do Nível 5: conforme a organização se toma mais e mais comprometida com o benchmarking e com a melhoria contínua, a velocidade com a qual o organização deseja que as mudanças sejam feitas pode levar esses dois níveis a uma sobreposição significativa. O feedback do Nível 5 de volta ao nível 4 e ao nível 3, conforme mostra­ do na Figura 21-3, implica que esses três níveis for­ mam um ciclo de melhoria contínua, e pode até ser possível que todos esses três níveis se sobreponham.

• Risco Baixo: praticamente nenhum impacto na cultura corporativa, ou a cultura corporativa é di­ nâmica e prontamente aceita a mudança. • Risco Médio: a organização reconhece que a mu­ dança é necessária, mas pode não estar ciente do impacto da mudança. A subordinação a vários chefes seria um exemplo de um risco médio. • Risco Alto: os riscos altos ocorrem quando a or­ ganização reconhece que as mudanças resultantes da implementação do gerenciamento de projetos causarão uma mudança na cultura corporativa. Exemplos incluem a criação de metodologias, po­ líticas e procedimentos de gerenciamento de pro­ jetos, bem como a descentralização da autoridade e da tomada de decisões.

O nível 3 tem o maior risco e grau de dificuldade para a organização. Isso é mostrado na Figura 21-4. Uma vez que uma organização está comprometida com o nível 3, o tempo e o esforço necessários para atingir os níveis mais elevados de maturidade têm um baixo grau de di­ ficuldade. Alcançar o Nível 3, no entanto, pode requerer uma grande mudança na cultura corporativa.

F-l

1

________________

1

bnjxçerr cwn

Mérfo

2

Pkxksos (omzs

Vele

3

Vetoddoçia srgjia

Mo

4 5

FIGURA 21-3 Feedback

entre os cinco níveis de maturidade.

fauá?

Descíçõo

FIGURA 21-4

Bcao

MeForc cortino

Boao

Graus de dificuldade dos cinco níveis de maturidade.

670

Gerenciamento de Projetos

Esses tipos de modelos de maturidade se tornarão mais comuns no futuro, com modelos genéricos sendo adaptados para cada empresa. Esses modelos vão ajudar a administração na realização do planejamento estratégico para a excelência no gerenciamento de projetos. 21.2 DESENVOLVIMENTO DE UMA DOCUMENTAÇÃO

PROCESSUAL EFICAZ

Uma boa documentação processual irá acelerar o pro­ cesso de maturidade do gerenciamento de projetos, pro­ mover o apoio em todos os níveis de gestão e melhorar significativamente as comunicações do projeto. O tipo de documentação processual escolhido é fortemente in­ clinado para se queremos gerenciar formal ou informal­ mente, mas deve mostrar como conduzir as atividades orientadas aos projetos e como comunicar-se em um am­ biente tão multidimensional. As políticas, procedimen­ tos, formulários e diretrizes de gerenciamento de pro­ jetos podem fornecer algumas dessas ferramentas para o delineamento do processo, bem como um formato para a coleta, processamento e comunicação dos dados rela­ cionados ao projeto em um formato organizado e padro­ nizado. O planejamento e o acompanhamento do proje­ to, no entanto, envolvem mais do que apenas a geração de papelada. Eles exigem a participação de toda a equipe do projeto, incluindo os departamentos de apoio, subcontratados e a alta administração, e esse envolvimento promo­ ve a unidade. Os documentos processuais ajudam a: • • • • • • • • • • • • •

Fornecer diretrizes e uniformidade Incentivar documentação útil, mas mínima Comunicar as informações de forma clara e eficaz Padronizar os formatos dos dados Unificar as equipes de projetos Fornecer uma base para a análise Garantir o entendimento dos documentos para re­ ferência futura Renovar os compromissos Diminuir a papelada Diminuir conflito e confusão Delinear os pacotes de trabalho Trazer novos membros de equipe Construir uma experiência de acompanhamento e método para projetos futuros

Feito de forma adequada, o processo de planejamen­ to do projeto deve envolver tanto a organização executora quanto a organização cliente. Isso leva à visibilidade do projeto em vários níveis organizacionais e estimula o in­ teresse no projeto e o desejo de sucesso.

Os Desafios

Mesmo que os documentos processuais possam for­ necer todos esses benefícios, a gerência, muitas vezes, é relutante em implementar ou apoiar plenamente um sistema formal de gerenciamento de projetos. As preo­ cupações da gerência frequentemente giram em torno de quatro temas: os encargos de overhead, atrasos na iniciali­ zação, criatividade sufocada e redução do controle da for­ ça própria. Primeiro, a introdução de maior formalidade organizacional por meio de políticas, procedimentos e formulários pode custar dinheiro, e o financiamento adi­ cional pode ser necessário para apoiar e manter o sistema. Segundo, o sistema é visto como a causa de atrasos na inicialização, exigindo definição adicional do projeto an­ tes que a implementação possa começar. Terceiro e quar­ to, o sistema é frequentemente visto como um sufoco à criatividade e como transferência do controle do projeto do indivíduo responsável para um processo impessoal. O comentário de um gerente de projetos pode ser comum: “Meu pessoal de apoio acha que gastamos muito tempo planejando um projeto antecipadamente; isso cria um ambiente muito rígido que sufoca a inovação. O único objetivo parece ser a definição de uma base para controles contra medidas ultrapassadas e para a punição, em vez de ajuda, no caso de uma contingência”. Esse comentário ilustra a potencial utilização indevida de um sistema for­ mal de gerenciamento de projetos para estabelecer con­ troles irrealistas e sanções em caso de desvios do plano de programa, em vez de ajudar a encontrar soluções. Como Fazer Funcionar

Poucas empresas introduziram procedimentos de ge­ renciamento de projetos com facilidade. A maioria passou por problemas desde o ceticismo à sabotagem do sistema processual. Muitas usam abordagens incrementais para de­ senvolver e implementar sua metodologia de gerenciamen­ to de projetos. Fazer isso, porém, é um desafio multifacetado para a administração. O problema é raramente de compre­ ensão das técnicas envolvidas, tais como o orçamento e o cronograma, mas um problema de envolvimento da equipe de projetos no processo, obtendo a sua contribuição, apoio e compromisso, e estabelecendo um ambiente de apoio.

As diretrizes e formulários processuais de uma meto­ dologia de gerenciamento de projetos estabelecida podem ser especialmente úteis durante a fase de planejamento/ definição do projeto. Não só a metodologia de gerencia­ mento de projetos ajuda a delinear e comunicar os qua­ tro grandes conjuntos de variáveis para a organização e o gerenciamento do projeto — (I) tarefas, (2) prazo (3), recursos e (4) responsabilidades mas também ajuda a definir marcos mensuráveis, bem como requisitos de re­ latório e de revisão. Isso fornece ao pessoal do projeto a

DESENVOLVIMENTOS MODERNOS EM GERENCIAMENTO DE PROJETOS

capacidade de medir o andamento e o desempenho do projeto e provê os insumos essenciais para o controle do projeto rumo aos resultados desejados.

O desenvolvimento de uma metodologia eficaz de gerenciamentodeprojetoscompreendemaisdoqueapenasum conjunto de políticas e procedimentos. Exige a integração dessas diretrizes e normas à cultura e ao sistema de valores da organização. A gerência deve liderar os esforços globais e promover um ambiente propício ao trabalho em equi­ pe. Quanto maior for o espírito de equipe, a confiança, o compromisso e a qualidade da troca de informações entre os membros da equipe, mais será provável que a equi­ pe venha a desenvolver processos eficazes de tomada de decisões, firmar compromissos individuais e em grupo, focar na resolução de problemas e operar em um modo de controle de força própria e autocorreção. Práticas Estabelecidas

Embora os gerentes de projetos possam ter o direi­ to de estabelecer suas próprias políticas e procedimentos, muitas empresas elaboram os formulários de controle do projeto que podem ser usados de maneira uniforme em todos os projetos. Os formulários de controle do projeto servem a dois propósitos essenciais por meio do estabele­ cimento de uma estrutura comum, a partir da qual: • O gerente de projetos se comunicará com executi­ vos, gerentes funcionais, empregados funcionais e clientes • Os executivos e o gerente de projetos poderão tomar decisões significativas sobre a alocação de recursos Algumas grandes empresas com estruturas madu­ ras de gerenciamento de projetos mantêm uma unidade funcional separada para o controle de formulários. Isso é muito comum nos setores aeroespacial e de defesa, mas também está se tornando prática comum em outras in­ dústrias e em algumas empresas de menor dimensão.

As grandes empresas, com uma infinidade de pro­ jetos diferentes, não podem se dar ao luxo de controlar os projetos com três ou quatro formulários. Existem di­ ferentes formulários para planejamento, programação, controle, autorização de trabalho, e assim por diante. Não é raro que as empresas tenham de 20 a 30 formulários diferentes, cada um dependente do tipo de projeto, da duração do projeto, do valor monetário, do tipo de in­ formação ao cliente, e outros argumentos. Os gerentes de projetos muitas vezes são autorizados a criar a sua pró­ pria administração para o projeto, o que pode levar a um dano em longo prazo, se cada um elaborar seus próprios formulários de controle do projeto.

671

O melhor método para limitar o número de for­ mulários parece ser o conceito de força-tarefa, em que ambos, gerentes e executores têm a oportunidade de dar uma contribuição. Isso pode parecer um desperdício de tempo e dinheiro, mas no longo prazo oferece grandes benefícios. Para ser eficaz, as seguintes regras básicas podem ser utilizadas: • As forças-tarefa devem incluir os gerentes, bem como os executores • Os membros da força tarefa devem estar dispostos a aceitar críticas de outros colegas, superiores e, es­ pecialmente, dos subordinados que devem “convi­ ver” com esses formulários • A gerência superior deve manter um envolvimen­ to (ou acompanhamento) bastante passivo • O mínimo de assinaturas para aprovação deverá ser exigido para cada formulário • Os formulários devem ser concebidos de modo que possam ser atualizados periodicamente • Os gerentes funcionais e os gerentes de projetos devem ser dedicados e estar comprometidos com a utilização dos formulários Categorizaçõo do Amplo Espectro de Documentos

A natureza dinâmica do gerenciamento de projetos e de seu envolvimento multifuncional cria a necessidade de uma infinidade de documentos processuais para orientar um projeto por meio das várias fases e estágios de inte­ gração. Especialmente para organizações maiores, o de­ safio não é apenas fomecer diretrizes de gerenciamento para cada atividade do projeto, mas também fornecer uma estrutura processual coerente com a qual os líde­ res de projetos de todas as disciplinas possam trabalhar e comunicar-se uns com os outros. Especificamente, cada política ou procedimento deve acomodar e estar coerente as várias outras funções que fazem interface com o projeto durante o seu cido de vida. Essa complexidade de relações intrincadas é ilustrada na Figura 21-5. Uma maneira simples e eficaz de categorizar o amplo espectro de documentos processuais é a utilização do con­ ceito de divisão de trabalho, como mostrado na Figura 21-6. Assim, as principais categorias processuais são definidas ao longo das fases principais do cido de vida do projeto. Cada categoria é, então, subdividida em (1) diretrizes gerais de gestão, (2) políticas, (3) procedimentos, (4) formulários e (5) listas de verificação. Se necessário, o mesmo conceito pode ser levado um passo adiante para desenvolver políticas, procedimentos, formulários e listas de verificação para os vá­ rios subníveis de operação fúndonais e do projeto. Embora isso possa ser necessário para os programas muito grandes,

672

Gerenciamento de Projetos

mais flexibilidade. Infelizmente, isso leva tempo porque os executivos devem confiar na capacidade de a metodologia de gerenciamento de projetos funcionar sem os rígidos controles previstos pelas políticas e procedimentos. Além disso, todas as empresas parecem passar por estágios evo­ lutivos das políticas e procedimentos antes de chegarem às diretrizes, aos formulários e às listas de verificação. 21.3

METODOLOGIAS DE GERENCIAMENTO

DE PROJETOS

O propósito final de qualquer sistema de gerenciamento de projetos é aumentar a probabilidade de que sua organização tenha um fluxo contínuo de projetos gerenciados com sucesso. A melhor forma de alcançar esse objetivo é por meio de boas metodologias de gerenciamento de projetos que sejam base­ adas em diretrizes e formulários, em vez de políticas e proce­ dimentos. As metodologias devem ter flexibilidade suficiente para que possam ser facilmente adaptadas a cada projeto. FIGURA 21-5

Inler-relocionamenio dos atividades do projeto com

os vários níveis funcionais/organizacionois e de gerenciamento do projeto.

um esforço deve ser feito para diminuir a “sobreposição” de políticas e procedimentos a fim de evitar novos problemas e custos. Para a maioria dos projetos, um documento único abrange todos os níveis das operações do projeto. À medida que amadurecemos...

Conforme as empresas se tornam mais maduras na execução da metodologia de gerenciamento de projetos, as políticas e procedimentos de gerenciamento de projetos são desconsiderados e substituídos por diretrizes, formu­ lários e listas de verificação. O gerente de projetos possui

FIGURA 21-6

As metodologias devem ser concebidas para apoiar a cultura corporativa e não vice-versa. Ê um erro fatal com­ prar um pacote de uma metodologia enlatada que obrigue você a mudar sua cultura corporativa para apoiá-la. Se a metodologia não oferece apoio à cultura, ela não será acei­ ta. O que converte qualquer metodologia em uma metodo­ logia de nível internacional é a sua adaptabilidade à cultura corporativa. Não há nenhuma razão para que as empresas nào possam desenvolver sua própria metodologia. Empre­ sas como a Compaq Services, Ericsson, Nortel Networks, Johnson Controls e Motorola sào consideradas detentoras de metodologias de nível internacional para gerenciamen­ to de projetos e, em cada caso, a metodologia foi desenvol­ vida intemamente. O desenvolvimento da sua própria me­ todologia internamente, para garantir um ajuste à cultura corporativa, geralmente proporciona um retomo sobre o

Cotegorizoçôo de documentos processuais em umo estrutura analítica de projeto.

673

DESENVOLVIMENTOS MODERNOS EM GERENCIAMENTO DE PROJETOS

investimento muito maior do que a aquisição de pacotes enlatados que exigem mudanças massivas. 21.4

MELHORIA CONTÍNUA

Muitas vezes a complacência dita o processo decisório. Isso é particularmente verdade em organizações que atin­ giram certo grau de excelência em gerenciamento de pro­ jetos, tornaram-se complacentes e, em seguida, percebe­ ram tarde demais que perderam a vantagem competitiva. Isso ocorre quando as organizações deixam de reconhe­ cer a importância da melhoria contínua. A Figura 21 -7 ilustra o porquê de existir uma necessi­ dade de melhoria contínua. Conforme as empresas come­ çam a amadurecer em gerenciamento de projetos e a atingir certo grau de excelência, atingem uma vantagem competi­ tiva sustentada. A vantagem competitiva sustentada pode muito bem ser o objetivo singular estratégico mais impor­ tante da empresa. A empresa, então, iniciará a exploração de sua vantagem competitiva sustentada.

FIGURA 21-7

PLANEJAMENTO DA CAPACIDADE

Conforme as empresas se tornam excelentes em gerencia­ mento de projetos, os benefícios da realização de mais tra­ balho em menos tempo e com menos recursos se tornam aparentes. A questão, é claro, é quanto trabalho a mais a organização pode assumir? As empresas estão agora se es­ forçando para desenvolver modelos de planejamento da capacidade para ver o quanto de novos trabalhos pode ser realizado dentro das restrições existentes, humanas e nào humanas. A Figura 21-9 ilustra a forma clássica na qual as empresas realizam o planejamento da capacidade. A abordagem descrita nesta figura é válida tanto para or­ ganizações orientadas a projetos quanto para organi­ zações não orientadas a projetos. A linha do “horizonte de planejamento” indica o momento para o planejamen­ to da capacidade. As linhas “propostas” indicam a mão de obra necessária para os projetos internos aprovados ou uma porcentagem (talvez quase 100%) para todo o trabalho previsto por meio da concorrência de licitação. A combinação desta linha e da linha dos “requisitos de mão de obra”, quando comparados com a alocação atual, nos fornece uma indicação da capacidade. Essa técnica pode ser eficaz se realizada cedo o suficiente, de forma que seja permitido um tempo de treinamento para futura escassez de mão de obra.

Porque hó o necessidade de melhoria contínua.

Infelizmente, a concorrência não está sentada de braços cruzados assistindo você explorar a sua vantagem competitiva sustentada. À medida que a concorrência começa a contra-atacar, você pode perder uma grande parte de a sua vantagem competitiva sustentada, se nào toda ela. Para se manter eficaz e competitiva, a organiza­ ção deve reconhecer a necessidade de melhoria contínua, como mostrado na Figura 21 -8. A melhoria contínua per­ mite a uma empresa manter a sua vantagem competitiva, mesmo quando os concorrentes contra-atacarem.

FIGURA 21-8

21.5

A necessidade de melhoria contínua.

FIGURA 21-9

Planejamento da capacidade clássico.

A limitação desse processo para o planejamento da capacidade é que somente os recursos humanos sào considerados. Um método mais realista seria utilizar o método apresentado na Figura 21-10, que também pode ser aplicado a organizações orientadas e nào orientadas a projetos. Pela Figura 21-10, os projetos sào seleciona­ dos com base em fatores como a adequação estratégica, rentabilidade, quem é o cliente e benefícios da empresa. Os objetivos para os projetos selecionados sào definidos tanto em termos técnicos, quanto em termos de negócios porque pode haver restrições de capacidade técnica e res­ trições de negócios.

674

Gerenciamento de Projetos

A Figura 21-11 mostra o modelo de competência para a Eli Lilly. Os gerentes de projetos devem possuir competências em três grandes áreas1: • Competências científicas/técnicas ■ Competências de liderança • Competências de processos

FIGURA 21-10

Planejamento da capacidade clássico.

O passo seguinte é uma diferença fundamental entre as empresas médias e as empresas excelentes. As restrições de capacidade são identificadas a partir do somatório dos cronogramas e planos. Nas empresas excelentes, os geren­ tes de projetos se reúnem com os patrocinadores para de­ terminar o objetivo do plano, que é diferente do objetivo do projeto. O objetivo do plano é atingir o objetivo do projeto com o menor custo, menor tempo, ou pelo me­ nor risco? Normalmente, apenas um desses se aplica, ao passo que as organizações imaturas acreditam que todos os três podem ser alcançados em cada projeto. Isto, natu­ ralmente, não é realista. A última caixa na Figura 21-10 é a determinação das limitações de capacidade. Anteriormente, consideramos apenas restrições de capacidade de recursos humanos. Agora, percebemos que o caminho crítico do projeto pode ser restrito não apenas pelo tempo, mas também pela mào de obra disponível, pelas instalações, pelo fluxo de caixa e até mesmo pela tecnologia existente. É possí­

vel ter vários caminhos críticos em um projeto para além daqueles identificados pelo tempo. Cada um desses ca­ minhos críticos fornece uma dimensão diferente para os modelos de planejamento de capacidade, e cada uma dessas restrições pode nos levar a uma limitação de capa­ cidade diferente. Por exemplo, a mão de obra pode nos limitar a aceitar apenas quatro projetos adicionais. Com base nas instalações disponíveis, no entanto, nós apenas teríamos capacidade de realizar mais dois projetos e, com base na tecnologia disponível, nós poderiamos realizar apenas um novo projeto. 21.6

Rira cada uma das três grandes áreas há subdivisões ou níveis degrau. A vantagem principal de um modelo de compe­ tência é que ele permite que o departamento de treinamento desenvolva programas de treinamentos personalizados de ge­ renciamento de projetos para satisfazer os requisitos de habi­ lidades. Sem modelos de competências, a maioria dos progra­ mas de treinamento é genérica e não personalizada.

Os modelos de competência focam em habilidades especializadas a fim de auxiliar o gerente de projetos a fazer um uso mais eficiente de seu tempo. A Figura 21-12, embora argumentativa, mostra que, com o treinamento de competências especializadas, os gerentes de projetos podem aumentar a eficácia de seu tempo, por meio da redução dos ladrões de tempo e do retrabalho.

Haas

MODELOS DE COMPETÊNCIA

No século XXI, as empresas substituirão as descrições de cargos por modelos de competência. As descrições de car­ gos para gerenciamento de projetos tendem a enfatizar as entregas e as expectativas do gerente de projetos, enquan­ to os modelos de competência enfatizam as habilidades necessárias específicas para realizar as entregas.

gemoanaío de prontos

FIGURA 21-12

geieoaonerto de protelas

Principal análise de competência.

Uma descrição detalhada dos modelos de competência da Eli

Lilly e da Lricsson pode ser encontrada cm: KERZNER, 1 larold. Applied project management. New York: Wiley, 1999. p. 266-283.

DESENVOLVIMENTOS MODERNOS EM GERENCIAMENTO DE PROJETOS

675

FIGURA 21-13 Modelos de competência e treinamento.

Os modelos de competência tornam mais fácil para as empresas desenvolver um currículo completo de ge­ renciamento de projetos, em vez de um curso singular. Isso é visto na Figura 21-13. Conforme as empresas ama­ durecem no gerenciamento dos projetos e desenvolvem um modelo central de competência para toda a empresa, um currículo interno e personalizado será desenvolvido. As empresas, principalmente as grandes, acharão neces­ sário manter um especialista em arquitetura decursos em seu quadro de funcionários. 21.7

GERENCIAMENTO DE VÁRIOS PROJETOS

Conforme as organizações amadurecem no gerenciamento de projetos, há uma tendência para que uma pessoa geren­ cie vários projetos. O ímpeto inicial pode vir tanto da em­ presa patrocinadora dos projetos ou dos próprios gerentes de projetos. Há vários fatores que apoiam o gerenciamento de múltiplos projetos. Primeiro, o custo da manutenção de um gerente de projetos em tempo integral em todos os projetos pode ser proibitivo. A magnitude e os riscos de cada projeto individual ditam se será necessário uma de­ signação em tempo integral ou parcial. Designar um ge­ rente de projetos em tempo integral em uma atividade que não precisa disso é um custo por excesso de gerenciamen­ to. O excesso de gerenciamento dos projetos era considera­ do uma prática aceitável nos primórdios do gerenciamento de projetos porque tínhamos pouco conhecimento sobre como lidar com o gerenciamento dos riscos. Hoje, existem métodos para o gerenciamento dos riscos.

Segundo, os gerentes de linha estão agora compar­ tilhando a responsabilidade com os gerentes de projetos pela conclusão bem-sucedida do projeto. Os gerentes de projetos estão agora gerenciando nos níveis de modelos da EAP com os gerentes de linha aceitando a responsa­ bilidade pelos pacotes de trabalho nos níveis detalhados da EAP. Os gerentes de projetos agora gastam mais do seu tempo integrando o trabalho, em vez de planejando e programando as atividades funcionais. Com o gerente de linha aceitando mais responsabilidade, o tempo pode estar disponível para o gerente de projetos gerenciar vá­ rios projetos. Terceiro, a alta administração chegou à conclusão de que deve fornecer treinamento de alta qualidade para seus gerentes de projetos para que possam colher os be­ nefícios do gerenciamento de vários projetos. Os gerentes seniores também devem mudar a maneira como atuam como patrocinadores. Há seis grandes áreas em que a empresa como um todo pode ter de mudar para que o gerenciamento de múltiplos projetos seja bem-sucedido.

• Priorizaçào: se um sistema de priorizaçào de pro­ jetos está em vigor, ele deve ser usado corretamen­ te, de forma que a credibilidade do empregado no sistema seja percebida. Um risco é que o gerente de projetos, tendo vários projetos para gerenciar, possa favorecer os projetos que tenham priorida­ des mais altas. É possível que nenhum sistema de priorizaçào possa ser a melhor solução. Nem todo projeto precisa ser priorizado, e a priorizaçào pode ser um esforço que demanda muito tempo.

676

Gerenciamento de Projetos

• Mudanças no escopo: o gerenciamento de múlti­ plos projetos é quase impossível se os patrocina­ dores/clientes estão autorizados a fazer constantes mudanças no escopo. Ao usar o gerenciamento de múltiplos projetos, deve ser entendido que a maioria das mudanças no escopo pode ter de ser realizada por meio de projetos de melhoria e não por meio de um esforço contínuo de mudanças no escopo. Uma grande mudança de escopo em um projeto poderia limitar o tempo disponível do gerente de projetos para servir a outros projetos. Além disso, mudanças contínuas no escopo serão, quase sempre, acompanhadas de nova priorização dos projetos, um prejuízo maior para o gerencia­ mento de múltiplos projetos. • Planejamento da Capacidade: organizações que apoiam o gerenciamento de múltiplos projetos têm, geralmente, um controle apertado sobre a progra­ mação dos recursos. Como resultado, a organização deve ter conhecimento do planejamento da capa­ cidade, da teoria das restrições, do nivelamento de recursos e do planejamento de recursos limitados. • Metodologia de Projetos: as metodologias para o gerenciamento de projetos variam de políticas e procedimentos rígidos a diretrizes e listas de ve­ rificação mais informais. Ao gerenciar vários pro­ jetos, o gerente de projetos deve ter certo grau de liberdade concedida. Isso requer diretrizes, listas de verificação e formulários. Práticas formais de gerenciamento de projetos criam a exigência de documentação excessiva, minimizando, assim, as oportunidades de gerenciar vários projetos. O ta­ manho do projeto também é crítico. • Iniciação do Projeto: o gerenciamento de múl­ tiplos projetos tem ocorrido há quase 40 anos. Uma coisa que aprendemos é que pode funcionar bem, desde que os projetos estejam em fases re­ lativamente diferentes do ciclo de vida porque as demandas pelo tempo do gerente de projetos sào diferentes para cada fase do ciclo de vida. • Estruturas Organizacionais: Se o gerai te de projetos for gerenciar múltiplos projetos, então é altamente improvável que ele seja um técnico especialista em todas as áreas de todos os projetos. Consideran­ do que a responsabilidade é compartilhada com o gerente de linha, a organização provavelmente irá adotar uma estrutura matricial fraca.

vos darem “sinal verde” à continuação do projeto. Como apenas boas notícias eram apresentadas, as reuniões eram utilizadas para dar aos executivos certo grau de conforto sobre o andamento do projeto. Hoje, as reuniões de revisão de final de fase têm uma dimensão diferente. Primeiramente, os executivos não têm mais medo de cancelar projetos, especialmente se os obje­ tivos tiverem mudado, se os objetivos forem inacessíveis ou se os recursos puderem ser utilizados em outras atividades que tenham uma maior probabilidade de sucesso. Os exe­ cutivos agora passam mais tempo avaliando os riscos do futuro em vez de focaran nas realizações do passado. Uma vez que os gerentes de projetos estào ficando cada vez mais orientados ao negócio, e não orientados à parte técnica, eles devem apresentar informações sobre os riscos do negócio, reavaliação da relação custo-benefício, e quaisquer decisões de negócio que possam afetar os ob­ jetivos finais. Sendo assim, as reuniões de revisão de final de fase agora se concentram mais em decisões de negócio, em vez de em decisões técnicas. ESTUDO DE CASO

HONICKER CORPORATION Plano de Fundo

A Honicker Corporation era bem reconhecida como fabri­ cante de alta qualidade de painéis para automóveis e ca­ minhões. Embora tenha atendido principalmente a fabri­ cantes de automóveis e de caminhões dos Estados Unidos, a oportunidade de se expandir como fornecedor mundial era bastante evidente. Sua reputaçào era bem conhecida no mundo todo, mas a empresa foi atormentada, por anos, por uma liderança uhraconservadora na alta administra­ ção, que impediu o crescimento no mercado internacional.

Quando a nova diretoria assumiu, em 2009, o con­ servadorismo desapareceu. O caixa da Honicker era rico, a empresa tinha grande poder de empréstimo e linhas de crédito com as instituições financeiras, e recebia classifi­ cação de qualidade AA por sua pequena quantia de dívida corporativa. Em vez de se expandir por meio da constru­ ção de instalações de produção em vários países, a Honi­ cker decidiu ir pela via rápida, por meio da aquisição de quatro empresas ao redor do mundo: as empresas Alpha, Beta, Gamma e Delta. Cada uma das quatro empresas adquiridas atendia principalmente a sua própria área geográfica. A alta dire­ ção de cada uma das quatro unidades conhecia a cultura

21.8 REUNIÕES DE REVISÃO DE FINAL DE FASE

Por mais de 20 anos, as reuniões de revisão de final de fase eram simplesmente uma oportunidade para os executi­

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

677

DESENVOLVIMENTOS MODERNOS EM GERENCIAMENTO DE PROJETOS

em sua área geográfica e tinha uma boa reputação com seus clientes e partes interessadas locais. A decisão toma­ da pela Honicker foi deixar as diretorias de cada empre­ sa intacta, desde que as mudanças necessárias, conforme estabelecido pela empresa, pudessem ser implementadas. A Honicker queria que cada unidade tivesse capa­ cidade de produção para fornecer peças para qualquer cliente mundial. Mas isso era mais fácil dizer do que fa­ zer. A Honicker tinha uma metodologia empresarial de gerenciamento de projetos (EPM) que funcionava bem. /X corporação entendia de gerenciamento de projetos, assim como a maioria dos clientes e partes interessadas, nos Estados Unidos. A Honicker reconheceu que o maior desafio seria fazer com que todas as divisões atingissem o mesmo nível de maturidade em gerenciamento de proje­ tos» e utilizassem o mesmo sistema de EPiM ou uma versão modificada do mesmo em nível corporativo. Esperava-se que cada uma das quatro empresas adquiridas precisasse que algumas fossem feitas.

As quatro divisões adquiridas estavam em diferen­ tes níveis de maturidade em gerenciamento de projetos. A Alpha tinha um sistema de EPM e acreditava que sua abordagem de gerenciamento de projetos era superior à que a Honicker estava usando. A empresa Beta estava apenas começando a aprender sobre gerenciamento de projetos, e não tinha qualquer sistema formal de EPM, embora tivesse alguns templates de gerenciamento de projetos que estavam sendo usados para reportar o status para seus clientes. As empresas Gama e Delta não tinham a menor ideia sobre gerenciamento de projetos.

Para piorar a situação, as leis em cada um dos países onde as empresas adquiridas estavam localizadas criavam outras partes interessadas que tinham de ser atendidas, e cada uma dessas partes interessadas estava em diferentes níveis de maturidade em gerenciamento de projetos. Em alguns países, as partes interessadas do governo estavam envolvidas ativamente por causa das leis trabalhistas, en­ quanto, em outros países, as partes interessadas do gover­ no eram participantes passivas a menos que leis de saúde, segurança ou meio ambiente fossem desrespeitadas. Seria sem dúvida uma tarefa formidável desenvolver um sistema EPM que pudesse satisfazer todas as empresas recém-adquiridas, seus clientes e partes interessadas. Instituindo a Equipe

/X Honicker sabia que haveria desafios significativos na obtenção de um acordo sobre o gerenciamento de pro­ jetos em um curto espaço de tempo; também sabia que nunca há aquisição entre iguais, há sempre um “senhorio” e os “inquilinos”, e a corporação era o senhorio. Mas, agir como senhorio e exercer influência no processo poderia

afastar algumas das empresas adquiridas e fazer mais mal do que bem. A abordagem da Honicker era tratar isso como um projeto, e cada empresa, juntamente com seus clientes e partes interessadas locais, seriam tratadas como partes interessadas no projeto. Utilizar práticas de geren­ ciamento de relacionamento com partes interessadas se­ ria essencial para obter um acordo sobre a abordagem de gerenciamento de projetos. zX Honicker solicitou que cada empresa alocasse três pessoas para a equipe de implementação de geren­ ciamento de projetos que seria chefiada pelo pessoal da corporação. O membro de equipe ideal, como sugerido pela Honicker, teria algum conhecimento e/ou experiên­ cia em gerenciamento de projetos, e seria autorizado pela alta administração a tomar decisões para sua empresa. Os representantes também deveríam compreender as neces­ sidades das partes interessadas de seus clientes e das par­ tes interessadas locais. A Honicker queria que se chegasse o mais rápido possível a um entendimento em que cada empresa concordaria em usar a metodologia que fosse fi­ nalmente decidida pela equipe. A alta administração de cada uma das quatro empresas enviou uma carta de entendimento para a Honicker, pro­ metendo designar o pessoal mais qualificado, e concordan­ do em utilizar a metodologia que fosse acordada. Cada uma afirmou que compreendia a importância deste projeto.

A primeira parte do projeto seria chegar a um acor­ do sobre a metodologia. A segunda parte do projeto seria convidar clientes e partes interessadas para ver a metodo­ logia e fornecer feedback. Isso era essencial, pois os clien­ tes e as partes interessadas estariam, em última instância, fazendo interface com a metodologia. Reunião de

Kickoff

/X Honicker esperava que a equipe pudesse chegar a um acordo sobre um sistema EPM global para a empresa dentro de seis meses. Mas antes do fim da reunião de kickoff, percebeu que levaria provavelmente dois anos até que um acordo sobre o sistema EPM fosse alcança­ do. V'árias questões se tornaram aparentes no primeiro encontro:

• Cada empresa tinha requisitos de tempo diferentes para o projeto. • Cada empresa via a importância do projeto de for­ ma diferente. • Cada empresa tinha sua própria cultura e queria ter certeza de que o design final tivesse um bom ajuste a essa cultura. • Cada empresa via o status e poder do gerente de projetos de forma diferente.

678

Gerenciamento de Projetos

• Apesar das cartas de entendimento, duas das em­ presas, a Gama e a Delta, não entenderam seu papel e seu relacionamento com a Honicker nesse projeto. • A Alpha queria microgerenciar o projeto, acredi­ tando que todos deveríam usar sua metodologia.

A alta administração da Honicker pediu aos seus representantes na reunião de kickoff que preparassem um memorando confidencial sobre sua opinião sobre a primeira reunião com a equipe. O pessoal da corpora­ ção preparou um memorando, incluindo os seguintes comentários: • Nem todos os representantes na reunião expres­ saram abertamente seus verdadeiros sentimentos sobre o projeto. • Ficou bastante evidente que algumas das empresas gostariam de ver o projeto falhar. • Algumas das empresas estavam com medo de que a implementação do novo sistema de EPM resul­ tasse em uma mudança de poder e autoridade. • Algumas pessoas tinham medo de que o novo sis­ tema EPM mostrasse que menos recursos eram necessários na organização funcional, causando assim uma redução de pessoa) e redução dos bô­ nus que estavam atualmente baseados no número de funcionários em grupos funcionais. • Alguns pareciam receosos de que a implementação do novo sistema pudesse causar uma mudança na cultura da empresa e nas relações de trabalho com seus clientes. • Alguns pareciam com medo de aprender um novo sistema e serem pressionados a usá-lo.

Era óbvio que essa não seria uma tarefa fácil. A Ho­ nicker teria de conhecer melhor todas as empresas e com­

preender suas necessidades e expectativas. A corporação tinha de mostrar a elas que sua opinião tinha valor, e en­ contrar maneiras de ganhar seu apoio.

PERGUNTAS

1. 2.

3. 4. 5.

6.

7.

8.

9.

10. 11. 12. 13.

Quais são as opções da I lonicker agora? O que você recomendaria que a Honicker fizesse primeiro? E se depois dc todas as tentativas, as empresas Gama e Delta se recusassem a vir a bordo? E se a empresa Alpha estiver convencida de que sua abordagem c a melhor c se recusar a ceder? E se as empresas Gama e Delta argumentarem que seus clientes e partes interessadas não aceitaram prontamente a abordagem de gerenciamento de projetos c querem lidar sozinhas com seus clientes? Sob que condições a Honicker poderia decidir se afastar c deixar que cada unidade empresarial fi­ zesse seu próprio negócio? Quão fácil ou difícil é fazer com que várias uni­ dades dispersas geograficamente concordem com a mesma cultura e metodologia? Se todas as quatro unidades estivessem dispostas a cooperar umas com as outras, quanto tempo você acha que levaria para haver um acordo sobre a aceitação do uso de um novo sistema de EPM? Quais partes interessadas podem ser poderosas e quais não são? Quais partes interessadas podem ter o poder de matar esse projeto? O que a I lonicker pode liizer para ganhar seu apoio? Se a Honicker nào puder ganhar seu apoio, então como deve gerenciar a oposição? E se todas as quatro empresas concordassem com a metodologia dc gerenciamento dc projetos c cm se­ guida algumas das partes interessadas do cliente de­ monstrassem falta de apoio no uso da metodologia?

O -NEGÓCIO” DAS MUDANÇAS NO ESCOPO

Estudos de Coso Relacionados (de Kerzner/Pro/ecf livro de Exercidos Relacionado (de fainet/Project Management Management (ase Studies, 4. ed.) Workbook and PMfAAP# bom Study Guide, 11. ed.)

• Multiple Choree Exam

. Projeto fiíue Sprtíter • (Oíwii Corporation • De/r/er Ifíerncnonal À/poft • Kemko Mcniatonng *

* fstdo de caso trwbm cpaece ooM do

22.0

Guio PMBOK - 5. ed., Seçào de Referenda paro o Exame de Certificação PMPe • • • • •

Gerenciamento de integração Gerenciamento de Escopo Gerenciamento de tempo Getencianento de Custo Gerenciamento de Portes Interessados

ccpíub.

INTRODUÇÃO

Pouquíssimos projetos sào concluídos de acordo com 5.5 Verificar o «icopo o plano original. As mu­ danças no plano resultam do aumento do conhecimento, da necessidade de competitividade ou de mudanças no gosto do cliente/consumidor. Depois que as mudanças sào feitas, quase sempre há um aumento significativo no orçamento e/ou um alongamento do cronograma. Guia PMBOK , 5. ed.

O processo de recomendação e aprovação das mu­ danças no escopo pode variar dependendo de o cliente ser ou nào interno ou externo à organização. As mudan­ ças de escopo para clientes externos têm sido vistas como uma fonte de lucratividade adicionada sobre os projetos. Anos atrás, era prática comum em alguns contratos do Departamento de Defesa oferecer um preço mais baixo para o contrato original durante a licitação para garan­ tir a concessão do contrato e, em seguida, avançar com grandes quantidades de mudanças de escopo lucrativas. Os clientes externos raramente eram informados sobre as lacunas em suas declarações de trabalho que poderíam

levar a mudanças no escopo. E, mesmo se a declaração do trabalho fosse escrita claramente, muitas vezes era intencio­ nalmente mal interpretada para buscar mudanças no esco­ po, fossem elas realmente necessárias ou nào. Para algumas empresas, as mudanças no escopo eram a principal fonte de rentabilidade corporativa. Durante a licitação, os executivos apresentavam duas questões críticas à equipe de licitaçào antes de apresentar uma oferta; (1) Qual é o nosso custo para fazer o trabalho com que estamos nos comprometen­ do? e (2) O quanto de trabalho adicional podemos forçar em mudanças no escopo, uma vez que o contrato seja adju­ dicado para nós? Muitas vezes, a resposta à segunda questão determinava a grandeza da oferta.

Para piorar ainda mais, nos primeiros anos do geren­ ciamento de projetos, o Departamento de Defesa solici­ tou que os gerentes de projetos dos fornecedores tivessem um domínio da tecnologia, em vez de um entendimento da tecnologia. Os engenheiros com pós-graduações eram designados como gerentes de projetos e seu objetivo, mui­ tas vezes, era exceder, em vez de simplesmente atender às especificações. Isso resultava em mudanças adicionais no escopo e, frequentemente, aumentava os riscos do projeto.

680

FIGURA 22-1

Gerenciamento de Projetos

Fornecedores sequenciais.

Outro problema que surgia era o efeito posterior de mudanças antecessoras no escopo em grandes pro­ jetos que envolviam vários fornecedores. Quando os fornecedores trabalham sequencialmente, como mostra­ do na Figura 22-1, uma mudança no escopo em um for­ necedor antecessor pode não ter um sério impacto sobre os fornecedores posteriores. O fornecedor B geralmente precisa do resultado do fornecedor A para começar a tra­ balhar. Se o fornecedor A inicia uma mudança de escopo, o impacto sobre fornecedor B pode ser mínimo. Se hou­ vesse um impacto sobre o fornecedor B, o cliente estaria sujeito aos custos adicionais. Mas se os fornecedores estão realizando o trabalho parcialmente ou totalmente em pa­ ralelo, como mostrado na Figura 22-2, o efeito posterior pode ser devastador. Uma decisão relativamente simples de um fornecedor antecessor de mudar a matéria-prima para uma qualidade superior ou inferior pode causar grandes mudanças nos planos do projeto e nas linhas de base dos fornecedores seguintes.

wo

FIGURA 22-2

concreto para a fundação. O fornecedor A constantemen­ te trocava informações com o fornecedor B para garantir que nenhuma mudança significativa estivesse prevista. Mas, quando o fornecedor A apresentou uma solicitação de mudança para modificar a fórmula do combustível lí­ quido para estender o alcance do foguete, o resultado foi uma grande mudança no escopo do trabalho já realizado pelo fornecedor B. A nova fórmula demandava mudanças onerosas no isolamento e nas bombas. Sendo assim, se o cliente vier a aprovar a solicitação de mudança do forne­ cedor A, então, o cliente pode precisar aprovar também as solicitações de mudança relacionadas de todos os forne­ cedores seguintes que seriam afetados pela solicitação de mudança do fornecedor A. 22.1

NECESSIDADE DE CONHECIMENTO DO NEGÓCIO

A utilização de mudanças no escopo como uma fonte dc receita tem sido uma prática aceitável para projetos financiados por clientes externos à organização. Mas, para os clientes internos, há inúmeras outras razões para mudanças no escopo, como mostrado na Figura 22-3. Para projetos internos, as mudanças no escopo devem ser segmentadas, e esse é o elo mais fraco, porque exige conhecimento do negócio, bem como conhecimento téc­ nico. Por exemplo, as mudanças no escopo não devem ser implementadas à custa da exposição ao risco de ações ju­ diciais de responsabilidade ou questões de segurança do produto. Da mesma forma, mudanças onerosas no esco­ po exclusivamente em prol do reforço da imagem ou da reputação devem ser evitadas. Além disso, as mudanças no escopo não devem ser implementadas se o período de payback para o produto for drasticamente estendido para recuperar os custos das mudanças no escopo.

------------- ►

Sobreposição de fornecedores.

Por exemplo, usando a Figura 22-2, A foi adjudicado para um contrato de desenvolvimento de um foguete de combustível líquido. O combustível líquido já havia sido formulado, testado e acordado pelo cliente. O fornecedor B foi adjudicado para um contrato de construção de um sistema de abastecimento e armazenamento local de lan­ çamento, com base na fórmula acordada. O fornecedor B começou a elaboração dos planos para a construção do sistema de abastecimento e também começou a despejar

FIGURA 22-3

Fatores a considerar para mudanças no escopo.

As mudanças de escopo devem ser baseadas em um fundamento sólido de negócio. Infelizmente, esse nem sempre foi o caso porque existia uma diferença entre ge­ renciamento de projetos e de programas. Historicamente,

O “NEGÓCIO" DAS MUDANÇAS NO ESCOPO

681

os gerentes de projetos eram responsáveis pelo desenvol­ vimento do produto e de suas características associadas. As mudanças no escopo, muitas vezes, eram iniciadas pe­ los gerentes de projetos com base em valor técnico, em detrimento do valor de negócio. Por exemplo, o desenvol­ vimento de um produto de alta qualidade pode parecer bom no momento, mas deve haver clientes dispostos a pagar o preço mais alto. Era muito comum os gerentes de projetos fazerem mudanças no escopo que não eram bem ajustadas aos objetivos de marketing. O resultado, mui­ tas vezes, era um produto que ninguém queria ou podia comprar.

Outro fator crítico que envolve o momento certo é saber se as mudanças no escopo são radicais. Mudanças ra­ dicais no escopo demandam ou um grande avanço na tec­ nologia ou o design de uma plataforma inteiramente nova. Por exemplo, um concorrente lança um novo produto que pode fazer com que o mercado veja o seu produto como obsoleto. Para permanecer competitivo ou para ultrapas­ sar a concorrência, você pode precisar considerar mudan­ ças radicais no escopo. As mudanças radicais no escopo se concentram mais na criatividade do que na execuçào. Esse tipo de mudança pode exigir um grande avanço na tecno­ logia associado a um vasto consumo de recursos.

Uma vez que o produto fosse desenvolvido, ele se­ ria entregue a um gerente de programas para comercia­ lização, marketing e vendas. Os gerentes de programas, funcionando como gerentes de linha de produtos, toma­ riam todas as decisões relacionadas ao negócio, incluindo a autorização de todas as mudanças caras no escopo. Os gerentes de projetos eram profissionais orientados tecni­ camente, enquanto os gerentes de programas eram quali­ ficados em marketing e vendas.

Outra questão sobre o momento certo é se as mudan­ ças no escopo devem ser realizadas de forma incrementai ou agrupadas e aprovadas junto aos projetos de melhoria. As mudanças incrementais no escopo sào, muitas vezes, chamadas de scope creep. Elas podem ser feitas rapidamen­ te e com um custo relativamente baixo. No entanto, se hou­ ver um número significativo de mudanças incrementais no escopo, tais como no caso do scope creep sem fim, o crono­ grama do projeto pode ser alongado.

Hoje, os gerentes de projetos devem tomar decisões firmes de negócio, em vez de apenas decisões de projeto ou técnicas. Mas não faz muito tempo que as empresas eram céticas quanto ao gerenciamento de projetos poder beneficiar a empresa como um todo. As empresas estão lentamente percebendo que estão administrando seus ne­ gócios por projetos. Os gerentes de projetos devem tomar decisões sólidas de negócio em vez de apenas decisões do projeto, e isso inclui a decisão sobre mudanças no escopo.

Como um exemplo da diferença entre as mudanças incrementais no escopo e projetos de melhoria, e os riscos que o acompanham, considere a construção do Aeroporto Internacional de Denver. Quando a construção do aeropor­ to estava praticamente concluída, a United Airlines ainda nào tinha assinado um contrato de arrendamento. Antes de finalmente fazê-lo, a United Airlines solicitou mudanças sig­ nificativas no sistema de manipulação de bagagem. O aero­ porto poderia ter sido inaugurado e as mudanças feitas aos poucos. Mas nào havia a informação de qual impacto estas mudanças poderiam ter sobre o serviço, a manipulação de bagagem e a segurança dos passageiros. A decisão foi tomada para tratar as mudanças no escopo como mudanças impor­ tantes de melhoria, mantendo, assim, o aeroporto fechado até que todas as alterações fossem feitas. O resultado foi qua­ se dois anos de desvio no cronograma e um sobrecusto de quase $ 2 bilhões. De uma perspectiva de segurança, a deci­ são pode ter sido correta. Hoje, o Aeroporto Internacional de Denver é visto como um sucesso.

22.2

0 MOMENTO CERTO PARA MUDANÇAS

NO ESCOPO

Todo mundo parece entender que quanto mais avança­ mos pelas fases do ciclo de vida do projeto, mais caras sào as mudanças no escopo. À medida que progredimos pe­ las fases do ciclo de vida, mais variáveis sào introduzidas no sistema, de modo que o impacto financeiro de uma pequena mudança no escopo pode ser bastante grande, em virtude dos custos envolvidos na reversão de decisões anteriores. Fazer mudanças no escopo da produção fica mais caro do que as mudanças no escopo do desenvolvi­ mento de tecnologia.

Para o desenvolvimento de novos produtos, podem ser necessárias quase 60 idéias para desenvolver um novo produto de sucesso. Cada ideia pode sofrer várias mu­ danças no escopo antes que seja oficialmente abandona­ da. Quaisquer mudanças no escopo, feitas após os gastos de capital serem comprometidos, podem ter um impacto significativo no custo total e no cronograma.

Outro exemplo comum de projetos de melhoria ocorre na tecnologia da informação (TI). Um gerente de projetos de ’EI era responsável pelo desenvolvimento e im­ plementação de um pacote de TI para controle de inven­ tário para as oito fábricas da empresa. A equipe do projeto incluía um representante de cada uma das fábricas. Os re­ presentantes foram informados de que deveríam traba­ lhar em conjunto e articular claramente os seus requisitos no início do projeto e que nenhuma mudança no escopo seria permitida uma vez concluída a declaração do esco­ po. Logo que o projeto fosse iniciado, todas as solicitações

682

Gerenciamento de Projetos

de mudança no escopo seriam realizadas em algum mo­ mento futuro, utilizando um projeto de melhoria. A equi­ pe do projeto compreendeu as preocupações do gerente do projeto, e trabalhou diligentemente para articular os requisitos de forma clara.

Depois que o projeto estava quase 70% concluído, as fábricas ficaram preocupadas com o fato de que não tinham definido claramente os seus requisitos e que se­ riam necessárias mudanças. Sendo assim, as fábricas afir­ maram que não poderíam usar o software sem que as mudanças fossem feitas. O gerente do projeto se recusou a fazer as mudanças no escopo, porque os recursos já es­ tavam comprometidos com outro projeto, que começaria imediatamente após o atual ser concluído. A aprovação de mudanças no escopo nesse momento teria um impac­ to grave nos cronogramas dos dois projetos. O gerente do projeto manteve-se firme e recusou-se a fazer as mudanças incrementais no escopo, apesar das queixas das fóbricas. Uma vez que o projeto foi imple­ mentado, as fábricas admitiram que ainda poderíam usar o software existente e o projeto de melhoria começou quatro anos mais tarde. Essa abordagem funcionou bem para o gerente do projeto, mas nem todos os projetos têm o mesmo resultado. 22.3

A NECESSIDADE DO NEGÓCIO POR

UMA MUDANÇA NO ESCOPO

Deve haver um propósito válido de negócio para uma mu­ dança no escopo. Isso inclui.no mínimo,os seguintes fatores:

• Uma avaliação das necessidades dos clientes e do valor adicionado que a mudança no escopo proporcionará • Uma avaliação das necessidades do mercado, in­ cluindo o tempo necessário para fazer a mudança no escopo, o período de payback, o retorno sobre o investimento e se o preço de venda do produto final será alto demais para o mercado

ESTUDO DE CASO

KEMKO MANUFACTURING Plano de Fundo

A Kemko Manufacturing era uma empresa de 50 anos de idade, que tinha reputação de fabricar eletrodomésticos de alta qualidade. O crescimento da Kemko foi rápido, durante a década de 1990. A empresa cresceu por meio da

©2010 por Harold Kerzncr. Reproduzido com permissão.

Todos os direitos reservados.

• Uma avaliação sobre o impacto na duração do ci­ clo de vida do produto • Uma avaliação sobre a capacidade da concorrência em imitar a mudança no escopo • Há alguma responsabilidade do produto associada à mudança no escopo e isso pode ter impacto na nossa imagem? As mudanças no escopo podem ocorrer para produ­ tos existentes ou para novos produtos. O apoio para os produtos existentes geralmente é uma mudança defensiva no escopo designada para penetrar em novos mercados com os produtos existentes. O apoio para novos produtos é geralmente uma mudança ofensiva no escopo desig­ nada para oferecer novos produtos/serviços aos clientes existentes, bem como para procurar novos mercados. 22.4 A LÓGICA PARA NÃO APROVAR UMA MUDANÇA NO ESCOPO

Algumas solicitações de mudança no escopo sào o resul­ tado de pensamento ilusório ou de caprichos pessoais da gerência e nào necessariamente têm base em decisões em­ presariais sólidas. Em tais casos, as mudanças no escopo podem precisar ser canceladas. A racionalização comum para o cancelamento ou não aprovação de uma mudança no escopo inclui: • O custo da mudança no escopo é excessivo e o custo final da entrega pode nos tornar não competitivos • O retorno sobre o investimento pode ocorrer tarde demais • A concorrência é muito acirrada e não vale o risco • Há obstáculos intransponíveis e complexidade técnica • Há incertezas legais e regulatórias • A mudança de escopo pode violar a política da empresa sobre acordos de sigilo, segredos e confidencialidade

aquisição de outras empresas. A empresa tinha agora mais de 25 fábricas nos Estados Unidos, na Europa e na Ásia.

Originalmente, cada fabrica adquirida queria manter sua própria cultura, e muitas vezes eram autorizadas a per­ manecer autônomas da corporação Kemko, contanto que o trabalho progredisse como planejado. Mas, conforme a Kemko começou a adquirir mais empresas, as dificuldades decorrentes do crescimento tornaram quase impossível permitir que cada fábrica permanecesse autônoma. Cada empresa tinha sua própria maneira de lidar com aquisição de matérias-primas e controle de estoque.

683

O “NEGÓCIO" DAS MUDANÇAS NO ESCOPO

Todos os pedidos de compra acima de um determinado valor em dólar deveríam ser aprovados pela corporação. Na corporação, muitas vezes, havia confusão sobre as informações em todos os formulários, pois cada fábri­ ca tinha sua própria documentação para a aquisição. A corporação tinha medo de que, a menos que fosse esta­ belecido um sistema de aquisições e controle de estoque padronizado em todas as fabricas, os efeitos decorrentes de problemas de fluxo de caixa e perda de controle cor­ porativo sobre o estoque poderiam ser sentidos em um futuro próximo. 0 Projeto é Iniciado

Em virtude da importância do projeto, a gerência sênior pediu a Janet Adams, Diretora de Tecnologia da Infor­ mação (Ti), que assumisse o controle do projeto pessoal­ mente. Janet tinha mais de 30 anos de experiência em TI e entendia completamente como o scope creep poderia criar confusão em um grande projeto.

Janet selecionou sua equipe de TI e definiu uma data de kickoff para o projeto. Além da presença obrigatória de todos os membros da sua equipe, ela também exigiu que cada fábrica designasse pelo menos um representan­ te, e que todos os representantes de fábrica deveríam tam­ bém estar presentes na reunião de kickoff. Na reunião de kickoff, Janet falou: Pedi que todos estivessem aqui porque quero que vocês tenham uma compreensão clara de como pretendo gerenciar este projeto. Nossos executivos nos deram um calendário para este projeto e meu maior medo é o scope creep. Sco­ pe creep é o crescimento ou melhorias no es­ copo do projeto enquanto o projeto está sendo desenvolvido. F.m muitos de nossos outros pro­ jetos, o scope creep alongou o projeto e elevou o custo: Eu sei que o scope creep nem sempre é ruim, e que pode acontecer em qualquer fase do ciclo de vida.

A razão pela qual pedi que todos os represen­ tantes de fábrica estivessem presentes nesta reu­ nião são os perigos do scope creep. O scope creep tem muitas causas, mas geralmente é a falha em realizar um planejamento inicial eficaz. Quan­ do existe scope creep, as pessoas geralmente ar­ gumentam que isso é uma ocorrência natural e que devemos aceitar o fato de que vai acontecer. Isso é inaceitável para mim!

Não haverá mudanças no escopo neste projeto, e real mente estou falando sério quando digo isso. Os representantes de fóbrica deverão se

reunir por conta própria e nos fornecer um pa­ cote detalhado de requisitos. Não vou permitir que o projeto comece oficial mente até que te­ nhamos uma lista detalhada dos requisitos. Mi­ nha equipe irá fornecer-lhes alguma orientação para a elaboração dos requisitos, se necessário. Nenhuma alteração no escopo será permitida depois que o projeto começar. Sei que poderá haver algumas solicitações de alteração de esco­ po, mas todas as solicitações serão agrupadas e trabalhadas posteriormente, como um projeto de melhoria. Este projeto será implementado de acordo com o conjunto original de requisitos. Se eu permitir que mudanças no escopo ocor­ ram, este projeto será executado para sempre. Eu sei que alguns de vocês não gostam disso, mas este será o caminho neste projeto.

Houve um silêncio mortal na sala. Janet poderia dizer pelas expressões nos rostos dos representantes de fábrica que estavam descontentes com seus comentários. Algumas das fábricas tinham a impressão de que o grupo de TI é que deveria preparar o pacote de requisitos. Ago­ ra Janet havia transferido a responsabilidade para eles, o grupo de usuários, e eles não estavam felizes. Janet deixou claro que o envolvimento do usuário seria essencial para a preparação dos requisitos. Depois de alguns minutos de silêncio, os represen­ tantes de fábrica disseram que estavam dispostos a fazer isso e que seria feito corretamente. Muitos dos represen­ tantes compreenderam a documentação de requisitos de usuário. Eles iriam trabalhar juntos e chegar a um acordo sobre os requisitos. Janet voltou a afirmar que sua equipe iria apoiar os representantes de fábrica, mas que o peso da responsabilidade repousaria exclusivamente sobre as fábricas. As fábricas vâo conseguir o pedirem e nada mais. Portanto, eles devem ser bem claros em seus requisitos.

Enquanto Janet estava falando aos representantes de fábrica, a parcela de TI da equipe estava apenas relaxando e sorrindo. Seu trabalho estava prestes a tomar-se mais facil, ou pelo menos pensaram assim. Janet, em seguida, dirigiu-se à parcela de TI da equipe:

Agora, quero abordar o pessoal de TI. A razão pela qual todos estamos presentes nesta reunião é que eu quero que os representantes de fábrica ouçam o que tenho a dizer para a equipe de TI. No passado, as equipes de Tl não ficaram sem alguma culpa pelo scope creep e alongamento do cronograma. Então, aqui estão os meus comen­ tários para o pessoal de Tl:

684

Gerenciamento de Projetos

• É de responsabilidade da equipe de Tl certifi­ car-se que compreende os requisitos da forma que foram preparados pelos representantes das fabricas. Não retornem para mim mais tarde dizendo que não entendem os requisi­ tos, porque foram mal definidos. Vou pedir a cada membro da equipe de '11 que assine um documento afirmando que leu os requisitos e que os compreende completamente. • Não é necessário perfeccionismo. Tudo o que quero que façam é terminar o trabalho. • No passado, fomos atormentados com “featurítis”*™, nos quais muitos de vocês acrescentaram seus próprios “adereços” des­ necessariamente. Se isso acontecer neste pro­ jeto, eu pessoalmente vou encarar como um fracasso de vocês e isso irá se refletir em sua próxima avaliação de desempenho. • Às vezes, as pessoas acreditam que um projeto como este vai alavancar sua carreira, especial­ mente se buscarem perfeccionismo e funcio­ nalidades adicionais. Confiem em mim quan­ do digo que isso poderá ter o efeito oposto. • Política de bastidores não será permitida. Se algum dos representantes de fábrica vier até vocês buscando formas de introduzir sorra­ teiramente mudanças de escopo, quero saber

Peaturitis é um termo composto pela mescla do anglicismofeature

(característica, propriedade, funcionalidade) e a desinéncia itis (com a qual são designadas as inflamações na medicina), para

identificar uma aplicação de software na qual se dispõem tantas

funcionalidades que complicam demasiadamente a usabilidade da

finalidade principal desta aplicação.

sobre isso. E se vocês fizerem as mudanças sem a minha permissão, poderão não estar traba­ lhando para mim por muito mais tempo. • Eu, e somente eu, tenho a autoridade de assi­ nar mudanças no escopo. • Este projeto será executado por meio de um planejamento detalhado, e não por meio de planejamento progressivo ou em ondas sucessi­ vas. Devemos ser capazes de fazer isso, uma vez que tivermos requisitos daramente definidos. Agora, alguém tem alguma dúvida?

As linhas de batalha estavam agora desenhadas. Al­ guns acreditavam que era Janet contra a equipe, mas a maioria entendeu a necessidade de Janet fazer isso. No entanto, ainda era questionável se poderia ou não funcio­ nar dessa forma. PERGUNTAS

Janet foi correta quanto aos comentários que fez aos representantes de fábrica? 2. Janet foi correia nos comentários que fez para os membros da equipe de TI? 3. Em projetos de TI é sempre melhor fazer altera­ ções usando projetos de melhoria, ou devemos permitir que sejam feitas alterações à medida que avançamos? 4. Qual é seu palpite sobre o que aconteceu? 1.

O ESCRITÓRIO DE PROJETOS

Estudos de (aso Reloiionodos (de Kerzner/ftopd livro de Exercidos Relacionado (de faiw/Project Management Management (ase Studies, 4. ed.) Workbook andPMP /(APM Exam Study Guide, 11. ed.)

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

• A oçoo ludool de gerentiomertc de peofetos'

• • • •

■ Multiple Choke Exom

Gerenciamento de Integroçao Gerencianento de Escopo Gerenciamento de Custo Gerenciamento de Pates Interessados

’fsuJodt caso «ombàn opaoct ooMóo ccpivlo

23.0

INTRODUÇÃO

Hoje, as empresas estào gerenciando seus negócios 1 4 4 EKrÜório de projelo * por projetos. O resultado tem sido uma grande quantidade de informações sobre o gerenciamento dos projetos emergindo de todas as áreas da empresa. Essas informações centram-se sobre as me­ lhores práticas de gerenciamento de projetos, a utilidade de uma metodologia empresarial de gerenciamento de projetos, os benefícios do gerenciamento de projetos e em como ele está melhorando a rentabilidade da empre­ sa. Conforme as empresas começam a reconhecer o efeito favorável que exerce sobre o desempenho, todo esse conhe­ cimento de gerenciamento de projetos é tratado como pro­ priedade intelectual. A ênfase agora é colocada em alcançar o profissionalismo em gerenciamento de projetos usando o conceito de escritório de projetos (PO)Kri, em que o es­ critório de gerenciamento de projetos (PMO)^2 torna-se o guardião da propriedade intelectual de gerenciamento Guia PMBOK ', 5.ed.

de projetos. O conceito de um PO ou PMO poderia mui­ to bem ser a atividade de gerenciamento de projetos mais importante nessa década. 23.1

0 ESCRITÓRIO DE PROJETOS ATUAI

A década de 1990 começou com uma recessão que afe­ tou negativamente as posições de colarinho branco. O desejo da administração por eficiência e eficácia a levou a prestar atenção em técnicas não tradicionais de gestão, tais como gerenciamento de projetos. O gerenciamen­ to de projetos começou a se expandir para setores não orientados a projetos. Os benefícios da utilização do gerenciamento de projetos, que antes eram vistos como aplicáveis somente para os setores aeroespacial, de defesa e de construção pesada, sào, agora, reconhecidos como sendo aplicáveis a outros setores.

Nn Da expressão em inglês, Project Office (PO).

Até o final dos anos 1990, conforme mais benefícios do gerenciamento de projetos ficaram evidentes, a admi­ nistração entendeu que poderia haver um impacto signi­ ficativo e favorável no resultado corporativo. Isso levou a

N_n Da expressão em inglês. Project Management Office (PMO).

administração a duas conclusões importantes:

686

Gerenciamento de Projetos

• O gerenciamento de projetos tinha de ser integra­ do e compatível com os sistemas de recompensas das empresas para o crescimento sustentado do gerenciamento de projetos • O reconhecimento corporativo do gerenciamento de projetos como profissão foi essencial para au­ mentar o desempenho

O reconhecimento do profissionalismo em geren­ ciamento de projetos levou as empresas a aceitar o Pro­ grama de Certificação do PMI® como um padrão e a reconhecerem a importância do conceito de PO. Estava sendo feita uma consideração para todas as atividades críticas relacionadas ao gerenciamento de projetos para serem colocadas sob a supervisão do PO. Isso incluiu temas como: • • • • • • • • • • • •

• • • • • • • •

Padronização na estimativa Padronização no planejamento Padronização no desenvolvimento do cronograma Padronização no controle Padronização nos relatórios Esclarecimento dos papéis e responsabilidades de gerenciamento de projetos Elaboração de descrições de trabalho para gerentes de projetos Elaboração de dados de arquivo nas lições apren­ didas Benchmarking contínuo de gerenciamento de projetos Desenvolvimento de modelos de gerenciamento de projetos Desenvolvimento de uma metodologia de geren­ ciamento de projetos Recomendação e implementação de mudanças e melhorias à metodologia existente de gerencia­ mento de projetos Identificação das normas de gerenciamento de projetos Identificação das melhores práticas de gerencia­ mento de projetos Realização de planejamento estratégico para o ge­ renciamento de projetos Estabelecimento de uma linha direta para a resolu­ ção de problemas em gerenciamento de projetos Coordenação e/ou condução de programas de treinamento em gerenciamento de projetos Transferência de conhecimento por meio de coa­ ching e mentoring Desenvolvimento de um plano de capacidade/uti­ lização de recursos corporativos Avaliação de riscos em projetos

• Planejamento para recuperação de desastres em projetos • Realização ou participação no gerenciamento de portfolio de projetos • Atuação como o guardião da propriedade intelec­ tual de gerenciamento gestão de projetos Com a ocorrência dessas mudanças, as organizações começaram a mudar o nome do PO para Centro de Ex­ celência (COE)Kli em gerenciamento de projetos. O COE foi o principal responsável por fornecer informações às partes interessadas, em vez de executar, de fato, os proje­ tos ou fazer correções na metade do curso de um plano. 23.2

OS RISCOS DE IMPLEMENTAÇÃO

Cada atividade designada ao PO traz vantagens e des­ vantagens. maioria das desvantagens foi atribuída ao aumento dos níveis de resistência às novas responsabili­ dades dadas ao PO. Para simplificar, os níveis de resistên­ cia podem ser classificados como de baixo risco, de ris­ co moderado e de alto risco de acordo com as seguintes definições:

• Baixo Risco: facilmente aceito pela organização com muito pouca mudança no equilíbrio de po­ der e autoridade. Praticamente nenhum impacto sobre a cultura corporativa. • Risco Moderado: alguma resistência por parte da cultura corporativa e, possivelmente, uma mudan­ ça no equilíbrio de poder e autoridade. Os níveis de resistência podem ser superados no médio pra­ zo e com o mínimo de esforço. • Alto Risco: existem fortes grupos de resistência e uma mudança definitiva em algumas relações de poder e autoridade. A forte liderança executiva pode ser necessária para superar a resistência. Nem todo PO tem as mesmas responsabilidades. Da mesma forma, as mesmas responsabilidades implemen­ tadas em dois POs podem ter diferentes graus quanto ao melhor interesse da organização. A avaliação dos riscos potenciais de implementação é crítica. Pode ser mais fácil obter apoio para o estabele­ cimento de um PO por meio da implementação de ati­ vidades de baixo risco em primeiro lugar. As atividades de baixo risco são as atividades operacionais para apoiar os esforços de gerenciamento de projetos no curto prazo, considerando que as atividades de alto risco estão mais alinhadas com as responsabilidades de planejamento Kn Da expressão cm inglês. Center ofExcellence (COE).

687

O ESCRITÓRIO DE PROJETOS

estratégico e, possivelmente, com o controle de informa­ ções confidenciais. Por exemplo, atividades de baixo risco incluem mentoring, desenvolvimento de padrões e treina­ mento em gerenciamento de projetos. Atividades de alto risco incluem o planejamento de capacidade, benchmarking e divulgação de informações. Os gerentes seniores estavam agora reconhecendo que o gerenciamento de projetos e o PO tinham se torna­ do ativos de valor incalculável para a alta administração, bem como para os níveis de execução.

Durante os últimos dez anos, os benefícios para os níveis executivos de gestão com o uso de um PO se torna­ ram evidentes. Esses benefícios incluem: • Padronização das operações • Tomada de decisões da empresa e não do silo • Melhor capacidade de planejamento (ou seja, alo­ cações de recursos) • Acesso mais rápido a informações de maior qualidade • Eliminação ou redução dos silos da empresa • Operações mais eficientes e eficazes • Menos necessidade de reestruturação • Menos reuniões que roubam o tempo valioso dos executivos • Priorização mais realista do trabalho • Desenvolvimento de futuros gerentes gerais

Todos os benefícios citados aqui estão direta ou indi­ retamente relacionados com a propriedade intelectual de gerenciamento de projetos. Para manter a propriedade inte­ lectual de gerenciamento de projetos, o PO deve manter os veículos para capturar e divulgar os dados para as diversas partes interessadas. Esses veículos incluem a intranet de ge­ renciamento de projetos da empresa, os websites dos proje­ tos, bases de dados de projetos e os sistemas de informação de gerenciamento de projetos. Uma vez que grande parte dessa informação é necessária tanto para o gerenciamento de projetos quanto para o planejamento estratégico corpo­ rativo, deve existir planejamento estratégico para o PO. Conforme entramos no século XXI, o PO se tomou comum na hierarquia corporativa. Embora a maioria das atividades atribuídas ao PO não tivesse mudado, havia uma nova missão para ele: o apoio a toda a corporação. O PO estava, então, a serviço da corporação, espe­ cialmente nas atividades de planejamento estratégico, em vez de focar em um cliente específico. O PO foi transfor­ mado em um centro corporativo para o controle da pro­ priedade intelectual de gerenciamento de projetos. Essa era uma necessidade, já que a magnitude das informações de gerenciamento de projetos cresceu quase exponencialmente ao longo de toda a organização.

23.3 TIPOS DE ESCRITÓRIOS DE PROJETOS

São comumente utilizados trés tipos de POs nas empresas:

• PO Funcional: esse tipo de PO é utilizado em uma área funcional ou divisão de uma organização, como sistemas de informação. A responsabilidade principal desse tipo de PO é gerenciar um grupo geral de re­ cursos críticos, ou seja, gerenciamento de recursos. O PMO pode ou não realmente gerenciar os projetos. • PO de Grupo do Cliente: esse tipo de PO é para um melhor gerenciamento do cliente e comuni­ cação com o cliente. Clientes ou projetos comuns são agrupados para um melhor gerenciamento e relacionamento com o cliente. Podem existir vá­ rios POs de grupo do cliente ao mesmo tempo e podem acabar funcionando como uma organiza­ ção temporária. De fato, ele atua como uma em­ presa dentro de uma empresa. Esse tipo de PMO terá um gerente de projetos permanente designado e gerenciando os projetos. • PO Corporativo (ou Estratégico): esse tipo de PO serve a toda a empresa e centra-se em questões cor­ porativas e estratégicas, em vez de questões funcio­ nais. Se esse tipo de PMO faz o gerenciamento de projetos, é para esforços de redução de custos.

As empresas podem defender mais de um tipo de PO, ao mesmo tempo. Por exemplo, podem existir dois POs, um fun­ cional e um estratégico/corporativo, que trabalhem juntos. 23.4

ESCRITÓRIOS DE GERENCIAMENTO DE PROJETOS EM REDE

Pór causa de disputas políticas pelo controle do PMO, mui­ tas empresas têm estabelecido PMOs múltiplos, os quais são ligados entre si por um PMO de “coordenação”. Outras empresas que são multinacionais criaram PMOs regionais, que são agrupamentos dos associados ao gerenciamento dos projetos (gerentes de projeto» membros de equipe etc.) que realizam as funções de gerenciamento de projetos dentro de áreas regionais específicas ou áreas específicas aos setores. Nesse caso, as principais responsabilidades do PMO sào:

• Promoção da metodologia de gerenciamento de projetos da empresa • Promoção da utilização de ferramentas de geren­ ciamento de projetos • Garantia de padronização na execução e entrega do projeto • Manutenção de uma fonte especialista em geren­ ciamento de projetos • Coordenação de conhecimento multinacional de gerenciamento de projetos

688

Gerenciamento de Projetos

23.5

SISTEMAS DE INFORMAÇÃO

Sistema de Informação de Gerenciamento

DE GERENCIAMENTO DE PROJETOS

de Riscos

Dado o fato de que o PO é agora o guardião da proprie­ dade intelectual de gerenciamento de projetos, deve haver processos e ferramentas para capturar essa informação. Essa informação pode ser coletada por meio de quatro sistemas de informação, como mostrado na Figura 23-1. Cada sistema de informação pode ser atualizado e geren­ ciado por meio da intranet da empresa.

FIGURA 23-1

O segundo sistema de informação fornece dados so­ bre o gerenciamento de riscos. O sistema de informação de gerenciamento de riscos (RMIS)'fT4 armazena e per­ mite a recuperação de dados relacionados aos riscos. Ele fornece dados para a criação de relatórios e serve como o repositório de todas as informações atuais e históricas relacionadas aos riscos do projeto. A informação deverá incluir a documentação de identificação de riscos (possi­ velmente utilizando modelos), documentos de avaliação quantitativa e qualitativa de riscos, entrega de contrato, se adequado, e quaisquer outros dados relacionados a riscos. O PiVIO irá utilizar os dados do RM1S para criar relatórios para a alta administração e recuperar dados para o dia a dia dos projetos. Ao utilizar modelos de gerenciamento de riscos, cada projeto irá produzir um conjunto de rela­ tórios padronizados para a comunicação periódica e tem a capacidade de criar relatórios específicos em resposta a consultas especiais. Essa informação está diretamente re­ lacionada ao sistema de informação de relatório de falhas e ao sistema de informação de lições aprendidas. Os dois últimos sistemas de informação são abordados com mais detalhes nas próximas duas seções.

Sistemas de informação de gerenciamento de projetos. Sistema de Informação de Falhas de Desempenho

Sistema de Informação de Medição do

Valor Agregado

O sistema de informação de medição do valor agre­ gado é comum a quase todos os gerentes de projetos. Ele fornece informações suficientes para responder a duas perguntas: • Onde está o projeto hoje? • Onde o projeto irá terminar?

Esse sistema captura ou calcula os valores plane­ jado e real do trabalho, os custos reais, as variações de custos e cronograma (em horas ou unidades monetárias e em percentual), o custo estimado no término, o tem­ po estimado no término, a porcentagem concluída e as tendências.

O sistema de informação de medição do valor agre­ gado é fundamental para uma empresa que precisa de informações facilmente disponíveis para a tomada rá­ pida de decisões. Em um plano de projeto, é mais fácil fazer pequenas mudanças em vez de grandes. Portanto, as variações da linha de base da medição do desempe­ nho devem ser identificadas rapidamente, de tal forma que ações corretivas possam ser tomadas em pequenos incrementos.

O PO pode ter a responsabilidade de manter o sis­ tema de informação de falhas de desempenho (PFIS)ST**. A falha poderia ser uma falha total do projeto ou simples­ mente a falha de determinados testes dentro do projeto. O PFIS deve identificara(s) causa(s) da falhae,eventualmen ­ te, as recomendações para a removê-la(s). A(s) causa(s) poderá(ão) ser identificada(s) como proveniente(s) de problemas totalmente internos da organização ou de in­ terações coordenadas com fornecedores.

É responsabilidade do PO desenvolver padrões para a manutenção do PFIS, em vez de validar a falha. A va­ lidação é da responsabilidade dos membros da equipe executora do trabalho. O relatório de falhas pode levar à descoberta de problemas adicionais e mais sérios. Em primeiro lugar, pode haver resistência em relatar alguma falha, por medo de que possa refletir negativamente sobre o pessoal associado com a falha, como os patrocinadores do projeto. Em segundo lugar, cada divisão de uma grande empresa pode ter os seus próprios procedimentos para o registro de falhas e pode ficar relutante em tornar a falha

KT* Da expressão em inglês, Rtd- Management Information System

(RMIS). Da expressão cm inglês. Performance Failure Information

System (PFIS).

689

O ESCRITÓRIO DE PROJETOS

visível em um banco de dados em nível corporativo. Ter­ ceiro, poderia existir muitas definições diferentes do que é ou não é um fracasso. Quarto, o PO pode estar à mercê dos outros para fornecer informações precisas, oportunas e completas. O relatório de falhas deve identificar o item que fa­ lhou, os sintomas, as condições no momento da falha e quaisquer outras evidências pertinentes necessárias para que as ações corretivas ocorram. A análise de falha, que é a análise sistemática das consequências da falha no pro­ jeto, não pode ser concluída até que as causas da falha tenham sido completamente identificadas. O PO pode simplesmente funcionar como o guardião de registros para padronizar um formato único para toda a empresa e uma base de dados para o relatório dos resultados de cada projeto. Isso poderia fazer parte da revisão das lições aprendidas, ao final de cada projeto.

Considere o seguinte exemplo: Uma empresa aeroes­ pacial tinha duas divisões que, muitas vezes, competiram entre si por meio de licitação em contratos do governo. Cada uma conduzia suas próprias atividades de P&D, e muito raramente faziam o intercâmbio de dados. Uma das divisões passou seis meses trabalhando em um pro­ jeto P&D que foi finalmente encerrado e rotulado como um fracasso (falha). Pouco tempo depois, soube-se que a outra divisão tinha trabalhado exatamente no mesmo projeto, havia um ano, e alcançado os mesmos resultados improdutivos. As informações sobre a falha não haviam sido trocadas, resultando em desperdício de recursos críticos. Todos reconhecem a necessidade de um sistema de informação corporativo para o armazenamento de dados de falha. Mas existe sempre o risco de que alguns vejam isso como uma perda de poder. Outros podem resistir por medo de que seu nome seja identificado juntamente com a falha. O risco global de dar essa responsabilidade para o escritório de projetos é de baixo a moderado. Sistema de Informação de Lições Aprendidas

(Análise

post-mortem)

Algumas empresas trabalham em um vasto número dc projetos a cada ano, e cada um desses projetos forne­ ce informações valiosas para a melhoria dos padrões, do processo de estimativa para licitações futuras e da forma como os negócios são conduzidos. Toda essa informação é propriedade intelectual e deve ser capturada para uso futuro. As revisões das lições aprendidas são uma manei­ ra de obter essa informação.

Se a propriedade intelectual dos projetos deve ser mantida em um local centralizado, então o PO deve

desenvolver conhecimento sobre como conduzir uma reunião de análise post-mortem. Nessa reunião, quatro questões críticas devem ser abordadas: • • • •

O que fizemos certo O que fizemos de errado Quais recomendações futuras podem ser feitas Como, quando e para quem as informações devem ser divulgadas

23.6 DIVULGAÇÃO DE INFORMAÇÕES

Um problema que acomete a maioria das organizações é como ter a certeza de que as informações críticas, tais como os KPls (indicadores-chave de desempenho) e os PCS (fatores críticos de sucesso), sejam conhecidos por toda a organização. As bases de dados de lições aprendi­ das da intranet seriam uma maneira de compartilhar a informação. No entanto, uma melhor forma pode ser o PO assumir a liderança na elaboração de estudos de casos de lições aprendidas ao final de cada projeto. Os estudos de casos poderíam, então, ser utilizados em futuros pro­ gramas de treinamento por toda a organização e estar ba­ seados na intranet.

Por exemplo, uma empresa completou um projeto com bastante sucesso e a equipe do projeto entrevista a gerência sênior no final do projeto. A empresa havia feito avanços significativos na fabricação de vários processos utilizados para o projeto e a gerência sênior queria ter a certeza de que esse novo conhecimento estaria disponível a todas as outras divisões.

A decisão foi tomada para dissolver a equipe e trans­ ferir as pessoas para várias divisões por toda a organi­ zação. Depois que seis meses haviam passado, tornou * -se evidente que muito pouco conhecimento tinha sido transferido para as outras divisões. A equipe foi então reagrupada e solicitada para escrever um estudo de caso das lições aprendidas para ser usado durante programas de treinamento de gerenciamento de projetos. Embora essa abordagem tenha funcionado bem, existem também consequências negativas que tornam essa abordagem difícil de implementar. Outra empresa adotou o conceito de ter de elaborar estudos de casos de lições aprendidas. Embora o resultado final de um dos projetos tenha sido um sucesso, vários erros dispen­ diosos foram cometidos durante a execução do projeto em virtude da falta de conhecimento de gerenciamento de riscos e tomadas de decisões ruins. Acreditando que os estudos de caso das lições aprendidas deveríam in­ cluir os erros, bem como os sucessos, a equipe do PO que estava elaborando o estudo de caso incluiu todas as informações.

690

Gerenciamento de Projetos

Apesar das tentativas de disfarçar os nomes dos co­ laboradores que cometeram os erros críticos, todos na organização sabiam quem trabalhou no projeto e eram capazes de descobrir quais eram os empregados. Vários dos colaboradores envolvidos no projeto apresentaram uma queixa à alta gerência sobre a divulgação dessa in­ formação, e os estudos de caso foram então retirados dos programas de treinamento. É preciso uma forte cultura organizacional para aprender com os erros sem a represá­ lia aos colaboradores. O risco aqui pode ser de moderado a alto para o PO administrar essa atividade.

23.7

MENTORING

O mentoring no gerenciamento de projetos é uma ativi­ dade crítica do PO. A maioria das pessoas parece concor­ dar que a melhor maneira de treinar alguém em geren­ ciamento de projetos é o treinamento prático. Tal método seria para os gerentes de projetos inexperientes trabalha­ rem diretamente sob a orientação de um gerente de pro­ jetos experiente, especialmente em grandes projetos. Essa abordagem pode se tornar cara se a organização não tem um fluxo de grandes projetos.

Talvez a melhor escolha fosse o PO assumir o pa­ pel de mentoring, de acordo com o qual os gerentes de projetos inexperientes podem buscar aconselhamento e orientação dos gerentes de projetos mais experientes que se reportam hierarquicamente em linha “sólida”ou “pon­ tilhada” ao PO. Essa abordagem tem três grandes bene­ fícios. Primeiro, o gerente de linha ao qual o gerente do projeto se reporta administrativamente pode não ter o conhecimento necessário de gerenciamento de projetos ou a experiência capaz de auxiliar o colaborador em tem­ pos de dificuldade. Segundo, o gerente de projetos pode não querer discutir certos problemas com seus superio­ res, por medo de represálias. Em terceiro lugar, dado o fato de que o PO pode ter a responsabilidade de manter os arquivos de lições aprendidas, o programa de mento­ ring de projetos pode usar esses arquivos e fornecer aos gerentes de projetos inexperientes os indicadores de aler­ ta precoce de que problemas potenciais podem ocorrer. O programa de mentoring pode ser feito em regi­ me de tempo integral ou conforme a necessidade, que é a abordagem preferida. O mentoring em tempo integral pode parecer uma boa ideia, mas inclui o risco de que o mentor acabe gerenciando o projeto. O risco global para o mentoring no PO é baixo. 23.8

DESENVOLVIMENTO DE PADRÕES E MODELOS

Um componente crítico de qualquer PO é o desenvol­ vimento de padrões de gerenciamento de projetos. Os

padrões fomentam o trabalho em equipe, criando uma linguagem comum. No entanto, o desenvolvimento de pa­ drões excessivos sob a forma de políticas e procedimentos pode ser um erro, pois pode não ser possível a criação de políticas e procedimentos que cubram todas as situações possíveis em cada projeto possível. Além disso, o tempo, o dinheiro e o pessoal necessário para desenvolver padrões rígidos de políticas e procedimentos tornaria a imple­ mentação do PO improvável por causa do requisito do número de pessoas. Os formulários e as listas de verificação podem ser preparados em um formato modelo tal que as informa­ ções possam ser usadas em uma infinidade de projetos. Os modelos devem ser feitos sob medida para uma de­ terminada organização, em vez de copiados de uma outra organização que pode não ter tipos de projetos semelhan­ tes ou uma cultura similar. Modelos reutilizáveis devem ser elaborados após a organização ter concluído vários projetos, seja com ou sem sucesso, e onde as informações das lições aprendidas possam ser utilizadas para o desen­ volvimento e melhoria dos modelos. Há um perigo na disponibilização de modelos como substitutos para padrões mais formais. Primeiro, pelo fato de que os modelos servem como um guia para um público geral, podem não satisfazer as necessidades de qualquer programa específico. Segundo, há o risco de que alguns usuários perspectivos dos modelos, especialmente de gerentes de projetos inexperientes, possam simples­ mente adotar modelos “conforme o exigido, conforme está escrito”, apesar do fato de eles não se ajustarem ao seu programa.

A razão para a disponibilização de modelos não é dizer à equipe como fazer o seu trabalho, mas dar ao ge­ rente de projetos e à sua equipe um ponto de partida para os seus próprios processos de iniciação, planejamento, execução, controle e encerramento do projeto. Modelos devem estimular o pensamento proativo sobre o que pre­ cisa ser feito e, possivelmente, algumas idéias sobre como fazê-lo. Modelos e padrões muitas vezes contêm muito mais informações do que a maioria dos gerentes de pro­ jetos precisa. No entanto, eles devem ser vistos como a chave para manter as coisas simples e os gerentes de pro­ jetos devem ser capazes de adequá-los para atender às necessidades do projeto, por meio da concentração nas principais áreas críticas. Os modelos e padrões devem ser atualizados sempre que necessário. Uma vez que o PO é mais provavelmen­ te responsável pela manutenção dos arquivos de lições aprendidas e pela análise post-mortem do projeto, é so­ mente por meio do ajuste que o PO avalia esses dados para procurar indicadores chave de desempenho que

691

O ESCRITÓRIO DE PROJETOS

possam ditar as melhorias do modelo. Os padrões e os modelos podem ser considerados como uma atividade de baixo risco do PO.

23.9

BENCHMARKING DE GERENCIAMENTO DE PROJETOS

Talvez a atividade mais interessante e mais difícil desig­ nada a um PO é o benchmarking. Assim como o mento­ ring, o benchmarking requer a utilização de gerentes de projetos experientes. Os indivíduos designados devem saber o que procuram e quais perguntas fazer, devem ter a capacidade de reconhecer um bom ajuste com a empre­ sa, como avaliar os dados e quais recomendações fazer. O benchmarking está diretamente relacionado com o planejamento estratégico de gerenciamento de projetos e pode ter um efeito destacado sobre o resultado corpora­ tivo baseado no quão rapidamente as mudanças são im­ plementadas. Nos últimos anos, as empresas descobriram que as melhores práticas podem ser comparadas com outras organizações, não necessariamente na sua linha de negócios. Por exemplo, uma divisão aeroespacial de uma grande empresa vem utilizando gerenciamento de projetos há mais de 30 anos. Durante a década de 1990, a empresa vinha realizando estudos de benchmarking, mas apenas com outras empresas aeroespaciais. A complacên­ cia se instalou, em conjunto, com a empresa acreditando que estava em pé de igualdade com os concorrentes no setor aeroespacial. No final dos anos 1990, a empresa co­ meçou a realizar benchmarking frente a empresas fora do seu setor, especificamente de telecomunicações, compu­ tadores, eletrônicos e de entretenimento. /\ maioria des­ sas empresas vinha utilizando gerenciamento de projetos por menos de cinco anos e, nesse tempo, tinha alcançado um desempenho em gerenciamento de projetos que exce­ dia a empresa aeroespacial. Agora, a empresa aeroespacial realiza o benchmarking frente a todos os setores. O estabelecimento da rede do escritório de projetos para fins de benchmarking poderia muito bem estar no futuro próximo para a maioria das empresas. A rede de escritórios de projetos poderia se estender por setores e continentes. Além disso, pode tornar-se comum, mesmo para os concorrentes, compartilhar conhecimento em gerenciamento de projetos. No entanto, atualmente, pa­ rece que a maioria do benchmarking em gerenciamento de projetos está sendo realizada por organizações cuja função é unicamente o benchmarking. Essas organizações cobram uma taxa por seus serviços e realizam simpósios para seus associados, nos quais dados das melhores prá­ ticas de gerenciamento de projetos são compartilhados. Além disso, oferecem serviços de base de dados com a qual você pode comparar a sua organização:

• Outras organizações no seu setor • Outras organizações em diferentes setores da indústria • Outras respostas de colaboradores dentro da sua empresa • Outras organizações por tamanho da empresa • Outras organizações por tamanho do projeto Algumas organizações têm uma forte resistência ao benchmarking. Os argumentos contra o benchmarking incluem:

• Não se aplica à nossa empresa ou setor. • Não foi inventado aqui. • Nós estamos indo muito bem! Não precisamos disso. • Vamos deixar isso para lá. • Por que consertar algo que não está quebrado? Por causa dessas preocupações, o benchmarking pode ser uma atividade de alto risco em função do medo do que será encontrado e das mudanças recomendadas.

23.10

0 DESENVOLVIMENTO DO

BUSINESS CASE

Uma das melhores maneiras para um PO apoiar a função de planejamento estratégico corporativo é tornando-se especialista no desenvolvimento de business case. Mais especificamente, isso inclui conhecimentos em estudos de viabilidade e análise de custo-benefício. Na seção de gerenciamento da integração do Guia PMBOK®, uma das saídas do processo Desenvolver o Termo de Abertura do projeto é a identificaçào/nomeação de um gerente de projetos. Isso é realizado após o business case ser desenvol­ vido. Há argumentos válidos para a atribuição do gerente de projetos após o business case ser desenvolvido:

• O gerente de projetos pode não ser capaz de con­ tribuir para o desenvolvimento do business case. • O projeto pode não ser aprovado e/ou financiado, e seria um custo adicional ter o gerente de projetos a bordo antecipadamente. • O projeto pode não estar suficientemente bem definido para determinar numa fase precoce a melhor pessoa a ser designada como o gerente do projetos.

Embora esses argumentos pareçam ter mérito, há um problema mais grave no fato de que o gerente de projetos finalmente designado pode não ter conhecimento sufi­ ciente sobre as premissas, restrições e alternativas conside­ radas durante o processo de desenvolvimento do business case. Isso poderia levar a um plano de projeto inferior ao

692

Gerenciamento de Projetos

ideal. É uma ilusão acreditar que o termo de abertura do projeto, que pode ter sido elaborado por alguém comple­ tamente fora dos esforços de desenvolvimento do business case, contenha todas as premissas, alternativas e restrições necessárias.

Um dos axiomas de gerenciamento de projetos é que quanto mais cedo o gerente de projetos é designa­ do, melhor é o plano e maior é o comprometimento com o projeto. As empresas argumentam que a contribuição do gerente do projetos é limitada durante o desenvolvi­ mento do business case. A razão para essa crença é que os gerentes de projetos nunca foram treinados para realizar estudos de viabilidade e análises de custo-benefício. Es­ ses cursos são praticamente inexistentes no mercado de seminários como um curso oferecido publicamente, mas algumas empresas possuem cursos feitos sob medida, es­ pecificamente para elas. O desenvolvimento do business case, muitas vezes, resulta em uma abordagem muito otimista com pouca consideração ao cronograma e/ou ao orçamento. A pres­ são é, então, colocada no gerente de projetos para que aceite argumentos e premissas feitas durante o desenvol­ vimento do business case. Se o projeto falhar em atender as expectativas do business case, a culpa recai sobre o ge­ rente do projeto. O PO deve desenvolver conhecimentos em estudos de viabilidade, análises de custo-benefício e desenvolvi­ mento de business cases. Essa experiência se presta muito facilmente aos modelos, formulários e listas de verifica­ ção. O PO pode se tornar um braço de apoio viável à for­ ça de vendas ao ajudá-las a fazer promessas mais realistas para os clientes e, eventual mente, ajudar na geração de vendas adicionais. No futuro, o PO pode muito bem tornar-se o especialista da empresa em estudos de viabilida­ de e análises custo-benefício e, eventualmente, conduzir o treinamento sob medida para a organização sobre esses temas. O pessoal de marketing e vendas, que tradicional­ mente executa essas atividades, pode ver isso como um risco elevado. 23.11

TREINAMENTO SOB MEDIDA (RELACIONADO

A GERENCIAMENTO DE PROJETOS)

Durante anos, o braço de treinamento do grupo de re­ cursos humanos teve a responsabilidade de trabalhar com instrutores e consultores na concepção de programas de treinamento sob medida de gerenciamento de projetos. Embora vários desses programas tenham sido muito bem-sucedidos, havia muitos que foram vistos como fra­ cassos. Uma divisão de uma grande empresa reconheceu a necessidade de treinamento em gerenciamento de pro­ jetos. O departamento de treinamento, então, partiu para

a licitação e selecionou um instrutor. O departamento de treinamento, em seguida, adicionou em suas próprias agendas, após filtragem, todos as informações sobre as metas e entregas procuradas pela divisão que estava soli­ citando o treinamento. O instrutor nunca se comunicou diretamente com a organização que estava solicitando o treinamento e simplesmente concebeu o curso em torno das informações apresentadas pelo departamento de trei­ namento. O programa de treinamento foi visto como um fracasso, e o consultor/instrutor nunca mais foi convidado. A análise post-mortem indicara as seguintes conclusões: • O braço de treinamento (e a organização solicitante) nunca reconheceu a necessidade de o ins­ trutor se reunir diretamente com a organização solicitante. • O grupo de treinamento recebeu a contribuição da alta administração, sem a organização solicitante saber, das informações que eles queriam que fos­ sem cobertas e o caminho resultante nào satisfez as expectativas de ninguém. • O instrutor pediu que algumas informações com­ plementares fossem cobertas, enquanto outras informações foram consideradas inadequadas e deviam ser excluídas. O pedido foi completamente ignorado. • O departamento de treinamento do instrutor in­ formou que só queria uma palestra, nenhum es­ tudo de caso e poucos exercícios. Essa foi a forma em outros cursos. Nas avaliações, os participantes reclamavam sobre a falta de exercícios e estudos de casos. Enquanto o grupo de treinamento acreditava que suas ações estavam de acordo com o melhor interesse para a empresa, os resultados eram devastadores. O ins­ trutor também foi culpado por permitir que essa situação ocorresse.

A implementação bem-sucedida do gerenciamento de projetos tem um efeito positivo na rentabilidade cor­ porativa. Dado que isso é verdade, por que permitir a não especialistas a concepção do trabalho dc gerenciamento dc projetos? Até mesmo os gerentes de linha que acredi­ tam que a sua organização requer conhecimentos em ge­ renciamento de projetos podem não saber o que ressaltar e o que não ressaltar do Guia PMBOK®. O PO tem o conhecimento especialista na concepção de conteúdos de cursos de gerenciamento de projetos. O PO mantém a propriedade intelectual sobre os arquivos das lições aprendidas e a análise post-mortem do proje­ to, o que dá ao PO uma visão valiosa sobre como obter o melhor retorno sobre o investimento de dinheiro em

693

O ESCRITÓRIO DE PROJETOS

treinamentos. Essa propriedade intelectual também pode ser inestimável para ajudar os gerentes de linha na con­ cepção de cursos específicos para suas organizações. Essa atividade é de baixo risco para o PO. 23.12

GERENCIAMENTO DAS PARTES INTERESSADAS

Todas as empresas possuem partes interessadas. Pode haver a apreensão na mente de alguns indivíduos de que o PO será o patrocinador final de projetos, responsável por todas as partes interessadas. Embora isso possa acontecer no futuro, é altamente improvável que venha a ocorrer no curto prazo.

O PO concentra a sua atenção principalmente nas partes interessadas internas (organizacionais). Não é a in­ tenção de um PO substituir o patrocínio executivo. Con­ forme o gerenciamento de projetos amadurece dentro de uma organização, é possível que nem todos os projetos venham a precisar de patrocínio executivo. Em tais situ­ ações, o PO (e, talvez, a média gerência) pode agregar a responsabilidade de algumas atividades de patrocínio, mais provavelmente para projetos internos. O PO é um bom “ponto de partida" para a constru­ ção e manutenção de alianças com as principais partes interessadas. No entanto, as atividades do PO são desig­ nadas a beneficiar a empresa como um todo e, dado o patrocínio do PO.a responsabilidade pode criar um con­ flito de interesse para o seu pessoal. As parcerias com as principais partes interessadas devem ser construídas e nutridas, e isso exige tempo. O gerenciamento das partes interessadas pode roubar tempo valioso do pessoal do PO necessário para outras atividades. O risco total para essa atividade é baixo. 23.13

MELHORIA CONTÍNUA

Dado o fato de que o PO é um repositório de proprie­ dade intelectual de gerenciamento de projetos, ele pode estar em melhor posição para identificar oportunidades de melhoria contínua. O PO não deveria ter autoridade unilateral para a implementação das mudanças, mas deve ter a capacidade de recomendar as mudanças. Algumas organizações mantêm um conselho de política estratégica ou um comitê diretor que, como uma de suas funções, avalia as recomendações de melhoria contínua ao PO.

assumir, bem como, quando e onde, sem sobrecarregar a força de trabalho existente. O PO deve trabalhar estrei­ tamente com a alta administração em todas as atividades relacionadas ao gerenciamento de portfolio e seleção dos projetos. O momento estratégico adequado, que é o pro­ cesso de decidir quais projetos trabalhar e quando, é um componente crítico do planejamento estratégico. A alta administração pode navegar na intranet da empresa conforme a necessidade para visualizar o anda­ mento de um projeto individual, sem a necessidade de contato pessoal com a equipe. Mas, para satisfazer os re­ quisitos para o momento estratégico adequado, todos os projetos precisariam ser combinados em uma única base de dados que identifica o seguinte: • Os recursos comprometidos por período de tempo e por área funcional • Poli de recursos por área funcional • Recursos disponíveis por período de tempo e por área funcional Pode haver algumas discussões sobre se o controle dessa base de dados deve ficar sob a administração do PO ou não. O autor acredita que isso deveria ser uma respon­ sabilidade do PO porque:

• Os dados seriam demandados pelo PO para apoiar os esforços de planejamento estratégico e de ge­ renciamento de portfólio de projetos. • Os dados seriam demandados pelo PO para deter­ minar prazos e custos realistas de apoio aos esfor­ ços de concorrências em licitações. • O PO pode assumir a responsabilidade de deter­ minar as habilidades necessárias dos recursos para a realização de trabalho adicional. • Os dados serão demandados pelo PO para atuali­ zações e melhorias a essa base de dados e a outras bases de dados impactadas. • Os dados podem ser necessários para realizar estu­ dos de viabilidade e análises de custo-benefício.

Esta atividade é um esforço de alto risco para o PO, porque os gerentes de linha podem ver isso como invasão de território. 23.15

23.14

PLANEJAMENTO DA CAPACIDADE

De todas as atividades designadas a um PO, a atividade mais importante aos olhos da alta administração pode muito bem ser o planejamento da capacidade. Para os executivos cumprirem as suas responsabilidades como os arquitetos do plano estratégico corporativo, eles devem saber quanto trabalho adicional a organização pode

OS RISCOS DA UTIUZACÃO DE UM ESCRITÓRIO DE PROJETOS

Riscos e recompensas andam de mãos dadas. Os benefí­ cios de um PO pode ser negado se os riscos de manuten­ ção de um PO nào forem gerenciados de forma eficaz. A maioria dos riscos não aparece durante a criação do PO, mas muitos aparecem bem após a implementação. Esses riscos incluem:

694

Gerenciamento de Projetos

• Número de Pessoas: uma vez que a organização comece a reconhecer os benefícios da utilização de um PO, há uma tendência natural de aumento do número de pessoal no PO com a falsa crença de que os benefícios adicionais virão em breve. Embora essa crença possa ser válida em algumas circuns­ tâncias, os resultados mais comuns são retornos decrescentes. Quanto mais a organização torna-se conhecedora em gerenciamento de projetos, mais o número de pessoas do PO deve diminuir. • Esgotamento: o esgotamento dos empregados é sempre um risco. A utilização de designações rota­ tivas ou em tempo parcial pode minimizar o risco. Nào é incomum que as pessoas que trabalham em um escritório de projetos ainda se reportem hierar­ quicamente em linha “sólida" ao seu gerente de linha, e em linha “pontilhada" ao escritório de projetos. • Documentação Excessiva: a documentação exces­ siva custa milhões para elaborar e pode gastar um tempo precioso. As atividades do projeto funcio­ nam muito melhor quando se usam formulários, diretrizes e listas de verificação, em vez de políticas e procedimentos mais rígidos. Fazer isso de forma eficaz requer uma cultura baseada na confiança, no trabalho em equipe, na cooperação e na comu­ nicação eficaz. • Reestruturação Organizacional: informação é po­ der. Dado o fato de que o PO realiza um trabalho mais lateral do que vertical, podem ocorrer brigas de poder pelo controle do PO, especialmente pelos gerentes de projetos. O gerenciamento de proje­ tos e um PO pode funcionar muito bem dentro de uma estrutura organizacional que se baseia na confiança, no trabalho em equipe, na cooperação e na comunicação eficaz. • Tentativa de Servir a Todos na Organização: a empresa deve estabelecer alguns critérios para quando o PO deve estar envolvido. O PO nào ne­ cessariamente acompanha todos os projetos. Os valores-limite mais comuns para quando envolver o PO incluem: • O valor monetário do projeto • O tempo de duração do projeto • A quantidade e complexidade da multifúncionalidade • Os riscos para a empresa • A criticidade do projeto (ou seja, reduções de custos)

Uma questão crítica que muitos executivos enfren­ tam é: “ Como nós, enquanto executivos, podemos me­ dir o retorno sobre o investimento, como resultado da

implementação de um escritório de projetos?” A medição real pode ser descrita em termos tanto qualitativos quan­ to quantitativos. Qualitativamente, os executivos podem olhar para o número de conflitos que vêm até o nível exe­ cutivo para resolução. Com um PO eficaz atuando como um filtro, menos conflitos devem ir até os níveis executivos. Quantitativamente, os executivos podem olhar o seguinte: • Revisões de Progresso: sem um PO, podem exis­ tir vários formatos de cronogramas, talvez até um formato diferente para cada projeto. Com um PO e com a padronização, as revisões sào mais rápidas e mais significativas. • Tomada de Decisões: sem um PO, as decisões mui­ tas vezes são demoradas e a ênfase é colocada em itens de ações, em vez de decisões significativas. Com um PO, decisões significativas são possíveis. • Reuniões Desperdiçadas: sem um PO, os executi­ vos podem gastar uma grande quantidade de tem­ po participando de reuniões excessivas e onerosas. Com um PO e com informações mais eficazes, os executivos podem gastar menos tempo em reuni­ ões e mais tempo lidando com questões estratégi­ cas, em vez de questões operacionais. • Quantidade de Informação: sem um PO, os exe­ cutivos podem acabar com muito poucas ou com informações excessivas sobre o projeto. Isso pode inibir a tomada de decisões eficaz. Com um PO e com a padronização, os executivos acham mais fá­ cil tomar decisões oportunas. A principal respon­ sabilidade da alta administração é o planejamento estratégico, a implantação e a preocupação com o futuro da organização. A principal responsabilida­ de das gerências de nível médio e baixo é a de se preocupar com questões operacionais. A respon­ sabilidade do PO é atuar como uma ponte entre todos esses níveis e facilitar para que todos os ní­ veis alcancem seus objetivos e metas. 23.16

GERENCIAMENTO DE PORTFOLIO DE PROJETOS

Sua empresa está atualmente trabalhando em vários pro­ jetos e tem uma lista de espera de mais 20 projetos que gostaria de completar. Se o financiamento disponível vai apoiar apenas mais alguns projetos, como uma empresa vai decidir em qual dos 20 projetos vai trabalhar em se­ guida? Este é o processo de gerenciamento de portfolio de projetos (PPM). Os benefícios do PPM sào relativamente claros. O PPM permite que nossos negócios1 possam:

PENNYPACKER, J.; RETNA, S. (Eds.). Project portfolio mana­ gement: a viewfrom the management trenches. 1 loboken, NJ: The

Enterprise Portfolio Management Council, Wuey, 2009. p. xvi.

695

O ESCRITÓRIO DE PROJETOS

• Fornecer uma estrutura para selecionar os proje­ tos certos e eliminar os errados • Alocar recursos para os projetos certos, reduzindo assim gastos desnecessários • Alinhar decisões de portfolio com as metas estra­ tégicas de negócios • Basear decisões de portfolio na sobre lógica, racio­ cínio e objetividade • Criar sentimento de propriedade aos membros equi­ pe por meio de envolvimento nos níveis corretos • Estabelecer caminhos para os indivíduos identifi­ carem oportunidades e obterem apoio • Ajudar as equipes de projeto a compreender o va­ lor de suas contribuições

Para maximizar os benefícios, é evidente que o PMO deve ser um participante ativo. No entanto, é importan­ te entender a diferença entre gerenciamento de projetos e gerenciamento de portfolio de projetos, mesmo que o PMO esteja envolvido em ambos. Debra Stouffer e Sue Rachlin fizeram essa distinção para projetos de TF:

Um portfólio de TI é composto de um conjunto ou coleção de iniciativas ou projetos. O geren­ ciamento de projetos é um processo contínuo, que se concentra na medida em que uma inicia­ tiva específica estabelece, mantém e alcança seus objetivos pretendidos dentro de linhas de base de custo, cronograma, técnicas e desempenho. O gerenciamento de portfólio concentra a aten­ ção em um nível mais agregado. Seu objetivo principal é identificar, selecionar, financiar, monitorar e manter a combinação adequada de projetos e iniciativas necessárias para atingir as metas e objetivos organizacionais.

Gerenciamento de portfólio envolve a considera­ ção dos custos agregados, riscos e retornos de to­ dos os projetos dentro do portfólio, bem como as diversas compensações entre eles. Naturalmente, o gerente de portfólio também está preocupado com a “saúde” e o bem-estar de cada projeto que está incluído dentro do portfólio de TL Afinal de contas, as decisões de portfólio, como quando financiar um novo projeto ou continuar finan­ ciando um projeto em curso, são baseadas em informações fornecidas em nível de projeto.

O gerenciamento de portfólio de projetos ajuda a determinar a combinação certa de projetos e o nível correto de investimento a se fazer em cada um deles. O resultado é um melhor equilíbrio entre novas iniciati­ vas estratégicas e as iniciativas em andamento. O geren­ ciamento de portfólio não é realizar uma série de cálculos específicos de projeto, como ROI, VLP, TIR, período de payback e fluxo de caixa e, em seguida fazer o ajuste apro­ priado para contar o risco. Em vez disso, é um processo de tomada de decisão para o que for de melhor interesse de toda a organização. Jim Pennypacker e San Retna identificam cinco ques­ tões críticas que são úteis para determinar o sucesso dos seus esforços de gerenciamento de portfólio de projetos’:

• • • • •

Estamos investindo nas coisas certas? F.stamos otimizando nossa capacidade? Quão bem estamos executando? Podemos absorver todas as mudanças? Estamos percebendo os benefícios prometidos?

Jim Pennypacker e San Retna também identificam sete “P’s” do PPM, que são os princípios fundamentais: Paixão, Pessoas, Política, Processos, Potencial, Perfor­ mance e Payback *.

Decisões de gerenciamento de portfólio não são feitas no vácuo. A decisão geralmente está relacionada a outros projetos e a diversos fatores, tais como a disponi­ bilidade de financiamento e alocação de recursos. Além disso, o projeto deve se ajustar bem com outros projetos dentro do portfólio e com o plano estratégico. A seleção poderia ser baseada no término de pro­ jetos, que liberaria recursos para novas iniciativas. Além disso, os projetos selecionados podem ser limitados pela data de conclusão de outros que requeiram entregas ne­ cessárias para iniciar novos projetos. Em qualquer caso, alguma forma de processo de gerenciamento de portfólio de projetos é necessária. Nem todas as empresas atribuem o mesmo grau de importância para o gerenciamento de portfólio. Em algu­ mas empresas, é um processo manual, enquanto em ou­ tras demanda o uso de ferramentas sofisticadas. Algumas empresas acreditam que o gerenciamento de portfólio faz parte dos esforços de planejamento estratégico, enquanto outras veem como uma função de suporte para o plane­ jamento de capacidade.

O gerenciamento bem-sucedido de um portfólio de projetos requer uma forte liderança por indivíduos que STOUFFER, D.; RACHLIN, S. A summan- of first practices

and lessons learned in information technology-

portfolio

management, preparado pelo Chief Information Officer (CIO)

Ver p. 4-5 da obra citada na nota 1.

Council, Washington, DC, mar. 2002. p. 7.

Ibidem, p. 140

696

Gerenciamento de Projetos

reconhecem os benefícios que podem ser acumulados por meio do gerenciamento de portfolio. O compromis­ so da alta administração é essencial. Stouffer e Rachlin comentam sobre o papel da alta administração em um ambiente de TI em agências do governo’: O gerenciamento de portfolio exige uma pers­ pectiva global do negócio e de toda a empresa. De qualquer forma, as decisões de investimento de TI devem ser feitas tanto em nível de projeto como em nível de portfolio. Altos funcionários do governo, gerentes de projetos e de portfolio, e outros tomadores de decisão devem rotineira mente responder a dois conjuntos de perguntas. Em primeiro lugar, em relação aos projetos, há confiança suficiente de que as atividades novas ou em curso que buscam financiamento vão atingir os objetivos pretendidos dentro de pa­ râmetros razoáveis e aceitáveis de custo, crono­ grama, técnicas e desempenho? Em segundo lugar, em relação ao portfolio e tendo uma resposta aceitável para a primeira pergunta, o investimento em um projeto ou em um mix de projetos é desejável em relação a ou­ tro projeto ou mix de projetos? Depois de obter respostas a estas perguntas, os altos funcionários da organização, gerentes de portfolio, e outros tomadores de decisão, então devem usar as informações para determinar o tamanho, escopo e composição da carteira de investimentos em TI. As condições em que o portfolio pode ser alterado devem ser clara­ mente definidas e comunicadas. Mudanças pro­ postas para o portfolio devem ser analisadas e aprovadas pela autoridade apropriada de toma­ da de decisão, como um conselho de revisão de investimentos, e consideradas a partir de uma perspectiva global da organização.

A alta administração é responsável, em última ins­ tância, por definir e comunicar claramente as metas e ob­ jetivos da carteira de projetos, bem como os critérios e condições considerados para a seleção de projetos para o portfolio. De acordo com Stouffer e Rachlin, isso inclui6: • Definir adequadamente e comunicar amplamente as metas e objetivos do portfolio de TI. • Articular claramente as expectativas da organiza­ ção e da gerência sobre os tipos de benefícios que

’

Ver a p. 8 da obra citada na nota 2.

*

Ibidem, p. 13.

estão sendo buscados e as taxas de retorno a serem alcançadas. • Identificar e definir os tipos de riscos que podem afetar o desempenho do portfolio de TI, o que a empresa está fazendo para evitar e lidar com o ris­ co, e sua tolerância para a exposição em curso. • Estabelecer, chegar a um consenso, e consistentemente aplicar um conjunto de critérios que serão utilizados entre os projetos concorrentes e iniciati­ vas de TI.

A alta administração também deve coletar e analisar os dados, a fim de avaliar o desempenho da carteira e de­ terminar se ajustes são necessários ou não. Isso deve ser feito periodicamente, de tal forma que recursos críticos não sejam desperdiçados em projetos que devem ser can­ celados. Stouffer e Rachlin fornecem uma visão sobre isso por meio de suas entrevistas7: De acordo com Gopal Kapur, presidente do Center for Project Management, as organiza­ ções devem se concentrar nas avaliações de seu portfolio de TI e em reuniões de controle sobre sinais vitais críticos do projeto. Exemplos desses sinais vitais incluem compromisso do patroci­ nador e tempo, estado do caminho crítico, taxa de acerto de marcos, taxa de acerto de entregas, custo real versus custo estimado, recursos reais contra recursos planejados, e de alta probabili­ dade, e eventos de alto impacto. Por meio da uti­ lização uma abordagem de boletim vermelho, amarelo ou verde, bem como de métricas defi­ nidas, a empresa pode estabelecer um método consistente para determinar se os projetos estão tendo um impacto negativo sobre o portfolio de TI, se estão falhando e precisam ser desligados.

Critérios e dados específicos a serem coletados e ana­ lisados podem incluir o seguinte:

• Medidas financeiras padrão, tais como re­ torno sobre o investimento, análise de custo e benefício, valor agregado (focando no real contra planejado, quando disponível), au­ mento da rentabilidade, contenção de custo, ou payback. Todas as empresas que participa­ ram das entrevistas incluíram uma ou mais destas medidas financeiras. • Alinhamento estratégico (definido como apoio à missão), também foi incluído por quase todas as empresas. Ibidem, p. 18.

697

O ESCRITÓRIO DE PROJETOS

■ Impacto sobre o cliente, conforme definido nas medidas de desempenho. • Impacto sobre a tecnologia (medida como “contribuição para” ou “impacto sobre” al­ gum tipo de arquitetura definida). • Projeto inicial e (em alguns casos) operações e cronogramas, como observado por quase todas as empresas. • Riscos, prevenção de riscos (e às vezes especificidades de mitigação de risco), como obser­ vado por quase todos os participantes. • Técnicas básicas de gerenciamento de proje­ tos e medição. • E, finalmente, fontes de dados e mecanismos de coleta de dados também são importantes. Muitas empresas entrevistadas preferem ex­ trair informações a partir de sistemas exis­ tentes, as fontes incluem sistemas contábeis, financeiros e de gerenciamento de projetos.

Uma das melhores práticas identificadas por Stouffer e Rachlin para projetos de TI foi cuidadosa consideração de partes interessadas tanto internas como externas1': Expandir o envolvimento do negócio no ge­ renciamento de portfolio, muitas vezes inclui o seguinte:

• Reconhecer que os programas do negócio são partes interessadas críticas, e melhorar esse relacionamento ao longo do ciclo de vida • Estabelecer acordos de nível de serviço que estejam vinculados à prestação de contas (re­ compensas e punições) • Transferir as responsabilidades para os pro­ gramas do negócio e envolvê-los nos grupos chave de tomada de decisão Em muitas empresas, existem mecanismos esta­ belecidos para permitir a criação, participação e adesão de coligações de partes interessadas. Estes mecanismos são essenciais para garantir que o processo de tomada de decisão seja mais inclusi­ ve e representativo. Ao receber adesão antecipada das partes interessadas no processo de gerencia­ mento de portfolio, fica mais fácil garantir práti­ cas consistentes e aceitação de decisões ao longo de uma organização. A participação das partes interessadas e a adesão também podem prover sustentabilidade aos processos de gerenciamento de portfolio, quando há mudanças na liderança.

’

Ver p. 22-23 da obra citada na nota 2.

As coligações de partes interessadas têm sido construídas de muitas formas diferentes depen­ dendo da organização, do processo e do tema em questão. Com a inclusão de representantes de cada um dos principais componentes orga­ nizacionais responsáveis por priorizar as muitas iniciativas concorrentes que vão sendo propos­ tas ao longo da organização, todas as perspec­ tivas são incluídas. A abordagem, combinada com a objetividade trazida ao processo usando critérios predefinidos e um sistema de apoio à decisão, garante que todos tenham uma partici­ pação no processo e que o processo é justo. Da mesma forma, o alto órgão de tomada de de­ cisão é composto por executivos sênior de toda a empresa. Iodos os grandes projetos, ou aqueles que necessitam de uma fonte de financiamento, devem ser votados e aprovados por esse órgão de tomada de decisão. O valor de conseguir a participação das partes interessadas neste nível sênior é no que este órgão trabalha em direção a apoiar a missão global da empresa e as priori­ dades, em vez de interesses paroquiais.

Mais e mais empresas hoje estão confiando pesadamente no PMO para apoio ao gerenciamento de portfo­ lio. Atividades típicas de apoio incluem o planejamento de capacidade, utilização de recursos, análise plano de ne­ gócios e priorização de projetos. O papel do PMO nesse sentido é apoiar a alta administração, e não substituí-la. O gerenciamento de portfolio permanecerá quase sem­ pre como uma responsabilidade primordial da alta ad­ ministração, mas as recomendações e o apoio do PMO podem tornar o trabalho do executivo um pouco mais fácil. Nesse papel, o PMO pode funcionar mais como um facilitador. Algumas empresas fazem o gerenciamento de portfólio sem envolvimento do PMO. Isso é muito co­ mum quando o gerenciamento dc portfólio inclui uma grande quantidade de projetos de despesa de capital. Há obstáculos para o gerenciamento de portfólio. Os tomadores de decisão de gerenciamento de port­ fólio geralmente têm muito menos informações para avaliar os projetos candidatos do que desejam. Incertezas muitas vezes cercam a probabilidade de sucesso de um projeto, seu valor final de mercado, e seu custo total para conclusão. Essa falta de uma base de informações adequa­ da, muitas vezes leva a outra dificuldade: a falta de uma abordagem sistemática para a seleção e avaliação de pro­ jetos. Critérios de consenso e métodos para avaliar cada projeto candidato contra estes critérios são essenciais para a tomada de decisão racional. Embora a maioria das

698 empresas tenha metas e objetivos organizacionais estabe­ lecidos, estes geralmente não estão suficientemente bem detalhados para serem usados como critério para a toma­ da de decisões em gerenciamento de portfólio de projetos. No entanto, são um ponto de partida essencial.

Gerenciamento de Projetos

são necessariamente de natureza subjetiva. Assim, a vonta­ de das partes, de compartilhar abertamente e confiar nas opiniões umas das outras, se toma um fator importante.

Decisões de gerenciamento de portfólio são muitas vezes perturbadas por vários fatores comportamentais e organizacionais. I^aldades departamentais, conflitos de as­ pirações, diferenças de perspectivas, e uma falta de vontade de compartilhar abertamente informações podem frustrar a seleção de projetos, a aprovação e os processos de avalia­ ção. Muitas informações e dados de avaliação de projetos

O clima para assumir riscos ou a cultura de uma em­ presa podem também ter uma influência decisiva sobre o processo de seleção dos projetos. Se o clima é avesso ao risco, projetos de alto risco podem nunca vir à tona. Atitudes dentro da organização em relação a idéias, e o volume de idéias sendo geradas vão influenciar na quali­ dade dos projetos selecionados. Em geral, quanto maior o número de idéias criativas geradas, maiores as chances de seleção de projetos de alta qualidade.

ESTUDO DE CASO

A Contratação do Novo Presidente

4 AÇÃO JUDICIAL DE GERENCIAMENTO DE PROJETOS' Plano de Fundo

Um novo presidente foi contratado e, em seguida, rees­ truturou a empresa da forma que imaginou ser melhor para que o gerenciamento de projetos ocorresse. Ao fazer esta reestruturação, o presidente violou um acordo con­ tratual que tinha sido feito com o vice-presidente de en­ genharia contratado trés anos antes. A Contratação do Vice-Presidente

Em 2006, a Phoenix Company contratou Jim como vice-presidente de engenharia. Da mesma forma como acon­ tece com todos os diretores, o processo de contratação incluía um contrato escrito que estipulava claramente os critérios para bônus, opções de ação, pacotes de in­ denização, pacotes de aposentadoria, e indenização por cessação de funções.

A cláusula de bônus de Jim envolvia gerenciamento de projetos. Todos os projetos de engenharia seriam che­ fiados por gerentes de projeto que se reportariam diretamente a Jim. Enquanto parte do bônus de Jim era basea­ do na rentabilidade global da empresa, o preço de venda das ações da empresa, e outros fatores, a maior parte do bônus era baseada na rentabilidade dos projetos sob seu controle direto. Jim era experiente em gerenciamento de projetos e acreditava que esse plano de bônus estaria cer­ tamente a seu favor. De 2006 a 2008, seus bônus eram mais do que o seu salário real, e do tamanho do seu bônus aumentava a cada ano. A empresa estava indo muito bem e Jim estava satis­ feito com seu próprio desempenho, e se sentia seguro em sua posição na Phoenix Company.

©2010 por Harold Kerzncr. Reproduzido com permissão.

Todos os direitos reservados.

Em 2008, o presidente da Phoenix Company anunciou sua aposentadoria, que seria efetivada ao final de dezem­ bro daquele ano. O Conselho de Diretores da Phoenix Company decidiu buscar um substituto fora da empresa e, finalmente, contratou um novo presidente que tinha experiência em gerenciamento de projetos. Inicialmen­ te, Jim via isso como um fator positivo, mas isso estava prestes a mudar.

Uma das primeiras coisas que alguns executivos fa­ zem ao assumir uma empresa é reestruturar a organiza­ ção de acordo com sua desejada abrangência de controle. Isso normalmente ocorre nos primeiros dois meses de­ pois que o novo presidente assume o cargo. Os funcioná­ rios sabem que, se ocorrerem mudanças, isso se dará nos dois primeiros meses. O novo presidente conhecia gerenciamento de proje­ tos e tinha experiência em escritório de projetos (project management office - PMO). A Phoenix Company tinha gerenciamento de projetos, mas não possuía um PMO. O novo presidente criou um PMO corporativo. Os gerentes de projeto em todas as divisões já não se reportariam aos vice-presidentes de cada divisão, e foram designados em tempo integral ao PMO corporativo. O PMO corpora­ tivo se reportava diretamente ao novo presidente. Com a maioria dos PMOs, os gerentes de projeto ainda se re­ portam sobre uma “linha contínua” para seus respectivos gerentes de divisão, mas se reportam ao PMO sobre uma “linha pontilhada”.

/\ decisão do presidente de alocar os gerentes de pro­ jeto permanentemente ao PMO indispôs as três divisões que tinham gerentes de projeto, sendo que e a divisão de engenharia ficou particularmente descontente. A maioria dos gerentes de projeto estava na divisão de engenharia anteriormente. A divisão de engenharia já não tinha mais

699

O ESCRITÓRIO DE PROJETOS

controle sobre os projetos, nem mesmo sobre aqueles que estavam principalmente dentro da engenharia. A criação do PMO teve um sério impacto sobre os bônus das divisões que perderam seus gerentes de projeto. Com efeito, o que a criação do PMO fez foi transferir a res­ ponsabilidade de lucro e perda dos projetos para o PMO. Isso significava que não havería nenhum fator de rentabili­ dade do projeto como parte do bônus de final de ano de Jim. Em 2009 e 2010, os pagamentos de bônus de Jim foram drasticamente reduzidos. Em janeiro de 2011, Jim se desligou da empresa e entrou com uma ação contra a Phoenix Company pelas perdas de parte de seu pagamen­ to de bônus ao longo dos últimos dois anos. Jim e seu advogado afirmaram que a criação do PMO corporativo

e a transferência da responsabilidade de lucros e perdas para o PMO de fato violaram o acordo escrito de Jim, e afetou seu bônus. PERGUNTAS

1.

2. 3.

4.

Por que a maioria dos executivos é contratada nas empresas por meio de contratos escritos e não por meio de uma carta de aceitação de emprego de uma página? O presidente de uma empresa tem o direito de rees­ truturar a empresa da maneira que mais lhe agradar? O presidente tinha o direito de transferir a respon­ sabilidade de perdas e lucros das divisões funcio­ nais para o PMO? Será que Jim ganhou ou perdeu a ação judicial?

GERENCIAMENTO DE PROJETOS DE CRISE

24.0

INTRODUÇÃO

Os gerentes de projetos se acostumaram a gerenciar den­ tro de uma estrutura de processo, como uma metodologia empresarial de gerenciamento de projetos. A declaração do trabalho havia passado por várias iterações e estava claramente definida. Existia uma estrutura analítica do projeto e todos entendiam seus papéis e responsabilida­ des, tal como definido na matriz de responsabilidades (MR). Tudo isso levava tempo para ser feito.

Esse é o ambiente que todos nós damos como certo. Agora, vamos mudar o cenário. O presidente da empresa o chama em seu escritório e informa-o que várias pessoas simplesmente morreram apenas ao utilizar um dos pro­ dutos da sua empresa. Você está sendo colocado no co­ mando desse projeto de crise. A imprensa lota o átrio do edifício e quer ouvir de você o seu plano para enfrentar a crise. O presidente informa que a mídia sabe que você foi designado como gerente do projeto, e que uma coletiva de imprensa foi agendada para daqui a uma hora. O pre­ sidente também afirma que quer ver o seu plano para ge­ renciar a crise, o mais tardar até as 22hOO. Por onde você começa? O que deve fazer primeiro? O tempo agora é uma restrição extremamente inflexível e não apenas uma restrição possível de ser mudada. Não há tempo para rea­ lizar todas as atividades que você está acostumado a fazer. Você pode precisar tomar centenas, se não milhares, de decisões rapidamente, e muitas dessas decisões você nun­

ca pensou que teria de tomar. Esse é o gerenciamento de projetos de crise.

24.1

COMPREENSÃO DO GERENCIAMENTO DE CRISES

O campo do gerenciamento de crises é geralmente re­ conhecido como tendo começado em 1982, quando sete pessoas morreram após ingerir cápsulas de Extra-Strength Tylenol, que estavam com cianureto. A John­ son & Johnson, origem do Tylenol, lidou com a situação de tal forma que se tornou o padrão para o gerencia­ mento de crises. Hoje, as crises não são raras, nem aleatórias. Elas fa­ zem parte da nossa vida cotidiana. As crises nem sempre podem ser previstas ou evitadas, mas quando ocorrem, devemos fazer todo o possível para gerenciá-las com ra­ pidez e eficácia. Temos também de identificar as lições aprendidas e as melhores práticas, para que erros não se repitam em crises futuras que, certamente, ocorrerão. Algumas crises estão tão bem enraizadas em nossas mentes que são continuamente citadas em uma variedade de cursos em escolas de negócios. Algumas crises que se tornaram ícones na sociedade incluem:

Furacão Katrina Doença da vaca louca A explosão do ônibus espacial Challenger O desastre da reentrada do ônibus espacial Columbia Os envenenamentos por Tylenol A controvérsia da fórmula infantil Nestlé A explosão da fábrica de produtos químicos da Union Carbide em Bhopal, na índia • O derramamento de óleo do F.xxon Valdez • O desastre nuclear de Chernobyl

• • • • • • •

702

Gerenciamento de Projetos

• O desastre nuclear de Three Mile Island 9 O desastre do submarino russo Kursk • A falência da Enron e da Worldcom

Algumas crises são o resultado de força maior ou de desastres naturais. O público é, geralmente, clemente quando isso acontece. O gerenciamento de crises, no en­ tanto, trata principalmente de crises provacados pelo ho­ mem como a adulteração de produtos, fraude e contami­ nação ambiental. Ao contrário dos desastres naturais, essas catástrofes provocadas pelo homem não são inevitáveis e o público em geral sabe disso e é completamente implacável. Quando o vazamento de óleo do Exxon Valdez ocorreu, a Exxon se recusou a enfrentar a mídia durante cinco dias. No final, a Exxon culpou o capitão do navio pelo acidente e também atacou o Departamento de Meio Ambiente do Alasca por dificultar os esforços de emergência. A obstru­ ção à mídia e a adoção de uma postura defensiva geraram uma publicidade negativa extensa para a Exxon. A maioria das empresas não possui nem processos em andamento para antecipar essas crises, mesmo apesar de realizar atividades de gerenciamento de riscos, nem sabe como lidar com elas de forma eficaz depois que elas ocorrem. Quando vidas são perdidas por causa de crises provocadas pelo homem, o público, implacável, torna-se extremamente crítico com as empresas responsáveis pela crise. As reputações corporativas são muito frágeis. Re­ putações que levaram anos para serem firmadas podem ser destruídas em horas ou dias.

Algumas pessoas argumentam que, com práticas eficazes dc gerenciamento de riscos, essas crises podem ser evitadas. Embora seja verdade que olhar para os gati­ lhos de riscos pode impedir algumas crises, nem todas as crises podem ser evitadas. No entanto, melhores práticas em gerenciamento de crises podem ser desenvolvidas e implementadas, de forma que, quando ocorrer uma crise, possamos evitar que uma situação ruim fique pior. Durante algum tempo, as corporações de setores es­ pecíficos descobriram que é necessário simular e anali­ sar os piores cenários para os seus produtos e serviços. A adulteração do produto seria um exemplo. Esses piores cenários tém sido chamados de planos de contingência, planos de emergência ou planos de desastre. Esses cená­ rios são projetados em tomo dos riscos “conhecidos des­ conhecidos”, quando pelo menos existe informação par­ cial sobre os eventos que poderíam acontecer. O gerenciamento de crises exige uma abordagem alerta com um tempo de reação muito rápido, combinado a um esforço orquestrado por parte de, possivelmente, todos os funcionários. No gerenciamento de crises, as decisões têm de ser tomadas rapidamente, muitas vezes sem informação

parcial e, talvez, antes que toda a extensão dos prejuízos seja conhecida. Os eventos acontecem tão rapidamente e tão imprevisivelmente, que pode ser impossível realizar qualquer tipo de planejamento. Os papéis e responsabilidades de in­ divíduos fundamentais podem mudar em uma base diária. Pode haver o envolvimento ativo da maioria das partes in­ teressadas, muitas das quais haviam estado silenciosas an­ teriormente. A sobrevivência da empresa poderia depender completamente de o quão bem a empresa gerencia a crise.

As crises podem ocorrer dentro de qualquer em­ presa, independentemente do tamanho. Quanto maior a empresa envolvida na crise, maior será a cobertura da mí­ dia. Além disso, as crises podem ocorrer quando as coisas estão indo muito bem. O guru da administração, Peter Drucker, observou que as empresas que têm sido extre­ mamente bem-sucedidas por um longo tempo tendem a tornar-se complacentes, embora as premissas iniciais e as condições ambientais tenham mudado. Sob essas condi­ ções, as crises têm mais probabilidade de ocorrer. Dru­ cker chamou isso de “fracasso do sucesso”. O gerenciamento de crises é agora uma parte inte­ grante dos programas de treinamento sobre responsabili­ dades profissionais para gerentes de projetos. Isso envolve lidar com uma variedade de partes interessadas, ser ho­ nesto com a mídia e com os clientes, e demonstrar uma sincera preocupação com a moralidade e a ética no geren­ ciamento de projetos.

Antes das discussões sobre o papel do gerente de pro­ jetos, é importante examinar as lições aprendidas das crises anteriores. O que é lamentável é que a maioria das lições aprendidas virá do tratamento inadequado da crise.

24.2

FORD

VERSUS FIRESTONE

Os recalls de produtos são caros e embaraçosos para a in­ dústria automobilística. O tratamento inadequado de um recall pode ter um efeito adverso na confiança do consu­ midor e no preço de venda das ações. A Ford e a fabri­ cante de pneus Firestone ainda sofrem as repercussões do seu tratamento ao recall dc um de produto em 2000-2001.

Em agosto de 2000, a Firestone fez o recall de 6,5 mi­ lhões de pneus nos Estados Unidos, principalmente por causa de problemas de separação da banda de rodagem no Ford Explorer [veículos utilitários esportivos (SUV)]. Os problemas com os pneus eram conhecidos havia vá­ rios anos. Em 1997-1998, a Arábia Saudita informou so­ bre a separação da banda de rodagem no SUV Explorer. Em agosto de 1999, a Firestone substituiu os pneus na Arábia Saudita. Em fevereiro de 2000, a Firestone subs­ tituiu os pneus na Malásia e na Tailândia e, em maio de 2000, os pneus foram substituídos na Venezuela.

703

GERENCIAMENTO DE PROJETOS DE CRISE

Inicialmente, acreditava-se que o problema podia ser restrito a países de clima quente e estradas ruins. No entanto, em maio de 2000, o órgão responsável pela se­ gurança viária dos Estados Unidos, o NHTSA (National Highway Traffic Safety Administration) recebeu 90 denún­ cias envolvendo 27 feridos e 4 mortes. Um recall de 6,5 milhões de pneus ocorreu em agosto de 2000, nos Estados Unidos. A Ford e a Firestone adotaram uma resposta unifica­ da sobre o recall. Infelizmente, os acidentes continuaram após o recall. A Ford, então, culpou a Firestone por falhas nos pneus e a Firestone culpou a Ford por falhas de design no SUV Explorer. A relação Ford-Firestone se deteriorou rapidamente. A troca de acusações entre as duas empresas era notícia suculenta para a mídia. Como nenhuma das em­ presas estava disposta a aceitar a responsabilidade por suas ações, provavelmente por causa das ações judiciais iminentes, a confiança dos consumidores diminuiu em ambas as empresas, assim como os preços de suas ações. O sentimento do consumidor era de que os fatores fi­ nanceiros eram mais importantes do que a segurança do consumidor.

O CEO da Ford, Jac Nasser, tentou acalmar os receios dos consumidores, mas suas ações não apoiavam suas pa­ lavras. Em setembro de 2000, ele se recusou a depor no Senado e na Subcomissão da Câmara de Comércio sobre o recall de pneus, informando que estava muito ocupado. Em outubro de 2000, Masatoshi Ono renunciou ao cargo de diretor executivo da Bridgestone, matriz da Firesto­ ne. Em outubro de 2001, Jac Nasser renunciou. Ambos os executivos partiram e deixaram para trás mais de 200 ações movidas contra suas empresas. Lições Aprendidas

1. 2.

3.

24.3

Os sinais precoces de alerta surgiram, mas foram mediocremente abordados. Uma empresa culpou a outra, deixando o público com a crença de que nenhuma delas poderia ser confiável, no que diz respeito à segurança pública. As ações devem reforçar as palavras, caso con­ trário, o público vai se tornar descrente. 0 ACIDENTE D0

CONCORDE DA AIR

FRANCE

Em 25 de julho de 2000, um voo Concorde, da Air Fran­ ce, caiu na decolagem matando todas as 109 pessoas a bordo e 4 pessoas em solo. A Air France imediatamente suspendeu toda a sua frota de Concorde durante uma in­ vestigação do acidente. Em resposta à pressão da mídia, a Air France utilizou o seu website para comunicados à im­ prensa, manifestou o pesar e as condolências da empresa

e organizou-se para que alguma contrapartida financeira fosse paga aos familiares das vítimas antes de uma solução legal completa. O presidente da Air France, Jean-Cyril Spinetta, visitou a cena do acidente, no dia do acidente e, mais tarde, participou de um serviço memorial para as vítimas.

O tratamento da Air France para a crise foi carac­ terizado por uma comunicação rápida e aberta com os meios de comunicação e sensibilidade aos familiares das vítimas. O preço de venda das ações declinou rapidamen­ te no dia do desastre, mas teve uma rápida recuperação. A British Airways (BA), também voava com o Con­ corde, mas teve uma abordagem diferente imediatamente na sequência do acidente. A BA esperou um mês antes de interromper todas as linhas Concorde indefinidamente, e só depois que a Autoridade de Aviação Civil anunciou que a re­ tiraria a certificação de aeronavegabil idade do Concorde. No final, a certificação de aeronavegabilidade foi reinte­ grada, mas demorou significativamente mais tempo para as ações da BA se recuperarem do seu declínio no preço. Lições Aprendidas

1. A Air France e a British Airways tiveram aborda­ gens diferentes para a crise. 2. O presidente da Air France mostrou compaixão por visitar o local da catástrofe o mais rapidamente possível e assistir a um serviço memorial para as ví­ timas. A British Airways não fez nenhum dos dois ignorando, assim, sua responsabilidade social. 24.4

A INTEL E0 CHIP PENTIUM

?X Intel, fabricante dos chips Pentium, sofreu um momento embaraçoso, resultante de um recall de produtos. Um pro­ fessor de matemática, ao realizar cálculos de números pri­ mos de dez dígitos, descobriu importantes erros de arredon­ damento ao utilizar os chips Pentium. /X Intel achou que os erros eram insignificantes e que aparecería apenas a cada al­ guns bilhões de cálculos. Mas o matemático estava executan­ do bilhões de cálculos e os erros eram, agora, significativos.

O professor informou à Intel sobre o problema. A Intel se recusou a tomar medidas, alegando que esses erros eram extremamente raros e que afetariam apenas uma pequena porcentagem de usuários do Pentium. O professor veio a público com a divulgação do erro. De repente, a pequena porcentagem de pessoas des­ cobrindo o erro não era tão pequena quanto pensado inicialmente. A Intel ainda insistia em sua convicção de que o erro afetaria apenas uma pequena porcentagem da população. A Intel colocou o peso da responsabilidade sobre o usuário para mostrar que suas aplicações exigiam uma substituição de chip. Os protestos dos consumidores ficaram mais fortes. Finalmente, a empresa concordou

704

Gerenciamento de Projetos

em substituir todos os chips, sem perguntas, depois que a IBM anunciou que deixaria de usar chips Pentium em seus computadores pessoais.

A Intel criou o seu próprio pesadelo de relações pú­ blicas. Sua resposta foi lenta e insincera. A Intel tentou resolver o problema apenas por meio dos canais técni­ cos e desconsiderou completamente a questão humana da crise. Dizer às pessoas que trabalham em hospitais ou no controle de tráfego aéreo que existe uma falha em seu computador, mas que ela é insignificante, não é uma resposta aceitável. A Intel gastou mais de meio bilhão de dólares no recall, significativamente mais do que o custo de uma substituição imediata. Lições Aprendidas

1.

2. 3. 24.5

/X incapacidade da Intel em assumir a responsabi­ lidade imediata pela crise e desenvolver um plano de gerenciamento de crise piorou a situação. A Intel ignorou totalmente a opinião pública. A Intel falhou em perceber que existia uma crise. 0 SUBMARINO RUSSO

KURSK

Em agosto de 2000, o naufrágio do submarino nuclear Kursk resultou na morte de 118 tripulantes. Talvez a tripulação nunca pudesse ter sido salva, mas a maneira como a crise foi gerenciada foi uma grande derrota, tanto para a Marinha quanto para o governo russos.

Em vez de fornecer declarações honestas e sinceras para a mídia, o Ministério da Defesa Russo tentou minimi­ zar a crise por meio da divulgação de informações engano­ sas, dizendo ao público que o submarino havia encalhado durante um exercício de treinamento e que a tripulação não corria nenhum perigo imediato. O ministério espa­ lhou um boato de que tinha havido uma colisão com um submarino da NATONTI. Finalmente, a verdade veio à tona e, no momento em que os russos procuraram ajuda para montar uma missão de resgate, já era tarde demais. Vladimir Putin, presidente da Rússia, recebeu enor­ me publicidade desfavorável pelo seu tratamento da crise. Ele estava de férias no sul do país no momento e apareceu na televisão russa vestindo roupas informais, afirmando que a situação estava sob controle. Ele, em seguida, desa­ pareceu de vista por vários dias, o que irritou o público e os familiares dos membros da tripulação, indicando sua relutância em envolver-se pessoalmente na crise. Quando ele finalmente visitou a base do Kursk, foi recebido com raiva e hostilidade.

Lições Aprendidas

Mentir para o público é imperdoável. A Rússia falhou em revelar a gravidade da crise. A Rússia falhou em solicitar ajuda a outros paí­ ses de forma oportuna. 4. A Rússia demonstrou falta de responsabilidade social pela recusa em comparecer ao local da crise e falta de compaixão pelas vítimas e suas famílias. 1. 2. 3.

24.6

OS ENVENENAMENTOS POR TYLENOL

Em setembro de 1982, sete pessoas morreram após tomar Tylenol Extra-Strength alterado com cianureto. Todas as vítimas eram relativamente jovens. Esses óbitos foram os primeiros a resultar no que veio a ser conhecido como adulteração de produto. Todas as sete pessoas morreram dentro do período de tempo de uma semana. Os sinto­ mas de envenenamento por cianureto são colapso rápido e coma, difíceis de tratar. Na manhã do dia 30 de setembro de 1982, os jornalis­ tas começaram a ligar para a sede da Johnson & Johnson, perguntando por informações sobre o Tylenol e pela rea­ ção da Johnson & Johnson às mortes. Essa foi a primeira vez que a Johnson & Johnson tinha ouvido falar sobre as mortes e a possível ligação com Tylenol.

Desde o início, a empresa viu-se entrando em um relacionamento mais próximo com a imprensa do que de costume. A Johnson & Johnson recordou amargamente de um incidente, nove anos antes, em que a mídia divulgou um relatório sugerindo que alguns talcos para bebê tinham sido contaminados por amianto. Mas, no caso do Tylenol, a Johnson & Johnson abriu as suas portas. Por um lado, a empresa estava recebendo algumas das informações mais precisas e atualizadas sobre o que estava acontecendo em todo o país a partir dos jornalistas que solicitavam comen­ tários. Por outro lado, a Johnson & Johnson precisava da mídia para liberar o máximo dc informações para o públi­ co o mais rápido possível e evitar pânico. O chairman da Johnson & Johnson era James Burke, 57, um veterano com 30 anos de Johnson & Johnson. O Sr. Burke tinha de proteger a imagem da empresa, afastar os receios que o público pudesse ter na utilização dos produ­ tos Tylenol e trabalhar com uma multiplicidade de partes interessadas, incluindo agências governamentais. Burke decidiu ser o porta-voz para a mídia e encarregou-se pes­ soalmente do projeto de crise na Johnson & Johnson.

O estudo de caso completo do Tylenol é muito extenso para

ser incluído aqui. Para informações adicionais e detalhes sobre

a crise do Tylenol, ver The Tylenol Tragedies. In: KERZNER, KTI North Atlantic Treaty Organization (NATO), ou Organização

di) Tralado do Atlântico Norte (OTAN).

Harold. Project management case studies. 3. cd. Hoboken, NJ: Wiley, 2006. p. 509-536.

705

GERENCIAMENTO DE PROJETOS DE CRISE

GERENCIAMENTO DAS PARTES INTERESSADAS

Burke tinha várias opções disponíveis sobre como lidar com a crise. A decisão sobre qual opção selecionar seria certamente difícil. Preocupadas com Burke estavam as partes interessadas que seriam afetadas pela decisão da Johnson & de Johnson. Entre elas, estavam os acionistas, as instituições de empréstimos, os trabalhadores, gestores, fornecedores, agências governamentais e consumidores. Os Consumidores

Os consumidores tinham a maior participação na crise porque suas vidas estavam em jogo. Eles deviam ter confiança nos produtos que compravam e acreditavam ser seguros para a utilização conforme a orientação. Os Acionistas

Os acionistas tinham um interesse financeiro no pre­ ço de venda das ações e nos dividendos. Se os custos de remoção e substituição, ou, no pior cenário, um redese­ nho do produto, fossem substanciais, isso poderia levar a uma dificuldade financeira para alguns investidores que estavam confiando no rendimento. As Instituições de crédito

As instituições de crédito concedem empréstimos e linhas de crédito. Se o fluxo de receita presente e/ou futu­ ro é prejudicado, então, os fundos disponíveis podem ser reduzidos e a taxa de juros poderia aumentar. O fluxo de receitas futuras de seus produtos poderia afetar a classifi­ cação da qualidade da sua dívida. 0 Governo

A principal preocupação do governo era proteger a saúde pública. Em respeito a isso, a polícia estava em­ penhada em apreender o assassino. Outras agências go­ vernamentais forneceríam assistência na promoção e no design de embalagens resistentes à adulteração em um es­ forço para restaurar a confiança dos consumidores. A Administração

A administração da empresa tinha a responsabilida­ de dc proteger a imagem da empresa, bem como a sua rentabilidade. Para fazer isso, ela deveria convencer o público de que seguiria todos os passos necessários para proteger o consumidor. Os Funcionários

Os funcionários têm as mesmas preocupações que a administração, mas também são um pouco preocupados com a possível perda de rendimento ou mesmo do emprego.

Seja qual for a decisão que a Johnson & Johnson selecionasse certamente desagradaria a pelo menos algu­ mas das partes interessadas. Portanto, como uma empre­ sa decide quais necessidades das partes interessadas são mais importantes? Como uma empresa prioriza as partes interessadas?

Para Jim Burke e todo o comitê estratégico, a decisão não foi muito difícil - bastou seguir o credo corporativo. Por mais de 45 anos, a Johnson & Johnson tinha um cre­ do corporativo que afirmava claramente que a primeira prioridade da empresa são os usuários dos produtos e serviços da Johnson & Johnson. Todos sabiam o credo, o que ele representava e o fato de que ele devia ser seguido. O credo corporativo orientou o processo da tomada de decisão e todos o conheciam, sem ter de ser avisados. O credo afirmava que as prioridades eram, pela ordem: 1. 2. 3. 4.

Os consumidores Os empregados As comunidades servidas Os acionistas

Quando a crise terminou, Burke lembrou que ne­ nhuma reunião havia sido convocada para a primeira decisão crítica: estar aberto à imprensa e colocar o inte­ resse do consumidor em primeiro lugar. “Cada um de nós sabia o que tinha de fazer”, comentou o Sr. Burke. “Não havia necessidade de nos reunirmos. Tínhamos a filosofia do credo para nos guiar.” Elogios

Algumas pessoas acreditavam que James Burke sal­ vou o Tylenol praticamente sozinho, principalmente quando Wall Street acreditava que o nome Tylenol estava morto. Burke tomou algumas decisões corajosas contra o conselho de agentes do governo e alguns de seus pró­ prios colegas. Ele apareceu em vários talk shows, como o Phil Donahue Show e 60 Minutes. Sua abordagem aber­ ta e honesta para a crise convenceu as pessoas de que a Johnson & Johnson também era uma vítima. Segundo o porta-voz da Johnson & Johnson, Bob Andrews, “O pú­ blico americano viu que essa empresa também foi vítima de um incidente lamentável e nos deu o nosso mercado de volta".

Tanto a Johnson & Johnson quanto James Burke rece­ beram nada mais que elogios e apoio da mídia e do público em geral sobre a forma como a crise foi tratada. Uma amos­ tragem da opinião dos jornais nos Estados Unidos inclui:

•

Wall Street Journal:" Johnson & Johnson, a empre­ sa matriz que fabrica o Tylenol, define o padrão de resposta para a indústria. Sem ser solicitada.

706

Gerenciamento de Projetos

•

•

•

•

ela rapidamente retirou o Tylenol Extra-Strength do mercado, a uma despesa muito considerável... A empresa optou por ter uma grande perda, em vez de expor qualquer pessoa a um risco adicio­ nal. O movimento anticorporação pode ter difi­ culdade em enquadrar isso nas teorias diabólicas que propaga.”

5.

Washington Post: “Ainda que a histeria e a frustra­ ção gerada pelos assassinatos aleatórios tenham, muitas vezes, obscurecido as ações da empresa, a Johnson & Johnson tem demonstrado de forma eficaz como um grande negócio deve lidar com um desastre. A partir do dia em que as mortes foram ligadas ao Tylenol envenenado... a Johnson & Johnson tem obtido êxito em retratar-se ao pú­ blico como uma empresa disposta a fazer o que é certo, independentemente do custo.”

8.

Express and News (San Antonio, Texas): “Apesar da perda de S 100 milhões que estava enfrentando, a empresa... nunca colocou os seus interesses antes da resolução dos assassinatos e da proteção ao público. Tal responsabilidade corporativa merece apoio.” Evening Independent (St. Petersburg, Flórida): “A empresa tem sido direta e honesta desde a pri­ meira notícia da possível ligação do Tylenol com as mortes na região de Chicago. Algumas em­ presas teriam tentado esconder, mentir ou dizer “sem comentários". A Johnson & Johnson sabe como fazer as coisas. Sua primeira preocupação foi salvaguardar o público de maior contamina­ ção, e a melhor maneira de fazer isso era deixar as pessoas saberem o que havia ocorrido, falando francamente com a mídia.” Morning News (Savannah, Geórgia): “Os fabri­ cantes de Tylenol merecem aplausos pela sua co­ rajosa tentativa de se recuperar do golpe terrível que sofreram."

Lições Aprendidas

1. Em projetos de crise, o patrocinador (executivo) do projeto estará envolvido de forma mais ativa e pode acabar atuando como gerente do projeto também. 2. O patrocinador do projeto deve atuar como porta-voz da empresa, responsável por todas as comunicações da crise. Fortes habilidades de co­ municação são, portanto, obrigatórias. 3. Comunicações abertas e honestas são essenciais, especialmente com a mídia. 4. A empresa deve mostrar uma consciência social, bem como uma preocupação sincera pelas pes­ soas, sobretudo as vítimas e suas famílias.

6.

7.

9.

10.

11.

12. 13. 14. 15.

24.7

O gerenciamento das partes interessadas com demandas conflitantes é essencial. A empresa, e especialmente o patrocinador do projeto, deve manter um relação de trabalho es­ treita com a mídia. Uma comissão de crise deve ser formada e com­ posta pelos mais altos níveis de gestão. Os credos corporativos podem encurtar o tempo de resposta durante uma crise. A empresa deve estar disposta a procurar a ajuda de todas as partes interessadas e, possivelmente, também agências governamentais. A responsabilidade social corporativa deve ser uma prioridade muito superior à rentabilidade das empresas. A empresa, especificamente o patrocinador do projeto, deve aparecer no cenário da crise e de­ monstrar uma sincera compaixão para com as famílias das vítimas. A empresa deve tentar evitar que uma má situa­ ção se agrave. Gerencie a crise, como se todas as informações fossem de conhecimento público. Aja rapidamente e com sinceridade. Assuma a responsabilidade por seus produtos e serviços e pelo seu envolvimento na crise. 0 MARKETING DA FÓRMULA INFANTIL

DA NESTLÉ

Durante uma crise, as empresas têm a obrigação de de­ monstrar responsabilidade social, com sorte, sem qualquer impacto sobre a rentabilidade. Durante os últimos 40 anos, as leis, diretrizes e códigos foram promulgados; não apenas para mostrar como essa responsabilidade social pode ser aplicada, mas também para garantir que essa aplicação seja feita de forma ética e sem qualquer dano à sociedade. Mas o que acontece se as diretrizes, códigos e leis são inexis­ tentes? O que acontece se a corporação realmente acredita que está fazendo um bom serviço para a humanidade, mas, ao mesmo tempo, parte da sociedade acredita que ocorreu uma injustiça? Tal foi o caso da Nestlé, no qual a adminis­ tração corporativa acreditava enfaticamente que a empresa estava fazendo um bom serviço para a humanidade com a distribuição da fórmula infantil para as nações do Tercei­ ro Mundo. Contudo, a mortalidade infantil, estimada em milhares, ocorreu em países do Terceiro Mundo como um resultado da campanha agressiva de marketing da Nestlé. A Fórmula Infantil da Nestlé

A entrada da Nestlé na indústria da fórmula infantil foi derivada de um desejo de aumentar a rentabilidade e

707

GERENCIAMENTO DE PROJETOS DE CRISE

conquistar uma maior fatia de mercado. A Nestlé come­ çou a desenvolver e comercializar a sua fórmula infantil na década de 1920, quando as fórmulas infantis foram comprovadas como nutricionalmente melhores do que o leite condensado para o bebé e uma alternativa de su­ cesso à amamentação. A Nestlé entrou primeiramente nos mercados do Terceiro Mundo, no Brasil, e expandiu ao longo dos 50 anos seguintes em cerca de 20 mercados adicionais de Terceiro Mundo. É importante notar que

Os consumidores dos países do Terceiro Mundo rece­ beram produtos da Nestlé que não poderiam ser usados corretamente. As restrições ambientais, juntamente com recursos e orientações impróprios, tornaram um mer­ cado muito arriscado para a Nestlé atingir, a menos que os consumidores recebessem informações básicas sobre saneamento e nutrição. A Nestlé não conseguiu garantir esse tipo de consciência e, mais importante ainda, falhou em providenciar responsabilidade social.

a Nestlé nunca pretendeu que a fórmula infantil servis­ se como um substituto ao leite materno, mas como um complemento.

A Crescente Oposição

O produto, em si, era de alta qualidade e nutricio­ nalmente superior a outras alternativas de produtos pro­ cessados. O produto poderia atender a uma necessidade nutricional como um suplemento para a amamentação e como uma segunda melhor alternativa quando as mu­ lheres que eram incapazes ou não desejavam amamen­ tar. Portanto» o produto poderia ser socialmente útil. O produto, em si, não foi o problema, mas seu mau uso. A probabilidade de má utilização do produto era maior para alguns consumidores do que outros. Nesse caso específico, eram os consumidores de baixa renda e baixa escolaridade nos países do Terceiro Mundo que a Nestlé tinha como alvo, os quais eram os mais vulneráveis.

Conforme a notícia se espalhou sobre os trágicos acontecimentos da fórmula infantil que ocorriam em países do Terceiro Mundo, muitos críticos começaram a levantar suas vozes e a exigir mudanças nas práticas de marketing da Nestlé. Finalmente, um grupo de boicote se formou e obteve apoio em grande escala de profissionais médicos e do clero. Os boicotadores nunca questionaram a qualidade, a necessidade e a importância da fórmu­ la infantil. Eles eram simplesmente contra a campanha de marketing agressiva nos países do Terceiro Mundo. A Nestlé manteve a sua posição original, a de que estava fa­ zendo uma boa ação para a sociedade, mas a opinião pú­ blica ficou com os boicotadores. No final, a Nestlé cedeu às demandas dos boicotadores.

Má Utilização do Produto

Lições Aprendidas

O produto é nutricionalmete benéfico para o bebê apenas se for misturado com água e servido em frascos limpos e esterilizados, armazenados em refrigeradores. Muitos consumidores nos países do Terceiro Mundo não poderiam cumprir com esses requisitos do produto. Mui­ tos desses consumidores pobres não tinham acesso à água limpa e potável. Eles, às vezes, utilizavam os abastecimen­ tos principais de água, rios ou lagos, que também eram utilizados para lavar roupa e tomar banho. Não tinham recursos para pagar o combustível necessário para ferver a água. As instalações sanitárias e os sistemas de coleta de detritos, muitas vezes, eram precárias e contaminados. Uma garrafa ou líquido insalubre pode produzir infec­ ções prejudiciais à criança. Alguns pais, nos países do Terceiro Mundo, eram analfabetos e não eram totalmente capazes de seguir as indicações do produto. As mães não misturavam adequadamente as fórmulas ou seguiam os procedimentos sanitários. A falta de recursos financeiros também os impedia de comprar a fórmula adicional ne­ cessária, fazendo com que as mães diluíssem a mistura da fórmula para fazer o produto durar mais.

As seguintes lições podem ser aprendidas com a crise da Nestlé:

Todas estas formas de uso indevido do produto cau­ saram graves e fetais efeitos sobre a saúde de lactentes.

A ações da Nestlé não demonst ravam que a empre­ sa tinha responsabilidade social. Suas ações podem ter sido legalmente corretas, mas eram também moral e eticamente incorretas. 2. A Nestlé deveria ter usado a mídia em sua vantagem, em vez de atacá-la Isso tomou a situação ainda pior. 3. A Nestlé permaneceu em um estado de negação so­ bre a crise e recusou-se a aceitar a responsabilidade por suas ações. Como resultado, a mídia procurava incansávelmente por segredos vergonhosos, encon­ trava alguns, e relatava os resultados ao público. 4. A Nestlé considerou que o público era ignorante quanto à magnitude da crise. 5. Quanto mais a crise atrai a atenção do público, maior a tendência de a empresa ser retratada como vilã e não como uma vítima. 6. Por causa da inércia da Nestlé, o tamanho e a influência do boicote cresceram. 7. /X Nestlé finalmente ficou sem opção e a imagem corporativa ficou manchada por causa da inércia. 1.

708

Gerenciamento de Projetos

8. A Nestlé foi negligente em perceber a importân­ cia de demonstrar uma preocupação com as pes­ soas durante a crise. 24.8

0 DESASTRE DO ÔNIBUS ESPACIAL

CHALLENGER Em 28 de janeiro de 1986, o ônibus espacial Challenger decolou da plataforma de lançamento às 11 h38. Em cer­ ca de 74 segundos de vim», a Challenger foi envolvida em um incêndio explosivo e toda a comunicação e telemetria foram cessadas. Os sete tripulantes perderam suas bra­ vas vidas. Após o acidente, foi gasta energia significativa tentando verificar se o acidente seria ou não previsível. A controvérsia surgiu do desejo de atribuir ou de evitar a culpa. Algumas publicações chamaram de uma falha de gestão, especificamente em gerenciamento de riscos, en­ quanto outros chamaram de uma falha técnica. Lições Aprendidas

As seguintes lições foram aprendidas com o desastre do Challenger.

1. A crise foi criada por uma fraca cultura organi­ zacional. 2. Houve significativos sinais de alerta que, se aten­ didos, poderiam ter evitado a crise. Eles foram ignorados. 3. A cadeia de comando isolou os gerentes e execu­ tivos das más notícias. 4. A administração se recusou a ouvir os trabalha­ dores que estavam implorando por ajuda. 5. Havia uma preocupação questionável pela vida humana indicada pela pressão em manter o cro­ nograma a todo custo. 24.9

0 DESASTRE DO ÔNIBUS ESPACIAL

COLUMBIA

Em I de fevereiro de 2003, o ônibus espacial Co­ lumbia começou a sua reentrada na atmosfera. O ônibus dependia de materiais resistentes ao calor e do escudo contra o calor para protegê-lo do atrito produzido pelo calor encontrado durante a reentrada. Infelizmente, ocorreu um problema e o ônibus espacial se desinte­ grou durante a reentrada na atmosfera, matando seus sete tripulantes.

Um Conselho de Investigação do Acidente com o Columbia foi convocado para tratar do acidente. Sete meses mais tarde, o conselho liberou seus resultados. As causas técnicas do acidente foram rastreadas para a de­ colagem, quando um grande pedaço de isolamento do tanque de combustível se deslocou, bateu e danificou as placas antitérmicas na borda principal da asa esquerda do Columbia, abrindo um buraco. Os componentes de metal do ônibus derreteram a cerca de 1093 °C. As pla­ cas antitérmicas derreteram a cerca de 1648 °C. As pla­ cas evitam que o calor de reentrada de 5.537 °C penetre o veículo. Durante a reentrada, o calor foi, então, capaz de penetrar a ah esquerda, acabando por fundir a parte da estrutura interna da asa fazendo com que ele entrasse em colapso, e resultando na perda de controle do ônibus durante a reentrada. Embora o isolamento expelido tenha sido a causa técnica ou física do acidente, o Conselho de Investiga­ ção do Acidente concluiu que a cultura da NASA estava igualmente em falta no acidente e que foi um prejuí­ zo para a segurança. Essas conclusões declararam que a NASA se baseou no sucesso do passado como um subs­ tituto para a engenharia segura. A NASA mantinha bar­ reiras organizacionais, evitando a comunicação de in­ formações críticas de segurança e abafava as diferenças de opinião profissionais.4 Em especial, o conselho iden­ tificou atitudes na NASA que eram “incompatíveis com uma organização que lida com tecnologia de alto risco.”5 O conselho também concluiu que a gerência do pro­ grama do ônibus espacial demonstrou uma forte resis­ tência a novas informações e tecnologias que poderiam ter sido capazes de evitar o desastre. A gerência também falhou em desenvolver um simples plano de contingência para uma reentrada de emergência. “Eles estavam con­ vencidos, sem estudo, deque nada poderia ser feito em tal emergência. A curiosidade intelectual e o ceticismo que uma cultura de segurança sólida demanda estavam quase total mente ausentes”.6

Enquanto essas conclusões estavam prejudicando a credibilidade da NASA, havia ainda mais conclusões preju­ diciais. Muitas das questões críticas abordadas pelo Conse­ lho de Investigação do Acidente com o Columbia também tinham sido identificadas 17 anos antes pela Comissão Pre­ sidencial de investigação do desastre do Ônibus Espacial Challenger. As lições aprendidas com a catástrofe do Chal-

Neste capitulo .são fornecidas apenas informações resumidas. Para uma análise mais aprofundada sobre o caso, rt: The Space Shuttle

Challenger Disaster.ln: KERZNER, Harold. Project management

4

Ven Columbia Accident Investigation Board, Report Volume 1, p. 9,1 ago. 2003. Disponível em: .

Columbia Disaster. In: KERZNER, Harold. Project management

5

Ver nota 4, Columbia Accident Investigation Board, p. 8.

case studies. 4. ed. Hoboken, NJ: Wiley, 2012. p. 457-503.

•

Ver nota 4, Columbia Accident Investigation Board, p. 181.

709

GERENCIAMENTO DE PROJETOS DE CRISE

tenger ainda não tinham sido plenamente implementadas cerca de 17 anos depois. Lições Aprendidas

As seguintes lições foram aprendidas com o desastre do Columbia:

1. 2. 3. 4.

24.10

O planejamento de riscos era praticamente inexistente. Não havia planos de contingência para várias das partes de alto risco do voo espacial. Havia um programa de segurança implícito em vigor. Houve uma transferência deficiente de conheci­ mento, especialmente das lições aprendidas, do desastre com o Challenger. VÍTIMAS

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.

Snclde/Jet Precoce

Eríerdrerto doPiottema

Adaõo das Donos

ResoLçõc doGise

bções

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. Durante o envenenamento por Tylenol, a abertura da Johnson & Johnson com a mídia, a vontade em aceitar a plena responsabilidade por seus produtos e a resposta rápida à crise, independentemente do custo, certamente foram vistos positivamente pelo público em geral. A John­ son & Johnson foi reconhecida como uma vítima da crise. A Nestlé, por outro lado, era vista como vilã, apesar da sua crença de que estivesse fazendo bem para a humanidade com a sua comercialização das fórmulas para lactentes. A Tabela 24-1 mostra como o público em geral viu o desempenho das empresas durante a crise. Quanto mais tempo durar a crise, maior a tendência de que a empresa será retratada como vilã.

TABELA 24-1

24.11

Visõo do Público sobre o Desempenho da Empresa

Giso

Frr#enenomentos per Tyiencl Nestlé e o Fâmulo Infonlil Explosoo do (tótenga Desastre do reentrado do Denomomentc de óleo do Exxon Yeldez Sibmorro Russo M Ford e Firestone Concorde. Air Fronte Concorde: British Airways Irtel e o Pentium

Visão do Opinião Púbico Vitimo Wò Vfc Vilã viõ Vtó Vilãs Vitima Viõ Vfc

(ar jrKDióes (ar a Feríes Interssafe

FIGURA 24-1

Fases do ciclo de vida do gerenciamento de crises.

/X 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 de avaliar todos os riscos. Portanto, as empresas devem ser seletivas quanto aos riscos que consideram. A fase seguinte do ciclo de 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 cido 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 Intd 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 agências 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. 1,12 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 e 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

TABELA 25-1 Visão executiva do gerenciamento de projetos

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

Visõo Antigo

Visão Novo

0 gerencomento de projetos e im done

0 gerenciamento de projetos é uno

de careiro

competência estratégico ou central

Precisamos de nosso pessool ceriíicodc

Precisamos de pessoos canficocfas em

*s comoPMP

geraxiomento de projetos, processos de negócio, e possrvdmerte em outros áreas

como geraxiamailo de pregemos e

geraxnmento efe riscos 0 gerencomento de projetos e irn processo

0 gerencomento de projetos evoluiu mas

pao o trobdbo de execução do projeto

como um processe de negócios do qje 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.

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.

Nossos gaentes de projeto precsom

Precisamos de treinamento especidizodo

de heromento sobre comportamento

em compcrtomaito orgonzocxncl,

otgonzoccnol tiodkionol

induhdo temos como equpes virtuas,

gerenciamento de relocionamaito com

portes rieressodas e gestoo do dwsdode

0s Executivos Mudam sua Visão sobre a Importância do Gerenciamento 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 dc tornar-se PMP®, um gerente dc projetos pode desejar certificar-se em:

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 Kretz 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 faz da disciplina de gerenciamento de projetos um processo de negócio essencial do século XXI.

• 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

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.

Algumas empresas têm conselhos de certificação que se reúnem com frequência e discutem quais programas dc 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

3

L. Kretz 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

Gerenciondo Projetos Trodeionots

Gerenciondo Projetos Nõo Tradicionais

Patrocinio de umo único pessoo

Governança per comitê

Pcssiwlmento umo único porto interessodo

Vonos portes interessados

lomodo de deersõo de projeto

lomodo de deersõo de projeto e de negócio

Metodclogro de gerenciamento de projeto

Metodologia de gerenciamento de projeto

ríleÓYel

flexível ou 'fluido'

Rekíóoo de slums perodxo

Rekíóoo em tempo red

0 sutesso é deôndc pelos restrições tnçios

0 sucesso é ddimdc por restrições

• 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. tonCnfciKCeSjcesx

concorrentes e dor Os KPls sõo derivodos do srstomo de

KPIs uncomerte onentodcs o volor FIGURA 25-1

Alguns novos desenvolvimentos.

medKõo de da o^egoá)

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

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 dc 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 dificil, 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.; BEI.ACK, C Managing complex projects. Hoboken, NJ: Wiley and I1L co-publishers, 2010,

Capítulo 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 satisfazer 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 de 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, e 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. Em 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. A 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.

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.

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

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. 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.

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, II. 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 fronteira 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. Agora, 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. • Fcaturitis: 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 cliente 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

6

Para informações adicionais, consulte: KERZNER, H. Project health

checks.

Disponível

em:

. Copyright© 2010 pelo International Institutefor 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

Audtoria

Exames de Saúde

Foco

No presente

No futuro

Intenção

Concordância

Eficácia da execução e

entregas

Timing

Itens o serem buscados

Geidnente agendado e

Gerdmente nõo agendado e

pouco frequente

sob demando

Melwes práticas

ProMemas escondidos,

possrvehente destrutnos e pcssáeB ajras

Fntre.ntadcr

Gerdmente dguém interno

Consüta externo

Como a entevrsto e

Com lodo o time

Sessões individuais

Prazo

Curto prazo

Longo prazo

Profundidade do anáke

Sumário

Pensão forense

conduzido

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 é 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 dc 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 dificil 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

(cnjrejY.»

FIGURA 25-3

loi»»

(crçanace

Nepraa:

teemeo

btoacN

Fases do ciclo do vida da recuperaçã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 dificil 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.

■ i

!

(omperscott F«eé

i i J

i GnpecMtãs Difrtt

!

i

!

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

Ato

Sua

Grito Aáomto oo (kKrtobdbo

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 maus 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 difícil 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

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

Kn Termo que designa a transferência dc informações à distância sem a utilização de fios e cabos elétricos.

Herschel-Shosteck Consultor de Telecomunicações

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.

2

PATF.RIK, 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, CE. Unterberg, 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 gfl/ewyque iria fazer a transmissão uplink™ 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™. 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 comunicação vio satélite.

três satélites geossíncronos e apenas alguns poucos ga­ teways poderiam 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.

f* 15 Em tradução livre,“tubo encurvado”.

Termo que designa a capacidade de um usuário de uma rede

107 Baixa órbita terrestre. Tradução para Low Earth Orbit (LEO). 4

Ver nota 3.

de telefonia em obter conectividade fora das áreas onde está

GERDING, Bruce. Personal Communications via Satellite: An

cadastrado por meio de uma outra rede, como visitante.

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 poderíam 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 Terra, os telefones poderíam 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 de segurança. Assim surgiu a ideia por trás de 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,

n. 6, p. 194,10 out. 1998. 7

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’Tí 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/ 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­

"

FLOWER, Joe. Iridium. Wired, n. 1.05, nov. 1993.

dos, equivalente à Anatel, no Brasil.

9

Ver nota 6, Bennahum, p. 136.

737

A ASCENSÀO, QUEDA E RESSURREIÇÃO DO IRIDIUM

26.4

0 SISTEMA IRIDIUM0

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, Allen & 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. A 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 dc desenvolvimento deveria levar anos e, no final, resultaria cm 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 dc capital, acesso ao mercado, espectro global, a mesma banda dc 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; ZERBIB, 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.

/X 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 daramente, 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­ vard Business Review, p. 11, fcv. 2003. Copyright © 2003 por

...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. 100-101, mar.-abr. 1985. Copyright

Harvard Business School Publishing Corporation. Todos os

1985 pelo Presidente e pelos Membros do Conselho Diretor da

direitos reservados.

Faculdade de Harvard. Todos os direitos reservados.

741

A ASCENSÀO, QUEDA E RESSURREIÇÃO DO IRIDIUM

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

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

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 $ 3.000 ou mais por um telefone via satélite, além de $ 3 a S 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 construi­ ríam 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, Nev*-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 * 19 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 S 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 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". ”

'•

1IARDY, Quentin. Motorola Is Plotting New Satellite Project -

1IARDY, Quentin. Iridium Pulls $300 Million Bond Offer;

M-Star Would Be Faster Than the Iridium System, Pitched to

Analysts Cite Concerns About Projects. Wall Street Journal,

Global Firms. Wall Street Journal, New York, p. B4,14 out. 1996.

New York, p. A5,22 set. 1995. Edição leste.

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 S 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 08 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 (IP0)

A Iridium estava queimando dinheiro a uma velocidade de $ 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 dc 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

11ARDY, Quentin Staiano Is Leaving Motorola to Lead Firm’s

Iridium Global Satellite Project. Hh// Street Journal, New York,

Ver nota 6, Bennahum, 1998.

p. B8, 10 dez. 1996. Edição leste.

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 mats 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 de 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. Uii// Street Journal, New York, p. Al, 18 agí». 1999. Edição leste.

Trechos do comunicado de imprensa da Iridium, em 1" de no­ vembro de 1998.

a

Trechos da conferência telefônica da Iridium, em 25 de 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 falha 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

Mn 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 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.21

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

Dato 31/03/1999 30/06/1999 30/09/1999

Receita Acumuloda em Espécie (SMihôes)

Receita Recebido Acumulado (SMihões)

Número de Assinantes do Telefone vio Satélite

Numecode 1

Assinantes do 1 * Sistema

ifl Éfl m ifl

*O total de ossi nontes 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. Grani, 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

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 solicitaçã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

SUROWIECK1PP, James. The Latest SateUite Startup Lifts Off.

Will It Too Explode? Fortune, p. 237-254,25 out. 1999. Relatório anual, de 1998, da Iridium World Communications Ud.

“

1IAWN, Carlecn. High Wireless Act. Forbes, p. 60-62, 14 jun. 1999.

748

Gerenciamento de Projetos

prorrogações era o fato de que a falência não era uma al­ ternativa viável. Os parceiros do capital eram proprietários de todas as estações terrestres, de toda a distribuição e de todas as licenças regulatórias. Se os bancos e os credores forçassem a Iridium à falência, eles poderíam acabar pro­ prietários de uma constelação de satélites que não poderia se comunicar com o solo ou com os gateways. Junho de 1999

A Iridium recebeu uma prorrogação adicional de 30 dias além da prorrogação de dois meses que já tinha rece­ bido. Ela recebeu o prazo até 30 de junho para fazer um pagamento de títulos de $ 90 milhões. /X Iridium come­ çou a despedir 15% dos seus 550 funcionários, incluindo dois altos executivos. As ações agora tinham afundado para $ 6 por quota e os títulos estavam sendo vendidos a 19 centavos de dólar.

Nós fizemos bem todas as coisas difíceis, como a construção da rede, e fizemos mal todas as coi­ sas acéfalas, no final.29 John Richardson, CEO da Iridium

O grande erro da Iridium foi um lançamen­ to prematuro de um produto que não estava pronto. As pessoas ficaram tão obcecadas com a grandiosidade técnica do projeto que deixaram passar armadilhas fatais de marketing... A estru­ tura internacional da Iridium, revelou-se quase impossível de gerenciamento: os 28 membros do conselho falavam várias línguas, transfor­ mando as reuniões em completas mini-conferências da ONU - com fones de ouvido e tra­ dução dos acontecimentos em cinco línguas.w

John Richardson, CEO da Iridium ...Nós somos um clássico estudo de caso de MBA sobre como não se introduzir um produ­ to. Primeiro, criamos um avanço tecnológico maravilhoso. Então, perguntamos como fazer dinheiro com isso.

John Richardson, CEO da Iridium A Iridium estava fazendo todo o possível para evitar a falência. Tempo era do que a Iridium precisava. Alguns

”

Ver nota 28.

“

CAULEY, Leslie. Losses in Space - Iridium s Downfall: The Ma­ rketing Took a Back Seat to Science. Wall Street Journal. New York, p. Al, 18 age». 1999. Edição leste.

clientes industriais levariam de seis a nove meses para experimentar um novo produto, mas ficariam relutantes em se cadastrar se parecesse que a Iridium estaria fora do negócio em seis meses. Além disso, os concorrentes da Iridium foram baixando seus preços de forma significa­ tiva, aumentando ainda mais a pressão sobre a Iridium. Richardson, então, começou a oferecer reduções de pre­ ços de até 65% do preço original para alguns produtos e serviços da Iridium. Julho de 1999

Os bancos e os investidores concordaram em dar à Iridium ainda uma terceira prorrogação para 11 de agos­ to para cumprir os seus compromissos financeiros. Todos pareciam compreender que o esforço de reestruturação era muito mais amplo do que o inicialmente previsto. A Motorola, o maior investidor da Iridium e forne­ cedora geral, admitiu que o projeto poderia ter de ser en­ cerrado e liquidado, como parte do processo de falência, a menos que um acordo de reestruturação pudesse ser alcançado. A Motorola também afirmou que, se a falência ocorresse, continuaria a manter a rede de satélites, mas apenas por um período designado de tempo. A Iridium havia solicitado ao seu consórcio de in­ vestidores e fornecedores para levantarem mais dinhei­ ro. Mas, para muitos membros do consórcio, parecia que estariam jogando o dinheiro bom em cima do dinheiro ruim. Vários parceiros deixaram claro que simplesmen­ te sairiam da Iridium, em vez de fornecer financiamento adicional. Isso poderia ter um efeito de longo alcance no serviço em algumas localidades. Portanto, todos os par­ ceiros tinham de estar envolvidos na reestruturação. Os analistas de Wall Street esperavam que a Iridium pudesse restituir o pagamento em dinheiro de sua dívida ao longo de vários anos ou oferecer aos detentores de debêntures uma posição no capital da Iridium. Era altamente impro­ vável que os satélites da Iridium que orbitam a Terra fos­ sem leiloados no tribunal de falências. Agosto de 1999

Em 12 de agosto, a Iridium solicitou proteção con­ tra falência. Isso foi como ter “um punhal preso em seu coração” para uma empresa que, alguns anos antes, havia previsto o equilíbrio financeiro logo no primeiro ano de operações. Esse foi um dos 20 maiores pedidos de falên­ cia até o momento. As ações, que haviam sido negocia­ das a menos de S 3 por quota, foram suspensas da NAS­ DAQ em 13 de agosto de 1999. As chamadas telefônicas da Iridium haviam sido reduzidas para cerca de S 1,40 a S 3 por minuto e os celulares foram reduzidos para $ 1.500 por unidade.

749

A ASCENSÀO, QUEDA E RESSURREIÇÃO DO IRIDIUM

Havia pouca esperança para o Iridium. Tanto o pla­ no de negócios quanto o plano técnico eram falhos. O plano de negócios para a Iridium parecia que tinha saí­ do do filme Field of Dreams™2, em que um agricultor de milho de Iowa foi obrigado a construir um campo de bei­ sebol no meio de uma plantação de milho. Uma voz mis­ teriosa em sua cabeça dizia: “Construa e eles virão.” No filme» ele construiu» e eles vieram. Enquanto isso virou um bom enredo para um filme de Hollywood, tornou-se um horrível plano de negócios. Se você construir o Iridium, as pessoas podem vir. Mas o que é mais provável é que, se você construir algo mais barato, as pessoas irão para este primeiro. Herschel-Shosleck, Consultor de Telecom u nicações, 1992 O plano técnico foi criado para desenvolver o Santo Graal das telecomunicações. Infelizmen­ te, depois de gastar bilhões, a necessidade pela tecnologia mudou ao long») do tempo. Os en­ genheiros que projetaram o sistema, muitos dos quais haviam trabalhado anteriormente em pro­ jetos militares, não tinham uma compreensão da palavra “acessibilidade” e da necessidade de co­ mercializar um sistema para mais do que apenas um cliente, ou seja, o Departamento de Defesa. Os sistemas de satélites estão sempre muito atrás da curva de tecnologia. O Iridium esta­ va perdendo completamente a capacidade de acompanhar a era da internet.'1

Bruce Egan, membro sênior do Instituto da Universidade de Columbia para Teleinformação Setembro de 1999

leo Mondale renunciou ao cargo de chief financial officer da Iridium. Os analistas acreditavam que a renúncia de Mondale era resultado de que uma reestruturação bem- sucedida não seria mais possível. Segundo um analista,“Se eles (Iridium) estivessem perto (de um plano de reestrutu­ ração), não estariam trazendo toda uma nova equipe”. 26.20

A "GRIPE" DA IRIDIUM

A falência da Iridium estava tendo o efeito de uma gripe so­ bre todo o mercado. A ICO Global Communications, uma

das principais concorrentes da Iridium, também entrou com pedido de falência apenas duas semanas após a apre­ sentação da Iridium. A ICO não conseguiu levantar S 500 milhões que procurava a partir das ofertas públicas que já tinham sido prorrogadas duas vezes. Outro concorrente, a Globalstar Satellite Communications System, ainda estava financeiramente sólida. Anthony Navarro, chief operating officer da Globalstar declarou: “Eles (Iridium) definiram que as expectativas de todos eram altas demais".'2 26.21

À PROCURA DE UM CAVALEIRO BRANCO 13

A Iridium precisava desesperadamente de um licitante qualificado, que funcionaria como um cavaleiro branco. Cabia ao Tribunal Federal de Falências determinar se al­ guém era um licitante qualificado. Um licitante qualifica­ do era obrigado a apresentar um depósito reembolsável em dinheiro ou carta de crédito emitida por um banco respeitado que fosse igual ou maior a S 10 milhões ou 10% do valor do montante da oferta para assumir o con­ trole da Iridium. De acordo com a ação judicial de falência, a Iridium estava gerando receitas de S 1,5 milhões por mês. Em 9 de dezembro de 1999, a Motorola concordou com uma infusão de dinheiro de $ 20 milhões para a iridium. /\ empresa precisava desesperada men te de um cavaleiro branco rapidamente ou poderia ficar sem dinheiro em 15 de fevereiro de 2000. Com um custo operacional men­ sal de $ 10 milhões, e um assombroso custo de $ 300 mi­ lhões a cada poucos anos para a reposição de satélites, era questionável se alguém poderia fazer um negócio bem-sucedido a partir dos ativos da Iridium, em virtude da especificidade dos ativos.

O empresário de telefonia celular, Craig McCaw, pla­ nejava uma infusão de dinheiro em curto prazo, enquan­ to considerava um investimento muito maior para res­ gatar a Iridium. Ele também estava liderando um grupo de investidores que prometia S 1,2 bilhão para resgatar o sistema de satélites da ICO, que solicitou a proteção con­ tra falência pouco depois da solicitação da Iridium?’ Vários cavaleiros supostamente brancos apareceram, mas o grupo de Craig McCaw foi considerado o único candidato confiável. Embora o plano de reestruturação

“

IIARDY, Quentin. Surviving Iridium. Forbes, p. 216-217,6 set.

1999. Nn’ Da expressão em ingles, “White Knight", que designa uma Cor­

poração, empresa privada ou pessoa que pretende ajudar uma outra empresa.

Ml2 A versão brasileira do filme tem como titulo “Campo dos Sonhos". 31

M

Craig McCaw Plans Cash Infusion to Support Cash-Hungry

PATERIK, Stephanie. Iridium Alive and Well. The Arizona Re­

Iridium. Uii// Street Journal, New York, p. 1,7 fev. 2000. Edição

public, p. 1)5,27 abril 2005.

leste.

750

Gerenciamento de Projetos

proposto de McCaw não tivesse sido totalmente divulga­ do, era esperado que o envolvimento da Motorola fosse o de uma parte interessada em minoria. Além disso, sob um plano de reestruturação, a Motorola iria reduzir o seu pagamento mensal para a operação e manutenção do sis­ tema Iridium de S 45 milhões para S 8,8 milhões.51 26.22 A DEFINIÇÃO DO FRACASSO (OUTUBRO DE 1999)

A rede Iridium era uma maravilha da engenharia. A ati­ tude da Motorola de nunca desistir realizou milagres téc­ nicos e superou problemas técnicos do nível da NASA. A Iridium superou questões políticas globais, regulamenta­ ções internacionais caóticas e uma série de outras ques­ tões geopolíticas em sete continentes. O sistema Iridium era, de fato, o que Galvin, da Motorola, chamava de a oi­ tava maravilha do mundo.

Mas será que a falência indicava um fracasso para a Motorola? Absolutamente não! A Motorola coletou $ 3,65 bilhões em contratos para a Iridium. Considerando $ 750 milhões em lucro desses contratos, o prejuízo lí­ quido da Motorola com o Iridium era de cerca de S 1,25 bilhão. Assim, a Motorola gastou $ 1,25 bilhão em um projeto que teria custado a ela talvez até S 5 bilhões de seu próprio bolso, se pretendesse desenvolver a tecnolo­ gia por ela mesma. O Iridium proporcionou à Motorola mais de 1.000 patentes na construção de sistemas de co­ municação via satélite. O Iridium permitiu à Motorola acumular uma posição de liderança na indústria global por satélite. A Motorola também era cadastrada como fornece­ dora principal para construir os 288 satélites “Internet in the Sky”N 1“ chamado de Projeto Teledesic. Apoiadores do Projeto Teledesic, que tinha um preço de $ 15 bilhões para a transmissão de dados, vídeo e voz, incluíam a Boeing, o chairman da Microsoft Bill Gates e o magnata da telefonia celular Craig McCaw. O Iridium havia melhorado a repu­ tação da Motorola para as décadas seguintes. A Motorola afirmou que nào tinha a intenção de for­ necer financiamento adicional para a doente Iridium, a menos que, é claro, outros membros do consórcio tam­ bém o fizessem. Vários membros do consórcio afirmaram que nào forneceríam qualquer investimento adicional e que estavam considerando a possibilidade de encerrar o seu envolvimento na Iridium.'5** **

Iridium Set to Get $75 Million from Investors Led by McCaw. Wall Street Journal. New York, p. 1,10 fev. 2000. Edição do leste.

Em Março de 2000, McCaw retirou sua oferta para socorrer a Iridium, mesmo com um grande desconto, afirmando que, em vez disso, seus esforços seriam gas­ tos na recuperação do sistema de satélites da OIC. Isso, efetivamente, assinava a sentença de morte da Iridium. Uma das razões para a relutância de McCaw em resgatar a Iridium pode ter sido o descontentamento de alguns dos investidores que teriam sido completamente deixados de fora, como parte do esforço de reestruturação, perdendo talvez todo seu investimento. 26.23 0 PLANO DE EXORBITACÃO DE SATÉLITES

Com a retirada do financiamento de McCaw, a Iridium no­ tificou o Tribunal de Falências dos Estados Unidos de que nào tinha sido capaz de atrair um comprador qualificado dentro do prazo atribuído pelo Tribunal. A Iridium encer­ raria seu serviço comercial após as 23h59 de 17 de março de 2000, e iniciaria o processo de liquidação de seus ativos.

Imediatamente após o anúncio da Iridium, a Moto­ rola emitiu o seguinte comunicado à imprensa:’*

A Motorola manterá o sistema de satélites Iri­ dium por um período limitado de tempo, enquanto o plano de exorbitaçào está sendo finalizado. Durante esse período, também con­ tinuaremos a trabalhar com os assinantes em locais remotos para obter comunicação alter­ nativa. No entanto, a continuação dos servi­ ços limitados Iridium durante esse tempo vai depender de as empresas de gateway, que são empresas que operam em separado, permane­ cerem abertas.

A fim de apoiar os clientes que adquiriram o serviço Iridium diretamente da Motorola, fo­ ram estabelecidos pela empresa os Call Centers de Suporte ao Cliente e um web site que está dis­ ponível 24 horas por dia, sete dias por semana. Uma lista de serviços alternativos de comuni­ cações via satélite está incluída na informação aos clientes. O plano de exorbitaçào provavelmente levaria dois anos para ser concluído a um custo de $50 a $ 70 milhões. Isso incluiría todos os 66 satélites e os outros 22 em ór­ bita que servem como reposição ou falhas desativadas. /X Iridium, mais provavelmente, exorbitaria quatro satélites por meio de disparos em seus propulsores para soltá-los na atmosfera, onde eles queimariam.

Em português, “Internet no Céu”.

55

T11URM, Scott Motorola Inc., McCaw Shift Iridium Tactics. Wall Street Journal New York, p. 1, 18 fev. 2000. Edição do leste.

Comunicado da Motorola à imprensa, ago. de 1999.

751

A ASCENSÀO, QUEDA E RESSURREIÇÃO DO IRIDIUM

26.24 A IRIDIUM É RESGATADA POR $ 25 MILHÕES

Em Novembro de 2000, um grupo de investidores lidera­ do por um executivo da companhia ganhou aprovação do Tribunal de Falências para formara Iridium Satellite Cor­ poration e adquirir os ativos restantes da falida Iridium Corporation. A compra foi uma liquidação no preço de $ 25 milhões, o que foi menos do que um centavo de dó­ lar. Como parte da venda proposta, a Motorola iria passar a responsabilidade de funcionamento do sistema para a Boeing. Embora a Motorola mantivesse uma participação de 2% no novo sistema, não teria mais obrigações para operar, manter ou desativar a constelação. Quase imediatamente após o anúncio, a Iridium Sa­ tellite recebeu um contrato de $ 72 milhões a partir da Agência de Sistemas de Informação de Defesa, que faz parte do Departamento de Defesa (DoD).

A Iridium não só contribuirá para aumentar a nossa capacidade existente, ela fornecerá uma alternativa comercial aos nossos sistemas pura­ mente militares. Isso pode permitir o real uso duplo civil/militar, manter-nos mais perto da vanguarda em termos de tecnologia e oferecer uma alternativa real para o futuro. ”

Dave Oliver, Diretor Vice-Subsecretário de Defesa para Aquisição

e maiores custam a partir de S 699, ou você pode alugar um por cerca de S 75 por semana. O serviço custa de S 1 a $ 1,60 por minuto.3’ 26.25

EPÍLOGO

6 de fevereiro de 2006, a Iridium Satellites declarou que 2005 foi o melhor ano de todos. A empresa teve 142.000 assinantes, o que foi um aumento de 24% desde 2004, e a receita de 2005 foi 55% maior que em 2004. Segundo Carmen Lloyd, CEO da Iridium, “A Iridium está sobre um alicerce financeiro excepcionalmente forte com um modelo de negócios que é o autofinanciamento.”40 Para o ano que terminou em 2006, a Iridium teve $ 212 mi­ lhões em vendas e S 54 milhões em lucro. A empresa teve 180.000 assinantes e uma taxa de crescimento prevista de 14 a 20% por ano. A Iridium mudou seu modelo de negó­ cios, focando em vendas e marketing em primeiro lugar e publicidade exagerada em segundo. Isso lhe permitiu chegar a novos dientes e novos mercados.41 26.26

PROCESSOS DE ACIONISTAS

O benefício para a Motorola, potencialmente, à custa da Iridium e de seus investidores, não passou despercebido. Pelo menos 20 grupos de investidores entraram com uma ação contra a Motorola e a Iridium, citando: • A Motorola explorou a Iridium e usou dinheiro dos sócios para financiar a sua própria incursão em tecnologia de comunicação via satélite. • Ao usar o Iridium, a Motorola assegurou que sua reputação não seria prejudicada se o projeto fracassasse. • A maior parte do dinheiro arrecadado por meio dos IPOs foram para a Motorola para a concepção da maioria dos equipamentos e software dos saté­ lites e estações terrestres. • A Iridium utilizou os proventos de seus $ 1,45 bi­ lhão em titulos.com taxas de juros de 10,875 a 14%, principalmente para pagar à Motorola por satélites. • Os réus falsamente relataram o número possível de assinantes e os valores das receitas. • Os réus não revelaram a gravidade das questões técnicas. • Os réus não divulgaram os atrasos nas entregas de aparelhos.

A Iridium havia sido resgatada da beira da extinção. Como parte do acordo, a recém-formada empresa ad­ quiriu todos os ativos da Iridium inicial e de suas filiais. Isso incluiu a constelação de satélites, a rede terrestre, os imóveis da Iridium e a propriedade intelectual desenvol­ vida originalmente pela Iridium. Por causa da estrutura de custos significativamente reduzida da nova empresa, ela foi capaz de desenvolver um modelo de negócio viável baseado em um mercado-alvo para os produtos e serviços da Iridium. “Todo mundo pensa que os satélites Iridium ca­ íram e queimaram, mas tudo ainda está lá em cima.”’*

Weldon Knape, World Communication Center (WCC), Chief Executive Officer, 27 de abril de 2005

Um novo telefone Iridium custa SI.495 e é do ta­ manho de um telefone fixo sem fio. Modelos mais velhos v

w

DoD Awards $72 Million to Revamp Iridium. Satellite Today,

**

Ver nota 38.

“

Comunicado da Iridium à imprensa em 6 de fevereiro de 2006.

41

Adaptado de: JANA, Reena. Companies Known for Inventive

fotomac, v. 3, n. 227, p. 1,7 dcz. 2000.

Tech Were Dubbed the Next Big Thing and Then Disappeared.

PATER1K, Stephanie. Iridium Alive and Well. The Arizona Re­

Now They’re Back and Growing. Business ivirdc, 10 abr. 2007.

public, 27 abr. 2005.

Innovation.

752

Gerenciamento de Projetos

• Os réus violaram os convênios existentes entre eles próprios e os seus credores. • Os réus atrasaram a divulgação de informações, forneceram informações enganosas e inflacionaram artificialmente o preço das ações da Iridium. • Os réus aproveitaram os preços artificialmente inflacionados para vender quantias significativas das suas próprias ações por milhões de dólares em lu­ cro pessoal. 26.27 A DECISÃO DO TRIBUNAL DE FALÊNCIAS

F.m 4 de setembro de 2007, após quase dez meses, o Tri­ bunal de Falências de Manhattan decidiu em favor da Motorola e irritou os credores arruinados que tinham esperança de conseguir um julgamento de $ 3,7 bilhões contra a Motorola. O juiz considerou que, embora os mercados de capitais estivessem “terrivelmente errados” sobre as esperanças da Iridium para lucros enormes, a Iri­ dium estava “solvente”, durante o período crítico, quando levantou com sucesso impressionante os montantes em dívida e capital próprio nos mercados de capitais.

O tribunal disse que, apesar de especialistas financei­ ros saberem agora que a Iridium era um caso perdido e de fluxo de caixa sem retorno, de projeto de tecnologia falho, e de um modelo de negócio condenado, a Iridium esta­ va solvente no período crítico de angariação de fundos. Mesmo quando as notícias ruins começaram a aparecer, os investidores e underwriters da Iridium ainda acredita­ vam que ela tinha o potencial para se tornar uma empresa viável. No dia seguinte à decisão do Tribuna), os jornais re­ lataram que a Iridium LLC, agora de controle privado, se preparava para levantar cerca de S 500 milhões em uma oferta privada de capitais a ser seguida por um IPO no ano seguinte ou no posterior. 26.28 AUTÓPSIA'

Houve várias razões para o colapso da Iridium: A construção e implementação da telefonia celular

reduziu drasticamente a necessidade do mercado-alvo pelo serviço Iridium

A Iridium sabia que seus telefones seriam muito grandes e caros demais para competir com o serviço ce­ lular, obrigando a empresa a atuar em áreas em que a te­ lefonia celular não estava disponível. Com essa restrição

FINKELSTEIN, Sydney; SANFORD, Shade II. Learning from Corporate Mistakes: The Rise and Fall of Iridium. Organizatio­ nal Dynamics, v. 29, n. 2, p. 138-148, 2000. © 2000 por Elsevier

Sciences, Inc. Reproduzido com permissão.

em mente, a Iridium procurou um mercado-alvo, concentrando-se em executivos de negócios internacionais que viajavam com frequência para áreas remotas onde o serviço de telefonia celular não estava disponível. Embora esse plano antecedesse a ascensão do mercado de telefo­ nes celulares, a Iridium permaneceu centrada no grupo viajante de negócios durante o lançamento de seu serviço. Ainda em 1998, o CEO Staiano previu que o Iridium teria 500.000 assinantes no final de 1999. Um dos principais problemas com a oferta da Iri­ dium era que a telefonia celular terrestre havia se pro­ pagado mais rápido do que a empresa esperava inicial­ mente. No final, a telefonia celular estava disponível. Em virtude da tecnologia elaborada da Iridium, o período do conceito ao desenvolvimento foi de 11 anos - durante esse período, as redes celulares se espalharam para cobrir a esmagadora maioria da Europa e até mesmo migraram para países em desenvolvimento, como China e Brasil. Em suma, o plano de marketing da Iridium mirava um segmento - o de viajantes de negócios - cujas necessida­ des estavam cada vez mais sendo atendidas pelos telefo­ nes celulares que ofereciam um valor significativamente melhor do que o Iridium. A aceitação reprimida das limitações tecnológicas

e de design do Indium

Como a tecnologia Iridium dependia da linha de visada entre a antena do telefone e o satélite em órbita, os assinantes não conseguiam utilizar o telefone dentro de carros em movimento, dentro de prédios e em mui­ tas áreas urbanas. Ademais, mesmo em campos abertos os usuários tinham de alinhar o telefone perfeitamente a fim de obter uma boa conexão. Como um consultor sê­ nior de mercado nos disse em uma entrevista, “você nào pode esperar que um executivo em viagem de negócios a Bangkok deixe um prédio, caminhe em uma esquina e sa­ que um telefone de $ 3000”. Além disso, faltava ao Iridium capacidade de dados adequada, um recurso cada vez mais importante para usuários de negócios. Para piorar as coi­ sas havia os incômodos, como o fato de que a recarga da bateria em áreas remotas demandava acessórios especiais movidos a energia solar. Essas limitações tornavam o te­ lefone difícil de vender para o mercado-alvo da Iridium, o de executivos de negócios de alto nível que viajavam com frequência. O design do telefone Iridium também dificultava a aceitação. Em novembro de 1997, John Windolph, dire­ tor de comunicações de marketing da Iridium, descreveu o aparelho da seguinte maneira: “É enorme! Vai assustar as pessoas. Se tivéssemos uma campanha que mostrasse o nosso produto, nós perderiamos”. No entanto, um ano depois a Iridium continuou basicamente com o mesmo

753

A ASCENSÀO, QUEDA E RESSURREIÇÃO DO IRIDIUM

produto. O aparelho, embora menor do que da concor­ rente Planet I, da Comsat, ainda era, literalmente, do ta­ manho de um tijolo.

Como o Wall Street Journal relatou, “com menos de seis meses antes do lançamento do serviço, o tempo tornou-se crítico... A maioria dos sócios não revelava que estava atrasada no cronograma.”

A execução operacional ruim atingiu a Iridium

Problemas de fabricação também fizeram com que o lançamento da Iridium tropeçasse portão afora. A ad­ ministração lançou o serviço antes que quantidades su­ ficientes de telefones estivessem disponíveis de um dos seus dois principais fornecedores, a Kyocera, que estava enfrentando problemas de software, no momento. Iro­ nicamente, esse gargalo de produção significava que a Iridium não poderia obter telefones até mesmo para al­ guns assinantes que realmente quisessem um. A decisão de lançar o serviço em novembro de 1998, apesar dos problemas de fabricação, foi tomada pelo CEO Staiano, embora não sem oposição. Conforme um relatório situ­ ava, “[John Richardson| alegou vociferar nas reuniões do conselho, argumentando contra o lançamento de novembro. Nem o serviço, nem os prestadores de servi­ ços, estavam prontos. As dificuldades de abastecimento significavam que havia poucos telefones disponíveis no mercado”. Os sócios da Iridium não forneciam apoio adequado

26.29 0 IMPACTO FINANCEIRO DA FALÊNCIA

À época da falência, os investimentos de capitais da Iri­ dium totalizaram aproximadamente $ 2 bilhões. A maio­ ria dos analistas, porém, considerava que aos ações não valiam a pena. O IPO foi realizado a $ 20 por quota em junho de 1997, atingiu a maior alta de todos os tempos a S 72,19 em maio de 1998, e caiu para $ 3,06 por quota no momento que a Iridium declarou falência, em agosto 1999. Além disso, a bolsa de valores NASDAQ reagiu à notícia de falência travando imediatamente a negociação das ações e removeu de fato a Iridium em novembro de 1999. Os sócios da Iridium - que também haviam feito investimentos por meio da construção de estações ter­ restres, reunião de equipes de gerenciamento e comer­ cialização dos serviços da Iridium - ficaram com pouco a acrescentar ao seu patrimônio. Depois que a Iridium declarou falência, seus $ 1,5 bilhões em títulos foram ne­ gociados por cerca de 15 centavos de dólar conforme a empresa entrou em negociações de reestruturação com seus credores.

de vendas e marketing

Embora a Motorola, a princípio, tivesse dificuldades para atrair investidores para a Iridium, em 1994, a Iri­ dium LLC tinha sociedade com 18 empresas, incluindo a Sprint, a Raytheon, a Lockheed Martin e uma variedade de empresas da China, do Oriente Médio, da África, da índia e da Rússia. Em troca de investimentos de $ 3,7 bi­ lhões, os sócios receberam uma participação e assentos no conselho de administração da Iridium LLC. Em 1998, 27 dos 28 diretores eram ou empregados, ou designados diretamente pelos sócios da Iridium. Os sócios da Iridium finalmente controlariam a co­ mercialização, os preços e a distribuição, quando o ser­ viço entrasse em linha. As receitas da Iridium vinham de preços por atacado para o seu serviço de telefone. Infe­ lizmente para a Iridium, seus sócios, principalmente os sócios fora dos Estados Unidos, demoraram a definir as equipes de comercialização e os canais de distribuição. “Os gateways eram muitas vezes grandes empresas de telecomunicações”, disse Stephane Chard, analista-chefe da Euroconsult, uma empresa de pesquisas, com sede em Paris. “Para eles, o Iridium era uma coisa pequena.” Tão minúscula, de fato, que os sócios da Iridium falharam em criar equipes de vendas, planos de marketing ou definir outros canais de distribuição para seus próprios países.

26.30 0 QUE REALMENTE DEU ERRADO?

A Iridium ficará na história como um dos fracassos de negócios mais importantes dos anos 1990. Que a sua tec­ nologia era incrivelmente elegante e inovadora, isso está fora de questão. De fato, a Motorola e os líderes da Iri­ dium mostraram grande visão para orientar o desenvol­ vimento e o lançamento de uma constelação de satélites incrivelmente complexa. Igualmente surpreendente, no entanto, foi a maneira como esses mesmos líderes leva­ ram a Iridium à falência por apoiarem um plano de ne­ gócio insustentável.

Ao longo dos últimos anos, tem havido talvez mi­ lhares de artigos escritos sobre o fracasso da Iridium em atrair clientes e sobre a sua consequente falência. A experiência convencional afirma com frequência que a Iridium foi simplesmente pega de surpresa pela propaga­ ção da telefonia celular terrestre. Ao concentrar-se quase que estritamente no que aconteceu, essa análise fornece pouco sobre a forma de aprendizado valioso. Uma ques­ tão mais interessante é sobre o porquê de o fracasso do Iridium ter acontecido - ou seja, saber por que a empresa continuou a avançar com um plano de negócio cada vez mais imperfeito.

754 Três Forças Combinadas para Criar o Fracasso do Iridium

Três forças se uniram para criar o fracasso do negócio Iridium. Primeiro, um “comprometimento crescente"^115, particularmente entre os executivos da Motorola que le­ varam o projeto adiante, apesar dos problemas conheci­ dos e potencialmente fatais de tecnologia e mercado. Em segundo lugar, por razões pessoais e profissionais, o CEO da Iridium não estava disposto a estancar o prejuízo e abandonar o projeto. E, em terceiro lugar, o conselho da Iridium foi estruturado de uma forma que o impediu de exercer seu papel de governança corporativa.

Problema 1: O comprometimento crescente Durante os 11 anos que se passaram entre o concei­ to inicial do Iridium até o seu desenvolvimento real, seu plano de negócio erodiu. Primeiro, o desenvolvimento e implementação gradual da telefonia celular encolheram dramaticamente o mercado-alvo da Iridium - executivos internacionais que viajavam regularmente para áreas não cobertas pela telefonia celular terrestre. Em segundo lu­ gar, ficou evidente ao longo do tempo que os telefones da Iridium teriam problemas significativos de design, problemas operacionais e de custos que limitariam ainda mais a sua utilização. A decisão da Motorola de continuar com o Iridium, apesar de um plano de negócio profundamente falho é um exemplo clássico das armadilhas do “comprome­ timento em escalada”. A teoria por trás do comprome­ timento em escalada é baseada em parte na “falácia dos custos irrecuperáveis”*116 - a tomada de decisões com base no tamanho dos investimentos anteriores e não no tamanho do retorno esperado. As pessoas tendem a au­ mentar seu comprometimento com um projeto quando (a) acreditam que os ganhos futuros estão disponíveis, (b) acreditam que podem reverter um projeto, (c) estão publicamente comprometidas e identificadas com o pro­ jeto e (d) podem recuperar uma grande parte do seu in­ vestimento se o projeto falhar. WTn Em tradução da expressão Escalating Commitment. A expressão foi mencionada pela primeira vvz em um estudo de Barry M.

Gerenciamento de Projetos

O envolvimento da Motorola no projeto Iridium reu­ niu todas as quatro condições. Apesar de problemas conhe­ cidos, altos executivos mantiveram a fé cega no Iridium. Dizer que a alta administração da Iridium não estava cien­ te dos problemas potenciais do Iridium seria totalmente impreciso. Na verdade, o prospecto da Iridium, escrito em 1998, listava 25 páginas cheias de riscos, incluindo:

• Uma estrutura de capital altamente alavancada • Limitações de design - incluindo o tamanho do telefone • Limitações de serviço - incluindo a degradação se­ vera em automóveis, edifícios e áreas • /Mto preço do aparelho e dos serviços • A construção e implementação das redes celulares • Falta de controle sobre os esforços de comerciali­ zação dos sócios

Durante o longo período do conceito ao desenvolvi­ mento do Iridium, há pouca evidência para sugerir que a Motorola ou a Iridium fizeram quaisquer progressos significativos no tratamento de quaisquer desses riscos. Ainda mais, a Iridium foi em frente, única e exclusiva­ mente concentrando-se na concepção e lançamento do satélite, enquanto desconsiderava os desafios em vendas e marketing dos telefones. A crença de que a tecnologia inovadora acabaria por atrair clientes, de fato, estava profúndamente enraizada na cultura da Motorola. De foto, a história da Motorola, está repleta de exem­ plos de inovações espetaculares que trouxeram o sucesso c notoriedade da empresa. Na década de 1930, Paul Gavin desenvolveu o primeiro rádio automotivo acessível. Na década de 1940, a Motorola subiu para a primazia quan­ do desenvolveu o primeiro rádio portátil bidirecional, que foi utilizado pelo Corpo de Sinaleiros do Exército dos Estados Unidos durante a Segunda Guerra Mundial. Na década de 1950, a Motorola fabricou os primeiros apare­ lhos de televisão portáteis. Em 1969, as primeiras palavras de Neil Armstrong da Lua foram enviadas por um trans­ ponder projetado e fabricado pela empresa. Na década de 1970 e 1980, a Motorola obteve sucesso por meio do desenvolvimento e fabricação de microprocessadores e de telefones celulares.

Staw, cm 1976, chamado “Knee deep in the big muddy: a study of escalating commitment to a chosen course of action”. O estudo

descrevr o fenônemo em que as pessoas justificam o aumento de

inwstimento em uma decisão.com base nos investimentos passa­

dos, apesar de novas evidências sugerirem que as decisões passa­ das estavam erradas. Maiores informações sobre o assunto: httpJ/

en.wikipcdia.org/wiki/Escalation_of_commitment (cm inglês).

Em tradução à expressão sunk costs fallacy. Maiores informações em http://en.wikipedia.org/wiki/Sunk_cost_fallacySLoss_avvrsion_

and_lhe_sunk_cost_fallacy (em inglês).

No momento em que desenvolveu o conceito Iridium, no início de 1990, a Motorola tinha passado por mais de 60 anos de sucesso em trazer, muitas vezes, novas tecno­ logias surpreendentes para os consumidores ao redor do mundo. Desse sucesso, no entanto, vieram uma certa arro­ gância e crença tendenciosa na própria tecnologia da em­ presa. Assim como a Motorola acreditava, em meados dos anos 1990, que os clientes de telefonia celular demorariam

755

A ASCENSÀO, QUEDA E RESSURREIÇÃO DO IRIDIUM

a mudar dos telefones analógicos da Motorola para os ce­ lulares digitais produzidos pela Ericsson e Nokia, a na sua fé no Iridium e sua tecnologia era inabalável.

Problema 2: A liderança de Staiano era uma faca de dois gumes O Dr. Edward Staiano tornou-se CEO da Iridium no final de 1996 - antes que a empresa tivesse lançado a maioria de seus satélites. Durante seu mandato anterior com a Motorola, Staiano tinha firmado uma reputação tão intimidadora quanto exigente - imponente tanto em estatura, 1,95 metro, quanto no temperamento. Staiano combinou seu estilo de liderança com uma antiga ética da Motorola que alegava que os líderes tinham a responsabi­ lidade de apoiar os seus projetos. Staiano também tinha incentivos financeiros significativos para empurrar o pro­ jeto adiante, em vez de reduzir as perdas e seguir em fren­ te. Em 1997 e 1998, ele recebeu 750.000 opções de ações da Iridium ao longo de um período de cinco anos. Na verdade, esse fato não escapou aos olhos de Staiano quan­ do ele assumiu a posição de CEO no final de 1996, decla­ rando: “Se eu puder transformar o sonho do Iridium em realidade, farei uma quantidade significativa de dinheiro”. Ironicamente, o estilo exigente de liderança, o com­ prometimento com o projeto em mãos e os incentivos fi­ nanceiros que tornaram Ed Staiano um líder tão atraente para uma empresa startup como a Iridium acabou por ser uma faca de dois gumes. Na verdade, essas mesmas características também o tornaram relutante a abandonar um projeto com um plano de negócio fracassado e uma tecnologia obsoleta.

26.31

LIÇÕES APRENDIDAS

Os Executivos Deveríam Avaliar Projetos

como o Iridium com Opções Reais

Projetos com longos períodos do conceito ao desen­ volvimento para os tempos de desenvolvimento colocam problemas únicos para os executivos. Esses projetos podem parecer bons investimentos durante o desenvolvimento do conceito inicial; mas, no momento em que o produto ou serviço entra em linha, tanto o cenário competitivo quanto a capacidade da companhia em fornecer o serviço ou pro­ duto, muitas vezes muda de forma significativa.

Para lidar com longos períodos do conceito ao de­ senvolvimento, os executivos devem avaliar esses projetos com opções reais. Um modelo simples seria um projeto de dois estágios. O primeiro estágio é de natureza estraté­ gica e proporciona a oportunidade para um investimento adicional e um maior retorno no segundo estágio. Quan­ do o estágio inicial estiver concluído, no entanto, a em­ presa deverá reavaliar o esperado retorno sobre os inves­ timentos futuros com base em uma melhor compreensão do produto/serviço e do cenário competitivo.

O Iridium é um exemplo clássico de um projeto que teria se beneficiado com esse tipo de análise. O projeto Iridium em si, essencialmente, consistia de dois estágios. Durante o estágio um (1987-1996), a Motorola desenvol­ veu a tecnologia por trás do Iridium. Durante a fase dois (1996-1999), a Motorola construiu e lançou os satélites - e a maioria dos custos da Iridium ocorreu durante essa parte do projeto. 0 Investimento em P&D para o Iridium foi Adequado 0 Investimento Subsequente, Não

Problema 3: O conselho de administração da Iridium nõo forneceu a governança corporativa adequada Em 1997, o conselho de administração da Iridium tinha 28 diretores - 27 dos quais eram ou funcionários da Iridium ou diretores designados pelos sócios da Iridium. A composição, para não mencionar o tamanho, do con­ selho da Iridium criou dois grandes problemas. Primeiro, o conselho não tinha a visão dos diretores de fora que po­ deríam ter fornecido uma diversidade de conhecimentos e pontos de vista objetivos. Segundo, o fato de a maioria do conselho ser composta por membros nomeados pe­ los sócios dificultou para a Iridium exercer pressão sobre seus sócios em momentos essenciais — como quando vá­ rios sócios foram lentos em estabelecer a infraestrutura necessária de marketing e vendas antes do lançamento do serviço. No final, o conselho da iridium falhou em prover a supervisão corporativa adequada e limitou a capacidade da Iridium de trabalhar com seus sócios de forma eficaz.

Olhando para trás, seria injusto afirmar que a decisão ini­ cial de investir em P & D para o Iridium foi um erro. Na década de 1980, a Iridium parecia ter um bom plano de negócio. As viagens entre os executivos de negócios esta­ vam aumentando e as redes terrestres dc telefonia celular não cobriam muitos dos destinos. Certamente não era in­ sensato prever uma grande procura por um telefone sem fio que não tivesse fronteiras. Por sua vez, o investimento em P&D era razoável, dado que proporcionava a opção de implantar (ou não implantar) o complexo sistema de satélites Iridium, nove anos depois.

Em 1996, entretanto, quando a Iridium teve de to­ mar a decisão de investir na construção e lançamento de satélites, muita coisa tinha mudado. Não apenas o crescimento das redes de telefonia celular havia erodido drasticamente o mercado-alvo da Iridium, como a própria tecnologia Iridium nunca foi capaz de superar problemas fundamentais de design, custos e problemas

756 operacionais. Simplificando, a Iridium não tinha um pla­ no de negócio viável. Munida desse conhecimento adi­ cional, uma avaliação razoável do projeto teria impedido novos investimentos. Os Executivos Devem Criar Avaliações do Valor

da Opção em Seus Planos de Negócio

A chave para usar a abordagem do valor da opção é incluí-la no plano de negócio. Particularmente, os execu­ tivos devem especificar, a priori, quando irão reavaliar o projeto e os seus méritos. Durante essa avaliação, a em­ presa deve avaliar objetivamente os dados de mercado atualizados e a sua própria capacidade de atender as de­ mandas modificadas dos clientes. O conselho de admi­ nistração desempenha um papel fundamental nesse pro­ cesso, fazendo com que a inércia nào conduza um projeto fracassado além de sua vida útil. Isso é particularmente importante quando os executivos da empresa têm razões auxiliares, tais como a preocupação com a reputação ou compensação pessoal para continuar, apesar de um plano de negócio falho. Os altos executivos foram publicamente compro­ metidos e identificados com o Iridium. Tão importante quanto o seu investimento financeiro no Iridium era o in­ vestimento psicológico da Motorola no projeto. O chair­ man da Motorola, Robert Galvin, e, mais tarde, seu filho Christopher Galvin, expressaram publicamente o apoio ao Iridium e olhavam para ele como um exemplo do poder tecnológico da Motorola. Na verdade, foi Robert Galvin, Chairman da Motorola na época, o primeiro a dar a apro­ vação à Bary Bertiger para ir em frente com o Iridium, depois que os superiores de Bertiger haviam rejeitado o projeto por ser demasiadamente caro. No final, ambos os Galvins apostaram boa parte da reputação da Motorola no sucesso do Iridium e o projeto proporcionou à Mo­ torola e ao restante dos seus sócios um grande prestígio. Os Custos de Projetos Muito Arriscados Podem Ser Reduzidos por Meio de Oportunidades de Contratação e Aprendizado

A Motorola obteve benefícios importantes de sua relação com a Iridium. Na verdade, a Motorola assinou S 6,6 bilhões em contratos para projetar, lançar e operar os 66 satélites da Iridium e fabricar uma parte de seus aparelhos. David Copperstein, da Forrester Research des­ creveu o negócio da Motorola com a Iridium como “uma forma muito astuta de criar uma situação sem perdas”. Outros analistas tinham menos cortesia: “Esse contrato |o acordo da Motorola de $ 50 milhões por mês, com a Iridium para prestar suporte operacional aos satélites) é

Gerenciamento de Projetos

absurdamente lucrativo para a Motorola” disse Armand Mussey, um analista de mercado que acompanhava o se­ tor para o Bank of America Securities, “a Iridium precisa cortar isso pela metade”. Esses contratos - embora lucrativos - também de­ ram à Motorola um incentivo para empurrar o Iridium adiante, independentemente do seu plano de negócio. Mesmo se o Iridium fracassasse, a Motorola ainda ge­ raria novas receitas significativas ao longo do caminho. Ao quantificar a importância dos contratos da Motorola com a Iridium, em maio 1999, VVojtek Uzdelewicz da SG Cowen estimou que a Motorola já houvesse recebido e arrecadado $ 750 milhões em lucros de suas relações com a empresa. Com base nesses lucros de compensação, ele colocou a exposição total da Motorola ao Iridium entre $ 1,0 e $ 1,15 bilhão - bem menos do que muitos obser­ vadores perceberam.

Além disso, a Iridium acabaria por expor a Motorola ao desenvolvimento da tecnologia de satélite e à proteção de patentes que veio com ela. Essa exposição veio num momento em que a Motorola estava interessada em en­ trar no setor de comunicações por satélite além do Iri­ dium, em projetos como o Teledesic, de Craig McCaw um projeto de $ 9 bilhões consistindo de uma complexa constelação de satélites LEO projetados para fornecer acesso global à Internet em alta velocidade. A Liderança Estratégica dos CEOs e dos Conselhos

de Administração Podem Construir, ou Destruir,

as Iniciativas Estratégicas

Em uma época em que a remuneração dos executi­ vos é dominada pelas opções de ações, a história da Iri­ dium deve dar uma pausa àqueles que veem apenas os benefícios de pagamentos baseados em opções. Os incen­ tivos financeiros são extremamente poderosos e as com­ panhias que dependem deles para a motivação devem ser particularmente cuidadosas para considerar as consequ­ ências intencionais e não intencionais. Será que o CEO Staiano teria sido mais atento aos vários sinais de alerta na Iridium se as opções de ações não tivessem um papel tão grande em seu pacote de remuneração? A forte ênfase nas opções deram a Staiano um incentivo para persistir com a estratégia da Iridium, era a única oportunidade que ele tinha de fazer as opções valerem. As lições do conselho de administração da Iridium são simplesmente gritantes. Certamente, poucos conse­ lhos podem funcionar com 28 membros, a maioria repre­ sentando diferentes circunscrições que certamente man­ tinham objetivos diferentes. Todos, exceto um membro do conselho, sendo membros do consórcio Iridium, dão

757

A ASCENSÀO, QUEDA E RESSURREIÇÃO DO IRIDIUM

uma ideia do volume de atenção do conselho no cum­ primento de suas funções de supervisão. Na verdade, esse tipo de conselho, constituído fundamentalmente por re­ presentantes dos investidores, está se tornando mais co­ mum em empresas startups de alta tecnologia. Empresas como a General Magic, a Excite At Home e Net2Phone possuem vários investidores, normalmente representa­ dos no conselho e que nem sempre concordam com a direção estratégica. Na verdade, o desenvolvimento de um assistente digital pessoal da General Magic foi seve­ ramente prejudicado pela sua dependência de investido­ res como Apple, Sony, IBM e AT&T. Com a Iridium, a magnitude dos benefícios contratuais auxiliares da Mo­ torola derivados da Iridium pareciam mais extravagan­ tes dada a condição financeira da Iridium. Um conselho eficaz deve ser simultaneamente vigilante e apoiador, um grande feito para um conselho dominado pelos mem­ bros e com vários investidores. 26.32

CONCLUSÃO

O que é fascinante sobre o estudo de casos como o Iri­ dium é que o que aparentemente tolices incompreensí­ veis são realmente janelas para o mundo da tomada de decisões gerenciais, imperfeições e tudo o mais. Em exa­ mes aprofundados da estratégia em ação podemos desta­ car como esses processos, tais como o comprometimento crescente, são verdadeiros impulsionadores da ação ge­ rencial. Quando as organizações tropeçam, os observado­ res geralmente se perguntam por que a empresa, ou a alta administração, fez algo tão “estúpido”. Muito mais desa­ fiador é começar a análise, supondo que a administração é tanto competente quanto inteligente e, então, pergun­ tar, por que eles tropeçam. As respostas que se têm com essa abordagem tendem a ser, ao mesmo tempo, tanto mais interessantes quanto reveladoras. Os estudantes de estratégia e das organizações certamente podem se bene­ ficiar de tal análise investigativa. 26.33 EPÍLOGO (2011)

Quando a Iridium entrou em falência, era considerada uma obra-prima técnica, mas um fracasso empresarial. Embora muitas pessoas tenham desejado eliminar a Iri­ dium, a empresa está viva e indo razoavelmente bem. Atendendo a uma decisão judicial em 2007, a Iridium anunciou seus planos para os satélites de segunda geração chamados Iridium NEXT. Os lançamentos dos satélites Iri­ dium NEXT iriam começar em 2015 e ser concluídos em 2017. Os satélites originais que inicialmente esperava-se

ter uma expectativa de vida de cinco a sete anos após seu lançamento em 1997-1998, agora deverão estar plena­ mente operacionais até 2014-2020. A Iridium conseguiu receber novos contratos do go­ verno dos EUA e também atrair novos usuários. A em­ presa também criou um consórcio de investidores que fornecería apoio financeiro. Em 2 de junho de 2010, a Iri­ dium anunciou a adjudicação de um contrato de USS 2,9 bilhões com a Thales Alenia Space para a aquisição de sa­ télite. Ao mesmo tempo, um contrato de USS 492 milhões foi adjudicado à Space X para o lançamento desses satéli­ tes na Base da Eorça Aérea de Vandenberg, na Califórnia.

Em 2010, as ações da Iridium tiveram uma alta de USS 11,13 e uma baixa de USS 6,27. A capitalização de mercado foi de USS656 milhões e o lucro por ação foi de USS 0,09. Mas enquanto a Iridium estava mantendo seu crescimento, houveram novos riscos que devem ser considerados: • Existem muitos satélites no espaço e existe o risco de que um satélite Iridium colida com outro satéli­ te. (Um satélite da Iridium colidiu com um satélite russo). Alguns dizem que este é um risco definido e aceitável. • Há também o risco de nuvens de detritos em órbi­ ta atingirem os satélites Iridium. • Satélites sobressalentes adicionais podem ser ne­ cessários e, talvez, nem todo plano terá um sobressalente. Normalmente, o deslocamento de satéli­ tes pode levar até duas semanas e consumir uma grande quantidade de combustível, encurtando assim a expectativa de vida do satélite. • Os satélites Iridium originais eram fabricados em linha de montagem. Em seu pico durante 19971998, a Iridium produzia um satélite a cada 4,3 dias, enquanto o desenvolvimento de um único satélite era tipicamente de 21 dias. A Iridium tam­ bém foi capaz de manter os custos de construção em cerca de USS5 milhões por satélite. Este proces­ so teria que ser repetido novamente ou mesmo ser melhorado. • Algumas pessoas argumentam que a sobrevivência da Iridium é baseada no grande número de con­ tratos que recebe do governo dos EUA. Se o go­ verno reduzir seu suporte ou mesmo desistir da Iridium, os riscos financeiros podem aumentar significativamente. /X necessidade pela Iridium ainda existe.

APENDICE

SOLUÇÕES PARA O EXERCÍCIO DE CONFLITO EM GERENCIAMENTO DE PROJETOS

PARTE 1: ENFRENTAMENTO DO CONFLITO

Depois de ler as respostas que se seguem, registre a sua pontuação na linha 1 da tabela 5-8, p. 199. a. Embora muitos gerentes de projetos e gerentes

b.

c.

funcionais negociem por meio da “retribuição” de favores, esse costume não é altamente reco­ mendável. O gerente do departamento pode sentir algum grau de endividamento no início, mas certamente ficará na defensiva nos projetos posteriores em que você estiver envolvido e pode até ficar com a impressão de que essa será a única maneira com a qual ele poderá lidar com você no futuro. Se essa foi sua escolha, coloque um ponto na linha 1. Ameaças só podem conduzir ao desastre. Essa é uma maneira infalível de acabar com um possível bom acordo antes de de começar. Não atribua pontos se você seledonou essa como a sua solução. Se você não disser nada, então você aceita a plena prestação de contas e responsabilidade pelos atra­ sos no cronograma e aumento nos custos. Você nào fez nada para abrir as comunicações com

d.

e-

f-

o gerente de departamento. Isso poderia levar a conflitos adicionais em projetos futuros. Insira dois pontos na linha 1, se esta foi a sua escolha. Pedir à alta administração para intervir nesse momento só pode complicar a situação. Os exe­ cutivos preferem intervir apenas como último recurso. A alta administração provavelmente pe­ dirá para falar com o gerente do departamento primeiro. Atribua dois pontos na linha 1, se essa foi a sua escolha. Embora ele possa ficar na defensiva ao receber seu memorando, será difícil para ele evitar o seu pedido de ajuda. A questão, claro, é quando ele lhe dará essa ajuda. Atribua oito pontos na linha 1, se você fez essa escolha. A tentativa de forçar a sua solução sobre o geren­ te do departamento irá ameaçá-lo severamente e fornecer a base para conflitos adicionais. Bons gerentes de projetos irão sempre tentar prever as reações emocionais a quaisquer decisões que eles possam ser forçados a tomar. Para essa escolha, atribua dois pontos na linha 1 da planilha.

760

Gerenciamento de Projetos

Marcar uma reunião para um momento mais tarde dará a ambas as partes uma oportunidade para esfriar a cabeça e pensar mais a respeito. Ele provavelmente achará difícil recusar o seu pedi­ do de ajuda e será forçado a pensar sobre isso até a reunião. Atribua dez pontos para essa escolha. h. Uma discussão imediata tenderá a abrir comu­ nicações ou manter a comunicação aberta. Isso será vantajoso. No entanto, também pode ser uma desvantagem se as emoções estão aflorando e se não foi dado tempo suficiente para a seleção de alternativas. Atribua seis pontos na linha 1, se essa foi a sua escolha. i. Forçar a solução à sua maneira, obviamente, afastará o gerente do departamento. O fato de que vocè pretende honrar o pedido dele em um momento posterior poderia dar-lhe algum alí­ vio, especialmente se ele entende o seu problema e o possível impacto da decisão dele em outros departamentos. Atribua três pontos na linha I para essa escolha.

g.

d.

e.

f.

PARTE 2: ENTENDIMENTO DAS EMOÇÕES

Utilizando a tabela de pontuação indicada na página 224, determine a sua pontuação total. Registre o seu total na caixa apropriada, na linha 2 da tabela na página 199. Não há, “absolutamente”, respostas corretas para esse proble­ ma, apenas o que parece ser o “mais” correto.

g.

PARTE 3: ESTABELECIMENTO DAS COMUNICAÇÕES

a.

b.

c.

Embora suas explicações possam ser aceitáveis e a responsabilidade pelo sobrecusto possa ser atribuída ao gerente do departamento, você nào fez qualquer tentativa para abrir a comunicação com o gerente do departamento. Novos confli­ tos parecem inevitáveis. Se essa foi sua escolha, conceda uma pontuação de zero na linha 3 da planilha. Você não está oferecendo ao gerente do depar­ tamento nenhuma escolha, a não ser a de elevar o conflito. Ele provavelmente não teve tempo al­ gum para pensar sobre a mudança de seus requi­ sitos e é extremamente duvidoso que ele vá ceder a você, uma vez que você já o colocou na parede. Conceda zero pontos na linha 3 da planilha. Ameaçá-lo pode fazê-lo mudar de ideia, mas certamente causará a deterioração das relações de trabalho tanto neste projeto quanto em quais­ quer outros que exigirão que você se relacione com o seu departamento. Insira zero pontos se essa foi a sua escolha.

Enviar-lhe um memorando solicitando uma reunião em uma data posterior dará a ele e a você uma chance de esfriar a cabeça, mas pode não melhorar sua posição de barganha. O geren­ te do departamento pode, agora, ter tempo de sobra para se certificar novamente de que estava certo porque você provavelmente não está sob uma terrível restrição de tempo, como levou-o a acreditar, já que você pode esperar vários dias para vê-lo novamente. Atribua quatro pontos na linha 3 da planilha, se essa foi a sua escolha. Você está indo na direção certa ao tentar abrir as comunicações. Infelizmente, pode ainda pro­ vocá-lo dizendo que ele perdeu a calma e que deveria pedir desculpas para você quando, du­ rante todo o tempo, você pode ter sido o único a perder a calma. Demonstrar arrependimento como parte de suas observações iniciais benefi­ ciaria a situação. Atribua seis pontos na linha 3 da planilha. Adiar o problema pode nào ajudá-lo. O gerente do departamento pode considerar o problema resolvido porque ele não teve notícias suas. O confronto não deve ser postergado. Sua escolha tem mérito no sentido de que você está tentando abrir um canal de comunicação. Insira quatro pontos na linha 3, se essa foi a sua escolha. Demonstrar arrependimento e buscar solução imediata é a melhor abordagem. G>m sorte, o gerente agora compreenderá a importância des­ se conflito e a necessidade de urgência. Atribua dez pontos na linha 3 da planilha.

Rmkôo

Ponluoção

pessool ou em grupo

o. Eu lhe dei mmho resposta. Procure o gerente

Hostil ou ewswo

4

gerol. se você noo esta contente.

b. Fu entendo o seu problema. Vamos fazer do Aceitação

4

seu jeito.

c. Eu entendo o seu prodemo, mas you fazer

Defensivo ou hostil

4

Cooperai»

4

o que é meter poro o meu departamento.

d. Vomas ifccutir o problema. Takez hejo oternOrvos.

e. Deixeme explica owcè per que precisamos Cooperar» ou dos revos requisitos.

f. Procure os supervisores do minha seção.

4

defensivo

Evasivo

4

Hostil ou defensivo

4

Isso foi recomendação deles.

g. Hoyos gerentes devem trazer news e mdhues fumas, nõo devem?

Total:

Pessod 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

Pessoal ou em

Grupo

o. 0$ requisitos soo decrsoc minto e

ImposKOO

4

Evosoo ou Suavizoçoo

4

Concessão ou Confronto

4

Suavização. Confronto ou

4

vwnos fazer do nosso jeito.

b. Eu pensei sobe isso e você esto cerIo. Vomos fazer do seu jeito. c. Vomos (fccuiroproblemo. Tobez hqo ohemaiwas.

d. Deixecne explicar poc que precisamos dos novos requisitos. e. Procure os supervisores do minto

Imposição EvOSÕO

4

Suavizoçoo ou Concessão

4

seção, eles estoo trotando disso

ogoro. f. Eu onaísei o proüemo e devo ser capaz de ceder em alguns dos

requisitos. M

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 discordâncias. 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 fíitura. 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 difícil 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 de 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. A melhor abordagem. Tudo está bem. (5 pontos) b. 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 funciona) 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

ÁREA DO 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. Haveria 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 barer 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? Todos os projetos precisam de gerenciamento dc projetos? Como a utilização de uma metodologia formal de gerenciamento 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ê.”

APÊNDICE C - ESTUDOS DE CASOS

2.

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? Como se difere da definição de um projeto? A 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

“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?"

VP:

Questões

I.

769

DORALE PRODUCTS

Iodos os projetos devem exigir a utilização dos princípios de gerenciamento de projetos?

3. 4.

Que tipo de projeto deve ou não exigir o uso de uma metodologia de gerenciamento de projetos? Como a magnitude dos requisitos de integra­ ção afeta a sua resposta à pergunta anterior? 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 cm 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á correto 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 cido 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 gale 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

1.

2.

3. 4.

5.

Qual é a definição padrão de sucesso (ou seja, fatores primários)? Como isso se relaciona à restrição tripla? Quais seriam os exemplos de fatores secundá­ rios de sucesso? Qual seria uma definição razoável de fracasso do projeto? Essas definições e fatores deveríam ser incluí­ dos em uma metodologia de gerenciamento de projetos? Há algum risco em relação à inserção de fa­ tores primários e secundários de sucesso na metodologia?

APÊNDICE C - ESTUDOS DE CASOS

771

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

1. Qual deve ser o papel principal do patrocinador? 2. 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?

“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 vtxzê! 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?”

772

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 é difieiI 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?

APÊNDICE C - ESTUDOS DE CASOS

773

DORALE PRODUCTS

DORALE PRODUCTS (J)

Questões

É 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? 2. As políticas e procedimentos de seleção de pes­ soal deveríam ser direcionadas para os gerentes de projetos, gerentes de linha ou ambos? 3. 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? 4. 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? 5. A seleção de pessoal para o projeto é uma deci­ são de “responsabilidade”? 6. Ê de responsabilidade do gerente de projetos ou do gerente de linha definir adequadamente o nível de habilidades necessário para completar uma tarefa? 7. 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?

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 Pessoa) Para o Projeto 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. A Reunião

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.”

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)

1. 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

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. A 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.

DORALE PRODUCTS

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 cliente. 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

2.0

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

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.3.3.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

83.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

6.3.2

383,386,389

9.1.2

10, 149,152

6.3.2.1

398,399,400

9.1.3

147

63.2.2

386,388

9.2

123,134

63.2.3

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.23

233,237,238,239

6.6.2

385,390

93.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.Ô

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

11.53.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.