Gestão de Projetos - As Melhores Práticas, 3 Edição KERZNER, Harold OCR

Harold Kerzner é um especialista internaciona lmente reconhecido na área de gestão
de projetos e Diretor Executivo Sênior no lntemational lnstitute for Learning (IIL). É

mestre e doutor e1n Engen haria Aeronáutica e Astronáutica pela University of Il linois
e possui MBA pela Utah State University. Lecionou na área da engenharia na Univer-
sity of Illinois e na área da administ ração na Uta h State University, e por 37 anos foi
professor de gestão de projetos na Baldwin-Wallace Universi ty. Publicou inú1neros
artigos de engenha ria e negócios, e é autor de mais de 50 livros sobre gestão de pro-
jetos, incluindo O que os executivos precisam saber sobre gerenciamento de projetos,
Gerenciamento de projetos orientado por valor e O que os gerentes precisam saber
sobre projetos, todos publicados pela Book1nan Editora.
K4lg Kerzner, Harold .

Gestão de projetos : as melhores práticas [recurso
eletrônico]/ Harold Kerzner; tradução: Christiane de Brito
Andrei ; revisão técnica: Fábio Giordani. - 3. ed . - Porto
Alegre: Bookman, 2016.
Editado como livro impresso em 2016.

ISBN 978-85-8260-381-9
1. Gestão de projetos. 2. Metodologias de

gerenciamento. 3. Excelência comportamental. I. Título.
CDU 005.8
Catalogação na publicação: Poliana Sanchez de Araujo - CRB 10/2094

HAROLD KERZNER, PH.D.
DE PROJETOS
'
AS MELHORES PRATICAS
3 a
E D I Ç Ã O
Tradução:
Christiane de Brito Andrei
Revisão técnica:
Fábio Giordani
Mestre e,n Administração e Negócios pela PUCRS
Professor nos programas de pós-graduação da ESPM e da PUCRS
Certificado PMP® e voluntário do PMI-RS desde 2009
Gerente de Projetos e Programas na Deli
Versão impressa
desta obra: 2017
~~
bookman
2017
Obra originalmente publ icada sob o título
Proiect Management - Best Practices: Achieving Global Excellence, 3'd Edition
ISBN 9781118657010
Ali Rights Reserved . This translation published under license ,vith the origina l publisher
John Wi ley & Sons, lnc.
Copyright ©2014,John Wiley & Sons, Inc.
Gerente editorial: Arysinha jacqttes Affonso
Colaboraram nesta edição:
Editora: Maria Edttarda Fett Tabajara
Capa: Márcio lvfonticelli
Imagem da capa: ©thinkstockphotos.com / }11piterimages, Leonard Zakim Bridge, Boston,

lvf.assach11setts
Leitura final: Lia Cremonese
Editoração: Techbooks
Reservados todos os direitos de publicação, e1n língua portuguesa, à

BOOKMAN EDITORA LTDA., uma empresa do GRUPO A EDUCAÇÃO $.A.
Av. Jerôni1no de Ornelas, 670 - Santana
90040-340 Porto Alegre RS
Fone: (51 ) 3027-7000 Fax: (51) 3027-7070
Unidade São Paulo

Rua Doutor Cesário Mota Jr., 63 - Vila Buarque
01221 -020 São Paulo SP
Fone: (11 ) 3221-9033
SAC 0800 703-3444 - W\V\v.grupoa.com.br
É proibida a duplicação ou reprodução deste volume, no todo ou em parte, sob quaisquer

formas ou por quaisquer meios (eletrônico, mecânico, gravação, fotocópia, distribuição na Web
e outros), se1n permissão expressa da Editora.
IMPRESSO NO BRASIL
PRINTED IN BRAZIL
À minha esposa, }o Ellyn,
q11e tne mostro11 que a excelência
pode ser alcançada no
casa,nento, na família e na vida,
a/é,n de no trabalho.
Esta página foi deixada em branco intencionalmente.
Prefácio
Por cerca de 50 anos, a gestão de projetos foi vista con10 un1 processo interessante,
n1as desnecessário para a sobrevivência da empresa. As en1p resas insistian1 en1 in-
vestir em alguns cursos de t reinamento apenas para que seu pessoal tivesse acesso a
conhecimentos básicos sobre p lanejamento e criação de cronogran1as. A gestão de
projetos era considerada uma an1eaça a h ierarquias já estabelecidas, e em muitas
empresas só era utilizada de forn1a parcial. Esta in1plementação irresoluta ocorreu
sin1plesn1ente para acaln1ar os ânimos do pessoa l de níveis n1ais baixos ou interme-
diários, a lém de clientes selecionados.
Durante estes 50 anos, fizemos todo o possível para evitar que a excelência em
gestão de projetos fosse alcançada. Só falávan1os da boca para fora sobre empode-
ran1ento, trabalho em equipe e confiança. Acun1ulávamos informações porque o
controle da informação era um poder. Colocávan1os interesses pessoais e funcionais
à frente dos interesses da empresa e n1antínhamos a falsa crença de que o tempo era
un1 luxo em vez de un1a restrição.
Em meados da década de 1990, essa n1entalidade começou a naufragar, em
grande parte devido a duas recessões econômicas nos Estados Unidos. As empresas
enfrentavam severas pressões competitivas para criar produtos de alta qua lidade
em p razos cada vez n1enores, e a in1portância de desenvo lver un1 relacionan1ento
de confiança de longo prazo con1 os clientes chegara à tona. As partes interessadas
estavan1 forçando as en1presas a muda r para n1elhor. A sobrevivência da empresa,
então, passou a ser a grande preocupação.
Hoje, as empresas muda ram pa ra melhor. A confiança entr e os clientes e os
fornecedores nunca foi tão grande. Novos produtos estão sendo desenvolvidos a
um ritmo jamais visto. A gestão de projetos se to rnou uma arma con1petitiva du-
rante a licitação con1petitiva. Algun1as empresas assinan1 contratos exclusivos de-
vido à fé do cliente na sua capacidade de entregar un1 fluxo contínuo de projetos
bem-sucedidos usando uma metodologia de gestão de projetos. Todos esses fatores
permitiram que un1a enorme variedade de empresas atingisse un1 grau de excelência
em gestão de projetos. As decisões empresariais agora tên1 mais prioridade do que
decisões pessoais.
Pa lavras que eram lugar-comun1 há dez anos hoje assumem novos significados.
Mudanças não são mais vistas con10 algo totalmente ruim; hoje, mudanças impli-
cam n1elhorias contínuas. Conflitos não são mais vistos con10 a lgo negativo; se bem
gerenciados, confl itos podem ser benéficos. A gestão de projetos não é mais vista
como um sisten1a totalmente interno à organização; agora é un1a arma competitiva
que t raz ao cliente níveis mais altos de qualidade e n1aiores oportunidades de valor
agregado.
vi ii Prefácio
As empresas tidas como excelentes no passado podem não n1a is ser vistas con10
excelentes hoje, especia lmente no que d iz respeito à gestão de projetos. Conside-
re, por exemplo, o livro ln Search of Excellence, escrito por Tom Peters e Robert
\Vaterman em 1982 (publ icado pela Harper & Ro,v, Nova York). Quantas das
en1presas ali exa ltadas ainda são consideradas excelentes? Quantas dessas empre-
sas ganharan1 o prestigioso Malcolm Baldrige National Quality Award? Quantas
ganhadoras do p rêmio a inda protagonizam o rol da excelência? A excelência en1
gestão de projetos é uma jornada sen1 fim. As empresas que relutam em investir en1
melhorias contínuas em en1 gestão de projetos logo se encontram com baixas taxas
de satisfação entre os clientes.
O que faz a diferença entre os prin1ei ros 50 anos da gestão de projetos e os
últimos dez é a abrangência da sua imp len1entação. Passamos mais de 30 anos
exa ltando as ferramentas quantitativas e con1portan1entais da gestão de projetos.
Enfatizavam-se un1 conhecin1ento básico e habilidades prin1árias, e a especialização
na área era limitada a poucos. Entretanto, ao longo dos últimos dez anos, passou-se
a primar pela in1p lementação macro da gestão de projetos, em toda a en1presa. A
questão estratégica n1ais in1portante hoje é con10 colocar 30 anos de teoria que es-
tavam nas mãos de poucos em prática en1 toda a corporação. É a implementação da
gestão de projetos em toda a en1presa que constitui a gestão avançada de projetos.
Tópicos como análise de valor agregado, liderança situacional e controle de custos
e n1udanças hoje fazem parte dos cursos básicos de gestão de projetos, n1as há 15
anos eram considerados avançados. Hoje, con10 implen1entá-la, quais são suas me-
todologias en1presariais e con10 trabalhar con1 as partes interessadas constituem os
tópicos avançados da gestão de projetos aplicada.
Este livro aborda os pontos mais avançados necessários para implen1entar a
gestão de projetos e atingir sua excelência. O texto contém inún1eras citações de
profissiona is da área que con1pararam e confrontaram as n1elhores práticas en1
gestão de projetos e estão atualmente implen1entando esses processos nas suas pró-
prias en1presas. Fornecidas por vários CEOs, presidentes, COOs, C!Os, CFOs, VPs
sên ior, VPs, VPs globais, gerentes gerais, diretores de PMO, etc, as citações são ines-
tin1áveis por most raren1 como esses líderes pensan1 e o run10 que suas empresas
estão ton1ando. Essas en1p resas alcançaran1 certo grau de excelência en1 gestão de
projetos, e o que é realn1ente notável é o fato de que isso aconteceu en1 menos de
. .
cinco ou seis anos.
As n1elhores p ráticas na implen1entação serão o fut uro da gestão de projetos no
sécu lo XXI. As en1presas criaram bibliotecas de n1elhores práticas, e muitas são usa-
das durante licitações como um d iferencial competitivo . As n1elhores práticas en1
gestão de projetos hoje são consideradas propriedade intelectual. Não se alcança a
excelência sin1plesmente desenvolvendo un1a metodologia de gestão de projetos: é o
modo con10 a n1etodo logia é usada repetidas vezes que cria a excelência e um fluxo
de projetos gerenciado con1 sucesso.
As práticas e n1etodologias de gestão de projetos são construídas em torno da
cultura das en1presas e determ inando o que é preciso pa ra que as pessoas traba-
lhen1 juntas, solucionen1 problen1as e tomem decisões. Con10 cada empresa ten1
sua própria cu ltura, é compreensível que cada uma tenha um nún1ero diferente de
fases de ciclo de vida, diferentes pontos de decisão e d iferentes critérios de sucesso.
Nenhuma abordagem única serve a todas as empresas, o motivo pelo qual este livro
discute diversas empresas, en1 d iferentes indústrias, de diferentes tan1anhos e en1 d i-
Prefácio ix
ferentes continentes. Esperamos que, depois de ter lido este livro, você tenha ideias
sobre a como suas atividades de gestão de projetos podem n1el ho rar.
As empresas que são discutidas neste livro incluem:
3M Indra
ABB Johnson Contrais
Alcatel-Lucent Key Plastics
Alstom Kodak
Americ.an Greetings KONE
AT &T maxIT-VCS
Aviva MCI
Babcock & \Vilcox Medical Mutual
Bendix Microsoft
Boeing Minnesota Power & Light
Cassidian Motorola
Chrysler NASA
Chubb Nea l and Massy Holdings, Ltd.
Churchill Downs Nortel
Comau NXP
Computer Associares Ohio Bell
Cooper Standard Orange Switzerland
csc Our Lady of Lourdes
Deli Regiona l Medical Ctr.
Deloitte Philips
Department of Defense Repsol
DFCU Financial Roadway Express
Dow Chemic.al Rockwell Auto1nation
DTE Energy SAP
EDS Sherwin Willia1ns
Eli Li lly Siemens
Enakta SigmaPM
Eric.sson Sla lom
Fluor Star All iance
Ford Tech Mahindra Limited
General Motors Tecn icas Reunidas
Goodyea r Teradyne
Harris Thiokol
Hewlett-Packard Tokio Marine
Hitachi Visteon
Holcim Wartsilii
IBM Westfield Group
ILLUMINAT World Wildlife Fund
Zurich North Americ.a
x Prefácio
Seminários e webinars sobre os princípios e as melhores práticas de gerenciamento

de projetos são disponibilizados aos usuários deste livro e de meu livro Project Mana-
gement: A Systems Approacb to Pla1111ing, Scheduling, and Controlling, 11 t h edition
(Wiley, Hoboken, Ne,v Jersey, 2013). Há também seminários sobre gerenciamento de
projetos avançado. Para obter informações sobre esses cursos, cursos de e-learning e
seminários públ icos ou oferecidos pela empresa, entre em contato com:
Lori Mi lhaven, Vice-Presidente Executiva, IIL:
Telefone: 800-325-1533 ou 212-515-5121

Fax: 212-755-0777
E-1nail: lori.milhaven@iil.com
Harold Kerzner
lnternationa l Institute for Learning, Inc.
2014
Sumário
Capítulo 1 Compre endendo as melhores práticas 1

1.0 Int rodução 2
1.1 Wartsila 2
1.2 Melhores práticas em gestão de projetos: 1945- 1960 3
1.5 A gestão de projetos vista por um executivo 13
1.6 Processo de melhores práticas 17
1.7 Passo 1: definição de uma 1nelhor prática 18
1.8 Passo 2: em busca das melhores práticas 22
1.9 Dashboards e Scorecards 33
1.10 Indicadores-chave de desetnpenho 36
1.11 Passo 3: validar a melhor prática 41
1.12 Passo 4: níveis das melhores práticas 44
1.13 Passo 5: gerenciamento das melhores práticas 46
1.14 Passo 6: revalidando melhores práticas 46
1.15 Passo 7: o que fazer com uma melhor prática 47
1.16 Passo 8: comun icar as melhores práticas por toda a empresa 48
1.17 Passo 9: garantir o uso das 1nelhores práticas 50
1.18 Crenças comuns 51
1.19 Biblioteca de melhores práticas 52
1.20 Hewlett-Packard: melhores práticas em ação 54
1.21 DTEEnergy 57
1.22 A gestão de projetos e as melhores práticas vistas
por um consultor 61
Capítulo 2 Da melhor prática a uma enorme dor de cabeça 67

2.0 Int rodução 67
2.1 Dor de cabeça nQ1: boas intenções 67
2.2 Dor de cabeça n" 2: a metodologia de gestão
de projetos da empresa 68
2.3 Dor de cabeça n" 3: a satisfação do cliente 69
x ii Sumário
2.4 Dor de cabeça n" 4: mudanças nas exigências do cliente 70

2.5 Dor de cabeça n" 5: a quem o PMO deve se reportar 71
2.6 Dor de cabeça ng 6: o dilema do fluxo de caixa 71
2.7 Dor de cabeça n" 7: o dilema da mudança de escopo 72
2.8 Dor de cabeça n" 8: equil ibrar 73
2.9 Dor de cabeça n2 9: quando cancelar um projeto 73
2.10 Dor de cabeça n" 10: oferecer reco1npensas 74
2 .11 Dor de cabeça n" 11: ter a cu ltura errada em vigor 75
2 .12 Dor de cabeça 112 12: questões políticas 76
2 .13 Dor de cabeça n" 13: os Sete Pecados Capitais 83
2 .14 Fontes de dores de cabeça menores 95
2 .15 Os dez perigos dos projetos 98
Referências 105
Capítulo 3 Jornada rumo à excelência 106

3.0 Introdução 106
3.1 Planeja1nento estratégico para a gestão de projetos 108
3.2 Hitachi Ltd. 117
3.3 KONE: o desafio da gestão de projetos 129
3.4 A luz no fim do túnel 132
3.5 Goodyear 134
3.6 Gerenciando prem issas 139
3.7 Gerenciando pre1nissas em projetos de conservação -
WWF lnternational 139
3.8 Governança de projetos 141
3.9 Sete falácias que at rasam a maturidade
da gestão de projetos 145
3.10 Motorola 147
3 .11 Texas Instruments 148
3.12 Hewlett-Packard: reconhecendo a necessidade 150
3.13 Hewlett-Packard: a jornada e os obstáculos 152
3.14 Cooper Standard 159
3.15 Navia ir: dentr o do prazo, dentro do orçamento 165
3.16 DTE Energy 174
3.17 Key Plastics 175
3.18 A ILLUMINAT e o negócio estratégico
da gestão de projetos 179
3.19 Avalon Po,ver and Light 182
3.20 Roadway Express 183
3 .21 Defcon Corporation 184
3.22 Kombs Engineering 186
3.23 Williams Machine Tool Co1npany 187
Sumário xiii
Capítulo 4 Metodologias de gestão de projetos 189

4.1 Definição de excelência 189
4.2 Reconhecendo a necessidade do desenvolvimento
de uma 1netodologia 192
4.3 Metodologias empresaria is de gestão de projetos 197
4.4 Benefícios de uma metodologia-padrão 201
4.5 Co1nponentes críticos 203
4.6 SAP 205
4.7 Cassidian: cronogra1nas mulrinível integrados 208
4.8 Tecn icas Reunidas 211
4.9 Teradyne: de miro a realidade 218
4.10 Slalom Consulting: funções da gestão de projetos 222
4.11 Slalom Consulting: substituindo metodologias por 1nodelos 224
4.12 Fases do ciclo de vida 225
4.13 Expandindo as fases do ciclo de vida 226
4.14 Church ill Do,vns, l nc. 228
4.15 lndra: a necessidade de uma metodologia 228
4.16 Implementando a metodologia 230
4.17 Erros na implementação 232
4.18 Superando barreiras ao desenvolvünento e à implementação 233
4.19 Ferra1nentas de gestão de projetos 234
4.20 Wartsilii: reconhecendo a necessidade
de ferramentas de suporte 239
4.21 Tech Mahindra Lrd.: monitoramento dos processos
de projetos 241
4.22 Tech Mahindra Lrd.: índice de satisfação do cliente
para proJetos 245
4.23 General Motors Po,vertrain Group 248
4.24 Ericsson Teleco1n AB 250
4.25 Indra: encerrando o projeto 252
4.26 Repsol: a metodologia GIPº da Repsol E&P -
o processo de gestão de qual idade
do projeto aplicado à tomada de decisões 255
4.27 Rockwell Auro 1nation: e1n busca de um processo comum 264
4.28 Sherwin-Williams 269
4.29 Medica l Mutua l 272
4.30 Holcim 276
4.31 Westfield Group 278
4.32 Hewlett-Packard 281
4.33 DTEEnergy 284
4.34 Alstom 291
4.35 Cassidian: regras áureas para a gestão de projetos 295
4.36 Quando metodologias t radicionais talvez não funcionem 297
xiv Sumário
Capítulo 5 Processos integrados 301

5.1 Compreendendo os processos integrados de gerenciamento 301
5.2 Evolução de p rocessos complementares
de gestão de projetos 303
5.3 Zurich America Insurance Company 306
5.4 Gestão da qual idade total 308
5.5 Engenharia simultânea 313
5.6 Gestão de riscos 313
5.7 Wãrtsila: a necessidade de uma gestão
de riscos proativa 316
5.8 ILLUMINAT: gestão de riscos eficiente 319
5.9 Indra: quando um risco se torna uma real idade
(gerenciamento de problemas) 323
5.10 O fracasso da gestão de riscos 325
5.11 Definindo a maturidade usando a gestão de r iscos 326
5.12 Boeing Aircraft Company 327
5.13 Gerenciamento de mudanças 328
5.14 Outros processos de gerenciamento 329
5.15 Hewlett-Packa rd 330
5.16 Mensuração do va lor agregado 331
5.17 DTE Energy 331
Capítulo 6 Cultura 333

6.1 A criação de uma cultura corporativa 333
6.2 Valores corporativos 335
6.3 Tipos de culturas 336
6.4 Cu lturas corportivas na prática 337
6.5 Indra: const ruindo uma cultura coesa 340
6.6 maxIT-VCS 343
6.7 DFCU Financia l 346
6.8 ILLUMlNAT (Trinidad & Tobago) Ltd. 362
6.9 DTE Energy 364
6.10 Hewlett-Packa rd 365
6.11 Barreiras à implementação da gestão de projetos
em mercados emergentes 366
Capítulo 7 Apoio por parte da gerência 373

7.1 Apoio visível por pa rte dos gerentes sênior 373
7.2 Patrocínio de projetos 374
7.3 Excelência e1n pat rocínio de projetos 378
Sumário xv
7.4 Patrocínio em ação na Hev.rlett-Packard 379

7.5 Zurich America lnsurance Company: melhorando
o engajamento das partes interessadas 379
7.6 Governança de projeto 381
7.7 Tokio Marine: excelência na governança de um projeto 383
7.8 Empoderamento dos gerentes de projetos 389
7.9 Apoio por parte da gerência na prática 390
7.10 Obtendo o apoio da gerência de área 393
7.11 DTEEnergy 394
7.12 Defensores convictos da iniciação e do encerra1nento 394
Capítulo 8 Treinamento e formação 399

8.1 Treinamento por uma gestão de projetos moderna 399
8.2 A necessidade de uma formação em negócios 400
8.3 SAP: importância de um plano de carreira
de gestão de projetos 402
8.4 lntemational lnstitute for Leaming 404
8.5 Identificando a necessidade de t reinamento 408
8.6 Selecionando alunos 408
8.7 Fundamentos da formação em gestão de projetos 409
8.8 Algumas mudanças na formação em gestão de projetos 410
8.9 Planejando cursos e minist rando o t reinamento 411
8.10 Medindo o retorno sobre o investimento
na formação dos funcionários 414
8.11 A gestão de projetos agora é uma profissão 414
8.12 Modelos de competências 416
8.13 Harris Corporation 428
8.14 Alcatel-Lucent: reconhecendo o va lor de um PMP® 432
8.15 Gestão de projetos integrada na Tech Mahindra Ltd. 434
Capítulo 9 Gestão informal d e p ro jetos 439

9.1 Gestão de projetos informal versus formal 439
9.2 Confiança 442
9.3 Co1nun icaçâo 443
9.4 Cooperação 445
9.5 Trabalho em equipe 445
9.6 Relatórios de status com cód igos de cores 446
9.7 Dashboards de crises 447
9.8 Gestão informa l de projetos na prática 450
xvi Sumário
Capítulo 10 Excelência comportamental 452

10.1 Liderança situaciona l 452
10.2 Resolução de conflitos 455
10.3 Selecionando funcionários tendo e1n mente a excelência 457
10.4 Equ ipes de projetos virtuais 459
10.5 Recompensando as equipes de projetos 461
10.6 A chave da excelência comportamental 464
10.7 Gerenciamento proativo vers1,s reativo 467
Capítulo 11 Medindo o retorno sobre o investimento em treinamento

em gestão de projetos 472
11.1 Benefícios da gestão de projetos 473
11.2 O crescimento da 1nodelagem do ROi 474
11.3 O 1nodelo ROi 475
11.4 Fase do ciclo de vida dedicada ao planejamento 476
11.5 Fase do ciclo de vida dedicada à coleta de dados 477
11.6 Fase do ciclo de vida dedicada à aná lise 480
11.7 Fase do ciclo de vida dedicada à geração de relatórios 484
11.8 Conclusões 484
Capítulo 12 O escritório de projetos 485

12.1 Boeing 487
12.2 A Philips Healthcare e o Software Customer Service 489
12.3 maxIT-VCS 496
12.4 Aviva 498
12.5 Churchill Downs Inc. (CDI): estabelecendo um PMO 513
12.6 Churchill Downs Inc. (CDI): gerenciando
mudanças no escopo 514
12.7 Tipos de escritórios de projetos (EP, PO ou PMO) 518
12.8 Dell Inc. 519
12.9 Computer Sciences Corporation (CSC) 528
12.10 Sla lo1n Consulting: compreendendo a natureza de um PMO 534
12.11 DTE Energy 542
12.12 Chubb 543
12.14 Star Alliance 547
12.15 Auditorias de projetos e o PMO 548
12.16 Verificações da "saúde" dos projetos 552
12.17 Prêmio PMO do Ano 553
Sumário xvi i
Capítulo 13 S e is S igma e o escritório de gestão de projetos 562

13.1 Relação entre gestão de projetos e Seis Sigma 562
13.2 Envolvendo o PMO 564
13.3 Seis Sigma tradicional versus não trad icional 565
13.4 Co1npreendendo o Seis Sigma 567
13.5 Os mitos do Seis Sigma 569
13.6 Uso de avaliações 572
13.7 Seleção de projetos 574
13.8 Típicos projetos Seis Sigma do PMO 576
Capítulo 14 Gere nciame nto d e portfólio de projetos 578

14.1 Por que usar o gerenciamento de portfólios? 579
14.2 Envolvimento da gerência sênior, das partes
interessadas e do PMO 580
14.3 Obstáculos à seleção de projetos 584
14.4 Identificação de projetos 585
14.5 Ava liação prel iminar 588
14.6 Seleção estratégica de projetos 590
14.7 Planejamento estratégico 592
14.8 Ana lisando o portfól io 593
14.9 Proble1nas em atender as expectativas 594
14.10 Gerenciamento de portfólio na Rockwell Automation 597
14.11 Fundo 1nundia l para a natureza
(\Vorld \Vildl ife Fund, WWF) 599
Capítulo 15 Exce lê ncia e m g e s tão de proje tos g lo bal 605

15.1 A cultura da IBM 606
15.2 Co1nputer Associares Technologies (CA):
sucesso na entrega e na gestão de projetos 632
15.3 Microsoft Corporation 646
15.4 Deloitte: gerenciamento de programas empresarial 658
15.5 COMAU 678
15.6 Fluor Corporation: gerenciamento de conhecimentos
para a execuç.ã o de projetos 691
15.7 Siemens PLM Soft\vare: desenvolvendo uma metodologia
de gestão de projetos global 704
xviii Sumário
Capítulo 16 Gestão de p rojetos o rientada a valor 713

16.1 Valor no decorrer dos anos 714
16.2 Valores e liderança 716
Capítulo 17 Efe ito das fusões e a q uis ições na gestão de p rojetos 728
17.1 Planejamento para o crescimento 728
17.2 Cadeia de va lor agregado da gestão de projetos 729
17.3 Tomada de decisões pré-aquisição 732
17.4 Proprietários e inqui linos 737
17.5 Melhores práticas: estudo de caso da Johnson Contrais, lnc. 738
17.6 Resultados da integração 742
17.7 Estratégias da cadeia de valor 744
17.8 Fracasso e reestruturação 746
Índice 749
Compreendendo as
melhores práticas
1.0 Introdução
A gestão de projetos evoluiu de u1n conjunto de processos recomendável para uma me-
todologia tida como obrigatória para a sobrevivência da empresa. As empresas agora
estão percebendo que todo o seu negócio, inclusive a maioria das atividades rotineiras,
pode ser compreendido co1no uma série de projetos. Di to de forma simples, estamos
gerenciando nosso negócio por meio de projetos.
A gestão de projetos hoje é vista tanto como u1n processo de gestão de projetos
quanto como um processo de negócios. Portanto, espera-se que os gerentes de projetos
tomem decisões de negócios, a lém de decisões de projeto. A necessidade de alcançar
a excelência na gestão de projetos hoje é muito evidente em quase todos os negócios.
À medida que a relativa importância da gestão de projetos passa a permear cada
faceta do negócio, acumula-se conheci1nento sobre suas melhores práticas. Algumas
empresas veem esse conhecimento como propriedade intelectua l a ser guardada a
qua lquer custo nas cúpulas da empresa. Outras comparti lha1n -no na esperança de des-
cobrir outras melhores práticas. Hoje as empresas preferem real izar um planeja1nento
estratégico para a gestão de projetos devido aos benefícios e à sua contribuição para
um valor sustentável dos negócios.
U1n dos benefícios de realizar um planejamento estratégico para a gestão de pro-
jetos é que ele normalmente traz à tona a necessidade de identificar e reter as melhores
práticas. Infel izmente, isso não é fácil de ser efetivado. Um dos motivos dessa difi-
culdade, como vere1nos mais adiante neste capítulo, é que as empresas não estão de
acordo quanto à definição do que seriam "melhores práticas", além de não compreen-
derem que melhores práticas levam a melhorias contínuas, que, por sua vez, levam à
adoção de novas melhores práticas. Muitas empresas também não reconhecem o valor
e os benefícios que podem decorrer das melhores práticas.
Atualmente, os gerentes de projetos estão adotando melhores práticas tanto nas
atividades da gestão de projetos quanto nas atividades de negócios. O motivo é sim-
ples: as melhores práticas são propriedade intelectua l que incentiva as empresas a ter
um dese1npenho cada vez ma is alto. As melhores práticas levam a um maior valor de
negócio, uma maior concretização de benefícios e 1nelhores ativ idades de gerencia-
mento de benefícios. A gestão de projetos e o pensamento empresarial não são mais
atividades separadas.
2 Gestão de projetos
1
1.1 Wãrtsilã
Gerenciamento de benefícios em projetos de desenvolvimento
operacional na Wãrtsilã
A \1v'ãrtsi la possui uma forte tr adição em negócios baseados em projetos e práticas de
gerenciamento. Assiin, estabeleceu-se um escritório para gerencia r os projetos de toda
a empresa em 2007 com o intuito de fortalecer ainda mais essa competência dentro do
grupo e de desenvolver uma cu ltura de gestão de projetos e seus processos, competên-
cias e ferramentas.
Hoje, as estruturas e as formas de trabalhar com gestão de projetos tornara1n-se
u1na parte fundamental do pensamento empresaria l da Wãrtsi lã. O modelo de pro-
cesso empresarial passou gradua lmente de um processo u1n tanto desordenado a um
modelo harmonizado que perm ite a implementação de diret rizes, terminologia e a l-
vos unificados. A empresa abordou a implementação dessas práticas a partir de dois
aspectos diferentes, mas igua lmente importantes. Em primeiro lugar, apresentou-se e
implementou-se uma ferramenta de gestão de projetos que fornece, entre outras coi-
sas, um p lanejamento mais eficiente dos recursos e do cronograma da etnpresa. Em
segundo lugar, a organ ização foi incentivada a participar ativamente de t reinamentos
profissionais e programas de certificação em gestão de projetos.
À medida que tais processos foram tomando forma e amadurecendo, a ênfase foi
passando gradualmente para o gerenciamento de benefícios em projetos de desen-
volvimento operaciona l. A in iciativa de aprimorar os processos de gerencia1nento de
benefícios decorre da missão do escritório de projetos (Project Management Office -
PMO) de desenvolvimento operacional da Wãrtsilii, que é garantir sinergias entre as
unidades empresariais que possibilitaria1n que empresas transformassem sua ambição
estratégica em operações cotidianas. Isso seria alcançado propiciando gerenciamento
e experiência em termos de gestão de 1nudanças, processos empresaria is e desenvolvi-
mento de aplicativos.
Na gestão de projetos tradicional, os projetos geralmente são 1nedidos segundo
o rçamento, cronograma, escopo ou qualidade. O gerenciamento de benefícios como
u1n conceito, no entanto, prioriza ma is o valor real que os projetos são capazes de
gerar para o cliente final. Em outras palavras, o sucesso do projeto não é 1nedido
somente segundo tempo ou dinheiro; a medida de seu sucesso vem do usuário fina l:
a solução atendeu às necessidades do usuário? Como o conceito de valor é bastante
vago, é de suma importância que os benefícios tenham 1nétr icas e medidas concre-
tas. Isso envolve ta 1nbém os chamados benefícios intangíveis. Embora não possam ser
quantificados financeiramente, eles têm de ser medidos. U1n out ro aspecto importante
no planejamento de benefícios é criar uma base válida com a qual se possam compa-
rar os resultados: e1n vez de compará-los apenas co1n uma situação habitua l de BAU
(bttsiness as us11al), os resu ltados obtidos co1n as medidas de concretização de benefí-
cios devem ser comparados com cenários alternativos (" Este resultado poderia ter sido
alcançado de outra maneira?" ).
Em desenvolvimento operacional, a saída do projeto pode ser, por exemplo, uma
ferramenta de TI criada para aprimorar o planejamento de recursos . A parte mais cru-
cial, no entanto, é fazer essa saída se tornar um resultado do projeto. Isso significa que
a saída do projeto (nesse caso, uma ferramenta de TI) deve se tornar pa rte do 1nodo
1
M.arerial fomecido pelo Wãrrsilã Projecr X'1anagemen.r Office (\VPMO). Direfros autorais de \Vártsilã Cor·
porarion, ©2013. Reproduzido com permissão.
Capítulo 1 Compreendendo as melhores práticas 3
de t rabalhar do usuário fina l. Para que isso aconteça, o planejamento de benefício te1n
que levar em consideração dois aspectos Ílnportantes:
1. O que o usuário final quer e do que ele precisa?
2. O que precisa mudar para que isso aconteça?
Com uma gestão adequada das expectativas do usuário fina l e de mudanças, po-
de-se evitar o risco de a saída do projeto se tornar "apenas 1nais um item da caixa de
ferramentas".
O sistema de gerenciamento de benefícios deve, resumida1nente, consistir nos se-
guintes elementos:
• Identificar o direcionador do projeto: Precisamos realmente desse investimento?
Quem mais irá se beneficiar dele?
• Identificar os benefícios essenciais: Quais são os benefícios e quando eles ocorre-
rão? Qual é sua proximidade (Qua l é a probabilidade de que aconteça?)
• Estimar os benefícios: Definir uma base clara para as 1nedidas perm ite-nos defi-
nir métr icas claras (que se aplicam a todo o portfólio de projetos) e oferece-nos
consistência em todas as fases do ciclo de vida, desde o início do projeto à concre-
tização dos benefícios. A pergunta crucial que te1nos que fazer é: Essas métr icas
toleram mudanças no a 1nbiente empresarial?
• Associar os benefícios à mudança: Como a organização precisa mudar para que
venha a possibilitar a concretização dos benefícios? Como podemos possibilitar
essa 1nudança? Planejar a implementação e ajustá-la às mudanças ambientais em-
presariais (mudanças organizacionais, mudanças na situação do mercado, etc.).
• Q uem é responsável p elo benefício? Definir uma pessoa/organização responsável
pela concretização dos benefícios.
• Monitorar os benefícios: Mon itorar seu desempenho com as métricas estabeleci-
das, apri1norando-as, se necessário, em direção à meta estabelecida e reconhecer
os riscos de maneira proativa.
• Fazer un1a avaliação pós-projeto: Garantir uma implementação be1n -sucedida
comun icando a saída do projeto e promovendo-a honestamente. Imagine-se na
posição do usuário final: você gostaria de usar esta ferramenta?
• Aprender com seus erros: Garantir que os pontos fortes e fracos do projeto seja,n
igua lmente t rabalhados. Concentrar-se na comunicação honesta e na aprendiza-
gem, e não na determinação de culpados. O nível executivo deve ser um exe1nplo
a ser seguido.
1.2 Melhores práticas em gestão de projetos:

1945-1960
Durante a década de 1940, os gerentes de área funcionavam como gerentes de projeto
e usavam o conceito de gerenciamento "por ci1na da cerca" (over-the-fence tnanage-
ment) para os projetos. Cada gerente de área, "vestindo a camiseta» de gerente de pro-
jeto, realizava o traba lho de sua área organ izacional e, quando o concluía, "passava
a bola por cima da cerca", na esperança de que a lguéin fosse pegá -la. Uma vez que a
bola tivesse sido jogada por cima da cerca, os gerentes de área "lavavam suas mãos"
de qualquer responsabi lidade, pois a bola não estava 1nais "em seu quintal". Se u1n
projeto falhasse, colocava-se a culpa em qualquer gerente de área que estivesse com a
"posse da bola" naquele momento.
O problen1a com o gerencian1ento "por cima da cerca" era que o cl iente não
tinha qualquer ponto de contato para fazer perguntas. A fi ltragem de info rn1ações
desperd içava un1 tempo precioso tanto para o cl iente quanto para a empresa con-
t ratada. Os clientes que qu isessem informações em primeira n1ão tinham de procu-
rar o gerente que estivesse de posse da bola. Para projetos pequenos, era fácil. Entre-
tanto, à medida que cresciam e ficavam mais complexos, a dificuldade aun1entava.
Nessa época, foram identificadas 1nuito poucas mel ho res práticas. Quando elas
existiam, permanecia tn dentro de determinada área funciona l e nunca eram compar-
tilhadas com o restante da etnpresa. Tomar decisões subótÍlnas na gestão de projetos
era a norma.
Depois da Segunda Guerra Mundial, os Estados Unidos entraratn na Guerra Fria.
Para vencer uma Guerra Fria, há que se competir na corrida armamentista e rapida-
mente constru ir armas de dest ruição em massa. O vitorioso nesses casos será aquele
que puder retaliar o in imigo com força suficiente para o bl iterá-lo. O desenvolvimento
de armas de destruição em massa cotnpreendia projetos muito grandes, que envolviam
potencialmente milhares de prestadores de serviços.
A corrida arman1entista deixou claro que o tradicional uso de gerenciamento
"por cima da cerca" não seria aceitável pa ra o Departan1ento de Defesa dos EUA
(DoD - Departn1ent of Defese) para projetos con10 o bombardeiro B-52, o n1íssil
balístico intercontinental Minuteman ou o submarino Polaris. O governo queria
un1 ponto de contato único, a saber, um gerente que tivesse responsabilidade total
por todas as fases do projeto. Além disso, o governo queria que o gerente de projeto
tivesse domínio tecnológico en1 vez de apenas um conhecimento superficia l, o que
obrigava o gerente de projeto a ser um engenheiro, de preferência con1 um diplon1a
avançado en1 algum ramo da tecnologia. O uso da gestão de projetos se tornou,
então, ob rigatório para a lguns dos s istemas n1enores de armas como os aviões de
caça ou tanques de guerra. A Administração Nacional da Aeronáutica e do Espaço
(NASA, Nationa l Aeronautics and Space Adn1inistr ation) detern1inou o uso da ges-
tão de projetos para todas as atividades relacionadas ao programa espacial.
Projetos nos setores aeroespacia l e de defesa estavam tendo sobrecustos acima
de 200 -300%. Culpava-se erronea tnente a implementação inadequada da gestão de
projetos quando, na verdade, o verdadeiro problema era a incapacidade de se fazerem
previsões em tecnologia, resu ltando na ocorrência de inúmeras oscilações no escopo.
Previsões tecnológicas são extretnamente difíceis para projetos que podem durar de
10 a 20 anos.
No fim da década de 1950 e no início da década de 1960, os setores aeroespacial e
de defesa nos EUA estavam usando gerenciamento em praticamente todos os projetos,
e estavam pressionando seus fornecedores a usá-lo também. A gestão de projetos es-
tava crescendo, mas a um ritmo relativa1nente lento, exceto pelos setores aeroespacial
e de defesa.
Devido ao vasto número de empresas contratadas e subcont ratadas, o governo
dos EUA precisava de padronização, especia lmente no processo de planejamento e na
d ivulgação de informações. O governo estabeleceu utn modelo de planejamento e con-
t role de ciclo de vida e um sistema de monitoramento de custos e criou um grupo de
auditores de gestão de projetos para ga rantir que seu dinheiro estivesse sendo gasto de
acordo com o planejado. Essas práticas tinham de ser usadas em todos os programas
governamentais que ultrapassassem certo va lor em dólares. O setor privado enxergava
essas práticas cotno um custo excessivo e não viam qualquer valor prático na gestão
de projetos.
Nos primeiros anos da gestão de projetos, como 1nu itas empresas não viam nela
qualquer va lor, havia muitos ma l-entend idos em relação à sua prática. Alguns deles
incluíatn :
• A gestão de projetos é uma ferramenta de determinação do progresso de proje-
tos co1no a técn ica de programa, ava liação e revisão/tnétodo do caminho crítico
(PERT/CPM, program evaluation and review techniqttelcritical-path method).
• A gestão de projetos se aplica sotnente a projetos de gr ande porte.
• A gestão de projetos é criada apenas para projetos governamentais.
• Os gerentes de projeto têm de ser engenheiros e, de preferência, ter d iplon1as
avançados.
• Os gerentes de projeto precisam de um " domínio de tecnologia" para terem êxi to.
• O sucesso do p rojeto é medido em termos exclusivamente técnicos. (Funcionou?)

1960-1985
Durante esse período, a gestão de projetos (já 1nais bem cotnpreendida) cresceu mais
por necessidade do que por vontade, mas a utn r itmo muito lento. Isso pode ser at ri-
buído principalmente à fa lta de aceitação das novas técnicas necessárias ao sucesso de
sua implementação. Um temor inerente diante do desconhecido agia cotno um impedi-
mento tanto para gerentes quanto para executivos.
Fo ra dos setores aeroespacial, de defesa e de constr ução, a maioria das empre-
sas na década de 1960 mantinha um método inforn1a l de gestão de p rojetos. Na
gestão informa l de projetos, como o non1e indica, os projetos e ram t ratados de
n1anei ra informal, e a autoridade do gerente do p rojeto era mín in1a. A maio ria dos
projetos era adn1 in ist rada por gerentes funcionais e permanecia en1 un1a ou duas
áreas funcionais, e comun icações formais eram ou desnecessárias, ou tratadas in-
forn1almente devido às boas relações profissiona is entre os gerentes de área. Esses
indivíduos aos qua is se atr ibuía a função de gerente de projeto logo descobriam
que estavam funcionando n1a is como líderes ou n1on itores de projeto do que como
gerentes. Hoje, muitas organ izações, como as de produção de baixa tecnologia, têm
gerentes de área que t rabalh an1 lado a lado há pelo n1enos dez anos. Nessas sit ua-
ções, a gestão informal de projetos pode ser eficiente en1 p rojetos de produção de
bens de capital ou de construção de instalações, e a gestão de projetos não é consi-
derada uma p rofissão.
Na década de 1970 e no início da década de 1980, mais empresas se afastara tn
da gestão informal de projetos e se reestr uturaram de ,nodo a formalizá-la, principal-
mente pelo fato de o tamanho e a complexidade de suas atividades teretn crescido a cal
ponto que se tomaram ingerenciáveis dentro da estr utura corrente.
Nen1 todos os setores precisan1 de gestão de projetos, e os executivos têtn de de-
tern1inar se há uma verdadeira necessidade antes de se compron1eteren1 con1 a prática.
Diversos setores con1 tarefas simples, seja em um ambiente estático ou dinâm ico, não
precisan1 de gestão de projetos. Indústrias manufacureiras con1 tecnologia con1 baixo
rit mo de mudanças não precisam dessa prática, a n1enos, é claro, que elas exijam di-
versos projetos especia is, como atividades de bens de capital, que possam interron1per
o fluxo normal de traba lho nas operações 1nanufacureiras rotineiras. O lento rit mo de
crescimento e a morosidade na aceitação da gestão de projetos estavan1 relacionados ao
fato de que as suas lin1itações eran1 muito aparentes, enquanto suas vantagens não eram
con1pletamente reconhecíveis. A gestão de projetos exige reestruturação organizacional.
A questão, é claro, é "Que grau de reestruturação?". Os executivos evitavan1 o assunto
por medo de que mudanças "revolucionárias" tivessem que ser feitas na organização.
A reestruturação da gestão de projetos permitiu que as empresas:
• real izassem tarefas que não podiam ser tratadas de forma eficiente pela estrutura
tradiciona l;
• rea lizassen1 atividades ún icas com uma interrupção mín ima dos negócios roei-
.
netros.
O segundo ite1n implica que a gestão de projetos é uma estrutura de gerencia-
mento " temporária" e, portanto, causa u1na perturbação organizacional mínima. Os
principais problemas identificados por esses gerentes que tentavam se adaptar ao novo
siste1na giravam, todos, em torno de recursos e de conflitos de autoridade.
Uma out ra grande preocupação era que a gestão de projetos exigia que os gerentes
de nível mais a lto renunciassem a pa rte de sua autoridade por meio da delegação de
tarefas a gerentes intermed iários. Em diversas situações, os gerentes intennediários
logo ocupavam as posições de poder, mais do que os gerentes de nível ma is alto.
A gestão de projetos se tornou u1na necessidade para muitas e1npresas à medida
e1n que elas se expandiam e1n múltiplas linhas de produto, das quais 1nuitas não eram
sim ilares, e que as complexidades organizacionais cresciam. Esse crescimento pode ser
at ribuído a:
• Avanços tecnológicos a ritmos impressionantes
• Maior investimento em pesquisa e desenvolvimento (P&D)
• Disponibilização de 1na is informações
• Diininuição dos ciclos de vida de projetos
Para satisfazer as exigências impostas por esses quatro fatores, a gerência foi" for-
çada" a u1na reest ruturação organizacional; a fonna organizacional t radicional que
sobrevivia há décadas era inadequada para integrar atividades at ravés de diferentes
"impérios" funcionais.
Por volta de 1970, o ambiente começou a mudar rapidamente. As empresas nos
setores aeroespacial, de defesa e de const rução foram pioneiras na implementação da
gestão de projetos, e outras indústrias logo as acompanharam, a lgutnas com grande
relutância. A NASA e o DoD "forçara1n" empresas subcontratadas a aceitarem ages-
tão de projetos.
Pelo fato de as estruturas organizacionais correntes não sere1n capazes de aco-
modar a ampla variedade de tarefas inter-relacionadas necessárias para a conclusão
bem-sucedida de projetos, a necessidade de seu gerenciamento tornou-se aparente.
Em geral, isso primeira1nente é identificado por gerentes de nível ma is baixo ou in-
tennediário, que acha1n impossível cont rolar seus recursos de forma eficiente para
as d iversas atividades dentro de sua área organ izaciona l. Mu itas vezes, os gerentes
intermed iários sentem mais o impacto de um ambiente em modificação do que os
executivos de nível mais a lto.
Uma vez que a necessidade de 1nudança tenha sido identificada, a gerência inter-
mediária tem de convencer a alta gerência de que ela realmente é importante. Se a alta
gerência não conseguir reconhecer os problemas com o cont role de recursos, então a
gestão de projetos não será adotada, pelo menos formalmente. A aceitação informal,
ent retanto, é outra história.
À medida que a gestão de projetos se desenvolveu, alguns fatores essenciais para
o sucesso da imple1nentação foram reconhecidos. O principal fator foi o papel do ge-
rente de projeto, que passou a ser o ponto foca l da responsabilidade integrativa, cuja
necessidade foi primeiramente identificada em complexos projetos de P&D. A tecno-
logia de P&D desfez os limi tes que existiam ent re os setores. Aqueles que já fora tn
mercados e canais de distribuição estáveis hoje se encontram em um estado de fluxo.
O ambiente industr ial é turbulento e e.ada vez mais difíci l de se prever. Muitos fatos
complexos sobre 1nercados, métodos de produção, custos e potenciais científicos estão
relacionados a decisões de investimento em P&D.
Todos esses valores se combinaram, produzindo uma "dor-de-cabeça gerencia l"
tamanho família. Simplesmente há decisões cruciais demais a serem totnadas para ser
possível que todas elas sejam processadas e resolvidas no alto da organização por 1neio
de uma hierarquia de linha comum. Elas têm de ser integradas de algu,na outra forma .
Confiar ao gerente de projeto a responsabi lidade dessa integração gerou os se-
guintes resultados:
• Responsabilidade total do projeto assumida por u1na ún ica pessoa
• Funcionários dedicados a projetos em vez de a funções
• Exigência única de coordenação ent re diferentes interfaces funcionais
• Utilização adequada de planejamento e contr ole integr ados
Sem a gestão de projetos, esses quatro elementos terian1 de ser rea lizados por exe-
cutivos, e é questionável se essas atividades deveriam ou não fazer parte da descriç.ão
de função de um executivo. Utn executivo de uma corporação da Fortune 500 declarou
que estava gastando 70 horas por sen1ana trabalhando tanto con10 executivo quan to
como gerente de projetos, e que sentia que não estava dando seu n1elhor en1 nenhum dos
dois trabal hos. Durante uma apresentação para a equ ipe de funcionários, o executivo
decla rou o que esperava da organização após a in1plen1entação da gestão de projetos:
• Transferir a tomada de decisões para níveis 1na is baixos da organizaç.ã o
• Eliminar a necessidade de comitês de soluções
• Confiar nas decisões de colegas de trabalho
Os executivos que decidiram acei tar a gestão de projetos logo descobriram as
vantagens da nova técn ica:
• Fáci l adaptação a um atnbiente em constantes mudanças
• Capacidade de lidar com u1na atividade multid isciplinar dentro de um período
especificado
• Fluxo de trabal ho horizontal, a lém de vertical
• Maior orientação aos problemas dos cl ientes
• Mais fácil identificação de responsabilidades nas atividades
• Utn processo multidisciplinar de totnada de decisões
• Inovação no design organ izacional
À medida que a gestão de projetos se desenvolveu, as melhores práticas se to rna-
ram itnportantes, sendo aprendidas tanto com sucessos quanto com fracassos. Nos
pri tnei ros anos da prática, o setor privado preferiu aprender melhores práticas cotn
os sucessos. O governo, no entanto, preferiu aprender melhores práticas com os insu -
cessos. Quando o governo finalmente optou por aprender com os sucessos, o conheci-
mento das melhores práticas passou a vir de seus relacionamentos com empresas con-
tratadas e subcontratadas. Algumas dessas melhores práticas que foram provenientes
do governo incluíam:
• O uso de fases de ciclo de vida
• Padronização e consistência
• Uso de templates (p . ex.: para a especificação do trabalho [SO\V, statement of

work], estrutura analítica do projeto [WBS, work breakdown struct11re] e gestão
de riscos)
• Uso de pessoal m ilitar e1n cargos de gestão de p ro jetos com m issões prolongadas
no mesmo loca l
• Uso de equipes integradas de projeto (lPTs, integrated project teams)
• Controle de oscilações no escopo geradas pelas empresas contratadas
• Uso de 1nedidas de valor agregado

1985-2014
Na década de 1990, as empresas tinham começado a perceber que a i1nplementação
da gestão de projetos era uma necessidade, e não uma opção. Em 2014, já tinha se
espalhado para praticamente todos os setores, e mel ho res práticas já estavam sendo
aprendidas. Em nossa opinião, o surgimento de melhores práticas a partir da perspec-
tiva de setores pode ser:
• 1960- 1985: Aeroespacial, de defesa e de const rução
• 1986- 1993: Fornecedores do setor automotivo
• 1994-1999: Telecomun icações
• 2000-2003: Tecnologia de informação
• 2004-2006: Assistência médica
• 2007- 2008: Ma rketing e vendas
• 2009- Presente: agências governamentais
A questão agora não é como implementar a gestão de projetos, mas com que ra-
p idez ela pode ser implementada. Com que rapidez podemos amadurecer na gestão de
p ro jetos? Podemos usar as melhores práticas para acelerar sua imple1nentação?
A Ta bela 1- 1 mostra as típicas fases de ciclo de vida pelas qua is passa uma orga-
nização ao implementar a gestão de projetos. Na priineira fase, a fase em br ionária, a
o rganização reconhece a aparente necessidade de implementá-la. Esse reconhecimento
normalmente ocorre nos níveis mais baixos e intermediários da gerência, em que as
atividades de projetos geralmente são rea lizadas. Os executivos são, então, informados
sobre a necessidade e aval iam a situação.
Há seis fo rças motrizes que levam os executivos a recon hecer a necessidade da
gestão de projetos:
• Projetos de capital
• Expectativas do cl iente
• Competitividade
• Compreensão por parte dos executivos
• Desenvolvimento de novos projetos
• Eficiência e eficácia
As e1npresas manufatureiras são at raídas pela gestão de projetos devido aos gran-
des projetos de capital de uma 1nu ltiplicidade de projetos simultâneos. Os executivos
logo percebem o impacto sobre o fluxo de caixa e que deslizes no cronogra1na pode
aca bar deixando funcionários ociosos.
As empresas que vendem produtos ou serviços, incluindo a instalação, precisam
ter 1nelhores práticas de gestão de projetos. Essas empresas normalmente não são
TABELA 1-1 Cinco fases do ciclo de vida da gestão de projetos
Aceitação pela Aceitação pela

Embrionária gerência executiva gerência de área Crescimento Maturidade
Reeonheeer a Obter apoio visível Obter apoio da gerên- Reeonhecer o uso de Desenvolver um
neeessidade dos executivos eia de área fases de ciclo de vida sistema de controle
gerencial de custos e
prazos
Reeonheeer os Fazer com que os Fazer com que a Desenvolver uma me- Integrar controle de
beneficies exeeutivos compre- gerência de área se todologia de gestão custos e prazos
endam a gestão de comprometa com a de projetos
projetos gestão de projetos
Reeonheeera Estabelecer patroci- Proporcionar conhe- Obter comprometi- Desenvolver um pro-

aplicabilidade nadores dos projetos cimento aos gerentes mente com o que for grama de ensino para
no nível executivo de área planejado melhorar as compe-
tências em gestão de
projetos
Reeonheeer o Estar disposto a Estar disposto a libe- Minimizar oscilações
que precisa ser mudar a maneira de rar funcionários para de escopos / deli-
leito conduzir o empreen- treinamentos em ges- nir um sistema de
dimento tão de projetos acompanhamento de
projetos
orientadas a projetos, mas funciona tn como se o fossem. Elas hoje vendem soluções
aos seus clientes em vez de produtos. É quase impossível vender soluções completas
aos clientes sem ter práticas superiores de gestão de projetos, porque o que você está
vendendo é, na verdade, sua experiência em gestão de projetos.
Há duas situações em que a competitividade se torna a força mot riz: projetos
internos e projetos externos (cliente externo). Internamente, as empresas encontram
dificu ldades quando percebem que grande parte do traba lho pode ser terceirizado
por menos do que custaria real izá-lo dentr o da empresa. Externamente, as empresas
encont ram dificuldade quando não são 1na is competitivas em preço ou qualidade ou
simplesmente não conseguem aumentar sua participação de mercado.
A compreensão por parte dos executivos é a força 1not riz naquelas organizações
que possuem u1na estr utura rígida e tradiciona l e que realizam atividades rotineiras e
repetitivas. Essas organizações são bastante resistentes a mudanças, a 1nenos que estas
sejam determinadas pelos executivos. Essa força motr iz pode existir em conjunção
com qualquer out ra das forças 1not rizes.
O desenvolvimento de novos produtos é a força motriz daquelas organizações que
investem fortemente em atividades de P&D. Dado que apenas um pequeno percentual
dos projetos de P&D chega a ser comercia lizado de modo que seus custos possam ser
recuperados, a gestão de projetos se torna uma necessidade. Ela pode ser usada como
um sistema de aviso precoce de que um projeto deve ser cancelado.
A eficiência e a eficácia, como forças motrizes, podem existir em conjunção cotn
qua isquer outras forças motrizes. Elas assu1nem suma importância para pequenas em-
presas que estão passando por dificuldades inicia is devido ao crescimento. A gestão de
projetos pode ser usada para ajudá-las a pennanecer competitivas durante períodos de
crescimento e para auxiliá-las a determinar restrições de capacidade.
Devido à inter-relação dessas forças, algu1nas pessoas argumentam que a única
verdadeira força motr iz é a sobrevivência. Isso é ilustrado na Figura 1- 1. Quando a
1O Gestão de projetos
e1npresa reconhece que a sobrevivência da empresa está em jogo, a implementação da

gestão de projetos torna-se mais fáci l.
Eficiência e eficácia Projetos

de capftal
Desenvolvimento de _ _ __ Expectativas
novos produtos dos clientes
Compreensão por
parte dos executivos
Figura 1- 1 O s componentes da sobrevivência. Fonte: Reimpresso de H. Kerzner, ln Search
of Excel/ence in Project Management, Hoboken, NJ: Wiley, 1998, p. 51.
Enrique Sevilla Molina, profissional da área, antigo di retor corporativo do PMO,

d iscute as forças motrizes em ação na Indra, que necessitava atingi r a excelência:
As forças internas se baseavam em nossa própria história e experiência empresa rial. Logo
descobrimos que, quanto melhores fossem os gerentes de um projeto, melhores seriam seus
resultados. Essa percepção veio com a necessidade de demonstrar em contratos nacionais e
internacionais, com cl ientes norte-americanos e eu ropeus, nossa verdadeira capacidade de
lidar com projetos de grande porte. Tais projetos exigiam um gerenciamento de excelência
e, para aqueles de nós que gerenciávamos o projeto, tratava-se de um desafio ma io r do que
simplesmente ser capaz de executá-lo tecnicamente. Em resumo, esses projetos determina-
ram o ritmo de definição de proced imentos precisos sobre como lidar com as partes interes-
sadas, com grandes empresas s ubcontratadas e sobre como se tornar um ponto de contato
principal confiável em todas as q uestões relacionadas ao projeto.
Sandra Kumorowski discute as forças mot rizes em aç.â o na Enakta:2
Eficácia e Organizações não Organizações

eficiência baseadas em projetos baseadas em
interna
hí/ ~
eorg~~~!~/
Competitividade ,b;;;;;;;;;;;;;;;:::==============!
Rápida Lenta
Velocidade da maturidade
Figura 1- 2 Velocidade da matu ridade.
i Sandra Kumorowski é professora assistente de comunicação e marketing no Columbia College, Chicago;

cátedra de marketing e comunicação, Christopher & Dana Reeve Foundarion, Chicago; é também principal
consultora empresarial e proprietária da Enakra LLC; P: 1- 224-715-5666; e-mail: sandrakum@sbcglobal.net
e skumorowskj@colum.edu.
TABELA 1-2 A necessidade da gestão de projetos

Por quê? Benefícios
Somos uma empresa 1. Sabemos como realizar projetos 2. Gestão de projetos é uma
baseada em projetos ferramenta para a realização
de ideias acionáveis de forma
bem-sucedida
Para ganhar credlbllldade, 1. Reputação 2. Estratégia de ne- 3. Gestão de projetos poderia
crescer e competir: Deve- merecida por gócios focada ser uma de nossas vantagens
mos ser percebidos como trabalho siste- competitivas
uma organização sistemática mático
e organizada. Temos de evi-
tar erros.
Para controlar custos, 1. Menor incerteza 2. Maior qualidade 3. Pessoas 4. Planejamento
tempo, recursos: Devemos dos produtos felizes mais eficiente
estabelecer um sistema (no nível do
eficiente de controle de projeto e da
projetos. empresa)
Para aprender como 1. Conceitos de 2. Uma organização
uma organização e como gestão de proje- voltada para a
indivlduos tos como parte aprendizagem está
de nossa edu- sempre à frente
cação contínua de seu tempo e de
seus concorrentes
Tratava -se de uma empresa baseada em projetos e fazia sentido recorrer à gestão de projetos
como uma ferramenta de melhoria contínua. As principais questões que também levaram
a empresa a usá-la eram questões gerencia is recorrentes relati,•as a tempo/custo/qualidade,
questões de produtividade de equipes e questões de satisfação do cliente.
A Tabela 1-2 ilust ra essa necessidade.
A velocidade com que as empresas alcançam certo grau de maturidade em gestão
de projetos gera lmente se baseia no grau de importância que elas atribuem às forças
motrizes. Isso é ilustrado de maneira genérica na Figura 1- 2. Organizações que não
são orientadas a projetos e organizações híbridas amadurecem rapidamente se u1n
aumento da eficiência e da eficácia for necessário internamente. A competitividade é
o cam inho mais lento, pois esse tipo de organização não reconhece que a gestão de
projetos afete sua posição competitiva diretamente. Para organizações orientadas a
projetos, o caminho é inverso. Competitividade é o nome do jogo, e o veículo usado
para vencê-lo é a gestão de projetos.
U1na vez que a organização perceba a necessidade de implementá-la, ela entra na
segunda fase do ciclo de vida da Tabela 1-1, a aceitação pela gerência executiva. Ages-
tão de projetos não pode ser implementada a curto prazo sem apoio executivo. Alé1n
do mais, esse apoio tem que ser visível a todos.
A fase do terceiro ciclo de vida é a aceitação pela gerência de área. É improvável
que qua lquer gerente de área apoie ativamente a sua implementação sem primeiro
reconhecer o 1nesmo suporte vindo de camadas hierárquicas superiores. Mesmo um
mín imo apoio pela gerência de área t raria problemas para a gestão de projetos se1n
. .
apoio executivo.
A qua rta fase do ciclo de vida é a fase de crescimento, na qua l a organização se
compromete com o desenvolvitnento das ferramentas corporativas para a gestão de
projetos. Isso inclui os processos e a metodologia de gestão para o planejamento, a
p rogramação e o controle, a lém da seleção de utn software de suporte apropria do .

Pa rtes dessa fase podem cotneça r durante fases anteriores.
A quinta fase do ciclo de vida é a maturidade. Nessa fase, a organização começa
a usa r as ferra tnentas desenvolvidas na fase anterior e precisa estar totalmente dedi-
cada à gestão de projetos. Ela tem que desenvolver um cu rrícu lo razoável de gestão
de projetos para oferecer o treinamento e a educação apropriados como suporte às
ferramentas e ao co1nporta 1nento organ izacional esperado.
Na década de 1990, as empresas fina lmente já tinham começado a reconhecer os
benefícios da gestão de projetos. A Tabela 1- 3 mostra os fatores críticos que contri-
buetn com o sucesso e que levam ao fracasso etn nossa visão de gestão de projetos.
Muitos desses fatores foram identificados por meio da descoberta e da imple1nentação
de melhores práticas.
Reconhecer que a organização pode se beneficiar com a imple1nentação da gestão
de projetos é apenas o ponto de pa rtida. A questão, então, passa a ser: "Quanto tem-
po levaremos pa ra alcançar esses benefícios?". Essa pergunta pode ser parciahnente
respondida com base na Figura 1- 3. No início do processo de imple1nentação, haverá
despesas extras para desenvolver a metodologia da gestão de projetos e estabelecer os
sistetnas de suporte para planejamento, cronograma e controle. Finalmente, os custos
irão se esta biliza r e se tornar fixos. O ponto de interrogação na Figu ra 1- 3 é o ponto
etn que os benefícios se igua lam ao custo de implementação. Esse ponto pode ser em-
purrado para a esquerda por meio de t reinamento e educaç.ã o.
TABELA 1-3 Fatores críticos no ciclo de vida da gestão de projetos
Fatores críticos de sucesso Fatores críticos de fracasso

Fase de aceitação pela gerência executiva
Considerar as recomendações de funcionários Recusar-se a considerar as ideias de colegas
Reconhecer que mudanças são necessárias Não estar disposto a admitir que mudanças podem ser
necessârias
Compreender o papel dos executivos na gestão de Acreditar que o controle da gestão de projetos cabe
projetos aos níveis executivos
Fase de aceitação pela gerência de área
Estar disposto a colocar os interesses da empresa aci- Relutar em compartilhar informações
ma dos interesses pessoais
Estar disposto a aceitar responsabilidades Recusar-se a aceitar responsabilidades
Estar disposto a aceitar o progresso de colegas Mostrar-se insatisfeito com o progresso de colegas
Fase de crescimento
Reconhecer a necessidade de uma metodologia que Perceber a metodologia-padrão como uma ameaça,
abranja toda a empresa não como um benefício
Apoiar a padronização do monitoramento dos relató- Não conseguir compreender os benefícios da gestão
rios de projetos
Reconhecer a importância de um planejamento efi- Dar apenas "apoio morar ao planejamento, sem se
ciente importar em concretizar o que foi planejado
Fase de maturidade
Reconhecer que custos e cronograma são inseperá- Acreditar que o estado do projeto possa ser determina-
veis do apenas pelo cronograma
Acompanhar os custos reais Não perceber a necessidade de acompanhar os custos
reajs
Desenvolver treinamento em gestão de projetos Acreditar que, na gestão de projetos, crescimento e
sucesso são sinônimos
Custos de gerenciamento
\'"
- - - - -~ lucros extras
devido à melhor
gestão do projeto
l
$
\ Fixo
? Tempo - -.
Figura 1- 3 Custos versus benefícios da gestão de projetos.
Durante a primeira década do século XXI, a compreensão e a aceitação dos be-

nefícios permeavam todos os níveis da gerência sênior em vez de apenas os executivos
que tinham contato diário co1n projetos. Os três comentários a seguir da gerência
sênior da American Greetings Corporation ilustra 1n essa questão:
Por meio da gestão de projetos, aprendemos a tomar decisões baseadas em fatos. No pas-
sado, costumávamos basear nossas decisões naquilo que achávamos que poderia acontecer
ou que esperávamos que fosse acontecec Agora podemos observar os fatos, interpretá-los
de maneira honesta e tomar decisões sólidas e estabelecer metas realistas com base nessas
informações. (Zev \'(leiss, CEO, American Greetings.)3
O PMO oferece a estrutura e a disciplina para concluir o trabalho que precisa ser
real izado. Desde o lançamento até sua finalização, cada projeto conta com um " roteiro"
para que se alcancem os objetivos estabelecidos. Ueff \Veiss, presidente e COO, American
Greetings.)'
Por meio da gestão de projetos, aprendemos o valor de definir projetos específicos e de
delegá-los a eq uipes. Abraçamos a filosofia da gestão de projetos e agora podemos usá-la
repetidas vezes para atingir nossas metas. (Jim Spira, presidente aposentado e COO, Ame-
rican Greetings.)'
Quando todos os executivos estão de acordo quanto ao valor e aos benefícios,
ocorrem melhorias contínuas em u1n ritmo acelerado.
1.5 A gestão de projetos vista por um executivo

Atua lmente, os executivos compreendem e estimam muito mais a gestão de projetos
do que seus antecessores. Antes, ela era utilizada apenas para detenninar o cronogra-
ma de um projeto e, então, gerenciá-lo com um software disponível na rede. Hoje, essa
visão restrita 1nudou sign ificativamente, e a gestão de projetos é reconhecida como
uma necessidade para a sobrevivência.
Embora haja diversos detenninantes para isso, três motivos significativos pare-
cem se destacar. Primeiro, quando as empresas fazem downsize devido a más condi-
J H. Kerz.ner, Advanced Project Management: Be$t Practices on lmplementation, Hoboken, NJ: \-Viley, 2004,
p. 273.
• lbid.
' lbid.
ções econõm icas ou à intensificação da concorrência, espera-se que os funcioná rios

que permanece1n na empresa façam mais co1n 1nenos. Os executivos esperam que os
funcionários realizem suas ta refas de fo rma mais eficaz ou ma is eficiente. Segundo,
o crescimento dos negócios hoje exige a aceitação de riscos significativos, especifica-
mente no desenvolvimento de novos produtos e serviços para os qua is pode não haver
técnicas ou padrões de esti1nativas razoáveis. Dito de forma simples, estamos empre-
endendo mais tra balhos que não são nem rotineiros, nem previsíveis. Terceiro, e talvez
mais importante, é o fato de acreditarmos estar gerenciando nossos negócios como se
eles fossem uma série de projetos. Os projetos hoje compreende1n u1na parte significa-
tiva dos trabalhos real izados por um funcionário. Assim, todos os funcionários são, na
verdade, gerentes de projetos até certo ponto, e espera-se que eles tome1n decisões de
negócios, a lém de decisões de projetos.
Esse novo tipo de executivo parece ter uma visão muito mais ampla do valor da
gestão de projetos, indo desde seus benefícios até os critérios de recruta 1nento e sele-
ção de gerentes de projetos e est ruturas o rganizacionais que podem toma r as empresas
mais eficientes. Esse fato fica be1n claro nos quatro comentários abaixo, que foram fei-
tos por Tom Lucas, diretor executivo de informação da Sherwin-\Villiams Company:
• Todos já gerenciamos projetos em a lgum 1no 1nento na vida, mas poucos somos
capazes de ser gerentes de projetos.
• A diferença ent re gerenciar projetos e a gestão de projetos profissional é como a
diferença ent re cruza r um lago em um caiaque ou em uma lancha. Am bos o leva-
rão até o outro lado do lago, mas ir de ca iaque é um processo longo e doloroso.
Co1no as pessoas poderão saber a d iferença se você nunca lhes der uma carona
em sua lancha?
• Não seja levado a pensar erronea1nente que a gestão de projetos profissiona l se
trata de processos. Trata-se de produzir resultados de negócios.
• Se você não perceber que implementar um PMO é uma tr ansiç.â o cu ltural, estará
destinado ao fracasso.
Os comentários abaixo, feitos por out ros executivos, indicam claramente o quan-
to compreende1n e estimam a gestão de projetos:
Nossos clientes, que são grupos industriais multinacionais, esperam da COMAU Project
Managers uma abordagem internacional, multicultural e global. Nesse meio tempo, nossos
acionistas estão nos exigindo uma alta governança de projetos obtida por meio de uma
estrutura eficiente de gestão de projetos global. Em 2006, adotamos uma abordagem de ges-
tão de projetos (i .e., PMI, Project Manageme11t /11stitute) de a ltíssima q ua lidade que, com a
implementação das melhores práticas para a abordagem global da COMAU, permitiram-
-nos demonstrar q ue tanto as metas dos clientes quanto as dos acionistas podem ser cum-
pridas. Tenho certeza de que estamos no caminho certo e de que essa melhoria contínua tem
de ser perseguida nos próximos anos com motivação e perseverança. (Riccardo Tarantini,
CEO da CO!v!AU, Grupo Fiat)
Na Deli, temos o comprometimento de produzir soluções tecnológicas que ajudem nos-
sos clientes a alcançar mais. Um elemento essencial de nossa capacidade para realizar isso
é a combinação de padrões de melhores práticas com a flexibilidade em soluções de TI de
próxima geração, o que possibilita bons resultados empresariais de nossos clientes. Nos-
sas melhores práticas exigem uma gestão de projetos padronizada em todas as soluções
multiserviço integradas de um extremo a outro da empresa (e,ui-to-end) a fim de oferecer
uma execução bem-sucedida aos nossos clientes. Um foco cada vez maior na adoção de no-
vas práticas, juntamente com nosso pessoal, processos e ferramentas de gestão de projetos,
ajuda-nos a melhorar a consistência da execução de projetos em toda a Deli. Uma gestão de
projetos eficiente é crucia l para que se produzam resultados previsíveis, reprodutíveis e de
alta qualidade para nossos clientes. (Suresh Vaswani, presidente, Deli Services)
Ao longo dos últimos 15 a nos, uma transformação contínua se tornou a principal ca-
racterística da IBM - e um fator essencia l de nosso sucesso. Mudanças eficientes e trans-
formação de TI contínuas não são coisas que simplesmente acontecem; elas têm de ser pos-
sibilitadas por gerentes de projeto extremamente habilidosos. Nossos gerentes de projetos
ana lisam processos, habilitados pela TI, de uma forma que nos permite inovar e eliminar
passos desnecessários, simplificar e a utomatizar. Eles nos ajudam a nos tornarmos mais
eficazes e eficientes reunindo os recursos certos para co locar as co isas em prática - dentro
do prazo e do o rçamento previstos. Eles são inestimáveis para que continuemos a progredir
em nossa jorna da de transformação. (Linda S. Sanford, vice-presidente sênior, Enterprise
Transformation, IBM Corporation)'
Os gerentes de projetos são um elemento c rucia l de nosso modelo e11d-to-e11d de de-
senvolvimento e execução de negócios. Nosso objetivo é ter sólidas práticas de gestão de
projetos implementadas de modo a garantir ma io r previsibilidade em s uporte aos nossos
produtos e ofertas. Como equipe, eles nos ajudam a enxergar desafios a ntes q ue eles se
tornem problemas críticos e a garantir que cumpramos nossos co mpro missos com a STG
e os clientes ... Continua mos nosso foco em gestão de projetos co mo um rumo de carreira
para funcioná rios de grande potencial e incentivamos fortemente nossos gerentes de projeto
a obterem certificações, não somente do PMI, mas também da IBM... A gestão de projetos
e11d-to-e11d tem que se enra izar na malha de nosso negócio. (Rod Ad kins, vice-presidente
sênior d o G rupo de Sistemas e Tecnologia [STG] da IBN1)7
Em prestadores líderes de serviços de software de TI, a gestão de projetos evoluiu e ama-
dureceu de um processo complexo para identifica r e atender às exigências exclusivas dos
cl ientes à aplicação de um conjunto central de melho res práticas comprovadas e de segunda
geração que foram captadas e são a presentadas ao cliente como paco tes-pad rão. Eles ge-
ram um sucesso reprodutível e retornos ma is rápidos para o cliente. Eles também oferecem
ao cliente e ao gestor do projeto a capacidade de a dota r uma abordagem em etapas para
desenvolver no cl iente uma visão abrangente de gerenciamento de TI. (Dave Yusuf, vice-
-presidente sênior e PMO global, Computer Associates Services)
O sucesso da gestão de projetos é crucial pa ra nós por dois motivos:
• Primeiro, ao definirmos e implementarmos soluções de PLM (producl lifecyde 111a11age-
me11t, gerenciamento do ciclo d e vida d o produto), ajudamos os clientes a simplificarem
todo o seu ciclo de vida de produtos em todas as suas unidades funciona is. Isso pode
to rna r q ualquer grande projeto de PLM um empreend imento intricado e a té mesmo
complexo. Para fazer jus ao ma ntra de nossa e mpresa de q ue "nunca deixamos um
cliente fracassar", uma gestão de projetos robusta e confiável geralmente é o compo-
nente mais im porta nte que fornecemos, a lém da plataforma de PLM propria mente dita;
a co mbinação dos dois permite que nossos clientes alcancem os benefícios co merciais
pelos quais estão se empenhando ao investir na PLM.
• Segundo, a própria Siemens é um de nossos ma iores clientes. Essa é uma g rande opor-
tunidade e, ao mesmo tempo, um grande desafio. Manter os objetivos e o escopo de um
projeto sob co ntrole com nosso cliente " interno" é tão desafiador q ua nto com nossos
clientes externos; ainda assim, é essencia l que mantenha mos linhas de desenvolvimento
e nossos progra mas de implementação no caminho certo. Nossa tarefa é continuar a
desenvolver e implementa r com sucesso a primeira e única plataforma e11d-to-e11d de
software industrial. Essa plataforma a brangente cobre todo o ciclo de vida do produ-
to, desde o seu desenvolvimento até manu fatura, planejamento, controle do chão da
fábrica e inclusive gerenciamento da manutenção, co nsertos e revisão do produto em
q uestão. Consequentemente, a gestão de projetos eficiente é vital para o nosso sucesso.
(Dr. Helmuth Ludwig, presidente, Siemens PLM Software)
6
Harold Ken.ner, Project Management Best Practices: Achieving Global Exce/lence, 2nd edirion, John \Viley
and IIL Co-publishers, 2010, p. 13.
7
lbid; p. 13.
A gestão de projetos é vital para o sucesso de qualquer organização. Independentemente

de os projetos estarem focados na aquisição de clientes, em fidelidade e intuição o u de serem
impulsionados pela necessidade de a umentar a eficiência da empresa, a excelência na gestão
de projetos garante q ue se alcancem resultados tangíveis e significativos dentro do prazo e
do orçamento previstos. (Brad Jackson, CEO, Sla lom Consulting)
Os projetos e a gestão de projetos desempenham um papel vital em nossa empresa de
Serviços de TI. Além de viabilizarem o encantamento dos clientes, também ajudam a deter-
minar as expectativas certas das partes interessadas e, ainda mais importante, a manter um
equilíbrio entre suas expectativas. Uma gestão de projetos eficiente é uma forte vantagem
competitiva o u diferencial das nossas capacidades de realização. A excelência nos permitiu
não somente a umentar a qualidade de nossos serviços, reduzir nosso tempo para colocação
no mercado, dimin uir os custos de retrabalho e aumentar a motivação da equi pe de funcio-
nários, mas também criar uma organização mais integrada e ágil. (A. S. Murthy, antigo CEO
e CTO [diretor de tecnologia], Te.e h Nlah indra Ltd)
O fundamento de nossa marca como uma empresa de soluções é a qualidade e a
consistência de nossos gerentes de projetos, nossas abordagens e metodologias de gestão.
Ao mesmo tempo, é importante compreender q ue não existe uma solução única, já que
cada projeto possui suas próprias exigências, desafios e personalidade. Uma gestão de
projetos de alta qua li dade vai a lém do básico, priorizando traba lhar lado a lado com o
cl iente para tecer um conjunto de sol uções q ue atenda às s uas necessidades e o coloque
no caminho de alcançar seus objetivos. (Kimberly Parrish, vice-pres idente executiva de
soluções, maxIT-VCS)
Nesta era da comunicação instantânea e de redes em rápida evolução, a Norte! contin ua
a maximizar o uso de s ua disciplina de gestão de projetos para garantir o sucesso da imple-
mentação de projetos cada vez ma is complexos. Cultivamos um ambiente em q ue o foco
seja compartilhar as melhores práticas e tirar proveito das lições aprendidas em toda a or-
ganização, em grande parte lideradas por nossos gerentes de projetos. Estamos também nos
esforçando para integrar a inda mais as capacidades de gestão de projetos à gestão da cadeia
de suprimentos por meio da introd ução do software de gerencia mento empresarial SAP. A
gestão de projetos continua sendo uma parte integral dos negócios e da estratégia da Norte)
à medida que a empresa avança em um ambiente mais orientado a serviços e soluções. (Sue
Sprad ley, antiga presidente de operações globais, Norte) Networks)8
O processo do PMO foi essenc ia l para o s ucesso de grandes e importantes projetos
de sistemas de informações (SI) no centro médico Our Lady of Lourdes Regional Medica l
Center. Isso ocorreu espe.cialmente em nossa re.cente conversão do s uporte ao SI MedCath
para o s uporte ao SI Franciscan Missionaries of our Lady Hea lth System (FMOLHS) em
nosso ma is novo joint ve11t11re de médicos: o Heart Hospita l of Lafayette. O PMO construiu
uma relação de confiança por meio de transparência, res ponsabilidade e uma estrutura para
ava liação de projetos em tempo real. Sem essa estrutura, duvido seriamente que teria tido
êxito na realização da conversão dentro do prazo e do orçamento estipulados. (W. F. "Bud"
Barrow, presidente e CEO, Our Lady of Lo urdes Regional Nledical Center)
No setor de serviços, o modo como executamos um projeto (a metodologia da gestão de
projetos) é tão importante q uanto o que executa mos (o resultado a ser entregue ao cliente,
o u deliverable). Os clientes esperam maximizar seus retornos sobre investimentos em TI a
partir de todo o nosso conhecimento e a experiência quando lhes oferecemos soluções de
ponta. Todo o conhe.cimento e a experiência da HP Serv ices (Hewlett-Packard) são ma is
facilmente acessíveis por meio do Método Globa l HP. Esse conjunto de metodologias in-
tegradas é um primeiro passo para possibilitar q ue a HP o tim ize a eficiência em prod uzir
valor aos clientes. O passo seguinte é saber o que está d isponível e aprender como e q uando
aplicá-lo ao executa r um projeto para os clientes. O Método Global HP é o primeiro passo
rumo a um conj unto de metodologias de ponta para a umentar a cred ibilidade como um
parceiro confiável. Isso melhora também nossas estruturas de custo, personalizando abor-
ilH. Kerzner, Besr Practices in Project Ma11agement: Achieving Global Exce/Jence, Hoboken, NJ: Wiley,
2006, p. 17.
dagens predefinidas já testadas, usando listas de conferência preexistentes para garantir a

abrangência de todas as bases, compartilhando experiências e aprendendo a aprimorar o
lvlétodo Global. (Mike Rigodanzo, antigo vice-presidente sênior de operações de serviços e
9
tecnologia de informação da HP)
Em 1996, começamos a analisar nossos negócios do ponto de vista de seus processos
essenciais ... Como seria de se esperar, a gestão de projetos ganhou fama como um dos pro-
cessos vitais e centrais aos quais precisavam se aplicar os princípios de q ualidade. (Martin
O'Sullivan, vice-presidente aposentado, Motorola)'º
As disciplinas de gestão de projetos constituem um fundamento essencial para todas
as iniciativas que visam ao avanço empresarial o u mes mo humano. Não consigo imaginar
cruzar o abismo entre visão empresarial e realidade sem elas. (Keith Thomas, presidente do
conselho de administração, [TC [Information Technology & Communicationsj Business
Unit, Neal & lvlassy Holdings, Ltd)
Os coment ários de Keit h Thomas indicam claramente que os executivos de hoje
reconhecem o fato da gestão de projetos ser uma co1npetência estratégica ou cent ral
para a sobrevivência, pois está interl igada a talvez todos os outros processos de negó-
cios, inclusive a iniciativas de qualidade.
1.6 Processo de melhores práticas

"Por que identificar as melhores práticas?" Os motivos e objetivos para ident ificar as
melhores prát icas podem incluir:
• Melhorias cont ínuas (eficácia, precisão de est imat ivas, redução de desperdícios,
etc.)
• Melhor reputação
• Ganho de novos negócios
• Sobrevivência da empresa
A sobrevivência da empresa hoje se tornou o mot ivo mais importante para iden-
t ificar as melhores práticas. Nos últimos anos, os cl ientes pressionara1n empresas
cont ratadas e1n pedidos de apresentação de propostas (RFPs, requests for proposals),
solicitando:
• uma listagem do nú1nero de PMPs® (Project Manage1nent Professionals) na em-
presa e quantos serão designados ao projet o;
• uma demonstração de que a empresa possui uma met odologia empresaria l de ges-
tão de projetos que seja aceitável para o cliente, caso contrário, a contratada terá
de usar outra metodologia aprovada pelo cliente;
• docun1entação de suporte, identificando o nível de n1aturidade da contratada
em gestão de projetos, possivelment e usando um n1odelo de n1at uridade para
avaliações;
• disposição para compartilhar lições aprend idas e 1nelhores práticas descobertas
nesse projeto e ta lvez em projet os anteriores, realizados para outros clientes.
Reconhecer a necessidade de ident ificar as melhores práticas é mu ito mais fácil do
que rea lmente identificá-las. As e1npresas estão desenvolvendo processos para identifi-
car, avaliar, armazenar e disse1n inar informações sobre as melhores práticas. Há nove
• lbid ., p . 67.
'º Ibid., p. 184.
Gerenciamento
Classificação Revalidação
Publicação
Utilização
Figura 1-4 Processos que envolvem as melhores práticas.
atividades de mel hores práticas, como mostra a Figura 1-4, e a ma ioria das empresas
que reconhece o va lor da identificação das melhores práticas segue todos esses passos.
Os processos respondem as nove perguntas a seguir:
• Qual é a definição de uma 1nelhor prática?
• Quem é responsável por identificar a 1nelhor prática, e onde a procuramos?
• Como validamos que algo seja u1na melhor prática?
• Há níveis ou categorias de 1nelhores práticas?
• Quem é responsável pela administ ração da 1nelhor prática, uma vez que ela tenha
sido aprovada?
• Com que frequência reavaliamos se algo continua sendo uma mel hor prática?
• Como as empresas usam as 1nelhores práticas, uma vez que elas tenha1n sido va-
lidadas?
• Co1no as grandes e1npresas se certificam de que todos sa ibam da existência das
mel hores práticas?
• Como nos certificamos de que os funcionários esteja1n usando as 1nelhores práti-
cas, e de forma adequada?
Cada uma dessas perguntas será abordada nas seções a seguir.
1.7 Passo 1: definição de uma melhor prática

Há mais de uma década, as empresas são fascinadas pela expressão "mel hores práti-
cas". Agora, no entanto, depois de duas décadas ou ma is de uso, esta1nos começando
a esmiuçar o termo, e talvez haja expressões ma is adequadas.
Uma melhor prática começa com uma ideia de que existe uma técnica, um processo,
u1n método ou uma atividade que pode ser ma is eficiente em produzir um resultado
do que qualquer outra abordagem e que nos fornece o resultado desejado com menos
problemas e imprevistos. Por consequência, acaba1nos, supostamente, com a maneira
ma is eficaz e eficiente de realizar uma tarefa baseada em um processo reprodutível que
foi comprovado ao longo do tempo por um grande número de pessoas e/ou projetos.
No entanto, uma vez que se comprova que essa ideia seja eficiente, normalmente
integramos a n1elhor prática aos nossos p rocessos, de n1odo que ela passe a ser uma
n1aneira-padrão de agir. Portanto, após a aceitação e o uso con1provado da ideia, a
n1el ho r expressão possiveln1ente seria uma "prática comprovada" em vez de un1a
"n1elhor prática". Esse é apenas um argumento q ue defende que o termo "n1elho-
res práticas" talvez seja apenas um n1odisn10 e deveria ser substituído por "práticas
comprovadas".
Um outro argumento é que a identificação de uma melhor prática pode levar
alguns a acred ita rem que estáva1nos realizando algumas atividades incorretamente
no passado, e talvez isso não tenha ocorrido. Ela pode ser simplestnente uma maneira
mais eficaz e eficiente de alcança r um resu ltado a ser ent regue ao cliente. Utna outra
questão é que algumas pessoas acreditam que as 1nelhores práticas impl icam que há
uma maneira única e exclusiva de realizar uma tarefa. Isso tambétn pode ser uma in-
terpretação falha.
Ta lvez no futuro a expressão "melhores práticas" seja substituída por "práticas
comprovadas" . Ent retanto, no restante deste livro, usaremos a expressão "melhores
práticas", mas o leitor deverá cotnpreender que out ros termos podem ser mais apro-
priados. Essa interpretação é necessária neste livro porque a maioria das empresas que
para ele contribuíram ainda usa a expressão "mel hores práticas".
À n1edida que a gestão de projetos se desenvolveu, desenvolveram-se tambén1 as
definições do que seria un1a melh or prática. Algumas defin ições são extremamente
complexas, enquanto out ras são relativamente simpl istas. Contudo, a aplicação de
ambos os tipos alcançam o n1esmo propós ito de p ron1over a excelência na gestão
de projetos en1 toda a en1p resa. As empresas têm de decidir a q ual p rofundidade
querem chegar en1 un1a n1elhor prática. Ela deve ser genérica e pern1anece r nos
níveis n1ais a ltos da hierarquia da empresa ou n1ais deta lhada, chegando a n íveis
n1ais ba ixos? Mel ho res p ráticas de nível n1a is alto podem não alcançar a eficiência
desejada, enquanto n1elhores práticas extremamente deta lhadas podem ter un1a
aplicabi lidade limitada.
Cada etnpresa pode ter sua própria defin ição sobre o que é uma 1nelhor prática, e
pode até 1nesmo haver padrões sobre a definiç.ã o de u1na melhor prática etn diferentes
setores. Algumas definições típicas de uma melhor prática:
• Algo que funcione
• Algo que funcione bem
• Algo que funcione bem e seja repetível
• Algo que leve a uma vantagem competitiva
• Algo que possa ser identificado em u1na proposta para gera r negócios
• Algo que nos d iferencie de nossos concorrentes
• Algo que mantenha a empresa longe de problemas e, caso haja problemas, a me-
lhor p rática auxil iará a empresa a sair da situação problemática
Cada empresa possu i sua própria definição. Parece haver quat ro principa is moti-
vos para identificar 1nelhores práticas:
• Aumento da eficácia
• Aumento da eficiência
• Padronização
• Consistência
Em cada uma das defin ições a seguir, você deve ser capaz de identificar qua l das
quat ro, ou que combinações delas, é o alvo da empresa:
• Na Orange Switzerland, uma melhor prática é definida como uma forma de agir
baseada em experiências, comprovada e comum para atingir um objetivo."
• Temos melhores práticas que são detalhadas em nossas políticas/procedÍtnentos
e fluxos de trabalho. Essas são diretrizes e templates, bem co1no processos que
todos nós concordamos em seguir, além de serem métodos eficazes e eficientes
para todas as partes envolvidas. Além disso, quando fechamos (concluímos) um
projeto, conduzimos uma sessão formal sobre as lições aprendidas (envolvendo
o gerente do projeto, os pat rocinadores, a equipe centra l e outras partes afetadas
pelo projeto), que são armazenadas em u1n banco de dados coletivo e ana lisa-
das por toda a equipe. São essas lições aprendidas que, com efeito, criam nossas
melhores práticas. Compartilha1nos essas lições co1n outras organizações de as-
sistência méd ica e com os fornecedores para os quais somos referência. Todos
os nossos te,nplates, políticas/procedimentos e fluxos de trabalho são acessíveis
mediante solicitação e, quando necessário, organizamos reuniões para analisá-los
e explicá-los detalhadamente. (Nani Sadowski, antiga gerente do PMO da Halifax
12
Community Health Systems)
• Qualquer ferramenta, tetnplate ou atividade usada por um gerente de projeto que
tenha tido um impacto positivo nas áreas de conhecimento e/ou processo e/ou
a restrição t ripla do G1<ia PMBOK®. Um exe1nplo de uma melhor prática seria:
realizar avaliações de satisfação do cliente durante cada fase de um projeto per-
mi te que se façam ajustes durante o ciclo de vida do projeto, o que melhora o
resultado a ser entregue ao cliente e a gestão de projetos de 1nodo geral. (Isso seria
acompanhado de um template para uma pesquisa de satisfação do cliente.) (Porta-
-voz da AT&T)
• Gera lmente vemos como melhor prática qualquer atividade ou processo que me-
lhore determinada situação, elimine a necessidade de out ros 1nétodos mais traba-
lhosos ou melhore significativamente um processo existente. Cada 1nelhor prática
13
é uma entidade viva que está sujeita a revisões, emendas ou remoção.
• Para a Churchill Downs lnc., uma melhor prática é qualquer método ou processo
que comprovada1nente melhore os resultados desejados por meio de aplicações
práticas. Não aceita1nos padrões " industriais" ou "profissionais" como 1nelhores
práticas até que tenha1nos validado que o método ou processo funcione em nosso
ambiente corporativo.
Exemplos de algumas de nossas melhores práticas incluem:

• Assinatura do termo de abertura de projeto: Uma de nossas melhores práticas é
exigir a assinatura das partes interessadas no termo de abertura do projeto e no
programa. Isso parece óbvio, mas, por experiência própria, uma análise e uma
aprovação fonna l dos objetivos e metas de negócio raramente são documenta-
das. Ao documentar os objetivos de negócios e suas medidas associadas, con-
seguimos gerenciar expectativas de maneira proativa e garantir o a linhamento
entre várias partes interessadas.
• Definição de processo: Alén1 de defin ir o projeto, o programa e os processos de
gerenciamento de portfólio, o PMO tan1bém adotou o papel ativo de mapear
todos os processos financeiros da Church ill Downs lnc., de solicitações de che-
ques e solicitações de reen1bolso de funcionários a procedin1entos para solicitar
11
H. Ker1J1er, Project Management Best Practices: Achieving Global Exce/Jence, Hoboken, NJ: \Viley, 2006,
p . 12.
12
l bid., p. 13.
u l bid.
despesas de capital e pedidos de compra. Essa prática aun1encou a consciência

em toda a corporação de como p rocessos pad ronizados podem aumentar a
eficácia.
• Acesso à infonnação: O PMO desenvolveu roteiros de processos, procedimen-
tos e políticas para os processos orçamentários end-to-end, fluxos de tra ba lho
associados e templates. Esses foram disponibilizados a toda a empresa por meio
14
do CCN, o site intranec da empresa.
• Na lndra, consideramos uma "mel hor prática" em gestão de projetos uma ação ou
atividade de gerenciamento que normalmente gera um resultado positivo. Como
ca l, ela é aceita na comun idade de gerenciamento e finalmente acaba por se tornar
uma maneira recomendada ou exigida de rea lizar a tarefa. Considera1nos cambétn
uma "melhor prática" o uso de métricas predefinidas, lim ites ou medidas para
tomar ou facil itar a tomada de decisões em relação aos p rocessos de gestão de
· IS
proJetos.
• No PMO, uma melhor prática é um processo, 1netodologia ou procedimento que é
seguido a fim de garantir que se uti lizem uma abordagem e um padrão consisten-
tes. Na 1nax!T-VCS, as 1nelhores práticas são aval iadas (i nterna e externamente)
por sua eficiência e atua lizadas de modo a refleti r as lições aprend idas e a expe-
r iência prática de nossa base de consultoria em gestão de p rojetos, que trabalha
16
e1n campo com nossos clientes. Integra remos ca1nbém as melhores práticas do
setor e da literatu ra da área a toda a nossa experiência na empresa e às lições
apren d1.das com nossos proJetos.
· 17
• Sandra Kumoro,vski acredita que uma 1nelhor prática seja um método, tática ou
processo comprovado por meio da implementação e do uso testado com o intuito
de agregar benefícios específicos e mensuráveis e valor de longo prazo em termos
de melhores resultados no dese1npenho dos projetos, como: menores custos, ma ior
produtividade dos funcionários, melhor experiência do cliente (taxa de detenção)
e um maior número de novos projetos. As melhores práticas agregam va lor de
curto e de longo prazo para a organização.
Fu i responsável por fazer atua lizações das melhores práticas para todos os
funcionários. Logo após a sessão post mortem (reunião de lições aprendidas) e
depois de uma ideia ter sido confirmada como uma melhor prática, eu enviava
uma atualização via e-1nail a todos os funcionários. As melhores práticas típicas
incluíam:
• Distribuição da carga de trabalho e liderança de eq,lipe: Em uma equipe, são
igua lmente distribuídas entre o líder do projeto (consultor sênior) e um consul-
tor júnior que normalmente faria o trabalho pesado de anál ise sem participar
na co1nposição da estratégia propriamente dica. (Muitas vezes, o pessoa l júnior
tinha a sensaç.ã o de ser deixado de fora e de não ter cont ribuído para o sucesso
do projeto. Eles gera lmente se sentiam inferiores, e isso se tornava um grande
problema que dim inuía muito a produtividade da equipe. Ta l problema fazia
parte da descrição de cargo do est rategista sênior [eles eram responsáveis por
80% do pensamento estratégico de um projeto], que podia ser interpretado de
maneira diversa por diferentes pessoas.)
14
Comentários de Chuck .Millhollan, diretor de gerenciamento de programas, ChurchiJJ Downs ln.e.
u Comentários de Enrique Sevilla Jvlolina, PJvlP*, amigo diretor corporativo do P.M.0, ln.dra.
'' Comentários de Marc Hirshfield, PMP1\ diretor, escritório de gestão de projetos, maxlT-VCS.
17
Comentários de Heidi \-Vurcz, VP, Solucions Cenrer, maxíf.. VCS.
TABELA 1-4 Incentivos às melhores práticas

Setor privado Setor público
Lucro Minimização do custo
Competitividade Entrega dentro do prazo
Eficácia Eficácia
Eficiência Eficiência
Satisfação do cliente Satisfação das partes interessadas
Parcerias Contratação de fornecedor único
• Reunião de abertura do projeto (kick-off rneeting}: Todas as partes interessadas

no projeto têin de estar presentes nessa reun ião para discutir o escopo e os ob-
jetivos do p ro jeto. Deve-se segui r um formato específico de escopo para definir
objetivos de ma neira clara . Durante a reunião, todas as datas importantes têm
de ser determi nadas e acordadas por todas as partes interessadas.
• Reuniões de rnarcos do projeto: Precisa ser agendada (alguns usam o so ftware
GoToMeeting) e incluída nos calendários de todas as pa rtes interessadas logo
após a reunião de início do projeto.
• Reunião post mortem d o projeto: Todos os n1embros da equipe têm de avaliar
o desen1penho do projeto, preencher o q uestionário post niorte-1n e discuti-lo
com o utros n1embros da equipe. As reu niões post m orteni têm de ser agenda-
das no máximo uma sen1a na após a apresentação final ao cliente pa ra garantir
que os problen1as e/ou sucessos do projeto se n1antenhan1 nítidos na n1ente de
todos.
Essas definições de uma 1nel hor prática priorizam mais o setor privado do que o
p úblico. Uma comparação de possíveis incentivos pa ra a descoberta e imple1nentação
de melhores práticas nos setores pú blico e privado é 1nost rada na Tabela 1-4.
1.8 Passo 2: em busca das melhores práticas

As 1nelhores práticas podem ser identificadas dentr o ou fora de sua o rga nização. O
bench,narking é uma forma de identificar melhores práticas externas, possivelmente
usa ndo o escritório de projetos como o ponto de comando das atividades externas de
benchmarking. Entretanto, há outras fo ntes externas a lém do bench,narking para a
identificação de mel hores práticas :
• Publicações do Project Manage,nent Institute (PMI)
• Formulários, d iretrizes, templates e listas de conferência que possam afeta r a exe-
cução do projeto
• Formulários, diretrizes, templates e listas de conferência que possam afetar nossa
defi nição de sucesso em um projeto
• Cada uma das áreas de conhecitnento do Guia PJ\1BOK®
• Dentro de toda a e1npresa ou uni dades de negócios isoladas
• Semi nários e si1npósios sobre conceitos gerais de gestão de p ro jeto
• Semi nários e simpósios especializados nas melhores p ráticas de gestão de projetos
• Relações com out ras sociedades p rofissionais
• Teses de nível de pós-graduação
Com mais universidades oferecendo cursos de mestrado e doutorado em gestão de

projetos, há cada vez ma is dissertações e teses que pode1n oferecer pequisas atua liza-
das sobre melhores práticas.
O problema co1n benchmarking externo é que as melhores práticas descobertas
em u1na empresa podem não ser transferíveis para out ra empresa. Na opinião do au-
tor, a maioria das melhores práticas é descoberta internamente e é especificamente
relacionada com o uso de 1netodologias e processos de gestão de projetos pela empre-
sa. Boas metodologias de gestão de projetos permitem a identificação e a adoção de
melhores práticas. Entretanto, boas ideias podem vir do benchmarking també1n.
Às vezes, os direcionadores ou 1nétricas que afeta1n cada mel hor prática são mais
fáceis de encont rar do que a melhor prática propriamente d ita. Mét ricas e direciona-
dores podem ser tratados como indicadores precoces de que uma 1nelhor prática pode
ter sido encontrada. É possível ter vários direcionadores para cada melhor prática. É
possível também estabelecer um conjunto universal de direcionadores para cada me-
lhor prática, co1no:
• Redução de r iscos em certo percentual, custo ou prazo
• Aumento da precisão da estimativa em certo percentual ou valor em dólar
• Econom ias de custo em certo percentual ou valor em dólar
• Aumento da eficácia em certo percentual
• Redução do desperdício, da burocracia ou de prazos em certo percentual
Há diversas vantagens nessa abordagem de busca de direcionadores. Primeiro, os
direcionadores podem mudar com o te1npo, e novos pode1n surgir rapida1nente. Se-
gundo, o processo de melhores práticas é ma is uma ciência do que uma arte. E tercei-
ro, podemos estabelecer níveis de 1nelhores práticas como mostra a Figura 1- 5. Nessa
figura, uma melhor prática de nível 4, que é a melhor, satisfaria pelo menos 60 % da
lista de direcionadores ou características da melhor prática idea l.
As melhores práticas podem não ser transferíveis de uma empresa para outra,
e nem sempre serão transferíveis de uma divisão para out ra dent ro de uma mes1na
empresa. Co1no exemplo, considere a segu inte melhor prática descoberta por u1na
empresa de telecomunicações:
• Uma e1npresa institucionalizou um conjunto de va lores que professava1n que a
qualidade era tudo. O resultado foi que os funcionários estavam focando tanto a
qualidade que houve u1na degradação da satisfação do cliente. A e1npresa, então,
redefin iu suas prioridades, tornando a satisfação do cl iente seu valor de maior
importância, e a qualidade melhorou, de fato.
Nessa empresa, a ênfase na satisfação do cliente levou à melhoria na qualida-
de. Entretanto, em uma out ra empresa, a ênfase na qualidade poderia igua lmente ter
levado a uma melhoria na satisfação do cliente. Deve-se to1nar cuidado durante as
atividades de benchmarking para garantir que quaisquer melhores práticas que fore1n
descobertas sejam, de fato, diretamente aplicáveis à sua empresa.
As melhores práticas não precisam ser visivelmente complexas. Como um exem-
plo, a lista de melhores práticas a segu ir foi retirada de empresas discutidas neste livro,
e, co1no se pode observar, algumas das melhores práticas foram aprendidas com fra-
cassos, e nao com sucessos:
• Trocar os gerentes de projeto durante o projeto é ru im mesmo que ele esteja apre-
sentando problemas, pois inevitavelmente alonga o projeto e pode torná-lo ainda
pior.
Nível 4: >60%
Características
Nível 3: 40%-60%
da melhor
Nível 2: 20%-40%
prática ideal
Nível 1: 0%- 20%
Figura 1-5 Níveis das melhores práticas. Gada nível contém um percentual das caracterís-
ticas ideais.
• Padron ização gera resultados excelentes. Norma lmente, quanto ma is padron iza-
ção houver e1n uma metodologia de gestão de projetos, 1nelhores serão os resul-
tados.
• A maximização dos benefícios ocorre com uma metodologia baseada em templa-
tes, formu lários, diret rizes e listas de conferência em vez de em políticas e proce-
dimentos.
• As metodologias têm de ser atualizadas para que inclua1n os resultados da des-
coberta de melhores práticas. Quanto ma is frequentemente a metodologia for
atualizada, ma is rapidamente os benefícios serão percebidos.
Co1no d ito antes, as melhores práticas não precisam ser co1nplexas. Embora a i-
gu inas possam parecer simplistas e baseadas no senso comum, rememorá-las e usá-las
constantemente leva à excelência e à satisfação do cliente.
Uma outra maneira de identificar fontes de melhores práticas é a partir da defini-
ção de sucesso do projeto, fatores críticos de sucesso (CFSs, criticai success factors ) e
indicadores-chave de desempenho (KPis, key perfo rmance indicators). Ext rair melho-
res práticas a partir da definição de sucesso em um projeto pode ser difícil e enganoso,
especiahnente se tivermos uma má definição de sucesso.
Ao longo dos anos, muitas das mudanças que ocorreram na gestão de projetos
foram resultado do modo como defini1nos o sucesso de um projeto. Como um exem-
p lo, considere os seguintes eventos cronológicos que ocorreram ao longo das últimas
décadas:
• O s11cesso é tnedido pelas triplas restrições ou restrições de concorrência. As tri-
plas rest r ições são prazo, custo e desempenho (que inclui qua lidade, escopo e
desempenho técnico). Essa era a base da definição de sucesso durante o nascimen-
to da gestão de projetos. As restrições de concorrência incluem segurança, valor
estético, benefícios, nível de r isco aceitável, etc.
• A satisfação do cliente tatnbém precisa ser considerada . Gerenciar um projeto
dentro das triplas restrições é sempre uma boa ideia, 1nas o cliente tem de ficar
satisfeito co1n o resultado fina l. Uma contratada pode concluir um projeto dentro
das triplas restrições e ainda assim descobrir que o cl iente ficou insatisfeito com o
resultado final.
• Outros fatores (o·u fatores secundários) também têm de ser considerados. Eles
inclue1n usar o no1ne do cl iente como referência, a reputação e a i1nage1n corpora-
tiva, o cumprimento de regulamentações governamenta is, o alinhamento estraté-
gico, a superioridade técnica, a conduta ética e out ros fatores similares. Os fatores
secundários podem acabar sendo ma is importantes do que os fatores priinários

das restrições t riplas.
• O s1,cesso te,n de incluir 11m componente de negócios. Os gerentes de projeto e.s-
tão gerenciando parte de um negócio em vez de meramente u1n projeto, e espera-
-se que eles tomem sólidas decisões de negócios a lém de decisões de projetos. É
necessário haver u1n objetivo comercia l para cada projeto. Cada projeto, quando
concluído, é considerado uma contribuição de valor comercial para a empresa.
• Deve haver 11ma priorização das restrições. Nem todas as restrições de projetos
são iguais. A priorização das restrições é feita separadamente para cada projeto. É
essencial que os patrocinadores do projeto se envolvam nessa decisão.
• A definição de s11cesso tem de ser acordada entre o cliente e a contratada. Cada
projeto pode ter uma definição diferente de sucesso. Cliente e contratada precisam
definir de 1naneira honesta no início do projeto, ou me.sino na primeira reunião
entre eles, o que constitui sucesso.
• A definição de sttcesso tem de inclttir um co,nponente de "valor". Por que traba-
lhar em um projeto que não oferece o va lor esperado correto na sua conclusão?
O problema com uma definição de sucesso como um projeto realizado dentro
do prazo, do custo e com a qua lidade ou o nível de dese1npenho desejado é que essa
é uma defin ição apenas interna. Coisas ruins pode1n acontecer em projetos quando
contratada, cl iente e várias partes interessadas têm d iferentes defin ições de sucesso.
Deve ser feito um acordo prévio sobre o que constitu i o sucesso do projeto. O cliente
fina l ou a parte interessada deve ter influência na defin ição de sucesso, e, em últi1na
aná lise, podem-se descobrir inú1neras melhores práticas que estão relacionadas com a
interação entre cliente e parte interessada.
Hoje, reconhecemos que o cliente, e não a cont ratada, é quem define a qua lidade.
O mesmo vale para o sucesso do projeto. Qua lquer definição de seu sucesso tem de
incluir a aceitação por parte do cliente e da parte interessada. Você pode concluir u1n
projeto internamente em sua empresa dentro do prazo, do custo e da qua lidade ou
limites de especificação determinados e, ainda assim, descobrir que o projeto não foi
totahnente aceito pelo cliente ou pelas partes interessadas.
Na Enakta, a definição de sucesso do projeto é co1nparada à definição de fracas-
18
so do projeto. De acordo com Sandra Kumorowsk i, a definição pode ser da fonna
apresentada na Tabela 1-5.
Embora as empresas possam manter u1na definição de sucesso do projeto (e mes-
mo de seu fracasso), elas podem não ter uma definição clara de excelência e1n gestão
de projetos. Isso ocorre quando a gestão de projetos está totahnente integrada a todos
os processos de fluxo de trabalho da empresa ou é vista como uma prática que desem-
penha um papel de apoio. Sandra Kumorov.rsk i acredita no seguinte:
Na Enakta, não temos uma definição formal do que seja excelência em gestão de projetos.
Entretanto, nossa empresa queria vê-la como uma prática com um papel de apoio à cria-
tividade. A excelência é, então, alcançada po r meio da total personalização da estrutura
organizacional corrente e do total a linhamento com metas organizacionais de longo prazo,
como mostra a Figura J--j,.
11
Sandra Kumorowski é professora assistente de comunicação e marketing no Columbia College, Chicago;
cátedra de .Marketing e Communicaç.ão, Christopher & Dana Reeve Foundacion, Chicago; é também princi~
pai consultora empresarial e proprietária da Enakta LLC; P: 1- 224-715-5666; e-mail: sandrakum@sbcglobal.
ner1 skumorowski@colum.edu.
TABELA 1-5 Comparando sucesso e fracasso de projetos: uma medida de sucesso

de projeto em gestão de projetos
Sucesso Nível organizacional

D Mais negócios com o cliente • Índice de projetos bem e mafsucedidos por ano
D Clientes entram em contato • Maior número de projetos bem-sucedidos por perlodo (ROi)
conosco • Todos estão no mesmo barco, aceitando mudanças, sem resistência
D Satisfação do cliente durante/ • Gerenciamento eficiente do portfólio do projeto= uso equilibrado de recursos
depois do projeto • Maior satisfação do cliente
D A equipe do projeto está feliz • Número de clientes que retornam
• Número de clientes que nos procuram por recomendação
Fracasso Nível do projeto
D Mais nenhum negócio com o • Redução dos custos do projeto (trabalhando em mais de um projeto ao
cliente mesmo tempo eficientemente, etc.)
D Temos de ligar para os clientes. • Tempo do projeto é bem distribuldo, equipe não precisa trabalhar à noite
D Insatisfação do cliente durante/ ou nos fins de semana
depois do projeto • Número menor de eventos/mudanças inesperadas durante todo o projeto
D A equipe do projeto não está feliz • Boa dinâmica de equipe, atingiu as expectativas
• Número menor de questões negativas por projeto
Crescimento contínuo
Cliente feliz
Figura 1-6 Gestão de projetos e seu papel de suporte.
Embora algumas defi nições de sucesso de projeto pareçam bastante simples, mui-
tas e1npresas desenvolveram a definição primária de sucesso de projeto. Na C hurchill
Do,vns Inc. (CDI), o sucesso é definido ma is rigorosamente do que na ma ioria das
e1npresas. Segundo C huck Millhollan, diretor de gerencia1nento de programa:
O sucesso de um projeto é definido em nossa cartilha de PMO da seguinte maneira:
Baseado nas informações da gerência execut iva da CDI, o PMO considera que um pro-
jeto foi bem-sucedido quando os seguintes fatores são verdadeiros:
a. Os objetivos de negócios foram predefinidos e os objeti,•os do projeto foram atingidos
o u excedidos.
b. Um prod uto de a lta qualidade é integralmente implementado e utilizado.
c. O projeto foi entregue no prazo o u antes e dentro dos alvos orçamentários.
Capítulo 1 Compreendendo a s melhores práticas 27
d. Várias partes saem ganhando:

,. Os participantes do projeto se orgulh am de sua participação proprietária e se sentem
bem com seu trabalho.
ii. As expe.c tativas do cliente (interno e/ou externo) são alcançadas.
111. A gerência alcançou seus objetivos.
e. Os resultados do projeto ajudaram a construir uma boa reputação.
f. Há métodos implementados para o monitoramento e a avaliação contínuas (realização
de benefícios).
Não usamos indicadores de " processo" de gestão de projetos para definir o seu sucesso.
Embora o cronograma e os alvos o rçamentários façam parte dos critérios, a aceitação pelos
patrocinadores, a conclusão do projeto e, em última análise, o sucesso do projeto se baseiam
em alcançar objetivos de negócios definidos.
En rique Sevilla Molina, PMP®, antigo diretor corporativo do PMO da Indra, oferece-
-nos a definição de s ucesso de um projeto e s ucesso de um p rograma adotada por s ua
empresa:
• O sucesso de um projeto se baseia em alcançar os objetivos propostos pelo projeto em
termos de orçamento, escopo, desempenho e prazo. Muitas vezes, os critérios econômi-
cos aparecem como o fator determinante para medir o sucesso, mas há o utros fatores
igualmente importantes, como a construção de um relacionamento duradouro e de for-
tes alianças com parceiros selecionados. Um o utro critério significativo para a med ição
do sucesso de um projeto é a confiabilidade da previsão de dados do projeto. Q uando os
resultados econômicos não são tão bons quanto deveria m ser, se o fato for identi ficado e
relatado s uficientemente cedo, pode ser que o projeto a inda alcance o s ucesso.
• O s ucesso de um programa se baseia em alcançar os seus objeti vos estratégicos gerais,
determinados durante a definição do programa . Assim, o sucesso é med ido não somen-
te por em q ue medida a empresa alcançou os res ultados econômicos esperados, mas,
acima de tudo, por em q ue medida ela alcançou a posição esperada no mercado em
relação a um produto o u linha de produtos e estabele.ceu uma posição mais vantajosa
em relação aos concorrentes. A liderança em uma lin ha de prod utos constitui a medida
máxima de sucesso em um programa. Vale mencionar que, muitas vezes, o sucesso de
um programa depende do conceito de parceria desenvolvido com nossas principais sub-
contratadas no nível do projeto.
• O s ucesso de um projeto é definido no nível da unidade de negócios pelo diretor res pon-
sável, de acordo com os objetivos estratégicos atribuídos ao projeto.
• O sucesso de um programa é definido no nível da empresa pelo gerente chefe de opera-
ções, de acordo com a missão definida do programa.
A AT&T define o sucesso de um projeto e de um programa de maneira sim ila r. De acor-
do com um porta-voz da empresa:
O s ucesso de um p rojeto é defin ido como um nível de satisfação do cl iente "Muito
Satisfeito" e um desempenho de entrega do projeto dentro do prazo de pelo menos 98%. A
Equi pe de Liderança O rganizacional da Gestão de Projetos estabele.ce os objetivos, que são
acompanhados para determinar o sucesso do projeto. O s ucesso de um programa é definido
e acompanhado da mesma maneira.
A excelência [em gestão de projetos] é definida como uma Metodologia de Gestão de
Projetos consistente aplicada a todos os projetos de toda a organização, o reconhecimento
continuado por parte de nossos clientes e uma alta satisfação do cliente. Além d isso, nossa
excelência é um fato r de venda essencial para nossas eq ui pes de venda . Isso resulta em
novos negócios com nossos clientes. Ainda, reconhece-se internamente que a gestão de p ro-
jetos agrega valor e é absolutamente necessária .
O sucesso do projeto pode ser medido d e forma interm itente d urante todas as
reun iões de ava liação de fase ou e tapa que fa zem p a rte d a metodologia de gestão de
projetos. Isso permite que a emp resa esta beleça métr icas p rovisórias pa ra medi r o s u-
cesso . Um exem p lo d isso a parecerá no Capítulo 4 .
Um outro ele1nento que está se tornando importante na definição do sucesso é a

pa lavra "valor". As informações a seguir foram fornecidas por Doug Bolzman, arqui-
teto consultor, PMP®, gerente de serviços !TIL®na Hewlett-Packard: 19
Compreendendo o sucesso de um projeto

Em determinado ponto, os cl ientes estavam medindo o sucesso de um projeto verifi-
cando se ele estava dentro do prazo e do orçamento. Mas se o projeto não agrega valor
real de negócios, de que adianta ele ter cumprido o prazo e o orçamento? O valor dos
projetos está se transformando, passando a representar o valor para seu usuário ou
cliente.
Na ma ioria dos casos, em uma organização que presta serviços de TI, o projeto
não é tudo. Ele é um 1neio para se chegar a u1n fim e, co1no ta l, é visto co1no um ganho
incremental. Os projetos em TI são vistos desde a implementação de um novo serviço,
que pode constitu ir um conjunto de projetos (ou lança1nentos), até os projetos de ma-
nutenção, co1no os ttpgrades de sistemas operacionais. O sucesso do projeto é atingir
os objetivos, produzir o que será entregue como resultado do projeto e adquirir o re-
sultado desejado com o t rabalho. O valor em TI é medido em relação a com que grau
o serviço de TI permite que a empresa funcione. Ele diminui a mão de obra manual e
fornece ao receptor um resultado satisfatório?
Definindo o sucesso de um projeto

Um bom gerente de projeto definiria o sucesso a partir da perspectiva dos usuários
ou dos clientes. Isso pode ser difícil de identificar no início, se a carta do projeto se
basear em premissas com un1a perspectiva diferente. Nossa equipe de gerencian1ento
está sempre desafiando os gerentes de projeto a explicaren1 o va lor do lançamento - o
que justifica o custo e o investimento de ten1po? Não podemos arca r con1 in1plen1en-
tos nos projetos porque a lguén1 identificou uma necessidade ou fez uma sugestão de
aperfeiçoamento. Precisan1os estar na n1ais atua l versão de um produto ou aplicativo?
A versão atua l atende às nossas necessidades de negócios? Que ganhos teremos en1
fazer um upgrade? O custo do projeto se pagará em eficiência, melhores resu ltados,
maior receita? Se essas perguntas não puderem ser respondidas pelo gerente de proje-
to (ou pelo patrocinador do projeto), ele não será aprovado. Os executivos podem de-
term inar o va lor gera l de como os projetos levam ao sucesso de um progran1a ou in i-
ciativa, n1as os usuários ou cl ientes serão a entidade que receberá o va lor do projeto.
" Doug Bolz.man está com a HP/EDS há mais de 25 anos e acualmeme é membro da equipe de Capacitação
em Transformação Empresarial da HP, que objetiva melhorar os resultados entregues aos clientes do Geren·
ciamemo de Serviços de TI. Ames da fusão da HP, a EDS enviou uma parente em nome dos processos de Doug
incitulada "Sistema e .M.érodo para Identificar e Monitorar as Melhores Práticas de uma Empresa"' (System
and Method for ldentifying and Monitoring Best Practkes of an Enterprise). Desde 1995, Doug vinha ar·
quirerando e entregando aos clientes uma abordagem para instituir a 1T lnformation Library (ITIL• ) em seu
ambiente de operações de 11. Ao trabalhar com os cliemes, Doug utiliza sua estrutura IT Enterprise lvlanage·
menr (ITEM), juntamente com o guia Project Management Body o/ Knowledge {PMBOK") e o c iclo de vida
do IT Service !vlanagement (ITSM) para auxil iar o cliente ao longo de mudanças culrurais, organizacionais,
empresariais e operacionais. Doug possui um certificado de Especialista em ITIL, rendo desenvolvido on-line
o treinamento mL Foundarion Training para o mL Version 2 juntamente com as edições de 2007 e 201 1.
Os comentários de Doug se baseiam no relacionamento da HP com seus clientes, especialmente quando eles
estão rrarando do gerenciamento empresarial de um negócio como um todo, e não simplesmente do gerencia·
mento de suas partes constirurivas.
Fatores críticos de sucesso

Comumente, os projetos ou melhoram algo, ou reduzem algo. Essas melhorias surge1n
na forma de capacidade ou funciona lidade da empresa (por 1neio dos funcionários/
usuários). Estes geram ainda mais produtividade na forma de novos produtos e ser-
viços ou mais eficácia para os produtos já existentes. Os fatores críticos de sucesso
(CSFs, criticai success factors ) são associados aos objetivos de negócios gera is.
Indicadores-chave de desempenho para o sucesso
Os indicadores-chave de desempenho (KPls, key performance indicators) perm ite1n
que o cliente faça uma série de mensurações para garantir que o desempenho se encon -
tra dentro dos limites declarados (fatores de sucesso). Os executivos chamam isso de
"manter o pulso da e1npresa" . Os KPls são determ inados, medidos e comunicados por
meio de 1necan ismos como dashhoards ou métricas.
Os comentários de Doug B0lz1nan indica1n que talvez o critério ma is importante
de todos para definir uma possível melhor prática seja verificar se ela agrega valor à
empresa e/ou ao cliente. De acordo com u1n gerente de progra1nas da Hewlett-Packard,
as três melhores práticas a segu ir são práticas que agrega1n valor:
• Portais de colaboração de projeto com templates de GP e kits de ferramentas in-
tegradas com a possibilidade de sol icitar recursos adiciona is por uma equipe de
suporte.
• Ret rospectivas de projeto - muito úteis para o aprendizado em grupo e para iden-
tificar/reconhecer/documentar" melhores práticas", mas, de fato, o desafio é a co-
municação para além da equ ipe imediata.
• Projetos virtuais - dado que haja infraestrutura suficiente, acho que projetos
virtuais são mais produtivos e eficientes do que gastar tempo de trabalho e
dinheiro en1 viagens. Acho que a HP uti liza muito ben1 essas capacidades inter-
namente.
A 1náxima definição de sucesso pode muito bem ser quando o cliente está tão
satisfeito com o projeto que permite que você use seu no1ne como referência. Isso
ocorreu em uma empresa que fez uma proposta a 40o/o abaixo do custo de realizar o
trabalho. Quando questionados sobre o porquê de a proposta ter sido tão baixa, os
representantes da empresa responderam que sabiam que estavam perdendo dinheiro,
mas que o que era rea lmente importante era conseguir o nome do cliente no "currícu-
lo" da empresa. Portanto, os fatores secundários podem 1nu ito bem ser mais importan-
tes do que os fatores primá rios.
A definição de sucesso também pode mudar dependendo de se a empresa é ou
não orientada a projetos. E1n uma empresa orientada a projetos, todo o negócio da
empresa é projetos. Mas em uma empresa não orientada a projetos, os projetos exis-
tem como suporte ao negócio corrente de produção ou prestaç.ã o de serviços. E1n u1na
empresa não orientada a projetos, a definição de sucesso ta1nbém inclui a conclusão
do projeto sem causar qualquer problema às atividades principa is dessa empresa. É
possível concluir um projeto dent ro do prazo, do custo e da qua lidade determ inados
e, ao mesmo tempo, causar danos irreparáveis à organização. Isso ocorre quando o
gerente de projeto não percebe que seu projeto possui uma importância secundária
para o negócio principal da e1npresa.
Algumas empresas definem sucesso em termos de CSFs e KPls. Os fatores críticos
de sucesso identifica1n os fatores necessários para atender às necessidades do clien-
te. Os CSFs e KP!s não precisam ser métricas elaboradas ou sofisticadas. Métricas
simples, possivelmente baseadas na restrição tripla, pode1n ser bastante eficientes. De

acordo com um porta-voz da AT&T:
Os fatores críticos de sucesso incluem prazo, escopo, orçamento e satisfação do cliente. Os
indicadores-chave de desempenho incluem desempenho dentro do prazo para os principais
res ultados a serem entregues. Estes incluem a instalação no cliente, satisfação do cliente e
tempo de ciclo para marcos comuns.
Típicos CSFs para a maioria das e1npresas inclue1n:
• Cumprimento do cronograma
• Cumprimento do orçamento
• Concretização da qualidade
• Conveniência e oportunidade da assinatura do contrato
• Cumprimento do processo de controle de mudanças
• Aditivos do contrato
Os fatores críticos de sucesso 1nedem o resultado final, normahnente a partir da
perspectiva do cl iente. Os KPis medem a qua lidade do processo utilizado para alcan-
çar os resultados finais. Os KPis são indicadores internos e pode1n ser revisados perio-
d icamente por meio do ciclo de vida de um projeto. Típicos KPis inclue1n:
• Uso da metodologia de gestão de projetos
• Estabelecimento de processos de controle
• Uso de 1nétricas provisórias
• Qualidade dos recursos aplicados versus planejados
• Envolvimento do cliente
Os indicadores-chave de desempenho respondem a perguntas co1no: A metodolo-
gia foi aplicada corretamente? Mantivemos a gerência informada? Com que frequên-
cia? Os recursos adequados foram alocados e uti lizados eficientemente? Aprendemos
alguma lição que pudesse nos levar a atua lizar nossa metodologia ou seu uso? As
empresas de excelência em gestão de projetos medem o sucesso tanto interna quanto
externamente usando KPis e CSFs. Como um exem~o, considere os segu intes comen-
tários feitos por um porta-voz da Norte) Networks:
A Norte! define o sucesso de um projeto de acordo com medidas relativas ao cronograma,
custo e qualidade, como acordado mutuamente pelo cliente, a equipe do projeto e as prin-
cipais partes interessadas. Exemplos de indicadores-chave de desempenho podem incluir a
conclusão de marcos essenciais do projeto, resultados da instalação/integração do produto,
res ultados da gestão de mudanças, conclusão dentro do orçamento e assim por diante. A
situação e os res ultados do projeto são monitorados de perto e analisados conjuntamente
pelo cliente e pela equipe de projeto regularmente ao longo de todo o projeto para garantir
expectativas consistentes e o sucesso geral. O sucesso do projeto é medido pela satisfação
do cliente.
Vejamos mais a lgumas defin ições de CSFs e KPls:
• CSFs:
• Fatores de sucesso são definidos nos estágios iniciais do projeto ou programa,
mesmo antes de eles se tornarem contratos de fato, e são uma consequência
direta dos objetivos estratégicos alocados ao projeto ou programa. Muitas ve-
zes, esses fatores são associados à expansão da participação de 1nercado em
io H. Keru1er~ Project Ma11agement Best Practices: Achieving Global Exce/Jencet Hoboken, NJ: \Viley, 2006,
p. 26.
uma lin ha de produtos ou ao desenvolvimento de novos mercados, tanto técnica

quanto geograficamente. (Fornecido por Enrique Sevilla Mol ina, PMP®, antigo
diretor corporativo do PMO, Indra)
• Obviamente, os CSFs variam de acordo co1n o projeto e sua intenção. Aqui há
alguns que se apl icam a uma grande variedade de projetos:
• Envolvimento do cliente desde o início
• Padrões de alta qua lidade
• Processos definidos e avaliações de fase formalizadas
• Estr utura organizacional interfuncional das equipe.s
• Controle de requerimentos, prevenção do au1nento gradual de escopo (scope
creep)
• Comprometimento com cronogramas - planejamento discipl inado para o nível
adequado de deta lhes e acompanhamento objetivo e frequente
• Comprometimento de recursos - nível certo de habil idade no momento neces-
' .
sano
• Comun icação ent re equipes internas e com o cliente
• Identificação precoce de riscos, gerencia1nento e mitigação - sem surpresas
• Execução técnica desigual baseada em uma engenharia rigorosa (comentários
feitos por um porta-voz da Motorola)2'
• KPis:
• Esta1nos implementando um p rograma de qua lidade provisório para 1nedir [a)
qualidade de todos os projetos e o desempenho dos gerentes de projeto em toda
a empresa. Esse programa inclu irá anál ises de projeto periódicas, detenninadas
pelo escopo, duração e complexidade do projeto e terminará com a perspectiva
do cliente sobre a qualidade ent regue pela empresa e pelo gerente do proje-
to. Isso talvez não mais seja chamado de "Avaliação de Qua lidade de Tarefas"
(AQA, Assignment Q11ality Assessment), mas ainda irá suscitar o feedback do
cliente e contribuir com o plano de mensuração do desempenho do gerente do
projeto. O programa de aval iação da qua lidade é uma função de nosso Cen-
tr o de Soluções, que oferece suporte a empresas integradas: maxIT-VCS. (Heidi
Wurtz, VP, Solutions Center, maxIT-VCS)
• Nossos KPis ma is comuns estão associados aos re.sultados financeiros dos pro-
jetos, por exemplo, a concordância ent re a 1nargem do projeto e o objetivo es-
t ratégico alocado, os valores de novos cont ratos para os objetivos da área de
desenvolvi1nento empresaria l, etc. Os fatores de sucesso se traduzem em indica-
dores de desempenho para que eles sejam checados periodicamente.
• Por padrão, uma primeira indicação da saúde do projeto é fornecida pelos índi-
ces de de.sempenho de prazos e de custos (IDP e IDC) embutidos nas ferramen-
tas de GP. Eles são gerados 1nensa lmente pelo sistema de infonnação de gestão
de projetos e também estão disponíveis para aná lise e revisão de histórico. Es-
ses indicadores também são calculados para cada departamento, e constitue1n,
assi1n, um indicador do desempenho geral de custo e prazo do departamento
ou un idade de negócios. (Fornecido por Enrique Sevilla Molina, PMP®, antigo
diretor corporativo do PMO, Indra)
• Indicadores de aceitação pós-entrega:
• Lucros e perdas
• Devoluções dent ro da garantia
• Defeitos únicos relatados pelo cl iente
• Mét ricas de satisfação
21
Ibid., p. 27.
• Indicadores durante o processo:

• Tendências de defeitos em co1npa ração ao plano
• Estabilidade de cada configuração (mudanças na contagem de peças) em com-
paração ao plano
• Funcionalidades presentes em comparação ao plano
• Prazos planejados vers11s desempenho real
• Esforço planejado versus desempenho real
• Custos de produção e métricas de qualidade
• Conformidade com processos de qual idade e resultados de auditorias de qua-
lidade
• Taxa de conclusão de teste de sistema e de aprovação/reprovação em compa-
ração ao plano
• Taxa de resolução de defeitos/proble1nas
• Índice de falhas em testes de stress reais em comparação ao p lano
• Defeitos por centenas de unidades (DPCU) do protótipo du rante o de-
senvolvimento em con1pa ração ao plano (Fornecido por um porta-voz da
n
Moto rola)"·
• O SOW (statement of work, especificação do traba lho) fornece uma lista de
conferência de indicadores básicos pa ra o sucesso do projeto, 1nas a satisfação
do cl iente também é importa nte. O SOW indica rá o que são os resu ltados a
sere1n entregues e fornecerão informações sobre custos e cronogramas, que são
facilmente acompanhados.
A 1naioria das pessoas parece compreender que os CSFs e KP!s podem ser dife-
rentes de u1n projeto para o outro. Ent retanto, é comum a crença errônea de que, uma
vez estabelecidos, eles não pode1n mudar durante o projeto. À medida que os projetos
passam por várias fases de seu ciclo de vida, esses indicadores podem mudar. Carl
Manello, PMP®, líder de soluções - gerenciamento de programas e projetos, Slalom
Consulting, acredita que:
Estabelecer os fatores críticos de s ucesso e os indicadores-chave de desempenho corretos é
essencial. O sucesso definido de um projeto (i .e., sucesso definido sign ifica q ue... todas as
partes interessadas estão de acordo nas etapas inicia is do projeto quanto ao seu estado fi-
nal) é identificado por meio dos fatores críticos de sucesso. A seleção dos indicadores-chave
de desempenho corretos para um projeto estabelece as métricas de mensuração a serem
acompanhadas para determinar se os fatores críticos de sucesso serão alcançados. Como
ponto de partida, "dentro do prazo", "dentro do orçamento" e "com as especificações acor-
dadas" (ou dentro de um intervalo de tolerância para as três métricas) são bons KPls bá-
sicos. À medida que os projetos amadurecem em sua capacidade de produzir res ultados,
indicadores de desempenho ma is sofisticados podem ser implementados. Por exemplo, em
vez de usa r a definição vaga de "acordado nas especificações", os projetos podem escolher
usar a formal idade de uma medida de volatilidade de requerimentos e alguma variação
aceitável em torno de um valor base.
Na experiência do autor, mais de 90 % das melhores práticas que as empresas
identificam são provenientes da anál ise dos KP!s durante as sessões de balanço (de-
briefing) ao conclu ir um projeto ou em algu1nas reuniões de análise de fases. Devido
à i1nportância de se identificar essas 1nelhores práticas, algumas empresas passaram a
t reinar facilitadores profissionais capazes de realizar o debriefing de equipes de proje-
to e identificar as mel hores práticas.
l2 lbid.
Capítulo 1 Compreendendo a s melhores prátic as 33
Antes de deixar esta seção, é necessário compreender quem descobre as mel hores
práticas. As 1n elhores p ráticas são descobertas pelas pessoas q ue realizatn o trabalho,
a saber, o gerente do projeto, a equi~e do projeto e possivelmente o gerente de á rea.
3
Segundo um porta-voz da M otorola:
A decisão quanto ao que é chamado de melhores práticas é tomada dentro da comunidade
que realiza a prática. As capacidades do processo geralmente são conhecidas e possuem
bases de referência. Para exigir o status de melhor prática, a prática o u processo p recisa
mostrar q ua ntitativamente melhorias signi ficativas em qualidade, eficácia, custo e/ou d ura-
ção de ciclo. A gerência da organização afetada e a gerência de processos têm de aprovar a
nova prática antes de s ua institucionalização.
Geralmente, o processo de identificação começa com o membro de equ ipe apro-

priado. Se o 1n embro de equ ipe acredita ter descoberto uma nova melhor prática,
ele informa seu respectivo gerente de área e possivelmente gerente de projeto pa ra
confirmação. Uma vez que se decida a favor da confirmação, o 1n aterial é enviado ao
escritório de gestão de projetos (PMO) pa ra va lidação. Após a validação, a pessoa
que identificou a melhor prática recebe o título de "Proprietár io de Melhor Prática" e
passa a ter a responsabilidade de fo mentá-la e cul tivá-la.
Algumas empresas usam facilitadores profissiona is pa ra rea lizar o debriefing das
equipes de projeto a fim de identificar as melhores práticas. Esses facili ta dores podetn
ser enca rregados do PMO e são profissional mente trei nados para identificar lições
aprend idas e mel hores práticas tanto de sucessos quanto de fracassos . Listas de confe-
rência e templates podem ser usados como parte do processo de facilitaç.ã o. Como utn
exemplo, considere as segu intes decla rações de Sa ndra Kumo rowski:
Depois de cada p rojeto, realizamos reun iões de post mortem a fim de avaliar o desempenho
do projeto. Criei um formato -padrão - uma lista de perguntas - , e todos o s membros da
eq uipe tinha m de preparar suas respostas a ntecipadamente. Se houvesse a lguma ideia, p ro-
cesso o u tá tica que tivesse agregado um benefício mensurável ou um valor de longo prazo
para a organização, a a lta gerência, então, adicionava-o à nossa Bibliote.ca. Eu era responsá-
vel por uma atualização para todos os funcioná rios toda vez que uma nova melhor prática
fosse adicionada à nossa Biblioteca de Melhores Práticas.
1.9 Dashboards e Scorecards

E,n nossa tentativa de digitalizar a gestão de projetos, enfatizaram-se representações
visuais como dashboards e scorecards utilizando e exibindo CSFs e KP!s. Executivos
e cl ientes desejam uma exibição visual das informações mais críticas sobre o desem-
penho do projeto, ocupa ndo o menor espaço possível. Técnicas simples de dashboard,
como o relatório do semáforo, podem expressa r informações críticas sobre o desem-
penho. Como um exetnplo:
• Setnáforo vermelho: Existe um problema que pode afetar prazo, custo, qua lidade
ou escopo. É necessá rio o envolvimento dos patrocinadores do projeto.
• Setnáforo amarelo : Trata-se de uma advertência. Pode existir um possível proble-
ma, talvez no futuro, se não for monitorado. O patrocinado r é informado, mas
não é necessário que ele tome providências no momento.
• Setnáforo verde: O t rabalho está progredindo confo rme planejado. Não é neces-
sário nenhum envolvi mento do patr ocinador.
u Ibid., p. 14 .
Embora um semáforo com apenas t rês cores seja o mais comum, algumas em-
presas usam mais cores. O grupo de tecnologia de informação (TI) de um revendedor
usava u1n dashboard de oito cores para seus projetos. A cor amarela sign ificava que
a data fina l a lvo tinha passado e o projeto ainda não estava concluído . A cor roxa
significava que esse pacote de t raba lho estava passando por uma oscilação no escopo
e poderia causa r um impacto sobre a restrição tripla. Algumas pessoas confundem os
4
dashboards com os scorecards. Há uma diferença entre eles. Segundo Eckerson:2
• Os dashboards são 1necanismos de exibição visual usados em um sistema de men-
suração de desempenho de cunho operacional que mede o desempenho em com-
paração a a lvos e limites usando dados de " tempo certo".
• Os scorecards são representações visua is usados em um sistema de mensuração
de desempenho de cunho estratégico que registra graficamente o progresso em
direção ao atingimento de metas e o bjetivos estratégicos por meio da cotnparação
do desempenho com a lvos e limites.
Tanto os dashboards quanto os scorecards são mecanismos de exibição visual
de um sistema de 1nensuração do desempenho que expressa1n informações críticas.
A diferença prÍlnordia l entre eles é que os dashboards monitoram processos opera-
cionais como aqueles que são usados na gestão de projetos, enquanto os scorecards
registr a1n grafica1nente o progresso de metas táticas. A Tabela 1-6 e a descrição que a
acompanha 1nostram como Eckerson compara as características dos dashboards e dos
scorecards. 25
Dashboards: Dashboards são mais como os painéis de controle de um automóvel. Eles
perm item que os especialistas operacionais e seus supervisores monitorem eventos gerados
pelos principais processos de negócios. Mas ao contrário dos automóveis, os dashboards da
maioria das empresas não exibem os eventos em "tempo real ", no momento em que ocor-
rem; eles os exibem no "tempo certo", como os usuários precisam vê-los. Isso pode ser cada
segundo, minuto, hora, dia, semana ou mês dependendo do processo de negócios, de sua
volatilidade e de quão crítico ele é para a empresa. Entretanto, a maioria dos elementos de
um dashboard é a tua lizada intradiariamente, com a latência medida em minutos ou horas.
Em geral, dashboards exibem informações visua lmente, usando diagramas ou gráficos
simples, como contadores e medidores. Entretanto, os gráficos do dashboard geralmente
são atualizados no local, fazendo o gráfico "piscar" ou mudar de forma dinâmica. Ironica-
mente, as pessoas que mon itoram processos operacionais costumam achar o gla,nour visual
distrativo e preferem visualizar os dados em seu formato o riginal, como números ou texto,
talvez acompanh ados de gráficos visuais.
TABELA 1-6 Comparando características

Característica Dashboard Scorecard
Finalidade Mede o desempenho Registra o progresso
Usuários Supervisores, especialistas Executivos, gerentes e luncionários
Atualizações Tempo certo Instantâneos periódicos
Dados Eventos Resumos
Exibição Gráficos visuais, dados não trabalhados Gráficos visuais, comentários
4
? W. \V. Eckerson, Performance Dashboards: Measudng, Monitoring and Managing )'our Business, Ho·
boken, NJ: \Viley, 2006, p. 293, 295. O Capítulo 12 apresenta uma excelente abordagem para criar relas de
dashboards.
?J lbid., p. 13.
Scorecards: Scorecards, por o utro lado, parecem ma is d iagramas de desempenho

usados para acompanhar o p rogresso em direção a metas e objetivos. Os scorecards nor-
malmente exibem representação mensais de dados resumidos para executivos da empre-
sa que acompan ham objetivos estratégicos e de longo prazo, ou representações diárias
e semanais de dados para gerentes que precisam registrar o progresso de seu grupo o u
projeto a caminho do cumprimento de seus objetivos e metas. Em ambos os casos, os
dados são bastante resumidos, de modo que os usuários possam ver sua situação de
desempenho rapidamente.
Assim como os dashboards, os scorecards fazem uso de diagramas e gráficos visuais
para indicar o estado de desempenho, tendências e variância em relação às metas. Quanto
ma is alto os usuários estiverem na hierarquia organizacional, ma is eles irão preferir ver o
desempenho visua lmente codificado. Entretanto, a maioria dos scorecards também con-
tém (ou deveriam conter) uma grande quantidade de comentários textua is q ue interpre-
tam os resultados de desempenho, descrevem as medidas tomadas e preveem resultados
futuros.
Resumo: No final das contas, não importa realmente se você usa o termo dashboard o u
scorecard, contanto que a ferramenta ajude a fazer os usuários e as organizações se concen-
trarem no que realmente importa. Tanto os dashboards q ua nto os scorecards precisam exi-
bir informações críticas sobre o desempenho em uma única tela, de modo que os usuários
possam monitorar os resultados em um relance.
Embora os termos sejam usados indistinta mente, a maioria dos gerentes de proje-
to perefe usar dashboards e/ou relatório de dashboard. Eckerson define três tipos de
dashboards, como exibe a Tabela 1- 7 e a descrição a seguir.26
• Dashboards operacionais monitoram os processos operacionais cent rais e são
usados primordia lmente por t rabalhadores da linha de frente e seus supervisores
que lidam di retamente co1n cl ientes o u gerenciam a criação e a entrega de produ-
tos e serviços organ izacionais. Os dashboards operaciona is exibem informações
levemente resumidas. Por exemplo, um comercia nte on-line pode acompa nha r
as transações no nível do produto em vez de no nível do cl iente. Além d isso, a
maio ria das métricas em um dashboard operaciona l é atual izada intradiaria1nente,
var iando de minutos a ho ras, dependendo da aplicação. Consequentemente, os
dashboards operacionais enfatizam o 1nonitora1nento ma is do que a anál ise e o
gerencia mento.
• Dashboards táticos acompanham processos e projetos departamenta is que seja1n
de interesse de um segmento da organização ou de um grupo li1nitado de pessoas.
Os gerentes e ana listas usam dashboards táticos pa ra compa rar o desempenho de
suas áreas ou projetos, pl anos orçamenta is, previsões ou os resultados do último
TABELA 1-7 Três tipos de dashboards de desempenho
Operacional Tático Estratégico

Finalidade Monitora operações Mede o progresso Executa a estratégia
Usuários Supervisores, especia- Gerentes, analistas Executivos, gerentes e fun-
tistas cionários
Escopo Operacional Departamental Toda a empresa
Informações Detalhadas Detalhadas/resumidas Detalhadas/resumidas
Atualizações lntradiariamente Diariamente/semanalmente Diariamente/semanalmente
~nfase Monitoramento Análise Gerenciamento
26
Jbíd., p. 17-18.
período. Por exe1nplo, um projeto para reduzir o número de erros no banco de da-
dos de um cliente pode usar um dashboard tático para exibir, 1non itorar e analisar
o progresso durante os 12 meses anteriores até, em 2007, ter atingido 99,9'% de
itens não defeituosos nos dados do cliente.
• Dashboards estratégicos 1non itora1n a execução de objetivos estratégicos e 1nui-
tas vezes são imple1nentados usando a abordagem de ind icadores ba lanceados
de desempenho (balanced scorecards), embora a gestão da qualidade total, o Seis
Sigma e outras metodologias ta 1nbém seja,n util izadas. O objetivo de u1n dashbo-
ard est ratégico é a linhar a organização e1n torno de objetivos est ratégicos e fazer
cada grupo caminhar na mesma direção. Para ta l, as organizações implementam
scorecards persona lizados para e.ada grupo da organização e, às vezes, para e.ada
indivíduo també1n. Esses scorecards "etn cascata", que normalmente são atua-
lizados semanal ou mensalmente, dão aos executivos uma ferramenta poderosa
para co1nun icar estratégias, obter maior visibilidade nas operações e identificar
os principais direcionadores de dese1npenho e valor de negócio. Os dashboards
estratégicos enfatizam o gerenciamento mais do que o 1non itoramento e a aná lise.
Há três passos críticos que precisan1 ser considerados ao usar os dashboards: (1) o
público-alvo do dashboard, (2) o tipo de dashboard a ser usado e (3) a frequência con1
que os dados serão atual izados. Alguns dashboards de projetos se concentram nos indi-
cadores-chave de desen1penho que faze1n parte da n1ensuração do va lor agregado. Es-
ses dashboards pode1n precisar ser atualizados diária ou se1nanalmente. Os dashboards
relacionados à saúde financeira da empresa poden1 ser atualizados sen1anal ou trin1es-
tralmente. As Figuras 1-7 e 1-8 mostram o tipo de informação que seria acompanhada
27
se1nanal ou trimestralmente para verificar a saúde financeira corporativa.
1.10 Indicadores-chave de desempenho

Na maioria das vezes, os itens que aparecem nos dashboards são elementos que tan-
to os clientes quanto os gerentes de projeto acompanham. Esses itens são chamados
de indicadores-chave de dese1npenho (KPls), como discutidos anteriormente. Segundo
Eckerson:28
Um KPI é uma métrica que mede quão bem uma organização o u um indivíduo realiza uma
atividade o peracional, tática ou estratégica crucial para o sucesso atual e futuro da organi-
zação.
Algu1nas pessoas confundem os KPls e os indicadores orientadores. Os indicado-
res orientadores são KPls que medem co1no o t rabalho que está sendo real izado hoje
afetará o futuro.
Os KP!s são componentes cruciais de todos os sistemas de 1nensuração de valor
agregado. A variância de custos, a variância de prazos, o índ ice de desempenho de
prazos, o índice de desempenho de preços e a duração/custo na conclusão são KP!s,
mas não são chamados dessa forma. A necessidade desses KP!s é siinples: tudo o que é
medido é realizado! Se o objetivo de um sistema de mensuração de desempenho é me-
lhorar a eficácia e a eficiência, então o KPI te1n de refletir fatores controláveis. Não faz
" J. Alexander, Performa11ce Dashboards and Anal)•Sis for Value Creatio11, Hoboken, NJ: \Viley, 2007, p.
87- 88. Reproduzido com permissão da John Wiley & Sons.
23
W. Eckerson, Performanc.e Dashl,oards: Measuriug.# Monitoring and Ma11agi11g Your Business, Hoboken,
NJ: \Viley, 2006, p. 294.
Previsibilidade
% Crescimento da receita Pendências Oo desempenho Modelo operacional HeaO Count
$150 o Oislodls•toshs
o FaDlade Olle~ao C 0e~9olSC0fflP&0 - PI~ - - - RIN1
4 An1 a Otl!Pt$.1$9'QiH ;ônri,lr.,1'4$
""' C Aa:. ld(f.illd'I W.dUSCtU C ~ 16.0 • t.:ro<iiera:klnal
a fia: . ~1*11 Vfr$USCtUchlno
- $134 Â
.,
100 1m 1225,
"'"
20'\ ..
fl)J)
-
-
>- >-
,.;;-
$12S
$117 DD '°10 1.,.
,s,.
~....., -
~ 50.0
-
>- >- -
- so; 1: 1190_
ºº
>- >- $100 .g 40
""'... "' "' "' "' .,.,
"'"
.,,, -o,os>-mos>- -ocos
>- >-
o:m 1.175
.,o
-
3U 10
o 1150 .__..__..,__ _.__~,__, 'O
°" 04CM 010S 020S 030S 04C6 0404 030S $1S 0404 o,os 020S OOOS 040S 0,0,
º"' °"" °""' °""01(6 020S 030S 040S
f
Clcio Oe caixa operacional Desempenho Oo escrlt6rlo Oe QuallO.Oe LlnearlOaOe Oa receita Eficácia Oo P&D o
~
Oesenvolvlmento Oe tecnologia (DTD)
't.de Wndas de
100%
150
"" ~---------, 1.1u ~ ~
3
) - -- Ot,jetvo
,... 1 .11.0 =
·...~
119 m i- - - - - - - - - - - - - - - - 1 "O
~
12S 11$ tt><t. 86'-
,......, ,......, 83'%
m 1K
r-, r-, = 1-- - - ~ ~~...-1 0,9
....
.---, MO
µ?,
"'" -""' -'-
""
24%
;:.:.:e
m
(D
:,
,! 100
11$
il '°"
~
;1 "" 71% 1--1

0.7 ~ ,...
-
,0,74
-
.---, a.
~
a.
.,
o
'""
:[E 888~
7$
Ih
: 11 1. 1 1. 1 1. 1 1. 1 1, . 3
50 (),CO,I 0,0$ 02('6 030$ OU,)$ 60% OICM 010S o:m 030S 04(6
6K .
040,I
.
o,os .
02('6
..
030S 040S
.
04>! 010$ 02('6 030$ 040S °" 0404 010$ <»OS 030$ 040S
(D
=r
o
Figura 1- 7 Dashboards típicos de saúde financeira da empresa. m
Ih
"O
iil-
"'o ·
!l:
...,
w
~
G)
$
Coo,panhla XYZ
04' OS Semana n'7 de 13/Sff• de 04
.,,
!!l
o
{$ em milhões) e.
$
V, $ $50 Reservas DTD 'O
Renrvas Semana n.•
0.7
o~
0.4
Unidade
BU
BU
BU
BU
1
2
3
4
DTD
15.0
0.9
4b
1.7
Pro•são
30.0
1.0
6.0
4.7
Obtido
50%
89
67
37
Requerido
---.5]'
0.1
2n
2.9
$40
~o ,..............................................,
:,; $20 .........
~ $10 .
$0
j 1 .. . 1
1.. .......
......... ::J:
......... •IU2
.2.
~
U>
o.o 01t'ler 0.1 - (D.1)
- OTD I PrMslo •OU' 1

iT To<... 21.7 4 1.7 5211 $20b
V,
Receitas Semana n.• Unidade DTD Provisão Ob!ido Renrva Necessário
2n BU 1 Tã]' 78% 5.0 10.00 ~g ,... ... . Recolla DTD
j ... ~
?llb
0.4 BU 2 3.0 5.0 80 1,0 1,00 :E $30 .............................................. ......... an,.......
1,00 ~ $20 .......... .........
on BU 3 3b 6b 50 2.0
2.6 BU 4 3.0 7.0 43 1.0 3.00 $$0
10 ........ , r:::::·..............
.... j
P ......... •IU2
•BU 1
OU~r
5b To<... 22.0 46b 48% 9,0 15b OTD Prewsão
Coleçlies recebivels Semana

Real
1 2 3
• 5
$40
Conlasa receberawmuladas
~~~1 ~:1~
(Cumu•11vo1 1.0 5.0 19.0
Alvo 4,0 9,0 17,0 28,0 35,0
$ 10 ................. .................................... ..
$0 1 2 3 4 5
Semanas
Rendimento do processo Dia 1 2 3

• 5
=1 o [rj'j·u·:~ nlE;;
77% 80% 8 111 6811 8211
70% ... ....... ...... D

f p
60% . ' 2 3 4 5
Dôas
Figura 1-8 Dashboards típicos de saúde financeira da empresa.

senti do medir u1na atividade se os usuários não podem mudar o resultado. Eckerson
29
identifica 12 características de KP!s eficientes:
• Alinhados: Os KP!s estão se1npre al inhados com a est ratégia e os objetivos cor-
porativos.
• Próprios. Todo KPI é "próprio" de um indivíduo ou grupo no lado empresarial
(ou do projeto) que é responsável por seu resultado.
• Preditivos. Os KP!s medem os determ inantes de valor empresaria l [ou do projeto].
Assim, eles são os indicadores orientadores do desempenho desejado pela organi-
zaçao.
• Acionáveis. Os KP!s são populados com dados a tualizados e acionáveis, de modo
que os usuários possam intervir no sentido de melhorar o desempenho antes que
seja tarde demais.
• Pouco ntttnerosos. Os KP!s devem concentrar os usuários e1n algumas poucas ta-
refas de alto valor, e não dispersar sua atenção e energia em itens demais.
• Fáceis de co,npreender. Os KP!s devem ser diretos e fáceis de compreender, e não
baseados em índices complexos que os usuários não sabem como influenciar di-
retamente.
• Equilibrados e conectados. Os KP!s devem equ ilibrar e reforçar uns aos outros, e
não solapar uns aos outros e subotimizar processos.
• Estimttlam m11danças. O ato de medir um KPI deve estimular uma reação em ca-
deia de mudanças positivas na organização (ou projeto), principalmente quando é
monito rada pelo CEO (ou cl ientes ou patrocinadores).
• Padronizados. Os KP!s se baseia1n em definições, regras e cálcu los-padrão de
modo que eles possa1n ser integrados em dashboards por toda a organização.
• Direcionados a contextos. Os KP!s colocam o desempenho em contexto aplicando
alvos e limites a ele, de modo que os usuários possam aval iar seu progresso co1n
o passar do tempo.
• Reforçados com incentivos. As organizações podem amplia r o impacto dos KP!s
atrelando compensações ou incentivos a eles. Entretanto, eles devem fazê-lo co1n
cuidado, aplicando incentivos apenas a KP!s bem compreendidos e estáveis.
• Relevantes. Os KP!s perdem de seu impacto com o passar do tempo, então, têm de
ser periodicamente revisados e revigorados.
Há vários motivos pelos quais o uso de KP!s geralmente não tem êxito em proje-
tos, dentre eles:
• As pessoas acreditam que o aco1npanhamento de um KPI term ina no gerente de
pri1neiro nível hierárquico.
• As ações necessárias para regu lar indicações desfavoráveis estão alé1n do controle
dos funcionários que faze1n o monitoramento ou acompanha1nento.
• Os KP!s não estão relacionados às ações ou ao tr abal ho dos funcionários que
faze1n o monitoramento.
• O ritmo de mudança dos KP!s é lento demais, tornando-os, dessa forma, inade-
quados para gerenciar o trabalho cotidiano dos funcionários.
• As ações necessárias para corrigir KP!s desfavoráveis levam tempo demais.
• A 1nensuração dos KP!s não fornece dados ou informações suficientes para torná-
-los úteis.
• A etnpresa identifica KP!s demais, a ponto de a confusão reinar entre as pessoas
que real izam as 1nensurações.
" Ibid., p. 201 .

Há a lguns anos, as únicas métr icas que algumas e1npresas utilizavam eram aquelas
identificadas como parte de um sistema de 1nensur ação de va lor agregado. As mét ricas
gera lmente se concentr avam apenas em prazo e custo e negl igenciava1n-se aquelas rela-
cionadas ao sucesso da e1npresa versus sucesso do projeto. Portanto, as métricas eram
as mesmas em cada projeto e as mesmas para cada fase do ciclo de vida . Hoje, podem
mudar de uma fase para outra e de projeto para projeto. A dificuldade, obviamente,
é decidir qua is utilizar. Deve-se tomar cuidado para que as métricas estabelecidas não
acabem por compara r "maçãs com la ranjas". Felizmente, há vários bons livros no
mercado que podem auxiliar na identificação apropriada de métricas significativas. 30
Selecionar os KPis corretos é fundamental. Pelo fato de u1n KPI ser uma forma de
mensuração, algumas pessoas acreditam que os KP!s devem ser atribuídos so1nente a
elementos tangíveis. Portanto, mu itos elementos intangíveis que seriam acompanha-
dos pelos KPis nunca são observados porque alguém acredita que tal mensuração
é impossível. Qualquer coisa pode ser med ida, independentemente do que a lgumas
pessoas pensam. Segundo Hubbard: 31
• Mensuração é um conjunto de observações que reduz a incerteza em que os resul-
tados são expressos como uma quantidade.
• Uma 1nera redução da incerteza, e não necessariamente sua eli1ninação, é suficien-
te para uma mensuração.
Portanto, podem-se estabelecer KPis mesmo para intangíveis, co1no os que serão
d iscutidos posteriormente, neste livro, no Capít ulo 16. Hubbard acredita que cinco
32
perguntas precisam ser feitas antes de estabelecermos KPis para mensuração:
• Qual é a decisão a que este (KPI) deve da r suporte?
• O que realmente está sendo medido (pelo KPI)?
• Qual é a importância do que está sendo med ido (e do KPI) para a decisão a ser
tomada?
• O que você sabe sobre ele agora?
• Qual é o va lor de continuar a medi-lo?
Hubbard também identifica quatro rressupostos úteis para mensuração que de-
3
ve1n ser considerados ao selecionar KP!s:
• Seu problema (ao selecionar um KPI) não é tão único quanto você pensa
• Você possui ma is dados do que pensa
• Você precisa de menos dados do que pensa
• Há uma mensuração úti l que é muito mais simples do que você pensa
Selecionar os KP!s corretos é essencial. Na n1aioria dos projetos, são necessá-
rios apenas alguns KP!s. As vezes, parecen1os selecionar KP!s demais e acabamos
com mais KP!s que nos fornecem pouco ou nenhum valor de informação, e o KPI
acaba sendo desnecessá rio ou inútil em nos auxiliar na ton1ada de decisões de un1
proieto.
30
Três livros que fornecem exemplos de identificação de métricas são: P. F. Rad e G. Levin, Metrics for Pro•
jec.t Management, Vienna, VA: Management Concepts, 2006; .M. Schnappere S. Rollins, Va/ue-Based Metrics
for lmproving Results, Fc. lauderdale, Fl: J. Ross Publishing, 2006; e D. \V. Hubbard, Horu To Measure
A1t)'thi11g; Hoboken, NJ: Wiley, 2007.
31
D. \V. Hubbard, HoruTo Meosure An)'thi11g, Hoboken, NJ: \Viley, 2007, p. 21.
32
lbid, p. 43.
" lbid, p. 31.
Às vezes, as empresas acreditam que as medi das que selecionar am são KPis qua n-
do, na verdade, são formas de 1nedidas de desem penho, mas não necessaria mente
34
KPis. David Parmenter discute três tipos de 1nedidas de desempenho:
• Ind icadores-chave de resultados (KRis, key results indicators) lhe d izem como
você se saiu em uma perspectiva
• Indicadores de desempenho (Pis, performance indicators) lhe dizem o que fazer
• KPis lhe dizem o que fazer para aumentar o desempenho drastica1nente
. 35
Parmenter acre d 1ta que:
O sucesso de uma estratégia de mudança depende muito de como ela é introduzida e im-
plementada, e m vez de ser algum mérito da estratégia p ropriamente d ita. O s ucesso no
desenvolvimento e na utilização de indicadores-chave de desempenho (KP!s) no trabalho é
determinado pela presença ou a usência de quatro peças fundamentais:
• Parceria com a equipe, sindicatos, p rincipais fornecedores e principais cl ientes
• Transferência de poder para a linha de frente da empresa
• Integração de atividades de mensuração, relatórios e melhorias do desempenh o
• Conexão entre as medidas de desempenho e a estratégia
Em u1n ambiente de projetos, as medidas de desempenho podem va riar de um pro -
jeto para o outro e de uma fase para out ra. A identificação dessas med idas é realizada
pela equipe do projeto, inc.luindo seu patr ocinador. As partes envolvidas no projeto
tam bém podem exercer influência. As 1nedidas de desempenho corporativo têm u1na
orientação fortemente fi nancera e podetn passar por mu ito poucas 1nudanças ao longo
do tempo. As medidas indicam a saúde fi nancei ra da corporação.
Estabelecer medidas de desempenho corporativo relacionadas a iniciativas estraté-
gicas ou o utras atividades simila res tem de ser tratado como um projeto e1n si, e ter o
suporte da equipe de gerência sênior (SMT, senior rnanagement team).
A atitude da SMT é crucia l - qualquer falta de compreensão, compromisso e prio-
rização desse importante processo dificultará seu sucesso. É comum que a equipe do
projeto e a SMT encaix em um projeto de KPI em torno de outras ativi dades concor-
rentes e menos importantes.
A SMT precisa estar cotnprometida co1n o projeto de KPI, para fazer com que
ele desça a té os níveis mais ba ixos da hiera rquia da organização. Se implementado de
forma apropriada, o projeto de KPI irá criar um ambiente d inâmico. Antes de poder
fazer isso, a SMT tetn de estar convencida do conceito. Isso fa rá com que o projeto de
KPI seja t ratado co1n prioridade máxitn a, o q ue pode significa r que a SMT pennita
que essas atividades concorrentes distratoras e menos importantes resolvam-se por si
36
mesmas.
1.11 Passo 3: validar a melhor prática

Anteriormente, afi rma 1nos que a busca de uma melhor prática é rea lizada pelo gerente
do pro jeto, por sua equipe, pelo gerente funcional e/ou possivelmente por um faci li-
tador profissional trei nado em como realizar o debriefing de uma equipe de projeto e
identificar as melhores práticas. Q ualquer dessas pessoas ou todas elas têm de acredi-
tar que aqui lo que descobrira m é, de fato, uma melhor prática. Q uando os gerentes de
.w D. Parmemer~ Key Perfom1011a lndic.ators, Hoboken, NJ: \-Viley, 2007, p. 1.

;.s Ibid., p. 19.
u. Ibid., p. 27. O Capítulo 5 desce livro possui temp/ates exce lentes para relatórios de KPls.
projeto são bastante ativos em um projeto, é esperado que eles tomem a decisão final
sobre o que constitui uma melhor prática. Segu ndo um porta-voz da AT &T, a respon-
sabili dade por detenninar o que é uma melhor prática está nas mãos do:
Gerente de projeto, que mostra como aquela prática teve um impacto positivo em seu pro-
Jeto.
Embora isso seja bastante comum, há outros 1nétodos de val idação que podem
envolver um número significativo de pessoas. Às vezes, os gerentes de projeto podem
ser retirados de onde o trabalho está se desenvolvendo e podem não estar fam iliariza-
dos com as atividades que poderia1n levar à identi ficação de uma melhor prática. As
empresas que possuem um PMO dependem fortemente do suporte desse escritório,
pois as melhores práticas aprovadas são, posteriormente, incorporadas à metodologia,
e o PMO normalmente é o "guardião" da metodologia. Segundo Heidi Wurtz, VP,
Solutions Center da max!T-VCS:
O processo de manutenção e a tua lização da metodologia é definido hoje como uma função
de nosso Solutions Center, q ue oferece suporte à max!T-VCS integrada. A visão é gerenciar e
manter centralmente todas as metodologias, das habilidades centrais como a gestão de pro-
jetos, adoção por clínicos, etc., às metodologias especializadas como o ICD-10 e o Health
Analytics. Implementar novas tecnologias e processos (p. ex.: ICD-10) pode ter um impacto
fundamental sobre todos os processos clínicos e de ciclo de receitas de uma organização.
Fracassos de projetos podem resulta r em problemas de conformidade, atrasos e negações
em solicitações de pagamentos e declín ios significativos na produtividade. Agora, mais do
q ue nunca, é indispensável que as organizações tenham uma forte estrutura de projeto im-
plementada para servir de suporte a essa transformação. A maxIT-VCS se esforça para pre-
encher a lacuna entre os compromissos assumidos por fornecedores de TI da área de saúde
q uanto aos seus deliverab/es e a equipe existente por meio do desenvolvimento de soluções
adaptadas às necessidades da organização. Nosso processo de manutenção de metodologia
permite que o envolvimento de especialistas garanta a cons istência nas atualizações e no
gerenciamento de mudanças de metodologias. O plano é identificar um pequeno grupo de
especialistas para cada metodologia e convocá-los periodicamente para revisar conteúdos, o
(eedback dos usuários, as melhores práticas do setor, lições aprendidas internamente e con-
tribuições de novos materiais. Esse órgão tomará decisões quanto a atualizações, remoções,
s ubstituições o u adições às ferramentas de inclusão de conteúdos metodológicos. Almeja-
mos um componente interativo da metodologia baseada na web para facilitar o (eedback e
contribuições de usuários em campo.
Uma vez que a gerênci a da organização afetada in icia lmente tenha aprovado a
nova melhor prática, ela é encaminha da ao PMO ou à gerência de processos para
validação e, então, institucionalização. O PMO pode ter u1n conjunto separado de
listas de conferência para validar a melhor prática proposta. O PMO tatnbém precisa
definir se a melhor prática é ou não de propriedade exclusiva da empresa, pois isso
irá determ inar onde a melhor prática será a rmazenada e se será ou não comparti lhada
com clientes.
A melhor prática pode ser colocada na bibl ioteca de melhores práticas da empresa
ou, se apropriado, incorporada diretamente à lista de conferência de passagens de fa-
ses da e1npresa. De acordo com a complexidade do processo dessa lista de conferência
e da metodologia de gestão de projetos da empresa, o processo de incorporação pode
ocorrer imediata ou tritnestrahnente.
Segundo Chuck Millhollan, diretor de gerenciamento de programas da Churchill
Do,vns, Inc.:
Não rotulamos nossos processos o u métodos de " melhores práticas". Simplesmente apren-
demos com nossos erros e garantimos q ue esse aprendizado seja incorporado à nossa meto-
dologia, processos, templates, etc.
Algumas o rganizações possuem co1nitês não afi liados ao PMO, que têtn como
principa l função a avaliação de possíveis melhores práticas. Qualquer pessoa da em-
presa pode fornecer dados de possíveis melhores práticas ao comitê, e este rea liza a
análise. Os gerentes de projeto podem ser membros do comitê. Outras organizações
usam o PMO para rea lizar esse t rabalho. Esses comitês e o PMO na maioria das vezes
se reporta tn aos níveis sênior da gerência.
A 4• edição do G11ia PJ\1BOK® enfatiza a Ílnportância de envolver as partes inte-
ressadas e1n projetos. Esse envolvimento pode incluir também a decisão fina l sobre se
uma descoberta se trata ou não de uma 1nelhor prática. Segundo Chuck Millhollan,
diretor de gerenciamento de programas, Churchill Downs, Inc.:
Em última análise, a decisão final está nas mãos das partes interessadas, tanto internas
quanto externas. Uma outra maneira de colocar isso é que o PMO não toma a decisão sobre
se um método ou processo funciona. Procuramos ativamente obter (eedback das partes
interessadas em nossos projetos e usamos suas contribuições para determinar se nossos
processos são "melhores práticas" para a Churchill Downs lnc. As melhores práticas espe-
cíficas identificadas anteriormente, entre outras, foram aceitas fora do PMO como práticas
geralmente aceitas.
Um outro exem~lo de envolvimento das partes interessadas é dado por Enrique
Sevilla Molina, PMP , antigo diretor corporativo do PMO, Jndra:
Uma decisão é tomada pelo PN!O corporativo responsável, o gerente da unidade de negó-
cios, a autoridade do PMO loca l ou mesmo a autoridade competente, se for o caso. De-
pende do assunto e do escopo da tarefa. Algumas das melhores práticas de gerenciamento
foram estabelecidas no nível corporativo e incorporadas à metodologia de GP. Muitas delas
também foram incorporadas aos sistemas de informação de gestão de projetos e às ferra-
mentas de GP.
Aval iar se a lgo é ou não uma melhor prática não leva tempo, mas é un1a tarefa
complexa. O simples fato de a lguén1 acreditar que aquilo que está fazendo é uma
n1elhor prática não sign ifica que o seja de fato. Alguns PMOs estão atua ln1ente de-
senvolvendo templates e critérios para determinar se un1a atividade pode ou não se
qualificar con10 melhor prática. Alguns itens que estão incluídos no template poden1:
• ser transferíveis a muitos projetos;
• permitir u1n desempenho eficaz e eficiente que pode ser medido (i.e., pode servir
como uma mét rica);
• perm itir a mensuração de uma possível lucratividade usando a melhor prática
• possibilitar que uma atividade seja concluída em menos tempo e a um custo mais
baixo;
• agregar valor tanto para a empresa quanto para o cliente;
• ser capazes de nos diferenciar dos outros.
Uma empresa apresentou duas características exclusivas e1n seu template de me-
lhores práticas:
• Ajudar a evitar fracassos
• No caso de crise, ajudar a sa ir da situação crítica
Os executivos precisam perceber que essas práticas são, na verdade, propriedade
intelectual que beneficia toda a organização. Se a melhor prática puder ser quanti-
ficada, então normaln1ente é n1ais fácil convencer a gerência sênior quanto ao seu
valor.
1.12 Passo 4: níveis das melhores práticas

Como afirmamos anteriormente, as melhores práticas vêm da transferência de conhe-
cimento e podetn ser descobertas em qualquer lugar dentro ou fora de sua organiza-
ção. Isso é exibido na Figura 1-9.
As empresas que mantêm bibl iotecas com um grande número de melhores prá-
ticas podem criar níveis para elas. A Figura 1- 10 mostra vários desses níveis. Cada
nível pode ter categorias internas. O 1nais baixo é o nível dos padrões profissionais,
que incluiriam aqueles definidos pelo PMI. O nível de padrões profissionais contém o
maior número de melhores práticas, mas elas são de uma natureza mais gera l do que
específica e têm um baixo nível de complexidade.
O nível de padrões do setor identificaria melhores práticas relacionadas ao desem-
penho dentro do setor. O setor auto1notivo estabeleceu padrões e 1nelhores práticas
específicas ao seu próprio setor.
À medida que progredimos para as 1nelhores práticas individuais na Figura 1- 10,
a cotnplexidade das melhores práticas passa de aplicações gerais a muito específicas
e, como esperado, a quantidade de melhores práticas vai diminuindo. Um exemplo de
u1na melhor prática em cada nível pode ser (do geral ao específico):
• Padrões profissionais: Preparação e uso de um plano de gestão de riscos, incluindo
tetnplates, diretrizes, formulários e listas de conferência.
• Específicas do setor: O p lano de gestão de riscos inclui as melhores práticas do
setor como a melhor maneira de fazer a transição da engenharia à produção.
MELHORIA CONTINUA
Novos conhecimentos
1
o
Conhecimentos internos
1 1
~
Conhecimentos externos
1
• Lições aprendidas • Benchmarking
• Experiência • Publicações
• História • Seminários e simpósios
• Bancos de dados internos • Bancos de dados externos
Figura 1- 9 Transferência de conhecimento.
Alta
l Individuais
_. ....
.;,.._---
Especificas de projetos
Específicas da empresa
Padrões do setor
Padrões profissionais (PMI)

Baixa
Quantidade -
Figura 1- 10 Níveis de melhores práticas.

• Específicas da empresa: O plano de gestão de riscos identifica os papéis e interações

entre grupos de engenharia, produção e garantia da qualidade durante a transição.
• Específicas do projeto: O plano de gestão de riscos identifica os papéis e as intera-
ções dos grupos afetados à medida que eles se relacionam a um produto ou serviço
específico para um cliente.
• Individuais: O plano de gestão de riscos identifica os papéis e interações de gru-
pos afetados de acordo con1 sua tolerância para riscos, possivelmente por meio
do uso de un1a matriz de atribuição de responsabi lidades preparada pelo gerente
do projeto.
As melhores práticas pode1n ser ext remamente úteis durante as atividades de pla-
nejamento estratégico. Como mostra a Figura 1- 11, os dois níveis 1na is baixos pode1n
ser ma is úteis para a formulação da estratégia de gestão de projeto enquanto os três
níveis mais altos são 1nais apropriados para a execução ou implementação de u1na
estratégia.
Nen1 todas as empresas n1antêm un1a biblioteca formal de n1elhores práticas. Em
algumas, quando uma melhor prática é identificada e validada, ela é in1ediatamente
colocada no processo de análise de passagens de fases ou na metodologia de gestão
de projeto. Nesse caso, a metodolojia proprian1ente dita torna-se uma melhor prá-
tica. Enrique Sevilla Molina, PMP , antigo diretor corporativo do PMO da lndra,
afirma:
Na verdade, nossa metodologia de gestão de projetos constitui nossa biblioteca estabelecida
de melhores práticas aplicáveis a todos os projetos da empresa. Existem outras bibliotecas
de melhores práticas em diferentes unidades de negócios. Há, por exemplo, instruções deta-
lhadas para a preparação de propostas ou para fins de estimação de custos e prazos, que são
apropriadas para a área de negócios ou área operacional específicas.
Quando questionado sobre quantas melhores práticas são mantidas na lndra, En-
nque comentou:
• É d ifícil dizer, devido ao assunto propriamente dito e à mu ltiplicidade de áreas de ne-
gócios na empresa. Se considerarmos nossa metodologia de GP como um conjunto de
;'melhores práticas", seria d ifícil contar cada melhor prática incluída.
• Além de nosso Project Ma11ageme11t Methodo/ogy Manual, de publicação interna, te-
mos, por exemplo, guias específicos no nível corporativo para a elaboração da estrutura
analítica do projeto (EAP, ou WBS, do inglês u1ork breakdo,un struct11re), gestão de
risco do projeto e mensuração do desempenho do projeto baseado em técnicas de valor
agregado. Temos também instruções específicas para a preparação de propostas, esti-
mação de custos e até mesmo regras e formatos detalhados de elaboração da estrutura
analítica do projeto para diferentes níveis de unidades de negócios.
Alta
i Individuais
__.. ...........
Especfficas de projetos
Execução da
t
estratégia
Espectticas da empresa
Formulação
Padrões do setor da estraté ia
Baixa
Quantidade ---+
Figura 1- 11 Utilidade das melhores práticas.

1.13 Passo 5: gerenciamento das melhores práticas

Há três participantes envolvidos no gerenciamento das melhores práticas:
• O proprietário da melhor prática
• OPMO
• O administrador da bibl ioteca de melhores práticas, que pode residir no PMO
O proprietário da melhor prática, que norn1a ln1ente reside na área funcional,
tem a responsabilidade de n1anter a integridade da melhor prática. Norma ln1ente é
um título não remunerado e não oficia l, mas é um símbolo de prestígio; portanto, o
proprietário da n1elhor prática tenta melhorá-la e mantê-la viva pelo máximo tempo
possível.
O PMO norma lmente tem a autoridade final sobre as melhores práticas e toma a
decisão fina l quanto a onde colocar a melhor prática, quem deve ter permissão para
vê-la, com que frequência ela deve ser revisada ou reva lidada e quando ela deve ser
removida de serviço.
O adn1inistrador da b iblioteca é n1eramente o guardião da n1elhor prática e
pode acon1panhar con1 que frequência as pessoas revisan1 a melhor prática, su-
pondo que ela esteja prontamente acessível na biblioteca de melhores práticas. O
adn1inistrador da biblioteca pode não ter un1a boa compreensão de cada uma das
melhores práticas e pode não ter qualquer direito de voto sobre quando eliminar
un1a n1elhor prática.
1.14 Passo 6: revalidando melhores práticas

As n1elhores práticas não duran1 para sempre. Por estarem diretamente relacionadas
à definição de sucesso de projetos de un1a empresa, a definição de uma n1elhor prá-
tica pode mudar e se desatualizar à medida que a definição de sucesso mudar. Por-
tanto, as melhores práticas tên1 de ser revisadas periodicamente. A pergunta crucial
é: "Com que frequência elas devem ser revisadas?". A resposta para essa pergunta
depende de quantas melhores práticas há na biblioteca. Algun1as empresas n1antên1
apenas algun1as, enquanto empresas n1u ltinacionais de grande porte podem ter n1 i-
lhares de cl ientes e n1anter centenas de n1elhores práticas en1 suas bibliotecas. Se a
en1presa vende produtos, a lém de serviços, a bibl ioteca pode conter melhores práti-
cas tanto relacionadas a produtos quanto relacionadas a processos.
Os dois exe1nplos a seguir ilust ram a necessidade de revisar as melhores práticas.
• Quando uma prática é indicada e aprovada co1no melhor prática, é sancionada
apenas até o ciclo de revisão anual segu inte. Co,n o passar do tempo, as 1nelho-
res práticas tende1n a perder seu va lor e a se tornar ineficientes se as deixarem
desatualizadas. (EDS)
• As melhores práticas são revisadas a cada quatro meses. As infonnações que en-
tram no processo de revisão inclue1n:
• Documentos relacionados às lições aprendidas de projetos concluídos nos qua-
tro últimos meses
• Feedback dos gerentes de projeto, arqu itetos e consultores
• Conhecimentos que especia listas (i.e., proprietários de melhores práticas) t ra-
zem para análise; isso inclu i informações levantadas tanto externa quanto in-
ternamente
• Os dados de relatórios e atividades da biblioteca de melhores práticas
Normahnente há trê.s tipos de decisões que podem ser totnadas durante o processo
de revisão:
• Manter a 1nelhor prática co1no está até o próximo p rocesso de revisão
• Atual izar a 1nelhor prática e continuar utilizando-a até o próxitno processo de
revisa o
• Retirar a melhor prática de serviço
1.15 Passo 7: o que fazer com uma melhor prática

Dada a definição de que utna tnelhor prática é uma atividade que leva a uma vanta-
gem competitiva sustentada, não é de se admirar que algumas empresas relutem etn
tornar suas mel ho res práticas conhecidas do público em geral. Portanto, o que uma
empresa deve fazer cotn suas tnelhore.s práticas se não torná-las públicas? As opções
disponíveis mais comuns incluem:
• Compartilhar o conhecimento apenas internamente: Isso é realizado usando a
int ranet da empresa para compartilhar informações cotn os funcioná rios. Pode
haver um grupo separado dentro da empresa que seja responsável pelo controle
das informações, talvez até mesmo o PMO. Nem todas as melhores práticas estão
disponíveis para todos os funcionários. Algumas melhores práticas podem ser pro-
tegidas por senha, como discutido abaixo.
• Escondidas de todos, exceto alguns poucos: Algumas empresas gastam enormes
somas na preparação de fo nnulários, diretrizes, te,nplates e listas de conferência
para a gestão de projetos. Esses docu1nentos são vistos tanto como informações
proprietárias da empresa quanto como melhores práticas e são fornecidos apenas
a alguns poucos funcionários que precisam tomar conhecimento deles. Exemplos
de melhores práticas "restritas" podetn ser formulários e te,nplates especializa-
dos para aprovação de projetos cujas informações podem ser dados financeiros
sensíveis para a empresa ou a posição da empresa em termos de lucratividade de
participação de mercado.
• Fazer propaganda da empresa para os clientes: Nessa abordagem, as empresas
podem desenvolver um panfleto de melhores práticas para promover suas rea li-
zações e podem também manter uma extensa biblioteca de melhores práticas que
seja compatilhada com seus cl ientes após a assinatura do contrato. Nesse caso, as
melhores práticas são vistas como armas competitivas.
A 1na ioria das empresas hoje utiliza aguma forma da biblioteca de 1nelhores práti-
cas. Segundo um porta-voz da AT&T:
A bibliote.ca de melhores práticas utiliza o aplicativo Sharepoint e é muito fácil de usar, tan-
to da perspectiva de envio quanto de busca. Qualquer gerente de projeto pode enviar uma
melhor prática a qualquer momento e pode buscar melhores práticas enviadas por o utros.
Embora as empresas colecionem melhores práticas, nem todas as melhores prá-
ticas são comparti lhadas fora da empresa, mesmo durante estudos de benchmarking,
em que se espera que todas as partes comparti lhem informações. Estudantes geral-
mente pergunta tn por que os livros didáticos não incluetn mais informações sobre
melhores práticas deta lhadas como formulários e templates. Uma empresa comentou
com o autor:
Devemos ter gasto pelo menos US$ l milhão nos últimos anos desenvolvendo um extenso
template sobre como avaliar os riscos associados à transição de um projeto da engenharia
para a produção. Nossa empresa não ficaria feliz em entregar esse template a todos que
q uiserem comprar um livro por US$85. Algumas melhores práticas são de conhecimento co-
mum, e certamente compartilharíamos essas informações. Mas vemos o te,nplate de riscos
de transição como um conhecimento confidencial, que não deve ser compartilhado.
1.16 Passo 8: comunicar as melhores práticas por

toda a empresa
A transferência de conhecimento é um dos maiores desafios enfrentados pelas cor-
porações. Quanto ma ior a corporação, maior o desafio. A situação se torna ai nda
mais complicada quando os loca is físicos da corporação são dispersos em diversos
continentes. Sem uma abordagem est ruturada para a transferência de conhecimento,
as corporações podem repetir erros e perder val iosas oportunidades. É necessário que
se desenvolvam 1nétodos de cola boração corporativa. A NXP encontrou uma maneira
de superar diversas dessas barreiras. Mark Gray, MBA, PMP~, Ph.D., a ntigo gerente
sênior de projetos na NXP Se1niconductor e hoje CEO da SigmaPM, discute essa abor-
dagem. Mark descreve-a da seguinte maneira: para plantar árvores, é preciso começar
com as sementes:
Um dos maiores problemas enfrentados pelos gerentes de projeto e suas organizações hoje é
descobrir a melhor maneira de transferir conhecimento de gerentes de projeto especial istas
(ou, pelo menos, experientes) para o resto da organização. Nluito já se escreveu sobre lições
ignoradas, bem como sobre lições aprendidas como um componente de valor agregado na
caixa de ferramentas da gestão de projetos. O que parece estar faltando é uma sólida abor-
dagem de como se transmitir conhecimentos (as partes identificadas, capturadas e a rmaze-
nadas são todas bem óbvias).
Na NXP, observamos que há muitas lições aprend idas durante projetos ou durante s ua
revisão, mas há muito pouca evidência de que essas lições esti vessem sendo vistas por outros
gerentes de projetos. Uma solução que implementamos foi usar o modelo de uma Comu -
nidade de Práticas (CoP, Comm1111ity o( Practice) descrita por \'(lenger'' em seu trabalho
sobre esse assunto. Usando a mesma ideia básica usada pela Shell em s uas plataformas de
perfuração o(f-shore, estabelecemos fóruns locais de "espe.cialistas" com a intenção espe.cí-
fica de criar uma arena em que os gerentes de projetos pudessem se sentir confortáveis em
compartilhar o q ue descobriram e aprenderam com seus projetos.
O processo propriamente dito é muito simples; lições são identificadas pelos gerentes
de projetos nas sessões de debrie(i11g de projetos ou na análise feita por colegas e são, então,
apresentadas ao fórum como um tipo de ;'história de guerra". É importante observar aq ui
q ue procuramos aprender tanto de incidentes bons quanto de ;'menos bons" . Em geral, isso
leva a um bom (e, às vezes, inflamado) debate sobre o tópico a partir do qual os participan-
tes podem extrair uma experiência genuína de aprendizagem. Os resultados são, obviamen-
te, de natureza um tanto qualitativa, então seria difícil dizer que temos melhorias mensurá-
veis daras como uma consequência direta dessas sessões. No entanto, vimos uma melhoria
generalizada no desempenho geral dos projetos desde que implementamos essa iniciativa .
Agora a parte difícil - construir e manter a CoP. Wenger fornece excelentes fundamentos
sobre como se construir CoPs, como a necessidade de ter uma boa equi pe central, o envolvi-
mento de executivos patrocinadores, resultados claros, regras gerais, etc. Ele também fala da
necessidade de um a lto nível de colaboração por parte da equipe central para criar e manter
o andamento da CoP. Já vimos isso na vida real e adicionamos nossos próprios ingredientes
específicos a essa receita:
37
E. Wenger, R. M.cDermocr e \V. M.. Snyder~ Odavar;ng Communit;es o/ Practk.e: A Cuide to Managing
Knowledge, Cambridge, M.A: Harvard Business School Press, Cambridge, MA, 2002.
• Comece com uma "semente" - você precisa de pelo menos uma figura de liderança mui-
to extrovertida e carismática. Procuramos pessoas que não sejam apenas especialistas
na áreas, mas que sejam quase fanáticas em sua dedicação ao desenvolvimento e ao
amadurecimento da gestão de projetos.
• Plante-a no lugar certo - você precisa garantir que a CoP não interfira excessivamente
com o tempo normal de trabalho o u pessoal. Geralmente, fazemos nossas sessões em
to m o do horário de almoço, oferecendo uma refeição.
• De vez em quando, é necessário ;'podar os galhos " da CoP para que ela cresça forte. Os
grupos podem se desenvolver em direções que não promovem realmente o tema central
da CoP e, nesse caso, é uma boa ideia arrancá-los para evitar dissoluções.
• Quando membros deixarem o grupo, não entre em pânico, é apenas uma questão sazo-
nal. As pessoas vêm e vão quando seu trabalho muda, a pressão de seus projetos muda,
etc. Elas voltarão...
• A CoP precisa produzir mais "sementes" que possam ser plantadas em outros lugares e,
assim, criar uma comunidade de comunidades interligadas. No caso da NXP, criamos
uma sólida equipe central nos últimos anos com comunidades ativas que compartilham
e aprendem umas com as outras em I Odiferentes locais em todo o mundo.
Não faz senti do assi milar as melhores práticas se os funcionários não as conhe-
cem. O problema, como identificamos acima, é como comun icar essas informações
aos funcionários, especialmente em empresas 1nu ltinacionais de grande porte. Algu1nas
das técnicas incluem:
• Sites
• Bibliotecas de melhores práticas
• Comunidade de práticas
• Boletins informativos
• E-mai ls
• Seminários via internet
• Transferência de funcionários
• Estudos de casos
A Norte) Net\vorks se esforça para garantir comunicações oportundas e consis-
tentes a todos os gerentes de projetos em todo o mundo para ajudar a promover u1n
sucesso continuado na aplicação de processos globais de gestão de projetos. Exemplos
dos vários 1nétodos de co1nunicação usados pela Norte) incluem:
• O PM Newsflash (Boletim informativo de G P) é publ icado mensahnente para
facilita r as comunicações ent re a organização de gestão de projetos e suas áreas
funcionais relacionadas.
• São feitas sessões de comunicação de gestão de projetos periodica1nente, com u1n
forte foco em promover treinamentos, revisões de mét ricas, atua lizações de pro-
cessos e tetnplates, entre outros.
• Boletins de divulgaç.ã o são uti lizados para comunicar informações urgentes.
• Estabeleceu-se um repositório cent ralizado para os gerentes de projetos pro move-
rem o fácil acesso e o compartilhamento de informações relacionadas à gestão de
· 38
proJetos.
Os con1entári os da Norte) deixam claro que as me lhores práticas hoje po-
dem pern1ear todas as unidades de negócios de uma en1presa, especia lme nte as
n1u ltinacionais.
" H. Kerzner, Project Managemenr Best Pmctices: Ad,;eving GJol,al Excellence, Hoboken, NJ: \-Viley, 2006,
p. 18.
Um dos motivos disso é que agora vemos todas as atividades de uma e1npresa
como u1na série de projetos. Portanto, esta mos gerenciando nosso negócio a partir de
pro jetos. Dado esse fato, hoje estão surgindo mel hores práticas em gestão de projetos
por toda a empresa.
Publicar as melhores práticas em algum fo rmato parece ser o 1nétodo preferido de
comunicação. Na Ind ra, Enr ique Sevilla Mol ina, PMP®, a ntigo diretor corporativo do
PMO, afirma:
As melhores práticas são p ublicadas no nível corporativo e no nível co rrespondente dentro
da unidade de negócios afetada . Cursos e treinamentos regulares também estão sendo ofe-
recidos para gerentes de projetos recém-nomeados, e o uso das melhores práticas é revisado
period icamente e verificado pelas equipes de audito ria interna. Além disso, as ferramentas
corpo rativas de GP automatizam as aplicações de melhores práticas a projetos, já que elas
se tornam exigências para os sistemas de informação do GP.
Segundo um porta-voz da AT & T:
Definimos uma melhor prática como q ua lquer ferramenta, template ou a tividade q ue tenha
tido um impacto positivo sobre a tripla restrição e/or qualquer p rocesso ou área de conhe-
cimento do Guia PMBOK"'. Perm itimos q ue o gerente de projetos ind ivid ua l determine se
está ou não diante de uma melhor prática baseados nesses critérios. Comunicamos isso por
meio de um boletim mensal de gestão de projetos e realçamos uma melhor prática do mês
para nossa comunidade de gestão de projetos.
Uma out ra Ílnportância estratégica das mel hores práticas em gestâo de projetos
pode ser o bservada nos comentários a baixo, feitos por Suza nne Z ale, diretora de ope-
39
rações da He,vlett-Packard e antiga gerente global de programas da EDS:
Di recionados pela economia mund ia l, o número de projeto s internacion ais o u globais de
grande escala tende a au mentar. Os gerentes de projeto q ue não tê m experiência g lobal
cost uma m trata r esses projetos g loba is como p rojetos n aciona is d e gran de porte. En-
tretanto , eles são completa mente d iferentes. É muito ma is importante nesses casos q ue
haja uma es trutura mais robusta de gestão de projetos. Planeja r com antecedência torna-
-se extremamente importante com uma perspectiva globa l. Como exemplo, estabelecer
uma equ ipe que te nha conhecimento das regiões geográficas relevantes para o projeto
é crucia l para seu sucesso. Os gerentes de projeto tam bém têm de saber como operar
nessas á reas geográficas. É essencial também que todos os membros da equipe do projeto
sejam treinados e co mpreenda m a mesma metodologia geral de gestão de projetos. A
globalização e a tecnologia tornam ainda ma is importante uma prática sólida da gestão
de p rojetos.
Os comentários de Suzanne Zale ilustram a Ílnportância de identificar melhores
práticas e1n projetos globais . Até o fi nal desta década, esse pode muito bem ter se tor-
nado o fut uro das melhores práticas.
1.17 Passo 9: garantir o uso das melhores práticas

Por que passar pelo complexo processo de identifica r as 1nelhores práticas se as pes-
soas não irão usá-las? Quando as empresas anuncia1n para seus clientes que possuem
mel hores práticas, entende-se que é necessá rio que se faça o seu acompanhamento e
se saiba como elas serâo usadas. Isso normal mente faz parte da responsabilidade do
PMO. O PMO pode ter a autoridade para audita r projetos periodicamente de 1n odo
39
Harold Kerzn.er, Advanced Project Management: Best Prac.r;ce.s on lmplementation, 2nd edfrion, Hoboken,
NJ: \Viley, 2004; p.2 1
a garantir o uso de uma melhor prática, mas pode não ter a autoridade para garantir
seu uso. O PMO pode precisar buscar o auxílio do líder do PMO, do patrocinador do
projeto ou de várias partes interessadas para garantir seu uso.
Quando as melhores práticas são usadas como armas co1npetitivas e anunciadas a
possíveis clientes cotno parte de uma licitação, a equipe de marketing e vendas precisa
compreender as melhores práticas e expl icar seu uso aos clientes. Ao cont rário de há
1 Oanos, hoje a equ ipe de marketing e vendas possui uma boa compreensão da gestão
de projetos e das melhores práticas que o acompanham.
1.18 Crenças comuns

Há várias crenças co1nuns relativas às melhores práticas que as empresas descobrira1n
ser vál idas. Uma lista parcial é:
• Con10 as melhores práticas podem estar inter-relacionadas, a identificação de uma
n1elhor prática pode levar à descoberta de uma outra, especialmente na mesma ca-
tegoria ou nível. As melhores práticas podem se autoperpetuar.
• Devido às interdependências que podetn existir, geralmente é mais fácil identificar
categorias de melhores práticas e1n vez de melhores práticas ind ividuais.
• As melhores práticas podem não ser t ransferíveis. O que funciona bem para u1na
empresa pode não funcionar para uma out ra.
• Embora a lgumas melhores práticas pareçam simplistas e baseadas no senso co-
mum na ma ioria das empresas, sua recordação e seu uso frequentes levam à exce-
lência e à satisfação do cl iente.
• As melhores práticas não estão limitadas exclusivamente a empresas co1n boa
saúde financeira. Empresas com muito dinheiro em caixa podem cometer u1n erro
de US$10 mi lhões e dar ba ixa nessa perda, mas etnpresas que não possuem muito
dinheiro em caixa são muito cuidadosas em como aprovam projetos, monitora1n
o desempenho e avalia1n se devem ou não cancelar um projeto.
Deve-se tomar cuidado para que a implementação de u1na melhor prática não leve
a resultados prejud iciais. Uma empresa decidiu que a organização precisava reconhe-
cer a gestão de projetos como u1na profissão a fim de maximizar o desempenho e reter
pessoal qualificado. A carreira de gerente de projetos foi criada e integrada ao siste1na
de recompensas corporativas.
Infelizmente, a etnpresa cometeu um grave erro. Os gerentes de projeto passaram
a receber salários significativamente mais altos do que os gerentes de área e os fun-
cionários. As pessoas ficaram co1n inveja dos gerentes de projeto e sol icitaram trans-
ferência para a gestão de projetos, achando que "a grama do vizinho era mais verde".
A destreza técnica da e1npresa diminuiu, e algumas pessoas pediram demissão quando
não tiveram a oportunidade de se tornar gerente de projetos.
Às vezes, a imple1nentação de u1na melhor prática é feita co1n a 1nelhor das in-
tenções, mas o resu ltado final ou não atende às expectativas da gerência ou pode até
produzir u1n efeito indesejável, que pode não ser aparente por algum tempo. Como
exemplo, considere a primeira melhor prática da Tabela 1- 8. Várias e1npresas hoje
usam relatórios de semáforos em seus projetos. Uma empresa simpl ificou sua meto-
dologia de gestão de projetos via intranet, passando a incluir relatórios de status "de
semáforos". Ao lado de cada pacote de trabalho na est rutura ana lítica dos projetos
havia um semáforo que podia virar vermelho, amarelo ou verde. O relatório de status
tornou-se mais simples e fácil de ser acompanhado pela gerência. O tempo gasto pelos
TABELA 1-8 Aplicação Inadequada de melhores práticas

Tipo de melhor prática Vantagem esperada Possível desvantagem
Uso de relatório de semáforo Velocidade e simplicidade Informações pouco precisas
Uso de um template/formulário de Voltado ao futuro e preciso Incapacidade de enxergar todos os
gestão de riscos riscos possíveis
WBS extremamente detalhado Controle, precisão e completude Mais controle e custos dos relatórios
Usar gestão de projetos em todos Padronização e consistência cara demais em certos projetos
os projetos da empresa
Usar software especializado Melhor tomada de decisões Dependência excessiva de ferramentas
executivos em reuniões de revisão de status foi signficativamente reduzido, e real iza-

ram-se economias de custo igualmente significativas.
Inicia lmente, essa 1nelhor prática parecia ser benéfica para a empresa. Entretanto,
depois de a lguns meses, ficou claro que o status de u1n pacote de trabalho indicado por
u1n semáforo não era tão preciso quanto os relatórios por escrito, ma is caros. Surgiu
também a preocupação de quem tomaria a decisão quanto à cor do semáforo. Fina l-
mente, o sistema de semáforo foi a 1npl iado, passando a incluir oito cores, e estabelece-
ram-se diretrizes quanto à decisão sobre a cor do semáforo. Nesse caso, a empresa teve
a sorte de identificar a desvantage1n da melhor prática e corrigi-la. Nem todas as des-
vantagens são faci lmente identificadas, e aquelas que o são nem sempre são corrigíveis.
Há outros motivos pelos quais as melhores práticas podem falhar ou fornecer
resultados insatisfatórios. Ent re eles:
• Faltar estabil idade, clareza ou compreensão da melhor prática
• Não conseguir usar as melhores práticas correta 1nente
• Identificar uma 1nelhor prática que não tenha rigor
• Identificar uma 1nelhor prática devido a um julgamento errôneo
• Não conseguir gerar va lor
1.19 Biblioteca de melhores práticas

Partindo da prem issa de que o conhecimento e as melhores práticas de projetos são
propriedade intelectual, como uma empresa retém essas infonnaçõe.s? A solução nor-
malmente é criar uma biblioteca de 1nelhores práticas. A Figura 1- 12 mostra os t rês
níveis de 1nel hores práticas que parecem ma is adequados para armazena1nento em
u1na biblioteca de melhores práticas.
Alta
i
.,
Individuais
Específicas de projetos
Bibliotecas
"'
~ ~
de melhores
'j;1 Específicas da empresa
!li? . práticas
=
g Padrões do setor 1
<.>
Baixa L - - - - - - - - - - --== :..._
Quantidade -
Figura 1- 12 Níveis de melhores práticas.

A Figura 1- 13 mostra o processo de criação de uma bibl ioteca de melhores práti-

cas. O nível mais baixo é a descoberta e a co1npreensão do que é ou não uma possível
melhor prática. As possíveis melhores práticas podem se originar de fontes local izadas
em qualquer lugar da organização.
O nível seguinte é o nível de ava liação para confi rmar que aquela é un1a n1elhor
prática. O processo de avaliação pode ser feito pelo PMO ou por un1 con1itê, n1as
deve ter o envolvimento dos níveis n1ais altos da gerência. O processo de avaliação
é n1uito difícil, porque un1a ocorrência positiva única pode não refletir uma melhor
prática que será repetível. É necessá rio que haja critérios para a avaliação de uma
n1elhor prática.
Uma vez que uma melhor prática tenha sido estabelecida, a ma ioria das empre-
sas fo rnece u1na explicação ma is detalhada dela, a lém de um meio para responder a
perguntas relativas ao seu uso. No entanto, cada empresa pode ter uma abordage1n
diferente quanto a como disseminar essas propriedades intelectuais crucia is. A maioria
delas prefere fazer uti lização máxima dos sites de intr anet da empresa. Porém, algu-
mas simples1nente consideram seus formulários e templates em uso como a biblioteca
de melhores práticas existente.
A Figura 1- 12 1nost ra os níveis de melhores práticas, mas o sistema de classifica-
ção para fins de armazenamento pode ser significativamente diferente. A Figura 1- 14
mostra um sistema de classificação típico para uma biblioteca de 1nelhores práticas.
A finalidade de cria r uma biblioteca de melhores práticas é transferir conheci-
n1ento para os funcionários. Isso pode ser feito por n1eio da intranet da en1presa,
seminários sobre melhores práticas e estudos de casos. Algumas empresas exigem
que a equipe de projeto prepare estudos de casos sobre as lições aprendidas e as me-
lhores p ráticas antes da dissolução da equipe. Elas, então, usam os estudos de casos
em sen1inários pat rocinados pela en1presa. As n1elhores práticas e lições aprendidas
têm de ser comun icadas a toda a organização. O problema é detern1inar como fazê-
-lo eficientemente.
Um outro problema crucial é o excesso de melhores p ráticas. Uma empresa ini-
ciou uma biblioteca de melhores práticas e, depois de alguns anos, tinha acumu lado
centenas delas. Ninguém se preocupou e1n reavaliar se todas elas a inda eram ou não
melhores práticas. Após a reavaliação, determinou-se que menos de um terço delas
TRANSFERtNCIA OE CONHECIMENTO:
• INTRANET
• SEMINÁRIOS
ARMAZENA· • ESTUDOS OE CASOS
MENTO
• OUTROS
Figura 1- 13 Criando uma biblioteca de melhores práticas.

BIBLIOTECA
DE MELHORES
PRÁTICAS
GESTÃO
OE PROJETOS
Avanços
tecnológicos MELHORIAS CONTiNUAS
Gestão de proj etos
Figura 1- 14 Biblioteca de melhores práticas.
a inda eram consideradas como melhores práticas. Algumas já tinham deixado de sê-
-lo, out ras precisava1n ser atua lizadas e out ras, ainda, tinham de ser substituídas por
melhores práticas mais recentes.
1.20 Hewlett-Packard: melhores práticas em ação40

Identificando atividades específicas como melhores práticas
O foco de nossa organização dent ro da HP é o gerenciamento de TI, ou tecnologia
da informação. A T I consiste em todo o hardware, software, redes, instrumentos que
fornecem informações na hora certa, para as pessoas certas, para possibilitar que as
pessoas real izem os traba lhos ou cumpram as obrigações/responsabilidades de suas
empresas. Os departamentos de TI amadurecera1n ao longo das décadas, passando a
lembrar as outras unidades de negócio de uma organ ização, especialmente no geren-
ciamento de TI na forma de serviços. U1na melhor prática para o setor chamada de
ITIL®, que é o acrôn imo de IT Infrastructure Library® (Biblioteca de Infraestrutura
de T I), foi introduzida em meados da década de 1980 e revolucionou o setor de TI ao
promover um único conjunto de melhores práticas, que foi incorporado à comunida-
de global de TI. Na década de 1990, apoiamos o lançamento inicial da ITIL, que era
u1na coleção de publicações ind ividuais. Na virada do sécu lo, apoiamos a versão 2,
que evoluíra para um grupo de práticas centradas em Suporte a Serviços e Entrega de
Serviços. Então (juntamente com todo o resto da comunidade de TI) fizemos o ugrade
das edições de 2007 e 2011, que forneciam uma abordagem de gerenciamento de ciclo
de vida para a gestão de Serviços de TI. O motivo desta aula de história é que foi o
amadurecer dessa 1nelhor prática o motivo de nosso apoio e do amadurecimento de
'
nossas propnas.
'ºO material sobre a HP foi fornecido por Doug Bolzman, arquiteto consultor, PMP• , especialisr.a em mL•
na HP.
Os serviços de TI são desenvolvidos para oferecer suporte à funcionalidade de uma

unidade de negócios. Então, um "sistema de fatu ra 1nento" é o serviço de TI para a fun-
ção da equipe financeira de cobrança de receitas. O sistema de fatu ra 1nento é decom-
posto em componentes de TI como aplicativos empresaria is, servidores de arquivos,
conectividade de rede, conven iências, etc. A !TIL perm ite que as empresas gerenciem
esses componentes com melhores práticas como o Gerencia1nento de Disponibilidade,
Gerenciamento de Capacidade, Gerencia1nento de Problemas e Gerenciamento de Mu-
danças. Hoje, já identificamos 28 melhores práticas a partir da !TIL e desenvolvemos
outras seis que possibilitam a implementaç.ã o e o gerencia1nento de uma abordagem de
Ciclo de Vida de Serviços de T I.
Definição de uma melhor prática

Nossa breve definição de u1na 1nelhor prática é potencialidade a lavancável. A !TIL®
define u1na potencialidade como a capacidade de uma organização ou serviço de TI
real izar uma atividade. Uma potencial idade é composta por t rês "designs": um design
de processos (as atividades a serem seguidas para produzir o resultado), um design de
pessoas (a estrutura e t reinamento da função para capacitar a pessoa a cumprir suas
responsabilidades) e um design de ferramentas (os equ ipamentos ou aplicações usados
para auto1natizar o t rabalho).
Para ilustrar isso, analise1nos algo que todos compreendemos: a sala de emergên-
cia de um hospital. A equipe não sabe o que passa rá pelas portas da e1nergência; eles
têm que estar preparados para tudo! Quando u1n paciente cruza a porta, seja sozinho,
seja em uma maca, a situação é identificada, e a sala, ferra 1nentas e pessoal adequa-
dos são envolvidos para reagir apropriadamente. Se alguém estiver tendo um ataque
cardíaco, haverá um ca rrin ho de reanimação preparado com todos os equipamentos
e medica1nentos necessários, sabem-se os procedimentos adequados a sere1n seguidos,
e há médicos com as habilidades apropriadas. Se alguém chegar com uma torção no
tornozelo, a pessoa terá de se sentar na sala de espera por um tempo enquanto pacien-
tes de maior prioridade são atendidos. Mas o tornozelo torcido não pode esperar para
sempre, ele é encaixado ent re pacientes mais graves.
Da mesma forma que um hospital, o posto de serviço de TI não sabe quem chama-
rá com que tipo de p roblema, mas eles precisam estar preparados para tudo. Quando
uma chamada chega ao posto de serviço, seja ela uma chamada telefônica ou uma cha-
mada acionada por a lgu1n evento, a situação é identificada, e o pessoal e ferramentas
apropriadas reagem apropriadamente. Se alguém tiver uma pergunta ou uma simples
solicitação que pode ser atendida na chamada inicia l, ou se uma função vital estiver
fora de funcionamento devido a um erro de TI, o pessoa l apropriado é reunido e1n
uma chamada de conferência e todas as ações emergenciais e seus desdobramentos são
tomados até que o erro seja corrigido e a funcionalidade seja restaurada.
Um posto de serviço funcional com uma resposta a incidentes urgentes baseia-se
nas melhores práticas da sala de emergência de um hospital. As potencialidades espe-
cíficas para que as equipes de TI ou de operações rea lize1n uma atividade depende do
design de pessoas, processos e ferramentas.
A fim de gerenciar cada uma das melhores práticas consistente1nente, cada capa-
cidade é documentada segu indo o template do perfil da melhor prática. Algumas das
informações contidas no perfi l inclui a descrição da prática, o tipo, o valor que ela
produz para a empresa, a lista de praticantes a usá-la. Cada uma das práticas possui
documentação dos ativos, a situação do ativo e os direcionadores de negócios que
foram usados para desenvolvê-las.
Decisão final sobre uma melhor prática

A fim de compreender que tem a decisão final do que é u1na melhor prática, precisa-
mos explora r como gerenciamos as melhores práticas. Isso é exibido na Figura 1-15.
O gerencia1nento de práticas começa com o estabelecimento da diretoria de pessoas
que serão proprietárias e gerenciarão a prática. Para esse exemplo, a melhor prática
é o gerenciamento de incidentes. Todos os aspectos da prática serão gerenciados; dos
o rçamentos e da orientação quanto a co1no ela se encaixa no 1nodelo gera l de serviços
à propriedade e aquisição pelas partes interessadas e, fina lmente, ao gerencianento de
melhorias ou revisões (e desativações) de design.
Em segundo lugar vem a compreensão de co1no a melhor prática será usada, o
va lor a ser o btido e os direcionadores que determ inarão o design necessário. É aí que
muitas "melhores práticas" fracassa 1n, quando se tentam encontrar "soluções un iver-
sais". Temos três ou quatro designs de gerenciamento de incidentes que são a mel hor
prática para os três ou quatro clientes aos quais servem de suporte. Cada melhor
prática é criada em torno de um conjunto específico de atributos (direcionadores de
negócios) que denota as ca racterísticas da prática que a tornam a 1nelhor opção para
aquele cliente. A menos que cada cl iente comparti lhe os mesmos d irecionadores de ne-
gócios e padrões, nunca haverá uma única mel hor prática que possa ser apl icada para
atender suas necessidades. Alguns clientes exigem um design alavancado e são flexíveis
quanto à adoção de um conjunto exclusivo de atributos aos quais se restringirão, o
que lhes permite um design alavancado e de custo ma is baixo que é implementado em
muitos clientes.
Em terceiro lugar, os designs de pessoas, processos e ferra 1nentas são criados e
integrados para que ofereçam suporte aos atributos acordados . Esse modelo oferece
suporte a uma melhor prática exclusiva para incidentes, ou pode ser desdobrada nas
25 potencialidades como fazer o regist ro de um incidente ou determinar uma classifi-
cação de prioridade a incidentes. Compreender e gerenciar no nível da potencialidade
O Diretoria do componente
Patrocinadores<'
EQuipe ele liderança
Arquitetos Responsável pela
Conselho : Proprietário elo direção, desenvolvimento
!Se deSign componente
e execução do
Gerente de componente
componente
O Atributos Equipe de cli?Si!)n
Descrição
Potencialidades Regras e direcionadores formais do cliente que são necessários
Requisitos para gerenciar as operações da perspectiva empresarial,
Padrões multiplataformas, multífornecedores e integrada
Métricas
Terminologia
9 Design
Pessoas
(Cargas. qualificações. treinamento) Todos os designs oferecidos pelo
Ptoc-essos fornecedor ao cliente são medidos
(fluxogramas, instIUções de trabalho) em relação aos atributos
Ferramentas
declarados e terão de estar em
(Modelo de dados, aplicativos. templates)
Impactos sobre o componente
conformidade com eles
Figura 1- 15 Gerenciamento de uma melhor prática.

nos fornece flexibi lidade para combinar designs de potencialidades de modo a atender
as necessidades do cliente. Se o cliente possui padrões governamentais, como a Sarba-
nes-Oxley, ou padrões setoria is, como os do setor fannacêutico, pode1nos identificar
os designs que fora1n criados para seguir esses padrões.
Uma biblioteca de melhores práticas

A bibl ioteca de nossas práticas de gerenciamento de serviços de TI é armazenada e1n
uma ferramenta de trabalho em grupo compatilhada com um tipo de classificação e1n
metadados. Cada prática possui controle de versão e está associada à empresa à qual
foi aplicada. Dessa forma, se tivermos duas e1npresas no mesmo setor, podemos sem-
pre começar com um design existente, e então fazer ajustes dependendo da definição
de seus atributos.
O número de melhores práticas

Temos centenas de 1nelhores práticas na bibl ioteca, já que elas poden1 estar em um nível
de componente (gerencia1nento de incidentes) ou em um níve l de potencial idade (25
potencia lidades de gerenciamento de incidentes). Além disso, como cada potencial ida-
de é composta de um design de pessoas, processos e ferran1entas, a 1nelhor maneira de
ad1n inistrar a bibl ioteca é e1n u1n banco de dados de gerencian1ento de configurações.
Conseguindo apoio para as melhores práticas

As mel hores práticas usadas por nossa organização são gerenciadas por consultores
de ITSM e mantemos nosso serviço para lelo de 1nelhores práticas. Cada serviço de
consultor de ITSM possui u1n proprietário para supervisiona r os designs da melhor
prática e aplica r o design correto no ponto de partida de um novo contato. Esse é u1n
valor a 1na is para um cliente contratar nossos consultores, pois eles podem ter certeza
de que começaremos co1n a 1nelhor prática aplicável possível sem ter de co1npreender
o sistema inteiro. Eles podem ser os clientes, fornecer-nos seus atributos e nós demons-
traremos u1n design que esteja em conformidade com os at ributos.
41
1.21 DTE Energy
E,n 2002, a organ ização Information Technology Services (ITS) na DTE Energy ini-
ciou u1n esforço para identifica r e documentar melhores práticas para a gestão de pro-
jetos. Nossa intenção era publicar, co1nun icar e garantir que essas 1nelhores práticas
fossem adotadas em toda a cultura da empresa.
Acreditávamos que essa abordage1n levaria a oportun idades de melhorias contí-
nuas, resultando em software de soluções empresariais de mais a lta qual idade, mais
rápidos e menos caros.
Em vez de descrever o estado ideal da gestão de projetos como podíamos imaginá-
-lo, decidimos descrever o estado corrente, do modo como estava sendo praticado
pelos gerentes de projeto na organização. O objetivo era estabelecer um conjunto-base
de padrões que sabíamos que os gerentes de projeto conseguiriam cumprir, pois já os
estávamos praticando.
41
O material sobre a DTE Energy foi fornecido por Joseph C. Thomas, PJvt~ , gerente de projetos sên.ior; e
Sceve Baker, PM~ , CCP, anal ista principal de organização de processos e habilidades.
Formamos uma pequena equipe com nossos gerentes de projetos e líderes de TI

mais experientes. Essa equipe pôde tira r proveito de suas recentes experiências com
p ro jetos para identificar um conjunto de melhores práticas. Embora ne1n todo gerente
de projeto as seguisse uniformemente, as mel hores práticas representavam o máximo
denominador comum em vez de o 1n ínimo. Sabíamos que elas eram viáveis, pois re-
presentava1n experiências práticas de nossos gerentes de projeto mais bem-suced idos,
e elas tam bém caracterizava1n as práticas que queríamos que fosse1n aplicadas con-
sistentemente em todos os projetos. Dessa forma, a meta era ba ixa o suficiente para
ser alcançável, mas a lta o suficiente par a promover u1na mel horia significativa par a a
maioria dos projetos.
A equipe concordou em descrever as mel hores práticas em termos de "o que" em
vez de em termos de "co1no". Queríamos evitar a tarefa difícil e morosa de definir
procedimentos deta lhados com documentação forma l. Em vez disso, descrevemos o
que os gerentes de projeto precisavam fazer e os a rtefatos que os gerentes de projeto
p recisavam p roduzir. Isso deu aos gerentes de p ro jeto praticantes certo grau de fle-
x ibi lidade quanto aos métodos (o "como") que eles empregavam para produzi r os
resultados (o "o que").
Publicamos as melhores práticas em um manual de cem páginas chamado de Project Mana-
gement Standards and Guideli11es (Sumário, Tabela 1.9) e também as postamos no Centro
de Processamento de Entregas de Soluções (S0/utio11 Delivery Process Center, SDPC) do site
de nossa intranet (lmagem de Tela, Figura 1- 16). Incluímos referências a outros recursos
como form ulários, templates e procedimentos-padrão que j á existiam.
O SDPC é nossa biblioteca de ativos de processos, que contém uma enorme q uantidade
de descrições de papéis e processos de alto nível, templates e exemplos de fácil acesso e
links para vários recursos de o utros departamentos de toda a [TS. Fizemos o design de
nossa bibioteca d ig ital de modo que ela fosse utilizável a partir de várias perspectivas, com
modos de acesso q ue variam desde o acesso baseado em função ("Eu sou um..."), ao acesso
baseado em localização ("Estamos em ...") e ao baseado em artefatos (" Preciso de um ..."),
e assim por d iante.
Lançamos os materiais dos " Padrões e d iretrizes" e a bibliote.ca SDPC com uma estraté-
gia de comunicação diversa, tendo como a lvo a mensagem correta para o público correto no
momento correto. Incluímos um processo de (eedback para garantir a evol ução e a aplica-
bilidade dos padrões ao longo do tempo. Esse processo de melhoria contínua inclui (a) uma
conta de e-mail de entrada para receber comentários, s ugestões e ideias; (b) um processo de
revisão e atualização incluindo funções e local izações; e (c) atualizações rápidas ao SDPC e
impressões selecionadas do manual de padrões e d iretrizes.
Como uma forma de captar as lições aprend idas com cada um de nossos projetos,
adotamos um processo de Revisão Pós-Ação (AAr, A/ter Act.ion Revieiv). Todo projeto
rea liza uma AAr após seu encerramento, e procuramos fazer melhorias e inovações em
nossos processos e templates ex istentes. lnstituc ionalizamos essas mel horias em nossos
" Padrões e d iretrizes" e na Biblioteca SDPC, q ue se encontra m em constante evolução.
Solucionamos o d ilema de nossas lições aprendidas (as melhores práticas eram devida-
mente arquivadas, mas raramente consultadas), incorporando cada descoberta em nosso
''Padrões e diretrizes".
Os "Padrões e d iretrizes" são um meio para se chegar a u m fim. Descobrimos q ue
simplesmente publicá-los e comun icá-los não é s uficiente para causar um impacto sig-
nificativo em nossa c ultura. Com essa finalidade, instituímos um grupo de Controle de
Qualidade (QMg, Qua/it.y Management. group), formado por uma eq ui pe de especialistas
peq uena, mas d iversa. O Qtvlg a um só tempo habilita nossos projetos com serviços de
consultoria e d ivulgação e garante que n ossos projetos estejam em con formidade com os
"Padrões e d iretrizes" publicados. Com cinco momentos de ins peção, o QMg demonstra
nosso compromisso organ izacional com as melhores práticas e as melhorias contínuas.
TABELA 1-9 Padrões e diretrizes para a gestão de projetos

Padrõ es e diretrizes para a gestão de projetos em engenharia de software, métodos
e recrutamento de pessoal
Introdução 1
Público-alvo 1
Finalidade 1
Conteúdo 2
Centro de processo de entrega de soluções 3
Certifique seu aplicativo - lista de conferência 3
Revisões de documentos 3
Convenções de documentos 4
1. Iniciação do projeto 7
1.1 Relacionamento com o cliente 8
1.2 Financiamento 9
1.3 Registro 10
1.4 Termo de abertura 12
2. Planejamento do projeto 17
2.1 Escopo 18
2.2 Lista de características/exigências 20
2.3 Lista de itens de trabalho 22
2.4 Cronograma 25
2.5 Previsão de custos 28
2.6 Prontidão ambiental da T I 30
2.7 Recrutamento e seleção de pessoal 31
2.8 Lista de participantes de equipe 33
2.9 Plano de alocação de capacidades/recursos da equipe 35
2.10 Recursos de infraestrutura 38
2.11 Plano de treinamento do usuário final 40
2.12 Mensurações 41
2.13 Contratação externa 43
2.14 Estimativas 46
2.15 Qualidade 49
2.16 Implementação, transição e conclusão 51
2.17 Lista de riscos 52
2.18 Testes 53
2.19 Compromisso baseada em restrições 55
2.20 Conversão de dados 56
3. Execução e controle 59
3.1 Execução baseada em restrições 60
3.2 Gestão de riscos 62
3.3 Gerenciamento de problemas 63
3.4 Relatórios de desempenho 65
3.5 Lista de casos de teste 69
3.6 Lista de defeitos e melhorias 71
3.7 Reunião de abertura do projeto 73
3.8 Reunião d iária de equipe 75
3.9 Reunião de teste de funcionalidades (features) 76
(continua)
TABELA 1-9 Padrões e diretrizes para a gestão de projetos (continuação)
Padrões e diretrizes para a gestão de projetos em engenharia de software, métodos

e recrutamento de pessoal
3.1o Reunião de design 77
3.11 Reunião retrospectiva 78
3.12 Feedback sobre o desempenho dos m embros do grupo 81
3.13 Cumprimento dos padrões e diretrizes da ITS 83
3.14 Acompanhamento dos custos reais 84
3.15 Execução de contratações externas 86
3.16 Migração da produção 88
3.17 Migração do portfólio de aplicativos 90
3.18 Aprovação de prazos 91
4. Finalização do projeto 93
4.1 Encerramento do projeto 94
4.2 Revisão pós-encerramento 95
4.3 Liberação de recursos 96
4.4 Encerramento administrativo 97
Apêndice A: Revisões de documentos 99
Versão 1.1 : revisões 99
,;;
11 Ili< ~ I."" - l°"' tl<i>
Solution Delivery Process Center

The Sc:M,on Oe!Nvry P1oce&& Center (SOPC) public1:zes and clanfie& lhe requirrnenle fo1100'Jtt ProceH
C~liance. perl.1-'lent to Prcject-Based Appbtation Sotulf:ln OMry work in the llS Organi z.etion ai OTE
E1141rgy This sic, prc,wides tht artiracts. p1oc.ius. and Policats for Pl'oJtC1 Ma nagifS. OeYi1lope11, anel
Tedlnital Business S1.1bjeel Ma11er E.xperts (íBSW.Es) e11919ed in projett worl<.
• Oyfaif'.d Artifucts
• LA@çydf!YU
• AttifaSls aod Proctsua
• M!lntts
lse-'.ed .:l
• S!arclar'ds aM Guiotbnes
• Ars:hlttl\llH iod Jogh
• ITS SolU!ion- Pc!IYfry lnrtiatiYJs

.:l
• Wbit'i '{n !D Ih& SOfC?
Conwnern, arul Euõack?
Figura 1- 16 Imagem de tela do Centro de Processamento de Entregas de Soluções.

1.22 A gestão de projetos e as melhores práticas vistas

por um consultor
Quando as empresas iniciam sua busca por excelência em gestão de projetos, normal-
mente se enfatiza o benchmarking externo. Embora estudos de benchmarking tenha tn
seu mérito, as informações obtidas podetn ter utn va lor limitado ou nu lo para a em -
presa que os está realizando, apesar de ela ter começado com boas intenções. Talvez a
melhor escolha seja cont ratar consultores que possam contribuir com experiências de
uma variedade de empresas, tanto grandes quanto pequenas. O restante desta seção
foi fornecido por Sandra Ku1norowski.
Gestão de projetos no ambiente da pequena empresa

Gera lmente, no a tnbiente da pequena etnpresa, os proprietários são 1na is incl inados
a usar práticas de gestão de projetos - às vezes não intencionalmente e, na ma ioria
das vezes, por uma questão de bom senso - do que em qualquer outro a tnbiente. Já vi
práticas bastante sofisticadas de estimação, orçamento e determinação de cronogra-
mas no a tnbiente de pequenas empresas em que os proprietários as consideravam a
habilidade número utn a ser dominada porque seu sustento dependia dela. Escopo e
objetivos são muito bem definidos, e expectativas são determinadas no início do pro-
jeto. Isso pode, no entanto, variar de um setor pa ra outro. Deixe-me começar cotn dois
exemplos do setor da construção e de saúde.
Gestão de projetos no setor de construção

Meu marido possui u1na empresa de pintura (residencia l e comercial) há mais de uma
década . Ao longo de tantos anos, não houve um projeto sequer em que ele tenha per-
dido d inheiro. Suas habilidades precisas de esti tnaçâo, seu esti lo de comunicaç.ã o e sua
experiência gerencial permitem que ele crie experiências de projeto bastante rápidas e
diretas. Quando ele trabalha cotn um empreiteiro geral, quando o sucesso do projeto
de const rução depende do alinhamento preciso de todos os serviços subcontratados, é
crucial que se cumpra o cronograma. Quando t raba lha com clientes d iretos, precisão e
tempo são ainda mais itnportantes, porque a vida dos clientes podem ser diretamente
afetadas pelo projeto de pintura.
O fator de sucesso número um de seu negócio é um treinamento mu ito intenso e
contínuo de seus funcionários . Ao contratar a lguétn novo, o funcionário passa por utn
treina tnento intenso. Todos os funcionários são continuamente atualizados e t reinados
em novas técnicas e inovações em pintura.
O fator de sucesso nún1ero dois é un1a autonomia de equipe gerenciada. Cada
equipe possui un1 líder que é inteiramente responsável pelo desempenho do proje-
to e que tem de informar meu marido todos os dias sobre o progresso do p rojeto.
Meu marido passou a usar esse sistema de autonon1ia de equ ipe gerenciada depois
de abandonar o sisten1a anterior, em que ele pessoaln1ente controlava cada p rojeto
quase que integralmente (o que usava demais do seu ten1po e não era necessarian1ente
n1ais lucrativo) e o achou n1uito eficiente. O novo sistema foi recebido positivan1ente
pelos funcionários, que se sentiram n1ais independentes e, de fato, começaram a ter
un1 n1elhor desempenho, especialmente em tern1os de tempo. Hoje, eles tern1inam seus
projetos en1 períodos de tempo mais curtos, mantendo o mesmo nível de qualidade,
se não n1ais alto.
As habilidades naturais de n1eu marido em gestão de projetos são bem refinadas,

e ele nunca usou nenhum tipo de conceito formal ou software de gestão de projetos.
Ele desenvolveu seu próprio sistema, que tem funcionado bem para ele. Entretanto,
há muitos desafios de gestão de projetos no setor de construção. Portanto, acred ito
que haja uma grande oportunidade para os proprietários dessas pequenas en1presas
serem apresentados e t reinados sobre n1etodologias de gestão de projetos, das qua is
eles tirariam enorme proveito. Quando pesquisados, a maioria deles as considerou
den1oradas demais. Mas essa opinião deve-se principalmente à falta de conhecimen-
to sobre a prática e, n1uitas vezes, a habilidades con1putacionais limitadas.
Gestão de projetos no setor de saúde/categoria odontológica

Baseada em 1neus sete anos de experiência em um consultório especializado etn pe-
riodontia, tenho de admitir que as práticas de gestão de projetos e pacientes eram
bastante avançadas. O consultório era administrado por utn dentista, e suas incríveis
e avançadas habilidades cirúrgicas e seu gerenciamento do tempo permitiam que um
grande número de pacientes fosse atendido todos os dias. E,n um dia, o consultório
podia atender até 60 pacientes divididos entre o dentista, o higienista e o assistente
pós-operatório. Isso exigia práticas muito sofisticadas de marcação de horários e mo-
nitoramento do tempo. Usáva1nos o software de administração de consultório odon-
tológico Eagelsofc, que, embora um tanto limitado em sua capacidade de geração de
relatórios, oferecia eficientes ferramentas de acompanhamento e mon itoramento. Em
média, um paciente nos visitava de quat ro a seis vezes por ano. Para evitar cancela-
mentos e lacunas na agenda, tentávamos marcar todas as consultas com antecedência
para cada paciente e tínhamos estabelecido uma rígida política de cancelamentos -
a lgo betn incomum na categoria de consu ltórios odontológicos.
Cada paciente era como um miniprojeto e, sen1 o software e a marcação de
consu ltas n1etódica, não seríamos capazes de gerenciá-los com êxito. O consu ltório,
graças à sua meticulosa abordagem de gerenciamento de operações e, especifica-
mente, de marcações de consu ltas, desfrutava de um crescimento contínuo.
Gestão de projetos na educação superior

Trabalhar com projetos pode ser bastante desafiador para muitos estudantes univer-
sitários. Na educação superior, na maioria das vezes, os projetos representam 50% da
nota final, mas não se presta atenção suficiente às inst ruções de gestão de projetos. Fiz
uma pesquisa em ,ninha turma e, de 44 a lunos, apenas dois estavam fami liarizados
com a gestão de projetos. Em torno de 70% dos alunos percebia o trabalho com pro-
jetos como um grande desafio, principa lmente devido a questões de gestão de projetos
e de equ ipes.
Então, adotei uma abordagem proativa e dediquei em torno de 10% do tempo
das au las durante o semestre a práticas e métodos de gestão de projetos para tornar o
projeto deles mais eficiente e bem-sucedido.
Gestão de projetos na categoria de propaganda e marketing

Trabalhar na categoria de propaganda e 1narketing há anos me possibi litou estudar
e analisar como a gestão de projetos era compreend ida no ambiente da agência. Pela
minha própria experiência, em primeiro lugar, não há conscientização suficiente sobre
práticas de gestão de projetos e seus benefícios cotnprovados. As pessoas não acredi-
cam na gestão de projetos e, na ma ioria das vezes, ela é percebida como um obstácu lo
à criatividade. No entanto, é importante dizer que o 1nodo como as contas de clientes
e projetos são gerenciadas é bastante consistente com a metodologia de gestão de pro-
jetos. O problema, porém, é que os planeja dores de contas não fazem uso da d isciplina
da gestão de projetos para aprimorar processos e fazer os projetos terem um desem-
penho melhor. Não há relação formal entre a gestão de projetos e o gerencia1nento de
contas na categoria de propaganda e marketing.
Quando apresentei a gestão de projetos à 1ninha empresa de executivos da propa-
ganda como u1na forma de melhorar nosso negócio, levei algum tetnpo para fazê-los
acreditar nisso.
A seguir, conto a história de como consegui.
Iniciativa de gestão de projetos para uma empresa de consultoria

de estratégia em marketing
Minha empresa era de consultoria de estratégia em marketing, pequena (22 funcio-
nários), mas extremamente era ben1-sucedida. Fundada em 2003 por um executivo
da área de propaganda, seu foco era produzir ideias para pesqu isas e estratégias
acionáveis relacionadas baseadas na análise de conversas o n-line. A consultoria
prestava serviços para empresas listadas na Fortune 500 e conseguiu sua reputação
criando a "grande ideia" em cada projeto e ajudando as marcas a construírem seu
próprio valor de marca (brand equity) de longo prazo.
Necessidade de un1a in iciativa de gestão de projetos? Devido à natureza ba-
seada em projetos da empresa, fu i abordada pela alta gerência para ava liar as práti-
cas correntes de gestão de projetos e estabelecer um sistema mais formal. À medida
que a en1presa cresceu, a necessidade de un1 sistema consistente para nosso p laneja-
n1enco e execução de projetos foi se tornando bastante aparente.
Nossos projetos iam desde alguns de duas sen1anas a escudos de pesquisa de
oito sen1anas, e havia uma necessidade de criar um sistema de gerencian1ento de
portfó lio de projetos para melhor controlar nosso planejan1ento futu ro.
Além disso, algun1as questões n1a is sérias relativas ao pessoa l con1eçaram a vir à
tona. A maioria dos prob lemas estava nas fases de iniciação e planejamento, en1 que
a con1un icação se perd ia pelo fato de um número grande den1ais de pessoas estar
envolvido . Os escopos às vezes estavam fora de controle, e a equipe descobria, no
final do projeto, que escava trabalhando em algo diferente do que o cliente queria.
A n1ensagen1 principal (escopo/objetivos) se perdia.
Mais tarde, no projeto, os erros na detern1 inação do escopo se an1pliavam ex-
ponencia lmente en1 situações por vezes quase incontroláveis, nas qua is membros de
equ ipes precisavan1 ficar no trabalho até carde da noite e nos fins de sen1ana para
tentar levar o projeto até a fase de conclusão satisfatória. Os níveis de estresse às
vezes eran1 altos.
Un1 outr o problema que sempre atrapalhava nossos projetos era a d inâmica de
grupo. Cada equipe consistia em dois n1embros - um estr ategista sên ior, que era o
líder do projeto, e um estrategista júnior. O papel do estrategista sênior era definido
como 80% desenvolvin1enco de estratégias e 20 % levantamento e análise de dados.
O estrategista jún ior tinha que fazer 80% de levantamento e anál ise de dados e
contr ibuía apenas com 20 % do desenvo lvin1enco de estr atégias. Isso levava a un1a
forte sensação de injustiça, e a lguns men1bros se recusavam a trabal har juntos. Isso
precisava mudar.
Havia sete principais áreas em que o uso de gestão de projetos como uma melho-
ria contínua de instrumentos era aparente:
1. Gerenciamento do relacionamento com o cliente (CRM, Client Relationship
Management)
2. Saúde/dinâmica das equipes
3. Qualidade/criatividade dos projetos
4. Custos/orçamento dos projetos
5. Escopo/prazo dos projetos
6. Gerenciamento de portfólio de projetos
7. Cultura da empresa
A mudança necessária pode ser vista na Figura 1- 17.
Cronologia da iniciativa de gestão de projetos

1. Reconhecimento da necessidade: necessidade de que a gestão de projetos seja
reconhecida devido a mudanças graduais no escopo, equipes insatisfei tas, fal-
ta de controle de projetos, entre outros.
2. Reunião in icial de aprovação (buy-in ) com a alta gerência: estabelecer a ne-
cessidade imediata e relevante.
3. Entrevistas: entrevistas detalhadas com e.ada funcionário, incluindo a alta ge-
rência (criei um questionário pa ra e.ada funcionário e, então, me reuni co1no
cada um deles individualmente para d iscuti-lo).
4. Pesquisa e aná lise: pesquisar as 1nelhores práticas da gestão de projetos, além
de análises dos processos correntes e da aná lise das entrevistas.
5. Período de pesquisa das melhores práticas da gestão de projetos.
SISTEMA DE NOVOSISTEMA DE
COMUNICAÇÃO ATUAL COMUNICAÇÃO
CEO
CEO Equipe de wndas
1 ouvem a
mesma
Equipe de vendas/ Consultor mensagem
Gerência Equipe de
júnior
gerência
! Consultor
sénior
Consultor sênior
!
Consultor júnior
Figura 1-17 O sistema de comunicação antes e depois.

6. Segunda reunião de aprovação com a alta gerência: reconfirma r a necessida-

de da gestão de projetos, revisar custos, cronograma e objetivos da iniciativa,
priorizar áreas de foco para a iniciativa.
7. Definição dos objetivos da iniciativa de gestão de projetos.
8 . Apresentação oficia l: para todos os funcionários.
9. Implementação de objetivos e táticas: e testes.
10. Relatórios mensais de progresso.
Exen1plo de iniciativa de gestão de projetos. Objetivos 1nJC1a1s . Como nossa
empresa era nova em gestão de projetos, as mudanças ocorreram em etapas. Abaixo
(ver Tabela 1- 10) há alguns dos objetivos que foran1 alcançados e medidas tomadas
assim que a iniciativa de gestão de projetos foi in1plementada.
TABELA 1.10 Panorama da Iniciativa de gestão de projetos
Classificação de Resultado/
prioridade Área Ação Benefício Medida
1. Gerenciamento do 1. Estabelecer u m • Relacionamentos • Pesquisa do cliente
relacionamento com contato pessoaJ com de longo prazo • Retenção de clien-
o cliente o cliente (adicionar com o cliente tes/taxa de retorno
MOTIVO:VOLTA DO custos de viagens ao • Ganhar credibili· de clientes
CLI ENTE/REPETI· contrato) em projetos dade • Taxa de recomen·
ÇÃO DE VENDAS mais longos, comple· • Mais projetos dação
xos e que ofereçam • Aumento da boa • Número de pro·
novas oportunidades reputação da em- jetos de navas/
2. A primorar a fase de presa antigos clientes
planejamento por mês/ano
3. Temp/afe de escopo.'
contrato
4 . Template post mortem
5. Marcar reuniões com
pautas padronizadas e
deixar todos trabalha·
rem na declaração do
escopo
2. Saúde/dinâmica da 1. Designar 3 pessoas • Maior colaboração • Resultados da ava-
equipe a cada projeto (3ª na equipe liação post mortem
MOTIVO: RELACIO- para balanço/controle) • Menos estresse e (consultor júnior
NAMENTOS 2. Distribuição da carga problemas avalia abertamente
de trabalho a 40/60 • Consultores júnior o consultor sênior
(em vez de 20/80 a sentem-se mais e vice-versa?)
consuttores sénior/ valorizados • Pesquisa de Satis-
júnior) • Maior responsabili· fação Ponderada
3. Novas responsabili· dade delegada aos do Funcionário -
dades de GP consuttores sénior WESS (Weighted
4. Redefinição das fun- Employee Satis-
ções correntes taction Swvey)
3. CriaUvidade 1. Padronizar proces· • Mais tempo para • Grande ideia em
MOTIVO: LIMITADO sos de planejamento criar cada projeto
POR2, 4e5 de projetos por meio • Menos tempo para • Ideias acionáveis
da padronização da se preocupar em cada projeto
estrutura do projeto
2. Ater•se a funções
bem definidas (todos
sabem o que fazer)
(continua)
TABELA 1.10 Panorama da Iniciativa de gestão de projetos (continuação)

Classificação de Resultado/
prioridade Área Ação Benefício Medida
4. Determinação do 1. Criar e implementar • Controle de custos • Método do valor
custo/orçamento do o melhor sistema durante todo o agregado
projeto personalizado de projeto • Vaôação de Custo
MOTIVO: CONTROLE custeio do projeto • Capacidade de (VC = VA - CR),
(MS Project) precificar bem ver Apêndice
2. Estimativas de cus- projetos para evitar • Índice de Oesem-
tos no início do proje- perdas penha de Custo
to (MS Project) -CPI (Cost Perfor-
mance lndex)
5. Escopo/prazo do 1. Implementar um siste- • Controle de esco- • Método de Valo r
projeto ma personalizado de po/prazo durante Agregado
MOTIVO: CONTROLE cronograma e plane- todo o projeto • Variação de Prazo
jamento (MS Project) (VPR = VA - VP)
2. Focar a fase de • IDP (Índice de
planejamento para Desempenho de
evitar mudanças
Prazo)
graduais no escopo/
prazo
6. Gerenciamento do 1. Criar e implementar • Eficiente gerencia- • Margem de lucro
portfólio do projeto a ferramenta de mento de portfólio • Planejamento e
MOTIVO: VER O acompanhamento de projetos para cronograma efi-
QUADRO GERAL, de todos os projetos tomar decisões de ciente de projetos
ESTRATÉGIA (MS Project) negócios eslraté- futuros
2. Analisar projetos gicas
baseados no custo, • Menor incerteza e
preço, prazo, sensi- maior planejamen·
bilidade do prazo e lo do futuro
oportunidade
7. Cultura 1. Aplicar transparên- • Menos temor e • Resultados da ava-
eia por meio de uma ressentimento liação post mortem
comunicação aberta e • Inovação e criati- generalizados e li·
ativa em cada projeto vidade ções aprendidas a
• Cultura de aprendi· partir deles: biblio-
zagem teca de melhores
• Transparência práticas
Objetivo 1 CRM: Construir relaciona1nentos de longo prazo co1n o cl iente, aumentar

a propaganda boca a boca e a reputação, aumenta r vendas.
Ação: Listar todas as reuniões a serem marcadas co1n o cliente.
Objetivo 2 Saúde/ Dinâmica de equipe: Esta belecer uma colaboração eficiente e um
equilíbrio de ca rga de tra balho na equipe pa ra alcançar o produto de melhor qua-
lidade possível.
Ação : 1. Ma rcar palestra sobre novos processos de gestão de p ro jetos, eficiência no
tra balho em equipe e liderança pa ra toda a equipe na sexta-feira . 2. M arcar reu-
nião sobre liderança com os líderes de projeto .
Objetivo 3 Planejamento de pro jetos: Gerencia mento de escopo/eficiência das reuniões
Ação: 1. Fina lizar e usar o template interno da pauta da reun ião de abertur a. 2. Fi nali-
zar e usar o tem pia te interno da pauta da reunião post mortem.
Objetivo 4 Monitoramento de pro jetos: Aco1n pa nhar projetos e o sucesso do projeto
de gestão de projetos
Ação: 1. Desenvolver TODOS os formatos de acompanhamento de projetos (quad ro
branco). 2 . Fazer relatório sobre os o bjetivos de gestão de p ro jetos apresentados
mensalmente.
Da melhor prática a
uma enorme dor de cabeça
2.0 Introdução
Por quase 40 anos, a gestão de projetos esteve presente em relativamente poucos
setores, como aeroespacia l, de defesa e de constr ução. Esses setores eram orientados a
projetos e implementavam-na principahnente para atender as solicitações dos clientes.
A gestão de projetos era considerada interessante, mas acessória. Por consequência, as
melhores práticas em gestão de projetos nunca rea lmente foram consideradas impor-
tantes.
Nas duas últimas décadas, a gestão de projetos evoluiu, to rnando-se um processo
obrigatório pa ra a sobrevivência da empresa no longo prazo. Atualmente, é u1na ne-
cessidade, e não um luxo. Ela permeia todos os aspectos de uma empresa. As empresas
hoje gerenciam seus negócios por 1neio de projetos. A gestão de projetos se tomou
uma forte arma de vantagem competitiva. O conheci1nento adqui rido por 1neio dela é
tratado como propriedade intelectual, e os escri tórios de projeto foram criados para
serem seus guard iões, reportando-se à alta gerência e recebendo a tarefa de identificar
as melhores práticas em gestão de projetos.
Assim como com qualquer nova atividade de gestão de p rojetos, os benefícios
são acompan hados por desvantagens e possíveis proble1nas . Alguns são pequenos e
fáceis de corrigir, mas outros são dores de cabeça enormes, que fazem os executivos
passarem noites em claro. A maioria das dores de cabeça emana ou de uma má com-
preensão dos benefícios da gestão de projetos, ou de expectativas altas demais. Outros
problemas ocorrem quando uma atividade na verdade não é uma 1nelhor prática e
acaba por acarretar resu ltados negativos.
2.1 Dor de cabeça ns:i 1 : boas intenções

Às vezes, as melhores intenções podem se tr ansformar em enormes dores de cabeça.
Como exe1nplo, uma empresa percebeu rapidamente a importância da gestão de pro-
jetos e a transformou em u1n ca rgo de carreira. Isso certamente fo i a decisão certa.
Internamente, as pessoas acreditavam que a e1npresa considerava a gestão de projetos
uma co1npetência estratégica, e os funcionários começaram a se especializar em gestão
de projetos. Externa1nente, seus clientes ficaram bastante satisfeitos em vê-la como
uma disciplina de carreira, e os negócios aumentaram.
Alta
necessidade Riscos para o cliente
Satisfação
do cliente
Baixa Riscos para a empresa

necessidade
Simples Complexo
Sistema de controle do gerenciamento de projetos
Figura 2- 1 Crescimento dos riscos.
Essas boas intenções logo se transformaram e1n problemas. Para most rar seu
apoio à excelência e1n gestão de projetos, os gerentes de projeto recebiam au1nentos
salaria is de 14%, enquanto os membros das equipes dos projetos e os gerentes de área
recebia1n de 3 a 4'Yo . Depois de dois anos da implementação do gerente de projetos
como cargo de carreira, todos estavam tentando se tornar um e trilhar o 1nesmo ca-
minho, inclusive gerentes de área importantes co1n conhecimento especia lizado. Todos
achavam que "a grama era mais verde" no quinta l do gerente de projetos do que em
seu próprio quinta l. Os gerentes de área co1n habi lidades essencia is estavam ameaçan-
do pedir demissão da empresa se não tivessem a chance de se tornar gerentes de pro-
jeto. A empresa fina lmente corrigiu o problema dizendo a todos da empresa que cada
p lano de carreira da empresa oferecia as mesmas oportunidades de crescimento. O
grande diferencial em aumentos salariais desapareceu e foi substituído por um p lano
mais equitativo. Entretanto, já era tarde dema is. Os 1ne1nbros de equipes e os gerentes
de área sentiam que os gerentes de projeto os exploravam, e o relacionamento profis-
sional entrou em crise. Os executivos agora estavam enfrentando a dor de cabeça de
ter de consertar os danos causados.
A Figura 2- 1 ilustra por que 1nuitas out ras dores de cabeça ocorrem. À medida
que a gestão de projetos cresce e evolui para uma arma competitiva, a organização é
pressionada a implementar melhores práticas, 1nuitas das quais necessita1n de caros
sistemas de controle interno para o gerenciamento de recursos, custos, cronogramas e
qual idade. Os sistemas de gestão de projetos têm de ser capazes de lidar com diversos
projetos simultaneamente. Da mes1na forma, obter a satisfação do cliente é algo con-
siderado co1no uma melhor prática e pode ter um preço alto. À medida que a impor-
tância de ambos aumenta, aumentam ta1nbém os riscos e as dores de cabeça. Manter a
paridade entre a satisfação do cl iente e os controles internos não é fácil. Gastar tempo
e dinheiro dema is com satisfação do cl iente pode levar a desastres financeiros em
determinados projetos. Gastar tempo demais em cont roles internos pode levar a uma
não competitividade.
2.2 Dor de cabeça nº 2: a metodologia de gestão de

projetos da empresa
À medida que a importância da gestão de projetos tornou-se aparente, as e1npresas re-
conheceram a necessidade de desenvolver metodologias para isso. Boas metodologias
são melhores práticas e pode1n levar a contratações de fornecedores únicos, baseadas
na capacidade dessa metodologia de continua1nente produzir resultados de qual idade
e da fé que o cliente possui nela . Infel izmente, os departamentos de marketing, de

produç.ã o, de sistemas de informação, de P&D e de engenharia podem ter sua própria
metodologia para a gestão de projetos. E,n uma empresa, essa subotimização era acei-
tável para a gerência contanto que essas áreas individuais não precisassem trabalhar
juntas continuamente. Cada metodologia tem sua própria term inologia, fases de ciclo
de vida e processos de revisão de fases.
Quando os clientes começam a exigir soluções completas para seus negócios etn
vez de produtos proven ientes de várias un idades funcionais, a necessidade de m ini-
mizar o número de metodologias torna-se aparente. Soluções cotnpletas exigiam que
várias unidades funcionais trabalhassetn juntas. Isso era considerado uma necessidade
pela gerência sênior, que acreditava que a criação de soluções completas acabaria se
tornando uma melhor prática, a lém de levar à descoberta de outr as melhores práticas.
Uma empresa possuía t rês un idades de negócios est ratégicas (SBUs, strategic
business 11nits), que, devido a mudanças nas exigências dos cl ientes, agora tinham de
traba lhar juntas para cu tnprir requisitos específicos da solução ao cliente. A gerên-
cia sênior instr uiu uma das SBUs a assumir a liderança em condensar todos os seus
processos funciona is em u1na única 1netodologia de gestão de projetos etnpresarial
(EPM, enterprise proiect management). Depois de certo grau de sucesso, a gerência
sênior tentou, sem sucesso, fazer as out ras duas SBUs implementaretn essa metodo-
logia de EPM, que se acred itava ser uma melhor prática. Os argu1nentos oferecidos
foram "Não precisa tnos dela", "Ela não se aplica a nós" e "Não foi inventada aqui".
Relutantemente, o presidente da empresa esclareceu para seus funcionários que não
havia escol ha. Todos usariam a mesma 1netodologia. O presidente está enfrentando
o mesmo desafio com a globalização da aceitação da metodologia. Agora, questões
culturais são importantes.
2.3 Dor de cabeça nº 3: a satisfação do cliente

As empresas t radicionalmente viam cada cliente cotno uma oportunidade de ocorrên-
cia única, e depois que as necessidades desse cliente tivessem sido atendidas, enfatiza-
va-se encontrar novos clientes. Isso é aceitável, contanto que exista uma grande base
de clientes potencia is. Hoje, as organizações voltadas a projetos, a saber, aquelas que
sobrevivem com a renda gerada a partir de utn fluxo contínuo de projetos financiados
pelos cl ientes, estão implementando a abordagem da "gestão de projetos por compro-
misso" . Cotn isso, cada novo cliente potencial é abordado de uma forma similar a utn
"noivado", no qua l a contratada está sol icitando um relacionamento de longo prazo
com o cliente, em vez de uma oportunidade única. Com essa abordagem, as contrata-
das estão vendendo não somente os resultados a serem entregues e soluções completas,
mas também uma disposição a tornar a metodologia de EPM cotnpatível com a meto-
dologia do cl iente. Para manter a sua satisfação e utn relaciona tnento de longo prazo,
os clientes são solicitados a fornecer informações sobre como a metodologia EPM da
cont ratada pode ser estendida à sua organização. A última fase do ciclo de vida da me-
todologia EPM usada pela ABB (Asea, Bro,vn and Boveri ) chama-se "gerenciamento
da satisfação do cliente" e é criada especificatnente para solicitar feedback do cliente
para u1na satisfação do cliente de longo p razo.
Essa n1elhor prática de in1plen1entar a gestão de projetos por compron1isso é po-
derosa, pois permite que a empresa ti re proveito de sua visão de gestão de projetos, a
saber, que a gestão de projetos se transformou em uma con1petência estr atégica para
a empresa, levando a un1a vantagen1 competitiva sustentada. Embora essa aborda-
gem tivesse seu mérito, ela abriu uma caixa de Pandora.
Os cl ientes passaram a esperar ter influência no design da metodologia EPM

da contratada. Un1 fornecedor automotivo decidiu solicitar feedback de uma das
Big Three de Detroit ao desenvolver sua abordagem de EPM. En1bora isso tenha
gerado boa vontade e satisfação do cl iente, gerou un1 problen1a sério com outr os,
que tinham exigências d iferentes e visões diferentes de gestão de projetos. Que grau
de liberdade deve-se dar a um cliente em fazer recomendações para mudanças do
sistema de EPM de uma contratada? É uma boa ideia correr o risco de abri r a caixa
de Pandora para o benefício da satisfação do cliente? Que grau de influência un1
cl iente deve ter sobre o modo como uma contratada gerencia seus projetos? O que
acontece se isso pern1 itir que os clientes con1ecem a dizer às contratadas con10 elas
devem realizar seu t raba lho?
2.4 Dor de cabeça n12 4: mudanças nas exigências do

cliente
Quando a gestão de projetos se torna uma arma competitiva e acaba levando a uma
vantage1n competitiva estratégica, mudanças resultantes das exigências do cliente têm
de ser feitas rapida1nente. O siste1na de EPM precisa ter um processo para gerencia-
mento de configurações pa ra o contr ole das mudanças. A parte do processo de contro-
le de mudanças do sistema de EPM tem de manter a flexibil idade. Mas o que acontece
quando as exigências do cl iente muda tn de tal 1naneira que precisam ser feitas mudan-
ças correspondentes no EPM, e essas mudanças poderiam leva r a resultados negativos
e1n vez de a melhores práticas?
Um fornecedor automotivo de nível 1 passou anos desenvolvendo um sisten1a de
EPM que fosse altamente apreciado pelos clientes para o desenvolvimento de novos
produtos ou con1ponentes. O sisten1a de EPM era visto con10 uma melhor p rática
tanto pelos clientes quanto pela empresa. Mas isso estava prestes a mudar. Os clien-
tes agora estavan1 tentando econon1 iza r dinheiro passando a trabalhar con1 menos
fornecedores. Certos fornecedores serian1 selecionados, tornando-se "provedores de
soluções" responsáveis por grandes seções ou pa rtes do carro em vez de por compo-
nentes individuais . Vários fornecedores de nível 1 adqu ir iram outr as en1presas por
meio de fusões e aquisições a fim de se tornarem fornecedores de componentes. Todo
o sisten1a de EPM tinha de ser mudado e, em muitos casos, ocorreran1 choques cultu-
rais. Algumas das empresas adqu iridas tinhan1 fortes cu ltu ras de gestão de projetos e
suas próprias n1elhores práticas, a inda mais fortes do que as da empresa aqu isitora,
enquanto outras não tinham a menor ideia sobre a gestão de projetos. Para piorar a
sit uação, todas essas empresas eram multinacionais, e questões de global ização assu-
miriam um papel central. Agora tínhan1os n1elhores práticas concorrentes.
Após anos de dificuldades, o sucesso agora estava ao a lcance de muitos forne-
cedores de cotnponentes. As fusões e aquisições tinham sido bem-suced idas, e novos
conjuntos comuns de melhores práticas tinham sido implementados. No entanto, mais
u1na vez, as exigências do cliente estavam prestes a mudar. Os cl ientes agora estavam
pensando em voltar à abordage1n de componentes e1n vez de a abordagem de "pro-
vedor de soluções", acreditando que os custos ba ixariam. Se isso ocorresse em todo o
setor, dores de cabeça colossais surgiriam devio a maciças reestr uturações, desenves-
timentos, mudanças cu lturais e outras mudanças importantes nos sistemas de EPM.
Como as contratadas convencem os cl ientes de que suas ações podem ser negativas
pa ra todo o setor? Além disso, a lgumas empresas que anteriormente era1n bem-su-
cedidas financeiramente ta lvez não fossem mais ter o mesmo grau de sucesso como
fabricantes de co1nponentes.
2.5 Dor de cabeça nº 5: a quem o PMO deve se reportar

As empresas estabelecera1n um PMO como o guardião da propriedade intelectual da
gestão de projetos. Incluídos nas responsabilidades de um PMO estão o planeja1nento
estratégico para a gestão de projetos, o desenvolvimento e o apri1noramento do EPM,
a manutenção de te,nplates, formulários e diretrizes de gestão de p rojetos, o gerencia-
mento de portfól ios de projetos, a orientação de gerentes de projeto inexperientes por
mentores, uma linha direta para a solução de problemas relacionados a projetos e a
manutenção de uma biblioteca de melhores práticas em gestão de projetos. O PMO
passa a ser o guardião de todas as melhores práticas em gestão de projetos.
Embora a criação de um PMO seja considerada como uma melhor prática pela
maioria das empresas, ela coloca uma grande parte da propriedade intelectual nas
mãos de alguns poucos funcionários, e informação é poder. Com toda essa proprieda-
de intelectua l nas mãos de três ou quatro pessoas no PMO, a pessoa a quem o PMO se
reporta poderia possivelmente ter mais poder do que seus colegas. O problema é que
o PMO precisa se reportar aos níveis executivos da gerência, e parece haver uma forte
luta interna nos níveis executivos pelo controle do PMO.
A fim de apaziguar os te1nores de u1n executivo se tornar mais poderoso do que
out ro, as empresas criaram 1nútiplos PMOs, que supostamente são interligados e com-
parti lha1n informações livremente. A Hewlett-Packard possui múltiplos PMOs interli-
gados. A Co1nau possui PMOs na América do Norte, América do Sul, Europa e Ásia,
todos interligados. A Star All iance tem como membros 27 empresas aéreas, cada u1na
com um PMO e todos interligados, sendo na Ale1nanha o PMO de liderança. Esses
PMOs são bem-sucedidos porque as informações e a propriedade intelectual da gestão
de projetos são compartilhadas livremente.
Perm itir a existência de múltiplos PMOs pode parecer ser a coisa certa para agra-
dar cada executivo, mas, em alguns casos, gerou dores de cabeça pelo fato de a pro-
priedade intelectual da gestão de projetos não ser mais centra lizada. E, para p iorar a
situação, o que acontece se e.ada executivo, inclusive os de mu ltinaciona is, exigir seu
próprio PMO? Isso poderia acabar sendo visto como uma despesa de gerencia1nento
excessivo e, a menos que a e1npresa possa ver um retorno sobre o investi1nento e1n
cada PMO, o conceito do PMO pode desaparecer, destr uindo, assitn, uma melhor prá-
tica importante por motivos de política interna.
2.6 Dor de cabeça nº 6: o dilema do fluxo de caixa

Para muitas empresas que sobrevivem à base de licitações, o custo de preparar uma
proposta pode variar de a lguns mi lhares de dólares a centenas de mi lhares. Na maioria
dos casos, a gestão de projetos pode não aparecer até depois do cont rato ser adjudica-
do. Os resultados podem ser catastróficos se a realização do benefício no final do pro-
jeto não corresponder à visão ou à 1nargem de lucro esperada durante a preparação
da proposta ou no início do projeto. Quando as empresas desenvolvem u1n siste1na
de EPM e ele funciona be1n, a maioria delas acredita que agora podem assum ir mais
trabal hos. Começam a fazer propostas para todos os contratos possíveis, acreditando
que o sistema de EPM que possuem pode realizar 1nais t rabal ho e1n 1nenos tetnpo e
com menos recursos, sem nenhum co1nprometimento da qualidade.
No verão de 2002, uma grande empresa 1nultinacional estabeleceu um progra1na
de t reinamento em gestão de projetos na Europa para 50 gerentes de projetos multina-
cionais. O vice-presidente executivo falou durante os 10 primeiros minutos da aula e
disse: "A e1npresa agora começará a recusar trabalho". Os gerentes de projeto ficara 1n
i Despesas
planejadas -,._ $
o
>
da contratada $ Conclusão
;
.!!!
::,
do projeto
E
::,
<.>
o
ij "-- Plano de
(.)
pagamento do cliente
Tempo ---+
Figura 2- 2 Curva de despesas.
aborrecidos ao ouvir isso e precisa ra1n de uma expl icação. O vice-presidente executivo
colocou a Figura 2- 2 na tela e esclareceu que a empresa não mais aceitaria projetos
nos quais as margens de lucro fossem menores do que 4- 6% , porque assim estariam
financiando os projetos para seus clientes. A e1npresa estava funcionando como um
banqueiro para seus clientes. A rea lização de benefícios não estava sendo alcançada.
Para reduzir os custos das licitações, a etnpresa estava respondendo a solicitações de
propostas usando bancos de dados de estimativas e1n vez de mão de obra faseada. A
questão do fluxo de caixa não estava sendo identificada até depois de ser dado sinal
verde ao p rojeto.
Embora o financiamento do projeto ten ha se tornado uma prática aceitável, ele
comprime o lucro em mercados já alta1nente competitivos. Para manter as margens de
lucro, as empresas geralmente são forçadas a desconsiderar o que foi d ito ao cl iente
na proposta e designar recursos do projeto de acordo co1n o p lano de pagamento
do cliente em vez de com o cronograma original do projeto apresentado na propos-
ta. Embora isso possa levar a u1na lucratividade no curto prazo, gera lmente resulta
em cronogra1nas alongados, possíveis processos judiciais e insatisfação do cl iente. O
equilíbrio ent re satisfação do cliente, relacionamentos de longo prazo com o cl iente e
lucratividade está gerando uma enorme dor de cabeça. A melhor prática de criar um
sistema de EPM de alto nível pode levar a resultados negativos se a lucratividade não
puder ser mantida.
2. 7 Dor de cabeça nº 7: o dilema da mudança

de escopo
Para etnpresas que dependem de licitações betn -sucedidas para sobreviver, o pote de
ouro geralmente é a quantidade de mudanças de escopo que ocorrem após a aprova-
ção do projeto. O contrato original pode ser sublicitado na esperança de que mudan-
ças de escopo lucrativas geradas pelo cliente ou pela cont ratada venham a ocorrer.
Para a maxitnização do lucro, é u1na 1nelhor prática que u1n processo de controle de
mudanças de escopo faça parte do sistema de EPM.
Ao longo dos anos, os gerentes de projeto fora1n incentivados por seus superio-
res a buscar toda e qualquer 1nudança de escopo que fosse financiada pelos cl ientes.
Mas essas mudanças de escopo hoje estão causando enormes estragos nas ativida-
des de planejamento de capacidade e na desi~nação dos recursos críticos necessários
às mudanças de escopo e a outros projetos. A 1nedida que as empresas a 1nadurecem
na gestão de projetos, os sistemas EPM se tornam mais baseados na internet. Todos
os cronogramas de projetos individuais são incluídos em u1n cronograma tnaster de
modo que a gerência sênior possa ter um quadro real ista dos recursos comprometidos
pelos 90 ou 180 dias seguintes. Isso pennite que a empresa determine que quantidade
adicional de tr abalho ela pode assum ir sem sobrecarregar a base de ,não de obra exis-
tente. Além disso, se for identificado um gargalo de recursos, deve ficar relativamente
claro quantos recursos adiciona is devem ser cont ratados e em que grupos funcionais.
Com a transformação do planejamento da capacidade de uma arte em uma ciên-
cia, os problemas com a obtenção de recursos qualificados para mudanças de escopo
não planejadas aumentam. A maxim ização dos lucros em determinado projeto pode
não ser do interesse da empresa, especia lmente se os recursos puderem ser usados mais
eficientemente em out ras partes da organização. As organizações hoje em dia têm me-
nos pessoal do que precisa tn, por acreditaretn que é melhor ter mais trabalho do que
pessoas em vez de ma is pessoas do que t raba lho. Os executivos têtn de encontrar uma
maneira de equi librar a necessidade de mais recursos adicionais com as 1nudanças de
escopo, a seleção de portfólios de projetos e a pressão sobre o relacionamento profis-
sional entre gerentes de projeto e gerentes de área . Como os executivos hoje conven-
cem os gerentes de projeto de que mudanças de escopo são desnecessárias e de que a
maxim ização de lucros deve ser esquecida?
2.8 Dor de cabeça n1:1 8 : equilibrar

Uma das responsabilidades de utn PMO é fazer o debriefing da equipe de projeto após
a conclusão deste. Isso inclu i captar as lições aprendidas, identificar oportunidades
de aprimoramento do sistema de EPM e atua lizar o banco de dados de estitnativas.
Com a melhoria do bando de dados de estimativas, as empresas percebem que podetn
terceirizar parte do t rabalho dos projetos por um preço significativamente mais baixo
do que custaria rea lizar o mesmo trabalho interna tnente.
Embora essa função possa se tornar uma Ítnportante melhor prática e possa eco-
notnizar algum dinheiro para a empresa, pode haver resultados negativos. Utn banco
recebeu publicidade bastante negativa nos jornais locais quando se descobriu que a
divisão de sistemas de informação sofreria cortes de pessoal em conjunção com u1na
terceirização eficiente etn termos de custos. Uma out ra organ ização também terceiri-
zou seu t rabalho relativo a sistemas de informação a tal ponto que tinha cotneçado a
dar aos seus fornecedores e suas cont ratadas informações confidencia is da empresa.
Gera-se muita dor de cabeça quando os executivos têtn de equilibrar a lucratividade
no curto prazo com a saúde de longo prazo da corporação e as necessidades e expec-
tativas da co1nun idade de partes interessadas.
As 1nelhores práticas são criadas para beneficiar tanto a empresa quanto os traba-
lhadores. Quando a implementação de melhores práticas leva à perda de emprego, a
importância relativa das mel hores p ráticas pode dim inu ir aos olhos dos funcionários.
2.9 Dor de cabeça nº 9 : quando cancelar um projeto

Praticamente todo sistema de EPM se baseia etn fases de ciclo de vida . Cada fase de
ciclo de vida term ina cotn u1na reunião de revisão de fase criada para funcionar como
um ponto de decisão de aprovação/não aprovação para prosseguir à fase seguinte.
Muito poucos projetos parecem ser cancelados nas primeiras reuniões de revisão de
fase. Um motivo é que os gerentes de projeto não necessariamente fornecem todas
as informações essenciais necessárias pa ra tomar uma decisão viável. Os gerentes de
projetos fornecetn infonnações em relatórios de previsão sobre o custo estimado no
momento da conclusão e o prazo de conclusão. O que fica faltando são os benefícios

esperados na conclusão, e essa estimativa pode ser 1na is importante do que o prazo e
o custo. Embora seja compreensível que esse valor possa ser difíci l de obter durante
as fases iniciais do ciclo de vida do projeto, deve-se tentar de tudo para apresentar
esti tnativas razoáveis dos benefícios na conclusão deste.
Se um projeto passa do prazo ou excede o o rçamento, os benefícios esperados
a inda assim podem ser alcançáveis. Da mesma forma, se um projeto fica abaixo do
o rçamento ou é concluído antes do prazo final, talvez não haja motivo para acreditar
que a visão no início do projeto terá sido alcançada na conclusão. Uma empresa deu
início a um conceito chamado de "dias de mapea1nento" (map days), no qual a equipe
periodicamente mapeia seu desempenho até aquele momento. Os 1napas são revisados
junto com a gerência sênior para decidir com certeza se o projeto deve continuar. Esse
conceito pode ser expand ido de modo a incluir possíveis benefícios na conclusão do
p roJeto.
Embora boas metodologias de gestão de projetos sejam melhores práticas e for-
neça1n informações va liosas para a gestão de projetos, o sistema também precisa ser
capaz de fornecer as informações necessárias para a gerência sênior poder to1nar todas
as decisões essenciais. Muito frequentemente, os sistemas de EPM são desenvolvidos
exclusivamente para o benefício dos gerentes de projeto em vez de sere1n do interesse
de toda a empresa.
2.10 Dor de cabeça n11 10: oferecer recompensas

Talvez a maior dor de cabeça enfrentada pela gerência sênior seja o estabelecimento de
u1n sistema equitativo de recompensas/reconhecimento de projetos que faça parte do
programa de cargos e salários. As empresas já reconheceram que a gestão de projetos é
u1n esforço de equ ipe e que oferecer recompensas a equipes de projetos pode ser mais
benéfico do que recompensar indivíduos. A dor de cabeça é como fazê-lo de forma
eficiente.
Há várias questões que precisam ser abordadas:
• Quem determina a magni tude da contribu ição de cada pessoa para o sucesso do
projeto?
• O tempo gasto no projeto deve influenciar o tamanho da recompensa?
• Quem determina o tamanho da recompensa?
• O siste1na de recompensas afetará estimativas futuras, especialmente se as recom-
pensas forem baseadas em custos orçados subutil izados?
• O tamanho das recompensas afetará a seleção de pessoal para projetos futura-
mente?
• Os funcionários migrarão para gerentes de projeto que tenha1n um histórico pré-
vio de sucessos em que grandes recompensas foram obtidas?
• As pessoas se afastarão de projetos de a lto risco, nos quais ta lvez possa não haver
recompensas?
• Os funcionários evitarão ser designados a projetos de longo prazo?
• Os funcionários sindica lizados podetn participar do sistema de recompensas dos
projetos?
Fornecer reconhecimento monetá rio e não 1nonetário é uma melhor prática con-
tanto que seja realizada de maneira equitativa. Deixar de fazê-lo pode destruir até
mesmo os melhores sistemas EPM além de uma cultura corporativa que levou anos
para ser desenvolvida.
2.11 Dor de cabeça nº 11: ter a cultura errada em vigor

Criar a cultu ra corporativa correta para a gestão de projetos não é fáci l. No entanto,
quando há uma forte cultura corporativa etn vigor e ela apoia ativamente a gestão
de projetos de modo que outras melhores p ráticas sejam acessíveis, é mu ito difícil
duplicá-la em outras etnpresas. Algumas culturas corporativas não possuem coopera-
ção entre os participantes e sustentam si los bem protegidos. Out ras culturas baseiam-
-se na fa lta de confiança, e outras ainda fomentam uma atmosfera em que é aceitável
persistentemente om itir informações para a gerência.
Utna empresa de telecomun icações financiou mais de 20 novos projetos de desen-
volvimento de produto que precisavam ser concluídos dentro de um tritnestre especí-
fico para agradar a \Vali St reet e gerar fluxos de caixa que sustentassem o dividendo.
A gerência persistentetnente reagia ma l a notícias ru ins, e o fluxo de informações para
a gerência sênior passou a ser fi ltrado. A metodologia de gestão de projetos foi usada
com moderação por medo de que a gerência fosse reconhecer logo de início a serieda-
de dos problemas de alguns dos projetos.
Sen1 ouvir nenhu1na má notícia, a gerência sênior se convenceu de que os projetos
estavatn progredindo conforme o planejado. Quando se descobriu que n1ais de un1 pro-
jeto estava tendo problen1as sérios, a gerência realizou intensas revisões de projeto etn
todos eles. E,n utn dia, oito gerentes de projetos foram ou dispensados de suas respon-
sabilidades ou demitidos. Mas já era tarde demais, e o problema era, na verdade, a cul-
tura que tinha sido criada. Decepar o portador de más notícias pode destruir siste1nas
de gestão de projetos potencialn1ente bons e di1n inu ir o estado de espírito das equipes.
Em uma outra empresa de telecomun icações, a gerência sênior estimulava a cria-
tividade e dava à força de trabalho a liberdade de ser criativa. Havia ali muitos fun-
cionários técnicos portadores de diplomas avançados. Esperava-se que os funcionários
passassem até 20 % de seu tetnpo tendo ideias para novos produtos. Infel izmente, esse
tempo estava sendo cobrado de volta em qualquer projeto em que os funcionários
estivessem trabalhando no momento, tornando ineficientes, assim, as partes relativas
ao custo e ao cronograma do sistema de EPM.
Embora a gerência aparentemente tenha tido boas intenções, os resultados não fo -
ram os que ela esperava. Novos produtos estavam sendo desenvolvidos, mas o período
de recuperação do investimento estava ficando cada vez ma is longo, enquanto os cus-
tos operaciona is estavam aU1nentando. Os orçamentos estabelecidos durante a seleção
do portfólio de projetos era tn inúteis. Para p iorar a situação, a comunidade técnica
defin ia sucesso de um p rojeto como exceder as especificações, em vez de cumpri-las.
A gerência, por outro lado, definia sucesso co1no a cotnercialização de um produto.
Dado o fato de que entre 50 e 60 novas ideias e projetos devem ser empreendidos para
que utn seja um sucesso comercialmente aceitável, o custo do desenvolvimento de no-
vos produtos estava sugando o dinheiro da empresa, e a gestão de projetos foi inicial-
mente acusada de ser a culpada. Mesmo os melhores sistetnas de EPM não conseguetn
detectar quando o trabalho foi concluído senão observando o dinheiro consu1nido e o
tempo empregado.
Pode levar anos para se criar uma boa cu ltura de gestão de projetos, mas é pos-
sível que ela seja destruída rapidamente por meio dos caprichos pessoais da gerência.
Uma empresa empreendeu dois projetos de P&D de alto risco concomitante1nente.
Estabeleceu-se um prazo de doze meses para cada um deles, na esperança de que a l-
gu1n avanço tecnológico fosse surgir e, 1nesmo se surgisse, a1nbos os produtos teriam
u1na vida úti l de aproximadamente um ano antes de se tornare1n obsoletos.
Cada projeto teve um patrocinador designado dos níveis executivos . Na prin1eira
reunião de revisão de fase, ambos os gerentes de projeto recon1endaram que seus proje-
tos fossem cancelados. Os patrocinadores executivos, para manter as aparências, orde-
naram que os projetos continuassem até a revisão de fase seguinte em vez de cancelar os
projetos enquanto as perdas ainda eram pequenas Os executivos forçaran1 os projetos a
continuarem a se concretizarem. Os avanços tecnológicos fora1n feitos seis meses depois,
e não houve praticamente nenhuma venda con1 nenhun1 dos dois produtos. Só havia
un1a n1aneira de os patrocinadores executivos 1nanterem as aparências - pron1over an1-
bos os gerentes de projeto por tere1n desenvolvido con1 sucesso dois novos produtos e
então, culpar o marketing e vendas por sua incapacidade de encontrar clientes.
Cancelar projetos nunca é fácil. As pessoas gera lmente veem notícias ruins como
u1n fracasso pessoal, um sinal de fraqueza e uma mancha e1n sua carreira. Há que se
compreender que expor um fracasso não é sinal de fraqueza. A lição é clara: qualquer
executivo que sempre toma a decisão certa certamente não está tomando decisões
suficientes, e qua lquer empresa em que todos os projetos são concluídos co1n sucesso
não está trabalhando e1n projetos suficientes e não está aceitando um risco razoável.
2.12 Dor de cabeça nº 12: questões políticas

A conclusão de um projeto exige pessoas. Mas o simples fato de pessoas serem desig-
nadas ao projeto não significa necessariamente que elas se1npre toma rão decisões a
favor do que é mais interessante para o projeto. Quando as pessoas são designadas a
u1n novo projeto, elas se pergunta 1n: "O que eu ganho com isso? Como minha carreira
se beneficiará com essa designação?".
Esse tipo de pensamento gera severas dores de cabeça e pode permea r todos os
níveis da gerência de um projeto, inclusive os responsáveis por sua governança. As pes-
soas tendem a fazer politicage1n para conseguir o que querem, e essas jogadas criam
barreiras que o gerente de projeto tem de superar. As pessoas são motivadas pelas re-
compensas que podem receber da estrutura formal da empresa e também da estrutura
informal de poder político que existe. Barreiras são criadas quando as recompensas
de um indivíduo de qualquer dessas estruturas são ameaçadas. As barreiras levam a
confl itos e podem envolver como o projeto será p lanejado, quem será designado a
atividades específicas, especialmente as atividades que podem receber alta visibil idade,
que a bordagem adotar para solucionar um problema e out ros itens desse tipo que ge-
ralmente são questões de segundas intenções. Algumas pessoas podem até querer ver o
projeto fracassar se isso as beneficiar.
O jogo de cintura político é essencial para o gerente de projetos de hoje. Não se
pode mais confiar somente em co1npetências técnicas ou gerenciais. É preciso com-
preender a natureza política das pessoas e organizações co1n quem se está lidando,
e que política e conflitos são inevitáveis e são u1n estilo de vida no gerencia1nento de
projetos. Os gerentes de projeto do futuro têm de se tomar pol itica1nente astutos. In-
felizmente, embora haja alguns livros publicados sobre política na gestão de projetos,
pouco se pesquisou sobre o assunto em comparação a out ras á reas do Guia PMBOK®.
Riscos políticos
E1n projetos grandes e co1nplexos, a política costuma ser tratada como um risco polí-
tico, especia lmente quando o projeto está sendo conduzido no país hospedeiro e está
sujeito a interferência governa1nental ou violência política. Os fatores que geralmente
são considerados como parte dos riscos políticos incluem:
• Mudanças políticas, como a eleição de um novo partido que chega ao poder
• Mudanças na política fiscal, na política trabalh ista ou na política de contratação
pública do país hospedeiro
• Nacional ização ou confisco indevido de ativos e/ou propriedade intelectual de u1n
proJeto
• Conflitos civis resultantes de u1n golpe, atos de terrorismo, sequest ros, pedidos de
resgate, assassinatos, guerras c1v1s e insurreições
• Mudanças significativas das taxas de inflaç.ã o resultando em políticas de conver-
são monetária desfavoráveis
• Problemas contratua is como cancelamento de licenças e falta de pagamentos
Tendemos a incluir muitos desses riscos no escopo dos fatores a 1nbientais da em-
presa que são de responsabil idade do patrocinador do projeto ou do com itê de gover-
nança. No entanto, quando o projeto está sendo conduzido no país do hospedeiro,
nonnalmente é o gerente de projeto que tem que lidar com os riscos políticos.
Quanto maior e n1ais complexo o projeto, maior o custo excedente e, quanto
n1aior o custo excedente, maior a probabilidade de intervenção política. Em alguns
países, como os Estados Un idos, passar o problema ad iante para camadas hierár-
quicas superiores sign ifica que o problen1a acabará nas mãos do pat rocinador do
projeto. Mas em outros países, especialmente en1 países de mercados en1ergentes, os
problemas podem ultrapassar o comitê de governança e envolver altos oficiais do
governo. Isso ocorre particularn1ente em megaprojetos que são suscetíveis a grandes
custos excedentes.
Motivos para se envolver em jogos políticos

Há inúmeras razões pelas quais as pessoas se envolvem em jogos políticos. Alguns
motivos comuns incluem:
• Querer manter o controle sobre recursos escassos
• Buscar recompensas, poder ou reconhecimento
• Manter a imagem própria e va lores pessoais
• Ter segundas intenções
• Ter medo do desconhecido
• Ter controle sobre quem fará viagens de negócios para lugares exóticos
• Ter controle sobre informações importantes, uma vez que informação é uma fonte
de poder
• Fazer outras pessoas realizarem seu trabalho por você
• Enxergar apenas o que se quer enxergar
• Recusar-se a aceitar ou a admitir derrota ou fracasso
• Ver más notícias como um fracasso pessoal
• Ter medo de expor erros aos out ros
• Ver um fracasso co1no um sinal de fraqueza
• Ver um fracasso co1no a lgo prejudicia l à sua reputação
• Ver um fracasso co1no a lgo prejudicia l à sua carreira
Todos esses são motivos que podem beneficiá-lo pessoalmente. Há ta tnbém a po-
lítica negativa, quando alguém se envolve em jogos políticos com a intenção de pre-
judicar outros, o que pode, por sua vez, acaba r por beneficiá-lo pessoa lmente. Alguns
exetnplos são:
• Querer ver o projeto fracassar
• Ter medo de 1nudanças e.aso o projeto seja bem-suced ido
• Querer prejudicar a i1nagem ou reputação de outra pessoa, especialmente se ela
representar um ent rave ao avanço de sua ca rreira
• Repreender as ideias dos outros para fortalecer sua posição
Situações em que haverá envolvimento em jogos políticos

Embora a política possa esta r p resente etn qualquer projeto e durante qualquer fase
de ciclo de vida do projeto, há algumas situações específicas em que a experiência nos
mostra que é mais provável que ocorram jogos políticos:
• Quando se busca alcançar a maturidade em gestão de projetos em um ambiente
de cultura conservadora
• Durante fusões e aqu isições em que "sen horio" e " inqui lino" se encont ram em
diferentes níveis de maturidade em gestão de projetos
• Ao se tentar fazer toda uma organização aceitar uma metodologia de gestão de
projetos que foi criada por u1na área funcional, e não por um comitê composto de
membros de todas as á reas funcionais (i.e., a síndrome do "isso não foi inventado
aqu i")
• Quando não se acredita que o projeto possa ser concluído com sucesso e se quer
proteger-se
• Ao ter de mudar seus hábitos profissionais e ter de fazer as coisas de modo dife-
rente se o projeto for betn -sucedido
• Quando ocorretn problemas, e não se sabe aonde eles acabarão chegando para
serem resolvidos
• Caso se acredite que equipes virtuais estão livres de jogos políticos no projeto
• Quanto maior e mais cotnplexo o projeto, pois são maiores as chances de interfe-
rência política
• Quando maior o tamanho do comi tê governa tnenta l, pois há 1naior chance de
surgiretn desacordos e problemas políticos
• Quando não se consegue compreender as práticas de gerenciatnento eficiente de
relaciona tnento com as partes interessadas
• Quanto 1na is poder as pessoas detiverem no projeto, por ser maior a chance de
que elas se envolva tn em jogos políticos
• Quando há funcionários reconhecidos como "celebridades", mais propensos a se
envolverem em jogos políticos do que os funcionários comuns.
O comitê de governança
A política nos projetos nonnalmente acaba pressionando o com itê em un1a direção dife-
rente da declaração de trabalho (SOW, Statement of \Vork) original. Essa pressão pode
se originar en1 sua própria gerência sênior, en1 a lguns dos men1bros de sua equ ipe de
projeto, no cliente e até mesn10 em algun1as das partes interessadas. Cada parte deseja um
resultado leven1ente diferente, e o trabalho do c01nitê é tentar encontrar uma maneira de
agradar a todos.
A solução 1nais simples parece ser a criação de utn com itê composto de gerentes
sênior de sua empresa, representantes da empresa do cliente e representantes de vários
grupos de partes interessadas. Aparentemente, pode-se deixar o comitê resolver todos
os conflitos entre si e dar uma orientação unificada para o projeto. Obter suporte de
uma camada hierárqu ica superior parece a coisa certa a se fazer. Infel izmente, a inda
existe a possibi lidade de que o comitê não consiga chegar a um acordo, e, 1nesmo que
eles pa reçam estar de acordo, certos metnbros do comi tê podetn ainda tentar fazer
politicagem "por trás dos bastidores". A existência do comitê de governança não eli-
mina a politicagem nos projetos. As pessoas que formam o cotn itê gera lmente fazetn
politicagem a fim de ampl iar sua base de poder.
A ma ioria das empresas possui fundos limitados disponíveis para projetos. O re-
sultado é uma concorrência no nível executivo por financiamento para o projeto, que
pode ser do interesse de uma área, mas não necessariamente de toda a empresa. Os
executivos podem fazer politicagem pa ra conseguir que seus projetos sejam aprovados
antes de todos os out ros, vendo isso como utn aumento de sua base de poder. Porétn,
o com itê de governança pode incluir executivos das áreas funciona is que perdera tn
a batalha por financiamento de projetos, e eles podem tentar exercer u1na influência
política negativa sobre o projeto, chegando ao ponto de torcer para o seu fracasso. O
resultado é o gerente de projeto ser designado e colocado em cena depois da aprova-
ção do projeto, nunca compreendendo totalmente, até o projeto já estar em uma fase
bastante avançada, a politicagetn que foi feita durante sua aprovação e início.
Amigos e inimigos
E,n geral é d ifícil identificar rapidamente quem são seus a tn igos e quem são seus ini-
migos. Nem todas as pessoas com intenções políticas são inimigos. Algumas podetn
estar fazendo pol iticagem por seu interesse. Portanto, é vantajoso identificar, se pos-
sível, qua is das pessoas que possuem interesses pessoa is são suas amigas e quais são
inimigas. Isso significa que você tem de se comunicar cotn elas, talvez mais informal
do que formahnente, para compreender suas intenções. Ana lisar a linguagetn corporal
geralmente é uma maneira de tentar adivinhar de modo prelim inar se alguétn é seu
amigo ou inÍlnigo. Uma forma possível de classificar as pessoas pode ser:
• Verdadeiros apoios: Pessoas que demonstram aberta tnente sua disposição a apoiar
você e sua posição no projeto.
• "Ern ci1na do muro": Pessoas que você acredita que irão apoiá-lo ao longo do can1i -
nho, contanto que você prove a elas que merece sua confiança e apoio. Talvez você
tenha de dedicar um tempo extra a mostrar-lhes sua posiç.ão e ganhar seu apoio.
• Verdadeiras incógnitas: Ao contrário dos que estão "em cima do muro", que po-
dem ser convencidos do seu modo de pensar e vi rar seus aliados, essas pessoas
são verdadeiras incógnitas. Elas podem ter segundas intenções que não são do seu
interesse, ,nas são relativamente caladas e podem ainda não ter expressado suas
preocupações. Essas pessoas podem representar uma séria a tneaça caso se opo-
nham à direção que o projeto está tomando.
• Verdadeiros initnigos: Pessoas que deixaram bem claro que provavelmente não
apoiarão suas ideias . Você cotnpreende sua posição e provavelmente está certo de
como elas responderiam a você e à d ireção que seu projeto está tomando.
Atacar ou recuar
Quando as pessoas fazem policie.agem em projetos, há dois fatos que parecem ser
dados e.orno garantidos. Primeiro, essas pessoas provavelmente têm experiência em
pol iticagem e, segundo, elas esperam sair ganhando. Dependendo de quem o conflito
envolve, você terá de decidir se deve atacar agressivamente ou se deve recuar. Não to-
mar providência a lguma é uma forma de distancia1nento que certamente o fará perder
a bata lha.
A regra número um das bata lhas é reunir o máximo de informação possível sobre
seu inimigo. Por exemplo, como parte do gerenciamento dos relacionamentos com as
pa rtes interessadas, podemos 1napeá-las de acordo com a Figura 2- 3.
O 1napeamento das pa rtes interessadas é mais frequentemente exibido em uma
grade que compara seu poder e seu nível de interesse no projeto.
• Gerenciar de perto: Pessoas com um alto nível de poder e interesse, que podem
determinar o sucesso ou fracasso de seu projeto. Você precisa fazer o máximo
esforço para satisfazê-las. Esteja ciente de que há fatores que as fazem 1nudar de
quadrante rapidamente.
• Manter satisfeitas: Pessoas co1n alto nível de poder, mas menos interessadas, que
também podem determinar o sucesso ou fracasso de seu projeto. Você tem de fazer
certo esforço para satisfazê-las, mas não com u1n nível excessivo de deta lhes de
possa levar ao tédio ou a um tota l desinteresse. Elas podem não se envolver até a
conclusão do projeto e.star próxitna.
• Manter informadas: Pessoas co1n um poder li1nitado, 1nas com u1n grande inte-
resse no projeto. Elas podem funcionam como um sistema de alerta precoce na
abordagem de problemas e podem ser perspicazes para auxiliá-lo com a lgumas
questões técn icas. Essas são as partes interessadas que gera lmente oferecem opor-
tunidades ocultas.
• Apenas 1nonitorar: Essas são pessoas com poder limitado e que talvez não estejam
interessadas no projeto, a menos que ocorra un1 desastre. Forneça-lhes algun1as in-
formações, n1as não tão detalhadas ao ponto de fazê-las perder o interesse ou ficar
entediadas.
Quando você ent ra na ofensiva e ataca as pessoas que estão fazendo pol iticagem,
precisa ter não somente mun ição, mas também um apoio, se necessário. Tem de estar
preparado para most rar como as decisões políticas podem afetar as restrições ao pro-
jeto além das bases de referência que o aco1npanham. Dependendo do nível de poder e
influência de seu oponente, de acordo com a Figura 2- 3, você pode precisar que outras
pa rtes interessadas o ajudem a pleitear seu e.aso. É extrema1nente benéfico ter apoio
Manter Gerenciar
satisfeitas de perto
Apenas Manter
monitorar fnlonnadas
Baixo Alto
Nível de interesse das partes interessadas
Figura 2- 3 Mapeamento das partes interessadas.

no 1nesmo nível de posição de poder ou ma is alto do que as pessoas que estão fazendo
politicagem.
Nem todas as bata lhas políticas precisam ser vencidas. As pessoas que fazem po-
liticagetn e possuem grande quantidade de poder podem também ter a autoridade
para cancelar o projeto. Nesses casos, recuar pode ser a única opção viável. Se você
realmente deixar de fora as pessoas que estiverem fazendo jogadas de poder, a situação
pode se deteriorar a inda ma is. Sempre há a chance de que você tenha de t rabal har
com as mesmas pessoas no futuro. De qua lquer maneira, a melhor abordagem é tentar
compreender aqueles que estão fazendo politicagem, os motivos que os levam a tal, e
que grau de poder e influência eles têm sobre a decisão final.
A necessidade de uma comunicação eficiente

Embora nem sempre seja possível determinar quando alguém está fazendo ou pre-
tende fazer politicagem em seu projeto, há a lguns sinais indicativos de que talvez isso
esteja acontecendo. Alguns exemplos são quando as pessoas:
• Não se importam com os seus sentimentos
• Evitam discutir problemas sérios
• Nunca pedem sua opinião sobre o assunto
• Procrastinam a tomada de decisões
• Têm pretextos para não conclu ir certas providências
• Só discutem os itens que podem beneficiá-las pessoalmente
Embora os gerentes de projeto possam não ter cont role sobre esses sinais indi-
cativos, eles podem p iorar a situação devido a uma co1nunicação ineficiente. Para
min imizar o impacto político sobre utn projeto, o gerente de projeto deve considerar
adotar as seguintes práticas:
• Escutar cuidadosamente antes de falar e não tirar conclusões precipitadas.
• Certificar-se de ter compreendido o que os out ros estão dizendo e tentar enxergar
a questão a partir do ponto de vista deles.
• Acompanhar toda comunicação inforn1al de un1 men1orando que resuma o que foi
discutido, para garantir que não tenha ocorrido nenhmn 1nal-entendido.
• Antes de declarar seu ponto de vista, certificar-se de ter reunido todas as informa-
ções de suporte que forem necessárias.
• Certificar-se de ter uma clara compreensão de como a cultura afeta o modo como
. .
as pessoas se comunicam com voce.
• Se você precisar fazer críticas, certificar-se de que elas sejam const rutivas, e não
.
pessoais.
• Ao resolver questões políticas, ter consciência de que sempre haverá aqueles que
saem ganhando e aqueles que saem perdendo. Não se t rata apenas de escolher utn
vencedor. Você também tem de expl icar para todos por que você selecionou u1na
determinada abordagetn e, da mesma forma, por que as outras abordagens não
foram consideradas. Isso tem de ser feito com tato.
• Se a situação não puder ser gerenciada eficientemente, não ter vergonha de perdir
conselhos e assistência à gerência sên ior.
• A ineficiência na comunicação encoraja mentiras, o que, por sua vez, gera a inda
mais politicagem acompanhada por um alto grau de falta de confiança.
Os gerentes de projeto têm de ser cuidadosos ao discutir política cotn os membros
de equipe, o cliente e as partes interessadas. As informações podem ser mal entendidas
ou filtradas, especia lmente se as pessoas ouvirem o que querem ouvir. O resultado
pode ser ainda mais politicagem quando não se esperava, e amigos pode1n faci lmente
se tornar n11m1gos.
Poder e infl uência

Habilidades de eficiência na comunicação não podem, por si só, resolver todas as
sit uações políticas. Para con1preender por que, precisamos saber con10 a gestão de
projetos geralmente funciona. Se todos os projetos ficassem dentro da hierarquia tra-
dicional, alguém teria a autoridade máxima para solucionar problemas políticos. En-
tretanto, como a maioria dos projetos é gerenciada de fora da hierarquia tradicional,
o ônus da resolução de conflitos norn1aln1ente fica nas n1ãos do gerente de projeto,
mesmo que haja um con1itê de governança. O comitê pode muito ben1 ser a causa do
conflito. De modo superficia l, pode parecer que a solução mais simples seja dar ao
gerente de projetos autoridade suficiente para solucionar problen1as políticos, mas
os projetos normalmente são executados fora da hierarquia tradicional, lin1itando,
então, a autoridade do gerente de projeto. Essa falta de autoridade forn1a l d ificulta
o seu trabalho. Embora o tern10 de abertura dê aos gerentes de projeto certo grau
de autoridade para determinado projeto, a maioria deles ainda ten1 limitações, pois:
• Precisam negociar com gerentes funciona is por recursos qualificados.
• Podem não conseguir remover funcionários de u1n projeto sem a cooperação do
gerente funcional.
• Gera lmente não têm responsabi lidade direta pela adminsitração salarial.
• Podem não ter pratica1nente nenhum poder de recompensa ou punição.
• Talvez não consigam forçar os funcionários a t rabalharem em seus projetos se
estes forem designados a diversos projetos ao mesmo tempo.
Com a fa lta de poder de cargo que a hierarquia tradicional tem, e sem a capaci-
dade de recompensar ou punir, o gerente de projeto tem que depender de outras for-
mas de poder e da capacidade de influenciar as pessoas. Habi lidades comportamentais
como eficiência na co1nunicação, técnicas de motivação, gerenciamento de confl itos,
poder de barganha e de negociação são essenciais para resolver problemas políticos.
Infelizmente, a 1naioria dos gerentes de projeto não possui tenacidade política e possui
pouca habil idade de resolução de conflitos.
Gerenciando a política nos projetos

Embora a política seja inevitável nos projetos, há providências que o gerente de pro-
jetos pode tomar para minim izar ou cont rolar os problemas políticos. Algumas delas
incluem:
• Levante o máximo de infonnação possível sobre a situaç.ã o política.
• Certifique-se de que todos compreendam integra lmente o impacto da situação
política sobre as bases de referência do projeto.
• Tente enxergar a situação através dos olhos da pessoa que está fazendo politica-
gem.
• Tente formar uma coalizão com as pessoas que estão fazendo politicagem.
• Veja se seu patrocinador ou o co1nitê de governança pode isolá-lo da pol iticagem.
• Tenha um processo de tomada de decisões estruturado como parte de sua metodo-
logia de gestão de projetos, o que pode reduzir parte da politicagem.
• Tente determinar a posição política das pessoas através da leitura de sua lingua-
gem corporal.
• Se o problema político não puder ser solucionado rapidamente, demonstre estar

disposto a chegar a um consenso, contanto que a integridade do projeto não seja
sacrificada.
O poder gera a política, e a política, por sua vez, gera poder. Esperar gerenciar utn
projeto sem nenhuma interferência política é pura ilusão. Não podemos prever o com-
portamento do cliente e das pa rtes interessadas. Às vezes, a situação política ocorre
sem dar nenhum sinal de aviso anterior.
Ninguén1 consegue chegar a um acordo quanto à definição de política orga-
nizacional ou de projeto. A política pode assumi r mu itas formas e tan1anhos. Por-
tanto, o gerente de projeto p recisa desenvolver habilidades comportamentais supe-
riores para lidar com sit uações políticas. O perigo de não consegu ir lidar com elas
corretamente é o redirecionan1ento ou o n1au direcionan1ento do projeto.
2.13 Dor de cabeça nº 13: os Sete Pecados Capitais

Por n1a is de 40 anos, a área da gestão de projetos rendeu livros d idáticos, artigos
de jorna l e artigos acadêmicos que discuten1 as causas de fracassos de projetos.
Jnfelizn1ente, n1u itas das anál ises parecen1 enxergar o fracasso de modo superficial.
Ao tentar descobrir a raiz de um problen1a, normaln1ente procuramos alguém em
quem pôr a cu lpa prin1eiro na empresa da cont ratada em vez de em nossa en1presa.
Se isso não der certo, só então começamos a subir a h ierarquia de nossa própria
empresa, enfocando a equ ipe de projeto, seguida pelo gerente de p rojeto. Quando
encont ran1os a lguém en1 quem pôr a culpa, a busca parece ter terminado, e nos
sentin1os confortáveis por termos descoberto a causa do fracasso.
É da natureza humana começar a aponta r culpados primeiro na base da hierarquia
organizacional, não no topo. Contudo, frequentemente a verdadeira causa do fracasso
é o resultado das ações (ou da falta delas) e decisões tomadas no topo da organização,
e não em sua base. Faz parte ta tnbém da natureza humana tomar decisões baseadas
em como somos afetados pelos Sete Pecados Capita is : inveja, ra iva/ira, orgul ho, ava-
reza, preguiça, luxúria e gula. Decisões baseadas nos Sete Pecados Capitais, sejam elas
tomadas no topo ou na base da organizaç.ã o, podem ter consequências terríveis para
os projetos. Às vezes os pecados estão ocultos e não são faci lmente reconhecidos por
nós ou pelos outros. Simplesmente não vemos ou sentimos que estamos pecando.
Os Sete Pecados Capitais afetam todos nós mais cedo ou mais tarde, apesar de
nos recusarmos a admiti-lo. Alguns de nós podem ser afetados por apenas utn ou
dois dos pecados, enquanto outr os podem sucumbir a todos os sete. Infel izmente, o
nível máximo de danos pode ocorrer aos projetos quando os pecados influencia tn o
modo como aqueles que ocupam cargos mais altos da gerência estão relacionados a
projetos, seja como patrocinador ou como mem bro de um grupo de governança. Más
decisões no topo da hierarqu ia, especialmente quando baseadas em emoções em vez de
em questões práticas, podem coloca r o projeto em um caminho destrutivo até mesmo
antes de sua data de início.
1
Os Sete Pecados Capitais
O tenno "Sete Pecados Capitais", também chamados de "Sete Pecados Mortais", "Ví-
cios Capita is" ou " Pecados Cardeais", é uma classificação de vícios objetáveis. Origi-
• Adaptado da \Vikipédia, a enciclopédia livre.

na lmente, faziam pa rte da ética cristã e são usados desde os pritnórdios da era cristã
para educar e instr uir fiéis quanto à tendência da humanidade decadente a cometer pe-
cados. A versão dos pecados reconhecida atuahnente engloba ira, ganância, preguiça,
soberba, luxúria, inveja e gula. Parte ou todos os pecados foram discutidos ao longo
das quatro últimas décadas a partir de d iferentes perspectivas nos escritos rel igiosos
do Cristianismo, Hinduísmo, Islam ismo, Budismo e Judaísmo. Ao longo dos anos,
os pecados foram mod ificados e d iscutidos por clero, filósofos, psicólogos, autores,
poetas e educadores.
Uma breve descrição dos Sete Pecados Capitais aparece na Ta bela 2- 1. Cada um
dos pecados pode estar relacionado a um animal, uma cor específica e mesmo a uma
punição no inferno por cometê-lo.
Em um ambiente de projetos, qualquer um desses pecados, ou todos eles, pode
fazer pessoas racionais tomarem decisões irraciona is, e isso pode ocorrer e1n qualquer
nível dentr o da hierarqu ia organizacional. E1n alguns níveis, a existência dos pecados
pode ter u1n maior impacto sobre o desempenho de projetos do que em outros. Se um
pecado é aparente no início de um projeto, más decisões to1nadas na fase inicial po-
dem ter consequências negativas em todas as fases posteriores.
Inveja
• "A inveja é a arte de conta r as bênçãos dos outros em vez de suas próprias ." (Ha-
rold Coffin)
• " Inveja é ignorância. Imitação é suicídio." (Ra lph Wa ldo Emerson)
• "Quando os homens estão tomados pela inveja, menosprezam tudo, tanto o que é
ruim quanto o que é bom." (Publ ius Cornel ius Tacitus)
Inveja é o desejo de possuir o que os outros possuem. Ressentimentos ocorrem quan-
do alguéin não possu i qualidades superiores de um outro, como status, riqueza, sorte,
dotes físicos, características, habilidades ou posição. A inveja pode levar alguén1 a infligir
sofrimento a outra pessoa e a tentar desfazer a vantagen1 de outra pessoa ou impedir que
ela obtenha a vantagen1. A inveja tan1bé1n pode afetar o relacionamento entre pessoas,
con10 quando alguém ignora uma pessoa de que1n sente inveja. A inveja gera lmente é
sinôn imo de ciún1e, amargura, ganância, desdén1 e ressentin1ento.
A inveja pode ser ma ligna ou benigna. A 1naligna apresenta todas as característi-
cas que acabamos de 1nencionar. A benigna pode ser u1na força motivacional positiva
TABELA 2-1 Os Sete Pecados Capitais

Pecado Características Animal Cor Punição no inferno
Inveja O desejo de possuir o que os Serpente Verde Ser colocado em água congelante
outros possuem
Raiva/Ira Um forte sentimento de descon- Leão Vermelho Ser desmembrado vivo
tentamento
Orgulho A necessidade de satisfação Pavão Violeta Ser despedaçado na roda
emocional interna
Avareza O desejo de riqueza ou ganhos Rã Amarelo Ser colocado em caldeirões de
materiais óleo fervente
Preguiça A recusa ao trabalho Caracol Azul claro Ser jogado em um poço de cobras
Luxúria Um desejo, mas não necessaria- Cabra Azul Ser sufocado na fumaça de fogo
mente sexual e enxofre
Gula O desejo de consumir mais do que Porco Laranja Ser forçado a comer ratos, rãs e
o necessário cobras
se encorajar as pessoas a agirem de 1naneira favorável para que os desejos sejam al-
cançados. A inveja benigna normahnente existe na base da hierarquia organizaciona l,
enquanto a inveja mal igna aparece no topo.
As quatro situações a seguir ilustram como a inveja pode levar a desastres no
contexto de projetos:
Situação 1: Fracasso devido a problemas reorganizacionais. Uma etnpresa possu i qua-
tro divisões, cada uma liderada por um vice-presidente sênior. No passado, a maioria
dos projetos permanecia integra lmente dentro de uma única divisão. Cada divisão
possuía sua própria metodologia de gestão de projetos, e o nútnero de projetos bem-
-suced idos superava significativamente o número de fracassos. À medida que o 1ner-
cado começou a mudar, a empresa começou a t raba lhar em projetos que exigiam que
mais de uma divisão t rabalhasse junta no mesmo projeto. Usar d iferentes metodolo-
gias etn utn mesmo projeto se mostrou uma tarefa impossível.
O presidente determinou que deveria haver uma ún ica metodologia, e que todas
as divisões teriam de usá-la para gerenciar projetos. A empresa criou um PMO, e o
presidente designou a utn dos vice-presidentes o cont role do PMO. Funcionários de
cada u1na das t rês divisões foram designados ao PMO na base de um acordo para o
desenvolvimento da metodologia singular.
As pessoas do PMO pareciam t rabalhar ben1 juntas, n1as os quatro vice-presidentes
exigiran1 ter a autoridade final sobre a adoção da metodologia singulaL Cada u1n deles
acreditava que a abordage1n de gestão de projetos usada em sua divisão deveria ser a
força n1otriz para a criação de u1na metodologia singular. Independentemente do design
criado pelo PMO, cada vice-presidente de1nonstrava inveja e ressenti tnento, encontran-
do problemas nas ideias dos out ros, sofrendo da síndron1e do " isso não fo i inventado
aqui". Enquanto isso estava acontecendo, o nún1ero de projetos que fracassaran1 cotne-
çou a aumentar, devido à fa lta de estrutura para sua execução.
Ficou óbvio também para os quatro vice-presidentes que quem quer que, entre
eles, tivesse o cont role do PMO, passaria a ser mais poderoso do que os out ros três,
devido ao controle sobre toda a propriedade intelectual da gestão de projetos. Infor-
mação é poder, e a inveja pelo controle das infonnações tinha afetado a capacidade de
gerenciar e cont rolar projetos eficientetnente. Finalmente, o presidente entrou em cena
e perm itiu que cada vice-presidente tivesse um PMO. Entretanto, os PMOs tinham de
ser interl igados. Isso ajudou um pouco, mas mesmo depois de terem concordado com
uma metodologia comum, cada PMO tentou seduzir os outros PMOs a seguirem seu
modo de pensar e, como esperado, mudanças contínuas ficavam sendo int roduzidas na
metodologia, e os projetos ainda sofriam uma falta de direção. A inveja itnpedia que se
tomassem decisões que eram do interesse de toda a empresa.
Situação 2: Fracasso devido a r ecompensas. Acreditando que um sistema eficiente de
recompensas/bônus motivaria as equ ipes de projeto, a gerência sên ior anunciou que
seria1n dados bônus a cada equipe baseados na lucratividade de seus projetos. A etn -
presa sobrevivia à base de licitações para ganhar contratos, e a maioria dos projetos
estava na casa dos milhões de dólares. Os gerentes de projeto rapidamente aprenderam
que grandes bônus podian1 ser oferecidos se as estimativas de custo do projeto fossem
bastante infladas durante o processo de licitação e os contratos pudessem ser fechados.
Dessa maneira, os lucros reais de alguna contratos poderian1 exceder as metas de lucros.
Embora a empresa tenha perdido alguns contratos que esperava ter fechado de-
vido aos custos inflados, alguns dos bônus dados aos gerentes de projeto no final
dos contratos tinham tamanhos similares aos bônus dados a alguns dos executivos.
Muitos dos executivos, então, passaram a sentir inveja das pessoas abaixo deles que
estavam recebendo bônus tão altos. Devido à inveja, os executivos, então, mudara tn
a política de bônus, e parte do fundo dos bônus seria distribuída ent re os executivos,
mesmo que estes não estivessem agindo como pat rocinadores de projeto. Os bônus
dados aos traba lhadores e aos gerentes de projeto foram, então, significativa1nente
reduzidos. Alguns dos traba lhadores, consequentemente, passaram a sabotar alguns
dos projetos só para não verem os executivos receberem bônus que eram concedidos
à custa dos trabalhadores.
Situação 3 : Fraca sso d evido a sabotagens. Paul era d iretor de operaçôes de uma
en1presa de médio porte. A sua en1presa estava no processo de estabelecer un1 PMO
que se reporta ria diretamente ao diretor executivo (CEO). Paul queria desespera-
damente a nova pos ição de d iretor do PMO, acreditando que ela seria un1 passo
adiante na di reção de um d ia se tornar vice-presidente. O maior concorrente de Paul
para o cargo de d iretor do PMO era Brenda, uma veterana com 22 anos de empresa
e considerada a melhor gerente de projetos. Devido às habi lidades de tomada de
decisôes de Brenda, ela quase sen1pre recebia autoridade total pa ra tomar decisôes
en1 seus proJetos.
Quando Brenda foi designada ao seu último projeto, Paul solicitou e obteve a po-
sição de patrocinador de projeto. Paul ficou cotn inveja das habil idades e da sorte de
Brenda e acred itava que, se pudesse sabotar o projeto dela sem se prejudicar durante
o processo, poderia facilmente ser nomeado diretor do PMO. Pau l impôs lim ites à
autonomia de Brenda e exigiu que, como patrocinador, toda e qualquer decisão impor-
tante tivesse que ter sua aprovação. Pau l continuamente forçava Brenda a selecionar
a lternativas não ótimas quando algumas decisôes tinham de ser tomadas. O projeto de
Brenda foi quase utn desastre, e Paul, posteriormente, foi nomeado diretor do PMO.
A inveja pode nos forçar a causar sofrimento aos outros pra conseguirmos o que
queremos. Pau l conseguiu sua promoção, mas os trabalhadores e Brenda sabiam o que
ele tinha feito. O relacionamento profissiona l de Pau l com os especial istas funcionais
no assunto se deteriorou.
Situação 4: Fracasso no relacio namento. Jerry e dois de seus am igos moravam perto
uns dos outros e entraram para a empresa exatamente ao mestno tempo; Jerry traba-
lhava em gestão de projetos, e os outros dois, etn engenharia. Eles formaram um grupo
de ca rona sol idária e iam e voltavam juntos do t rabalho todos os dias. O três também
socializavam fora do trabalho.
Dois anos depois de entrar para a empresa, Jerry tinha recebido sua segunda pro-
moção, enquanto os outros dois não tinham recebido nenhu1na. Os out ros dois traba-
lhadores ficara tn com inveja do sucesso de Jerry a ponto de pararem de socia lizar e de
dar caronas para ele. A inveja se tomou tão forte que os dois chegavam até a se recusar
a trabalhar nos projetos de Jerry. Os trabalhadores nunca demonstraram visivelmente
sua inveja de Jerry, mas suas açôes falavam mais alto e deixavam bem claro como eles
realmente se sentiam.
Raiva (ou Ira)

• "Para cada minuto que você passa com raiva, você perde sessenta segundos de
fel icidade." (Ralph Waldo Emerson)
• "Fale quando está com raiva - e você fará o discurso do qual mais se a rrependerá
na vida." (Dr. La,vrence J. Peters)
• "A raiva nunca ocorre sem motivo, mas raramente o motivo é bom." (Benjamin
Franklin)
• " Raiva e perigo caminham lado a lado." (Anônimo)
• "A raiva, se não for contida, muitas vezes nos causa 1nais mal do que os danos que
provoca." (Sêneca)
A raiva, ou ira, é um forte sentin1ento de descontentamento. Às vezes, fican1os co1n

raiva porque as ações de outros no projeto nos ofenderan1. Outras vezes, demonstran1os
uma raiva desnecessária para deixar a lguén1 extren1amente irritado com o intuito de dar
fi 1n a un1 con1portamento an1eaçador, como contínuos desvios de cronograma ou custos
excedentes. Raiva n1u itas vezes é sinônimo de ira, irritação, ódio, fúria e ressentimento.
Quando esta 1nos com raiva, perdemos a objetividade. A raiva que sentimos e de-
monstramos pode aparecer repentina1nente, ou pode ser deliberada. Há vários graus
de raiva. Do lado 1nais leve do espectro, a raiva pode ser uma irritação leve, enquanto
do lado mais pesado pode resultar em fúria e ód io. Nem toda raiva é faci lmente per-
ceptível. Por exemplo, a raiva passiva pode se manifestar como u1n sorriso falso, frieza
no t ratamento, uma reação exagerada a algo, ou verificar as coisas constantemente. A
raiva agressiva pode se manifestar como bullying, expressão de desconfiança, rapidez
da fala ou destrutividade.
Vejamos alguns exemplos de como a raiva pode afetar projetos:
Situação 5: Fracasso devido a unia raiva injusta . Ao selecionar o portfólio de 20 pro-
jetos para o ano seguinte, a gerência sênior estabeleceu os orçamentos e cronogra1nas
sem nenhum dado de suporte sobre o que poderia ou não ser rea lista. Para piorar a
situação, os pat rocinadores executivos de cada projeto afirmaram enfaticamente que
não tolerariam desvios de cronograma ou custos excedentes. As equipes de projeto
desenvolvera1n o plano de projeto deta lhado e, em o ito de 20 projetos, as equipes
determ inaram que os orçamentos e cronogramas produzidos pela gerência sênior não
eram realistas. Em vez de informar a gerência sênior imediata1nente que a percepção
que eles tinham sobre orçamento e cronograma talvez estivesse errada, as equipes
começara1n a executar os projetos e torcer por um 1nilagre. As equ ipes sentiam que
essa era uma abordagem 1nelhor do que causar a ira da gerência sênior quando fosse1n
informados da situação.
As oito equipes foram malsucedidas em sua busca por um milagre. Após alguns
meses, a gerência sên ior fez uma anál ise sobre a saúde de um dos oito projetos e
descobriu a verdade: o projeto estava se sa indo ma l. Realizou-se, então, uma aná lise
sobre a saúde dos 20 projetos e ficou claro que oito dos projetos estavam enfrentando
problemas, tanto financeiros quanto técnicos. A gerência sênior ficou enfurecida co1n
o fato de não ter sido informada sobre isso anteriormente, cancelou os o ito projetos
problemáticos e demitiu todos os oitos gerentes de projeto em um mesmo d ia.
Parte da culpa certamente ca i nas mãos das equipes de projeto por não terem in-
formado a gerência sênior mais cedo. Ent retanto, grande parte da cu lpa teria de ficar
nas 1nãos da gerência sênior, especialmente quando eles têm um histórico de compor-
tamentos dominados pela ira que ta lvez não tenham justificativa. Quando as equipes
de projeto acred itam que, por causa de problemas, serão tratadas pelo topo da hie-
rarquia com raiva, e não apoio, a gestão de projetos pode não ter êxito, e os projetos
fracassarão. Más notícias gerahnente são filtradas para evitar a ra iva.
Situação 6 : Fracasso devido a segundas intenções. O diretor executivo de TI (CIO)
tornou-se o patrocinador de projeto de um projeto de TI de US$25 milhões progra1na-
do para durar en1 torno de un1 ano. O CIO estabeleceu 1° de outubro como a data e1n
que o projeto iria "entrar em operação". Durante uma revisão do status do projeto e1n
julho, o CIO foi inforn1ado pelo gerente de projeto de que a data de início de operaç.ão
não era realista. O CIO ficou furioso e perguntou: "Que proporção do software estaria
operacional en1 l Qde outubro?". O gerente de projeto respondeu, "Talvez 10%".
O CIO abandonou a reunião após demonstrar raiva, cha1nando a equipe de proje-
to de " idiotas incompetentes". O CIO, então, autorizou uma quantidade significativa
de horas extras e concedeu à principal cont ratada quase US$5 m ilhões em custos adi-
cionais se eles pudessem conseguir que pelo menos 50% do software estivesse opera-
ciona l no dia 1Q de outubro e 70'% ou mais até l Qde novembro . O CIO sabia que seu
bônus corporativo de fim de ano estava parcialmente at relado à implementaç.ã o desse
projeto, e com 70% do software operacional, seu bônus seria sign ificativo. Quando o
projeto foi finalmente concluído, em fevereiro, o comitê executivo o considerou co1no
um fracasso parcial devido aos US$5 mi lhôes em custos excedentes e o gerente de pro-
jeto foi repreendido. Entretanto, o CIO recebeu seu bônus.
Situação 7: Fracasso devido à filtragem de inforn1ações. A gerência sênior de uma
agência governamental estabeleceu u1na cultura em que más notícias seria filtradas
à medida que fossem su bindo pela hiera rqu ia organizacional. Perm itir que 1nás no-
tícias chegassem ao topo seria um convite à fúria e à revolta do topo em relação aos
projetos. Portanto, no 1no1nento em que as informações chegavam ao topo, grande
pa rte das 1nás notícias já tinham desaparecido, e os riscos associados ao projeto eram
ocultados. O resultado de um projeto foi exatamente como os especialistas em riscos
técnicos previram: sete astronautas foram 1nortos quando a espaçonave Challenger
2
explodiu durante a decolagem. Houve out ros fatores, também, que levaram a esse
desastre. Durante uma reunião do comitê do Congresso para analisar a causa da fata-
lidade, o co1nitê perguntou a um especia lista no assunto: "Por que você não explicou
para a gerência sênior quais eram os riscos?". O especia lista afirmou, "Eu não me re-
porto adminstr ativamente à gerência sên ior. Minha responsabilidade era informar isso
ao 1neu chefe e ele, por sua vez, deveria ter informado seus superiores".
Situação 8: Fracasso devido a uma crença coletiva. U1na crença coletiva é um dese-
jo ardente e, muitas vezes, cego de realizações - independente1nente do custo e das
consequências. Quando existe uma crença coletiva, especiahnente nos níveis mais altos
da gerência, organ izações racionais co1neçam a tomar decisões irracionais, e qualquer
desvio da crença coletiva é recebido com raiva. As pessoas que questionam a crença
coletiva ou desafiam o progresso são afastadas do projeto ou severamente repreendi-
das. Para tr aba lhar nesses projetos, deve-se suprimir a raiva e nadar a favor da maré,
independentemente do resu ltado. Esses projetos podem ser sucessos técnicos, 1nas fra-
cassos financeiros, nunca cumprindo integralmente a estratégia corporativa.
3
Um bom exemplo disso é o Projeto Iridium , que fo i um projeto de 11 anos de
duração que at rasou a data de lançamento do serviço em um 1nês. O serviço era uma
rede de 66 satél ites circulando a Terra, que perm itia que se falasse com qualquer pes-
soa em qualquer lugar. As atividades de gestão de projetos realizadas pela Motorola e
pela Iridium LLP era1n ext raordinárias, especialmente se considerarmos que o projeto
resultou e1n mais de mi l patentes e 25 milhões de linhas de código de software. Tecni-
ca1nente, o projeto fo i um sucesso, mas financeira 1nente, foi um desast re, invocando a
raiva quando se tornou aparente que eles não conseguiriam os número de assinantes
do serviço de que necessitavam para chega r ao ponto de equilíbrio. Durante todo o
p rojeto, a ameaça de u1na severa raiva dos superiores, alé1n da existência da crença
coletiva, tornou quase impossível para as pessoas questionar as projeções sobre o nú-
mero de assinantes.
A raiva não precisa ser de1nonstr ada para prejudicar um projeto. A 1nera ameaça
implícita ou o medo da raiva pode limitar o desempenho de uma equipe significativa-
mente.
i Para informações adicionais sobre esse caso, ver Harold Kerzner, Project Ma11agement Case Studfos, 4th
Edirion, Hoboken, NJ: \Viley, 2013; "Case Scudy: 11,e Space Shunle Challenger Disaster·, p. 447-496.
3
Para informações adicionais, yer Harold Kerz.ner, Project Management Case Studies, 4ch Edicion, Hoboken,
NJ: Wiley, 2013; "Case Scudy: l11e Rise, Fall and Resurreccion of Iridium; A Projecr lvlanagemenr Perspec·
rive", p.327- 366.
Orgulho
• "Um homem orgu lhoso setnpre acha que coisas e pessoas estão abaixo dele; e, é
claro, ao olhar para baix o, não consegue ver nada que está aci1na de si 1nesmo."
(C.S. Le,vis)
• "Os cegos não podem ver - os o rgulhosos não querem." (Provérbio russo)
• "A va idade e o orgulho são duas coisas diferentes, embora as pa lavras muitas ve-
zes sejam usadas como sinônimos. Uma pessoa pode sentir orgu lho se1n ser vaido-
sa. O orgu lho está mais relacionado à nossa opinião sobre nós mesmos; a vaidade,
ao que gostaríamos que os outros pensassem de nós." Uane Austen)
• "Raramente somos orgulhosos quando estamos sozinhos." (Voltaire)
Orgulho é uma emoção interna que leva à satisfação pessoal ou ao alcance de
objetivos pessoa is. O orgulho pode ser uma virtude ou simplesn1ente an1or próprio
ou um senso inflado de suas realizaçôes, o que leva a en1oçôe.s estin1ulantes. O orgu-
lho pode ter tanto conotaçôes negativas quanto positivas. En1 um sentido negativo,
o orgulho pode nos fazer inflar nossas rea lizaçôes. Em un1 sentido positivo, pode
ser um apego às ações dos outros ou um sentin1ento de satisfação e pertencin1ento,
con10 o orgulho naciona l ou émico, ou de ser membro de un1a equ ipe ou um projeto
importante.
O orgulho gera lmente é visto como u1na virtude. O o rgulho inflado pode resultar
em um d istanciamento da verdade, o que às vezes vem acompanhado de autogratifica-
ção. Os antônimos de orgulho são humi ldade e culpa.
Aqui temos alguns exe1nplos de como o orgulho pode afetar um projeto:
Situ ação 9: Fracasso devido à especialização excessiva . Peter era um dos engenheiros
mais experientes da empresa. Sua especialização técnica estava à frente da de todos.
Pediram que ele solucionasse um problema em um projeto. Embora houvesse diversas
opções possíveis, Peter escolheu a opção mais cara, resu ltando na adição de recursos
desnecessários. Peter afirmou que sua solução era a única viável, e o gerente de projeto
concordou relutantemente. Peter via esse projeto como uma forma de 1nelhorar sua
reputação na empresa, independentemente do impacto causado sobre o projeto. Os
recursos desnecessários aumentara1n, e o custo final do produto a ser entregue subiu
significativa1nente. Isso tambétn inflou a autoestima de Peter.
Situação 10: Fracasso devido ao patrocinador errado. Nancy era diretora de marke-
ting. Seu superior, o vice-presidente de marketing, tinha solicitado o desenvolvi1nento
de um projeto de TI bastante sofisticado para a Divisão de Marketing. Era de costume
para o departa1nento de T I agir como o patrocinador do projeto em todos os projetos
de T I, uma vez que eles tivessem sido aprovados. Nancy sabia que seu projeto chama-
ria a atenção dos níveis mais a ltos da gerência. Nancy nunca tinha trabalhado como
pat rocinadora de um projeto antes, mas acreditava que, se pudesse ser a patrocinadora
desse projeto, sua identificação com ele poderia aca rretar uma promoção.
A campanha de Nancy para se tornar a patrocinada foi u1n sucesso. Infeliz1nente,
havia inú1neros proble1nas de TI que tinha1n de ser resolvidos no nível do patroci-
nador e, devido à falta de especia lização de Nancy em TI, ela tinha tomado diversas
decisôes erradas. O projeto acabou se atrasando e ult rapassando o orça1nento, porque
muitas das decisões de Nancy tiveram de ser mudadas em fases posteriores do projeto.
A luta de Nancy por orgulho acabou tendo resultados negativos.
Ganância (Avareza)
• "A ambição não passa de avareza em pernas-de-pau e mascarada." (Wa lter Savage
Landor)
• "A avareza já arruinou ma is ahnas do que a extravagância." (Charles Caleb Colton)

• "A avareza é o vício dos anos decadentes." (George Bancroft)
• "A avareza nonna lmente é a última paixão da vida daqueles que, e1n sua primeira
metade, desperd içaram em nome do prazer e, na segunda, dedicaram-se à a 1nbi-
ção." (Samuel Johnson)
• "A pobreza quer muito, mas a avareza quer tudo." (Publil ius Syrus)
• "A pobreza quer a lgumas coisas, o luxo, muitas coisas, e a avareza, todas as coi-
sas." (Benjamin Franklin)
• "O amor é sempre um estranho na casa da avareza." (Andreas Capellanus)
• "Prejudicar muito para conseguir muito está mais para avareza do que para sabe-
doria." (\Vill iam Penn)
A ganância é um forte desejo por riqueza, bens materiais e objetos de valor para
si. Ela vai além das necessidades básicas de conforto e sobrevivência. A ganância pede
mais do que aquilo de que realmente precisamos ou que rea lmente merece1nos. Tam-
bém pode se manifestar como o desejo por poder, informação, ou cont role de recursos.
Sinônimos da ganância são "avareza" e "cobiça" .
A segu ir, te1nos vários exemplos de co1no a cobiça pode afetar projetos:
Situação 11: Fracasso devido ao excesso de recursos. Karl foi encarregado de um pro-
jeto de dois anos de duração que exigia o envolvimento de 118 pessoas, muitas das
quais eram necessárias apenas em meio expediente. Karl convenceu a gerência sênior
de que esse projeto exigia uma equipe coloca lizada, com todos os designados t raba-
lhando em período integral, e que a equipe pudesse estar em um loca l d istante dos
gerentes de área dos funcionários. A gerência sênior sabia que isso era u1na má ideia,
mas relutantemente, concordou com ela, sabendo muito bem que o projeto agora ti-
nha ma is funcionários e gerentes do que precisava.
No final do primeiro ano, ficou óbvio que nenhu1n dos funcionários do projeto de
Karl tinha recebido promoções ou aumentos salariais por mérito. Os gerentes de área
estavam recompensando somente os funcionários que se encontravam perto deles,
va lorizando-os diariamente. Os funcionários do projeto de Karl agora sentiam que ter
sido designados a esse projeto fadava-os a não receber pro1noções. Vários funcionários
tentara1n sabotar o projeto apenas para poder se livrar dele. Ma is tarde, Karl desco-
briu que vários dos outros gerentes de projeto agora tinha1n por ele forte antipatia
pelo fato de sua ganância por recursos ter prejudicado seus projetos.
Situação 12: Fracasso devido ao poder. Carol era gerente de departamento. Ela estava
orgulhosa do fato de fina lmente ter ocupado esse cargo. Havia rumores por toda a em-
presa de que a gerência sênior estava pensando em fazer cortes de pessoal na empresa.
Carol temia que seu departamento pudesse ser eliminado e que ela perdesse seu cargo
de gerente de departamento.
Para proteger sua pos ição de poder, Carol começou a dar instruções conflitantes
às pessoas de seu depa rtamento. Os trabalhadores procuravam-na ins istentemente em
busca de esclarecimentos quanto às instruções conflitantes. Carol, então, disse aos seus
superiores que as pessoas de seu departan1ento precisavan1 de supervisão diária para
evitar que o desen1penho do departan1ento diin inuísse. Apesar de essa técn ica parecer ter
evitado o corte do departamento de Carol, ela teve um efeito negativo sobre o trabalho
dos funcionários nos projetos. A ganância de Carol por poder e recursos se mostrou
prejudicial à en1presa, n1as benéfica para as necessidades pessoais de Carol.
Situação 13: Fracasso devido à cobiça por bônus . O vice-presidente de engenharia foi
designado como patrocinador de projeto para u1n contrato multim ilionário do Depar-
tamento de Defesa dos EUA (DoD), e Ben era o gerente de projeto. Uma grande fração
do bônus do vice-presidente baseava-se na lucratividade dos projetos que estavam sob

seu controle direto e dos qua is era patrocinador. Esse grande projeto, liderado por Ben,
estava programado para ser concluído em novembro; o contrato de acompanhamento,
que também era bem grande, estava programado para começar e1n fevereiro.
O vice-presidente e Ben concordaram que se deveria estabelecer uma grande re-
serva gerencia l para servir de suporte à equipe de projeto entre os contratos. A equ ipe
tinha de ser des1nembrada em novembro, 1nas não havia nenhuma garantia de que as
mesmas pessoas estaria1n disponíveis para o contrato de acompanha1nento que come-
çaria em fevereiro. Quando o projeto foi concretizado e1n outubro, a reserva gerencial
restante era grande o suficiente para servir de suporte aos recursos com habi lidades
crucia is ent re outubro e fevereiro. Essas pessoas traba lhariam em algumas atividades
que seriam necessárias para o contrato de acompanha1neneto como atividades de pla-
nejamento prel iminar e de planejamento de aquisiçôes.
Quando o contrato fina lmente terminou, em outubro, o vice-presidente disse ao
pessoal do departamento financeiro para registrar a reserva gerencia l nos livros contá -
beis da empresa como um lucro adiciona l do projeto. Isso aumentou o bônus do vice-
-presidente de modo significativo. Ent retanto, sem a reserva gerencial, os recursos co1n
habilidades crucia is foram re1nanejados de volta aos seus departamentos funcionais,
e muitos não estavam disponíveis para trabalhar no contrato de acompanhamento. O
cont rato de acompanha1nento sofreu com custos excessivos e desvios de cronograma,
pois possuía diferentes recursos e u1na nova curva de aprendizagem. Os danos causa-
dos pela ganância do vice-presidente agora se tornavam aparentes.
Preguiça
• "Nada me irrita ma is do que a preguiça crôn ica dos outros. Veja bem, refiro-me
apenas à preguiça menta l. A preguiça física pode ser divina." (El izabet h Huxley)
• "Explicamos nossa pregu iça sob o pretexto de dificuldade." (Marcus Fabius Quin-
tilian )
• "O e1npenho supera dificuldades, a preguiça as cria." (Benjamin Franklin)
• "A preguiça e o si lêncio são as virtudes do idiota." (Benjamin Franklin )
• "Tudo é fácil para o determinado; tudo é difícil para o preguiçoso." (Benjamin
Franklin)
A pregu iça é o ato de estar física, mental e/ou emociona lmente inativo e geral-
mente é caracterizada pela ociosidade. Ela pode resultar em u1n ext remo desperdício
no uso eficiente de pessoas, objetos, habilidades, informações e até mesmo tempo. A
preguiça geralmente nos força a superestimar a d ificuldade da tarefa.
A seguir, temos exemplos de como a preguiça pode afetar projetos:
Situação 14: Fracasso devido à preguiça. Becky foi encarregada de um projeto de um
ano de duração que era relativamente fácil de ser realizado e de baixo r isco. Ao nego-
ciar co1n os gerentes de área para decidir quanto ao pessoal que se envolveria no pro-
jeto, Becky superestimou a complexidade e o risco do projeto, de 1nodo que pudesse
sol icitar as pessoas mais experientes. Isso certamente facilitaria o t rabalho dela. Os
gerentes de área não tinha1n certeza de que as estimativas de Becky sobre risco e com-
plexidade eram válidas, mas decidiram que seria 1nelhor atender às suas solicitações
do que oferecer recursos 1nedíocres e descobrir, posteriormente, que ela estava certa.
Não sobrou 1nuito para Becky fazer no projeto. Os especia listas no assunto fi -
zeram tudo sozinhos. Finalmente, o pessoal experiente do projeto de Becky relatou
aos seus gerentes de área que recursos de remuneração mais baixos deveriam ter sido
designados. Embora o projeto de Becky tenha sido considerado um sucesso e Becky
não tenha tido muito o que fazer, os outros projetos que realmente poderiam ter se be-
neficiado cotn recursos mais expressivos sofreratn com isso. A preguiça normalmente
beneficia um único indivíduo à custa do bem comum.
Situação 15: Fracasso devido ao padrão sindical. Uma empresa possuía um poderoso sin-
dicato que desencorajava novos trabalhadores que estavan1 ansiosos para mostrar aqui lo
de que eram capazes produzindo mais unidades do que o padrão acordado pelo sindica-
to. Pediu-se aos novos trabalhadores que diminuíssem seu ritmo e desfrutassem da vida.
A empresa logo se tornou não competitiva no mercado, e sua base de negócios
começou a se deteriorar. A gerência sênior, então, disse ao sindicato que ou os padrões
tinham de ser atual izados, ou as pessoas perderiatn seus empregos. O sindicato man-
teve sua complacência e se recusou a mexer nos padrões. Quando a gerência ameaçou
terceirizar grande parte do trabalho e demitiu pessoa l, os traba lhadores sindicalizados
entraram em greve.
O pessoal da gerência e os traba lhadores não sindical izados começaram a fazer o
t rabalho que anteriormente era feito pelos trabalhadores sindica lizados. Ele.s produ-
ziram 70'% do trabalho utilizando 10% da quantidade de trabalhadores de antes. O
pessoal do departamento de recursos humanos estava operando furadeiras e fechos,
e os vendedores estavam traba lhando na linha de montagetn. A gerência agora tinha
utn quadro claro do que o pecado da preguiça tinha feito com a empresa todos aqueles
anos. A gerência não tinha nenhuma intenção de negociar um fim para a greve. O sin-
dicato acabou cedendo e voltando ao trabalho. Entretanto, mais de 160 dos trabalha-
dores sindica lizados foratn demitidos depois de os novos padrões terem sido adotados.
A empresa voltara a ser competitiva.
Luxú ria
• "A luxúria está para as outras paixões assitn cotno o fluido nervoso está para a
vida; é a base de todas elas: ambição, crueldade, avareza, vingança, todas se fun-
datnentam na luxúria." (Marquês de $ade)
• "De todas as paixões mundanas, a luxúria é a mais intensa. Todas as out ras pare-
cem seguir seus trilhos." (Buda)
• "A sociedade enlouquece as pessoas com luxúria e cha,na isso de propaganda."
Uohn Lahr)
• "Seu insaciável desejo por poder só se igua la à sua incurável impotência em exer-
cê-lo." (Winston Churchill)
• "O inferno possui três portões: a luxúria, a raiva e a ganância." (Bhagavad Gita)
• "Não é o poder propriamente d ito, mas a legitimação do desejo por poder que
corrompe de maneira absoluta." (Richard Howard Stafford Crossman)
• "A luxúria tem tamanho domínio sobre a humanidade que mais parece que é a
riqueza do homem que o possui, e não o homem que possui sua riqueza." (Plínio,
o Velho)
A luxúria é a etnoção ou sentimento de intenso desejo físico. Embora norma l-
mente seja descrita em utn contexto sexual, ela também pode se manifestar como um
forte desejo por poder, conhecimento ou cont role. Ela pode levar a grande ânsia ou
entusiasmo, especia lmente se atender à necessidade de agradar os sentidos.
A segu ir, veremos dois exemplos de como a luxúria pode afetar os projetos:
Situação 16: Fracasso devido ao desejo por poder. Ralph estava eufórico para ser de-
signado como gerente de projeto em utn novo projeto que tinha sido ganho através
de licitação. A chance de seu cliente querer fazer novos traba lhos com eles era ext re-
mamente a lta . Aquela era a chance para Ra lph se tornar mais poderoso do que os
out ros gerentes de projeto e possivelmente ser protnovido e passar a ter seu próprio
escritório. Ter seu próprio escritório com janelas amplas era sinal de poder e prestígio.
Para que isso acontecesse, Ralph precisava lentamente transformar seu projeto e1n u1n
império de recursos, independente1nente das consequências.
No final do contrato inicia l, Ralph tinha n1ais recursos designados ao projeto em
período integral do que o planejado durante o início do projeto. Havia um excesso de
funcionários sign ificativo, e isso causava un1 efeito adverso sobre os lucros. No entanto,
Ralph explicou aos seus superiores que isso levaria a lucros mais altos no futuro.
Quando o segundo cont rato surgiu, Ralph a rgumentou que precisava de ainda
mais recursos, e que era necessária uma estrutura organizacional baseada em projetos,
com ele na liderança. A empresa concordou. A estrutura baseada em projetos permitiu
que todos os tra balhadores de meio exped iente fossem designados ao projeto de Ralph
em tempo integral. Já no meio do projeto, a empresa foi notificada de que haveria
novos contratos, mas que todos eles seriam fechados na base da licitação. O poder de
Ralph agora atingira seu ápice.
Infel izmente, devido à necessidade de sustentar seu império, a lucratividade do
cont rato de repetição que Ralph estava terminando ia toda para paga r os salários dos
trabalhadores. Mais uma vez, Ralph argu1nentou que lucros significativos estavam por
vir. Durante a licitação pelo novo tra balho co1n a antiga cliente, os superiores de Ralph
aumentaram significativamente o preço da proposta. Infelimente, agora a e1npresa se
torna ra não competitiva. Ralph e pa rte do império que ele tinha const ruído fora 1n
demitidos. O desejo de poder fez co1n que seu poder, que tinha levado dois anos para
se de.sen volver, desa parecesse em um dia.
Situação 17: Fracasso devido ao desejo de poder - r evis itado. Este projeto seria a
pri1neira chance que Kathy teria de trabalhar como patrocinadora de projeto. Kat hy
acreditava que seu desejo de poder floresceria se ela m icrogerenciasse a equipe de pro-
jeto e exigisse tomar toda e qua lquer decisão. A gerência sênior certamente perceberia
isso. Pelo menos é o que ela pensava...
Kat hy tinha razão quanto à gerência sênior ter visto que ela estava tomando todas
as decisões. Infel izmente, os especialistas designados ao projeto, além do gerente de
projeto, sabiam que Kathy tinha um conhecimento muito lim itado em relação a algu-
mas das decisões técnicas que precisavam ser to 1nadas no projeto. Eles também esta-
vam insatisfeitos co1n o fato de estarem sendo 1n icrogerenciados. Muitas das decisões
de Kathy estavam erradas, e a equ ipe sabia d isso, mas deram prosseguimento às ideias
ruins mesmo assi1n, se1n questioná-las . A gerência também viu as más decisões que
Kathy tinha tomado e acabou afastando-a da posição de patrocinadora de projeto.
Gula
• "Glutão: alguéin que e.ava seu túmulo com os próprios dentes." (Provérbio francês)
• "A gula é a fonte de todas as nossas e1úermidades e a fonte de todas as nossas
doenças. Assim como u1na la 1nparina se apaga por excesso de óleo e o fogo é ex-
tinto por excesso de co1nbustível, a saúde natural do corpo é destruída por u1na
dieta sem moderação." (Robert Burton)
• "O avarento e o glutão representam duas facetas de um abut re; um esconde suas
posses e o outro as conso1ne escond ido." Uosh Billings)
• "A gula é u1na fuga en1ocional, sinal de que algo está nos comendo." (Peter De Vries)
• "A gula mata mais do que a espada." (George Herbert)
A gula gera lmente é definida no contexto de comida, co1n termos como "deglutir"
ou "devorar". Vemos a glutonaria como um consumo excessivo de comida. Em u1n
ambiente empresarial, a glutonaria é o desejo de consu1n ir ma is do que o necessário. é
extravagância ou desperdício.
O exemplo a seguir mostra co1no a glutonaria pode levar tanto ao sucesso quanto
ao fracasso.
Situação 18: Sucesso devido à gula por recursos. Jerry era um dos diretores de produ-
ção que se reportava ao vice-presidente de produção. Quando a tecnologia começou a
mudar, o pessoal da produção recon heceu a necessidade de criar vários novos depar-
tamentos para tirar proveito de novas tecnologias. Jerry era sedendo por recursos. Ele
convenceu o vice-presidente de produção de que esses novos departa1nentos deveriam
ficar sob seu controle. Pelos dois anos seguintes, todos os novos departa1nentos es-
tavam sob a supervisão de Jerry, que agora controlava mais de 75'% dos recursos da
Divisão de Produção.
Quando o vice-presidente de produção se aposentou, Jerry foi promovido a vice-
presidente. A primeira providência de Jerry foi desfazer o i1npério que ele tinha criado
para que ninguém jamais pudesse se tornar tão poderoso quanto ele se tornara. Aos
o lhos de Jerry, ele agora tinha controle sobre todos os recursos, independentemente de
se eles se encont ravam na Divisão de Produção.
Aqui, p intan1os um quadro deso lado r de como os Sete Pecados Capita is poden1
ter um impacto negativo sobre os projetos. Do ponto de vista dos projetos, alguns
dos pecados estão intiman1ente relacionados e não podem ser facilmente separados
e d iscutidos como os psicólogos e filósofos nos fazem crer. Isso pode ser percebido
nas situações que apresentamos anterio rn1ente, por exemplo, quando o desejo de
contro le de amplos recursos pode ser considerado uma forma de luxú ria, gula ou
avareza.
É verdade que, em algumas situações, os pecados podem produzir resultados posi-
tivos. Eles podem nos forçar a nos tornarmos mais determinados, correr riscos, aceitar
novos desafios e agregar valor para a e1npresa . Nossa fascinação com o orgulho e a
luxúria pode nos ajudar a virar a mesa de um projeto problemático e t ransfonná-lo
em um sucesso, de modo que tenhamos o reconhecimento de toda a corporação. A
ganância de querer um grande bônus pode, da mesma fonna, nos encorajar a tornar
nosso projeto bem-sucedido. O r isco dos vícios é que eles muito provavelmente po-
dem ter um efeito negativo em nossa capacidade de nos estabelecermos com base em
nossas habilidades interpressoais e nossos relacionamentos com as equipes de projeto
e departamentos funcionais.
Então, devemos treinar os gerentes de projeto e os 1nembros de equipe e1n como
identificar e controlar os pecados? Talvez não, contanto que estejam surgindo resulta-
dos benéficos. Mais uma vez, todos sucumbimos a alguns ou todos esses pecados, mas
e1n diferentes graus.
A Igreja Católica Romana reconhece sete virtudes, que correspondem inversamen-
te a cada um dos Sete Pecados Capitais. Elas são apresentadas na Tabela 2- 2.
TABELA 2-2 Vícios e virtudes

Vício Virtude
Inveja Bondade
Ira Paciência
Orgulho Humildade
Ganância Caridade
Preguiça Diligência
Luxúria Simplicidade
Gula Moderação
Do ponto de vista da gestão de projetos, talvez a melhor solução seria ensinar as

virtudes nos cursos de treinamento em gestão de projetos. É possível que, em futuras
edições do Guia PMBOK®, o capítu lo sobre gestão de recursos humanos possa até
discutir vícios e virtudes. Só o tempo dirá.
2.14 Fontes de dores de cabeça menores

Nem todas as dores de cabeça da gestão de projetos levam a enxaquecas. A lista a
seguir identifica a lgumas das dores de cabeça menores que já ocorreram em várias
empresas, mas que não necessariamente levara1n a enormes enxaquecas:
• Manter as restrições originais: Quando a equipe de projeto começou a trabalhar
no projeto, o trabalho começou a se expandir. Algumas pessoas acreditavam que
dentro de todo projeto havia u1n projeto ma ior à espera de ser reconhecido. Ter
mais de um patr ocinador de projeto, cada um com suas próprias intenções, criava
esse problema.
• Revisões da declaração de tnissão original: Nas reuniões de revisão de fase, o
projeto era redirecionado quando a gerência redefinia sua declaração de 1nissão
original. Embora esses tipos de mudanças fossem inevitáveis, a magnitude dos re-
direciona1nentos tinha um efeito devastador sobre o sistema de EPM, os esforços
de gerenciamento de portfólio e o planejamento de capacidade.
• Falta de métricas: Uma organização de TI mantinha um quadro de ma is de 500
funcionários. Em dado momento, a gerência sên ior não conseguia determinar se
o número de funcionários do grupo de TI era alto dema is, ba ixo dema is ou na
medida certa. A priorização de recursos estava sendo malfeita, e o gerencia1nento
de recursos se tornou reativo e vez de proativo.
• Mais métricas: Em um outro exemplo, a equipe de gerenciamento de TI, para aju-
dar a identificar se os projetos estavam ou não sendo entregues dentro do prazo,
tinha implementado recentemente indicadores balanceados de desempenho para
os projetos. Depois dos seis primeiros meses de levantamento de dados, a conclu-
são foi que 85% de todos os projetos era1n ent regues no prazo. Do ponto de vista
da gerência executiva, esse va lor parecia ser enganoso, mas não havia nenhuma
forma precisa de determinar se ele era preciso ou não. Por exemplo, um executi-
vo sabia pessoalmente que nenhu1n de seus cinco maiores projetos e todos os 1 O
projetos de um gerente de TI estavam atrasados. A gerência executiva acreditava
que o verdadeiro desafio seria determinar mét ricas apropriadas para med ir dados
relativos ao prazo, qua lidade e orçamento.
• Gerenciatnento de portfólio de projetos: Ao revisar portfól ios de projetos ou pro-
jetos individua is, todos os planos estavam en1 diferentes níveis de detalhe e preci-
são. Por exemplo, alguns planos incluían1 apenas n1arcos com datas importantes,
enquanto outros possuíam un1 excesso de detalhes. O problema principal era "qual
é o equilíbrio correto de inforn1ação que deve ser incluído em um plano e como
todos os planos podem fornecer u1n nível de "precisão" consistente e1n todos os
projetos?". Nem 1nes1no o tenno "precisão" era consistente en1 toda a organização.
• Priorização de projetos e recursos: Em uma empresa, não havia qualquer mecanisn10
em funcionamento para priorizar projetos, e isso complicava a alocaç.ão de recursos
na organização. Por exemplo, o CIO tinha seus cinco maiores projetos, un1 executivo
tinha seus 10 1naiores projetos e u1n gerente de TI tinha seus 10 n1aiores projetos.
Alé1n de ter de comparti lhar gerentes de projeto e recursos con1 todos esses proje-
tos, não havia qualquer n1aneira objetiva de determ inar se o projeto n• 3 do CIO
era mais/menos in1portante do que o projeto n" 6 do executivo ou do que o projeto

n" 1 do gerente de TI. Portanto, quando surgiam interesses concorrentes, ton1avam-se
decisões su bjetivas, e era u1n desafio determinar se a decisão ton1ada tinha ou não
sido a correta.
• Responsabilidade compartilhada pelo sucesso 011 fracasso : Os projetos da organi-
zação tradicionalmente eram caracterizados como projetos de um único recurso,
processo e platafonna. Hoje, quase todo p rojeto possui mais de uma equipe, mais
de uma p lataforma e mais de um processo. Esse novo modelo não somente au-
mentou a complexidade e risco de muitos projetos, mas também passou a exigir
maior responsabilidade da equipe do projeto por seu sucesso ou fracasso. Infeliz-
mente, a cultura e o pessoal da organização ainda defendiam o modelo antigo. Por
exemplo, se uma equipe fosse bem-suced ida em sua parte de u1n projeto e outra
equipe não era, a atitude seria : "Estou feliz por não ter sido eu quem fez o projeto
fracassar" e "Apesar de o projeto ter fracassado, eu fui be1n -sucedido porque fiz
a minha parte". Embora isso tivesse a lgu1n mérito, em geral, a cultura precisava
mudar para sustentar um ambiente em que "Se o projeto é be1n -sucedido, todos
somos" e vice-versa.
• Medir os resultados de utn projeto: Muitos dos projetos que era1n concluídos
eram aprovados com base e1n melhorias de processo e aumento da eficiência. En-
tretanto, depois de um projeto de 1nelhoria de processo ser concluído, não havia
programas disponíveis para determinar se as melhorias tinham ou não sido alcan-
çadas. Na verdade, como a empresa estava passando por um crescimento anua l na
casa dos dois dígitos, a equipe executiva questionava se as melhorias de processo
aprovadas eram reahnente extensíveis no longo prazo.
• Integrar diversas metodologias: As equipes de desenvolvi1nento de aplicativos ti-
nha1n adotado a Metodologia de Desenvo lvin1ento de Software (SOM, Software
Develop1nent lvfethodology) e a Metodo logia Agile pa ra Desenvolv imento de
Software. Ambas possuíam excelentes a bordagens para entregar con1ponentes de
software que atendian1 os objetivos de qua lidade, orçamento e prazo. O desafio
que a organização enfrentava era saber se os componentes de ambas as metodo-
logias poderian1 ou não ser adaptados a projetos que não estivesse1n relacionados
ao desenvolvimento de software e, caso pudessen1, co1no isso poderia ser realizado.
Esse debate tinha chegado à alta gerência para ser resolvido, e ela estava relutante
en1 tomar qualquer decisão. Essa diferença de visão sobre co1no os projetos de-
vem ser gerenciados, independenten1ente de ser relacionado ao desenvo lvin1ento
de software ou não, tinha levado diversos grupos a fazer lohby para juntar seus
esforços e oferecer suporte ao SOM e Agile para todos os projetos. De n1odo geral,
os esforços de lobby não estava1n agregando va lor à organização e foram um des-
perdício de esforço feito por recursos cruciais.
• Cotnunicações organizacionais: Embora haja muita comunicação sobre projetos
por toda a organizaç.ã o, há muitas limitações no processo existente. Por exemplo,
um executivo afirmou que quando fazia sua reunião mensal de status do proje-
to com seus superiores diretos, ele ficava chocado quando um gerente não tinha
ciência do projeto de outro gerente, especia lmente se o p rojeto estivesse ficando
pronto para migrar para a produção. O processo existente levava muitos gerentes
a reagir a projetos em vez de planejá-los proativamente. Além disso, o processo
de co1nun icação existente não faci litava ocompartilhamento de conhecimentos e
a coordenação entre diversos projetos ou em toda a organização. Em vez disso,
faci litava silos individuais de comunicação.
• O significado das palavras: Um projeto foi iniciado no nível dos funcioná rios.
A declaração de tra ba lho (SOW) contin ha inúmeras frases com uma linguagem
vaga, como: "Desenvolver uma p lataforma de controle de primeira classe cotn

uma ergonomia excepciona l e apelo visual". O gerente do projeto e sua equipe
interpretaram essa SO\V usando sua própria criatividade. A ma ioria dos metnbros
da equipe era de engenheiros, sem nenhum 1nembro do marketing, e a solução
acabou sendo tecnicamente forte, mas um desast re de vendas/marketing. Perde-
ram-se meses cotn a colocação do produto no mercado.
• Problema com o sucesso: Um projeto foi aprovado com um termo de abertura que
definia os seus limites etn termos gerais. No início do projeto, houve alguns suces-
sos, e a notícia se espa lhou rapidamente pela organ ização. A medida que o projeto
prosseguia, certos gerentes de depa rtamento começava tn a "adicionar" questões
ao escopo do projeto, usando sua própria interpretação da SO\V, na esperança de
fazer progresso em suas próprias intenções cotn esse ta lentoso grupo. O projeto
acabou sendo suspenso, e a equipe ficou destnoral izada. A gerência sênior des-
membrou o grupo. Depois disso, a gerência teve muita d ificuldade em fazer as
pessoas participarem de equipes de projeto.
• Desafio à autoridade: Un1a nova equipe de projeto n1ultifunciona l foi montada
envolvendo especialistas técnicos de inútneros departan1entos. O gerente do proje-
to era um consultor de uma empresa contratada externa. Durante o decorrerdes-
se grande projeto, co1neçara1n a surgi r confl itos de recursos com os cronogra tnas
da produção. Inevitavelmente, os gerentes de área começaram a desviar recursos
do projeto. O consultor in1ediatan1ente inforn1ou atrasos pendentes devido a essa
ação, e os funcionários reiteraran1 as preocupações do consultor e a necessidade de
a organ ização apoiar o projeto. As lutas continuaram, criando situações estressan-
tes para os 1ne1nbros de equipe que tentavam equilibrar suas cargas de trabalho.
O projeto terminou atrasado cotn custos excedentes significativos e causou indi-
retan1ente un1a grande quantidade de animosidade entre 1nuitos dos participantes.
• Deliverables inacabados: Um projeto foi lançado para redesenha r e implementar
um sistema de gestão de mudanças em engenharia . A equipe recebeu um forte
apoio etn toda a sua duração. E,n uma reunião de finalização do projeto com a
equipe executiva, o gerente de projeto apresentou a interpretação dos deliverables
feita por sua equ ipe. Para sua surpresa, os executivos determinaram que os deli-
verables não estava tn completos. No final, essa equipe específica traba lhou etn
um "abacaxi" que se estendeu por três anos a mais que sua SOW original (a apre-
sentação de fechamento origina l ocorreu depois de nove meses). A equipe estava
frustrada tra balhando em um projeto que parecia nunca ter fim, e os executivos
estavam ficando cada vez ma is impacientes com uma equipe que eles sentiam estar
"enrolando" o trabalho. O processo de gestão de projetos da empresa sofreu du-
ras críticas, ameaçando esforços futuros e o apoio executivo.
• Cttstos excedentes: Logo depois de um grande projeto de renovação de produto
ter sido encomendado, o gerente de projeto divu lgou que o custo de conclusão
tinha sido subavaliado. Infelizmente, o departamento de marketing, esperando
que o prazo fosse cumprido, já tinha ent rado no mercado com u1na promoção
"relâmpago", e as expectativas do cl iente eram altas etn relação ao lançamento
do produto. A equ ipe administrativa estava diante da decisão de gerar custos ex-
cedentes para concluir o projeto dentro do prazo ou perder o moral e vendas no
mercado ao postergar a conclusão do projeto.
Apesar de todas essas dores de cabeça, a gestão de projetos funciona, e funciona
bem. Mas ela está deixando a desejar? Algumas pessoas discutem que "si tn", porque
ele não é um amuleto mágico que pode produzir deliverables sob toda e qualquer cir-
cunstância. Out ros discutem que ele funciona bem e não há nada errado, exceto o fato
de as expectativas dos executivos estarem superinfladas. A gestão de projetos pode

ser u1n sucesso ou um fracasso, mas a intenção, o compromisso e a compreensão nos
níveis executivos têm de estar presentes.
4
2.15 Os dez perigos dos projetos
Introdução
As metodologias, aulas e livros de gestão de projetos são adequados para explica r os
mecanismos de ad1n inistr ação de projetos e as ferra 1nentas usadas para tal. É essencial
compreender esses 1necanismos, mas é a experiência que distingue os gerentes bem-su-
cedidos dos outros. Mais especificamente, é a soma de todas as experiências negativas
que os gerentes de projeto enfrentam em suas carreiras que lhes ensina o que não deve
ser feito. Como Vernon La,v explica,"A experiência é um professor rígido, pois dá o
teste primei ro e a aula depois".
Em meus muitos anos de experiência em gestão de projetos, já encontrei diversas
áreas que consistentemente fazem os projetos passarem por dificuldades. Chamo-as de
"perigos" dos projetos, já que são essas coisas que fazem os projetos se tornarem pro-
blemáticos. Norma lmente se t ratam de coisas que, u1na vez reconhecidas, são difíceis
de consertar de maneira simples.
Esta seção discutirá os 1 O perigos dos projetos e proporá algu1nas formas de reme-
d iá-los. Certamente há outros perigos por aí, mas estes são os mais comuns e que têm
o maior impacto de acordo com minha experiência.
Os dez perigos
A seguir, veremos os 1 O perigos com uma descrição de cada u1n e alguns sinto 1nas que
indicam que eles podem estar à espreita .
1. Falta de manutenção de documentação: Geralmente, quando os projetos es-
tão pressionados pelo tempo, a primeira coisa que é eliminada é a documentação. Às
vezes, a documentação não é feita mesmo quando os projetos têm tempo. Quando a
documentação é criada apropriadamente, à medida que os projetos continuam a pro-
gredir, é uma raridade vê-la ser mantida.
Sintomas
• Documentos exigidos que não correspondem ao que foi produzido
• Documentos técnicos que não podetn ser usados para 1nanter a tecnologia, por
estarem desatualizados
• Ausência de documentação sobre que decisões foram tomadas e por que elas
foram tomadas
• Ausência de tri lhas de auditoria das mudanças rea lizadas
Isso é um problema pelo fato de a documentação fornecer a possibi lidade de
um gerenciamento ético e responsável do projeto. Com isso, quero dizer que os
projetos futuros e as pessoas que forem responsáveis pela 1nanutenção do proje-
to após sua conclusão precisam da documentação para compreender o q11e foi
criado, por q11e foi criado e como fo i criado. Caso cont rário, eles acabam ca indo
' Esta seção foi escrita por Kerry R. \Vills, PM.r1', diretor de gerenciamento de portfólios, Divisão de Soluções
de lnfraesrrurura. The Hanford. ©2005 por Kerry R. \Vills. Reproduzido com permissão de Kerry R. Wills.
nas mes1nas armadilhas que aconteceram antes - nesse caso, "aquele que ignora a
história documentada está fadado a repeti-la".
2. O fenômeno do acúmulo : "O que é isto debaixo do tapete?" é un1a pergunta que
se faz frequenten1ente perto do fim de um projeto. O trabalho principal sempre recebe
o foco prin1ário de u1n projeto, mas são aquelas coisas que fica1n pela tangente que são
esquecidas ou "deixadas para depo is" até chegarem ao ponto de se tornare1n várias
pilhas de coisas (que são varridas para debaixo do tapete) que precisan1 ser resolvidas.
Chamo isso do "fenôn1eno do acú1nulo" porque os n1embros de equipe o veen1 como
u1n fenô1neno de todo aquele trabalho "ext ra" que de repente aparece no final.
Sintomas
• Qua lquer trabalho que seja identificado como "faremos isso depois", mas que
não apareça em nenhu1n plano
• Registros crescentes (problemas, defeitos, etc. )
• Suposiç.ã o de que a docu1nentação será feita no final
Não há espaço para nenhum "depois" na maioria dos p lanos de projeto, e,
portanto, esses itens ou são deixados de lado ou há uma corrida enlouquecida no
final para terminar o trabalho.
3 . Falta de qualidade na fonte: Os 1nembros da equipe de projeto nem sempre
adotam o mantra "qualidade na fonte". Às vezes há uma mentalidade de que "algu1na
out ra pessoa encontrará os erros" em vez de uma mental idade de garantia da qualida-
de. Os gerentes de projeto nem sempre têm a possibilidade de revisar todo o trabalho,
então, dependem dos membros de sua equipe. Portanto, os membros da equipe pre-
cisa1n ter o ônus de garantir que qua lquer coisa que leve o no1ne deles represente seu
melhor traba lho.
Sintomas
• Entregar t raba lhos co1n erros antes de revisá-los
• Desenvolver código sem testá-lo
• Não se importar com a apresentação do t rabalho
Há vários estudos que most ram que problemas relacionados à falta de qua li-
dade na fonte têm um custo exponencial quando descobertos em fases posteriores
do projeto.
4. Pessoas erradas envolvidas: As funções dos membros de uma equipe de projeto
exige1n uma boa correspondência entre habi lidades e responsabilidades. Às vezes, o
conjunto de habi lidades de uma pessoa não se encaixa bem na função lhe foi designa-
da. A ética profissional é tão i1nportante quanto habil idades.
Sintomas
• Mostrar as mes1nas coisas repetidas vezes aos 1nembros da equ ipe
• Deixar consistentemente de cumprir prazos
• Produzir consistentemente uma má qua lidade
Como gerentes de projeto, todos temos nossos recursos. Não encont rar u1n
bom ajuste para os me1nbros da equipe resultará e1n ter de trabalhar ma is pesado
do que o necessário e afetará todos os outros membros da equipe que tivere1n
de recuperar o tempo perdido. Há também uma questão motivacional e1n jogo:
Quando os membros de equ ipe estão dese1npenhando as funções erradas, eles
podem não se sentir desafiados ou podem sentir que não estão t rabalhando de
acordo com seu potencial. Isso faz com que essas pessoas não se esforcem ao
máxÍlno, não manifestando a mesma ética profissional sólida que normalmente

manifestariam, sentindo-se subaproveitados, e assim por diante.
5. Não envolver as pessoas certas: As pessoas que sabem como fazer o projeto ser
bem-suced ido são os 1nembros de equ ipe que estão traba lhando nele. Não envolver
os membros de equipe certos no momento certo pode colocar o projeto em risco de
fracassar antes mesmo de começar.
Sintomas
• Necessidade de fazer mudanças em t raba lhos já concluídos
• Constantes mudanças de escopo por parte do cliente
• Falta de co1nprometimento da equipe com as estÍlnativas
• Falta de assumir responsabi lidade por decisões
Não envolver as pessoas certas desde o início de um projeto sempre resulta
em mudanças no t rabalho. Não envolver os me1nbros da equipe e1n decisões e
estimativas faz eles sentirem que não possuem controle sobre o seu trabalho ou os
resultados do projeto.
6. Não ter o patrocínio apropriado: Os projetos precisam de patrocín io dos execu-
tivos internos e do cliente para serem be1n -sucedidos. Os pat rocinadores atuam co1no
agentes de "desempate" e elimina1n a politicagem organizacional/obstáculos que este-
jam entravando o projeto.
Sintomas
• Suporte inapropriado de d iferentes áreas da organização e das partes interessa-
das do lado do cliente
• Problemas levam muito tempo para serem resolvidos
• Decisões não são tomadas eficientemente
Não ter o patrocínio apropriado pode fazer com que os projetos fiquem "em-
pacados". Além disso, quando um esforço de mudanças é envolvido, não ter o
pat rocínio apropriado pode fazer co1n que os funcionários afetados não consigam
apoiar um projeto (i.e., não repassar as mensagens do alto da organização para
as "massas,,).
7. Falta de rigor nos pr ocessos: Quase toda empresa usa uma metodologia para
implementar projetos. O sucesso dela depende da quantidade de rigor usado. Mu itas
vezes, não se adere aos processos, e os projetos fracassam.
Sintomas
• Deliverables incompletos/inexistentes
• Inconsistências dentro do projeto
• Falta de co1npreensão do quadro geral do projeto
• Falta de processos repetíveis ("reinventar a roda" desnecessariamente)
Os processos são tão val iosos quanto a rigidez a eles aplicada. Em a lgumas
empresas, usa -se um número excessivo de metodologias de gestão de projetos.
Algu1nas são necessárias devido à variedade da natureza do trabalho, 1nas as prá-
ticas e princípios fundamenta is da gestão de projetos (e até mesmo ferramentas,
i.e., usar Project versus Excel) poderiam facilmente ser padronizadas, mas não o
são. Quando um gerente tem de t ransferir um projeto para out ro gerente, cria-se
uma camada ext ra de complexidade, pois as duas pessoas não estão usando uma
linguagem co1nu1n entre si (é co1no tentar interpretar o cód igo de uma outra pes-
soa quando elas não seguiram os padrões que você tem usado).
8. Ausência de plano comunitário: Os gerentes de projeto passan1 un1a quantidade

sign ificativa de tempo planejando, estimando e determinando um cronograma para as
atividades. Se esses resultados não fore1n compartilhados com os n1embros da equipe, eles
não saberão o objetivo de seu trabalho e não conseguirão gerenciar seus próprios crono-
gran1as. Isso inclu i a co1nunicação de metas e itens que são importantes para a equipe.
Sintomas
• Falta de conhecimento sobre o que precisa ser feito e para quando
• Desrespeito às datas
• Falta de responsabilidade pelos deliverables
• Deliverables são esquecidos
Não ter um p lano comunitário resulta em não ter uma comunidade informada.
Ter um plano e metas compartilhadas ajuda a const ruir uma coesão e ma ior com-
preensão sobre como o trabalho de cada indivíduo se encaixa no todo.
9. Não planejar retrabalho: As técnicas de estimação geralmente se focalizam no
tempo que leva para criar unidades de traba lho. O que normalmente é deixado de fora
é o tempo gasto em retrabalho. Isso significa traba lho que foi feito incorretamente e
precisa ser corrigido, em oposição ao gerenciamento de escopo. Quando o ret rabalho
é necessário, ou ele ocorre no tempo destinado a out ro t raba lho, que agora fica atrasa-
do, ou é deixado para depois (ver "perigo" 2).
Sintomas
• Desrespeito às datas
• Má qualidade
Nunca suponha que a lgo será feito correta1nente logo da primeira vez.
1O. Datas não passam de números: O cronogra1na é o 1naior determinante do su-
cesso de um projeto. Fico surpreso com o número de pessoas que pensa em datas como
"sugestões" e não co1no prazos. Devido a interdependências entre projetos, uma data
desrespeitada no início pode ter um efeito em cadeia pelo restante do projeto.
Sintomas
• Desrespeito constante às datas
• Itens deixados em aberto por longos períodos de tempo
• Deliverables incompletos/inexistentes
• Falta de um senso de urgência por parte da equipe de projeto
Se1n estrutura no que tange ao gerenciamento de datas, o sucesso exige muito
ma is esforço. Uma out ra questão em jogo aqui é a da comunicação - essas datas
precisam ser comunicadas claramente, e as pessoas precisam concordar que esse é
seu objetivo. Além disso, elas têm de co1npreender o que está no caminho crítico e
o que possu i uma folga em termos de tempo; então, se perdem te1npo e1n u1n ite1n
que está no caminho crítico, sabe1n que haverá um impacto sobre o projeto ou
sobre algum outro projeto dentro do mesmo programa.
Possíveis remédios
Ao analisar os "perigos" , observei que eles estão todos inter-relacionados. Por exen1plo,
não ter rigor nos processos (n" 7) pode resultar e1n não ter u1n p lano con1partilhado
(n" 8), o que pode fazer com que as pessoas não se importem com datas (n" 10), e assiin
por diante. (Ver Figura 2-4.) Percebi també1n que havia algu1nas fonnas de ren1ediar
Falta de manutenção Ausência de plano para retrabalho

de documentação Envolvimento das pessoas
erradas no projeto
Falta de rigor nos processos

Má qualidade
ão envolvimento das pessoas ce
Ausência de um
plano comunitário 1--...::::::s.lõoiiteieni'iõínmiie:;;nõoiido~ac~úÍnmnuiii1oil
ILOatas-1=:;_::,=-~
não importam
Falta do patrocínio apropriado
Figura 2-4 1nter-relações observadas.
esses perigos. A dica aqui é resolvê-los proativamente etn vez de reagir a eles, pois, na
hora en1 que você percebe que há um perigo, seu projeto já apresenta problemas.
Gerenciamento proativo Gerenciamento proativo significa gastar a quantidade
de tempo apropriada logo no início para mini1n izar o nú1nero de "incêndios" que de-
verão ser apagados depois. O gerenciamento proativo inclui as seguintes ações:
• Criar um plano detalhado.
• Sempre observar o plano para ver o que e.stá por vir e se preparar para tal:
• Pensar sobre o t raba lho que está por vir e analisar todos os proble1nas que po-
dem vir a surgir. Imagino a equipe como um corredor de maratona e é minha
tarefa "esvaziar a rua" diante deles para que eles possam continuar correndo.
• Estabelecer uma logística. Algo tão trivial quanto não reservar uma sala de reu-
nião com antecedência pode acarretar u1n atraso no cronograma.
• Recrutar as pessoas apropriadas para que elas esteja1n prontas quando o traba-
lho chegar.
• Conhecer a programação de férias do pessoal.
• Constante replanejamento à medida que informações se disponibilizam.
• Compreender o que está acontecendo com o projeto. Vejo tantos gerentes de pro-
jeto traba lhando no modo " torre de 1narfim" quando descobrem coisas sobre os
SEUS projetos pela primeira vez em um relatório de status. A essa a ltura, já se
passou uma semana sem que o gerente do projeto estivesse ciente dos problemas.
Sempre surgirão proble1nas inesperados, mas o gerenciamento proativo pode aju-
dar a mitigar aqueles que são cont roláveis. Isso pode ser t ratado como um investi-
mento de tempo, no sentido de que você gastará mais tempo (e d inheiro) reagindo a
problemas do que se focal izando em garantir que o processo seja seguido apropria-
da1nente. Isso é d ifícil para alguns gerentes de projeto, porque exige a capacidade de
sempre olhar adiante e1n relação ao e.stado corrente do projeto em vez de se foca lizar
apenas no problema do d ia. Um elemento-chave do gerenciamento proativo é ter a
capacidade de tomar decisões eficiente1nente.
" Faça as coisas no decorrer do trabalho" Agora que você não está reagindo a "in-
cêndios", pode fazer os membros de equipe se concentrarem e1n 1nanter seu trabalho
continuamente. Isso significa 1nanter-se focado em todos os aspectos do traba lho cor-
rente e pensar em suas implicações. As características desse modo de trabalho incluem:
• Documentar o trabalho enquanto está sendo realizado, e não no final. Tenho cer-
teza de que isso suscitará a reação instintiva de "não reinos tempo para isso", 1nas
rea lmente acredito (e já provei) que docu1nentar ao longo do processo consome
muito menos tempo do que fazê-lo no final.
• Pensar nas implicações quando houver mudanças no projeto. Por exemplo, se um
docu1nento mudar, o proprietário desse documento deve pensar e1n qua isquer ou-
tros deliverables que podem ser afetados pela mudança e comunicá-la à pessoa
apropriada.
• Verificar todo o seu trabalho antes de repassá-lo aos outros.
• Usar o processo/plano como diretriz para que trabalho tem que ser feito. Já vi isso
ser cha1nado de "colocar o plano em prática".
O resultado dessa técnica será uma distribu ição mais uniforme de tr abalho ao
longo da duração do projeto e m inimização de picos no final. Em vez de a notória
"marcha da morte", o pior caso seria considerado uma "desconfortável maratona".
Empoderar a equipe Os gerentes de projeto têm de perceber que as estruturas do
projeto lembram uma pirâ1nide invertida na qua l o gerente de projeto trabalha PARA
a equipe. São os 1nembros da equipe que realiza1n o trabalho do projeto, então a fun-
ção primordial do gerente de projeto é apoiá-los e cuidar dos obstáculos que possa1n
impedi-los de concluir seu trabalho. Isso inclui:
• Envolver membros de equipe no planejamento de projeto, de modo que eles não
possam dizer que a única coisa que a gerência fez foi lhes dar u1n prazo final.
• Perguntar aos membros de equipe como as coisas estão caminhando, e então
tomar providências em relação às suas preocupações. Pedir feedback e não fazer
nada a respeito é pior do que nem perguntar nada, pois sugere uma expectativa
de que as preocupações serão abordadas.
• Celebrar os sucessos da equipe com os me1nbros de equipe.
• Ser honesto com os membros de equipe.
Sou um grande fã de W. Ed,vards Deming, que revolucionou a indústria manu-
fatureira. Seus 14 princípios de gerenciamento giram em tomo do e1npoderamento
da equipe e se aplicam muito bem a projetos. Alguns princípios selecionados estão
TABELA 2-3 Princípios de gerenciamento de Deming

Princípio de Deming Observação
8. Elimine o medo, de modo que todos possam tra- Isso significa que a técnica de gestão de projetos com
balhar eficientemente para a empresa "punho de ferro• não é uma ideia muito boa. As pessoas
serão avessas a dar sua opinião e a fazer um trabalho
de boa qualidade
10. Elimine lemas, recomendações e metas para a Segundo a minha interpretação, isso significa que os
força de trabalho que exijam defeito zero e novos gerentes de projeto não devem somente lançar metas,
níveis de produtividade. Tais recomendações só mas, em vez disso, envolVer os membros de equipe nas
servem para criar relações adversas, já que a decisões. Significa também que os gerentes de projeto,
maior parte das causas de baixa qualidade e bai- e não os membros de equipe, é que devem analisar o
xa produtividade pertencem ao sistema e, sendo processo no sentido de evitar fracassos
assim, estão fora do domínio da força de trabalho
12. Remova barreiras que separem o trabalhador Essa é a metáfora da maratona - na qual os gerentes
horista e seu direito ao orgulho de seu trabalho de projeto precisam remover obstáculos e deixar que os
membros de equipe façam seu trabalho
13. Institua um vigoroso programa de aprendizagem Permitir que os membros de equipe constantemente
e autoaperfeiçoamento desenvolvam seus oonjuntos de habilidades
TABELA 2-4 Características de um estado atraente
Perigo Nomedo Fazer as coisas no decorrer
n.• perigo Características do estado de perigo Gerenciamento proativo do trabalho Empoderamento
1 Falta de • Desconhecer totalmente que decisões foram • Documentação atualizada • Feito durante o projeto Membros de equipe assumem
manuten- tomadas • Documentação planejada • Sem trabalho extra no final do projeto responsabilidade pela doeu-
çãode • Desconhecer o motivo das decisões tomadas • Qualquer um pode compreender as mentação
documen· • Não poder contar oom a precisão dos doeu· decisões
lação mantos
• Não poder usar em projetos futuros
2 Acúmulo D eixar para depois - talvez nunca seja fe ~o • Trabalho gerenciável Trabalhado ao longo do projeto, então os acú· Minimizado, poique as pessoas
de trabalho • Se houver acúmulos, eles entrarão mulos nunca devem sair de controle assumem responsabilidade pelo
no plano trabalho
3 Qualidade • Falta de responsabilidade pelo trabalho Melhor qualidade, pois você dedicou Focalizar na qualidade enquanto as pessoas A qualidade será mantida, pois
na fonte • Má qualidade uma quantidade de tempo apropriada desenvolvem seu trabalho, em vei de se supor as pessoas assumem responsa-
• Alto custo para consertar erros no início que isso será feito posteriormente bilidade pelo trabalho
4 Adequa- Má adequação do pessoal às funções desig· Capacidade de reconhecer problemas Gerenciar o trabalho de modo que problemas Outros membros de equipe
çãodo nadas de recursos e resolvê-los antes que de recursos sejam identnicados o mais cedo podem assumir o trabalho de
pessoal eles afetem seriamente o projeto possível colegas com problemas
Adequação de recursos desde o início
5 Envolví· Mudanças depois de o trabalho estar concluído Envolver as pessoas certas desde o Envolver as pessoas durante o trabalho em Membros de equipe empodera-
mentodo Falta de responsabilidade pelo trabalho início para evitar retrabalho posterior- vez de esperar que elas reajam posterior- dos assumem responsabilidade
pessoal Falta de responsabilidade por resultados mente mente pelo trabalho
6 Patrocínio Não conseguir resolver problemas Envolver as partes interessadas desde Decisões rápidas e eficientes no momento Pode melhorar devido a uma
Ser envolvído na pollticagem organizadonal o início lhe permitirá contar com seu necessário maior compreensão dos pro-
apoio quando for realmente necessário biamas
7 Rigor dos • Falta de rigor • Rigor apropriado é a essência do • Rigor ocorre quando os membros de equipe Assumir responsabilidade pelo
processos • Má qualidade gerenciamento proativo seguem o processo trabalho permite maior rigor em
• Trabalho inconsistente • Processos repetíveis • Garante que nenhum passo do processo torno de processos
• Olhar adiante garante que a atenção seja "pulado"
apropriada seja dada ao processo
8 Plano CO• Não ter ideia do que predsa ser entregue ou Ter a capacidade de compartilhar um Todos estão trabalhando segundo o mesmo • Todos estão informados - me·
munitário membros de equipe não se responsabilizarem plano e metas com a equipe plano e sabem para onde estão caminhando tas compartilhadas
pelo trabalho - o plano é de responsabilidade do • As pessoas podem gerendar
gerente de projeto seu próprio trabalho
9 Retrabalho Falta de planejamento para alternar entre fazer Prever áreas em que pode haver re- • O retrabalho será considerado à medida que Deve ser minimiiado devido à
outros trabalhos ou consertar problemas trabalho ou mudanças de escopo e os membros de equipe trabalham motivação e à responsabilidade
trabalhar com as partes interessadas • Mantendo o projeto sob controle, você estará assumida pelo trabalho
essenciais desde o início para abordar ciente da magn~ude de retrabalho neces•
o que foi planejado sário e pode replanejar como for preciso
10 Datas • Datas não importam Datas (e as consequências de não res· Da tas são importantes, e ~ens são fechados Membros de equipe assumem
• Nenhuma responsabilidade peitá..ias) são claramente oomunicadas dentro do prazo responsabilidade quanto a datas
• DeKve,ables faltantes
registrados na Tabela 2- 3 cotn minha opinião sobre como eles estão relacionados à
gestão de projetos.
O empodera tnento da equipe permite que o gerente de projeto cotnpartilhe in-
formações com os membros de equ ipe e perm ite também que estes sintam que têtn
controle sobre seu próprio trabalho. O resultado é que e.ada um se torna responsável
pelo projeto.
Resultados dos remédios Os resultados da apl icação desses remédios aos perigos
são exibidos na Tabela 2-4. Cha,no m inha visão sobre a nova 1naneira de fazer as
coisas de "estado at raente", uma vez que ela leva a um estado que leva as pessoas ao
sucesso.
Conclusão
Priorizar o gerenciamento proativo, 1nanter o t rabal ho em andamento e empoderar
suas equipes são o segredo de gerenciar um projeto bem-sucedido. Não há nada nesta
seção que já não tenha sido escrito ou d ito mi l vezes. Nada deve soar novo para utn
gerente de projetos. Ainda assim, continua1nos vendo os perigos abundando aqui e ali.
Isso me leva à conclusão de que é a aplicação desses conceitos que é o desafio. Percebo
que, depois de ler um bom artigo ou assistir a um curso de gestão, fico mu ito entusias-
mado para experimentar as novas técnicas, ,nas, ao primeiro sinal de problemas, volto
para ,n inha zona de conforto. Portanto, proponho que haja utn quarto remédio para
os perigos - ser consciente. Isso não é nada alétn de estar ciente do que está acontecen-
do e como você está gerenciando seu projeto.
Venho para o traba lho todas as manhãs um pouco mais cedo do que o resto da
equipe para poder ter meu momento etn silêncio e pensar no t rabalho que precisa ser
feito (não somente naquele dia, ,nas nos próximos dias também). Também lembro a
mÍtn 1nesmo de entrar no modo "pare e pense". Uma série excelente que aborda essa
técnica são os livros sobre " inteligência emocional", de Daniel Goleman.
Sempre haverá perigos rondando o seu projeto, mas se você estiver consciente de-
les pode identificá-los quando estiverem entrando em cena e pode ser capaz de evitar
que eles levem seus projetos ao caos. Boa sorte!
Referências
Deming, W. E. 0111 o( the Crisis: Quality, Productivity a11d Competítive Positio11, Cambridge:
Cambridge Uni,,ersity Press, 1982, 1986.
Gleman, D. \'(lorki11g with Emotio11al l11tellige11ce, New York: Bantam Books, 1998.
Jornada rumo à excelência
3.0 Introdução
Toda e1npresa possui suas próprias forças, ou forças motrizes, como d iscutimos no
Capítulo 1, que a forçam a embarcar em uma jornada rumo à excelência em gestão de
projetos. Algumas empresas co1npletam essa jornada em dois ou três anos, enquanto
out ras levam uma década ou 1na is . Neste capítulo, discutire1nos as abordagens adota-
das por diversas empresas. Cada u1na delas escolheu um cam inho diferente, mas todas
alcançaram certo grau de excelência em gestão de projetos.
Algumas empresas en1barcan1 nessa jornada a pedido de seus próprios funcioná-
rios, enquanto outr as são forçadas pelas ações de concorrentes e clientes. De qual-
quer n1aneira, há fo rças n1otr izes que propagam a busca da excelência em gestão de
proJetos.
As fo rças motrizes que levam à excelência, co1no discutido anteriormente, in-
cluem:
• Projetos de capital
• Expectativas do cliente
• Competitividade
• Compreensão por parte dos executivos
• Desenvolvimento de novos produtos
• Eficiência e eficácia
Até mesmo a menor organização manufatu reira pode gastar milhões de dólares a
cada ano em projetos de capita l. Sem boas estimativas, um bom controle de custos e
um bo1n contro le de cronogramas, eles podem comprometer o fluxo de caixa da o rga-
nização, forçando-a a dem itir trabalhadores pelo fato de equipamentos de capital não
estare1n disponíveis ou não estarem devidamente instalados, e irritando o cliente co1n
atrasos na entrega de produtos ou serviços. Em organizações e empresas manufaturei-
ras não o rientadas a projetos, os projetos de capita l constitue1n as forças motrizes que
as leva1n à maturidade.
As expecta tivas dos clientes podem ser uma outra força mot riz. Atualmente, os
clientes esperam não apenas que o fornecedor entregue um produto ou serviço de qua-
lidade, mas também que exerça essa atividade com práticas sólidas de gestão de p ro -
jetos. Tais práticas incluem a e1nissão eficiente e periódica de relatórios de status eco-
municações com o cliente que sejam eficientes de modo geral. Não deveria surpreender
o fato de que empresas co1n propostas de baixo custo talvez não ganhem licitações de
cont ratos devido a práticas precárias de gestão de projetos em projetos empreend idos
anteriormente para o cliente.
A tercei ra força 1not riz comum por trás da gestão de pro jetos é a cotnpetitividade.
Etnpresas como a IBM e a He,vlett-Packa rd veem a gestão de projetos como uma a rma
competitiva. Empresas orientadas a projetos que sobrevivetn na base de contratos (i.e.,
fonte de renditnentos) com empresas externas fazem propaganda de suas habilidades
por interméd io de cada proposta feita . A diferença entre ganhar ou perder um contra-
to pode muito bem depender do histórico de sucessos e fracassos nesse item.
A fo rn1a mais comun1 de con1petitividade é a concorrência entre d uas ou n1ais
empresas pelo mesn10 traba lho . Muitos contra tos já fo ram gan hos con1 base no
desempenho prévio de uma empresa em gestão de p rojetos, supon do que todos os
outr os fatores sejam iguais. Não é incon1um hoje que as empresas façan1 contrata-
ção de fornecedor único devido ao valor atribuído à capacidade da empresa con-
t ratada de ter um bon1 desempenho . Un1 subconj unto desse tipo de competitividade
é quando u ma en1presa descobre que tercei rizar é n1ais barato do q ue usar seus
próprios recu rsos internos devido à matu ridade dos sistemas de gestão de p rojetos
da empresa contratada. Isso pode faciln1ente resultar em den1 issões, funcionários
insatisfeitos e baixo mora l. Isso cria un1 am biente de rivalidade interna e pode impe-
dir que uma o rganização implemente a gestão de p rojetos com sucesso e an1adureça
sua abordagem.
Utna qua rta força motriz que leva à excelência é a adesão dos executivos. Um su-
porte visível e participativo por pa rte dos executivos pode reduzi r o impacto de muitos
obstáculos. Ent re os típicos o bstáculos que podem ser superados por meio do suporte
executivo estão:
• Gerentes de área que não apoiam o projeto
• Funcioná rios que não apoia tn o projeto
• Funcioná rios que acredita m que a gestão de projetos não passa de uma moda
• Funcioná rios que não cotnpreendem cotno a empresa irá se beneficiar
• Funcioná rios que não cotnpreendem as expecta tivas do cliente
• Funcioná rios que não cotnpreendem as decisões dos executivos
Uma outr a força motriz por trás da gestão de projetos é o desenvolvitnento de
novos produtos. Ele pode levar 1neses ou anos e pode mui to bem ser a principal fonte
de renda da empresa por muitos anos ad iante. O p rocesso de desenvolvimento de no-
vos produtos engloba o tempo necessário para desenvolver, comercializa r e introduzi r
novos produtos no mercado. Ao aplicar os pri ncípios da gestão de projetos ao desen-
volvi1nento de novos produtos, uma empresa pode prod uzir mais em um período de
tempo mais curto e com custos inferiores e utn nível de qualidade potencia lmente alto
e, ainda assitn, satisfazer as necessidades do cliente.
Em certos setores, o desenvolvin1ento de novos produtos torna-se necessá rio à
so brevivência, pois pode gerar u m grande fluxo de receita para os anos segui ntes.
Pratican1ente todas as en1presas estão envolvidas, de uma maneira ou de o utra, no
desenvolvimento de novos produtos, n1as o n1aior in1pacto pode estar nos fornece-
dores dos setores aeroespacial e de defesa. Para eles, o desenvolvimento de novos
produtos e a satisfação do cliente podem levar a cont ratos de vá rios anos, talvez por
20 anos ou n1ais . Con1 o aperfeiçoamento de prod utos, a duração pode se estender
ai nda n1ais.
Os clientes só aceitarão pagar preços razoáveis. Portanto, qualquer metodologia
para o desenvolvi mento de novos produtos deve ser integrada a um sistema eficiente
de gerenciamento e contro le de custos. As empresas contrata das dos setores aeroespa-
cial e de defesa se tomaram especialistas em sistemas de mensur ação de valor agrega-
do. Os sobrecustos de que geralmente ouvimos falar nos projetos de desenvolvimen-
Eficiência e Projetos
eficácía de capital
Desenvolvimento
de novos produtos
Compreensão por
parte dos executivos "-- Competitividade
Figura 3- 1 Os componentes da sobrevivência.
to de produtos para o governo são atribuídos não necessariamente à ineficiência da

gestão de projetos ou à inadequação do cont role de custos, mas mais às mudanças de
escopo e aos aperfeiçoamentos.
A melhoria na eficiência e eficácia gera is da e1npresa às vezes é d ifícil, se não
impossível. Gera lmente exige mudanças na cultura corporativa, que sempre são dolo-
rosas. A velocidade com que essas mudanças aceleram a implementação da gestão de
projetos gera lmente depende do ta1nanho da organização: quanto maior, 1nais lenta a
mudança.
A sobrevivência é, obviamente, a força ma is poderosa por t rás da excelência da
gestão de projetos. Pode-se argu1nentar que todas as outras forças são tangencia is à
sobrevivência (ver Figura 3- 1). E,n alguns setores, como o aeroespacial e o de defesa,
u1na gestão de projetos malfeita pode rapidamente levar à falência. Empresas menores,
no entanto, certamente não estão imunes a esse r isco.
Às vezes, há outros tipos de forças motrizes:
• Aumento no ta1nanho do projeto determinado pela necessidade de crescer
• Clientes que exige1n uma i1nplementação mais rápida
• Clientes que exige1n experiência em projetos para terem certo grau de garantia de
que o deles será concluído com sucesso
• Globalização da organização determinada pela necessidade de crescer
• Consistência na execução a fim de ser tratado co1no sócio, e não fornecedor
3.1 Planejamento estratégico para a gestão

de projetos
Por ma is de cinco décadas, a gestão de projetos amadureceu do que já foi considerado
u1na 1noda que logo desapareceria para u1na co1npetência estratégica e um plano de
carreira necessário para o crescimento e a sobrevivência da empresa. Ela agora está
sendo usada e1n praticamente todos os setores e em todas as partes da empresa. Ama-
durece1nos ao ponto de acreditarmos que estamos gerenciando a e1npresa como se ela
fosse uma série de projetos, nos quais se espera que os gerentes de projetos tomem tan-
to decisões de projeto quanto decisões empresariais. Eles passara1n a ser considerados
e1npresários e1n vez de apenas gerentes de projetos.
Atualmente, a gestão de projetos é reconhecida como uma série de processos que
pode ser usada em cada projeto, independentemente de sua duração ou complexidade,
do valor do projeto ou de sua exposição a riscos. Contudo, a parte da empresa na qual
a gestão de projetos demorou a ser aceita, pelo 1nenos até agora, foi a de projetos de
execução de p lanejamento estratégico. Pode-se se1npre argu1nentar que gerenciar pro-

jetos de execução de planejamento est ratégico não é diferente de gerenciar qualquer
out ro tipo de projeto. Embora esse argumento possa ter seu mérito, há várias diferen-
ças importantes que têm de ser consideradas. Os gerentes de projetos precisam pen-
sar estrategicamente, em vez de tática ou operacionalmente, e ta lvez eles tenham que
passar da liderança trad icional de gestão de projetos para uma liderança est ratégica,
dependendo da co1nplexidade do projeto.
Por que planos estratégicos fracassam

Para saber como a gestão de projetos pode beneficiar o planejamento estratégico, é
importante compreender por que alguns planos estratégicos fracassam. Alguns dos
motivos comuns, vistos através do olhar dos gerentes de projetos, incluem:
• Negligência quanto à compreensão de como os fatores ambienta is da empresa
pode1n influenciar a visão que a gerência sênior tem do futuro
• Compreensão inadequada do comportamento do consu1nidor ou das ações do
cl iente
• Pesquisa inadequada antes da aprovação do projeto
• Escopo pouco definido ou ma l definido
• Caso empresaria l mal documentado, resultando na aprovação do projeto errado
• Falha em obter adesão dos executivos e das partes interessadas desde o início
• Má governança executiva uma vez que a estratégia tenha começado a ser imple-
mentada
• Mudanças constantes dos membros da equipe de governança
• Superestimação das competências do pessoal necessárias para a execução do
proieto
• Esforços de planejamento de capacidade fracos, resu ltando e1n projetos com falta
de pessoal
• Recusa dos gerentes funcionais a co1nprometerem os recursos adequados ao longo
do projeto est ratégico
• Não comprometimento com o projeto por parte dos funcionários
• Fa lta de explicações sobre a importância do projeto para a equipe que irá exe-
cutá-lo
• Falha ao explicar para a equipe de execução de projeto os incentivos ou benefícios
financeiros de trabalhar num projeto de longo prazo
• Não magnitude das mudanças organizacionais necessárias para que o projeto seja
bem-sucedido
• Incapacidade de gerenciar mudanças de forma eficiente
• Desconsideração dos impactos das mudanças tecnológicas durante a execução do
proieto
• Estimativas malfeitas de prazo e custos
• Equipe de execução que não consegue t rabalhar co1n requisitos mal definidos ou
que são constantemente a lterados
• Má integração do projeto em toda a organização
• Comunicação inadequada
Há inúmeros out ros motivos para que os projetos de execução de planejamen-
to estratégico fracasse1n. Essas causas pode1n ocorrer em qualquer projeto, mas, nos
projetos de execução de planejamento est ratégico, os danos potenciais para a e1npresa
podem ser bastante severos.
Gestão de projetos: uma perspectiva executiva

Com a capacidade de produzir repetidos sucessos em projetos, não é de se ad1n irar que
os executivos agora estejam percebendo o valor de se usar a gestão de projetos para a
execução de um plano estratégico. Há vários motivos pelos quais os executivos enxer-
gam o valor de usá-la para essas atividades:
• A execução leva significativamente mais tempo do que o planejamento e consome
mais recursos. Os executivos não têm tempo para passar anos coordenando e in-
tegrando trabalhos em um enonne nú1nero de áreas funcionais.
• Sem um plano de imple1nentação bem-sucedido, o p lanejamento est ratégico não
tem como ter êxito.
• Os gerentes de projetos podem realizar de forma exitosa a separaç.ã o disfuncional
entre planejamento e execução.
• Os objetivos estratégicos de longo prazo tên1 de ser decon1postos en1 objetivos de
curto prazo para sitnplificar a execução. Isso pode ser feito con1 faci lidade usando as
ferran1entas da gestão de projetos e tuna estrutura analítica do projeto (EAP).
• As técnicas de seleção de gerentes de projetos, possivelmente co1n o uso de um
escritório de gestão de projetos (PMO), pode "casar" os recursos apropriados aos
. .
proJetos existentes.
• Os ativos de processos organizacionais usados na gestão de projetos podem man-
ter a gerência sênior atua lizada sobre o status do projeto.
• Os objetivos de planejamento estratégico, devido à duração de longo prazo, são
extremamente orgânicos e estão sujeitos a mudanças. Os gerentes de projetos sa-
bem como gerenciar e cont rolar as 1nudanças.
Planejamento estratégico: uma perspectiva de gestão

de projetos
O planejamento est ratégico é o processo de defin ição de onde e como uma organ i-
zação gostaria de estar posicionada no futuro. O futuro pode ser 1nedido em uma
janela de três, cinco ou 10 anos (ou ma is). O plano estratégico se baseia em visão,
missão, consciência socia l e valores da e1npresa. O planejamento est ratégico exige uma
compreensão da empresa e de seu ambiente. Os executivos, mais do que os gerentes
de projetos, têm uma melhor compreensão dos fatores ambientais da empresa, a sa-
ber, produtos oferecidos, mercados atendidos, tecnologias presentes e futuras, base de
fornecedores, 1nercados de 1não de obra, condições econômicas, ambiente político e
exigências regulatórias.
Os executivos estabelecem objetivos de a lto nível para o que eles queretn que
seja feito . Gera lmente, isso não passa de uma " lista de desejos" que pode ou não ser
próxi1na da realidade. A função do gerente de projetos é determinar se eles podem ser
realizados. Isso exige um caso empresarial claro para cada projeto, uma declaração
de escopo e o uso da est rutura ana lítica do projeto (EAP) para decompor os objeti-
vos de alto nível em subobjetivos, ou objetivos de nível mais ba ixo que são fáceis de
compreender e cumprir. Se o gerente de projetos e a equipe de projeto acreditarem que
eles podem ser realizados, então se cria um plano de aç.ã o formal para o projeto. Se-
gundo a Wikipédia, a enciclopédia livre, uma das metas cent rais ao se criar um p lano
estratégico é desenvolvê-lo de uma forma que seja faci lmente t raduzível em planos de
ação. A maioria dos planos estratégicos aborda iniciativas de alto nível e metas abran-
gentes, 1nas não é articulado (traduzido) em projetos e tarefas cotidianas que são ne-
cessárias para real izar o plano. A terminologia ou escolha de palavras e o nível em que
u1n p lano é escrito são a 1nbos exemplos de maneiras fáceis de fracassar na tradução
de seu plano estratégico de uma 1naneira que faça sentido e que seja exequível pa ra os
out ros. Gera lmente, os planos são cheios de termos conceituais que não estão ligados
às realidades cotidianas da equipe que supostamente irá realizá-los.
Superficialmente, pode pa recer que os projetos de execução de planejamento es-
tratégico podem se t ratados como qualquer outr o projeto. Entretanto, se o lharmos
para as áreas de conhecimento do G11ia PJ\1BOK®, podetnos ver agumas diferenças
significativas que são, em grande parte, atribuídas ao comprimento do p ro jeto. Algu-
mas dessas diferenças são apresentadas na Tabela 3- 1.
Os benefícios da gestão de projetos

Talvez o principal benefício de usar a gestão de projetos, o que a torna extreman1ente
interessante para os projetos de planejamento estratégico, seja oferecer aos executivos e
clientes un1 único ponto de contato para relatórios de status. A maior parte dos projetos
de planejamento estratégico de hoje é tão con1plexa que não pode ser gerenciada eficien -
temente por um gerente de área funcional, que pode ter tun confl ito entre as tarefas espe-
cíficas de sua área e as tarefas do projeto. Esses projetos exigem o esforço coordenado de
várias áreas funcionais, como vendas, marketing, engen haria e produção. Sem un1 ponto
de contato único para os relatórios de status, os executivos precisariam eles próprios fa-
zer coordenação e integração, e é muito itnprovável que eles teriam ten1po para isso. Da
mestna fonna, os gerentes funcionais não tên1 tempo suficiente para gerenciar suas áreas
fu ncionais e realizar o t rabalho de integração em vários projetos. A necessidade da gestão
de projetos é bastante nítida.
TABELA 3-1 O Guia PMBOK'° e a execução de projetos estratégicos

Área de conhecimento Impactos nos projetos de planejamento est ratégico
Gerenciamento de A integração do esforço pode muito bem englobar toda a organização tanto domésti-
integração ca quanto globalmente
Gerenciamento de O escopo pode mudar à medida que a tecnologia muda. A duração do projeto toma
escopo imperativo que exista um processo de controle de mudanças de escopo significati-
vas. A linha de base do escopo pode parecer uma janela móvel que exige constan-
tes atualizações
Gerenciamento de tempo Encontrar o •casamento" perfeito entre a disponibilidade das pessoas certas e as
mudanças constantes no escopo pode ter um efeito devastador na geração do cro-
nograma. Perder pessoas porque elas precisam •apagar incêndios" em suas áreas
funcionais pode causar um sério impacto
Gerenciamento de custos Prever o verdadeiro custo do projeto é quase impossível. É necessário que se faça
uma reestimação rotineira para garantir que os benefícios e o valor de negócio ainda
excedam os custos
Gerenciamento da As expectativas dos dientes sobre a qualidade e as forças competitivas podem cau-
qualidade sar grandes mudanças na direção do projeto
Gerenciamento de Quanto mais longo for o projeto, maior a probabilidade de que ocorram mudanças
recursos humanos nos recursos, possivelmente mudanças para pior nos recursos humanos. Pode ser
dif!cil manter a motivação no longo prazo
Gerenciamento das Os requisitos de comunicação podem envolver a empresa inteira. Mudanças nas
comunicações partes interessadas também têm um sério impacto no plano de comunicação
Gerenciamento de riscos O projeto pode exigir que se tenha uma equipe dedicada de gerenciamento de riscos
Gerenciamento de A duração do projeto pode dificultar para que se determinem os custos de aquisição
aquisições antecipadamente
Gerenciamento de partes Devido à duração do projeto, o gerente de projetos pode acabar interagindo com um
interessadas conjunto de partes interessadas no final do projeto que é diferente daquele com que
interagiu no início
Há também mu itos outros benefícios propiciados pelo uso da gestão de projetos,

a lguns dos quais são exibidos na Tabela 3- 2.
Os benefícios exibidos na Tabela 3- 2 aplicam-se a quase todos os p rojetos, in-
clusive projetos de execução de gerenciamento estratégico, projetos con1plexos e
p rojetos tradicionais . Há, porém, a lguns benefícios adicionais que afetan1 os projetos
de execução de planejan1ento estratégico mais do que outros. Estes são ilustr ados na
Tabela 3- 3 .
Derrubando mitos
Quando olhamos para as Tabelas 3- 2 e 3- 3 e ve1nos todas as vantagens, deve1nos nos
perguntar: " Por que ainda há resistência à aceitação da gestão de projetos, especia l-
mente para os p ro jetos de execução de planejamento estratégico?". A resposta é bem
clara; a inda há mitos sobre o uso da gestão de projetos para ativi dades relacionadas
ao planejamento estratégico.
TABELA 3-2 Benefícios de usar a gestão de projetos

Atributo Benefício
Eficiência Permite que uma organização assuma mais trabalho em menos tempo sem aumentos no
custo ou degradação da qualidade
Rentabilidade Mantendo todos os outros fatores fixos, a rentabilidade deve aumentar
Mudanças Permite maior planejamento antecipado, o que deve reduzir o número de mudanças de
de escopo escopo adiante e evitar que mudanças indesejadas ocorram
Estabilidade Focaliza-se na eficiência do trabalho de equipe, comunicação, cooperação e confiança em
organizacional vez de na reestruturação organizacional
Qualidade Qualidade e gestão de projetos andam de mãos dadas; ambas enfatizam o planejamento
antecipado
Riscos Permite melhor identificação e mitigação de riscos
Solução de Os processos de gestão de projetos permitem que sejam tomadas decisões informadas na
problemas hora certa
TABELA 3-3 Benefícios adicionais dos projetos de execução de planejamento estratégico

Atributo Benefício
Alinhamento Melhor alinhamento de projetos aos objetivos estratégicos corporativos
Subdesempenho Identificação mais rápida de investimentos com subdesempenho
Planejamento de Melhor análise do planejamento de recursos corporativos e da disponibilidade de recur-
capacidade sos qualificados
Priorização Combinação de esforços de planejamento de capacidade e gestão de projetos permite
melhor priorização do portfólio de projetos
Mitigação de riscos Permite melhor mitigação dos riscos de negócio por meio do uso de mais cenários hipotéticos
Tempo de colocação Permite menor tempo de colocação no mercado
no mercado
Tomada de decisões Decisões mais informadas e na hora certa devido à disponibilidade de informações
essenciais
Eficácia e eficiência Permite trabalhar em mais projetos sem aumentar o número de pessoas necessárias
Melhor fluxo de Eliminação da duplicação de esforços por gerentes que não estão cientes do que os ou-
informações tros estão fazendo
Seleção de projetos Melhor análise do que é ou não uma boa ideia
Mito n.• 1: Os gerente de projetos têm um forte conhecimento técnico, mas um

conhecimento limitado sobre a empresa. Embora seja verdade que, historicamente,
os gerentes de projetos vên1 de disciplinas técnicas e n1u itos até possuem mestrados
e doutorados en1 disciplinas técnicas, o gerente de projetos de hoje tem n1ais un1a
compreensão geral de tecnologia do que um domín io tecno lógico profundo, mas
tambén1 un1 excelente conhecimento da empresa. O conhecimento en1presarial é es-
sencial para fazer a ponte entre estratégia e execução de maneira eficiente. Os geren-
tes de projetos que são considerados "globais» precisan1 ter uma boa con1preensão
dos negócios da en1presa do cliente a lém dos de sua própria en1presa. Essa é uma
necessidade para con1petir em un1 mercado global. Esses gerentes de projetos globais
tambén1 estão sendo treinados em gerenciamento de relações com as partes interes-
sadas, política, cultura e religião, já que todos esses assuntos tên1 un1 impacto sobre
o projeto do cliente.
Acreditamos hoje que estamos gerenciando os negócios de nossa empresa como
se eles fossem uma série de projetos, nos quais se espera que os gerentes tomem tanto
decisões de projeto quanto de negócios. Algumas empresas estão exigindo que seus
gerentes de projetos se certifiquem ou façam cursos que lhes dê uma certificação como
ana lista de negócios.
Mito n .• 2: Os gerentes de projetos devem ser designados depois de o projeto ser
aprovado e o caso de negócio, desenvolvido. Há anos, os gerentes de projetos era1n
envolvidos e1n un1 projeto no final de sua fase inicia l, en1 vez de logo no início. Acre-
ditávan1os que, como os gerentes de projetos tinhan1 un1 conhecimento li1n itado dos
negócios da empresa, eles não podiam contribuir com nada válido durante o processo
de iniciação. Depois de os projetos terem sido selecionados, os gerente de projetos era1n
envolvidos e recebian1 orden1 para co1neçar a execução. Hoje, eles são envolvidos desde
o início do projeto e do processo de seleção, e se espera que eles façan1 u1na contribui -
ção val iosa devido aos seus conhecin1entos sobre negócios .
Mito n.• 3: Se in1plementarmos a gestão de projetos, os gerentes de projetos come-
çarão a tomar decisões que deveriam ser tomadas nos níveis executivos da gerência. O
planejamento estratégico e as decisões necessárias que o acompanham são realizados
por executivos, não por outra pessoa para eles. Entretanto, e1n alguns casos, as deci -
sões de execução de planejamento estratégico podetn ser to1nadas para os executivos
em vez de por eles. Os executivos sempre temera1n delegar autoridade e responsabi -
lidade aos gerentes de projetos no que diz respeito à tomada de decisões de projetos.
Esse mito por si só tem sido um grande impedimento para a i1nplementação bem-
-sucedida da gestão de projetos.
O problema foi parcialn1ente resolvido com a criação da posição do patroci-
nador executivo ou pat rocinador do projeto. Os gerentes de projetos passaran1 a
poder tomar decisões técnicas, n1as os patrocinadores de projeto se reservavan1 o
direito de ton1ar toda e qua lquer decisão relacionada aos negócios. Essa aborda-
gem funcionava bem para projetos de duração razoaveln1ente curta. No entanto,
para os projetos de execução de planejamento estratégico, que pode ter de cinco
a 10 anos de duração, o número de decisões que precisam ser tomadas pode ser
esmagadora . Portanto, para derrubar esse n1 ito, é benéfico definir claramente a fun-
ção do gerente de projetos no que diz respeito às responsabilidades e à autoridade
de tomada de decisões.
Mito n. • 4: Os gerentes de projetos não sabem como usar os ativos de processos
organizacionais de forma eficiente para os sistemas controlados de mensuração para
que possam ser ton1adas decisões inforn1adas. Nas últi1nas cinco décadas, as duas
métricas principais usadas pelos gerentes de projetos eram prazo e custo. Isso ocorria
devido à regra de inversão, que afirma que gera lmente selecionamos as 1nét ricas mais
fáceis de medir e divu lgar, embora elas possam não oferecer um quadro muito claro
sobre a saúde do projeto. Apenas prazo e custos não podem prever o sucesso de um
projeto ou se o valor desejado terá sido almejado na conclusão do projeto. Isso é par-
ticularmente válido para projetos de execução de planejamento estratégico.
Atualmente, há sem inários no mercado de traba lho sobre técnicas de mensuração.
Há também livros didáticos sobre técnicas de mensuração que discutem que qualquer
coisa pode ser medida se você si tnplesmente compreender as informações que estão à
sua disposição. O resultado foi a criação de mét ricas adicionais para a gestão de pro-
jetos. Acredita-se que devamos considerar as seguintes 1nétricas cent rais nos projetos
de hoje:
• Tempo (prazos)
• Custos
• Recursos
• Escopo
• Qualidade
• Itens de ação (pendências)
Essas métricas centra is se apl icam a todos os projetos, mas há que se adicionar
out ras, baseadas em tamanho, natureza, escopo e importância do projeto. Como os
projetos de implementação do p laneja tnento est ratégico podem ter longa duração,
podem ocorrer mudanças significativas. Portanto, precisamos permitir que as mét ricas
mudem no decorrer do projeto. Estabelecer um conjunto de mét ricas centra is que pos-
sam ser usadas em cada projeto pode ser difíci l.
Como a gestão de projetos pode ajudar

o planejamento estratégico
Há sen1pre situações especiais e1n que a gestão de projetos pode beneficiar significativa-
mente uma organização. En1 uma empresa que produz eletrodotnésticos, e.ada área fun-
cional tinha permissão para realizar seu próprio planejamento estratégico. O problema
ocorria quando as unidades funcionais precisavam trabalhar juntas en1 um n1esn10 pro-
jeto. Nessa en1presa, novos produtos eram lançados etn feiras de negócios, e havia duas
feiras de negócios por ano. Perder o lança1nento de un1 produto etn u1na delas poderia
facihnente resultar na perda de receitas por seis meses, até a feira seguinte.
O lançamento de novos produtos era de máxima prioridade no plano est ratégico
do departamento de marketing. O depa rtamento de P&D, por outro lado, tin ha mais
de 300 projetos na fila. Na lista de prioridades da P&D, os novos produtos de que o
marketing precisava para as feiras de negócios estavam lá no final de sua lista de prio-
ridades. As batalhas entre o marketing e P&D ocorriam continuamente.
Em uma outra empresa, o 1narketing podia priorizar projetos como parte de suas
atividades de planeja tnento estratégico. Para cada projeto, eles também priorizavam
os atr ibutos do projeto/produto que tinha influência d ireta sobre o modo como o pro-
duto seria anunciado e comercia lizado. Entretanto, quando o projeto/produto passava
para a fase de produção, o pessoal dessa área geralmente tinha um conjunto de prio-
ridades diferentes para os atributos. Nesse caso, as batalhas por prioridades ocorriam
ent re o departamento de marketing e o de produção.
Em ambos os exemplos anteriores, os problemas foram resolvidos quando o
pessoal da gestão de projetos solicitou que a organização criasse uma única lista de
prioridades para todos os projetos da empresa. O resultado foi que os departamentos
de P&D, engenharia e produção se reunir iam a cada t rês 1neses e chegariam a um
acordo sobre as prioridades dos projetos. No entanto, havia projetos detnais na fila de
priorização. Decidiu-se, então, que apenas 20 projetos de cada vez seriam priorizados.
Isso beneficiou muito o processo de seleção de equ ipes para os projetos, porque todos
agora escavam traba lhando a partir da mesma lista de prioridades.
Outro uso eficiente da gestão de projetos é fazer a anál ise de lacunas e o preenchi-
mento de lacunas. A análise de lacunas é usada para fortalecer a posição competitiva
de sua empresa ou para reduzir a posição competitiva de seus concorrentes reduzindo
lacunas. Projetos são estabelecidos para tirar proveito das melhores práticas e lições
aprend idas e1n outros projetos, através do que se pode diminuir lacunas. Essas lacunas
podem ser:
• A velocidade co1n que novos produtos são introduzidos (tempo de colocação no
mercado)
• Competitividade em termos de custos
• Competitividade em termos de qua lidade
• Introdução de novas tecnologias ou desempenho de produto
Liderança estratégica da gestão de projetos

Mostramos algumas das maneiras como a gestão de projetos pode beneficiar a exe-
cução de um plano est ratégico. Para que isso aconteça, o gerente de projetos pode
precisar mudar seu estilo de liderança de t radicional, que se focal iza fortemente na
liderança situacional orientada à equipe de projeto, para estratégico, no qual o resulta-
do final pode afetar as mudanças organizacionais em toda a empresa.
"Liderança estratégica" é um tenno normalmente reservado para os níveis mais
sênior da gerência. Ele impl ica a capacidade dos executivos de expressar uma visão
est ratégica para o futuro da e1npresa e, então, motivar e convencer a organização
a adquirir ou seguir essa visão. A liderança estratégica exige o desenvolvi1nento de
planos de ação, e é aí que a gestão de projetos assume 1náxima importância. Visões
não ajudam 1nuico, a menos que planos possam ser desenvolvidos e implementados
para torná-las uma realidade . Gerenciar projetos que envolvem a Ílnplementação de
uma estratégia é significativamente diferente de gerenciar projetos trad icionais a que
alguns de nós estamos acostumados. Ao contrário dos planos de ação de projetos tra-
diciona is, que se baseiam e1n uma especificação do traba lho bem definida, o gerente
de projetos precisa desenvolver planos de ação que possam ser baseados em comple-
xidade, ambiguidade, incerteza e conhecimento volátil. Devido ao grande número de
variáveis desconhecidas e de sua capacidade de mudar constantemente, os gerentes de
projetos têm de compreender que seu trabalho exige decisões consequentes, que cê1n
de envolver os gerentes que detêm o controle último dos recursos necessários para
executar essas decisões.
Se os projetos exigem certos graus de inovação, as habilidades de liderança deve1n
ser desenvolvidas em torno de se conseguir fazer a equipe ser inovadora e criativa.
Sessões de brainstorming e de solução de proble1nas poderiam ocorrer toda semana.
Habi lidades de facilitação também são uma necessidade. As habilidades de liderança
necessárias para projetos de inovação de longo prazo podem ser sign ificativamente
diferentes das habilidades necessárias para entregar ao cliente um deliverable simples.
Para ser eficiente na liderança estratégica, o gerente de projetos tem de perceber
que ele agora é um gerente de mudanças organizacionais e, como cal, pode precisar
criar "mentes preparadas" em grande escala. O gerente de projetos e possivelmente
toda a equipe agora têm de funcionar como líderes de torcida e executores ao mesmo
tempo, a fim de fazer as pessoas de toda a organização concordarem co1n um propó-
sito comum. Para esses tipos de projetos, a equipe geralmente é chamada de equipe
de apoio estratégico (SST, strategy s,,pport team). Para a SST funcionar de forma efi-
ciente, seus 1ne1nbros precisam estar dispostos a orientar e guiar o processo est ratégico
à 1nedida que ele se desenvolve. O desafio mais difícil para a SST é em projetos que
exigem mudanças organizaciona is. Existem obstáculos sign ificativos que têm que ser
superados. Os membros da SST ta tnbém têm de ser inovadores e agentes de mudan-
ças, capazes de ver o quadro gera l e pensar estrategicamente etn vez de operacional
ou taticamente. Eles devem abrir mão do pensa tnento de curto prazo e se focalizar no
futuro distante.
O principal objetivo da liderança est ratégica é tornar a organ ização mais est ra-
tegicamente produtiva e inventiva além de eficiente e eficaz. Os t raba lhadores devem
ser encorajados a seguir suas próprias ideias quando viável e oferecer feedback so-
bre inovações técnicas ou comportamentais que podem ser captadas através de lições
aprendidas ou 1nelhores práticas. As lições aprendidas ou melhores práticas perm item
que as empresas focal izem somente nas energias certas que ajudarão uma empresa a
lucrar no longo prazo.
Tradicionalmente, esperava-se que os gerentes de projetos captassem os conhe-
cimentos relacionados a p rojetos e os enviassem ao PMO para análise e a rn1azena-
mento. No entanto, com a liderança est ratégica, mais conhecimentos relacionados
aos negócios precisan1 ser captados e a limentados en1 um repositório corporativo de
conhecimentos.
Características estratégicas de liderança em gestão

de projetos
Há mais de quat ro décadas, examinamos as habilidades necessárias para ser um ge-
rente de projetos e oferecer u1na liderança de projeto eficiente. As análises foram feitas
com foco no projeto tradiciona l, que pode durar de 12 a 18 meses ou menos. Além
d isso, a especificação do t rabalho é razoavelmente bem definida, muitas das pessoas
podem ter sido designadas em tempo integral, mas apenas por a lgumas semanas, e o
resultado do projeto pode afetar somente utn pequeno nú tnero de pessoas. Os prazos
potencia lmente longos dos projetos est ratégicos agora estão nos forçando a revisar
a lgu1nas dessas habilidades de liderança.
É quase impossível criar uma lista que inclua todas as competências necessárias
para que alguém ofereça uma liderança estratégica em gestão de projetos. No entanto,
podemos mostrar algumas das 1nudanças possíveis em liderança que serão necessárias.
Elas aparecem na Tabela 3-4. Há um argumento válido de que todos os gerentes de
projetos precisam dessas habilidades, mas elas podetn ser mais cruciais em projetos
estratégicos.
O gerente de projetos como um gerente de mudanças

A função dos projetos está em constante evolução. Como afirmado na Tabela 3-4,
a lguns projetos de p lanejamento estratégico são criados para que ocorram mudanças
organizaciona is, que podem afetar a empresa toda no mundo todo. Um exemplo pode
ser a implementação de um novo sistema de segurança, informação, ou e-mail seguro
etn toda a corporação.
A nova questão passa a ser: "Quen1 irá gerenciar a in1plen1entação das mudan-
ças un1a vez que o projeto esteja pronto para implementação?". Historicamente, os
gerentes de projetos criavam os deliverables, e alguén1 das categorias hierárquicas
da gerência assumia a liderança pa ra implementar as mudanças. Hoje, pede-se que
o gerente de projetos assuma o papel de liderança no gerenciamento de n1udanças
Capítulo 3 J ornada rumo à excelênc ia 117
TABELA 3-4 Diferenças entre os estilos tradicional e estratégico da liderança em gestão

de projetos
Características Diferenças
Autoridade Da liderança sem autoridade à autoridade significativa
Poder Do poder legítimo para o uso ponderado do poder
Tomada de decisões De certo nível de tomada de decisões a ter autoridade para uma tomada de
decisões significativa
Tipos de decisões De decisões somente relacionadas a projetos a decisões de projeto e de negócios
Disposição a delegar O comprimento e tamanho do projeto forçará os gerentes de projetos a delegar
mais autoridade e tomada de decisões do que normalmente fariam
Rdelidade De fidelidade ao projeto à fidelidade à visão corporativa e à empresa
Habilidades sociais São necessárias fortes habilidades sociais, já que poderemos trabalhar com as
mesmas pessoas por vários anos
Motivação Aprender como motivar os trabalhadores sem usar recompensas financeiras ou
poder
Habilidades comunicativas Comunicação em toda a organização em vez de com apenas alguns poucos
selecionados
Relatório de status Reconhecer que o status de projetos estratégicos não podem ser feitos apenas
de prazo e custos
Perspectiva/ponto de vista Ter um ponto de vista muito mais amplo, especialmente de uma perspectiva
empresarial
Visão Ter a mesma visão de longo prazo que os executivos e promovê-la em toda a
empresa
Compaixão Ter mais compaixão pelos trabalhadores, já que eles podem ser designados por
vários anos
Autocontrole Não poder reagir exageradamente a más notícias ou a incômodos
Brainstorming e solução de Ter habilidades muito fortes de brainstorming e solução de problemas
problemas
Gerenciamento de mudanças Ir da gestão de projetos ao gerenciamento de mudanças em toda a corporação
Impacto do gerenciamento Ir dos efeitos da gestão de projetos aos efeitos do gerenciamento de mudanças
de mudanças organizacionais
organizacionais. Pode tan1bém haver um patr ocinado r de p rojeto dos níveis n1ais
sênior da gerência com conheci mentos especia lizados en1 gestão de m udanças orga-
. . .
n1zac1ona1s.
Por a nos, a lguns de nós gerenciamos pro jetos estratégicos sem perceber que está-
vamos fazendo isso e ta lvez não tenhamos reconhecido a possível necessi dade de u1n
estilo de liderança diferente. Porém, à med ida que o uso da gestão de projetos co1neça
a crescer em termos de sua aplicação a projetos de execução de planejamento estraté-
gico, pode1nos precisar realiza r mais pesquisas sobre as habilidades de lidera nça espe-
cíficas que são necessá rias. Estamos apenas dando os primei ros passos em termos de
aplicações de gestão de projetos est ratégica, mas esperamos que essa tendência assu1na
o cont role ao longo da próxima década ou 1nais.
3.2 Hitachi Ltd.

Quando o planejamento est ratégico em gestão de projetos é feito corretamente, o uso
benéfico da gestão de projetos pode permear toda a empresa e ela pode ser integrada
a pratica1nente todas as áreas. Um excelente exe1nplo disso pode ser visto na Hitachi.
Iniciativas de fortalecer a capacidade de gestão

1
de projetos na Hitachi
A formação empresarial do Grupo Hitachi varia amplamente do desenvolvin1ento, pro-
dução, vendas e provisão de soluções para Sistemas de Informação e Telecomunicações,
Sisten1as de Energia, Sistemas de Infraestrutura Social e Instalações Industriais, Materiais
de Alta Funcionalidade, Sistemas Ferroviários, Elevadores e Escadas Rolantes, Produtos e
Con1ponentes Auton1otivos, Máquinas de Construção, Produtos de Mídia Digital e Bens
de Consumo, além de consultorias relacionadas e serviços. Para cada linha de negócios, é
essencial que haja n1elhorias nas tecnologias de engenharia e na gestão de projetos para
servir de suporte à qualidade da empresa. Esse é o contexto para as iniciativas fortalece-
ren1 a capacidade da gestão de projetos para cada linha de negócios.
Do ponto de vista da gestão de projetos, as cinco perspectivas indicadas na Figura
3- 2 são os componentes do suporte necessário para levar um projeto até sua conclu-
são be1n -sucedida.
A perspectiva (1 ) se refere a iniciativas para oferecer u1n treinan1ento contínuo e
eficiente a gerentes de projetos superiores. Con10 o sucesso ou fracasso de um projeto
depende, en1 a lto grau, das capacidades do gerente de projetos, é importante treinar
um pessoa l superior. Para tal, é necessário não somente construir os sistemas educa-
cionais para treinamento do pessoal, mas treiná-los de acordo com suas características
individuais. Em termos das habilidades do gerente de projetos, o Modelo de Desenvol-
vimento de Competências em Gestão de Projetos (PMCDF, Project Managernent Co,n-
petency Develop1nent Framework ) ana lisa a relação entre as características individuais
e o desempenho do gerente de projetos, e ton1a iniciativas para estimu lar o treinan1ento
pessoal potencializando as características individuais dos gerente de projetos (3].
A perspectiva (2) se refere ao suporte à criação de equipes, e visa reduzir a carga
de trabal ho do gerente de projetos e a restringir seu desencaminhamento, criando uma
equipe que realize o trabalho do gerente de projetos. Como mencionado anteriormen-
te, o sucesso ou o fracasso de u1n projeto depende e1n alto grau das capacidades do
gerente de projetos, mas quanto maior sua escala, mais difícil é para um único gerente
de projetos cobrir todas as áreas. Portanto, os projetos precisam ser cobertos co1n as
habi lidades gerenciais de uma equipe de gestão de projetos que inclua não somente o
gerente de p ro jetos, 1nas também um gerente sênior, um PMO, uma equipe compar-
tilhada de tecnologia e uma equipe de desenvolviinento. Há estudos sendo realizados
sobre modelos de avaliação para est ruturas de gerenciamento para aval iar as habili-
dades de gerenciamento como toda uma equipe de gerenciamento, e não so1nente do
ponto de vista das características individuais de um gerente de projetos [4].
A perspectiva (3) visa oferecer suporte aos projetos por n1eio do suporte organ i-
zaciona l da corporação con1 o PMO ou outras organizações avaliando a situação do
projeto, oferecendo consel hos e real izando avaliações do ponto de vista de terceiros. Ao
desenvolver uma co1npreensão externa da situação à medida que o projeto vai progre-
d indo, pode-se identificar riscos que passaram despercebidos por aqueles que estão en-
volvidos de perto. Ao oferecer suporte organizacional e avaliação de riscos não so1nen-
te pela equipe de gerencia1nento, incluindo do gerente do projeto e1n questão, n1as do
ponto de vista de terceiros, a probabil idade de sucesso do projeto pode aun1entar [5].
A perspectiva (4) usa tecnologias, n1etodologias e modelos de suporte para apoiar
as atividades de in1plementação do projeto e o domín io do suporte inclui o gerencia-
mento de riscos, identificação de requisitos, suporte à comunicação, gerenciamento de
1
O material sobre a Hirachi foi fornecido pelo PM Technical Commircee, Hirachi Lrd. €>2013 by Hirachi
Ltd. Reproduzido com permissão.
Elevar a qualidade do gerenciamento Reduzir a carga de trabalho e restringir
por meio da aplicação de metodologia desencaminhamentos realizando o trabalho
e modelos r: - - _ _ _ _ _ do gerente de projetos como uma equipe
1
Aequipe de gerenciamento (2) Gerenciamento por uma e ui e
de erenciamento 1
1
g
Gerente sénior
1
1
1 1
a,
'C
e,
1 "'a,E
CI. (1) Gerenciamento por erentes
= 1 de ro·etos su eriores ·--;;"'
"'a, Equipe do PMO Gerente de
e,
'C projetos 'C
-"'"'e,cn Treinamento eficiente para 1 e

-"'
cn &'
g
gerentes de projetos superiores
-
e,
e
1 1 e
a,
"O
~
o
u
{!!.
1, Equipe compartilhada 1 "'
11 de tecnologia Equipe de desenvolvimento 1 t...
o
1 .,
~
::,
1 &l'
1 (5) Construir ambientes por meio
~
e
3
11 PMO de negócios, PMO de toda a empresa 1
do i t
.,.
o
(3) Gerenciamento organizacional por

rmnt rt ------- -
Dar suporte a projetos por meio do suporte
Estruturas para aumentar a probabilidade
• de sucesso (passagens de fase, etc.) e
ambientes que facilitem a gestão
!
(D>
organizacional da corporação de projetos .,~

Figura 3-2 Componentes do suporte à gestão de projetos. ......
(O
conhecin1entos, suporte ao PMO, entre outros. Em termos de gerencian1ento de riscos,

há iniciativas para oferecer suporte à identificação de riscos e criar contran1edidas e1n
un1a variedade de áreas de negócios (6- 10). Em termos de suporte à identificação de re-
quisitos, a identificação de requisitos para clientes ten1 suporte de pesquisas etnográficas
haseadas en1 processos de design centrado no ser hun1ano e iniciativas como sisten1as de
gerenciamento de construção de edifícios baseado nos resultados (11 ]. Quanto ao suporte
à con1unicação, há iniciativas para identificar problen1as de gerenciamento visualizando a
comunicação sobre o progresso do projeto usando sisten1as de sensores. En1 tern1os de ge-
renciamento de conhecimento, há n1étodos de extração de conhecimentos en1píricos (13)
e técnicas de utilização desses conheciinentos (14, 15) con10 mn sistema de circulação dos
con hecimentos en1píricos obtidos durante projetos em toda a organização. A circu lação
dos conhecin1entos é implementada como ilustrado na Figura 3-3, em colaboração com
design de sistema da perspectiva (5 ). Há também iniciativas de siste1nas de infonnação
para oferecer suporte não somente ao gerente de projetos, n1as tambén1 ao PMO (5).
A perspectiva (5) constrói estruturas para au1nentar a probabilidade de sucesso de
um sistema, sistemas de certificação para gerentes de projetos e est ruturas para gover-
nança de projetos. Uma dessas est ruturas é o uso do Gerenciamento de Passagens de
Fases (uma estrutura que divide o processo do produto em várias fases e erige "pontos
de decisão" para revisar se as condições foram ou não atend idas antes de passar para
a fase seguinte), ilustrado na Figura 3-4, para tomar decisões quanto a continuar ou
suspender projetos (16) . Ao usar o Gerenciamento de Passagens de Fases, é possível
otim izar a to 1nada de decisões de 1nodo a d iminuir o risco, aumenta r a qua lidade do
design e maxiinizar os ganhos da gerência.
Além disso, co1no uma med ida para ligar as perspectivas (1) a (5) organ icamen-
te, e não independentemente, um projeto de 1nelhoria dos negócios chamado D-WBS
(Denryoku \Y/ork Breakdown Structure - Estrutura Analítica do Proieto Denryoku)
está sendo implementado na Power Systems Company [17). O Projeto D-WBS possui
u1na plataforma (a plataforma D-WBS) para extrai r sinergias de negócios relacionadas
à gestão de projetos, como mostra a Figura 3- 5, e constru ir processos de negócios que
unam as perspectivas (1) a (5) na plataforma.
Os co1nponentes de suporte que menciona1nos são exigidos para implementar pro-
jetos sen1 depender das unidades de negócios. Embora cada área de aplicação tenha
suas próprias características, co1nparar e contrastar técnicas de gestão de projetos na
Pov,er Systems Company e na Information & Telecon1munication Systems Company
nos faz perceber que há muitos pontos de referência para a1n bos os lados. Consideran-
do que co1npartilhar e uti lizar o conhecimento de iniciativas para fortalecer a gestão de
projetos nas a1nplamente variadas áreas de negócios do Grupo Hitachi se torna un1a
fonte de excelência con1petitiva pa ra a Hitachi, o comitê técnico interno está criando
oport unidades para esti1nular a troca de infonnações.
Esse con1itê técn ico é chan1ado de Comitê Técnico de Gestão de Projetos e teve iní-
cio co1n d iscussões no nível dos traba lhadores na Power Systems Company e na en1presa
Infonnation & Telecommunication Systen1s em torno do ano 2000. Então, um comitê
técn ico aberto para a empresa inteira foi estabelecido em un1a reun ião de voluntários
em 2005, e hoje 1nuitas unidades de negócios estão participando con1 o foco no PMO. O
Com itê Técnico está promovendo un1a gestão de projetos n1ais forte e1n toda a empresa.
Alén1 da troca de informações, ele oferece suporte a institutos de pesqu isas, investigan-
do estratégicas de solução para problen1as con1uns [18). Por exen1plo, a estrutura para
con1partilhar tarefas de gestão de projetos entre todas as unidades de negócios (19], ou
atividades en1 toda a empresa baseadas en1 iniciativas para usar conhecimentos na Infor-
mation & Telecommunication Systen1s Con1pany (20).
Além de organ izar fóruns internos com o objetivo de treinar os funcioná rios em
gestão de projetos, ou comunica r as atividades do Com itê Técnico a profissionais de
- - - - 1 Passo 1: Extrair conhecimento 1- - - - "" .- - - - -1 Passo 3: Desenvolver a organização 1 - - - - ,
>" Esclarecer sucesso/fracasso em termos gerais >" Aumentar a capacidade de usar integralmente
);:, Análise objetiva, e não subjetiva o conhecimento de sucessos/fracassos
Métodos de Relatórios de situação do projeto

suporte ao uso 1 • - - - - - - - 1
PMO dos conhecimentos
Post mortem
Partes interessadas do projeto (Pós-análise) 1 •
1 1
•
1 1 - Suporte contínuo ao projeto
Técnicas de Escrutinar 1 1 GP (contínuo)
1 1
análise causal conteúdo analítico 1 1
1 1
1- Uso para treinamento de GP
Presença
Análise de
1
1
1
1
1
1
.......... '
no treinamen to Trainee de GP
•
..
o
fracassos 1 1 "D
Programa de treinamento ;::;,
1 1
' -
e
-- ----------------------· -- ·--------------- -------- -------

1 1 o
w
---------
,
1
•
----------------------------------- 1
Captar conhe- Acumular

-l> Com,eica, cooheclme,IOs ,
Iniciativas
t..
....-
o
: :,
a.
:
-
1
1-··-
• cimentos do Gp 1, exemplos (BD
de exemplos) >"
captados e lições aprendidas
a terceiros
Informações para a busca
de conhecimentos
•
: <;
•
:
do PMO
Conteúdo da
-
e:
3
...
o
~
o(1)
1
1 pesquisa ffi;
•- - - - - - - - - - - - Passo 2: Captar conhecimentos ]- -----------· ..
::,
Q.
Nota: Pode-se dar exemplos de sucesso com a mesma estrutura. ......

1\)
PMO: Escritório de gestão de projetos; GP: Gerente de projetos
Figura 3-3 O processo de circulação de conhecimentos empíricos da gestão de projetos em toda a organização.
...
1\)
1\)
G)
(1)
• Atividades diretamente ligadas ao gerenciamento .,,o
!e
• Avaliação e decisão pelos responsáveis pela tomada de decisões
a.
(1) Implementação direta de cima para baixo (1)
"O
Govemança
(2) Nomear um avaliador para cada "ponto de decisão"
de passagem de fase -·ag
(1)
• Gerenciar sistemas
• Sistematizar • Ligação com projetos
• Aprimorar processos importantes • Verificações organizacionais
Pontos de decisão (gates)

Organização/
Processo Estrutura
(6) Organização do gerenciamento e

(3) Revisar, redefinir, estrutura de suporte a projetos
padronizar processos
(4) Reforçar processos antes
• Fornecer informações necessárias
do início do projeto
• Operações do projeto como plataforma
(5) Estabelecer gatewayfinal Infraestrutura (7) Critérios de avaliação / materiais de avaliação
(8) Habilidades e conhecimentos especializados
para operar projetos
Figura 3-4 O processo de gerenciamento de passagens de fase da Hitachi.
./ Fornecer informações adequadas às necessidades ./ Coordenar organicamente as informações do
do usuário (gerente/GP/funcionário encarregado) projeto com base em código D-WBS
./ Gerência capaz de manter a qualidade das (p rod ução/resultado/p rocessos/custo)
informações (precisão, atualização) ./ Melhorar a utilidade das informações
(comparar/analisar/reutilizar, etc.)
Código Sistema de informação D-WBS (exemplo típico) Manual de

D-WBS operação
Identificação D-WBS
Gerenciamento
~ do projeto/ Gerenciamento Gerenciamento
do trabalho
gerenciamento b de engenharia R de aquisições R de construção
de riscos Jc....
Formulário ~
WBS do projeto
À
1
À
1
Proieto de EPC
À
1 ..o
-e
;::;,
•
Pré-projeto Engenharia Aquisições ~ Produção /i Construção :
Manual de -
e
o
Aplicar ao operação w
formulário D-WBS t..
WBS do •
1 1 1
i
1 1 -~
o
: :,
projeto Suporte da gerência para manter a qualidade das informações Regras para a ..-
Código do projeto (precisão, atualização) • 1 1 condução de
e:
3
D-WBS gestão de ...
o
(WBS padrão) v'

-~
i ~!t1 projetos/ !
- negócios ffi;
Organização do gerenciamento: Centro de gerenciamento dos sistemas de GP ..
::,
Q.
Plataforma D-WBS ....

1\)
w
Figura 3- 5 Esboço do Projeto D-WBS.
todo o Grupo Hitachi, o Com itê Técnico também conduz pesquisas periódicas sobre
a conscientização em relação às questões de fortalecimento da gestão de projetos em
cada unidade de negócios.
Dessa manei ra, há iniciativas e1n andamento que pretendem gerar sinergias no
Grupo Hitachi divulgando experiências especial izadas latera lmente em todas as unida-
des de negócios, identificando problemas comuns e estudando est ratégias de solução
por meio das atividades do Comitê Técn ico.
Referências (com resumos, quando disponíveis)

li) Takafumi Kawasaki et ai., " Practice action of project managers: The d ifference between
highly competent PM a nd moderately competent PM", Proceedi11gs o( 13th Natio11al Co11-
(ere11ce o(The Society o( Project Ma11ageme11t, 2007, 373- 3n, 2007-03-15
(http://ci.nii .ac.j p/naid/110007602 74 7).
Os conhecimentos e habilidades q ue os gerentes de projetos convencionalmente possuem
foram focalizados a fim de explicar desempenhos bem-sucedidos. No entanto, situações
extremamente complexas exigem que gerente de projetos profissionais criem práticas
adaptativas e úteis. Essa prática é conhecida como "knowi11g" (saber, conhecimento), isto
é, criar novos conhecimentos e ações adaptativas. Este estudo a nalisou ações de gerentes
de p rojetos superiores e de gerente de projetos menos superiores e explico u as diferenças
em termos da promoção do coconhecimento dos membros da equipe.
[2) Hitosh i Yamadera et ai. " Relations between Ach ievement and Characteristics of Project
Managers", Proceedi11gs o( 16th Natio11al Co11(ere11ce o(The Society o( Project Ma11age-
me11t, 2009, 209- 212, 2009-03-10
(http://ci.nii .ac.j p/naid/110007602894).
Este estudo investigou as relações entre as conq uistas de gerente de projetos e sua per-
sonalidade, atitude profissional e tipo de a tividade do projeto. Os resultados mostraram
q ue ser extrovertido, estar consciente de problemas e d isposto a aprender com os outros
estavam relacionados ao sucesso. Em relação às a tividades do projeto, foram identifi-
cados cinco t ipos de competência necessários para q ue um gerente apresente um nível
normal de contribuição. Embora eles contribuíssem integralmente com seus projetos, foi
revelado q ue os maiores contribuidores ajustavam de forma consciente seu comporta-
mento para um nível ma is a lto, de modo a promover a evolução o rganizacional.
[3) Takeshi Yokota et a i., ;'Strengthening of Personnel Training Process of Project Managers",
fo11r11al o( the Society o( Project Ma11ageme111 15(2), 2013-04-15.
Para aumentar a taxa de sucessos dos projetos de construção, estamos desenvolvendo um
processo de treinamento de pessoal para gerentes de projetos. Desenvolvemos o método
q ue avalia quantitativamente as características de gerente de projetos. Esse método possui
uma base de dados que consiste em respostas de em torno de 200 itens de um questio-
nário. Ele avalia as características do gerente de projetos a partir de alguns pontos de
vista (experiência em projetos, traços comportamentais, conhecimento, etc.). Esse método
define a pontuação-alvo do trabalho com gestão de projetos e, por meio da comparação
das características do gerente de projetos com a pontuação-a lvo, esclare.ce seus pontos
fortes e fracos para fins de treinamento. Além disso, oferecemos suporte à organização da
formação de projetos por meio da avaliação de um resultado de comparações.
[4) Ak iyuki Onaka, "Model of Project Team Assessment to Make Projects Succeed", Pro-
MAC2010, 2010.
Q uanto aos gerentes de projetos dos projetos de sistema de TI em nossa empresa, s ua
capacidade de gerenciamento é ava liada e sua classificação de GP, dividida entre "pe-
quena", "média,, e "grande", de acordo com o tamanho do projeto, é certificada com
base em nossos próprios critérios do "sistema de acreditação de gerente de projetos". Os
gerentes de projetos certificados são in dicados a um projeto cujo tamanho corresponde à

sua classificação de GP segundo o ;'sistema de nomeação de gerentes de projetos".
Alguns projetos, especia lmente os de grande porte, d eram errado apesa r de os geren-
tes de projetos terem qualificação adequada segundo os sistemas recém-mencionad os.
Esse fato nos fez inferir a importância dos compo rtamentos de membros de projeto,
especialmente aqueles que se esperavam ajudar os gerentes de projetos. Os membros a
serem considerados são, por exemplo, aqueles que reduzem a carga que recai sobre o ge-
rente e a queles q ue supervisionam e aconselha m os gerentes de projetos. Entretanto, nos-
sa discussão insuficiente sobre q ue pontos de vista dificultavava a avaliação de equipes
de projetos, incluindo membros de apoio, da mesma forma q ue avaliávamos os gerente
de projetos. A fim de melhorar essas situações, analisamos d ados de projetos anterio res
para concluir como o rganizar um a equipe. Baseados na conclusão, c riamos um modelo
de avaliação para equipes de gestão de projetos que levam em co nsideração o tamanho
do projeto e o tipo de desenvolvimento. Este artigo descreve os resultados de nossa pes-
quisa sobre o modelo de avaliação de equipes de gestão de projetos.
[5] Kenji Hatsuda et a i., "PMO Information System as a Support o f Project Management Office
Activities" ,]01tr11al o( the Society o( Project 1'Aa11ageme111 5(4), 28- 31, 2003 -08-15
{http://ci.nii.ac.jp/naid/ 110003 726282).
De acordo com o a umento do reconhecimento da importância da gestão de projetos, o
PMO também passou a desempenha r papéis importantes, como a promoção da organização
da gestão de projetos. A gestão de projetos precisa ser a tarefa a ser estrategicamente pro-
movida e sistematicamente implementada pelo PNIO. Os papéis do PMO são desenvolvi-
mentos de uma base comum, como os procedimentos de gestão de projetos, treinamento de
pessoal e desenvolvimentos técnicos, além dos suportes aos projetos entre as organizações.
É eficiente construir o sistema de informação do PMO, que oferece suporte às a tividades do
PMO. Este a rtigo se focaliza nas atividades baseadas em PNIOs práticos, e considera o de-
senvolvimento, a utilização e os efeitos esperados do sistema de informação do PMO como
um suporte ao PMO.
[6] Nlinamino, Toyama, "An Application of Modem Project Management;'IT" System Develop-
ment Projects", ProMAC2002, 2002.
Nos últimos anos, cada projeto de desenvolvimento de s istema d e TI se diversificou e
se co mplico u, e é necessária sua exploração no curto prazo. Além disso, mudanças nas
solicitações durante o desenvolvimento também a umentaram. Os projetos de sistemas de
TI possuem características q ue fazem co m que nenhuma imagem do sistema possa ser
observada co mo uma forma concreta diretamente, nem durante nem depois do desenvol-
vimento. Os a utores tentaram a aplicação da gestão de projetos moderna, especialmente
para gestão de riscos e gerenciamento de escopo em tais projetos de desenvolvimento de
sistemas. Eles fornecem alguns exemplos da a plicação da gestão de projetos moderna
aos projetos de desenvolvimento de sistemas de TI e descrevem aspectos futuros sobre a
aplicação do modelo de gestão de projetos.
[7] Ta keshi Yoko ta et a i., "Development of a Contract Ris k Assessment Support System (C RA-
RIS)" , ]01tn1al o( the Society o( Project. 1'Aa11age,ne11/ 7(3), 20- 25, 2005-06-15
{http://ci.nii.ac.jp/naid/ 110003 726628) .
Examinou-se um processo de negócios necessário para oferecer suporte à avaliação de riscos
de contratos em projetos no exterior e desenvolveu-se o sistema de suporte a avaliações de
riscos de contrato (CRARJS), que era um sistema de gerenciamento de conhecimento relati-
vo ao gerenciamento de riscos de contrato. O CRARIS se baseia em uma lista de verificação
feita em uma seção de casos jurídicos, e caracteriza-se como uma apresentação de in forma-
ções de know-how que relacionam cada item listado a uma avaliação a utomática de riscos
de acordo com o conteúdo da lista de verificação. Além disso, em torno de 2000 [itens de]
informações de know-ho,u foram extraídos de conversas sobre os resultados de especialistas
em uma divisão de operações e da seção de casos jurídicos, as minutas de avaliação dos pro-
jetos propriamente ditos, entre outros. Foram também executados um exame de processos
de negócios e uma estrutura organizacional eficiente para avaliar o contrato.
[8) Takeshi Yokota et ai., 'Tievelopment of a Risk Management System for Construction Pro-
jects", fournal o( the Society o( Project Ma11ageme11t 8(5), 36-41, 2006-10-15
A fim de oferecer suporte ao gerenciamento de riscos de um projeto de construção, de-
senvolvemos o sistema q ue usa a tecnologia de simulação de progresso e que suporta a
ava liação do problema de um projeto e a decisão de contramedidas para o problema.
Esse sistema caracteriza-se por ter uma lógica de sim ulação da avaliação de p rogressos
q ue avalia o progresso detalhado de cada trabalho de um projeto seria lmente, por sema-
na . Além d isso, tem também a capacidade de levar em consideração situações como a
mudança da eficiência de trabalho, e a umenta o número de trabalhadores, na lógica de
simulação. Esse sistema foi avaliado usando os dados de um projeto real, e a validade do
resultado da avaliação do projeto foi verificada usando as várias funções de um sistema.
[9) Takesh i Yokota et a i., "Upgrade of Risk Management Technique for IT System Develop-
ment Project" ,fo11r11al o( the Society o( Project Ma11age111e111 14(3), 25- 30, 2012-06-15
(http://ci.nii .ac.j p/naid/11000949 54 77).
Para oferecer s uporte à introdução eficiente de sistemas de TI, construímos um sistema
de suporte à aná lise de justificari,,as de negócios para o desenvolvimento de sistemas
de TI. Ele avalia os benefícios dos sistemas, efeitos de investimento, fatores de risco e a
justificativa dos sistemas de desenvolvimento. Usando essas informações, ele esclarece
a adeq uação e o nível de prioridade do investimento de desenvolvimento, e oferece
s uporte ao processo de gerenciamento de riscos da fase de desenvolvimento. Para es-
clarecer características de projetos com mais precisão, classificamos a pontuação de
risco considerando se os gerente de projetos podiam gerenciá-lo o u não. Ao aplicá-la
a projetos rea is, verificamos que essa técnica de classificação de risco é eficiente para a
[10) Yosh inobu Uchida, ;'Development of the Risk Management System for Construction Pro-
jects", ProMAC2011, 2011.
Para oferecer suporte a projetos de construção, desenvolvemos um sistema de gerencia-
mento de riscos q ue identifica os riscos de um projeto e suporta decisões sobre contra-
medidas a eles. O sistema de gerenciamento de riscos possui um sistema de avaliação de
projetos, um registro de riscos e um porta l da web de gerenciamento de riscos. O sistema
de avaliação de projetos fornece uma lista de verificação adeq uada para um projeto e
suporta a avaliação de projeto. O registro de riscos fornece a planil ha e s uporta a iden-
tificação de riscos de projeto e o desenvolvimento de um planejamento de respostas. O
portal da ,veb de gerenciamento de riscos visualiza os resultados de avaliações por meio
do sistema de avaliação de projetos. Neste artigo, relatamos cada subsistema do sistema
de gerenciamento de riscos.
[ 11) Hisako Okada et a i., "An Approach to Advance Construction Management System for Lar-
gesca le Power Plant Projects",fournal o( the Society o( Project lvfa11ageme11t 15(1), 8- 13,
2013-02-15.
Projetos de construção de usinas de geração de energia são projetos complexos e de
grande escala, q ue envolvem mu itas partes interessadas. Para garantir a "q ualidade, os
prazos e os custos " desse enorme projeto, a Hitachi aplicou um sistema de TI à área
de construção. Seu ponto focal é ( I) a realização de um enorme controle consistente e
coordenado de projetos e (2) a realização de eficiência e q ua lidade crescentes da área de
construção, para reduzir riscos e custos. A partir da década de 1990, ele foi aplicado a
projetos reais e a lcançou certo efeito, mas novas melhorias estavam chegando ao lim ite
na abordagem centrada no gerenciamento e em sistemas. Logo, ao reconsiderar a ideia
fundamental de que "A construção é uma produção humana ", a Hitachi passou a con-
d uzir pesquisas em sistemas de gerenciamento de construções baseados na Abordagem
Centrada no Ser Humano, que se focaliza no usuário/lado humano, e conduziu pesqu isas
q ue refletem os resultados da gestão de projetos propriamente dita .
[12] Hideyuki Maeda et a i., "Visualization of Comm unication using the Team Activity Nlea-
suring System and lts Application to the Project Management", journal o( the Society o(
Project Ma11ageme11t 12(1), 5-10, 2010-02-15
{http://ci.nii.ac.jp/naid/110007 573280).
Com o avanço de tecnologias de sensor e de análise, desenvolveu-se um sistema q ue pode
automaticamente medir e visualizar a atividade de uma equipe. Aplicamos esse sistema a
um projeto de grande escala e medimos e analisamos experimentalmente as cond ições de
uma comunicação dentro dele. Como resultado, tivemos êxito em quantificar e visuali-
zar as condições das comunicações de um projeto. A análise q uantita tiva mostra q ue há
uma forte relação entre a prod utividade e o tempo gasto com comunicação face a face.
Ao monitorar continuamente o tempo desse tipo de comunicação, conseguimos ajudar a
expor os problemas de um projeto em uma fase inicia l. Isso nos ajudou a oferecer infor-
mações úteis ao gerente de projetos para solucionar esse problema exposto .
[13] Yosh inobu Uch ida et a i., "An approach of kn owledge extraction via empirical fail ure know-
ledge in project management" ,}01tr11al o( the Society o( Projeá Ma11ageme11t 12(4 ), 27- 32,
2010-08-15
{http:l/ci.nii.ac.jp/naid/110007880184 ).
Uma forma de tornar um projeto bem-sucedido é [ter] uma compreensão da essência de
experiências passadas. Para desenvolver um esquema para aprender com experiências
passadas, é importante acumular [os] valiosos conhecimentos da organização. Os co-
nhecimentos são extraídos por meio de análise e interpretação depois de as in formações
obtidas com a experiência serem mais uma vez ordenadas. No entanto, é difícil deduzir
conhecimentos objetivos e lucrativos de acordo com os seguintes fatores de obstrução.
( 1) É feita uma análise baseada em uma consciência superficial dos fatos ou em uma
consciência situacional local. (2) A consideração de ;'jogo de empurra ". Para solucionar
[esses] problemas, desenvolvemos um método analítico causal que inclui a visualização
da sequência de decisões para servir de suporte à extração de conhecimentos e um for-
mulário definido para compreender os conhecimentos. Avaliamos o método analítico e
o formulário de conhecimentos e mostramos a eficiência da extração de conhecimentos.
[14] Yoshinobu Uchida et a i., "Proposal for Risk Management Support Method Using Failure
Knowledge", jour11a/ o( the Society o( Project Ma11ageme11t 7 (6), 3-8, 2005-12-15
{http:l/ci.nii.ac.jp/naid/1100062783 74 ).
O fracasso de projetos influencia muito o desempenho corporativo. Muitas empresas de SI
precisam reconstruir a gestão de projetos. Trabalhamos na eliminação do projeto deficiente
e estamos pesquisando o método para usar os conhecimentos derivados do fracasso em
gestão de projetos com o objeti,•o de evitar que o mesmo fracasso se repita. Neste artigo, de-
finimos "Informações sobre riscos nos processos" (PIR, process in(ormation for risk), como
informações sobre riscos no processo correspondente, e propomos o método de usar in for-
mações no processo de gestão de projetos. As vantagens de nossa proposta são as seguin-
tes: (1) as PIR são extraídas do relatório periódico automaticamente. (2) Um caso passado
similar é apresentado como um caso de fracasso. (3) O membro do projeto delibera [sobre]
medidas baseadas no caso de fracasso. Acreditamos que nossa proposta possa suporta r [e,•i-
tar] que o projeto fracasse [devido à] mesma causa.
[15] Yoshinobu Uchida et a i. "Proposal of utilization of the failure experience in project mana-
gement", Proceedings o( 15h Natio11al Co11(ere11ce o(The Society o( Project Ma11ageme111,
2008, 140-143, 2008-03-14
(http://ci.nii.ac.jp/naid/ 110007 602790) .
Compreender a essência da experiência de fracasso e aprender lições com a experiência
de fracasso é importante para se criar conhecimento. Acreditamos que nossa organização
possa fortalecer a gestão de projetos aprendendo com experiências de fracasso de projetos
passados e compartilhando preceitos na organização. Para aprender com experiências de
fracasso, devemos utiliza r a experiência de fracasso em gestão de projetos.
Nossa abordagem supõe a atividade de avaliação pelo escritó rio de gestão de pro-
jetos em um projeto contínuo. Pesquisamos sobre as atividades de ava liação atua is e
descobrimos os seguintes problemas:
1. Como [os assessores] devem compreender a situação do projeto? Nem todo assessor
tem capacidade de esclarecer todos os aspectos do projeto. Geralmente um assessor não
possui informações suficientes para verificar a eficiência de uma contramedida.
2. Como [os assessores) devem encontrar as informações de que o gerente de projetos
precisa no projeto?
Para solucionar [esses] problemas, definimos um formato para descrever a situação
do projeto e a estratégica de busca das informações de q ue o gerente de projetos precisa.
[16) Koji Okada et a i., "Applying Phase-Gate Management for Diverse BusinessTypes",]ournal
o( the Society o( Project Manageme11t 13 (6), 29- 34, 2011-12-15
A concorrência global foi se tornando cada vez mais d ifícil em todos os domínios de
negócios. A fim de eli minar projetos não lucrativos e aumenta r os lucros sob ta l situação,
estabelecemos uma iniciativa corporativa para implementar o gerenciamento de passa-
gens de fases, q ue produziu res ultados bem-suced idos na unidade de negócios principa l
e em todas as unidades de negócios, de maneira mais ampla. À primeira vista, o conceito
do "Gerenciamento de passagens de fases da Hitachi ", q ue é aplicável a diversos tipos
de empresas, foi esclarecido. Os possibilitadores fundamentais em comum, como ( 1)
guias de operação, (2) materia is de treinamento, (3) modelo de maturidade de passagem
de fase, (4) um guia de determinação de KPls e (5) o compartilhamento de conteúdos de
conhecimento são desenvolvidos/estabelecidos e providos de maneira ampla. Além disso,
dez unidades de negócio modelo foram selecionadas e receberam suporte tanto no desen-
volvimento de seus planos de ação de aperfeiçoamento do gerenciamento de passagens
de fases quanto na s ua realização. De acordo com os resultados, foram demonstradas
melh orias tanto nos níveis de maturidade das passagens de fases quanto em alguns KPls
de todas as unidades de negócios modelo selecionadas.
[17] Tomoyuki Aoki et a i., ;'The Case Study of Business Process Reengineering for EPC Project
Management", journal o( the Society o( Project Ma11ageme11t 14 (6), 5-10, 2012-12-15.
Na Hitachi Power Systems Company, o projeto de reengenharia de processos de negó-
cios BPR (Business Process Reengineering) chamado de "projeto D-WBS" foi iniciado
e m 2009, e estamos conduzindo a primeira fase desse projeto para ser concluída em
2013. No projeto 0-\'ilBS, gostaríamos de alcança r a melhoria da ca pacidade de ges-
tão de projetos por meio do desenvolvimento de uma plataforma-padrão de gestão que
[pode ser] usada entre nossos segmentos de negócios. O objetivo dessa plataforma é
um projeto de engenharia, aquisição e construção (EPC, E11gi11eering, Proc.urement and
Co11slr11ction) que construa uma usina de energia elétrica e sistemas médicos avançados.
Neste artigo, primeiramente apresenta mos um histórico e um panorama do proje-
to D-WBS. Então, explicamos nossa plataforma de gestão de projetos que consiste em
q uatro domínios: um sistema de código WBS, um sistema de TI, um padrão operaciona l
e um departa mento operacional. Explicamos também a metodologia do código 0-\'ilBS
para o planejamento do projeto EPC. Finalmente, gostaríamos de compartilhar nossa
abordagem de BPR.
[18] Kichie Matsuzaki, " Hitachi, Ltd. 100th Anniversa ry Series: Genealogy of the Pioneers (20)
lnheriting and Reforming the Heart of Monozukuri at Hitachi - Companywide Activit ies
toward Monozukuri", Hitachi Review 92(2), 136-143, 2010-02
(http://d igital.hitachihyoron.com/pd f/2010/02/2 O10_ 02_pioneers.pd f).
[19] Koji Okada et a i., "Challenge for Extracting Project Management Knowledge across
Business Units" , ]01,r11al o( the Society o( Project. Managemenl 10(3), 23- 28, 2008-06-15
(http://ci.nii .ac.j p/na id/110006950594).
A fim de evitar problemas com o projeto ou de repetir seus sucessos, as empresas têm de-
senvolvidos seus próprios Sistemas de Gerenciamento da Q ualidade (QMS, Qua/ity Ma-
11age,ne11t System) para a gestão de projetos. Embora essas atividades de aprimoramento
sejam rea lizadas em unidades de negócios individuais, os conhecimentos obtidos não
são compartilhados entre as diversas unidades de negócios. Neste artigo, descrevemos
a metodologia para extra ir e organizar os conhecimentos da gestão de projetos, o que
é desenvolvido por meio da sua prática real de extração e organ ização. Especialmente,
criamos conceitos fundamentais baseados em fato em com um, d iferenças e especia li-
dades. Além d isso, desenvolvemos uma ;'plan il ha de extração de conhecimentos ", uma
"planilh a de descrição de conhecimentos" e um "mapa de conhecimentos" como ferra-
mentas de suporte, além de um procedimento para extrair e organ izar conhecimentos,
por meio de três ciclos de prática real.
[20] Koji Okada et a i., "An Analysis Method for Extracting Project l essons learned wh ich are
Sharable across Business Un its",/011r11a/ o/ the Society o( Project Ma11ageme11t 12(6), 21-
26, 2010-12-15
(http:l/ci.nii.ac.jp/naid/11000859292 7) .
Desejam-se melhorias nas atividades de gestão de projetos em todos os dom ín ios de
negócios. Compartilhar as lições aprendidas com os projetos entre todas as unidades de
negócios pode ser uma maneira eficiente de melhorar as atividades de gestão de projetos
em uma empresa composta por várias un idades. A fim de compartilhar as lições aprendi-
das com projetos entre as unidades de negócios, levantamos 31 casos de fracasso em pro-
jetos de oito delas, reanalisamo-os e compilamos 50 lições aprend idas compartil háveis.
Além d isso, criamos um método de aná lise para extrair de projetos lições aprendidas
compartilháveis que reflitam a análise do know-how obtido a partir de ativ idades de
reanálise que foram de fato realizadas.
2
3.3 KONE: o desafio da gestão de projetos
O desafio do crescimento
O sucesso da KONE nos mercados de projetos de arranha-céus e projetos maiores des-
de o início da década de 2000 baseou-se em grandes inovações técnicas e 1na ior foco
corporativo e1n projetos maiores. A KONE estava investindo 1nu ito e1n competências
de vendas e de engen haria de vendas, utilizando nossa forte cadeia de suprimentos
global para entregas.
O que acompanha naturalmente um forte desempenho de venda é a necessidade
de uma fo rte execução. Esses novos mercados e projetos eram mais exigentes, e os
cl ientes tin ha expectativas diferentes do que antes. O negócio e seus cl ientes estava1n
empregando gerente de projetos profissiona is para realizar o tr aba lho, e precisavam
do mesmo de nós. Isso foi percebido em 2008, ao ana lisa r nosso desenvolvimento de
rentabil idade de projetos - estáva1nos perdendo nossa margem!
Isso ocorreu pelos seguintes motivos:
• Ausência de uma estr utu ra-padrão de gestão de projetos
• Inexistência de um padrão glo ba l para a função e a responsabil idade de um ge-
rente de projetos
• A gestão de projetos não era vista como u1na carreira desejada ou legítima
• A gestão de projetos entrava no processo de entrega tarde de1nais
2
©2013 by KONE. Reproduzido com permissão. Todos os direitos reserYados. O material sobre a KONE
foi fornecido por Sreve Gonzalez., diretor de projetos maiores, e Jyri Toiviain.en, diretor, desenvolvimento de
competência em GP, suporte à gestão de projetos de projetos maiores.
• Ausência de sistema para identificar, recruta r, desenvolver e reter gerentes de pro-

Jetos
• O gerenciamento de um projeto era realizado por uma pessoa sem as devidas qua-
lificações do modo que fosse conveniente
Ne1n tudo era ruim. Havia a lguns gerentes de projetos muito bons na empresa.
Cada um deles tinha desenvolvido suas próprias ferra 1nentas e sistemas para gerenciar
o tra ba lho, contr atos e clientes. Comparando o trabal ho dessas pessoas com o dos
outr os, ficava cla ro que o resultado médio em margem de projeto ("vendido" vers11s
"entregue") dependia 1nuito da competência do gerente de projetos.
• Projetos com GPs treinados e experientes + 1,5 pontos
• Projetos com GPs sem t reinamento - 4,3 pontos
Havia dois problemas. O primei ro era a falta de previsibilidade do negócio. O
segundo, a grande variaç.ã o entre o mel hor e o pior. Com nosso atraso e nossas aspira-
ções, precisávamos agir com rapidez. Começar de novo estava fo ra de cogitação. Em
vez disso, aprenderíamos com o passado e garantiríamos o futuro.
Imperativos em termos de desenvolvimento de competências

em gestão de projetos - 2009
Para conseguir obter alguns resultados mensuráveis e1n um período dado de seis me-
ses, determina1nos cinco imperativos para o desenvolvimento de nossa gestão de pro-
jetos (ver Tabela 3-5):
1. Ter uma avaliação das habilidades de gestão de projeto en1 vigor e funcio-
nando
2. Estabelecer um programa de treinamento e fazer um teste piloto desse pro-
grama durante 2009
TABELA 3-5 Desenvolvimento de competências de GP - ações e métricas

Imperativos Objetivos Mensurações
Avaliação de habili· • Avaliação sistemática e contínua de GPs segundo • Avaliação própria e por supe-
dades de gestão de os padrões de competência definidos pela KONE riores realizada como parte do
projetos programa anual PD/IDP
Programa de treina- • Estabeledmento de um programa de treinamento • Planos de desenvolvimento exis-
mento em gestão de de GPs tentes em Ft:s
projetos • Realização de um treinamento piloto durante 2009 • Satisfação do diente (NPI)
• Implementação de aprendizados em operações • Projeto CMII (Configuration Ma-
cotidianas de projetos nagement li)
Rede de gestão de • Todo gerente de projetos possui uma rede conhe- • Redes de contatos comunicados
projetos cida que ofereça suporte a ele • Uso de redes de contato
• Estabelecimento de uma rede de profissionais de
projeto na KONE
Auditoria de projetos • Ter um mínimo de dois projetos auditorados em • Melhores práticas compartilhadas
cada área • Lacuna de competência identi-
• Compartilhamento de melhores práticas entre pro- ficada
jetos e países (FL) • Riscos de projeto identificados
Revisões de projeto • Comprometimento da gerência de área/FL com o • Revisões de projeto estabele-
(e orientação doca- programa cidas
minho a ser tomado) • Ter revisões de projeto funcionando em empresas
FL selecionadas
3. Estabelecer uma rede de gestão de projetos na KONE

4. Co1neçar o projeto de auditoria periódica
5. Ter revisões de projetos sendo real izadas globalmente
Compartilhe as melhores práticas em gestão de projetos existentes

na KONE
Com base no portfól io do projeto e em aná lise de rentabi lidade, entrevistas globais,
aval iações de habilidades e o período de tempo disponível (seis meses), decid imos
continuar com uma abordagem muito funcional, co1npartilhamos as "melhores práti-
cas" que já temos na gestão de projetos da empresa.
Usando áreas de conhecimento de gestão de projetos que são padrão no setor,
levantamos as práticas da KONE ma is conhecidas globa lmente em cada d isciplina.
Finalmente, 1nonta1nos uma coleção de práticas comprovada1nente bem-sucedidas e1n
áreas de foco selecionadas em gestão de projetos na KONE.
Gerentes de projetos bem-sucedidos min istraram os treina1nentos. Então, a abor-
dage1n a e.ada tópico era muito prática - gerente de projetos discutindo com outros ge-
rente de projetos maneiras produtivas de gerenciar os projetos. Isso promoveu dois be-
nefícios distintos. Em primeiro lugar, ajudou os gerente de projetos a co1npreendere1n
que eles não estavam sozinhos em suas carreiras. Em segundo lugar, garantiu que tudo
que fosse ensinado poderia ser aplicado imed iatamente nas empresas individuais ao
redor do mundo. Para garantir que os gerentes de projetos compreendesse1n tambétn
a estr utura de suporte disponível, outros especialistas corporativos de diferentes áreas
foram convidados a comparti lhar seu conhecimento.
Torne a experiência eficiente e excelente - use parceiros profissionais

Quando os instrutores que estão con1parti lhando suas experiências não são profissionais,
o desafio é manter o treinan1ento estruturado co1n um conteúdo claro e objetivos de
aprendizagen1 direcionados aos objetivos-chave que precisam ser alcanç.ados na prática.
"Que mudanças cada gerente de projetos imple1nentará na forma com que eles
gerenciam seus projetos hoje (metas, 1ned idas e ações)?"
Para fazer isso acontecer com sucesso, selecionamos u1na e1npresa profissional
para estruturar o conteúdo do treinamento junto conosco. Planejamos ta1nbém a
abordagem do treina1nento com eles, de modo a incluir dois workshops presenciais
que agem como suporte para as sessões virtuais e uma "orientação prática no projeto".
Para fazer isso acontecer na prática, fora 1n definidos os seguintes ele1nentos-chave:
• Slides de sessão
• Slides para atividades de sessão
• Gu ias do instr utor
• Melhores práticas identificadas para cada tópico
• Objetivos-chave para e.ada tópico
• Formulário de planejamento de ação individual (regist ro do aprendizado, planos
de ação)
• Modelos claros, expansíveis e repetíveis de orientação
• Planeja1nento da orientação e estrutura de comun icação
• Manua l de gestão de projetos
Na prática, os workshops de treinamento incluíam uma expl icação do tópico co1n
muitas atividades em grupo e u1na discussão co1n o grupo todo - todos eram encora-
jados a participar.
Com essa abordagem, estávamos não somente comparti lhando as melhores práti-
cas do instr utor para os "alunos", mas também estávamos levantando e comparti lhan-
do as mel hores práticas de cada participante do grupo.
Com base na d iscussão, todos têm a chance de atual izar seu p lano de ação indivi-
dual pa ra orientação e implementação de 1nelhores práticas no dia a dia de seu traba-
lho. Estabeleceu-se o Programa de Desenvolvimento de Gestão de Projetos da KONE
(PMDP, Proiect Management Development Progratn).
Fatores-chave de sucesso
Compreender o desafio - Claro, alvo comum
Pa ixão e motivação entre os 1nembros da equipe
Equipe excelente - GPs de área + especialistas - Vencendo juntos
Alvos desafiadores e tetnpo lim itado - é necessário u1na abordagem inovadora
Abordage1n prática para implementação rápida
Foco nos principa is tópicos - não tentar fazer tudo de uma vez só
Usar parceiros competentes
Divertir-se!
Real izações
Ma ior conscientização e1n relação à gestão de projetos na KONE
Aumento significativo da rentabil idade
Ma ior satisfação do cliente
Compreender o que é a gestão de projetos no a 1nbiente de negócios da KONE
Base a partir da qual desenvolver a gestão de projetos
Ser um parceiro profissional em negócios exigentes e crescentes para nossos clientes
3.4 A luz no fim do túnel

A maioria das pessoas parece acred itar que a luz no fim do túnel é a criação de uma
metodologia de gestão de projetos para a empresa que seja imed iatamente aceita em
toda a o rganização e sirva de suporte à necessidade de sobrevivência da empresa. Na
verdade, o objetivo deve ser alcançar a excelência em gestão de projetos, e a metodo-
logia é o direcionador dessa excelência. Segundo um porta-voz da AT &T, a excelência
pode ser definida como:
Uma metodo logia de gestão de projeto consistente apl icada a todos os projetos de toda a
organização, o reconhecimento continuado por nossos clientes e alta satisfação do cl iente.
Além d isso, nossa excelência em gestão de projetos é um fator-chave para nossas eq ui pes
d e venda. Isso resulta em negócios de repetição com nossos clientes. Além d isso, existe
um reconhecimento interno de que a gestão de projetos agrega valo r e é uma necessidade
absoluta.
Embora possa haver certo mérito nessa crença de que a excelência começa com a
criação de u1na metodologia, há outros elementos que devem ser considerados, co1no
mostra a Figura 3-6. Começando no alto do triângu lo, a a lta gerência precisa ter uma
clara visão de como a gestão de projetos irá beneficia r a organização. As duas visões
mais comuns são que a implementação da gestão de projetos t rará u1na vantagem
competitiva sustentada para a empresa ou que ela será vista internamente como uma
competência estratégica.
Uma vez que a visão tenha sido percebida, o passo seguinte é criar uma declaração
de missão, acompanhada por objetivos de longo e curto prazo que claramente arti-
culam a necessidade da gestão de projetos. Co1no exemplo, veja a Figura 3-7. Nesse
exe1nplo, uma empresa pode desejar ser reconhecida por seus cl ientes como um prove-
dor de soluções, e não como u1n fornecedor de produtos e serviços. Portanto, a missão
pode ser desenvolver uma metodologia de gestão de projetos empresarial apoiada pelo
Formulação
de estratégias
Objetivos de alto nível
Implementação usando
um escritório de
gestão de
projetos
Figura 3-6 Gestão de projetos empresarial.
PRODUTOS/SERVIÇOS
SOLUÇÕES
COMPETÊNCIA ESTRATÊGICA
VANTAGEM COMPETITIVA
Figura 3- 7 Identificando a missão.
cliente que forneça um fluxo contínuo de soluções bem-sucedidas para os clientes, na

qua l os clientes tratem a contratada como um parceiro estratégico, e não como apenas
mais um fornecedor. A necessidade da 1netodologia de gestão de projetos empresarial
pode aparecer no enunciado tanto da declaração da visão quanto da declaração da
mtssao.
As declarações de missão podem ser desdobradas em objetivos de curto e longo
prazo. Por exemplo, cotno vimos na Figura 3- 8, os objetivos podetn começar com o
estabeleci tnento de métricas, a partir das qua is podemos identificar os FCSs (fatores
críticos de sucesso) e os KP!s (indicadores-chave de sucesso). O foco dos FCSs é sobre
as mét ricas de satisfação do cliente quanto ao produto, serviço ou solução. Os KP!s
são 1nedidas internas de sucesso no uso da metodologia. Os FCSs e KP!s são os dire-
cionadores para que a gestão de projetos se torne uma competência estratégica e u1na
vantagem competitiva. Observe tambétn na Figura 3- 8 que os FCSs e os KP!s podetn
se basear nas melhores práticas.
Os três níveis 1nais altos do triângulo da Figura 3- 2 representam o design da estra-
tégia de gestão de projetos. Os quat ro níveis ma is baixos envolvem a execução da es-
tratégia, cotneçando com os elementos fundamentais. Os elementos fundamentais são
os fatores de longo e curto prazo que devem ser considerados, talvez até mesmo antes
PRODUTOS/SERVIÇOS
Trabalho fundamental
e melhores práticas =:::::::~ (FCSs)
com foco externo
SOLUÇÕES
Melhores práticas
e biblioteca de (KPls)
melhores práticas
com foco interno
COMPETÊNCIA ESTRATÉGICA
Figura 3-8 Identificando as métricas.
TABELA 3-6 Elementos fundamentais
Longo prazo Curto prazo

Missão Processos primários e secundários
Resultados Metodologia
Logística Implementação da globalização
Estrutura Desenvolvimento de caso de negócios
Responsabilidade Ferramentas
Direção Infraestrutura
Confiança
Trabalho de equipe
Cultura
de começar o desenvolvimento de u1na metodologia de gestão de projetos empresarial

(Tabela 3-6). E1nbora seja discutível que fatores são os 1na is Ílnportantes, as empresas
parecem ter acelerado até a excelência em gestão de projetos quando questões cultu-
rais são abordadas primeiro.
Para alcançar a excelência em gestão de projetos, primeiro há que se compreender
as forças direcionadoras que determinam a necessidade de excelência. U1na vez que as
forças seja1n identificadas, é essencial ser capaz de identificar os problemas e obstácu-
los potencia is que podem impedir o sucesso da implementação da gestão de projetos.
No decorrer desse processo, o envolvi1nento executivo é essencial. Nas seções a seguir,
essas questões serão discutidas.
3
3.5 Goodyear
Quando as empresas embarcan1 em un1a jornada rumo à excelência em gestão de pro-
jetos, elas nonnaln1ente estabelece1n un1 escritório global de gestão de projetos a fi1n de
3
© 2013 by Goodyear. Reproduz.ido com permissão. Todos os direitos reservados. O material sobre a
Goodyear foi fornecido por Sherry Neuberr, VP do escritório global de gesrão de projetos; Andy \Veimer, Sr.
gerente do escritório de gestão de projetos da RDE&Q; Jayne Cole, gerente de competências empresariais
do escritório global de gestão de projetos; Alexis Rizopulos, gerente da seção de gestão do conhecimemo do
escritório global de gestão de projetos; e John Renner, gerente de projetos do escritório de gestão de projetos
da RDE&Q.
identificar e comparti lhar as melhores práticas. A identificação de melhores práticas é

essencial para que ocorran1 n1elhorias na gestão de projetos. A Goodyear con1partilha
conosco três de suas n1elhores práticas.
Melhor prática n12 1: conferência global da Goodyear sobre

gestão de projetos
A Goodyear Tire & Rubber Company ten1 promovido u1na conferência global sobre
gestão de projetos anualn1ente desde 2012 para conectar gerentes de projetos e n1en1-
bros de equipe de todas as un idades de negócios estratégicas e quase todas as funções
de negócios. A conferência consiste en1 un1a experiência de três dias de duração focali-
zada son1ente em gestão de p rojetos, habil idades de liderança e networking profissio-
na l. Os participantes são selecionados por meio de u1n processo de non1eação e apro -
vação realizado pelos líderes de seus respectivos PMOs e a liderança de sua unidade
de negócios. Os critérios de seleção incluen1 o percentual de tempo que o gerente de
projetos dedica aos projetos, alén1 do escopo e a complexidade de seus projetos.
"Todo ano, n1ais de cen1 talentosos gerentes de projetos e men1bros de equipe da
Goodyear se reúnem para aprender con1 especialistas e uns com os out ros, con1 u1n
objetivo: potencializar a excelência em gestão de projetos pa ra produzir os resultados
esperados nos projetos da Goodyear. Essa reunião ilust ra o con1promisso da Goodyear
em desenvolver capacidades e1n torno da gestão de projetos", diz Sherry Neubert, vice-
-presidente do PMO.
A liderança de gestão de projetos da Goodyear participa da seleção da e1nenta da
conferência - especificamente concent rando-se em tópicos que contribuam para ele-
var a competência da empresa em gestão de projetos e que tenham apl icação imediata
ao trabalho cotidiano de seus gerentes de projetos. O programa é uma coleção bem
equilibrada de apresentações e discussões lideradas pelos especia listas do setor, pelos
líderes sênior da Goodyear e pelos gerentes de projetos da Goodyea r.
O horário dos participantes é preenchido por dois tipos de sessões de aprendiza -
gem: "sessões gera is", que têm tip icamente de duas a t rês horas de duração, inclue1n
todos os participantes e se focaliza1n en1 um assunto que cobre todos os tipos de pro -
jeto e níveis de experiência; e "sessões especializadas", que são sessões interativas de
u1na hora de duração focalizadas nos assuntos específicos a cada função e papel e que
são opcionais. Exen1plos dos assuntos a bordados nas sessões gerais são gerenciamento
de partes interessadas, un1a mesa-redonda sobre un1 estudo de caso das lições apren -
didas e1n um megaprojeto, como construi r equipes de projeto de excelente qualidade,
inteligência emocional e gestão de 1nudanças. Os assuntos das sessões especial izadas
incluen1 expectativas de pat rocinadores, como obter e n1anter uma certificação PMP®
(Profissional de gestão de projetos ou, em inglês, Project Management Professional),
mesas-redondas de executivos e planejan1ento de riscos e cenários.
Da primeira vez que participou de un1a dessas conferências, o diretor de progra1na da
OTR Tires, Alfredo Gamboa, disse que o astral da conferência era contagiante. " É con10
se cada tun de nós levasse para casa tun pedaço do 'DNA de Gestão Projetos da Goodye-
ar'. Agora aplicaren1os o que aprendemos ao nosso trabalho, independente de a que fun-
ções oferecemos suporte e, n1ais importante, trabal haren1os juntos durante o processo. A
colaboração é uma parte essencial da co1nunidade de gestão de projetos. Ela nos permite
trabalhar horizontalmente, e não verticalmente, ou em um silo."
A Conferência de Gestão de Projetos é criada para oferecer suporte ao amadu-
recimento gera l da gestão de projetos empresarial. É também indicativa de u1n forte
suporte à disciplina por parte dos níveis intermediário e sênior da gerência, como u1n
meio de alcança r os resultados desejados. Com ma is de 20 líderes sênior participando
da conferência todos os anos, é evidente que haja um forte suporte.
A aplicação da gestão de projetos e de conceitos de liderança aprendidos na con-

ferência é de suma importância para a liderança da Goodyear e para a comunidade
de gestão de projetos. Os participantes responde1n a uma enquete no final de cada dia
da conferência e ao fim dos três dias para que eles deixe1n seu feedback sobre os pa-
lestrantes, o programa e as atividades. O feedback é, então, aplicado à conferência do
ano seguinte como pa rte do planejamento de aprendizagem contínua.
Melhor prática nº 2: o estudo de caso de gestão de projeto

O histórico
Além de gerenciar projetos, o escritório de gestão de projetos da Goodyear prima pela
construção de capacidade, facil itando etapas e passagens de fases, orientando gerentes de
projetos e criando mecanismos para identificar e reutilizar o conhecimento institucional
da Goodyear. Em 2011, a Goodyear começou a usar o tradicional estudo de caso com um
toque inovador: con10 um mecanismo para aprender, "curar" e energizar suas equipes de
projeto e seus projetos, de n1odo a possibilitar futuros sucessos.
En1 reconhecin1ento ao fato de que as instituições que incuten1 uma cultura de melho-
rias contínuas são capazes de aprender com o passado, o PMO da Goodyear con1binou
o tradicional estudo de caso de projetos con1 metodologias de Investigação Apreciativa,
refinadas pela Case Western Reserve's Weatherhead School of Management, de modo a
identificar lições aprendidas en1 projetos e n1elhores práticas em gestão de projetos.
A Investigação Apreciativa é uma metodologia baseada e1n pontos forces, que se
focal iza no que foi bem feito e procu ra r renovar, construir e desenvolver futuros su-
cessos por 1neio da visua lização de um futuro que simu la experiências positivas do
passado. Apl icar esse " toque" ao tradicional escudo de caso foi extremamente eficiente
para o processo de estudo de caso da Goodyear. O propósito do estudo de caso é do-
cumenta r u1na revisão de objetivos sobre o que aconteceu e o que projetos futuros po-
dem aprender com ele. Começar o processo de entrevistas de forma positiva, pergun-
tando "o que deu certo" determina o tom da entrevista e cria um ambiente e1n que o
ent revistado se sente confortável o suficiente para compartilhar conhecimentos-chave
a sere1n passados para projetos futuros. Essa reflexão ajuda a fazer um encerramento
e uma "recuperação" da equipe de projeto, além de criar uma sensação de satisfação
pelo fato de outras equipes poderem se beneficiar das lições aprendidas co1n o proje-
to. O estudo de caso cria uma oportunidade para as pessoas serem ouvidas e para os
membros da equipe de p rojeto participarem da documentação de uma pa rte va liosa da
história da gestão de projetos da Goodyear.
O processo
Um projeto é ind icado para consideração como escudo de caso por um representante
de uma das quatro un idades de negócio da empresa, normalmente por um patrocina-
dor de projeto ou liderança regional. O PMO analisa os projetos e decide se irão real i-
zar um estudo de caso basedo nos recursos e investÍlnentos necessários para identificar
os dados e o valor organ izacional das lições aprendidas co1n o projeto que devem ser
compartil hadas.
Uma vez que o estudo tenha sido aprovado, o processo de coleta começa entrevis-
tando as partes interessadas e contribuidores do projeto, estruturando as respostas em
aprend izados-chave e melhores práticas e então, recontando, na forma de narrativa,
os pontos fortes do ciclo de vida do projeto e os fatores críticos de sucesso. A crença
é a de que falar a respeito dos fatores críticos de sucesso do passado, docu1nentando-
· os e simulando-os, possa criar futuros sucessos. Na Goodyear, é grande o desejo de
aprender com o passado e co1npartilhar conhecimentos da empresa. A simulação é um
fator-chave para o sucesso desse processo. O " impulso" de futuros projetos é criado
pelo desejo de ser bem-sucedido como os projetos passados - e o desejo mais favorável
de não reaprender por experiência, mas pelo aprendizado dos out ros.
O gerente de projetos e os pat rocinadores são consu ltados ao preparar a lista de
ent revistados - que pode va riar de 20 a 100 membros de equipe, patrocinadores e
partes interessadas. Esses indivíduos são ent revistados individualmente - algo que às
vezes se estende por vários meses e vários continentes. Pede-se aos ent revistados que
contem uma história sobre a experiência de projeto 1na is positiva que já tivera tn, inde-
pendenemente do tipo ou localização do projeto. Depois, pede-se que eles descreva tn
seu papel no projeto em estudo. E, finahnente, pede-se que eles descrevam os fatores
que contr ibuíram para o estado atua l do projeto.
O resultado é um estudo de e.aso que conta a história do projeto desde seu início
a té o estado atual, focalizando-se em um principal tema ou lição aprendida .
Recomenda-se que estudos de e.aso sejam realizados itned iatamente após um p ro-
jeto (ou fase) ser concluído ou enquanto o projeto (ou fase) ainda está em andamen-
to. Isso ocorre principalmente porque, quando os mem bros de equ ipe terminam seu
trabal ho etn um projeto, eles passam rapidamente a novos projetos, dispersando-se, e
podem se esquecer de detalhes relevantes de seu projeto anterior.
Os benefícios
A Goodyear observou que o processo do estudo de caso é catá rtico para os entrevis-
tados. O processo permite que os membros de equipe tenham uma chance de refletir e
encerrar o p ro jeto. É também gr atificante o fato de uma outra pessoa poder aprender
simplesmente ao ler o estudo de caso. É tão simples que a transferência de conheci-
mento pode ser fáci l quando ded icamos um tempo a anotar as coisas. A pessoa que
levanta as informações tambétn está aprendendo e, dado que essa pessoa tipicamente é
um membro do PMO, ele aumenta sua capacidade de contr ibuir para outros projetos.
Um out ro benefício para a empresa e pa ra as pessoas envolvidas é a oportunidade de
mel horias de processo ou reforço das mel hores práticas em projetos e equipes de p ro-
jeto futuras. O estudo de caso perm ite que as equ ipes de projeto futuras tirem p roveito
daqui lo que já sabemos e reproduzam sucessos passados.
O estudo de caso de p rojeto da Goodyear é um fator crítico de sucesso na acele-
ração da jornada da Goodyear rumo à maturidade em gestão de projetos. Ele faz cotn
que associados da Goodyea r de todo o mundo aprenda tn uns com os outros. Permite
que as equipes de projeto celebrem seus sucessos e a comunidade de gestão de projetos
como um todo seja reconhecida e valorizada por sua contr ibuição para possibi lita r os
investimentos da etnpresa. E com essa apreciação pela aplic.aç.ã o de u1na a bordagetn
disciplinada da gestão de projetos, a Goodyear aumentou também a confiança da em-
presa em sua capacidade de executar grandes projetos.
Melhor prática n12 3: abordagem da Goodyear quanto à orientação

e aconselhamento de gerentes de projetos
A Goodyea r adota u1na abordagem em três partes para incutir os princípios e métodos
de gestão de projetos em sua organização:
1. Estabelecimento de padrões de gestão de projetos (por meio de um "Playbook")
2. Treinamento em gestão de projetos
3. O rientação e aconselhamento para a gestão de projetos
Anteriorn1ente, a Goodyear descobriu que somente a con1 binação de padrões do-
cu1nentados e treinamento não eram suficientes para alcançar o nível desejado de ,na -
turidade de gestão de projetos. Portanto, a Goodyear intr oduziu a terceira "perna da

1nesa" na forma de orientação e aconselha ,nento sobre gestão de projetos.
Projetos com certo perfil de r isco recebem orientação e aconselha,nento do PMO.
A Goodyear reconheceu que o suporte oferecido aos projetos por um orientador de
gestão de projetos faz parte integral de um ciclo de vida de gestão de projetos bem-
-sucedido. Como o título sugere, um orientador designado a um projeto irá oferecer
suporte ao projeto em cada passo do caminho, de modo a possibilitar bons resultados.
Os orientadores tra balha ,n d ireta1nente com o gerente de projetos para fornecer um
fundamento ao t rabalho-padrão de processos, supervisão est ratégica para o p lane-
jamento de projetos e uma abordagem equilibrada da governança de projeto em um
processo de passagens de fases.
O objetivo último do orientador é garantir que o gerente de projetos tenha a ca-
pacidade de produzir os resultados desejados, o que, por sua vez, aU1nenta a probabi-
lidade de que o projeto vá produzir os resultados esperados. O orientador depende de
u1na relação de troca mútua com o gerente de projetos, na qua l os planos de projeto
são transparentes e o orientador indica respeitosamente áreas onde há oportunidades
e onde as 1nelhores práticas podem ser aplicadas. O principa l foco de um orientador
é oferecer uma orientação gera l de um ponto de vista objetivo para ajudar o projeto
a alcançar suas metas. Um benefício i1nportante da orientação é a visibilidade que o
orientador possui de projetos atuais e passados - o orientador se encont ra e1n u1na ex-
celente posição para comparar e cont rastar projetos atua is e passados e rapidamente
t ransferir melhores práticas entre diferentes projetos. Entretanto, o gerente de projetos
continua sendo o líder do projeto e, e1n última aná lise, é responsável por seu sucesso.
Ao estar envolvido em um projeto, o orientador pode assumir vários pap éis:

• Mentor: aconselha ,nento individual baseado no aprendizado de projetos passados
da empresa ou de experiências pessoa is de liderança.
• Facil itadorfTreinador: processo de encorajamento e t rabalho-padrão para produ-
zir os melhores resultados possíveis.
• Mediador: aconselhamento em negociações, r isco ou situações co1n patrocinado-
res, partes interessadas, 1nembros de equipe e relações multifuncionais.
• Observador: pode ajudar a descobr ir o risco de um projeto ou dar visibilidade a
um desafio antes que seja tarde demais.
• Torcedor: reconhecer rea lizações e reforçar o bom trabalho .
Embora haja situações e1n que um gerente é designado a um projeto a partir de um
grupo centra l, nos casos em que um orientador é implen1entado, tipicamente o gerente
de projetos vem da un idade de negócios ou função. Co,no a filosofia da Goodyear é
desenvolver a con1petência da gestão de projetos e uma n1entalidade de integração em
todos os seus futuros líderes e não desenvolver un1a empresa cheia de gerentes de proje-
tos, mais de 80% dos gerentes de projetos designados possui um histórico de gerência de
área ou administração e não un1 histórico de gestão de projetos formal.
Orientaç.ã o e aconselha ,nento são fatores críticos de sucesso para o PMO da
Goodyear. Quando apl icados a todo o ciclo de vida de um projeto com total transpa-
rênca e parceria, a Goodyear acredita que a orientação aumente sign ificativamente a
probabilidade de sucesso de um projeto .
Con1 a adição da orientação, a Goodyear viu a maturidade da gestão de projetos
e1n sua organização aumentar de forma perceptível. Como disse Sherry Neubert, VP do
PMO, "é preciso ter um Playbook que estabeleça as políticas e proced imentos funda-
mentais, e é preciso ter treinamento para acelerar a assin1i lação de conceitos e termi-
nologia pelos gerentes de projetos, mas a orientação durante a ap licação é, de fato, o
cimento que n1antém a coisa toda de pé".
3.6 Gerenciando premissas

Sempre que discutimos a jornada rumo à excelência, as pessoas esperam ver uma cro-
nologia de eventos relacionada ao modo como a empresa amadureceu em gestão de
projetos. Embora isso certamente seja i1nportante, há outros fatores que podem ace-
lerar o processo de maturidade. Um deles é a co1npreensão das premissas adotadas
e uma disposição para acompanhá-las ao longo do projeto. Se as pre1nissas estava1n
erradas ou mudaram, então talvez a direção do projeto deva mudar ou ele deva ser
cancelado.
O p lanejamento começa com a compreensão das premissas. Muito frequente-
mente, elas são adotadas pelo pessoal de marketing e vendas e, então, são aprovadas
pela gerência sên ior co1no parte da seleção do projeto e processo de aprovação. As
expectativas quanto aos resultados finais baseiam-se nas premissas adotadas.
Por que, muito frequentemente, os resultados finais de um projeto, então, não
satisfaze1n as expectativas da gerência sênior? No início de um projeto, é impossível
garantir que os benefícios esperados pela gerência sênior terão sido rea lizados na con-
clusão do projeto. Embora a duração do projeto seja um fator crítico, o verdadeiro
culpado são as mudanças nas pre1nissas.
As pre1n issas têm que ser documentadas no início de um projeto usando seu termo
de abertura como um meio possível. Durante todo o percurso, o gerente de projetos
deve reval idar e questionar as premissas, que podem determ inar que o projeto seja
cancelado ou redirecionado a um d iferente conjunto de objetivos. A jornada rumo à
excelência pode exigir uma forma de reval idar as prem issas. Quanto ma ior a duração
do projeto, maior a chance de as premissas mudarem.
Um plano de gestão de projetos baseia-se nas premissas descritas no termo de
abertura do projeto. Mas há pre1n issas adiciona is adotadas pela equ ipe que serve1n de
insumo para o plano de gestão de projetos.' Um dos principais motivos pelos quais as
empresas usa1n um termo de abertura é o fato de os gerentes de projetos 1nu itas vezes
entrarem em cena mu ito depois de o processo de seleção e o processo de aprovação
dos projetos tere1n sido concluídos. Consequentemente, os gerentes de projetos preci-
sam saber que prem issas devem ser consideradas.
3.7 Gerenciando premissas em projetos

5
de conservação - WWF lnternational
6
E1n 2005, e1n colaboração com outras organizações de conservaç.ã o, o World Wide
Fund for Nature (\VWF) concordou e1n dar início e iniciou a implementação de um
4
Ver A Cuide to tl,e Project Management Body of Knowledge• , 4ch ed., Project Managemenr Insricure,
Newrown Square, PA, 2008, p . 79 .
.s Qualquer reprodução parcial ou rotai deste artigo deve mencionar o círulo e os créditos da W\VF além do
detentor dos direitos autorais. © cexc 2009 \VWF- W'orld \-Vide Fund For Narure (também conhecido como
World \Vildlife Fund, ou Fundo !vlun.dial para a Narurez.a, em português) . Todos os direitos reservados. O
material foi fornecido por \Vi]ljam Reidhead, !v1Sc, gerente, consultor de design e impacto (monimramenco),
Unidade de Esrrarégia de Conservação e Desempenho, \V\VF lnrernarional.
6
Os Padrões do Programa W\VF são esrricamence baseados nos Padrões Abertos para a Prática e Con~
servação (Open Standards for tl,e Prac.rice of Conservatfon), desenvolvidos pela Parceria de Medidas de
Conservação (Couseroatfon Mensures Partnership), uma parceria de 11 organizações de conservaç.ã o que
trabalham juncas em busca de melhores maneiras de projetar, gerenciar e medir os impactos de suas ações de
conservação (www.con.servarionmeasures.org) .
conjunto de Padrões de Gestão de Programas e Projetos de Conservação ("Padrões de

Programas") .7 Esses padrões têin suas ra ízes em uma longa história de p lanejamento
de projetos e programas e gerencia1nento na WWF, entre outras organizações de con-
servação e em outras discipl inas. Os padrões de programas são criados para ajudar
os gerentes de projetos e os funcionários a descrever o que eles pretendem conservar,
identificar suas principais pre1nissas, desenvolver estratégias eficientes, 1nedir seu su-
cesso e então adaptá -las, compartilhá-las, e aprender co1n o passar do tempo.
Gerenciamento adaptativo e desafios em projetos de conservação

Em bora haja u1na quantidade significativa de pesquisas e documentação sobre gestão
de projetos no setor privado, cujos princípios se apl icam iguahnente ao setor sem fins
lucrativos, os projetos de conservação também enfrenta1n outros desafios. Além dos
p rocessos usua is de execução e controle de projetos, os projetos de conservação p reci-
sam operar e1n meio a uma grande incerteza e a sistemas complexos iiú luenciados por
fatores biológicos, políticos, sociais, econômicos e cultura is.
Ao definir o contexto do projeto, os conservacionistas devem considerar incerte-
zas quanto à situação da biodiversidade, ao funcionamento de sistemas ecológicos e a
como os humanos causam mudanças nos sistemas ecológicos e são, por sua vez, por
eles afetados. Da mesma fonna, ao criar intervenções cujo objetivo é 1nelhorar a situa-
ção da biodiversidade, os projetos de conservação enfrentam o desafio de precisarem
selecionar entre inúmeras estr atégias que a inda não foram testadas, saber qua l será a
mais eficiente e medir e comun icar o Ílnpacto dessas est ratégias. Tudo isso acontece no
contexto de recursos humanos e financeiros, informações e capital político limitados,
a lém da exigência cada vez maior de transparência e da influência de doadores ego-
. .
vernos que apoiam os proJetos.
Consequenten1ente, os Padrões de Progran1as da WWF seguen1 u1na abordagen1
experi1nental para gerenciar projetos de conservação, integrando definição, design,
gerencian1ento e monitoramento para testar sistematica1nente as pren1issas a fim de
adaptar e aprender. O processo de gerenciamento adaptativo exige que as equipes de
p rojeto identifiquem explicitamente as pren1issas sob as qua is estão operando e as tes-
tem siste1natican1ente para ver se são válidas no contexto de seu projeto. Isso fornece
u1n método para to1nar decisões 1nais conscientes, testando a eficiência das estratégias
usadas e aprendendo e adaptando-as para melhorá-las.
Abaixo há duas ferramentas que são melhores práticas recomendadas dentro dos
Padrões de Programas da WWF e são essenciais para determinar e gerenciar premissas
de projetos.
Modelos conceituais
Um m odelo conceituai (também chamado de "árvore de proble1nas" ou "mapa da pro-
blemática" ) é um diagrama que representa um conjunto de supostas relações causais
ent re fatores que se acredita1n afetar um ou mais dos alvos de biodiversidade (espécies
ou habitats) que o projeto pretende conservar. Um bom modelo conceituai deve asso-
ciar explicitamente os alvos de biodiversidade às ameaças diretas que os afetam e às
ameaças e oportunidades indiretas que influenciam as ameaças diretas . Deve também
ressaltar as prem issas que foram adotadas sobre relações causais e indicar camin hos
por meio dos quais atividades estratégicas podem ser usadas para influenciar positiva-
mente essas relações. E,n resumo, um modelo conceitua i representa a situação presente
7
Para informações mais detalhadas sobre os Padrões de Programas da \\7\Xff, visite www.panda.org/scandards.
no local em que o projeto está sendo desenvolvido e fornece a base para determinar
onde as equ ipes de projeto podem intervir com atividades est ratégicas.
Observe que cada seta que conecta duas caixas na Figura 3- 9 indica causa lidade e
representa uma premissa que pode ser testada.
Cadeias de resultados
As equipes de projetos de conservação implen1entan1 estratégias que elas acreditam
que irão contribui r para conserva r a biodiversidade em seu local, n1as poden1 não
declarar formalmente suas premissas sobre exatamente como a estratégia levará à
redução da an1eaça e à conservação da biodiversidade. Na verdade, é provável que
elas tenham n1u itas pren1issas in1p lícitas - que podem até mesn10 diferir entre os
n1embros de equ ipe e parceiros de projetos - sobre como suas estratégias irão contr i-
bui r para alcançar a conservação. No entanto, se essas premissas não forem explici-
tadas, não poderão ser testadas, nem sua validade poderá ser determinada ao longo
do tempo .
Uma cadeia de resttltados é uma ferramenta que esclarece essas prem issas, u1n
diagrama que mapeia uma série de declarações causais que conectam fatores na fonna
de causa e consequência (se ... então ... ). As cadeias de resultados podem ajudar as
equipes a especificar e modelar suas teorias de mudança. Em algu1nas organizações,
as cadeias de resultados ta1nbém são chamadas de "modelos lógicos" ou "árvores de
soluções". As cadeias de resultados são const ruídas a partir do modelo conceitua i e,
como mostra a Figura 3- 10, são compostas por u1na estratégia (um grupo de ativida-
des), resultados desejados e o impacto último que esses resultados terão sobre o a lvo
de biodiversidade. Uma meta é uma declaração formal de u1n impacto desejado sobre
um alvo de biodiversidade e um objetivo é uma declaração formal de um resultado
desejado, frequentemente a redução de uma ameaça.
Dessa maneira, uma cadeia de resultados bem construída oferece ao projeto u1n
conjunto de atividades estratégicas a serem executadas no local, a lém de 1netas e ob-
jetivos, ou seja, um plano de ação de conservação. As cadeias de resultados tambétn
fornecem a base para planos financeiros/operacionais, a lém de formular indicadores
e monitorar e controlar planos. Além de elucidar premissas e desenvolver planos para
a execução de projetos, os modelos conceitua is e as cadeias de resultados são, ambos,
ferramentas úteis para monitorar e cont rolar durante a implementação de um projeto,
para avaliar impactos e para diagnosticar qualquer gargalo que possa surgir.
De nada adianta que as duas ferramentas aci1na caiam dentro dos planos de pla-
nejamento dos Padrões de Programas da WWF conhecidos como Defin ir e Projetar.
Esses passos também incluem out ras ferramentas para avaliar a via bilidade de alvos
de biod iversidade, para classificar ameaças à biodiversidade, para a análise de partes
interessadas, para avaliar r iscos, etc. Outros passos incluem melhores práticas de im-
plementação, de aná lise de resutados, de adaptação de planos e de comparti lhamento.
3.8 Governança de projetos

A maioria das empresas começa a jornada rumo à excelência co1n o desenvolvi1nento
de uma metodologia de gestão de projetos. A fina lidade da metodologia é fornecer não
somente um guia de co1no proceder, mas tambétn oferecer ao gerente de projetos as in-
formações necessárias e atualizadas para a to1nada de decisões. A tomada de decisões
exige a lguma forma de governança e muitas vezes isso é descoberto tard iamente na
jornada rumo à excelência.
....
~
Coosclentlzaçlo Fraca aplicaçlo
-
1- 1\)
-
limitada de da lel
proprietários ~ Desmatamento
ilegal por
Valor de çonservação de de terras proprietários G)
Conhecimento E"opo: (1)
zonas úmidas recoohecido
por leis estaduais
limltado das leis por
proprietários
1- Zonas úmldas e
habitat limitrofe à
.,,o
!e
Planlcie Costeira a.
Falta de priorlzaçlo de
çonservação de zonas úmidas
no planejamento estaduaVJocal
Fracasso na
implementação de políticas
estaduais/tocais
1JDesmatamento
para a ronstruçl[o ,-~
residencial ou
de infraestrutura
Ptrdi
,,,.,~
"'"'· - /
deSWan
Florestas
'
(1)
"O
-·ag
(1)
Demanda adjacentes às
por terras zonas úmidas
Demanda ,
- '
por lenha
Uso
recreativo -
Perturbação
da vegetaçlo
Colonlzaçlo
nativa
~Ervas daninhas
invasivas - /
Zonas úmidas'
,... por meio de rom inundaçl[o
sazonal
Falta de compreensão acelros
~Maior extração """'"'"' +-
de gerenciamento de deáguas 1-n4t1.igda;01M- / Processos
-
vegetação pelos subte rrâ neas Jlltltt'mil!BH de filtração
proprietários Demanda deágua
por água ,
População
crescente - Medidas
de eflc!ncla
de água
-
~ \!!!!) Mudanças
climáticas (redução
das chuvas)
1
!:J caça (local· Patos de

Demanda Cultura de caça f-., mente eao longo de
por ... ?
n trajetória migratória) bico azul
Demanda
pos pastos
de verão - Capacidade limltada
para agricultura H
orgânica
AjJricultura
orgânica
limitada
~ Pesticidas ,-
da agricultura
Vegetação
L.EGENDA Classificação da ameaça rasteira
Aceitação social adjacenteàs
J
G Ameaça Ameaça • Muilo D Alta
das zonas úmldas \!!!!..1Sobrepaston, io zonas úmidas
direta
indin,ta ou ª"ª
OMrtunidade D Medlana D Mediana para pastoreio
' /
Figura 3-9 Exemplo (simplificado) de um modelo conceituai da Planície Costeira do Swan no sudeste da Austrália.
__, Ol!i 1.1
Proprietários
MelM>rias no
!reinados em BMPs ProprielâriOs
de ionas ó.mklas e lmplemenlam BMPs 1----, 9erenciamenlodas
nas propriedades zonas õmklas e na
Promoção das 1 vegetação margin.a1 vegetação margNlal
lerreSlre
mellores prâtcas de
'gerenc:iamenlO (BMPs ... b Rt<AIÇ30 <li
management practkes)e pltrda de nora
mecaniSmos de proteção
econservação 1 Proprietários dentes
dos incenl '°"
a mecaniSmos
de proteção 8
conservação
H Proprielários
reconhecem benelieiOs
de mecanismos de
proEçãoe conservação
H [01J;1z 1
Maior adoção
voluntâria de
mecanismos
de proteção
ebuna
..
o
"D
;::;,
-
e
o
w
t..
-~
o
: :,
Figura 3- 10 Exemplo (simplificado) de uma cadeia de resultados da Planície Costeira do Swan, no sudeste da Austrália. ..-
e:
3
...
o
!ffi;
..
::,
Q,
...
'"
w
Uma metodologia é uma série de p rocessos, atividades e ferramentas que fazem

pa rte de uma d iscipl ina específica, cotno a gestão de projetos, e desenvolvida para
alcançar utn objetivo específico. Quando os produtos, serviços ou clientes têm requi-
sitos similares e não exigem persona lização significativa, as empresas desenvolvem
metodologias para fornecer certo grau de consistência na forma em que os projetos
são gerenciados. Esses tipos de 1netodologia geralmente se baseiam em políticas e pro-
cedimentos rígidos.
À med ida que as empresas se tornam razoavehnente maduras em gestão de pro-
jetos, as políticas e procedimentos são substituídas por formulários, di ret rizes e listas
de verificação. Isso fornece ao gerente de projetos maior flexibilidade em como aplicar
a 1netodologia para satisfazer os requisitos de um diente específico. Isso leva a uma
aplicação mais informal da metodologia de gestão de projetos.
Hoje, chama tnos essa abordagem infonnal da gestão de projetos de "modelo".
Um modelo é u1na est rutura conceituai básica que é usada para tratar de algum assun-
to, como um projeto. Inclui um conjunto de pretn issas, conceitos, va lores e processos
que fornecem ao gerente de projetos um meio para ver o que é necessário para cumprir
os requisitos de um cliente. Trata -se de uma estrutura de suporte sobre a qual se pode
const ruir os deliverables do projeto.
Os modelos funcionam bem, contanto que os requ isitos do projeto não impo-
nham uma pressão forte demais ao gerente de projetos. Infelizmente, no ambiente
caótico de hoje em d ia, essa pressão parece estar aumentando, pois:
• Os cl ientes estão exigindo produtos de baixo volume e alta qua lidade, com certo
grau de persona lizaç.ã o
• Os ciclos de vida de projeto e as durações do desenvolvimento de novos produtos
estão sendo comprimidos
• Os fatores ambienta is da empresa estão tendo um itnpacto ma ior sobre a execu-
ção de projetos
• Os clientes e partes interessadas querem ser tnais ativamente envolvidos na exe-
cução de projetos
• As empresas estão desenvolvendo parcerias est ratégicas com fornecedores, e cada
fornecedor pode estar em um nível diferente de maturidade etn gestão de projetos
• A concorrência globa l forçou as empresas a aceitarem projetos de cl ientes que
estão todos em d iferentes níveis de 1naturidade em gestão de projetos
Essas p ressões tendem a tomar ma is lentos os processos de tomadas de decisão
em um momento em que as partes interessadas queretn que eles sejam rápidos. Essa
desaceleraç.ã o é resultado dos seguintes fatores:
• Espera-se que o gerente de projetos tome decisões em áreas em que ele tem conhe-
cimento limitado.
• O gerente de projetos hesita etn aceitar total responsabilidade e propriedade dos
proJetos.
• Camadas excessivas de gerenciamento são superpostas acima da o rgan ização da
• O gerencia tnento dos r iscos está sendo empurrado pa ra níveis mais a ltos da hie-
rarquia da organização.
• O gerente de projetos demonstra uma capacidade de liderança questionável.
Esses problemas podetn ser resolvidos usando uma governança de projetos efi-
ciente. A governança de projetos é, na verdade, um 1nodelo segundo o qua l se tomam
decisões. A governança está relacionada a decisões que definem expectativas, respon-
sabilidades, delegação de poder ou verificação de desempenho. A governança está re-

lacionada a um gerenciamento consistente, pol íticas e processos coesivos e diretos de
tomada de decisões para determinada á rea de responsa bi lidade. A governança possibi-
lita que a tomada de decisões seja eficiente e eficaz.
Cada projeto possui uma governança diferente, mesmo que cada um deles use a
mesma metodologia empresaria l de gestão de projetos. A função de governança pode
operar como utn processo separado ou como parte da liderança de gestão de projetos.
A governança é criada não sotnente para substituir a tomada de decisões do projeto,
mas para evitar que decisões indesejáveis sejam tomadas.
Historicatnente, a governança era feita pelo pat rocinador do projeto. Hoje, a go-
vemança é feita por um comitê, cujos membros podem mudar de um projeto para ou-
tro e de um setor pa ra outr o. Podem variar também dependendo do número de partes
interessadas e se o projeto é para um cl iente interno ou externo.
3.9 Sete falácias que atrasam a maturidade

da gestão de projetos
Muito frequentemente, as empresas embarcam em u1na jornada rumo à itnplementa-
ção da gestão de projetos e só então descobretn que o caminho que eles pensaratn ser
claro e di reto é, na verdade, cheio de obstáculos e falácias. Sem cotnpreensão suficiente
das barreiras iminentes e de como superá-las, uma organização pode nunca alcançar
um alto nível de maturidade em gestão de projetos. Seus concorrentes, por outro lado,
podem exigir apenas alguns anos para implementar uma est ratégia para a organização
que produza projetos bem-sucedidos de forma previsível e consistente.
Un1 importante obstáculo à maturidade em gestão de projetos é o fato de que as
atividades de in1plen1entação geraln1ente são lideradas por pessoas em cargos de au-
toridade dentro de uma organização. En1bora n1uitas vezes tenham uma compreensão
insuficiente da gestão de p rojetos, não estão dispostas a frequentar progran1as de
treinamento, por mais curtos que sejam, pa ra adquirir uma compreensão básica do
processo. Um segundo obstácu lo importante é que essas mesmas pessoas geraln1en-
te toman1 decisões de in1plen1entação baseadas em interesses pessoais ou segundas
intenções. Ambos os obstáculos causam problen1as à implen1entação da gestão de
proJetos.
As falácias que afetam a 1naturidade de uma implementação de gestão de projetos
não necessariamente impedem que ela ocorra. Em vez disso, essas crenças errôneas
alongam a du ração da implementação e criam uma frustração sign ificativa entre os
membros da equipe de gestão de projetos. As sete falácias mais co1nuns serão explica-
das a seguir.
Falácia 1: Nosso objetivo final é implementar a gestão de projetos. Meta errada! O
objetivo fina l deve ser o desenvolvimento progressivo de sistemas e processos de ges-
tão de projetos que, consistente e previsivelmente, resu ltam em um fluxo contínuo de
projetos bem-sucedidos. Qualquer um pode comprar um pacote de software e imple-
mentar a gestão de projetos de forma pontual, mas o resultado não necessariamente
será sistemas e processos eficientes de gestão de projetos. Além disso, conclu ir cotn
sucesso um ou dois projetos não significa que você irá continuar a ter apenas projetos
bem-sucedidos.
Ainda, cotnpra r o melhor software de gestão de projetos não pode e não irá subs-
tituir a necessidade de as pessoas teretn de t rabalhar juntas em um ambiente de gestão
de projetos. O software não é:
• Un1a panaceia ou solução pal iativa para os problemas de gestão de projetos;

• Uma a lternativa ao lado humano da gestão de projetos;
• Um substituto do conhecimento, das habi lidades e experiências necessárias para
. .
se gerencia r proJetos;
• Um substituto da tomada de decisões hu1nana;
• Um substituto da atenção da gerência quando necessário.
É essencial ter o objetivo correto para alcançar a 1naturidade em gestão de proje-
tos no menor interva lo de tempo possível.
Falácia 2: Precisamos estabelecer tal número de formulários, gabaritos, diretrizes
e listas de verificações em determ inado prazo . Critérios errados! A maturidade em
gestão de projetos pode ser ava liada somente por meio do estabelecimento de níveis
de maturidade baseados no tempo e do uso de instrumentos de ava liação. Embora
formulários, gabaritos, diret rizes e listas de verificações reahnente seja1n necessários,
maximizar seu número ou colocá-los em vigor não significa que a gestão de projetos
esteja amadurecendo. Mui tos - inclusive eu - acreditam que a maturidade possa ser
acelerada se o foco for o desenvolvimento de u1na 1netodologia de gestão de projetos
para toda a organização à qual todos adiram e apoiem.
As metodologias devem ser criadas de modo a agilizar a forma como a organi-
zação lida com projetos. Por exemplo, quando um projeto é concluído, deve-se fazer
o debriefing da equipe para identificar as lições aprendidas e as 1nelhores práticas. A
sessão de debriefing geralmente revela maneiras de minimizar ou combinar processos
e mel horar a eficiência e a eficácia se1n au1nentar os custos.
Falácia 3: Precisamos con1prar u m softiuare de gestão de projetos para acelerar o pro-
cesso de maturidade. Abordage1n errada! Comprar um software somente para ter um
software de gestão de projetos é uma má ideia. Muito frequentemente, os tomadores
de decisões compram esses softwares baseados nos recursos e acessórios que o acom-
pan ham, acreditando que um pacote de softiuare maior conseguirá acelerar a matu-
ridade. Ta lvez um pacote de softiuare de US$200 1nil seja benéfico para u1na empresa
que esteja construindo usinas nucleares, mas que percentual de projetos exige recursos
elaborados? Os gerentes de projetos e1n meus seminários imediata 1nente ad1nite1n que
usam menos de 20 % da capacidade de seu softiuare de gestão de projetos. Eles pa-
recem vê-lo como uma ferramenta de geração de cronogra1nas em vez de como uma
ferramenta para gerenciar projetos proativamente.
Considere o exemplo a seguir que poderia representar um ano típico em uma or-
ganização de médio porte:
• Número de reuniões por projeto: 60
• Número de pessoas presentes em cada reunião: 1O
• Duração de cada reunião: 1,5 hora
• Custo de uma hora-homem em sua carga máxima: US$125
• Número de projetos por ano: 20
Usando essas informações, a organização gasta u1na média de US$2,25 milhões
para que as pessoas participem de reuniões de equipe em um ano! Bem, e se pudésse-
mos comprar um pacote de softiuare que reduzisse o número de reuniões de projeto
e1n 10% ? Podería1nos economizar para a organização US$225 1nil por ano!
A ,neta da seleç.â o do software deve ser os benefícios para o projeto e a organi-
zação, como reduções de custo por meio de eficiência, eficácia, padronização e con-
sistência. Um pacote de software de US$500 pode, na maioria das vezes, reduzir os
custos do projeto tão eficientemente quanto u1n pacote de US$200 mil. Infel izmente,
as pessoas que encomendam o pacote focal izam 1nais no nú tnero de recursos que o
pacote possui do que em quanto a empresa economizará com o uso do software.
Falácia 4: Precisan1os implementar a gestão de projetos em pequenos passos con1 u m
pequeno pr ojeto inaugural que todos possam acompanhar. Método errado! Isso fun-
ciona se o tempo não for uma restrição. A melhor aposta é usar um grande proje-
to cotno o projeto inaugura l. Um grande projeto ser bem-sucedido significa que os
mesmos processos podem funcionar em pequenos projetos, enquanto o inverso não é
necessariamente verdadeiro.
Em pequenos projetos inaugura is, algumas pessoas sempre discutetn contra a im-
plementação da gestão de projetos e encontram inúmeros exemplos de por que eles
não funcionarão. Usar um projeto grande geralmente encontra menos resistência, es-
peciahnente se a sua execução proceder sem grandes proble1nas.
Há riscos em usar um projeto grande como inaugural. Se o projeto enfrentar pro-
blemas devido a uma gestão de projetos mal implementada, podetn ocorrer danos
significativos à empresa. Existe um argumento válido a favor de começar com projetos
pequenos, mas a preferência do autor é por projetos maiores.
Falácia 5: Precisan1os acompanhar e d ivulgar os resultados do projeto inaugural. Ação
errada! Expor o sucesso de utn projeto beneficia somente aquele projeto, e não a em-
presa inteira. Esclarecer como a gestão de projetos fez um projeto ser betn -suced ido
beneficia toda a organização. As pessoas, então, irão compreender que a gestão de
projetos pode ser usada etn diversos projetos.
Falácia 6: Precisamos do apoio executivo. Quase verdadeiro! Precisamos de um apoio
executivo visível. As pessoas podem faci lmente diferenciar entre apoio genuíno e apoio
"da boca para fora". Os executivos devem servir de exemplo. Têm de presidir reuniões
para demonstrar seu apoio à gestão de projetos e estar presentes em várias reuniões de
equipes de projetos. Eles precisam manter u1na política de portas abertas para proble-
mas que ocorram durante a implementação da gestão de projetos.
Falácia 7: Precisamos de um curso de gestão de projetos para que nossos funcionários
possam se tornar PMPs®. Mais uma vez, quase verdadeiro! Aqui lo de que rea lmente
precisamos é u1na educação contínua em gestão de projetos. Tornar-se PMP®é apenas
o ponto de partida. Existe vida alétn do Guia PMBOK®. A educação contínua etn
gestão de projetos etn toda a organização é a 1naneira mais rápida de acelerar a matu-
ridade em gestão de projetos.
Nem é preciso mencionar que há um número significativamente maior do que o
que foi discutido aqui de falácias prontas para impedir sua imple1nentação da gestão
de projetos e postergar sua 1naturidade. O que é crucial é que sua organização a imple-
mente por meio de um plano bem pensado, que receba adesão e apoio de toda a orga-
nização. Falácias criam atrasos desnecessários. Identificar e superar pensamentos er-
rôneos pode ajudar a acelerar a maturidade na gestão de projetos de sua organizaç.ã o.
3.10 Motorola
"Em 2005 fará bem mais [BH2] de 30 anos que a Motorola tem usado a gestão de
8
projetos", segundo um porta-voz da Motorola. As forças que levaram a empresa a
reconhecer a necessidade de se tornar bem-sucedida em gestão de projetos foram "a
' H. KerZJler, Project Management Best Practices: Acbieving Global Excellence, Hoboken, NJ: \Viley, 2006, p. 88.
148 Gestão d e projetos
crescente complexidade dos projetos junta mente co1n problemas de qua lidade, des-
cumprimento de prazos e sobrecustos, o que levou a gerência sêni or a busca r uma
sol ução gerencia l alternativa ao q ue acontecia a nteriormente. A seguir, temos uma
crono logia do que a M otorola fez para chegar onde se encontra hoje além de alguns
dos problemas encontr ados:
• 1995: Contrata r um diretor de gestão de projetos
• 1996: Primeiro, contratar gerentes de projetos - definição de papéis forma is e transfe-
rência de responsabilidades para geração d o cronograma e aceitação do projeto
• 1998: Contro le de mudanças forma is instituído - liderado por gerente de projetos
• 1998: Passagens de fases implementadas em todos os projetos
• 2000: Implementação de ferramenta de controle do tempo
• 2001: Implementação de um acompanhamento de recursos mais formal
• 2002: Melhorias no planejamento e acompanhamento de recursos
• 2004: Contabilidade de custos de projetos
Inicialmente, o gerenciamento de progra mas era visto como uma atividade extra . Gerentes
de engenha ria relutavam em abrir mão do controle do programa e comunicação de status.
Foi somente por meio do comprometimento da gerência sênio r com práticas forma is de
gestão de projetos que foi criado um PMO e cargos e responsabilidades foram transferidos.
A aceitação tota l do gerenciamento d a engenha ria só ocorreu vários a nos depois de a gestão
de projetos ter demonstrado o valor de práticas estruturadas de gerenciamento de progra-
ma, o q ue resultou em entregas de produtos consistentemente dentro do prazo. Tais práticas
incluem a geração formal, integrada e completa do cronogra ma do projeto, oferecendo uma
s upervisão do projeto de forma independente e multifunciona l, comunicando o status do
programa de forma não tendenciosa, coordenando a resolução de problemas de modo mul-
ti funcional, além da identificação e gerenciamento d os riscos do programa. Posterio rmente,
as responsabilidades da gestão de projetos a umentaram, passando a incluir o utras á reas
impo rta ntes, como comunicações com o cl iente, controle de escopo e gestão de mudanças,
contenção de custos e planejamento de recursos.
O suporte executivo foi fornecido por meio do patrocínio do desenvolvimento d a fun-
ção de gerencia mento de progra ma. A estrutura de geração de relató rios da função foi cui-
d adosamente mantida dentro de uma área a propriada d a organização, garantindo indepen-
dência de influências indev idas de outras áreas funcionais, de modo que fossem oferecidos
s uporte e relatórios objetivos e independentes."
9
3.11 Texas lnstruments
Um problema crucia l enfrentado pelas empresas é se a 1n etodologia deve o u não ser
desenvolvida antes do esta beleci mento de uma cultura de gestão de projetos. As em-
presas gera lmente cometetn o erro fata l de acreditar que o desenvolvimento de uma
metodo logia de gestão de projetos é a solução pa ra seus problemas. Embora isso possa
ser verdade etn a lgumas circunstâ ncias, as etnpresas excelentes percebem que são as
pessoas que executa m as 1n etodologias e que as mel hores práticas em gestão de pro-
jetos podem ser alcançadas mais rap idamente se o foco forem as pessoas, e não as
ferramentas.
Uma fo rma de se tornar bom em gestão de projetos é desenvolver uma pirâmide
de sucesso co1n o mostra a Figura 3-11. Cada empresa possui sua própria abordagem
q uanto ao que deve ser incluído em uma pirâ mide de sucesso.
9
H. Keru1er, Advanced Project Management: Best Practices in lmplement.atfo11, Hoboken, NJ: \Viley, 2004,
p. 46-48.
A Texas Instru1nents reconheceu a importância de focar as pessoas como u1na

forma de acelerar o sucesso nos projetos. A pirâmide do sucesso desenvolvida pela em-
presa para gerenciar projetos globais é apresentada na Figura 3-12. Um porta-voz da
Texas Instruments descreve o desenvolvimento e a utilização da Pirâm ide do Sucesso
na gestão de projetos globa is na Texas lnstruments:
No final da década de 1990, a organização empresarial de sensores e controles tinha migra-
do de equipes locais para eq uipes globais. Eu era responsável por gerencia r de cinco a seis
gerentes de projetos que, por sua vez, gerenciavam eq uipes globais de desenvolvimento de
novos produtos (NPD, New Prod11ct Deve/opment). Essas equipes geralmente consistiam
Valor
•
Adesão da equipe
•
Gerência funcional
•
Apolo da gerência sênlor
Figura 3-11 Pirâmide do sucesso.

•
Foco em comunicações, trabalho em equipe e confianç
PIRÂMIDE DO FACILITADORES
SUCESSO DA EQUIPE
GLOBAL
COMUNICAÇÃO TRANSFERÊNCIA PROCESSOS

OE DADOS
LOGÍSTICA
PLANEJAMENTO ACORDOS
DE PROJETOS OPERACIONAIS
Figura 3-12 Pirâmide do sucesso da Texas lnstruments.

em 6-12 membros da América do Norte, Europa e Ásia . Embora estivéssemos operando em

um ambiente empresaria l global, as equipes enfrentavam muitas dificuldades novas e ímpa-
res. Desenvolvemos a pirâmide do sucesso para auxiliar os gerente de projetos nessa tarefa.
Embora a mensagem da pirâmide seja bastante simples, o uso dessa ferramenta pode ser
muito poderoso. Ela se baseia no princípio de construir uma pirâmide da base a té o topo.
A camada inferior dos blocos de construção é o a licerce, chamado de "compreensão e con-
fiança". A mensagem aqu i é q ue, para que uma equ ipe global funcione bem, deve haver um
vínculo comum. Os membros da equipe precisa m confiar uns nos outros, e cabe ao gerente
de projetos garantir q ue esse vínculo seja estabelecido. Nos blocos de construção desse
nível, são fornecidos detalhes e exemplos adicionais para a uxílio dos gerente de projetos. É
comum q ue alguns membros de uma equi pe jamais tenham se encontrado antes do início de
um projeto, de modo que a tarefa de construir a confiança é, definitivamente, um desafio.
O segundo nível se chama ;'d ireção sancionada". Esse nível inclu i o termo de abertura
do projeto e a missão da equipe, bem como as metas e objetivos formais. Como essas equi-
pes são virtuais e raramente se encontram pessoalmente, a mensagem nesse nível é a de que
o gerente de projetos deve assegurar-se da aprovação e do apoio de todos os gerentes regio-
nais envolvidos no projeto. Tal passo é crucia l para q ue se evitem conflitos de prioridades
entre membros de equi pe que se encontram em locais d istantes.
O terceiro nível da pirâmide é denominado de ;'responsabilidade" . Esse nível enfatiza
a importância de se incluírem os valores e crenças de todos os membros de equipe. Em
equipes globais, pode haver bastante variação nessa área. Ao permitir que a voz de todos
os membros de equipe seja o uvida, não só o planejamento de projeto pode ser mais abran-
gente, mas também todos podem aderir d iretamente ao plano. Os gerentes de projetos que
usam um método de liderança d istribuída nessa fase norma lmente se saem mu ito bem. O
segredo é levar as pessoas fazerem a transição de uma atitude de obrigação para uma d ispo-
sição a aceitar responsabilidades.
O n ível seguinte, chamado de "logística", é aquele em q ue a equipe trabalha na maior
parte do tempo durante o projeto e realiza s uas tarefas do d ia a d ia. Esse nível inclui todas
as comunicações diárias, semanais e mensais e baseia-se em um acordo quanto ao tipo de
desenvolv imento que se seguirá. Na Texas lnstruments, há um processo para projetos de
DNP q ue geralmente é utilizado para esse tipo de projeto. O poder da pirâmide é que esse
nível de trabalho detalhado pode ter um andamento bem uniforme, desde que esteja funda-
mentado em um sólido alicerce.
Seguindo a execução dos níveis mais baixos da pirâmide, podemos espera r a obtenção de
bons "resultados", como mostra o quinto nível, desenvolvido nas duas áreas, de clientes inter-
nos e externos. Os clientes internos podem incluir a gerência ou pode incluir locais de centros
de negócios que detenham a propriedade financeira do projeto como um todo.
Finalmente, o nível mais a lto da pirâmide mostra a meta geral e é chamado de "sucesso
da equ ipe" . Nossa experiência nos mostra que uma equipe global q ue é bem-s ucedida em
um projeto de duração de um a dois anos geralmente é elevada a um n ível superior de con-
fiança e capacidade. Esse sucesso gera um entusiasmo ainda maior e prepara os membros de
equipe para enfrentarem tarefas maiores e ainda mais desafiadoras. A habilidade do gerente
de aproveita r esse nível superior de capacidade proporciona uma vantagem competit iva e
impulsiona a conquista do sucesso.
Na Texas lnstr uments, a ênfase na cultura é uma melhor prática. Infelizmente,
outras empresas não percebem a importância disso.
1
3.12 Hewlett-Packard: reconhecendo a necessidade º
Desde 1992, a gerência da Hev.rlett-Packard totnou a decisão de prioriza r o desenvol-
vimento da maturidade e da excelência em gestão de projetos. Formou-se um novo
'º H. Kerz.ner, Project Ma11agement Best Practices: Achieving Glol,al Excellence, 2nd edicion, Hoboken~ NJ:
\Viley, 2010; p. 118.
grupo de recursos de projetos dedicados dent ro do departamento de serviços da or-

ganização, que recebeu o tenno de abertura de projeto para se tornarem "especialis-
tas" profissionais em gestão de projetos. A Hewlett-Packard estabeleceu um dinâmico
programa de treinamento, a lém de um programa informa l de "mentores", no qual
gerentes de projetos sên ior ofereceriam orientação e direção para o pessoal recém-
-designado. Alé1n dos cursos de treinamento interno existentes, foram desenvolvidos
novos cursos de gestão de projetos. Quando necessário, eles era1n complementados
com programas externos que forneciam uma instrução abrangente em todos os aspec-
tos da gestão de projetos. Esforços para alcança r a certificação reconhecida pelo setor
tornaram-se u1na iniciativa crucial para o grupo.
A Hewlett-Packard reconheceu que poderia expand ir seus negócios se demons-
trasse habilidades superiores em gestão de projetos. Na imple1nentação de soluções
grandes e complexas, a gestão de projetos passou a ser vista co1no um diferencial
para o processo de vendas. Clientes satisfeitos estavam se tomando clientes leais. O
resultado final foi um apoio maior a inda e novos negócios para a He,vlett-Packard. A
Hewlett-Packard reconheceu também que seus clientes ou não possuíam seus próprios
recu rsos, ou não queriam compro1netê-los, e a empresa foi capaz de convencer os
clientes do valor da gestão de projetos profissional. Em poucas palavras, se a Hewlett-
-Packard possui habilidade para tal, por que não deixamos o gerenciamento de nossos
projetos em suas mãos?
Segundo J im Hansler (PMP®), gerente de projetos da Hewlett-Packa rd, foram ob-
tidos os seguintes benefícios:
Primeiro, estamos suprindo as necessidades de implementação de nossos clientes por um
custo mais baixo do que eles conseguiriam alcançar sozinhos. Segundo, somos capazes de
fornecer aos nossos clientes um meio consistente de implementar e entregar um projeto por
meio do uso de uma base comum de ferramentas, processos e metodologias de projeto. Ter-
ceiro, estamos nos beneficiando de vendas adicionais pelo emprego da gestão de projetos.
Nossos clientes agora d izem: "Deixe que a HP faz!".
A Hewlett-Packa rd logo reconheceu que não estava mais apenas vendendo produ-
tos, mas oferecendo "soluções" aos seus clientes. Hoje a HP vende soluções, assumin-
do a responsabi lidade por todas essas tarefas e tantas outras. Ao final, o cliente recebe
uma solução completa e já em funcionamento, sem ter que comprometer recursos
significativos de sua própria e1npresa. Para fazer isso com êxito repetidas vezes, a HP
também precisa vender suas proeminentes capacidades em gestão de projetos. Em ou-
tras palavras, os cl ientes esperam que a HP tenha uma capacidade superior de gestão
de projetos para oferecer soluções. Essa é uma das exigências quando as expectativas
dos clientes são a força mot riz.
Mike Rigodanzo, antigo vice-presidente sên ior da HP Services Operations and
Information Technology, acredita que:
No setor de serviços, a forma como produzimos é tão importante quanto o que produzimos.
Os clientes esperam maximizar seu retorno sobre investimentos em TI a partir de nosso
conhe.cimento e experiência coletiva quando lhes oferecemos as melhores soluções.
Todo o conhecimento e a experiência da HP Services são facilmente acessíveis por meio
do Método G lobal HP. Esse conjunto integrado de metodologias é um primeiro passo para
possibilitar que a HP Services otimize a eficiência em oferecer valor aos clientes. O passo
seguinte é saber o que está disponível e aprender como e quando aplicá-lo ao que o ferece-
mos aos cl ientes.
O Nlétodo Global HP é o primeiro passo em dire.ç âo a um conjunto de metodologias
de ponta para aumentar a credibilidade como parceiro confiável, refletindo todo o conheci-
mento e experiência da HP Services. Ele também melhora nossas estruturas de custo, perso-
nalizando abordagens comprovadas predefinidas, usando as listas de verificação existentes
para garantir que todas as bases sejam cobertas, compartilhando experiências e aprendendo
a melhorar o Método Global.
A Hewlett-Packard identifica claramente sua capacidade de gestão de projetos em
suas propostas, nas quais o material a seguir costuma ser incluído.
Compromisso da HP Services com a gestão de projetos

Por que a gestão de projetos da HP Services
A HP Services considera un1a forte ge.stão de projetos como um ingrediente básico
para oferecer soluções ben1-sucedidas a nossos clientes. Nossos gerentes de projetos
são profissionais experientes com ampla e profunda experiência em soluções. Nossos
rigorosos processos empresaria is garantem sua satisfação. Um "roteiro de programa"
apresenta a arquitetura gera l do ciclo de vida do projeto enquanto a gerência sênior
da HP Services conduz revisões de progresso periódicas para garantir a qualidade.
Nossa metodologia de ponta en1 gestão de projetos combina as melhores práticas
do setor con1 a experiência da HP para ajudar a n1anter tudo sob controle. Nosso
programa de gerenciamento do conhecimento permite que os gerentes de projetos
e consu ltores em tecnologia disseminem nossa experiência por todo o mundo para
trabalhar para você.
Processos e metodologia de GP
A HP Services usa processos r igorosos para gerenciar programas. O Roteiro de Pro-
grama fornece uma arqu itetura geral do ciclo de vida do projeto. Ele inclui o processo
de Aprovação e Revisão de Soluções e Oportun idades (SOAR, Solution and Oppor-
tunity Approval and Review), que aprova novos negócios, além de conduzir revisões
de progresso da implementação de forma a garantir a qualidade e resolver problemas
com rapidez.
A metodologia de gestão de projetos da HP Services usa as melhores práticas do
setor com o va lor agregado de nossa experiência implementada por meio de tecno-
logia baseada na web para pennitir atual izações rápidas e acesso em todo o mundo.
Ela possui mais de 20 mil web pages de informações disponíveis como suporte às
nossas equipes de projeto. A metodologia inclui u1n extenso conhecimento de bancos
de dados de gerenciamento, como lições aprendidas e experiência obtida em projetos
anteriores, que nossos gerentes de projetos podem usar como auxíl io à gestão de seus
próprios projetos.
3.13 Hewlett-Packard: a jornada e os obstáculos

Quando uma empresa consegue reconhecer as forças motrizes que levam à excelência
e1n gestão de projetos e compreender que a gestão de projetos potencialmente poderia
ser necessária para a sobrevivência da empresa, boas coisas podem acontecer rapi-
da1nente para a 1nelhoria tanto da empresa quanto de seus clientes. Doug B0lz1nan,
Arquiteto Consultor, PMP®, Especial ista em !TIL® na Hewlett-Packard, descreve as
forças que afetam o sucesso da gestão de projetos e alguns dos problemas que eles
enfrentaram e superara1n. Os comentários de Doug são feitos a partir das experiências
e lições aprendidas ao implementar est ruturas e melhores práticas nos ambientes de
clientes e não são u1na reflexão da HP diretamente. Para os cl ientes, nossa organ ização
está envolvida na consultoria, estabelecitnento de estratégias, mentoria/facilitação e
atividades de treinamento pa ra implementa r uma estrutur a, processo ou ambiente e1n

seu local. Todas as nossas implementações incluem os princípios básicos de gestão de
projetos, como proferidos no G11ia PMBOK®.
Doug Bo lzman d iscute os significativos eventos emocionais que já encont rou e1n
ambientes de clientes:
• Perder participação de mercado
• Não ter conhecimento da linha de base de prazo ou o rçamento de p rojetos, se1n
saber, assim, se estão se sa indo bem ou mal
• Não ter a capacidade de velocidade de colocaç.ã o no mercado
• Compreender que há muita burocracia na organização devido à ausência de u1na
única capacidade de gestão de projetos
Doug Bolzman discute três problemas específicos que foram encontrados:
Prob/e,na 1: A gerência não sabe ou não G01npreende a hnport.ância de uma equipe de
gestão de projetos GOm pessoal em regime de tempo integral GOm treiname111.o e certifica-
ção profissio11al. Esse problema gerava vários sintomas na empresa que eram removidos
uma vez que a causa-raiz fosse eliminada. Para remover esse problema, a gerência precisa
compreender ana liticamente todos os papéis e responsabilidades realizados pela gestão de
projetos, os deliverables pro duzidos e o tempo necessário. Uma vez que se tenha compreen-
dido que esse é um esforço significativo, podem começar a orçar e pla neja r esses papéis
separadamente do trabalho que está sendo desenvolvido.
Um gerente estava co nvencido de que a eq ui pe de engenha ria não estava trabalhando
na capacidade que deveria até ser demonstrado que a q uantidade de trabalho de gestão de
projetos que eles precisavam realizar estava acima e além de suas responsabilidades relacio-
nadas à engenharia. Como o trabalh o foi distribuído a todos os engenheiros, sua produção
geral foi reduzida. O líder da eq uipe de engenh aria demonstrou as funções e o comprometi-
mento de tempo que estavam relacionados à gestão de projetos para q ue o executivo passas-
se a designar a função a um gerente de projetos com regime de tempo integral. A produção
da equipe voltou aos níveis esperados.
Problenia 2: Todos estão trabaha11do em exusso, e não há tempo para i11,ple1ne11/ar 11111a
disdpli11a de gestão de projetos. Como esse é um problema comum, o modo de contornar
essa situação é gerar um Conselho de Governança de Gestão de Projetos tático para deter-
minar os padrões, abordagens e gabaritos que serão considerados " melhores práticas" em
projetos passados e potencializados para projetos futuros. Para não amplia r o escopo o u
os riscos para os projetos existentes, elas se baseiam nos novos padrões. Q uando o termo
de abertura e a equipe de um projeto são gerados, essa equipe é treinada e " mentorada" na
nova disciplina. O Conselho de Govemança se reúne quando necessário para aprovar novas
estruturas de gestão de projetos e medir a conformidade dos gerentes de projetos.
Problema 3: Os gerentes de projetos estavam trabalha11do em um nível de maturidade mais
alt.o do que o 11ível do qual a orga11ização poderia se be11eficiar. Os gerentes de projetos
gera lmente usam todas as ferramentas e gabaritos q ue estão à sua disposição para geren-
ciar um projeto, mas são incoerentes no n ível de maturidade de negócios d o cl iente. Para
casos como esse, costuma-se dizer: "Aq uele gerente está usando 30 q uilos de gestão de
projetos para gerencia r um projeto de 10 quilos" . Se o cliente se encontra em um ambiente
instável e em constante modificação, o gerente de projetos gasta a maior parte do tempo
administrando forma lmente o gerenciamento de mudanças, ajustando todas as ferramentas
apropriadas de determinação de custos, e não leva o projeto adiante. Para remed iar essa
situação, devem-se oferecer diretrizes aos gerentes de projetos para q ue eles eq uilibrem o
nível de maturidade da gestão de projetos ao ambiente de negócios do cl iente. Isso é feito ao
trabalhar com o cliente para demonstrar como a maturidade do ambiente de negócios custa
mais tempo, dinheiro e recursos.
Em relação ao papel dos executivos d u rante a implementação da gestão de proje-

t os, Doug Bolzman coment ou:
Muitos executivos assumem um papel de "Comprom isso de Gerenciamento" ameno duran-
te a implementação, já que as implementações da gestão e da estrutura de projetos são ca-
pacidades fundamentais e não são reconhecidas como voltadas para o mercado, geradoras
de receitas ou interessantes! Normalmente, o executivo aprova um plano o rçamental baixo
no q ual a maioria dos recursos é absorvido da organização e, então, serve de palestrante
motivacional na reunião de abertura do projeto. Estive presente em uma reunião inaugura l
na semana passada na qual o patrocinador d isse à equipe que ele não esperava que o esforço
fosse bem-suced ido ou q ue mudasse a cultura presente. A equipe ficou na dúvida q uanto a
se o patrocinador estava oferecendo motivação ao instituir um desafio.
Os executivos compreendem a linguagem dos negócios e não toleram o u escutam a
falação tecnológica da gestão de projetos. Os executivos são orientados a resultados, e se
as equipes de projeto p uderem simplesmente traduzir o ambiente em termos do jargão de
negócios, criar um molde de negócios para melhorias incrementais e fornecer valor de ne-
gócios, eles se tornarão mais abertos a auxiliar. Se a expectativa é que os executivos gerem a
estratégia ou plano de melhoria, o u definam o papel da gestão de projetos dentro da orga-
nização, a implementação irá fracassar.
A ma ioria dos sucessos de implementação vem dos líderes imediatos da empresa e
dos próprios gerente de projetos q ue estão cansados do status quo e q uerem implementar
melhorias.
Um grande indicador para compreender o nível de compromentimento da gerência a n-
tes do início do projeto obtem-se pedindo ao líder para indicar em q ue formato eles q uerem
q ue a equipe documente o caso de negócio para o investimento necessário para o projeto.
Quando eles pedirem esclarecimentos, pergunte a eles q ue critérios usarão para basear sua
decisão, como por exemplo:
• Valor de negócio (melhorar o modo como o negócio geral opera, alcançando os objeti-
vos das unidades de negócios)
• Valor financeiro (decisão puramente baseada em custo e em se manter dentro de um
li mite de custo)
• Valo r de q ualidade (conformidade às exigências e padrões refletidos em uma a uditoria)
• Valo r de integração (capacidade de oferecer suporte a um modelo de entrega end-to-end
e manter os níveis operacionais)
• Valo r de cliente (indicadores de satisfação do cliente, voz das pesquisas do cl iente)
• Retorno sobre investimento (financeiramente baseado em um ponto em q ue os retornos
são maiores do que o custo)
• Maior participação de mercado
Os critérios usad os pa ra justificar a liberação d o projet o lhe d arão u m ind icador
do q ue é Íln porta nte pa ra os líderes, e d e cotn o eles oferecerão suporte ao projeto.
M uitas vezes, os critérios escolhid os não são baseados em uma d ecisão pessoal, mas
refletem os cri térios segundo os quais eles p róprios são medid os. Os critérios d o pro-
jeto podetn refletir os objetivos dos líderes para adqu irir seu p róximo bôn us, como
eficiência d e equipe, (aumento o u d iminuição do) tama nho d o quadro d e funcionários,
cresci me nt o e red uçôes nos custos.
Q uant o à cronologia d os eventos, Doug Bolzma n cont in ua:
Ao planeja r a implementação de uma estrutura, como a implementação da gestão de um
projeto, mudança ou liberação (todos usando d isciplinas da gestão de projetos), aprende-
mos que a o rganização precisa progredir com sucesso por meio de uma série de marcos or-
ganizacionais. Um exemplo é exibido na Tabela 3-7. A cronologia é similar ao que acontece
q uando uma pessoa decide q ue pre.cisa perder peso. Primeiro a pessoa toma essa decisão
devido a algum evento, como roupas q ue estão ficando apertadas, comentários de outras
pessoas o u problemas de saúde. Depois, a pessoa percebe q ue é necessária uma mudança
cultural, e se ela não estiver disposta a mudar de comportamento, não perderá peso. A pes-
TABELA 3-7 Marcos organizacionais

Marco Atividade Valor
1. Estabelecimento da Desenvolvimento da função e responsa- Implementação de estrutura de goveman-
estrutura do conse- i)jfidades de todos os participantes para ça que seja uma "melhor prática" profis-
lho de governança implementar as melhorias sional. Todos os papéis são integrados e
aprovados
2. Tarefas de O nome do patrocinador (executivo) que Executivos estabelecem prioridade por
governança desempenhará cada função, delegando meio de delegações. Todos são treinados
responsabilidade e autorização em seus papéis; determinam-se expec-
tativas
3. Geração de Os atributos descrevem os requisitos, pa- A melhoria é mensurável, não emocional.
atributos drões, capacidades e métricas que serão A equipe pode demonstrar valor em ter-
usadas para definir as melhorias e medir mos de negócios
os resultados
4. Geração de plano Planos incrementais para melhorias são O ambiente melhora com base na veloci-
de melhorias gerados com base em um modelo de dade com a qual a organização pode ar-
maturidade ou objetivos de melhoria dos car. Os planos podem ser ajustados com
negócios base em mudanças empresariais
5. Implementação Gada implementação é uma liberação do Incrementais são as melhorias realizadas.
ambiente. É medida e demonstra valor de A empresa investe incrementalmente, de-
negócio pendendo de suas necessidades
soa precisa encontrar o ;'evento emocional significativo" para ela, que justifique o descon-
forto de mudar de comportamento, como começar a fazer exercícios, não comer à noite o u
mudar os tipos de alimentos ingeridos.
Para os clientes, define-se e analisa-se uma abordagem fundamental. Muitas vezes, o
cl iente tenta tomar atalhos, mas então percebe que cada passo fornece um valor funda-
mental para a jornada ma is longa. Para um cl iente, essa abordagem foi implementada há
sete anos, a inda está em vigor, gerou nove grandes liberações de seu a mbiente de gestão de
mudanças e enfrentou cinco grandes reorganizações corporativas.
A Figura 3- 13 reflete como o cliente precisa se transformar de uma d iretoria funcional
em uma matricial para estabelecer um a estrutura comum e como os programas são, então,
medidos em relação ao seu grau de conformidade com a estrutura .
Qua nto à gestão de p rojetos ser considerada uma profissão, Doug Bolzma n
contin ua:
Com o surgimento do PMI, a maioria d as empresas começou a reconhecer a gestão de p ro-
jetos como uma profissão e desenvolveu um plano de carreira para os gerentes de projetos.
N!elhorias nesse plano de carreira ocorrem com o ponto de entrada ("agendadores" do pro-
jeto) vindo de o utras partes d o negócio e o ponto de saída (gerentes d e programa) liderando
as unidades de negócio significativas. As pessoas que deixam a "família profissional" da
gestão de projetos ainda utilizam seu conhecimento e disciplinas para estabelecer e d irigir
outras partes da empresa.
A fim de aumentar as oportunidades para as pessoas que se encontram designadas para
a função de gerente de projetos, identificamos outras funções que o gerente de projetos pode
desempenhar ao cumprir seus compromissos. Identificamos várias funções para o desen-
volvimento de serviços de TI, como o gerente de componente, como ilustrado na figura da
Estrutura de Componente. A função de gerente de componente inclui a gestão de projetos,
mas também inclui uma função de designer, como design de processos. Um funcionário
que possa desempenhar ambas as funções simultaneamente irá gerar mais valor para a
organização do que aquele que puder desempenhar apenas uma função. Essa dualidade na
designação d e funções também oferece ao gerente maior oportunidade de aplicar outras
habilidades além do gerenciamento de escopo, de recursos e de comunicação, etc. que ele já
...
u,
a,
G)
(1)
Programas da empresa
.,,o
!e
Diretoria de a.
(1)
gerenciamento 'O
Conselho
de design
de lançamentos -·ag
(1)
/
/ I
/ \
\
'
Estabelecer o "ambiente" de gerenciamento de liberações da empresa
"
a!)é ja rl.!.eJJti
b ,188
c:J c:J c:Jc:J c:J
Executar/utilizar o
ambiente de gerenciamento
de liberações de seus
projetos/programas
c:J c:Jc:Jc:Jc:J
Figura 3-13 A transformação.

desempenha rotineiramente. Essa a bo rdagem também suporta um ambiente de equilíbrio de

recursos. Se o PN!O tem funcioná rios com o utras habilidades aproveitáveis como design de
processos, design de materiais de cursos, criação de cargos, a eles podem ser delegados ou-
tros tipos de trabalhos, o q ue libera a o rganização de ter que trazer a bo rdo novos talentos.
Isso também ajuda quando há reduções no trabalho de gestão de projetos e os funcionários
podem ser realoca dos em vez de serem demitidos.
Q uando eu estava pensando e m minha carreira e surg ira m oportunidades de cresci-
mento, como ser líder de eq uipe ou de programa, escutei meu gerente e mentor que me
deu este conselho. Se você possui uma o u d uas ha bilidades nas mãos, pode começar a ser
promovido. Mas sem uma a mpla base de habilidades, seu avanço na carreira ficará seve-
ramente limitado. Se você está pensando em se tornar líder exe.c utivo ou de uma unidade
de negócios, pense em todos os desafios que eles enfrenta rão e busque agressivamente esses
tipos de ta refas para desenvolver habilidades na á rea financeira, de recuperação de desastres
ou de segurança, de modo que você possa contar com s uas experiências q uando enfrentar
desafios nessas situações. Definitivamente, ning uém deseja ter de aprender na prática depois
de ser promovido e o resultado de sua inexperiência afetar muitas pessoas e a empresa pela
qual você está encarregado. N unca me esqueci desse co nselho e vi que era exatamente o que
aco ntecia quando meus colegas subiam rapidamente em suas carreiras e, então, atingiam
um platô por esta rem cometendo erros básicos e ficando para trás po r falta de experiência .
A gestão de projetos oferece uma enorme experiência para uma pessoa em seu pla no
de carreira, já que ela toca em muitos aspectos de negócios que precisam ser forma lmen-
te gerenciados. Os gerentes de projetos ta mbém têm a o portunidade de vivencia r muitas
situações de negócios d iferentes, já q ue podem ser designados a q ualquer tipo de projeto.
Uma empresa seria sábia em gerenciar forma lmente esses tipos de habilidades, disponibili-
zar oportunidades para seu pessoal desenvolver novas habilidades e promovê-los do PMO'"
quando essas pessoas demonstrarem as habilidades para necessidades ma is desafiadoras da
empresa. Então, q ua ndo eles assumirem o coma ndo, serão mais valiosos na determinação
de uma direção para a empresa se tiverem experiência em design de processos, modelagem
de dad os, desenvolvimento de cursos o u gerenciamento de riscos, po is serão capazes de
visua lizar e comunicar sua d ireção e auxiliar na remoção de quaisquer obstáculos.
Qua nto à descrição de cargos em gestão de pro jetos, Do ug Bolzman continua:
O papel da gestão de projetos é incorporado a outros papéis funciona is de nosso modelo
de recursos. A função d o gerente de projetos faz parte de nossa descrição de cargos de ge-
rente de liberações, gerente de componentes, co ntrolado r mestre de li beração e co nsulto r de
ITSM (lnforma tion Technologr Service Management). Ganha mos novos negócios devido ao
fato de nossos Consultores de JTSM serem capazes de a rregaçar as mangas e desempenhar
funções de gestão de projetos. Vendemos nossos serviços de Consultoria em ITSM com a
advertência de q ue podemos nos prontifica r a atender as necessidades imed iatas da empresa
enqua nto definimos o a mbiente gera l juntamente com o treinamento e mentoria de seus
funcionários, para que eles possam assumir o comando. A seguir, temos um trecho da des-
c rição d e cargo de um gerente de componentes:
Lógica do agente. O gerente de componentes precisa liderar todos os recursos e a tivi-
dades relativos a qualquer modificação no design ou d ire.ç ão de um co mponente ITSM.
Descrição do agente. O gerente de co mponente gerencia todos os aspectos do compo-
nente de cada nova liberação, incluindo a ma triz de liberações, o plano, escopo, cro-
nogra ma, o rçamento, recursos e co municações de li beração. Ele trabalha diretamente
com o gerente de li beração e coordena as atividades da equipe de design, garantindo
q ue o plano de liberação seja seguido e as direções de design estejam concluídas para
implementação.
Responsabilidades gerais. Suporte ao proprietário de componente em uma capacidade
de gestão de projetos para um ou mais componente de ITSM, garantindo q ue o design
do componente esteja a tendendo às necessidades pretendidas do cliente, os direcionado-
res de negócios e as justi ficativas de negócios.
Suporte ao gerente de liberação quando o componente é incluído em um pacote

maior de componentes
Oferecer o planejamento e s upervisão para o gerenciamento e controle de tarefas de
liberação, deliverables, planos de trabalh o, orçamentos, seleção de funcionários, proble-
mas e marcos.
Estimar e gerenciar recursos e necessidades financeiras, delegar trabalho, estabelecer
prioridades e estabelecer o cronograma de liberação.
Manter o repositório do caderno de trabalhos do projeto.
Responsabilidades específicas de componentes

Descrição: Esta seção irá deta lhar as responsabilidades que o agente encontr a para
cada componente afetado .
Estratégia de serviço • Determinar os impactos específicos que uma nova liberação de TI terá
sobre seu componente em termos de processos, ferramentas e papéis e
design de treinamentos.
• Determinar as habilidades necessárias e a experiência da equipe de design
de componente para uma liberação específica.
• Liderar a equipe de design de componente ao definir os casos de teste de
componente, planos e condições de aprovação/reprovação.
Design de serviço • Liderar a equipe de design de componente ao desenvolver e testar todas as
instalações, operações ou materiais de treinamento que sejam necessários
para as equipes de implementação ou para as equipes de operações.
• Supervisionar a equipe de testes de liberação durante a validação dos de-
signs do componente.
Transição de serviço • Ofereoer suporte à equipe de transição se a instalação do componente não
estiver procedendo como o desejado no local do cliente.
Produtos do trabalho
Descrição: Esta seção irá detalhar os deliverables ou produtos do trabalho produzidos
por essa função.
Deliverable Descrição
Planos de liberação A finalidade desse documento é registrar e comunicar com precisão o esco-
po, intenção, plano e cronograma para cada versão do componente.
Inventário de compo- A finalidade de se conduzir esse inventário é forneoer as informações neces-
nentes (ferramentas e sárias para compreender o ambiente atual do componente. Esse inventário
processos) fornece um único local para identificar todos os processos, ferramentas, métri-
cas, recursos e tomadores de decisões que atualmente formam o componente.
Treinamento necessário
Descrição: Esta seção irá deta lhar os cursos específicos que são necessários para essa
função.
10 do curso Nome Descrição Local

SMLC-Aware SMLC Overview Awareness (Conscientização do pano-
rama geral do SMLC)
ITSM-library ITSM library Structure (Estrutura da biblioteca ITSM)
Capítulo 3 Jornada rumo à excelência 15 9
Acesso a ferramentas
Descrição: Esta seção irá detalhar as ferramentas às qua is essa função exigirá acesso
para cumprir suas obrigações.
Nome da ferramenta Nível de acesso
Qualificações
Todas as pessoas que assum irem as função de gerente de componente serão entrevista-
das e serão capazes de demonstrar suas qualificações para atender às necessidades da
liberação de cada versão.
• Praticante treinado e1n ciclo de vida do serviço !TIL (preferência pela certificação
da fundação ITIL - ou obtida nos t rês priineiros 1neses).
• 2-3 anos de experiência em gestão de projetos/programas ou experiência equiva-
lente em liderança de equipes ou certificação do PMI.
Habilidades
• Pessoa com automotivação e iniciativa, capaz e trabalhar sem supervisão direta.
• Forte comunicador, tanto oralmente quanto por escrito. Comunica informações
apropriadas para todos os níveis da organização. Ministra apresentações para o
nível executivo.
Essa lista é usada por diversas organizações para gerenciar as necessidades gerais
de recursos, equilíbrio de recursos e recruta1nento de recursos. Pelo fato de todas as
organizações usare1n a mesma lista, o gerenciamento de recursos se torna mais eficien-
te e preciso.
11
3.14 Cooper Standard
Melhores práticas na Cooper Standard
Bill Pumphrey (Presidente da Cooper Standard Norte-Americana e PMP®J identificou
a gestão de projetos como uma necessidade crucial para o sucesso da empresa. Iniciou
um projeto de implementação incluindo Melhores Práticas em GP. Para executar tal
projeto, contratou Dave Kandt para desenvolver uma est ratégia de Pessoas, Processos
e Est ruturas e imple1nentar a gestão de projetos na organ ização. O papel desempenha-
do por Bill era o de pat rocinador de projeto.
Dave Kandt t rouxe consigo t rês décadas de experiência e1n gestão de projetos
e e1n seu antigo cargo de vice-presidente de gestão de projetos no departamento de
melhoria contínua e qualidade na Johnson Controls. Dave tinha sido responsável pela
gestão de projetos em todos os grupos globa is de produtos e cl ientes com negócios,
insta lações e lançamentos de produtos em todas as regiões, inclu indo Europa, China,
sudeste asiático, Japão, Coreia, as Américas e regiões em expansão co1no Rússia e Tur-
quia. Ele gerenciou oito PMO nos vários grupos de produtos e clientes.
u O material sobre a Cooper Standard foi fornecido por Kriscin L. Handley, gerente sénior de recursos huma~
nos - Di,,isão da América do Norte. ©2013 by Cooper Standard. Reproduzido com permissão.
Dave tinha sido responsável por siste1nas, organização e pessoal de gestão de pro-
jetos, dentre os quais:
• O sistema JCI de Gestão de Projetos (PLUS).
• A Academia de Gestão de Projetos (The Project Management Academy).
• Contratação e p lanos de carreira em gestão de projetos.
• O Programa de Desenvolvimento de Liderança e1n Gerenciamento de Programas
(PMLDP, Program Managetnent Leadership Developtnent Program) .
• Diretrizes e procedimentos sobre projetos globais de gerenciamento.
• Avaliação de habi lidades em gestão de projetos.
• Processo de planejamento da força de trabalho para Equipes de Desenvolvimento
Simultâneo.
• Relatórios padronizados e sistema de KPI em projetos globais.
• Processo de Melhorias Contínuas em Gestão de Projetos (Excelência na Execução
de Projetos).
Elementos-chave da estratégia realizada em 2012:

1. Estabelecer o GP como um departamento separado com gerentes de projetos
sênior encarregados da gestão de projetos para as quatro unidades de negó-
cios. Isso esclareceu eficientemente que o gerente de projetos era, em última
análise, responsável pelo sucesso do projeto, dirigia as equipes de projeto e
tinha a autoridade para tomar decisões de equ ipe e orientar o comprometi-
mento das equipes com os clientes.
2. Seleção de gerentes de projetos baseada em uma ferramenta de avaliação de
habilidades por escrito que resu ltou em classificações numéricas para cada
indivíduo. Essa n1etodologia esclareceu as exigências feitas aos gerente de
projetos, que incluíam nove áreas fundamentais: Liderança/ Gerenciamen-
to de equipe de progran1as / Gerencian1ento de escopo/ Planejamento de
lançamento/ Gerenciamento financeiro/ Gerenciamento do ten1po / Co-
nhecimento sobre produtos/ Satisfação do cliente/ Habilidades de gestão
de projetos global. A última área era necessária porque n1uitos dos projetos
automotivos hoje são gerenciados e n1anufaturados em diversas regiões.
3. Modificação do processo de GP existente para simplificar e esclarecer as exi-
gências de passagens de fases baseadas nos deliverables-padrão do setor. J un-
tamente com o sistema fundamenta l de pontos de decisão de final de fase, ou-
tros padrões de gestão de projetos foram liberados globalmente, para faci litar
a natureza global do negócio, e perm itir que equipes de projeto funcionem
em diversas regiões. Adotou-se um padrão de seis pontos de decisão, como
mostra a Figura 3- 14.
1. Treinamento de toda a e1npresa em GP com focos no CLAUS (Cooper
Launch Standard). Foco especia l no alinha1nento garantido da Engenharia,
Aquisições e Operações dentro de todos os departamentos.
2. Implementação de um PMO global responsável por Pessoas, Processos, Mé-
tricas e Treinamento. Isso permitia um foco globa l para os gerentes de proje-
tos e uma organização clara.
3. Exigência de que os gerentes de projetos peguem o 1naterial de certificação
IIL PMP® e passe1n no exame de PMP®. Isso formalizava a profissão de ge-
rente de projetos na empresa.
4. Colocação das equipes de projeto, incluindo gerentes de projetos, gerentes de
conta e especial istas em engenharia e CAD. Tendo feito isso, adicionavam-se
<_bcooperStandard ~ ,au
Cooper LAUnch tandard (Padrão de lançamento da Cooper)
Fases Fase1 Fase 2 Fase3 Fase4 Fase 5 Fase 6
Envio de
Eventos protótipos Envio da produção aos clientes
do cliente aos cl~ntes
Cotação
Design e
desenvolvimento
Protótipos de
ferramentas e
Testes de
verificação
Produção de
ferramentas e
Testes de
validação do
Otimização de
produtos e Produção
..o
"D
;::;,
equipamentos do design equipamentos produto processos
-
e
o
w
Pontosde0
decisão
de final
de fase
PO
Inicio do
orçamento
0 0
Início do
programa
Liberação
do protótipo lnfclo llos testas
+0 +
Liberação para
produção
Ferramentas e
equipamentos
Processo oe
aprovação da peças Início da
produção
• Relatório
pós•lançamanto
t..
-~
o
: :,
..-
e:
nas instalaçDes de produção (PPAP)
3
o
li>'
Figura 3- 14 Padrão de lançamento da Cooper.
!ffi;
..
::,
Q.
......
a,
analistas de custos e engenheiros de processos para permitir u1na verdadeira

colaboração funciona l nas equipes de projeto.
5. Un1 foco formal na pontualidade da iniciação para futuras oportun idades de
negócios com cronogran1as organizados em blocos padronizados para garantir
o desenvolvin1ento adequado e tooling ti1ne para novos programas. Adicionou-
-se um foco significativo às futuras oportunidades de negócios n1uito antes de os
prazos e projetos se tornare1n críticos. Isso tan1bén1 pern1itia n1elhor orçamento
de recursos, despesas corporativas, investünentos de capital e carga da fábrica.
6. Formalização das funções da equipe de projetos por meio de descrições de
cargo padronizadas. Isso, juntamente com a est rutura de pontos de decisão
de final de fase CLAUS e deliverables-padrão permitia1n uma compreensão
comum de que,n era responsável por qtte deliverables e até qtte prazo em to-
das as 25 fábricas da América do Norte e ao redor do mundo.
7. implementação de revisões padronizadas do projeto por executivos e revisões
de prontidão para lançamentos gerenciadas pela equipe de operações das fá-
bricas para novos projetos. Isso aumentava o foco sobre a execução do pro-
jeto e colocava a equipe executiva bem no 1neio do processo de lançamento e
na posição de tomar decisões cruciais logo no início do projeto.
8. In1plementação de um processo de avaliação de riscos para todos os novos or-
çamentos. Isso pern1itia que a equipe executiva detern1inasse claramente as ha-
bilidades e as quantidades da equipe de projetos, além de planejar un1 suporte
especial para produtos ou processos de manufatura que apresentassem desafios.
9. !Jnplementação do termo de abertura do projeto até o ponto de decisão 1
para todos os projetos com foco nas metas financeiras, prazos, seleção da
equipe de projeto e ava liação de risco para a engenharia, 1nanufatura, quali-
dade, finanças e desempenho dos fornecedores. O elemento-chave do Tenno
de abertura do projeto era o documento final - u1n formulário-padrão de
risco e mitigação com classificações de risco vermelhas/amarelas/verdes e as
estratégias de 1n itigação exigidas por cada um deles (não havia riscos verdes,
por definição). As equipes de projeto, nessa fase do projeto, solicitaria1n um
auxílio específico da equipe executiva quando fosse necessário suporte.
10. Documentos de aprovação e controle de mudanças de escopo. Se o escopo
mudasse co1n base ou nas decisões da Cooper Standard ou nas sol icitações
do cliente, exigia-se um termo de abertura revisado com nova assinatura pela
. .
equipe executiva.
Limitar inovações no ciclo de vida para novas oportunidades de negócios.
Outras melhorias pretendidas para 2013:

1. Desenvolvünento organizacional das equipes de projeto nas 24 fábricas da
A1nérica do Norte. Isso será liderado pelo PMO com maior foco no desenvol-
vimento de ha bilidades e na colocação de 1nembros da equipe de projeto nas
operações.
2. Treinamento e1n soluções formais de problemas para todos os membros da
equipe de projetos. A Cooper Standard estabeleceu a solução de problemas
como uma parte centr al de seus processos de 1nelhorias contínuas e irá for-
malizar a abordagem globalmente.
3. Implementação de um dasbboard de GP que acompanhe mét ricas crucia is re-
lativas a prazos, finanças e satisfação do cliente. Será fornecido mensalmente
ao quadro de executivos para perm itir um foco nos prazos, no desempenho
financeiro, na qualidade e na satisfação do cliente, quando necessário.
Facilitadores
Patrocinador O mais importante facilitador dessa inicia ti va fo i o papel de Bill
Pu1npluey como patrocinador e sua extensa compreensão sobre a gestão de projetos,
resu ltado do seu PMP® e de sua experiência na área. A 1nelhor prática em destaque
aqui é a importância de o líder ter real conhecimento e experiência co1no gerente de
projetos. Não é suficiente ter u1n executivo que acredite na gestão de projetos e apoie
a iniciativa. Para que ocorra 1n rea is melhorias em um período ótimo, o líder deve ter
sido u1n gerente de projetos. Isso deveria ser um pré-requisito para presidentes e líde-
res de companhias de qualquer lugar.
Ambiente e escopo do projeto

À medida que a apreciação pela gestão de projetos cresceu na equipe executiva, tor-
nou-se mais claro que os principais direcionadores do sucesso eram as decisões toma-
das pela equipe executiva durante o processo de planeja1nento de negócios e durante o
orçamento. As principais decisões que "possibilitam o sucesso do projeto" são:
1. Te1npo adequado para executar o projeto.
2. Seleção adequada de n1en1bros de equipe con1 o conjunto certo de habilidades.
3. Seleç.ã o de fábricas para produção que tenham a capacidade e os recursos
adequados.
4. Aceitar metas financeiras dos clientes que sejam razoáveis e alcançáveis, co1n
o foco apropriado em roteiros e p lanejamento pelo gerente de projetos e pe-
las equipes e projeto.
5. Aceitar um escopo e uma dificuldade razoáveis para os produtos e processos
de manufatura, evitando inovações arriscadas ("primeira vez no setor") no
ciclo de vida de um projeto. Esse tipo de inovação deve ser (e é, na Cooper
Standard) feito em um departamento separado, onde as inovações pode1n
amadurecer e se desenvolver de maneira contr olada .
6. Seleção de fornecedores com o nível apropriado de co1npetência técnica e
manufatureira, baseada nas especificações e requerimentos do produto.
Esses parâinetr os básicos normahnente estão a lé1n do nível de auto ridade das
equipes de projeto e lhes são "dados" quando o projeto é "ganho". A equ ipe executiva
da Cooper Standard se sensibilizou quanto à necessidade de estabelecer um escopo
alcançável logo no início do projeto e evitar projetos de alto risco.
Expectativas para o futuro

Há projeções de que a Cooper Standa rd irá crescer significativa1nente entre 2013 e
2018. Espera-se que a gestão de projetos seja um direcionador para esse crescimento,
que será impulsionado por u1na melhor satisfação do cl iente resu ltante da excelên-
cia no lança1nento de novos produtos. Além disso, a Cooper Standard espera u1na
redução no custo de lançamento de novos produtos, u1na redução no capital de giro
resultante de um maior controle sobre prazos e deliverables, melhor uso dos recursos
existentes em decorrência da colocação e maior integração de nossos projetos globais
e equipes de projetos.
Em suas próprias palavras

"Nlinh a responsabilidade na Cooper é a região da América do Norte, atua lmente uma recei-
ta anual de USS 1,5 bilhão. Do meu ponto de vista, dirijo dois negócios na Cooper, ambos
no valor de US$1,5 bilhão. Um já está em produção e o outro estará em produção no futuro
(atua lmente em desenvolvimento) . Podemos tra balha r intensamente para melhorar os negó-
cios que estão em produção atua lmente, mas se não prestarmos atenção no futuro, teremos
de "conserta r" os negócios repetidas vezes. Ficou claro qua ndo comecei que tínhamos um
excelente pessoal, processos e estrutu ra para lidar com o negócio atual, mas aquele o utro,
bem, não estava tão claro. Nosso negócio futuro será ma io r do que o negócio atual - cres-
cimento é a lgo bom! Mas precisáva mos agir rápido para estar à frente da onda que estava
por vir.
Primeiro, tínhamos de melho rar os processos para q ue eles se to m assem bem cla ros em
termos de deliverables, p razos, matriz de responsabilidades RASIC, etc. - tínhamos de assu-
mir essa responsabilidade! Então, precisávamos de uma estrutura que suportasse o processo
e realçasse a importância d o gerencia mento de programas. Essa tinha de ser uma função se-
parada, reportando-se diretamente a mim. Fina lmente, precisávamos d e pessoas, as pessoas
certas, que pudéssemos treinar e posicionar para que identificas.sem e mitigassem riscos,
gerenciassem prioridades complexas, lidassem eficientemente com pessoas/clientes e nunca,
jamais temessem pedir ajuda . Ainda temos muito a fazer, mas a o rganização está vendo os
benefícios e sentindo o suporte que as pessoas, processos e estruturas podem trazer. Q ua ndo
o novo negócio fo r lançado, os custos históricos de "desperdícios" (custos de má qualidade,
fretes caros, atritos, etc.) melhorarão percepti velmente. Os cl ientes já veem o benefício e
estão começando a valorizar nossas co mpetências. Já podemos ver isso com nosso crescente
registro de ped idos. N o final das co ntas, é disso que se trata - um crescimento lucrativo que
beneficie todos nós na Cooper Standa rd Automotive."
Bill Pumphrey
Presidente da Cooper Standard, América do Norte
;, O gerencia mento de programas não é simplesmente uma ferramenta ou grupo de indiví-
d uos que se enco ntra em um departa mento funcional; em vez disso, é uma cultura que pre-
cisa ser a braçada de cima para ba ixo e alinh ada a seus clientes e forneced ores. N a Cooper
Standa rd, integramos as ferramentas de gerencia mento de programas dentro de nossa base
de suprimentos para reduzir o risco associado ao lançamento de novos programas, acelerar
o desenvolv imento de novas tecnologias e s ustenta r relações de longo prazo com fornece-
d ores estratégicos."
Ed Kiell
Diretor, Aquisição Global de Linhas de Produtos
;, O gerenciamento de programas se resume a criar um sistema eficiente dentro de um a orga-
nização que o riente as pessoas certas, falando a coisa certa na hora certa. Significa tam bém
criar um ambiente que se oriente ao sucesso em torno do que cha mo d os 4 Ps:
1. Pessoas (Peop/e)
2. Processos (Processes)
3 . Procedimentos (Proceditres)
4. Aquisições (P1trchases)"
Kevin Kreiner
Diretor, Desenvolvimento de Produtos de Engenharia
;'Como sabemos, a Cooper hoje está totalmente envolvida em um sistema de Gerencia men-
to de Progra mas que depende da 'da ta de requerimento d o programa' vers11s a Cooper do
passado, que dependia da 'data de início das vendas'. O que significa que... se nosso grupo
de vendas a inda não possui todas as a provações integra is de nossos clientes a linhadas, mas
o programa deve prosseguir para evita r a pressa depois, nossa gerência a provará que pros-
sigamos. Entretanto, as melho rias iniciais vistas são:
• O s progra mas são revisados antes do ponto de decisão 1 em reuniões mensais co m os
funcionários para garantir que a abertura do projeto esteja em dia.
• O processo de termo de a bertura impõe a necessidade de compreender o progra ma do
início ao fim. Dados detalhados do prazo, datas de passagens de fases, recursos da eq ui-
pe, finanças são anota dos e riscos são identifica dos.
• O envolvimento da gerênc ia é a chave para remover os o bstácul os e ma nter os pro -
gramas no caminho certo. Isso é visto semanalmente em reuniões de assuntos cruciais,
mensalmente em revisões executivas e trimestralmente nas revisões de pro ntidão de

lançamento na fábrica.
Essas ações atLxiliarão nossas equipes a cumprir os compromissos assumidos no termo
de abertura e aumentarão muito o sucesso do programa."
C huck Eisel
Gerente sênior, Gerenciamento de Programas
12
3.15 Naviair: dentro do prazo, dentro do orçamento
Como fazer de programas grandes e complexos um sucesso
Reconhecer o cenário
A provisão de serviços de navegação aérea na Europa é un1 dos últimos segn1entos do
mercado que não foi libera lizado em grande n1edida. A navegação aérea é - à exceção
da área da torre - ainda mn monopólio para os seus 37 provedores de serviços, e como
Siin1 Kallas, Vice-Presidente da Con1issão Europeia expressou em seu discurso inaugural
na conferência Single European Sky - the time for action (Um Único Céu Eu ropeu - é
hora de agir ), em Limassol en1 10 de outubro de 2012: "Estamos indo em direção a um
ambiente regu latório n1ais simples, coerente e baseado e1n un1a econom ia de n1ercado".
Em paralelo, esse setor é fortemente regulado da mesma maneira que os setores
ferroviário e médico. Novas demandas surgem à medida que as regulamentações da
União Europeia (UE), legislações nacionais e novos ou atualizados padrões da ICAO
(International Civil Aviation Organization) são continuamente Ílnplementados co1n
prazos rígidos a serem cumpridos. Investimentos significativos são fei tos a fi 1n de
a tender às exigências regulatórias. Ao 1nesmo tempo, o tráfego está estagnando e até
mesmo diminuindo no espaço aéreo dinamarquês devido ao 5° ano consecutivo de
recessão divulgado no primeiro trimestre de 2013. Isto é, há recursos limitados dispo-
níveis, a pa rtir do ponto de vista de um provedor de serviços, para atender a natureza
complexa e exigente do setor de aviação.
Com base no crescente nún1ero de regulan1entações da UE fornecidas pela Co1nissão
Europeia, há uma expectativa de que a provisão de serviços de navegação aérea na Eu -
ropa desenvolva maneiras n1ais eficientes de rea lizar o controle do tráfego aéreo. Nesse
contexto, a Naviair fonnou un1a cooperação chamada COOPANS com os provedores
de serviços de navegação aérea sueco, irlandês, austríaco e croata e o fornecedor francês
Thales. Essa cooperação con1partilha os custos e recursos necessários para o desenvol-
vimento, a Ílnplen1entação e a n1anutenç.ão de mn Siste1na de Gerenciamento de Tráfego
Aéreo (ATM, Air Traffic Management), que está em conforn1idade com as regulamenta-
ções existentes e futuras da UE. Até agora, o progra1na COOPANS foi n1uito be1n-suce-
dido e hoje está em operação en1 quatro países e e1n seis centrais de controle de tráfego
aéreo. A sétima central de controle, localizada em Zagreb, entrou em operação em 2014.
Nesse cenári o, há uma forte necessidade de sucesso. Recursos escassos e pressões
externas tornam esse empreendimento desafiador. Entretanto, quando o comparamos
a out ros segmentos de mercado similares, ficamos orgu lhosos de quão bem -suced idos
fomos ao rea liza r nossos programas e projetos. Não há espaço para fracassos, e na
Naviair atingimos uma taxa de quase 100% no que diz respeito a entregas dentro do
prazo - e dentro do orçamento.
12
©2013 by Na via ir. Reproduzido com permissão. Todos os direitos reservados. O material sobre a Naviair
foi fornecido por Jvlikael Ericsson, diretor de projetos de AT~l e Engenharia, Steen MyhreTaschner Erichsen,
diretor/escritório de gestão de projetos, projetos de AT~l e Engenharia (bacharel em engenharia elécrica) e
Michael \-Vibelius, gerência tática (mestre em planejamento e gerenciamento).
Figura 3- 15 Como fazer de programas grandes e complexos um sucesso.
A capacidade da Naviair de lidar com o cenário e, ao mesmo tempo, entregar seus

serviços dentro do prazo e do orça1nento baseia-se em seis p rincípios essenciais (ver
Figura 3- 16):
• Estabelecer confiança
• Planejar o sucesso
• Gerenciar o desempenho e a cultura
• Adaptar processos
• Organizar e produzir relatórios
• Comunicar-se com todos
Con10 os princípios essenciais não são estritan1ente inter-relacionados e con10 o
sucesso não necessariamente depende de uma implementação integral de cada un1 dos
princípios, o nível do usuário dos princípios pode ser adaptado à organ ização em ques-
tão, já que a lguns parâmetros pode1n ser 1na is úteis en1 algumas organizações do que
e1n outras. Portanto, a gerência sênior e os gerentes de projetos/progra 1nas especifica-
1nente (já que eles são os leitores-alvo deste ensaio) estão livres para escolher as ideias
contidas na descrição de e.ada um dos princípios. No entanto, deve-se ter e1n n1ente que
se recomenda maximizar o uso de cada um dos princípios, con10 descrito neste ensaio.
Estabelecer confiança
O gerenciamento de mudanças muitas vezes não é priorizado ou não é levado em
consideração ao se realiza r um programa de grande porte. Muitas empresas já tiveram
experiências negativas com projetos anteriores e, portanto, a gerência simples1nente
não espera que suas organizações internas sejam capazes de dirigir um programa de
grande porte se1n grandes problemas. Na Dinamarca, análises de projetos de TI rea li-
zadas pelo governo revelaram que 75 % dos projetos não era entregue no prazo. Além
d isso, uma quantidade significativa dos projetos ultr apassava o orçamento, e 40 %
deles tiveram gastos muito acima do orçado.
ESlabelecer
confiança
Comunicar-se Planejar
com todos o sucesso
Reconhecer
o ceMrlo
Organizar e Gerenciar o
desempenho
produzir relatórios
e a cultura
Adaptar
processos
Figura 3- 16 Estrutura: dentro do prazo - dentro do orçamento (Naviair).
Quando um progra tna é iniciado na Na via ir, começa1nos garantindo que a organi-
zação se ocupe das mudanças que estão por vir. Perguntas sobre por que as mudanças
são necessárias são bem-vindas, além de discussões relativas a a lternativas. Isso auxilia
na destnistificação das mudanças na organização e é um importante passo inicial no
sentido de evitar que seja necessário investir tempo nisso em uma fase posterior, quan-
do as coisas não se possam mais ser mudadas ou quando as mudanças sejam acotnpa-
nhadas de grandes dificuldades e/ou despesas.
O tom deve ser encontrado, ao mesmo tempo em que se reconhece o fato de que
as dificuldades podem ser apontadas por pessoas com diferentes experiências e inte-
resses. Nesse contexto, é importante evitar reagir proa tiva mente e perm itir que grupos
com diferentes profissões expressem suas opiniões. Nossa experiência mostra que isso
torna o processo de mudança mais suave e pennite utn refinamento da direção a ser
tomada, a fi ,n de m itigar d iferentes riscos que, caso contrário, poderiam se transfor-
mar em proble1nas. Você deve se certificar de ouvir todas as partes da organização e
chegar a um consenso, mestno que ele mude um pouco o escopo. É muito fácil mudar
o escopo nessa fase em comparação a fazê-lo em fases posteriores do programa/pro-
jeto. A fim de garantir que todas as partes interessadas internas envolvidas tenham a
mesma compreensão das mudanças, a prÍtneira coisa a ser feita, antes que qualquer
pré-investigação do projeto seja realizada, é chegar a um acordo quanto a u1na estrutu-
ra de alto nível do projeto que forme os principa is benefícios e objetivos mensuráveis.
A estrutura de governança também precisa permitir que as diferentes partes in-
teressadas discutam e obtenham o nível apropriado de informação durante todas as
fases do programa/projeto. A Naviair realizou um programa muito grande contendo

mais de 50 projetos inter-relacionados que entraram em operação no fina l de 2007,
e levou a um sistema de gerenciamento de t ráfego aéreo cotnpletamente novo na Di-
na tnarca. A responsabilidade por integrar todas as soluções técnicas de muitos for-
necedores diferentes foi colocada em nossas mãos. Embora os desafios tecnológicos
tenham sido enormes, a gestão de mudanças fo i a inda maior. Na verdade, é um desafio
mental levar ad iante um p rograma desses se você espera bater as metas "na 1nosca" .
A Naviair conseguiu, mas tivemos de investir 1nuito tempo e preocupações a fim de
implementar essa estrutura de govemança e de garantir que todas as partes interessa-
das, tanto internas quanto externas, fossem envolvidas. Tivetnos também de realizar
pesqu isas periód icas para garantir que todos estivessem apoiando as 1nudanças e, às
vezes, certos grupos tinham preocupações que tinham de ser abordadas imediatamen-
te. O mantra nesse contexto é que essas preocupações são muito úteis no processo de
toma r o programa bem-sucedido. Nunca tentamos nos defender, ou fazer os comentá-
rios difíceis desaparecerem, e hoje isso se tornou uma prática permanente na Navia ir.
Planejar o sucesso
Uma regra básica na Naviair é definir un1a data par a colocar o novo sistema en1
operação o mais rápido possível. Se possível, determinamos até mesmo uma hora
exata; no progran1a n1encionado acima, tín hamos tambén1 un1 relógio de contagen1
regressiva na página in icial da intranet da Naviair. É muito mais fácil se você ten1
coragen1 de definir un1a meta visível para a organ ização. O perigo, porém, é que a
data não pode ser mudada. Um jogador de tênis profissional como Roger Federer
não pensa en1 um possível fracasso quando entra na quadra, e você tem de fazer o
mesmo: ser profissional todos os d ias com um ún ico foco - estar dentro do prazo e
dentro do orçamento.
Se você conseguir fazer sua organização concordar com essa data, que é uma
meta alcançável, pode começa r a planeja r retroativamente. Se possui uma abordagem
determ inada por pontos de decisão de final de fase, o que é fortemente recomendá-
vel, você e suas equipes ficarão imed iatamente muito ocupados, 1nesmo que seja um
p rograma de vários anos de duração. Você deve sempre se lembrar de que, no início,
o prazo é uma estimativa qualificada. O cronogra tna irá melhorar gradualmente e
se tornar ma is deta lhado à medida que o progra tna for progredindo. Um gerente de
programa que é capaz de seguir o cronograma tetn muito a ganhar, e todo o trabalho
relacionado à revisão do cronograma é evitado. Quando o programa estiver pronto, o
cronograma será utn plano perfeito. Ent retanto, você nunca deve usar esse a rgumento
pa ra se enganar, adiando o planeja tnento. Contanto que a data operacional não mude,
os marcos podem ser ajustados, se necessário, o que geralmente ocorre com a maioria
dos programas.
O resu ltado esperado de atividades posteriores como verificação e validação,
t reinan1ento ou testes en1 tempo real devem ser abordados logo de início. Se sua
organ ização não estiver madura, muito provavelmente ela irá, por exen1p lo, argu-
menta r que o teinamento não pode ser planejado antes de o sistema esta r fisicamente
en1 operação. Esses a rgun1entos devem ser levados a sério devido ao fato de que eles
expressan1 que as partes interessadas não saben1 como proceder nessa fase inicial
do progran1a . Uma vez que as d iferentes partes da o rganização tenhan1 aprendido a
abordar os tópicos no nível certo, o t rabalho pode ser iniciado cedo, e as n1etas po-
den1 ser atingidas. Men1bros inexperientes do programa precisam receber o suporte
de un1 PMO ou simi lar, a fin1 de aprenderem con10 p lanejar as atividades antes de
entrar no modo de solução .
Você deve co1nunicar o plano em sua estrutura de governança repetidas vezes. A

chave para o sucesso é obter adesão de todas as partes interessadas, e alguns fatos têtn
de ser muito bem explicados. Ao mestno tempo, todos os fóruns devem ser levados etn
consideração, como no princípio "Estabelecer confiança" descrito acima. Diferentes
partes da governança devem ser abordadas no nível certo, e algumas pa rtes interessa-
das externas podem ficar satisfeitas com a data de entrada em operação se não foretn
afetadas por seus testes, etc.
Uma das ma is importantes mensagens da Naviair é nunca operar com um plano
B que inclua uma data a lternativa para o sistema entrar etn operação. Você é autori-
zado e aconselhado a implementar ações de mitigação em relação ao r isco de perder a
"Data X", por exetnplo, ter um plano bem testado de recuperação de dados e outros
planos de ação similares. Entretanto, apenas utn plano deve estar disponível, e a gerên-
cia e as partes interessadas internas teriam que concordar cotn esse plano e comunicar
o seguite: nós conseguiremos!
Gerenciar o desempenho e a cultura

Un1a equipe não é automaticamente mais forte do que os indivíduos, n1as com uma cul-
tura de equipe de a lto desempenho, o resu ltado pode ser fantástico. Um n1étodo con1um
usado por equipes esportivas, forças especiais ou outras equipes sin1i lares raran1ente é
usado em gerenciamento de programas. Quando uma equipe da SWAT (Special Wea-
pons And Tactics) é reunida pela primeira vez ou quando a equipe muda, eles normal-
mente passam onze semanas conhecendo uns aos outros. Nesse 1non1ento, a tarefa a ser
solucionada ainda nem está nos planos. Qual é, então, a finalidade de tal evento social?
Quando un1a tarefa é real izada pela equipe da SWAT, os participantes são total -
mente dependentes uns dos outros. A fi ,n de poderen1 confiar uns nos outros 100%, é
preciso 1nuito n1ais do que apenas alguns profissionais individuais: é preciso conhecer
também as pessoas por trás dos profissionais, os fatores sociais e partes de suas histó -
rias. Em u1na equipe da S\VAT, você está prestes a colocar sua vida nas ,nãos de u1na
outra pessoa, e isso não funcionaria com un1 completo estranho. O n1esmo va lor para
utn progratna desafiador que pode afetar o seu sono, sua vida fan1i liar e suas atividades
de lazeL Quando utn progran1a chega ao fi ,n cotn sucesso, a n1aioria dos participantes
diria o n1esn10: "foi un1 trabalho difícil, n1as uma experiência para a vida toda!" .
Porque Porque
Explicar, Estimular
discutir
Quem Uaul
Equipe de alto
Construir desempenho
confiança
(HPT)
Quem
O que Gerar
Escopo Como
Organização, resultados
termos de
referênci
Figura 3-17 Equipes de alto desempenho.

O processo de construi r u1na equipe de alto desen1penho, como n1ostra a Figu ra

3- 17, deve começar con1 a interação social em um ambiente protegido da interferência
d iária do escritório ou da fáb rica. Nesse an1biente, o primeiro passo seria perguntar:
Por que esta mudança? Ao mes1no ten1po, os men1bros da equ ipe devem se famil izarizar
uns com os outros. Muitos diferentes métodos poderian1 ser usados ao socializar; un1
dos n1étodos usados na Naviair é pedir a cada participante para trazer um item pessoal
muito in1portante e fazer um discurso sobre ele. Você descobrirá novos lados de seus co-
legas que você nen1 imaginava que existiam. Agora você se encontra no segundo passo,
chamado de Quem. Nessa fase, você construirá a confiança entre os n1embros de equipe.
Permaneça no passo 1 e/ou 2 o máximo que puder, pelo menos durante um se-
minário e u1na reunião de segu imento. Agora você pode passar para o passo 3, que é
O que. Nesse passo, você determina o escopo das 1nudanças e da tarefa. Esse passo e
o passo 4: Como, são fáceis para uma organização de progra1na em que você tenha
esta belecido governança, termos de referência, etc. Na ma ioria das organizações, O
que e Como são os pontos de partida. Usa r O que e Con10 funciona, mas gera apenas
um desempenho medíocre. Se você começa r no passo 3 ou 4, o processo não pode ser
revertido devido ao fato de ser 1nuito difícil para a 1naioria das pessoas (pelo menos
duas e1n sua equipe) sair do "modo solução" após iniciá-lo.
O passo seguinte é começar a t rabalhar com seu escopo e sua equipe e, se você
começou da maneira certa, é mu ito provável que experimenta rá o passo Uau, no qual
a equipe está tendo um alto desempenho. Esse desempenho deve ser mantido de modo
que o último passo repi ta o primeiro passo, Por que, pelo qual você precisa passar pelo
menos uma vez por ano ou imediata1nente depois de ter substi tuído um de seus mem-
bros de equipe. Se você substituir um de seus me1nbros de equipe, terá, por definição,
u1na nova equipe, então não seja levado a acreditar erroneamente que u1na cultura de
a lto desempenho continua rá para sempre.
Em equipes 1nulticultura is, como a 1naioria das equipe de hoje em dia é, você,
como gerente de programa, precisa ter habi lidades relativas a d iferenças cuturais. Cer-
to conheci1nento em relação aos países de origem, sua história, religião, cená rio polí-
tico e cultural (p. ex.: uma cu ltura dominada por homens ou mulheres) possibilitará
u1na construção de equipe bem-sucedida e o ajudará a alcançar uma equipe de alto
dese1npen ho (HPT, high performance team).
Adaptar processos
A posição de gerente de programa é como "estar ent re a cruz e a espada" . Em bora
você esteja no topo de sua própria governança, você tem pessoas demais e instâncias
dema is com as qua is se relacionar. Você tem de lida r com o ambiente à medida que o
programa progride. Sua meta será afetada econo1nicamente, tecnologicamente e por
flutuações do mercado, mas gerahnente seu progr a1na ta 1nbém pode ser afetado politi-
ca1nente devido à cooperação ou alianças das quais ele pode fazer parte. Esses fatores
podem conferir maior co1nplexidade ao progra 1na.
O modelo de projeto da Naviair, que contém os processos de projeto e os templa-
tes que são usados para in icia r, executa r, entregar e concluir projetos, baseia-se nos
princípios PRINCE2 (PRojects IN Controlled Environments). No entanto, ele é adap-
tado à disposição, natureza e cenário organizacional de nossos projetos. Co1no tal, o
modelo de projeto da Navia ir é pragmático em sua natureza, com um fluxo documen-
tal ági l e uma est rutura de fases simples, com uma decisão muito clara (continuar/não
continuar) a ser tomada pelo grupo de liderança (favor consultar o princípio "Orga-
nizar e produzir relatórios") ent re duas fases. Os processos do projeto são claramente
ligados aos processos circundantes da empresa, co1no o processo orçamentário anual,
procedi1nentos de manutenção, etc.
O n1odelo de projeto da Naviair focaliza-se nas fases iniciais, a fi 1n de garantir que

o projeto seja justificável e que a decisão certa seja tomada em relação às especificações
de produto e ao escopo do programa/projeto antes de prossegui r para a fase de execu-
ção. A fase de iniciação do projeto baseia-se em uma estrutura de alto nível, compilada
pelo proprietário do projeto, formando a principal referência do programa/projeto co1n
objetivos declarados claramente n1ensuráveis. O gerente de projetos é designado para
a aná lise de possíveis soluções - se houver - dentro do escopo da estrutura do projeto.
Nesse contexto, e como u1n passo final das fases iniciais, o gerente de projetos faz uma
ava liação relativamente deta lhada, contendo estiinativas relativas a orçan1ento, recur-
sos, prazos, principais riscos, etc. para formar a base de un1a so lução recomendável.
Com base nessa análise, o grupo de lideranç.a decide se o projeto deve ou não continuar
na fase de execução, em que o progresso é continuan1ente monitorado (favor consultar
o princípio "Organizar e produzir relatórios" ). Se o projeto não for 1nais justificável,
ele pode ser cancelado a qualquer 1non1ento durante o seu ciclo de vida. Un1a vez que
os deliveries do projeto estejan1 concluídos, a fase de entrega do projeto é realizada
antes da fase de conclusão proprian1ente dita e de lições aprendidas ser iniciada. Esta
última fase abre espaço para o con1partilhan1ento de conheci1nento e rea lização de be-
nefícios que, por sua vez, poden1 levar ao início de um novo projeto. Essa abordage1n
tem sido 1nuito bem-sucedida, co1n u1n histórico 1nuito bom de entregas dentro do
prazo e do orça1nento con1 cada investin1ento feito e1n todo o processo.
A fase de realização do projeto é uma fase ágil, co1n foco no monitoramento do
progresso e na mitigação de riscos e problemas.
A priorização de porúólio é rea lizada de acordo com os padrões de priorização
da Naviair, que foram implementados para garantir que só realizemos programas e
projetos que apoiem e fortaleça1n nossos valores de negócio.
Organizar e produzir relatórios

Sua governança é muito importante, e uma regra básica é loca lizar o patrocínio em
camadas bem altas da o rganização. Essa pessoa deve ser um membro da gerência
executiva e do lado do va lor de negócio, como o COO ( Chie( Operating Officer)
ou o CEO (Chie( Executive Officer) . Se o patrocínio ficar nas mãos do CFO (Chie(
Financial Officer) ou do CTO (Chie(Technology Officer), normahnente ele trará u1n
outro tipo de foco ao programa, um foco muito fo rte ou no lado financeiro, ou no
lado tecnológico.
O pat rocinador deve ser o presidente do grupo de liderança do programa, que deve
ser con1posto por representantes da gerência de cada un1a das principais áreas organi-
zacionais, a fim de verificar se as decisões concernentes à priorização e as n1udanças de
fase do programa/projeto são holísticas e estão a linhadas dentro de toda a organização.
O grupo de liderança do programa deve se encont rar periodicamente. A frequência
das suas reuniões depende muito do programa, n1as pode ser un1a vantagen1 se reunir
mais frequente1nente quando a data do início da operação estiver se aproxin1ando. Se
sua configuração organizacional pern1 itir a fo nnação de um grupo de liderança para
todos os progran1as e projetos, isso seria vantajoso, pois você poderia priorizar todo o
portfólio de u1na vez só e, assim, se beneficiar de u1na visão holística.
U1n programa complexo deve ser composto com o suporte de seu próprio pessoal
administ rativo e de planejamento. Richard Branson, e1npresário e fundador da marca
Virgin, declarou: "Prefiro u1n assistente brilhante". Temos a mes1na opinião quanto ao
progra1na mais complexo da Naviair, o COOPANS; temos essa o rganização e suporte.
Os subgrupos da organização do programa deve1n ser equili brados de tal maneira
que reflitam as diferentes partes interessadas internas de forma positiva e que seja1n
equipados com co1npetências suficientes para tomar as decisões relacionadas à sua

área de especia lização a fim de garantir o progresso. As partes interessadas externas
podem fazer pa rte da organização, mas é mais provável que elas sejam parte de um
grupo de interesse ou de um grupo de usuários. Não é importante que tipo de sub-
grupos você define, mas como os subgrupos interagem uns com os outros e com você
como gerente de programas.
Na Naviair, preferimos uma visão pragmática da produção de relatórios. Nosso
template usado para relatório de status é feito como uma simples ferramenta do Excel
e se baseia nos tr adicionais relatórios de semáforos. O relatório p ropriamente dito
consiste em seis parâmetros, e alguns deles representam KP!s de negócios ligados aos
indicadores ba lanceados de desempenho geral da Navia ir. Dependendo da comple-
x idade do portfó lio, a frequência dos relatórios varia de uma vez por semana a uma
vez por mês. O mais importante, porém, não é o status atua l de seus se1náforos. Isso
é coisa do passado, com informações antigas. Os riscos e problemas do programa e a
proatividade para 1nitigá-los são muito mais importantes. Se você possui u1n portfólio
grande com muitos programas e projetos, você precisará de ferramentas e de um ge-
renciamento de riscos mais complexos. Na Navia ir, usamos ferramentas pragmáticas
de gerenciamento de risco, gerentes experientes e certificados e muitas reuniões físicas
pa ra interagir em relação aos riscos e problemas. Se você guarda suas experiências e
já realizou muitos projetos antes, pode usar seu instinto para decidir quando usar seus
esforços. Portanto, priorizamos reuniões, discussões e interações físicas individuais em
vez de u1n amplo uso de relatórios.
Na Naviair, aprendemos que é 1nuito difícil para uma organização decidir se os
resultados de um programa são ou não satisfatórios. Muitas vezes, uma organiza-
ção fica um pouco instável e excessiva1nente orientada a deta lhes antes de finalmente
colocar um novo sistema e1n operação - o que gera lmente gera atrasos. Na Navia ir,
desenvolve1nos uma mat riz de critérios de aceitação para decidir se um programa é
satisfatório para ser colocado em operação. Temos dois níveis: u1n com marcos deta-
lhados e descrições por critério e um nível de grupo de liderança que pode fazer um
relatório rápido e1n uma apresentação de Pov,rerPoint de dois slides. Quando todos os
critérios são atendidos, estamos prontos para entr ar em operaç.ã o . Não há chateações
ou discussões quanto a se estamos prontos ou não.
Comunicar-se com todos

Não se consegue real izar uma comunicação bem-sucedida concernente a um pro-
grama sem um plano de comunicação. O p lano de comunicação deve se basea r en1
uma análise das pa rtes interessadas, uma análise S\VOT e/ou a lgun1a anál ise simi lar
pa ra obter um quadro claro do público-alvo e de con10 ele pode reagir a certas decla-
rações. O plano de comun icação baseado nas análises n1encionadas fornecerá un1a
con1unicação mais d irecionada, o que, no final das contas, garantirá que você alcan-
ce o resu ltado que estava procurando. Você deve considerar qualquer meio possível,
alén1 da frequência e da hora certa para abordar as diferentes partes interessadas
internas e externas, e em que nível de informação. A mensagen1 principal deve ser
clara, consistente e fácil de compreender e de se identificar ao abordar as diferentes
partes interessadas. Use con10 exemplo proen1inente os grandes produtores de bebi-
das, carros ou empresas de prestação de serviços e como elas comun icam os valores
de seus produtos. Você deve aborda r seus valores de negócio, e não as vantagens
tecnológicas que, para a n1a ioria das pessoas, são inúteis e só parecen1 encarecer o
p roduto. Você deve repetir os valores de negócio e mensagens centra is até o progra-
ma ter sido executado.
Você pode direcionar sua comunicação aos diferentes fóruns de n1uitas maneiras e
não deve se limitar ao uso exclusivo de ferramentas de comunicação tradicionais. Um
gerente de programa be1n -sucedido terá de usar quase a metade de seu horário de traba-
lho para fazer co1nun icações e lobby, a fim de garantir o sucesso de seu programa. Um
gerente de programa que prioriza a comunicação corretamente nunca se recusa un1a pos-
sibilidade de apresentar seu programa e os valores de negócio a ele relacionados.
É uma boa prática de co1nun icação enviar artigos para publ icação en1 revistas, de-
finir un1 portal do projeto ao qual a organização interna tenha acesso, publicar notícias
tanto na internet quanto na intranet, organizar reuniões inaugurais e eventos de "portas
abertas" e, é claro, propiciar apresentações físicas sempre que houver possibil idade. Um
dos segredos da comunicação eficiente é variar os meios de con1t1nicação e encontrar
novas maneiras criativas de abordar as partes interessadas, como, por exemplo, dis-
posições para mercadores em que a n1ensagem central seja exibida, envolver a cantina,
transm itir entrevistas con1 pessoas in1portantes para o programa/projeto pelo porta l de
notícias ou colocar banners con1 as mensagens centrais en1 locais frequenten1ente visi -
tados, con10, por exen1plo, ao lado da máquina de café. Essa última ideia possi bilita um
formato mais informal de comunicação, já que a 1náqu ina de café e/ou locais sin1i lares
represen tam " zonas seguras", onde a con11111 icação flui livremente entre os funcioná-
rios. Um banner con1 un1a mensagen1 positiva pode levar a conversa en1 un1a direção
mais positiva ou sin1plesmente dar mais visibil idade à n1ensagen1 entre os funcionários.
Fonnatos de comunicação n1ais informais têm sido util izados com sucesso na Naviair.
Un1 exen1plo, entre n1uitos outros, é o café da manhã sen1ana l pro1novido pelo gerente
de projetos às sextas-feiras, no qual os funcionários se reúnem e discutem o progresso
do programa/projeto, enquanto desfrutam de deliciosos doces folhados e un1a xícara de
café/chá. Con10 nenhun1 gerente de a lto nível está presente nessas reuniões, preocupa-
ções e informações que, caso contrário não serian1 discutidas podem ser compartilhadas.
O mesmo ocorre e1n relação a run1ores que o gerente de projetos terá a oportunidade
de identificar e reagir a fin1 de evitar que o progresso e valores de negócio importantes
do programa/projeto sejan1 solapados. O gerente de projetos pode dar segu in1ento às
reun iões de café da manhã com u1n e-ma il informal de status para n1anter as pessoas
que não estavam presentes atualizadas sobre o progran1a/projeto e convidá-las a fazer
comentários, se tiverem qualquer informação extra ou contraditória.
A falta de comunicação e de informação faz as pessoas desenvolvere1n suas pró-
prias informações quando se encont ram na máquina de café. Isso gera preocupações
e ru1nores que precisam ser tratados seriamente, já que podem assumir a qualidade
de fatos. A cura simples para esse problema é atacar todos os rumores assim que são
ouvidos, e eles devem ser questionados para verificar se há algum fato por trás deles.
Geralmente não há fatos que confirmem rumores correntes. Ent retanto, se eles fore1n
baseados em fatos, uma solução precisa ser encontrada.
Você não deve se esquecer de celebrar qualquer marco importante que tenha sido
alcançado. Celebre de maneira aceitável e co1npatível com a cultura da empresa. A
cultura de algumas empresas não vê nenhu1n problema e1n oferecer jantares gratuitos
ou ingressos para a ópera enquanto a de outras não aceita isso por motivos fiscais ou
simplesmente porque "não é assim que deveria ser". Dar de presente um carrinho de
corrida não muito caro por u1n teste de aceitação aprovado pode ser uma forma de de-
monstrar gratidão por parte da organização. Na Naviair, reinos gerentes de progra1nas
que têin lindas coleções de Ferraris e Lamborghinis que são orgu lhosamente exibidas
em loca is muito visíveis de seus escritórios.
A coisa mais importante e eficiente que você poderia fazer em relação a projetos é
elogiar, dar créd ito e reconhecimento à equipe envolvida. O reconhecimento mais forte
que você poderia dar é comunicar a uma pessoa de um outro departa1nento.
Resumo
Os seis princípios essenciais apresentados aqui são continuamente refinados de acor-
do co1n lições aprendidas, informações externas e à medida que o setor de provisão
de serviços de navegação aérea na Europa se desenvolve, de modo a maxim izar o
dese1npen ho dos projetos da Navia ir e a capacidade de ent regar dentro do prazo e do
o rçamento. A mensagem central é que temos de reconhecer o cenário e nos adaptar a
ele e perceber que estamos vivendo em um inundo dinâmico - não importa quão boas
suas 1nelhores práticas possam ser, elas podem se tornar coisa do passado se não seco-
locar o foco no desenvolvimento contínuo com uma disposição a mudar e se adaptar.
Fina lmente, como o finado dramaturgo irlandês, o socia lista e cofundador da London
School of Econo1nics, George Berna rd Sha,v, disse: "Quem não consegue mudar de
ideia, não consegue mudar coisa alguma".
3.16 DTE Energy

Há vários modelos de 1naturidade disponíveis no mercado para auxiliar as e1npresas
em sua busca por crescimento, excelência e sucesso em gestão de projetos. A Tabela
1-1 do Capítulo I é u1n deles. A final idade do modelo é simplesmente fornecer algum
tipo de estrutur a pa ra o processo de maturidade. Tim Menke, PMP®, especia lista sê-
nior em melhorias contínuas no gerenciamento de desempenho de operações de distri-
buição, descreve o p rocesso de cresci1nento na DTE Energy:
A DTE Energy abraça a gestão de projetos para conseguir entregar produtos e serviços de alta
qualidade eficientemente e dentro do prazo para nossos diversificados clientes de serviços de
utilidade pública. Nossa aplicação de gestão de projetos a esforços de engenharia e construção
data de décadas atrás. A expansão da gestão de projetos para outras áreas além da de grandes
projetos tem aumentado nos últimos anos. Por exemplo, nossa organização de Tecnologia de
Informação in iciou um esforço formal para aumentar a maturidade em gestão de projetos
no ano 2000. O domínio individual de habilidades era incentivado por meio de treinamento,
experiências práticas e certificação formal. Criaram-se códigos de cargos e um modelo de pro-
gressão de ca rreira . Simultaneamente, estabeleceu-se um grupo multifuncional representando
todas as áreas da TI para gerenciar o portfólio de projetos dessa área. Com o passar do tempo,
outros departamentos migraram para um modelo sim ilar, que incluía o uso de códigos formais
de ca rgos e planos de progressão de carreira em um esforço para a umentar o controle de seus
pro1etos.
O foco em gestão de projetos continua em nossa empresa. Por exemplo, recentemente
criamos um novo departamento - Grandes Projetos Empresariais - liderado por um vice-
-presidente sênior q ue se reportava d iretamente ao CEO. Esse departamento foi criado para
s upervisionar os grandes projetos e suas interações. Um exemplo desses projetos é a possível
construção de um Gerador de Energia N uclear.
Nossa motivação para aumentar a maturidade em gestão de projetos antes era impulsio-
nada internamente (Remediação de TI no ano 2000, fusão com a MichCon, Implementação do
Sistema de Planejamento de Recursos Empresariais, Certificação em CNlMl, etc). Entretanto, a
recente onda de choque econômico sentida tanto nacional quanto internacionalmente ressoou
a lto no sudeste do Michigan. Estamos usando a melhoria contínua Seis Sigma enxuta para
eliminar o desperdício de nossos proce.~sos e agilizar a inda mais nossas operações. A gestão de
projetos é crucial para fazer nossos projetos de melhorias contínuas concretizarem-se rápida e
eficientemente. Re,•isamos nossa metodologia de Melhorias Continuas na Gestão de Projetos,
passando a incluir um mecanismo de feedback que permita que deixemos projetos em sus-
penso ou os cancelemos sem perdê-los de vista no futuro (Fases de Identificação de Projeto e
de Seleção de Projeto). Providenciamos a expansibilidade em nossa abordagem reconhecendo
uma variedade de tipos de projetos e seus requerimentos correspondentes. Todos esses esforços
foram defendidos por níveis sênior da liderança da DTE Energy.
3.17 Key Plastics

A jornada rumo à excelência norma lmente co1neça com a criação de uma gestão de
projetos decomposta de acordo com fases do ciclo de vida. As metodologias e as fases
do ciclo de vida não precisam ser complexas. Elas forma 1n a base para a padronização
e o sucesso repetível, independentemente do tamanho da empresa.
13
O histórico da Key Plastics
A Key Plastics possui un1 forte legado como fornecedora auton1otiva Tier 1, oferecen-
do operações con1pletas de design, engenharia, manufatura e montagem para compo-
nentes de acaban1ento interior moldados por injeção, n1açanetas exteriores e compo-
nentes deba ixo do capô. A Key tem sido consistentemente reconhecida por fabricantes
de equipamentos originais (OEMs, Original Equip·m ent Manufacturers) globa ln1ente
pela habil idade de entregar um produto de valor excelente, a lta qua lidade e dentro do
prazo. H istorican1ente, a Key potencializou processos e ferran1entas de gerenciamento
de progran1as regionais. O processo da An1érica do Norte focaliza-se forten1ente em
acompanhar os requerimentos do planejan1ento avançado da qual idade do produto
(APQP, advanced product quality planning) e com un1a forte fase de design. A equipe
da Ásia-Pacífico potencia liza as ferramentas e processos con1provados do parceiro de
joint venture. A equipe europeia segue dois processos diferentes. Um se concentra na
n1anufatura e em uma forte fase de estin1ativa de custos e orçan1entos. Um segundo
processo europeu é equi librado, contendo elen1entos con1erciais, de design e n1anufa-
tura, programado para acontecer em torno das fases de construç.ã o. Ver Figura 3-18.
Em u1n esforço para alvancar as 1nelhores práticas globa lmente, a Key recente-
mente iniciou o esforço de criar um único processo global chamado de Processo de
Real ização de Produto da Key (KPRP, Key Product Realization Process) e implementar
uma única ferramenta global de colaboração de gestão de projetos chamada de enter-
Proj. Um comitê de liderança foi formado co1n os líderes do gerenciamento de progra-
mas global, além de membros da equipe funcional, para garantir que todas as áreas da
empresa fossem representadas no desenvolvitnento do novo processo.
O Processo ( KPRP)
A equipe concordou e1n usar o processo equilibrado da UE como uma linha de base
para o novo KPRP (Ver Figura 3-19). A equipe compartilhava "coisas que deram cer-
to" e "coisas que dera1n errado" no nível regiona l para determinar as melhores práti-
cas a serem captadas de cada um dos processos regiona is e incorporadas ao novo pro-
cesso. Alguns pontos que merecem ser ressa ltados no recém proposto KPRP incluem:
• Fase de "Planejamento de negócios": inicia o projeto no portfólio corporativo
fornecendo visibilidade global precoce a tentativas
• Fase de "Aquisição": focal izada em estimativas de custo detalhadas para fornecer
o melhor valor no produto por meio do envolvimento de membros das equipes
funcionais desde o início
• Fase de "Desenvolvimento e planejamento": centrada em fortes pontos de revisão
de design com a opção de uma versão especializada dessa fase usada somente para
u O material sobre a Key Plasrics foi fornecido por Darlene Taylor, diretora de TI e práticas de negócios
globais. Reproduz.ido com permissão.
1/ '" ,us11cs u .c. construção de fe"amenras
vers100: 11 / S1ah1s: 17.12.2012 ...
ãl
1Macrofases AQo~~ão Desenvotvirnen1o -~ Pré-sene
Marcos Gl
(D
P<lnt.,êdo pro;eto
'"°'i.1*
. h 'I ' /lo,_ 1 Gtftll"W t
PMW'1$ lettan"IM!as
LanÇatl' ptoduto
e~ocesso
~ ' Oll.tAIV• &'
SOP SOP • Ili
,,.,,.....,,...,,,
-oº"
U>
Gat11•1tw 1
l,l(lt~OI ..,«lf'W
$,ti' CCIII la101t,_ l:lf
tlfltl
$lltl "4ll•rtl*rl RI
••ilflk'- 0.11,..,, (illfAl\t• • a.
lfl•t«C>'.!J'l!t(I (D
Gesfão econtro~ 1 'O
do projeto a.
a
{rqJfYd«i,1'1.-U
•'llll*
...
(lli:,llfle...
N~(I
()..ll:)"l••hÕJ• .... "1.1'
(~"
º"'"""'"'"'
OIWO.O) -~--....
11..11......, eo.111o\w,
---
1 ~<:1
(J.lftl.itl t)' """
OOltll.....itw $
0.1111.:..... 001•11i1:.iw & lt...,..IÁ•necl
1«(1tlft"114
,.,..,,bl,:.on
Hlf'lf*h•I
(D·
g
Vendas
P111•uii:i.1W:t1 .......,
f'Nlttl-,flOII
....
-
Pi,ic-1)1
··~
C\>,,i'\,d. . (i...""" •o:niahll...i dlltmóNd
11-... .., ,_ . ."
......
11,
' O•_.. O•OI
-··
...........
Desenv0Mmen1D---4!~1t"-------ll-~H.t••'4._~-•---._...._+---------t-=-:-.-.------+---+----l
llo<l•I 11 ..... ,
""'!."' ""'-·
I Z"~~
,.....,._l'tuun Plit-_.,_ 1 $,l·~l;rl lf*ITW iô)O
Ao1tã.i C>#lofA hWw!•ibllllyhoNI Q.lli(nll•(la11 1w ..n,ffflldb\ (<J(Jl)ljllarl,o;I j!IYÃ(l(lfl t41,•ll"<,l:t,.(t11'1
"·"·· V
l.o•Nd IIUCI UbH dil• ut•w.cl utjllr ,..,... mrll(ili,ta1fllu1'10íl • ••rvl*n,..,.,., -
......t:,11
P""1..- f»'!:l1Mt<l'I «n!f/J O•A" llud
j:,lln111ra,d li••.. ~ 111 IOl'O 4•tt
(J...........,. ff'i ..(Jlldt'(I $11.l(<W'W'ltf"t ,. .t'O
c..11d 1fllllH/Of!!'lll111d I OW ,..._.,:1 11--,lf'On:I 1~j(II , ..... _... «JA'»'tfl
1 , ,i.~ll"l'1'11d
-----------1---,
ftllt'Vp,tc:t '/ "'-
/
Ooalidade
ete~e ,?ª
-, "Q~,.~~ ,.,----r
--J.CXX'.
lf'M>l 11::t 1Wa'""Cltlf.C8!rl
fll flill lalt'QC- tab.f , 1d (hl!l(lfflll (1 '
.,--,l"Olttl 1111
(-ft<lf.cnl"ll,:I
lalrctilll
"""'
Ol:ll•NII.IUl"Olttl
l•ll"e1CMnl"
TtfW'I')', • ...,..
fl:l•:11'1>-.,t1J11!1
1
1 tUn.. ,l••
CCif'l~rl
111
·"'*'
C«n~hll
f
-"
-.11.«1
$11'11 .......
,...,..,.. 1 .............. ""•illl"W
$.,.1.,..,n
•
,...11tu
$'1,-.,tP"'II"
•
W;rt.1ro;11111re
,.,.11,(.,..
1111(1
~nw1~1N11'1• <11111
(li t(f.C81rl «injllrlld
oli:lll•(I ~ m f<dl ftl,l •d
Ferramentas e
eQ11iparnen1os ___.. 1 ~ -- i .. , :' 1 , 1 1
Ttci11r111c:ÍC...11d ~<l!JW\IC*
.... lit:,f, ,,..,'",
1
OPl,.1111:fl 1ttlfJlt#'e
(ll'lotfl(<.rl~·(I ......
~,d.n,
l'fl:jtft-._pW $o1•IÍl(,lt Pa..-.RIIOlC
.....,.,ro Ptó.ci!'O
c~rt•d
1.i:!(lllll(«f'W:4( 0 ..W)'Cftn "'"'·
LOQ~liea e
fornecimento
- - - - - - - - UI
0-idr'Clf:ric•lll'*'l:it._.,,
P,llllli.... d
Í>l•r.111,o,IIICICCll<tlll ~
a1111ttt
~ 11$- 1 1 )
_..,
; ; ; ; : ; ; ;l'Wt ...... ~ .(11'

c-1,uu
'.'.'1 i1111d
57.-.M
1
61.
~ ..L.
~
··-»
coanl r.1"'
'li,.....
:i:.:-· ,..,.,L. ~....
1
! IWll!b(_Uli:ttf'
..J. .
0t,----r------;
(JI
(al•Nl)llllm jlll.U fl:lfJllll'ltl M'-l"Ojlll... jU1hl>f'Oj)II,- f:Ud•iif'Oj)IIU1!'11 j)ll.-1ro1 llnlNd dfT*I0\111
~IUl«n:4(
a,ilo,l;tt
PIW,(ltf\PfflH
º"" 1'1'1 ......
Mtwl"OP,ftt
•M"'-""
a ·•llt*
"'.tf1ll fJll•ill
a-. 1,t,ft ltli:t:,•
n.111•1 RI
"""'•iif'Oj)II,- 1t111bd•
1.... -;""41,·~.....-oe,t fllfJlllrlol ~ ' '1(<.n:11(1
ProOi,;ão 1 - - -t-- - - - - - - - - - -1' --- 1•

- - - - - - - - - ••~ • n - -·ít -• r
r,, 1
1 1 ~'-...
·--
P.fWíA
ft•IJllyÕNto•) ~a(jlty
Q
,cm,1)111,-, ~..,
fn1(J1 ·f«t1W11uttnlttd Pltid.dicnjlllflfll
• º""~f......(U)
ll)nflltlld
·•'11•~
. .tnl*cl
•
$ á l\'lf)
, ...........Of1f"lf'U )
•
·~
Oa,1w-,r1 ,tlff )
•
~6',lnb,v1••rct<PIYI')
fotlM'-l"O{Wll)&) Key Plastics Lõhne ~'-l"O«K)

•
•
O:lfttl l'0«:0)
""'-•1111&i:o.•~l,NIWI)
.
•
hd.d{:Ol(f'llc.l)
.,.,.""'" G')
Figura 3-18 Pl'ocesso alemão. (Dísticos não passíveis de edição toram mantidos conforme original.)
• . , KEY PLAST I CS PROCESSO GLOBAL DE REALIZAÇÃO DE PRODUTO (KPRP)

1
MRD CAD MRD MRD PPAP SOP
Datas do cliente
• V V V V V V..,
DR4
Design
No enterProj Concessão DR3 DR3 pronto
Processo
W104 'Y W96 ... w66'Y wss'Y wso ... pronto
Planejamento Aquisições para a
Planejamento e desenvolvimento
de negócios
FASEO
e cotação
FASE 1
Revisão
BET
FASE2 ...
Revisão
W20
produção
'Y
BET Industrialização e piloto
FASE3
Revisão SOP SOP+90
BET wo ... W-12 'Y
Fase de construçio Fase de Fase de
de protótipo construção construção
Serialização e lançamento
FASE 4
Revisão
BET
• Focalizado no cliente.: . Focalizado nos resultados a
Figura 3-19 Processo Global de Realização de Produto (KPRP).
projetos que criam produtos de acordo com as especificações exatas do cl iente

(build-to-print)
• Fase de "Industrial ização": contém "mini" fases que gerencia1n o desenvolvimento
de ferra 1nenta de moldagem por injeção, equ ipamentos, instalações, em balagens,
peças compradas e resina além do plano de seleção de funcioná rios para a manu-
fatura
• Fase de "Seria lização": focalizada na ent rega do produto final
Para garantir a flexibil idade e permitir um processo " baseado na construção",
as fases de construção são intencionahnente mantidas em separado. Essas fases foca-
lizam-se somente nas tarefas lógicas necessárias pa ra a construção. Essa a bordagem
permite flexibi lidade para entregar quantas construções de protótipos ou de produção
forem necessárias para o cl iente. Essas fases possuem u1n cronograma separado das
fases cent rais listadas acima.
"O envolvimento dos especial istas em gerenciamento de progra 1nas globahnente,
além dos membros das equipes funcionais, gerou uma excelente discussão e debate so-
bre as tarefas cruciais necessárias para entregar um produto de alto valor e qualidade
para a Key e nossos clientes", diz Darlene Taylor, diretora de TI e Práticas de Negócios
Globais. " Essa contribuição global resultou e1n um processo único e otimizado, foca-
lizado em todas as áreas do projeto."
A ferramenta (enterProj)
Regionalmente, as equipes de programa da Key potencializam diferentes conjuntos de
ferramentas localizados para gerenciar eficientemente os planos e a documentação dos
projetos. Com o desenvolvimento do processo global, a equipe está imple1nentando o

enterProj - uma solução de nuve1n baseada na web criada para a colaboraç.ã o tanto
e1n projetos de produtos quanto de TI. Ver Figura 3- 20.
A Key está inicialmente focalizada no desenvolvimento do enterProj centra l, in-
cluindo a habilidade de gerencia r:
• Resumo do projeto: descrição, datas principa is, dados mensuráveis, fotos de pro-
dutos, resumo dos dados financeiros.
• Equipe: incluindo todos os 1nembros de equ ipes funciona is, segurança de proje-
to personal izada para me1nbros desejados, capacidade de ad icionar membros de
equipe fornecedores e capacidade de facihnente redistribuir tarefas a membros de
equipe.
• Risco, Problema e Oportun idade (RIO, Risk, Issue and Opportttnity): abordagem
colaborativa para o gerencia1nento de riscos, proble1nas e oportun idades com a
capacidade de ad icionar múltiplas ações a cada RJO.
• Peças, Ferramentas e Equipamentos, Fornecedores: aco1npanha informações-cha-
ve sobre dados desse projeto, além da capacidade de criar cronogramas específicos
atrelados ao plano de cronograma do projeto de grande porte e de formar uma
linha de base com dados mestres para as finanças do projeto.
• Cronograma: cria um plano de projeto personalizado basedo no processo global
KPRP e nos requerimentos de construção do cliente. Capacidade de ressaltar ta-
refas e.specíficas a serem reveladas no plano do cliente e também exportar para o
MS Project.
• Gerencia1nento de mudan~as: cria a funcional idade de solicitações de 1nudanças e
notificações de mudanças baseadas no projeto, o que permite que as equipes pro-
gramem o gerenciamento das mudanças baseadas em te,nplates de ação, aléin de
construir te,nplates de ação persona lizados Essas 1nudanç.as ta 1nbém pode1n estar
ligadas aos 1nodelos financeiros do projeto.
• Gerencia1nento financeiro : 1nodelo financeiro on-line calcula as 1nét ricas financei-
ras do projeto e é ampliado pela capacidade de fazer upload em qualquer modelo
detalhado de custeio.
"Com a implementação do enterProj, agora tenho visibi lidade em tempo rea l do
status de todos os programas globalmente", diz Terry Gohl, CEO da Key Plastics.
"Minha equ ipe executiva tem acesso imediato ao resu1no e a informações detalhadas
de cada projeto a partir do dashboard do enterProj."
,.
enterfro) • PfoJ«t
"-'~Oli!ll'l@nt is• ~e to
11:SC web ba5td pt"O)CCt
"'-'º-'O@ll'l@nt SQlut,o,'1 tQf
m11m,111ng ffld ttadOnq
f."O)tct$ of fn'I r.1t.
Figura 3-20 Exemplo de uma imagem de tela do enterProj.

3.18 A ILLUMINAT e o negócio estratégico

da gestão de projetos
E,n todo este capítulo, discutimos a jornada rumo à excelência. Quando as empresas
foretn capazes de integrar os processos de gestão de p rojetos, processos de negócios
e atividades de planejamento estratégico, a 1naturidade etn gestão de projetos e, fi-
nalmente, a excelência poderão ser e serão a lcançadas. A ILLUMINAT é um ótimo
exemplo de empresa que alcançou a excelência.
Serviços de gestão de projetos da ILLUMINAT: a busca pela

14
excelência em gestão de projetos
Segundo O,ven Field, Gerente Regiona l de Serviços de Gestão de Projetos da ILLUMI-
NAT, é preciso haver um motivo estratégico pelo qua l u1na empresa deseja se tornar
excelente em gestão de projetos. Ana lisando o elemento estratégico tradicional (produ-
tos oferecidos - mercados atend idos), a excelência em gestão de projetos deve permitir
que uma empresa tenha a oportunidade de desenvolver mais produtos e atender mais
mercados do que se não a tivesse adotado. A ILLUMINAT reconheceu isso há anos e
deu início a u1na jornada rumo à excelência na á rea.
A ILLUMINAT é líder no setor de provisão de soluções de TI e teleco1nunicações
para grandes organizações caribenhas que atendem todas as indúst rias, setores e em-
preend imentos; de equipamentos e suprimentos de escritório a aplicações empresariais
em gerencia tnento de ativos, gerenciamento de registros e gerenciamento de recursos
financei ros e humanos; além de redes e teleco1nunicações ao suporte técnico e serviços
de gestão de projetos. As práticas de gestão de projetos hoje afetam todas as áreas de
nosso negocio.
Os benefícios de se alcançar a excelência en1 gestão de projetos são bem visíveis.
A Unidade de Serviços en1 GP da ILLUMINAT é composta por uma equ ipe de elite
de p rofissionais com experiência e certificação en1 várias n1etodologias para p rover
soluções de negócios, de p rojetos e de consulto ria em T I, poss ibilitando o ROi a
nossos clientes, ti rando p roveito de nossa experiência para entregar realização de
va lor. Criamos um conjunto preciso de serviços de consultoria a partir dos don1í-
nios do p rojeto, negócios e informação e tecno logia de con1unicação, fornecendo
aos nossos clientes un1a entrega especial izada e orientada pela excelência. Execu-
tamos projetos, gerenciamos a transformação de negócios e entregamos resultados
aos nossos clientes.
Agora podemos voltar ao elemento estratégico dos produtos oferecidos e merca-
dos atendidos. A ILLUMINAT presta os seguintes serviços:
• Gestão de projetos e p rogra mas
• Consultoria e implementação do escritório de gestão de projetos
• ltnplementação e Suporte a Negócios
• Soluções de Negócio etn TI
• Gestão de Projeto e Soluções de Negócio para treinamento etn TI
A ILLUMINAT presta serviços:
• ao setor público e ao privado;
"' ©20 13 by ILLU!vUNAT. Reproduzido com pennissão. Todos os direitos reservados. O marerial desta seção
foi fornecido por Owen Field, gerente regional de serviços de gestão de projetos da ILLU/v!INAT.
• em diferentes indústrias nas áreas de energia, finanças, agências governa1nenta is e

agências nacionais, varejo e hotelaria, util idade pública e manufatura;
• em todo o Caribe, das Bahamas às Guianas;
• que satisfazem partes interessadas da Índia, Europa, do Reino Unido, da A1nérica
do Norte e América do Sul.
Nós constantemente:
• monitoramos o 1nercado competitivo;
• respondemos a mudanças nas demandas do mercado;
• identificamos " lacunas" no dese1npenho das organizações e desenvolvemos so-
luções de serviços para otitnizar o desempenho do cliente e a realização de valor
. .
para seus 1nvesttmentos;
• satisfazemos as necessidades dos cl ientes;
• comprometemo-nos com o desenvolvimento profissiona l.
O feedback de nossos clientes obtidos por n1eio de pesquisas de satisfação do
cl iente e avaliações de in1pactos indicam que nossas melhores práticas e delivera-
bles estão sendo adotados dentr o de suas empresas para otim izar seus processos de
negocios.
Nossa jornada em busca da excelência na gestão de projetos baseia-se na fi losofia
de que "Somos o que faze1nos diversas vezes. A excelência, portanto, não é um ato,
mas um hábito" (Aristóteles).
Os serviços de GP da ILLUMINAT em sua forma atual está operando e crescendo
há sete anos.
Esforçamo-nos rumo à excelência estando na vanguarda de nossa profissão:
• Comprometidos com o desenvolvimento profissional
• Reconhecidos em várias cerimônias de premiação por nossa excelência em proje-
tos, pessoas e serviços
• Reconhecidos por nossos clientes e partes interessadas por aprimorar seus proces-
sos de negócio por meio da adoção de nossas melhores práticas e deliverables em
gestão de projetos
• Reconhecidos por vários autores pela excelência em gestão de projetos
• Autores de W!hite Papers
• Palestrantes em conferências do setor
• Pioneiros na pesquisa em gestão de projetos na região
• Acreditados como Provedor Registrado Globa l de Educação pelo Instituto de Ges-
tão de Projetos (PMI, Project Management Institute )
• Atuantes nos Comitês de Sociedades Profissionais
• Investidores do desenvolvimento nacional e regiona l
• Foca lizados em uma perspectiva global, pronta para a exportação
• Transformados de um centro de custos com uma única linha de serviços, uma
entidade com foco interno e descon hecida, em um centro de lucros co1n cinco
linhas de serviço, uma entidade co1no foco externo e de exportação, publicada e
reconhecida internacionalmente por ter vencido prêm ios de melhores práticas em
excelência.
Alcançamos tudo isso construindo a Excelência em tudo o que faze1nos. Exen1plos:
• Estratégia e Capacidade no Gerenciamento de um PMO
• Competência dos funcionários de gestão de projetos, certificação e perspicácia de
negocios
• Desenvolvimento e refinamento de métodos, p rocedimentos, ferramentas e tem-

plates de GP alin hados aos pad rões, melhores pr áticas e regulan1entações do
setor
• Liderança apaixonada e u1na cultura de comprometimento com o gerenciamento
de serviços e relaciona1nentos
• Redes estratégicas e repositórios de conhecimento
• Evolução e mel horias contínuas
A cont ribuição do PMO para a organização é uma mel horia geral no seguinte:
• !tnage1n da ILLUMINAT
• Moral dos funcionários
• Produtividade dos funcionários
• Serviço e qua lidade para o cliente
• Boas práticas de negócios, aumentando as receitas e a rentabil idade
• Gerenciamento de despesas
• Gerenciamento de contas a receber e estoques
• Eficiência operacional
!tnpacto geral do PMO ao longo de um período prolongado:
• Satisfação do cl iente - entregas de acordo com os padrões e expectativas, co1n
profissionalismo.
• Satisfação dos funcionários - elim inou o confl ito por recursos entre diferentes uni -
dades por meio de um PMO da empresa que abriu caminho para que os funcio-
nários produzissem. O PMO é classificado como um departamento de liderança
na organ1zaçao.
• Produtividade - aumentou significativamente devido ao desenvolvimento profis-
sional e à cultura de alcançar resultados superiores.
• Eficiência - capacidade desenvolvida por meio de metodologia e ferramentas para
fazer mais co1n menos.
• Utilização - melhorou a padronização do aco1npanhamento e gerenciamento das
horas a pagar por serviços profissiona is .
• Desempenho dos funcionários do PMO - consistentemente acima das metas.
• Erosão - reduziu sign ificativamente a perda de receitas devido a esti1nativas ruins
e esforços não faturados por má gestão de mudanças. Melhorias na estimação e na
aplicação de controle de mudanças no projeto permitiram uma redução de 100o/o
na erosão das receitas.
• Receitas - fora1n desenvolvidos u1n novo canal de receitas e uma capacidade de
recuperação de receitas. PMO passou de um centro de custos a um gerador de
receitas/lucros.
• Reputação da 1narca - excelência na entrega de projetos, reconhecimento formal
e informal pelo setor.
• Integração da organização - processos e padrões unifonnes, avanço da capacidade
organizacional.
• Integração regional - benchtnarking e padrões. A integração do PMO regional
está promovendo sinergias em todo o Caribe, onde a experiência em GP de u1n
território pode ser aplicada a outro, além d isso, as inovações e aprendizados mul-
ticulturais são comparti lhados e aplicados em todos os territórios.
• Ativos de conhecimento - certificação de funcionários, informações sobre proje-
tos, repositório de lições aprend idas e melhores práticas continuam a promover a
apreciação de capital, gerando novos benefícios de negócios.
3.19 Avalon Power and Light

A Avalon Power and Light (nome fictício) é uma emp resa de util idade pública da
região dos Mounta in States, EUA, que, por décadas, foi detento ra de um monopólio
regional. Tudo iso mudou em 1995, co1n o início da desregula mentação das empresas
de utili dade pública nos EUA. A prioridade interna, então, passou ao corte de custos
e à competitividade.
A Divisão de Sistemas de Informaç.ã o da Avalon sempre foi consi derada um "es-
pinho no pé" da empresa. Os funcionários agia m como supercelebridades e se recu-
savam a aceita r q ualquer u1n dos princípios da gestão de projetos. Acontece que o
progra ma de cortes de custos na Avalon deix ou claro para todos que a maio r parte do
t rabalho da Divisão de Siste1nas de Informação podia ser tercei rizada por um preço
significati vamente mais baixo do que se real izado interna mente. A gerência tinha a
convicção de que a gestão de pro jetos poderia torna r a divisão mais competitiva, mas
será que os funcionários agora estar iam dispostos a fi na lmente aceitar a abordagem
da gestão de projetos?
Um porta-voz da Avalon Po,ver a nd Light expl ica:
Duas tentativas a nteriores de implementar uma metodologia-padrão de desenvolvimento de
aplicações tinh am fracassado. lvlesmo com o novo diretor de sistemas de informação dando
apoio to ta l a essa terceira tenta tiva, impondo o uso de uma metodologia e ferramentas-
-padrão, ainda se faziam presentes obstáculos significativos.
A curva de a prend izagem da metodologia de gestão de projetos era a lta, produzindo
entre os líderes uma tendência a impor suas próprias interpretações às tarefas de metodolo-
gia, em vez de a prender as explicações documentadas. Isso resulto u em uma interpretação
inconsistente da metodologia, o que, por sua vez, produzia inconsistências quando tentáva-
. . . . .
mos usar est1mat1vas anteriores ao estimar novos prOJetos.
A necessidade de atualizar os planos de projeto em tempo oportuno a inda não tinha
sido aceita por todos. Inconsistências na documentação de horas realmente trabalhadas e
datas de fin alização resultavam em disponi bilidades inexatas. Os re.c ursos q ue, segundo o
plano depa rta mental, deveria m estar d isponíveis, na verdade não estavam.
Muitos líderes de equipe não tinh am aderido à filosofia que embasava a gestão de pro-
jetos, nem ta mpouco acreditavam realmente em seus benefícios. Eles faziam as coisas acon-
tecerem, alcançando os resultados previstos, mas gerenc iavam seus projetos de maneira
intuitiva em paralelo ao plano de projeto em vez de usá-lo.
A gerência de sistemas de informação não fazia perguntas que exigissem o uso da gestão
de projetos nos relatórios de status de projeto . As métricas-pad rão da gestão de projetos
eram ig noradas nos relatórios de status de projeto e substituídas po r avaliações subjetivas.
A Divisão de Sistemas de Informação se deu conta de que sua existência poderia
depender da q ualidade e da rapidez com que ela poderia desenvolver um siste1n a ma-
d uro de gestão de projetos. Em 1997, o senso de urgência para atingir a maturidade
já permeava toda a Divisão de Siste1n as de Informação. Quando indagado sobre os
benefícios que fo ra 1n alcançados, o porta-voz comento u:
A percepção da estrutura e a capacidade de documentar propostas utilizando técnicas re.co-
nhecidas exteriormente à nossa organização permitiu que a divisão co mpetisse com sucesso
com o utras o rganizações nos projetos de desenvolvimento de aplicações.
Um melhor gerenciamento de recursos, por meio da eliminação da prática de "acúmulo"
de recursos preferidos a té que um o utro projeto precisasse seleciona r funcionários, permitiu
q ue a Divisão de Sistemas de Informação realmente trabalhasse mais com menos pessoas.
Atua lmente estamos definindo requerimentos para um projeto de seguimento do pro-
jeto o riginal de implementação da gestão de projetos. Esse novo projeto abordará as lições
aprendidas em nossos dois primeiros anos. O treinamento em conceitos de gestão de pro-
jetos (em oposição ao treina mento em ferramentas) será adicionado ao c urrículo existente.
Precisamos da r maior ênfase ao porquê da necessidade de registrar o prazos e status de
tarefas com precisão. Será feita uma tentativa de estende r o uso da gestão de projetos a
á reas não relacionadas ao desenvolvimento de aplicações, como a de comunicações em
rede e s uporte técn ico. A aplicabilidade de nossa metodologia existente para o desenvol-
vimento de aplicações cl iente-servidor e via internet será testada . Exploraremos também
eficiências adicionais como a entrada d ireta da informação de status de tarefas por mem-
bros individuais da eq uipe.
Hoje oferecemos serviços de gestão de projetos como uma opção em nossos acordos de
nível de serviço com nossos "clientes" corporati vos. Uma das histórias de sucesso envolveu
um projeto que tinh a por objetivo implementar uma nova identidade corporativa na q ua l
vários componentes de toda a corporação foram reunidos. O projeto conseguiu supera r as
barreiras departamentais e manter um cronograma dinâmico. O processo de definição de
tarefas e estimação de s uas durações resultou em uma melho r compreensão dos requeri-
mentos do projeto. Isso, por sua vez, gerou estimativas precisas que direcionaram decisões
significativas relativas ao escopo do projeto, levando em consideração as severas pressões
orçamentais. As decisões de projeto tendia m a se a ncorar em sólidas a ltemati,,as empresa-
riais, em vez de em mera intuiç.ão.
3.20 Roadway Express

Na primavera de 1992, a Roadv,ay Express percebeu que era necessário fazer u1na
atualização em seus siste1nas de suporte (especificamente, seus sistemas de informa-
ção) pa ra que a empresa estivesse bem posicionada na chegada do século XXI. Mike
\1v'ickham, então presidente da Road,vay Express, era um forte defensor das mudanças
contínuas. Tratava-se de u1na necessidade pa ra sua empresa, tendo em vista que os
rápidos avanços tecnológicos faziam dos esforços de reengenhari a um processo contí-
nuo. Vários dos projetos a serem empreendidos exigia 1n um nú1nero signi ficativa1nente
maior de recursos do que os projetos passados. Era necessária também uma interação
mais forte entre os depa rtamentos funcionais.
Em 1992, o conhecimento de princípios e ferra n1entas de gestão de projetos
nos níveis operaciona is da Roadway Express era, na melhor das hipóteses, mínimo.
Nos níveis executivos, en1 contrapartida, esse conheci mento era excelente. Isso iria
se comprovar de grande utilida de. A Roadway Express reconheceu a necessidade
de utiliza r a gestão de projetos em un1 projeto de dois anos de duração que tinha
visi bilidade e suporte executivo e que era considerado estrategicamente crucia l para
a empresa. Entretanto, en1 bo ra o projeto exigisse um gerente de projetos en1 regin1e
de ten1po integral, a empresa optou por designar um gerente de área que se encarre-
garia simultaneamente das duas ta refas por dois anos . A empresa não usava a ges-
tão de projetos de forma contínua, e a compreensão do processo era extremamente
limitada.
Três meses depois de iniciada a tarefa, o gerente de área renunciou ao seu ca rgo
de gerente de projetos, a legando estar est ressado demais e ser impossível gerenciar sua
área eficientemente ao mes1no tempo em que cu1npria as obrigações do projeto. U1n
segundo gerente de área foi nomeado para a mes1na ta refa, ainda em regÍlne de tempo
parcial e, assim como seu predecessor, achou necessário abdicar da função gerente de
proJetos.
A empresa, então, designou um terceiro gerente de área. Dessa vez, porém, libe-
rou-o de todas as responsabilidades da gerência de área por toda a duração do projeto.
A equipe de projeto e funcionários selecionados da empresa receberam treinamento
em gestão de projetos. O presidente da empresa percebeu os riscos da implementação
acelerada, especiahnente em um projeto de tal 1nagnitude, mas estava disposto a acei-

tar os riscos decorrentes de sua decisão.
Depois de outros t rês 1neses, o gerente de projetos reclamou que alguns dos mem-
bros de sua equipe estava1n muito insatisfeitos com as pressões exercidas pela gestão
de projetos e estava1n a1neaçando ped ir demissão da etnpresa, se necessário, simples-
mente para se livrar dessa função. Porém, quando questionado sobre o status do pro-
jeto, o gerente declarou que estava conseguindo alcançar todas as metas determinadas
até o momento. Ficou, então, bem claro para o presidente, Mike \Vickha1n, e para os
demais executivos da empresa, que a gestão de projetos corria conforme o esperado. A
ênfase agora era como "afagar" os funcionários descontentes e convencê-los da impor-
tância de seu trabalho e de quanto a e1npresa apreciava seus esforços.
Para atenuar a ansiedade dos funcionários, o presidente assumiu o papel de pa-
t rocinador do projeto e deixou bem claro que a gestão de projetos tinha chegado para
ficar na Roadway Express. O presidente promoveu progra1nas de treinamento em
gestâo de projetos e t ratou de marcar presença e1n cada u1n deles.
O reforço e visível apoio dado pelo presidente permeou todos os níveis da empre-
sa. Em junho de 1993, menos de oito 1neses depois do primeiro uso oficia l da gestão de
projetos, a Road,vay Express tinha ido mais longe no caminho ru1no à 1naturidade do
que a maioria das outras empresas consegue em dois a três anos, simplesmente devido
ao apoio visível da gerência sênior.
A gerência sênior rapidamente percebeu que a gestão de projetos e o gerenciamen-
to de sistemas de informação poderiam ser eficientemente integrados em uma única
metodologia. Mike Wickham corretamente reconheceu que quanto mais rapidamente
ele pudesse convencer seus gerentes de área a apoiar a 1netodologia da gestão de pro-
jetos, mais rapidamente eles alcançaria1n a maturidade. Segundo Mike Wickham, Pre-
sidente da Roadway Express naquela época (e posteriormente presidente do conselho
de diretoria):
A gestão de projetos, independentemente do nível de sofisticação e treinamento, não pode
funcionar eficientemente, a menos que toda a gerência esteja comprometida com um re-
s ultado de sucesso. Antes de colocarmos nossos processos atuais em funcionamento, en-
volvemos ativamente todos o s nossos gerentes de área que achavam que era função deles
descobrir todos os motivos pelos quais um sistema nunca funcionava! Agora, o comitê de
liderança diz: ;'Este é o projeto. Tome as rédeas e faça-o funcionar" . Há um uso muito mais
eficiente dos recursos quando todos estão focalizados nas mesmas metas.
3.21 Defcon Corporation

Um fornecedor do setor de defesa que deseja manter sua identidade preservada (aqui
chamado de Defcon Corporation) tinha conseguido sobreviver no ramo por mais de
20 anos à base de contratos com o governo de preço fixo e pagamento à vista. A
característica de um contrato de preço fixo é que o cliente não faz auditoria dos regis-
t ros contábeis, custos ou nem mesmo do sistema de gestão de projetos do fornecedor.
Consequentemente, a empresa em questão gerenciou seus projetos de forma bem libe-
ral no período entre 1967 e 1987. Contanto que os prazos fossem cumpridos, nunca se
questionava a competência do sistema de gestão de projetos.
Em 1987, o ambiente de terceirização do governo tinha mudado. Havia vários
motivos para ta l mudança:
• O Departamento (m inistério) de Defesa dos EUA (DoD) estava passando por uma
reestruturação.
• Houve cortes nos gastos do DoD, com previsão de cortes ainda mais drásticos.
• O DoD estava concedendo cada vez mais contratos de custos ree1nbolsáveis (pa-
gamento pós-entrega).
• O DoD estava pressionando seus fornecedores a se reestruturarem, passando de
uma forma organizacional trad iciona l a uma fonna organ izaciona l orientada a
produtos.
• O DoD estava pressionando os fornecedores a reduzirem custos, especialmente os
custos indiretos.
• O DoD passara a exigir produtos de mais alta qual idade.
• O DoD passara a exigir em suas propostas que as empresas de1nonst rassem maior
qualidade nas práticas de gestão de projetos.
Para garantir a sobrevivência, a Defcon teve de se submeter às licitações de con-
t ratos com pagan1entos posteriores à entrega. Internamente, isso exigia duas mu-
danças cruciais. Primeiro, a organ ização tinha de passar de un1a gestão de projetos
inforn1a l para a fo rn1al. Segundo, a o rganização precisava aprender con10 usar e
relata r os indicadores de valor agregado. Pa ra ser vista favoravelmente pelo governo
na d isputa por um contr ato com pagamento posterior à entrega, uma empresa deve
ter seu sistema de controle/relatórios dos indicadores de valor agregado validado
pelo governo.
Um gerente de uma out ra empresas que estava passando por essas mesmas difi-
culdades fez os seguintes comentários sobre como a "sobrevivência" tinha forçado a
organização ascender mais rapida1nente à maturidade nos últimos 1O anos:
A gestão de projetos formal começou com a primeira grande concessão de um contrato do
governo. Uma das exigências contratuais determinava q ue se fizessem relatórios de custos
por itens em cada área e também das variâncias em níveis específicos de contratos. Obti-
vemos um sistema validado que nos deu a flexibilidade de enviar propostas em programas
governamentais em que a discriminação dos custos programados era um dos itens exigidos
na solicitação de proposta (RFP, request for proposal).
Tivemos uma experiência prévia em técnica de avaliação e revisão de programas (PERT,
program eval11atio11 a11d review tech11ique), estrutura analítica do projeto e programas de
organizaç.ã o. A administração também costumava operar de maneira estruturada por causa
da exigência de revisões nos programas de nossos cl ientes. Após a val idação do sistema,
em 1987, levou de seis meses a um ano para que treinássemos e desenvolvêssemos ade-
quadamente as habilidades ne.cessárias em contabi lidade gerencial de custos e supervisão
do pacote de trabalho. À medida que se progride em um programa, s urge a necessidade de
novos treinamentos e revisão nos requisitos da gestão de projetos juntamente com toda a
organização.
Visitamos outras empresas e d ivisões de nossa própria empresa que haviam tido expe-
riências anteriores em gestão de projetos. Encaminhamos pessoas para seminários e cursos
ministrados por especialistas da área. Conduzimos treinamentos internos e estabele.cemos
as políticas e os procedimentos para auxiliar os funcionários com o processo de gestão de
projetos. Mais tarde, compramos softwares para relatórios com o intuito de reduzir os cus-
tos da programação interna de sistemas.
Estabelecemos equipes exclusivas para um contrato/programa. Atualmente, temos um
programa de organização do escritório para os grandes projetos com capacidade de acom-
panhar e coordenar a informação para o gerenciamento interno e para os nossos clientes.
Ajustamos nossos sistemas e os relatórios de maneira a poder s uprir as necessidades tanto
dos cl ientes internos quanto dos externos.
A implementação de sistemas integrados pode fornecer dados em tempo mais oportuno.
Estes dados capacitarão a gerência a reagir de forma mais d inâmica na resolução de proble-
mas e na redução do impacto dos custos.
A gestão de projetos nos permitiu compreender melhor os custos e as variações por
contrato/programa. Ele fornece dados mai s pontuais e torna o acompanhamento da pro-
gramação, de questões de orçamento e do valor agregado mais flexível. A gestão de projetos
nos deu ma ior visibilidade dos programas que são úteis na implementação de reduções de
custos e a perfeiçoamento dos processos. Ter um sistema validado nos permite permanecer
competitivos na licitação de projetos que exigem um sistema formal de controle dos custos
programados.
3.22 Kombs Engineering

A empresa descrita na última seção foi 1nuito feliz ao identificar as crises e dedicar
tempo a u1na reação apropriada. Outras empresas não têm a mesma sorte. Embora
as duas empresas a seguir pareça1n ult rapassadas, há lições valiosas que podem ser
aprendidas sobre o que não fazer ao embarcar no ca1ninho rumo à maturidade. É o
caso, por exemplo, da Kombs Engineering, de Michigan (nome fictício, por exigência
da empresa ana lisada).
Em junho de 1993, a Kombs Engineering já era uma empresa com faturamento
de US$ 25 milhões. Sua base de negócios consistia em dois cont ratos com o Depar-
tamento (1ninistério) de Energia (DoE), um deles de US$ 15 milhões e o outro de
US$ 8 1nilhões. Os outros US$ 2 milhões provinham de uma variedade de pequenos
etnpreendimentos, variando de US$ 15 mi l a US$ 50 mil cada.
O maior cont rato com o Do E era, logicamente, o de US$ 15 mi lhões ao ano, com
cinco anos de duração. Tendo sido assinado em 1988, tinha sua renovação prevista
para 1993. O DoE havia deixado claro que, mesmo estando plenamente satisfeito com
o dese1npenho técnico da Ko1nbs, a lei determinava a abertura de nova licitação por
ocasião da renovação. Investigações 1nercadológicas revelara1n que o DoE pretendia
gastar US$ 10 mi lhões por ano no contrato posterior, por mais cinco anos, co1n data
de atribuição prevista para outubro de 1993. Em 21 de junho de 1993, a Kombs foi
notificada para enviar sua proposta. Os requisitos técnicos do cont rato não eram con-
siderados problema algum para a Kombs. Ninguém tinha a menor dúvida de que, se
dependesse exclusiva1nente dos méritos técnicos, o contrato continuaria com a Ko1nbs.
O proble1na principal, porém, é que o DoE exigia uma seç.ã o separada na proposta
deta lhando de que forma a Kombs administraria o projeto de US$ 10 milhões anuais,
bem como uma descrição pormenorizada do funcionamento do sistema de gestão de
projetos da companhia.
Quando a Kombs ganhou a licitação original em 1988, nenhuma imposição rela-
cionada à gestão de projetos fora feita. Todos os projetos da Kombs eram conduzidos
por meio da estrutura t radiciona l de organização. Apenas gerentes de área funciona-
vam co1no líderes de projetos.
Em julho de 1993, a Kombs contratou u1n consultor para treinar toda a empresa
em gestão de projetos. O consultor também passou a trabalhar em conjunto com a
equipe da proposta na elaboração de respostas às exigências do DoE em matéria de
gestão de projetos. A proposta fina l foi apresentada ao DoE na segunda semana de
agosto. E1n setembro de 1993, o DoE submeteu à Kombs nova lista de questões rela-
tivas à proposta. Mais de 95% das questões envolviam gestão de projetos. A Kombs
respondeu a todas elas.
Em outubro de 1993, a Kombs foi notificada de que não ganharia o cont rato.
Em entrevista posterior à divulgação da decisão final, o DoE afirmou que não tinha
"confiança" no sistema de gestão de projetos da Kombs. A Kombs Engineering fechou
suas portas.
A Kon1bs Engineering é um excelente estudo de caso para análise nos cursos de
gestão de projetos. Mostra o que acontece quando un1a empresa terceirizada não
reconhece quão avançado se tornou o cl iente em gestão de projetos. Se a Kon1bs ti-

vesse estado em contato permanente e próxima de seus clientes, teria tido cinco anos,
e não apenas um mês, para o desenvolvimento de um sistema n1aduro de gestão de
proJetos.
3.23 Williams Machine Tool Company

A força de uma cultura pode não apenas impedir que uma empresa perceba a necessi-
dade de algumas 1nudanças como, ca1nbém, bloquear a implementação das mudanças
mesmo depois de terem sido finalmente percebidas como indispensáveis. Foi a situa-
ção vivida pela Williams Machine Too! Company (outro nome fictício).
Durante 75 anos, a Williams Machine Too! Company forneceu produtos de qua-
lidade para os seus cl ientes, a ponto de se tornar, em 1990, a terceira ma ior fábrica de
máquinas operacrizes estabelecida nos Estados Unidos. Era uma empresa de alca ren-
tabilidade e com uma taxa de rotatividade excre1namente baixa entre os funcionários.
Os sa lários e os benefícios ad icionais era1n excelentes.
Entre 1970 e 1980, os lucros da empresa chegaram a pata 1nares recordistas. Todo
esse sucesso decorria de uma linha padronizada de máquinas operatrizes. A Williams
investiu a maior parte de seu tempo e recursos no aperfeiçoamento desta linha tra-
diciona l de produtos, não se preocupando co1n o desenvolvimento de novos produ-
tos. Suas 1náqu inas operacrizes faziam canto sucesso que out ras e1npresas chegavam
a mod ificar suas linhas de produção para se adaptarem a elas, ao invés de pedirem à
Will iams que fizesse modificações nas máquinas operacrizes.
Em 1980, a \Villiams se mostrava por dema is acomodada, na certeza de que o
fenomena l sucesso da sua linha de produtos estaria garantido no míni1no por mais
20 ou 25 anos. Porém, a recessão de 1979-1983 obrigou a gerência a repensar suas
prioridades. A queda da produtividade diminuiu a demanda por máquinas operacri-
zes-padrão. Aumentava sem cessar o número de clientes que ped iam alcerações no
produto-padrão, ou até mes1no uma 1náquina co1n u1n design tota lmente novo.
O mercado estava mudando, e a gerência reconheceu a necessidade de um novo
foco estratégico. Entretanto, os esforços empreendidos para convencer a gerência in-
termediária e os operários, especialmente os do setor de engenharia, dessa necessidade,
enfrentavam sérias resistências. Os funcionários, especia lmente aqueles com 20 anos
ou mais na empresa, recusavam-se a reconhecer essa necessidade, na crença de que os
dias de glória de outrora voltariam logo que a recessão acabasse.
Em 1986, a empresa foi vend ida para a Crock Engineering, que tinha cambétn
uma conceituada divisão de máquinas operatrizes e conhecia muito bem o setor. Ape-
sar da t ransação, a Williams continuou a operar co1no entidade independente de 1985
a 1986, quando o balancete demonstrou que ela estava operando no vermelho. A
Crock substituiu toda a gerência executiva da \Villia1ns por pessoa l próprio. Então,
anunciou que todos os funcionários da Williams deveriam se tornar fabricantes de
acessórios especiais de 1náquinas operacrizes e que os "dias de glória", definitivamente,
jamais voltariam. A demanda por acessórios especiais havia triplicado nos 12 me-
ses anteriores. A Crock procurou deixar claro para os funcionários que aqueles que
não apoiassem estas novas diretrizes seriam substi tuídos. O novo gerente sênior da
Willia1ns reconheceu que os 85 anos de gerenciamento tradicional tinham chegado
ao fim em u1na empresa volcada, a partir desse 1no1nenco, para acessórios especiais. A
nova cultura era a da mudança, envolvendo gestão de projetos, engenharia simulcânea
e gestão da qualidade coca l.
O comprometimento da gerência sênior com a gestão de projetos ficou be1n claro

e1n função do tempo e do dinheiro gastos na reeducação dos funcionários. Infel izmen-
te, os experientes funcionários com 20 anos ou 1nais de casa, ainda não apoiavam a
nova cultura. Reconhecendo o problema, a gerência reforçou seu apoio à gestão de
projetos, contratando a inda um consultor especializado nessa área para t raba lhar com
as pessoas. O consultor t rabalhou na \Vill iams de 1986 a 1991.
Nesse mesmo período, a Divisão Williams da Crock Engineering apresentou défi-
cits em 24 trimestres consecutivos. O trimestre encerrado em 31 de março de 1992 foi
o primeiro a apresentar lucro e1n 1nais de seis anos. Grande pa rte deste feito foi cre-
d itado ao desempenho e à maturidade do sistema de gestão de projetos. Em ma io de
1992, a Divisão Williams fo i vend ida. Mais de 80'% dos funcionários perderam seus
e1npregos quando a empresa foi reinstalada a mais de 2 mi l quilômetros de distância.
A \Villiams Machine Too) Company levou tempo demais para reconhecer que a
base do negócio havia 1nudado de um sistema orientado à produção para u1n sistema
orientado a projetos. Viver do passado só é aceitável para quem deseja ser historiador.
Se as empresas pretendem sobreviver, especia lmente em um ambiente altamente com-
petitivo, terão que o lhar adiante e reconhecer que mudanças são inevitáveis.
Metodologias de
gestão de projetos
4.0 Introdução
No Capítulo 1, descrevemos as fases do ciclo de vida necessárias para alcançar a ma-
turidade e1n gestão de projetos. A quarta fase era a do crescimento, que inclui as se-
guintes etapas:
• Estabelecimento das fases do ciclo de vida
• Desenvolvimento de uma metodologia de gestão de projetos
• Funda1nentação da metodologia em um planeja1nento eficiente
• Miniinização de mudanças de escopo
• Seleção do software apropriado para servir de suporte à metodologia
A importância de uma boa metodologia não deve ser subestimada. Além de me-
lhorar o desempenho durante a execução do projeto, ela aumenta a confiança dos
clientes e melhora sua relação com a empresa. Boas metodologias também pode1n
levar a contratos exclusivos.
Criar uma metodologia funcional para a gestão de projetos não é tarefa simples.
Um dos maiores equívocos que se pode cometer é desenvolver uma metodologia dife-
rente para cada tipo de projeto. Out ro é deixar de integr ar a 1netodologia e as ferra-
mentas de gestão de projetos em um único processo, se possível. Quando as empresas
desenvolvem metodologias e ferramentas de gestão de projetos que se completa 1n,
surgem dois benefícios. Em primeiro lugar, o trabalho é realizado com menos mudan-
ças de escopo. E1n segundo lugar, os processos são planejados visando criar o menor
número possível de distúrbios nas atividades operaciona is que estão em andamento
na empresa.
Este capítulo discute os componentes da 1netodologia e de algu1nas das ferramen-
tas mais uti lizadas em gestão de projetos. Também são apresentados exe1nplos deta-
lhados de metodologias existentes.
4.1 Definição de excelência

A excelência em gestão de projetos geralmente é considerada um fluxo contínuo de
projetos gerenciados com êxito. Se1n u1na metodologia de gestão de projetos, pode ser
difícil concluir projetos bem-sucedidos com frequência.
Atua lmente, todos parecem concordar, pelo menos em parte, com a necessidade de
uma metodologia de gestão de projetos. Porém, ainda há um desacordo quanto à de-
fin ição da excelência na área, da 1nesma maneira que as e1npresas possuem d iferentes
definições de sucesso de um projeto. Nesta seção, discutiremos algumas das diferentes

definições de excelência em gestão de pro jetos.
Algu1n as podem ser bem simples e alca nçar o mesmo obj etivo de defi nições com-
1
p lexas. Segundo um porta-voz da M otorola:
A excelência em gestão de projetos pode ser definida como:
• Estrita observância das práticas de geração de cronogramas
• Supervisão periódica pela gerência sênio r
• Controle formal de 1nudanças nos requerimentos
• Acompanha ,n ento formal de pro blem as e riscos
• Acompanha ,n ento formal de recursos
• Acompanha ,n ento formal de custos
Um porta-voz da AT& T definiu a excelência na AT& T como :
A excelência [em gestão de projetos] é definida como uma metodologia consistente aplicada
a todos os projetos da organização, o reconhecimento continuado po r nossos clientes e uma
alta satisfação do cl iente. Além disso, nossa excelênc ia em gestão de projetos é um fato r
de venda para nossas equipes de vendas. Isso resulta em negócios de repetição com nossos
clientes. Há também um re.conhecimento interno de que a gestão de projetos é uma a tivida-
de q ue agrega valo r e de que é uma necessidade a bsoluta.
Do ug Bolzman, Consultor em arquitetura, profissional de gestão de projetos
(PMP®), especialista em !TIL® (Information Technology In frast ructure Library) na
He,vlett-Packard, discute sua visão de excelência em gestão de projetos:
A excelência não é classificada po r meio do gerenciamento das peças, mas da compreensão
de co mo as peç.as se encaixam umas nas o utras, sustentam as dependências umas das o utras
e agregam valor para a empresa. Se a gestão de projetos fizer a penas o q ue tem de ser feito,
como gerenc ia r 300 projetos individ ua is no próximo trimestre, estará propiciando uma
função de baixo valo r agregado q ue fundamentalmente funciona como o "burro de carga"
q ue é necessário, mas que só faz aq uilo q ue tem de fazer - e ma is nada. As Figuras 4-1 e
4- 2 demonstram que se associarmos a gestão de projetos à estrutu ra geral de gerenciamento
de lançamentos de uma empresa, cada projeto é gerenciado independentemente, co m as
características exibidas.
Usando a mesma estrutura de lançamento e as mesmas solicitações dos cl ientes, as dis-
ciplinas da gestão de projetos podem co mpreender a na tureza das exigências e prestar um
serviço va lioso ao agrupar em "pacotes" os mesmos tipos de solicitações (projetos) com
o intuito de gerar uma previsão do trabalho, o q ue a ux ilia rá a empresa a equilibrar suas
finanças, expectativas e recursos. Essa função pode ser realizada no PMO.
Na DTE Energy, a excelência etn gestão de projetos é definida usa ndo a metodo-
logia de gestão de projetos. Segundo Jason Schulist, gerente de melhorias contínuas da
Operating Systems Strategy Group:
A DT E Energy promove um modelo de gestão de projetos de melhorias contínuas com
q uatro pontos de decisão/nove passos. (Ver Figuras 4-3 e 4-4.) No ponto de decisão 1, a
liderança do projeto define claramente a métrica que irá ava lia r o sucesso do projeto. No
ponto de decisão 2, depois de o estado ideal ter sido definido, a liderança do projeto recebe
aprovação de seu patrocinador co nvicto, confirmando não somente que as métricas foram
apropriadas, mas também o alvo.
Esse a lvo de sucesso é mantido d urante todo o projeto e não é concl uído (ponto de deci-
são 4) a menos q ue o a lvo seja atingido. Se o projeto não atingir o alvo por meio das ações
1
H. Kerzner, Projec.r Nfanagemenr Best Practices: Acl,ieving Global Exallence, \-Viley, Hoboken, NJ, 2006,
p. 136.
Capítulo 4 Metodologias de gestão de projetos 19 1
Planejamento , Design/Testes Implementação ; Operações ~

Projeto 1 Caracterlsllcas
Projeto 2 • Todos os projetos gerenciados
Projeto 3 independentemente
Projeto 4
• Abordagem individualizada
Projeto 5
produz pequenos ganhos
Projeto 6
Projeto 7 • Alto custo para gerenciar
Projeto 8
todas essas liberações para
Projeto 400 operações
• Alto custo para testar e
certificar cada liberação
independentemente
• Ausência de controle geral
• Pouco planejamento, maior parte
reagindo e acertando pedidos
SOLICITAÇÕES OOS CLIENTES
Figura 4-1 Etapas do gerenciamento de liberação.
Planejamento - Design/Testes ~ Implementação - Operações ~

Caracterlsllcas
• Todos os projetos agrupados
segundo impactos similares
causados à infraestrutura
• ''Pacotes" planejados, projeta-
dos, testados e implementados
como um grupo
• Custo reduzido pelos esforços
consolidados
• Redução dos riscos devido à
compreensão do impacto total
sobre as operações
• "Pacotes" são planejados e
estimados; resultados em
gerenciamento estratégico, e
não reativo
SOLICITAÇÕES DOS CLIENTES
Figura 4-2 Etapas do gerenciamento de liberação: agrupando as solicitações.
realizadas, volta ao ponto de de.c isão 2, onde o estado ideal é revisado e novas funções são
determinadas.
Allan Dutch, profissiona l de gestão de projetos (PMP®), gerente de projetos sênio r
em engenharia de software, métodos e alocação de pessoal da DTE Energy, acredita
que:
O projeto de tecnologia da in formação (TI) da DTE Energy que exibe s ucesso e excelência
em gestão de projetos é aquele em que o gerente de projetos cond uz sua equipe da mesma
forma que um maestro rege s ua orquestra. O valor de negócio é demonstrável e reconhecido
pela unidade de negócio enquanto as interações com as organizações de apoio e os requisi-
tos de infraestrutura são coordenados suavemente e de acordo com o plano.
.7 DTE Energy
eaola dB dBtisaa l; Alcalia,aa

• Revisar avaliações
• Especificar oponunidades para a fase de design
• Apresentar linha do tempo do projeto
• Planejar os requisitos de recursos
• Chegara um acordo quanto a alvos, resultados e mensurações
1. Identificar o projeto e
-, 2. Formar equipe e 3. Aw/iar e analisar
ressaltar a$ opOftunidades refinar esoopo i---, realidade atual
que o projeto traz
J.
Ponto de decisão 4: Resultados 4. Definir resultados
• Revisar resultados do projeto 9. Reconhecer o lrabalho dasejados/estado ideal
• Garantir que haja mecanismos que da equipe, refletir e
comunicar ~ultados
sustentem os resultados !
• Planejar oomunicações a outros t S. Identificar lacunas e
departamento-s 8. Medir o progresso contramedidas do
do projeto e sustanta.r projeto
• Planejar evento de comemoração (se necessârio) seus objetwos
' /
7. T~tat. refinar e 6. Criar um plan~mestre
snj)lementar sduç~ para implarnentar
doproje1o SOIIJQÕ8S
Ponto dl decisã~ 3: lmglementação

• Revisar desempenho do plano Ponto de decisão 2: Design
• Abordar lacunas e contramedidas do plano • Revisar design do estado ideal do processo/sistema
• Discutir o progresso rumo aos alvos do projeto • Garantir que fatores críticos de sucesso sejam abordados
• Garantir que os resuhado-s se;am alcançados • Garantir que os alvos do projeto sejam atingidos
• Abordar barreiras e obstâculos
• Revisar requisitos de recursos
• Chegar a um acordo quanto ao prazo da impt,ementação la;;;
Figura 4-3 Modelo de gestão de projetos com quatro pontos de decisão e nove passos.
4.2 Reconhecendo a necessidade do desenvolvimento

de uma metodologia
A existência e a observância de u1na metodologia de gestão de projetos não bastam
para levar a empresa ao sucesso e à excelência e1n gestão de projetos. A necessidade de
melhorias no sistema pode ser crucia l. Fatores externos podem ter uma forte influência
sobre o sucesso ou fracasso da metodologia de gestâo de projetos de uma empresa. As
mudanças são uma certeza no atual clitna e1npresarial, e não há sinais de que o futuro
será d iferente. É mu ito improvável que os rápidos avanços tecnológicos que impu l-
sionaram mudanças na gestão de projet os nas duas últimas décadas es1noreça1n. Uma
outra tendência, a crescente sofist icação dos consu1nidores e clientes, provavelmente
cont inuará. O controle de custos e de qualidade tornaram-se praticamente a 1nesma
coisa em mu itos setores. Out ros fatores externos incluem fusões e aquisições repenti-
nas e comun icações em tempo real.
As metodologias de gestão de projetos são processos "orgânicos" e precisam
acompanhar as mudanças que ocorrem nas organizações em resposta a um clima em-
presarial que se encontra em constante evolução. Isso exige que os gerentes de todos os
níveis tenha1n um compromisso com as mudanças e desenvolva1n u1na visão que con-
Cap ítulo 4 Metodologias de gestão de p rojetos 193
1,1.J lden.tiliear lfl'UJ!IO potMcbl

Chaves do sueesso: • V02 do consumidor
' E,e"mPliosd; .-.---- --,/

• AntlliSedospoo1os iortes. t"acos.
1. Disciplina em relação ao modelo de q:io111mldad!s e ame~s (SWOTJ -nldldU
gestão de projelos
2. Usar a lena menta certa na hora certa
• Busca aa ronw dop(Oblema (w.tstt W.bt,)
• PrOO!Ssode planejlmentolntegmo•
• Diagram de dlq)ersJ~~lise de tegrm:Jo'
/ de .-thorlas
/ • Rt'dl.llif OS cus:,os .. I
I
I
----
/ EP fflPIOS -------- ---
dft orobltMH I
. """""'"'19
I
I
I
""''
• A..rnetnat a WI I
I
I • Fahas no resen<iitMo 8oll!r I di cobrança de I

Cri.Wriot 111e sele~ 111e preJeLOs I • Rt'd!Jlif as botas
• OIIIO$ eauSJdos pOI' 1ercei'Os àtubul~o / I
I
I
• Fns no IJ11'1Stoonador /
• Resullidos ou OMeftclc:$ de negOCio
· Vlddade
'--r-------
.. ___
I
I
'---- --,---------
• Erros de contabiilJde
• Erros do lellOI' de mediljOr
1
I
I • lmpae,o orgrit.JeitWI
• op..-d1dede
•
L!J
'---, 1
Fo1111ar eq11i,e e reilUr escopo
• fSt.lbel!Cet pa!tOOIUdOf,
l'lltlliorla Nefllilcada
• Processo podetla ser
rellzado mais tapido.
l der e lt'll!fftl(o, de t'(llife
•
PrMlema .._tlkldo
• Termo d! abert.n do projeio
• Oiagrnas de atmdade
mais barato.lTlebM'
ffrraiaNIH e-,MlilkH
• Prooesoo fl:0 esa • Cliagr.wade KaM/ÃtYofe CIO' • Mlrtshop$ SODre o
cumprkldo req11.s1tos • DiagrnaSIPOC'
lnteroos ou exiemo:s t)'OQtllma de ~lldade SS
• • ldernllk3ç.1o de detptrdieos
Ferramentas especlllett
• Gdfleo9 de P.ireio
• Hi!logramas,
IJ.J Antillr e 1n1lb 1r m lid*
Ferrllfl'lentas comun,
11Ual .........
• Superpt~O
• De!ellos
• Ciplcldad! do processar
anàfSe de val"iaÇ.10'
• An&e de Modos e
• Mapeamento ae prOO!Ssos
• MIEM de e:wsas-raiZf
...._..
• TtabialOerti WBO
• Ttanspone
Beitos de Falha (fMf.A') d3(1rwnas de causa e e1l'i10
• &pera
• Diagrama de dlspersJOi • Gdflc($ St'qü!Aeiais
anàfSe de regress;Jo' • FOihas d! ...et1t1caçao
• Smls.bçati do cten1e
• An&e de confiabili:lJde • ,
• Plane!ifflMlo de expetinentot Ponto de decisão 1
'
L!.J Oellnlr 1ewll1dos desejadolfeslldt ldeal
• VOl do COl'$11midor (VOC)
'
. """""'"'19
• MlfSe dos poo1os rories. tacos.
q,onunldades e ame.çts lSWOl)
• PlltlO de negócios
Pro-.1 lde ..lllCldO

L!J
• Dportu.-.ede
aelhori1 lde•111e1d1
ldM!lllt11 ~1,c11nu· e
ferrllfl'lentas especillcas
contr1.-.1das do projete ff!rralaNIH es,edlkls
• Grifleo9 de P.ireio
• ReduÇ.10 do 1eiq)O de
• Clpacldad! do processar Ferrllfl'lentas com11ns
anàfSe de val"iaÇ.10' lns.tm'IÇ.10
• Prl!'MIÇlo de etros (M'Ot/JIOIJ/itJ(J) • KtltlStJop$ ~ o pro-
• Anatisede regres!.ão' • M.peamento domado Ideal gl'lffll de qualidade SS
• An&e de confiab!li:lJde' • SWI • F~ViSual
• Tes!edeh9ólt'Se$'
• PlanejlmM!o de expeti- • ( M.sv.l(fJtlOl)t
tnetllOS' (DOE) .!!.J
Cri11 plano mem
1.,iemen.1111 SOfal:IH
'*' (""'_...,
• f111J10 oom~uo
• Mi11"2 de analise de dec:asões

• CrbÇlo de ptino mes.1re
• Gestao de tnudil'lças
Ponto de decisão 2
l,LJ
• '
Tetllr, rerrn. e lfl'lple,nenl.lr

toluçlies de projete
• Jes!es Jioto
• PrOO!SSO de ges.tao de ll'ltl~S
· Mlrt (MH AC*iOO Re\li!WS)
.
ProMefl'II id. .llletdO ~
• op..-d1dede
Ponto de decisão 3
melliorla Nefllillc8d8
Medir o pro0mso ,e (lrtjel.G e
Ferr1mentas especllltH tlldenta, "'""'lvot ff!rralaNIH es,Kfficas
• Gdfloosd! PMt10 Ferrllfl'lentas COfllllM • Anatlse de red~o de
• Gdfloosd! con1,01e• • Sm!s.bçati do ctente •mpo
• Tes!edebípOl!Ses• • Anatlsedered~ode
• Gdflc($ St'qü!AeiilS'
• CUS.10
• SWI
• FOihas d! ...~ F~ViStlal
• Alldi!OOlS de pontot de OCl'ltrole
L!J
•
Reconhecer o , ,11,. . dl eq11r,e,
rteeli' e com11n1ca, rewllados
· Miro
• Mhll'ieis balance3d3S
• COll'l!ll'IOOIÇ.10
. Ponto de decisão 4
Figura 4-4 Modelo de quatro pontos de decisão e nove passos e mapa do processo de seleção de
ferramentas.
vida ao desenvolvimento de siste1nas de gestão de projetos juntamente com os outros

siste1nas empresariais do restante da organização.
Atua lmente, seja1n orientadas a projetos ou não, as empresas estão gerenciando
seus negócios por meio de projetos. Praticamente todas as atividades de uma organiza-
ção podem ser t ratadas como algum tipo de projeto. Portanto, faz sentido que as em-
presas bem gerenciadas tomem a 1netodologia de gestão de projetos como uma forma
de gerenciar todo o negócio, em vez de apenas projetos. Os processos de negócios e os
processos de gestão de projetos irão se fund ir quando o gerente de projetos passar a
ser visto como pa rte de um negócio.
Desenvolver uma metodologia-padrão de gestão de projetos não é tarefa para
qualquer e1npresa. Para empresas com projetos de pequeno porte ou de cu rto prazo,
sistemas tão formais podem não ser apropriados ou não ter uma boa relação custo-
-benefício. Entretanto, pa ra empresas com projetos de grande porte ou de longo prazo,
desenvolver u1n sistema viável de gestão de projetos é indispensável.
Por exen1plo, uma empresa que produz utensílios domésticos tinha un1a série de
protocolos de desenvolvimento de projetos em uso. Quando con1eçaram a empregar
a gestão de projetos de forma sisten1ática, a con1plexidade dos métodos se tornou
aparente. A empresa tinha diversas metodologias de desenvolvimento de sistemas,
dependendo do tipo de projeto, o que era muito incômodo para os funcionários. A
en1presa, então, optou por criar uma única metodologia para todas as finalidades e
projetos. A nova metodologia tinha uma flexibilidade inerente. Segundo o porta-voz
da empresa:
Nossa abordagem de gestão de projetos, por definição, não está ligada a nenhuma metodo-
logia específica de desenvolvimento de sistemas. Como acreditamos que é melhor usa r uma
única metodologia (padrão) de desenvolvimentos de sistema do que ter q ue decidir qua l
empregar, demos início ao desenvolvimento de diretrizes para a metodologia de desenvol-
vimento de sistemas específica à nossa organização. Agora já desenvolvemos pré-requisitos
para o s ucesso dos projetos. Alguns deles são:
• Metodologia padronizada
• Conjunto claro de o bjetivos
• Expectativas bem compreendidas
• Definição minuciosa de problemas
D urante o fina l da década de 1980, u1na onda de fusões atingiu a comunidade
bancária. Com a redução dos custos devido a economias de escala e a 1naior compe-
titividade daí resultante, a comun idade bancária reconheceu a importância da utili-
zação da gestão de projetos para fusões e aquisições. Quanto 1nais rapidamente as
duas culturas se tornassem uma só, menor o impacto sobre o resu ltado financeiro da
corporaçao.
A necessidade de uma boa metodologia tornou-se óbvia, segundo o porta-voz de
u1n banco:
A intenção dessa metodologia é tornar mais eficiente o processo de gestão de projetos: da
proposta e priorização à a provação e implementação. Essa metodologia não é adaptada a
tipos ou classificações específicas de projetos, como os esforços de desenvolvimento de sis-
temas ou as instalações de hardware. Ao contrário, é uma abordagem sensata para auxiliar
na priorização e implementação bem-sucedida dos esforços de qualquer jurisdição.
Em 1996, a divisão de serviços de informação($!) de um banco formou uma equi-
pe de reengenharia de SI com o intuito de se focalizar no desenvolvimento e implemen-
cação de processos e ferra 1nentas associados à gestão de projetos e ao desenvolvÍlnento

de sistemas. A missão da equ ipe de reengenharia de SI era melhorar o desempenho dos
projetos de SI, resulcando em maior produtividade e melhor tempo de ciclo, qualidade
e satisfação dos clientes dos projetos. Segundo um porta-voz do banco, o processo
começou da seguinte maneira:
Informações canto das metodologias correntes quanto das anteriores usadas pelo banco fo-
ram revisadas, e as melhores práticas de todos esses esforços anteriores foram incorporadas
a esse documento. Independente da fonte, as fases da metodologia de projetos são relativa-
mente padronizadas. Todos os projetos seguem os mes mos passos, sendo que a complexida-
de, tamanho e tipo de projeto determina até que ponto a metodologia tem que ser seguida.
O que essa metodologia enfatiza são controles de projeto e vínculo entre os de/iverab/es e os
controles para alcançar o s alvos.
Para determ inar os pontos fracos associados às metodologias de gestão de pro-
jetos passadas, a equipe de reengenharia de SI conduziu vários grupos de foco. Esses
grupos concluíram que havia:
• Falta de compro1n isso da gerência
• Ausência de u1n mecanismo de feedback para os gerentes de projeto determinaretn
as atua lizações e revisões necessárias para a metodologia
• Ausência de metodologias adaptáveis para a organ ização
• Ausência de um programa de treinamento para os gerentes de projeto sobre a
metodologia
• Ausência de foco em uma comunicação consistente e periódica sobre o progresso
da Ílnplementação da metodologia
• Ausência de foco sobre as ferramentas e técnicas da gestão de projetos
Com base neste feedback, a equipe de reengenharia de SI desenvolveu e i1nple-
mentou com sucesso uma metodologia de gestão de projetos e desenvolvünento de
sistemas. De junho a dezembro de 1996, o público-alvo de 300 gerentes de projetos
se conscientizou e aplicou uma metodologia e uma ferramenta-padrão de gestão de
projeto (MS Projecc).
O banco fez um excelente t raba lho com a criaç.ã o de u1na metodologia que reflete
diret rizes, e não políticas, e oferece procedimentos que podetn facilmente ser adapta-
dos a qualquer projeto do banco. A seguir, discutiremos componentes selecionados da
metodologia de gestão de projetos.
Organização
Com qua lquer projeto, você deve defin ir o que precisa ser a lcançado e decidir como
o projeto chegará a esses objetivos. Cada projeto começa com uma ideia, visão ou
oportunidade de negócio, um ponto de partida que ten1 de ser vinculado aos ob-
jetivos de negócio da organização. O termo de abertura do projeto é o al icerce do
projeto e forma o contrato com as partes envolvidas. Ele inclui un1a declaração das
necessidades do negócio, um acordo sobre o que o projeto se con1promete a produ-
zir, uma identificação das dependências do projeto, os papéis e responsabilidades dos
n1embros de equipe envolvidos, e os padrões de como o orçamento do projeto e a
gestão de projetos devem ser abordados. O tern10 de abertura do projeto define os
seus lin1ites.
Planejamento
Uma vez que os li1n ites do projeto esteja tn definidos, devem-se levantar informações
suficientes para sustentar os a lvos e objetivos e pa ra limita r o risco e minimizar os
p roblemas. Esse componente da gestão de projetos deve gerar informações suficientes
pa ra estabelecer claramente os deliverables que precisam ser concluídos, defin ir as
tarefas específicas que garantirão a conclusão desses deliverables e esboçar o nível
apropriado de recursos. Cada deliverable influencia cada fase do projeto, se irá ou não
atingir seus alvos, orçamento, qualidade e prazo. Por uma questão de simpl icidade,
a lguns projetos adotam uma abordagem de quat ro fases:
• Proposta: in iciação e definição do projeto.
• Planejamento: planejamento do projeto e definição dos requisitos .
• Desenvolvimento: desenvolvimento dos requ isitos, testes e treina tnentos.
• lmple1nentação: implantaç.ã o dos requisitos desenvolvidos para a operação diária .
Cada fase contém pontos de revisão que ajudam a garantir que as expectativas de
cada projeto e deliverables de qual idade sejam alcançados. É itnportante identificar
os revisores do p rojeto o mais cedo possível para garantir o equ ilíbrio adequado do
envolvimento de especia listas no assunto e a gerência.
Gerenciamento
Durante todo o projeto, o gerenciamento e o controle do processo precisam ser manti-
dos. Essa é a oportunidade para o gerente de projeto e a equ ipe ava liarem o projeto, o
seu desempenho e cont rolarem o desenvolvitnento dos deliverables. Durante o projeto,
as seguintes áreas devem ser gerenciadas e controladas:
• Avaliar o progresso diário das ta refas e deliverables do projeto por meio da men-
suração de orçamento, qualidade e tempo de ciclo.
• Ajustar as tarefas e deliverables do projeto a cada d ia em resposta a variâncias e
problemas imediatos.
• Resolver proativamente os problemas e 1nudanç.as do projeto para controla r even-
tuais 1nudanças graduais no escopo.
• Ter como objetivo a satisfação do cliente.
• Estabelecer revisões periód icas e estruturadas dos deliverables.
• Estabelecer um arqu ivo cent ralizado de controle do projeto.
Dois mecanismos essenciais para gerenciar projetos co1n sucesso são procedimen-
tos sólidos de geração de relatórios de status e procedimentos de gerenciamento de
p roble1nas, p reocupações e mudanças. Os relatórios de status são necessários para
manter o curso e a saúde do projeto. O relatório de status deve incluir o seguinte:
• Realizações importantes até o 1no1nento
• Realizações planejadas para o período seguinte
• Resumo do progresso do projeto:
• Percentual de horas de t raba lho consum idas
• Percentual de custos orçamentários consumidos
• Percentual do prazo do projeto consumido
• Resumo dos custos do p rojeto (custos orçados vers,,s rea is)
• Problemas e preocupações do projeto
• Impacto sobre a qual idade do projeto
• Providências to1nadas pela gerência
O gerencia tnento de problemas e 1nudanç.as protege o andamento do projeto, pro-

porcionando flexibi lidade. Os problemas do projeto são questões que exigetn que o
gerente de projeto, a equipe do projeto ou a gerência tome decisões. O gerencia1nento
de problemas do projeto precisa ser definido e devidamente comunicado à equipe de
projeto, de modo a garantir o nível adequado de acompanhamento e monitora tnento
dos problemas. Esse mesmo princípio está relacionado ao gerenciamento de mudanças
porque, inevitaveltnente, o escopo de um projeto estará sujeito a algu tn tipo de mu -
dança. Qua lquer gerenciamento de 1nudanças no projeto que afete os custos, o prazo,
os deliverables e os projetos dependentes deve ser informado à gerência. Os relatórios
sobre o gerenciamento de problemas e mudanças devem ser resumidos no relatório de
status, indicando o número de itens etn aberto ou já solucionados de cada um deles.
Isso auxi lia a gerência na ava liação da saúde do projeto.
Simplesmente ter uma metodologia de gestão de projetos e empregá-la não leva à
maturidade e à excelência na área. É preciso haver uma "necessidade" de melhorar o
sistema, de ,nodo que ele ascenda à maturidade. Os sistemas de gestão de projetos po-
dem mudar à medida que ocorrem mudanças na organização. Entretanto, a gerência
deve ter um compromisso com as mudanças e uma visão que permita que os sistemas
de gestão de projetos evolua tn na organ ização.
4.3 Metodologias empresariais de gestão

de projetos
A n1aioria das empresas hoje parece reconhecer a necessidade de uma ou ma is meto-
dologias de gestão de projetos, mas ou crian1 as metodologias erradas, ou fazem mau
uso das metodologias que foram criadas. Muitas vezes, as en1presas se precipitan1 em
desenvolver ou adqu irir uma n1etodologia sem antes compreender qual a necessida-
de de possuir uma alén1 do fato de seus concorrentes já possuíren1. Jason Charvat
declara:'
Usar metodologias de gestão de projetos em uma estratégia de negócios permite que as em-
presas maximizem o valor do projeto para a organ ização. Uma metodologia tem de evoluir
e ser ajustada para acomodar as mudanças no foco ou na direção de uma empresa. Trata-se
quase de uma mentalidade, uma maneira que remodela todos os processos organizacionais:
vendas e marketing, projeto de produtos, planejamento, implementação, recrutamento, fi-
nanças e suporte a operações. Apresenta uma mudança cultural radical para muitas orga-
nizações. À medida que os setores e empresas mudam, mudam também suas metodologias.
Caso contrário, estarão perdendo uma oportun idade.
Metodologias são conjuntos de fo rn1ulários, diretrizes, te1nplates e listas deve-
rificação que poden1 ser aplicados a un1 projeto ou situação específica. Talvez não
seja possível criar un1a única n1etodologia que abranja toda a empresa e possa ser
aplicada a todo e qualquer projeto. Algun1as empresas tên1 tido êxito com isso, mas
ainda há muitas que mantêm com sucesso mais de un1a metodologia. A menos que
o gerente de projeto seja capaz de adaptar a n1etodo logia en1presarial de gestão de
projeto às suas próprias necessidades, pode ser necessário que haja mais de un1a
n1etodologia.
2
J. Charvar, Project Management Metl,odologies, Hoboken, NJ: Wiley, 2003, p. 2.
Há vários motivos pelos quais boas intenções muitas vezes se desencaminham.

Nos níveis executivos, as metodologias podem falhar se os executivos tiverem uma
compreensão precária de o que uma metodologia é e acreditare1n que ela seja:
• uma soluç.â o paliativa;
• um método infa lível;
• uma solução te1nporária;
• uma "receita" para o sucesso dos projetos3.
Nos níveis dos trabalhadores, as metodologias também podem falhar se:
• forem a bst ratas e de a lto nível;
• contiverem narrativas insuficientes para sustentá-las;
• não forem funcionais ou não abordarem áreas cruciais;
• ignorarem os padrões e as melhores práticas do setor;
• parecerem impressionantes, mas não apresenta rem uma verdadeira integração ao
negocio;
• usarem convenções e tenninologia que não sejam padrão para projetos;
• competirem por recursos simi lares se1n abordar esse problema;
• não possuírem nenhuma métrica de desempenho;
• levarem ten1po demais para serem conclu ídas devido à burocracia e adn1inistração•.
Decidir sobre o tipo de 1netodologia a ser empregada não é uma tarefa sÍlnples. Há
muitos fatores a serem considerados, como:
• A estratégia geral da empresa - quão competitivos somos co1no empresa?
• O ta1nan ho da equipe de projeto e/ou do escopo a ser gerenciado
• A prioridade do projeto
• A importância do projeto para a empresa
5
• O grau de flexibi lidade da metodologia e seus co1nponente.s
As n1etodologias da gestão de projetos são criadas en1 torno do nível de ma-
t uridade da empresa e de sua cult ura corporativa. Se a empresa for razoaveln1ente
madura em gestão de p rojetos e possuir un1a cult ura que estin1u le a cooperação,
a con1un icação eficiente, o trabalho en1 equ ipe e a confiança, então se pode criar
un1a n1etodologia extremamente flexível baseada en1 d iretrizes, forn1ulários, lis-
tas de verificação e templates. Os gerentes de projeto podem escolher as partes da
metodo logia que são adequadas a un1 cl iente específico. As organ izações que não
têm nenhuma dessas duas características dependem fortemente de metodologias
construídas com políticas e procedimentos rígidos, criando, dessa forma, un1a buro-
cracia significativa acompanhada por aumentos de custos e perda da flexibi lidade
de que o gerente de projetos precisa para adaptar a n1etodologia às necessidades de
cada cl iente específico.
Jason Charvat descreve esses dois tipos como metodologias leves e 1netodologias
6
pesadas.
3
lbid., p. 4.
' lbid., p. 5.
' lbid., p. 66.
' lbid., p. 102- 104.
Metodologias leves
Complexidades tecnológicas cada vez maiores, at rasos nos projetos e 1nudanças nas
solicitações dos clientes geraram uma pequena revolução no mundo das metodologias
de desenvolvimento. Um tipo de metodologia totalmente novo - que é ági l e adaptável
e envolve o cliente em todas as partes do processo - está começando a surgir. Muitos
dos defensores de 1netodologias pesadas se opuseram à introdução dessas metodolo-
gias "leves" ou "ágeis" (Fo,vler, 2001 7) . Essas metodologias usam um estilo comunica-
tivo informa l. Ao contrário dos projetos que usam metodologias pesadas, os projetos
leves possuem apenas algumas poucas regras, práticas e documentos. Os projetos são
elaborados e construídos em discussões presencia is, reuniões e baseados no fluxo de
informações para os clientes. A diferença imediata do uso de metodologias leves é que
elas são muito 1nenos orientadas a docu1nentações, normahnente enfatizando u1na
quantidade menor de documentaç.ã o para o projeto.
Metodologias pesadas
As metodologias tradicionais de gestão de projetos (i.e., abordage1n CVDS, ou de ciclo
de vida de desenvolvin1ento de sistemas) são consideradas burocráticas ou de natureza
" preditiva" e resultaram en1 muitos projetos ma lsucedidos. Essas metodologias pesadas
estão se tornando n1enos popu lares. Elas são tão laboriosas que todo o ritmo do design,
desenvolvin1ento e in1plen1entação desacelera - e não se realiza nada. Os gerentes de
projeto tendem a prever cada n1arco porque querem prever cada detalhe técn ico (i.e.,
deta lhe de código de softiuare ou de engenharia). Isso leva os gerentes a começ.arem a
exigir muitos tipos de especificações, planos, relatórios, pontos de verificação e cronogra-
mas. As n1etodologias pesadas tentam planejar uma grande parte de um projeto em alto
nível de detalhamento por un1 longo período de ten1po. Isso funcionava bem até as coisas
con1eçaren1 a mudar, e os gerentes de projeto inerenten1ente tentan1 resistir a n1udanças.
As 1netodologias empresariais de gestão de projetos podem 1nel horar o proces-
so de planejamento, alé1n de oferecer certo grau de padronização e consistência. As
empresas chegaram à conclusão de que as metodologias empresariais de gestão de
projetos funcionam melhor se forem baseadas em templates e1n vez de em políticas e
procedimentos rígidos. O Intemational Institute for Learning criou u1na Metodologia
Un ificada para a Gestão de Projetos (UPMM"'', Unified Project Manag_ement Me-
thodology ), co1n templates classificados de acordo com o G11ia PMBOK"', 4• ed ição,
' 8
Areas de Conhecimento:
Comunicação:
Termo de abertura do projeto
Documento de procedi1nentos do projeto
H istórico de solicitações de mudanças no projeto
Relatório de status do projeto
Relatório de garantia de qua lidade do GP
Resu1no do gerenciamento de aquisições
H istórico de problemas do projeto
Plano de gestão de projetos
Relatório de desetnpenho do projeto
7
M. Fowler, The New Metodologia, l11oughrWorks, 2001. Disponível em: www.marcin.fowler.com/arcicles/
n.ewmechodology.hcml.
1
A U11ified Project Ma11agement Metl,odology (UPMM.n.1) é registrada, protegida pela lei de direfros aurorais
e de propriedade do Inremacion.al lnsricure for Leaming, Inc., e 2009; reproduzido com permissão.
Custo:
Cronograma do projeto
Plano e registro de resposta a riscos
Estrutura analítica do projeto (EAP)
Pacote de trabalho
Documento de estimativas de custo
Orçamento do projeto
Lista de verificação do orçamento do projeto
Recursos humanos:
Plano de gerenciamento de comunicações
Diagra1na de organização do projeto
Diretório da equipe de projetos
Matriz de responsabilidades (MR)
Documento de procedimentos de projeto
Lista de verificação da reunião inaugural
Avaliação de desempenho da equipe de projetos
Avaliação de desempenho do gerente de projetos
Integração:
Panorama dos proceditnentos do projeto
Proposta de projeto
Plano de gerenciamento de comunicações
Plano de aquisições
Orçamento do projeto
Documento de procedimentos do projeto
Matriz de responsabilidades (MR)
Plano e registro de respostas a riscos
Declaração de escopo
Histórico de solicitações de mudanças no projeto
Histórico de problemas do projeto
Histórico de mudanças no plano de gestão de projetos
Relatório de desempenho do projeto
Documento de lições aprendidas
Feedback sobre o desempenho do projeto
Documento de aceitação de produto
Lista de verificação de avaliação de encerramento de processo
Relatório dos arquivos do projeto
Aquisições:
Declaração de escopo
Lista de verificação do planejamento das aquisições
Declaração de trabalho (DT) de aquisições

Solicitação de esboço do documento de proposta
H istórico de solicitações de mudanças no projeto
Lista de verificação de formação de cont rato
Resu1no do gerenciamento de aquisições
Qualidade:
Panorama dos procedimentos de projeto
Plano de qualidade no trabalho
Relatório de garantia da qua lidade em GP
Documento de lições aprendidas
Feedback sobre o desempenho doe projeto
Avaliação do desempenho da equipe de projeto
Documento de melhorias nos processos de GP
Riscos:
Documento de procedi1nentos do projeto
Escopo:
Declaração do escopo do projeto
Pacote de trabalho
Tempo:
Plani lha de estimação da duração das atividades
Documento de estimativas de custos
Pacote de trabalho
Lista de verificação para revisões do cronograma do projeto
4.4 Benefícios de uma metodologia-padrão

Para empresas que compreendem a Ílnportância de uma metodologia-padrão, os be-
nefícios são inú1neros. Esses benefícios podem ser classificados como benefícios de
curto e de longo prazo. Os benefícios de curto prazo foram descritos por u1na e1npresa
como:
• Tempo de ciclo menor e custos mais ba ixos
• Planos rea listas com maiores possibil idades de cumprimento de prazos
• Melhores comunicações quanto a "o que" se espera dos grupos e "quando"
• Feedback: lições aprendidas
Esses benefícios de curto prazo enfocam os indicadores-chave de desempenho

(KPls, key perfor,nance indicators) ou simplesn1ente a execução da gestão de proje-
tos. Os benefícios de longo p razo parecen1 priorizar mais os fatores críticos de su-
cesso (CSFs, criticai success factors) e a satisfação do cl iente. Os benefícios de longo
prazo do desenvolvimento e da execução de uma metodologia de classe mundial
incluen1:
• Menor " tempo para colocação no mercado" por meio de u1n melhor controle de
escopo
• Menor risco gera l para o progra1na
• Melhor gestão dos r iscos, o que leva a uma melhor tomada de decisões
• Maior satisfação e confiança do cliente, o que leva a ma is negócios e maiores res-
1;onsabilidades para os fornecedores de tier 1
• Enfase na satisfaç.ã o do cl iente e em valor agregado em vez de em concorrência
interna entre grupos funciona is
• Cliente t rata o fornecedor como "parceiro" em vez de como "mercadoria"
• Fornecedor auxi lia o cliente durante as atividades de planeja1nento estratégico
Talvez o maior benefício de uma metodologia de classe mundia l seja a aceitação
e o reconhecimento por seus clientes. Se um de seus clientes mais itnportantes desen-
volver sua própria metodologia, esse cliente poderia "forç.á -lo" a aceitá-la e empregá-
-la como condição para continuar sendo seu fornecedor. No entanto, se você puder
mostrar que sua metodologia é igual ou superior à do cl iente, ela será aceita, fazendo
preva lecer uma at1nosfera de confiança.
Um fornecedor descobriu recentemente que seu cliente tinha tanta fé e respei-
to por sua metodologia que o convidou a pa rticipar das atividades de planejamento
est ratégico dele. O fornecedor estava sendo tratado como parceiro em vez de como
commodity ou apenas mais um fornecedor. Isso resultou em contratos de aquisição de
fornecedor único para o fornecedor.
Desenvolver uma metodologia-padrão, que englobe a maioria dos projetos de
u1na empresa e seja aceita por toda a organ ização é uma tarefa árdua. A parte 1na is
d ifícil provavelmente seja garantir que a metodologia suporte tanto a cultura corpora-
tiva quanto os a lvos e objetivos estabelecidos pela gerência. As metodologias que exi-
ge1n 1nudanças em uma cultura corporativa ta lvez não sejam muito bem-aceitas pela
organ ização. Culturas que não apoiam u1na 1netodologia podem destruir até mesmo
metodologias de gestão de projetos que pareçam boas.
Durante as décadas de 1980 e 1990, várias e1npresas de consultoria desenvolviam
suas próprias metodologias de gestão de projetos, na maioria das vezes para projetos
de siste1nas de informação, e então pressionavam seus clientes a comprar a metodolo-
gia em vez de ajudá-los a desenvolver uma que fosse ma is adequada às necessidades
deles. Embora talvez tenham ocorrido a lguns sucessos, parecia haver um número sig-
nificativamente maior de fracassos. Um hospita l co1nprou uma metodologia de gestão
de projetos no va lor de US$130 1nil, acreditando que essa seria a solução para suas
necessidades relativas a sistemas de informação. Infelizmente, a gerência sên ior decidiu
comprá-la sem consultar os trabalhadores que usariam o sistema. No fim das contas,
o pacote nunca foi util izado.
Uma outra empresa comprou um pacote sim ilar, descobrindo tarde dema is que
ele era inflexível e que a organ ização, especificamente a cultura corporativa, teria de
mudar para poder empregar a metodologia de gestão de projetos eficientemente. O
fornecedor admitiu posteriormente que os melhores resultados seriam alcançados se
não fosse feita mudança a lgu1na na metodologia.
Esses tipos de metodologia são extren1amente rígidos e baseados em políticas e pro-

cedimentos. A possibilidade de personalizá-los a projetos e culturas específicas era ine-
xistente, e, finalmente, caíram em desuso - n1as son1ente depois de os fornecedores terem
obtido lucros significativos com sua venda. Boas metodologias precisan1 ser flexíveis.
4.5 Componentes críticos

É praticamente impossível tornar-se uma empresa de classe mundial em gestão de pro-
jetos sem possuir uma metodologia de classe 1nundial. Há vários anos, ta lvez apenas
algumas poucas empresas reahnente tivessem metodologias de classe mundial. Hoje,
devido à necessidade de sobrevivência e do acirratnento da concorrência, há inúmeras
empresas com boas 1netodologias.
As características de uma metodologia de classe mundial incluem:
• Máximo de seis fases de ciclo de vida
• Superposições nas fases do ciclo de vida
• Revisões de final de fase
• Integração com outros processos
• Melhoria contínua (i.e., ouvir a voz do cliente)
• Orientação ao cliente (interface com a 1netodologia do cliente)
• Aceitação em toda a etnpresa
• Utilização de tetnplates (est rutura analítica do projeto [EAP] nível 3)
• Cronograma do caminho crítico (EAP nível 3)
• Relatórios de gráficos de barras simplistas e padronizados (software-padrão)
• Mini1nização da papelada (burocracia)
De 1naneira geral, cada fase do ciclo de vida da metodologia de gestão de projetos
exige documentação, pontos de controle e, ta lvez, requisitos administrativos especiais.
Ter poucas fases de ciclo é um convite ao desastre, ao passo que ter 1nuitas pode elevar
os custos de administração e controle. A maioria das empresas prefere que o ciclo de
vida tenha, no máximo, seis fases.
Historicamente, as fases do ciclo de vida eram sequenciais por natureza. No en-
tanto, devido à necessidade da compressão do cronograma, as fases do ciclo de vida
hoje em dia se superpõem. A quantidade de superposição depende da magnitude dos
riscos que o gerente de projetos decide assumir. Quanto maior a superposição, maior
o risco. Erros cotnetidos durante atividades superpostas são, normalmente, mais caros
de corrigir do que erros que ocorrem durante atividades sequenciais. A superposição
de fases do ciclo de vida exige utn excelente planejamento prévio.
As revisões de final de fase são cruciais para fins de cont role e verificação dos
marcos de cada fase. Com a superposição de fases, ainda há revisões no final de cada
fase, mas elas são reforçadas por fases intermediárias durante as fases do ciclo de vida.
As metodologias de gestão de projetos de alto nível são integradas a outros pro-
cessos de gestão, como a gestão de 1nudanças, de riscos, da qualidade tota l e a enge-
nharia simultânea. Ta l integração produz utn efeito sinérgico que minimiza a papelada
(burocracia), minimiza o número tota l de recursos comprometidos com o projeto e
permite que a organização faç.a o planejamento de capacidade para determinar a carga
de trabalho máxima que pode suportar.
Metodologias de classe mundia l são continuamente aprimoradas por meio de re-
visões de KPI, atualizações das lições aprendidas, benchmarking e recomendações dos
clientes. A metodologia propriatnente dita pode se tornar o canal de co1nunicação en-
1 Linha do lampo - + 1
.,
Geração Critérios de Seleção do Planejamento
de ideia seleção de gerente de detalhado
projetos projeto
Estudo de Seleção Análise de
viabilidade do projeto custo-benefício
Figura 4-5 Quando preparar o termo de abertura do projeto.
tre o cl iente e o fornecedor. Metodologias eficientes promovem a confiança do cliente,

mini1n izando sua interferência no projeto.
As 1netodologias de gestão de projetos têtn de ser de fácil utilização para os t ra-
ba lhadores e cobrir a maioria das situações que podem surgir etn um projeto. Talvez
a melhor maneira de fazer isso seja colocar a metodologia em um manua l simples de
util izar.
Metodologias de classe mundial tentam facilitar o planejamento e a geração do
cronograma de projetos. Isso é real izado por meio do uso de templates para os três
níveis superiores da EAP. Ou seja, ao usar os tetnplates da EAP nível 3, haverá uma
terminologia e relatórios padronizados. As diferenças entre projetos aparecerá nos
níveis inferiores (i.e., níveis 4- 6) da EAP. Isso também leva a uma min imização da
papelada (burocracia).
Atua lmente, as empresas parecem estar promovendo o uso do conceito do termo
de abertura do projeto como um componente de uma metodologia, mas netn todas
as empresas criam o termo de abertura no mesmo ponto do ciclo de vida do projeto,
como mostra a Figura 4-5. Os três triângu los da Figura 4-5 mostram possíveis pontos
etn que o termo de abertura pode ser preparado:
• No primeiro triângu lo, o termo de abertura é preparado imediatamente após a
conclusão do estudo de viabilidade. Neste ponto, o tenno de abertura contém os
resu ltados do estudo de viabilidade, além da documentação de quaisquer supo-
sições e restrições que tenham sido consideradas. O termo de abertura é, então,
revisado e atua lizado uma vez que o projeto tenha sido selecionado.
• No segundo triângu lo, que parece ser o método preferido, o termo de abertura é
preparado após o projeto ser selecionado e o gerente de projeto ter sido designa-
do. O termo de abertura inclui a autoridade concedida ao gerente de projeto, mas
apenas para o projeto em questão.
• No terceiro triângulo, o tenno de abertura é preparado depois do planejamento
detalhado ser concluído. O termo de abertura contém o plano detalhado. A gerên-
cia não assina o termo de abertura até depois do plano deta lhado ter sido aprova-
do pela gerência sênior. Então, e só então, é que a empresa sanciona oficialmente o
projeto. Uma vez que a gerência tenha assinado o termo, ele passa a ser um acordo
jurídico ent re o gerente de projetos e todos os gerentes de área envolvidos e deter-
mina que deliverables serão clllnpridos e quando.
9
4.6 SAP
Pontos de decisão de controle de qualidade do projeto -
abordagem estruturada para garantir o sucesso do projeto
A qua lidade de um projeto é fundamenta l na ent rega de projetos da SAP; esse fato se
reflete na abordagem est ruturada do gerenciamento da qua lidade para a entrega de
sol uções da SAP - Qualidade Embutida (Q11ality Bt<ilt ln ). A base da abordagem de
qua lidade e1n projetos da SAP é a execução de pontos de decisão formais de qualidade
do projeto. Os pontos de decisão de qualidade são definidos na ASAP, metodologia
de entrega de projetos que a SAP e seus clientes e parceiros uti liza1n para o p laneja-
mento, gerenciamento e entrega de projetos. Cada tipo de projeto possui um nú1nero
predeterminado de pontos de decisão de qualidade executados em marcos essenciais
do projeto, como mostra a Figura 4-6.
A SAP acredita que os pontos de decisão de qualidade são essenciais para o suces-
so de qualquer projeto, independentemente da est ratégia de implementação - como
tradicional ou ági l. Os pontos de decisão de qualidade (P-Q) são integrados não
somente à nossa n1etodologia de ent rega, mas também são codificados em nossas
políticas de entrega e em nossos sisten1as internos. Os resultados de cada ponto de
decisão de qualidade são registrados no sistema de inforn1ação da gestão de projetos
da en1presa e são frequentemente revisados e divu lgados em relatórios. Un1a equipe
de qua lidade dedicada na SAP é encarregada do gerenciamento dos pontos de decisão
de qualidade, da revisão da saúde do projeto e do acon1panhan1ento junto ao gerente
de projeto, partes interessadas e liderança.
1 2 P-0 doASAP 3 4
e:l!..1 P-Q 2 ffil P-04 ffil f:Q_§ f:.01 V1rililõl~
Avallaçlo d:a AYallaçJo da AvallaçJo da Awallaçao da Awallaçlo da Awanaçao da Avallaçlo do agós iaícic
last de prepa,. tase de plano Unha de bast de contlguraçlo ta.se de preparação projeto das oi;ier~es
raçl o do projeto do projeto conftguraçao 11:nal reatlzaçlo 11:nal concluído
Preparação
do pro1eto
Plano do
pro1eto
. .
. Preparação
final ..
"
" '
Operações
Quatro pontos de decisão de qualidade são obrigatórios:

• fase de preparação do projeto
• fase de plano do projeto
• fase de realização
• Preparação final
Os outros três pontos de decisão são opcionais, conforme for combinado com o cliente.
Figura 4-6 Os pontos de decisão de qualidade do projeto são definidos no Plano de Gestão de
Projetos e são estabelecidos em etapas cruciais do ciclo de vida do projeto.
' ©20 13 by SAP. Todos os direitos resen•ados. Reproduzido com permissão. O material desta seção foi for·
n.ecido por Jan Musil, líder global da prácica de gestão de projetos da SAP Field Sen•ices, SAP America, lnc.
Os pontos de decisão de qualidade do projeto na metodologia ASAP fornecem

orientações claras aos gerentes de projetos, às partes interessadas e às equ ipes de pro-
jeto sobre como estruturar e realizar a revisão do ponto de decisão de qua lidade. Du-
rante cada ponto de decisão de qualidade, o gerente de garantia da qual idade ava lia
a completude e a qualidade de cada deliverable produzido no projeto de acordo com
a lista de verificação predefinida dos pontos de decisão de qua lidade que inclui não
sotnente o nome do deliverable, mas também critérios de aceitação detalhados. Cada
deliverable que consta da lista de verificação do P-Q é marcado como obrigatório ou
opciona l para a conclusão do ponto de decisão de qualidade. Mediante a conclusão
do P-Q, o gerente de garantia da qualidade aval ia o P-Q como aprovado/reprovado
e propõe um p lano de segui1nento para tomar providências corretivas que tratem das
deficiências identificadas nesse processo.
O processo formal de qualidade embutida mostrou ter utn impacto positivo sobre
a satisfação do cliente, 1nelhorar a saúde geral do portfólio de projetos e a receita.
Metodologia ASAP - maneira estruturada, repetível e prescritiva

de entregar projetos na SAP e inovar na entrega de projetos
A entrega de projetos na SAP segue un1a metodologia estruturada, repetível e prescri-
tiva para a in1plen1entação. A ASAP é a n1etodologia da SAP rica en1 conteúdo para
auxiliar a implementação e/ou atua lização de soluções da SAP en1 todos os setores
e ambientes de cl ientes. Criada con1 a experiência de m ilhares de projetos da SAP, a
ASAP fornece conteúdo, ferran1entas e melhores práticas que ajudam os consultores
a produzir resultados consistentes e bem-sucedidos em diversos setores e ambientes
de cl ientes.
As seis fases da ASAP oferecem suporte durante todo o ciclo de vida das soluções
SAP. Subjacente a essas fases há uma série de verificações de entrega de valor para ga-
rantir que a solução, quando implementada, entregue o valor esperado. A Figura 4-7
ilustra as fases da ASAP.
A metodologia abrange aspectos essenciais da implementa5ão SAP desde a orien-
tação sobre a gestão de projetos em torno do Guia PMBOK" do PMI ao design do
processo de negócios, gerenciamento de valor de negócio, gerenciamento do ciclo de
vida da aplicação, gestão de mudanças organizacionais, gerenciamento de dados e
outros tópicos importantes para a entrega das soluções SAP.
A n1etodo logia ASAP não é un1a pura metodologia de gestão de projetos, e
sim un1a n1etodologia que combina todos os elen1entos-chave que a equipe de pro-
jeto precisa cobrir a fin1 de entregar projetos bem-suced idos. Isso é exibido na
Figu ra 4-8.
o
o
•
+
,,..-
,._
&A
6 Suporte ao Operaçll~
Realização Inicio das
operações
o
o
o
Figura 4-7 As fases da ASAP.

O Pre~aração do O Plano do projeto0 Realização O Preparação

0
Suporte ao Inicio(:) Inicio da~
pro1elo final das operações operações
Conduzir planet.amento Mapear determinadores Consuulr e testar um Preparar sistema para Executar novos slsle· Rodar O l)l)VO
e preparação ll'llclal; de valor para o escopo ambiente completo de ül>eração da produção; mas e proce.ssos; sistema: aplicar
definir alvos, escopo da Implementação: testes e neoõclos: migrar/transferir dado~ monitorar resultados padrões de
e objetivos do projeto; refinar requisitos de desenvolver material executar treinamento: dos processos de operaçõe, SAP
Identificar e 1rernar negócios:documentar de treinamentoe prepa,ar a organização negócios e monitorar adicionais para
membros de e,quipe os processos que en· manuais do usuá.rlo; {lntem~externa) para o ambiente dt produ~ otimll:ar a
trarão em vigor: definir obter aprovação da o Início das operações ção: construir um operação do
o design da solução equipe executiva Centro de Excelência sistema
funcional: ldentíflcar para suporte e
requisitos funcionais me lho rias
e técnkos adicionais:
obter a assinatura da
equipe executiva nos
requisitos/design )
Garantir a enlrega de valor durante todo o ciclo de vida da solução ("Entrega de valor" )
Figura 4-8 Os elementos da metodologia ASAP.
A 1netodologia ASAP é projetada de uma forma que permite flexibi lidade e expan-
sibilidade de projetos menores, co1no serviços ind ividuais de consultoria à entrega de
implementações globais 1nais complexas em corporações multinacionais. Esse design
flexível nos permite uti lizar a metodologia como base para a criaç.ã o de todos os servi-
ços de consultoria. Cada serviço criado tira proveito da EAP comum da metodologia
ASAP a fim de definir claramente o t raba lho a ser real izado, pepéis e habilidades ne-
cessárias para prestar o serviço, além de detalhes sobre o recrutamento dos papéis na
, . .
propna organ1zaçao.
-
Essa abordagem nos ajuda a alcançar pontos comuns entre os serviços nas áreas
que não são a especialidade centrai dos proprietários do serviço (como a gerência do
projeto), di1ninui o custo de criação do serviço e simplifica o processo de adoção.
Graças ao uso da taxono1n ia comum baseada na ASAP na criação de serviços, os
projetos SAP podem ser montados a partir de serviços criados individualmente e entre-
gues segundo uma abordagem de "montagem a pedidos" em vez de serem criados des-
de o início para cada projeto. A SAP foi reconhecida pela Associação das Indústrias de
Serviços Tecnológicos (TSIA, Technology Services Industry Association) e1n 2012 por
sua abordagem inovadora na prestação de serviços com a abordagem SAP de Geren-
ciamento Avançado de Entregas, que se baseia em princípios de serviços modulares co-
muns que possam ser montados e reutil izados em diferentes projetos. Ver Figura 4-9.
Com essa abordagem, os clientes da SAP tiram proveito de serviços e conteúdos
pré-montados e d iminuem o custo de implementaç.ã o e a complexidade dos projetos,
min imizando os riscos dos projetos. Os serviços criados e soluções de rápida itnple-
mentação são usados nas etapas inicia is do projeto para estabelecer u1na solução de
linha de base que, posteriormente, é apri1norada em séries de montagens adicionais
usando as técnicas ágeis. Essa abordagem inovadora da entrega de projetos mudou
significativa1nente essa atividade e exige que nossos gerentes de projetos adaptem suas
habilidades a essa maneira inovadora de executar projetos. Um exemplo é que eles
precisam aprender como estrut urar e executar projetos com as técn icas interativas
ágeis para criar o design, configurar ou desenvolver as extensões específicas do cliente,
o que é substancialmente diferente da gestão de projetos t radicional, na qual a solução
é criada desde o início.
A metodologia comu1n e sua taxonomia é não so1nente um grande facilitador para
a ent rega de projetos, mas também ajudou a SAP a inovar o modo co1no as soluções
são entregues e implementadas.
Com a nova abordagem de entrega, nós .. . Como fazemos isso
INÍCIO
quatro variantes com alto
... garantimos o prazo mais esforço de criação
previslvel e rápido até a obtenção
do valor de negócio
11..-.
b --
... entregamos a integração que o
negócio exige para começar e crescer
sem problemas
l
MODULARIZAÇÃO
duas partes (módulos)
configuráveis
' ....Lllil l
: .-
... escolhemos dentre um portfólio
de soluções prontas para o uso
•l
/ ' '
e opções de implementação e
preço RESULTADO
uma infinidade de variantes
passiveis com esforço mlnimo
. . . inovamos mais rápido do que os

concorrentes e tiramos proveito
de todo o potencial de sermos
aqueles que •viram o jogo•
......
......
Figura 4- 9.
4.7 Cassidian: cronogramas multinível integrados

Talvez o benefício mais importante de uma boa metodologia seja a capacidade de criar
cronogramas 1nultinível integrados para todas as partes interessadas. O restante desta
seção foi fornecido pela Cassidian: ©2013 by Cassidian. Reproduzido com permissão.
Todos os direitos reservados.
Por que cronogramas multinível integrados?

A prática de criar cronogratnas multinível integrados visa fornecer a e.ada nível de ge-
rência do projeto, desde o cliente e/ou a gerência da empresa até a gerência do projeto
e à gerência do pacote de t rabalho, cronogramas de referência consistentes, uma men-
suração do progresso consistente e esti tnativas consistentes até a conclusão do projeto.
Essa prática é amplamente util izada para projetos grandes e complexos.
Definição dos cronogramas multinível integrados

Os cronogran1as n1u ltinível integrados de projetos dividen1-se en1 três níveis de
gerência:
• Cronograma-mest re (Nível 1 ): cl iente e/ou gerência da empresa,
• C ronograma do resumo do projeto (Nível 2): gerência do projeto e

• Cronograma deta lhado (Nível 3 ): gerência do pacote de t raba lho.
Por definição, os diferentes níveis de cronogramas são autossuficientes, refletindo
a delegação de responsabilidades da gerência no projeto:
• O gerente de projetos é o "proprietário" do cronograma-mestre
• O gerente de projetos é o "proprietário" do cronograma de resumo do projeto
(para projetos grandes, o gerente de projetos pode ter o apoio do PMO)
• Os gerentes do pacote de traba lho são os "proprietários" do cronograma deta-
lhado
Alé1n disso, para produzir e manter um cronograma multinível, devem-se esta-
belecer ligações entre os d iferentes níveis para fornecer um cronograma multinível
integrado.
Pré-requisitos para preparar e entregar cronogramas multinível

integrados
Antes de desenvolver cronogramas 1nultinível integrados, os segu intes deliverables de-
vem estar concluídos:
Definir o escopo do projeto, por meio de:

• levanta1nento dos requ isitos;
• definição da Est rutura Analítica do Produto co1n todos os deliverables internos e
externos;
• desenvolvimento da Estrutura Analítica do Projeto (EAP) - pense em DELNE-
RABLES;
• especificação de pacotes de trabalho com um foco especia l nas entradas necessá-
r ias e nas saídas esperadas, incluindo os critérios de aceitação dos deliverables;
• p lanejan1ento de uma revisão de todas as descrições dos pacotes de trabalho
com todas as principa is partes interessadas do projeto - o objetivo é comparti-
lhar e controlar a consistência entre entradas e saídas dos diferentes pacotes de
traba lho;
• estimativas da duração, do trabalho, dos custos e habilidades de cada pacote de
trabalho;
• gestão de riscos e oportun idades para definir e p lanejar ações de mitigação e
de identificação de em quais pontos dos planos devem-se adicionar zonas de
regulagem.
Princípios dos cronogramas multinível integrados

Os princípios aba ixo deve1n ser seguidos para garantir o sucesso dos cronogramas
multinível integrados:
• O Cronograma-mestre (ta1nbém chamado de Plano Nível 1) deve produzir u1na
visão sintética (uma página) sobre o cronograma do projeto, refletindo os prin-
cipais marcos (marcos contratua is, principais itens ou equipamentos fornecidos
pelo cliente (CFJ / CFE, Customer-Furnished Information / Customer-Furnished
Equipment) com impacto crítico nos deliverables cont ratua is), as dependências
entre os principais 1narcos e resumos das principais fases, as datas contratuais
(comprom issos do cont rato) e o status do cont rato (principais marcos alc.ançados
e progresso atua l com datas previstas).
21 O Gestão de projetos
• O Cronogra,na do Resu1110 do Projeto (também chamado de Plano Nível 2) deve

cobrir a estrutura ana lítica do projeto (EAP) completa do projeto e ser organ izado
de acordo com a EAP. Deve fornecer as dependências ent re todos os pacotes de
trabalho do projeto e as dependências entre os deliverables dos pacotes de traba-
lho e os principais marcos do projeto.
• O Cronogra111a Detalhado (também chamado de Plano Nível 3) deve produzir o
cronograma detalhado de cada pacote de trabalho, que precisa ser decomposto em
atividades, e cada atividade deve conduzir a um deliverable e deve ser decomposto
em tarefas ele1nentares com recursos designados.
Além disso, ent re os d iferentes níveis, devem-se imple1nentar ligações entre os cro-
nogramas 1nultinível (Ver Figura 4-10):
• Ent re o Plano Nível 1 e o Plano Nível 2, devem-se definir ligações pa ra acompa-
nhar a adesão às datas dos marcos contratuais (compro1nissos com o cl iente) e
out ras datas de marcos importantes. Destes, todos os principa is marcos relatados
no Plano Nível 1 devem ser ligados aos correspondentes principa is marcos do
Plano Nível 2.
• Ent re o Plano Nível 2 e o Plano Nível 3, devem-se definir ligações para acompa-
nhar a adesão às datas do projeto (datas-alvo do projeto), e cada pacote de traba-
lho, a(s) entrada(s) e a(s) saída(s) definidas no Plano Nível 2 devem ser ligados à(s)
entrada(s) e saída(s) correspondentes do Plano Nível 3.
Dois tipos de links deve1n ser usados:
• Hard links (também chamados de ligações direcionadoras) para entradas, a fim
de alinhar automaticamente a data de disponibilidade da entr ada correspondente
no nível inferior.
• Soft links para saídas, para informar sobre a data prevista para a saída no nível
inferior sem afetar automaticamente a data definida no nível superior.
Monitoramento e controle dos cronogramas multinível integrados

No monitoramento e cont role dos d iferentes níveis do cronogra1na, incluindo a con-
sistência, as verificações devem ser realizadas em um mês, de acordo com o esquema
a segu1r:
1. Atua lização dos cronogramas Nível 3 por cada gerente de pacote de trabalho
baseado e1n infonnações correntes rea is e novas previsões de acordo com o
progresso contínuo do pacote de trabalho.
2. Verificação da consistência nos diversos níveis pelo escritório de gestão de
projetos, incluindo os desvios, e identificação de como estes afetam os 1nar-
cos importantes.
3. Revisão do cronograma, dividido entre o escritório de gestão de projetos, a
autoridade de engenharia e os gerentes de pacote de trabalho para identificar
planos de ação para recuperar datas-alvo.
Validação pelo gerente de projeto com a atua lização dos cronogramas do Nível 3
e Nível 2 baseada nas decisões tomadas e na linha de base do desempenho da atuali-
-
zaçao, se necessano.
Cronograma-mestre • Plano nível 1 com marcos contratuais e marcos importantes (Mls)
•
...,
Cronograma@ execução - Plano nivet 2 com todos os pacotes de trabalho (PT) edependências entre eles
t
....- - ---+.: Marco importante 1 :
:
~ • PT 1 ~ _ ,: Marco importante 2
> ' e e PT3 '
- , , PT 2 "' . PT necessário para alcançar o
~
. >-
\
; PT necessário para
,.~ ,..
•
~~
•',. MI 2 com dependências
++ alcançar o MI 1 com
dependências
.,l - •
:I
.
,, ..................................... '
,............ .
_--~ ·.;tmi• !---

Cronograma detalhado· Nível 3 Cronograma detalhado • Nfvd 3 Cronograma detalia<lo • Nlvd 3
!
--- Entrada :
- vÀ'
; • IPT 1
''
Saída
1 ..-.,.,
....>
,PT
,,..,,.
2.,.1-.
~
:•
~
---·
:
:.
Entrada ;•
Saída interna
'
Saída -:., ÓSaída O' Saída
- - Hard links para entradas (Deliverables dos PT anteriores ou CFE)
············ So/t links para saídas (Deliverables dos PT)
Figura 4-10 Exemplo de cronograma multinível integrado.
1
4.8 Tecnicas Reunidas º
A estimativa a livros abertos (OBE, open book estímate) como uma
alternativa bem-sucedida de contrato para executar projetos no
setor de petróleo e gás
Introdução
E1n decorrência da taxa projetada do crescimento da demanda por enegia, a indústria
de petróleo e gás tem uma ampla variedade de desafios e oportunidades e1n diferentes
áreas. Devido a isso, o setor está prosseguindo, há vários anos, ao desenvolvimento de
novas instalações que, em muitos casos, se trata de 1negaprojetos.
Tipicamente, o cic.lo de vida completo de um projeto de e.apitai no setor de pe-
tróleo e gás foca liza-se nas etapas gerais que são apresentadas na Figura 4-11 . Com-
preender e gerenciar essas etapas é crucial para o sucesso de longo prazo do projeto.
O cont rato LSTK (Lump Sum Tttrn Key) e o cont rato por custos reembolsáveis
(cost-plus contract) são, a 1nbos, tipos prevalecentes na indústria de pet róleo e gás.
Dependendo do nível de risco que o cliente está disposto a aceitar, restrições orçamen-
tárias e competências centrais da organização do c.l iente irão determ inar que método
é o melhor para o projeto.
10
©2013 Tecnicas Reunidas. Reproduzido com permissão. Todos os direitos reservados. O material foi for-
necido por Felipe Revenga López. Felipe Revenga López é diretor de Operações da Tecnicas Reunidas desde
setembro de 2008. Ele entrou para a TR em 2002 como dfreror de projetos e lá acuou como patrocinador de
projetos de um grupo de projetos estratégicos internacionais. Tem ampla experiência em projetos EPC.. LSTK
e OBE-LSTK nas Unidades de Produção de Petróleo e Gás, Refinaria, Petroquímica e Setor de Energia em
rodo o mundo. Ele é engenheiro industrial (especializado em substâncias químicas) fonnado pela School of
Industrial Engineers (ETSllM) e atualmente está concluindo o Programa de Doutorado em Engenharia de
Processos Químicos e Bioquímicos na Universidade Politécnica de Madrid (ETSIIM).
Uma grande quantidade de projetos neste setor é realizada co tn contratos

EPC-LSTK; a enorme experiência da Tecnicas Reun idas baseia-se principahnente nesse
tipo de projeto que, etn geral, implica gerenciar todo o projeto e real izar a engenharia
de detalhamento (em alguns casos inclui-se a engenharia básica ou de pré-deta lha-
mento (FEED, front-end engineering design ) no escopo do trabalho), adquirir todos os
equipamentos e materia is necessários e, então, constru ir, fazer o pré-comissionamento
e o start-1<p para entregar as instalações da obra em condições de pleno funcionamen-
to. Os contratos LSTK tendem a ser os mais arriscados, e todos os riscos são assumi-
dos pelo fornecedor EPC.
A estimativa a livros abertos (OBE, open book estimate) ou estimativa de custos
a livros abertos (OBCE, open book cost estitnate) é uma a lternativa para executar
projetos EPC. Com esse tipo de cont rato, o propósito final do trabalho é definir o
preço total do projeto em colaboração com o cliente; os custos globa is do projeto são
estabelecidos de 1naneira transparente ("a livros abertos").
A estimativa a livros abertos (OBE)

A principal fina lidade dessa metodologia é const ruir um Preço EPC preciso por meio
da aplicação de alguns parâmetros previamente acordados (entre o cliente e o forne-
cedor), o custo base por 1neio de uma O BE, o desenvolvimento de uma engenharia de
pré-detalhamento (FEED) e, em alguns casos, a realização de pedidos de compra para
itens selecionados cruciais e itens de longo prazo de entrega para garantir o cumpri-
mento do cronograma geral do projeto. A OBE fixará o custo base do projeto e servirá
de base para determinar o preço fix o EPC do projeto.
Durante uma fase OBE, o fornecedor desenvolve uma FEED e/ou parte da enge-
nharia de deta lhamento na base do reembolso ou preço fixo ou out ras a lternativas,
incluindo uma estimativa de custo completa e aberta das instalações. Após um período
acordado (norma lmente entre 6- 12 meses, dependendo principa lmente do grau de
precisão, do cronograma e de outros fatores requisitados pelo cliente) de desenvol-
vimento de engenharia e um acordo entre cliente e fornecedor sobre o custo base, o
contrato é alterado ou convertido em utn cont rato EPC-LSTK, por meio da aplicação
de fatores 1nultiplicativos previamente acordados.
Metodologia de estimativa de custo

Principais elementos do custo e categorias de precificação:
A OBE normalmente se baseia em utn desenvolvitnento de engenharia suficiente, de
acordo com os deliverables identificados no contrato OBE. Esses deliverables têm o
maior grau de desenvolvimento que é possível sob o progresso normal do projeto. Os
deliverables requisitados são preparados e encaminhados ao cliente antes da conclusão
da fase de conversão.
Os principais elementos de custo, exibidos na Figura 4- 12, que cotnpreenderão a
OBE são descritos abaixo. A estimativa de custo OBE deve incluir o escopo de traba-
lho total:
1. Serviços deta lhados de engenharia, aquisições e construç.ã o
2. Suprimento de equipamentos, materiais a granel e peças avulsas
3. Transporte até o local de const rução
4. Desembaraço aduaneiro
5. Construção e edificação no local
6. Provisão de instalações e serviços temporários de const rução para as subem-
pre1te1ras
"'
"O
·5
Q)
"O
o
-~
(.)
o
"O
(/)
-~a.
·--
2 14 Gestão de projetos
Equipamentos
Suprimentos
Instrumentos
TRANSPORTE
Parte elétrica
··• Direto
Obras civis
Subcontratos Suprimento de estruturas de aço
de construção Principal subempreiteira
(l.e., mecãnlca, elétrica, de
Instrumentos, etc.)
r-------------,L--1
Engenharla
Outros
Gerenciamento de suprimentos de construção

... Indireto
Instala l!es temporárias
Outros
Figura 4-12 Elementos típicos de custo.
7. Serviços de construção e pré-comissionamento

8. Serviços de co1n issionamento e start-up
9. Serviços de t reinamento e assistência ao vendedor
10. Encargos de obrigações, seguros e fundos de cobertura
11. Outros custos, incluindo inspeção por terceiros e seguro das empreiteiras
12. Outros...
Base de custo
• Um procedimento OBE é desenvolvido durante a etapa do cont rato e implementa-
do durante a fase de OBE do projeto. Todos os detalhes de como se preparar uma
OBE devem ser acordados e incluídos no contrato como u1n anexo.
• Pré-acordo de subsídios, aumento, condiciona1nento, subsídios para o projeto téc-
nico, excedentes e cortes e desperdícios.
• MTOs feitos com o software PDS, medidos em P&ID e gráficos de planos e es-
timativas. Todos os detalhes sobre procedimentos devem ser acordados antes da
assinatura do contrato OBE.
Ao executar projetos que serão convertidos, a TR desenvolve a OBE en1 parale-
lo com a execução normal do p rojeto, garantindo que ambas as atividades possan1
fluir sen1 interferências. Durante a fase de OBE, em casos específicos e se acordado
con1 o cliente, a TR pode adiantar a aqu isição dos principais equipamentos e in iciar
as negociações com suben1preiteiras para a construção. A execução dessas ativi-
dades com antecedência faci lita o cumprimento dos requisitos do cronograma do
proieto.
Essa fase de OBE do projeto é desenvolvida conjuntamente entre o cliente e a TR.
A OBE é totahnente t ransparente para o cl iente e a conversão em LSTK é faci lmente
acordada uma vez que o elemento risco/recompensa seja fixado.
Na Figura 4- 13, ve1nos os principais passos e atividades desenvolvidos para a l-
cançar as metas da OBE e para converter para a fase seguinte do projeto:
• Todas as obras civis e estruturas de aço devem

ser pré-projetadas (orientadas para a construção) OBE CONCLUÍDA
• MTOs completas de tubulações, parte FASE DE CONVERSÃO
elétrica e Instrumentos
• Equipamentos principais e cruciais projetados
• Obter cotações para todos os • Averiguações emitidas para 90%
equipamentos (para aquisição) dos suprimentos
• Negociações finais com subempreiteiras
de construção
• Formulár,os de dados preliminares • Conversão para o EPC em um mês
quando necessário estabelecido
• Desenvolver desenhos específicos válidos
somente na fase de OBE, quando necessário
• Desenvolver Ideias de economia
de custo {engenharia de valor)
Passos para alcançar o alvo da OBE
Figura 4-13 Passos para alcançar o alvo da OBE.
Durante a fase de OBE, desenvolvem-se ideias relativas a economias de custo a fim

de ajustar a estimativa do custo final. Para tal, uma equipe especia l de engenharia é
nomeada para trabalhar tanto com o gerente de engenharia quanto com o gerente de
estimativa, co1n a finalidade de detectar as áreas e1n que possíveis econom ias possa1n
ser alcançadas por 1neio da otim ização do projeto, sem prejudicar a segurança, a qua-
lidade ou o cronograma. Qualquer uma dessas 1nudanças que possa levar a economias
de custos é cuidadosamente avaliada de um ponto de vista técn ico, e, se ficar provada
a viabilidade da mudança potencial, a solução a lternativa, junta1nente com a aval iação
do impacto de economia de custo, será encaminhada aos CLIENTES para considera-
ção e aprovação.
O preço do contrato EPC é o resultado do custo base multiplicado por percentuais
fixos acordados entre cliente e e1npreiteira para detenninar os honorários e mark-1<ps
relacionados a equipamentos, materia is a granel, construção e custos comple1nentares.
Esse preço, durante a fase de conversão, é convertido a um preço fixo e, a partir de
então, permanece fixo durante a fase EPC-LSTK.
Contratos
Os típicos modelos de contrato sob a alternativa OBE são:
• U1n contrato, duas pa rtes: OBE e EPC. Preço da pa rte EPC a ser incluído na con-
versão.
• Dois contratos, u1n OBE e outro EPC: Ambos podem ser assinados no início ou
um no início e outro, na ocasião da conversão.
A metodologia de estimativa a livros abertos é incluída no contrato. Em caso de
não haver conversão:
I. A relação contratual desaparece, e tanto cliente quanto empreiteira quebram
seu compromisso. O cliente pode quebrar o contrato se não estiver interessa-
do. Consequências:
• Seis meses, nova LSTK. 2-3 meses 1nais avaliação das ofertas
• Repetir FEED com e1npreiteira diferente
II. O contrato fornece mecanismos no caso de desacordo:

• Continua r o contrato na base do serviço (melhor contrato LS)
• Acordo quanto a uma conversão pa rcial
• Outr os, conforme acordo contratua l
Vantagens
Um O BE + LSTK poderia otimizar toda a execução do projeto, especialmente em ter-
mos de custo e cronograma.
• Em termos de custo, cl iente e empreitei ra poderiam determinar juntos o custo do
projeto por 1neio de uma estimativa a livros abertos porque cl ientes e empreiteiras
chegaram a um acordo quanto a uma metodo logia de estimativa, as condições de
conversão, como os fatores multiplicativos são acordadas, etc. e, além disso, clien-
tes e e1npreitei ras possue1n t ransparência e confiança mútuas. Esse modelo resulta
em um custo preciso porque evitam-se contingências desnecessárias.
• Por outr o lado, esse 1nodelo resulta em vantagem no cronograma porque o pe-
ríodo de licitação é reduzido ou substituído por uma fase de negociação da con-
versão; uma fase de EPC é reduzida devido a todos os t rabalhos desenvolvidos
durante a fase prolongada de FEED e conversão. Uma representação da vantagem
no cronograma é apresentada na Figu ra 4-14:
Em resumo, as vantagens no custo e no cronogr ama são:
Custo Redução do cronograma

• Desenvolve e gera estimativas EPC durante 6 a • Curto período de licitação, já que as estimativas
12 meses. Isso fomece uma precisão muito mede custo não precisam ser tão detalhadas.
lhor dos custos.
• Preços exatos baseados em ofertas reais + um • Diminui o cronograma geral do projeto, já que o
fator de conversão acordado garante justiça ao tempo do FEED ampliado e a licitação EPC são
cliente e à contratada. drasticamente encurtados.
• Tempo suficiente para desenvolver o projeto e • Procedimento de adjudicação de contrato muito
para evitar contingências desnecessárias. mais fácil e mais curto.
• Aplicação de economias de custo para que elas • Alguns itens de longo prazo de entrega e equi-
correspondam ao orçamento de custos do proje- pamentos cruciais podem ser adjudicados ou
to para o cliente. negociados.
• Facilita a possibilidade de financiamento, devido
a uma estimativa mais precisa.
• Riscos são reduzidos e mais bem controlados
para o benefício comum de cliente e contratada.
Resumo
A estÍlnativa a livros abertos (OBE) p rovou ser u1na alternativa de cont rato bem-
-suced ida para executa r projetos no setor de pet róleo e gás porque alinha cliente e
empreiteira com os alvos do projeto. Ambos sentem-se motivados a buscar a melhor
estitnativa de custo possível, ou o 1nelhor custo-alvo possível para o projeto e, ao mes-
mo tempo, o cronograma é otim izado .
Co1no foi mencionado na int rodução, no setor de petró leo e gás, a maioria dos
p rojetos atua is pode ser classificada como megaprojetos, em que tam bém há mu itos
riscos associados, em u1n mercado a ltamente va lorizado co1n um grande volume de
t rabalho real izado por empreitei ras, subempreiteiras, etc. Empregando u1na alternati-
va OBE, os clientes podem gerenciar melhor seus r iscos por meio de uma abordagem
LSTK
Adjudicação de contrato Adjudicação de contrato
FEED EPC LSTK
OBE + LSTK (conversível) Vantagem no

cronograma
Adjudicação de contrato Fase de
• FEED
conversão
+EPCLSTK -
Definição de preço:
maior precisão dos custos .. Preço Justo:
contingências mlnímízadas
Vida do projeto
Figura 4-14 Típica vantagem no cronograma.
de maior cooperação, na qual os riscos são reduzidos durante UJna estimativa precisa
e, então, abraçados, em vez de totalmente transferidos às empreiteiras. Dessa 1naneira,
os resultados dos projetos podetn melhorar.
A Tecnicas Reunidas desenvolveu e converteu com êxito 100% de projetos OBE
em projetos LSTK-EPC.
Siglas
• Cliente: sign ifica o proprietário da empresa de pet róleo e gás
• Empreiteira: empresa afi liada responsável pela realização dos serviços de enge-
nharia, aquisição e const rução
• EPC (Engineering, Proc11retnent and Construction): tipo de cont rato típico do se-
tor de const rução de instalações industria is, compreendendo a prestação de servi-
ços de engenharia, aquisição de 1nateriais e construção
• FEED: Front-End Engineering Design significa engenharia básica ou de pré-de-
talhamento que é conduzida após a conclusão do Projeto Conceituai ou Estudo
de Viabilidade. Nessa etapa, antes do início do EPC, vários estudos são real iza-
dos para solucionar questões técnicas e fazer uma estimativa geral do custo de
. .
1nvest1mento
• Contrato LS (L11mp S11m Contract): implica que a empreiteira concorda em reali-
zar um projeto específico por um preço fixo
• Cont rato LSTK: Contrato LS + todos os siste1nas entregues ao cliente prontos
para entrar em operação
• MTOS (Material take-offs): listas de materiais da parte elét rica, tubulações e ins-
trumentação
• OBE: a esti1nativa a livros abertos (OBE, Open Book Estimate) ou esti1nativa de
custo a livros abertos (OBCE, Open Book Cost Estitnate)
• PDS: software usado para projetar instalações industriais por meio de uma ativi-
dade de engenharia multidisciplinar
• P&ID (Process & Instr11ment Diagrams): diagramas de processos e instru1nentos
• TR: Tecnicas Reunidas
4.9 Teradyne: de mito a realidade

Ma is cedo ou mais ta rde, todas as empresas reconhecem a necessidade de possuir uma
metodologia de gestão de projetos, talvez até mesmo uma 1netodologia que abranja
toda a empresa (EPM, enterpríse proiect tnanagement). E1nbora o reconhecimento
seja fáci l, o desenvolvimento p ropriamente dito e, em última anál ise, a imple1nentação
podem ser difíceis se a empresa basea r suas decisões em mitos, e não na realidade. Na
Tabela 4- 1 vemos a lgumas das características de metodologias bem desenvolvidas,
pelo menos na opinião do autor. A segunda coluna ilustra os m itos, enquanto a tercei-
ra coluna identifica o que empresas maduras pa rece1n fazer.
Uma e1npresa p rodutora de bens de capital do setor eletr ôn ico desenvolveu uma
metodologia que segue a ma ioria dessas características de realidade. Por exemplo, o
pa rágrafo de abertura da metodologia da Teradyne decla ra:"
Uma das fina lidades deste d ocumento é apresenta r uma descrição de a lto nível da função
d o gerente de progra mas/projetos no ciclo de desenvo lvimento de produtos. Um gerente de
programas é res ponsável po r projetos a linhados de mú ltiplos produtos relacionad os que
TABELA 4-1 Características de design de uma boa metodologia

Característica Mito Realidade
Descrição da metodo- São necessários detalhes excessivos, tal- Descrição de uma estrutura de classe
logia vez centenas de páginas com ilustrações, mundial, curta e fácil de ler e compreen-
gráficos e tabelas der; talvez com 25 páginas ou menos
Legibilidade Detalhes excessivos e ilustrações com- Descrições narrativas com suporte princi-
plexas palmente de fluxogramas
Aplicabilidade São necessárias múltiplas metodologias Uma metodologia de classe mundial pode
dependendo dos tipos de programas, pro- ser usada para projetos e programas
jetos, deliverab/es e áreas funcionais
Adaptabilidade A metodologia deve estar alinhada aos A metodologia deve estar alinhada ao
de/iverables dos projetos ou programas negócio e ser aplicável a projetos e pro-
gramas
Equivalência ao Guia A metodologia deve se basear em políti· A metodologia deve ter flexibilidade de
PMBOJ<" case procedimentos rígidos modo que possa ser adaptada a todos
os programas e projetos e também ser
imediatamente adaptável a mudanças
necessárias
Delineação de papéis As metodologias possuem caracterlsticas A estrutura básica da metodologia deve
únicas e baseiam-se em políticas e pro- estar associada ao Guia PMBOK"'
cedimentos rígidos
Lições aprendidas A metodologia deve delinear claramente Devido à necessidade de flexibilidade e
os papéis de todos os participantes: adaptabilidade, apenas o papel de gerente
gerentes de projetos, gerentes de área, de projetos precisa ser delineado, espedfi·
executivos e clientes camente a responsabilidade de integração
O uso da metodologia termina quando os As metodologias devem ter um passo
deliverab/es são alcançados final para captar as melhores práticas e
lições aprendidas
11
As o utras cirações desra seção foram fornecidas pelo Dr. Sreve Lyons, gerente de projetos de aplicações da
Teradyne, uma fabricante de bens de capital do seror elecrônico, e adaptadas de sua metodo logia de gestão de
projeros e programas. O material é reproduzido com permissão da Teradyne.
c ul mina m em um grande deliverable no q ua l um gerente de projetos se foca lizará em um

de/iverab/e com um único grande nível de produto. A finalidade do gerente de programas/
projetos é: "Trabalhar com parceiro de lideranças de design na direção e integração de equi-
pes de projetos multifuncionais para garantir que os objetivos das partes interessadas sejam
atendidos e entregues produtos que esteja m de acordo com o plano de projeto aprovado" ...
A proposição de valor do gerenc ia mento de programas poderia ser definida como: Um
gerente de programas/projetos (GP) fornece a estrutura organizada e disciplinada a linhada
à toda a empresa necessária para integrar a engenharia funcional e os grupos operacionais
ao levar projetos ou programas baseados em produtos a serem concl uídos dentro do prazo
e do orçamento, atendendo, ao mesmo tempo, as demandas/necessidades/requisitos do mer-
cado. Uma outra finalidade deste documento é apresenta r uma descrição de a lto nível da
estrutura de instruções de trabalho q ue o Gerenciamento de Programas utiliza ao gerenciar
projetos/programas de desenvolvimento de prod utos ... Considerando-se o papel integrativo
único do GP, este documento também tentará servir de elo com grupos funcionais como
marketing, engenh aria e operações.
O docu1nento ta mbém continua descrevendo o papel dos gerentes de projetos
e programas, além do fato de que a metodologia se aplica tanto a programas quan-
to a p ro jetos. Além disso, a metodologia também identifica o fato de q ue não seja
necessário empregar toda a metodologia em certos projetos. Este fato fornece u1na
flexibilidade considerável etn seu uso e ilustra a fé da empresa na capacidade de seus
gerentes de projetos/programas.
Este documento pertence a todos os Programas e Projetos gerenciados pelo PMO. Um
gerente de projetos irá focar um único nível de produto,enquanto o gerente de programas
será responsável por múltiplos projetos a linhados de produtos relacionados q ue c ulmi-
na m em um grande deliverab/e de produto. Daqui em d iante, neste documento, chamare-
mos os tít ulos de gerente de projetos e gerente de programas por sua sigla, GP, sendo seu
significado definido a part ir do contexto do trecho. Haverá variação no nível de esforço
que os gerentes de projeto ou programa dedicarão em qualquer projeto ou programa
específico, dependendo de diversos fatores, como: tamanho do orçamento do projeto/
progrmna, c:.on1plexidade técnica 011 do cronogra,na.
O PMO estabe)e.ceu os critérios q ue determina m quando um Projeto deve ser consi-
derado um Programa. No o utro extremo do espectro, estabeleceu também critérios para
definir q ue projeto deve usar o processo;'PM Lite", q ue não exige o uso das ferramentas e
técnicas de GP identificadas neste documento. Ambas as definições podem ser encontradas
no documento do processo "PM Lite" d isponível na web page do Plv!O. Este documento
adotará como premissa uma situação em q ue há a necessidade de um GP e toda a variedade
de ferramentas/técnicas padronizadas de projeto disponíveis estaria em uso.
Como previamente mencionado, boas metodologias se focalizam em fluxogramas de
fácil compreensão. Documentos com gráficos e figuras complexas são não somente difíceis
de acompanhar, mas também d ificultam que os funcionários os acompanhem e ut ilizem .
Fluxogramas comp lexos o u ma l construídos podem limitar seriamente a flexibilidade do
gerente de projetos. A declaração abaixo, retirada da metodologia da Teradyne, serve como
um excelente exemplo de um fluxograma fácil de acompanhar:
A Figura 4- 15 mostra o a linhamento entre o desenvolvimento e produtos e o geren-
ciamento de programas e o fato de que o maior envolvimento do GP é no Caminho Il,
Fases 1 a 4. Os grupos funcionais da empresa e os gerentes de programa operam e m u ma
organ ização ma tricia l composta (Guia PMB0K"'2004, Figura 2.12). Os gerentes de pro-
grama são responsáveis pelo escopo, cronogra ma e custo de um projeto, mas não geren-
ciam recursos h umanos d iretamente. O(s) gerente(s) de programas geralmente trabalham
de perto com a(s) Jiderança(s) de design (o conceito ;;dois em um") ao controlar as "triplas
restrições" do projeto: escopo, cronograma e custo. Observe que o Caminho li, Fase 1
pode ser subdivid ido nos segmentos opcionais A e B. Isso tipicamente seria recomendado
para projetos de grandes platafo rmas. A Fase 2 também é subdividida em segmentos A e

B em todos os projetos.
Os dois círcu los da Figura 4- 15 representam o ciclo de melhoria contínua da De-
ming e mostram que a qualidade está embutida no fluxo do processo e nos processos
de comprotn isso com a qualidade e a gestão da qua lidade total da empresa.
Uma outra característica de muitas empresas é o alinhamento de sua metodologia
aos processos do Gttia PMBOK®. De acordo com a metodologia da Teradyne:
A Tabela 4- 2 mostra a equivalência dos deliverab/es de cada fase a os processos do G11ia PM-
BOK"'. A Fase 2 (planejamento) pode exigir o uso de processos de todas a s nove• áreas de
conhecimento e norma lmente é considerada a fase que exige o maior comprometimento de
tempo por parte do GP devido à quantidade de trabalho em que ele realmente precisa;'pôr a
mão na massa" . Po r exemplo, durante a Fase 2, o GP cria o cronograma detalhado, orçamen-
to, plano de recursos e planos de gestão de riscos. As Fases 3 e 4 exigem esforços continuados
do GP porque na Fase 2 o traba lho é planejado, mas nas Fases 3 e 4, o plano é co locado em
prática. Na realidade, nenhum projeto jamais co rre de aco rdo com o plano, então o papel do
GP de monito rar, ajustar e replanejar (sem desrespeitar as restrições de escopo, cronograma e
custo) é desafiador. O envolvimento do GP na Fase 5 é mínimo, embora as ava liações de fim
de projeto sejam inestimáveis devido à captação das "lições aprendidas" .
Fina lmente, as 1netodologias passam por mudanças e aperfeiçoamentos. Assim

como acontece com o gerenciamento de configuração e o cont role de mudanças no
escopo, as revisões são acompanhadas e registradas para que seja tn rast reáveis. Isso é
exibido na Tabela 4-3, que foi adaptada da metodologia da Teradyne
Execução do projeto
Portfólio do projeto Caminho 2

··Fazendo as coisas da maneira certa•
caminho 1
"Fazendo a coisa certa"
Estratégia de execucão do projeto

Tecnologia Principios I Processo I Estrutura
facilitadora
r '\
Passo O Passo 1 Passo 2 Passo 3 Passo 4

Design p
-
Estratégia
Alvos e
Arquitetura
da linha de
Plano de Funil Planejamento
detalhado e Teste de
Liberação/
Ramp-up º'\\
de negócio
da divisão
objetivos
produtos
pro;eto
agregado OesenvoMmento
de pro;eto
e produto desenvolvi- produto
do produto ,A e
de oonceito A B mento • -
A B Fase2 Fase3 Fase4 Fases
Fase 1
\: )
'p
-o'~
Avaliação do projeto
A e
Figura 4-15 Alinhamento do desenvolvimento de produto e gerenciamento de programas.
• N . de T.: A versão 4 do Guia PMBOK* possui nove áreas de conhecimento, sendo que a versão 5 coma com
1Oáreas de conhecimento .
TABELA 4-2 Equivalência dos deliverables de cada fase aos processos do Guia PMBO,e,
Grupos de processo do Guia Áreas de conhecimento dos
Descrição PMBO,e, processos do Guia PMBO~
Desenvolvimento de conceitos Iniciação Integração
Planejamento Escopo
Custo
Recursos humanos
Planejamento de projetos e pro- Planejamento Integração
dutos Monitoramento e controle Escopo
Tempo
Custo
Qualidade
Recursos humanos
Comunicações
Riscos
Aquisições
Design detalhado e desenvolvi- Execução Integração
mento Monitoramento e controle Escopo
Tempo
Custo
Qualidade
Recursos humanos
Comunicações
Riscos
Teste e verificação de produtos Execução Integração
Monitoramento e controle Escopo
Tempo
Custo
Qualidade
Recursos humanos
Comunicações
Riscos
Re/ease e ramp-up de produtos Encerramento Integração
Aquisições
TABELA 4-3 Histórico de revisões
Data Página(s) Seção Comentários Rev.

15/3/2009 6-8 2.13 Expansão dos papéis e 1.0
responsabilidades
4.10 Slalom Consulting: funções da gestão de projetos

Com o passar dos anos, as empresas passa ram a aceitar o G11ia PMBOK® co1no a
"bíblia da gestão de projetos". Precisamos lembrar, no entanto, que ele ainda é ape-
nas u1n guia, e não necessariamente "o verdadeiro conhecimento". O conhecimento
perfeito teria de ser baseado no tamanho, na natureza e na complexidade dos projetos
de uma empresa, no tipo de setor em que ela co1npete e no percentua l de t rabal hos
em que precisa utilizar a gestão de projetos. Alguns instr utores da gestão de projetos
afirmam que há três maneiras de gerenciar projetos: a maneira certa, a maneira errada
e a 1naneira do Guia PMBOK®. Embora as empresas criem metodologias de gestão de
projetos baseadas no Guia PMBOK®, estas raramente o seguem ao pé da letra. Um
grande percentual das áreas de conhecimento pode ser usado, mas o foco poderia ser
mais alinhado às áreas de domínio. Os processos podem ser mais importantes do que
as á reas de conhecimento. Como exemplo, considere os seguintes comentários de Carl
Manello, PMP®, diretor de p ráticas de eficiência na ent rega, Slalom Consulting:
Para tudo aquilo pelo que os gerentes de projetos são res ponsáveis, dependendo de seu pa-
pel (e.g., projetos de grandes ou pequenas proporções, programas focalizados em negócios,
fusões/aquisições corporativas), há vários modelos que representam o q ue cada um precisa
saber para se tomar um especialista na prática da gestão de projetos. Um modelo, o Guia
PMBO~, deco mpõe esse conhecimento tácito em nove áreas do conhecimento básicas. Um
modelo que eu desenvolvi decompõe a inda mais as áreas de conhecimento em doze funções
de gestão de projetos (fGP). Há diversos outros modelos espalhados pela internet. Tenham
nove o u doze áreas, os modelos nos ajudam a definir o que nós, como gerentes de projetos,
fazemos.
Na minha experiência, todos os gerentes de projeto devem saber da existência e ter
experiência nas funções de gestão de projetos definidas em meu modelo. As fGP básicas (ver
Figura 4-16), representam as funções q ue defini para um gerente de projetos/programas. As
fGP são robustas e mudam com as mudanças do foco da gestão de projetos (i.e., as funções
dos gerentes de projetos são d iferentes daquelas descritas em um Escritório de Programas
da Empresa). 12 Se tirarmos proveito do modelo fGP, essas funções podem ser estabelecidas
como práticas-padrão para os gerentes de projeto, mas podem ser persona lizadas ou adap-
tadas a um específico projeto ou cl iente. Em minhas negociações com corporações - tanto
grandes quanto pequenas - evito especificamente o termo "melhores práticas", que sempre
foi confuso para mim. Se cada empresa determina a ;'melhores práticas" para si mesma, en-
tão o termo propriamente d ito se d ilui e perde o sentido. Assim como um setor, a gestão de
projetos não pode ter centenas de melhores práticas. Embora certamente seja possível que
as práticas adotadas em uma empresa possam ser as melhores, segundo a minha experiência
e las geralmente são as " práticas preferidas" da organização implementadora ou do líder
principal no momento da implementação.
Se nos liberarmos do foco em "preferidas", "melhores" ou "super fantásticas" como ad-
jetivos, as áreas funcionais da gestão de projetos podem ser vistas como principais áreas de
prática em torno das qua is os gerentes de projeto devem ser capazes de se mobilizar. Cada
empresa precisa escolher q ue gerentes funcionais são os mais importantes para elas, definir
o nível certo de maturidade que devem buscar, colocar planos em prática para alcançar o
domínio, reavaliar e continuar no caminho interminável da evolução das capacidades. Cada
organ ização implementa a gestão de projetos de acordo com sua melhor capacidade e, in-
dependentemente de este ser ou não um nÍ\•el realmente ;'melhor" - a lgo q ue não tem uma
definição-padrão globa l - , ele será o nível mais apropriado para aquele momento e local.
12
Para mais informações sobre as fGP, os leitores devem consultar o livro de C. Manello, Value Projec.t
Management.
Gerenciamento de Gerenciamento , Monitoramento

implementação '' e relatórios
' • Conselhos de
• Vendedores
'
Figura 4-16 Funções de gestão de projetos.
Infelizmente, em minhas discussões com as corporações, percebi que pa rece haver

uma ideia comum na mente de mu itos gerentes sênior de que a implementação de
práticas-padrão somente podem ser realizadas com a imple1nentação de ferramentas
de gestão de projetos (p. ex.: Clarity, Plan View, MS/Project). Observei que as empre-
sas que tentam "cortar ca1ninho" no estabelecimento do processo priineiro e, em vez
disso, procu ra m uma ferra 1nenta para solucionar seus desafios em gestão de projetos
geralmente não têm êxito com a implementação de nenhuma boa prática, pelo menos
dent ro de um período razoável de te1npo . E1nbora esteja certo de que esse não é o caso
de todas as organizações - caso contr ário, os vendedores de ferra 1nentas já teriam ido
à fa lência - deve ficar claro que o processo não pode ser ignorado ou substitu ído por
uma ferra menta .
Já trabalhei em diversos setores. E1n cada um, vi empresas que gastavam mi lhões
de dólares em aquisição, personalização, imp lementação, educação e adm inistração de
ferra mentas de gestão de projetos. Todas tivera1n resultados abaixo do esperado. U1n
motivo para o baixo desempenho poderia ser atr ibuído à crença de que implementa r
um software de gestão de projetos é a mesma coisa que implementá-la . Certamente
é necessá rio usar um software para gerencia r os p rojetos, mas a questão-chave é a se-
guinte: devemos selecionar uma ferra 1nenta de software de gestão de projetos e então
cria r nossa metodologia segundo essa ferramenta ou devemos criar nossa 1netodologia
primeiro e só então selecionar a ferramenta adequada para a nossa metodologia ? A úl -
tiina opção certamente é a melhor escol ha. O software é simplesmente uma ferra men-
ta, e os projetos são gerenciados por pessoas, não por ferramentas. Uma compreensão
apropriada do software e de sua capacidade é essencial no início da implementação da
gestão de projetos, mas não deve ser vista como um substituto para bons processos.
Carl Ma nello afirma:
Como cons ultor, tive a oportunidade [dej trabalhar com muitas empresas e o bservar
muitos exemplos de implementações de ferramentas de suporte à gestão de projetos: tanto
s ucessos q uanto fracassos. As fases do ciclo de vida dos projetos bem-sucedidos de imple-
mentação da gestão de projetos norma lmente são as mesmas, mas não acho que seja pos-
s ível, nesse sent ido, aplicar facilmente um modelo repetível de estrutura de prazos à cro-
nologia específica de uma empresa. Por exemplo, a implementação nacional de um pacote
de so(Jware conhecido como a ferramenta de registro durante o programa de substituição
financeira de um grande fabricante do setor aéreo - englobando vá rios anos e incluindo
mais de 800 recursos que trabalham em regime de tempo integral ou parcial - não foi igua l
à implementação na d ivisão de engen ha ria de um grande fabricante de telefones celula res.
Cada im plementação é diferente. O q ue é transferível, porém, é o processo por meio do
q ual uma organização aborda como c hegar às práticas-pad rão. Deve-se começa r com a
ava liação de onde a organização se encontra em termos de suas capacidades (tirando pro-
veito da fGP), determina r como definição, construção e im plementação de processos irão
s ustenta r o c rescimento, para então selecionar conjuntos de ferramentas de suporte e, só
então, a nalisá-las, personalizá-las e implementá-las. É essencia l q ue o processo preceda as
(erranzentas.
4.11 Slalom Consulting: substitu indo metodologias

por modelos
En1 bora as metodo logias de gestão de projetos p areçan1 estar na moda, há uma
crescen te tendência a su bstit uir n1etodo logias por modelos. As metodologias de
fato possuem desvantagens, e as en1presas que só enxergan1 uma única metodo-
logia, a sua própria, poden1 ter dificu ldade en1 reconhecer seus pro blen1as. Mas
os consu ltores de gerencian1ento que foram expostos a diversas n1etodologias en1
vários setores ~eraln1ente têm un1a comp reensão muito melhor das limitações. Carl
Manello, PMP e diretor de p ráticas de eficiência na ent rega da Slalom Consu lting,
afirma q ue:
Nos últimos 20 a nos, t ive contato com u ma grande quant idade de metodologias deta-
lhadas. H á, é claro, gran des histórias de s ucesso devido a metodologias, especia lmente
quando enormes q ua ntidades de consulto res a lta mente t reinados foram trazidos à cena
para dirigir enormes iniciativas que abrangia m toda a empresa. Entretanto, para projetos
menores o u para os casos em q ue treina r toda uma equipe de projetos sobre como se usar
a metodologia está fora de cogitação, as metodologias podem causa r tantos proble mas
q uanto soluções.
Em uma grande empresa manu fatureira no final da década de 1980, t ive o privilégio
de trabalhar com um o pessoal do Centro de Tecnologia e do Escritó rio de Programas Em-
presariais (do qua l eu fazia parte). Aproveitamos um modelo de fornecedor, adapta ndo-o
às nossas necessidades e utilizando-o para projetos tanto de TI quanto de P&D. Em minha
primeira tarefa como líder de Soluções de Gerenciamento de Programas e Projetos com uma
outra empresa de consulto ria, tive a o portunidade de levar a abordagem dos modelos a o u-
tros clientes. Hoje, na Slalom, continuo a defender modelos em detrimento de metodologias
detalhadas. A Sla lom Consulting não possui uma metodologia própria de GP. Em vez disso,
usamos modelos.
As metodologias tendem a ser definidas como um a série de passos inflexíveis que têm
de ser seguidos, normalmente em o rdem seq uencia l. Os " modelos", por outro lado, deli-
neiam passos que podem ser seguidos. A diferença é que os passos de um modelo podem ser
executados de maneira diferente a cada projeto, podem ser "pulados" o u podem ser imple-
mentados em variados graus de detalhamento. Em um de meus antigos empregadores, criei
um modelo de ciclo de vida de GP e fiz seu marketing interno chamando-o "Aplicando com
flexibilidade um processo rigoroso". A frase de marketing foi desenvolvida não somente
para ajudar a vender o conceito de um novo processo, mas também para ajudar a ilustrar a
diferença essencial entre um modelo e uma metodologia. O processo do modelo era projeta-
do e construído com uma quantidade significa tiva de detalhes (p.ex.: passos do projeto, de-
liverables, métricas, processos de aprovação). Entretanto, o rigor da implementação variava
dependendo do tipo de projeto, além de seu tamanho, importância, etc. Projetos de grandes
proporções tinham de aderir ao ciclo de vida do GP nos mínimos deta lhes, enquanto proje-
tos peq uenos tinham a flexibilidade de om itir partes específicas da abordagem. Nem todos
os projetos são criados da mesma forma.
Em um de meus a nt igos cl ientes, há uma metodologia exaustiva definida e em vigor,
que emprega d iversos te11,plates, inúmeros processos e múltiplas equipes de governança,
cada qual responsável por diferentes partes do processo. O desafio dessa implementação de
metodologia é sua in flexibilidade. Os gerentes de projeto passam tempo demais tentando se
movimenta r no processo e são distraídos ou não conseguem se focalizar em suas atividades
de GP. Eles passam mais tempo realizando trabalhos relacionados a processos de gestão de
projetos do q ue agregando valor aos seus projetos. Isso, por sua vez, força o cliente a con-
tratar mais pessoas para realizar as atividades da ;'gestão de projetos" (ter a lg uns gerentes
de projeto para gerencia r o projeto e o utros para garantir o cumprimento da metodologia),
aumentando, dessa forma, o tempo ded icado à gestão de projetos. Não se pode provar q ue
esse tempo extra tenha um impacto direto sobre o projeto ou benefícios financeiros e, na
verdade, erode q ua lquer benefício inicial que os programas a legavam ser capazes de realizar.
Da mesma forma, há uma ins uficiência de treinamento, orientação, documentação o u o utro
supo rte disponível q ue ajude os gerentes de projetos a se movimentar ao longo do rigoroso
processo. Eles não somente passam uma quantidade exagerada de tempo cumprindo aquilo
que compreendem, mas também precisam sair pela organização em busca do escritório de
governança certo para lhes aj udar sobre o q ue devem fazer. Se o programa de substituição
de sistema de toda a empresa não se sair bem, a metodologia de gestão de projetos propria-
mente d ita (que deveria estar facilitando seu sucesso) certamente será um dos principais
elementos de seu fracasso.
4.12 Fases do ciclo de vida

Determinar o mel hor número de fases de ciclo de vida pode ser difíci l ao desenvolver
uma 1netodologia de gestão de projetos. Como exemplo, consideremos a TI. Durante a
década de 1980, com a exp losão no setor de software, muitas empresas de consultoria
em TI entra ra m em cena com o desenvolvi mento de 1netodo logias de TI que usava tn
fases de ciclo de vida de desenvolvimento de sistemas (CVDS ou, em inglês, SDLC,
systems developtnent /ife-cyc/e). Os consultores prometem resultados feno1nena is aos
seus clientes se eles comprarem o pacote juntamente com o trei namento e serviços de
consultoria q ue o acompanham. Então, depois de gasta r centenas de milhares de dó-
lares, o cliente lê as cláusulas em let ras miúdas que afirma1n que a metodo logia deve
ser usada da forma que é apresentada, e não é possível nenhuma persona lização. E1n
out ras pa lavras, o cliente precisa 1nudar sua empresa pa ra que ela se adapte à 1n etodo-
logia em vez de o contrá rio. A maioria das empresas que consultoria em TI que adotou
essa abordagem não existe mais.
Para uma empresa individual, chega r a um acordo q ua nto ao número de fases
pode ser di fícil, a princípio, 1n as quando final mente se chega a um acordo, todos os
funcionários devem seguir as mesas fases. Entreta nto, para as empresas de consultoria
e1n T I de hoje em dia, o conceito de "pacote ún ico" não funciona. Qualquer que seja a
metodologia criada, ela precisa ter flexi bilidade de modo que seja possível que o clien-
te a personalize. Ao fazê-lo, pode ser mel hor focalizar-se em processos do que em fases,
ou possivehnente uma abordagem de modelos que co1nbine os melhores recursos de
cada. Carl Manello afirma que:
Embora o ciclo de vida da gestão de projetos seja paralelo ao CVDS, eles são separados e
d istintos (especialmente porque muitos projetos não têm nada a ver com TI o u com ;'siste-
mas"). Com a lgumas exceções específicas a certos cl ientes, as fases-padrão são:
1. Conceitualização do projeto - onde o projeto come.ça a tomar forma (normalmente um
p rocesso informal não estruturado)
2. Iniciação do projeto - uma iniciativa aprovada dá in ício à sua jornada e começa a seguir
o rigor do ciclo de vida
3. Análise e design - começa-se a decompor o escopo do projeto naquilo q ue será reali-
zado
4. Desenvolvimentoffestesílmplementação - fases CVDS padrão, mas adaptadas a proje-
tos que não são de TI, como necessário
5. Encerramento/Seguimento - finalização do "projeto" e início da "manutenção contí-
nua" (q uando necessário)
6. Acompanhamento da rea lização de benefícios - a fase lamentavelmente negligenciada
onde comprovamos a realização dos benefícios pretendidos na fase de conceitualização
Durante uma de minhas vidas corporativas, ajudei a definir um ciclo de vida de gestão
de projetos que se baseava em seis fases centrais (ver Figura 4-17). Como um modelo, as
fases devem ser ma leáveis às necessidades da situação. Nosso PMO fazia parte da função
de Governança de TI, que era, primordia lmente, o braço financeiro da TI. O equ ivalente
ao CFO da TI queria garantir q ue permitíssemos que processos suficientemente detalhados
possibilitassem a a tivação (ou início admin istrativo) de um projeto. A ativação representava
determinar os b11ckets de rastreamento de prazos e os buckets financeiros, além de estabe-
lecer acordos quanto ao nível de serviço. Da mesma forma, adicionamos a fase de garantia
e teste de q ualidade, pois aquela era uma organização recém-formada q ue se foca lizava
nessas funções, e a TI queria garantir s ua proeminência nas mentes das equipes de projeto.
Finalmente, para ajudar a "apagar" os a nos de problemas de implementação, criei uma fase
separada para ela. Essa fase detalhava os papéis, responsabilidades, deliverables e pontos
de verificação associados que nos permitiriam gerencia r um projeto até depois de s ua data
de entrada em operação. Como discutido acima, cada iniciativa fluía por esse modelo de
maneira "flexível", aproveitando partes q ue faziam sent ido de acordo com a natureza do
pro1eto.
13
4.1 3 Expandindo as fases do ciclo de vida
Historicamente, definimos a primeira fase de um projeto como a fase de iniciação.
Essa fase incluía tr azer o gerente de projetos a bordo, ent regando a ele um orçamento
e u1n cronogra1na, e dizendo-lhe para co1neçar a execução do projeto. Hoje, há uma
fase p ré-iniciação que Russ Archibald e seus colegas chamam de incu bação do projeto/
fase de viabi lidade. Nessa fase, analisamos os benefícios do p rojeto, o valor esperado
na concl usão, se há recursos suficientes e qual ificados disponíveis e a relativa impor-
tância de um p rojeto em comparação a outros projetos que pode1n esta r na fi la. É
possível que o projeto jamais chegue à fase de iniciação.
u Russell D. Archibald, lvano Di Filippo e Daniele Oi Filippo escreveram um excelente arrigo sobre esse as·
sumo, "The Six-Phase Comprehensive Projecr Life Cycle M.odel lnduding the Projecr lncubacion/Feasibility
Phase and rhe Posr-Projecr Evaluarion Phase.,. O arcigo foi publicado no PM \Vorld Joumal em dezembro
de 2012.
G ·e1 • Relatório de status • Controle de mudanças no projeto
overnança Oe oro1 os • Gerenciamento de problemas
Cone aitua lizaç:llo Garantia da Acompanhamento
do aroleto I Iniciação do projeto Anjlise e design Ativar Desenvolvimento qualidade ! Encerramento/
Implementação seguimento da reallzaçfo
(Processo de
parceiro de J Comitê de
Revisão e testes de benefícios
(Processo
&'
,:,
negócios) priorização
governança de TI
de finanças ~ -
Parc<!lro d negócios
'
Comitê~..
Subcomltê de
, redes financeiras
de '
Avaliação
impacto ISP/ASP
TI do grupo
comitêde
Parc~iro de negócios corporativas)
.s::
õ
Gs11ndamento 11 / arquitetura (D
arqultetur1c
dB 1/Bmandas g_
o
Figura 4-17 Modelo de GP ampliado. .,

~.
<J>
a.
(D
(O
.-o,,
(D
<J>
a.
(D
-o
.2.
~
<J>
~
....,
No passado, esperava-se que a gestão de pro jetos cotneçasse na fase de iniciação,

pois era nessa fase que o gerente de projetos era designado. Hoje, espera-se que os ge-
rentes de p rojetos tenham u1na compreensão muito 1naior do negócio como um todo,
e as empresas descobriram que é benéfico t razer o gerente de projetos a bordo 1na is
cedo, na fase de iniciação, para a uxiliar na tomada de decisões de negócios etn vez de
deixá-lo se encarrega r somente de decisões de projeto .
No mesmo contexto, cradicionahnente via-se a fase do ciclo de vida como o en-
cerra tnento do projeto. Isso incl ui a implementação do encerramento do cont rato,
do encerramento a dministrativo e do encerramento fina nceiro . Após, o gerente seria
realocado a um out ro projeto.
Hoje, estamos incluindo uma fase de avaliação pós-projeto . Algumas empresas
chamam-na de fase de gerencia mento da satisfação do cl iente. Nela, mem bros sele-
cionados da equipe de projeto e do pessoa l de vendas/mar keting, a lém de 1nembros
do comitê de govemança, se reúnem com o cliente para ver que muda nças podem ser
feitas na metodologia o u nos processos usados par a executa r o projeto, e o q ue pode
ser feito de outra maneira em projetos futuros, pa ra esse cliente melhora r ai nda mais a
relação profissional entre cliente, fornecedor e pa rtes interessadas .
4.14 Churchill Downs, lnc.

A C hurchill Downs, Inc. criou u1n a metodo logia de gestão de projetos que clar amente
reflete sua organização. Segun do Chuck Millhollan, diretor de gerenciamento de pro-
gramas:
Apesar de termos baseado nossa meto dologia em padrões p ro fissionais, desenvolvemos um
gráfico (e usamos terminologia) compreendido por nosso seto r para ajudar a co mpreendê-
-la e aceitá-la. Po r exemplo, temos um p rocesso estruturado de solicitação de in vestimento,
aprovação e prio rização. (Ver Figura 4-1 8.) Usamos a ana logia de primeiro levar o cavalo
puro-sangue até o paddock de apresentação e, então, até o po rtão de partida . O p rojeto, o u
corrida, não começa até o puro-sangue ter chegado ao portão de pa rtida (aprovação de caso
de negócio e priorização de p rojeto).
4.15 lndra: a necessidade de uma metodologia

Como menciona do no Capítulo 3, a busca pela excelência em gestão de projetos é
q uase sempre acotnpanhada do desenvolvimento de uma metodologia de gestão de
p ro jetos. Foi o que aconteceu na Indr a. A empresa defi ne excelência na á rea da seguin-
te ma neira: "A excelência em gestão de projetos é atingida por 1n eio da capacidade
de alcançar constantemente os alvos dos projetos, cria r oportunidades de negócios e
apr imorar o processo de gerenciamento propriamente dito ao gerenciar projetos desig-
nados". Enr ique Sevilla Mol ina, PM P®e antigo di retor do PMO corporativo, discute
a jornada rumo à excelência :
Uma metodologia de gestão de projetos foi formalmente definida em meados da década
de 1990, baseada na ex periência obtida em nossos grandes contrato s internaciona is. Os
principa is problemas q ue enfrentamos estavam relacionados à definição do escopo, isto é,
os limites da metodologia, e à adoção da estratégia correta para difund ir esse conhecimento
por toda a empresa. Para reso lver esses problemas, nossa gerência decidiu contratar uma
empresa de consultoria externa para agir como um fator dinâmico q ue estimularia e dirigi-
ria as mudanças culturais necessárias.
i-,i ~!!~~~!1:~.~oWNs "Pista de corrida" do projeto
5. Histórico de riscos e problemas
6. Controle de mudanças no escopo
Por1ão de
(soI ic itaçõ es/hi stó ricos) 3. Termo de abertura par1ida
7. Testes/Acompanhamento de defeitos 4. Estrutura analítica do projeto
2. Aprovação e priorização
&'
,:,
1. Caso de negócio ~ -
.s::
Oocumen10s de supol1e
13. Relalórlos de slatut 11 . Lições aprendidas õ
14, Minutas de reuniões :1'
15. Plano de comunicações
. : 12. Mensuração de
- ~~ i benefícios (D
liil
Cirçulo dos
P.tddockde apresentaçao g_
vencedores o
~
.,.
<J>
a.
(D
(O
8. Aprovação da TI 1O. Aprovação do patrocinador
.-o,,
(D
<J>
9. Passagem à produção/
NOTA 1.&u f apenas tanabb1011e01 de ie.ni,lite.s. faça o do1U1f01ddos ranp111unecessáto:s e srtte-<isern ,eudilco~
Implementação pa.a awll.l~s e_.ecNieas do pa,)elo. a.
(D
NOTA 2. Lentue-se. p•a pr4«os !lll:I\Odos, tlça o IJ,Ofotdde seusdocta'l'll!moscom~os N imu apr<,t1.1dldoa,1e111ode "O
eposW!iO SN1!Pan1 do p,<tf lO • h"-"fll'4«tsJ..ydertl'/.c:omMetnttas~ .2.
~
<J>
~
Figura 4-1 8 A metodologia da Churchill Downs, lnc. (O
Sim, o processo foi cuidadosamente pa trocinado desde o início po r exe.c utivos sênio r e
acompanhado de perto até s ua tota l implementação em todas as á reas da empresa.
Os p rincipais marcos d o processo foram, aproximadamente:
• Decisão sobre a estratégia da gestão de projetos ................... meados da década de 1990
• Definição e documentação da metodologia ............. meados ao fim da d écada de 1990
• Definição e preparação das ferramentas ................................... .fim da década de 1990
• Início d o processo de treinamento ........................................................................ 2000
• Gestão de riscos no n ível departamenta l ............................................................... 2002
• Início d o treinamento para certificação de PMPs" ................................................ 2004
• Processo de gestão de riscos definido no nível corporativo ................................... 2007
• Início d a definição de processos de gerenciamento de programas e portfólios ....... 2008
Uma metodologia de GP foi desenvolvid a no início da década de 1990 e forma lizada
durante essa década. Poste riorme nte, ela foi atualizada para acompanha r a evolução
da empresa e do setor e está sendo usada como modelo para desen volver e manter os
sistemas de informações da gestão de projetos (SIGP) e para treinar os G Ps em toda a
e mpresa.
A metodologia baseia-se no ciclo de vida do projeto e é estruturada nas duas etapas e
seis fases a seguir, a presentadas na Figura 4-19:
Etapa pré-contratual
Fase 1. Iniciação
Fase 2. Desenvolvimento do conceito, criação de ofertas e propostas
Fase 3. Negociação da oferta
Etapa contratual
Fase 4. Planejamento do projeto
Fase 5. Execução, monitoramento e contro le
Fase 6. Encerramento
As etapas pré-contratua l e contratual são a mbas pa rte do projeto e de seu c iclo de vida.
A maioria dos problemas q ue a pa rece durante a vida de um projeto se origina d urante s ua
definição e na negociação de seus objetivos, conteúdos e escopo rea lizada com o cl iente. Um
gerenciamento a propriado da eta pa pré-co ntratua l é a melhor maneira de evita r pro blemas
posteriores.
No fina l de cada fase há um resultado específico q ue permite q ue se tome uma decisão-
-chave, focalizando e d irecionando as ações da fase seguinte e reduzindo, assim, os riscos e
incertezas iniciais do projeto.
A decisão nas etapas e fases era uma decisão baseada principa lmente nas necessidades
de nosso ciclo-padrão da concepção e desenvolvimento de um projeto, e ta mbém nos tipos
mais sign ificativos de projetos com os quais nos envolvemos.
Os processos de gestão de riscos são integrados à metodologia e às ferramentas corpo-
rativas de G P. Um processo inicia l de identificação de riscos é realizado durante a fase de
proposta, seguido por um plano completo de gestão d e riscos du rante a fase de planejamen-
to da etapa contratual, e os subseq uentes processos de monitoramento durante a fase de
execução do projeto. A avaliação da qua lidade e os processos de co nt role de mudanças são
considerados os principa is processos de suporte da metodologia.
4.16 Implementando a metodologia

A existência co ncreta de uma metodologia não basta para t ransformá-la em uma me-
todo logia de classe mundia l. As metodologias, afina l, não passa1n de fol has de papel.
O que transforma uma metodologia-padrão em uma metodologia de classe mund ial é
a cultura da organização e o modo como ela é implementada .
Etapa pré-contratual Etapa contratual
Fase 1 Fase 2 Fase 3 Fase 4 Fase 5 Fase 6
Figura 4-19 Ciclo de vida da gestão de projetos.
A existência de uma metodologia de classe mundial não basta para se alcançar a

excelência em gestão de projetos. Sua aceitação e sua utilização por toda a empresa é
que conduzem à excelência. É por meio da excelência na execução que u1na metodolo-
gia de nível médio se toma uma metodologia de classe mundial.
Determinada etnpresa desenvolveu uma metodologia excepcional de gestão de
projetos. Cerca de um terço da empresa usou a metodologia e reconheceu seus verda-
deiros benefícios de longo prazo. Os outros dois terços da etnpresa não a apoiara tn.
O presidente finalmente sentiu-se forçado a intervir, reest ruturando a organização e
impondo o uso obrigatório da metodologia.
Nunca é dema is realçar a importância da execução. Uma das características de
empresas com metodologias de gestão de projetos de classe mund ial é que elas pos-
suem gerentes de classe 1nundia l em toda a sua organização.
O desenvolvimento acelerado de uma metodologia de e.lasse mund ial exige a
existência de um executivo convicto de sua indispensabilidade, e não meramente utn
executivo responsável por sua implantaç.ã o. Este, age predominantetnente por conve-
niência, enquanto o executivos convictos são mais "mão na massa" e impulsiona tn
o desenvolvimento e a implementação da metodologia de.scendente na hierarquia da
empresa (top-bottom ). A ma ioria das etnpresas reconhece a necessidade de um execu-
tivo convicto. Ent retanto, 1nu itas não reconhecem o fato de que a posição de executivo
convicto é uma experiência que deve durar para toda a vida. Utna empresa de Detroit
realocou seu executivo convicto depois de alguns sucessos alcançados com a 1netodo-
logia por ele implantada . Consequentemente, ninguém ficou encarregado de protnover
a melhoria contínua na metodologia.
Boas metodologias de gestão de projetos permitem a ad tn inistração de seus clien-

tes e das expectativas deles. Se os clientes confiarem em sua metodologia, normalmen-
te entenderão quando você lhes disser que novas mudanças no escopo são inviáveis
u1na vez in iciada determinada fase do ciclo de vida do projeto. Uma empresa subcon-
t ratada do setor automotivo levou esse conceito de confiança ao extretno, convidando
os cl ientes a assistirem às suas reuniões de revisão de final de fase, uma atitude que
maximizou a confiança entre cliente e subcontr atada. Ent retanto, o cl iente era solici-
tado a não participar dos últimos 15 minutos das reuniões de revisão de final de fase,
quando as finanças do projeto seriam d iscutidas.
As metodologias da gestão de projetos são um processo "orgânico", o que itnplica
que elas estão sujeitas a mudanças e melhorias. Áreas típicas de melhoria de metodo-
logias podem incluir:
• Melhor interação cotn os clientes
• Melhor interação cotn os fornecedores
• Melhor explicação de su bprocessos
• Definição mais nítida dos marcos do projeto
• Delineamento mais nítido do papel da gerência sênior
• Reconhecimento da necessidade de templates adicionais
• Reconhecimento da necessidade de métricas adicionais
• Desenvolvimento de tetnplates para guiar o envolvimento do grupo
• Melhoria do guia de gestão de projetos
• Maneiras de ensinar ao cliente o funcionamento da metodologia
• Maneiras de reduzir o tempo das reuniões de revisão
4.17 Erros na implementação

Embo ra as empresas reconheçan1 as forças motr izes que indican1 a necessidade da
melhoria da gestão de projetos, a decisão propriamente dita de fazer un1 investi-
mento nesse sentido pode não acontecer até que algun1a crise ocorra ou se encontre
un1a quantidade significativa de perdas financeiras no balanço patrimonial da em-
presa. Reconhecer uma necessidade é muito n1a is fácil do que fazer algo a respeito,
porque para isso é necessá rio investir ten1po e dinhei ro. Muito frequentemente, os
executivos adiam dar sinal verde para o projeto, na esperança de que un1 mi lagre
ocorra e as melhorias na gestão de projetos não sejam mais necessárias. Enquanto
procrastinam, a sit uação gera lmente deteriora a inda n1ais. Considere os segu intes
con1entá rios de Carl Manello, PMP®, diretor de práticas de eficiência na entrega da
Slalom Consulting:
Acho que a maior motivação para o s meus clientes investirem em melhorias é como eles
veem o impacto da gestão de projetos em suas iniciativas. Q uando seu histórico de direção
de iniciativas de negócios de grande porte é menos do que proeminente (indicando falta de
processos, métodos, ferramentas ou habilidades suficientes), eles come.ç am a compreender
a necessidade do investimento. Q uando há implementações de projeto não realizadas, orça-
mentos estourados e má qualidade, todos falam muito alto e chamam a atenção da gerência
exe.c utiva sênior. O desafio é, em vez disso, chamar a atenção dos executivos antes de mi-
lhões de dólares serem desperdiçados.
No início, muitas corporações provavelmente não irão querer investir em melhorar in-
fraestruturas de GP como a fGP. "Há projetos verdadeiros com benefícios de peso a serem
realizados, em vez disso." Porém, depois que essas mesmas organizações começam a en-
frentar problemas, compreender suas fraquezas e a necessidade de melhoria na gestão de
projetos básica, elas começam a se focalizar nessas melhorias.
O investi1nento tardio nas capacidades de gestão de projetos é apenas um de mui-
tos erros. Um outro erro comum, que pode ocorrer até mesmo com as melhores em-
presas, é não tratá-la como uma profissão. Em algumas empresas, essa é uma atividade
de tempo parcial a ser rea lizada além da função principal de um funcionário. As opor-
tunidades de subir na carreira estão atreladas à funç.ã o principa l, e não à gestão de
projetos. Em outras etnpresas, a gestão de projetos pode ser considerada meramente
co1no uma habi lidade especializada no uso de ferra1nentas de geração de cronogra1nas.
Carl Manello continua:
Embora o PM! tenha feito um trabalho incrível, especialmente nos últimos 10 anos, de-
fendendo a gestão de projetos como uma habilidade especializada que deve ser entregue a
profissionais, acho que muitas empresas ainda acreditam que a gestão de projetos é uma
habilidade, e não uma profissão. Seja em organizações de marketing ou de engenharia,
geralmente se aloca algum funcionário aleatório para a função de gerente de projetos, in-
dependentemente de sua formação, nível de habilidade demonstrado ou capacidade como
gerente de projetos. Essa falta de atenção à gestão de projetos como profissão talvez seja um
dos fatores que contribuem para que projetos em todo o mundo continuem a ter um mau
desempenho. Muitos projetos não possuem à sua frente gerentes de projetos qualificados.
4.18 Superando barreiras ao desenvolvimento

e à implementação
Tomar a decisão de que a empresa precisa de uma metodologia de gestão de projetos é
muito mais fácil do que realmente implementá-la. Há várias barreiras e problemas que
surgem muito depois de a equipe de design e implementação começar seu traba lho.
Típicas problemáticas inclue1n:
• Devemos desenvolver nossa própria metodologia ou fazer u1n benchmark das me-
lhores práticas de outras empresas e tentar usar a metodologia delas?
• Pode1nos fazer com que toda a organização concorde com uma única 1netodologia
para todos os tipos de projetos ou devemos ter várias 1netodologias?
• Se desenvolvermos várias 1netodologias, que d ificildade encontrare1nos na imple-
mentação de esforços de melhoria?
• Como devemos lidar com a situação em que apenas parte da empresa vê benefício
em usar uma metodologia e o resto da empresa quer fazer do seu próprio jeito?
• Como convencemos os funcionários de que a gestão de projetos é uma competên-
cia estratégica e que a metodologia de gestão de projetos é um processo que serve
de suporte para essa co1npetência estratégica?
• Para empresas multinacionais, como fazemos todas as organ izações e1n todo o
mundo usar a mesma 1netodologia? Ela precisa ser baseada na intranet?
Essas são perguntas típicas que afligem as empresas durante o processo de desen-
volvimento da metodologia. Esses desafios podem ser superados, e com grande suces-
so, como ilust ram as empresas identificadas nas próximas seções.
4.19 Ferramentas de gestão de projetos

As metodologias de gestão de p rojetos exigem sistemas de software de suporte. Há
apenas cinco anos, mu itas das empresas citadas neste livro não tinham qualquer capa-
cidade de gestão de projetos; quando as tinham, eram lim itadas. Como elas implemen-
taram a gestão de projetos tão rapidamente? Por causa da explosão de software para
computadores pessoais. Esses software ajudavam a planejar os projetos, estimá-los,
cont rolá-los e gerar cronogramas, ou seja, eram críticos para o desenvolvimento da
metodologia.
Até o final da década de 1980, as ferra 1nentas de gestão de projetos em uso eram
pacotes de software criados para gerar cronogramas de projetos:
• Técnica de aval iação e revisão de progra1nas (PERT, Progratn evaluation and re-
view technique)
• Método do diagrama de setas (ADM, Arrow diagramming tnethod)
• Método do diagrama de precedência (PDM, Precedence diagratnming method)
Essas três técnicas de redes e geração de cronogra1nas forneceram aos gerentes de
projetos capacidades computacionais que em muito ultrapassavam os gráficos de bar-
ra e gráficos de marcos que estavam em uso. Os três programas de software provaram
ser inestimáveis na época:
• Formaram a base de todo o planejamento e de roda a previsão e permitiram que a
gerência fosse capaz de planejar o melhor uso possível de recursos para alcançar
determ inado alvo dentro das restrições de cronograma e orçamento.
• Ofereceran1 visibil idade e possibil itaram à gerência controlar progran1as exclusivos.
• Ajudaram a gerência a lidar co1n as incertezas envolvidas em programas ao res-
ponder perguntas como, por exemplo, de que modo os atrasos influenciam a con-
clusão do projeto, quando há folga entre os ele1nentos, e que elementos são cru-
cia is para que a data de conclusão seja cumprida. Esse recurso deu aos gerentes
um meio de ava liar a lternativas.
• Forneceram uma base para obter os fatos necessários para a tomada de decisões.
• Utilizavam u1na chamada análise de rede temporal como o método básico para
detenninar os requisitos em termos de mão de obra, materia l e capital, a lém de
fornecer um 1neio para verificar o progresso.
• Forneceram a estr utura básica para gerar relatórios de informações.
Infelizmente, as técnicas de geração de cronogra1na não podem substituir o plane-
jamento, e são apenas tão boas quanto as informações que entra1n no plano. Críticas
às três técnicas na década de 1980 incluíam o seguinte:
• São necessários tempo, mão de obra e esforços intensos para usá-las.
• A capacidade da a lta gerência de contr ibuir com a tomada de decisões pode ser
reduzida.
• A propriedade funcional das estitnativas foi reduzida.
• Dados históricos para estimar tempo e custo foram perdidos.
• A suposição de recursos indesejados era inadequada.
• A quantidade de detalhes necessários tornou inapropriado o uso integral das fer-
ramentas de geração de cronograma.
Avanços nas capacidades de men1ória dos sisten1as computacionais 1nainfra1ne
du rante a década de 1990 acabaram por possibilita r a superação de mu itas das de-
ficiências nas três técnicas de geração de cronogramas que estavan1 sendo usadas na
gestão de projetos nas décadas de 1970 e 1980. Surgiu um grande número de pacotes
para mainframe que combinavam técn icas de geração de cronogramas com capa-
cidades de planejamento e estin1ativa. A estimativa, então, podia inclu ir bancos de
dados históricos nos quais armazenávan1os os arquivos de memória do mainfra,ne.
Os progran1as de computador também se mostraram úteis na alocação de recursos.
As lições aprendidas com projetos anteriores tan1bém poderian1 ser armazenadas
em arquivos históricos. Isso melhorou o planejamento futuro além dos processos de
estimação.
O inconveniente era que os pacotes de software de gestão de projetos para tnain-
frames eram muito caros e difíceis de usar, e foram considerados 1nais apropriados
para projetos maiores nos setores aeroespacial, de defesa e de grandes construções.
Para empresas de pequeno e 1nédio porte, os benefícios não justificavam o investimen-
to.
O uso eficiente de software de gestão de projetos de qualquer tipo exige que as
equipes e os gerentes de projetos primeiro compreendatn os princípios da gestão de
projetos. Muitas vezes, u1na organização compra um pacote para mainframe sem t rei-
nar seus funcionários em como usá-lo no contexto da gestão de projetos.
Por exemplo, em 1986, um grande hospita l de renome nacional adquiriu um pa-
cote de software para mainframe no va lor de US$130 mi l. Os funcionários do depar-
tamento de siste1nas de informação do hospital foram inst ruídos a usar o pacote para
o planejamento e relatórios de status de todos os projetos. Menos de 10% dos fun-
cionários da organização recebeu a lgum treinamento em gestão de projetos. Treinar
pessoas no uso de software sem antes treiná-las nos princípios da gestão de projetos
provou ser um verdadeiro desast re. O moral da organização chegou ao fundo do poço
e, finalmente, todos pararam de usar o caro software.
De 1nodo geral, os pacotes de software para mainframe são mais difíceis de imple-
mentar e usar do que pacotes menores, de computadores pessoais. Por que motivo?
Os pacotes para mainfra,ne exigem que todos usem o mesmo pacote, geralmente da
mesma forma. U1n estudo post mortetn realizado no hospital identificou as seguintes
dificuldades comuns durante a imple1nentação de seu pacote para mainframe:
• Os gerentes de níveis mais altos às vezes não gostavan1 da real idade dos resultados.
• Os gerentes de níveis 1nais a ltos não usavam os pacotes para planejamento, orça -
mento e tomada de decisões.
• Planejadores de projetos que trabalhava1n co1n planeja1nento cotid ianamente às
,.. ,, . .
vezes nao usavam os pacotes em seus propnos proJetos.
• Alguns gerentes de níveis mais altos às vezes não demonstravam suporte e com-
. .
prometimento com o treinamento.
• Não havia relatórios claros e concisos.
• Pacotes para mainfrarne nem sen1pre propiciavan1 o repasse imed iato de infor-
mações.
• O hospita l não possuía padrões de gestão de projetos em vigor antes da i1nple-
mentação do novo software.
• A i1nple1nentação realçou a inexperiência de a lguns gerentes intermed iários em
planeja1nento de projetos e na aplicação de habi lidades organizacionais.
• Nem o ambiente de negócios ne1n a est rutura organizacional oferecia1n suporte à
gestão de projetos/necessidades de planejamento do hospital.
• Eram necessários recursos suficientes/extensos (funcionários, equipamentos, etc.).
• A entidade de negócios não determinou a extensão e o uso apropriado dos siste-
. .
mas na organ1zaçao.
• Alguns funcionários via1n o sistema como um substituto para as habilidades inter-

pessoais extensas que se exigiam dos gerentes de projetos.
• A Ílnplementação do software não teve êxito porque os funcionários do hospital
não tinham treinamento suficiente em princípios de gestão de projetos.
Hoje, os gerentes de projeto têm uma grande variedade de software para compu-
tador pessoal disponível para o planejamento, a geração de cronogramas e o cont role
de projetos. Pacotes como o Microsoft Project possue1n quase as mesmas capacidades
que os pacotes para mainframe. O M icrosoft Project pode importar dados de outros
programas para planejar e estimar, faci litando as difíceis tarefas de acompanhar e
controlar diversos projetos.
A simpl icidade dos pacotes para computador pessoa l e sua faci lidade de uso fo-
ram especia lmente va liosas em empresas de pequeno e médio porte. Os pacotes são tão
acessíveis que até mesmo as 1nenores empresas podem dominar a gestão de projetos e
buscar a excelência.
É claro que até mesmo o mais sofisticado pacote de software nunca poderá subs-
tituir u1na liderança de projeto competente. Sozinhos, esses pacotes não conseguem
identificar ou corrigir problemas relacionados a tarefas, mas podem ser ferramentas
incríveis para o gerente de projetos usar ao acompanhar as muitas variáveis e tarefas
inter-relacionadas que ent ram em jogo na gestão de projetos contetnporânea. Exem-
p los específicos dessas capacidades incluem os seguintes:
• Resumo dos dados do projeto; dados sobre despesas, prazos e atividades
• Capacidades gráficas da gestão de projetos e do negócio
• Capacidades de gerencia1nento de dados e geração de relatórios
• Análises do caminho crítico
• Formatos de relatórios personalizados e padrão
• Acompanha1nento de diversos projetos concomitantemente
• Divisão em sub-redes
• Análise de Ílnpacto
• Sistemas de alerta precoce
• Análises on-line de alternativas de recuperaç.ã o
• Apresentações gráficas de dados de custo, prazo e atividades
• Planejamento de recursos e análises
• Análises de custo e variância
• Calendários múltiplos
• Nivelamento de recursos
A Figura 4- 20 1nostra que, hoje, aproximadamente 95 % dos software de gestão
de projetos focam planejamento, geração de cronogramas e controle de projetos. No
futuro, podemos esperar que se crie1n ma is software para a iniciação e o encerramento
de u1n projeto.
Atualmente, o n1aior prob lema com as n1etodologias é que as empresas não estão
tirando proveito de todas as capacidades das ferramentas que estão adqu irindo. Un1
exen1plo perfeito disso é o sistema de gestão do valor agregado (GVA - EVM, earned-
· value measurement). As e1npresas parecen1 estar relutantes e1n usar a GVA provavel-
1nente por n1edo da rea lidade financeira que os nú1neros da GVA irão 1nostrar.
A intenção por trás da GVA é garantir que a pessoa que está liderando o projeto
esteja funcionando como gerente, e não como mero monitor de projetos. Os monitores
de projetos simples1nente registra1n números e os repassam a uma autoridade superior
para a tomada de decisões. O gerente de projetos, por out ro lado, 1nede as variâncias
em relação às linhas de base, desenvolve planos de contingência, obtém a aprovação

dos planos, implementa-os e mede as novas variâncias, para verificar se as 1nelhorias
funcionaram. Sem o uso integral de um sistema de GVA, pode ser difícil gerenciar um
projeto de maneira plena.
Enrique Sevilla Mol ina, PMP® e antigo diretor do PMO corporativo da Indra,
afinna:
As técnicas de valor agregado são usadas d urante a execução do projeto. A mensuração d o
valor agregado é realizada regularmente pelo gerente de projetos, q ue, para tal, faz uso da
ferramenta corporativa.
As variâncias são analisadas mensa lmente no nível do pacote de trabalho e também no
nível do projeto.
Se for ne.cessária uma ação corretiva, ela é iniciada pelo gerente de projetos, que analisa
um conjunto de ind icadores (stat11s de risco, custo geral, cronograma e desvios marginais,
fluxo de caixa do projeto, etc.), o que é seguido pelo julgamento especializado do contro-
lador de área, q ue também considera a análise das informações fornecidas pela equipe de
projetos. Se for o caso, um relatório executivo específico pode ser solicitado ao GP para for-
necer informações mais detalhadas sobre os desvios por cada pacote de trabalho e o status
do programa como um todo. Uma vez que o quadro geral do projeto esteja claro, toma-se
uma decisão quanto à necessidade de ações corretivas.
Ta lvez a GVA seja a melhor abordagem para determinar progresso, status e, fi-
nalmente, previsões de aonde chegaremos. O componente crítico da GVA é o valor
agregado, que é a quantidade de t rabalho que foi fisicamente concluída e medida ou
em horas ou em dólares. Mui to frequentemente, as empresas aceitam a GVA como u1n
"estilo de vida", sem cotnpreender as complexidades de seu uso. Memorizar as 12-15
equações necessárias para usar a GVA é fácil. O que é d ifíci l é captar os dados que
entram nas equações. Carl Manello afirma que:
O valor agregado (EV, earned va/11e) não é para iniciantes. Conceitualmente uma medida
simples de trabalho rea lizado/a ser real izado, o esforço que é preciso para levantar os
dados necessários e fazer os cálculos não é tarefa fácil. Mu itos de meus cl ientes faziam
um trabalho tão deficiente no sentido de gerenciamento do tempo e poss uíam tamanha
insuficiência de planos de projeto que captar as informações nos níveis requeridos para
95°/o do software de hoje
INICIAÇÃO EXECUÇÃO CONTROLE ENCERRAMENTO
•
D
Estudos de viabilidade
Áreas de deficiência D
• Lições aprendidas
• Análises de custo-benefício • Biblioteca de
• Definição de critérios melhores práticas
• Premissas definidas • Análises de fracassos
• Critérios de avaliação
• Gestão de riscos
• Software comportamental
Figura 4-20 Software de gestão de projetos.
o VA se tornava a lgo quase impossível. Depois de trabalhar com inúmeras empresas

14
Fort une 250, encontrei apenas uma que acompanhava o IDPnDC (SPUCPI). Levantar
dados sobre o projeto, rea li zar a garantia da qual idade e manter as informações com
precisão em uma ferramenta de gestão de projetos exigia despesas gera is sign ificativas
(o programa empregava ma is de uma dúzia de pessoas cuj as ún icas responsabilidades
eram a entrada e a precisão de dados e geração de relatórios por meio da ferramenta do
projeto).
Para os projetos menos maduros, geralmente uso uma variação do va lor agregado,
q ue se baseia na conclusão de de/iverables. Usando plan ilhas simples, posso acompanhar
os de/iverables (q ue são atribuídos diferentes valores no rascunho e na versão), marcos e
principais atividades. A planilha gera g ráficos que representam q ue fração do trabalho já
foi produzida, o custo associado ao tempo previsto no cronograma e os valores agregados
reais, em comparação ao plano (ver Figuras 4-21 a 4-23). Cada deliverable é compara-
do com um cronograma planejado para a conclusão, e créditos só são rea lizados com
q ualq uer valor entregue mediante concl usão (i.e., algo 90% completo recebe um belo e
gordo zero nesse modelo. Há muitas circustãncias em q ue essa abordagem extremamente
simplista não é adequada, e um deliverab/e parcialmente concluído tem valor. Nessa im-
plementação, porém, as opções são tudo o u nada). Embora essa ferramenta também exija
algumas despesas gerais para cria r a lista inicia l baseada na estrutura ana lítica do projeto,
acompanha r a conclusão e atualizar o s/.atus para q ue ele refl ita o progresso, suas despesas
gerais são da ordem de horas em vez de múltiplos eq ui valentes a dias trabalhados em regi-
me de tempo integral.
._L I._ ,
Tempo gasto
Trabalho concluído • Real

• Total
Custos incorridos
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Percentual concluído
Figura 4- 21 Custos reais versus totais.
14
IDP ou SPI é o índice de desempenho de prazo (sdtedule performance index ) e IDC ou CP) é o índice de
desempenho do custo (cosr performance índex). SPI e CPI identificam as tendências ou direções em que custo
e cronograma estão apontando. Dura me o IJriefing dos executivos sobre o status do projeto, geralmente o SPI
e o CPI são os dois primeiros números discucidos.
100,0%
-+- linha de base
90,0%
-- Plano
80,0% -+-Real
o 70,0%
:!e!
.2
<.>
e 60,0%
o
<.>
-.,
"'
:,
e
50,0%
-
.<.>,
Cl.
40,0%
30,0%
20,0%
10,0%
0,0%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Semanas
Figura 4-22 Valores agregados reais em comparação ao plano.
Status
Deliverables Cronograma Orçamento Despesas gerais
10% 12% 9o/o
o o o o
Legenda: O No alvo @ Em risco • Em perigo
Indicadores-chave
Escopo Entrega Custo Pessoal
~
Legenda: ~ Estável il' Aumentando O Diminuindo
Figura 4-23 Direções do status e indicadores.
4.20 Wãrtsilã: reconhecendo a necessidade

15
de ferramentas de suporte
Apesar de sempre termos tido uma grande paixão por motores na Wãrtsila, agora so-
mos muito 1nais do que uma empresa produtora de motores. Atualmente, o gerencia-
u O material foi fornecido pelo escritório de gestão de projetos da \Vãrcsilã (\VPMO). Direitos aurorais da
Wãrtsilã Corporacion 2013. Reproduzido com permissão.
mento de projetos profissional se tornou parte essencia l de nosso sucesso continuado

devido aos projetos marinhos e de usinas de energia elét rica maiores e mais complexos
que entrega1nos.
Gestão de projetos excelente - um pré-requisito para

a satisfação do cliente
O escritório de gestão de projetos da Wartsilii (WPMO) foi estabelecido em 2007 para
desenvolver uma cultura de gerenciamento, processos, competências e ferramentas a
fim de garantir que nossos cl ientes recebessem a satisfaç.ã o que merecetn.
Uma das primeiras coisas que fizemos foi conduzir uma análise detalhada de ges-
tão de projetos para identificar áreas que necessitavam de mel horias. Naquela época,
não tínhamos software para gestão de projetos e portfólios. Portanto, uma das pri tnei-
ras providências totnadas pelo WPMO foi iniciar um programa de melhoria global
chamado de "gateway" para desenvolver e imple1nentar um conjunto de processos de
gestão de projetos e portfólios cotn utn aplicativo de suporte.
Segundo o proprietário de projetos, Antti Kiimi, o ponto de partida do gateway
e o motivo pelo qual a Wiirtsilii precisava aprimorar a gestão de projetos ainda 1nais
foram os seguintes: "A gestão de projetos profissional era vista como verdadeiramente
essencial para nossa lucratividade, competitividade e para gerar valor para nossos
clientes" .
Projetos divididos em três categorias

Para alcançar o ma ior número possível dos benefícios esperados, ficou decidido que as
partes relevantes dos processos unificados da nova ferramenta deveriam ser usadas em
todas as divisões e em todas as três categorias de projeto da etnpresa:
• Projetos de entrega ao cliente
• Projetos de desenvolvimento operaciona l
• Projetos de desenvolvimento de produtos e soluções
Usar essa nova abordagem significava que 1n ilhares de projetos poderiam ser ge-
renciados com a nova ferramenta, envolvendo aproximadamente 2 mi l pessoas na
Boas práticas de gestão de projetos

Hoje temos processos de negócios unificados (modelos de pontos de decisão) em uso
em toda a Wiirtsilii com d iretr izes e term inologia harmonizados. Além disso, 1nante-
mos esse recurso por 1neio de um treinamento profissional e certificação em gestão de
proJetos.
Assim cotno todos os projetos dessa magn itude, enfrentamos 1nuitos desafios
pelo caminho, especia lmente ao desenvolver paralelamente tanto o modo de trabal har
quanto o software. Os níveis variados de maturidade etn gestão de projetos na empre-
sa também representaram um grande desafio. O resultado positivo foi que hoje temos
etn vigor um diálogo contínuo e ativo em torno da gestão de projetos, há uma enorme
t roca de experiências entre as divisões e categorias de projetos e o trabal ho nos dá uma
verdadeira sensação de haver "Uma Ún ica Wiirtsilii".
Em diversas áreas da gestão de projetos, já podemos ver melhorias e benefícios,
especiahnente no gerenciamento de portfólios e no de recursos.
Atualmente, usa1nos a nova aplicação como um banco de dados de projeto para

o planeja1nento de portfólio de nossa Pesquisa e Desenvolvimento. Isso permite que
os projetos sejam organizados em portfólios, o que significa que há um processo de
segu imento mais est ruturado. Isso, por sua vez, leva a uma ma ior transparência e
visibi lidade em projetos, respostas 1na is fáceis e rápidas às indagações dos cl ientes e
relatórios de projeto mais eficientes de maneira gera l.
U1n gerencia1nento de a lta qualidade é importante hoje pelo fato dos recursos do
gerenciamento de informações serem usados e1n projetos de desenvolvimento opera-
cional em toda a empresa. Ter uma ferramenta de software co1npartilhada por todos
garante boa disponibilidade de recursos, transparência para gerenciar e monitorar a
carga de trabalho, além de fatos confiáveis para um bom planejamento.
Outros benefícios incluem a possibilidade de registrar e util izar lições aprendidas,
a possibi lidade de colaboração e de ter infonnações faci lmente disponíveis para todos
os membros de equipe de projetos.
Ferramentas rea lmente fazem a diferença na gestão de projetos

Resumidamente, é disto que se t rata o gateway da \Vãrtsilã: elaborar e apl icar u1na
maneira 1na is eficiente de planejar e dirigir projetos e uma ferra 1nenta co1nu1n a todos
para nos ajudar a levantar, manipular e co1npartilhar informações relacionadas a pro-
jetos. E, com isso, garantir que tanto os cl ientes internos quanto os externos esteja1n
satisfeitos.
4.21 Tech Mahindra Ltd.: monitoramento

dos processos de projetos
Na seção anterior, discutimos a lgumas das ferramentas que são usadas com as meto-
dologias de gestão de projetos. O GVA e as ferramentas de geração de cronogramas
são comuns à maioria das metodologias. Algumas empresas criam ferramentas exclu-
sivas para sua organização e, assim, potencializa1n seus benefícios esperados. Essa é a
situação da Tech Mahindra Ltd. O restante das informações desta seção foi fornecido
por Krishna Ga li, do Grupo de Qualidade da Tech Mah indra Ltd. e Anu Khendry, do
Tech Mahindra Limited Learning World, Tech Mahindra Ltd.
A Tech Mahindra Ltd. é uma empresa de serviços de so ftware que conduz seus
negócios por meio de projetos de software que precisam cu1nprir parâmetros críticos
de produtos e processos definidos pelos cl ientes. O monitoramento dos processos de
projetos (PPM, project process m onito-ring) é u1na atividade de garantia que permite
que os gerentes, suas equipes e a gerência sên ior co1npreendam esses parâmet ros crí-
ticos e os níveis relacionados de conformidade do projeto. O PPM é uma atividade
obrigatória para todos os projetos de proposta fixa e projetos de alto impacto/críticos,
que são definidos co1n base em certos critérios de tamanho, esforço e foco no cliente.
(Ver Figuras 4- 24 e 4-25, que contêm duas partes do PPM.)
Os objetivos do PPM são:

• Providenciar a lertas precoces sobre problemas potenciais do projeto com suges-
tões para medidas corretivas e preventivas
• Identificar e acelerar melhorias nos processos dos projetos
• Identificar as melhores práticas e cotnpartilhá-las com toda a etnpresa
Os recursos exclusivos do processo de PPM incluem:

• Avaliação em 12 áreas essenciais de foco do projeto com parân1etros predefinidos
• Classificaç.ã o quantitativa do projeto em uma escala de O a 100
• Automatização e integração com out ras ferramentas de gestão de projetos da
Tech Mahindra Ltd.
• Avaliação do processo alinhada ao CMMJ e à Organização Internacional para a
Padronização (ISO) 9001 - Sistema de Gestão da Qua lidade (SGQ)
O processo PPM incluí:

• Autoavaliação pelo gerente de projetos em todas as áreas e parâmetros de foco
que forem aplicáveis ao projeto.
• Revisão e validação pela garantia da qua lidade na conformidade do projeto.
Isso é feito por 1neio da ava liação dos artefatos do projeto em relação a requisi-
tos aplicáveis a produtos/processos. No final desse passo, o projeto possui uma
taxa de conformidade em uma escala de O a 100 e um status vermelho/amarelo/
verde baseado nessa taxa.
• Relatórios sobre as avaliações do projeto para a gerência sênior.
• As deficiências observadas durante o PPM são acompanhadas no mês subse-
quente.
Figura 4-24 Monitoramento de processos de projeto.
• N. de T.: SLAs (Service Levei Agreements ) ou Acordos de N ível de Serviço.

Os diagramas de contexto nos PPMs...
Esclarecimentos/
respostas
Satyam SSU Qualidade -
Corporate Relatório Garantia da qualidade total (TOA)
dePPM
Monijorar/revisar e gerar relatórios
Revisão e suporte sobre o projeto
Conformidade de processos e suporte
Equipes de projeto para
. - - - - - ' melhorias/entrega ao cliente
Requisitos Entrega
Cliente Cliente
Figura 4-25 Monitoramento de processos de projeto.
O processo de PPM permitiu a identificação dos problemas certos do projeto na

hora certa para sua resolução imediata. Os relatórios de PPM descreve1n dados em
tempo real sobre o dese1npenho do projeto. A automatização dos processos també1n
ajudou na condução da análise por vencimento-base de problemas do projeto e seu
aco1npanhamento até o seu encerramento.
As revisões do PPM realça1n o impacto da não conformidade nos t rês parâmetros
básicos do projeto : qua lidade, custo e prazo. O sucesso desse processo é evidente e se
tornou uma informação crucial no suporte de todas as revisões de desempenho em-
presarial no nível corporativo com relatórios quantitativos de problemas do projeto,
. ' .
mes a pos mes.
O processo Customer One

No ciclo de vida de um projeto de software na Tech Mahindra Ltd., produtos de
software são criados, revisados e testados em diversas fases, como testes de unidades,
testes de integração e testes de siste1na. O foco, durante essas fases, é uma detecção de
defeitos e cumprimento dos requisitos do cliente.
A fase final de testes antes da ent rega é chamada de testes de aceitação pelo usuá-
rio (TAU ou e1n inglês, UAT, user acceptance testing). Durante essa fase, as equipes de
projeto revisam, inspecionam e testam o deliverable final a partir da perspectiva do
cl iente. Qualquer desatenção nesse momento pode permitir que defeitos cheguem às
mãos do cliente, resultando na sua insatisfação e em retrabalho. Isso afeta negativa-
mente não somente a ent rega eficiente e eficaz do projeto, 1nas também o relaciona-
mento com o cl iente de forma geral. O processo Customer One (Cl ) da Tech Mahin-
dra Ltd. garante que os deliverables fina is atendam às expectativas do cl iente, levando
ao seu encantamento. (Ver Figura 4-26. )
Modelos
de soluções
Modelos de
tecnologia
Figura 4- 26 C1: componentes de avaliação que d irecionam compromissos contratuais.
Os objetivos do processo Ct são:

• Validação externa dos deliverables fina is do projeto a partir da perspectiva do
cl iente
• Decisão de aprovar/reprova r na liberaç.ã o dos deliverables do projeto para o
cl iente
O foco da avaliação Cl é validar que os deliverables do projeto não so1nence
cumprem as especificações e requisitos específicos do cl iente, mas também que estão
em conformidade com seus requisitos implícitos e valor de negócio pretendido. O C1,
assi tn, ajuda a evitar qualquer surpresa desagradável para o cliente, que exija subse-
quentes au1nentos na qualidade da entrega.
Os projetos são selecionados para avaliação Cl com base em seu grau de critica-
lidade para o cliente, 1nodelo de precificação e tipo de projeto. A aval iação é realizada
por uma equipe de especialistas com co1npetências/habi lidades relevantes. A equ ipe de
ava liação Cl cem o suporte de d iretr izes detalhadas e1n diversas áreas de foco, indo
desde requisitos, tecnologia/ferramentas e arqu itetura técnica a 1netodologias de ent re-
ga, testes e atividades pré-implementação.
As ava liações C1 de qualquer projeto são amplamente classificadas em dois com-
ponentes:
1. Aval iação da eficiência da solução em comparação à declaração de tr abalho
(DT)/requisitos
2. Aval iação dos deliverables do projeto em comparação aos requisitos e especi-
ficações de negócio
A avaliação envolve:
• Rea lizar de um papel de pseudocl ience
• Inclu ir da visão do cl iente na avaliação de soluções/produtos/serviços
• Priorizar os compromissos cont ratuais (declaração de trabalho, DT)
• Descobrir riscos potenciais
O processo de ava liação Cl é automatizado e integrado a outr as ferra tnentas de

gestão de projetos da Tech Mahindra Ltd. O sucesso desse processo foi observado por
meio de um aumento significativo nas apreciações do cliente sobre a qua lidade dos
deliverables.
4.22 Tech Mahindra Ltd.: índice de satisfação

do cliente para projetos
O que é mais importante para a empresa típica: 1nanter alianças com os clientes exis-
tentes ou buscar novos cl ientes? Poderíamos discutir que ambos são igua lmente im-
portantes. No entanto, devido às forças competitivas do mercado, a dianteira va i para
os esforços de gerenciamento de clientes e relacionamento com o cliente. Há uma
tendência hoje a adicionar uma fase ao ciclo de vida após o encerramento do contrato
chamada de "gerenciatnento da satisfação do cliente" ou "gerenciamento do relacio-
namento com o cliente". A finalidade dessa fase é ana lisar o grau de satisfação do
cl iente durante todo o projeto, com os resultados finais e com o fluxo de informação
fornecido por sua metodologia de gestão de projetos. Nessa fase, você pergunta ao
cl iente: "Que melhorias você gostaria que fizéssemos antes do próxi1no projeto que
realizarmos para você?". O cliente pode sol icitar maior envolvimento nas ,nu danças
no escopo, um diferente formato de relatórios de status ou mesmo 1naneiras melhores
de acompanhar o status de seu projeto ao longo da aplicação de sua metodologia de
Embora essa abordagem de ter uma fase do ciclo de vida chamada de "gerencia-
n1ento da satisfação do cliente" tenha seu n1érito, ela apre.senta tan1bém um risco de
que esta seja analisada somente no final do projeto. Boas en1presas acompanham a
satisfação do cl iente durante todo o projeto, não somente no fina l. A Tech Mahindra
Ltd . descobriu uma maneira bastante interessante de fazer isso. As inforn1ações res-
tantes desta seção foram fornecidas por H irdesh Singhal e Anu Khendry, da School
of Program and Project Management, Tech Mahindra Ltd.
A Tech Mahindra Ltd. é uma empresa de serviços de software que gerencia proje-
tos que foram terceirizados à empresa por seus clientes. A satisfação ou encanta tnento
do cliente desempenha um papel crucial na obtenção de negócios de repetição com os
cl ientes, e isso é importante para o sustento da Tech Mahindra Ltd. Além disso, reter
um cliente custa significativamente tnenos do que adquirir um novo. O modelo do
índice de satisfação do cl iente (ISC ou, etn inglês, CDI, customer delight índex) foi de-
senvolvido na Tech Mahindra Ltd. para medir e aumentar continuamente a satisfação
do cliente.
O ISC é medido para todos os projetos da Tech Mahindra Ltd. (Ver Figura 4-27.)
O ISC é essencia lmente a perspectiva do gerente de projetos sobre o que ele observa
da percepção do cl iente quanto aos serviços prestados a partir das cotnun icações e in-
terações cotn as partes interessadas na empresa do cliente. Ele ajuda a gerência sênior
ou investidores de projetos a agir proativamente e a apoiar os projetos, se necessário.
Para os gerentes de projetos, ajuda a enviar os sinais certos proativamente à gerência
de que eles precisam de seu apoio e intervenção.
Os alvos do /SC:
• Ava liar a saúde dos projetos e tomar medidas proativas a fim de evitar esca lada
de conflitos com os clientes.
• Acompanhar, até o encerra tnento do projeto, problemas crucia is que afetem

diretamente a satisfaç.ã o extretna do cliente.
• Identificar e registrar motivos para o encanta tnento do cliente.
Registra -se o valor do ISC dependendo da perspectiva do gerente de projetos so-
bre "como o cliente está se sentindo a respeito do projeto". Chega-se ao valor com
base no feedback do cliente e interações com ele. Os gerentes de projeto precisam
registr ar o ISC, problemas do projeto e/ou motivos de satisfação com uma frequência
acordada ent re as partes. Os gerentes de programa revisam o status do ISC com a
mesma frequência .
Há quatro tipos de status para o ISC (ver Figura 4-28):
Se o status do ISC for "extremamente satisfeito", espera-se que o projeto tenha
um ou ma is motivos para a satisfação do cliente. Os gerentes de projeto precisam re-
gistrar o(s) motivo(s) e salvar o nome do arquivo.
Se um gerente de projetos deixar de regist rar o ISC dentro do período especificado
de uma semana, o status registrado será de "Dados não registrados" (representado
pela cor "cinza") para aquela semana.
Se o status de ISC for "insatisfeito", espera-se que o projeto tenha no mínimo um
problema em aberto que refl ita o motivo de insatisfação do cl iente. Os gerentes de
projetos precisam regist rar o problema e salvar o arquivo.
Depois de ter atua lizado os problemas/motivos de satisfação cotn o projeto, se-
leciona-se a classificação de ISC apropriada, e o status do ISC é sa lvo (Figura 4- 29).
Problemas de um projeto
Os problemas do projeto precisam ser comparados ao conjunto predefinido de cate-
gorias e subcategorias. Quando o status de ISC for diferente de "ext remamente satis-
feito", os gerentes de projetos precisam especificar os problemas do projeto usado as
categorias e subcategorias.
É obrigatório para utn projeto ter no mínitno um problema etn aberto que seja a
causa provável de insatisfação do cliente quando o status de ISC do projeto for "insa-
tisfeito".
Projetos em que o status de ISC é "satisfeito" ou "extremamente satisfeito" tam-
bém podem ter proble1nas que ou têm um potencia l de afetar a satisfação do cl iente ou
são questões internas que precisam ser acotnpanhadas até sua resolução.
Um projeto que tenha o status de ISC como " insatisfeito" não terá permissão para
passa r para "satisfeito" ou "extrema tnente satisfeito" sem todas as questões que estão
etn aberto seretn resolvidas (Figura 4- 30).
Motivos do projeto
Em casos em que o status de ISC é "extremamente satisfeito" e/ou "satisfeito", os
gerentes de projeto precisarão informar os motivos do projeto que os ajudaram a
"satisfazer" o cl iente. Na mesma tela de "satisfação do cliente", o gerente de projetos
precisa informar os motivos do projeto dentre as opções que estão listadas. Dependen-
do da seleção, será ativado o campo dos motivos.
J
J
-<D
eQ)
o
o
"O
)
·-"'~
o
~ "'
iJ!
- -
"'
r;
t
~
Q)
"O
Q)
·ºe
"O
-i_f• J
j
·-o
"O
.. a - o
i -í 1 :ri
i It 1 ,~-~
t ~
8
e
o..
d!
••
• • • • • • !f•
•
I'-
"'...1
'"
~
:,
e,
i!
.
Q)
.
6
'
Dados não registrados
Insatisfeito
Satisfeito
o Extremamente satisfeito
Figura 4-28 Resumo das categorias de satisfação.
Parãmetro/
Extremamente satisfeito Satisfeito Insatisfeito
Interpretação
Escopo Escopo cumprido com Escopo cumprido com níveis Escopo não cumprido
soluções/serviços de aceitáveis de desempenho
valor de negócio superior das soluções/serviços
Qualidade Produtos/serviços entregues Produtos/serviços entregues Produtos/serviços entregues

com defeitos mínimos com níveis de defeitos com nível de defeitos além
aceitáveis pelo cliente do aceitável pelo cliente
Cronograma Concluído antes do prazo/ Dentro do prazo/atraso Atrasado

tempo de retorno mutuamente aceito
A classificação de ISC do projeto pode ser selecionada com base em uma combinação dos fatores acima.
A classificação do ISC deve ser a mais baixa das interpretações de escopo de todos os parâmetros juntos.
Por exemplo, se a classificação do escopo de determinado projeto for "Extremamente satisfeito" e a de
"Qualidade" e "Cronograma" for "Satisfeito", a classificação de ISC geral do projeto deverá ser "Satisfeito· .
Figura 4-29 Diretrizes para a seleção da classificação do ISC.
4.23 General Motors Powertrain Group

Para en1presas com projetos pequenos ou de curto prazo, as metodologias de gestão de
projetos poden1 não ser apropriadas ou não ter uma boa relação custo-benefício. Para
e1npresas com projetos de grandes proporções, no entanto, uma metodologia que fun-
cione é quesito obrigatório. O General Motors Powertrain Group é un1 outro exemplo
de un1a grande e1npresa que alcança a excelência e1n gestão de projetos. Os negócios
da en1presa baseiam-se prin1ordialn1ente en1 projetos de internet, embora sejan1 aceitos
a lguns projetos de contrato de clientes externos. O tamanho dos projetos do grupo
varia de US$100 1n ilhões a US$1,5 bilhões. Sediado en1 Pontiac, M ich igan, EUA, o GM
Powertra in Group desenvolveu e Ílnple1nentou u1na 1netodologia de gestão de projetos
de quatro fases que se tornou o processo central de seu negócio. A en1presa decidiu
adotar o gestão de projetos para colocar seus produtos no n1ercado 1na is rapidamente.
Segundo Michael Mutchler, antigo vice-presidente e executivo do grupo:
A principal expectativa que tenho co m uma organização focalizada em produtos é uma exe-
cução eficiente. Isso compreende desenvolvimento, implementação e operações cotidianas
de programas de produtos disciplinados e eficientes. Foram formadas equi pes de pro duto
para criar um ambiente em que os líderes pudessem compreender melhor o mercado e as
necessidades do cliente a fim de estimular o pensamento em termos de sistemas e um com-
portamento multifuncional e interdependente e de possibi litar que todos os funcionários
categoria Subcategoria categoria Subcategoria

1. Gerenciamento de clientes Comunicação com o cliente 4. Recursos humanos Compe1êncla
Escopo Atritos
Eslllo do cliente Produtividade
Escalada de conflitos com o ctlente Motivação
Assinatura dt ae:eltaÇão do cliente Atitude
Expectativa do ctlente TrabalOO em equipe
Dlsponib[lldade de recursos
2. Gestão de projetos Crooograma do p,ojeto Conhecimento de domínio
Estimação
COQbOraçãO 5. lnlraestnitura e serwlços Equipamentos
Comunicação Espaço de esetitórlo
Conformidade com o projeto Instalações de comunicação
Propriedade do projeto ConectMdadt em rede e bar'Mb larga
Riscos Viagens e embatques
Aoompanhamenro econtrole do projeto Imigração
Ptaoet,amento do pro;eto
6. Flnanças Contrato do projeto
3. Engenh.arla de sottwar, Requisitos PO (Purchas, Oroev)/llecQração de Trabalho (OT)
Design Faturamento
Cod~lcaçllo Custo do projeto
Testes Lucratividade dO projeto
Entrega
Implementação
Tecnologia
Qualidade do software
Ge,enclamento de configuração
Ambiente {desenvoMme1to.1estes. etc.)
Figura 4-30 Categorias de satisfação detalhadas.
compreendam seu papel na execução das estratégias do Glvl Powertrain e na entrega de

produtos de a lta qualidade. Essa estratégia organ izacional pretende possibilitar que uma
grande organização seja responsiva e entregue produtos de qualidade desejável e acessível
para os clientes.
O processo de gerenciamento de progra tna no GM Powertrain baseia-se em te,n-
plates, listas de verificação e sistemas cotnuns. A segu ir, listamos vários elementos que
eram comuns a todos os programas do GM Pov,rertrain durante a década de 1990:
• Termo de abertura e contrato
• Estrutura organizacional da equipe de programa com papéis e responsabilidades
definidas
• Planos de programas, cronogramas e redes lógicas
• Sistemas de acompanhamento no nível do programa e no nível da parte interes-
sada
• Processo de desenvolvimento de produtos com quatro fases
• Processo de gerenc.ia tnento de mudanças
Dois elementos críticos da metodologia do GM Pov,rertrain são o termo de abertu-
ra e o contrato do progra tna. O termo de abertura define o escopo do programa com
objetivos tnensuráveis, como:
• Final idade de negócio
• Objetivo estratégico
• Resultados que o programa procura alcançar
• Engenharia e orça1nento de capital

• Cronologia do programa
O cont rato do programa especifica como ele real izará os objetivos determinados
no tenno de abertura. O contrato se torna uma ideia co1npa rti lhada do que a equipe
de programa irá entregar e o que a equipe do GM Powert rain oferecerá à equipe em
termos de recursos, suporte, ent re outros.
Embora as informações aqui no GM Pov,rertrain possam parecer um pouco ultra-
passadas, elas most ram que a GM estava vários anos à frente da maioria das empresas
no desenvolvimento de u1na metodologia de gestão de projetos. A GM fez mudanças
significativas e1n sua 1netodologia desde então. O que a empresa conseguiu há mais de
u1na década, muitas estão apenas começando a desenvolver hoje. Atualmente, a GM
usa a supra1nencionada metodologia para o desenvolvimento de novos produtos para
projetos de software.
4.24 Ericsson Telecom AB

A Genera l Motors Co rpo ration e o banco foran1 exen1plos de metodologias de
gestão de projetos internas à organização (i.e., clientes internos ). Para a Ericsson
Telecom AB, o problen1a é n1ais con1plicado. A maioria dos projetos da Ericsson
é voltada para cl ientes externos, e a empresa possu i divisões en1 todo o n1undo .
Será possível desenvolver uma metodologia que satisfaça essas restr ições de alcance
mundial?
Em 1989, a Ericsson Telecom AB desenvolveu uma metodologia de gestão de pro-
16
jetos que foi batizada PROPS. Ainda que, inicialmente, a intenção fosse utilizá-la em
projetos de desevolvimento técnico na Área de Negócios de Telecomun icações Públi-
cas, a PROPS vem sendo aplicada e apreciada em toda a rede 1nundial da Ericsson,
e1n todos os tipos de projetos. Na opinião do autor, a PRO PS é uma das metodologias
mais bem-sucedidas do mundo.
Novos usuários e novos ca1npos de aplicações aumentaram a demanda pela
PROPS. Os usuários fornecem feedback sobre as lições aprendidas de modo que suas
experiências compartilhadas possam ser usadas para a t ua lizar a metodologia. Em
1994, foi desenvolvida uma segunda geração da PROPS, incluindo aplicações para
pequenos projetos, projetos de engenharia simultânea e projetos multifunciona is que
incluíam melhorias cujo objetivo era au1nentar a qua lidade dos projetos.
A PRO PS é genérica por natureza e pode ser usada em todos os tipos de organiza-
ção, o que fortalece a possibilidade da Ericsson de conduzir projetos com sucesso em
todo o mundo. A metodologia pode ser utilizada em todos os tipos de projetos, inclu-
sive em desenvolvimento de produtos, desenvolvimento organizacional, constr ução,
marketing, projetos exclusivos, projetos de grandes e pequenas proporções e projetos
multifunciona is.
A PROPS tem seu foco voltado para negócios, o que significa dedicar todas as
atividades operacionais à satisfaç.ã o do cl iente e a ga rantir a lucratividade por meio de
u1na uti lização eficiente dos recursos da empresa. A PROPS usa um conceito de pontos
de cont role e de pat rocínio de projeto para garantir que os projetos seja,n iniciados e
realizados de uma 1naneira orientada aos negócios e que os benefícios para o cl iente e
para a Ericsson sejam sempre considerados.
16
A definiç.ão da sigla PRO PS é em sueco. Pa ra fins de simplificação, será referida assim em rodo este livro.
O modelo da PROPS é extremamente genérico, o que acrescenta flexibilidade à

sua aplicação. Os quatro fundamentos do modelo de projeto genérico são:
• Pontos de cont role
• O 1nodelo do projeto
• Os modelos de trabalho
• Marcos
Os pontos de controle são pontos de decisão superordenada em um projeto nos
quais se tomam decisões formais quanto aos objetivos e à execução do projeto, se-
gundo utn conceito comum a toda a empresa. Na PROPS, cinco pontos de controle
constitutem a estrutura cent ral do modelo. A função e posição dos pontos de controle
são padronizadas para todos os tipos de projeto. Assim, a utilização da PROPS irá ga-
rantir que o 1nodelo corporativo de pontos de cont role da Ericsson seja itnplementado
e aplicado.
O patrocinador do projeto toma a decisão do ponto de controle e assume a res-
ponsabilidade total por todo o projeto e por seus resultados. Uma decisão de ponto
de controle precisa ser bem preparada. O procedimento de decisão de ponto de con-
trole inclui a ava liação e a preparação de um resumo executivo capaz de fornecer ao
patrocinador do projeto argumentos suficientes para suas decisões. O projeto e seus
resultados devem ser aval iados a partir de diferentes aspectos: o stat11s do projeto, os
recursos que sua implantação exigirá e os benefícios esperados para o cl iente e para a
Ericsson. Nos cinco pontos de controle, são tomadas decisões sobre:
• o início do estudo de viabi lidade do projeto;
• a execução do projeto;
• a execução continuada, confirmação do projeto ou revisão de li1nites e implemen-
tação do design;
• a utilização dos resultados finais do projeto, entrega ao cliente, introdução rest rita
no mercado;
• a conclusão do projeto.
O modelo do projeto descreve que atividades de gestão de projetos real izar e que
docu1nentos preparar, desde o início de um pré-estudo até a conclusão do projeto. O
pat rocinador do projeto determina a iniciação do projeto e to 1na as decisões de ponto
de controle, ficando as demais atividades descritas no modelo sob a responsabilidade
do gerente de projetos. O modelo de projeto é dividido em quat ro fases: pré-estudo,
estudo de viabi lidade, execução e conclusão.
O propósito da fase de pré-estudo é avaliar a viabilidade do ponto de vista técnico
e comercial, baseado nos requerimentos expressos e não expressos e nas necessidades
de cl ientes externos e internos. Durante a fase de pré-estudo, formu la-se um conjunto
de soluções alternativas. Faz-se uma estimativa aproximada do cronograma e da carga
de trabalho necessária para as diversas alternativas de implementação do projeto.
A finalidade da fase do estudo de viabi lidade é fonnar uma boa base para o futuro
projeto e preparar a sua execução bem-sucedida. Durante o estudo de viabi lidade,
ana lisa tn -se diferentes alternativas de realização e suas eventuais consequências, além
de seu potencial para cumprir requisitos. Definem-se os alvos e est ratégias, preparam-
-se planos de projeto e se avaliam os riscos envolvidos. In iciam-se as negociações de
cont rato e se define a organização do projeto em utn nível abrangente.
O alvo principal da fase de execução é executar o projeto de acordo com as me-
tas estabelecidas em termos de prazos, custos e detnais características, de maneira a
atingir essas ,netas do projeto e atender os requisitos do cliente. O trabalho técnico é
realizado pela área técnica correspondente dentro da organização, de acordo com os

processos e métodos de trabalho que foram determi nados. O trabalho do projeto é ati-
vamente cont rolado; isto é, o progresso é continuamente verificado, e as providências
necessárias são tomadas para manter o projeto no curso determinado.
A final idade da fase de conclusão é encerrar a organização do projeto, regist rar
as experiências obtidas e garantir que todos os proble1nas mais importantes estejam
sob controle. Durante essa fase de conclusão, os recursos que haviam sido colocados à
d isposição são desativados, sugerindo-se, então, medidas para aperfeiçoar o 1nodelo o
projeto, os modelos e os processos de trabalho.
Além de descrever as atividades que serão rea lizadas para se alcançar detenninado
resultado, o modelo de t rabalho também inclui definições dos 1narcos. Entretanto,
para se chegar a uma descrição completa do tr abalho em um projeto específico, um ou
mais modelos de trabalho devem ser definidos e associados ao modelo gera l do proje-
to. Um modelo de trabalho combinado com o modelo geral do projeto configura uma
aplicação da PROPS. Quando não existem 1nodelos de tr aba lho adequados descritos
para um projeto, é de responsabil idade do gerente de projetos definir as atividades e os
marcos de modo que o plano do projeto possa ser cumprido, e o projeto, ativamente
controlado.
Um marco é um objetivo intermediário que define um evento importante e men-
surável e representa um resultado que precisa ser alcançado nesse ponto. Os marcos
une1n os modelos de t rabalho ao modelo do p ro jeto. Marcos claramente definidos
são essenciais para 1nonitorar o progresso, especia lmente em projetos grandes e/ou
de longo prazo. Além de oferecer u1na forma de est ruturar o cronograma, os marcos
fornecem sinais de a lerta precoce quanto a possíveis atrasos. Além disso, eles ajudam
a tornar o progresso visível para os me1nbros e o patrocinador do projeto. Antes de
se atingir cada um dos marcos, realiza -se uma revisão deles no conjunto do projeto a
fim de comparar os resultados alcançados aos critérios detenninados pelos marcos. O
gerente de projeto é responsável por essa revisão.
O sucesso alcançado pela Ericsson em suas operações mundiais pode ser parcial-
mente atribuído à aceitação e à util ização do modelo PROPS. A Ericsson de1nonstr ou
que é possível atingir o sucesso mes1no com o mais simples dos modelos e sem o desen-
volvimento de políticas e proced imentos rígidos.
4.25 lndra: encerrando o projeto17

Encerrando o projeto
Em uma empresa tecnológica como a Indra, com projetos gerenciados para desenvol-
ver, 1nanufaturar e fazer a manutenção de co1nplexos sistemas de hardware e software,
o encerra1nento precoce de um projeto pode ser, se não bem t ratado, uma causa de
grandes perdas de eficiência. Os projetos normalmente exigem uma curva de esforço
com pico no início e no meio de seu ciclo de vida de projeto. Ver Figura 4-31. Ou, em
outras pa lavras, do ponto de vista do gerente de projetos, o planejamento e monitora-
mento e o cont role são as fases que exigem mais atenção.
Durante a etapa de planejamento, o gerente de projetos traba lha com o intuito
de atingir alvos claros. Ao mes1no tempo, o p lanejamento depende de comprom issos
17
€>2013 lndra. Reproduzido com permissão. Todos os direitos reservados. O material sobre a Indra foi for·
necido por Alfredo Vázquez Díaz, profissional de gestão de projetos (PM~) e dfreror do escritório de gestão
de projetos corporativos.
estabelecidos ou com o patrocinador ou com o cliente. Enquanto estiver nas fases de

monitoramento e cont role, a atenção do gerente de projetos é concentrada na coor-
denação dos esforços da equ ipe para alcançar os marcos do projeto, identificando
variâncias e linhas de base e protegendo o projeto de mudanças, o que realmente to1na
a maior parte do tempo.
Esse não é o caso no fim do projeto: quando os compromissos são cu1npridos, a
maior parte da pressão sobre o GP é liberada. Isso ocasionalmente faz co1n que o úl-
titno dos marcos (encerramento do projeto) não seja alcançado da 1naneira devida, já
que a atenção e esforço do GP diminuiu e é até mesmo possível que uma nova tarefa o
esteja esperando, e ele tenha sido liberado para começar a nova responsabi lidade sem
encerrar devidamente a anterior.
No contexto de uma organizaç.â o como a Indra, cujo principal negócio é entregar
resu ltados de projetos aos seus clientes, pretendemos organizar nossos recursos da
maneira ma is eficiente possível, respondendo a todos os compromissos com nossos
clientes em u1na estrutura de melhoria de negócios.
Realizar um botn encerramento pode ser um pequeno motivador e pode ser classi-
ficado pelos GPs como u1na tarefa simples e administ rativa. Portanto, pode-se esque-
cer que, se não prestarmos atenção ao encerramento, a oportunidade de consolidar o
rendimento que foi obtido no projeto, que toda a organ ização pode perder benefícios,
particularmente no gerenciamento de escopo e recursos (que, a propósito, são os prin-
cipa is valores usados no cálculo da produtividade). Se focalizarmo-nos no gerencia -
mento do escopo, se o encerramento do projeto não for bem feito, há um r isco de que
os acordos de aceitação dos deliverables tenda a ser di luído, reaberto ou reinterpreta-
do pelo cliente. Isso acontece se o final do projeto não for bem determinado e se for
confundido e 1nisturado com o período de garantia.
Deixe-1ne most rar isto: as necessidades do cl iente, após um novo siste1na ser im-
plantado, podem mudar, e isso pode fazer a interpretação dos requ isitos evoluir, per-
der rastreabi lidade com o escopo inicial do projeto e suas condições de va lidação
anteriores. A pessoa que rea liza a validação de requisitos dos deliverables no cliente
pode mudar sua percepção à medida que o tempo passa se1n um encerramento forma l.
Dessa forma, o cliente pode tentar rea locar novas necessidades ao projeto em vez de
colocá-las em uma extensão do projeto, como deveria ser.
É especialmente aconselhável prestar atenção especificamente aos esforços dedica-
dos à aceitaç.â o dos requisitos do cliente ao gerenciar u1n projeto baseado em 1nodelos
ágeis, que estão tão na moda hoje em dia. A constante d inâmica da microval idação
de entregas pode levar o problema de um encerramento de projeto mal executado a
dimensões praticamente int ratáveis.
Se foca liza nnos no gerenciamento de recursos, podem ocorrer vários obstáculos
organizaciona is, sendo o mais frequente deles evitar que recursos sejam liberados de
nossos projetos para outros. Acontece ta1nbém que recursos não liberados dim inue1n
a produtividade obtida durante o projeto. U1n outro efeito negativo é a fa lta de foco
metodológico durante um encerramento de projeto que não é devidamente executado,
se deixando levar pela reação a eventos e incidentes de mudanças. Essa abordage1n
não preventiva é co1no um cavalo de Troia no que d iz respeito às pre1nissas relativas a
mudanças, escopo, melhorias e responsabil idades que foram adequadamente negocia-
das pelo gerente de projetos durante out ras etapas do projeto, e que no encerra1nento
do projeto podem novamente ser colocadas em jogo.
Essa preocupação levou a Indra a aperfeiçoar as práticas de encerramento de pro-
jeto por meio da implementação do siste1na de informações da gestão de projetos
(SIGP) de um grupo de facil itadores:
1\)
U1
.I>,
G)
Etapa do pré-contrato Etapa do contrato (1)
!!l
•• •• ""e.
o
Fase 1 •• Fase 2 •• Fase 3 Fase 4 Fase 5 Fase 6 (1)
•• •• "O
•• ••
•• •• .2.
(1)
•• ••
••
••
••
••
g
• •
Iniciação Preparação
da proposla
• •••
••
Execução e
Planejamento monitoramento/controle
Apoio à
proposta
Encerramento
Esforço do GP ao longo do tempo (ciclo de vida da gestão de projetos da lndra)
Figura 4- 31 Ciclo de vida da gestão de projetos da lndra.

• Possibi lidade de início precoce das atividades de encerramento do projeto, por

meio da superposição dessa fase à anterior (p.ex.: em casos e1n que o escopo é
cortado ou em que há uma data de encerramento planejada)
• Usar as informações que o SIGP acumu lou com o projeto ao longo de sua vida
para ajudar a identificar situações que poderiam impedir o encerramento formal
• Ind icadores e relatórios associados ao encerramento do projeto, oferecendo ao
mesmo tempo o status do encerramento do projeto
• Lições aprend idas associadas umas às out ras, o que pennite uma busca em co-
nhecimentos adquiridos por meio de experiências anteriores; isso poderia afetar o
processo de encerramento (e outros)
O provérbio espanhol "feche a porta, [senão] o gato foge" mostra com clareza os
riscos que a organização enfrenta se o encerramento do projeto não for bem feito. Se
não fecharmos a porta (encerrarmos o projeto), o gato foge, ou, em out ras palavras,
riscos que eram cont rolados passam a ter chance de acontecer. Se o gerente de proje-
tos não rea lizar o encerramento do projeto co1n cu idado, ele pode estar ad icionando
ao 1nesmo grandes riscos que estavam sob cont role em fases anteriores, quando seus
esforços e atenção estavam altos.
4.26 Repsol: a metodologia GIP©da Repsol E&P -

o processo de gestão de qualidade
18
do projeto aplicado à tomada de decisões
A "Gestión Integrada de Proyectos" (GIPº ) é a metodologia integrada de gestão de
projetos na direção geral da Repsol Exploração e Produção (Repsol E&P). A GIPº se
baseia no conceito de pontos de decisão de final de fase.
A GIPº estabelece um conjunto de deliverables para cada uma das disciplinas en-
volvidas em um projeto de E&P; ao todo, há 330 deliverables a serem cobertos, segun-
do a apostila da Fase de Exploração do Projeto de Desenvolviinento. Cada derivable
é descrito em um "ca rtão", que inclui sua descrição e a melhor diret riz e exemplo de
sua classe. A GIPº está disponível a todos os funcionários por meio do GIP Space0 na
intranet da Repsol, por meio de u1n mapa interativo de deliverables.
A GIPº considera quatro fases (ver a Figura 4-32). As fases são, na verdade, qua-
tro projetos e1n sequência em que as fases do ciclo de vida do projeto do Guia PM-
BOK® do PMI se agrupam: iniciação; planejamento; execução; monitoração e contro-
le; e encerramento. No final de cada fase há um processo de encerramento e o início
da fase seguinte.
O principal deliverable da Fase de Visualização é uma lista de opções inte-
gradas de desenvovimento, viáveis tanto técn ica quanto economicamente. Essas
opções incluem perfis de produção e poços associados das insta lações. A Fase de
Visualização é un1 período de alta criatividade, en1 que todas as opções tecnica-
n1ente viáveis devem ser detectadas, para serem ana lisadas e priorizadas na fase
seguinte. A frase que define o esforço durante a Fase de Visua lização é " Quando
alguém impõe um limite àqui lo que irá fazer, impõe um lin1ite àqui lo que pode fa-
zer." (Charles M. Schwab)
11
©2013 by Repsol. Reproduzido com pennissão. Todos os direitos reservados. O material sobre a Repsol
foi fomecido por Jose !vlanuel Boccardo, execucivo de desenvolvimento técnico na Divisão de Gerenciamen~
to, Divisão de Gerenciamento Executivo da Repsol Exploração e Produção.
Um processo impulsionado por decisões baseadas em riscos: •Nem mais, nem menos, na hora certa".
Criação de vai MaterlaJIZa o de valor
Ponto de decisão 1
....
Ponto de decisão 2
....
Ponto de Encerramento do
decisão 3/flD (Final projeto e lições
•identificar uma oportunidade de negócio" lnvestment Declsion) aprendidas
Continuar/Não continuar
Seiec,onar e amadurecer o conceito ótimo
Completar escopo e plano de gesta.o de proieto I PGP)
Executar o plano de gerenciamento do pro1eto (PGP)
Gerenciamento HSE
Gestl o de riscos
Figura 4-32 O conceito GIP" .
Durante a Fase de Conceitua lização as opções de desenvolvimento previamente

detectadas são analisadas, e novas opções podem su rgir. Elas são, então, priorizadas e
apenas uma opção é selecionada. Uma vez selecionada, a opção é amadurecida até as
informações serem suficientes para produzir uma Estimativa de Custo Classe 4 segun-
do a AACEi. Essa é a fase em que o valor máximo pode ser captado em um projeto. A
frase que melhor define a filosofia por trás do esforço de conceitualização é "Vista-me
devagar, pois estou com pressa." (Napoleão Bonaparte)
Se a Fase de Conceitual ização é essencia l por ser o período e1n que o projeto capta
maior valor, a Fase de Definição também é essencial porque é a fase que estabelece o
escopo e a linha de base do projeto e na qual o Plano de Gestão de Projeto (PGP ou,
e1n inglês, PMP®, Proiect Management Plan) é concluído. Neste caso, a frase que defi-
ne a fi losofia por t rás das atividades de Definiç.ã o é "Dê-1ne seis horas para derrubar
u1na árvore e passarei as quat ro primeiras afiando o machado." (Abraham Lincoln)
A Fase de Execução inclui todas as atividades planejadas e incluídas no PGP. O
produto final da fase é a infraestrutura do projeto: poços, instalações, edifícios, etc. A
fase é concluída e encerrada quando a infraestrutu ra é entregue ao "cliente", que é o
Gerente de Ativos. Nesse caso, a frase que define as atividades é "O sucesso depende
do esforço." (Sófocles)
A GIPº gerencia os r iscos associados a incertezas ao longo do ciclo de vida do
projeto, administrando compro1nissos e despesas. Essas incertezas podem estar rela-
cionadas à maturidade da 1nodelagem dos reservatórios, perfurações e escopo das ins-
talações, ent re outros. O nível de incerteza por meio do ciclo de vida de um projeto
pode ser visualizado encontrando uma equiva lência que associa a Classe de Estimativa
de Custo do Projeto de Desenvolvi1nento à classe da AACEi em cada fase. Ver Figura
4-33. Esses níveis de incerteza dependem do escopo das opções de desenvolvimento
para desenvolver um reservatório específico de petróleo bruto ou gás. Essas incertezas
nas estimativas de custo não cobrem as incertezas associadas ao conhecimento sobre
o reservatório, que deverá ser aval iado e considerado na configuração e projetos das
instalações de superfície e nos poços.
Assim co1no a maioria das metodologias de pontos de decisão de fina l de fase,

a GIPº estabelece quatro possíveis decisões em cada ponto de decisão. (Ver Figura
4- 34). Os resultados possíveis das decisões são:
• Continuar para a fase seguinte
• Voltar no ciclo pelo fato de o nível de incerteza ser alto dema is para o próximo
compromisso e serem necessárias 1nais anál ises, modelagem, engenharia, etc.
• Cancelar
• "Arquivar" até as condições favorecerem o desenvolvimento do projeto
As decisões em cada ponto de decisão são tomadas por comitês de guardiões do
ponto de decisão que irão endossar ou aprovar compro1nissos e fundos de acordo co1n
seus níveis de delegação na empresa. Cada ponto de decisão é alimentado pela Revisão
Técnica real izada por uma equipe de especialistas mu ltidiscipl inar e integrada, na qual
todas as discipl inas de E&P são representadas. Essa equ ipe integrada revisa todos os
deliverables desenvolvidos durante a fase avaliada de acordo com o 1napa no GIP Spa-
ce0. Especia listas de outras áreas, como a Fiscal e Jurídica, também avalia1n o projeto.
A avaliação é disponibil izada para os guardiões do ponto de decisão em um documen-
to e apresentação integrados cha1nado de Documento de Suporte a Decisões ou DSD.
As Revisões Técnicas feitas no final de cada fase são, na verdade, eventos de Con-
trole de Qual idade, nos quais o nível de maturidade e completude dos principais deli-
verables são verificados, e os desvios, identificados. Ver Figura 4- 35.
No início de um projeto, oficialmente após o Ponto de decisão 1, estabelece-se
um Mapa de Eventos de Qualidade com o qual o gerente de projeto e o escritório de
gestão de projetos de E&P deve1n concordar mutuamente. Esse mapa é incorporado
ao Plano de Qualidade do Projeto e seus marcos são integrados ao Cronograma Mes-
tre do Projeto. O Mapa de Eventos de Qualidade I identifica os marcos de Controle
de Qualidade associados à tomada de decisões e também aos eventos de Garantia da
Qualidade.
O Mapa de Eventos de Qua lidade é específico para cada projeto, o que sign ifica
que dependerá do nível de investimento, complexidade, exposição da empresa ou de
alguma combinação desses fatores. Esse Mapa de Eventos de Qual idade inclui os even-
tos de Ga rantia da Qualidade que geram a convicção de que os eventos de Cont role de
Qualidade serão be1n-sucedidos.
A Qualidade na Repsol E&P pode ser representada por uma pirâmide de quatr o
andares ou níveis. O primeiro nível corresponde a empresas contratadas e fornecedo-
res; o segundo, às equipes de projeto; o terceiro, à tomada de decisões; e o quarto, às
políticas e normas corporativas. (Ver Figura 4- 36.)
Para 1nelhor compreender a filosofia por t rás dessa pirâmide, é importante consi-
derar que e1n um Projeto de Exploração e Produção, a 1na ioria das atividades é con-
tratada, e bens são sempre fornecidas por tercei ros. As equipes de projeto literalmente
planejam e supervisionam o traba lho executado por out ros .
As empresas cont ratadas e os fornecedores executam o p rocesso de qua lidade
para garantir que os serviços e bens sejam entregues de acordo com os requisitos con-
tratados.
No nível da equipe de projeto, a execução do processo de qualidade é menos in-
tensa e exige menos recursos do que as atividades de qua lidade realizada por empresas
contratadas e fornecedores. As atividades de Garantia da Qualidade têtn como obje-
tivo oferecer a confiança de que as e1npresas cont ratadas e os fornecedores esteja1n
seguindo ou usando as especificações e procedimentos acordados, usando os perfis de
pessoal adequados, etc., e que irão ent regar serviços e bens que estão de acordo com os
requisitos oferecidos. Exemplos disso são inspeções durante a fabricação e a auditoria
40
--
o~
o
....- 20
""
,1/l
u
e ,,
..,
....
o
'l3.
·;:: o
>
- 20
Classe 5 Classe 4 Classe 3 Classe 2 Classe 1

Factoring de Factoring de Custo unitário Custo unitário detalhado Custo unitário
capacidade, modelos equipamentos semidetalhado com 13ke-off detalhado
paramétricos, ou modelos com itens de linha detalhado com take-ott
julgamento ou analogia paramétricos no nível de montagem forçado detalhado
Classificação da estimativa de custo
Figura 4-33 Precisão da estimativa de custos de acordo com as fases da GIP" .
Um processo Impulsionado por decisões baseadas em riscos: "Nem mais. nem meno'!., na hora certa"
Criação de valor Materialização de valor
......
Ponto de decisão t
......
Ponto de decisão 2
......
Ponto de Encerramento
decisão 3/DFt do projeto e
Continuar/Não continuar lições aprendidas
• • •
2:
Voltar no ciclo
.ar.a.:'
. Voltar no cicto2: •
'Jt.. continuar
2:
Voltar no ciclo
.,,.a.:'
.
! '-... :a:~..
.ar.a.:''1;_,contlnuar
:a: ~ ..
'1;_,continuar
Figura 4-34
-
Cancelar/Arquivar
Pontos de decisão da GIPº .

-
Cancelar/Arquivar -
Cancelar/Arquivar
GerenclamenlO da qualldade t6cnlca
Planejar Garantir Co1trolar
Plano de qualidade RevlsnesJAuxíllos de colegas Revlsnes técnicas
, ,
,
,,
-·.
,
,,
, --,
,
'•
,', ,,' •
,, ' '
•'
&'
,:,
, ,
~ -
Projeto
Criação de valor
,
,
,',
,
, ,,
,,'
,Mata ri ai ização da valor :

•'
'•
'
. .s::
õ
,,' , '•
,, '
(D
g_
VISUALIZAÇÃO CJIIICÉITUAl.11AÇÃO o
ldentWicar uma
oportunidade de negócio
S1llclo1w I amadurecer
o COIClbO 611mo
.,
~.
<J>
a.
Â Â Â ..... (D
(O
.-o,,
(D
Ponto de decisão 1 Ponto de decisão 2 Ponto de decisão 3/DFI Encerramento <J>
(Decisão Final de lnveS11mento) a entrega do
Continuar/Não continuar projeto a.
(D
"O
EncerramenlO e entrega do projelO .2.
~
<J>
Figura 4- 35 GIF>° e o processo de qualidade para a tomada de decisões.
~
(D
Políticas
---i[ Nível O: corporativo J
e normas
Gerenciamento
- ---< Nível 1: tomada de decisões
da qualidade (operadora e seus parceiros)
técnica
Garantia da qualidade
Planeja- Nível 2: projeto
mento da :-- --- --- --- --- --- --- --
qualidade : Controle de qualidade
--i (equipe do projeto)
do projeto :
'
Garantia da qualidade
Planejamento Nível 3: empresas
da qualidade - contratadas/fornecedores
do projeto Controle de qualidade
Figura 4-36 A pirâmide da qualidade da GIF"".
de produtos de engenha ria durante o seu desenvolvimento. As atividades de Cont role

de Qua lidade estão associadas a determina r se os produtos entregues serão aceitos ou
rejeitados.
Durante a p reparação do plano de Qualidade do Projeto, a equ ipe de projeto es-
tabelece os requisitos dos deliverables, avalia a criticalidade de cada área do projeto e
de seus deliverables, seus respectivos contratos, materiais e equipamentos e estabelece
o número, a data e a profundidade das auditorias e inspeções associadas tanto à Ga-
rantia quanto ao Controle da Qualidade.
O terceiro nível da pirâ1nide corresponde à qual idade associada ao que é repassado
aos tomadores de decisões ou guardiões dos pontos de decisão. Os "principais cl ientes"
dos resultados do Processo de Qua lidade do terceiro nível são os guard iões dos pontos
de decisão, que usarão os resultados das Revisões Técnicas para aval iar o va lor do
projeto e seus riscos o ponto de decisão; e, então, decidirão se irão ou não prosseguir à
fase seguinte. (Ver Figura 4- 37.) O outro cliente que é beneficiado co1n o Processo de
Qualidade do terceiro nível é a equipe do projeto, pois os eventos de qualidade detec-
tarão desvios que, un1a vez corrigidos, garantirão ou au1nentarão o va lor do projeto. É
importante con1preender que o Processo de Qualidade do terceiro nível não substitui o
Processo de Qua lidade no nível das Equipes de Projeto, mas si1n o con1plen1enta.
A GIPº pennite uma flexibi lidade controlada no processo de tomada de decisões.
Por exemplo, e1n certos casos, to1nar decisões finais de investi1nento (DFI, FIDs) antes
do ponto de decisão 3 possui seus benefícios. Isso significa que certas partes do projeto
podem não estar suficientemente maduras para oferecerem u1na Estimativa de Custo
Classe 2 de acordo com a AACEi. (Ver Figura 4- 38).
Nesse caso, realiza-se uma análise para avaliar os riscos produzidos pelas incerte-
zas associadas à baixa maturidade, e então p laneja-se e, às vezes, toma1n -se providên-
cias imed iatas em resposta. A proba bilidade e os i1npactos residuais refletem-se nas
p rincipais variáveis do projeto e são considerados em sua análise de valor.
- Defini ção + Definição
+ Incerteza - Incerteza
VISUALIZAÇÃO
Estimação de custo
Classe 5
Â
Â Â E.nce,ramento
Ponto de deci são 1 Ponto de deci são 2 Ponto de decisão 3 e entrega
••·- ·- ·-
À
'
' ....
DA Continuar/
Não continuar
............................
• • • • • • -~
do projeto
&'
,:,
.. .. .. ~ -
'
~~~-~,:.:. .. -.. -
.s::
õ
(D
Alinhamento do negócio g_
• o
~
.,.
Relatório de revisão técnica <J>
a.
(D
(O
.-o,,
(D
Resultados da avaliação de risco <J>
Controle de Quali dade Pontos de decisão
(RT1 , RT2, RT3) 1, 2, 3
a.
(D
Resullados da análise
"O
técnica/económica (VPN~RR)
.2.
~
<J>
0
Figur a 4- 37 Modelo GIP e o processo de tomada de decisões.
...
N
a,
1\)
a,
1\)
- Definição + Defini ção

G)
(1)
!!l
""e.
o
+Incerteza • Incerteza (1)
"O
.2.
VISUALIZAÇÃO (1)
g
Estimação de custo
Classe 5
.... .... ...

...
Entrega
Ponto de decisão 1 Ponto de decisão 2 Ponto de deci são 3 do proj elo
FI D Continuar/ DFI Continuar/ encerrado
Não continuar
• ##
....____ #
Não continuar
_____________ _
... ••• • • • -~
---· -------
....... ~--------
...
Alinhamento do negócio Voltar ao ciclo
Relatório de revisão técnica

Continuar
Resultados da avaliação de risco

Controle de Qualidade Pontos de decisão
(Revi sões técnicas) 1, 2, 3 cancelar/Arquivar
Resultados da análise técnlca/econllmlca
(VPN/IRR)
Figura 4- 38 Flexibilidade da GIP0 no processo de tomada de decisões.

Quando a Equipe do Projeto e o patrocinador do projeto detectam uma oportu-

nidade a ser explorada ao tomar uma decisão em uma fase anterior com um projeto
de ba ixa maturidade, co1no visto na Figura 4- 39, os resu ltados da análise de risco são
discutidos na Revisão Técnica, e ações de resposta são confirmadas. Durante a Revisão
Técnica, riscos adicionais podem ser detectados, e ações de resposta podem ser esta-
belecidas e incorporadas ao PGP. O Docu1nento de Suporte a Decisões é enviado aos
guard iões do ponto de decisão para aprovação após o endosso da equipe de especia lis-
tas 1nu ltidisciplinar integrada. (Ver Figura 4-40 ).
Posltívos: Negativos:
• Identificar oportunidades mais cedo • Incertezas técnicas ao especificar
• Cumprir os compromissos equipamentos e materiais
contratuais • Alta probabilidade de retrabalho
• Identificar o mercado de venda • Possível alto nível de incerteza ao
• Acelerar a contratação e as desenvolver estimativas de custos
aquisições para garantir os prazos e cronograma
do projeto (cronograma)
• Acelerar receitas
Efeitos positivos
l(' n· • Incertezas quanto ao valor do projeto
Possível fracasso do projeto
Ações em resposta
;::i.: Efeitos negativos
Figura 4-39 GIPº tomando decisões com informações de projetos com baixa maturidade.
ProJeto
Oportunidades, Incorporação Apresentação aos
Incertezas e análise . Açl!es em resposta ao PGPde novas guardll!es de pontos
de riscos açl!es de resposta de decisão
• Técnicas (especlflcaçl!es, pesquisa,
produção, etc.)
• Jurfdlcas
• Fiscais
• Polltlcas
• Contextuais
• Estimativas de custos e cronograma
• Plano de proJeto
• Análise de valor
--------------------· ---------- - - - -- --
Equipe de especlallstas multldlsclpllnar
Integrada
Revlsl!es técnicas Revisar e endossar
Guardiões dos pontos de decisão
(~Aprov
--ação ~ J
Figura 4-40 Processo da GIPº para tomada de decisões com informações de projetos com baixa
maturidade.
4.27 Rockwell Automation: em busca de um

19
processo comum
A Rockwell Automation foi formada por meio da un ião de duas grandes empresas de
auto 1nação no final da década de 1980. Essas duas empresas, Allen -Bradley e Relia nce
Electric, fora 1n a base do que hoje é a Rock,vell Automation. Ao longos dos anos, a
Rock,vell Automation continuou a adquirir fornecedores líderes no ramo da automa-
ção como uma estratégia de crescimento e ta1nbém como u1na maneira de trazer novas
e avançadas tecnologias de automação para a empresa. Em 2005, quando a Rockv,ell
Automation estava planejando a implantação de um novo sistema de negócios da SAP,
reconhecemos a necessidade de um novo processo "comum" de desenvolvimento de
produtos que seria definido de acordo com as melhores práticas da empresa so1nadas
ao que era1n consideradas as melhores práticas do setor e1n termos de desenvolvi-
mento de produtos. Esse esforço resu ltou em um processo de " desenvolvimento de
produtos comum" (DPC ou, em inglês, CPD, common product development) que foi
definido de forma a possibilitar que ele fosse adotado por toda a empresa. Ver Figura
4-41. Isso significa que 16 diferentes negócios de produtos, de fornecedores de com-
ponentes de alto volume a fornecedores de soluções de siste1nas de controle de proces-
sos contínuos e complexos, usariam o mesmo modelo de processo de a lto nível para o
desenvolvimento de seus novos produtos.
O processo resultante é composto por seis fases com uma revisão de passagem de
fase após cada u1na delas. As seis fases são:
Consideração
• Desenvolver um caso de negócio e proposta de projeto de alto nível para justi-
ficar o financia 1nento SAI para a execução das atividades das fases de iniciação
e viabilidade.
Iniciação
• Refinar o documento de caso de negócio (DCN) de a lto nível criado na fase
de consideração, transformando-o em u1n conjunto de requ isitos do cliente
suficiente para a equipe de projeto criar conceitos de soluções, requisitos de
produtos e documentos de requisitos funcionais na fase de viabilidade. (Ver Fi-
gura 4-42.)
Viabilidade
• Ava liar conceitos de soluções pa ra abordar os requ isitos do cl iente da fase de
1111c1aç.ao.
• Definir os requisitos de produto e os requisitos funcionais.
• Completar todo o p lanejamento do projeto e a geração do cronograma para
atualizar o plano de projeto, incluindo todas as atividades e recursos necessários
para concluir as fases de execuç.ã o, liberação e encerramento do projeto.
• Desenvolver um DCN que justifique o investimento necessário pa ra executar o
plano de projeto do conceito de solução escolhido. (Ver Figur a 4-43.)
19 1
E..çca seç.ão sobre a Rockwell Aucomarion foi fornecida por James C. Brown, PgMP, PNLP \ OP.M.3 AC,
tvlPNL, CIPM, CSP, CSS!vlBB, antigo diretor do escritório de gerenciamento de programas empresariais da
A&S; Karen \-Xfojala, gerente de planejamenro de negócios; e X1acr Sribora, gerente de empreendimemos
enxutos.
• Oprocesso de OPC Inclui: EVENTOS DE FINANCIAMENTO

•SA1 , SA2 = SOLICITAÇÕES OE APROPRIAÇÃO
- Seis fases l PARA AS FASES
- Seis grandes revisões de marcos .à •TECO = TECNICAMENTE COMPLETO
•PENC = PROJETO ENCERRADO
- Quatro eventos de financiamento O EVENTOS DE ENTRADA DE PEDIDOS
- Oois eventos de entrada de pedidos O
•AEP = ABERTO PARA ENTRADA OE PEDIDO
•OC = DISPONÍVEL PARA OCLIENTE
- -- --
1 l
oeee
LIBERAÇÃO l ENCERRAMENTO l
A A. '1. A
Figura 4-41 Processo de DPC: conceitos fundamentais.
Prlnclpals entradas Principais def/verabtes (amostra)

• Caso de negócio de alto nível Finalidade: refinar • Documento de requisitos do
• Avaliação de alto nível de a OtJOrlllnldade cliente (DRC)
riscos e capacidades Identificada na lase • Plano e cronograma do projeto
• Estrutura documental inicial de CONSIDERAÇÃO atualizados
do projeto por melo da criação • Materiais de revisão de marcos
• Plano e cronograma iniciais do projeto de um documento • Recomendações para a decisão
• Designação do gerentede de requisitos do de Continuar/Não contínuarNoltar
projeto Inicial cliente (DRC) ,a,.as (eniranas para a rase de
• Aprovação do financiamento SA1 VIABILIDADE caso se decida
~
"Continuar")
• Requisitos do cliente de
Principais atividades (amostra) referência
• Voz do cliente (VDC. voice oi custome,j • Plano e cronograma do
projeto atualizados
• Pontos fortes, fracos, oportunidades e
ameaças (análise SWOT)
• Avaliar oportunidades de propriedade Intelectual (PI)
(S • Atualizar plano de projeto (documento em Word e

MS Project Schedule) (definir escopo, cronograma J)
~
e recursos)
• Preparar-se para a Revisão de Marcos 1
Figura 4-42 Resumo da fase de iniciação.

Finalidade: gerar os requisitos

Principais entradas dos produtos, os requisitos
• Plano e cronograma iniciais luncionais o plano e o
cronograma do projeto Principais delirerables (amostra)
do projeto
e o caso de negócio e criar • Documento de Requisitos de Produtos (ORP)
• Requisitos do cltente de
referência (ORC) uma linha de base para eles • Especificações dos Requerimentos
a fim de garantir o Funcionais (ERP)
• Marco 1 - Decisão de
linanciamento pelo restante • Revisões de segurança do produto e inovação
''Conlinuar"
do projeto e prosseguir para • Planos de produção e qualKlade
a fase de EXECUÇÃO. • Documento do caso de negócio
Principais atividades
' - - - - - - - - ~ - - 1 • Plano final do projeto
(amostra) • Marco 2 - Materiais de revisão
• Benchmarking competitivo • Recomeoclação para decisões de
• Identificar e avaliar conceitos de soluções ~continua~r Não continua~f Voltar"
• Criar o Documento de Requisitos de Produtos (ORP}
• Criar as Especificações dos Requerimentos
Funcionais (ERP) Saídas (entradas na fase de EXECUÇÃO
• Revisões de segurança do produto e inovação caso se decida ''Continuar")
• Plano de produção de referência • Plano de projeto
• Plano comercial de referência • Documento de caso de negócio (inclui
• Plano de projeto de referência e cronograma o retomo sobre o investimento- ROi)
detalhado de referência • ERF
• Documento de referência do caso de negócio • SA2 Financiamento para o desenvolvimento
• Planejamento de qualidade/certificação
• Preparar para Revisão de Marcos 2
'---"I • Preparar e enviar Solicitação de Apropriação
para SA2
Figura 4-43 Resumo da fase de viabilidade.
Execução
• Desenvolver o p roduto o u serviço de acordo cotn as especificações dos requi·
sitos funciona is (ERF) de referência que fo ram feitas na fase de viabi lidade;
rea liza r as revisões necessá rias; fazer 1nuda nças aprovadas nos requisitos e/ou
design à med ida que o projeto progr ide.
Liberação
• Fi nalizar todos os testes, certificação e o utras documentações de verificação de
produtos.
• Montar e valida r a produção piloto.
• Abr ir para entrada de pedidos e executar o lança mento cotnercial.
Encerramento
• Posicionar o produto pa ra transição pa ra engenharia de continuaç.ã o/ma nuten·
ção; "faxina" da docutnentação, post mortems, lições aprend idas e retenção de
registros, e completar roda as tra nsações financeiras.
Nosso objetivo era atingir un1 modelo rápido e repetível, que consistentemente
resultasse en1 sa ídas de alta qual idade. Um grande objetivo da equipe que produzi u
esse novo processo era levar os negócios de produtos a serem mais disciplinados no
modo de abraçar a inovação ao decidir quais propostas de projetos serian1 fina ncia-
das e quais não seria m. Havia, também, n1uitos exemplos de projetos que recebi an1
apo io e fi na nciamento da gerência sem atender a un1 conjunto de critérios mínin1os
que resulta riam em un1a probabi lidade mais alta de sucesso con1ercial. As propostas
de investimento nem sen1pre eram baseadas en1 um processo de ideação conduzido

por nossos clientes.
Encontra tnos exemplos de projetos financiados que desfrutava tn de apoio e fi-
nanciamento sem nenhuma base comercial conduzida pelo cliente. A justificativa para
esses projetos baseava-se etn novas tecnologias interessantes, investindo em cobertura
de uma famíl ia de produtos pela mera cobertura, setn uma verdadeira demanda de
mercado, provendo soluções de nicho com um potencial limitado conduzidas por utn
único cliente, etc.
Para solucionar esse problema, o foco original da equipe foi colocado etn dois as-
pectos do que era definido co1no uma melhor prática. Há inúmeras teorias que tenta tn
descrever a melhor maneira de captar as necessidades do cl iente e usá-las como a base
para criar conceitos eficientes de novos produtos. Nosso objetivo era compreender os
problemas do cliente antes de produzirmos conceitos de soluções e soluções de produ-
tos. Atingimos esse objetivo decompondo uma ferramenta existente, cha,nada de pro-
cesso e Documento de Requisitos de Marketing (DRM) e usada pelo Gerencia tnento
de Produtos, em duas ferramentas.
Queríamos que os proprietários de produtos cotnpreendessem o mercado e os
problemas do cliente antes de consideraretn soluções. Ao decompormos o DRM em
dois deliverables, o pri tneiro (Documento de Requisitos do Cliente) passou a se foca-
lizar na necessidade do mercado e nos problemas do cl iente, e o segundo (Docu1nento
de Requisitos do Produto ) passou a se focalizar nos conceitos de soluç.ã o e nos requi-
sitos dos produtos e, ao localizar essas ferramentas e atividades em fases separadas
divididas por uma revisão de passagem de fase, forçamos nossos gerentes de produtos
a se distanciarem da "marcha morta l de fazer o produto evoluir continuamente" etn
que nos encontrávamos.
É claro, as práticas aceitas e a cu ltura da empresa são difíceis de 1nudar, então a
governança é crucia l ao conduzir mudanças. Esse passo si tnples é o começo do que
será u1na melhoria significativa nas práticas de desenvolvimento de novos produtos
dessa empresa.
A força motriz por trás do compromisso da empresa em implementar esse novo
processo e etn conduzir a mudança cultural era a visão de uma metodologia consis-
tente e comum a toda a empresa para o desenvolvimento de novos produtos. Essa
consistência foi priorizada do alto da organização (envolvi1nento direto da gerência
nas revisões de passagem de fase) para baixo, a fim de realizar benefícios o mais rápi-
do possível.
Muito frequentemente, as empresas eram forçadas a negar financiamento para
projetos estratégicos devido às intermináveis melhorias incretnentais dos produtos,
que continuavam sendo feitas. Ao forçar a gerência da empresa a aprovar a passagetn
de cada projeto de u1na fase à seguinte, levamos a visibilidade de cada projeto, cada
recurso e cada dólar até os tomadores de decisão que lutavam tentando encontrar
dólares para financiar projetos que eram verdadeiras oportunidades de "virar o jogo".
Essa visibil idade facilitava para os proprietários da empresa cancelarem projetos cotn
retornos questionáveis, ou adiarem um projeto a fim de liberar recursos cruciais, Utna
vez que a gerência começou a ver os retornos obidos a partir dessas decisões na fonna
de introduções de produtos que realmente fazetn a d iferença, começamos a nos foca li-
zar no refinamento do processo e metodologias empregadas. (Ver Figura 4-44.)
A revisão de passagem de fase é o evento mais importante de um projeto. Ante-
riormente, sob a antiga forma de se executar um projeto, essas revisões eram infor-
mais e fortuitas. As equipes podiam continuar gastando ou até 1nesmo desperdiçando
sem nenhum medo real de cancelamento de seu projeto. Esse novo processo garante
Voltar
Revisão Decisão CONTINUAR

Lista de verificação do marco Presença
Recomendação da equipe Teste de Desenvolvimento
de Negócio, TDN (baseado
no tipo de projeto,
tamanho, etc.) NÃO CONTINUAR
Figura 4-44 O processo de tomada de decisões.
que cada organização dependente seja representada na revisão apropriada e tenha a

chance de concordar ou discorda r com o gerente do projeto sobre a d isponibi lidade
de todos os deliverables. A intenção é que a decisão de "Continua r"/"Não continua r"
seja tomada tanto pela organ ização principal responsável pelos deliverables durante a
fase anterior quanto pela responsável na fase subsequente. Ambas as o rganizações são
necessárias em cada revisão de passagem de fase. Se isso for feito corrretamente, ao
garantir a transparência durante as fases inicia is, seremos capazes de evitar surpresas
durante as fases posteriores.
Uma vez que um gerente de projeto ten ha sido designado e un1a equ ipe de proje-
to tenha sido for mada, a in1portância de deliverables bem definidos que sejam fáceis
de localiza r e uti lizar se tornou evidente . Os 12 n1eses segu intes ao lançamento ori-
ginal do novo p rocesso foram passados mel ho rando continuan1ente as definições de
fase, os documentos de procedimentos, os te1nplates dos deliverables, e as políticas
de governança. Os limites ent re rigor e fardo são muito tênues; o truque é reforçar
esses limites para garantir un1a implementação rigorosa sem tornar lento o progresso
da equipe de pro jeto.
No final da fase de viabilidade, quando se entra na fase de execução com a garan-
tia do financiamento requisitado, o plano de projeto passa a ser a "Bíblia" da equipe.
O plano de projeto orienta todas as atividades da fase de execução, da fase de libera-
ção e finalmente, da fase de encerra1nento do projeto. Qua lquer problema que a equi-
pe de projeto enfrente que exija uma mudança de percurso deve ser reconhecida em
u1n plano de projeto atualizado. Na conclusão do projeto, o plano precisa representar
o que rea lmente aconteceu.
Antes de qualquer novo p roduto ser liberado pa ra ser enviado ao cliente, todas as
partes interessadas afetadas têm de estar de acordo quanto ao p roduto estar pronto
antes de dar a aprovação final.
Há uma dimensão da introdução de um processo end-to-end que foi suposta, mas
que precisa ser mencionada. A empresa é formada por negócios de produtos relacio-
nados, mas muito diferentes. Cada seg1nento de negócio estava em um nível de matu-
ridade diferente em relação a todos os aspectos do desenvolvimento de produtos, até
mesmo quanto à existência de uma organ ização formal de gestão de projetos.
Os gerentes de p ro jeto são essenciais na execução de um processo de desenvolvi-
mento de produto. Se consistência, transparência e mitigação de riscos são importan-
tes para um negócio, e o são para a Rockwell Automation, então uma entidade formal
e betn reconhecida e administrada de gestão de projetos é de suma importância.
A Rockwell Automation está buscando a disciplina da gestão de projetos em to-
dos os níveis de sua o rganização.
4.28 Sherwin-Williams
Há várias fo nnas de uma empresa desenvolver uma metodologia de gestão de proje-
tos. A terceirização do processo de desenvolvimento pode ser proveitosa. Algumas em-
presas possuem 1netodologias padronizadas (templates) que podetn ser usadas como
base para o desenvolvimento de sua própria metodologia. Isso pode ser vantajoso
se a metodologia de modelos tiver flexibilidade suficiente para ser adaptada à sua
organização. Por outro lado, essa abordagem pode apresentar a desvantagem de o
resultado final não se adequar às necessidades de sua organização ou à cultura de sua
empresa. A cont ratação de consultores externos pode melhorar u1n pouco a situação,
mas os resultados finais ainda podem ser igualmente desfavoráveis, bem co1no mais
dispendiosos. Essa abordagem pode exigir a pennanência de terceiros e1n sua folha de
pagamento por um longo período, de forma que possam compreender completamente
a sua cultura e seu jeito de fazer negócios.
A comparação do desempenho co1n o de outras empresas, ou bench,narking, pode
ser eficiente, mas, até esse processo estar concluído, a empresa teria tempo de começar
a desenvolver sua própria metodologia. Um out ro problema cotn esse tipo de cotnpa-
ração é que podemos não ser capazes de obter todas as informações de que necessita-
mos ou as infonnações de apoio para fazer com que a metodologia funcione.
As empresas que desenvolvem sua própria metodologia intema1nente parecem ter
mais sucesso, especialmente se incorporam suas próprias melhores práticas e lições
aprend idas a partir de outras atividades. Isso ocorreu na 1na ioria das empresas descri-
tas neste livro.
As infonnações abaixo foram fornecidas pela Sherwin-Williams Company.
Histórico da empresa
A Shenvin-Will ia1ns Company trabalha com o desenvolvimento, produção, dist ribui-
ção e venda de tintas, revestimentos e produtos afins para clientes de nível profis-
siona l, industrial, co1nercial e de varejo, nas Américas do Norte e do Sul, no Reino
Unido, Europa, China e Índia. A empresa opera em quatro segmentos: lojas de tintas,
consum idor, América Latina e acabamentos globa is. O seg1nento de lojas de tintas
vende tintas, revestimentos e produtos relacionados a clientes que são usuários finais.
Esse segmento comercializa e vende tintas e revestimentos arquitetônicos, produtos
para uso no setor industrial e marinho além de acabamentos e itens relacionados a fa-
bricantes de equipamentos originais. Em 31 de deze1nbro de 2008, operava 3.346 lojas
de tintas. O segmento do consum idor desenvolve, produz e dist ribui uma variedade
de tintas, revestimentos e produtos afins para terceiros e para o segmento de lojas de
tintas. Os segmentos da América Latina e de acabamentos globais desenvolvem, licen-
ciam, produzem, dist ribuem e vendem tintas e revestimentos arquitetônicos, produtos
industriais e marinhos, acabamentos automotivos e produtos para repintura, além de
revestimentos e produtos afins para fabricantes de equipa tnentos origina is. Esses seg-
mentos ta1nbém licenciam certas tecnologias e patentes além de d istribuíre1n os pro-
dutos da marca Shenvin-Will iams por 1neio de uma rede de 541 filiais operadas pela
empresa, dirigirem as equipes de venda e enviaretn representantes de vendas externos
a varejistas, negociantes, empreiteiros, licenciadas e outras distribu idoras terceirizadas.
A empresa foi fundada em 1866 e está sed iada em Cleveland, Ohio.
O departamento de Tecnologia da Informação (TI) corporativa da Sherwin-\Villiams
Company presta serviços compa rtilhados de suporte às três divisões operacionais que
formam a organização, co1no descrito acima .
Histórico do estudo de caso

Durante o verão de 2002, o departan1ento corporativo de TI dedicaram -se a ativi-
dades que envolviam a conversão de serviços de telecomunicações internaciona is,
interestaduais, estaduais e locais, que passarian1 de um provedor de telecon1t1nica-
ções para un1 outro. Melhores práticas e d iscipl inas de gestão de projetos, usando
uma metodologia estruturada, foram utilizadas nesse projeto, levando a um resultado
bem-sucedido.
O projeto foi i1nple1nentado com o uso de uma abordagem de fases, sendo as
principais descritas a seguir. As fases foram estabelecidas de tnodo a incluir mu itos
dos princípios existentes no Gttia PJ\1BOK® e tambétn incluíam várias das tnelhores
práticas que haviam sido desenvolvidas anteriormente na Shenvin-Willia tns Company.
As fases poderia tn se sobrepor, se necessário, perm itindo uma evolução gradual de
utna para out ra. A superposição ta tnbém perm itia acelerar os cronogramas, se fosse
preciso, mas possivelmente trazendo algum risco adicional. Real izavam-se revisões de
projetos ao final de cada fase para determinar a possibi lidade de passagem para a pró-
x ima, para decidir se os projetos deveriatn continuar ou não, para avaliar os riscos do
momento e os riscos futuros e para determinar se ajustes de rota seriam necessários.
• Iniciação : A primeira fase é a de Iniciação, etn que a equ ipe de projeto é formada,
uma reun ião inaugural é realizada, as necessidades e exigências são identificadas e
as funções e responsabi lidades são defin idas.
• Planeiamento: A fase de Planejamento é vista, pela maioria dos gerentes de pro-
jetos, como a mais importante. A tnaior parte do etnpenho para a rea lização do
projeto concentra-se no Planejamento, e se acred ita que o tempo e o esforço ade-
quados investidos nessa fase garantam o desenvolvimento de uma sólida funda-
mentação para o projeto. A gerência apoia integralmente os esforços realizados
nessa fase, pois é onde mu itas de nossas melhores práticas foram desenvolvidas.
Além disso, um forte alicerce nesse tnomento perm ite que as fases restantes do
projeto sejam realizadas com maior eficiência, proporcionando à gerência sênior
um maior grau de confiança na habilidade de nossos gerentes de projetos para
produzir os resultados desejados e atingir as expectativas dos cl ientes.
Normalmente, d iversas reuniões são realizadas no Planejamento para identificar,
no nível mais básico, as necessidades, requisitos, expectativas, processos e atividades/
passos para os processos do projeto. Os resultados dessas reuniões são vários, in-
cluindo utn documento de necessidades e exigências, um plano do projeto, um plano
de gestão de riscos, um registro de problemas e uma lista de providências a serem
tomadas. Entre os documentos adiciona is, estão os planos de gestão de mudança e de
gerenciamento de qual idade. Ta is documentos, em conjunto, dão à admin istração um
panorama de todo o projeto e do empenho necessário para se atingir a meta da trans-
ferência de serviços na data-alvo estabelecida.
• Execução: A terceira fase na itnplementação é a Execução. Ela evolui gradua l-
mente, assim que a maior parte do Planeja tnento está concluída. Todas as ativida-
des del ineadas nos processos durante a fase anterior tomam-se úteis nesse momen-
to, à medida que começam a ocorrer solicitações reais de linhas de comunicação e
a instalação de equ ipa tnentos, quando necessário. Os serviços passam por utn pro-
cesso de t ransição empreendido por Divisão/Segmento, e a implementação avança
rapidamente para o projeto devido às restrições impostas pelo cronogra tna. É de
vita l importância que as atividades nessa fase sejam monitoradas de perto a fim de
facilitar a identificação proativa de proble1nas que possam ter impacto negativo

na linha de tempo, nos custos, na qualidade ou nos recu rsos do projeto.
Para facilitar o moni toramento e o controle do projeto, reuniões semanais são
realizadas com o vendedor e a equipe de projetos, bem como pequenas reuniões diá-
rias para revisão das atividades planejadas para cada dia. Reuniões ad hoc també1n
' .
ocorrem, se necessa n o.
• Encerra,nento: A fase final do projeto é o Encerra1nento. Nela, gerahnente há uma
reunião de encerramento para identificar quaisquer questões re1nanescentes e para
determinar o nível da satisfação do cliente. Essa fase incluiu a "faxina» do projeto,
o encerramento administ rativo, a co1nun icação de procediinentos de apoio pós-
-implementação e u1na revisão das lições aprendidas.
As me lhores prát icas que funcionaran1 notavelmente bem para a
Sherwin-Williams Con1pany incluen1 o estabelecimento de critérios para o sucesso,
consistindo da análise de objetivos e de necessidades/exigências do projeto, comuni-
cações frequentes ent re os n1embros da equipe de projeto e entre a equ ipe e outras
partes interessadas no projeto, recursos dedicados, definição de funções e responsa-
bi lidades, transferência de conhecimento entre equipes multifuncionais, traba lho de
equipe, desenvolvin1ento de um ambiente de trabalho animado e em sinergia e uma
revisão das lições aprendidas.
Uma das 1nelhores práticas na gestão de projetos é a que propicia que a maturi-
dade e a excelência ocorra1n rapidamente quando a gerência sênior não apenas apoia
ativamente a prática, 1nas também articula com a organização sua visão de onde es-
pera que a gestão esteja no futuro. Essa visão pode motivar a organização a buscar a
excelência, e os aperfeiçoamentos das melhores práticas em uma metodologia de ges-
tão de projetos parecem ocorrer em rit mo veloz. Esse foi o caso da Sherwin-Williams
Company. Tom Lucas, vice-presidente de TI da empresa, co1nenta sua visão para a
Shenvin-Willia1ns:
O futuro da gestão de projetos na Sherwin-\Villiams Company inclui a integração de
disciplinas de gestão de projetos e das melhores práticas por meio do estabelecimento
de um PMO virtual, combinado com técnicas de gerenciamento de portfólio para obter
resultados de alto valor de forma sistemática . A Sherwin-Williams Company prevê que o
uso de um PlvlO virtua l não apenas irá incutir as melhores práticas como competências
importantes, mas também irá ajudar a desenvolver a maturidade em gestão de projetos
na organ ização.
Um intuito é unificar as metas e os objetivos de departamentos individuais aplicando
uma estrutura de gestão de projetos uniforme, mas flexível, na busca de melhores resultados
em toda a empresa. Demos grandes passos nesse sentido. A Sherwin-Williams Company de-
seja aprender com os sucessos e erros passados, tomar os processos eficazes e desenvolver as
habilidades e os talentos das pessoas para trabalharem de forma mais eficiente por meio do
estabelecimento de procedimentos padronizados dentro da empresa. Acima de tudo, preci-
samos demonstrar um verdadeiro valor de negócio ao usar a gestão de projetos profissional.
Embora os profissiona is de gestão de projetos possam se encontrar em d iferentes unida-
des operacionais, para estar o mais perto possível de nossos clientes internos, pretendemos
ter um grupo central, que estabeleceria padrões e realizaria a identificação e o compartilha-
mento das melhores práticas.
Todos já gerenciamos projetos em um momento ou em outro, mas poucos somos ca-
pazes de ser gerentes de projetos. É nisso que se encontra um dos maiores impedimentos à
implementação da gestão de projetos profissional. Podemos ter os gerentes de projetos mais
bem treinados, podemos ter todos os processos certos em funcionamento, podemos usar os
termos corretos, mas, a inda assim, o PMO o u falhará, o u será apenas uma fração do que
poderia ser. A equipe de funcionários e a gerência têm dificuldades em apreciar a força e os
melh ores resultados de um projeto gerenciado profissionalmente. Até q ue tenham se envol-
vido, a té q ue tenham sentido, a té que vejam os resultados, a d istinção entre gerenciar um
projeto e gestão de projetos será apenas semântica .
A diferença entre gerenciar projetos e a gestão de projetos p rofissional é como a diferen-
ça entre a travessar um lago em um caiaque ou em uma lancha . Ambos o levarão até o o utro
lado do lago, mas ir de caiaq ue é um processo longo e doloroso. Como as pessoas poderão
saber a diferença se você nunca lhes oferecer uma carona em sua lancha?
O estudo de caso da Telecom de 2002 foi uma ;;carona" desse tipo. Apesar de o foco
da discussão ter sido a rticular o mecanismo do processo do PMO, a verdadeira história é
a melhoria d ireta na rentabilidade por ação que resultou dessa inicia tiva bem-suced ida.
Além disso, houve uma preocupação legítima da empresa com o possível impacto q ue essa
mudança poderia causar para nossos clientes internos e externos, caso a lgo desse errado
d urante a transição. A gestão de projetos profissiona l q ue foi empregada deu a todos um
o timismo cauteloso necessário para segui r adiante, e os resultados fizeram a eq uipe de fun-
cionários e a gerência passarem a "ter fé" no processo.
Projeto por p rojeto, sucesso por sucesso, uma transição cultura l está em processo. De-
monstramos, com os melhores resultados devido à gestão de projetos profissiona l, q ue so-
mos capazes de prestar serviços a um p úblico mais amplo e de assumir projetos fora do
ramo da TI, onde o PMO teve início.
Ao nos mantermos focados nos res ultados dos negócios, ao nos mantermos próximos
de nossos cl ientes para que possamos compreender bem suas necessidades e ao constan -
temente nos desafiarmos a aprimorar nossos processos s ubjacentes, os serviços de nosso
PtvlO estão amadurecendo mais e ma is a cada d ia, o que torna a jornada d ivertida para
todos.
4.29 Medical Mutua12º

Algumas empresas descobr iram que várias metodologias já disponíveis que podem ser
comp radas ou al ugadas têm flexibilidade suficiente para satisfazer suas necessi dades.
Esse é pa rticula nn ente o caso na á rea de T I. As informações a seguir foram fornecidas
por Dan Halicki, coordenador de administração de TI na Mutual.
Introdução
Os ana listas da indúst ria acred itam que apenas um quarto de todos os projeto de TI
seja ent regue dentro do prazo, e menos a inda dent ro do orça mento. Em resposta a esse
p ro blem a, surgira tn várias abordagens de gestão de projetos cujo pri ncipa l objetivo é
ga ra ntir o sucesso do projeto.
Com o advento da reforma do sistema de saúde, a Medica l Mutual buscou refor-
çar sua estratégia para entrega r u1n a com binação de sistetn a de benefícios, gerencia-
mento de saúde e outr os serviços com o intuito de otim izar o valor investido no setor
de saúde. A fim de ajudar a alca nçar esse objetivo, aj ustamos nossa fi losofia de gestão
de projetos de TI de modo que encontrássemos o equilíbrio adequado entre os requisi-
tos metodo lógicos rigorosos e as rea lidades de contenção das despesas ad tninistr ativas
gerais do projeto.
?o O material desta seção foi retirado de A. \-VaHen e D. Halicki, Medical Mutual - Project Management Meets
Hea/1/,care Reform: Bringi11g the Right Amoimt o/ Discipline to a Project. © 2013 Medical Mutual. Todos os
direitos reservados. Reproduz.ido com permissão.
O desenvolvimento de sistemas na Medica l Mutual seguiu os princípios t radicio-

nais de gestão de projetos por mais de 20 anos, tendo, inclusive, um compro1n isso co1n
os padrões de GP do Instituto de Gestão de Projetos (PMI). Em 2005, estabeleceu-se
uma Equipe de Práticas de Gestão de Projetos para oferecer governança e garantir que
a 1netodologia e os padrões de gestão de projetos acompanhassem as subsequentes
iterações do Guia PMBOK®. O uso dos princípios t radicionais de gestão de projetos,
os conceitos do PMI e essa equipe de governança contribuiu para o sucesso geral do
projeto e ajudou a Divisão de TI a cumprir nossa missão de ser o melhor provedor
de tecnologia da informação para a Medical Mutual por meio da ent rega de soluções
com valor excepcional.
Quais são, então, as n1elhores práticas que a Medical Mutual segue para es-
tabelecer as prioridades do projeto, infundir flexibilidade e trazer o grau certo de
discipl ina à sua abordagem de gestão de projetos de tecnologia da inforn1ação? A
segu ir, temos uma discussão sobre as técn icas e deliverables que constituem os ele-
n1entos-padrão en1 gestão de projeto, da iniciação, planejamento, execução, controle
e monitoran1ento ao encerramento. Além disso, é importante enxergar a lém dos ele-
n1entos da metodologia proprian1ente dita para incluir o sisten1a de suporte que faz
tudo funcionar, como a ade.são da gerência executiva, o treinamento e as atividades
de seguimento.
O Com itê de Direção Executiva de TI fornece um processo de Gerenciamento de
Demandas e garante que as iniciativas de projetos de TI estejam alinhadas aos objeti-
vos estratégicos da organização.
A Med ical Mutua l usa um processo de gerenciamento de demandas que exige a
colaboração ent re a gerência de área da empresa e o planejamento de T I de modo a ali-
nhar eficientemente a visão de negócio às soluções técn icas. O Planejamento Est raté-
gico Corporativo estabelece os objetivos da e1npresa que guiam nossa estratégia de TI.
Para alcançar os objetivos desejados, esboçam-se propostas de projeto relacionadas
usando u1n formato padronizado de termo de abertura que identifique como o projeto
proposto se alinha a direcionadores de valor de negócio específicos e a direcionadores
de negócio estratégicos para garantir consideração. O antigo modelo de negócio do
setor de saúde está passando por mudanças significativas, e é de suma importância,
agora ma is do que nunca, que recursos escassos de TI seja utilizados nos projetos mais
estratégicos.
Fornecer treinamento contínuo em gestão de projetos em

toda a empresa
O termo "gestão de projetos" pode significar diferentes coisas para diferentes pessoas.
E1n um curso, o inst rutor explica como a Tecnologia da Informação se aplica à sua
"metodologia de gestão de projetos" aperfeiçoada para garantir que todos os partici-
pantes do projeto, incluindo a comunidade dos clientes, tenham uma compreensão do
processo compartilhada, especialmente a participação das pa rtes interessadas e a par-
ticipação proprietária. Com uma duração de 24 horas ao longo de três d ias, o curso
oferece instrução e um workshop prático sobre os principa is componentes do proces-
so de gestão de projetos, por exemplo, in iciação, planejamento, execução, 1nonitora-
mento e controle e encerramento do projeto. Um 1nanual de gestão de projetos (PM
Handbook) será implementado em 2013 para ajudar na orientação dos funcionários
existentes e na instrução de funcionários novos sobre a fi losofia de gestão de projetos
em uso na Medical Mutual.
Estruturar cada projeto de maneira consistente, incluindo escopo,

responsabilidades, riscos e marcos de alto nível
Central ao processo de gestão de projetos é a criação do termo de abertura do pro-
jeto, que documenta e forma liza o acordo de todas as partes envolvidas, incluindo
patrocinadores da e1npresa, gerente de projetos e os membros da equipe do projeto.
O termo de abertura descreve o que será realizado e quando, quem é responsável por
sua realização, riscos conhecidos e o curso de ação que deve ser to1nado para mitigar
os riscos, 1nedidas de garantia da qualidade, medidas quantificáveis de sucesso e os
principais 1narcos a sere1n alcançados.
Comunicar e atualizar os planos e o status do projeto de maneira

contínua, usando ferramentas on-line, quando for o caso
Uma vez que o termo de abertura de projeto aprovado esteja em vigor, o p lano de
projeto passa a ser o próxiino foco de atenção. O plano e os relatórios de status pe-
riódicos que documentam o progresso em relação ao que foi planejado são os princi-
pa is veículos de comunicação para 1nanter a gerência e os funcionários informados. A
Medical Mutual montou e conserva um centro de status de projeto on-line em tempo
real usando o software SharePoint para 1nanter o planejamento de projeto, problemas,
controle de mudanças e informações sobre o projeto atualizadas e prontamente dispo-
níveis para toda a organ ização. Informações sobre o Desempenho Essencia l também
são mantidas e disponibi lizadas nesse sistema como uma fonte contínua de medidas
de nível de serviço de TI.
Manter uma lista oficial de problemas do projeto, incluindo quem é

responsável, quais são os possíveis impactos e como o problema
foi resolvido
À medida que problemas vão surgindo durante a execução de um projeto, é vital
manter um histórico preciso, de modo a docu1nentar apropriada1nente cada problema
e o que foi feito a respeito. Nas reuniões de projeto, o histórico de problemas serve
como uma ferramenta importante para evitar a repetição improdutiva de informações
antigas e garantir às áreas interessadas que seus problemas não foram esquecidos. Jun-
ta mente com o termo de abertura e os relatórios periód icos de progresso, o histórico
de problemas pode ser acessado por meio do centro de status do projeto e problemas
cruciais são realçados no dashboard de relatórios de status do projeto.
Usar um processo formal de controle de mudanças, incluindo um Comitê

de Direção Executiva para solucionar mudanças de maior alcance
À n1edida que surjan1 problen1as que possan1 exigir recursos ext ras, o "arqui-in in1 i-
go" do GP chamado "aumento de escopo" pode con1eçar a surgir e a gradualmente
ton1ar as rédeas do projeto. Un1 processo formal de controle de mudanças é essencial
para ajudar o gerente de projetos con1 o dilen1a entre agradar o cliente ou estourar
o orçamento ou perder marcos. O processo de cont role de n1udanças da Medical
Mutual (solicitação e ava liação) pode ser acessado por meio do centro de status do
projeto, e o controle de mudanças cruciais é realçado no dashboard de relatórios de
status do projeto.
Instituir a governança para revisar periodicamente o processo

de gestão de projetos e projetos selecionados a fim de determinar como
a metodologia está se saindo e identificar oportunidades de melhorias
Com o estabelecimento dos padrões de gestão de projetos e os investimentos maciços
em treinamento, faz sentido dar um passo atrás de vez em quando e avaliar se os ob-
jetivos gerais estão sendo atingidos. Quando os projetos enfrentam dificu ldades, u1na
abordagem diferente teria ajudado? Quando os projetos se saem bem, que aspectos da
execução do projeto devem ser co1npatilhados por outros projetos? Esses são os tipos
de perguntas que nossas equ ipe de práticas de gestão de projetos de TI está preparada
para responder. Esforços de benchtnark também são valiosos para avaliar o progresso
ao longo do tempo.
Concluir cada grande projeto com uma apresentação aberta das lições
aprendidas, dos resultados para compartilhar experiências ganhas,
demonstrar novas tecnologias e real izar o encerramento oficial
Muitas organizações passa1n apressadamente pela fase de conclusão do projeto para
podere1n iniciar a tarefa segu inte. Entretanto, dedicar um te1npo para docu1nentar
integralmente todas as rea lizações, questões ext raordinárias, deliverables ad iados e
lições aprendidas é um exercício válido que dá o devido crédito ao que foi concluído
com êxito, reduz mal-entendido quanto a qualquer omissão e faci lita transições para
projetos de seguimento. Trimestralmente e utilizando tecnologia webcast, a gerência
de TI e funcionários de liderança se reúnem para ver apresentações sobre as Lições
Aprendidas em projetos recentes e essas apresentações são mantidas para futuras con-
sultas, quando necessário.
Adaptar-se para atender às necessidades do cliente

Hoje n1ais do que nunca, o ambiente de seguros de saúde em rápida evolução obriga
a Med ical Mutual use n1etodologias de desenvolviinenro de software n1ais flexíveis
para atender aos requisitos da en1presa. As n1etodologias pode1n incluir modelos de de-
senvolvimento (sequencia is, incren1entais e iterativos) usados juntamente co1n uma ou
mais técn icas (ági l, geração de protótipos, orientada a objetos). O desenvolvimento de
sites parece ser particulannente adequado para u1na metodo logia ágil, já que o ten1po
de co locação no 1nercado é uma preocupação cent ral. Independente do n1odelo ou téc-
nica e1npregada no esforço de desenvolvimento, a entrega de um projeto ben1-sucedido
depende da estrutura de gerenciamento de processos con1uns do projeto, con10 por
exemplo iniciação, planejamento, execução, moniroran1enro e controle e encerran1enro.
Essa estrutura fornece um vocabulário comum aos gerentes de projeto e pern1ite que
rodas as partes interessadas co1npreenda1n as fases do projeto 1nais claramente.
Conclusão
U1n dos motivos mais comuns pelos quais os projetos perdem o controle é o fato de
os gerentes de projetos operarem reativa1nente em vez de prever possíveis obstácu los.
Quando o obstácu lo finalmente surge, eles hesitam em tomar decisões eficientes, o
que geralmente resulta em situações que podem destruir um projeto. A experiência da
Medical Mutua l mostra que as melhores práticas aciina ajuda1n a estiinular um am-
biente mais proativo em parceria com o cliente, resultando na entrega mais consistente
de projetos bem-sucedidos. Além d isso, essa abordagem alcança um equi líbrio que
exige despesas gera is mínimas, obtendo, ao mesmo tempo, benefícios máximos.
21
4.30 Holcim
A Holci1n é uma das fornecedoras líderes mundia is de cimento e agregados (pedras
britadas, areia e cascalho) além de outras atividades como concreto pré-1n isturado e
asfalto, incluindo serviços. O Holcim Group detém interesses majoritários e minoritá-
rios e1n mais de 70 países em todos os continentes. A indústria de cimento é intensiva
em termos de capital, exigindo investimentos de longo prazo. Executar projetos com
segurança, dentro dos custos esperados e atingindo as 1netas de prazo e qualidade é
crucial para o sucesso financeiro de longo prazo dessas empresas. Devido à estrutura
da empresa e aos limitados recursos disponíveis, os projetos são iniciados e executados
localmente, co1n uma organ ização de suporte cent ral que fornece o know-how em
conceitos tecnológicos, planejamento e controle de qual idade.
Metodologias de gestão de projetos

A Abordagem de Gestão de Projetos (AGP ou, em inglês, Proiect Management Appro-
ach ou PMA) é a metodologia-padrão da Holci1n para todos os projetos, e se baseia
nos padrões do PMI. No final da década de 1990, a Holci tn decidiu desenvolver um
padrão e uma 1netodologia est ruturada de gestão de projetos que fora 1n introduzidos
e1n toda a empresa para o desenvolvimento e execução de todos os tipos de projetos.
Essa 1netodologia compreende cinco fases e 25 passos cobrindo todo o ciclo de vida
da gestão de projetos, incluindo a 1naioria das 10 áreas de conhecimento do Guia
PMBO~ do PMI, e tetn como suporte uma série de tetnplates. As fases de defin ição,
encerramento e avaliação recebem u1na ênfase especial para possibilitar o comparti-
lhamento de conhecimentos no Holcim Group.
A Holcim possui padrões específicos de gestão de projetos para projetos de inves-
timento (projetos CAPEX).
A fim de manter e melhorar seus resultados, ao longo da última década, a Holcim
tem investido e1n méd ia 50'% de seu fluxo de ca ixa proven iente das operações nos cha-
mados projetos CAPEX, que são projetos para manter, aprimorar e expandir as insta-
lações de produção da Holcitn. Como um passo a mais em direção à padronização, a
Holcim decidiu expandir a AGP para apl icação em projetos CAPEX, incorporando as
tarefas e deliverables 1nais importantes e crucia is. Quat ro novas metodologias foram
desenvolvidas e implementadas. Elas abrange1n as mesmas cinco fases da AGP, mas o
número de passos foi ampl iado para ent re 50 e 200, tendo, cada um deles, ferramentas
e diretrizes de suporte. As novas metodologias são:
• ProMap: metodologia para projetos CAPEX no ramo de ci1nento. Divide-se em
duas metodologias, a ProMap for Small Projects (investimentos inferiores a CHF
2 m ilhões) e ProMap for Medium and Large Projects (investitnentos superiores a
CHF 2 1nilhões).
• AggPro: metodologia para projetos CAPEX no ra1no de agregados.
• RMXPro: n1etodo logia para projetos CAPEX no ramo de concreto pré-misturado.
• AsphPro: metodologia para projetos CAPEX no ra1no de asfalto.
Já que a maioria dos gerentes de projetos conhece a AGP, eles podem aplicar a me-
todologias e passos específicos do CAPEX com apenas um pouco mais de treinamento.
i, €>2013 by Holcim. Reproduz.ido com permissão. Todos os direitos reservados. O material desta seção foi
fornecido por Roberto Nores, líder do escritório de gestão de projetos CAPEX, Hokim Technology Ltd. -
Hokim Group.
Gerenciamento de portfólios de projetos

E1n decorrência de seus esforços em gestão de projetos, a Holcim reconheceu a neces-
sidade de estabelecer conexões claras ent re seu planeja1nento anual de alto nível (pro-
cessos de planejamento e orçamento empresarial ) e a execução operacional diária de
projetos. Em média, o Holcitn Group realiza entre 100 e 300 projetos por ano. Houve
uma necessidade de otimizar a priorização de projetos, seus fluxos de ca ixa, alocação
de recursos e mon itoramento de portfólios. Consequente1nente, estabeleceu-se u1na
metodologia de gerenciamento de portfólios de projetos que oferece suporte à alta
gerência e1n cada país para gerenciar seu Portfólio de Projetos anua l.
As atividades de gerenciamento de portfólios de projetos têm o suporte de u1n
software comum que comporta a maioria dos seus processos. Até o momento, esse
software está e1n vigor em 60 % das operações da Holcim, e tetn boa aceitação por
funcionários e gerência.
Treinamento em gestão de projetos na Holcim

Ao longo dos anos, a Holcim estabeleceu un1a série de programas de treinan1ento e1n
gestão de projetos para aumentar o nível de competência dos gerentes de projeto. Atual -
mente, a Holcin1 traba lha com o seguinte conceito de treinan1ento e1n três níveis:
Progra1nas locais de treina1nento:
AGP: esse treinamento visa a garantir que os gerentes e as equipes de projeto com-
preendam a AGP básica e os princípios fundamenta is de gestão de projetos
por t rás dela.
ProMap: esse treinamento visa a garantir que os gerentes de projetos CAPEX
compreendam os passos e ferramentas adicionais dessa abordagem.
Progra1nas regionais de treinamento:
Seminários e programas de certificação em GP: esses programas são voltados para
o público de gerentes de projetos que lidatn com os projetos 1na is importantes
e co1nplexos em cada país. Os programas abordam tanto habil idades pesadas
de gestão de projetos (geração de cronograma, gerencia1nento de valor agre-
gado, etc.) quanto co1npetências ma is leves (liderança, engajamento das partes
interessadas, etc.). Os cursos incluem várias atividades pré e pós-sem inário
para 1naximizar o impacto das novas habilidades sobre seus projetos. Os cur-
sos também faci litam a criação de redes de gerentes de projetos em regiões
geográficas (Ásia, Europa, América Latina, etc.).
Treina1nento global:
Grande sem inário de gestão de projetos CAPEX: esse treinamento serve como
u1na plataforma de intercâ1nbio na qual os gerentes de projeto e as princi-
pa is partes interessadas dos ma iores projetos CAPEX se reúnem para trocar
experiências e discutir melhores práticas. O treinamento é rea lizado em uma
área de const rução dos maiores e 1nais complexos projetos da Holcim.
Escritórios de gestão de projetos da Holcim

Ao longo dos anos, a Holcim tem estabelecido escritórios de gestão de projetos
(PMOs) para oferecer suporte a seus esforços e1n gestão de projetos. Em 1999, o pri-
meiro escritório global foi inaugurado para desenvolver metodologias e competências
de gestão de projetos. Seu foco era1n o desenvolvimento e a implementação de u1na
abordagem-padrão de gestão de projetos, fornecendo um conjunto de ferra 1nentas
padronizadas, desenvolvendo competências do pessoa l, fornecendo 1nentoria/coaching

para gerentes de projetos e protnovendo a gestão de projetos na organização.
No final da década de 2000, a Holcim começou a estabelecer PMOs funciona is
globa is nas áreas com a 1na ior quantidade e investi tnentos em projetos: T I e CAPEX.
Esses PMOs focalizam-se etn:
• monitorar e controlar o desempenho do projeto: relatórios de stat11s de projeto
para instâncias superiores da gerência, monitorar indicadores-chave de desempe-
nho do projeto, etc;
• multigerenciar os projetos: coordenar projetos, identificar, selecionar e priorizar
novos projetos, alocar recursos ent re projetos, etc;
• aprendizagen1 organ izacional: gerenciar atividades de documentaç.ão de projetos,
conduzir revisões pós-projeto e auditorias de projeto, docun1entar e implementar
lições aprendidas, documentar e Ítnplementar processos de gestão de riscos.
O último PMO estabelecido no nível do grupo foca liza aspectos estratégicos da
empresa, oferecendo suporte, em particular, à itnplementação do principal programa
de melhoria do desempenho da Holcün, o chamado Jornada rumo à Liderança da
Holcim (Ho/citn Leadership journey), cujo objetivo é acrescentar CHF 1,5 bilhão em
lucros até 2014 a fim de melhorar o capital de retorno sobre investimento depois dos
impostos para pelo 1nenos 8'%. O PMO da Ho/cim Leadership journey prioriza o
aconselha ,nento da a lta gerência, participando do planejamento estratégico e financei-
ro, 1nonitorando o atingimento de benefícios e alvos financeiros do projeto, etc.
Resultados alcançados
Em 1999, o Comitê Executivo da Holcim t ransformou a AGP em um padrão mundial
para suas operações. Hoje em dia, as metodologias específicas AGP e CAPEX de ges-
tão de projetos são a linguagem comum no Grupo. A 1na ioria dos 1nais de 5 m il geren-
tes de projetos em todo o mundo faz uso dessas abordagens, adaptando-as à natureza
de cada projeto individual.
A aplicação dessas metodologias ajudou a:

• reduzir o tempo de execução dos projetos;
• reduzir sobrecustos, além dos custos de investimentos;
• melhora r a capacitação para executar projetos;
• melhora r a colaboração e o t rabalho em equipe.
Esses esforços em gestão de projetos estão ajudando o Holcim Group a manter
sua posição como um dos líderes na produção de cimento e no setor de materiais de
const rução.
4.31 Westfield Group

Desenvolver uma 1netodologia de gestão de projetos pode não ser tão complicado
quanto se poderia imaginar. Há atividades que uma empresa pode realizar para facil i-
tar o processo de desenvolvimento da metodologia. As informações desta seç.ã o foram
fornecidas por Janet Kungl, profissional de gestão de projetos (PMP®) e gerente de
p rogramas do \Vestfield Group.
Há quatro peças fundamentais que, se presentes, permitem o desenvolvimento de
u1na 1netodologia eficiente de gestão de projetos em um período de tempo razoavel-
mente curto:
• Reconhecimento e apoio à necessidade da competência em gestão de projetos pelo

nível executivo
• Estabelecimento de uma organ ização foca lizada em projetos com uma visão de
como a disciplina de gestão de projetos será integrada à organização
• Promoção do Gttia PMBOK®para o desenvolvimento de metodologias
• Compro1n isso em desenvolver e/ou cont ratar gerentes de projeto habilidosos
O Westfield Insurance (westfieldinsurance.com), um grupo de empresas de servi-
ços bancários, de seguros e de serviços financeiros afins sediado em Westfield Center,
Ohio, EUA, reconheceu, no final da década de 1990, que as necessidades das empresas
tinham mudado e1n relação aos projetos de tecnologia da informação e de siste1nas de
informação. Para atender essas necessidades, a gerência sênior constatou que eram ne-
cessárias capacidades de gestão de projetos além de uma organização que fosse criada
para ser "parceira" das empresas e se especia lizasse em prover soluções empresariais
e soluções tecnológicas de alta qualidade. O \Vestfield reorganizou seu departa1nento
de sistemas de informação, passando a incluir uma unidade de entregas focalizada na
entrega de projetos por meio do uso de "equipes virtuais" formadas por membros de
equipes de tecnologia de de negócios.
A fim de desenvolver a capacidade em gestão de projetos, um dos gerentes de
projeto do Westfield foi designado ao projeto de desenvolver a metodologia de ges-
tão de projetos. A abordagem foi usar o Gttia PMBOK® como ponto de partida e
personalizar os processos de n1odo que eles refletissem a cultura e a estrutura orga-
nizacional do Westfield. Um componente-chave do apoio contínuo à metodologia
era designar os outros gerentes de projetos para trabalhar no desenvolvimento dos
processos.
A metodologia começa com uma explicação das fases do projeto (ver Figura
4-45 ). Dentro de cada uma dessas fases, fazem-se a definição e referências cruzadas
das atividades a serem realizadas de acordo co1n as nove áreas* de conhecimento do
Guia PJ\1BOK® Guide. Um exemplo é exibido na Figura 4-46. Cada uma ds ativida-
des da Figura 4-47 pode, então, ser ampl iada em u1n fluxograma que mostra as ati-
~ Projeto ::::----
Planejar Realizar
-<:::: ~
Iniciação Planejamento Execução Encerramento
Conceber Definir Executar Concluir
Compromisso Planos Produto Produto

do projeto aprovados aceito aceito
Fundos Principal decisão
aprovados "Continuar"f'Não
continuar"' tomada
Figura 4-45 Fases do ciclo de vida.
• N. de T.: A versão 4 do Guia PMBO~ possui nove áreas de conhecimento, e a versão S coma com 10 delas.
Gerenciamento Processo Seleção e Processo de Mobilização de

de recursos de inicio integração do seleção do oomitê recursos de
humanos do projeto gerente de projetos de direção alto nivel
Gerenciamento Estabelecimento
de aquisições do projeto
Plano de Processo de
Gerenciamento de apresentação
comunicações
comunicações de alto nivel do projeto
Gestão Avaliação de
riscos de
de riscos
....
o
'D,
:w Gerenciameoto
alto nível
Determinação
..-..• de escopo
do escopo de
alto nivel
li
... Gerenciameoto Iniciar formulârio
de satisfação do
Coletar
as tições
da qualidade cliente para a equipe aprendidas
Anâlisede
Gerenciameoto
custo-beneficio
de custos de aho nivel
Gerenciameoto Geração de
cronograma
do tempo de aho nivel
Processo de Termode
Gerenciameoto
priorização abertura
da integração oorporativa do projeto
.
' Tempo '.
Figura 4-46 Atividades da fase de iniciação.
vidades detalhadas necessárias para a realização dos deliverables dessa atividade. Por
exe1n plo, a atividade de "Processo de Iniciação do Pro jeto" na Figur a 4-46 está listada
sob Gerenciamento de Recursos Hu1na nos. As atividades deta lhadas são apresentadas
pelo fluxograma da Figura 4-47. Templates e exemp los fictícios ta1n bém fo ra 1n de-
senvolvidos e estão acessíveis em u1na pasta elet rônica pad rão do projeto. Foi imp le-
mentado também um processo de mel horia contínua para a metodologia. Melhorias
de processo incluem o desenvolvimento de 1nétr icas de sucesso do projeto, revisôes
de projeto forma lizadas e a definição de pontos de integração com outr os processos
[p.ex.: ciclo de vida de desenvolvi mento de software (CVDS), governança de a rquite-
tura e pla nejamento de portfól io]. Co1n o passar do tempo, gerentes de projetos ex-
perientes foram recrutados de o utras organizaçôes pa ra complementa r os gerentes de
projetos desenvolvidos internamente. Pa ra apoiar seu desenvolvimento profissional,
estabeleceu-se, em 2006, um fórum de gerentes de pro jetos. Essa reunião, que ocorre a
cada duas semanas, permite que os gerentes de p ro jetos comparti lhem mel hores práti-
cas e liçôes aprendidas com seus colegas de trabalho. Uma t rajetória da experiência em
gestão de projetos foi documenta da em 2007 pa ra identificar experiências e competên-
cias fundamentais que influencia1n a tr ajetória de ca rreira de um gerente de p ro jetos
e defi ne o ca minho de entrada, de passagem e de saída pelos " tr il hos" da trajetória da
ca rreira em gestão de projetos (ver Figura 4-48 ).
A função ganhou aceitação por 1neio da ent rega bem-suced ida de projetos. Um
apo io maior de todos os níveis da organização é evidente pelo fato de 1nais clientes
(1) (2) (3) (4) (5)
GP formalmente
designado ao
projeto - PGM (Program
Manager) agenda --+
reunião
inaugural
Executar as
atividades do
processo de
iniciação do
projeto
1-l
Revisar
resultados do
início do projeto
com PGM
- Prosseguir para
as atividades
de planejamento
formal do projeto
Figura 4-47 Processo de iniciação do projeto.
"TolhQs" dQ aerencjamento de D
'Trilhos" da gestão de projeto
Competências
fundamentais
"Papéis
alimentadores" Experiências fundamentais
Habilidades
técnicas
Figura 4-48 A trajetória da experiência do gerente de projetos.
solicitare1n parcerias co1n equipes lideradas por gerentes de projetos. Ter colocado as
peças fundamentais corretas no lugar certo criou a fundação necessária para seguir
adiante. Atualmente, o \Vesúield está tendo ma is sucesso na entrega e resultados me-
lhores de maneira geral com importantes iniciativas de negócios. Esses resultados va li-
dam o va lor da gestão de projetos. A jornada rumo à excelência em gestão de projetos
continua no Westfield Insurance.
4.32 Hewlett-Packard
Doug Bolzman, arquiteto consultor, profissiona l de gestão de projetos (PMP®), espe-
cialista em !TIL®na Hev.rlett-Packard, discute a base para uma metodologia de gestão
de projetos:
Muitos clientes têm uma n1etodologia de gestão de projetos e, alén1 d isso, a
n1aioria das en1presas apresenta várias metodologias que incluem disciplinas de
gestão de projetos. A HP teve êxito em integrar o método de GP definitivo en1 ou-
tras n1etodologias para permitir a promoção dos padrões e ferran1entas de GP sem
duplicação.
Para o gerenciamento do ambiente de TI de uma empresa, desenvolvemos u1na
estr utura de interface com o cl iente chamada de Gerenciamento da Tecnologia da In-
formaç.ã o Empresaria l (ITEM, Information Technology Enterprise lvfanagement). Essa
estrutura auxi lia o cliente a 1napear sua d ireção estratégica em liberações exequíveis. A
ITEM é uma estrutura pré-integrada de três modelos e uma metodologia, como ilustra
a Figura 4-4 9.
Antes da liberação do ITIL® edição 2007, identificamos uma lacuna para geren-
ciar o cic.lo de vida de um serviço e desenvolvemos o que chamamos, na época, de Me-
todologia de Gerenciamento de Liberação, que engloba quat ro Etapas (Planejamento,
Integração, Implementação e Operações). Cada Etapa é constituída de Fases -Ativida-
des - Tarefas. Isso é 1nostrado na Tabela 4-4.
Desde então, o ITIL® introduziu a abordagem do ciclo de vida nas edições de 2007
e 2011. Suas etapas, Estra tégia de Serviço, Design de Serviço, Transição de Serviço,
Operação de Serviço e Operação Contínua de Serviço são equiva lentes quase exatos
de nossas etapas MGL. Desde a implantação em 2007, mantivemos grande parte de
nossos colaterais, uma vez que as novas edições do ITIL® não fornecia1n uma estr utura
ana lítica abrangente. Simplesmente associamos nossa EAP aos objetivos e conteúdos
gerais da estr utura do e.ido de vida ITIL®. Isso é uma ilustração de como desenvolve-
mos continuamente nossas práticas e de como continua1nente apl icamos os avanços
da indúst ria ao nosso trabalho.
Basicamente, usamos a regra 9x9, como mostra a Figura 4-50. Se houver ma is
de nove fases em uma etapa e mais de nove atividades e1n cada fase (um tota l de 81
unidades de t rabalho), então o escopo se tomará grande demais, e nosso esquema de
numeração se tomará instável.
"OQUE"
oModelo de Gerenciamento de Infraestrutura tMGI ou.
em Inglês, IMM, tnwstruc111Ce Manaaement MQde/1 descreve
sistematicamente tudo do ambiente de TI que precisa ser gerenciado.
"QUEM"
oModelo de
"QUANDO" Governança de TI...
o Modelo de
Maturidade de TI...
Q] Q!] [!!!:)!!!) [?J
DQBEJô
iiii Define uma
matrÍZ de
Mede o progresso que os governança
clientes estão fazendo ao
colaborativa
estabelecer e alcançar que inclui todos os
metas relativas à maturidade
papéis necessários em um
de seu ambiente de TI. ambiente de TI empresarial.
"COMO"
AMetodotooia de Gerenciamento de Liberacao (MGL ou. em Jnotes. RMM.
Re/ease Manaaemenl MethodO!QQ'à descreve como liberar qualquer tipo de modificação
em um ambiente de TI de produção de forma estruturada e previsível.
Figura 4-49 Uma abordagem integrada para o mapeamento da fase de Atividade de uma
solução integrada.
TABELA 4-4 Etapas da metodologia de liberação
Etapa Descrição
Planejamento O ambiente que é utilizado para estabelecer e gerenciar a visão e a direção estratégica do
ambiente de TI da empresa e definir proativamente o conteúdo e o cronograma de todas
as liberações de TI. A finalidade é oferecer um meio comum para o cliente e os presta-
dores de serviços planejarem o ambiente de TI da empresa de maneira clara e precisa e
gerenciar todos os aspectos do planejamento, estimando uma liberação e estabelecendo
expectativas apropriadas para o cliente sobre o que cada liberação irá entregar
Integração O ambiente que é utilizado para finalizar o design da liberação de uma infraestrutura pla-
nejada e realizar todos os testes e validações junto ao cliente, preparando a liberação para
ser implementada na comunidade do usuário. A finalidade é fornecer um meio comum
para o cliente e prestadores de serviços para validarem de forma clara e precisa a segu-
rança, precisão e conteúdo de cada liberação e finalizar todo o desenvolvimento, além de
fomecer ao diente um quadro claro e preciso do resultado da liberação e de estabelecer
expectativas apropriadas quanto à implementação e às atividades operacionais, custos e
cronogramas
Implementação O processo que é utilizado para implementar novas liberações do design de TI da empresa
(componentes de negócios, de suporte e técnico) para determinado ambiente-alvo. A fina-
lidade é fomecer um meio comum para o cliente e prestadores de serviços para agenda-
rem, implementarem e fazerem a conversão para a produção do ambiente atualizado
Operações O ambiente de produção que é utilizado para sustentar e manter os componentes de TI e
os itens configuráveis que fazem parte do ambiente de TI da empresa. A finalidade é ofere-
cer um ambiente de TI estável que é exigido pelos usuários de TI para servir de suporte a
seus papéis e responsabilidades dentro da empresa
Descrição:
Ahierarquia sequencial de eventos caso não haja necessidade
de desvio. Isso demonstra o mais alto percentual de
... 1000 .._2000 ... 3000 ocorrência quando o processo é executado. Aprincipal
Nome Nome Nome Intenção deste gráfico é demonstrar as tarefas subordinadas
da rase da fase da fase
a cada atividade
... 1100 .._2100 ... 3100 Val or:
Nome da Nome da Nome da • Cada elemento de trabalho pode ser ldentíllcado eassociado
a!Mdadt atividade a!Mdadt externa ou Internamente ao componente
• Todasas atividades são divididas em tarefas (Justmcado)
... 1200 .._2200 ... 3200
Nome da Nome da
• To dos os trabalhos são representados uma vez apenas
Nome da
a!Mdadt atividade alivldadt (mesmo que seja executado multas vezes)
11._1300 .._2300 ... 3300

Estrutura:
Nome da
• Todos os elementos de trabalho possuem um ldentíllcador
Nome da Nome da
alivldadt atividade alivldadt único
- Fases numeradas pelas unidades de milhar
..._1400 ..._2,00 ..._3400 - Atividades numeradas pelas unidades de centena
Nome da Nome da Nome da - Tarefas numeradas pelas unidades de dezena
atividade atividade atividade • Todosos elementos de trabalho precedidos pelo Componente
Identificador de nome (PL_1000; PL_1100)
• Nomes de atividades e tarefas devem ser relativamente curtos
PL.. 1410 Task Name e descritivos de um trabalho completo. e não frases
PL.. 1420 Task Name • Todasas tarefas formam o escopo da atividade
• Este NÃO é um modelo relacional
Figura 4-50 Mapeamento da fase de atividade.

4.33 DTE Energy

Henry Campbell, a nalista chefe do Escritório de Serviços de Atendimento ao Cliente
de Gestão de Pro jetos e Time Menke, p rofissional de gestão de projetos (PMP®), es-
pecial ista sênior em melhorias contínuas, gerente de Desempenho das Operações de
Dist ribuição na DTE Energy, discute o crescimento da gestão de pro jetos na empresa:
A DTE Energy crio u uma abordagem com um para garantir que projetos sejam implemen-
tados de maneira consistente. No passado, diversas metodologias de gestão de projetos
eram usadas em toda a empresa . Várias unidades de negócios (especificamente, o Serviço de
Atendimento ao Cliente (SAC), Operações de Distribuição (00 ), Operações de Gás (OG),
Grupo de Estratégias de Sistemas O peracionais (GESO), e grupos de Serviços de Informação
Tecnológica (SIT)) chegaram a um consenso de q ue era necessário adotar uma abordagem
"comum".
O ;'processo de gerenciamento de portfólios de projetos CI" (Figura 4-51) foi desenvol-
vido utilizando a melhores p ráticas internas e externas. Essa abordagem foi desenvolvida
para fornecer uma estrutura comum pa ra projetos de Melho rias Contínuas, porém, o utros
tipos de projetos (de capita l, ad-hoc, etc.) também se beneficiaram de sua estrutura. O pro -
cesso contém sete fases de gestão de projetos:
1. Identificação
Projetos potenciais são identificados a pa rtir de uma variedade de fontes, inclusive
(mas não somente):
• Solicitações de ações corretivas
• Revisões após ação
• Benchntarking
• Swanns
Projetos considerados ;'Faça e pronto!" U11st Do lt, o u JDI) pula m a fase de Seleção,
passando d iretamente à fase de Iniciação.
ll. Seleção
Os projetos potencia is são, então, classificados de acordo com Critérios de Seleção de
Projetos estabelecidos, criam-se casos de negócio, se aplicável, registra-se o projeto junto à
o rgan ização apropriada, e inicia-se o trabalho relativo ao termos de abertu ra do projeto.
Ili. Iniciação
A fase de Iniciação inclui uma avaliação do estado corrente dos negócios e por q ue são
necessárias mudanças. O Termo de Abertura do Projeto é refinado, e toma-se a decisão
q uanto a prosseguir com o projeto o u não. (Figura 4-52).
O Termo do Projeto contém:
• Descrição e fina lidade do projeto
• Membros de equipe e seus papéis
• Linha do tempo
• Caso para mudança
• Premissas, riscos e desafios
• Identificação do estado atual
• Identificação do estado ideal
• Avaliação de lacunas (estados atual e ideal)
• Principais marcos
• Métricas (linha de base e a lvo)
1• i 1
!
il
j: ••
J
••
l ••
"'II
• ! 1
i j ji
-1---- . -~-- ~i
J J
--r--
: .i•
.i 1
í .• •t
i ;• !
•• ..•• ,~
f. f i!
i i Ji ...
l1
• • •
l.i '
• • 11---
1• 1•
g 3 !ã
• •
'• '•§• ia§!••
1
'I
i ••• :1
1 1 I' -i
~ 1!1 II
• .
i J• .1
J• õ
• • __ ...___
--• • ~i
(/)
g
-,ii'
Q)
_,J ·ea.
~,
,,
Q)
"O
1• g•
>
o
__ ... ___ :g
- ' --- ~
8.
g e
•i
Q)
"O
CI)
g
"O ••
-- e
o l Q)
e: t E
CI)
E
! "'
'õ
e
!!! J
•e
~
"e:~ •••
Q)
O)
1
Q)
"O
8 1
l
• ~
CI)
"O
O
tll! H!
LL-1-...!::::===;=====!===='======;:=::::;::=--1 .' f ~
e
• !•~ j~l
.U.'"•i ••• ·-· : ·,111 ,ili Q.
~
:
CI)
iht !Ui jf!I i j! li• ;5e
;!
e
Q. a. e a."" - cn
! h
~-! ~
•1 1
1\)
TERMO DE ABERTURA: Versão Da1a: ClD
CJ)
h*>ffl\8Qões s<t,,e o pft$eto e assir'lal!radospoo10s de d«isão (PO) de passagem de la.ses FW:lócas dos pot'IIOS de deeislio 1 a• e d aca da ,ews10
""'""
Nome (1() pf'CjelO Avalação 1fflt,Hffll!l'l 18çli O RMl.ba dos
Licle, da e<p.Jipe
Execta.-o oon'""'*>
"'' Da~ PD2 Da~ POO Da~
"'' "'~ G)
(1)
!!l
Pr,....&lfliio de orooesso
""e.
o
(1)
"O
Atlffi!ie de l'nf)aCIO sobe o Mgócb tlMS&da • POI 1SM 1HÃO Es1ado a!ual • P DI
.2.
0.ct.ii;,çlio de p«:t,19m;as POI (1)
......... l.inhoi de t»se POI ANO P02 Alwl P03 H'lail F'04 &lõldo ._..,ç •P02
Men1:l'08da eQu'ipe • POI

.
Papel
..., .
" ..,,. laOJl'\18 • P02
E~ipeoenir.it
0i11a&dO$ QU.-Omaa:x>$• P()l

Oill,'.I pfiW!ei,oo.i
....°"' ""'·' ""'·ª Rev,3
"''
PD2
Avêiraçao
"""11•
F03 rnQl9mef1.lçio
Avéfiaçêo de 0.1$108 e reout'808 r ~ de • POI

Detll'OdO UOOJ'.)O, Fora do Meq:)O. PO I
1Sm .... l'04 A:lwh.ldo$
Re8umo doe iesutlaclos. Po.t
Figura 4-52 Template do termo de abertura do projeto.

IV. Planejamento
A fase de Planejamento estabelece o estado desejado da mudança com uma ênfase no
(re) design técn ico, c ultural e de processos. Os gerentes de projetos recebem d iversas fer-
ramentas para auxili ar com o planejamento geral do projeto. Uma delas é o "Template
do Plano de Projeto" (Figura 4- 53). O template contém uma metodologia-padrão de pla-
nejamento para Projetos de Serviços de Atendimento ao Cliente. Ele fornece também aos
gerentes um padrão de tempos de folga e de atraso para certas tarefas intensivas em termos
de recursos. Cada gerente de projetos persona liza o template de acordo com sua iniciativa.
O Te,nplate do Plano de Projeto contém:
• Principais atividades de projetos
• Elementos de plano de projetos (atividades comuns, datas de início e fim, e recursos
designados)
• Marcos de a lto nível
V. VNI.Execução/Controle
As mudanças reais em p rocessos e procedimentos, codificação técnica e ;'corre.ções de cur-
sos" necessárias ocorrem durante as fases de "Execução e Controle". Se for necessária uma
mudança no projeto que esteja relacionada a escopo, prazo o u recursos financeiros, o geren-
te de projetos preenche um formulário de ;'Solicitação de Mudança " (Figura 4- 54). Além
disso, o gerente de projetos fornece um status a cada duas semanas, usado para preenche o
"Quadro de Desempenho do Projeto" (Figura 4-55).
O Quadro de Desempenho do Projeto acompanha:
• Informações do projeto
• Nome e ID do projeto
• Nome do gerente de projetos
• Percentua l concluído
• Conclusão de fase (aprovações nos pontos de decisão)
• Problemas
VI. Encerramento
Durante a fase de "Encerramento" , o gerente de projetos classifica os deliverables reais do
projeto em relação ao plano. O projeto é formalmente fechado quando os a lvos desejados
são atingidos. O gerente de p rojetos conclui o "Relatório de Encerramento do Projeto"
como parte do processo de encerramento.
O Relatório de Encerramento contém:
• Resumo do projeto
• Objetivos alcançados
• Objetivos não alcançados
• Medidas/Métricas
• Lições aprendidas
• Outras ações
Cada fase do Processo Comum de Gestão de Projetos term ina com uma "Ap rovação no
ponto de decisão" pelo patrocinador do projeto. Se aprovado, ele passa forma lmente para
a fase seguinte. Quando apropriado, cada unidade de negócios conco rda em implementar
projetos utilizando essa abordagem com um. Embora o p rocesso seja o mesmo em toda a
DTE Energy, os procedimentos de gestão de projetos são adaptados às necessidades de cada
depa rtamento o u organização específica .
1Dd••.,.d•"- , . _ d• •lmiki•
....... .. ...,,.,..._
•c111~ Sm .._;.e.;o d• •Wd4'11•
'
t..r..d...._ .
lunel'w....
.. ....... ,,,_
,,.,..._ "·-
,,,_ ,,,,.......
21•.-..•
...,.,
~-dk,Jó1 :
AIO)!)
.,..,
_
........ P-• -"""'*"1"11. 9"'-Õl-d•,,.o;-
...,.,_ -oi:,odo ~
. _.
...... ,,,_ .......
,,,_ ,,,,......
,,,_ ,,......
..... .........
C..1,nlr '9CUt- c l o ~ o , - 9C!IOP9
..... ,,,_ ,,,,...... ......

.,.,.
A107'0 Milot0; ,p,w"(l,o no..- do dlocWoo 1
1mm1mmnnmn
fll>ntô dt dilóüo 2' ft
· - . .... ,,,_ ,,.,..._ ,,
,,,_ ,,......
.......
.....
"""
""'
AlllO
o..-.oi-.,._. ........11o....-
" - - ' -ío,n,,Urio d, .-,.:,,,.,,- ela m ~
Mio«l .,.w~ no.,-dodll,w,J,o2 .... ,,,_ ,,,,......

.......
,,..... ,,.....
"--di d,,úw<I 2.2': JII,....,..,
AIIIO
All)O
o.t.,i, ..14'110 . . .,..i,:. dOll p,Ol'.a>-
Gond...,, -IO(M cla 1..:-
- - -ins-g,..._
-
.... ,,,_
""
-
_
,,,_ ,,,,......
.......
,,,_ ,,.......
AlllO
~ d• diio<i... 2.1:
All.-0
o.-..oi- u,ni,.-..ta.,. , , , . _ , _ ~ ~ -
0.....0,.. -.q-- lkn-

,...,MOII..._.e-• n
....... ,,,_
"" ,,,_ ........
,,,,......
.......
.
AIISO
Al\60
tonbde~3t~·~
AUIIO
flniw
0...9n(Tl.l
1Go,,d...,, '""'° ""°' ~

........ ,,,_
,,,_ ,,.......
,,.,..._ ,,.....
,,......
__
AU90
......
1M;oll'.O; •p,w"(l,o
Pot,10 dt CM<iWo 3.5: T-IOGom
no.,- do ..W.O $
..... ,,,,,_ .... ,,.......
_
,,
__ ..
,,.,..._ .......
"°""° •
-
1 1 ~ pl;onodac_,~
e.clr.i,o l i1;
...."''""'"" ......
"°"°"'""''
~''°'"' ,,,.,..._ • •r,o di, <0miniudo ..... ,,,_
..... ,,,_
....... ,,,_
,,......
,,,_ ,,,,.......
,,,_ ,,.......
.......
......
"'"'
-..... ~--~·-·
Pon111ao dKiM035::tc...__d•o,cun~do
..,.,.
O,,..o,;6ft .... (...,.o
.....
1,..,_.,
....... ,,,_ ,,
,,,_ ,,.......
,,,_ ,,.......
,,,_ ,,......
F--'°
Aq~dedldo.
....... ,,,_,,,_ ,,.......
,,......
-
~~-c-..nodot
,,,_ ,,,,......
A.1110
"'"'
.....
"'"" °'*-<'"' •
~ d l ~ l i 2.h(<III -
9io
...... ,,,_
27.J__
.......
,,,,......
,,,_ ,,......
'""
Noliboc«......,
""' F-
Alt SO "'- P•• -
do~ c1o,,...o411,cp,.'°'* 11--d•..ao,.;..,
o SME:<1o.-.io ~ . -... ~e..r...:.w~
............ (ou cc.nu...., ...._,_ P•• ..,.._.Wl'lf t ct. n:io "9nl f t
Al110 ............ 1,.;...- ...... --•e.-
....... ,,,_ ,,
,,,_ ,,......
......
.......
__
_ ,_d.~3.1,~
.....
AIUO O...~...., ~ -
o.....oi-1nOc1ru,
0.....0,..jll, nod,i..,~~
~ """*'.....,'°"' ........... ,,,_
v....__
,,,_ ,,,,......
,,,_ ,,.............
"'°"'"""
""'
""'
°
clt dH.l,il,o 3.2: t •
o...,.o1.,....w illt
fn•••oi-,(Tl.l ........... ,,,_
v ........_ u .........
.,,,_ ,,
,,
.......
......
,,,_ ,,.......
"
""'
""'
Al)41
Go,,d...,, - • - ~p,b .....1no(tA1.A
0.....0,.. Jll•no•-- tAU {c.nl.....
......... qu•io,q- d·-- lNJ .... ,,,_ ,,,_ ,,......
.......
,,,_ ,,,,......
""' A,.u. .w.ilCII. c -1...io..
,_....,if_..._..
....... ,,,_,,.,.,._
Al•lO
AHSO
AH,0
-~-
,i,..c1.~ueon.......
..... F1<1cowod.,..
'*"°
Moei._.,.--- f_...._...o_ .,;,i-6do,no p._

""
....... ,,,_
,,,_ n.-.
,,.......
,,,_ ,,,,......
.......
,,.......
,,,_ ,,,,......
21.J_ _
PO,,io. ~ <11: &,,:. . . .,o111«.,.u\.oob
A1SCO
AISIO
AlUO
o.....oi- Jll•no • ...- .u bliiti.dio ;. """..,...,o)
Go,,d...,, --..o do jlfOjftO . . . . ~
Monit:,,• -111.dh ~ oni:,1-~
.,..IMI' i ~ i.. _
....... ,,,_,,,_ ,,.............
,,,_ ,,,,.......
.......
A1S-> FM•
"91..t.c• • 1....., O._..,_ cb P.»
.......
...... .,,,_ ,,.......
... ,,,_
A1SSO
......... oc1oc:_.,oc1t-,--do ~ ,,.......
,,......
AIS60
A1S80 Milfl'.O. •pW"(lo no..- d• dlicbJo 4tonl'.ll"'° do .-,..O
Figura 4-53 Temptate do plano de projeto.

Gerenciamento do programa de atendimento ao cliente Temp/ate de mudanças no projeto
<data>
1Data de solic itação 1_ 1 Organização
<nome do GP> <data>

Gerente de projetos Ntínero do projeto
<nome do projeto> <data>
Nome do projeto Di retor/Patroci nador
Prioridade Caso de negócio

Alta O Média O Baixa O impactado? Sim O Não O
Necessário refazer
Sim O Não O
linha de base?
Descrever como
essa mudan ça afeta Escopo: n
o er~ eto
Incluir oiçameneo a feladO Prazo: 0
emdólarM
Declara, oomovalorda
lftlClar'IÇa e percet1l'ua1
da l'l'luel'ani;a. se ~it,tet
P,0r e x1M1plo: CuS10 do pioj~ O utro: O

aumetilac50 em x dóla,,es, o
que rep,esetita y por cenlO
do CUSIIO ap,ovado dO prOj"'O.
1 Beneffcio da solicitação ~
de mudanç a
Acomp anhamento de informações - a ser p reenchido pelo Escritório de Gerenciamento de Projetos (PM O)
Analise de impactos Sim u Não u Data de revisão:
adicional - necessária?
Revisor:
Problemas/Preocupações com a solicitação de mudança:
Aprovação pelo p atrocinador - a ser preenchido pelo Escritá io de Gerenciamento de Projetos (PM O)
Aprovada O Rejeitada O 1 Data de aprovação:
Motivo:
Anexos: Favor anexar: (a) estimativa de custos revisada; (b) cronograma proposto, se necessário.
APROVAÇÕES
Patrocinador do projeto Diretor do PMO do SAC
Gerente de projetos
Versão 2 Página 1 de 1
Figura 4-54 Temptate de mudanças no projeto.

l1
i
·111
J•
1!
1 -
1
•!
1t
l
1
!
1
~
·1•. ~ -
-
1
,
;.
Ji jJ - 1~ ,~ ,__
t
•1 1
-
.-
- . ."
. .-
. . .$ _·
,--a~
o
_.. -·-
-- ..-
--.. .,,.,.., ._
-w
.......
"""°pai..
22
4.34 Alstom
Introdu ção
O contexto e o ambiente dos projetos de siste1nas integrados se tornaram cada vez
mais desafiadores devido à sua estr utura globa l e complexa. A integração do projeto
é um processo-chave necessário para auxiliar o a linhamento das partes interessadas e
para gerencia r eficientemente um projeto em várias dimensões. Na gestão de projetos
moderna, essas dimensões incluem, a lém de qualidade, custos e prazos (QCP), aspec-
tos financeiros, ambientais, políticos, de saúde e de segurança.
Metodologia do Ciclo V na gestão de projetos de sistemas

industriais integrados:
O Ciclo V é uma metodologia operacional de integração de projetos. Este capítulo
descreve como essa 1netodologia pode ser aplicada a projetos indust riais complexos e
de grande porte.
Foco no cliente
As metodologias do Ciclo V estão sendo cada vez 1na is empregadas na gestão de pro-
jetos para garantir uma realização eficiente dos projetos. Os setores mi litar e aero-
espacial foram os que iniciara1n a implementação desse modelo de gerenciamento,
construindo complexos sistemas integrados baseados e1n produtos e tecnologias ino-
vadoras.
O ciclo do projeto (ver Figura 4-56) auxilia com o processo de t ransformar os
requisitos do cliente (Entrada) em valoresldeliverables esperados (Saída). Isso corres-
ponde ta1nbém à construção de sistemas integrados no ciclo de projeto de projetos
industria is. Esse ciclo do projeto pode ser sustentado por u1na metodologia do Ciclo V.
A i1nplementação do Ciclo V refo rça o papel do cliente em um ciclo de projeto
ao relembrar continuamente tanto dos requisitos inicia is quanto do valor final espe-
rado. Monitorar pontos de verificação, chamados de pontos de decisão, aumenta a
visibilidade e o envolvimento do cl iente durante a execução e a va lidação do projeto.
Consequentemente, a aplicação da metodologia do Ciclo V ajuda as equipes de proje-
to e as organizações a serem 1na is focalizadas no cliente.
Alinhamento dos ciclos do projeto e do produto

Os passos genéricos do ciclo de desenvolvimento de um produto e as fases genéricas
do ciclo do gerenciamento de u1n projeto são exibidos no Ciclo V (ver Figura 4- 57).
O alinhamento dos ciclos, passos e fases garante u1na execução controlada do projeto.
Portanto, o Ciclo V auxi lia as partes interessadas do projeto e os gerentes de projetos a
ter u1na compreensão comum das vá rias etapas de seus projetos e dos principais pon-
tos de verificação para aval iar seu progresso físico, riscos e deliverables.
Monitorando marcos e datas importantes

Os marcos e as datas importantes de projetos industriais geralmente estão relaciona-
dos aos principa is eventos do projeto, como a ordem de prosseguimento (NTP, notice
to proceed), ent rega no loca l, início do serviço gerador de receitas ou operações co-
21
© 2013 by Alsrom. Reproduzido com permissão. Todos os di reitos reservados. M.arerial fornecido por
Lahcen Zeggoud~gerente de programas do Grupo Alsrom.
Ciclo do projeto
Entrada Salda do ciclo do Salda (valor
(requlsílos projeto = Entrada x esperado pelo
do cliente) Processo de Transformação cliente)
Ciclo V
Processo de transformação (valor agregado peloprovedor)
Figura 4-56 O Ciclo V é um processo de cliente-a-cliente (C2C).
Fases do ciclo do proJeto

Iniciação Execução Validação Entrega
Passos dos
ciclos do
produto
Linha de tempo do proJeto

M1: Iniciodo design; M2: Iniciodas aqulslçGestmanufalura; M3: Inicio da montagem;
M4: Iniciodos testes; M5: Inicioda entrega; M6: Encerramento
Figura 4-57 Alinhamento da Fase de Gestão de Projeto e os passos do produto.
merciais, mas também pode estar relacionado ao progresso físico, como validação do
design, aprovação dos principais ped idos de cotnpra, aceitação de relatórios de testes
de fá brica. Alguns desses marcos e datas importantes são usados pa ra decla ra r receitas
o u, como marcos de pagamentos junto a clientes ou fornecedores.
Os marcos M1 a M6, 1nost rados na Figura 4-57, correspondem a eventos cruciais
nos qua is decisões-chave precisam ser tomadas. Esses marcos geral mente são incl uídos
no caminho crítico do projeto . O 1nonitora 1nento de marcos do Ciclo V melhora a
solidez e a consistência do progresso físico.
Revisões de passagem de fases nos pontos de decisão

Os pontos de passagem de fases do Ciclo V representa tn pontos de verificação pa ra ava-
liar o progresso do projeto. Isso é n1ostrado na Figu ra 4-58. Esses pontos são in1plemen-
tados por n1eio de revisões forn1ais do projeto, con1 a participação das principa is partes
interessadas. Eles são mon itorados por un1 comitê de decisão independente (assessores)
que deciden1 sobre se o projeto deve Continuar/Não Continuar. Para maior transparên-
Iniciação Execução Valldação Entrega
LEGENDA·
RPFEsp Seis pontos RPFV RPfEsp: revtslo de passagem ele 1-a.se
de decisão de especmcaço.es
RPfP: revisão de passagem de ta.se
RPFP prellmlnar
RPfC: revisão de passagem de fase crfllca
RPFQ RPfO: revisão de p:a.ssagem de fase de
qu:alldade
RP C RPfV: revisão de passagem de ta.se de
valldação
RPfEnc: revlslo de passagem ele 1-a.se
de encerramento
M1 M2 M3 M4 MS M6
Figura 4-58 O Ciclo V introduz pontos de decisão em eventos-chave do projeto.
eia e alinhamento das principais partes interessadas, o processo de revisão de passagem

de fase nos pontos de decisão geraln1ente é aberto para partes interessadas externas.
As revisões de passagem de fases usam o processo de gestão de riscos por meio da
avaliação de todas as atividades do projeto, seguindo listas de verificação. Os riscos ou
deliverables cruciais de u1n ponto de decisão são avaliados por perguntas "OK?"; se
declarado " não OK", será decidido "Não Continuar" no ponto de decisão.
Tecnologia e riscos de "congelamento'' de produtos

O Ciclo V pode ser aplicado a ciclos de tecnologia, produtos e siste1nas. Um Ciclo V de
tecnologia tennina quando a tecnologia é integralmente va lidada e está madura para
ser usada em um produto. Um Ciclo V de produto termina quando o produto é inte-
gralmente val idado e está maduro para ser usado em um ciclo de sistema integrado.
Tanto os ciclos de tecnologia quanto os de produtos são gerenciados, de maneira gera l,
como parte de projetos ou programas de P&D. Ver Figura 4-59.
O "congelan1ento" (a parte superior da Figura 4-59) de u1na tecnologia ou de um
produto é considerado o encerramento do ciclo. Esse encerramento especifica e valida o
nível de desetnpenho, os custos, e os litn ites de implen1entação, alé1n dos riscos associados
à tecnologia ou ao produto. Esse "congelamento" é, portanto, uma decisão crucial para
que se realize tun projeto de sistema controlado. De modo geral, a falta de encerramento
no ciclo de uma tecnologia ou produto introduz un1 alto nível de incertezas na defin ição
do escopo, na linha do tetnpo e na gestão de riscos de projetos de sistemas.
A ma ioria dos projetos ou programas de sistemas integrados industriais que uti-
lizam tecnologias ou produtos não maduros e não "congelados" (a parte inferior da
Figura 4-59) se encont ram fora de controle do ponto de vista do planejamento, custos
e r iscos. Suas linhas de base são difíceis de estabelecer e validar pelas partes interessa-
das durante a fase de iniciação do projeto. Além disso, a consequência é que ocorre1n
margens ou atrasos no cronograma, o que leva a quebras dos direitos contratuais e
disputas entre partes interessadas. Em alguns casos, essas d isputas só podem ser resol-
vidas por meio de arbitragem ou de rescisão do cont rato.
Sincronização dos pontos de decisão

O gerenciamento de interfaces é um dos principa is desafios do gerenciamento da
integração de projetos. Em projetos grandes e complexos, normalmente várias in-
terfaces precisan1 ser gerenciadas devido ao grande número de pacotes de trabalho
alocados às partes interessadas do p ro jeto. Uma sincronização "de cima para baixo"
se aplica aos po ntos de decisão de especificações/requ isitos (lado esquerdo do Ciclo
V) e un1a abordagem " de ba ixo para cin1a " se ap lica aos pontos de decisão de mon-
tagem e validação (lado d ireito do Ciclo V). As especificações do projeto precisan1
ser "congeladas" com o cliente em uma revisão de passagem de fase de especificações
(RPFEsp) a ntes de "congelar" as especificações do pacote de traba lho com as partes
interessadas (RPFEsp-sub). O pacote de trabalho do subsistem a é validado (RPFVa l-
Ciclos de tecnologia, produto e sistema
"Congelar" " Congelar"
Ciclo do sistema
(projeto)
Atransição entre os Ciclos V devem ter um "congelamento" de maturidade
Tecnologia Produto
"não congelada" "não congelado"
Ciclo de tecnologia 1Ciclo do produto I Ciclo do sistema

(projeto)
Superposições dos Ciclos V levando à Instabilidade no projeto
Figura 4-59 Ciclos d e tecnologia, produto e sistema.
RPFVal-p
RPFEsp-p
Projeto
(sistema)
RPFVal-sub
RPFEsp-sub Pacote de trabalho
(subsistema)
RPFVal-comp
Pacote de trabalho
RPFEsp-comp (componente
Figura 4-60 Processo de sincronização dos Ciclos V por meio do alinhamento de pontos
de decisão.
-sub) antes de sua integração ao projeto de sistema e de sua validação (RPFVal-p).

(Ver Figura 4-60.)
A sincronização dos pontos de decisão dos Ciclos V pennitem o alinhamento das
partes interessadas em termos do progresso físico e do gerenciamento de interfaces e1n
todas as etapas do projeto.
4.35 Cassidian: regras áureas para a gestão

de projetos 23
Todas as empresas discutidas neste capítulo possuem excelentes metodologias de ges-
tão de projetos. Quando uma empresa e.apta as 1nelhores práticas nessa área e as rela-
cionam à metodologia, a e1npresa pode desenvolver suas "regras áureas para a gestão
de projetos" . O restante desta seção foi fornecido pela Cassidian. A Cassidian oferece
excelentes exemplos de como a gestão de projetos deve funcionar para os benefícios
e o va lor a serem alcançados. Este material também é representativo de qual pode ser
o resultado da jornada ru1no à excelência em gestão de projetos, como discutido no
Capítulo 3.
Por que adotar regras áureas para a gestão de projetos?

As regras áureas para a gestão de projetos são o elemento de a lto nível do gerencia-
n1ento de programas ao longo do ciclo de vida do projeto. Elas são desenvo lvidas
com a exigência de serem faci ln1ente compreensíveis e apl icáveis a todos os proje-
tos/progran1as. Ter regras áureas para a gestão de projetos fornece um conjunto de
regras que são comuns a todos os projetos e programas. Elas forn1an1 um corpo
regu lamentar que deve ser seguido sen1 exceções e são escritas de ta l forma que
possam ser adequadas tanto para os projetos ext ren1amente con1p le.xos, de a lto vo-
lume e a lto risco quanto para os projetos de baixo orçamento e recursos limitados.
Elas descrevem as principais áreas em que todos os projetos precisam alcançar o
mesmo nível de desempenho a fim de au1nentar a qual idade dos projetos/progra1nas.
Seguir essas regras provavelmente levará a um padrão de qua lidade básico comu tn
que, no fim das contas, ajudará a evitar qualquer deficiência ma is séria.
Fina lmente, essas regras áureas deve1n ajudar a aumentar a excelência geral do
projeto/programa no que diz respeito aos requisitos de "prazos - custos - qualidade" e
são a "espinha dorsa l" do processo de "gestão de programas e projetos".
Regras áureas para a gestão de projetos

Regra áurea : O gerente de projetos é integra lmente responsável pelo projeto em ter-
mos de custos, fluxo de caixa, prazos e qualidade (como indicado pelo Termo de aber-
tura do Projeto) e é ativamente apoiado por seu patrocinador na gerência de área.
Objetivo: Empoderamento do gerente de projetos e definição clara das respon-
sabilidades dentro da proposta e da equipe de execução em relação a outras áreas
funcionais, mas também a obrigação do gerente de projetos de cumprir com suas res-
ponsabi lidades.
2J © 20 13 by Cassidian. Reproduz.ido com permjssão. Todos os direitos rf"servados.

Regra áurea: u1n gerente de projetos adequadamente qualificado deve ser designa-
do pela organ ização e ser ativamente envolvido durante a preparação da proposta e a
negociação do contrato.
Objetivo: Estimular a cooperação ativa dos responsáveis pela proposta e pela exe-
cução do projeto, a fim de aumentar a transparência e a t ransferência sem perdas da
fase de in iciação à fase de p lanejamento.
Regra áurea : A responsabilidade pela gestão de projetos, baseada nas linhas de
base relacionadas no cont rato e no termo de abertura do projeto (p .ex.: custo, escopo
e cronograma, acordos de pré-financiamento, classificação final do projeto), deve ser
passada adiante oficialmente da equipe de negociações à equipe do projeto dentro de,
no máximo, 10 dias úteis após a assinatura do cont rato.
Obj etivo: Transferência rápida, conjunto completo de documentos d isponíveis,
objetivo de longo prazo é um período de tempo fixo. Estando dentro desses 1O dias,
fica provado que a equipe de proposta forneceu u1na qual idade adequada.
Regra áurea: O gerente de projetos estabelecerá um p lano de projeto integrado
formal, real ista e mensurável durante a fase de planejamento de projeto, até no má-
x imo t rês meses após a assinatura do contrato. Uma linha de base de mensuração do
desempenho (custos, escopo e cronograma ) será estabelecida, em relação à qual o
progresso do projeto será 1ned ido e registrado e1n relatórios mensais.
Objetivo: Garantir o p lanejamento integrado incluindo o cronograma do projeto,
marcos importantes e marcos menores, marcos/depedências, planejamento de custos,
p lanejamento de recursos e linhas de base. Estabelecer o gerenciamento de va lor agre-
gado como a base para 1non itorar e acompanhar o planejamento do projeto baseado
e1n uma linha de base inicia l.
Regra Áurea: O gerente de proposta (antes da assinatura do contrato) e, poste-
riormente, o gerente de projetos (na execução do projeto) é proprietário dos riscos
e oportunidades do projeto e garante que eles sejam gerenciados proativamente. o
engenheiro-chefe oferece suporte a essa tarefa assum indo responsabi lidade pelos riscos
e oportunidades técnicas.
Objetivo: Garantir o gerencia1nento adequado de r iscos e oportun idades dentro
dos projetos seguindo as regras e regulamentações definidas na iniciação do projeto.
Regra á urea: o escopo e os objetivos do projeto deven1 ser gerenciados con1
foco nos requ isitos dos clientes, e um gerenciamento de requ isitos ded icado deve
ser estabelecido a fim de evitar mudanças no escopo. Além disso, a gestão de mu-
danças e configurações deve estar totalmente en1 funcionamento antes da execução
do projeto.
Objetivo: Aumentar o gerenciamento de requ isitos para evitar produtos de qual i-
dade enganosa e não conformidades. É necessário um forte foco sobre os requisitos do
cliente além da defin ição do escopo e objetivos do projeto ao longo de todo o seu ciclo
de vida. Aumentar a aceitação dos requ isitos do projeto pelo cliente desde o início
para evitar futuros mal-entendidos.
Regra áur ea: O gerente de projetos estabelecerá comunicações (forma lizadas do
Plano de Co1nunicação do Projeto) para facilitar o trabalho como uma equipe de pro-
jeto integrada e garantir u1n ótimo fluxo de informações dentro da equipe.
Objetivo: Todos os membros da equipe do projeto conhecem seus meios de comu-
nicação e suas interfaces internas ou externas. Os relatórios são claramente estabeleci-
dos e de fáci l acesso a qualquer parte interessada no projeto.
4.36 Quando metodologias trad icionais talvez

não funcionem
En1bora as n1ecodologias sirvam a uma finalidade viável, as metodologias tradicio-
nais podem não funcionar bem quando os projetos enfrentam problemas e são ne-
cessárias ações rápidas para salvar um projeto que está em vias de fracassar. Nesse
caso, outr os fatores podem ser n1ais importantes do que seguir as fases tradicionais
do ciclo de vida.
Ideias sobre a recuperação de projetos e programas problemáticos

Os projetos e programas de hoje em dia se tornaram cão complexos que, no dia a dia,
técn icas eficientes de recuperação de projetos podem ser necessárias independente-
mente do país em que você se encontra ou da base de negócios de sua empresa. Pre-
cisa1nos estar dispostos a enfrentar situações diferentes ou imprevistas que não estão
relacionadas à cidadania, à língua que fa lamos ou às experiências que todos temos.
Somos afetados por uma enorme quantidade de riscos internos e externos que podetn
se tornar verdadeiros problemas durante a execução de u1n projeto.
Abaixo, veremos algumas ideias do Dr. Alexandre Si:irensen Ghisolfi, que, por
muitos anos, colaborou com o Internacional Inscicuce for Learning e enfrentou esses
desafios na comunidade global de gestão de projetos. A seguir, temos algumas de suas
melhores práticas e a lgumas reflexões.
A recuperação de projetos pode ser uma fonte de muitas ideias e lições aprendidas.
Quando os projetos precisa1n ser recuperados, eles norma lmente são acompanhados
de conflitos, desacordos e até mesmo brigas.
Quando os projetos estão enfrentado problemas, você provavelmente verá me-
lhor que1n as pessoas realmente são e se elas têm um verdadeiro compro1nisso com a
organização. Quer dizer, quando as coisas vão bem, é fáci l ver sorrisos e gera lmente
conhecemos o melhor lado das pessoas. Quando as coisas vão mal, normalmente surge
um indivíduo diferente.
Nesse tipo de ambiente, aprende1nos que, para ser bem-sucedida, a recuperação
gerahnente exige uma equipe de especialistas e u1na liderança eficiente em gestão de
projetos. Ne1n todos os gerentes de projetos possuem habilidades e1n técnicas de recu-
peração para gestão de projetos. A confiança canto no gerente de projetos quanto na
solução é provavelmente o critério mais importante para que a recuperação funcione.
Além disso, normahnente é essencia l que se tenha1n equipes de gestão de projeto de-
dicadas.
Quando as condições indicam que o fracasso pode estar iminente, devemos ser
capazes de claramente 1nudar os aspectos culturais nos quais sentimentos ruins pode1n
e irão surgir. Dessa forma, calvez sejamos capazes de conseguir criar uma nova cultura
que leve à recuperação.
As equipes de recuperação em gestão de projetos são compostas de pessoal mais
experiente, especia listas profissiona is, jovens com novas ideias, novos talentos que
reconhecem que o sucesso da recuperação pode beneficiar seus objetivos de carreira,
e gerentes de recuperação de projetos que tenham habi lidades de liderança. Todos eles
têm de t raba lhar juntos para que possamos transformar um ambiente com sentimen-
tos ruins em um ambiente no qual as pessoas acredita tn que ainda podemos colocar o
projeto de volta no ca1n inho cerco e entregar o que é preciso. Se a equipe tiver êxito,
isso irá, ainda mais, deixá-la orgulhosa de suas rea lizações, o que pode desenvolver u1n
grande sentimento de adesão que permanecerá por toda a vida.
Durante a recuperação, devemos considerar dois ambientes diferentes:

• O comportamento humano
• A aplicação de experiência técnica
O comportamento humano
Cada projeto que está enfrentando dificu ldades possui cenários e alternativas muito
d iferentes. O processo de recuperação depende de sua experiência e capacidade de
encont rar soluções. Depende tan1bén1 de seu grau de influência sobre as d iferen-
tes partes interessadas pa ra fazê-las chega r a um acordo quanto a un1a visão na
qual todas reconhecem que o "jogo" pode ser vencido. Para soluções bem-sucedidas
baseadas nas diferentes contr ibu ições dos n1embros de equipe, o gerente de projetos
p recisa saber como extr air o n1elhor deles ou influenciá-los a a lcançar o que é espe-
rado pelo líder.
No entanto, antes de você começar a identificar e avaliar d iferentes alternativas,
seria bom considerar alguns diferentes aspectos relacionados ao comportamento hu-
mano que influencia1n fortemente o resultado. Para simplificar, não fala remos sobre
politicagem, hierarquia, conhecimento ou outros aspectos que influencia1n o compor-
tamento humano, mas sugerimos que você pelo menos compreenda clara1nente que
tipo de empresa e equipe você possui. Podemos tentar compreendê-las por meio do
estudo da maturidade organizacional.
Você possui uma equipe madura? A empresa é igualmente madura em gestão de
projetos?
Algumas melhores práticas que voc ê deve sempre tentar c olocar em prática:
• A maturidade organizacional de un1a emp resa e/ou equ ipe afeta diretamente
os resultados, então, quanto n1ais n1adura e profissional for sua equipe, n1e-
lhor será sua capacidade de recuperar programas em vias de fracassar. A me-
lhor p rática é primeiro analisar profundamente a maturidade da empresa e dos
n1en1bros da equ ipe de projetos; com os resultados em mãos, você será capaz de
identificar lacunas, prob lemas e condições que talvez exijam mudanças. Após a
análise, e con1 o relatório de maturidade nas n1ãos, será necessário preparar un1
plano de recuperação e n1ostrar aos patrocinadores do p rojeto uma justificativa
que prove por que algun1as p rovidências importantes deven1 ser tomadas urgen-
ten1ente. Ao trabalhar em o rgan izações n1atricia is, podemos enfrentar dificul-
dades importantes en1 termos de recu rsos que não fazem parte d iretamente de
nossa estrutura organizacional de projetos e que poden1 ter diferentes interesses
no resu ltado do projeto.
Outras melhores práticas certamente seriam:

• Le1nbrar as pessoas sobre a necessidade de mudanças. Se necessário, lembre1nos as
pessoas todos os dias sobre nossa missão e nossas tarefas diárias.
• Oferecer t reina1nento para as pessoas de acordo co1n a necessidade e agir como
um modelo para as atitudes que são necessárias. Essa é provavehnente a mel hor
maneira de melhorar a maturidade da equipe e da organização.
• Empoderar os membros de equipe; tornar deles o nosso desafio.
• Certificar-se de que toda a equipe tenha um comprometimento profundo com o
desafio de t razer os bons resultados de volta.
Garantir que os processos de comunicação sejam eficientes. Você pode comunicar
menos ou ainda ma is, mas, no final das contas, a comunicação precisa ser eficiente.
Depende, mais uma vez, da maturidade de sua empresa e da equipe e de seu grau de
compromisso cotn o projeto. Membros de equipe realmente comprometidos se foca li-
zam na comunicação. A co1nunicação tem de fluir naturahnente.
Ao fa lar sobre processos e trabalho, a flexibil idade é importante. Por outro lado, é
preciso haver discipl ina para realizar as principa is atividades. Novatnente, a estrutura
da equipe organizacional, seus departamentos e os interesses dos fornecedores podetn
ter um enorme impacto para que ocorram coisas boas ou ru ins.
O comportamento humano é provavelmente mais desafiador do que a aplicação
na experiência técn ica necessária.
O estudo da maturidade da organização e da equipe pode apontar para uma for-
ma mais segura de proceder. Como um desempenho mais rápido e melhor deve ser
implementado com rapidez, você não pode falhar novamente; as ações precisam ser
eficientes.
Aplicação da experiência técnica

Do lado técnico, ao recuperar projetos, pode ser ainda mais importante conhecer ou
definir claramente quais são suas prioridades.
Você provavelmente enfatizará os critérios de qualidade (i.e., critérios de quali-
dade para aceitação) dos produtos que você precisa ent regar; sem dúvida, você não
pode sacrificar a qual idade. O equi líbrio das restrições dependerá de sua capacidade
de negociação, a lém das condições contratuais que você possa ter com seus clientes.
Ta lvez você não seja capaz de ent regar tudo o que é determ inado pelo projeto,
porque há que se fazer sacrifícios. Ta lvez você entregue resultados d iferentes etn re-
lação às linhas de base do projeto. Um plano de recuperaç.ã o precisa entrar etn vigor
imediatamente.
O que sacrificar? Custos? Os custos do projeto? Os custos de produtos? Prazos?
As especificações? Estratégias de mudança na entrega de produtos/projetos? A co1nu-
nicaç.ã o? A documentação, as apresentações?
Muitos fatores podem afetar sign ificativa 1nente o sucesso e au1nentar os proble-
mas quando se enfrenta projetos problemáticos. Aqui há algumas out ras melhores
práticas que você pode tentar imple1nentar:
• Você provavelmente terá certeza de que a ênfase na gestão de riscos é uma con-
dição necessária. Em projetos problemáticos, ela se torna a inda mais Ítnportante.
Quando você estimula a equipe a seguir um plano direcionado pela gestão de
r iscos, a equipe já está definindo prioridades, que são os resultados da anál ise de
r isco. A gestão de riscos, como uma visão holística, pode impulsionar tudo mais
que está à sua volta, como escopo, prazos, organização da equipe, habi lidades,
comunicações, etc.
• Coloque as melhores pessoas que você tetn nas atividades mais difíceis prÍtneiro.
• Enfatize as atividades cruciais para encu rtar suas respectivas durações.
• Evite trazer novas pessoas que não tenham experiência suficiente para o projeto;
por outro lado, você pode trazer novas pessoas para o projeto quando precisar
mudar aspectos cu lturais e/ou interesses em vigor.
• Evite o co,ú lito de interesses; não podemos perder tempo ou desperdiçar recursos
resolvendo problemas desnecessários. Trabalhe a inda ma is pesado com seu patro-
cinador para conseguir seu apoio.
• A adaptação das melhores práticas disponíveis no cenário do projeto também é
um assunto-chave. Você tem de encontrar uma maneira, gera lmente "pensando
diferente", de fazer sua equipe real izar coisas que possivelmente ela jamais teria
colocado em prática antes. Desafie os membros de sua equipe; peça-lhes sua opi-
nião e pergunte como vocês poderiam começar a t rabalhar de formas diferentes.
Dessa forma, você estará desenvolvendo o sentimento de adesão.
• Você provavelmente está procurando vitórias imediatas, mas logo perceberá que
algumas melhores práticas que a equipe tentou aplicar foram úteis, enquanto ou-
tras não foram muito bem recebidas. Substitua ou adote melhores práticas que
nunca foram adotadas e que não necessaria1nente sejam aplicáveis ao seu projeto
por outras com as quais você possa ter resu ltados satisfatórios rapidamente. A
rápida identificação do que está funcionando e do que não está dando muito certo
é essencial para recuperar o tempo perd ido.
A recuperação bem-sucedida de projetos ruins pode ser uma experiência incrível,
e, quando você possu i uma equipe que tem a mental idade adequada, ela pode con-
tribu ir significativamente com o aumento da maturidade da empresa e da equipe de
projetos. Pode1n -se alcançar excelentes resultados em futuros projetos evitando que
eles entrem em situações críticas que possam levar ao fracasso.
Processos integrados
5.0 Introdução
As empresas que se tornaram extremamente bem-suced idas em gestão de projetos o
fizeram utilizando um planejamento estratégico. Essas empresas não cree1n que o im-
portante é competir; optam por superar o desempenho de suas concorrentes. Fazer
isso continua1nente exige processos e metodologias que promovam o sucesso cont í-
nuo, e não apenas esporádico.
A Figura 5-1 mostra o hexágono da excelência. Os seis componentes identifica-
dos no hexágono são as áreas e1n que as empresas excelentes em gestão de projetos
superam suas concorrentes. Cada uma dessas áreas será discut ida nos Capítulos 5-10.
Começaremos com os processos integrados.
5.1 Compreendendo os processos integrados

de gerenciamento
Como discutimos no Capítulo 1, desde 1985 vários novos processos de gerencia1nento
(p.ex.: engenharia simultânea) oferecera1n suporte à aceitação da gestão de projetos.
Os ma is i1nportantes processos de gerenciamento complementares e os anos e1n que
foram intoduzidos estão listados a segui r:
Excelência
Gestão
informal de
projetos
Figura 5-1 Seis componentes da excelência. Fonte: Reimpresso de H. Kerzner: ln Search of Exce-
lence in Project Management, Hoboken, NJ: Wiley, 1998, p. 14.
• 1985: Gestão da qualidade tota l (TQM, total quality managetnent)

• 1990: Engenharia simultânea
• 1992: Empoderamento dos funcionários e equipes autodirigidas
• 1993: Reengenharia
• 1994: Custeio do ciclo de vida
• 1995: Gerencia1nento de mudanças
• 1996: Gestão de riscos
• 1997: 1998: Escritórios de gestão de projetos e cent ros de excelência
• 1999: Equipes co-localizadas
• 2000: Equipes multinacionais
• 2001: Modelos de maturidade
• 2002: Planejamento estratégico para a gestão de projetos
• 2003: Relatórios de status via int ranet
• 2004: Modelos de planejamento de capacidade
• 2005: Integração do Seis Sigma à gestão de projetos
• 2006: Gestão de projetos com equipes virtuais
• 2007: Gestão de projetos enxuta/ágil
• 2008: Bibliotecas de melhores práticas
• 2009: Certificação do processo de negócio de gestão de projetos
• 2010: Gestão de projetos complexos
• 2011: Govemança por com itês
• 2012: Restr ições à concorrência usando um componente de va lor
• 2013: Avanços no gerenciamento de mét ricas
A integração da gestão de projetos co1n esses outr os processos de gerencia1nento é
essencial para se alcançar uma excelência sustentável. Nem toda empresa usa todos os
processos o tetnpo inteiro. As empresas escolhem os processos que funciona1n mel hor
para elas. Entretanto, qua isquer que sejam os processos selecionados, eles são combi-
nados e integrados à metodologia de gestão de projetos. Anteriormente, afirmamos
que as empresas com metodologias de classe mundial tentam empregar uma única
metodologia-padrão baseada em processos integrados. Isso inclui processos de negó-
cios, além de processos relacionados à gestão de projetos.
A capacidade de integrar processos baseia-se em que processos a empresa decide
implementar. Por exemplo, se uma empresa implementou u1n modelo de pontos de
decisão de final de fase para a gestão de projetos, talvez ache fácil integrar novos pro-
cessos como a engen haria simultânea. A única precondição seria que eles não fossem
t ratados como funções independentes, mas projetados desde o início co1no pa rte de
u1n sistema de gestão de projetos que já estivesse em vigor. O modelo de quatro fases
utilizado pelo General Motors Pov,rertr ain Group e o modelo PROPS utilizado na
Ericsson Telecom AB permitem a assim ilaç.ã o itnediata de novos processos de negócio
e de gerenciamento.
Anteriormente, afirmamos que, hoje, os gerentes de projetos são vistos como ge-
rentes de parte de um negócio e1n vez de apenas de um projeto. Portanto, eles precisam
compreender o negócio e os processos que oferecem suporte ao negócio, a lém dos
processos que oferecem suporte ao projeto. Empresas como a Visteon e a Johnson
Cont rols compreendetn isso muito bem e têm processos de negócios integrados à me-
todologia de gestão de projetos ou concomitantes a ela.
Este capítulo discute cada um dos processos de gerenciamento listados e como eles
cont ribuem com o aprimoramento da gestão de projetos. Depois, uti lizando estudos
de casos reais, veremos como a lguns dos processos de gerenciamento integrado alcan-
ça ra1n o sucesso.
5.2 Evolução de processos complementares

Desde 1985, diversos novos processos de gerenciamento se desenvolveram e1n paralelo
à gestão de projetos. Destes, a TQM e a engenharia simu ltânea são os 1nais relevantes.
As empresas que alcançam a excelência são aquelas que mais rapidamente reconhece1n
a sinergia entre as muitas opções de gerenciamento hoje disponíveis. As empresas que
alcançam a maturidade e a excelência mais rapidamente são aquelas que reconhece1n
que certos processos alimentam uns aos outros. Como exemplo, considere os assuntos
listados a seguir. Esses sete conceitos fazem parte de uma metodologia de gestão de
projetos?
• Traba lho em equipe
• Integração est ratégica
• Melhoria contínua
• Respeito pelas pessoas
• Foco no cliente
• Gerenciamento baseado em evidências
• Sol uç.ã o de problemas est ruturada
Esses conceitos formam, na verdade, a base do processo de TQM da Sprint. Eles
poderiam facilmente ser diferentes facetas de uma metodologia de gestão de projetos.
Durante a década de 1990, a Kodak min istrou um curso intitulado Liderança em
Qualidade (Qttality Leadership). Os cinco princípios do programa de liderança e1n
qua lidade da Kodak incluía1n:
Foco no cliente
"Priorizaremos nossos clientes, tanto internos quanto externos, cujas infor-
mações impulsionam o projeto de produtos e serviços. A qual idade de nossos pro-
dutos e serviços é determinada exclusivamente por esses clientes."
Liderança no gerenciamento
"Demonst raremos, em todos os níveis, uma liderança visível no gerenciamen-
to segundo esses princípios."
Trabalho em equ ipe
"Trabalharemos juntos, combinando nossas ideias e habilidades para melho-
rar a qua lidade de nosso t rabalho. Reforçaremos e recompensaremos quaisquer
contribuições para a melhoria da qual idade."
Abordagen1 analítica
"Utilizaremos 1nétodos estatísticos para controlar e aprimorar nossos proces-
sos. Análises baseadas em dados orientarão nossas decisões."
Melhoria contínua
"Buscaremos ativamente a melhoria da qualidade por meio de um ciclo contí-
nuo que foca planejamento, in1plementação e verificação das melhorias nos processos
centra is."
A Figura 5- 2 most ra o que acontece quando uma organizaç.â o não integra seus
processos. O resu ltado são processos tota lmente desacoplados. As e1npresas co1n me-
todologias separadas para cada processo podem acabar com a dupl icação de esforços,
possivelmente com a duplicação de recursos e até mesmo com a duplicação de insta-
lações. Embora haja vários processos na Figura 5- 2, analisaremos apenas a gestão de

projetos, a TQM e a engenharia simultânea.
Quando as empresas começam a reconhecer os efeitos sinérgicos de colocar vá-
rios desses processos sob un1a única n1etodologia, os dois prin1eiros processos a se
tornarem parcialmente acoplados são a gestão de projetos e a TQM, con10 n1ostra a
Figura 5- 3. À med ida que os benefícios da sinergia e da integração vão se tornando
aparentes, as organizações optam por integrar todos esses processos, con10 n1ostra a
Figura 5-4.
Empresas excelentes são capazes de reconhecer a necessidade de novos proces-
sos e de integrá-los rapidamente às estruturas de gerenciamento existentes. Durante o
início da década de 1990, enfatizou-se a integração da gestão de projetos à TQM e à
engenharia simultânea. Desde meados da década de 1990, dois out ros processos tam-
bém passaram a ser importantes: a gestão de riscos e o gerenciamento de mudanças.
Nenhum deles é novo; é a ênfase que é nova.
Durante o fim da década de 1990, $teve Gregerson, antigo vice-presidente de de-
senvolvimento de produtos na Metzeler Automotive Profile System, descreveu os pro-
1
cessos integrados em sua metodologia:
Processos do
Guia PMBO/('
Gestão de
projetos l Gestão da
qualidade total
Figura 5-2 Processos totalmente desacoplados.
Gestão de Gestão da
projetos qualidade total
Engenharia Outros
simultânea processos
Figura 5-3 Processos parcialmente integrados.
1
H. Kerzner, Advanced Project Management: Best pracr;ces 0 11 lmplementation, Hoboken, NJ: \Viley, 2000,
p. 188.
Gestão de Gestão da
projetos qualidade total
Engenharia Outros processos

simultânea
Figura 5-4 Processos totalmente integrados.
Nossa organização desenvolveu uma metodologia-padrão baseada em melho res práticas

g lobais e em requisitos e expectativas d os cl ientes. Essa metodologia também c umpre as
exigências do ISO 9000. Nosso processo incorpora sete gatewttys q ue exigem de/iverables
específicos listados em uma única folha de papel. Alguns desses deliverables possuem um
procedimento e, em muitos casos, um formato definido. Essas diretrizes, listas de verifica-
ção, formulários e procedimentos são o elemento central de nossa estrutura de gestão de
projetos e servem também para captar as lições aprendidas para o programa seguinte. Essa
metodologia é incorporada a todos os aspectos de nossos sistemas de negócios, incluindo
gestão de riscos, engenha ria simultânea, planejamento avançado da qualidade, a nálise de
viabilidade, processo de revisão de design, entre o utros.
Claramente, Metzeler vê a integração e a compatibi lidade dos sistemas de gestão
de projetos e dos sistemas de negócios. Um outro exemplo de processos integrados é a
metodologia empregada pela Nortel. Durante o fi nal da década de 1990, Bob Mans-
bridge, então vice-presidente de gerenciamento da cadeia de suprimentos da Norte)
Networks, acreditava que:2
A gestão de projetos da Nortel Networks é integrada à cadeia de suprimentos. O papel da
gestão de projetos hoje é compreendido como uma série de processos integrados dentro da
cadeia de suprimentos total. A TQM na Norte) Networks é definida por métricas chama-
das de pipeline m etrics. Essas métricas resultaram do cliente e de visões externas do que
seria m as melhores realizações "de sua classe". Tais métricas são estratificadas e fornecem
indicadores conectados tanto para o nível executivo quanto para o nível dos trabalhadores.
O papel do gerente de projetos é trabalha r com todas as áreas da cadeia de suprimentos e
otimizar os resultados para o benefício do projeto em questão. Com um processo-padrão
implementado globalmente, incluindo a revisão mensal das pipeline metrics pela gestão de
projetos e pelas unidades de negócios, a implementação das " melhores p ráticas" torna-se
mais controlada, mensurável e significativa.
A importância de integrar a gestão de riscos está fi nal mente sendo recon hecida.
Segundo Frank T. Anbari, professor de gestão de projetos da Drexel University:
Por definição, projetos são empreendimentos arriscados. Eles pretendem criar produtos,
serviços e processos novos e exclusivos que não existiam no passado. Portanto, a gestão
cuidadosa dos riscos dos projetos é imperativa para que o sucesso seja repetível. Nlétodos
quantitativos desempenham um importante papel na gestão de riscos. Não existe substituto
para o conhecimento profundo dessas ferramentas.
Durante décadas, a gestão de riscos fo i prioridade entre as organizações do ramo
da saúde, por 1notivos ó bvios, além de entre instituições fina nceiras e escritórios de
advocacia. Hoje, em organizações de todos os tipos, a gestão de riscos evita que pos-
terguemos nossos problemas na esperança de encontrar uma sol ução fáci l mais adia n-
2
lbid.
Gerenciamento de projetos
Gestão Gestão da
de riscos qualidade total
Gerenciamento Engenharia
de mudanças simultânea
Figura 5- 5 Processos integrados para o século XXI.
te ou de que o proble1na simplesmente desapareça sozinho. O gerencia1nento de mu-

danças co1no um complemento à gestão de projetos é usado para cont rolar os efeitos
adversos das mudanças no escopo: aumentos nos custos (às vezes o dobro ou o t riplo
do orçamento original) e atrasos nos cronogramas. Com processos de gerenciamento
de mudanças em vigor como parte do sistema geral de gestão de projetos, as mudanças
no escopo do projeto original podem ser tratadas como projetos ou subprojetos sepa-
rados, de modo que os objetivos do projeto origina l não se percam.
Hoje, empresas excelentes integram cinco principa is processos de gerenciamento
(ver Figura 5-5):
• Gestão de projetos
• Gestão da qualidade total
• Gestão de riscos
• Engenharia simultânea
• Gerencia1nento de mudanças
Equ ipes de trabalho autogerenciadas, empoderamento dos funcionários, reenge-
nharia e custeio do ciclo de vida també1n são combinados com a gestão de projetos em
a lgumas empresas. Discutiremos brevemente esses processos 1nenos utilizados depois
de termos discutido os de uti lizaç.ã o mais comum.
5.3 Zurich America lnsurance Company3

Um dos benefícios de ter processos integrados é que isso permite um planejamento de
contingências mais abrangente e real ista. Kat hleen Cavanaugh afirma que:
Como sabemos, dito de forma simples, o objetivo de todos os PN!Os é entregar projetos
dentro do prazo e do orçamento. Há um maior escrutínio sobre os projetos hoje em dia
e muitas empresas adotaram med idas protetivas de govemança "em funil" para ajudar a
garantir que os projetos certos sejam aproveitados. Com a compressão do tempo de coloca-
ção no mercado, é fácil que os orçamentos e datas finais dos projetos sejam estimados, ou
até mesmo ;'prometidos" cedo demais para o desespero do gerente de projetos. Para ajudar
a aliv iar uma possível decepção, o PN!O de T I da Zurich American lnsurance Company
implementou um processo de contingências tanto para a duração quanto para o orçamento
de projetos.
' Material fornecido por Kaci,leen Ca,•anaugh, Pl\1r• , Líder do PMO da Zurich - ZNA.
O processo de contingências ajuda a mitigar o risco de inesperados conhecidos no esco-

po de um projeto. Como fazemos parte do Zurich Financial Serviços G ro up global, temos
um processo de governança bastante rígido que exige tempo e dinheiro. Depois de ter passa-
do pelo "funil ", você realmente não q uer voltar para conseguir reaprovações, autorizações
de extensão de prazos, etc., então é imperativo fazer um planejamento adequado dos riscos
e mudanças de um projeto.
O processo de contingências usa uma matriz de determinação q ue considera fatores
espe.cíficos de risco, como recursos e complexidade te.e nológica, entre outros. Ele é criado
de forma a a LLxiliar o GP (gerente de projetos) a designa r a quantidade de contingência ne-
cessária tanto em termos de prazo quanto de orçamento. O conceito não é novo, mais ainda
não foi totalmente aceito como uma questão de necessidade.
O objetivo é não somente nos proteger das demoradas apresentações de govemança
de projetos, mas também nos afastar de estimativas indiv idua is exageradas. Antes dessa
abordagem de contingência ter sido int roduzida, a lguns gerentes de projetos embutiam a
contingência em suas estimativas. A principa l desvantagem disso é que, pelo fato da contin-
gência estar "oculta", não há processo s istemático para liberar fundos de volta ao poo/ de
financiamento do plano do projeto à medida que os riscos diminuem ao longo do projeto.
H oje, a contingência é mantida separada do p la no de projeto de modo que possamos ter
uma ideia melho r de q uando e por que as estima tivas originais foram ruins. Somente então
poderemos descobrir a ca usa-raiz e melhorar a abordagem de estim ação.
Algo importante a ser observado é que o cl iente participa da determ inação da necessi-
dade de contingência, de modo que eles possam compreender por que ela é tão importa nte
para o sucesso do projeto. O processo torna a contingência transparente e uma vez que o
cl iente compreende que os dólares da contingência não podem ser usados sem seu conhe-
cimento, eles ficam mais abertos para compreender as mudanças inerentes que ocorrem
durante a vida de uma projeto.
A contingência deve ser gerenciada ativamente à medida q ue o projeto progride. Todo
mês, q ua ndo os riscos de projeto são reava liados e a probabilidade de riscos d iminui, a
quantidade de contingência deve ser ajustada tanto no orçamento quanto no cro nograma .
Espera-se que a contingência possa ser liberada do projeto se ficar determinado que ela não
é mais necessária, por meio de uma avaliação de risco atualizada. Isso permite a disponibi-
lização de dinheiro para o utros esforços da empresa.
Em resumo, os itens abaixo são um esboço dos passos dados para se utilizar o processo
de contingência eficientemente.
Planeiar: O gerente de projetos de TI traba lha com o gerente de projetos de negócios
e com a equipe do projeto usando a matriz de determinação para calcular o percentua l
de contingência apropriado quando o projeto estiver pronto para buscar financiamento
integra l.
D0cume11tar/Co11111nicar: O GP atualiza o plano de p rojeto e o H istórico de Uso para
documentar e comunicar os valores da contingência.
Aprovar: O patrocinador é responsável pela assinatura dos documentos antes da con-
tingência ser utilizada.
Gerenciar: O gerente de projetos maintém o H istó rico de Uso à medida que a contin-
gência é consumida e outros dados de contingência são a tua lizados a cada mês, junta mente
com a avaliação de riscos.
Liberação: Os fundos de contingência são li berados de volta ao pool de financiamento
de projetos à medida de os riscos diminuem.
De maneira geral, esse processo aborda o a nt igo problema do trabalho do projeto co-
meçar antes de todo o resto que precisa ser conhecido e dá aos GPs a chance de luta r para
entregar o projeto dentro do prazo e do orçamento nesse a mbiente em constante modifica-
ção. Porque, afina l, mudanças acontecem .
5.4 Gestão da qualidade total

Durante a última década, o conceito de gestão da qual idade total (TQM, total quality
management) revolucionou as operações e as funções de produção de muitas empre-
sas. As empresas aprenderam rapida1nente que os princípios e sistemas da gestão de
projetos pode1n ser usados para oferecer suporte e administrar programas de TQM
e vice-versa. As empresas excelentes já integraram completamente os dois sistemas
complementares.
A ênfase da TQM é abordar questões de qualidade e1n sistemas tota is. A quali-
dade, no entanto, nunca é um objetivo final. Os sistemas de gestão da qualidade total
rodam continuamente e concorrente1nente em cada área em que u1na empresa faz ne-
gócios. Seu objetivo é levar ao 1nercado produtos de qual idade cada vez mel hor e não
apenas a 1nesma qualidade do ano passado ou de dois anos atrás.
A gestão da qua lidade total foi fundamentada nos princípios defendidos por W.
Edwards Dem ing, Joseph M. Juran e Ph illip B. Crosby. Deming é famoso por seu
papel na tr ansformação do Japão pós-guerra em uma força dominante na economia
mund ial. Os processos de gestão da qua lidade total se baseiam no simples Ciclo de
Deming (ou Cicl o PDCA, Plan-Do-Check-Act), que consiste em p lanejar-executar-
-verificar-agir.
O ciclo se encaixa perfeitamente nos princípios de gestão de projetos. Para a l-
cançar os objetivos de qua lquer projeto, pri1neiro você planeja o que será executado
e então executa. Depois, você verifica o que foi feito, conserta o que não funcionou
e então executa o que planejou inicialmente. O ciclo, no entanto, não termina co1n a
saída. O Ciclo de Dem ing funciona também como um siste1na de melhoria contínua.
Quando o projeto está completo, você examina as lições aprendidas no planejamento
e na execução, e depois incorpora essas lições ao processo e reinicia o ciclo planejar-
-executar-verificar-agir em um novo projeto.
A gestão da qualidade tota l tan1bém se baseia em três outros in1portantes ele-
mentos: foco no cl iente, pensamento em termos de processos e redução da va riação.
Isso o faz lembrar dos princípios da gestão de projetos? Deveria. O ciclo PDCA pode
ser usado para identificar, validar e in1plementar melhores práticas en1 gestão de
proJetos.
Uma das características das empresas que gan haram o prestigioso Malcolm Bal-
d rige National Quality A,vard é que todas elas possuem um excelente sistema de ges-
tão de projetos. Empresas como Motorola, Armst rong World Indust ries, General Mo-
tors, Kodak, Xerox e IBM usam sistemas de T QM e de gestão de projetos integrados.
Em meados da década de 1990, durante uma videoconferência ao vivo sobre o
assunto, intitulada Como alcançar a maturidade em gestão de proietos, Dave Kan-
dt, vice-presidente de qua lidade e gerenciamento de programas da Johnson Contr ols
durante a época da videoconferência, comentou sobre os motivos por trás do incrível
sucesso de sua empresa:
Entramos na gestão de projetos de um modo um pouco d iferente de algumas empresas.
Combinamos a gestão de projetos e o controle de q ualidade total (TQC, o u Total Qua/ity
Co11trol) o u a gestão da qualidade total. Nossos primeiros projetos de design e desenvolvi-
mento em meados da década de 1980 nos levaram a acreditar q ue nossos departamentos
funcionais estavam funcionando muito bem separadamente, mas precisávamos ter alguns
sistemas para juntá-l os. E, é claro, grande parte da gestão de projetos envolve fazer o
trabalho fluir ho rizontalmente pela empresa. O que fizemos primeiro foi contatar o Dr.
Norman Feigenbaum, o avô do TQC na América do Norte, q ue nos ajudo u a estabelecer
alguns sistemas q ue conectavam toda a empresa. O Dr. Feigenbaum enxergava a q ualidade
em seu sentido mais amplo: a q ua lidade de produtos, a q ua lidade de sistemas, a qualidade

dos deliverab/es e, é claro, a q ualidade dos projetos e do lança mento de novos produtos .
Uma parte essencial desses sistemas inclu ía sistemas de gestão de projetos que tratavam
da introdução de produtos e do processo da introdução de produtos. O treinamento em
gestão de projetos também fazia parte deste, uma vez que era necessário para colocar esses
. .
sistemas em vigor.
Começ.amos com nosso escritório executivo e, uma vez que tivéssemos expl icado os
princípios e filosofias da gestão de projetos a essas pessoas, passa mos ao gerenciamento de
insta lações, gerentes de engenharia, ana listas, do pessoal do departamento de aq uisições
e, é cla ro, dos gerentes de projetos. Somente quando o fundamento foi estabelecido é que
demos prosseguimento à gestão de projetos propriamente d ita e com a definição de papéis
e responsabilidades de modo q ue o pessoal de toda a empresa compreendesse seu papel
quando começasse a traba lhar. Só essa compreensão nos permitiu passar a uma o rgani-
zação matricia l, e, fina lmente, passamos a ter um departamento independente de gestão
de projetos. Q ue gra u de s ucesso tivemos? Subsequentemente, desde meados da década
de 1980, crescemos de dois a três projetos para em torno de 50 na América do Norte e
Europa. Crescemos de dois a três gerentes de projetos para 35. Não acred ito q ue teria sido
possível gerenciar esse crescimento ou conseguir esse número de projetos sem s istemas e
procedimentos de gestão de projetos e pessoas q ue os compreendessem nos níveis ma is
a ltos da empresa .
No início da década de 1990, descobrimos que estávamos fazendo certo sucesso na Eu-
ropa, e conseguimos nosso primeiro projeto de design e desenvolvimento lá . Com esse pro-
jeto, levamos para a Europa não somente gerentes de projetos e gerentes de engenharia q ue
compreendiam esses princípios, mas também os sistemas e o treinamento que inco rporamos
na América do Norte. Então, tínhamos uma abordagem integrada de gestão de projetos,
envolvendo toda a empresa. O que aprendemos nesses últimos 10 a nos q ue é o ma is impor-
tante para nós, ao meu ver, é que você começ.a com os sistemas e a compreensão do que você
quer que as várias pessoas envolv idas façam na empresa cruzando todas as barreiras fun-
cionais, e aí entra o treinamento em gestão de projetos e, finalmente, a sua implementação.
Obviamente, as pessoas que selecionamos para a gestão de projetos eram absolutamente
essenciais, e selecionamos as pessoas certas. Você mencionou a importância de os gerentes
de projetos compreenderem o negócio, e as pessoas que colocamos nessas posições são
escolhidas com muito c uidado. Normalmente, elas têm experiência técnica, com marketing
e com negócios e fina nças. É muito d ifícil encontrá-las, mas achamos que elas têm a com-
preensão multifuncional necessária para serem bem-sucedidas nesse ramo.
Na Johnson Cont rols, a gestão de projetos e a TQM foram desenvolvidas ao mes-
mo tempo. Dave Kandt fo i questionado, durante a 1nesma videoconferência, se as
empresas precisam ter uma sól ida cu ltura de TQM etn vigor a ntes de tentarem o de-
senvolvimento de um progra ma de gestão de projetos. Ele afirma:
Acho q ue não é necessário. O motivo pelo qua l d igo isso é que empresas como a Johnson
Controls são ma is a exceção do que a regra por implementa r a TQN! e a gestão de projetos
ao mesmo tempo. Conhe.ç o empresas que não tiveram tanta dificuldade de implementar o
ISO 9000 e a TQM porque eram razoavelmente ma duras em gestão de projetos. Não há
dúvidas de q ue ter a TQM em vigor facilitaria as coisas um pouq uinho, mas o q ue apren-
demos durante a recessão é que, se você quiser ser competitivo na Europa e quiser seguir as
diretrizes do ISO 9000, a TQM tem que ser implementada. E usar a gestão de projetos como
veículo para essa implementação costuma funcionar muito bem.
Há também a questão de se uma gestão de projetos be1n-suced ida pode ou não
existir dentro do ambiente ISO 9000. Segundo Dave Kandt:
A gestão de projetos não somente é cons istente com o ISO 9000, mas muitos dos sistemas
que o ISO 9000 exige são crucia is para o sucesso da gestão de projetos. Se você não pos-
s ui um bom sistema de q ua lidade, um s istema de engenha ria de mudanças e o ut ras coisas

q ue o ISO exige, o gerente de projetos enfrentará d ificuldades ao tenta r realiza r e executa r
esse projeto. Além disso, acho interessante o fato d e que em presas q ue estão traba lhando
para instala r e implantar o ISO 9000, se estão sendo bem-suced idas, provavelmente estão
utilizando técn icas de gestão de projetos. Cada um dos diferentes elementos do ISO exige
treinamento e, às vezes, a criação de sistemas dentro da empresa que possam ser agendados,
equipes que possam ser desig nadas, deliverables que possam ser esta belecidos, rastreados e
monitorados e relató rios que sejam enviados à gerência sênior. Foi exatamente as.sim que
instalamos a TQC na Johnson Controls, e, ao meu ver, o ISO 9000 possui uma força e in-
tenç.ão mu ito similares.
Embora os princípios do TQM ainda exista m, a importâ ncia dos conceitos do Seis
4
Sigma cresceu. Segundo Eric Alan Johnson e Jeffrey Alan Neal:
Gestão da q ua lidade total
Além d o ciclo PDCA da TQM, o modelo de melhoria contínua DMAJC (definir, medir,
analisar, aperfeiçoar e controlar - define, measure, a11a/yse, improve and control) pode ser
usado para melhorar a eficiência d a gestão de projetos. Esse modelo foi em pregado com
s ucesso para a mel horia de processos do Seis Sigma e d a filosofia l ean, mas os pilares bá-
s icos de sua metodologia estrutu rada de solução de problemas baseados em d ados tam bém
podem ser empregados para melhorar o sucesso da gestão de projetos.
Como avalia os dad os coletados sobre o sucesso de projetos e sobre a causa-raiz do
fracasso de projetos, o modelo pode ser usado para melhorar e refinar tanto a gestão de
projetos quanto a qualida de final d os produtos produzidos.
N a fase "definir", a definição e os requisitos específicos do projeto são basead os nos
d ados levantados junto ao cliente e no histórico de desempenho de projetos. l evanta r o má-
ximo de in formações possível nessas á reas permite q ue o gerente de projetos se concentre no
q ue é realmente importante para o cliente ao revisar o desempenho com o intuito de evita r
os problemas de projetos passados e de estimular que se propaguem seus sucessos. Nessa
fase, dados disponíveis sobre as pessoas, processos e forneced ores são avaliados e revisados
para determina r sua capacidade de c umprir os requisitos de custo, qua lidade e cronogra ma
d o projeto. A fase ;'definir", em resumo, deve avaliar não somente os requis itos do cliente,
mas tam bém a capacidade de seu sistema de cumprir esses requisitos. Ambas essas avalia-
ções devem se basear em d ados levantados por um sistema de mensuração dedicado. Além
disso, a etapa "definir" deve esta belecer as métricas a serem usadas durante a execuç.ã o
de projetos para monitorar e contro la r seu progresso. Essas métricas serão co nt inuamente
avaliadas durante as fases "medir" e "avaliar" (essas fases DMAIC são simultâneas às fases
de gestão de projetos do PMI).
N a fase seguinte do modelo DMAIC, " med ir", dados (as métricas identificadas na fase
;'definir") do sistema de mensuração são continuamente rev isados durante a execução do
projeto para garantir que ele esteja sendo gerenciado de forma eficiente. Os mesmos da-
d os das métricas usadas na fase "definir" devem ser atua lizad os com dados específicos do
projeto para determinar o seu progresso. A avaliação contínua do desempenho do projeto,
baseada nos dados levanta dos du rante a fase de execução, é essencial pa ra a gestão de pro-
jetos baseada em dados.
Du rante a mensuração contínua do progresso d o projeto, é provável que a lgumas des-
sas métricas essencia is ind iquem pro blemas que estejam oco rrendo (pro blemas a tua is) o u
q ue provavelmente venh am a ocorrer (principais indica dores). Esses pro blemas têm de ser
abordados para que o projeto seja executa do dent ro d o prazo e d o o rça mento, cumprindo
os requisitos. É aqui q ue o aspecto de análise do modelo DMAJC se to m a crucia l da gestão
• Eric Alan Johnson, diretor adjunto de Programas de Contratos da Sarellire Concrol Nerwork, AFSCN, e
vencedor do Prêmio Kerzner 2006 de Gerente de Projetos do Ano; e Jeffrey Alan Neal, Faixa Prera/especialis·
ra e palesrranre em gestão enxura, métodos quanricarivos, na Universiry o f Colorado, Colorado Springs, EUA.
Capítulo 5 Processos integrados 31 1
de projetos. A aná lise de dados é todo um campo em si mesmo. Inúmeros li vros e artigos já
abordaram o problema de como avaliar dados, mas o principal objetivo permanece. O ob-
jetivo da a nálise de dados é transforma r dados em informações utilizáveis nas quais possam
ser baseadas as decisões de um projeto.
Os métodos de aná lise de dados são específicos ao tipo de dad o e às perguntas para as
qua is se buscam respostas. O primeiro passo (d epois de os dados terem sido levantados)
é usar técnicas descritivas para o bter um q uadro geral dos dados. Esse quadro gera l deve
incluir uma medida de tendência central (i.e., média) e uma medida de va riação como o
desvio-padrão. Além disso, ferramentas gráficas como histogramas e diagramas de Pa reto
são uma forma útil de resumir e exibir informações. Testes de signi ficânc ia e o desenvol-
vimento de interva los de confiança são úteis para determina r se os resulta dos da aná lise
são estatisticamente significa tivos e para estima r a pro babilidade de se obter um resulta do
similar.
No monitoramento contínuo dos processos, no rmalmente se utilizam gráficos de con-
trole para ava lia r o estado de estabilidade dos processos e para determina r se a va riação
é significativa o suficiente para garantir ma io res investigações. Além disso, os gráficos de
controle fornecem uma base para determinar se o tipo de variação tem uma causa espe.c ia l
ou co mum. Essa distinção é essencial na determinação das ações corretivas apropriadas que
podem precisar ser realizadas.
A fim de fornecer uma base para a identificação de possíveis causas-raiz para pro -
b lemas de desempenho de projetos, ferramentas como a Aná li se de Modos e Efeitos de
Fa lhas e o diagrama da espinha de peixe (ta mbém conhecido como diagrama de Ishkawa)
podem ser usadas para inic ia r e docume nta r o processo de pensamento organizado pa ra
sepa ra r as principa is ca usas de não conformidades de causas que a penas co ntribuem para
as mesmas.
Se os dados atenderem à condição estatítica necessária, testes co mo a Análise de Va-
riância (ANOVA) e aná lise de regressão podem ser extrema mente úteis na quantificação e
previsão do desempenho de processos e projetos. Como a ANOVA (o Modelo Linear Geral)
pode ser usada para testar diferenças méd ias de do is o u mais fatores ou níveis, ela pode ser
utilizada para identificar impo rtantes variáveis independentes para muitas variáveis depen-
dentes do projeto. Diversos modelos de regressão (linear simples, linear múltiplo e biná-
rio) podem ser usados para q uantificar os d iferentes efeitos de variáveis independentes em
va riáveis dependentes que são cruciais para o s ucesso do projeto.
Em resumo, essa fase usa dados para conduzir uma investigação profunda e abrangente
das ca usas-raiz que foram responsáveis pelo problema na execução do projeto e os efeitos
sobre o projeto se as mesmas forem deixadas sem co rreção.
A fase seguinte envolve a co rreção e melho ria do processo, abordando a causa-raiz iden-
tificada na fase anterior. Trata-se de ações corretivas (conserta r o problema que você está
enfrentando) e ações preventivas (certificar-se de que o problema ou algum problema simi-
la r não volte a ocorrer). Então, uma vez que a causa-raiz tenha sido identificada, as ações
corretivas e preventivas de melhoria d os processos podem ser levadas a a bordar a execução
do projeto a tua l e a prevenir a reocorrência desse problema específico em projetos futuros.
A fim de garantir que os projetos a tua is não sofram com o problema q ue foi identificad o
recentemente e que projetos futuros evitem cometer os erros do passado, implementa-se um
plano de controle para monitorar e co ntrolar os projetos. O ciclo se repete para todos os
problemas da gestão de projetos.
O monitoramento d o status e d as métricas do projeto junta mente com sua anál ise e
correção é um processo contínuo e constitui a fase Cont ro la r d o projeto . Durante essa fase,
as princi pa is med idas instituídas durante a fase de Iniciação são usadas para rastrear o
desempenho do projeto em relação aos requisitos. Quando a causa-raiz de cada problema
do projeto é analisada, essa causa-raiz e as ações corretivas e preventivas subsequentes en-
tram em um banco de dados de "lições a prend idas". Isso permite que sejam to madas ações
consistentes de resolução de problemas. O banco de dados ta mbém é usado pa ra identificar
possíveis riscos de projetos e instituir ações de mitigação a priori.
Gestão de riscos/oportunidades usando ferramentas

do Seis Sigma e modelos probabilísticos
A gestão de riscos/oportun idades é u1na das ferra 1nentas mais Ílnportantes, senão a
mais importante, da ca ixa de ferramentas dos gerentes de projetos ou progra 1nas - in-
dependentemente do tipo de cont rato. Em geral, projetos/programas focam o possível
impacto e/ou a probabilidade de ocorrência de u1n risco.
Embora esses sejam fatores muito importantes para desenvolver um bom plano de
mitigação de riscos, a engenhosa capacidade da equipe de projeto de detectar o risco
terá o 1na ior impacto na execução de p rojetos bem-suced idos. Se você não conseguir
detectar o risco, sua capacidade de gerenciá-lo será sempre reativa. O r isco indetec-
tável é uma ameaça 1naior à execução do que fatores de alta probabi lidade ou alto
impacto. É aí que o uso da ferramenta do Seis Sigma chamada de Anál ise de Modos
e Efeitos de Falhas (FMEA, Fai/11re Modes and Effects Analysis) pode ser mu ito efi-
ciente. A ferramenta FMEA pode ajudar a equipe de projeto a avaliar e detectar riscos.
Prioriar a detecção de riscos ajudará a equipe a pensar de forma inovadora ao propôr,
p lanejar ou executar um projeto be1n -sucedido.
Exemplo: se seu projeto/programa possui um r isco que te1n uma probabil idade de
ocorrência significativa, então ele provavelmente não é um risco - é um proble1na. Se o
impacto for grande e a probabilidade for baixa, você terá de ficar de olho nesse risco,
mas nonnalmente não gastará para mitigá-lo. Entretanto, se o r isco tiver a lto impacto
ou probabilidade, mas um ba ixo nível de detectabil idade, os resultados podem ser
devastadores.
O outro lado de gerenciar um projeto/programa é a falta de foco na identificação
e no gerenciamento de oportunidades. Se a equipe de um projeto a focar somente a
gestão de riscos, ela pode deixar de identificar as possíveis oportun idades do projeto.
As oportunidades precisam ser ava liadas com o mesmo rigor que os riscos. O 1nes-
mo nível de foco em áreas de Ílnpacto, probabi lidade e capacidade de reconhecer a
oportunidade tem de ocorrer para uma equipe de projetos. A FMEA é também muito
útil para o reconhecimento e gerenciamento de oportunidades. Às vezes, riscos inde-
tectáveis ocorrerão, mas a capacidade de reconhecer e rea lizar oportun idades pode
contraba lançar esses impactos de riscos. O uso do reconhecimento de oportunidades
possui os 1naiores impactos nos projetos de preço fixo nos quais economiza r custos
pode aumentar a 1nargem de lucro dos projetos.
Se um projeto possui riscos de cronograma, como podemos quantifica r esse risco?
Um método é por meio do uso de modelagem probabi lística. A modelagem probabi-
lística de seu cronogra1na pode ajudá-lo a prever a probabi lidade de alcançar todos os
seus marcos dentro de seu período de dese1npenho. Se o risco de não cumpri r seu cro-
nograma é a lto demais, você pode usar esses modelos para rea lizar análises do tipo "e
se ... ?" até que os fatores de riscos possam ser levados a níveis aceitáveis. Essa aná lise
deve ser feita ANTES de se determinar as linhas de base do projeto ou (preferencia l-
mente) durante a fase de proposta.
A chave para uma implementação bem-sucedida dessa est ratégia é um banco de
dados relacional que lhe perm itirá construir o modelo p robabilístico mais rea lista pos-
sível. Essas infonnaçôes devem ser levantadas em uma ampla variedade de projetos
de modo que as informaçôes sobre os projetos de ta1nanho e escopo/complexidade
sim ilares possam ser avaliados. Ele precisa ser integrado às " liçôes aprendidas" desses
outros projetos a fim de constr uir o melhor modelo probabilístico para mitigar os r is-
cos de seu cronograma. Sempre tenha em mente de que um modelo é tão bo1n quanto
a qual idade das informações usadas para construí-lo.
5.5 Engenharia simultânea

A necessidade de diminuir o te1npo de desenvolvimento de produto sempre foi uma
praga para as empresas dos EUA. Durante momentos de condições econôm icas favo-
ráveis, as corporações implementaram enormes quantidades de recursos para tratar do
proble1na de tempos de desenvolvimento 1nuito longos. Durante retrações econôm icas,
no entanto, não somente os recursos são escassos, mas o te1npo se torna uma restrição
crucial. Hoje, os princípios da engenharia simu ltânea são quase que un iversa lmente
adotados como a solução ideal para o problema.
A engenharia simultânea exige que se realizem os vários passos e processos ao ge-
renciar um projeto em paralelo e1n vez de e1n sequência. Isso significa que engenharia,
pesquisa e desenvolviinento, produção e marketing são todos envolvidos no início de
um projeto, antes de qua lquer traba lho ser rea lizado. Isso nem sempre é fáci l, e pode
criar riscos à medida que o projeto progride. Um planejamento de projeto superior é
necessário para evitar aumentar o nível de risco posteriormente. Os riscos mais sérios
são at rasos em decorrência de mau planejamento. Um planejamento melhor é essen-
cial para a gestão de projetos, então não surpreende que empresas excelentes integrem
a engenharia siinu ltânea e sistemas de gestão de projetos.
A Cluysler (hoje chamada de DaimlerChrysler) Motors usou a engenharia simul-
tânea com a gestão de projetos para levar o carro esporte Viper do conceito ao merca-
do em 1nenos de três anos. A engenharia simultânea pode muito bem ser a maior força
motriz por trás da 1na ior aceitação da gestão de projetos.
5.6 Gestão de riscos

A gestão de riscos é un1 meio organ izado de identificar e medir riscos e desenvolver,
selecionar e gerenciar opções para lidar con1 esses riscos. Em todo este livro, enfatizei o
fato de que os gerentes de projetos do futuro precisarão de habi lidades de negócios su-
periores ao avaliar e gerenciar riscos. Isso inclui tanto riscos de projetos quanto riscos de
negócios. Os gerentes de projetos no passado não eram equipados para quantificar ris-
cos, responder a riscos, desenvolver planos de contingência ou n1anter registros de lições
aprendidas. Eles eram forçados a pedir conselhos aos gerentes sên ior sobre o que fazer
quando se desenvolvian1 situações arriscadas. Hoje, os gerentes sênior estão empoderan -
do os gerentes de projetos a tomar decisões relacionadas a riscos, algo que exige um ge-
rente de projetos con1 sólidas habil idades de negócios alén1 de conhecimentos técn icos.
Preparar um plano de projeto é algo baseado no histórico. Dito de forma simples:
o que aprendemos com o passado? A gestão de riscos nos incentiva a olhar para o
futuro, a prever o que pode dar errado e, então, a desenvolver est ratégias de contin-
gência para m1ttgar esses r iscos.
Rea lizávamos a gestão de riscos no passado, mas somente a gestão de riscos finan-
ceiros e de cronograma. Para mitigar um risco financeiro, aumentamos o orçamento
do projeto.
Para m itigar u1n risco de cronograma, adicionamos ma is te1npo a ele. Mas, na
década de 1990, os riscos técnicos se tornaram cruciais. Simplesmente adicionar mais
tempo ou dinheiro ao plano não é a solução para mitigar riscos técnicos. A gestão de
riscos técnicos aborda pri1nordia lmente duas questões:
• Pode1nos desenvolver a tecnologia considerando as restrições impostas?
• Se desenvolvermos a tecnologia, qual é o risco de obsolescência, e quando pode-
mos esperar que isso ocorra?
Para a bordar esses riscos técnicos, são necessárias estratégias eficientes de gestão
de riscos baseadas na previsão técnica. A pri ncípio, pode parecer que tomar a gestão
de r iscos pa rte integral do planejamento de pro jetos deve ser relativamente fáci l. Basta
identificar e t ratar dos fatores de risco antes de eles saíre1n do contr ole. Infeliz1n ente, o
provável é que o contr ário seja a norma, pelo menos em um futuro previsível.
Dura nte a nos, as emp resas só falavam da gestão de riscos da boca para fo ra e
achavam q ue simplesmente tinha1n de conviver com ele. M uito pouco se publicou so-
bre como desenvolver um processo estr uturado de gestão de riscos. O desastre com a
espaçonave Challenger, em janeiro de 1986, despertou todos e1n relação à importância
5
de u1n a gestão de riscos eficiente.
Hoje a gestão de riscos se tornou tão importa nte que as e1n presas estão estabe-
lecendo organizações de gestão de riscos separadas dent ro da empresa . Entretanto,
muitas empresas tê1n usado un idades funcionais de gestão de riscos há anos, e ainda
assim esse conceito tem passado despercebido. A seguir temos um pa norama da meto·
dologia de gerenciamento de progr ama do departa1n ento de gestão de riscos de uma
e1n presa 1n a nufatureira internacional sediada em Ohio, EUA. Esse departa1n ento está
em operação há aproxiin adamente 2 5 anos.
O departa mento de gestão de riscos é parte da disciplina financeira da empresa e, em última
análise, reporta-se ao tesoureiro, q ue se reporta ao d iretor financeiro (CFO). O objetivo ge-
ra l do depa rta mento é coordenar a proteção dos a tivos da empresa . O meio principal para
se alcança r esse objetivo é eliminar o u reduzir as perdas potenciais po r meio de progra mas
de prevenção. O depa rtamento funciona de forma muito alinhada com o depa rtamento
interno de saúde e segurança. Além d isso, ele utiliza especia listas externos em controle de
perdas para auxiliar as divisões da empresa na prevenção de perdas.
Um método empregado pela empresa para assegurar o envolvimento de toda a corpo-
ração no processo de gestão de riscos é responsabilizar suas d ivisões po r q ualquer perda
até determ inado nível de retenção segurado pelas pró prias d ivisões. Se houver uma perda
significativa, a divisão tem de absorver a perda e seu impacto em s ua margem de lucro final.
Isso envolve direta mente as d ivisões tanto na prevenção de perdas quanto no gerenciamento
de pedidos de indenização. Q uando ocorre um pedido de indenização, a gestão de riscos
mantém co ntato regular co m o pessoal da divisão para estabelecer protocolo sobre o pedido
e uma resolução final.
A empresa não compra seguros acima dos níveis de retenção designados. Assim como
com os pedidos de indenização do cliente, os prêmios de seguro são a locados às suas d i-
visões. Esses prêmios são ca lculados com base no volume de vendas e histórico de perdas
dos pedidos de indenização, sendo o percentual mais significativo a locado para este último.
Cada uma das loca lizações da empresa precisa manter um p la no de co ntinuidade de
negócios. Esse plano é revisado pela gerência de riscos e é auditado pelos depa rta mentos
internos de audito ria e de saúde ambienta l e segurança.
A gestão de riscos é uma parte integrante das o perações da corporação, como eviden-
ciado por seu envolvimento no processo de diligência prévia para aquisições o u desinvesti-
mentos. É envolvida no início do processo, e não no fim, e forne.ce um relatório por escrito
detalhado das descobertas, a lém de uma apresentação oral para a gerência do grupo.
O serviço de a tendimento ao cl iente faz pa rte do esta tuto social da empresa. Os clientes
atendidos pela gestão de riscos são as divisões da empresa. O estilo de gerenciamento do
departamento co m seus clientes é o de construção de um consenso e não de imposição. Isso
é exemplificado pelo fato de a empresa usar vários ad ministradores externos terceirizados
(TPAs, third-party administrators), em estados em que a empresa possui seguro próprio.
Administrativamente, seria mu ito mais fácil utilizar um único T PA nacional. Entretanto,
usar TPAs regionais fortes co m escritó rios em estados nos q ua is as divisões operam oferece
5
O escudo de caso "l11e Space Shuttle Challenger Disaster·· aparece em H. Kerzner, Project Management
Case Studies, 4th ed. Hoboken, NJ: Wiley, 20 13, p. 447.
às divisõ es uma assistência especia lizada em leis estaduais es pecíficas. Essa abordagem fun-
cionou muito bem para essa empresa, que reconhece a necessidade de conhecimentos sobre
as leis de cada es tado individual.
A importância da gestão de riscos hoje é evidente em todo o mundo. Seus princí-
pios podem ser apl icados a todos os aspectos de um negócio, não apenas a projetos.
Quando uma empresa começa a usar práticas de gestão de r iscos, ela sempre consegue
identificar outras aplicações para ta is processos.
Para empresas multinaciona is que são voltadas a projetos, a gestão de riscos tem
suma importância. Nem todas as empresas, especia lmente em países não desenvol-
vidos, compreendem a gestão de r iscos ou a sua importância. Esses países às vezes a
veem como uma despesa de excesso de gerenciamento em um projeto.
Considere o segu inte cenário: à medida que sua organização va i melhorando e1n
gestão de projetos, seus clientes começam a lhe dar mais e ma is tr abalho . Você está
consegu indo contratos para projetos turnkey, ou projetos de solução completa. Antes,
tudo o que você tinha de fazer era ent regar o produto dentro do prazo e pronto. Agora
você tam bém é responsável pela instalação e o início das operações, às vezes até mes-
mo pelos serviços contínuos de a tendimento ao cliente. Co,no os clientes não usa1n
mais seus próprios recursos no projeto, eles se preocupam menos com como você está
lidando com seu sistema de gestão de projetos.
Como alternativa, você poderia estar tr aba lhando para clientes do terceiro mundo
que a inda não desenvolvera1n seus próprios siste1nas. Cem por cento do risco desses
projetos é seu, especialmente à medida que os projetos vão se tornando mais comple-
xos (ver Figura 5- 6). Bem-vindo ao século XXI!
Un1a subcontr atada recebeu um contr ato para instalar componentes nas novas
instalações de um cliente. A construção das insta lações seria concluída até determi-
nada data específica. Depois da conclusão da construção, a contratada instalaria os
equipan1entos, realizaria testes e, então, daria início às operações. A subcontr atada
não poderia faturar produtos ou serviços até depois de um início ben1-sucedido das
operações. Havia também uma cláusula que previa uma multa para entrega com
atraso.
A contratada ent regou os componentes ao cliente dentro do prazo, mas os con1-
ponentes foram colocados en1 un1 armazém porque a construção das instalações esta-
va atrasada . A contr atada agora tinha un1 problema de fluxo de caixa e um possível
pagan1ento de multa devido a dependências externas que se encontravan1 no cam inho
crítico. Em outras pa lavras, o cronograma da contratada estava sendo controlado
pelas ações de terceiros. Se o gerente de projetos tivesse feito a gestão de riscos de
negócios en1 vez de apenas a gestão de riscos técn ica, esses riscos poderiam ter sido
reduzidos.
Inexperiente
Conhecimento
do clíente
Experiente ,__ _ _ _ _ _ _ _ _ _ _ _ _.._

Simples Complexo
Típo de contrato
Figura 5-6 Riscos futuros.

Pa ra o gerente de projetos global, a gestão de riscos assume uma nova di1nensão.

O que acontece se a cultura do país com o qual você está trabalhando não compreende
a gestão de riscos nem possui qualquer processo de gestão de riscos? O que acontece
se os funcionários estiverem temerosos de que más notícias venham à tona ou de que
novos p roblemas potencia is sejam identificados? O que acontece se as restrições do
projeto sobre tempo, custo e qua lidade/desempenho não fizere1n sentido para os t ra-
ba lhadores locais?
5. 7 Wãrtsilã: a necessidade de uma gestão

6
de riscos proativa
Gestão de riscos proativa nos projetos das instalações
da usina de energia da Wãrtsilã
Na Wiirtsilii, a gestão de riscos de projetos tradicionalmente tetn lidado com a iden-
tificação e o planeja1nento. Vimos que isso agora precisa ser expandido, passando
a cobrir também a reflexão e a tomada de ações p roativas nos projetos cotnplexos
de ho je. Os riscos precisam ser enfrentados co1n antecedência, antes de ocorrerem e
potencialmente prejudicarem os objetivos dos projetos. Agora apresentaremos breve-
mente o que fize1nos a esse respeito.
O modo como a incerteza e o risco são enfrentados e1n projetos depende muito
da experiência. Pode-se dizer que muitos gerentes de projetos só lida tn com riscos e
incertezas em decorrência do que eles já estão vivenciando em seus projetos. Gerentes
de p rojetos experientes, no entanto, podem reconhecer riscos muito antes de eles vira-
rem problemas. Da mes1na fo nna, as oportunidades e incertezas positivas podem ser
reconhecidas com maior facilidade por gerentes de projetos experientes. Entretanto, o
reconhecÍlnento de oportunidades depende não somente da experiência, uma vez que é
necessário ta 1nbém uma disposição a correr riscos. Em muitos casos, é necessário que
os gerentes de projetos passem por uma 1nudança de mentalidade para serem capazes
de fazê-lo.
À medida que os projetos de grande porte foram se tornando cada vez mais com-
p lexos de gerenciar, tornou-se essencial que o gerente de projetos tenha experiência
suficiente para ter uma percepção precisa do que está envolvido. Além do projeto em
si, é de ext rema Ílnportância conhecer o local, o cl iente e o a 1nbiente. Não ter conheci-
mento sobre ou experiência nessas questões pode causar grandes problemas, tornando
o projeto ma is complexo e desafiador do que o necessário. A fim de evitar esses obs-
táculos, é importante que toda a equ ipe de projeto use uma combinação de conheci-
mento, experiência e criatividade. E1nbora a gestão de riscos seja de responsabilidade
do gerente de p ro jetos, essa não é uma tarefa exclusivamente dele. Toda a equipe de
p ro jeto precisa co1npa rtilhar essa responsabilidade.
Isso nos mostra a relevância de ter um banco de dados de lições aprendidas com
informações que sejam comparti lhadas entre as equipes de projetos. Tal banco de da-
dos é u1n importante recurso para um novo gerente de projetos ou outro membro da
equ ipe de projeto que esteja se reun indo aos outr os. Da mes1na forma, quando uma
equ ipe de projeto aceita um novo tipo de projeto, ou um projeto em um loca l tota l-
mente novo, é vantajoso ser capaz de ava liar o conhecimento sobre casos simi lares.
' O material foi fornecido pelo escritório de gestão de projetos da Wãrtsilã (\VPMO). Direitos aurorais da
\Vánsilã Corporarion 2013. Reproduzido com permissão.
Tendo isso em vista, está sendo implementado um banco de dados de lições aprend idas
para que todo esse conhecimento e experiência possam ser compartilhados.
Vin1os que o conhecin1ento e a experiência desempenhan1 un1 in1portante papel
na gestão de riscos, incertezas e outros fatores en1 projetos. Ent retanto, gestão de
riscos proativa é a lgo que nen1 sempre é fácil de implementar, já que depende das
percepções de tantas pessoas diferentes a seu respeito. É necessária muita comunica-
ção para que se possa ter un1a compreensão comun1 do que a organização precisa em
relação a riscos e incertezas, além de uma clara con1preensão dos possíveis benefícios
que eles t razem para a o rganização. A gestão de riscos proativa não envolve ape-
nas identifica r, classifica r e quantifica r os riscos; trata-se de muito ma is. A uti lização
desse processo envolve ter a maturidade para usar a experiência e o conhecin1ento
adqu iridos para evitar que riscos cheguem a ocorrer, a lém da confiança para tomar as
ações necessá rias para ser capaz de incentivar o desenvolvimento de oportunidades
pos1ttvas.
Uma equ ipe de p rojetos precisa de u1na ferramenta de gestão de r iscos de proje-
tos na qua l os eventos futuros, tanto os previstos quanto os imprevistos, possam ser
aco1npanhados continuamente. Uma ferramenta de processos de gestão de riscos não
precisa necessariamente ser complexa. O aspecto mais i1nportante é a forma como ela
é utilizada na organização. Ve1nos que, nesse caso, a afirmaç.ão: "quanto ,nais súnples,
melhor" descreve 1nui to bem o que é necessário.
O processo proativo de gestão de riscos colocado em uso na Wiirtsila consiste e1n
três fases diferentes (Figura 5- 7). Primeiro, deve-se fazer a classificação de um projeto
para defin ir a sua complexidade. Daí em diante, os processos de risco propriamente
ditos serão gerenciados como um processo contínuo durante todo o ciclo de vida do
projeto. Além d isso, devem -se registra r as lições aprendidas sobre r iscos em que as
ações tomadas diferiram significativamente da resposta p lanejada. Na Wiirtsila, imple-
mentamos todo esse processo em uma ferramenta de gestão de projetos comum usada
por todas as equipes e a gerência.
O processo de classificação fornecerá informações importantes para os passos da
identificação de riscos. A intenção do processo é incentivar os gerentes de projetos a
pensarem no projeto e tanto definirem onde se encontra a complexidade do projeto
quanto fornecerem informações para a identificação do processo de gestão de riscos.
Eles têm de descrever o projeto de um ponto de vista objetivo. Um dos principais valo-
res agregados que a classificação de projeto traz para a gestão de projetos é definir os
recursos necessários para a alocação de recursos.
O processo de gestão de riscos fundamentahnente depende do fato de ser um
processo contínuo. Todos os mesmos elementos que foram usados no processo de
classificação são imple1nentados nesse processo. O processo tradicional de gestão de
riscos descrito no Guia PMBOK® (2008 ) foi usado como a base para o novo processo
de gestão de riscos.
Para que u1n processo proativo de gestão de riscos seja bem -suced ido, é vital que
a equipe de projeto tire tota l proveito dele. O desconhecimento de riscos e incertezas
causa grandes proble1nas à gestão de projetos quando eles se materializa1n inesperada-
mente e se tornam problemas nocivos.
É preciso que se crie um bo1n sistema de comunicação a fim de iinplementar u1n
processo uniforme de gestão de riscos entre as equipes de projetos. Além disso, deve-se
oferecer treinamento sobre como usar o processo de gestão de riscos para melhorar a
compreensão de como o processo de r iscos proativo pode ser util izado e para que se
compreenda por que ele é tão importante.
'J!)"'
-
'"'3:
o
~
·E= "'
"O
~
8
~
-
·.::
•Q)
Q)
-8
"- "'e>
Q)
eQ)
Q)
"O
1/)
"'
e
·u;
:,
1/)
"'e
1/)
-·eo
Q)
e.
Q)
"O
1/)
~
·.::
Q)
"O
o
!l!I
1/)
Q)
C)
Q)
"O
.,g
8
·e
"'ee.
= o
~ :ri
~
-
8
"- e
o..
t--
1
-"'
li)
:,
e,
i!
7
5.8 ILLUMINAT: gestão de riscos eficiente
A ILLUMINAT (Trinidad & Tobago) Ltd. é umas das provedoras líderes de produtos
e serviços de Informação, Comunicações e Tecnologia (ICT) e1n Trinidad e Tobago
(T&T) e na Região do Grande Caribe. A ILLUMINAT faz parte do grupo de empresas
Neal and Massy, um conglomerado que opera na maioria dos países de língua inglesa
do Caribe. Grande parte dos negócios da ILLUMINAT com seus clientes externos é
gerenciada por meio de projetos que usam uma metodologia padronizada de gestão de
projetos, na qual foi estabelecido u1n PMO e o uso da metodologia, tetnplates, ferra-
mentas e processos do PMO é fo rtemente encorajado em toda a organização. Segundo
a KPMG (1997) e a Nieto-Rod riguez e Evrard (2004), a capacidade organizacional
de gestão de projetos é vista cada vez ma is como uma chave para a vantagem compe-
titiva e, portanto, como algo em cujo desenvolvimento vale a pena investir. A gestão
de riscos (GR) é um componente-chave de u1na gestão de projetos eficiente e, como
tal, é uma das abordagens usadas para oferecer suporte aos objetivos estratégicos da
organ1zaçao.-
Contexto empresarial
A Figura 5-8 representa o contexto empresarial no qual a ILLUMINAT opera e que
afeta a estratégia usada para integrar as abordagens de gestão de riscos de portfólio,
progra1nas e projetos co1n a estr atégia geral da organização.
O conceito de GR é embutido na ILLUMINAT, onde sua apl icação é evidenciada
nos níveis de gerenciamento de portfólios, programas e projetos em toda a organiza-
ção. As est ruturas de governança em vigor para um GR eficiente incluem as seguintes
dimensões centra is, como mostra a Figura 5-9:
Figura 5-8 Contexto empresarial da ILLUMINAT.
7
Informações fornecidas pela Sra. Kerdell Brereron, gerente da unidade de gestão de projetos de serviços da
ILLUMINAT (Trinidad & Tobago) ltd.
• Programas
• Projetos
• Sistemas
• Infraestrutura
• Plano de continuidade de negócio (recursos humanos e físicos)
• Recursos da ILLUMINAT
• Clientes
• Fornecedores
• Alianças estratégicas (parcerias de negócios, afiliações a indústrias, etc.)
Figura 5-9 Dimensões centrais da gestão de riscos da ILLUMINAT.
Figura 5- 10 Etapas da gestão de riscos na ILLUMINAT.
Essas pri ncipa is dimensões são usadas para avalia r os riscos e1n oportuni dades de
negócios dos pro jetos desde o início. A avaliação inclui riscos a viabilidade comercial,
viabilidade técnica e capacidade orga ni zacional, entre outros. Os ambientes externo
e interno tam bém são levados e1n consideração, e todos os riscos são agredados e
revisados de modo holístico a fim de informar as decisões finais pa ra o portfólio da
ILLUMINAT.
Abordagem de gestão de riscos

A Figur a 5- 10 é uma visão de alto nível da estutur a de governa nça da gestão de riscos
que está em vigor na ILLUMINAT, onde ela é gerenciada em t rês etapas.
Etapa: Pré-programa/decisão do projeto (solicitação de proposta)

• Monta r uma equipe incluindo recursos de vendas, especialistas em assuntos técni-
cos, recursos de gestão de pro jetos, executivo/gerente sênior.
• Defini r solução técnica e grau de integração (um único ou vários fornecedo res)
necessários à criação de uma solução.
• Revisar todos os aspectos do progra tna/projeto, inclusive de perfis de clientes e

fornecedores, prazos para ent rega (datas de marcos), moeda a ser usada, logística
necessária (p.ex.: um único ou diversos países envolvidos), armazenamento, possí-
veis causas para atraso e o impacto sobre o projeto, etc.
• Identificar e avaliar e.ada risco e definir ações de mitigação viáveis que possam ser
tomadas para el iminar ou reduzir o impacto dos riscos (se eles se 1nateria lizarem).
Esses planos de ação são integrados aos acordos contratua is (cliente e fornecedor),
acordos comercia is, o plano de implementação do projeto e outros arranjos de
trabalho (p.ex.: seguro) que são encapsulados na proposta final.
• Revisar a proposta e, u1na vez aprovada pela Gerência Executiva, liberá-la ao
cl iente para que ele a assine.
Etapa: Implementação do programa/projeto

Uma vez que se feche o negócio e o programa/projeto tenha se iniciado, o GR é ativa-
mente gerenciado nos seguintes níveis:
• Criar um plano para definir as abordagens de govemança para o GR, levando e1n
consideração as nuances específicas do programa/projeto.
• Conduzir uma aná lise de GR ma is profunda para identificar r iscos que podetn
afetar o projeto em todas as etapas (fatores internos e externos).
• Ava liar cada risco usando dados relevantes e conhecimentos especializados para
definir e Ítnple1nentar p lanos de m itigação (e contingência ) eficientes, alétn de
. . .
pnonzar os nscos.
• Monitorar continuamente os riscos e implementar asções corretivas e/ou planos
de contingência quando aplicável.
• Incluir uma análise de risco dos riscos que tenham prioridade "Muito Alta" e
"Alta" em relatórios periódicos para as principais partes interessadas.
A análise de riscos é realizada a partir de três principais perspectivas: estratégica,
co1nercial e técnica . A fi ,n de conduzir essa atividade eficiente e eficazmente, são desig-
nados encarregados de programa/projeto, que são responsabilizados por garantir que
todos os arranjos estejam de acordo com o planejado de ,nodo a assegurar que os alvos
e objetivos do programa/projeto sejan1 alcançados, n1 inin1izando, ao mesn10 ten1po,
qua isquer impactos negativos. O encarregado de progran1a/projeto é tipicamente utn
recurso sênior con1 a autoridade de tomar decisões ind ispensáveis e é utn ponto-chave
de escalada de conflitos para resolver os problemas à n1edida que foren1 surgindo.
Etapa: Pós-programa/projeto
Após a conclusão do programa/projeto, os clientes respondem a questionários que
visam a identificar sua satisfação geral com os serviços da ILLUMINAT, além de qual-
quer área para melhorias. Isso é feito por 1neio de Pesquisas de Satisfação do Cliente e
Pesquisas de Avaliação de Impacto de Projetos. O feedback dessas pesquisas é, então,
ana lisado e, quando aplicável e viável, usado pela organização para mel horar as áreas
relevantes identificadas.
Relatórios de gestão de riscos

No nível de ger enciamento de portfólios, cria-se utn perfil de risco para cada oportuni-
dade e isso é feito por 1neio de duas etapas no momento da proposta:
• Usando a política de "delegação de autoridade " da organ ização, todas as propos-
tas são revisadas e assinadas dependendo do va lor do projeto dentro da organiza-
ção (chefe da un idade de negócios [UN], diretor executivo [CEO], presidente do

Consel ho Diretor, CEO do Grupo). Com isso, pretende-se garantir que o nível de
escrutínio (que au1nenta com o valor do projeto) necessário para aval iar abran-
. . .
gentemente os nscos inerentes esteJa presente.
• Produz-se um documento (Project 011tline) que detalha os riscos envolvidos, os
fatores internos e externos que podem causar um impacto, as estratégias de miti-
gação a serem usadas e uma avaliação da probabilidade de fechar o negócio. Se o
perfil de r isco da oportun idade for considerado aceitável, se tomará a decisão de
prosseguir. O inverso pode ocorrer se o perfi l de risco for considerado inaceitável
e a organização decidir não apostar na oportunidade.
Depois de fechado o negócio, considera-se o perfi l de risco no planejamento geral
dos projetos, no qual os relatórios de projetos que atendem aos critérios específicos
são fei tos mensalmente. Esses relatórios são revisados pela Gerência Executiva em
reuniões mensais do Conselho Diretor, nas qua is o stat11s dos projetos e os riscos em
particular são analisados.
Nos níveis do programa/projeto, o relatório de riscos é feito com mais frequência,
revisando os r iscos em vários pontos de decisão, particularmente ao passar de uma
fase para outra:
• Iniciação - continuidade da identificação e análise profunda dos r iscos
• Planejamento - desenvolvimento e ratificação do Plano de Gestão de Riscos
• Execução - implementação dos planos de resposta a riscos
• Mon itoramento e controle - imple1nentação de ações corretivas, se necessário
• Encerramento - extinção dos riscos
Relatórios são feitos du rante as reuniões da equ ipe de projetos e, se necessário,
são feitas reuniões especificamente para focalizar em riscos em etapas cruciais do
programa/projeto. Incluem-se relatórios também nos relatórios formais de stattls que
são d istribuídos para as principais partes interessadas na frequência documentada
no Plano de Con1un icação do p rogran1a/projeto (mensalmente, no n1ínimo). Alén1
disso, para os programas/projetos que atendem critérios específicos, são enviados
Relatórios Resumidos ao Conselho Di retor para revisão n1ensal (con10 observado
acima).
Lições aprendidas
A ILLUMINAT é uma o rganização baseada en1 conhecimento, na qual um dos ob-
jetivos é auxiliar os clientes em tornar seus negócios bem-sucedidos. Para alcançar
isso, un1a gestão de r iscos eficiente e a aplicação de lições aprendidas relacionadas
a riscos na implen1entação de p rogramas e projetos do portfólio são componentes-
-chave.
Consequentemente, como parte da govemança gera l da gestão de riscos, revisam-
-se os programas/projetos e observam-se denominadores comuns nas abordagens usa-
das e na eficiência dos resultados. Essas observações são, então, usadas para melhorias
de processos na organização (p.ex.: definição de p rocessos padronizados robustos e
critérios para avaliar parceiros de negócios estratégicos).
Conclusão
A gestão de riscos está enraizada na cultura organizaciona l da ILLUMINAT e foi re-
conhecida como uma das est ratégias-chave para garantir a conclusão de progra1nas/
projetos bem-sucedidos. Isso é demonstr ado pelos pensa1nentos expressos pelo CEO
da ILLUMINAT 's CEO, o Sr. David Belgrave:
Acho que (a gestão de riscos) é algo muito positivo. Ela garante que demos atenção sufi-
ciente a um projeto a ntes de entrarmos nele, incluindo o fato de q ue podemos decidir não
entrar no projeto, na pior das hipóteses. No míni mo, porém, avalia mos o risco do projeto,
propomos ações de mitigação, certificamo-nos de da r o grau de atenção e rigor necessários
para garantir o s ucesso do projeto. Essa ação afeta o tempo, o d inheiro, o número e tipo
de recursos necessários e, em última a nálise, o serviço de atend imento ao cliente. Todo o
processo de Avaliação de Riscos ao abordar projetos possibilita um trabalho ma is profissio-
nal e mais lucrativo, no fim das contas. Por meio das técnicas que ut il izamos na gestão de
projetos, conseguimos prever alguns dos problemas bem antes de eles acontecerem e tomar
ações corretivas para manter um programa/projeto no caminho previsto, e esse é um enor-
me benefício para a organização.
Assi m, considera-se que as a bordagens de gestão de riscos utilizadas na ILLUMI-
NAT agreguem valor ao gerenciamento eficiente e eficaz do portfó lio de projetos, e,
por meio da aprendizage1n contínua, podem ser feitas 1nelhorias nessas abordagens a
fi 1n de alca nçar os objetivos est ratégicos da organização e garantir u1n dese1npenho de
crescimento.
5.9 lndra: quando um risco se torna uma realidade

(gerenciamento de problemas)ª
E1n uma empresa como a Ind ra, com milha res de projetos ativos geografica mente dis-
tribuídos, u1na prática sólida e contínua de gestão de riscos é vita l. Isso é exibido na
Figura 5-1 1. As ações que podem conter o impacto que os riscos podem ter sobre os
resultados do p rojeto são pla nejadas e monitoradas durante todo o ciclo de vida do
proJeto.
O percentual de projetos co1n p lanos de riscos e registr os de riscos é muito alto
na Indra . Entreta nto, nós do PMO observamos q ue esses valores não evitavam que
alguns riscos acontecessem e, o que é pior, que out ros r iscos desconhecidos surgisse1n
como problemas que os gerentes de projetos não fora 1n capazes de identificar em seus
planos.
Porém, um problema não está no futuro, e si m já está afetando os ma rcos ou o
cronogra 1na do projeto, ou certos elementos da EAP (Estrut ura Ana lítica do Projeto),
ou o o rçamento a locado ou o nível de qua lidade do p rojeto. Po r esse 1notivo, u1n
problema normalmente exige resposta imediata, e sua resolução precisa ser a bordada
o ma is ráp ido e eficientemente possível pa ra evita r que o utras áreas do projeto seja1n
afetadas .
Achamos que analisar a relação ent re r iscos e problemas é essencia l pa ra uma
abordagem integrada da gestão de riscos. Por meio de um a a nálise pre-morte,n dos
riscos e seus problemas relacionados, sua ordenação e classificação e de por que esses
riscos não foram bem abordados nas etapas anteriores do planeja1nento, procura mos
compreender as ca usas que os originara m e determinar critérios ma is precoces de t ria-
gem de r iscos.
Em u1na segunda etapa, precisa1nos conhecer seus efeitos reais sobre o projeto e se
as soluções p ropostas para conter os efeitos foram eficientes. Isso nos permitirá cria r
um banco de dados e identificar a lgumas lições aprendidas para nos ajudar a identi fi-
1
Material fornecido por Alfredo Vázque2 Díaz, PNlP*, diretor do P!v10 corporativo.
Na fase de preparação da proposta:
Identificação Avaliação inicial

inicial de riscos dos riscos
Na fase de planejamento:
Na fase de monitoramento e controle:
Revisão do Identificação Atualização

status dos de novos do plano
riscos riscos de riscos
Figura 5- 11 Processo de gestão de riscos de projetos da lndra.
car precocemente riscos propensos a se tornarem proble1nas e evitar que eles apareçam
e1n futuros projetos.
Nem todos os problemas são iguais ou afetam a organ ização da mesma manei-
ra. Seu impacto depende do tamanho ou volu1ne do projeto, sua visibilidade interna
ou externa, sua complexidade, variâncias em relação à previsão econômica in icial, o
tempo necessário para colocá-lo no caminho certo ou seu impacto sobre a imagem da
e1npresa.
Tendo feito todas essas considerações antecipadamente, decidiinos foca lizar nos-
sos esforços nos projetos com problemas 1na is críticos. Esses são considerados projetos
que exigem supervisão de perto e, para eles, é essencial identificar a fonte do problema,
seus efeitos imediatos e o prosseguimento do p lano de ação. Para possibilitar isso,
criamos uma nova funcionalidade em nosso Siste1na de Informaçôes da Gestão de
Projetos (SIGP) chamado Registro de Proble1nas. Ta l registro está embutido em nosso
módulo de Gerenciamento de Proble1nas do SIGP.
O Registro de Problemas funciona da seguinte maneira: quando um PMO ou um
usuário responsável pelo controle do projeto analisa um projeto e detecta que ele está
com sérios problemas, o gerente de projetos precisa preencher informações deta lhadas
no módulo de Regist ro de Problemas. Isso pode ser d isparado automaticamente por
meio de um alerta vermelho no SIGP. (Ver Figura 5- 12.)
O gerente de projetos deve descrever os problemas existentes em seu projeto, os
p lanos de ação para lidar com eles e o alvo de recuperação que precisa ser atingido
para trazer o projeto de volta ao caminho certo. Tendo realizado isso, e para evitar que
essa seja uma representação estática do projeto, espera-se que o gerente de projetos
atua lize as informações a cada período de relatório a partir desse momento, indicando
atua lizaçôes do plano de ação e o status do projeto em relação aos alvos in iciais.
O que pretendemos conseguir com o Registro de Problemas? Queremos foca lizar
nossa atenção e nossos esforços em:
• Detectar quais proble1nas surgira1n de riscos anteriormente identificados e quais
não surgiram
• Obter u1na classificação e tipificação homogêneas dos projetos que tinham sido
seriamente afetado por problemas
® 1nd,a (OffCAAfl IMfOIOIATl:)N 111.lKAH USOU.CU
GESTIONA
-
...... -1_
ti
-- ~--~.-.
) p,t,>d lilll(of
-----
-----
My P1 •
(
.' l follco o ,•1
... _---~'----
...__ 1111 • !)
-
_e,,,,._,...,, C..0-1 ~ , , 1 ... ws:n
·-...
., a ....
•••
a
1'.._ C . I - 0 1FCII 1e.,1• •.1t
,.. .,..,.. _ _ . , ..... o
"'' ,,,_ ... , . _ . , _••--01 0
~
g
....... 1.1--1'1,. . . .
a a
°""
a '">~ '!I
-....
,.. , . _ . . , . , _ . , _ ••..,., e
"""' a
"'"" a
a
a
t ----·
"'· - - · · , . - · , · · l
Ulll ..,..__ ,.,.,2'2011

a
a
a
a
a
a
a l ,;W'!)
a I!')121:'.;'!)
"~~ a
-.... a I.MI . . , . _ · - -
OONZ,t.tU. ,1AIWf
""'°~. ~ r . z a a a a '">12'!l
-" -
~
a a a a a a a 11')~ '!1
1
""' a a a a a a a a '">~ '!I 1
Figura 5- 12 Monitoramento de riscos de projetos no SIGP da Indra.
• Aco1npanhar a eficiência dos p lanos de ação relacionados ao problema

• Relatórios auto1natizados e sistemáticos para a gerência da empresa sobre esses
problemas e seus projetos a pa rtir de diferentes perspectivas (unidade de negócios,
solução, tipo de projeto, localização geográfica, etc. )
Historicamente, os esforços de nossa organização era1n voltados à gestão de ris·
cos, relegando o gerenciamento de problemas a um processo secundário, não conec·
tado à gestão de riscos. O gerenciamento de problemas era mais dependente do en·
volvimento e da proatividade do gerente de projetos e, por esse motivo, era abordado
de forma heterogênea, normalmente no contexto de um projeto interno e se1n um
monitoramento de perto e u1n acompanha1nento do problema pela organ ização, que é
o que ocorria com a gestão de riscos.
Com esse novo recurso, o Registro !CU, o registr o e acompanhamento de pro·
jetos !CU e a rastrea bilidade entre riscos e problemas podem ser feitos a partir do
SIGP. Para reverter a d inâmica real, daremos um primeiro passo, aprendendo co1n
proble1nas já ocorridos e, baseados neles, em u1na segunda etapa, nos foca lizaremos na
prevenção de problemas recorrentes, aqueles que foram registrados, diagnosticados e
solucionados por outros gerentes de projetos, obtendo informações inestimáveis para
que gerentes de projetos aprenda tn com a experiência de outros em seus próprios fu-
turos projetos si1nilares.
A solução se encont ra no cerne do proble1na e só conhecendo o problema é que
podemos solucioná-lo e evitá-lo.
5.10 O fracasso da gestão de riscos

Há d iversos motivos pelos quais a gestão de riscos pode fa lhar. Motivos típicos in·
cluem:
• Não conseguir rea lizar a gestão de riscos de forma eficiente

• Não conseguir identifica r os riscos
• Não conseguir medir a incerteza de ocorrência
• Não conseguir prever o impacto, seja ele favorável ou desfavorável
• Ter um orça1nento insuficiente para o trabalho de gestão de riscos
• Ter 1nembros na equ ipe que não compreendem a importância da gestão de riscos
• Temer que a identificação dos verdadeiros riscos possa resultar no cancelamento
do projeto
• Temer que aquele que reconhecer riscos decisivos possa ter u1n reconhecimento
desfavorável
• Sofrer pressão de colegas de trabalho e superiores que querem ver o projeto con-
cluído independentemente dos r iscos
Todas essas fa lhas ocorrem durante a execução do projeto. Aparente1nente, com-
p reendemos e podemos corrigi-las com instr ução e alocação orçamentária adequadas
pa ra as atividades de gestão de riscos. No entanto, ta lvez as p iores fa lhas ocorram
quando as pessoas se recusa1n até mes1no a considerar a gestão de r iscos dev ido a
a lgu1na noção preconcebida sobre sua utilidade ou importância para o projeto. David
Dunha1n discute alguns dos motivos pelos qua is as pessoas evitam a gestão de riscos
em projetos de desenvolvi1nento de novos produtos (DNP; em inglês, NPD, new pro-
duct develo ptnent).9
Discutir riscos no desenvolvimento de novos produtos certamente parece ser algo
d ifíci l. Apesar de a natureza de alto risco do desenvolvimento de novos produtos já
estar i1npregnada na psique corporativa, 1nuitas corporações ainda adotam uma abor-
dagem fatalista em relação à gestão dos riscos. Os motivos para não fica r ansioso ao se
debruçar em riscos difere1n dependendo da função que você ocupa na empresa.
Gerente de programas
• Ded icar tempo à avaliaç.ã o e à gestão de riscos vai cont ra a cultura de ação de
muitas corporações. Citando um executivo, "A gestão de riscos não cria ativos".
• A gerência sente que a aprendizagem pode/deve ser feita no 1nercado.
Gerente de projetos
• Há uma aversão natural ent re os desenvolvedores a se focalizar no lado negativo.
• Rea lçar riscos é cont raintuitivo para as equipes de desenvolvimento que querem
promover a oportun idade ao competir por financiamento para o DNP.
5.11 Definindo a maturidade usando

a gestão de riscos
Durante anos, a maturidade da gestão de projetos era 1nedida pela frequência com que
conseguíamos atender à tripla restrição dos projetos de prazos, custos e desempenho
ou escopo. Hoje, esta1nos começando a medir a maturidade em componentes, co1no as
áreas de conhecimento do Guia PMBOK®. A maturidade hoje é medida em etapas e
componentes, como o nível de desempenho de nosso gerencia1nento de escopo, geren-
9
D. J. Dunham, "Risk Jvlanagement: The Program Manager's Perspecr:ive.,, in P. Bell iveau, A. Griffin e S.
Somermeyer, Tl,e PDMA Toolbook for New Prod11ct Deve/opm ent, Hoboken, NJ: \Viley, 2002, p. 3 82.
ciamente de tempo, gestão de riscos e outras áreas de conhecimento. Gregory Git hens
acredita que o modo como lidamos cotn a gestão de r iscos pode ser um indicador de
maturidade organizacional:'º
Algumas empresas têm maior capacidade de gerenciar riscos, e essas são as mais
consistentes em seu crescimento e lucratividade. Ta lvez o teste mais simples para exa-
minar a maturidade da gestão de riscos seja exa1ninar o nível de autoridade dada ao
gerente de programas [projetos] de DNP [Desenvolvi1nento de Novos Produtos]: se
a autoridade for alta, a organização provavelmente está se posicionando bem para
gerenciar riscos; se a autoridade for ba ixa, então a organizaç.ã o pode estar com a visão
ofuscada. Um outro teste é o uso de listas de verific.aç.ão: se 1narcar o que foi feito em
uma lista de verificação for a única resposta da etnpresa aos riscos, a maturidade o rga-
nizacional é ba ixa. A gestão de riscos fornece [uma] excelente lente por meio da qual
aval iar a capacidade de uma empresa de integrar e equilibrar a intenção estratégica
com as operações.
Muitas empresas ignoram a gestão de riscos porque ainda não viram necessidade
de empreendê-la. Elas percebem sua indúst ria como estável e se foca lizam primordial-
mente em suas riva is competitivas e em seus desafios operacionais. Ao abordar riscos
no nível do projeto, você encoraja a organização a deixar vir à tona novas preocupa-
ções estratégicas.
As principais empresas de DNP possuem uma sofisticada capacidade de gestão de
riscos e " agendam" utn plano de projeto, prestam atenção aos detalhes do escopo do
produto e ao escopo do projeto, usam ferramentas de gestão de riscos, como simula-
ções computacionais e negociações baseadas etn princípios, e documentam seus planos
e premissas. Essas empresas mais maduras são aquelas que consideram os riscos ao
estabelecer as linhas de base e os cont ratos de projetos. Por exetnplo, a Norte) usa utn
conceito chamado "fora dos limites" (011t o/ bottnds ) que dá aos gerentes de progra tna
de DNP a liberdade para fazer trade-o ffs entre tempo, desempenho, custo e outros
fatores. A anál ise e gestão de riscos é u1na importante ferramenta.
Empresas menos maduras normalmente estabelecem uma data li1nite e prestam
atenção a pouco mais do que isso (e, na minha experiência, isso representa a maioria
das empresas). As empresas que usam a regra de decisão de "Respeitar a data de lan -
çamento" caem em uma espécie de aceitação passiva - ocultando os riscos em vez de
gerenciá-los. Remediar situações emergencia is, o que é vulgarmente conhecido como
"apagar incêndios", e gerenciamento de crises caracterizam sua cultura organ izacio-
nal, e seu desempenho estratégico é inconsistente. Essas empresas são como o persona-
gem mitológico Ícaro: voam a lto, mas logo caem, pois ignoraram eventos arriscados
faci lmente reconhecíveis.
5.12 Boeing Aircraft Company

À medida que as empresas vão se tornando mais bem-sucedidas em gestão de projetos,
a gestão de riscos va i se tornando um processo estruturado que é realizado continua-
mente ao longo de todo o ciclo de vida do projeto. Os dois fatores mais comuns que
servem de suporte à necessidade da gestão de riscos são quanto tempo o projeto dura
e que volume de d inheiro está em jogo. Por exemplo, considere os projetos das aero-
naves da Boeing. Projetar e produzir um novo avião pode exigir 10 anos e um investi-
mento financeiro de mais de US$15 bilhões.
10
G. D. Githens, "How to Assess and Manage Risk in NPD: ATeam-Based Approac-h", in P. Belliveau, A. Griffin,
a nd S. Somermeyer, The PDMA Toolbook for New Product Development, Hoboken, NJ: Wiley, 2002, p. 208.
TABELA 5-1 Categorias de risco na Boeing"
Tipo de risco Descrição do risco Estratégia de mitigação de riscos

Financeiro Financiamento à vista e período Financiamento por fases do ciclo de vida
de pagamento baseado no nú- Gerenciamento contínuo de riscos financeiros
mero de aeronaves vendidas Compartilhamento de riscos com empresas subcontratadas
Reavaliação de riscos baseado nos compromissos de venda
Mercadológico Previsão das expectativas do Contato de perto com o cliente, coletando informações
cliente sobre custos, configu- Disposição a fazer um projeto personalizado por cliente
ração e comodidades baseada Desenvolvimento de um projeto de linha de base que possibi-
em uma vida útil de 30 a 40 lite personalizações
anos de uma aeronave
Técnico Devido à longa vida útil de uma Um processo estruturado de gerenciamento de mudanças
aeronave, é necessário que se Uso de uma tecnologia comprovada em vez de tecnologias
façam previsões quanto à tec- de alto risco
nologia e ao seu impacto sobre Processos em paralelo de melhoria de produtos e de desen-
custo, segurança, confiabilidade volvimento de novos produtos
e capacidade de manutenção
De produção Coordenação da produção e Relações profissionais próximas com as empresas subcon-
montagem de um grande núme- tratadas
ro de subcontratadas sem afetar Um processo estruturado de gerenciamento de mudanças
custos, cronogramas, qualidade Lições aprendidas dos programas de outras novas aeronaves
ou segurança Uso de curvas de aprendizagem
De u1n ponto de vista acadêmico, a Tabela 5- 1 mostra as características de riscos

na Boeing Ai rcraft Company. (A ta bela não pretende deixar implícito que os riscos são
mutuamente exclusivos, nem que esses são os únicos riscos existentes. ) Novas tecnolo-
gias podem agradar os cl ientes, mas os riscos de produção aumentam porque a curva
de aprendizagem é a longada com a nova tecnologia em relação à tecnologia aceita.
A curva de aprendizagem pode ser a inda mais alo ngada quando alguns recursos são
projetados personalizadamente para clientes individuais. Alé1n disso, a perda de for-
necedores ao longo da vida de uma aeronave pode afetar o nível de riscos técnicos e
de produção. As relações ent re esses riscos exigem o uso de uma matriz de gestão de
riscos e u1na ava liação de riscos continuada.
5.1 3 Gerenciamento de mudanças

As empresas usam o gerenciamento de mudanças para controla r tanto as mudanças
geradas internamente quanto aquelas impulsionadas pelo cliente no escopo dos proje-
tos. A 1na ioria das empresas estabelece u1n comitê de cont role de configurações ou um
comitê de controle de mudanças para regu lar as mudanças. Para mudanças Ílnpulsio-
nadas pelo cliente, este participa como membro do comitê de controle de configura-
ções. Este comitê trata, pelo 1nenos, das seguintes questões:
• Q ual é o custo da mudança ?
• Q ual é o impacto da mudança sobre os cronogramas do p rojeto?
• Q ue valor agregado a mudança representa para o cl iente ou usuário final?
• Quais são os riscos?
11
As informações desta seção sobre como a Boeing pode caracterizar riscos no projeto de uma nova aeronave
representam a opinião do autor e não necessariamente a opinião oficial da 8-0eing.
O benefício de desenvolver um processo de gerencian1ento de mudanças é que

ele lhe permite gerenciar seu cliente. Quando seu cliente inicia uma sol icitação de
n1udança, você deve ser capaz de prever imediatan1ente o in1pacto da mudança sobre
cronograma, segurança, custos e desen1penho técnico. Essas informações precisam
ser transmitidas ao cliente imediatamente, especialmente se sua metodologia for tal
que nenhuma mudança seja possível devido à fase do ciclo de vida en1 que você se
encontra. Informar seu cliente sobre o funcionan1ento de sua tecnologia é essencial
para conseguir a adesão dele às suas recomendações durante o processo de n1udança
no escopo.
A gestão de riscos e o gerenciamento de mudanças funcionam juntos. Os riscos
geram mudanças que, por sua vez, criam novos r iscos. Por exemplo, considere u1na
empresa em que o gerente de projetos seja responsável pelo desenvolvimento de um
novo produto. A gerência normalmente determina uma data de lança1nento antes mes-
mo de o projeto ser iniciado. Ela quer que o fluxo de receita do projeto comece e1n
determinada data a fim de cont rabalançar os custos de desenvolvimento. Os geren-
tes de projetos veem os executivos co1no seus clientes durante o desenvolvimento de
novos projetos, mas os executivos veem os clientes co1no os acion istas que espera1n
receber um fluxo de receitas proven iente do novo produto. Quando a data de lança-
mento não é cL11nprida, surpresas significam que "cabeças irão rolar" - nonnalmente
as cabeças dos executivos primeiro.
Na ediç.ã o anterior deste livro, afirmamos que a Asea, Bro,vn e Boveri tinha desen-
volvido excelentes processos de gestão de riscos, então é compreensível que a e1npresa
também tenha estruturado processos de gerenciamento de mudanças. Em empresas
excelentes em gestão de projetos, a gestão de riscos e o gerenciamento de 1nudanças
ocorrem continuamente ao longo de todo o ciclo de vida do projeto. O impacto sobre
a qualidade do produto, bem como seus custos e tempo de produção, é continuamente
atualizado e informado à gerência o ma is rápido possível. O objetivo é sempre min imi-
zar o número e a ordem de grandeza das surpresas.
5.14 Outros processos de gerenciamento

O empoderamento dos funcionários e das equipes de t rabalho autogerenciadas con-
quistaram o mundo dos negócios durante o início da década de 1990. Com u1na ên-
fase crescente na satisfaç.ã o do cliente, fazia sentido empoderar aqueles que se encon-
tra tn mais próximos dele - o pessoal que recebia pedidos, enfermeiras, ca ixas, entre
out ros - para agir na resolução das reclamações dos cl ientes. Uma extensão lógica do
empoderamento dos funcionários é a equipe de t raba lho autogerenciada. Trata-se de
um grupo de funcionários responsáveis por gerenciar a si mes1nos nas atividades coti-
dianas e no trabalho que realizam. Isso inclui a responsabi lidade de lidar co1n recursos
e de resolver problemas.
Alguns veem o empoderamento como a base da próxima revolução industrial,
e é verdade que muitas corporações de renome internacional estabeleceram equipes
de tr aba lho autogerenciadas. Entre elas, estão Esso, Lockheed-Martin, Honey,vell e
\1Veyerhauser. Só o tempo d irá se esses conceitos virarão u1na tendência ou se não pas-
sarão de um modismo.
Fazer a reengenharia de uma corporação é um out ro termo para fazer o d ownsi-
zing da organização com a (muitas vezes infeliz) crença de que a 1nesma quantidade de
trabalho pode ser real izada por menos pessoas, a custos mais baixos e em um período
de tempo 1nais cu rto. Como a gestão de projetos propõe fazer mais em 1nenos tempo,
com menos pessoal, parece prático implementá-la como parte da reengenharia. Ainda
não se tem certeza de que o downsizing executado ao mes1no tempo em que a imple-
mentaç.ã o da gestão de projetos funcione, ,nas as organ izações orientadas a projetos
parecem considerar essa opção bem-sucedida.
O custeio do ciclo de vida foi usado pela primeira vez em organizações militares.
Dito de forma simples, ele exige que as decisões tomadas durante o processo de P&D
sejam ava liadas em relação ao custo do ciclo de vida tota l do sistema. Os custos do
ciclo de vida são o custo tota l da organização para a propriedade e aquisiç.ã o do pro-
duto ao longo de toda a sua vida.
O gerencian1ento da tecnologia de informação en1presarial (ITEM, infor,nation
technology enterprise manage1nent) integra todas as disciplinas da gestão de p roje-
tos, juntamente com outras disciplinas de TI con10 engen haria, testes e escritórios
modelo . Mu itos projetos con1eçam com um tern10 de abertura e un1 escopo que
fazem un1 gerente de p rojetos ver o t raba lho con1 o in ício definitivo e un1 fin1 de-
finitivo . (Ver Figura 5- 13 .) Se isso se aplicar às etapas relativas de uma liberação,
eles sin1plesn1ente estendem os grupos de processos de gestão de projetos por toda
a liberação. Isso faz os fornecedores do projeto tentarem con1preender se o design
e a construção fazen1 parte da execução ou se a inljlementação do projeto é a
execução do projeto. Como afirn1a o Guia PMBOK , os grupos de processos de
gestão de projetos devem ser repetidos para cada etapa de liberação. Isso promove
outras estratégias de gestão de projetos, con10 o planejamento em ondas sucessivas
e o equ ilíbrio de recu rsos. Com essa visão da estrutura, outras capacidades poden1
ser aplicadas a cada etapa, juntamente com as capacidades da gestão de p rojetos
(Figura 5- 14).
Etapas do gerenciamento de liberação:

Planejamento Integração Implementação 1 Operações
Grupos de processos de gestão de projeto:
Processos Processos
de iniciação de controle
\
Processos de Processos Processos de
lanejamento de execução encerrament
Não é possível estender as disciplinas do projeto a todas

as etapas de uma liberação
Figura 5-13 Aplicação típica do Guia PMBOK".

Etapas do gerenciamento de liberação:
Planeiamento Integração Implementação Operações
Grupos de processos de gestão de projeto:

Controle
/ Iniciar / '\ '\ Iniciar

c'....,.'"'S:"-P.f~......_ ~ Planejar Encerrar
Executar Executar
Outras capacidades "integradas":

• Planejamento estratégico • Design de hanfware • Avaliações do local • Ponto de serviço
• Previsão de liberação • Design de aplicativos • Aquisições • Resolução de incidentes
• Análise de impacto da liberação • Testes de unidades/sistemas • Instalação de hardware • Gerenciamento de mudanças
• Estudo de viabilidade do diente • Escritório modelo • Teste de aceitação pelo usuário • Gerenciamento de configurações
• Ponto de decisão de passagem • Ponto de decisão de passagem • Ponto de decisão de passagem • Gerenciamento de problemas
de fase do cltente de fase do cliente de fase do cliente
Figura 5-14 Aplicação correta do Guia PMBOK".
5.16 Mensuração do valor agregado

Uma pa rte integra l da maioria das metodologias da gestão de projetos é a capacidade
de rea lizar a 1nensuração do valor agregado, que foi criada de modo que os gerentes de
projetos gerenciassem p rojetos, em vez de meramente mon itorar resultados. Embora
algumas empresas não use1n a mensuração do va lor agregado forma lmente, concei-
tos cent rais como a análise de variância e relatórios estão sendo util izados. Como
exemplo, Keit h Kingston, PMP®, gerente de gerencimento de programas da Motorola,
afi nna:
Variâncias no desempenho do cronograma são analisadas semanalmente ou a cada duas se-
manas, mas não como parte de uma abordagem formal de valor agregado. Mais do que três
dias de variação no cronograma de qualquer deliverable interno exige análise e um plano de
mitigação. Qualquer variância que afete negativamente o cumprimento da data exigida pelo
cl iente exige anál ise e um plano de m itigação.
5.17 DTE Energy

U1na das características dos processos integrados é que eles devem inclu ir uma in-
tegração com um sistema de informações de gestão de grojetos capaz de d ivulgar a
mensuração do valor agregado. Kizzmett Collins, PMP , gerente sênior de projetos
de engenharia de software, métodos e seleção de pessoal na DTE Energy, descreve a
integração com a mensuração do valor agregado.
Con1eçando no início de 2001, o escritório de gestão de projetos (PMO) dos Ser-
viços de Tecnologia da Infonnação (STJ) patrocinou diversos projetos que ajudavan1 a
avançar e desenvolver uma con1preensão e conhecimentos sobre a análise de valor agre-
gado (EVA, earned-value analysis) entre n1embros da gerência e gerentes de projetos.
A implementação do conjunto de programas de gestão de p rojetos Primavera Te-

amP/ay permitiu um fácil acompanhamento de métricas de EVA para projetos ind ivi-
duais e portfólios de projetos. Ent re outras fontes de instruç.ã o, o treina tnento no pro-
duto TeamP/ay apresentou aos gerentes de projetos e à gerência de STI as métricas de
EVA. O PMO desenvolveu processos e relatórios para auxil iar os gerentes de projetos
e a gerência na análise e relatórios das 1nétricas de EVA. O STJ contratou Quentin\'(/.
Flemming para ministrar cursos sobre a EVA, o que aumentou a compreensão da EVA
por parte dos gerentes de projetos e da gerência de STI.
A jornada da análise do valor agregado do STI da DTE Energy

Relatório de métricas de EVA As métricas de EVA (como o Índice de Desetnpenho de
Prazos ou IDP, o Índ ice de Desempenho de Custo ou IDC, a Variaç.ã o de Custo ou VC,
a Variação de cronograma ou prazos ou VPR e a Estimativa no Término ou ENT) são
relatadas semana lmente em relatórios de status do projeto e no portfólio de projetos
do STJ. O gerente de projetos fornece comentários adicionais sobre o status para vari-
âncias que excedam:!: 10%.
Durante as reuniões de planejamento e gerenciamento (PMT, planning and tnana-
gement table), os gerentes de projetos relatam o status do projeto, normalmente todos
os meses. O PMT revisa as métricas EVA e discute as variâncias e indicadores, como
justificado. Out ros desencadeadores que podem necessitar a revisão das métricas da
EVA dos projetos são:
• Um projeto se encontra a 20% de sua duração esti tnada originalmente.
• Uma fase sign ificativa termina.
• O gerente de projetos apresenta problemas, riscos ou mudanças.
Associando recompensas à métrica IDC da EVA

Em 2003, a Organização STI cotneçou a associar recompensas à métrica IDC. Os
resultados da métr ica IDC agora são incluídos tanto nas revisões de desempenho do
gerente de projetos quanto no Scorecard organ izacional do STI.
O Scorecard organizacional do STI é atrelado ao Plano de Recotnpensas ao Fun-
cionário (PRF). O PRF oferece bônus aos funcionários baseados no alcance das metas
corporativas e organ izaciona is A 1nétrica IDC da Organização $TI é o agregado do
IDC de cada projeto do portfól io de projetos. Consequentemente, todos os funcioná-
rios do STI possuem interesses 1nonetários no sucesso de cada projeto.
As metas de desempenho do gerente de projetos incluetn a métrica IDC para todos
os projetos em sua área de responsabilidade. Resultados do IDC entre 0,95 e 1,05
excedem as expectativas de desempenho. A análise do desempenho de cada gerente de
projetos é atrelada ao seu aumento de mérito.
As oportun idades para melhorias na Organ ização $TI int roduziu a EVA à cor-
poraç.ã o por meio do scorecard do STJ. Tanto no STI quanto no resto da corporação,
é necessários que se ofereçam ma is treinamentos com o intu ito de expandir nossa
compreensão comparti lhada da EVA. Internamente, o STI pode dar o próximo passo
em compreender ainda melhor o que as métricas da EVA indicam. Por exemplo, temos
a oportunidade de ser ma is deliberados ao alocar dólares em outro lugar quando o
IDC de um projeto indica problemas de custo.
Cultura
6.0 Introdução
Ta lvez a característica mais sign ificativa das empresas excelentes en1 gestão de pro-
jetos seja a sua cultura. A implen1entação bem-sucedida da gestão de projetos cria
un1a o rganização e uma cult ura que podem n1udar depressa segundo as demandas
de cada projeto e ainda assim se adapta r rapidan1ente a um an1b iente d inâmico e
em constante n1udança, calvez ao mesmo tempo. As en1presas bem-sucedidas preci-
sam lida r com mudanças em ten1po real e conviver com a possível desordem que as
acompanham.
Mudanças são inevitáveis nas organizações o rientadas a projetos. Como cais, as
empresas excelentes perceberam que o sucesso competitivo pode ser alcançado somen-
te se a organização tiver uma cultu ra que promova o comportamento necessá rio. As
culturas corporativas não podem ser mudadas da noite para o dia. Norma lmente são
necessários anos. Além disso, se apenas um executivo se recusar a apoia r uma cultura
de gestão de projetos potencialmente boa, o resultado pode ser desastroso.
No a lvorecer da gestão de projetos, uma pequena empresa aeroespacial teve de
desenvolver u1na cultura de gestão de projetos para conseguir sobreviver. A mudança
foi rápida. Infelizmente, o vice-presidente de engenharia se recusou a aderir à nova
cultura. Antes da aceitá-la, a base de poder da organização era a engenharia. Todas
as decisões era1n ou instigadas, ou aprovadas pela engenharia. Como a organização
poderia fazer seu vice-presidente aderir à nova cultura?
O presidente percebeu o problema, mas passa por cima dele na busca de uma
solução prática. Livrar-se do vice-presidente poderia ser u1na alternativa, mas impra-
ticável devido aos seus sucessos anteriores e ao seu know-how técnico. A corporação
recebeu um projeto de dois anos que era estrategicamente importante para a e1npresa.
O vice-presidente foi, então, temporariamente designado como gerente do projeto e
removido de seu cargo de vice-presidência de engenharia. Na conclusão do projeto, o
vice-presidente foi designado a preencher o cargo recém -criado de vice-presidente de
6.1 A criação de uma cultura corporativa

Cu lturas corporativas podem levar muito tetnpo para serem criadas e entrarem e1n
vigor, mas podem ser destruídas da noite para o dia . As cu lturas corporativas da ges-
tão de projetos baseia1n -se no comportamento organizacional, e não em processos.
As culturas corporativas refletem metas, crenças e aspi rações da gerência sên ior. Pode
levar anos para que se estabeleça a base para que uma boa cultura exista, mas uma
boa cu ltura pode ser destruída rapidamente por meio dos caprichos pessoais de um
executivo que se recuse a apoiar a gestão de projetos.
As culturas de gestão de projetos podetn existir em uma estrutura organizacional.
A velocidade com que a cultura amadurece, no entanto, pode depender do ta1nanho
da empresa, do tamanho e da natureza dos projetos e do seu tipo de clientes, sejam
eles internos ou externos. A gestão de projetos é u1na cultura, e não políticas e proce-
d imentos. Consequentemente, pode não ser possível reproduzir ou fazer o benchmark
de u1na cutura de gestão de projetos. O que funciona bem em uma empresa pode não
funcionar igualmente betn em outra.
Boas culturas corporativas ta1nbém podem estimular 1nelhores relações co1n o
cliente, especialmente com cl ientes externos. Como exe1nplo, uma empresa desenvol-
veu uma cu ltura de sempre ser honesta ao relatar os resultados de testes realizados
para clientes externos. Os clientes, por sua vez, começara1n a tratar a empresa contra-
tada como u1na parceira e co1npartilhavam rotineiramente informações proprietárias,
de modo que cl iente e contratada pudessem se ajudar mutuamente.
Em etnpresas excelentes, o processo de gestão de projetos evolui em uma cultura
comporta1nental baseada em relatórios de múltiplos chefes. Não se pode ignorar a
importância desses relatórios. Existe u1na crença errônea de que a gestão de projetos
pode ser reproduzida de uma empresa para out ra. Benchmarking é o processo de con-
tinuamente se medir e se comparar a uma organização que se encontra em qualquer
lugar do mundo a fim de obter informações que ajudarão a sua organ ização a melho-
rar seu desempenho e sua posição competitiva. O benchmarking competitivo é aquele
no qual se faz o benchmark do desempenho organizacional em relação ao desempenho
de organizações concorrentes. O bench,narking processual é o bench,narking de pro-
cessos discretos em relação a organizações que são líderes nesses processos.
Como uma cultura de gestão de projetos é uma cultura co1nportamenta l, o ben-
chmarking funciona melhor se compararmos as melhores práticas, que são métodos
operacionais, de liderança ou de gerenciamento que levam a um desempenho superior.
Devido à forte influência comportamental, é quase impossível t ransferir uma cultura
de gestão de projetos de uma empresa para outra. Como mencionado anteriormente,
o que funciona betn em uma empresa pode não ser apropriado ou benéfico e1n termos
de custos em outra e1npresa.
Culturas fortes podem se formar quando a gestão de projetos é vista como uma
profissão e apo iada pela gerência sênior. Un1a cultura forte tan1bén1 pode ser vista
como u1n prin1ordial diferencial de negócios. Culturas fortes podem priorizar un1a
a bordage1n de gestão de projetos formal ou inforn1al. Entretanto, com a forn1ação de
qualquer cultura, há se1npre algumas barreiras que têm que ser superadas.
Segundo um porta-voz da AT&T:
A gestão de projetos é apoiada no sentido de o gerente de projetos ser visto como um pro-
fissiona l com habilidades específicas e responsabilidades a serem realizadas como parte da
equipe de projetos. Ele pode escolher sua eq uipe e tem controle completo sobre a a locação
orçamentária? Não. Isso é impraticável em uma grande empresa com muitos projetos que
competem por financiamento e es pecialistas em várias organizações funcionais.
Nem sempre se faz um termo de abertura do projeto q ue nomeia um indivíduo como
gerente de projetos (GP), mas ser designado como gerente de projetos lhe confere o poder
q ue acompanha esse cargo. Em nossa passagem da informalidade a uma maior formalidade,
normalmente se inicia com o planejamento de projeto e o gerenciamento do tempo, e o
gerenciamento de escopo entra em cena um pouco mais tarde.
Capítulo 6 Cultu ra 335
O GP tinha apoio, mas havia barreiras. A maior foi convencer a gerência de que eles
não precisam contin uar gerenciando todos os p rojetos. Eles podem gerenciar os gerentes
de projeto e deixá-los gerenciar os projetos. Uma coisa que ajuda nesse sentido é mudar os
GPs de lugar, de modo q ue eles estejam no mesmo grupo de trabalho, em vez de espalhados
pelas equipes em toda a empresa, e fazer com q ue eles sejam supervisionados por um forte
defensor da gestão de projetos. Uma outra coisa que ajudou foi a execução da missão pelo
PN!COE para melhorar as capacidades de gestão de projetos por toda a empresa, inclusive
influenciando a cultura corporativa q ue serve de suporte a ela .
Nosso sucesso é atribuível a uma visão de liderança que levou a criar uma o rganização
ded icada à gestão de projetos e uma cultura que reconhece o va lo r da gestão de p rojetos
para a empresa. Nossa visão: estabelecer uma d isciplina global de gestão de projetos de má-
xima q ua lidade, criada para maximiza r a experiência do cliente e a umentar a lucratividade
para a AT& T.
Em boas cultu ras, o papel e as respo nsa bilidades do gerente de projetos são cla-
ramente identificados. São também reconhecidos pela gerência executiva e compreen-
didos por todos os me1nbros da e1npresa. Segundo Enrique Sevilla Molina, antigo
diretor do PMO corporativo da Ind ra :
Com base no histórico de nossa empresa e nas práticas q ue colocamos em vigor para ge-
renciar nossos projetos, descobrimos que o cargo de gerente de projetos constitui um fator-
-chave para o sucesso do p rojeto. Nossa teoria e prática de gestão de projetos foram criadas
para oferecer apoio tota l ao gerente de projetos ao tomar decisões e, consequentemente,
para lhe dar responsabilidade total pela definição e execução do projeto.
Acred itamos que ele não seja o único que está à frente do projeto ou que lida com o
orçamento o u o c ro nograma, mas aq uele que ;'compreende e enxerga seus projetos como
se estivesse à frente de seu próprio negócio", como nosso CEO costumava dizer, com uma
abordagem integrada ao seu t rabalho.
Nossa cultura prio riza o apoio aos gerentes de projetos em seu trabalho, aj udando-os
nos processos de tomada de decisões e fornecendo-lhes as ferramentas e o t reinamento ne-
cessários para q ue eles realizem seu trabalho. Essa abordagem permite, até certo ponto, p ro-
cessos formais que não sejam tão rígidos. Isso faz com que a responsabilidade e a iniciativa
do gerente de projetos seja exposta, mas sempre cumprindo com a estrutura e o conjunto de
regras q ue permitem sólidos relatórios contábeis e de resultados.
Podemos dizer que gestão de projetos sempre teve apoio durante as d iferentes etapas
de evolução da empresa, e em todas as suas diferentes unidades de negócios, embora
a lgumas áreas tenham sido mais relutantes em implementar mudanças em sua forma esta -
belecida de realizar o traba lho. Uma das principais barrei ras ou obstáculos é a capacidade
de usa r os mesmos conceitos de gestão de projetos com diferentes tipos de projetos e
produtos.
Ainda é uma grande preocupação em nossos programas de treinamento tentar explicar
como a estrutura e a metodologia se aplicam a projetos com um a lto grau de definição no
escopo e a projetos com um grau de definição menor (projetos d ifusos).
6.2 Valores corporativos

U1na iin portante pa rte da cultura de empresas excelentes é um conjunto estabelecido
de va lores cumpridos po r todos os funcioná rios. Os valores vão além dos manuais
normais de "práticas-padrão" e da moralidade e ética ao lida r com clientes. Garantir
que os va lores da empresa e a gestão de projetos seja1n congruentes é vital para o su-
cesso de qualq uer p rojeto . A fim de garantir essa coerência de va lores, é importante
que metas, objetivos e valores da empresa sejam bem compreend idos por todos os
membros da equipe de projetos.
A gestão de projetos be1n -sucedida pode florescer en1 qualquer estrutura, indepen-
dentemente de quão terrível essa estrutura pareç.a ser no papel, 1nas a cultura da organi-
zaç.ão precisa sustentar os quatro pilares fundan1enta is da gestão de projetos:
• Cooperação
• Trabalho em equ ipe
• Confiança
• Comunicação eficiente
6.3 Tipos de culturas

Existem d iferentes tipos de culturas de gestão de projetos, que variam de acordo com
a natureza, a quantidade de confiança e cooperação e o ambiente competitivo do ne-
gócio. Tipos de culturas tipos incluem:
• Culturas cooperativas: baseiam-se na confiança e na comunicação eficiente, não
somente interna, mas também extema1nente.
• Culturas não cooperativas: nessas culturas, a falta de confiança prevalece. Os fun-
cionários se preocupa1n mais consigo mesmos e com seus interesses pessoais do
que co1n aqu ilo que é melhor para a equ ipe, a empresa ou o cliente.
• Culturas co-rnpetitivas: essas cu lturas força 1n as equipes de projetos a competirem
umas com as out ras por recursos corporativos valiosos. Nessas culturas, os geren-
tes de projeto geralmente exigem que os funcionários demonstrem ma is lealdade
ao projeto do que ao seu gerente de área . Isso pode ser desastroso quando os fun-
cionários estão trabal hando e1n múltiplos projetos ao mesmo tempo.
• Culturas isoladas: ocorrem quando uma grande organização permi te que as uni-
dades funciona is desenvolvam suas próprias culturas de gestão de projetos. Isso
poderia resu ltar em u1n am biente em que há uma cu ltura dentro da outra. Isso
ocorre dentro das unidades de negócio estratégicas.
• Culturas fragmentadas: projetos nos quais parte da equipe está geograficamente se-
parada do resto pode1n resultar en1 un1a cu ltura fragmentada. As cu lturas fragmen-
tadas tan1bé1n ocorren1 e1n projetos multinacionais, onde a sede ou a equipe corpo-
rativa pode ter uma forte cultura de gestão de projetos, mas a equipe estrangeira não
tem un1a cultura sustentável de gestão de projetos.
As culturas cooperativas florescem com comun icações eficientes, confiança e
cooperação. As decisões são tomadas com base nos interesses de todas as pa rtes inte-
ressadas. O patrocínio executivo é ma is passivo do que ativo, e muitos poucos pro-
blemas chegam até os níveis executivos para resolução. Os projetos são gerenciados
mais informal do que formahnente, co1n 1nínima documentação, e muitas vezes com
reun iões marcadas somente quando necessário. Esse tipo de cultura de gestão de pro-
jetos leva anos para ser a lc.ançado e funciona bem sob condições econõmicas tanto
favoráveis quanto desfavoráveis.
As culturas não cooperativas são um reflexo da incapacidade dos me1nbros da
gerência sênior de cooperar entre si e possivelmente sua incapacidade de cooperar
com a fo rça de tra balho. O respeito é inexistente. As culturas não cooperativas podem
p roduzir u1n bom deliverable para o cl iente quando se acredita que o fim justifica os
meios. Entretanto, essa cultura não gera o mes1no nú1nero de projetos bem-sucedidos
que pode ser alcançado com a cu ltura cooperativa.
As cu lturas competitivas podem ser saudáveis no cu rto prazo, especialmente se

houver abundância de trabalho. Os efeitos de longo prazo, porém, não costumam ser
favoráveis. Uma empresa de produtos elet rôn icos pa rticipava continuamente de licita-
ções de em projetos que exigiam a cooperação de três departamentos. A gerência, en-
tão, implementou a decisão nada saudável de permitir cada um dos três departamen-
tos fizesse ofertas de licitação independentes para cada trabalho. O depa rtamento que
consegu isse o contrato t rataria os outros dois departamentos como subcontratadas.
A gerência acreditava que essa competitividade era saudável. Infelizmente, os re-
sultados de longo prazo foram desastrosos. Os t rês depa rtamentos se recusavam a
falar uns com os out ros, e o comparti lhamento de informações cessou. Para realizar
o trabal ho pelo preço cotado, os departa1nentos começaram a terceirizar pequenas
frações de t rabalho e1n vez de usa r os out ros departamentos, que eram mais caros. À
medida que mais e 1nais trabalho ia sendo terceirizado, ocorriam demissões. A gerên-
cia agora percebera as desvantagens de uma cu ltura competitiva.
O tipo de cultura pode ser influenciado pela indúst ria e pelo tamanho e natureza
1
do negócio. Segundo Eric Alan Johnson e Jeffrey Alan Neal:
Cultura orie11t.ada a dados: a cultura orientada a dados (também conhecida como gerencia-
mento baseado em conhecimento) é caracterizada pelo fato de a liderança e os gerentes de
projeto basearem s uas ações cruciais nos resultados de métodos quantitativos. Esses méto-
dos incluem várias ferramentas e técnicas como a estatística descritiva e inferencial, testes de
hipóteses e modelagem. Esse tipo de cultura de gerenciamento é essencialmente dependente
de um sistema de coleta de dados consistente e preciso, criado especificamente para fornecer
mensurações chave do desempenho (métricas). Um programa de análise robusto do sistema
de mensuração é necessário para garantir a precisão e a usabilidade dos dados.
Esse tipo de cultura também emprega técnicas de gerenciamento visual para exibir objetos-
-chave de negócios e programas para toda a população de trabalhadores. A intenção do progra-
ma de gerenciamento visual é não somente exibir o progresso e o desempenho do projeto, mas
desenvolver um senso de o rgulho e propriedade em relação aos resultados naqueles que, em
última análise, são responsáveis pelo sucesso do projeto e programa: os próprios funcionários.
O utra coisa que também é crucial para o s ucesso desse tipo de cultura de gerenciamento
é o treinamento necessário para implementar os aspectos técnicos de tal sistema. Para com
precisão coletar, avaliar e possibilitar a tomada de decisões baseada em d iversos tipos de
dados (dados nominais e intervalos), a organização precisa de especialistas habilidosos em
várias técnicas de análise e interpretação de dados.
6.4 Culturas corportivas na prática

As culturas corporativas se baseia1n em confiança, comun icação, cooperação e tra-
balho de equipe. Consequente1nente, a estr utura da organização se torna menos im-
portante. Reestruturar uma empresa simplesmente para incluir a gestão de projetos
levará a desast res. As empresas devem ser reest ruturadas por out ros motivos, como se
aproximar do cl iente.
Boeing
A gestão de projetos bem-sucedida pode ocorrer en1 qualquer estr utura, independen-
temente de quão insuficiente a estrutura pareça ser no papel, se a cu ltura da organi-
1
Eric Alanjohnson, diretor de programas e encarregado de comraros na Sarellire Comrol Nerwork, AFSCN,
e vencedor do prêmio Kerzner 2006 de melhor gerente de projetos do ano; e Jeffrey Alan Neal, Faixa Prera/
especialista e palestrante em gestão enxuta, métodos quantitativos na Unjversiry of Colorado, em Colorado
Springs, EUA.
zação promover o traba lho em equipe, a cooperação, a confiança e comunicações

eficientes.
Nos primeiros anos da gestão de projetos, as empresas contratadas do setor aero-
espacial e de defesa estabeleceram escritórios de projetos focal izados no cliente para
clientes específicos como a Força Aérea, o Exército e a Marin ha dos EUA. Um dos
benefícios desses escritó rios de projetos era a capacidade de criar uma relação de tra-
balho e u1na cultura específicas para aquele cliente.
Desenvolver uma relaç.ã o ou cu ltura específica era justificável porque os projetos
geralmente tinham décadas de duração. Era como ter u1na cultura dentro de outra.
Quando os projetos desapareciam e o escri tório de projetos não era mais necessário, a
cu ltura daquele escritório de projetos pod ia desaparecer também.
Às vezes, um grande projeto pode exigir uma mudança cultu ra l permanente em
u1na empresa. Esse foi o caso da Boeing co1n a decisão de projetar e construi r o mo-
delo de aeronave Boeing 777. Esse projeto exigia novas tecnologias e uma mudança
radical no modo como as pessoas teriam de trabalhar juntas. A 1nudança cultura l per-
mearia todos os níveis da gerência, dos níveis ma is altos aos trabalhadores da fábrica.
2
A Tabela 6- 1 mostra a lgumas das mudanças que ocorreram. A intenção da Tabela
6-1 é mostrar que, em projetos de grande porte e longo prazo, mudanças culturais
podem ser necessárias.
À medida que a gestão de projetos amadurece e o gerente de projetos recebe cada
vez mais responsabil idades, gerentes de projetos podem ser responsabilizados pela ad-
minist ração salarial. Entretanto, mes1no as empresas excelentes estão tendo problemas
com essa nova abordagem. O primeiro problema é que o gerente de projetos pode não
TABELA 6-1 Mudanças devido ao projeto do novo modelo de aeronave Boeing 777
Projetos anteriores
Situação de novas aeronaves Boeing 777
Comunicações executivas Sigiloso Aberto
Fluxo de comunicações Vertical Horizontal
Processo de pensamento Bidimensional Tridimensional
Tomada de decisões Centralizado Descentralizado
Empoderamento Gerentes Até os trabalhadores da fábrica
Gerentes de projetos Gerentes Até os não gerentes
Resolução de problemas (a forma de) Individual Equipe
Revisões de desempenho (dos gerentes) De via única Via de mão tripla
Foco de problemas de recursos hum.anos Fraco Forte
Estilo de reuniões Sigiloso Aberto
Envolvimento do cliente Muito baixo Muito alto
Valores centrais Resultado/qualidade final Liderança/participação/satisfação
do cliente
Velocidade das decisões Lenta Rápida
Custeio do ciclo de vida Mínima Extensa
Flexibilidade de design Mínima Extensa
' O estudo de caso do Boeing 777, " Phil Condir and che Boeing 777: From Design and Development to
Produccion and Sales'", aparece em H. Kerzner, Project Management Case Studies, 4ch Ed irion, Hoboken,
NJ: Wiley, 2013, p. 97. As informações apresentadas na Tabela 6-1 representam a interpretação de Harold
Kerzner de algumas das mudanças que ocorreram e não são, necessariamente, a opinião oficial da Boeing.
estar na esca la de pagamento da gerência, mas recebe o direito de assinar ava liações
de resultados.
O segundo proble1na é detenninar que método de ava liação deve ser empregado
para funcionários sindical izados. Esse é provavelmente o problema ma is sério, e o
júri não chegou ainda a nenhuma conclusão quanto ao que funcionará e ao que não
funcionará. Um 1notivo pelo qua l os executivos relutam u1n pouco a implementar a
administração sa larial que afeta a gestão de projetos é o envolvimento do sindicato.
Isso muda o quadro drasticamente, especialmente se uma pessoa de um projeto decidir
que um trabalhador sindicalizado é considerado digno de uma promoção, enquanto,
na verdade, seu gerente de área diz: "Não, essa decisão tem que se basear em um cri-
tério do sindicato". Nada é preto no branco nessa questão, e a maioria das empresas
ainda nem chegou a abordá-la.
Midwest Corporation (empresa fictícia)

Quanto maior a empresa, mais difícil é estabelecer uma cultura uniforme de gestão
de projetos. As empresas grandes possuem "ilhas" de gestão de projetos, e cada u1n
deles pode amadurecer em um ritmo diferente. A grande M idwest Corporation tinha
uma divisão que se destacava e1n gestão de projetos. A cultura era forte, e todos apoia-
vam a gestão de projetos. Essa d ivisão ganhou prêmios e reconhecimento sobre sua
capacidade de gerenciar projetos com sucesso. Contudo, ao mesmo tempo, uma divi-
são "i nnã" estava aproximadamente cinco anos atrás da divisão cuja maturidade era
excelente. Durante uma auditoria dessa divisão " irmã", identifica ra 1n -se as seguintes
áreas problemáticas:
• Inúmeras mudanças nos processos devido a novas tecnologias
• Tempo insuficiente alocado pa ra o esforço
• Interferência externa excessiva (reuniões, at rasos, etc. )
• C ronogramas estabelecidos com base em premissas que acabam 1nudando duran-
te a execução do projeto
• Desequ ilíbrio da força de trabalho
• Objetivos diferentes entre os grupos
• Uso de um processo que não pennite nenhuma flexibi lidade de colaborações in-
dependentes
• Incapacidade de discutir abertamente as questões sem algumas pessoas levare1n as
críticas técnicas para o lado pessoa l
• Falta de planejamento da qualidade, do cronogra1na e de acompanhamento do
progresso
• Falta de acompanhamento de recursos
• "Herdar" o projeto de outra pessoa e encontrar pouca ou nenhu1na documenta-
ç.ã o de suporte
• Lidar com o gerenciamento de cont rato ou de agência
• Mudar ou expandir as expectativas do projeto
• Mudar os prazos frequentemente
• Mudanças de última hora nos requisitos
• Pessoas envolvidas nos projetos terem segundas intenções
• O escopo do projeto não está claro desde o início
• Dependência de recursos sem ter cont role sobre eles
• Acusações de terceiros: "Não tenho nada com isso"
• Nenhum processo forma l de estimação de custos
• Falta de compreensão da est rutura analítica do projeto
• Pouco ou nenhum foco sobre o cl iente
• Duplicação de esforços
• Pouca ou nenhu1na informação obtida por meio da "voz do cl iente" sobre suas
necessidades/vontades
• Capacidade limitada de pessoa l de apoio
• Falta de direcionamento da gerência
• Ausência de um executivo convicto para o programa/projeto
• Reuniões 1nal dirigidas
• As pessoas não cooperam com facil idade
• As pessoas se ofendem quando são solicitadas a realizar o trabalho que se espera
que rea lizem, quando tudo o que seus gerentes procuram fazer é desenvolver um
produto de a lta qualidade
• Algu1nas tarefas têm duração desconhecida
• Pessoas que querem se envolver ,nas não possuem as habilidades necessárias para
solucionar o problema
• Dependências: certificar-se de que quando as especificações 1nudare1n, outras coi-
sas que dependem delas também mudetn
• Lidar com a resolução de problemas de emergência sem prejudicar o trabalho
programado
• Superposição de tarefas (três liberações ao mesmo tempo)
• Não ter o pessoa l correto designado às equipes
• Desaparecitnento do apoio da gerência
• O t rabalho começar a "poucos dias do prazo fina l", em vez de "o mais rápido
possível"
• Proteção do seu "domínio" entre funcionários de níveis não gerenciais
• Inexistência da gestão de riscos
• Mudança gradual do escopo do projeto (mudanças incrementa is que são vistas
como "pequenas" no momento em que ocorrem, mas que, sotnadas, representam
grandes incrementos)
• Comunicações ineficientes com atividades de outros países
• Responsabil idades vagas/mudando toda hora (de quem é a responsabi lidade?)
As empresas grandes tendem a favorecer as "ilhas" de gestão de projetos em vez
de uma cu ltura que abranja toda a empresa. Entretanto, há situações etn que uma
empresa precisa desenvolver uma cultura em toda a empresa se quiser pennanecer
competitiva. Às vezes é simplesmente para pennanecer sendo a ma ior concorrente;
outras vezes, é para se tornar uma empresa global.
6.5 lndra: construindo uma cultura coesaª

Na lndra, o papel de gerente de projetos constitu i um fator-chave para o sucesso do
projeto. Isso porque administrar projetos é uma parte central de nosso negócio. Sendo
assim, as po líticas e práticas da empresa são orientadas de ,nodo a oferecer tota l apoio
aos gerentes de projetos e lhes atribuir responsabilidade integral pela definição e execu-
ção do projeto. Nas palavras de nosso antigo CEO: "Os gerentes de projetos precisan1
enxergar seus projetos como se estivessen1 administrando seus próprios negócios".
Essa frase define a base da cultura de gestão de projetos na Jndra, deixando itnplí-
cito que o gerente de um projeto deve ter uma abordagem integrada ao seu trabalho,
não son1ente se focal izando nos principais objetivos atrelados à tripla restrição, cuidan-
do do cronogra tna e das linhas de base de custos, n1as tambén1 tendo un1a perspectiva
3
Material fornecido por Alfredo Vázquez Díaz, PMP'", diretor, PMO, lndra.
de negócios e esti1nulando que se produzam resultados que atenderão aos objetivos das
unidades de negócios (lucratividade, eficiência de custos, desenvolvi1nento de recursos,
produtividade, etc.) Os funda1nentos da gestão de projetos são exibidos na Figura 6- 1.
O PMO corporativo oferece suporte a em torno de 3.300 gerentes de projetos que
precisam de d ireções, missões, estratégias e metodologias claras, além de um conjunto
comum de ferra1nentas e procedimentos para desenvolver seu t rabalho . Somos res-
ponsáveis por desenvolver e atua lizar a IPMM, a Metodologia de Gestão de Projetos
Corporativa. Co1n base nesse desenvolviinento, os requ isitos para atua lizar o SIGP da
empresa são definidos e implementados. Oferece-se suporte contínuo tanto às unida-
des de negócio quanto aos gerentes de projetos individuais, em termos de treinamento
e instrução, networking informal e participação em di ferentes iniciativas relacionadas
à gestão de projetos que são exigidas pelas unidades de negócios. Nosso objetivo final
é const ruir e consolidar uma cultura de gestão de projetos forte e reconhecível na ln-
dra, independentemente da unidade, da área geográfica ou do setor de negócio em que
a gestão de projetos é realizada.
Em 2005, começamos um programa interno de certificação de profissionais de
gestão de projetos (PMP®) para um pequeno grupo de gerentes sênior de programas e
projetos e gerentes de unidsades de negócios. Esse programa de certificação passou a
ser real izado anualmente desde então, e se tornou uma das iniciativas mais procuradas
pelos gerentes de projetos. Os gerentes de negócios cuidadosamente selecionam os
cand idatos que participa1n do programa.
Ao todo, 1na is de 950 profissionais já passaram pelo processo de treinamento de
PMP®. Alcança1nos objetivo de contar de ter concedido 500 certificações de PMP®
até o fim de 2012. Hoje, já contamos com 558 PMPs® e temos e1n torno de outras 40
pessoas aguardando para fazer o teste.
Esses números não teriam sign ificado sem um contexto. Para nós, tê-los alcan-
çado significa que uma grande proporção dos profissionais mais experientes e talen-
Metodologia de GP da lndra
(IPMM) e Instruções
SIGP Metodologia e
Negocla-GEP/ padrões de gestão
Gestiona de projetos
• Desenvolvimento
e atualização da
' metodologia de
GP corporativa
• Define requisitos para

atualização do SIGP
Sistemas de
Informações de Escrll6rlo • Oferece treinamento
gestão de projetos de gestão e instrução em GP
corporativa de projetos no nível corporativo
corporativa
• Oferece suporte de GP
às unidades de negócios
Figura 6-1 Bases da gestão de projetos.

tosos da lndra é ben1 treinada nas melhores práticas de gestão de projetos. Levando
en1 consideração gue nossa metodologia de gestão de projetos, a IPMM, é a linhada
ao Guia PA1BOK"', poderíamos intuir que um PMP®certificado poderia rapidamente
espalhar o conhecimento e a experiência nas melhores práticas de gestão de projetos
en1 sua área de influência, seja ela seu p rogran1a, projeto ou sua unidade de negócios.
Essa é uma n1anei ra que funciona quando se t rata de estabelecer uma forte cu ltura de
gestão de projetos en1 todas as filiais de un1a empresa. (Ver Figura 6- 2.)
Começamos em 2008 con1 a colaboração de PMPs®como instrutores internos que
repassavan1 o conteúdo do curso Gestão de projetos na Indra, criado pelo PMO Cor-
porativo. Esse curso expl ica a Metodologia IPMM e os sistemas de inforn1aç.ão do GP.
Graç.as a essa iniciativa, estamos treinando nosso jessoal no padrão PMBOK®e, ao
mesmo ten1po, a experiência do instrutor de PMP é usada para adaptar a gestão de
projetos ao nosso contexto, usando projetos e serviços que a Indra oferece aos seus
clientes co1no exemplos de tre inamento. Na verdade, essa colaboração ten1 sido un1
sucesso, com resultados positivos para todos os participantes envolvidos:
• PMPs®contri buem para criar Uina cultura de gestão de projetos n1elhor, difundindo
as n1elhores práticas na empresa e tambén1 obtendo Unidades de Desenvolvin1ento
Profissional (PDUs, Professional Development Units ) para n1anter sua certificação.
• Os trainees se conectam diretamente com o conteúdo, sem nenhuma interpretação
que um instrutor externo poderia oferecer, já que o professor é u1n PMP®que sabe
muito bem que problemas precisa1n ser abordados em relação ao gerenciamento
de um projeto e1n nossa empresa.
• Os departamentos de treinamento de RH ta1nbém saem ganhando, pois podem
investir dinheiro e1n out ras áre.as que poderiam precisar de instrutores externos.
• O PMO corporativo, que supervisiona e apoia a consistência da mensagem que
está sendo passada no processo de treina1nento.
No fim das contas, é a lndra como um todo que se beneficia, pois o conteúdo
desse curso de gestão de projetos fo i colocado no formato de e-learning, t raduzido
Programa Cursos internos

de PMP"' padrão PMOs Comunidades de GP
* *
Difusão dos Suporte às
conhecimentos sobre GP empresas locais
• Ministrado anualmente
• Desde 2005 • +550 PMPs'" certificados
• Selecionado pelo PMO • 40 GPs com testes pendentes
• E também Centros • +70 GPs iniciando seu processo
Registrados de de treinamento
Treinamento (REPs) • +950 GPs treinados
Figura 6- 2 Pessoal: instrutores internos.

PROJE(T KIWA(Ã:MO,T AT INORA • 1n dra
GESTIONA 1
Master Plan
TheMaster Plan Is the maln

productof toe planni ng ph.ase
ltshows.ln an lntepatedplan:
Tl'le scope ot me project
lllcproJect sch~ukt '
Thel)fo)ect budpt
:!!r-
...t---·,,...··"'"+-···,-t··"+-···"'"
7
"' t·""' 7
···-···•·-,í,,,-.,.,j<"·'!'~
"' - WBS ''
.., ,
• 1 ....._ ...... . _ .......... .,.,v.....-...............
1 ···r··r···1····~···r ..'!'';l• ·* ··r ···r ··T"···
1
•
····>·:--:·-·>:'f.
····t...!'.. ,1..·i,t·· · '•• •, •••:•••:••:
.····t···j····t· •••:•••
..!'···1 •: •••'"'
..··t·..
•••,.••• t"·ll'···l'·· ·l··· ·,-•··l....,.... I' ... , • ••• ,.•• •
+
Schedule - ~
INSTRVCTIONS:
···
-
•·;i····t···!····t···r···t····a. ···!····t·..
-
oo:onNOI~
lN budetl SIIOWS Wl\efl a,'ld l'IOw N, PM ffiestl mone,y h
tncuc,s tc. lhe ptojc,n
h musl be d,wk114nd Md IO lht óelnllion ohwpe ilnd
Ih$! OI qlllll)' COlmllnPd !Mlh Ih, CU510mPt
----------------------------------'
+
__,, '
Budget
.._
.,,. [~J [~
Figura 6-3 Curso Gestão de proíetos na lndra na plataforma de e-leaming.
para inglês e português e incluído como conteúdo obrigatório nos treina1nentos de

gestão de projetos de todas as empresas da Indra, onde quer que ela esteja local izada
no mundo. (Ver Figura 6- 3.)
Além disso, em 2010, o departa1nento de RH disponibilizou para todos os funcio-
nários u1na plataforma acessada da int ranet e cujo objetivo é pennitir que as pessoas
se conectem, compartilhem e aprendam u1nas com as outras. Essa plataforma (chama-
da de Sharing knowledge, ou compartilhando conhecimento) tem o aspecto de uma
rede social e o objetivo de apoia r a troca de conhecimentos e experiências entre pro-
fissionais. Seu escopo é corporativo e local, e ajuda, de forma rápida e fácil, a disponi-
bil izar conteúdo sobre melhores práticas e 1netodologias, gerenciamento e proble1nas
técnicos, informações de negócios e tetn a possibilidade de criar grupos e comunida-
des, e até 1nesmo de transm itir conteúdo e cursos em formato d igital.
Para nós, a Sharing Knowledge tetn sido uma ferramenta poderosa para manter
nossos GPs informados e em contato com o PMO Corporativo e também continuar
a construir a cultura da gestão de projetos. Criamos o PMPnet (ver Figura 6-4 ), para
profissiona is certificados na lndra que desejare1n manter conta to, ser atual izados co1n
informações sobre qua lquer iniciativa ou atividade interessante, ou simples1nente con-
tri hui r com experiências e ideias.
Além disso, un1a con1unidade de metodologias, à qual todos os funcionários da em-
presa tên1 acesso, inclui inforn1ações relativas à IPMM e suas bibliotecas MIDAS associa-
dos, como mostra a Figura 6- 5. A MIDAS é a estrutura da lndra para os ciclos de vida
de diferentes projetos (consultoria, engenharia, desenvolvimento, integração e serviços)
6.6 maxlT-VCS
Quando você t rabalha em sua própria empresa, geralmente pode se dar ao luxo de
dedicar tempo a mudar a cu ltura da empresa para que ela passe a apoiar ma is a gestão
de projetos. No entanto, quando você tra balha como consu ltor e precisa real izar 1ni-
PMPnet
My Trirnning
~ IIUl'l~lfflfffl
'°""'9'C.~~
......
( : ~ M:IO\ll)!'I$ ~f>Jl!il
"""~-,,~m
' ~ h'11'10 r'll'I
• Wltl'lllilll'!Ull'IU
• ~hlllllOUltn<W
li li :/1 • CWfle (IOU!W$ (llltn.S.
AVIEOOVA/DUU. IXA.l
YOUA TAANl!ff'i WOE
o Ili ~ do~!"'O iff""""1 ~8'
{a'! \"'i,,,Y.,.T,wn:,t;.~{I
> • •
•• "
" •
"
.. .. " "
. "·1
w
a MAATAIVI.Al;;ll_AOAOlNN< 0RMS
li COl'l.,_ht~ 1111~.,_(0lllff!f<k 'tlmtdVIIUII ~ EVA18
e:. ..,..
~
-
_._ ____............../lr,-·"'·"'·-·-··ct>
q!, Ait tOUlll'lilMili J 1011 "-'-1 b 01111$11 (O!Qo,I....,
...... ~ll'-11•" ri 'll1lul MUIOl'I•

~ 1:.-,11.. , ......... _""
CEi ~~,.~d;
g \J$tf ,.,..,,..,11,.
Uif'!IIU~fl
cvu~
ft
....,
Ili P,c,.Jl(ll lt.lll>,iOJmt,ftl(foO<Mtó:t
ÍiJl'WP~""'J...
Figura 6-4
-
"PMPnet'' na ferramenta Sharíng Knowtedge.
~pmp
lagres e1n u1n cl iente que tem uma cultura que se recusa a apoiar a gestão de projetos,
a vida pode ser bem d ifícil. Marc Hirshfield, PMP®, diretor do escritório de gestão de
projetos na maxIT-VCS, afirma:
Como consultor de gestão de projetos trabalhando no estabelecimento de um clie nte, a
cultura da empresa muitas vezes não apoia a gestão de projetos. Normalmente, a reação
inicia l a um GP é o ceticismo, até que um GP lidere uma equipe de projeto e implemente
um projeto bem-sucedido. Q uando percebem a importância da gestão de projetos, in-
cl uindo um plano de trabalho bem definido, relatórios de status, lista de problemas, etc.,
mudam de opinião. Na ma ioria dos casos, a cultura permite que a gestão de projetos
funcione de maneira informal. Entretanto, uma GP pode ser bem-sucedida com uma in-
trodução gradual de ma is metodologias formais a um projeto que criem padrões para
projetos futuros.
Uma barreira cultural específica à aceitação pela organização da função de gestão
de projetos é a percepção de que ta l função consome tempo demais, exige deta lhes
excessivos e que o uso das metodologias e ferramentas de gestão de projetos sobre-
carregam o projeto. Com ênfase excessiva sobre a ferra 1nenta, essa percepção pode se
tomar uma rea lidade. Os projetos funcionam mel hor, e são mais aceitos pela gerência,
se o gerente de projetos focalizar a comunicação como o objetivo, co1n a ferramenta
usada si1nples1nente co1no uma maneira de manter grandes quantidades de tarefas
organizadas e aco1npanhadas em subpartes gerenciáveis.
Um outro grande desafio cultural em nossa indústria é o aumento gradual do es-
copo. As principais partes interessadas, incluindo a gerência, podem solicitar um novo
escopo para o projeto, o que o coloca em risco. U1na forma de superar esse desafio é
ter o documento de escopo preparado e aprovado antes de o projeto começar. Se qual-
quer pessoa tentar au1nentar o escopo, o gerente de projetos pode lembrar o grupo do
MIDAS STARTNOW
GDU 1a rM$1on
MIDAS significa metodologia para o desenvolvimento,
personalização e serviços usada na lndra
••
LISTAGENS I PAPÉIS-PERFIS I PLANEJAMENTOS I FERRAMENTAS I PADRÕES I RECURSOS
MINO MIDO MITO MISO

Necessidade e demanda OesenYOMmento-adaptação Transto,mação S.ivlços
b:opo. s:·l~·;d::, Focallzaoo no Focahzalk> na Focahzalk> em
'.Ccn1u1. acordo:-. e destnvotvlmcnto e 1mplementaÇào. serv,,ços desenvolvidos
a-:ordo do n1,•cl dt: aquisição de soluções 1ntcgraçào. valldaça.o como: garantias.
~r·,1p (SLAI e produtos e cntrcqa 00 produto manutenções. ou
serv,,ços puros
-
ardl1!.ado e csltu!~tado
-- --
Gerenciamento de escopo
~.....,.......
3.3
V.tlldaçto
t
Marco de
V.tlldaç-.11)
e entrerp
"'"°
d!IIÍCIO
t
Tecnologia e suporte t
Figura 6-5 Estrutura MIDAS.
plano original (declaração de escopo) e de como adiciona r mais tr aba lho afetaria o
orçamento e a linha do tempo.
A falta de compromisso das principais partes interessadas ta tnbém é utn desafio
cultura l em nossa indústria. Às vezes, as pessoas queretn ser incluídas no processo de
tomada de decisõe.s, mas não desejam estar presentes nas reuniões. Isso causa atrasos
desnecessários, o que pode afeta r a conclusão do projeto. Uma 1naneira de superar esse
desafio é se encont rar com as principais parte.s interessadas e lhes pedir pessoalmente
que estejam presente.s nas reuniões, verifiquetn suas agendas com antecedência para
garantir que estejam disponíveis ou organiza r encontros setnana is para revisar todas
as decisões e obter sua aprovação antes de prosseguir com o projeto. E1nbora isso
possa ser um t raba lho ext ra para o gestor de projetos, ga rantirá que atrasos desneces-
sários sejam evitados e que se ofereça o suporte necessário.
Acreditamos que algu1nas organizações que nos empregam tenham hoje uma ex-
pectativa de que tenha ,nos certificação de gerente de projetos, o que implica maior
conscientização e maior desejo por gerentes de projetos profissiona is. Essa documen-
tação geralmente é sol icitada como parte de uma solicitação de proposta.
Como p rofissionais de projetos, percebemos a importância de gerenciar o projeto
de um cliente levando em consideração a sua cultura: considerando seus processos de
tomada de decisões, sua govemança forma vers11s informal e o gerenciamento de reu-
niões, a cultura de comunicação, etc. Um bom gerente de projetos é capaz de adaptar
as ferramentas e técnicas de gestão de projetos, adaptando-as à cultura organizacional

do ambiente do cliente.
Internamente, no contexto de integrar duas en1presas de consultoria bem-su-
cedidas a uma terceira, adotan1os un1 forte con1promisso com uma cultura que
apo ia e espera a excelência em gestão de p rojetos. Estamos integrando a gestão
de projetos e outras metodo logias entre as empresas, selecionando o "melhor dos
melhores" como nossos padrões para ferran1entas e templates. Então, t reinamos
os consultores nessas n1etodologias definidas. Estamos desenvolvendo nosso pro-
gran1a de qualidade baseados em expectativas específicas, então, os gerentes de
projetos tên1 incentivos pa ra produzir padrões consistentes. Reconhecen1os que os
projetos geralmente são ben1 ou n1alsucedidos dependendo de sua observância de
un1 sólido fundamento de gestão de projetos, e resolvemos oferecer a estrutu ra de
metodo logias, treinamento e Perguntas e Respostas como suporte aos nossos con-
sulto res e cl ientes.
4
6.7 DFCU Financial
Com US$3,4 bi lhões em ativos, a DFCU Financia l é a ma ior cooperativa de crédito
de Mich igan, EUA, e está ent re as 40 maiores do país. Com um aumento de 318,7%
na receita líquida desde 2000, a DFCU Financial nunca foi tão bem-sucedida, e a im-
p lementação eficiente de projetos desempenho um importante papel nisso. Na raiz de
sua história de sucesso, há u1na lição de como promover o que há de melhor em sua
cu ltura corporativa. A história ta 1nbém serve de prova de que se manter fiel a valores
cent rais é u1na forma garantida de sustentar o sucesso no longo prazo.
1997-2005: superando o passado

Gi rando o relógio de volta ao fim de 1997, tinha acabado de me voluntariar como
gerente de projetos associados ao bug do mi lênio (projetos Y2K) - o possível escopo,
escala e r isco associados a esse projeto assustou a maioria do pessoal. E isso era um
tanto justificável - aquela não era uma empresa conhecida pelo sucesso de seus pro-
jetos. Tive1nos bons resu ltados, porém, e isso me ensinou muito sobre a cultura da
DFCU Financial. Não tínhamos u1na metodologia sofisticada. Não tínha1nos gerentes
de unidades de negócios acostumados a estar formal e ativamente envolvidos em pro-
jetos. Não tínha1nos ne1n mesmo muitos recursos de TI que fossem acostumados a ser
pessoalmente responsáveis por deliverables específicos. O que tínha1nos, no entanto,
era u1n valor cent ral compartilhado de prestar um serviço de qualidade proeminente
- de fazer o que fosse necessário para fazer um trabalho bem feito. Foi incrível para
mim ver como esse valor era eficiente quando combinado com uma amostra bem sele-
cionada de técnicas forma is de gestão de projetos.
Tendo sentido o sabor do sucesso em gestão de projetos, tentamos estabelecer uma
metodologia formal - a teoria era a de que se u1n pouco de gerenciamento forma l de
projetos funcionava bem, muito mais seria mel hor. Apesar de sua beleza burocrática,
essa metodologia não garantia uma conversão de siste1na cent ral bem -sucedida em
meados dos anos 2000. Voltamos à fase de design em relação à gestão de projetos e
estávamos enfrentando uma assustadora lista de projetos solicitados.
• ©2013 por DFCU Financial. Reproduzido com permissão. Todos os direitos reservados.
Com a nomeação de um novo presidente no final do ano 2000, a equ ipe executiva
da DFCU Financial co1neçou a 1nudar. Não levou muito tempo para que a nova equ ipe
avaliasse o "balanço patrimonial cultural". Do lado dos débitos, enfrentávamos diver-
sos desafios culturais que afetavam diretamente o sucesso dos projetos:
• Falta de responsabilização pela execução dos projetos
• Planeja1nento estratégico e priorização tática ruins
• Projetos cont rolados quase que exclusivamente pelo departa1nento de TI
• Gestão de projetos extremamente burocrática
• Empoderamento limitado
Do lado positivo, nosso maior ponto forte ainda era nossa forte cultura de servi-
ços. Com a tarefa de analisar a proposição de valor da empresa no mercado, a antiga
vice-presidente sênior de marketing, Lee Ann Mares, fez as seguintes observações:
Por meio das histórias que s urgiram em grupos de foco com membros e funcionários, ficou
muito claro q ue o legado dessa organ ização era seus serviços extraordinários. Confirmar
que a marca DFCU cuidava de serviços foi a parte fácil. Tornar essa generalidade acessível
e acionável era difícil. Como se quebra um conceito como serviços proe,ninentes em coisas
com as q uais as pessoas possam se identificar em seu trabalho cotidiano? Criamos três
princípios orientadores extremamente claros: faç.a-os "ganhar o dia"; simplifique as coisas;
e seja um especialista. O interessante foi que essas regras simples não só nos deram uma
linguagem comum, mas também nos ajudaram a exigir mais de nós mesmos em muitos
aspectos. Então, trabalhamos com os funcionários de área de toda a organ ização para
elaborar a inda mais os princípios. O resultado foi uma lista de 13 Ações de Marca (Brand
Actions) - coisas q ue cada um de nós pode fazer para prestar um serviço extraordinário
(Tabela 6- 2).
Embora estivéssemos ocupados defin indo nossa marca, estáva1nos, obviamente,
executando projetos. Desde 2000, tínhamos melhorado nossa eficiência operacional
por meio de inúmeros projetos de mel horias de processos. Substituímos diversos de
nossos principa is subsistemas. Lançamos novos produtos e serviços e abrimos novas
fi liais. Tornamo-nos cada vez melhor na execução de projetos, devido, e1n grande par-
te, a várias mudanças específicas que fizemos no modo como lidávamos com projetos.
Quando observamos ma is de perto o que essas mudanças sign ificavam, ficou claro sua
forte congruência com nossos Princípios Orientadores e Ações de Marca. Por mais
simples que possa parecer, torna1no-nos melhores em gestão de projetos 1nantendo-nos
fiéis à nossa marca.
Ação de marca - responsabilidade

O cont role de projetos foi uma das prÍlneiras coisas a mudar. Historicamente, o depar-
tamento de TI contro lava com exclusividade a maioria dos projetos. Os gerentes de
projetos da empresa até se reportavam ao CIO. Co1no ex-principa l executivo financei-
ro, Eric Schomhorst comentou: "A ma ioria dos projetos tinha um patrocínio fraco ou
ausente do lado dos negócios. Para mel hor estabelecer a responsabilidade pelo projeto,
tiramos os gerentes de projetos do depa rtamento de TI e agora os designamos para
trabalhar com o gerente de uma unidade de negócios somente para projetos de gran-
de escala. Os gerentes de projetos dese1npenham u1n papel mais admin istrativo e de
faci litação, enquanto o gerente da unidade de negócios assume reahnente a liderança
do projeto".
Atua lizamos a e1nenta de nosso curso de liderança, que todos os gerentes precisa1n
concluir, passando a incluir um curso mu ito básico de gestão de projetos, estabelecen-
do a base para futuros desenvolvünentos profissiona is nessa área.
TABELA 6-2 Ações de marca da DFCU Financial

Faça-os "ganhar o dia" - Simplifique as coisas - Sej a um especialista
Voz Reconhecemos os membros de equipe como a chave para o sucesso da empresa, e o
papel de cada membro de equipe, bem como suas contribuições e suas opiniões são
valorizadas
Promessa A promessa de nossa marca e seus princípios orientadores são a base do nível de
serviço inequívoco da DFCU Financial. A promessa e os princípios são os objetivos co-
muns que compartilhamos e que devem ser conhecidos e assumidos como obrigação
por todos nós
Objetivos Comunicamos os objetivos e as principais iniciativas da empresa a todos os membros
da equipe, e é responsabilidade de todos conhecê-los
Clareza Para criarmos um ambiente de trabalho participativo, todos temos o direito a ter expec-
tativas bem definidas para nossos cargos, treinamento e recursos de suporte e uma voz
no planejamento e implementação de nosso trabalho
Trabalho em equipe Temos a responsabilidade de criar um ambiente de trabalho em equipe, apoiando uns
aos outros para atendermos às necessidades de nossos clientes
Proteção Temos a responsabilidade de proteger os ativos e as informações da empresa e de
nossos membros
Respeito Somos membros de uma equipe que servem a outros membros e, como profissionais,
tratamos nossos membros e uns aos outros com respeito
Responsabilidade Assumimos a responsabilidade de nossos problemas e reclamações até eles serem
resolvidos ou encontrarmos um recurso apropriado que os assuma
Empoderamento Somos empoderados com expectativas definidas para tratar e resolver problemas dos
membros
Atitude Adotamos uma atitude positiva todos os dias, uma atitude de "faremos isto - este é meu
trabalho!"
Qualidade Usamos os padrões de qualidade dos serviços em cada interação com nossos mem-
bros ou outros departamentos a fim de garantir a satisfação, a fidelidade e a retenção
Imagem Orgulhamo-nos de nossa imagem profissional e a apoiamos por meio do cumprimento
das diretrizes do código de vestimenta
Orgulho Somos "embaixadores" da DFCU Financial falando positivamente da empresa e comuni-
cando comentários e preocupações para a fonte apropriada
Princípio orientador - facilite as coisas

Com a propriedade do projeto mais claran1ente estabelecida , tan1 bén1 si mplifica-
mos nossos processos de p lanejan1ento e acompan han1ento de projetos. Con1eçamos
acon1pan hando todos os grandes projetos corporativos e d ivisionais em un1a única
p lanil ha que era revisada n1ensalmente pela equipe executiva (ver Tabela 6- 3 para
os cabeçal hos dos relatórios). A pr io ridade dos p rojetos estava atrelada às nossas
iniciativas est ratégicas. Nossos recursos limitados era m, en tão, aplicados aos p ro-
jetos de n1aior in1pacto e importância. Eric Scho rnhorst comentou, "Si mplifica r os
formulários e processos de gestão de p rojetos nos permitiu nos focalizar na identi-
ficação de possíveis obstáculos e problemas. Melho ran1os m uito na gestão de riscos
do projeto".
Ação de marca - objetivos

O pr incipal executivo de informações, Vi nce Pittigl io, lembrou-se do pro blema do le-
gado do excesso de comprometimento do departamento de TI. "Sem um planejamen-
to estr atégico e tá tico eficiente, o que gerenciávamos era 1nais co1no uma "lista de
desejos" de projetos do que um verdadeiro po rtfó lio de projetos impo rtantes. Nós,
do departamento de TI, fa ríamos nossa lista de pri ncipais projetos de infraest rutura
TABELA 6-3 Lista de cabeçalhos dos relatórios de projetos corporativos da DFCU Financial
Nome da coluna Conteúdo da coluna

Prioridade 1 = lnfonnado ao comitê/ou alta prioridade
2 = Alta prioridade
3 = Prioridade corporativa, mas pode ser prorrogado
4 = Focalizado na unidade de negócios ou concluído quando o tempo permitir
Projeto Nome do projeto
Descrição Breve explicação, especialmente para novas iniciativas
Status do documento R = Requisitado
de requerimento V= Recebido
N/A = Não necessário
Statu s Fase (descoberta, desenvolvimento, implementação) e percentual con-
cluído da fase atual
Encarregado da área de negócios Gerente da unidade de negócios que é encarregado do projeto
Gerente de proj etos Pessoa atribuída a esse papel
Prazo de entrega previsto Ano/trimestre planejado para entrega
Recursos Áreas funcionais ou equipe especifica envolvida
Notas do projeto Breve narrativa sobre os principais marcos ou problemas que estão por vir
todo ano. Ao longo do ano, gerentes ind ividuais ad icionariam novos projetos à nossa
lista. Gera lmente, muitos desses projetos tinham pouco a ver com o que estávamos
realmente tentando alcançar em termos estr atégicos. Tínhamos mais projetos do que
poderíamos rea lizar eficientemente e, honestamente, 1nuitas vezes priorizávamos pro-
jetos com base na conveniência para o departamento de TI, em vez de no que seria
melhor para a organização e nossos membros." Focal izar nas principais iniciativas
possibilitava dizer "não" para pro jetos de baixa prioridade que não agregava1n valor
ou que simples1nente não eram do interesse de nossos membros. E o novo parâmetro
para medir o sucesso de um projeto era não meramente se a parte de TI do projeto
estava concluída, mas si1n se o projeto tinha cumprido seus objetivos mais amplos e
cont ribuído para o sucesso da empresa co1no um todo.
Ação de marca - trabalho em equipe

Historicamente, a DFCU Financial era u1na organização funciona l e forte. A colabo-
ração interdepartamental era rara e ocorria somente sob condições 1nuito específi-
cas. Essa dinâ1nica cultural não oferecia um ambiente ótimo para projetos. A reunião
mensa l de revisão de projeto reunia toda a equipe executiva para discutir todos os
projetos atuais e futuros. A equipe decidia que projetos era 1n de maior interesse para
a o rgan ização como um todo. Essa colaboração crítica contribuía para a const rução
de equipes de projeto multifuncionais mais eficientes. Começamos a desenvolver u1na
boa intuição de quando u1na equipe ou departamento específico precisava se envolver
em um projeto. Passamos, ta1nbém, a compreender melhor o conceito de que nosso su-
cesso ou fracasso seria algo que alcançaríamos juntos e começamos a trabalhar juntos
melhor do que nunca.
Ação de marca - empoderamento

Hoje principal executivo operacional aposentado, Jerry Brandman comenta: "nossos
funcionários sempre foram positivos e agradáveis, mas nunca foram encorajados a dar
sua opinião, especia lmente para a gerência. Isso geralmente tinha um impacto negativo
direto sobre os projetos - as pessoas previam problemas, mas sentiam que não era de
sua responsabi lidade soar o ala nne. Grande parte do medo estava relacionado a não
querer causar problemas aos outros. Esta tnos tentando tornar confortável para as
pessoas levantar questões. Se o rei está nu, queremos que a lguém se man ifeste ! Para
fazer as pessoas visualizarem a obrigação que têm de se manifestarem, peço que elas
imaginem estar andando de trem e que elas acham que sabem de algo que poderia co-
locar a viagem etn perigo. Elas têtn a obrigação de puxar a corda e parar o tretn. Isso
não tem sido fácil para as pessoas, ,nas esta1nos fazendo progressos diários".
Ação de marca - qualidade

No passado, a implementação de projetos na DFCU Financial seguia u1na abordagem
de big bang, ou "grande explosão" - implementar tudo ao 1nesmo tempo para todos.
Quando "os p lanetas se alinhavam", o sucesso era possível. Na maioria das vezes, po-
rém, as coisas não eram tão simples. Jerry Brandman afi nna: "Você deve ter um pro-
cesso para lançar as coisas para seu público. Você também precisa sondar a situação
com um piloto de pequena escala sempre que possível. Isso permite que você modifi-
que e ajuste seu projeto à luz de um verdadeiro feedback". A maioria dos funcionários
têm conta na DFCU Financial, então achamos que tínha ,nos um público conveniente
para pi lotos em projetos 1na iores como o uso de caixas elet rônicos para conversões de
moeda com cartões de débito e a intr odução do sistema de ext ratos elet rônicos eSta-
tements para garantir que tudo funcionasse corretamente antes de lançá-lo para todos
os nossos membros.
Em conclusão, a melhor prática ma is significativa da DFCU Financial foi nos
mantermos fiéis aos nossos valores culturais centr ais de prestar serviços extraordiná-
rios . Ao trabalhar na definição desse valor e encontrar maneiras de torná-lo acionável,
também estáva1nos fazendo mudanças no modo como abordamos a gestão de projetos
que estavam bem a linhados aos nossos valores. Nosso compromisso com a fidel idade
à nossa marca nos ajudou a:
• Transferir a responsabilidade pelo projeto do departamento de TI para as unida-
des de negócios
• Simplificar os formulários e processos de gestão de projetos
• Usar reuniões de revisão de projeto para estabelecer prioridades e a locar recursos
mais eficientemente
• Superar as barreiras organizacionais e encorajar contribuições sobre os projetos
de indivíduos de toda a organização
• Melhorar o sucesso do projeto por meio de pilotos e feedback
Como presidente e CEO, Mark Shobe resumiu, em 2005: "boas coisas acontecem
quando você tem integridade, quando você faz o que disse que faria. As 1nelhorias
que fizemos ao lidar com projetos vieram naturalmente de nosso cotnprom isso coleti-
vo com reahnente cu tnprir a pro1nessa de nossa marca. Progredimos muito no ,nodo
como gerenciamos projetos? Sim. Tudo está onde gostaríamos que estivesse? Ainda
não. Estamos indo na direção certa? Pode apostar que sim. E temos um mapa excelen-
te para indicar o caminho".
2005-2009: preparado para o crescimento

Então, aquele mapa era bom mesmo? O material precedente foi escrito no início de
2005. Por medidas objetivas, os anos fiscais de 2005 a 2008 foram bons para a DFCU
Financial (ver Tabela 6-4). Com ma is de US$2 bi lhões em ativos no fina l de 2008, a
cooperativa de crédito estava em 1O" lugar entre suas concorrentes nas medidas 1nais
importantes.
Então, de un1a perspectiva puran1ente financeira, a DFCU estava se saindo 1nuito

bem, especiahnente dado o cli1na econômico global no início de 2009 e o fato de a
DFCU estar, de n1odo geral, atendendo a n1en1bros associados ao setor da indústria au-
tomobi lítica, que faz parte da notoriamente problemática econon1ia de Michigan, EUA.
As finanças sól idas foram o resultado dos esforços da administração atual ao lon-
go de um período de oito anos para simplificar e melhorar as operações, esclarecer
a marca e a proposição de valor da DFCU e iniciar processos eficientes de seleção e
execução de projetos.
Embora esses esforços estivessem em andamento, a equipe executiva e o conselho
diretor estavam avaliando uma métrica problemática - uma 1nétrica que podia solapar
a capacidade da empresa de sustentar seus sucessos recentes: a DFCU não ganhava
novos membros há muitos anos - uma tendência que estava afetando quase todas as
cooperativa de créditos dos EUA. Portanto, eles estavam foca lizados na questão cru-
cial e estratégica do crescimento. E, mais uma vez, a 1narca e os princípios orientadores
da DFCU estavam ajudando a moldar os resultados.
Ações de marca - voz e qualidade; princípio orientador - faça-os

"ganhar o dia"
E1nbora a equipe executiva e o conselho diretor da DFCU explorassem várias opções
de crescimento, o trabalho de seleç.ã o de um novo sistema centra l de processamento
começou em meados de 2005. O projeto de conversão do sistema central era visto
como u1n imperativo estratégico para o crescimento, independente da estrutura ope-
racional da DFCU. A conversão de sistema anterior em 2000 sofreu uma péssi1na
execução que deixou co1no legado problemas pendentes de dados e processos que
precisavam ser solucionados. No início do projeto de conversão, que começou for-
mahnente em janeiro de 2006, a conversão estava programada para outubro daquele
ano. Desde o início, porém, enfrenta1nos dificuldades com o fornecedor do siste1na.
Ele estava passando por uma de suas maiores expansões de seu pipeline de clientes e
estava tendo dificuldade para satisfazer todas as demandas dos projetos de conversão
de seu pipeline. O impacto sobre nós foi perceptível - alta taxa de rotatividade e1n
membros-chave do projeto do fornecedor, deliverables de má qualidade e falta deres-
ponsividade quanto aos proble1nas de conversão. Devido à má qua lidade dos cortes de
dados, a data de conversão do projeto estava em sério risco e1n junho.
TABELA 6-4 Resultados da DFCU Financial para o trimestre que terminou em

30 de setembro de 2008
Resultado Classificação
Média nacional Média regional Concorrentes Concorrentes
Mét rica DFCU das concorrentes' das concorrentes' nacionais regionais
Retorno sobre 1,94% 0,42% 0,77% 1 1
ativos
Retorno sobre 13,98% 4,23% 7,19% 2 2
capital próprio
Índice de eficiência 49,57% 65,41% 69,31% 5 3
capital/Ativos 13,91% 9,82% 10,69% 2 9
Total de ativos US$2,0 Bi US$3,4Bi US$1 ,0 Bi 39 5
1
Cinquenta maiores cooperativas de crédito medidas pelo total de ativos.
2
Cooperativas de crédito com pelo menos US$500 milhões em total de ativos nos estados do Michigan, Pensitvânia, Ohio,
Indiana, Illinois, Wisconsin e Minnesota, EUA.
Devido ao seu escopo, o projeto de conversão de sistema foi o único projeto cor-
porativo comissionado e1n 2006, e toda a atenção estava sendo voltada para ele. Não
era uma tarefa fácil, portanto, entregar a mensagem de que o projeto estava passando
por problemas. "Mark estava ciente de estáva1nos tendo dificuldades quando nos sen-
tamos para discutir se teríamos uma conversão suave em outubro», comenta o princi-
pal executivo de informação, Vince Pittiglio. "Já tinha precisado da r 1nás notícias antes
para outros chefes, mas a conversa que tive com Mark foi 1nuito diferente de todas as
anteriores." Nosso objetivo declarado com essa conversão era praticamente não cau-
sar nenhum dano. Todos concordamos que não podíamos fazer nossos membros ou
nossos funcionários passar pelo mesmo tipo de conversão pelo qua l tínhamos passado
e1n julho de 2000. Precisávamos fazer o melhor possível. Segundo Pittigl io, "Explicitei
os principais problemas que estávamos enfrentando e o fato de que nenhum de nós no
projeto acreditava que eles poderiam ser resolvidos até a data de outubro. Se manti-
véssemos a data original, acreditávamos que afetaríamos negativamente a experiência
dos 1nembros". Mas nosso CEO, Mark Shobe, foi muito claro - ele insistiu que esse
projeto fosse uma experiência de qual idade tanto para os membros quanto para os
funcionários, co1no todos tínhamos concordado desde o início, e ele estava d isposto
a ad iar a data e coloca r out ras iniciativas em suspenso pa ra garantir o sucesso da
conversão. A equipe do projeto concordou com u1na data revisada para a conversão
no início de junho de 2007. Segundo a gerente de projetos e vice-presidente sênior de
conversão, Ma rtha Peters, "E1nbora a equipe continuasse a enfrentar dificuldades com
o fornecedor, trabalha ,nos pesado e fizemos nosso traba lho sem maiores problemas.
Fez uma verdadeira diferença saber que os principa is executivos e o conselho d iretor
tinham levado nosso feedback a sério. No final das contas, nenhum problema grandio-
so aconteceu para nossos me1nbros e funcionários, exatamente como quería1nos que
fosse. Foi uma decisão difícil adiar a conversão, uma decisão que muitas empresas não
estão dispostas a toma r. Mas foi uma decisão acertada - nós realmente tentamos nos
manter fiéis à nossa marca."
Ação de marca - clareza e trabalho em equipe

Quando a conversão de sistema foi concluída, em junho de 2007, só tínha ,nos nos
envolvido em u1n projeto nos dois anos anteriores, ainda que um projeto de grande
escala e importância estr atégica - que foi conscientemente adiado em oito meses. Esse
projeto sugou nossos recursos, e muito pouco foi rea lizado naqueles dois anos. "Ter-
minar a conversão de sistema era uma demanda acumulada enorme. E todos achavam
que os problemas que sua divisão estava enfrentando eram, é claro, os mais urgentes",
comenta o antigo principal executivo financeiro, Eric Schornhorst. "Descobrimos ra-
p idamente que nossa úti l lista de acompanhamento de projeto e nossa reunião corpo-
rativa mensal eram ferramentas insuficientes para priorizar como alocar nossos escas-
sos recursos." U1na pequena equipe foi rapidamente formada para criar um processo
para inica r e aprovar projetos ma is eficiente e consistentemente. Um objetivo principal
pa ra essa equipe era min imizar a burocracia, tentando estabelecer, ao mes1no tempo,
a lgu1na estrutura útil, incluindo uma revisão preliminar de todas as novas solicitações
da d ivisão de TI. O resu ltado foi um simples fluxograma que deixava todos os passos
do processo de solicitação e aprovação mui to claros para todos (ver Figura 6- 6) e um
formulário que integrava as intruçôes de cada seção. Como o vice-presidente sênior
de recu rsos humanos relatou na época, "Meu grupo foi um dos primeiros a usar o
novo processo. Foi surpreendentemente bem pensado e fácil de usa r. Convencemos
a empresa a substituir nosso sistema de gerenciamento de aprendizagem por uma so-
lução terceirizada mais robusta . Foi um dos projetos que entrou na lista de 2008.
Honestamente, estávamos rea lmente no momento da história de nossa empresa em
,- - - -- - -1> Fase1 + -- -- --,

' ' ,,,- -------- + fase3 + --------,
' '
Dono de nerpcacrs
(busio'lt!ss OWlll!l'J
ldetltttlu neces-
sidade de projelo
Cootdenador de
Dono de negócios projetos cotpOtat!YOS
'""''"'º
lorrnulàl'o de
CPC) adlCiCll'la pro,etol - -
à pauta. cb reuni:.O
SOIICl'laÇAO de prOjel.O Nlo
0000 de neg IOS

etl\ta &-mall de Cootdenador de Equipe de projetos
SOIIOtJçatl pari a projetos CO(p(N'atlvos co,porillMlS ldentlflea
equipe de pro,elOS coloca o projeto em et\Ull)e", GP, ptalOS
c«pora!lyos e revisao l sta de pendêncras e pfb'ld.ldes
del)f0f!1os IM&O
\·-- -~- --- --- --- -- ---------------

>--NlO- Sim
...
, ,--------• fase 4 + ------ '
~---- -------------------#
- ----- t - +
Sim
Fase 2
1
oooJenador de
'
+ - ----- , projetos CO(pol'l!IYOS
' ' coroca. o projeto na
liSta de projetos
cor ratt#Os
Sim
1 Dono de negóclcls
eotnpleli os
Dono de negôcaos requis.los do
oonvoca reunlao prOjel.O
com os presentes
SOIIC!Udos
' ---------------------------'
''
~------------------------'
. ,
Figura 6-6 Processo de iniciação de projetos na DFCU Financial.
que precisávamos de um pouco 1nais de d isciplina nesse processo. Em out ros anos,
defendíamos independentemente nossos projetos na hora da aprovação do orça1nento
com os líderes de nossas divisões. Se tivéssemos aprovação orçamental, víamos nosso
projeto como fazendo 'parte da lista'. Quando chegava a hora de realmente executá-lo,
no entanto, geralmente tínhamos problemas com o recrutamento de todos os recursos
das diferentes áreas que precisavam ser envolvidas, especialmente os do TI".
O novo processo cont ribuiu não somente com a clareza relativa aos projetos cor-
porativos, mas com o t rabalho em equipe também. Como Schornhorst tinha refleti-
do no final de 2008, " Revisamos os projetos solicitados para 2009 usando o novo
processo. Embora não tenhamos dado conta cotnpletamente do acúmulo de projetos
criado pela conversão de sistetna, ta tnbém temos um outro projeto que provavelmente
tomará a ma ioria dos recursos em 2009. Isso não é boa notícia para áreas cujos pro-
jetos a inda não foram abordados. O que é interessante, porém, é como houve pouca
contenção quando revisamos a súmula de 2009 - e tivemos de colocar mu itas coisas
importante 'em banho maria'. Acho que quando você faz todos revisarem os fatos
simultaneamente, é mais fáci l obter um conjunto de prioridades que faz sentido para
a organização e que se apoiam mutuamente independente de seus interesses pessoais.
Isso ajuda a despertar o melhor de cada um de nós."
Então, aonde o mapa nos levou?

No início de 2009, a DFCU Financial estava preparada para aumentar o número de
seus membros. Após uma revisão de opções de charter, o consel ho diretor e a equipe
executiva decidiram permanecer como uma cooperativa de crédito, ,nas buscar outros
caminhos para o cresci tnento . Com essa fina lidade, no início de 2009, o consel ho
d iretor apresentou uma proposta aos membros da DFCU para voto sobre uma fusão
com a cooperativa de crédito CapCom, que possuída nove fi liais nas áreas centro-sul
e oeste de M ichigan, EUA. Segundo o antigo principal executivo operacional, Jerry
Brandman, "Consideramos 1nu itas opções diferentes para abordar nossa visão est ra-
tégica de crescimento e expansão de nossos membros - de fusões a várias estratégias
internas de crescimento. Apesar de nós, na indústria de cooperativas de crédi to estar-
mos atuahnente enfrentado os mesmos desafios que out ras instit uições financeiras,
tambétn somos uma indústria fa ,nosa pela qua lidade de nossos serviços. E aqu i na
DFCU Financial nós não somente falamos sobre serviços - nós os prestamos. Nossos
funcionários são fel izes e entusiasmados. Tratam nossos membros 1nu ito bem. Fomos
classificadas entre as 101 melhores melhores empresas para se t rabalhar no sudeste de
M ichigan por cinco anos consecutivos, baseado em feedback de nossos funcionários. E
temos utn programa de member shops que nos mostr a como nosso serviço se cotnpara
aos benchmarks da indústria. Nosso desetnpenho foi, consistentemente, do ma is alto
nível de serviço em relação às nossas concorrentes. A fusão com a CapCom e a passa-
gem a um charter comunitário nos propiciará o crescimento de que precisamos para
garantir um futuro promissor para nossos membros e funcionários. Isso nos permitirá
d ifundir a marca DFCU para outr as áreas geográficas. Acreditamos que essa proposta
será at raente para nossos mem bros e será betn -sucedida. Acreditamos que as pessoas
quei ram fazer parte de nossa organização."
E tên1 bons motivos para isso. Tan1bém no início de 2009, a DFCU Financial pagou
utn dividendo de patrocínio de US$17 mi lhões aos seus men1bros pelo terceiro ano
consecutivo, son1ando utn total de 1nais de US$50 mil hões desde o começo, durante utn
dos piores cenários econômicos a afetar a Motor City etn décadas. Segundo Keri Boyd,
vice-presidente sênior de 1narketing na época, "Como estamos co tnprometidos en1 per-
manecer sendo u1na cooperativa de crédito, procuramos 1naneiras de melhorar nossa
proposição de valor aos membros existentes e atra ir novos membros. O dividendo de
patrocínio é a pedra fundamental de nossa abordagem para expandir o negócio co1no
u1na cooperativa de crédito". Con10 resumiu Mark Shobe, "O conselho diretor e eu
não quería1nos começar a fazer os paga1nentos até tennos a certeza de que podería1nos
sustentá-lo ao longo dos anos. Exigiu utn traba lho pesado, a lgu1nas decisões difíceis,
u1na excelente execução de projetos e diligência en1 nossas operações cotidianas para
estar na posição de compartilhar nosso sucesso con1 nossos n1en1bros. A verdade é que
a força 1notriz por trás de nosso sucesso é nosso con1prometi1nento coletivo com nossa
1narca." Então, con1 un1 cronograma de projetos acordados para 2009, u1na possível
fusão se aproxin1ando no horizonte e alguns n1en1bros muito, n1uito satisfeitos, con10 o
1napa da DFCU está funcionando? "Muito ben1, obrigado!", responde Mark.
2009-2013: pagando dividendos de mais do que uma só maneira

Durantes esse período ma is recente da história da DFCU Financia l, fizemos grandes
p rogressos em nosso objetivo estratégico de crescimento. Concluímos a fusão com a
CapCom no final de 2009, o 1nesmo ano em que começamos a di ligência prévia para
u1na outra fusão cotn a corporativa de créd ito M id\Vest Financia l, sed iada em Ann
Arbor, Michigan, EUA. A fusão com a MidWest foi concluída no início de 2011. Em
janeiro de 2012, abrimos uma nova filial que construímos em Novi, M ichigan, EUA,
e quando este livro estava sendo escri to, estávamos constr uindo uma nova fi lia l para
o 1nercado de Ann Arbor que esperávamos inaugurar em maio de 2013. A Ta bela 6-5
resume as principais mét ricas do crescimento dos quatro últimos anos .
TABELA 6-5 Métricas do crescimento da DFCU Financial
2000 2008 2009 2010 2011 2012

Número de membros 170.812 167.910 201.329 218.374 213.869 214.454
Número de filiais 6 12 12 21 22 23
Número de funcionários 409 336 434 426 408 413
Ativos em bilhões US$1 ,2 US$1,9 US$2,4 US$2,7 US$3,0 US$3,2
TABELA 6-6 Métricas de sucesso financeiro da DFCU Financial
2000 2008 2009 2010 2011 2012

Principais métricas financeiras'
Retorno sobre ativos (ROA) 1,01% 1,69% 1,25% 1,23% 1,38% 1,55%
Retomo sobre capital próprio (ROE) 13,08% 12,06% 9,52"/o 9,53% 11,11% 12,36%
Índice de eficiência 77,50% 50,84% 52,90% 54,73% 57,56º/o 52,26%
Capital/Ativos 7,66% 14,00% 13,12% 12,94% 12,70% 12,49%
Dividendo de patrocínio especial
Pagamento total em milhões - $17,5 $19,3 $18,9 $21,1 $21 ,8
Satisfação dos membros
Member shops, escala O - 5 - 4,80 4,86 4,89 4,96 4 ,972
Satisfação dos funcionários
Melhores e mais promissoras - ,/ ,/ ,/ ,/ ,/
Detroit Metropolitana'
Melhores e mais promissoras -
Oeste de MI
Melhores e mais promissoras - ,/
Nacional
Em comparação às nossas 50 maiores concorrentes nacionais, a OFCU obteve 81il lugar em ROi, 15ª em ROE, sª em
1
eficiência e sª em C/A em 31/12/2012.

2
Versus uma concorrente com pontuação de 4 ,82 em 2012. Nota: Os Shops começaram em 2002 com uma linha base de 4 ,OS.
3
A DFCU recebeu o prêmio de 101 Melhores e Mais Promissoras Empresas para se Trabalhar - Detroit Metropolrtana por
8 anos consecutivos.
Exatamente como pretendíamos, de fato crescemos no negócio por meio de fusões

e projetos de novas fi lia is. Mas o crescimento não é a única medida de sucesso. Se mal
gerenciado, o crescimento pode ter um efeito deletério nas finanças, serviços e no 1no-
ral dos funcionários. Então, como foi que fizemos?
Du rante esse mesmo período, mantivemos uma forte posição financeira em com-
paração às nossas concorrentes. Nossa força financeira nos pennitiu continuar a paga r
um Dividendo de Patrocín io anua lmente aos nossos mem bros. Em janeiro de 2013,
pagamos nosso 7" dividendo, totalizando US$21,8 m ilhões, o que representava u1n
total acumu lado de US$133,4 milhões desde 2006. A satisfação dos membros nunca
fora mais alta segundo as 1nedidas de nosso progr ama de tnember shops e, e1n 2012,
estávamos nova1nente nos rankings 1nais a ltos nesse ele1nento ao fazermos o bench-
marking em relação às nossas concorrentes.
Igualmente importante foi o fato de termos continuado a receber prêm ios que re-
conheciam a DFCU Financial como excelente empregadora - prêmios que se baseia1n
somente no feedback de funcionários - como as 101 Mel hores e Mais Promissoras
E1npresas para se Trabalha r e os prêmios " Melhor local de traba lho" concedido pela
Detroit Free Press.
Estamos também vendo o reconhecimento de nosso crescimento e expansão geo-

gráfica ao longo dos últi1nos anos, sendo chamados de um "Ponto Positivo" econô-
mico em Michigan pela Corp! J\ifagazine. Esses sucessos são resumidos na Tabela 6-6.
A marca ainda é como a fazemos

Quando crescemos por 1neio da construção de novas fi liais, a 1narca DFCU Financial se
estende de modo bastante natural. En1 projetos de novas filiais, todos os ele1nentos da
1narca são ben1 controlados - desde o visua l e o cli1na das instalaçôes, ao treinamento e
contratação de novos funcionários ou n1esn10 à metodologia de projetos que usan1os. O
crescin1ento através de fusôes não é tão orgân ico. Garantir que a n1arca seja protegida
por meio desses projetos não é tarefa fáci l. Segundo o presidente e CEO Mark Shobe,
"Ao buscar possíveis parceiros de fusão, procura1nos organ izaçôes que não son1ente se
encaixe1n bem estrategica1nente, n1as tan1bén1 que comparti lhe1n ostensiva1nente nos-
sos valores centrais. No entanto, independente de quão adequada a outra organizaçôes
pareça ser, o n1aior desafio em qualquer projeto de fusão é a cultura."
Ação de marca - objetivos e clareza

A CapCon1 foi a primeira fusão da DFCU Financial concluída du rante esse período.
Ela nos propiciou acesso a dois novos mercados geográficos, n1as, o que é ma is im-
portante, nos deu a oportunidade de mudança de charter. Originalmente un1a coope-
rativa de crédito com cont role federal, a DFCU Financial hoje é un1a cooperativa de
crédito comun itária de contr ole estatal, que passou a ter acesso a todos os dist ritos
da península inferior de Mich igan. A mudança de charter exigiu uma votação pelos
membros. A votação do contr ole pelos n1embros foi u1na das tarefas mais importan-
tes do escopo do projeto de fusão con1 a CapCom. Segundo ao vice-presidente sênior
de marketing e operações estratégicas, Martha Peters, que fo i a gerente de projetos da
fusão com a CapCon1:
Para consegui rmos alcançar nossos objetivos com essa fusão, não somente precisávamos in-
tegrar sistemas e áreas funciona is com sucesso, mas também precisávamos ter um argumen-
to convincente para nossa base existente de membros m udarem nossa estrutura de negócios.
Ao fazer as duas coisas acontecerem, alavancamos nossa marca. Precisávamos assegurar
nossos membros existentes de que seríamos a mesma DFCU em que eles confiavam - só que
melho~ enquanto, ao mesmo tempo, precisávamos demonstrar aos nossos novos colegas da
CapCom como eles e o s membros q ue eles historicamente atend iam se beneficiariam com
a adoção da cultura da DFCU Financia l. Para facilitar nosso s ucesso nesse projeto, fomos
muito cuidadosos em relação a como estruturamos o projeto e comunicamos nossos objeti-
vos. Estabelecemos um comitê de direção, formado por executivos da DFCU e da CapCom,
q ue era res ponsável por tomar todas as principais decisões relativas ao projeto e aval iar
e comunicar o impacto sobre membros e funcionários de cada uma dessas decisões. Essa
estrutura nos ajudou a manter o (eedback de funcionários e membros sob controle e avaliar
o risco do projeto muito eficientemente.
Todos os principais objetivos desse projeto foram atendidos - a mudança de char-
ter, a integração funcional, a fusão legal e a integração dos sistemas - e, o mais impor-
tante, a marca da DFCU Financial se sa iu desse projeto como uma vencedora.
Ações de marca - respeito e responsabilidade; princípio orientador -

faci lite as coisas
Como a fusão con1 a CapCon1 estava sendo fina lizada co1n sucesso, fui designado
co1no gerente de projetos para a fusão con1 a MidWest Financial. Embora a n1udança
de charter ten ha figurado forte1nente na fusão con1 a CapCom, aquele també1n foi un1
projeto en1 que aprendemos n1uito sobre como realizar fusões. Co1no conduzin1os un1
exercício fonna l de lições aprendidas ao sair da fusão com a CapC01n, pude reutilizar
os elementos que funcionaran1 e me focal izar nas áreas que precisavam ser fortalecidas.
Por sermos uma empresa pequena, não possuímos recursos dedicados de gestão de
projetos. Espera-se que os gerentes da linha de frente e das un idades de negócios de re-
taguarda e suas equipes participem como membros de equipe de projeto, e geralmente
sirvam como gerentes de projetos. Em nossos projetos de fusão, todos os gerentes são
responsáveis por tadas as tarefas de integração que estão relacionadas à sua un idade
de negócios. Eles são essencialmente o gerente de projetos de sua área funcional. Os
gerentes cujas operações estão fortemente acopladas ao sistema computacional central
têm a inda 1naior responsabilidade de garantir que os dados do sistema que está sendo
abandonado seja convertido de forma segura e correta ao siste1na sobrevivente. É u1n
conjunto de responsabilidades hercúleo.
Uma das lições aprend idas com a fusão com a CapCom é que essas responsa-
bi lidades não estava1n claras para todos, então, tínhamos d iferentes graus de cum-
pri1nento da 1netodologia do projeto. Pelo mesmo motivo, todos aprendemos juntos
nessa primeira fusão quais eram as principa is peças daquele processo e como elas se
encaix ava1n umas às outras. Para desenvolver o que aprendemos com a CapCom, tra-
balhei com a equ ipe executiva para desenvolver um termo de abertura do projeto que
explicasse seu escopo, objetivos, estrutura e responsabilidades dos participantes e para
realizar uma revisão desse documento na reunião inaugural. Então, para tornar esse
projeto de grande escala ma is gerenciável para os gerentes das unidades de negócios,
reuni o pequeno conjunto de ferramentas que todos teriam de utilizar - nosso banco
de dados usual de projetos no Lotus Notes, um tetnplate com u1na lista de tarefas sim-
ples em Excel e um template co1n um relatório de status simples - e articu lei claramen-
te as regras de envolvimento: 1) as ferramentas deveriam ser usadas proativa1nente, 2)
as listas de tarefas e os relatórios de status precisavam ser postados por prazo fina l no
banco de dados e 3) o gerente de projetos de cada área tinha de revisar seu relatório
por escrito, postando-o em cada reunião de projeto com toda a equipe. Disponibil izei-
-me totahnente a qualquer pessoa que precisasse de ajuda com a utilização das ferra-
mentas e fiquei feliz em ver até que ponto aumentamos a competência de nossa gestão
de projetos por 1neio desse projeto.
Os requ isitos 1netodológicos e o conjunto de ferramentas que insistimos que os lí-
deres e os participantes do projeto usasse1n para o projeto da Mid\Vest valeram muito
a pena para nós, e não só para aquele projeto de fusão.
Ações de marca - empoderamento, responsabilidade e qualidade

Com duas fusões ocorrendo consecutivamente, e a primeira delas não mui to te1npo
depois de nossa grande conversão de sistema centr al em 2007, o atr aso acumu lado
do projeto estava crescendo diaria1nente. Houve um verdadeiro momento de côm-
puto em outubro de 201 O, quando a fusão com a Mid\Vest ainda estava e1n pleno
vapor. Um dos problemas que tinham surgido durante a fusão com a CapCom esta-
vam relacionados a caixas automáticos (CDMs, cash dispenser machines). Todas as
filia is originais da DFCU possuíam CDMs e1n cada caixa. As fi lia is da CapCom não
possuíam os mesmos ca ixas automáticos Em vez de adquirir CDMs para a CapC01n,
reescrevemos dezenas de procedimentos operacionais de ca ixa para acomodar filiais
com e sem CDMs. E1nbora isso solucionasse o problema imed iato, a gerência sênior
de filia is não gostou da complexidade que isso trazia às operações. Tendo tam bé1n
out ras preocupações mais técnicas co1n os CDMs, a equipe da gerência decidiu avaliar
a desimple1nentação dessas máquinas. Eles trabalharam em um piloto em uma de suas
fi lia is 1nais movimentadas. Gostaram do resultado e decidiram passa r imediatamente
à desimplementação em todo o sistema. Tínha1nos, no curto prazo, um out ro projeto
acontecendo quase que despercebido e1n meio a uma fusão. Estava na hora de pisar no
freio. Segundo Steven Schuhnan, vice-presidente sênior de desenvolvimento de fil iais,
"Lá estava eu, recé1n-promovido a VP sênior e min ha primeira grande ta refa era me
livrar de nossos CDMs. Nada demais, certo? De uma hora para out ra, vários outros
gerentes começam a me encher de perguntas - já pensou no impacto sobre os proce-
d imentos? As unidades estão tota lmente amortizadas? O departamento de instalações
irá reformar o gabinete dos caixas - eles têm orçamento para isso? Precisamos remo-
ver os CDMs do sistema? E assim por diante. Senti que estava fazendo a coisa certa,
mas ficou claro para mim que, para fazer aqui lo imed iatamente, eu precisava seguir
nossos protocolos normais de gestão de projetos. Lições aprendidas!".
O projeto de desi1nplementação dos CDM foi um divisor de águas para nós em
d iversos aspectos. Era absolutamente a coisa certa a se fazer e provavelmente não
era muito aconselhável ad iar por muito ma is te1npo. Ao 1nesmo tempo, todos nós,
gerentes de unidades de negócios tínhamos inúmeros projetos tanto de grande quanto
de pequena escala em nossas listas de afazeres e, alguns deles, exatamente como esse,
tinham realmente de prosseguir - apesar da fusão. Então, para o benefício de todas as
partes envolvidas, realmente precisávamos forçar nossa metodologia de projeto e nos-
so conjunto de ferra 1nentas a ser utilizado por um público muito 1na is amplo. Sendo
assim, demos ao Steven as ferramentas de que ele precisava para realizar esse projeto,
e então passamos 2011 não somente term inando a fusão da M id\Vest, mas também
implementando algumas melhorias no modo como gerenciamos projetos e nos comu-
nicamos a respeito deles. Embora ainda utilizássemos bancos de dados dedicados para
projetos de grande escala como fusões, d isponibilizamos o banco de dados de projetos
corporativos em Lotus Notes, que contém tetnplates de projetos e oferece u1n lugar
para postar documentos para todos os projetos ativos (ver Figura 6- 7). No final de
2011, também introduzimos u1n Processo de Mudanças Empresaria is formal criado
para garantir que evitássemos um out ro projeto surpresa como a desimplementação
dos CDMs. O processo é leve em termos burocráticos e exige que os gerentes das
un idades de negócios iniciem a conversa determinando como prioridade um banco
de dados de suporte que descreva o problema que precisam resolver ou o projeto que
acreditam que precise se envolver. Temos u1n pequeno comitê empresarial de mudan-
ças, formado por representantes de cada divisão, que revisa as prioridades toda sema-
na para melhor compreender o escopo de cada in iciativa e determinar que á reas preci-
sam ser envolvidas. Em alguns casos, as prioridades de mudança empresarial passam
à estatura de projeto corporativo, sujeitos aos nossos protocolos formais de gestão de
projetos. Na maioria dos casos, porém, as iniciativas empresa riais de mudanças pros-
segue1n como projetos de pequena esca la que são traba lhados à medida que o tempo
1iiil New TopidCõleoo,y ll'-:51 NewResoonse to Topic 1

Corporate Projects
C.tego,y
• AII Ptojects
> Currcnt Projoct3
• Poot Proiectt
> Sya1em Updatee
> ATMADA.Comphdl'ICC
Current Proj•cts > ATM SelYICC Conlntcb
Meeting Topies > ATM Temunal OriYing
Meetlng Oat•• > Cnrpcnter & ~ r d Broncti Con81r'uctK>n
Project Requests > CETO
PMO S•cure > ECM Arcttrv'8 Con"'8t8ion
Figura 6- 7 Banco de dados de projetos corporativos da DFCU Financial.

--
2013 Resource Planning
·-- Jr "ª"' J aso•oc:-~
• • - .i..1..1.
"'&t<offill png,r,t, ontk cvtnt of •no!,,.,...,.
Figura 6-8 Documento de planejamento de recursos da DFCU Financial.
permitir, ao cont rário dos projetos corporativos aprovados e dos projetos recorrentes
necessários como atua lizações do sistema cent ral e relatórios fiscais. Juntamente cotn
essa mudança nos processos, criamos uma nova lista de projetos que resume todos
os projetos em andamento em qualquer dado momento e perm itimos que a gerência
compreenda não somente as prioridades dos projetos, mas onde os recursos de toda
a etnpresa estão cotnprometidos atua lmente (ver Figura 6- 8). A lista é liberada men-
salmente a toda a gerência, que é encorajada a dedicar um tempo a revisar o que está
na lista e cotnpartilhar com suas equipes aquilo que acharem apropriado. A intenção
da nova lista de projetos é garantir t ransparência sobre como os recursos estão sendo
implantados nos projetos e conscientizar sobre iniciativas que acabarão afetando os
funcionários e/ou membros.
E a marca continua
Tivemos um sucesso financeiro significativo ao longo dos últimos anos, e a equipe
executiva está mu ito focalizada em sustentar esse sucesso no longo prazo. A mar-
ca DFCU Financial nos orienta no que precisamos fazer e, em muitos casos, como e
quando precisamos fazê-lo. Nossa 1narca tem mu ito a ver cotn moldar o modo como
abordamos projetos, pois reflete como pensamos a nosso próprio respeito e o que que-
remos alcançar. Continuaremos a progredir como pudermos com nossa estratégia de
crescimento gerenciado. Nosso recétn -concluído estudo sobre a expansão informará
nossas decisões quanto a construir novas filiais e, embora o ambiente esteja 1nudan-
do, continuaremos procurando oportunidades de fusões. Ao mesmo tetnpo estamos
procurando cuidadosamente maneiras de melhorar, de levar nossos produtos, serviços
e processos ao próximo nível. Então, quando começarmos em 2013, teremos vários
projetos e iniciativas em andamento que tiveram seu ponto de partida na marca.
Ação de marca - proteção

Assim co1no out ras organizações de serviços financeiros, a DFCU Financial tem en-
frentado uma dim inuição nas receitas líquidas de juros devido à reprecificação de
nossos portfólios de empréstimos e investimentos causada pelo ambiente prolongado
de baixas taxas e pela crescente pressão sobre a renda proven iente de encargos devido
ao que é descrito co1no "proteção ao consumidor". Isso significa uma perda de em
torno de US$6 m ilhões anuais para a DFCU ao longo dos últimos anos. O principal
executivo financeiro, Marv Elenbaas, tem mantido a equipe de gerência focada em al-
gumas métricas essenciais que são extremamente importantes de serem acompanhadas
durante épocas de forte compressão de margens: aumento das principa is receitas ope-
raciona is líquidas e aumento das principais despesas sem juros. Ele também de1nonstra
o impacto que o ambiente está tendo sobre nós incluindo nas finanças mensais o ren-
d imento médio dos ativos remunerados dos cinco últimos trimest res, que passaram de
3,34% no final do 4" trimestre de 2011 para 2,66% no final do 4" trimestre de 2012.
Ao promover a conscientização quanto ao impacto que o ambiente estava tendo sobre
nossas principais finanças, Marv conseguiu ser convincente e gan har apoio para um
p ro jeto para real izar uma revisão e uma aná lise minuciosa de nossas est ruturas de en-
cargos. Entretanto, cobrar encargos dos membros é um assunto sobre o qual diferentes
áreas da cooperativa de crédito têtn opiniões fervorosas e, muitas vezes, dia1net ralmen-
te opostas. E essas opiniões são solidamente racionalizadas em relação à nossa 1narca.
Pa ra garantir uma análise e um processo de tomada de decisões produtivos e colabo-
rativos, Marv procurou u1n terceiro que tivesse uma perspectiva neutra para facil itar
a revisão. O principa l deliverable do projeto era u1n conjunto de reco1nendações para
mudanças. Segundo Marv, "as 1nudanças nos encargos acordadas por 1neio desse pro-
jeto são apoiadas e bem compreendidas por todas as partes e, o que é mais importante,
refletem um equ ilíbrio dos princípios de nossa 1narca. O plano aborda a necessidade
crucial de aumentar nosso fluxo de receitas ao longo dos próximos anos. Ao mesmo
tempo, garante que a DFCU continuará oferecendo uma sól ida proposição de valores
aos seus membros. Não somente eles se beneficiara1n co1n a reprecificação para ba i-
xo das taxas de emprésti1nos, mas também continuamos posicionados como menos
agressivos em termos de encargos em relação às nossas concorrentes, permitindo-nos
manter no mercado nosso princípio de " faça-os ganhar o dia". Não é setnpre que as
partes interessadas dos departa1nentos de finanças, atendimento ao cl iente e marketing
concordam em um assunto como encargos, 1nas chega1nos bem perto disso".
Princípios orientadores - "faça-os ganhar o dia" e simplifique as coisas

Um dos n1aiores projetos de infraestrutura que foram iniciados quando estávamos fi-
nal izando as fusões recentes foi a implementação de un1 novo e robusto sisten1a de ge-
rencia1nento de conteúdo empresarial. Ainda que as primeiras fases dessa iniciativa de
vários anos de duração não chan1en1 n1uita atenção, apesar de fundan1entais - substi-
tu ir o arquivo de docun1entos existente e converter o conteúdo - espera-se que as fases
posteriores agraden1 os funcionários e n1embros captando assinaturas elet ronica1nente
na documentação da conta, el iminando, assim, o n1anuseio e a n1ovimentação de papéis
físicos, e fornecendo maior acesso de autosserviço a docu1nentos eletrônicos (eDocu-
ments) a n1en1bros e passando de comprovantes e recibos impressos no caixa a recibos
eletrônicos (eReceipts) - coisas que nossos funcionários e n1en1bros vên1 solicitando já
há algun1 tetnpo, à medida que mais e 1na is empresas adere1n a práticas mais "verdes".
Ação de marca - voz

Para garantir que sustentemos nossa posição como e1npregadora favorita e fortalecer
nossa retenção de funcionários, o que certamente será um desafio até que a economia
de Michigan melhore, os recursos humanos lançaram u1n novo e aprimorado processo

em nossa reunião de funcionários anual e1n janeiro de 2013. Esse sólido compromisso
de escutar o feedback de funcionários sem dúvida será o ponto de partida para pro-
jetos e iniciativas criados para atrair e reter o talento de que a DFCU precisará para
levar nosso negócio a um pata1nar superior.
Ação de marca - promessa

2013 também é un1 ano em que nos foca lizaremos em avalia r e aperfeiçoar nossos
serviços de atendimento ao cliente. Segundo Keri Boyd, vice-presidente executivo de
desenvolvimento corporativo, "Nosso pessoal de linha de frente que presta serviços
di retos aos membros participam dos shops há anos - e suas ponn1ações são impres-
sionantes. Ainda assim, temos nos perguntado: podemos ser ainda n1elhores? Esse
questionamento nos levou a analisar o processo de prestação de serviços de maneira
n1ais an1pla . Quando os n1en1bros da equipe da linha de frente p recisam de ajuda,
eles procuram nossas áreas de retaguarda - sejan1 elas T I, operações, subscrições,
cobrança. Queremos garantir que essas interações ofereçam o máxin10 de apoio e
sejam o mais positivas e eficientes possível. Somos todos parte da cadeia de valor
de serviços. Analisando os seviços internos de perto, seren1os capazes de identificar
áreas para n1elhorias".
Princípio orientador - seja um especialista

Um componente crítico de serviços superiores é a competência, logo, o apelo para ser
"u1n especialista". Quando estávamos passando pela conversão de nosso sistema cen-
tral, tudo era novo para todas as áreas, então, docu1nentar procedimentos deta lhados
foi u1n componente i1nperativo desse projeto. Políticas e procedimentos era1n uma
grande preocupação também nos projetos de fusão, já que precisávamos garantir que
novos membros das equipes compreendessem claramente os 1nodos de agir da DFCU.
Segundo o supervisor de suporte ao canal de ent rega, Kelly Kid,vell, "Agora temos
uma equipe muito experiente e, a inda assim, estamos encont rando algumas evidências
de u1na dependência literal em nossa base de conhecimento por escri to, que às vezes
atrapalha a solução eficiente de problemas e a tomada de decisões ao prestarmos servi-
ços aos nossos membros. Essa é u1na grande preocupação para mim, já que m inha área
escreve e mantém todas as políticas e procedimentos operacionais e oferece suporte
via telefone a membros da equipe de linha de frente em questões operacionais". Para
começar a abordar essa tendência, Kelly iniciou uma campanha chamada "solucione o
problema certo" com sua equipe e os está orientando a 1nelhorar suas habi lidades de
faci litação e de ouvir com atenção ao oferecer suporte à linha de frente, e encorajando
discussões internas sobre o que está dando certo e o que não está. Essa iniciativa já
ajudou a identificar a necessidade de reformulação de nossos processos de prestação
de serviços para contas de pessoas fa lecidas e contas fiduciárias, um projeto que entra-
rá em andamento em 1neados de 2013.
Princípio orientador - facilite as coisas

Apesa r de estarmos focalizados na conversão de sistema e nas fusões, não tín hamos
a capacidade para tratar de nossos cana is de entrega. Como observou Marcha Peters,
vice-presidente sênior de marketing estratégico e operações, "Precisávamos manter al-
gumas coisas ina lteradas. Fusões e conversões, por si só, já apresentam enormes mu-
danças. Não podíamos arriscar também fazer mudanças de cana is, algo que é se1npre
disruptivo para nossos 1nembros. Então, nem preciso dizer que os últimos anos fora 1n
dedicados, acima de tudo, aos canais. E1n 2012, liderei projetos para desl igar nossa
plataforma de controle de terminais de ca ixas eletrônicos, substituir nosso sistema de
resposta de voz interativa (IVR) e lançar o apl icativo de transações bancárias móveis.
Atualmente, estamos passando pelo processo de solicitação de propostas para substi-
tuir nosso canal de tr ansações bancárias via internet. Nosso alvo é que essas mudanças
sejam realizadas em 2014. Um requisito estratégico importante para todas essas ini-
ciativas é simplificar nossas soluções e facil itar nossas mudanças e melhorias. Para tal,
precisamos passar de nossas p lataformas, que hoje são extremamente personalizadas,
a soluções que nos permitam que nos adapte1nos ma is rapidamente a mudanças tecno-
lógicas e mercadológicas".
À medida que a DFCU Financial embarca no próximo trecho dessa jornada, o
mapa de orientação serve mais para polir nossa experiência, mel horando a qualidade
da prestação de serviços e sendo bem-sucedido e1n u1n mundo ági l e cada vez mais co-
nectado. E, como sempre, o "como" de nossa jornada será guiado por nosso interesse
e1n sustentar e ampliar nosso sucesso e em incentivar nossa 1narca a fazê-lo.
6.8 ILLUMINAT (Trinidad & Tobago) Ltd.

No papel, a fusão de duas ou n1ais en1presas pode parecer fáci l. No entanto, se as en1-
presas têm diferentes culturas, e cada cultura possui uma diferente visão dos benefícios
da gestão de projetos, a fusão propria1nente dita pode não produzir os benefícios es~e-
rados. O restante desta seção foi fornecido por Cynt hia Jan1es-Cra1ner, EMBA, PMP , e
consultora de serviços de gestão de projetos da ILLUMINAT (Trinidad & Tobago) Ltd.
Gerenciando a cultura de gestão de projetos em uma fusão

Uma fusão de empresas sempre traz desafios inerentes para a organização recém -for-
mada. Os métodos empregados para enfrentar esses desafios determina não somente
o sucesso da fusão, mas també1n com que rapidez as operações podem alcançar um
nível eficiente.
Quando três entidades do grupo ITC (lnformation Technology & Com1nun ica-
tions) da empresa Neal & Massy Holdings se fundiram no d ia 11 de setembro de
2001, o então CEO da ILLUMINAT,o sr. Keith Thomas, tomou i1npulso para int rodu-
zir a organização a uma Metodologia de Serviços Profissiona is (Profserv) na qua l ha-
via uma metodologia de gestão de projetos embutida juntamente co1n a aprendizagem
organizaciona l e a adoção organizaciona l.
Das t rês entidades, apenas uma empresa tinha anterionnente uma cu ltura que
apoiava a gestão de projetos devido ao seu foco em TI e tinha int roduzido o conceito
de um escritório de projetos logo antes da fusão. A tarefa do CEO agora era não so-
mente implementar a metodologia Profserv, mas também institucionalizar uma cultura
de gestão de projetos. Isso foi essencial, já que a missão da nova empresa agora focali-
zava -se em fornecer soluções que abrangessem as ofertas de todas as três entidades de
maneira distinta de seus empreendi1nentos anteriores em termos de oferta de produtos
.
e serviços.
A ordem
O CEO emitiu uma ordem para que a metodologia Profserv fosse adotada por todos
os funcionários, inclusive a gerência sênior, que foi responsabilizada pelo sucesso de
sua execução. Emitiu-se u1na ordem similar para a adoção, e1n toda a empresa, de uma
abordagem-padrão para a gestão de projetos.
A abordagem
Primeiramente, todos os gerentes, líderes de equipe e principais recursos de departa-
n1entos foran1 sensibilizados em relação a uma cu ltu ra de gestão de projetos e tan1-
bém foran1 instruídos quanto a que consequências podem su rgir quando tal cu ltura
não existe. As evidências se tornaram aparentes em un1a pesquisa feita com un1a
amostra de projetos importantes que foram executados sen1 uma metodologia de
gestão de projetos que demonstrasse claran1ente onde as coisas deran1 errado e o
impacto sobre o sucesso desses projetos. A resposta e o feedback dos funcionários
foran1 enormes, o que resu ltou em alguns funcionários ficaren1 ansiosos para che-
garem logo ao treinamento que estava por vir. A organ ização propriamente dita foi
reestruturada, adotando un1a abordagem baseada en1 equipes para a prestação de
serviços e, quando relevante, os papéis de supervisor e gerente foran1 renomeados
para " líder de equ ipe".
O escritório de projetos agora tinha redirecionado seu foco para um escritório de
gestão de projetos (PMO ) com a ordem de estabelecer e disponibilizar uma metodo-
logia e servir de repositório para disseminar informações sobre a gestão de projetos,
além de para amadurecer a cultura no curto e no longo prazo. A liderança da organi-
zação mostrou seu compro1neti1nento investindo no t reinamento da equipe e comple-
mentando a equ ipe existente cotn o recrutamento de gerentes de projetos experientes.
O sucesso
Os desafios da fusão de culturas mistas, departamentos fundidos, funções fund idas e
níveis variados de maturidade em gestão de projetos, ou a ausência de.sra agora tinha tn
sido a barcados em um único teste. O sucesso emergente foi recompensador quando
a abordagem baseada em equ ipes começou a ser colocada em prática. Hoje há u1na
abordagem padronizada para todo o ciclo de prestação de serviços desde o 1nomento
em que a empresa consegue a oportunidade até o momento em que implementa a so-
lução. Houve também evidência de um aumento dos negócios de repetição de clientes
existentes e a oportunidade de licitações com apenas um participante.
Recentemente, foi real izada u1na outra pesquisa com uma amost ra de projetos
similar à da primeira pesquisa, desta vez executando os projetos utilizando uma meto-
dologia de gestão de projetos. Os resultados fa laram por si só, cotnprovando o maior
sucesso dos projetos.
Sustentando a cultura da gestão de projetos

A a lta gerência está continuando seu investimento na cu ltura de gestão de projetos ao
sustentar o desenvolvimento contínuo da equipe do PMO e seus esforços. O PMO, ao
manter sua visi bilidade na organização, lançou o programa de um prêtnio anual de
reconhecimento e iniciou um boletim informativo de publicação trimestral, que circu la
por toda a organização. O boletim relata o inventário e os sucessos de projetos e dicas
de gestão de projetos. Juntamente cotn esses esforços, os funcionários com um inte-
resse específico na disciplina são encorajados a tentar obter a certificação básica etn
gestão de projetos, co1no alguns já fizeram, e out ros a inda estão fazendo. Além disso,
novos funcionários são apresentados ao PMO por meio do programa de orientação
a novos funcionários. Há mais um impulso de treinamentos internos p lanejado para
todo o pessoal mais importante de entrega de projetos, para reforçar a metodologia de
Conclusão
Adotar uma cu ltura de gestão de projetos e1n uma fusão pode parecer uma barreira
quase que intrasponível no início, mas ao segu ir mel hores práticas de adesão, envolvi-
mento e apoio da alta gerência, metade do trabalho já está feito. O resto se resume ao
PMO se manter visível por meio de mentoria, ensino e acesso às informações necessá-
rios e ao apoio a todas as sub-ramificações da organ ização até que a transferência da
cu ltura tenha sido embutida.
Nas palavras do então CEO:
Começando! A abordagem da adoção talvez seja o aspecto mais crítico de qualquer proces-
so de mudança. Discutivelmente mais crucial do que a mudança propriamente dita, a abor-
dagem deve ser pensada e implementada cuidadosamente. O que vem a seguir é o resultado
da devida deliberação por parte da gerência e do (eedback dos grupos de foco formados por
funcionários.
Alguns acreditam q ue adultos aceitem melhor novas abordagens quando eles compreen-
der o porquê delas. Portanto, começaríamos com sessões abrangendo toda a organização
sobre POR QUE.
Depois, prosseguiríamos com o CO!v!O.
6.9 DTE Energy

T im Menke, PMP®, especialista sênior em melhorias contínuas no gerenciamento de
desempenho de operações de distribuição da DTE Energy, descreve a cultura nessa
etnpresa:
Embora o nível de apoio à gestão de projetos varie entre os d iferentes departamentos, de
modo geral, ele está aumentando em toda parte. Há vários anos, era comum encontrar
praticantes experientes gerenciando projetos de grande porte e alta visibilidade usando me-
todologias tanto internas quanto externas. Hoje, pode-se encontrar praticantes em toda a
empresa aplicando as ferramentas e técn icas a d iversos projetos. Em alguns casos, isso é o
res ultado das expectativas das partes interessadas. Em outros, é impulsionado pela pessoa
que está gerenciando o projeto. A metodologia de melhorias contínuas na gestão de projetos
é usada por todos os candidatos a Faixa Preta em Seis Sigma Enxuto na DTE Energy, uma
vez que isso é exigido de todos os projetos apresentados como uma forma de estimular a
certificação.
Usam-se abordagens de gestão de projetos tanto formais quanto informais. Os projetos
q ue informam o progresso a com itês de govemança ou de partes interessadas tendem a ser
gerenciados mais formalmente. A maioria dos departamentos implementou templates de re-
latório de progresso para garantir a consistência. Os projetos gerenciados sob a organização
de um diretor o u abaixo tendem a ser gerenciados menos formalmente. Reconhecer todos
os projetos não exige o mesmo nível de rigor de gestão de projetos, nossa metodologia de
melhorias contínuas na gestão de projetos foi revisada para se "adaptar" às necessidades do
projeto específico e de suas partes interessadas.
Os desafios à implementação da gestão de projetos e programas pela qual passamos
incluem:
• As partes interessadas, gerando aumentos graduais no escopo
• Gerentes de projetos com níveis de experiência variados
• Membros de equipe lutando para eq uilibrar as necessidades operacionais e de projetos
Maneiras de superarmos essas barreiras incluem:
• Mentoria um-a-um liderada por praticantes experientes
• Atividades de plano de desenvolvimento de funcionários para melhorar a proficiência
• Maior foco sobre o gerenciamento de relatórios de relações matriciais
Doug Bolzman, consultor em arquitetura, profissiona l de gestão de projetos (PMP®),
especial ista e1n !TIL® na HP, acredita que:
Em muitos casos, institu ir a gestão de projetos é uma pa rte capacitadora da mu-
dança cultural exigida por uma organização. Quando são necessárias grandes melho-
rias, a cu ltura é apritnorada por 1neio da instituição da ge.stão de projetos, e e.sra não
pode depender de haver uma cu ltura e1n vigor. Implementar liberações/projetos que
abarquem roda a empresa exige que a cu ltura leve a organização de um gerencia1nento
funcional a um gerenciamento 1natricial, faça a entrega deixar de ser centrada no pro-
jeto, passando a ser centrada em componentes e passe o planejamento do nível tático
(emocional) para o nível estratégico (analítico). Esse nível de mudança cu ltural precisa
ser identificado, projetado e imple1nentado.
Recentemente, t raba lhamos com o PMO de uma organização que estava primor-
dialmente gerenciando projetos ind ividuais, tin ha o dashboard típico em vigor para
comunicar o status, e representava basicamente u1na função admin istr ativa para a
organização. Oferecemo-lhe a oportunidade de ser um "PMO de primei ra classe", e
poderíamos ajudá-lo a implementar diversas 1nelhores práticas para permitir:
1. Direcionar o Mapa de Serviços de TI em termos de liberações para o cliente
a. Em relação ao cronograma das necessidades empresariais
b. Em relação à compatibilidade/ integração dos serviços/arquiteturas
2. Gerenciar/Integrar liberações de serviços de TI
a. Para cada equipe de Serviços/Entrega
b. Utilizando o ciclo de vida de gerenciamento de serviços
c. Gerenciar a integração e as dependências de cada liberação
3. Responsabilizar-se pelo Design e Implementação de solicitações de serviços
que fujam ao padrão
a. Projetos, entrada de membros, requisições, t ransferências de funcionários
b. Estabelecer uma previsão t ri1nestra l e abrir os Pedidos de Compra para
faturar as solicitações
4. Comunicar o status do serviço ao encarregado pelo serviço de TI e/ou ao
cliente
5. Estabelecer e medir ciclos de vida / políticas de serviços de TI
a. Estabelecer o ciclo de vida geral de gerenciamento de serviços e aprimorá-
-lo continuamente
b. Instituir consistência e1n co1no os serviços são prestados (i.e. Política de
Mudanças)
c. Trazer para o projeto provedores de serviços superiores pa ra garantir os
padrões apropriados para o cliente e padrões farmacêuticos
Con10 o PMO não "reconheceu" forn1a ln1ente o !TIL®, con10 uma melhor prá-
tica, eles negaram a oportunidade de avança r ou amadurecer seus serviços de gestão
de projetos e continuaram com suas próprias práticas administrativas. Eles tiveram a
oportun idade de ser uma força n1otriz significativa para sua empresa e p rover valor
no gerencian1ento de di reções gerais de TI, mas não queriam mudar, desejavam o
status quo.
O cl iente seguinte com que trabalhamos tinha um PMO estabelecido cotn os mes-
mos parâ tnetros básicos de oferecer apoio aos projetos. Quando lhes apresentamos
essa oportunidade, eles pularam de a legria com o fato de que a lguétn estava disposto
a ajudá-los a serem 1na is va liosos para o negócio e sa ir do "modo administ rativo". En-
tão, a moral da história é a seguinte: as oportunidades estão d isponíveis (por meio da
promoção de mel hores práticas), e as pessoas que tiram proveito das mel hores práticas
são aquelas que desejam promover a excelência nos serviços.
6.11 Barreiras à implementação da gestão

de projetos em mercados emergentes
O crescin1ento da tecnologia computacional e das equipes virtua is tornou o mun-
do n1enor. As nações do primeiro n1undo estão se juntando a nações de n1ercados
en1ergentes para obter acesso à abundância de e.apitai humano altamente qualifi-
cado e relativamente ba rato e que quer participar de equipes virtuais de gestão de
proietos.
No entanto, trabalhar nessas equ ipes virtuais pode gerar enormes dores de cabe-
ça. En1bora apareça uma aceitação relativa da gestão de projetos nos níveis profis-
sionais em que os membros da equ ipe operam, n1ais acima na hierarquia pode haver
resistência à sua in1plen1entação e à sua aceitação. Devido ao crescimento da gestão
de pro jetos em todo o n1undo, muitos executivos ainda a aceitan1 só da boca para
fora quando, por trás dos bastidores, erigen1 barreiras sign ificativas para evitar que
ela funcione adequadamente. Isso cria verdadeiras dificuldades para as partes das
equipes virtuais que se encontr an1 em países de p rimeiro mundo e têm de depender
do apoio de outros n1en1bros de equipe. O resultado fina l pode incluir frustrações
decorrentes do n1au fluxo de informações, processos de tomada de decisões extrema-
mente longos, mau controle de custos e abundância de dependências externas que
estenden1 os cronogramas a lém das datas contratuais estabelecidas pelo comprador.
Dito de forma simples, há fo rtes questões culturais que p recisam ser consideradas.
Nesta seção, tipicamente usaren1os os Estados Un idos como un1 exemplo das nações
do primeiro mundo.
Existem barreiras à implementação de uma gestão de projetos eficiente etn todo o
mundo, não sotnente nas nações de países emergentes. Porém, nesses países, as barrei-
ras são mais aparentes. Por motivos de simplificação, as barreiras podem ser classifi-
cadas etn quat ro categorias:
• culturais
• políticas e relacionadas a status
• relativas à gestão de projetos
• outras
Cultura
Uma cultura é um conjunto de crenças que as pessoas seguem. Cada empresa pode
ter sua própria cultura. Algumas empresas podem até mesmo ter 1núltiplas cu lturas.
Algumas culturas são fortes, enquanto outras são fracas. Em algumas nações dos mer-
cados etnergentes, há culturas naciona is que podem ser tão fortes que prescrevem as
culturas corporativas. Há inúmeros fatores que podem influenciar a cu ltura de uma
organização. Apenas os fatores que podem ter um impacto sobre a implementação e a
aceitaç.ã o da gestão de projetos serão discutidas aqu i. Entre eles, estão:
• Cent ralização burocrática da autoridade nas mãos de alguns poucos

• Ausência de um verdadeiro e significativo patrocín io por pa rte dos executivos
• !tnportância da hierarquia organizacional
• Leis juridica1nente i1npróprias
• O potencial de corrupção
Centralização da autoridade: Muitos países mantêm uma cultura em que poucos
têm a autoridade para tomar decisões. A tomada de decisões repousa nas mãos de
alguns e serve como uma fonte de amplo poder. Esse fator existe tanto em e1npresas de
capital privado quanto em organizações governamentais. A gestão de projetos defende
a descentra lização da autoridade da tomada de decisões. E1n mu itos países, o nível
mais sênior de gerenciamento nunca irá abrir 1não de sua autoridade, poder, ou direito
de tomar decisões e ent regá-la aos gerentes de projetos. Nesses países, ser nomeado
para cargos de nível sênior da gerência não é necessariamente a lgo que se consegue
pelo mérito de seu desempenho. E1n vez disso, depende da idade, de pertencer ao parti-
do político correto e de contatos pessoais com pessoas que detenham ca rgos governa-
mentais. O resultado pode ser executivos com pouco conhecimento sobre seu próprio
negócio ou sem capacidade de liderança.
Patrocínio executivo: O pat rocínio do projeto pode existir em algum luga r da
empresa, mas quase co1n certeza não nos níveis executivos. Há dois motivos para ta l.
Primeiro, os gerentes sênior conhecem suas lim itações e podem não ter conhecitnento
algum sobre o projeto. Portanto, eles podem estar incl inados a cometer sérias gafes
que podem se tornar visíveis para as pessoas que os colocaram nessas posições de
poder. Segundo, e possivehnente 1na is importante, agir como u1n patrocinador execu-
tivo em um projeto que poderia falhar poderia sinalizar o fim da carreira política do
executivo. Portanto, o patrocínio, se é que ele existe, pode se encontra r em um ba ixo
nível da hierarquia organizaciona l, e e1n um nível onde as pessoas são dispensáveis se
o projeto fa lhar. O resultado é que os gerentes de projetos acaba tn com pat rocinadores
que ou não conseguem ou não querem ajudá-los em momentos complicados.
Hierarquia organizacional: Nos Estados Unidos, os gerentes de projetos geralmen-
te têm o direito de fa lar co1n qualquer pessoa da empresa para obter informações rela-
tivas ao projeto. A intenção é fazer o t raba lho fluir horizontal além de verticahnente.
E1n alguns países de mercados emergentes, o gerente de projetos precisa seguir a cadeia
de comando. A hierarquia organizaciona l é sagrada. Seguir a cadeia de comando certa-
mente alonga o processo de tomada de decisões ao ponto de o gerente de projetos não
ter nenhuma ideia de quanto tetnpo levará para obter acesso às informações necessá-
rias ou para u1na decisão ser tomada, ainda que exista u1n patrocinador. Não existe
nenhuma infraestrutura madura em vigor que apoie a gestão de projetos. A infraestru-
tura existe para fi ltrar más notícias dos níveis executivos e para justificar a existência
de cada gerente funcional.
Nos Estados Unidos, não se "passa o bastão" alé1n do patrocinador. Os pat roci-
nadores têtn a autoridade máxima de tomada de decisões, e espera-se que eles auxi-
liem os gerentes de projetos durante uma crise. O papel do patrocinador é claramente
definido e pode ser descrito detalhadamente na metodologia empresarial de gestão de
projetos. No entanto, em a lguns países de mercados emergentes, mesmo o patrocina-
dor pode não ser autorizado a tomar uma decisão. Algu1nas decisões precisam chegar
a té u1n m inistro do governo. Dito de forma simples, não se sabe onde e quando a de-
cisão precisa ser tomada e onde ela será tomada. Além disso, nos Estados Unidos, dar
notícias ruins acaba ficando nas mãos do patrocinador de projetos. Em alguns países,
as notícias podem chegar até os minist ros. Ou seja, não se pode ter certeza de onde as
informações sobre o projeto acabarão.
Leis juridicamente impróprias: Nem todas as leis das nações de mercados e1nergen-
tes são vistas por outras nações como juridica1nente aceitáveis. Contudo, os gerentes
de projetos norte-a 1nericanos que esteja trabalhando e1n parceria con1 essas nações
precisan1 cumpri-las. Con10 exen1plo, contratos de aquisição podem ser adjudicados
não para o fornecedor ma is qualificado ou para aquele com oferta de n1enor custo, mas
para qualquer licitante que resida em uma cidade que apresente alto nível de desem-
prego. Como outro exe1nplo, algumas nações possuen1 leis que implican1 que subornos
sejan1 u1na prática aceitável ao adjudicar contratos. Alguns contratos ta1nbén1 poden1
ser adjudicados a parentes ou an1igos en1 vez de ao fornecedor mais qualificado.
Potencial de corrupçã.o: A corrupção pode existir e existe en1 alguns países e ten1
efeitos devastadores sobre os gerentes de projetos que se focalizam na tripla rest r i-
ção. Os gerentes de projetos tradicionalmente desenvolven1 un1 plano para cun1prir
os objetivos e a tr ipla restr ição. Eles também supõen1 que tudo será feito sistematica-
mente de n1aneira ordenada, o que pressupõe a ausência de corrupção. Em algumas
nações, no entanto, há indivíduos ou organ izações potencialmente corruptos que
fa rão todo o possível pa ra suspender o projeto ou desacelerá-lo, até que possan1
obter benefícios pessoais.
Status e politicagem
Status e pol iticagem prevalecen1 em todos os lugares e pode1n ter un1 impacto negativo
sobre a gestão de projetos. Em algumas nações dos n1ercados emergentes, status e políti-
ca chegan1 n1esn10 a sa botar a gestão de projetos e impedir seu perfeito funcionamento.
Fatores que podem afetar a gestão de projetos incluen1:
• Formalidades jurídicas e restrições governamentais
• Insegurança nos níveis executivos
• Consciência em relação a questões de status
• Obrigação socia l
• Política interna
• Dese1nprego e pobreza
• Atitude em relação aos trabal hadores
• Ineficiências
• Falta de dedicação em todos os níveis
• Falta de honestidade
Fonnalidades jurídicas e restrições governatnentais: Aqui nos Estados Unidos,
acreditamos que os funcionários com mau desempenho pode1n ser afastados do proje-
to ou até mesmo dem itidos. No entanto, em a lgu1nas nações de mercados emergentes,
os funcionários têm o direito de reter um emprego mes1no se seu desempenho for
aba ixo do padrão esperado. Ter um e1nprego e um pagamento periódico fixo é um
luxo. Há leis que determ inam clara1nente sob que condições um trabalhador pode ser
demitido, se u1na demissão for possível, em primeiro lugar.
Há leis ta1nbém que regulam o uso de horas ext ras. O uso de horas extras pode
não ser perm itido porque pagar a lguém pa ra t rabalha r fo ra de seu horário nonnal
pode acabar criando uma nova classe social. Portanto, as horas extras talvez não pos-
sam ser usadas como um meio de 1nanter ou acelerar um cronogra1na que esteja en-
frentando proble1nas.
Insegurança: Os executivos gerahnente sente1n mais insegurança do que os geren-
tes aba ixo deles, pois seus cargos podem ser o resultado de nomeações políticas. Dessa
forma, os gerentes de projetos podem ser vistos como as est relas do futuro e uma
ameaça aos executivos.
Perm itir que gerentes de projetos que estão t rabalhando em projetos extremamen-
te be1n -sucedidos façam apresentações aos níveis 1nais a ltos de gerência no governo
pode ser um campo 1ninado. Se o projeto estiver enfrentando problemas, o gerente de
projetos pode ser forçado a fazer a apresentação. Os executivos têm 1nedo de gerentes
de projetos.
Consciência e,n relação a questões de status: Os executivos corporativos nas na-
ções de 1nercados emergentes são extrema1nente conscientes em relação a questões de
status. Eles têm um medo real de que a i1nplementação da gestão de projetos possa
forçá-los a perder seu status, contudo, se recusa1n a funcionar como pat rocinadores
ativos de projetos. O status geralmente é aco1npanhado por benefícios ext ras como
automóvel da empresa e outros privi légios especiais.
Obrigações sociais: Nas nações de mercados e1nergentes, as obrigações sociais
devido a crenças rel igiosas (e, possivehnente, crenças supersticiosas) e pol iticage1n
podem ser 1nais i1nportantes do que nas nações do primeiro mundo. As obrigações
sociais são maneiras de 1nanter a lianças co1n aquelas pessoas que colocaram um exe-
cutivo ou gerente de projetos no poder. Assim sendo, os gerentes de projetos podem
não ter permissão para interagir socilamente com certos grupos. Isso poderia ser visto
como uma ameaça à implementação da gestão de projetos.
Política interna: A política interna existe em todas as empresas do mundo. Antes
de os executivos considerare1n oferecer seu suporte a uma nova abordagem co1no a
gestão de projetos, eles se preocupam com se eles se tornarão mais fortes ou mais fra-
cos, se terão 1nais autoridade ou menos e se terão maiores ou menores chances de pro-
gresso na carreira. Esse é um dos 1notivos pelos quais apenas um pequeno percentual
de empresas em mercados emergentes possui PMOs. Qualquer executivo que consiga
o cont role do PMO poderia se tornar mais poderoso do que outros executivos. Nos
Estados Unidos, solucionamos esse problema pennitindo que vários executivos te-
nha1n seu próprio PMO, mas nos mercados emergentes, isso é visto como um excesso.
Desemprego e restrições governamentais: Praticamente todos os executivos com-
preende1n a gestão de projetos e os benefícios que a acompanham, contudo, permane-
cem em silêncio em vez de most rar seu apoio visivelmente. Um dos seus benefícios é
que ele pode tornar as organizações ma is eficientes ao ponto em que menos recursos
são necessários para realizar o t rabalho em questão. Isso pode ser u1na a 1neaça para
um executivo, pois, a 1nenos que se consigam mais t raba lhos, a eficiência pode resultar
em cortes de pessoal, na redução do poder e autoridade do executivo, no aumento
do nível de desemprego e, possivelmente, no aumento da pobreza na comunidade.
Portanto, o aumento da eficiência da gestão de projetos pode ser visto como algo
desfavorável.
Atitude em relação aos f1111cio11ários: Em algu1nas nações, os funcionários pode1n
ser vistos como pedras fundamenta is para a "construção de impérios". Contratar três
traba lhadores aba ixo da méd ia para fazer o mesmo traba lho de dois trabalhadores
médios é 1nelhor para essa fina lidade, porém, possivelmente à custa do orçamento
e cronograma do projeto. É verdade, no entanto, que encontrar recursos humanos
adequados pode ser difíci l, mas às vezes as empresas simplesmente não se esforçam o
suficiente e1n sua busca. Amigos e membros da fa 1nília pode1n ser contratados priori-
tariamente, independente de suas qua lificações. O problema se complica a inda mais
quando é preciso encontrar pessoas com experiência em gestão de projetos.
Ineficiências: Anteriormente, afirmamos que as empresas podem achar difíci l con-
tratar pessoas extremamente eficientes e1n gestão de projetos. Nem todas as pessoas
são eficientes. Algumas pessoas simplesmente não assumem u1n compro1n isso co1n seu
trabalho embora compreendam a gestão de projetos. Out ras podem se sentir frustra-
das quando percebe1n que não têm o 1nesmo poder, autoridade ou responsabil idade do
que seus colegas em países do primeiro mundo. Às vezes, pessoas recém -cont ratadas
que querem ser eficientes são pressionadas por uma cultura a permanecerem ineficien-
tes, caso contrário, os colegas do indivíduo serão identificados como traba lhadores
ruins. A pressão de colegas existe e pode impedir que as pessoas demonstrem seu
verdadeiro potencial.
Falta de dedicação: É difícil 1notivar as pessoas quando elas acreditam que não
podem perder seu emprego. As pessoas simplesmente não se dedicam à tr ipla restrição.
Algumas preferem ver o cronograma se at rasar pelo fato de isso lhes dar a lgum grau
de segurança por u1n período de tempo 1naior. Há também uma falta de dedicação ao
encerramento do projeto. Quando um projeto começa a chegar em suas etapas finais,
os funcionários começam a procurar espaço em algum out ro projeto. Eles podem até
mesmo deixa r seu projeto atual prematuramente, antes de o tra balho ser concluído,
pa ra garantir emprego em a lgum out ro lugar.
Honestidade: As pessoas que traba lham em países de 1nercados e1nergentes têm
u1na tendência a esconder coisas de seus colegas de trabalho e gerentes de projetos,
especialmente más notícias, seja para manter seu prestígio, ou para reter seu poder e
auto ridade. Isso cria uma enorme barreira para os gerentes de projetos, que dependem
de informações na hora certa, sejam elas boas ou ruins, a fim de gerenciar o projeto
com sucesso. At rasos em relatórios podetn gerar um enorme desperdício de um tempo
va lioso quando ações corretivas poderiam ter sido to1nadas.
Implementação da gestão de projetos

Ainda que a cultura, o status e a politicagem possam criar barreiras para qualquer
nova filosofia de gerenciamento, há outr as barreiras que são direcionadas à gestão de
proJetos, como:
• Custo da implementação da gestão de projetos
• Riscos de fracasso na implementação
• Custo de t reinamento e limitações do treina1nento
• Necessidade de sofisticação
• Falta de encerra1nento nos projetos
• Ética profissional
• Mau p lanejamento
Custo da itnplementação: Há um custo associado à implementação da gestão de
projetos. A empresa precisa co1npra r equipamentos e software, criar uma metodologia
de gestão de projetos e desenvolver o desempenho das técnicas de geração de relató-
rios sobre projetos. Isso exige um dese1nbolso financeiro significativo, com o qual a
empresa talvez não seja capaz de arcar, a lém de exigir que recursos significativos sejam
retidos na implementação por um longo período de tempo. Com recursos limitados, e
o fato de que melhores recursos seriam necessários para a imple1nentação e removidos
de seus tra balhos em anda1nento, as empresas se acovardam diante da gestão de proje-
tos, embora conheçam seus benefícios.
Risco de fracasso: Mesmo que uma empresa esteja disposta a investir o tempo e o
d inheiro necessários pa ra a implen1entação da gestão de p rojetos, há um risco signifi-
cativo de que a implementação venha a fracassa r. E mesn10 que a implementação seja
ben1-sucedida, mas os projetos con1ecem a fracassar por inúmeros motivos, a culpa
será colocada en1 uma implen1entação falha. Os executivos poden1 acha r que sua po-
sição na hierarquia agora está insegu ra, uma vez que eles precisan1 explica r o tempo
e o dinheiro que foram en1pregados sen1 nenhun1 resultado real. Esse é o n1otivo pelo
qual os executivos ou se recusam a aceitar ou não apoian1 visivelmente a gestão de

proJetos.
Litnitações do treinamento: A implementaç.ã o da gestão de projetos é difícil se1n
progra1nas de t reinamentos para os trabalhadores. Isso cria t rês problemas adicionais.
Pri1neiro, que quantia de dinheiro precisa ser alocada para o treinamento? Segundo,
quem providenciará o treinamento e quais são as credenciais dos instrutores? Tercei-
ro, as pessoas devem ser li beradas do t rabalho no projeto para assistirem às au las de
treinamento? Treinar pessoas em gestão de projetos leva tempo e custa caro, seja,n
gerentes de projetos ou 1nembros de equipe que precisa1n ser t reinados. A soma dos
custos da implementaç.ã o e do treina1nento pode fazer com que os executivos evitem
aceita r a gestão de projetos.
Necessidade de sofisticação: a gestão de projetos exige sofisticação, não somente
em tecnologia ou ferra 1nentas lim itadas que pode1n estar disponíveis, ,nas també1n
na capacidade das pessoas para trabalharem juntas. Essa sofisticaç.ã o do trabalho e1n
equ ipe gerahnente é ausente em países de mercados emergentes. As pessoas podem não
ver nenhu1n benefício no trabalho em equipe, porque os outros podem ser capazes de
reconhecer sua falta de competência e seus erros. Elas não foram treinadas a trabalhar
adequadamente em equipes e não são recompensadas por sua contribuição à equipe.
Falta de encerra,nento nos projetos: Os funcionários geralmente têm medo de fica-
rem presos ao projeto no 1no 1nento de seu encerramento, quando as lições aprendidas
e as melhores práticas são captadas. As lições aprendidas e as 1nelhores práticas po-
dem se basear no que fizemos bem e no que fizemos 1na l. Os funcionários podem não
querer ver nada por escrito que indique que as melhores práticas foram descobertas a
partir de seus erros.
Ética profissional: Em algumas nações, a Ílnpossibi lidade de demitir pessoas cria
uma ética profissional relativamente fraca, contr ária às práticas da gestão de projetos.
Há uma falta de pontua lidade quanto à hora de chegar ao tra ba lho e a estar presen-
te em reuniões. Quando as pessoas aparecem nas reuniões, apenas boas notícias são
discutidas em um grupo, enquanto as más notícias são d iscutidas individualmente. As
habilidades de co1nunicação são fracas, assim como a produção de relatórios escritos.
Há uma falta de responsabilização, porque isso significa ter de explicar suas ações, se
as coisas não estivere1n indo be1n.
Mau planejamento: O mau planejamento é extre1no em nações de mercados emer-
gentes. Há u1na falta de comprometimento com o processo de planejamento. Devido à
falta de pad rões, talvez atribuída à ética profissional fraca, estimar a duração, esforços
necessários e custos torna-se muito d ifícil. O resultado fina l do mau planejamento é o
prolongamento do cronograma. Para trabalhadores que se sentem inseguros quanto
à sua próxima tarefa, isso pode ser visto como segurança no emprego, pelo menos no
curto prazo.
Outras barreiras
Há um número tão grande de outras barreiras que não é possível 1nencioná-las. En-
tretanto, algu1nas das mais importantes estão indicadas abaixo . Elas não são neces-
sariamente universais nas nações de mercados emergentes, e muitas delas podem ser
superadas.
• Ineficiências na conversão de 1noedas
• linpossibil idade de receber paga1nentos em dia
• C renças supersticiosas
• Leis contra a importação e exportação de propriedade intelectual

• Falta de tolerância em relação às crenças rel igiosas de parceiros de equipes virtuais
• Risco de sanções i1npostas pelos governos dos parceiros
• Uso de tecnologias fracas ou desatua lizadas
Recomendações
Embora tenhamos pintado um quadro bastante negativo, há grandes oportunidades
futuras nesses países. As nações de mercados emergentes possuem uma abundância de
talento que ainda está por ser cocahnente explorado. As verdadeiras capacidades des-
ses trabalhadores a inda são desconhecidas. As equipes virtuais de gestão de projetos
podem ser o ponto de partida para sua cocal implementação.
À medida que a gestão de projetos começa a crescer, os executivos sênior co-
meçam a reconhecer e aceitar os benefícios e ver sua base de negócios aumentar. As
parcerias e joint ventures que usam equipes virtuais se tornarão mais prevalecentes. As
barreiras que impedem o sucesso da implementação da gestão de projetos ainda exis-
tirão, mas começaremos a nos tornar especial istas em como viver e t rabalhar dentro
das barreiras e restrições impostas às equipes virtua is, que estão se tornando cada vez
.
mais comuns.
Há enormes oportunidades nas econom ias de mercados emergentes. Eles estão
começando a ver mais va lor na gestão de projetos e têm se esforçado para expandir
seu uso. Algumas das economias em rápido desenvolvimento são até muito mais agres-
sivas em oferecer o suporte necessário para quebrar muitas das barreiras indicadas
acima. À medida que vão surgindo 1na is histórias de sucesso, as várias econom ias irão
se fortalecer, se tornar mais conectadas e começa r a utilizar integra lmente a gestão de
projetos da forma como realmente deveriam.
Apoio por parte da gerência
7.0 Introdução
Como vimos no Capítu lo 6, os gerentes sênior são os arquitetos da cu ltura corpo-
rativa. Eles são encarregados de garantir que as culturas de suas empresas, uma vez
adotadas, não se desarticulem. U1n apoio visível por parte da gerência é essencia l para
manter a cultura de gestão de projetos. Acima de tudo, esse apoio precisa ser contínuo,
e não esporád ico.
Este capítulo examina a importância do apoio por pa rte da gerência na criação e
na manutenção da cultura de gestão de projetos. Estudos de caso ilustra1n a importân-
cia vital do empoderamento dos funcionários e do papel de patrocinador de projeto
no sistema de gestão de projetos.
7.1 Apoio visível por parte dos gerentes sênior

Assim como os pat rocinadores de projeto, os gerentes sênior oferecem apoio e enco-
rajamento aos gerentes de projetos e ao resto da equipe. As empresas excelentes e1n
gestão de projetos apresentam as seguintes características:
• Os gerentes sênior não se envolvem, mas estão disponíveis quando surgem problemas.
• Os gerentes sênior esperam receber relatórios de status de projeto concisos.
• Os gerentes sênior praticam o e1npoderamento.
• Os gerentes sên ior descentraliza1n a autoridade e a tomada de decisões do projeto.
• Os gerentes sên ior espera1n que os gerentes e suas equipes não somente identifi-
quem problemas, mas também sugiram a lternativas e façam recomendações para
a sua solução.
Entretanto, os limites entre u1n patrocínio eficiente e um patrocínio autoritário
são tênues. Robert Hershock, antigo vice-presidente da 3M, expressou bem essa ideia
durante u1na videoconferência sobre excelência em gestão de projetos:
Provavelmente a coisa mais importante é ter adesão desde as camadas hierárquicas. É pre-
ciso haver liderança desde o topo, e o topo deve apoiar lOOo/o todo esse processo. Se você
é uma pessoa controladora, se você é alguém com altas habilidades organizacionais e gosta
de colocar todos os pingos nos is e cuidar de cada detalhe, esse será um processo descon-
fortável, porque, basicamente, trata-se de um processo desordenado; você precisa ter muito
tolerância a erros. O que a gerência deve fazer é projetar a confiança que possui nas equipes.
Tem de estabelecer a estratégia e as diretrizes e, então, dar às e.quipes o empoderamento de
que elas precisam para concluir o trabalho. A melhor coisa que a gerência pode fazer depois
de treinar a equipe é deixar seu caminho livre.
Para garantir sua visibi lidade, os gerentes sênior precisam acred itar em andar pe-
los corredores da empresa. Dessa maneira, cada funcionário passará a reconhecer o
patrocinador e perceber que é apropriado se aproximar dele com perguntas. Gerencia-
mento de andar pelos corredores també1n significa que os patrocinadores executivos
deixam suas portas abertas. É importante que todos, inclusive os gerentes de área e
seus funcionários, se sintam apoiados pelo patrocinador. Deixar a porta aberta pode
ocasionalmente levar a problemas se os funcionários tentarem contornar os gerentes
de níveis mais ba ixos buscando uma autoridade de nível superior. Esses casos, porém,
não são frequentes, e o patrocinador pode facilmente repassar os proble1nas para o
gerente apropriado.
7.2 Patrocín io de projetos

Os pat rocinadores de projeto executivos oferecen1 orientação aos gerentes de pro-
jetos e às equipes de projetos. Eles também são responsáveis por ga rantir que os
gerentes de linha, que lideran1 departamentos funciona is, cumpran1 seus compro-
missos de recursos para os projetos que estão en1 andan1ento. Alén1 d isso, os patro-
cinado res de p rojeto executivos são responsáveis por manter a comunicação con1
os cl ientes.
O pat rocinador de projeto normalmente é um gerente de nível mais alto que, além
de exercer suas próprias responsabi lidades, oferece orientação contínua aos projetos
que lhe foram designados. Um executivo pode assumir o patrocínio de d iversos pro-
jetos concorrentes. Às vezes, em projetos de ma is baixa prioridade ou de manutenção,
u1n gerente de nível intermediário pode assumir o papel de patrocinador de projeto.
Uma organização que conheço prefere até designar gerentes intermed iários e1n vez de
executivos. A empresa acredita que isso evita o problema comum de falta de adesão
dos gerentes de área aos projetos (ver Figura 7- 1).
Em a lgumas corporações grandes e diversificadas, os gerentes sênior não têin tem-
po adequado para investir em pat rocínio de projeto. Nesses casos, o patrocínio cai
para o nível abaixo da gerência sên ior corporativa ou para um comitê.
Alguns projetos não precisam de patrocinadores. De maneira geral, o patrocínio é
necessário em projetos grandes e complexos, que envolve1n um forte comprometimen-
to de recursos. Projetos grandes e complexos també1n exigem um patrocinador para
integrar as atividades das linhas funciona is, para solucionar confl itos e para manter
fortes relações com o cliente.
Considere um exemplo de apoio do pat rocinador de um projeto. Um gerente de
projetos que estava lidando com um projeto e1n uma organização no governo federal
decidiu que um outro cargo seria necessário em sua equipe se o projeto quisesse cum-
prir o prazo final de conclusão. Ele já tinha identificado uma jove1n mulher na empre-
sa que possuía as qualificações que ele tinha descrito. No entanto, adicionar um outro
cargo de tempo integral parecia impossível. O tamanho do escritório de projetos do
governo era rest ringido por um documento que determinava o número máximo de
cargos disponíveis.
O gerente de projetos procurou a ajuda do executivo patrocinador do projeto. O
pat rocinador traba lhou junto com o departamento de recursos humanos e gerencia-
mento de pessoal da organização para adicionar o cargo selecionado. Dentro de um
prazo de 30 dias, a adição do cargo foi aprovada. Sem a intervenção do patrocinador,
a burocracia da organização teria levado 1neses para aprovar o cargo, o que teria sido
tarde demais para afetar o prazo fina l.
Projetos prioritários Patrocinador do projeto:

gerência sénior
Projetos de manutenção Patrocinador do projeto:

gerência média/ mais baixa
• Estabelecimento objetivo
• Planejamento prévio
Patrocinador
• Organização do projeto
do projeto
• Seleção dos principais participantes
• Plano mestre
Gerente de • Políticas
projetos • Monitoramento da execução
• Estabelecimento de prioridades
Equipe de projeto Equipe do projeto • Resolução de conflitos
• Contato entre executivos e clientes
Figura 7- 1 Papéis do patrocinador de projeto. Fonte: Reimpresso de H. Kerzner, ln Search

of Excel/ence in Project Management, Hoboken, NJ: Wiley, 1998, p. 159.
Em um outro exemplo, o presidente de uma empresa manufatureira de médio

porte queria preencher o cargo de patrocinador em um projeto especial. O gerente
do projeto decid iu tirar proveito do presidente para a vantagem do projeto. Ele ped iu
ao presidente/pat rocinador que lidasse com u1na situação difícil. O presidente/patro-
cinador viajou até a sede da etnpresa e voltou dois dias depois com uma autorização
para uma nova ferramenta de que o gerente do projeto precisava. A empresa acabou
economizando tempo com o projeto, que foi concluído quatro meses antes do prazo
original agendado.
Patrocínio por comitê

À medida que as empresas crescem, às vezes se torna impossível designar u1n gerente
sênior a e.ada projeto, e, assim, os comitês agem no lugar de patrocinadores de projeto
individuais. Na verdade, a tendência recente foi o patrocín io por co1nitês e1n muitos
tipos de organização. Um comitê de patrocín io de projeto nonna lmente é formado por
um representante de cada função da e1npresa: engenharia, 1narketing e produção. Os
comitês podem ser temporários, quando são reunidos para patrocinar um único pro-
jeto ou um projeto que vá durar por u1n tempo limitado, ou permanentes, quando u1n
comitê fixo assume o patrocínio de projetos contínuo de novos projetos.
Por exemplo, a General Motors Powertra in tinha alcançado a excelência utilizan-
do pat rocínio por comitê. Dois importantes executivos, o vice-presidente de engenha-
ria e o vice-presidente de operações, lidera ra 1n o Escritório de Produtos e Operações,
um grupo fonnado para supervisionar o gerenciamento de todos os programas de
produtos. Esse grupo demonstrou um apoio visível por parte do nível executivo e u1n
compromisso com toda a organização. Seus papéis e responsabilidades eram:
• Nomear o gerente e a equipe do projeto como parte do processo do termo de
abertura
• Tratar de questões est ratégicas
• Aprovar o contrato do programa e testar sua suficiência

• Garantir a execução do programa por meio de revisões periódicas com os gerentes
de programa
Fases do patrocínio de um projeto

O papel do patrocinador muda ao longo do ciclo de vida de u1n projeto. Durante as
fases de planeja1nento e iniciação, o patrocinador dese1npenha u1n papel ativo nas
seguintes atividades:
• Ajudar o gerente de projetos a estabelecer os objetivos do projeto
• Oferecer orientação ao gerente de projetos durante as fases de organização e sele-
ção de funcionários
• Expl icar ao gerente de projetos que fatores ambientais ou políticos podem influen-
ciar a execução do projeto
• Estabelecer a prioridade do projeto (t rabalhando sozinho ou co1n out ros execu-
tivos da empresa) e, então, informar o gerente de projetos sobre a prioridade do
projeto na empresa e o motivo dessa prioridade ter-lhe sido at ribuída
• Oferecer orientação ao gerente de projetos ao estabelecer as políticas e procedi-
mentos do projeto
• Funcionar como o ponto de contato para os clientes
Durante a fase de execução de um projeto, o patrocinador precisa ser muito cui-
dadoso ao decidir que problemas exigem sua orientação. Tentar se envolver com cada
problema que surge em um projeto resultará em microgerenciamento. Poderá, tam-
bém, solapar a autoridade do gerente e dificultará para os executivos cumprirem suas
responsabi lidades comuns.
Para projetos de curto prazo, co1n dois anos ou menos, normalmente é melhor que
o pat rocinador de projeto não mude ao longo da duração do projeto. Para projetos
de longo prazo, de cinco anos, mais ou menos, diferentes pat rocinadores pode1n ser
designados para cada fase do projeto, se necessário. Escolher patrocinadores ent re
os executivos no mesmo nível corporativo funciona 1nelhor, já que o pat rocínio no
mesmo nível cria condições de igua ldade, enquanto e1n diferentes níveis, pode ocorrer
favoritismo.
Os pat rocinadores de projeto não precisam vir da área funcional em que a maior
pa rte do trabalho do projeto será rea lizada. Algumas e1npresas chegam até a designar
pat rocinadores de funções que não têm nenhu1n interesse no projeto. Teoricamente,
esse sistema promove uma tomada de decisões imparcial.
Relações com o cliente

O papel de patrocinadores executivos de projeto nas relações com o cliente depende
do tipo de organização (totalmente direcionada ou parcialmente direcionada a proje-
tos) e o tipo de cl iente (externo ou interno) . Contratadas que traba lham em projetos
maiores para clientes externos norma lmente dependem de pat rocinadores executivos
de projetos para manter os clientes totalmente informados sobre o progresso e1n seus
projetos. Os cl ientes com projetos multimilionários geralmente ficam de olho em como
seu dinheiro está sendo gasto. Eles ficam aliviados em ter um pat rocinador executivo
a que1n possam recorrer para fazer perguntas.
É uma prática comum para as contratadas fortemente envolvidas em licitações que
os contratos incluam tanto o currículo do gerente de projeto quanto do patrocinador
executivo de projeto nas propostas. Mantendo todos os outr os fatores constantes, os

currículos podem dar a uma contratada uma vantagem competitiva sobre uma outra.
Os cl ientes preferem ter uma via de comunicação direta aberta com os gerentes
executivos de suas contratadas. Uma contratada identificou as funções do patrocina-
dor executivo de projetos como:
• Participar do esforço preliminar de vendas e das negociações de cont ratos
• Estabelecer e manter relações de alto nível com os clientes
• Auxi liar gerentes de projetos e1n colocar o projeto em andamento (planejamento,
seleção de funcionários e assim por diante)
• Manter o conhecimento atua l de das principais atividades do projeto
• Lidar com os principais problemas cont ratuais
• Interpretar políticas da e1npresa para gerentes de projetos
• Ajudar os gerentes de projetos a identificar e solucionar problemas significativos
• Manter os gerentes gera is e gerentes de clientes informados de problemas signifi-
. .
cativos com os proJetos
Tomada de decisões
In1agine que a gestão de projetos seja con10 u1na corrida de carros. Uma bandeira ama-
rela é um aviso para ficar acento a un1 problema. Bandeiras an1arelas exigen1 ação do
gerente do projeto ou do gerente de área. Não há nada errado en1 informar um execu -
tivo sobre um problen1a co1n bandeira amarela, contanto que o gerente de projetos não
procure o patrocinador para solucionar o proble1na . Bandeiras vennelhas, porém, nor-
maln1ence exigen1 o envolvin1enco direto do patrocinador. Elas indican1 problemas que
podem afetar prazo, custo e os parân1cros de desempenho do projeto. Então, bandeiras
vermelhas precisan1 ser levadas a sério, e as decisões precisa1n ser tomadas cola borati-
va1nence pelo gerente de projeto e pelo patrocinador de projeto.
Problemas sérios às vezes resultam em conflitos sérios. Desacordos entre gerentes
de projetos e gerentes de área não são comuns, e exigem uma intervenção atenta por
parte do patrocinador executivo de projeto. Primeiro, o pat rocinador deve certificar-
-se de que o desacordo não poderia ser solucionado sem sua ajuda. Segundo, precisa
levantar informações de todos os lados e considerar as a lternativas possíveis. Então, o
pat rocinador deve decidir se está qua lificado a resolver a disputa. Geralmente, as dis-
putas são de natureza técnica e exige1n a lguém co1n a base de conhecimento adequada
para solucioná-las. Se o patrocinador não for capaz de solucionar o problema, ele terá
de identificar uma outra fonte de autoridade que possua o con heci1nento técnico. E1n
última análise, u1na solução justa e apropriada pode ser compartilhada por todos os
envolvidos. Se não houvesse nenhum pat rocinador executivo no projeto, as pa rtes e1n
disputa seriam forçadas a subir a hierarquia de autoridade até encontrar um superior
comum para ajudá-los. Ter pat rocinadores executivos de projeto m inimiza o nú1nero
de pessoas e a quantidade de ce1npo necessária para resolver as disputas de t raba lho.
Planejamento estratégico
Os executivos são responsáveis por realizar o p lanejamento est ratégico da empresa, e
os gerentes de projetos são responsáveis pelo planejamento operacional dos projetos
que lhes foram designados. Embora o processo de pensamento e lim ites de tempo se-
jam diferences para os dois tipos de planejamento, as habi lidades de planejamento es-
tratégico dos patr ocinadores executivos podem ser úteis para os gerentes de projetos.
Para projetos que envolvem desenvolvimento de processos ou produtos, os patrocina-

dores podem oferecer um tipo especial de vigi lância de mercado para identificar novas
oportunidades que possam influenciar a lucratividade da organizaç.ã o no longo prazo.
Além disso, os patrocinadores pode1n obter 1nuitos conhecimentos estrategica1nente
importantes de gerentes e funcionários de níveis ma is ba ixos. Que outras pessoas sa-
bem melhor quando a organização está carente da habilidade e base de conhecimento
de que precisa para começar a produzir um novo tipo de produto? Quando a empresa
p recisa contratar mão de obra co1n 1na ior qualificação técnica? Que mudanças técni-
cas provavelmente afeta rão sua indúst ria?
7.3 Excelência em patrocínio de projetos

Em empresas excelentes, o papel do pat rocinador não é supervisionar o gerente de
projetos, mas garantir que os interesses tanto do cl iente quanto da empresa sejam
reconhecidos. Ent retanto, co1no os dois próximos exemplos revela 1n, raramente é pos-
sível tomar decisões executivas que agradem a todos.
A Franklin Engineering (nome fictício) tinha uma reputação de desenvolver pro-
dutos inovadores e de alta qualidade. Infelizmente, a empresa pagou u1n preço alto por
sua reputação: um grande orçamento de P&D. Menos de 15% dos projetos iniciados
pela P&D levaram à comercial ização total de um p roduto e à recuperação dos custos
de pesquisas.
Os gerentes sênior da empresa decid iram implementar uma política que deter-
minava que todos os patrocinadores de projeto de P&D rea lizassem periodicamente
aná lises de custo-benefício em seus projetos. Quando o índ ice de custo-benefício de
u1n projeto não conseguisse alcança r os níveis previstos na política, o projeto seria
cancelado para o benefício de toda a empresa.
Inicialmente, o pessoal de P&D ficava insatisfeito em ver seus projetos serem can-
celados, mas logo perceberam que o cancela1nento precoce era melhor do que investir
grandes quantias em projetos que provavelmente fracassaria 1n. Finahnente, os geren-
tes de projetos e me1nbros de equipe chegara1n à conclusão de que não fazia sentido
desperdiçar recursos que poderiam ser mais bem empregados em projetos mais bem-
-suced idos . Em dois anos, a organização se viu tr abalhando em mais projetos com
u1na taxa de sucesso mais alta, mas sem nenhum aumento no orça1nento de P&D.
Um outro caso fictício envolve uma e1npresa sediada na Ca lifórn ia que projeta e
manufatura equipamentos de computador. Chamemo-la de Design Solutions. O grupo
de P&D e o grupo de projeto estavam cheios de indivíduos talentosos que acreditavam
que podiam fazer o Ílnpossível, e geralmente o faziam. Esses dois poderosos grupos
tinham pouco respeito pelos gerentes de projeto e não gostavam de cronogramas, pois
achavam que eles limitavam sua criatividade.
Em junho de 1997, a empresa intr oduziu dois novos produtos que chegaram ao
mercado pouco antes da concorrência. A empresa tinha iniciahnente planejado intro-
duzi-los no final de 1996. O motivo das liberações tardias: os projetos tinham se atra-
sado devido ao desejo da equipe de projetos de exceder as especificações necessárias,
e não apenas cumpri-las.
Para ajudar a empresa a evitar atrasos si1n ilares no futuro, decidiu-se designar pa-
t rocinadores executivos para cada projeto de P&D para se certificar de que as equipes
de projetos aderisse1n às práticas de gerenciamento-padrão no futuro. Alguns membros
tentaran1 esconder seus sucessos con1 o raciocínio de que conseguiriam fazer n1elhor,
mas o patrocinador ameaçou despedir os funcionários, e eles, finalmente, cederam.
As lições em ambos os casos são claras. O patrocínio executivo na verdade pode

apri1no ra r os siste1nas existentes de gestão de projetos pa ra melhor a tender aos inte-
resses da empresa e de seus clientes.
7.4 Patrocínio em ação na Hewlett-Packard

Segundo Doug Bolzman, arquiteto consultor, PMP"', especial ista e1n !TIL® na HP:
A gerência apoia os res ultados da gestão de projetos, e se o PMO estiver em posição de
compreender o ambiente atua l e como melhorar os resultados, a gerência escutará. Se a ge-
rência recebe uma declaração de pro blemas em relação a como os projetos agora não estão
sendo gerenciados eficientemente, então eles serão de pouco valor.
Gostaríamos de compartilhar uma história de quando um parceiro de negócios veio
até nós e perguntou por que nossa Metodologia de Gerenciamento de Liberações não tinha
sido formalmente implementada em toda a organização como um método corporativo. Esse
nosso patrocinador tinha conexões e marcou uma reunião com o CIO de nossa empresa
(isso foi alguns anos depois da virada do século). Apresentamos a metodologia geral, seu
valor para a organização, as histórias de sucesso que tínhamos a lcançado. Sua resposta foi:
"Isso é tudo muito interessante, mas o que vocês querem que eu faça?". O patrocinador
dessa reunião sentou-se em s ua cadeira e res pondeu: "estamos procurando 'comprom isso
gerencial' para essa metodologia ". Ao final da reunião, percebi que se não tivesse sido pelo
excelente jantar que tivemos na noite anterior, depois de viajarmos até a sede, a reunião
teria sido uma total perda de tempo. O q ue pretendo ressaltar aqui é que não definimos o
que especificamente estávamos procurando na equipe de gerência. Agora, quando estamos
na mesma situação, explicamos os investimentos, o financiamento, os recursos necessá rios,
a mudança cultural e as políticas que eles precisam sancionar e colocar em prática. Descre-
vemos seu papel e suas responsabilidades para apoiar o projeto, a prática, o PMO, o u seja
lá o que for que estivermos esperando que eles apoiem.
7.5 Zurich America lnsurance Company: melhorando

o engajamento das partes interessadas
Kathleen Cavanaugh, PMP®, líder do PMO de Zurich - ZNA, conta co1no os patro-
ci nadores podetn ajuda r a melhorar o engajamento das partes interessadas. As lições
aprend idas do projeto oferecem u1na perspectiva inestimável sobre o que está e o que
não está funcionando bem nos projetos/programas. Quando as lições aprendidas são
levadas até o nível do portfólio, os problemas comuns enfrentados por esses projetos/
programas são revelados, e surgem tendências que, caso contr ário, teriam sido negli-
genciadas.
Uma das oportunida des de melhorias identificadas com as revisões de lições
aprend idas do projeto nos últimos a nos na Zurich na América do Norte (ZNA) foi a
necessidade de um novo papel de liderança de projeto chamado Líder de Negócios. O
feedback agregado do projeto mostrou que em projetos/programas grandes e t rans-
formadores, u1n engaja1nento empresarial mais forte era uma "necessidade absoluta»
desde o início do esforço e até a pós-implementação. Observamos também que as
camadas intermediárias da gerência muitas vezes podem apresentar os ma iores de-
safios de a linhamento para esses tipos de grandes projetos/progra1nas de 1nudanças
relacionadas a processos e/ou pessoas. A necessidade era óbvia. As partes interessa-
das de todos os níveis precisam ser mantidas informadas, alinhadas aos objetivos do
projeto e envolvidas no projeto/programa ao longo de todo o seu ciclo de vi da. Sem o
compromisso das partes interessadas, o projeto/programa sofrerá de baixas taxas de

aceitação/adoção ou, o que é pior, pode ser cancelado.
Dessa forma, para ajudar a solucionar esse problema, os líderes de toda a empresa
t rabalharam no sentido de definir as responsabi lidades, a fi 1n de colocar o papel de
Líder de Negócios em vigor. Foi feito um teste piloto, para ajudar a provar o conceito
e para ganhar adeptos antes da implementação definitiva. Foram fornecidas diretr izes
para ajudar a esclarecer as responsabilidades do Líder de Negócios que, originalmente,
incluíam: alinhar as partes interessadas, garantir que os objetivos do projeto apoiem
continua1nente a estratégia empresarial, utilizar o gerencimento de mudanças para
preparar as pa rtes interessadas para os impactos do projeto, garantir o apoio na pós-
-implementação e a realização de benefícios. Entretanto, as verdadeiras tarefas do Lí-
der de Negócios são, em última análise, determinadas pelo Pat rocinador do Projeto e
podem variar de um projeto para outro.
O papel propriamente dito fo i criado para complementar e colaborar com os
papéis de Patrocinador do Projeto e Líder do Projeto, criando u1na Equipe Triangu-
lar de Liderança de Projeto. Juntos, eles formam uma forte parceria e unem forças
para tomar decisões essenciais para o projeto/programa. O Líder do Projeto e o Líder
de Negócios gera lmente traba lham bem de perto durante todo o projeto/programa,
conectando os mundos dos Negócios e de T I. Para ajudar a garantir que as partes
interessadas continuem engajadas, uma variedade de métodos pode ser util izada, in-
cluindo reuniões de grupos de foco, conselhos de usuários, e 1núltiplos mecanismos
de feedback. A gerência intermediária deve ser um ponto focal para as comunicações
do projeto/programa, já que essas são as pessoas que podem garantir que os usuários
finais escutem e compreendam as mensagens principais. O patrocinador fornece uma
supervisão e orientaç.ã o contínuas ao projeto/programa. Se o projeto/programa en-
cont rar um obstáculo, o ca1ninho de escalada do confl ito gera lmente va i direto ao
patrocinador e/ou ao co1nitê de d ireção em busca de uma solução.
Para ser eficiente, a pessoa que desempenhar o papel de Líder de Negócios p re-
cisa ser alguém en1 un1 nível razoavelmente alto da organização, e deve ter un1 con-
junto de habilidades inigualável. .. habilidades estas que incluem un1 conhecimento
multifuncional, a capacidade de desafia r o status quo e quebrar ba rreiras e unir as
partes interessadas. O papel p ropriamente dito exige que o escolhido seja forte na
arte do gerencian1ento de mudanças e da comun icação. No entanto, para que essa
pessoa seja realn1ente bem-sucedida, ela p recisa ter permissão para se dedicar ao
projeto/programa, especialmente em esforços grandes e multifuncionais. Geralmen-
te achamos que o papel exige un1 forte envolvimento nas atividades cotidianas do
p rojeto/programa. Então, em muitos casos, o Líder de Negócios selecionado abdica
de suas tarefas por pelo menos 12 a 18 meses a fim de se tornar oficialmente 100%
dedicado a esse papel essencial pa ra o p rojeto/programa. Convencer a liderança de
tirar alguém de seu papel e fazê-lo se dedicar a um grande esforço transforn1ador por
esse longo período de ten1po nen1 sempre é un1a tarefa fácil. No entanto, se o projeto/
p rograma for realmente importante para a organ ização, esse será um pequeno preço
a ser pago para ga rantir uma implementação bem-sucedida. É uma grande decisão
a ser tomada e uma decisão que, norn1almente, é in1pu ls ionada pelo patrocinador,
que possui consciência o rganizacional e conhecin1ento pa ra identificar a pessoa certa
para desen1pen ha r o papel.
O valor do papel do Líder de Negócios cresceu sign ificativan1ente nos últimos
anos, e uma con1unidade de p rática está sendo formada para que os Líderes de Ne-
gócios possam con1part ilhar suas experiências e lições aprend idas, pa ra continuar
aprimorando suas capacidades. O papel está se tornando um sólido alicerce da Equ i-
pe de Liderança do Projeto pa ra projetos/programas grandes e transforn1adores na
ZNA. A colaboração e a sinergia entre os papéis de Patrocinador do Projeto, Líder

do Projeto e Líder de Negócios são a chave para seu sucesso. Essa estrut ura de Li-
derança do Projeto está se n1ostrando ser um n1odelo viável para ajudar a garantir
que o engajamento e al inhamento das partes interessadas ao longo de todo o ciclo
de vida do projeto/progran1a, o que significa mais resultados de sucesso e n1aior sa-
tisfação do usuário fina l.
7.6 Governança de projeto

Todos os projetos têm o potencial de passar por problemas, ,nas, etn geral, a gestão de
projetos pode funcionar bem, contanto que as exigências não imponham uma pressão
severa sobre o gerente de projetos, e exista um patrocinador de projeto como al iado
para auxiliar o gerente de projetos quando surgir a lgum proble1na. Infel izmente, no
ambiente caótico de hoje etn dia, essa pressão parece estar aumentando, devido ao
fato de:
• Empresas estaretn aceitando projetos de a lto risco e alto grau de complexidade
como uma necessidade para a sobrevivência
• Cl ientes estarem exigindo um a lto volume de produtos de a lta qualidade cotn
certo grau de personalização
• Ciclos de vida de projetos e tempos de desenvolvimento de novos produtos às
vezes serem comprimidos
• Fatores ambientais empresariais estarem tendo um impacto maior sobre a execu-
ção do projeto
• Clientes e partes interessadas quererem estar mais ativa1nente envolvidos na exe-
cuç.ã o dos projetos
• Empresas estarem desenvolvendo parcerias estratégicas com fornecedores, e cada
fornecedor estar etn un1 nível diferente de maturidade en1 gestão de projetos
• A competição globa l ter forçado as empresas a aceitarem projetos de clientes que
se encontram, todos, em níveis diferentes de 1naturidade em gestão de projetos e
com diferentes requisitos de relatórios
Essas pressões tendem a tornar os processos de ton1ada de decisões mais lentos,
em uma época en1 que as partes interessadas querem que os projetos e processos
sejan1 acelerados. Uma pessoa, a inda que esteja agindo como patrocinadora de pro-
jeto, pode não ter nem o tempo nen1 a capacidade de abordar todas essas questões
adicionais. O resu ltado será uma desaceleração do projeto, que pode ocorrer pelos
. .
segu intes n1ottvos:
• Esperar que o gerente de projetos tome decisões em áreas em que possui conheci-
mentos limitados
• O gerente do projeto hesitar em aceitar tota l responsabilidade e ser o encarregado
pelos projetos
• Ca,nadas excessivas de gerência sendo superpostas à organizaç.ã o da gerência do
proJeto
• A gestão de riscos ser empurrada para os níveis mais altos da hierarquia organiza-
cional, resultando em decisões at rasadas
• O gerente de projetos demonstrar uma capacidade de liderança questionável etn
alguns dos projetos não t radicionais
Os problemas resu ltantes dessas pressões podem não ser capazes de ser resolvi -
dos, pelo menos com facilidade e a tempo, por um ún ico patrocinador de projeto.
Esses problemas podem ser resolvidos usando uma governanç.a de projeto eficiente.
A governança de projeto é, na verdade, uma est rutura a partir da qual as decisões são
tomadas. A governança está relacionada a decisões que definem expectativas, respon-
sabilidades, concessão de poder ou verificação de desempenho. A governança está re-
lacionada a gerenciamento consistente, políticas coesas, processos e direitos de tomada
de decisões para determ inada área de responsabi lidade. A governança permite que
ocorra uma tomada de decisões eficiente.
Cada projeto pode ter uma governança diferente, mesmo que cada um deles use
a mesma 1netodologia de gestão de projetos empresaria l. Uma função de governança
pode operar co1no um processo separado ou como parte de uma liderança de gestão de
projetos. A governança não é criada para substituir a tomada de decisões do projeto,
mas para evitar que decisões indesejáveis sejam tomadas.
Historicamente, a governança era propiciada por um único patrocinador de proje-
to. Hoje, é real izada por u1n comitê e pode incluir representantes de cada organização
das pa rtes interessadas. A Tabela 7-1 mostra várias abordagens de governança basea-
das no tipo de equipe de projeto. A formação do co1nitê pode 1nudar de um projeto
para outro e de uma indúst ria para outra. A participação ta 1nbém pode ser baseada no
número de partes interessadas e se o projeto é de um cl iente externo ou interno. Em
projetos de longo prazo, a participação pode mudar ao longo do projeto.
A governança em projetos e programas às vezes falha porque as pessoas confun-
dem governança de projeto co1n governança corporativa. O resultado é que os mem-
bros do comitê não têm certeza de qual deveria ser seu papel. Algumas das principais
d iferenças incluem:
• Alinha mento : A governança corporativa se focal iza em quanto o portfólio de
projetos está alinhado e satisfaz os objetivos de negócios de maneira geral. A
governança de projetos se focaliza em n1aneiras de manter um p rojeto no can1 i-
nho certo.
• Dir eção: A governança corporativa fornece uma direção estratégica com um foco
em como o sucesso do projeto satisfará objetivos corporativos. A governança de
projeto é ma is voltada a u1na direção operacional com decisões baseadas nos pa-
râmetros predefinidas em escopo de projeto, prazo, custo e funcionalidade.
TABELA 7-1 Tipos de governança de projeto

Estrutura Descrição Governança
Localmente dispersa Os membros de equipe podem trabalhar em Normalmente, uma única pessoa
tempo integral ou parcial. Eles ainda estão ad· age como patrocinador, mas pode
ministrativamente ligados à sua área funcional ser um comitê interno dependendo
da complexidade do projeto
Geograficamente dispersa Esta é uma equipe virtual. O gerente de pro- Normalmente, a govemança é por
jetos pode nunca ver alguns dos membros de comitê e pode incluir a participa-
equipe. Os membros de equipe podem traba- ção das partes interessadas
lhar em tempo integral ou parcial
Colocalizada Todos os membros de equipe estão fisicamen- Normalmente, uma única pessoa
te localizados próximos do gerente de projetos. age como patrocinador
O gerente de projetos não tem nenhuma res-
ponsabilidade pela administração salarial
Projetizada Esta é similar a uma equipe oolocalizada, Pode ter governança por comitê
mas o gerente de projetos funciona, em linhas dependendo do tamanho do
gerais, como um gerente de área e pode ter projeto e do número de parceiros
responsabilidades salariais estratégicos
• Dashboards: Os dashboards da governanç.a corporativa baseiam-se em métricas

financeiras, de marketing e de vendas. Os dasbboards da governança de projeto
têm métr icas de operações sobre o prazo, custo, escopo, qualidade, itens de aç.ã o,
r iscos e deliverables.
• Participação: Os comitês de governanç.a corporativa são compostos pelos níveis
mais sên ior da gerência. A participação na governança de projeto pode incluir
alguma participação da gerência intermediária.
Utn outro 1notivo pelo qual pode ocorrer algum fracasso é os membros do grupo
de governanç.a de projetos ou progratnas não compreenderem a gestão de projetos ou
progratnas. Isso pode levar a um microgerenciamento pelo comitê de govemança. Há
sempre uma questão sobre que decisões devem ser tomadas pelo cotnitê de governança
e que decisões o gerente de projetos pode tomar. Em geral, o gerente de projetos deve
ter a autoridade para totnar decisões relacionadas a ações necessárias para 1nanter
as linhas de base. Os comi tês de governança precisam ter autoridade para aprovar
mudanças de escopo acima de certo valor em dólar, e para tomar decisões necessárias
para alinhar o projeto aos objetivos e estratégia corporativa.
7.7 Tokio Marine: excelência na governança

de um projeto
A gerência executiva deve estabelecer a governança de TI:
Tokio Marine Group
1
Por: Yuichi (Rich) Inaba, CISA e Hiroyuki Shibuya
O Tokio Marine Group é um grupo corporativo global envolvido em uma grande

variedade de negócios na área de seguros. Ele consiste em aproximadamente 70 em-
presas em cinco continentes, incluindo a Tokio Marine and Nichido Fire Insurance
Uapão), a Philadelphia Insurance (EUA), a Kiln (Reino Unido) e a Tokio Marine Asia
(Singapura).
Além da Tok io Marine and Nichido Fire Insurance, que é a maior seguradora de
imóveis e acidentes do Japão, o Tokio Marine Group possui várias out ras empresas no
Japão, como a Tokio Marine and Nichido Life Insurance Co. Ltd., além de prestado-
ras de serviços, como a Tokio Marine and N ichido Medical Service Co Ltd . e a Tokio
Marine e Nachido Faci lities Inc.
Implementando a governança de TI no Toki o Marine Group

A Tok io Marine Holdings, que é responsável por esta belecer a abordagem de gover-
nança de TI do grupo, observou que a gerência executiva das empresas do Tokio Ma-
rine Group acredita que a TI seja uma infraestrutura essencial para o gerencia tnento
de negócios, e esperava fortalecer a gerência da empresa por meio de sua utilização.
Entretanto, alguns diretores e executivos tinham uma itnpressão negativa da TI - que a
TI é difíci l de compreender, custa demais e resulta etn frequentes problemas no sistetna
e falhas no desenvolvimento de sistemas.
É co1num para a gerência executiva de uma organ ização reconhecer a importância
do desenvolvimento de sistemas, mas para colocar esse desenvolvi1nento somente nas
1
Originalmente publicado em Cobir* Focus, yoJume 1, janeiro, 201 3 . © 2013 ISACA. Todos os direitos
reservados.
mãos no departamento de TI. Out ros executivos vão ainda ma is longe, dizendo que
o gerenciamento ou governança de TI não é responsabi lidade de ninguém além do
departamento de TI ou dos principais executivos de infonnações (CIOs). Essa linha de
pensamento a respeito da TI é similar ao processo de pensamento que diz que a conta-
bilidade é de responsabi lidade do departamento de contabilidade e lidar com questões
relacionadas aos funcionários é papel do departamento de recursos humanos.
Esses são comportamentos típicos de organizações que não implementam sistemas
de governança de TI. A gerência executiva da Tokio Marine Hold ings reconheceu que
a TI não deve ser responsabilidade apenas do depa rtamento de TI, mas que é uma fer-
ramenta para forta lecer os negócios.
A gerência da Tokio Marine Holdings reconheceu que havia vários tipos de falhas
no desenvolvimento de sistemas (p.ex.: atr asos no desenvolvimento devido à data de
entrada do serviço, projetos que ult rapassa tn o orça1nento). Ainda ma is frequente-
mente, a organização estava encont rando lacunas nos requisitos - por exemplo, quan-
do depois de montar um sistema, as pessoas d izem, "Este não é o sistema que pedimos
que você montasse" ou "O sistema que você montou não é de fáci l utilização. É inútil
para ,ninha empresa".
Por que ocorrem lacunas nos requisitos

O processo de desenvolvimento de sistemas é similar ao da const rução de ed ifícios.
Entretanto, há uma diferença essencial entre os dois: o desenvolvimento de sistemas
não é visível, enquanto a construção de um edifício, é. Portanto, no desenvolvimento
de sistemas, é inevitável que haja lacunas de reconhecimento e de comun icação entre a
etnpresa e o departamento de TI.
A solução do Tokio Marine Group para o sucesso do desenvolvimento

de sistemas
Para preencher essas lacunas, a empresa e o departamento de TI precisam se co1nunicar
o suficiente para mini1nizar as lacunas [entre] A e C na Figura 7- 2 e maxin1izar un1a
con1preensão con1um de B. O caminho para o sucesso do desenvolvimento de sistemas
é melhorar a qualidade da con1unicação entre a etnpresa e o depa rta tnento de TI.
Essa comunicação não pode ser alcançada ou mantida em um relacionatnento uni-
lateral. A comunicação ideal se estabelece somente quando há uma parceria igual itária
entre a empresa e o departamento de TI com papéis e responsabilidades mutuamente
a locadas.
Esse é o conceito central do Sistema de Encarregados pelos Aplicativos.
Implementando o Sistema de Encarregados pelos Aplicativos

A Tokio Marine Holdings decidiu implementar o Sistema de Enca rregados pelos Apli-
cativos como um conceito central do Sistema de Governança de TI do grupo. A Tokio
Marine Holdings acred ita que é essencia l para as empresas do grupo serem bem-suce-
d idas no desenvolvimento de sistemas e alcançarem o cresci tnento do grupo no atual
ambiente de negócios.
A ideia fundamental do Sistema de Encarregados pelos Apl icativos (Figura 7- 3) é:
• Cooperação mútua entre en1presa e TI com funções adequadas de verificação e
equ ilíbrio, responsabilidades apropriadamente alocadas e objetivos compa rt i-
lhados.
• Comunicação próxima entre empresa e TI, cada pa rte levando etn consideração
seus respectivos papéis e responsabi lidades.
Os requisitos que a empresa Os requisitos que a TI

deseja expressar reconhece
---;.-i A
Figura 7- 2 A lacuna dos requisitos.
Papéis e responsabllldades dos Papéis e

encarregados pelos apllcallvos Relação responsabllldades da TI
-.n.. cooperativa com
...a.
........
objetivos comuns 2. Consultoria de questões
....
=
ft
1. Solicitar implementação
do sistema
técnicas e questões relacionadas
a custos, sugestão de requisitos
otimizados
........
3
3. Finalização da definição
....
ft
&
......-
i. dos requisitos, determinação
da análise de custo-benefício
a
...
;.
Q,
.....
5'
5. Teste de aceitação pelo
usuário (casos de teste
4. Criação do código,
testes de sistema ..-
=
de desenvolvimento)
-=alt 7. Instrução e desenvolvimento
6. Teste de desempenho,
formatação do servidor, etc.
s
de manuais
Figura 7- 3 O Sistema de Encarregados pelos Aplicativos do Tokio Marine Group.
Sucesso rápido na Tokio Marine and Nichido Fire lnsurance

A Tokio Marine and Nichido Pire Insurance Co. Ltd., a 1naior e1npresa do grupo, im-
plementou o Sistema de Encarregados pelos Aplicativos e1n 2000. A implementação
imediatamente reduziu os problemas do sistema em 80'%. (Ver Figura 7-4. )
Mentalidade da IT
A 1nenta lidade da Tokio Marine é a de que apenas a gerência executiva pode estabele-
cer o sistema de governança de TI da empresa. Assim, a governança de TI é de respon-
sabilidade da gerência executiva.
Além disso, a organizaç.ã o tem a 1nentalidade de que todos os funcionários, não
somente a gerência executiva, devem compreender o princípio de que fortes sistemas
de TI não podem ser real izados somente pelo departamento de TI, mas exigem a co-
operação ent re a empresa e a TI. É importante que todos os funcionários reconheçam
os problemas da TI como seus próprios, e não como responsabilidadedo departamen-
to de TI.
Estabelecer tal mentalidade na empresa é papel da gerência executiva.
500
' 492
1
400
\
\
300
200
\
\
100
/
.O.
,_
1'"
.
"- . ,~ ""
""
.. • 40 • ~JS
o
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 201O
Figura 7-4 Número de problemas do sistema.
Sistema de governança de TI no Tokio Marine G roup

Caracterizado pelo Sisren1a de Encarregados pelos Aplicativos, a Tokio Marine Holdings
introduziu uma estrutura de governança de TI, focalizada na estrutura COBIT 4.1, espe-
cificamente o domínio Planejar e Organizar (PO, ou Plan and Organize).
Os principais objetivos da estrutura de govemança de TI são:

• Estabelecer políticas básicas para a governança de TI - a Tok io Marine Holdings
estabeleceu as Políticas Básicas para Governança de TI como as políticas da estru-
tura de governança de TI do grupo.
• Estabelecer princípios orientadores para a governança de T I - a Tokio Marine
Holdings define sete princípios como seus princípios orientadores. (Ver Tabela
7-2.) Esses princípios abordam as cinco áreas de foco definidas no Briefing do
Consel ho Diretor sobre Governança de TI, focal izando-se particu larmente no ali-
nhamento est ratégico e na ent rega de valor. Os sete princípios são incluídos nas
Políticas Básicas de Governança de T I. A Tokio Marine Holdings acredita que o
princípio ma is importante seja o Sistema de Encarregados pelos Aplicativos, que é
declarado da seguinte maneira:
Ao implementar o plano, é importante para a unidade de TI e para as unida-
des encarregadas pelo aplicativo cooperare1n umas com as out ras com funções
adequadas de verificações e equi líbrio. A gerência deverá determinar clara1nente o
comparti lha1nento adequado de papéis entre a unidade de TI e as unidades encar-
regadas pelos aplicativos, garantir recursos humanos de qua lidade adequada em
ambas as unidades e estabelecer um sistema de gerenciamento para garantir que
cada un idade execute o p lano de acordo com suas responsabi lidades.
• Estabelecer um sistema de governança e gerenciamento para o Tokio Marine
Group - A Tokio Marine Holdings define o sistema de governança e gerencia-
mento como ele foi implementado nas empresas do grupo. Abrange cinco domí-
nios e consiste em t rês principa is componentes: o estabelecimento da estrutura
organizacional, o estabelecimento de políticas e padrões e a execução do Ciclo de
Deming (ciclo PDCA) para melhorias. O sistema de governança e gerenciamento
necessário para as empresas do Tokio Marine Group é detalhado nas Nonnas de
Governança de T I do Grupo.
• Estabelecer normas de governança de TI (a definição dos processos prioritários da
Tokio Marine) - a Tokio Marine Hold ings decid iu utilizar o COBIT 4.1 para defi-
nir o sistema de gerencia1nento. Entretanto, a organização reconhece que é d ifícil
Capítu lo 7 Apoio por parte da gerência 387
TABELA 7-2 Sete princípios orientadores

Nº Princípios orientadores Área de foco
1 Estabelecer um plano estratégico de TI que permita que a gerência alcance Alinhamento estratégioo
seu plano estratégico de negócios, construa os processos de negócios para
tal, e desenvolva um plano de execução
2 Ao executar o plano, garantir que a unidade de TI e as unidades encarrega- Alinhamento estratégico
das pelo aplicativo cooperem uma com a outra com funções adequadas de
verificação e equilíbrio
3 No desenvolvimento ou implementação de sistemas de infonnação, garantir Entrega de valor
que a gerência inspecione minuciosamente a validade do plano de projeto
do ponto de vista da garantia da qualidade, usabilidade, compromisso com a
data de entrada do serviço, estimação de custo adequada e correspondência
à disponibilidade de recursos humanos
4 Garantir que os sistemas de informação sejam integralmente utilizados por Entrega de valor
todos os funcionários da empresa, a fim de alcançar os objetivos para o de-
senvolvimento ou implementação dos sistemas de informação
5 Conduzir um gerenciamento de recursos de TI adequado, incluindo o ge- Gerenciamento de recursos
renciamento de capacidade oomputacional e o gerenciamento de recursos
humanos
6 Conduzir um gerenciamento adequado de riscos e da segurança das in- Gestão de riscos
formações, e estabelecer planos de oontingência para falhas no sistema
em consideração do acúmulo de vários fatores de risco em TI, oomo a alta
dependência que os processos de negócios têm da TI, a centralização de
informações importantes e ameaças devido a um uso mais amplo da internet
7 Encorajar a transparência das operações de TI a serem melhoradas, e moni- Gerenciamento de
torar seu progresso, o que inclui, por exemplo, o progresso de projetos, o uso desempenho
de recursos de TI e a utilização de sistemas de informação
para empresas relativamente pequenas do grupo implementar processos a 1nadure-

cidos pa ra todos os processos do COBIT 4.1. Para lidar com essa preocupação, a
organização se focalizou no conj unto e p rocessos míni1nos ou em contr oles mais
deta lhados sobre os objetivos, que são essenciais para seu negócio em termos de
governança de TI e os controles mais importantes pa ra o Tokio Marine G roup.
Nas Normas de Govemança de TI, a Tokio Marine Hold ings definiu os contro-
les de T I descritos na Figura 7- 5 como prio ridades para o To ki o Ma rine G ro up . Os
controles de TI prio ritários são defi nidos como cinco domínios, 14 processos e 39
objetivos de contro le, que são processos selecionados dos 21 Oobjetivos de controle do
COBIT 4.1. Ver Tabela 7- 3.
As empresas do grupo têtn de aprimo ra r os controles de prioridade para a lcança r
um nível de maturidade 3, segundo o Modelo de Maturidade do COBIT, e relata r o
progresso das mel horias da Tokio M ari ne Holdings .
Rumo ao futuro
Desde o esta beleci1nento do siste1na de governança de T I do To kio Marine Group, a
Tokio M ari ne Holdings tem se comunicado extensamente não somente com os CIOs,
mas também com os CEOs e gerência executiva das empresas do grupo pa ra garantir
que eles compreendam, concordem e assumam a lidera nça da implementação da go-
vemança de TI.
Por meio dessas atividades, a orga nização tem certeza de que o conceito cent ral
da govema nça de TI tenha passado a ser mais bem compreendida pela gerência e que
se esteja fazendo um bom progresso em decorrência da implementação do Siste1na
Controles do COBIT 4.1
Controles Prioritários do
Grupo (14 processos.
39 OCs)
(34 Processos, 21 0 OCs)
Figura 7- 5 Controles prioritários do Tokio Marine Group.
TABELA 7-3 Controles prioritários do Tokio Marine Group

Nome do domínio ld Nome do processo
a. Planejamento e organização a1 Planejamento anual de TI
a2 Definições de papéis e responsabilidades da unidade de TI e
das unidades de encarregados pelos aplicati\/Os
a3 Estabelecimento de um comitê de direção de TI
b. Gestão de projetos b1 Gerenciamento de desenvohlimento e projetos de implementação
c. Gerenciamento de mudanças c1 Controle de mudanças
d. Gerenciamento de operações d1 Gerenciamento de incidentes/problemas
d2 Gerenciamento de forneeedores
d3 Gerenciamento de segurança
d4 Gerenciamento de ativos de TI
dS Gerenciamento de capacidade computacional
d6 Recuperação de desastres e backup/restauração
e. Monitoramento do e1 Revisão anual de TI
desempenho e retorno e2 Monitoramento do comitê de direção de TI
sobre o investimento e3 Monitoramento da gestão de projetos, do gerenciamento de
mudanças e do gerenciamento da operação de sistemas
de Enca rregados pelos Aplicativos nas empresas do grupo. A Tokio Marine Holdings
continuará sua missão de "catequisar" as empresas do grupo, realizando o benefício
do negócio do grupo e agregando valor pa ra as partes interessadas.
Yu ichi (Rich) lnaba, CISA

É um consultor sênior especialista na área de governança de TI, gestão de riscos
de TI e segurança de informações de TI na Tokio Marine and N ichido Systems Co.
Ltd. (TMNS), uma e1npresa do Tokio Marine Group. Antes de ser transferido pa ra a
TMNS, ele tinha tra balhado no Departamento de Planejamento de TI da Tokio Ma ri-
ne Hold ings Inc. e tinha se envolvido no estabelecimento da estr utura de governança
de TI do Tokio M ar ine Group baseado em COBIT 4 .1. Sua responsabilidade atual é
implementa r e praticar a governança de TI do Tokio Marine Group na TMNS. Inaba
é membro do Com itê de Normas da Divisão de Tóquio da !SACA e está at uahnente
envolvido na t radução das publicações do COBIT 5 pa ra o japonês.
Hiroyuki Shibuya
É o executivo enca rregado da IT na Tokio Marine Holdings Inc. De 2000 a 2005, ele
liderou o projeto de inovação do lado do T I, que reconstr uiu totalmente as linhas de
p rodutos de seguros, seus processos de negócios e os sistemas de info rmação da Tokio
Marine and Nichido Fire lnsurance Co. Ltd. A fim de promover sua experiência cotn
esse projeto, alétn de remediar outr os projetos problemáticos das em presas do grupo,
ele foi nomeado gerente geral do recém-estabelecido departamento de TI na Tokio
Marine Holdings em julho de 2010. Desde então, ele tem liderado os esforços para
estabelecer os padrões e políticas básicas de govemança de TI para forta lecer a gover-
nança de TI em todo o Tokio Mar ine Group.
7.8 Empoderamento dos gerentes de projetos

Utn dos 1naiores problemas cotn a designaç.ã o de pat rocinadores executivos para tra-
balhar lado a lado com gerentes de á rea e gerentes de projeto é a possibilidade de que
os gerentes de níveis mais ba ixos se sintam ameaçados com a perda de autori dade.
Esse problema é real e precisa ser a bordado no nível executivo. Frank Jackson, a ntigo
gerente sênior da MCI, acredita na ideia de que in formação é poder:
Fizemos uma a uditoria das equipes para ver se realmente estávamos tendo o progresso
que imaginamos ou se estávamos nos enganando, e tivemos um res ultado surpreendente.
Quando o lhamos a auditoria, descobrimos que 50o/o do tempo da gerência intermediária
era gasto fi ltrando informações para c ima e para baixo na hiera rquia da organização.
Quando t ínhamos um patrocinador, as informações iam da equipe para o patrocinador
e deste, para o com itê operacional, e isso criava uma verdadeira crise na área de nossa
gerência intermediária.
A lv!CI encontrou sua solução para esse pro blema. Se há a lguém q ue acredita que sim-
plesmente entrar no ambiente de abordagem de uma equipe é algo fácil, está completamen-
te enganado. lvlesmo nas empresas com as quais estou envolvido, é muito difícil para os
gerentes desistir das responsabilidades de a utoridade que eles tinham. Você simplesmente
precisa chegar lá, e temos um s istema com o qual nos comunicamos com a MCI, q ue é o
lv!CI mail. É um sistema de correio eletrônico. O que ele nos permitiu fazer como empresa é
contornar níveis de gerência. Às vezes, você fie.a atolado em comunicações, mas ela permite
que você se comunique com todos os níveis hierárquicos sem que ninguém fique retendo as
informações.
Os executivos têm a capacidade não somente de levar a gestão de projetos ao
sucesso, mas também de criar um a tnbiente que leve um projeto ao fracasso. Segundo
Robert Hershock, a ntigo vice-presidente da 3M:
A maioria das experiências que tive em que projetos fracassaram, isso aconteceu por intro-
metimento da gerência . Ou a gerência não estava 100% comprometida com o processo, ou
simplesmente atolava o processo com relatórios e d iversas o utras insinuações ma ldosas.
Os maiores fracassos que já presenciei foram realmente devido à gerência. Basicamente, há
duas experiências em q ue os projetos não conseguiram ser bem-sucedidos. Uma é o intro-
metimento da gerência quando esta não pode abrir mão de suas capacidades de tomada de
decisões, constantemente voltando à equipe e dizendo que eles estão fazendo isso ou aquilo
errado. O o utro lado da moeda é quando a eq uipe não consegue comunicar seu próprio
objetivo. Q uando não consegue se focalizar, o escopo se expande continuamente, e você
chega ao aumento grad ual de escopo. A equipe simplesmente perde o a utocontrole por ter
perdido o foco.
O fracasso de um projeto pode muitas vezes ser uma questão de percepções falhas.
A 1na ioria dos executivos acredita ter chegado ao topo de suas organizações sozinhos.
É muito difícil para eles muda r sem sentir que estão a brindo mão de u1na tremenda
quantidade de poder, que tradicionalmente é confiado ao nível mais alto da etnpresa.
Para 1nudar essa situação, o melhor pode ser começar pequeno. Cotno um executivo
observou:
Há muitas ocasiões em que os executivos sênior não vão ao treinamento e não escutam nin-
guém, mas acho q ue é fazendo que se aprende. Se você deseja incutir equipes de gestão de
projetos em suas organizações, comece pequeno. Se a empresa não permite fazê-lo usando a
teoria da N ike de ;'simplesmente fazer" a lgo, comece pequeno e prove a eles, passo a passo,
q ue eles podem alcançar o sucesso. Dê mérito à equipe por seus resultados - eles falam por
s1mesmos.
É itnportante também para nós lem brar que os executivos podem ter 1notivos vá-
lidos para fazer microgerenciamento. Um executivo cotnentou sobre por que a gestão
de projetos pode não estar funcionando como o planejado etn sua empresa:
Nós, os executivos, queremos empoderar os gerentes de projeto e eles, por sua vez, empo-
derariam seus membros de equi pe para tomar decisões relacionadas ao seu projeto o u área.
Infelizmente, não sinto que nós (os executivos) apoiamos totalmente a descentralização da
tomada de decisões devido a preocupações políticas que derivam da falta de confiança que
temos em nossos gerentes de projetos, q ue não são proativos e q ue não demonstram capa-
cidade de liderança.
Na maioria das organ izações, os gerentes sên ior começam em um ponto em que
confiam apenas etn seus colegas também gerentes. À medida que o sistetna de gestão
de projetos melhora e uma cultura de gestão de projetos se desenvolve, os gerentes sê-
nior passam a confiar nos gerentes de projeto, em bora eles não ocupem posições altas
na organizaç.ã o. O empoderamento não acontece da noite pa ra o d ia. Ele leva tempo
e, infelizmente, muitas empresas nunca chegam ao total empoderamento dos gerentes
de projetos.
7.9 Apoio por parte da gerência na prática

Um apoio executivo visível é necessá rio para a gestão de projetos bem-sucedida e a
estabil idade de uma cultura de gestão de projetos. No entanto, pode ocorrer uma visi-
bilidade excessiva para os gerentes sênior. Veja o exemplo do caso a seguir.
Midline Bank
O Mid line Bank (nome fictício) é um banco de médio porte que atua em uma gr ande
cidade do noroeste dos EUA. Os seus executivos perceberam que o crescimento da in-
dústria bancária no futuro próximo dependeria de fusões e aquisições, e que o Midline
precisaria assu1nir uma posição agressiva para se manter competitivo. Financeiramen-
te, o Midline estava betn preparado para adqui rir outr os bancos de pequeno e médio
porte para aumentar sua organização.
O grupo de tecnologia da informação do banco fo i encarregado de desenvolver
utn pacote de software extenso e sofisticado a ser usado na ava liação da saúde dos
bancos-alvo da aqu isição. O pacote de software exigia informações de praticamente
todas as divisões funcionais do Midl ine. Esperava-se que coordenação do projeto fosse
ser difíci l.
A cultura do Midl ine era dominada por grandes itnpérios funcionais rodeados por
paredes impenetráveis. O projeto do software foi o pri tneiro da história do banco a
exigir cooperação e integração ent re os grupos funciona is. Um gerente de projeto em
tempo integral foi designado a di rigir o projeto.
Infel izmente, os executivos, gerentes e funcionários do Mid line sabiam 1nuito pou-
co dos princípios de gestão de projetos. No entanto, os executivos reconheciam a
necessidade do patrocínio executivo. Um comitê de di reção de cinco executivos foi
designado para oferecer suporte e orientação ao gerente de projetos, mas nenhu1n dos
cinco co1npreendia a gestão de projetos. Consequentemente, o co1n itê de direção inter-
pretou seu papel como uma direção diária contínua do projeto.
Cada um dos cinco patrocinadores executivos pediu que o gerente de projeto fi-
zesse briefings semanais pessoais, e cada pat rocinador to1nava decisões conflitantes.
Cada executivo tinha seus próprios objetivos para o projeto.
No final do segundo mês do projeto, o caos tinha tomado conta da situação. O ge-
rente de projetos passava a maior parte de seu tempo preparando relatórios de status
em vez de gerenciando o projeto. Os executivos mudavam os requisitos do projeto
frequentemente, e a organização não possuía nenhum processo de controle de mudan-
ças além da aprovação pelo comi tê de direção.
No final do quarto mês, o gerente de projetos renunciou ao seu cargo e procurou
emprego fora da empresa. Um dos executivos do comitê de direção, então, assumiu o
papel do gerente de projetos, mas só em regÍlne de meio expediente. Finalmente, o pro-
jeto foi assumido por outros dois gerentes de projetos antes de sua conclusão, um ano
mais tarde do que o p lanejado. A empresa aprendeu uma lição vital: 1na is patrocínio
não é necessaria1nente melhor do que menos.
Contractco
U1n outro caso com nome fictício envolve uma empresa sediada em Kentucky, que
chamarei de Contractco. A Contractco está no negócio de testes de fusão nuclear. A
empresa estava no processo de licitação em um contrato nos EUA.
O Departamento de Energia dos EUA exigiu que o gerente de projetos fosse iden-
tificado como parte da proposta da e1npresa e que fosse incluída uma lista de suas
tarefas e responsabil idades. Para impressionar o Departamento de Energia, a e1npresa
designou tanto o vice-presidente executivo quanto o vice-presidente de engenharia
como copatrocinadores.
O DoE questionou a ideia de patrocín io dual. Ficou claro para o departamen-
to que a empresa não compreendia o conceito de patrocínio de projetos, porque os
papéis e responsabilidades dos dois patrocinadores pareciam se superpor. O depar-
tamento ta1nbém questionou a necessidade de ter o vice-presidente executivo como
pat rocinador.
O contrato foi finalmente concedido a uma outra empresa. A Contractco apren-
deu que uma empresa nunca deve subestimar o conhecimento que o cliente possui
sobre gestão de projetos ou de patrocínio de projetos.
Health Care Associates

A Hea lth Care Associares (outr o non1e fictício ) presta serviços de gerencian1ento
de saúde para en1presas de grande e pequeno po rte na Nova Inglaterra, EUA. A
empresa tem parcerias com uma cadeia de 23 hospitais na região. Mais de 600 mé-
dicos fazem pa rte da equipe p rofiss ional, e muitos dos n1édicos atendem tan1bém
nas fi lia is da en1presa. Os gerentes-n1édicos possuem tambén1 seus consultórios
particulares.
Foi a prática da empresa de usar propostas clichês preparadas pelo departa1nento
de marketing para solicitar novos negócios. Se um cl iente estivesse seriamente interes-
sado nos serviços da Hea lth Care Associares, uma proposta persona lizada baseada nas
necessidades do cliente seria preparada. T ipica1nente, o processo de persona lização
levava no máximo seis meses ou até mes1no um ano inteiro.
A Health Care Associares queria acelerar o processo de propostas personalizadas

e decidiu adotar processos de gestão de p ro jetos pa ra a lcança r esse objetivo. Em janei-
ro de 1994, a em presa decidiu que poderia dar um passo à frente de sua concorrência
se designasse um gerente-médico como o patroci nador de projeto de e.ada nova pro-
posta . O raciocínio era que os cl ientes ficariam favoravelmente impressio nados.
O projeto pi loto dessa abordage1n fo i a Sinco Energy (outro no1n e fictício), uma
e1n presa sediada em Boston, EUA, co1n 8.600 funcioná rios trabalhando em 12 ci dades
da Nova Inglaterra . A Health Ca re Associates prometeu à Sinco que o pacote de saúde
estar ia pro nto para implementação no máximo em junho de 1994.
O projeto tinha sido concl uído com quase 60 dias de at raso e substa nciahn ente
acima do orçamento. Os gerentes sênio r da Health Care Associares entrevistou se-
pa rada mente cada um dos funcioná rios do projeto Sinco para identificar a causa do
fracasso do projeto. Os funcioná rios tiveram as seguintes observações:
• Embora os médicos tivessem recebido trei na mento e1n gerenciamento, tinham
muita dificuldade e1n aplicar os pri ncípios da gestão de projetos. Consequente-
mente, termina ram desempenhando o papel de patr ocinador invisível em vez de
participar ativa1n ente do projeto.
• Como se t ratavam de médicos praticantes, os 1n éd icos-patrocinadores não se com-
prometia m totahnente com seu papel como patroci nadores de projeto.
• Sem um force patrocínio, não havia processo eficiente em vigor para controla r o
au1n ento gradua l de escopo.
• Os 1n édicos não tinham autoridade sobre os gerentes de área, que forneciam os
recursos necessá rios para concluir um projeto com sucesso.
Os gerentes sênior da Health Care Associares aprenderam duas lições. Pri1nei ro,
nem todo gerente é q ualificado para agir como patrocinador de pro jeto . Segundo, os
patr ocinadores de projeto devem ser designados de acordo com sua habilidade de ge-
renciar o projeto ao sucesso. Impressionar o cliente não é tudo.
maxlT-VCS
Há vários níveis de s upo rte da gerência no que diz respeito a metodologias de gestão de
projetos [na maxIT-VCSJ. Inicialmente, a gerência pode não a precia r o valor até q ue um G P
identifiq ue os deliverables, acompanhe o progresso, forneça relatórios de status em tempo
real, identifiq ue q uestões e riscos e faça a lguém s upervisionar ativamente o projeto e manter
seu ntmo.
O suporte da gestão de p rojetos pela gerência em nossa ind ústria está crescendo à me-
d ida que o papel de um gerente de projetos está se tornando ma is importa nte para q ue se
atendam as necessidades de projetos complexos, mas os gerentes a inda precisam a braçar e
empoderar o s GPs. Há momentos em que o GP não é cons ultado q uando ocorrem mudan-
ças (alocação de recursos como um exemplo) ou, em alguns casos, não é apoiado como a
pessoa encarregada da iniciativa. Obvia mente a cultura e a po lítica desempenham um fator
em cada indústria, mas para que a saúde a tenda às demandas da indústria, a gerência deve
continuar a investir e a apoiar o crescimento de seus GPs.
Na VCS, toda a equipe de liderança (inclusive nossos altos d iretores executivos, o cha-
mado C-suite) oferece muito apoio e está d iretamente envolvida em ajuda r a expandir o
PMO. O PMO funciona como o " hu b" central para oferecer à nossa base de clientes um ser-
viço de consultoria completo. Isso inclui a capacidade de dirig ir uma iniciativa complexa de
TI de saúde com um gerente de projetos especializado tanto em operações quanto no lado
técnico da casa, junta mente com uma metodologia e processos publicados a serem seguidos.
Para a VCS, esse é um grande d iferenciador de mercado e oferece aos nossos clientes um
grande valor em comparação à nossa concorrência . (Marc H irsh field, d iretor, escritório de
gestão de projetos, maxIT-VCS)
Após a integração das duas empresas sob uma terceira, o PMO contin uará sendo um
grupo de gerentes de projeto experientes (e, em sua grande maioria, certificados). Esse com
esse grupo de GPs q ue podemos co ntar para gerencia r projetos de saúde complexos. Esse
centro contribui também para a manutenção e treina mento da metodologia de gestão de
pro1etos.
Atualmente somos um Centro Registrado de Treinamento (Registered Ed11catio11 Pro-
vider) junto à PNU.
Planejamos desenvolver novos treinamentos internos para todos os níveis de gerentes
de projetos, a lém de certificação interna para q ue se alcancem determinadas habilidades em
gestão de projetos (Heidi \Xlurtz, VP, Centro de Soluções, maxJT-VCS).
lndra
A gerência executiva [da lndra] é extremamente motivada para apoiar o desenvolvimen-
to da gestão de projetos dentro da empresa. Eles insistem com regularidade em melhorar
nossos programas de treinamento a lém de em se focalizar na necessidade de q ue métodos
melhores de gestão de projetos sejam colocados em vigor.
Às vezes, o sucesso de um projeto constitui um passo significativo no desenvolvimento
de uma nova tecnologia, no lançamento em um novo mercado, o u para o estabelecimento
de uma nova parceria e, nesses casos, a direto ria gerencial norma lmente desempenha um pa-
pel espe.c ia lmente ativo como patrocinadoras durante a execução do projeto o u programa .
Eles participam com o cliente de comitês de dire.ç ão para o projeto o u programa e ajudam
na tomada de decisões ou nos processos de gestão de riscos.
Por um motivo similar, devido à importância de um projeto específico, mas de um ní-
vel mais baixo, não é incomum ver a gerência intermediária observa r cuidadosamente sua
execução e fornecer, por exemplo, suporte extra para negociar com o cliente a resolução de
determinado problema .
Conseguir o apoio da gerência intermed iária foi algo alcançado usando o mesmo con-
junto de ferramentas corporativas para a gestão de projetos em todos os níveis e para todos
os tipos de projetos da empresa. Nenh um projeto é reconhecido se não estiver no sistema
corporativo e, para fazer isso, os gerentes de áreas devem seguir as mesmas regras e mé-
todos básicos, independentemente de se tratar de um esfo rço recorrente, não recorrente,
ou outro tipo de projeto. Uma estrutura ana lítica do projeto (EAP) bem desenvolvida, um
cronograma totalmente previsto, um plano de gestão de riscos e um conjunto persona lizado
de métodos com valor agregado, podem ser aplicados a qualquer tipo de projeto. (Enriq ue
Sevilla Molina, PMP" , antigo diretor do PN!O Corporativo da Indra).
7.10 Obtendo o apoio da gerência de área

O apoio da gerência não se restringe exclusivamente à alta gerência, como a seção a n-
terior most rou. O apoio da gerência de área é igualmente essencial para que a gestão
de projetos funcione eficientemente. Os gerentes de área nonnahnente apresentatn
mais resistência à gestão de projetos e muitas vezes exigem provas de que a gestão
de projetos fornece realmente va lor para a organização antes de apoiarem o novo
processo. Esse p ro blema foi identificado a nteriormente na jornada rumo à excelência
em gestão de projetos. Ele surgi u, também, na Motorola. Segundo u1n porta-voz da
Motorola:2
(Conseguir o apoio da gerência de área) foi difícil no princípio. Foram anos e mais anos em
que os GPs ofereciam valor para a organ ização.
2
H. Kerz.ner, Project Nfanagement Best Prac.tices: Acl,ievi11g Global Excellence, \Viley, 2006, p. 307.
Quando as organ izações se tornam maduras em gestão de p rojetos, o patrocí-

nio nos níveis executivos e nos níveis da gerência intermediá ria torna-se n1ínimo e
formam-se equ ipes de p rojetos integradas, en1 que a equipe integrada ou centra l é
en1poderada para gerenciar o projeto con1 um patr ocín io mínimo, envolvido apenas
en1 decisões críticas. Essas equipes integradas ou centra is podem ou não incluir a
gerência de á rea. O conceito de equ ipes centra is tornou-se uma n1elho r prática na
3
Motorola:
A maior parte da autoridade e das decisões de projeto se encontra nas mãos da equipe
central do projeto. A equipe central é formada por gerentes de nível intermediário para bai-
xo, provenientes de de d iferentes áreas funcionais (marketing, software, elétrica, mecânica,
produção, teste de sistemas, q ualidade, etc.) e possui a responsabilidade de ser encarregada
pelo projeto. Essa equ ipe central é responsável por revisar e aprovar requisitos de prod utos
e comprometer recursos e datas do cronograma. Age também como o conselho de controle
de mudanças do projeto e pode aprovar o u rejeitar solicitações de mudança de escopo. En-
tretanto, qualquer mudança de datas na aceitação de entrega de cargas precisa ser aprovada
pela gerência .
7.11 DTE Energy

Jason Schulist, gerente de melhorias contínuas, grupo de est ratégia de sistemas opera-
ciona is da DTE Energy, comenta sobre o patrocín io de projetos:
Os defensores convictos de projetos de melhorias contínuas que usam a metodologia dos
Q uatro Pontos de decisão/Nove Passos [já discutida no Capítulo 4] são primordia lmente os
vice-presidentes e diretores da DTE Energy. Esses defensores convictos precisam dar uma
assinatura em cada ponto de decisão para aprovar os resultados do processo. Em a lgumas
unidades de negócios, um Faixa Preta Mestre também precisa deixar s ua assinatura em
cada ponto de decisão para garantir que se sigam uma análise rigorosa e a metodologia do
Sistema Operacional da DTE Energr.
A importância dessa declaração é que a gerência sênior deveria ser a defensora
convira da metodologia além de se tornar defensora convicta do projeto. Em um for-
necedor automotivo, a gerência sénior empreendeu o papel de defensora convicta para
o desenvolvimento de uma metodologia de gestão de projetos. Depois de a metodo-
logia ter sido desenvolvida, o executivo assum iu um diferente papel na e1npresa. Três
anos mais tarde, a empresa percebeu que não havia esforços de mel horias contínuas da
metodologia porque não havia nenhu1n executivo que fosse um defensor convicto. O
executivo, então, voltou a defender a metodologia e ocorreram esforços de melhorias
contínuas.
7.12 Defensores convictos da iniciação

e do encerramento
À medida que a gestão de projetos evoluiu, evoluiu tan1bém o papel do executivo na
gestão de projetos. Hoje, há três papéis desen1pen hados pelo executivo:
• O patrocinador de projeto
• O defensor convicto do projeto (in iciaç.ã o)
• O defensor convicto do encerramento do projeto
' lbid., p. 308 .

O papel do executivo na gestão de projetos como um patrocinador de projeto se

tornou razoavelmente 1nadu ro. A maioria dos livros didáticos sobre o assunto pos-
sui seções dedicadas ao papel do pat rocinador de projeto.' O papel do defensor con-
victo do projeto, no enta nto, está apenas em p rocesso de amadurecimento. Stephen
Markham define o papel do defensor convicto:
Os defensores convictos são líderes informais q ue surgem de uma forma um tanto impre-
visível. Ser um defensor convicto é um ato voluntário realizado por um indiv íduo para
promover determ inado projeto. Nesse ato, os indivíd uos raramente se referem a si mesmos
como defensores convictos; em vez disso, descrevem-se como alguém q ue está tenta ndo
fazer a coisa certa pela empresa certa. Um defensor convicto raramente toma uma decisão
de defender um projeto. Em vez disso, ele come.ça de maneira simples e desenvolve um cres-
cente entusiasmo pelo projeto. Um defensor convicto torna-se intensamente entusiasmado
quanto a um projeto e, em última análise, envolve os outros devido à s ua convicção pessoal
de que o projeto é a coisa certa para toda a organização. O defensor convicto afeta o modo
como outras pessoas pensam a respeito do projeto, espalha ndo informações positivas pela
organização. Sem poder ou responsabilidade oficia l, um defensor convicto contribui para o
desenvolvimento de novos produtos, fazendo os projetos irem adiante. As.sim, os defensores
convictos são líderes informa is que (1) "adotam " projetos como se fossem deles próprios,
de maneira pessoa l, (2) assumem riscos promovendo os p rojetos a lém do que é esperado
de pessoas em sua posição e (3) promo,,em o projeto fazendo o utros ind ivíduos apoiá-lo.'
No que diz respeito aos projetos de desenvolvimento de novos produtos (DNP),
são necessários defensores convictos para superar os obstáculos do "vale da morte",
6
como vemos na Figur a 7-6. O vale da morte é a área no DNP o nde o reconheci1nento
da ideia/invenção e esforços para comercializar o produto se reúnem. Nessa á rea, bons
projetos geralmente ficam de lado e projetos com menos valor geralmente são adicio-
7
nados ao portfólio de projetos. Segundo Markham,
Há muitos motivos para a existência do Vale da Morte. O pessoal técnico (lado esq uerdo
da Figura 7..f,J geralmente não compreende as preocupações do pessoal da comercialização
(lado direito) e vice-versa. O fosso cultura l entre esses dois tipos de pessoal se manifesta nos
resultados p rezados por um lado e desvalorizados por outro. Networkin.g e gerenciamento
de contatos pode ser importante para o pessoal de vendas, mas é visto como superficia l e
como autoengrande.cimento pelo pessoal técnico. O pessoa l técn ico valo riza a descoberta e
o a la rgamento das fronteiras do conhecimento. O pessoal da comercialização precisa de um
produto q ue vá vender no mercado e muitas vezes considera o valor da descoberta como
meramente teórico e, portanto, inútil. Tanto o pessoal técnico quanto o da comercialização
precisa traduzir as descobertas de pesquisas em ofertas de produtos superiores.
Como vi mos na Figura 7-6, o va le da morte parece se origina r em algum luga r
próximo do f11zzy front end (FFE).
[FFE é] o confuso período do ;' início" do desenvolvimento de prod utos, que vem antes do
processo formal e bem estruturado de desenvolv imento de produto, q uando o conceito
do produto a inda é muito confuso (/utty). Geralmente, consiste nas três primeiras tarefas
(planejamento estratégico, geração de conceito e, especia lmente, avaliação p ré-técnica) do
processo de desenvolvimento de p roduto. Essas atividades geralmente são caóticas, impre-
4
H. Kerzner, Projec.t Management: A Sy$tems Approach to Planning_, Scheduling and Controlli11g1 11 th ed.,
Hoboken, NJ: \Viley, 2013, Chaprer 10 . Além disso, H. Kerzner and F. Saladis, \Vhat Executives Need to
Know Abo11t Project Ma11ageme11t, Hoboken, NJ: \Viley and New York: lll, 2009.
' S. K. /vl arkham, " Producr Champions: Crossing rl,e Valley of Dea rh" , in P. Belliveau, A. Griffin, and S. So-
mermeyer (Eds.), T/,e PDMA Toolbook for New Prod11ct Deve/opmellt, Hoboken, NJ: \Viley, 2002, p. 119.
• lbid., p. 120 .
7
lbid., p. 120 .
R
e
e
u
j Vale da morte
r
s
Recursos
existentes ~
Recursos
o de pesquisa
s (técnicos e existentes de
de mercado) comercialização
Ideia Pesquisa Fuzzy front end Desenvolvimento de produto Comercialização

Nível de desenvolvimento
Figura 7-6 Vale da morte.
visíveis e não estruturadas. Em comparação, o processo d o desenvolvimento de um novo

produto é tipicamente estruturado e formal, com um conjunto prescrito de atividades, per-
guntas a serem respond idas e decisões a serem tomadas.•
Os defensores convictos de projetos normalmente não são nem os gerentes de pro-
jetos nem os patrocinadores de projeto. O papel do defensor convicto é vender a ideia
ou conceito até que ela finahnente se tome um projeto. O defensor convicto pode nem
mesmo compreender a gestão de projetos e pode não ter as habilidades necessárias
para gerencia r u1n projeto. Os defensores convictos pode1n se encontrar 1nuito 1na is
a lto na hierarquia o rganizaciona l do que o gerente de projetos.
Permitir que o defensor convicto de um projeto atue como o patrocinador do pro-
jeto pode ser tão ruÍln quanto permitir que ele atue como o gerente de projetos. Quan-
do o defensor convicto do projeto e o patrocinador de projeto são a mesma pessoa, os
projetos nunca são cancelados. Há uma tendência a prolongar a dor de continuar com
u1n projeto que deveria ter sido cancelado.
Alguns projetos, especiahnente projetos de muito longo prazo em que o defensor é
ativamente envolvido, gerahnente determinam que haja uma crença coletiva. A crença
coletiva é um desejo fervoroso, e talvez cego, de alcançar o sucesso, que pode permear
toda a equipe, o pat rocinador de projeto e até mesmo os níveis ma is altos da gerência.
A crença coletiva pode fazer u1na organização racional agir de maneira irracional.
Isso é particularmente verdadeiro se o patrocinador de projeto estiver na d ianteira da
crença coletiva.
Quando existe uma crença coletiva, as pessoas são selecionadas de acordo com
seu apoio a ela . Os defensores podem evitar que funcionários ta lentosos tr aba lhem
no projeto a menos que tenham a 1nesma crença fervorosa que o defensor convicto.
' r. Belliveau, A. Griffin, and S. Somenneyer, T/,e PDMA Toolbook for New Product Development, Ho-
boken, NJ: Wiley, 2002, p. 444.
Pessoas que não têm essa crença são pressionadas a apoiar a cren'ia coletiva e os
membros de equipe não são autorizados a questionar os resultados. A 1nedida que a
crença coletiva cresce, tanto os defensores quanto os não defensores são estnagados. A
pressão da crença coletiva pode superar a real idade dos resultados.
A crença coletiva possui várias características, motivo pelo qua l a lguns projetos de
alta tecnologia de grande porte geralmente são difíceis de extinguir:
• Incapacidade de ou recusa a reconhecer o fracasso
• Recusar-se a ver os sinais de alerta
• Enxergar apenas o que se quer enxergar
• Temor de expor erros
• Ver más notícias como um fracasso pessoal
• Ver o fracasso como um sinal de fraqueza
• Ver o fracasso como algo que causa danos à carreira
• Ver o fracasso como algo que causa danos à reputação
Os patrocinadores de projetos e os defensores convictos fazetn todo o possível
para tornar seu projeto bem-suced ido. Mas e se o defensor convicto do projeto, alétn
da equipe de projeto e do patrocinador, tiverem uma fé cega no sucesso do projeto? O
que acontece se as fortes convicções e a crença coletiva desconsiderarem os sina is de
alerta que indicam perigo iminente? O que acontece se a crença coletiva tornar inau-
díveis as divergências?
Nesses casos, há que se designar um defensor de encerramento. O defensor de
encerramento às vezes precisa ter envolvimento direto no projeto a fim de ter credi-
bilidade, mas o envolvimento direto nem sempre é uma necessidade. O defensor de
encerramento precisa estar disposto a colocar sua reputação em jogo e, possivehnente,
enfrentar a possibilidade de ser expulso da equipe de projeto. Segundo Isabelle Royer:'
Às vezes é preciso um ind ivíduo, em vez de crescentes ev idências, para sacudir a crença
coletiva de uma equ ipe de projeto. Se o problema com o entusiasmo desenfreado começar
como uma consequência não intencional do trabalho legítimo do defensor convicto de um
projeto, então o que pode ser necessário é uma força na direção oposta - um defensor
de encerramento. Essas pessoas são mais do que meros advogados do diabo. Em vez de
simplesmente levantar questões sobre um projeto, elas buscam evidências objetivas de que
problemas, de fato, existem. Isso permite que elas desafiem - ou, dada a ambiguidade dos
dados existentes, concebivelmente até mesmo confirmem - a viabil idade de um projeto.
Elas, então, agem com base em dados.
Quanto maior o projeto e 1na ior o risco financeiro para a etnpresa, mais a lto na
hierarquia deve se encontrar o defensor de encerra tnento. Se o defensor do projeto
por acaso for o CEO, então alguém do conselhor diretor ou mestno todo o conselho
diretor deve assumir o papel de defensor de encerramento. Infeliztnente, há situações
em que a crença coletiva permeia todo o conselho diretor. Nesse caso, a crença coletiva
pode forçar o conselho diretor a se esquivar de sua responsabi lidade de supervisão.
Projetos de grande porte incorrem em grandes custos excedentes e atrasos no cro-
nogra tna. Tomar a decisão de cancelar tal projeto, uma vez que ele tenha sido iniciado,
10
é muito difícil, segundo David Davis :
• 1. Royer, "Why Bad Projects are So Hard to Kill'", Harvard Busi11ess Revie,v, February 2003, p. 11.
Copyright O 2003 by rhe Harvard Business School Publishing Corporarion. Todos os direitos reservados.
10
D. Davis, "New Projects: Beware of False Economics··. Harvard Business Review, .March- April 1985, p.
100-10 1. Copyright O 1985 by rhe Presidenc and Fellows of Harvard College. Todos os direitos reservados.
A dificuldade de abandonar um projeto depois de vários milhões de dólares terem sido com-
prometidos tende a ev itar uma revisão e um recusteio objetivos. Por esse motivo, idealmente
uma equipe de gerenciamento independente - q ue não esteja envolvida no desenvolvimento
dos projetos - deve realizar o re.custe.io e, se possível, toda a revisão ... Se os números não
corresponderem na revisão e no recusteio, a empresa deve abandonar o projeto. O número
de projetos ruins que chegam à fase operaciona l serve como prova de que seus defensores
geralmente relutam em tomar essa decisão .
. . . Os gerentes sênior pre.cisam criar um ambiente que re.compense a honestidade e a co-
ragem e promova maior tomada de decisões por parte dos gerentes de projetos. As empresas
precisam de uma atmosfera q ue encoraje o projeto a ser bem-sucedido, mas os executivos
têm de permitir q ue eles fracassem.
Quanto mais longo o projeto, 1naior a necessidade de o defensor de encerramen-
tos e os patrocinadores de projeto se certificarem de que o plano de negócios possui
"saídas", de modo que o projeto possa ser extinto antes de recursos maciços sejam
comprometidos e consum idos. Infel izmente, quando há u1na crença coletiva, essas
saídas são propositahnente omitidas do projeto e dos planos de negócios. Um outro
motivo para ter um defensor de encerramentos é para que o processo de encerramento
do projeto possa ocorrer o mais rápido possível. À medida que os projetos se aproxi-
mam de sua conclusão, os membros de equipe geralmente ficam apreensivos quanto à
sua at ribuição seguinte e tenta tn estender o projeto existente até estarem prontos para
deixá-lo. Nesse caso, o papel do defensor de encerramento é acelerar o processo de
encerramento sem causar nenhum impacto na integridade do projeto.
Algumas o rganizações usam 1nembros de um conselho de revisão de portfó lio
como defensores de encerramento. Esses conselhos têm a palavra fina l na seleção do
projeto. Eles tam bém têm a palavra fina l quanto a se o projeto será extinto ou não.
Normalmente, um membro do conselho funciona como defensor de encerramento e
faz a apresentaç.ã o fina l para o restante do conselho.
Treinamento e formação
8.0 Introdução
Estabelecer programas de creina1nento e1n gestão de projetos é u1n dos 1naiores de-
safios enfrentados pelos diretores de treinamento, pois a gestão de projetos envolve
inúmeras habilidades complexas e inter-relacionadas (qualitativa/comportamental,
organizacional e quantitativa). Nos primórdios, os gerentes de projetos aprendia1n
com seus próprios erros e1n vez de com a experiência dos out ros. Hoje, as empresas
excelentes em gestão de projetos estão oferecendo cursos corporativos na área. U1n
creina1nento eficiente serve de suporte à gestão de projetos co1no profissão.
Algumas grandes corporações oferecem mais cursos internos relacionados à ges-
tão de projetos do que a maioria das facu ldades e universidades. Essas etnpresas tra-
tam a formação de seus profissiona is quase como uma religião. Empresas menores têtn
progra1nas internos mais modestos e normalmente enviam seu pessoa l para progra1nas
de treina1nento oferecidos pelo governo.
Este capítu lo discute processos para identificar a necessidade de t reinamento, se-
lecionar os alunos que precisam de t reinamento, projetar e minist rar o treinamento e
medir o retomo do t reinamento sobre o valor investido.
8.1 Treinamento por uma gestão

de projetos moderna
Durante os pri1nórdios da gestão de projetos, no final da década de 1950 e durante
toda a década de 1960, os cursos de treinamento se concentravam nas vantagens e des-
vantagens de várias formas organizaciona is (p.ex.: 1natricial, tradicional, projetizada e
funcional). Os executivos aprendiam rapidamente, porém, que se podia fazer qua lquer
estrutura organ izaciona l funcionar eficiente e eficazmente quando a gestão de projetos
básica é aplicada. As habilidades da gestão de projetos baseadas em trabalho em equi-
pe, cooperação e comunicação podem solucionar a maioria dos problemas estruturais.
A partir da década de 1970, a ênfase se afastou das estruturas organizacionais da
gestão de projetos. Os antigos programas de treinamento foram substituídos por dois
progra1nas básicos:
• Planejamento
• Geração de cronograma
• Controle de custos
• Software
Pessoas a serem treinadas
Especialistas técnicos
Gerentes de área
Funcionários
• Conflitos
• Motivação
• liderança
• Formação de equipes
• Gerenciamento de tempo
Comportamental (qualitativa)
Figura 8-1 Tipos de treinamento em gestão de projetos. Fonte: Reimpresso de H. Kerzner,

ln Search oi Excellence in Project Management, Hoboken, NJ: Wiley, 1998, p. 174.
• Gestão de projetos básica, que ressalta assuntos comportamentais, como as 1núl-

tiplas relações dos relatórios, gerenciamento de tempo, liderança, resolução de
confl itos, negociações, formaç.ã o de equipes, motivação e áreas básicas de geren-
ciamento, como o planeja1nento e o cont role.
• Gestão de projetos avançada, que ressalta as técnicas de geração de cronogramas
e pacotes de software usados para planejar e controlar projetos.
Os programas de treinamento em gestão de projetos de hoje incluem cursos em
tópicos comportamentais além de quantitativos. O problema mais importantes enfren-
tado pelos gerentes de treinamento é como alcançar um equilíbrio viável entre as duas
pa rtes do curso - comportamental e quantitativa (ver Figura 8- 1). Para programas de
t reinamento patrocinados pelo governo, os líderes de seminários determinam seu pró-
prio nível de conforto na "zona discricionária" entre os tópicos técnicos e comporta-
mentais. Para treina1nentos oferecidos dentro da própria empresa, poré1n, o equi líbrio
tem que ser preeestabelecido pelo d iretor de treinamento com base em fatores como
que alunos serão designados para gerenciar projetos, tipos de projetos e as durações
médias dos projetos (ver Tabela 8- 1).
8.2 A necessidade de uma formação em negócios

Na seção anterior, discutimos a importância de determinar o equi líbrio correto en-
t re habilidades quantitativas e habi lidades comportamentais. Esse equi líbrio hoje está
mudando devido ao modo como vemos o papel de um gerente de projetos. Hoje,
temos u1n novo tipo de gerente de projetos. Há a lguns anos, pratica1nente todos os
gerentes de projetos era1n engenheiros com d iplomas avançados. Essas pessoas tinham
u1n domínio tecnológico em vez de 1neramente alguns conhecitnentos em tecnologia.
Se o gerente de área acreditasse que o gerente de projetos de fato possuía do1nínio de
u1na tecnologia, ele pennitiria que os funcionários operacionais designados recebes-
TABELA 8-1 Ênfases em vários programas de treinamento
Ênfase do programa de treinamento

Tipo de pessoa designada para Habilidades Habilidades
o treinamento de GP (Fonte de GP) quantitativas/tecnológicas comportamentais
Treinamento necessário para funcionar como gerente de projetos
Especialista técnico em projetos de curto prazo Altas Baixas
Especialista técnico em projetos de longo prazo Altas Altas
Gerente de área que atua como gerente de projetos Altas Baixas
em tempo parcial
Gerente de área que atua como gerente de projetos Altas Médias a altas
em tempo integral
Funcionários experientes em operações cooperativas Altas Médias a altas
Funcionários inexperientes em operações cooperativas Altas Médias a altas
Treinamento necessário pa ra conhecimentos gerais
Qualquer funcionário ou gerente Médias Médias
Fonte: Reimpresso de H. Kerzner, ln Search of Excellence in Projeto Management, Hoboken, NJ: Wiley, 1998, p. 175.
sem ordens do gerente de projetos. O resultado era que se esperava que os gerentes de
projetos gerenciassem pessoas e fornecessem orientações técnicas.
A maioria dos gerentes de projetos hoje possui conhecimentos de tecnologia em
vez de u1n domín io. Consequentemente, a responsa bilidade pelo sucesso do projeto
agora é vista como compartilhada entre o gerente de projetos e todos os gerentes de
áreas afetadas. Com uma responsabilidade compartil hada, o gerente de área agora
precisa ter uma boa compreensão de gestão de projetos, que é o motivo pelo qual mais
gerentes de área hoje estão se tornando PMPs®. Hoje, espera-se que os gerentes de pro-
jetos gerenciem deliverables, não pessoas. O gerenciamento dos recursos designados é,
na maioria das vezes, função dos gerentes de área .
Um outro importante fato é que os gerentes de projetos são tratados como se
estivessem gerenciando parte de um negócio e1n vez de simplesmente um projeto, e,
portanto, se espera que eles to 1ne1n sólidas decisões de negócios além de decisões rela-
tivas a projetos. Os gerentes de projetos devem compreender os princípios de negócios.
No futuro, talvez se espere que os gerentes de projetos se tornem certificados exter-
namente pelo PMI®e internamente por sua empresa nos processos de negócios de sua
organ1zaçao. -
Agora, ao planejar cursos de treinamento, determ inamos o equ ilíbrio correto en-
tre habi lidades quantitativas, habilidades comportamenta is e habil idades de negócios.
Competências interpessoais e perspicácia empresarial são elementos cruciais para u1na
execução de projeto se1n fa lhas, diz Benny Nyberg, antigo vice-presidente assistente do
grupo, encarregado das Metodologias de GP e Desenvolvimento de Talentos na ABB:
Após implementar o Processo de GP na ABB como um processo comum de alto nível em
todas as organizações de vendas do projeto da empresa além de em várias organizações de
desenvolvimento de produtos, uma coisa ficou muito clara. Em uma empresa técn ica que
emprega um grande número de engenheiros extremamente qual ificados, alguns dos quais
são promovidos a gerentes de projetos, os as pectos técnicos da gestão de projetos como
planejamento, geração de cronogramas e controle de custos são, no mínimo, d ifíceis de
implementar. Funcionários iniciantes precisam de treinamento nes.sa área, mas o verdadeiro
desafio para alcançar a excelência operacional em gestão de projetos, uma execução de
projeto sem falhas, um resultado desejável para os projetos e um alto nível de satisfação do
cl iente está em identificar e desenvolver gerentes de projetos com o nível certo de perspicá-
c ia empresarial. A gestão de projetos é um cargo que exige habilidades comerciais, de co-
municação e de liderança. Um gerente de projetos precisa ter uma menta lidade empresarial,
ser capaz de se comunicar eficientemente com d iversas partes interessadas e de liderar e mo-
tivar pessoas. Para projetos de entrega, uma compreensão precisa do contrato, i.e., termos
e condições, escopo e q ua lquer promessa que seja feita é crucial para ser capaz de entregar
exatamente o que foi acordado, atender as expectativas do cliente e, assim, garantir a sua
satisfação e o sucesso do p rojeto. A compreensão do contrato é um outro requisito a inda
para maximizar o resultado financeiro e reconhecer as oportunidades de vendas adicionais
à medida que elas forem ocorrendo.
O papel de um gerente de projetos, especia lmente para grandes contratos q ue levam
muitos meses o u vários anos para serem concluídos, é muito próximo do papel de um
gerente de contas. As habilidades a seguir estão entre as mais importantes para o sucesso:
menta lidade empresaria l, comunicação, negociações, liderança, gestão de riscos, estratégia
de venda .
A fim de identificar e realizar treinamentos e o utras atividades de desenvolvimento ne-
cessárias para a ampla variedade de competências e habilidades, a ABB implementou um
modelo de competência. Ele inclui uma definição de competências necessárias, questioná-
rios de autoavaliação, questionários de entrevista ma is guias de desenvolvimento e por últi-
mo, mas não menos importante, vários módulos de treinamento selecionáveis que levam ao
nível apropriado de certificação.
8.3 SAP: importância de um plano de carreira

1
Na SAP Services, estabelecemos um claro plano de carrei ra de gestão de projetos para
q ualquer pessoa que apoiasse nossos projetos de entrega a clientes (ou projetos trans-
formaciona is internos). O pla no de carrei ra de gestão de projetos engloba desde car-
gos de nível de entr ada a GP associado, passando por vários níveis de gerentes de
projetos e chegando ao papel de gerente de programas ou executivo de ent rega. (Ver
Figur a 8-2 .)
Cada papel possui um perfil de habilidades claramente definido, incluindo a de-
fi nição precisa das habi lidades profissiona is necessárias e o nível de proficiência es-
perado para cada uma das ha bilidades exigidas pelo cargo. Cada perfil ta1n bém é
associado à categoria do projeto que se espera que a pessoa nesse nível de carreira
gerencie - as dimensões dessa atribuição incluem tama nho do projeto, comp lexidade,
exposição a riscos, receitas, etc.
Cada perfil é intin1amente ligado ao perfi l de cargo do RH e ao respectivo p la-
no de desenvolvin1ento pessoal que especifica claramente as aulas e t reinan1ento re-
con1endadas pa ra cada habi lidade que consta do perfil. Os trei na mentos oferecidos
para a prática de G P especifican1 papéis-alvo para o trei na mento e os objetivos de
t reinamento são associados a ha bilidades específicas a pa rtir do perfi l. O catálogo
de treinan1ento cobre uma a mpla var iedade de habilidades, das habi lidades centra is
de gestão de projetos baseadas en1 padrões como os fundan1entos de gestão de pro-
jetos do Guia PMBOK® do PMI; conhecimentos específicos da SAP (como o conhe-
cimento de soluções da SAP, a metodologia de imp lementação da SAP, entrega ágil,
ferra mentas de entrega e ferramentas internas de GP, etc.) a habilidades de liderança
. .
e 1nterpessoa1s.
1
©2013 by SAP. Todos os d ireitos reservados. Reproduzido com permissão. O material desta seção foi for·
necido por Jan Musil, líder global da prática de gestão de projetos, SAP Field Services, SAP America, lnc.
Associado Especialista Sênior Expert Expert chefe
Gerente de Gerente de programas/

GP associado Especialista em GP Gerente de projetos
projetos principal executivo de entrega
1
Os gerentes de 1 Os gerentes de
O GP Associado é Especialista em GP projetos são projetos principais Os gerentes de
um cargo júnior no é o cargo de entrada responsáveis por são responsáveis programas/executivos
plano de carreira no plano de carreira um gerenciamento pelo gerenciamento de entrega são
de gestão de de gestão de end-to-end end-to-end responsáveis pelo &'
projetos e é projetos. Pode de projetos de de projetos de gerenciamento "O
responsável por incluir papéis em categoria A e categoria Be end-to-end ~
desempenhar uma projetos como o projetos de projetos de de projetos o
co
função básica líder da equipe categoria B categoria C e programas de
no PMO de projetos com nível mais baixo com nível mais baixo categoria C e O ::;I
' de complexidade !!!.
1 de complexidade :,
~
(1)
:,
õ
(1)
õ
~
.,
3
Figura 8-2 Plano de carreira de gerente de projetos e gerente de programa. -g,
o
.I>,
o
w
Por meio de um plano de carreira estruturado, os gerentes de projetos ampliam

conhecimento, especial ização e experiência, o que lhes permite subir no plano de car-
reira de GP. O plano de carreira de GP está interconectado com outros perfis de cargos
na SAP, de 1nodo que os gerentes de projetos possam fazer escolhas de carreira que lhes
permita tn passar a diferentes planos de carreira, como gerência e vendas, ou permane-
cer na carreira de GP.
8.4 lnternational lnstitute for Learning

Considerando-se a importância da gestão de projetos hoje e no futuro, haverá uma
necessidade contínua de inst ruç.ã o nessa área . E. La Verne Johnson (fundador, presi-
dente e CEO do lnternational lnstitute for Learning) comenta sobre o crescimento do
t reinamento em gestão de projetos. (Para maiores informações sobre o IIL, visitar o
site w,vw. iil.com.)
Nos n1ais de vinte anos de história do IIL, traba lhan1os con1 mi lhares de orga-
nizações em todo o n1undo, planejando e minist rando treinamentos en1 gestão de
projetos, programas e portfólios. Temos clientes em todas as indústrias, e eles incluen1
grandes en1presas globais e organizações menores que estão tentando obter un1a van-
tagem con1petitiva por meio de programas eficientes. Con1 o IIL atendendo as neces-
sidades cotidianas de nossos clientes, além daquelas que estão começando a surgi r no
horizonte, temos ocupado un1a posição incompa rável para participar e observar o
crescimento da gestão de projetos como uma profissão p lena. Já estávan1os "na ativa"
quando a gestão de projetos passou de uma n1era área de interesse a um in1perativo
o rganizaciona l.
A partir de nossa perspectiva, cursos que eram suficiente há apenas alguns anos
hoje deixa1n a desejar - e esse é um verdadeiro sinal de progresso. O mercado global
e a crescente importância da gestão de projetos tem determinado o surgimento de
toda uma família de novos cursos, conteúdo enriquecidos e uma variedade flexível
de métodos de entrega que perm item que os alunos aprendam quando e onde eles
precisarem - e1n salas de aula presenciais ou virtuais, sozinhos em suas 1nesas em e.asa
ou no escritório, determinando seu próprio rit mo ou liderados por instrutores. Parece
que a aprendizagem e a tecnologia se reuniram para oferecer à profissão de gerente de
projetos ferra 1nentas ext remamente úteis para continuar constr uindo o futuro. O IIL
se orgulha de sua marca Many Methods of Lea rningT" (Mui tos Métodos de Aprendi-
zagem), que garante que a formação oferecida atenda a uma d iversidade de necessida-
des, esti los e interesses.
Anos de evolução: tendências da aprendizagem

Os cursos de t reinamento durante a década de 1980 eram, em sua maioria, dedicados
a apritnorar as habi lidades dos gerentes de projetos. O foco do t reinamento era no bá-
sico: a metodologia fundamenta l e os conhecimentos necessários para passar no exa-
me de Certificação de Profissiona l de Gerenciamento (PMP®) do PMI®. Em resposta, o
IIL lançou cursos de treinamento em fundamentos de gestão de projetos e estabeleceu
u1n programa de certificação abrangente que perm itia que os indivíduos se preparas-
sem e passassem co1n sucesso no exame de PMP® do PMI. Uma pequena variedade de
livros, cursos presenciais e produtos de so ftware foi dispon ibilizada para os indivíduos
responsáveis por gerenciar p rojetos em suas empresas.
Anos de revolução: tendências do mercado

Nos últimos anos, u1na variedade bem ma ior de empresas e indústrias reconheceu a
importância de se gerenciar projetos 1na is eficientemente e anal isar os modos co1no os
projetos cumprem metas corporativas gerais. Em comparação aos anos anteriores, está
se in iciando u1na revolução. Isso se tornou evidente em diversas tendências.
• O volume de projetos está aumentando à medida que ma is e mais empresas pas-
sam a ad1ninistrar suas empresas por meio de projetos. De fato, algumas organi -
zações líderes empreendetn centenas de milhares de projetos individuais todos os
anos - alguns pequenos e simples, out ros enormes e complexos.
• A habilidade de gerenciar projetos eficientemente passou a ser de crucial impor-
tância para os negócios, e boas habi lidades de gestão de projetos passaram a ser
uma vantagem competitiva para as empresas líderes.
• Em decorrência desse crescitnento revolucionário, o status e o valor do gerente de
projetos passaram a ter maior importância - ter esse know-how permite que u1na
empresa conclua projetos co1n ma ior rapidez, menores custos, ma ior satisfação do
cl iente e resultados mais desejáveis.
• O conhecimento que já foi visto como "bom de se ter" hoje é considerado obriga-
tório. O sucesso econômico e a sobrevivência de uma empresa dependem de sua
capacidade de determinar que projetos apoiam seus objetivos estratégicos gerais e
de possibilitar sequenciá-los de modo a alcançar esse sucesso.
• Hoje, os funcionários que possuem habilidades em gestão de projetos vão alé1n
dos gerentes de projetos. Membros de equ ipe e gerentes intermed iários e a ltos
estão se especializando no assunto.
• A complexidade e o escopo das metodologias de gestão de projetos au1nentara1n,
passando a incluir novas habi lidades e aplicações.
• O desenvolvimento e a melhoria de processos por meio do apoio prático ou de
soluções de gerenciamento do conhecimento se tornaram um requisito para a so-
brevivência econôm ica na mais desafiadora das épocas. O pacote de software da
Metodologia Unificada de Gestão de Projetos® do IIL (UPMM™, Unified Project
Manage1nent® Methodology) foi desenvolvido para servir de suporte à consistên-
cia e à qua lidade na i1nplementação da gestão de projetos, programas e portfólios.
• Um grande número de programas de software relacionados à gestão de projetos
foi desenvolvido (como o M icrosoft® Project e Project Server, SharePoint, Prima-
vera, e dezenas de out ros, incluindo uma ampla variedade de software de cód igo
aberto).
• A certificação em gestão de projetos tornou-se un1 ativo cada vez n1ais valioso para
o plano de carreira de um indivíduo. Consequenten1ente, havia mais de 520 mil
PMPs® ativos e n1ais de 411 mil n1en1bros do PMl no início de 2013 (o que, para
este último, representa mn aun1ento de 8,8% em relação ao ano anterior) .
• Até este momento, o conjunto de habilidades do gerente de projetos permaneceu,
e1n sua grande parte, técnico. No entanto, hoje estamos vendo gerentes de pro-
jetos abraçare1n novas áreas do conhecimento como de liderança e habi lidades
. .
1nterpessoa1s.
• O planeja1nento est ratégico da gestão de projetos assum iu importância. As orga-
nizações hoje estão buscando maneiras sistemáticas de melhor alinhar a gestão de
projetos a objetivos empresariais.
• Ma is e mais empresas estão estabelecendo escritórios de gestão de projetos e
portfólios.
• Abordagens à gestão de projetos dentro de uma organizaç.ã o pennanecem relati-

vamente va riadas e não padronizadas. As empresas precisa1n t raba lha r em direção
a uma metodologia mais madura e comum para obter u1n sucesso mais repetível
e previsível.
• As etnpresas e seus escritórios de gestão de projetos estão colocando maior ênfase
nos serviços de qualidade, produtos de qualidade e processos aprimorados por
meio do uso de ferramentas de gerenciamento como o Seis Sigma Enxuto (Lean
Seis Sigma ), Valor Agregado e Aná lise de Negócios.
Anos de revolução: tendências da aprendizagem

Em resposta a essas tendências, uma variedade de cursos ma is ampla está disponível
pa ra um número crescente de indústrias. Novos métodos de aprendizagem foram in-
t roduzidos para atender à crescente diversidade das necessidades dos cl ientes. Aqui há
a lguns exe1nplos de como o IIL respondeu a essas necessidades e estabeleceu melhores
práticas e1n treinamento e formação de gerentes de projetos:
• O IIL possui dezenas de títulos de cursos diferentes em áreas do conhecimento
avançadas para aumentar o escopo, a apl icação e a sofisticação do gerente de
projetos. Esses cursos inclue1n conceitos avançados em gestão de riscos, gestão de
projetos complexos, gerenciamento de requisitos, design e desenvolvimento de um
escri tório de projetos e gestão de projetos ágil.
• Os cursos que abordam o lado "mais humano" da gestão de projetos são criados
de fonna a aperfeiçoar habil idades de facilitação, habilidades interpessoa is, habi-
lidades de liderança e outras áreas não técnicas.
• As organizações estão aumentando e1n seus níveis de 1naturidade de gestão de pro-
jetos, há uma necessidade de t reina1nento no uso eficiente de software de gestão
de projetos e1npresarial.
• Mais e mais universidades estão reconhecendo a gestão de projetos como parte de
seus progra 1nas de pós-graduação. O IIL fez uma parceria com a New York Uni-
versity School of Continuing and Professiona l Studies (NYU-SCPS) e a University
of Southern Cal ifomia 's Marshall School of Business para oferecer progr amas de
certificação em gestão de projetos.
• O modo como aprendemos está mudando . Os funcioná rios têm menos tempo
para dedicar a estudos presenciais. Assim, alé1n dos treinamentos t radicionais em
sala de au la, o IIL oferece métodos de instrução sob de1nanda, virtuais, aplicativos
para telefone celular e vídeos.
Olhando para a bola de cristal: tendências e reações

É setnpre u1n desafio tentar prever o futuro, mas há a lgu1nas tendências que estão sur-
gindo que nos permitem tentar. Para cada uma dessas tendências, haverá a necessidade
de desenvolver as respostas de aprendizage1n apropriadas.
• Un1 fator con1petitivo essencial nas empresas será sua capacidade de empreen-
der e gerenciar eficientemente n1ú ltiplos p rojetos - projetos para desenvolver
novos p rodutos e serviços, chegar mais rapidamente ao n1ercado, aun1enta r a
satisfação do cl iente, aumentar as vendas, e assim po r d iante. Quanto mais
bem escolh idos forem os projetos, mais competitiva será a empresa no merca-
do (especia ln1ente em relação a projetos de n1elhoria em produtos, processos e
satisfação do cl iente).
• Prevemos uma m isn1ra de n1etodologias de gestão de projetos com outras estra-

tégias de negócios comprovadas (como o Seis Sign1a, gerenciamento ágil, geren-
ciamento da qualidade, gestão de riscos e análise de negócios). O treinamento
nesses assuntos irá, da mesma forma, se tornar uma m ist ura deles.
• A gestão de projetos, programas e portfólios continuará a crescer em importân-
cia e a se tornar um fator de diferenciação estratégica para as organizações per-
manecerem competitivas. O software de gerenciamento de porúólios hoje é u1na
ex1genc1a.
• A gerência sênior se tomará ma is informada e envolvida nos esforços de gestão de
projetos. Isso exigirá um treinamento em gestão de projetos que atenda às necessi-
dades específicas dos executivos.
• O planejamento est ratégico da gestão de projetos se tomará utn modo de vida
para as organizações líderes. O papel do escritório de projetos/portfólios aumen-
tará e se tornará lugar-comum e vital nas empresas. Seus membros incluirão os
níveis mais alcos da gerência executiva. A gerência sên ior assutnirá a liderança dos
esforços de gerenciamento do porúól io de projetos da etnpresa.
• O IIL continuará a fazer parcerias com empresas para oferecer certificação dupla
a gerentes de projetos. Os gerentes de projetos terão de ser certificados em gestão
de projetos além de etn operações e processos internos de sua empresa.
• Os executivos estarão cada vez 1nais envolvidos em atividades como p laneja1nento
de capacidade, gerenciamento de portfól ios, priorizaç.â o, melhoria de processos,
gerenciamento da cadeia de suprimentos e planejamento estratégico, especifica-
mente para a gestão de projetos. Na verdade, mais e mais executivos estão tirando
certificações em gestão de projetos.
• A pa rticipação de alcos gerentes será obstruída pelo fato de sua experiência e treina-
n1ento serem limitados em gestão de projetos, programas e portfólios. Utn elen1en -
to essencial será oferecer a esses gerentes a experiência e o treinamento etn con10
gerenciar as atividades de projeto etn suas empresas. Esse treinan1ento precisa ser
adaptado às necessidades e responsabil idades específicas da alta gerência.
• Os sistemas de recompensa e reconhecimento da empresa irá mudar para passar a
estimular e reforçar as metas e objetivos da gestão de projetos.
• O treinan1ento en1 gestão de projetos será expandido, passando a inclu ir todos os
níveis da hierarqu ia da en1presa, inclusive os não gerentes de projetos. O treinamen -
to se tornará responsivo a un1a variedade de funções, níveis e responsabi lidades.
• O status do gerente de projetos certificado crescerá significativamente, e as habi li-
dades do gerente de projetos serão tanto técn icas quanto gerenciais.
• Testetnunharemos o estabelecimento de um executivo de gestão de projetos no
nível corporativo (principal executivo de gestão de projetos).
• O bench,narking de projetos e a melhoria contínua dos projetos se tornarão essen-
cia is para as organ izações líderes. Os 1nodelos de maturidade da gestão de proje-
tos desempenharão um papel importante nesse sentido, pois ajudarão as empresas
a identificarem seus pontos fortes, fracos e oportunidades específicas de melhoria.
• A crescente itnportância da gestão de projetos, programas e porúól ios exigirá n1ais
indivíduos que sejam t reinados em gestão de projetos. Isso, por sua vez, necessitará
do desenvolvin1ento de novos e aperfeiçoados métodos de instrução. O treinamen-
to on-line desen1penhará um papel cada vez n1ais importante.
• Veremos um aumento da ordetn de grandeza do número de organ izações que al-
cançam os níveis mais altos de maturidade de projetos.
• Mais faculdades e universidades oferecerão programas de pós-graduação em ges-
tão de projetos e procurarão a linhar seus cursos aos padrões e às melhores práti-
. . .
cas 1nternac1ona1s.
• A gestão de projetos se focará em oferecer o conhecimento e as melhores práticas

para oferecer suporte a iniciativas sustentáveis. A sustentabil idade de projetos na
economia globa l por meio de valores, liderança e responsabilidade profissional
serão obrigatórios para todos os gerentes e patrocinadores de projetos, programas
e portfólios.
8.5 Identificando a necessidade de treinamento

Identificar a necessidade de treinamento exige que gerentes de área e gerentes sênior
reconheçam dois fatores críticos: primeiro, que o treinamento é uma das maneiras
mais rápidas de const ruir conhecimento sobre gestão de projetos em u1na empresa e,
segundo, que o treinamento deve ser ministrado para o benefício dos resu ltados cor-
porativos por meio de ma ior eficiência e eficácia.
Identificar a necessidade de treinamento se tornou um pouco mais fácil nos últi-
mos 10 anos, devido aos estudos de casos publicados sobre os benefícios do treina-
mento em gestão de projetos. Os benefícios podem ser classificados de acordo com
benefícios quantitativos e qualitativos. Os resultados quantitativos incluem:
• Menor tempo de desenvolvimento de produtos
• Decisões mais rápidas e de ma is alta qualidade
• Custos mais baixos
• Margens de lucro mais altas
• Necessidade de menos pessoas
• Redução da papelada
• Maior qualidade e confiabilidade
• Menor rotatividade de pessoa l
• lmple1nentação 1nais rápida das "melhores práticas"
Os resultados qualitativos incluem:
• Maior visibil idade e foco sobre resultados
• Melhor coordenação
• Moral mais alto
• Desenvolvimento acelerado dos gerentes
• Maior controle
• Melhores relações com os clientes
• Maior apoio funcional
• Menos conflitos que exigem o envolvimento da gerência sênior
As empresas estão finalmente percebendo que a velocidade com a qua l os benefí-
cios da gestão de projetos podem ser alcançados é acelerada por 1neio do treinamento
adequado.
8.6 Selecionando alunos

Selecionar as pessoas para sere1n t reinadas é crucial. Como já vimos em vários estudos
de casos, é norma lmente um erro t reinar apenas os gerentes de projetos. Para que a
gestão de projetos seja bem-suced ida, é necessário que haja, em toda a organização,
u1na compreensão minuciosa da gestão de projetos e das habi lidades por ele exigidas.
Por exe1nplo, uma subcont ratada do ramo automobilístico investiu meses em t reinar
seus gerentes de projetos. Seis 1neses depois, os projetos ainda estavam sendo concluí-
dos com atraso e com o rçamento estourado. O vice-presidente executivo fina lmente
percebeu que a gestão de projetos era um esforço de equipe em vez de uma responsa-
bilidade individual. Depois dessa revelação, foi oferecido treinamento para todos os
funcionários que tinham alguma ligação com os projetos. Praticamente da noite para
o dia, os resultados dos projetos melhoraram.
Dave Kandt, vice-presidente aposentado do grupo, encarregado da qualidade, ge-
renciamento de programas e melhorias contínuas na Johnson Controls, explicou como
o p lano de t reinamento de sua e1npresa foi tr açado para alcançar a excelência e1n
gestão de projetos:
Começamos com nosso escritório executivo, e depois de explicarmos os princípios e filoso-
fias da gestão de projetos a essas pessoas, passamos para os gerentes das instalações, geren-
tes de engenharia, analistas de custos, pessoal do departamento de compras e aq uisições e,
é claro, gerentes de projetos. Somente q uando o fundamento tinha sido determinado é que
prosseguimos com a gestão de projetos propriamente dita e com a defin ição de papéis e res-
ponsabilidades, de modo q ue toda a empresa compreendesse seu papel na gestão de projetos
quando essas pessoas começassem a trabalhar. Somente essa compreensão nos permitiu pas-
sar a uma organização matricial e, finalmente conseguimos estabelecer um departamento
independente de ges tão de projetos.
8.7 Fundamentos da formação em gestão de projetos

Há vinte anos, éramos um tanto limitados quanto à dispon ibilidade do treinamento e
formação em gestão de projetos. A ênfase era em torno de treinamento prático na es-
perança de que 1nenos erros fossem cometidos. Hoje, temos outros ripos de programa,
como, por exemplo:
• Cursos universitários
• Seminários universitários
• Seminários nas empresas
• Grades curriculares nas empresas
• Equipes de aprendizagem à distância (e-learning)
• Treinamento baseado em computador (CBT, ou computer-based training)
Com a quantidade de literatura disponível hoje em dia, temos diversas maneiras
de difundir o conhecimento. Sistemas de instrução típicos incluem:
• Palest ras
• Palest ras com discussão
• Exames
• Estudos de caso sobre empresas externas
• Estudos de caso sobre projetos internos
• Simulação e dramatização
Os gerentes em treinamento estão atualmente fazendo experimentos com o "quan-
do fazer o treinamento". As escolhas mais comuns incluem:
• Treinamento j11st-i11-time: Inclui treinar funcionários imediatamente antes de de-
signá-los a projetos.
• Treinamento por exposição: Inclui treinar funcionários nos princípios centra is

apenas pa ra lhes dar conhecimento suficiente para que eles compreendam o que
está acontecendo na empresa em termos de gestão de projetos.
• Aprendizagem contínua: Treinamento primeiro nos tópicos básicos, depois em
avançados, para que as pessoas continuem a crescer e a amadurecer em gestão de
proJetos.
• Treinamento da autoconfiança: Sim ilar à aprendizagem contínua, ,nas em conhe-
cimentos de última geração. Serve para reforçar a crença dos funcionários de que
suas habilidades são comparáveis àquelas das empresas com reputações excelentes
em gestão de projetos.
8.8 Algumas mudanças na formação

em gestão de projetos
Nos primórdios da gestão de projetos, quase todos os gerentes de projetos vinham
de d isciplinas de engenharia. Esperava-se que os gerentes de projetos dominassem a
tecnologia em vez de ter apenas certos conheci tnentos sobre ela. Quando os princípios
do gestão de valor agregado (GVA) foram desenvolvidos, o curso de gestão de proje-
tos enfatizava o controle de custos e cronogra tnas . Surgiram seminários no mercado
intitulados "Gestão de projetos", mas o conteúdo desses cursos de dois ou três dias
de duraç.ã o era quase que integralmente PERT e GVA. Em quase todas as indúst rias, a
gestão de projetos era vista como um tra balho que exigia dedicação em tempo parcial,
e algo extra ao cargo principa l de um profissional. A necessidade de compreender in-
tegralmente as habil idades e competências necessárias pa ra ser eficiente como gerente
de projetos não era considerada tão itnportante.
Hoje, a gestão de projetos é um ca rgo cotn plano de carreira em quase todas as
empresas. Faculdades e un iversidades hoje oferecem cursos de mestrado e doutorado
etn gestão de projetos.
Assuntos tipicamente abordados nesses progra tnas incluem:
Grade curricular central:

• Princípios da gestão de projetos
• Técnicas de geração de cronogramas
• Técnicas de esti tnação para projetos
• Técnicas de financiamento de projetos
• Criatividade e brainstorming
• Solução de problemas e to tnada de decisões
• Gestão de projetos global
• Gerenciatnento de múltiplos projetos
• Liderança em gestão de projetos
• Gerenciamento de equ ipes virtua is
• Gerenciatnento de portfólios de projetos
Matérias eletivas:
• Gestão de projetos avançada
• Gerenciatnento da qualidade em projetos
• Aquisições e contratos em projetos
• Ética em projetos e o Código de Conduta Profissiona l
• Técnicas de monitoramento e controle de projetos
Capítulo 8 Treinamento e formação 41 1
• Práticas de relatórios em projetos

• Gerenciamento das relações co1n as partes interessadas
• Conduzindo verificações da "saúde" de projetos
• Gestão de projetos proble1náticos
• Identificação de melhores práticas
• Gerenciamento de diferenças culturais
Algumas instituições educacionais também oferecem aos alunos t reinamentos es-
pecializados para certificação em várias áreas da gestão de projetos. O conhecitnento
necessário para passar nos exames de certificação podem vir de cursos especializados
ou dos requisitos centrais tradicionais e matérias eletivas. Uma lista parcial de a lguns
programas de certificação relacionados à gestão de projetos pode incluir:
• Gerenciamento de programas
• Gestão de riscos de projetos
• Gestão de projetos ágil
• Ana lista de negócios
• Gestão de projetos complexos
• Outras certificações em gestão de projetos
• Certificações especializadas ou personalizadas
A ma ior mudança na formação em gestão de projetos parece ser do lado dos re-
quisitos de habilidades mais "humanas". Isso é compreensível, já que projetos exige1n
que as pessoas t raba lhem juntas. A ênfase nas áreas co1nporta1nenta is hoje estão sendo
colocadas em:
• Habi lidades de solução de problemas
• Habi lidades de tomada de decisões
• Habi lidades de conceitualização
• Habi lidades de criatividade!brainstor,ning
• Habi lidades de processos
• Lidando co1n o estresse/pressão
• Liderança sem autoridade
• Relatórios a diversos chefes
• Aconselhamento e faci litação
• Habi lidades de mentoria
• Habi lidades de negociação
• Habi lidades de resolução de conflitos
• Habi lidades de apresentação
No futuro, é possível que habilidades de networking social possam ser adiciona-
das à lista.
8.9 Planejando cursos e ministrando o treinamento

Muitas empresas percebera1n que o treinamento prático na empresa pode ser menos
eficiente do que um t reinamento ma is forma l. O t reinamento prático na empresa pra-
ticamente força as pessoas a cometerem erros como u1na experiência de aprendizage1n,
mas o que elas estão aprendendo? A como cometer erros? Parece muito mais eficiente
treina r as pessoas a fazerem seu trabalho da forma correta desde o início.
A gestão de projetos se tornou uma carreira. Mais e 1na is empresas hoje perm item
ou até mestno exigem que seus funcionários obtenhatn certificação em gestão de pro-
jetos. Uma empresa informou seus funcionários de que a certificação seria tratada da
mesma forma que utn mest rado na estrutura salarial e de plano de carreira. O custo do
t reinamento por trás do processo de certificação é de apenas 5 ou 10% do custo de um
mestrado típico no programa de adtninist ração. E a certificação promete um retorno
sobre investimento (ROi) ma is rápido para a empresa. A certi ficação etn gestão de
p ro jetos pode ser útil também para funcionários sem d iplomas universitários; ela lhes
dá a oportunidade de um segundo plano de carreira na empresa.
Linda Zaval, antiga instrutora do lnternational Institute for Learning, explicou
que tipo de treinamento em gestão de projetos funcionava melhor etn sua experiência
durante o início da década de 1990:
Em nossa experiência, descobrimos que o treinamento antecipado é definitivamente o me-
lhor caminho a ser tomado. Fizemos da outra maneira, com as pessoas aprendendo na práti-
ca e, às vezes, essa era uma situação terrível. Quando falamos em treinamento, não estamos
falando apenas de treinamento. Queremos que nossos gerentes de projetos sejam certifica-
dos pelo Project Management lnstitute (Plvll). Temos dado ao nosso pessoal dois anos para
obter a certificação. Para tal, é necessária uma boa dose de dedicação e estudos pessoais.
Acredito que o treina mento ma is formal seja excelente, e então você pode mod ificá-lo para
q ualquer necessidade interna de sua empresa.
Há também a questão do que é melhor: programas de treina tnento internos ou
oferecidos pelo governo. A resposta depende da natureza de cada empresa individual
e de quantos funcionários precisam ser treinados, do taman ho do orçamento e da pro-
fundidade da base de conhecimento interna da etnpresa. Se apenas alguns funcionários
de cada vez precisaretn de treina tnento, pode ser mais eficiente enviá-los a um curso de
t reinamento patr ocinado pelo governo, mas, se grandes números de funcionários pre-
cisaretn de treinamento continuamente, planejar e m inist rar um treina tnento interno
personal izado pode ser a mel hor opção.
Em geral, cursos personalizados são os 1na is eficientes. Em empresas excelentes,
são realizadas pesquisas quanto ao conteúdo dos cursos em todos os níveis da gerên-
cia. Por exemplo, o gr upo de P&D da Babcock and \Vilcox em Alliance, Ohio, EUA,
p recisava de um treina tnento em gestão de projetos para 200 engenheiros. A líder
do departamento de treinamento sa bia que não estava qua lificada para selecionar o
conteúdo centra l, então, enviou questionários aos gerentes executivos, gerentes de área
e outros profissiona is da organização. As informações obtidas por meio dos questio-
nários foram usadas para desenvolver t rês cursos separados para o público. Na Ford
Motor Company, o t reinamento fo i subdividido em uma sessão de duas horas para
executivos, um programa de três dias para o pessoal dos projetos e uma sessão de meio
d ia para o restante do pessoal.
Pa ra cursos de treinamento interno, escolher os instr utores e palestrantes corretos
é essencia l. Uma empresa pode usar instrutores que já fazem parte do seu quadro de
funcionários, se eles tiverem um sólido conhecimento de gestão de projetos, ou os
instrutores podetn ser treinados por consu ltores externos que oferecem programas de
t reinamento de fonnação de instrutores.
De uma forma ou de outra, os inst rutores da empresa devem ter o conhecimento
de que a empresa precisa. Alguns problemas com usar instrutores internos incluem os
seguintes:
• Eles podem não ter experiência em todas as áreas da gestão de projetos.
• Eles pode1n não ter conhecimentos atua lizados das técnicas de gestão de projetos
praticadas por outras empresas.
• Ele.s ta lvez tenham outras responsabi lidades na empresa e, assim, podem não ter o
tempo adequado para a preparação.
• Eles podem não ser tão dedicados à gestão de projetos ou tão habi lidosos quanto
inst rutores externos.
No entanto, a base de con hecimento dos instrutores internos pode ser amplia-
da por inst rutores externos à medida que for necessário. Na verdade, a maioria das
empresas usa pa lest rantes e instrutores externos para seus t reina 1nentos internos. A
melhor manei ra de selecionar palestrantes é buscar recomendações de diretores de
treinamento de outras empresas e de professores de cursos de nível universitário em
gestão de projetos. Um outro método é contatar o escritório dos palest rantes, mas a
qualidade do progra1na oferecido pode não ser tão a lta q uanto o necessário. O mé-
todo mais comum para descobri r pa lest rantes é analisar os folhetos de seminá rios
pat rocinados pelo governo. É claro, os folhetos foram criados como 1naterial de venda,
então, a mel hor maneira de ava liar os semi nários é assisti-los.
Depois de um possível palestr ante ser selecionado, o passo seguinte é verifica r
suas recomendações. A Tabela 8- 2 resume muitos dos perigos envolvidos na escolha
de palestrantes para progra1nas de treinamento interno e como você pode evitá-los.
O passo final é avalia r os materiais de t reinamento e a apresentação que o instru-
tor externos usará nas aulas. As seguintes perguntas podem ser usadas como u1n a lista
de verificaç.ão:
TABELA 8-2 Perigos comuns envolvidos na contratação de Instrutores e palestrantes

externos
Sinal de alerta Como evitar
O palestrante afirma ser especialista em várias Verifique as credenciais do palestrante. Muito poucas pessoas
áreas diferentes são especialistas em diversas áreas. Fale com outras empre-
sas que já o contrataram
O currículo do palestrante identifica como Verifique se o palestrante já prestou consultoria para algumas
cliente várias organizações conhecidas e bem dessas empresas mais de uma vez. Às vezes, um palestrante
conceituadas faz um bom trabalho de marketing pessoal da primeira vez,
mas a empresa se recusa a recontratá-lo após sua primeira
apresentação
O palestrante causa uma primeira impres- Ser um palestrante dinâmico não garante que sejam apresen-
são muito positiva e faz um bom marketing tadas informações de qualidade. Alguns palestrantes são tão
pessoal. Uma breve observação de uma aula dinâmicos que os alunos não percebem até tarde demais que
confirma sua impressão "aquele cara era legal, mas as informações, nem tanto"
O currículo do palestrante mostra 10 a 20 Dez a vinte anos ele experiência em determinada indústria ou em-
anos de experiência ou mais como gerente de presa não significa que o conhecimento dO palestrante seja trans-
projetos ferível às necessidades específicas de sua empresa ou indústria.
Pergunte ao palestrante que tipos de projetos ele já gerenciou
O pessoal do departamento de marketing da Você está contratando o palestrante, e não o representante de
empresa do palestrante mostra agressivamen- marketing. Peça para falar com o palestrante ou encontrá-lo
te a qualidade de sua empresa, em vez de a pessoalmente e analise a lista de clientes dele, em vez de a
qualidade do palestrante. A lista de clientes lista da empresa
apresentada é a lista de clientes da empresa
O palestrante promete personalizar seus ma- Exija ver o material personalizado do palestrante pelo menos
teriais para atender às necessidades da sua duas semanas antes do programa de treinamento. Verifique
empresa também a qualidade e o profissionalismo de gráficos e outros
materiais
• O pa lestrante usa muitos slides em sua apresentação? Slides podem ser um proble-
ma quando os alunos não têm luz suficiente para totnar notas.
• O instrutor usa t ransparências? Elas foram preparadas profissionalmente? Os alu-
nos receberão cópias das transparências?
• O palest rante faz 1nuito uso de quadro negro? Escrever muito no quadro normal-
mente significa que os alunos precisarão anotar mu ito e que há pouca prepa ração
de aud iovisual por parte do palestrante.
• O palestrante usa estudos de caso? Se usa, os estudos de caso são factuais? É me-
lhor que a empresa desenvolva seus próprios estudos de caso e peça ao palestrante
que os use, pa ra que os casos tenham relevância para os negócios da empresa.
• Há dramatização e experimentos planejados? Eles podetn ser recursos val iosos
para a aprendizagem, mas ta tnbém podem li1n itar o tamanho da turma.
• Deveres de casa e leitura obrigatória fazem parte da aula? Em caso afirmativo, eles
podem ser concluídos antes do seminário?
8.10 Medindo o retorno sobre o investimento

na formação dos funcionários
A última área de t reinamento etn gestão de projetos é a determinação do valor obtido
com o montante investido etn treinamento. E essencial lem brar que o treinamento não
deve ser realizado, a menos que haja um retorno contínuo sobre o investimento feito
pela empresa. Tenha etn mente, tambétn, que o valor cobrado pelo pa lestrante é ape-
nas u1na parte do custo do treinamento. O custo para a empresa de ter funcioná rios
afastados de seu tr aba lho regular precisa ser incluído no cálculo. Algumas etnpresas
excelentes cont ratam consultores externos para determinar o ROi. Os consultores
baseiam suas avaliações em ent revistas pessoais, avaliações no local e pesqu isas por
escnto .
Uma empresa testa os a lunos antes e depois do treina tnento para descobrir quan-
to conhecimento eles realmente obtiveram. Uma out ra empresa contrata consultores
externos para preparar e interpretar pesquisas pós-treinamento sobre o valor do trei-
na tnento específico recebido.
A quantidade de treinamento necessária em qualquer empresa depende de dois
fatores: se a empresa é voltada para projetos e se ela já pratica a gestão de projetos há
utn tempo suficiente para ter desenvolvido um sistema 1naduro . A Figura 8- 3 mostra
a quantidade de treinamento oferecida (inclusive cursos de atua lização) em relação ao
número de anos de prática em gestão de projetos. As o rganizações voltadas a projetos
oferecem o maior número de t reinamentos, e as o rganizações que acabaram de imple-
mentar a gestão de projetos oferecem o menor nútnero. Isso não é nenhuma surpresa.
As empresas com mais de 15 anos de experiência em aplicar princípios de gestão de
projetos mostr atn a maior va riância.
8.11 A gestão de projetos agora

é uma profissão
Durante muitos anos, a gestão de projetos foi vista como uma ocupação parcia l e, por-
tanto, todo o treinamento era voltado para o cargo principal do aluno, qualquer que
ele fosse, em vez de para gestão de projetos. Por esse motivo, não havia necessidade de
desenvolver descrições de cargos para os gerentes de projetos e programas. Hoje, essas
Indústrias não direcionadas a projetos

(maioria não madura) D Ausência de crescimento
(seguir o líder)
D Indústrias em amadurecimento
(maioria direcionada a projetos)
D Estrelas do amanhã
D Crescimento lento (barreiras)
o
~
-"'
o
.õ~
~
Q.
~
"'o o
'"'
1;s
~
e,
:li!
:;
E
-
~
o
e:
~
E
"'
e:
~
o
><
~
~
>-
1-5 6- 15 Mais de 15
Anos de experiência em gestão de projetos
Figura 8-3 Quantidade de treinamento por tipo de indústria e anos de experiência em gestão de
projetos. Fonte: Reimpresso de H. Kerzner, ln Search of Excel/ence in Project Management, Hoboken,
NJ: Wiley, 1998, p. 185.
descrições de cargo existem, a gestão de projetos é vista como uma profissão, e os pro-
gramas de treinamento são oferecidos com base nessas descrições de cargo. Quando
perguntamos a um porta-voz da AT&T se a empresa possuía descrições de cargos, ele
respondeu "sim" para o gerenciamento tanto de projetos quanto de programas:
Gerente de projetos
Realiza uma gestão de projetos e11d-to-e,ui durante todo o c iclo de vida de um projeto, di-
recionando os esforços da(s) equi pe(s) de projeto por meio do uso de autoridade funciona l
de entregar um produto e/ou serviço concluído. Possui total responsabilidade por gerenciar
projetos de baixa a alta complexidade, ou projetos dentro de programas que podem envol-
ver múltiplas regiões e/ou múltiplas funções; diversos projetos concorrentes podem ser ge-
renciados. Inclui gerar estimativas e cronogramas, coordenar, designar recursos, certifica r-se
de que o financiamento do projeto seja garantido e auxiliar na recomendação de soluções
de negócios/alternati,•as para os projetos. Avalia, planeja e gerencia os riscos do projeto, pe-
rigos, escaladas de conflitos e resoluções de problemas. Gerencia o escopo do projeto, bem
como seu orçamento e relatórios de custos, e garante a conclusão de projetos se atendo à
qualidade, ao cronograma e aos objetivos de custos usando os processos-padrão da organi-
zação. Age como ligação do projeto entre parceiros de TI, organizações clientes e liderança
de TI. Pode auxilia r no gerenciamento de fornecedores junto aos fornecedores existentes.
Pode dirigir gerentes associados de projetos para oferecer apoio às comunicações do pro-
jeto e ao acompanha mento de seu progresso. Não inclui o gerenciamento de programas
extremamente grandes e complexos, com vários subprogramas, o que exige supervisão pelo
nível sênior e extensas comunicações entre os executivos. Precisa passar pelo menos 80% do
tempo realizando as obrigações de gestão de projetos descritas acima.
Gerente de programas
Realizar a gestão de projetos end-to-end e/ou o gerenciamento de programas através de
todo o ciclo de vida de um projeto/programa direcionando os esforços da(s) equipe(s) de
projeto/progra ma por meio do uso de autoridade funcional de entregar um produto e/ou
serviço concl uído. Possui responsabilidade total por gerenciar projetos conco rrentes de a lta
complexidade e/ou programas que podem abranger diversas regiões, funções e/ou un idades
de negócios . Responsável pelo pla nejamento detalhado, inclusive por estrutura e recruta-
mento de pessoal de programas/projetos, fazer estimações, a locar e designar recursos, gerar
c ronogramas detalhados, fazer análises do caminho crítico, consolidar planos de projeto
e m um plano de programa geral e negociar qua lquer conflito q ue possa s urgir. Dirige as
atividades do projeto e/ou programa utilizando os processos-padrão da organização para
garantir a entrega dentro do prazo dos benefícios de negócios declarados, comparando a
realidade aos planos e aj ustando os pla nos como for necessário. Avalia, planeja e geren -
c ia os riscos de projeto/programa, incluindo planos de mitigação e contingência; geren -
cia problemas, perigos, escaladas de conflitos e resoluções de problemas. Define o escopo
do projeto/programa e garante que mudanças no escopo e deliverab/es sejam gerenciados
usando o processo de controle de mudanças. Gerencia orçamentos e relatórios de custos
de programas ou projetos de grande porte. Age como elo entre cliente e liderança de TI,
propiciando comunicação e status de progresso do projeto/programa. Pode a uxiliar e m
desenvolvimento de solicitações de propostas, avaliação e seleção de fornecedores, além de
relaciona mentos existentes com fornecedores o u consultores. Utiliza os conhecimentos do
negócio, indústria e tecnologia para incorpora r melhorias do processo de negócio à organ i-
zação e/ou para desenvolver estratégias de negócios e arquiteturas funciona is/empresaria is/
técn icas. Pode dirigir os esforços de gerentes de projetos q uando estes gerenciam um pro-
jeto o u subprograma sobre o qual o gerente sênior de projetos/programas tem autoridade.
Pode incluir o gerenciamento de programas extremamente grandes e complexos, como
d iversos subprogramas, o q ue exige supervisão pelo nível sênior e extensas comunicações
entre os executivos. Precisa passar pelo menos 80o/o do tempo realizando as obrigações de
gestão de projetos descritas acima .
O recon hecimento da gestão de projetos como uma profissão se espalhou por

todo o inundo. Segu ndo Enrique Sevilla Molina, antigo di retor do PMO da Indra:
A gestão de projetos é considerada o resultado de um mistura específica de conhecimento e
experiência, obtidos por meio da dedicação a a lcançar o sucesso em projetos sob a respon-
sabilidade do gerente de projetos.
Temos um conjunto de papéis de gerenciamento associados aos d iferentes n íveis de
responsabilidades e experiência em gerenciar projetos, programas e portfólios, e para de-
senvolver oportunidades de negócios (i.e., gerentes de projetos, diretores de programas,
etc.). Para cada papel, define-se um conjunto específico de habilidades em determinado
grau, então o desempenh o e o grau de sucesso podem ser avaliados. A avaliação anual do
desempenho pessoal é feita com base em descrições de cargo, maturidade que o papel já
alcançou e desempenho esperado para o papel e seu desempenh o real. Assim, a evolução do
desempenho pessoal ta mbém pode ser avaliada .
8.12 Modelos de competências

Há 20 anos, as empresas preparara 1n descrições de cargo para gerentes de projetos
para explicar seus papéis e responsabi lidades. Infelizmente, as descrições de cargo
eram normalmente muito breves e ofereciam 1nuito pouca orientação sobre o que era
necessário pa ra receber promoções ou au1nentos sala riais. Há 10 anos, ainda enfati-
závamos a descrição de cargo, mas agora ela tinha o suporte de u1n material didático,
que geralmente era obrigatório. No final da década de 1990, as empresas começara1n
a enfatizar modelos de competências cent rais, que claramente descreviam os níveis de
habilidades necessárias para ser eficiente como gerente de projetos. Os programas de
treinamento foram instituídos para oferecer suporte aos modelos de competências cen-
tra is. lnfeliz1nente, estabelecer um modelo de competências centrais e o treinamento
que o aco1npanha não é tarefa fácil.
A Eli Lilly possu i o que talvez seja um dos mais abrangentes e eficientes 1nodelos
de competências da indústria hoje. Martin D. Hynes, IIl, diretor de gestão de projetos
farmacêuticos do PPM (Pharmaceutical Project Management), foi o patrocinador-cha-
ve da iniciativa para desenvolver o modelo de competências. Thomas J. Konechnik,
gerente de operações da gestão de projetos farmacêuticos, foi responsável pela imple-
mentação e integração do modelo de competências com out ros processos do grupo
PPM. A base do modelo de competências é descrita abaixo. As competências de gestão
de projetos do Lilly Research Laboratories classificam-se em três grandes áreas:
Especialização científica/técnica
• Conhecer o negócio: considerar os conhecimentos sobre o processo de de-
senvolvimento de medicamentos e as real idades organizacionais ao tomar
decisões.
• Iniciar ações: dar passos proativos para abordar necessidades ou problemas
antes que a situação exija.
• Pensar criticamente: buscar fatos, dados ou a opin ião de especial istas para
orientar a decisão ou o curso de ação.
• Gerenciar riscos: prever e possibilitar mudanças nas prioridades, cronogra1nas
e recursos e 1nudanças devido a assuntos científicos/técn icos.
Habilidades processuaís
• Comunicar-se com clareza: ser bo1n ouvinte e fornecer infonnações que sejam
facihnente compreendidas e úteis para os outros.
• Prestar atenção a detalhes: manter registros co1npletos e detalhados de planos,
minutas de reuniões, acordos.
• Est ruturar o processo: constr uir, adaptar ou seguir um processo lógico para
garantir que objetivos e metas sejam alcançados.
Uderança
• Foca lizar-se e1n resultados: focalizar continuamente sua própria atenção e a
dos outros e1n marcos e deliverables real istas.
• Constru ir uma equipe: criar um ambiente de cooperação e responsabilidade
mútua ent re as funções e dentro delas, a fi 1n de alcançar objetivos comuns.
• Gerenciar a complexidade: organizar, planejar e monitorar diversas ativida-
des, pessoas e recursos.
• Tomar decisões difíceis: demonstrar segurança em suas próprias habil idades,
julgamentos e capacidades; assumi r responsabilidade por suas ações.
• Constr uir o suporte est ratégico: conseguir o apoio e nível de esforço neces-
sário por parte da gerência sênior e de outros para manter o projeto no cami-
nho certo.
Examinaremos cada uma dessas competências ma is detalhadamente a seguir.
1. Conhecer o negócio: considerar os conhecimentos sobre o processo de de-
senvolvimento de medicamentos e as real idades organizaciona is ao tomar
decisões.
Os gerentes de projetos/associados que demonstram essa competência irão:

• Reconhecer como outras funções na Eli Lilly afetam o sucesso de um esforço
de desenvolvimento.
• Usar os conhecimentos de que atividades estão ocorrendo no projeto como
um todo para estabelecer credibilidade.
• Saber quando 1ne1nbros de equ ipe na sua própria função e em outras precisa-
rão de suporte adiciona l para concluir u1na tarefa/atividade.
• Gerar perguntas baseadas na compreensão de interações não óbvias de dife-
rentes parte.s do projeto.
• Focalizar a atenção nas questões e premissas que têm o ma ior impacto sobre
o sucesso das atividades ou tarefas de determ inado projeto.
• Co1npreender/reconhecer problemas/est ruturas políticas da organização.
• Usar a compreensão de prioridades funcionais e empresaria is concorrentes
para testar a real idade dos planos, prem issas, estimativas de prazos e compro-
m issos por parte das funções.
• Identificar com precisão as consequências para o projeto de decisões e eventos
em outras partes da organização.
• Reconhecer e responder às diferentes perspectivas e realidades operacionais
de diferentes partes da organização.
• Considerar as implicações (prós e contras) de longo prazo das decisões.
• Co1npreender as implicações financeiras de diferentes escolhas.
Os gerentes de projetos/associados que não demonstram essa competência irão:
• Depender de recursos e estimativas de tetnpo daqueles que são responsáveis
por uma atividade ou tarefa .
• Tomar decisões baseadas no que deveria acontecer idealmente.
• Construi r planos e linhas do tempo fund indo linhas do tetnpo individua is e
assim por diante.
• Perceber at rasos como atos conscientes da parte de outras partes da organi-
zaçao.
• Supor que os mem bros de equipe compreendem como suas atividades afetam
outras partes do projeto .
• Focaliza r a a tenção em produzir relatos precisos do que aconteceu.
• Evitar mudar de planos até que seja forçado a fazê-lo.
• Esperar que mem bros de equipe peçam ajuda.
Algumas das consequências para projetos/negócios por não demonst rar essa
competência são:
• O gerente de projetos ou associado pode depender da gerência sênior para
resolver problemas e obter recursos.
• As linhas do tempo propostas do projeto podem ser significativamente retra-
balhadas de modo a a tender às diretrizes do mo1nento.
• Pode-se focal izar a atenção e1n questões secundárias em vez de em questões
centra is empresa n a1s ou técnicas.
• Co1npromissos atuais, fornecedores, entre outros, podem ser continuados in-
dependente de sua disponibil idade e valor.
• Os deliverables do projeto podem ser comprometidos por 1nudanças em ou-
tras partes da Lilly.
• Os planos de projeto podem ter um impacto negativo em out ras partes da
organização.
2. Iniciar ações: dar passos p roativos para abordar necessidades ou problemas

antes que a situação exija.
Os gerentes de p ro jetos/associados que demonstram essa competência irão:
• Fazer um acompanhamento imediato quando ocorrerem eventos imprevistos.
• Exigir ação imediata para resolver pro ble1nas e fazer escolhas.
• Expressar decisões e opções para a equipe de projeto, não siinplesmente faci-
lita r discussões.
• Assumi r responsabilidade por li da r com p ro ble1nas pelos qua is mais ninguéin
está assumindo responsabilidade.
• Formular propostas e planos de ação quando u1na necessidade ou lacuna for
identificada .
• Rapidamente abordar e leva nta r questões com a equipe de projeto e out ros.
• Informar os outros prontamente qua ndo os problemas tiverem maiores impli-
cações pa ra o p ro jeto.
• Agir de modo a ga rantir que participantes relevantes sejam incluídos em p ro-
cessos ou discussões cruciais.
Os gerentes de projetos/associados que não demonstra1n essa competência
1rao:
• Focal izar esforços em garanti r que todos os lados de pro blemas sejam explo-
rados.
• Pedir aos outros para formular respostas iniciais ou planos para problemas ou
eventos que suqam.
• Deixar que áreas funcionais resolva m sozinhas questões relativas a recursos.
• Levantar questões difíceis ou possíveis problemas depois que seu impacto seja
totalmente co1n preendido.
• Evitar interferi r ou intervi r en1 áreas fora de sua própria área de especial ização.
• Supor que mem bros de equipe e o utros responderão assim que puderem.
• Deixar que me1n bros de equipe mais experientes decida 1n sobre o ,nodo como
lidar com um pro ble1na.
Algumas das consequências para projetos/negócios por não demonstrar essa
competência são:
• A gerência sênior pode ser surpreendida por eventos relacionados ao projeto.
• As atividades do projeto podem se atrasar devido a "problemas de com unica-
ção" ou à delonga na resposta das funções.
• Esforços e recursos podem ser desperd içados ou subutilizados.
• Vá rias abordagens podem ser adotadas em paralelo.
• Problemas difíceis podem ser deixados sem resolução.
3. Pensa r critica mente: buscar fatos, dados o u a op inião de especia listas pa ra
orientar a decisão o curso de ação .
Os gerentes de p ro jetos/associados que demonstra m essa competência irão:
• Buscar informações de pessoas com experiência ou conhecimentos de primei-
ra mão dos problemas enfrentados, e assim por dia nte.
• Fazer perguntas difíceis e diretas para esclarecer esti mativas de prazos ou para
questiona r premissas e ser capaz de compreender as respostas .
• Imergir-se nas informações do p rojeto para compreender rapidamente o status
do projeto e seus principa is problemas.
• Focal izar a atenção nas principa is premissas e causas-ra iz quando surgirem

problemas.
• Resumir de maneira rápida e sucinta discussões longas.
• Levantar dados sobre projetos passados, entre outros, para ajudar a determi-
nar as melhores opções futuras para um projeto.
• Esforçar-se para obter fatos e dados suficientes a fim de fazer um julgamento
sól ido.
• Assi1n ilar grandes volumes de informação de 1nuitas fontes diferentes.
• Usar ferra tnentas formais de decisão quando apropriado para avaliar a lterna-
tivas e identificar riscos e problemas.
Os gerentes de projetos/associados que não de1nonstram essa competência irão:
• Aceitar premissas trad icionais em relação à necessidade de recursos e estima-
tivas de prazos.
• Depender dos membros de equ ipe para obter as informações necessárias.
• Esforçar-se para atingir um novo marco sem determinar o motivo pelo qual o
marco anterior não foi alcançado.
• Resumir deta lhes de discussões e brigas setn tirar conclusões.
• Li ,n itar as perguntas a fontes-padrão de informações.
• Usar procedimentos e ferramentas que estejam pronta tnente disponíveis.
• Defin ir papéis de forma estreita ao faci litar e documenta r as discussões dos
membros de equipe.
competência são:
• Os compromissos assumidos podem ser muito fora da real idade ou ter datas
não testadas.
• Abordagens de alto risco podem ser adotadas setn validação explícita.
• Os projetos poden1 levar 1nais tempo do que o necessário para serem concluídos.
• Novas descobertas e resultados podem ser incorporados lentamente a outras
práticas atuais da Li lly.
• G randes problemas podem surgir inesperada tnente.
• Os mesmos proble1nas podem se repetir.
• O plano de projeto pode pennanecer inalterado apesar de grandes mudanças
nos recursos, pessoas e prioridades.
4. Gerenciar riscos: prever e possibi lita r mudanças nas prioridades, cronogra-
mas e recursos e mudanças devido a assuntos científicos/técnicos.
• Fazer duplo controle de dados e pretn issas importantes antes de tomar deci-
sões controversas ou potencialmente arriscadas.
• Cria r um p lano de contingência ao buscar opções que têm riscos cla ros
associados.
• Manter utn conta to direto contínuo com atividades "arriscadas" ou do cami-
nho crítico para compreender o progresso.
• Estimular os membros de equ ipe a identificarem todas as pretnissas implícitas
. . .
em suas est1mat1vas e co1nprom1ssos.
Manter contato regu lar com aqueles cujas decisões afetam o projeto .
• Informar se1n delongas a gerência e outros sobre os r iscos associados a deter-

minado p lano de ação .
• Defender o nível de recursos e estimativas de prazo que possibilite1n eventos
" inesperados" previsíveis.
• Identificar as principa is fontes de riscos científicos.
Os gerentes de projetos/associados que não demonstram essa con1petência irão:
• Permanecer otim istas independentemente do progresso.
• Concordar co1n as linhas do tempo do projeto apesar de terem sérias objeções.
• Inovar em valor e ideias apesar dos riscos iminentes.
• Aceitar membros de equipe menos experientes em áreas cruciais.
• Dar aos indivíduos a liberdade de explorar diferentes opções.
• Aceitar estimativas e avaliações com 1nínima d iscussão.
competência são:
• Os projetos pode1n levar mais tempo do que o necessário para serem concluídos.
• Os projetos podem ter dificu ldade de responder a mudanças nas prioridades
. . .
organ1zac1ona1s.
• Podem ocorrer grandes at rasos se a abordagem inovadora proposta se mos-
t rar inadequada.
• Áreas problen1áticas conhecidas pode1n continuar sendo fontes de dificuldades.
• Os planos de projetos podem estar sujeitos a revisões drásticas.
5. Comunicar-se com clareza: ser bom ouvinte e fornecer informações que se-
ja,n faci lmente compreendidas e úteis para os outros.
• Apresentar proble1nas técnicos e outras questões complexas de 1naneira clara
e interessante.
• Posicionar ou adaptar a comunicação para que ela aborde as necessidades
ou o nível de compreensão do público (p.ex.: necessidades médicas, gerência
sênior).
• Filt rar dados para que eles forneçan1 as informações ma is relevantes (p.ex.:
não entra r em todos os detalhes, mas saber quando e como fornecer uma
visão gera l).
• Manter os outros infonnados e atua lizados sobre decisões ou problemas que
podem afetá-los.
• Facilitar e encorajar a comunicação a berta ent re os me1n bros de equ ipe.
• Estabelecer mecanismos para comunicações periódicas co1n membros de equi-
pe que se encontre1n em loca is re1notos.
• Identificar com precisão os principais pontos de d iscussões complexas ou
longas.
• Dedicar o te1npo necessário para preparar apresentações para a gerência.
• Comunicar eficientemente e representar argumentos técnicos fora da própria
área de especial ização.
• Fornecer todos os deta lhes disponíveis.
• Ver diversos lem bretes ou mensagens co1no ineficientes.
• Espera r que os membros de equ ipe compreendam termos técnicos das áreas
de especialização uns dos outros.
• Reutil izar materiais de comun icação e briefing com diferentes públicos.
• Li1n itar as comunicações a atualizações periódicas.
• Convidar para reuniões apenas aqueles que (presumivehnente) precisam estar
lá ou que têm algo a contribuir.
• Depender de especia listas técn icos para fornecer briefings em áreas de espe-
cialização técn ica.
competência são:
• Os indivíduos de fora da equipe imediata podem ter pouco conhecimento
sobre o projeto.
• Outros projetos podetn ser atrapalhados por "ações emergencia is" ou mudan-
ças de última hora no plano.
• As principais decisões e discussões poden1 ser docun1entadas inadequadan1ente.
• Os briefings da gerência podem ser entendidos como um "calvário" pela equi-
pe e pela gerência.
• Recursos/esforços podem ser desperdiçados ou mal aplicados.
6. Prestar atenção a deta lhes: documentar sistematicamente, acompanhar e or-
ganizar os deta lhes dos projetos.
• Lembrar os indivíduos de datas marcadas e outros requ isitos.
• Garantir que todas as partes relevantes sejan1 inforn1adas de reuniões e
decisões.
• Preparar se1n delongas minutas precisas e completas das reuniões.
• Atualizar ou ajustar continuamente os documentos do projeto de modo que
eles reflitam decisões e mudanças.
• Verificar a validade das premissas cent rais ao constru ir o plano.
• Fazer um acompanhamento para garantir que os compromissos sejam com-
preendidos.
• Supor que os out ros estão acompanhando os detalhes.
• Ver revisões formais como instrusões e perda de tempo.
• Escolher procedimentos que sejam, no míni1no, exigentes em termos de acom-
panhamento de detalhes.
• Revisar e atual izar apenas esporadica1nente os documentos do projeto para
que eles reflitam decisões e outras mudanças.
• Li1n itar a documentação do projeto àquelas que são forma lmente exigidas.
• Depender das anotações da reun ião con10 uma documentação adequada
delas.
competência são:
• A coordenação com outras partes da organ ização pode ser inexistente.
• A documentação pode estar incompleta ou ser difícil de ser usada para revisar
problemas do projeto.
• Podem surgir desacordos quanto aos compromissos feitos.
• O p ro jeto pode ser excessivamente dependente da p resença física do gerente

ou associado.
7. Estr uturar o processo: const ruir, adaptar ou segu ir u1n processo lógico para
garantir que objetivos e metas sejam alcançados.
• Escolher marcos que a equipe possa usar para avaliar o progresso.
• Estruturar reuniões de modo a garantir que os itens previstos na pauta seja1n
abordados.
• Identificar a sequência de passos necessária para executar o processo de ges-
tão de projetos.
• Manter uma documentação atual izada que indique as expectativas para cada
membro de equipe individual.
• Usar as ferramentas de planejamento disponíveis para padronizar os procedi-
mentos e estr uturar as atividades.
• Criar ferramentas simples para ajudar os membros de equ ipe a acompanhar,
organizar e comunicar informações.
• Construir um processo que use eficientemente o tempo dos me1nbros de equi-
pe, permitindo que eles participem das decisões do projeto; não se deve incluir
todos os membros de equipe em todas as reuniões.
• Revisar impl icações de d iscussões ou decisões para o plano de projeto como
u1n mecanismo para resumir e esclarecer d iscussões.
• Manter as discussões em andamento anotando desacordos e1n vez de tentar
resolvê-los naquele momento e lugar.
• Criar e usar um processo para garantir que prioridades seja1n estabelecidas e
que a est ratégia do projeto seja definida.
1rao:
• Confiar que membros de equ ipe experientes saibam o que estão fazendo.
• Tratar sequências de atividades complexas como u1n todo.
• Compartilhar responsabilidade por liderar reuniões, formular pautas, entre
outros.
• Criar planos e docu1nentos que sejam o mais completos e deta lhados possível.
• Providenciar documentação por escrito somente quando solicitado.
• Permitir que os membros de equipe se exprimam.
competência são:
• Os projetos podem receber níveis de atenção significativamente diferentes.
• Os projetos podem não ter u1na ún ica direção ou foco.
• Os documentos de planeja1nento podem estar incompletos ou desatualizados.
• As apresentações e briefings podem exigir grandes quantidades de traba lho
adicional.
• As reuniões podem ser vistas como improdutivas.
• Problemas centrais podem ser deixados sem solução.
• Out ras partes da organização podem não saber clara1nente o que é esperado
e quando.
8. Focalizar-se e1n resu ltados: focalizar continuamente sua própria atenção e a
dos outros em marcos e deliverables realistas.

• Ressaltar a necessidade de manter as atividades relacionadas ao projeto cami-
nhando adiante.
• Focalizar continua1nente nos deliverables finais (p.ex.: produto a ser comer-
cializado, afirmar/desconfirmar méritos de compostos, valor de produtos/pro-
gramas para a Lilly) (gerente).
• Escolher ações em termos do que precisa ser rea lizado, em vez de buscar solu-
ções ou respostas ótimas.
• Lembrar os 1ne1nbros de equipe do projeto dos principais marcos e cronogra-
mas do projeto.
• Manter os principais marcos visíveis para a equipe.
• Usar o objetivo fundamental do projeto cotno um meio de avaliar as opções
que orientam as decisões em tempo oportuno.
• Estimular os 1nembros de equipe a fazerem comprotnissos explícitos e públi-
cos com os deliverables.
• Extinguir projetos ou atividades de ba ixo va lor em tempo oportuno.
• Assumir que os membros de equipe tenham uma compreensão clara dos deli-
verables e marcos do projeto.
• Abordar tarefas e problemas somente quando elas se tornarem absolutamente
cruc1a1s.
• Minimizar ou relevar resultados negativos.
• Continuar pressionando para que os objetivos origina is seja tn alcançados
apesar de novos dados/grandes mudanças.
• Desenvolver atividades não relacionadas aos requisitos origina is do projeto.
• Confiar que todos concordarão com os planos definitivos uma vez que todos
os membros de equ ipe estejam envolvidos no projeto.
• Perm itir que indivíduos sem as devidas qual ificações permaneçam nas tarefas.
• Tornar facultativa a p resença nas reuniões de planejamento do projeto.
competência são:
• Os marcos podetn deix ar de ser cutnpridos sem uma explicação adequada.
• As áreas funcionais podem ficar surpresas com a demanda por recursos im-
portantes.
• A equipe pode se comprotneter com ,netas ou cronogramas não realistas.
• Os projetos podem levar mais ten1po do que o necessário pa ra seren1
concluídos.
• Os objetivos e as prioridades podem diferir significativamente de um membro
de equipe para outro.
9. Construir u1na equipe: criar um ambiente de cooperação e responsabilidade
mútua entre as funções e dentro delas, a fim de alcançar objetivos comuns.
• Adtn itir abertamente d iferentes pontos de vista e desacordos.
• Encorajar ativamente a participação de todos os membros de equipe, indepen-
dentemente de sua formação funcional ou nível na organização.
• Dedicar tetnpo e recursos expl icitamente para construir uma identidade de
equipe e um conjunto de objetivos compartilhados.
• Manter a objetividade; evitar levar proble1nas e desacordos para o lado pessoal.

• Esta belecer relaciona1nentos individuais com cada membro de equipe.
• Encorajar os me1nbros de equipe a contribui r co1n áreas de fora das áreas
funciona is.
• Envo lver os n1en1bros de equipe no processo de planejamento do início ao fim.
• Reconhecer e tirar proveito da experiência e especia lização que cada 1nembro
de equipe possui.
• Solicita r contribu ições e envolvimento de diferentes funções antes que elas
sejam envolvidas.
• Uma vez tomada uma decisão, insistir que a equ ipe a aceite até que dados
adicionais sejam disponibi lizados.
• Estimular o compromisso explícito dos membros de equipe ao resolver ques-
tões cont roversas.
1rao:
• Declarar o que pode e o que não pode ser feito.
• Supor que profissiona is maduros precisem de pouco suporte ou reconheci-
mento de equ ipe.
• Limitar os contatos com os membros de equipe a reuniões e d iscussões
formais.
• Tratar problemas que afetem o desempenho de um membro de equipe como
responsabi lidade da gerência de áreas funciona is.
• Ajudar outros somente quando explicitamente solicitado.
• Ser a bertamente crítico sobre as contribuições ou atitudes de outros me1nbros
de equipe.
• Reconsiderar decisões quando os membros de equ ipe voltarem a toe.ar e1n
certas questões.
competência são:
• Os me1nbros de equipe podem não saber com clareza quais são as suas res-
ponsabil idades.
• Ind ivíduos importantes podem passar para outros projetos.
• Obstáculos e contratempos podem solapar os esforços de forma geral.
• Conflitos de prioridade em uma equipe de projeto podem subir até a gerência
sen1or.
• A responsabilidade pelo projeto pode se tornar difusa.
• Os membros de equipe pode1n relutar em oferecer suporte uns aos outros ou
e1n acomodar solicitações especia is.
10. Gerenciar a co1nplexidade: organizar, planejar e moni torar diversas ativida-
des, pessoas e recursos.
• Permanecer ca lmos quando estiver sob ataque pessoal ou sob ext rema pressão.
• Monitorar o progresso de maneira frequente e consistente.
• Focalizar-se e1n esforços pessoa is na ma ioria das tarefas críticas: aplicar a
regra do 80- 20'%.
• Docu1nentar cuidadosamente todos os compromissos e responsabilidades.
• Definir tarefas e atividades para todos para fins de monitoramente e de um
senso de progresso.
• Decompor as atividades e tarefas em componentes que pareça1n viáveis.

• Equil ibrar e otimizar a carga de trabal ho entre diferentes grupos e indivíduos.
• Reun ir rapidamente equipes especiais ou usar especialistas externos a fi 1n de
tratar de emergências ou ciscunstâncias incomuns.
• Fazer debriefing para identificar as " melhores práticas" e as" lições aprendidas".
Os gerentes de projetos/associados que não de1nonstram essa competência irão:
• Li1nicar o número de rev isões para maxim izar o tetnpo d isponível para os
me1nbros de equipe.
• Querer saber e.ada detalhe.
• Depender dos me1nbros de equ ipe para acompanhar seu próprio progresso.
• Dizer aos outros co1no se sentem e1n relação a um problema ou indivíduo.
• Depender da equipe para resolver problemas.
• Supor que os indivíduos reconhecem seus próprios erros e aprendetn com eles.
competência são:
• Os projetos podem receber níveis de atenção significativamente diferentes.
• Os projetos podem "adquirir vida própria" setn nenhuma direção e.Iara ou
resu ltado alcançável.
• A responsabil idade pelas decisões pode se tornar difusa entre os membros de
.
eqtupe.
• Pode ser difícil de detenninar o status exato dos projetos.
• Problemas sérios podem se tomar incracáveis.
• As atividades de diferentes partes do negócio podem não ser coordenadas.
• Conflitos podetn surgir continuamente entre a liderança do projeto e out ras
partes da Li lly.
11. Tomar decisões difíceis: demonst rar segurança em suas próprias habilidades,
julga1nentos e capacidades; assu1n ir responsabil idade por suas ações.
Os gerentes de projetos/associados que demonstram essa competência irâo:
• Questionar o modo co1no as coisas são feitas e tomar decisões quanto a co1no
as coisas serão feitas.
• Forçar os outros a lidarem co1n as real idades desagradáveis de uma situação.
• Forçar a reava liação de decisões cont roversas tomadas pela gerência quando
novas informações/dados são d ispon ibilizados.
• Chamar a atenção dos outros para problemas com impactos sign ificativos.
• Usar conscientemente experiências passadas e dados históricos para conven-
cer os out ros.
• Confrontar indivíduos que não estejam cumprindo seus compromissos.
• Estimular a gerência de área a substituir indivíduos que não atendam às suas
expectativas.
• Questionar o investimento continuado em um projeto se os dados sugerirem
que ele não será be1n -sucedido.
• Buscar ou adotar proced imentos inovadores que ofereçam possíveis benefí-
cios significativos mesmo quando a experiência anterior disponível for insu-
ficiente.
• Pronunciar-se contra as ideias de membros de equipe ma is experientes.
• Dar aos outros o benefício da dúvida en1 como de compron1issos não cun1pridos.
• Adiar a totnada de decisões até o último 1n inuto possível.

• Buscar diversas opções em vez de parar o trabalho para t raba lhar em aborda-
gens a lternativas.
• Esperar um suporte explícito dos out ros antes de tocar em problemas difíceis.
• Aceitar as decisões dos gerentes sênior como "indiscutíveis".
• Contar com a equipe para tomar decisões controversas.
• Dar mais recursos e tempo a indivíduos com problemas de desempenho.
competência são:
• Os projetos poden1 levar ma is tempo do que o necessário para serem con-
cluídos.
• Projetos em vias de fracassar podem ter mais tetnpo para continuar ativos.
• Decisões podem ser delegadas a níveis superiores.
• O 1nora l da equ ipe podetn ser solapado pelo mau desetnpenho de certos mem-
bros de equipe.
• "Más notícias" podetn não ser comunicadas até o último m inuto.
• Indivíduos importantes podem ficar frust rados devido ao esforço de sempre
precisar "correr atrás de prejuízos".
12. Construir o suporte estratégico: conseguir o apoio e nível de esforço neces-
sário por parte da gerência sênior e de outros para 1nanter o projeto no cami-
nho certo.
• Assumir responsabilidade por defender os projetos demonstrando, ao mesmo
tempo, um equ ilíbrio entre paixão e objetividade.
• Adaptar argumentos e apresentações para tratar as principais preocupações
de tomadores de decisões influentes.
• Fam iliarizar-se com as preocupações operacionais e de negócios das principais
funções da Lilly.
• Usar uma rede de contatos para determinar a melhor maneira de levantar utn
problema ou fazer uma proposta.
• Estimular o envolvimento ativo de ind ivíduos cotn a experiência e influência
necessárias para fazer as coisas acontecerem.
• Identificar a dist ribuiç.ã o de influência em situações de confl ito.
• Preparar o terreno antes de difundir ideias ou informações controversas.
• Selecionar apresentador para garantir que a mensagem adequada seja enviada.
• Pedir à gerência sênior para ajudar a posicionar questões com outros gerentes
sentar.
• Encontrar a gerência sênior e os patrocinadores de projeto apenas em reu-
niões formais.
• Propor grandes mudanças de direção em reuniões de grupo.
• Fazer contato cotn tomadores de decisões importantes quando estiver enfren-
tando obstáculos ou problemas.
• Limitar o número de contatos face a face com parceiros "globais".
• Tratar todos os indivíduos da mestna forma.
• Evitar o surgimento de "politicagem".
• Depender de outros membros de equipe para comunicar aos gerentes sênior
que se encontram em partes não famil iares da Lilly.
competência são:
• Projetos viáveis poden1 ser cancelados sem uma clara articu lação dos benefícios.
• "Diferenças culturais" podem limitar o successo de projetos globais.
• Decisões podem ser tomadas sem a contribu iç.ã o de invidíduos importantes
para elas.
• Resistência a mudanças no escopo ou direção do projeto pode1n se tornar
entrincheiradas antes de os méritos de propostas serem compreendidos.
• Indivíduos/organizações importantes podem nunca aderir à direção ou escopo
de um projeto.
• Pequenos conflitos podem se intensifica r e levar tempo para serem resolvidos.
8.13 Harris Corporation

Muitas vezes, as pessoas frequenta 1n se1ninários e cursos que levam a uma certificação
como PMP® e ficam iinpressionadas com os conhecimentos apresentados no curso.
Elas se questionam como é que qualquer corporação real izaria todas as atividades
abordadas nas informações apresentadas no curso e por que elas precisam aprender
todas essa informações.
En1bora seja verdade que muitas empresas não precisem rea lizar ou não reali-
zem todas as atividades que são abordadas, exige-se que as empresas cont ratadas
do setor aeroespacia l e de defesa realizen1 todas elas. Essas empresas sob reviven1
dependendo de seu sucesso ao desen1penhar p rocessos de gestão de projetos. Quan-
do empresas como a Harris Corporation tornam-se excepcionaln1ente boas em ges-
tão de projetos apresentam n1elhorias contínuas, elas passan1 a ter um desempenho
superio r ao de suas concorrentes. A Ha rr is Corporation possu i uma histó ria de
sucesso em gestão de projetos. O n1aterial restante desta seção foi fornecido por
Alex Sadowsk i da Harris Corporation.2 Ta lvez depois de ler o restante desta seção,
o leitor tenha un1a compreensão e apreciação maior de por que esse materia l está
sendo ensinado e todas as con1plexidades de se trabalhar en1 uma indústria cuja
sob revivência depende da n1anutenção de un1a capacidade superior de gestão de
proietos.
1. A filosofia funda menta l da gestão de projetos se aplica a todos os projetos, independen-
temente do tamanho e da indústria envolvida. Entretanto, cada indústria possui seu am-
biente e cultura singulares, e a aplicação da filosofia de gestão de projetos pode assumir
diferentes formas dependendo dessa singularidade. O a mbiente singular da indústria
aeroespacial e de defesa pode ser caracterizado da seguinte forma:
• O ambiente é d inâ mico
• O cronograma é, na maioria das vezes, agressivo
• Muda nças de cenário resulta m em mudanças nos requisitos
• Um gerenciamento de mudanças eficiente é absolutamente necessário
• Esta é a primeira vez que um projeto deste tipo está sendo realizado
• Na maioria dos casos, o conjunto de tecnologia é estend ido
i Alex Sadowski, PNlP• , é gerente de programas da Governmem Commun.icacions Syscems Division da Har·
ris Corporarion. Tem mais de 30 anos de experiência com uma base de clientes numerosa e diversificada,
incluindo várias organizações civis, govemamencais e militares. Suas atividades na área de gestão de projetos
são relacionadas aos negócios do espaço aéreo e da defesa. Ele também está envolvido com iniciativas para o
Harris Division. Process Group e para o Division Trainin.g Sreering Committee.
• Pa ra concluir o projeto, o desenvolvimento de novas tecnologias gera lme nte é

necessá rio
• Novas metodo logias precisam ser desenvolvidas
• A gestão de riscos é de máx ima importância
• Há informações patenteadas e/ou confidenciais em jogo
• Isso prejudica a co municação a berta
• Considerações de segurança afetam todos os aspectos d o projeto
• Focalizar-se demasiada mente em tecno logias novas e desafiadoras pode ca usar pro-
blemas com o gerenciamento de todo o projeto
• As exigências de a plicar novas tecnologias e desenvolver as existentes pode ser sobrepu-
1ante
• O segredo é aceita r o desafio tecnológico sem perd er contro le do custo e do c rono-
gra ma
2. Como uma empresa co nt ratada da indústria aeroespacial e de defesa, a Ha rris Corpo-

ration desenvolveu, ao longo dos anos, processos e procedimentos deta lhados q ue a bor-
d am todas as fases da gestão de projetos, desde a identificação de uma oportunidade até
sua conclusão fin al, liquidação e encerramento.
3. Esses processos e procedimentos são documentados co m grande nível de detalhamento
no sistema Command Media, e são regularmente promulgados po r meio de seminá rios,
cursos e reuniões gerais, sempre que apro priado.
4. Esse processo envolve muitos pontos de decisão (p.ex.: revisões pa ra decidir prosseguir/
não prosseguir, reuniões para decidir se devem o u não fazer uma proposta de licitação,
Red Teams de pro postas, revisões de precificação, revisões de incentivos à criação de
empregos, revisões regulares de programas, revisões dos requisitos dos s istemas, revi-
sões preliminares de design, revisões críticas de design, rev isões de colegas, revisões
de disponibilidade de pro duto, revisões de disponibilidade de testes, revisões finais do
cliente, encerramento do contrato, etc.)
S. O processos e metodologias são bastante extensos, mas há alguns poucos aspectos dessa
metodologia que fazem tudo se encaixa r e facilitam o sucesso do projeto.
6. Po r meio de muita experiências, às vezes bem penosas, desco brimos que o planejamento
deta lhado antecipado é a melhor a bo rdagem para alcançar o sucesso de projetos.
7. Muito frequentemente, há o perigo de que a exu berância excessiva d a equipe de projeto
e a impaciência d o cliente resulte em um curto -circuito do planeja mento antecipado.
Essa é a receita para o desastre!
8. Um planeja mento adequado deve se basear na co mpreensão do que o cliente contratou,
o preço q ue ele concordo u em pagar e a data em que ele espera ver a conclusão.
9. Um Plano de Projeto a brangente pre.cisa ser desenvolvido antes de a equipe de projeto
completa estar engajada.
10. Um planejamento eficiente depende do seguinte (ver Figura 8-4):
Plano de
gestão de
Específicação riscos
de Trabalho
(ET)
Estrutura Cronograma Sistema de Geração de
Analítica do Integrado do Gerenciamento status e controle
Projeto Projeto (CIP) do Valor Agregado do projeto
(EAP) (SGVA)
Definição
de requisitos ...----..__/'
Plano de
gerenciamento de
mudanças
Figura 8-4 Passos de um planejamento eficiente.

• Estrutura Ana lítica do Projeto (EAP)

• Cronograma Integrado do Projeto (CIP)
• Sistema de Gerenciamento do Valor Agregado (SGVA)
• Planejamento do Gerenciamento de Mudanças
• Planejamento da Gestão de Riscos
11. Tanto a Espe.cificação de Trabalho (ET) q uanto o Documento de Req uisitos dos Siste-
mas (DRS) são usados para desenvolver a Estrutura Ana lítica do Projeto (EAP).
• A ET identifica o q ue deve ser feito, q ualquer restrição, q ua lquer ponto de decisão
especial para o cliente, os deliverables e o prazo do projeto.
• O DRS é a definição oficial dos requisitos sobre a q ua l se baseiam os aspectos técnicos
do projeto. Isso é usado para garantir que a funcionalidade necessária seja alcançada.
12. A EAP documenta os deta lhes do que precisa ser alcançado.
• Decompõe o projeto em s uas partes essenciais.
• Fornece a base para designa r ta refas e responsabilidades.
• É uma estrutura hierárquica q ue mostra como as tarefas de cada indivíduo contri-
buem para a tarefa de ordem maior.
• Essas tarefas ind ividua is são essenciais ao definir o cronograma e ao estabelecer o
SGVA do projeto.
• Desenvolve-se um d icioná rio da EAP definindo cada ta refa e q uem é responsável por
ela.
13. Gerenciamento de mudanças
• Mudanças são inevitáveis em q ua lquer projeto.
• Algumas mudanças não têm nenhum impacto maior sobre o projeto.
• Algumas mudanças podem ter um efeito drástrico sobre os custos, os cro nogramas o u
sobre a integridade técnica do esforço. Às vezes todos esses três são afetados.
• É preciso desenvolver um plano que possibilite:
• a identificação de mudanças
• o impacto das mudanças
• como essas mudanças devem ser tratadas (aceitas o u rejeitadas)
• como as mudanças são negociadas com o cliente
• como podem ser feitas mudanças no contrato e por q uem
14. Gestão de riscos
• Todos os projetos têm riscos
• Um risco é q ualquer coisa que pode afetar o resultado bem-sucedido de um programa
• Um risco pode afetar:
• Custos
• Cronogramas
• Integridade técnica (p.ex.: funciona lidade, confiabilidade, etc.)
• Se um risco não for resolvido, ele se torna um problema.
• Nas etapas de pla nejamento iniciais de um projeto, os riscos precisam ser identificados.
• É preciso desenvolver um pla no que aborde:
• A identificação de riscos
• A definição de sua severidade
• A definição da probabilidade de ocorrência
• A definição do impacto sobre o sucesso do projeto (i .e., custo, cronograma, etc.)
• Classificação de riscos
• Mitigação de riscos
• Extinção dos riscos
15. O Cronograma Integrado do Projeto (CIP)
• Deta lha o cronograma de atividades do projeto do início ao fim
• Mostra as datas de início e fim das atividades d iscretas individ ua is
• Mostra as inter-relações de todas as a tividades individuais

• Identi fica o caminho crítico
• Identi fica todos os ma rcos críticos
16. Sistema de Gerenciamento de Valor Agregado (SGVA)
• Facilita o acompanhamento do progresso de atividades individuais no que diz respei-
to ao cronograma e à aderência aos custos
• Mostra o bjetivamente que tarefas estão dentro d o prazo e se e las estão dentro d o
o rça mento
• Fornece um meio de ava lia r continua mente se um projeto está o u não dentro d o
prazo e do o rçamento
17. Geração de status e contro le d o projeto
• Para qua lquer projeto ser bem-sucedido, a geração contínua de status do projeto e seu
controle é essencial.
• De maneira geral, relatórios d o SGVA devem ser gerados e revisados todo mês. Para
projetos
.
problemáticos
. .
o u de a lto risco, uma geração de status semanal via SGVA
sen a o ma is vanta1oso.
• O SGVA fornece uma metodologia conveniente, precisa e contínua pa ra determinar
o progresso de um projeto.
• Qua nto ma io r o esforço dedicado à EAP e ao CIP, ma is precisas serão as informações
o btidas co m o SGVA.
• Marcos rea listas e significa tivos, a bo rdando suficientemente todas as ta refas, são es-
senciais para o uso bem-sucedido d o SGVA.
• Os ma rcos podem ser acompanhad os periodicamente (i.e., norma lmente co m fre-
quência mensal, mas muitas vezes semanal, se necessário) .
• Uma vez que o a lca nce dos marcos tenha sido considerado, então pode-se a lca nçar a
geração de status de cronograma e custo.
• A geração d o Índice de Desempenho de Prazo (IDP) (SPI, o u schedule performance
índex ) fornece uma medida o bjetiva de se o projeto está o u não dentro do prazo.
• A geração do Índice de Desempenho de Custo - IDC (CP!, o u cost per(orma11ce ín-
dex ) fornece uma medida objetiva de se o projeto está ou não dentro do orça mento .
• Uma nova Estimativa pa ra Terminar (EPT) (ETC, ou estimate to complete) deve ser
gerada regula rmente (i.e., na geração de status mensal) e comparada ao O rçamento
no Término (ONT) (BAC, ou budgeted-Gost at completion ).
• Discrepâncias entre a EPT e o ONT devem ser ana lisadas e reconciliadas. Um resul-
ta do deve ser implementar um plano pa ra fazer o programa voltar ao caminho certo.
Um SGVA bem implementado é uma ferra menta de gerenciamento muito poderosa para o
gerente de projetos.
• Ao considerar o valor do IDP, o gerente de projetos saberá se o projeto irá c umprir o
cronograma.
• Se o va lor for menor do que 1, o GP saberá que o projeto está a trasado e terá de de-
terminar que tarefas estão ficando para trás e por quê, de modo que ações corretivas
apropriadas possam ser adotadas.
• Se o valo r for maior do que 1, isso indica que o projeto está adiantado. Não se deve
comemorar demais nesse momento, uma vez que essa pode ser a penas uma sit uação
temporária. Se o valor for muito maior do que 1, isso pode indicar um pro blema na
estimação e planejamento o riginais, o que exige uma aná lise d etalhada.
• Ao considerar o valor do IDC, o gerente de projetos saberá se o projeto ficará dentro
d o orçamento.
• Se o valor for meno r do que 1, o GP sa berá q ue o projeto está ultrapassando o or-
çamento e precisará determin ar que ta refas estão excedendo o o rçamento e po r quê,
para que ações corretivas possam ser a dotadas.
• Se o valor for ma ior do que 1, isso sign ifica que o projeto está dentro do o rçamento.
Deve-se toma r c uidado, uma vez q ue essa pode ser a penas uma situação temporária .
Se o valor for muito maior do que 1, provavelmente é porque há algum problema

com a estimação e planejamento originais, e uma análise detalhada deve ser feita para
determinar o porquê dessa d iscrepância.
• Quando o projeto é planejado, estabelece-se um orçamento. O custo orçado do pro-
jeto é o que se espera ter sido gasto na conclusão do projeto e é o ONT. Com o
prosseguimento do projeto, custos reais são incorridos. Ao revisar os custos reais e
considerar o que a inda pre.cisa ser feito, o GP pode, então, chegar à Estimativa até a
Conclusão.
• Ao comparar a EPT e o ONT, a Variação no Término (VNT) (VAC, variance at com-
p/etion) pode ser calculada. A VNT indica se o projeto excederá o orçamento ou se
ficará dentro do esperado.
• Se a VNT indicar que o projeto irá exceder o orçamento, é necessário realizar uma
investigação e análise para identificar o problema . Então, será preciso adotar algum
curso de ação a fim de mitigar o problema.
18. No ambiente exigente e dinâmico dos projetos aeroespaciais e do governo, o uso de um
sistema de gerenciamento de valor agregado bem definido e integralmente implementa-
do pode oferecer a metodologia necessária para manter o projeto dentro do cronograma
e do orçamento.
8.14 Alcatel-Lucent: reconhecendo o valor de um PMP®

Mu itas vezes, as empresas deixam de tirar proveito da propriedade intelectua l retida
pelos PMPs® e, da mesma forma, não consegue1n recon hecer a contribuição iue eles
podem fazer para a e1npresa. Algumas empresas t ratam as credenciais do PMP , co1no
a lgo a ser colocado embaixo do nome deles em um cartão de visitas como pa rte de
seus esforços competitivos de licitação. Algumas empresas até mesmo oferece1n finan-
ciamento para progra1nas de treinamento para obter as credencia is por 1nedo de que
os traba lhadores procurem emprego em outras empresas que ofereçam mais oportuni-
dades aos funcionários de aprofundar sua formação em gestão de projetos.
No entanto, quando empresas como a Alcacel-Lucent reconhece1n o valor que um
PMP® pode t razer para a empresa, pode haver u1n enorme retorno sobre investimen-
tos (RO i) sobre os PMPs®. O ROi pode ser visto na fo nna de 1nentoria oferecida a
gerentes de projetos que pretendem se tornar PMPs®ou que desejem obter certificação
de suas credenciais, um consel ho consultivo ou linha d ireta para projetos que estejam
com dificuldades, ou simples1nente do estabelecimento de uma rede global de informa-
ções sobre gestão de projetos, de modo que todos os funcionários em todo o mundo
compreendam os desenvolvimentos acuais e melhores práticas da empresa relativas à
Boas coisas acontecem com empresas que, como a Alcacel-Lucenc, reconhecem o
va lor de um PMP®. Segundo Rich Maltzman, PMP®, gerente sên ior do PMO globa l da
Alcacel-Lucent:
A Alcatel-Lucent procurou a umentar a maturidade do GP estabelecendo e implementando
uma estrutura integrada de desenvolvimento dos GPs, incluindo um plano de carreira dedi-
cado no qual descrições de cargo são inteligadas a um sistema de gerenciamento de recursos
e habilidades d iretamente ligado às opções de desenvolvimento, como os cursos dedicados
a GPs. A empresa também ofereceu aos seus GPs uma sofisticada Estrutura de Entrega para
ajudá-los a implementar e governar projetos, med ir e gerenciar riscos e gerenciar as finanças
dos projetos. Essas estruturas oferecem a plataforma fundamental para alcançar a maturi-
dade em GP. Em particular, um grupo de foco de PMPs" assumiu um papel d inâm ico para
oferecer suporte a futuros PMPs" e a PMPs" existentes a fim de facilitar o credenciamento
de GPs e de ajudar os PMPs" existentes não somente a reter seus PMPs" , mas fazê-lo de uma
maneira extremamente prod utiva para seus colegas.
A equipe, q ue foi a utointitulada PN!-CERT for PN!-Continuing Education and Recer-

tification Team, se reúne semana lmente e se focaliza em d iversos esforços para cumprir as
metas previstas em seu título. Embora seja uma equipe ad hoc, trabalha conjuntamente com
o PN!O Global e a Akatel-Lucent University (um Centro Registrado de Treinamento junto
ao PMJ), ambos os qua is são representados na eq uipe. Vejamos algumas das principais
atividades do PM-CERT.
Grupos de estudos de PMPs®
Desde o in ício dessa in iciativa, foram estabelecidos em torno de 30 grupos de estudos de
PMPs" . Esses são separados por regiões com mesmo fuso horá rio com em torno de I O mem-
bros cada, que estudam colaborativamente para o exame de PNIP11 sob a tutela de um ins-
trutor. Esse instrutor tipicamente é um PNlr" recém-credenciado. Encontrando-se com uma
freq uência determinada pelo grupo e traba lhando no idioma em que a maio ria dos membros
espera fazer o teste, os Grupos de Estudo usam os mesmos materiais e treinam a matéria jun-
tos de acordo com um c urrículo modelo estabelecido pela eq uipe do PM-CERT, mas adapta-
do para as necessidades daquele grupo específico. Um site especial com uma Sala de Estudos
foi estabelecido espe.c ificamente para essas eq ui pes fazerem perguntas, compa rtilharem des-
cobertas e, e claro, postar o fato de que passaram no exame! Os a lunos recebem 30 horas
de tempo de contato, q ue contribui com a maior parte do q ue é necessá rio para a aplicação
do exame e o instrutor pode exigir as valiosas Un idades de Desenvolvimento Profissiona l
(PDUs, Pro(essio11al Development U11its) em virtude de seus serviços como instrutores.
Instrutores e a lunos rela tam q ue essa é uma experiência en riquecedora declarando, por
exemplo, q ue os Grupos de Estudos "me permitiram encontrar o utros GPs com formações
em diferentes áreas e trocar experiências com eles. Isso me ajudou a me to rnar um GP mais
forte, usando os con hecimentos obtidos a partir dessas várias formações".
Boletim informativo
Há vários anos, a equi pe do PM-CERT tem p ublicado um boletim informati vo period ica-
mente, mas pelo menos trimestralmente, com histórias sobre gestão de projetos, notícias de
novas oportunidades de obter PDUs, perfis de projetos e anúncios de eventos relacionados
ao GP em todo o mundo. Ela já atingiu em torno de 500 assinantes. Hoje, a equipe do PM-
-CERT usa um blog corporativo q ue se encontra na plataforma de míd ia social Engage da
Alca tel-Lucent para distribuir notícias e informações.
Simpósio do Dia Internacional do GP
A Akatel-Lucent decid iu celebrar o Dia Internacional do GP realizando o Simpósio do Dia
Internacional do GP. Trata-se de uma web-conferência com conectividade por telefone e ví-
deo. Ocorre desde 2007, com uma participação de em torno de mil pessoas cada. Determina-
-se um tema para o Simpósio, e os apresentadores enviam propostas que serão selecionadas
por um comitê do PM-CERT para uso na sessão. Temas passados incluem "Uma gestão de
projetos sign ificativa • e "Gestão de projetos - uma d iferença do tama nho do m undo". Os
apresentadores de seis a o ito países d iferentes compartilham lições aprendidas ou abordam
uma á rea de conhecimento da gestão de projetos, como gestão de riscos. Além d isso, há pa-
lestrantes convidados, como autores notáveis como o De Ha rold Ken.ner e Jean Binder (ven-
cedora do Prêmio David Cleland do PMI), o Dr. Cha rlie Pellerin da NASA, ou executivos do
PMI. O Simpósio foi registrado junto à Alcatel-Lucent Un iversity, e os a lunos recebem seis
PDUs por sua presença. Essas sessões são arquivadas e tornam-se continuamente disponíveis
por meio da Alcatel-Lucent University.
Disponibilizando as PDUs - Centro de Aprendizagem
Novamente trabalhando com a Alca tel-Lucent University, o PN!-CERT ajudou a estabelecer
o Centro de Aprendizagem de GP - um site rico em recursos com dicas de como se inscrever
no exame de PMP'", como manter sua c redencia l uma vez tendo-a obtido, leituras e cursos
sugeridos e links para os grupos apropriados da Comunidade de Prática Engage de GPs e
para as grades curriculares dos cursos de GP.
Mesas-redondas
O PM-CERT patrocina bimestralmente "Mesas-redondas de dicussão" conversas telefôni-
cas de uma hora de d uração, no horário de a lmoço, focalizadas em determinado assunto e
liderado por um especia lista interno o u externo à Alcatel-Lucent. As sessões são casuais e
dão ao aluno um PDU.
Inspiração do PMP-CERT
A equipe do PM-CERT também inspirou o utras atividades de GP. Baseado parcialmente no
sucesso do PM-CERT, o Grupo da Comunidade de Prática Engage de GPs da Akatel-Lucent
é muito ativo, abordando tópicos de interesse geral para os GPs e subiu no ranking, tor-
nando-se um dos grupos corporativos ma is populares da Engage. Baseado nesse sucesso, a
empresa agora está começando a usar isso como um modelo para outras disciplinas e perfis
de cargos na empresa, como uma maneira de promover aprendizagem e compartilhamento
de conhecimentos na comun idade de prática.
8.15 Gestão de projetos integrada

na Tech Mahindra Ltd.
O termo "integração" possui vários significados, seja usado em relação a TI, engen ha-
ria, sociologia ou economia. Integração é u1n processo de combinar vários elementos e
também inclui princípios de gerenciamento e controle, além de reunir todos os compo-
nentes. A Tech Mahindra Ltd. descobriu um uso interessante da integração para reunir
todos os elementos necessários para treinar e formar gerentes de projetos. O restante
do material desta seção fo i fornecido por Hirdesh Singhal, Tech Mahindra Ltd. Lear-
ning World, Tech Mahindra Ltd.
A Tech Mahindra Ltd. gerencia projetos de serviços de TI em todo o mundo. Para gerenciar
o rápido crescimento e preencher a lacuna entre demanda e oferta de recursos humanos
q ualificados na organização, era crucial q ue a Tech Mahindra Ltd. a umentasse rapidamente
o número de gerentes de projetos internamente q ue pudesse gerenciar projetos eficientemen-
te e atendendo às expectativas de várias partes interessadas de forma lucrativa.
Havia uma Estrutura de Desenvolvimento de Competências em Gestão de Projetos dis-
ponível na Tech Mahindra Ltd. que se focalizava em tornar os vários papéis do processo de
entrega eficientes e prepará-los para assumir o papel seguinte. Essa estrutura era a linhada
à Estrutura de Desenvolvimento de Competências de Gerentes de Projetos do PMI, EUA.
Com esse histórico, desenvolveu-se a prática de Gestão de Projetos Integrada (1PM,
lntegrated Project Ma11ageme11t ) para líderes do projeto, a linh ada à Estrutura de Desen-
volvimento de Competências de Gerentes de Projetos de modo que eles sejam rapidamente
preparados para assumir o papel de GP.
A prática foi desenvolvida com as seguintes metas:
• Criar gerentes de projetos mais rápido do que a concorrência
• Economizar custos reduzindo a contratação de GPs externos
• Aproveitar os conhecimentos e habilidades de líderes de projeto existentes para criar GPs
• Reduzir o tempo de ciclo para receber um GP no projeto
• Tomar os novos GPs eficientes desde o primeiro dia em seu trabalho
• Preparar associados existentes para assumir responsabilidades de mais a lto nível
• Motiva r os associados a permanecerem na empresa por mais tempo
Alguns dos diferenciadores da prática da gestão de projetos integrada in cluem:
• Aprendizagem holística a aspirantes a GPs, o que não somente incl ui processos e ferra-
mentas de gestão de projetos, mas também gerenciamento e comportamento, cultura e
idiomas
• Certificação da Comunidade de Usuários - líderes das Unidades de Entrega, integrado-

res de entrega/gerentes de programa são envolvidos no ciclo e avaliam e certificam os
participantes em sua disponibilidade para assumir o papel de GP
• Projetos de aprendizagem de ação - durante o curso, forne.ce uma profunda compreen-
são sobre q uestões de entrega
• Livro de registro d iário de aprendizagem para o Plano de Desenvolvimento Pessoal após
a conclusão do programa
O processo de design é exibido na Figura 8- 5
Seleção de participan tes:
• Ter mais de o ito anos de experiência em projetos
• Ter gerenciado uma equipe de pelo menos 10 pessoas
• Indicação de habil idades para assumir res ponsabil idades de ma is a lto nível - um
(eedback do sistema de gerenciamento de desempenho
Tínhamos afirmado q ue a experiência de aprendizagem da gestão de projetos precisa
ser somada a uma experiência de aprendizagem sobre compo rtamento e sobre gerencia-
mento e liderança para produzir gerentes de projeto s uperio res. Os participantes podem
compreender claramente os processos que precisam seguir, as ferramentas que precisam
usar e várias técnicas de gerenciamento que podem ajudá-los a gerenciar melhor o projeto.
Para melhorar o comportamento, eles fizeram dramatizações e simulações para praticar e
demonstra r a mudança no comportamento durante o programa . A prática tirou proveito
de vários programas de treinamento e conteúdos que existiam na un iversidade da empresa.
A Tech Mahindra Ltd. integrou os dados das Ta belas 8-3 e 8-4.
Uma das facetas importantes da excelência na entrega é tornar os gerentes de projetos pro-
dutivos desde o primeiro dia. Eles não só aprend iam d urante o d ia, mas, ao fim do d ia,
tinha m de preencher seus Livros de Registro de Aprendizagem, indicando o que eles tinham
aprendido bem e o que precisavam aprimorar ou praticar ma is. Isso também os ajudava a
desenvolver seu plano de desenvolvimento de longo prazo.
A estrutura da empresa baseia-se em uma premissa essencial de colaboração. Havia uma
forte colaboração entre as diferentes fuções da empresa. Ver Figura 8-6.
Levantamento de informações Lançamento do programa Certificação incluindo

sobre as competências dos GPs com introdução de projeto de aprendizagem
alto impacto de ação
Avaliação SPMP
Criação do conteúdo dos

cursos do programa Condução do programa
de 15 dias de duração Cerimônia
de graduação
Validação do conteúdo dos

cursos e dos critérios de avaliaçã
com líderes sênior da entrega
(integradores de entrega/
gerentes de programas)
Incorporação do teedback
e finalização do colateral
Figura 8-5 O processo de design.

TABELA 8-3 Programas de treinamento em gestão de projetos
S Nº Nome do curso Duração Modo de instrução

1 Práticas de gestão de projetos da Tech Mahindra Ltd. 3 dias ILT
2 Processos e ferramentas de GP 2 dias ILT
3 Estimações via soffware usando pontos de função 2 dias ILT
4 Gestão de riscos 5,5 horas V-learning
5 Conceitos e técnicas fundamentais de estimação 6,5 horas V-learning
6 Soffware de mensuração e métrica de projetos 4 horas V-learning
7 Gerenciamento de todo o ciclo de vida de projetos 1 dia ILT
TABELA 8-4 Programas de gerenciamento, comportamentais e de liderança
S Nº Nome do curso Duração Modo de instrução

1 Simulação de desafio de negócio 2 dias ILT
2 Presença executiva 1 dia ILT
3 Ferramentas de gerenciamento de conflitos 1 dia ILT
4 Habilidades de interação com o diente 1 dia ILT
Learníng World
• Comportamental
• Gerenciamento
• Liderança
Qualidade
, Processos
-.... __-- ...... _
• Ferramentas -------------- ....... _
• Estimação ---- . ... --- Gestão de
projetos integrada
Centro de liderança em
Tempo Real
• Govemança
, Medidas
Alocação de recursos
• Seleção
• Designação
Figura 8-6 Gestão de projetos integrada.
• Várias escolas da universidade da empresa se reuniram para criar e colocar em prática

o programa que abordava a gestão de projetos e os componentes comportamenta l, de
gerenciamento geral e de liderança.
• O Centro de liderança em Tempo Real ajudou com ideias sobre med idas e a tributos em
que um GP precisa se focalizar ao gerencia r projetos.
• A função de Q ualidade contribuiu com ideias sobre os p rocessos e ferra mentas de GP

na organização.
• A Equipe de Alocação de Recursos designou os participantes, casando demanda e oferta
de GPs em toda a empresa .
A colaboração da l earning World da Tech Mahindra ltd. com o utras funções da orga-
nização.
Principais lições:
1. O sucesso da prática depende, em grande parte, da seleção dos participantes certos para
o programa. O envolvimento dos usuá rios e das unidades de negócios é crucial para o
resultado positivo.
2. Esse programa ajudou os participantes a aprenderem todos os aspectos necessários para
desempenharem o papel de GP.
3. Cria r um programa holístico para um gerenciamento completo de todas as partes inte-
ressadas. Assim, inclui aspectos de gerenciamento, comportamentais e de liderança.
4. A va lidação da forma e do conteúdo do programa pelos usuários nos ajuda a to rnar o
programa eficiente desde o primeiro d ia.
5. Os projetos de Aprendizagem de Ação focalizavam-se em questões fundamentais na en-
trega de projetos. As q uestões q ue não fossem signficativas seriam removidas. Esses as-
suntos foram identificados por meio de uma pesq uisa com os líderes sênior de entrega.
6. Um forte apoio e pa trocínio pelos executivos sênio r para a prática é um dos elementos-
-chave do sucesso.
7. Ter pré-requisitos antes dos participantes chegarem ao programa a umenta sua eficiência
e fornece ma is tempo para os pa rticipantes praticarem juntos em sala de a ula e aprende-
rem uns com os out ros.
A qualidade do treinan1ento e da formação em gestão de projetos que os fu ncioná-
rios de un1a en1presa recebem é, juntamente com a adesão dos executivos, um dos
fato res mais importantes para se alcançar o sucesso e, em últin1a análise, a excelência
em gestão de p rojetos. O t reina mento pode ser tanto para os funcionários da em-
presa q ua nto para seus fornecedores, que precisa m interagir com a metodologia de
gestão de p rojetos do cliente. Vejamos algu ns exemplos de progran1as de treina men-
to eficientes.
A Hewlett-Packard está claramente comprotn etida com o desenvolvi meno de p ro-
gramas e da gestão de projetos. Segundo J im Crotty, líder da profissão de gerencia-
mento de programas nas Américas:
Desenvolvimento de G Ps
A HP Services possui um abrangente Programa de Desenvolvimento de Gerenciamento de
Progra mas (PMDP, Program Ma11ageme11t Developme11/ Program) com cursos q ue abordam
todos os aspectos do treinamento de gestão de projetos e progra mas. Uma grade curricular-
-padrão com mais de 100 cursos foi implementada em todo o mundo por meio da lide-
rança em programas/projetos, gerenciamento, comunicação, gestão de riscos, contratação,
gerenciamento de desempenho de negócios, geração de cronogramas e controle de custos
e q ualidade. Os cursos são baseados no corpo de conhecimentos de gestão de p rojetos do
PNll (Guia P,WBOK"'). A grade curricula r engloba também c ursos especia lizados sobre os
principa is tópicos internos da HP, como a Metodologia de Programas, além de aspectos
essenciais do gerenciamento de negócios e financeiro dos projetos.
Todos os c ursos oferecidos na grande curricular do PN!DP da HP são registrados junto
ao Programa de Centros Registrados de Treinamento (REP, Registered Eáucatio11 Provider),
para garant ir uma base e uma supervisão consistentes. O PMDP ganhou um prêmio de
Excelência na Prática em desen,•o lvimento de carreira e aprendizagem o rganizaciona l da

American Society for Training & Development (ASTD), o recurso líder mundial em apren-
d izagem no trabalho e em problemas de desempenho.
Mesmo os GPs mais experientes d a HP cont inua m as a tividades de desenvolvimento
para reforça r seus conhecimentos e ha bil idades. A HP Services pa trocina o Progra ma da
Universidade de Gestão de Projetos (PMU, Program Ma11ageme11t U11iversity). A PMU co n-
siste em simpósios de cinco dias em cada uma das principais regiões geográficas (Américas,
Ásia/Pacífico e Europa) e um d ia de eventos realizados nos escritórios da HP. Esses eventos
oferecem aos gerentes de projetos uma oportunidade de dedica r um tempo concentrado
para estudar e troca r conhecimentos e ideias com outros gerentes de projetos da HP de todo
o mundo e em sua á rea geográfica loca l. A PMU foi reconhecida por sua excelência pela
ASTD e pelo Plvll.
Certificaçã o de PMP.,
A HP possui um programa bem estabelecido para encoraja r e a po ia r nossos gerentes de
projetos a obter a certificação. A HP Services possui ma is de 5 mil indivíduos q ue obti,•era m
certificação de PMP"' (Profissiona l de Gestão de Projetos) junto ao PMI®.
Suporte do PMI
A HP a poia ativamente o Instituto de Gestão de Projetos (PMI"), uma o rganização sem fins
lucrativos com ma is de 265 mil membros. O PMI'" estabeleceu padrões para a excelência
em gestão de projetos que são reconhecidos pela indústria e por nossos clientes em todo o
mundo.
Os funcionários da HP pa rticipam de di versos conselhos e comitês no PMI'", inclusive
d o Conselho Corporativo G lo ba l (Global Corpora/e Com,âl), o Cent ro de Acreditação
Global (Global Accreditatio11 Ce11/er), o Grupo Cons ultivo de Membros de Programas de
Pesquisa (Researcb Program Membersbip Advisory Gro11p), o desenvolvimento d o Asso-
ciado Certificado em Gerenciamento de Programas (Certi(ied Associa/e in Projec/. Mana-
geme11t, CAPM), o desenvolvimento de Certi ficados de Qua li ficação Adicional (Certi(icates
o( Added Q11ali(icalio11, CAQ ) em Sistemas de TI, Redes de T I e escritó rio de gestão de
projetos, a revisão d o G11ia P,WBOK"', e as Equipes d e Atual ização d o G11ia PMBOK"'.
Muitos funcioná rios da HP ocupam cargos de liderança nos Capít ulos d o PMI'" e G rupos
d e Interesses Especia is em todo o mundo.
Gestão informal de projetos
9.0 Introdução
Nos últi1nos 25 anos, uma das muda nças mais significativas na gestão de projetos foi
a ideia de que a gestão informal de projetos funciona. Nas décadas de 1950 e 1960,
as indúst rias aeroespacial, de defesa e de const ruções de gra nde porte eram as pri n-
cipais usuárias das ferra mentas e técnicas da gestão de projetos. Como se t ratava u1n
processo de gerenciamento relativa mente novo, os clientes das empresas contratadas
e subcontrata das queria1n evidências de que o sistema funcionava. A documentação
das políticas e procedimentos a sere1n usados passaram a fazer parte da proposta por
escrito. A gestão fo rmal de projetos, sustentada por centenas de políticas, procedi-
mentos e formulários, tornou-se a norma. Afinal, por que um cliente potencial estaria
disposto a assinar um contr ato de US$10 m ilhões para um projeto ser gerenciado
informa lmente?
Este capítulo esclarece a diferença entre gestão de projetos informa l e fo rmal, e
então discute os q uatro elementos essenciais da gestão informal de projetos.
9.1 Gestão de projetos informal versus formal

A gestão forma l de projetos semp re foi cara. Em seus primórdios, o tempo e os recur-
sos gastos na preparação de políticas e procedi1nentos por escrito tinham um propósi-
to: tranquilizar o cl iente. À medida q ue a gestão de projetos foi se estabelecendo, foi-
-se cr iando uma documentação forma l p rincipalmente pa ra o cliente. As contratadas
começaram a gerencia r mais informalmente, enquanto o cliente a inda estava pagando
pela documentação de uma gestão fo rmal de projetos. A Tabela 9- 1 most ra as pri n-
cipais diferenças ent re a gestão de projetos formal e informal. Como podemos ver, a
diferença ma is relevante é a quantidade de papelada .
TABELA 9-1 Gestão de projetos formal versus informal
Fator Gestão formal de projetos Gestão informal de projetos

N lvel do gerente de projetos Alta Baixa a média
Autoridade do gerente de projetos Documentada Implícita
Papelada Exorbitante Mlnima
Gestão de projetos convencional Gestão de projetos

com engenharia
simultânea
Fases do Manuais de Diretrizes por Diretrizes Listas de verificação

ciclo de vida políticas e fase de ciclo gerais do com pontos de
procedimentos de vida projeto revisão periódica
Década de 1970 Início da década Meados da década Fim da década Década de 1990
de 1980 de 1980 de 1980
Figura 9- 1 Evolução das políticas, procedimentos e diretrizes. Fonte: Reímpresso de

H. Kerzner, ln Search of Excel/ence ín Project Management, Hoboken, NJ: Wiley, 1998,
p. 196.
Custa caro manter a papelada. Até mesmo uma apostila rotineira de uma reunião
de equipe pode custar entre US$500 e US$2 mi l por página pa ra ser preparada. Exe-
cutivos de empresas excelentes se comunicam sem quantidades excessivas de papel.
Eles encorajam as equipes de projetos a se co1nunicarem sem quantidades excessivas
de papel. Entretanto, a lgumas pessoas a inda opera tn sob a crença errônea de que a
certificação ISO 9000 exige uma enorme papelada.
A Figura 9- 1 most ra as mudanças nos requisitos de papelada em gestão de proje-
tos. O início da década de 1980 marcou o auge dos amantes da documentação em pa-
pel. Naquela época, o típico manua l de políticas e proced imentos provavelmente cus-
tava ent re US$3 milhões e US$5 m ilhões para prepa rar inicia lmente e de US$1 mi lhão
a US$2 1nilhões para atualizar anualmente ao longo da vida do projeto de desenvolvi-
mento. Os gerentes de projetos se afundavam em formulários a serem preenchidos, ao
ponto de ter muito pouco tempo sobrando para rea lmente gerenciar os projetos. Os
clientes começaram a reclamar do alto custo da subcontratação, e o boom da papelada
começou a perder força.
As verdadeiras econotnias de custo não se materia lizaram até o início da década
de 1990, cotn o cresci tnento da engenharia simu ltânea. A engenharia si1nu ltânea en-
curtava os tempos de desenvolvimento de produtos passando a realizar em para lelo
atividades que antes eram rea lizadas em série. Essa 1nudança au1nentou o nível de
risco etn cada projeto, o que exigia que a gestão de projetos se afastasse de a lgumas
de suas antigas práticas. Diret rizes formais foram substituídas por listas de verificação
menos detalhadas e mais genéricas.
Políticas e procedimentos representavam formal idade. Listas de verificação re-
presentavam informalidade. No entanto, a informalidade não eliminava totalmente
a papelada dos projetos. Ela reduzia os requisi tos de papelada a níveis minimamente
aceitáveis . Passar da forma lidade à informal idade exigia uma mudança na cultura
organizaciona l (ver Figura 9- 2). Os quatro elementos fundamenta is de uma cu ltura
informal são os seguintes:
Capítulo 9 Gestão informal de projetos 441
Gestão formal de projetos Gestão

informal de
Magnitude relativa da documentação projetos
Manuais de políticas Diretrizes por fase Diretrizes Listas de verificação para

e procedimentos do ciclo de vida por projeto : revisões de passagem de fase
'
Questões c(Jticas
• Conflitos de alta • Concorrência contínua • Memorandos • Confiança
intensidade por recursos de proteção • Comunicação
• Resistência à • Mudança constante • Atrasos no • Cooperação
geração de múltiplos de prioridades cronograma • Trabalho em equipe
relatórios para os chefes • Baixa motivação • Aumentos graduais • Desenvolvimento de
• Confiança nas políticas no escopo uma metodologia
e procedimentos • Fases do ciclo de vida
• Patrocinadores invisíveis • Treinamento nas
• Problemas de habilidades centrais
poder/autoridade
• Reuniões muito
frequentes
Trajetória geral da maturidade - - - - - - - - - +
Figura 9- 2 Evolução da papelada e mudança dos níveis de formalidade. Fonte: Reimpres-

so de H. Kerzner, ln Search of Excel/ence in Project Management, Hoboken, NJ. Wiley, 1998,
p. 198.
• Confiança
• Comunicação
• Cooperaç.ã o
• Traba lho em equipe
Empresas grandes 1nuitas vezes não conseguiam gerenciar projetos informalmente
apesar de quererem. Quanto maior a empresa, ma ior a tendência de a gestão formal
de projetos assumir o contr ole. U1n antigo vice-presidente de operações de vendas e
1
serviço de atend imento ao cliente da Norte! Networks, acred ita que:
A introdução dos padrões de processos e ferramentas de projetos em toda a empresa na
Norte! Networks e o uso de métricas pipeline (medidas que seguem normas da indústria
definidas pelo cliente) fornece uma estrutura para a gestão formal de projetos. Isso é neces-
sário dada a complexidade dos projetos de telecomunicações que empreendemos e a neces-
1
H. Kerzner, Project Ma11ageme11t Best Practices: Achieving Global Exce/Jence, Hoboken, NJ: \Viley, 2006,
p. 329.
sidade de uma solução integrada em um curto espaço de tempo. O gerente de projetos da

Norte! Networks cruza muitos limites organizacionais para alcançar o s resultados exigidos
pelos clientes em um ambiente dinâmico.
A maioria das empresas gerencia fonnal ou infonnalmente. Entretanto, se sua em-
presa é direcionada a projetos e possui u1na cultura 1nuito forte de gestão de projetos,
você pode ter que gerenciar formal ou informalmente dependendo das necessidades de
seus cl ientes.
9.2 Confiança
Confiar em todos os envolvidos na execução de un1 p rojeto é essencial. Você acorda
de manhã, se veste e entra no carro para ir para o trabalho. Em uma manhã típica,
você pisa no freio de seu carro en1 torno de 50 vezes. Você nunca encontrou as
pessoas que projetaran1, fabricaram ou instalaram os freios. Ainda assim, você nen1
pensa se os freios irão ou não funcionar quando você precisar deles. N inguém o
xinga no trânsito a caminho do traba lho. Você não atropela ninguém. Então você
chega ao trabalho e aperta o botão para chan1ar o elevador. Você nunca encontrou
as pessoas que projetaram, fabricaram, instalaram ou inspecionaram o elevador,
mas, ma is uma vez, você se sente perfeitamente confortável sub indo de elevador até
o seu andar. Ao chegar ao seu escritório às 8 da manhã, você já confiou sua vida a
inúmeras pessoas que você nunca viu. Mesn10 assin1, você se senta en1 seu escritório
e se recusa a confiar na pessoa do escritório ao lado para ton1ar un1a decisão de
US$50.
A confiança é a chave para a implementação bem-sucedida da gestão informal de
projetos. Sem ela, os gerentes de projetos e os patrocinadores de projetos precisariam
de toda aquela papelada somente para garantir que todos que estão traba lhando em
seus projetos estejam fazendo o traba lho da forma como foram inst ruídos a fazer. A
confiança ta1nbém é fundamental para se construir um bom relacionamento ent re a
contratada/subcontratatda e o cl iente. Vejamos um exemplo.
Ta lvez a melhor aplicação da gestão informal de projetos que já vi tenha sido
a que ocorreu há vários anos no Grupo de Sisten1as de Veícu los Pesados da Bendix
Corporation. A Bendix contratou um consultor para realizar un1 progran1a de trei-
nan1ento de três dias de duração. O programa era personalizado, e, durante a sua
fase de criação, o consu ltor perguntou ao vice-presidente e gerente geral da divisão se
ele queria ser treinado en1 gestão de projetos forn1a l ou informal. O vice-presidente
optou pela gestão informa l de projetos. Qual foi o n1otivo de sua decisão? A cu ltura
da d ivisão já se baseava em confiança. Os gerentes de área não eram cont ratados
son1ente com base en1 especialização técnica . Contratações e pron1oções baseavam-se
en1 como o novo gerente se comunicaria e cooperaria com os outros gerentes de área
e gerentes de projetos ao tomar decisões que fossem do interesse tanto da empresa
quanto do projeto.
Quando a relação ent re um cl iente e uma cont ratada se baseia e1n confiança, há
inúmeros benefícios para ambas as partes. Os benefícios são aparentes em e1npresas
como a Hewlett-Packard, a Co1nputer Associares e várias subcont ratadas da indúst ria
auto 1nobi lística. A Tabela 9- 2 1nostra os benefícios.
Capítulo 9 Gestão informal de projetos 44 3
TABELA 9-2 Benefícios da confiança em relações profissionais entre cliente e empresa

contratada
Sem confiança Com confiança
licitações frequentes Contratos de longo prazo, negócios de repetição e
contratos de fornecedor único
Documentação maciça Documentação mínima
Reuniões de equipe excessivas entre cliente e contratada Número mínimo de reuniões de equipes
Reuniões de equipe com documentação Reuniões de equipe sem documentação
Patrocínio nos níveis executivos Patrocínio nos níveis intermediários da gerência
9.3 Comun icação

Em orga nizações t radicionais e fo rmais, os funcionários norma lmente reclamam de
uma com unicação insuficiente. Os gerentes sénio r, no enta nto, no rmal mente acham
que a comunicação em sua empresa é ótiina. Por que a dispa ridade? Na maioria das
empresas, os executivos são inundados por informações comunicadas a eles por meio
de reuniões frequentes e dezenas de relatórios de status se1na nais que chegam de todas
as á reas funcionais da empresa. A qualidade e a frequência das informações que vão de
cima para ba ixo pela hierarquia organizaciona l são menos consistentes, especialmente
em empresas mais formais. No enta nto, seja este um problema com as informações
que vão de baixo para cima até o nível executivo ou com as que vão de ci ma para bai-
xo, até o nível dos funcionários, uma coisa é certa: o problema norma lmente se origina
nas partes 1na is altas da hierarquia. Os gerentes sênior norma lmente são os suspeitos
qua ndo se t rata de exigir relatórios e reuniões. E muitos desses relatórios e reuniões
são desnecessários e redundantes.
A ma ioria dos gerentes de projetos prefere se comunicar verbal e informahnente.
O custo da comunicação formal pode ser alto. A comunicaç.â o e1n projetos inclu i a dis-
tribuição de in formações sobre decisões tomadas, autorizações de tra ba lho, negocia-
ções e relatórios de projeto . Os gerentes de projetos e1n e1npresas excelentes acredita1n
que gastam até 90 % de seu te1npo em comunicações interpessoais internas co1n suas
equipes. A Figura 9- 3 ilustra os ca nais de comunicação usados por um típico gerente
de projetos. Em organizações di recionadas a projetos, os gerentes de p ro jetos pode1n
passar a maior parte de seu tempo se comun icando externamente com clientes e agên-
cias regu latórias.
Boas metodologias promovem não somente a gestão informal de p rojetos, mas
tam bém com unicações eficientes ta nto lateral quanto vertica lmente. A metodologia
propriamente d ita fu nciona como um canal de com unicação. U1n executivo sênior
em uma gra nde institu ição financei ra comentou sobre a metodologia de gestão de
projetos de sua organização, chamada de Padrões de Gestão de Projetos (PMS, Project
Management Standards ):
Os PMS o rientam o gerente de projetos po r cada passo do projeto. Os PMS não somente
controlam a estrutura de geração de relatórios, mas também estabelece as d iretrizes para
quem deve estar envo lvido no projeto propriamente dito e o s vários níveis de revisão. Isso
cria um fl uxo de comunicação excelente entre as pessoas certas. A comunicação de um p ro-
jeto é um dos fatores mais importantes do sucesso. Um plano ótimo não passa d isso se não
for bem comunicado.
Comunicação de
baixo para cima
até patrocinados
e executivos
Gerente de
projetos .j, J. J.
Comunicação
Comunicação Comunicação
lateral com
lateral com lateral com
organizações
clientes e grupos a equipe
formais e
de colegas de projetos
informações
Figura 9-3 Canais de comunicação internos e externos para a gestão de projetos. Fonte:
Reimpresso de H. Kerzner, ln Search of Excel/ence in Proíect Management, Hoboken, NJ:
Wiley, 1998, p. 200.
A maioria das empresas acredita que uma boa metodologia de gestão de projetos
levará a comunicações eficientes, o que pennitirá que a empresa gerencie de maneira
mais informa l do que formal. A questão, é claro, é quanto tempo ela levará para a l-
cançar co1nunicações eficientes. Como todos os funcionários trabalhando debaixo do
mesmo teto, o tempo necessário pode ser mais curto. Pa ra projetos globais, a dispersão
geográfica e as diferenças culturais podem fazer levar décadas até que ocorram comu-
nicações eficientes. Mesmo então, não há nenhuma ga rantia de que os projetos globais
venham a ser gerenciados infonnalmente.
Suzanne Zale, diretora de operações da He,vlett-Packard, enfatizou:2
Com qualquer projeto global, as comunicações se tornam ma is complexas e exigirão muito
mais planejamento antecipado. Todos os q ue precisam aderir precisam ser identificados
logo no início. A fim de promover assuntos existentes, especia listas familiarizados co m a
c ultura local e fornecedores, a necessidade de equipes virtua is se to rna ma is óbv ia. Isso
aumenta a dificuldade de co municações eficientes.
O mecanis mo de comunicação também pode mudar drasticamente. Conversas ou reu-
niões face a face torna m-se mais difíceis. Tendemos a depender fortemente de comunicações
eletrônicas, co mo vídeo e teleconferências e correio eletrônico. O formato das comunicações
precisa ser padronizado e compreendido a ntecipada mente, de modo que as in formações
possam ser enviadas rapidamente. As co municações também levarão ma is tempo e exigirão
mais esforços devido a diferenças culturais e de fusos horá rios.
Uma das premissas implícitas para que a ge.stão informa l de projetos exista é que
os funcionários compreendam sua estrutura organizacional e seus papéis e responsa-
bil idades na estrutura organ izacional e na do projeto. Formas como o gráfico linear
de responsabilidades (LRC, linear responsibility chart) e a mat riz de atribuição de
responsabilidades (RAM, responsibility assign,nent tnatrix) são úteis. As ferramentas
de comunicação não são usadas hoje co1n a 1nesma frequência do que nas décadas de
1970 e 1980.
Para projetos 1nultinacionais, a estrutura, papéis e responsabil idades organizacio-
nais devem ser claramente delineados. Comunicações eficientes são de máxi1na im-
portância e provavelmente têm de ser alcançadas mais formal do que informa lmente.
' lbid., p. 332.

Capítulo 9 Gestão informal de projetos 44 5
Suzanne Zale, diretora de operações da Hev,rlett-Packard afirma:

Para qualquer projeto global, a estrutura organizaciona l precisa ser claramente definida
para minimizar qualquer poss ível mal-entendido. É melhor ter uma definição bem clara do
gráfico organizacional e seus papéis e responsabilidades. Qualquer incentivo à motivação
também precisa considerar d iferenças culturais. Os direcionadores e va lores de d iferentes
culturas podem variar substancialmente.
Os dois principais obstáculos à comunicação que devem ser superados quando
uma empresa rea lmente quer cultivar uma cultura informal são o que gosto de cha1nar
de "relatórios hérnia" e "reuniões forenses". Os "relatórios hérnia" são decorrentes da
crença da gerência de que aquilo que não foi escrito não foi d ito. Embora essa crença
tenha um fundo de verdade, a palavra escrita tem um alto custo. Precisamos conside-
rar mais do que apenas o tempo consum ido na preparação de relatórios e memoran-
dos formais. Há todo o tempo que os destinatários passam lendo-os, além de todo o
tempo necessário para seu processamento, cópias, distribuição e arquivamento.
Se os relatórios de status escritos para a gerência precisam ser grampeados ou
presos por um cl ipe, isso sign ifica que eles são longos demais. Os relatórios de pro-
jetos com mais de 5 a 10 páginas muitas vezes nem mes1no são lidos. Em empresas
excelentes em gestão de projetos, relatórios internos de projetos respondem essas três
perguntas da forma ma is sitnples possível:
• Onde estamos hoje?
• Onde acabaremos?
• Existe algum problema que exige o envolvi1nento da gerência?
Todas essas perguntas podem ser respond idas em uma folha de papel.
O segundo obstácu lo é a reunião de equipe "forense". Uma reunião de equipe
"forense" é uma reunião marcada para durar 30 m inutos que, na verdade, dura mais
de três horas. As reuniões "forenses" são criadas quando os gerentes sênior interfere1n
nas atividades rotineiras de trabalho. Mesmo os gerentes de projetos caem nessa arma-
dilha quando apresentam à gerência informações com as qua is ela não deveria precisar
lidar. Tais situações são um convite ao desastre.
9.4 Cooperação
Cooperação é a disposição de ind ivíduos a t rabalhar uns com os outros para o benefí-
cio de todos. Inclui as ações voluntárias de u1na equipe que traba lha junto para obter
um resultado favorável. E1n empresas excelentes em gestão de projetos, a cooperação
é a norma e ocorre se1n a intervenção formal de autoridade. Os membros da equipe
sabem o que é a coisa certa a se fazer, e a fazem.
Na empresa típica (ou em um grupo típico de qua lquer tipo, na verdade), as pes-
soas aprendem a cooperar à med ida que vão se conhecendo. Isso leva tetnpo, e tempo
é a lgo normalmente escasso para as equ ipes de projetos. No entanto, empresas como a
Ericsson Teleco1n AB, o General Motors Powertra in Group e a Hewlett-Packard cria1n
culturas que promovem a cooperação para o benefício de todos.
9.5 Trabalho em equipe

Traba lho em equipe é o traba lho rea lizado por pessoas que agem juntas com um es-
pírito de cooperação sob os limites da coordenação. Algumas pessoas confundem tra-
balho em equ ipe com mora l, mas moral tem ma is a ver com atitudes em relação ao
t raba lho do que com o trabalho propria1nente di to. Obviamente, porém, um bom
moral é vantajoso para o t raba lho em equipe.
Em empresas excelentes, o trabalho em equipe possui as seguintes características:
• Os funcionários e gerentes compartilha1n ideias uns com os outros e estabelecem
altos níveis de inovação e criatividade em grupos de trabalho.
• Os funcionários e gerentes confiam uns nos outros e são fiéis uns aos outros e à
empresa.
• Os funcionários e gerentes têm um co1npromisso com o traba lho que realizam e
as promessas que fazem.
• Os funcionários e gerentes compartilham informações livremente.
• Os funcionários e gerentes são consistentemente abertos e honestos uns com os
out ros.
Fazer as pessoas sentirem que fazem parte de u1na equipe não necessaria1nente exi-
ge n1uito esforço. Considere a situação na Divisão de Serviços de Engenharia e Cons-
t rução da Dov, Chemical Corporation há vários anos. A Dov, Chemical tinha solici-
tado que um instrutor desenvo lvesse um curso de treina1nento en1 gestão de projetos.
O instrutor entrevistou vários dos participantes do seminário antes do progran1a de
t reinamento para identificar possíveis áreas problemáticas. O 1naior problen1a pareceu
ser uma falta de trabalho e1n equ ipe. Essa lacuna era especiahnente evidente no depar-
tamento de projetos arquitetônicos. O pessoal desse departamento reclan1ou que un1
nún1ero excessivo de n1udanças estava sendo feito nos projetos arquitetônicos. Eles
sin1plesn1ente não conseguian1 compreender os 1notivos por trás de todas as 1nudanças.
O segundo proble1na identificado, e talvez o mais sério, era que os gerentes de pro-
jetos não se con1unicavam con1 o departamento de projetos arquitetôn icos uma vez que
eles estavam concluídos. O pessoal de projetos arquitetônicos não tinha ideia do status
dos projetos en1 que estavam trabalhando, e não sentiam que faziam parte da equ ipe.
Durante o programa de treina1nento, um dos gerentes de projetos, que era respon-
sável por const ruir uma grande fábrica de produtos químicos, foi solicitado a explicar
por que estavam sendo feitas tantas mudanças nos desenhos de seus projetos arqu ite-
tônicos. Ele disse: "Há três motivos para as mudanças. Primeiro, os clientes nem sem-
pre sabem o que querem com antecedência. Segundo, quando temos os desenhos pre-
li1ninares, const ruímos um modelo de plástico da fábrica. O modelo geralmente nos
mostra que equ ipa tnentos precisam ser movidos para manutenção ou por motivos de
segurança. Terceiro, às vezes precisamos correr até a const rução bem antes de termos
a aprovação final da Agência de Proteção Ambiental. Quando a agência finahnente
dá sua aprovação, essa aprovação geralmente se torna contingente para grandes mu-
danças estruturais no t rabalho que já foi concluído". U1n antigo funcionário da Do,v
comentou que, em seus 15 anos de empresa, ninguém nunca tinha explicado antes os
motivos por trás das mudanças nos desenhos dos projetos.
A solução para o problema de comunicação insuficiente tambétn era fáci l de
consertar uma vez que fosse revelada. Os gerentes de projetos prometeram tirar ins-
tantâneos mensais do progresso dos projetos de construção e compartilhá-los com o
departamento de projetos arquitetônicos. O pessoal dos projetos arquitetônicos ficou
satisfeito e passou a se sentir mais como pa rte da equipe de projetos.
9.6 Relatórios de status com códigos de cores

O uso de cores em relatórios de status, seja para relatórios impressos ou para apresen-
tações visuais na intranet da empresa, cresceu significativamente. Os relatórios com
códigos de cores encorajam a ocorrência da gestão de projetos info rmal. As cores

pode1n reduzir os r iscos alertando a gerência rapidamente de que existe um possível
problema. Uma empresa preparava relatórios de status complexos, mas marcava as
margens direitas de cada página com um código de cores criado para públ icos e níveis
da gerência específicos. Um executivo comentou que hoje ele só lê as páginas que
possuem códigos de cores para ele especificamente e1n vez de ter de procurar o que é
de seu interesse por todo o relatório. Em uma outra empresa, a gerência sênior desco-
briu que os relatórios de stat11s via int ranet que era1n marcados com códigos de cores
permitia1n que eles revisassem mais informações e1n menos te1npo hábi l focal izando
apenas nas cores que ind icava1n possíveis problemas. As cores podem ser usadas para
indicar:
• O stat11s não foi endereçado.
• O stat11s foi endereçado, mas não há problemas.
• O projeto está em andamento.
• Pode haver um possível problema no futuro.
• Existe definitivamente um proble1na, e ele é sério.
• Nenhuma ação deve ser tomada e1n relação a esse problema.
• A atividade foi concluída.
• A atividade ainda está ativa e a data de conclusão já passou.
9.7 Dashboards de crises

Ao longo dos úlcimos anos, os dashboards se tomaram lugar-comum para apresentar
informações de status de projetos para a equipe de projetos, clientes e partes interessa-
das. A finalidade de um dashboard é converter dados brutos em informações significa-
tivas que possa1n ser facilmente compreendidas e usadas para u1na tomada de decisões
informada. O dashboard fornece ao espectador uma "consciência situacional" do que
as informações significam agora e do que podem significar no futuro se as tendências
existentes continuarem. Os dashboards funcionam como ferramentas de comunicação
que nos pennite1n passar à gestão de projetos livre de papelada, com menos reuniões
e sem desperdícios.
Os projetos no ambiente de hoje são sign ificativamente ma is complexos do que
muitos dos projetos gerenciados no passado. Com os projetos de hoje, a govemança é
real izada por u1n comitê de governança, em vez de um ún ico patrocinador de projetos.
Cada parte interessada ou membro do comitê de governança pode mu ito bem exigir
diferentes 1nét ric.as e KP!s. Se e.ada parte interessada desejar observar de 20 a 30 mét ri-
cas, os custos da mensuração e relatório de métricas pode ser muito alco e contrariar o
propósito de el iminar a papelada na gestão de projetos.
A solução para comunicações eficientes com as partes interessadas e os grupos
de governança é mostrar a eles que mui to provavelmente poderão conseguir todos
os dados essenciais necessários para u1na tomada de decisões informada com 6 a 1 O
métricas ou KP!s que podem ser exibidos na tela de um computador. Isso nem se1npre
é o que ocorre e pode ser necessário um maior detalhamento e1n outras telas. Em gera l,
porém, uma tela de computador deve ser suficiente.
Se houver uma situaç.ã o de condição de fora de tolerância ou crise com qua lquer
uma das métricas ou KP!s na tela do dashboard, a situação deve fie.ar aparente imedia-
tamente para o leitor. Mas e se a crise ocorrer devido a métricas que não aparecem na
tela? Nesse caso, o leitor será imediatamente d irecionado a um dashboard de crise que
mostra todas as métr icas que estão fora de tolerância. As métricas fora de tolerância
permanecerão no dashboard de crise até o 1no1nento em que a crise ou as condições
fora de tolerância sejam corrigidas. Cada pa rte interessada agora verá a tela regular e,
então, será instruída a olhar a tela de crise.
Definindo uma crise

Uma crise pode ser defin ida como qualquer evento, seja ele esperado ou não, que
possa nos levar a uma situação instável ou perigosa que afeta o resultado do projeto.
As crises significam consequências negativas que podem prejudicar u1na organ ização,
suas partes interessadas e o público etn geral. A crise pode resultar em mudanças para
a estratégia de negócios da empresa, como ela interage com os fatores ambienta is
empresariais, co1no a consciência social da empresa é exibida, e o modo como ela
mantém a satisfação do cl iente. Uma crise não necessariamente significa que o projeto
fracassará, nem significa que o projeto será extinto. A crise pode simplesmente ser o
fato de que o resultado do projeto não ocorrerá como esperado.
Algumas crises às vezes aparecem gradualmente e são precedidas por sinais de
a lerta precoces. Esses sina is podem ser chamados de crises latentes. A intenção das
métricas e dos dashboards é identificar tendências que poderiam ind icar que uma crise
talvez esteja se aproximando e fornecer ao gerente de projetos tetnpo suficiente para
desenvolver p lanos de contingência. Quanto antes você souber de crises iminentes,
mais opções poderá ter disponíveis para retned iá-las.
Como determinados se a condição de fora da tolerância é apenas um problema ou
u1na crise? A resposta está nos danos potenciais que podem ser causados. Se qualquer
uma das coisas a seguir acontecer, a situação provavelmente seria t ratada como uma
cnse:
• Há uma ameaça significativa para o resu ltado do projeto
• Há uma ameaça significativa para a organ ização como um todo, suas partes inte-
ressadas e possivelmnte o públ ico em geral
• Há uma a tneaça significativa para o 1nodelo e a estratégia de negócios da empresa
• Há uma ameaça significativa para a saúde e a segurança dos traba lhadores
• Há un1a ameaça sign ificativa para os consumidores, con10 adulteração de produtos
• Existe a possibilidade de perda de vidas
• Existe a possibil idade de at rasos no t rabalho porque os sistemas estão sendo re-
desenhados
• Existe a possibilidade de atrasos no traba lho devido a mudanças organizacionais
necessanas
• Existe uma chance significativa de que a imagem ou reputação da empresa seja
prejudicada
• Existe uma chance alta de que a deterioração na satisfação do cliente possa resul-
tar etn perdas de receitas significativas no presente e no futuro
É importante compreender a d iferença entre gestão de riscos e gerencia tnento de
crises. Segundo a Wikipédia, a enciclopédia livre,
Ao contrário da gestão de riscos, que envolve ava liar possíveis ameaças e encontrar as me-
lhores maneiras de evitá-las, o gerenciamento de crises envolve lidar com as ameaças antes,
d urante e depois de elas terem ocorrido. Isto é, o gerenciamento de crises é proativo, não
meramente reativo. É uma disciplina dentro do contexto mais amplo de gerenciamento que
consiste em habilidades e técnicas necessárias para identificar, avaliar, compreender e lidar
com uma situação séria, es pecialmente a partir do momento em que ocorre pela primeira
ve2 até o ponto em q ue se iniciam os procedimentos de recuperação.
As crises geralmente exigem que decisões imediatas sejam totnadas. Uma tomada
de decisões eficiente exige informações. Se u1na métrica pa rece estar em modo de crise
e aparece no dashboard de crises, os leitores talvez achem necessário ver d iversas ou-
tras métricas que podem não estar em modo de crise e não apa recer no dashboard de
crise, mas que são possíveis causas de crises. Observa r as métricas nos dashboards é
muito mais fácil do que ler relatórios.
A d iferenciação entre um problema e uma crise é cotno a beleza: está nos olhos de
quem vê. O que u1na parte interessada vê como um p roble1na, uma outra parte interes-
sada pode ver como crise. A Tabela 9-3 mostra como é difícil fazer essa diferenciação.
Agora podemos tirar as seguintes concl usões sobre os dasbboards de crise:
• A definição do que é ou não uma crise nem sempre é clara para os leitores
• Nem todos os problemas são crises
TABELA 9-3 Diferenciação entre um problema e uma crise

Mét rica/KPI Problema Crise
Tempo O projeto sofrerá atraso, mas ainda O projeto sofrerá atraso, e o cliente está consi-
será aceitável para o cliente derando o cancelamento
Custo Os custos estão sendo excedidos, Os custos estão sendo excedidos, e não há
mas o cliente pode fornecer financia- financiamento adicional disponível. O cancela-
mento adicional mento é extremamente provável
Qualidade O cliente não está feliz com a qualida- A qualidade dos deliverab/es é inaceitável,
de, mas pode aceitá-la danos pessoais são possíveis, o cliente pode
cancelar o contrato, e é possível que esse
cliente não ofereça mais nenhum trabalho
Recursos O projeto está com falta de pessoal A qualidade ou a falta de recursos causará um
ou os recursos designados possuem sério atraso no cronograma, e a qualidade das
habilidades insuficientes para fazer o habilidades do pessoal pode ser inaceitável a
trabalho. Um atraso no cronograma é ponto de o projeto poder ser cancelado
provável
Escopo Há inúmeras mudanças de escopo, O número de mudanças de escopo levou o
que podem causar mudanças às cliente a acreditar que o planejamento não
linhas de base. Atrasos e excessos de está correto, e mais mudanças de escopo
custos estão acontecendo, mas são ocorrerão. Os benefícios do projeto não mais
aceitáveis para o cliente por enquanto superam seus custos, e é provável que o proje-
to seja extinto
Itens de ação O cliente está insatisfeito com a quan- O cliente está insatisfeito com a quantidade de
tidade de tempo levada para encerrar tempo levada para encerrar itens de ação, e o
itens de ação, mas o impacto sobre o impacto sobre o projeto é significativo. As deci-
projeto é pequeno sões de governança estão sendo atrasadas
devido aos itens de ação aberta, e o impacto
sobre o projeto pode ser severo
Riscos Existem níveis de risco significativos, Os danos potenciais que podem ocorrer de-
mas a equipe pode ser capaz demiti- vido à severidade dos riscos são inaceitáveis
gar parte deles para o diente
Premissas e restrições Surgiram novas premissas e res- Surgiram tais novas premissas e restrições
trições que podem afetar o projeto que será necessário um replanejamento signi-
adversamente ficativo do projeto. O valor do projeto pode não
mais existir
Fatores ambientais Os fatores ambientais empresariais Os novos fatores ambientais empresariais
empresariais apresentam mudanças e podem afe- reduzirão muito o valor e os benefícios espera-
tar o projeto adversamente dos do projeto
• Às vezes, tendências desfavoráveis são t ratadas como crises e aparecem nos dash-
boards de crises
• O dashboard de crises pode conter uma mistura de métricas de crises e métricas
que são tratadas apenas como problemas
• As métricas que aparece1n em um sistema t radicional de relatórios via dashboard
podem precisar ser redesenhadas quando colocadas em um dashboard de crise
para garantir que elas seja facilmente compreendidas.
• As métricas de crises gera lmente implica1n que ou essa situação precisa ser moni-
torada de perto ou que algumas decisões deve1n ser tomadas.
9.8 Gestão informal de projetos na prática

Analisemos dois estudos de casos que ilustram a gestão informa l de projetos em ação.
Polk Lighting
A Polk Lighting (um no1ne fictício) é uma empresa de US$35 mi lhões localizada em
Jacksonville, Flórida, EUA. A empresa produz lâmpadas, lanternas e diversos out ros
instrumentos de iluminação. Seu negócio é integralmente baseado em produtos e ser-
viços, e a etnpresa não aceita projetos contratados de clientes externos. A 1na ior parte
das ações da empresa é negociada na bolsa de valores. O presidente da Polk Lighting
detém esse cargo desde o início da e1npresa em 1985.
Em 1994, as atividades da Polk se concentravam no grupo de P&D, que o presi-
dente supervisionava pessoa lmente, recusando-se a contratar um diretor de P&D. Ele
acreditava no gerenciamento info rmal para todos os aspectos do negócio, 1nas tinha
segundas intenções com o uso da gestão informal de projetos. A ma ioria das empresas
usa este artifício para manter os custos baixos o máximo possível, mas o presidente da
Polk favorecia a gestão informal de projetos para que ele pudesse 1nanter o cont role
sobre o grupo de P&D. Entretanto, para que a empresa pudesse crescer, o presidente
precisaria a 1npliar a estrutura de gerencia1nento, estabelecer o rçamentos apertados
para os projetos e possivelmente, tomar a gestão de projetos mais formal do que tinha
sido até então. Além disso, ele provavelmente seria forçado a contratar um diretor de
P&D.
Pressões dos acionistas da e1npresa acaba ra 1n forçando o presidente a permitir que
a empresa crescesse. Quando o crescimento tornou necessário para o presidente assu-
mir tarefas adm inistrativas 1na is pesadas, ele finahnente cont ratou um vice-presidente
de P&D.
Dentro de a lguns anos, as vendas da en1presa tinham dobrado, 1nas a gestão infor-
mal de projetos a inda estava en1 vigor. Embora os orçan1entos e cronogran1as tenhan1
sido estabelecidos à 1nedida que a e1npresa foi crescendo, a gestão real dos projetos e o
1nodo co1no as equipes trabalhavam juntas permaneceram informais.
Boeing Aerospace (década de 1970)

Há várias décadas, a Boeing era a principal contratada pela Força Aérea dos EUA para
produzir o novo míssi l de ataque de curto alcance ($RAM, sbort-range attack tnissile)
e subcontratou a Thioko l Corporation pa ra desenvolver o sistema de propulsão do
míssil. Geralmente, supõe-se que a comunicação entre grandes cl ientes e suas empre-
sas contr atadas p recise ser forma l, devido a possíveis receios quando os contr atos
são complexos e envolvem bi lhões de dólares. O uso de representantes no local, no
entanto, pode transformar uma relação possivelmente polêm ica e1n uma relação de
confiança e cooperação co1n a introdução da informalidade.
Dois funcionários da Boeing foram cuidadosamente selecionados como repre-
sentantes no local para supervisionar o desenvolvimento do sistema de propulsão do
$RAM na Thiokol Corporation. A relação de t rabalho entre o escritório de gestão de
projetos da Thiokol e os representantes no local da Boeing rapidamente se desenvol-
veu em uma confiança compartilhada. Eram feitas reuniões de equipe sem troca de
documentação excessiva. Cada parte concordou em cooperar uma com a outra. O
gerente de projetos da Thiokol confiava nos representantes da Boeing o suficiente para
lhes dar dados brutos de resultados de testes mesmo antes dos engenheiros da Thio-
kol poderem formular suas próprias opiniões sobre cais dados. Os representantes da
Boeing, por sua vez, prometeram que não repassariam os dados brutos para a Boeing
até que os engenheiros da Thiokol estivessem prontos para comparti lhar seus resulta-
dos co1n seus próprios patrocinadores executivos.
A relação Thiokol- Boeing nesse projeto clara1nente indica que a gestão informal
de projetos pode funcionar ent re clientes e cont ratadas. Grandes empresas contratadas
no ra1no de construção tiveram os mesmos resultados positivos ao usar a gestão infor-
mal de projetos e representantes no loca l para reconst ruir a confiança e a cooperação.
A informalidade não é um substituto para as atividades forma is da gestão de projetos.
Em vez disso, significa simplesmente que a lgumas atividades podem ser feitas mais
informa l do que formalmente. Comunicações formais e informais podem coexistir.
Excelência comportamental
10.0 Introdução
Nos capít ulos anteriores, vimos que as en1presas excelentes em gestão de projetos
enfatizam fortemente o treinan1ento em habilidades con1portamentais. No passado,
pensava-se que os fracassos de projetos ocorrian1 prin1ordialn1ente devido a n1au
planejamento, imprecisões de estimativas, ineficiência na geração de cronogramas
e falta de controle de custos. Ho je, as en1presas excelentes percebem que o fracas-
so de projetos está n1ais ligado a problemas comportan1entais - baixo moral dos
funcionários, relações humanas negativas, baixa produtividade e falta de compro-
n11sso.
Este capítulo d iscute esses fatores humanos no contexto da liderança situacional
e resolução de conflitos. Oferece, ta tnbém, informações sobre questões de seleç.ã o de
funcionários em gestão de projetos. Fina lmente, o capítu lo oferece conselhos sobre
como alcançar a excelência comportamental.
10.1 Liderança situacional

Quando a gestão de projetos começou a enfatizar 1nais o gerenciamento compor-
tamental do que o gerenciamento técn ico, a liderança situacional também passou a
receber 1nais atenção. O tamanho médio dos projetos cresceu, e cresceu ta tnbém o
tamanho das equipes de projetos. A integração de processos e relações interpessoais
eficientes também passaram a ter maior importância com o aumento das equipes de
projetos. Os gerentes de projetos hoje precisam ser capazes de se co1nunicar com mui-
tas diferentes funções e departamentos. Existe um provérbio contemporâneo da gestão
de projetos que diz mais ou 1nenos o seguinte: "Quando um pesquisador fala com
out ro pesquisador, há uma compreensão de 100%. Quando um pesqu isador fala cotn
o departamento de produção, há u1na compreensão de 50%. Quando um pesqu isador
fala com o departamento de vendas, há uma compreensão de O'Yo. Mas o gerente de
projetos fala com todos eles".
Randy Coleman, antigo vice-presidente sênior do Federal Reserve Bank of Cleve-
land, enfatiza a importância da to lerância:
A característica mais importante necessária para uma gestão de projetos bem-sucedida é
a tolerância: a tolerância a eventos externos e a tolerância às personalidades das pessoas.
De modo geral, há dois grupos aqui no Fed - pessoas que gostam de estabilidade e q uerem
passar o resto da vida no mesmo emprego e aquelas que trocam de emprego com frequên-
cia. Você precisa lidar com os dois grupos de maneiras d iferentes, mas, ao mesmo tempo,
deve tratá-los da mesma forma . Você tem de se curvar um pouco diante dos independentes
(pessoas mais jovens que mudam de emprego com frequência) que têm ideias boas e criati-
vas e q ue você quer segurar na empresa, particularmente aqueles q ue se arriscam. É preciso
admitir que terá que lidar com alguns trade-o(fs.
Um gerente de projetos sên ior em u1na etnpresa internaciona l de contabi lidade
declara como seu próprio estilo de liderança mudou de t radicional para situacional
desde que se tornou gerente de projetos:
Eu achava que havia determinada abordagem que era melhor para a liderança, mas a ex-
periência me ensinou que liderança e personalidade andam de mãos dadas. O que funciona
para uma pessoa, não funciona para outras. Sendo assim, você precisa compreender o sufi-
ciente sobre a estrutura de projetos e sobre pessoas e, então, adotar um estilo de liderança
que se adapte à s ua personalidade, de modo que você soe natural e genuíno. É um misto da
experiência e da personalidade de uma pessoa com seu estilo de liderança.
Muitas empresas começam a apl icar a gestão de projetos sem compreender as
diferenças comporta tnentais fundamentais entre os gerentes de projetos e os gerentes
de área. Se supusermos que o gerente de área não esteja t rabalhando também como
gerente de projetos, estas são as d iferenças comportamenta is entre os dois:
• Os gerentes de projetos têm de lidar cotn 1nú ltiplas relações hierárquicas. Os ge-
rentes de área se reportam a profissionais etn cargos superiores em uma única
cadeia de comando.
• Os gerentes de projetos têtn muito pouca autoridade rea l. Os gerentes de área de-
têm uma grande quantidade de autoridade em virtude de seus títu los.
• Os gerentes de projetos geralmente não contribuem com os relatórios de desempe-
nho de funcionários. Os gerentes de área contribuem formahnente com os relató-
r ios de desempenho dos funcionários que se reportam diretamente a eles.
• Os gerentes de projetos nem sempre fazem parte de um plano de carreira que pre-
veja aumentos salariais. Os gerentes de área sempre fazem.
• O cargo de gerente de projetos pode ser temporário. O ca rgo de gerente de área é
permanente.
• Os gerentes de projetos às vezes são de um nível de grau inferior ao dos 1nembros
da equipe de projetos. Os gerentes de área geralmente são re1nunerados em utn
nível superior aos de seus subordinados.
Há vários anos, quando a Ohio Bell a inda era subsidiária da American Telepho-
ne and Telegraph, contratou-se um instrutor para 1ninist rar um curso de três dias de
duração em gestão de projetos. Durante o processo de personalização, pediu-se que
o instrutor enfatizasse o planejamento, a geração de cronogramas e o controle, e que
não se importasse com os aspectos comportamentais da gestão de projetos. Naquela
época, a AT&T ofereceu um curso sobre como se tomar supervisor de área que todos
os participantes do sem inário já haviam feito. Na discussão que se segu iu entre o
instrutor e os desenvolvedores de conteúdo do curso, ficou claro que liderança, moti-
vação e resolução de conflitos estavam sendo ensinados do ponto de vista do superior
para o subordinado no curso da AT&T. Quando os desenvolvedores de conteúdo do
curso perceberam que os gerentes de projetos oferecem liderança, motivação e reso-
lução de conflitos a funcionários que não se reportam diretamente a eles, permitiu-se
que o instrutor incluísse assuntos comportamentais relacionados à gestão de projetos
no semtnano.
As organizações precisa tn reconhecer a importância dos fatores comportamentais
nas relações de trabalho. Quando reconhecem, passam a compreender que os gerentes
de projetos devem ser contratados por sua competência gera l de gerenciamento de
p rojetos, e não so1nente por seus con hecimentos técnicos. Brian Vannoni, antigo ge-
rente de treinamento e p rincipal engenheiro de processos da GE Plastics, descreveu a
a bordagem de sua organizaç.ã o ao seleciona r gerentes de projetos:
O processo de seleção para fazer as pessoas se envolverem como gerentes de projetos baseia-
-se primordialmente em suas habilidades comportamentais e suas habilidades como líderes
no que d iz respeito a outros aspectos da gestão de projetos. Alguns dos gerentes de proje-
tos profissiona is que trabalham em regime de tempo integral escolhem engenheiros sênior
como seus protegidos, sendo seus guias e mentores, de modo q ue os engenheiros possam
aprender os o utros aspectos da gestão de projetos. Porém, as principais habilidades que
estamos procurando são, na verdade, as habilidades de liderança .
Os gerentes de p ro jetos com fortes habilidades comporta1nenta is têm mais chan-
ces de envolver suas equipes na tomada de decisões, e a tomada de decisões comparti-
lhada é um dos p rincipais traços da gestão de projetos bem-sucedida. Hoje os gerentes
de projetos são mais gerentes de pessoas do que gerentes de tecnologia. Segundo Ro-
bert Hershock, antigo vice-presidente da 3M:
A confiança, o respeito e, especialmente, as com unicações são muito, muito importantes,
mas acho q ue uma coisa q ue devemos ter em mente é q ue um líder de equipe não gerencia
tecnologia; gerencia pessoas. Se você gerencia r as pessoas da forma certa, elas gerenciarão
a tecnologia.
Além disso, os gerentes de projetos orientados por questões comportamenta is têm
mais chances de delegar responsabilidade.s aos 1nembros de equipes do que gerentes de
projetos tecn icamente fortes. Em 1996, Fran k Jackson, antigo gerente sênior da MCI,
afirmou :
Os líderes de equipes precisam ter um foco e um compromisso com um objetivo último.
Você definitivamente tem de se res ponsabilizar por s ua equipe e pelo resultado dela. Você
precisa ser capaz de compartilh ar a tomada de decisões. Não pode se a utodetermina r como
o detentor ecxclusivo do d ireto de tomar decisões. Você deve ser capaz de d ividir esse direi-
to. E isso, novamente, só para bater na mesma te.da, é uma q uestão de comunicação. Uma
comunicação clara e concisa por toda a equipe e subindo e descendo uma cadeia de coman-
do é muito, muito importante.
Algun1as o rga nizações preferen1 te r un1 gerente de projetos com fo rtes habi li-
dades con1portan1en ta is, deixando a especial ização técnica nas n1ãos do engenheiro
de p rojetos. Outras descobriram q ue o inverso é eficiente. Rose Russet t, a ntigo ge-
rente de processos de gerencian1ento de programas da Genera l Motors Powertrain,
declarou:
Norma lmente indicamos um indivíduo com formação técnica para o cargo de gerente de
programas e um ind ivíduo com formação em negócios e/ou sistemas para o cargo de ad-
ministrador do programa . Essa combinação de habilidades parece complementar uma à
o utra. Os vários gerentes de área são, em última análise, responsáveis pelas partes técnicas
do programa, enquanto a responsabilidade principal do gerente de programas é propiciar
a integração de todos os deliverables funcionais a fim de alcançar os objetivos do progra-
ma. Tendo isso em mente, é útil para os gerentes de programas compreender as q uestões
técnicas, mas eles agregam valor não solucionando problemas técnicos específicos, e sim
liderando a equipe por meio de um processo q ue resultará nas melhores soluções para o
programa de modo geral, não somente para a á rea funcional específica. O administrador
do programa, com dados recebidos de todos os membros da equipe, desenvolve os planos
de programa, identifica o caminho crítico e comunica periodicamente essas informações à
equipe ao longo da vida do p rograma. Essas informações são utilizadas para auxiliar com a
solução de problemas, a tomada de decisões e a gestão de riscos.
10.2 Resolução de conflitos

Os oponentes da gestão de projetos afirman1 que o principal n1otivo pelo qual a l-
gumas empresas evitam n1udar para un1a cultura de gestão de projetos é o fato de
elas temerem os conflitos que qualquer n1udança inevitaveln1ente acarreta. Conflitos
fazen1 parte da rotina das empresas com culturas de gestão de projetos. Eles podem
ocorrer em qualquer nível da organização, e geralmente resu ltam de objetivos con-
flitantes. En1 muitas organizações, os gerentes de projetos estão sen1pre resolvendo
problemas emergenciais e lidando com crises que surgem de conflitos interpessoais
e interdepartan1entais. Eles estão tão ocupados fazendo isso que delegan1 as respon-
sabilidades cotidianas de dirigir seus projetos às equipes de projetos. Embora esse
arranjo não seja o mais eficiente, às vezes é necessário, especialmente após un1a rees-
trun1ração organizacional ou o início de un1 novo projeto que exige novos recursos.
A capacidade de lidar com conflitos exige uma compreensão e1n relação ao moti-
vo de seu surgimento. Podemos fazer quat ro perguntas, cujas respostas normalmente
são úteis ao lidar com conflitos e possivehnente evitá-los e1n um ambiente de gestão
de proj ecos:
• Os objetivos do projeto ent ram e1n conflito co1n os objetivos de outros projetos
que estão sendo desenvolvidos no momento?
• Por que os confl itos ocorrem?
• Como podemos resolver confl itos?
• Existe a lgo que possamos fazer para prever e resolver conflitos antes de eles se
tornarem sérios?
Embora os conflitos sejam inevitáveis, pode-se 1ninimizá-los com p laneja1nento.
Por exemplo, é provável que surjam conflitos em uma equipe em que os membros não
compreendem os papéis e responsabilidades uns dos outros. Podem-se traçar gráficos
de responsabilidades para mapear quem é responsável pelo quê no projeto. Tendo eli-
minado a ambiguidade dos papéis e responsabilidades, resolve-se o confl ito ou evitam-
-se futuros conflitos.
Resolução sign ifica colaboração, e colaboração significa que as pessoas precisa1n
estar dispostas a confiar umas nas out ras. Sem colaboração, a falta de confiança pre-
valece, e a documentação do progresso aumenta.
Os tipos 1na is comuns de confl itos envolvem o seguinte:
• Recursos hu1nanos
• Equipamentos e instalações
• Desembolsos de capita l
• Custos
• Opiniões técnicas e trade-offs*
• Prioridades
• Procedimentos adm inistrativos
• Cronogramas
• Responsabi lidades
• Choques de personalidade
• N . de T.: A expressão refere•se a uma necessidade de perda ou rroca de algo para se conseguir outra coisa.
Normalmente uma relação "perde-e-ganha" em que se perde ou abre-se mão de uma qualidade para poder
obter outra.
Cada um desses tipos de confl itos pode variar em intensidade ao longo da vida do
projeto. A intensidade relativa pode variar em funç.ã o de:
• Estar se aproximando das rest rições do projeto
• Ter encont rado apenas duas restrições e1n vez de três (p.ex.: te1npo e desempenho,
mas não custo)
• O ciclo de vida do projeto propriamente dito
• Os ind ivíduos que estão em conflito
Os conflitos podem ser positivos se trouxere1n resu ltados benéficos. Deve-se per-
mitir que esses confl itos positivos continuem contanto que as restrições de projeto não
sejam violadas e que haja resultados benéficos. Um exemplo de conflito positivo pode
ser dois especia listas técn icos discutindo que cada um possu i uma maneira melhor de
solucionar um problema. O resu ltado benéfico seria que cada u1n deles tentaria encon-
t rar informações adicionais para respaldar suas hipóteses.
Alguns confl itos são inevitáveis e ocorrem repetidas vezes. Por exemplo, considere
um estoque de matérias-primas e bens acabados. O departamento de produção deseja
o maior estoque possível de 1natérias-primas à mão para evitar possíveis interrupções
na produção. O departamento de vendas e marketing deseja o maior estoque possível
de bens acabados para que os registros contábeis pareçam favoráveis e não seja possí-
vel nenhum problema de fluxo de caixa.
Considere cinco 1nétodos que os gerentes de projetos pode1n usar para resolver
conflitos:
• Confrontação
• Conci liação
• Facil itação (ou suavização)
• Força (ou obrigação)
• Retirada
A confrontação é provaveln1ente o n1étodo mais con1um usado pelos gerentes de
projetos para resolver conflitos. Usando a confrontação, o gerente de projetos enfrenta
o confl ito diretan1ente. Con1 a ajuda do gerente de projetos, as partes em desacordo ten-
tam convencer umas às outras de que sua soluç.ão para o problema é a n1ais adequada.
Quando a confrontaç.ã o não funciona, a segunda abordagem 1nais empregada pe-
los gerentes de projetos nonna lmente é a conciliação. Na conciliação, cada uma das
pa rtes em confl ito concorda com trade-offs ou faz concessões até que se chegue a uma
solução que seja aceitável por todos. Essa abordagem de "toma lá - dá cá" pode faci l-
mente levar a uma solução do conflito que seja favorável a ambas as partes (win- win).
A terceira abordagem para a resolução de conflitos é a faci litação. Usando habili-
dades de facilitação, o gerente de projetos enfatiza áreas de acordo e dese1úatiza áreas
de desacordo.
Por exemplo, suponha que un1 gerente de projetos diga: "Estamos discutindo cinco
questões, e até agora só chega1nos a u1n acordo nas três prin1eiras. Não há n1otivo para
não concordarmos nas duas últimas, não é?" . A facilitação de un1 desacordo não resol-
ve o confl ito. A facilitação n1inÍlniza o contexto en1ocional no qual o conflito ocorre.
Força também é um 1nétodo de resolução de conflitos. U1n gerente de projetos usa
força quanto tenta resolver um desacordo exercendo sua opinião à custa das out ras
pessoas envolvidas. Gerahnente, forçar uma solução às pa rtes de um confl ito produz
u1n resultado que só é favorável para u1na das partes (win- lose). Chamar o patrocina-
dor do projeto para resolver um conflito é uma outra forma de força às vezes empre-
gadas pelos gerentes de projetos.
O modo de resolução de conflitos menos usado e menos eficiente é a retirada.

Un1 d iretor de projetos pode sin1plesn1ente se retirar do confl ito e deixar a situação
sem ser resolvida. Quando esse método é utilizado, o conflito não desaparece e pro-
vavelmente será recorrente mais adiante. Conflitos de personalidade podem ocor-
rer a qua lquer momento, con1 qua lquer pessoa, e a respeito de qua lquer assunto.
Alén1 d isso, eles podem parecer quase impossíveis de prever e de se planejar para
evitá-los.
Vejamos como uma empresa encont rou uma maneira de prever e evitar conflitos
pessoa is em um de seus projetos. O Foster Defense Group (um nome fictício) era a
fi lial cont ratada pelo governo de uma empresa da Fortune 500. A empresa compreen-
deu os efeitos potencialmente negativos dos choques de personalidade em suas equipes
de projetos, mas não gostava da ideia de reunir a equ ipe toda para "lavar a roupa
suja". A empresa encontrou uma solução melhor. O gerente de projetos colocou os
no1nes dos membros da equipe de projetos em uma lista. Então, ent revistou todos in-
dividualmente e pediu a cada um deles que identificasse os nomes na lista das pessoas
com quem eles já tinham tido conflitos de persona lidade no passado. As informações
permaneceram confidencia is, e o gerente de projetos conseguiu evitar possíveis confli-
tos separando persona lidades que não se encaix avam bem.
Se possível, o gerente de projetos deve lidar com a resolução de conflitos. Quando
não conseguir neutra lizar o confl ito, então - e só então - o patrocinador de projetos
deve ser chamado para tentar resolver o problema. Mesmo nesse caso, o pat rocinador
não deve chegar e forçar u1na resolução do conflito. Em vez disso, deve facilitar uma
discussão mais aprofundada ent re os gerentes de projetos e os membros de equipe
envolvidos.
10.3 Selecionando funcionários tendo em mente

a excelência
A seleção de gerentes de projetos é sempre uma decisão tomada no nível executivo.
E1n empresas excelentes, poré1n, os executivos vão além de simplesmente selecionar o
gerente de projetos. Eles usam o processo de seleção para alcançar o seguinte:
• Os gerentes de projetos são t razidos "a bordo" logo no início da vida do projeto,
para ajudar a delineá-lo, estabelecer seus objetivos, e até 1nesmo fazer planos para
marketing e vendas. O papel do gerente de projetos nas relações com o cl iente ve1n
se tornando cada vez mais importante.
• Os executivos designam gerentes de projetos para a vida do projeto e para sua
extinção. O patrocinador pode mudar ao longo do ciclo de vida do projeto, mas
não o gerente de projetos.
• A gestão de projetos ganha seu próprio plano de carreira.
• Espera-se também que o gerente de projetos cujo papel a desempenhar envolva
relações com o cliente ajude a vender futuros serviços de gestão de projetos muito
antes do projeto atual estar concluído.
• Os executivos percebem que mudanças no escopo do projeto são inevitáveis. O
gerente de projetos é visto como um gerente de mudanças.
As empresas excelentes em gestão de projetos estão preparadas para crises. Tanto
o gerente de projetos quanto os gerentes de área são encorajados a trazer os proble-
mas à superfície o mais rápido possível para que haja tempo para o p lanejamento de
contingência e a solução de problemas. Substituir o gerente de projetos não é mais
a p rimeira solução para os problemas de um projeto. Os gerentes de projetos são

substituídos so1nente quando tenta tn ocultar problemas.
Uma empresa contratada da indústria de defesa estava atrasada no cronograma de
u1n projeto, e a equipe de produção foi sol icitada a fazer muita hora extra para colocar
o trabalho em dia. Dois dos funcionários da produção, ambos sindica lizados, usaram
o lote errado de matérias-primas para produzir u1n equ ipamento de US$65 mi l neces-
sário para o projeto. O cliente ficou insatisfeito com o não cu1nprimento de prazos e
os custos excedentes que resultaram da necessidade de substituição do equipamento
inutilizável. Uma reunião que mais parecia uma sessão da inquisição foi 1narcada e
assistida por executivos tanto do cl iente quanto da contratada, o gerente de projetos
e os dois funcionários da produção. Quando o representante do cl iente pediu uma
explicação do que havia acontecido, o gerente de projetos se levantou e disse, "O que
aconteceu é de 1ninha inteira responsabi lidade. Esperar que as pessoas façam hora
ext ra leva a erros. Eu devia ter sido mais cuidadoso". A reunião fo i encerrada sem nin-
guém ser culpado. Quando ru1nores se espalharam pela empresa sobre o que o gerente
de projetos fez para proteger dois funcionários sindicalizados, todos dera1n o mel hor
de si para conseguir colocar o projeto em dia novamente, 1nesmo tendo de fazer hora
ext ra não remunerada.
O comportan1ento hun1ano também deve ser considerado ao designar funcio-
nários a equipes de p rojetos. Os n1embros de equipes não deven1 ser designados a
un1 projeto son1ente com base en1 seu conhecimento técnico. Deve-se reconhecer
que a lgumas pessoas simplesn1ente não conseguem t rabalhar eficientemente en1 un1
an1biente de equipe. Por exemplo, o diretor de pesqu isa e desenvo lvimento de un1a
en1presa na Nova Inglaterra tinha un1 funcionário, um engenheiro de 50 anos, que
possuía dois mestrados en1 disciplinas de engenharia. Ele tinha trabalhado nos últi-
mos 20 anos en1 projetos em que podia trabalhar sozinho. O d iretor relutantemente
designou o engenheiro a uma equipe de projetos. Depois de anos trabalhando sozi-
nho, o engenheiro não confiava nos resultados de ninguém a lém dos seus próprios.
Ele se recusou a trabalhar cooperativamente com os out ros men1bros da equipe,
chegando até mesmo a refazer todos os cálcu los que lhe tin ham sido repassados por
outros engenheiros da equipe.
Para solucionar o problema, o diretor designou o engenheiro a um outro projeto
no qua l ele supervisionaria dois outros engenheiros co1n menos experiência. Nova-
mente, o engenheiro 1na is velho tentou fazer todo o tra balho sozinho, mesmo que isso
significasse horas extras para ele e nenhum tra balho para os outros.
Finalmente, o d iretor precisou admitir que algumas pessoas não são capazes de
t raba lhar cooperativamente em projetos de equipe. O direto r voltou a designar o enge-
nhei ro a projetos que envolviam apenas uma pessoa, nos quais as habil idades técnicas
do engenheiro seriam úteis.
Robert Hershock, antigo vice-presidente da 3M, u1na vez observou:
Há certas pessoas que você s implesmente não q uer colocar em equipes. Ela s não funcionam
bem em equi pe, e atrapalham o trabalho dos outros. Acho que temos de reconhecer isso e
garantir que essas pessoas não façam parte de uma equipe. Se você precisar de seus conheci-
mentos e experiência, pode trazê-las à equipe como cons ultoras, mas nunca, jamais coloque
. .
pessoas ass ,m na equipe.
Acho que u1na out ra coisa é que eu nunca, jamais eliminaria a possibilidade de
ninguém ser membro de uma equipe, independente do nível da gerência. Acredito que,
se t reinadas adequada1nente, essas pessoas podetn participar de um conceito de equipe
etn qua lquer nível.
Em 1996, Frank Jackson, antigo gerente sên ior da MCI, acred itava ser possível
encontr ar uma equipe com a qual qualquer indivíduo poderia contribuir:
As pessoas não devem ser rotuladas como a lguém que "não funciona bem em equipes ".
Todos têm a capacidade de participar de uma eq ui pe e de contribuir com ela com base
nas habi lidades e experiências pessoais que já tiveram. Se passarmos para o ambiente da
equipe, uma outra coisa que é muito impo rtante é não impedir a comunicação. A comu-
nicação é a chave para o sucesso de q ualquer equipe e qua lq uer o bjetivo que uma equipe
tente alcançar.
Un1 dos argumentos cruciais que ainda são expressos na con1unidade de gestão
de projetos é se un1 funcioná rio (até mesmo un1 gerente de projetos) deve ter o direi-
to de recusar un1a tarefa. Na M innesota Po,ver and Light, foi anunciado um cargo
aberto para gerente de projetos, n1as ninguém se cand idatou. A empresa reconheceu
que os funcionários provavelmente não con1preendian1 quais eram as responsabili-
dades que o cargo envolvia . Depois de mais de 80 pessoas terem sido treinadas nos
fundamentos da gestão de projetos, surgiram inúmeros candidatos para o cargo a ser
preench ido.
É uma sentença de morte designar algué1n ao cargo de gerente de projetos se essa
pessoa não for dedicada ao processo de gestão de projetos e à responsabilidade que
ele exige.
10.4 Equipes de projetos virtuais

Historicamente, a gestão de projetos era um ambiente presencia l no qual reuniões
de equipe envolviam todos os participantes que se encontravam em uma sala. Hoje,
devido ao tamanho e à complexidade dos projetos, é i1npossível encontrar todos os
membros de equipe loca lizados deba ixo do mesmo teto. Duarte e Snyder definem sete
1
tipos de equipes virtuais. Elas são apresentadas na Tabela 10-1.
Cu ltura e tecnologia podem ter um forte Ílnpacto sobre o desempenho das equipes
virtua is. Duarte e Snyder identificaram algumas dessas relações na Tabela 10-2.
É impossível ressaltar a importância da cultura o suficiente. Duarte e Snyder iden-
tificam quatro questões importantes a serem lembradas a respeito do impacto da cul-
tura sobre as equipes virtuais. As questões são as seguintes:2
1. Existem culturas nacionais, culturas organ izaciona is e culturas de equipes.
Elas podem ser fontes de vantagens co1npetitivas para as equipes virtuais
que souberem usar as diferenças culturais para criar sinergia. Os líderes e
membros de equipes que co1npreendem e são sensíveis a diferenças cu ltu-
ra is pode1n gerar resultados ma is robustos do que os membros de equipes
homogêneas que pensam e agem da mesma forma. Diferenças culturais po-
dem criar vantagens distintivas se forem compreendidas e usadas de formas
pos1t1vas.
2. O aspecto mais importante de compreender e t raba lhar com diferenças cultu-
ra is é criar uma cu ltura de equipe na qual problemas possam surgir e diferen-
ças possam ser discutidas de maneira produtiva e respeitosa.
1
D. L. Duarte e N. Tennanr Snyder, Masteri11g Virtual Teams. San Francisco: Jossey-Bass, 200 t, p. l O. Repro·
duzido com a permissão de John \Viley & Sons.
2
lbid., p. 70.
TABELA 10-1 Tipos de equipes virtuais
Tipo de equipe Descrição

Em re<le Os membros da equipe são difusos e fluidos; entram e saem quando neces-
sário. A equipe não possui limites claros dentro da organização
Em paralelo A equipe possui limites claros e membros bem definidos; trabalha no curto
prazo para desenvolver recomendações para uma melhoria em um processo
ou sistema
De desenvolvimento de projeto A equipe possui membros fluidos, limites claros e uma base de clientes,
ou produto requisitos técnicos e saldas bem definidas. Tarefas de mais longo prazo não
são rotineiras, e a equipe tem autoridade para a tomada de decisões
De trabalho ou produção A equipe tem membros bem definidos e limites claros. Os membros realizam
trabalhos regulares, normalmente em uma área funcional
De serviços A equipe possui membros definidos e oferece suporte a atividades continuas
relacionadas à rede de clientes
De gerenciamento A equipe possui membros definidos e trabalha de maneira regular para liderar
atividades corporativas
De ação A equipe lida com ações imediatas, normalmente em situação emergencial.
Os membros podem ser fluidos ou definidos
Fonte: O. L. Duarte e N. Tennant Snyder, Mastering Virtual Teams. San Francisco: Jossey·Bass, 2001, p. 10. Reproduz.ido
com a permissão de John Wiley & Sons.
TABELA 10-2 Tecnologia e cultura

Fator cultural Considerações tecnológicas
Distância do poder Membros de culturas com alto índice de distância do poder podem participar
mais livremente com tecnologias assíncronas que permitem contribuições
anônimas. Essas culturas às vezes usam a tecnologia para indicar diferenças
de status entre membros da equipe
Rejeição de incertezas As pessoas de culturas com alta rejeição de incertezas podem demorar a
adotar novas tecnologias. Elas também podem preferir tecnologias que são
capazes de produzir registros mais permanentes de discussões e decisões
Individualismo-coletivismo Membros de culturas altamente coletivistas podem preferir interações face a
face
Masculinidade-feminilidade Pessoas de culturas com orientações mais "femininas• tendem a usar tecnolo-
gias de forma mais cuidadosa, especialmente durante o início das equipes
Contexto Pessoas de culturas de alto contexto podem preferir tecnologias mais ricas
em informações, além daquelas que oferecem oportunidades para o senti-
mento de presença social. Elas podem oferecer resistência ao uso de tecno-
logias com baixa presença social para se comunicar com pessoas que elas
não conhecem pessoalmente. Pessoas de culturas de baixo contexto podem
preferir comunicações mais assíncronas
Fonte: D. L Duarte e N. Tennant Snyder, Mastering Virtual Teams, San Francisco: Jossey-Bass, 2001, p. 60.
3. É essencial distingu ir ent re problemas que resultam de d iferenças culturais e

problemas que ocorrem devido ao desempenho.
4. As práticas de negócios e a ética nos negócios variam e1n diferentes partes do
mundo . As equipes virtuais precisam a rticular claramente suas abordagens de
prática e ética nos negócios que sejam compreendidas e cumpridas por todos
os mem bros.
10.5 Recompensando as equipes de projetos

Hoje, a maioria das empresas utiliza equipes de projetos. Entretanto, ainda há desafios
no que diz respeito a como recompensar as equ ipes de p ro jetos por um desempenho
bem-sucedido. A importância do modo como as equipes são recotnpensadas é identifi-
3
cada por Pa rker, McAdams e Zielinski:
Algumas organ izações gostam de d izer "Todos nós fazemos parte da equipe", mas muito
frequentemente isso não passa de retórica gerencial. Isso é especialmente comum em orga-
nizações hierárq uicas convencionais; eles dizem as palavras, mas não as acompanh am com
ações significativas. Seus funcioná rios podem ler os artigos e ir às conferências e a té mesmo
acreditar q ue muitas empresas se tornaram colaborativas. Na verdade, porém, poucas orga-
nizações hoje são genuinamente voltadas para o trabalho em equipe.
Outras, que querem tergiversar, mostram como recompensam ou reconhecem as equipes
com planos espalhafatosos de bônus o u de participação nos lucros. No entanto, esses p lanos
por si só não representam um compromisso com as equipes; eles são mais como um presen-
te dado por um tio rico. Se a a lta gerência acredita q ue apenas dinheiro e a lguns programas
de reconhecimento ("eq ui pe do ano" e coisas parecidas) reforçam o trabalho em eq uipe, ela
está enganada. Tais fatores sozinhos não causam nenhuma mudança fundamenta l no modo
como pessoas e equipes são gerenciadas.
No entanto, em a lgumas o rganizações, a formação de equipes é um componente-chave
da estratégia corporativa, o envolvimento com as equipes é a lgo natural, e a colabora-
ção acontece sem grandes esforços ou fanfarras. Há grupos de trabalho naturais (eq uipes
de pessoas q ue fazem o mesmo tipo de trabalho ou trabalhos similares no mesmo loca l),
eq ui pes multifuncionais permanentes, equipes de projetos ad hoc e verdadeiras eq ui pes de
gerenciamento. O envolvimento simplesmente acontece.
Por que é tão difíci l recompensar as equipes de projetos? Para responder essa per-
gunta, temos que compreender o que u1na equ ipe é e o que ela não é:'
Considere a seguinte afirmação: uma unidade organizacional pode agir como uma equipe,
mas uma equipe não é necessa riamente uma unidade organizacional, pelo menos para des-
crever planos de recompensas. Uma unidade organizacional é apenas o seguinte: um grupo
de funcioná rios organizados em uma unidade de negócios identificável q ue aparece no grá-
fico organizacional. Elas podem se comportar no espírito do trabalho de equipe, mas, para
os fins de desenvolvimento de planos de recompensa, não são uma "equipe" de verdade. A
unidade organizacional pode ser toda uma empresa, uma unidade de negócios estratégica,
uma d ivisão, um departamento ou um grupo de trabalho.
Uma "eq uipe" é um peq ueno grupo de pessoas aliadas por um projeto comum e com-
partilhando objetivos de desempenho. Elas geralmente têm habilidades o u conhecimentos
complementares e uma interdependência q ue exige que elas trabalhem juntas para alcançar
o objetivo de seu projeto. Os membros de eq uipes responsabilizam-se mutuamente por seus
resultados. Essas equipes não se encontram no gráfico o rganizaciona l.
Incentivos são difíceis de apl icar porque as equ ipes de projetos poden1 não aparecer
em um gráfico organ izaciona l. A Figura 10-1 most ra o n1odelo de reforço para fu n-
cionários.5 Para as equipes de projetos, a ênfase é representada pelas três setas do lado
d ireito da Figura 10-1.
J G. Parker,J. McAdams e D. Zielinski, Reruarding Team.s, San Francisco: Jossey-Bass, 2000, p. 17. Reprodu-
zido com a permissão de John \-Viley & Sons.
' lbid., p . 17 .
' 5. Ibid., p. 29.
Custo (Pagamentos)
Custo de fazer negócios lnvestímento em resultados

Foco dos participantes
Unidade
Individual Equipe de programa organizacional
Remuneração- Capacidade Incentivos Reconhecimento Incentivos Incentivos

-base (competêncía) individuais às equipes às unidades
de projetos organizacionais
Figura 10-1 Modelo de reforço.
O s incentivos às equipes de projet os são importa ntes po rque os membros das

6
equipes esperam receber o recon heci1n ent o e recompensas apropriadas :
As equipes de projetos são norma lmente, mas nem sempre, formadas pela gerência para
tra ba lha r com projetos o u desafios espe.c íficos co m um prazo definido - revisar processos
para ma ior eficiência ou recomendações de economia de custos, o lançamento de um novo
produto de so(tu1are ou a implementação de sistemas de planeja mento de recursos em toda
a empresa são apenas a lguns exemplos. Em outros casos, as equipes se forma m sozinhas em
to rno de q uestões específicas ou como parte de inicia tivas de melhorias cont ínuas, como
sistemas de s ugestões baseados em equipes.
As equipes de projetos podem ter membros de diversas á reas funcionais o u simplesmen-
te ser um subconjunto de uma unidade o rganizaciona l existente. A pessoa que patrocina
a eq uipe - seu "defensor convicto" tipicamente c ria um plano de incentivos com med idas
obj etivas específicas e um c ronograma de premiação atrela do ao fato de essas med idas
serem alcançadas. Para se qualifica r como incentivo, o plano tem q ue incluir metas prede-
terminadas, como uma garantia de "faça isto e ganhe aquilo" para as equ ipes. O incentivo
normalmente varia de acordo com o valo r agregado pelo projeto.
Os planos de incentivo da equipe de projetos normalmente têm a lguma combinação
d essas med idas básicas:
• Marros do projeto: a lcance um ma rco, dent ro d o o rçamento e do prazo previstos, e
todos os membros da equipe ganharão determ inad a quantia . Embora na teoria seja
sólido a trela r incentivos financeiros ao alcance de ma rcos, ta l ação apresenta problemas
inerentes. Os ma rcos muitas vezes mudam por bons motivos (avanços tecno lógicos,
mudanças no mercado, outros acontecimentos), e você não quer que a equipe e a gerên-
cia entrem em uma negociação sobre atrasos nos prazos para estimular o incentivo. A
menos que os ma rcos sejam imutáveis e alcançá-los dependa simplesmente de a equipe
fazer o seu trabalho norma l e cotidiano, gera lmente é melhor usar uma celebração de
reconhecimento a pós o fato de se a lca nçar marcos ter sido consumado - em vez de atre-
la r incentivos financeiros a eles.
' lbid., p. 38- 39.

As recompensas nem sempre precisam esta r ligadas ao tempo, como aquela que quando a
equipe alcança um marco antes de determinada data, obtém uma recompensa . Se, por exem-
plo, uma equipe de desenvolvimento de produto depurar um novo software a tempo, esse não
é necessariamente um motivo para recompensá-la . Mas se descobre e soluciona um problema
imprevisto ou escreve um código melhor antes da data de entrega, merece uma recompensa .
• Condusão do projeto: todos os membros da equipe ganham determinada q uantia quan-
do concluem o p rojeto dentro do orçamento e prazo previstos (ou dentro dos padrões
de q ua lidade do defensor convicto da equipe).
• Valor agregado: esse prêmio depende do valor agregado por um projeto, e depende, em
grande parte, da habilidade da organização de criar e acompanhar med idas objetivas.
Exemplos incluem o tempo de resposta a solicitações do cliente, melho ria do tempo de
ciclo de desenvolvimento de produtos, economias de custo devido a eficiências de novos
processos ou lucros incrementa is o u participação de mercado criada pelo prod uto o u
serviço desenvolvido ou implementado pela equi pe de projetos.
Um alerta q uanto aos planos de incentivo de projetos: eles podem ser muito eficien-
tes em aj udar as equipes a se manterem no foco, alcançarem metas e se sentirem recom-
pensadas por seu traba lho pesado, mas tendem a ser excludentes. Nem todo mundo pode
pa rticipa r de uma equipe de projetos. Alguns funcionários (membros de eq ui pe) terão a
oportunidade de obter um incentivo q ue outros (não membros de equi pes) não terão. Há
uma desigualdade interna. Uma forma de aborda r esse problema é recompensar membros
da equi pe central por alcançar as metas da equipe e reconhecer participantes periféricos q ue
apoiaram a equi pe, seja por meio de conselhos, recursos o u uma ajuda mais prática, seja
substit uindo os membros da equipe de projetos em seu cargo original.
Algun s projetos têm tamanha importância estratégica que você se sente disposto a con-
viver com esses problemas de desigualdade interna e com as reclamações de não membros
de eq uipes sobre os incentivos excludentes. Ou seja, essa ferramenta deve ser usada com
cautela.
Algumas organ izações se foca lizam somente em recompensas em di nheiro . En-
tretanto, Parker et ai. concluíra1n, em sua pesquisa, que recompensas não monetárias
7
podem funciona r igualmente be1n, se não melhor, do que recompensas monetárias :
Nluitas de nossas organizações usam recompensas não monetárias devido ao seu poder de
permanência. Todo munda ama d inheiro, mas pagamentos em dinheiro podem perder seu
impacto motivacional com o tempo.
Entretanto, re.compensas não monetárias carregam o valor de um troféu, que possui
um grande poder de permanência, porque cada vez q ue você o lha para aquele aparelho de
TV o u placa comemorativa, você se lembra do q ue sua eq uipe fez para gan há-la . Cada um
dos planos encoraja recompensas que são cobiçadas pelos beneficiários e, portanto, serão
memoráveis.
Se você perguntar aos funcionários o que eles querem, eles invariavelmente d irão d i-
nheiro. No entanto, oferecer recompensas em d in heiro pode ser d ifícil se o orçamento for
peq ueno o u os ganhos oferecidos em um plano de incentivo forem modestos. Se você dis-
tribuir os incentivos com frequência maior do q ue uma vez por a no, a quantia líquida pode
parecer bem pequena, até mesmo avarenta. Re.compensas não monetárias tendem a depen-
der mais de seu valor simbólico do que de seu valor financeiro.
As recompensas não monetárias podem vir em q ua lq uer forma: um simples agradeci-
mento, uma carta de parabenizaç.ã o, uma folga remunerada, um troféu, mercadorias com a
marca da empresa, uma placa comemorativa, cartões-presente, serviços especiais, um jantar
para dois, um a lmoço grátis, um crédito em um cartão emitido pela empresa para compras
em lojas locais, itens ou mercadorias específicas, mercadorias de um extenso catálogo, via-
gens a negócios o u com a família, e opções de ações. Só a criativ idade e a imaginação dos
criadores do plano li mitam as escolhas.
7
lbid.,p.190- 191.
10.6 A chave da excelência comportamental

Há algumas ações distintivas que os gerentes de projetos podem empreender para ga-
rantir a conclusão bem -sucedida de seus projetos. Elas incluem:
• Insistir no direito de selecionar uma equipe de projetos com recursos-chave
• Negociar por membros da equ ipe-chave com históricos comprovados en1 suas áreas
• Desenvolver u1n compro1nisso e um senso de missão desde o início
• Procurar autoridade suficiente junto ao patrocinador
• Coordenar e manter u1na boa relação co1n cl iente, empresa matriz e equipe
• Procurar melhorar a imagem do projeto aos o lhos do público
• Fazer com que membros da equipe-chave auxiliem na to1nada de decisões e na
solução de problemas
• Desenvolver estimativas e 1netas rea listas de custo, cronograma e desempenho
• Manter estratégias alternativas (planos de contingência) em antecipação a possí-
veis problemas
• Propiciar uma estrutura de equipe que seja apropriada, mas flexível e horizonta l
• Ir alé1n da autoridade formal para maximizar sua influência sobre as pessoas e
decisões-chave
• Empregar um conjunto viável de ferramentas de planejamento e controle de
proJetos
• Evitar que se dependa de apenas u1n tipo de ferramenta de controle
• Enfatizar a importância de cumprir as metas de custo, cronogra1nas e desempenho
• Dar prioridade a alcançar a missão ou função do item final
• Manter as mudanças sob controle
• Procurar maneiras de garantir a segurança no emprego para membros eficientes
da equ ipe de projetos
Anteriormente neste livro, afirmei que um projeto não pode ser bem-sucedido a
menos que seja reconhecido como tal e ganhe o apoio a alta gerência. A alta gerência
deve estar disposta a investir recursos da empresa e oferecer o suporte administ rativo
necessário para que o p rojeto se torne parte da rotina cotid iana de fazer negócios.
Além disso, a organizaç.ã o matr iz precisa desenvolver uma atmosfera que conduza
a boas relações de traba lho ent re os gerentes de projetos, a organização matriz e a
organização cliente.
Há ações que a a lta gerência deve empreender para garantir que a organização
como um todo apoia projetos individua is e equ ipes de projetos a lém de um sistema
geral de gestão de projetos:
• Mostrar disposição pa ra coordenar esforços
• Demonstrar disposição para manter a flexibilidade est rutural
• Mostrar disposição pa ra se adaptar a mudanças
• Realizar um planejamento estratégico eficiente
• Manter a harmonia
• Dar a ênfase adequada às experiências passadas
• Fornecer buffering externo
• Comunicar-se rapidamente e co1n precisão
• Exibir entusiasmo
• Reconhecer que os projetos, na verdade, contribuem com as capacidades de toda
a empresa
Os patrocinadores executivos pode1n e1npreender as seguintes ações para tornar o

sucesso do projeto 1na is provável:
• Selecionar logo no início do projeto um gerente de projetos que tenha um históri-
co comprovado de habi lidades comportamentais e técnicas
• Desenvolver diretrizes claras e viáveis para o gerente de projetos
• Delegar autoridade suficiente ao gerente de projetos de modo que ele possa to1nar
decisões juntamente com os membros da equipe de projetos
• De1nonst rar entusiasmo e comprometimento com o projeto e a equipe de projetos
• Desenvolver e manter linhas de comunicação curtas e informais
• Evitar pressões excessivas sobre o gerente de projetos para que ele feche novos
contratos
• Evitar cortar ou inflar arbitrariamente as estin1ativas de custos da equ ipe de projetos
• Evitar "adesões" (b·u y-in)*
• Desenvolver relações de traba lho próximas, evitando int rometÍlnentos, entre o
principa l contato do cliente e o gerente de projetos
A organização cliente pode exercer u1na grande dose de influência sobre os aspec-
tos comportamenta is de um projeto minim izando as reun iões de equipe, respondendo
rapidamente a solicitações de ÍIÚormações e simplesmente pennitindo que a contrata-
da conduza os negócios sem interferências. As ações positivas das organ izações cliente
também incluem:
• Mostrar disposição para coordenar esforços
• Manter a harmonia
• Estabelecer metas e critérios razoáveis e específicos para o sucesso
• Estabelecer proced imentos para realizar 1nudanças
• Comunicar-se rapidamente e com precisão
• Compro1neter recursos do cliente no momento necessário
• MinÍlnizar a burocracia
• Delegar autoridade suficiente ao representante do cliente, especia lmente na toma-
da de decisões
Com essas ações como o fundamento básico, deve ser possível alcançar o sucesso
comportamental, que inclui:
• Encorajar a abertura e a honestidade de todos os participantes desde o início
• Criar uma atmosfera que promova uma competição saudável, evitando situações
hostis ou co1npetições de "que1n mente ma is"
• Planejar um financiamento adequado para concluir todo o projeto
• Desenvolver uma clara compreensão da importância relativa de custos, cronogra-
mas e objetivos de desempenho técnico
• Desenvolver linhas de comunicação curtas e informais e uma estrutura organiza-
cional horizontal
• Delegar autoridade suficiente ao principa l contato do cl iente e permitir a aprova-
ção ou rejeição imediata de importantes decisões de projeto
• Rejeitar adesões
• Tomar decisões rápidas em relação a dar "ok" ou " prossegu ir" em contratos
• N . de T.: Comprometer-se com uma decisão apenas por ter sido envoh•ido na formação do caso, mesmo
sem rotai certeza de estar cerro. O termo buy-;n nos jogos é considerado como a raxa de inscrição, o valor
necessário para fazer parte do jogo.
• Desenvolver relações de traba lho próximas com os participantes do projeto

• Evitar relações distantes
• Evitar esquemas de relatórios excessivos
• Tomar decisões rápidas quanto a mudanças
As empresas excelentes em gestão de projetos foram além das ações-padrão lista-
das anteriormente. Essas ações adicionais em busca da excelência incluem o seguinte:
• O gerente de projetos excelente possui as seguintes qua lidades demonstráveis:
• Compreende e demonstra coinpetência como gerente de projetos
• Trabalha criativa e inovadoramente em um sentido não t radicional soinente
quando necessário; não procura problemas
• Demonstra alto nível de automotivação desde o início
• Possui um alto nível de integridade; se mantém acima da politicagem e dos jogos
de poder
• É dedicado à empresa, e não somente ao projeto; nunca é interesseiro
• Demonstra humildade na liderança
• Demonstra fortes habi lidades de integração comportamental tanto Interna
quanto externamente
• Pensa de maneira proativa em vez de reativa
• Está disposto a correr grandes riscos e passa o tempo apropriado necessário
para preparar planos de contingência
• Sabe quando lidar com a complexidade e quando evitá-la; demonstra tenacida-
de e perseverança
• Está d isposto a ajudar as pessoas a perceberem todo o seu potencial; tenta des-
pertar o que há de melhor nas pessoas
• Comunica-se de forma rápida e com confiança em vez de desespero
• O gerente de projetos mantém altos padrões de desempenho para si Inesmo e para
sua equipe, como mostram as abordagens a seguir:
• Enfatiza a integridade gerencia l, operaciona l e de produtos
• Traba lha em confonnidade com códigos mora is e age eticamente ao lidar com
as pessoas Interna e externamente
• Nunca retém informações
• É consciente em relação à qualidade e ao custo
• Desencoraja a politicagem e os jogos de poder; enfatiza a justiça e a equidade
• Esforça-se pela melhoria contínua, Inas de maneira consciente em relaç.â o aos
custos
• O gerente de projetos excelente organ iza e executa o projeto de maneira sól ida e
eficiente:
• Informa os funcionários na reunião inaugural do projeto sobre como eles serão
avaliados
• Prefere uina estrutura organizacional horizontal a uma estrutura burocrática
• Desenvolve um processo de projeto para lidar com crises e emergências de ma-
neira rápida e eficiente
• Mantém a equipe de projetos sempre informada
• Não exige relatórios excessivos; cria uma atmosfera de confiança
• Define papéis e responsabi lidades de antemão
• Estabelece um processo de gerenciamento de mudanças que envolve o cliente
• O gerente de projetos excelente sabe como motivar:
• Sempre usa comunicação de duas vias
• Tem empatia com a equipe e é boin ouvinte
• Envolve os membros da equipe na tomada de decisões; sempre busca ideias e

soluções; nunca julga a ideia de um funcionário precipitadamente
• Nunca dá ordens
• Dá crédito a quem merece
• Faz críticas const rutivas em vez de ataques pessoais
• Dá crédito publicamente a quem merce, mas faz críticas de maneira privada
• Garante que os membros das equipes saibam que serão responsabilizados por
suas tarefas
• Se1npre 1nantém uma política de portas abertas; está prontamente acessível,
mesmo para funcionários com problemas pessoais
• Age rapida1nente sobre as queixas dos funcionários; é sensível aos sentimentos
e opin iões dos funcionários
• Permite que os funcionários tenha1n contato com os clientes
• Tenta determinar as capacidades e aspirações de cada membro da equipe; sem-
pre procura alguém que se enquadre ao perfi l necessário; preocupa-se com o
que acontecerá com os funcionários quando o projeto acabar
• Tenta agir como " intermediário" entre a equipe e problemas adm inist rativos/
. .
operac1ona1s
• O gerente de projetos é, em última análise, responsável por transformar a
equipe em um grupo coeso e produtivo para que haja un1 ambiente aberto e
criativo. Se o gerente de projetos é ben1-s uced ido, a equ ipe exibe os segu intes
comportamentos:
• Demonst ra inovação
• Troca informações livremente
• Está d isposta a aceitar riscos e a investir e1n novas ideias
• Possui as ferramentas e processos necessá rios para executar o projeto
• Ousa ser diferente; não fica satisfeita co1n si1nples1nente se igualar à concorrência
• Compreende o negócio e a econom ia do projeto
• Tenta tomar sólidas decisões de negócios e1n vez de apenas sólidas decisões de
proJeto
10.7 Gerenciamento proativo versus reativo

Talvez um dos maiores desafios comportamentais que um gerente de projetos precisa
enfrentar, especiahnente quando ele é inexperiente, seja aprender a como ser p roativo
em vez de reativo. Kerry Wills discute esse problema.
Propensão à capacidade de gerenciamento proativo8

No mundo de hoje, os gerentes de projetos geralmente são forçados a gerencia r vários pro-
jetos ao mesmo tempo. Isso normalmente res ulta em terem tempo apenas para reagir aos
problemas d o dia que cada projeto está enfrentando. O que eles não conseguem fazer é de-
dicar um tempo a olhar adiante em cada projeto para planejar trabalhos futuros, o que im-
plica mais emergências q ue precisam ser resolvidas imediatamente. Antigamente, havia um
jogo de fliperama chamado" ,vhack-a-mo/e", no qual o participante tinha de bater co m um
martelo em cada toupeira que saísse de buracos. Cada vez que ele acertava uma to upeira,
1
O resran.re desra seção foi fornecido por Kerry R. \Vills, P.M.r1'. Reproduzido com a permissão de Kerry R.
Wills.
s urgia uma nova . O ciclo de passar tempo resolvendo emergências e ignorando problemas
q ue causam mais emergências pode ser pensado como o ",vhack-a-mole dos projetos".
Na minha experiência, o gerenciamento proa tivo é uma das ferramentas ma is efi-
c ientes que os gerentes de p rojetos podem usar para garantir o sucesso de seus projetos.
Entretanto, é uma sit uação d ifícil gerenciar vários projetos e ainda ter tempo para p lane-
jar adiante. Chamo essa habilidade de dedicar tempo para planejar o futuro de "Propen -
são à capacidade de gerenciamento proativo" (PtvlCP, Proactive A1a11age111e11t Capaâty
Prope11sit.y). Este a rtigo irá demonstrar os benefícios do gerenciamento proativo, defin ir
a PtvlCP e propor mane iras de aumentar a PMCP e, ass im, a probabilidade de s ucesso
nos proietos.
Gestão proativa
A gestão de projetos envolve muito planejamento de antemão, incl usive p lanos de trabalho,
orçamentos, a locação de recursos, entre o utros. A melhor estatística q ue já vi sobre a preci-
são dos planos iniciais diz que há uma variância 30% positiva ou negativa em relação aos
planos originais no fina l de um projeto. Portanto, uma vez que se tiverem feito planos e o
projeto tiver começado, o gerente de projetos precisará reavaliar constantemente o projeto
para compreender o impacto dos 60o/o do desconhecido que irá ocorrer.
O dicionário define proativo como "q uem age antes de lidar com a dificuldade espera-
da" . Ao "agir com antecedência", um gerente de projetos consegue exercer a lguma infl uên-
cia sobre o controle do desconhecido. Entretanto, se deixar de agir com a ntecedência, os im-
pactos do desconhecido serão ma iores, já que o gerente de projetos só reagirá ao problema
q uando ele tiver se acumulado como uma bola de neve.
Uma metáfora: quando dirijo a té o trabalho, tenho um plano e um cronograma. Saio de
casa, pego certas ruas e estradas e chego ao trabalho em 40 minutos. Se eu tratasse dirigir
até o trabalho como um projeto {ter uma meta específica com um início e um fim finitos),
teria duas opções para gerenciar minha viagem [Fig ura 10-2]:
Ao gerenciar minha viagem proativa1ne11te, assisto o jo rnal na TV pela manhã para ver
a previsão do tempo e do tráfego. Embora eu tenha um plano, se houver uma obra em uma
das ruas que norma lmente pego, posso fazer mudanças nesse plano para pegar uma rota
d iferente de modo que meu cronograma ainda seja respeitado. Se sei que talvez haja neve,
posso sair mais cedo e me dar mais tempo para chegar ao trabalh o. Quando estou dirigindo,
o lho para a estrada Jogo adia nte para ver o que está a cam inho. Pode haver acidentes o u
buracos q ue queira evitar, e isso me dá tempo de trocar de faixa.
Uma abordagem reativa à minha viagem poderia ser supor que meu plano origina l irá
funciona r integra lmente. Q uando pego a estrada, se houver obras, terei de sentar e esperar,
porque quando percebo o impacto sobre meu plano o riginal, já passei de todos os viad utos
a
l l J J l l J J
~ ~
PROATIVO REATIVO
Figura 10-2 Metáfora da viagem ao trabalho.

de saída. Isso resulta em um atraso no cronograma. O mesmo ocorreria se eu fosse lá fora e

visse 30 cm de neve. Agora tenho um a chance de mudar o escopo, pois adicionei a atividade
de remover a neve da porta da minha casa e do meu carro. Além disso, se sou um motorista
reativo, não vejo o buraco a té já ter passado por ele (o que pode levar a uma variância no
orçamento, já que agora preciso de uma nova suspensão para o carro).
Benefícios
A metáfora acima demonstra que o gerenciamento reativo é negativo para os projetos,
pois q uando você percebe que existe um problema, ele norma lmente já está causando um
impacto sobre o cronograma, escopo o u custo. H á vários outros benefícios decorrentes do
. .
gerenciamento proat1vo:
• Gerenciar um plano proativamente permite que o gerente de projetos veja que ativida-
des estão a caminho e comece a se preparar para elas. Isso pode ser a lgo pequeno, como
agendar salas de conferência para reun iões. Já vi situações em q ue tarefas deixaram de
ser concluídas no tempo devido a problemas meramente logísticos.
• Compreender as ativ idades que estão a cam inho também perm ite q ue os recursos
adeq uados estejam preparados. M ui tas vezes, os projetos exigem o envolvimento de
pessoas de fora da equi pe de projetos e a linhá-las é sempre um desafio. Ao preparar
as pessoas com antecedência, existe uma probabilidade mais alta de q ue elas esteja m
prontas na hora em q ue é preciso.
A relação
• O gerente de projetos deve fazer constantes replaneja mentos. Ao o lhar para todas as
a tividades que estão por vir além de para as atuais, ele pode ter uma medida da proba-
bilidade de sucesso que pode ser gerenciada em vez de esperar a té um dia antes do prazo
final de alguma coisa para perceber q ue o c ronograma não poderá ser cumprido.
• O gerenciamento p roativo também permite q ue se focalize e se ded ique tempo à quali-
dade. O gerenciamento reativo normalmente é caracterizado por correr e tentar conser-
ta r o mais rápido poss ível q ua lquer " to upeira" q ue tenha aparecido. Isso normalmente
s ignifica fazer um remendo em vez de um conserto apropriado. Ao planejar o trabalho
adequadamente, ele pode ser tratado de modo apropriado, o q ue reduz a probabilidade
de retrabalhas.
• Q uando surgem trabalhos anteriormente não identificados, ele pode entrar nos planos
em vez de se supor q ue " podemos simplesmente incorporá-lo".
O gerenciamento proativo tem fortíssima influência sobre a probabilidade de sucesso de
um projeto, pois perm ite o replanejamento e a capacidade de abordar problemas antes de
eles terem um impacto s ign ificativo.
Panorama Observei uma relação entre a q ua ntidade de trabalho q ue um gerente de
projetos possui e sua capacidade de gerencia r proativamente. À medida q ue os gerentes de
projetos
.
pegam mais
.
trabalhos e projetos mais concorrentes, sua capacidade de gerenciar
proat1vamente ca i.
A relação entre a carga de trabalho do gerente de projetos e a capacidade de gerenciar
proativamente é apresentada na Figura 10- 3. Quando os gerentes de projetos possuem mais
trabalho, eles têm menos capacidade de ser proativos e acabam sendo mais reativos.
Nem todos os projetos e gerentes de projetos são iguais. Alguns gerentes de projetos
conseguem lidar com vários projetos muito bem, e a lguns projetos exigem mais foco do
que o utros. Portanto, chamei esse fator de Propensão à Capacidade de Gestão de Projetos
(PMCP, Project Ma11ageme11t Capacity Propensity). Isto é, a soma dessas q ua lidades que
permitem que um gerente de projetos gerencie projetos proativamente.
A PCMP Há vários fatores q ue formam a PMCP, que tracei abaixo.
Os conjuntos de habilidades do gerente de projetos influenciam a PMCP. Possuir boas
técn icas de gerenciamento do tempo e de organização pode influencia r q uanto um GP con-
segue se focalizar em o lhar adiante. Um gerente de projetos q ue é eficiente com seu tempo
tem a capacidade de analisar mais a tividades q ue estão a caminho e planejá-las.
Gerencíamento
reativo
PMCP
Gerenciamento
proativo
Carga de trabalho de gerente de projetos
Figura 10-3 Gráfico da proatividade.
Os conhecimentos d o gerente de projetos acerca do projeto também influenciam a

PMCP. Se o GP é especia lizado em negócios ou em projetos, isso pode possibilitar decisões
mais rápidas, já que não precisará buscar informações o u esclarecimentos (o que leva tem-
po) .
A PMCP também é in fluenciada pela composição da equipe. Se o gerente de projetos
estiver em um grande projeto e tiver vários líderes de equi pe que gerenciam os planos, eles
terão maior capacidade de se focalizar no replanejamento e em trabalhos que estão a ca-
minho. Além d isso, ter membros de equi pe que são espe.cializados em sua área exige menos
foco do gerente de projetos.
Aumentando a PMCP A boa notícia sobre a PMCP é que ela pode ser a umentada.
Os gerentes de projetos podem procurar maneiras de aumentar seus conjuntos de ha-
bilidades por meio de treinamento. Há vários livros e sem inários sobre gerencia mento de
tempo, priorização e organização. Participar deles pode aumentar a eficiência do tempo
gasto pelo GP nessas a tividades.
O GP também pode reavaliar a composição da equipe. Ao conseguir líderes mais fortes
para as equipes o u diferentes membros, ele pode diminuir s ua própria carga de trabalho e
passar mais tempo se focalizando no gerenciamento proativo.
Todos esses itens podem a umentar a PMCP e resultar em ma ior capacidade de gerenciar
proativamente. A Figura 10-4 mostra como um aumento na PMCP aumenta os parâmetros
e perm ite mais gerenciamento proativo com a mesma carga de trabalho.
Gerenciamento
reativo
PMCP ~G
fe-ra~n-.
cía
Lm_eLn7toL...J--'--:;;J.L....~~~~~~--'
proativo
Carga de trabalho de gerente de projetos
Figura 1Q-4 Aumentando a PMCP.

Conclusão
Gerenciar um projeto proativamente é a umenta r sua probabilidade de ser bem-sucedido.
Existe uma correlação direta entre a ca rga de traba lho de um gerente de projetos e s ua ca-
pacidade de o lha r adiante. Os gerentes de projetos têm controle sobre certos aspectos que
podem lhes dar ma ior ca pacidade de focar o gerencia mento proativo. Esses itens da PN!CP
podem ser a umentados por meio de treinamento e da equipe adequada.
Lembre-se de manter os olhos na estrada.
Medindo o retorno sobre
o investimento em treinamento
em gestão de projetos
11.0 Introdução
Por quase 30 anos, da década de 1960 à de 1980, o crescimento e a aceitação da
gestão de projetos se rest ringiu às indústrias aeroespacial, de defesa e de construção
pesada. En1 praticamente rodas as out ras indústr ias, era considerada "boa de ter",
n1as dispensável. Havia pouquíssimos progran1as de treinamento, e os que eram ofe-
recidos abordavam os fundamentos con1 a fraca tentativa de adaptar o material a
un1a empresa específica. O conceito de medi r o retorno sobre o investin1ento (ROi,
return on invest,nent) em treinan1ento, pelo menos en1 cursos de gestão de projetos,
era inexistente. Nos últimos 10 anos, houve vá rios estudos sobre a quantificação dos
benefícios da gestão de pr~etos, com alguns trabalhos pioneiros sobre os benefícios
do treinamento na área. 1,2 .• Não foi o suficiente, n1as pelo menos reconhecen1os a
necessidade.
Hoje, nossa visão sobre a forn1ação em gestão de projetos mudou, e mudou
também nosso desejo de ava liar o ROi sobre os fundos de treinan1ento. Há vários
. .
n1ot1vos para isso:
• Os executivos percebem que o treinamento é uma necessidade básica para as em-
presas crescerem.
• Os funcionários querem t reinamento para seu desenvolvimento profissional e
oportunidades de avanço na carreira.
• A gestão de projetos agora é vista como uma profissão em vez de como u1na ocu-
pação em regime de te1npo parcia l.
• A importância de se tornar PMP® tem aumentado.
• Há inúmeros programas universitários d isponíveis, que oferecem diplomas de
graduação, 1nestrado e doutorado em gestão de projetos.
1
W. Ibbs e J. Reginaro, Q1-1anafying the \!alue of Project Management, Newton Square, PA: Projecr Mana·
gemem lnsrirure, 2002.
2
\V. Ibbs e Y-H. Kwak, The Bene(,ts o/ Project Management, Newton Square, PA: Project Managemenr
lnsrirure, 1997.
J W. Ibbs, "Measuring Projecr X1anagemenr·s Value: New Direccions for Quanrifying PM/ROJ*··, in Proc.ee•
dings of the PMI Researd, Conference, June 21- 24, 2000, Paris, France.
' J. Knucson, A three-parr series in PM Network,January, February, and July 1999.
Capítulo 11 Medindo o retorno sobre o investimento em treinamento .. . 473
• Há programas certificados e1n vários conceitos de gestão de projetos co1no gestão

de r iscos e gerenciamento de programas.
• A pressão para n1anter a lucratividade corporativa aumentou, resu ltando em
menos dinheiro disponível para treinan1entos. Contudo, cada vez n1a is fundos
de treinan1ento estão sendo solicitados pelos trabalhadores que desejan1 se tor-
nar PMPs®e, então, precisam acun1u lar 60 unidades de desenvolvimento profis-
siona l (PDUs, pro fessional develop·m ent units) a cada t rês anos para manterem
sua certificação.
• A gerência percebe que uma parte significativa dos orçamentos de treinamento
tem de ser a locada para a formação em gestão de projetos, mas ela deve ser aloca-
da para os cursos que fornecem à empresa o maior ROi. Surge o conceito de ROi
educacional.
11.1 Benefícios da gestão de projetos

Nos primórdios da gestão de projetos, principalmente nas indústrias aeroespacial e de
defesa, foram feitos estudos para determinar seus benefícios. Em u1n estudo realizado
5
por Middleton, os benefícios descobertos foram:
• Melhor controle dos projetos
• Melhores relações com o cliente
• Menor tempo de desenvolvünento de produtos
• Menor custo de programas
• Maior qualidade e co1úiabilidade
• Maiores margens de lucro
• Melhor controle sobre a segurança do programa
• Melhor coordenação entre as divisões da empresa que estão t rabalhando no
proJeto
• Moral 1nais a lto e melhor orientação à missão para funcionários que estão traba-
lhando no projeto
• Desenvolvimento acelerado de gerentes devido à amplitude das responsabilidades
dos projetos
Esses benefícios foram identificados pela Middleton por meio de pesquisas e era1n
de natureza subjetiva. Não houve qualquer tentativa de quantificar os benefícios. Na-
quela época, praticamente não havia programas de treinamento em gestão de projetos.
O treinamento prático no traba lho era o método preferido de aprend izagem de gestão
de projetos, e a maioria das pessoas aprendia com seus próprios erros em vez de co1n
os erros dos outros.
Hoje, os benefícios identificados pela Middleton ainda se aplica1n, e adicionamos
out ros benefícios à lista:
• Realização de mais trabalho em menos tempo e com poucos recursos
• Desempenho mais eficaz e mais eficiente
• Aumento dos negócios devido à satisfação do cliente
• Desejo por uma parceria de longo prazo com os clientes
• Maior controle das mudanças de escopo
5
C. J. Middleron, "'How ro Ser Upa Project Organ.izacion··, Harvard Busin.ess Review, Jvlarch- April 1967,
p. 73-82.
Os executivos queriam todos os benefícios descritos aqui, e queriam os benefícios

"para ontem". É verdade que esses benefícios poderian1 ser obtidos simplesmente
con1 o uso de esforços de treinan1ento prático, mas isso supondo que o tempo fosse
um luxo, e não un1a restrição. Além disso, os executivos queriam que os funcioná rios
aprendessem com os erros dos outros en1 vez de com os seus próprios erros. Queriam
tan1bém que todos os envolvidos na gestão de projetos p rocurassem esforços de me-
lhorias contínuas en1 vez de apenas uma melhor prática ocasional.
Nem todo programa de t reina1nento em gestão de projetos se focaliza em todos
esses benefícios. Alguns cursos se concentram em um benefício específico enquanto
outros podem se focal izar e1n um grupo de benefícios. Decidir que benefícios você
deseja é essencial ao seleciona r um curso de treinamento. E se os benefícios puderem
ser quantificados após o término do t reinamento, os executivos podetn maximizar seu
ROi em t reinamento em gestão de projetos, selecionando apropriadamente as organi-
zações que oferecem treinamento.
11.2 O crescimento da modelagem do ROi

Nos últimos anos, a expansão globa l da modelagem do ROi assumiu o comando. A
Sociedade A1nericana de Treinamento e Desenvolvi1nento (ASTD, American Society
for Training and Development) realizou estudos sobre a modelagem do RO L6 Em todo
o mundo, associações profissionais estão conduzindo seminários, oficinas e conferên-
cias dedicadas ao treinamento em ROL
Segundo o Relatório Anua l de Treinamento de 2001, 1nais de US$66 bi lhões fo-
ram gastos em treinamento em 2011. Portanto, não é nenhuma surpresa que a gerên-
cia trate o treinamento com u1na mentalidade empresarial, justificando, assim, o uso
da mensuração do ROL No entanto, apesar de todo o co1npromisso em todo o mundo
e dos sucessos documentados, a inda há u1n medo muito real em 1nuitas empresas,
evitando o uso da modelagem do ROi. Argumentos típicos são: "Isso não se aplica a
nós", "Não podemos avaliar os benefícios quantitativamente", "Não precisamos dis-
so", "Os resu ltados não são relevantes", "É caro demais". Esses medos criam barreiras
à i1nplementação das técnicas do ROi, mas a maior parte das barreiras são mitos que
podem ser superados.
Na ma ioria das etnpresas, o desenvolvitnento de recursos humanos (DRH ) detém
o papel p rincipal na superaç.ã o desses medos e na realização dos estudos sobre o ROi.
O custo de realizar esses estudos continuamente pode ser tão a lto quanto 4'% a 5%
do orçamento do DRH. Algumas organ izações de DRH têm dificuldade em justificar
essas despesas. E, para piorar a situação, o pessoa l do DRH pode não compreender
muito bem a gestão de projetos.
A salvação para superar esses 1nedos e criar os programas apropriados de t reina-
mento pode mu ito betn ser o escritório de gestão de projetos (PMO, project ,nanage-
ment office). Como o PMO se tornou o guard ião de toda a propriedade intelectual da
gestão de projetos, a lém de criar os cursos de treinamento, ele muito provavelmente
assu1nirá a liderança no cálculo do ROi de cursos de treinamento relacionados à ges-
tão de projetos. Os membros do PMO podem ser solicitados a se torna r certificados
' J. J. Phillips, Return on /nvestment ;,r Training and Performance lmprovement Programs, 2nd ed., Burling·
ron, M.A: Butterworch-Heinemann, 2003, Chaprer 1. Na opinião do autor, esse é sem dúvida um dos melho·
res, senão o melhor, texto sobre esse assumo.
na mensuração do ROi educaciona l da mes1na forma que são certificados como PMP®
ou Fa ixa Preta do Seis Sigma.
U1n out ro motivo para usar o PMO é a metodologia da gestão de projetos empre-
saria l (EPM). O EPM é a integração de vários processos, como gestão da qualidade to-
tal, engenharia simultânea, melhorias contínuas, gestão de r iscos e controle de mudan-
ças de escopo em uma única metodologia de gestão de projetos que é util izada em toda
a empresa. Cada um desses processos possu i saídas 1nensuráveis que anteriormente
talvez não fossem acompanhadas ou relatadas. Isso colocou uma pressão adicional so-
bre o PMO e a formação em gestão de projetos para que eles desenvolvessem 1nétricas
e mensurações do sucesso.
11.3 O modelo ROi

Qualquer modelo usado precisa fornecer uma abordagem siste1nática para o cálculo
do ROL Ele deve ser preparado com uma abordagem baseada no ciclo de vida ou
uma abordagem passo a passo sim ilar a uma metodologia de EPM. Assiin como co1n
o EPM, há um critério essencia l que deve existir para que qualquer 1nodelo funcione
eficientemente.
Con1<> os critérios são considerados essenciais, qua lquer n1etodologia de RO i
deve atender à maioria dos critérios, se não a todos. A má notícia é que a ma ioria dos
processos do ROi geralmente não atende a todos esses critérios. Um n1odelo típico
é exibido na Figura 11- 1. As definições dos níveis na Figur a 11- 1 são n1ostr adas na
Tabela 11- 1.
Análise de dados
Tabelar
custo do
Planejamento 1 . _ l_ _ _ _ _ c_o_
ie_ta_d_e_d_a_do_s_ _ _ _ _ __, programa Gerar relatórios
Desenvolver
planos de avaliação Chegar
e dados de linha a urna
de base conclusão
e gerar
relatório
Isolar Identificar Transmitir

efeitos do L--.I benefícios informações
programa intangíveis aos grupos
alvo
Figura 11- 1 O modelo do ROi. Fonte: Adaptado de J . J. Phillips, Return on Jnvestment in Training
and Performance lmprovement Programs, 2nd ed., Bu rlington , MA: Butterworth-Heinemann, 2003
p. 37.
TABELA 11-1 Níveis de definição

Nível Descrição
1: Reação/satisfação Mede as reações dos participantes ao programa e possivelmente cria um pla-
no de ação para a implementação de ideias
2: Aprendizagem Mede habilidades específicas, conhecimentos ou mudanças de atitude
3: Aplicação Mede mudanças nos hábitos de trabalho ou desempenho no trabalho além
da aplicação e implementação de conhecimentos aprendidos
4: Impacto sobre os negócios Mede o impacto sobre os negócios em decorrência da implementação de
mudanças
5: Retorno sobre investimentos Compara os benefícios monetários com o custo do treinamento e os expressa
como um percentual
11.4 Fase do ciclo de vida dedicada ao planejamento

A prin1ei ra fase do ciclo de vida no modelo RO i é o desenvolvi men to dos planos
de ava liação e dados de lin ha de base. O _p la no de avaliação é sin1 ilar a algumas
áreas de con hecimento do Guia PMBOK"', que exigen1 um plano como parte do
prin1eiro passo do processo em cada área de conhecimento. O plano de ava liação
deve identificar:
• O(s) objetivo(s) do programa
• O(s) modo(s) como o (s) objetivo(s) serão va lidados
• O público-a lvo
• Premissas e rest rições
• A duração do programa
Os objetivos do programa de treinamento devem ser clara1nente defi nidos antes
da modelagem do RO i poder ser conclu ída. A Ta bela 11- 2 identifica objetivos típi-
cos. Os objetivos têm de ser cla ramente definidos pa ra cada um dos ci nco níveis do
modelo. A linha 3 da Tabela 11- 2 seria representativa dos obj etivos que uma empresa
pode ter quando regist ra um participante em um curso de treinamento de Programa
de Certificação em Gestão de Projetos (PMCP, Program Management Certificate Pro-
gratn ). Nesse exemplo, a empresa que fina ncia o trei na mento do participa nte pode
espera r que ele se torne PMP® e, então, auxilie a or~anização no desenvolvimento
de uma 1netodologia EPM baseada no Guia PMBOK"' co1n a expecta tiva de que isso
levaria à satisfação do cliente e a mais negócios. A linha 4 da Ta bela 11- 2 pode serre-
p resenta tiva de um a e1npresa que registra um participantes em um curso de mel hores
p ráticas em gestão de projetos. Algumas empresas acreditam que, se um participante
de um sem inário sair do progra ma de treinamento co1n duas boas ideias para cada dia
de programa e essas ideias puderem ser i1nplementadas com u1na rapidez razoável, o
semi nário será considerado um sucesso. Nesse exe1nplo, os objetivos são identificar as
mel hores práticas em gestão de projetos q ue out ras empresas estão fazendo e podem
ser i1nplementadas eficiente1nente na empresa do participa nte.
Pode haver di ferenças nos o bjetivos do treina1nento, aos ol hos da gerência. Como
exe1nplo, o bserva ndo as linhas 3 e 4 da Ta bela 11- 2, os objetivos podem ser:
• Aprender habilidades que podetn ser aplicadas imediatamente ao t rabalho. Nesse
caso, o RO i pode ser medido rapidamente. Isso pode ser representativo do curso
de PMCP na li nha 3.
• Aprender sobre técnicas e avanços. Nesse caso, deve-se investir ma is dinheiro para
alcançar esses benefícios. A mensuração do RO i pode não ser importa nte até de-
Capítulo 11 Medindo o retorno sobre o investimento em treinamento .. . 4 77
TABELA 11-2 Objetivos típicos de programas

Objetivos
Curso de treinamento típico
Nível Descrição Típico treinamento em PMCP em melhores práticas
1 Reação/Satisfação Compreender princípios do Guia Compreender que as empresas estão
PMBOK" documentando suas melhores práticas
2 Aprendizagem Demonstrar habilidades ou conheci- Demonstrar como as melhores práticas
mento em grupos de domínio e áreas beneficiam uma organização
de conhecimento
3 Aplicação Desenvolvimento de processos de DesenvolVer a biblioteca de melhores
EPM baseados no Guia PMBOK"' práticas ou maneiras de identificar as
melhores práticas
4 Impacto sobre os Mensuração da satisfação do cliente e Determinar as economias de tempo e/
negócios usuário com a EPM ou custo propiciadas por uma melhor
prática
5 Retomo sobre Quantidade de negócios ou satisfação Medir o ROi para cada melhor prática
investimentos do cliente gerada pela EPM implementada
pois de as técnicas terem sido implementadas. Isso pode ser representativo do

curso de 1nelhores práticas na linha 4.
• Utna combinação dos itens acima.
11.5 Fase do ciclo de vida dedicada à coleta de dados

A fi tn de validar que os objetivos de cada nível do curso de t reinamento foram alcan-
çados, é preciso coletar e processar dados. Os níveis 1-4 na Figura 11- 1 formam a fase
do ciclo de vida dedicada à coleta de dados.
Para compreender os métodos de coleta de dados, revisitamos o curso sobre me-
lhores práticas etn gestão de projetos, que cobre as melhores práticas implementadas
por várias empresas em todo o mundo. As seguintes premissas serão adotadas:
• Os participantes estão fazendo o curso para trazer de volta à sua empresa pelo
menos duas ideias que possam ser imple1nentadas em sua empresa dentro de seis
meses.
• Coletar PDUs é um benefício secundário.
7
• A duração do curso é de dois dias.
As abordagens típicas de coleta de dados são apresentadas na Tabela 11-3 e expli-
cadas aba ixo para cada nível.
Nível 1: Reação e satisfação

O nível 1 mede a reação dos participantes ao programa e possivelmente um plano
de ação para a implementação das ideias. A mensuração do nível 1 é norma lmente
um questionário de fim de curso no qua l o participante ava lia as infonnações apre-
sentadas, a qua lidade da instrução, material de instrução e outros assuntos similares
em u1na escala de 1 a 7. Mu itas vezes, o questionário é respondido de acordo com as
7
Algumas empresas têm cursos com duração de um dia, dois d ias e aré mesmo de uma semana sobre melho~
res práricas em gestão de projetos.
TABELA 11-3 Coleta de dados

Métodos e
instrumentos de Fontes Pessoa
Nível Medidas coleta de dados de dados Duração responsável
Reação/ Uma avaliação Questionário Participante Fim do programa Instrutor
satisfação com escala de 1 (último dia do
a 7 como crítica programa)
de fim de curso
Aprendizagem Pré-teste, pós- Testes em sala e Instrutor Gadadiade Instrutor
-teste, CDROM, e séries de práticas curso
estudos de caso de habilidades
Aplicação Discussão em Sessão de acom- Participante e/ou Três meses após PMO
sala de aula panhamento ou PMO o programa'
questionário
Impacto sobre Mensuração dos Monitoramento do Registros do Seis meses após PMO
os negócios esforços de me- custo-benefício PMO o programa
lhorias continuas peloPMO
da EPM
Retorno sobre Índices custo- Estudos do PMO Registros do Seis meses após PMO
investimentos -benefício PMO o programa
'Normalmente apenas para programas internos. Para seminários públicos, isso pode ser feito pelo PMO dentro de uma
semana após a conclusão do treinamento.
habi lidades de apresentação do instrutor e1n vez de com a qualidade das informações.
Embora esse método seja o mais comum e muitas vezes sirva como uma indicação de
satisfação do cliente, o que se espera que leve a negócios de repetição, não é nenhuma
garantia de que novas habi lidades ou conhecimentos tenham sido aprendidos.
Nível 2: Aprendizagem
Esse nível mede habi lidades específicas, conhecimentos ou mudanças de atitudes
aprendidas durante o curso. Os instrutores usa1n u1na variedade de técnicas de t reina-
ment o, como:
• Palestras
• Palestras/discussões
• Exames
• Estudos de casos (empresas externas)
• Estudos de casos (projetos internos)
• Simulação/dramatização
• Combinações
Para cada técnica de t reinamento, é preciso estabelecer u1n 1nétodo de 1nensura-
ção. Alguns instrutores oferecem um pré-teste no início do curso e um pós-teste no
fim. A d iferença de pontuação geralmente é representativa de quanto o participante
aprendeu. Isso normalmente é feito para programas de t reinamento internos em vez
de seminários públicos. Deve-se tomar cuidado com o uso de pré-testes e pós-testes.
Às vezes, u1n pós-teste é fáci l co1n a finalidade de fazer parecer que se aprendeu muito.
Testes fora da sala de aula também podem ser realizados usando estudos de caso que
os participantes levam para casa e questões de múltipla escolha em CD-ROMs.
Os testes são necessários para val idar que se aprendeu a lgo e se absorveram co-
nhecimentos. Entretanto, simplesmente ter havido aprendizado não é nenhuma ga -
rantia de que as infonnações aprend idas sobre as 1nelhores práticas podem ser ou
serão transferidas para a etnpresa. O aprendizado pode simplesmente confirmar que a
empresa está se saindo bem e acotnpanhando o r itmo de suas concorrentes.
Nível 3: Aplicação de conhecimentos

Esse nível mede mudanças nos hábitos de trabalho ou no desetnpenho prático, além
da implementação dos conhecimentos obtidos. A 1nensuração nesse nível normalmen-
te é feita por meio de sessões ou questionários de ava liação. Entretanto, para cursos
oferecidos pelo governo com um grande número de participantes, é impossível para o
instrutor fazer uma avaliação de acompanhamento com todos os participantes. Nesses
casos, a responsabilidade cai nas mãos do PMO. Os participantes podem ser solicita-
dos a preparar utn curto relatório de u1na ou duas páginas sobre o que eles aprende-
ram no curso e que melhores práticas são aplicáveis à empresa. O relatório é enviado
ao PMO, que pode ter a palavra final sobre a implementação de ideia is. Dependendo
da magnitude das ideias das melhores práticas, o gerente de portfól io de projetos pode
ser afetado. Entretanto, não há nenhuma garantia nesse ponto de que haja um impacto
positivo sobre os negócios.
Nível 4: Impacto sobre os negócios

Esse nível mede o impacto sobre os negócios em decorrência de uma implementação
de mudanças. Áreas típicas de mensuração são apresentadas na Figura 11- 2. Os ter-
mos crucia is da Figura 11- 2 são:
• Fator crítico de sucesso (FCS) : Mede as mudanças na saída do projeto, resultante
da implementação de melhores práticas. Espera-se que eles levem a melhorias etn
prazo, custo, qua lidade e escopo.
Objetivos
do projeto
Unidades de negócios
Satisfação Oportunidade [futuro)
do cliente de negócios
Processos/
metodologia
Apoio IKPIJ
Metodologia
executivo
Deliverables
(FCSJ
Custo Qualidade Escopo
Medidas
do projeto
Figura 11-2 Pirâmide post mortem. Fonte: De H. Kerzner, Advanced Project Management:
Best Practices in lmplementation, 2nd ed., Hoboken, NJ: Wiley, p. 302.
• Indicadores-chave de dese,npenho (KPI, key performance indicators): Medem as

mudanças no uso do sistema da EPM e o suporte recebido da gerência funcional
e da gerência sên ior.
• ltnpacto sobre a unidade de negócios: Medido pela satisfação do cliente em de-
corrência da implementação de melhores práticas e/ou oportunidades de negócios
futuros.
A mensuração no nível 4 é normalmente rea lizada pelo PMO. Há vários motivos
para tal. Pri1neiro, as infonnações podetn ser sigilosas para a empresa e indisponíveis
para o inst rutor. Segundo, como há um longo período de tempo entre o treinamento
e a itnplementação das melhores práticas, o instrutor pode não estar disponível para
suporte. Terceiro, a empresa pode não querer ningué1n de fora dela falando com seus
clientes sobre satisfação do cliente. E1nbora a implementação de melhores práticas
possa ter um impacto favorável sobre os negócios, deve-se to1nar cuidado para que ela
seja custo-efetiva.
Co1no 1nostra a Figura 11- 1, uma importante contribuição no nível 4 é isolar
os efeitos do treinamento. Geralmente é impossível identificar clara1nente o impacto
sobre os negócios que resulta diretamente do programa de treina1nento. O problema é
que as pessoas aprendem a gestão de projetos de d iversas fontes, co1no estas:
• Educação forma l
• Transferência de conhecimentos de colegas
• Experiência prática
• Pesquisas internas sobre melhorias contínuas
• Benchmarking
Devido à dificu ldade em isolar os conhecimentos específicos, esse passo geralmen-
te é negl igenciado.
11.6 Fase do ciclo de vida dedicada à análise

A fim de calcu lar o ROi, os dados relativos ao impacto sobre os negócios, do nível 4,
devem ser convertidos em um valor monetário. As informações podem vir de entre-
vistas com funcionários e gerentes, bancos de dados, especialistas em certos assuntos
e dados históricos. Muito raramente todas as informações necessárias vêm de uma
única fonte.
Uma outra contribuição necessária para a análise de dados é o custo do programa
de t reinamento. Custos típicos que devem ser considerados incluem:
• O custo da criação e desenvolvimento do curso
• O custo dos materiais
• O custo do(s) faci litador(es)
• O custo do loca l e de refeições oferecidas durante o treina1nento
• O custo de viagens, refeições e alojamento para cada participante
• O custo dos sa lários dos participantes com todos os encargos
• Custos adm inistrativos ou gera is relacionados ao curso de treinamento ou a abor-
dagem aos participantes para que eles façam o treinamento
• Possível custo (perda de receita) de não ter os participantes d isponíveis para ou-
tros t raba lhos durante o período do t reinamento
Ne1n todos os benefícios podem ser convertidos em va lores monetários. Esse é
o motivo para a existência do quadro "Identificar benefícios intangíveis" na Figu-
ra 11- 1. Alguns benefícios do impacto sobre os negócios que são facilmente converti-
dos em valores monetários incluem:
• Menor duração do desenvolviinento de produtos
• Decisões ma is rápidas e de qual idade 1nais a lta
• Custos mais ba ixos
• Margens de lucro 1nais altas
• Menos recursos necessários
• Redução da papelada
• Melhoria na qual idade e na confiabil idade
• Menor rotatividade de pessoal
• Implementação mais rápida das melhores práticas
Benefícios típicos que são intangíveis e não podem ser faci lmente convertidos e1n
valores monetários inclue1n:
• Melhor visibi lidade e foco em resultados
• Melhor coordenação
• Moral 1na is alto
• Aceleração no desenvolvimento de gerentes
• Maior controle sobre os projetos
• Melhores relações com os clientes
• Mais apoio funciona l
• Menos conflitos que exigem algum suporte da gerência
Embora esses benefícios possa1n ser intangíveis, deve-se fazer cada tentativa de
atribuir valores monetários a eles.
Nível 5: Retorno sobre investimentos

Duas fórmulas são necessárias para a conclusão do nível 5. A primeira fónnula é o
!BC, que pode ser formulado como
!BC = Benefícios do programa
Custos do programa
A segunda fórmula é o ROi expresso co1no um percentual. A fórmula se baseia

nos benefícios "líquidos" do programa, que são os benefícios menos os custos. Mate-
matica1nente, podemos descrevê-la como
Benefícios líquidos do programa
ROi = x100
Custos do programa
Para ilust rar a utilidade desse nível, considera1nos três exemplos, todos baseados
no mesmo curso de treina1nento. Você participa de um seminário de dois dias de du-
ração sobre melhores práticas em gestão de projetos. O custo para sua etnpresa para
que você participe do curso é:
Taxa de inscrição US$ 475

Tempo de liberação (16h a US$100/h) 1.600
Despesas de viagem 800
US$ 2.875
Ao fim do sem inário, você volta à e1npresa com três melhores práticas para reco-
mendar. Sua e1npresa gosta de todas as três ideias e o designa como gerente de projetos
para imple1nentar todas elas. Fundos extras precisam ser gastos para alcançar o bene-
fício desejado.
Exemplo 1
Durante o seminário, você descobre que muitas empresas adotaram o conceito de gestão
de projetos sem papel, implementando um sistema de relatório de status de "semáforo"'. Sua
empresa já possui um sistema de EPM baseado na web, mas você tem preparado relatórios
em papel para as reuniões de revisão de status. Agora, todas as reuniões de revisão de status
serão realizadas sem papel e com um projetor em LCD exibindo a metodologia baseada na
web com um mostrador em "semáforo"' ao lado de cada pacote de trabalho na estrutura ana-
lítica do projeto.
O custo de desenvolver o sistema de semáforo é:
Programação de sistemas (240 h a US$100/h) US$24.000

Gestão de projetos (150 h a US$100/h) 15.000
US$39.000
Os benefícios expressos em termos monetários são:
• Tempo dos executivos dedicado a reuniões de revisão de projeto (20 h por projeto a 10 h
por projeto x 15 projetos x 5 executivos por reunião x US$250/h): US$187.500
• Redução de tempo necessário para a preparação de papelada (60 h/projeto x 15 proje-
tos x US$100/h): US$90.000
• O benefício adicional total é, portanto, US$275.500:
IBC = US$275.000 - $39.000 = 82

US$2.875
US$275.000 - US$39.000 - US$2.875

ROi = = 8.109
US$2.875
Isso significa que, para cada dólar investido no programa de treinamento, houve um re-
torno de US$8.109 nos benefícios líquidos! Nesse exemplo, supôs-se que o salário dos tra-
balhadores com todos os encargos fosse de US$100/h, e o dos executivos, de US$250/h. Os
benefícios foram mensurações de um ano, e o custo de desenvolver o sistema de semáforo
não foi amortizado, mas descontado dos benefícios anuais.
Nem todos os programas de treinamento geram benefícios dessa magnitude. A Lear, em
Dearborn, Michigan, EUA, possui um sistema de relatórios de semáforo para a gestão de pro-
jetos como parte de seus sistema de EPM baseado na web. A Lear mostrou que, na mesma
quantidade de tempo que ela revisaria o status de um projeto usando papel, agora revisava o
status de todos os projetos usando os relatórios com semáforos.
Exemplo 2
Du rante o programa de treinamento, você descobre que outras empresas estão usando tem-
plates para a aprovação e iniciação de projetos. Você recebe os templates durante o treina-
mento e é necessário muito pouco esforço para torná-los parte do sistema de EPM e informar
Capítulo 11 Medindo o retorno sobre o investimento em treinamento .. . 48 3
a todos a respeito da atualização. Os novos templates eliminarão pelo menos uma reunião por
semana, com uma economia de US$550:
Benefício = (US$500/reunião) x (1 reunião/semana) x 50 semanas = US$27.500
US$27.500
IBC = = 956
US$2.875 '
US$27.500 - US$2.875
ROi = = 8,56
US$2.875
Nesse exemplo, para cada US$1 investido no programa de melhores práticas, foi reco-
nhecido um benefício de US$8,56.
Exemplo 3
Durante o programa de treinamento, você descobre que as empresas estão ampliando seus sis-
temas de EPM para se tornarem mais compatíveis com os sistemas utilizados por seus clientes.
Isso deve estimular maior satisfação do cliente. O custo de atualizar seu sistema de EPM para
passar a integrar geradores de relatórios para clientes diversos será em tomo de US$100 mil.
Depois do gerador de relatórios ser instalado, um dos clientes com os quais você tem
quatro projetos por ano lhe informa que está tão satisfeito com essa mudança que agora lhe
dará um contrato de fornecedor exclusivo. Isso resulta em economias significativas em custos
de aquisição. Sua empresa tipicamente gasta US$30 mil preparando propostas:
IBC = (4 projetos x US$30.000) - US$100.000

= 6,96
US$2.875
ROl(º/o) = (4 x US$30.000) - US$100.000 - US$2.875

= 596
US$2.875
•
Nesse caso, para cada dólar investido no programa de melhores práticas, foi recebido um
benefício líquido de US$5,96.
Até hoje, houve muito poucas tentativas de medir o ROi especificamente na formação
em gestão de projetos em vez de em trabalhos feitos pela Phillips. Entretanto, houve mais su-
cessos. Em uma empresa de seguros, foi empreendido um projeto de US$100 milhões. Todos
os funcionários tiveram de fazer um treinamento em gestão de projetos antes de trabalhar no
projeto. O projeto foi concluído 3% abaixo do orçamento.
Na incerteza de se a economia de US$3 milhões fora devido a uma melhor formação
em gestão de projetos ou à baixa qualidade das estimativas iniciais, a empresa realizou um
estudo sobre todos os projetos em que os funcionários eram treinados em gestão de projetos
antes de trabalhar em equipes de projetos. O resultado foi um surpreendente retorno de 700%
sobre o valor investido em treinamento.
Em uma outra organização, o pessoal do DRH trabalhou com gestão de projetos para
desenvolver um programa informatizado de treinamento em gestão de projetos. Os resultados
iniciais indicaram um ROi de 900o/o. Os trabalhadores fizeram o curso em seu tempo livre em
vez de no horário de trabalho.
Talvez essa seja uma indicação dos benefícios dos programas de aprendizagem digital
(e-Jearning). Os programas de e-Jearning podem produzir um ROi muito mais alto do que os
cursos tradicionais pelo fato do custo do curso ser significativamente reduzido com a elimina-
ção do custo de liberação dos funcionários de suas funções comuns.
11.7 Fase do ciclo de vida dedicada à geração

de relatórios
A fase final do ciclo de vida na Figura 11- 1 é dedicada a relatórios. É bem provável
que a aceitação dos resu ltados dependa de como o relatório é preparado. O rela-
tório precisa ser autoexplicativo para todos os grupos-alvo. Se forem adotadas pre-
missas quanto aos custos ou benefícios, elas devem ser justificadas. Se os valores do
ROi forem inflados para fazer um programa de treinamento parecer melhor do que
realmente é, as pessoas podem se tornar céticas e se recusarem a aceitar os resultados
de futuros estudos de ROL Todos os resultados devem ser factua is e respaldados por
dados rea listas.
11.8 Conclusões
Devido à quantidade e à profundidade dos programas de treinamento em gestão de
projetos, pode-se esperar que o concei to de mensuração do RO i sobre o va lor investi-
do cresça. Os executivos reconhecerão os benefícios dessa abordagem e sua aplicação
à gestão de projetos da mesma forma que ela se aplica a outr os programas de t reina-
mento. As organizações que oferecem treinamentos em gestão de projetos precisarão
demonstrar domínio da análise de ROL Por fim, o PMI ta lvez até estabeleça um grupo
de investigações especiais sobre a mensuração do ROi.
O escritório de projetos
12.0 Introdução
À 1ned ida que as e1npresas começam a reconhecer o efeito favorável da gestão de pro-
jetos na lucratividade, passa-se a enfatizar a importância de se atingir o profissiona lis-
mo na área usando o conceito de escritório de projetos (PO, project office). O conceito
de um PO, ou PMO (project manage,nent office), provavelmente é atividade de gestão
de projetos mais importante desta década. Com o reconhecitnento de sua importância,
vem o planeja1nento est ratégico, tanto para a gestão de projetos quanto para o escri-
tório de projetos. A maturidade e a excelência não ocorrem com o mero uso da gestão
de projetos ao longo de um longo período, mas por meio do planejamento estratégico
tanto para a gestão de projetos quanto para o PMO.
O planejan1ento estratégico geral envolve a dete rn1inação de onde você dese-
ja estar no futuro e, então, de como você planeja chegar lá. Para o planejan1ento
estratégico do PMO, ge ralmente é mais fácil decidir que atividades deven1 estar
sob o controle do PMO do que determinar como ou quando rea lizá-las. Para cada
atividade colocada sob os seus cuidados, podem surgir movimentos de resistên-
cia que inicialn1ente veen1 a ren1oção dessa atividade de sua área funcional con10
uma ameaça a seu poder e autoridade. Típicas atividades designadas a um PMO
incluen1:
• Padronização nas estimativas
• Padronização no planejamento
• Padronização na geração de cronogramas
• Padronização no controle
• Padronização na geração de relatórios
• Esclarecimento dos papéis e responsabilidades que gestão de projetos envolve
• Preparação de descrições de cargos para os gerentes de projetos
• Preparação de dados de a rquivo sobre lições aprendidas
• Benchmarking contínuo
• Desenvolvimento de templates para a gestão de projetos
• Desenvolvimento de uma metodologia de gestão de projetos
• Recomendação e in1plementaç.ão de n1udanças e melhorias à metodologia existente
• Identificação dos padrões do projeto
• Identificação de melhores práticas
• Realização do planejamento est ratégico para a gestão de projetos
• Estabelecimento de uma linha telefônica d ireta para a solução de problemas rela-
cionados à gestão de projetos
• Coordenação e/ou condução de progra1nas de treinamento em gestão de projetos

• Transferência de conhecimentos por meio de orientação e 1nentoria
• Desenvolvimento de um plano de capacidade/uti lização dos recursos corporativos
• Suporte às atividades do gerenciamento de portfólios
• Avaliação de riscos
• Planejamento para recuperaç.ã o de desastres
• Auditoria do uso da 1netodologia de gestão de projetos
• Auditoria do uso de mel hores práticas
Na pritneira década do século XXI, o PMO se tornou lugar-comum na hierarquia
corporativa. Embora a ma ioria das atividades designados ao PMO não tenha 1nudado,
havia uma nova 1n issão para o PMO:
• O PMO tinha a responsabi lidade de manter toda a propriedade intelectual rela-
cionada à gestão de projetos e de oferecer suporte ativo ao planejamento est raté-
. .
g1co corporativo.
O PMO atendia à corporação, especialmente às atividades de planejamento es-
t ratégico para a gestão de projetos, em vez de priorizar um cliente específico. O PMO
foi transformado em u1n cent ro corporativo de cont role da propriedade intelect ual
da gestão de projetos, que era uma necessidade, já que a magn itude das informações
cresceu quase que exponenciahnente em toda a organizaç.ã o.
Durante os últimos 15 anos, os benefícios do uso de um PMO para os níveis exe-
cutivos da gerência se tornaram aparentes. Eles incluem:
• Padronização das operações
• Tomada de decisões com foco na empresa em vez de em silos
• Melhor planeja1nento da capacidade (i.e., alocações de recursos)
• Acesso mais rápido a informações de ma is alta qualidade
• Elitn inação ou redução de si los na empresa
• Operações mais eficazes e eficientes
• Menos necessidade de reestruturação
• Menos reuniões, que roubam o tempo va lioso dos executivos
• Priorização ma is rea lista do t raba lho
• Desenvolvimento de futuros gerentes gerais
Todos os benefícios acima estão direta ou indiretamente relacionados à proprie-
dade intelectual da gestão de projetos. Para preservá -la, o PMO deve manter os veí-
cu los para captar os dados e, então, disseminá-los às várias partes interessadas. Esses
veículos inclue1n a intranet de gestão de projetos da empresa, sites de projetos, bancos
de dados de projetos e sistemas de informação de gestão de projetos. Como grande
parte dessas informações é necessária tanto para a gestão de projetos quanto para o
p lanejamento estratégico corporativo, é preciso haver o planejamento estratégico para
o PMO.
O reconhecimento da importância do PMO agora já se espa lhou por todo o mun-
do. Enrique Sevilla Molina, antigo d iretor corporativo do PMO da Indra, declara:
Temos um PMO no nível corporativo e PMOs locais em d iferentes níveis em toda a empre-
sa, realizando uma variedade de funções. O PMO no nível corporativo fornece orientações
sobre d iferentes questões de gestão de projetos, esclarecimentos sobre metodologias e sobre
o uso de ferramentas aos PMOs locais.
Além de oferecer suporte aos PMOs locais e aos gerentes de projetos mediante solicita-
ção, as principais funções do PMO corporativo incluem agir nas seguintes áreas:
• Manutenção e desenvolvimento da metodologia geral de gestão de projetos, inclusive as

extensões aos níveis de programa e portfólio
• Definição do material e processos de treinamento dos GPs
• Gerenciamento do processo de certificação de PMPs'" e treinamento e preparação dos
candidatos
• Definição dos requisitos para as ferramentas corporativas de GP
O PMO corporativo se reporta ao diretor executivo financeiro.
Utn típico PMO não gera lucro ou responsabil idade por perdas nos projetos, netn
gerencia projetos para clientes externos. Segundo Jim Triompo, vice-presidente sênior
de grupo da ABB:
O escritório de projetos não entrega projetos. Os projetos gerenciados pelo escritório
de gestão de projetos se limitam a desenvolvimento, implementação e treinamento em
processos/ferramentas. O escritório de gestão de projetos às vezes é so licitado a realizar
revisões, participar de revisões de risco ges tão nível das divisões e revisões operacionais
em vários países.
A 1naioria dos PMOs é vista como ,não de obra indireta e, portanto, sujeita a
reduções ou el iminações de pessoa l quando uma corporação passa por estresse finan-
ceiro. Para m inimizar esse risco, o PMO deve estabelecer métricas para mostr ar que o
PMO está agregando valor para a empresa. Métr icas típicas abrangem:
• Mensurações tangíveis, que incluem:
• Satisfação do cliente
• Projetos em r isco
• Projetos enfrentando problemas
• O número de setnáforos vermel hos que precisam de recuperação e que esforço
adiciona l exigem
• Pode haver também elementos intangíveis, e eles talvez não possam ser medidos.
• Identificação precoce de problemas
• Qualidade e rapidez das informações
1
12.1 B0eing
Nem todas as empresas usam o termo escritório de gestão de projetos. Em algu1nas,
ele ta tnbém é chamado de comunidade de excelência ou co1nun idade de prática. Cada
empresa possu i suas próprias metas e objetivos específicos para um PMO. Assim, as
responsabilidades do PMO podem variar de empresa para empresa. As informações a
seguir sobre a Boeing foram fornecidas por Kerry Braaflat - patr ocinador executivo
de gestão de projetos da Boeing; Stephen Markgraf - líder do escritório de gestão de
projetos empresarial da Boeing; Scott Sears - líder da comunidade de excelência em
gestão de p ro jetos da Boeing; Christine Baker - antiga líder da comunidade de exce-
lência em gestão de projetos da Boeing; e Sherry Kytonen - gerente de projetos sênior
de portfól ios:
O escritório de gestão de projetos empresarial da Boeing patrocina uma comuni-
dade de excelência em gestão de projetos (PjMCoE, Project Management Cotntnunity
1
© 201 3 by Boeing. Reproduzido com permissão. Todos os direitos reser\'ados.
of Excellence) que exemplifica as melhores práticas e promove a disciplina de gestão

de projetos em toda a Boeing Company.
Un1a comunidade de excelência (CoE) na Boeing é um grupo formal con1 seu
próprio estat uto que a linha funcionalmente pelo menos uma organização empre-
saria l, possu i uma representação e ten1 um compromisso com o engajamento em-
presarial: o compartilhan1ento e a aplicação de conhecimentos em toda a Boeing
Company.
O PjMCoE opera co1no um grupo de interesse voluntário co1n mais de 5.400
membros ativos na Boeing e é um dos maiores grupos de interesses da empresa. O
PjMCoE iniciou suas atividades em 1997 como u1n grupo de interesse formal em ges-
tão de projetos, que incluía apenas 75 1ne1nbros. A fina lidade de um PjMCoE pode ser
descrita como liderar e gerenciar um fórum de toda a Boeing para maior consciência
das habilidades, disciplina e profissão de gestão de projetos. O PjMCoE é a base do
sucesso da gestão de projetos na Boeing e oferece os seguintes serviços tanto aos seus
membros quanto aos seus negócios:
• Oferece um fórum de networking, colaboração e suporte
• Oferece mentoria, orientação e treinamento em gestão de projetos
• É anfitriã do grupo de estudo anual de PMPs®
• Auxi lia na contratação de gerentes
• Fornece os recursos adequados aos gerentes de projetos e às equipes de projetos
O PjMCoE possu i sua própria equ ipe de direção con1 responsabilidades defi-
nidas que oferecen1 suporte aos produtos e serviços do CoE e seu representante en1
tod os os grupos e locais operacionais da Boeing. A equipe de direção é a base pa ra se
alcançar o estatuto do CoE - facilita reuniões periódicas, supervisiona as operações
de um sistema de inforn1ações de gerenciamento eficiente, garante que todas as sol i-
citações de angajan1ento recebam un1a resposta e notifica as organizações al inhadas
ao ser contatada pelas equipes de p rojetos, programas ou funções com solicitações
de suporte.
Para auxiliar ao desenvolvünento continuado da habi lidade da gestão de projetos,
o PjMCoE oferece suporte aos seus membros propiciando o seguinte:
• Bibl iotecas contendo livros, periódicos, metodologias, software e apresentações
relacionadas à gestão de projetos
• SharePoint e site com informações sobre capítulos regiona is e notícias
• O conhecimento se centra em oferecer serviços de mentoria e orientação, a lém de
informações sobre certificados e diplomas em gestão de projetos
• Um grupo de estudo anua l de PMPs® que oferece 16 sessões de treinamento ao
vivo e gravado e lições aprendidas como a~oio à prepa ração para o exame de
PMP®. O p rimeiro grupo de estudo de PMP começou em 2000 e teve u1na taxa
de aprovação de 95% para aqueles que realmente fizeram o exame de PMP®. Em
2013, a reun ião inaugura l do grupo de estudos de PMP® contou co1n a presença
de mais de 400 funcionários
• Assistência para gerentes que estão procurando cont ratar ou promover gerentes
de projetos
• Reuniões bünestrais via \VebEx, recebendo pa lestrantes convidados e oferecendo
Unidades de Desenvolvimento Profissional usadas para acred itação
• Conferência anua l de gestão de projetos atraindo funcionários da Boeing e empre-
sas contratadas de todo o mundo
O PjMCoE mantém uma forte relação contínua com o PMI e é um Centro Re-
gist rado de Treinamento do PMI. Con10 ta l, fornece eventos de treinamento a cada
duas sen1anas para seus funcionários, oferece suporte aos instrutores para as aulas
de gestão de projetos específicas para a Boeing e oferece outros treinan1entos ad hoc
que fornecem aos funcionários da Boeing a oportunidade de obter Unidades de De-
senvolvin1ento Profissional para a recertificação de seus certificados de PMP®. Há
disponível tambén1 n1ódulos de treinamento em MS Project, Milestones Professiona l e
Gestão de Riscos, Problen1as e Oportunidades, Liderança e Gerenciamento de Comu-
nicações e de Equipes Virtuais. S0n1ente en1 2012, o PjMCoE ofereceu treinan1ento
a mais de 1O m il funcionários, oferecendo mais de 15 m il horas de oportunidades de
tre1nan1ento.
Muitos funcionários tiram proveito da 1nentoria e/ou serviços de consultoria para
auxiliá-los no desenvolvi1nento de carreira e habilidades de gestão de projetos. A men-
toria fornece também visibilidade de oportunidades tanto para gerentes quanto para
funcionários.
Em 2013, o PjMCoE fará parceria com a equipe de Cidadãos Corporativos Glo-
bais da Boeing para identificar oportunidades para gerentes de projetos se voluntaria-
rem para traba lhar em projetos de serviços de comunidades de suporte.
12.2 A Philips Healthcare e o Software

2
Customer Service
Excelência em gestão de projetos com um escritório de gestão

de projetos (PMO) global
Michael Bauer, líder do PMO Global de Software Customer Service (Serviços de Aten-
dimento ao Cliente via Software ) da Philips Healthcare, descreve como o PMO oferece
suporte para que um negócio de operação global de soluções de informática para
dados clínicos alcance a excelência em gestão de projetos.
O Software Customer Service da Philips Healthcare

A Philips é uma empresa forte e diversificada de saúde e bem-estar que opera em todas
as áreas geográficas globa is. Em tomo de 118 m il funcionários trabalham nos t rês
negócios de Saúde, Estilo de Vida do Consu1nidor e Iluminação.
3
A Phil ips Healthcare fornece inovações significativas que melhora1n a qualidade
do atendimento e a vida dos pacientes, e permitem a produção de resultados melhores
por custos mais ba ixos. A Phil ips Healthcare opera e1n cinco principais áreas de negó-
cios: Sistemas de Geração de Imagem; Patient Care and Clinicai Informatics (PCCJ -
Atendi1nento a Clientes e Infonnática de Dados Clínicos); Home Healthcare Solutions
(Soluções de Trata1nento de Saúde a Dom icíl io); Serviços G loba is de Atendimento ao
Cliente; e Serviços de Transformação de Tratamentos de Saúde.
A Ph ilips é líder mundial en1 soluções para cardiologia e ten1 forte presença nas
áreas de tratan1entos cardiopu ln1onares, oncologia e saúde da n1u lher. A en1presa
ajuda médicos a diagnosticar, t ratar e gerenciar as doenças mais prevalecentes de
hoje em d ia, como insuficiência cardíaca congestiva, câncer de mama e outros tipos
de câncer, doenças respiratórias e outras doenças da artéria coronária, da maneira
n1ais rápida, eficiente e eficaz possível. O foco é na con1preensão do ciclo completo
de cuidados de saúde - desde a prevenção de doenças e a detecção e diagnóstico até
2
€>201 3 by Philips. Reproduz.ido com permissão. Todos o s di reitos reservados.
J Ver também hrrp://www.healrhcare.philips.com/main/ para informações mais detalhadas.
o tratamento, monitoran1ento e o gerencian1ento de saúde - e escolher pa rticipar

das áreas em que a Ph ilips Healt hcare pode agregar um valor significativo. A Ph ilips
Healthcare acredita que a excelência clínica e as inovações contínuas em torno da
experiência do paciente pode fundamentalmente mudar os cuidados da saúde da
forma que os conhecemos.
O Patient Core and Clinicai 1nformatics (PCCI) fornece serviços de informática
para dados clínicos e soluções para cuidados com os pacientes que simplificam o fluxo
de t raba lho, melhoram os resultados financeiros e ajuda tn a melhorar e a salvar vidas.
O Software Customer Services (SCS) da Phil ips Healthcare implementa e oferece
suporte a projetos de soluções de informações clínicas em organizações hospita lares.
O SCS da Philips Healthca re oferece gestão de projetos, serviços de implementação e
soluções para cuidados com os clientes para garantir uma experiência superior para os
clientes em todo o ciclo de vida da solução. O SCS é uma organ ização globa l que ope-
ra em todo o mundo com um único foco: o sucesso na implementação e nos cu idados
com o cl iente para as soluções da Philips Healthcare Clinicai Jnformatics (Infonnática
Clínica da Philips Healthcare).
As soluções de Informática Clínica (baseadas e1n produtos de software a ltamente
configuráveis) oferecidas são:
• Sistemas de radiologia PACS (arquivamento de imagens e sistema de co1nun ica-
ções) e RIS (siste1na de informações e1n radiologia)
• Sistemas PACS de cardiologia
• Sistemas de informações cardiovasculares
• Sistemas de informações de cuidados clínicos intensivos, anestesia e obstet rícia
A amplitude da complexidade nos projetos de Informática Clínica abrange:
• Soluções independentes em consultórios de grupos ou em pequenos departamen-
tos
• Múltiplas aplicações em múltiplos departamentos
• lmple1nentação em vários hospitais
• Imple1nentações " inovadoras" em todas as moda lidades' e aplicações
Implementar projetos de Informática Clínica é uma atividade local rea lizada em
cada organização hospita lar em cada país, gera lmente no idioma loca l. O SCS opera
com recursos locais e centra lizados. Essa d isposição o rganizaciona l global/ loca l ge-
rahnente leva a um ambiente de t rabalho virtual com requisitos específicos para se
executar os projetos eficientemente. Os requ isitos e os níveis de maturidade etn cada
país/mercado e de cada cl iente hospitalar varia enorme1nente. Cada projeto em um
hospital é único e varia em duração (de semanas a anos), em ta1nanho (até projetos
multimil ionários) e e1n complexidade (de soluções independentes para apenas um mé-
d ico a soluções dist ribuídas regiona lmente para m ilhares de usuários).
O SCS está ciente de que cada organização deixa uma marca no cl iente, uma ex-
periência formada por aspectos raciona is e emocionais que determina o que os clientes
da Informática Clínica associa1n à marca Philips, o que a Philips significa para eles.
5
Isso é especia lmente pronunciado em um negócio de serviços. A experiência do cliente
está no cerne de uma relaç.ã o que se traduz em se os clientes repetidamente dependem
das capacidades da organização e as abraçam co1no a um conselheiro de co1ú iança .
• Por exemplo: modalidades de geração de imagens, como RX, IRM, TC.

5
Fontes dos conceitos de experiência do cliente: http://www.cxpa .orf/, hcrp://w,vw.cemkingroup.com/, http://
www.beyondphilosophy.com/.
Essa compreensão fundamental de vital importância para a expenencia do

cliente - o ,nodo como é criada e propiciada - ao fonnar a base de um sucesso con-
tinuado e diferenciação no mercado levou o SCS a assumir abordagem holística no
gerenciamento da experiência do cl iente. O SCS possui visão e est ratégia baseadas
na experiência do cliente e moldou a cu ltura e as operações necessárias para oferecer
suporte a essa visão.
O SCS aplica essa abordagem focal izada na experiência do cliente durante todo
o ciclo de vida da solução do motnento em que os clientes comparti lham sua visão e
encarregam a Phi lips de sua rea lizaç.ã o até a implementação da solução e aos cuidados
com o cliente após o início de suas operações. Nesse contexto, a Excelência em Gestão
de Projetos é utn ingrediente estratégico chave ao garantir o SCS confiavelmente e
propicia repetida tnente a experiência do cliente desejada. Logo, construir e sustentar a
excelência em gestão de projetos e alcançar utn alto nível de maturidade com projetos
de implementações de soluções de Informática Clínica é u1na ambição resoluta de im-
portância vita l tanto para o cliente quanto para a Philips.
Segundo a pesquisa Pulse of the Profession6, real izada em 2012 pelo Instituto de
Gestão de Projetos (PMI, Proiect lvfanagement lnstitute), apenas 73'% dos projetos
em organizações com u1na a lta maturidade em gestão de projetos a lcança seus obje-
tivos de negócios e sua intenção inicial. Para o Software Cttstomer Services da Ph ilips
Healthcare, as a tnbições de uma implementação de projetos bem-suced ida são altas e
exigem utn a lto grau de maturidade em gestão de projetos para um negócio de Infor-
mática Clínica. Esse foi o principa l direcionar est ratégico para a implementação de um
PMO global. O SCS usa o termo Excelência em Gestão de Projetos com o foco nos
. .
seguintes aspectos importantes:
• Pessoas: Gerentes de projetos (e equipes de projetos) com alto nível de educação,
certificados, habilidosos (envolvendo tanto habi lidades técnicas quanto compor-
ta tnenta is) e continuamente t reinados com u1na menta lidade profissional, apa-
rência e comportamento. Isso também inclui recrutar os melhores talentos para o
7
cargo de gerente de projetos.
• Processos: Processos a ltamente eficientes, padronizados, repetíveis e bem docu-
mentados, que são continuamente aprimorados.
• Ferramentas: Ferramentas alta tnente integradas e eficientes, templates e apl icações
da aquisição até o final do projeto.
A excelência em gestão de projetos não é vista como um objetivo estático; a ambi-
ção é continuamente elevar os parâmetros da maturidade em gestão de projetos, alétn
de supervisionar as competências gerais de gestão de projetos (GP) e a capacidade de
entrega dos projetos.
Escritório de gestão de projetos

O estabeleci tnento de um escritório de gestão de projetos (PMO) foi uma clara decisão
estratégica e teve apoio total da alta gerência para dirigir a gestão de projetos estra-
8
tegica tnente. O PMO possibilita a ambição da Excelência em Gestão de Projetos, em
que os seguintes aspectos precisam ser realçados:
• Fonte: P/vll"s Pulse of the Profession March 2012, p. 6.

1
Sobre a importância do gerenciamento de talemos na gestão de projetos, ver também: PMI"s Pulse of the
Profession ln Deptl, Study: Talent Management, March 2013.
1
Ver também a importância do suporte esrracégico da gestão de projetos: Plvfl's Pulse of tl,e Profession,
March 2013, p. 3.
• A excelência em gestão de projetos importa para o SCS - aspecto -chave para ava-
liar e aprimora r habilidades, processos e ferramentas.
• Gerenciamento de mudanças - identificar, dirigir e imple1nentar melhorias e mu-
danças na organização.
• Padronização - permitir práticas padronizadas e processos em todos os do1nínios
e regiões do produto. 9
• Aprendizagem contínua - t reinar, revisar e oferecer mentoria quando necessário.
• Facilitação de uma Comunicade de Prática de GP - aspecto-chave para possi-
bi litar o c<~,n~.;3rtilha1nento, a aprendizagem, a alavancagem, o networking e a
comun1caçao.
Ao const ruir o Escritórios de Gestão de Projetos (PMO), as seguintes condições
foram consideradas:
1. Posicionamento do PMO: Especial istas sênior em gestão de projetos que
orienta1n a organização durante as mudanças em busca da excelência em
gestão de projetos com um forte gerenciamento de mudanças.
2. Foco do PMO: O PMO propriamente dito não implementa projetos de in-
teração com o cliente nos próprios hospitais, mas se focaliza em oferecer
suporte ao gerente de projetos/equipes de projetos locais.
3. Consultor de gestão de pr ojetos: A implementação de um cargo dedicado de
especialista sênior em determinadas áreas para prestar consultoria para os
gerentes de projetos e1n todos os países. O objetivo do cargo de consultor em
gestão de projetos é pro1nover os processos, ferramentas e metodologias de
gerenciamento, de modo que elas realmente reflitam as ambições de excelên-
cia em gestão de projetos.
4. Suporte ao projeto: A Ílnplementação de u1n cargo operacional dedicado de
gestão de projetos para oferecer suporte às operações manté1n as várias pla-
taformas de co1npartilhamento de informações e conhecimentos e t reinamen-
. .
tos e1n aspectos operac1ona1s.
5. A integração do PM O às operações e às regiões geográficas: O PMO global
é altamente conectado às organizações de implementação do projeto nos res-
pectivos países para permitir um forte alinhamento. Os membros da equi-
pe do PMO se encontram em várias local idades, possibilitando um alcance
reahnente global.
Serviços oferecidos pelo escritório de gestão de projetos

Todos os serviços de PMO são posicionados em torno dos gerentes de p rojetos. Os
gerentes de projetos são centra is para todas as áreas de iniciativas e projetos do PMO,
como mostra a Figura 12-1.
• A área de iniciativa " Habilidades e Competências" se focaliza em todos os aspec-
tos para treinar, formar e certificar os gerentes de projetos (e as equipes de proje-
tos). Isso inclu i os seguintes serviços:
• Criar e manter o currícu lo de gerente de projetos do SCS
9
"As organizações de alto desempenho têm quase rrês vezes mais chances do que as organizações de baixo
desempenho (36% versus 13%) de usar práticas padronizadas em roda a organização e, em decorrência disso,
rêm projetos com melhores resultados." Fonte: PM/'s Pulse o/ the Profession., March 2013, p. 10 .
0
' Ver rambém hcrp://wenger-crayner.comflnrro-ro-CoPs/ para informações mais detalhadas sobre a Comun.i·
dade de Prática (CoP, Conmumity of Practke).
Habilidades e
competências do GP
Comunidade de
prática do GP
Ferramentas,
processos e
metodologia do GP
Figura 12- 1 Diagrama da pirâmide de excelência em projetos.
• Organ ização do treinamento de preparação para a certificação PMP®/CAPM 11

do PMI e Prince2 Foundation and Practitioner
• Organ ização do treinamento específico do SCS, conferências e webinars
• Mentoria dos novos gerentes de projetos
• Criação de treinan1entos en1 torno das ferramentas/processos/metodologia internas
• Facilitação do compartilha1nento e gerenciamento de melhores práticas, lições
aprendidas e conhecimentos
• Gerenciamento de ta lentos
• A área de iniciativa " Ferramentas, Processos, Metodologia" foca liza-se em todos
os aspectos para aprimorar ferramentas, processos e metodologias, o que inclu i os
. .
seguintes serviços:
• Padronização das práticas e processos de gestão de projetos
• Design da estrutura de gestão de projetos da SCS: SUCCESS 2.0
• Melhoria da pa isagen1 do sistema de TI relacionada à gestão de projetos
• Criação de templates (p.ex.: ET, EAP, regist ro de riscos) adaptados às metodolo-
gias usadas e a negócios relacionados
• Suporte a todas as melhorias por um forte gerenciamento de mudanças
11
Profissional de Gerenciamento de Programas (Program Nfanagement Professional, PM~)/ Associado Cer·
tificado em Gestão de Projetos (Certified Associare in Projec.r Management, CAPM) do lnscirum de Gerencia·
memo de Programas (Program Management lnst;tute, PMI).
• A área de iniciativa "Operações" focal iza-se em todos os aspectos para facilitar a

vida dos gerentes de projetos (e seus gerentes) a partir de uma perspectiva opera-
cional:
• Suporte a projetos específicos que estejam enfrentando proble1nas, recuperação
de projetos, verificação da "saúde" de projetos
• Suporte às operações do projeto na est rutura do sistema
• Manutenção das plataformas para compartilhamento de informações e conhe-
cimentos
• Treinamento em aspectos operaciona is
• KP!s e relatórios
• Comunicações padronizadas.
Comunidade de Prática do Gerente de Projetos
Como já foi mencionado, os gerentes de projetos são centrais pa ra os serviços do
PMO, particulannente para a Comunicade de Prática (CoP, Comrnunity of Practice) .
12
Uma CoP possui as seguintes características:
1. Domínio de interesse comparti lhado (gestão de projetos)
2. Seus membros são p raticantes (gerentes de projetos)
3. Envolvimento dos membros e1n atividades conjuntas
O PMO G lobal oferece suporte e facilita a CoP a desenvolver um trabalho em
equ ipe próximo com uma equipe cent ral da CoP. Tal equipe consiste em gerentes de
projetos voluntários de d iferentes regiões geográficas. Os objetivos da CoP de GP do
SCS são comparti lhar, aprender, incentivar, estabelecer networking e comunicar entre
os gerentes de projetos. O envolvimento na CoP varia de membros contribuidores
muito ativos a uma participação passiva. Além disso, a CoP de GP é uma 1naneira de
estiinu lar os gerentes de projetos a compartilhar informações.
A troca de informações na própria CoP ajuda a const ruir competências individuais
e de grupo, resolver problemas e evitar a "reinvenção da roda". A CoP propriamente
d ita também oferece um mecanismo de feedback ao PMO para ajudar a aprimora r e
desenvolver seus serviços e seu direcionamento futuro por meio de várias ferramentas
(p.ex.: ao usar a tecnologia de enquetes, a CoP pode oferecer aconsel hamentos sobre
p referências e prioridades). Desde o início, os gerentes de projetos estão envolvidos
ativamente, e sua voz é levada em consideração.
As atividades incluem reun iões on-line periód icas para trocar informações so-
bre assuntos cent rais e oferecer suporte à preparação de t reinamentos e conferências
p resencia is, além de constru ir novos a rtefatos na criação de novos conteúdos para o
domínio de um produto específico ou processos de gestão de projetos. As reun iões
on-line da CoP são um sucesso repetido. É a melhor manei ra de obter feedback instan-
tâneo da comunidade para a comunidade.
Processos
No Software C11stotner Services são usados processos e metodologias-padrão em todo
o ciclo de vida de u1n projeto. A Figura 12- 2 fornece um panorama:
Ela mostra co1no os processos da Philips Hea lthcare são estrutu rados, como os
grupos de p rocessos do PMI são mapeados e como as est ruturas de processos se super-
põe1n para que haja uma passage1n suave entre d iferentes áreas de responsabi lidade
do ses.
12
Fome: hnp:/lwenger-crayner.com/fnrro-m-CoPs/.
'5
:. 0 0
~
i!" ~~
~
~
0e
~8 1!;; ili '5
~0 lQ :; li! :.
!'~ ~ !l, ~ i!
e ~
e~
.. 0
$l1!
~ o
Ou
~-
$l ·~
o"'
Processo da • • .r. . , O 11 Atendimento ao cliente Customer carc
Phili p:s Healthcate
Grupos de Monitoramento e conttole

processos PMJ lnlcl ão Plane men10 Execução Encerramento
Fases Pré-venda PóS·lf'líclo das operações
Ge,eoctamento de
P,oposta de venda
} SUCCESS 2.0
Es1rutum de
processos ) ITJL'!I
Processos 00 experiência do chcntc
liderança e1ente de propostas Gmentc de serviços 00 atendimento ao d1cntc

Gerente de c-x crienc1a õo cliente
GP olerece sq:,one às YMdas a Al!ndmtt110 ao clieott Olerece svpone ao pro,eto
Figura 12- 2 Panorama dos processos e metodologia padrão.
• R ecebimento de pedidos: um forte t rabalho em equipe ent re o departament o de

vendas e a gestão de projet os é extremamente importante nos projetos de soluções
de Informática Clínica após um processo definido de Gerenciament o de Propostas
de Venda.
• R ealização de pedidos: SUCCESS 2.0 é a est rutura de gestão de projet os do SCS
que oferece suporte a marcos, templates, aceitação, geração de relatórios, etc. - to-
dos consistentes co1n o PMI e o Prince2 juntamente com as melhores práticas e1n
infonnática clínica. O SUCCESS 2.0 está intimamente relacionado ao Processo de
Gerenciament o de Propostas de Vendas e permite uma passagetn suave para a área
de Atendi1nento ao Cliente.
• At endimento ao Cliente: o ITIL® 13 é uma melhor prática da indústria para estabe-
lecer um conceito de serviços em TI de última geração e extre1namente eficiente.
• Exp eriência do Cliente: para t ornar a experiência do cliente atual visível e1n di-
ferentes marcos do projeto e, posteriormente, na fase de atendimento ao cliente,
os cl ientes são convidados, em pontos de conta to específicos do ciclo de vida do
software a compartil har seu feedback com a organização do SCS. O processo de
pesquisa cont inua além das implement ações e atualizações, com suporte e manu-
tenção contínuos. O feedback é recebido e avaliado sob o aspect o de congruência
com a experiência do cl iente desejada, ident ificando áreas que necessitam apri1no-
ramentos e aprendendo sobre os pontos fortes em relação à Excelência em Gestão
de Projet os e, posteriormente, em Atend imento ao C liente. Esse processo em loop
fechado é uma abordagem extrema1nente eficiente e característica essencial de
uma organização com aprendizagem e melhorias contínuas.
u mL• (IT ln.frastrucrure Library ou Biblioteca de lnfraesrrurura em 11) desenvolvida pelo Office of Gover~
nment in Commerce (OGC) no Reino Unido.
Uma importante lição é que os d iferentes processos estão todos inter-relacionados

e, assim, quebram a t radiciona l abordagem de silos. A co1nunicação e o trabalho em
equipe são alguns dos aspectos essenciais que prevalecera1n durante as definições des-
ses processos. Especiahnente em uma organização global como o Ph ilips Healthcare
SCS, é i1nportante i1nplementar, treinar e aprimorar processos harmonizados e padro-
nizados. E importante também que todos use1n o mesmo jargão de gestão de projetos
e e1npreguem os mesmos termos. Esse é um dos motivos pelos quais todo gerente de
p rojetos do SCS precisa ter certificação de PMP® (para o Reino Unido e Irlanda é o
Prince2 Foundation & Practitioner, segundo as necessidades do 1nercado), ser t reina-
do na estrutura SUCCESS 2.0 de gestão de projetos e ter certificação pelo menos nos
Fundamentos do !TIL®.
Principais lições da excelência em gestão de projetos global com um PMO global

As principa is lições para alcançar a Excelência em Gestão de Pro jetos com u1n PMO
globa l podem ser resu1n idas desta fonna:
• Embora a Excelência em Gestão de Projetos não seja um objetivo absoluto por si,
é considerada uma maneira proativa de prever e atender às necessidades da Indús-
tria de Informática Clínica.
• A Excelência e1n Gestão de Projetos não é um objetivo estático. Exige melhorias
contínuas em torno de Pessoas, Processos e Ferramentas.
• Um PM O é um possibilitador essencial da Excelência em Gestão de Projetos, em
que u1n foco sobre papéis e configurações específicas é mui to importante pa ra o
sucesso.
• Uma Comun idade de Prática de gerentes de p ro jetos é uma abordagem de ponta e
uma melhor prática essencial e reconhecida para Comparti lhar, Aprender, Incenti-
var, Estabelecer Networking e Co1nun icar.
Harmon ização e padro nização de processos é ext rema1nente importante para o
sucesso de uma organização que opera globa lmente. Uma forte integração nos proces-
sos a montante (p .ex.: vendas, gerenciamento de propostas) e processos subsequentes
(p.ex.: atendimento ao cliente) são 1nuito importantes também. Esse fato tem que ser
apoiado por um sólido gerenciamento de mudanças e atividades de treina1nento.
14
12.3 maxlT-VCS
A max!T-VCS possui um PMO q ue serve de "casa" para todos os nossos consultores de
gestão de projetos. O PMO se reporta diretamente ao nosso vice-presidente sênior, q ue se
reporta ao nosso CEO. O grupo entra na estrutura matricia l de nossas d ivisões funcionais
o u práticas específicas. O PN!O atende à empresa de duas principais maneiras (interna e
externamente). Internamente, oferecemos aos funcionários um plano de carreira em gestão
de projetos que inclui acesso a metodologias e a padrões além de oportunidades de estudo
(i.e., credenciais de PMP"' do PMI) focalizados exclusivamente em gestão de projetos. Exter-
namente, oferecemos aos nossos cl ientes serviços ligados à gestão de projetos em tecnologia
de informação na área de sa úde. Tais serviços incluem gerentes de projetos certificados com
experiência na indústria (a méd ia na VCS é de 14 anos). Oferecemos também suporte com
a metodologia e as ferramentas para construir a fundação de um PMO por meio de nossa
14
O material sobre a maxlT-VCS foi fornecido por .M.arc Hirshfield, PJvU,;t> e diretor do escritório de gestão
de projetos da maxlT· VCS.
solução PMO JumpStart. A maxIT-VCS oferece serviços de s uporte à gestão de projetos e

programas à nossa base de clientes há aproximadamente sete anos.
A maxIT-VCS decidiu investir e criar o PMO para atender tanto à demanda interna
quanto à externa. Internamente, o PMO permite que a maxIT-VCS ofereça uma "casa"
e um plano de carreira para os funcionários que q ueiram se focalizar exclusivamente em
gestão de projetos, passando a propiciar oportunidades em diferentes pacotes de so(Jware e
uma metodologia formal e abordagem documentada para a administração de uma iniciati-
va (projeto) de TI na área de saúde. Externamente, a tendeu às necessidades de nossa base de
cl ientes, que estavam em busca de gerentes de projetos q ua li ficados para ajudar no s uporte
às suas iniciativas de TI na área de saúde.
O maio r desafio com um PMO é seguir uma metodologia ou padrão de múltiplas inicia-
tivas q ue va riam em tamanho, escopo e complexidade. A chave para o sucesso é certifica r-se
de que seu PMO siga um formato consistente, forneça as ferramentas necessárias para rea-
lizar o trabalho, mas permita escalabilidade baseada nas ne.cessidades dos GPs individua is.
A mental idade de aplicar uma abordagem única para todas as situações simplesmente não
funciona ao administrar um PMO.
Q uando in icia mos o PMO na maxlT-VCS, tínhamos total apoio executivo (principal).
Todos estavam de acordo com o va lo r da prática, e esse fato em si leva ao nosso s ucesso.
Como todos sabemos, ter adesão dos executivos é não somente crucia l para um projeto
bem-s ucedido, mas também é integra l ao se construir um PMO.
O papel de um GP na maxIT-VCS é considerado um plano de carreira para nossos funcio-
nários, mas também é uma de nossas soluções. A maioria das o rganizações de sa úde para as
quais prestamos serviços a inda estão aprendendo o verdadeiro valor e o ROi de um gerente
de projetos. Algumas o rganizações adotantes iniciais que investiram e apoiaram um PMO
adequadamente estão tendo um enorme retorno sobre seu investimento, Temos descrições de
cargos para nossos gerentes de projetos inclu indo os níveis 1 a 3 (sendo o 3 nosso GP sênior).
Heidi Wurtz, VP do Centro de Soluções da maxIT-VCS declara que:
A maxIT-VCS, uma empresa do grupo SAIC, continua a apoiar um PMO enquanto traba-
lhamos no sentido de integrar nossos serviços combinados de gerenciamento e consultoria
estratégica. O Plv!O reside em nosso G rupo de Soluções, a d ivisão de consultoria em ge-
renciamento de nossa organização integrada. O Grupo de Soluções definiu uma iniciativa
de Gerenciamento de Portfólio com uma visão que apoia o esforço da maxlT-VCS para
melhorar suas capacidades de gerenciamento de portfólios e programas. Ela buscar captar
e integrar dados essencia is de projetos (status, cronogramas, alocação de ,e.c ursos, etc.) em
um armazém de dados e apresenta r as informações necessárias aos gerentes com necessida-
des específicas. Isso fornecerá uma fundação para a intel igência empresarial em toda a orga-
nização, elim inando ou racionalizando os processos manuais. O Resumo de Oportunidades
em Gerenciamento de Portfólios inclui:
• Otimiza r o tempo da liderança e da gerência dedicado às comun icações internas relati-
vas a programas e pro1etos
• Propiciar um ambiente de intel igência empresarial para todos os níveis da organização
para ajudar a gerenciar programas e p rojetos
• Ter a documentação padronizada e focada para o envolvimento dos GP e PD da
maxlT-VCS
• Tirar proveito dos dados armazenados em um banco de dados de gestão de projetos
• Ti rar p roveito da propriedade intelectua l - a rquivar documentos e dados para uso futuro
• Apoiar e padron izar as expectativas dos papéis de GPs, PDs e analistas em todas as
práticas
• Identificar os projetos q ue exigem atenção da gerência baseado em critérios de negócios
(pad ronizar processo de Revisão de Projetos)
• Inclu ir a pontuação da revisão de qualidade feita pelo cliente como suporte a interações
apropriadas com os clientes, obtendo dados cruciais para melhorias contínuas, propos-
tas e vendas e marketing
15
12.4 Aviva
Estrutura
Contexto do mercado
A Aviva Canada é um dos grupos líderes de seguros de imóveis e acidentes pessoais
no Canadá que oferece seguros residenciais, de automóveis, de veículos recreacionais,
seguros de grupos e de empresas a ma is de 3 milhões de clientes. A e1npresa é uma
subsid iária integra l da Aviva PLC, sed iada no Reino Un ido, e possui mais de 3 m il
funcionários, 25 estabeleciinentos e 1.700 corretores independentes como parceiros. A
Aviva Canada e seus funcionários investe1n em mudanças positivas, inclusive por meio
16
do Aviva Co1nmunity Funde da Eva's lnitiatives, sua parcei ra no programa globa l da
Aviva chamado "St reet to School" (Das ruas para as escolas) que ajuda desabrigados
e outros jovens e1n situação de risco a alcançarem seu potencial. (http://Avivacanada.
comia rticl e/a viva -canada -and -eva 's-initia tives-working-togheter-prevent -youth -home-
1essness.)
Contexto da indústria
As megatendências e,npresariais 17 começ.ara1n a moldar e afetar muitas indústrias. A ne-
cessidade dos serviços de atendimento ao cliente com rapidez, maior transpa rência e ca-
pacidade persona lizada de acompanhar produtos e serviços é nossa presente real idade.
Consequentemente, as megatendências empresariais se traduzen1 em megatendências de
seguros (para tudo: segu ros gera is, de vida, de saúde, etc.) quando todos são pressio-
nados a se tornarem n1ais ágeis (aumentar a produtividade - fazer mais co1n menos), a
digitalizarem a cadeia de valor (tanto vertical quanto horizontaln1ente), e quando o ge-
rencian1ento de capital humano é mais importante do que nunca (aun1entar habilidades
e investir nas habi lidades de u1n futuro não mu ito distante). Ver Figura 12-3.
Descreve1nos o EPMO da Aviva Canada como direcionado ao mercado, operando
e1n um 1nodelo híbrido-federado. Nossa estr utura e processos permitem que a função
responda melhor e ofereça melhor suporte a uma organização foca lizada no cresci-
mento lucrativo, e em ser cada vez mais ági l e eficiente. Possibi litar uma aprovação
d inâmica de in iciativas permite maior agilidade. Consequentemente, as iniciativas são
apresentadas quando o a 1nbiente justifica o investimento (lega l, regu latório, resposta
a um concorrente ou pressão de custos, etc.). Nossa abordagem é gerenciar dentr o o
o rçamento de investimento total do portfólio para o ano (estabelecido a detenninado
percentua l do alvo de receitas), e isso é sustentado por um forte modelo de expansão
e contração da mobilização de recursos, oferecendo flexibilidade em termos de capital
humano. Os EPMOs t radiciona is, em sua ma ioria, operam quando as iniciativas são
apresentadas uma vez por ano (e de ba ixo para cima) durante a época da determ i-
nação do orçamento e do planejamento, quando enormes esforços são ded icados à
seleção, priorização e previsão da demanda e da oferta ao longo dos 12- 18 meses
seguintes. Não acreditamos nessa abordage1n; se o ambiente exige que a empresa res-
ponda, então ela precisa se apresentar para ava liação e decisão - queremos ouvi-la !
Nosso t rabalho é, então, fazer a coisa acontecer se aprovada - é para isso que estamos
aqui: liderar e facilitar mudanças em toda a e1npresa.
15
€>2013 by Aviva. Reproduzido com permissão. Todos os direitos reservados. Informações fornecidas por
lan Laliberré, vice~presidenre de estratégia e mudança em TI.
16
Eva é o nome do cencro juvenil mancido pela Aviva Canada.
17
Service 2020: Megacren.ds for che Decade Ahead, a BDO Reporc, escrito pela Economist lnrelligence Un.ic,
Summer 201 1, 37 p.
Megatendências empresariais
Necessidade de
rapidez do serviço de
atendimento ao cliente
Tempo é o novo luxo Megatendências de seguros
Tornar-se mais ágil,
Maior transparãncla aumentar a produtividade
Conseguida pelas
mídias sociais Digitalizar a cadela de valor Prioridades
veltlcal ehorizonw
Serviços personalizados Focalizadas, ágeis,
e acompanhados Crescimento lucrativo eficientes
Gerenciamento do
Mais e mais capital humano
lntllv/dualizados
Figura 12-3 Megatendências empresariais e de seguros moldando prioridades.
Liderança
U1na cultura de liderança é um ingred iente crucial para um EPMO direcionado ao
mercado. Para buscar continuamente rapidez, eficiência, adaptabilidade e flexibilida-
de, toda e e.ada pessoa (e não somente a gerência) precisa ser capaz de questionar o
status q110, deter a burocracia do modo que for necessário e tornar sua abordagem
adequada dent ro da estrutura de governança d irecional. Uma liderança de ponta (ino-
vadora), e não a partir do centro (seguindo as regras preestabelecidas), ou de ci1na
para ba ixo, é o que buscamos em nossos parceiros e é a base de nossas relações.
BHAG, 4 Pilares
A fim de alcançar um ele1nento de impulso e conexão com todos, estabelece-se uma
meta clara, grande, "cabeluda" e audaciosa (BHAG, a clear big, bairy, and a11dacious
goal) - uma declaração t ransformativa que continua1nente lembra a todos de onde
vie1nos, quais são nossos objetivos e co1no os alcançaremos. Para alcançar o futuro
imaginado e colocar o foco e1n como faremos isso, quatro pi lares sustentam o BHAG.
U1na simples declaração que está ligada a prestadores de serviços e funcionários em
regi1ne de tempo integra l. Isso é exibido na Figura 12-4.
Pode parecer difíci l 1nanter esse elemento em u1n modelo direcionado ao mercado,
mas, na verdade, é o oposto: ele é cent ral para nossa to1nada de decisões em termos de
contratações (os entrevistados são consultados quanto à sua reação inicial e co1nenta1n
sob o itnpulso do momento), para iniciativas de melhorias contínuas que devemos ter
(processos e operações), para co1no devemos nos comportar interna e externamente, e,
o que é mais i1nportante, para como nos alinhamos co1n nossas partes interessadas e
nossos clientes. Cada FTI é designado a um dos pilares para personificar e impulsionar
a mudança necessária.
Uderança e união na indústria

Para fazer co1n que funcionários e prestadores de serviços se esforcem para se tornar
líderes de pensamento e versáteis (fazer o que for preciso para rea lizar o t rabalho
mesmo que não conste na minha descrição de cargo), tambétn reconhecemos que a
equipe precisa ser ext remamente engajada e visível externamente em várias co1nunida-
des de gestão de projetos. Para desbloquear o potencial da liderança de pensa1nento,
conectando, comparti lhando e discutindo desafios, alguns funcionários se reúnem pelo
O FUTURO QUE IMAGINAMOS

Transformarmo-nos de um parceiro que só acata ordens, bom em Implementar projetos, percebido como
burocrático e pesado, além de Inconsistente em nossa paixão e estímulo, na melhor opção de parceiro, premiado
e de nível mundial, Inteligente, ágil e com uma forte paixão por lazer o que lor preciso para ser o catalisador da
mudança para a Aviva globalmente. Faremos Isso Instigando os membros de nossa equipe a se tornarem líderes de
pensamento ven;átels e extremamente engaJados - parceiros estratégicos confiáveis em termos de excelência na mudança.
.,,
.,,
o
?l
• Criar critérios de
.,, w
t.,, ~,
.i
• Melhorar continuamente
*
<
a:
• Pensar em resultados no
oontratação mais robustos ~ o nossos processos com :::, conlaXIO eq,mariil -
a: • Revisar periodicarnante zw <> parteiros e fornecedores traballar para elininar a
:::, os talentos. perfis de _, < • Revisar e racionaizar !:.
:::, mentalidade de silos
e.,
cargos e 8S1abelec1r e.,
a:
w nossa Metodologia de e., • Oefirir compottamenkls e
w
a: objetivos de desempertlo .,, a. Enltega de Projeios w alvos de desempertlo e
w
...
o
que se ainham com o
Muro que imaginamos
.,,
o
.,,
o
.,,
w
• ln1roduzir a Agilidade
oom rel!Vância ...
o
zw
estabelecer um now
mandado di liderança
z • Estabelecer um plano de o
z .,,
o
.,,
• Introduzir um plano para para permitir nossa
_,
w trtinamento robusto que
se alinhe oom uma
.,, w
oomo se tornar wna
organização de riYel
:E
;!
trans1ormação em uma
organização dt classe
;! organização de IM
o e., mtr><ial a: mundial
< o
mundial
• Continuilf a promOY11t
nossos planos de cantira
...
o
zw
a:
a.
• Rtintroctuzir os
indicaOOres dlan de
deseq>enho (KPls) para
o
a.
:E
oe.,
• Crilr mensagens positivas
ql.8 unam e inspirem a
equipe e simm para
em E'S1ratêgia e Mucfança :E que sirvam ele suporte redefrlir nosso val01 para
em TI para que eles sirvam <
:e
aos resutlados dos aorgalmçâo
de suporte à aprendizagem z programas e projelOs • Sempre cltsafiar o status
e ao desenvorvimento na _, quo- pensar ele maneira
pràtica < inovadora e laraticamente
• Oese1WOlver um plano de discipinada
sucessão para os cargos • Exercitar a paranoit
de liderança de Eslra!égia prodU1iva.
e Mudança em TI • Praticar a criativiclade
empirica
Figura 12-4 Visão de estratégia e mudança em TI , BHAG e pilares.
menos duas vezes por ano co1n colegas de várias indústrias que ocupam funções simi-
lares. Essas sessões de meio dia de duraç.ã o vale1n ouro para cada organização, já que
a abordagem comprovada e verdadeira de "polinização cruzada" de conheci1nentos
permite que todos nós rapidamente dissem inemos aprendizados essencia is em cada
u1na de nossas organizações e expandamos a rede de conexões de todos. Isso nos
permite comparti lhar nossa visão e abordagem, de modo que, enquanto funcionários
e prestadores de serviços muda tn as organizações co1no pa rte de suas carreiras, tenta-
mos moldar como será o futuro. A partir de 2012, a ma ioria dos líderes sênior passou
a se conectar com outros lídereos de EPMO, e o mes1no ocorre com nossa prática
e1npresarial de Anál ise de Negócios, bem como na prática de Execução de Mudanças
e Gerenciamento de Processos de Negócios (BPM, Business Process Management) .
Um exemplo perfeito tambétn está aproveitando essa oportunidade no último
lançamento de Kerzner. Essa é u1na outra p lataforma para au1nentar a liderança de
pensamento necessária para elevar uma função central de tamanha importância em
muitas organizações.
Capital humano
Uma sólida revisão do gerenciamento de talentos
A Aviva como organizaç.ã o focaliza-se em seus talentos e possui um bom processo e es-
t rutura de gerenciamento de talentos. Na função EPMO, certificamo-nos de que todas
as pessoas tenham seus objetivos anua is estabelecidos, um plano de desenvolvimento
pessoa l e tenham sua reun ião mensal ind ividua l com seus respectivos gerentes de área
para discutir o progresso em seus objetivos e desenvolvimento. No 1neio do ano, a
equ ipe de gerência se reúne e discute todos os seus funcionários e co1no tem sido seu
desempenho ao longo do tempo, e co1no sua agi lidade vem se desenvolvendo. Essa é
Capítulo 12 O escritório de projetos 5 01
uma ótima 1naneira pa ra a Equipe de Liderança Sên ior (SLT, Senior Leadership Teatn)
do EPMO ficar sabendo cotno sua equipe de execução está sendo percebida pelo resto
da o rganização, oferecendo, na verdade, um feedback crítico sobre o desenvolvÍlnento
de nossos funcionários. O gerente de área, então, oferece esse feedback de volta à sua
equipe em sua próxima reunião mensal individua l, quando se oferece um feedback
honesto e se t raça um p lano de ação. Trata-se de um importante processo, já que ele
também delega ao funcionário o poder de retificar sua trajetória entre o meio do ano
e a revisão de desempenho do fim do ano, quando o mesmo processo se repete, ,nas,
dessa vez, para discutir o desempenho de fim de ano para discutir aumentos sala riais
e bônus por mérito.
Um claro plano de carreira
Um plano de carreira é importante, e cada papel precisa tem utn claro perfi l de cargo
que descreva suas responsabilidades, mas que também demonstre como uma pessoa
pode passar de um cargo júnior, a intermed iário e até mesmo co1no ele pode se mo-
vimentar lacerahnente em out ras funçôes de gestão de projetos ou portfólios e etn
cargos de aná lise de negócios no nível empresarial. Todos os perfis de cargos até o
vice-presidente são disponibi lizados para os funcionários.
Um plano de treinamento visível

O plano de treinamento é u1na visão de baixo para cÍtna de todos os planos de desen-
volvimento pessoal dos funcionários, e uma visão de cima para baixo do que a equ ipe
de gerência também imagina que a lguns dos indivíduos ou equ ipes irão exigir no ano
com base na direção e foco da organização como um todo. N inguém é deixado para
trás, e tornamos o plano de treinamento visível, já que estamos falando sério quando
dizetnos que investimos em todos. Nosso pessoal da admin istração também recebe
treina tnento em ferramentas de produtividade e gestão de projetos, pois isso é impor-
tante para que todos" falem a mesma língua".
Recompensas e reconhecimentos
Recompensas e reconheci tnentos também são fatores centrais e instrumentais em tor-
nar nossa equ ipe um sucesso; na verdade, muito do que fazemos é aprendido e aplica-
do em out ras áreas da organização.
A celebração faz parte dos sucessos de un1 projeto; oferecetnos recompensas aos
indivíduos e equipes ou, às vezes, sin1ples cartões de agradecin1ento, bilhetes de cinema
ou vales-café significan1 muito quando se trata de um colega que está si1nplesn1ente
dizendo un1 "obrigado". Os prestadores de serviços são considerados como pa rte da
equipe, assim con10 nossos funcionários de tempo integral; a união e a uniformidade da
equ ipe são fatores centrais para que nos torne1nos uma organização de nível 1nundial
e, como ca l, todos precisan1 sentir que foran1 escolhidos como parceiros de confiança.
Designação de projetos como suporte ao crescimento na carreira

Para apoiar os t rês últimos pontos aci tna sobre p lanos de carreira, treinamento e re-
compensa e reconhecimento, nosso modelo de governanç.a de projetos etn diversos
níveis cambétn garante que ma is funcionários de nível júnior possam assumir cocal
responsabil idade de iniciativas pequenas a médias que sejam adequadas ao seu nível.
Discutiretnos mais sobre esse assunto nas seçôes de Funções e Operações.
Contratar para o sucesso

Muito tem -se escrito sobre esse assunto, mas isso é porque se não há pessoas, você
simplesmente não existe cotno função dent ro de uma o rganização. Portanto, as pes-
soas são o núcleo do sucesso. Para sustentar isso, garantimos que nossos gerentes de
contratação analisem tanto o "que" quanto o "como" de um candidato. Para garantir

o foco em torno dessas duas áreas, nossos gerentes de pessoas chegam a um acordo
quanto a quem irá focar e1n quê antes da ent revista acontecer. Lembre-se de que para
se tornar uma empresa de nível mundia l não se pode fazer compromissos quanto à
qualidade dos indivíduos que contratamos; sejam eles funcionários de tempo integral
ou prestadores de serviços, seguimos o mesmo processo. Designações profissiona is
são obrigatórias (PMI, Prince2, CBAP) - se anos de experiência justificarem a con-
t ratação, certificaremo-nos de que a lacuna da designação seja preenchida em até 12
meses. Seja o papel desempenhado de execuç.ã o ou de gerenciamento (até o nível do
VP), as designações são obrigatórias. Para sermos claros, reforçamos constantemente
a mensagem de que operar nesse espaço exige uma grande energia e estí1nu lo; contri-
buições individuais e de equipe são importantes, e reconhecemos que nem todo mundo
consegue se adaptar a ta l a 1nbiente - co1npreendemos e fazemos de tudo para retirar
da organização aqueles que tiverem baixo desempenho.
Programa de contratação baseado em papéis

Quando um candidato é selecionado, a maioria das organizações recebe os novos
membros da equipe em seu primeiro dia e faze1n um tottr pela empresa, apresenta-o
às suas novas principais partes interessadas, etc. Nós, não. Ent rar em u1na empresa é
u1n negócio sério; a agi lidade e a rapidez começam no Dia 1. Desenvolve1nos perfis
baseados em papéis para novos funcionários nos qua is haveria uma a duas semanas de
aprendizagem, dependendo do papel a ser desempenhado e pelo nível hierárquico do
funcionário. Aborda-se tudo: BHAG e nossos quatro pi lares, ferramentas, processos,
governança, insta lações/logística, processos de aprovação e tomada de decisões, gráfi-
cos organizacionais, etc. Investir uma a duas semanas no início poupa semanas por um
funcionário "perdido" na organização e por ineficiências e, mais importante, minimiza
erros potenciahnente caros em decorrência de simplesmente não saber o que é ou o
que não é errado. Por mais siinples que isso possa parecer, sempre nos surpreendemos
ao ouvir de novos funcionários quanto isso é inexistente e1n out ras organizações, mas
também ficamos muito felizes e1n sempre ouvir como nosso programa de incorpora-
ção de novos funcionários é ótimo.
Incorporação e "polinização cruzada"

Fina lmente, esta seção não estaria completa se não fechássen1os o loop em nosso
modelo híbrido-federado. Federado porque nossos "tentáculos" se estendem a todas
as funções da organ izaç.ã o por n1eio de nossa execução de projetos, e quando ten1os
en1 execução progran1as grandes, complexos e de mu itos anos de duração, queren1os
que nosso pessoal n1t1de de linhas de reporte e, en1 outros, mantemos a capacidade
interna, mas oferecen1os un1 serviço diferente; son1os híbridos e adaptáveis. No sen-
tido federado, son1os favoráveis a oportunidades de substituições ten1porárias (de
ent rada) e a liberar nossos n1elhores funcionários (saída), porque a ent rada e saída de
funcionários estimula a gerência e a execução em toda a organização, e, por sua vez,
eles orientam e fazem n1entoria de outros nesse espaço operacional; novan1ente, sen1-
pre indo adiante, possibilitando o foco, a agi lidade e eficiências de execução en1 toda
a empresa. Somos híbridos porque não se trata de un1 verdadeiro modelo federado,
mas também porque en1 a lguns casos, desenvolven1os un1a equipe de programas que
só serve de suporte a determ inada função (nossas Linhas de Pessoa l) - uma grande
oportunidade para GPs e BAs aprenderem sobre as operações do negócio de seguros,
e até n1esmo considerar uma mudança de carreira na funç.ã o. Novamente, nunca con-
sideramos isso uma perda, n1as un1 tremendo ganho para ambas as funções e para a
organização como um todo.
Função
Equipes funcionais - Nosso ecossistema de parcerias estratégicas
Encontramos o equ ilíbrio certo de papéis e funções necessárias, permitindo uma rápi-
da expansão e contração, dependendo da dinâmica do mercado. E,n seu cerne, nossa
equipe (inclu indo a gerência) é formada por aproximadamente 30 FTs (times funcio-
nais), e pode facilmente ser dobrada de tamanho dependendo da carga do portfólio.
A força de nossa operação e o que nos permite sermos vistos cada vez mais como utn
parceiro estratégico etn termos de excelência em mudanças é a amplitude de nossa
unidade, que vai além da execução de projetos, programas e portfólios tradicionais.
O EPMO opera na função de estratégia e mudança em TI, na qual as equipes a seguir
podetn ser vistas como exercendo u1na liderança de ponta, uma liderança a partir do
centro, e u1na mistura das duas - nosso verdadeiro sistema de execução. Ver Figura
12- 5 para um panorama funcional da Estratégia e 1nudança em TI.
Uderança de ponta (inovadora):
• Parcerias de negócios em TI: Em dois níveis. No primeiro nível, das parcerias de
negócios, temos gerentes sênior, cujo papel é ser um ponto de esca lação " trian-
gular" ent re gerentes de projeto/ progra1na, líderes funcionais da área que re-
presentam (pode ser relacionado ao projeto ou ao business as 11sual - BAU),
ou específicos de TI que podem ou não incluir um terceiro. No segundo nível,
temos os líderes de TI mais sênior, indicados como utn parceiro para as outras
áreas funcionais maiores (como vendas, finanças, subscrições, etc.). Seu papel é
servir de "ponte" entre outros membros do Co1nitê Executivo (CE) e sua SLT ao
escritório do CIO. O líder mais sênior em estratégia e mudança etn TI é indicado
para a distribuição por corretores (vendas).
• Estratégia de T I / Escritório do CIO: Esta seção apoia diretamente o Escritório
do CIO a gerenciar todas as solicitações de informação e as apresentações ao
Comitê e Diretoria Executiva, a lém de garantir que haja um sólido "mapa" de
informações e tecnologia que sirva de suporte direto à direção est ratégica da
organizaç.ã o a lém de responder às prioridades táticas, principalmente por meio
da execução de seu portfólio.
Uderança a partir do centro

• Gerenciamento e execução de portfólio: É a divisão de execução da gestão de
projetos do portfólio da Aviva; é a ela que coordenadores, gerentes de projetos e
gerentes de programas se reportam. É tatnbém onde reside o escritório de gestão
de projetos.
Estratégia e
mudança
em TI
Execução de mudan-
Gerenciamento Anâlise Planejamento e
Parcerias de Estratégia de TI/
e execução empresarial geração de relató-
Finanças ças e gerenciamento
negócios em TI Escritório do CIO do EPMO de processos de
de portfólios de negócios rios de portiótios
negócios (BPM}
•
Escritório
de gestão GOe
conformidade
de projetos
Figura 12-5 Panorama funcional da estratégia e mudança em TI da Aviva Canada.

• Análise empresarial de negócios: Ser um PMO empresarial exige um amplo jar-

gão de negócios que transcenda muitas áreas funciona is - todos os BAs que
serve1n de suporte ao relatório de execução do portfólio nessa função.
• Planejamento e geração de relatórios de portfólios: Essa equ ipe é a proprietá-
ria do aplicativo do pacote de gestão de projetos e portfólios, onde residem as
informações sobre de1nanda e oferta do portfólio. Ela produz todas as informa-
ções de intel igência do negócio necessária às partes interessadas; o desempenho,
saúde e status de nosso portfólio é disponibilizado para todos os 3.500 funcio-
nários de toda a o rganização.
• Finanças do EPMO: Temos uma equipe de analistas financeiros sênior de proje-
tos (SPFAs, senior proiect financial analysts), e cada um deles possui u1n mix de
projetos a apoiar; nenhum GP, ou gerente de programa, fica para t rás. Gerencia-
mos nosso portfólio como um fundo mútuo; o projeto flutua para cima e para
baixo todo mês, e fazemos de tudo para não sobrecarregar a equipe de geren-
ciamento da execução, mantendo visíveis os Fluxos de Caixa e Lucros e Perdas.
Te1nos profissionais que vivem disso (além de GPs ou BAs), e isso garante que
os padrões financeiros adequados sejam seguidos em nossos investimentos e re-
latórios. Essa equipe também oferece suporte ao desenvolvimento e aos detal hes
financeiros iniciais de qualquer caso de negócios, e funciona lado a lado dos
respectivos funcionários da função financeira de parceiros de negócios sempre
que necessário. Além disso, ela acompanha todas as declarações de trabalho
e fatu ras que chegam, para garantir que elas corresponda1n ao comprom isso
inicialmente acordado.
Uderança em ambos os espaços

• Liderança do escr itório de gestão de projetos: Com uma liderança a partir do
centro, devido ao nosso modelo de expansão e contraç.ã o, os prestadores de ser-
viços precisam de muito mais orientação sobre como navegar e t rabalhar dentro
de nosso modelo de governança. É aqui também que ocorre nossa função deres-
gate de projetos - quando algo sa i errado, temos alguém que pode rapidamente
intervir e traba lhar em parceria com os encarregados e a equipe de execução
para ajudar a colocar as coisas de volta no rumo certo. Além da liderança de
ponta, essa área ta 1nbém é encarregada da Comunidade de Prática de Gestão de
Projetos (PMCoP, Project Management Cotn,nunity of Practice), em que prati-
cantes e líderes funcionais que estão realizando um papel de gerente de projetos
se reúnem pa ra discutir problemas e tópicos de interesse específicos e estimulam
um ambiente de networking com colegas de toda a organização.
• Execução de mudanças e gerenciamento de pr ocessos de negócios (BPM): Essa
área pratica a liderança a partir do centro quando é necessário compreender de
forma holística todas as interdependências do projeto (cronogran1as, recursos) e,
ao usar esse ponto de vista, define ativamente iniciativas para oti1nizar continua-
n1ente o canal de execução de projetos, alé1n de basear o trabalho de reengenharia
de processos de negócios nas atribu ições do projeto (principa lmente quando ele
envolve um trabalho de natureza transforn1acional). Pratica a liderança de ponta
quando interdependências externas precisam ser compreendidas (todos sabemos
das iniciativas do tipo business as usual - BAU) durante a fase de in iciação e pla-
nejamento, de n1odo que se estabeleça un1 cronogran1a sólido. A reengenharia dos
processos de negócios tan1bé1n ocorre fora do portfólio de projetos, em sua gran-
de parte em suporte parceiros de negócios estratégicos e de TI quando necessário,
quando são encontradas ineficiências em várias áreas da organização.
• Garantia da qualid ade e conformidade: Esta não é uma função de policiamen-

to, mas uma função de habilitação para agilizar e fornecer orientações simples
quanto ao que vem depois do ponto de vista da governança, ou quanto a quem
deve ser contatado dependendo do ponto em que você se encontr a no ciclo de
vida. Essa função também é responsável por manter todos os ciclos de vida
(CVGP (ciclo de vida da gestão de projetos), CVDS (ciclo de vida de desen-
volvimento de software), Ágil, Iterativo, E1n Cascata e Híbrido). Essa equipe
oferece suporte a projetos específicos, e estabelece parcerias co1n várias áreas da
organização onde os líderes funcionais pode1n precisar navegar na estrutura de
execução de tecnologias.
A força de nosso modelo é que son1os parte do processo de tomada de decisões,
oferecen1os suporte a todos aqueles que se reportam diretan1ente aos respectivos
n1embros do CE por meio de nosso modelo de parceria, somos uma conexão essencial
entre várias funções e as equipes de execução de portfólio, ajudamos também a mol-
dar e apoiar o desenvolvimento estratégico de investimentos futuros, e pron1ovemos
cada ativo existente na cadeia de va lor da Aviva para garantir o sucesso da execução
dos projetos. É isso que definimos como o motor de execução de nossa en1pre.sa (ver
Figura 12- 6).
Operar com esse 1nodelo é a lgo único; somos expostos à amplitude e à profun-
didade da organ ização e temos uma ampla rede de relações e conexões que ro1npe
com o pensamento e1n silos. O desafio de qualquer EPMO é sentir que eles são u1na
equipe. A natureza do trabalho que fazemos é constantemente despachar a solicitação
de trabal ho para toda a organização; quando uma in iciativa é aprovada, você é então
designado a tr abal har co1n o patrocinador e encarregado de uma função, reunir o
l~CIUMIS
denegóclOs
Nossas ideias
(- Nossa conexão
Figura 12-6 Modelo e interações de execução da empresa.

pessoal e realiza r o trabalho. Quando se t rata de um projeto ou programa rea lmente

grande, você traba lha co1n a lguns membros essencia is, 1nas, caso cont rário, apenas
pequenos grupos do EPMO t raba lham juntos e1n qua lquer momento específico. Con-
sequente1nente, é i1nportante realizar constantemente atividades de fortalecimento de
grupos e, embora haja uma est rutura funcional em vigor, ela não estaria completa se
não fa lássemos das atividades que são como o cimento dessa função:
• Reuniões mensais entre gerentes de projetos e coordenadores: Quando todos
os gerentes de projetos e coordenadores se reúnem e discutem suas iniciativas e
dificuldades; é incrível ver quanta dependência pode haver entre as equipes (re-
cursos, janelas de promoç.ã o de sistemas, sol icitações de fornecedores), e como
as pessoas estão disponíveis a apoiar e ajudar umas às outras. Criar u1na cons-
cientização do que mais está em jogo por meio de uma simples mesa-redonda
pode trazer mu itos benefícios.
• Reuniões departamentais trimestrais: É itnportante reunir o departamento uma
vez a cada três meses para discutir as últimas notícias provenientes dos níveis
mais altos da empresa, decisões, mudanças organizacionais, recompensas e reco-
nhecimentos e discutir assuntos importantes. Essas atual izações e discussões são
crucia is, pois essas equipes têm de navegar continuamente através da estrutura
organizacional.
• Comitê/Encontros sociais: No verão, nada melhor do que convidar todos para
uma socia lizaç.ã o no fim da tarde - permite que todos se desliguem do tr abalho
e se conheçam fora dos litn ites corporativos.
• Responsabilidade Social Corporativa: Gostamos de m isturar diversão, encon-
tr os de equipe e impacto sobre nossa comunidade, tudo ao mesmo tempo. A
Aviva permi te que cada funcionário dedique 15 h/ano para ajudar as comunida-
des em que vive1nos e trabalhamos. Levamos isso a sério e transformamos essas
atividades e1n parte de nossos objetivos pessoa is . Todo ano, levantamos alguns
milhares de dólares e realizamos trabalhos (organização de cent ros de juventu-
de, plantio de á rvores, etc.).
• Otimização continua: Todo ano, real izamos entre 10 e 20 iniciativas de mel ho-
r ias contíuas em nossa área. Adaptação é a chave do sucesso, e nosso EPMO
está em constante fluxo para sempre melhor responder às necessidades da or-
ganização. Portanto, certificamo-nos de incluir isso nos objetivos de todos e de
garantir que todos contribuam para tornar este um lugar melhor e ma is flexível
para se t ra ba Iha r.
• Mesa-redonda trimestral com gerentes de projetos e coordenadores: Quando
mui tos projetos estão em andamento, e1n várias fases do ciclo de vida, é im-
portante que nossos gerentes de projetos se reúna1n e compartilhem com seus
colegas suas iniciativas e suas dificuldades. Essa "polinização cruzada" de com-
partilhamento de informações eleva a conscientização organizaciona l de todas
as iniciativas de mudanças, e, o que é ma is importante, ajuda a identificar inter-
dependências ent re os projetos.
Operações
Governança: um modelo de parceria
Nosso modelo envolve possibi litar que a organização seja focada, ágil e eficiente e
que ofereça a velocidade necessária do tempo de colocação no 1nercado. Portanto,
compreendemos que nossa governança não pode tratar de cont role e policiamento,
mas, em vez disso, deve se adequar à sua finalidade e proporcionar agilidade. Para
alcançar isso, nosso ciclo de vida é: marcado por um jargão de negócios (proposta,
iniciação, planejamento, execução, encerra1nento), ági l e autocentrada (com três níveis
de govemança), adaptável (etn cascata, iterativa, ágil, híbrida), rápida e eficiente (cinco
fases, cinco pontos de decisão, t rês aprovações). (Ver Figura 12- 7.)
Jargão de negócios
Parece-se muito como o ciclo de vida proposto pelo PMI no nível macro, e é verdade.
Pelo fato de a Aviva Canada se encontrar na América do Norte, e tambétn devido ao
nosso 1nodelo operacional de expansão e cont ração de recursos e práticas de contra-
tação, queremos nos certificar de que nossos profissionais de gestão de projetos (PMI
ou Prince2) possam rapidamente compreender nosso esquema organizaciona l em uma
linguagem com a qua l todos estejam familiarizados. Isso se aplica a qualquer novo
gerente sênior que esteja entrando para a organização e que se torne Encarregado de
Projetos ou Patrocinador Executivo.
Governança autocentrada e em diversas camadas

U1n modelo único não serve para todas as situações. A velocidade do tempo de colo-
cação no 1nercado garante duas coisas: a organização pode liderar e gerenciar suas
próprias iniciativas de pequeno a médio porte e permite que essas iniciativas se mova1n
rapidamente pela organização, exigindo menos burocracia e aprovações independente
de que1n as estiver liderando. Isso recebe o suporte de u1na ava liação de govemança
autocent rada (já que o EPMO, em grande parte, lidera e gerencia iniciativas gran-
des, co1nplexas e t ransformadoras). Nossa ava liação de governança autocent rada é
concluída com listas de verificação, nas quais fazemos perguntas sÍlnples relativas ao
desempenho (duração esperada, tamanho da equipe, valor) e complexidade (va lores-
tratégico, risco de negócios, impacto sobre os negócios e sobre o cliente, r iscos téc-
nicos, impacto técnico). O resultado produzido indicará se o projeto deve navegar
pela organização com uma abordagem de governança leve, intermed iária ou plena.
Se atrelarmos isso à nossa seção sobre Capita l Humano, que trata de p lano e desen-
volvünento de carreira, garantiremos que nosso pessoal mais sênior de execução seja
designado às iniciativas mais co1nplexas e 1na iores, e daremos também oportunidades
aos nossos funcionários júnior de liderar e gerenciar in iciativas pequenas a médias,
ase de entrad
nlcio do ptojeto tojeto encerrad __
,,_ ../
.__,I Marcos do ciclo de vida de gestão de projetos
Figura 12- 7 O ciclo de vida adaptável, flexível e direcionado ao mercado da Aviva Canada.
tendo uma responsabi lização por lucros e perdas adequada ao seu nível de experiência
e maturidade na carreira. (Ver Figura 12-8.)
Autocentrada e adaptável
Um modelo único não serve para todas as situações, assim como nenhuma abordagem
de execução serve para todas as situações. Garantimos que a metodologia de execução
aplicada à iniciativa é adequada à sua fina lidade, de modo a assegurar máx:i tna taxa
de transferência (throughput) para que os resu ltados desejados sejam alcançados e os
benefícios sejam realizados o mais rápido possível. Sendo assim, utn modelo autocen-
trado também se aplica aqui. Usamos dez perguntas simples para ajudar a determinar
11 AVALIAÇÃO OE GOVERNANÇA
AVIVA
lr,fo1mo - O lo()) i
--)
nuopmç6es
mmas(i.e
o
-~...
lilllbdo-ObtrtrtOS
_.,.
o
i.nufnctu \UÍYl!IS
em cuslo. oper~.
lucro ou lellda
docons.-lts o
Certo IISICO de .t.vuns n$005
o negõoo5tJ!!l1II
idJSSl ll'lllhio> o chrte ele neg6oos
(1 a 10mlh6es! o
-- ....l'lu Ulldadles
....l'hS Ulldades
de Ne96Clos • • ~
de Ne9ôcios
A19uns IUIOORUIOS
...........
Umotfbl5
_
FUIOO!IÚ!Os 1.-
o co.ocle'*
licbm dirmntenle
o co.oche'*
dirunellle o
.
---
Sislem:t e'Jl8III*
,_,
Padlio dt imdaa
lier6unu. mlllbni;i
na llibelrutu11;
o
Novo ~Ili a ltfrn:.
O.Spo111taldlde
amedllla(~s.Wl
Mio ela llllllW11
Ne!lh-.ud,nça
o -~
No'IO 113111 a Am11:
h,~o;
l!l,çio à llldimna
Pequenas mudaçu
-m
'-'ill!IUS vranc1es
o
• inlllleSlniura; - uilr.,estniura; draoslrutu111;
lier6ulna mlllbr,ç,.
IIOS ,plQWos,
m11xes°'
Peq,,enu mudllçu
"''"'""""'
ou
llllerbces
Mlcbnçasem ...
OU IIIIIS ;aplQWOs.,
1111ertaces ou
..........°'
liov.1 bmlii dt
modelos de cbdos
o
.::iôelos de m!os
o
.:>ôelos de d'3do5
o
-
.....
11Cer'bces
l!JilblfOs, DGW5
~
o
Figura 12-8 Avaliação de governança autocentrada.

se a metodologia de execuç.â o deve ser em cascata, iterativa, ágil ou híbrida. Os respec-

tivos fluxogramas de processos são integrados ao ciclo de vida de gestão de projetos
(CVGP); portant o, uma vez que a metodologia de execução seja identificada, basta
pegar o fluxograma e seguir os passos do processo. Ver Figura 12- 9 para u1n exe1nplo
de nossa seleção de metodologia de projet os autocentrada e ver Figura 12- 10 para um
exemplo de como traçamos nosso fluxo de t raba lho iterativo na etapa de planejamen-
to de nosso ciclo de vida.
Ctlthlos de metodologia. dt seieçao de projetos
:~!~2~------------------------------J
Os crilinos.'t)cr11..Us, 5e9Jir lima 1111e11Çio de auaiiar ~a uma mtlhof iv.1bçio de QJJe metodoloQ11 6Sl)OnNei strll a mais ,d~uada pm o pr.-,.
Jtuã: a b,rlllS ele .uordlO com .a ,dei:,,,çio de ada projtto tm cleltrmnado lllOI. ObSC!l'W: cpe ada crilil!Ofpergunla nec:dJe o m - peso. Se hoimr
dlhidu siolue o Q[llt esli sen5o soklladlO pts clelermnado cnlé'io. hawd - eliaa de comedrios lomecendo miiores deulhes p,q relrin:11.
h$0 rett"°
Oi~do Ne-:tro Concordo .
'> ..
0 ~ 1!0* Mf -,Ul;IO . . 1i1N. C1U ffllllS ~:litS llfldlOt'lilllS <k QMIIÇCfl
• ._.._..dl..._.,F. lllsllihll
-• •+-
•
,''
• -
. . . . .llfllielN llOdlWUIIOCIIIIMitu"*'*"Ullllal:l~MI
dtdlll·-·
~--lbl l,·. . . . . . -~,
0 5 -IIIOael5 sao 1ot5 llldiCIGIK a,..
»
de «li •'lldl. p,ejtli)t
.
•
•
••
+
+
+
••
~~~totll--~
!'5~"'~.aourioes~tllr-.tte~~·-·Euc +
•• .... •ear:osta•-.._,_.,..._.......... -11111& +
• +
,o
• +
. ~'°"" ~-~*'--
·s, dOS s.s- "QoQCI"
t:ul khl:141 U • l>tllldO llalS dqiiilllO a - d l o ~ Af/1
i:ul 1111*1 dt 2S-S5 • , _.... - ~ 4t l>tllldXI . ,...
t.:ui ui.c,,o • 2S • $IQi'f a ~ ~- usc.it.t
Figura 12-9 Seleção de metodologia de projetos autocentrados.
: : NleQf ....51:0S
~
•'
.,..~.
Wlflltbll
Ã
---- t ___ _ 'ô;·~ ·;;;;.;·;;;;;~;;;;.··~

'
:r ==--- --1
• ----
'
' - . , 11(11' plflfa.
i:ltfcisc OS jlrlS5CS alfm 4tflt jll)dO S,0
~UOSatencttUOClitQW
at1tllCII Clt euc.çJO CIIS ~
!
!
~ rr''"":.;;,,;;~,:,;;;,::,;;..;;;-il
.. ---------
---------
Plano
o;rs,;r;;;s d!! Rlzn;izmmlP UOl9*4N NSSOSCIGIP"(H50
Oa lfl'!'<mÇio dll Ulb de pra~lo - sem.1nas dt f"fflos ele fimo

plantjamfflkl r:u !MI de llOW'efflWIÇI
__.........
Pusos CltCD\'S/n
U'olt - 2 sem.111:15 dt pbll!j1mtnlo
• 4 llltse5 pul oi,eil!ÇÔ!5
M!i:fio • 3 SODln:15 dt IUDePrrerto
• 4 llltse5 pul oi,eraçi5e5
~ - S sem.111:15 dt pbll!j1mtnlo
• 4 mtses Pari oi,eraç&!s
·os PllUOS Podem 5er m.1is curws dl'l'ffl(ltndo
do ni:ci,o t esloiço
'
Figura 12-10 Um exemplo da etapa de planejamento do fluxo de trabalho iterativo dentro do CVGP.
Ági l e eficiente - gerenciamento de portfólio

Ter uma excelente abordagen1 de governança em várias camadas con1 o suporte de
diversos n1odelos de execução adequados, não sign ifica muito até que a gerência
sênio r tenha total transparência e visibilidade no portfólio . Direções e decisões estr a-
tégicas são ton1adas nos níveis n1ais altos da organ ização; portanto, a tradução entre
saber e fazer começa na mesa do Comitê Executivo . É crucial que, nessa n1esa, te-
nhamos uma sin1ples definição de um projeto (ren1over o estigma de BAU - business
as usual - versus projeto), que todos concordemos sobre os novos investimentos en1
mudanças necessá rios e que estejamos esclarecidos quanto ao progresso, status e
saúde atual do portfólio.
Em 2010, nosso CEO endossou e publicou a definição de um p ro jeto pelo Escri-
tório Executivo.
Uma definição siinples todos os funcioná rios co1npreendem. Para oferecer supor-
te ao foco incessante sobre execução e al inhamento, pa rte dessa definição publicada
é que não se deve fazer nenhum traba lho em p rojetos que não estejam listados no
portfól io. Se um funcionário for solicitado a tra balha r e1n uma in iciativa não listada
no portfólio, ele precisa levar a solicitação ao seu respectivo gerente de área (publica-
mos nosso portfólio na intranet mensalmente). Ver Figura 12- 11 para a defin ição de
p ro jeto da Aviva Canada.
Nenhum iceberg oculto

Segundo nosso ciclo de vida, qualquer pessoa que tiver uma ideia pode enviá-la para
aná lise usando nosso tetnplate de Proposta de Iniciativa. Pedem-se informações sim-
p les que ajudem a determinar a forma da ideia e t razer consistência a como as ideias
são apresentadas pa ra aprovação de financiamento . Ver Figura 12- 12 para ver esses
passos simples.
Esse p rocesso si1nples garante que todos os projetos só possam ser vetados por
seus respectivos executivos, de 1nodo que eles possam ser validados imediata1nente
se forem considerados prioridades. Daí, e se seu executivo aprovar, ele é enviado ao
$1 ,,,,
bigirem aprowaçJo pela TI {segundo a Palftlta rt, AulQC1tlaUt Commuvas. ouCorporate Authoóties PoHcy, seçJo 4.5. tl/»glna 1~
ou
NÃO edgtrem a execução de TI ou bens e serviços de segurança MAS REPRESENTAREM MAIS DE US$200 Mil em gasaos de caixa totai'S do
ptojeto (recursos mais ptodutos ou serviços adquiridos)
•1. Possuir uma data de infclo ede finahz.ação
2. Introduzir mudanças (crlaOOO ou alterando um produto, serviço ou capacidade}
3. hlglr os serviços ou envolvimento de mais de uma unidade de negócios
FAVOR OBSERVAR: Se sua lnklatln 1110 atende aos critérios acima. ela nJo ura lnclu(da no Awlva Canada Bookoi Wo111: e será
considerada como BAU.
Figura 12- 11 Definição de projeto da Aviva Canada.
,r----, Formulârio de proposta de Mwca•se , mllorârio na

Preeaclltr lormulirio
de proposta de
inici aliva e q.alquw mlleri al
de apoio prunchirlm
'°
ageada G" Pº b HUtiYO ,,
Revisão de Muâaças (ECRG,
Decisões ,ulli cadas
e como.nicarias dentro
fliciativa para levar a ideia de OOis dias uteis. BoW
e enviados via a•mai1 para Executi'IB Change Rew!W Group}
ao seu Membro do CE é atualir.ado oo
MAWW. Canacfa BoW intal:e~ para o membro do CE
AVNaWorld
para anàlise pelo CIO apresentar a fliciativa
Figura 12- 12 Adicionando um projeto ao portfólio de projetos da Aviva Canada - fluxo de trabalho
de proposta e aprovação da iniciativa.
Capítulo 12 O escritório de projetos 51 1
CIO para garantir que estimativas de TI de a lto nível (ordem de 1nagn itude) inclua tn
todos os componentes necessários. Uma vez validadados pelo CIO, eles são enviados à
próxima reunião com o Comitê Executivo, em que o respectivo membro do CE apre-
senta rá e ganha rá a sua aprovação. Durante essa reun ião, tomam-se decisões sobre
classificação (executar, transformar, crescer, ou run, transfo rm, grow ), nível de priori-
dade (PI, P2 ou P3 bucket), tipo de financiatnento (Corporativo, Empresarial), e quetn
será o líder o (EPMO, Empresa). Então, comunicamos a decisão.
ARM - Avaliar Recu rsos e Metodologia

Todo mês, temos um tempo de 30 1ninutos 1narcado na reunião do CE para qua lquer
aprovação de Propostas de Iniciativa (se houver) e para ana lisar a saúde e o status
financeiro do portfólio. Aprendemos com a experiência que uma vez que uma ini-
ciativa tenha sido aprovada, todos querem começar imed iatamente; mas a alocação
de recursos pelos vários gerentes de área ainda não ocorreu. Para acelerar o processo
da aprovação até a seleção de recursos, podemos começar nossa etapa de Iniciação e
seleciona r a metodologia de execução adequada, marcar reuniões de ARM um dia útil
após a reunião do CE para que os gerentes de área se reúnam para analisar a proposta
aprovada e, então, identifica r os mais adequados para seretn nomeados (o funcioná-
rio mais adequado disponível) . O efeito imediato é que todos os respectivos gerentes
entra tn em sincronia quanto a qua is são as iniciativas, quando e quais recursos eles
precisam dispon ibilizar. Essa preparação nos oferece uma abordagem mais rápida.
Uma versão da verdade, status e saúde do portfólio

A segunda coisa que avaliamos na reun ião do CE é a saúde financeira de nosso portfólio.
Todos os projetos são classificados etn Executar, Transformar ou Crescer (Run, Trans-
fonn, Grow). Isso nos perm ite manter o alinhan1ento das prioridades sob controle, as-
sin1 con10 saber onde precisamos colocar o foco ou reequilibrar quando for necessário.
Além disso, todo líder funciona l dos níveis hierárquicos mais altos sa be exatamente
como seu portfólio de investimento en1 n1udanças está progredindo. Ver Figura 12- 13.
V isibilidade e transparência em toda a empresa

Quando fechamos os relatórios de status e as finanças de fi,n de mês, nossa equipe de
portfólio produz dashboards mensais relevantes que são publicados em nossa int ranet,
e um link é enviado a toda a equipe de gerência da Aviva Canada (gerente e acima ).
E,n nossa página de destino, atualizamos e publicamos o status de nosso portfólio, in-
cluindo: pro jetos por etapa e pontos de decisão (todos estão cientes do que está por vir,
o que está acontecendo e o que está sendo finalizado), como nossos projetos e recursos
se a linham às prioridades estratégicas da organização, nossos riscos gerais e status de
problemas e demanda e oferta de recursos por projeto, tipo de recurso e portfólio. Ver
Figura 12- 14 para um exemplo de nosso dashboard de demanda e oferta de recursos.
Figura 12- 13 Exemplo da visão financeira de nosso portfólio.

Figura 12- 14 Exemplo de um dos seis dashboards: alocação da o ferta e demanda de recursos.
Clientecentrismo
O termo "cliente" em utn departamento de serviços pode ter diferentes significados, o
que pode causar confusão ou nos fazer não prestar atenção no verdadeiro cliente de
negócios. Como parceiros estratégicos do negócio, expandimos nossa compreensão
de nosso cliente de negócios interno para nosso cliente externo. Isso nos pennite falar
a 1nesma língua que o negócio no que d iz respeito à colocação de um novo produto
ou serviço no segmento de um cl iente. Para a Aviva, nossos cl ientes são nossos corre-
tores e, a fim de possibi litar um conhecimento fundamenta l, usamos uma ferramenta
chamada "Broker-On-A-Page". Essa ferramenta oferece às equ ipes de projetos e aos
executivos um único "i nstantâneo" de um segmento de cliente específico, incluindo
seus fatores críticos de sucesso, o modelo de interação desejado e relatos integrais di-
retamente do segmento. Isso define o segmento d istintivamente para possibilitar uma
execução direcionada. A Broker-On-A-Page é usada como u1na ferra tnenta vita l de
tomada de decisões para gerenciar o aumento gradual de escopo e os assuntos impor-
tantes de maior destaque (ver Figura 12-15).
Escutar ativamente para o planejamento futuro

Escutar ativamente exige compreender mensagens Ítnportantes que nos são enviadas
por nossas partes interessadas, colegas de t rabalho, clientes e mercado, e então agir
sobre as informações obtidas. Escutar ativamente é crucial para tnanter um EPMO de
padrão mundia l que nos perm ita focalizar naquilo que "importa" hoje e planejar e oti-
mizar proativamente para o futuro. Essa competência cent ral gerou 1nuitas ideias que
estão em várias etapas de desenvolvimento para possíveis futuras implementações. Por
exetnplo, estamos investigando as impl icações de um método relevante modernizado
de pensa tnento estratégico baseado em pesquisas científicas de sistemas vivos. Esse
método de pensa tnento auto-habilitado é planejado para servir de suporte a melhores
perguntas est ratégicas, forta lecendo ainda mais nossa tomada de decisões. Escutar,
compreender, compartilhar e responder a mensagens centrais de um amplo conjunto
Modelo de interação de cliente em estados futuros Fatores criticos de sucesso - Cliente

Coisas que deixam
.... CLIENTE o cOente extremamente Satl"....,.J
satisfeito ....... "
Coisas que deixam
o cliente satisfeito
Como deixaremos nossos O que devemos fazer certo para
-
.1. coO'etores extremamente satlstaz.er o corretor?
satisfeitos?
PASSO #1
Ne<essldades "obrigatórias":
- PASSO #2 OuaJ é o mínimo nece,ssárlo para atender
às necessidades dos corretores?
Ponto de vista do cliente que sustenta o modelo Ideias dos clientes que sustentam os fatores criticos de sucesso
de Interação de estados futuros
Exemplo: Exemplo:
"NJo se trata somente de cobrar um preço "Ser capaz de enviar Imagens de um acidente diretamente
competítlvo por nossa apólice de seguros, do local de ocorréncla agrega um valor enorme!"
mas também de vek>cldade, uma vez que uma CJl'dgM28ÇIO OOS ltQ'dSJ?os do dlMl'e:
lndenlzaçJo por sinistro tenha sido reclamada." "Ger.tm sar/stJç.to· - stllJSfVJ!m 011 nJo, ~ dr> dW!mpMho
--~~---~-~~--~ "Ger.tm muil'J ~Ji>· - s6 po$$Uf{IJ o lido ,ooslbW

"NM!S5'h1.ldlts o.,0nn· - s6 HMUm , sarJst.tÇIO st 1t.Jo tomn IJ/Neod<ls
Oobjetivo principal é captar a visão do cliente da execução
ConlldencUJ do roduto/serviÇ(! nas alavras do ró rio cliente
Figura 12- 15 Exemplo da fe rramenta Broker-On·A-Page (ou Customer-On·A-Page).
de fontes, interna e externamente, pennite que a equipe se focalize no que é itnportante

hoje, mantendo seu caráter inovador.
12.5 Churchill Downs lnc. (CDI):

estabelecendo um PMO
Decid ir implementar um PMO é fácil. Ser capaz de fazê-lo exige que certos obstáculos
seja tn superados. Chuck Mill hollan, di retor de gerenciamento de programas da CDI,
discute a cronologia de eventos pela qual sua organização passou e a lguns dos obstá·
culos que ela teve de superar:
Uma das principais ba rreiras à implementação de processos estruturados de gestão de pro-
jetos, programas e portfólios foi a ;'familiaridade" . O PMO da Churchill Downs Jnc., inau-
g urado em abril de 2007, é o primeiro na indústria de corridas de cavalos p uro-sangue.
Nossos líderes mais sênior compreenderam a necessidade de uma abordagem estruturada
e padronizada para solicitar, aprovar e gerenciar projetos e manter o portfólio de projetos;
entretanto, muitos dos recursos organizacionais nunca tinham sido expostos aos conceitos
formais de gestão de projetos.
Nossos executivos assumiram um papel ativo no processo de implementação.
Eu diria que esse é um dos principais fatores que influenciam o s ucesso imediato desfru-
tado pelo PMO da Churchill Downs Jnc. Estabelecemos nosso PMO com uma visão, deda-
rações de missão e objetivos de negócios claramente definidos. Nosso CEO assinou o termo
de abertura, concedendo autoridade ao PMO para despender dos recursos organizacionais
no q ue diz respeito à gestão de projetos de capital.
i. Nosso PMO foi aberto em abril de 2007.
ii. Desenvolvemos uma missão tripartida focalizada na necessidade identificada por nossos
líderes sênio r:
1. Estabelecer, facilitar e gerencia r a seleção do portfólio de projetos e o processo de

financiamento.
2. Criar fundamento para um s ucesso consistente nos projetos em toda a organização
por meio do desenvolvimento de uma forte e profunda d isciplina de gestão de proje-
tos nas equi pes de projeto da CDI.
3. Guia r os projetos importantes a uma conclusão bem-sucedida, oferecendo liderança
em gestão de projetos, melhorando, ao mesmo tempo, a q ualidade e a repetibilidade
de processos relacionados.
111. Definimos os objetivos de negócio do PMO e atrelamos o progresso ao plano de remu-
neração do Diretor do PMO. Os objetivos incluíam:
1. Desenvolver e implementar pad rões para a seleção de projetos.
2. Desenvolver e implementar uma metodologia de gestão de projetos.
3. Desenvolver um senso de profissionalis mo em gestão de projetos entre os funcioná-
rios da CDI.
4. Gerenciar o portfólio de projetos da CDI.
5. Dirigir a gestão de projetos para in iciativas estratégicas chave.
6. Garantir processos para a realização de benefícios.
1v. Também ministramos aulas de treinamento sobre gestão de projetos, formação de equi -
pes, pensamento críticos, etc. para não somente compartilhar nossos conhecimentos,
mas também para constru ir relacionamentos com os membros da equ ipe de projetos e
outras partes interessadas.
v. O PMO facilito u a criação de um cl ube do livro (também estabelecido com objetivos
definidos) no ano passado. Esse processo recebeu reconhecimento em toda a organi-
zação e contribuiu d iretamente para o desenvolvimento de bons relacionamentos en-
tre diferentes departamentos. O nosso Clube do Livro inclui representantes de nove
d iferentes departamentos, indo de membros do nível do vice-presidente a contribu i-
dores individ ua is.
1. Objetivo 1: Crescimento pessoal por meio da conclusão de livros escolhidos e de um
envolvimento ativo em discussões.
2. Objetivo 2: Exploração de ideias criativas e modos de abordar q uestões de negócios
do m undo rea l por meio da aplicação prática de conceitos e de uma aprend izagem
compartil hada no q ue diz res peito à Churchill Downs e às suas respe.c tivas equipes.
3. Objetivo 3: Promoção da interação entre d iferentes á reas funcionais na eq uipe da
Ch urchill por meio da ativa participação em discussões do Clube do Livro e de opor-
tunidades de compartilhamento de modos de abordar problemas profissionais do
mundo real em um ambiente seguro e confidencia l.
4. Objetivo 4: Compartilhar a aprendizagem com as respectivas eq ui pes por meio de
uma discussão interdepartamental e da implementação de conceitos relacionados à
aprendizagem.
vi. Os principa is fatores determinantes por trás da decisão da Churchill Downs Jnc. de
postula r um PMO foram desafios relacionados à definição e ao gereciamento do escopo
de projetos, alocando eficientemente os recursos entre d iversos projetos e levando os
projetos a um encerramento definido.
12.6 Churchill Downs lnc. (COI):

gerenciando mudanças no escopo
PMOs maduros ou par ticipam diretamente nas 1nudanças no escopo que superam
certo valor ou estabelece1n processos para controla r muda nças no escopo. C huck
Millholla n, diretor de gerenciamento de programas da CDI, identifica seis passos ne-

18
cessários pa ra a defi nição e contr ole de mudanças no escopo:
Passo 1: seja "enxuto"

Tenta r introduzir qualquer tipo de estrutura o u controle em uma organização ou ambiente
que apresente uma a usência de controles pode representar um grande desafio. Antes de uma
organização de gestão de projetos poder abordar o controle de mudanças no escopo, ela
deve implementar um p rocesso para definir o escopo. Fazer os tomadores de decisões da
organização aceitarem os preceitos da gestão de projetos não é muito d ifícil, mas mudar o
comportamento organizacional para tirar máximo proveito desses princípios é outra histó-
ria. Q uanto ma is mudanças tentarmos introduzir em um ambiente, mais dificuldades esse
ambiente terá para se adaptar, aceitar e abraçar essas mudanças. Para evitar a resistência
natura l a mudanças excessivas, uma abordagem lógica é limitar o seu escopo e se focalizar
nas necessidades imediatas. Foco nos fundamentos e no básico. Por que ter um processo
complexo e extremamente maduro se você não consegue ter um desempenho consistente-
mente bom no q ue é básico?
Passo 2: defi na o escopo preliminar

A necessidade imed iata de uma o rganização sem processos para captar os objetivos de ne-
gócios associados aos requisitos do projeto é definir uma abordagem estruturada para do-
c umentar, avaliar e aprovar o escopo de trabalho preliminar. Observe que aprovar o escopo
de trabalho envolve mais do que fazer que sim com a cabeça, mais do q ue apertos de mãos,
ou um acordo ca usal em critérios amplos e subjetivos. Aprovações, em gestão de projetos,
implicam endossas documentados. Mais simples ainda, assinaturas que forneçam evidências
de acordo e um fundamento sobre o qual se basear. É importante enfatizar para as partes in-
teressadas e os patrocinadores que não estiverem familia rizados com a abordagem estrutu-
rada de nossa profissão que aceitar um escopo de trabalho preliminar não significa q ue você
esteja "p reso" pelo resto da execução. Nada poderia estar mais longe da verdade. Em vez
disso, você está p ro tegendo seus interesses ao começar a estabelecer li mites sobre os quais
um planejamento eficiente pode ser iniciado. Em outras palavras, você está a umentando a
probabilidade (lembre-se da pesquisa) de q ue o projeto seja bem-s ucedido.
Passo 3: compreen da o que a aceitação final significa para

o patrocinador ou os patrocinadores do projeto
Como sabemos quando alcançamos um objetivo? Q uando estamos viajando, sabemos q ue
nossa viagem chegou ao fim quando chegamos ao nosso destino pretendido. Da mesma
forma, sabemos que um projeto está completo q uando alcançamos os objetivos de negócios
identificados no termo de abertura do projeto, certo? Bem, sim ... e mais um pouco. Esse
"mais um pouco" é o foco do controle das mudanças no escopo. Como sua organ ização
define a aceitação final pelo patrocinador? A abordagem recomendada é definir a aceitação
pelo patrocinador para as partes interessadas usando uma linguagem simples. Essa aceita-
ção é o reconhecimento formal de que os objetivos defin idos no escopo de trabalho original
acordado foram alcançados juntamente com os objetivos estabelecidos em todas as solicita-
ções de mudanças aprovadas. Essa simples definição ajuda a evitar as d iferentes percepções
em torno do que se queria versus o que foi documentado.
" C. Nlillhollan, "Scope Change Concrol: Conrrol Your Projecrs or Your Projecr\V.li Conrrol You1··. Direitos
a utorais ©2008 by Chuck M illhollan. Reproduzido com a permissão de Chuck Millhollan.
Passo 4: defina, documente e comunique uma abordagem

estruturada para solicitar, avaliar e aprovar solicitações
de mudanças
O que é uma solicitação de mudança? Algumas esco las de pensamento s ugerem que mudan-
ças sejam limitadas a solicitações de atributos, de/iverab/es o u trabalho a dicional. Embora
este a rtigo esteja focalizado nesses tipos de solicitações de mudanças, o u solicitações de
mudanças no esco po, é importante observar q ue q ualquer m udança que tenh a o potencia l
de impacta r as expectativas deve segui r um processo forma l de solicitação, a provação e
comunicação. Lembre-se de que gerencia r as expectativas agressivamente é nossa melhor
o portunidade de infl uenciar a percepção de valor de nossas partes interessadas. Escopo, o r-
çamento, cronogramas e riscos são tipica mente interdependentes e influencia m direta mente
as percepções de nossas pa rtes interessadas. Além disso, lembre-se de que os processos de
controle de mudanças mais eficientes incl uem avaliações de risco que avaliam os riscos po-
tenciais de aprovar o u não uma solicitação de mudança .
Tenha em mente de que excesso de burocracia, excesso de a nálise o u excesso de pape-
lada desnecessá ria dá às partes interessadas um incent ivo pa ra co nto rnar seu processo. Se
você quer que suas partes interessadas evitem, ignorem o u pulem totalmente seu processo,
inclua bastante "administrivialidades". "Administrivialidades" [no inglês, "ad,ninistrivia"J
é a nova palavra para "processo administrativo trivial" (Como autor, reservo-me o direito
de expandir a língua inglesa). Lembre-se: o foco de nossa profissão é sobre as entregas e os
resultados de negócios, não apenas a adesão a um processo predefinido. Adotar uma abor-
d agem ;'enxuta" para a d ocumentação de solicitações de mudanças no escopo pode ajudar
a influencia r a aceitação desse processo po r vezes do loroso, mas vital, de captar mudanças.
Dica de processo: Determine a ntecipadamente (ou como um padrão da empresa o u pa ra
o seu projeto específico) quais são os "acionadores " e os níveis associados e a utoridade para
aprovar uma mudança solicitada. Que nível de mudança pode ser a provado internamente?
Por exemplo, uma mudança com um impacto de um atraso no cronograma de menos de
uma semana o u um impacto sobre o orçamento de menos de US$10 mil pode ser a provada
pelo gerente de projetos. O que precisa ser esca lado para o patrocinador d o projeto, o que
precisa ser revisado po r um comitê de controle de mudanças ou um conselho de governa n-
ça? Determina r esses pontos de decisão com antecedência pode remover grande parte do
mistério em torno de como gerencia r as mudanças.
Certifique-se de que todos co mpreendam a di ferença entre o processo de deco mposição,
com a identificação de novos traba lhos que tenha m que ser realizados para alcançar um
objetivo de negócios previamente aco rdados, e o trabalho associado a entregáveis novos o u
mod ificados. Lembre-se de q ue o missões e erros de planejamento podem levar a mudanças
no cronograma e orçamento, mas no rma lmente não se trata m de mudanças no escopo.
Passo 5: documente e valide o escopo de trabalho integral

(Criação da Estrutura Analítica do Projeto - EAP)
Uma excelente a bo rdagem para definir todo o trabalho necessário para co mpleta r um pro-
jeto é começar co m o estado fina l desejado e os benefícios esperados associa dos. Que tra-
balho é necessário para pro piciar esses benefícios? Que trabalho é necessário para alcançar
os objetivos aprovados de estado final (ou objetivos de negócios)? Planeje até o nível de
detalhe necessário para gerenciar eficientemente o trabalho. Decompôr os pacotes de tra-
balho a lém d o nível necessário para um gerenciamento eficiente é co nsiderado uma "ad-
ministrivia lidade". Observe que definir e comunica r os processos para aceitação final pelo
patrocinador e solicitar mudanças vêm a mbos antes da decomposição tradicional. Por quê?
Excelente pergunta! Os processos de planeja mento natura is que seguim os ao de.co mpor os
o bjetivos de negócios em pacotes de trabalho definíveis pode ser um cata lisado r para as
solicitações de mudanças. Queremos comunicar a ntecipadamente que mudanças não são
gratuitas e que solicitações a dicionais deverão ser formalmente solicitadas, documentadas,
acordadas e a provadas antes de serem incluídas no escopo de trabalho do projeto.
Passo 6: gerencie as mudanças

Você estabeleceu os fundamentos, d ocumentou o escopo preliminar, definiu processos para
aceitação pelo patrocinador, definiu e documentou processos de solicitação de mudanças no
escopo e desenvolveu sua EAP, então, a única coisa que falta é gerenciar de acordo com suas
políticas e seu plano. Já ia me esquecendo ... você precisa gerenciar as solicitações de mudanças
que garantidamente virão também! O controle de mudanças no escopo protege o gerente de
projetos e a organização de a umentos graduais no escopo e contribui para gerenciar as expec-
tativas das partes interessadas. Uma pergunta que frequentemente s urge entre os praticantes é:
"o que eu faço quando meus lídere.~ não me permitem definir, documentar e gerenciar mudan-
ças?". Essa é uma pergunta real e de caráter prático que merece uma resposta. A abordagem
instintiva é comunica r a necessidade de uma abordagem estruturada para documenta r e ge-
rencia r o escopo. Como nossos colegas confessariam, isso nem sempre é suficiente para con-
seguir o s uporte de que precisamos para estabelecer a política organizacional. Podemos tentar
implementar esses processos sem formalização, ou simplesmente "fazer de uma forma ou de
outra". Essa pode ser uma abordagem eficiente para demonstra r o valor, mas também pode
ser percebida como uma medida de a utoproteçâo em vez de um processo usada para aumentar
a probabilidade de sucesso do projeto. As pessoas podem ficar desconfiadas de uma outra
pessoa documentar solicitações, justificativas, etc. para as necessidades delas. Certifique-se de
compartilhar as informações e fornecer uma explicação quanto a por que essa abordagem é
projetada para garantir que você esteja gerenciando as expectativas delas. Em gera l, as pessoas
têm dificuldade em rejeitar abordagens altruístas que a tendam às suas necessidades.
Aprenda com as lições dos outros: uma aplicação no mundo real

Tirando proveito de experiências, melhores práticas e lições aprendidas, o escritório de
gerenciamento de programas da Churchill começou com o básico: estabeleceu seu PMO.
A missão tripartida d o recém-fundado PMO era estabelecer, facilitar e gerenciar a seleção
do portfólio de projetos e o processo de financia mento; criar um fundamento sólido para
o sucesso consistente de projetos em toda a organização por meio do desenvolv imento de
uma disciplina de gestão de projetos forte e onipresente; e guia r os principa is projetos para
uma concl usão bem-sucedida, oferecendo liderança em gestão de projetos e melhorando,
ao mesmo tempo, a qualidade e a repetibilidade de processos relacionados. Parece padrão,
não é mesmo? A missão foi, então, decomposta em objetivos específicos e a conclusão bem-
-s ucedida desses objetivos foi atrelada à remuneração do diretor do PMO.
Objetivos do PMO incluídos

1. Desenvolver e implementar processos-padrão para solicitações, avaliações e financia-
mento de projetos, de modo a garantir que os projetos aprovados estejam a linh ados
com as metas e objetivos da Churchill Downs lnc.
2. Desenvolver e implementar uma metodologia padronizada de gestão de projetos, para
incluir políticas, padrões, diretrizes, procedimentos, ferramentas e templates.
3. Construir um profissionalismo em gestão de projetos, propiciando mentoria, treinamen-
to e orientação às equipes de projeto para que elas aprendam e adotem os processos e as
melhores práticas de gestão de projetos.
4. Gerenciar o portfólio de projetos da Churchill Downs lnc., garantindo que a docu-
mentação necessária esteja dispon ível e que as partes interessadas estejam devidamente
informadas sobre o processo contínuo do portfólio de projetos por meio de relatórios
eficientes dos indicadores-chave de desempenho.
5. Direcionar a gestão de projetos para iniciativas estratégicas chave.
6. Garantir a realização de benefícios usando processos para definir claramente os casos
de negócios e as métricas associadas para medir o sucesso d os projetos. Facilitar a men-
s uração e os rela tórios de benefícios pós-implementação.
No que tange ao controle de mudanças, queremos garantir que o processo seja enxuto,
que nossas partes interessadas compreendam a importância do processo e, fina lmente... e
d iscut ivelmente mais importante ... q ue elas sejam comunicadas de uma forma que nossas
partes interessadas compreendam e possam acompanh ar os processos de solicitação de mu-
danças. Uma pergunta instigante para nossos praticantes: "Por que esperamos que nossas
partes interessadas aprendam e compreendam nosso jargão?". Para auxiliar na compreen-
são e no treinamento, desenvolvemos ferramentas visuais que documentam nossos proces-
sos gera is de gestão de projetos em uma linguagem compreensível. Por exemplo, a "pista de
corrida " do projeto (ver Figura 4-10) demonstrou para nossa liderança e para os membros
da equipe de projeto o que nós, em nossa profissão, consideramos como garantido e uni-
versa lmente compreendido: que os p rojetos possuem um início definido, um fim defin ido e
q ue exigem certa documentação ao longo dos processos de planejamento e execução para
garantir que todos compreendam as expectativas e q ue realizaremos os benefícios pretendi-
dos com o investimento feito.
Para a Churchill Downs lnc., o controle das mudanças no escopo começa com o estabe-
lecimento de uma Planil ha de Solicitação de Investimento preenchida (ou caso de negócio) e
com um escopo de trabalho acordado segundo o que foi descrito em um termo de abertura
assinado. O trabalho é, então, decomposto até um nível de detalhe exigido para controlar o
esforço e completar o trabalho necessário para alcança r os objetivos solicitados e aprovados
como foram detalhados nesse termo de abertura solicitações de mudanças no escopo apro-
vadas posteriormente. Uma solicitação de mudanças no escopo consiste em um template de
fácil compreensão a ser preenchido, e o processo é facilitado pelo gerente de projetos. O que
é ainda mais importante é que o formulário de solicitação de mudanças no escopo é usado
para documentar os objetivos de negócios de uma solicitação de mudanças, as métricas
necessárias para garantir que os benefícios da mudança sejam realizados, o s impactos sobre
cronograma e custos, a fonte de financiamento e as aprovações necessárias para incluir a
solicitação no escopo de trabalho geral.
Alguns dos benefícios que a Church ill Downs Jnc. realizou a té o presente momento a
partir dessa abordagem estruturada de documentar e controlar o escopo incl uem:
1. Documentar retroativamente o escopo para projetos de legado, o q ue resultou em can-
celamento de projetos q ue eram atormentados por mudanças descontroladas a ponto de
o produto final não mais entregar os benefícios apresentados no caso de negócio.
2. Negar solicitações de mudanças no escopo baseadas em retornos sobre investimentos e
análises de impactos factuais.
3. Garantir q ue as mudanças no escopo solicitadas contribuiriam com os o bjetivos de
negócio aprovados pelo conselho de investimentos.
4. Empoderar os membros da equipe de projeto para d izer "não" a solicitações de mudan-
ças informais que possam ou não propiciar um benefício quantificável.
5. Demonstrar q ue ideias aparentemente excelentes podem não suportar uma análise de
impactos estruturada .
12.7 Tipos de escritórios de projetos (EP, PO ou PMO)

Há três tipos de EPs normalmente util izados nas empresas.
• EP fu ncional: Esse tipo de EP é utilizado em uma área funciona l ou divisão de
uma organização, como os sistemas de informação. A principa l responsa bili dade
desse tipo de EP é gerenciar u1n pool de recursos críticos, isto é, o gerenciamento
de recursos. Muitas empresas mantêm um PMO de T I, que pode ou não ter a res-
ponsa bilidade por reahnente gerenciar projetos.
• EP de grupo de clientes: Esse tipo de EP é para um 1nelhor gerenciamento de clien-
tes e uma melhor comunicação com os 1nesmos . Clientes ou projetos comuns são
agrupados para um 1nelhor gerenciamento e relacionamento. Pode haver diversos
EPs de grupos de clientes concomita ntes, e eles podem aca bar funcionando co1no
uma organ ização te1nporária . Com efei to, um EP age como uma empresa dentro
de out ra empresa e tem a responsabi lidade de gerenciar projetos.
• EP corporativo (ou estr atégico): Esse tipo de EP atende toda a empresa e se foca-
liza e1n questões corporativas e estratégicas em vez de em questões funcionais. Se
esse EP gerenciar projetos, normalmente trata-se de projetos que envolvem esfor-
ços de reduções de custos.
Como será discutido posteriormente, não é incomum que exista mais de u1n tipo
de PMO ao mesmo tempo. Por exemplo, a A1nerican Greetings mantinha um PMO
funcional e1n TI e u1n PMO corporativo ao mes1no tempo. Co1no um outro exe1nplo,
considere os seguintes comentários feitos por um porta-voz da AT&T:
O escritório de gerenciamento de programas de clientes (CPMO, Clie11t Program Manage-
me11t Of(ice) representa uma organização (p.ex.: unidade de negócio, segmento) que geren-
cia determinado conjunto de projetos de um portfólio e interage com:
• Patrocinadores do cliente e gerentes de projetos de clientes para os projetos a ele designados
• Seu DPMO designado (ver Papéis e Responsabilidades do DPMO para contatos)
• Seu representante designado do Escritório de Administração de Portfólio (PAO, ou Port-
(olio Admi11istratio11 O((ice)
• Factories da organização para a linhamento de recursos (AR) pelo principa l executivo
de projetos (CPOJ
O escritório de gerenciamento de portfólios de departamento (DPNIO, Departamental
Project Ma11ageme11t O((ice) oferece suporte ao diretor executivo da organização cliente, re-
presentando todo o portfólio do departamento. Serve como principal ponto de contato entre
os CPMOs designados dentro de sua organização cliente e o PAO para o gerenciamento do
portfólio departamental geral nas seguintes áreas:
• Planejamento anual de portfólio
• Financiamento de capital e despesas dentro dos alvos de capital e despesas do portfólio
• Gerenciamento de mudanças listadas no plano e anexos ao caso de negócio
• Priorização de Projetos do Portfólio Departamental
O PMO é liderado por um diretor executivo que é colega dos diretores executivos de gestão
de projetos. Todos os diretores executivos se reportam ao vice-presidente de gestão de projetos.
As funções do PNIO incluem: Definir, documentar, implementar e continuamente apri-
morar os processos, ferramentas, informações de gerenciamento e requisitos de treinamento
em gestão de projetos a fim de garantir a excelência na experiência do cliente. O PMO
estabelece e mantém:
• Processos e procedimentos de gestão de projetos eficientes e eficazes em todo o portfólio
de projetos.
• Sistemas e ferramentas focalizadas em melhorar a eficiência das atividades diárias do geren-
te de projetos, atendendo, ao mesmo tempo, as necessidades dos clientes externos e internos.
• Gerenciamento de informações que medem a experiência do cliente, o desempenho do
projeto e o desempenho organizacional.
• Grade curricular de treinamento/certificação que sirva de suporte aos objetivos organi-
zac1ona1s.
19
12.8 Dell lnc.
Aumentar a eficiência e melhorar a qualidade da execução
de projetos por meio de padronização e governança
A Deli Services padronizou a gestão de projetos e uma abrangente est rutura de PMO
para servir de suporte à consistência na execução com resultados confiáveis, previsí-
" ©2013 by Deli lnc. Reproduzido com permissão.

veis e de alta qualidade para projetos e progra1nas complexos, oferecendo, assim, uma
execução suave, e permitindo que nossos clientes façam ma is por meio de soluções de
negócio integradas, holísticas e de múltiplos serviços.
Sobre a Deli Services

A Deli lnc., sediada no Texas, EUA, é o 3" fornecedor mundial de PCs desktop e note-
book. Seus produtos tecnológicos - inclu indo servidores de redes, impressoras, siste-
mas de armazenamento de dados e projetores - alcançam uma base de cl ientes global.
Ela oferece também software e hardware de terceiros, aléin de serviços de TI. Com
mais de 100 m il funcionários, a Deli registrou US$62 bi lhões em receitas no ano de
2012.
Uma de suas principais unidades de negócios, a Deli Services possui 52 m il funcio-
ná rios em 1na is de 90 países e oferece:
• Serviços de aplicativos
• Serviços gerenciados
• Serviços na "nuve1n"
• Serviços de suporte em TI
• Serviços de configuração
• Serviços de instalação
• Serviços de fabricantes de equipa1nentos originais (OEM, Original Eq11ipme11t
Manufacturer)
• Serviços de segurança nas informações
• Computação de usuários finais
• Serviços de t reinamento
• Consultoria empresarial para centros de dados e cargas de trabalho
• Terceirização de processos de negócios
Criada, na 1naior pa rte, por meio da aquisição da Perot Systems em 2009, a Deli
Services presta suporte a 95'% das empresas globais da Fortune 500, 10 m ilhões de pe-
quenas empresas, 400 mil salas de aula, todos os governos do G20, 200 1nil médicos,
7 5 mil canais parceiros e 60 mil estabelecimentos de varejo.
Evolução da estrutura PM3 da Deli Services

Há 1na is de 28 anos, a Deli estin1ula países, co1nunidades, clientes e pessoas e1n todo
o n1undo a usaren1 a tecnologia para realizaren1 seus sonhos. A Deli te1n um co1npro-
1netin1ento com prestação de serviços, soluções e produtos de que os cl ientes precisan1
para alcançar seus objetivos de negócios e que sejam adequados aos seus estilos de vida.
A aquisição da Perot Systems pela Deli em 2009 combinou duas marcas icõnicas
de TI. A Deli expandida se tornou mais bem posicionada para um cresci1nento imedia-
to e de longo prazo e eficiência impulsionada pelo fornecimento de uma gama ma is
ampla de serviços e soluções de TI e pela otimizaç.ã o do modo como eles são executa-
dos; ampliando o alcance das capacidades da Perot Syste1ns nos segmentos de cl ientes
mais dinâmicos, em todo o mundo; e fornecendo os sistemas computacionais da Deli
a mais clientes da Perot Systems.
Em 2010, o presidente da Unidade de Negócios da Deli Services pat rocinou o
lança1nento do Programa de Padron izaç.ã o Gestão de Projetos e1n toda a E1npresa
(EPMS, Enterprise Project lvf.anagement Standardiz,ation). Para estimular eficiências e
mel horar a experiência gera l do cl iente ao oferecer soluções integradas, end-to-end e
multiserviços aos clientes da Deli, é imperativo que as equipes de projeto demonstrem
u1na execução unificada, suave e de a lta qual idade. Ao longo dos três últimos anos,
o Programa EPMS foi bem-sucedido em alcançar o objetivo máxi1no: estabelecer um
padrão mínimo de práticas de gestão de projetos para aumentar conhecimento espe-

cial izado, eficiência e eficácia em toda a Deli Services, aumentando, em última análise,
o sucesso da execução globa l de projetos, com o passar do tempo.
A equipe do Progran1a EPMS começou con1 os melhores con1ponentes existentes
de gestão de projetos, já contribuindo con1 o sucesso operacional en1 toda a organiza-
ção. Por meio da colaboração com representantes de todos os segn1entos da Deli Servi-
ces e equipes de execução e1n todo o inundo, o Progran1a de Padronização de Gestão de
Projetos en1 toda a E1npresa (EPMS) trabalhou para estabelecer un1a estrutura padrão
de gestão de projetos chan1ada de "PM3" (gestão de projetos, gerencia1nento de pro-
gra1nas e gerenciamento de portfól ios, ou Project Management, Program Management
e Portfolio Manage1nent). (Ver Figura 12- 16.)
A estrutura patenteada PM3 20 é a Est rutura Global de Execução de Projetos da
Deli Services, que engloba a Estrutura de Gestão de Projetos e Programas, a Estrutura
do Escritório de Gestão de Projetos (PMO) e os padrões e processos internos de Go-
vemança de Execução de Projetos.
A estrutura PM3 de Gestão de Projetos/Programas:

a. Aborda os aspectos de pessoas, processos e ferramentas da gestão de proje-
tos, programas e portfólios.
b. É flexível, ampl iável e aplicável a qualquer tipo de projeto.
c. Está completamente alinhada às melhores práticas reconhecidas pela indús-
tria, pelo Gttia PMBOK® do Project Management Institute e pelo Padrão
para Gerenciamento de Portfólios do PMI®.
d. Reúne e integra de maneira exclusiva os ativos de metodologia on-line, via
SharePoint, para ajudar os 1nembros de equipe de GP a navegar rápida e
facilmente pelos processos, templates e kits de ferramentas de suporte, por
meio de u1na variedade de modos de visual ização de fácil uti lização.
Processos Ferramentas
Pessoas
l l l
A Estrutura de execução global de projetos da Deli Service
Figura 12- 16 Estrutura de execução global de projetos da Deli Service.
20
US Parem 8,407,078 BI: Metl,od o( and System for Managing Projects, Programs and Portfolios Throu •
ghout the Project Lifecycle .
u,
N
N
G)
Governança do Gerenciamento de (1)
portfólio de projetos portfólio de projetos !!l
Desenvolver direclonadores Gerenciar inventários de projetos

""e.
o
(1)
de negócio estratégicos e requisições de novos projetos "O
Desenvolver modelo de c41·@'®1·ii·Gliilli·li®V$• Priorizar projetos para a execução
.2.
(1)
governança e métricas g
Executar e Implementar Gerenciar. analisar e reportar
modelo de governança
Gerenciar mudanças
de projeto com portfolio
Portfólio
Risco de saúde
Mudança
Requisições
Suporte do PMO para gestão

C> de projetos e programas
ta ~;;
.., 'E
E o
e "'
m o Categorização de projelOs, certKicaç6es de
E..,
.!! gestão de projetos, certlficaçlles de planejamenlO
u..,li) de projetos, avallaç6es de saúde de projetos
m..,
e "'
·-
~
m -
"' =
~ Planejamento e design '
organizacional do PMO
Figura 12-17 Fluxo de processos do PMO.
" N. de T.: RALO é uma sigla que se refere a uma ferramenta de gestão de projetos e significa Riscos, Premissas, Problemas e Dependências (no inglês, Risks, Assumptions,
lssues, Dependencies).
A estrutura PM3 do PMO (ver Figura 12-17):

• Foca liza-se em padrões, processos, ferramentas e templates no nível do port-
fólio, abordando seis funções-padrão do PMO. Essas ferramentas e processos,
quando devidamente aplicados, aumentam a qualidade e a eficiência da execu-
ção do projeto por meio de uma melhor govemança, suporte geral e incentivo
do uso das melhores práticas e lições aprendidas.
• Fornece os processos, ferramentas e te,nplates para executar um grupo de fun-
ções-padrão que sirvam de suporte ao sucesso do negócio, por meio de:
• Governança do porúól io de projetos
• Gerenciamento do portfólio de projetos
• Gerenciamento de recursos do portfólio
• Gerenciamento da qualidade do portfólio
• Suporte do PMO à gestão de projetos e programas
• Planejamento, design e gerencia tnento organ izacional do PMO
• Representa o componente de gerenciamento de portfólio do PM3; trabalha
dentro da est rutura PM3 para propiciar maior compreensão organizacional de
todos os aspectos da execução de projetos tanto no nível tático quanto no estra-
tégico. O PMO tatnbém ajuda a alocar eficientemente os recursos entre as ini-
ciativas em andamento e governa os projetos de um ponto de vista estratégico,
ajudando a aumentar o alinhamento da execução do projeto com os objetivos
est ratégicos do cliente.
• O PMO...
• Racionaliza o esforço de gestão de projetos, programas e portfólios e aumenta
a qual idade e a eficiência da execução de projetos.
• Fornece dados que podetn ser aplicados para aumentar a taxa de t ransfe-
rência (thro·u ghput) do projeto, maximizando, assim, o ganho estratégico do
cliente sobre seus investimentos.
• É criado para acelerar o gerenciatnento de mudanças organizacionais.
• Fornece linhas claras de liderança e autoridade de projetos para escalada e
resolução de problemas.
• Em geral, a Estrutura PM3 da Deli Services cont ribui para a excelência opera-
cional tanto para a Deli quanto para nossos clientes:
• Demonstrando uma execução unificada e suave para nossos clientes, padro-
nizando a gestão de projetos e gerando soluções integradas, end-to-end e
multisserviços.
• Aumentando a probabi lidade de sucesso na execução, cotn melhores práticas
comprovadas, repetíveis e a linhadas à indústria.
• Fornecendo um contínuo monitoramento e geração de relatórios sobre o
desempenho do projeto, usando 1nétricas quantitativas de alerta precoce;
identificando e 1ninimizando proativamente os itnpactos negativos, o que, etn
últi tna análise, contribui para a fidelidade do cliente.
• Permitindo que os gerentes de projetos cresça tn e prosperem por meio de t rei-
na tnentos e certificações flexíveis, custo-efetivos e a linhados à indúst ria, for-
necendo um desenvolvimento profissional contínuo e p lanos de carreira mais
claramente definidos.
Garantindo a qualidade por meio da governança da execução de projetos

Governança da Execução de Projetos é o processo e a estrutura de responsabili-
zação associada para supervisionar, n1onitorar e cont rolar o desen1penho global
da execução de projetos, além do cumprin1ento dos padrões PM3 para gestão de

proJetos.
O processo PM3 de Governança da Execução de Projetos:

• É aplicável a projetos e progra1nas internos e externos.
• É devidamente esca lado com base em uma Categorização de Co1nplexidade de
Projetos (PCC, Project Complexity Catego-rization) padronizada - que classifica
cada projeto de acordo com u1n questionário comum sobre seu ta1nanho, com-
plexidade e fatores de r iscos.
• Inclui as responsabi lidades do PMO da conta, do PMO da linha de negócios/
equipe de execução e/ou Líderes de Governança, a lém da do PMO da Un idade
de Negócio (BU, B11siness Unit) de Serviços. Esse padrão também define opa-
pel do gerenciamento de operações na governança da execução de projetos e o
modo como trabalhamos rodos juntos.
• É real izado por meio de uma governança, geração de relatórios, ga rantia da
qualidade (GQ) e atividades de controle da qualidade feitos de modo rotineiro.
Esse processo de governança mel ho ra a visibilidade do desempenho do projeto
no nível da Linha de Negócios e da Unidade de Negócios (BU) da Deli Services, além
de definir padrões para mensurações e relatórios de desempenho. As informações di-
vu lgadas em relatórios como parte do processo de governança fornece1n um alerta
precoce e são usados para d isparar o cont role de qua lidade, a lém de processos de
intervenção e remediação para projetos de baixo desempenho.
O escopo do controle desse processo de g overnança no nível da BU

da Dei/ SeNices é:
• Desetnpen ho global de execuç.ã o de projetos
• Cu1nprimento dos padrões de gestão de projetos
Os benefícios da Governança da Execução de Projetos PM3 incluem:
• Melhora a visibi lidade do desempenho do projeto em toda a Deli Services.
• Fornece um monitoramento contínuo, a lerta precoce, identificação e inspeção
de projetos de ba ixo desempenho por meio de relatórios de desempenho quan-
titativos e objetivos.
• Facilita uma rápida resposta, a intervenção proativa e a remediação de projetos
e programas de baixo desempenho.
• Define un1 padrão con1un1 consistente para n1étricas de dese1npenho e relatórios.
• Cont ribui, em última anál ise, para a redução dos impactos negativos sobre as
finanças da e1npresa e a satisfação do cliente.
• Aumenta nossa capacidade de replicar a excelência em todos os nossos projetos.
• Possibi lita a consistência na execução, com resu ltados confiáveis e previsíveis.
• Garante uma metodologia e um kit de ferra1nentas padronizadas de gestão de
projetos em toda a Deli Services, oferecendo suporte às metas de esca labilidade
e crescimento.
Possibilitando o sucesso por meio de desenvolvimento, certificação

e habilidades de liderança do gerente de projetos
A "arte" e a "ciência" da gestão de projetos
A metodologia patenteada PM3 e seus documentos de suporte exigem que os mem-
bros de equipe de gestão de projetos sejam qua lificados para interpretar e apl icar
devidamente 1netodologia, padrões e ferramentas, dependendo das necessidades es-
pecíficas do projeto ou programa. A gestão de projetos não pode ser executada cotn
sucesso, nem seu valor e seus benefícios podem ser plena tnente realizados segu indo
uma lista de verificação, ou um procedimento passo a passo. Os padrões, processos
e ferramentas são apenas metade da equação. A gestão de projetos bem -sucedida de-
pende de liderança e tomada de decisões fortes, além de julga1nentos especializados.
Para tirar máximo proveito dos benefícios com o uso da Est rutura PM3 de Gestão de
Projetos e Programas, os gerentes de projetos precisam encont rar o equilíbrio entre
a ciência da execução discipl inada e a a rte de usar julgamentos sólidos ao liderar o
esforço. Alcança-se valor quando os processos e ferramentas são apl icados de maneira
adequada e mais eficiente tanto para nossos cl ientes quanto para a Deli Services, equi-
librando riscos com o grau de rigor aplicado.
Os processos e ferramentas de suporte e templates do PM3 são criados para mi-
tigar riscos e produzir resultados previsíveis e repetíveis - tais processos e ferramen-
tas são o que chaman1os de "ciência" da gestão de projetos. Os gerentes de projetos
devem se focalizar não somente nos processos que precisam seguir, n1as tan1bém na
intenção dos processos e nos resultados que esses processos e padrões são criados
para p roduzi r.
A "arte" da gestão de projetos é a aplicação sensata e custo-efetiva da ciência
do problema e ambiente de negócios. A metodologia e as ferra tnentas são flexíveis e
exigem gerentes de projetos experientes e qual ificados para aplicá-las adequada tnente.
E1nbora nossa metodologia forneça diretrizes de dimensionamento (scaling) baseadas
no ta tnanho, complexidade e riscos do projeto, o engajamento de cada cliente é dife-
rente, e esse dimensionamento exige julgamento e experiência por parte do gerente de
projetos para decidir onde persona lizar e onde flexibi lizar.
A Estrutura PM3 é um 1neio para se chegar a um fim. Pode haver vários caminhos
que levatn o praticante de GP aos resultados cruciais que não necessários para o suces-
so do projeto. O gerente de projetos forte sabe equi librar a "arte" e a "ciência" para
garantir que os resultados cruciais sejam alcançados.
Desenvolvendo e mantendo a proficiência por meio do programa

interno de certificação em gestão de projetos PM3
Programa Interno de Certifcação em Gestão de Projetos PM3
da Dei/ SeNices
É o padrão para alinhar o gerente de projetos certo, com base em suas ha bilidades e
experiência, ao projeto certo, com base no tamanho, complexidade e fatores de risco
(ou nível categorização de complexidade do projeto - PCC).
• Permite melhor alocação dos recursos de gestão de projetos de acordo com os
níveis de cotnplexidade dos projetos, a fim de reduzir os riscos e aumentar a pro-
babil idade de sucesso, da maneira mais custo-efetiva.
• Estabelece utn padrão consistente em toda a Deli Services a fi ,n de permitir mobi-
lidade e promover o progresso na carreira por meio de um plano de desenvolvi-
mento de carreira mais claratnente definido.
• Fornece um nível consistente de qualificação e garantia da qualidade da popula-
ção de GPs, o que é crucial em um modelo de recursos alavancados.
• É um progra tna de certificação etn gestão de projetos em diversos níveis que certi-
fica os recursos de gestão de projetos de acordo com suas habilidades, treinamen-
to e, o que é mais importante, experiência em projetos bem-suced idos.
• É um diferenciador-chave e agrega valor para o cliente, detnonstr ando garantia da
qualidade e desenvolvimento profissional para os 1ne1nbros de nossas equipes de
projetos, o que aumenta o nível de confiança do cliente com nossos recursos de

!lerenctamento.
• E medido e detenninado pela prioridade e necessidade organizaciona l.
• É complementa r à est ratégia de pessoal da Deli e às certificações de gestão de
projetos do PMJ®.
• Reconhece formalmente sucesso, experiência e conhecin1ento do gerente de pro-
Jetos.
• Encoraja e estimula uma cultura de mentoria.
• Promove a proficiência e a consistência em padrões e melhores práticas em gestão
de projetos em toda a Deli Services.
• Garante a designação de gerentes de projetos completos, que tenham demonstra-
do uma aplicação eficiente dos padrões e um sucesso comprovado com projetos e
programas de tamanho e complexidade similares.
• Alinha-se às certificações de gestão de projetos do PMI"', complementando-as.
• Fornece ma ior visibilidade a oportunidades de carreiras para gerentes de projetos.
Investindo no desenvolvimento dos gerentes de projetos para aumentar

a qualidade e o sucesso
Alén1 das habilidades técnicas relacionadas aos processos e ferramentas específicas de
gestão de projetos, ou o que às vezes é chamado de "ciência" da gestão de p rojetos, o
Sisten1a de Aprendizagen1 en1 Gestão de Projetos (PMLS, Project Management Lear-
ning System) da Deli Services enfatiza a in1portância das habilidades de desempenho
humano, ou a "arte" da gestão de p ro jetos. Habilidades excelentes de liderança e um
bom julgamento são crucia is para o sucesso de qua lquer gerente de projetos.
O Programa de Certificação em Gestão de Projetos PM3 e seu Treinan1ento
PM3 associado são cruciais para a sustentabilidade dos padrões no longo p razo . O
PM3 inclu i un1 progran1a curricu lar abrangente que oferece aos membros de equ ipes
de gestão de p rojetos a opo rtunidade de desenvo lver habilidades e con1preender a
abordagem da Deli Services. Esses cursos empíricos baseiam-se no PM3 e seu kit
de ferramentas associados, con1 exemplos e estudos de caso adicionais do mundo
rea l selecionados para aborda r os desafios comuns da gestão de projetos. O p ro-
grama cu rr icu la r de gestão de p rojetos foi aprovado pelo Instituto de Gestão de
Projetos (PMJ®, Program Management Institute), contr ibuindo para o status de
Centro Registrado de Treinamento (REP® Registered Education Provider) da Deli
Services, concedido pelo PMI®, que qualifica os participantes para receberem Un ida-
des de Desenvolvimento Profissional (PDUs, Professional Develop·m ent Units) para
sua certificação de Profissional de Gestão de Projetos (PMP®, Project Management
Profesional) do PMJ® ou outra certificação ou recertificação de gestão de projetos
concedida pelo PMI®.
Todo o treinamento do PM3 é baseado na web, disponibilizado on-line para ofe-
recer acesso e navegação fáceis, da maneira ma is conveniente e custo-efetiva pa ra os
membros das equipes de gestão de projetos da Deli Services. Uma página de treina-
mento é disponibi lizada na intranet para auxiliar o usuário na navegação por todos os
recursos de treinamento disponíveis, organizados por:
Últimos destaques e atalhos para cursos recém-lançados
Importantes links para outros sites relacionados a treinamento específicos para as equipes
Um link d ireto para o repositório do PM3 e o Programa de Certificação em Gestão de
Projetos Plv13
Treinamento classificado por Assuntos ou Programas de Aprendizagem, a linhados a:
• Papel e Nível de Certificação de GP PM3

• Competências de liderança
• Competências técnicas e funcionais
Conduzindo a adoção de longo prazo e a sustentabilidade por meio

das técnicas de gerenciamento de mudanças da organização
Importantes fatos críticos para o sucesso do programa de Padronização da Gestão
de Projetos em toda a Empresa (EPMS) são a abordagem e as técnicas usadas para
conduzir e sustentar mudanças importantes ao longo do tempo para alé1n da unidade
de negócios.
A equipe achou mais eficiente incentivar várias técnicas de Gerenciamento de Mu -
danças Organizacionais (OCM, Organizational Change Management), a começar por:
Patrocinadores comprometidos de nível executivo determinados desde o início e
mantidos durante todo o processo, incluindo enquanto o programa passava para ope-
rações de govemança em regime permanente.
Comunicação de cima para baixo pelos patrocinadores

• Reforçar prioridade e alinhamento à est ratégia organizaciona l geral
• Period icamente
• no mínimo duas vezes por ano, com um progra1na de longa duração, especial-
mente após mudanças na liderança e reorganizações significativas;
• juntamente com a comunicação da estratégia e depois de ela ser comunicada.
Uma "Avaliação de Prontidão para Mudanças" - um elemento padrão do OCM,
promove entrevistas e solicita a contr ibuição de u1n grupo amost ra l de partes inte-
ressadas afetadas de todos os níveis da organização. Essas informações são cruciais
para a implementação, treinamento e planos de comun icação do PM3. Além disso,
oferece-se suporte à adesão, pois a equipe de programa levou o tetnpo necessário para
incluir e ava liar o envolvitnento e participação das partes interessadas desde o início
do progra1na.
Garantir o envolvimento de todos os grupos de partes interessadas
e equipes afetadas
• Gerar um envolvimento e colaboração global em toda a unidade de negócios
de serviços com representantes especia lizados no assunto (SME, sttbject matter
experts) de todas as equipes co1n projetos e1n execução.
• Solicitar e incorporar feedback por meio de deliverables formais e reun iões roti-
neiras semanais ou a cada duas se1nanas.
• Estabelecer um "conselho de orientação de liderança" para o programa, com
representação em toda a unidade de negócios no nível da liderança com auto-
ridade para fazer cu1nprir padrões, remover obstáculos e promover a escalada/
resolução proble1nas.
• Ser colaborativo, e não ditatorial; flexi bilizar pa ra se adaptar à situação de ne-
gócio e ao nível de maturidade da organização, sem sacrificar a qualidade ou a
intenção do padrão. Foco no resultado pretend ido.
Estabelecer e manter a credibilidade do PMO e da equipe de programa

em toda a unidade de negócios
• Liderar por meio do exemplo; demonstrar o va lor por meio de aplicações prá-
ticas, e não de teorias.
• Comun icar o alinhamento com melhores práticas reconhecidas pela indúst ria.
• Garantir que os planos de implementação e/ou melhoria demonst rem valor para
o negócio logo no início e periodicamente, durante a execução, para manter in-
teresse, ritmo e visibi lidade ao va lor - co1n "ganhos rápidos" , de fácil obtenção,
alinhados aos piores "pontos doloridos" da empresa.
• Ser favorável e flexível, equilibrando risco e r igor, a 1npliando e racionalizando
segundo a necessidade, sem sacrificar a qua lidade;
• O PMO existe para servir ao negócio, aos nossos cl ientes e à co1nunidade de
GPs; ofereça apoio e seja flexível, e não seja intrometido ou desrespeitoso.
• Escutar; continuar a tentar compreender o negócio e ser sensível às prioridades
dos cl ientes.
• Envolver-se com organizações externas, aproveitar oportun idades de demons-
trar suas melhores práticas para sol icitar reconhecimento e validação externa da
indústrias; usar essas rea lizações, prêmios e reconhecimentos nas comunicações
para estabelecer e dar credibilidade aos padrões e à equipe do PMO que estiver
à frente das mudanças.
• Co,nunicar, co1nun icar, comunicar! Isso sustenta a visibilidade e o ritmo.
Contribuidores
Os cont ribu idores do PM3 por especial istas no assunto de toda a Deli Services, com
autoria específica para esta publicação pela equipe do PMO da Unidade de Negócios
de Serviços:
Micheie A. Caputo, PMP®
Líder do escritório de gestão de projetos da Unidade de Negócios da Deli Services
(PMO da BU) e diretor de programas de padronização de gestão de projetos
(EPMS)
H ern1 Barringhaus, PMP®, CSM
Allison Bass, PMP®, !TIL®, 6<1GreenBeit
Bonnie Flynn, PMP®
Tracy F. Grimes, PMP®
Brad Horner, PMP®
Tama S. Kinsey, PMP®
David H. Meyer, PMP®, CSM
Steve Sheppard, PMP®, PRINCE2®
12.9 Computer Sciences Corporation (CSC)

Considere por um momento a seguinte situação: sua empresa quer iniciar um PMO
para funcionar como o gua rdião da propriedade intelectual de gestão de projetos.
Você contrata u1na pessoa que já fez isso antes para uma out ra empresa com certo
grau de sucesso. O que essa pessoa traz para a sua e1npresa são os sucessos e fracassos
que ela já vivenciou em uma empresa anterior. Esse indivíduo tomará decisões basea-
das nessas experiências. Essa abordagem pode funcionar, e pode funcionar bem. Mas
há uma 1naneira melhor de alcançar a meta da implementação de um PMO.
Mais empresas hoje parecem contratar empresas de consu ltoria para ajudá-las
na implementação de um PMO. As empresas de consultoria mantêin arqu ivos sobre
os sucessos e fracassos de todos os seus clientes, e os consultores que você cont rata
podem tirar proveito das experiências fornecidas no repositório de conheci1nentos
da empresa de consultoria. Se o consultor necessitar de ajuda com a lguns problemas,
pode cha,nar outros consultores para seu aconselhamento e orientação. Dito de forma
simples, o consultor cont ribui com talvez centenas de anos de experiências e melhores
práticas documentadas, enquanto a pessoa que você contratou na alternativa anterior

pode contribuir apenas com cinco a 10 anos de experiências pessoais.
Utn out ro problema ocorre se a pessoa que você contratar não estiver fa 1niliariza-
da cotn sua indúst ria. As empresas de consultoria geralmente mantêm a rquivos clas-
sificados por indústria. Isso pode beneficiar significativamente o consultor designado
à sua empresa. Cotn as etnpresas de consultoria, geral mente é mais fáci l encontrar
consultores específicos para cada indústria. Ao in iciar um PMO em um ambiente de
serviços de saúde, isso é essencial.
Para ilustrar como contratar uma em presa de consultoria pode ser benéfico, con-
sidere a csc:2'
A finalidade da CSC é produzir soluções tecnológicas e empresariais inovadoras que aj udem
seus clientes comercia is e governamenta is em todo o mundo a alcançarem aqu ilo que mais
desejam - resultados. O foco é colocado na singularidade de cada cliente ao redor do globo.
A CSC possui mais de 91 mil funcionários em 80 países e está em operação há mais de 49
anos. A CSC focaliza-se em uma ampla variedade de indústrias e oferece serviços de consul-
toria, implementação, terceirização e integração em todos os níveis.
Melhores práticas/cultura/estrutura de governança/metodologia

Na descrição da CSC aci tna, é importante cotnpreender a crucia lidade das palavras
"si ngula ridade de cada cliente". Ao iniciar um PMO em um ambiente de serviços de
saúde, onde aprimorar e manter a saúde são a pr incipal preocupação, estabelecer utn
PMO baseado em uma empresa de engenha ria, construç.ã o ou manufatura pode não
ser aconsel hável. Nan i Sadowski-Alvarez continua:
As melhores práticas foram utilizadas extensamente durante a incorporação de um PMO
(escritório de gestão de projetos) em um grande Sistema de Saúde com uma base de 9 mil
funcionários, localizado em Baton Rouge, Louisiana, EUA, chamado Franciscan lvlissiona-
ries of our Lady. Essa implementação foi conduzida por meio de uma parceria com a CSC
pelo período de um ano, a fim de form ular uma equipe de PMO racionalizada, plenamente
operacional, otimizada e madura, capaz de facilitar e liderar um portfólio grande e equi-
librado q ue consistia em uma mistura de projetos, programas e solicitações de serviços de
foco técnico, clínico e empresarial. As melhores práticas foram estabelecidas por meio de
uma variedade de experiências e lições aprendidas durante implementações anteriores no
estabelecimento de outros clientes, a lém de por meio das lições aprendidas compartilhadas
via afiliações profissionais na indústria de serviços de saúde e também via uma se.ç ão cru-
zada de indústrias, estatísticas baseadas em gerencimento de projetos, tendências da indús-
tria e tendências baseadas em tratamentos e regulamentações de saúde. Além d isso, foram
realizadas pesquisas de clientes (tanto formais quanto informais) para determinar e revelar:
• A percepção dos clientes de á reas dentro de sua o rganização que tenham provado estar
operando de maneira eficiente e eficaz.
• Áreas-alvo q ue são ,e.conhecidas por necessita rem de melhorias
• Áreas e processos que exigem uma atenção focalizada que melhorariam as necessidades
gerais, missão/v isão e direção organ izacional a lmejada, além de fornecer a ênfase dese-
jada sobre a criação de resultados positivos e produtivos.
• Quais e quem são os determinantes percebidos dessa mudança.
• ;' Ritmo" e visão organizacional geral em torno da implementação da metodologia do
pro1eto.
• Áreas que exigem refinamento e revisões.
21
O material sobre a CSC nesta seç.ão foi fomecido por Nan.i Sadowski-Alvarez, PMJY'>, consultora sên.ior de
gerenciamento do CPHIM:S, Gerenciamento e Arquirerura Empresarial de Programas da CSC.
• Pontos de vista dos funcionários internos e (eedback sobre as a uditorias e avaliações

realizadas por o utras agências d e consultoria e audito ria.
• As metas e iniciativas organizacionais estratégicas consideradas.
• A percepção e visão geral da muda nça e da transformação q ue está em a ndamento.
• Ambiente e tom da interação entre as instalações e departa mentos organizacionais.
Sendo um fato que a implementação foi cond uzida/liderada por consultores que fizera m
uma parceria de perto co m o Sistema de Serviços de Saúde, há vá rios fatores adiciona is
q ue precisam ser levados em consideração com a ut ilização das Melho res Práticas como
funda mento orientado r. A segui~ temos uma lista desses "Desafios e oportunidades de 11m
G011s11ltor em tonw da i11Gorporaçiioh11ilizaçiio das melhores práticas":
• Interpretar a partir da c ultura organizacional.
• Escutar eficientemente todos os sinais fornecidos pela o rganização (verba is e não ver-
ba is) em torno de suas necessidades.
• Persona liza r as melhores práticas a um nível que forneçam os resultados ma is benéficos.
• O bter e encorajar um a mplo (eedback e contribuições d os líderes e usuá rios finais de
que as primeiras impressões das Melhores Práticas seja m o ma is positivas possíveis.
• Rea lizar comunicações eficientes que tenham como a lvo o impacto que a iniciativa/
projeto e as Melhores Práticas inco rporadas terão.
• Fornece r respostas adequad as a Q uem, O que, Qua ndo, Onde, Por que e Como em
torno da necessidade da transformação/mudança em andamento.
• Incut ir uma abordagem equilibrada e flexível para o uso das Melhores Práticas com-
provadas como fundamento, com a adição de ajustes que garanta m sua incorporação à
organização que as está a dquirindo e implementado .
• Cria r o equil íbrio a dequado para garantir que silos seja m removidos, permitindo uma
co municação mais transpa rente e fluida e a util ização das Melho res Práticas acordadas.
Defin ição de M elhores Práticas - De modo geral, as Melhores Práticas são processos, pro-
cedimentos, padrões, metodo logias, técnicas, atividades, etc. co mprovadamente mais efi-
c ientes e bem-suced idas e m fornecer eficiências e resultad os mens uráveis d o q ue o utros
processos procedimentos, padrões, metodologias, técnicas e atividades co mparáveis.
Os fatores e perguntas considerados na avaliação das melho res p ráticas são:
• De que se trata ? De processo, procedimento, template, metodo logia, ação ?
• É repetível?
• É algo que resulta em eficiência?
• É algo que ca usa um impacto sobre os cuidados clín icos? Como e que regulamentações
(Metas de Segurança d os Pacientes, JCAHO - The Joint Commission on Accreditation
o f Healthca re O rganizations, Regras de Segurança HIPAAJ são cumpridas ou afetadas?
• Há algum impacto sobre as Iniciativas de Negócios e Avanços Tecnológicos ?
• Que processos de "tentativa e erro,, estavam em vigor para testar um conjunto amostra l
de opções e determinar qual seria o "melhor ca minho" pelo qual proceder?
• Que pa râmetros de avaliação foram implementados a fim de avaliar e d eterminar se
um processo/procedimento/template/metodologia/ação estavam, de fato, atendendo às
necessidades das á reas afetadas e houve eficiências relacionadas a estas?
• Houve uma colaboração cla ra e definível d as pa rtes interessadas para garantir que to -
dos os fatores tenh am sido considerados ?
Amostras das melhores práticas com PMOs na

área de serviços de saúde
• Estrutura r todos os projetos de ma neira consistente co m uma metodo logia central em
vigor (à qual é necessário a derir).
• Passar po r a uditorias periódicas de projetos a leatórios realizadas por um depa rta mento
externo (ou o departamento de serviços jurídicos o u o de qualidade e a uditoria) que são,
então, disponibilizadas a todos os recursos internos que as solicitarem.
• Conduzir apresentações formalizadas de iniciação e encerramento exigindo a presença

de todas as partes interessadas q ue forem convidadas a participar e os membros da
Eq uipe Central. Faz-se, então, o seguimento e a comunicação desses eventos/marcos via
comunicações internas de marketing acessíveis a todos os funcionários.
• Garantir q ue todos os projetos (clínicos, técnicos e empresaria is) recebam contribuições
e classificação de um representante executivo clínico experiente.
• Validar o fato de q ue a classificação/priorização do projeto contém uma se.ç ão direta-
mente relacionada às iniciativas estratégicas das organizações a lém de fluxos de p roces-
so e q ualidade de atendimento.
• Cria r métricas de projeto detalhadas que estejam d isponíveis semanalmente para todas
as partes interessadas e os funcioná rios da organização.
• Cria r transpa rência com toda a documentação relativa ao projeto a fim de garantir q ue
q ualquer pa rte interessada seja capaz de avaliar os itens de ação, riscos, p roblemas,
solicitações de mudança, entre o utros itens correntes, com a capacidade de, então, fazer
s ugestões e propicia r oportunidades de melhoria se assim o desejarem.
• Incutir-lhes a ideia de que os GPs são partes envolvidas na revisão do contrato e no
processo de negociação e q ue eles facilitam a conclusão de uma lista de verificação de
contrato.
• Ter todas as metas de Projetos/Programas e os Ped idos de Prorrogação de Serviços com-
pilados em a linhamento com a filosofia de metas SMART•, para validar o fato de as
metas serem mensuráveis.
• Fazer todos os Projetos/Programas e os Pedidos de Prorrogação de Serviços passarem
por uma Rotatividade Operaciona l formal a ntes do projeto ser marcado como ;'fecha-
do". Essa ro ta tividade ocorre com os membros participantes da Equipe Central, áreas
impactadas e principais partes interessadas e exige a assinatura da gerência em todas as
á reas que recebem responsabilidades de suporte.
• Fazer com q ue os projetos passem pelo processo formal de solicitação de recursos para
valida r o fato de q ue os Gerentes de Recursos serão capazes de oferecer a ded icação
necessária para tornar um projeto bem-sucedido.
Armazenamento e indicação de melhores práticas

As possíveis melhores práticas são ava liadas durante toda a d uração do ciclo de vida do
projeto. São, então, documentadas no template de lições Aprendidas e d isponibilizadas
para todos os funcionários/membros de eq uipe da organização. A documentação do projeto
é armazenada em SharePo int com acesso de visua lização liberado a todos os membros da
Equipe Central, os Nlembros do Com itê de aprovações e as principais Partes Interessadas,
a lém de partes q ue os solicitem . As melhores práticas determinadas são registradas como
padrões e geralmente incorporadas a Políticas/Procedimentos com a necessidade de uma
aprovação via assinatura, garantindo q ue os níveis de a utoridade de suporte e execução
tenham a oportunidade de fornecer (eedback e contribuições.
Metodologia
O PMO foi criado nesse Sistema de Serviços de Saúde (XYZ Health System) sob a d ire.ç âo
da organização além do suporte integra l da CIO/CMIO, dra. Stephan ie Mills e da d iretora
do PMO, Claudia Blackburn, PMP"', CPJ-IlMS (Certi fied Professional in Hea lth lnformation
and Management Systems). Nani Sadowski-Alvarez, PMP" , CPHIMS foi trazida da FCG/
CSC para lidera r a transformação organizaciona l focalizada na implementação. Util izou-se
um misto de metodologias. O fundamento central da metodologia repousava sobre as práti-
cas baseadas no PMI com uma mistura de ISO 9000 (para segmentos sobre os projetos com
• N . de T.: A sigla SMART descreve uma filosofia de definição de meras que sugere que meras "imeligemes'"
(smart, em inglês) devem ser específicas (Specific), mensuráveis (Measurable), alcançáveis (Anainable), realis·
tas (Realiscic) e com tempo (ou prazo) definido (Ttme-bound).
o rientação tecnológica), princípios da gestão de projetos enxuta do Seis Sigma e melhores

práticas já estabelecidas na organ ização. Com o funda mento sendo focalizado no Plvll e no
G11ia PMBOK"', as fases centrais da gestão de projetos (Iniciação, Planejamento, Execução/
Controle e Encerramento) foram infiltradas em todas as implementações do projeto. Po-
líticas e procedimentos de s uporte foram desenvolvidas juntamente com padrões e fluxos
de processo detalhados que se direcionavam a todas as partes interessadas e explicavam a
metodologia passo a passo. Cada uma dessas ferramentas fornecia contribuições em torno
de templates que seriam utilizados nas várias fases, a lém de uma listagem de quais seria m
as sa ídas e resultados. O importante disso tudo era ma nter conceitos e explicações diretos
e simples, e fornecer deta lhes em torno dos recursos responsáveis pela execução dos passos
específicos do processos, tempos previstos de finalização, resultados e referência a processos
interdependentes relacionados. Todos os templates relativos à metodologia, processos, pro -
cedimentos, padrões e fluxos de traba lho foram padronizados e disponibilizados a todos da
o rganização a lém de a fornecedores que os solicitassem. Essa criação de um departamento
transparente permitiu que todas as partes interessadas tivessem acesso a detalhes pertinentes
e à metod ologia do projeto em qualquer momento.
Governança
A transformação da o rganização foi d ividida em diferentes "caminhos", sendo o principa l
foco de um deles a criação e implementação do Plv!O, de um outro, a Governança de TI e
de um o utro a inda, a implementação de um Gerenciamento de Portfólio de Projetos (PPM,
Project Port(olio Management) e de uma ferramenta interna de Recursos de T I e Gerencia-
mento de Capacidade, com um 4• cam inho sendo focalizado na governança organizacional.
A chave para o sucesso é que todos os caminhos devem trabalha r coletivamente a fim de ga-
rantir a colaboração e a coesão dos esforços de cada caminho. A govem ança do sistema de
serviços de saúde foi c riada para garantir adesão de todas as principais á reas - Empresarial,
Clínica e Técnica. O GP (em parceria com o PMO e o Patrocinador de Projetos e Progra-
mas) era responsável pela facilitação do processo e por garantir que os comitês Empresa-
rial, Clín ico e Técnico tivessem a oportunidade de revisar o Termo de Abertura do Projeto/
Programa (e forne.c er (eedback - sugestões) antes da entrega ao Conselho de Orientação. A
partir daí, o projeto pode ou não ir para o Conselho Executivo (Custo pendente do projeto,
ta manho, impacto sobre os recursos conforme indicado nas Políticas de Governança), além
de ser apresentado ao Conselho D iretor. Os parâmetros foram todos claramente definidos
e criados com a participação de importantes recursos de toda a organização. Isso garantiu
q ue todas as á reas tivessem igua l contribuição e que houvesse ma io r probabilidade de rápi-
da adesão e s uporte à estrutura de governa nça.
Sucesso do projeto/ programa

O sucesso do projeto é med ido com base na entrega dos projetos dentro do prazo e do or-
çamento, juntamente com sua capacidade de c umprir a missão/visão do projeto, além das
metas SMART. Tendo dito isso, é preciso confirma r que a metodologia de Gerenciamento de
M udanças seja solidamente dara e aceitável ao realinhar o projeto e seu escopo com aderên-
cia à tripla restrição e que o acordo de que as solicitações de mudança sejam assinadas pelo
Patrocinador de Projeto/Programa. É responsabilidade dos GPs a tua liza r a documentação
do projeto adequadamente e aderir à política, proced imento, padrão e fluxo de processos do
gerenciamento de mudanças em projetos. O stat11s do Projeto/Programa está disponível 24/7
a todas as partes que o solicitarem. Encoraja-se que fornecedores também participem das
a tualizações de stat11s. Os fatores c ríticos de sucesso são claramente detalhados no documento
do escopo do projeto (que também é assinado pelas principais partes interessadas) e, quando
as mudanças são de 25 mil ou acima, envolvem a aprovação via Estrutura de Governança. Os
GPs (Gerentes de projetos e programas) precisam rea lizar atualizações de marcos e produzir
relatórios sobre eles por meio do relatório de status. Os GPs também são medidos e avaliados
com base em sua capacidade de a lca nçar os objetivos de seu papel, baseados em padrões/
indicadores de desempenho. Esses indicadores alinham-se às suas tarefas diárias, às tarefas ba-
seadas em projetos e também às perspe.ctivas metodológicas e às iniciativas organizacionais.
De modo geral, o s ucesso do p rojeto é definido pela organização como um todo. Os
termos de abertura dos projetos contêm todos os deta lhes em to rno da missão/visão do
projeto e das metas do projeto. Uma representação equilibrada está presente em reuniões
do Conselho de Aprovações (do lado Financeiro/Empresarial, do lado clínico e tecnológico
da casa, incluindo os principais executivos, CFOs, médicos, d iretores de tecnologia, líderes
de departamentos, representantes especializados - Stv! Es - etc.) para garantir que as veri-
ficações e balanços estejam claras antes de se votar na aprovação de um projeto. Uma vez
que ele tenha sido apro,•ado, o escopo detalhado é revisado (contendo fatores críticos de
sucesso, problemas/riscos conhecidos, fluxos de processos deta lhados, matriz de comunica-
ção, etc) e aberto para s ugestões/revisão antes de ser assinado. Uma vez tendo sido assinado,
adere-se à metodologia formal de Gerenciamento de Mudanças. Essa metodologia contém
um procedimento emergencial na situação do s urgimento de um item/oportunidade de mu-
dança q ue seja urgente o u imediata. A execução desse processo exige a provação pelo nível
executivo dev ido à magn itude dos ind ivíd uos que serão afetados.
A excelência é definida claramente pela teoria dos 3 Es da "Excelência Excedendo as
Expectativas". Com q ua lq uer esforço para exceder as expectativas in icia lmente estabeleci-
das e aprovadas, há a capacidade de se alcançar a excelência com a presença de racionaliza-
ção, aprimoramentos, econom ias de custos e satisfação dos pacientes e funcioná rios.
Perguntas a serem feitas em torno do sucesso

do programa/projeto
• Os marcos foram alcançados?
• Ocorreu um gerenciamento eficiente das mudanças?
• Os riscos foram s uficientemente mitigados?
• Foram fornecidos relatórios de status seguindo as d iretrizes de políticas e procedimen-
tos d urante toda a d uração do projeto?
• Foram agendadas reuniões periód icas com a Equipe Central?
• As metas e os objetivos acordados do Projeto/Programa foram alcançadas?
• A metodologia do projeto foi seguida d urante todo o ciclo de vida do projeto?
• Q ual é a opinião dos patrocinadores e das principais partes interessadas quanto aos
resultados do projeto/programa?
• Todos os participantes puderam dar sua opinião sobre os sucessos do projeto e oportu-
nidades de melhoria?
• O projeto está dentro do orçamento?
• O projeto foi entregue dentro do prazo?
• Q ua is são os res ultados da(s) a ud itoria(s) do projeto?
NOTA: Descobrimos e confirmamos q ue os templates precisam ser refinados para todos
os clientes, de modo a garantir q ue eles atendam as necessidades e as iniciativas daquela
organização. O comprimento dos templates pode, em determ inados momentos, prej udicar
o s ucesso do projeto. Consequentemente, a recomendação é que o PMO revise e d iscuta
continuamente a utilização dos templates e aj uste-os de acordo com s ua necessidade.
Escritório de gestão de projetos (PMO)

O escritório de gestão de projetos que foi criado para as Instalações de Serviços de Sa úde
consiste em um PMO d iretor, 10 gerentes de projetos (dois dos q ua is são deta lhados como
GPs sênior), dois coordenadores de Ped idos de Prorrogação de Serviços e dois engenheiros
de tecnologia (q ue se focalizam na orientação com avaliações e audito rias da tecnologia dos
projetos). Esse PMO se reporta ao CIO/CMJO a lém de ao Conselh o de O rientação e outros
conselhos. Os Programas (como a implementação do Hospita l do Coração) também são
facilitados por meio do escritório do PMO.
A visão do PMO é "fornecer uma gestão de projetos consistente e pad ron izada com foco
na excelência em um cenário colaborativo. Todos os projetos aprovados conterão metas e
o bjetivos mensuráveis d iretamente relacionados às metas e padrões do Sistema de Saúde
com convergência em dire.ç ão ao a lcance de um continuum abrangente de um atendimento
de qualidade".
Existe um sólido processo de governança, como descrito na seção sobre governança .
O suporte ao PMO vai direta mente dos Executi vos de Nível C até essa organização de
Serviços de Saúde, a lém do ponto de vista co nsistente do valor de que o PMO agrega co mo
um todo. Antes da implementação do PMO, oco rreu uma a uditoria organizaciona l com a
s ugestão de uma metodo logia e padrões mais forma lizados a lém de ma ior transparência em
to rno de esforços e iniciativas foca lizadas no projeto.
Os patrocinadores recebem uma sessão ind ividua l com o Diretor do PNIO e o Gerente
de Projetos designado, para revisar uma a presentação em PowerPoint e várias apostilas q ue
claramente definem qua l é o papel de um patrocinador de projeto. Nessa conversa, ava lia-se
também se eles se sentem preparados para assumir o papel de patrocinador. Em caso negativo,
o fato é levado ao Conselho de Orientação para discussão e determinação de quem poderia ser
um patrocinador apropriado. Ourante a sessão inicia l com o patrocinador, a bordam-se itens
como as Comunicações do Projeto, a frequência dos relatórios de stat11s, as reuniões regulares
entre o GP e o patrocinador, etc., e discutem-se deta lhes. Os patrocinadores de projetos apren-
dem a oferecer suporte aos seus projetos e a valorizar a pa rceria que o GP e o PMO formam
com eles, a fim de garantir que seu projeto seja um sucesso. Apresenta-se a eles também o fo-
lheto de três dobras do marketing do PMO, que contém informações sobre o seguinte:
• FltLxo de processos para o processo de a provação do projeto
• Definições dos principais pa péis na equi pe d o projeto e qua is são suas resposnabilidades
• Fatores críticos se sucesso para tod os os projetos
• Definição de projeto versus programa versus ped ido de pro rrogação de serviço
• Expecta tivas de co municação de a lto nível (incluindo seu papel no a tLxílio à remoção
das ba rreiras ao sucesso do projeto)
• Revisão de alto nível da documentação do projeto q ue será fornecida consistentemente
• Breve panora ma d as fases d o projeto e de sua metodologia
Os patrocinado res são responsabilizados pelo s ucesso de seus projetos e são solicitados
a fazer a apresentação inicial ao Conselho de Orientação, solicitando aprovação. Eles falam
d a ;' necessidade" d o projeto (para a organização), do ROi, das metas SMART, do valor
agregado geral, do impacto sobre os recursos, duração, classificação, etc., juntamente co m
o G P e participam do segmento de perguntas/respostas. Q uando surgem grandes mudanças
(que exceda m um valor de 25 mil o u que tenha m um impacto signi ficativo sobre os recursos
o u o cronogra ma d o projeto), o patrocinador e o gerente de projetos são c ha mados para
uma reunião co m o Conselho de Orientação para fornecer os detalhes e discutir as opções
para resolução e o bter um voto de a provação para a ;'direção" recém-definida a ser seguida.
Suporte da gerência
Os patrocinadores devem ser d o nível da gerência ou acima. Para Pedidos de Prorrogação
de Serviços (iniciativas q ue seja m de 500 horas o u menos de duração e exija m uma estrutura
formal para ser executada), um patrocinador pode residir no nível gerencia l. Pa ra projetos
e programas, no entanto, o patrocinador precisa residir no nível de diretoria para garantir
que ele tenha o poder e a autoridade para aux iliar com a remoção de barreiras ao sucesso.
12.10 Slalom Consulting: compreendendo a natureza

de um PMO
Nos exemplos a nteriores de.ste capítul o, vimos empresas que i1nplementara1n um
PMO depois de utn processo bem reflet ido. No enta nto , mu itas vezes uma empresa se
apressa cotn a implementação de um PMO antes mesmo de decidi r sobre qua l será seu
uso, que funções ele desempenha rá, quem será designado e possíveis p roblemas polí-
ticos internos. Nem todo PMO é igua l, mesmo etn empresas que possuetn múltiplos
PMOs. Ca rl Manello, diretor de práticas de eficiência na ent rega na Slalom Consul-
ting, esclarece-nos sua visão dos PMOs:
Que há num simples nome? Mais do q ue a maioria de nós consideraria. Muitas vezes, a
sigla de três letras PMO é muito discutida, dando muito pouca importância àquilo a que
ela se refere em sua implementação. Já vi essa falta de cuidado ocorrer com meus clientes e
também em o rganizações de consultoria q ue oferecem soluções nessa área . A simplificação
excessiva das organizações de gestão de projetos em um ;'PMO" levou a a lguns res ultados
desastrosos. O que fazem os ;'PMOs", afinal? Eles são:
• Centros de excelência em gestão de projetos (p.ex.: encarregados de processos)
• Escritórios de governança (i.e., supervisão da con formidade)
• Pools de recursos de gerentes de projetos
• Centros de gerenciamento de recursos encarregados de equilibrar oferta e demanda
Já vi cada um desses ser implementado com o mesmo nome: PMO. "E daí?", você pode
se perguntar. ;'Por que é tão importante q ua l nome damos à função? ". Uma rápida anedota
talvez ilustre bem essa questão.
Uma CFO lê na última publicação de uma revista especializada o celebrado sucesso de
uma empresa do seu ramo em sua implementação de um PMO. "Fantástico", ela pensa e
liga para o CIO. "Bill, precisamos fazer sua equipe montar um PMO. Sei que eles podem
fazer uma diferença, ter um impacto financeiro e produzir res ultados. Mãos à obra! " Depois
de desligar o telefone, Bill não tem certeza de a q uem deve recorrer. A CFO quer um Escri-
tório de gestão de projetos, um escritório de gerenciamento de p rogramas, um escritório de
programas empresarial o u um escritório de governança?
Como gerentes de projetos profissiona is, devemos aj udar nossas empresas a d istinguir
a diferença no papel funcional de cada uma dessas diferentes organizações. Temos também
de aj udar a esclarecer a gama de d iferenças de controle - d igamos, entre um Escritório de
Programas e um Escritório de Programas Empresarial. Oriento meus colegas e clientes sobre
devermos nos manter afastados da referência à ideia de que "um nome serve para todos os
casos,,, isto é, de um "PMO,, mítico, e, em vez d isso, falar de funções operacionais.
Por exemplo, a Figura 12- 17 ilustra um Escritório de Governança em TI que possu i
uma variedade de responsabilidades. Entretanto, ele se foca liza no departamento de TI e
não alcança o lado "dos negócios" da empresa. Com um foco somente no departa mento
de TI, a governança assume muitos papéis. Esse "PMO " focaliza-se em presta r auxílio aos
gerentes de projetos, a linha ndo e monitorando a designação de gerentes de projetos, auxi-
liando o Escritório do CIO no planejamento estratégico, monitorando os gastos financeiros/
de projeto do departamento de TI e os relatórios de TI de modo geral para a liderança. Ao
contrário, esse ;'PMO" não contém um pool de gerentes de projetos a serem designados a
projetos em toda a organização de tecnologia de informação. Esse PMO de govemança
também não tem a mesma extensão de controle que um Plv!O (escritório de gerenciamento
de programas) q ue opera dentro dos limites de uma grande iniciativa de negócios.
Para ilustrar a d iferença em extensão de controle, analisemos os seguintes modelos.
Embora não sejam soluções perfeitas para toda implementação, estes valo res mostram a
gama de possibilidades e começam a desconstruir a visão de um único PMO para toda e
qualquer situação. A Figura 12- 18 fornece um dos modelos ma is simples: o escritório de
projetos.12 O escritório de projetos faz superv isão, monitoramento e geração de relatórios,
possivelmente, com algumas funções de governança sobre projetos não relacionados. Ao
contrário, o escritório de gerenciamento de programas da Figura 12- 6 está contido em uma
única iniciativa empresaria l de grande escala . Esse Plv!O tem a responsabilidade por d irigir
21
O s ímbo lo no canto superior direito da Figura 12- 19 iluscra que cada uma das estrururas sucessivas de
PMO nas Figuras 12- 20 a 12- 22 promove as mesmas capacidades de gestão de projetos em (GP que foram
discutidas na Figura 4- 20.
~
CJ)
G)
(1)
!!l
""e.
o
(1)
"O
.2.
(1)
g
Serviços de suporte Suporta a Estratégia a
gerenciamento Supervldo Relat6rlos
8 BIBCUÇão
a entrega de recursos
planejamento financeira e resposta
• Gerenciamento de • Processamento e • Planejamento • Gerenciamento de • Gerenciamento de

conhecimentos suporte ao RH estratégico contratos padrões
• Suporte consultivo / • Desenvolvimento • Gerenciamento de • Gerenciamento de • Monitoramento do
de mentoria de capacidades investimentos ativos fixos desempenho
• Comunicações • Desenvolvimento de • Planejamento • Gastos do projeto • Relatórios para a
• Treinamento planos de carreira organizacional gerência
• Gerenciamento
da demanda
• Seguimento de
projetos
• Gerenciamento
da oferta
• Alocação de recursos
Figura 12- 18 Exemplo de funções de um PMO.

Escritório de
Projetos
Figura 12- 19 Escritório de projetos que supervisiona projetos independentes.
PMO
Figura 12- 20 Escritório de gerenciamento de programas interno ao programa.
um programa de negócios, acompanhar os múltiplos projetos a ele associados e oferecer

monitoramento e relatórios aos principais executivos. Em algumas implementações, o PMO
não é apenas o órgão do programa que governa os projetos, mas é o local de onde os prin-
cipais executivos que dirigem a iniciativa. Na Sears, durante a integração com a K-Mart, e
na Donnelley, em seus esforços do ano 2000, o PMO foi formado pela equ ipe de liderança
executiva do esforço focado em negócios. Havia, é claro, eq uipes que ofereciam suporte aos
gerentes de projetos e programas, mas, quando o presidente se referia ao " PN!O", ele estava
falando da liderança . A Figura 12- 7 ilustra a segunda maior organização de governança: o
Escritório de Programas. Muito similar ao Escritório de Projetos, o Escritório de Programas
supervisiona projetos não relacionados, com a responsabilidade adicional da govemança de
programas. Pela natureza de sua s upervisão, essa organização é normalmente estabelecida
com responsabilidades cruzavam os limites das grandes funções (p.ex.: cruzavam unidades
de negócios). Os membros do Escritório de Programas trabalham com seus contrapartidas
nos Escritórios de Gerenciamento de Programas na coleta de métricas e atualizações de
status. No entanto, geralmente estão foca lizados em um nível mais a lto. Enquanto o PMO
trabalha em um nível detalhado coletando dados, gerando rela tórios e gerenciado um ún ico
.·,.. .·
· ·· ·';;4··~ · · ·
.'
....... {_:a C> ~ .......

······~~-
... : ··.······
Escritório de
Programas
Programa
Programa
Figura 12-21 Escritório de programas que supervisiona programas e projetos.
programa, o Escritório de Programas resume informações de diversas iniciativas para con-

solidação no nível executivo, A última variedade é o Escritório de Programas Empresa rial,
da Figura 12- 18, que é tipicamente implementado em o rganizações muito grandes. Seu pa-
pel é desenvolver a inda mais, consolida r e coordernar iniciativas em toda a empresa . Além
das responsabilidades de governança, esse grupo pode ser encarregado das atividades de ge-
renciamento de portfólios. Com essa visão de toda a empresa, o EPO é adequado para ope-
rar tendo em mente as metas de toda a organização, ao contrário de assumir o lado de uma
unidade de negócios em detrimento de outra . Como parte do primeiro EPO na R. R. Don-
nelley & Sons em 1997, trabalhamos com gerenciamento de portfólio para toda a empresa,
com o desenvolvimento do cronograma mestre, a criação de métodos e processos de gestão
de projetos e oferecemos apoio aos projetos. Trabalhamos cruzando os limites das funções
corporativas, Pesquisa e Desenvolvimento, todas as unidades de negócios (p.ex.: livros e
revistas) e estivemos envolvidos em diversos impo rtantes programas de negócios. Dado que
há tama nha variedade de manifestações da organização de gestão de projetos, com variáveis
graus de controle, não é nenhuma surpresa que também haja uma ampla variedade de níveis
de hierarquia de prestação de contas; uma organização de projetos nem sempre produz re-
latórios para a mesma função em todas as empresas. Tipicamente, já vi o que identifico com
Escritórios de Projetos estabelecidos dentro da o rganização de Tecnologia da Informação.
Muitas, se não todas as iniciativas de TI se reportam ou têm uma conexão com o Escritórios
de Projetos de TI. No entanto, iniciativas que não envolvem o departamento de TI como um
de seus principais componentes tipicamente não são atreladas a esse órgão administrativo.
O meu EPO d a R. R. Donnelley & Sons se reportava ao chefe da organização de Pesquisa e
Desenvolvimento (naquela época, a Donnelley não possuía um CIO em regime de tempo in-
tegral controlando a organização de TI), O meu Escritório de Govemança em TI na Zurich
North America se reportava ao vice-presidente de T I, enquanto a implementação na Sears
de um Escritórios de Gerenciamento de Programas se reportava ao escritório do presidente.
O PMO d a Sears possuía uma relação hierárquica especia l devido à importância e à visi-
bilidade d o programa de negócios que estávamos liderando. Entretanto, a maior parte dos
Escritório de
Programas
Programa
'•.
·•.•, . /
...• ,o.~:;,,°" ···•··
....... ~:::::,: .......
. ,,...
... ... "->41).9•. . •• ....
..
Escritório de
Programas
Empresarial
Programa
Escritório de
programas
Figura 12- 22 EPO (Escritório de Programas Empresarial) que engloba programas e PMOs
(Escritórios de Gerenciamento de Programas).
outros Escritórios de Gerenciamento de Programas normalmente se reporta diretamente ao

executivo convicto enca rregado da iniciativa de negócios.
Embora as ilustrações q ue forneci certamente não sejam exaustivas, acho que fica óbvio
que haja vários diferentes tipos de organização. Há também uma variedade de níveis de
controle ou de hierarquia de prestação de contas. Dada essa variabilidade de implementa-
ção, deve ficar claro para o leitor que um rótulo genérico de ;'PMO" é totalmente inadequa-
do e pode, na verdade, ser prejudicial.
Como foi mencionado em um capítulo anterior, os clientes agora estão exigindo
que suas em presas contratadas avaliem sua organização e detennine1n seu nível de
maturidade em gestão de projetos. Esse processo de ava liaç.ã o, seja impu lsionado pelo
cliente ou interna1nente, muitas vezes exige o envolvi1nento do PMO. Carl Manello
continua:
Com tantos tipos d iferentes de "PtvlOs" (como discutido anteriormente), q ua l é o certo a
se estabelecer? Dito de o utra forma, como uma organização pode avalia r em q ue ponto
se encontra no c:ontinuwn da maturidade em gestão de projetos, para determinar que
tipo de ;;PMO" deve implementar? A resposta é um pouco mais complexa do que se pode
s upor a princípio. É preciso primeiro compreender o ambiente no qual a organização de

gestão de projetos estará localizada, pois, para planejar uma organização de gestão de
projetos que n ão esteja ligada nem ao estado corrente da organização (i.e., competências e
capacidades), nem a uma visão de crescimento e desenvolvimento é uma receita para uma
solução subótima.
Há diversos modelos para se avaliar a maturidade da gestão de projetos. Cada orga-
nização pre.cisa cuidadosamente considerar as implicações do modelo q ue escolher e com-
preender aonde a implementação baseada no modelo a levará. Um modelo de maturidade é
ilustrado nos d iagramas abaixo.
Da mesma forma que o CMMJ (Modelo de Maturidade em Ca pacitação - lntegra-
ção) fornece um modelo de ma turidade em d iferentes "degraus" para o desenvolvimento de
software, o modelo da Figura 12- 23 c ria um modelo de maturidade para as organizações
de gestão de projetos. Os vários degraus estão in forma lmente d ivididos da seguinte forma:
• Fundamentos da construção - estabelecendo funções de gestão de projetos (fGP)
• Foco na execução - implementando um escritório de p rojetos para coordenar/supervi-
sionar projetos discretos
• Foco nos negócios - colocar um escritório de gerenciamento de programas em um papel
de responsabilidade dentro das p rincipais iniciativas de negócios
• Visão integrada - o escritó rio de programas, q ue reúne projetos e programas díspares
em uma visão holística para a organização
• Proposição de valor - realização do escritório de programas empresaria l (EPO)
Embora não haja absolutamente nenhu ma regra sobre como proceder para se alcançar
a maturidade um degrau de cada vez, acred ito q ue q ua lq uer organização q ue tente realizar
a proposição de valor de implementar um EPO antes de ter q ualquer experiência com as
organizações menos maduras está pedindo para ter problemas. Da mesma forma q ue não
se pode pular níveis de maturidade no CMMJ, essa mesma visão deve ser considerada ao
se desenvolver organ izações de gestão de projetos. Um outro paralelo que pode ser traçado
ao CMMI vem do nível de desempenho avaliado de uma organização. Para ser "CMMI"
no sentido mais verdadeiro do termo, uma organização deve ser avaliada por um terceiro
com base em um padrão internacional. Embora não exista tal padrão para avaliar o nível de
maturidade das organizações de GP, as empresas precisam ser bruta lmente honestas quanto
às s uas capacidades e competências.
M uitas das organizações para as qua is já trabalhei tinham uma visão extremamente
o timista de em q ue ponto da escala CM!\lll se encontravam (muitas empresas acham q ue e
Proposição
devalor
--
Visão
integrada
Foco nos
negócios
Foco na
execucão
Fundamentos
da construção
Figura 12- 23 O modelo de maturidade do valor do projeto.

encontram no Nível 3 o u acima!). Da mesma forma, as empresas que " pulam,, níveis por
avaliar de forma excessivamente otimista sua maturidade em gestão de projetos podem, na
verdade, diminuir a proposição de valor do " Plv!O" e, na verdade, afetar negativamente a
empresa.
A Figura 12- 24 é uma visão relacionada da progressão da maturidade, focalizando-se
em seis desafios organizaciona is da gestão de projetos, alinhados aos seis níveis de maturi-
dade. Observe que esse modelo específico foi desenvolvido para ilustrar os desafios relativos
ao desenvolvimento de uma organização de gestão de projetos de TI. Dependendo do tipo
de "PMO", o modelo será d iferente.
• Alinhamento com os negócios - o movimento da organização de TI de uma unidade de
negócio separada a um provedor de serviços para o resto da organização
• Foco no projeto - o crescimento de projetos d iscretos de TI para iniciativas alinhadas
focalizadas no negócio
• Governança - passando de nenhuma s upervisão a uma organização com gerenciamento
baseado em métricas e medidas
• Padrões - indo de uma gestão de projetos ;'selvagem e desregrada" a uma organização
dirigida, com práticas padronizadas
f undamentos Foco na Foco nos Visão Proposição

da construção execução negócios integrada de valor
Ligação e,cplicita Revisões e Métricas de
Foco na com a estratégia atualizações das processos
Alinhamento tecnologia, Ligação fraca ligações com definidas -
com as metas de negôcios -
com os negócios não nos Gerenciamento os negócios - Gerenciamento
negócios de negócios de valor no nivel Gerenciamento do portfólio
do programa de portfólio empresarial
Foco no
projeto
Governança
Padrões
Interdependências
Planejamento Iniciativas de
Projetocentrismo Planejamento cruzadas entre
Escopo de integrado: mudanças
sem deliverables· de programas projetos/
planejamento padrões nos negócios
-padrão padronizado programas
definidos gerenciadas
gerenciadas
Esfera de influência MUltiplas

Projetos Programas Toda a
da comunidade de Não aplicâvel linhas de
individuais individuais empresa
especialização (COE) negócio
Figura 12- 24 Matriz de maturidade.

• Escopo de planejamento - indo de projetos operacionais independentes a projetos pla-

nejados de forma padron izada e repetível e integrados como iniciativas de mudanças
para o negócio
• Esfera de influência da comunidade de especialização (COE) - paralelo ao crescimento
das organizações de "PN!O" descritas acima, da supervisão individual à influência em
toda a empresa
12.11 DTE Energy

Embora os PMOs funciona is possam ser desenvolvidos em qualquer parte de uma or-
ganização, eles são 1nais co1nuns em um ambiente de sistemas de informação. A DTE
Energy mantém um PMO de sistemas de informação. Segundo T im Menke, PMP®,
especialista sênior em mel horias contínuas no gerencia1nento de desempenho de ope-
rações de distribuição da DTE Energy:
Na DTE Energr, o escritório de gestão de projetos (PMO) de Serviços de Atendimento ao
Cliente é uma função com o grupo de Gerenciamento de Programas de Serviços de Atendi-
mento ao Cliente (CSPM, Cusiomer Service Program Ma11age111e11t) que se reporta ao vice-
-presidente de Serviços de Atendimento ao Cliente. O CSPM consiste no PN!O, na equipe
de gerenciamento de processos e na equipe de gerenciamento do cana l de contato com o
cliente.
O PMO fornece s uporte à gestão de projetos para iniciativas de melhorias contínuas
dentro do departamento. Essas iniciativas são criadas para alcançar a Estratégia de Serviços
de Atendimento ao Cliente.
Funções específicas do PMO incluem:
• Desenvolver e manter a metodologia de gestão de projetos
• Manter o portfólio de projetos de melhorias contínuas dos serviços de atendimento ao
cliente
• Coletar e d isseminar dados e métricas do projeto
• Fornecer ferramentas e templates para a gestão de projetos
O portfólio de Serviços de Atendimento ao Cl iente contém projetos dos cinco de-
partamentos que formam o Serviço de Atendimento ao C liente (Questões relativas aos
Consumidores, Assistência ao C liente, Cobrança, Aq uis ição de Dados e Gerenciamento
de Programas de Serviços de Atendimento ao Cl iente). Os projetos melhoram os serviços
prestados aos cl ientes, aumentam a eficiência operacional, e/ou alcançam economias com
as operações.
O PMO poss ibilita e facilita a aplicação do processo de gestão de projetos. Os funcio-
nários do PMO têm uma extensa formação em gestão de projetos e agem como consultores,
articuladores e orientadores em seus respectivos projetos.
Como afirmado anteriormente, o PMO também pode participar do gerenciamen-
to de portfólios de projetos. Isso é comum em empresas que desejam fazer máximo uso
do talento que se encont ra em seu PMO. Ti tn Men ke expl ica:
Selecionamos projetos no nível da empresa baseados em vários indicadores, incluindo Re-
torno sobre Investimentos (ROl), Taxa Interna de Retorno (TIRJ e Valor Presente l íquido
(VPL). Esse processo anual envolve os níveis mais altos de liderança da organ ização e é
parte integrante do processo de priorização e orçamento.
Nosso escritório de gestão de projetos (PMO) se envolve com o gerente de projetos em
projetos "aprovados". Nosso PMO agrega projetos aos portfólios alinhados por unidade de
negócio. Essa abordagem nos permite analisar ;, trade-o((s" entre projetos de determinada
unidade de negócio em um esforço de elevar o desempenho do portfólio.
À medida que os s ucessos dessa abordagem vão se acumulando, nosso interesse em
realizar o gerenciamento de portfólio em toda as unidades de negócio vai a umentando.
Nosso foco futuro inclui maior ênfase na alocação de recursos, de acordo com as estratégias
da empresa, em oposição às estratégia s das unidades de negócios.
23
12.12 Chubb
A Chubb possu i uma estrutura federada de TI cotn um PMO divisional em cada u1na
das principais un idades de TI em nossa zona dos EUA, cotno, por exetnplo, Linhas
de Seguros Comerciais, Linhas de Seguros Pessoa is, Reclamaç.ã o de Sin istros, Segu-
ros Corporativos e Seguros de Infraestrutura. Temos tatnbém um PMO em nossas
zonas internacionais, incluindo Canadá, Europa, Ásia-Pacífico e América Latina. Utn
aumento nos serviços comparti lhados e nas metas de eficiência impulsionaram a ne-
cessidade de padrões e consistência em toda a empresa. Com e.ssa finalidade, os líde-
res dos PMOs divisionais trabalharam junto com o PMO empresarial (EPMO) para
desenvolver práticas ampla ,nente ligadas à nossa ferramenta de monitoramento dos
processos de projetos (PPM) e ciclo de vida de desenvolvimento de sistemas (CVDS)
padrão. Nosso impulso em direção à adoção de padrões exige recursos locais e aten-
ção da gerência que cotnpetem com prioridades de negócios e preferências locais, às
vezes exigindo negociação e equilíbrio. A seguir, temos nossas realizações e os desafios
que enfrentamos:
Clarity é nossa ferramenta de g estão de projetos e portfólios, e ela inclui:

• Cont role do Tempo para calcu lar o custo do projeto etn horas. Associamos ta-
refas a dez categorias padrão que podem ser d ivididas em discricionárias, não
discricionárias e operações e administração. O Gerente de Finanças de TI da
Chubb se encarregou desse conteúdo e está no processo de desenvolver alvos
para cada categoria de gastos. A precisão dos relatórios foi um desafio, no iní-
cio, mas continua a melhorar à medida que a gerência vai aumentando o uso
dos resu ltados do Controle do Tempo.
• Gerenciamento de Demandas para padronizar nosso processo de solicitação de
t rabalho. Isso é especialmente importante para uma organização que está am-
pliando seus serviços compartilhados, mas foi difíci l de implementar, dado que
cada unidade de negócio já possuía ferramentas locais adaptadas para se ade-
quarem aos processos de governança de negócios.
• Gerenciamento de Recursos, para melhorar o p lanejamento da capacidade. Isso
exige que "gerentes de recursos" verticais façam a alocaç.ã o do tempo dos fun-
cionários a projetos e atual izem as a locações semana lmente. Manter o nível
necessário de rigor na precisão é algo que está em desenvolvimento. Em últÍlna
análise, planejamos usar as alocações de recursos como a base para os planos de
custos dos projetos.
• Gerenciamento Financeiro, para calcular o custo rea l dos projetos multiplican-
do-se a remuneração dos t rabalhadores por função pelo número de horas tra-
balhado obtido por meio do Controle do Tempo. Adicionamos tambétn faturas
das empresas contr atadas, mas atualmente não incluímos os recursos de negó-
cios necessários no custo total.
• Gestão de projetos em 2014, para passar a integrar o Contr ole do Tempo aos
cronogramas de projetos. Isso el iminará o duplo registro feito pelo Controle do
Tempo e pelos cronogramas do MS Project, mas exige proficiência em esforços
llO material sobre a Chubb foi fornecido por Patrick Gerriry, vice-presidente do PMO Empresarial, em
nome dos funcionários da disciplina de P.MO da Chubb; reproduzido com permissão da Chubb.
baseados em geração de cronogramas, o que é uma habilidade que está em de-

senvolvimento para alguns de nossos gerentes de projetos.
• Gerenciamento de Portfólios em 2015, para passar a analisar projetos em todas
as unidades de negócios (BUs) com base em critérios selecionados (p.ex.: risco
versus retorno).
Project Path é nosso CVDS padrão

• Cada Disciplina (PMO, BA, arquitetura, desenvolvimento e garantia da qualida-
de) é encarregada de seus respectivos artefatos, mas o EPMO é responsável pela
consistência geral, integração e pelo repositório via nossa página da internet.
Cada artefato possui d iretrizes, templates e exemplos de apoio. Não foi difícil
que concordassem com a defin ição de melhores práticas nas diferentes BUs.
• O uso da Trajetória do Projeto é ad1ninistrado por u1na política corpoativa e seu
cumprimento é medido para projetos com mais de mil horas. Os GPs tên1 a flexi-
bil idade de decidir que atributos e1n um artefato são aplicáveis ao projeto. Arte-
fatos inteiros tan1bém poden1 ser excluídos co1n a aprovação do gerente do PMO.
• Nossa grande iniciativa de melhoria para 2013 é aprimorar nosso modelo de
estimação. Isso incluirá:
• Um nível 1na is baixo de detalhes no modelo existente (p.ex.: versões específi-
cas para certas tecnologias).
• Um cálcu lo-padrão da contingência baseado nos riscos identificados. Com
essa finalidade, um novo perfil de risco será imple1nentado para avaliar riscos
ma is abrangentemente.
• Uma descrição de como as estimativas interagem com nosso caso de negócio
existente, cronogra1na do projeto, controle de tempo e exigências de relatórios
de status.
Todas as pessoas que participam das equipes de projeto serão treinadas.
Uma função de garantia do GP no EPMO que:

• Realize verificações da "saúde" de nossos principais projetos(> 10 mil horas)
para garantir que riscos importantes sejam transparentes e que os GPs estejam
cumprindo com os padrões empresariais. Nos dois últimos anos o foco dessas
verificações de saúde passaram de cumpriinento de artefatos a r iscos materiais
que estivessem surgindo.
• Apresente relatórios de status para nossos principais projetos em um dashboard
mensal. É o EPMO que decide a cor do status (e não o gerente de projetos). Esse
relatório é revisado todo mês em uma reunião que inclu i o CIO 1nundial, os
CIOs divisionais, os líderes dos PMOs divisionais e os líderes do EPMO.
No longo prazo, gostaria de fazer uma rotatividade dos gerentes de programa que
real izam verificações de saúde com aqueles que estão gerenciando programas. Isso é
necessário para manter uma perspectiva renovada e desconstruir a noção de que os
"auditores" não são praticantes.
Uma out ra empresa que reconheceu a importância da gestão de projetos global é a
He,vlett-Packard. Segundo Sameh Boutros, PMP®e antigo diretor da prática de geren-
ciamento de programas e projetos na Hewlett-Packard:
Em gera l, as empresas globais acred itam q ue a necessidade da padronização da gestão de

projetos seja essencial para se prestar serviços de mais a lto valo r a custos co mpetitivos. Na
Hewlett-Packa rd, no grupo de negócios HP-EDS, existe uma rede de Práticas de Gerencia-
mento de Programas e Projetos (PPM, Program and Project Ma11ageme11t) nas regiões d as
Américas, Europa e Asia-Pacífico. A missão dessas práticas é:
Prestar Serviços de G P aos Clientes da HP por meio de Líderes de PMO de Conta e GPs
que liderem seus projetos de serviços em TI. A Prática de PPM a lcança seus objetivos quan-
do os GPs entregam seus projetos consistentemente dentro do prazo, dentro do o rçamento e
satisfazendo o cliente, usando melhores práticas d isciplinadas e maduras. A Prática de PPM
oferece suporte aos objetivos de negócio de uso eficiente de recursos, lucratividade, cresci-
mento e satisfação do cliente. Fornece ta mbém liderança na profissão para garantir que os
GPs estejam preparados para atender as necessidades do negócio e tenham a oportunidade
de desenvolver e crescer em suas carreiras.
O desenvolvimento da gestão de projetos envolve treinamento e certificação for-
mal a lém de desenvolvimento informa l. A gestão de projetos é uma habilidade e com-
petência centra l para a HP Services. O progra 1n a de desenvolvi mento de gestão de
projetos, vencedor de prêm ios é organizado por cursos cent rais de gestão de projeto,
tópicos avançados e1n gestão de projetos, cursos específicos para as práticas da H P
Services e trei namento em ha bi lidades profissionais. O utr as atividades que servem de
suporte ao desenvolvimento de gestão de pro jetos incluem:
• Dir igir programas de certificação em gestão de projetos
• Atual izar e gerenciar o cur rículo de t reina1n ento formal em coordenação co1n o
desenvolvi1n ento da força de trabalho
• Dirigir e pa rticipa r de eventos importantes como os congressos do PMI e eventos
regionais de networkingltreinamento em gestão de pro jetos
• Encorajar a comunicaç.ã o e a mentoria info nnal
• Oferecer mentoria aos gerente.s de projetos em ca mpo
O M étodo G loba l de Gerencia1n ento de Progra mas fornece aos gerentes de pro-
jetos 1n etodologias e uma a bordage1n padronizada que usa as melhores práticas da
indústria e incorpora o valor agregado da experiência da HP. Isso é exibido na Figu-
ra 12- 25.
Do ug Bolzman, arquiteto consultor, PMP®, especialista em !TIL® na HP, discute a
abordagem do PMO :
A ma io ria das organizações possui um PMO estabelecido, e isso foi gerado a pa rtir da visão
de que seus projetos individua is exigiam supervisão. Tra ta -se de um salto significativo para
muitas organizações que, há 15 a nos, não viam valor nos gerentes de projetos e hoje estão
fundando um PMO. No entanto, a maioria delas está pagando o preço de seleciona r funcio-
nários para o PMO, mas a inda não consegue enxergar seu valor - eles veem o PMO como
um mal necessário. Em o utras palavras, as coisas provavelmente poderiam ser piores se não
selecionássemos funcionários para o Plv!O.
As principais funções incluem supervisão do projeto, relatório de status e co nformidade
com o projeto. Como não havia estuturas de liberação claras, as empresas t inham a situação
em que s uas principa is organizações fornecedoras simlesmente "passavam a bola para o ou-
tro lado da cerca" para o fornecedor seguinte. O escritório de gerenciamento de programas
foi criado pa ra facilita r essas transações. Ver Figura 12- 26.
O problema com a implementação dessa abordagem é q ue nunca ho uve um único mo-
delo desenvolvido para esse tipo de estrut ura, e o PMO a dicionaria ainda ma is restrições,
burocracia ou cargas de trabalho. Esperava-se q ue o PMO pla nejasse a d ire.ç ão da empresa
por meio da implementação de projetos individua is.
Valor agregado da HP
Práticas
de negócios
Gestão
de projetos
Soluções
técnicas
Melhores práticas da indústria
Figura 12-25 Método global, metodologia de programa: abordagem padronizada usando as

melhores práticas da indústria com o valor agregado pela empresa.
/ '\. / '\.
Engenharia Instalação Operações
Escrttório de programas
Figura 12- 26 Usando o PMO para facilitação.
Em vez disso, um o utro modelo foi desenvolvido para fazer todos os fornecedores con-
tribuírem com cada etapa de uma liberação, compartilhando a responsabilidade de plane-
jamento e design, mas, ao mesmo tempo, fornecendo ao PMO o nível adequado de funcio-
nalidade. Ver Figura 12- 27.
Etapa de Etapa de Etapa de Etapa

planejamento Integração Instalação operaclonal
Escritório de proaramas Escritório de prooramas Escritório de proaramas
Escritório de Instalação Instalação
programas Operações
Instalação
Instalação
Operações
Operações Operações
Engenharia
Engenharia Engenharia
Engenharia
Figura 12- 27 Associando o PMO a funcionalidades.

24
12.14 Star Alliance
A Star Alliance é a primeira e ma ior a liança de empresas aéreas do mundo, englobando 27
empresas e no processo de integrar mais uma (EVA). As empresas membros atua is sempre
podem ser verificadas no site Staralliance.com. Ao todo, a rede da Star Alliance oferece mais
de 21.900 voos diários para 1.329 des tinos em 194 países. Seus membros transportaram
um total de 670,5 milhões de passageiros com um giro de US$181 bilhões em 2012. Cada
membro da Star Alliance poss ui um Plv!O.
• Adria Airways
• Aegean Airl ines
• Air Canada
• Air China
• Air New Zealand
• ANA
• Asiana Airlines
• Austrian
• Avianca, TACA Airlines
• Brussels Airl ines
• Copa Airlines
• Croatia Airlines
• EGYPTAlR
• Ethiopian Airl ines
• LOT Pol ish Airlines
• Lufthansa
• Scandinavian Airlines
• Shenzhen Airlines
• Singapore Airlines
• South African Airways
• SWISS
• TAM Airl ines
• TAP Portugal
• TH Al
• Turkish Airl ines
• United
• US Airways
O PMO da Star não age como um "superPMO" para os PlvlOs das empresas aére-
as membro. O PMO da Star All iance presta serv iços de gestão de projetos em toda a
empresa Star. Aqu ilo que o PMO real iza para as unidades de negócios inclu i assuntos
como tecnologia de informação, marketing, vendas, produtos, serviços e programas de
passageiro freq uente, além de projetos comuns de prospeção, que são os projetos que
usam o poder aqu isitivo combinado de todas as empresas aéreas e, conjuntamente, ad-
quirem mercadorias comuns (peças sobressa lentes, serviços a bordo, assentos da classe
econômica, etc.) .
Os projetos da Star All iance têm como objetivo fornecer uma experiência de viagem
comum em todas as empresas aéreas o u naquelas q ue aproveitam nosso tamanho para
desenvolver apl icativos de TI comuns, redes com uns, salas de espera comuns, serviços de
check-in, ou upgrades de passageiro frequente entre uma empresa e o utra. Os membros das
equ ipes de projetos são norma lmente especia listas em administração das empresas aéreas
membro de todo o mundo. Precisamos ser muito bons em conscientização cultural e criação
de consenso.
24
As informações sobre a Scar Alliance foram fornecidas por John Donohoe, P!vlP*, diretor do escritório de
gestão de projetos da Star Alliance Services GmbH.
En1 2011, in1plementaran1-se processos de gestão de projetos ágil para comple-

mentar o t radicional método em cascata para projetos selecionados. Faz-se uma
avaliação no início do p rojeto para detern1 inar que n1étodo de execução e entrega
seria mais eficiente de acordo con1 critérios defin idos. Alén1 d isso, o PMO da Star
Alliance PMO auxilia e coordena diversas empresas áreas men1bro em un1a Plata-
forma Comum de TI da Star Alliance. A Plataforn1a Con1um de TI da Star Alliance
é um progran1a estratégico, focalizado em esforço de melhor atender o cliente,
custos de TI marcadamente mais baixos e aun1ento significativo na velocidade de
colocação de novos produtos no mercado. Uma vez in1p lementado, permitirá que
as empresas aéreas n1embro participantes melhores seus serviços de atendin1ento ao
cl iente e ampl iem suas capacidades operacionais. A p lataforma baseia-se no port-
fólio pioneiro de nova geração de So luções de Gerencian1ento de Clientes (Custo-
mer Management Solution) da en1presa de soluções en1 TI An1adeus. Tal portfólio
consiste nas soluções Altéa Reservation, Altéa lnventory e Altéa Depa rture Contrai.
12.15 Auditorias de projetos e o PMO

Nos últimos anos, a necessidade de uma revisão independente estruturada de várias
partes de u1n negócio, incluindo projetos, assum iu um papel 1nais importante. Parte
d isso pode ser atribuída às exigências de cumprimento da Lei Sarbanes-Oxley. Essas
auditorias fazem parte da responsabilidade do PMO.
Essas revisões independentes são auditorias que se foca lizam na descoberta ou na
tomada de decisões. Elas ta 1nbém podem se foca lizar na determinação da "saúde" de
u1n projeto. As auditorias podem ser marcadas aleatoriamente, e podem ser realizadas
por pessoa l interno ou por examinadores externos.
Há vários tipos de auditorias. Alguns tipos comuns incluem:
• Auditorias de desempenho: são usadas para avaliar o progresso e desempen ho
de determinado projeto. O gerente de projetos, o patrocinador do projeto ou um
comitê executivo de orientação pode conduzi-las.
• Auditorias de observancia: são norma lmente conduzidas pelo PMO para va lidar
se o projeto está usando a metodologia de gestão de p rojetos adequada1nente.
Normalmente, o PMO tem a autoridade para rea lizar a auditoria, mas não tem a
autoridade para garantir a observância.
• Auditorias de qualidade: garantem que a qua lidade do projeto esteja sendo alc.an-
çada e que as leis e regulamentações esteja1n sendo seguidas. É o grupo de garantia
da qua lidade que as real izam.
• Auditorias de saída: são normalmente para projetos que estão passando por di-
ficuldades e que ta lvez precisem ser extintos. É um pessoal externo ao projeto,
como um executivo defensor de saída ou u1n comitê executivo de orientação, que
conduz as auditorias.
• Auditorias de melhores práticas: podem ser realizadas no fi 1n de cada fase de ciclo
de vida ou no final do projeto. Algu1nas empresas descobriram que os gerentes de
projetos podem não ser os melhores indivíduos pa ra realizar as auditorias. Nessas
situações, a empresa pode ter facilitadores profissionais treinados na condução de
revisões de mel hores práticas.
Listas de verificação e templates gera lmente são os melhores meios de se rea lizar
auditorias e verificações de "saúde" . Nani Sadowski-Alvarez, PMP®, consu ltora sê-
nior de gerencia tnento do CPHIMS, Gerenciamento e Arquitetura Empresa rial de Pro-
gramas na Computer Sciences Corporation (CSC), compartilha conosco um te,nplate
para a aud itoria de um pro jeto (ver Tabela 12- 1).
TABELA 12-1 Temp/ale para a auditoria de projetos

Patrocinador do p rojeto: Gerente do proj eto:
Data em que o projeto Data da aud itoria final
entrou em operação: do projeto :
Validação Documento/ltem a ser validado Classificação Comentários
Sim Não Aprovações do Conselho (i.e., minutas da reunião, as- o
o o sinatura, etc., indicando que o projeto foi aprovado e foi
assinado para execução e implementação)
Sim Não Escopo do projeto assinado (com assinaturas originais o
o o e/ou com assinaturas eletrônicas/enviadas via fax em
anexo)
Sim Não Apresentação e pauta da reunião de apresentação inicial o
o o do projeto (incluindo data da inauguração)
Sim Não Folha de custos das despesas de capital e despesas o
o o operacionais do projeto oorrente/atualizada
Sim Não Todas as solicitações de mudança especificas do projeto o
o o (oom detalhes relativos à tripla restrição: cronograma/orça-
mento/recursos), oom todas as assinaturas de aprovação
das solicitações de mudança oorrespondentes em anexo
Sim Não Aceitação do projeto assinada (pelo patrocinador do pro- o
o o jeto) - carta de encerramento e rotatividade operacional
Sim Não Apresentação do encerramento do projeto juntamento o
o o oom pauta e data da reunião de encerramento
Sim Não Contratos oom Jornecedores e declarações de trabalho o
o o (DT) assinadas (por todas as partes afetadas - i.e.: for-
neoedor, patrocinadores, departamento jurídico, etc.)
Sim Não Lista de verificação de encerramento do projeto oon- o
o o clulda no encerramento do projeto
Iniciação
Sim Não Termo de abertura escore do projeto o
o o
Sim Não Orçamento do projeto aprovado finalizado o
o o
Sim Não Fluxos de trabalho da fase inicial (quando aplicável) cria- o
o o do para demonstrar a necessidade do projeto, a raciona-
lização dos esforços de trabalho, etc. NOTA: Se o projeto
for estritamente relativo a hardware (HW)/equipamentos,
o diagrama fornecido pode ser de equipamentos ou
netware (NW)
(continua)
TABELA 12-1 Template para a auditoria de projetos (continuação)
Validação Documento/Item a ser validado Classificação Comentários

Planejamento
Sim Não Contratos assinados do fornecedor juntamente com a DT o
D D
Sim Não Cronograma do projeto que foi criado e mantido via Cla- o
D D rity e Work Bench. (NOTA: Uma cópia assinada inicial
deve ser incluída como anexo ao escopo do projeto. O
GP mostrará o cronograma atual ao auditor via Clarity/
Wor Bench mediante solicitação)
Sim Não Escopo do projeto assinado - documento completo, o
D D incluindo gráfico organizacional do projeto, plano de
comunicação, marcos de alto n!vel, avaliações técnicas/
empresariais/clinicas, além dos materiais financeiros do
projeto (quando dados financeiros detalhados são incor-
porados à execução dos projetos), etc.
Sim Não Avaliação técnica e diagramas relacionados o
D D
Sim Não Avaliação do aprovisionamento (quando aplicável), in- o
D D cluindo estimativas de custo, equipamentos previstos, etc.
Sim Não Avaliação de segurança como estabelecido pelo princi- o
D D pai executivo de segurança ds informações financeiras
(FISO, financial information security officer)
Sim Não Orçamento do projeto aprovado finalizado o
D D
Validação Documento/Item a ser validado Classificação Comentários
Execução/Controle
Sim Não Fazer o design/Construir - qualquer documentação apli- o
D D cável relativa ao design/construção
Sim Não Riscos e problemas - o GP deve documentar problemas o
D D e riscos utilizando a aba de problemas/riscos/solicitação
de mudanças no Clarity· e carregar os documentos rela-
cionados ao risco ou problema específico
Sim Não Solicitação de mudanças e documentos associados - o o
D D GP deve documentar as solicitações de mudança de
seus projetos utilizando a aba de problemas/riscos/
solicitação de mudanças no Clarity. As solicitações de
mudança também serão carregadas no SharePoint.. na
pasta aplicável ao projeto
Sim Não Fluxogramas e procedimentos revisados e aprimorados o
D D
Sim Não Testes - toda a documentação do projeto relativa a testes o
D D (scripts, planos, etc.)
Sim Não Treinamento - toda a documentação do projeto relativa o
D D a treinamentos (plano, cronograma, informações sobre
cursos, etc.)
Sim Não Medidas e formulários apropriados em tomo do apro- o
o o visionamento (incluindo qualquer processo necessário
para obter assinaturas para acesso de segurança)
• N. de T.: Clarity é uma ferramenta de gestão de projetos.
•• N. de T.: Sharepoint é uma ferramenta de gestão e compartilhamento de documentos e projetos.
(continua)
TABELA 12-1 Temp/ale para a auditoria de projetos (continuação)

Sim Não Detalhes do pedido de compra (solicitações, estimativas o
o o de custos, etc.)
Sim Não Todas as faturas (estas também serão acompanhadas o
o o via Ctarity com a revisão e orientação do contador in-
terno)
Sim Não Avaliação de segurança pré-início das operações realiza- o
o o das pelo FISO
Sim Não Fluxos de processo pré-início das operações (quando o
o o aplicável) detalhando o estado atual e o estado previsto
após a implementação do projeto; se o projeto envolver
equipamentos
Sim Não Avaliação geral com contador interno o
o o
Sim Não Plano de ativação/Entrada em operação, incluindo o
o o todos os detalhes necessários para que a equipe cen-
trai e outras partes afetadas alcancem uma ativação
bem-sucedida e eficiente do projeto
Encerramento
Sim Não Orçamento do projeto - detalhes do orçamento aprovado o
o o versus fechamento final real
Sim Não Lições aprendidas - compiladas pelo GP e toda a equipe o
o o central do projeto
Sim Não Documentação da rotatividade operacional o
o o
Sim Não Carta de aceitação do projeto (encerramento) com a as- o
o o sinatura do patrocinador

Pautas/Minutas
Sim Não Todas as pautas relativas aos projetos (salvas com o
o o formato de data no título para garantir facilidade de uso
para referência)
Sim Não Todas as notas de reunião (salvas com formato de data o
o o no título para garantirfacilidade de uso para referência)

Apresentações
Sim Não Apresentação inicial em PowerPoint o
o o
Sim Não Apresentações/Demonstrações relacionadas a o
o o patrocinadores
Sim Não Apresentações internas utilizadas para a aprovação de o
o o projetos (se aplicável)
Sim Não Apresentação de encerramento do projeto em o
o o PowerPoint
12.16 Verificações da "saúde" dos projetos

M uito frequentemente, os projetos passa1n por verificações de "sa úde" , mas estas são
realizadas pelas pessoas erradas. O cone.eito de rea lizar uma verificação de "sa úde" é
u1na prática sólida, contanto que as pessoas certas estejam realizando a verificação e as
informações certas esteja m sendo discutidas. A finalidade deve ser fazer críticas cons-
t rutivas e ava liar abordagens a lternativas, quando necessário . Muito frequentemente,
po rém, as reuniões acabam sendo um ata que pessoal à equipe de projetos. Revisões
no nível executivo e revisões simila res realizadas pelo PMO podetn não fornecer ao
gerente de projetos as info nnações const rutivas que ele deseja. Er ic M aurice, da NXP,
e Mark Gray, ex-NXP e hoje CEO da Sigma PM, identificaram uma forma inovadora
de fazer isso. Eles cha 1na ram essa a bordagem de: Se duas cabeças pensam melhor do
que tttna, por que nao - ttsar tres
' ou q11atro.?25
Em nosso impulso para aumenta r a proba bilidade de s ucesso para os projetos, um mecanis-
mo que muitas vezes é utilizado é as revisões por pares, nas quais outros especialistas fazem
uma análise crítica de nosso projeto e oferecem uma avaliação e conselhos. O principal pro-
blema co m essa abordagem é o fato de ela geralmente ser uma revisão muito breve feita em
uma única o portunidade d a documentação d a gestão de projetos co m pouca ou nenhuma
avaliação dos verdadeiros mecanismos do projeto.
Eric Ma urice, gerente de projetos na área de P&D da NXP Semiconductors criou uma
nova maneira de tirar verdadeiro proveito dessa a bordagem - o gerente de projetos de mul-
ticerebrado! (O q ue às vezes é cha mado de gerente de projetos Hidra.)
Impulsionados pelas descobertas de um exercício na classificação tipo lógica de Myers
Briggs (MBTI, Myers Briggs Type lndicator) feito no nível da equipe, Eric percebeu que há
um perigo significativo de se to rnar tendencioso dema is em direção a uma perspectiva do
projeto com a possibilidade de negligencia r o que poderiam ser problemas óbvios. Isso é
exacerbado pelo nível de co mplexidade d os projetos e pelo número de (às vezes conflita n-
tes) d ados q ue o gerente de projetos precisa considerar no início d o projeto .
Eric, então, abordou vários colegas d a gestão de projetos (de toda a organização) por
meio da rede local e então lhes pediu para se torna r pa rte de uma rede neural - compa r-
tilhando ideias, co nceitos e pontos de vista no contexto desse projeto especificamente. O
moti vo pa ra usar essa abordagem e m vez de uma simples revisão de pares era s uperar a
restrição de ter apenas uma única oportunidade de análise, e mostrar, ao mesmo tempo, a
o portunidade de va lor agregado.
Obviamente, fazê-lo exigia alguma preparação e condições iniciais:
• Dado q ue os colegas tinham experiência em projetos extremamente d iferentes, grande
parte da preparação tinha de ser dedicada a explicar o contexto do projeto para o grupo.
• Regras básicas de confianç.a mútua, abertura, honestidade e críticas construtivas eram
necessá rias (embora não forma lmente declaradas). Isso foi especia lmente útil para iden-
tificar possíveis pontos fracos no plano de risco, e para ajudar a enfrentar a verdade (às
vezes cruel).
• Superar suas ba rreiras para mostrar pontos fracos nunca é fácil - isso novamente de-
pende de um bo m nível de confiança e cooperação no grupo.
• A frequência precisa ser razoavelmente regular - nesse caso, era uma vez por mês (em
um projeto de 20 meses). Isso, co m o intuito de garant ir que a visão compartilh ada seja
mantida a tua lizada.
Dessa experiência, temos as seguintes observações e resultados:
• Um resultado tangível foi uma redução no nível de risco do projeto - uma revisão do
plano de risco ajudou a garantir o conteúdo e o pla nejamento de respostas.
?JO material desta seção foi fomecido po r .Mark Gray, amigo gerente de projeros sénior na NX P Semicon·
ducmrs e hoje CEO da SigmaPJvl, e Eric Maurice, PJvlP• . gerente de projetos da NXP Semiconducrors.
• Fortes laços foram estabelecidos entre os gerentes de projetos q ue, na verdade, conti-
nuaram em operação fora do contexto desse projeto. Isso ta mbém aj udou a reforçar o
valor do net,vork.ing na organização.
• O (eedback dos participantes ta mbém foi positivo: eles a preciaram a oportunidade de
compartilhar e aprender uns com os outros.
• Um elemento que foi visto como tendo contribuído para o sucesso foi a decisão de foca-
lizar precisamente em uma área específica para ca da sessão (planejamento, risco, etc.).
Essa determinação de um "tema" permitiu que os colegas aplicassem seus conhecimen-
tos (ou aprendessem com os outros) em uma á rea de foco específica no contexto de um
projeto real e compreendido.
• O grupo pequeno, mas dinâmico (ent re três e seis pessoas foi considerado o ta ma nho
ideal), também serviu como uma verdadeira incubadora para novas ideias, a lém de
como um excelente cana l para que as lições aprend idas fossem transmitidas entre dife-
rentes projetos e por toda a organização.
Concluindo, podemos certamente dizer que o uso da abordagem do gerente de projetos
"multicerebrado" possui um cla ro valor agregado em a lca nçar a excelência na execução de
projetos, muito mais do q ue revisões forma is de projeto o u do que as rev isões de pa res q ue
analisam um " instantâneo" do projeto. Não é apenas o projeto que sai ganhando com isso,
mas também seus participantes e a o rganização como um todo!
Algumas recomendações - e um "alerta de saúde"!

Já que o processo de estabelecer e dirigir as sessões "hidra" exige um investimento em tempo
que é acima do trivial, deve-se considera r quando isso seria apropriado. Temos a lgumas su-
gestões a respeito de quando esta seria uma abordagem a propriada (e de quando não seria):
• Esse processo teria um bo m reto rno sobre investimento, seja quando o projeto tem um
nÍ\•el muito a lto de risco percebido, o u quando se deseja usá-lo como uma oportunidade
para mento ria (ou o gerente de projetos é novo no emprego o u seus colegas têm a opor-
tunidade de aprender com um "adepto").
• Não recomendaríamos usar essa abordagem em projetos de muito curto prazo (alguns
meses de d uração), já que ela reduz a possibilidade de ganhar tração, ou em p rojetos
com um baixo nível de importância estratégica, já q ue isso reduz o nível de interesse
d os colegas.
• Não é uma boa ideia ter gerentes de projetos envolvidos em diversas "sessões hidra" -
não somente do ponto de vista do tem po necessário, mas também porq ue isso diluiria
demais o foco.
• Colocar uma abordagem de " hidra" em andamento em um projeto deve ser decisão q ue
vem dos p róprios gerentes de projetos; forçá-los a fazê-lo transforma a abordagem em
um castigo ou, o que é pior, indicar uma falta de con fiança no gerente de projetos.
Alguns diria m que esse deve ser o domínio do PMO (qua ndo este existe), mas aqui,
gostaríamos de fazer um "a lerta de saúde": o Plv!O deve, é claro, ser a(s) pessoa(s) que
ajuda(m) a estabelecê-lo e a captar os resultados - mas o verdadeiro valor vem de ter seus
colegas rea lmente envolvidos no projeto que está sob escrutínio . Na opinião do a utor, se a
"hidra" se to mar o dom ínio do PMO, ela correrá o risco de se tornar o monstro da lenda
grega ...
Essa abordagem não p retende se torna r apenas ma is uma ferramenta de "monitora-
mento e controle" - o verdadeiro benefício é a arendizagem compartilhada e as múltiplas
perspectivas sobre o funcionamento cotidia no do projeto.
12.17 Prêmio PMO do Ano

Algumas pessoas d iscutem que a mudança ma is significativa em gestão de p rojetos
na primeira década do século XX I foi a imple1n entação do conceito do PMO. Sendo
assim, não é nenhuma surpresa que o Cent ro de Práticas de Negócios (Center for
26
Business Practices) tenha lançado o prêmio "PMO do Ano" .
Critérios de premiação
O prêmio PMO do Ano é oferecido ao PMO que mel hor ilustra - por meio de un1
ensaio e outros documento - as estratégias de melhoria, n1elhores práticas e lições
aprendidas de sua gestão de projetos. Outros documentos de apoio - con10 gráficos,
tabelas, planilhas, folhetos, etc. - não poden1 exceder cinco unidades. Embo ra se
encoraje o envio de documentação adicional, cada PMO qualificado den1onstrou
claran1ente suas n1elhores práticas e lições aprendidas no ensaio do p rêmio . Os
juízes analisaram os ensaios para considerar como o PMO do candidato associou a
gestão de projetos às estratégias de negócios de sua organização e que papel desem-
penhou no desenvolvin1ento de un1a cultura organizacional de gestão de projetos.
Os ensaios foran1 aval iados quanto à sua validade, mérito, precisão e consistência,
alén1 da contribu ição do PMO candidato ao sucesso do projeto e da organ ização
con10 un1 todo .
Os tipos de melhores práticas que os juízes procuram incluem:
• Práticas para integrar as estr atégias do PMO a fim de gerenciar projetos de forma
bem-sucedida
• Melhorias nos processos, metodologias ou práticas de gestão de p rojetos, levando
a uma execução mais eficiente e/ou eficaz dos projetos da organização
• Abordagens inovadoras da mel horia da capacidade da gestão de projetos da or-
-
gan1.zaçao
• Práticas que sejam distintivas, inovadoras ou originais na aplicação da gestão de
proJetos
• Práticas que pron1ovan1 o uso de padrões de gestão de projetos em toda a em-
presa
• Práticas que encorajem o uso de resultados de mensuração de desempenho para
auxilia r a tomada de decisões
• Práticas que aumentetn a capacidade dos gerentes de projetos
Os resultados de melhores práticas incluem:
• Evidências de benefícios de negócios real izados - satisfação do cl iente, produti-
vidade, desetnpenho orça1nenta l, desempenho do cronograma, qua lidade, ROi,
satisfação dos funcionários, desempenho do portfólio, al inhamento estratégico
• Uso eficiente de recursos
• Maior maturidade o rganizaciona l em gestão de projetos
• Compromisso executivo com uma cultura de gestão de projetos expressa em po-
líticas e out ros docu1nentos
• Um PMO que exibe u1n foco sobre os resultados de negócios da organização
• Uso eficiente do conhecimento sobre gestão de projetos e de suas lições aprendidas
• Objetivos de desempenho individuais e possíveis recotnpensas ligadas à mensura-
ção do sucesso do projeto
26
O material desta seção foi fornecido pelo Cenrer for Business Practices, Rockwell Auromarion e pela
Akarel~Lucenr. Para informações mais detalhadas sobre o Cemer for Business Praccices e o Prêmio de PN10
do Ano, visite seu site: www.cbponline.com.
• Funções de gestão de pro jetos aplicadas consistentemente em toda a organização

O ensa io compreende três sessões. Qualquer material enviado incompleto foi des-
qualificado.
Concluindo o ensaio
Seção 1: Qua l é o histórico do PMO? Em não 1nais do que mil palavras, os candidatos
descreveram seus PMOs, incluindo informações passadas sobre sua visão e 1nissão,
escopo e estrutu ra organizaciona l. Além disso, descreveram:
• Há quanto tempo o PMO estava e1n funcionamento
• Seu papel no PMO
• Como a operação do PMO é financiada
• Como o PMO é estruturado (pessoa l, papéis e responsabil idades, se envolve toda
a e1npresa ou se é departamental, etc.)
• Con10 o PMO usa padrões de gestão de projetos para oti1nizar suas práticas
Seção 2: Quais são as inovações e melhores práticas do PMO? Em não mais do
que 1.500 palavras, os candidatos abordaram os desafios encontrados por sua orga-
nização antes da implementação das novas práticas do PMO e como eles superara1n
esses desafios. Eles descreveram clara e concisamente as práticas implementadas e seu
efeito sobre o sucesso do projeto e da organização como um todo.
Seção 3: Qual o i1npacto do PMO e seus p lanos para o futuro? Em não mais do
que 500 palavras, os cand idatos descreveram o impacto do PMO ao longo de de-
terminado período (p.ex.: satisfação do c.liente, produtividade, redução do tempo de
ciclo, crescimento, construç.ã o ou a lteração da cultu ra organizacional, etc.). Quando
possível, os candidatos forneceram dados quantitativos para ilustrar as áreas em que o
PMO teve 1na ior impacto sobre os negócios. Finalmente, descrevera 1n resumidamente
os planos de seu PMO para 2009 e como esses planos têm potencial para afetar sua
-
organ1zaçao.
Duas das empresas discutidas neste livro cotnpetiram pelo prêm io: a Rockwell
Automation, que venceu o prêmio de PMO do Ano de 2009, e a Alcatel-Lucent, que
foi reconhecida como uma das finalistas do prêmio. A1nbos os seus perfis são discuti-
dos a seguir.
Rockwell Automation: vencedora do PMO do Ano de 2009

Escritório de gerenciamento de programas de software
Tipo de organização: manufatura
Sede: Mihvaukee, Wisconsin, EUA
Número de funcionários em regime de tempo integral (FTis): 21 mi l +
FTis no PMO: 30
orçamento operacional anual do PMO: US$3,2 1nilhões
James C. Brown, antigo diretor, escritório de gerenciamento de programas A&S
Desafio enfrentado: Lançar uma prática consistente de produtos e de gestão de proje-
tos e1n 16 negócios
Benefícios de negócios: Ma ior previsibilidade e produtividade; ritmo ma is acelera-
do de inovação; execução de uma liberação maior, compreendendo 20+ projetos,
dentro do prazo e do orçamento pela pri1neira vez na história da e1npresa
Site: http://w,vv1.rock,vellautomation.com/
Rockwell Automation : de "tábula rasa" a inovadora global

em menos de cinco anos
A Rockwell Auton1ation foi formada por meio da fusão de duas grandes empresas
de automação, Allen-Bradley e Reliance Electric, no final da década de 1980. Ao
longo dos anos, a Rock,vell Auton1ation continuou adquirindo outros fornecedores
líderes do ramo de auton1ação como estr atégia de crescimento e também como un1a
maneira de t razer novas tecnologias de automação avançadas para a empresa. En1
2005, quando a Rockwell Automation estava p lanejando o lançan1ento de um novo
sistema de negócios SAP, a empresa reconheceu a necessidade de um novo processo
de de.senvolvin1ento de produto comum (CPD, comrnon develop·, nent p-rogram), que
seria baseado nas n1elhores práticas da en1presa, juntamente com as melhores p rá-
ticas da indústria en1 tern1os de desenvolvimento de p rodutos. Esse esforço resu ltou
en1 um processo de CPD que permitia a adoção em toda a en1p re.sa. Todos os 16
d iferentes negócios de p rodutos, de fornecedores de componentes de alto volume a
fornecedores de soluções de complexos sistemas de controle de processos contínuos
agora usam a mesma estrutura de processos de alto nível para o desenvolvimento de
seus novos produtos.
Como os gerentes de projetos são essenciais na execução de um processo de de-
senvolvimento de produtos, percebeu-se rapidamente que introduzir um processo end-
·to-end em uma empresa formada por 1nuitos negócios de produtos relacionados, mas
muito diferentes, exigiria a aplicação consistente da gestão de projetos em todas as
linhas de produtos. Para complicar a inda mais a situação, cada segmento de negócios
estava em um nível de maturidade diferente em relação a todos os aspectos do desen-
volvimento de produtos. Uma organização formal de gestão de projetos, estabelecida
em 2004, já existia e fo i aproveitada para apoiar esse esforço. O diretor do PMO,
James C. Bro,vn, diz: "Se consistência, transparência e mitigação de r iscos são impor-
tantes para seu negócio, como são para nós, acredita 1nos que uma entidade de gestão
formal de projetos, bem reconhecida e bem administrada é essencial".
Bro,vn, contratado e1n 2004 para ajudar a i1nplementar o PMO, chamou o am-
biente de gestão de p rojetos de " rábula rasa", sem contar aquelas pessoas que já eram
identificadas como gerentes de projetos. O PMO é estruturado por função com geren-
tes de programas supervisionando programas e gerentes de projetos supervisionando
projetos, auxiliados por outras duas ferra1nentas de suporte como o MSProject Server
e o Sha repoint.
O novo PMO da Rockwell se desenvolveu rapidamente, fazendo todos os seus
participantes tirarem a certificação de PMP®em menos de dois meses, o que chamou
a atenção do VP sênior da divisão. Então, começaram a estabelecer processos e meto-
dologias, criando sco-recards e mét ricas, e implementando ferramentas para o suporte
do desenvolvimento de novos produtos e serviços. Eles passa ra1n de uma abordagem
e1n cascata na direção de seus projetos para uma abordagem ágil, tr ansformando pro-
cessos de ma is de 20 páginas em menos de cinco páginas e passando-os de fichá rios
de papel para 1nídias eletrônicas. Como Brov,rn diz, "Deixamos de incluir tudo nos
relatórios, passando a incluir somente as exceções".
O PMO cresceu de 10 pa ra 30 pessoas em pouco mais de quatro anos, e seu alcan-
ce passou de norte-americano a global. O número de projetos sob sua direção aumen-
tou de 12- 15 para 50 projetos concomitantes. No caminho, a Rock,vell Automation
implementou um processo de gerenciamento de portfólio em seu Grupo de Ar quitetu-
ra e Software. As metas e a finalidade do processo são liga r investi1nentos a estr atégias
de negócios, maxim izar o valor do portfól io, alcançar um desejado equilíbrio (mix) de
projetos e dar um foco aos esforços da organização. O processo de gerenciamento de
portfólio se associa a p rocessos relacionados, como o gerenciamento de ideias, desen-

volvimento de estratégias, gestão de projetos e programas e o recém-desenvolvido pro-
cesso de CPD, e se tornou parte integral do processo de pla nejamento. Bro,vn foca liza-
-se no lado hum ano dos benefícios do gerenciamento de portfólios de projetos (PPM,
project portfolio ,nanagement): "Trata-se de pessoas chega rem a um consenso usando
dados confiáveis, e uma est rutur a comum de tomada de decisões" .
É claro, é difícil muda r a cultura da emp resa, então a governança é crucial; e isso
exige compromisso por parte da gerência. A força motriz por trás do compromisso por
parte da gerência para imp lementar esse novo processo era a visão de uma metodolo -
gia co1nu1n para o desenvolvimento de novos produtos que fosse consistente e1n toda a
empresa. Essa consistência foi priorizada de ci ma (envolvimento direto da gerência nas
revisões de pontos de decisão de fina l de fase) para ba ixo, a fi m de realiza r benefícios
o mais rápido possível.
Muito frequentemente, os negócios eram fo rçados a nega r fi na nciamento pa ra
projetos estr atégicos devido a intermináveis mel horias de produtos que não pa rava1n
de chega r. Ao forçar a gerência ad1ninist rativa a aprovar a passagem de cada projeto
de uma fase pa ra a seguinte, os novos processos empurravam a visi bili dade de cada
projeto, cada recurso e cada dólar gasto para os tomado res de decisões de ca rgos su-
periores, que lutavam para tentar encontra r dinhei ro para financiar os projetos que
reahnente "virariam o jogo".
Essa visibi lidade ta1nbém faci litou para os proprietários de negócios ca ncelare1n
projetos com retornos questionáveis ou atrasarem um projeto para a liberação de
recursos cruciais. Isso cont rastava com a antiga manei ra de executar um projeto, co1n
revisões informais e apressadas. As equipes pod iam continuar gastando e até mes-
mo desperdiçando sem nenh um te1nor real de cancela1nento . Sob o novo processo,
cada organização dependente é representada na revisão apropriada e tem a chance de
concorda r ou discordar com o gerente de projetos de que todos os deliverables estão
disponíveis. A intenção é ter decisões de continua r/não continuar tomada tanto pela
principal organização responsável pelos deliverables dura nte a fase anterior qua nto
pela pr incipal organização responsável pelos deliverables na fase subsequente. Am bas
essas organizações são necessá rias em cada revisão de passagem de fase. Dessa manei-
ra, ga rantindo a tr anspa rência dura nte as fases iniciais, o processo ajuda a Rockwell
Automation a evitar sur presas durante as fases posteriores.
Tudo isso foi implementado de uma forma leve, que facilitou a aceitaç.ã o dos no-
vos processos. Co1no Bro,vn observa: " Há uma diferença muito sutil entre rigor e
ônus, e o segredo é garantir uma imp lementação rigorosa sem frear o p rogresso da
equipe de projetos".
O PMO foi essencial na busca da Rockwell Automation por maior previsibi lidade,
prod utividade e visibilidade. Ao entregar - pela primei ra vez na história da empresa -
uma grande liberação com mais de q uatro programas e 1na is de 20 pro jetos dentro do
prazo e do orça1nento, a orga nização p rovou seu valor de negócio.
Alcatel-Lucent: finalista do PMO do Ano de 2009

Escritório global de gerencia1nento de progra mas
Tipo de O rganização: telecomunicações
Sede: Paris, Fra nça
Número de funcionários em regi me de tempo integral (FTls): 70 mi l
FTls no PMO: 10
O rçamento operacional a nual do PMO : US$4,5 milhões
Gerente sênior do PMO: Rich Maltzman, PMP®, gerente sênior de aprendizage1n e

desenvolvimento profissional
Desafio enfrentado: Combina r os esforços de melhorias em gestão de projetos de duas
empresas em uma 1n1c1at1va
Benefícios de negócios: Melhorias em uma ampla gama de métricas de projetos em
projetos que afetam positivamente a satisfação do cl iente
Site: htt p:ww,v.alcatel-lucent.com
O Escritório Globa l de Gerenciamento de Progran1as (GPMO ) da Alcatel-Lucent
con1b ina as melhores práticas em gestão de projetos da Alcatel e da Lucent, duas
en1presas que já estavan1 em meio a grandes esforços para revitalizar a gestão de
projetos enquanto disciplina na época en1 que a Lucent se fundiu con1 a Alcatel en1
noven1bro de 2006. Ambas as organizações já tinhan1 pesquisado melhores práticas
en1 gestão de projetos, e a disciplina fo i priorizada pela nova liderança da empresa.
Uma equipe central foi designada para combinar os esforços de gestão de projetos em
uma única iniciativa no fina l de 2006. O foco in icial do GPMO em toda a empresa foi
nos n1ais de 2 1nil gerentes de projetos que lidavam con1 clientes e supervisionavam
o giro de novas soluções para os clientes. O GPMO focalizou-se em duas principa is
"estruturas" - un1a de execução de projetos e uma de desenvolvimento de gerentes
de projetos.
A estrutura de execução de projetos, dedicada às metodologias e ferramentas que
os gerentes de projetos usam em toda a empresa, traz u1n novo nível de maturidade
em gestão de projetos ao oferecer consistência na prática em todas as unidades de
negócios e regiões geográficas. E,n seu cerne encontra-se uma metodologia baseada
em pontos de decisão de passagem de fases chamada de processo de implementação
de contrato (CIP, contract imp/e,nentation process). O CIP aponta para uma coleção
de ferramentas que podem ser usadas como for apropriado pelos gerentes de projetos
que lidam com clientes ou na base de região por região ou unidade por unidade. Cada
metodologia CIP é associável a um processo do Guia PJ\1BOI<®. A empresa agora
está em vias de integrar o CIP a um grande siste1na de software de gestão de projetos
e1npresarial para sua população.
A estrutura de desenvolvimento de gerentes de projetos é um modelo integrado
em nove pa rtes que reconhece a interconexão entre importantes elementos do desen-
volvimento do gerente de projetos co1no um modelo de competências, um plano de
carreira, t reinamento dos gerentes de projetos, certificação pela indústria, acreditação
e reconhecimento interno, e gerenciamento das habilidades dos gerentes de projetos.
O GPMO estabeleceu metas rígidas para a certificação de PMPs®para seus gerentes de
projetos nos dois próximos anos. A Alcatel-Lucent foi citada na revista anual do PMI
Leadership in Project lvfanagement por trabalhos nessa área. A profundidade do com-
promisso da empresa em oferecer u1n am biente de suporte para os gerentes de projetos
é ilust rada por inúmeros programas, dentre eles:
• Acreditação Profissional em Gestão de Projetos. A Akatel-Lucent possui seu pró-
prio programa de acreditação, acima e além da certificação de PMP®, a Acred ita-
ção Geral de Gerente de Projetos, que honra a excelência em uma imple1nentação
no mundo real de projetos de clientes externos. Exige a conclusão de um extenso
conjunto de materiais avançados sobre gestão de projetos baseado em casos e
está sujeita a critérios ext remamente rígidos, inclusive um conselho de júri formal.
Essa certificaç.ã o ajuda a garantir que os gerentes de projetos tenham não somente
o conhecimento geral sobre gestão de projetos necessário para seu t rabalho, mas
também a experiência específica e1n projetos reais no campo das telecomunicações
para auxiliar os cl ientes. Iniciando cotn a popu lação de gerentes de projetos (2 mil
pessoas), a acreditação profissional foi tão bem-suced ida que hoje está sendo lan-
çada para todos os contribuidores na organ ização de serviços - aproxitnadamente
18 mi l pessoas.
• Modelo de Competências. O cerne da estrutura do desenvolvimento de gerentes de
projetos é um 1nodelo de competências que reúne o melhor da herança da Alcatel
e da Lucent. Este é um modelo "vivo", atualizado todo ano para acompanhar o
r itmo das 1nudanças na disciplina de gestão de projetos, além do rápido rit mo do
negócio de telecomun icações.
Alcatel-Lucent: as melhores práticas de duas empresas

de telecomunicações unem suas forças na gestão
de projetos
• Sistema de Gerencia,nento de Recursos e Habilidades (RSMS, Reso11rce and Skills
Manage,nent Systetn). O RSMS facilita a habil idade dos gerentes de projetos de
monitorar seu próprio progresso em desenvolvimento, usando seu perfil de cargo
como uma base para identificar lacunas nas ha bilidades e sugerir opções de desen-
volvi1nento para preencher essas lacunas.
• Alcatel-Lucent University. Como un1 Centro Registrado de Treinamento (REP, Re-
gistered Ed11cation Provider) do PMI, a Alcatel-Lucent University fornece acesso
a u1na an1pla gama de treinatnentos baseados na internet e liderados por un1 ins-
trutor, alguns dos quais extrema tnente personal izados e baseados em casos, para
permitir que os gerentes de projetos aprendan1 con1 projetos bem-sucedidos rea is.
• Grupos de estudo para PA1P®. O GPMO, por 1neio do t rabalho da equipe PM-
-CERT (ver Capítulo 8), reun iu grupos de estudo para PMP®, 8- 12 indivíduos que
somam seus esforços estudando para o exame de PMP®. Um inst rutor de PMP®
orienta o grupo, que se encont ra com a frequência que desejarem via teleconferên-
cia, e conclui o estudo usando utn livro recomendado e um conjunto de exercícios.
O programa também beneficia o inst rutor, gerando val iosas unidades de desen-
volvi1nento profissiona l (PDUs), uma vez que regist ramos esse programa junto ao
PMJ como parte da Alcatel-Lucent University.
• Simpósio do Dia Internacional da Gestão de Projetos. O segundo (lntemational
Project Managetnent Day SymposÍlun) contou com apresentações de sete países
sobre tópicos de gestão de projetos, cotn pa lestrantes cotno o Dr. Harold Kerzner.
Esse programa se encontr a hoje em sua sétima ed ição. Em torno de mi l gerentes
de projetos participam anua lmente do simpósio, que recebe consistentemente u1na
excelente ava liaç.ã o.
Integração: uma melhor prática por si só

Segundo Rich Maltzman, PMP®, líder de aprendizagem e desenvolvimento profissio-
nal - um papel que se focaliza no lado humano da gestão de projetos, inclu indo planos
de carreira, t reinamento, programas internos de reconhecimento e gerenciamento de
habilidades, "Sentitnos que a natureza integrada da Estrutura de Desenvolvimento dos
GPs é uma 1nelhor prática. Ela força a interação ent re ele1nentos de suporte de u1na
carreira bem-sucedida em gestão de projetos, e, por sua vez, uma disciplina de GP que
é a melhor para apoiar projetos dos clientes e, assi tn, aumentar a posição financeira
da empresa".
Além disso, algumas das principais ferramentas de melhores práticas incluem:

• Estrutura de execução de projetos. O CIP, o cerne da estrutura de execução, é o
processo padron izado para gerenciar o ciclo de vida do projeto na empresa e está
focalizado nas passagens de fase desse ciclo de vida do projeto. Reconhecendo que
são as pessoas que fazem os projetos funcionare1n, ele oferece matrizes de respon-
sabil idade para mostr ar que papel é responsável por que atividades em cada ponto
de passagem de fase. O extenso número de ferra 1nentas e processos que ele define
para os gerentes de projetos oferece um meio un iforme e eficiente de gerenciar
projetos. O CIP, por sua vez, está hoje no cerne de um grande programa para adi-
cionar softare no nível empresarial ao arsena l de ferramentas de GP da empresa.
• Construção de uma Comunidade de Gestão de Projetos. A página do GPMO na
internet oferece notícias, mensagens executivas, links para recursos de preparação
para o exame de PMP®, CIP e um grupo Engage cada vez mais popu lar centrado
na Comunidade de GP. O GPMO também encoraja os gerentes de projetos a ofe-
recer lições aprendidas "ao vivo" em vez de contar com u1n repositório estático.
• Prê1nio Equipe de Projetos do Ano. Un1 programa dedicado foi estabelecido en1
janeiro de 2008 para reconhecer as as equipes de projeto de maio r destaque en1
cada região e na empresa como um todo. O progran1a foi criado con1 gerentes
de p rojetos. Indicações de 32 equipes foram recebidas e julgadas por un1 painel
de gerentes de p rojetos e executivos. Durante o ano, repo rtagens baseadas nas
indicações foran1 colocadas no site do GPMO e em outros importantes s ites
corporativos. Nove finalistas foran1 selecionados, e, destas, foi selecionado un1
único vencedor. Todos os outros final istas recebem um jantar com a equipe, e
a equipe vencedora envia un1 representante a Paris para receber un1 prêmio es-
pecial do CEO da Alcatel-Lucent. Esse programa continuou na Alcatel-Lucent,
e em 2013 continua sendo um de seus ma is populares programas de reconhe-
c1n1ento.
• Avaliação da maturidade e melhorias. Em 2008, o GPMO iniciou uma mensura-
ção deliberada da maturidade em gestão de projetos usando uma ferramenta de
pesquisa padronizada, const ruída a pa rtir de recomendações do Sofnva re Engi-
neering Institute (Carnegie Mellon University, Capabil ity Maturity Measurement
Integrated e o Conselho Executivo do Escritório de Gestão de Projeto, parte do
Conselho Executivo Corporativo). O número de perguntas foi lim itada a 25, di-
vididas ent re á reas como governança, desempenho de projetos, gerenciamento de
recursos e finanças. A taxa de resposta foi mu ito alta (700 participantes), e as res-
postas geraram dados matemáticos além do feedback palavra por palavra, o que
ofereceu um cam inho para identificar mel horias.
Verificando os benefícios
As inscrições no Sistema de Gerenciamento de Recursos e Habilidades (RSMS) aumen-
taram desde que foi introduzido, ao ponto de - apesar de uma rotatividade sign ificati-
va na força de trabalho - bem mais de 90% ter começado a gerenciar ativamente suas
habilidades usando os programas dedicados personalizados para os quatr o perfis de
cargo de gerentes de projetos. Mais de 100 novos PMPs® foram certificados graças ao
estabelecÍlnento de metas e ao uso dos grupos de estudo para o exame de PMP®. Além
d isso, 36 novas acreditações gera is de gerente de projetos fora 1n conced idas em 2008,
u1n au1nento de quase 30%.
O GPMO possui como uma de suas prioridades a disseminação da liderança no
raciocínio e1n gestão de projetos pela Alc.atel-Lucent, por meio de:
• Apresentações em congressos 1nundiais do PMI

• Publicações de artigos na revista Leadership in Project Manage,nent do PMI
• Apresentações da Alcatel-Lucent no PMO Summit (Flórida, EUA) e no PMO Sym-
posium (Texas, EUA)
• Participação no comitê de operações da 4' edição do Guia PMBOK®
• Contribuições com a 5ª edição do G11ia PMBOK®
Fina lmente, e1n termos de resultados estatísticos, todas as medidas a seguir de-
monstraram 1nelhorias na passagem de ano de 2007 ou 1nesmo em 2008:
• Linha de base de projetos abaixo da 1narge1n financeira de controle aumento e1n
160% .
• O percentua l de projetos com aumento de escopo (aprovado) quase dobrou.
• O percentua l de projetos abaixo dos custos previstos ma is do que dobrou.
• O percentual de projetos cobertos pelo siste1na empresarial de gestão de projetos
subiu de 52 para 87'% no ano de 2008.
• O percentua l de gerentes de projetos certificados cotn planos de desenvolvi1nento
forma is passou de 52 para mais de 80%.
Claramente, um foco dual sobre pessoas e processos teve um resultado positivo
para a empresa e auxiliou os projetos sob o GPMO a e1úrentarem o período de fusão
sem grandes problemas - u1n grande feito por si só.
Seis Sigma e o escritório
13.0 Introdução
No capítu lo anterior, discutimos a i1nportância do PMO para o p lanejamento estra-
tégico e as melhorias contínuas. Em a lgu1nas empresas, o PMO foi estabelecido espe-
cificamente para supervisionar e gerenciar projetos Seis Sigma. As equipes Seis Sigma
em toda a organizaç.ã o reunia1n dados e faziam recomendações ao PMO para projetos
Seis Sigma. O gerente de projetos Seis Sigma e, possivehnente, a equipe, eram perma-
nentemente designados ao PMO.
Infelizmente, nem todas as empresas podem se dar ao luxo de manter um grande
PMO no qual equipes Seis Sigma e outro pessoa l de suporte são permanentemente de-
signados ao PMO. O autor acredita que a maioria dos PMOs não possua mais do que
quat ro ou cinco pessoas permanentemente designadas. As equ ipes Seis Sigma, incluin-
do o gerente de projetos, podem acabar sendo registradas como "pontilhadas" (tem-
porárias) no PMO e ad1n inistrativamente"sólidas" (permanentes) em out ras pa rtes da
organização. As responsabilidades do PMO nessas organizações são primordialmente
avaliação, aceitação e priorização de projetos. O PMO pode também ter a autoridade
de rejeitar soluções recomendadas para projetos Seis Sigma.
No restante deste capítulo, focalizaremo-nos em organ izações que mantêm equi-
pes pequenas no PMO. O pessoal designado ao PMO pode possuir um conhecitnento
considerável no que diz respeito ao Seis Sigma, mas pode não ser nem Faixa Verde
nem Fa ixa Preta em Seis Sigma. Esses PMOs pode e gerenciam projetos Seis Sigma
selecionados, mas talvez não o tipo tradiciona l de projetos Seis Sigma ensinado em
sala de aula.
13.1 Relação entre gestão de projetos

e Seis Sigma
Existe uma relação entre a gestão de projetos e o Seis Sigma? A resposta é, com
toda certeza, "sim". O prob lema é con10 trocar os benefícios de modo que os bene-
fícios do Seis Sigma possam ser integrados à gestão de projetos e, da n1esma forn1a,
os benefícios da gestão de projetos possam ser integrados ao Seis Sigma. Algumas
empresas, como a EDS, já reconheceran1 essa importante relação, especialn1ente a
cont r ibu ição dos princípios Seis Sign1a para a gestão de projetos. Doug B0lzn1an,
arquiteto consu ltor, PMP® e especia lista en1 IT!Ls® na Hewlet t-Packard, discute
essa relação:
Capítulo 13 Seis Sigma e o escritório de gestão de projetos 563
Incorporamos a Biblioteca de Informações sobre Tecno logia da Informação (ITIL" , l11{or-

mation Tech110/ogy l11{ormation Library) à estrutura de Gerencia mento Empresarial de
Tecnologia da Informação (ITEM, l11{ormatio11 Tech110/ogy E11terprise Ma11ageme11t) para
projetar o modelo o peracional necessário para ma nter e servir de s uporte à liberação. Os
componentes de operações da ITIL'" são avaliados e incl uídos em cada liberação que exige
um foco operaciona l. Os modelos Seis Sigma foram gerados para atLxiliar a organ ização na
compreensão das capacidades de cada liberação e como gerenciar os requisitos, padrões e
dados de cada uma das capacidades estabelecidas.
Hoje, existe uma crença co1nu1n de que a maioria dos fracassos tr ad iciona is, orien-
tados à manufatura do Seis Sigma se devem à fa lta da gestão de projetos; ninguétn está
gerenciando os projetos Seis Sigma como projetos. A gestão de projetos oferece ao
Seis Sigma processos est rutu rados a lém de uma execução mais rápida e melhor de
mel horias.
De uma perspectiva de gestão de projetos, os proble1nas com os Faixa Preta do
Seis Sigma incluetn :
• Incapacidade de apl icar p rincípios de gestão de p ro jetos ao p lanejamento de pro-
jetos Seis Sigma
• Incapacidade de aplicar princípios de gestão de projetos à execução de projetos
Seis Sigma
• Forte dependência de estatísticas e 1nínima dependência de processos de negócios
• Incapacidade de reconhecer que a gestão de projetos agrega valor
Se essas áreas problemáticas não forem resolvidas, então, podem-se espera r fra-
cassos do Seis Sigma em decorrência de:
• Todos planejarem, ,nas muito poucos executarem melhorias de 1naneira eficiente.
• Haver p ro jetos demais na fi la e esforços de priorizaç.ã o insuficientes.
• O Seis Sigma permanecer na manufatura e não ser alin hado aos objetivos de ne-
, . .
goc1os gera is.
• Os Faixas Pretas não perceberem que a execução de mel horias são projetos dentr o
de um projeto.
O pessoal do Seis Sigma é formado por gerentes de projetos e, co1no tal, deve com-
preender os princípios da gestão de projetos, incluindo declarações de t rabalho, téc-
nicas de geração de cronogra tnas, entre outros. O mel hor pessoal do Seis Sigma sabe
gerenciar projetos e é bom gerente de projetos; Fa ixas Pretas são gerentes de projetos.
Un1a possível solução para a lguns dos fracassos do Seis Sigma é exigi r que seu
pessoal use a metodologia de gestão de projetos da empresa. Jason Schulist, gerente
de n1elhorias contínuas do G rupo de Estratégias Operaciona is da DTE Energy, dis-
cute ISSO.
Exemplo
Em 2002, a DTE Energy desenvolveu uma Estrutura de Sistema Operacional para possibi-
litar o pensamento sistêmico em torno de melhorias contínuas. Misturamos uma ferramenta
enxuta e uma estratégia de implementação Seis Sigma para desenvolver nossa abordagem
sistêmica "Sigma Enxuto". Essa abordagem utiliza um modelo de gestão de projetos de quatro
pontos de decisão/nove passos. '
1
O modelo é exibido na Seção sobre a DTE Energy, no Capítulo 4.
Os membros das diversas unidades de negócios podem apresentar ideias para projetos.
Um comitê de revisão prioriza os projetos dentro de cada unidade de negócios usando um do-
cumento de seleção de projetos. Uma vez priorizados, cada unidade de negócios aloca 1- 2o/o
de sua equipe organizacional em iniciativas de melhorias contínuas em regime de tempo inte-
gral. A maioria desses recursos não é nem treinado nem certificado em Sigma Enxuto. Esses
recursos usam o modelo de gestão de projetos de quatro pontos de decisão/nove passos para
todos os projetos.
O modelo de gerenciamento de 4-pontos de decisão/9-passos

Nos Passos 1- 3, o líder do projeto avalia a oportunidade de projeto, forma uma equipe e ana-
lisa a realidade atual usando técnicas rigorosas de análises de dados. Usando a ferramenta
y = f(x), as equipes são capazes de quantificar suas métricas e avaliar seus projetos no nível
apropriado. Todos os projetos certificados com Faixa Preta (BB, 8/ack Belt) têm que a lcançar
pelo menos US$250 mil em economias ou ter um impacto significativo sobre segurança ou
serviços de atendimento ao cliente. A equipe desenvolve um termo de abertura de projeto, que
o executivo defensor convicto assina juntamente com o formulário de revisão de passagem
de fase 1.
Nos passos 4-6, a equipe define o design ideal que mais eficientemente melhora as mé-
tricas acordadas na passagem de fase 1. A equipe identifica lacunas e desenvolve contrame-
didas mais eficientemente [usando a análise de modos e efeitos de falha (FMEA, tailure mode
and effect anatysis)] para migrar a iniciativa do estado atual para o estado ideal. A equipe de-
senvolve um plano mestre para implementar as mudanças e se compromete com alvos para
cada uma das métricas. A equipe mede tanto as métricas de entrada quanto de saída e mede
o sucesso do projeto no que diz respeito à melhoria dessas métricas. O executivo defensor
convicto assina a passagem de fase 2.
No passo 7, a equipe implementa seu plano e corrige seu curso à medida que for neces-
sário a fim de alcançar as métricas. Na passagem de fase 3, a equipe revisa seu desempenho
em relação ao plano, aborda lacunas e planeja contramedidas, discute o progresso em dire-
ção às metas do projeto e garante que os resultados sejam alcançados.
Nos passos 8 e 9, a equipe mede o progresso do projeto, sustenta as metas, agradece
à equipe, reflete sobre o projeto e comunica os resultados. A equipe realiza uma revisão pós-
-ação (AAR, after-action review) para inculcar a aprendizagem do projeto e reduzir erros em
futuras implementações. A equipe tem de alcançar as métricas do projeto da passagem de
fase 2 antes de o patrocinador assinar a passagem de fase 4. Se a equipe não alcançar suas
metas, ela provavelmente retornará ao ponto de decisão da fase 2 para redefinir o estado ideal
e confirmar se as metas originais ainda são alcançáveis.
O prêmio Sarah Sheridan da DTE Energy reconhece muitos projetos concluídos com
sucesso usando o modelo de gestão de projetos de quatro pontos de decisão/nove passos.
Melhorias nos sistemas operacionais usando a metodologia do projeto economizaram para a
DTE Energy mais de US$40 milhões em 2003 e mais de US$100 milhões em 2004.
13.2 Envolvendo o PMO

O PMO tradicional existe para melhorias de processos de negócios e apoia toda a
o rgan ização, incluindo os Faixas Pretas Seis Sigma, por meio do uso da 1netodologia
de gestão de projetos empresa rial. Os gerentes de projetos, incluindo os Faix as Pretas,
focal izam-se fo rtemente nas atividades que agregam va lor para o cliente, sejam eles
cl ientes internos ou externos. O PMO focaliza -se em atividades que agregam valor
para a corporação.
O PMO ta tnbém pode auxiliar com o alinhamento ent re os projetos Seis Sigma e
a estratégia. Isso inclui o segu inte:
• A repriorização frequente pode ser negativa. Tarefas importantes podetn ser sacri-
ficadas, e a motivação pode sofrer.
• Evitar prioridades para agradar a todos pode resultar no prolongamento ou na
dissolução de t rabalhos significativos.
• Utna mudança cultural pode ser necessária durante o al inhamento .
• Projetos e estratégia podetn estar funcionando com fina lidades confl itantes.
• A estratégia cotneça no topo da organização, enquanto projetos se originam no
meio dela.
• Funcionários podem recon hecer projetos, mas podem não ser capazes de articular
est ratégias. Selecionar o m ix adequado de projetos durante o gerenciamento de
portfól io não pode ser realizado eficientemente sem conhecer a est ratégia. Isso
ta lvez resulte em más interpretações.
• O "chunking" quebra um projeto grande em projetos menores para oferecer me-
lhor suporte à estratégia. Isso facilita a revitalização ou rejeição.
O PMO também pode auxilia r na solução de alguns dos problemas associados à
identificação das melhores práticas Seis Sigma, como:
• Intr oduzir uma mel hor prática pode "elevar a exigência" cedo demais e pressionar
projetos existentes a possivelmente implementar uma melhor prática que talvez
não seja apropriada naquele momento.
• Funcionários e gerentes não estão cientes da existência das melhores práticas e
não participam de sua identificação.
• A transferência de conhecimentos pela organização é inexistente ou fraca, na me-
lhor das hipóteses.
• Ser vítima da crença supersticiosa de que a maioria das melhores práticas são pro-
venientes de fracassos do que de sucessos.
Dito de forma simples, o "casamento" ent re a gestão de projetos e o Seis Sigma
permite-nos gerenciar 1nelhor, a partir de um nível mais alto.
13.3 Seis Sigma tradicional versus não tradicional

Na visão t radiciona l do Seis Sigma, os projetos se dividem etn duas categorias: de
manufatura e transacional. Cada categoria do Seis Sigma é multifacetada e inclui u1na
estratégia de gerenciamento, métrica e metodologia de melhoria de processos. Isso é
exibido na Figura 13- 1. Os processos Seis Sigma de manufatura uti lizam máquinas
para produzir produtos, enquanto os processos Seis Sigma transacionais util izam pes-
soas e/ou computadores para produzir serviços. A faceta da metodologia de melhoria
de processos do Seis Sigma aborda ambas as categorias. A única diferença são ferra-
mentas que você irá utilizar. Na 1nanufatura, onde utilizamos processos repetitivos
que produzem produtos, é mais provável que usemos ferramentas estatísticas. No Seis
Sigma transacional, talvez nos focal izemos mais na análise gráfica e em ferra tnentas/
técnicas criativas.
A visão tradicional de um projeto Seis Sigma possui um forte foco na melhoria
contínua de um processo ou atividade repetitiva associada à manufatura. Essa visão
tradiciona l inclui métricas, possivelmente estatística avançada, rigor e um forte desejo
Seis Sigma de Seis Sigma

manufatura transacional
FACETAS
• ESTRATÉGIA DE
GERENCIAMENTO
• MÉTRICA
• METODOLOGIA DE
MELHORIA DE
PROCESSOS
Figura 13-1 Categorias do Seis Sigma (visão tradicional).
de reduzir a variabilidade. A ma ioria desses projetos Seis Sigma se encaixa melhor

para i1nple1nentação na manufatura do que no PMO. A equipe Seis Sigma gerencia
esses projetos relacionados à manufatura.
Nem todas as empresas possuem manufatura e nem todas as empresas oferecem
suporte ao conceito de PMO. As empresas sem necessidade de 1nanufatura podem se
focaliza r ma is na categoria Seis Sigma transacional. As empresas sem um PMO depen-
dem fortemente das equipes Seis Sigma para o gerenciamento de ambas as categorias
de projetos.
Essas empresas que possuem suporte a um PMO devem se fazer as t rês perguntas
a seguir:
• O PMO deve estar envolvido em projetos Seis Sigma?
• Em caso afirmativo, que tipo de projeto é apropriado para o PMO gerencia r, mes-
mo se a organização possuir capacidade de manufatura?
• Temos recursos suficientes designados ao PMO para nos tornarmos ativa1nente
envolvidos na gestão de projetos Seis Sigma?
Os PMOs que são ativamente envolvidos na maioria das atividades descritas no
Capítulo 12 não possuem o tempo ou os recursos necessários para oferecer suporte
a todos os projetos Seis Sigma. Nesse caso, o PMO tem de ser seletivo quanto a que
projetos apoiar. Os projetos selecionados são normalmente chamados de projetos não
t radicionais, que se focalizam mais em atividades relacionadas à gestão de projetos do
que 1nanufatura .
A Figura 13- 2 mostra a visão não tradicional do Seis Sigma. Nessa visão, o Seis
Sigma operacional inclu i atividades de manufatura e todas as out ras atividades da
Figura 13- 1, e o Seis Sigma transacional agora contém primordia lmente as atividades
que servem de suporte à gestão de projetos.
Na visão não t rad iciona l, o PMO ainda pode gerenciar projetos Seis Sigma tan-
to trad icionais quanto não tr adicionais. Entretanto, há alguns projetos Seis Sign1a
não tradiciona is que são mais apropriados pa ra o gerenciamento pelo PMO. AI-
SEIS SIGMA
Seis Sigma Seis Sigma

operacional transacional
FACETAS
• ESTRATÉGIA DE
GERENCIAMENTO
• MÉTRICA
• METODOLOGIA DE
MELHORIA DE
PROCESSOS
Atividades Gestão de
cotidianas e projetos
funções repetitivas empresarial
Figura 13-2 Categorias Seis Sigma (visão não tradicional).
guns dos projetos atualmente confiados aos PMOs incluen1 melhorias à n1etodologia
empresa rial de gestão de projetos, n1elhorias ao conjunto de ferramentas do PMO,
n1elhorias relativas à eficiência e esforço de evitar/reduzir custos. Un1 outro projeto
confiado ao PMO envolve melhorias de processos para reduzir o lançamento de um
produto e melhorar o gerenciamento de clientes. Especialistas em Seis Sigma podem
ver esses tipos de projetos como não tradicionais. Há tan1bém certa preocupação
quanto a se esses são realn1ente projetos Seis Sigman ou simplesn1ente se trocou o
non1e de un1 projeto de n1elhorias contínuas a ser gerenciado por um PMO. Como
várias empresas agora chaman1 esses projetos de projetos Seis Sigma, o autor conti-
.
nuara con1 esse uso.
O p lanejamento estratégico da gestão de projetos Seis Sigma não é alcançado me-
ramente uma vez. Em vez disso, como qualquer outra função de planejatnento estraté-
gico, é um ciclo de mel horias contínuas. As melhorias podem ser pequenas ou grandes,
medidas quantitativa ou qua litativa1nente, e criadas pa ra cl ientes internos ou externos.
Quase sempre existe uma diversidade de ideias quanto a melhorias contínuas. O
maior desafio está na seleção eficiente de projetos e, então, na designação dos par-
ticipantes certos. Ambos esses desafios podem ser superados confiando as melhores
práticas em gestão de projetos Seis Sig1na ao escritório de gestão de projetos. Pode
até ser benéfico ter especialistas em Seis Sigma com Faixas Verdes ou Faixas Pretas
designados ao PMO.
13.4 Compreendendo o Seis Sigma

O Seis Sigma não se t rata somente de manufat ura de widgets. Trata -se de utn foco
sobre processos. E já que o PMO é o guard ião dos processos de gestão de projetos,
faz sentido que o PMO tenha algum envolvimento no Seis Sigma. O PMO pode estar
mais ativamente envolvido na identificação da "causa-raiz" de um problema do que
em gerenciar a solução Seis Sigma do problema.
Algu1nas pessoas argumentam que o Seis Sigma deixou a desejar e certamente não
se aplica às atividades confiadas ao PMO. Essas pessoas afirmam que o Seis Sigma é
si1nples1nente um 1nistério que alguns acreditam poder resolver qualquer problema.
Na verdade, o Seis Sigma pode ser um sucesso ou um fracasso, mas a intenção e a
compreensão precisam estar presentes. O Seis Sigma aproxiina-o do cl iente, melhora
a produtividade e determina onde você pode obter os maiores retornos. O Seis Sigma
consiste e1n melhorias de processos, normalmente processos repetitivos, e e1n redução
da 1nargem de erros humanos e/ou de 1náquinas. Os erros só podem ser determ inados
se você compreender os requisi tos críticos do cliente interno ou externo.
Há diversas visões e definições de Seis Sigma. Algu1nas pessoas veem o Seis Sigma
como apenas um outro nome para os programas de gestão da qualidade total (TQM,
total q11ality tnanagetnent). Outras, veem o Seis Sigma como a implementação da ri-
gorosa aplicação de ferramentas estatísticas avançadas em toda a organ ização. Uma
terceira visão combina as duas primeiras, definindo o Seis Sig1na como a aplicação de
ferramentas estatísticas avançadas a esforços de TQM.
Essas visões não são necessariamente incorretas, mas são inco1npletas. De uma
perspectiva de gestão de projetos, o Seis Sigma pode ser visto como algo que simples-
mente obtém 1na ior satisfação do cliente por meio de esforços de melhorias contínuas
de processos. O cliente pode ser externo à organização ou interno. A palavra "satisfa-
ção" pode ter um significado diferente se estivermos d iscutindo clientes externos ou
internos. Os cl ientes externos esperam produtos e serviços de alta qua lidade e com
preços razoáveis. Os clientes internos podem definir satisfação em termos financeiros,
como margens de lucros. Os clientes internos também podem se focalizar em itens
como redução do tempo de ciclo, exigências de segurança e exigências ambienta is.
Se essas exigências forem cu1npridas da maneira mais eficiente se1n nenhu1n custo
que não agregue valor (p.ex.: mu ltas, ret rabalho, horas extras), as margens de lucro
au1nentarão.
Podem ocorrer desacordos ent re as duas definições de satisfação. Os lucros podem
sempre aumentar diminuindo a qualidade. Isso pode colocar em risco negócios futuros
com o cliente. Fazer 1nelhorias na metodologia para satisfazer a determinado cl iente
pode ser viável, mas pode ter um efeito negativo sobre outros clientes.
A visão trad icional do Seis Sigma se focalizava forte1nente nas operações de ma-
nufatura, usando mensurações e 1nét ricas quantitativas. Os conjuntos de ferramentas
Seis Sigma foram criados especificamente para essa fina lidade. Suas atividades aqui,
podem ser defin idas como Seis Sigma operacional e Seis Sigma transaciona l. O Seis
Sigma operaciona l engloba a visão tradicional e se focal iza mais em processos, como a
metodologia de gestão de projetos empresarial, com ênfase em 1nelhorias contínuas no
uso dos formu lários, diretrizes, listas de verificação e templates associados. Algumas
pessoas discute1n que o Seis Sigma transacional não passa de um subconjunto do Seis
Sigma operaciona l. Embora esse argumento tenha seu 1néri to, a gestão de projetos e
especificamente o PMO passam a maior parte do seu tempo envolvidos com o Seis
Sigma transacional, e não com o operacional.
O objetivo últiino do Seis Sigma é a satisfação do cliente, mas o processo pelo qual
o objetivo é alcançado pode diferir se estivermos discutindo Seis Sigma operacional ou
t ransacional.
Os objetivos do Seis Sigma pode1n ser estabelecidos ou nos níveis de execução ou
nos níveis de traba lho. Os objetivos podem ou não ser concluídos com a execução de
apenas um projeto. Isso é indicado na Tabela 13- 2.
As iniciativas Seis Sigma de gestão de projetos são criadas não para substitu ir
iniciativas em andamento, mas para se focalizar nas atividades que possam ter um
TABELA 13-1 Objetivos do Seis Sigma

Objetivo• Método usado para alcançá-lo
Compreender e cumprir os requisitos do d iente (fazê-lo Melhorar formulários, diretrizes, listas de verificação e
por meio da prevenção e redução em vez de inspeção) templates para compreender os requisitos dos clientes
Melhorar a produtividade Melhorar a eficiência na execução da metodologia de
gestão de projetos
Gerar maior receita líquida diminuindo os custos ope- Gerar uma receita líquida mai s alta, racionalizando a
racionais metodologia de gestão de projetos sem sacrificar a
qualidade ou o desempenho
Reduzir o retrabalho Desenvolver diretrizes para melhor compreender os
requisitos e minimizar as mudanças de escopo
Criar um processo previsível e consistente Melhorias continuas sobre os processos
ªDe: The Fundamentais oi Seis Sigma, lnternational lnstitute for learning, NewYork, 2008, p. 1-24.
TABELA 13-2 Objetivos versus áreas de foco

Objetivos executivos Áreas de foco do PMO
Fornecer relatórios de status eficientes Identificação das necessidades executivas
Utilização eficiente das informações
Relatórios de status no formato "Semáforo"
Reduzir o tempo de planejamento de projetos Compartilhamento de informações entre documentos de
planejamento
Uso eficiente do software
Uso de templates, listas de verificação e formulários
Templates para relatório de status para o cliente
Pesquisas de satisfação do cliente
Extensões da metodologia de gestão de projetos empre-
sarial na organização do cliente
impacto crítico para a qualidade ou para a satisfação do cliente tanto no longo quanto
no curto prazo.
Os objetivos operacionais do Seis Sigma enfatizam a redução da margem de erro
humano. No enta nto, as atividades Seis Sigma transacionais gerenciadas pelo PMO
pode1n envolver questões hu ma nas, como alinhar o bjetivos pessoais aos o bjetivos do
projeto, desenvolver u1n sistema equitativo de recompensas pa ra as equipes de proje-
tos e oportunidades de planos de carreira. Resolver os p roble1nas das pessoas faz parte
do Seis Sigma transacional, mas não necessa riamente do Seis Sigma operacional.
2
13.5 Os mitos do Seis Sigma
Dez m itos do Seis Sigma são apresentados na Ta bela 13- 3. Eles são conhecidos há
algum tempo, mas ficaram bastante evidentes q uando o PMO assum iu a responsa bili-
dade pelas iniciativas de gestão de p ro jetos de Seis Sigma tr ansaciona l.
2
Adaptado de F. W. Breyfogle III, J. M . Cupello e 8. Meadows, Managing Six Sigma, Ho bo ken, NJ: \Viley,
200 1, p. 6- 8.
TABELA 13-3 Dez mitos do Seis Sigma

1. Funciona somente na manufatura
2. Ignora o cliente em busca de lucros
3. Cria uma organização paralela
4 . Exige um treinamento excessivo
5. É um esforço supérfluo
6. Exige equipes grandes
7. Cria burocracia
8. É apenas mais um programa de qualidade
9. Exige estatísticas complicadas e difíceis
10. Não tem um bom custo-benefício
Funciona somente na manufatura

Gra nde pa rte do sucesso inicial da aplicação do Seis Sigma baseou-se na manufa-
tura; no entanto, publicações recentes abordaram out ras apl icações da 1netodologia .
3
Breyfogle incl ui m uitas aplicações t ransacionais/de serviços. No relatório anual da
GE de 1997, o CEO Jack Welch declara orgulhosamente que o Seis Sigma " focal iza-se
etn levar cada processo que chega aos nossos cl ientes - cada produto e serviço (ênfase
adicionada ) - um passo adiante em direção à qua lidade quase perfeita" .
Ignora o cliente em busca de lucros

Essa afi rmação não é um mito, e sim uma má interpretação. Os projetos que fazem o
investimento em Seis Sigma valer a pena devem (1) ser de interesse p rimordial para o
cliente e (2) ter o potencial de melhorar significati vamente o resultado final. Ambos
os critérios precisam ser atendidos. É o cliente q ue está no leme deste "ba rco". No
a mbiente competitivo de hoje em dia, não há forma mais ga rantida de ir à falência do
q ue ignora r o cliente em uma busca cega por lucros.
Cria uma organização paralela

Um dos objetivos do Seis Sigma é eliminar cada vestígio de desperdício organizacional
q ue possa ser encontrado e, então, reinvesti r um pequeno percentual dessas economias
pa ra continua r a impulsionar melhorias . Cotn a gra nde quantidade de downsizing
q ue ocorreu pelo mun do durante a última década, não há espaço ou incl inação para
desperdiçar di nheiro por meio da d uplicação de funções. Muitas delas têm falta de
pessoa l. O Seis Sigma envolve alimentar cada função que agregue um valor significati-
vo para o cliente, adiciona ndo uma receita significativa ao resultado final.
Exige um treinamento excessivo

Peter B. Vaill afirma:
Inovações valiosas são o resultado positivo dessa era (em que vivemos), mas o custo pro-
vavelmente cont inuará a ser interferências constantes no sistema devido ao fato dos mem-
bros nunca pararem de mexer nele. Cond ições de constante agitação estão nos levando
3
F. W. Breyfogle, III, lmplemenring Six Sigma; Smarrer Solutions Using Scarisr:ica l .Merhods, Hoboken, NJ :
\Viley, 1999.
todos a sa ir de nossa zona de conforto e nos exigindo coisas que jamais imaginamos
que seriam exigidas. Está na hora de fazermos uma pausa e pensarmos cuidadosamente
na ideia de ser continuamente lançado de volta ao nosso "modo iniciante ", pois este é
o verdadeiro significado da aprendizagem contínua. Não precisamos de habil idades de
competência para esta vida. Precisamos da habilidade de incompetências, as habilidades
de ser realmente iniciantes.
É um esforço supérfluo
Este é simplesmente o mito "cria uma organização para lela" disfarçado. Mesma per-
gunta, mesma resposta.
Exige equipes grandes

Há 1nuitos livros e artigos na literatura de negócios que declara tn que as equipes
devem ser pequenas se quiseretn ser eficientes. Se as equipes foretn grandes demais,
acredita-se, ocorre uma explosão combinatória no número de possíveis canais de co-
municação entre os membros da equipe, e, consequentemente, ninguém sabe o que a
out ra pessoa está fazendo.
Cria burocracia
Utna defin ição de dicionário do termo burocracia é "a rígida aderência a rotinas
administ rativas". A única coisa rígida sobre a metodologia Seis Sigma aplicada de
forma sensata é sua incansável insistência na ideia de que as necessidades do cliente
precisa tn ser atendidas.
É apenas mais um programa de qualidade

Com base no fraco desempenho de inúmeros programas de qualidade durante as últi-
mas t rês a cinco décadas, um programa de qualidade eficiente seria bem-vindo. Mais
objetivo,5 o Seis Sigma é"uma forma totalmente nova de gerenciar uma organização".
Exige estatísticas complicadas e difíceis

Não há dúvidas de que diversas ferramentas estatísticas avançadas sejam extretnamen-
te valiosas na identificação e solução de problemas de processos. Acreditamos que os
praticantes precisam possuir experiência ana lítica e compreender o uso sensato dessas
ferramentas, mas não precisam compreender toda a 1natemática por t rás das técnicas
estatísticas. A aplicação sensata das técnicas estatísticas pode ser rea lizada por meio
do uso de software de análise estatística.
Não tem um bom custo-benefício

Se o Seis Sigma for itnplementado de forma sensata, as organizações podem obter u1na
alta taxa de retorno sobre investimentos logo no primeiro ano.
4
J. Micklerhwait e A. \Vooldridge, Tl,e \Vitch Doctors o/ the Ma11agement Gunts, New York: Ran.dom Hou~
se, 1997.
' T. l'yzdek, "Six Sigma Is Primarily a lvlanagemenc Program", Quality Digesr, 1999, p. 26.
13.6 Uso de avaliações

Uma das responsabil idades que pode ser confiada a um PMO é o gerenciamento de
portfólio de projetos. Ideias para possíveis projet os podem se originar e1n qualquer lu-
gar da organização. Entretant o, ideias especificamente designadas como projetos Seis
Sigma transacional podem ter de ser procuradas pelo PMO.
Uma 1naneira de determina r projet os potenciais é por meio de uma avaliação.
Uma ava liação é um conjunto de diretr izes ou procedimentos que permitem que uma
organização to1ne decisões sobre mel horias, a locações de recursos e até mes1no priori-
dades. As aval iações são maneiras de:
• Exam inar, definir e possivelmente medir as oportunidades de desempenho
• Identificar o conhecimento e as habi lidades necessárias para alcançar as 1netas e
objetivos organizaciona is
• Exam inar e solucionar problemas de lacunas no desempenho
• Acompanhar as melhorias para fins de validação
Un1a lacuna é a diferença entre o que existe atualn1ente e o que deveria existir. As
lacunas poden1 ser relativas a custo, ten1po, qualidade, dese1npenho ou eficiência. As ava-
liações nos permitem identificar a lacuna e detern1inar o conhecimento e as habilidades
necessárias para preenchê-la. Para as lacunas de gestão de projetos, as avaliações podem
ser fortemente tendenciosas em direção a problemas transacionais, e1n vez de operacio-
nais, e isso pode faci lmente resultar em projetos de modificação de co1nporran1ento.
Há vários fat ores que deve1n ser considerados antes de realizar u1na ava liação.
Tais fatores podem inclu ir:
• Quant idade de suporte e patrocínio do nível executivo
• Quant idade de suporte da gerência de área
• Foco e1n aplicações de base ampla
• Definição sobre quem avaliar
• Viés dos participantes
• Realidade das respostas
• Disposição a aceita r os resultados
• Impacto sobre a política interna
A fina lidade da ava liação é identificar n1aneiras de melhorar as práticas de negó-
cios globais primeiro e depois as práticas de negócios funcionais. Como o público-alvo
é normahnente global, é preciso existir suporte e con1preensão unificada do processo de
avaliação e do fato de ela ser do interesse de toda a organização. Proble1nas de política,
poder e autoridade têm que ser colocados de lado para o aperfeiçoan1ento da organ ização.
As ava liações podem ocorrer em qualquer nível da organizaç.ã o. Elas podem ser:
• Organizacionais globais
• Organizacionais das unidades de negócios
• De processos
• Individuais ou de tarefas
• De feedback do cliente (satisfação e melhorias)
Há várias ferra 1nentas disponíveis para ava liações. U1na lista típica pode incluir:
• Ent revistas
• Grupos de foco
• Observações
• Mapas de processos
Avaliações de gestão de projetos Seis Sigma não devem ser realizadas a menos que
a organizaç.ã o acred ite que haja oportunidades. A quantidade de te1npo e esforço gasta
pode ser significativa, como mostra a Figura 13- 3.
As vantagens da ava liação podem levar a melhorias significativas na satisfação do
cliente e na lucratividade. Entretanto, há desvantagens, como:
• Alto custo dos processos
• Exige mão de obra intensiva
• Dificuldade em medir que atividades de gestão de p rojetos podem se beneficiar
das a vali ações
• Talvez não forneça nenhum benefício significativo
• Não se pode medir um retorno sobre investimento a partir das avaliações
As aval iações podem ter vida própria. Há fases do ciclo de vida típicas para ava-
liações. Essas fases do ciclo de vida podem não estar alinhadas às fases do ciclo de
vida da metodologia de gestão de projetos empresarial e pode1n ser realizadas mais
informa l do que formalmente. Fases do ciclo de vida típicas para ava liações incluem:
• Reconhecimento de lacuna ou problema
• Desenvolvimento do conjunto de ferramentas de ava liação apropriado
• Condução de ava liaç.ão/investigação
• Aná lises de dados
• linplementaç.ã o das mudanças necessárias
• Revisão para possível inclusão na bibl ioteca de melhores práticas
Determ inar o conjunto de ferramentas pode ser d ifícil. O elemento mais co1nu1n
de um conjunto de ferra 1nentas é um foco em perguntas. Tipos de perguntas inclue1n:
• Perguntas abertas
• Segmentos sequencia is
• Comprimento
• Complexidade
• Tempo necessário para responder
O Avaliações de Gestão de Projetos Seis Sigma
l
Tempo
O Avaliações de Uso de Metodologias
O Avaliações de Competência
O Avaliações de Trabalhos e Tarefas
O Avaliações Educacionais da Gestão de Projetos
Rigor _ _.
Figura 13-3 Tempo e esforços gastos.
TABELA 13-4 Escalas

Concordam fortemente Menosde20%
Concordam Entre 20 e 40%
Indecisos Entre 40 e 60%
Discordam Entre 60 e 80%
Discordam fortemente Maisde80%
• Perguntas fechadas
• Múltipla escolha
• Escolhas forçadas (sim- não, verdadeiro- falso)
• Escalas
A Tabela 13-4 ilustra como detenninar esca las. A coluna da esquerda solicita
u1na resposta qualitativa e pode ser subjetiva, enquanto a coluna da direita seria uma
resposta quantitativa e mais subjetiva .
É de importância vital que o instrumento de ava liação passe por u1n teste piloto .
A importância dos testes piloto seria:
• Validamento da compreensão das instruções
• Facilidade de resposta
• Tempo para responder
• Espaço para responder
• Análise de perguntas ruins
13.7 Seleção de projetos

A gestão de projetos Seis Sigma se focaliza en1 n1elhorias contínuas para a meto-
dologia de gestão de projetos empresarial. Identificar projetos potenciais para o
portfólio é sign ificativamente mais fáci l do que real izá-los. Há dois principais mo-
tivos para tal:
• PMOs típicos podem não ter mais de três ou quat ro funcioná rios. Com base nas
atividades confiadas ao PMO, os funcionários podem ser limitados quanto ao
tempo que podem destinar para as atividades de gestão de projetos Seis Sigma.
• Se recursos funcionais são necessários, eles podem ser designados primeiro pa ra as
atividades que são obrigatórias para o andamento da empresa.
O conflito entre negócios em andamento e melhorias contínuas ocorre frequen-
temente. A Figura 13-4 ilust ra esse ponto. A atividade idea l de gestão de projetos
Seis Sigma geraria uma a lta satisfação dos clientes, altas oportunidades de redução de
custos e um apoio significativo para os negócios em andamento. Infelizmente, o que é
do interesse do PMO pode não ser do interesse dos negócios em andamento no curto
prazo.
Todas as ideias, independente de serem boas ou ruins, são armazenadas no "banco
de ideias". As ideias pode1n se originar de qua lquer lugar da organização, a saber:
• Executivos
• Executivos convictos do Seis Sigma
• Executivos convictos de projetos Seis Sigma
• Mestres Fa ixas Pretas
• Faixas Pretas
• Faixas Verdes
• Membros das equipes
Se o PMO estiver ativamente envolvido no gerenciamento de porúólio dos pro-
jetos, terá de rea liza r estudos de viabilidade e aná lises de custo-benefício de projetos,
juntamente co1n recomendações de priorização. Oportunidades típicas podem ser de-
terminadas usando a Figur a 13- 5. Nesta figura, 6X representa a quantia de dinheiro
(ou dinheiro adicional) que está sendo gasta. Essa é a informação de entrada no pro-
Expectativas de
e/lente
Altas
Médias
Impacto sobre
Baixas o trabalho em
Alto andamento
Baixo Médio
Oportunidades de reduç5o de custos
Figura 13-4 Cubo de seleção de projetos.
cesso de aval iação. A saída é a melhoria, /l Y, que é o benefício recebido ou as econo-

mias de custo. Considere o exemplo a seguir.
Convex Corporation
A Convex Corporation identificou um possível projeto Seis Sigma envolvendo a racio-
nalização dos relatórios de status internos. A intenção era eli1n inar o máximo possível
de papel dos volumosos relatórios de status e substituí-los por relatórios com códigos
de cores do formato "semáforo" usando a intranet da empresa. O PMO usou os se-
guintes dados:
• Valor da hora (incluindo benefícios) no nível executivo: US$240
• Número típico de reuniões de revisão de status de projeto por projeto: 8
• Duração por reunião: 2 horas
• Número de executivos por reunião: 5
• Número de projetos que exigem revisão por executivos: 20
Usando as informações acima, o PMO calculou o custo total dos executivos como:
(8 reuniões) x (5 executivos) x (2 h/reun ião) x (US$240/h) x (20 projetos)=
US$384 mil
y +t;Y
(t,X =$$,e t,Y =$$ou benefícios)
Entrada~
Figura 13-5 Avaliação quantitativa do Seis Sigma.

A Convex designou un1 progran1ador de sistemas (a US$100/h) por quat ro semanas.

O custo de adicionar o relatório de semáforo à metodologia intranet foi de US$16 mil.
Seis meses após a implementação, o número de reuniões tinha sido reduzido para
cinco por projeto, com uma média de 30 minutos de duração. Os executivos agora se
focalizavam apenas nos elementos do projeto que tinham sido codificados com cores
como um possível problema. Em termos anuais, o custo das reun iões dos 20 projetos
agora estava em torno de US$60 mi l. Somente no primeiro ano, a empresa identificou
u1na economia de US$324 1n il para utn investimento de US$16 mi l.
13.8 Típicos projetos Seis Sigma do PMO

Os projetos confiados ao PMO podem ser operaciona is ou t ransacionais, mas, em sua
maioria, transaciona is. Projetos típicos podem incluir:
• Relatório de status aprimorado: Este projeto poderia util izar relatórios de semá-
foro criados para facilitar a análise de desempenho pelos cl ientes, o que é factível
se baseado na int ranet. A intenção é alcançar a gestão de projetos sem papel. As
cores podem ser at ribuídas dependendo dos problemas, riscos presentes ou futu-
ros, ou título, nível e classificação do público.
• Uso de formulários: Os formulários devem ser fáceis de usar e de preencher. Deve-
-se exigir input 1nínimo por parte do usuário e os dados informados etn um for-
mulário devem atender vários formulários, se necessário. Dados não essencia is
devem ser eliminados. Os formulários devem constar de uma listagetn cruzada na
biblioteca de melhores práticas.
• Uso de listas de verificação/temp/ates: Esses documentos devem ser abrangentes,
mas de fáci l compreensão, além de fáceis de usar e de atualizar. Os formulários
precisam ser flexíveis, de forma que possam ser adaptados a todas as situações.
• Critérios de sucesso/fracasso: É preciso haver critérios estabelecidos para o que
constitui sucesso ou fracasso em utn projeto. Tem de haver também um processo
que permita mensurações constantes com base nesses critérios, além de meios pe-
los quais o sucesso (ou fracasso) pode ser redefin ido.
• Empoderamento da equipe: Esse projeto ana lisa o uso de equ ipes de projeto in-
tegrada, a seleção de membros de equ ipe e os critérios a serem utilizados para
aval iar o desempenho de equ ipes. Este projeto é criado para facilitar a gerência
sênior a etnpoderar as equ ipes.
• Alinhamento de metas: A maioria das pessoas possui ,netas pessoais que podem
não estar al inhadas às do negócio. Isso inclui metas do projeto versus da em-
presa, metas do projeto versus metas funcionais, metas do projeto versus ,netas
individuais, metas do projeto versus metas profissionais, e outros alinhamentos
si1nilares. Quanto maior for o alinhamento ent re as metas, maior a oportunidade
de au1nento da eficiência e da eficácia.
• Mensuração do desempenho da equipe: Esse projeto se focaliza em maneiras de
apl icar uniformetnente os fatores críticos de sucesso e os indicadores-chave de
desempenho a métricas do desempenho da equipe. Inclui ta tnbém o alinhamento
do desempenho cotn metas e de recompensas com as metas. Esse projeto pode
interagir com o programa de admin istração salarial, exigindo revisões de desem-
penho de duas ou três vias.
• Modelos de competência: As descrições de cargo em gestão de projetos estão sen-
do substituídas por modelos de competências. Um critério de competência deve
ser estabelecido, incluindo a linha,nento de metas e mensuração.
• Precisão da aná lise financeira: Esse tipo de projeto procura formas de incluir os
dados 1nais precisos em revisões financeiras de projetos. Isso pode abranger a
transferência de dados de vários sistemas de informação e contabil idade de custos.
• Resolução de testes de falhas: Alguns PMOs mantêm um sistema de info rmação
de alerta de fa lhas que possu i interface com a FMEA. Infelizmente, falhas são
identificadas, mas pode não haver nenhuma resolução para elas. Esse projeto ten-
ta suavizar esse problema.
• Preparação de listas de verificação t ransicionais: Esse tipo de projeto é criado para
focalizar na t ransiç.ã o ou na prontidão de uma área funcional para aceitar respon-
sabilidade. Por exetnplo, pode ser possível desenvolver uma lista de verificação
para avaliar os riscos ou a prontidão de t ransicionamento do projeto da engenha-
r ia para a manufatura. A situação ideal seria desenvolver uma lista de verificação
para todos os projetos.
Essa lista não é, de forma alguma, exaustiva. Entretanto, identifica projetos típi-
cos gerenciados pelo PMO. Algu1nas conclusões podem ser tiradas com a sua análise.
Primeiro, os projetos podem ser tanto t ransacionais quanto operacionais. Segundo, a
maioria dos projetos focaliza-se em melhorias na metodologia. Terceiro, ter pessoas
com experiência em Seis Sigma (i.e., Faixas Verdes, Marrons ou Pretas) seria úti l.
Quando um PMO assume a iniciativa em gestão de projetos Seis Sigma, pode
desenvolver uma caixa de ferramentas Seis Sigma exclusivamente para PMO. Elas
muito provavelmente não incluirão as ferramentas estatísticas avançadas que são usa-
das pelos Faixas Pretas na 1nanufatur a, mas podem ser ferramentas mais orientadas a
processos ou ferra tnentas de avaliação.
Gerenciamento de
portfólio de projetos
14.0 Introdução
Sua em presa at ualmente está t ra bal ha ndo en1 vá rios projetos e p ossui uma lista de
espera de outros 20 p rojetos que gosta ria de concluir. Se o financian1ento disponível
supo rta apenas mais a lg uns p rojetos, com o a em presa decide em q uais dos 20 deve
trabal ha r em seguida? Esse é o p rocesso de gerenciamento de por fólios. É in1portan-
te co mpreender a diferença ent re gestão de projetos e gerencia n1ento de portfólio
de projetos. Debra Sto uffer e Sue Rachlin fizera m a segunte d istinção pa ra p rojetos
1
de T I:
Um portfólio de TI é composto por um conjunto ou co leção de iniciativas ou projetos. A
gestão de projetos é um processo contínuo que se focaliza em a té q ue ponto uma iniciativa
específica estabelece, mantém e a lca nça seus objetivos pretendidos dentro de suas linhas de
base de custo, de cronogra ma, técnicas e de desempenho.
O gerenciamento de portfólio focaliza a atenção em um nível ma is agregado. Seu ob-
jetivo primeiro é identi ficar, selecionar, financiar, monito rar e manter o ,nix apropriado de
projetos e iniciativas necessário para alcança r a s metas e objetivos o rganizacio na is.
O gerenciamento de portfólio envolve a consideração de custos, riscos e retornos agre-
gados de todos os projetos co ntidos no po rtfólio, a lém dos vários tradeo((s entre eles. Ob-
viamente, o gerente do po rtfólio também está preocupado com a "sa úde" e o bem-estar de
cad a projeto que está incluído no portfólio de TI. Afina l, as decisões de portfólio, co mo
financiar um novo projeto ou co ntinuar a fin anciar um q ue já está em andamento, baseiam-
-se em informações fornecidas no nível do projeto.
O gerenciamento de porúól io de pro jetos ajuda a determinar o ,nix certo de proje-
tos e o nível certo de investi1n ento a ser feito em cada um deles. O resultado é um me-
lhor equi líbr io entre iniciativas est ratégicas em andamento e novas . O gerencia mento
de portfólio não é uma série de cálculos específicos de projetos como RO i, VPL, TIR,
período de recuperação do investimento (payback) e fluxo de cai xa e depois fazer o
ajuste aproprado para considerar os r iscos. Em vez disso, é um processo de tomada de
decisões quanto ao que é do interesse de toda a organização.
As decisões do gerenciamento de porúól io não são tomadas no vácuo . Elas geral-
mente estão relacio nadas a o utr os projetos e a d iversos fatores, co1n o financia1n ento
dispo nível e a locações de recursos. Além d isso, o projeto p recisa se adequar bem a
out ros projetos do portólio e ao plano estratégico.
1
D. Srouffer e S. Rachlin, "A Summary of Firsr Pracrices and Lessons Learned in Informarion Technology
Ponfolio X1anagemenc··, prepa rado pelo Conselho de Principais Executivos de ln.formação (CIO),
Washington, DC, March 2002, p. 7.
Capítulo 14 Gerenciamento de portfólio de projetos 579
A seleção pode se basear na conclusão de out ros projetos que liberariam recursos
necessários para os novos projetos. Além disso, os projetos selecionados podem ser
restringidos pela data de conclusão de out ros projetos que exigem deliverables neces-
sários para iniciar novos projetos. E1n qualquer caso, alguma forma de processo de
gerenciamento de portfólio de projetos é necessária.
14.1 Por que usar o gerenciamento de portfólios?

Nem todas as empresas at ribuem o mesmo grau de importância ao gerenciamento de
portfólio. Em algumas empresas, t rata-se de u1n processo manual, enquanto em outras
exige o uso de ferramentas sofisticadas. Algumas empresas acreditam que o geren-
cia1nento de portfólio faz parte dos esforços de planejamento estratégico, enquanto
out ras o veem co1no uma função de suporte para o planeja1nento de capacidade. Carl
Manello, PMP®, d iretor de práticas de eficiência na ent rega da Slalom Consu lting,
acredita que:
O gerenciamento de portfólio é crucia l para garantir que as empresas estejam gastando
seus recursos limitados da melhor maneira possível. Já trabalhei co m empresas em vários
níveis para implementar algum tipo de gerenciamento de portfólio. Em a lguns casos, o
gerenciamento de portfólio é simplesmente uma extensão do processo orçamentário anual.
Nos melhores casos, ele se desenvolve em um processo totalmente validado de avaliação e
priorização contínua.
No entanto, não existe uma melhor abordagem para o gerenciamento de portfólio. O
processo de gerenciamento de portfólio pode ser implementado em graus variados. Por
exemplo, pode-se decidir estabelecer um processo com ou sem uma ferramenta sofisticada
de gerenciamento de portfólios. Até mesmo o processo pelo qual a priorização é realizada
pode variar. Dependendo da capacidade de organização, a abordagem pode ser um inventá-
rio de projetos correntes e propostos com uma classificação forçada criada pelo PMO. Para
a empresa ma is sofisticada, um processo plenamente desenvolvido pode envolver a gerência
sênior e a gerência executiva em uma negociação para decidir onde inves tir os escassos
recursos corporativos dependendo na unidade de negócios, objetivo estratégico e retornos
previstos. A Figura 14-1 ilustra uma típica matriz de portó lios. Em uma empresa, trabalhei
no desenvolvimento de um algoritmo numérico relativamente simplista para avaliar pro-
jetos. Após se estabelecerem critérios para Importância para os Negócios e Con,plexidade
(essas foram as duas medidas definidas pelo Escritório de Programas da Empresa e pelo
Principal Executivo Financeiro), cada projeto foi representado em uma matriz simples dois
por dois. Essa visualização nos ofereceu a possibilidade de comparar e contrastar projetos
não similares com m uito pouco esforço.
Em 2012, a Slalom se focalizou em aproveitar essa "prática comprovada" em portfólios
cada vez maiores. Em uma empresa global de negociação financeira, implementamos um
modelo a utomatizado para servir de s uporte a avaliações objetivas, quantificáveis e repetí-
veis do portfólio de um departamento que continha aproximadamente 100 iniciativas. Para
o foco empresaria l de uma operadora de celula~ o modelo foi usado para representar q uase
400 iniciativas. Estamos atualmente nos preparando para in iciar um traba lho com uma
empresa de serviços financeiros para implementar a ferramenta com visibilidade em toda
a empresa, incluindo mais de 900 projetos. Apesar de meu conhecido viés como extremista
em relação a ferramentas, reconheço o valor q ue elas trazem para o complexo mundo do
gerenciamento de portfólio.
Mesmo sem se comprometer com as ferramentas líderes no mercado para gerencia-
mento de portfólio de projetos, as empresas podem aproveitar a vantagem oferecida por
ferramentas básicas para ajudá-las em sua análise, ratificação, priorização e tomada de
decisões. Quando o exercício do gerenciamento de portfólio se torna um exercício de criar
visibilidade para dados cruciais para a tomada de decisões, não somente os executivos se
tornam mais d ispostos a estarem alinhados com o processo e a participarem, mas também
Traçando o gráfico de pro/elos empresariais

1
Alta 1
1 @ Projeto H
@ Projeto A Projeto o
, Projeto X @ @ @ Projeto W
: Projeto e
@
, @ Projeto M
@ :Projeto D @ Projeto R
@ Projeto N @ Projeto S
i
1
@ Projeto E
1
____________________ -!- Prajeto B --------------
@ Projeto F
@ Projeto T
@ Projeto V
Projeto K @ @ Projeto E
@ Projeto J Projeto D
@ Projeto G
Baixa
~ ,
~------------~--------------~
Baixa Carl Manelloº Alta
Complexidade
Figura 14-1 Matriz de um portfólio típico.
as decisões se tornam decisões de negócios e não o apaziguamento do departamento que

gritar mais a lto o u do vice-presidente sênior.
14.2 Envolvimento da gerência sênior,

das partes interessadas e do PMO
O gerenciamento bem-sucedido de um portfól io de projetos exige uma forte li derança
pelos ind ivíduos que reconhecem os seus benefícios. O cotnpromisso pela gerência
sênior é crucial. Stouffer e Rachl in co1nentam sobre o papel da gerência sênior em um
a mbiente de TI e1n agências governamentais:2
O gerenciamento de portfólio exige uma perspectiva de negócios que abranja toda a em-
presa. Entretanto, as decisões de investimento em TI devem ser tomadas tanto no nível do
projeto quanto no nível do portfólio. Funcionários sênior do governo, gerentes de portfólio
e projeto e o utros tomadores de decisões precisam fazer rotineiramente d ois co nj untos de
perguntas.
Primeiro, no nível do projeto, há confiança suficiente de que atividades novas o u
e m a ndamento que estejam e m busca de financ ia mento alcançarão seus objetivos pre-
tendidos dentro de p arâmetros razoáveis e aceitáveis de c usto, cronograma, técnicos e de
desempenho?
Segundo, no nível do portfólio, dada uma resposta aceitável para a primeira pergunta, o
investimento em um projeto ou em um m ix de projetos é desejável do ponto de vista de um
o utro projeto ou mix de projetos?
' lbid., p. 8 .
Tendo recebido respostas para essas perguntas, os executivos sêni or da organização,

gerentes de portfólio e o utros tomadores de decisões devem, então, usa r as informações
para determinar o tamanh o, o escopo e a composição do portfólio de investimento em T I.
As condições sob as quais o portfólio pode ser mudado precisam ser claramente definidas
e comunicadas. Mudanças propostas para o portfólio devem ser revisadas e a provadas por
uma a utoridade apropriada de tomada de decisões, como um conselho de revisão de inves-
timentos, e consideradas a partir da perspectiva de toda a empresa.
A gerência sênior é, em última análise, responsável por definir e comunica r clara-
mente as metas e objetivos do portfólio de projetos, a lém de os critérios e condições
considerados para a seleção de projetos do por tfólio. Segundo Stouffer e Rachlin, isso
1.nc1u1:. 3
• Defini r adequadamente e comu nicar ampla1nente as metas e objetivos do portfó-
lio de TI.
• Articular clara 1nente as expectativas da organização e da gerência sobre o tipo de
benefícios pretendidos e as taxas de retorno a sere1n alcançadas.
• Identifica r e definir o tipo de riscos que podem afetar o desempenho do portfólio
de TI, o que a orga nização está fazendo para evitar e a bordar os riscos e sua tole-
rância à exposição atua l.
• Estabelecer, chegar a um consenso e consistentemente aplicar um conjunto de cri-
térios que serão usados entre projetos e in iciativas concorrentes de TI.
A gerência sênior també1n te1n de coletar e anal isa r dados a fim de aval iar o
desempenho do portfó lio e determinar se ou ajustes são ou não necessários. Isso pre-
cisa ser feito periodicamente, de modo que recursos cruciais não sejam desperdiçados
em projetos que deveria m ser ca ncelados. Stouffer e Rachlin falam sobre isso em suas
• 4
entrevistas:
Segundo Gopal Kapur, presidente do Centro de Gestão de Projetos (Ce11ter for Project Ma-
11ageme11t), as o rganizações devem se focaliza r em s uas avaliações de po rtfólios de TI e
reuniões de controle sobre os sina is vitais de projetos cruciais. Exemplos desses s inais vi-
tais incluem comprometimento e tempo do patrocinador, status do caminho crítico, taxa
de cumprimento de marcos, taxa de cumprimento de deliverables, custo real versus c usto
estimado, recursos reais versus recursos planejados, e eventos de alta probabilidade e a lto
impacto. Usando uma abordagem de cartões de relatórios vermelhos, a ma relos ou verdes,
além de métricas bem definidas, uma o rganização pode estabelecer um método consistente
para determinar se os projetos estão tendo um impacto adverso sobre o portfól io de TI,
estão fracassando e precisam ser cancelados.
Critérios e dados específicos a serem coletados e ana lisados podem incluir o seguinte:
• Medidas financeiras padrão, como retorno sobre investimento, a nálise de custo e bene-
fício, valo r agregado (focalizando em realidade versus plano, q uando ho uver dados d is-
poníveis), maior lucratividade, contenção de c ustos ou pagamentos. Cada organização
que participou das ent revistas incluiu uma o u mais dessas medidas financeiras.
• Alinha mento estratégico (definido como suporte à missão), também incluído por quase
todas as o rganizações.
• Impacto sobre o cl iente, como definido em medidas de desempenho.
• Impacto te.e nológico (como med ido pela contribuição para ou impacto sobre a lguma
forma de a rquitetura definida).
• Projeto inicial e (em a lg uns casos) operações e cronogramas, como observado por quase
todas as o rganizações.
' lbid., p. 13.

' lbid., p. 18.
• Riscos, prevenção de riscos (e às vezes especificidades relativas à sua mitigação), como

observado por quase todos os participantes.
• Técnicas e medidas de uma gestão de projetos básica.
• E, finalmente, fontes de dados e mecanismos de coleta de dados também são impor-
tantes. Muitas organ izações entrevistadas preferiram extrair informações de sistemas
existentes; as fontes incluem sistemas contábeis, financeiros e de gestão de projetos.
Uma das melhores práticas identificadas por Stouffer e Rachlin para projetos de
5
TI foi a consideração cuidadosa das partes interessadas internas e externas:
Um envolvimento de negócios cada vez maior no gerenciamento de portfólios geralmente
inclui o seguinte:
• Reconhecer que os programas de negócios são partes interessadas essenciais, e melhorar
essa relação em todo o ciclo de vida
• Estabelecer acordos de nível de serviço que estejam atrelados à responsabilidade (re-
compensas e punições)
• Transferir as responsabilidades para os programas de negócios e envolvê-los em grupos-
-chave de tomada de decisões
Em muitas organizações, há mecanismos que permitem a criação, a participação e ade-
são de coa lizões de partes interessadas. Esses me.c anismos são essenciais para garantir que
o processo de tomada de decisões seja mais inclusivo e representativo. A participação e a
adesão das partes interessadas também pode oferecer s ustentabilidade aos processos de
gerenciamento de portfólio quando há mudanças na liderança.
Foram criadas coalizões de partes interessadas de mu itas maneiras diferentes, depen-
dendo da organização, do processo e do problema em questão. Ao incluir representantes
de cada principa l componente organ izacional que é responsável por priorizar as muitas
iniciativas concorrentes sendo apresentadas em toda a organização, todas as perspectivas
são incluídas. A abordagem, juntamente com a objetividade trazida ao processo pelo uso
de critérios predefin idos e um sistema de suporte a decisões, garante que todos tenham
influência no processo e que o processo seja justo.
Da mesma forma, a participação do órgão máximo de tomada de decisões compreende
executivos sên ior de toda a empresa . Todos os principais projetos, ou aqueles que exigem
uma fonte de financiamento, devem ser votados e aprovados por esse órgão de tomada de
decisões. O valor da obtenção da participação das partes interessadas nesse nível sênior é
q ue esse órgão traba lha em direção ao s uporte da missão gera l da organ ização e de suas
prioridades, em vez de a interesses pessoais.
Hoje, cada vez mais empresas estão passando a confiar fortemente no PMO para
o suporte ao gerenciamento de portfólio. Atividades de suporte típicas incluem o pla-
nejamento de capacidade, uti lização de recursos, aná lise de casos de negócios e prio-
rização de projetos. O papel do PMO nesse sentido é apoiar a gerência sên ior, não
substituí-la. O gerencia1nento de portfólio quase sempre permanece como responsabi-
lidade primordia l da gerência sênior, mas as recomendações e o suporte oferecido pelo
PMO podem facilitar um pouco o trabalho do executivo. Nesse papel, o PMO pode
funcionar mais como um facilitador. Chuck Millhollan, diretor de gerenciamento de
programas da Churchill Do,vns Inc. (CDI), descreve o gerenciamento de portfólio em
sua organização:
Nosso Plv!O é res ponsável pelo processo de gerenciamento de portfólio e por facilitar re-
visões de portfólio por nosso "Conselho de Investimento ". Separamos intencionalmente os
processos de solicitação e avaliação de projetos (aprovação de projetos, em princípio) e o
trabalho de autorização (entrada no portfólio ativo).
' lbid., p. 22- 23.

Quando solicitado a descrever a relação do PMO com o gerenciamento de portfó-

lio, Chuck M ill hollan comentou:
Conselho de Investimento: O Conselho de Investimento é formado por membros sênior (vo-
tantes) (CEO, COO, CFO, VPEs) e representantes de cada unidade de negócios. Há reuniões
mensais frequentes, facilitadas pelo Plv!O, para revisar e aprovar novas solicitações e para
revisar o portfólio ativo. As metas e objetivos do Conselho de Investimento incluem:
1. Priorizar e aloca r capita l aos projetos.
2. Aprovar/Não aprovar projetos selecionados com base no mérito do Caso de Negócio
associado.
3. Agir indiv id ua l e coletivamente como defensores convictos e visíveis de projetos em
todas as s uas organizações representantes.
4. À medida que for necessário, assumir um papel ativo na aprovação de deliverables, aju-
dando a resolver problemas e decisões de políticas e oferecendo orientação relativa ao
pro1eto.
Solicitação, avaliação e aprovação: Usa mos uma "Planilha de Solicitação de Investi-
mento" para padronizar o formato e m que os projetos (chamados de solicitações de inves-
timento) são apresentados ao Conselho de Investimento. Elementos incluem descrição da
solic itação, critérios de sucesso e métricas associadas, descrição do estado a tual e fut uro,
a linhamento a metas estratégicas, avaliação preliminar de riscos, ident ificação de projetos
dependentes, d isponibi li dade preli mina r de recursos e ava li ação de restrições, além de
aná lise de pagamento para inicia tivas de ROi e eliminação de c ustos que não geram valor
(cost-out).
Autorização de Trabalho: Se os projetos foram aprovados d urante os processos anuais
de planejamento operacional e são investimentos de capital que geram ROi o u resultam em
um cost-out, volta m ao Conselho de Investimento para autorização de trabalho e adição
ao portólio de projetos ativos. Isso pode ser feito concomitantemente com a solicitação, a
avaliação e a aprovação de projetos q ue são iniciados no meio do ciclo de planejamento.
Manutenção de portfólio: Usamos um processo de relatório de status de projetos quin -
zenais e somente incluímos p rojetos que o Conselho de Investimento tenha identificado
como projetos q ue necessita m de revisão de portfólio e/ou supervisão. Os relatórios de
portfólio são fornecidos q uinzenalmente e apresentados mensalmente durante as reuniões
do Conselho de Investimento.
Quando o PMO apoia ou faci lita o processo de gerencia tnento de portfólio, ele se
torna um pa rticipa nte ativo no p rocesso de pla neja tnento estratégico e apoia a gerên-
cia sênior, garanti ndo que os projetos que estão na fi la sejam alinhados aos objetivos
estratégicos. O papel pode ser apoia r ou 1nonitorar e controlar. Enr ique Sevi lla Moli-
na, PMP®, antigo d iretor do PMO corporativo da lndra, d iscute o gerencia mento de
portfólio em sua organizaç.ã o:
O gerenciamento de portfólio é fortemente orientado a monitorar e controla r o desempe-
nho do portfólio e a revisar seu a linhamento com o planejamento estratégico. Real iza-se
também uma a nálise periódica cuidadosa das tendências e previsões, de modo q ue a compo-
sição do portfólio possa ser avaliada e reorientada, se necessário.
Uma vez q ue os a h•os estratégicos do portfólio tenham sido definidos e a locados pelos
diferentes n íveis da o rganização, o principal loop do processo inclui gerar relatórios, revisar
e agir em relação a desempenho do po rtfólio, problemas, riscos, prev isões e p lanejamento
de novos contratos. Um conjunto de alertas, semáforos e indicadores foram definidos e
a utomatizados a fim de focalizar a atenção sobre os principais problemas relacionados ao
gerenciamento de portfólio. Os projetos ou propostas q ue forem marcados como precisan-
do de atenção específica serão cuidadosamente acompanhados pela equipe de gerência, e
um relatório de status específico é gerado para eles.
Uma das principa is ferramentas usadas para [o] processo de gerenciamento de portfólio
é nosso !vlonito r de Projetos. Essa é uma ferramenta baseada na web que fornece uma visão
total do status de q ua lquer conjunto predefin ido de projetos (ou portfólio), incluindo dados
gerais, dados de desempenho, indicadores e semáforos. Ela possui também a capacidade de
produzir d iferentes tipos de relató rios, no nível do projeto individua l, no nível do portfólio
o u um relatório especializado de riscos para o portfólio sele.cionado.
Além do PMO corporativo, as principais Unidades de Negócios de toda a empresa usam
PMOs locais em seu processo de gerenciamento de portfólio. Alguns deles são encarrega-
dos dos relatórios de status de riscos para os projetos mais importantes ou programas do
portfólio. Alguns são encarregados de uma definição inicial do nível de risco dos projetos e
operações para fornecer uma detecção precoce de áreas de risco potenciais. Outros desem-
penham um papel significativo em fornecer o suporte específico aos gerentes de portfólio ao
relata r o status à gerência de nível superior.
Nosso PMO de nível corporativo define os p rocessos de gerenciamento de portfólio a
fim de ser consistente com o nível da gestão de projetos e, consequentemente, com as exi-
gências para a implementação desses processos nas ferramentas e sistemas de informação
da empresa.
Algumas e1npresas real izam o gerenciamento de portfólio sem envolvimento do
PMO. Isso é bastante comum quando esse processo pode inclu ir uma grande quanti-
dade de projetos que desembolsam capital. Segundo um porta-voz da AT&T:
Nosso PMO não faz parte do gerenciamento de portfólio. Mantemos um Escritório de Ad-
ministração de Portfólio (PAO, Por/fo lio Administration Of(ice), q ue aprova os principais
projetos e programas que desembolsam capital por meio de um processo de planejamento
anual. O PAO utiliza o controle de mudanças para q ualquer modificação feita na lista de
projetos aprovados. Cada gerente de projetos precisa acompanhar os detalhes de seu proje-
to e atualizar as informações da Ferramenta de Administração de Portfólio (PAT, Port(o/io
Admi11istratio11 Too/). O Escritório de Programas Corporativo usa dados contidos na PAT
para monitorar a saúde e o bem-esta r dos projetos. Projetos individua is são auditorados
para garantir aderência a processos e preparam-se relatórios para acompanhar seu progres-
so e status.
6
14.3 Obstáculos à seleção de projetos
Os tomadores de decisões do gerenciamento de portfólio freq uentemente têm muito
menos informação para avaliar projetos candidatos do que gostariam. Incertezas sempre
rodeiam a probabilidade de sucesso de um projeto, seu valor de mercado final e seu cus-
to total até a conclusão. Essa fa lta de uma base de informações adequadas geralmente
leva a uma outra d ificu ldade: a falta de uma abordagem s istemática da seleção e avalia-
ção de projetos. Os critérios e métodos consensuais para ava li ar cada projeto candidato
em relação a esses critérios são essenciais para a tomada de decisões racional. Embora
a maioria das empresas tenha estabelecido metas e objetivos organ izacionais, estes nor-
ma lmente não são s uficientemente detalhados para serem usados como critérios para a
tomada de decisões de gerenciamento de portfólio de projetos. Entretanto, são um ponto
de partida essencial.
As decisões do gerenciamento de portfólio geralmente são confundidas por vários fato-
res comportamentais e organizacionais. Fidelidades departamentais, conflitos nos desejos,
d iferenças de perspectivas e uma indisposição a compartilhar informações abertamente po-
dem prejud icar os processos de seleção, aprovação e avaliação de projetos. Grande parte
dos dados e informações de projetos é necessariamente subjetiva por natureza. Assim, a
d isposição das partes de compartilhar abertamente e confiar nas opin iões uns dos outros se
torna um fator importante.
O cl ima ou a cultura de uma organização em relação a riscos também pode ter uma
influência decisiva no processo de seleção de projetos. Se o cl ima for de aversão a riscos,
' \Y/. Souder, Projec.r Selectfon and Eam.omic Appraisal, New York: Van Nostrand Reinhold, 1984, p. 2- 3.
projetos de alto risco podem n unca vir à to na. As atitudes na organ ização em relação a
ideias e o volume de ideias gerado influenciam a qualidade dos projetos selecionados. Em
geral, q uanto ma io r o número de ideias criativas geradas, maiores as chances de selecionar
projetos de a lta q ualidade.
14.4 Identificação de projetos

O p rocesso geral de gerenciamento de portfól io de projetos é uma abordagem com
quatro passos, como most ra a Figu ra 14-2. O pri mei ro passo é a identificação das
ideias de p rojetos e das necessidades de ajudar a oferecer suporte ao negócio. A iden-
tificação pode ser feita por meio de sessões de brainstorming, pesquisa de mercado,
pesquisa de clientes, pesqu isa de fo rnecedores e buscas na literatura . Todas as ideias,
independentemente de seu mérito, deve1n ser listadas.
Como o número de ideias potenciais pode ser grande, é necessário algum tipo de
sistema de classificação. Há t rês métodos com uns . O primeiro consiste em colocar os
projetos em duas pri ncipais categorias, como sobrevivência e crescimento. As fontes
e tipos de fundos para essas duas categorias podem ser e serão diferentes. O segundo
método ve1n dos modelos de planejamento estratégico típicos da P&D, como mostra
a Figura 14-3. Usando essa abordage1n, projetos para desenvolver novos produtos
ou serviços são classificados como ofensivos ou co1no defensivos. Projetos ofensivos
são criados pa ra captar novos mercados ou expandir a fração de mercado dentr o dos
mercados existentes. Os p ro jetos ofensivos detenninam o desenvolvi1nento contínuo
de novos produtos e serviços.
Os projetos defensivos são criados para amplia r a vida de produtos o u serviços
existentes. Isso pode incluir add-ons o u aprimoramentos voltados a 1na nter os clientes
atuais ou acha r novos clientes para produtos ou serviços existentes. Os projetos de-
fensivos normalmente são mais fáceis de gerencia r do que os projetos ofensivos e têtn
uma proba bilidade mais alta de sucesso.
Identificação de
projetos
Identificar necessidades
! . _ _e fontes de ideias
Planejamento estratégico Avaliação prelim inar

Gerenciamento
Análise de mercado, Estudos de viabilidade/
de portf611o
competitividade e disponi- Análises custo-benefício
de projetos
bilidade de recursos e critérios de avaliação
Seleção estratégica de
projetos \
Adequação e
priorÍZação estratégica
Figura 14-2 Processo de seleção de projetos.

1 Análise ambiental
Forças, fraquezas, oportunidades e ameaças

Forças competitivas
Metas de P&D, objetivos e estratégias
Suporte aos produtos atuais Suporte a novos produtos
P&D defensiva P&D ofensiva
Penetrar em Ampliar mercados Penetrar em Ampliar mercados

novos mercados existentes novos mercados existentes
Avaliação e seleção de projetos de P&D
Integração ao plano estratégico
Figura 14-3 Processo de planejamento estratégico da P&D.
Estado corrente da "última geração"
Solução
por meio
de adoção
Depuração do
Experimentação protótipo e au- Comercialização
e cálculo mento de escala
Solução
por meio
da invenção
Reconhecimento Formulação de Solução de Solução/criação

Comercialização
de problema ideia e avaliação problemas de protótipos
Figura 14-4 Modelagem do processo de inovação.
Projetos de descobertas tecnológicas radicais são os mais difíceis de gerenciar de-

vido à necessidade de inovação. A Figura 14-4 mostra um típico modelo de inovação.
Os projetos de inovação, se bem-sucedidos, podem levar a lucros muitas vezes maiores
do que os custos originais de desenvolvi1nento. Projetos de inovação malsucedidos
podem levar a perdas igua lmente drásticas, o que é um dos motivos pelos quais a
gerência sênior precisa exercer o devido cuidado ao aprovar projetos de inovação.
Deve-se tomar cuidado para identificar e eli1ninar projetos candidatos inferiores antes
de comprometer recursos significativos com eles.
Não há dúvida de que os projetos de inovação sejam os ma is caros e d ifíceis de
gerenciar. Algumas empresas erroneamente acreditam que a solução seja minimizar ou
limitar o número total de ideias de novos projetos ou lim itar o número de ideias e1n
cada categoria. Isso poderia ser um erro oneroso.
Em u1n estudo sobre as atividades de novos produtos de várias centenas de empre-
sas e1n todas as indústrias, Booz, Allen e Hamilton' definiram o processo de evolução
de novos produtos como o tempo necessário para se levar u1n produto até a existência
comercia l. Esse processo co1neçava com objetivos da empresa, que incluíram ca tnpos
de interesse, metas e planos de crescimento de produtos, e terminava, esperava-se, e1n
um produto bem-sucedido. Quanto mais especificamente esses objetivos fossem defi-
nidos, maior orientaç.ã o seria dada ao progra1na do novo produto. Esse processo foi
deco1nposto em seus etapas sequencia is gerenciáveis e bastante claras:
• Exploração : A busca por ideias de produtos que atendam os objetivos da empresa.
• Triagetn: Uma aná lise rápida para determinar qua is ideias era 1n pertinentes e me-
reciam um estudo mais detalhado.
• Análise de negócio: A expansão da ideia, por meio da anál ise criativa, em uma
reco1nendação de negócio concreta, incluindo elementos do produto, anál ise fi-
nanceira, análise de riscos, ava liação de mercado e um programa para o produto.
• Desenvolvimento: Transforma r a ideia no papel em um produto nas 1nãos, de-
monstrável e produzível. Essa etapa foca liza-se na P&D e na capacidade inventiva
da empresa. Quando surge1n problemas imprevistos, buscam-se novas soluções e
trade-offs. Em muitas situações, os obstáculos são tão grandes que não se conse-
gue encont rar uma solução, e o traba lho é term inado ou adiado.
• Testes: Os experimentos técnicos e comercia is necessários pa ra verificar julgamen-
tos técnicos e de negócios anteriores.
• Comercialização: Lançar o produto em produção e venda em grande escala; inves-
tir recursos e a reputação da empresa.
No estudo de Booz, Allen e Ham ilton, o processo de novos produtos foi carac-
terizado por uma curva de decaimento representando as ideias, como most ra a Fi-
gura 14-5. Isso most ra uma rejeição progressiva de ideias ou projetos por etapas do
processo de evolução do produto. Embora a taxa de rejeição varie entre indústrias e
empresas, a forma geral da curva de deca imento é típica. Gera lmente é preciso cerca de
60 ideias para gerar apenas um novo produto be1n -sucedido.
O processo da evoluç.ã o de novos produtos envolve uma série de decisões de ge-
renciamento. Cada etapa é progressivamente mais cara, medida em gastos tanto de
tempo quanto de d inheiro. A Figura 14-6 most ra a taxa segundo a qual as despesas
são gastas à medida que o tempo passa para o projeto típico dentro de uma amostra
de empresas líderes. Essas informações baseiam-se em uma média de toda a indústria e
são, portanto, útil para compreender o processo indust ria l típico de novos produtos. É
importante observar que a ma ioria das despesas de capita l estão concentradas nas três
últimas etapas de evolução. É, portanto, muito importante melhorar a triagem para a
análise de negócios e financeira. Isso ajudará a elim inar ideias de potencia l limitado
antes de elas chegarem às etapas mais caras da evolução.
1
Managemenr o/ Neru Products, Boo2., Allen e Hamilton, X'1cl ean, VA, 1984, p. 180- 181 .
60
~ ----+---
I --t-----1-
1 1--------1--1----1-----
1 1-----1---
1 1 ...............
1 -1------1-
1 1
-
.!!?
-8
15
Triagem
~ 1- Análie de
"'
'O negó io u novo p oduto
~ 10 be ·Suced do
E ,....._ Des nvolvi ento stes
,::,
2
5 merc1a açao
i
o
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Tempo cumulativo
Figura 14-5 Mortalidade das ideias de novos produtos.
~
~-
ê cê 100% t-- - . - - , - - , - - - - , - - , - - - . - - . - - - , - - , - --,,-
::, e.
~~ 90% 1-- + - -1--+---t--+ - -+--i---l---t-,-,
1o "'
~ ~ 80% ~ - - 1 - - - 1 - --1-- --4---1-----1----1-- ---1-- -/"
.E?o
!º•_g Totl .::o;;s~o,1----4~/r
70% ~ - - 1 - - - 1 - - - 1 - -- - 4 - - + , = de
-
~ !;; 60% 1--
"'~ ~
+ - -1--+----+--+-- ---+--+----ID
50% t--+---;--+--t--+---+---::a-'
-"' --"'
~ -~ 40% 1--i--t--+--+--+,,--~
"' e.
'O "'
-
30%
- õ -8 20%
- -
o 'O
'O "'
10%
"' e
::, "'
e= 0%
CI,) -
~
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
"'
"- Tempo cumulativo
•I• •I• •I
Triagem Análise de Desenvolvimento Testes Comercialização
negócio
Figura 14-6 Despesas cumulativas e tempo.
14.5 Avaliação preliminar

Con10 n1ostra a Figu ra 14- 2, o segundo passo na seleção de projetos é un1a ava-
liação prel iminar. De uma perspectiva financei ra, a aval iação p reliminar é basica-
mente um processo em duas partes. Prin1ei ro, a organização conduzirá um est udo
de viab ilidade para determinar se o projeto pode ser rea lizado. A segunda parte é
realizar uma aná lise de custo-benefício para verificar se a en1presa deveria realizá-
-lo (ver Tabela 14- 1).
A fina lidade do estudo de viabi lidade é confirmar se a ideia do projeto atende as
exigências de viabilidade em termos de custo, tecnologia, segurança, perspectiva de
TABELA 14-1 Estudos de viabilidade e análises custo-benefício
Estudo de viabilidade Análise custo-benefício

Pergunta fundamental Podemos realizá-lo? Devemos realizá-lo?
Fase do ciclo de vida Pré-conceituai Conceituai
Gerente de projetos selecionado? Ainda não Talvez
Análise O ualltatlva Quantitativ a
Técnica VPL
Custo Fluxo de caixa descontado (FCD)
Qualidade TIA
Segurança ROi
Jurídica Premissas
Econômica Realidade
Critérios de decisão Adequação estratégica Benelfcios > Custos
comercialização e facilidade de execução. É possível para a empresa usar consu lto-

res externos ou sujeita r especialistas no assunto para auxiliar tanto nos estudos de
viabilidade quanto nas análises de custo-benefício. Um gerente de projetos pode não
ser designado até depois de o estudo de viabilidade estar concluído, pois o gerente de
projetos pode não ter conhecimento suficiente de negócios ou técnico para cont ribuir
antes de.sse momento.
Se o projeto for considerado viável e adequado ao plano estratégico, ele será prio-
rizado para desenvolvimento com outros projetos aprovados . Uma vez que a viabi li-
dade tenha sido detenninada, realiza-se uma análise de custo-benefício para confirmar
se o projeto irá, se executado corretamente, fornecer os benefícios financeiros e não
financeiros necessários. Análises de custo-benefício exigem significativamente mais
informações a serem exam inadas do que normalmente está d isponível durante utn
estudo de viabi lidade. Essa pode ser u1na proposição onerosa.
Estimar benefícios e custos de maneira rápida é muito difíci l. Os benefícios geral-
mente são definidos como:
• Benefícios tangíveis, para os quais os dóla res podem ser razoavelmente quantifi -
cados e medidos
• Benefícios intangíveis, que podem ser quantificados em unidades diferentes de dó-
lares ou podem ser identificados e descritos su bjetivamente
Os custos são sign ificativamente mais difíceis de quantificar, pelo menos de ma-
neira rápida e barata. Os custos mínimos que devem ser detenninados são aqueles que
são usados especificamente para comparação com os benefícios. Eles incluem:
• Os custos operacionais correntes ou o custo de operação nas circunstâncias de
hoje.
• Custos de períodos futuros, que são esperados e que podem ser planejados com
antecedência.
• Custos intangíveis, que podetn ser difíceis de quantificar. Esses custos geralmente
são omitidos se a quantificação puder cont ribuir um pouco com o processo de
tomada de decisões.
É necessário que haja uma cuidadosa documentação de todas as restrições e pre-
missas conhecidas que foram feitas ao desenvolver os custos e benefícios. Prem issas
não realistas ou não reconhecidas normalmente são a causa de benefícios não realistas.
A decisão de continuar/não continuar com um p rojeto pode mui to bem depender da
validade das prem issas.
14.6 Seleção estratégica de projetos

Como vemos na Figura 14-2, o terceiro passo do processo de seleção de projetos é a
seleção estratégica de yrojetos, o que inclui a determinação de uma adequação estra-
tégica e priorizaç.ã o. E nesse ponto que o envolvimento da gerência sên ior é crucial,
devido ao impacto que os projetos podem ter sobre o plano estratégico.
O p lanejamento estratégico e a seleção estratégica de projetos são sim ilares no
sentido de que ambos lidam com os lucros e o cresci tnento futuro da organização. Sem
utn fluxo contínuo de novos produtos ou serviços, as opções de planejamento est ra-
tégico da empresa podem ser limitadas. Hoje, os avanços tecnológicos e a crescente
pressão cotnpetitiva estão forçando as empresas a desenvolverem produtos novos e
inovadores enquanto o ciclo de vida dos produtos existentes parece estar di1n inuindo
a taxas alarmante.s. Contudo, ao mesmo tempo, os executivos podetn manter grupos
de pesquisas "no vácuo" e deixar de tirar proveito da potencial cont ribuição de lucros
do planejatnento estratégico e seleção de projetos de P&D.
Há três principais motivos pelos quais as corporações t raba lham em projetos in-
ternos:
• Produzir novos produtos ou serviços para o crescimento lucrativo
• Produzir mel horias lucrativas a produtos e serviços existentes (i.e., esforços de
redução de custos)
• Produzir conhecimento científico que auxil ie na identificação de novas oportuni-
dades de resolver proble1nas emergencia is
Uma seleção de projetos bem -sucedida é direcionada, mas o direcionamento exige
utn botn sistema de informações e isso, infeliztnente, é o lado mais fraco na maioria
das empresas. Os sistemas de informação são necessários para a otimização dos esfor-
ços de direciona tnento, e isso incluir avaliar as necessidades do cliente e do mercado, a
realização de avaliações econôtn icas e a seleção de projetos.
Avaliar as necessidades do cl iente e do tnercado envolve as funções de busca de
oportun idades e intel igência comercial. A maioria das empresas delega essas respon-
sabi lidades ao grupo de marketing, e isso pode resultar em utn esforço prejudicial,
pois os grupos de marketing parecem estar ocupados com os produtos de hoje e com
a lucratividade no curto prazo. Eles si1nples1nente não têm o tempo ou os recursos
necessários para ana lisar adequadamente out ras atividades que têm implicações de
longo prazo. Além disso, os grupos de marketing podetn não ter pessoal tecnicamente
t reinado que possa se comunicar eficientemente com os grupos de P&D dos cl ientes e
fornecedores.
A maioria das organizações estabelece critérios de seleção de projetos que podem
ser subjetivos, objetivos, quantitativos, qualitativos ou simplesmente um bom de um
pa lpite. Os critérios de seleção se baseiam, na 1na ioria das vezes, etn critérios de ade-
quaçao, como:
• É si1n ilar em tecnologia
• É si1n ilar nos 1nétodos de 1narketing empregados
• É si1n ilar nos canais de distribuição empregados
• Pode ser vendido pela força de vendas atual
• Será comprado pelos mestnos clientes dos produtos atua is
• Adequa-se à filosofia ou imagem da empresa
• Utiliza o know-how ou experiência existentes
• Adequa-se às instalações de produção atuais
• Deixa o pessoa l tanto de pesquisa quanto de marketing entusiasmado
• Adequa-se ao plano de longo prazo da empresa

• Adequa-se às metas de lucro atuais
De qua lquer forma, deve haver um motivo válido para selecionar o projeto. Os
executivos responsáveis pela seleção e priorização geralmente buscam a opinião de
outros executivos e gerentes antes de ir adiante. Uma maneira de buscar opiniões de
maneira rápida e razoável é transformar os critérios de adequação exibidos acima em
modelos de pontuação. Modelos de pontuação típicos são exibidos nas Figuras 14-7,
8
14-8 e 14-9. Esses modelos podem ser usados tanto para a seleção estratégica quanto
para a pnonzaçao.
.,,
~
.,, ~
.,, o
.,, "= "e: =~ .,,
~
~
~ :ei
~li =-
~
Critérios > ..,

~
~ .g
-=
~ = i~ N
=
Pesos dos cnténos

u
~
4
fJ
Q.
~ ~
~o
u -1
"8
Q.
1 Ponluação
3 2
tola!
Proietos Pontuação dos critérios• ponderada
Projelo D 10 6 4 3 69
Projeto E 5 10 10 5 75
Projeto F 3 7 10 10 63
Pontuação total ponderada= r (Ponluação do critério x Peso do critério)

• Escala: 10=Excelente; 1=1naceltável
Figura 14-7 Modelo de pontuação.
.
a,
CD~
o
!;!" ..
Critérios
.
'C
..
'C 'C
.. .ti .. o
>-
-
-.-
'C ;:
"S u- :'2 "'
u
...,
=
.. u
Q.
t! E
8?. 8
a; :e
..
""
l'l
=
e .,
a.
..
'C
Ponluação
Projelos 2 1 3 2 1
total
Proielo A J 7
J J JI 6
J J J 3
Figura 14-8 Lista de verificação para três projetos.
1
W. Souder, Project Selec.tion and Eamomic Appraisal, New York: Van Noscrand Reinhold~ 1984, p. 66-69.
Escala
Legenda:
+2 = Excelente
+1 = Bom
O= Aceitável
- 1 = Ruim
- 2 = Inaceitável
-
Não aplicável
><
Ponhlação do proJeto A
Processab,lidade
..........
- Know-ho. . - -
01spon1b1tidade de eQuipamentos
NúmeíO de Xs
Figura 14-9 Modelo de dimensionamento para um projeto, o projeto A.
A priorização é u1n processo difíci l. Fatores como fluxo de caixa, lucratividade no

cu rto prazo e expectativas das partes interessadas precisam ser considerados. São tam-
bém consideradas diversas forças ambienta is, como as necessidades do cliente, com-
porta1nento competitivo, tecnologia existente ou prevista e políticas governamentais.
Ser ext remamente conservado r durante a seleção e priorização de projetos
pode ser un1 convite a desast res. As empresas com produtos industriais altamente
sofisticados têm de buscar un1a abordagem agressiva para a seleção de p rojetos ou
sofrerão riscos de obsolescência. Isso tan1bén1 determina o suporte de un1a forte
base técnica.
14.7 Planejamento estratégico

Muitas organizações cometetn o erro fatal de assumir projetos demais sem considerar
a dispon ibilidade lim itada de recursos. Consequentemente, os t raba lhadores ext rema-
mente qualificados são designados a ma is de um projeto, criando atrasos no cronogra-
ma, menor produtividade, lucros menores do que os previstos e conflitos intermináveis
ent re os proJetos.
A seleção e a priorização de projetos têm que ser feitas com base na dispon ibil i-
dade de recursos qua lificados. Há modelos de planejamento disponíveis para ajudar
com o planejamento estratégico de recursos. Esses modelos gera lmente são chamados
de modelos de planeja,nento agregado.
Um out ro problema com o p lanejamento estratégico é a determinação de que
projetos exijam os melhores recursos. Algumas empresas usam um cubo de risco-
· reco1npensa, no qual os recursos são designados com base na relação entre risco e
recompensa. O problema dessa abordagem é que o tempo necessário para alcançar os

benefícios (i.e., período de recuperação do investimento) não é considerado.
Os modelos de planejamento agregado permitem que uma organização identifi -
que a sobrecarga de recursos. Isso poderia significar que os projetos de alta prioridade
podem precisar ser adiados a tempo ou possivelmente el iminados da fila devido à falta
de dispon ibi lidade de recursos qua lificados. É uma pena que as empresas també1n
desperdicem tempo considerando projetos para os quais elas sabem que a organização
não possui os talentos adequados.
U1n outro co1nponente essencial desse planejamento é o nível de tolerância a riscos
da organização. Nesse caso, o foco é sobre o nível de risco do portfól io, em vez de o
nível de risco de um projeto individual. Os tomadores de decisões que compreendem a
gestão de riscos podem, então, designa r recursos eficientemente, de modo que o risco
de portfólio seja mitigado ou evitado.
14.8 Analisando o portfólio

As empresas que são organizações voltadas para projetos precisam ser cuidadosas
quanto ao tipo e à quantidade de projetos e1n que elas tra ba lham, devido aos recur-
sos disponíveis. Devido a questões de tempo, ne1n sempre é possível contr atar novos
funcionários e treiná-los a tempo ou cont ratar empresas subcontratadas que pode1n
acabar possuindo habi lidades questionáveis.
9
A Figura 14-10 mostra u1n típico portfólio de projetos. Cada círcu lo representa
um projeto. A loca lização de cada círcu lo representa a qualidade dos recursos e a fase
Qualidade dos recursos

Alta Média Baixa
Definição ()A
Fases
do ciclo Desenvolvimento ~ D
de vida
Implementação
Conversão
Figura 14-10 Típico portfólio de projetos.
' Esse ripo de portfólio foi adaptado do modelo de ciclo de vida de portfólios normalmeme utilizado para as
atividades de planejamento estratégico.

Alta Média Baixa
Definição
Design
Fases
do ciclo Desenvolvimento
de vida
Implementação
Conversão
Figura 14-11 Portfólio de alto risco.
do ciclo de vida em que o projeto se encontra. O tamanho do círculo representa a mag-

nitude dos benefícios em relação a out ros projetos, e a "fatia da torta" representa o
percentua l do projeto concluído até o 1no1nento. Na Figura 14-10, o Projeto A possui
benefícios relativamente ba ixos e usa recursos de qua lidade média. O Projeto A está
na fase de definição. Entretanto, quando o Projeto A passa para a fase de design, a
qual idade dos recursos pode 1nudar para baixa ou para alta.
Portanto, esse tipo de gráfico deve se r atualizado com frequência. As Figuras
14- 11, 14- 12 e 14-13 mostram três tipos de portfólios. A Figura14-11 representa
un1 portfól io de projetos de a lto risco no qual são necessários recursos fo rtes en1
cada projeto . Isso pode ser representativo de organizações orientadas a projetos
que receberam projetos grandes e ext remamente lucrativos. Poderia tambén1 ser
un1a empresa no ramo de computação que compete em uma indústria que possui
ciclo de vida de produto curtos e na qua l a obsolescência de p rodutos ocorre seis
meses a Jusante.
A Figura 14- 12 representa um portfólio lucrativo conservador, caso em que uma
o rganização trabalha cotn projetos de baixo r isco que exigem recursos de baixa qua-
lidade. Isso poderia ser representativo de um processo de seleção de portfólio de pro-
jetos etn u1na organ ização de serviços ou mestno em uma empresa de manufatura que
tenha projetos criados, em sua maioria, para o aprimoramento de produtos.
A Figura 14- 13 1nostra um portfólio equi librado com projetos em cada fase do
ciclo de vida e no qual todos os níveis de recursos estão sendo utilizados, normalmente
de forma bastante eficiente. É necessário um 1nalabarismo muito delicado para manter
esse equilíbrio.
14.9 Problemas em atender as expectativas

Por que, muito frequentemente, os resultados fina is de um projeto ou de um portfólio
inteiro não alcançam as expectativas da gerência sênior? Esse problema aflige 1nuitas
corporações, e a culpa é, etn últi tna análise (e muitas vezes erroneamente) racionaliza-
da cotno práticas ruins de gestão de projetos. Como um exemplo, uma empresa apro-
vou um portfólio de 20 projetos de P&D para 2001. Cada projeto foi selecionado por
sua capacidade de ser lançado cotno um novo produto bem-suced ido. As aprovações

Alta Média Baixa
Definição
Design
Fases
do ciclo Desenvolvimento
de vida
Implementação
Conversão
1 1.
Figura 14-12 Portfólio lucrativo.
Fases
do ciclo
de vida
Figura 14-13 Portfólio equilibrado.
foram feitas depois da conclusão de estudos de viabi lidade. Orçamentos e cronogra-

mas foram, então, estabelecidos de tal modo que os fluxos de caixa do lançamento dos
novos produtos respaldassem os d ividendos e o caixa necessário para o andamento
das operações.
Gerentes de projetos trabalhando em regime de tempo integral foram designados
a e.ada um dos 20 projetos e co1neçara1n com o desenvolvimento de cronogramas e
planos de projetos detalhados. Para o ito dos projetos, tomou-se rapida1nente eviden-
te que as restrições financeiras e de geração de cronogramas impostas pela gerência
sênior não eram realistas. Os gerentes de projetos desses oito projetos decid iram não
informar à gerência sênior sobre os problemas potenciais, mas esperar um pouco para
ver se poderiam-se estabelecer p lanos de contingência. Sem ouvir nenhu1na má notícia,
a gerência sênior ficou com a impressão de que todas as datas de lançamento eram
realistas e sa iriam co1no p lanejadas.
Os o ito projetos proble1náticos estavam passando por dificuldades. Depois de
exaurirem todas as opções e não vere1n um 1nilagre, os gerentes de projetos, então,
informaram relutantemente a gerência sênior de que suas expectativas não seria aten-
d idas. Isso ocorreu tão tarde no ciclo de vida dos projetos que a gerência sênior ficou
bastante irritada e vários funcionários foram demitidos, inclusive a lguns dos patroci-
nadores de projetos.
Várias lições podem ser aprendidas co1n essa situação. Primeiro, expectativas não
realistas ocorrem quando a análise financeira é realizada a partir de dados infonnais
e1n vez de forma is. Na Tabela 14-1, 1nost ramos as diferenças entre um estudo de via-
bilidade e uma aná lise de custo-benefício. De modo geral, os estudos de viabi lidade
baseiam-se e1n dados informais.
Portanto, os resultados de decisões financei ras cruciais baseadas en1 esn1dos de
viabilidade podem conter erros sign ificativos. Isso também pode ser observado na
Tabela 14-2, que ilust ra a precisão de estimativas típicas. Estudos de viabi lidade
usan1 estimativas descendentes (top-down), que podem conter margens de erros sig-
nificativas.
As aná lises de custo-benefício devem ser conduzidas a partir de planos de projeto
detalhados usando estimativas ma is definitivas. Os resultados da análise de custo-
-benefício devem ser utilizados para confirmar se os a lvos financeiros estabelecidos
pela gerência sên ior são realistas.
Mesmo com os melhores planos de projeto e com aná lises de custo-benefício
abrangentes, ocorrerão mudanças de escopo. É preciso haver u1na reesti1nação perió-
d ica das expectativas, realizada em tempo oportuno. Uma 1naneira de fazer isso é usar
o concei to de ondas sucessivas exibido na Figura 14-14. O conceito de ondas sucessi-
vas implica que, se você for adiante no projeto, ma is conhecimentos serão obtidos, o
que permitirá realizar uma estimativa e um p lanejamento mais detalhados. Estes, por
sua vez, fornecem infonnações ad icionais a partir das quais podem-se confirmar as
. .
expectativas ong1na1s.
A reavaliação contínua das expectativas é crucial. No início de um projeto, é im-
possível garantir que os benefícios esperados pela gerência sênior sejam realizados
na conclusão do projeto. A duração do projeto é um fator crucial. Dependendo da
duraç.ã o, mudanças de escopo podem resultar em um redirecionamento do projeto. O
cu lpado é, na maioria das vezes, mudanças nas condições econô1n icas, resultando em
premissas originais invá lidas. Além disso, a gerência sênior precisa tomar ciência dos
eventos que possam alterar as expectativas. Essas informações têm de ser disponibi-
TABELA 14-2 Estimativas de custo/hora

Tipo Tempo para
Método de estimação genérico Relação com a EAP Precisão preparar
Paramétrico OGA' Descendente (top-down) 25% a+ 75•;. Dias
Analogia Orçamento Descendente (top-down) - 10% a+25% Semanas
Engenharia (de base) Definitivo Ascendente (bottom-up) - 5°/o a + 10% Meses
•ordem de grandeza aproximada.
MESES DEPOIS DA DECISÃO DE CONTINUAR

1 2 3 4 5 6 7 8 9 10 11 12 13 14
~ --E_A_P_N_ív_E_
L_s_ _ ~l~____ EA
_P_N
_í_
v E_L_2_ _ _ ~
EAP NÍVEL 5
li EAP NÍVEL 2
EAP NÍVEL 5 li EAP NÍVEL 2
Figura 14-14 Conceito de ondas sucessivas.
lizadas rapidamente. A gerência sênior deve estar disposta a ouvi r 1nás notícias e ter
coragem de possivelmente cancelar um projeto.
Como as mudanças podem alterar as expectativas, o portfól io de gestão de pro-
jetos precisa ser integrado ao processo de gerencia mento de mudanças do projeto.
Segundo Mark Forman, diretor associado de TI e governo elet rônico (e-government)
do escritório de gerenciamento e orçamento:'º
Nluitas agências deixam de transformar seu processo de gerenciamento de TI usando um
processo de gerenciamento de portfólios por não terem um gerenciamento de mudanças em
vigor antes de começarem. A TI não resolve problemas de gerenciamento - são os processos
de reengenharia que o fazem . As agências devem treinar seu pessoal para abordar os proble-
mas c ulturais. Elas precisam perguntar se seu processo é um processo simples. Um plano de
gerenciamento de mudanças é necessá rio. É a í q ue a visão e a direção da gerência sênior é
extremamente ne.cessária nas agências.
Embora os comentários aqui sejam das agências de TI do governo, o proble1na
ainda é de extrema importância em organizaçôes não governamenta is e em todas as
indústrias.
14.10 Gerenciamento de portfólio

11
na Rockwell Automation
A Rockwell Automation implemento u um processo de gerenciamento de portfólio em seu
Grupo de Arquitetura e Software. As metas e a fina lidade do processo são ligar investimen-
tos à nossa estratégia de negócio, maximizar o valo r do portfólio, alcançar um equilíbrio
(mix ) desejado de projetos e focalizar-se nos esforços da organização. O processo de Geren-
c iamento de Portfólio coloca o foco estratégico sobre como gerencia mos nossos investimen-
tos tornando-se parte integral de nosso processo de planejamento. Trata-se de as pessoas
chegarem a um consenso usando dados confiáveis, e uma estrutu ra comu m de tomada de
decisões. O Processo de Gerenciamento de Portfólios associa-se a processos relacionados
como Gerenciamento de Ideias, Desenvolvimento de Estratégias, Gerenciamento de Pro-
gramas e Projetos e nosso recém-implementado Processo Comum de Desenvolvimento de
Produtos. (Ver Figura 14- 15.J
0
' Ver nora t, p. 2.
11
Esta seção sobre a Rockwell Auromarion foi fornecida por James C. Brown, PgN1P, PMr• , OP!v13 AC,
MP!vl, CIP!vl, CSP, CSSMBB, diretor, escritório de gerenciamento de programas empresarial da A&S; Karen
Wojala, gerente de planejamento de negócios; e Matt Stibora, gereme de empreendimentos enxutos.
u,
CD
O)
G)
(1)
!!l
""e.
o
(1)
"O
.2.
(1)
g
Proposição
de valor
Visão
Estratégia
. .1corporativa Metas
estratégicas
1• Alinhamento l+-+t
estratégico Governança
ReuniDes de revisão de propostas Reuniões de revisão de port161io
Proposta de Aprovação
investimento 1 •I Avaliação Prorização
do port161io
Consideração Iniciação Viabilidade Execução Liberação Encerramento
A A A A A IA
Nota: AR1 e AR2 são solicHações de apropriação em vários
marcos de passagens de Iases
Figura 14-15 O gerenciamento de portfólio e um processo comum de pontos de decisão de passagens de Iases no desenvolvimento de produtos.
Propostas de Investimento são qualificadas por meio de um Co11cept Scorecard, q ue é

uma planilha d inâmica q ue quantifica e marca a atratividade de um conceito por meio de
uma Proposta de Investi mento que, se aprovada, é utilizada para quantificar um projeto no
processo de pontos de decisão de passagem de fase, o q ue inclui eventos de financiamento.
Os dados usados para a tomada de decisões começam com menos no início e a umenta m
posteriormente à medida q ue a p recisão e acerte-La das estimativas melhora . A soma de to-
das as (propostas) não financiadas e todos os (projetos) financiados é gerenciada por meio
da lista de Conceitos Ordenados por Classificação (Ra11ked Ordered Co,u:ept List), que é
alimentada pelo Concept Scorecard. (Ver Fig ura 14-16.)
14.11 Fundo mundial para a natureza

12
(World Wildlife Fund, WWF)
Gerenciamento de portfólio: medindo os resultados de curto

e longo prazo no WWF
O W\'</F é um a das maiores organizações de conservação e baseia-se em u1na rede de
escritórios nacionais que produziram uma Estrutura Globa l de Programas ( Global
Progratn Fra,nework, GPF) com u1n, um ambicioso portfól io de prio ridades em bio-
diversidade e impacto ambiental no q ual focaliza r os esforços da rede do WWF até
2020 . O WWF está implementando um conjunto de programas globais de prio ridades
concentra ndo-se e1n áreas geográficas prioritárias (ecorregiões), principais espécies,
13 14
pegada ecológica e fatores determinantes a fi m de cumpri r as metas da GPF.
O WWF lntemational age como uma secreta ria para coordenar a rede e fornecer
serviços centra lizados de gerencia mento e pa ra estabelecer padrões e mel hores prá-
ticas. Como todas as organizações, o WWF precisa mo nitorar o desempenho de seu
portfólio para maxi mizar a relação custo-benefício, para gerenciar riscos e para iden-
ti ficar e co1npa rtilha r as mel hores p ráticas.
Entretanto, como uma organi zação sem fins lucrativos tra ba lhando em um am-
biente m uito co1n p lexo e1n e1n consta nte modificação, o WWF enfrenta diversos desa-
fios específicos em seu gerenciamento de portfól io, em particular:
• Uma estrutura organizacional fortemente descentral izada, com sistema de geren-
cia1nento e aprovações independentes, prio ridades específicas a e.ada local e con-
juntos não padronizadas de medidas de desempenho.
• Recursos fi nancei ros e hu1na nos globais li1nitados e, assim, uma forte necessidade
de prio rizar programas que maxi mizarão o impacto coletivo.
• Um contexto global em constante evolução, fortemente influenciado por tendên-
cias econô micas e geopolíticas globais.
• De1noras significativas entre intervenção e iinpacto mensurável, e difícil atri buição.
12
Qualquer reprodução integral ou parcial deste artigo precisa mencionar o título e dar o crédfro ao \V\VF
como detentor dos direitos aurorais. Texr 2013 © W\VF-World \Vide Fund for Narure {também conhecido
como \Vorld \-Vildlife Fund). Todos os direitos reservados. O material foi escrito por Perer J. Srephenson, PhD,
diretor, e \Villiam Reidhead, MSc, consultor de design e impacto da Unidade de Estratégia e Desempenho de
Conservação do \VWF lnternational.
u Pegada ecológica se refere às áreas de plantação, pastagens, florestas e zonas de pesca necessárias para
produz.ir os alimentos, fibras e madeira consumidas em um país, para absorver os resíduos emitidos ao gerar
a energia que uciliza e ao fornecer espaço para sua infraestrutura.
14
Um fator determinante é definido como um fator social, econômico ou polír:ico que leva a um impacto
direto sobre o meio ambiente por meio de uma mudança ou no estado da biodiversidade e/ou na pegada
ecológica.
OI
o
o
Gl
m
íi1ó
Proposta de Aprovação o
Avaliação Priorização a.
investimento do portfólio CD
i:,
a
Concept Scorecard Planilha de pontuação Guia de discussão da revisão 1·
<J>
do Concept Scorecard de propostas/portfólios
-··--.-
-·----
---·----
:.-_::.:=::t.:.:::-:::.::::.="'-
:.::..~.:;.=::-;;...--=·
·---
-- --- --
---
·--- ------
·-----·-
--·------------
----------
·--·------·--···-·
··-····--··-·--·--··-
·------···
··--·-·
,e,~ - -·-
------·---·
------{Proposal 14ame•
USTE:N. Proposal Review
THINK.
SOLVE ••~·°""'~
..=e::::
Lista de Concettos Ordenados Classificados (COC)
Figura 14-16 Processo de gestão de projetos e panorama do template comum.

Capítulo 14 Gerenciamento de portfólio de projetos 6 01
Para lidar com esses desafios, o WWF desenvolveu um sisten1a global de mo-
nitoramento e gerenciamento de portfólios que de lega poderes à gerência local,
informando, ao n1esmo tempo, a tomada de decisões globa l; que demonstra resu l-
tados no curto, méd io e longo prazo; que detecta tendências e oportunidades que
estejam surgindo; e que possibilite a alocação de recursos mais eficiente em termos
de conservação.
O sistema de gerenciamento de portfólio do WWF, implementado em julho de
2013, fornece, portanto, programas co1n as informações necessárias para um geren-
cia1nento adaptativo, permite que órgãos de governança explorem o progresso entre
diferentes programas e dentro de um mesmo programa e permite a agregação, em u1n
nível global, de dados suficientes para análises significativas do desetnpenho geral da
GPF e dos impactos e tendências de conservação.
O sistema de gerenciamento de portfólio incluí três pilares:

a) Ava liar o desempenho do progra1na
O WWF reconhece que poucos resultados de conservação mensuráveis
são observáveis no curto prazo e, em muitos casos, os programas exigem cin-
co anos ou ma is para demonstrar mudanças. Consequentemente, os progra-
mas de conservação enfatizam substancialtnente a articulação e teste de suas
teorias de mudança, isto é, a lógica do programa sobre como intervenções no
curto prazo se desenrolarão, com o passar do tetnpo, chegando a resultados
e impactos de escala cada vez 1naiores. U1na teoria de mudanças que seja
bem articulada especifica resultados intermed iários planejados como a base
para o planeja1nento do trabalho no curto prazo e a unidade de gerenciamen-
to de programas regu lar. O primeiro pi lar do sistema de gerenciamento de
portfólio do WWF exige que cada progra1na faça uma autoava liação anual,
em uma escala contínua de 1 a 7, de seu progresso em direção aos seus resul-
tados intermediários planejados anuais. Para aumentar a objetividade desse
processo, cada programa está sujeito a u1na revisão paritária independente.
Gera-se, assi1n, um "KPI geral dos resultados de conservação" para cada pro-
gra1na prioritário do WWF; esse KPI pode ser usado no nível do portfólio
como um instantâneo do desempenho e1n determinado momento e como u1n
sistema de alerta precoce de programas com sub-dese1npenho ou progra1nas
que exigem suporte ad icional da rede do WWF.
b) Medir resultados e impactos
O segundo pi lar do sistema de gerenciamento de portfólio exige que a or-
ganizaç.ã o vá alé1n do desempenho de curto prazo dos programas, em d ireção
a resultados e impactos selecionados.
Resultados normalmente estão relacionados a reduzir ameaças à biodiversidade e
são definidos pelos objetivos declarados de um programa. O monitora1nento
de resultado responde perguntas co1no: novas áreas protegidas foram esta-
belecidas e eficientemente gerenciadas? As capturas da pesca melhoraram e
as capturas acidenta is foram reduzidas? Mudanças políticas essenciais fora 1n
detenninadas e implementadas?
Impacto é uma medida de como um programa está se saindo em relação às suas
metas declaradas direta1nente relacionadas à biodiversidade que está ten -
tando conservar ou a pegada ecológica que está tentando reduzir. Responde
a perguntas co1no: o nú1nero de tigres aumentou? A cobertura florestal na
Amazônia permanece estável? A pesca do bacalhau se recuperou? O consu-
mo de energia ditninuiu? As comunidades locais se beneficiaram com esse
programa?
A Rede do WWF chegou a um acordo quanto a 20 "indicadores comuns"

que pretendiam gerar um quadro dos resultados que os programas estão atin-
gindo e1n relação a um conjunto comum de med idas comparáveis. Os indica-
dores co1nuns são articulados em torno do estado (cobertura e conetividade
do habitat; populações das principais espécies; saúde do oceano; diversidade
das espécies; fluxos ambientais), pressões (perda e degradação do habitat;
frag1nentaç.ã o dos r ios; redução e superexploração de espécies, emissões de
C02), respostas (tamanho das áreas protegidas e eficiência do gerenciamen-
tos; produç.ã o sustentável de mercadorias, energia e água; comércio de fauna
e flora selvagens) e impacto socia l (beneficiários). Indicadores sim ilares de
programas sim ilares pode1n se agrupar para permitir u1na análise globa l para
uso por órgãos de governança em gerenciamento de portfólios.
c) Dashboards de portfólios
O primeiro e o segundo pilares do sistema de gerenciamento de portfólio
fornecem sistematicamente dados no nível do programa sobre o desempenho
de curto prazo (o KPI dos resultados de conservação) e o dese1npenho de
médio e longo prazo (os indicadores comuns de resu ltados e impactos). Esses
dados podem ser apresentados juntos em um dashboard para oferecer um pa-
nora1na holístico de como cada programa está se saindo, independentemente
de qualquer outro. Os dados serão apre.sentados no contexto das metas do
programa para fornecer uma 1nedida relativa de progresso e1n di reção aos
resultados e impactos. Os dashboards compreendem o cerne do Relatório do
Programa de Conservação Global anual do W\1v'F e serão acompanhado por
uma narrativa para colocar os resultados no contexto das ações e teorias de
mudança do programa.
Ao usar 1ned idas co1nuns de curto e mais longo prazo, o sistema também
permite que esses dados sejam visua lizados e1n todo o portfólio do \1v'\1v'F,
possibilitando a comparação do desempenho em diversos programas, e per-
mitindo a agregação de dados para 1nedir o desempenho do WWF como
organização em relação às metas globais que estabeleceu para si mes1no na
Estrutura Global de Programas. A Figura 14- 17 fornece uma simulação de
como os dados poderia1n ser agregados e usados no nível do portfólio.
O dashboard de portfólio serve como uma ferramenta centra l de geren-
ciamento para uso por diversos públ icos d iferentes, inclu indo equipes de
gerenciamento de programas e órgãos de governança, órgãos de supervisão
e governança da rede do \1VWF, além de doadores e outras partes interessa-
das . As principais perguntas respond idas pelo sistema de gerenciamento de
portfólio incluem:
• Os progra1nas do WWF estão alcançando suas metas e objetivos e tendo um
impacto sobre o estado da biod iversidade?
• Quais são os programas em que o investimento do \1v'\1v'F está tendo ma ior/
menor impacto em direção às metas da Estrutura Global de Programas?
• Quais são os fatores técn icos e operacionais comuns que estão influenciando
o desempenho dos programas?
• Quais são as 1nelhores práticas e lições aprendidas entre diferentes progra-
mas e dentro de um mesmo programa?
• Qual é a contribu ição da rede do W\1v'F para a conservação em tennos glo-
bais? O que pode ser atribuído ao trabalho do WWF?
• Quais são as tendências, desafios e oportunidades que estão surgindo para a
conservação em termos globais?
it-----~&--·' ! ····················-
::::<. ·······
:::c.:,:s,,:l?J.::............
............. x,:x,.:x, .
l
" ª'
+
' i
•:::-:,:-::-:-:-::,;, ..•:::,_,;.::-:,:-::-
. ..... .... ... ,, H ,, u ,,, , ,
,:-::,:,:-::-:-:-::-: :.,: ::,:•:-::-:,:-::-
•••• ••••.••• ... .••:··,·:,·,·;:·.
!
1
••
:••,-,-,·.-.- ' H ••• •••• -•
~
'fa ·.·.·
·- ·. :c·.·.· c··.·c.·j ···.·cc·.·.·c·.·..
.•. ·. : ·. : .• .. •, ..'.•. ·. : .•. ·. :
! .'.
y 1l ' '°' ' ' ' ' ' ' ' ' '
,,, , ,,, H ,, u •• H ••• •••• -•
• -••• -••• · •••
•.·. :•.·,:.•.·. :.• .. ••,·:.••.·
. :.•.·. :
' !
.
. •• .
. . . .. . ·I' · • . .
1 .. ' . • •
I·
)( ,. N
"'
:E "' "' "'
:E :E :E :E
:E :E :E
~~ ~ ~ ~
""'...
o
..""'
o ""'...o ""'...o
É importante observar que a eficiência do sistema de gerenciamento de portfólio

está intimamente ligada à qualidade dos planos est ratégicos e do mon itoramento pra-
ticado em cada progra1na. Por consequência, os programas do WWF são fortemente
apoiados e estimulados a seguir melhores práticas em planejamento, monitoramento
15
e ava liação, a separar recursos para o levantamento e a análise de dados e a integrar
as informações resu ltantes à tomada de decisões e à aprendizage1n em gerenciamento
no nível dos programas.
15
O \V\VF segue os "'Padrões W\VF para a Gestão de Projetos e Programas de Consen•ação'" (\V\Y/F Sta11•
dards for Conseroatfon Project and Programme Management), baseados nos "Padrões Abertos para a Prática
da Conservação" (Open Standards for tl,e Practice of Conservation), um conjunto de melhores práticas de·
se1wolvido e promovido pela Aliança para as M.edidas de Conservação (Conservation Measures Partnership,
www.conservacionmeasures.org).
Excelência em gestão
de projetos global
15.0 Introdução
Nos capítulos anteriores, discutimos a excelência em gestão de projetos, o uso de me-
todologias de gestão de projetos e o hexágono da excelência. Muitas empresas descri-
tas neste livro já se tomaram excelentes em todas essas áreas . Neste capítulo, discuti-
remos sete empresas: IBM, Computer Associares, Microsoft, Deloitte, COMAU, Fluor
e Siemens. Todas já alcançaram práticas e ca racterísticas especializadas relacionadas a
uma gestão de projetos globalizada profunda:
• Elas são 1nultinacionais.
• Vendem soluções de negócios aos seus clientes, em vez de apenas produtos ou
serviços.
• Reconhecem que, para seretn provedoras de soluções bem-sucedidas, precisatn se
tornar excelentes em gestão de projetos, em vez de apenas serem boas nisso.
• Reconhecem que têm de ser excelentes em todas as áreas da gestão de projetos etn
vez de apenas em uma á rea.
• Reconhecem que uma abordagetn de gestão de p rojetos globa l deve focalizar mais
est rutura, te,nplates, listas de verificação, formulá rios e diretrizes do que políticas
e proceditnentos rígidos, e que a abordagem precisa poder ser usada igua lmente
bem em todos os países e pa ra todos os clientes.
• Reconhecem a importância do gerenciamento do conhecimento, de lições aprendi-
das, de captar as melhores práticas e das melhorias contínuas.
• Compreendem a necessidade de possu ir ferramentas como suporte à sua aborda-
gem de gestão de projetos.
• Compreendem que, sem melhorias contínuas na gestão de projetos, elas podetn
perder clientes e participação de mercado.
• Mantêm um escritório de gestão de projetos ou um cent ro de excelência.
• Realizam o p lanejamento estr atégico da gestão de projetos.
• Consideram a gestão de projetos como uma competência est ratégica.
Essas características podem se aplicar e se aplicam a todas as empresas citadas
anteriormente, mas são de máxima importância para empresas multinacionais.
1
15.1 A cultura da 1BM
Em seu livro, Wlho Says Elephants Can't Dance, o antigo presidente da IBM, Lou
Gerstner, escreveu:
• O problema, em essência, é: como lidamos com a matriz da IBM? Como podemos
executar nossas est ratégias em uma empresa de tamanha complexidade?
• ... o valor singular da IBM para os cl ientes é nossa capacidade de constr uir solu-
ções integradas ...
• ... nossa capacidade de integrar produtos, habil idades e ideias é nossa única van-
tagem competitiva sustentável.
• ... não existe vantagem competitiva sustentável de longo prazo em tecnologia.
• A questão, então, é: que tipo de sistema de gerenciamento suporta nossa estr até-
gia fundamenta l de integração?... O clássico sistema de cadeia de comando é não
somente lento demais para o ritmo dessa indúst ria, mas também se opõe à nossa
habilidade de t rabalhar ent re d iversas organizações. A hierarquia, que parece su-
portar a integraç.ã o, na verdade vai contra ela. A hierarquia erige linhas e lim ites
verticais e estimu la a infame mentalidade de "silo».
• ... u1na matriz bem gerenciada é ext remamente flu ida e adaptável. Os papéis
mudam frequentemente. Equipes se formam e se desfazem. Decisões sobre que
unidade de negócios irá liderar determ inada situa ão não são codificadas. Isso
acentua o julgamento de líderes em todos os níveis.
7
Em meados da década de 1990, dinâmicas de indúst ria como concorrência no ní-
vel mundial, pressões relativas a recursos, rápidas mudanças nos segmentos de cl ientes
e tecnologia levaram a IBM a uma estrutura organizacional d iferente de sua abor-
dagem hierárquica tradiciona l de gerenciamento. Além disso, a empresa identificou
a falta de uma forte gestão de projetos como um grande fator de contribuição para
o fracasso do projeto e de problemas na satisfação do cl iente em toda a corporação.
Esses fatores levaram a IBM a decidir se tornar uma empresa baseada em projetos,
aplicando e integrando disciplinas de gestão de projetos e1n todos os seus principais
negócios, processos e sistemas.
Em nove1nbro de 1996, a IBM consolidou seus esforços pa ra se tornar uma em-
presa baseada e1n projetos e estabeleceu o Centro de Excelência em Gestão de Projetos
(PM/COE, Project lvfanage,nent Center of Excellence). O estatudo do Centro de Ex-
celência em Gestão de Projetos tem por objetivo desenvolver a co1npetência necessária
para a eficiência e o sucesso dentro de sua empresa matr icia l. Ele dirige a t ransforma-
ção da IBM em uma empresa baseada e1n projetos desenvolvendo e oferecendo supor-
te a profissionais de gestão de projetos e1n todo o inundo.
Desde seu início, esse estatuto é periodicamente revisado para garantir seu valor
e relevância. Em 2010, o gerenciamento de programas foi adicionado ao estatuto em
resposta ao aumento da complexidade dos projetos e ao reconhecimento pela indús-
t ria da necessidade de gerentes de programa qual ificados. A adição do gerenciamento
de programas não so1nente apresentava a necessidade de mais treinamento, mas tam-
bém de um plano de carreira para os profissiona is.
1
€>20 13 by IB.M Corporarion. Reproduzido com permissão . Todos os direitos reservados.
i Gerscner, Louis V., \Y/ho Says Elephants Can't Dance?, ©2002, Harper Business Publishers, an lmprim of
Harper Collins Publishers, Appendix A, pages 313-314 .

Capítulo 15 Excelência em gestão de projetos global 607
O Cent ro de Excelência em Gestão de Projetos foi reconhecido e1n 201 O como o

Escritório de Gestão de Projetos do Ano pela PM Solutions e PMOSIG, e em 2011,
como uma Melhor Prática pela APQC.
O estatuto: elevar a gestão de projetos e programas

a uma competência central na IBM
A IBM identificou a gestão de projetos como uma chave para sua capacidade de cum-
prir seus co1npromissos de fonna confiável. Assim como muitas empresas na década
de 1990, a ausência de uma gestão de projetos forte contribuiu para a d ificuldade
em cumprir compromissos dentro do prazo, do orçamento e com o lucro adequado.
Aná lises das capacidades da gestão de projetos em relação às melhores práticas da
indústria mostrou que a IBM:
• Geralmente não reconhecia um esforço de trabalho como um projeto e, portanto,
não aplicava as disciplinas necessárias para realizar o traba lho de forma bem-
-sucedida;
• Não possuía gerentes de projeto qualificados ou uma est rutura para cobrir opor-
tunidades de projeto e
• Possuía uma cu ltura e sistemas organizacionais (gerenciamento e negócios) que
não eram baseados em projetos e, portanto, não ofereciam suporte, e às vezes, na
verdade, impediam, o t raba lho de projetos.
A IBM deu passos definitivos no sentido de mudar sua cultura e sistemas de su-
porte para melhorar sua post ura de negócios. A empresa deu passos audaciosos em
relação a con10 organizar, executar e acon1panhar o trabalho e começou a organ izar
o trabalho en1 projetos que produziam serviços, produtos e soluções para nossos
clientes. Essa abordagem foi aplicada a projetos de desenvolvimento tanto externos
quanto internos.
Desde o seu início, o Centro de Excelência em Gestão de Projetos da IBM, t ra-
balhando conjuntamente co1n todas as unidades de negócios em todo o mundo, es-
forçou-se para garantir que a IBM se tornasse uma empresa baseada em projetos que
aplica e integra discipl inas de gestão de projetos a todos os sistemas e processos de
negócios centra is. (Ver Figura 15- 1.) O estatuto inicia l dirigiu um uso mais consistente
e mais amplo de disciplinas de gestão de projetos, importante para a capacidade da
IBM de atender as necessidades do cliente. Entretanto, a gestão de projetos não pode
ser plenamente aproveitada se1n uma profunda competência organ izacional em habi -
lidades de gestão de projetos. Ações dirigiram a forma lização da posição de gerente de
projetos em toda a IBM além de o foco no aperfeiçoamento das habilidades de gestão
de projetos de todos os funcionários da empresa.
A adição do gerenciamento de programas em 2010 ocorreu em resposta às exi-
gências das unidades de negócios para dar conta da crescente comp lexidade dos
projetos e o foco en1 programas. Ações de suporte ao gerenciamento de programas
são incluídas nas d iscussões con1 o Comitê de Direção Executiva e as linhas orga-
. . .
n1zac1ona1s.
Competência organizacional em gestão de projetos e programas

A competência central e1n gestão de projetos e programas exige um ambiente que se
focalize em projetos e progra1nas, e não em funções. O ambiente precisa desenvolver
um núcleo de gerentes qual ificados de projetos e programas em todo o mundo. A IBM
encoraja e espera que todos os funcionários associados a projetos compreendam co1no

seus papéis afeta tn a execução dos mes1nos e um envolvimento bem-suced ido com o
cliente. São necessários recu rsos financei ros, recursos humanos e sistemas de geren-
ciamento para oferecer suporte às at ividades de gestão de projetos. (Ver Figura 15- 2.)
Para alcançar a competência organizaciona l em gestão de p rojetos, o PM/COE
d irige as seguintes ações e1n toda a sua cultura:
Centro de Excelência
Comitê de Direção Executiva
em Gestão de Projetos
Garantir que a "decisão de mudar"' Desenvolver e manter:

aconteça em sua unidade Programas, ferramentas, método e
de negócios (BU) políticas para desenvolver e oferecer
suporte ao uso sistêmico de disciplinas
Oferecer orientação de GP em toda a corporação
Implementar e integrar.
Trabalhar por meio de líderes de Disciplina de GP por unidades de negócios
implementação e de gerenciamento
de unidades de negócios
Unidade de negócio
Remover obstáculos Competência GP
Lideres
Comunicar a mensagem Redes de competência em GP das BU
D
Linhas organizacionais
Comunidade de GP
Figura 15-1 O envolvimento em todos os n íveis da empresa é crucial para a aceitação sis-
têmica e o uso de disciplinas de gestão de projetos.
Construir Produzir os Tornar o

habilidades possibilrtadores•chave GP sistêmico
Habilidades Métodos Envolvimento executivo

Educação Ferramentas Mensurações
Qualificação Avaliações Comunicações
Compartilhamento Sistemas financeiros Integração: de negócios,
de conhecimento cultural, organizacional
Indivíduo Empresa
Figura 15-2 O ro te iro para a lcançar a competência da gestão de projetos começa no

profissional individual e a lcança toda a empresa, garantindo a eficiência organizacional e a
aceitação.
• O trabalho é organ izado ao longo de linhas de projeto; esforços e iniciativas são

dirigidas por equipes multifuncionais que se focalizam em alcançar metas especí-
ficas em prazos definidos.
• Os projetos são consistentemente financiados, populados e gerenciado sem todas
as unidades de negócios.
• A gestão de projetos possui um papel relevante e1n todos os processos de negócios
gerais.
• Os indivíduos envolvidos nos projetos - incluindo executivos, membros da equ ipe
de projetos, e gerentes funcionais - compreendem seu papel no planejamento, exe-
cução e avaliação de projetos individuais e múltiplos projetos.
• Os resu ltados de projetos podem ser previstos com altos graus de certeza. Quando
essas previsões estiverem erradas, a organização tem o conhecimento e a habilida-
de de ajustar decisões e tomar as ações corretivas apropriadas cedo.
• Há métodos quantitativos rápidos e precisos disponíveis para monitorar o pro-
gresso, prever resu ltados e avaliar riscos; há sistemas em vigor para oferecer su-
porte a essas técnicas; e os resultados são continuamente aprimorados.
• Os gerentes de projetos são qua lificados e designados de acordo com critérios
est ritamente profissionais.
• A gestão de projetos é considerada uma d isciplina profissiona l crucial com pro-
gramas para a melhoria contínua de habi lidades e desenvolviinento profissional.
O Cent ro de Excelência em Gestão de Projetos estabeleceu as seguintes ações para
alcançar tamanha competência organizacional e ta l cultura baseada em projetos em
toda a IBM.
Ação 1: A IBM adotou uma sólida abordage1n para a gestão de projetos e progra1nas.
Essa abordagem personifica 1netodologias, práticas, ferramentas e técnicas cen-
trais comuns a todas as organizações IBM, 1nas é suficiente1nente flexíveis para
acomodar considerações de negócios individua is.
Inicia ln1ente, havia múltiplas abordagens à gestão de projetos, incluindo di -
ferentes vocabulários, processos e ferramentas. Os gerentes de projetos eram trei -
nados de 1naneiras diferentes e1n cada unidade de negócios. Até 1nesn10 o papel
do gerente de projetos diferia de un1a organização para a outra. Con1 a adiç.ão do
gerencian1ento de progran1as, o PM/COE está fornecendo un1 caminho para lidar
com a crescente complexidade e an1biente de desenvolviinento do negócio.
Uma competência organ izaciona l exige u1na abordagem consistente. A con-
sistência melhora a rapidez e a qualidade e reduz custos. A co1nun icação é sim-
plificada e acelerada co1n ferramentas e fonnatos padronizados. Os gerentes de
projetos e programas de toda a IBM se beneficiam da experiência dos outros, já
que eles não desperdiça1n tempo reinventando técnicas já aprendidas por meio da
experiência. Claramente, uma abordagem idêntica de um processo ou programa
de gestão de projetos detalhado não será apl icável a todas as unidades de negócios
e pode até mesmo interferir com processos de negócios e necessidades individuais.
No entanto, há características-chave co1nuns a todos os projetos e programas
bem-suced idos, independente de seu tipo ou magnitude. Desenvolvemos um pro-
cesso essencial baseado nas melhores práticas da IBM e de nossos colegas e con-
correntes. Instituciona lizar esse processo essencial garante que as disciplinas da
gestão de projetos e programas cruciais ao sucesso sejam agora aplicadas em toda
-
a corporaçao.
Ação 2: Gerentes de projetos e programas certificados selecionados gerenciam proje-
tos e programas significativos, enquanto os sistemas de gerencia1nento permite1n
esse processo. Os gerentes de projetos e programas da IBM atendem às exigências
apropriadas de formação profissional e experiência, proporcionais às exigências

dos cargos.
Os gerentes de projetos e programas da IBM têm de cumprir padrões edu-
cacionais. Uma est rutura de qualificação progressiva, incluindo a exigência de
passar em exames independentes da indúst ria, garante que os gerentes de projetos
da IBM obtenha1n o conhecimento e a experiência necessários à medida que vão
progredindo em suas carreiras. Um estudo de competências deta lhado foi utiliza-
do para mapear a experiência e formação essencial para desenvolver os melhores
gerentes de projetos e programas e garantir sua vitalidade profissional.
As abordagens de plano de carreira e de qualificação têm o suporte de uma
estrutura integrada de recursos humanos e um programa de desenvolvi1nento pro-
fisional. Essas abordagens são al inhadas e convergiram em uma única abordagem
para toda a IBM da formação e vital idade profissional. A abordagem é flexível de
modo que tambétn possa incluir novos programas de Recursos Humanos, o que
garante que os níveis de habi lidade atingidos sejam consistentes não somente em
todos os papéis desempenhados na gestão de projetos, mas ta1nbém em compara-
ção a todos os outros cargos da IBM.
Iguahnente importante para o desenvolvimento e a qual ificação é um refina-
mento do processo pelo qual eles são designados a diferentes projetos. Projetos
e programas são avaliados tendo em vista seu tamanho, itnplicações de receita,
risco, itnportância do cliente, urgência de tempo, necessidade do mercado e outras
características; profissionais qualificados são designados a eles com base e1n fato-
res de formação e experiência necessários.
Ação 3: A IBM 1nonitora o desempenho de projetos e programas e mede seu progresso
em termos de seu desempenho técnico, financeiro e de cronograma. Os gerentes de
projetos e programas e seus executivos patrocinadores são responsáveis por resul-
tados específicos. Para auxi liá-los nesses esforços, são disponibil izados tambétn os
métodos e as ferramentas necessários para analisar o desempenho.
A gestão de projetos é muitas vezes pensada como o gerenciamento de tarefas
em um cronograma. Entretanto, o sucesso de um projeto tambétn é determina-
do pelo grau de cumpri1nento dos requ isitos estabelecidos e por seu desempenho
financeiro. Um esforço que é concluído dent ro do prazo, mas que não atende
aos requisitos ou que excede significtivamente suas projeções orçamentárias pode
muito bem acabar fazendo a e1npresa perder clientes, participação ou liderança de
mercado, além de lucros imediatos e o moral dos funcionários.
Ao avaliar o desen1penho, todos os aspectos - técnico, do cronograma e
financeiro - são consistenten1ente aval iados. Os processos e sistemas da IBM
oferecem suporte a essa abordagem e fornecen1 dados rápidos e abrangentes
sobre os projetos e progran1as. Há diversos sistemas disponíveis para oferecer
suporte ao gerenciamento de tarefas e cronogramas, a lém de para avaliar o
de.sen1penho financeiro de projetos individuais. O PM/COE vem, desde seu iní-
cio, guarnecendo bancos de dados históricos que permitem a identificação e a
ava liação de tendências e comparações históricas. Ele continua garantindo que
os esforços en1 andamento para aprin1orar sisten1as sejan1 suportados e expan-
didos, de n1odo a oferecer uma orientação de projeto para todo o trabalho en1
toda a corporação.
Ação 4: A IBM estabeleceu u1n Cent ro de Competência de Gestão de projetos, cuja
missão é oferecer suporte à prática da gestão de projetos profissional em toda a
Corporação IBM. E1n 2010, essa missão foi expandida, passando a incluir o ge-
renciamento de programas.
A IBM designou utn pat rocinador executivo e, então, esta beleceu e popu lou
um Centro de Excelência em GP. O PM/COE é a fonte virtual e o cent ro coordena -
dor dos conhecimentos de gestão de projetos e progra tnas em toda a corporaç.ã o.
O PM/COE é composto por gerentes de projetos certificados etn um esque1na
rotativo envolvendo todas as un idades de negócios. É modelado segundo a abor-
dagem ext remamente bem-sucedida da IBM Academy e util iza o modelo de gover-
nança desenvolvido pela G loba l Services pa ra seu IBM Solutions Institute.
Responsabilidades específicas do PM/COE englobam:
• Desenvolver uma estratégia e planos pa ra toda a IBM para o desenvolvi1nento
e o suporte da gestão de projetos e programas co1no uma competência organi -
zaciona l além de co1no uma profissão individua l
• Dirigir o desenvolvimento de processos, práticas, ferramentas e cu rrículos
para que se alcance essa estratégia e seus esforços relacionados de coordena-
ção etn todas as unidades de negócios
• Fornecer experiência e assistência especia lizada em gestão de projetos e pro-
gramas em toda a corporação
• Manter uma comunidade de profissiona is de gestão de projetos e programas
dentro da IBM e coordenar essa comunidade com outras comunidades inter-
nas e externas relacionadas
Ação 5: Os gerentes de projetos e programas da IBM ampliam o avanço da gestão de
projetos e programas como uma d iscipl ina profissiona l por meio de atividades de
compartilhamento de experiências du rante ou entre tarefas.
Uma co1nunidade profissional floresce e cre.sce somente por meio das cont ri-
buições de seus membros, ao ajuda rem uns aos outros a se tornaretn mais pro-
ficientes na prática de sua disciplina. Esses esforços incluem 1nentoria, ensino,
aval iação de projetos e atividades de garantia, a lém do compartilhamento de ex-
periências por meio de exercícios de lições aprendidas e da publ icação de artigos.
Essa cont ribuição serve para atualizar e renovar os gerentes de projetos, e é con-
siderado uma honra cont ribuir para sua profissão dessa manei ra . Entretanto, esse
crescimento e aprimoramento profissiona l pode ocorrer somente com o suporte
organizacional consciente de tais atividades.
Segundo Debi Deli, PMP®, Gerente do Centro de Excelência em Gestão de
Projetos da IBM,
É somente por meio da contribuição e de atividades similares que a IBM se beneficia da
aprendizagem e do crescimento da profissão de gestão de projetos. Determinamos uma
expectativa de que nossos melhores e mais brilhantes gerentes de projetos irão contri-
bui r com a comunidade de GP - pois eles são realmente os que mais têm a ofere.cer. A
participação em a tividades de contribuição é integrada às exigências de q ual ificação
dos gerentes de projetos em toda a corporação. A liderança deve continuar a endossar
a profissão e essas atividades como algo valioso e que contribui d iretamente para a
eficiência da IB!vl.
Pa ra concluir, o PM/COE desenvolve e itnplementa uma est ratégia e planos
em toda a corporação para alcançar uma competência organizacional etn gestão
de projetos e programas. Ele estabelece e dirige uma consistência de abordagetn,
uma rede de praticantes experientes e de processos e sistemas de suporte. (Ver Fi-
gura 15- 3.) Finalmente, ele estabelece e mantém uma comunidade de profissionais
de gestão de projetos e programas dent ro da IBM e age como a interface entre a
comunidade da IBM e out ras comunidades profissionais internas e externas.
Desenvolver Empresa
Unidade de negócios
Organização
Projeto/
Programa
Implementar
PM GM Integrar
Figura 1S-3 Gestão de projetos empresarial.
Co1n o passar do tempo, o PM/COE dirigiu a tr ansformação e a integração da

gestão de projetos à 1nalha da IBM. Os profissionais da IBM são mais experientes
e competentes em suas capacidades de executar o t rabal ho usando as disciplinas da
gestão de projetos. Em resu1no, as d isciplinas da gestão de projetos se torna ram sis-
têmicas e1n toda a IBM, resu ltando em projetos be1n-sucedidos e em um maior valor
para o cl iente. Hoje, a etnpresa se focaliza e1n alcançar o mesmo com o gerenciamento
de programas.
Suporte da gerência
Um forte respa ldo executivo começou no topo da IBM quando o Comitê Executivo
Corporativo, liderado por Lou Gerstner (CEO), declarou, em novembro de 1996, que
a IBM se tornaria uma empresa baseada em projetos com métodos e ferramentas co-
muns e o reconhecitnento da gestão de projetos como uma profissão. Essa t ransforma-
ção continua a receber forte suporte executivo em toda a corporação.
A formação e a implementação da estratégia de Gestão de Projetos Empresaria l da IBM é
um exemplo glorioso de uma transformação organ izacional bem-s ucedida. Iniciada por um
estatuto que o CEO Lou Gerstner estabeleceu em I 996 para tornar a IBN! uma empresa
baseada em projetos, o Centro de Excelência em Gestão de Projetos da IBN! dirigiu as fases
progressivas do programa ao longo desses últimos anos. O segredo do s ucesso do PM/COE
foi o patrocínio por um comitê de executivos sênioc, que agiam como defensores convictos
da gestão de projetos e programas em um conjunto diverso de unidades de negócios globais.
Os benefícios organizacionais dessa transformação q ue foram realizados ao longo desse
tempo são muito evidentes no sucesso atua l da IBM.
Steve DelGrosso,
Diretor do Centro de Excelência em Gestão de Projetos da IBM
Muitos executivos apoiam ativa1nente a gestão de projetos e progra1nas dentr o de
suas organizações e enviam fortes mensagens a toda a sua un idade de negócios a esse
respei to. Isso é essencia l para fazer outr os participantes da o rgan ização apoiarem a
O suporte da gerência precisa co1neçar no topo com uma declaração de fo rte
apoio executivo, que é comunicado entre organizações e dentro de u1na mes1na orga-
nização. Isso, por sua vez, é decisivo pa ra fazer a gerência intermediária e a gerência de
á rea apoiarem as 1n1c1at1vas.
O PM/COE traba lha com os executivos dentro das unidades de negócios sem esse
suporte descendente para aumenta r sua compreensão da importância da gestão de
projetos para alcançar seus objetivos de negócios e para, subsequentemente, articular

seu suporte e suas 1nensagens para sua organização.
Depois de conseguir o suporte executivo geral em uma organ ização, oferece-se
formação gerentes intermediários, gerentes de área e praticantes sobre as inciativas de
projetos e programas da IBM e como elas podem ser totalmente adotadas. Essa for-
mação assume muitas diferentes formas, como cursos, artigos de publicação mensal,
reuniões periódicas, conferências, etc.
Finalmente, um componente essencial para a integração dessas disciplinas dentro
de todas as un idades de negócios é uma Rede de Competências. Existe uma equipe
central de líderes de comun idade em cada uma das principa is localidades geográficas
da IBM, bem como em suas linhas de negócios e un idades de negócios (BU), que são
responsáveis por sua comunidade de gestão de projetos e programas. Esses líderes e
equipes garantem que atividades, ferramentas, métodos e fonnação sejam implemen-
tados dent ro de sua região geográfica ou em sua unidade de negócios.
Gestão de projetos, programas e portfólios

A IBM estrutura-se em tomo de organizações globais de hardware, software e servi-
ços. Implementar processos, procedimentos, métodos, ferramentas e habilidades co-
muns que pudessem cruzar os limites das unidades de negócios e regiões geográficas e
ainda assim sere1n eficientes foi difíci l no início. Entretanto, ao permitir que as organi-
zações adaptassem a abordagem de modo que ela se adequasse ao modelo de negócios
de cada organização e área geográfica, obtém-se uma consistência, convergência e
eficiência em todas as práticas de GP em todo o inundo.
Dentro da empresa baseada em projetos da IBM, é itnportante para todos os níveis
da gerência co1npreender como os projetos, a const rução funda 1nenta l de realização de
trabalhos, estão relacionados aos programas e portfólios. Essa relação é fundamental
para que se aplique abordagem, autoridade e controles de gerenciamento apropriados
para garantir o sucesso. As definições dessas construções na empresa incluem:
Projetos são esforços temporários empreendidos a fi 1n de produzir um produto ou
serviço singular. Projetos são esforços táticos, uma vez que são de curto prazo e
possuem um escopo ou objetivos definidos.
Program as são esforços de longo prazo empreend idos a fim de implementar uma es-
tratégia ou 1nissão para cumprir metas de negócios ou organizacionais. U1n pro-
grama é i1nplementado por meio de diversos projetos e atividades regulares inter-
-relacionados. Mu itas vezes, projetos complexos devem 1nais corretamente ser
gerenciados co1no programas. Na IBM, típicos programas inclue1n cont ratos e
desenvolvi1nento de produtos.
Portfólios de projetos/progran1as são um modo empresarial de ver projetos e/ou pro-
gramas que compartilham características co1nuns específicas e são vistos como
um grupo para fins de gerenciamento. Na IBM, portfólios típicos são: os serviços
oferecidos pela IBM Global Services, projetos nas 1nãos de um d iretor ou progra-
mas nas mãos de um setor.
O Centro de Excelência em Gestão de Projetos desenvolveu práticas corporativas
cujo objetivo era oferecer suporte ao gerenciamento de e.ada uma dessas áreas. As
práticas são documentos curtos e concisos que servem de referência ao se verificar
se uma equ ipe está abordando todas as áreas comuns que most rara1n ser fatores de
sucesso em uma e1npresa baseada em projetos. As práticas t ratam especificamente das
seguintes áreas de disciplina de GP, formando uma base comum para o gerenc.ia1nento
em todas as unidades de negócios (ver Figura 15-4):
Uma comunidade de profissionais de GP

qualificados que lideram equipes e que gerenciam
entregas dentro do prazo, escopo e custo,
Comunidade reduzindo riscos, por meio do uso de disciplinas
baseadas em projetos.
Métodos de GP e conjunto de ferramentas de GP,

ampliável e adaptável às necessidades dos
programas e projetos do cliente, oferecendo
Possibilitadores o nível certo de controle necessário para controlar
o risco e garantir a entrega.
Os sistemas de gerenciamento, infraestrutura

e processo, que dão visibilidade às informações
sobre projetos e programas necessárias para
Infraestrutura
gerenciar o negócio eficientemente.
Figura 15-4 A relação entre projetos, programas e portfólios e materiais de suporte.
• A relação entre projetos, progra 1nas e portfólios;

• As responsabilidades da gerência e das partes interessadas em projetos, programas
e portfólios; e
• As práticas de gestão de projetos e programas.
Recomenda-se o cumprimento de uma prática, exceto em casos e1n que a política
ou processo de unidade de negócios torne tal cumprimento obrigatório. Ao utilizar
u1na Prática Corporativa da IBM, unidades de negócios individuais podem tomar as
decisões apropriadas quanto ao cumprimento da prática relevante aos seus objetivos
de negócios.
Escritório de gestão de projetos (PMO)
Como parte de sua missão de se transformar em uma empresa baseada e1n projetos,
o PM/COE da IBM focaliza-se na compreensão e na implementação de escritó rios de
gestão de projetos (PMOs) para auxiliar no processo de transfonnação do GP.
Os PMOs, definidos como um grupo coordenado que consiste e1n um ou ma is
indivíduos dentro de uma organização, são estabelecidos dentro da IBM para rea lizar
funções de gestão de projetos para um único projeto ou para um portfólio de projetos
visando a tomar a organizaç.ã o mais eficiente. Na verdade, o PM/COE é estruturado
como um PMO.
Dentro da IBM, há primordia lmente dois tipos de PMOs:
• Um escritório de projetos internos, que oferece suporte em gestão de projetos a

um único projeto ou programa e
• Un1 escritório de projetos central izado, que oferece conhecimentos especializa-
dos em gestão de projetos para diversos projetos, programas e organ izações ou
que possu i um estat uto que define objetivos para a lém da execução de tarefas
de GP.
O PM/COE desenvolveu e definiu o Programa de Escritório de Projetos, forne-
cendo um conjunto de conhecimentos sobre o design efetivo e a implementação das
capacidades do escritório de projetos, tanto dentro da IBM quanto em nome de seus
clientes. O Programa de Escritório de Projetos oferece assistência a escritórios de pro-
jetos por 1neio de diversas ferramentas, incluindo o Guia do Escritório de Projetos
(Project Office G11ide), o Guia de Configuração (Setup Guide) e a Orientação quanto
aos Papéis desempenhados pelo Pessoal (Staffing Roles Guidance).
Além disso, 1nembros do PM/COE apresentam o va lor dos PMOs e1n toda a em-
presa, encorajando seu uso quando apropriado. No mundo de hoje, em que a entre-
ga de soluções altamente complexas é a nonna, um escritório de gestão de projetos
(PMO) aumenta a eficiência e a eficácia. Um PMO deve ser organ izado de 1nodo a
oferecer suporte a metas organizaciona is e a oferecer benefícios como:
• Perm itir que gerentes de projetos adotem uma abordagem consistente, sistemática
e repetível para a gestão de projetos
• Melhorar continuamente o cojunto de habi lidades dos gerentes de projetos
• Oferecer visibil idade ao gerenciamento e controle de projetos para reduzir a ocor-
rência de projetos problemáticos
• O timizar recursos, seleção e priorização de projetos
• Realizar funções administrativas de projetos, programas e portfólios para liberar
o gerente de projetos para que ele possa se concentrar no projeto/contrato
• Apoiar a adoção de uma cultura de gestão de projetos
O foco e o compromisso executivo é necessário ao estabelecer e apl icar o uso do
escritório de projetos. Os executivos precisan1 patrocinar e dedicar tempo, atenção
e recursos financeiros a tornar o escritório de projetos bem-suced ido. A gerência,
então, ten1 de designar con10 gerente do escritório de projetos um gerente de pro-
jetos respeitado e capaz de traba lhar eficientemente em d iversos projetos e também
garantir que o PMO seja composto por indivíduos experientes, capazes e com dedi-
cação en1 ten1po integral. Como sempre, a gerência deve comun icar eficientemente e
garantir a aceitação dos papéis e responsabilidades do escritório de projetos en1 toda
a organ ização.
Finalmente, se o escritório de projetos for bem gerenciado, como resultado haverá
benefícios adicionais, tanto no nível do projeto quanto da organização. Os projetos
testemunham um menor prazo de entrega, custos reduzidos, uma melhor coleção de
materiais intelectua is e dados históricos relativos ao projeto para subsequente reuti-
lização e para a geração de melhores estimativas. As organizações realizam melhores
comunicações, maior capacidade de prever do que de reagir a problemas, melhor aná-
lise de possíveis problemas e planejamento de ações corretivas e 1nelhores habil idades
de gerenciamento de negócios e1n toda a sua extensão.
Desenvolvimento profissional - Qualificação

A profissão da gestão de projetos é uma das muitas profissões globais que a IBM es-
tabeleceu para garantir a disponibi lidade e a qual idade de habi lidades profissionais e
técnicas dent ro de sua empresa. A iniciativa de Desenvolvimento Profissional da IBM
inclui uma liderança mundial da profissão de gestão de projetos, seus processos de
qua lificação, a relação da IBM com o Instituto de Gestão de Projetos (PMI) e o de-
senvolvimento de habilidades de gestão de projetos por meio da educação e mentoria.
Esses programas têm como objetivo cultivar conhecimentos e1n gestão de projetos e
programas e manter padrões de excelência na profissão. O objetivo máximo é desen-
volver a competência dos praticantes.
Qual é o contexto da profissão dentro da IBM? As profissões da IBM são comu-
nidades auto rreguladas de profissiona is habilidosos e co1n mentalidades similares que
realiza1n trabalhos simi lares . Seus me1nbros desempenham papéis sÍlnilares onde quer
que estejam nas organizações da IBM e independente do título de seu cargo atual.
Cada profissão desenvolve e oferece suporte à sua própria comunidade, incluindo a
assistência com o desenvolvimento profissional, desenvolvimento de carreira e de ha-
bilidades. As profissões da IBM:
• ajudam a empresa a desenvolver e 1nanter as ha bilidades críticas necessárias para
seus negócios;
• garantem que os seus clientes estejam recebendo melhores práticas e habilidades
consistentes na área de gestão de projetos; e
• ajudam os funcionários a assumirem o controle de suas carreiras e de seu desen-
volvimento profisional.
Todos os cargos da IBM foram agrupados em uma dentre várias diferentes áreas
funcionais chamadas de "famílias de cargos". Uma famíl ia de cargos é uma coleção
de cargos que compartilham funções ou habilidades si1nilares. Se não houver dados
específicos para determinado cargo, as responsabilidades do cargo são comparadas à
definição da família de cargos para determinar a famíl ia de cargos apropriada à qual
designar um profisiona l.
Os gerentes de projetos, e, de modo geral, os gerentes de programas, se enquadram
na família de cargos de gestão de projetos. Os cargos da gestão de projetos garantem
que as exigências dos cl ientes sejam satisfeitas ao longo da formulação, desenvolvi-
mento, i1nplementação e entrega de soluções. Os profissionais de gestão de projetos
são responsáveis pelo plano de projeto geral, orçamento, estrutura analítica do proje-
to, cronogra 1na, deliverables, requisitos de pessoa l, gerenciamento da execução e riscos
de projetos e a aplicação de processos e ferramentas de gestão de projetos. Os indiví-
duos têm de gerencia r os esforços da IBM e os funcionários do cl iente e também forne-
cedores terceirizados para garantir que se forneça uma solução integrada que atenda
às necessidades do cl iente. O cargo exige conhecimentos e habilidades significativas
em comunicação, negociação, solução de problemas e liderança. Especificamente, os
profissionais de gestão de projetos precisam demonstrar:
• Habi lidades em gerenciamento de relacionamentos com suas equipes, clientes e
fornecedores
• Conhecimentos especializados e1n tecnologia, indústria ou negócios
• Conhecimentos especializados e1n metodologias
• Um sólido julgamento na área de negócios
Oferecem-se orientações à gerência sobre classificação, desenvolvimento e ma-
nutenção da vital idade dos funcionários da IBM. No contexto da profissão de GP,
define-se vital idade como os profissionais cumprirem as exigências de habilidades,
conhecimentos, fonnação e experiência (critérios de qualificação) feitas pela gestão de
projetos, e1n um nível igual ou superior ao seu nível atual. São definidos critérios mí-
nimos de qualificação para cada etapa na carreira, e eles são usados pelos indivíduos
como compromissos de negócios ou objetivos de desenvolvimento, a lém dos alvos de

desempenho das unidades de negócios e individuais.
Profissionais habilidosos de gestão de projetos e progra1nas conseguem progredir
em seus planos de carreira para cargos com mais e mais responsabilidade. Para aqueles
com a dose certa de habilidades e experiência, é possível passar a cargos de gerencia-
mento de programas, a executivo de projeto e à gerência executiva. O crescimento e a
progressão na profissão são medidos por diversos fatores:
• Conhecimentos gerais de negócios e técnicos necessários para dese1npenhar o car-
go de maneira eficiente.
• Formação e habilidades em gestão de projetos para aplicar esse conhecimento
eficientemente.
• Experiência adquirida "na prática" que promova o conhecimento e habi lidades
profissionais e relacionadas a negócios.
• Contribuições para a profissão por 1neio de atividade que aumentetn a qual idade
e o valor da profissão para suas partes interessadas.
A profissão de gestão de projetos e programas na IBM estabeleceu um processo
end-to-end para "garantir a qualidade" do progresso pelo plano de carreira de gestão
de projetos. Esse processo chama-se "qualificação" e alcança quatro objetivos:
• Fornece um mecanismo em nível 1nundia l que estabelece um padrão para manter
e aumentar a excelência da IBM em gestão de projetos e programas. Esse padrão
baseia-se em habi lidades de1nonstradas, conhecimentos especia lizados e sucesso
em relação a critérios que são exclusivos da profissão.
• Garante que se apliquem critérios consistentes em todo o inundo ao avaliar candi-
datos para cada etapa no desenvolvimento da profissão.
• Maximiza a confiança do cliente e do mercado na qualidade dos profissionais
de gestão de projetos da IBM por meio do uso de sólidas d isciplinas de gestão
de projetos (i.e., uma ampla variedade de processos, metodologias, ferramentas e
técn icas de gestão de projetos e programas aplicadas pelos profissionais de gestão
de projetos na IBM).
• Reconhece os profissionais da IBM por suas habilidades e experiência.
O plano de carreira da profissão de gestão de projetos e programas da IBM permi-
te que os funcionários cresçam de um cargo de nível iniciante a um cargo de gerência
executiva. Os profissionais ent ram na profissão e1n d iferentes níveis, dependendo de
seu grau de maturidade em gestão de projetos. A validação das habil idades e experiên-
cias de u1n profisional é rea lizada por meio do processo de qualificação. O processo de
qua lificação é composto pela acreditação (nos níveis iniciantes mais ba ixos), certifica-
ção (em níveis 1na is altos e experientes), recertificação (para garantir que o profisional
se 1nantenha atualizado) e/ou mudanças de nível (passando para etapas superiores de
certificação). (Ver Figura 15- 5.)
Acreditação é o nível iniciante no processo de qua lificação. Ocorre quando o processo
de qua lificação da profissão avalia um profissional de gestão de projetos para as
etapas da carreira de associado ou consultor.
Certificação é a can1ada ma is alta do processo de qualificação e é destinada aos ge-
rentes de projetos e programas n1ais experientes. Ocorre quando o processo de
qua lificação da profissão avalia um profissional de gestão de projetos para as
etapas da carreira de gerente sênior ou gerente executivo. Essas etapas da car-
reira exigem u1n pacote de certificação n1ais forma l a ser concluído pelo gerente
Crescimento na carreira
Profissional executivo
Habilidades Profissional sênior

Experiência Certificação
Educação
Conhecimento Profissional de gestio de projetos nível consultor
Profissional de gestiio de projetos nível associado
Acreditação
Anos
O plano de carreira permite o crescimento de um nível iniciante para

um cargo de gerência executiva.
Figura 15-5 Plano de carreira em gestão de projetos e programas na IBM.
de projetos. O gerente autoriza o envio do pacote do candidato à Comissão de

Certificação en1 Gestão de Projetos. A Com issão de Certificação em Gestão de
Projetos da IBM, composta por especia listas da profissão, adm inistra o passo da
autenticação no processo de certificação. A Com issão verifica se as rea lizações
documentadas e aprovadas no pacote de certificação do candidato são válidas
e autênticas. Uma vez que a Comissão tenha ava liado que aquelas etapas foram
alcançadas, o candidato recebe a certificação de GP sên ior ou executivo.
Recertificação avalia profissiona is da IBM com certificação em gestão de projetos
para que eles se mantenham nas etapas de carreira de gerente sênior ou executivo.
A recertificação ocorre e1n um ciclo de e.ada três anos e exige a preparação de um
pacote em que um gerente de projetos docu1nenca o que ele tem feito em termos de
gestão de projetos, educação continuada e contribuições para a profissão desde o
último ciclo de validação.
A IBM continua seu compromisso com a melhoria de suas capacidades de ges-
tão de projetos, ampliando e oferecendo suporte a um exercício robusto e qualifi-
cado da profissão e oferecendo formação e treinamentos de qualidade em gestão
de projetos aos seus praticantes.
A abordage1n do plano de carreira e qualificação tem o suporte de uma estru-
tura integrada de recursos hu1nanos e de um progra1na de desenvolvimento profi-
sional chan1ado Estrutura de Carrreira IBM (!Blw Career Framework). A Estrutura
de Carrreira IBM é um 1nodelo de carreira que abrange toda a empresa para orien-
tar as carreiras dos funcionários e desenvolver as capacidades que mais importan1
para nossos clientes. A Estrutura fornece un1 processo fonna l para validar capaci-
dades demonstradas e programas de certificação existentes. Ver Figura 15- 6.
Ela oferece aos praticantes processos e ferramentas integradas relacionadas à
carreira, fo rnecendo, ao mesmo tempo, maior clareza e orientação sobre as habil i-
dades, capacidades e experiência de que os funcionários precisam para terem êxito
em seu ca rgo acuai. A Estr utura de Carreira integra as discussões sobre fortaleci-
A validação em dfferentes níveis fornecem as etapas de carreira que garantem que

os praticantes estejam adquirindo os conhecimentos, habilidades, capacidades
e experiências necessárias para fornecer valor aos clientes em cada nível.
Nivel Líder de
Capacidades Iniciante Experiente Especialista
fundamet1tal pensamento
Qualificações 1I GP associado : : consultor .

: t••oo, r - .
Habilidades
Habilidades
técnicas
..
{ Habilidades
intermediárias
de GP
Habilidades
básicas de GP
.
11, Habilidades
especiais
de GP
Habilidades
de liderança
Experiência / .__ ______________....

Capacidade
de iniciante
Capacidade
adquirida
Capacidade
aplicada
Capacidade
de domínio
Capacidade
executiva
Validação
Figura 15-6 Validação da estrutura de carreira.
mento e desenvolvimento de carreira entre gerentes e funcionários, especialmente

no que diz respeito à certificação.
Igua lmente importante para o desenvolvimento e a certificação dos gerentes de
projetos é um refinamento dos processos por 1neio dos quais eles são designados a
diferentes projetos. Os projetos são aval iados em termos de tamanho, implicações de
receitas, riscos, importância dos cl ientes, urgência do prazo, necessidade do mercado e
out ras características; os gerentes de projetos certificados são designados a eles depen-
dendo dos fatores exigidos de formação e experiência (ver Figura 15-7).
Oferece-se orientação à gerência quanto à classificação, desenvolvimento e ma -
nutenção da vita lidade dos funcionários da IBM. No contexto da profissão de GP,
define-se vita lidade como os profissionais cumprirem as exigências de habi lidades,
conhecimentos, formação e experiência (critérios de qualificação) feitas pela gestão
de projetos, em um nível igual ou superior ao seu nível atual. São definidos critérios
mínimos de qua lificação para cada etapa na carreira e eles são usados pelos indivíduos
como compromissos de negócios ou objetivos de desenvolvimento, a lém dos alvos de
desempenho das unidades de negócios e individuais.
Currículo de GP
O Currículo de GP da IBM (IBM PM Curriculum ) é um currículo global. O desen-
volvimento e a entrega desse currículo de G P coeso e de primeira qualidade foi u1n
elemento importante no estabelecimento de uma base consistente de terminologia e
conhecimentos de t rabalho para os mi lhares de profissionais de gestão de projetos e
programas professionais na IBM em todo o mundo. Um Comitê de Direç.ã o Curricu-
lar (CSC, Curriculum Steering Comtnittee), com representação global, gerencia seu
desenvolvi1nento, entrega e imple1nentação. Cada curso e1n sa la de aula é minist rado
da mesma forma em todos os países usando os mesmos materiais e insta lações com
instr utores loca is certificados para ministrar o curso. Os cursos de e-learning se encon-
tram nos servidores e são acessíveis 24 horas por dia, 365 dias por ano, por a lunos de
rodo o inundo. A formação de GP da IBM é minist rada via e-learning com 1nais de 100
mi l dias de cursos minist rados em 34 países.
Gestão de projetos Gerenciamento de programa

Lideres de pensamento slo
Líder de certificados e estio tentando obter
pensamento recertlllcaçlo com o Cunfculo
Avançado ou o Cunfculo de
~
e.,. Gerenciamento de Programas.
~
;;::
;::;
GPs especlat/stas slo certificados
e estio tentando obter
fS recertlf/caçlo com o Cun/culo
..., Especialista
Avançado ou o Cullfculo de
Gerenciamento de Programas.
GPs experientes slo acreditados e estio

tentando obter certlllcaçlo concluindo
Experiente a formaçlo do Culllculo Básico. GPs
experientes precisam ser certificados
~
e.,. para serem promovidos a especla//stas.
~
iS
lt! GPs n/vel fundamental estio tentando
~ Nível
obter acredltaçlo no Currículo Básico.
fundamental
Figura 1S-7 O processo de refinamento.
À medida que as necessidades dos profisionais de GP e as habilidades em cada

nível do cargo foran1 sendo n1ais bem con1preendidas e amadu recidas, o currículo de
GP foi construindo uma arqu itetura de diversos níveis (ver Figura 15- 8) que asso-
ciavam o conteúdo dos cursos às exigências de habi lidades necessárias para desen-
volver uma competência em gestão de projetos na IBM. A a rquitetura é composta
por: forn1ação básica en1 GP, que aborda os fundan1entos da gestão de projetos para
funcionários com experiência lin1itada ou inexperientes; formação de capacitação
en1 GP, que aprofunda e amplia as habi lidades de gestão de projetos con1 conteúdos
mais aprofundados; e a forn1ação en1 gerenciamento de programas, que aprofunda
as habilidades de GP aumentando as habilidades gerais de negócios e oferecendo
ferramentas e técnicas baseadas em projetos para gerenciar progran1as n1aiores com
múltiplos projetos e objetivos de negócios. Quando a arquitetura e o currículo foram
estabelecidos, criamos roteiros para que os a lunos pudessem faci lmente determ inar
que cursos fazer.
Organização do currículo de gestão de projetos

A maioria dos gerentes de projetos e programas da IBM cotneça sua formação em
gestão de projetos da IBM fazendo cursos seguindo o roteiro pela Educação Básica
de GP. Essa formação é criada para gerentes de projetos com experiência anterior
li1nitada ou sem experiência anterior em gestão de projetos que esteja tn tentando ob-
ter uma certificação da IBM. Dentro do cu rrículo de Educação Básica de GP da IBM,
também há um roteiro para os gerentes de projetos experientes que estejam tentando
o bter uma certificação. O Currículo Básico inclui cursos preparatórios para o exame
do PMI, incluindo o PMI Examination Preparation e o PMI'® Exam Prep Intensive
\Y/orkshop.
A fim de garantir que os a lunos deixetn o Currículo Básico com as habilidades de
GP IBM necessárias, aplicam-se exames no final da maioria dos cursos. O conteúdo
Capítulo 15 Excelência em gestão de projetos global 6 21
Gerência executiva 1
1
Formação em 1
ecutivo gerenciamento
de programas 1
ª'
~
o
e
Formação de :!
capacitação 1 ~
enior em gestão ;;a
1 :.!
de projetos e,
.,"'
Consultor
Formação
básica em
1
1
..
o
'l:J.
E
~
~
gestão de
projetos 1
soc,ado 1
Formação em gestão de projetos 1

para não gerentes de projetos
1
Figura 15-8 Arquitetura do currículo de gestão de projetos da IBM.
e o rigor de nosso currícu lo levou a George Washington University a declarar que o

Currículo Básico da IBM equivalia ao seu diploma de mestrado em gestão de projetos.
Vários cursos no cur rículo també1n são acreditados pelo Conselho Americano de Edu-
cação (American Council on Education) para créditos de graduação e pós-graduação
na América do Norte e pelo Cent ro Nacional de Informação sobre Reconhecimento
Acadêmico (NARIC, Academic Recognition Information Centre ) na Europa e Ásia.
A formação de capacitação em gestão de projetos é criada para aprofundar e ampliar
as habil idades em gestão de projetos. O público-alvo dessa formação varia de
acordo com o curso. Em geral, os cursos just-in-time e os cursos curtos de 2 a 4
horas de e-learning exigem que os a lunos tenham uma compreensão básica da
prática, 1nas não se exige que eles tenham concluído a Educação Básica. Ent re-
tanto, os cursos 1nais aprofundados presenciais ou de e-learning geralmente não
exigem a conclusão do programa Básico.
A formação em gerenciamento de programas é criada para aprofundar as habil idades
em gestão de projetos, ampliando as habilidades gerais de negócios e fornecendo
ferramentas e técnicas para gerenciar projetos, programas e portfólios de projetos
complexos. Os gerentes de projetos certificados pela IBM são o públ ico-alvo dessa
formação, já que eles geralmente são aproveitados para os projetos e programas
maiores e mais nnportantes.
A form ação em gestão de projetos para não gerentes de projetos contém cursos no
currículo de gestão de projetos para ajudar os gerentes e membros da equipe de
projetos que trabalham nas equipes de projetos ou que oferecem apoio a elas.
Além da formação específica em gestão de projetos e programas, todos os gerentes
de projetos precisa1n de uma formaç.ã o que os prepare para o ambiente específico e1n
que t rabalham. Essa formação pode ser específica para sua especialização, unidade de
negócios, indústria, país ou outros elementos relacionados a cada cargo. A fonnação
específica na área de atuação não é especificamente abordada pelo currículo de ges-
tão de projetos, mas é reconhecida co1no uma parte necessária do treinamento de u1n
gerente de projetos. A educação especializada, u1na parte da formação específica na
área de atuação é exigida para que um gerente possa obter a certificação de gestão de
projetos da IBM. Após a certificação, os profissionais recebem créditos pela formação
específica para sua recertificação.
Além do desenvolvimento de habilidades, a Universidade de GP oferece informa-
ções curriculares em um fonnato fácil de usar. Um "local" baseado na internet, essa
ferra 1nenta toma os cursos de formação em gestão de projetos e progra1nas e as ses-
sões de lições aprend idas mais fáceis de encontrar.
A IBM continua comprometida com a 1nelhoria de suas capacidades de gestão
de projetos, ampliando e oferecendo suporte a um exercício robusto e qualificado da
pr ofissão de gestão de projetos e fornecendo cursos de formação e treinamentos de
a lta qualidade aos seus praticantes.
A Universidade de GP possibi lita 1nelhorias contínuas em todos os tipos de cursos
de formação. Um exemplo foi a exigência de uma formação prática para ensinar os
a lunos a como começar a usar a metodologia de GP. Essa exigência esteve à frente da
criação de vários cursos avançados globais, abordando a aplicação da metodologia e
ferramentas globais de GP. Um outro exemplo foi na área de Contratação. Diferentes
países possue1n diferentes leis. O curso global não foi mod ificado, mas foram criados
vários cursos para diferentes países para abordar as exigências específicas de cont ra-
tação de cada país. Depois de os alunos concluírem o curso global para compreender
o processo de contratação, eles faziam o curso específico para compreender os pro-
cessos especia is necessários em seu país. A Universidade de GP oferece u1n roteiro e
u1n guia de inscrição para tratar das necessidades específicas de aprendizagem de cada
praticante.
Metodologias de gestão de projetos

Tony DeBellís/Lee Gay
Para oferecer às suas equipes métodos consistentes para implementar a gestão de pro-
jetos e1n todo o inundo, a IBM desenvolveu o Método Mund ial de Gestão de projetos
(\Vorldwide Project Management Method, WWPMM), que estabelece e oferece orien-
tações sobre as melhores práticas de gestão de projetos para definir, p lanejar executar
e controlar u1na ampla variedade de projetos. O Método M undial de Gestão de pro-
jetos da IBM (\V\VPMM) é uma resposta à ação do Conselho Executivo Corporativo
(CEC, Corporate Executive Council), tomada para estabelecer um único método co-
mum de gestão de projetos para os projetos da IBM em todo o mundo. O WWPMM
é uma implementação do Guia PMBO K4' do PMI, criado para o ambiente da IBM.
Em 2012, o WWPMM foi aprimorado, passando a incluir extensões de gerenciamento
de progra1nas à medida que a complexidade da entrega dos projetos e programas se
intensificasse.
As atividades do processo de gestão de projetos podem ser classificadas em qua-
tro grupos básicos: "definir", "planejar", "executar" e "controlar", "encerrar". Um
projeto normalmente consiste em uma série de fases, con hecidas como o ciclo de vida
do projeto, e esses grupos de atividades de processos podem ser aplicados a cada fase
individualmente ou a u1n conjunto de d iversas fases.
No grupo "definir", chega-se a u1n acordo quanto aos objetivos do projeto, esta-
belece-se o escopo do projeto, define-se a organizaç.ã o inicial, d istribuem-se responsa-
bilidades e documenta-se a avaliação dos fatores situaciona is.
No grupo "planejar", traça1n -se planos deta lhados de t raba lho e de r isco, confir-
ma-se a organ ização e fazem-se designações de pessoa l. Nenhu1na quantidade signi-
ficativa de recursos pode ser gasta no projeto (isto é, a execução não começa) até que
u1n claro plano esteja t raçado e que a autorização para prosseguir tenha sido recebida
no final dessa fase.
No grupo "executar" e "cont rolar", usam-se os planos e cont roles para execu-
tar e gerenciar o projeto à medida que o traba lho de desenvolvi1nento e entrega são
realizados. Conforme o trabal ho progride, os planos são expand idos ou refinados de
acordo cotn a necessidade.
No grupo "encerramento", o patr ocinador concorda em encerrar o projeto, encer-
ra-se o projeto e produz-se o relatório de avaliação (também con hecido cotno lições
aprend idas).
Durante a vida de um progratna e a dos projetos, várias dessas atividades podetn
estar ocorrendo e reocorrendo concotnitantemente. A medida que os programas são
definidos e planejados, identificam-se projetos, que, por sua vez, são definidos, plane-
jados, executados, controlados e encerrados. Enquanto os progra tnas são executados
e controlados, reavaliações periód icas dos objetivos podem levar à identificação de
novos projetos a serem definidos ou de projetos a serem encerrados por não mais
gerarem valor. Enquanto um projeto é executado, é comum que os planos sejam rede-
fin idos no final de a lgumas fases, para preparar a execução das fases seguintes.
A fim de ser genérico e aplicável etn toda a IBM, o método de gestão de projetos
não descreve fases do ciclo de vida, tnas, em vez disso, grupos de atividade de GP que
podem ser usados repetidamente ao longo de qua lquer ciclo de vida. Isso perm ite a
flexibilidade para o método ser usado com qualquer número de a bordagens técnicas e
ciclos de vida. (Ver Figura 15-9.) O \V\VPMM é o modo como os projetos e progra-
mas são gerenciados na IBM e é implementado em todo o mundo por meio de uma
variedade de métodos e sistemas de gerenciamento específicos a cada unidade de negó-
cios como o Método Global de Serviços (GSM, Global Services lvfethod) e o Desenvol-
vimento Integrado de Produtos (IPD, Integrated Product Development), entre outros.
Grupos de processos do WWPMM podem

ser usados iterativamente nas fases do IPD
~
Desenvolver/ Qualificar/ Ramp-up/ Ciclo Encer·

Conceito Plano
Fases do IPD Validar Certificar lançamento de ramento
vida
.
' •
'
'' •••
'
'' •••
' •
' •
Pontos de decisão do IPD DCP do DCP do DCP da DCP do fim do
conceito plano disponibilidade ciclo de vida
Grupos de processos do WWPMM

Definir tarefas n
Planejar tarefas • • • e
Executar/Controlar tarefas a
Encerrar tarefas a a:
Exemplo: Dentro da ta.se ds Conceito do IPO. a maioria das !areias se classifica nos grupos de processo Definir ePlanejar.
embora haja tardas que também se enquad,em nos grul)O$ de processo Executar/Controlar e Encerrar.
Figura 1S-9 Método Mundial de Gestão de Projetos da IBM.

O WWPMM contém documentação de referência (domínios), passos de processos

(padrões de trabalho) e produtos ou templates de trabalho para co1nponentes desiste-
mas de GP além de material de suporte que explica o uso do WWPMM. O WWPMM
descreve como dar forma e planejar um projeto e, então, gerenciar sua execução por
meio de três visões inter-relacionadas (ver Figura 15- 10): o \VWPMM ajuda a definir
o Sistema de Gestão de Projetos, u1na coleção de planos, procedi1nentos e registros que
d ireciona todas as atividades de GP. Ele descreve o estado atual e o histórico do pro-
jeto, incluindo as mét ricas necessárias para acompanhá-lo e med i-lo. Pode-se fazer o
download de templates genéricos da página de referência do \VWPMM e por meio de
várias ferramentas de GP. Quando utilizado com ferramentas apropriadas e integrado
com sistemas de gerenciamento de negócios e técnicos, esse 1naterial fornece u1n amplo
ambiente de GP. Ele define também a documentação que será criada e entregue bem
como o 1nodo e o local onde essa documentação será armazenada.
Para responder à necessidade de ser flexível, os templates e produtos de trabalho
do Sistema de Gestão de Projetos podem ser personalizados de modo a atender aos re-
quisitos específicos de áreas geográficas, de linhas de negócios ou de cl ientes, manten-
do, ainda, nosso compromisso com" um único método comum de gestão de projetos".
Os gerentes de projetos, programas ou portólios podem garantir que seus gerentes de
projetos estejam usando u1n sistema apropriado para o r isco e a complexidade das
necessidades específicas de seus projetos e linhas de negócios.
O siste1na de gestão de p rojetos é exclusivo para cada projeto. As políticas vigen-
tes de uma organização, os 1nétodos técnicos e de negócios e os métodos de GP da
Metodologia Mundial de Gestão de Projetos (W\VPMM) fornecem uma base para um
abrangente sistema de gestão de projetos (ver Figura 15- 11). O siste1na deve, então,
ser adaptado às necessidades de cada projeto individua l pa ra dar conta da co1nplexi-
dade do projeto e do clima de negócios do ambiente em que o projeto se encontra. Os
gerentes de projetos determ inam que proced imentos, processos e ferramentas são me-
lhores para seus projetos, dependendo dos padrões ou da o rientação que foi definida
pela unidade de negócios. Usar um sistema de GP ajuda a garantir que cada equipe de
projetos esteja traba lhando e1n um ambiente estruturado e cont rolado, traba lhando
e1n direção aos mesmos objetivos do projeto.
No entanto, mesmo com nossa própria metodologia, a IBM se mantétn sincro-
nizada com o que está acontecendo na indústria e com a resposta aos requisitos da
un idade de negócios. Ágil é uma outr a abordagem técnica usada para desenvolver
software e soluções de TI na IBM. Embora a indústria a tenha empregado há anos, a
IBM agora está expandindo seu uso à medida que os cl ientes cada vez 1nais solicitam
que a IBM utilize técnicas ágeis .
Padrões de
trabalho
Produtos
Domíni de trabalho
Figura 1S-10 As visões inter-relacionadas do WWPMM da IBM.

1 ~ JtT"
1 JPO CRM
1
1 SITO JPO
ww V -
/ Processos de negócios
"
/
- V
Meu
sistema / '\
I \
cn
·-"'
/ de GP
'-
WWPMM
. .'"''". . . . 1.
e-~__...""-
u
•
-o
""
Q.
'
\
'-.
'\. /
•
.
./
1 IPO !
' I'-.
Q 1
1 BTOP I
Método Global de Servir.ns da IBM (GSM /
' V
-
- Métodos técnicos -
-
Figura 1S-11 A Metodologia Mundial de Gestão de Projetos (WWPMM) fornece uma base para um
sistema abrangente de gestão de projetos.
Na IBM hoje, a maioria dos projetos ágeis são partes de projetos maiores de de-
senvolvimento ou de serviços. Assim, é necessário um gerente de projetos para garantir
que os deliverables do projeto maior sejam entregues e os requisitos do sistema de
gerenciamento de negócios sejam cUinpridos. Para projetos em que o desenvolvi1nento
ágil co1npreende todo o projeto, os requisitos e cont roles de gerenciamento de negó-
cios a inda têm de ser seguidos. Para lidar com esses requisitos do sistema de gerencia-
mento de negócios, o Método Mundial de GP da IBM (WWPMM) é projetado para
ser ampliável e adaptável para que possa atender às necessidades de todos os projetos,
inclusive dos ágeis. A IBM oferece orientação aos seus gerentes de projetos sobre como
o \V\VPMM pode ser racionalizado para projetos ágeis e como as disciplinas e com-
portamentos de GP podem ser apl icados para abraçar a agilidade mantendo, ainda, os
cont roles de negócios necessários.
Um método, por mais robusto que seja, gera lmente não é tão eficiente sem uma
ferramenta que possibil ite sua aplicação prática. Uma maneira eficiente de implemen-
tar o \V\VPMM é por meio de ferramentas que ofereçam a capacidade de ent regar
pratica1nente todo um sistema de gestão de projetos em um único local acessível pela
internet, além de imple1nentar e integrar um método técnico. Por meio do uso de seus
te,nplates pré-aprovados e de seu monitoramento de rotinas, uma equipe de projetos
pode implementar o sistema apropriado de gestão de projetos.
Melhores práticas
Uma busca na internet das palavras-chave " ib1n + melhores práticas" gera literalmente
mi lhões de respostas. Uma melhor prática pode ser definida como um método, proces-
so ou técn ica para produzir um resu ltado que tenha provado gerar um resultado de-
sejado de maneira 1nais confiável e previsível do que out ras técn icas. Ao longo de sua
história, a IBM já desenvolveu 1ni lhares de melhores práticas para muitos diferentes
aspectos da tecnologia da infonnação. Elas foram produzidas com muitos níveis dife-
rentes de rigor e forma lidade. No mundo técn ico, essas mel hores práticas podem ser
publicadas como white papers ou, mais formalmente, na série de publicações Redbook
da IBM. Na disciplina de gestão de projetos na IBM, não é diferente. Desde 1996, a
IBM vem desenvolvendo mu itas melhores práticas em gestão de projetos. O PM/COE
tem a função de comunicar e informar as partes interessadas na gestão de projetos da
e1npresa sobre essas melhores práticas.
Como discutido anteriormente neste capítulo, estabeleceu-se um conjunto de ini-
ciativas-chave de gestão de projetos como o cerne da abordagem para imple1nentá -la
na empresa. Em parceria, o PM/COE e as unidades de negócios de toda a IBM tra ba-
lharam na implementação de oito iniciativas-chave que formaram o fundamento da
visão da IBM em relação à implementação de sua gestão de projetos empresarial. As
o ito iniciativas-chave incluem (ver Figura 15- 12):
• Educação
• Qualificação
• Método
• Projetos selecionados
• Ferramentas
• Gerenciamento de portfólios
• Maturidade
• Política
Dentro de cada iniciativa, desenvolveram-se melhores práticas que servem de su-
porte à implementação na organ ização. Algu1nas delas fo ra 1n mencionadas anterior-
mente, 1nas esse quadro serve de base para as medidas em relação às qua is o progresso
da IBM ru1no a se tornar uma empresa baseada em projetos é aval iado.
Educação
A abordage1n da IBM da formação em GP foi descrita em linhas gerais em uma seção
anterior. O cur rículo de GP, roteiro e abordagem da formação foram uma melhor
prática muito formal na IBM por diversos anos. Todos os gerentes de projetos da IBM
são ensinados co1n o mesmo currículo e as mesmas mensagens, que evoluíram com o
passar do tempo à medida que a IBM amadureceu e1n gestão de projetos. Essa mel hor
prática é mantida em um conjunto de docu1nentos que são supervisionados por uma
pequena equipe do quadro de funcionários e por um comitê de direção.
Organização da Gestão de Projetos Empresarial (EPM)

demonstrando valor de negócios
Gerenciar pipeline Dirigir negócios Manter uma organização

de GP certmcados baseados em projetos madura em GP
Educação I Qualificação I Método I Cobertura 1~ rramentas I Maturidade I G;;e;::~~:o I Políticas
Figura 15-12 Dentro de cada uma das iniciativas, desenvolveram-se melhores práticas que
servem de suporte à implementação na organização.
Qualificação
A abordagem da IBM para qualiicar e certificar gerentes de projetos ao longo de suas
carreiras 1nost rou gerar valor para nossos clientes, para nossos gerentes de projetos e
para a etnpresa. Essa abordagem é documentada como uma melhor prática no Guia
Profissional da Gestão de Projetos e mantida mediante aprovação por um comitê de
desenvolvimento profisional. Uma pequena equipe supervisiona a administraç.ã o dessa
melhor prática. O material e as atualizações são comunicadas à comunidade de gestão
de projetos por meio do programa de comunicações do PM/COE para garantir que
todos os gerentes de projetos de todo o mundo estejam aderindo ao mesmo processo
de qua lificação.
Método
A IBM foi orientada a 1nécodos por muitos anos. O desafio da gestão de projetos
era fazer toda a empresa se reun ir sob um método un ificado de gerenciar projetos.
E1nbora haja muitas dezenas de 1nécodos técnicos mantidos pela IBM para definir os
diferences aspectos da realização do traba lho, há apenas um método para gestão de
projetos usado por todas as partes da IBM em muitos tipos diferences de projetos.
O WWPMM (Método Mundial de Gestão de Projetos) foi descrito em uma seção
anterior e é a melhor prática da IBM para gerenciar projetos. Ele é mantido pelo
PM/COE e atua lizado periodicamente para que reflita as mudanças nos requisitos. As
unidades de negócios da IBM, na maioria dos casos, adaptaram o \V\VPMM aos seus
processos de gerencia1nenco.
Projetos selecionados
E1nbora Formação, Qualificação e Método seja1n melhores práticas da IBM co1n u1na
docu1nencação e mecanismos de suporte mu ito formais, Projetos Selecionados é u1na
melhor prática mantida de forma muito diference. Um dos princípios fundadores es-
tabelecidos quando o PM/COE se formou foi que projetos "selecionados" seriam ge-
renciados pelos gerentes de projetos mais qualificados. Devido à variedade do modo
como diference.s partes da IBM operam e dos funcionários que a empregam em suas
atividades, esta melhor prática é definida, em conceito, em um alco nível, e o PM/
COE t rabalha com as diferences un idades de negócios para desenvolver um modelo
que funcione para seu negócio. Ela ainda é considerada uma melhor prática porque
a premissa é muito importante para o sucesso da gestão de projetos, contudo, não se
encontra uma documentação deta lhada dos processos da prática.
Ferramentas
Quando a IBM con1eçou a jornada run10 à gestão de projetos empresarial, n1uicas di -
ferences ferramentas eram usadas para gerenciar nossos projetos. Isso era 1nuico ine-
ficiente, canto no custo para manter n1uicas ferran1encas quanto pela ineficiência de
recursos para constitu ir projetos con1 indivíduos que conhecessem as ferran1encas. O
PM/COE, traba lhando co1n as diferences partes do negócio, selecionou u1na ferramenta
estratégica para usar para a gestão de projetos. Isso pern1itiu un1 melhor investimento
na ferra1nenca, alén1 de sua integração con1 elen1encos-chave, con10 contabilidade tra-
ba lhista. Uma equipe trabalhando con1 o PM/COE mantinha n1elhores práticas para a
in1plen1encaç.ão da ferra1nenca aos negócios. À 1nedida que novas unidades começara1n
a implementar a ferramenta para sua organização, essas 1nelhores práticas passan1 a ser
seguidas para n1ini1nizar proble1nas e sin1plificar a i1nple1nencação.
Gerenciamento de portfólio
O Gerencian1enco de Portfólio de Projetos agrupa, visualiza, analisa e gerencia projetos a
fin1 de maximizar os resulcados de negócios positivos dentro das restrições de recursos de
un1a organização. Os projetos ou são incluídos ou excluídos do portfólio, dependendo de

seu al inhamento con1 a estratégia e de seu desen1penho em relação aos objetivos de negó-
cio. A IBM possui uma política publicada forn1al que é nossa melhor prática para geren-
ciamento de portfólios. O PM/COE trabalha con1 as un idades de negócios para adaptar
essa política aos seus processos de negócios para gerenciar seu portfólio de projetos.
Maturidade
A IBM desenvolveu uma ferramenta-padrão e melhor prática, o Guia do Progresso da
Maturidade da Gestão de Projetos (PMPMG, Progress Mat11rity G11ide), para 1nedir
a maturidade da gestão de projetos. O PMPMG permite que uma organização ava lie
a 1naturidade de suas capacidades tanto no nível do projeto quanto no nível organi-
zacional. Ao compreender seus pontos fortes e fracos nessas áreas, uma organização
pode identificar ações para melhorias contínuas ao gerenciar projetos/programas e
alcançar seus objetivos de negócios. O PMPMG consiste em um conjunto de pergun-
tas objetivas separadas em cinco níveis e que busca1n informações sobre os processos
de GP em uso. Quando concluído, uma 1nédia ponderada das respostas é usada para
calcular um va lor relativo para a maturidade da organização. No guia, as perguntas
se aplica1n ou à organização como um todo, ou a projetos dentro da o rgan ização. A
execução bem-suced ida da ferramenta leva rá a uma pontuação de 1 a 5 e1n maturi-
dade uma lista de itens de ação para abordar as deficiências. O PM/COE mantém o
PMPMG como u1na ferramenta e banco de dados do Lotus Notes e auxi lia diferentes
unidades de negócios com o desempenho das aval iações.
Política
O PM/COE mantém práticas corporativas fo nnais para a gestão de projetos e progra-
mas que definem o conjunto recomendado de práticas de gerenciamento que devem
ser usadas para todos os projetos e programas da IBM. Essas práticas são uma mel hor
prática de nível corporativo formal à qua l se espera que toda a empresa venha a aderir.
A fi 1n de lidar com a variedade de tipos de negócios na IBM, o PM/COE, então, traba-
lha com e.ada unidade para desenvolver sua própria declaração de política que adote
as práticas corporativas e outras iniciativas e as adapte a todas as especificidades de
sua organização. Essas políticas das unidades são patrocinadas pelos pat rocinadores
executivos da gestão de projetos das organ izações e publ icadas na int ranet do PM/
COE para que todas as partes interessadas da gestão de projetos possam facihnente
visualizá-las.
Essas o ito iniciativas compreendem uma grande coleção de melhores práticas em
gestão de projetos que foram os pilares da caminhada da IBM em direção à gestão de
p rojetos empresarial. O PM/COE mede o progresso da IBM co1no empresa moni to-
rando essas iniciativas por meio do uso de um scorecard Vermelho/AmareloNerde,
que é atua lizado trimest ralmente para cada pa rte do negócio e cada área geográfica do
mundo. Quando ocorre1n mudanças, como reorganizações, mudanças no mercado ou
ações da liderança executiva, ve1nos o 1novimento no desempenho refletido em nosso
scorecard. O PM/COE trabalha com a Equipe de Direção Executiva para ajuda r a cor-
rigir á reas problemáticas, mantendo a empresa no caminho certo e1n relação ao nosso
p rogresso em tennos de maturidade.
No entanto, as melhores práticas não param aí. O suporte de nossos profissionais
também está no cerne da t ransformação baseada em projetos.
Compartilhamento de conhecimentos
Em bora as o ito iniciativas sejam melhores práticas mais forma lizadas, existe a oportu-
nidade de tira r proveito das lições aprendidas em atividades dos gerentes de projetos
da IBM. A Rede de Conhecimento de GP (PMKN, PJ\1 Knowledge Network ) ofere-
ce suporte à transformação da IBM e1n u1na e1npresa baseada em projetos tirando

proveito do compartilhamento de conhecimentos e da reutilização de ativos (capital
intelectual). O repositório da PMKN serve de suporte à Comunidade da PMKN, co1n
uma ampla variedade de ativos que inclui templates, exe1nplos, estudos de caso, for-
mulários, white papers e apresentações sobre todos os aspectos da gestão de projetos.
Os praticantes pode1n navegar, fazer do,vnload ou reutil izar qualquer um dos mais de
2.400 itens para auxi liar seus projetos, suas propostas ou sua compreensão.
Comunidade e comunicações
Segundo Debi Deli, PMP®, Gerente do Centro de Excelência em Gestão de Projetos, a
IBM criou u1n forte senso de comunidade para seus profissiona is globais de gestão de
projetos; esta é uma melhor prática entre as profissões da IBM.
Na IBM, uma comunidade é defin ida como um grupo de profissionais que compar-
ti lham u1n interesse específico, trabalham em detern1inado don1ín io de conhecin1ento
e participan1 de atividades que são n1utuan1ente benéficas para constru ir e sustentar
capacidades de desempenho. Nossa comunidade focaliza-se em seus n1en1bros e en1 criar
oportun idades para que eles achem seu trabalho significativo, aun1entem seu conheci-
mento e don1ínio de un1a área e tenhan1 um senso de fazer parte de um grupo - que eles
achen1 que têm os recursos necessários para obter ajuda, inforn1ação e suporte em suas
vidas profissionais. O con1partilhamento de conhecimento e a reuti lização de e.apitai
intelectual são uma parte importante daquilo que un1a con1un idade possibilita, n1as não
são seu único foco. As comunidades geran1 va lor para o negócio por meio da reduç.ão
de atritos, da redução da velocidade do fechan1ento de vendas e do estímulo à inovação.
Comunidades fazem parte da malha organizacional, mas não são defin idas ou
restringidas por seus limites. Na verdade, as comunidades criam u1n e.anal para que o
conhecimento cruze limites Ílnpostos pelo fluxo de t raba lho, geografias e te1npo e, ao
fazê-lo, fortalecem a malha social da organização. Elas fornece1n os meios para trans-
formar know-how local em informações coletivas e para dist ribuir informações coleti-
vas de volta ao know-how local. A participação é integralmente baseada em interesse
em um assunto e é voluntária. Uma co1nun idade NÃO é limitada por uma prática,
uma rede de conhecimentos ou qualquer out ro conceito organizacional.
A Co1nunidade da Rede de Conhecimentos de GP (PMKN) é patrocinada pelo
PM/COE. A participação é aberta a todos os funcionários da IBM que tenham u1n
plano de carreira profissiona l ou interesse e1n gestão de projetos. A PMKN é uma
comunidade de prática autossuficiente com quase 12 m il membros que se reúne1n
para o aprimora1nento geral da profissão. Os membros compartilham conhecimentos
e criam capita l intelectua l em GP. A PMKN oferece um ambiente para compartilhar
experiências e se conectar com outros colegas gerentes de projetos.
Ao entrar na co1nunidade de GP, os profissionais contratados pela IBM gera lmente
são indagados: "Qual é a n1aior diferença cultura l que você encontrou na IBM en1 rela-
ção a outras empresas em que você já trabalhou? " . A resposta mais co1nu1n é que seus
colegas são ext ren1an1ente prestativos e estão dispostos a comparti lhar informações,
recursos e ajuda con1 as atribuições de suas funções. A cultura da IBM se presta gracio-
samente à mentoria. Como a contribuição com a profissão é uma exigência para a cer-
tificação, agir co1no mentor de candidatos que estão en1 busca da certificação não so-
mente atende a un1a exigência profissional, n1as tan1bém contribui com a co1nunidade.
A mentoria pode ser um relaciona1nento frági l. Um estudo sobre o mundo corpo-
rativo revelou que o motivo mais comum pelo qual os relacionamentos de mentoria
terminavam pre1naturamente era a ausência de uma estrutura ou objetivo forma l para
manter o anda,nento do t raba lho. Além disso, não havia uma ferramenta mundial de
mentoria. O Centro de Excelência e1n Gestão de Projetos respondeu ao estudo criando
utn "Processo de Mentoria de Habi lidades em Gestão de Projetos". Seguindo as 1nes-

mas linhas da d isciplina da gestão de projetos, criou-se um processo de mentoria para
acompanhar os conceitos básicos de um projeto. Um relacionamento de 1nentoria ti-
nha um começo definido, um resultado desejado para o projeto (elevar o nível de uma
habi lidade ou área de conhecimento), um plano, utn cronograma, marcos, seguimento
e conclusão. Há exemplos de planos de 1nentoria, acordos, marcos e documentação
de encerramento juntamento com um Guia de Mentoria de Habi lidades etn GP (PJ\11
Skills Mentoring G11ide) no site da etnpresa.
Para se endereçar às comun idades e a todos os profissionais de gestão de projetos,
os canais de comunicação primários incluem o site do PM/COE e boletins e avisos
d irecionados podem ser adicionados ao perfil de gestão de projetos corporativa. En-
t retanto, à medida que a profissão de gerente de projetos vai crescendo, au1nentam
também as exigências por projetos direcionados a comunidades específicas. O Centro
de Excelência em Gestão de Projetos desenvolveu infonnações para as seguintes comu-
nidades com a profissão de GP:
• Iniciantes na profissão
• Gerentes de gerentes de projetos
• Gerência intermed iária
• Rede de conhecimentos sobre GP
• Comunidades de GP de geografias específicas
Porém, as melhores práticas da IBM não são reconhecidas somente dentro da em-
presa. Muitas delas já receberam o reconhecimentos de fonte.s da indústr ia.
Segundo Debi Deli, em várias propostas, o Centro de Excelência em Gestão de
Projetos acompanhava os prêm ios e realizações e compartilhava esses feitos com toda
a IBM, a comunidade de GP e com cl ientes. A seguir temos uma uma lista pa rcial de
atividades que rea lçam onde a IBM foi reconhecida por sua excelência em gestão de
proJetos.
Prêmios
• Prêmio de Ouro 2012 do Grupo Brandon Hall na Categoria de Melhor Empresa
em Programas de Certificação
• Prêmio APQC 2012 de Escritório de Gestão de Projetos do Ano
• Prêmio PMI 2012 de Provedor de Educação Continuada pela Universidade de GP
• Prêm io de Ouro 2011 do Grupo Brandon Hall na Categoria de Excelência em
Aprendizagem
• Prêmio PMI 2011 de Produto do Ano em Educação Continuada: Pacote de Apren-
dizagem Ági l
• Prêmio PMI 201 O de Escritório de Gestão de Projetos de Soluções em GP do Ano
• Prêmio PMI 2009 de Provedor de Educação Continuada pelo Currículo de GP
• Prêmio PMI 2007 para Projeto Destaque (Projeto da IBM de Imposto de Conges-
tionamento de Estocohno)
• Prêmio PMI 2006 de Provedor de Desenvolvimento Profissional do Ano
• Prêmio PMI 2006 de Provedor de Educação do Ano PMI
• Prêmio PMI 2005 de Provedor de Desenvolvimento Profissional do Ano
• Prêmio PMI 2005 ao Direto r do PM/COE (C. Wright) por Contribuição de
Destaque
• Prêmio PMI 2005 Provedor de Desenvolvimento Profissional do Ano
• Prêmio de Patente 2001 pelo "Learn How... Do lt Now..." - Equipe de Cur rículo
em GP
• Prêm io 2001 da lnternationa l Sociedade Internacional para a Melhoria no

Desempenho (Society for Performance Improvement, ISPI) pelo curso no Lotus
LeamingSpace sobre excelência e1n cont ratos em gestão de projetos
• Prêmio 2000 de Excelência na Prática da Sociedade A1nericana para Treinamen-
to e Desenvolvimento (American Society for Training and Develop-rnent, ASTD ),
reconhecendo a excelência em treinamento e processos de desenvolvimento de
carreira.
• Março de 1998: Prêmio de Ouro do Giga Information Group: o Sistema de Ge-
rencia1nento de Capita l Intelectual da IBM.
Currículo
• O currículo em GP continua a ser reconhecido com nosso curso de e-learning
"Contratos para Gerentes de Projetos" pela Sociedade Internacional para a Me-
lhoria no Desempenho (Society for Perfonnance Improvement, ISPI), com um prê-
mio por sua excelência.
• Reconhecido pela Sociedade A1nericana para Treinamento e Desenvolvimento
(American Society for Training and Develop-rnent, ASTD ) co1n um prêmio de ex-
celência na prática por sua iniciativa relativa ao currículo de gestão de projetos.
• O Conselho Americano de Educação (American Council on Ed11catio11, ACE) re-
comendou nossos cursos Nível 1 para equivalência de créditos em programas de
gradução e pós-gradução.
Externo
• Participação do Diretor do Cent ro de Excelência e1n GP da IBM como principal
orador no webinar lnternationa l Project Management Day da IIL (2011 )
• Participante-chave da IBM no conselho PMI de Gestão de Projetos Corporativos
- e1n andamento
Publicações
• Forbes Magazine "Pulse of t he Profession with PMI" (março de 2012)
• Keys to Building a S11ccessf11/ Proiect Management Office (© 2011 IBM)
• PMO of the Year e-book (© 2010 PM Solutions)
• IBM PM history (Chapter 15), Best Practices in Project Management, Harold
Kerzner (2009)
• Centro de Excelência em GP da IBM reconhecido como uma das 25 melhores
organizações baseadas em projetos em 2007 pelo PMI
• Práticas de GP da IBM citadas em Technical Business Review Report em 2007
Coordenadora do material
Deborah (Debi) A. Deli, PMP®é Gerente do Centro de Excelência em Gestão de Pro-
jetos da IBM. Em seus 33 anos de experiência na IBM, Debi já teve cargos de gestão
de projetos, planejamento de negócios, tecnologias móveis e sem fio, e planeja ,nento
de 1nercado e produto. Foi coautora de ThinkPad: A Different Shade of Blue em 1999.
Debi é certificada pelo PMI e possui título de mestrado em gerenciamento de tecnolo-
gias e títu los de graduação e 1nestrado em admin istraç.ã o de empresas.
Contribuidores
Mike Collins é atuahnente Gerente de Projetos Executivo no Centro de Excelência em
Gestão de Projetos da IBM. As tarefas atuais de Mike incluem o suporte à implemen-
tação da gestão de projetos global em u1na unidade de negócios e a liderança dos pro-
jetos Valor da Gestão de Projetos e Métricas Mundia is de GP da IBM. Anterionnente,
M ike t rabalhou como Gerente de Entregas e Executivo de Projetos na IBM G lobal

Business Services gerenciando um portfólio de projetos de desenvolvimento para o es-
tado de NY, EUA. Mike é Gerente de Projetos Executivo certificado pela IBM e PMP®
há mais de 10 anos, possui 26 anos de experiência na indúst ria e é membro do Co1n itê
de Certificação em GP da IBM.
Steve DelGrosso, PMP®é Diretor do Centro de Excelência em Gestão de Projetos
da IBM. Em seus 34 anos de experiência em diferentes áreas de especialização da in-
dústria de TI, $teve já trabalhou co1no líder norte-americano da Profissão de GP na
IBM, gerente, desenvolvedor e instrutor de Engenharia de Siste1nas para o C urrículo
de GP da IBM e também leciona gestão de projetos a alunos de pós-graduação da
University of Miami em Cora l Gables, Flórida, EUA. Steve é membro do PMI College
of Performance Management, GovSIG e do comitê editorial do PM Journal. Steve já
publicou artigos nas revistas Industrial Engineer e Personal Systems jo·urnal e foi capa
da revista PM Network do PMI na edição de abril de 2004.
J ohn Marrine é GP executivo no Centro de Excelência em GP da IBM (PM/COE).
Passou seus últimos 20 anos em cargos de gestão de projetos e Executivo de Projetos.
John também já ocupou d iversos cargos de gerência durante sua carreira na IBM.
Possui certificações de Executivo de Projetos pela IBM e PMr® pelo PMI, tendo obtido
d iplomas de bacharelado em engenharia elétrica e ciência da computação.
Sandy Steinruck é engenheira mecânica por formação, mas tetn trabal hado com
gestão de projetos há ma is de 25 anos na IBM. Começou em projeto de produtos,
gerenciando projetos de desenvolvimentos de impressoras e copiadoras, sendo então
t ransferida para a Flórida, onde passou 10 anos gerenciando projetos de desenvolvi-
mento de software e de integraç.ã o na indústria de telecomunicações. Por seu tr abalho
com gestão de projetos, recebeu o prêmio de Excelência em GP em 1998. Sandy é
membro do Centro de Excelência em GP da IBM como Gerente de Programas do pre-
miado Currículo de GP da IBM há 12 anos.
15.2 Computer Assoe iates Technologies (CA): sucesso

na entrega e na gestão de projetosª
Introdução
CA Technologies é líder no fornecimento de software independente de soluções em
gerenciamento de TI. Os clientes procuram a CA para prover soluções que gerenciem e
garantam a 1n bientes co1nplexos de TI em toda a empresa para a obtenção de mel hores
resultados. A organização de serviços profissiona is da CA Technologies, a CA Services,
ajuda cl ientes a imple1nentar, atualiza r e otimizar soluções há ma is de 35 anos. Duran-
te esse tempo, a apl icação de lições aprendidas e mel horias contínuas resu ltou em uma
estrutura madura de entrega e gerenciamento bem-sucedidos de p rojetos.
Hoje, a maioria das empresas uti liza técnicas-padrão de gestão de projetos e, ain-
da assim, as taxas de sucesso dos projetos permanecem ba ixas. O sucesso de um pro-
jeto tipicamente depende das habilidades e, às vezes, do heroísmo das pessoas a ele
designadas, enquanto empresas de classe mundial conseguem repetir o sucesso em
projetos de forma consistente. A CA Services reconheceu que, para alcançar o sucesso
repetível em projetos, precisamos ir além das mel hores práticas costumeiras de geren-
3
€>2013 by Compurer Associares. Reproduz.ido com permissão. Todos os direitos reserYados. O material
sobre a Computer Associares foi fornecido por Robert J. Zuurdeeg, consultor sênior de práticas globais, e
lvlark Elkins, diretor do PMO de serviços.
ciamento de projetos: as equipes de projetos precisa1n de um arsena l co1nprovado de

ferramentas, processos e suporte.
Quando uma organização completa um projeto com êxito, a equipe provavelmen-
te possui uma sólida gestão de projetos, deliverables de a lta qua lidade, um produto
que gerou valor para as pa rtes interessadas e uma metodologia de entrega que funcio-
nou. A maioria das organizações não tira proveito desses fatores de sucesso, aplican-
do-os a outros projetos. A documentação do projeto é arquivada, e a equipe se separa,
e então o processo co1neça do zero novamente no projeto seguinte. Desafios si1nilares
se aplicam a projetos que fracassara1n, nos quais as lições aprendidas, problemas e
riscos não são compartilhados ou usados para melhorar a execução de projetos poste-
riores. A CA Services se foca liza em oferecer ferra1nentas e técnicas às nossas equipes
de projetos que entregam soluções de alta qual idade e de sucesso repetível.
Abordagem da CA Technologies
A abordagem da CA Technologies para entregar soluções começa com a compreensão
da visão do cliente: saber qual é o escopo integral do desafio de negócio e qua l é a
melhor solução para enfrentar o desafio hoje que também ofereça flexibilidade e sirva
de suporte para o crescimento futuro.
Quando vista dessa fonna, a solução pode exigir um extenso levantamento de
requisitos, design, testes, design de processos e treinamento. Embora seja viável, isso
pode exigir muito tempo até que uma solução seja implementada. Os clientes exige1n
uma abordagem que entregue a solução e o valor de negócio incre1nentalmente.
A Figura 15- 13 representa uma abordagem realista para alcançar a visão: em vez
de tentar definir e implementar 1nuitos novos processos de negócios e ferramentas de
suporte de uma ún ica vez, deve-se adotar uma abordagem faseada para alcançar a
Fase 5
<Capacidade 5>
Fase4
<Capacidade 4> <Capacidade 4>
Fase 3
· Capac dade 3 · · Capacidade 3. • C.1pac1d.1de 3 •
Fase 2
'
<Capacidade 2> <Capactdade 2> <Capacidade 2> <Capacidade 2>
Fase 1
<Capacidade 1> <Capaadade 1> <Capactdade 1> <Capacidade 1> <Capacidade 1>
linha do tempo da implemenla~ão
Figura 15-13 A abordagem da CA.

visão, focalizada em entregar certas capacidades durante cada fase. É assim que a CA
Services recomenda seus clientes a planejarem co1no irão alcançar sua visão, em fases
lógicas, sendo que cada fase produz va lor de negócio.
"Cada fase produz valor de negócio" é crucial para o sucesso do projeto. Mas
como a CA explica o va lor de negócio e como o cliente compreende e reconhece o
va lor produzido em cada fase? De maneira muito simples: cada fase produz capaci-
dades específicas predeterm inadas, que são definidas de acordo com cada caso de uso
(funcional).
Definições
Capacidade: un1a habilidade que uma organização, pessoa ou sistema possu i. Capa-
cidades são tipican1ente expressas en1 tennos gerais e de alto nível e exigem uma
combinação de organ ização, pessoas, processos e tecnologia para serem alcançadas.
Caso de uso (funcional): um termo usado no contexto de uma solução. Trata -se de um
caso de uso específico que descreve um objetivo funcional que serve de suporte
aos requisitos funcionais gerais da capacidade.
Os nomes e as descrições das capacidades e casos de uso empregam uma lingua-
gem direta para explicar a funcionalidade que está sendo oferecida. Um exemplo: a
capacidade "Provisionamento flexível a pedido" incluiria casos como "Implementar
aplicação", "Gerenciar Apl icação", "Expandir Aplicação" e "Migrar Aplicação", entre
outros. Cada capacidade e caso de uso possui descrições explicando mais aprofunda-
da1nente a funcionalidade oferecida.
Isso é i1nportante pa ra a CA Technologies, seus parceiros e clientes - em vez de
apenas relatar ou docu1nentar que a equipe de projetos irá implementar o produto xxx
com características yyy e zzz, eles usa1n as capacidades e casos de uso para comunicar
a funciona lidade que será oferecida. As capacidades relevantes e seus casos de uso são
incluídos nas ferramentas de venda e determinação de escopo, em suas declarações de
t rabalho e nos deliverables produzidos para o cl iente du rante a atividade de imple-
mentação. Isso minimiza a ambiguidade a respeito da funcional idade que a CA Tech-
nologies irá oferecer; essa funciona lidade é descrita desde o início e é acompanhada
durante toda a execução e entrega da solução.
Começando da maneira certa

Muitos projetos estão fadados ao fracasso antes mesmo de começarem. Simplesmente
segu ir as práticas padrão de gestão de projetos não é suficiente para garantir o sucesso.
A CA Technologies criou diversas ferramentas e implementou processos-padrão para
ajudar as equipes de projetos a começarem com um projeto que é estabelecido para ser
bem-sucedido desde o início. As seções a segu ir descrevem a lguns dos métodos que são
util izados antes de dar início a um projeto.
Definindo o sucesso do projeto

Uma pergunta óbvia que norma lmente não é feita é: "Como se define o sucesso?".
A resposta que na 1naior parte das vezes vem à mente é se o projeto está dentro do
o rçamento, do cronograma e se a declaração de escopo foi cumprida; entretanto, toda
o rgan ização deve examinar esse assunto de maneira mais aprofundada. Baseado em
u1na ava liaç.ã o das metas do projeto, a CA Services busca o sucesso de projetos inclua
os seguintes critérios:
• Adoção de soluções pa ra o cl iente - Projetos nos quais são defin idos novos pro-
cessos, as pessoas são treinadas, e soluções de TI são implementadas so1nente para
os produtos a serem engavetados ou usados com moderação são um grande de-

safio de TI hoje em dia. Isso ocorre quando os usuários fina is do cliente não são
treinados eficientemente no uso da solução, a gerência não está ciente dos recursos
e benefícios da solução e/ou as metas do cliente evoluem e não está claro como a
nova solução oferecerá suporte à sua mudança de direção. Independente disso, o
sucesso deve, em últi1na análise, ser definido de modo a incluir a adoção da solu-
ção pelo cliente, porque ela trata de necessidades de negócios essenciais.
• Satisfaç.ã o do cliente - A satisfação do cliente no curto e no longo prazo é crucial
para a CA Technologies. É medida informalmente no encerramento do projeto por
meio de uma reunião com o cliente e uma revisão das rea lizações do projeto. É
ta1nbém medida mais formahnente por meio de um processo de pesquisa.
• Tempo até o retorno (time-to-value) para o cl iente - Inclui a habilidade de levar
soluções até a produção e ajudar o cl iente a rea lizar ROi o mais rápido possível.
Medidas incluem Tempo até o Contrato (time-to-contract), * Dias até o Início da
Produção e ROi da Solução.
• Padronização da solução e 1nelhores práticas - No longo prazo, o sucesso dos
clientes pode ser negativan1ente afetado se a so lução implen1entada for extrema-
n1ente personalizada e uti lizar funções e processo que estejam fora da norma. Essas
persona lizações tornam desafiador para o cl iente tirar proveito de futuras capaci-
dades do produto; portanto, a CA Techno logies acredita que o sucesso no longo
prazo inclua a definição de n1elhores práticas para a solução e a orientação dos
cl ientes para que eles tirem proveito dessas melhores práticas. As 1nedidas inclue1n
a imple1nentação de soluções padronizadas, casos de uso e n1elhores práticas.
• Desempenho do projeto - Inclui a ent rega do projeto dentro do prazo e do or-
ça1nento. Medidas incluem o índice de desempenho de custo (IDC), o índice de
desempenho de prazo (IDP) e a margem gera l do projeto.
Essa definição de sucesso de um projeto exige uma abordagem diferente para a
gestão de projetos. As atividades típicas da gestão de projetos de T I começam após
o acordo de serviços (uma Especificação de Traba lho, ou ET) ser assinado e term ina
com o início da produção da solução. Alcançar os fatores de sucesso acima exige u1n
gerenciamento do início ao fim do processo (end-to-end): das atividades de proposta,
à imple1nentação e à t ransição para a produção com a adoção integral. Medir e moni-
torar esses fatores de sucesso pode ser difíci l, mas é essencial para manter em curso as
melhorias contínuas.
A CA Services utiliza um dashhoard na Gestão de Projetos e Portfólio CA Clari-
tyTMpara ajudar a gerenciar o portfól io de projetos. Essas 1nedidas de sucesso são cap-
tadas e exibidas no Dashboard de Serviços para disponibilizar os dados para vários
grupos da CA Technologies. Esse compartilhamento aberto de dados sobre o sucesso
do projeto promove o suporte multifuncional de projetos e o feedback necessário para
as melhorias contínuas.
Foco do projeto
É essencia l reconhecer o que uma organização faz be1n feito. A tendência natural é
achar que podemos apl icar as 1nelhores práticas de gerenciamento para executar qual-
quer projeto de fonna bem-sucedida. A realidade é que a ma ioria das organizações
possui u1n fraco por projetos que elas executam bem; projetos que inclue1n tecnologias
específicas, que se encont ram dentro de determinado escopo ou certas indústrias, que
soluciona1n problemas específicos, que são de certo tamanho, e assi1n por diante. As
"'N. de T.: Time•t.o-c.ontrac.t é o prazo entre a data de encerramemo do convite à apresentação de propostas
e a assinarura do contrato .
o rganizações precisam fazer uma ava liação honesta dos projetos que elas executam
bem e as necessidades do negócio que eles são capazes de solucionar. Projetos fracassa-
dos colocam em r isco relaciona tnentos de negócios e futuros negócios.
Para a CA Services, o foco está em implementação, gerenciamento e otimização
das soluções de negócios necessárias, uti lizando o software da CA. Os resultados de
nossa ava liação indicaram a necessidade de:
• Ofertas de soluções padronizadas que ofereçam capacidades (funcionalidades) co-
muns, com capacidades opciona is.
• Oferta de ferramentas padron izadas para servir de suporte ao posicionamento,
determ inação do escopo e proposta da solução certa.
• Um catálogo de serviços oferecidos; um repositório a partir do qual as ofertas de
feramentas padronizadas podem ser facilmente acessadas.
• Uma revisão e val idação independentemente de soluções para as soluções que in-
cluem múltiplos produtos da CA Technologies e/ou que precisam se integrar com
vários produtos não CA.
Ofertas de soluções padronizadas

Para alcançar os fatores de sucesso definidos, é importante compreender por que a l-
guns projetos não alcançam os alvos de sucesso. Na prática, durante as atividades
realizadas na CA Technologies, descobrimos um fator comum em projetos que reali-
zava tn uma extensa análise de requisi tos, perguntamos ao cliente o que eles queriam
e executamos a declaração de escopo perfeita tnente. A captaç.ã o e documentação de
requisitos excessivamente detalhados pode parecer uma boa fónnula para o sucesso
de um projeto, mas, na real idade, criava riscos devido a uma aná lise prolongada e à
demora no tempo até o retorno. O cl iente não recebia soluções otimizadas ou mel ho-
res práticas porque u1na personal ização excessiva afetava negativamente o valor no
longo prazo. Uma abordagem melhor seria definir ofertas padron izadas, como mostra
a Figura 15- 14, que inclua tn a 1naior parte do que a maioria dos clientes precisa e
permitam que os cl iente alcancem rapidamente o ROi. A maioria dos cl ientes prefe-
riria receber orientações sobre o que eles deve implementar, o que funciona melhor e
que soluções estão sendo usadas em sua indústria. Ao definir pacotes de ofertas, criar
arquiteturas de referência e utilizar casos de uso padrão que podem ser usados para
projetos com objetivos simi lares, a CA Technologies consegue melhorar o Tetnpo até
o Retorno para seus clientes.
Idealmente, cada oferta executaria exatamente o mesmo escopo, projeto após pro-
jeto. Embora a maioria das situações seja bastante sim ilar em escopo, setnpre haverá
certas funcional idades singulares necessárias em cada projeto. Esse desafio pode ser
contro lado por meio da identificação de opções de escopo dentro de e.ada oferta. A CA
Serviço de Serviço de Serviço de Serviço de

aceleração aceleração de aceleração de aceleração de
para cartuchos capacidade capacrtação relatórios
Serviços fundamentais
Figura 1S-14 Ofertas de soluções padronizadas.

Technologies realiza isso por meio da definição de Serviços Fundamentais e Serviços

de Aceleraç.ã o para cada oferta.
Os Serviços Fundamentais são o escopo e a funcionalidade n1ínin1a in1plementada
para cada solução e esta belece uma estrutura comum que pode ser faciln1ente expandida.
Funcionalidades adicionais a lin hadas às necessidades de negócios do cliente poden1 ser
oferecidas usando os Serviços de Aceleração. Os Serviços de Aceleração são un1 conjunto
de casos de uso que pode1n ser implen1entados de u1na maneira co1num, tirando proveito
das n1elhores práticas. Fazer isso n1antém a padronização e aun1enta o sucesso repetível,
oferecendo, ao n1esmo ten1po, capacidades alinhadas às necessidades do cliente.
Ferramentas para ofertas padronizadas

Para ga rantir que as equipes de vendas possa1n eficiente1nente posicionar, criar u1n
escopo e propor a solução certa, incluindo as ofertas padron izadas, fora1n produzi das
várias ferramentas, para lhes servi r de suporte, co1no mostra a Tabela 15- 1.
Catálogos de ofertas de seNíços

Para ajuda r a organização CA Technologies a acessar faci lmente as O fertas-Padrão e
suas ferramentas de suporte, a CA Services criou o Catálogo de Ofertas de Serviços.
Trata-se de um repositório no qual oferecem-se ferramentas de suporte ao posiciona-
mento, determ inação de escopo e venda das Ofertas Padrão.
O Catálogo de Ofertas de Serviços passa por mel horias contínuas e é um reposi-
tório dinâmico. Ofertas são adicionadas, atua lizadas e retiradas da lista dependendo
das necessidades dos cl ientes. O feedback também é usado para melhorar a est rutura e
a facilidade de uso. Por exemplo, grupos de foco recentemente forneceram o seguinte
feedbacklcontribuição sobre as ferramentas necessárias e o layout do repositório:
• Fornecer menos ferramentas, mas que estas sejam mais abrangentes e enfocadas
TABELA 15-1 Ferramentas para ofertas padronizadas

Ferramenta para oferta padronizada Descrição da ferramenta
Descrição do Serviço A Descrição de Serviço é uma descrição ocupando uma
página de oferta, vator e benefícios para o cliente e delive-
rab/es específicos. Além de no Catálogo, esse documento
está disponível no site ca.com
Apresentação ao Cliente A Apresentação ao Cliente é um conjunto de slides sobre
a oferta específica a ser incorporado na apresentação de
uma solução maior. Inclui uma descrição da oferta, o valor
e os benefícios para o cliente e deliverab/es específicos
Calculadora de Soluções A Calculadora de Soluções é uma planilha que estima o
esforço (em termos de horas) para a equipe de projetos
entregar uma Oferta Padronizada; dependendo de variá-
veis exclusivas da solução
Especificação do Trabalho (ET) Uma ET é o contrato entre o Cliente e a CA. Define a solu·
ção que a CA irá implementar na forma de capacidades e
casos de uso
Questionário de Determinação de Escopo Uma ferramenta usada para possibilitar que a equipe de
vendas reúna as informações funcionais e técnicas neces-
sárias para se determinar o escopo e se propor a solução
certa
Diretrizes de Determinação do Tamanho Uma ferramenta usada para definir os recursos de infraes-
da Solução trutura necessários para hospedar a solução proposta pela
CA Technologies
• Usar o mínimo possível de sequências de teclas pressionadas/cliques do mouse

para local izar docu1nentos disponíveis
• Identificar em que ponto do Ciclo de Vida de Oportunidades cada ferramenta será
usada
O Catá logo de Ofertas de Serviços permite que um usuário entre no catálogo (que
foi criado no Microsoft SharePoint), loca lize rapidamente uma Oferta Padronizada,
visualize todas as ferramentas disponíveis e faça o down load das ferra1nentas necessá-
rias nesse ponto do ciclo de vendas.
Revisão/validação de soluções
Uma outra manei ra de a CA Technologies melhorar a probabilidade de sucesso de um
projeto é uti lizar vários programas e processos que verifiquem a adequação da solução
proposta durante o ciclo de vendas. Isso é especialmente válido para soluções grandes
e complexas nas qua is pode ser apropriado fazer revisões extras. Por exe1nplo, solu-
ções que incluem múltiplos produtos da CA Technologies que precisa1n ser integrados
com diversos produtos não CA em um ambiente grande e complexo. Nenhu1na pessoa
pode possivehnente ser especializada em todas as soluções de software, versões, pla-
taformas e integrações da empresa; por este motivo, uma equipe de tecnólogos com
várias habilidades e graus de experiência revisa e aprova a arquitetura certa - antes de
a CA Technologies propor a solução para o cliente.
Pode ser benéfico também passar un1 ten1po extra co1n o cliente e1n atividades para
val idar as necessidades do negócio e garantir que os con1ponentes da solução proposta
atendan1 a essas necessidades e às expectativas do cl iente. En1 alguns casos, isso pode
at rasar leve1nente o ciclo de vendas, mas o foco extra ajuda a garantir que o projeto
seja ben1-sucedido. O objetivo é identificar o quanto antes possíveis r iscos ao se atender
às expectativas e necessidades do cliente, idealn1ente, antes do início do projeto.
Por que o foco no ciclo de vendas?

Se o objetivo deste livro é discutir as melhores práticas em gestão de projetos, por que
estamos dedicando tanto tempo ao ciclo de vendas?
A resposta é muito siinples: um projeto de serviços bem-sucedido, que resulta na
implementação da solução certa e em u1n cliente satisfeito, é o resultado de:
1. Compreender as necessidades de negócios do cliente
2. Analisar os processos existente e suas tecnologias de suporte
3. Concordância por pa rte do cl iente co1n a solução (Capacidades e Casos de
Uso) a ser implementada
4. Determinar o escopo do projeto correta1nente e defini-lo nos docu1nentos
cont ratuais
5. Estabelecer adequadamente as expectativas do cliente
Os benefícios do cliente incluem:

• Riscos de implementação sign ificativamente ma is ba ixos, se comparados aos r is-
cos presentes quando da não adesão às 1nelhores práticas
• Os clientes ent ram rapidamente na fase de produção
• Maior satisfação com resultados definidos que geram va lor
• Maior rapidez de retomo sobre investimentos
Execução do projeto
Uma vez que o contrato de serviços tenha sido vendido, a CA Services se prepara para
ent regar a solução necessária. A solução é ent regue seguindo-se uma Metodologia de
Entrega de Soluções padrão da CA Services, co1n o suporte de guias de referência para

imple1nentação e templates de deliverables e gerenciando-se por meio de uma Metodo-
logia de Gestão de Projetos da CA Services.
Metodologia de entrega de soluções

A Metodologia de Ent rega de Soluções da CA Services apresentada na Figura 15- 15
é construída a partir de princípios fundamentais e comprovados de engenharia de sis-
temas que forma lizam uma abordage1n consistente e repetível para uma rápida imple-
mentação ou para implementações de soluções mu ltifaseadas. A 1netodologia foca liza-
-se em garantir que a solução se alinhe às necessidades de negócios do cliente e que os
deliverables necessários forneçam essa solução.
A metodologia consiste em:
Configuração e iniciação do projeto
Antes de a CA Services chegar ao estabelecitnento do cliente, faz-se uma série
de reuniões conjuntas e/ou chamadas de conferência para preparar tanto a CA
Services quanto o cl iente para o início da implementação. As principa is atividades
incluem criar e receber aprovação do Plano de Gestão de Projetos e do Cronogra-
ma do Projeto, conduzindo uma Avaliação de Riscos e validando o escopo e os
pré-requisitos do projeto.
Definição dos requisitos da solução
Os requisitos já devem ter sido levantados durante uma ava liação do processo
de venda. Nessa etapa, usa-se uma série de sessões de levantamento de requ isitos
com as principa is partes interessadas - gerentes de negócios, arquitetos de solu-
ções e membros da equipe de operações - para verificar e descobrir mais sobre os
direcionadores de negócios do cl iente e seus requisitos funciona is e não funcio-
nais, à medida que for necessário. Os resu ltados são requisitos de solução defini-
dos que o cliente e a CA Technologies acred itam que leve1n à solução solicitada.
Tais requisitos serão na fonna de capacidades e casos de uso definidos.
Arquitetura e design da solução
Por 1neio de uma série de oficinas colaborativas e discussões, a CA Techno-
logies anal isa o estado atual do ambiente do cliente. Define-se um estado final
planejado, identificam-se as principais decisões de design e configuração e doeu-
r--.-i f1iiiml fiiml liiii1 Oiiiil

i-----
0
[- · · ·
'• •
.
Figura 1S-15 Metodologia de entrega de soluções.

menta-se a lógica de cais decisões. O resultado inclui u1n design funciona l e técnico
juntamente co1n u1na documentação sobre os impactos da solução.
Construção e testes da solução
1. A soluç.ã o é insta lada e configurada no ambiente in icia l (nonnalmente, de-
senvolvimento). Componentes ind ividuais são imple1nentados no ambiente
apropriado e, então, integrados à solução.
2. Após a conclusão da integração e dos testes das un idades, a equ ipe de tes-
tes (da CA Services e do cl iente) executa um conjunto de testes para va lidar
requisitos funcionais, atributos de qua lidade e restr ições da solução. Esses
testes fornecem rastreabilidade da solução de trabal ho e dos casos de uso
definidos ao escopo do projeto no contrato e se alinham às necessidades de
negócios do cliente. Os resultados dos teste.s são registrados no Relatório de
Testes. Qualquer problema mais sério que exija remediação será abordado e,
então, retestado.
Implementação de soluções de produção

Para auxi liar na Ílnplementação da solução no a 1nbiente de produção do cl iente, util i-
za-se um template de planejamento pré-implementação para definir planos deta lhados
para as atividades de implementação. Isso ajuda o gerente de projetos ao determ inar se
está pronto para t ransferir a solução para a produção. Os procedimentos operacionais
são documentados para auxiliar a equipe de administ ração que fará a manutenção da
solução.
Entrega e encerramento do projeto
Os gerentes de p ro jetos da CA e do cl iente rea lizam uma reunião de encerramento de
projeto para confirmar se a solução está de acordo com os requisitos identificados na
DT e para d iscutir os próximos passos e/ou fases de implementação propostas. Isso
inclui a confirmação de que toda a documentação e todos os deliverables do projeto
foram fornecidos juntamente com a conclusão da transferência de conhecimento.
Templates de implementação
Tetnplates que se alinham a cada u1na das ofertas-padrão servem de suporte à Me-
todologia de Entrega de Soluções. Esses tetnplates fornecem a est rutura para os deli-
verables padrão produzidos em cada etapa. Isso promove o sucesso repetível ao reunir
o que funciona em pacotes e ajuda outros a aplicar as lições aprendidas. A cartilha de
implementação é apresentada na Figura 15- 16.
Os templates fornecem tre1nendos benefícios durante a execução de um projeto:
• Consistência - Quando os 1nembros da equipe passam de um projeto a outro,
eles sabem que a execução do projeto será muito sim ilar aos outros projetos em
que trabalharam. O tempo para fazer a equipe entrar no ritmo e agregar valor ao
projeto reduz mui to.
• Deliverables padrão - Essa padronização pro1nove a reuti lização e reduz o tempo
de criação.
• Roceiro para o GP - O gerente de projetos não precisa criar p lanos de projeto do
zero; existe um roteiro predefinido que facil ita muito o trabalho do gerente.
• Melhorias contínuas - Fornece u1n repositório de deliverables, ferramentas e téc-
nicas padrão que podem ser continuamente 1nelhorados a partir de lições aprendi-
das e do feedback de projetos.
Templates servem de suporte a cada etapa da Metodologia de Implementação.
A Tabela 15- 2 lisca os tetnplates fornecidos para auxil iar a implementação da solução.
ca • Instruções metódicas que permijem que a CA Services

···---- entregue capacidades de forma consistente e repetível
• Todos os documentos e ferramentas de que você
precisará durante todas as nove fases de um projeto
m -=~-'------~
= ----
--
(3
_ _ ,.,..>11••• =--------
-- .-· - ·-·---
·--~-- --
---
Cartilha de
Guia de ----
·---~·..-
lmplementaçãoL---- - - - ---1
Especificação
dos requisitos
da solução Especificação Especificação
do design da integração Plano de Testes
da solução da solução da Solução
Figura 15-1 6 A cartilha de implementação.
TABELA 15-2 Lista de templates

Etapa Template Descrição
Configuração e inicia- Apresentação da reunião Um template de apresentação a ser utilizado durante a
ção do projeto inaugural reunião inaugural do projeto
Definição de requisitos Oficina de levantamento Esquema para uma oficina de levantamento de requisitos
da solução de requisitos
Questionário de levanta- Um questionário utilizado para levantar os requisitos da
mento de requisitos solução
Arquitetura e design Design Juncional dos re- Detalha os requisitos para a implementação da solução
da solução quisitos da solução
Descreve a solução proposta de um ponto de vista lun-
cional e como a solução foi projetada a fim de mitigar os
desafios atuais. Fooo sobre o alinhamento entre as neces-
sidades de negócios e as capacidades da solução
Descreve também quaisquer mudanças/melhorias a serem
feitas no processo ou realinhamentos de pessoal necessá-
rios para oferecer suporte à nova solução
Design técnico Descreve a solução proposta de um ponto de vista técnico.
Detalha os oomponentes, as integrações e a configuração
de rede da tecnologia
Construção e testes da Plano de testes da solução Descreve os testes necessários para validar a solução em
solução cada um dos ambientes de implementação
Relatório de testes Detalha os resultados dos testes de validação
Registro de testes Resume os testes e seus resultados
Implementação na Planejamento pré-imple- Requisitos e detalhes planejados para prosseguir de um
produção mentação ambiente de desenvolvimento ou garantia da qualidade
para o ambiente de produção
Operações e procedi- Procedimentos para a manutenção da solução após a im-
mentos plementação
Entrega e encerramen- Resumo do projeto e Descreve "próximos passos propostos" e projetos adicio-
to do projeto apresentação dos próxi- nais necessários para aumentar a maturidade do cliente
mos passos propostos dentro dos parâmetros da solução. Panorama das lições
aprendidas que podem ser aplicadas a futuros projetos
Templates de gestão de projetos

Tetnplates e ferramentas para o gerente de projetos reforçam as melhores práticas de
gestão de projetos. Os gerentes de projetos da CA Technologies utilizam esses tem-
plates para oferecer governança de projetos durante todo o projeto. Como mostra a
Figura 15-17, a govemança é u1n processo contínuo que cruza as fronteiras do projeto
de u1na etapa para outr a.
Os principais benefícios da governança de projetos para os projetos da CA

Technologies incluem:
• Minimização das lacunas de comunicação
• Uso eficiente de recursos qualificados, o que reduz os custos do projeto
• Gerencia1nento financeiro eficiente e relatórios orçamentários consolidados
• Único ponto de contato para todas as escaladas de conflito, questões financeiras,
de recursos e de planejamento
• Gerencia1nento do sucesso e padrões do projeto
• Padrões de qualidade estabelecidos do projeto
• Maior satisfação do cl iente com os resultados do projeto
A Tabela 15-3 realça alguns dos principais templates que um gerente de projetos
utiliza como suporte às atividades de gerencia1nento.
Produtos de trabalho em pacotes - Componentes padrão para acelerar
a implementação
Ao desenvolver soluções para os clientes, não é incomum encontrar a lguns casos de
uso e requisitos funcionais que não estão disponíveis na arquitetura de referência ou
nas funcional idades prontas para o uso . A CA Services possui uma organização de
Entrega Global que serve de suporte à entrega de ca is casos de uso. U1n cliente pode ter
a necessidade de um relatório ou função específica que não faz parte da oferta-padrão;
nessa situação, o trabalho de desenvolvimento é realizado pela Entrega G lobal em
u1n módu lo de código específico. Entretanto, u1na grande vantagem de usar um único
grupo para qualquer t rabalho de funcionalidade a 1npliada é a capacidade de rastrear
as necessidades do cliente em todos os projetos. Fica óbvio, então, que casos de uso
Determinação de escopo GOVERNANÇA OE PROJETO Encerramento
Configuração Transição e
e iniciação Requisitos Design Construção Implementação encerramento
e teste
do projeto do projeto
Equipe de projeto do cliente EDUCAÇÃO Treinamento do administrador e do usuário final
Gerencramento Gerenciamento Gerenciamento

de escopo da qualidade de mudanças
Gerenciamento Gerenciamento Gerenciamento

de cronograma de recursos de problemas
Gerencramento Gerenciamento Gestão

orçamentáno das comunicações de nscos
Fig ura 15-17 Principais elementos da governança de projetos.

TABELA 15-3 Destaques dos principais templates
Etapa Template Descrição

Todas as etapas Template de minutas da reunião Um documento contendo esboÇo de alto nível para
as minutas da reunião
Relatório de status do projeto Relata o progresso do projeto
Histórico de problemas do projeto Acompanha os problemas do projeto, incluindo deta-
lhes, passos dados para a remediação e status atual
Formulário de aceitação de marcos Assinatura de de/iverab/es pelos dientes
Relatório de controle do tempo Acompanha o tempo gasto pela equipe de projetos
Configuração e ini- Plano de gerenciamento do projeto Planeja como o projeto será gerenciado
ciação do projeto
Avaliação de riscos Ferramenta para avaliar os riscos do projeto
Inventário e mitigação de riscos Identifica e acompanha os riscos do projeto, planos
de mitigação e status atual
Acompanhamento finanoeiro Acompanha os planos financeiros do projeto, seus
custos reais e suas métricas financeiras
Lista de contatos Identifica todos os indivíduos que participam do pro-
jeto, listando suas informações de contato
Cronograma do projeto Define as tarefas, marcos e recursos associados ao
projeto
Registro de produtos gerenciados Acompanha os deliverab/es da EAP e seus status
Entrega e encerra- Feedback da implementação Usado internamente para identificar como metodo-
mente do projeto logia, processos, templates, ferramentas ou ofertas
poderiam ser aprimorados para servirem de suporte
a futuros projetos
são comuns para 1nú ltiplos clientes, e onde a solução pode ser expand ida de modo que
passe a oferecer o máximo de va lor. Usa ndo esses dados, a Entrega Glo bal consegue
cria r um pacote para esse produto de trabalho incluindo acelerado res e componentes
predefinidos. A meta última é minim izar as personalizações individuais para um único
cliente, e levar os clientes a tirarem proveito dos componentes predefinidos . Isso propi-
cia retornos mais rápidos, 1nenos riscos e maior consistência par a o projeto .
Encerramento do projeto
Uma das etapas que a CA Technologies enfa tiza é o Encerramento de Projetos. Mu i-
tas organizações veen1 essa etapa como uma formalidade que gera pouco valor. En-
t reta nto, a CA verificou que ela é crucial para o sucesso de longo prazo do cliente,
e prepara o terreno para novos negócios. Há um p rocesso formal de encerramento
de um projeto publicado para reforçar mel ho res práticas. Ele descreve uma reunião
de encerra mento de p rojeto co m o cl iente e define uma p rogramação específica para
tal reunião. A Tabela 15-4 descreve os principais itens da p rogra mação de un1a reu-
nião de encerramento de projeto e como eles contr ibuen1 para o sucesso do projeto
e do cliente.
Melhorias contínuas
Um dos maio res desafios que as organizações enfrentam é sua capacidade de aplicar
lições aprendidas de um único projeto a fim de n1elhorar o p lanejan1ento e a execu-
ção de fut uros p rojetos. A CA Services confiou essa responsabilidade a dois p rinci-
pais grupos da CA Services - o grupo de Práticas Globais e o PMO. Em qua lquer
n1omento em que um gerente de projetos está pri mordia lmente focado na execução
TABELA 15-4 Principais itens da programação

Item da programação do
encerramento de um projeto Contribuição para o sucesso do projeto e do cliente
Recapitulação dos requisitos e Confirmação de que o projeto atende os objetivos do diente e o ROi loi posi-
objetivos de negócios cionado ou realizado
Scorecard final Mensurações finais de quão bem o projeto loi executado. Analisar essas
métricas pode ajudar a identificar pontos lracos a serem melhorados ou a
relorçar o sucesso de execução
Desalies e lições aprendidas do É importante obter o ponto de vista do d iente sobre qualquer desafio que o
projeto projeto tenha tido que superar ou lições aprendidas. Ter essa conwrsa com o
diente traz uma diferente perspectiva e possíveis novas ideias para melhorias
Documentação do projeto Todos os de/iverab/es e a principal documentação do projeto são colocados
em um pacote e apresentados ao cliente. Isso ajuda a garantir que o cliente
possua cópias do trabalho do projeto linal em um pacote consolidadado para
facilitar a consulta
Plano de treinamento Uma análise da formação concluída e recomendações para cursos extras
pode ajudar a garantir que o diente esteja pronto para assumir o comando
da solução implementada. Isso é crucial para o sucesso de longo prazo do
diente e o ROi
Próximos passos O projeto concluído pode ser um projeto de muitas fases ou novas oportu-
nidades podem ter sido identificadas para um ROi extra. Analisar os passos
seguintes ajuda a garantir que o cliente esteja ciente das recomendações e
determine suas expectativas para futuras atividades
Transição de serviços ao suporte É importante ter uma transição suaw da equipe que acaba de concluir o pro-
jeto para a equipe de suporte que irá trabalhar com o cliente no longo prazo.
Essa atividade analisa com o diente o processo de trabalho com o Suporte e
faz a transição da documentação essencial para a organização de Suporte
Assinatura do documento de Confirma que o projeto está pronto para ser encerrado
encerramento do projeto
Pesquisa com o cliente A CA Technologies realiza pesquisas com o cliente para confirmar sua satis-
fação e avaliar possíveis áreas de melhoria. Reforçar isso durante o encerra-
mento do projeto ajuda a aumentar as taxas de resposta das pesquisas
Referências do cliente Essa atividade descreve o programa de referência da CA Technologies e
determina se o cliente é adequado. Incluir essa atividade no encerramento
do projeto aumenta o número e a qualidade de referências que podem ser
usadas em futuros projetos
Encerramento da reunião Essa atividade abre a discussão a qualquer comentário final do cliente e do-
cumenta as minutas do encerramento para distribuição
ben1-sucedida de um único p rojeto pa ra un1 cliente, as Práticas Globais e o PMO são

responsáveis pelo portfólio de pro jetos e por mel ho rar nossa capacidade de repetir
o sucesso do p rojeto.
À medida q ue os projetos vão sendo concluídos, as lições aprendidas são captadas,
e os d iferencia is (.t.) entre o pla no e a execução rea l são identificadas. Esse feedback é
utilizado para atuaiza r as ofertas, ca lculadoras, ferramentas e te,nplates como apro-
p riado. A maioria das organizações acha que fazer uso das lições aprendidas constitua
u1n grande desafio, mas na CA Services isso conta co1n o suporte de ofertas documen-
ta das e um repositório central para agir sobre as lições aprendidas.
Historicamente, essas mel horias contínuas da execução de projetos e no sucesso
de projetos têm sido muito desafiado ras pa ra as orga nizações. Uma organização pode
muitas vezes captar as lições aprendidas ou documentar os resultados de a nál ises de
pro jetos, mas essas informações podem estar ocultas e nunca serem usadas para gerar
mel horias contínuas. U1na das maiores vantagens de se possuir um repositório de ofer-
tas-pad rão e templates é a capacidade de melhorar com o passa r do tempo. Quando
um projeto faz algo 1nu ito bem ou enfrenta dificu ldades, essas informações são reuni-
das e real izam-se 1nel horias no repositório de ferramentas, permitindo, dessa manei-
ra, que os futuros projetos sejam ainda mais bem-sucedidos. A Tabela 15- 5 descreve
como algumas dessas lições aprendidas são usadas para gera r mel horias contínuas.
A CA Technologies utiliza diversos métodos pa ra captar as lições aprend idas e
dados durante toda a execução do projeto. A Figura 15- 18 lista esses métodos, mos-
trando em que etapa eles são uti lizados para gerar melhorias contínuas.
TABELA 15-5 Usando as lições aprendidas para realizar melhorias continuas

Lições aprendidas Á rea de melhoria Benefício para o sucesso do projeto
Arquitetura do cliente não é Atualizações nas arquiteturas de capacidade de produzir mais rapidamen-
100% alinhada à arquitetura referência te documentos sobre arquitetura e design;
de referência maior padronização dos designs
Tarefas adicionais ou diferen- Atualizações na calculadora da EAP e estimativas de tarefas com maior
ciais (11.) de esforço dedicado à solução precisão
execução do projeto
casos de uso não incluídos na Criação de pacotes de componen- Redução do tempo/custo para implemen-
oferta-padrão tes pela Entrega Global ou criação tar; padronização de soluções; melhor
de novos Serviços de Aceleração ROi para o cliente
Melhorias de conteúdo nos Atualizações nos templates Deliverables de melhor qualidade
entregáveis
Melhorias na metodologia Entrega da solução e/ou atualiza- Melhoria no tempo até o retorno e na
ções na Metodologia de Gestão de qualidade
Projetos
Melhor alinhamento do escopo Atualizações nas ofertas-padrão / Melhor alinhamento da solução às neces-
às necessidades do cliente no Catálogo de Ofertas de Serviços sidades de negócios do cliente; melhor
tempo até o retorno
Desafios não identificados Atualizações nos templates de ava- Melhor mitigação de riscos e reforço das
logo no início do ciclo de vida liação de risco melhores práticas; maior sucesso do
projeto
Configuração Transição e
Construção
Oportunidade e m1c1ação Requisitos Design Implementação encerramento
e testes
do proJeto ' do pro1eto
Verificações da saúde do projeto
Ratificação de soluções Equipe de especialistas (Red Team) - Análise das causas-raiz

-
Entrada em operação
Transição para
o suporte
Solicitações e /eedback das prãticas
Figura 15-1 8 Métodos de captação das lições aprendidas.

Métodos para gerar mehorías nos processos:

Verificações da "saúde" do projeto: O PMO e as Práticas G loba is pode1n realizar uma
verificação da saúde do projeto em qualquer momento de seu andamento. Não se
trata de aud itorias, mas de um 1nétodo para confirmar que as ferramentas estejam
gerando va lor e reunindo lições aprendidas . Desafios específicos são abordados,
oferecendo-se uma assistência extra à equ ipe de projetos. O feedback é usado
primordia lmente para melhorar as calculadoras, templates e ofertas de soluções.
Ratificação da solução: Para projetos grandes, co1n diversas integrações de tecnolo-
gias, u1na equ ipe de especialistas muito experientes oferece uma supervisão adi-
cional durante as etapas de oportunidade, requisitos e design da arquitetura. As
Práticas Globais fornecem especialistas ao projeto para analisar as necessidades de
negócios do cliente e para garantir que o design do projeto atenderá a essas neces-
sidades. Os resultados dessas anál ises podem ser, então, usados para fazer novas
mel horias nas arquiteturas de referência e nas ofertas de soluções.
Equipe Globa l de Gerenciamento de Esca lada de Confl itos - aná lise de causas-raiz:
Se um projeto encont ra problemas durante as etapas de garantia de qua lidade e
testes ou de imple1nentação, a Equipe Global de Gerenciamento de Escalada de
Confl itos pode trazer novos especialistas ao projeto para trabalhar especificamen-
te co1n a identificação e resolução de problemas. A final idade imediata da equipe
é resolver o problema, mas uma análise da causa-raiz também será realizada. Os
resultados dessa análise podem fo rnecer ideias sobre áreas que podem ser mel ho-
radas; especialmente para arquiteturas de referência.
Início das operações: U1na das etapas crucia is de um projeto é sua implementação na
produç.ã o. A CA criou um processo no qual representantes de grupos multifuncio-
nais se reúnem para fornecer 1naior apoio ao projeto antes e durante sua imple-
mentação na produção. Essa equ ipe se focaliza especialmente em qua lquer proble-
ma ou obstáculo que esteja causando algum impacto sobre a capacidade da equipe
de projetos de implementar a solução com êxito. Os resultados dessas verificações
podem, então, fornecer feedback para aprimorar continuamente a metodologia, as
ferra 1nentas ou os tetnplates.
Transição para o suporte: É essencial para o sucesso de longo prazo do cliente que
um projeto faça uma t ransição suave da equipe de projetos que implementou a
solução para a equipe de suporte que irá traba lhar com o cl iente no longo prazo.
Durante esse período de transição, a arquitetura e o design do cliente são compar-
ti lhados co1n a equipe de suporte juntamente co1n a transferência de conhecimen-
tos. Durante toda a fase pós-imple1nentação, o sucesso do cliente é monitorado,
usando-se feedback para aprimorar as ofertas de soluções.
Site G loba l de Solicitações e Feedback de Práticas: Esta é uma ferramenta que permite
que qualquer pessoa da CA Technologies registre seu feedback, fazendo sugestões
sobre qualquer das ofertas-padrão e solicitações de recursos para assistência. Ter
esses dados em uma ferramenta centra lizada serve de suporte à anál ise de tendên-
cias, garante que as sugestões não se percam e acompanha as ações necessárias
para se iinplementar as melhorias.
15.3 Microsoft Corporation

Há programas de treinamento que discutem como desenvolver boas metodologias. Es-
ses progra1nas se foca lizam no uso de "práticas comprovadas" em desenvolvimento de
metodologias em vez de no uso de uma ún ica metodologia. A Microsoft desenvolveu
u1na fa1níl ia de processos que incorpora os princípios cent rais e práticas comprovadas
em gestão de projetos. Esses processos co1nbinados com ferramentas e conciliando

4
pessoas chama-se Microsoft Solutions Framework (MSF). O que aparece no restan-
te desta seção é apenas um breve resumo da MSF. Para ma iores informações e u1na
compreensão mais aprofundada do assunto, ver o livro de Mike Turner nas referências
na nota de roda pé.
A MSF foi criada há 16 anos, quando a Microsoft reconheceu que a TI era u1na
possibi litadora essencial para ajudar os negócios a funcionarem de novas maneiras. A
TI possuía um histórico de problemas em produzir soluções. Ao reconhecê-los, criou-
-se a MSF com base na experiência da Microsoft na produção de soluções.
A MSF é mais do que apenas gestão de projetos: envolve a produção de soluções
das qua is a gestão de projetos (a lta govemança) é um componente-chave. Produzir de
soluções é conci liar a construção da solução com governança. Segundo Mike Turner:
Em s ua base, a MSF envolve a umenta r a co nscientização quanto aos vários e lementos e
influências sobre o sucesso da produção de soluções - ninguém possui uma metodologia
infalível; é quase impossível oferecer as melhores receitas a serem seguidas para se garantir
o sucesso em todos os projetos ... A MSF envolve compreender seu ambiente, de modo que
você possa criar uma metodologia que permita um equilíbrio harmonioso entre gerenciar
projetos e co nstruir soluções.
Um o utro ponto-chave em relação à MSF é q ue a gestão de projetos é vista como uma
disciplina que todos precisam praticar, não somente os gerentes de projetos. Todos precisam
ser responsabilizados e responsáveis pelo gerenciamento de seu próprio trabalho (i.e., ser
gerentes de projetos de si mesmos) - isso desenvolve a confiança entre os membros da equi-
pe (algo muito necessário em projetos com gerenciamento de orientação Agil), o q ue não
acontece tanto com projetos gerenciados formalmente (uma gestão de projetos feita a inda
de forma muito descendente).
O principal ponto que a MSF tenta passar é que os clientes e pa trocinadores querem
soluções entregues - eles francamente veem a gestão de projetos como uma despesa extra
necessária. Todos precisam compreender como governar a si mesmos, s ua equipe e o traba-
lho que o projeto realiza - não somente os gerentes de projetos.
Boas est ruturas focalizam-se na compreensão da necessidade de flexibilidade. A
flexibil idade é essencial, pois o ambiente de negócios está em constante modificação,
e isso, por sua vez, oferece novos desafios e oportun idades. Como um exemplo, a
Microsoft reconhece que o ambiente de negócios de hoje em dia possui as segu intes
características:
• Taxas de mudança em negócios e tecnologia aceleradas
• Ciclos de produtos mais curtos
• Diversos produtos e serviços
• Novos 1nodelos de negócios
• Requisitos em rápida modificação
• Legislação e governança corporativa
• Demanda crescente por parte do consumidor
• Novas pressões competitivas
• G loba lização
Típicos desafios e oportunidades incluem:
• Expectativas de negócios cada vez 1nais altas
4
JvL S. V. Turner, Microsoft Solutfons Framework Essentials, Jvlicrosofr Press. Todos os direitos reservados.
O autor gostaria de agradecer a JvLike Turner por ter fornecido as figuras para esca seção do livro. As figuras
com números no canto in.ferior direito indicam referências ao número da página no livro de Mike Turner.
• A tecnologia é vista como fator possibi litador e1n todas as áreas de negócios
modernos
• C rescente Ílnpacto das soluções de tecnologia sobre os negócios
• Os riscos hoje são mais a ltos do que nunca
• Maximação do uso de recursos escassos
• Ent regar soluções com orçamentos menores e e1n menos tempo
• Soluções rápidas de tecnologia
• Muitas novas oportunidades, mas elas exigem novas habilidades e equipes efi-
cientes para que possam ser aproveitadas
Com uma co1npreensão do ambiente de negócios, seus desafios e oportunidades, a
5
M icrosoft criou a MSF. A MSF é uma est rutura adaptável, que co1npreende:
• Modelos (ver Figura 15-19)
• Discipl inas (ver Figura 15-19)
• Princípios fundamenta is
• Mentalidades
• Práticas comprovadas. A MSF é utilizada para produzir soluções com êxito e
maior rapidez, exigindo o envolvimento de menos pessoas e envolvendo menos
risco, possibil itando, ao mesmo tempo, resultados de mais a lta qual idade. A MSF
oferece orientação sobre como organizar pessoas e projetos com o intuito de pla-
nejar, constru ir e implementar soluções de tecnologia bem-sucedidas
Os princípios fundamenta is da MSF orienta1n como a equipe deve trabalhar unida
para produzir a solução. Isso inclui:
• Estimu lar comunicações abertas
• Trabalhar ru1no a uma visão compartilhada
• Empoderar os membros de equipes
• Estabelecer uma clara responsabil ização, co1npartilhar responsabi lidades
Modelos
Modelo Modelo de
de equipe governança
Dlsclplinas
Disciplina
de gestão
n'i:611 Disciplina
de gestão
Disciplina de
gerenciamento
de projetos 1 &!J.n de riscos da prontidão
Figura 15-19 Modelos e disciplinas da MSF. Fonte: M. S. V. Turner, Microsoft So/utions Fra-
mework Essentials, Microsoft Press. Todos os direitos reservados.
5
A X'1SF faz parte de uma relação simbiórica entre a estrutura clássica de "construir·· e a estrutura de "exeª
curar'" . A MSF representa a estrutura "construir'", e a Microsoft Operarions Framework (Jv10F) representa
a "executar··.
• Produzir valor incremental

• Manter-se ágil, esperar e se adaptar a mudanças
• Investir em qualidade
• Aprender com todas as experiências
• Estabelecer parcerias com os clientes
A 1nenta lidade da MSF orienta os mem bros da equ ipe sobre como eles deve1n
lidar co1n a produção e a entrega da solução. As orientações incluídas são:
• Estimular uma equipe de colegas
• Focalizar-se no valor de negócio
• Manter a solução em perspectiva
• Orgulhar-se de suas habi lidades
• Aprender continuamente
• lnterna lizar as qualidades do serviço
• Praticar a cidadania
• Cumprir seus co1npromissos
Em relação a práticas comprovadas, a Microsoft atual iza continuamente a MSF,
incluindo as práticas comprovadas atuais na produção e ent rega de soluções. Todos os
cursos sobre a MSF usam duas importantes melhores práticas em gestão de projetos.
Pritneiro, os cursos são representados como uma estrutura em vez de uma metodo-
logia rígida. Est ruturas baseiam-se em tetnplates, listas de verificação, formulários e
diret rizes em vez de em políticas e procedimentos 1nais rígidos. Processos inflexíveis
são uma das causas de fracassos de projetos.
A segunda 1nelhor prática é que a MSF se focaliza fortemente em u1n equilíbrio
entre as pessoas, processos e ferramentas, em vez de apenas e1n tecnologia. A imple-
mentação eficiente da gestão de projetos constitui-se de u1na série de bons processos
com ênfase em pessoas e em suas relações profissiona is, a saber, comunicação, coope-
ração, trabalho em equipe e confiança. Deixar de se comunicar e se reunir é uma outra
causa-raiz de fracassos de projetos.
A MSF se foca liza não somente em captar as práticas comprovadas, 1nas também
em captar as práticas comprovadas certas para as pessoas certas. Mike Turner afirma:
A principal coisa que acredito d iferenciar a MSF é que ela busca estabelecer uma aborda-
gem sensata e equilibrada para a produção e entrega de soluções, uma vez que esta envolve
um equilíbrio em constante modificação de pessoas, processos e ferramentas. Os processos e
ferramentas precisam ser do ;'tamanho certo " para a aptidão e capacidades das pessoas que
estão realizando o trabalho. Muitas vezes as "melhores práticas da indústria" são aplicadas
a pessoas que têm poucas chances de realizar os benefícios pretendidos.
A MSF preza a importância das pessoas e do trabalho em equipe, o que inclui:
• Desenvolver uma equipe cujos membros se tratem como iguais.
• Cada membro da equipe ter papéis e responsabilidades específicas.
• Os membros individua is serem empoderados em seus papéis.
• Todos os membros serem responsabil izados pelo sucesso de seus papéis.
• O gerente de projetos se esforçar por uma tomada de decisões baseada no
consenso.
• O gerente de projetos dar a todos os membros da equipe uma participação no
sucesso do projeto.
O modelo de equipe da MSF é exibido na Figura 15- 20. Ele define as categorias
de cargos funcionais ou habilidades necessárias pa ra concluir o t rabal ho de u1n pro-
jeto, além dos papéis e responsabilidades de cada 1nembro da equipe. O modelo de
equ ipe focaliza-se em uma equ ipe de defensores da colaboração, em vez de em uma
forte dependência da estrutura organizacional.
Em alguns projetos, pode haver a necessidade de uma equipe de equ ipes. Isso é
ilustrado a baixo, na Figura 15-21.
Entrega de soluções Design de soluções
Construção de soluções
Verificação de soluções
Oesenvol~
"Defensores"
Testes
Descrição de soluções Validação de soluções

Gerenciamento de programas
Desenvo!Vimento/lmplementação de soluções
Figura 1S-20 Modelo de equipe da MSF. Fonte: M. S. V. Turner, Microsoft Solutions Framework Es-
sentia/s, Microsoft Press. Todos os direitos reservados.
Equipe
funcional
Equipe lider
Experiência
do usuârio
Desenvol~
Equipe de Oeemot.1...-0
recursos
de desktop
Equipe de 0e~tn10
recursos de arquivar
e imprimir Equipes de
recursos
Figura 15-21 Equipe de equipes da MSF. Fonte: M. S. V. Tu rner, Microsoft Solutions Framework
Essentia/s, Microsoft Press. Todos os direitos reservados.
Estabelece1n -se marcos realistas que servem como pontos de revisão e sincroni-
zação. Eles permitem que a equipe avalie o progresso e faça correções no decorrer do
processo, quando os custos de correções ainda são ba ixos. Os marcos são utilizados
para planejar e monitorar o progresso, além de para estabelecer o cronograma de deli-
verables importantes. A utilização de 1narcos beneficia os projetos:
• Ajudando a sincronizar os ele1nentos de trabalho
• Fornecendo uma visibi lidade externa do progresso
• Permitindo correções no decorrer do processo
• Focalizando as revisões nas metas e deliverables
• Gerando pontos de aprovação para o traba lho que é passado adiante
Há dois tipos de 1narcos em a lguns programas: relevantes e provisórios. Os mar-
cos relevantes representam o acordo entre equipe e cliente sobre como proceder de
uma fase para outra. Os marcos provisórios indica1n o progresso dent ro de uma fase e
dividem grandes esforços em segmentos executáveis.
Para cada um dos principa is marcos e fases, a Microsoft define uma 1neta e u1n
foco específico para a equipe. Por exemplo, a meta da fase de conceitua lização de u1n
programa pode ser criar uma revisão de alto nível das metas, restrições e solução do
projeto. O foco da equipe nessa fase pode ser:
• Identificar o proble1na ou a oportunidade de negócios
• Identificar as habilidades de equipe necessárias
• Reunir os requisitos in iciais
• Criar a abordagem para solucionar o problema
• Definir metas, prem issas e restrições
• Estabelecer u1na base para revisão e 1nudanç.as
A MSF também estabelece metas para cada defensor. Isso é u1na necessidade por-
que há metas "opostas" natura is para ajudar com as verificações e ba lanços de qua-
lidade - dessa maneira, u1na qualidade realista é incorporada ao processo e não vista
como uma consideração a posteriori.
Isso é exibido na Tabela 15- 6.
Gera lmente se diz que muitos programas pode1n continuar para sen1pre. A MSF
encoraja a final izar (estabelecer un1a baseline) os documentos o n1ais cedo possível, mas
paral isar (freeze) os docun1entos até o ma is tarde possível. Como afirn1ou Mike Turner:
O termo " finalizar" (estabelecer um baseline) é difícil de usar sem um histórico ou uma
defin ição. Quando uma equipe, mesmo que se trate de uma equipe de uma só pessoa, é
TABELA 15-6 Metas de qualidade e defensores da MSF

Defensor da MSF Principais metas de qualidade
Gerenciamento de produtos Partes interessadas satisfeitas
Gerenciamento de programas Entregar solução dentro das restrições do projeto. Coordenar otimização das
restrições do projeto
Arquitetura Fazer o design de soluções dentro das retrições do projeto
Desenvolvimento Construir a solução de acordo com as especificações
Testes Aprovar soluções para liberação garantindo que todos os problemas sejam iden-
tificados e abordados
Experiência do usuário Maximizar a usabilidade da solução. Aumentar a eficiência e prontidão do usuário
liberação/Operações Fazer a implementação e a transição para operações de modo suave
Fonte: M . S. V. Turner, Microsoft Solutions Framework Essentials, Microsoft Press. Todos os direitos reservados.
designada a um trabalho e ela acha que concluiu esse trabalho com sucesso, o status do
marco/ponto de verificação é chamado de "concluído" (p. ex.: Plano de testes concluído);
enquanto ;'finalizado" (base/ined) é usado quando a equipe que é designada para verificar
o trabalho concorda que o traba lho esteja concl uído (p.ex .: Plano de testes finalizado).
Depois do marco/ponto de verificação da finalização, não há mais trabalho planejado. O
ponto em que o trabalho o u é enviado ao cliente o u colocado sob um rígido controle de
mudança, é quando você o declara "para lisado" (/rozen) - o que significa que quaisquer
mudanças terão de ser feitas por meio de um processo de controle de mudanças. E por isso
q ue q ueremos adiar o gerenciamento forma l de mudanças o máximo possível, devido às
despesas extras envolvidas.
Isso também exige um processo de controle de mudanças estruturado associa-

do ao uso de liberações de versões, como 1nostra a Figura 15- 22. O que as setas na
esquerda significam é que a solução é entregue, a conclusão da solução aumenta, o
conhecimento do espaço da sol ução aumenta e o risco geral da entrega da solução
diminui. Os benefícios das liberações em versões incluem:
• Forçar o encerramento de problemas do projeto
• Estabelecer 1netas claras e motivacionais para todos os 1ne1nbros de equ ipe
• O gerenciamento eficiente da incerteza e das mudanças no escopo do projeto
Minimizar riscos decompondo grandes projetos

em múltiplas versões
-.,"
o
o liberação 2
~. ~.
liberação 3
.
.§ u
.,
u .!<!
~
.e a: liberação 1 •
..,"o
•
Tempo
Figura 15-22 Abordagem iterativa da MSF. Fonte: M. S. V. Turner, Microsoft Solutions Fra-
mework Essentia/s, Microsoft Press. Todos os direitos reservados.
Base de
conhecimento.
- Aprender
conceitos e
processos de riscos
Figura 15- 23 Processo de gestão de riscos da MSF. Fonte: M. S. V. Turner, Microsoft So/u-
tions Framework Essentia/s, Microsoft Press. Todos os direitos reservados.
• Encorajar melhorias contínuas e incrementais

• Possibilitar um menor tempo de entrega
Um dos pontos fortes da MSF é a existência de templates para ajudar a criar de-
liverables de projeto de forma rápida. Os templates fornecidos pela MSF podem ser
personalizados para atender às necessidades de determinado projeto ou organização.
Te,nplates típicos podem inclu ir:
• Template do cronograma do projeto
• Template do gráfico de fatores de risco
• Template da matriz de aval iação de risco
• Template post m ortem
O processo de gestão de riscos da MSF é exibido na Figura 15- 23. Devido à im-
portância da gestão de riscos hoje em dia, ela passou a fazer parte de todos os progra-
mas de treinamento em gestão de projetos.
A MSF encoraja todos os me1nbros de equipe a gerenciarem r iscos, não somente
os gerentes de projetos. O processo é administrado pelo gerente de projetos.
• Disciplina de gestão de riscos da MSF: Uma abordagem sistemática, abrangente e
flexível para lidar com riscos proativa1nente em 1nuitos níveis.
• Processo de gestão de riscos da MSF: Inclui seis passos lógicos, a saber: identificar,
analisar, planejar, aco1npanhar, controlar e aprender.
Alguns dos principais pontos da abordagem de riscos da MSF inclui:
• Avaliar riscos continuamente.
• Gerenciar riscos intencionalmente - estabelecer um processo.
• Tratar das causas-raiz, não apenas de sintomas.
• Riscos são inerentes em todos os aspectos e todos os níveis de um esforço.
Há inú1neras n1aneiras de lidar com riscos, e a MSF fornece à equ ipe diversas opções.
Co1no exen1plo, a Figura 15- 24 n1ostra duas abordagens para priorização de riscos.
Na Figura 15- 19, mostramos que a MSF é est ruturada em torno de um modelo
de equipe e um modelo de governança. O 1nodelo de govemança é exibido na Figu-
Abordagem de priorização simples

Probabilidade/Impacto Baixo Médio Atto Crítico
Alto M M A e
Médio 8 M M A
Baixo 8 8 M M
Abordagem de priorização multiatributos

Classificação Sobrecusto Cronograma Técnico
Baixo Menos de 1% Atraso de 1 semana Efe~o leve sobre desempenho
Médio Menos de 5% Atraso de 2 semanas Efe~o moderado sobre desempenho
Alto Menos de 10% Atraso de 1 mês Efe~o severo sobre desempenho
Crítico 10% ou mais Atraso de mais de 1 mês Missão não pode ser concluída
Figura 1S-24 E xemplo de priorização de riscos. Fonte: M. S. V. Turner, Microsoft Solutions

Framework Essentia/s, Microsoft Press. Todos os direitos reservados.
ra 15- 25. Esse modelo aparece e1n todas as figuras da MSF, ilustrando que a gover-
nanç.a está continua1nente em atuaç.ã o .
Há dois componentes no modelo de governança da MSF: govemança de projetos
e realização de processos:
• Governança de projetos
• Otimização do processo de entrega de soluções
• Uso eficiente e efetivo dos recursos do projeto
• Garantia de que a equ ipe do projeto esteja e permaneça al inhada:
• aos objetivos (est ratégicos) externos
• às restrições do projeto
• à demanda por supervisão e regulação
• Realização do processo
• Definição, construção e implementação de uma solução que atenda às necessida-
des e expectativas das partes interessadas
O modelo de governança da MSF, como mostr a a Figura 15- 25, é representado
por cinco diferentes rotas de realização. As Figuras 15- 26 a 15- 30 fornecem uma des-
crição de cada uma dessas rotas.
A MSF possui critérios de sucesso estabelecidos para cada uma das rotas:
Rota de conceitua/ízação
• Partes interessadas e equipe concordam quanto:
• à motivação para o projeto
• à visão da solução
• ao escopo da solução
• ao conceito da solução
• à equipe e est rutura do projeto
• ao fato de restrições e metas terem sido identificadas.
• ao fato da aval iação de risco inicial ter sido realizada.
• ao fato dos processos de cont role de mudanças e gerencia1nento de configura-
ções term sido estabelecidos.
• ao fato de já ter sido dada aprovação formal pelos patrocinadores e/ou princi-
pais partes interessadas.
•
Co11Sft11·
"
Figura 15-25 Modelo de governança da MSF: rotas de realização. Fonte: M. S. V. Turner,
Microsoft Solutions Framework Essentials, Microsoft Press. Todos os direitos reservados.
Deliverables
o Documento da visão/escopo
o Documento da estrutura do projeto
o Documento de avaliação de risco inicial
Visão/escopo
aprovados
Metas
o Desenvolver uma clara compreensão do que é necessário
e de todas as restrições do projeto
o Reunir a equipe necessária para conceitualizar possíveis soluções
com opções e abordagens que melhor atendam a essas necessidades
o Estabelecer uma base para mudanças pelo resto do ciclo de vida do projeto
Figura 1S-26 Rota de conceitualização da MSF. Fonte: M. S. V. Turner, Microsoft Solutions

Validação de tecnologia
concfuida
~ Especificação runcional
Oeliverables
finalizada (bisei~
o Especificações funcionais . : Plano mastsr dO projeto
finalizado (b.astNn~
o Plano master do projeto
o Cronograma master do projeto .. Cronograma mastsr do projeto
!matizado (bastlml)
Planos do
Ambientesde supõrte
projeto
estabelecidos
aprovados
Metas
o Desenvolver o conceito da solução em designs a planos tangíveis,
de modo que ela possa ser construída na rota de construção
o Descobrir o máximo possível de informações, o mais cedo possível
o Saber quando você possui informações suficientes para seguir adiante
Figura 1S-27 Rota de planejamento da MSF. Fonte: M. S. V. Turner, Microsoft Solutions Fra-
mework Essentials, Microsoft Press. Todos os d ireitos reservados.
Rota de planejamento
• Obteve-se acordo cotn as partes interessadas e a equ ipe quanto:
• aos componentes de soluções a serem entregues
• às principais datas de verificação do projeto
• a como a solução será montada
• Atnbientes de suporte já foram construídos
• Processos de cont role de mudanças e de gerenciamento de configu rações estão
funcionando sem problemas
• Avaliações de risco já fora tn atualizadas
• Pode-se voltar à origem de todos os designs, planos e cronogramas nas especifica-
ções funcionais e pode-se voltar à origem das especificações na rota de conceirua-
lização de deliverables
• O (s) patrocinador(es) e/ou principa is partes interessadas assinaram a aprovação
•
Escopo
concluiclo
Deliverables
Construir
. + Criação de protótipos
eonc1uída
o Solução concluída
o Materiais de treinamento 'l ••• + t
L
Liberação interna 1
Liberação inlerna 2
o Documentação
Liberação interna n
O Processos de implementação
o Procedimentos operacionais
o Suporte e resolução de problemas (troubleshooting)
o Materiais de marketing
o Plano master, cronograma e documento de riscos atualizados
Metas
o Construir todos os aspectos da solução de acordo com os deliverables da rota
de planejamento (p. ex.: designs, planos, requisitos)
o Desenvolver 1uncionalidades e componentes da solução (código e inira),
concluir todos
o Testar todos os aspectos da solução para avaliar seu estado de qualKlacle
Figura 15-28 Rota de construção da MSF. Fonte: M. S. V. Turner, Microsoft Solutions Fra-
mework Essentials, Microsoft Press. Todos os direitos reservados.
Aprovação
da prontidão
Piloto concluido • para liberação
Candidato n para liberação eoncluido •
De/iverables Testes de actilação pelo usuàrio conduídos •
o Revisão do piloto Candidato 1 para liberação conduido •
Testes de rri•produção oonduidos •
o Versões da solução prontas Testesdesístemaconcluídõ< • Estabilizar
para liberação e colaterais ri aprovação em teste funcional conduido
que as acompanham Hist6rico de problemas apurado
do "'"!rio ••13~uza11a
o Resultados de testes e ferramentas de testes '"~'"''Convergenoia de problemas
o Documentos do projeto 1' aprovação em teste tunâonaJ concluida
Metas
o Melhorar a qualidade da solução para atender a critérios
de liberação para passar à produção
o Validar se a solução atende às necessidades e expectativas das partes interessadas
o Validar a usabilidade da solução do ponto de vista do usuário
o Maximizar o sucesso e minimizar os riscos associados à implementação
e operações de soluções em seu ambiente-alvo
Figura 15-29 Rota de estabilização da MSF. Fonte: M. S. V. Turner, Microsoft Solutions Fra-
mework Essentia/s, Microsoft Press. Todos os direitos reservados.
Rota de construção
• Todas as soluções são construídas e concluídas, o que significa que:
• Não há nenhum outro desenvolvimento de funcionalidades ou capacidades.
• A solução opera de acordo com o que foi especificado.
• Tudo o que falta é estabilizar o que foi const ruído.
• Faz-se o esboço de toda a documentação.
Rota de estabilização
• Todos os elementos estão prontos para a liberação.
• Obteve-se a aprovação para a liberação.
• Obteve a aprovação administ rativa.
Rota de implementação
• A solução está completamente implementada e operacionalmente estável.
• Todos os encarregados do loca l concordaram que as imle1nentações foram bem-
-sucedidas.
• As equipes de operações e de suporte assumiram tota l responsabilidade e são to-
ta lmente capazes de rea lizar suas tarefas.
• Os processos e procedimentos operacionais e de suporte e os sistemas de suporte
são operacionalmente estáveis.
A MSF focaliza-se no planejamento proativo em vez de reativo. Acordos entre a
equipe e os vários grupos de pa rtes interessadas logo no início do projeto podem tor-
nar os trade-offs mais fáceis, reduzir atrasos no cronograma e eliminar a necessidade
de uma redução na funcionalidade para atender as rest rições do projeto. Isso é exibido
na Figura 15- 31.
Deliverables
o Operações e sistemas
de informação de suporte
o Processos e procedimentos
Implementações
no local
oonduidas
Com ponente:s
centrais da
•
Implementação
concluída
revisados solução
implementadOs
o Reposijório de todos os
colaterais da solução
Metas
o Colocar a solução em produção no(s) ambiente(s) designado(s)
o Facil~ r uma transferência suave da solução da equipe de projetos
para a equipe de operações o mais rápido possível
Figura 15- 30 Rota de implementação da MSF. Fonte: M. S. V. Turner, Microsoft Solutions

Framework Essentials, Microsoft Press. Todos os direitos reservados.
A matriz de trade-offda MSFé um acordo

entre a equipe e as partes interessadas
Dado um cronograma fixo, escolheremos recursos e ajustaremos

as funcjpna!jdades de acordo com a necessidade.
Figura 15-31 Matriz de trade-ott dos projetos. Fonte: M. S. V. Turner, Microsoft Solutions
15.4 Deloitte: gerenciamento de programas

6
empresarial
Introdução
Mu itas organizações iniciam mais projetos do que tên1 capacidade de entregar. Con-
sequentemente, elas tipicamente tên1 coisas dema is para fazer e não dispõem tempo
ou recursos suficientes para tal. Os benefícios pretendidos de mu itos projetos mu itas
vezes não são rea lizados, e os resultados desejados raran1ente são alcançados em sua
total idade.
Há vários fatores que podem dificultar muito que se atinjam resultados previsíveis
em um projeto:
• Maior complexidade da natureza transformacional de muitos projetos
• Impulso constante por 1n elhor eficiência e eficácia
• Novas pressões para demonstrar responsabilização e transparência
• Aceleração do rit1no das mudanças e mudança constante de prioridades
Métodos tradiciona is de coordenação e gestão de projetos estão se tomando ine-
ficientes e podem levar à duplicação dos esfo rços, à on1issão de atividades específicas
ou ao mau a linhan1ento e priorização na estratégia de negócios. Ton1ar as decisões de
investimento certas, n1aximizando o uso de recursos disponíveis e realizando os bene-
fícios esperados pa ra impu lsionar o va lor organizacional, nunca foi ma is importante.
Este artigo irá explorar os métodos de gerenciamento de portfólio de p rojetos,
técnicas, abordagens e ferran1entas da Deloitte, indo da tradução da estratégia o rga-
nizacional em um conjunto a linhado de progran1as e projetos ao acon1panhamento
da obtenção do valor esperado e dos resu ltados das iniciat vias t ransformaciona is
en1preendidas.
Gerenciamento de programas empresarial

As organ izações estão enfrentando pressões cada vez maiores para "fazer ma is com
menos". Elas precisam equi librar as expectativas crescentes por mais alta qualidade,
facil idade de acesso e velocidade na entrega com novas pressões para demonstrar efi-
ciência e custo-efetividade. O tradicional equi líbrio entre o gerenciamento do negócio,
i.e., as operações do dia a dia, e a transformação do negócio, i.e., projetos e iniciativas
de mudanças, está 1nudando. Para muitas organizações, a proporção de recursos em-
p regados em projetos e programas au1nentou enorme1nente nos últünos anos. Ent re-
' O material sobre a Deloitte foi fornecido por Daniel .M.anyniuk, Chrisrine Lyman, PMP* e Rusty Greer.
Copyright e 2013 Deloirce Developmenr LLC. Todos os direitos reservados. Como usado neste documento,
"Deloirre'" significa Deloicre Consulring LLP, uma subsidiária da Deloicre LLP. Favor consultar www.deloirce.
com/us/abour para uma descrição detalhada da estrutura jurídica da Deloitte LLP e suas subsidiárias. Certos
serviços podem não estar disponíveis para atestar clientes sob as regras e regulamentações da contabilidade
pública. Essa publicação contém apenas informações gerais, e a Deloine não irá prestar, por meio desta pu·
blicação, consultoria ou serviços de contabilidade, negócios, finanças, investimentos, jurídicas, fiscais ou de
qualquer outra narureza. Esta publicaç.ão não é um substituto para essas consultorias e serviços profissionais,
nem deve ser utilizada como base para qualquer decisão ou ação que possa afetar seu negócio. Antes de tomar
qualquer decisão ou realizar qualquer ação que possa afetar seu negócio, você deve consultar um profissional
qualificado. A Deloine não se responsabiliza por nenhuma perda sofrida por qualquer pessoa que esteja
relacionada a esta publ icação.
canto, o desenvolvimento das capacidades organizacionais, estruturas e processos para

gerenciar e contr olar esses investimentos continua a ser u1na luta.
Além d isso, houve u1n au1nento significativo na interdependência entre projetos e
em sua complexidade. Embora, no passado, muitos projetos e progra1nas possam pro-
vavelmente ter se restringido a uma função ou área de negócio específica, hoje vemos
cada vez mais que há forces relações siscêmicas entre iniciativas específicas. A maioria
dos problemas não existe em isolamento, e as resoluções cê1n conexões e impactos
encadeados que vão alé1n do escopo de um único problema. Os projetos não somente
envolvem pessoas, processos e tecnologias cada vez mais distintos entre si, mas eles
também o faze1n ent re diferentes funções, áreas geográficas e, 1nuicas vezes, limites or-
ganizacionais. Sem uma abordagem estrutu rada pa ra sua imple1nentação, os projetos
e programas pode1n não conseguir produzi r o valor esperado. A necessidade de uma
abordagem estratégica pa ra a gestão de projetos, programas e portfólios é enorme.
A abordage1n da Deloicce para o gerenciamento de portfólios de projetos é repre-
sentada pela estrutura orientadora que é o Gerenciamento de Programas Empresarial
(EPM, Enterprise Program Managemenc), que fornece um modelo dentro do qua l os
projetos, programas e portfólios se enca ixam em uma hierarquia e1n que a execução
de projetos e a entrega de programas está a linhada à est ratégia empresa ria l e pode
levar a uma 1nelhor real ização dos benefícios desejados. Essa abordagem pretende
alcançar um equilíbrio entre o gerenciamento dos resultados (eficiência) e o gerencia-
mento dos recursos (eficácia) para produzir valor e1npresarial.
Na Figura 15- 32, a Estratégia inclui a definição da visão e missão da organização,
alé1n do desenvolvimento de metas, objetivos e medidas de dese1npenho estratégicas.
A capacidade de Gerenciamento de Portfólios t ransforma a estratégia empresarial
da organização em realidade e gerencia o portfólio para determ inar um alinha1nento
dos programas, a locação de recu rsos e realização de benefícios de 1nodo eficiente. O
Gerenciamento de Programas focaliza-se na estruturação e coordenação de projetos
individuais em conjuntos relacionados para determinar a realização de valor que pro-
vavelmente calvez não fosse alcançada com a ent rega independente de projetos sepa-
radamente. A Gestão de Projetos ajuda a possibilitar que o escopo definido de pacotes
de trabalho seja ent regue com os padrões de qualidade desejados.
Gerenciar resultados:
• Quais são as coisas "certas" a fazer?
• Estamos fazendo as coisas "certas"?
• Estamos fazendo o suficiente?
• Estamos obtendo os resultados que queremos?
Gerenciar recursos:
1
• Temos o mixde recursos ideal?
• Estamos fazendo as coisas "certas" da maneira "certa"?
• Estamos maximizando a eficácia?
Figura 15-32 Estrutura de Gerenciamento de Programas Empresariais (EPM) da Deloitte. © Deloitte

& Touche LLP e entidades afiliadas.
Estratégia e valor empresarial

Os líderes de negócios de hoje vivem em u1n inundo de perpétuo movimento, adm i-
nistrando e melhorando suas empresas ao mes1no tempo. Decisões difíceis têm de ser
tomadas rodos os dias - esta belecer orientações, alocar orçamentos e lança r novas
iniciativas - tudo para melhorar o desempenho organizacional e, em última análise,
criar e oferecer valor para as partes interessadas. É fácil dizer que o valor pa ra as par-
tes interessadas é i1nportante, mas é 1nuiro mais difícil fazê-lo influenciar as decisões
que são tomadas todos os d ias: onde gastar tempo e recursos, a melhor maneira de
conseguir colocar as coisas em prática e, em última análise, como vencer no mercado
competitivo ou no setor públ ico, e como eficientemente ent regar determ inada missão.
Servindo de suporte ao componente de Estratégia da est rutura de Gerenciamento
de Programas Empresa rial, o Mapa de Va lor Empresarial (Enterprise Va lue Map™) da
Deloitte é criado para acelerar a conexão ent re agir e gerar valor empresarial. Ele fa-
cilita o processo de se focalizar em áreas importantes, identificando maneiras práticas
de colocar as coisas em prática, e de determinar se as iniciativas escolhidas fornecem
o va lor de negócios que pretendiam. O Mapa de Va lor Empresaria l pode faci litar esse
p rocesso, acelerando a identificação de possíveis in iciativas de 1nelhorias e descreven-
do como cada um pode cont ribuir pa ra um maior valor para as partes interessadas.
O Mapa de Valor Empresa rial, ilustrado em versão resumida na Figura 15- 33, é
potente e interessante porque alcança u1n equilíbrio muito útil e prático entre:
• Estratégia e tática
• O que pode ser feiro e como isso pode ser feiro
• A demonstração de resultados e o balanço patrimon ial
'
Valor para as partes interessadas
Crescimento Margem Eficácia Expectativas

das receitas operacional dos ativos
• Volume • Custos de • Propriedades, • Pontos fortes

Gerenciamento venda, gerais e instalações e da empresa
de programas • Realização administrativos equipamentos
de preço • Fatores
• Custo de • Estoques externos
Gestão de mercadorias • Contas a
projetos vendidas receber e
• Impostos a pagar
Como o valor é criado Mudar o que você faz Fazer melhor aquilo que você faz
Direcionadores de valor (Estratégia/ (Tática/
~ •
•
Oque você oferece
Quem é seu alvo
• Processos de negócios
• Colaboração
( •
•
Como você compete
Onde você emprega seus
• Satisfação do cliente
e dos funcionários
Oque você pode fazer recursos • Desenvolvimento e uso
Alavancas de melhorias • Que operações você terceiriza de recursos ou ativos
• Desenvolvimento de capacidades
estratégicas
Figura 15- 33 Mapa de Valor Empresarial (EVM) da Deloitte. © Deloitte & Touche LLP e entidades
afiliadas.
• A capacidade organizaciona l e a execução operaciona l

• Desempenho atual e desempenho futuro
Em geral, o Mapa de Va lor Empresaria l ajuda as organ izações a se focal izare1n
nas coisas apl icáveis e serve como um lembrete gráfico do que está sendo feito e por
quê. Do ponto de vista executivo, o Mapa de Valor Empresarial é u1na est rutura que
descreve a relação entre as métricas a partir das quais as empresas são avaliadas e os
meios com os quais as empresas podem melhorar essas métricas. De uma perspectiva
funcional, o Mapa de Valor Empresarial é um resu1no de uma página de o que as em-
presas faze1n, por que elas o fazem e como elas podem fazê-lo melhor. Funciona como
uma potente estrutura de discussão, pois pode ajudar as empresas a se focalizarem e1n
nas questões que mais importarem para elas.
O Mapa de Valor Empresarial é usado pela Oeloitte para ajudar os clientes a:
• Identificarem coisas que podem ser feitas para melhorar o va lor para as partes
interessadas
• Ad icionarem est rutura à priorização de possíveis iniciativas de melhoria
• Avaliarem e comunicarem o contexto e valor de iniciativas específicas
• Fornecerem ideias quanto ao desempenho de negócio atual da organização
• Descreverem como o portfólio de projetos e programas se a linha aos direciona-
dores de valor
• ldentificare1n pontos proble1náticos e possíveis áreas para melhorias
• Descreverem iniciativas passadas, presentes e futuras
O valor para as partes interessadas é determinado por quatro"Determinantes

de Valor"básicos: o Crescimento das Receitas, a Margem Operacional,
a eficácia os Ativos e as Expectativas:
1. Crescimento das Receitas: O crescimento nas "receitas brutas" da empresa,
ou os pagamentos recebidos de clientes pelos produtos e serviços da e1npresa.
2. Margem Operacional: A porção das receitas que sobra depois de os custos
de prover bens e serviços terem sido subtraídos. U1na medida importante da
eficácia operacional.
3. Eficácia dos Ativos: O valor dos ativos usado ao administ rar o negócio em
relação ao seu nível atual de receitas. Uma medida importante da eficácia de
. .
1nvest1mento.
4. Expectativas: A confiança que as partes interessadas e analistas têin na capa-
cidade da empresa de ter bom desempenho no futuro. Uma medida impor-
tante da confiança do investidor.
Há literalmente mi lhares de ações que as empresas podem realizar para melhorar
o desempenho do valor para as partes interessadas, e o Mapa de Valor Empresarial,
em sua versão integral, descreve centenas deles. Embora as ações sejam bastante diver-
sas, a grande maioria delas gira em torno de um destes três objetivos:
• Melhorar a eficiência ou a eficácia de um processo de negócios
• Aumentar a produtividade de um ativo de capital
• Desenvolver ou fortalecer a capacidade de u1na empresa
As ações individuais do Mapa de Valor Empresarial começam a identificar como
uma empresa pode fazer essas melhorias. De modo geral, há duas abordagens básicas
para a melhoria:
1. Mudar o que você faz (mudar sua estratégia): essas ações envolvem mudan-
ças estratégicas - a lterar est ratégias co1npetitivas, mudar os produtos e servi-
ços que você oferece e para que1n, e mudar a designação de processos opera-
. . . .
c1ona1s para equipes internas e externas.
2. Fazer melhor aqu ilo que você faz (melhorar sua tática): essas ações envolvem
mudanças táticas - designar processos a diferentes grupos (ou cana is) inter-
nos ou externos, redesenhar os principais processos de negócios e melhorar a
eficácia e a eficiência dos recursos que executam esses processos.
Gerenciamento de portfólios
O Gerenciamento de Portfólios é uma abordagem estrut urada e disciplinada para
alcançar n1etas e objetivos estratégicos, escolhendo os investimentos mais eficientes
para a organ ização, e determinando a realização de seus benefícios e valor combina-
dos, exigindo, ao mesmo tempo, o uso de recursos disponíveis. A função de Geren-
ciamento de Portfól ios fornece a supervisão centralizada de um ou mais portfólios e
envolve identificar, selecionar, priorizar, avaliar, autorizar, gerenciar e controlar pro-
jetos, programas e outros t rabalhos relacionados, pa ra a lcançar n1etas e objetivos
estratégicos específicos. A adoção de uma abordagem estratégica do Gerenciamento
de Portfólios permite que as organizações n1elhorem a conexão entre estratégia e
execução, ajudando-as a estabelecer prioridades, estin1a r sua capacidade para p ro-
p iciar e n1onitorar a obtenção de resu ltados no projeto para impu lsionar a criação e
entrega de valor en1presarial.
A a bordagem da Deloitte ao Gerenciamento de Portfólios pode permitir que uma
organ ização associe sua visão estratégica ao seu portfól io de in iciativas e gerencie as
inciativas à med ida que for progredindo. Essa abordagem fornece a conexão crucial
que tr aduz est ratégia e1n realizações operacionais. Como ilust rado na Figura 15- 34, a
Est rutura de Gerenciamento de Portfólios ajuda a responder as perguntas: "Estamos
fazendo as coisas 'certas'?", "Estamos fazendo o suficiente de coisas 'certas'?" e "Quão
bem estamos fazendo essas coisas?".
Uma vez implementada, a estrutura ajuda a t ransformar a estratégia de negócios
em um portfólio de iniciativas coordenadas que funciona 1n juntas para aumentar o
va lor para as partes interessadas. Alé1n disso, ela pode fornecer as ferramentas e técni-
cas para manter os projetos no cam inho certo, aumentando muito as chances de uma
organização de alcançar os resu ltados desejados. Ela focaliza uma organização e1n ini-
ciativas que ofereçam maiores oportunidades de criação de valor e que também forne-
ça1n uma estrutura e disciplina para estimular iniciativas de 1nelhoria de desempenho
e auxi liar na identificação de oportunidades de melhorias contínuas. Finahnente, ela
garante que os recursos e o orçamento apropriado sejam disponibi lizados para tarefas
críticas e fornece as ferramentas e técnicas para gerenciar eficientemente o portfól io de
iniciativas de uma organização.
O pri1neiro passo crucial no processo de desenvolver um portfólio de projetos efi-
ciente é o estabelecimento de um método para determinar que projetos cairão dentro e
que projetos cairão fora do escopo do portfólio. Uma clara defin ição do que constitui
u1n "projeto" é necessária, a lém da identificação de critérios que serão aplicados para
colocar uma iniciativa específica dentro ou fora dos limites do portfól io. Daniel Mar-
tyniuk, u1n gerente da prática de Estratégias e Operações da Deloitte Consulting LLP,
especial izado e1n gerenciamento de portfólio de projetos, realça:
Embora esse primeiro passo pareça básico no sentido de que seu objetivo é fornecer uma
estrutra básica na qual definir, separar e categorizar projetos, o componente crítico é cuida-
dosamente captar todos os projetos que estejam sendo empreendidos atualmente ou que te-
Estamos fazendo
Estamos fazendo as coisas "'c-ertas"? o suficiente das Quão bem estamos lazendo essas coisas?
coisas "'certas"'?
TRADUÇÃO DA ESTRATEGIA EXECUÇJ.D DA ESTRATEGIA
AUXHAJI. PRO.JflOS AVAllJ.R E AfVISJ.ll OTUIIZAJI. AVALIAR AS Pfl[[NCHER

AOlil.fÇAOEAOS PROJETOS O PORTf()UO CAPACIDADES DE LACUNAS DE GERENCIA.A
O POATFOUO
8tKmc1os O[ NEGOCIO E•OATIVAS DE PRO.VOS EXECUÇÃO ATUAIS CAf.lCIOAD!S
• l.11'1'11 esttun p,3ra

trinl\lJ pro,e1os e
• í«alit.lr aalft'l;iO na • C(wil'irmar aadeQlu3ÇIO . Oel!rmit'III' atawna
enlrt aOlft'la ea
.
""""
umaes1,..._a
. Permrnro
jllSlli:alf,a de llf9ÕOOS df PfOi«OS CCW!l 8S ai'lllat'l'INIO
illiC:i.1liv3S às
pnOti!.ld@S ae aeoõeios
e l)MSivtiS l!et'ltr..CiOS
po, lrb de cada projeio
e illitillr.YI
• fOMeC!r ~ 1!(111! d!
pr.orwdes de l'leQ~
• MIAilnilar a Olljthid.lde
e a con~hlttia •
. det'l'INld.1 de recursos
Cor"!Sidn as llltiillldes
e eotnoelêl'lciaS
organi21ci01'111
quepe~UO
Qb'811C~n10
conlinuode
j!rOjetoS C0'1I
as prielrillldes
. Foeawr os rewrsos
~-· ......_
- • Faeiliu, a compreeMiO ftdilllS de quak!Me. Cri.1çJo de põfU't,os neces.utllS do,; recursos de iniOralúas e bMeícios
dlS ifflfr-tebQõeS
muilOSi)arlH'~
\llllôr erisco para avaiar
JWOietos e ll'lieialrlas
• h11ar enos de
d~çJo e Oll'liHJo nas àr9tS que ais
eslmfgicu
. """"""ª . de tlfQOCios
c.o.li'nw (t.l! as
Mlrtotiteli~de
t'lfQÕC:iOS ep,()jKOS
, connrrn.1, a v31id.1de • Mello,., o uso de
. jlreci~M de IIW!lllewi8S
Comuncar as tnelltlfes MiniOrab',as
iniCiahv3s alftkl•
SNS Otljtw:1$
-
e acon~klei.1 de ftc:un:OS ~11-dOS
• caieui. o orau eotn • COmeçar a ~ utll prücas por toai lllul!ilur'ICiOnas
Que as initimlas
il'llotm~ões. petm,,lilldO
fl'l!lllOtff comparai;:6es C0119!11SIO SO!lle Oque,
~,1 Ou fllO r!l'IUMIO . a organll,çlo
Cot1irmar q.e o
. s>.omo...era et'IQU,ll'llo.ao
Oll!feteM SUpotl! • A ~lrulul\1 f VUd3 p,,a alil(jlem as
IS t'lfCeoS~ld!S Mli.1r ao.31iv.tt potl161iO 'l)rMdO e aeoor~o tljletla!MIS de
delleG6ci0S il'ltrtmel'Uis e 1104 es.wil a~ado às IWl!redr,enas tempo. custo
JlfOjetcd ~a,es aauaiS illieilli.YIS eQ"Alicl*
Figura 15-34 Estrutura de Gerenciamento de Portfólios da Deloitte. © Deloitte & Touche LLP
e entidades afiliadas.
nham sido propostos para aprovação. Muitos projetos de d ifícil definição são muitas vezes
ignorados, já que eles podem assumir a forma de atividades cotidianas o u podem oco rrer
"por trás dos bastidores" . Sendo assim, é essencial definir limites claros entre operações do
dia-a-dia e o trabalho de projetos - deixar de fazê-lo pode levar a ambiguidades e à repre-
sentação imprecisa do número verdadeiro de projetos na o rganização.
Um método consistente de categorização, cotno a Estrutura de Investimento da
Deloitte ilustrada na Figura 15- 35, ajuda a responder à pergunta: "por que estamos
alocando recursos a esse projeto?".
Ela pretende definir as diferenças ent re iniciativas que permitem um reconhe-
ci tnento e categorização i1nediatos de projetos e fornece o contexto para comparar
projetos que seja tn diferentes em sua natureza ou escopo. Ela tambétn facil ita a aloca-
ção de recursos primeiro por tipo, depois pela priorizaç.ã o de projetos dent ro de utn
mesmo tipo. Mais importante, ela fornece u1na base comum para faci litar o diálogo e
discussões sobre priorização.
Uma vez que o escopo do portfólio tenha sido estabelecido, a organ ização pode
exigir um processo disciplinado para possibi litar o a linhamento contínuo de projetos
a objetivos est ratégicos, avaliação, priorização e autorização, alé do gerenciamento
contínuo do progresso, mudanças e a realização de benefícios.
O Processo de Gerenciamento de Portfólios da Deloitte, como ilustra a Figura
15- 36, pode servir de base para a definição da sequência comum de gerenciamento de
portfólios. Ela permite que a coordenação ent re projetos tire proveito de sinergias e
reduza redundâncias. Ajuda tambétn a delinear e identificar projetos em um formato
comparável em que há diversas oportunidades de projeto e/ou pontos proble1náticos
para a organização para aumentar o va lor criado pelas iniciativas das organizações,
equilibrando, ao mesmo tempo, risco e recompensa.
TRANSFORMACIONAL
oN
~
e. Transforma a infraestrutura
o central para que ela siNa
g>
de suporte ao modelo
de negócios desejado.
Aumentar receitas
eo tamanho
.e
o
PROOUTIVIOAOE MANUTENÇÃO
......11111 ,.
Melhoria das Evita a erosão
margens e da das margens e
utilização de a deterioração Ili"'
,r,i,~ ativos dos ativos ~e,
-. sr,MENros oPEcl'Jl.c.\0~ Mantém a funcionalidade

facilita a melhoria do da infraestrutura, reduz
desempenho operacional custos e eleva a qualidade
de processos existentes e a eficãcia dos seNiços
MELHORIA OE
PROCESSOS RENOVAÇÃO
Escopo do projeto
Solução de negócios Infraestrutura compartilhada
Figura 15-35 Estrutura de Investimento da Deloitte. © Deloitte & Touche LLP e entidades afiliadas.
Quando a lista aprovada de projetos que compõe1n o portfólio for estabelecida, o

registro e o sequenciamento do projeto passa a ser o passo crítico seguinte. Só porque
u1n projeto faz parte do registro de projetos "aprovados", isso não significa que ele
deve ou será iniciado imediatamente.
Há inúmeros fatores que devem ser considerados ao determinar a sequência apro-
priada para a execução do projeto. Alguns dos importantes critérios de decisão para o
sequenciamento de projetos incluem:
• Prioridade est ratégica - o nível de i1nportância dado a esse projeto pelas partes
interessadas ou pela liderança da organ ização; acelerar o início das iniciativas que
cont ri buam diretamente com a realização dos objetivos de negócios declarados.
• Janela de oportunidade - a lgumas iniciativas precisam ser concluídas dentro de
certo período de tempo a fim de obter os benefícios desejados; dar a essas iniciati-
vas a consideração necessária para ajudar a garantir que a oportunidade de gerar
valor não seja perd ida .
• Interdependências ent re os projetos - confirmar que todas as dependências en-
tre projetos relacionados tenha ,n sido identificadas e consideradas ao toma r as
Fazer o design
Traduzir estratégia do portfólio Gerenciamento de portfólios Execução de pro1etos
•••
: Reunir informações
sobre o projeto
utilizando um
template padrão ,
°n
:
Acompanhar periodicamente beneflcios, custos,
I
recursos, mudanças, alinhamento estratégico
e mais usando dashboardscom indicadores
da · saúde" dos projetos, programas
e portfólios
í Gerar relatórios
para comunicar seu
portfólio a todas as
partes interessadas
Desenvolver Monitorar Implementar

Estabel~er ) ' um modelo programas
o portfólio e executar
de priorização e projetos o portfólio
Coletar
Es~belecer
periodicamente
as linhas de base
, l
: Desenvolver e ponderar:
: os critérios de valor
: informações
sobre o
projeto
~
Comunicar e
gerar relatórios
1
Lo,
E~utar
seu portfólio
do portfólio e de risco Autorizar
e alocar o baseado no
roteiro e plano
orçamento
\ Analisar --...:_ priorizados
?~
r
o portfólio
Gerencia· Priorizar -o
Aqueles que forem
mentodo programas
portfõlio ;'b~ e projetos
responsãveis pela
Gerenciamento
de programas
%
<r> Avaliar o valor e o risco
de cada projeto e programa
e produzir uma lista
! entrega dos benefícios
revisam e, então,
autorizam, rejeitam ou
adiam os programas
e projetos priorizados
Gestão de priorizada de projetos Criar uma lista de projetos
projetos com sugestões de cortes priorizada de acordo com
possiveis restri ões e limltes
Figura 15- 36 Processo de Gerenciamento de Portfólios da Deloitte. © Deloitte & Touche LLP e
entidades afiliadas.
decisões de sequenciamento e iniciação do projeto; além d isso, considere outras

dependências que podem afetar o início ou a conclusão de projetos, cotno o tempo
levado para tomar decisões itnportantes, o ciclo orça1nentário, etc.
• Disponibilidade de recursos - utn projeto não pode ser iniciado até que os re-
cursos aplicáveis se rornetn disponíveis para começar a traba lhar nesse projeto
específico; ent retanto, lembre-se de que " disponibi lidade" não é uma habil idade,
e, a lém de conseguir os recursos designados para o seu projeto, certifique-se de
que eles sejam os recursos "certos" em termos de seu conhecimento, habi lidade e
expenencta.
• Risco - considere o nível de risco que se corre em decorrência de empreender
determinado conjunto de projetos; não é uma boa ideia iniciar projetos de alto
r isco todos de uma vez, rodos dentro do mesmo período de entrega; projetos de
alto risco devem ser monitorados de perto e você deve se esforçar para encontrar
um mix aplicável de projetos de a lror risco e de baixo risco; sempre que possível,
você deve considerar executar projetos de a lto risco etn diversas etapas e conduzir
uma aná lise de r isco completa para determinar e decid ir sobre as est ratégias de
m itigação de r isco apropriadas.
• Mudanças - considere a novidade do etnpreendimento, e a quantidade de mu-
danças a ser introduzida em sua organização em decorrência da implementação
do conjunto proposto de mudanças que estiver sendo criado - só se pode fazer a
quantidade de mudanças que uma organização pode suportar; execute esses pro-
jetos em etapas que int roduzam mudanças significativas e sequencie-as de modo a
limitar a fadiga proveniente de mudanças em sua organ ização.
• Custos/Benefícios - d iferentes iniciativas possuem diferentes custos/benefícios a

elas associados; assim como com os riscos, é imperativo co1npreender que projetos
oferecerão os maiores benefícios pelo menor custo; você não quer começar todos
os seus projetos de custo 1nais alto ao mesmo tempo, especialmente se você não
for colher todos os benefícios ad iantados.
Um fator para o sequenciamento adequado e, consequentemente, um equ ilíbrio
adequado do porúól io, é ter uma compreensão sólida quanto à capacidade de entrega
da organização, betn como de seus recursos. As organizações deve1n saber quem está
d isponível para trabalhar em projetos e que tipo de habi lidades eles possuem. Geral-
mente é fácil determinar quantas pessoas há - então, criar u1n inventório de recursos
norma lmente não é nenhum problema. O desafio chega quando tentamos determinar
e1n que os recursos estão trabal hando atualmente e que disponibilidade eles têm para
t rabalhar em projetos ou para projetos ext ras, se eles já estiverem t rabalhando em
a lgum. Um dos 1nétodos d isponíveis para obter um quadro correto é acompanhar as
horas t rabalhadas pelos recursos e1n um projeto.
Os resultados de longo prazo e os benefícios esperados com a adoção de um Pro-
cesso e uma Estrutura de Gerenciamento de Portfólios consistentes podem incluir, mas
não se limitam a, ter a habil idade e a capacidade de:
• Fazer escolhas conscientes ao selecionar projetos para imple1nentação baseados
em informações corretas e atualizadas como o a linhamento estratégico às priori-
dades de negócios, os benefícios esperados, os custos estimados e os riscos iden-
tificados.
• Determinar a capacidade, i.e., o nú1nero de projetos concorrentes para gerenciar
projetos pequenos, médios e grandes, de modo a possibi litar a priorização.
• Gerenciar proativamente os riscos associados a projetos de transformação peque-
nos a médios, além de grandes e complexos.
• Aumentar as competências centr ais na gestão de projetos em toda a organ ização e
adotar uma abordagem de gerencia1nento de portfólios para a tomada de decisões
executiva.
• Racionalizar e padronizar processos relacionados à gestão de projetos individuais,
além de 1núltiplos projetos e portfólios de projetos relacionados.
• Manter uma lista atua lizada de todos projetos, ativos e inativos, fasear a iniciação
dos projetos de modo que elas correspondam à capacidade e melhorar a entrega
de acordo com os requisitos de projetos aprovados.
• Maxim izar o uso de recursos internos e racionalizar o uso de recursos externos
para co1nplementar a equ ipe interna, com maior capacidade de criar valor e de
concluir eficientemente o portfól io de projetos aprovados.
• Medir o desempenho em tetnpo real e acompanhar a realização dos benefícios dos
projetos e/ou programas; com a capacidade de identificar o progresso real feito na
obtenção de resultados tangíveis e resultados reais.
De acordo com os padrões de prática do Instituto de Gestão de Projetos (PMI), um
programa é u1n grupo de projetos relacionados, gerenciados de maneira coordenada
para obter benefícios e cont roles não disponíveis no gerenciamento de cada um deles
individualmente. Os programas podetn inclui r elementos de t rabalhos relacionados
(p.ex., operações em anda1nento ) fora do escopo dos projetos discretos em u1n progra-
ma. Algumas organizações chamam seus projetos grandes de progra1nas. Se um pro-
jeto grande for quebrado em diversos projetos relacionados co1n um gerenciamento
explícito dos benefícios, então o esforço se torna um programa. Gerenciar múltiplos

projetos por meio de um programa pode melhorar os cronogra1nas em todo o pro-
grama, gerar benefícios incrementais, a lém de possibilitar a otimização do pessoal no
contexto das circunstâncias gerais do programa.
Como ilustrado na Figura 15- 37, a abordage1n da Deloitte para o Gerencia1nento
de Programas realça quatro responsabil idades cent rais para a função de gerenciamen-
to de programas: a integração de programas, a conscientização de dependências, a
aderência a padrões e a geração de relatórios sobre os programas. A figura ilustra ain-
da atividades primárias e secundárias que caem no escopo do trabalho dessa função.
Embora tempo, custo e escopo/qual idade seja1n medidas de desempenho impor-
tantes no nível do projeto individual, a coordenação, co1nunicação e sequencia1nento
são os fatores no nível do programa que ajudam a possibi litar os resultados deseja-
dos. Isso ocorre porque o Gerencia1nento de Programas envolve o agrupamento e o
gerenciamento de uma série de projetos de maneira integrada, e não somente concluir
projetos individua is. No fina l das contas, uma boa gestão de projetos pode ajudar a
entregar o programa de acordo com o escopo planejado. Um bom gerenciamento de
progra1nas também fornecerá u1na melhor compreensão das conexões e dependências
entre projetos e programas em todo o portfólio geral de projetos.
Gestão de projetos
No nível dos programas, a consistência pode gerar resultados desejáveis. Esse ritmo
operaciona l perm ite relatórios e monitoramentos regulares e em múltiplos projetos.
Responsabilidades centrais
Integração do programa Conscienlização de dependências
• Alinhar programa e projetos • Realçar conexões e
ã estrateqia de negócios dependências para garantir
a compreensão de todo
• Manter sinergias em todo o programa em todo
o programa por meio do emprego
o portfólio de projetos
de ferramentas, processos
e prãticas padronizadas
Aüvidades primárias
Governança e plane1amento Gerenciamento do
de programas escopo de programas
Gerenciamento
Gerenciamento das de programas Gerenciamento dos
comunicações de programas recursos de programas
Gerenciamento da Gerenciamento dos riscos e
qualidade de programas Gestão de problemas de programas
projetos
Aderência aos padrões Atividades secundãrias Geração de relatórios

• Desenvolver e disseminar Gerenciamento de • Fornecer à liderança de
padrões para o gere<1ciamento fornecedores/contratos programas as inlormações
da qualidade e dos projetos de que eles precisam para
Gerenciamento de benefícios tomar decisões eficientes
• Monitorar o cumprimento e rápidas
de padrões apropriados Gerenciamento de
de aplicação mudanças no pessoal
Figura 15- 37 Estrutura de Gerenciamento de Programas da Deloitte. © Deloitte & Touche LLP e
entidades afiliadas.
No nível do projeto, essa consistência nem sempre faz sentido. A variaç.ã o interna nos
projetos pode ser produto de inúmeros fatores:
• Tipo de projeto (p.ex.: desenvolvi1nento de estratégia, imple1nentação de tecnolo-
gias, implementação de mudanças organizacionais, etc.)
• Escopo geográfico/organizacional (p.ex.: único local, único país, global)
• Modelo de implementação de projetos (p.ex.: ágil, em cascata, iterativo, etc.)
• Tamanho da equipe de projetos
Essas variâncias levam a diferentes necessidades e rest rições que afetam alguns
processos de gestão de projetos. Isso impl ica as diretrizes e1npresariais e de programas
precisarem ser padronizadas em algumas áreas, retendo, ao mesmo tempo, a flexi-
bilidade em outras. Esse equi líbrio, quando devidamente alcançado, pode pennitir
que os gerentes de projetos ajustem os processos em certas áreas (p.ex.: relatórios de
status, planeja1nento de traba lho), ajudando, ao mesmo tetnpo, a alcançar os padrões
de desetnpenho mínimos.
Além disso, há outros fatores externos ao projeto que tambétn causa1n variabili-
dade e, portanto, devem ser considerados. Alguns desses fatores adicionais incluem:
• Indústria
• Ambiente (p.ex.: setor públ ico, regulamentado, comercial)
• Tecnologia sendo implementada (p.ex.: solução de "nuvem", sistemas integrados
de gestão empresarial ERP, etc.)
Mesmo com tantos elen1entos diferenciais, há a lguns processos e diretrizes que per-
manecerão fixos independente de que modelo de gestão de projetos é selecionado. Isso
inclui leis e regulan1entos, políticas organizacionais, padrões da empresa, controles de
projeto e processos/políticas de gerenciamento financeiro. (Ver Figura 15- 38.)
É importante que a organização compreenda onde é necessária a variabilidade e
onde a padronização é necessária e eficiente. O objetivo é facilitar para que as equi-
•
Leis/Regulamentações
Políticas organizacionais
Padrões da empresa
Controles do projeto
Gerenciamento financeiro
• •
Figura 15-38 Comparação de fatores organizacionais lixos versus fatores variáveis.© De-
loitte & Touche LLP e entidades afiliadas.
pes de projeto ent regue1n soluções be1n e não sejam dogmáticas ou excessivamente
teóricas. A empresa também se esforça para ajudar a possibilitar o estabelecimento
de salvaguardas aceitáveis para identificar e gerenciar situações "fora do controle" de
. .
maneira proativa.
À medida que cada projeto é iniciado, consideram-se suas especificidades. O resul-
tado é um conjunto personalizado de processos de gestão de projetos que se alinha1n
aos padrões da empresa e do programa, refletindo, ao mesmo tempo, a natureza espe-
cífica do projeto propriamente dito.
A metodologia
Uma solução holística de gestão de projetos está relacionada à definição e à entrega de
fluxos de trabalho específicos dentro de uma estrutura gera l de Gerencia1nento de Pro-
gramas Empresarial. Ela inclui padrões, processos, te,nplates, treinamento, materiais
de apoio e ferramentas. Quanto mais esses componentes puderem ser padronizados,
mais fácil será imple1nentá -los; as equipes co1npreendem as expectativas, conhece1n as
ferramentas e já vivenciaram os processos.
A Geração de Valor Empresarial (EVD, Enterprise Value Delivery) em gestão de
projetos é o método da Deloitte para entregar soluções consistentes de gestão de pro-
jetos para nossos clientes. O n1étodo aborda siste1natican1ente componentes específicos
de gestão de projetos e é un1a abordagem comum baseada em padrões e com o suporte
de ferran1entas possibilitadoras, orientação de profissionais experientes e treinamento.
Esse método é ampl iável e flexível, podendo ser integrador outros n1étodos da Deloitte,
integral ou parcia hnente, para abordar problen1as relevantes de gestão de projetos. Ele
incorpora padrões, embora tambén1 permita que projetos individuais personal izem as
partes que fizerem sentido para sua situação específica.
Criado para ajudar os praticantes da Deloitte a gerenciar seus projetos, a EVD

em gestão de projetos é:
• Ampl iável - usa um design modular para aumentar sua flexibilidade e pode se
adequar à maioria dos projetos, incluindo uma variedade de tamanhos ou escopos
de projeto.
• Baseada em deliverables - possibi lita a natureza iterativa dos processos de gestão
de projetos.
• Prescritiva - inclui ferramentas, procedimentos detalhados, templates e amostras
de deliverables específicos para o gerenciamento do projeto que ajudam os prati-
cantes a iniciar, planejar, executar, cont rolar e encerrar o projeto.
• Rica em informações - abriga uma quantidade extensa de informações sobre pro-
cessos metodológicos, distribuição de trabalhos e criação de deliverables.
• Baseada na experiência - perm ite que os praticantes aproveitem materiais reuti li-
záveis desenvolvidos por meio da vasta experiência e conhecimentos da indústria
relativos à nossa prática.
• Baseado em práticas líderes - reflete as melhores práticas da Deloitte e pesquisas
e a experiência da indústria, permitindo que seus praticantes compartilhem u1na
linguage1n comum em todo o mundo.
• Prática - fornece informações real istas e úteis, focalizando-se no que rea lmente
funciona.
O conteúdo do método de gestão de projetos da Deloitte está alinhado ao Corpo
de Conhecimentos (Guia PMBOK®) do Instituto de Gestão de Projetos (PMI) e ao
Modelo de Maturidade em Capacitação - Integração (CMMI) do Instituto de Enge-
nharia de Software (Software Engineering Institute, SEI). Dividido em duas disciplinas
de trabalho, a Gestão de Projetos e o Gerencia1nento da Qua lidade, o 1nétodo inclui
descrições deta lhadas de tarefas, instr uções passo a passo e considerações para a con-
clusão de tarefas que são essenciais para a entrega de uma solução de GP. Diversos
auxílios ao desenvolvimento, incluindo diret rizes, procedimentos e ferramentas, com-
p lementam cada tarefa.
Diversos benefícios podem resultar da aplicação consistente das tarefas de
deliverables definidos de gestão de projetos:
• Ajudar os gerentes a ver o "quadro" geral e acelerar o trabalho
• Fornecer uma abordagem consistente e uma linguagem comum
• Incluir te,nplates e ferramentas de deliverables
• Incorporar o Gerenciamento de Qual idade e Risco, facilitando a melhoria da qua-
lidade e a redução de riscos dos deliverables de projetos
• Pode ser usada para gerenciar programas a lém de projetos
As ferramentas
A Deloitte descobriu que aproveita r ferramentas focalizadas em possibilitar processos
de gestão de projetos pode ajudar a impulsionar a adoção de sólidos processos de
gestão de projetos em uma organização. Há inúmeras ferramentas d isponíveis para as
organizações usarem e todas elas têin seus próprios conjuntos de vantagens e desvan-
tagens. (Ver Figura 15- 39.) Selecionar a ferramenta apropriada pode ajudar a facili-
tar a consistência do gerenciamento em todo o projeto, mas é importante diferenciar
ent re processos e ferra 1nentas. É menos i1nportante que ferramenta é implementada,
contanto que haja uma rigorosa discipl ina de processos. Ter uma ferra1nenta de ponta
e pronta para usa r é extremamente vantajoso, 1nas o equi líbrio é entre flexibi lidade
(usar a ferra 1nenta apropriada para o trabalho) e a padronização (independentemente
da ferramenta usada, você deve realizar um conjunto prescrito de tarefas).
Se uma organização não possui uma ferramenta disponível para uti lizar, a De-
loitte possui uma solução que pode beneficiar os clientes. A ferramenta personalizada
fornece recursos sofisticados sendo, ao 1nesmo tempo, suficientemente simples para
o rganizar uma equipe de projetos rapidamente. Oferece-se segurança em um ambiente
com múltiplos usuários, e os praticantes são t reinados na ferra 1nenta antes de se en-
volverem em um projeto.
Gestão de projetos "Ágil"

A solução EVD da Deloitte estabelece uma base para realizar tarefas comuns de gestão
de projetos, fornecendo, ao 1nesmo tempo, a flexibil idade para personal izar processos
para dar conta da variabilidade conhecida:
• Definindo típicos modelos de uso pa ra cenários de soluções frequentes que incor-
poram todo o espectr o dos co1nponentes de soluções (documentação, t reinamen-
to, amostras, etc.)
• Fornecendo diretrizes para possibi litar que os projetos tirem proveito dos proces-
sos apropriados para as circunstâncias específicas de seu projeto
• Pennitindo flexibil idade para definir u1na estr ut ura de governança apropriada
para servir de suporte ao perfi l específico de r iscos/custos do projeto
Condições de mercado emergentes também estimularam a necessidade de ava liar
p rocessos-padrão de gestão de projetos, especialmente em um a 1nbiente "Ágil". As
abordagens Ágeis são tipicamente usadas em projetos em que os requisitos não são
claros ou estão sujeitos a mudanças frequentes, e/ou em que é necessária a entrega
frequente de componentes de solução com o maior valor. Projetos que e1npregam uma
metodologia Ági l realizam certos processos de gestão de projetos de manei ra similar
Características da ferramenta Benefícios para o projeto

Possibilidade de acessar a ferramenta de
Baseada na web qualquer local de entrega
Dados consolidados, seguros e holísticos sobre

Única fonte de verdade
o projeto
Ruxos automatizados com desencadeamento

Fluxo de trabalho poss1b1htado
de exceções e alertas
Pré-configurada Rápida iniciação do projeto
Flex1b1hdade nos relatórios Exportações, dashboards, on-line e relatórios em lotes
Personalizado Telas, conteúdos e dados customizados
Figura 15-39 Características da ferramenta de gestão de projetos da Deloitte. © Deloitte &

Touche LLP e entidades afiliadas.
aos projetos que usam abordagens em cascata ou iterativas (p.ex.: gestão de riscos e
problemas, gerenciamento financeiros e a lguns aspectos da geração de relatórios de
status), enquanto outr os são realizados de maneira 1nu ito diferente. A EVD fornece
orientação para gerentes de projetos de ambas as perspectivas. Além disso, para os
aspectos que são diferentes, ela prescreve co1no eles podetn ser abordados usando téc-
nicas específicas à metdologia Ági l.
Especifica1nente, o gerenciamento de escopo e o planeja1nento e acompanha1nento
do trabalho na metodologia Ágil é significativa1nente diferente do que em projetos que
usam u1na metodologia em em cascata ou iterativa. A EVD da metodologia Ágil des-
creve como os projetos se desenvolvem e gerencia os Backlogs de Produto e Sprint
Backlog, • e inclui diretr izes para a documentação de histórias de usuários que são
suficientemente detalhadas para sere1n abordadas em uma única sprint. Descreve a
aná lise de 1nét ricas (usando velocidade, capacidade e gráficos de bttrn upldown) que as
equipes de projetos usam para determinar o tamanho das sprints e as histórias dos
usuários, prever a entrega de componentes e incluir os relatórios de produtividade que
são usados para monitorar o progresso. O fator importante é reter u1na disciplina su-
ficiente de gestão de projetos, mesmo se as técnicas para gerenciar o t rabalho fore1n
drastica1nente diferentes. E1n resumo, embora a metodologia Ágil possa ser totahnente
diferente em como um projeto é executado, as funções básicas da gestão de projetos
ainda existem e a Deloitte identificou uma maneira de realizá-las.
A equipe de projetos
Mesmo com o método e conjuntos de ferramentas mais intricadas, sem uma equipe de
projetos ded icada e t reinada, o projeto a inda pode falhar. Recursos com experiência
sign ificativa em gestão de projetos ou programas tipicamente funcionam no nível de
Gerenciamento de Programas, enquanto recursos com experiência limitada ou inexis-
*N. de T.: Sprint é cada um dos ciclos do processo de desenvolvimento de um produto. O Sprinr Backlog
representa mdo o que será feito durante a próxima Sprint do seu projeto. Ele surge a partir da preparação,
escimação e priorização de itens que foram levantados e listados no Backlog de Produto, onde ficam até serem
selecionados para o Sprint Backlog.
tente podem se encont rar no nível do projeto. Tendo dito isso, ter uma abordagem de
gestão de projetos que leva isso em consideração é essencia l.
Para tornar os recursos eficientes durante todo o projeto, há a lgumas coisas a
serem consideradas ao personalizar a implementação de sua gestão de projetos, co1no
mostra a Figura 15-40.
• Compreender as impl icações do gerenciamento de mudanças internas. Os proces-
sos de Gerenciamento de Mudanças podem ser mais rígidos e1n alguns lugares do
que em out ros. O projeto tem que estar totalmente consciente de por que circuns-
tâncias precisará passar durante o processo de gerenciamento de mudanças e que
i1úormações serão necessárias em que momentos. Isso é crucial para facilitar que
as mudanças sejam encaminhadas de maneira correta e eficiente. Ter de revisar a
precisão de e.ada solicitação de mudança torna o projeto ma is lento e pode ter um
efeito adverso imprevisto sobre as linhas do tempo do projeto.
• Inicie as atividades básicas logo. Reconhecer que, embora as camadas de gerencia-
mento empresaria l e de programas sejam tipica1nente ocupadas por profissionais
de GP dedicados e que traba lham e1n regime de tetnpo integral, as equ ipes de
projetos tipicamente inclue1n recursos operacionais que têm pouca ou nenhuma
experiência com projetos. Certifique-se de que a equipe de projetos saiba o que
se espera deles e conheça os "fundamentos" de seu traba lho. Exemplos incluem:
Comece
como básico
facilrte a
real izaç.\o das
tarefas do
dia a dia
Figura 15-40 Fatores-chave da implementação da gestão de projetos. © Deloitte & Touche

LLP e entidades afiliadas.
• Com que frequência preciso fazer relatórios de stat11s?

• O que é a linha do tempo geral?
• Onde posso encontrar a documentação do escopo deste projeto?
Realizar a abertura e implementar o rigor adequado nos processos logo no
início é essencial ao apresentar a equipe à dinâmica específica de um projeto. É
nesse momento que a linha do tempo geral, os protocolos de gestão de projetos, os
papéis e responsabilidades, entre outros tópicos, são apresentados. Nesse momen-
to, a equ ipe de projetos também pode iniciar outras atividades de planeja tnento,
incluindo a identificação ou o desenvolvimento de templates.
• Faci lite que se faça 1n bem as coisas simples. Para tarefas do dia a dia, como arma-
zenar deliverables atualizados, registrar o tempo ou o status, ou atualizar o plano
de t raba lho, o esforço deve ser míni1no, independentemente do nível de experiên-
cia. Essas atividades não devem causar gastos extras para o projeto. Quanto mais
tempo se leva para rea lizar essas coisas, 1nenos tetnpo produtivo haverá para o
trabalho substancial de criação ou construção e1n u1n projeto.
• Aproveite os especialistas quando forem necessárias atividades de gestão de proje-
tos mais avançadas. Certas atividades exigem significativamente 1na is habilidades
e não devem ser rea lizadas por noviços inexperientes em projetos. Essas áreas
muitas vezes estão centradas e1n esforços de planejamento de trabalho. As ativi-
dades de p lanejamento de t raba lho ocorrem durante todo o projeto e exige1n u1na
profunda compreensão das dependências do gerencia1nento, identificando itens
do caminho crítico e realizando uma 1neticu losa alocação de recursos. As ativida-
des apresentadas na Figura 15-41 focalizam-se somente no desenvolvimento ini-
cia l do p lano de trabalho. Os recursos também precisam compreender que ajustes
são necessários para o plano de trabalho à medida que as mudanças ocorrerem no
escopo ou nos recursos.
• Mantenha o foco nos processos definidos de gestão de projetos quando as coisas
se tornarem precárias. À medida que mudanças ocorrem ao longo do projeto, às
vezes parece que ele pode sair do controle. Uma das maneiras de evitar isso é pre-
servar os processos de gestão que foram aprovados na in iciação do projeto. U1na
sólida disciplina de gestão de projetos perm ite que o gerente de projetos tire o
projeto de qualquer situação incerta que possa surgir. O processo pode determ inar
o efeito geral do escopo, a linha do tempo, os recursos ou os orçamento de u1n
projeto se gerenciado d iligentemente. É essencial manter a discipl ina quando as
coisas co1neçam a dar errado - justamente quando as pessoas tipicamente dize1n
"não tenho tempo para isso" é quando as coisas se torna1n mais críticas.
A gestão de projetos excelente é o resultado de uma clara compreensão do contex-
to do projeto. A implementação de processos e ferramentas padron izadas pode faci li-
tar, mas somente se equi librado de forma a refletir as variações de cada projeto especí-
fico. Uma vez que esse equilíbrio tenha sido determinado, trata-se primordiahnente de
uma questão de fazer bem as tarefas básicas. Co1nunique as expectativas e estabeleça
disciplinas logo no início, de modo que elas se tornem um hábito. Isso permite que a
equipe de projetos focal ize suas energias criativas em const ruir a melhor solução, que
é, afinal, o motivo pelo qual o projeto existe, em primeiro lugar.
Liderança e governança
Há fatores adiciona is que influenciam a capacidade de uma organização de gerar valor
e entregar resultados de transfonnação que vão alé1n de ter os processos ou templates
certos de gestão de projetos, programas e portfólios. "A i1nportância de govemança,
• Realizar atividades
de configuração
Criar estrutura
• Criar uma estrutura
de plano de
anafijica do projeto
trabaho
• Oefinir dependências
Estimar
durações
Estimar o plano • Estimar
de trabalho esforços
• Oesignar
recursos
, Confirmar que o cronograma

é alcançável com a
equipe disponível
Refinar o plano • Oocumentar dependências
de trabalho
externas
• Obter comprometimento
organizacional
Figura 15-41 Atividades necessárias para desenvolver um plano de trabalho.© Oeloitte & Touche
liderança e responsabilidade adequadas não pode ser subesti1nada", diz Martyniuk.

"Na minha experiência com implementação de gerenciamento de portfólios de proje-
tos, ter a estrutura certa para guiar as partes interessadas no projeto pela miríade de
decisões que precisam ser tomadas constantemente é um fator diferenciador crítico
ent re o sucesso e o fracasso de um projeto ."
A principal final idade da governança é especificar direitos de decisão, esclarecer
responsabi lidades e encorajar comportan1entos desejáveis. A governança envolve tra-
zer os ind ivíduos apropriados para a 1nesa de reunião para ter a conversa desejada
usando o processo relevante para to1nar as decisões preferidas dadas as inforn1ações
d isponíveis. As estruturas de governança representam estruturas e processos por n1eio
dos qua is se ton1an1 decisões, e elas define1n conjuntos de princípios e práticas para
.
gerenciar:
• Que decisões precisam ser tomadas
• Quem tem a autoridade e a responsabi lidade para tomar decisões e com que in-
formações e
• Como as decisões são implementadas, monitoradas, medidas e controladas
Como ilust ra a Figura 15-42, a governança eficiente exige um forte patrocínio

executivo, claros encarregados dos "negócios" e sólida consultoria técnica para faci li-
tar o cumprimento das regulamentações, padrões e diret rizes estabelecidas. Exige tam-
bém a lgum tipo de supervisão de benefícios e valores. Isso pode ser feito por meio de
um com itê de partes interessadas selecionadas que compreendam os aspectos qualitati-
vos do valor de um projeto. Mais importante, cada função da est rutura de governança
escolhida deve ser empoderada cotn a autoridade necessária para tomada de decisões
dent ro de sua área de responsabil idade.
Gerenciamento de mudanças organizacionais e de pessoal

Fina lmente, e ma is itnportante de tudo, as pessoas é que são os elementos cruciais
para se alcançar os objetivos do projeto e de t ransformaç.ã o. Elas também são a prin-
cipal causa dos resu ltados de transformações deixaretn a desejar. Um gerenciamento
integrado de mudanças organizacionais e de pessoa l, RH e serviços de aprendizagetn
devem ser oferecidos em todo o portfólio nos níveis dos programas e projetos para
estimular a consistência, o a linhamento e a entrega eficiente em todo o esforço geral
de transformação.
Como ilust ra a Figura 15-43, a Dimensão Pessoal de Transformações da Deloitte
é utna estrutura ampla que se alinha com a est ratégia de negócios e pode envolver
tudo, desde avaliaç.ã o de riscos e al inha ,nento da liderança a mudanças comportamen-
tais, co1nunicações, t reinamento, design organizacional, ent re out ros.
Utna das principa is causas de uma transformação não alcançar seus objetivos de-
sejados é a incapacidade de as partes interessadas verem e sentirem o motivo premente
para 1nudanças. Consequentemente, medo, raiva ou complacência podem se arraigar
e causar resistência. Em casos em que a mudança é ma is eficiente, os indivíduos têtn
Supervisão exerull'va
• Fornece direção estramJia
baseada em metas e prioridades
• f.Ornece orie-ntação. consultoria
eliderança de mudanças
• Aprova investimentos de projelõs
• Remove bat reiras identificadas
Direção cll? ll!l!)ÓCIOS Gerenciamento de portlóho Direção de soluçães

• Determina necessidade ou • Facilita a apresentação. priOrilaÇão • Revisa anecessidade ou a
opõrtunidade e ap,ovação de projetos oportunidade e recomenda
• Estabelece se o caso exige mudanças • Monitora acapacidade e competência a solução apropriada
• Fomeee liderança em processos • Facil:ita acriação de pontos de • Fornece Orientações quanto a
e sul)Me à implementação verificaçio de passaoem de rase privacidade.. ~urança. arquitetura,
• Acompanha resultados e mede a para revisa, o prog.resso e divuloar finanças, parte juridica. aquisições.
realitação dos btneficios esperados a obtenção de resultados RR relações ttabalhiS!as, ele.
, Enltega de ProgramasNroietos
• Gerenciamento de p,ogramas/proj8tos no dia adia, incluindo o gerenciame-nto
do orçamento, escopo, cronograma. recursos. partes interessadas equalidade
• Gerenciamento e/ou escalada de proble-mas.. riscos e solicitações de mudança
• Adoção de padrões estabelecidos ecumprimento de diretrizes determinadas
• Comunicações reg.ulares. induindo relatórios de s.tttus e de progresso
Figura 15-42 Estrutura de governança de portfólios de projetos da Deloitte © Deloitte &

Touche LLP e entidades afiliadas.
• A organização entende as mudanças Atividades

eestá pronta para abraçá-las ~ Liderança de mudanças
~ Organização/RH
Aprendizagem
• Ferramentas e treinamentos
são fornecidos aos
funcionários para aumentar
o conhecimento e a • As partes interessadas com
AprendiZagem e
aprendizagem em toda autoridade, poder e/ou
transferência de
a organização inttuêocia lideram e apoiam
capacidades ~ visivelmente a mudança
• Programas, processos e
ferramentas de Gestão • Os funcionários são bem
de Talentos integrados e Dimensão Pessoal inlormados sobre as
atinha.dos às estratégias de Transformaçães mudanças e se envolvem
de negócios e de talento, nelas
que estão sempre em
modificação • Oalinhamento das crenças
de indivíduos com os
• Transição suave para valores certos, gerando,
maximizar o beneficio assim, os comportamentos
potencial e manter a desejados
organização produtiva
ao longo da mesma
• Aorganização é realinhada para

otimizar recursos ea eficiência
dos funcionários
Figura 15-43 Estrutura de Dimensão Pessoal de Transformações da Deloitte. © Oeloitte & Touche
u1n senso de pa ixão. Pode-se criar situações convincentes, chamativas e drásticas para
ajudar as pessoas a visua lizarem problemas, soluções ou progresso ao tratar da com-
p lacência, falta de empoderamento ou outros problemas i1nportantes.
A transformação sustentada também exige um comprom isso profundo e pessoal
em todos os níveis da organ ização. Algumas partes interessadas podem ser cocriadoras
que ajudatn a dar fonna à visão e aos planos da transformação. Algumas serão intér-
pretes. Outras serão consumidoras da transformação. U1na transformação eficiente
exige cont ribuições e envolvimento de todos os tipos de participantes. O alinhamento
e o compromisso interno começam no topo - os líderes devem estar alinhados, dispos-
tos a vencer resistências e comprometidos co1n a liderança da transfonnação por meio
de seu exemplo.
Os projetos de t ransformação normalmente alteram estruturas, processos de t ra-
ba lho, siste1nas, relacionamentos, estilos de liderança e comporta1nentos que, juntos,
criam o que conhecemos co1no cu ltura organizacional. Criar a cultura que a organi-
zação quer - ou preservar aquela que já possui - pode exigir um programa del iberado
que se alinhe a outras atividades t ransformativas. Se1n um esforço consciente, é fácil
acabar deixando a organização presa entre novas maneiras de t raba lhar e antigos
modos de comportamento.
Para aumentar o investimento em novos modelos, tecnologias e processos de ne-
gócios, é essencial que haja um programa formal e del iberado de educação e desenvol-
vimento de habi lidades para as pessoas afetadas pela transformação. Contudo, educa-
ção e treinamento norma lmente não são priorizados nas t ransformações.
Maneiras selecionadas para abordar eficientemente o gerenciamento organizacio-

nal e de pessoal em projetos de transformação incluem:
• Con1preender a situação das partes interessadas. Compreender como a transforma-
ção pode afetar cada grupo de partes interessadas, a léin de indivíduos específicos.
• Prever riscos. Identificar áreas de resistência antes que elas surjam, juntamente
com possíveis problemas de negócios e riscos que possa aparecer.
• Avaliar a situação. Determinar se a 1nagnitude e o ritmo da mudança está energi-
zando ou paralisando a organização.
• Estabelecer prioridades. Priorizar atividades, atacando as barreiras críticas
pnme1ro.
• Influenciar os influenciadores: Identificar pessoas dentro de cada grupo de partes
interessadas que exigem respeito e envolvê-las como defensores da t ransformação.
• Esforçar-se por um compromisso autêntico: Compreender as circunstâncias e as-
pirações das pessoas - e então fazer um esforço coletivo para acomodá-las.
• Equipar líderes para dirigir a t ransformaç.ão: Equipar líderes com o conhecitnento
e as habil idades necessárias para ajudar seu pessoa l a passar por esse período de-
safiador e, 1nuitas vezes, traumático. Transformar os líderes em modelos do com-
portamento desejado.
• Reconhecer que pode haver vencedores e perdedores: O impacto da transformação
varia de um grupo de partes interessadas para o outro, e a lguns podem não ficar feli -
zes con1 o resultado. Con1preender, envolver e infonnar todas as partes interessadas.
• Focalizar-se nas coisas que realmente importam. Uma cultura eficiente é aquela
que cria um va lor de negócio sustentável, diferencia a organização de seus concor-
rentes, oferece suporte aos requisitos específicos da indústria e ajuda os clientes a
conseguir o que realmente querem.
• Ser consistente. As coisas que impulsionam o co1nportamento e a cultura devem
se alinhar umas às outras. O mau a linhamento simplesmente confunde as pessoas.
• Reforçar. Alinhar iniciativas relacionadas a pessoas - particularmente reco1npen-
sas e incentivos - para ajudar a pro1nover a nova cultura. Estabelecer modelos
eficientes de liderança e introduzir novas palavras e vocabulário que sublinhe o
comportamento desejado.
• Reter funcionários selecionados. Identificar funcionários co1n alto dese1npenho e
outros funcionários selecionados que sejam essenciais para os resultados futuros
da organização. Informe-os de que eles não correm riscos.
• Captar conhecimentos. Estabelecer processos e sistemas formais para transferir
e captar conhecin1entos organizacionais - particularmente para terceirizar trans-
formações.
• Ser genti l, n1as confiante. Os tomadores de decisões devem ser gentis, mas não de-
ven1 de1nonstrar dúvida de que decisões são necessárias, apropriadas e conclusivas.
Conclusão
A adoção e aplicação consistente de u1na padrão de gestão de projetos, programas e
portfólios, a lém da imple1nentação da govemança relevante co1n técnicas eficientes de
gerenciamento de mudanças organ izacionais e de pessoal, podem levar a organização
à realização de diversos benefícios, dent re os quais:
• Melhor tomada de decisões dos executivos - ma ior capacidade de detenninar que
projetos continuar/parar, com base em informações atualizadas sobre o status/
progresso de projetos.
• Transparência e responsabilização financeira - ma ior capacidade de gerenciar

subuti lizações do orçamento ou custos excedentes; e transferir fundos dent ro do
portfólio para 1nelhor gerenciar e responder a circunstâncias imprevistas e mudan-
ças nas prioridades.
• Melhor gerenciamento de capacidade de recursos - disponibilidade das informa-
ções necessárias para fazer um uso eficiente dos recursos d isponíveis; e capacidade
de t ransferir recursos dentro do portfólio para melhorar a uti lização de recursos
em todos os projetos.
• Gerencia1nento proativo de proble1nas e r iscos - capacidade de prever e responder
a desafios antes que eles cresça1n e se tornem problemas maiores; um mecanis1no
para levar a resolução de problemas selecionados ou solicitações de decisões/ações
de mitigação de riscos à atenção dos executivos.
• Padronização e consistência - comparar apenas projetos similares; 1naior quali-
dade e rapidez nas comunicações internas e externas com funcionários, cl ientes,
executivos e outras pa rtes interessadas.
• Maior colaboração e melhores resultados - melhor realização de benefícios por
meio do gerenciamento conjunto de in iciativas como um portfól io integrado;
cooperação e melhor remoção de obstáculos para se alcançar resultados.
Embora não sejam exaustivos, os tópicos abordados neste artigo descrevem a l-
guns fatores selecionados para alcançar os resu ltados desejados que, de acordo com
nossa experiência prática, podem guiar uma organização na direção "certa" enquanto
ela inicia seu caminho rumo à implementação de uma capacidade sustentada de geren-
ciamento de portfólios, a fim de produzir valor empresarial real e tangível.
7
15.5 COMAU
Na segunda edição de meu livro Strategic Planning for Proiect Management Using a
Proiect Management J\1aturity Model, afirmei que o caminho rumo à maturidade pode
ser acelerado com (1) a implementação de PMO logo no início do processo; (2) um
PMO que se reporte diretamente aos níveis executivos da empresa; e (3) ter um apoio
visível à gestão de projetos por parte dos executivos. As empresas que consegue1n rea-
lizar esses três itens parece1n superar o desempenho de seus concorrentes em relação à
gestão de projetos. Esse foi o caso da COMAU.
Histórico da COMAU
A COMAU é uma líder 1nundial em manufaturar sistemas flexíveis e automáticos e
e1n integrar produtos, processos e serviços que au1nentam a eficiência diminuindo, ao
mesmo tetnpo, os custos gerais. Com uma rede internacional que engloba 13 países, a
COMAU utiliza a ma is recente tecnologia para produzir sistemas turn-key avançados
e consistentemente exceder as expectativas de seus cl ientes. A COMAU é especializada
em soldage1n de carrocerias, usinagem e montage1n de cadeia cinemática, robótica e
manutenç.ã o, além de serviços ambientais para uma grande variedade de setores in-
dust riais. A contínua expansão e melhoria de sua variedade de produtos permite que
' €>2013 by COMAU. Reproduz.ido com permissão. Todos os direitos reservados. O material sobre a CO·
.MAU foi fornecido por Roberto Guida, vice-presidente de gerenciamento de contratos e projetos da CO·
NlAU, Angelo Putiri, gerente do PMO da CO~lAU, Claudio Samarocro, gerente de riscos da CONlAU e Paolo
Vasciminno, gerente da Academia de GP da COMAU.
a COMAU garanta assistência personalizada em todas as fases de um projeto - do de-

sign, à implementação e instalação, e ao início da produç.ã o e serviços de manutenção.
As competências cent rais da COMAU são: soldagem por pontos, soldage1n a laser e
soldagem por arco elétrico, vedação, perfuração e rebitage1n, usinagem, montage1n e
testes, monitoramento e controle, manuseio e logística, serviços de manutenção, con-
sultoria em eficiência energética e serviços de gestão de projetos.
Descrição do problema
Durante a década de 1980, a COMAU estava desfrutando de um sucesso significativo
e, sendo assim, reconheceu a oportunidade que poderia ter com aquisições. Na década
de 1990, ela começou a buscar uma est ratégia de aqu isições globais. Os problemas
com o gerencia1nento das e1npresas adqu ir idas logo se tornou aparente, pois cada
uma possuía um diferente nível de maturidade em termos de gestão de projetos, e não
havia padrões corporativos para gestão de projetos. Até alguns anos atrás, a gestão
de projetos na COMAU era tipicamente executada de maneira mu ito fragmentada.
Havia uma ausência genera lizada de cultura, metodologias, processos e diret rizes e1n
torno do processo de gestão de projetos. Em 2007, já havia uma necessidade urgente
de implementar uma abordagem eficiente e global. O objetivo era simples: integrar o
conhecimento sobre gestão de projetos em toda a e1npresa global a fim de dar à CO-
MAU uma forte vantage1n competitiva.
A Solução - "de um aglomerado a uma rede eficiente... "

E,n 2007, a COMAU decid iu reforçar a cultura de gestão de projetos estabelecendo
a função de gerenciamento corporativo de projetos e contratos. Assim como com a
maioria das empresas que compreende1n a importância da gestão de projetos e reco-
nhecem a necessidade da liderança executiva na área, a nova organizaç.ã o era liderada
por um vice-presidente de gerencia1nento de contratos e projetos.
As principais diretrizes da missão da organização incluíam:
1. Desenvolvimento organizacional da empresa e implementação de políticas
organizacionais globais relacionadas à gestão de projetos
2. Reforço da política de gestão de projetos corporativo e da est rutura do escri-
tório de gestão de projetos
3. Criação de uma Academia de Gestão de Projetos da COMAU - o desenvol-
vimento contínuo de conhecimento de competências tanto técnicas quanto
. .
1nterpessoa1s
A COMAU corretamente reconheceu a importância do PMO em alcançar essa
missão. Ao contrário de empresas menos maduras, a COMAU se via como provedora
de soluções, cuja ,neta era satisfazer as necessidades de negócios de seus cl ientes glo-
bais. O escritório de gerenciamento de cont ratos e projetos era, portanto, considerado
como um provedor de soluções de negócios interno.
A COMAU abordava as três principais diretrizes da seguinte maneira:
• Desenvolvitnento da empresa e i,npletnentação das políticas organizacionais.
Durante 2007, uma política global de gestão de projetos foi desenvolvida, junta-
mente con1 un1 programa de treinamento intensivo baseado no Guia PJ\1BOK®.
Estabeleceran1-se benchmarks para a gestão de projetos para n1edir o nível de ma-
turidade da en1presa e criou-se um plano de ação para n1elhorar continuan1ente
o processo de maturidade. A política globa l, que seria aplicada a toda a empresa

globa l COMAU, era un1a política de gestão de projetos que descrevia as tarefas
que todas as equipes de projeto têm de gerenciar. A política estava diretamente
ligada às melhores práticas do Guia PMBOK® do PMI. Deve-se observar que a
empresa decid iu integrar o gerenciamento de contratos e a gestão de projetos em
un1a ún ica unidade. A COMAU estava convencida de que essa era uma impor-
tante inovação e de que ela p roduziria resultados positivos pa ra a empresa como
un1 todo.
• Reforço da política corporativa e gestão de projetos e da estrutura do PMO. Hoje,
o portfólio do PMO da COMAU consiste em um grupo co1n receitas 1nultim i-
lionárias que cobre projetos globais de veículos automotivos comercia is, energia
renovável e projetos aeroespaciais real izados em ma is de 30 países. O escritório
de gestão de projetos da COMAU, como parte do escritório de gerenciamento de
cont ratos e projetos, coordena os esforços de cada um dos PMOs regionais : PMO
América do Norte, PMO A1nérica do Sul, PMO Europa e PMO Ásia. A organiza-
ção global COMAU é apresentada na Figura 15-44.
• A equipe de gestão de projetos, especial istas internaciona is em gestão de proje-
tos, programas e portfólios, é incluída como parte da famíl ia de gestão de proje-
tos e é co1nposta por gerentes de projetos, gerentes de progra1nas, planejadore.s
e membros de equipes. As missões do PMO da COMAU são apresentadas na
Figura 15-43.
• Criação da Academia de Gestão de Projetos da COMAU. En1 2007, estabele-
cemos un1a entidade o rganizacional específica con1 o objetivo de desenvolver a
cultura e as competências em gestão de projetos: a COMAU PM Fan1ily, que é
a comunidade de p rofissiona is de gestão de projetos da COMAU. Con1preende-
n1os tan1bém que seria eficiente ter uma estrutura com a responsabilidade espe-
cífica de aprimorar essa con1unidade. Assin1, foi lançada a Academia de Gestão
de Projecos.
u ttãloa i. a lt
u França i. a 9
•G
...
Alemanha
Reino Unido
Polônia i.
•a
..
u Romênia
Rússia
i.
e
I!)
•-
EUA
México
Brasil
i.
i.
i.
"
Argenbna
~
i.
•o China
i. v
Índia
i. a
la OPERAÇÕES INDUSTRIAIS • ENGENHARIA
'( CENTRO DE INOVAÇÕES
Figura 15-44 COMAU em todo o mundo. Reproduzido por cortesia da Comau.

Desde o início, os objetivos da Academia de GP foram:

• Difundir conhecimentos sobre e a cultura da gestão de projetos em toda a
empresa
• Ana lisar as necessidades de treinamento das Unidades de Negócios da COMAU
• Criar atividades de treinamento específicas para nossos profissiona is em gestão
de projetos
• O rgan izar iniciativas (co,úerências, workshops, etc.) para estimu lar a dissemina-
ção de know-how sobre gestão de projetos
Para apoiar a missão da COMAU, o PMO primeiro preparou um roteiro de alto
nível para 2007- 2009 que incluía o seguinte:
• 2007:
• Realizar benchtnarking e determinar a linha de base da maturidade
• Definir o conceito do PMO
• Desenvolver políticas operacionais para a gestão de projetos
• Desenvolver programas de treinamento em gestão de projetos
• 2008:
• Estabelecer um PMO corporativo
• Estabelecer PMOs regionais
• ltnplementar ações inovadoras de acordo com a avaliação de maturidade
• Estabelecer a Academia de Gestão de Projetos co1no representante do PMI
• 2009:
• Gerencia r as atividades etn andamento de projetos, progra tnas e portfólios de
proJetos
• Realizar benchtnarking externo sobre a 1naturidade em gestão de projetos
• Expandir as atividades da Academia de Gestão de Projetos
• Gerenciar projetos estratégicos e projetos especiais selecionados
Gerenciar os portfólios de projetos da COMAU

globalmente; fechar as lacunas entre estratégia
e ações e permijir o fluxo de experiências
entre diferentes países e negócios
Providenciar especialistas
Harmonizar procedimentos em contratos e riscos
durante a fase de execução
(adoção das diretrizes do PMI)
Missão do do projeto
e ferramentas de gestão de
projetos em todo o mundo PMO da
COMAU
Gerenciar a Academ ia PM Fam ily

de GP da COMAU
(Centro Registrado Gerenciar projetos multinacionais com
de Treinamento PMI) o empoderamento e a visibilidade certos
Figura 15-45 Missões do PMO da COMAU. Reproduzido por cortesia da Comau.

Como afirmado anteriormente, a COMAU via o PMO como o mecanismo prin-

cipal para prover soluções de negócios internas. Alguns do benefícios alcançados pela
COMAU incluíam:
1. O reconhecimento do cliente como o integrador nú1nero 1 de trabal hos com-
plexos, dessa forma, agregando valor à cadeia de va lor/supri1nentos.
2. Desenvolvimento de uma cu ltura e u1na abordagem de gestão de projetos de
alto padrão e de e.lasse internaciona l.
3. Melhor suporte para a equipe de vendas, resultando em maior sucesso para
os projetos, por meio de um planejamento de projetos proativos e de estraté-
gias de redução de r iscos.
4. Desenvolviinento de uma cultura capaz de sincroniza r a linguage1n com os
c.l ientes da COMAU, reduzindo ma l-entend idos nas defin ições e execuções
de projetos e oferecendo suporte a comunicações baseadas em confiança em
todos os projetos.
5. Desenvolviinento de uma das 1nelhores técn icas de otimização da carga de
trabalho capaz de reduzir os custos para seus clientes.
6. Desenvolvimento de un1a linguagem técnica con1partilhada ao trabalhar en1
prol da padronização de u1na abordagen1 global, p.ex.: a WBS Po,vertrain
Itá lia e França. Isso permite que a COMAU troque partes entre produtos e
equipes de projetos en1 diferentes países, alcançando, assi1n, n1elhor planeja-
n1ento, execução, controle de custos, planejamento de carga de trabalho, alén1
de gestão de riscos, comunicações e qua lidade 1na is equilibrados.
7. Identificação e gerenciamento de situações "fora do escopo do projeto" , o que
resulta em 1na iores benefícios para os clientes, a COMAU e os provedores.
8. Otimização de processos e sistemas de geração de relatórios, o que reduz o
tempo desperdiçado e cria mais tempo para gerenciar problemas críticos.
9. Contribu ição com a integração em toda a empresa do t raba lho e seus proces-
sos, compartilhando informações, visões e estr atégias, inclu indo o início de
projetos estratégicos.
10. Criação de u1na forte equipe de gerentes e técnicos altamente qua lificados,
capazes de oferecer suporte a projetos difíceis e e1n situações de a lta pressão.
O PMO da COMAU está gerenciando ativamente o Portfólio G lobal de Projetos,
reportando-se ao CEO e trabalhando para alcançar o máximo grau de alinhamento
ent re a gestão de projetos e a est ratégia de negócios, como 1nost ra a Figura 15-46.
·•·,----------
•••
••
••
••
••
•' i ! • !• •• •
.. ri.. ' '
% Concluído
Figura 15-46 Gerenciamento de portfólios da Comau. Reproduzido por cortesia da Comau.

A equ ipe do PMO se tornou o agente da mudança dent ro de cada uma das uni-
dades de negócios organizacionais da COMAU. O resultado tem sido várias soluções
de "resultado imediato". A COMAU te1n sido capaz de obter ma ior controle de seus
custos indiretos, oferecendo, ao 1nesmo tempo, oportun idades de va lor agregado tanto
para a empresa quanto para sua base de cl ientes global. Todos os gerentes hoje de-
lega1n 1nais autoridade do que no passado, e os vice-presidentes e gerentes regionais
estão funcionando co1no fortes patrocinadores.
U1n segundo roteiro de alto nível foi desenvolvido para 2010- 2013, incluindo os
seguintes objetivos:
• 2010:
• Desenvolver em nível mundial o conceito de Gerenciamento de Contratos
• Aumentar o gerenciamento de portfólios
• Desenvolver os progra1nas de treinamento em gestão de projetos para cl ientes
externos
• 2011:
• Desenvolver o conceito de Gestão de Riscos em nível mundial
• Desenvolver regras e metodologias de Gerenciamento G loba l de Porúól ios
• 2012:
• Desenvolver processos de Gerenciamento G loba l de Projetos
• Desenvolver programas de treinamento em Gestão de Riscos
Seguindo o roteiro, o Gerenciamento de Contratos e Projetos modificou sua estru-
tura a fi,n de alcançar u1na configuraç.ã o baseada no compartilhamento coordenado
de atividades entre o escritório de gestão de projetos, o gerenciamento de contratos,
o escri tório de gestão de riscos e a acade1nia de GP, além de em uma escala geográfica
pelos PMOs locais e o Gerenciamento de Cont ratos . Os PMOs regionais se reporta1n
para o PMO Corpo rativo e também aos gerentes regionais. Esses gerentes regionais
de1nonstr ara1n um sincero desejo de funcionar como patrocinadores de nível executivo
e fazem a evolução do PMO acontecer.
Do ponto de vista geográfico, a presente estrutura global do escritório de geren-
ciamento de contratos e projetos é descrita na Figura 15-47.
O primeiro processo de gestão de projetos global da COMAU

U1n a lto grau de fragmentação no nível internacional junta1nente com problemas de
sustentabi lidade de negócios levaram a COMAU a pensar na gestão de projetos como
uma ferramenta de integração. Consequentemente, uma linguagem e ferramentas co-
muns foram desenvolvidas e disseminadas pela organização.
Hoje, a a lta concorrência de projetos multinacionais (p.ex.: um cliente global faz
um _pedido à COMAU lnc. de uma linha auto1natizada a ser instalada em uma fábrica
na lndia. A COMAU lnc. desenvolve a engenha ria da fábrica enquanto a COMAU
C hina rea liza a manufatura e a COMAU Índia gerencia a instalação) e a criação das
Unidades de Negócios Globais levou a u1n grau muito ma is alto de integração, forçan-
do a COMAU a dar um passo à frente.
Portanto, tomou-se necessário revisa r os processos de gestão de projetos co1n o
objetivo de harmonizar nossa maneira de t rabalhar e gerenciar projetos em toda a or-
ganização. Nesse sentido, o Departamento de Qualidade e os Escritórios de Gerencia-
mento de Contratos e Projetos patrocinara1n conjuntamente uma iniciativa para pro-
duzir uma revisão global dos processos de gestão de projetos (ver Figura 15-48), que
foi rea lizada por equipes mu ltifunciona is e multinacionais, coordenadas pelo PMO
corporativo.
Gerenciamenlo de
conlratos e projetos
Gestão da
Academia de GP
Escrttôno de Gestão
gestão de protelas de riscos
fo Gerenciamento de
PMO Itália.
PMO AJemanha,
França e
!s contratos Europa Polônia e Romênia
w _Re,oo Unido_
~ Organização de
~
Gerenciamento de PMO PMO
gestão de
"'z contratos NAFTA EUA Méx.oo
projetos
(BUs/Países)
Gerenciamento PMO SIStemas

de contratos Brasil
PMO Serviços
s
:É
Sistemas
Aménca Latina
PMO Sistemas
Argentina
Aménca Latina
"' •
-
u 1
"'... PMO
Gerenciamento de
t... contratos China China
PMO Índia
"'
Figura 15-47 Presença geográfica do Escritório de Contratos e GP. Reproduzido por cortesia da
Comau.
Baseamos a criaç.ã o e o desenvolvimento do Gerenciamento Global de Projetos

nas seguintes fontes (ver Figura 15-49):
• Processos locais de Gestão de Projetos em uso nas d iferentes fi liais da COMAU
• Lições aprendidas da COMAU
• Modelo do PMf'
• Política G loba l de Execução da COMAU
A fim de garantir a criação de um verdadeiro processo global, usamos o paradig-
ma exibido na Figura 15- 50.
A Pirâ tn ide do Parad igma possui "Políticas" no topo (no nível do Setor), o que
inspira o desenvolvi tnento de Procedimentos/Processos Globais, "Inst ruções Opera-
ciona is" (em nível Global) e a aplicação de "Procedimentos/ Instruções Operacionais
Locais" no nível do Pa ís.
Abordagem para a gestão de riscos da Comau

Em 2006, a COMAU começou a trata r a Gestão de Riscos cotn uma abordagem mais
focalizada e estr atégica, reconhecendo-o como u1na pa rte essencial da conclusão bem-
-suced ida de projetos. Um aspecto de Gestão de Riscos foi incluído na Política de
Gestão de Projetos, introduzindo, dessa forma, as regras gera is para o planejamento,
ava liação, manuseio e monitoramento de fatores variáveis de modo a ga rantir resul-
tados favoráveis.
A crescente complexidade e internacionalidade organizacional do gerenciamen-
to de pedidos tornou necessário encont rar ferra tnentas mais est ruturadas e refinadas
P10 - OESTÃO OE PROJETOS
GC _ GC80
Adjudicação do con1ra10 Acellação de linallzaçlo
T T
r.t1000
Translerfncla
CIO Oep. de
r.11010
Aeunllo Inaugural
r.t1020
Aprovação da
llnha de base
r.11030
Reunião da
r.11040
Reunião de
r.t1050 r.11080 r.11070
Rela'6rlo de statu, Pe~lsa de Sollcilaçlo
equipe de GP revido de projetos do projeto ao eIlente saUstaÇIO de 1'1allz-aç80
r.t1080
Translerfncia
para o Oep. de
r.t1090
Reoollo de
encerramento
..o
-o~-
dO pr~e~ "C
Vendas do pro jelo {periódica) (.periódica) (.periódico) do cliente Pôs•Vendas do proj elo
• P10.1 r<ICIAl~AÇÃO
• P10.2 PlAl<EJAMIJ<TO
• • • • • • • • P10.3 EXECUÇÃO P10.5 IJ<CERRAl,tfOTO
~
UI
m
1'§
(D
(D>
~
fll'
(D
3
(O
(D
Ih
íi>o
o
a.
(D
"C
MONTORAMENTO E CONTROLE a·
m
g
(O
Figura 15-48 Processo de gerenciamento global de projetos da COMAU. Reproduzido por cortesia da Comau.
..
o
O'
CJ)
O>
u,
8l
___
PIIOJECT • PEOPlE
,....
IIINIOOIElll
-
(l\b
CJ)
Melhores 11dllcas
-·- G)
......... da Comau (1)

!!l
""e.
/
de Ces.110 oe o
ProjelOs locais
(1)
"O
.. 10 1 lillCV\ÇÃO 10 2 PlA"EJAMEIITO 103 EXECUÇÃO 1ü "MOllfTORAMalTO

- 1O.5 EIICERRAMEIITO
.2.
(1)
g
E COIITAOLE
[ I0.1.1 °"'""""T""'°) [102.1

de Aberiura <IO Projelo
D-.......ol'lono> 1
de Ges.tão de Ptqe1os
103.1Origireo,,_,
Exeouçkldo Ptqelo
>1 10.4.1
Conroa. o f'$QO(IO
º> conua?90eote
1 10~.IEnoerr;;;;>
aqu
1 ~0 1.2 1.lom.,,eq,i~':) r 022Co""''""'~ 1
=>
1 1032R-aGaramo ) 10.• 2 ) 1 10$2 )
tfencramento do projelit t<letlnlr esoo~ <li OulliCIMlt ComrCQf occonogt\Vfll &lot<tat o or(fllo
[ 10.1.31dentJ!icarM~es) [ l0. 2.30eserwot.-eci ± . ) ~ .30esetivdvefe(lef...ciar ) [ 10.4.3 -
L
.......
lntetes:saclas
[ 10.2.40esMYCMf
a EillllOtde Pro;etos
= > 103.40ilsU,1:,u1r~10,l'NIQ(,e$eoerencw
cronogf#Rill . ast)qleotalt.'IS<las panes ~leressacLIS
[
CM toIM' osouS10s
10.4.4 J
Mon~rar e oomrotair os (1$()(1$
[ 102.5 fs1SNll'OUS10st )
delen'IW'llr orçatnlf'IIO
L 103..5 Realar COOn1açilie$
eaquisiÇ(ies
) ~ 10.4.5 ~
Rflllzar o coorc. de mudM'iças h1!9rad0
10 2.61C1M1tiçar, .-ar e [ . 10.• 6 )
pta,i res(los.ta utsoos Vtmicaf oesc:«10
102'7 °"'"" ..... 1 10.4.7
- ---- __---- ~ >

de base de pro,e1os Aealzar o Contrcte de Oualdade
1 10.4.8
Re(IOIW ~edlo
e
.....
._...,..
l!O
<rCM•a10seaq~es
1 f0:.C9 )
---~
-~.~ J
::,
·-
·- -- ---
-·-------
.-----
-- --·.
·--
-
·------ ~ - -.-... '
Pol!IICI GIOtlll pn
hecuçto de ProJelos
~)~
G5
~- -, ~
__ ,.::ç;z~
m~~•
,....-..,111,.. 1..,... ~~
'"-,j((t ,...
Figura 15-49 Fontes dos processos de gestão de projetos.

.. Política Global
de Gestão de
Projetos da COMAU
Processos Globais
de Gestão
11M@M de Projetos
Figura 15-50 Paradigma de processos de gestão de projetos.
para gerenciar incertezas. Consequentemente, e1n 2010, criamos, como parte do Ge-
renciamento de Cont ratos e Projetos, um escritório de gestão de riscos, cujo propó-
sito é lidar melhor com o ambiente de negócios internaciona l e o maior tamanho e
complexidade dos projetos, além de fornecer suporte e governança interna a todos
os projetos/programas em andamento nas diferentes unidades de negócios e nos di -
ferentes países. Sua tarefa é aprimorar as capacidades de ge.stão de r iscos e reunir as
experiências aprendidas durante a execução dos projetos da COMAU.
Supondo que uma gestão de riscos eficiente deva ser proa tiva, é fundamental iden-
tificar problemas que possam potencialmente afetar um projeto e traba lhar para di-
minuir suas consequências e1n vez de simplesmente reagir quando surgem proble1nas.
Como ta l, as responsabi lidades específicas do escritório de gestão de riscos pode1n
incluir:
• Definir as regras da Gestão de Riscos corporativa;
• Aprimorar a abordagem da Gestão de Riscos em todo o ciclo de vida do projeto;
• Realizar Aval iações de Risco de Projetos (verificar a "saúde" do projeto);
• Oferecer suporte à BU/Centro de Lucros para a Gestão de Riscos na fase de lici-
tação
• Oferecer suporte à BU/Centro de Lucros para a Gestão de Riscos no nível do
portfólio
Em 2011, depois da necessidade de hannon izar a abordagem de gestão de riscos
em toda a organização mundialmente, criou-se e disse1n inou-se uma ferramenta co-
mum de Registro de Riscos (ver Figura 15- 51) dentro de toda a organização. Após u1n
período de treinamento e refinamento, as ferramentas foram incluídas do conjunto de
ferramentas de gestão de projetos da COMAU e incluídas no livro: Project and People
Management - An Operational Gttide, publicado em março de 2013.
A partir de meados de 2012, como parte da oportunidade de definir o novo pro-
cesso de Gestão Global de Projetos, estabeleceram-se processos e regras de Gestão
de Riscos també1n incluídos nos processos-padrão da COMAU. Nesse ambiente, os
Escritórios de Gestão de Riscos agem como provedores de t reina1nento e dicas para
8l
O)
G)
(1)
!!l
""oe.
CCJIVIAU
~
ATUALIZAR PARA PPR 1

Resumo do registro de riscos
GRF·PM0-150 rev24
1 OCULTAR FECHADO 1
1MOSTRAR FECHADO 1
(®
C OMA U
(1)
"O
.2.
(1)
g
Ameaças e oportunidades
EUR Atualizado em "#Jxxl'fY
1.
Dispositivo de leitura/escrita colocado

•••• _1_!~?'."'.ª.~e."!e. ~! !~t!i!! ~! ~l_e!".s•••••••••••• ~- •••• _1,~_1qq •• •~i!':'! '!'.IÍIJ!'•••••••• • fl~_E[IA.0.0. ~IIY!'••••••••••• t ........ :... _I_D_E_N_TJ~IÇ{IP!'••2Jl~~-?9'!~ .
Atividades de remodelagem durante o fim de
2 S<lmana, causando fechamento na segunda-feira € 4.00.000 Risco médio MITIGAÇÃO € 61.440 ANALISADA 30-09-2002
SOidagem com C02 exige mais peças para
.... 3 chegar à qualidade solicitada................ € ••••• 45.000 .. _Risco médio .. . . .... MITIGAÇÃO ............... €_ •••••• 1.000.. _ID.ENTIFICADA_ 30-01-2002.
NAO
REALIZADA -
4 Aumento dos custos do timerde soldagem € - f11chado € - FECHADA 30-04·2012
.... 5 RealocaçAo da linha XY ................... € •••• 1.40.000 .. Risco médio .. . . .... MITIGÃÇAO ............... €•••••••• • -•••• ANALISADA .. 10-03-2012.
~f~~~;~.Jt~:;~~;r~~~~~
: : : : ~: '.~:~~::::: ~:::::: :~~~~: :rRisco médio
.... !. ~-u~~~J. '!". er~S;S~.<!>.l[n_h~.>\V. ri[•! ~_.qqq . .IRisco alto
_B_ ...... ~- ......
rA~~;~;çA~~~I~~::::::::::: ~:::::::: ::.:::: ~~~I; :~:::
t~II[~A~O, ••••••••••••••• t ........ :............... -~~l!-?9!~.
:~~~-~~;~ :
Custo por hOra do aumentoda manufatura
8 em pais de baixo custo € 1.20.000 lRiscoalto )MITIGAÇÃO € 23.000 IDENTIFICADA 10-03-2012
Total de ameaças
Total de ameaças € 927.400 altas/médias € 9.27 .400
Figura 15~1 Registro de Riscos da COMAU.

apoiar as equipes durante a iniciação das atividades de gestão de r iscos dos projetos
relevantes.
Abordagem para o gerenciamento de contratos da COMAU

A COMAU estabeleceu o requisito de ter o suporte de um gerente de contratos para
a equipe de programas/projetos que surgiu claramente quando o PMO foi lançado
origina lmente a fi 1n de oferecer à equipe um "ponto de vista" adicional não somente
focalizado e1n aspectos técnicos ou gerenciais.
A gestão de projetos ta 1nbém é auxiliada pelo gerenciamento de cont ratos, o que
aumenta tanto a satisfação do cliente quanto o desempenho do fornecedor por meio
do design de acordos de contratos claros e bem equilibrados. O objetivo é garan-
tir uma execução de projetos eficiente focal izando-se em objetivos comuns esperados
para os projetos e util izando negociações competentes e justas.
Os especialistas e1n gerenciamento de contratos, localizados nas principais áreas
geográficas de nossos negócios, combinam competências jurídicas e de gestão de pro-
jetos e serve1n de suporte aos gerentes de vendas e de projetos, além de às equipes
jurídica e financeira . Competentes em leis e regulamentações locais específicas, eles
trabalham com todas as un idades de negócios da COMAU em todo o inundo du rante
as fases de licitação, execução e encerramento.
A finalidade da atividade cent ral de gerenciamento de contratos é garantir que o
projeto seja realizado conforme solicitado pelo cliente, e suportado pelos fornecedores
de acordo co1n os acordos de contr ato conjunto.
As principais atividades de gerenciamento de contratos são:
• Compreensão de contratos
• Completude de cont ratos
• Correspondência de contratos
• Modificação de contratos
• Disputas e reclamações
• Encerramento de contrato
• Lições a prendidas
Academia de gestão de projetos da COMAU

O primeiro desafio co1n que a Academia de GP teve que lidar foi sua natureza interna-
cional: ela precisava oferecer um serviço útil para as empresas da COMAU em todos
os países. Para alcançar colegas de todo o mundo, deciditnos criar u1na rede de troca
de con hecimentos que seria enriquecida com suas contri buições. Na verdade, a Aca-
demia promove o envolvimento direto dos Especial istas em GP da COMAU para que
eles compartilhem conhecimentos e experiências. As pessoas que rea lizam ta refas coti-
dianas de gestão de projetos têm a melhor perspectiva em relação a como desenvolver
uma gestão de projetos eficiente. Esse foi o segundo desafio: a Academia de GP deve
ser um cent ro de cooperação. A equipe de ensino é formada por gerentes de projetos
qua lificados que min istram treina1nentos e oferecem suporte aos profissionais de ges-
tão de projetos. Em out ras palavras, a Academia de GP da COMAU é "aberta": todos
da empresa podem idealmente participar dela (é apenas u1na questão de habilidades e
interesse). O objetivo dessa abordage1n é alcançar o crescimento mútuo: o indivíduo
envolvido expande suas habilidades e seus conheci1nentos; a Academia de GP recebe
um constante supritnento de novo "sangue vital".
Para as pessoas envolvidas nela, a Academ ia de GP oferece a oportun idade de
"reinterpretar" sua própria experiência profissiona l, permitindo que eles amadureça1n
utn conhecimento mais forte dos principais pontos a seretn considerados ao gerenciar
projetos cotnplexos. A Acadetnia ta tnbém é u1na "academia de ginástica" para algu-
mas das competências que normalmente são chamadas de "habilidades interpessoais",
como gerenciar relacionamentos interpessoais, reun iões e apresentações, ou a habil i-
dade de dar e receber feedback e empatia. Hoje, a Academia de Gestão de Projetos da
COMAU oferece treina tnento em diversos tópicos:
• Cursos sobre a essência da gestão de projetos (para profissionais que não têm
responsabilidade direta pela gestão de projetos)
• Cursos sobre os funda tnentos da gestão de projetos (para líderes de equipes e ge-
rentes de projeto júnior)
• Cursos especial izados (para gerentes de projetos experientes)
• Atividades de cooperação direta para o suporte a projetos e à PM Family (seminá-
rios, workshops, orientaç.ã o, mentoria, ideias)
A Academia de GP e a Certificação de PMP"'

Como a COMAU decidiu adaptar seus próprios processos de gestão de projetos aos
padrões e recomendações do PMI"', as atividades da Academia de GP estão em con-
formidade com o PMI"' também. Então, foi u1na progressão natural para nós nos can-
d idatarmos a ser um Cent ro Registrado de Treinamento (CRT). A Academia de GP é
utn CRT desde 2008.
Graças a esse reconhecimento, nossa Academia pode fornecer treinamentos va lio-
sos como suporte para que os gerentes de projetos possa tn obter sua certificação de
PMP"'. Consequentemente, a Academia precisou enfrentar um outro desafio: oferecer
t reinamento não somente aos funcionários da COMAU, mas também aos clientes.
Hoje, nossas atividades educaciona is são apreciadas e solicitadas porque são o resulta-
do de um misto de conteúdo qualificado, boa metodologia e a experiência profissional
concreta de nossos instrutores (profissionais va lidados de gestão de projetos).
Algumas lições aprendidas

O verdadeiro sucesso de um projeto é 1nedido não somente cotn base na lucratividade,
mas também em conhecimento que pode beneficiar toda a corporação. A COMAU
escreveu uma lista de lições aprendidas reunidas durante seus projetos internaciona is.
• A habil idade de compartilhar melhores práticas e padrões organizacionais é ain-
da ma is importante ao trabalhar globa lmente. Permite a troca de infonnações, o
comparti lha ,nento da carga de trabalho, o nivelamento de recursos, etc.
• A participação das pessoas é crucial. É difíci l fazer as pessoas compreenderem os
futuros benefícios de se gerenciar um projeto e a importância de sua efetiva par-
ticipação porque ela está relacionada ao conhecimento, experiências e etnpodera-
mento pessoal. A habilidade de conseguir fazer as pessoas participaretn é crucial
para a mudança, a velocidade e a adesão.
• O desenvolvitnento de "resultados imed iatos" é um estímulo itnportante.
• Fazer as pessoas se sentirem confiantes a respeito do futuro é utn estímulo à ade-
são. Hoje, a importância da gestão de projetos como uma solução de negócios
para uma empresa global é um forte estítnulo para a PM Fa tnily.
• Maior eficiência nas comunicações, transparência e no uso da filosofia de "portas
abertas" são fortes estímulos.
• Desenvolver a abordagem de Gestão de Projetos e Programas é itnportante, mas
não suficiente; toda a empresa precisa compreender o modelo de negócio de ge-
. .
renctamento por proJetos.
• Educação em liderança eficiente é uma questão chave no dia a d ia.
A abordagem da gestão de projetos de1nonstrou que outros grupos funcionais

têm de ser iguahnente receptivos à aceitação da gestão de projetos para, dessa forma,
reduzir barreiras e criar melhores produtos.
Na segunda edição de meu texto, Strategic Planning for Project Management
Using a Project Management Maturity lvfodel, afirmei que o caminho rumo à ma-
turidade pode ser acelerado com (1) a implementação de um PMO logo no início do
processo; (2 ) u1n PMO que se reporte direta 1nente aos níveis executivos da empresa; e
(3) ter um apoio visível à gestão de projetos por parte dos executivos. As empresas que
consegue1n realizar esses três itens parecem superar o desempenho de seus concorren-
tes e1n relação à gestão de projetos. Esse foi o caso da COMAU.
15.6 Fluor Corporation: gerenciamento de

conhecimentos para a execução de projetosª
Gerenciamento de conhecimentos para execução

de projetos na Fluor
Histórico da Fluor Corporation
A Fluor Corporation é uma das ma iores empresas de capital aberto de engenharia,
aqu isições, construção, manutenção e gestão de projetos. Ao longo do último século, a
Fluor, por meio de suas subsid iárias operaciona is, tornou-se uma confiável líder global
por prover serviços e conhecimentos técnicos excepciona is.
Consistentemente classificada como uma das empreiteiras ma is seguras do mun-
do, o principal objetivo da Fluor é desenvolver, executar e manter projetos dentro do
cronograma e do orça1nento, e com excelência. A Fluor é uma empresa da Fortune 500
e é classificada Nº 1 na categoria "Engenharia, Construç.ã o" das maiores corporações
da América do Norte. Alé1n d isso, a Fluor é Nº 1 na lista da revista ENR (Engineering
News-Record) das 100 Melhores E1npresas de Projeto-Const rução e Nº 2 em sua lista
das 400 Melhores E1npreiteiras. Para os clientes da Fluor, esse reconhecimento enfatiza
a capacidade da empresa de executar com sucesso projetos grandes e financeiramente
complexos em todo o mundo.
A receita da Fluor em 2012 totalizou um recorde de US$27,6 bilhões, 18'% a
mais do que no ano anterior. Novos pagamentos representavam US$27,1 bilhões, e o
backlog da e1npresa no fim do ano era de US$38,2 bilhões. Por meio de sua compe-
tência individual e coletiva, a força de t rabalho global da Fluor, com ma is de 43 mil
funcionários, oferece soluções rápidas, custo-efetivas e inteligentes.
A Fluor mantém uma rede de escritórios em 1na is de 25 países em seis continentes.
Essa força de traba lho oferece à Fluor a capacidade de executar diversos escopos de
trabalho em projetos, grandes ou pequenos, e a flexibil idade de designar funcionários
a projetos de acordo com a necessidade.
A Fluor atende clientes em uma ampla variedade de indústrias, inclusive óleo e
gás, produtos químicos e petroquímicos, empresas comerciais e institucionais, serviços
governamentais, ciências da vida, manufatura, m icroeletrõn ica, 1nineração, energia,
teleco1nunicações e transporte.
A Fluor é alinhada em cinco principais segmentos operaciona is : Energia e Pro-
dutos Quín1icos, Indústria e Infraest rut ura, Governo, Serviços Globais e Cadeia de
1
©2013 by Fluor Corporarion. Reproduz.ido com permissão. Todos os direitos reservados. Esta seção foi
fornecida por John McQuary, vice-presidente, Jeff Hescer, analista de negócios e Tara Keithley, diretora de
comunicações.
Suprimentos Global. Os projetos da Fluor incluen1 o design e construção de ins-

ta lações de manufatura, refina rias, instalações fa rn1acêuticas, usinas de energia e
infraestruturas de telecomunicações e transporte. Muitos dos projetos da Fluor são
os maiores, mais remotos, mais con1plexos e mais desafiadores p rojetos de capital
do n1undo.
Comunidades de conhecimento em suporte à gestão de projetos global

O ambiente de negócios da Fluor é globa l, móvel, cíclico e colaborativo. Os funcioná-
rios são localizados em todo o mundo e precisam tr aba lhar de perto uns dos outros
para UJna execução distri buída de projetos, na qual diversos escritórios ao redor do
mundo t rabalham no mesmo projeto concorrente1nente. A escassez e mobilidade da
força de tr abal ho é uma realidade na Fluor, e o acesso a especialistas de qua lquer
pa rte do mundo é crucial para seu ambiente de negócios. Além diso, devido ao enve-
lhecimento da força de tra balho da organização, a retenção de conhecimentos é uma
questão cada vez 1nais importante.
Por meio de nossa capacidade de gerenciamento do con hecimento, a Fluor integra
e tira proveito do capita l intelectual coletivo de nossos funcionários para a excelência
na execução de projetos. Nossa vasta base de conhecimentos, chamada de Kno,vledge
OnLineSM, permite que funcionários em escritórios de todo o mundo tenham acesso
ao nosso conhecimento corporativo e cont ribuam com seu próprio conheci1nento e
competência. Esse sistema promove a colaboração e fornece uma forma sistemática de
captar, compartilha r e reutilizar o conhecimento da empresa. Para oferecer suporte à
execução de projetos global, a Fluor se organiza em torno de comunidades de conhe-
cimento, e sua platafo rma de tecnologia Knowledge Onl ine permite a distribuição
de t rabalho sem que as pessoas tenham de se movimentar de um lugar a outr o. A
p lataforma de tecnologia de gerenciamento do conhecimento da Fluor é posicionada
como o mecanismo de entrega para todas as práticas e procedimentos, material de trei-
na1nento, colaboração e localização de co1npetências. A direção estratégica geral para
retenç.ã o, compartilhamento e colaboração de con hecimento está intimamente ligada
ao a 1nbiente de negócios da Fluor.
Na Fluor, definimos gerencia1nento de conheciinento como a maneira de a organi-
zação identificar, criar, captar, adquirir, compartilhar e tirar proveito do conhecimento
- t rata-se de uma cultura e um processo de gerenciamento, e não de um produto ou
si1nples1nente u1na instalação de TI. As comunidades de con hecimento são redes de
pessoas designadas que compartilham, colaboram e aprendem umas com as out ras
face a face ou vi rtualmente. As co1nun idades se mantêm unidas por uma meta co-
mum e pelo desejo de compartilhar experiências, ideias e melhores práticas dentro de
u1n tópico ou disciplina, usando normas e processos compartilhados. As co1nunidades
também são responsáveis por captar as melhores práticas e administra r um corpo de
conhecimentos e1n nome da organização. As comunidades da Fluor são lançadas for-
malmente e possuem líderes, gerentes e especialistas designados.
Os esfo rços de gerenciamento de conhecimento da Fluor já receberam diversos
p rêmios por sua excelência, incluindo o de E1npresa Mais Admi rada da América do
Norte e do Mundo em termos de Conhecimentos (MAKE, North American and Glo-
bal Most Admired Knowledge Enterprise), chegando ao status de "Hall da Fama" por
criar um am biente cola borativo para o compa rtilhamento de conhecimentos. Esses
prêmios reconhecem soluções que sistematicamente tiram proveito do conhecimento
e do pessoal de uma organização de modo a 1nelhorar 1nensuravehnente a responsi-
vidade, inovação, co1npetência e eficiência organizacional. Além disso, a abordagem
da Fluor já figurou na Harvard B11siness Review e na \Vali Street ]011rnal, alé1n de em
outros livros e artigos.
A maior parte da força de trabalho alvo está envolvida em uma ou mais comuni-
dades de conhecimento, compartilhando conhecimentos globahnente, possibilitando
processos de t rabalho e reunindo as pessoas de forma rápida . A Fluor encoraja com-
portamentos de compartilhamento de conhecimentos em toda a organização. Qual-
quer funcionário pode se juntar a uma ou mais comunidades de conhecimento e pode
postar uma pergunta ou responder a uma pergunta. As respostas das perguntas feitas
nos fóruns normalmente são recebidas dentro de 24 horas da postagem - mantendo a
pro1nessa da Fluor de comunidades confiáveis e responsivas - garantindo que todos os
funcionários tenham um a lto grau de confiança no sistema.
Hoje, há 49 comunidades de conhecimento estabelecidas na organização. A Fluor
possui 30 mi l membros ativos na comunidade dispersos por todo o mundo e ma is de
4 m il especial istas no assunto (SMEs, subject tnatter experts) em mais de 1.200 áreas
dent ro dessas co1nun idades. Há um a lto volume de atividade na comunidade; são fei-
tas 1na is de 10 mil buscas e 2.600 visua lizações ou downloads de anexos diaria1nente,
além de 1O mil acessos semanais para leitura do fóru 1n.
Estratégias de gerenciamento de conhecimentos para suportar

a execução de projetos
A Fluor possui uma longa história de compartilhamento de conhecimento, da qual
grande parte se atribui a uma cultura que apoia consistentemente tais comportamen-
tos. A paixão pela const rução de carreiras e conhecimento se encontra no cerne dos
negócios da Fluor. A organ ização promove uma cultura baseada no comparti lhamento
de conheci1nentos por toda uma rede de funcionários. Os líderes desempenham u1n
papel i1nportante na sustentação dessa cultura.
O processo forma l de gerencia1nento de conhecimentos da Fluor começou e1n
1999, quando a empresa lançou sua estratégia de gerenciamento de conhecimento. A
Fluor utilizou uma abordage1n de duas vertentes por meio da implementação de u1na
estratégia de condificação e de u1na estratégia de persona lização:
• A estratégia de codificação envolve a docu1nentação do conhecimento e seu ar-
mazenamento e1n um banco de dados. A ênfase aqui é na reuti lização do conhe-
cnnento.
• A estratégia de perso,ialização focaliza-se na conexão entre pessoas, criando re-
des de pessoal e enfatizando soluções personal izadas para problemas singulares.
O objetivo da Fluor é que novos conteúdos seja1n passados rapidamente de u1n
foco de personalização para um foco de codificação a fim de possibilitar a reutilização
dos conhecimentos que foram reunidos.
U1na n1aneira por meio da qual a Fluor n1antém as comunidades relevantes é a
atualização periódica de conteúdos. A organizaç.ão implementou processos para garan-
tir que as comunidades ana lise1n e revisem frequentemente seus conteúdos. Espera-se
que cada co1nunidade assu1na responsabilidade por todos os seus ativos intelectuais.
Por que usar essa abordage1n de duas vertentes? A equipe de gerenciamento de
conhecimentos percebeu que enfatizar conhecÍlnentos explícitos em det r imento de
conhecimentos tácitos não funcionaria porque seria visto como "apenas mais u1na
ferramenta". Por outro lado, focalizar somente nos conhecimentos tácitos teria re-
sultado e1n uma fa lta de conhecimentos docu1nentados e uma fa lta de impacto global
multifuncional.
Projetos empresariais, pensamento empresarial
A abordagem da Fluor quanto ao gerencian1ento de conhecimentos é extremamente sin-
gular, exigindo un1 pensan1ento empresarial e uma mentalidade global - uma abordagem
raramente vista em outras organizações. Essa abordagen1 é adotada en1 suporte aos seus
projetos globais. Na Fluor, todos os funcionários possuen1 acesso a todas as comun ida-
des, segue-se un1 processo rigoroso de in1plantação da comunidade, há programas de
mensuração do desempenho e auditoria da comun idade em andamento, e integran1-se
comportamentos de con1parti lhamento a todos os aspectos das operações da empresa.
A visão de gerenciamento de con hecimentos da Fluor, que engloba toda a empre-
sa, era ter uma solução de tecnologia que incluísse as comunidades com conteúdos
integrados, discussões e perfis de pessoal a fim de protnover uma menta lidade global.
Tirar proveito do capital intelectual coletivo de todos os funcionários em suporte à
d ireç.ã o estratégica dos negócios era um objetivo-chave. As comunidades foram cria-
das para fornecer soluções ótimas aos clientes por meio de utn cotnpati lhamento de
conhecimentos que cruzasse os limites geográficos e das linhas de negócios da empre-
sa, usando uma ferra tnenta de busca robusta e permitindo o acesso globa l. O geren-
ciamento de conheci tnentos (GC) em toda a empresa ta tnbém pretendia aprimorar os
conjuntos de habilidades dos funcionários por meio do fácil acesso ao conhecimento,
a materiais de treinamento e a especialistas. Finalmente, o GC em toda a empresa pro-
tege a propriedade intelectual na organização. O sistetna monitora a atividade para
salvaguardar a propriedade intelectua l.
Comunidades de conhecimento: onde as pessoas se reúnem

As comunidades de conhecimento têm o suporte de professores, gerentes de conheci-
mentos, uma equipe global e centra lizada de GC e especialistas em diversos assuntos.
Uma equipe centralizada de GC supervisiona as atividades da comunidade e trabalha
de perto com os líderes, gerentes de conhecimento e especia listas em diversos assuntos
de todas as partes da etnpresa.
A Fluor utiliza um forte modelo de governança, como exibe a Figura 15- 52, para
a criação de uma comunidade, defin indo os objetivos dessa comunidade e medindo
Patrocínio
Líder de
comunidade
Gerente de
conhecimentos
da comunidade
Membros da
Especialistas comunidade
em diversos
assuntos
Figura 1S-52 Modelo de governança da Fl uor.

seu desempenho. A Fluor já observou out ras organizações que oferecem um modelo
ad hoc de criação de comun idades ou oferecem um conjunto de tetnplates desenvolvi-
do pela Equipe Centra l de GC para qualquer grupo interessado em criar u1na comuni-
dade. A experiência nos mostra que esses modelos abertos de criação de comunidades
resultatn em comunidades ineficientes e redundantes.
A abordagem to gerenciamento de conhecitnentos empresarial da Fluor exige u1na
mental idade expandida para Ítnplementar e 1nanter comunidades com botn desempe-
nho além do que é exigido quando a abordagem de GC é direcionada a um seg1nento
da empresa, é regional, ou não é aberta a todos os funcionários. A Fluor aplica quatro
conceitos de pensamento empresarial em seu programa de GC:
1. Proteção - Assumir responsabilidade pelos ativos intelectuais confiados à
comunidade (pessoas e conteúdos explícitos); não gerenciar conteúdos que
deveriam ser gerenciados por uma outra comunidade; informar sobre lacunas
- não criar conteúdo, a menos que você realmente seja seu proprietário; se
você for proprietário de conteúdos, mantenha-os atualizados;
2. Perspectiva geral - Criar um atnbiente que permita todos os funcionários
"compreenderem a 1nensagem" sem precisar despender esforços excessivos.
Algo pode fazer sentido enquanto estiver autocontido em uma comunidade,
mas a partir de uma perspectiva geral (e em toda a empresa), aquilo pode
parecer confuso, então ajudamos os funcionários a pensar em como se solu-
cionam problemas de engenharia e de negócios, e não cotno decifrar a nave-
gação (do site) de uma comunidade personalizada;
3. Teste de credibilidade para o cliente - Espere que o cliente vá ver o conteúdo,
demonstrações para clientes potenciais são frequentes;
4. Expectativas de Franchise da Co,nunidade - Apoie a marca GC da Fluor, seja
un1 líder ent re os n1en1bros da co1nunidade, tire proveito das n1elhores práti -
cas de GC em todas as con1t1nidades, crie orgulho em todas as co1nunidades.
As comunidades de conhecimentos têm flexibilidade, sim: cada comunidade esta-
belece seus próprios objetivos, que estão alinhados à estratégia gera l da organização,
mas que são suficientemente específicos para definir o que a co1nunidade de pessoas
precisa a lcançar a fim de oferecer suporte à direção estratégica. Os líderes da comu-
nidade são a autoridade máxi1na dentro dessa função. Nesse papel de liderança, são
responsáveis por melhorar o desempenho geral dentro de suas respectivas funções,
pela seleção, implementação e atua lização de 1nelhores práticas, pela seleção e suporte
de ferramentas de software exclusivas para sua função, e pelo desenvolvimento funcio-
nal do pessoa l. Uma rede de líderes funcionais da comunidade (Líderes de Excelência
Global) que cria consistência entre as funções.
Ao lançar uma nova comunidade de conhecimentos, cada uma delas passa por um
processo de gerenciamento que inclui os seguintes conceitos ao longo de um período
de tempo detenninado pela urgência da liderança da comunidade:
• Avaliação da prontidão
• Estratégia da liderança da comunidade
• Inauguração da comunidade
• Estrutura da comunidade
• Conceitos de coleta de conteúdos
• Identificação de conteúdos prioritários
• Atualização da coleta de conteúdos
• Estratégia de lançamento
• Lançamento da comunidade
• Transição da implementação ao desempenho
• Plano de desempenho da comunidade
• Reuniões periódicas de desempenho
• Implementação inicial
• Dese1npenho
Dent ro de cada co1nun idade, estabelece-se uma estr ut ura de categorias baseada
nas co1npetências centra is, já que a proteção dos ativos explícitos é crucia l. Isso inclui
criação de u1n processo para a revisão e aprovação de novos conteúdos por um espe-
cialista, revisão e atualização de conteúdos por especialista quando for chegada a data
de revisão, e respostas confiáveis e responsivas de um especialista pa ra as perguntas
feitas em fóruns de discussão.
O desempenho da comunidade é 1ned ido pela forma como ela alcança seus obje-
tivos. Dentr o da implementação da tecnologia, coletam-se inúmeras estatísticas. Essas
estatísticas, embora não sejam uma medida real do desempenho, fornecem uma in-
d icação dos níveis de atividade e uso e acompanha1n alguns níveis de conformidade.
Especialistas formam a espinha dorsal da comunidade de conhecimentos

A aplicação de un1 a lgoritmo não substitui a experiência no mundo real. A rede de
especialistas no assunto (SMEs, subiect matter experts) da Fluor fo rn1a a espinha
dorsal dos esforços da empresa em termos de conhecimentos. Envolver esses espe-
cia listas é essencial pa ra o sucesso da comunidade, de projetos e da en1p resa. Esses
SMEs formam o núcleo de cada con1unidade. A frequência com que um SME partici-
pa de uma comunidade afeta a qualidade e a quantidade de conteúdo dela . Os espe-
cia listas são escolhidos pelos líderes de cada comunidade: não se pode sin1plesmente
se autodecla rar um especial ista - eles deven1 ser recon hecidos con10 ta is por outr as
pessoas. Os SMEs receben1 treinan1ento en1 p rocessos de GC que con1unican1 expec-
tativas cruciais de modo que eles possan1 funciona r eficientemente. Eles se inscre-
ven1 pa ra receber notificações automáticas sobre discussões e recebem at ualizações
quando docun1entos necessitam de revisão ou feedback . Alinhar conteúdo e fóruns
a á reas de especialização facilita a notificação auton1ática dos SMEs quando seus
conhecimentos são necessá rios.
História de sucesso: acesso a alternativas de design economiza 1 milhão

de euros em um projeto
Um engenheiro de processos em uma empresa recé1n -inaugu rada no Oriente Médio
estava procurando alternativas para um equipamento caro que estava na base do de-
sign do projeto. Ele estava questionando a necessidade daquele equipamento, pois ele
gerava um custo de insta lação muito alto para o projeto .
Embora estivesse em um escritório sem todos os recursos funcionais típicos, por
meio do acesso à base de conheci1nentos globa is da Fluor, ele foi capaz de acessar os
manuais de design, obter respostas de especialistas a perguntas colocadas nos fóruns e
referências a projetos passados. Consequentemente, ele conseguiu reco1nendar a elimi-
nação do equipamento caro, o que economizou I m ilhão de euros para o cliente mais
custos extras de operação e manutenção.
O cl iente ficou tão satisfeito com a rapidez da resposta e com o rápido acesso
aos conhecimentos e especialistas da Fluor em todo o n1undo que foi feito un1a nova
encomenda de trabalho no va lor de 700 m il para um estudo sim ilar en1 un1 out ro
estabelecimento.
O Programa SME Protégé é uma outra plataforma criada para promover o envol-
vimento de futuros especialistas desde cedo. O programa "casa" funcionários inician-
tes e intermediários com especia listas de nível sênior e promove uma aprendizage1n
acelerada. Os SMEs trabalha,n com funcionários para criar relacionamentos, d iscutir
áreas técnicas de projetos, desenvolver novos conhecimentos, revisar conhecimentos
existentes, e ajudar a responder perguntas dos fóruns.
A liderança é a chave do sucesso

Un1a liderança eficiente é a n1elhor garantia de sucesso para as comunidades de conhe-
cin1ento da Fluor. Os líderes de conhecimento atende1n as co1nunidades e se comunicam
aberta e frequentemente con1 elas, sendo modelos visíveis dos comportamentos deseja-
dos. Os líderes de comunidade reconhece1n que eles estão ajudando a criar u1na cultura
de con1partilhamento de conhecimentos e faci litando conexões entre pessoas. Eles ta 1n -
bé1n se certifican1 de que é "seguro" para os funcionários fazer perguntas, con1partilhar
abertan1ente e confiar nas respostas que recebem. Além disso, os líderes de conhecin1en-
to reconhecem que uma comunidade é uma comunidade hun1ana, e não uma in1plen1en-
tação tecnológica. Os líderes compreendem que são responsáveis pelo con1ponente de
capita l hun1ano de suas comunidades e encorajam a aprendizagem por toda a vida.
É importante ta1nbém o fato de os líderes reconhecerem o ta lento e a inteligência
das pessoas da organização. Eles inspiram os membros de uma comunidade a combi-
nar experiências e pensamento inovador para criar novos conhecimentos e encorajam
a comunidade a trabalhar por meio da colaboração.
Finalmente, os líderes conectam a comunidade à direção estratégica da empresa e
a estimulam a alcançar bons resultados de negócios. Eles sabem que quando as pessoas
estão conectadas por meio de um objetivo comum, elas se sente1n mais energizadas.
Processos de trabalho para as comunicações em gerenciamento

de conhecimentos
U1na parte integra l da estratégia de gerenciamento de conhecimentos da Fluor é u1na
comunicação eficiente. A Fluor utiliza diversos princípios de comunicação para garan-
tir que suas comunicações sejam eficientes e rápidas. A Fluor acredita que seja impor-
tante tirar proveito de todos os canais de comunicação da organização e proa tiva men-
te procurar oportunidades para informar sobre o gerenciamento de conhecimentos e
como ele facilita a execução de projetos.
A Fluor possu i inúmeras est ratégias de comunicação em funcionamento como
suporte à retenção e à t ransferência de conhecimentos. Alguns deles incluem:
Orientação a funcionários recé1n-cont ratados. Os funcionários são expostos à cul-
tura de compartilhamento de conhecimentos durante o recrutamento e à orientação a
funcionários recém -cont ratados. Especifica1nente, os materiais usados nessa orienta-
ção desafiam os funcionários a compartilharem conhecimentos por toda a rede global
da Fluor a fim de ter sucesso na organização. Como a mobi lidade na carreira aumenta
de acordo com a participação em comunidades, 1nuitos funcionários se envolvem rapi -
damente em atividades das comunidades.
• Treinamento para os gerentes de conhecimentos.
• Teleconferências globais.
• Reuniões de depa rtamento.
• Sessões "aprendendo no almoço".
• Histórias de sucesso na página inicia l da comunidade on-line que mudam a cada
dois ou três dias.
Uma outra melhoria no processo de trabalho está ligada à estr atégia de comu-
nicação organizacional. A antiga prática era d isseminar informações por meio da
hierarquia organizacional. Ent retanto, nem todos via tn essas comunicações. Agora,
as comunidades enviam mensagens diretamente para todos os membros da comu-
nidade. Consequentemente, as mensagens têtn um 1naior nútnero de leitores (maior
penetr ação), o que deixa as pessoas informadas e ajuda a atr air novos membros. Cada
mensagem é enviada como um e-ma il com um link com informações de suporte na
comunidade de conhecimento. A abordagem de usar um link tem como final idade o
acompanhamento e, às vezes, a conformidade. Os funcionários frequentetnente res-
pondem a mensagens e são encorajados a entrar etn determ inada comunidade como
pa rte de um acompanhamento de rotina.
Reconhecendo os pioneiros do GC... e outros

Desde que a Fluor co1neçou com seu compartilhamento de conhecimentos em suporte
ao caminho rumo a projetos globais, a empresa percebeu que precisava reconhecer
aqueles que tinham sido tão instr u1nentais para seu sucesso e sua adoção. Anterior-
mente, a Fluor tinha reconhecido os "Pioneiros do GC": aqueles que ol havam a lém
dos lim ites norma is geográficos ou de linha de negócios e enxergavam como o com-
partilha,nento de conheci tnentos podia ser institucionalizado globa lmente. Hoje, a
Fluor possu i dois bem-sucedidos programas de reconhecimento em funcionamento.
O primeiro programa reconhece em out ros colegas o comportamento de compartilha-
mento de conhecimento, e o segundo reconhece o valor gerado por 1neio do comparti-
lhamento de conheci tnento e da colaboração - essa campanha ajuda a Fluor a contar
as histórias de por que o compa rtilhamento de conhecimentos e a colaboração são
importantes não somente pa ra a Fluor, mas para os ind ivíduos.
A Fluor desenvolveu um prêmio anual de gerenciamento de conhecimentos para
o reconhecimento de colegas conhecido como "KM Pacesetter" (Precursor em GC).
Colegas de tr abalho indicam uns aos outros ao longo do ano para esse prestigioso
prêmio. Um "KM Pacesetter" é a lguém excelente em comportamentos de comparti-
lhamento de conhecimento. Só no ano de 2012 houve mais de 1 mil indicações de
funcionários da Fluor em todo o inundo, e, até hoje, centenas de pessoas já foram re-
conhecidas como "KM Pacesetters". A Fluor sente que essa campanha é bem-sucedida
porque é decidida por funcionários - eles próprios podem reconhecer o bom tr abalho
que seus colegas estão desenvolvendo, e, por sua vez, a empresa é capaz de realçá-los
como "KM Pacesetters".
A segunda campanha é uma competição anua l de histórias de sucesso em GC
como parte das celebrações do"Knov,rvember" (nove1nbro do conhecimento). A equi-
pe de GC reúne histórias de sucesso que ajudem a articula r o va lor que está sendo
levardo às pessoas e aos projetos etn todo o mundo. Essas histó rias são variadas, e têm
d iferentes proposições de valor. Isso é importante, já que não há nenhuma proposição
de valor "única" quando se trata de uma força de trabalho de 30 mil pessoas. O segre-
do do valor das histórias de sucesso é que normahnente há a lgo com que todos conse-
guem se identificar, e eles podem compartilha r o sucesso com sua equipe de projetos
ou replicá-los em seus próprios projetos.
"O cotnpa rtilhamento de conhecimentos é hoje claramente uma parte institucio-
na lizada de nossa cultura, na qual se cria valor pa ra nossos Clientes por 1neio de uma
estrutura aberta, transparente e colaborativa que, interessantemente, reflete muito as
sociedades modernas e bem-sucedidas de hoje em dia", diz Peter Oosterveer, presiden-
te do Grupo Energia e Produtos Quím icos.
Gerenciamento de conhecimentos no contexto da gestão de projetos

Quando o gerenciamento de conhecimentos é considerado no contexto da gestão de
projetos, há duas áreas de alto nível que devem ser abordadas:
• Compartilhamento de conhecimentos e colaboração ent re os projetos
• Compartilhamento de conhecimentos e colaboração dent ro de um mes1no projeto
Cada área possui aspectos e oportunidades únicas para entregar valor ao projeto
e à organização. A Figura 15- 53 fornece uma visão desses dois tipos de compartilha-
mento de conhecimentos e colaboração.
Compartilhamento de conhecimento entre diferentes projetos
As organizações de execução de projetos desenvolvem u1na base considerável de co-
nhecimentos obtidos do número de projetos que já fora 1n executados no passado.
Parte desse conhecimento é explícito e é aproveitado por meio de u1na estratégia de
codificação. Outros conheci1nentos são tácitos e exigem uma estratégia de persona li-
zação para tirar proveito de um possível valor.
O conhecimento documentado assume muitas formas, incluindo relatórios de
conclusão de projetos, práticas, diret rizes, lições aprendidas e outros conteúdos que
fornecem a estrutura para os processos de execução de projetos e pode1n ser acomo-
dados em uma plataforma de comparti lha1nento de acesso imediato. Outros exemplos
de conhecimento documentado incluem relatórios de mitigação de riscos, soluções
exclusivas desenvolvidas sobre o projeto, relatórios de aná lise de alternativas e reco-
mendações; e sugestões de conscientização de valor.
Uma quantidade significativa de conhecimentos acumulados, poré1n, é tácita e
baseada em experiências pessoais que funcionários adquirem ao longo de mu itos anos
e em muitos projetos, e1n muitos locais, para muitos clientes. Esses conhecimentos re-
sidem nas 1nentes das pessoas 1nais experientes da organização. Eles não estão escritos,
e, mesmo que estivesse1n, o contexto e a interpretação dificultariam que fossem usados
adequadamente. A menos que esses conhecimentos sejam trazidos para novos proje-
tos, eles são, na verdade, um ativo da empresa do qua l não se tira proveito.
Entre diferentes projetos Dentro de um mesmo projeto
Modelos e Sub·
t1mplat1s Prãtlcas e contratadas
Llçl!es procedi·
aprendidas
mentos
Esallário
Conheci·
Cliente
mentos
exteroos
Colaboração Colalloraçlo
no nível da Ho11e 10 1Mtl 110
empresa olllce proJoto
Conheci· \ _ _,....,
mentas da
indústria JV's e
Canlelro
tle obras parceiros
Grupos Fôruns de
funcionais dlsc:usdo
Especialistas Fornecedores
globais
Figura 15-53 Colaboração de conhecimentos.

Para ser bem-sucedido com o cotnpartilhamento de conhecimentos ent re d iferen-

tes projetos, o conteúdo e a experiência de especialistas também precisam ser acessí-
veis, de fonna que atendam às necessidades dos participantes do projeto que estejam
em busca desses conhecimentos. O objetivo do cotnparti lhamento de conhecimentos
ent re d iferentes projetos é melhorar continuamente o desetnpenho dos projetos por
meio da aplicação de conheci tnentos e experiências adquir idos durante a execução
de projetos anteriores. Para os funcionários, esse comparti lhamento cria oportun i-
dades para se aprender de colegas de todo o inundo, ajuda novos funcionários a se
adaptarem ao traba lho mais rapidamente e gera um clüna de confiança, uma vez que
os funcionários sabem que a comunidade global está disponível e disposta a auxil iar.
Como utn exemplo de comparti lha ,nento de conhecimentos entre diferentes proje-
tos, um engenheiro recétn -formado foi contratado pela Fluor e enviado a um canteiro
de obras. Utn dia, ele foi desafiado pelo cl iente e pelo gerente da obra. Em uma coluna
de suporte de dutos de distribuição, um dos pinos de montagem não conseguiu ir alto
o suficiente para apertar a porca e a arruela como deveria. Essa foi uma situação que
o novo funcionário nunca encont rara antes, ,nas sua resposta foi: "Não se preocupem,
terei uma resposta até o fi ,n do dia». Ele voltou para o trailer de construção, digitou
esse problema em um fórum de discussão, e especialistas no assunto forneceram os
procedi tnentos necessários em menos de uma hora. Instilar esse tipo de confiança em
todos os funcionários, não apenas em recém-fonnados, é um enorme benefício quando
os conhecÍtnentos são faci lmente acessíveis ent re diferentes projetos.
Na n1edida em que a organização passou a reconhecer o va lor da colaboração
globa l, foram surgindo n1uitos exemplos de inovações nos processos de t rabalho.
Por exen1plo, o gerenciamento de conhecimentos é integrado aos requisitos dos siste-
mas operacionais da Fluor, que é o programa de qua lidade geral da empresa. Todos
os principais documentos operacionais da Fluor são entregues e mantidos por meio
da plataforma Kno\vledge Online. Esses documentos de processos de traba lho são
atualizados frequenten1ente, com base na experiência de projetos e mudanças nos
cód igos da indústria. Durante o processo de atua lização, as mudanças propostas são
postadas na con1unidade de conhecimento apropriada, e qualquer funcionário pode
fazer sugestões.
Compartilhamento de conhecimentos dentro de um mesmo projeto
A colaboração e o compartilhamento de conheci tnentos dent ro de um mesmo proje-
to é tão importante quanto o compartilhamento entre diferentes projetos. Esse tipo
de colaboraç.ã o é d iferente no sentido de que as partes envolvidas podem incluir a
contratada, o cliente, os parceiros de joint vent11re, fornecedores, fabricantes e outras
organizações. As solicitações de informação (RF!s, requests for information), o geren-
ciamento de interfaces, as revisões de documentos do fornecedor, as revisões de design
e progresso são exemplos de interações que se beneficiam do compartilhamento de
conhecimentos e da colaboração dentro de utn mesmo projeto.
Os desafios que podem ser encont rados ao tentar cotnparti lhar conhecimentos e
estabelecer colaborações dent ro de um mesmo projeto incluem: situações em que cada
organização pode ter sua própria p lataforma de tecnologia de GC, uma cultura de
compartilhamento de conhecimentos que talvez não exista e preocupações relativas a
propriedade intelectual. O objetivo geral, porém, deve ser que cada organização que
forma a equipe de projeto ampl iada não somente designa 1nembros individua is, mas
também possui as capacidades de reunir e t razer os ativos intelectua is combinados de
sua organização para o projeto. A medida que novos conhecimentos são desenvolvi-
dos ao longo da execução do projeto, conforme o caso, eles devem ser disponibilizados
para reutilização por cada organização.
As abordagens de comunicação e compartilhamento de conhecimentos devem fa-

zer parte de uma sessão de alinha1nento na inauguração do projeto e quando os fabri-
cantes ou fornecedores são trazidos "a bordo" do projeto.
Fatores-chave de sucesso
Pesquisas em iniciativas de gerenciamento de conhecimentos indica tn que um nú tnero
muito grande, 80%, não consegue corresponder às expectativas. Co1n mais de u1na
década de colaboração e compartilhamento de conhecimentos be1n -sucedidos, a Fluor
aplicou os seguintes fatores-chave de sucesso para guiar suas atividades de gerencia-
mento de conhecimentos.
Alinhar os objetivos do GC à estratégia de negócios

O compartilhamento de conhecimentos e a colaboração devem ser apl icados a u1n
desafio de negócios ou oportunidade est ratégica com uma 1nental idade empresarial.
Simples1nente montar uma plataforma de gerenciamento de conhecimentos ou colabo-
ração sem um sólido raciocínio estratégico é uma das principais causas de fracasso do
gerenciamento de conhecimentos. É mais provável que a organização adote e demons-
tre os comportamentos desejados de compartilhamento de conhecimentos quando são
definidas e comun icadas claras necessidades e expectativas de negócios.
Os funcionários formam o cerne da estratégia de seNiços baseada em

conhecimentos da Fluor
Um pessoal entusias1nado, uma liderança ativa, co1npreensiva e envolvida e fortes re-
des unindo as pessoas são essencia is para o sucesso. Os comportamentos de retenção e
transferência de conhecimento precisa tn englobar o ciclo de vida de empresa do recru-
tamento à aposentadoria . É iguahnente importante definir e comunicar as expectativas
de compartilhamento de conheci1nentos e incutir os comportamentos desejados de
comparti lhamento de conhecitnentos na cultura organizacional.
Usar tecnologia em suporte à comunidade global

Embora programas bem-sucedidos de gerenciamento de conhecimentos coloque1n
uma forte ênfase sobre as pessoas, conectar uma força de traba lho globa lmente dist ri-
buída exige u1na platafonna de tecnologia robusta. Para minimizar a curva de apren-
dizagem e a confusão dos usuários, criar uma plataforma única para conectar os fun-
cionários de toda a empresa, independente da localização ou do fuso horário em que
se encontram, facilita a adoção.
Ênfase nas comunicações
A fim de sustentar as comunidades, é importante certificar-se de que histórias de su-
cesso se tornem ocorrências cotid ianas. Um forte patrocínio das comun idades deve
comunicar valor periodicamente e promover o envolvimento da comun idade.
Permitir que o compartilhamento de conhecimentos cruze limites

Incorpore o pensamento que engloba toda a empresa à sua est ratégia de gerenciamen-
to de conhecimentos. Certifique-se de que seus processos de gerenciamento de conhe-
cimentos envolva1n a comunidade globa l desde o início.
A liderança. possui influência direta sobre o sucesso do gerenciamento de
conhecimentos
O sucesso do gerencian1ento de conhecimentos está diretamente ligado ao apoio dado
pela liderança. Os gerentes de projetos estão em un1a posiç.ão en1 que seu suporte visível
influencia diretamente a força do compartilhamento de conhecimentos e colaboração,
tanto em seus projetos específicos quanto en1 toda a organ ização. Os gerentes de projeto
e1n particu lar precisam t irar provei tos de inovações, encorajar mem bros da equipe de
projetos a buscar o conselho de especialistas, encorajar me1nbros a contribuir co1n no-
vos conhecimentos e reconhecer o talento e a inteligência dentro da organização.
O gerenciamento de con hecimentos permi te que os gerentes de projetos t irem
proveito dos melhores conhecimentos e especia listas de sua organização, cruzando
os lim ites de tempo e espaço. O GC informa os membros de equ ipes de projetos,
a judando-os a to1nar decisões melhores e melhorando os resultados finais do projeto.
Direções fu turas para o gerenciamento de conhecimentos em projetos

Quando você já t iver aplicado o GC com êxito e t iver alcançado resultados mensu-
ráveis - qual é o seu próximo passo? Considere as seguintes áreas de oportun idade:
Entrega de conhecimento preventiva

Quando as equipes de projetos passam a se sent ir confortáveis compartilhando e tirando
proveito de conhecin1entos, o projet o se beneficia. A responsabi lidade pelo co1npartilha-
mento de conhecin1entos hoje ainda cai em grande parte nas mãos de cada n1en1bro de
equ ipe de projetos, acessando conhecimentos ou e.special istas quando surge a necessida-
de. Con10 se pode gerenciar o processo, prevendo a necessidade de conhecimento e espe-
cial istas? Con10 garantir que o projeto irá tirar proveito dos n1elhores conhecin1entos dis-
poníveis, independentemente da iniciativa do men1bro individual da equipe de projet os?
O futuro está nas mãos da entrega preventiva de conhecimentos. Isso começa com
u1na abordagem proat iva da entrega, usando uma sessão de facil itação de auxílio aos
conhecimentos - às vezes chamada de auxílio a colegas.
O auxJ/io ao conhecimento
O auxílio ao conhecimento é uma sessão planejada de faci litação para reunir todos os
recursos de projetos potenciais com a fina lidade de co1npart ilhar experiências e conhe-
cimentos com a equipe de projet os antes da reunião inaugural da execução do projeto.
Os resultados da sessão são documentados com ações identificáveis ou sugestões a
serem usadas e seguidas. O objetivo é aprender antes de fazer.
Um auxílio ao conheciment o bem-sucedido exige p lanejamento e preparação.
Você precisa ter as pessoas certas disponíveis e ministr ar a sessão no 1no1nento ade-
quado, pois o valor da sessão diminui com o passar do tempo. Quanto 1nais cedo você
puder min istr ar a sessão de auxílio ao conheciment o maior será o possível impacto
positivo sobre o projet o.
Entrega preventiva de conhecimentos - o papel do gerente de projetos

A fim de aprender antes de fazer, o gerente de projetos precisa procurar e encontrar as pes-
soas certas envolvidas no processo de auxílio ao conhecimento desde o início. A maior opor-
tunidade de impacto é no início, e tirar proveito de experiências passadas dá uma vantagem
ao seu projeto. O gerente de projetos precisa estar aberto a ideias de fora e estar disposto a
aplicá-las aos requisitos específicos de seu projeto.
Conexões para além da equipe de projetos

A maioria dos conhecimentos são tácitos. Trata-se do know-how ocu lto que se encon-
t ra na cabeça de cada membro das equipes de projetos e de out ros recursos externos. A
maior parte desse know-how nunca será exposta em um documento ou em uma fonte
on-line. Ela surge no cruzamento ent re necessidade e experiência. Nesse cruzamento,
ocorre uma t ransação - uma t roca de con hecimentos de uma pessoa para out ra. As
pessoas que estão se conectando umas com as outras continuam sendo o cana l mais
importante para a transferência de conhecimentos sobre projetos.
Ao gerenciar um projeto, há várias tecnologias emergentes que podem ajudar a
faci litar essas conexões ent re pessoas. A computação socia l propositada, usando ferra-
mentas de colaboração social, permite que as pessoas se conecte1n cruzando limites de
tempo e espaço, tirando proveito do melhor know-how d isponível. E possibilita que
essas conexões ocorram onde as pessoas estão, usando qua lquer dispositivo que esteja
disponível. Em muitos casos, isso sign ifica um dispositivo móvel wireless ou um tablet.
Conexões além da equipe de projetos - o papel do gerente de projetos

Quando você permite que os membros de equipes de projetos se envolvam em suas redes
ampliadas, participando e colaborando por meio de sistemas sociais empresariais, seu projeto
se beneficia. Os membros de sua equipe são capazes de tirar proveijo dessa rede para uma
tomada de decisões mais informada sobre o projeto.
Conhecimentos contextualizados
Começar o projeto bem infonnado por uma sessão de auxílio ao conhecimento é es-
sencial, mas esse não o único momento em que conhecimentos e especialistas são ne-
cessários. À 1nedida que a equ ipe de projetos va i se tornando mais confortável co1n
o compartilhamento e a busca de conhecimentos, ela passa a to1nar a in iciativa, pro-
curando ou compartilhando conheci1nentos sempre que necessário. O desafio é fazer
todos participarem. Para consegu ir isso, você precisará contextual izar a tarefa. Quan-
do dominamos a tarefa e temos um tÍlne interessado no projeto, podemos começar a
entregar o conhecimento e a experiência especializada a ela relacionados. Essa entrega
contextual do conhecimento informa todos os membros de equipes de projetos e ajuda
a garantir que eles estejam totalmente informados.
A entrega contextua l de conhecimentos depende de uma compreensão da ativi-
dade atua l de um 1nembro da equipe de projetos, e a capacidade de conectar o co-
nhecimento relacionado ao seu fluxo de processo de t rabalho. Buscar e co1npartilhar
conhecimentos não envolve uma decisão consciente ou um passo extra; é algo que está
embutido nas atividades que já estão sendo rea lizadas.
Por exemplo, um engenheiro que está trabalhando no design de uma torre de esca-
das poderia rapida1nente se conectar a exemplos passados; a outros especial istas ou a
códigos e práticas da indústria para informar suas decisões de design.
Conhecimentos contextualizados - o papel do gerente de projetos

Estabeleça expectativas com sua equipe de projetos, encorajando-os a identificar pontos fra-
cos em processos atuais que poderiam ser melhorados por uma injeção de conhecimentos ou
experiência. Desafie-os a procurar maneiras de melhorar o processo, especialmente quando
elas tornam a busca de conhecimentos e experiência mais transparente.
Desenvolvimento acelerado de experiência especializada

No d ia 1º de janeiro de 2011, os prÍlneiros adultos da geração Baby Boomer chegara1n
à idade de aposentadoria. Desde aquele dia, mais de 10 m il Baby Boomers chegam à
aposentadoria todos os dias. Esse ritmo irá continuar até o ano 2030. O r isco de perda
de conhecimentos devido simplesmente a uma força de t rabalho que está se aposen-
tando é tremenda, mas pode ser 1nediada .
Em seu livro Outliers, Malcolm Glad,vell sugere que" ... a ideia de que a excelên-
cia em rea lizar uma tarefa complexa exige um nível mínÍlno de prática ressurge aqui e
a li nos estudos sobre experiência especial izada. Na verdade, pesquisadores determina-
ram o que eles acreditam ser o número-chave para uma verdadeira especialização em
a lgu1n assunto: 10 mil horas". Não há atalhos para se tornar experiente, mas sempre
há formas de dedica r maior atenção ao assunto, encorajando a transferência de conhe-
cimentos de uma pessoa a outra .
O primei ro passo é identificar u1n plano de carreira que reconheça e encoraje o
acúmulo de experiência, reconhecer que sua equipe de projetos ta lvez possa trabalhar
junta em futuros projetos e considerar as oportunidades de aprimorar e desenvolver
os membros das equipes.
Forme pares reunindo um especialista como mentor e um "protégé" que o mentor
acompanhará. O aspirante a protégé pode ajudar o especialista, tirando parte da carga
de tr abalho de um 1nembro de equipe altamente valioso e solicitado, o que oferece
u1na verdadeira oportunidade de transferência de conhecimento enquanto se desen-
volvem os especia listas da próxima geração.
Desenvolvimento acelerado de experiência especial izada - o papel

do gerente de projetos
Os gerentes de projetos precisam considerar o desenvolvimento de membros de equipes de
projetos, tanto para a satisfação e o crescimento de sua carreira quanto para o benefício do
seu projeto e de projetos futuros. A transferência de conhecimentos ainda ocorre amplamente
por meio do desenvolvimento de especialistas.
O gerenciamento de conhecimentos dá aos gerentes de projetos a capacidade de

tirar proveito dos n1elhores especia listas disponíveis, gera ln1ente incluindo recursos
de fora da equipe de p rojetos imed iata. Aprendendo con1 outros p rojetos, tem-se
un1a vantagem no caminho run10 ao sucesso. O segredo é começar cedo e oferecer
un1a liderança clara à sua equipe. Defina as expectativas e encoraje-a a participar
do con1partilhamento de conhecin1entos e experiências especializadas não son1ente
dentro do projeto, n1as também para a lém dos lim ites de diferentes p rojetos.
Sua compreensão e apoio do gerenciamento de conheci1nentos fornece os funda-
mentos necessários para u1na execução de projetos mais intel igente.
15.7 Siemens PLM Software: desenvolvendo uma

metodologia de gestão de projetos global
Há décadas, grandes empresas dão às suas divisões multinaciona is uma tremenda au-
tonom ia no modo como elas fazem negócios. Isso funciona bem, contanto que as vá-
rias unidades não tenham de interagir e trabalhar juntas em projetos. Quando é neces-
sária interação, no entanto, e cada divisão possui uma abordagem diferente à gestão
de projetos - usando diferentes ferramentas e processos - podetn ocorrer resu ltados
desfavoráveis. Hoje, a tendência é o desenvolvi1nento de uma metodologia que abranja
toda a empresa. A Siemens PLM Soft\vare é u1n exemplo de empresa que desenvolveu
9
tal metodologia co1n êxito.
9
O restante desra seção foi fornecido por Jan Hornwall, PMO de SerYiços Globais da Siemens PLM Soft·
ware. Para informações mais detalhadas sobre os produtos e serviços da Siemens PLM. Software, visite www.
siemens.com/plm. Nora: a Siemens e seu logotipo são marcas registradas da Siemens AG.
Sobre a Siemens PLM Software

A Siemens PLM Soft\vare, uma unidade de negócios da Divisão de Automação In-
dust ria l da Siemens, é uma provedora global líder em software e serviços de gerencia-
mento de ciclo de vida de produtos (PLM, product /ife-cycle mariagement) com 5,9
mi lhões de licenças por posto de trabalho e 56 m il clientes e1n todo o inundo. Sediada
em Plano, Texas, EUA, a Sie1nens PLM Software trabalha colaborativamente com ou-
tras empresas para entregar soluções abertas que as ajudem a transformar mais ideias
em produtos bem-sucedidos.
Sobre a Divisão de Automação Industrial da Siemens

A Divisão de Automação Industrial da Sien1ens (Nuremberg, Alemanha) é uma líder
n1undial nas áreas de sistemas de auton1ação, computadores de baixa voltagem e
software industrial. Seu portfólio va i de produtos-padrão para indústr ias de manu-
fat ura e processan1ento a soluções para setores industr iais completos que englobam
a automação de instalações de produção de automóveis ou usinas químicas inteiras.
Con10 fornecedor líder de software, a Divisão de Auton1ação Indust r ia l otin1 iza
toda a cadeia de valor agregado de fabricantes - desde o design de produtos, desen-
volvimento e produção, a vendas em un1a an1pla variedade de serviços de n1anuten-
ção. Com cerca de 42.900 funcionários em todo o mundo, a Divisão de Automação
Industria l da Siemens alcançou, no ano fisca l de 2008, un1 total de vendas de EUR
8,7 bi lhões.
Resumo
A Siemens PLM Soft\vare, uma unidade de negócios da Divisão de Automação In-
dust ria l da Siemens e provedora global líder em software e serviços de gerencia1nento
de ciclo de vida de produtos (PLM), desenvolveu uma tecnologia que inclui a gestão
de projetos e programas, atividades técnicas e governança de projetos. A tecnologia
baseia-se no uso de um site interno que permite rápido acesso a todos os funcioná-
rios e foi implementada e ensinada globalmente co1n sucesso. O restante desta seção
descreve o histórico da 1netodologia de projetos e identifica melhores práticas para
esforços simi lares no futuro.
Histórico de projetos
A Siemens PLM Soft\vare desenvolve e implementa software de Gerenciamento de
Ciclo de Vida de produtos que inclui soluções para design con1putadorizado, ma-
nufatura e análise de engenharia (CAD/CAM/CAE), • além de gerenciamento de
dados, colaboração e simulação d igita l de fábricas. A organ ização global de vendas
e serviços da empresa é responsável por configurar e in1p lementar as so luções nos
estabelecin1entos dos clientes. Contratos podem variar de projetos pequenos com
duração de algums meses de t raba lho de un1a só pessoa a programas globais de
vários anos de duração envo lvendo centenas de pessoas. Esses projetos já foram
executados seguindo várias metodologias diferentes em estabelecimentos de todo
o mundo. Devido à nan1reza cada vez mais global das emp resas manufatureitas e
à crescente den1anda por uma variedade de especialistas en1 d iferentes assuntos de
• N . de T.: CAD: Compute, Aided Design (Desenho Auxiliado por Computador).

CAE: Computer Aided Engineering (Engenharia Auxiliada por Computador) .
CA/vl: Comp11ter Aided Mam,facturing (Fabricação Assistida por Computador).
todo o n1undo, iniciou-se a iniciativa de criar uma única metodo logia global para a
Siemens PLM Soft\vare.
Benefícios de negócios
Os benefícios de negócios a seguir impulsionaram o desenvolvimento da nova 1neto-
dologia:
• Co1npartilhar melho res p ráticas e bons exemplos ent re diferentes projetos e
geografias
• Acelerar o desenvolvimento de projetos por meio do rápido acesso a ferramentas,
guias, templates e melhores práticas
• Estabelecer uma " linguagem" metodológica comum que é usada em todas as
geografias e projetos
• Compartilhar recursos ao redor do inundo e desenvolver rapidamente os funcio-
nários recém-cont ratados e o externos
• Possibi litar maior repetibil idade e previsibilidade, resultando em menores riscos e
tempos de entrega
• Fornecer uma estrutura de governança de projetos/programas
• Aumentar a reuti lização de informações em projetos; estabelecendo a base para o
gerenciamento de conhecimentos
• Apresentar u1na experiência unificada e consistente de gestão de projetos para
cl ientes globais
Desenvolvimento metodológico
Uma vez que a iniciativa tenha sido iniciada, a prin1eira decisão foi ou desenvolver
nossa própria n1etodologia ou adquirir uma n1etodo logia de GP pronta pa ra usar.
A gerência, juntamente com a equ ipe de projetos, decidiu desenvolver sua própria
metodologia, baseada na experiência existente na própria empresa. O principal cri-
tério de decisão era que a n1etodologia deveria cobrir não somente as atividades de
gestão de projetos, mas tan1bém as atividades técnicas específicas de nosso negócio.
Era crucial tr abalhar tanto na gestão de p rojetos quanto na parte técnica conjunta-
mente en1 cada fase, já que um número razoável de projetos é realizado em pequenas
equipes e às vezes até n1esn10 o gerente de p rojetos possui o papel dual de tambén1
ser o arquiteto-chefe da solução técnica. Un1 outro critério-chave era que queríamos
tirar proveito do que já tínhamos em termos de processos e ternplates . Prevíamos
também uma adoção muito mais rápida se as pessoas da á rea reconhecessem partes
da n1etodologia.
O projeto foi planejado, e um plano de gestão de projetos fo i escrito e aprovado
pelo patrocinador do projeto. A equipe de projetos consistia de pessoas-chave de todas
as zonas do globo: Américas, Europa, Ásia-Pacífico e nossa equipe interna localizada
na Índia que imple1nentou o site da metodologia. Ao todo, a equ ipe cent ral consistia
e1n aproximada1nente I O pessoas.
O escopo do projeto foi desenvolvido e incluía o seguinte:
• A 1netodologia precisa cobrir todo o ciclo de vida de um projeto de serviços, de
sua iniciação ao seu encerramento. Além disso, ela tem de conter gerenciamento e
governança de programas.
• As atividades gera is de GP serão incluídas em uma seção que é a mesma para to-
das as fases, "Gerenciar Projeto".
• As atividades técnicas irão cobrir métodos sobre como identificar soluções pron-
tas para o uso mantendo, ao mesmo tempo, as personalizações dos clientes em u1n
nível mínimo, além de técnicas modernas como a rápida criação de protótipos e o
desenvolvi1nento iterativo.
• As atividades de cada fase são estruturadas e precisavam ser descritas; as respon-
sabi lidades de cada tarefa devia1n ser definida; e diret rizes e ferramentas de supor-
te a tetnplate tinham de ser disponibil izadas
• A metodologia tinha de ser alinhada aos processos em tomo dela como o processo
de vendas e o processo de suporte pós-projeto.
• Consolidar vários métodos de entrega de serviços existentes, tirar proveito das
melhores práticas reconhecidas já existentes na empresa.
• A gestão de projetos precisa ser a linhada ao processo e à terminologia do PMI
(Proiect Management lnstitute).
• Começar co1n uma metodologia abrangente, então uma versão para "projetos pe-
quenos" terá de ser desenvolvida.
• A tecnologia incluiria um web site com gerenciamento de conteúdo e uma ferra-
menta de feedback com funcional idade de aco1npanhamento.
• U1na versão que pode ser baixada da internet deve estar disponível a todos os fun-
cionários que t rabalham fora da rede interna, como a indústria de defesa.
• Treinamento e implementação globais.
A equipe traba lhava virtualmente, por meio de teleconferências, mas também ti-
vera1n três encont ros presenciais em vários loca is ao redor do globo, cada um co1n
quatro a cinco dias de duração. O projeto para desenvolver a metodologia durou 10
meses. Se estivéssemos todos no mesmo lugar, a duração teria sido significativamente
menor.
No início do projeto, a Siemens PLM Software era conhecida como UGS, uma
empresa de capita l privado independente. No final do projeto, a UGS foi adquiri-
da pela Siemens e renon1eada Sien1ens PLM Software. Ela foi mantida intacta como
unidade de negócios. Como a metodologia é adaptada ao nosso negócio de PLM, a
gerência decid iu continuar o projeto e implementar a n1etodologia. O alinhan1ento
con1 os aspectos obrigatórios de gestão de projetos da Sien1ens aconteceria em relea-
ses postenores.
Metodologia resultante - PLM VDM (descrição)

A metodologia de ent rega de va lor do gerenciamento do ciclo de vida de produtos
(PLM VDM, prod11ct lifecycle management value delivery methodology) fornece u1n
processo est ruturado para entregar uma solução PLM . (Ver Figura 15- 54.) A PLM
VDM enfatiza os aspectos singu lares de entregar uma solução para toda a empresa
usando os produtos da Siemens PLM Sofnvare e foi adotada em toda a organização de
serviços da Siemens PLM Sofnvare.
A PLM VDM engloba tanto a gestão de projetos quanto o trabalho técn ico.
É estrut urada de modo a possibilitar uma ent rega de projetos interativa e flexível,
n1antendo, ao mesn10 ten1po, "pontos de controle da qualidade" e marcos entre as
fases.
""o
O)
G)
(1)
!!l
SIEMENS .. ,iomons.com • Automation and OrWes
""
o
~ ~ ,; .... _. • 1,h!t.od l,l~p 1 &•d-•1< 1 Puf>!
e.
(1)
"O
IJ,tfo :ittíl,tDI D Mil íiiC'iul 'WllWlilll:!

.2.
(1)
9 PI.M VOM Sm.11 Proi,ects

g
lnlfOC,,,ctii TernK & Ell.,.-eniom • !'C!ltlodology
<>ven,iew MtlMdol...,Mml111$11,tlo11
PLM Value Delivery Methodology
fre.Align Align Plan Build Test Deploy Close
The P-rodutt Uttc,,de Man~tmtnl Vakle OtlivtlY MtlhodOIOIW (PLll1 VOII() prcwidts a $111JCluttd Pio«$$ fo, delivtnng • PLM $OIUIIOn, empha,sioog
lhe uniQUe aq,em oi del1Ytring an enterpme wide solVlion using Siemert& Pl.M Sofhtnfe produt1s This methodologv !las been aOOpted globa,
a«oss fie &emens PLM SoltWare semces O(OantZa1ions. PLM VOM delwers lhe fOloW«lg beneffls:
,. Eslabllshes a common me1l'lod01ogy"language· 111a1 is used across all-zones and between counlnee
• MoWs best prsflittt and goocf examptes to be shared glOballt
• Ena,bfes lnereased ,·el)ealabH~ and predletabDltt'1esut11ng in ta51er aelNeiylimes and reduted l'iSk
• PrCMdtt a S1rutbJ1td pro,ecb'prog,am gcwtrnanee hmtW01k
Tht mtlhOdology includts lht t bt-ams ofl)rOitd managemtnt and ltdlnica1 Clti'le:ry n is stutlurtd 10 allOW i•,Mrft aind f!txlblt p,ojttl OtliYtry wtiilt
m,intttning QIUJlity -oa•s· 01 milts.1onts btlwttn C,hHtS
For• oescripll(ln of e.acl'I PhHt , pie.ase stlttl lht c,h•st in tht lOgo o, in lht ·Oi,en,iew.,. MtlnCldology" droo-down menu •IMNt
Figura 15-64 O site interno da PLM VDM.

As sete fases da metodologia são as seguintes:
Pré-alinhamento
A final idade da fase de "pré-alinhamento" é adquirir conhecimentos suficientes sobre
os requisitos do cliente e o escopo do projeto, para ser capaz de definir um esboço de
alto nível da solução e a declaração de t rabalho.
A equipe de projetos t rabalha com a equipe de vendas e o cliente para estabelecer
o escopo gera l do projeto, determinar um cronograma preliminar, definir a estratégia
de serviços, conduzir uma ava liação de in fraestrutura e desenvolver o orçamento ini-
cial do projeto.
Alinhamento
Na fase de "alinhamento", a equipe de projetos trabalha com o cliente para transfor-
mar os conceitos da solução que foram definidos durante as atividades de pré-alinha-
mento em uma a rquitetura geral be1n definida para a solução.
• Os objetivos da fase de "alinhamento" são estabelecer uma compreensão co1nu1n
ent re o cl iente e a equipe de implementação em todos os aspectos do projeto,
captando uma definição completa e precisa do projeto por meio de workshops
técnicos, definições de casos de uso, rápida criação de protótipos e a linhamento
dos requisitos da solução às capacidades de produtos prontos para o uso.
• Esta fase está co1npleta quando o cliente aceita os casos de uso e os requisitos e
autoriza o prosseguimento do trabalho.
Planejamento
Na fase de "planejamento", a equipe de projetos t rabalha com o cl iente para desen-
volver os documentos restantes que serão usados para executar e contr olar o projeto
e desenvolver o design técnico.
• Dependendo da complexidade da solução, a equipe define planos detalhados para
o escopo, cronogra1na, custos, habi lidades, recursos, riscos, qualidade e comuni-
cações.
• Além do ambiente de testes, a equipe finaliza (baselines) a infraestrutura do sis-
tema para criar u1na plataforma estável para os a 1nbientes de desenvolvimento,
testes e t reinamento .
• Esta fase está completa quando todos os planos necessários de gestão de projetos
e as especificações funciona is e de design exigidas foram revisadas e fina lizadas
(baselined).
Construção
Na fase de "construção", a equipe de projetos trabalha com o cliente para criar a so-
lução definida, mantendo-se estritamente fiel aos requisitos.
• Durante a fase de "const rução", a equipe técnica configura e testa a solução, im-
plementa a estr atégia de migração de dados e desenvolve os materiais de treina-
mento. A fase de "construção" também inclui testes unitários internos e testes de
integr ação.
• Esta fase está completa quando a soluç.ã o está pronta para ser testada pelo cliente.
Testes
Na fase de "testes", a equipe confinna que a solução está pronta para uso pela produção.
• Durante a fase de " testes", os representantes da co1nun idade de usuários realiza
testes funcionais e de sistema para verificar se o sistema atende aos requisitos.
• Esta fase está completa quando a solução é aceita pelo cliente e está pronta para
i1nplementação em um ambiente de produção.
Implementação
Na fase de "implementação", a equipe ent rega a solução pronta aos usuários finais.
• A "implementação" da solução consiste en1 garantir que todos os dados tenham
sido migrados para o ambiente de produção, que a solução esteja funcionando com
todas as interfaces e que os usuários e as equipes de helpdesk tenhan1 sido treinados.
• A fase de "implementação" está completa quando a solução tiver sido passada ao
cl iente para uso na produção.
Encerramento
Na fase de "encerramento", a equipe garante que todos os aspectos administrativos do
projeto estejam completos.
• Durante a fase de "encerramento", a equipe de projetos completa e arqu iva docu-
mentos de projetos e conduz uma retrospectiva sobre o projeto a fim de captar e
documentar as lições aprendidas. A equ ipe de projetos é liberada.
As seções adicionais da metodologia são:
Seguindo o padrão do PMJ, as cinco fases do gerenciamento de programas são descri-
tas incluindo templates de suporte:
• Configuração pré-programa
• Configuração do programa
• Estabelecimento do gerenciamento de programas e configuração da infraestrutura
técnica
• Ent rega de benefícios incrementais
• Encerramento do programa
Pequenos projetos
Projetos menores do que USUS$100 mil em receita tota l poden1 selecionar un1a metodo-
logia simpl ificada, com descrições de atividades mais cu rtas e templates simpl ificados.
Governança de projetos
A governança de projetos envolve as linhas organizaciona is garantirem que o projeto
seja governado corretamente e que a to1nada de decisões seja efetiva e eficiente, levan-
do o projeto ao sucesso. Isso é feito através da garantia de que esteja1n e1n andamento:
• Termo de abertura do projeto
• Delegação de autoridade ao gerente de projetos
• Conselho de orientação do projeto

• Conselho de revisão gerencia l (MRB, Management Review Board)
• Conselho de revisão técnica (TRB, Technical Review Board)
• Verificações de saúde do projeto e retrospectivas de projeto
• Processo de aprovação de novos projetos
As melhores práticas são descritas nessas seções, juntamente com templates de su-
porte. Esta é uma área na qual se realiza o alinha1nento com os processos obrigatórios
da Siemens.
Treinamento e marketing
Esta importante seção cobre o materia l para treinamento, atua lizações, links para o
creina1nento e1n PLM VDM no site de treinamento interno, apresentações da 1netodo-
logia para o público interno e para cl ientes.
Lançamento e implementação
O lançamento e a implementação da metodologia globalmente incluem a segu intes
atividades:
• Divulgação em conferências em cada uma das geografias. A gerência reservou
tempo para a metodologia ser apresentada, o que envia uma mensagem positiva e
force a todos os funcionários.
• Desenvolver um panorama de uma hora da metodologia co1no uma apresentação
em voice-over. Tal panorama foi disponibil izado na infraest rutura do treina1nento
interno, e os participantes pod iam visualizá-lo de qua lquer pa rte do mundo pela
int ranet da empresa.
• Desenvolvimento de materia l para um treinamento presencial de dois dias. Esse
treinamento foi, então, 1ninist rado e1n mu itas aulas, em quat ro continentes, para
aproximadamente 600 pessoas, ao longo de seis meses e cobria todos os papéis a
serem desenvolvidos pelos funcionários e incluía exercícios.
• Apresentações ao vivo extras em chamadas de teleconferência para centenas de
outras pessoas
• Desenvolvimento de garantias de marketing; ficha informativa sobre a metodo-
logia - mesmo formato que os de nossos produtos, desenvolvendo um logotipo e
apresentações de clientes
• Atividades de seguimento; adoção do 1nonitoramento por meio de KPls e da ação
baseada no feedback dos usuários
Lições aprendidas e melhores práticas

Desenvolver u1na metodologia em u1na equipe remota/virtual é possível, mas planeje
diversas reuniões presenciais. Essas reuniões foram cruciais para o sucesso do projeto;
reunir todos em u1na sala para workshops mais longos, dividir o trabalho e fazer ses-
sões e grupos menores, reunir todos novamente e tomar decisões finais. É itnportante
também que as pessoas se conheça1n e se divirtam fora do horário de t rabalho - isso
torna o t rabalho à distância que se dará posteriormente muito mais eficiente. Essas
reuniões tambétn serviam co1no um reconhecimento da cont ribuição feita por todos.
Envolva pessoas-chave das várias localizações geográficas no desenvolvimen-
to desde o início. Leva muito mais tempo do que uma pura abordagem descendente
(top-down) rea lizada por um PMO centra l, mas essas pessoas se torna1n defensoras
convictas em cada local geográfico durante a i1nplementaç.ã o e aumentam significati-

vamente as chances de uma adoção no longo prazo.
Se você precisa de uma pura metodologia de gestão de projetos, considere adquirir
u1n produto pronto para o uso.
Se você precisa de uma metodologia específica para cada projeto, considere desen-
volvê-la você mesmo. Na maioria das vezes, há um enorme conhecimento na própria
empresa é apenas uma questão de captá -lo, registrá-lo e disponibilizá-lo globalmene
dentro da e1npresa.
Obter a adesão da gerência é essencia l a fim de garantir uma participação ativa de
pessoas-chave, de obter espaço em conferências para a divu lgação e de tornar o logo-
tipo da metodologia visível nas apresentações da alta gerência, o que é essencia l para
a adoção da metodologia.
Não subestime o tetnpo que leva para o desenvolvimento de materia is de t rei-
na1nento e para o próprio treinamento ser m inist rado globalmente. O sucesso dessa
metodologia se deve ao trabalho pesado desenvolvido pelas pessoas dedicadas que
concluíram essas tarefas com sucesso!
Gestão de projetos
orientada a valor
16.0 Introdução
Ao longo dos anos, passamos a aceitar a definição tradicional de sucesso de um proje-
to: atender à tripla restr ição. Mais recentemente, 1nod ifica 1nos nossa definição de su-
cesso declarando que é preciso haver um propósito de negócios válido para trabalhar
no projeto. Passou-se a reconhecer, então, que o sucesso possui tanto u1n componente
de negócios quanto um co1nponente técn ico.
Hoje, estamos mod ificando a definição de sucesso ainda 1nais adicionando u1n
componente de "valor", como se vê na Figura 16-1. Em out ras pa lavras, o p ropósito
último de se tra balha r em um projeto deve ser fornecer alguma forma de valor tanto
ao cliente quanto à organização matriz. Se o va lor do projeto não conseguir ser identi-
ficado, então talvez não devamos nem mesmo trabalhar nele.
Valor pode ser definido com o 1nérito atr ibuído pelas partes interessadas aos deli-
verables do projeto.
Cada parte interessada possui uma definição de va lor diferente. Além disso, o va-
lor real pode ser expresso etn termos qualitativos etn vez de puramente quantitativos.
Simplesmente, pode não ser possível quantificar o valor real.
Vale enfatizar a importância do co1nponente de va lor. Considere as seguintes de-
clarações: concluir um projeto dentr o do prazo e do orçamento não garante o sucesso
se você estiver tra ba lhando no projeto errado; ter a mel ho r metodologia de gestão
de projetos empresarial do mundo não pode garantir que haverá valor no final do
proJeto.
Tripla restrição
Figura 16-1 Definição de sucesso.

• Conclu ir um projeto dent ro do prazo e do o rçamento não garante que o projeto

terá gerado valor em sua conclusão.
Essas t rês declarações nos leva tn a crer que talvez o va lor seja hoje o fator domi-
nante na seleção de utn portfólio de projetos. Os solicitantes de um projeto hoje têm
de articular clara tnente o cotnponente de valor no caso de negócios do projeto ou
correr o risco de o projeto não ser considerado.
16.1 Valor no decorrer dos anos

Surpreendentemente, inúmeras pesquisas sobre va lor ocorreram nos últimos 15 anos.
Alguns dos itens abordados etn pesquisas incluetn:
• A dinâmica do valor
• Análise de lacunas do valor
• Valoração do capital intelectual
• Valoração do capital hu1nano
• Análise econõ1nica baseada em valor
• Fluxos de valor intangíveis
• Gerenciatnento/mapeamento do valor de cl iente
• Matriz do valor competitivo
• Análise da cadeia de valor
• Valoração de projetos de TI
• Indicadores balanceados de desempenho (balanced scorecard)
A evolução do con hecin1ento baseado en1 valor parece seguir o fluxogratna da
Figura 16- 2. Aparentemente, pesquisas são relevantes em un1a área específica co1no
calcular o va lor de projetos de desenvolvimento de software ou calcular o va lor ao
acionista. Os resultados dessas pesquisas nonnaltnente são um 1nodelo que é apresenta-
do ao n1ercado para aceitação, rejeição e/ou crítica. Logo outros seguirão com modelos
sin1 ilares, ,nas na 1nesma área de pesquisa, con10 desenvolvi1nento de software. Utna
vez que a aceitação pelo mercado concorde sobre a validade desses 1nodelos, co1neçan1
a surgir livros didáticos discutindo os prós e os contras de un1 ou mais dos modelos.
Com a aceitação dos modelos em u1na área específica, a modelagem, então, espa-
lha-se para out ras áreas. O processo do fluxograma continua até que d iversas áreas
tenha passado pela 1nodelagem. Uma vez que isso tenha sido concluído, surgem livros
Não
Pesquisa em Modelagem de ~ itação

uma área + uma área pelo
específica específica mercado
1 s-------------J
, Sim
Uvros didáticos
específicos da área
Criação de
um modelo
genérico (MMV)
! Uvros
didáticos
genéricos
Figura 16-2 Evolução do conhecimento baseado em valor.

Capítulo 16 Gestão de projetos orientada a valor 715
didáticos sobre a modelagem genérica de valor para uma variedade de aplicações. A

lista a seguir contém alguns dos modelos que ocorrera tn nos últi1nos 15 anos:
• Valoração do capita l intelectual
• Pontuação da propriedade intelectual
• Indicadores bala nceados de desempenho (balanced scorecard)
• Gerenciamento de valores futuros (F11t11re Va/11e Management'.")
• Classificação do Capita l Intelectual (/ ntellectual Capital Rating°..,.')
• Modelagem do fluxo de valores intengíveis
• Mensuração Inclusiva de Valores (Inclusive Va/11e MeasttrementTM)
• Estrutura de desetnpenho de valores
• Metodologia de Mensuração de Valores (MMV)
Mu itos desses modelos possuem características con1t1ns entre si, de modo que eles
podem ser aplicados à gestão de projetos. Por exen1plo, Jack Alexander criou un1 mo-
delo chamado de "Estrutura de Desempenho de Valores" (VPF, Value Perforrnance Fra-
1nework). O n1odelo é exibido na Figura 16-3. Ele prioriza construir (hui/d) valor ao
acionista en1 vez de criar (create ) valor ao acionista.' O modelo se incl ina fortemente na
direção dos indicadores-chave de desempenho (KPis). entretanto, os elementos-chave do
VPF podem ser aplicados à gestão de projetos, como indicado na Tabela 16-1. A primei -
ra coluna contén1 os elementos-chave do VPF do livro de Jack Alexander, e a segu nda
2
coluna ilustra a aplicação à gestão de projetos.
A chave para se maximizar o valor ao acionista de forma sustentável no longo prazo é

identificar e aprimorar os fatores determinantes críticos do desempenho do valor.
A Estrutura de Desempenho de Valores (VPF) integra os princípios econômicos fundamentais

de valoração, aprimoramento de processos, planejamento e seguimento da execução e
medidas de desempenho para construir valor para as partes interessadas:
Estrutura de Desempenho de Valores (VPF)
1 Ferramentas 1 Objetivos 1Metas

Fun!lamentos da Identificar fatores determinantes Maximizar o valor ao
valoração do valor da empresa acionista no longo prazo
Fatores determinantes Traduzir as metas e a estratégia !la
de valor empresa em planos mensuráveis 1Satisfação do cliente
Qualidade e melhoria Associar o valor às atividades Desenvolvimento,
de processos realizadas pelos funcionários empregabilidade e
1Medidas de desempenho 1 Identificar e captar oportunidades satisfação dos
de aprimoramento com alta funclonár',os
1Execução
alavancagem
1Modelo de negócios 1 Planejar e realizar iniciativas-chave
Benchmarklng/ Melhorar a visibilidade e a
Melhores práticas responsabílldade
Figura 16-3 O modelo VPF. Fonte: J. Alexander, Performance Oashboards and Ana/ysis
for Va/ue Creation, Hoboken, NJ: Wiley, 2007, p. 5. Reproduzido com permissão da John
Wiley & Sons.
1
J. Alexander, Performance Dashboards and Analysis for Value Creation, Hoboken, NJ: \Viley, 2007, p. 5 .
Reproduzido com permissão da John Wiley & Sons.
2
lbid., p. 6.
TABELA 16-1 Aplicação do VPF à gestão de projetos

Elemento do VPF Aplicação à gestão de projetos
Compreender os princípios chave da valoração Trabalhar com as partes interessadas do projeto para
definir valor
Identificar os principais fatores determinantes de valor Identificar os principais fatores determinantes de valor
para a empresa para o projeto
Avaliar o desempenho e medidas em prooessos de Avaliar o desempenho da metodologia da gestão de
negócio cruciais por meio da avaliação e do bench- projetos empresarial e de melhorias continuas usando
marl<ing extemo o PMO
Criar uma ligação entre o valor ao acionista e os Criar uma ligação entre valores de projetos, valores de
processos de negócios cruciais e atividades de fun- partes interessadas e valores de membros de equipes
cionários
Alinhar as metas dos funcionários e da corporação Alinhar as metas dos funcionários, do projeto e as me-
tas corporativas
Identificar os principais "pontos de pressão" (oportuni- captar lições aprendidas e melhores práticas que
dades de melhorias de alta alavancagem) e estimar o possam ser usadas para atividades de melhorias
impacto potencial sobre o valor contínuas
Implementar um sistema de gerenciamento de desem- Estabelecer e implementar uma série de dashboards
penho para melhorar a visibilidade e a responsabHid a- ou dashboards baseados em projetos para maior
de em atividades cruciais visibilidade para cliente e partes interessadas dos
indicadores-chave de desempenho
Desenvolver dashboards de desempenho com um alto Desenvolver dashboards de desempenho para maior
nível de impacto visual visibilidade das partes interessadas, da equipe e da
gerência sênior
Fonte: J. Alexander, Performance Oashboa.rds and Analysis for Value Creation, Hoboken, NJ: Wiley, 2007, p. 6. Reprodu·
zido com permissão da John Wiley & Sons.
16.2 Valores e liderança

A i1nportância do va lor pode ter um impacto significativo no estilo de liderança dos
gerentes de projetos. Historicamente, a liderança em gestão de projetos era percebida
como o confl ito inevitável entre va lores individua is e valores organizacionais. Hoje,
as empresas estão procur ando fonnas de fazer os funcionários a linharem seus valores
pessoa is aos da organização.
Vários livros já foram escritos sobre esse assu nto, e o mel ho r deles, na opinião
deste autor, é Balancing Individual and Organizationa/ Values, de Ken Hu ltman e Bill
3
Gellerman. A Ta bela 16- 2 mostra como nosso conceito de valor mudou ao longo dos
4
anos. Se você o bservar de perto os itens da Tabela 16- 2, poderá ver que mudanças
nos valores afeta tn ma is do que apenas os valores indivi duais versus organizacionais.
Em vez disso, é mais provável que tais mudanças sejam um confl ito de quatro grupos,
como mostra a Figura 16-4. As necessidades de cada grupo podem ser:
• Gerente de projetos
• Alcance de objetivos
• Demonstração de criatividade
• Demonstração de inovação
• Membros de equipe
• Rea lização
3
K. Hulanan e B. Gellerman, Balanâ ng Individual and O rganizationa l Va lues, San Francisco: Jossey•Bass/
Píeiffer, 2002.
' lbid., p. 105- 106.
• Aprimoramento
• Ambição
• Credenciais
• Recon hecimento
• O rganização
• Melhorias contínuas
• Aprend izage1n
• Qualidade
• Foco estratégico
• Moralidade e ética
• Lucratividade
• Recon hecimento e image1n
• Partes interessadas
• Partes interessadas organ izacionais: segurança no e1nprego
• Partes interessadas em produtos/mercado: desempenho de alta qualidade e uti-
lidade dos produtos
• Mercados de capita is: crescimento fi nanceiro
TABELA 16-2 Mudanças nos valores
Afastando-se de: Valores ineficientes Aproximando-se de: Valores eficientes

Falta de confiança Confiança
Descrições de cargo Modelos de competência
Poder e autoridade Trabalho em equipe
Foco interno Foco nas partes interessadas
Segurança Assumir riscos
Conformidade Inovação
Previsibilidade Flexibilidade
Concorrência interna Colaboração interna
Gerenciamento reativo Gerenciamento proativo
Burocracia Ausência de limites
Educação tradicional Educação ao longo de toda a vida
liderança hierárquica liderança multidirecional
Pensamento tático Pensamento estratégico
Conformidade Comprometimento
Cumprir padrões Melhorias contínuas
Fonte: Adaptado de K. Hultman e 8 . Gellerman, Balancing Individual Organizational Values , San Francisco:
Jossey-Bass/Pfeiffer, @ 2002.
Valores Conflitos Valores

individuais organizacionais
Valores da Valores das partes

equipe interessadas
Figura 16-4 Conflitos de valor em gestão de projetos.

Há vários 1notivos pelos qua is o papel do gerente de projetos e o esti lo de lideran-

ça que o acompanha mudara1n. Alguns deles incluem:
• Agora estamos gerenciando nosso negócio como se ele fosse u1na série de projetos.
• A gestão de projetos hoje é vista como uma profissão realizada em regime de
tempo integral.
• Os gerentes de projetos agora são vistos como gerentes de negócios e gerentes de
projetos, e espera-se que eles tomem decisões em ambas as áreas.
• O va lor de um projeto é med ido em termos de negócios em vez de somente em
tennos técnicos.
• A gestão de projetos agora está sendo aplicada a partes do negócio que tradicio-
nalmente não a empregavam.
O último item exige um co1nentário. A gestão de projetos funciona bem para o
tipo de projeto "tradicional", que inclui:
• Tempo de duração de 6 a 18 meses.
• Não se espera que as premissas mudem ao longo da duração do projeto.
• A tecnologia é conhecida e não mudará ao longo da duração do projeto.
• As pessoas que começarem no projeto continuarão nele até sua conclusão.
• A declaração de trabalho é razoavelmente betn definida.
lnfeliz1nente, os tipos de projetos ma is recentes são mais não t radiciona is e pos-
suem as seguintes características:
• Tempo de duração de vários anos.
• As premissas podem e irão mudar ao longo da duração do projeto.
• A tecnologia irá mudar ao longo da duração do projeto.
• As pessoas que aprovaram o projeto podem não estar presentes na sua conclusão.
• A declaração de trabalho é mal definida e está sujeita a inúmeras mudanças.
Os tipos de projetos não tradicionais deixaram claro por que a gestão de projetos
t radicional precisa mudar. Há t rês áreas que necessitam de mudanças:
• Os novos projetos passara1n a ser:
• Extremamente complexos e com maior aceitação de riscos que podetn não ser
tota lmente compreendidos durante sua aprovação
• Mais incertos em seus resultados e sem garantia de valor no fina l
• Pressionados para acelerar a velocidade de colocação no mercado, independen-
te1nente dos riscos
• A especificação de t raba lho (ET):
• Nem sempre é bem definida, especiahnente em projetos de longo prazo
• Baseia-se em premissas possivelmente fa lhas, irraciona is ou não realistas
• Desconsidera condições econõmicas e ambienta is desconhecidas ou em rápida
mudança
• Baseia-se em um alvo estático e1n vez de dinâmico para o valor final
• Os siste1nas de gerencia1nento e cont role de custos [metodologias empresariais de
gestão de projetos (EPM)] focal izam-se etn:
• Uma situação idea l (como no G11ia PMBOK"')
• Teorias, em vez de na compreensão do fluxo de trabalho
• Processos inflexíveis
• Relatórios periódicos de prazo de conclusão e custo total na conclusão, mas não
em valor (ou benefícios) na conclusão
• Continuação em vez de cancelamento de projetos co1n valor limitado ou sem
nenhum va lor
Ao longo dos anos, demos vários pequenos passos e1n d ireção a planejar o uso do
gerenciamento em projetos não tradiciona is. Eles incluem:
• Os gerentes de projetos têm 1na is conhecimentos de negócios e podem opinar du-
rante o processo de seleção de projetos.
• Devido ao item anterior, os gerentes de projetos são trazidos ao projeto no início
da fase de iniciação em vez de no fim dela.
• Os gerentes de projetos agora pa recem apenas ter uma breve compreensão da
tecnologia em vez de dominá-la.
Os novos tipos de projetos combinados com um forte foco sobre o alin hamento
de negócios e valor trouxera1n consigo um sistema de classificação, como mostra a
Figura 16-5.
• Projetos operacionais: Esses projetos, em sua grande maioria, são projetos repeti-
tivos como folhas de pagamento e impostos.
Eles são chamados de "projetos", mas são gerenciados por gerentes funcionais
sem o uso da metodologia de gestão de projetos e1npresarial.
• Projetos internos 011 de rnelhorias: São projetos criados para atual izar processos,
melhorar a eficiência e a eficácia e, possivehnente, au1nentar o moral.
• Projetos financeiros: As e1npresas exigem alguma forma de fluxo de caixa pa ra
sua sobrevivência. Esses são projetos para clientes externos à empresa e têm uma
margem de lucro a eles atribuída.
• Projetos relacionados ao futuro: São projetos de longo prazo destinados a produ-
zir um fluxo futuro de produtos ou serviços capazes de gerar um fluxo de caixa
futuro. Esses projetos podem significar uma enorme perda bruta de exploração
(cash drain ) durante anos, sem nenhuma garantia de sucesso.
• Projetos relacionados aos clientes: Alguns projetos podem ser real izados, mesmo
com uma perda financei ra, para manter ou constru ir uma relação com o cliente.
Entretanto, realizar um número grande dema is desse projetos pode levar ao de-
sast re financeiro.
Esses novos tipos de p rojetos foca liza1n -se mais no va lor do que na t ripla restr i-
ção. A Figura 16-6 most ra a t ripla restrição tr adicional, enquanto a Figura 16-7 mos-
tra a tr ipla restrição di recionada o rientada por va lor. Com a restrição t ripla orientada
Projetos operacionais
Projetos relacionados Projetos de

ao futuro melhorias
Projetos de Projetos
relacionamento financeiros
com o cliente
Figura 16-5 Classificação de projetos.

por valor, enfatizamos a a satisfação das partes interessadas, e as decisões são to tnadas
em tomo dos quat ro tipos de projetos (excluindo os projetos operacionais) e o valor
que é esperado no projeto. Em outras palavras, sucesso é quando se obtém va lor,
preferenciahnente dentro da tripla restrição. Consequentemente, podetnos defin ir as
quatro bases do sucesso usando a Figura 16-8. Muito poucos projetos são concluídos
sem alguns trade-offs. Isso é válido tanto para os projetos tradicionais quanto para os
orientados por valor. Como mostra a Figura 16-9, os trade-offs tradiciona is resultam
no prolonga1nento do cronograma e um aumento no orçamento. O mestno é vá lido
para os projetos orientados por valor exibidos na Figura 16-10. A principa l diferença
é o desempenho. Com os trade-offs tradicionais, tendemos a reduzir o desetnpenho
para satisfazer outros requisitos. Com os projetos orientados por va lor, tendemos a
au1nentar o desetnpenho na esperança de fornecer ma is valor, e isso tende a causar
sobrecustos e desvios do cronogra tna muito maiores do que os trade-offs tradicio-
RECURSOS
DESEMPENHO/TECNOLOG IA
OU ESCOPO
Figura 16-6 Tripla restrição tradicional.
fiianoeiros fu1u:ros
Valores
Valoras
relacionados
inlernos ao cli@nle
DESEMPENHO/TECNOLOGIA
OU ESCOPO
Figura 16-7 Tripla restrição orientada a valor.

Sucesso Sucesso
financeiro no futuro
Sucesso
Sucesso relacionado
interno
ao cliente
Figura 16-8 As quatro bases do sucesso .
.6.P
/ --~A~--
/ \
Desempenho
Nota:.6.= Desvios do plano original
Figura 16-9 Trade-o/fs tradicionais.
Valores Valores
fwlanceiros lu'luros
Valores Va!ores
6P . relacionados
in1emos ao cliente
Desempenho
Nota: 6 = Desvios do plano original
Figura 16-10 Trade-o/fs orientados por valor.
nais. Os gerentes de projetos geralmente não detêm individualmente a autoridade para

realizar aumentos/d iminuições no escopo/desempenho. Para os trade-offs t radicionais,
os gerentes de projetos e o patrocinador do projeto, trabalhando juntos, podem ter a
autoridade para tomar decisões envolvendo trade-offs.
No entanto, para projetos o rientados por valor, todas ou quase todas as partes in-
teressadas podem precisar ser envolvidas. Isso pode criar problemas ad icionais, co1no
por exe1nplo:
• Pode não ser possível fazer todas as partes interessadas concorda rem com um
valor-a lvo durante a iniciação do projeto.
• Conseguir um acordo sobre mudanças no escopo, custos extr as e prolongamentos
no cronograma é significativa1nente ma is difícil quanto 1nais você tiver avançado
no cronograma do projeto.
• As partes interessadas devem ser informadas disso na iniciação do projeto e con-
tinuamente atua lizadas à medida que o projeto progred ir, isto é: sem surpresas!
Podem ocorrer confli tos entre as pa rtes interessadas. Por exemplo:
• Durante a iniciação do projeto, conflitos entre pa rtes interessadas normahnente
são resolvidos a favor dos maiores contribuidores financeiros .
• Durante a execução, confl itos sobre valor futur o são ma is co1nplexos, especia l-
mente se contribuidores importantes ameaçare1n abandonar o projeto.
Para projetos que possuem um grande número de partes interessadas, o patrocí-
nio do projeto pode não ser eficiente com u1n único pat rocinador. Portanto, pode ser
necessário um com itê de patrocín io. A participação do comitê pode incluir:
• Talvez u1n representante de todos os grupos de partes interessadas
• Executivos i1ú luentes
• Parceiros estratégicos e cont ratadas crucia is
• Outros, dependendo do tipo de valo r
As responsabilidades do comitê de patrocínio podem incluir:
• Assu1n ir um papel de liderança na defin ição do valor em questão
• Assu1n ir um papel de liderança na aceitação do valor real
• Ter capacidade de fornecer financiamento adiciona l
• Ter capacidade de aval iar mudanças nos fatores ambientais da etnpresa
• Ter capacidade de validar e revalidar as prem issas
Os comi tês de pat rocínio podem ter muito mais experiência do que o gerente de
projetos para defin ir e avaliar o valor de um projeto.
Projetos orientados por valor exige1n que pa remos de foca lizar em orça1nentos
e cronogramas e, em vez disso, passemos a foca lizar em como o valor será captado,
quantificado e reportado. O va lor deve ser medido e1n termos de com que o p rojeto
contr ibui para se alcançar os objetivos da etnpresa. Para tal, é necessário compreender
quatro termos.
• Benefícios: uma vantagem.
• Valor: quanto vale o benefício.
• Fatores detern1inantes de negócios: metas ou objetivos definidos por n1eio de
benefícios ou valor e expressos n1ais em tern1os de negócios do que em tern1os
técn icos.
• Indicadores-chave de desempenho (KPls): métricas de va lor que podetn ser avalia-
das quantitativa ou qual itativa1nente.
C apítulo 16 Gestão de projetos orientada a valor 723
Tradicionalmente, os planos de negócios identificavam os benefícios esperados

do projeto. Hoje, as técnicas de gerenciamento de portfólio exigem a identificação do
valor além dos benefícios. Entretanto, a conversão de benefícios em va lor não é fáci l. 5
A Tabela 16-3 ilustra a conversão de benefício em valor. Além disso, co1no most ra a
Figura 16-11, há limites no processo de conversão que podem dificultá-lo.
É necessário identificar os fato res determinantes de negócios, e eles devem ter in-
dicadores de desempen ho mensu ráveis usando KP!s. Deixar de fazê-lo Ílnpossibilita a
verdadeira avaliação do va lor. A Tabela 16-4 ilust ra típicos fatores determ inantes de
negócios e seus KP!s associados.
Necessário assumir um Validade das

número excessivo de premissas
premissas questionável
Mensuração em Deixar de medir

nível alto demais Limites
mudanças
/ "'-
Pessoas erradas Ausência de métodos
fazendo a mensuração legítimos disponíveis
Figura 16-11 Limites.
TABELA 16-3 Medír valor a partír de benefícíos
Benefícios esperados Conversão em valor

Lucratividade Fácil
Satisfação do cliente Difícil
Boa vontade Difícil
Penetrar novos mercados Fácil
DesenvolVer novas tecnologias Médio
Transferência de tecnologia Médio
Reputação Difícil
Estabilizar a força de trabalho Fácil
Utilizar capacidade ociosa Fácil
TABELA 16-4 Fatores determínantes de negócios e o KPI
Fatores determinantes de negócios Indicadores-chave de desempenho

Aumento das vendas Vendas mensais ou participação de mercado
Satisfação do cliente Pesquisas mensais
Economias de custo Sistema de mensuração de valor agregado
Melhoria de processo Cartões de controle do tempo
5
Para informações mais deralhadas sobre as complexidades da conversão, ver J. J. Phillips, T. W. Bochell e
G. L. Snead, T/,e Project Management Scorecard, Oxford, UK: Butterworch Heinemann, 2002, Chaprer 13.
Os KPis são métricas para se avaliar o va lor. Com a gestão de projetos tradicional,
as métricas são estabelecidas pela sua 1netodologia e fixas por toda a duração do ciclo
de vida dos projetos. No entanto, com a gestão de projetos orientada por valor, as
métricas podem mudar de um projeto para o outro, durante u1na fase do ciclo de vida
e ao longo do tempo, devido a:
• O modo como a empresa define valor internamente
• O modo como o cliente e a contratada definem sucesso e valor conjuntamente na
iniciação do projeto
• O modo como o cliente e a contratada chega1n a um acordo na iniciação do proje-
to quanto às métricas que devem ser usadas em determ inado projeto
• Versões novas ou atualizadas de software de acompanhamento
• Melhorias na metodologia de gestão de projetos empresarial e do sistema de infor-
mações de gestão de projetos que o acotnpanha
• Mudanças nos fatores ambientais da empresa
Mesmo com as melhores 1nétricas possíveis, 1nedir valor pode ser difíci l. Alguns
valores são fáceis de 1nedir, enquanto out ros são mais difíceis. Os valores fáceis de
medir geralmente são chamados de va lores tangíveis, enquanto os difíceis são 1nuitas
vezes considerados intangíveis. A Tabela 16- 5 ilustra alguns dos va lores fáceis e difí-
ceis de medir. A Tabela 16-6 most ra alguns dos problemas associados à mensuração
tanto de valores difíceis quanto de fáceis.
Os elementos intangíveis agora são considerados por a lguns como 1nais importan-
tes do que os elementos tangíveis. Isso parece estar acontecendo em projetos de TI, em
que os executivos estão dando significativamente 1nais atenção a va lores intangíveis.
TABELA 16-5 Medindo valores

Valores fáceis (tangíveis) Valores difíceis (intangíveis)
Galculadoras de retorno sobre investimento (ROi) Satisfação dos acionistas
Valor presente líquido (VPL) Satisfação das partes interessadas
Taxa interna de retomo (TIA) Satisfação do cliente
Fluxo de caixa Retenção de funcionários
Período de recuperação do investimento Fidelidade de marca
Lucratividade Tempo de colocação no mercado
Participação do mercado Relações de negócios
Segurança
Confiabilidade
Reputação
Boa vontade
Imagem
TABELA 16-6 Problemas com a mensuração de valores

Valores fáceis (tangíveis) Valores difíceis (intangíveis)
As premissas muitas vezes não são reveladas e O valor quase sempre se baseia em atributos sub-
podem afetar a tomada de decisão jetivos da pessoa que está fazendo a mensuração
A mensuração é muito genérica Está mais para uma arte do que para uma ciência
A mensuração nunca capta os dados corretos de Há modelos limitados disponíveis para realizar a
forma significativa mensuração
O problema dos valores intangíveis não está necessaria1nente no resultado fina l, 1nas
6
no modo como fora 1n calculados.
Os valores tangíveis são normalmente expressos quantitativamente, enquanto os
valores intangíveis são expressos por meio de uma ava liação qua litativa. Há três esco-
las de pensamento para a 1nensuração de valor:
• Escola 1: A única coisa que é importante é o ROL
• Escola 2: O ROi nunca pode ser calculado eficientemente; somente os intangíves
são importantes.
• Escola 3: Se não dá para ser medido, então é porque não importa.
As três escolas de pensa1nento parecem ter u1na abordage1n do tipo "tudo ou
nada", na qual o valor é ou 100% quantitativo ou 100% qual itativo. A melhor abor-
dagem é, mais provaveltnente, um co1npromisso entre uma ava liação quantitativa e
uma avaliação qual itativa de valor. Pode ser necessário estabelecer uma extensão efi-
ciente, como 1nostra a Figura 16- 12, que é um compromisso entre as três escolas de
pensamento. A extensão eficiente pode se expandir ou se cont rair.
O momento escolhido para a mensuração de valor é absolutamente decisivo. Du-
rante o ciclo de vida de u1n projeto, pode ser necessário passar várias vezes de u1na
aval iação qua litativa para quantitativa e vice-versa, e, como d ito anteriormente, as
métricas reais ou KPis também podem mudar. Certas questões importantes precisa1n
ser abordadas:
• Quando ou até que ponto do ciclo de vida do projeto podemos estabelecer mét ri-
cas concretas, supondo que isso possa ser feito, em primeiro lugar?
• O valor pode ser simplesmente percebido e, portanto, não ser necessária nenhu1na
métrica de valor?
• Mesmo se tivermos métricas de valor, elas são suficiente1nente concretas para pre-
ver razoavelmente o valor rea l?
• Seremos forçados a usar a gestão de projetos orientada por valor em todos os pro-
jetos ou há alguns projetos e1n que essa abordagem não é necessária?
100% 0%
Extensão
eficiente
Oual~ativa Quantitativa
Figura 16-12 Avaliação quantitativa versus qualitativa.
6
Para informações mais detalhadas sobre as complexidades da mensuração de intangíveis, ver nota 5, Ca~
pículo 10. Os autores enfatizam que o verdadeiro impacto sobre um negócio cem de ser medido em unidades
de negócios.
• Bem defin ido versus 1nal definido

• Estratégico versus tático
• Interno vers11s externo
• Podemos desenvolver um critério para quando usar a gestão de projetos orientada
a valor ou devemos usá-la em todos os projetos, mas com um nível de intensidade
mais ba ixo?
Para alguns projetos, avaliar o valor no encerramento pode ser difícil. Devemos
estabelecer um limite de quanto tempo esta tnos d ispostos a esperar para medir o valor
ou os benefícios de um projeto. Isso é particularmente importante se o valor real não
puder ser identificado até certo tempo depois de o projeto ter sido concluído. Portan-
to, pode não ser possível avaliar o sucesso de um projeto no encerramento se os valo-
res econômicos rea is não puderem ser rea lizados até certo tempo depois.
Alguns praticantes da mensuração de valor questionam se é melhor usar "caixas
delim itadoras" em vez de fases do ciclo de vida. Para projetos orientados por valor, os
problemas potenciais com as fases do ciclo de vida incluem:
• Métricas podem 1nudar ent re fases e até 1nesmo dent ro de uma mesma fase.
• Incapacidade de explicar 1nudanças nos fatores ambientais da empresa.
• O foco pode ser sobre o va lor no fim da fase etn vez de sobre o valor no fi ,n do
proJeto.
• Os mem bros de equipes podem ficar frustrados por não seretn capazes de calcular
valor quantitativamente.
As ca ixas deli1nitadoras, como exibe a Figura 16- 13, têm certo grau de sim ilari-
dade com gráficos de cont role de processos estatísticos. Estabelecem-se valores-alvo
estr atégicos como litnite superior e inferior. Contanto que os KPis indiquem que o
projeto ainda esteja dentro dos alvos superior e inferior, os objetivos e deliverables do
projeto não passarão por nenhuma mudança de escopo ou trade-off.
Projetos orientados por valor precisam passar por "verificações de saúde" para
confirmar que o projeto fará uma contribu ição de valor para a empresa. As métr icas
de valor, como os KPis, ind icam o valor corrente. Algo que também é necessário é uma
extr apolação do presente para o futuro. Usando a gestão de projetos t radicional junta-
mente com uma metodologia tradicional de gestão de projetos empresarial, podemos
calcular o prazo do projeto concluído e o custo do projeto concluído. Esses são termos
comuns que fazem parte dos sistemas de mensuração de valor agregado. Porém, co1no
d ito anteriormente, estar dentro do prazo e do orçamento não é nenhuma garantia de
que o valor percebido estará lá na conclusão do projeto.
Portanto, etn vez de usar uma metodologia de gestão de projetos empresaria l, que
se foca liza na mensuração do valor agregado, podetnos precisar criar u1na metodolo-
gia de mensuração de valores (MMV) que enfatiza as variáveis do valor. Com a MMV,
Valores-alvo superiores va1ores-a1vo

• Fluxo de caixa
• ROi
• Datas de entrega
• Métricas de
desempenho
Valores-alvo inferiores
Figura 16-13 A caixa delimitadora.

o prazo para conclusão e o custo para conclusão a inda são usados, mas introduzimos
um novo termo, intitulado valor (ou benefícios) do projeto concluído. A determinação
de valor na conclusão tem de ser feita periodicamente ao longo do projeto. Entretanto,
a reava liação periódica dos benefícios e valor na conclusão podem ser difíceis, porque:
• Pode não haver processo de reava liação.
• A gerência não está comprometida e acredita que o processo de reava liação não
é rea l.
• A gerência está excessivamente otimista e complacente com o desempenho atua l.
• A gerência está cega por lucros excepciona lmente altos em out ros projetos (tná
interpretação).
• A gerência acredita que o passado seja uma indicação do futuro.
Utna ava liaç.ã o de va lor na conclusão do projeto pode nos dizer se são necessários
trade-offs de valor.
Motivos para trade-offs de valor incluem:
• Mudanças nos fatores ambientais da empresa
• Mudanças nas premissas
• Melhores abordagens encont radas, possivelmente com menos risco
• Disponibil idade de trabalhadores altamente qualificados
• Descobertas tecnológicas
Como dito anteriormente, a maioria dos trade-offs de valor é acompanhada de
um prolongamento do cronograma. Dois fatores decisivos que devem ser considerados
antes de ocorrerem prolongamentos de cronograma são:
• Prolongar um projeto pelo valor desejado ou agregado pode gerar riscos.
• Prolongar um projeto consotne recursos que podem já estar comprometidos a
outros projetos do portfólio.
Ferramentas e técnicas tradicionais podem não funcionar bem em projetos orien-
tados por valor. A criação de uma MMV pode ser necessária para alcançar os resul-
tados desejados. Uma MMV pode incluir os ele1nentos de sistemas de mensuração de
valor agregado (SGVAs) e sistetnas de gestão de projetos empresarial (EPMs), como
mostra a Tabela 16-7. Porém, variáveis adicionais têm de ser incluídas para captar,
medir e reportar valor.
TABELA 16-7 Comparação de SGVAs, EPM e MMV

Variável SGVA EPM MMV
Prazo ./ ./ ./
Custo ./ ./ ./
Qualidade ./ ./
Escopo ./ ./
Riscos ./ ./
Tanglveis ./
Intangíveis ./
Benefícios ./
Valor ./
Trade-offs ./
Efeito das fusões e aquisições
na gestão de projetos
17.0 Introdução
Todas as empresas se empenham para crescer. Preparam-se planos est ratégicos iden-
tificando novos produtos e serviços a serem desenvolvidos e novos mercados a sere1n
penetrados. Muitos desses planos exigem fusões e aquisições para obter as metas e
objetivos estratégicos. Contudo, mes1no os planos est ratégicos mais betn preparados
muitas vezes falham. Muitos executivos vee1n o planejamento est ratégico apenas como
planejamento, não considerando a implementação. O sucesso da implementação é vi-
tal durante os processos de fusão e aquisição.
17.1 Planejamento para o crescimento

As empresas podetn crescer de duas maneiras: interna e externamente. Com o crescin1en-
to interno, as empresas cultivan1 seus recursos por dentro e podem passar anos atingindo
seus alvos estratégicos e seu posicionamento no mercado. Como o tempo pode ser um
luxo não disponível, é preciso ton1ar um cuidado n1eticu loso para garantir que todos os
novos progressos se adaptem à n1etodologia e à cultura da gestão de projetos corporativa.
O crescimento externo é significativa 1nente n1ais con1plexo. Ele pode ser obtido
por meio de fusões, aquisições e joint ventures. As e1npresas podem adquirir os conhe-
cin1entos especializados de que precisan1 muito rapidan1ente por n1eio de fusões e aqui-
sições. Algumas e1npresas executam aquisições ocasionais, enquanto outras têm acesso
suficiente a capita l, de forn1a que podem realizar aquisições frequentes. Entretanto,
mais u1na vez, as e1npresas muitas vezes deixam de considerar o i1npacto na gestão de
projetos. As n1elhores práticas em gestão de projetos podetn ser transferíveis de u1na
empresa para outra. O impacto nos sistemas de gestão de projetos resultante de fusões
e aquisições geralmente é irreversível, enquanto joint ventures podem ser canceladas.
Efeito de fu sões na gestão de projetos

Este capítulo d iscute o impacto de fusões e aquisições na gestão de projetos. As fusões
e aquisições permitem que as empresas atinjam a lvos est ratégicos a u1na velocidade
não facilmente alcançável por meio do crescimento interno, contanto que o compar-
ti lhamento de ativos e capacidades possa ser feito de maneira rápida e eficiente. Esse
efeito sinérgico talvez crie uma oportunidade que uma empresa pode estar sendo pres-
sionada a desenvolver.
Capítulo 17 Efeito das fusões e aquisições na gestão de projetos 729
As fusões e aquisições focalizan1 -se em dois con1ponentes: as ton1adas de de-

cisão pré-aquisição e os processos de integração pós-aquis ição. A \Vall Street e as
instit uições financei ras pa recen1 estar n1ais interessadas no in1pacto financeiro de
curto prazo do que no valor de longo prazo que pode ser a lcançado por meio de
uma n1elhor gestão de projetos e de processos integrados. Durante n1eados da dé-
cada de 1990, as en1presas fazian1 aquisições apressadas, em menos tempo do que
precisavam para uma aprovação de desembolso de capital. Pratican1ente nenhun1a
consideração era dada ao in1pacto na gestão de projetos e se as n1elhores práticas
esperadas seriam ou não transferíveis. O resultado parece ter sido mais fracassos
do que sucessos.
Quando uma empresa faz uma aquisição apressada, mu ito pouco tempo e esfor-
ços parece1n ser gastos na integração pós-aquisição. Contudo, é aí que o verdadeiro
impacto ou as mehores práticas são sentidas. linediatamente após uma aquisição, cada
empresa comercia liza e vende produtos para os cl ientes umas das outras. Isso pode
agradar os acionistas, mas somente no curto prazo. No longo prazo, novos produtos
e serviços precisarão ser desenvolvidos para satisfazer ambos os mercados. Sem u1n
sistema integrado de gestão de projetos, em que a 1nbas as partes possam co1nparti lhar
as mesmas melhores práticas, isso pode ser difícil de alcançar.
Quando tempo suficiente é gasto nas tomadas de decisão pré-aquisição, am bas as
empresas se dedicam a co1nbinar processos, compartilhar recursos, t ransferir proprie-
dade intelectua l e realizar o gerenciamento geral de operações combinadas. Se esses
problemas não forem abordados na fase de pré-aquisição, podem ocorrer expectativas
não realistas durante a fase de integração pós-aquisição.
17.2 Cadeia de valor agregado da gestão

de projetos
Espera-se que as fusões e aquisições agreguem valor à empresa e aumentem sua com-
petitividade geral. Algumas pessoas definem valor como a capacidade de manter de-
terminado fluxo de receitas. Uma defin ição melhor de valor pode ser as vantagens
co1npetitivas que uma empresa passa a possuir em decorrência da satisfação do cl iente,
diminuição dos custos, eficiências, ma ior qualidade, utilização eficiente do pessoal, ou
a implementação de mel hores práticas. O verdadeiro valor ocorre somente na fase de
integração pós-aquisição, bem depois da aquisição propriamente dita.
O valor pode ser anal isado por meio da anál ise da cadeia de valor: o fluxo de
atividades de fornecedores a 1nontante aos clientes a jusante. Cada componente da
cadeia de valor pode fornecer uma vantagem co1npetitiva e apriinorar o deliverable ou
serviço final. Cada empresa possui uma cadeia de valor, como ilustra a Figura 17- 1.
Quando uma empresa adquire u1na empresa fornecedora, as cadeias de valor são com-
binadas, e espera-se que elas crie1n u1na posição co1npetitiva superior. Espera-se o
mesmo resultado quando u1na empresa adquire uma e1npresa a jusante. No entanto,
pode não ser possível integrar as melhores práticas.
Historica1nente, a aná lise de cadeia de valor era usada para se analisar o negócio
como um todo.' Ent retanto, no restante deste capítu lo, o único foco será a cadeia
de valor agregado da gestão de projetos e o impacto das fusões e aquisições sobre o
desempenho da cadeia. A Figu ra 17- 2 mostra a cadeia de valor agregado da gestão
1
M. E. Porter, ComperWve Advantage, New York: Free Press, 1985, Chap. 2.
Cadeias de Cadeias de valor Cadeias de

valor a montante da empresa valor a jusante
Sistemas Sistemas,
Sistemas, internos, produtos,
produtos, produtos, Consumidor,
lucros e cadeia de
lucros e métodos, métodos de
métodos dos custos e valor do
parceiros de usuário
fornecedores lucros canais adiante
Integração a Fusões Integração a Benefícios

jusante: montante: adicionados
compra de Integrações para os
compra de
empresas Aquisições empresas consumidores
fornecedoras distribuidoras
Figura 17-1 Cadeia genérica do valor agregado.
li--* lnlegraçlo Escopo Prazo

l
Contf313ção
l .
ll--*7de fornecedor >--7~ Custo Risco
i
li--~ Recursos >--~ ~ Qualidade >-~ Comunicação
humanos
Fornecedores::J--::::::::::::::::::::::::._....::::::===:::_-~====::'.:_....,J
Processos organizacionais / Clientes
as 9 áreas da 4! edição do Guia PMBO~)
~--------.----<
Infraestrutura de suporte
Atividades
de suporte
(metodologia de GP, SIGP, TOM, etc.) \
Gerenciamento de recursos humanos: carreira e treinamento \ ~
da empresa DesenvoMmento de tecnologias: otensiva versus defensiva \ ~ç...
Contratação de fornecedores: qualidade dos fornecedores e serviços) f
Atividades Encerra- / A/
primárias Iniciação Planejamento Execuçlo Controle mento do s
do projeto do projeto do projeto do projeto do projeto ,/
projet}
Atividades primárias
Figura 17-2 Cadeia de valor agregado da gestão de projetos.
de projetos. As principa is atividades são os esforços necessários para a criação física

de um produto ou serviço. As atividades primárias podetn ser consideradas as cinco
principais áreas de processos da gestão de projetos: iniciação, planejamento, execução,
controle e encerramento de projetos.
As atividades de suporte são os esforços exigidos pela empresa necessários para
que as atividades primárias possam ocorrer. No mín imo absoluto, as atividades de
suporte têm de incluir:
• Gerencia,nento de contratações: A qualidade dos fo rnecedores e dos produtos e
serviços que eles fornecem à empresa.
• Efeito de fusões e aquisições na gestão de projetos: A capacidade de combina r

mú ltiplas abordagens de gestão de projetos, cada uma e1n um diferente nível de
matu ridade.
• Desenvolvimento tecnológico: A qua lidade da propriedade intelectual controlada
pela empresa e a capacidade de aplicá-la a produtos e serviços tanto ofensivamen-
te (desenvolvimento de novos produtos) quanto defensivamente (melhorias e1n
produtos existentes).
• Gerenciamento de recursos humanos: A capacidade de recrutar, contratar, treinar,
desenvolver e reter gerentes de projetos. Inclui a retenção de propriedade intelecu-
ta l em gestão de projetos.
• Infraestrutura de suporte: A qua lidade dos sistemas de gestão de projetos neces-
sários para integrar, reun ir e responder a dúvidas sobre o desempenho do projeto.
Incluídos na infraestrutura de suporte estão a metodologia de gestão de projetos,
os sistemas de informação de gestão de projetos, o siste1na de gestão da qualidade
tota l e outros sistemas de suporte. Como a interface com o cliente é essencia l, a in-
fraestrutura de suporte também pode incluir processos para um contato eficiente
entre fornecedor e cliente.
Essas quatro atividades de suporte podem ser ainda subdivididas em nove das dez
áreas de conhecimento do Guia P1WBOK®. As setas que conectam as nove áreas do
Guia PMBOK® indicam como estão interrelacionadas. As interrelações exatas pode1n
variar para cada projeto, deliverable e cl iente.
Cada uma dessas atividades prÍlnárias e de suporte, juntamente com as nove áreas
de processos, é necessária para converter o material recebido de seus fornecedores e1n
deliverables para seus clientes. Teoricamente, a Figura 17- 2 representa u1na estrutura
ana lítica do projeto para uma cadeia de va lor agregado de gestão de projetos:
• Nível 1: Cadeia de valor
• Nível 2: Atividades primárias
• Nível 3: Atividades de suporte (que podem incluir a área de conhecimento Geren-
cia1nento das Partes Interessadas)
• Nível 4: Nove das dez áreas de conhecimento do Guia PMBOK®
A cadeia de valor agregado da gestão de projetos permite que uma empresa iden-
tifique fraquezas críticas quando melhorias precisam ocorrer. Isso pode incluir u1n
melhor controle das mudanças no escopo, a necessidade de ma ior qual idade, maior
rapidez na geração de relatórios de status, melhor relacionamento com o cliente ou
melhor execuç.ã o de projetos. A cadeia de valor agregado também pode ser úti l para o
gerenciamento da cadeia de suprÍlnentos. A cadeia de valor agregado da gestão de pro-
jetos é uma ferramenta vital para os esforços de melhorias contínuas e pode facilmente
levar à identificação de mel hores práticas.
Os executivos consideram o custeio de p ro jetos como um componente crucial da
gestão de projetos, se não o mais crucial de todos. A cadeia de valor da gestão de proje-
tos é uma ferra 1nenta para compreender a porção referente à estrutura de custo de um
projeto da metodologia de gestão de projetos. Na maioria das empresas, é considerada
como u1na 1nelhor prática. Ações que visam a eli1ninar ou reduzir uma desvantage1n
no custo ou no cronograma precisa1n ser associadas à localização na cadeia de valor
em que as diferenças de custo ou cronogra1na se originaram.
O "cimento" que une os elementos dentro da cadeia de gestão de projetos é a sua
metodologia. Un1a n1etodologia de gestão de projetos é um agrupamento de formulá-
rios, diretrizes, listas de verificaç.ão, políticas e procedimentos necessários para integrar
os elementos dentro da cadeia de valor agregado da gestão de projetos. Pode haver uma
metodologia para un1 processo individual, co1no a execução de projetos ou para uma
con1binação de processos. Uma empresa pode tam bém criar sua metodologia de gestão
de projetos para n1elhor interface com organizações a n1ontante ou a jusante na cadeia
de valor agregado. Uma integração ineficiente nos pontos de interface entre fornecedor
e cl iente poden1 ter um sério i1npacto sobre o gerenciamento da cadeia de suprin1entos e
sobre os negócios futuros da en1presa.
17.3 Tomada de decisões pré-aquisição

O motivo da maioria das aqu isições é satisfazer u1n objetivo est ratégico e/ou finan-
ceiro. A Tabela 17- 1 most ra os seis motivos 1na is comuns pa ra uma aquisição e seus
objetivos est ratégicos e financei ros mais prováveis . Os objetivos estratégicos são de
mais longo prazo do que os o bjetivos financeiros, que sofrem a pressão dos acion istas
e credores que desejam obter retornos rápidos.
Os benefícios de longo prazo das fusões e aquisições incluem:
• Economias de operações co1nbinadas
• Oferta ou de1nanda garantida por produtos e serviços
• Propriedade intelectual ad icional, que poderia ter sido impossível de obter de ou-
tra forma
• Controle d ireto sobre custo, qual idade e cronograma em vez de estar à mercê de
um fornecedor ou distribuidor
• C riação de novos produtos e serviços
• Pressão sobre os concorrentes por 1neio da criação de sinergias
• Corte de custos por meio da eliminação de passos duplicados
Cada um desses benefícios pode gerar d iversas melhores práticas.
O propósito essencia l de qualquer fusão ou aquisição é cria r va lor duradouro que
se torna possível quando duas empresas são com binadas e que não existiria separa-
da1nente.
Alcançar esses benefícios, assim co1no atingir os objetivos estratégicos e financei-
ros, pode depender diretamente de quão bem as cadeias de valor agregado de gestão
de projetos de a 1nbas as empresas se integram, especialmente as metodologias dentro
de suas cadeias. A 1nenos que as metodologias e as culturas de ambas as empresas
possam ser integradas, e de forma razoavelmente rápida, os objetivos talvez não sejam
atingidos como o planejado.
TABELA 17-1 Tipos de objetivos

Motivo para aquisição Objetivo estratégico Objetivo finance iro
Aumentar a base de clientes Maior participação de mercado Maior fluxo de caixa
Aumentar capacidades Oferecer soluções Margens de lucro mais amplas
Aumentar a competitividade Eliminar passos onerosos Ganhos estáveis
Diminuir tempo de colocação no mercado Liderança de mercado Crescimento dos ganhos
(novos produtos)
Diminuir tempo de colocação no mercado Unhas de produtos amplas Ganhos estáveis
(melhorias de produtos existentes)
Mais próximo dos clientes Melhor mix de preço-qualidade- Contratação de fornecedor único
-serviço
Fracassos de integraç.â o em gestão de projetos ocorrem após a ocorrência de u1na

aqu isiç.ã o. Fracassos típicos são exibidos na Figura 17-3. Esses fracassos comuns ocor-
rem porque as fusões e aquisições simplesmente não podem acontecer sem mudanças
organizacionais e cultura is que, muitas vezes, são perturbadoras por natureza. Melho-
res práticas podem se perder. Infelizmente, as empresas muitas vezes se apressam em
fazer fusões e aquisições na velocidade da luz, mas co1n pouca consideração quanto a
como as cadeias de valor agregado da gestão de projetos serão combinadas. Planejar
uma 1nelhor gestão de projetos é de suma importância, mas, infelizmente, muitas vezes
- ,
nao e o que ocorre.
A primeira área problemática comum na Figura 17- 3 é a incapacidade de com-
binar metodologias dentro das cadeias de valor agregado de gestão de projetos. Isso
ocorre devido a:
• Uma má compreensão das práticas de gestão de projetos u1nas das outras antes
da aquisição
• Uma ausência de direção clara durante a fase pré-aquisição quanto a como a in-
tegração ocorrerá
• Uma liderança não comprovada na gestão de projetos em uma ou em ambas as
empresas
• U1na atitude persistente de "nós-eles"
Algumas metodologias podem ser tão complexas que uma grande quantidade de
tempo é necessária para que ocorra integração, especialmente se cada organização
possuir um diferente conjunto de clientes e diferentes tipos de projetos. Por exe1nplo,
uma e1npresa desenvolveu u1na metodologia de gestão de projetos para fornecer pro-
dutos e serviços para grandes empresas de capita l aberto. A empresa adquiriu, então,
uma pequena etnpresa que vendia exclusivamente para agências governamentais. A
empresa percebeu tarde dema is que a integração das 1netodologias seria quase impos-
sível devido às exigências i1npostas pelas agências governa1nenta is para fazer negócio
com o governo. As 1netodologias nunca fora 1n integradas, e a empresa que atendia os
Motivos para aquisições
Integração de
duas culturas
Disparidades
Diminuir o tempo de salariais
colocação no mercado
ara novos rodutos
Diminuir o tempo de Superestimação
colocação no mercado das capacidades
ara melhorias
Aproximar-se Fracassos
do cliente de liderança
Figura 17-3 Áreas problemáticas da gestão de projetos após uma aquisição.

clientes governamentais pode funciona r como subsidiária, com seus próprios produtos
e serviços especializados. A sinergia esperada nunca ocorreu.
Algumas 1netodologias simplesmente não podem ser integradas. Pode ser ma is
prudente permitir que as organizações funcionem separadamente do que perder opor-
tunidades no mercado. Nesses casos, podem existir "bolsões" de gestão de projetos
como entidades separadas, espalhados por u1na grande corporação.
A segunda maior área problemática na Figura 17- 3 é a existência de d iferentes
cu lturas. Embora a gestão de projetos possa ser vista como uma série de processos re-
lacionados, é a cultura em vigor na organização que, em última aná lise, deverá execu-
tar esses processos. Resistência pela cultura corporativa em oferecer o devido suporte
à gestão de projetos pode efetiva1nente fazer com que os 1nelhores planos fracassem.
Fontes de proble1nas com diferentes culturas incluetn:
• Uma cultura em uma ou ambas as empresas que possua conhecimentos limitados
sobre gestão de projetos (i.e., competências faltantes)
• Uma cu ltura que seja resistente a mudanças
• Uma cu ltura que seja resistente à transferência de tecnologia
• Uma cultura que seja resistente à transferência de qualquer tipo de propriedade
intelectual
• Uma cu ltura que não permita uma redução no tempo de ciclo
• Uma cu ltura que não permita a elitn inação de passos onerosos
• Uma cu ltura que tenha que "reinventar a roda"
• Uma cu ltura na qua l críticas aos pro jetos sejam vistas como críticas pessoa is
Integrar duas culturas pode ser iguahnente difícil durante épocas de dificuldade
ou de prosperidade econômica. As pessoas podem resistir a qua lquer mudança em
seus hábitos de trabal ho ou zonas de conforto, embora reconheçam que a empresa se
beneficia com as mudanças.
Fusões e aquisições mu ltinaciona is são igua lmente difíceis de integrar devido a
d iferenças culturais. Há vários anos, um fornecedor automotivo dos EUA adquiriu
u1na europeia. A empresa norte-a 1nericana apoiava vigorosamente a gestão de proje-
tos e incentivava seus funcionários a se tornarem certificados na área de projetos. A
empresa europeia oferecia mui to pouco suporte à gestão de projetos e desencorajava
seus funcionários a se tornarem certificados, usando o argumento de que seus cl ientes
europeus não dava tn tanta itnportância à gestão de projetos quanto a Genera l Motors,
Ford e Chrysler. A subsidiária europeia não via qualquer necessidade para a gestão de
projetos. Incapaz de combinar as qualquer, a empresa 1nat riz norte-a tnericana substi-
tuiu os executivos europeus para dar conta da necessidade de uma abordagem única
de gestão de projetos etn todas as divisões. A transformação completa levou quase
cinco anos. A empresa matriz acreditava que a resistência da divisão europeia se devia
mais ao medo de mudanças em sua zona de conforto do que a u1na fa lta de interesse
pelos cl ientes europeus.
Durante os últimos 40 anos, a Phi lip Morris buscou sistetnaticamente uma estra-
tégia de diversificação para reduzir sua dependência de cigarros. Além de seu negócio
de cigarros, a etnpresa é proprietária da Clark Chewing Gum, Kraft General Foods,
M iller, Miller Lite, Lowenbrau, Jell -0, Oscar Meyer, Maxwell House, Sealtest, Oro-
wheat Baked Boas e Louis Kemp Seafood. A estratégia da Philip Morris era adqu i-
rir líderes bem estabelecidos na indústr ia. Cada organ ização adquirida possuía uma
cultura corporativa distinta. Contudo, embora todas as organizações fossetn bem-
-sucedidas, algumas das sinergias esperadas não foram realizadas devido a diferenças
culturais. Cada aquisição fo i t ratada como uma organização independente. Apesar
de se poder argumentar que não havia motivo a lgum para fundir essas empresas e1n
uma única cultura, isso most ra que até mesmo empresas extremamente bem-sucedidas
muitas vezes são resistentes a mudanças.
Às vezes, há claras indicações de que a fusão de duas culturas será difícil. Quando
a Federal Express adquiriu a Flying T iger, a est ratégia era fundir as duas em uma única
organização com operações que funcionassem be1n. Na época da fusão, a Federal Ex-
press e1npregava u1na força de traba lho jovem e 1nuitos funcionários trabalhavam e1n
regÍlne de meio expediente. A Flying Tiger possuía funcionários em regÍlne de tempo
integral, mais velhos e com muitos anos de empresa. A Federal Express focal izava-se
em políticas e procedimentos formalizados e um rígido cód igo de vestimenta. A Flying
Tiger não possuía código de vestimenta, e a gerência conduzia os negócios de acordo
com a cadeia de comando, na qual alguém com autoridade poderia quebrar as regras.
A Federa l Express focalizava-se em uma meta de qual idade de entregas 100% dentro
do prazo, enquanto a Flying Tiger parecia complacente com um alvo de 95- 96'%.
Combinar essas duas cu lturas seria uma tarefa monumenta l para a Federal Express.
Nesse caso, mes1no com esses possíveis problemas de integração, a Federa l Express
não podia permitir que a Flying Tiger funcionasse como u1na subsidiária independen-
te. A integração era obrigatória. A Federa l Express precisou ocupar-se rapidamente
dessas tarefas que envolviam diferenças organizacionais ou cu lturais.
Planejar a integração cu ltural tan1bém pode produzir resu ltados favoráveis. A
n1aioria dos bancos cresce por meio de fusões e aquisições. A crença generalizada na
indústria bancária é crescer ou ser adquirido. Durante a década de 1990, a National
City Corporation de Cleveland, Oh io (EUA), reconheceu isso e desenvolveu sistemas
de gestão de projetos que permitian1 que a National City adquirisse outros bancos e
os integrasse à sua cultura em menos ten1po do que out ros bancos dedicavam a fusões
e aqu isições. A Nacional City via a gestão de projetos con10 um ativo que possui um
efeito muito positivo no resu ltado final da corporação. Muitos bancos hoje em dia
têm n1anuais para gerenciar projetos de fusão e aquisição.
A terceira área problemática na Figura 17- 3 é o impacto sobre o programa de
administ ração salaria l. As causas comuns dos problemas com a ad1n inistração sa larial
incluem:
• Medo de do wnsizing
• Disparidades nos salários
• Disparidades nas responsabilidades
• Disparidades nas oportunidades de plano de carreira
• Políticas e proced imentos diferentes
• Mecanis1nos de ava liação diferentes
Quando uma empresa é adqu irida e a integração de metodologias é necessária, o
impacto sobre o programa de administração sa larial pode ser profundo. Quando ocor-
re uma aqu isição, as pessoas querem saber como elas se beneficiarão individuahnente,
embora saibam que a aquisição ocorre para atender aos interesses da empresa.
A empresa que está sendo adquirida geralmente te1n a 1naior apreensão sobre ser
iludida com uma falsa sensação de segurança. As organizações adquiridas podem ficar
ressentidas ao ponto de tentar fisicamente sabotar a empresa aquisitora. Isso resulta
na destruição de valor, e a autopreservação adquire suma importância para os traba-
lhadores, gerahnente à custa dos sistemas de gestão de projetos.
Considere a seguinte situação. A Empresa A decide adquirir a Empresa B. A Em-
presa A possui u1n sistema de gestão de projetos relativamente fraco, no qual a gestão
de projetos é uma atividade de tempo parcia l e não é considerada u1na profissão.
A Etnpresa B, por out ro lado, promove a certificação em gestão de projetos e reconhe-

ce o gerente de projetos cotno um cargo de tetnpo integral e dedicado. A estrutura sala-
rial dos gerentes de projetos na Empresa Bera significativamente mais alta do que a de
seus colegas da Empresa A. Os trabalhadores da Empresa B expressam a preocupação
de "Não queremos ser como eles", e a autopreservação leva à destruição de valor.
Devido aos probletnas salariais, a Empresa A tenta tratar a Empresa B como uma
subsidiária separada. No entanto, quando as diferenças se torna tn aparentes, os ge-
rentes de projetos da Empresa A tentam 1n igrar para a Empresa B em busca de maior
reconhecimento e sa lários ma is a ltos. Finalmente, a escala salarial para gerentes de
projetos na Empresa B torna-se a norma para a organização integrada.
Quando as pessoas estão preocupadas com a autopreservação, o itnpacto no cur-
to prazo sobre a cadeia combinada de valor agregado de gestão de projetos pode
ser severo. Os funcionários da gestão de projetos devem ter pelo menos as mesmas
oportun idades após a integração de aquisição, senão melhores, do que tinham antes
da aquisição.
A quarta área problemática na Figura 17- 3 é a superestimação das capacidades
após a integração de aqu isição. Incluídos nessa categoria estão:
• Competências técnicas faltantes
• Incapacidade de inovação
• Velocidade de inovação
• Faita de sinergia
• Existência de capacidade excessiva
• Incapacidade de integrar melhores práticas
Os gerentes de projetos e os indivíduos que estão ativamente envolvidos na cadeia
de valor agregado da gestão de projetos raramente participatn das totnadas de decisão
pré-aquisição. Consequentemente, as decisões são tomadas por gerentes que podem
estar muito distantes da cadeia de valor agregado da gestão de projetos e cujas estima-
tivas de sinergia pós-aquisição são excessivamente otimistas.
O presidente de uma empresa relativamente grande fez uma conferência de im-
prensa anunciando que sua empresa estava a ponto de adqu irir uma outra empresa.
Para agradar os anal istas financeiros que estavam presentes na conferência, ele identi-
ficou meticulosa tnente as sinergias esperadas com as operações combinadas e mostrou
a linha do tempo de novos produtos que surgiriam no mercado. Esse pronunciamento
não fez muito sentido para a força de t rabalho, que sabia que as capacidades estavam
superstimadas e que as datas não eram realistas. Quando, posteriormente, as datas
de lançamento de produtos não fora tn cumpridas, o preço das ações despencou, e
culparam erroneamente o fracasso na cadeia integrada de va lor agregado da gestão
de projetos.
A qu inta área problemática na Figura 17- 3 é o fracasso da liderança durante a
integração pós-aquisição. Incluídos nessa categoria estão:
• Fracassos de liderança ao gerenciar mudanças
• Fracassos de liderança ao cotnbinar metodologias
• Fracassos de liderança no patrocínio de projetos
• Fracassos de liderança gerais
• Liderança invisível
• Liderança de microgerenciamento
• Acred itar que fusões e aqu isições precisam ser acotnpanhadas de uma grande re-
estruturação
Mudanças gerenciadas funcionam sign ificativamente mel hor do que mudanças

não gerenciadas. Mudanças gerenciadas exigem uma forte liderança, especia lmente
com pessoal experiente em gerenciar mudanças durante aquisições.
A Empresa A adquire a E1npresa B. A Empresa B possui um sistema de gestão
de projetos razoavelmente bom, mas com diferenças significativas em relação ao da
E1npresa A. A Empresa A decide, então, que "Devemos gerenciá-los como gerenciamos
a nós mesmos", e nada deve mudar. A Empresa A, então, substitu i diversos gerentes
da E1npresa B por gerentes experientes da Empresa A. Isso foi feito com pouca con-
sideração quanto à cadeia de va lor agregado da gestão de projetos na Empresa B. Os
funcionários dentro da cadeia da Empresa B estavam recebendo ligações de diferentes
pessoas, a ma ioria desconhecidas, e não receberam nenhum tipo de orientação quanto
a quem contatar quando surgissem proble1nas.
À med ida que o problema de liderança foi crescendo, a Empresa A continuava
transferindo gerentes de uma empresa para out ra. Isso resultou no sufocamento da ca -
deia de valor agregado da gestão de projetos co1n burocracia. Como era de se esperar,
o desempenho diminuiu em vez de aumentar.
Transferir gerentes de uma empresa para outra para aumentar as interações ver-
ticais é uma prática aceitável após u1na aquisição. Ent retanto, ela deve se restringir à
cadeia de comando vertica l. Na cadeia de valor agregado da gestão de projetos, o prin-
cipal fluxo de comunicaç.ã o é lateral, não vertical. Adicionar camadas de burocracia e
substituir gerentes de cadeia experientes por funcionários inexperientes em comunica-
ções laterais pode criar severos obstáculos para o desempenho da cadeia.
Qualquer uma das áreas problemáticas, seja individualmente ou em combinação
com out ras, pode fazer a cadeia ter um desempenho mais ba ixo, como:
• Deliverables fracos
• Incapacidade de se ater aos cronogramas
• Falta de confiança na cadeia
• Baixo moral
• Todos os novos funcionários são submetidos a provas de fogo
• Alta rotatividade de funcionários
• Nenhuma transferência da propriedade intelectual da gestão de projetos
17.4 Proprietários e inquilinos

Anteriormente, mostrou-se como é importante avaliar a cadeia de valor, especifica-
mente a metodologia da gestão de projetos, durante a fase pré-aquisição. Não há duas
empresas que possuam a mesma cadeia de valor de gestão de projetos ou mesmo me-
lhores práticas. Algumas cadeias funcionam bem; outras, têm um desempenho insufi-
ciente.
Para simpl ificar, o "proprietário" será a empresa aquisitora e o " inqui lino" será a
empresa adquirida . A Tabela 17- 2 identifica possíveis proble1nas de alto nível com a
relação proprietário-inquil ino identificada na fase pré-aquisição. A Tabela 17- 3 mos-
tra possíveis resultados da integração pós-aquisição.
O 1nelhor cenário ocorre quando ambas as partes têm boas metodologias e, o que
é ma is Ílnportante, são suficientemente flexíveis para reconhecer que a metodologia
da out ra parte pode ter elementos desejáveis. Uma boa integração, nesse caso, pode
produzir uma posição de liderança no 1nercado.
Se a abordagem do proprietário for boa e a abordagem do inquil ino for fraca, o
proprietário pode precisar forçar uma solução ao inqu ilino. O inqui lino deve estar
TABELA 17-2 Possíveis problemas com a combinação de metodologias antes de

aquisições
Proprietário Inquilino
Boa metodologia Boa metodologia
Boa metodologia Metodologia fraca
Metodologia fraca Boa metodologia
Metodologia fraca Metodologia fraca
TABELA 17-3 Possíveis resultados da integração

Metodologia
Proprietário Inquilino Possíveis resultados
Boa Boa Baseado na flexibilidade, boa sinergia alcançável; liderança de mercado possível
por um baixo custo
Boa Fraca Inquilino deve reconhecer pontos fracos e estar disposto a mudar; possível choque
cultural
Fraca Boa Proprietário precisa ver benefícios presentes e futuros; forte liderança essencial
para rápida resposta
Fraca Fraca Chances de sucesso limitadas; uma boa metodologia pode levar anos para ser
alcançada
d isposto a aceita r críticas, ver a luz no fim do túnel e fazer as mudanças necessárias.
As 1nudanças, e os motivos para elas, têtn de ser a rticu ladas cuidadosamente com o
inqu ilino para evi tar choques culturais.
Muitas vezes uma empresa com uma metodologia de gestão de projetos fraca ad-
qu ire uma organização com u1na boa abordagem. Nesses casos, a transferência da
p ropriedade intelectual de gestão de projetos tem de ocorrer rapidamente. A menos
que o proprietá rio reconheça as realizações do inqui lino, a cadeia de valor agregado
do inquilino pode passar a ter um desempenho mais baixo e pode haver uma perda de
funcioná rios-chave.
O pior cená rio ocorre quando nem o proprietá rio, ne1n o inquil ino possue1n bons
siste1nas de gestão de projetos. Nesse caso, todos os sistemas precisa1n ser desenvolvi-
dos do zero. Isso pode ser uma "bênção disfa rçada" porque talvez não haja qualquer
viés de nenhuma das pa rtes.
17.5 Melhores práticas: estudo de caso da Johnson

2
Controls, lnc.
O Automotive Systems Group (ASG) da Johnson Contr ols, lnc. UCI) é uma das or-
gan izações mais betn gerenciadas do mundo, com experiência de destaque no geren-
? D. Kandc, antigo vice-presidente do Grupo de Qualidade, Gerenciamento de Programas e Melhorias Con·

rínuas e Alok Kumar do Aummorive Sysrems Group da Johnson Con.trols, lnc., forneceram grande parte das
informações do restante desta seção. Originalmente publicadas em Harold Kerz.ner, Advanced Project Nfana•
gement: Best Prac.tkes on lmplementation, Hoboken, NJ: \Viley, 2004, p. 520-524.
ciamente da cadeia de valor agregado de gestão de projetos. O ASG é um fornecedor

global de sistemas auto1notivos internos e baterias.
Durante a década de 1990, os negócios da JCI automotive se expandiram mais
de 10 vezes, com pa rte do crescimento se devendo a aquisições estratégicas. O ASG
estava tr abalhando cada vez ma is em projetos de desenvolvimento que exigiam d iver-
sas equ ipes em vários loca is desenvolvendo p rodutos para um ún ico cliente. Estava
cla ro que o ASG precisava ter un1a n1etodologia ou processo globa l con1un1 de gestão
de p rojetos que permitisse que todos os seus funcionários e suas equipes se comuni-
cassem n1elhor e n1elhorassem a eficiência do processo de desenvolvimento. Sem isso,
os resu ltados poderian1 ter sido devastadores. O ASG não estava mais fornecendo
apenas produtos. Ele agora fornecia soluções completas aos seus clientes: a saber, o
interior do veícu lo.
Integração do Automotive Systems Group da Johnson Controls,

lnc. com a Prince e Becker Corporation
A JCI adquiriu tanto a Prince quanto a Becker há aproximada1nente 10 anos, co1n
a intenção de se tornar um fornecedor integrado de interiores para a indúst ria au-
tomotiva. A adição das capacidades de sistemas de teto, pa inel de porta e pa inel de
instru1nentos da Prince aos painéis de encaixe de plástico da Becker e aos produtos de
assentos do ASG estabeleceram o ASG imediatamente como fornecedor de interiores.
Foram necessárias mudanças organizacionais para rea lmente integrar as empresas e
suas capacidades. O resu ltado foi um modelo de negócio a partir do qual a empresa
seria reorganizada em plataformas de veículos de modo a fornecer soluções completas
para seus cl ientes em vez de meramente co1nponentes sepa rados.
Todas as três empresas possuíam diferentes sistemas de gestão de projetos, diferen-
tes descrições de cargos de gestão de projetos e diferentes est ruturas organizacionais.
Por exemplo, a Becker, na Europa, tinha encarregados de projetos, que eram uma
com binação de gerente de projetos e pessoal de vendas. A Prince, por out ro lado,
alé1n dos gerentes de projetos, possuía coordenadores de projetos que lidavam co1n
as funções adm inistrativas para os gerentes de projetos. A J CI seguia uma abordagem
tradicional, com uma organização mat ricial bem definida e gerentes de projetos que
eram integra lmente responsáveis por todos os aspectos da execução do projeto e de
seu sucesso. A J CI decidiu rapidamente que os t rês siste1nas de gestão de projetos
deveriam ser integrados em u1n único sistema comu1n. Isso se 1nost rou ser u1na tarefa
difícil, mas produtiva.
Integran do as metodologias O Automotive Systems Group da Johnson Cont rols tinha
uma história de 15 anos em gestão de projetos, com uma metodologia que estava
bem integrada ao cont role da qua lidade total. Ent re 1995 e 2000, o ASG tin ha re-
cebido ma is de 164 prêmios de qualidade de seus clientes e de out ras organizações,
e grande pa rte do créd ito por esse feito foi dado à maneira como os projetos era1n
gerenciados. Esse sistema possuía nove fases no ciclo de vida. O sistema da Prince
era chamado de desenvolvimento de novos produtos/processo de desenvolvitnento
de produtos e possuía sete fases no ciclo de vida. O sistema da Becker possuía seis
fases no ciclo de vida e se chamava Projekt Management Handbuch (Manual De
Gestão De Projetos). Os Sistemas Não Somente Eram Diferentes, Mas Os Jdio1nas
ta1nbém o eram. Cada empresa achava que seu sistema era superior e deveria ser
adotado por toda a empresa. Chegar a um acordo somente em títulos de cargos
exigia longas discussões.
Cultu ras corporativas Alén1 de d iferentes organ izações e sistemas, as t rês empre-
sas possuíam diferentes va lores e todas eram con1preensivelmente o rgu lhosas
de seus próprios modos de operação. A Prince Corporation tinha uma cu ltura
n1uito bem integrada e com um forte foco sob re a liderança, e tinha sido criada
por seu fundador, Ed Prince. A Prince Corp. (localizada em Holland, M ichigan,
EUA) nunca tinha tido nenhuma necessidade real de considerar os interesses eu-
ropeus, especialmente os da Becker, que tradicionalmente fora ou conco rrente
ou fornecedora. A J CI possuía uma presença muito forte na Europa, con1 seu
escritório centra l em Burscheid, Alen1anha. O escritório de Burscheid segu iu a
orientação da América do Norte quanto aos sistemas de gestão de projetos, mas
tinha fortes opiniões sobre como esses sistemas deverian1 funcionar na cultura
eu ropeia e seguia un1a abordagem n1u ito mais laissez-faire de gestão de proje-
tos. Ao manter a cu ltura europeia e a tradiciona l separação entre os países eu-
ropeus, os vários centr os de desenvolvimento do ASG localizados em diferentes
países da Europa operavan1 bastante independentemente, com pouca influência
centra lizada. O resultado final foi n1u itas opiniões sobre como integrar os siste-
n1as de gestão de projetos, com alguns princípios comuns e valores amplan1ente
distintos.
Foco no produto Além das diferenças listadas acima, a aquisição da Prince e da Becker
pretendia levar a JCI a uma posição de sistemas automotivos de interior total
com as e1npresas de veículos. Isso significava que não somente as diferenças em
cultu ra, organização e sistemas tinha1n de ser superadas, mas ta 1nbém diferenças
em produtos, equipamentos e processos de manufatura centrais. O ASG precisava
encont rar uma maneira de torná-los comuns. Além diso, o ASG tinha de posicio-
nar os novos sistemas de 1nodo a perm itir o desenvolviinento e lançamento de
interiores totais de veículos, u1n escopo fundamenta lmente diferente para todas as
três empresas envolvidas. A recém desenvolvida cadeia integrada de valor agrega-
do da gestão de projetos seria uma abordage1n completamente nova para todas as
três empresas.
A integração Foi criada uma e1npresa para integrar os vários sistemas, a organização
e os va lores das três empresas. Foram nomeados gerentes de projetos de todas
as t rês empresas, incluindo a América do Norte e a Europa. Além disso, foram
selecionados representantes de todos os departa1nentos funcionais. Representan-
tes dos departa1nentos de Qualidade, Engenharia, Ma nufatura e Finanças faziam,
todos, pa rte da equipe e eram capazes de influenciar sua direção.
A equipe foi desafiada a criar uma metodologia de gestão de projetos (e uma
cadeia de valor agregado da gestão de projetos multinacional) que alcançasse as
seguintes metas:
• Co1nbinar as melhores práticas de todas as metodologias de gestão de projetos e
cadeias de va lor agregado de gestão de projetos existentes
• Criar uma metodologia que englobasse toda a cadeia de valor agregado de ges-
tão de projetos dos fornecedores aos clientes
• Cumprir os padrões da indústria estabelecidos pelo Automotive Industry Action
G roup (AIAG), pelo Instituto de Gestão de Projetos (PMI) e pela Organização
Internacional para a Padronização (ISO)
• Compartilhar as melhores práticas entre todos os estabelecin1entos globais do ASG
• Alcançar as metas corporativas de prazos, custo, qualidade e eficiência
• Acomodar todos os produtos do ASG
• Otimizar proced imentos, deliverables, papéis e responsabi lidades
• Fornecer uma documentação clara e útil
O sistema que se desenvolveu, chamado PLUS (Prod11ct La1111ch System, ou

Siste1na de Lançamento de Produtos), incorporava ideias e melhores práticas de
todas as três empresas.3 O PLUS possuía cinco fases (mais uma fase inicial chama-
da de fase O para concepção, que era a fase de criação de produto da Prince). Todas
as t rês empresas conseguiram se identificar com esse novo sistema e forneceram
a estrutura básica de gestão de projetos para que a JCI buscasse atingir seu a lvo
est ratégico de fornecer interiores de veículos. O PLUS reformulou e aprimorou os
três sistemas existentes em um novo processo com proced imentos, papéis, respon-
sabi lidades e deliverables otimizados.Fez-se uma correspondência m inuciosa entre
o novo sistema e os Qua lity System Requirements QS9000 (AIAG, March 1998),
Advanced Product Qual ity Planning (APQP) e Cont rol Plan (AIAG, J une 1994),
Automotive Project Management Guide (AIAG, 1997) e o Guia PMBOK® (2000).
Ainda havia alguns problemas que precisavam ser resolvidos. Isso se tornou
evidente quando as equipes co1n ma is de um ano de desenvolvimento foram soli-
citadas a se converterem ao PLUS. O PLUS foi introduzido aos t raba lhadores por
meio de um curso on-line com a visão geral do PLUS. Esse curso não foi suficiente
para preparar as equipes para usar o PLUS. Programas de treinamento adicional
foram, então, organizados com uma personalização para públicos específicos de
traba lhadores. O progra1na de treinamento forneceu orientação sobre por que o
PLUS fora desenvolvido, co1no aplicá-lo e os procedimentos para rea lizar as me-
lhorias sugeridas.
O resultado O PLUS foi bem recebido por todas as t rês empresas. Mais de 350 pro-
gramas estavam usando o PLUS. A equ ipe que criou o novo sistema recebeu o
Prêmio de Satisfação do Cliente das mãos de seu presidente. O ASG agora tinha
um sistema básico que permitia que todos da empresa utilizassem uma linguage1n
comum para o desenvolvimento e lançamento de produtos. Na verdade, esse de-
senvolvimento preparou o terreno para uma mudança organizacional que veio
um ano mais tarde, chamada de Novo Modelo de Negócios, que reorganizou a
empresa em equipes de plataforma de veícu los, enfatizando a direção estratégica
da JCI rumo a se tomar um fornecedor total de interiores de veícu los.
Essa mudança permitiu que o ASG funcionasse como u1na e1npresa integrada.
As equipes das plataformas (escritórios de projetos) tinham se tornado verdadei-
ras equipes e tinha1n um senso de identidade com base em todo o veículo em vez
de apenas portas, assentos e painéis de cont role. As principais métricas, como pra-
zo, lucratividade e relações com o cliente, agora eram vistas a partir da perspectiva
de todo o veículo. Os clientes estavam mais felizes, porque agora tinham um ún ico
ponto de contato para seu veículo, e1n vez de vários pontos de contato.
Trabalho de seguimento Os benefícios do PLUS eram claros: o siste1na integrado, pa-
péis e responsabil idades comuns, a capacidade de gerenciar projetos como plata-
formas integradas. O lado negativo era que o PLUS fora criado por um comitê.
Como todos tinham poder de voto, o sistema ficou um tanto mais volumoso e
menos elegante do que poderia ter ficado. O próximo passo era óbvio - o PLUS
precisava ser simplificado e racionalizado. Por respeito às fortes opiniões e cultu-
ras das três empresas, o PLUS pode pennanecer co1no era por aproximadamente
1-1,5 anos. Depois disso, um grupo central de diretores de gerenciamento de pro-
JAs co7Jexidades do desenvolvimento e implementação do PLUS e a correspondência do PLUS ao Guia

PMBOK podem ser enconcradas em R. Spigarelli e C. Allen, "Implemenrarion of an Auromocive Producr
Launch Sysrem··. Proceedings of rhe Project Managemenr lnscirute Annual Seminars and Symposiums, No~
vember 1- 10. 2001, Naslwille, Tennessee.
jetos adotou uma a bo rdagem 1ninimal ista ao PLUS, removeu algu ns conteúdos
desnecessários, focalizou nos deliverables essenciais e o tomou muito mais simples
e fáci l de usar. O siste1na revisado, lançado em outubro de 2001, focalizava-se nos
deliverables essenciais e em um princípio de um deliverable-um encarregado . Os
resultados foram bem-acei tos na Europa e na América do Norte.
O sistema é revisado d uas vezes por ano a intervalos de seis n1eses. O foco
continua sendo torná-lo int uitivo e flexível, orientado por deliverables essen-
ciais e responsabilidades cla ras. Un1a integração apropriada de metodologias,
aliada possivelmente a toda a cadeia de valo r agregado da gestão de projetos,
pode for necer excelentes benefícios. N a J CI, os segu intes benefícios fo ran1 en-
contrados:
• Tenninologia comum em toda a organização
• Unificação de todas as empresas
• Formulários e relatórios comuns
• Diretrizes par a gerentes de pro jetos e membros de equipes menos experientes
• Definição mais cla ra de papéis e responsabil idades
• Red ução no nú mero de prcedimentos e formulários
• Nenhuma duplicação nos relatórios
• Red ução no nú mero de itens na linha do tempo de 184 para 11O
Recomendações para outras empresas

As segui ntes recomendações pode1n ser feitas:
• Usa r um sistema comum por escrito par a gerenciar programas. Se novas empresas
forem adquiri das, trazê-las ao sistema básico o mais rápi do possível dentro dos
limites razoáveis.
• Respeitar todas as partes. Você não pode forçar uma empresa a aceita r os sistemas
de outra empresa. É preciso "vender" ideias, chegar a um consenso e fazer modi-
ficações.
• Leva te1npo par a fazer diferentes culturas corporativas se combina rem. Forçar de-
mais simplesmente irá alienar as pessoas. Ênfase e impulso contínuos pela gerência
são mesmo a melhor manei ra de a lcançar a integração de sistemas e culturas.
• Compartilhar pessoal de gerência ent re as empresas que estão se fundindo ajuda a
aproximar sistemas e pessoas rapidamente.
• É preciso haver um "enca rregado pelo processo" comum par a o sistema de gestão
de projetos. Uma pessoa no nível vice-presidencial seria apropriada.
17.6 Resultados da integração

Os planos n1ais bem preparados não necessa riamente ga rantem o sucesso. A reava-
liação é sempre necessária . A avaliação do va lor agregado integrado da gestão de
p rojetos após a aqu is ição e a in tegração serem concluídas pode ser feita usando o
modelo do Boston Consulting Group (BCG), exibido na Figura 17-4. Os dois pa -
râmetros críticos são o valor perceb ido para a en1presa e o valor percebido para os
clientes.
Se a cadeia final for um va lor percebido ba ixo tanto para a empresa quanto para
os cl ientes, ela pode ser considerada um "peso morto" (dog) . As características de um
"peso mo rto" incluem:
Alto
Potencial de "Dilema·
crescimento (Problem chí/d)
"Estrela" "Peso morto·

(Star) (Oog)
Baixo
Alto + - - - - - - - - - - - Baixo
Valor percebido para a empresa
Figura 17-4 Sistema de gestão de projetos após a aquisição.
• Falta de cooperação interna, possivelmente e1n toda a cadeia de valor agregado.

• A cadeia de valor não tem boa interação com os cl ientes.
• O cl iente não acred ita na capacidade da empresa de fornecer os deliverables soli-
citados.
• Os processos da cadeia de valor agregado são sobrecarregados com conflitos ex-
cessivos.
• As expectativas pré-aquisição não foram alcançadas, e os negócios podem estar
diininuindo.
Possíveis estratégias a serem empregadas com "peso morto"incluem:

• Fazer downsizing, reduzir o escopo, ou abandonar a cadeia de valor agregado da
• Reestruturar a empresa em uma organização de gestão de projetos projetizada ou
departamental izada.
• Perm itir que os negócios diminuam e focalizar-se em projetos e clientes selecionados.
• Aceitar a posição de seguidor de mercado em vez de líder de mercado.
O quadrante do "dilema" na Figura 17-4 representa uma cadeia de valor agre-
gado que possui um alto valor percebido para a empresa, mas não é muito estimada
pelos diente.s.
As características de um"dilema"inc/uem:
• O cl iente acredita razoaveln1ente na capacidade da en1presa de produzir os re-
su ltados desejados, n1as não confia na cadeia de va lor agregado da gestão de
proJetos.
• Pode1n existir sistemas incompatíveis dent ro da cadeia de valor agregado.
• Os funcionários ainda são céticos quanto à capacidade da cadeia de valor agrega-
do de gestão de projetos.
• Os projetos são concluídos mais na base da "prova de fogo" do que co1n u1na
abordagem estruturada.
• Ainda pode haver "bolsões" fragmentados de gestão de projetos tanto no proprie-
tário quanto no inqui lino.
Possíveis estratégias para uma cadeia de valor "dilema"inc/uem:
• Investir fortemente em treinamento e educação para obter un1a cultura cooperativa.
• Monitorar cuidadosamente a interface multifunciona l em toda a cadeia.
• Procurar a liados visíveis da gestão de projetos tanto no proprietário quanto no

inquilino.
• O uso de pequenos projetos envolvendo avanços pode ser apropriado.
O quadrante do potencial de crescimento na Figura 17-4 tem o potencia l de a l-
cançar as expectativas da tomada de decisão pré-aquisição. Essa cadeia de va lor agre-
gado é percebida positivamente tanto pela empresa quanto por seus clientes.
As características de uma cadeia de valor com potencial de crescimento incluem:
• Um número lünitado de projetos bem-sucedidos está usando a cadeia.
• A cultura que permeia cadeia baseia-se e1n confiança.
• Existe um patrocínio visível e eficiente.
• Tanto o proprietário quanto o inquilino consideram a gestão de projetos como
uma profissão.
Possíveis estratégias para uma cadeia de valor agregado da gestão de projetos

com potencial de crescimento incluem:
• Manter um crescimento lento que leva a projetos 1naiores e mais complexos.
• Investir em melhorias na metodologia.
• Co1neçar a vender soluções completas para os clientes em vez de si1nples1nente
produtos ou serviços.
• Foco em um 1nelhor relacionamento co1n o cl iente usando a cadeia de va lor agre-
gado de gestão de projetos.
No último quadrante na Figura 17-4, a cadeia de valor é vista como uma "estrela"
(star). Uma estrela possu i um alto valor percebido pela empresa, mas um ba ixo valor
percebido pelo cl iente. O motivo para o baixo valor percebido pelo cliente é o fato de
você já tê-lo convencido da capacidade de sua cadeia de produzir os resultados espera-
dos, e seus cl ientes agora estão focalizados nos deliverables em vez de na metodologia.
As características de uma cadeia de valor agregado da gestão de projetos

"estrela"incluem:
• Existe uma cultura altamente cooperativa.
• A t ripla restrição é satisfeita.
• Seus cl ientes tratam como parceiro em vez de como empresa contratada.
Possíveis estratégias para uma cadeia de va lor "estrela " incluem:
• Investir fortemente em subsistemas de suporte de última geração para a cadeia.
• Integrar seu SIGP (sistema de informação de gestão de projetos) aos sistemas de
informação do cl iente.
• Permitir que as opiniões do cliente gerem melhorias para sua cadeia.
17.7 Estratégias da cadeia de valor

No início deste capítu lo, o foco foi sobre os objetivos estratégicos estabelecidos du-
rante a to1nada de decisão pré-aquisição. Ent retanto, para alcançar esses objetivos, a
empresa precisa co1npreender sua vantage1n competitiva e seu mercado co1npetitivo
depois da integraç.ã o de aquisição. Quat ro estratégias genéricas para uma cadeia de
va lor de gestão de projetos são apresentadas na Figura 17- 5. A e1npresa te1n de abor-
dar duas questões fundamentais relativas à integração pós-aquisição: A organização
agora se tornará competitiva em termos de custo ou da singu laridade de seus produtos
e serviços?
• O 1nercado pós-aquisição será a tnplo ou est reito?

A resposta para essas duas questões gera lmente determina os tipos de projetos que
são ideais para a metodologia da cadeia de va lor agregado de gestão de projetos. Isso é
exibido na Figura 17-6. Projetos de ba ixo risco exigem metodologias não complexas,
enquanto projetos de alto risco exigetn metodologias complexas. A complexidade da
metodologia pode ter utn impacto sobre o tempo necessário para a integração pós-
-aquisição. O tempo 1nais longo de integração ocorre quando uma empresa quer que
uma cadeia de valor agregado da gestão de projetos forneça uma solução completa de
gestão de projetos, o que inclui desenvolvimento de produtos e serviços, instalação,
e seguimento. Pode inclu ir também uma plataforma de gestão de projetos, como foi
o caso da Johnson Controls, Inc. A ênfase é sobre satisfação do cl iente, confiança e
trabalho de seguimento .
As metodologias de gestão de projetos geralmente são um reflexo da tolerância
a riscos por parte de uma etnpresa. Co1no most ra a Figura 17-7, as empresas cotn
alta tolerância a riscos desenvolvem cadeias de valor agregado de gestão de projetos
capazes de lidar com projetos complexos de P&D e se tornar líder de mercado. Na
out ra ext remidade do espectro, encontram-se projetos de 1nelhorias que se foca liza tn
Vantagem competitiva
Custo Singularidade
liderança de custo Diferenciação

o
"O o
"' -E
<.> Q.
~ • llpo de projeto: Redução de custo • Tipo de projeto: Novos produtos
:í "' • llpo de P&D: Engenharia de produto • Tipo de P&D: P&D básica
• Risco: Baixo (obsolescência} • Risco: Médio
• Metodologia: Simples • Metodologia: Complexa
Liderança de baixo Diferenciação

custo focalizada Focalizada
• llpo de projeto: Melhorias • Tipo de projeto: Soluções
• llpo de P&D: DesenvolVlmento • Tipo de P&D: P&D aplicada
avançado
• Risco: Baixo a médio • Risco: Muito alto
• Metodologia: Simples • Metodologia: Complexa
Figura 17- 5 Quatro estratégicas genéricas de gestão de projetos.
Altorisco = Soluções
Metodologias
de gestão de
projetos complexas
Novos produtos
Produtos aprimorados
Metodologias de
gestão de projetos
Baixo risco = Produtos similares
não complexas
Figura 17- 6 Espectro de risco por tipo de projeto.

Altorisco =
<::a Desenvolvimento avançado
<::a Desenvolvimento integral de engenharia
<::a Engenharia de produção
Baixo risco = <::a Engenharia de produtos ou serviços
Figura 17- 7 Espectro de risco para os tipos de projetos de P&D.
em 1nanter u1na participação de mercado e se tomar u1na seguidora, e não uma líder
de mercado.
17.8 Fracasso e reestruturação

Grandes expectativas geralmente levam a grandes fracassos. Quando cadeias integra-
das de valor agregado de gestão de projetos fracassam, a empresa possui t rês a lterna-
tivas viáveis, mas indesejáveis:
• Fazer um downsizing na e1npresa.
• Fazer um downsizing no número de projetos e comprimir a cadeia de valor agre-
gado.
• Focar-se em uma base de clientes selecionados.
Os resultados de curto e longo prazo para essas alcernativas são exibidos na Fi-
gura 17-8. O fracasso geralmente ocorre porque a fase de to1nada de decisão p ré-
-aqu isição foi baseada em ilusões em vez de fatos. Típicas ilusões incluem:
• Integrar as metodologias de gestão de projetos reduzem automaticamente ou el i-
minam passos duplicados na cadeia de valor agregado.
Resultados no Resultados de
curto prazo longo prazo
Propriedade
Alternativas intelectual perdida
Downsizing
De líder a
seguidora
Diminuição
do esco o
Propriedade
intelectual erdida
Clientes
selecionados
Maiores riscos
Figura 17-8 Resultados da reestruturação.

Capítulo 17 Efeito das fusões e aquisições na gestão de projetos 74 7
• Conhecimentos especia lizados e1n uma parte da cadeia de valor agregado da ges-
tão de projetos poderiam ser diretamente aplicáveis a atividades que se encontra1n
a montante e a jusante na cadeia.
• Um proprietário co1n uma forte metodologia em parte de sua cadeia de valor
agregado poderia eficientemente forçar uma mudança a um inquilino com uma
metodologia mais fraca.
• A sinergia de operações combinadas podem ser alcançadas da noite para o dia.
• A integração pós-aquisição é uma garantia de que a tecnologia e a propriedade
intelectual serão transferidas.
• A integração pós-aqu isição é uma garantia de que todos os gerentes de projetos
terão uma situaçao de igualdade em termos de autoridade e tomada de decisão.
Fusões e aquisições continuarão a ocorrer independentemente de a economia estar
fraca ou forte. A esperança é a de que as empresas agora prestem mais atenção à inte-
gração pós-aquisição e reconheçam os possíveis benefícios.
Esta página foi deixada em branco intencionalmente.
,
lndice
AAr (After Action review), 58- AggPro, 276-277 análise de portfólio, 592-596
60, 564 AC P (Abordagem de Gestão de análise de valor agregado (EVA,
ABB, veja Ase.a, Brown e Boveri Projetos), 275-279 earned-value aualysis ), 33 '1-332
(ABB) ajustes de rota, 287 Análise de Variância (ANOVA),
abertura de projetos, veja Termo Alcatel-Lucent: 3·11
de Abertura de Projetos finalista do PMO do Ano, 557- análise financeira, 576-577
abordagem analítica, 304 561 análises de c usto-benefício, 589-
abordagem de Gerenciamento reconhecimento de valo r de 590, 596-597
Avançado de Entregas, 207-208 um PMP" na, 432-434 Anbari, Frank T., sobre gestão de
Abordagem de Gestão de treinamento na, 432-434 projetos arriscados, 306
Projetos (ACP), 275-279 Akatel-Lucent University, 558- anos de evolução (cursos de
Academia de Gestão de Projetos 560 treinamento), 404
da COtv!AU, 679-681, 689-690 Alexander, Jack, 3611.29, 71 4-717 anos de revoluç.ã o (tre inamento),
aceitação: alicerce, 150 405-406
de metodologias, 202-203 alinhamento, governança e, 382- ANOVA (Análise de Variância),
de riscos, 13-14 383 3 'I 1
por toda a corporação, 231- Allen-Bradley, 263-264 "apagar incêndios", maturidade
232 Alstom, metodologia do Ciclo V e, 327
ações de marca, da DFCU, 347- na, 291-295 aplicabilidade do gerenciamento
350 alternativas de design, 695-697 de m udanças:
aconselhamento, na IBM, 629- alunos, treinamento/seleção de, na Churchill Downs, 51 4-519
630 408-409 na Deli Services, 526-528
acreditação (no processo de ambientes de pequenas empresas, na Deloitte, 673-678
qualificação), 617 gestão de projetos em, 61 na Naviair, 166-168
acreditações gerais de gerente de Americ.an Greetings Corporation: aplicação de conhecimento por
projetos, 558-559 benefícios da gestão de participantes de tre inamentos,
adequação do pessoal, 103 projetos na, 12, 13 479
adesão dos executivos, 106-107 PMO da, 518-519 aplicações das melhores práticas:
ADN\ (affow diagramming American Telephone and na AT&T, 20, 29, 41, 47, 49-
method), 233-235 Telegraph, veja AT&T 50
Administração Nacional da amigos, em projetos políticos, na Churchill Downs, 20-21,
Aeronáutica e do E.spaço 79-80 26-27, 42, 43
(NASA, National Aeronautics análise da cadeia de valor, 730 na Computer Associares, 47
and Space Administration), 4, 6 análise de causas-raiz, 645-646 na Computer Sciences
administradores externos análise de lacunas, 114-115 Corporation, 528-532
terceirizados (TPAs, third-party Análise de Modos e Efeitos de na DTE Energy, 56-61
administrators), 315 Falhas (Ft.lEA, Fai/11re Modes na EDS, 46
adoção de soluções para o aud Effects Analysis), 311,312 na Enakta, 21-22, 25, 28-29,
cliente, 634-635 análise de negócio 33
Agência de Proteção Ambiental, (desenvolvimento de novos na Halifax Community Health
446 produtos), 586-587 Systems, 20
750 Índice
na Hewlett-Packard, 28-29, da maxlT-VCS, 497 da Chubb, 540-544

49-50, 53-57 da Medical l\1utual, 272-276 da Churchill Downs, 513-519
na HP Services, 28-29 da Repsol Exploration and da COMAU, 71, 679-684
na 1Blv1, 14- '15, 625-631 Production, 255-264 da Computer Sciences
na lndra, 10, 21, 27, 30-31, 43, da Rockwell Automation, 263- Corporation, 528-534
45-46, 49-50 269 da Dell lnc., 519-529
na Johnson Controls, 738-742 da SAP, 204-209 da DTE Energy, 542
na maxlT-VCS, 21, 31, 42 da Sherwin-Williams, 268-272 da Hewlett-Packard, 71, 544-
na Microsoft, 649 da Slalom Consulting, 222-225 547
na Motorola, 16-17, 32, 33 da Tech Mahindra Ltd., 241- da Holcim, 277-278
na Norte! Networks, 30, 48-50 249 da fBt\>1, 614-615
na NXP Semiconductor, 48-49 da Tecnicas Reunidas, 211-218 da fLLUJVlfNAT, 319
na Orange Switzerland, 20 da Teradyne, 217-222 da lndra, 340-343, 487
na Our Lady of Lourdes da Wàrtsila, 239-242 da ITS, 331-332
Regional t\>ledical Center, 16 da Westfield Group, 278-282 da maxlT-VCS, 496-498
na Sherwin-Williams, 270-27'1 aplicações de treinamento : da Philips Healthcare Software
na Siemens, 7'11-712 da A88, 400-402 Customer Services, 488-496
na Tech Mahindra Ltd., 15-16 da Alcatel-Lucent, 432-434 da R. R. Donnelley & Sons,
na Wàrtsila, 2-3 da AVIVA Canada, 501 535, 537, 538
no governo, 7-8 da Churchill Downs, 513-514 da Sears, 535,538
no Seis Sigma, 564-565 da Deli Services, 526-52 7 da Sherwin-Williams, 271-272
ap1icações de gerenciamento de da Ford Motor Co., 411-4 12 da Slalom Consulting, 53 4-54 1
portfólio: da Harris Corporation, 427- da Star Alliance, 7'1, 545-548
da AT&T,583 432 da Teradyne, 2 19
da AVIVA Canada, 507-511 da Hewlett-Packard, 437-438 da Wiirtsila, 239-24 '1
da Chubb, 540 da H itachi Ltd., ·116-118 da Zurich America, 306-308
da Churchill Downs, 583-583 da Holcim, 276-278 aplicações do suporte da
da COt\>lAU, 682-683 da 1BtV1, 619-622, 630 gerência:
da Deloitte, 661-667 da lndra, 341-343 daAT&T,335
da Holcim, 276-277 da KONE, 131 da Computer Sciences
da 181'>1, 613-614, 627 da Medical Mutual, 273-274 Corporation, 534
da lndra, 583 da SAP, 402-403 da Contractco (nome fictício),
da Rockwell Automation, 597- da Tech Mahindra Ltd., 434- 391
600 438 da DTE Energy, 394
da Slalom Consulting, 578-580 do lnternational lnstirute for da Health Care Associares
da Wàrtsila, 240-241 Learning, 404-408 (nome fictício), 391-392
do World Wildlife Fund, 599- aplicações do gerenciamento de da Hewlett-Packard, 378-379
604 processos integrados: da IBM, 612-613
aplicações de metodologia: da Alcatel-Lucent, 559-561 da lndra, 393
da Alstom, 291-295 da 8oeing Aircraft, 327-328 da maxlT-VCS, 392-393
da Cassidian, 208-211, 294- da DTE Energy, 331-332 da Midline 8ank (nome
297 da Hewlett-Packard, 329-331 fictício), 389-391
da Churchill Downs, lnc., 226- da ILLUl\11NAT, 319-320 da Motorola, 394
229 da lndra, 323-325 da Zurich Americ.a lnsurance
da Compute r Associares da Wàrtsila, 316-318 Company, 379-381
Services, 638-640 da Z urich Americ.a lnsurance do Tokio t\>larine Group, 382-
da Compute r Sciences Company, 306-308 389
Corporation, 531-532 aplicações do patrocínio: apoio por parte da gerê ncia, 14 7,
da Deloitte, 668-670 da Cooper Standard, 162-163 373-398
da DTE Energy, 284-291 da Design Solutions (nome de nível mais a lto, 464-465
da Ericsson Telecom A8, 249- fictício), 378-379 e a governança de projetos,
253 da Franklin Engineering (nome 380-389
da GM Powertrain C roup, fictício), 377-379 e o empocleramento de
248-250 da Hewlett-Packard, 378-379 gerentes de projetos, 388-390
da Hewlett-Packard, 281-284 da Naviair, 171-172 e o patrocínio de projetos,
da Holcim, 275-279 aplicações do PMO: 373-379
da 181'>1, 622-625, 627 da A88, 487 e os executivos convictos, 394 -
da lndra, 228-231, 252-255, da Aviva Canada, 498-514 398
340-342 da 8oeing, 487-4 89 obtendo o, 393-394
Índice 751
para as melhores práticas, 56- indicado res-chave de banco de dados de lições

57 desempenho da, 29 aprendidas, 316-3 17
problemas resolvidos co m o, melhores práticas da, 20, 49- banco de dados relacional, 31 2-
106-107 50 313
visível, 184, 373-374 PMOs da, 518-520 " banco de ideias", 574-575
a poios, verdadeiros, 79-80 sucesso de projetos na, 2 7 Bancroft, George, sobre avareza,
apre ndizado . Veja t.m nbém validação das melhores 89-90
educação; tre inamento práticas na, 41 Barringhaus, Herm, 527-528
a partir de e rros, 3 atendimento ao cliente, 495 Barrow, W. F. "Bud", sobre gestão
contínuo, 409-410 atividades sobrepostas, 203-204 de projetos, 16
dos participantes de programas auditorias de desempenho, 548 base de clientes, 68-69
de treiname nto, 478 auditorias de melho res práticas, base de c usto, para estimativa a
ho lístico, 434 548 livros abertos 2 14-215
organizacional, 2 77-278 auditorias de observância, 548 baselining (finalizar), 650-652
responsabilidades para o, 406- aud itorias de projetos, 274-275, Bass, Allison, 527-52 8
408 548-551 Bauer, Michael, sobre PJvlOs,
sistemas de instrução para o, aud itorias de qualidade, 548 488-496
408-409 aud itorias de saída, 548 Becker, 739, 740
aprovações nos pontos de Austen, Jane, sobre o rgulho, Belgrave, D avid, sobre a gestão
decisão, 29'1 88-89 de riscos na ILLUl\1INAT, 322-
aquisições, 728-729. Veja auto nomia de equipe gerenciada, 323
também fusões e aquisições 62 Belliveau, P., sobre {ttv:y front
Archibald, Russ, 226-228 Autoridade: end, 395-39611.8
á rea da saúde, gestão de pro je tos desafios da, 97-98 Benchma-r king, 333-334
na,62 em mercados emergentes, 367 compe titivo, 333-334
Área de Negócios de inveja sobre, 85-87 e tendências de c ursos de
Telecomunicações Públicas, perda da, 388-389 tre inamento, 407
250-251 auxílio ao conhecimento, 702 externo, 22-2 3
Aristóteles, sobre excelência, 180 Avaliação de Prontidão para limirações do, 268-269
ARJvl (Avaliar Recursos e l\1udanças, 526-528 para as melho res práticas, 22-
Metodologia) reuniões de, 510- avaliação preliminar de projetos, 23
511 587-590 processo de, 333-334
Asea, Brown e Boveri (ABB): avaliações (Seis Sigma), 572-574 Bendix Corporation, 442
c ursos de treiname nto na, 400- fases do ciclo de vida para as, benefícios:
402 573 definição, 72
gerenciamento da satisfação do fato res a serem considerados esti mando os, 3
cliente, 70 para as, 572 realização dos, 72
gestão de riscos na, 329-330 fe rramentas para as, 573-574 benefícios de curto prazo, 201-202
PMO na, 487 finalidade das, 572 benefícios de longo prazo, 201-
AsphPro, 276-277 Avaliar Recursos e Metodologia 203
Associação das Indústrias de (ARM), reuniões, 510-5 1 'l benefícios essenciais, 3
Serviços Tecnológicos (TSIA, Avalon Power and Light (nome benefícios intang íveis, 2
Technology Services lndustry fictício), 1 82-183 benefícios intang íveis do
Association), 207-208 avareza, no ambiente de projetos, treinamento 480-481
Associado Certificado em 89-92 Bhagavad Gita, 92-93
Gere nciamento de Programas Aviva Canada, 498-514 Biblioteca de Informações sobre
(Certified Associate in Project estrutura da, 498-503 Tecnologia da Informação
Management, CAPJvl, 4 3 8 fu nção da, 502-507 (!TIL, lnformation Technology
AT&T (American Telephone and operações da, 506-514 lnformation Library) , 281-284,
Telegraph), 452-454 563
biblioteca de melhores práticas Babcock and Wilcox, 4 11-41 2 biblioteca de melhores práticas,
da, 47 Baker, Christine, PMO da Boeing, 51-54
c ultura da, 335 487-489 comunicando as me lhores
definição de excelência da, Baker, Steve, me lhores práticas, práticas co m a, 4 7
132, 189-190 56-57n.43 criando a, 52-53
descr ição de cargos da, 4 15- Balancing Individttal and e a validação das melhores
416 Organizational \!alues (Ken práticas, 4 2
gerenciamento de portfólio na, Hultman e Bill Gellerrnan), e o gerenciame nto das
583 716-717 me lhores práticas, 46
752 Índice
na DTE Energy, 58-60 Brown, J ames C., 263 -264u.19 Centro de Aprendizagem de GP,
na Hewlett-Packard, 56-57 e o prêmio PtVIO do Ano, 555- 433-434
níveis de melhores práticas na, 557 Centro de Competência ([BM),
44, 52-53 sobre o gerenciamento de 610
bibliotecas MIDAS, 343-345 portfólio, 597-598u.'l l Centro de Excelência em Gestão
Billings, Josh, sobre o glutão, Buda, sobre a luxúria, 92-93 de Projetos ( (lBl\1), 606-613,
93-94 burocracia, 439-441, 570-571 626-630
Blackburn, Claudia, 531-532 Burto n, Robert, sobre o glutão, Centro de Práticas de Negócios
boas intenções, 67-68 93-94 (Cer,ter for Business Practices),
Boccardo, Jose Manuel, 255- buy-iu, 106-1 07 554
256t1. l 8 Centro de Processamento de
Boeing: CA, veja Computer Associares Entregas de Soluções (SDPC,
c ultura corporative da, 337- Technologies S0l11t io11 D elivery Process
339 cadeia de valor agregado, 728- Ce11ter), 57-60
e a Thiokol Corporation, 4 50- 732. Veja também fusões e Centro N acional de Informação
45 ·1 aquis ições so bre Reconhecimento
gestão de riscos na, 32 7-328 cadeias de resultados, 141, 143 Acadêmico (NARIC, Academic
gestão informal de projetos na, caixas delimitadoras, 725-727 Recognition lliformation
450-451 Campbell, Henry, 284-291 Ce11tre), 621
Ptvló da, 487-489 canais de entrega, 361-362 Centro Registrado de
processo de gerenciame nto cancelamento (projetos), 73 -75, Treinamento (REP, Registered
integrado da, 327-328 397-398 Ed11ca tio11 Provider), 4 38, 526-
Boeing 777, 337-339 capacidade: 527, 689-690
Bolzman, Doug: definição, 633-634 ce rtificação:
sobre a abordagem do PMO para fusões e aquisições, 736 da Comunidade de Usuários,
na HP, 545-547 CapCom Credit Union, 353, 434
sobre a cultura da Hewlett- 356-357 dupla, 407
Packard, 365-366 Capellanus, Andreas, sobre a na [BM, 626-627
sobre a excelência, 153-159, avareza, 89-90 no processo de qualificação, 618
189-1 91 capital humano, na AVIVA PMI~ 620, 621
sobre a relação do Seis Sigma Canada, 500-503 PMP , 341-342, 404, 432-434,
com a gestão de pro jetos, CAPtvl (Certified A ssociate i11 4 38, 689-690
563 Project Ma11agement), 4 38 prog rama interno de
sobre as bases para uma Caputo, Michele A., 527-528 ce rtificação em gestão de
metodologia, 281-284 CAQ (Certificates of A dded projetos PM3, 525-527
sobre as melhores práticas, 53 - Q 11a lif icat io11), 438 tre inamentos espec ializados
54u.54 Cassidian: para, em ins tituições
sobre o pape] dos executivos, c ro nogramas multinível educacionais, 4 10-411
154 integrados na, 208-21 ·1 ce rtificação de profissionais
sobre o patrocínio, 378-379 metodologias da, 208-211, de gestão de projetos (PtvlP'"),
sobre o sucesso de um projeto, 294-297 34 '1-342, 404, 432-434, 438,
28-29 regras áureas para a gestão de 689-690
sobre os fatores críticos de projetos da, 294-297 certificação dupla, 407
sucesso, 28-29 c ategorização , proje tos, 240 - Certificados de Qualificação
sobre os indicado res-chave de 241 Adicional (Certificates of Added
desempenho, 29-30 Categorização de Complexidade Q ualificatio u, CAQ ), 438
bônus, 85-86, 90-92 de Projetos ( PCC, Project Charvat, Jason, sobre
Booz, Allen e Hamilton, 586-589 Complexity Categorizatio11), metodologias, 197-199
Bo utros, Sameh, sobre gestão de 523-524 choque cultural, 70
projetos global, 544-547 Cavanaugh, Kathleen: Ch.rysle r M oto rs, 313
Boyd, Keri, 354, 360-361 sobre engajamento das partes Chubb, PMO da, 540-544
Braaflat, Kerry, sobre PMO da interessadas e patrocinadores, " Chunking", 564-565
Boeing, 487-489 379-381 Churchill, Winston, sobre a
Brandman, Jerry, 349, 353-354 sobre pro cesso s integrados, luxúria, 92-93
Branson, Richard, sobre o 306-308 Churchill Downs, lnc. (CDI):
suporte adm inis trativo, 1 71 CDI, veja Churchill Downs, lnc. gerenciamento de portfólio na,
Bre re ton, Kerdell, 31911. 7 celebrações do"Knowvember" 583-583
Broker-011-A-Page, ferrame nta, (novembro do conhecime nto), gerenciando mudanças no
511-513 698 escopo da, 514-519
Índice 753
melhores práticas da, 20-21, gestão de riscos na, 684-689 governança da, 640-643
42,43 lições aprendidas, 690-691 iniciação de projetos na, 634 -
metodologia da, 226-229 Pirâmide do Paradigma, 684- 639
PMO da, 21, 513-519 689 melhoria contínua na, 643-
sucesso de projetos na, 26-27 PMO na, 679-684 646
ciclo de vida de desenvolvimento processo de gestão de projetos métodos de melhoria de
de sistemas (CVDS), 225-228 global da, 683-689 processos da, 645-646
ciclo do produto, 292-294 Comissão de Certificação em o fertas de soluções
ciclo do projeto, 291,292 Cestão de Projetos (IBM), 618 padronizadas da, 635-637
Ciclo PDCA, "Plan-Do-Check- comitê de controle de organização de Entrega Global
Act", 308 configurações, 328 da, 642-643
Ciclo V de produto, 293-294 Comitê de D ireção Curricular revisão das melho res práticas
Ciclo V de tecnologia, 293-294 (CSC, Curriculum Steering na, 4 7
CIP (contract implementatiou Committee) (IBM), 619 revisão/validação de soluções
proc:ess), 558-560 comitês de govemança, 78-82, 145 na, 637-638
da reza, como aç.ã o de ma rca da Como alcançar a maturidade Computer Sciences Corporation
DFCU, 352-353 em gestão de projetos, (Dave (CSC):
CLAUS (Cooper Launch Kandt), 308-309 auditoria de projetos na, 54 8-
Standard), 160-'162 compartilhamento do 551
cliente(s): conhecimento, 4 7, 628, 699-702 melhores práticas da, 528-532
atende r às neces.sidades do, competência, 360-362 P1'10 da, 528-534
274-276 centra], gestão de projetos comunicação:
como referê ncias, 29 como, 607 como competência centra],
conhecimento do, 186-187, organizacional, 607-612 421-422
391 competências interpessoais, 41 0- das melhores práticas, 48-51
divulgar as melho res práticas 411 descendente (top-doum), 526-
para os, 47 competição por financiamento de 528
expectativas dos, 106-107 projetos, 78-80 e a gestão de projetos políticos,
exte rnos/internos, 249-250, competitividade, 9, 10, 106-107, 80-82
567-568 335-336 em projetos globais, 444
foco no, 303 componente de negócios na face a face, 44 3
gerenciamento dos, 328-330 definição de s ucesso de um metodologias UPt\>tMT>• para
metodo]ogias aceitas pe los, projeto, 25 a,200
202-203 comportamento humano, 298- na Fluor Corporation, 696-
necessidades dos, durante o 299, 458 698, 701
fechamento, 253-255 compreensão por parte dos na gestão de riscos proativa,
sucesso definido pelo, 25 executivos, 9 317
clientecentrismo, 511-5 12 compromisso, 455-456 na gestão informal de projetos,
CMMI (Modelo de t\>laturidade compromisso, partes interessadas, 443-445
em Capacitação - Integração), 345-346 na IBM, 628-630
669-670 computadores, cronogramas na Naviair, 172-173
cobiça, 89-90-91-92 gerados por, 234-237 na Norte! Networks, 48-50
Coffin, H arold, sobre a inveja, Computer Associares nas regras áureas para a gestão
84-85 Technologies (CA), 632-636 de projetos, 297
colaboração, 455 abordagem da, 632-634 organizacional, 96-97, 698
Coleman, Randy, 452-453 cartilha de implementaç.ã o da, para a recuperação da gestão
coletivismo, 4 60 639-643 de projetos, 299
Collins, Kizzmett, 331-332 catálogos de ofertas de serviços Comunidade de Excelência, 487-
Collins, Mike, 631 da, 636-638 489
Colton, Charles Caleb, sobre a execução de projetos na, 63 8- Comunidade de Excelência
avareza, 89-90 643 em gestão de projetos
COMAU, 71, 678-69·1 fechamento de projetos na, (PjMCoE, Project Management
Ac.ademia de Cestão de 642-644 Comm11nity of &cellence),
Projetos da, 679-681, 689-690 ferramentas para o fe rtas 487-489
certificação PMP• na, 689-690 padronizadas da, 636-638 Comunidade de Prática (CoP,
ferramenta de registro de foco no cic1o de vendas na, Comm1111ity of Practice), 48-49,
riscos da, 684-687 637-639 487-488, 494
gerenciamento de contratos na, gestão de projetos vista po r um Comunidade de Usuários,
687-690 executivo da, 15 certificação da, 435
754 Índice
comunidades: Contractco (nome fictício), 391 na Naviair, 168-·169

na Fluor Corporation, 691-696 contratação, 442, 50"1-503 nos anos 1980, 233-235
na 1Btvl, 628-630 contratação de fornecedor único, software para, 233-235
comunidades de conhecimento, 106-107 versus planejamento, 234-235
691-696 contratos de custos Crosby, Phillip B., 308
conceito "fora dos limites" (out reembolsáveis, 185 Cros.s man, Richard Howard
of bormds), 327 contratos de preço fixo, 184 Stafford, sobre a luxúria, 92-93
conceito de ondas sucessivas, contratos EPC, veja engenharia, Crotty, Jim, sobre treinamento,
596-597 contratos EPC (Procureme11t & 438
conferência global de gestão de Construction) CSC, veja Computer Sciences
projetos, 134-136 controle do tempo, 540 Corporation
confiança, 150 controle dos cronogramas CSFs, veja fatores críticos de
de gerentes, 389-390 multinível integrados, 209-211 sucesso (CFSs, criticai success
e os clientes em reuniões de Controles da Automotive Systems factors)
revisão de final de fase, 231- Group,Johnson, 738-742 cultura, 333-372
232 controles internos, 68 como um problema de
em sistemas de gestão informal Convex Corporation, 574-576 integração nas fusões e
de projetos, 442-443 COOPANS, ·165, 171 aquisições, 734-735
conflito(s), 3 76-3 78 Cooper Launch Standard comportamental, 333-334
causado(s) por mudanças, 455 (CLAUS), 160-162 corporativa, ver cultura
de interesses, 300 Cooper Standard, excelência na, corporativa
de personalidade, 452-453 159-164 definição, 366-367
congelamento no Ciclo V, 293-294 cooperação, 335-337, 445 e a gestão de projetos nos
conhecimento: corrida armamentista, 4 mercados emergentes, 366-372
aplicações do, 4 79 corrupção, nos mercados e a implantação de mudanças,
baseado em valor, 713-717 emergentes, 368 187-188
da empresa, 112-113 CPD (commo11 prodttct e o uso da tecnologia, 460
entrega contextual de, 703 development), 263-264-268-269 e os valores corporativos, 335-
entrega preventiva de, 702 CPI, veja lodice de Desempenho 336
proprietário do, 47 de Custo - [DC (CP!, cost informal, 44 ·1
tácito, 702 performance i11dex) na Naviair, 170
conhecimento confidencial, 47 CPMO, C/ient Program na Wiirrsila, 239-240
conhecimento do negócio Management Office, 518-519 nos mercados emergentes, 366-
(competência central), 418-419 credibilidade do Pt.>10, 527-528 368
Conselho Americano de crenças coletivas, 88-89, 396-397 tipos de, 335-338
Educação (America,i Council 011 crescimento interno versus cultura corporativa, 75-76, 333-
Educatio11), 621 externo, 728-729 340
Conselho de Governança de crescimento dos riscos, 68 criaç.ã o de uma, 333-336
Gestão de Projetos, 153 crescimento externo, 728-729. da Boeing, 337-339
conselho de investimentos (CDI), Veja também fusões e aquis ições da DFCU Financial, 346-362
583-583 crescimento interno, 728 da DTE Energy, 364-365
construção de uma comunidade, criação de equipes, 119, 424-425 da Fluor Corporation, 699
559-560 criatividade, 75 da Hewlett-Packard, 365-366
consultores: crise, definição, 448-450 da lBM, 606-607, 609-612,
gestão de projetos e as critérios de adequação, 590-591 629
melhores práticas vistas por, cronograma detalhado, 208-211 da ILLUt.>UNAT, 361-364
61-66 cronograma do resumo do da lndra, 340-345
retorno sobre o investimento projeto, 208-211 da maxlT-VCS, 343-346
na fonnação dos funcionários Cronograma Integrado do da Midwest Corporation
determinado por, 4 ·14 Projeto (CIP), 430-431 (nome fictício), 338-340
consultores de lTStvl, 56-57 cronograma mestre, 208-211 da Texas lnstruments, 150
consultorias de estratégia em cronograma Nlestre do Projeto, incorporar problemas à, 75-76
marketing, gestão de projetos 257-260 metodologias criadas sobre a,
para, 62-66 cronogramas, 103, 233-235 198-"l 99
consultório odontológico, gestão como o desenvolvimento da metodologias que exigem
de projetos em um, 62 computação afetou os, 234- mudanças em uma, 202-203,
contexto (cultural), 460 236 231-232
contexto empresarial, gestão de ineficientes, 101-102 mudanças na, 333
riscos no, 319-320 multinível integrados, 208-211 na gestão de riscos, 322-323
Índice 755
cultura o rganizacional, veja Defcon Corporation (nome Departamento de Defesa dos

cultura co rporativa fictício), 1 84-186 EUA (DoD - Department of
cultura o rientada a dados, 337- defensores: Defese), 4, 6. Veja também
338 da DT E Energy, 394 indústria de defesa
culturas competitivas, 335-336 da iniciação e do Departamento de Energia dos
culturas cooperativas, 335-33 7 encerramento, 394 -398 EUA, 391
culturas fragmentadas, 335-337 de equipes de projetos, 462 dependências, 209-2 10
culturas isoladas, 335-336 para o desenvolvimento de Deployment Playl,ooks
culturas não cooperativas, 335- metodologia, 231-2 32 (Computer Assoc iares Services),
337 versus convictos, 2 3 1-232 639-643
currículos, 376-377 definição de processo, 21 desacordos, 376-378
curso "Gestão de projetos na DelGrosso, Steve: desafio da gestão de projetos,
lndra", 341-3 43 histórico de, 631 129-132
cursos de doutorado em gestão sobre a gestão de projetos desastre co m a espaçonave
de projetos, 409-41 'I empresarial na IBM, 612 Challerger, 88-89, 31 4
cursos personalizados, 41 '1-412 deliveral,les: descrição de cargos, 41 5-417
custe io : bem definidos, 267-268 desempenho:
de projetos, 731-732 equivalência para o guia como medida de sucesso, 635-
do ciclo de vida, 306, 329- PM BOK°, 221 636
330 inacabados, 97-98 e confiança no software, 224
custo de criação (de curso), 4 '11- metodologia G[P0 , 255-257 estrutura de desempenho de
412-414 Deli, Deborah (Debi) A.: valores, 714-717
custo-eficiência do Seis Sigma, histórico, 631 indicadores de, 40. Veja
570-571 sobre o Centro de Excelência t..ambém indicado res-chave de
customizaç.ã o, 634-635 em Gestão de Projetos da desempenho
custos ex cedentes, 97-98 IBlvl, 611,628,630 índice de desempenho de custo,
CVDS (ciclo de vida de Deli Services: 33 2
desenvolvimento de sistemas), e a estrutura PM3, 520-528 quadro de desempenho do
225-228 gestão de projetos na, 14 projeto, 287, 290
PMO da, 519-529 desempenho de projetos, como
DaimlerChrysler lVlotors, 313 Deloitte, 657-678 medida de sucesso, 635-636
dashboards, 33-38, 635-636 equipes de projetos na, 671-675 desemprego em mercados
de crises, 447-450 Estrutura de D imensão Pessoa] emergentes, 369
de saúde financeira da de Transformações da, 673- desenvolvimento, 195-196
empresa, 37, 38 676 desenvolvimento de novos
e a governança, 382-383 Estrutura do Gerenciamento produtos (NPD, new prod11ct
indicadores-chave de de Programas Empresarial development), 106-108
desempenho nos, 36 (EPlVI, Enterprise Program como força motriz, 9
na AVIVA Canada, 51 1-513 Management) na, 658-660 e o gerenciamento de po rtfólio,
na WWF, 601-604 Geração de Valor Empresarial 586-589
scorec.ards versus, 34 -35 (EVD, Enterprise Value gestão de riscos no, 326, 327
tipos de, 34-36 Delivery) na, 669-672 vale da morte pa ra o, 394-
dashboards estratégicos, 36, 39 gerenciamento de portfólios 396
dashboards operacionais, 34-35 na, 661-667 desenvolvimento de produto, 9
dashboards táticos, 36 gerenciamento de programas desenvolvimento de produto
datas, contratuais, 209-210. Veja na, 666-668 comum (CPD, common product
também cro nograma gerenciamento de mudanças development), 263-269
Davis, David, sobre o na, 673-678 desenvolvimento de recursos
cancelamento de projetos, 397- liderança e governança na, humanos (DRH), 474
398 673-676 desenvolvimento de uma
de Sade, lVlarquês, sobre a Mapa de Valor Empresarial estimativa de custo classe, 2 56-
luxúria, 92-93 (Enterprise Value Map"'') da, 257
De Vries, Pe ter, sobre a gula, 659-662 desenvolvimento profissional na
93-94 método de gestão de projetos IBM, 616-619
DeBellis, Tony, 622-625 na, 667-670 Design Solutions (nome fictício),
declarações de visão, 95-96, 133, variação nos projetos da, 667- 378-379
134 669 desigualdade interna, 463
dedicação nos mercados Deming, W. Edwards, 102-103, desperdício organizacional, 569-
emergentes, 370 308 570
756 Índice
determinantes de valor para as reuniões de post mortem na,

partes interessadas, 661-662 Eagelsoft, 62 33
DFCU Financial, cultura da, Eckerson, W. : sucesso de projetos na, 25, 28-
346-362 sobre dasbboards e scorecards, 29
d iagrama da espinha de peixe, 34-36 encerramento:
311 sobre os indicad ores-chave de com a estimativa a livros
diagrama lshkawa, 3·11 desempenho, 36, 38-39 abertos (OBE),216-217
dias de mapeamento (map days ), EDS, melho res práticas na, 46 na DTE Energy, 287,291
74 educação, 147. Veja t..am.bém encerramento do projeto, 226-
direção, governança e, 382-383 aprendizado; treinamento 228
diretores de treinamento, 400- em negócios, 400-402 medindo valor no, 725-727
401 fundamentos da, 408-410 na Computer Associares
di retrizes, avaliando a mudanças na grade curricular, Technologies, 642-644
maturidade com, 146 409-41 1 na lndra, 252-255
d istância do poder, 460 na IB1'>1, 626 na Rockwell Automation, 266-
d istribuição de carga de trabalho, para o suporte da gerência, 267
melho res práticas para, 21 613 na Sherwin-Williams, 270-271
documentação: planejamento de cursos para a, nos mercados emergentes, 371
escondida, 4 7 411-414 Engage, boletim informativo,
manutenção da, 98-99, ·103 retomo sobre o investimento 433-434
na seleção de projetos, 589-590 na,414 engajamento das partes
quantidade de, 439-441 efetividade, 9-1 O, 108 interessadas, 379-381
Documento de Requisitos de eficiência, 9-1 O, 13, 108 engajamento na gestão de
Marketing (DRi\>1), 266-267 Eisel, Chuck, sobre a excelência projetos, 68-69
Documento de Requisitos do na Cooper Standard, 164 engenharia, contratos EPC
Cliente (DRC), 266-267 Elenbaas, l\1.arv, sobre proteção (Procurement & Constrttction ),
Documento de Requisitos do nas ações de marca, 359-360 212, 213, 215-217
Produto (DRP), 266-267 Eli Lilly, modelo de competências engenharia de pré-detalhamento
Documento de Requisitos dos de, 416-428 (FEED, Fro11t-E11d Engi11ccri11g
Sistemas (DRS), 429-430 Elkins, 1\>lark, Sr., sobre a gestão Design), 212, 216-217
Documento de Suporte a de projetos g lobal, 632-633n.3 engenharia e a divisão de ser viços
Decisões (DSD), 263 Emerson, Ralph Waldo: (Dow Chemical), 446
Donohoe, John, sobre PMO, 545- sobre a inveja, 84-85 engenharia simultânea:
547n.24 sobre a raiva (ira), 86-87 e a gestão da qualidade total,
dores de cabeça, veja problemas empoderamento, 102-'103 303
Dow Chemical Corporation, 446 como ação de marca da DFCU, e a TQNt, 303-306
downsizing, 329-330 349-350, 357-360 e processos de gerenciamento
DTE Energy: das equipes, '1 02-103, 576-577 integrado, 313
apoio de gerência de área na, dos funcionários, 306 economias de custo na, 4 39-
394 e as regras áureas para a gestão 4 40
cultura na, 364-365 de projetos, 295-296 Enterpr ise Project Management
e as medidas de valor e o gerenciamento de processos (EPM), 475, 657-678
agregado, 331-332 integrados, 331-332 Enterprise Value 1\>!ap"', 659-
e o Seis Sigma, 564 e os gerentes de projetos, 388- 662
excelência na, 174, 192 390 entrega contextua] de
gerenciamento de processos Empresa i\>!ais Admirada da conhecimentos, 703-704
integrad os na, 331-332 América do Norte e do Mundo entrega de conhecimento
melhores práticas na, 56-61 em termos de Conhecimentos, preventiva, 702
metodologias da, 284-291 692-693 Entrega Global (Computer
Pi\>10 da, 542 empresas m ultinacionais, gestão Associares Technologies), 642-
Duarte, D. L, sobre equipes de riscos para as, 315-316 643
virtuais, 459-460 empresas não orientadas a envolvimento do pessoal, 103
Dunham, David, sobre a gestão projetos, 10, 29 EP corporativo, 518-519
de riscos, 326 Enakta: EP de grupo de clientes, 518-5'19
Dutch, Allan, sobre projetos de forças motrizes na, 10 EPM (Enterprisc Program
T I, 192-194 iniciativas de gestão de Ma11agcmcnt), 475, 657-678
D-WBS (Dc11ryok11 \V/ork projetos na, 62-66 EPMO (PMO empresarial), 504,
Breakdoum Structure), 124, 123 melhores práticas da, 21-22 540-544
Índice 757
EPO (Enterprise Program equipes de suporte, transiç.ã o especialização científica/técnica

Office), 535 para, 64 5-646 (competência central), 4 ·16-42 ·1
equipe: equipes de trabalho, 306, 329- especificação do trabalho (SOW,
ação, 460 330, 460 statement of •=rk):
central, 394 equipes de trabalho e a gestão de projetos e
composição de, 469 autogerenciadas, 306, 329-330 políticas, 78-79
de desenvolvi mento de projeto equipes em paralelo, 460 na indústria aeroespacial e de
ou produto, 460 equipes em rede, 460 defesa, 429-430
de gerenciamento de serviços, equipes funcionais, 502-507 para projetos não tradicionais,
460 Erichsen, Steen Myhre Taschner, 718
de produtos, veja equipe de 16511.12 "estado atraente", 104
projetos Ericsson, 1\>likael, 165n.12 estágio de comercializaç.ã o
de projetos virtuais, 459-460 metodologia PROPS da, 249- (desenvolvimento de novo
de trabalho, 306, 329-330, 460 253, 301-302 produto), 587-588
definição, 461 metodologias da Ericsson estimativa a livros abertos (OBE,
em rede, 460 Telecom AB, 249-253 Ope11 Book Estimate), 211-218
funcional, 502-507 erros, 408-409 Estimativa para Tenninar, EPT
liderança de, 21, 453-454 escopo de trabalho: (ETC, estimate to complete),
mensuração de desempenho definição, 208-210 431-432
para, 576-577 e os indicadores-chave de estratégia de codificação, 692-
multicultural, 170 desempenho, 29, 32 694
participação em, 458-459 linguagem do, 96-97 estratégia de personalizaç.ã o,
recompensas para, 461-464 escritório de gerenciamento, veja 692-694
suporte, 645-646 PNIO estratégias de ataque, para
suporte estratégico, 115 F.scritório de Gerenciamento de projetos políticos, 79-81
tamanho da, 570-571 Portfólios de Departamento estratégias de cadeia de valor,
equipe de análise empresa ria] de (DPNIO), 518-519 744-746
negócios, 503 F.scritório de Gerenciamento de estratégias de TUescritório do
equipe de apoio estratégico (SST, Programas, 537, 538 CIO, 503
strategy support team), 115 F.scritório de Gerenciamento de "estrela", cadeia de valor como,
equipe de Cidadãos Corporativos Programas de Clientes (CPMO, 744
Globais da Boeing, 48 8-489 Client Program J\1anagemeut estrutura analítica do projeto
equipe de garantia da qualidade e Office), 518-519 (WBS, work breakdown
conformidade, 504 escritório de gestão de projetos structttre):
equipe de planejamento e geração (PMO, project mauagement como componente crítico de
de relatórios de portfólios, 503- office), veja PMO uma metodologia, 203-204
504 F.scritório de Produtos e Denryoku, 124, 123
equipe de reengenharia de Operações, 375-376 na Churchill Downs, lnc., 516-
serviços de informação (SI), F.scritório de Programas, 535, 5·17
194-196 537, 538 na indústria aeroespacial e de
Equipe Global de Gerenciamento F.scritório de Programas defesa, 429-430
de Escalada de Conflitos, 645- Empresarial (EPO), 535 na SAP, 206-207
646 F.scritório de Projetos, veja PMO para planejamento estratégico,
equipe trabalhando em excesso, escritórios de gestão de projetos 110
153 funcionais, 518-519 Estrutura Analítica do Projeto
equipes de desenvolvimento de escritórios de projetos com foco Denryoku (Denryoku \Vork
produto, 460 no cliente, 337-339 Breakdown Str11ct11re, D-WBS),
equipes de produção, 460 escutar ativamente, 511-514 124, 123
equipes de projetos: especialistas no assunto (SMEs, Estrutura de Carreira (fBM),
conexões para além das, 702- s11bject matter experts), 695-697 618-619
703 especialização: Estrutura de Desempenho de
debriefing, para as melhores desenvolvimento acelerado por Valores (VPF, Va/11e Perfonnance
práticas, 33 meio da, 703-704 Framework), 714-717
na COMAU, 679-680 e PNICP, 469-470 E.strurura de Desenvolvimento
na Deloine, 671-675 fracasso devido à, excessiva, de Competências de Gerentes de
na metodologia CIPº , 263 89-90 Projetos, 434
recompensa para as, 461-464 na Fluor Corporation, 695-696 Estrutura de D imensão Pes.soa]
relevância das, 153 na recuperaç.ã o de projetos, de Transformações (Deloitte),
virtuais, 459-460 299-300 673-676
758 Índice
estrutura de execução de etapa de teste (desenvolvimento na DTE Energy, 'J74

projetos, 559-560 de novos produtos), 587-588 na Goodyear, 134-138
Estrutura de Investimento da etapa de triagem na Hewlett-Packard, '150-159
Deloitte, 663-665 (desenvolvimento de novos na Hitachi Ltd., 116-'129
Estrutura Global de Execuç.ã o de produtos), 586-587 na fLLUi\ {fNAT, 178-181
Projetos (Deli Services), 520- etapa pré-contratual, 228-231 na Key Plastics, 175-179
528 ética professiona1, em mercados na Kombs Engineering (nome
Estrutura Global de Programas emergentes, 3 71 fictício), 186-187
(Global Program Framework, EVD (Enterprise Value Delivery), na KONE, 129-132
GPF), 599-601 669-672 na Motorola, 147-148
estrutura PM3, 520-528 EVM (f.arned-value na Naviair, 165-174
estruturação de processos nieasurement) sistemas de, 331- na Roadway Express, 183-184
(competência central), 422-423 332 na Texas lnstruments, 14 8-
estruturas, 144. veja modelos intenção por trás do, 236-237 150
de carreira !BtVl, 618-619 KPls como components na Williams Machine Too)
de desempenho de valores, críticos do, 36, 39, 41 Company (nome fictício),
714-717 NlMVs e EPtvts versus, 727 187-188
de Desenvolvimento de EVMS (sistema de gestão do no \Vorld Wide Fund for
Competências em Gestão de va1or agregado, ea-r ned value Nature l ntemational, 139-
Projetos, 4 34 11u111agement system), 409-41 O, 143
de execução de projetos, 559- 429-432 excelência comportamental,
560 excelência, 106-188. 452-471
de execução global de projetos Veja também excelência chave da, 464-467
da Deli Service, 520-528 comportamental e a Jiderança s iruacional, 452-
de Gerenciamento de ações para a, 466-467 455
Programas Empresariais clara definição de, 25 e a resolução de conflitos, 455-
(EPM) da Deloitte, 658-660 com PMO global, 488-496 457
de Investimento da Delo itte, definição, 27, 189-194 e o gerenciamento proativo
663-665 e governança de projetos, 141- versus reativo, 467-471
de programas globais, 599- 145 para equipes de projetos
601 e metodologias, 132-134, 189- virtuais, 459-460
gerais de gerenciamento de 194 recompensando as equipes
lançamentos, 191 e o atraso na maturidade, 145- pela, 461-464
Microsoft Solutions 147 selecionando funcionários
Framework (tv!SF), 645-658 e o desafio da gestão de tendo em mente a, 457-459
Ptv13, 520-528 projetos, 129-132 excelência em gestão de projetos
substituindo metologias por, e o planejamento estratégico, global, 605-712
224-225 108-118, ')78-181 comunidades de conhecimento
estudo de caso de gestão de em gestão de projetos global, para a, 691-693
projetos, na Goodyear, 136-137 veja excelência em gestão de da COMAU, 678-691
estudos de caso, 633-634 projetos global da Computer Associares
etapa contratual, 228-231 forças motrizes para a, 10, Technologies, 632-646
etapa de avaliação pós-projeto, 3, 106-108, 134, 147-148 da Deloitte, 657-678
226-228 gerenciando premissas para a, da Fluor Corporation, 690-
etapa de desenvolvimento 139-141 704
(desenvolvimento de novos hexágono da, 301 da IBM, 606-633
produtos), 587-588 no patrocínio, 377-379 da Microsoft, 64 5-65 8
etapa de exploração passos para a, 132-134 da Siemens PL!\1 Software,
(desenvolvimento de novos reconhecendo a necessidade 704-712
produtos), 586-587 da, 150-152 excesso, de melhores práticas,
etapa de implementação de selecionando funcionários 53-54
programa/projeto, 32 'J tendo em mente a, 457-459 execução de mudanças e
etapa de planejamento (ROi), excelência, aplicações: gerenciamento de processos de
476-477 na AT&T, 132 negócios (8PM), 504
etapa de pós-programa/projeto, na Avalon Power and Light executivos, 6-9. Veja também
gestão de riscos na, 321 (nome fictício), 182-183 gerência sênior
etapa de pré-programa/decisão na Cooper Standard, 159-164 como defensores convictos da
do projeto, gestão de riscos na, na Defcon Corporation (nome iniciação e do encerramento,
320-321 fictício), 184-186 394-398
Índice 759
governanç.a deTl pe los, 382- fase de geração de relatórios na declaração da missão, 133,
389 (Ró f), 484 134
implementação por, 154 fase de identificação, 284 na Hewlett-Packard, 28-29
planejamento estratégico feito fase de implementação (PLM fato res determ inantes de
pelos, 377-378 VDM), 709 negócios, 723-724
recompensas para os, 85-86 Fase de incubação do projeto/fase Federal Express, 735
treinamento para, 407 de viabilidade, 226-228 Federal Reserve Bank of
visão dos, sobre a gestão de fase de iniciação, 226-228 Cleveland, 452-453
projetos, 13-17, 1·10 na DTE Energy, 284,286,287 FEED, veja engenharia de pré-
executivos convictos, 231-2 32, na Rockwell Automation, 264- detalhamento (FEED, Front-End
394. Veja também defensores 266 Engineering Design)
exigências dos clientes: na Sherwin-Williams, 269-270 Feigenbaum, Norman, 309
mudanças nas, 70-71 fase de liberação na Rockwell feminilidade, 460
nas regras áureas para a gestão Automation, 266-267 fenômeno do acúmulo, 98-99, 103
de projetos, 295-297 fase de maturidade, ·11, 12 ferramenta de Registro de Riscos
expectativas, 97-98, 139, 594- fase de planejamento (PLM (CólVIAU), 684 -688
597, 694-695 VD/\1), 709 fe rramenta enterProj, 177-179
expectativas de fraucJ,ise da fase de pré-alinhamento (Pl l\1 ferramentas, processo,
comunidade, 694-695 VD/\1), 707 metodologia (pirâmide de
experiência do cliente, 490-491, fase de pré-estudo, 251-252, excelência), 494
495, 496 587-590 ferramentas:
experiência técnica, na e expectativas, 594-597 para avaliações de Seis Sigma,
recuperação de projetos, 299- na Rockwell Automation, 264- 4, 573-574
300 266 para suporte à meto do logia da
propósito da, 251-252 gestão de projetos, 2 33-242,
facilitação, 455-457 fase de seleção, 284 627, 670-671
falácias que atrasam a fase de teste (PLIVI VDM), 709 ferramentas estatísticas para o
maturidade da gestão de fase de visualização (metodologia Seis Sigma, 570-571
projetos, 145-147 Gil"'), 255-256 FFE (fuzzy front e11d), 395-396
falta de honestidade nos fase dedicada à análise (Rói), Field, Owen, sobre a exce lência,
mercados emergentes, 370 480-484 179
falta de pessoal, 73 fase dedicada à coleta de dados finalização, 463
fase de aceitação pe]a gerência (Ró i), 477-480 financiamento, 72
executiva, 11, 12 fase embrionária, 9-11 financiamento, concorrência por,
fase de alinhamento (PLM fases do ciclo de vida, 8-13, 202- 78-80
VDM), 707, 709 204 financiamento de projetos, 72
fase de conceirualização do modelo Ró f, 475-484 Flemming, Quentin W., 331-332
(metodologia GfP•), 256-257 e CVDS, 225-228 flexibilidade, 202-203, 262, 263,
fase de conclusão, 251-252, 274- e metodologia, 202-204, 225- 299
275 228 Fluor Corporation, 690-704
fase de consideração, 264-265 e PlVIOs, 73-74 alternativas de design na, 695-
fase de construção (Pl lVI VDM), expandindo as, 226-228 697
709 na análise de portfólio, 592- compartilhamento de
fase de crescimento, 11, 12 596 conhecimento na, 699-700
fase de definição (metodologia na AVTVA Canada, 506-511 comunicações na, 696-698,
CIP"), 256-257 na Indra, 252-255 701
fase de encerramento (PLM para ava1iações de Seis Sigma, comunidades de conhecimento
VDM), 709 573 da, 691-696
fase de execução: superposição de, 203-204 direções futuras na, 702-704
metodologia CIPº , 256-257 fato res c ríticos de suces.so (CFSs, especialistas na, 695-696
na Computer Associares criticai success factors): exec ução de projetos na, 692-
Technologies, 638-64 3 definindo o sucesso em termos 696
na Fluor Corporation, 692-696 de, 28-29, 34-35 gerenciamento de
na Rockwell Automation, 266- e o impacto sobre os negócios, conhecimento na, 690-704
269 479 Knowledge Online" 1, 691-
na Sherwin-Williams, 270-271 e os benefícios de longo prazo, 692
propósito da, 251-252 201-202 liderança na, 696-697, 701-
fase de exec ução/co ntrole, 2 87, identificando as melho res 702
289, 290 práticas a partir dos, 2 4 pioneiros do GC da, 698-699
760 Índice
fluxo de caixa, 71-72 da gestão de riscos, 325-326 aquisições, 194-195,

fusões e
fluxogramas, 220 da governança, 382-383 728-747
Flying Tiger, 735 de indicadores-chave de avaliando resultados da
Flynn, Bonnie, 527-528 desempenho, 39 integração após, 742-744
FtvlEA (Failttre Modes and de melhores práticas, 51-52 benefícios de longo prazo em,
Effects Analysis), 311,312 de metodologias, '197-198 732-733
foco em resultados (competência de planos estratégicos, 109- da Johnson Controls, 738-742
central), 423-424 110 e a cadeia de valor agregado,
fonte, qualidade na, 99-100, 103 devido à cobiça por bônus, 90- 728-732
força, 457 92 e o crescimento interno versus
Força Aérea dos EUA, 450 devido à especia1ização externo, 728-729
forças motrizes: excessiva, 89-90 e reestruturação após fracasso,
e a maturidade, 10 devido à filtragem de 746-747
para a excelência, 106-108, informações, 87-89 estratégias de cadeia de valor
134, '147-148 devido à inflição de para, 744-746
para a gestão de projetos, 8-1 O, sofrimento, 85-87 gerenciamento da cultura na,
13-14 devido à preguiça, 91-92 353-356, 36'1-364
para as melhores práticas, 23 devido a problemas impacto na gestão de projetos,
para melhorar infraestruturas reorganizacionais, 84-86 728-729
de GP, 232-233 devido a recompensas, 85-86 relacionamento e integração
para o gerenciamento de devido a segundas intenções, proprietário-inquilino em,
benefícios, 3 87-88 737-738
Ford l\1otor Company, 411-412 devido a uma crença coletiva, tomada de decisão pré-
formação em gestão de projetos 88-89 aquisição para, 732-737
(IBM), 621 devido a uma raiva injusta, 87- Fuzzy front end (FFEJ, 395-396
formaç.ã o em gestão de projetos 88
para não gerentes de projetos devido ao desejo por poder, Gali, Krishna, sobre
(IBM), 621 92-94 monitoramento dos processos de
formação em negócios, devido ao excesso de recursos, projeto, 241-242
necessidade de, 400-402 90-91 Gamboa, Alfredo, sobre a
formalidade, 439-442 devido ao padrão sindical, 91- Conferência Global de Gestão
Forman, Mark, sobre 93 de Projetos, 134-136
gerenciamento de portfólio, devido ao patrocinador errado, ganhos rápidos, 300
596-597 89-90 garantia de qualidade, 257-260,
formas, 146, 439-440, 575-576 devido ao poder, 90-91 263
Fornecedor(es): e o patrocínio, 388-390 gateway, 239-241
com a estimativa a livros e os Sete Pecados Capitais, 83- Gay, Lee, 622-625
abertos, 215-2'17 95 GE Plastics, 453-454
da Defcon Corporation (nome em mercados emergentes, 370 Gellerman, B. 1., 716-717
fictício), 184-185 no relacionamento, 86-87 General Electric (GE), 569-570
da GM Powertrain, 249-250 no Seis Sigma, 563 General l\1otors (Gtvl), 249-250
e as expectativas dos dientes, reestruturação após, 746-747 General l\1.otors Powertrain
106-107 responsabilidade pelo, 95-97 Group:
nas regras áureas para a gestão testes para o, 576-577 especialização técnica dos
de projetos, 295-296 Franklin, Benjamin: gerentes de projetos na, 453-
fornecedores, como provedores sobre a avareza, 89-90 455
de soluções, 70-71 sobre a preguiça, 91-92 metodologia da, 248-250
fórum de gerentes de projetos, sobre a raiva (ira), 86-87 modelo de quatro fases da,
280-281 Franklin Engineering (nome 301-302
Foster Defense Group (nome fictício), 377-379 patrocínio por comitê na, 375-
fictício), 457 função de garantia, 544 376
fracasso: funcionários: George Washington University,
aprendendo melhores práticas alocação inapropriada de, 99- 62 '1
a partir do, 24, 25 100 Geração de Valor Empresarial
comparação entre sucesso e, empoderamento dos, 306 (EVD, Enterprise Va/11e
25, 26 nos mercados emergentes, Delivery), 669-672
critérios de, 576-577 369 gerência andando pelos
da gestão de projetos funcionários sindicalizados, corredores da empresa, 373-
integrada, 733 avaliaç.ã o, 338-339 374
Índice 761
gerência de área, 393-395 e os processos de mensuração de valor agregado

e gerentes de projetos, 3-4, 68, gerenciamento integrado, parao, 331-332
376-377 328-330 metodologias UPPM" ' para,
suporte da, 393-394 na indústria aeroespacial e de 200-201
versus gerente de projetos, defesa, 4 29-4 31 gerenciamento de programa:
452-454 nas organizações o rientadas a com Siemens PLM VDM, 7'10
gerência de nível mais alto, veja projetos, 333 na Deloitte, 666-668
gerência sênio r nos processos de fusões e na IBM, 613-614
gerência sênior, 464-465. Veja aquisições, 737 Gerenciamento de Programas
também executivos gerenciamento de passagens de de Serviços de Atendimento
atender às expectativas da, fase, 119, 120 ao Cliente (CSPtvl, Customer
594-597 gerenciamento de portfólio, 9 5- Service Program Management),
como de fe nsores da 96, 578-604 542
metodologia, 394 análise de portfólio no, 592- Gerenciamento de Programas
medidas de desempenho 596 Empresarial (EPM, Enterprise
suportadas pela, 41 atender às expectativas no, Program Management), 68-69
papel da, no gerenciamento de 594-597 e a excelência, 132, 133
portfólio, 580-581 avaliação preliminar no, 587- e a governança, 381-382
relatórios e reuniões 590 metodologias para, 68-70,
solicitados pela, 44 3 e relatórios de gestão de riscos, 196-202, 718-719
suporte visível da, 184, 373- 321-322 mudança no controle de
374 gerência sênior no, 580-582 processoss, 70-71
visão da, 132-133 identificação de projetos no, na IBM, 611,612
gerenciamento "por cima 584-589 para projetos não tradicionais,
da cerca .. (over-the-feuce importância do, 578-580 718-719
mauagement), 3-4 obstáculos à seleção de recomendações dos clientes
gerenciamento adaptativo, 140 projetos no, 584-585 para, 68-70
gerenciamento da satisfação com para projetos de TI, 578-579 VtvtM e EVM versus, 727
o cliente, 70, 226-228 partes interessadas no, 582- gerenciamento de recursos, 540
gerenciamento das expectativas, 583 gerenciamento de recursos
231-232 planejamento estratégico no, humanos, 200, 731
gerenciamento de aquisições, 592-593 gerenciamento do tempo,
106-107, 201,731 PMO no, 583-583 metodologias da UPPM" ' para
gerenciamento de benefícios, 2-3 processo de seleção de projetos o, 201-202
Gerenciamento de Ciclo de Vida no, 584-586 Gerenciamento Empresarial
de Produtos (PLM, Product seleção estratégica no, 589- de Tecnologia da Informação
Lifecycle Management), 15, 593 (ITEM, Tnformation Tecln10/ogy
705-712 gerenciamento de portfólio de Enterprise Managemcnt), 28 ·1-
gerenciamento de contratos na T I (Tecnologia da Informação), 282, 329-331, 563
COMAU, 687-690 578-579, 596-597 gerenciamento financeiro na
gerenciamento de crise, gerenciamento de problemas, Chubb, 540
maturidade e o, 327 196-'197, 245-246, 248, 323-325 gerenciamento/gestão:
gerenciamento de custos, 108, 200 gerenciamento de processos adaptativo(a), 140
gerenciamento de desempenho na complementares veja andar pelos corredores, 373-
Naviair, 169-1 70 gerenciamento de processos 374
gerenciamento de escopo: gerenciamento de processos contratação, 201, 731
metodologias UPPMTMpara, integrados, 301-332 custos, 108, 200
201-202 com gestão da qualidade total, de melhores práticas, 46, 55-56
na Churchill Downs, 514-519 308-313 de mudanças, veja
na Deloine, 671-672 compreendendo o, 301-303 gerenciamento de mudanças
na lndra, 253-255 e a engenharia simultânea, 313 de portfólio, veja
na maxlT-VCS, 345 e a gestão de mudanças, 328- gerenciamento de portfólio
gerenciamento de incidentes, 330 de problemas do projeto, 195-
55-56 e a gestão de riscos, 313-328 197
gerenciamento de mudanças, e a reengenharia, 329-330 de programa, 613-6'1 4, 657-
196-197 e o custeio do ciclo de vida, 678, 7'10
como um complemento à 329-330 de projeto, veja gestão de
gestão de projetos, 306 e o empoderamento, 329-330 projetos
e a gestão de riscos, 328-330 evoluç.ã o do, 303-306 de projetos políticos, 82-83
762 Índice
de qualidade, 61,201. Veja conhecimento de negócios dos, gestão de projetos, 195-197

também gestão da qualidade 112-113 benefícios da, '1 2-13, 473-474
total (TQ1Vl, total quality descrição de cargos de, 157-159 ciclo de vida da, 8-13
1nanageme11t) desenvolvimento acelerado de com TQM e engenharia
de recursos humanos, 200, 731 experiência especializada por, simultânea, 303-306
equipe, 201-202 704 como profissão, 155, 157, 232-
escopo, 201-202, 514-5 '19 e as conexões dos membros da 233, 414-416
executivo, veja suporte da equipe, 703 como um plano de carreira,
gerência; gerentes; gerência e os gerentes de área, 3-4, 68 402-404
sênior eficiência na comunicação de, de 1945 a 1960, 3-5
liderança pelo, 303 81-82 de 1960 a 1985, 5-8
.. por cima da cerca", 3-4 empoderamento de, 388-390 desenvolvimento da, 6-8
proativo, 101-103, 467-471 entrega contextua] do e cultura, 335
processos de, integrado, veja conhecimento para, 703 em indústrias manufatureiras, 9
processos de gerenciamento entrega de conhecimento ferramentas para o suporte da
integrado preventiva por, 702 metodologia da, 233-242
reativo, 467-4 71 formação em negócios para, forças motrizes para a, 8-·10,
relevância da equipe de gestão 400-402 13-14
de projetos para, 153 implementação de p lanos formal, 185, 439-442
riscos, veja gestão de riscos estratégicos por, 116-118 gerenciamento de
satisfação do cliente, 70, 226- jogo de cintura politico dos, 76 conhecimentos no contexto
228 mitos sobre os, 112-114 da, 699-702
gerenciar a comp1exidade na AT&T, 335, 415-416 "ilhas" de, 338-340
(competência central), 425 na Deli Services, 524-527 impacto das fusões e aquisições
gerenciar de perto (mapeamento na Hitachi Ltd., 116-119 na, 728-729
das partes interessadas), 79-80 na lndra, 340-341 implementação da, 8
gerente de conhecimento: na maxlT-VCS, 343-344 informal, 439-451
d ireções futuras para o, 702- orientação e aconselhamento malentendidos em relação à, 5
704 de, 137-138 modelos de, 714-717
estratégias de codificação e poder e influência dos, 82-83 moderna, 399-401
personalização, 692-694 seleção dos, 457-459 na construção, 61-62
na Fluor Corporation, 690-704 versus a maturidade dos na educação superior, 62
no contexto da gestão de clientes, 153-154 na IBM, 606-614
projetos, 699-702 gerentes de treinamento, 400- necessidade da, 5-6, 11
no suporte à execuç.ã o de 401, 409-410 no ambiente da pequena
projetos, 692-696 gerentes funcionais, 5, 376-377 empresa, 61
gerente de programas, descrição gerentes intermediários, 6 no setor de saúde/categoria
de cargo para a AT&T, 416 Gerrity, Patrick, 540u.23 odontológica, 62
gerentes: Gerstner, Lou: padronização da, 544-546
confiança nos, 389-390 e a IBN-1 como uma empresa para consultorias estratégicas
de níveis mais baixos, 388- baseada em projetos, 612 de marketing, 62-66
389 sobre a matriz da IBM, 606 para o p lanejamento
de projetos, veja gerente de gestão da qualidade, estratégico, 108-11 8, 1 78-
projetos sênior, veja gerência metodologias UPP~1_TM para, 181
sênior como patrocinadora, 201 recuperação de projetos na,
veja treinamento de gestão da qualidade total (TQM, 297-300
patrocinadores executivos, total quality management), 303 regras áureas para a, 294-297
400-401, 409-41 O e a engenharia simultânea, relaç.ã o com o Seis Sigma, 562-
formação para não gerentes de 303-306 564
projetos, 407 e Seis Sigma, 567-568 treinamento para, 234-235,
funcionais, 5, 376-377 ferramentas Seis Sigma com, 399-401
suporte visível dos, 184, 373- 310-312 valores da, 335-336
374 na Johnson Controls, 308-310 vantagens da, 7-8
gerentes de níveis mais baixos, processos da Sprint para, 303 vista por um consultor, 61-66
388-389 processos integrados de vista por um executivo, 13-17,
gerentes de nível mais alto, 6 gerenciamento com, 308-313 110
gerentes de projetos (GPs): gestão de mudanç.as gestão de projetos avançada,
certificação dupla para, 407 organizacionais (OCM, 400-401
com responsabilidade Organizational Change gestão de projetos básica, 400-
integrativa, 7 Management), 526-527 401
Índice 763
gestão de projetos integrada gestão de riscos/oportunidades, govemança em diversas camadas,

([Ptvl, Jntegrated Project 295-296, 312-313 506-508
Managcm.cnt): gestão formal de projetos, 185, govemança geograficamente
fracasso da, 746-747 439-442 despersa, 381-382
na Tech l\1ahindra Ltd., 434- gestão informa] de projetos, 5, governança projetizada, 381-382
438 439-451 Governo:
gestão de projetos orientada à comunicações na, 4 43-445 e os mercados emergentes, 368,
valor, 713-727 confiança na, 442-443 369
captar, medir e reportar valor cooperação na, 44 5 fracasso devido à filtragem de
na, 719-727 e os dashl,oards de crise, 44 7- informações no, 87-89
comitê de patrocínio na, 722- 450 ambiente de terceirização do,
723 e os relatórios de status com 185
e a evolução do conhecimento códigos de cores , 446-44 7 melho res práticas do, 7-8
baseado em valor, 713-717 equipes na, 445-446 GPF (Global Program
e tipos de projetos, 718-720 na Boeing, 450-451 Framework), 599-601
estilo de liderança na, 716-718 na Polk Lighting (nome GPs, veja gerentes de projetos
Nletodologia de Mensuração fictício), 450 (GPs)
de Valores (l\1N1V), 726-727 versus gestão formal de grade curricular central
partes interessadas na, 722 projetos, 439-442 (formação em gestão de
trade-offs de valor na, 726-727 Ghisolfi, Alexandre S6rensen, projetos), 409-41 O
gestão de riscos: 29 7-300 grá ficos de responsabilidades,
como competência central, GIJ>°(Gestión Integrada de 455
420-421 Proyectos), 255-264 grandes empresas, 338-340
contemporânea, 306 Githens, Gregory, sobre a gestão Gray, Mark:
definindo a maturidade de riscos, 326-327 sobre melhores práticas, 48-49
usando, 326-327 Gladwell, Malcolm, 703 sobre verificação da "saúde"
e a gestão de mudanças, 328- GM (General Motors), 249-250 do projeto, 552-553
330 GM Powertrain Group, veja Greed, sobre ambiente de projeto,
e o desastre com a espaçonave General Motors Powertrain 89-92
Challenger, 314 Group Greer, Rusty, 657-658n.6
e o gerenciamento de Gohl, Terry, sobre a ferramenta Gregerson, Steve, sobre processos
problemas, 323-325 enterProj, 178-179 integrados, 305
e o serviço de atendimento ao Goleman, Daniel, 104 Griffin, A., sobre fuzzy front end,
cliente, 315 Goodyear, excelência na, 134-138 395-396n.8
e os processos integrados de governança, 141-145 C rimes, Tracy F., 528-529
gerenciamento, 313-328 com a Siemens PLM VDM, Grupo de Controle de Q ualidade
efetivo, 319-320 710 (QMG, Quality Ma11agement
em organizações do ramo da e a entrega de projetos, 523- Group), 61
saúde, 306 525 Grupo de Sistemas de Veículos
fracasso da, 325-326 e a Microsoft Solutions Pesados, 442
metodologia do Ciclo V para, Framework, 647, 653-658 Grupo de Sistemas e Tecnologia
293-294 e o suporte da gerência, 380- da 1Btvl, 15
metodologia UPPM" ' para, 389 Grupo Fiar, 14
201-202 na AVIVA Canada, 506-514 grupos de estudos de PMPs'",
na Boeing Aircraft, 327-328 na Computer Associares 432-434, 559-560
na COMAU, 684-689 Technologies, 640-643 Guerra Fria, 4
na fase de fechamento, 253- na Computer Sciences Guia do Progresso da
255 Corporation, 531-533 Nlaturidade da Gestão de
na fLLUtvUNAT, 319-320 na Deloitte, 673-676 Projetos (PNlPl\1G, Progress
na indústria aeroespacial e de na Fluor Corporation, 69 3-69 5 Maturity Guide), 627-628
defesa, 430-431 no Tokio Nlarine Group, 382- Guia l'MBO~ (Project
na metodologia, 230-231, 255- 389 Management Body of
264 por executivos, 382-389 Knowledge):
na Microsoft Solutio ns governança adaptativa, 507-508 alinhando metodologias ao,
Framework, 652-654 governança autocentrada, 506- 221-223, 278-281, 622, 669-
na recuperação em gestão de 509 670
projetos, 299 governanç.a co]ocalizada, 381- áreas de conhecimento do, 731
na Wiirrsila, 316-318 382 e a execuç.ã o de projetos
proativo, 316-318 governanç.a da execuç.ã o de estratégicos, 111
gestão de riscos técnicos, 3 14 projetos, 523-525 e cultura, 341-342
764 Índice
e o PMO da COMAU, 679-680 melhores práticas da, 28-29 IBM Academy, 611
grupos de processos de gestão 1\>létodo Global da, 152 IBM Solutions lnstitute, 611
de projetos no, 330-331 processos e metodologias, 152 ILL (lnternational lnstitute for
limitações do, 222-223 hierarquia organizacional em Learning), 404-408, 41 '1-412
sobre o envolvimento das mercados emergentes, 367-368 ILLUMINAT (Trinidad &
partes interessadas, 43 Hirshfield, Marc: Tobago) Ltd.:
Guia Profissional da Gestão de sobre a cultura da maxlT-VCS, cultura corporativa na, 361-
Projetos (IBM), 626 343-346 364
Guida, Roberto, 678-67911. 7 sobre melhores práticas, excelência na, 178-181
gula, no ambiente de projetos, 2111.16 gerenciamento de processos
93-95 sobre PNIO da maxlT-VCS, integrados da, 319-320
49611.14 gestão de r iscos na, 319-320
habilidades e competências sobre suporte dos gerentes, impacto, mensuração de, 599-602
(pirâmide de excelência), 492- 392-393 impacto dos programas de
493 Hitachi Ltd.: treinamento sobre os negócios,
habilidades processuais F.strutura Analítica do Projeto 479-480
(competência central), 416-417, Denryoku da, 124, 123 implementação, 195-196
421-423 excelência na, 116-129 como meta, 145-146
Halicki, Dan, sobre metodologias gerenciamento de passagens de custos versus benefícios da, 13
da Medical !Vlutual, 272-276 fases na, ·119, 120 de melhores práticas, 50-52
Halifax Community Health iniciativas de fortalecer a de metodologias, 230-234
Systems, 20 capacidade de gestão de de planos estratégicos, 116-118
Handley, Kristin L., 159n.11 projetos na, 116-123 e cultura, 187-188
Hansler, Jim, sobre gestão de Holcim Group, metodologia da, em mercados emergentes, 370-
projetos na HP, 150-151 275-279 371
Harris Corporation, 427-432 Horner, Brad, 528-529 erros na, 232-233
Health Care Associares (nome Hornwall,Jan, sobre gestão de liderança na, 145
fictício), 391-392 projetos global, 70411.9 metodologia ASAP para, 205-
Herbert, George, sobre a gula, HP, veja Hewlett-Packard 209
93-94 HP Services, veja na Hitachi Ltd., 119
Hershock, Robert: Hewlett-Packard Services (HP) na Roadway Express, 184
sobre a liderança, 373-374, Hubbard, D. W., sobre papel dos executivos na, 154
453-454 mensuração e KPls, 40 pequenos versus grandes
sobre membros da equipe, Hultman, K., 716-717 projetos para, 147
458-459 Huxley, Elizabeth, sobre superando barreiras à, 232-234
sobre o fracasso, 388-389 preguiça, 91-92 lnaba, Yuichi "Rich", 382-389
Hester, Jeff, 690-69111.8 Hynes, Martin D., 416-417 incentivos. Veja também
Hewlert-Packard (HP): recompensas
cultura da, 365-366 1BC, para treinamento, 481 para as melhores práticas, 22
excelência na, 150-·159 IBM, 606-633 para equipes de projetos, 461-
gerenciamento de processos competência organizacional 463
integrados na, 329-331 em habilidades de gestão de incertezas, 256-257, 316-318,
indicadores-chave de projetos na, 607-612 460
desempenho na, 29 cultura da, 606-607, 609-612, incógnitas, verdadeiras, 79-80
melhores práticas da, 49-50, 629 incorporação, 502-503
53-57 currículo de GP na, 619-622 indicadores de aceitaç.ã o pós-
metodologia da, 281-284 desenvolvimento profissional entrega, 31-32
patrocínio na, 378-379 na, 616-619 indicadores de desempenho (Pls,
PtVIOs da, 71, 544-547 gestão de projetos, programa e performance indicators), 40
sucesso de projetos na, 28-29 portfólio na, 613-614 indicadores durante o processo,
suporte dos gerentes na, 3 78- gestão de projetos como 32
379 competência central na, 607 indicadores orientadores, versus
treinamentos na, 437-438 gestão de projetos vista por um KPls, 36
Hewlett-Packard Services (HP), executivo da, 14-15 indicadores-chave de desempenho
152 melhores práticas da, 625-631 (KPls), 36, 38-41
compromisso com a gestão de metodologias da, 622-625 definição, 723
projetos, 152 PMOs na, 614-615 e os fatores determinantes de
gestão de projetos vista por um prêmios da, 630 negócios, 723-724
executivo da, 16 suporte da gerência na, 612-613 e treinamento, 4 79
Índice 765
efetividade, 38-39 ineficiências, em mercados !TIL (IT lnfrastructure Libra ry),

em dashl,oards, 36, 447-448 emergentes, 369 54-55, 495
fracasso de, 39 influência, 81-83 ITS (I11formatio11 Tech110/ogy
identificando melhores práticas infonnação: Services), 56-57, 331-332
para os, 24 acesso à, 21
ind icadores o rientadores filtragem de, 87-89 Jackson, Brad, sobre gestão de
versus, 36 informalidade, 439-442 projetos, ·15
na declaração da missão, 133, lnformation Technology Services Jackson, Frank:
134 (ITS), 56-57, 331-332 sobre a informação como
selecionando, 40-4 1 infraestrutura, para dar s uporte à poder, 388-389
sucesso em termos de, 29-35 cadeia de valor agregado, 731 sobre liderança, 453-454
versus outras medidas de ingressar (em uma empresa), sobre membros da equipe, 459
desempenho, 40-4 1 502-503 James-Cramer, Cynthia, sobre
indicadores-chave de resultados iniciação do projeto, na a c ultura de gere nciamento em
(KRls, key res11/ts i11dicators), 40 Computer Associares fusões, 361-364
índice de desempenho de c usto - Technologies, 634-639 jargão de negócios, 506-507
IDC (CPI, cost performance iniciar ações (competências JCI, veja Johnson Controls, lnc.
i11dex), 237-23811.14, 332, 4 31- centrais), 419 Johnson, E. LaVeme, sobre os
432 inimigos, em projetos políticos, treinamentos do [JL, 404-408
índice de desempenho de prazo 79-80 Johnson, Eric Alan:
(SPI, sched11/e perfonnance inimigos, verdadeiros, 79-80 sobre a cultura, 337-338
i11dex), 237-23811.14, 4 31-432 inquilinos, 737-738 sobre Seis Sigma com TQ!\1,
índice de satisfaç.ã o do cliente insegurança, dos executivos dos 310-312
(ISC), 244-249 mercados emergentes, 368-369 Johnson, Samuel, sobre a avareza,
individualismo, 4 60 Instituto de Gestão de Projetos 89-90
lndra: (PMr"J, 405, 491-492n.9, 526- Johnson Controls, lnc. QCI):
fechamento de projetos na, 527, 616, 620, 621, 689-690 cultura do gerenciamento da
252-255 instrutores, 4 11-4 14 qualidade total na, 309-310
cultura da, 335-336, 340-345 instrutores externos, 41 3-414 excelência na, 408-409
forças motrizes na, 1O integração, para fusões e fusões e aquisições da, 738-
gestão do valor agregado na, aquisições, 737-738 , 742-744 742
237-238 lnternational lnstitute for gere nciamento de processos
gerenciamento de processos Learning (fll), 404-408, 411- integrados na, 303
integrados, 323-325 41 2 gestão de projetos e TQ1VI na,
suporte da gerência na, 393 inveja, no ambiente de projetos, 308-309
metodologia da, 228-231, 252- 84-87 sucesso na, 308-309
255 investigação apreciativa, 136 joint ventures, 728-729
PMO na, 487 investimento tardio, nas jornada rumo à lide rança da
gerenciamento de portfólio na, melhorias na gestão de projetos, Holcim (Holcim Leadership
583 232-233 Jour11ey), 277-278
sucesso de projeto e programa investimentos, em melhorias na Juran, Joseph M., 308
na, 27, 30-31 gestão de projetos, 232-233
gestão de projetos na, 41 6 [PlVI (l11tegrated Project Kallas, Siim, sobre a regulação da
e nvolvimento das partes Ma11agement), 434-438, 746- navegação aérea, 165
interessadas na, 4 3 74 7 Kãmi, Anni, sobre as ferramentas
melhores práticas da, 21, 45- ira, no ambiente de projetos, da gestão de projetos, 239-240
46, 49-50 86-89 Kandt, David, 73811.2
indústria de de fesa: lridium LLP, 88-89 e as melho res práticas na
e os escritórios de projetos ISC (índice de satisfação do Cooper Standard, 159-160
focalizados no cliente, 337- cliente), 244-249 sobre a c ultura da gestão da
339 ISO 9000, 309-310, 439-440 qualidade total na Johnson
desenvolvimento de novos ITEM, veja Gerenciamento Controls, 309-3'10
produtos na, 106-108 Empresarial de Tecnologia sobre a excelência, 408-409
treinamento e m gestão de da Informação (lnformation sobre o ISO 9000, 309-310
projetos para empresas Tedmology Enterprise sobre o s ucesso na Johnson
contratadas, 4 27-432 Management) Controls, 308-309
nos anos 1950 e 1960, 4 ITIL (lnformation Tech110/ogy Kapur, Copa), sobre os s inais
indústrias manufatureiras, 5-6, 9, Information Li/,rary), 281-284, vitais de projetos cruciais, 581-
569-570 563 582
766 Índice
Keithley, Tara, 690-691n.8 licitações co mpetitivas, 71 -72, lV!anello, Carl:

Kerzner, Harold, 337-33811.2, 376-377 sobre CSFs e KP!s, 32
678-679, 690-691 Líder de Negócios, 379-381 sobre gerenciame nto de
Key Plastic.s, excelência na, 175- liderança, 452-454 portfólio, 578-579
179 como compe tência central, sobre metodologias, 222-228,
Khendry, Anu: 41 6-417, 423-428 232-233, 237-240
sobre o índice de satisfação do de equipes, 453-454 sobre PlV!Os, 534-541
cliente, 245-246 de equipes fu ncionais, 503-504 lV!ansbridge, Bob, sobre
sobre o monitoramento dos de pe nsamento, 500 processos integrados, 305-306
processos de projetos, 241- e o patrocínio executivo, 389- manter informadas (mapa das
242 390 partes interessadas), 80-81
KidweH, Kerry, sobre ser um e valores, 716-718 manter satisfeitas (mapa das
especialista, 360-361 estratégia de gestão de partes interessadas), 80-81
KieJJ, Ed, sobre a excelência na projetos, 115-117 manutenção:
Cooper Standard, '164 na AVIVA Canada, 499-500 de documentação, 98-99, 103
Kingsto n, Keith, sobre os na Deloitte, 673-675 de projetos, 102-102
sistemas de mensuração de valo r na Fluor Corporation, 696- de restrições, 94-96
agregado, 331-332 697, 70'1-702 lV!any Methods of l earning™,
Kinsey, Tama S., 528-529 na Holcim, 277-278 404
Kodak, 303 nas fusões e aquisições, 736-737 ma peamento da fase de atividade,
Kombs Engineering (nome no gere nciamento, 303 283, 284
fictício), 186-187 no gere nciamento de portfó1io, mapeamento das partes
KONE, excelência na, 129-132 580-583 interessadas, 79-81
Konechnik, Thomas J ., 416-41 7 programas para a, 303 ma rcos, 155, 209-210
KP!s, veja indicadores-chave de situacional, 452-455 definição, 251-253
desempenho (KPls), uso de software versus, 235-237 em modelos de trabalho, 252-
KPMG, 319 Líderes de Excelência Global, 253
KPRP (Key Product Realization 694-695 incentivos nos, 4 62-4 63
Process), 175-177 Lincoln, Abraham, sobre na implementação de
Kreiner, Kevin, sobre excelência preparação, 256-257 metodologias, 228-230
na Cooper Standard, 164 língua, 96-97 na metodologia do Ciclo V,
KRls (key results indicators), 40 listas de problemas dos projetos, 293
Kumar, Alok, 73811.2 273-275 na Microsoft Solutio ns
Kumorowski, Sandra: listas de verificação, 146, 4 39- Framework, 650-651
sobre as forças motrizes, 1O 440, 576-577 organizacionais, 155
sobre as melhores práticas, 21- Livros de Registro de Ntares, Lee Ann, sobre a
22, 61-66 Aprendizagem, 435-437 proposição de valor da DFCU,
sobre as reuniões de post logística (Pirâmide do Sucesso), 347
mortem, 33 150 ma rketing, com Siemens PLN-1
sobre o sucesso de projetos, 25 LSTK Contracts, 21 2, 216-2 18 VDl\1, 710
Kungl, Janet, sobre as Lucas, Tom: ma rketing, gestão de projetos no,
metodologias do Westfield a gestão de projetos na visão 62-63
Group, 278-282 de, 14 lVlarkgraf, Stephen, sobre PMO
Kytonen, Sherry, sobre PMO na visão de, sobre a Sherwin- na Boeing, 487-489
Boeing, 487-489 Williams, 271-272 lV!arkham, Stephen:
lucro, 73, 569-570 sobre defensores convictos,
l ahr, John, sobre a luxúria, 92-93 Ludw ig, H elmuth, sobre a gestão 394-395
l alinerré, lan, 498n.15 de projetos, 15 sobre o vale da morre, 394-396
Landor, Walter Savage, sobre a luxúria, no ambiente de projetos, lV!arrine, J ohn, 631
avareza, 89-90 92-94 lVlarryniuk, Daniel, 657-65811.6
Law, Vernon, sobre experiência, Lyman, Christine, 657-65811.6 sobre gerenciame nto de
98-99 Lyons, Steve, sobre metodologia, portfólio, 662-664
l ei Sarbanes-Oxley, 548 219n.11 sobre liderança e govema nç.a,
leis, nos mercados emergentes, 673-675
367, 368 l\1altzman, Rich: masculinidade, 460
Lewis, C. S., sobre orgulho, 88- e o Prêmio PtV!O do Ano, 557, material didático (educação),
89 559-560 409-410-4 10-41 1
Jicirações, sobrevivência à base sobre os valo res dos PMPs•, matérias eletivas (formação em
de, 71-72, 376-377 432-434 gestão de projetos), 4 10-411
Índice 767
matriz de gerenciamento de direcionadores de , 23 implementação da gestão de

portfólio, 578-580 e definições de sucesso de projetos nos, 370-371
maturidade: projetos, 24-32 recomendações para os, 371-
de gerentes de projetos versus em busca das, 22-33 372
clientes, 153-'154 fracasso das , 5'1-52 status e politicagem nos, 368-
de organizações híbridas, 1O garantir o uso das, 50-51 370
definindo a, usando a gestão gerenciamento das, 46, 55-56 mesa-redonda trimestral, 505
de riscos, 326-327 identificando as, 22-24 "mesas-redondas de discussão"
e a recuperação para gestão de implementação das, 50-52 (Alcatel-Lucent), 433-4 34
projetos, 298 níveis das, 24, 44-46, 52-53 meta clara, grande, "cabeluda"
e as forças motrizes, 1 O para a recuperação para gestão e audaciosa (BHAG, a clear
e o gerenciamento de de projetos, 298-299 big, hairy\ a11d audacious goal),
premissas, 139 processo de, '17-18 499-500
e tendências de treinamento, revalidação das, 46-4 7 metas:
407 simplicidade das, 24 alinhamento de, 576-577
em empresas não orientadas a templates para, 43, 47, 48 BHAG, 499-500
projetos, 1O uso dos termos, 19 como ações de marca da
falácias que atrasam a, 14 5- usos das, 47-4 8, 50-51 DFCU, 348-3 49
147 utilidade das, 4 5 do Seis Sigma, 567-569
mensuração da, pela IBM, 627- va1idar as, 41-4 3 falácias sobre, 145-1 46
628 vistas por um consultor, 61-66 na e tapa de planejamento,
metodo]ogias criadas ao redor me lhores práticas específicas da 252-253
da, 198-199 indústria, 44-45, 48 na N1icrosoft So1utions
modelo para a, 539-541 me lhores práticas específicas de Framework, 650-652
na Alcatel-Lucent, 560-561 projetos, 44-45, 48 método do diagrama de
organizacional, 326 me lhores práticas específicas do precedência (PDtVI, Precede11ce
para a sobrevivência, 1 85-186 setor da empresa, 44-45, 48, 73 diagrammi11g method), 233-235
velocidade da, 11 me lhores práticas individuais, método do diagrama de setas
Ntaurice, Eric, sobre a verificação 44-45 (ADM, Arrow diagrmnmi11g
da saúde do projeto, 552-553 me lhoria contínua, 304 method), 233-235
maxlT-VCS: e as tendências de tre inamento, Método Global HP, 16, 152
cultura da, 343-346 407 Método l\1undial de Gestão
a gestão de projetos vista por modelo D,VIAJC para, 310-31 1 de projetos (Worldwide
um executivo da, 16 na Computer Associares Project Mauagement Method,
suporte da gerência na, 392- Technologies, 643-646 WWPt\>lM), 622-625, 627
393 na Teradyne, 220 metodologia do Ciclo V, 291-295
PMO da, 496-498 me lhorias, forças motrizes para, metodologia Ágil:
projetos e programas de 232-233 definição, 198-199
sucesso da, 3 1 me lhorias nos processos, na CA e o encerramento do projeto,
melhores práticas da, 21, 42 Technologies, 645-646 253-255
NkAdams, J., sobre recompensar membros de equipe, 458-459 na Deloitte, 670-672
equipes de projetos, 461 t\>lenke, Tim: na IBM, 624-625
t\>ICI, 388-389, 453-454, 459 sobre a cultura da DTE Energy, na t\>ledical t\>lutual, 274-276
tV!cQuary, John, 690-691n.8 364-365 metodologia ASAI' para
megatendências empresariais, sobre a metodologia da DTE implementação, 205-209
498-499 Energy, 284-291 metodologia da Repsol
melhores práticas "restritas", 4 7 sobre o processo de Exploração e Produção (Repsol
melhores práticas e práticas crescimento da DTE Energy, E&P), 255-264
comprovadas, 1-66 174 Meto dologia de Desenvolvimento
aplicação inadequada das, 51- sobre PMOs, 542 de Software (SDI\1, Software
52 mensuração, 40. Veja também Development Methodology),
a prendidas com fracassos, 24 métricas da Medical N1utual, 96-97
comunicar as, 4 8-51 metodologias das, 272-276 metodo logia de entrega de valor
crenças sobre as, 50-52 mensuração de desempenho, 4 1, do gerenciamento do ciclo de
de 1945 a 1960, 3-5 576-577, 635-636 vida de produtos (PLM VDt\>I),
de 1960 a 1985, 5-8 mercados emergentes, 366-372, 707-712
de 1985 a 2014, 8-13 671-672 Meto dologia de Gerenciamento
definições de, 18-22, 54-56 barreiras nos, 3 71 de Liberação, 191, 281-283,
descoberta de, 33 cultura dos, 366-368 378-379
768 Índice
Metodologia de Serviços s istemas de software de Jvlidline Bank (nome fictício),

Profissionais (Profserv), 361-364 suporte para, 233-242 389-391
metodologia [Pl\1Jvl, 340-342 substituindo, por modelos, Jvlidwest Corporation (nome
metodologia Projetos 224-225 fictício), 338-340
Selecionados (fBlVI), 627 superando barreiras, 232-234 IVlidWest Financial Credit Union,
Metodologia Unificada de metodologias com foco no 354, 356,357
Gestão de Projetos'" (UPMM" ', cliente, 291-292 Jvlillhollan, Chuck:
Unified Project Management• metodologias da indústria sobre metodologia, 226-228
Methodo/ogy), 198-202, 405 bancária, 194-196 sobre PlVIO na CDI, 513-515
metodologias, 189-300. metodologias de desenvolvimento sobre gerenciamento de
Veja também metodo]ogias de projetos, 192-195 portfólio, 583-583
específicas metodologias de gestão de sobre sucesso de projetos, 26-
aceitação das, 202-203 projetos de alto nível, veja 27
aluguel de, 272-276 metodologias sobre definição de escopo e
barreiras às, 232-234 metodologias padrão, 201-203 mudança de controle, 5 '14-
benefícios essenciais das, 20·1- metodologias preditivas, 198- 519
203 'l 99 sobre as melhores práticas,
características das, 202-204 métodos quantitativos, 306 21n.14,42, 43
características de design das, métricas. Veja também métricas Jvlills, Stephanie, 531-532
217-218 específicas Jvlinnesota Power and light, 459
como problema nas fusões e da lndra, 21 míssil de ataque de curto alcance
aquis ições, 733, 734 evolução das, 3 9 (SRAJvl, short-ra11ge attack
componentes críticos das, 202- falta de, 95-96 missile), 450
205 fora de tolerância, 44 7-448 MM V (Metodologia de
definição, 141 identificando, 95-96 Mensuração de Valores), 726-
desenvolvidas internamente, para análise de valor agregado 727
268-269 (EVA), 331-332 modelo de controle, 4
desenvolvimento de, 228-231 para mensuração de valor, modelo de equipe, na Microsoft
e a cultura corporativa, 202- 723-727 Solutions Framework, 649-651
203 para objetivos, 133-134 modelo de funções de gestão de
e a tolerância a riscos, 744-746 para PMOs, 487 projetos (fGP), 222-224
e as fases do ciclo de vida, 202- pipeline, 441-442 modelo de gerenciamento de
203, 225-228 usos das, por gerentes de 9-passos, 564
e excelência, 132-134, 189- projetos, 113-114 modelo de gestão de projetos
194 ~1.etz.eler Automotive Profi1e com quatro pontos de decisão e
em fusões e aquisições, 737- System, processos integrados nove passos, 192-193, 564
738 da, 305 modelo de planejamento e
empresariais, 196-202 Meyer, David H., 528-529 controle de ciclo de vida, 4
fracasso de, 197-198 microgerenciamento, 382-383, modelo de reforço, 462
implementação de, 230-234 389-390 modelo DMAIC, com TQlVI,
incorporando melhores l\1icrosoft Corporation, 645-658 310-311
práticas nas, 4 2 Microsoft Project, 235-236 modelo do Boston Consulting
leves, 198-199 Microsoft Solutions Framework Group (BCG), 742-744
manutenção das, 42 (lVISF), 645-658 modelo fGP (funções de gestão
mensuração de valor das, 726- critério de sucesso na, 653-658 de projetos), 222-224
727 e governança, 64 7, 653-658 modelo híbrido-federado, 502-
múltiplas, 84-86, 96-97, 189 flexibilidade da, 647-648 503
na cadeia de gestão de gestão de riscos na, 652-654 modelo PRO PS, 250-253, 301-
projetos, 732 marcos na, 650-651 302
para funções de gestão de melhores práticas na, 649 modelo retorno sobre
projetos, 222-224 metas na, 650-652 investimento (ROi), 475-484
para PMOs, 497 modelo de equipe na, 649-651 fase de análise de dados, 480-
para projetos em vias de para o planejamento proativo, 484
fracassar, 297-300 657-658 fase de coleta de dados, 477-
para projetos globais, 704-T I 2 processo de controle de 480
pesadas, 198-202 mudanças na, 651-652 fase de geração de relatórios,
processos de gestão de riscos templates na, 652-653 484
em, 230-231 Middleton, C. J., sobre os fase de planejamento, 476-477
reconhecendo as necessidades benefícios da gestão de projetos, modelo ROi, veja modelo retorno
por, 192-197 473 sobre investimento (Ró i)
Índice 769
modelos. Veja t.m nbém estruturas melhores práticas, teoria da, 33 nível 3 planejamento (cro nograma
competência central, 416-428 sistemas de mensuração de detalhado), 208-211
conceituais, 140-142 valor agregado na, 331-332 Nores, Roberto, 275-276n.21
controle de, 4 tv!SF, veja Microsoft Solutions Norte! Networks:
de competência, 416-428, 558- Framework comunicações na, 4 8-50
559, 576-577 tv!udança(s): gestão fonnal de projetos na,
de gestão de pro jetos co m e co nflitos, 4 55 441-442
quatro pontos de decisão e exigências para, veja exigências gestão de projetos vista por um
nove passos, 192-193, 564 para mudança executivo da, 16
de planejamento agregado, na cultura corporativa, 202- projetos integrados na, 305-306
592-593 203, 333 sucesso de projetos na, 30
de planejamento e controle de nas exigências dos clientes, 70- no tícias ruins, 7 5
ciclo de vida, 4 71 Novo Modelo de Negócios, 741
DMAIC,310-311 no gerenciamento de NPD, ver desenvolvimento de
do Boston Consulting Group, benefícios, 3 novos produtos (NPD, New
742-744 mudanças no escopo: Product Developme11t)
equipe, 649-651 gerenciando, 328-330 NXP Semiconductor:
híbrido-federado, 502-503 na Churchill Downs lnc., 5 ·14. melhores práticas da, 4 8-49
para funções de gestão de 519 verificações da "saúde" do
projetos, 222-224 no gerenciamento de portfólio, projeto na, 552-553
probabilísticos, 312-313 596-597 Nyberg, Benny, sobre habilidades
PRO PS, 250-253, 301-302 problemas com, 72-73 de negócios, 400-402
reto mo sobre investimento mu1tigerenciar os projetos, na
(Ró i), 475-484 Holcim, 277-278 O'Sul1ivan, Martin, sobre gestão
modelos conceituais, 140-142 múltiplos Ptv!Os, 71 de projetos, 16-17
modelos de competências, 4 16-428 tv!urthy, A. S., sobre a gestão de OBE (Open Book Estimate),
da Alcatel-Lucenr, 558-559 projetos, 15-'16 2 ·11-218
da Eli Li lly, 41 6-428 tv!usil, Jan, 204-20511.9, 402n.1 o bjetivos:
para Seis Sigma, 576-577 tvlutchler, Michael, sobre as de programas de treinamento,
versus descrição de cargos, empresas co m fo co no produto, 476, 477
41 6-417 249-250 dos PMOs, 517-518
modelos de compe tências e declarações de missão, 133,
centrais, 41 6-428. Veja também não gerentes de projetos, 134
modelos de competências fo rmaç.ã o em gestão de pro jetos no planejamento estratégico, 'l 'l O
modelos de planejamento para, 407 para fusões e aquisições, 732
agregado, 592-593 Napoleão Bonaparte, sobre a obrigações sociais, em mercados
modelos probabilísticos, 312-313 pressa, 256-257 emergentes, 369
monitoramento de desempenho, National City Corporation, 735 OCtv! (Orga11izational Change
na Holcim, 277-278 Naviai r,excelência na, 165-174 Ma,uigement), 526-527
monitoramento dos cronogramas Neal & tvlassy Holdings, Ltd., o ferta de ferramentas
multinível integrados, 209-211 17, 361-362 padronizadas (Computer
monitoramento dos processos de Neal, Jeffrey Alan: Associares Services), 636-638
projetos (PPtvl, project process sobre a c ultura, 337-338 Ohio Bell, 452-454
monitoring), 241 -245 sobre Seis Sigma com TQM, Oosterveer, Peter, sobre
monitorar os benefícios, 3 310-312 o comparriJhamento de
motivação, em mercados necessidades do cliente, atender conhecimento, 699
emergentes, 370 às, 274 -275 operações (pirâmide de
1\>!otorola: Neubert, Sherry: excelência), 494
apo io da gerência de área na, sobre a Conferência Global de Orange Switzerland, melhores
394 Gestão de Projetos, 134-135 práticas da, 20
descoberta das melhores sobre a orientação de gerente organização, projetos, 195-196
práticas na, 33 de projetos, 138 o rganizações do ramo da saúde,
excelência na, 147-148, 189- New York University School of 306
190 Continuing and Professional organizações híbridas, 10
fato res críticos para o sucesso Studies (N YU-SCPS), 406 o rganizações orientadas a
na,32 níve11 planejamento projetos,29, 4 14
fracasso devido a uma crença (cronograma mestre), 208-21 1 o rgulho, no ambiente de pro je tos,
coletiva na, 8 8-89 nível 2 planejamento 88-90
gestão de projetos vista por um (cronograma do resumo do o rientação, na F1uo r
executivo da, 16-17 projeto), 208-21 1 Corporation, 696-698
no Índice
orientação de gerente de projetos, palestrantes externos, 413-414 e orgulho, 89-90

na Goodyear, 137-138 Parceria de Medidas de excelência em 377-379
os dez perigos dos projetos, 97- Conservaç.ã o (Conservation executivo, 378-379, 388-390
104 Measures Partnership), 13911.6 falta de, 100-101
ausência de plano comunitário parcerias de negócios em TI, 503 fases do, 375-377
(8), ·1 00-102 parcerias estratégicas, 502-507 planejamento estratégico do,
datas não passam de números Parker, G., sobre recompensar as 377-378
(10), 101-102 equipes de projetos, 461, 463 por comitê, 375-376, 722-723
e a manutenção de projetos, Parmenter, David, sobre patrocínio de projetos, veja
102-102 mensuraç.ã o de desempenho, patrocínio
e o empoderamento das 40-41 patrocínio executivo, 3 78-
equipes, 102-103 Parrish, Kimberly, sobre gestão 379, 388-390. Veja também
e o gerenciamento proativo, de projetos, 16 patrocínio por comitê, 375-376,
101-103 partes interessadas: 722-723
falta de manutenção de comprometimento das, 345- PCC (Project Complexity
documentação (1), 98-99 346 Categorizatio11), 523-524
falta de qualidade na fonte (3), determinantes de valor para, PCC! ( Patie11t Care a11d Clinica/
99-100 661-662 Informatics ), 489-490
falta de rigor nos processos e gerenciamento de portfólio, PDM (Precede11ce diagramming
(7), ·1 00-101 582-583 method), 233-235
fenômeno do acúmulo (2), 98- envolvimento em projetos, 4 3 PDUs (Professional Development
99 gestão de mudanças com as, Units), 488-489, 526-527
não envolver as pessoas certas 527-528 pedido de apresentação de
(5), 99-100 na gestão de projetos proposta (RFP, request for
não planejar retrabalho ( 9), d irecionada a valor, 722 proposal), 185, 320-321
101-102 processo de tomada de Peno, William, sobre a avareza,
não ter o patrocínio decisões das, 144 89-90
apropriado ( 6), ·1 00-101 participação, governança e, 382- pensamento crítico (competência
pessoas erradas envolvidas (4 ), 383 central), 419-420
99-100 Patient Care and Clinicai pequenas empresas, PLM VDNI
remédios para, 101-104 / nformatics (PCC! - para, 710
otimização contínua, 505 Atendimento a Clientes e percepções, fracasso de projeto e,
Our Lady of Lourdes Regional Informática de Dados Clínicos), 389-390
Medical Center, 16 489-490 percepções falhas, fracasso de
0111/iers (l\1alcolm Gladwell), patrocinadores. Veja também projetos e as, 389-390
703 executivos convictos, 396-397 perguntas fec hadas, 573-574
aceitação final pelos, 515-516 perigos, veja os dez perigos dos
(P&D), veja pesquisa e comunicação de cima para projetos
desenvolvimento (P&D) baixo pelos, 526-528 Perot Systems, 520-521
pacotes de software de gestão em mercados emergentes, 367 perspectiva geral das
de projetos para mainframes, papel dos, 375-377 comunidades de conhecimento,
234-236 responsabilidades na resolução 694-695
pacotes de software para de conflitos, 457 Pf.RT, veja Técnica de Avaliação
computadores pessoais, 235- patrocinadores executivos, 3 76- e Revisão de Programas (Pf.RT,
237 377, 394-395. Veja também Progrmn evaluatio,i and revie.w
padrão sindical, 91-93 patrocinadores nos mercados tecbnique)
Padrões Abertos para a Prática emergentes, 367 "peso morto" (dog), 742, 743
e Conservação (Parceria de papel de suporte dos, 465 pesquisa e desenvolvimento
Nledidas de Conservação), versus executivos convictos, (P&D), 7, 75-76, 377-379
13911.6 231-232 pesquisas pós-treinamento, 414
Padrões de Gestão de Projetos patrocínio, 103, 373-379 Peters, Lawrence J., sobre a raiva,
(PN1S, Project Ma11ageme11t dual, 391 86-87
Standards ), 443 e a tomada de decisões, 376- Peters, ~1.artha:
padrões do PNU, 44, 48 378 sobre canais de entrega, 361-
padrões e diretrizes para a gestão e a tomada de decisões pelos 362
de projetos, 57-59 gerentes de projetos, 113 sobre fusões e aquisições, 35 6
padronizaç.ã o de soluções, 634- e as relações com o cliente, sobre processo de inicialização
636 376-377 de projetos, 352
palestrantes, 413-414 e o suporte da gestão, 373-379 Philip l\1orris, 734-735
Índice 771
Philips Healthcare Software plano de carre ira de gestão de e Seis Sigma, 564-565, 575-577
Customer Services: projetos, 402-404, 501 e treinamento, 4 74-475
Comunidade de Prática, 494 Plano de Gestão de Projeto, PGP gerenciamento das melhores
PMO da, 488-496 (Project ,Vfanagement Plan, práticas pelo, 46
processos da, 495-496 PNlP), 256-257 gerenciamento de portfólio
serviços oferecidos pela, 492- plano de projeto integrado, 295- com, 583-583
494 296 global, 488-496, 544-547
Phillips, J. J., 47411.6 plano de qualidade do projeto, métricas para, 487
pioneiros do GC, 698-699 257-260, 263 múltiplo, 7'1
pirâmide de excelência, 492-494 plano de recompensas ao papel do, 407
Pirâmide do Paradigma funcionário (PRF), 332 prêmio Pi\>10 do Ano, 553-561
(COMAU), 684-689 planos de projetos, 267-269 problemas com, 71
Pirâmide do Sucesso, 149-150 na Medical Nlurual, 273-274 projetos á picos do, 575-577
Pls (performance indicators), 40 nas regras áureas para a gestão tipos de, 518-520
"Pista de corrida" do projeto, de projetos , 295-296 validação das melhores
229 template para, 287-289 práticas pelo, 42-43
Piniglio, Vince, 348,349, 351-352 planos estratégicos, 109-·11 O, verificaç.ã o de saúde do projeto
planejamento, '195-196 116-'118 com, 551-553
cronograma versus, 234-235 Plataforma Comum de T I da Star PMO em presarial (EP!'.10), 504,
em mercados emergentes, 371 Alliance, 548 540-544
entendendo premissas no, 139 plataforma Knowledge PMOs globais:
fluxo de trabalho iterativo, 509 O nline" ', 691-692 de atendimento ao cliente
metas durante o, 252-253 plataforma Sharing Knowledge, (customer services), 488-496
na Deloine, 671-672 342-344 na Hewlett-Packard, 544-547
na DTE energy, 287,288 Plínio, o Velho, sobre a luxúria, na Philips Healthcare Software
na ~1.icrosoft Solutions 92-93 PMP (Project Ma11ageme11t Plan),
Framework, 657-658 PLM ( Product Lifecycle 256-257
na Sherwin-Williams, 269-271 Ma11agement), 15, 705-7'12 PMPMG (Project 1\'1a11agement
para Seis Sigma, 566-567 PLM VDNI (product lifecycle Progress Maturity Cuide), 627-
planejamento de cursos de management value delivery 628
treinamento, 4'11-414 methodology), 707-712 P!'.1Pnet, 342-344
planejamento de capacidade, 73 PLUS, Sistema de Lançamento PMS (Project Ma11agement
planejamento de contingências na de Produtos (Product Launch Standards), 443
Zurich America, 306-308 System), 740-742 PMU (Project Ma11ageme11t
planejamento do fluxo de PM Newsflash, 48-49 University), 4 3 8, 622
trabalho iterativo, 509 PMCP, veja propensão à PO, veja PMO
planejamento estratégico, 108- capacidade de gerenciamento poder, 81-83, 90-94
118, 377-378, 592-593 proativo (Proactive Management polinização cruzada, 502-503
benefícios da gestão de Capacity Prope11sity) política de delegação de
projetos para o, ·111-112, PMI" , veja Instituto de Gestão de autoridade, 322
114-1 15 Projetos (PMI") política de potras abertas, 373-
e a gestão de projetos vista por PMLS (Project Ma11agement 374
um executivo, ·11 O Leaming System), 525-527 política negativa, 77-78
e a implementação pelo gerente PMO (escritório de projetos, polítkas em mercados
de projetos, 116-118 escritório de gestão de projetos, emergentes, 368-370
e a liderança estratégica da PO), 485-561 políticas versus listas de
gestão de projetos, 115-1 17 atividades do, 485 -486 verificação, 4 39-440
e as tendências de treinamento, benefícios do, 485-487 Polk Lighting (nome fictício), 450
407 compreendendo a natureza de pontos de controle, 250-252
e o fracasso nos planos um, 534-541 pontos de decisão de qualidade
estratégicos, 109-110 criação do, 7'1, 513-515 (P-Q), 204-206
mitos sobre o, 112-1 '14 e a garantia de uso das pontuação AQA (Avaliação de
na fLLUtvUNAT, 178-'181 melhores práticas, 50-51 Qualidade de Tarefas), 31
perspectiva da gestão de e a satisfação do consumidor, pontuação na Avaliação
projetos o, ·u 0-1 11 239-241 de Q ualidade de Tarefas
planejamento estratégico de e as fases do ciclo de vida, 73- (AQA, Assignment Quality
recursos no gerenciamento de 74 Assess:m ent), 31
portfólio, 592-593 e auditorias de projetos, 54 8- portais de colaboração de
plano comunitário, 100-101, 103 551 projeto, 29
n2 Índice
Pôs estratégicos, 518-519 priorização, 95-96 processo de gerenciamento de

posto de serviço de TI, 54-56 e o planejamento de demandas, 272-274, 540
potencial da liderança, 500 estratégias, 114 Processo de gerenciamento de
potencial de crescimento, na na definição de sucesso de portfólios de Projetos CI, 284-291
cadeia de valor, 743-744 projetos, 25 fase de Encerramento do, 287,
Powertrain Croup, veja General no gerenciamento de portfólio, 291
Motors Powen rain Group 589-593 fase de Identificação do, 284
PPM (project process problemas, 67-98. Veja também fase de Iniciação do, 284,286,
monitoring), 241-245 os dez perigos dos projetos 287
P-Q (pontos de decisão de a partir das mudanças nas fase de Planejamento do, 287,
qualidade), 204-206 exigências do cliente, 70-71 288
práticas comprovadas, 19. Veja ao cancelar um proje to, 73- fase de Seleção do, 286
t.am.bém melhores práticas e 75 fases de Execução/Controle do,
práticas comprovadas causados por questões 287, 289, 290
Práticas de Gerenciamento políticas, 76-83 processo de gerenciamento de
de Programas e Projetos com a terceirizaç.ã o, 73 q ualidade do projeto, 255-264
(PPM, Program and Project de a quem o PMO deve se processo de gestão de riscos
Management), 544-546 reportar, 71 (gestão de riscos p roativa), 317
práticas de PPlV!, 544-546 de oferecer recompensas a processo de implementação
práticas padrão, 223-224 projetos, 74 de contrato (CIP, contract
precisão, 95-96, 576-577 de ter a cultura errada em implementation process), 558-560
preenchimento de lacunas, 114- vigor, 75-76 processo de início do projeto,
115 e a satisfação do consumidor, 280-281
preguiça, fracasso devido à, 91-92 68-70 Processo de N1entoria de
preguiça, no ambiente de e o dilema do fluxo de caixa, Habilidades em Cestão de
p rojetos, 91-93 71-72 Projetos, 629
prêmio (s): e os Sete Pecados Capitais, 83- processo de mudança
da IBlVl, 630 95 empresarial, 358-359
de Satisfação do Cliente, 74 1 em atender às expectativas, processo de negócios, gestão de
em dinheiro, 463-464 594-597 projetos como, ·1
Empresa lV!ais Admirada menores, 9 4-98 processo de qualidade, 263
da América do Norte e na metodologia de gestão de processo de qualificação (IBlV!),
do ~1.undo em termos de projetos da empresa, 68-69 617-619
Conhecimentos (MAKE, na mudança de escopo, 72-73 Processo de Realização de
North America11 and C/ol,al quando boas intenções se Produto da Key (KPRP, Key
Most Admired Knowledge transformam em, 67-68 Product Realization Process),
Enterprise), 692-693 versus crise, 449 175-177
Equipe de Projetos do Ano, problemas de bandeira amarela, processo de revisão, para
559-561 376-377 melhores práticas, 46-4 7
KM Pacesetter (precursor em problemas de bandeira vermelha, processo organizacional, uso para
CC), 698 376-377 o, 113-'114
Malcolm Baldrige, 308 procedimentos, 4 39-440 processos de gerenciamento, 306
não monetários, 463-464 processo Customer One (Cl ), Profserv (Metodologia de
PlVlO do Ano, 553-561 243-245 Serviços Profissionais), 36'1-364
projeto, 74, 320-321 processo de Aprovação e Revisão Programa da Universidade de
Sarah Sheridan, 564 de Soluções e Oportunidades Cestão de Projetos (PtVfU,
prêmio PMO do Ano, 553-561 (SOAR, Solution aud Progrmn Management
critérios para o, 554 Opporttmity Approval and Uniuersity), 438, 622
ensaio para o, 555-556 Review), 152 Programa de Administração
ganhadores do, 555-561 processo de benchmarking, 333- Salarial, 74, 735-736
prestar atenção a detalhes 334 Programa de Certificação em
(competência centra l), 422 processo de classificação Gestão de Projetos (PlVlCP,
PRF (Plano de Recompensas ao ( processo proativo de gestão de Program Management
Funcionário), 332 riscos), 317 Certificate Program), 4 76
Primavera TeamPlay, 33 '1-332 processo de controle de programa de contratação
Prince, Ed, 739 mudanç.as: baseado em papéis, 502-503
Prince Corporation, 739-741 na Medical Mutual, 274 -275 Programa de Desenvolvimento de
principal executivo de gestão de na l\1.icrosoft Solutions Gerenciamento de Programas,
p rojetos, 407 Framework, 651-652 na HP Services, 438
Índice 773
Programa de Desenvolvimento projetos c ruciais, sinais vitais de, QMG (Quality Ma11agement
de Gestão de Projetos (PMDP), 581 Group), 61
545-546 projetos de aprendizagem de quadrante do dilema na cadeia de
Programa de Padronização ação, 435 valor, 743
Gestão de Projetos e m toda a projetos de capital, 106 quadro de desempenho do
Empresa (EPl\1S, E11terprise projetos defensivos, 584-585 projeto, 2 87, 290
Project Management projetos em vias de fracassar, Qualidade, 309
Sta11dardizatio11), 520-52 1, 526- metodologias para, 297-300 como ação de marca da DFCU,
527 projetos financeiros, 7'19-720 350-352, 357-360
programa interno de certificação projetos globais, 149-150, 444 definição, 25
em gestão de projetos PM3, projetos inovadores, 586-589 na fon te, 99-100, 103
525-527 projetos inte rnos ou de pontos de decisão de co ntrole
Programa SME Protégé (Fluor melhorias, 719 de qualidade do projeto, 204-
Corporation), 696-697 projetos multinacionais: 206
programas de qualidade, Seis com fusões e aquisições, 7 34 questões inacabadas, 573-574
Sigma e, 570-571 excelência em, veja excelência questões políticas da gestão de
programas de treiname nto em gestão de projetos global projetos, 76-83
oferecidos pelo governo, 4 11- projetos ofensivos, 584-585 atacar versus recuar
41 2 projetos ope racionais, 2-3, 719 (estratégia), 79-81
Project and People Management projetos relacionados ao futuro, classificando amigos e
(COMAU), 684-687 719-720 inimigos, 79-80
Project Ma11agement Body o( projetos relacionados aos e co mitês de governança, 78-
K11owledge, veja Guia PMBOK"' clientes, 719-720 80
(Project 1\Aa11ageme11t Body o( projetos virtuais, 29 e c omunicações efetivas, 80-
K11owledge) Prol\>lap, 2 76-277 82
Project Management promessa, co mo ação de marca e poder/influência, 81-83
Certification Program (Pl\1CP), da DFCU, 360-361 gestão de projetos po líticos,
476 promoções, 86-87, 442 82-83
Project 011tli11e, 322 propaganda, gestão de projetos razões para se envolver em
Project Path, 540-544 de, 62-63 jogos políticos, 77-78
Projeto lridium, 88-89 propensão à capacidade de r iscos políticos, 76-78
Projeto(s): gerenciamento proativo (PN1CP, situações em que haverá
cancelamento de, 73-75 Proactive J\1.auagement Capacity e nvolvimento em jogos
classificação de, 584-589 Propensity), 467-471 políticos, 78-79
compreendendo sucesso para, benefícios da, 469 Quintilian, 1\1-tarcus Fabius, sobre
28-29 crescimento da, 469-4 71 a preguiça, 91-92
definição, 508-511 e a carga de trabalho, 469-
designação de, 501 4 70 R. R. Donnelley & Sons, PMO
e Seis Sigma, 573-577 gerenciamento da, 467-469 da, 535, 537, 538
e nvolvimento das partes proposição de valor, 34 7 Rach1in, Sue, sobre
interessadas no(s), 43 propósito, 195-196, 295-296 gerenciamento de portfólio,
gerenciamento de, direcionado propostas clichês, 392 578-583
a valor, 718-720 Proprietário de Melho r Prática, raiva no ambiente de projetos,
gerenciando negócios como 33 86-89
uma série de, 14 proprietários, 737-738 ratificação, solução, 645-646
global(is), 149-150, 444 proteção, 693-695 reação, de participantes de
manutenção de, 102-102 proteção, como ação de marca da programas de treiname nto, 4 77,
mensuração de, 96-97 DFCU, 359-360 478
me nsuração de sucesso para, provedores de soluções, 70-71 realização de pedidos, 495
25-32 PubliJius Syrus, sobre a avare za, recebimento de pedidos, 495
operacional( is), 719 89-90 recertificação (processo de
pr iorização de 95-96 Pumphrey, Bill: qualificaç.ã o), 618
sinais vitais do(s), 581-582 e as me lho res práticas na recompe nsas:
sucesso de, 25-32 Cooper Standard, 159 à métrica !DC, 332
variação em, 667-669 patrocínio por, 162 a pro jetos, 74, 320-321
projeto whack-a-mole (jogo de sobre a excelência na Cooper fracassos com, 85-86
fliperama), 467-468 Standard, 163-164 na AVfVA Canada, 501
projetos CAPEX, na Holcim, Putiri, Angelo, 678-67911. 7 não mo netárias, 4 63-464
275-278 para equipes, 461-464
n4 índice
reco nhecimento: integrativa, 7 nsco:

na AVIVA Canada, 501 nas regras áureas para a gestão aceitação de, 13-14
na Fluor Corporation, 698-699 de projetos, 295-296 de c ro nograma, 3 13, 3 14
rec uo, estratégias de, para social corporativa, 505 de produção, 328
projetos políticos, 79-81 restrições: financeiro, 313,3 28
rec uperação em gestão de manter as, 94-96 mercadológico, 328
projetos, 297-300 tr iplas, 24, 719-721 político, 76-78
recursos: resultados (Pirâmide do Sucesso), técnico, 3 28
cobiça por, 90-91 150 RMXPro, 276-277
disponibilidade de, 592-593 Resumo de O portunidades em Roadway Express, excelência na,
fracasso devido ao excesso de, Gere nciamento de Portfólios, 183-184
90-91 497-498 Rockwell Automation:
gula po r, 93 -94 re to rno sobre investime nto (ROi, gerenciamento de portfólio na,
priorização de, 95-96 return º" investment): 597-600
Rede de Competências (1BlVI), e estudos dos benefícios da Prêmio PMO do Ano para a,
613 gestão de projetos, 473-474 555-557
Rede de Conhecimento de história da modelagem do, Processo Comum de
GP (PMKN, PM Knowledge 474-475 Desenvolvimento de
Network), 628, 629 para tre inamento, 41 4, 4 72- Produtost na, 263 -269
reengenharia, 306, 329-330 484 Rod Adkins, sobre gestão de
reestruturação, 6, 337-339, 746- retrabalho, 101-1 03 projetos, 15
747 re trospectivas de projetos, 2 9 ROi, veja retorno sobre
registro de problemas, 324 -325 re uniões: investimento (ROi, returu on
Registro !CU, 325 ARlV!, 510-51 1 iuvestment)
regra 9x9, 282, 284 de abertura de projetos, 22 Roteiro de Programa, 152
regras áureas para a gestão de de final de fase, 73 -74, 231- Royer, lsabelle, sobre defensores
projetos, 294-297 232 de encerramento, 396-398
re lacio namento com o cliente, de marcos, 2 2 RSMS (Resource a11d Skills
333-334, 376-377 departamentais trimestrais, Management System), 558-56'1
relatório. Veja também relatório 505 Russett, Rose, sobre excelência
de status e as ex igências da gerê ncia na G/'.1 Powertrain, 453-455
na N aviair, 172 sénior senior, 443 Sadowski, Alex, sobre
re latórios de múltip]os c hefes, equipe, 445 treiname nto na Harris, 4 27-4 32
333-334 fo renses, 445 Sadowski, Nani, sobre melhores
relató rio de encerramento, 2 9 1 na AVIVA Canada, 505-507 práticas, 20
relató rio de gestão de riscos, post mortem, 22, 33 Sadowski-Alvarez, Nani, 531-
321 -322 revalidando as melhores práticas, 5 32
relató rio de semáforo 46-47 sobre audito ria de projetos,
(dashboards), 33-34, 51 -52 Revenga López, Felipe, 21 ln.10 548-551
relatório de status, 196-197, revisão de passagem de fase de sobre PlVIO, 528-52911.21
575-576 especificações (RPFEsp), 293- Samarotto, Claudio, 678-67911.7
com código de cores, 446-44 7 294 sancio nando direção (Pirâmide
e o planejamento estratégico, revisão do gere nciamento de do Sucesso), 150
111 talentos, 500-501 Sanford, Linda S., sobre gestão de
na Medical Mutual, 2 73-274 revisão pós-ação (AAr, A/ter projetos, 14-1 5
tamanho do, 445 Action review), 58-60, 564 SAP:
Reliance Electric, 263 -264 revisões, metodologia, 221 -222 metodologia da, 204-209
Rf.P, veja Centro Registrado de revisões de final de fase, 203- plano de carre ira de gestão de
Treinamento (REP, Registered 204 projetos na, 402-404
Education Provider) revisões de marcos, 252-253 pontos de decisão de contro le
resolução de conflitos, 455-457 revisões de passagem de fase, de qualidade do projeto na,
"respeitar a data de lançam ento" 267-268 204-206
regra de decisão, 32 7 Revisões Técnicas, 256-257, 263 tre inamento na, 4 02 -404
respeito como ação de marca da RFP (request fo r proposal), 185, satisfação, 477, 478, 567-568
DFCU, 356-357 320-321 satisfação do cliente, 68-70, 134
responsibilidade: Rigodanzo, Mike: e o escritório de gestão de
como ação de marca da DFCU, sobre excelência, 150-1 52 projetos, 2 39-241
347-348, 356-360 sobre gestão de projetos, 16 e os co ntroles internos, 68
dos executivos, 377-378 Rigor, 100-101, 103 e sucesso, 24 , 634 -635
Índice 775
índice de satisfação do cliente selecionando funcio nários, 457- Sherwin-Williams:

(CDI, cttstomer delight index), 459 gestão de projetos na, 14
244-249 semáforo amarelo, 33 melhores práticas da, 270-271
no Seis Sigma, 567-568 semáforo amarelo, 33 metodologias da, 268-272
problemas com a, 68-70 semáforo verde, 33 visão da, 270-272
SBUs (strategic business ,mits), semáforo vermelho, 33 Shibuya, Hiroyuki, 382-389
68-69 Seneca, sobre raiva (ira), 86-87 Shobe, Mark, sobre a cultura da
Schornho rst, E.ric, sobre ação de senso comum, 88-89, 396-397 DFCU, 350, 352, 354,355
marca, 347, 348, 352, 353 Serviço de Atendimento ao Siemens lndustry Automatio n
Schulist, Jason: Cliente (SAC), 315 Division, 705
sobre excelência, 192 serviços de aceleramento (CA Siemens PLtvl Software:
sobre patrocínio de projeto, Technologies), 636-637 gestão de projetos vista por um
394 serviços fundamentais (CA executivo da, 15
sobre Seis Sigma, 563 Technologies), 636-637 metodologia da, 704-712
Schwab, Charles M., sobre ses.sões "hidra", 553 "Sigma Eoxuto", 564
limitações, 255-256 sessões de balanço (debriefing), SIGP, veja sistema de infonnações
scorecard do sn, 332 146 da gestão de projetos (SIGP)
scorecards, 34-35 Sete Pecados Capitais, 83-95 Simpósio do Dia Internacional
SDlVI (software developme11t avareza, 89-92 da Gestão de Projetos, 433-434,
methodology), 96-97 gula, 93-95 559-560
SDPC (Solution Delivery Process inveja, 84-87 sinais vitais, de projetos críticos,
Center), 57-60 luxúria, 92-94 581-582
Sears, Pl\10 da, 535,538 orgulho, 88-90 Sinco Energy (nome fictício), 392
Sears, Scott, sobre PMO na preguiça, 91-93 sincronização dos pontos de
Boeing, 487-489 raiva(ira), 86-89 decisão, 293-295
segundas intenções, 87-88 sete virtudes, 94-9 5 síndrome do "isso não foi
Seis Sigma, 562-577 setor aeroespacial inventado aqui", 85-86
avaliações para, 572-574 escritó rios de projetos Singhal, Hirdesh:
e a Convex Corpo ration, 574- focalizados no cliente no, e o índice de satisfação do
576 337-339 cliente, 245-246
e TQlVI, 3'10-312 desenvolvimento de novos sobre treinamento na Tech
fracassos no, 563 produtos no, 106-108 lVlahindra Ltd., 434-438
melhores práticas do, 564-565 curso de treinamento em gestão Sistema de Aprendizagem em
metas do, 567-569 de projetos no, 427-432 Gestão de Projetos ( PMLS,
mitos do, 569-571 nos anos 1950 e 1960, 4 Project Mauagement Learning
para planejamento estratégico, setor de construç.ã o, gestão de System), 525-527
566-567 projetos no, 61-62 Sistema de Encarregados pelos
para PlVIO, 564 -565, 575-577 Sevilla l\1olina, Enrique: Aplicativos, 383-388
para seleção de projetos, 573- sobre fatores críticos de sistema de gerenciamento de
576 sucesso, 30-31 conteúdo empresarial, 360-361
projetos típicos de, 575-577 sobre cultura, 335-336 Sistema de Gerenciamento
relação com a gestão de sobre as forças motrizes na de Recursos e Habilidades
projetos, 562-564 lndra, 10 (RSMS, Reso11rce and Skills
tradicional versus não sobre a importância do PMO, Ma11agement System), 558-561
tradicional, 564-567 487 Sistema de Gerenciamento do
Seis Sigma de manufatura, 565- sobre os indicadores-chave de Valor Agregado (SGVA}, 409-
566 desempenho, 31 410, 429-432
Seis Sigma operacional, 566-569 sobre metodologia, 228-231, sistema de informações da gestão
Seis Sigma transacional, 566-569 237-238 de projetos (SIGP), 253-255,
seleç.ã o de projetos (em sobre gerenciamento de 324, 325
gerenciamento de portfólio}: portfólio, 583 Sistema de Lançamento de
avaliação preliminar, 587-590 sobre sucesso de programas e Produtos (PLUS), 740-742
identificação de projetos, 584- projetos, 27 sistema de monitoramento de
589 sobre gestão de projetos como custos, 4
no gerenciamento de portfolio, uma pro fissão, 4 16 sistemas EVM, veja Sistema
584-593 sobre melhores práticas, de Gerenciamento do Valor
obstáculos na, 584-585 21n.15, 43, 45-46, 49-50 Agregado (SGVA)
processo para, 584-586 SharePoinr, 273-274 Site Global de Solicitações e
seleção estratégica, 589-593 Sheppard, Steve, 528-529 Feedl,ack de Práticas, 645-646
ns Índice
Slalom Consulting: SST (equipe de apoio estratégico), Tacitus, Publius Cornelius, sobre
a gestão de projetos na visão 115 inveja, 84-85
de um executivo da, 15 Standards for Cou.servation Tarantini, Riccardo, sobre gestão
gestão de portfolio na, 578-580 Project and Progrmmnc de projetos, 14
metodologia da, 222-225 Manageme11t (WWF Taylo r, Darlene, sobre excelência
modelos alavancados pela, lnternational), 139-140 na Key Plastics, 177
224-225 Sta r Alliance, 7'1, 545-548 TeamPlay (Primavera), 331-332
Ptvló da, 534-54 '1 stah1s em mercados emergentes, Tech Mahindra l td:
uso da mensuração do valor 368-370 gestão de projetos vista por um
agregado na, 237-240 Steinruck, Sandy, 631-633 executivo da, 15-16
SMEs (s11/,ject matter experts), Stibora, 1\>latt, 263-264u.19, 597- índice de satisfação do cliente
695-697 59811. l l da, 244-249
Snyde r, N . Tennant, sobre equipes Stouffer, Debra, sobre metodologia da, 241-249
virtuais, 4 59-460 gerenciamento de portfó1io, monitoramento dos processos
SOAR (so/11tio11 and opportunity 578-583 de projetos na, 24 '1-245
approval aud review), 152 Strategic Plamú11g for Project tre inamentos na, 4 34-438
sobrevivência, 'I O, 185-186 ,Vfanageme11t Using a Project técnica de avaliação e revisão
Sociedade Americana de ,Vfanageme11t Mahtrity J\tfodcl, de programas (PERT, program
Treinamento e Desenvolvimento 2e (Harold Kerzner), 678-679, evaluation a11d review
(ASTD, Americau Society for 690-691 tech11ique), 185, 233-235, 409-
Traiuing and Development), 4 74 subcontratação, 186-187, 439- 41 0
sofisticação, em mercados 440 Tecnicas Reunidas, me todologia
emergentes, 3 71 SUCCESS 2.0, 494, 495 da, 211-218
sofrimento, inílição de, 85-87 s ucesso: tecnologia:
software: comparação entre fracasso e, dando s uporte à cadeia de
e o mau desempenho, 224 25,26 valor agregado, 731
falácias sobre, '1 45, '1 46 componente de valo r de, 713- dando suporte à gestão de
liderança versus uso de, 235- 714 projetos global, 701
237 comportamental, 465-466 fato res c ulturais com a, 460
para computadores pessoais, c ritérios da Microsoft• templates:
235-237 Operations Framework para avaliando a maturidade com,
para cronograma, 233-235 o, 653-658 146
para gestão de projetos para critérios para o, 576-577 na CA Technologies, 640-643
mainframe, 234-236 CSFs e KPls na definição de, na Microsoft Solutions
para metodo logias de suporte, 28-33 Framework, 652-653
233-242 definição, 25-32, 713-714. no Seis Sigma, 576-577
treiname nto em, 234-235 Veja também falácias sobre as para melhores práticas, 4 3, 47,
solicitação de mudança, 287, melhores práticas, 14 7 48
328-330, 5'15-5'1 7 devido à gula por recursos, 93- proposta da iniciativa, 510-
Soluções de Gerenciamento de 94 511
Clientes (Customer Management em empresas não o rientadas a tempo até o reto rno (time-to-
So/11tio11), 548 projetos, 29 va/11e) para o cliente, 634-636
Somermeyer, S., sobre fuzzy front em empresas o rientadas a tendências:
end, 395-396n.8 projetos, 29 aprendizado, 404, 406-408
Sophocles, sobre sucesso, 256- identificando as melho res do mercado, 405-406
257 práticas a partir do, 24 durante os anos de evolução,
SOW, veja especificação do início de projeto para, 634-636 404
trabalho (SOW, statement of mensuração, 27, 134, 532-534 durante os anos de revolução,
work ) mensuração inte rna do, 13 4 405-406
SPl (Sd1ed11/e Performance problema com o, 96-97 e respostas de aprendizagem,
/udex), 237-238n.1 4, 431-432 quarto bases do, 719-721 406-408
Spira, Jim, sobre benefícios da responsabilidade pelo, 95-97 megatendências empresariais,
gestão de projetos, 13 s uporte, veja apoio por parte da 498-499
Spradley, Sue, sobre gestão de gerência Teradyne, metodologia de, 217-
pro jetos, 16 s uporte estratégico (co mpetência 222
sprint, 303 central), 426-428 terceirização, 73, 106-107, 268-
SRAM (short-range attack sustentabilidade de projetos, 408 269
missile), 4 50
Índice 777
termo de abertura de projetos: TPAs (third-party Triompo, J im, sobre PMOs, 487
assinatura das partes administrato-rs), 315 tripla restrição, 24, 719-721
interessadas no , 20 TQNI, veja gestão da qualidade Turner, Mike, sobre a t\i-ticrosoft
como alicerce dos projetos, total (TQM, total quality Solutions Framework, 64 7,
195-196 management) 649-652
daAT&T,335 trabalho em equipe, 303
da Churchill Downs lnc., 51 3- características do, 445-446 UAT (user acceptance testi11g),
514 como ação de marca da D FCU, 243-244
da DTE Energy, 286, 287 349, 352-353 UGS (empresa), 707
da GN! Powertrain, 249-250 na gestão informal de pro jetos, unidades de desenvolvimento
da IBM, 606-607 445-446 profissional (PDUs, professional
da Medical Mutual, 273-274 Pirâmide do Sucesso para, 149- developme11t units), 488-489,
gerenciando premissas no, 150 526-527
139 trade-offs: unidades de negócios estratégicas
nas regras áureas para a gestão em projetos orientados a valo r, (SBUs, strategic busiuess 1.mits),
de projetos, 295-296 726-727 68-69
preparação do, 203-205 em projetos tradicionais versus UPMM"1 ( U11ified Project
teste de cred ibilidade para o não tradicionais, 7'19-722 Ma11agemen t' Methodology),
cliente, 694 -695 transferência de conhecimento, 198-202, 405
testes de aceitação pelo usuário, 44, 48, 53-54 usar recursos internos, ·106-107
TAU ( UAT, user acceptance transparência, 511-512
testi11g), 243-244 treinamento, 399-438. Veja Vaill, Peter B., sobre Seis Sigma,
testes piloto, 573-574 também educação; aprendizado 570-571
Texas lnstruments (TI), benefícios do, 408 vale da morte, 394-396
excelência na, 148-150 com Siemens PLN! VDM, TI O va1idando as melhores práticas,
Thiokol Corporation, 450-451 e a gestão de projetos co mo 4 1-43, 46-47
Thomas, Joseph C., sobre as profissão, 414-4 16 valor agregado:
melhores práticas, 56-5711.43 e a propensão à capacidade de e a DTE Energy, 33 '1-332
Thomas, Keith: gestão de pro jetos, 469-4 70 para o gerenciamento de
e a metodologia de serv iços em empresas de capital aberto, processos integrados, 331-332
profissionais (Profserv), 361- 4 11-412 recompensas po r, 463
362 em empresas orientadas a valor(es):
sobre a gestão de pro je tos, 17 projetos, 414 captar, medir e reportar, 719-
T I (Texas lnstruments), 148-150 em mercados emergentes, 370- 727
T I, governança de, 382-389, 538 371 definição, 713, 722, 728-729
Tokio Ntarine Group, apoio por em Seis Sigma, 570-571 e cultura, 335-336
parte da gerência na, 382 -389 em software, 234 -235 e liderança, 716-71 8
tolerância, 4 52-453 fu ndamentos de, 408-41O em gestão de projetos, 335-
to lerância a riscos, 592-593, habilidades de negócios em, 336. Veja também gestão de
744-746 400-402 projetos o rientada à valo r e
tomada de decisões: identificando a necessidade de, sucesso, 28-29, 713-714
como uma competência 408-409 mensuração, 723-727
central, 426 inte rno, 4 1 1-4 13 na definiç.ã o de projetos de
descentralizada, 389-390 j11st-i11-time, 409-410 sucesso, 25
durante as crises, 449 modelo de competências para, valo res corporativos, 335-336
governanç.a de projetos e a 4 16-428 valo res difíceis, medindo os,
velocidade da, 144 na gestão de pro jetos, 61, 234- 723-725
o apoio do patrocinado r na, 235 valores intangíveis, 723-725
376-378 necessidades para, 14 7 valo res tangíveis, mensurando,
o processo de gerenciamento para a gestão de projetos 723-725
de qualidade do projeto moderna, 399-401 Vannoni, Brian, 453-454
aplicado à, 255-264 planejamento de cursos para, Variação no Término (VNT),
por gerentes de pro jetos, 113 4 11-414 431-432
pré-aquisição, 732-737 quantidade necessária, 41 5 variância, 667-669
sobre as melhores práticas, 55- Ró i do, 4 14, 472-484 Vasciminno, Paolo, 678-67911. 7
57 selecionando alunos para, 408- Vaswani, Suresh, sobre gestão de
tópicos comportamentais, 400- 409 projetos, 14
401, 41 0-41 1 3M, 373-374, 388-389, 453-454, Vázquez Díaz, Alfredo, 252-
tópicos quantitativos, 4 00-40 1 458 25311. 17, 32311.8
na Índice
verificação da saúde de projetos, Welch, Jack, sobre Seis Sigma, sobre indicadores-chave de
551-553 569-570 desempenho, 31
verificação de início de Wenger, E., sobre comunidades sobre o apoio da gerência,
operações, 645-646 de prática, 48-49 393
Viper, carro esporte, 313 Westfield Group, 278-282 sobre PlVIO da maxlT-VCS,
visão da gerência sênior, 132-133 \'(//Jack-a-mole (jogo de 497-498
visão financeira de portfólio, fliperama), 467-468 WWPlVlM ( \Vorldwide Project
511-512 \'(//,o Says Elephants Can't Dance Management Method), 622-625,
visibilidade em toda a empresa, (um Gersmer), 606 627
511-512 Wibelius, Michael, 165n.12
Visteon (empresa), 303 Wickham, Mike, sobre excelência Yusuf, Dave, sobre gestão de
VNT (variação no término), na Roadway, 183-184 projetos, 15
431-432 Williams 1\>lachine Too] Company
Voltaire, sobre orgulho, 88-89 (nome fictício), 187-188 Zale, Suzanne:
voz, como ação de marca da Willis, Kerry R.: sobre as melhores práticas, 49-
DFCU, 351-352, 360-361 sobre gerenciamento proativo, 50
VPF (value performance 467-471 sobre comunicações, 444
framework), 714-717 sobre os dez perigos dos sobre estrutura organizaciona1,
projetos, 97-98n.4 444-445
Wiirtsilii: Withdrawal, 4 5 7 Zava1, Linda, sobre treinamentos
gerenciamento de benefícios Wojala, Karen, 263-264u. 19, doUL, 41 1-412
na, 2-3 597-598u. 11 Zeggoud, lahcen, 29111.22
gestão de riscos na, 316-318 \'(/orld \Tlide Ftmd for Natttre Zielinski, D., sobre recompense a
metodologia da, 239-242 Internatio11al ( WWF): equipes de projetos, 461
processos de gerenciamento excelência no, 139-1 4 3 zona discricionária, 400-401
integrado da, 316-318 gerenciamento de portfólio no, Zurich America lnsurance
WBS, veja estrutura analítica do 599-604 Company:
projeto (WBS, work breakdown Wurtz, Heidi: apoio da gerência na, 379-381
str11c.t11re) sobre a validação de melhores processos integrados da, 306-
Weiss, Jeff, sobre gestão de práticas, 42 308
projetos, 13 sobre as melhores práticas, Zuurdeeg, Robert J., sobre gestão
Weiss, Zev, sobre gestão de 21n.16,42 de projetos global, 632-633n.3
projetos, 12

Gestão de Projetos - As Melhores Práticas, 3 Edição KERZNER, Harold OCR

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gestão de Projetos - As Melhores Práticas, 3 Edição KERZNER, Harold OCR

Enviado por

Direitos autorais:

Formatos disponíveis

Harold Kerzner é um especialista internaciona lmente reconhecido na área de gestão

de projetos e Diretor Executivo Sênior no lntemational lnstitute for Learning (IIL). É

K4lg Kerzner, Harold .

Editado como livro impresso em 2016.

1. Gestão de projetos. 2. Metodologias de

Catalogação na publicação: Poliana Sanchez de Araujo - CRB 10/2094

Gerente editorial: Arysinha jacqttes Affonso

Colaboraram nesta edição:

Editora: Maria Edttarda Fett Tabajara

Capa: Márcio lvfonticelli

Imagem da capa: ©thinkstockphotos.com / }11piterimages, Leonard Zakim Bridge, Boston,

Leitura final: Lia Cremonese

Reservados todos os direitos de publicação, e1n língua portuguesa, à

Unidade São Paulo

SAC 0800 703-3444 - W\V\v.grupoa.com.br

É proibida a duplicação ou reprodução deste volume, no todo ou em parte, sob quaisquer

Seminários e webinars sobre os princípios e as melhores práticas de gerenciamento

Telefone: 800-325-1533 ou 212-515-5121

Capítulo 1 Compre endendo as melhores práticas 1

Capítulo 2 Da melhor prática a uma enorme dor de cabeça 67

2.4 Dor de cabeça n" 4: mudanças nas exigências do cliente 70

Capítulo 3 Jornada rumo à excelência 106

Capítulo 4 Metodologias de gestão de projetos 189

Capítulo 5 Processos integrados 301

Capítulo 6 Cultura 333

Capítulo 7 Apoio por parte da gerência 373

7.4 Patrocínio em ação na Hev.rlett-Packard 379

Capítulo 8 Treinamento e formação 399

Capítulo 9 Gestão informal d e p ro jetos 439

Capítulo 10 Excelência comportamental 452

Capítulo 11 Medindo o retorno sobre o investimento em treinamento

Capítulo 12 O escritório de projetos 485

Capítulo 13 S e is S igma e o escritório de gestão de projetos 562

Capítulo 14 Gere nciame nto d e portfólio de projetos 578

Capítulo 15 Exce lê ncia e m g e s tão de proje tos g lo bal 605

Capítulo 16 Gestão de p rojetos o rientada a valor 713

1.2 Melhores práticas em gestão de projetos:

1.3 Melhores práticas em gestão de projetos:

• Uso de templates (p . ex.: para a especificação do trabalho [SO\V, statement of

1.4 Melhores práticas em gestão de projetos:

TABELA 1-1 Cinco fases do ciclo de vida da gestão de projetos

Aceitação pela Aceitação pela

Reeonheeera Estabelecer patroci- Proporcionar conhe- Obter comprometi- Desenvolver um pro-

e1npresa reconhece que a sobrevivência da empresa está em jogo, a implementação da

Eficiência e eficácia Projetos

Enrique Sevilla Molina, profissional da área, antigo di retor corporativo do PMO,

Eficácia e Organizações não Organizações

Figura 1- 2 Velocidade da matu ridade.

i Sandra Kumorowski é professora assistente de comunicação e marketing no Columbia College, Chicago;

TABELA 1-2 A necessidade da gestão de projetos

p rogramação e o controle, a lém da seleção de utn software de suporte apropria do .

TABELA 1-3 Fatores críticos no ciclo de vida da gestão de projetos

Fatores críticos de sucesso Fatores críticos de fracasso

Figura 1- 3 Custos versus benefícios da gestão de projetos.

Durante a primeira década do século XXI, a compreensão e a aceitação dos be-

1.5 A gestão de projetos vista por um executivo

ções econõm icas ou à intensificação da concorrência, espera-se que os funcioná rios

A gestão de projetos é vital para o sucesso de qualquer organização. Independentemente

dagens predefinidas já testadas, usando listas de conferência preexistentes para garantir a

1.6 Processo de melhores práticas

Figura 1-4 Processos que envolvem as melhores práticas.

1.7 Passo 1: definição de uma melhor prática

Exemplos de algumas de nossas melhores práticas incluem: