Você está na página 1de 226
Lo FUNDAMENTOS EM GESTAO PROJETOS CONSTRUINDO COMPETENCIAS PARA GERENCIAR PROJETOS REVISADA E AMPLIADA MARLY MONTEIRO DE CARVALHO @qigp Comm Imam é ef totais do MAM ] gmmEPogagEND Omi COMO mE de Producéo pela UFSC (bolsa Capes e CNPq) € engenheira de produgio mecdnica pela Escola de Engenharia de Sao Carlos da USP (EESC-USP). E vice-coordenadora de pesquisa da escola Po- litécnica da USP, coordenadora do grupo de pesquisa Qualidade e Engenharia do Produto (QEP) inscrito no diretério dos grupos de pes- quisa do CNPq, do qual também recebe bolsa de produtividade em pesquisa, e coordenadora do curso de especializacao em gestéo de proje- to da Fundagao Vanzolini (CEGP-FCAV). Foi por seis anos editora da revista Producéo, disponivel na base de dados Scielo, e atualmente é coedi- tora. E membro do conselho editorial (editorial advisory board) do Journal of Manufacturing Technology Management, disponivel na base de dados Emerald, desde 2006. Foi membro da diretoria da Associagio Brasileira de Engenharia de Produgéo (Abepro), por duas gestdes conse- cutivas, ocupando 0 cargo de Diretora Técnica e de 2: Vice-Presidéncia, e pesquisadora do Ins- tituto de Pesquisas Tecnolégicas do Estado de ‘So Paulo ~ Divisdo de Economia e Engenharia de Sistemas de 1992 a 2000. Seus princip teresses em pesquisa so nas éreas de estratégia competitiva, gestdo de projetos e da inovago e Ggestéo da qualidade. Autora do livro Inovacdo: estratégias e comunidades de conhecimento e coautora de Estratégia competitiva: dos con- ceitos 4 implementagdo e co-organizadora de Gerenciamento de projetos na prética: casos brasileiros (2 volumes), publicados pela Atlas. Fundamentos em gestado de projetos Marly Monteiro de Carvalho Roque Rabechini Jr. Fundamentos em gestao de projetos Construindo competéncias para gerenciar projetos 3? Edi¢ao (Revisada e Ampliada) 'SAO PAULO EDITORA ATLAS S.A. - 2011 © 2005 by Editora Atlas S.A. , ee As duas primeiras edicGes traziam o titulo Construindo Z ‘ competéncias para gerenciar projetos; 3. ed. 2011; 2. reimpress4o > ES 4b | Capa: Leonardo Hermano SS H Composigao: Formato Servicos de Editoracao Ltda. ! Dados Internacionais de Catalogagao na Publicagao (CIP) (Camara Brasileira do Livro, SP, Brasil) | Carvalho, Marly Monteiro de Fundamentos em gesto de projetos: construindo competéncias para gerenciar projetos / Marly Monteiro de Carvalho; Roque Rabechini Jr. - 3. ed. ~ Sao Paulo : Atlas, 2011. Bibliografia. ISBN 978-85-224-6228-5 1. Administragao de projetos I. Titulo. 05-5667 CDD-658.404 indices para catalogo sistematico: 1. Gestao de projetos : Administracdo de empresas 658.404 2, Projetos : Gestao : Administracao de empresas 658.404 TODOS OS DIREITOS RESERVADOS - £ proibida a reproducdo total ou parcial, de qualquer forma ou por qualquer meio. A violagéo dos direitos de autor (Lei n? 9.610/98) é crime estabelecido pelo artigo 184 do Cédigo Penal. Depésito legal na Biblioteca Nacional conforme Decreto n® 1.825, de 20 de dezembro de 1907. Impresso no Brasil/Printed in Brazil igi Editora Atlas S.A. Rua Conselheiro Nébias, 1384 (Campos Elisios) 1203-904 Sao Paulo (SP) Tel.: (011) 3357-9144 www.EditoraAtlas.com.br ‘Aos nossos pais pelo exemplo e dedicagao. Ao meu pai Mauro e a minha saudosa mae Maria do Carmo A minha mie Filomena Geny e a0 meu saudoso pai Roque As nossas familias, fonte de alegria, motivacao e inspiragao. Alexandre, Lucas e Diogo Fernando, Marcelo e Cristina Sumario Nota sobre os autores, xi Preflicio, xiii Mudangas na 3¢ edigao, xvii Parte I- A PRIMEIRA ONDA: COMO GERENCIAR BEM PROJETOS, 1 1 Gestao de Projetos: perspectivas e modelo de referéncia, 5 1.1 Gestdo de Projetos: evolucdo e tendéncias, 6 1.2. As duas ondas da Gestdo de Projetos, 10 1.3 Modelo de referéncia para andlise, 13 Questées para reflexiio e discussdo, 20 2 Oque é projeto?, 21 ! 2.1 Conceitos: projeto e Gestdo de Projetos, 21 2.2. Caracteristicas dos projetos, 22 2.3, Sucesso em projetos, 37 2.4 Caso: projeto Eurotunnel, 43 Questées para reflexéio e discussaio, 46 i 3 Boas praticas de Gestdo de Projetos, 48 3.1 Fatores criticos de sucesso, 49 3.2 Gestiio Contingencial de Projetos - Modelo It, 51 3.3 Introdugao aos Guias de Conhecimento (BoKs) em Gesto de Projetos, 55 3.4 O guia PMBoK®, 59 J Vili Fundamentos em gestio de projetos + Carvalho e Rabechini Jr. 3.5 Caso: constru¢do da casa de Eduardo e Ménica, 64 Questaes para reflexiio e discussdo, 66 4 Gestao da integragao do projeto, 68 4.1. Introducio, 69 4.2. O inicio: a formalizagao do projeto - project charter, 72 4.3. O meio: a composicao e o monitoramento do plano do projeto, 76 4.4 O fim: nao se esqueca de formalizar o encerramento do projeto, 81 Questées para reflexdo e discussdo, 83 5 GestAo do escopo do projeto, 85 5.1 Introducao, 86 5.2 Coletar requisitos e definir 0 escopo do projeto, 88 5.3 Estrutura analitica do projeto, 89 5.4 Acordando o escopo do projeto com os stakeholders, 96 5.5 Verificacdo e controle das alterag6es do escopo, 97 5.6 Caso: cercando 0 escopo do projeto, 100 Questées para reflexdo e discussio, 102 6 Gestao de tempo do projeto, 104 6.1 Introdugao, 105 6.2 Desdobrando a WBS em atividades do projeto, 106 6.3 Desenvolvimento do cronograma, 114 6.4 Exercicios resolvidos, 130 Questées para reflexdo e discussao, 134 7 Gestdo de custos, 136 7.1 Introdugo, 137 7.2. Preparando o orgamento do projeto, 139 7.3. Custos do projeto, 144 7.4 Monitoramento e controle dos custos, 156 7.5 Avaliando o desempenho do projeto, 158 Questées para reflexiio e discussdo, 167 8 Gesto da qualidade, 170 8.1 Introdugao, 171 8.2 Conceito de qualidade, 173 : ie 8.3 Elabora¢do do planejamento da qualidade do projeto, 175 8.4 Mecanismos de garantia e controle da qualidade de projetos, 184 ets | PET. 10 7 12 sot y Sumério. ix 8.5 Controle integrado da qualidade de projetos, 196 Questées para reflexdo e discussio, 202 +:.- Gestdo dos recursos humanos do projeto, 204 9.1 Introdugio, 205 9.2 Quem faz 0 qué?, 206 9.3. Aspectos da formacao de equipe: histograma de recursos, 209 9.4 Aspectos comportamentais e o amadurecimento da equipe de projeto, 212 9.5 Caso: os conflitos nas equipes de projeto, 218 Questées para reflexao e discussao, 219 Gestdo das comunicagées do projeto, 221 10.1 Introducao, 222 10.2. Framework de gestao da comunicacao em projetos, 224 10.3 Conceito de emissor — receptor, 226 10.4 Identificacao e gesto dos stakeholders, 232 10.5. Distribuigao de informagoes e a geracao dos relatos de desempenho do projeto, 241 10.6 Caso: rufdo no sistema de comunicagao do projeto, 244 Questées para reflexio e discussdo, 246 Gestio dos riscos, 247 11.1 Introdugao, 248 11.2. Conceito de riscos, 251 11.3 As fases iniciais da gestao do risco, 254 11.4 Anilise dos riscos do projeto: os aspectos qualitativos e quantitativos, 262 11.5 Estratégias de respostas, monitoramento e controle dos riscos, 274 Questées para reflexdo e discussio, 278 Gestao das aquisigées do projeto, 281 12.1 Introdugao, 282 12.2. Tipos de contrato, 284 12.2 O que contratar, quando, como, quanto e sob quais requisitos, 287° 12.3. A importancia da seleco da administra¢ao dos contratos, 292°) 12.5 Caso: contratagao modalidade EPC - Engineering, Procurement and Construction — para construgao do aeroporto de Quesnel, Canad4, 296 Questoes para reflexdo e discussio, 298 Sustentabilidade em projetos, 299 13.1 Introducao, 300 X ‘Pundamentos em gestio de projetos * Carvalho e Rabechini Jr, |. ———_________________ atk} 13.2. O conceito de sustentabilidade, 301 «. 13.3 O gerenciamento de projetos e a sustentabilidade, 303 13.4 Alinhamento das areas de conhecimento a sustentabilidade, 306 13.5 Caso: ponte estaiada, 321 13.6 Caso: Usina Hidrelétrica de Belo Monte, 322 Questées para reflexito e discussio, 324 Parte Il - SEGUNDA ONDA: PREPARANDO A ORGANIZAGAO PARA A EXCELENCIA EM GESTAO DE PROJETOS, 327 14 Alternativas estruturais em projetos, 329 14.1 Tipos de estruturas, 330 14.2. Escritérios de Gestio de Projetos, 341 14.3. Alinhando estratégia, estrutura e projetos, 348 Questées para reflexi e discussiio, 351 15 Rumo a maturidade em gestio de projetos, 353 15.1 Maturidade em gestao de projetos: conceitos, 354 15.2. Modelos de maturidade corporativos, 355 15.3 Caso: modelos de maturidade avaliados numa empresa de transporte aéreo, 360 15.4 Gerenciamento do portfélio de projetos, 363 Questées para reflexdo e discussdio, 370 16 Competéncias em gestao de projetos, 372 16.1 Introdugao, 372 16.2 Competéncias aplicadas a Gestio de Projetos, 373 16.3 Competéncias individuais em Gestao de Projetos, 375 16.4 Competéncias dos times em Gestdo de Projetos, 383 16.5 Modelo integrado de competéncias em Gestdo de Projetos, 389 16.6 Caso: gestéo das competéncias em GP na Perdigio, 395 16.7 Competéncia: a visdo dos institutos e associacées, 401 Questdes para reflexdo e discusstio, 403 Referencias bibliogréficas, 405 Nota sobre os Autores MARLY MONTEIRO DE CARVALHO € professora livre-docente da Escola Politécnica da USP, atuando na graduacao e pés-graduaco do Departamento de Engenharia de Producio, desde 1992. E vice-coordenadora de pesquisa da Escola Politécnica. Coordena o grupo de pesquisa Qualidade e Engenharia do Produto (QEP), onde desenvolve projetos de pesquisa com empresas e com apoio de érgios de fomento, tais como Capes, CNPq, Fapesp, entre outros. Coordena o curso de Especializaco em Gestao de Projetos da Fundacao Vanzolini (CEGP/ FCAV). Autora de diversos artigos e livros publicados no Brasil (Inovagdo: estratégia € comunidades de conhecimento; Construindo competéncias para gerenciar projetos; Gestéo de projetos na pratica I e Il; Gestdo da qualidade; Estratégias para a competitividade; entre outros) e nos Estados Unidos (Strategic alignment process and decision support systems: theory and case studies). Possui livre-docéncia pela Escola Politécnica da USP (2006), pés-doutoramento em Engenharia Gestional pelo Politécnico de Milo (Italia) (2004), doutorado e mestrado em Engenharia de Produgao pela Universidade Federal de Santa Catarina, em 1991 e 1997, respectivamente, e graduacao em Engenharia de Produc4o MecAnica pela Escola de Engenharia de So Carlos da USP (1987). Foi editora da Revista Produgdo por seis anos (2002 a 2007), disponivel na base de dados Scielo, e é atualmente do corpo editorial. £ membro do conselho editorial (editorial advisory board) do Journal of Manufacturing Technology Management, disponivel na base de dados Emerald. Foi membro da diretoria da Associa¢ao Brasileira de Engenharia de Produgdo (ABEPRO), por duas gestdes consecutivas, ocupando o cargo de Diretora Técnica e de 28 Vice- - Presidéncia. Foi pesquisadora do Instituto de Pesquisas Tecnolégicas do Estado de Sao Paulo de 1992 a 2000. xii, Fundamentos em gestio de projetos * Carvalho e Rabechini J ROQUE RABECHINI JR. é pés-doutor pela FEA/USP e doutor em Engenharia de Produgao pela Escola Politécnica da Universidade de Sao Paulo (USP). E diretor da C&R Consultoria Empresarial, onde desenvolve trabalhos de consultoria e treinamento em empresas. Pesquisador em tecnologia, foi chefe de agrupamento de Prospecgao e Avaliaco Tecnolégica do Instituto de Pesquisas Tecnolégicas do Estado de Sao Paulo (IPT). Trabalhou também na Gazeta Mercantil. Professor do Mestrado Profissional em Gerenciamento de Projetos da Universidade Nove de Julho, professor convidado da FEA-USP e dos cursos de pés-graduacao: Curso MBA em Administrago de Projetos da Fundagio Instituto de Administra¢ao (FIA); Curso MBA em Inovacio de Laboratério de Automacao de Redes Computacionais (LARC-USP); Curso MBA em Gestao de Projetos da FGV Management (Fundac4o Getulio Vargas); e Curso de Estratégia da Inovagdo Tecnoldgica do Departamento de Politica Cientffica e Tecnologia da Unicamp. Autor do livro O gerente de projetos na empresa, da Editora Atlas, ede artigos sobre gerenciamento de projetos publicados em congressos de inovacao tecnolégica, nacionais e internacionais, e nas revistas RAE - Revista de Administragdo de Empresas, da Fundacao Getulio Vargas, e Revista de Administragdo, da USP. Os autores também escreveram o livro Gerenciamento de projetos na pratica: casos brasileiros, primeira publicacao, envolvendo empreendimentos nacionais, também pela Editora Atlas. Prefacio ‘A 4rea de Gesto de Projetos tem assumido maior importancia nas empresas que tém passado por um processo de transformacéo, organizando-se para poder dar respostas eficazes e 4geis 4s questdes ambientais e organizacionais. Em consequéncia, na década de 1990 houve uma forte retomada em gerenciamento de projetos no Brasil e no mundo, e essa retomada pode ser vista em forma de ondas. Na primeira onda foram tratadas as questdes basicas de gerenciamento de Projetos, com foco no projeto. Nessa onda, proliferaram os cursos de treinamentos fundamentais em gerenciamento de projetos, com base no guia PMBoK (Project Management Body of Knowledge) do PMI (Project Management Institute). A intensificacao na utilizacdo de softwares de apoio ao gerenciamento dos projetos e uma maior atenco as informagées do projeto também foram verificadas. Além disso, o monitoramento e a andlise de desempenho dos principais objetivos do Projeto (escopo, prazo, custo e qualidade), com base em indicadores de valor agregado (EVA — Earned Value Analysis), foram implementados. Para demonstrar a forca dessa primeira onda em Gesto de Projetos, um dado impressionante é o numero de profissionais-membros do Project Management Institute (PMI), que superou a casa dos 300 mil, e segue em uma taxa de crescimento expressiva. Trata-se de um fendmeno global, com penetracao em 171 paises. Sua penetracao na América Latina também tem crescido, na casa dos 10 mil membros, a maioria no Brasil (PMI, 2008). " As grandes empresas brasileiras de tecnologia tém investido nesse tipo de formaco, como a Petrobras, bem como as subsididrias de empresas internacionais, influenciadas pelas matrizes, como é 0 caso da IBM, Siemens,;Motorola, HP, Telefonica, entre outras. Lae | xiv Fundamentosem eto de rojtos + Cava Rakehin stil FEL Na Parte I, o tema central refere-se 4 segunda onda, onde serao tratados os Essa primeira onda criou 0 caldo de cultura necessério para o surgimento da bs : - cases B 2 fatores relevantes para a gestao de projetos no 4mbito organizacional. Essa parte \ | segunda onda, que é a géstdo de projetos em ambito organizacional. A segunda 2a gest: “88 | onda em gerenciamento de projetos, além de cumprir os requisitos da primeira, esta Sahat em cee que watam 7 fe e estrutura, modelos visa produzir mais resultados: ser mais eficaz! A segunda onda deverd levar de maturidade e compe g projetos. | i jc iva de inovacdo a propria ativi i ituai ivro-t ompreendé- © gerenciamento de projetos como uma alternativa de inovago a prdpria atividade E, para consolidar os aspectos conceituais deste livro-texto e compreendé- gerencial. los na pratica, criaram-se 0s livros de caso que dao sequéncia a esse projeto: | Gerenciamento de projetos na prdtica: casos brasileiros e Gerenciamento de projetos | I Em busca da eficdcia no gerenciamento de projetos, é necessdrio promover cra por Pen : na prdtica 2: casos brasileiros. o alinhamento estratégico, que pode ser atingido através da adequada gestao do | portfélio de projetos, da implementagao de uma estrutura apropriada na forma de escritérios de projeto e da construgao de competéncias e de maturidade em gestao de projetos em ambito organizacional. | No entanto, é necessdrio nao sé avangar na sedimentagio de técnicas e ferramentas pouco exploradas na primeira onda, como a gestdo do risco, mas também criar elementos que possam sensibilizar uma camada mais estratégica das empresas. Nesse aspecto, 0 gerenciamento da carteira de projetos ira dar uma grande contribuicdo aos dirigentes das empresas, proporcionando um exame bem i detalhado das dimensées estratégicas que devem nortear o balanceamento da carteira e permitir a adequada priorizagao dos projetos, bem como criar mecanismos de controle e descarte de projetos. i Muitas empresas perderam a primeira onda e esto agora correndo para alcancar suas concorrentes em eficiéncia. Perder a segunda onda, nessa légica, significa ser menos eficaz, e isso pode representar perda de posicdes de mercado. Este livro é resultado de um trabalho em gerenciamento de projetos que pretende | cobrir as necessidades das duas ondas. O livro esta estruturado em 16 capitulos. Os dois capitulos iniciais abordam as perspectivas da Gestao de Projetos, modelo de referéncia, os conceitos e definic6es-chaves que sero utilizados ao longo do livro, tais como 0 que é projeto € 0 que é sucesso nessa perspectiva. Os demais capitulos sao divididos em duas partes, que representam a fronteira entre as duas ondas de gestao.de projetos. Na Parte I, a tematica central refere-se 4 primeira onda. Essa parte é constituida i de 13 capitulos. Apés os dois capitulos que tratam de modelos de referéncia e conceitos, ha um capitulo de boas praticas em gestao de projetos, que apresenta os principais guias de ‘teferéncias. Na séquéncia, por meio de nove capitulos, ‘ sao apresentadas as dreas ‘de conhecimento (integragao, escopo, tempo, custo, | qualidade, recursos humanos, comunicacao, risco e aquisigées) propostas no guia do PMI; e um capitulo que os autores’ consideram irreversivel na questao | | gerencial e que se refere a uma proposta de nova 4rea, sustentabilidade, que fh marca a transicao das Partes'l e Il, uma vez:que esse tema pode ser visto tanto da perspectiva do projeto quanto da organizacao. | Mudangas na 32 Edicao Esta terceira edicdo traz significativas alteracdes com relacdo as edicdes anteriores. A primeira e mais evidente é 0 alinhamento de seu contetido a nova versao do guia de gerenciamento de projetos, PMBOK, que est4 em sua 44 edicdo, publicada nos Estados Unidos em 2008. Além disso, introduzimos dois novos capitulos, que incorporam a visio de outros “guias de conhecimento” (body of knowledge — BoKs) de outras associacées da drea de Gestao de Projetos para referencial comparativo, como o da International Project Management Association (IPMA) e 0 PRINCE 2 - Project in Controlled Environments, estabelecido pela organizacao do Reino Unido Office of Government Commerce (OGC). A visao contingencial e agil de gerenciamento de projetos (Capitulos 2 ¢ 3) é apresentada e o tema de sustentabilidade é objeto de detalhada reflexdo no contexto de projetos. Todos os capitulos apresentam ampliacao e reformulacao com aprofundamento de alguns temas, como gerenciamento de portfdlio e indicadores multidimensionais e painéis de desempenho. Marly Monteiro de Carvalho e Roque Rabechini Jr Agradecimentos Aos érgaos de fomento Fapesp, Capes e CNPq que, no apoio aos projetos de pesquisa, propiciaram os recursos necessdrios para 0 desenvolvimento dos trabalhos que culminaram com a elaboracdo deste livro. Aos nossos alunos dos cursos de graduacdo, pés-graduacdo e extensao, que contribuiram e motivaram esta obra. Ao Departamento de Engenharia de Produgao, 4 Fundacio Carlos Alberto Vanzolini, ao Programa de Mestrado (Profissional) e Doutorado da Universidade Nove de Julho, 4 Fundaco Instituto de Administragao (FIA), 8 FGV Management eao Laboratério de Arquitetura e Redes de Computadores (LARC) da USP pelo apoio as publicagées académicas e aos projetos de pesquisa. i Aos colaboradores da C&R Consultoria de Empresas pelas oportunidades geradas nas consultorias realizadas a essas empresas. As nossas familias, em especial, Alexandre, Lucas e Diogo, pelo apoio e compreensao as demandas do trabalho, sempre com amor. Ao Mauro, pai zeloso, que sempre se dedicou incondicionalmente. Ao tio Aloizio Bignardi de Lima, pela revisdo cuidadosa, e 4 tia Zoé, pelo carinho e dedica¢ao. Aos meus queridos Marcelo, Fernando e Cristina e 4 minha mae Filomena Geny, aos quais, além de dedicar o livro, agradeco o imenso apoio. Parte I A primeira onda: como ws gerenciar bem projetos O conjunto de conhecimentos em gerenciamento de projetos pode ser repre- sentado, em sintese, por uma série de capacitacées e competéncias que interessa, e tem sido comumente aceita, por todos os envolvidos em projetos de diversas naturezas. Ointeresse em gerenciamento de projetos pode ser explicado pela observacio de que na era do conhecimento, em que vivemos, so as atividades inteligentes {as de projetos, portanto) que mais adicionam valor aos produtos/servicos e nao as atividades rotineiras. Ou seja, atividades ligadas a P&D (Pesquisa e De- senvolvithento), projeto de produtos e de processos, logistica, administragao da Tecnologia da Informacao, desenvolvimento de recursos humanos, entre outras, estao no grupo das atividades mais importantes para empresas que precisam ser mais competitivas em seus mercados. Assim, é claro que as atividades t{picas de projetos (atividades inteligentes) precisam, cada vez mais, ser administradas eficazmente. Foi durante a década de 1990 que se consolidaram os principais guias de conhecimentos em gerenciamento de projetos (Body of Knowledges - BoKs), que suportaram bem-sucedidas certificacdes profissionais. Naturalmente, na busca de administracdo por projetos um fator inibidor pode ser detectado: a configuracao dos grandes projetos tradicionais. No entanto, a corrida em diregdo ao gerenciamento. de Projetos, iniciada pelas empresas de forma mais acentuada no inicio dos anos 2600, tem levado em conta ‘0 contra- ponto existente entre a forma de’gerenciamerito de projetos profissi¢hal versus 0 tradicional. Ley 2 FF oluaiqs 4 if 2. Fundamentos em gestfo de projetos * Carvalho e Rabechini J. A primeira onds como gerenciarbem projetos. 3 Antes, quem adotava administra¢ao por projetos eram as grandes emprei- teiras, rgdos governamentais responsdveis por empreendimentos cujo prazo médio variava de trés a cinco anos. Atualmente, houve um notdvel crescimento da participacdo das empresas do setor da Tecnologia da Informacio interessadas em gestao de projetos. Estas desenvolvem projetos que demoram entre 2 e 24 meses, 0 que impde uma mudanca significativa na unidade de medida de prazo vista até entdo, de anos para meses. Mudancas também ocorreram no enfoque adotado pelo gerente de projetos e foram extremamente significativas, saindo de uma abordagem eminentemente técnica (em torno de 70% nos anos 70 a 80) para uma de enfoque mais gerencial (cerca de 90% atualmente). Nesse sentido, um novo perfil de gerente de proje- tos se configura, e sua competéncia est4 na capacidade de resolver os conflitos dos diferentes interessados no projeto, de melhorar o desempenho das equipes (muitas vezes virtuais e multilocalizadas), vencer os desafios da comunicasio, garantir a qualidade dos diversos produtos/servicos gerados pelo projeto; enfim, centrar suas agdes muito mais nos aspectos gerenciais e comportamentais que Nos aspectos técnicos. Nesse panorama atual, o gerenciamento de projetos vem sendo utilizado de forma profissional, visando contribuir com as empresas para que estas consigam resultados melhores. A mesma pesquisa que identificou outrora que apenas 16% dos projetos atingiam o sucesso mostra dados mais animadores atualmente, em que o sucesso é alcancado em 28% dos casos. A causa desse aumento: a adogao das praticas de gerenciamento de projetos. O movimento atual em torno do gerenciamento de projetos, assim, nao é mais um alvo a ser alcancado. Hoje, ja é realidade em muitas empresas. No final desta parte, o leitor ter4 visto os conceitos e praticas das seguintes reas de conhecimento: Capitulo 3 - Boas praticas de Gestao de Projetos Capitulo 4 — Gestio da integracdo do projeto Capitulo 5 - Gestao do escopo do projeto Capitulo 6 - Gest&o de'tempo do projeto Capitulo 7 = Gestao-de custos Capitulo 8 - Géstao'da qualidade Capitulo 9 - Gestao dos recursos humanos do projeto Capitulo 10 ~ Gestao das comunicacées do projeto Capitulo 11 - Gestio dos riscos Capitulo 12 - Gestao das aquisicdes do projeto Capitulo 13 - Sustentabilidade em projetos O Capitulo 13 faz a transicdo entre a Parte I e a Parte Il, pois ha no tema sus- tentabilidade uma dimensio organizacional e uma dimensio relacionada ao projeto. (onions e0i3i 4 o> . ctbsie sh Oeste ils ’ vis J fine Gestao de Brojetos: perspectivas ‘ e modelo de referéncia 09 6h | Parte I~ A organizagso Eficdcia Parte 1-0 projeto Cadeia de valor o uate Neste capitulo, apresentamos a evolucao da gestao de projetos, as pers- 4 pectivas e tendéncias da rea, bem como um modelo de referéncia para 4 estudar essa disciplina. Esse modelo i integra questdes intrinsecas do geren- i ciamento do projeto a questdes organizacionais. Apés estudar este capitulo, il © leitor estar apto a responder as segilifites questdes: | - 5 | Quais as duas ondas da Gestio de Projetos? | + €) Quais as perspectivas futuras para a area? : i id) Qual o modelo de referéncia?. 6 Fundamentos em gestio de projetos + Carvalho e Rabechini Je. — 1.1 Gestdo de Projetos: evolugao e tendéncias As empresas tém passado por um processo de transformac4o, organizando- se para poder dar respostas eficazes e 4geis aos problemas ambientais, e em especial aqueles que se referem 4 competi¢ao e ao posicionamento de mercado. Essas respostas constituem um conjunto de acdes ou atividades que refletem a competéncia da empresa em’ aproveitar oportunidades, incluindo, portanto, sua capacidade de agir rapidamente; respeitando as limitacdes de tempo, custo e especificacées. Para tal, investir na adogdo de técnicas e ferramentas de geren- ciamento de projetos é fundamental e tem sido uma preocupaco crescente nas empresas (CARVALHO, 2009). A configuragao das organizacdes na era p6s-industrial sera parecida com um “condominio”, em que grupos de projetos coabitam, uma vez que sao as atividades inovadoras e nao as rotineiras que mais agregam valor aos produtos e servicos (HANDY, 1995; FLEURY; FLEURY, 2000; CARVALHO, 2009). Essas transformagées foram se consolidando ao longo das tltimas décadas e cada vez mais as empresas que buscam inovacdo nao se encaixam mais no aparato gerencial da rotina, muitas vezes alicercado nos principios tayloristas e fordistas do inicio do século passado. A Figura 1.1 mostra a evolugao de um paradigma gerencial, com foco na rotina, para o paradigma gerencial, com foco na inovagéo (CARVALHO, 2009). cnn eee Toxslalsirone Rotina Inovacao ee ee RefecBncia inicial foi a Transigéo Valorizacio da Gestio de Projetos: produgdo em massa, racionalizagao “cientifica”, padronizagio e controle = Valorizacéo do capital intelectual COrganizagées inovadoras deixam de vender produtos e passam a vendar solugées (“servitizagao") Complexidade da inovagio, mobilidade do ‘apital intelectual levam a0 paradigma de inovagdo aberta e a gestéo de projetos complexos (consércios, EPCs etc.) Vis5o da estratégia baseada em recursos Customizagio em massa, fiexibilizagdo da produgao em massa — tradicional (variedade do mix de produtos e volumes, producao enxuta — lean, automacSo flexivel) - = Visio sistémica e percepcao dos custos de transagio (sistemas de _gestio, foco nas relagdes entre agentes da cadeia produtiva) - = Desenvolvimento de produtos (modularizacio) e inovacio fechada Fonte: Carvalho (2009). Figura 1.1 Transigdo dos modelos de gestao. i Gestio de Projetos: perspectivas e modelo de referéncia. 7 (. A transicao foi lenta e foram necessérias varias correntes evolutivas de gest40_ io. A primeira grande transigao foi a busca por flexibilidade, almejando a customiza¢do em massa. Foi preciso que os conceitos da produc&o enxuta (lean production) se disseminassem, bem como uma visao sistémica que olhasse nao 6.4 organizacdo, mas também sua cadeia e suas aliancas. No entanto, para lidar com a inovacao é preciso valorizar o capital intelectual, construindo as compe- téncias e gerindo o conhecimento, sem temer os riscos inerentes a inovacao, mas mitigando-os através de um bom gérenciamento de projetos é da construgao de redes e parcerias para inovacdo que ajudam a ratear os riscos (CARVALHO, 2009). Também no ambito do gerenciamento de projetos a transi¢ao foi paulatina. Embora as primeiras associagdes nessa 4rea datem da década de 1960, foi ape- nas ila década de 1990 que podemos considerar que a 4rea se consolidou e criou * identidade propria. As fases evolutivas esto ilustradas na Figura 1.2. iS Criagéo da disciplina de Gestio de Projetos na Graduagao (EC2) e Pos-Graduagao nna Escola Politécnica Pés-guerra 60's 70's 80's 90's i 2000's + Q Surgem as || Estagnacéo| Crescimento 4 associagées|| Destaque: Exponencial [PMA e Pm] Softwares Jdo namero de em GP Profissionais Certificados e Publicacoes Inicio da Segunda’ | Onda sett at Era | ET | o Anterior Projetos | Organizacao a Fonte: Carvalho; Rabechini Jr. (2007). Hast ‘ Figura 1.2° 'Evolugdio do gerenciamento de projetos. SOG Sate oe P aborngd)* i : oetanitiion htt Até a década de 1980, que chamamos de embrionéria, a Gestao de Projetos estava pulverizada em diversas dreas, sem ainda atingir uma identidade, Neésse periodo, que envolve 0 pés-guerra, temos como principais marcos da Gestao de 8 Fundamentos em gestio de projetos + Carvalho ¢ Rabechini J. Projetos a criagdo do método do caitiinho critico - CPM (Critical Path Method) e sua variante probabilfstica, PERT (Program Evaluation & Review Technique), que veremos em maiorés detalhes tio Capitulo 6. Na década de 1960 surgem as pri- meiras associagdes nos Estados Unidos e na Europa, como o Project Management Institute (PMI) ea International | Project. ‘Management Association (IPMA). Na década de 1970, ha um grande impulso ‘dé softwares de apoio 4 Gestao de Projetos como um promissor mercado, qué solidou nas décadas seguintes. No entanto, foi na segunda metade da década de 1990 que o crescimento da area foi vertiginoso, o que pode ser aferido pelo crescimento das associagdes e instituicdes de gerenciamento de projetos. Foi nessa década que varias associagdes publicaram as primeiras edic6es de seus guias de conhecimento em gerenciamen- to de projetos, em geral acompanhados de certificagao de profissionais (Bodies of Knowledge - BoKs), como 0 PMBoK® (Project Management Body of Knowledge) (PMI, 1996) e seu respectivo certificado, 0 Project Management Professional - PMP. ‘A 4rea experimentou um crescimento exponencial tanto no niimero de mem- bros das associages, quanto de profissionais certificados; também a pesquisa e as publicages cresceram na mesma propor¢do. Para ilustrar esse quadro, peguemos como parametro o ntimero de associados do PMI® - Project Management Ins- titute -, que cresce de forma consistente e impressionante nos EUA e em mais de 100 paises, inclusive no Brasil, que detém o maior numero de profissionais. certificados por esse instituto na América Latina. No inicio da década de 1990, o numero de sécios individuais do PMI® girava em torno de 15 mil; em meados da mesma década, esse numero atingiu a marca de 50 mil e o gerenciamento de projetos se consolidou como metodologia, passando a ser mencionado, por diversos estudiosos da administraco, como disciplina obrigatéria nas empresas que querem desenvolver e manter vantagens competitivas (FRAME 1999). Em 2008, o ntimero de associados do PMI® bateu a expressiva marca de 300 mil profissionais. A Figura 1.3 ilustra a evolugao do ntimero de membros do PMI nas tltimas décadas. No Brasil, as grandes empresas de tecnologia tém investido na formagao de profissionais especializados em gestao de projetos, tais como a IBM Brasil, Sie- mens, Unisys entre outras. Essas empresas em geral tém cursos de treinamento in company, além de pagar a primeira tentativa de aprovacdo no exame do PMI. Contudo, estudos baseados em empresas brasileiras mostraram que poucas tém formalizado e desenvolvido um modelo de gerenciamento do processo de inovacao e de projetos e, portanto, a drea ainda tem um grande desenvolvimento pela frente no pais (CARVALHO; LAURINDO, 2003; RABECHINIJR.; CARVA- LHO; LAURINDO, 2002; RABECHINI JR.; YU; CORREA, 1996). —_— esto de Projetos: perspectivas e modelo de referéncia: 9 Fonte: PMI (2008). Figura 1.3 Crescimento de membros do PMI® — Project Management Institute. Essa lacuna precisa ser sanada, pois vai de encontro ao cenario positivo de crescimento econémico que desponta no Brasil para os préximos anos, devido 4 demanda por desenvolvimento de infraestrutura para suportar 6 crescimento econémico em diversos setores como energia, transporte e telecomunicacées, bem como proporcionara desafiadores projetos na 4rea de engenharia. Além disso, sediaremos uma copa do mundo e uma olimpfada. Para tanto, nos com- prometemos a concluir, em curto prazo, os projetos propostos, sem desperdicio de recursos puiblicos, em um pais que ainda tem muitas demandas sociais que concorrem por esses recursos. Nesse contexto, ha demanda de grande refinamento das metodologias de gerenciamento de projetos para tratar da complexidade inerente a esse tipo de projeio, caracterizado por equipes multidisciplinares de grande porte, podendo envolver milhares de pessdaé de organizac6es'distintas, dispersas geografica- mente. O orcamento nao raro passa da casa dos milhées. ‘ A partir da virada do milénio,'as quest6es organizacionais de gestao de pro- jetos passaram a configurar urna nova tendéncia, que denominamos'ségunda onda, com foco’em modelos otganizacioniais dé géstao de projetos. Neste'aspecto, vale lembrar que, se na primeira'onda os diagnésticos e os treinamentos' foram os destaques, na segunda onda as empresas comegam a investir na implemen- 10. Fundamentos em gestio de projetos + Carvalho e Rabechini Je tagao de modelos de maturidade em projetos, como forma de gerir 0 processo de mudanga organizacional e estruturar os planos de acao rumo A exceléncia em gesto de projetos. Nesse sentido, deverao também vislumbrar o crescimento das competéncias e da maturidade em gerenciamento de projetos. . 1.2 As duas ondas da Gestdo de Projetos A evolugio recente da disciplina de Gestao de Projetos pode ser entendida como ondas: precisamente duas, conforme ilustra a Figura 1.4. Consolidagdo dos Modelos : guiasde Organizacionais de Alinhamento estratégico Maturidade Portfolio em Projetos conhecimento Desempenho e Valor Estruturas Competéncias Modelos Contingenciais Fonte: Carvalho; Rabechini Jr. (2007). Figura 1.4 As duas ondas de gerenciamento de projetos. Para dar vaz4o a essa onda, proliferaram os cursos sobre os fundamentos da dis- ciplina de Gesto de Projetos e suas abordagens, avangou-se no entendimento das técnicas e ferramentas de redes de atividades, cronogramas fisico/financeiro e estruturacao de projetos, entre tantos outros conceitos basicos. Tudo isso ali- cercado no uso mais intensivo da-Tecnologia da Informagao, no intuito de di: ponibilizar as informag6es dos projetos a tempo habil para a tomada de decisao. Gestdo de Projetos: perspectivas e modelo de referéncia 11 A primeira onda proporcionou, portant Ouso de técnicas e ferramentas, sem divida, tem ajudado as empresas em sua estruturacao por projetos, na organizacao das equipes e, fundamentalmente, na alocac4o mais adequada de seus recursos. Foi a onda da éficiéncia. : Entretanto, uma empresa nao sobrevive apenas fazendo as coisas de forma certa (DRUCKER, 1963). E preciso investir na eficdcia, ou seja, agora a hora é de resultados. Hora de ajuda-las a crescerem, sustentavelmente. Em decorréncia desse estado, surge o gerenciamento profissional de projetos, imbuido de novas abordagéns, sobretudo, contextualizado com uma realidade competitiva mais exigente. Surge, assim, a segunda onda, cujo enfoque é a organizagao. A palavra- chave é éficdcia, ou seja, fazer a coisa certa: Nessa direcdo, o gerenciamento de projetos, para poder se apresentar de forma Thais profissional, precisa ser desenvolvido com mais criatividade, mais competéncias gerenciais e com menos intui¢ao. A segunda onda deverd levar 0 gerenciamerito de projetos como uma alternativa de i inovagao a A propria’ at ee gerencial. mye A ‘segunda onda, assim, deve, definitivamente, realizar a integracao das 4reas de conhécimento consideradas no ambito do gerenciamento de projetos, que até agora sé estava nos papeis. Ouso de técnicas de simulagao, também, é outro caso que pode ser bastante explorado pelo ‘pessoal de projetos, assim como ocorre com os profissionais que trabalham com riscos financeiros, riscos empresariais etc. Essas técnicas, quan- do utilizadas de maneira plena, ajudam a configurar a administracdo em outras reas do conhecimento. As incertezas nos projetés's4o muitas e minimizé-las é uma tarefa’ que ainda poucos gerentes fazem: Nesse aspecto, cabe lembrar que os programas de simulaco podem ser utilizados,’também, para minimizar as incertezas‘de prazos e custos em projetos. Essa é uma forma mais criativa de utilizagao de recursos e ferramentas jd existentes que, em muitos casos, nao estao sendo exploradas devidamente. Outra cardctetistica dessa segunda onda é’a formacdo dos gerentes de pro- jetos. Agora com a ado¢do, por muitas empresas, de gerenciamento de projetos, nasce essé ‘novo profissional qué, além das ‘competéncias técnicas, tem de de- senvolver amas lace, incluindo af €4paCigadeSae HEROGIACAO)) Com 0 uso mais intensivo do gerenciamento de riscos em projetos, atrelado a um trabalho mais consciente‘e politico’do gerente de projetos e sua equipe, nen 12 Fundamentos em gestio de projetos * Carvalho ¢ Rabechini J. provavelmente, se evitariam casos como o que foi visto com o Metré de Sao Paulo, com a tragédia de Alcantara, com a plataforma da Petrobras, entre muitos outros casos. at ceigaie no bbs. Uma das novas alterniativas “que a segunda onda proporciona refere-se a profissionalizacao do gerenciamento ¢ dé projetos. E, nesse sentido, suas atencdes so vistas pelas camadas mais significativas das organizac6es. Surge, assim, a necessidade de entender o conjunto de projetos existentes na empresa e nao sé visualiz4-los individualmente. Nesse aspecto, o gerenciamento do portfdlio de projetos ira dar uma grande contribuicao aos dirigentes das empresas. Através de um exame bem detalhado das novas ideias que surgem continuamente nas empresas é possivel tragar e re- alimentar continuamente os planos estratégicos, gerando projetos mais especiais que os dos concorrentes. O incentivo A inovacdo certamente ira gerar projetos mais desafiadores e, com isso, dever4 proporcionar mais competitividade 4 em- presa. Além disso, 0 foco nao é mais o projeto, mas a multiplicidade de projetos € programas que concorrem por recursos continuamente. Estruturalmente, as acGes e processos em gerenciamento de projetos dessa segunda onda devem estar consolidados nos escritérios de projetos (PMO — Project Management Office) e, estes, dadas consideragGes aqui tragadas, se apresentam de forma mais estratégica. Uma visdo mais expressiva dos escritérios de projetos é que eles podem ser os elementos de integracdo dos varios esforcos (producao, marketing, financas, pessoal etc.) existentes numa empresa. A segunda onda dever4 também vislumbrar 0 crescimento das competéncias e da maturidade em gerenciamento de projetos. Nesse aspecto vale lembrar que, se na primeira onda os diagnésticos e os treinamentos foram os destaques, na segunda onda as empresas comecam a investir na implementa¢ao de modelos de maturidade em projetos, como forma de gerir o processo de mudanca organiza- cional e estruturar os planos de aco rumo A exceléncia em Gesto de Projetos. Nesse sentido, outros modelos de referéncia com o foco na Gesto de Projetos no ambito organizacional surgiram recentemente, como “The Standard for Portfolio Management”, The Organizational Project Management Maturity Model (OPM3™) eo Project Manager Competency Development Framework (PMCD), s6 para citar modelos do proprio PMI, bem como um novo certificado, como 0 Program Management Pro- fessional (PgMPSM), Além disso, existem também outras referéncias importantes, como a associa¢ao europeia International. Project Management Association (IPMA), com certificado em quatro niveis para profissionais da area de projetos. Dessa forma, é importante estar em sintonia com as novas tendéncias. Muitas empresas perderam a primeira onda e esto agora correndo para al- cangar suas concorrentes em eficiéncia. Nao surfar na segunda onda, nessa légica, significa ser menos eficaz, 0 que pode implicar perda de posicdes de mercado. “ee i Gesto de Projetos: perspectivas e modelo de referéncia 13 Preocupados com essa questdo e com os aspectos da competitividade das empresas; 0s autores propuseram o Modelo Estratégico de Gerenciamento de Projetos/iBRsWalO#® tlesenvolvido para atender as demandas da segunda onda. . A implementagao do model , 1.3 Modelo de referéncia para andlise A sobrevivéncia de'uma empresa, nos dias de hoje, requer de seus executivos ages rapidas, consequentes € coerentes. Nao é possivel desperdigar nenhum tipo de oportunidade. Ainda mais: é preciso crid-las! Para manter uma empresa viva, é preciso muito conhecimento, esforco e escolha de um conjuinto’ dé Braticas geren- ciais que a conduzam, com eficiéncia e eficécia, no sertidd de’atingir resultados relevantés: E sabido 0 quao complexa é essa tarefa. Segundo’ uma pesquisa do Sebrae, 56% das empresas fecham antes de completar trés anios ‘de vida. Uma das alternativas gerenciais que nos tiltimos anos tém se mostrado’ ‘bas- tante atraentes como op¢dd para os executivos das empresas éo gerénciamento de projetos. Muitos executivos optam pelo gerenciamento de projétos, talvez, por ser iima métodologia consagrada nas grandes empresas, como NASA, iBM, governo‘americano, nas empresas de construcdo civil e, mais recentemente, nas multinacionais de Tecnologia da Informacao e telecomunicagées:' Outros entendem que esto nas atividades nao rotineiras os valores essenciais a serem agregados aos produtos/servicos que desenvolvem. Tanto uns quanto outros buscam,’na verdade, algo que os ajude a transformar ideias em algo que dé a elas Spe de forma sustentavel, considerando-se o cendrio competitivo atual De'forma geral, todas as organizagdes vivem de projetos, mesmo. aquelas cujo produto final nao seja gerado por projeto. Nessa dire¢ao, sabe-se que as ditas atividades inteligentes de projetos sao responsdveis por 25% do-PIB-mun- dial, o que representa algo em torno de US$.10 trilhdes, segundo informacdes do Project Management Institute (PMI®), entidade americana com 35 anos de existéncia, voltada a disseminaco das praticas e certificadora em gerenciamento de projetos. Estima-se que ao redor do mundo 16,5 milhdes de trabalhadores estejam envolvidos com atividades de projetos. . ne ( Para Rabechini Jr. (2003), seguir rumo ao gerenciamento de projetos édispor de competéncias individuais, em equipes e,na organizacao, segundo estratégias bem definidas, estabelecimento de rocess0s & efetivacao de mudanicas. A institucionalizacZo de gerenciamento de Projetos nas empresas é um esfor- ¢0 continuo que precisa de apoio nao sé dos executivos, mas também de todos os i Gestdo de Projetos: perspectivas e modelo de referéncia 15 14 Fundamentos em gestio de projetos + Carvalho e Rabechini Jr. funciondrios envolvidos. Os primeiros passos da estrada que leva as empresas a exceléncia em gerenciamento de projetos séo importantissimos; qualquer trope¢o pode significar a perda de uma oportunidade. 5 Algumas empresas, quando decidem implementar o gerenciamento de pro- jetos, precisam antes definir um fluxo que represente as atividades de inova¢ao, para entao estabelecer um road map que oriente todos os envolvidos na condugao de projetos. O objetivo de profissionalizar o desenvolvimento das atividades nao rotineiras é certamente melhorar os resultados dos projetos: prazos cumpridos, custos controlados e qualidade desejada. Nesse inicio do processo de implementa¢4o de gerenciamento de projetos, o trabalho de convencimento da alta administracdo de investir em projetos tal- vez seja o mais Arduo dessa fase. Essa dificuldade ocorre porque todos sabem que as decisdes tomadas vao desencadear efetivas mudancas na organizacao e 08 envolvidos precisam sentir que vale a pena ir por esse caminho. No entanto, mudanca, como se sabe, nem sempre é bem-vinda no ambiente corporativo. As regras de poder est4o em jogo. Nessa fase, além do mais, é preciso definir os treinamentos para disseminaco do conhecimento em gerenciamento de projetos, bem como estabelecer as 4reas e os indicadores a serem tratados inicialmente. Uma vez estabelecidos os processos de gerenciamento, faz-se muito im- portante que as pessoas aprendam a utiliz4-los e comecem a perceber que os resultados vao aparecer. Para que isso aconteca, muitas organizag6es tém praticado a politica de ins- pecdo em projetos, visando ajudar os gerentes na condugao de seus projetos. Na verdade, dois aspectos s4o relevantes para a decisdo das inspegdes: o primeiro é tirar as pedras do caminho e tornar mais faceis as praticas gerenciais; o segundo é mostrar aos envolvidos que nao ha mais caminho de volta. A equipe do PMO (Project Management Office, ou escritério de projetos), nesse sentido, assume um papel relevante, pois passa'a realizar reunides com 0s gerentes, ajudando-os na definicao de estratégias e objetivos de cada um dos empreendimentos. A resposta dos gerentes, em geral; é imediata, pois a percep¢ao do nivel de profissionalizacéo aumenta consideravelmente.. Ao se aperfeicoar nas praticas gerenciais de projetos, as empresas criam mecanismos de estabelecer suas proprias metodologias, via de regra, baseadas no guia do PMI®. O aperfeigoamento ¢aracteriza-se como uma nova fase de de- senvolvimento do gerenciamento de projeto nas organizag6es. Para Kerzner (2001), um dos autores mais produtivos em gerenciamento de projetos da atualidade, o aperfeicoamenito das praticas de gerenciamento de projetos leva a maturidade. Conseguir uma metodologia singular é dar 4 empresa condicées de obter sinergia, combinando varias metodologias dentro de uma ' i unica, sendo que seu eixo central é o gerenciamento de projetos. As principais caracteristicas desse nivel so: processos integrados, apoio cultural, apoio ge- rencial e gerenciamento de projetos informal. As empresas que chegam a essé ponto'da caminhada sao poucas e para elas nao existe caminho de volta. Segundo o préprio Kerzner (2001) observa: “Diga-me o nome de uma empresa que optou por gerenciamento de projetos e se arrependeu.” A verificacao da maturidade de uma empresa em gerenciamento de projetos pode ser feita através de varios modelos existentes, atualmente, na literatura tedrica que trata do assunto. Em alguns casos, vale a pena saber se, com a adogao de praticas dé gerenciamento de projetos, as organizacdes tém, de fato, melho- rado seus resultados. Nesse’ ¢aminho, talvez 0. modelo mais recente, desenvolvido no sistema de voluntariado, tenha sido o Organizational Project Management Maturity’ Model (OPM3™), coordenado pelo PMI®. A ideia de criar um modelo de maturidade em gerenciamento de projetos que fosse padrao do PMI® ~ Project’ Management Institute —‘ocorreu em maio de 1998, com a constituicao de uma equipe de pro- jetos, visando discutir as principais capacitacdes inerentes a um gerenciamento de projetos organizacional. Esse conjunto de capacidades deve ser desenvolvido tendo-se como premissa o entendimento das estratégias de negécios da orga- nizacdo. ‘Trés grandes dimensdes foram consideradas em termos gerenciais: portf6lio, programas e projetos. Para essas dimensies foram propostos niveis, considerando-se padronizacao, medicées, controle e aprimoramento continuo. A partir desses elementos, define-se a maturidade organizacional em gerenciamento de Projetos, verificada através das capacidades e de resultados comprovados. Genericamente, a leitura de uma empresa em termos de sua capacidade em gerenciar projetos deve considerar suas competéncias em trés dimensies distin- tas: individuos, equipes de projetos ¢ organizacio. Do individuo que est envolvido em projetos, em linhas gerais, espera-se que ele domine técnicas e ferramentas em gerenciamento de projetos, dentro dos parametros amplamente divulgados, como restri¢des de recursos, prazos © custos, caracteristicos de projetos, levando em conta ainda as exigéncias de singularidade e empenho. Espera-se que esses individuos possuam uma visio bastante abrangente do sentido de governarem ou serem governados, mediante a necessidade de alinhamento de projetos as éstratégias organizacionais, bem como do desenvolvimento das habilidades gerenciais e da capacidade em aplicar técnicas e ferramentas de gerenciamento de projetos. Nesse aspecto, buscou-se identificar acdes que elever o grau de competéncia do individuo’em relacao as suas capacidades gerenciais, de conhecimento do negécio e de gerenciamento de projetos. Em suma, isso significa ter individuos competentes em projetos.* 16 Fundamentos em gestio de projetos * Carvalho ¢ Rabechini J. As equipes, no ambito dos projetos, devem ser proativas em buscar resulta- dos através de uma orienta¢do voltada para tarefas e atividades. Nesse aspecto, buscou-se planejar a¢des visando torné-las aptas ao desenvolvimento de com- prometimento com a agenda do projeto, bem como com orgamento, gest4o dos riscos, com a qualidade etc. Espera-se que, também, para que isso aconte¢a, haja um espirito de colaboracdo e comprometimento com os requisitos de gerencia- mento do projeto. Isso é, ter equipes competentes em projetos. A organizasio, por sua vez, no impeto de institucionalizar o gerenciamen- to de projetos como forma moderna de administracao de suas atividades nao rotineiras, deverd estar sensibilizada, disponibilizando recursos, adequando estratégias, divulgando resultados de projetos etc., isto é, ser uma organizacao competente em projetos. Resumidamente, uma empresa madura na conducio eficaz de seus projetos deve ter para as trés dimensdes mencionadas estratégias definidas de implemen- tacdo, desenho de processos para desenvolvimento de cada uma delas e controle e acompanhamento, visando garantir uma implementagao efetiva. Desse ponto em diante, existem apenas mais duas barreiras para se chegar A. exceléncia: a comparacdo com outras empresas e 0 aprimoramento continuo. No Brasil, ainda s4o poucas as empresas que chegaram a maturidade em gerenciamento de projetos. A implementacao de um novo conceito gerencial leva muito tempo e requer investimentos significativos. preciso muita dedicacao e determinagio, visto que os resultados nao aparecem imediatamente. No entanto, nos tiltimos quatro anos, tem-se assistido a uma corrida rumo A exceléncia em gerenciamento de projetos por alguns setores da economia, destacando-se Tec- nologia da Informago, telecomunicagées e servigos bancarios. Além destes, 0 setor que trata de Pesquisa e Desenvolvimento come¢a a dar sinais de interesse em gerenciamento de projetos, em virtude, em primeiro lugar, do hiato existente entre geracdo de inovacao tecnolégica versus esforco (custo, sobretudo) necessario e, em segundo lugar, da necessidade de gerenciar os diversos elementos em toda a fase de seu processo de inovacao. 1.3.1 Modelo Pré-Valor em Gerenciamento de Projetos © modelo estratégico de gerenciamento de projetos, modelo Pré-Valor®, foi criado para suprir as necessidades das empresas, no que tange ao atendimento dos quesitos. da segunda onda. Diferentemente de adicionar valor ao gerenciamento, 0 modelo é centra- do, essencialmente, nos resultados que os projetos poderao dar 4 organizacao. Gestdo dé Projetos: perspectivas e modelo de referéncia. ‘17 Adicionar valor, nesse contexto, inclui,’além‘da valorizacao do gerenciamento, também a maturidade dos envolvidos com o'projeto; as competéncias'relacio- nadas; a estrutura organizaciorial adequada.' Isto tudo alinhado externamente com 0 ambiente competitivo e internamente com as estratégias organizacionais. O modelo serve assim para ampliar a visdo nao sé dos gerentes de projetos, mas também dos estrategistas das organizacdes, na medida em que seus ele- mentos se integram. Em sua versio inicial denominada por Carvalho e Rabechini Jr. (2005, 2007, 2009) de Modelo Estratégico de Gerenciamento de Projetos MEGP® (Figura 1.5), era evidenciado o pano de fundo organizacional que condiciona o gerenciamento de projetos. tes be Estratégias da Organizagao Comunicagao Qualidade Ambiente Competitivo ‘ Fonte: Carvalho; Rabechini Jr. (2005). 3 Figura 1.5 MEGP® ~ Modelo Estratégico de Gerenciamento de Projetos. ° ’ youre, No entanto, o MEGP® nao evidencia a cadeia de valor em .gerenciamento de projetos, que é objeto do modelo Pré-Valor®. Também nao h4 nesse modelo uma preocupagao explicita com a questo da’sustentabilidade. (077 BSS" e * se a : shee" So A construc%o desse modelo vem no sentido de apoiar as empresas que op- taram por adotar o gerenciamento de projetds como forma de administrar seus empreendimentos, entendendo que a adocao de gerenciamento de projetos em 18 Fundamentos em gestéo de projetos, + Carvalho e Rabechini J. Ambito organizacional é decorrente de mudangas culturais profundas em varios niveis de competéncias, no uso das diversas técnicas e ferramentas gerenciais, considerando seus mais distintos aspectos (CARVALHO; RABECHINIJR., 2010). A implementagio de gerenciamento de projetos nas organizac6es, assim, deve enfatizar no sé questdes de ordem tatica, mas, essencialmente, estraté- gicas. Ou seja, as mudangas organizacionais implicam, certamente, alterar o fluxo de informacao e de tomada de decisdes, o modelo gerencial e as regras de poder interno. Decorrente disso tudo, sabe-se que as resisténcias s4o muitas e, portanto, precisam ser trabalhadas. Além disso, os gerentes de projetos ¢ os estrategistas ligados 4 implementa¢ao devem estar atentos, nao s6 a questées internas, mas também as quest6es exter- nas, pois é preciso monitorar o ambiente considerando os diversos interessados na mudanga gerencial, sobretudo os clientes, os concorrentes € os fornecedores e parceiros. As mudangas no enfoque estratégico com maior énfase no gerenciamento de projetos devem ser acompanhadas por uma adequada estrutura organizacional que atenda a flexibilidade necesséria 4 atividade de projetos, mas também reflita seu poder de tomada de decisao ao longo da estrutura. Questées relacionadas A carreira do gerente de projetos também apresentam criticas nesse contexto. ‘Além disso, 0 modelo se preocupa, também, em elucidar as questdes das competéncias necessérias, configurando uma trajet6ria de crescimento e apren- dizado que resulte na maturidade da organizacao. As competéncias devem assim ter um crescimento consistente e também coerente, levando-se em conta os aspectos das equipes de projetos e areas orga- nizacionais envolvidas. Esses aspectos constituem as preocupacées, em relacao ao preparo da organizacio, para adocdo da op¢ao gerenciamento de projetos, como alternativa de administracdo de empreendimentos, promovendo a mudanga cultural necesséria. Nesse aspecto, vale a pena ressaltar que, em geral, quando as organiza¢Oes precisam dominar as competéncias organizacionais, tendem a querer abrangé-las todas, ao mesmo tempo. As pautas que orientam o modelo, entretanto, deixam claro que o processo de maturacdo é lento, requer aprofundamento no dominio de cada area, sendo, portanto, gradual. Para compreender melhor o conceito de cadeia de valor em projetos, o siste- ma terrestre, em principio, pode servir de base para se tracar um paralelo, para efeitos de analogismo, com o modelo MEGP®, conforme ilustra a Figura 1.6. Gestdo de Projetos: perspectivas e modelo de referéncia 19 + Estratégia| * Estrutura + Maturidade * Praticas em jerenciamento’ Ths: le projets Cadeia de valor uate Figura 1.6 Analogia do modelo Pré-Valor com 0 modelo MEGP®. phe Ambos os sistemas sdo compostos por camadas. A terra possui, em linhas gerais, um nticleo, manto ¢ crosta. A parte central do modelo MEGP® ¢ a camada nucleo. As atividades-meio da cadeia de valor encontram-se no niicleo, sinteti- zadas pelas boas praticas de gerenciamento de projetos, que transferem energia para as demais camadas, aqui descritas nas 4reas de conhecimento do PMBoK acrescidas de sustentabilidade, mas de fato as possibilidades sao diversas, como abordaremos no Capitulo 3. Conforme discutida na primeira onda, a eficiéncia no gerenciamento dos projetos é obtida através do uso sistematico das boas praticas de gerenciamento, que envolvem as dreas de conhecimentos, os grupos de proces- so e o disciplinado monitoramento do ciclo de vida. As empresas, recentemente, tém adotado essas praticas, que sao propagadas pelos guias de gerenciamento de projetos, dentre os quais destaca-se, pela sua difusao, o PMBoK® do Project Management Institute (PMI, 2008). O manto, a camada intermediaria, no Modelo Pré-Valor®, conforme discuti- do, é 0 processo de mudanga em ambito organizacional, que envolve estrutura, competéncia e maturidade em gerenciamento de projetos. E preciso estabelecer um plano de exceléncia em Gestdo de Projetos e gerir a mudanca em busca de maturidade e construir competéncias no 4mbito das equipes, gerentes e da or- ganizacao, suportadas por um bom plano de carreira para retenco dos talentos nessa drea. A crosta, ultima camada, representa a estratégia organizacional, que, assim como na Terra, sofre as pressdes externas da atmosfera, no modelo representado pelo ambiente competitivo. E a camada da eficdcia, em que se enttega o pacote de valor para o mercado. E aqui também que temos a dimensio estratégica da sustentabilidade e seu impacto no meio externo, nas perspectivas social, am- biental e econémica. Nos capitulos seguintes deste livro serao detalhadas as bases conceituais do modelo ora descrito, no que concerne as camadas organizacionais, ou seja, 0 manto e a crosta — viséo da segunda onda. Questées para reflex4o e discussao 1. Quais sao os principais marcos evolutivos da 4rea de Gerenciamento de Projetos? O que caracteriza a primeira onda de Gestdo de Projetos? © que caracteriza a segunda onda de Gestdo de Projetos? Explique as camadas do Modelo Pr6-Valor®. Qual é a relagéo do MEGP com 0 Modelo Pré-Valor®? A que camada ele se refere? vr Y Dn O que é projeto? . Neste capitulo, apresentamos o conceito de projeto, suas caracteristicas, bem:como as peculiaridades de seu gerenciamento. Apés este capitulo, ° leitor estara apto a responder as seguintes questées: - leoviiy a) 0 que é projeto? - 4b), O que & Gestao de Projetos? -C)_Quais sao as principais caracteristicas de projetos? ; " d).;,Como definir sucesso em gerenciamento de projetos? ; 2.1 Conceitos: projeto e Gestdo de Projetos we O conceito de projeto tem sido aprimorado nos tiltimos anos, visando ésta- belecer um entendimento comum nas organizacées que trabalham com esse tipo de empreendimento (RABECHINI JR.; CARVALHO, 1999). Existem varias definigdes de projeto disponiveis na literatura. Dentre elas, as mais utilizadas estao na Figura 2.1. “Um ‘projeto é uma organizacao de pessoas dedicadas que visam atingir um propésito e objetivo especifico. Projetos geralmente envolvem gastos, acées ou empreendimentos tini- cos de altos riscos e devem ser completados numa certa data por um montante de dinheiro, dentro de alguma expectativa de desempenho. No minimo, todos os projetos nécessitam ter seus objetivos bem definidds e recursos suficientes para poderem desenvolver as tarefas requeridas”, (TUMAN, 1983)... ; a piomi9Te7 eq “Um processo tinico, que consiste em um grupo de atividades coordenadas e controladas. com datas para inicio e término, empreendido para alcance de um objetivo coriforme requisitos especificos; incluindo limitagdes de tempo, custo e recursos” (ISO 10006, 1997)/;.4 5; “Um empreendimento oe feito para criar um produto, servico, ou resultado>| nico” (PMI, 2008). ve asde nor Figura 2.1 Definigdes de projeto:ier 22. Fundamentos em gestio de projetos + Carvalho ¢ Rabechini Je. Podemos perceber dois conceitos intrinsecos nessas definicdes: um referente A temporalidade, ou seja, todo projeto tem um comeco e um fim bem determina- dos, e outro que se refere a unicidade ou singularidade, ou seja, que o produto e/ou servico do projeto é, de algum modo, diferente de todos os similares feitos anteriormente. Lembramos, porém, que temporalidade nao significa curta dura¢ao, pois projetos podem durar de semanas a anos. Destacamos ainda que, embora 0 pro- jeto acabe, seu produto e resultados podem perdurar por um longo perfodo de tempo. Por exemplo, o projeto de construgo da usina de Itaipu foi realizado na década de 1980, mas a usina continua a gerar eletricidade até hoje. Agora que sabemos o que é projeto, o que é Gestdo de Projetos? O gerenciamento de projetos inclui planejamento, organizaco, supervisao e controle de todos os aspectos do projeto, em um processo continuo, para alcangar seus objetivos, conforme defini¢ao da norma ISO 10006. O PMI (2001), por outro lado, enfatiza a aplicagaéo de conhecimento, habilidades, ferramentas e técnicas como aspectos fundamentais para a Gestao de Projetos, tendo como objetivo atender ou superar as necessidades e expectativas dos interessados (stakeholders). Quando um grupo de projetos relacionados é gerenciado de forma coorde- nada, o denominamos de programa. Os programas também envolvem uma série de atribuic6es repetitivas ou ciclicas (PMI, 2008). Os conceitos, ferramentas e técnicas da Gestdo de Projetos visam garantir © seu sucesso, através de boas prticas de gest4o, como veremos no Capitulo 3. 2.2 Caracteristicas dos projetos Embora as definiges de projetos sempre envolvam a questao da temporali- dade e da singularidade, as intensidades com que essas caracteristicas aparecem sao bastante dispares de projeto para projeto. Uma festa de casamento e a cons- truco de uma usina podem ser caracterizadas como projetos, mas sera que eles demandam o mesmo aparato gerencial? Veremos neste capitulo que diferentes tipos de projetos demandam road maps gerenciais diferentes, mas como classificar os projetos em tipos mais ho- mogéneos? Para tal, existem diversas tipologias que podemos utilizar para classificar os projetos, como veremos ao longo deste capitulo. Elas devem ‘servir como inspi- ragdo para a organizagao construir sua propria classificacdo de projetos, optando pelas dimensGes mais significativas em seu ambiente de negécios. Ogiieé projets? 23 2.2.1 “Incerteza e complexidade *.* Ampliando nosso entendimento de projetos, vamos trabalhar 0 conceito de singularidade em projetos, que é uma das suas caracteristicas mais marcantes. Todo projeto é de alguma forma Unico, ou seja, nunca foi feito, é uma inovacao. No entanto, o grau de novidade no projeto pode variar muito, levando a equipe de encontro 4 maior ou menor incerteza. Em linhas gerais, os projetos podem trazer inovacGes radicais e incrementais. As inovacées radicais séo aquelas que provocam grandes mudangas, enquanto as inovag6es incrementais promovem o processo de mudanca continuamente, incorporando pequenas alteracdes (SCHUMPETER, 1934). Existem diversos parametros que permitem avaliar a complexidade e a incerteza em projetos. Para Crawford et al. (2004), por exemplo, os atributos utilizadés para caracterizar a complexidade sao: escopo do projeto; ntimero de sites, localidades ou paises; numero de fungées ou habilidades; envolvimento organizacional; clareza de metas e objetivos; nivel de ambiguidade ou incerteza; fontes de risco; complexidade técnica; projeto individual ou componente de um projeto maior; familiaridade; e impacto organizacional. Jé outros autores focam na complexidade do produto do projeto, observando o numero de componentes, a dificuldade tecnoldgica, mimero de interfaces e interdependéncias (CLARK; FUJIMOTO, 1991; RAZ et al., 2002; BLOMQUIST, 2004; SHENHAR; DVIR, 1996, 2004, 2007). Por sua vez, Lewis (2000) propoe a classifica¢ao dos projetos em quatro ti- pos, baseados na complexidade do ambiente técnico e de negécio. A Figura 2.2 mostra os quatro tipos de Lewis (2000). ee | Muito : 7 complexo es Desafiador tecnicamente, ambiente de negécio oaz,. Ambiente | simples Técnico . ‘Ambiente técnico rotineiro, a simples ambiente de negécio jou rotina desafiador IV. iit} Simples Complexo Ambiente de Negécios Fonte: Lewis (2000). Figura 2.2 Matriz de avaliagao da complexidade do projeto. 24. Fundamentos em gestio de projetos + Carvalho e Rabechini je, Segundo Lewis (2000), a area da Figura 2.2 onde os ambientes de projetos e de negécios sao simples é denominada Tipo IV. Nesse tipo est4o os projetos de baixo valor para os negécios,da empresa e que usam tecnologia bem estabelecida. Os projetos do Tipo II sa0 aqiteles que usam novas ou complexas tecnolo- gias, mesmo estando num ambiente de negécios de pouco ou moderado valor para a empresa. JA os projetos Tipo III so aqueles que possuem complexidade técnica baixa ou moderada, mas estdo inseridos num ambiente de negécio de alto valor para a empresa. Finalmente, os projetos Tipo I sao os que usam tecnologia complexa e tém um alto valor de negécio, ou seja, normalmente sao misses criticas para a empresa. Para diferentes tipos de projetos, existem diferentes tipos de gerentes de projetos capazes de lidar com diferentes niveis de complexidade. Essa capacidade esta ligada diretamente as competéncias do gerente de projetos, ou seja, essas competéncias influenciam na probabilidade de sucesso ou de fracasso dos projetos na medida em que a designacao de um gerente de projetos com capacidade para lidar com complexidade menor do que a do projeto que foi designado diminui consideravelmente as chances de sucesso do projeto. A incerteza e a complexidade sao dimensées frequentemente utilizadas em tipologias de projetos para caracterizar os projetos (CLELAND; KING, 1967; CLARK; FUJIMOTO, 1991, MAXIMIANO, 1997; SABBAG, 1999; RAZ et al., 2002; BLOMQUIST, 2004; SHENHAR; DVIR, 1996, 2004, 2007; VIDAL; MAR- LE, 2008). No cubo da incerteza proposto por Sabbag (1999), essas questées sao tra- tadas num composto por trés varidveis, quais sejam: complexidade, singularidade e rigor das metas (ver Figura 2.3). Esse modelo avalia e propde estratégias de gerenciamentos distintas, dependendo da area do cubo. Segundo Sabbag (1999): projetos diferentes resultam em cubos diferentes. Por exemplo, um projeto de constru- gdo de uma estrada ou uma construgdo tipica, normalmente, apresenta alta estreiteza em relagdo aos objetivos, mas baixa complexidade e unicidade. Por outro lado, um tipico projeto de Pesquisa e Desenvolvimento (P&D) ou de desenvolvimento de um novo software, ao contrdrio, podem se mostrar com alta unicidade e complexidade, mas envolvendo baixa estreiteza de objetivos. O queé projero? 25 > Singularidade Rigor das Metas Fonte: Sabbag (1999). Figura 2.3 Cubo da incerteza. Como projetos se caracterizam pela elaboragiio progressiva, de maneira geral 0 escopo descrito no inicio do projeto vai se tornando mais explicito e detalhado, conforme o projeto se desenvolve, gerando uma maior compreensao de seus ob- jetivos. Quanto maior a complexidade e incerteza do projeto, maior a dificuldade de gerar uma boa compreensao dos objetivos logo no proceso de inicializacao, deixando evidente o carater de elaboragdo progressiva dos projetos. Para Maximiano (1997), os projetos podem ser clasificados em quatro grandes categorias, segundo a incerteza e a complexidade, conforme ilustra a Figura 2.4. Quanto maior o grau de desconhecimento, maior a incerteza e maior © risco associado. Jé a complexidade pode ser avaliada através da multidiscipli- naridade necesséria para a execucao do projeto, da diversidade e do volume de informagGes a serem processadas, do mimero de organiza¢ées envolvidas, entre outros aspectos. Categoria 2 Categoria 4 j Projetos de Pesquisa e Grandes projetos de Pesquisa e 7 Desenvolvimento Desenvolvimento Incerteza | Categoria 1 Categoria 3 sper Pequenos projetos de engenharia| Organizacao de eventos — Organizagao de um evento especiais: visita do Papa, Jogos Olimpicos Complexidade Fonte: Adaptada de Maximiano (1997). Figura 2.4 Categorias de projeto. 26 Fundamentos em gestdo de projetos + Carvalho ¢ Rabechini J. Uma versao multidimensional dos modelos anteriores pode ser encontrada no modelo de diamante (Practical NCTP “Diamond” Model), proposto por Shenhar e Dvir (2004, 2007). Os autores também iniciaram com uma versao bidimen- sional — incerteza tecnolégica e complexidade do sistema (SHENHAR; DVIR, 1996) -, 4 semelhanga de Maximiano (1997), e evolufram para uma tipologia de quatro dimensées: novidade, complexidade, tecnologia e passo. As Figuras 2.5 e 2.6 apresentam 0 modeld e suas dimensées. TMenos dados de mercado -raso na definigto os requisitos Fonte: Shenhar e Dvir (2004, 2007). Figura 2.5 Modelo pratico do “diamante” (NCTP). Para cada dimensio existe um conjunto de elementos analisados, conforme ilustra a Figura 2.6. 2H as Oqueé projeto? 27 Novidade: quéo novo € 0 produto parao mercado: Sura + Derivativo: melhoria de um produto existente. + Plataforma: uma nova geracéo de uma linha existente do produto. * Inédito: um produto totalmente novo. “Complexidade: quao complexo é 0 produto: Conjunto: subsistema, desempenha uma fungao tnica. * Sistema: colegao de subsistemas, multi- plas fungdes.. , * Grupo: grande colegio de sistemas diver- sos com uma Unica misséo. Tecnologia: extensdo de nova tecnologia para a empresa utilizada pelo projeto: + Baixa: nenhuma nova tecnologia é utili- zada. + Média: alguma nova tecnologia. * Alta: toda ou a maioria nova, mas tecno- logias existentes. + Superalta: tecnologias nao existentes na iacao do projeto. Passo: urgéncia do projeto e disponibilidade | de planejamento do temp * Regular: atrasos nao + Répido/competitivo: prazo para o merca- do importante para os negécios. + Tempo-critico: prazo de concluséo é crucial para as janelas de oportunidade de sucesso. * Urgente: projeto em risco ~ solugdo ime- diata é necessaria. icos. Fonte: Shenhar et al. (2005). Figura 2.6 Dimensdes do Modelo pratico do “Diamante” (NCTP). Observa-se na Figura 2.6 que cada dimenso impacta o projeto de uma forma especifica, por exemplo, a dimensio novidade na confiabilidade das previsdes de mercado, pois quanto menos dados de mercado disponiveis, maior pode ser o atraso na defini¢ao dos requisitos do consumidor; por outro lado, a dimensao pas- so afeta a autonomia ea velocidade do planejamento (SHENHAR; DVIR, 2007). 2.2.2. Projetos e outros tipos de produgao Slack (1993) contextualiza o projeto em face aos diferentes tipos de produ- cdo. Nas organizacées, é possivel identificar um continuo que vai de um extremo “projetos” ao outro extremo “processos continuos”, conforme ilustra a Figura 2.7. 28 Fundamentos em gestio de projetos + Carvalho e Rabechini Jr VARIEDADE VOLUME YO we PROCESSO CONTIN ESCALA DE INTEGRAGAO = AUTOMAGAO INCREMENTO DE DA DA CAPACIDADE TECNOLOGIA TECNOLOGIA Fonte: Slack (1993). Figura 2.7. Tipologias de produgiio. Conforme ilustra a Figura 2.7, o projeto est4 no limite superior quando o volume é minimo (unico), a variedade 6 maxima (singular) e os incrementos de capacidade, integrac4o e automacao da tecnologia esto no limite inferior. Portanto, projetos e outros tipos de operaces diferem primariamente pelo fato de que os outros tipos apresentam repetitividade, embora em diferentes niveis, enquanto projetos s4o tempordrios e tinicos, conforme j4 comentamos. 2.2.3 Projetos e localizagéo Os projetos podem também ser analisados segundo sua localizacao, uma vez que projetos dispersos geograficamente apresentam caracteristicas gerenciais distintas, tais como dificuldades de comunicac4o e de compartilhamento de recursos entre diferentes frentes e localidades. Evaristo e Van Fenema (1999) discutem essa questo em uma tipologia de projetos que relaciona a composi¢io dos projetos em face do numero de locali- dades envolvidas, conforme ilustra a Figura 2.8. que projero? 29 UL Dis Projeto dnico.»i1 Programa (miltiplos projetos) Projeto tradicional Programa colocalizado Localizagao tinica Miltiplos projetos _] Programas colocalizados tradicionais. maltiplos OO | 68 0 Projeto distribuido Localizacées miittiplas Projetos maltiplos Projetos multiplos ldistribuidos: localizacdes|distribuidos: localizacées| 2 discretas ‘compartilhadas G8 | : T= roi Fonte: Adaptada de Evaristo e Van Fenema (1999). Figura 2.8 Tipologia de projetos. Nas'colunas est4 a composi¢ao dos projetos, que podem ser simples ou miiltiplos, com caracterfsticas de programa, como vimos anteriormente. Nas li- nhas apresenta-se o numero de locais em que o projeto est4 sendo desenvolvido, podendo ser localizacao tinica ou localizagdes miltiplas. A combinagao dessas dimensées gera sete tipos de projetos: projeto tradicional, projeto distribufdo, programa colocalizado, miltiplos projetos tradicionais, programas colocalizados miiltiplos, projetos multiplos distribuidos com localizagdes discretas e projetos miultiplos distribuidos com localizacdes compartilhadas (ver Figura 2.8). Up 2.2.4 Projetos hard e soft e gil Outro continuo que ajuda a entender as diferengas entre projetos est rela- cionado as caracteristicas hard e soft de um projeto. Em um extremo do continuo estdo os projetos hard, que representam projetos de grande porte, auténomos com objetivos e produtos finais bem definidos, enquanto no outro estdo os Projetos soft, que nao sdo predefinidos, mas abertos 4 negociacdo durante o seu ciclo de vida (CRAWFORD; POLLACK, 2004, ATKINSON; CRAWFORD; WARD, 2006, POLLACK, 2007). Para classificar os projetos nesse continuo entre hard e soft, os autores identificam sete dimensédes: clareza de meta/objetivo, tangibilidade de meta/objetivo, medidas de sucesso, permeabilidade do projeto, nuimero de 30. Fundamentos em gestio de projetos + Carvalho ¢ Rabechini J. Hi opsées de solusao, grau de participasao e expectativas dos stakeholders (ver Figura 2.9). , Para classificar os projetos, os autores sugerem uma escala de 0 até 100 para —— : ii cada uma das sete dimensées, sendo que 0 valor 0 indica caracteristica hard e o Objetivos 7 _ ir valor 100 indica caracteristica soft. predefinidos Medigbes ristica soft. quantitativas 3 a] ¥ i@ \ i Clareza do Objetivo L il . MotayObjetivos MetavObjetivos A Fi claramente definidos ambiguamente definidos [Sem necessidade| Enfase no de participagao controle ionisti | Tangibilidade do Objetivo aa istas i Artefato fisico oO 100 Conceito abstrato _ eet 5 ft | Medidas de Sucesso caste i eid ‘Somente medidas Somente medidas ee queries HOS ualtatvas projetos fe Filosofia realistas Enfase na Ak como expert e positivistas q Permeabilidade do Projeto P Go Ue Nao sujeito a 0 100 Altamente sujito a | influéncias externas ce ee? influéncias externas ian Niimero de Opgbes de Solugéo Refinamento de uma mr Exploragéo de muitas alternativas de solug3o Objetivos Medidas solugso Unica < 1 «ambiguos qualitativas iT Grau de Participagio Ho Participagao mais 0 100 Participacio mais liberal i i tgdeee anicoato See Rae temematerrrt isii¢ alto envolvimento dos | {| ‘dos stakeholders stakeholders Expectativas dos Stakeholders Enfase no i Valorizacao da técnica, 0 100 Valoriza 0 relacionamento, aprendizado in performance e eficiéncia 454023 (Rises cultura significado, Filosofias ‘gerenciada por controle ‘gerenciado por negociagso interpretativas Fonte: Crawford e Pollack (2004, p. 650). Figura 2.9 Continuo entre projetos hard e soft. Gerente de Projetos como pee aa et , . facilitador ‘As implicagSes gerenciais dessa tipologia podem ser vistas na Figura 2.10, que distingui as inter-relac6es dos atributos para projetos hard e soft (CRAWFORD; POLLACK, 2004). Necessidade de Participacao Fonte: Pollack (2007, p. 267). Figura 2.10~ Inter-relagdo entre os atributos dos paradigmas hard e soft. a eae en Pproposta no contexto de projetos de Tecnologia da Infor- ae }), conhecida como gestio dgil de projetos “Manifesto 4gil” (BECK et 001), traz semelhangas com a andlise hard e soft apresentada. O.“Manifesto , um dos marcos dessa abordagem, criticava a burocracia exagerada na con: «the 32. Fundamentos em gestio de projetos + Carvalho e Rabechini Jr. dugio dos projetos de software, tanto no que concerne adocumentacao como no planejamento e controle (BECK et al., 2001). Williams (2005) destaca que os métodos de gerenciamento de projetos ca- racterizados como 4gil (agile) ou enxutos (lean) tém se mostrado mais aderentes aos projetos que apresentam trés caracteristicas: estruturalmente complexos, incertos e com limitag6es rigidas de tempo. Além disso, observa-se nesse con- texto a presenca ativa do cliente ao longo do ciclo de vida do projeto (BOEHM; TURNER, 2005). Shenhar e Dvir (2007) tracam um paralelo entre a gestao Agil e tradicional de projetos, que traz grande similaridade com os parametros para classificar projetos hard e soft. Abordagem Tradicional Agil Metasdo Foo no tempo, custo e requisitos de Foco no negocio, atingir mul- projeto qualidade. tiplos critérios de sucesso. Planodo Conjunto de atividades a serem execu- _Ciclo/processo com 0 obj projeto tas conforme o planejamento com o de atender 4 meta esperada e objetivo de atender ao custo, prazo e resultado para 0 negécio. qualidade, Planejamento —Realizado uma vez no inicio do projeto. _Realizado no inicio e reavalia- do sempre que necessario. Abordagem _Rigida, com foco no plano inicial. Flexivel, adaptavel. gerencial Execugao _Previsivel, mensurdvel.. Imprevisivel, nao mensurdvel. Influéncia da Minima, a partir do kick-off do projeto.__ Impacto no projeto ao longo corganizacao da execugao. Controlede _Identificar os desvios a partir do plano _Identifica as mudancas e projeto inicial e corrigi-los para seguir conforme —_ajusta o plano. © planejado. ‘Aplicagéo de Aplicado genérica de forma similara__- Adaptaco do processo de- metodologia _ todos os projetos. pendendo do projeto. Estilode Um modelo atende a todos os tipos de Abordagem adaptativa, um gestao projetos. Unico modelo nao atende a Fonte: Shenhar e Dvir (2007, p. 11). Figura 2.10 Abordagem tradicional x dgil. Nesse contexto, os métodos tradicionais de gerenciamento tornam-se ina- todos os projetos. propriados e podem, eventualmente, conduzir o projeto ao fracasso. Cicmil et al. Oqueé projero? 33 (2006). também destacam que os projetos que apresentam essas caracteristicas tém sua execu¢ao atropelada pelos modelos tradicionais de gerenciamento de projetos..: 2.2.5. Tipologia I¢ Cada tipo de projeto demanda tratamento diferenciado no que concerne ao seu gerenciamento, suas habilidades, técnicas e ferramentas especificas. Em geral, a construcao de tipologias visa entender as peculiaridades de cada cate- goria de projeto, que implicam demandas de ferramentas, técnicas e processos gerenciais distintos. Carvalho e Rabechini Jr. (2010) e Rabechini Jr. e Carvalho (2009 e 2010b) apresentam um modelo contingencial de Gestao de Projetos ue sera apresentado no Capitulo 3, que se basei: i i i que ser opr ent iP q ia em uma tipologia de projetos | Com base no conceito de avaliac6es por grupos de varidveis ou clusters, quatro eixos orientadores e essenciais de projetos, no formato de I’s, foram definidos: integra¢ao, impacto, inovacdo e imediato (Figura 2.11). Oo eixo da integracao esta relacionado as necessidades de agregar dreas de uma organizacao, equipes multidisciplinares, elementos de diversas naturezas. Ocorre, tipicamente, em projetos cujas equipes esto dispersas ou multilocali- zadas, em que o nimero de participantes é alto, sendo necessario conect4-los constantemente. Os projetos de desenvolvimento de produtos, por exemplo, se enquadram nesse eixo em que dreas de naturezas distintas precisam conviver em torno de um projeto. __ Ocixo dos impactos se refere aos efeitos que os projetos geram no meio am- biente, nos interessados, no comportamento humano e na ética dos envolvidos. Os projetos de impacto sao aqueles de implementagao de gasodutos, construcio de hidrelétricas, rodovias, por exemplo. O cixo da inovacao se refere a projetos em que predominam as inexatidées tecnolégicas, de mercado e de informacées, auséncia de conviccées, dificulda- des tecnoldgicas e instabilidade. Significa ser diferente, exclusivo, novidade e criatividade em termos de abordagem. Os projetos de inovacdo constituem-se, por exemplo, na criagdo de um novo programa/sistema de Tecnologia da Infor- mac4o, langamento de novos produtos, entre outros. As restrigées/limitacdes do projeto referem-se ao eixo do imediato que envolve atengao as metas de prazos, custos e qualidade. Em geral, os projetos de entregas imediatas referem-se, por exemplo, aos eventos, como olimpiadas € eventos esportivos em geral, aqueles cujo prazo requer um extremo cuidado. Enquadram-se nesse eixo, também, os projetos de lancamento de produtos sa- Zonais, como a fabricacao de carros em determinado perfodo do ano. 34 Fundamentos em gesto de projetos + Carvalho e Rabechini J. A partir desses quatro clusters, os projetos sao classificados'de acordo com a intensidade que’esses I’s se manifestam no projeto. Cas6'o projeto apresente fraca intensidade em todas as varidveis que definem sua tipologia, ele serd clas- sificado como Pré-Valor®/Simples. Por outro lado, é possivel que um projeto apresente fraca intensidade em apenas um dos I's; nesse caso, 0 chamaremos de Pré-Valor®/Unico, e assim subsequentemente, 2 I’s intensos classificam-no como Pré-Valor®/Duplo, trés I’s intensos como Pré-Valor®/Triplo e, por fim, quando os 4 I’s insidem de forma intensa no projeto ele sera classificado como Pré-Valor®/Intenso, conforme ilustram as Figuras 2.11 a, b ec. O modelo com- pleto pode ser encontrado em Carvalho e Rabechini Jr. (2010) e no artigo de Rabechini Jr. e Carvalho (2009). [iiregiato Figura 2.11a Modelo I* Pré-Valor®/Unico. Oqueé projero? 35 [rg}acao i Figura 2:11b° Modelo I* Pré-Valor®/Duplo. i Modelo Pr6-Valor®/Triplo Modelo Pré-Valor®/Intenso Figura 2.11¢ Modelo I Pré-Valor®/Triplo e Pré-Valor®/Intenso. Fonte: Adaptada de Rabechini e Carvalho (2009 e 2010). Figura 2.11 Tipologia I* Pré-Valor®. 36 Fundamentos em gestfo de projetos + Carvalho ¢ Rabechini J 2.2.6 Impacto estratégico do projeto ‘Lev Os projetos também podem ser classificados segundo seu impacto estratégi- co, conforme sugerem diversos autores (KERZNER, 1992; PATAH; CARVALHO, 2009). ot 2 i Patah e Carvalho (2009) sugerem a classificacao em dois grupos: operacionais e estratégicos. Os projetos categorizados como operacionais impactam a eficién- cia, enquanto os estratégicos impactam a eficacia da organizacao. Também a OGC (2002) sugere uma classificacdo em trés niveis segundo o impacto estratégico: visiondrio, emergente e obrigatério. Tanto o visionario como o obrigatério tém prioridade. Enquanto no visionario existe uma orientacao top-down e foca em uma oportunidade estratégica, no obrigatério a organizacao tem um imperativo de conduzir 0 projeto, quer por forcas do mercado, quer pelo potencial negativo de nfo fazé-lo. Kerzner (1992) classifica os projetos em duas dimensdes ~ qualidade dos recursos e beneficio do projeto, que resultam em uma matriz, com nove qua- drantes, ilustrada na Figura 2.12. < Qualidade necessaria em matéria de recursos Alta Média Baixa z 2 3 2 = s| |e $| | = 8 3 & a & l Prioridade do projeto Média Baixa Fonte: Adaptada de Kerzner (1992). } Figura 2.12 Prioridade de projetos. & 0 queé projero? 37 Observa-se na Figura 2.12, que existem trés regides, com prioridades dis- tintas. Quanto maior a qualidade necessaria de recursos e maior o beneficio do projeto para 0 negocio, maior seu impacto estratégico e, portanto, maior sua prioridade. Nesse caso, Kerzner (1992) sugere um primoroso gerenciamento de projetos, fazendo uso de profissionais altamente treinados em ferramentas e técnicas, de preferéncia, certificadas. Outra matriz utilizada em geral na classificagao de projetos de Tecnologia da Informacdo (TI) a Cranfield Grid (WARD; GRIFFITHS, 1996). Essa classificacao é inspirada no Grid Estratégico de McFarlan (1984), que relaciona a TI a estra- tégia e 4 operacao do negécio, em quatro quadrantes: suporte, fabrica, transi¢io e estratégico. J4 na Cranfield Grid, as categorias de projetos de investimentos em TI sao: suporte, operacional, alto potencial e estratégico. 2.3 Sucesso em projetos Tradicionalmente, adota-se o triangulo de ferro (ver Figura 2.15). A avaliacéo de desempenho em projetos é um tema que gera muita controvérsia: O'sucesso em projetos depende muito do ponto de vista que se analisa. Diferentes perspec- tivas e expectativas dos stakeholders quanto ao projeto vo remeter a avaliaces dispares, que precisam atender a um 6timo global, estabelecido por consenso. sucesso na perspectiva de um tinico stakeholder, ou seja, 0 dtimo local, pode gerar impacto negativo nos demais grupos de stakeholders. Definir o que é sucesso em projeto nao é tarefa facil, pois depende da perspec- tiva da parte interessada (stakeholder), do tipo de projeto, da perspectiva temporal (curto, médio e longo prazo) e da unidade de anilise (projeto e organizacao) (Carvalho, 2010). Dependendo dessas perspectivas, as dimensoes de sucesso so diferentes, como ilustra a Figura 2.13. vabbel Stakeholders Valor em Projetos ercéncs |) DBO) escsce cut peaco tomo pace Foconoprosto (fo?) Foo na cristo Foco no uso dos recursos Foco no impacto estratégico (fazer bem as coisas) (fazer as coisas certas) Fonte: Carvalho (2010). Figura 2.13 Sucesso em projetos. Para discutirmos sucesso vale estabelecer uma distinco didatica da rela¢ao entre sucesso do projeto, da gest4o do projeto e do produto do projeto, conforme sugerem alguns autores (COOKE-DAVIES, 2002; BARCLAY; OSEI-BRYSON, 2010) (ver Figura 2.14). © que é projeto? 39 Suicessc Sucesso e Sucesso do; 0 “produto. [+ ]*) _ Beneficios 1 | | organizacionais Desempenho do projeto Desempenho da organizacao 1 Fonte: Adaptada de Barclay; Osei-Bryson (2010). Figura 2.14 Constituintes do desempenho do projeto. A visio tradicional de sucesso em projetos tem o foco na eficiéncia, analisada apartir do triangulo de ferro (ver Figura 2.15), denominacdo da triplice restricao: escopo (também denominada desempenho técnico), prazo e custo. Dessa, for- ma, um projeto de sucesso é aquele que gerencia as restrices de escopo, prazo e custo, dentro do previsto (NAVARRE; SCHAAN, 1990; BELASSI; TUKEL, 1996; HATUSH; SKITMORE, 1997; ATKINSON, 1999; BELASSI; TUKEL, 1996; BRYDE; BROWN, 2004; CARVALHO; RABECHINIJR., 2005, 2007; PMI, 2008). Projetos acima do limite orcado, entregues em atraso e fora do escopo Custo Prazo Fonte: Carvalho e Rabechini Jr. (2005 e 2007). Figura 2.15 | Objetivos primérios de projetos. 40 Fundamentos em gestio de projetos * Carvalho e Rabechini J. Mesmo esse tipo de avaliacao do sucesso em projetos com foco limitado em eficiéncia sofre significativa resistencia pelos times de projetos. Em outros tipos de produc4o, como uma linha de montagem, costumamos ter padrées de desempenho bem conhecidos, tais como taxas médias de refugo e retrabalho, tempo de ciclo e tempo de preparaco (setup) entre tantos outros indicadores de desempenho disponiveis (CARVALHO; RABECHINI JR., 2005, 2007). E para projeto? Como fazer avalia¢do de desempenho de algo tinico? Argumenta-se que devido a incerteza e 4 complexidade inerentes aos projetos é dificil avaliar sua eficiéncia, pois as andlises sao feitas com base em estimativas tracadas em geral nas fases iniciais do projeto, por vezes com um erro expressivo em face das in- certezas e lacunas de informacao existentes (CARVALHO; LAURINDO, 2003). Imaginem agora a dificuldade de avaliar o sucesso dos projetos em uma perspectiva da eficacia! Em busca de uma visdo mais estratégica de sucesso, Pinto e Slevin (1987, 1988), propuseram que um projeto deve ser considerado um sucesso se atender a tripla restricdo, mas também focar na eficdcia e na satisfacao do cliente. Esses critérios foram distribuidos em um esquema circular, que sugere participagao homogénea de todos no sucesso, sendo a parte esquerda destinada 4 eficiéncia ea direita a eficdcia (ver Figura 2.16). Posteriormente, Pinto e Pinto (1991) também sugeriram a incluso de resultados psicoldégicos dos projetos, referentes 4 satisfacdo com as relacées interpessoais entre os membros das equipes. No entanto, os autores nao distinguem as diferentes perspectivas dos stakeholders, nem as diferentes caracteristicas dos projetos. Fonte: Adaptada de Pinto e Slevin (1988). Figura 2.16 Modelo de critério de sucesso em projeto. = so que t proto? 41 A perspectiva dos diferentes stakeholders no sucesso dos projetos.comec¢a a ser discutida de forma mais efetiva na década de 1990 (GRIFFIN; PAGE, 1996; SANVIDO et al., 1992; ATKINSON, 1999). 6 sanvido et al. (1992) e Griffin e Page (1996) alertam para a dificuldade de se medir sucesso em projetos devido a caracteristica de ser multifacetado, pois depende do ponto de vista do stakeholder, que pode variar de acordo com as ex- pectativas. Ja Atkinson (1999) propde quatro dimensées de avaliacdo do sucesso. O autor agrega a0 tradicional triangulo de ferro as dimensées de sistemas de infor- magio, beneficios para a organizacao e beneficio para os stakeholders. Essa ultima dimensao expande a “satisfacao do cliente” para “beneficios para os stakeholders”, incorporando a perspectiva de diversos grupos de stakeholders internos e exter- nos, tais como usuarios satisfeitos, impacto social e ambiental, desenvolvimento pessoal, aprendizado profissional, lucro do contratado, fornecedores capazes, equipe satisfeita, impacto econémico para a comunidade. A perspectiva temporal é introduzida de forma integrada as dimensGes ante- riores nos artigos e livros de pesquisadores israelenses (SHENHAR et al., 2005; SHENHAR; DVIR, 2007). Os autores integraram um conjunto de dimensGes para entender o sucesso de projetos e propdem indicadores, alguns ja consolida- dos, mas agregam alguns novos, quais sejam: eficiéncia, impacto para o cliente, impacto para,a equipe, negécio e sucesso imediato e preparacao para o futuro (ver Figura 2.17). Sucesso do : 5 Proieto Od eficiee tia Impacto para. ||. Impacto,paraj,||. : Negécio e,, ||. Preparacdo, a © dliente aequipe... || sucesso direto || para o futuro I I I I I * Cumprimento [+ Cumprimento ||+ Satisfagdo da ||+ Vendas + Tecnologia nova de cronograma,|| de requisitose || equipe + Lucros jercado novo * Cumprimento” "|| especificagées || + Moral da equipe||* Parcela de + Nova linha de do orcamento * ||* Beneficios para ||+ Desenvolvimento || mercado produto * Ganho ‘odiente das capacidades||+ ROI, ROE + Nova * Outras medidas ||+ Extenséo de uso || e habilidades || + Fluxo de caixa || competéncia de eficiéncia,:, ||+ Satisfacaoe ||» Crescimento dos||* Qualidade do |] _essencial || tealdade do membros da servico + Nova. BN) cliente equipe + Tempo de ciclo + Reconhecimento |] + Retencéo dos ||* Medidas da marca membros da organizacionais ae hc, equipe * Aprovagio we + Sem conftos || regulamentar [2 9 is. fie Fonte: Adaptada de Shenhar e Dvir (2007, p. 7). Figura 2.17 . Dimensées e indicadores de sucesso de projetos. if 42. Fundamentos em gestio de projetos + Carvalho e Rabechini Jr - al que proto? 43 bah re | oe pone ; ' a : a | As dimensées eficiéncia; impacto para o cliente € impacto para a equipe ja Algumas empresas, como a Petrobras, tratam essas questées sob o guarda-chuva haviam sido tratadas por outros autores, como visto, mas a perspectiva temporal, denominado satide, meio ambiente e seguranca (SMS). Também as questdes | que considera o impacto presente e futuro, é contribuicdo nova (ver Figura 2.18). sociais devem ser avaliadas, como o impacto na vida das comunidades afetadas li pelo projeto. Sao varios os exemplos, ‘como’ minhocao na cidade de Sao Paulo, as comunidades indfgenas afetadas pela hidrelétrica de Belo Monte, entre tantos Dimensées de sucesso outros. a - 4 Algumas dessas quest6es podem ser mensuradas a partir de indicadores como sucesso do nae 7 Sereaen, 7 séncia de processos legais e outros embates judiciais (POCOCK et. al., 1996). Preparacdo para o futuro projeto aau : $ I a » Outra critica 4 avaliacdo de sucesso em projetos refere-se a necessidade de considerar a perspectiva dos diferentes tipos de projetos, conforme estudado na Negécios e sucesso direto seco anterior. Varios autores sugerem que os parametros de sucesso e fracasso sdo distintos, dependendo do tipo de projeto (SHENHAR, 2001; SHENHAR; DVIR, 2007), ou seja, nao ha dimensées de sucesso que sejam universais para Impacto para a equipe todos os contextos. Dessa forma, temos de discutir muito as dimensées de su- cesso de um projeto na perspectiva singular e no contexto organizacional; nao Ww hé receita pronta, apenas dimensées-base para a discussio. en 14 Impacto para o cliente : lal 2.4 Caso: projeto Eurotunnel WB Eficiéncia o H i tree Para entender os aspectos conceituais de projetos, cabe ilustrar, através de hl Curto Médio Longo um caso, muito conhecido por profissionais que se interessam por projetos, | prazo prazo prazo que é 0 projeto Eurotunnel. O caso mostra alguns problemas, t{picos dos gran- ii ee des projetos, e com eles pretendem-se extrair ligdes para melhorar a geréncia r : de projetos. ‘i Figura 2.18 Perspectiva temporal das dimensGes de sucesso. Pro} i, Ss h ht Introdugao ao caso Quando finalmente o projeto Eurotunnel entrou em constru¢ao, muitos come- moraram, pois, apés décadas de concepgao técnica e politica, tudo o que era ficcio Lig A questo da sustentabilidade ainda é pouco tratada como um critério de sucesso em projetos. Como discutir sustentabilidade se ainda nao a considera- mos na anélise? if Um exemplo rico para essa discussao 0 projeto da hidrelétrica de Belo comegou a virar realidade. Mas poucos sabiam que durante as comemoragées do at Monte, que terd um impacto significativo - econémico, social e ambiental - para langamentd'de sua construgio o projeto estava mais de um ano atrasado, com or- \ | Lit © seu entorno, para a sociedade e para as geragGes futuras (ver Capitulo 13). samento batendo a casa dos US$ 15 bilhées, o que significava ser quase o dobro'do ‘| Carvalho e Rabechini Jr, (2010) alertam para a necessidade de se incorpora- Te eee : _ - } { rem novas dimensées na avaliacdo do sucesso de projetos. Um projeto elaborado : © Eurotunnel hoje liga a Franca com a Gra-Bretanha e foi considerado o projeto sem a perspectiva de sustentabilidade pode afetar a organizago e seu entorno lo século passado, tamanhos seus desafios, marco da engenharia e audacia do homem. a por décadas, com escolhas de alternativas energéticas a base de combustivel A ideia de ligar a Franca com a Gra-Bretanha é antiga. Em 1751, a Academia +a fossil em vez de fontes renovaveis, por exemplo. Além disso, aspectos ligados a Amiens,'na Franca, lan¢ou uma competi¢4o para descobrir quais a miélhores ma- i satide e seguranca da equipe e demais envolvidos no projeto sao outro critério neiras de atravessar 0 canal até a Inglaterra. Varias propostas surgiram, desde as hi relevante; seré que uma construcdo de usina em que a taxa de mortalidade ou de mais bizarras até algumas factiveis. Em 1974, ingleses ¢ frariceses dao inicio a uma qth acidentes de trabalho foi elevada pode ser considerada um projeto de sucesso? discussao, formal, sobre a construgao de um tinel. Em 1983 cinco banqueiros e 44 Fundamentos em gestio de projetos * Carvalho e Rabechin Je ter ge pret? 45 fornecedores franceses e éilco banqueiros e fornecedores inglésés propuseram um esquema para o tiinel. Em 1986, foi assinado um tratado entre os dois pafses, e contratada uma empre- sa para gerenciar e entregar o projeto, chamada Transmanche Link - TML, também proprietaria por 50 anos dessa concessao. Em 1990, o servico no tunel, para ambos os lados da via, estabeleceu-se. Em 1991, o téinel norte estava completo e em junho o tinel sul. Em 1993, o primeiro trem atravessa a via. Em dezembro de 1993, a TML entrega a construgdo e comega a operar a concessio. projeto Eurotunnel, desde o seu inicio, foi marcado por intimeros problemas que, se estudados sem paix6es, tornam-se um excelente meio de conhecimento para 0s gerentes de projetos de privatizagbes, projetos internacionais, identificagdo e ava- liagdo de claims (reclamag6es com direito a recebimento), andlise de interessados, entre outros. O Quadro 2.1 mostra algumas caracteristicas desse projeto. Quadro 2.1 Caracteristicas do Eurotunnel. Caracteristica Comentario Diametro de acesso Os dois acessos do trilho tém 7,6 m de diémetro interno. Area de servicos A drea para servicos no tunel tem 4,8 m de diametro interno. Passagens de equipamentos Os tineis estao a 38 Km de distancia, ligados por 150 passa- gens de 3,3 m de didmetro para cruzamento de equipamen- tos. Méaquinas perfuradoras | O projeto necessitou de 11 maquinas de brocar tuineis. Anéis Aestrutura do tunel é feita por anéis de concreto, fundidos no lugar, em ambos os lados da via. Engenharia utilizada ‘As curvaturas das passagens sao de 164 m de distancia, 21 m de extensdo e 15 m de altura. Os franceses usaram o mé- todo mini-mount baker para seu lado do tunel; os britanicos usaram um novo método de construcéo austriaco. Namero funciondrios | Aproximadamente 15.000 trabalhadores foram empregados no projeto. Escopo 0 projeto também incluiu terminais em cada lado da via e a ctiagdo do parque Shakespare Cliff no lado britanico. Custo ‘Aviagem dura 3 horas de Paris para Londres e 0 custo foi alterado de $ 325 para $ 465. Principais problemas do projeto: lig6es aprendidas Num projeto dessa natureza, como o Eurotunnel, muitos fatos nao previstos ocorrem e, quando analisados, podem-se extrair liges em termos de gerenciamento de projetos. geod Os problemas ocorridos e sira forma de solucao trazem para o pesquisador e estudante da drea de gerenciamento de projetos quest6es bastante interessantes que contribuem, definitivamente, para seu aprendizado. Nesse ‘specto, vale a pena examiriar os problemas enfrentados pelo gerente de projeto e, com eles, aprimorar os conceitos, aprender sobre as técnicas, entender as questées politicas e efetivamente fazer uso do aprendizado nos empreendimentos reais. ee Varios foram os problemas enfrentados pelo gerente de projeto do Eurotunnel. Tecnicamente, talvez o maior problema identificado tenha sido o de escavaco. Se- gundo relatos da época, a maquina utilizada para escavar o tinel, com um sofisticado controle computadorizado, foi projetada para trabalhar em solos macios, bem como sistema de'alinhamento do tunel. Num determinado momento do trajeto o solo encontrado;’mais duro, gerou infiltragdo de 4gua no sistema eletrénico. Dois pro- blemas surgiram, um no manuseio da maquina e outro no encaixe dos segmentos de concreto pré-moldados. Para resolver isso foi necessdrio injetar uma massa especial solidificadora, nao prevista no escopo do projeto. Outro pfdblema verificado foi a formacdo hierdrquica do projeto, que no final significaria definir o gerente de projeto- um francés ou um inglés? Desenhar a orga- nizacdo do projeto, bem como identificar os interessados, foi fundamental para evitar atritos e problemas de responsabilidades. Saber sobre os envolvidos e interessados nao foi uma tarefa simples, pois significava entender as necessidades dos banqueiros franceses ¢ ingleses, das empresas fornecedoras de maquinas e equipamentos, das empresas de engenharia, dos governos francés ¢ inglés, entre tantas outras. Das dificuldades de estabelecimento de responsabilidades e poder decorrem, por exemplo, as implicacdes técnicas que, no caso, foram distintas, ou seja, enquanto na parte ingles foram utilizados métodos de engenharia austriaca, na parte francesa foram adotadas as técnicas denominadas mini-mount baker, americanas. As implicag&es dos problemas técnicos em projetos, por ouitro lado, certamente geram problemas financeiros. No caso do Eurotunnel, o fato mais conhecido foi 0 da alocacao das mAquinas perfuradoras, que gerou o maior claim do século, segundo ironia de alguns analistas. O que ocorreu em relacdo aos claims foi que, segundo um consenso geral, o equipamento fixo do projeto deveria ter sido contratado por preco global e nZo 0 foi. Assim, conforme os prazos foram sendo vencidos, foi necessério solicitar pagamentos adicionais. O acréscimo do custo foi provocado pela grande interferéncia e desaceleragao do ritmo do projeto causado pelo Eurotunpel.-Tecni- camente, 0 contrato deveria ser feito no modelo turn key, ou seja, por preco fechado. O contrato, por fim, resultou no claim de US$ 2,25 bilhées contra o Eurotunnel pela organizacao contratante. visten Fouts Os aspectos polfticos foram os problemas, talvez, mais dificeis de serem tratados. Num projeto desta envergadura criam-se comités visando minimizar as interferéncias de varias entidades ambientais, de seguranca, satide, normas técnicas, entre outras.. Nesse aspecto, cabe lembrar da necessidade de adequarem as medidas, que nos dois 46 Fundamentos em gestio de projetos + Carvatho e Rabechini J paises so diferentes. As normas técnicas foram necessérias, para todas as engenha- rias envolvidas serem tratadas. Uma comissio (Intergovernmental Commission - IGC), formada por servidores civis da Franga e Inglaterra, foi criada para tratar dos assuntos sobre normas técnicas. Ela definiu que, onde houvesse diferencas entre as normas dos dois paises, a comissao decidiria o que iria prevalecer. Na teoria isso poderia ser uma grande ideia, mas os subcontratados nao conseguiam interpretar facilmente as diferengas relacionadas a inimeros itens, como por exemplo concentragao de graos em concretos, bitolas de ferros, usinagem do material de trilho e tubos, entre outros. Concluindo Considerando o porte deste projeto, conflitos e interferéncias externas seriam inevitaveis. A capacidade de resolver conflitos, portanto, é um dos aspectos mais interessantes a serem explorados pelo gerente de projetos que quer aprender com as ligdes deste caso. No entanto, cabe lembrar que, além das técnicas de resolu¢do de conflitos, as técnicas e ferramentas de gerenciamento de projetos foram criadas justamente para serem desenvolvidas e, assim, minimizarem os impactos adversos sobre o projeto. Os interessados em estudar gerenciamento de projetos, nesse sentido, devem explorar as metodologias de administragao de empreendimentos e integrar as técnicas e ferramentas visando ao sucesso. Com este caso pretendemos dar inicio a uma série de dicas e recomendacées para que os leitores possam extrair ligdes e aprender de forma ampla e profunda sobre gerenciamento de projetos. Como mensagem final podemos dizer que em projetos, alinhada com as técni- cas, a audécia do homem vem para permitir a melhora na condicao do bem-estar das pessoas, facilitando a vida do homem moderno, através de um projeto como este do Eurotunnel. Questées para reflexdo e discussio | 1. Defina projeto e Gestao de Projetos. Quais so os objetivos primarios da Gestdo de Projetos? O que tem impulsionado o crescimento da area de Gestao de Projetos no atual cenério competitivo? 4, Oque é sucesso em projeto? i Analise os projetos abaixo e classifique-os quanto a e complexidade: © preparagao de t dima festa de formatura; gue t projeta 47 10. IL. « preparacdo de uma viagem de pesquisa ambiental na Antartida; « desenvolvimento de um novo software para telefonia celular; « desenvolvimento de um novo modelo de automével. Classifique os projetos acima segundo suas caracterfsticas hard e soft. Explique as dimensdes do Modelo pratico do “Diamante” de Shenhar e Dvir (2007). Utilizando ‘a matriz volume e variedade, classifique os seguintes exemplos: + fabricacao de automéveis; * — fabricagdo de navios; + fabricac4o de utensilios domésticos em plastico; + desenvolvimento de software; + prestac4o de servico de consultoria; * produgao de aco. Estamos no ritmo de copa do mundo + Busque na Internet dados sobre o projeto do estdio que ser palco da abertura da copa do mundo de 2014. + Identifique os principais interessados (stakeholders). * Mostre a situa¢ao atual do projeto, respondendo a seguinte questao: ele pode ser considerado um sucesso? Ausina hidrelétrica de Itaipu foi construida na década de 1970 sob forte oposicao da populacdo, que a batizou de elefante branco. Além disto, 0 impacto ambiental causado pela usina foi alto, pois, quando as comportas foram fechadas e formou-se o reservatorio da usina, o Lago de Itaipu alagou uma drea de 1.350 km? em apenas 14 dias. * Utilizarido as diferentes classificagdes de projeto, como vocé enquadraria © projeto da usina de Itaipu? * Como satisfazer a todos os stakeholders de um projeto dessa magnitide? Escolha algum projeto importante desenvolvido na sua localidade, uma rodovia, uma linha de metré, um tunel etc. Pesquise na Internet o desem- penho dele e discuta 0 seu sucesso ou fracasso segundo as varias dimensdes estudadas. ond a d j - 3 Neste capitulo, apresentamos os fatores criticos de sucesso em projetos eos principais guias de conhecimento (Body of Knowledge - BoK) em Gest4o de Projetos. Além disso, serd detalhada a estrutura do guia PMBoK® (Project Management Body of Knowledge) do PMI (Project Management Institute). Apds este capitulo, o leitor estara apto a responder as seguintes questdes: i a) Quais sao os fatores criticos de sucesso? b) O que é gestdo contingencial de projetos? ©) Quais so os principais BoKs? d) Como esté estruturado 0 PMBoK®? Boas priticas de Gestko de Projetos 49 Gerenciar projetos é algo que fazemos cotidianamente em nossas vidas, embora nem sempre estejamos conscientes disso. E dificil encontrar alguém que nunca tenha estabelecido os projetos prioritarios de sua vida, tais como concluir um curso superior, casar, construir ou comprar um imével etc. Contudd, sabemos que nem todos conseguem levar a cabo seus projetos de vida. Todos esses projetos concorrem por seu tempo, dinheiro e sua energia para serem. concluidos. Em consequéncia, 4s vezes temos de priorizar alguns e abandonar ou postergar outros. ‘Também ja tivemos de conviver com o fracasso em projetos que priorizamos. Abandonamos 0 projeto de fazer uma universidade no terceiro ano por falta de recursos oui'de tempo para concilid-la com o trabalho, ou ainda desistimos de um casaménto por dificuldades de negociacao e conflitos com o(a) parceiro(a). Nas organizasées, nao é diferente, apenas tornamos esse processo menos intuitivo e mais estruturado. . 3.1 Fatores criticos de sucesso uso abrangente de projetos nas organizagSes estimula a busca pelos fatores que influenciam o sucesso de um projeto. Esse tema assume especial importancia na medida em que varios estudos apontam que as taxas de sucesso em projetos nGo s4o satisfatérias (MORRIS; HOUGH, 1987; PINTO; MANTEL, 1990). Dados de um levantamento em projetos de Tecnologia da Informac¢4o apontam para taxa de sucesso em torno de 30% (STANDISH GROUP, 2003). O concéito de fatores criticos de sucesso (FCSs) pode ser definido como: “um limitado numero de 4reas nas quais os resultados, se satisfatérios, iro assegurar urri desempenho competitivo de sucesso para a organizagao. Sao as poucas areas-chave em que as coisas devem dar certo para que o negocio flores¢a” (ROCKART'1979, p. 85). Segund6 ‘Fortune e White (2006), a busca por FCS em Gestao de Projetos comegou em torno da década de 1960 e, desde entio, varios autores tém publi- cado as suas listas de fatores criticos. Algumas dessas listas destinam-se a uma utilizagdo em dominios especificos, enquanto outras tém buscado 0-estabeleci- mento da derradeira lista, aplicdvel a todos os tipos de projetos. usiq * A primeira quest4o que chama a atengao consiste na discussio,sobre oque, realmente, corresponde ao sucesso de um projeto, conforme vimos no Capitulo 2, o que dificulta ainda mais a descoberta doé fatores gerenciais Que influenciam significativamente o sucesso. ay aeefiop et Boas priticas de Gestdo de Projetos 51 50 Fundamentos em gestio de projetos + Carvalho ¢ Rabechial J. Existe, também, a busca por modelos, na tentativa de se obter uma prescri¢ao de qual caminho seguir para se alcancar 0 sucesso, embora se reconhega que cada projeto é unico e, portanto, depende de suas contingéncias. Hyvari (2006) estudou os fatores criticos de sucesso e de falha na Gestao de Projetos ¢ os relacionou aos. fatores,¢ varidveis de fundo organizacional. Além disso, o estudo buscou compréender como clientes de projetos e outros interes- sados (stakeholders) apresentam suas necessidades e expectativas para assegurar ‘© sucesso em projetos. O autor identificou fatores criticos de sucesso na Gestao de Projetos que sao significativamente relacionados ao tamanho da organizacao, tamanho do projeto, tipo de organizacao e experiéncia de trabalho do gerente de projetos. Os resultados destacam a importancia da comunicacao em projetos, que esté relacionada ao tamanho da empresa. Em contraste com alguns estudos prévios, a comunicagao foi classificada como um dos mais importantes fatores na maioria das fases dos projetos (ver Capitulo 10). A importancia de aspectos relacionados as pessoas envolvidas no projeto também tem sido foco de crescente interesse, salientando-se fatores como a adequacao da personalidade do gerente e seu estilo de lideranca ao tipo de projeto (ver Capitulo 11). Dvir et al (2006) partiram da teoria da adequacao organizacao-individuo e levantaram a hipétese de que um projeto com um perfil particular precisa de um gerente com tra¢os de personalidade que se enquadrem de modo a alcancar 0 sucesso. Os resultados obtidos nas anilises estatisticas demonstraram correlagées entre tipos de projetos, personalidade dos gerentes e sucesso do projeto. Nessa mesma linha, outros trabalhos também enfatizani © estilo de lideranca dos gerentes de projetos e fatores relacionados a equipe, como tendo papel primordial no sucesso de projetos (TURNER; MULLER, 2005; PRABHAKAR, 2005). a Grabher (2002, p. 246) conclui que uma anilise “ecolégica” deve ser desen- volvida para explorar as interdependéncias entre projetos e organizaées, bem como relacionamentos pessoais, localidades e rede corporativa de trabalho onde © projeto é criado e em seu contorno. Fortune e White (2006), partindo de uma anilise de 63 publicagdes sobre FCSs, elaboraram uma lista, ordenada por numero de ocorréncias dos fatores criticos de sucesso, conforme segue: * apoio da geréncia sénior; + objetivos claros e realistas; + planejamento firme e detalhado mantido atualizado; * boa comunicacio e feedback; + envolvimento do cliente/usuario; + equipe qualificada/suficiente staff; e * -gestao da mudanga eficaz;...: * gerente de projetos competente; * boa base em projetos; * recursos suficientes e bem alocados; * boa lideranca; + tecnologia comprovada e familiar; * cronograma realista; + riscos identificados e gerenciados; * patrocinador de projeto; * controle/monitoramento eficaz; * orcamento adequado; * cultura organizacional; * bom desempenho de consultores externos; + planejamento para encerramento/reviséo; * provisdo para treinamen * estabilidade politica; * selecio adequada e experiéncia com metodologia e ferramentas de Gestao de Projetos; e * influéncias do ambiente. bs i No entanto, essas listas que alimentam varios guias de conhecimento em Gesto de Projetos (Body of Knowledge - BoKs) devem ser vistas como referéncia, e podem ou no se encaixar a um projeto especifico. 3.2 Gestao Contingencial de Projetos - Modelo I* , Dessa introducao, observa-se que cada tipo de projeto demanda tratamento diferenciado no que concerne ao seu gerenciamento, suas habilidades, técnicas, ferramentas e seus processos gerenciais distintos (ver Capitulo 2). __ Partimos entdo da premissa de que tipos diferentes de projetos terao va- riaveis gerenciais distintas a serem controladas (fatores criticos de sucesso), as quais terao impacto significativo no resultado final do projeto, sucesso ou fracasso. Para entender melhor esse relacionamento, a Figura 3.1 apresenta o Modelo Contingencial de Gesto de Projetos denominado I* (ver Capitulo 2): A Proposic4o do modelo é de que um tinico road map gerencial nao se encaixa em 52. Fundamentos em gestfo de projetos + Carvalho e Rabechini Jf. Lt Boas priticas de Gestio de Projetos 53 todos os contextos, portanto, é necessario construir road maps customizados as Quadro 3.1 Relacionamento entre dreas gerenciais e 0 Modelo I*. ‘, contingéncias dos projetos. Lew A esas Cluster iM Area de Gerenciamento z 7 : vacate |r Imediatas:; _|novagao"|-integrasao | Eitregas.. Abordagem contingencial de | Gestdo de Projetos A Escopo 1 [2 Recursos Huimanos Ng Road map de — Sucesso em 3 | Prazos ’ Gestdo de Projetos projetos | custos ; tt 5 | Aquisigges [ l6| Riscos. i.vi, — 7 | Comunicacao * Fonte: Adaptada de Rabechini e Carvalho (2009). 8 | Qualidade™ " Figura 3.1 Modelo I* de gestéio contingencial de projetos. 9 | Juridica , 10 | Etica iy Com base no conceito de avaliacées por grupos de variaveis ou cluster’s, quatro 11 | Marketing { eixos orientadores e essenciais de projetos, no formato de I’s, foram definidos: 12 | Responsabilidade Social integrac4o, impactos, inovacao e imediatas entregas (ver Capitulo 2). 13 | Meio Ambiente Para proposi¢ao de um sistema de gerenciamento de projetos contingencial, 14 | sadde além da proposicao de uma nova tipologia foi preciso ampliar a base de conheci- mento em gerenciamento de projetos comumente aceita no BoKs, embora a lista do Quadro 3.1 seja apenas sugestiva, podendo incorporar novas dreas de acordo 16 | Criatividade com 0 tipo e as necessidades especificas do projeto a ser gerenciado. 17 | Conectividade & Redes 18 | Gestéo Conhecimento fi : Legenda: 5 15 | Seguranca Baixa Intensidade Média Intensidade Alta Intensidade Fonte: Adaptada de Rabechini e Carvalho (2010). 3 A percepgao das necessidades dos projetos pode ser representada através da : intensidade dos indicadores (I’s) que, quando combinados, certamente sao mais a desafiadores do ponto de vista gerencial. . Um exemplo de projeto que precisa uti izar essa alternativa ‘gerencial combi- HSE Oe nando inovagao e integracao é a aeronave silenciosa— investigac4o em aeroactisti- 54 Fundamentos em gestio de projetos + Carvaliio.¢ Rabechini J. ca-, desenvolvido pela Embraer com financiamento da Fapesp (VASCONCELOS, 2009). Esse projeto ~ com duracdo de trés anos e investimentos de R$11 milhdes ~ tem como objetivo identificar fontes de ruidos aerodinamicos provocados pelas aeronaves, e quantificd-log. Para isso, o projeto ira instalar 256 microfones numa 4rea de 2.500 m? na cabeceira da pista de testes da Embraer ~ Gaviao Peixoto — com a fungio de captar o barulho gerado pelos avides que pousarao e decolarao intmeras vezes. Segundo Vasconcelos (2009), a necessidade de instalar tantos microfones se justifica, uma vez que os ruidos’propagados pelas aeronaves s4o muitos complexos. O aspecto da atengao a inovacdo nesse projeto foi evidenciado pela cons- tatagao do avanco teérico esperado sobre o assunto especifico e da criagao do ferramental para entender os fenémenos envolvidos na questo do ruido ae- rondutico. Como consequéncia disso terd como ganho a formagao de recursos humanos especializados na 4rea, uma vez que existem poucos profissionais com conhecimentos relevantes no pais sobre o assunto. © projeto aeronave silenciosa também se enquadra na tipologia da integra¢ao, em que é caracterizado pela interdisciplinaridade de conhecimentos envolvidos e pela agregacdo de varias entidades. Assim, o projeto sera integrado com seis entidades de ensino e pesquisa nacionais e quatro internacionais. Sao elas: * A Escola Politécnica da USP; * Escola de Engenharia Sao Carlos — USP; * Universidade Federal de Santa Catarina - UFSC; * Universidade de Brasilia - UnB; * Instituto Tecnoldégico de Aeronautica — ITA; * Universidade Federal de Uberlandia - UFU; * Universidade de Twente, da Holanda; + Imperial College, da Inglaterra; * Universidade de Southampton, da Inglaterra; ' * Centro Aeroespacial Germanico da Alemanha. Nesses casos, exige-se aten¢do as seguintes geréncias: * Escopo: visando maximizar o entendimento daquilo que é para ser feito no projeto e todos os seus elementos, pelos diversos interessados no projeto, o gerenciamento de escopo é uma das dreas mais importantes para esse tipo de projeto. > * Comunica¢o: uma vez que ha varios interessados, é preciso estar sem- pre atento ao tratamento adequado para toda informacao do projeto."t Boas priticas de Gestio de Projetos 55 + Recursos humanos: por motivos semelhantes a gest4o anterior,’as pessoas envolvidas nos projetos dessa natureza precisam estar bem . 4nformadas e adequadamente contribuindo com as suas necessidades. * ‘Integracao: os projetos complexos sao suscetiveis a falta de alinhamento " entre as partes. A gesto da integracao, nesse sentido, vem nao s6 para ; dar homogeneidade As Areas de gest4o, como também aos distintos + setores nos quais esta envolvido o projeto. * “Aquisig&es: essa geréncia é de extrema importancia, principalmente nos projetos de montagem de sistemas em que os varios bens e servicos . : precisam estar adequadamente integrados nas areas de desenvolvimento do projeto. + SMS: nos projetos complexos executados fora do Ambito interno da * émpresa, essa drea se faz cada vez mais importante. Nas montagens “ude sistemas de plataforma de petréleo, por exemplo, o cuidado com satide dos envolvidos serve para evitar exposico a gases e Iiquidos que . comprometem o bem-estar das equipes de projetos. Nesse sentido, os . ..cuidados com relagio ao meio ambiente tém sido também bastante Tigorosos, tendo em vista a existéncia de casos de fracassos ocorridos ianteriormente. 3.3 Introdu¢ao aos Guias de Conhecimento (BoKs) em Gestao de Projetos » Conforme vimos no Capitulo 1, a evolugdo da Gestdo de Projetos pode ser entendida como duas ondas. Enquanto a primeira onda focou na Gestao de Pro- jetos em si, a segunda onda focou em questdes de cunho mais organizacional. Dessa forma, foi durante a primeira onda, que ocorreu na década de 1990, que se buscou estruturar o gerenciamento de projetos, com foco nas boas praticas de gestao. Nesse periodo, proliferaram os guias de conhecimento (Body of Know- ledge — BoKs), em geral propostos por institutos ou associagdes de profissionais ligados a 4rea de Gestao de Projetos. Esses BoKs sintetizam a visio de determinada comunidade sobre as boas Praticas de Gestao de Projetos. Em geral, sdo estruturados em 4reas de conheci- mento e processos, mas também ha aqueles que se orientam por competéncias. Desses guias, 0 mais difundido é o Project Management Body of Knowledge (PM- BoK), proposto pelo Project Management Institute (PMI), que, embora seja também conhecido como abordagem americana, est4 presente em mais de 100 paises e € 0 mais difundido no Brasil - o detalharemos na préxima se¢do. Associada a esse guia, temos uma certifica¢ao profissional de sucesso conhetida como Pro- Ject Management Professional (PMP), em que uma das avaliagées é uma prova de ite 56. Fundamentos em gestio de projetos + Carvalho e Rabechini Jt Boas priticas de Gestdo de Projetos 57 “@ conhecimentos cujo.contetido é basicamente 0 PMBoK. Por isso, optamos por utiliz4-lo ao longo deste livro. . No entanto, ha varios outros guias que trazem visGes interessantes e por ve- zes complementares da drea. Para dar uma viséo mais abrangente, neste capitulo apresentaremos uma visdo geral dos BoKs. ‘Além do PMBoK®, cujo foco é a Gestao de Projetos, o PMI tem também modelos de referéncia para gestao de competéncias do gerente de projetos, ges- t4o da maturidade organizacional e gestao de programas e portfolio, conforme abordaremos nos Capitulos 15 e 16. Outro guia bastante difundido, mas com estruturacées distintas, € o IPMA Competence Baseline (ICB) elaborado pela International Project Management Asso- ciation (IPMA), também conhecido como a abordagem europeia de Gestao de Projetos, dado que funde as visdes do Reino Unido, Suica. Alemanha e Franca. Esse guia esta ja em sua 3* edicdo (IPMA, 2006), e traz uma visdo com foco nas competéncias, como o préprio nome sugere. © contetido do ICB é dividido em trés grandes grupos de competéncias (IPMA, 2006): contextuais, comportamentais e técnicas. As competéncias contex- tuais apresentam conceitos relacionados a dimensao organizacional da Gesto de Projetos, contemplando temas como 0 alinhamento estratégico do portfdlio de projetos. Jé as competéncias comportamentais tratam das habilidades do gerente de projetos, que serao mais detalhadas no Capitulo 16. 0 terceiro bloco de com- peténcias refere-se aos conhecimentos de elementos-chave para a boa gestao de projetos em uma perspectiva técnica, conforme ilustra o Quadro 3.2. Sao ao todo 42 elementos, dos quais 28 sao considerados elementos-base e 14 elementos adicionais (na 2 versao eram 9 elementos). Quadro 3.2 ICB: conhecimentos & experiéncia. » Elementos-base Elementos Adicionais rojetos e Gerenciamento de Projetos mplementago do Gerenciamento de Projetos jerenciamento por Projetos 8.4; Abordagem Sistémica e Integracao. 5: Contexto do Projeto B.6: Fases e Ciclo de Vida do Projeto B.7: Desenvolvimento e Avaliacao do Projeto B.8: Objetivos e Estratégias do Projeto B.9: Critério de Sucesso e Fracasso em Projeto 8.10: Iniciagao do Projeto B.11; Encerramento do Projeto B.12: Estrutura Analitica dé Projeto (WBS) : Contetido e Escopo Planejamento do Tempo: 2 RECUTSOS Custo e Financiamento do Projeto Configuracao e Modificagées Riscos do Projeto Medida do Desempenho : Controle do Projeto : Informacéo, Documentagao e Reporting : Organizagao do Projeto Trabalho em Equipe : Lideranca ‘Comunicagéo : Conflitos e Crises Aquisic6es e Contratos Qualidade do Projeto }: Informatica em Projetos ): Normas e Regulamentacées : Resolugdo de Problemas Negociacao e Reunides Organizacées Permanentes Processos Organizacionais Desenvolvimento de Pessoal : Aprendizagem Organizacional : Gerenciamento de Mudancas : Marketing e Gerenciamento de Produtos : Gerenciamento de Sistemas : Seguranca, Satide e Meio Ambiente Aspectos Legais, inangas e Contal lidade Fonte: IPMA (2006). a Outro guia de referéncia que traz uma estrutura diferente, mais enxuta, que basicamente trata dos processos e saidas gerenciais, é o PRINCE 2 — Projects in Controlled Environments — Office of Government Commerce (OGC). Trata-se de um BoK com recorte setorial, pois foi desenhado para projetos de Tecnologia da Informaco (TI), mas pode ser {itil também em outros contextos. ee hmy O PRINCE 2 deriva de um modelo corporativo criado em 1975 pela Simpact Systems conhecido como PROMPT, que foi adotado pela Agéncia de Computa¢ao 58. Fundamentos em gestio de projetos + Carvalho ¢ Rabechini J. e Telecomunicacgdes do Reino Unido (Central Computer and Telecommunications Agency - CCTA), como padrao de gest4o para projetos governamentais. Poste- riormente, o Office of Government Commerce (OGC) publicou o PRINCE, em 1989, e tornou a metodologia de dominio publico. A verséo PRINCE 2 foi publicada em 1996, conforme ilustra a Figura 3.2. eB) Start up do Projeto & Inicializagao do Projeto & Controle do Projeto 2 g £ 3 é 8 z Gerenciamento do g Produto 8 & = Gerenciamento da fronteira entre estégios & Encerramento do Projeto (= tecnicas Componentes (J Processos Fonte: OGC (1996). Figura 3.2 PRINCE 2. E nitida a orientacdo por processos do PRINCE 2. Embora haja similaridade em alguns grupos de processos descritos no PMBoK®, aqui existe distingao entre o planejamento focando 0 produto do projeto e também os controles a partir da direcao do projeto. O cuidado com as fronteiras gerenciais também é explicito. Essa introdugao aos guias, embora sintética, pois existem varios outros BoKs, tem como objetivo demionsirar a diversidade de metodologias, ferramentas e téc- nicas disponiveis para o bom gerenciamento do projeto e despertar a curiosidade do leitor para pesquisé-las. 3 Boas pritias de Gestdo de Prjetos. 59 3.4 O guia PMBoK® wet O PMBoK®, que jd esta em sua 42 edicdo (PMI, 2008), é estruturado em dreas de conhecimento e grupos de processos gerenciais, conforme ilustra a Figura 3.3. Sio nove areas de conhecimento: gestao de escopo, gest4o de tempo, gestdo de custo, gest4o da qualidade, gest4o de recursos humanos, gestao da comunica¢io, gestao de risco, gestao de aquisi¢ao e gestao de integracdo. Essas dreas so vis- tas de forma matricial por cinco grupos de processos: iniciacao, planejamento, execu¢4o, monitoramento e controle e encerramento (PMI, 2008). Processos Figura 3.3. Articulagiio de processos e dreas de conhecimento no PMBOK®. E importante observar que matriz de relacionamento de reas e grupos de Processos apresenta algumas intersecc6es vaziqs, dado que apenas a gestdo da integracao tem todos os grupos de processos, conforme ilustra a Quadro 3.3. Além disso, cada area de conhecimento pode ter mais de um processo por grupo de processos; dessa forma, totalizam-se 42 processos gerenciais, com entradas, ferramentas e safdas detalhadas ao longo do guia. O grupo de processos de pla- nejamento é o.que contém mais processos, 20 ao todo, distribuidos em todas as Nove areas de conhecimento. {60 Fundamentos em gestio de projetos * Carvalho ¢ Rabechini Jt thy Boas priticas de Gestio de Projetos 61 Proj rt Quadro 3.3 Grupos de processos e dreas de conhecimento no PMBoK®.., . Esse BoK est fortemente inspirado nos modelos de qualidade e no conceito i { BITE Gye We processos de'gerenclamentde Bolts t do ciclo PDCA (plan-do-check-act cycle), que veremos melhor no Capitulo 8:‘No tl tee Areas de TS y ers entanto, como a natureza dos processos de Gerenciamento de Projetos é mais r: ‘comhecimento, complexa, por nao ser rotineira e ter restrigGes de temporalidade, foi necessério lh j aX | ‘ : ane e ; | b ‘ criar grupos de processos, considerando-se o inicio e o fim, conforme ilustra a Desenvolvero | Desenvolver plano | Orientar e Monitorare | Encerrar 0 projeto : s | | termo de abertura | de gerenciamento | gerenciar a controlar 0 ou fase Figura 3.4. K | ; | do projeto do projeto execusdo do - | trabalho do. ! z projeto projeto ar ae] Realizar o controle r } é 2 integrado de | 8 : = mudancas Gerenciamento do Coletar requisitos Verifier 6 escopo | ‘escopo do projeto Definir 0 escopo Controlar 0 ©. 1 ee 4 Criar a estrutura escopo | anaiitica do | ed projeto (EAP) | yon Gerenciamento do Definir as Controlaro io Nie ‘tempo no projeto atividades cronograma Es 1 : Sequenciar as h ‘ atividades 1 Estimar os, 02 lift recursos das atvidades, woe Wis Estimar as i { duracdes das . 9X9 2 atividades ft Desenvolver 0 : cronograma ‘ Gerencimento dos Estimar os custos Controlar os custos do projeto Determinar 0 custos corgamento nag Gerenciamento Planejar a Realizar a garantia | Realizar o controle : da qualidade do” ‘qualidade da qualidade da qualidade ¢ projeto By Gerencimento dos Desenvolvero | Mobilizara equipe : reo recursos hurnanos plano de recursos | do projeto Figura 3.4 Grupo de processos PMI (2008). do projeto humanos Deseavolver a % equipe do projeto 7 ih wk Gerenciara Bon 98bGne uipe do projeto . a | : ; eae ae lean Wanders Bettini Reportar Para melhor entender como sao constitufdos tais processos, sera necessdrio ha fas comunicagbes| a parts omunicagber | Informagtes desempenho apresentarias caracteristicas de cada grupo e como as areas de conhecimento fo pre interessadas cian as * i bes : ‘expectativas esto amarradas nesses grupos. | east: AGncd Seeaes M bo intressadas © processo de inicio de projetos caracteriza-se, fundamentalmente, pela Gerenciamento els LO ees aprovacao do projeto e da nomeasao de seu gerente. Os procedimentos descritos mt projet sh = Ro processo de inicio referem-se a area de conhecimento denominada integraao. ai tscos in Para aprova¢do do projeto é recomendavel que o berente de projetos e seu(s) ealizar a anslise i - men fl | qualitative de Patrocinador(es) elaborem um documento que, quando aprovado; possibilitaré if Realizar a andlise a alocacao de recursos organizacionais ao projeto. _ ‘ bet ibe ae: intitativa de ee ¢ o f Leste fo ad aa Uma vez aprovado o projeto, cabe ao gerente de projetos e sua equipe passar { Planejar respostas se preocupar com o processo de planejamento do projeto. —xx9201 iuicn! sup | Panel rrt—sCss Este processo é robusto e requer atenco em todas as areas de’conhecimento i Propostas pelo PMI (2004). Na verdade, o:planejamento vai servir para que se j | | ii Fonte: PMI (2008). evite a ocorréncia de alguma a¢io indesejada iaté o final do projeto. Se.as acdes 62. Fundamentos em gestio de projetos + Carvalho e Rabechini J St Boss pritcas de Gestio de Projets 63 | para evitar isso forem cortetas, provavelmente 0 projeto atingird o sucesso. Pla- Estes, em linhas gerais, so os elementos adotados na metodologia de geren- nejar significa pensar no futuro. * . ciamento de Projetos proposta pelo PMI (2004). Vale a pena comentar que exis- | © primeiro passo do planejamento de projetos é, segundo o PMI (2004), tem muitos projetos com necessidades que extrapolam as areas de conhecimento | elaborar o detalhamento do escopo do projeto declarado no processo de inicio. O apresentadas aqui, e outros, evidentemente, nao requerem tanta sofisticagao, detalhamento do projeto; quando realizado adequadamente, ira explicitar todas conforme ja comentamos nas se¢des anteriores. | as entregas desejadas e necessdrias no 4mbito do projeto. Oo ‘desenvolvimento dos préximos capitulos pode ser considerado um parado- | Para realizar as entregas, deve ser feita uma programacéo dos tempos pos- x0, pois se de um lado estaremos abordando cada area do conhecimento segundo siveis e, segundo essa programagao, da alocacao de recursos humanos e mate- orecorte feito pelo PMI (2008), de outro decidimos ficar 4 vontade e apresentar as. essencialidades de cada area em nossa visao, além de incorporarmos as discusses de sustentabilidade. Nesse aspecto, propomos uma visdo mais personalizada e que, acreditamos, ira complementar o conjunto de conhecimento apresentado. riais a serem consumidos pelo projeto. E durante o processo de planejamento, ainda, que sao calculados todos os custos e organizados de forma a deixar claras as safdas e os desembolsos previstos. | Com essas 4reas (escopo, prazos, recursos humanos e suprimentos) integradas Cabe lembrar que os autores, além de professores, dedicam e dedicaram | é possivel planejar a qualidade de cada entrega do projeto, bem como organizar grande parte de suas carreiras ao gerenciamento de projetos tecnolégicos, e suas } toda a comunicacao do projeto. contribuig6es serao mais bem aproveitadas quando nfo forem regidas por regras Para encerrar a abordagem desse proceso, faz-se necessério, ento, concen- rigidas. Sabe-se também que muitas publicacdes dessa natureza tém pecado, n trar-se na administracdo dos riscos do projeto. or 00e} ee oe apresentar de forma quase idéntica 0 que’o. guia do | } Feito o planejamento, faz-se necessdrio desenvolver os processos de execugao e controle. As caracteristicas do grupo de processos de execu¢o sao: . . 3.4.1 ConsideracGes sobre o cicl i ji + desenvolver as equipes de projetos; . eee i * realizar as licitagdes ou fazer chegar o material necessdrio ao projeto; Os conceitos de gerenciamento de projetos vistos até aqui foram abordados * assegurar a qualidade; e através de grupos de processos e de dreas de conhecimento. Mas naturalmente | i Ann S res rn f 7 Ff rojetos pode ém vi i i | + distribuir informagées necessérias aos diversos interessados identifi- projetos podem ser também vistos como fases de ciclo de vida. cados no processo de planejamento. __A Figura 3.5 mostra que em projetos existem trés momentos ou fases dis- tintas - inicial, intermediaria e final. Com essas atividades desenvolvidas é possivel realizar o processo de controle 2 de projetos. Fundamentalmente, nesse processo os relatérios de desempenho devem ser elaborados e analisados. E através deles que os interessados podem Entradas saber: Ideia, Recursos ys * seo que foi planejado até a data foi feito; Fases * o que nao foi feito; Gestao de | Charter Plano Accit * o que resta ser feito; e | | . a projetos rly a | * quais os desvios existentes. 1 . elas pris) 2 Saidas Especifcagbes Progresso Fechamento. 9,94.) © projeto, ao encerrar suas atividades, deve proceder aos passos para o seu ee a \ correto fechamento. Vale a pena designar um responsavel para tal atividade, Prodte va | | que inclui receber a avaliacdo e aceite do cliente, armazenar as informacdes dos Fonte: Adaptada de PMI (2004). chor 4 K) relatérios de desempenho e fazer a avalia¢ao interna/externa final do projeto. i : e . | elaté lesemp: te a 0 proj Figura 3.5 Ciclo de vida. 8 Como visto, para cada processo esto vinculadas areas de conhecimento que : Sean | precisam ser trabalhadas (ver Quadro 3.3). ‘ shoe Fara ise 9, q it il 64 Fundamentos em gestfo de projetos * Carvalho ¢ Rabechini J O conceito de ciclo de vida tem ajudado os gerentes a administrar de forma mais linear seus projetos. Através de suas fases, € possivel eritender as safdas esperadas. Os participantes, por sua vez, passam a obedecer aos requisitos de cada fase. O controle passa a ser encarado de forma mais profissional. Muitos projetos esto vinculados aos processos de’ producAo ou opera¢ao. Apés sua entrega final ocorre o desenvolvimento de operaco repetitiva ou con- tinuada. ea i Para poder entender melhor como sao configurados e integrados todos os elementos da Gest4o de Projetos, vamos adotar um caso que sera desenvolvido ao longo dos préximos capitulos. 3.5 Caso: construgdo da casa de Eduardo e Ménica “Quem um dia ird dizer Que existe razao Nas coisas feitas pelo coragtio? E quem ird dizer Que ndo existe razao?” Eduardo e Ménica Renato Russo Um dos usuérios mais intensos em gerenciamento de projetos é, sem divida, o setor da construcio civil. Por ser um setor cujo produto final é concreto, ou seja, de facil entendimento, visualizacao inclusive, decidimos propor um caso que serd referenciado em toda a segunda parte do livro. Trata-se da construcao da casa de um interessante casal, conhecido em todo 0 Brasil: o Eduardo e a Ménica. ...Eduardo e Ménica fizeram natagiio, fotografia, Teatro e artesanato e foram viajar. ‘A Ménica explicava pro Eduardo Coisas sobre o céu, a terra, a dgua e o ar: Ele aprendeu a beber, deixou o cabelo crescer E decidiu trabalhar; E ela se formou no mesmo més Em que ele passou no vestibular. E os dois comemoraram juntos E também brigaram juntos, muitas vezes depois. E todo mundo diz que ele completa ela e vice-versa, : Que nem feijao com arroz. : Construfram uma casa uns dois anos atrds, Mais ou menos quando os gémeos vieram — tly Boas priticas de Gestio de Projetos 65 Batalharam grana e seguraram legal A barra mais pesada que tiveram.., Eduardo e Ménica Renato Russo Eduardo e Ménica moravam num apartamento alugado de dois quartos, aper- tado, uma vaga na garagem. Ménica tinha moto, mas nAo tinha onde guardar. Um dos quartos funcionava como oficina onde os quadros, fotografias e esculturas de artesanato ocupavam todo o lugar. Eduardo e Monica, apés procurarem por muito tempo um apartamento, mu- daram de opiniao e decidiram, entao, construir uma casa, principalmente quando souberam da chegada dos gémeos. Batalharam grana e seguraram legal as econo- mias e recentemente adquiriram um terreno de 200 m? num bairro residencial. Agora vao se dedicar A construgao da casa de seus sonhos. Comecaram discutindo tudo aquilo que gostariam em uma casa, em fun¢ao de suas atividades. Estas caracteristicas estao descritas a seguir: ' * Mbnica, embora trabalhe fora, gosta de preparar pratos diferentes quan- do estd em casa. Sua especialidade é uma rica e gostosa comida baiana; ‘© Ménica, apaixonada por jardinagem, tem sempre em seus vasinhos pequenas plantacées de hortela, manjericdo, cravo, entre outras espe- ciarias. Seu sonho é ter espago para uma horta de verdade; * Eduardo estuda violao e, se possivel, ficaria horas em seu quarto estu- “~~ dando, mas Ménica, cA entre nds, nao aprecia muito o estilo de suas ot misicas; gue AA F ' a +"'Eduardo e Ménica se parecem no quesito guardar bugigangas. Nao jogam fora nada. Seus espacos vivem entulhados; + . Eduardo acha que os filhos, mesmo gémeos, devem ter quartos sepa- rados — nao sabemos ainda se sao do mesmo sexo; *,, Ménica aprecia pintura e Eduardo gosta de fazer consertos e recuperar méveis antigos. *,,M6nica, desde suas aulas de alemio, tinha viajado e,sentido a preocu- 9: Pagdo desse povo com as questdes ambientais e a legislaco mais rigida daquele pais. Agora que ia construir, queria uma casa sustentavel! 1 ay Estas caracteristicas servirao para que o casal possa dar 0 pontapé inicial no gerenciamento do projeto: Casa Eduardo e.Ménica. . LIM * Eduardo recentemente ingressou num’ MBA em administracd0 de projetos e convenceu a Ménica a organizar todas as decisdes e acdes do projeto. ‘Para isso, 66. Fundamentos em gestio de projetos * Carvalho ¢ Rabechini J querem fazer tudo como mandam as boas praticas da disciplina Gerenciamento de Projetos. Durante toda a Parte II e nos prximos capitulos do livro eles irdo aplicar as técnicas e ferramentas possiveis de gerenciamento de projetos. Desejamos a eles boa sorte! Questées para reflexdo e discussao ee eee 11. 12. 13. 14. Descreva as competéncias do ICB. Descreva os processos do PRINCE 2. O que é gestao contingencial de projetos? Quais as areas de conhecimento segundo o PMBoK®? Quais as principais entregas que vocé como gerente de projetos faz durante a fase de inicio de projeto? © que ocorre quando o planejamento de projetos nao é feito? Quais as im- plicagdes no projeto? Vocé concorda que a fase de controle de projetos vem apés a execucao? Durante o planejamento de projetos € necessario chegar a elaboracao de um plano coerente e consistente com as entregas esperadas do projeto. Quais so os elementos fundamentais desse plano? Onde ocorrem mais conflitos em projetos? Em que fase? . O conjunto de processos que se dedicam a configurar o encerramento de ptojetos enfatiza a possibilidade de aprender com as licSes proporcionadas pelo projeto. Comente e mostre como isto tem ocorrido em sua empresa € mesmo em suas experiéncias pessoais. Vocé se lembra de sua ultima viagem? Considerando-a um projeto, intui- tivamente, quais os passos que vocé seguiu em termos gerenciais? E quais poderia ter seguido? Vocé j4 pensou em planejar sua carreita? Quais os marcos relevantes e até onde acredita que vocé poder4 chegar? Quanto vocé gasta de tempo no transito? Com planejamento é possivel oti- mizar mais seu tempo. Faca um planejamento e veja como isso é possivel! Faca um estudo dirigido nos principais institutos e associagdes da area de gestao de projetos: + PMI-Project Management Institute. Sites: ; (Sao Paulo); (Rio); (Minas). ™| Boas priticas de Gestio de Projetos 67 IPMA ~ International Project Management Association (); no Brasil, veja Associacao Brasileira de Gerenciamento de Projetos (ABGP), site: . OGC - Office of Government Commerce — Projects in Controlled Environments (PRINCE 2). Site: . JPMF — Japan Project Management Forum (). oy — Australian International Project Management (). +. APM — Association for Project Management (). 4 Neste capitulo, sera tratada a questo do gerenciamento das integracdes dos projetos. Apés esta unidade, o leitor tera condicdes de responder as seguintes questGes: a) Quais os processos que suportam o gerenciamento da integracao do projeto? b) Quais as técnicas utilizadas para realizacao da integracdo? c) Como o gerente de projetos poderd fazer uso do gerenciamento da integracdo para melhorar o desempenho dos empreendimentos coordenados por ele? d) Qual o nivel de integracdo adequado em um projeto? e) Quais as integra¢ées relevantes de um projeto? f) Como realizar o encerramento de um projeto? Gestio da integragio do projeto 69 - Imagine uma orquestra tocando 0 Bolero de Ravel. A obra, embora composta de uta melodia simples, é contagiante. Para um leigo, 4 primeira vista, pode parecer facil de tocar. Individualmente, talvez. Mas uma apresentacao do Bolero de Ravel com orquestra tem de ser muito bem-preparada, ensaiada, para que todos os integrantes deem sua participac4o com contribuicao coletiva. S6 assim, com integracao dos misicos e entradas devidas de seus instrumentos e de forma coordenada é que aparecem os resultados. Certa vez, o maestro Zubhin Meta disse que seu grande desafio, numa obra como 0 Bolero de Ravel, era a integrac4o, ou seja, levar os musicos a atingir o 4pice da peca no momento exato. Qualquer deslize, antes ou depois, certamente acarretaria no fracasso do projeto. Sem integrac4o, essa obra, como todas as outras, nao atinge sucesso! Em pro- jetos, ocorre o mesmo, ou seja, os varios elementos devem estar uniformemente integrados para que possam ser coordenados. O gerenciamento de integracao compdé-se de processos requeridos para que seja possivel essa coordenaco. 4.1: Introdugao a Cada vez mais os gerentes de projetos tém dado importancia 4 drea de co- nhecimento de integracao. A integracao exerce papel essencial no gerenciamento de projetos na medida em que, inicialmente, cria as condic6es propicias para o desenvolvimento ade- quado de um projeto. Nesse aspecto, o processo de integra¢ao leva em conta os ingredientes existentes e ambiente onde o projeto seré realizado. E no processo de integra¢ao, que os gerentes lancam o projeto, estabelecendo seus objetivos, restrigdes, premissas, justificativas pelas quais 0 projeto foi criado etc. A integracao é relevante ao gerenciamento de projetos, também, como area que contém os elementos de coordenagao dos varios planos do projeto, que é feita através da andlise de interfaces entre as outras 4reas. Assim, por exemplo, quando uma atividade de projeto esta atrasada, sabe-se que os impactos em ou- tras areas (custo, evidentemente, recursos, muitas vezes, entre outras) precisam ser avaliados. E a drea de integracdo a responsavel por ter esses elementos que dardo subsfdios para a anélise dos impactos. A gestao da integracdo é responsavel, também, por fornecer elementos para o controle de alteracdes em projetos. Projetos, dada sua natureza, contém elemen- tos intrinsecos, como as mudangas que, por sua vez, precisam ser administradas. O processo de gestao das alteragdes, no ambito do projeto, é proposto pela area da integracdo. | Hf | \ | | | 70 Fundamentos em gestio de projetos * Carvalho ¢ Rabechint Jr. ‘thy - Gestio da integracio do projeto. 71 } aus 5 if A area de integracdo também.contém processos para encerramento de proje- Cultura . ; in| . i: ics izacd Zo final, conduco Sistema de Inforhacéo Declavagio de t tos: aprendizagem com as ligdes, organizacao da documentacao Ga ay Produte denecuses tumanes —_[ peanvelvere elragion a ‘ }¢@—ee_| i de reunides, entre outro: N Organizacionais Project Charter“ convato || Stakeholders id Os processos considerados pelo PMI (PROJECT MANAGEMENT INSTITU- = . fd | | TE, 2004) no gerenciamento da integra¢do do projeto sao: 1 Procedimentos & Diretrzes pate : 5 Processos i a) desenvolver o project charter (termo de abertura): desenvolve o project acne teranoadies” esas i | | charter (contrato do projeto, proposta de projetos, solicitacao de projetos | Organizacionais 7) scope, Lyk autorizada, termo de referéncia, entre outros termos utilizados no Bra- sano det * | sil), sendo que sua aprovacio autoriza, formalmente, um determinado | ' wes \ i : Prano de Prazo I projeto; 1 Pano de Custo { / p . i ot b) desenvolver o plano de gerenciamento do projeto: estabelece as agdes ! Piano de taf 1 | necessarias para definir, preparar, integrar e coordenar todos os planos ay Plano de Reco 1 que irdo subsidiar o plano de gerenciamento do projeto; | ee rs! . a + s ¢ 1 c) orientar e gerenciar a execugao do projeto: consiste em executar 0 traba- t ve a 7 ! ! i Iho definido no plano de gerenciamento do projeto para alcangar seus fo erwnbes | tt i objetivos; ie leplernds me i i i le mplerentadas | tf d) monitorar e controlar o trabalho do projeto: monitora e controla os ee ET | ! i ! i ; processos requeridos para iniciar, planejar, executar e encerrar 0 pro- yee Wome = |} tt Ih jeto visando atingir os objetivos de desempenho definidos no plano de I on raid Hl gerenciamento do projeto; ! eect Pets ei Hu | . eESIneee 1 e) realizar o controle integrado de mudangas: consiste em rever todas as_— | ! cca es ! i mudangas requeridas, aprovadas, bem como coordenar as alteragdes 20 1 Fequstos de Midangas Reads =| | | longo do projeto; ' fs ees ! \ | if 5 ‘ ‘ E Reparos dos defeitos H f) encerrar o projeto ou fase: consiste em organizar a documentagao de 1 rr de Po tna) ryt i : i __ Pano de Ecopo(atualizade) it f fechamento do projeto. Rakartconae ii i A an? ; ao — rae | | A Area de integracio é a que possui, como o préprio nome sugere, ligagdes | oe Beware 1! 4 com todas as areas da gestio do risco, conforme ilustra a Figura 4.1. 1 maces Oanaconis eves Aoonaos | 1 ne Delverobes | i ! Procedimento deFechamento_ | i : onganizaconats Gestéo : mode > de i. rechomente de Contos senige Resstndo | Itegragéo | Fonte: Adaptada de PMI (2008). : : Figura 4.1 Fluxo dos processos de gestio da integragao. ca pou 1 i Y i Gestdo da integragdo do projets’ 73 72. Fundamentos em gestio de projetos * Carvalho e Rabechini Jt = 4.2. O inicio: a formalizagao do projeto - project charter O inicio do projeto ocorre de diversas formas nas organizacoes e é perce- bido diferentemente pelos envolvidos e interessados (stakeholders). Poucas sao as empresas que tém processos qiie definem o inicio de um projeto e, por isto, € necessario que as pessoas ligadas ao gerenciamento de projetos estabelegam formalmente seu inicio. A formalizagao do infcio de um projeto pode ser feita através de um docu- mento chamado project charter. Algumas empresas usam outras denominagées, como: proposta de projeto, termo de referéncia de projeto, contrato do projeto, solicitagao de projeto autorizada etc. O project charter contém elementos para que sejam reconhecidas formalmente as necessidades de utilizacao de recursos, bem como as premissas e restric¢des para realizaco de um projeto. Nesse aspecto, o documento project charter deve ser desenhado para conter: titulo, objetivo, premissas, restrigdes, resultados esperados, escopo macro, or- ganizac4o dos interessados, principais riscos etc. O projeto da casa de Eduardo e Monica pode ser um bom exemplo para preenchimento de um project charter. O primeiro passo para preenchimento do project charter foi analisar as caracte- risticas das necessidades expressas pelo casal (veja seco 3.5). Uma vez discutidos esses requisitos, Eduardo pegou seu notebook, buscou um modelo de project charter apresentado em seu MBA e comecou a preenché-lo. Assim, quando a Ménica retor- nasse do plantao poderiam discutir. Imediatamente veio a primeira diivida: quem deve ser o gerente de projetos? Os professores de seu MBA dizem que cada projeto s6 pode ter um gerente! Em seguida pensou: e o patrocinador? Bem, em geral, essas so questdes que surgem no inicio dos projetos e que devem. ser resolvidas o mais répido possivel. Os papéis dos envolvidos diretamente com 0 projeto tam de ser definidos para que nao haja interferéncias negativas. Sabe-se que 08 patrocinadores sao 0s investidores, diretores, supervisores da alta geréncia, mui- tas vezes clientes internos, entre outros. Eles tém um interesse direto na resolugao e busca dos resultados do projeto. Seu papel muitas vezes é conseguir recursos dar solucao aos problemas que os gerentes de projetos precisam e no conseguem resolver. Ja o gerente de projetos, tipicamente, deverd ser o executivo do projeto: ele faz acontecer empreendimento! Eduardo no sabia, portanto, o que preencher no campo gerente de projeto e no campo patrocinador. Mesmo sem esperar a Ménica para discutir suas duividas, resolveu ir em frente e preencher 0 titulo do projeto: Casa Eduardo & Ménica. Em seguida, comecou a escrever o objetivo do projeto. Tentou digitar varios, mas ndo ficou satisfeito com nenhum! Eis alguns: + deixar de pagar aluguel;-’ 7 .* ter mais espaco, integrando ambientes; * construir uma casa sustentavel; + constituir uma nova familia num espaso nov + organizar as decisdes durante a construgdo e tomar agdes adequadas etc. Foi ento que Eduardo comegou a perceber a importancia de ter um bom project charter, e mais: que esse documento precisa ser bem elaborado para que tenha uma fungao gerencial. Agora Eduardo comegou a perceber que ter um charter de projeto & mais do que saber sobre sua importancia, seus beneficios, ou mesmo conhecer visualmente seus diversos modelos - sua visio de charter era, na realidade, muito académica. Com a necessidade de preencher para poder utiliz4-lo, gerencialmente, a coisa mudou. Para se ter um bom project charter, pensou Eduardo, é preciso, muitas vezes, dispor de varias informagées estratégicas que nem sempre esto a sua disposigao imediatamente. No caso das empresas, pensou em quais informacées seriam titeis — planejamento estratégico, andlise do setor, tecnologia envolvida etc. Esa reflexdo fez com que ele pensasse em informagées sobre construcio civil, prefeitura, escritérios de engenharia, entre outras, que poderiam servir como subsi- dios para a formacio de seu charter. Quando Ménica voltou do plant4o, Eduardo resolveu compartilhar com ela suas frustrag6es e dificuldades no preenchimento correto do documento. Apés discutirem os requisitos de informagio e fazerem algumas suposigdes, comesaram a trabalhar no preenchimento do charter novamente. Ficou decidido que Eduardo seria o gerente do projeto e Ménica a patrocinadora = decisio talvez pouco convencional, como tudo nesse casal. O titulo permaneceu ‘© mesmo € 0 objetivo teve a seguinte declaracao: construir uma casa (sobrado) de dois quartos em 15 meses com orcamento de R$ 300 mil. Decidiram também que, além dos cémodos tradicionais de uma casa com dois quartos, iriam ter uma pequena 4rea de lazer com churrasqueira e forno, fora da casa, um pequeno espaco para plantagoes das especiarias de Ménica. Lembraram que iriam precisar de alguém para cuidar da documentacao da casa, bem como dos registros das plantas. woe Em ‘seguida comesaram a pensar nas premissas, nas restric6es'e nos riscos envolvidos. Confusio geral! Entendiam que o documento prescindia de tais infor- mages, mas preenché-lo nao era tarefa facil. Nao eram questGes de escrita e sim de conceitos desses termos. : . st Apés muitas horas de reflexao e pesquisas nos livros de Eduardo, chegou-se a um consenso de que: (a) premissa seria algo incerto que iriam tomar‘como certo, a qualquer custo, (b) restri¢ao seria tudo que-limitaria o projeto; e (c) risco seria algo 74. Fundamentos em gestéo de projetos + Carvalho e Rabechin J. Gestio da integragto do projeto 75 Athy relacionado com as incertezas. Ele lembrou também que sua professora falou que as restricdes do projeto esto relacionadas ao seu escopo, pois limitam as opcdes da equipe, enquanto as premissas s4o condi¢6es a priori ou, como se diz em latim, sine qua non (sem a qual nao pode ser), ou seja, se no forem de fato “verdades” repre- sentardo risco a execucao do projeto, pois nao foram consideradas em seu escopo. Project charter Patrocinador Ménica Gerente Eduardo Nome Projeto Casa Eduardo & Ménica 10/01/06 Objetivo Construir uma casa (sobrado) de dois quartos em 15 meses com orgamento de : R$ 300 mil Beneficios ¥ deixar de pagar aluguel; ¥ ter mais espaco, integrando ambientes; ¥ ter patriménio proprio: Y_ melhorar a qualidade de vida. Prazo: 15 meses Custo:R$ 300 mil Restrigdes ¥ Tamanho do terreno; Y Prazos e custos. Premissas ¥ Ter terreno Escopo Macro ¥ servigos preliminares; ¥ documentacao (planta, Habite-se, registro prefeitura etc.); ¥ construgdo civil; ¥ acabamento; ¥ servicgos complementares; Y gerenciamento do projeto. Estrutura Basica da Equipe ¥ patrocinador: Ménica; Y gerente de projeto: Eduardo; Y_ executores: Modelo Engenharia, Arquitetura e Construgio S/C Ltda. Identificagso Riscos ¥ plano econdmico; ¥_aumentos abusivos no setor de construcdo civil Aprovacées Patrocinador Gerente Modelo Engenharia, Arquitetura Ménica | Eduardo @ Construcdo S/C Ltda. Figura 4.2. Project charter do projeto Casa Eduardo & Ménica. Eduardo e Ménica nao chegaram a brigar, mas sairam exaustos e levaram horas preenchendo o project charter (veja Figura 4.2). Sairam munidos do project charter, pois, sabiam que, agora, precisaridm aprov4-lo com 68 executores. Também acharam que as fronteiras ndo ficaram bem definidas e resolveram acrescentar um item como nao escopo ¢ deixar mais claras as quest6et'ambientas. Voce poderia refazer o projet charter ¢ ajudé-los a incorporar esses itens, que tal? vu Uma vez aprovado o projeto, faz-se necessario esbogar seu escopo, registran- do as varias possibilidades de suas entregas, dadas as estratégias de resultados. O gerente de projetos e sua equipe restrita devem ter elementos suficientes (charter e escopo preliminar) para, entao, poderem dar a partida no projeto. Para a realizagao da partida do projeto, algumas precaugdes devem ser tomadas pelo gerente de projetos. A comunicacao da existéncia de um projeto numa otganizacdo deve ser formalizada através de uma reuniao e distribuic¢ao e armazénamento de documentagio necessaria. A organizacao da reuniao de partida de projeto deve mostrar o quao cuidadosa ser4 a’administra¢ao do empreendimento. Uma reuniao de partida de projeto devera levar em conta uma agenda, uma lista de participantes, uma preparacéo de material e, essencialmente, uma preocupa¢ao em buscar comprometimento dos participantes. Quanto a agenda, a literatura tem apontado para preocupagées bastante convergentes, como: Bi *- recepcao dos interessados (stakeholders): faz-se importante “quebrar 0 gelo” entre os participantes, bem como fazer uma introdu¢io, por si _,mesmos; *\apresentacao dos objetivos: formalizar o inicio do projeto, promovendo ointegracao entre os participantes e discutir as metas, expectativas da _ alta administracdo e resultados; *slapresentacao da estratégia de gerenciamento do projeto: propor e in- 2/corporar estratégias para gerenciamento do projeto; aPresentacao do charter e escopo preliminar: mostrar que a preocupacao Sem planejar e controlar o projeto esta definitivamente iniciada; * consolidar comprometimento: revelar a opinido de pessoas importan- Ates, através de declaracées explicitas delas prdprias visando buscar 0 comprometimento dos demais participantes; a +. préximos passos: apresentar as pr6ximas tarefas a serem executadas, -. bem como o cronograma das préximas reunices. EET R 76 Fundamentos em gestio de projetos * Carvalho e Rabechini J. A conduco da reuniao de partida de projetos deve ser feita pelo gerente, mas algumas pessoas envolvidas diretamente devem ajudéd-lo na facilitac4o. Deve-se ter 0 registro de cada momento da reunido e, portanto, umia ata deve ser elaborada ao longo da reuniao e distribuida em seguida. Caso o gerente de projetos seja de personalidade analitica, introspectivo, é possivel que seja necessdrio nomear um facilitador no sentido de conduzir o grupo visando a sua integracao. Uma vez encerrada a sesso que marcou 0 inicio do projeto, é preciso ter claros os préximos passos que serao dados para que o comprometimento obtido mantenha-se em alta. Nesse aspecto, a informagao passa a ser a principal alia- da do gerente de projetos, que dever4 dela fazer uso para se comunicar com os diversos stakeholders no projeto. 4.3 O meio: a composi¢4o e o monitoramento do plano do projeto a O plano de gerenciamento de um projeto é 0 resultado de um processo de planejamento, expresso num tinico documento, integrado, que agrega informa: Ges de outros planos de forma coerente e consistente. Uma vez iniciado 0 projeto, o gerente deve incentivar sua equipe a produzir os planos subsequentes, a partir do charter e de um escopo preliminar. As equipes passam a se preocupar com o detalhamento do trabalho do pro- jeto, bem como dos prazos, custos, qualidade, risco, recursos, comunica¢ao etc. Essas preocupac6es devem estar expressas através de planos que, por sua vez, deverdo ser integrados. Um dos principais desafios do gerenciamento de projetos é acertar um. plano de projeto onde estejam representadas todas as preocupacées a serem adminis- tradas. Em geral, um bom plano de gerenciamento de projetos é aquele que integra os planos das dreas de conhecimento descritas no PMI (PROJECT MANAGE- MENT INSTITUTE, 2004) com as demais preocupacées envolvidas no ambito de um projeto. A composic¢ao do plano de gerenciamento do projeto deve considerar, ini- cialmente, os elementos organizacionais onde o projeto est4 inserido. Assim, na introdugao do plano do projeto é possivel que se faca necessario saber sobre a missdo de uma organizacao, seus objetivos, metas e esttatég as € COMO O projeto esta alinhado a tudo isso. Nesse contexto, os envolvidos com 0 projeto deverao saber: (a) a quais metas o projeto ira atender; (b) quais 6bjetivos 0 projeto deve alcancar; e (c) quais estratégias devem ser utilizadas para buscar seus objetivos. Também se faz necessario considerar, na composi¢do do plano de projeto, o desenvolvimento integrado das dreas de conhecimento. O elemento-chave dessa consideracdo 6, sem diivida, a WBS. Através da WBS 0 gerente de projetos podera esto da integrasSo do projeto 77 consolidar a integraco do gerenciamento de um projeto. E dela que saem os jnsumos para a programacao dos tempos, é com ela que as responsabilidades sao jnicialmente associadas, que a gest4o dos riscos encontra os indicios de fontes geradoras, que, enfim o gerenciamento do projeto se consolida. Coma WBS em mios 0 gerente de projetos, no intuito de fazer a integracao, terd condi¢es de responder a uma série de questdes. O Quadro 4.1 mostra alguns tipos de integracao e questdes associadas, a serem desenvolvidas pelo gerente de projetos e sua equipe. Quadro 4.1 Tipo de integragdo e as dreas de conhecimento. Integraco Questées Todos os pacotes de trabalho esto cobertos na programacéo Escopo x Prazo _ Todos os pacotes de trabalho apresentam-se com os devidos responséveis? Ss Escopo X Recursos Humanos : E possivel associar quem faz 0 qué? Dada uma programacao necesséria, 6 possivel associé-la as x ursos Humanos ee disponibilidades de recursos? Todos os pacotes de trabalho apresentam custos de mao de Escopa x Custos obra e aquisicées? E possivel identificar os desembolsos de recursos humanos e x ee Recursos Humanos x Custos aquisigoes? Recursos Humanos Comunicagao Os interessados esto recebendo informacées adequadas? Prazo x Suprimentos Quando e onde devern chegar as aquisic6es? Quando e como fazer as inspegdes no projeto? Qualidade x Prazo Quais varidveis devem ser medidas ao longo do projeto? Prazo x Risco Quando fazer as avaliag6es de risco? Custo x Risco Quais os custos dos eventos incertos?. = Os indicadores de resultado do projeto poderao ser '!" gerenciados? Existe um sistema de indicadores (EVMS) previsto para ser utilizado no gerenciamento do projeto? Escopo x Prazo x Custo Custo x Escopo Qual o custo das mudangas? i Ha uma programagéo de reunides do projeto segundo o Comunicaca icagao x Prazos planejamento de avangos? Gestdo da integraso do projet 79 | 78 Fundamentos em gestio de projetos + Carvalho e Rabechini Je. | gE | | As integracdes podem ser vistas através das curvas dos projetos. A Figura 4.3 mostra uma série de relacdes, entre as varidveis de um projeto. ‘% de términog do projeto Lento Rapido: Lento Tempo Nivel de & Custo A Esforco Prazo Prazo RReduzido Excessive Duraho Ideal 7 Tempo Custo das & Conflitos A Mudangas de Escopo | eee Tempo Fases Figura 4.3 As curvas tipicas de projetos. A medida que os planos de gerenciamento do projeto esto prontos, é possivel fazer novas integracées complementando as dreas de conhecimento. O Quadro 4.2 mostra os novos tipos de integracdo e as questes associadas. Quadro 4.2 Tipo de integrago e diversos elementos. Integragao > © Questdes a) ‘Todos os pacotes de trabalho estao cobertos com tecnologias Escopo x Tecnologia adequadas? Tecnologia X Recursos Humanos Todos os envolvidos dominam a tecnologia adquirida? Tecnologia x Prazo x Serd necessério programar treinamentos para as novas. Recursos Humanos tecnologias? Os eventos do projeto precisam ou carecem de atividades de Escopo x Marketing marketing? Recursos Humanos x Meio | Os envolvidos no projeto esto aptos a desenvolver produtos, Ambiente considerando-se o meio ambiente? Recursos Humanos x Tecnologia x Meio Ambiente O desenvolvimento do projeto tem considerado tecnologias adequadas dados os requisitos ambientais? Prazo x Juridico Estdo previstas aces juridicas ao longo do projeto? Juridico x Recursos Os especialistas nas questées juridicas esto por dentro do Humanos escopo € programagao do projeto? Risco x Meio ambiente 5 riscos ambientais foram avaliados? Com as integragGes realizadas o gerente de projetos deveré comunicar a equi- pe seu coritetido, discutindo seus possiveis ajustes. Em seguida, sera necessario aprova-lo com o(s) patrocinador(es). : Os planos de projeto mais conhecidos normalmente contém apenas os cronogramas fisicos que revelam como ser4 controlada a agenda do projeto. No entanto, uma abordagem gerencial mais profissional requer controle e acompa- nhamento de varios outros elementos, além do monitoramento da qualidade, da troca prevista de informagées, da recepcao de tecnologia etc. Assim, faz-se necessario produzir um documento (plano) contendo todos os Produtos que iro possibilitar o acompanhamento e controle do projeto. Para ter uma ideia das informagées existentes num plano de projeto, a Figura 4.4 mostra sumariamente os elementos fundamentais. . A reunifo para aprovagao do plano do projeto deve ser planejada cuidadosa- mente, evitando problemas qué possam interferir no sucesso do projeto. Como na reunido de partida do projeto (veja se¢ao 4.2), os cuidados devem ser tomados visando ao comprometimento dos stakeholders, agora em maior numero. x 80 _Fundamentos em gestéo de projetos * Carvalho ¢ Rabechiai Je Plano do Projeto > 1 Nome Projeto 7 Gerente Patrocinador 7 ‘Objetivo Y¥ declaracao do objetivo do projeto; ¥_metas associadas. : ‘Sumério Executivo ¥ project charter ¥_escopo preliminar. Prazo: Custo: Produtos Esperados Qualidade ¥- aserem elaborados pelo projeto; ¥ padrdes de desempenho; ¥ aserem adquiridos. ¥ revis6i ¥_avaliagdes. Gerenciamento do Projeto Gerenciamento do Projeto Wes; ¥ alocagao de recursos; cronograma fisico; ¥ plano de treinamento; cronograma financeiro; ¥ acompanhamento dos riscos; plano de comunicacao; ¥ administragao de contratos. cronograma de reunides. [eaees Estrutura Basica da Equipe Y patrocinador; Y gerente de projeto; ¥ equipe. ‘Anexos. Y tabelas auxiliares; ¥ relatérios ambientais; Y manuais ¥_memérias de calculo etc. Aprovagées Patrocinador Gerente Cliente Figura 4.4 Plano do projeto ~ elementos essenciais. ; 1 E necessério registrar que muitos projetos chegam a esse est4gio um pouco desgastados, sendo que muitos nao tém félego para continuar. Sabe-se que, no momento dessa reunido, existe um marco implicito do ciclo de vida de um projeto que poderé revelar sua continuidade. Sabe-se, também, que os custos daqui para frente serao cada vez maiores, necessitando de controles rigidos. ‘ z . Gestio da integragfo do projeto 81 A dinamica do projeto toma outra frequéncia. O ambiente passa’a ser de execuc4o € nao mais de planejamento. Isso faz'uma grande diferenga, a que o gestor deve estar atento, pois os impactos nos resultados sao agora evidentes e reais: Numa linguagem mais popular, pode-se dizer que o projeto, a partir da aprovagao de seu plano, passa a ficar mais “nervoso”. A execucao de um projeto dever4 ser acompanhada do plano e o gerente e sua equipe devem estar atentos logo nos primeiros movimentos. Existe uma diferenca sutil entre acompanhamento e controle de projeto que, esclarecida, pode ajudar o gerente de projetos a encarar profissionalmente a sua gestao. Controlar é interferir, e acompanhar, nao, e, nesse aspecto, a informa¢ao éum elemento vital para o controle. Portanto, para um efetivo controle de todo trabalho desenvolvido em projetos, é requerido um sistema de gerag4o, registro e disseminacao de informagio, a respeito do andamento do projeto. Através da andlise das informacées geradas pelo sistema do projeto, o gerente e sua equipe devem tomar decis6es (interferéncias) que mantenham o projeto nos trilhos. Duas abordagens, em termos de geréncia profissional, devem ser adotadas . pelos gerentes de projetos. Uma, baseada do trabalho desenvolvido e no registro do andamento desses trabalhos. Nessa abordagem, os gerentes, munidos de in- formagoes de custo, prazo e escopo, fundamentalmente, comunicam as decisdes do projeto aos envolvidos. Para isso so requeridas informacGes tanto de carater + quantitativo, quanto qualitativo. ‘A outra abordagem se refere aos aspectos baseados nas relacdes humanas. Muitos gerentes de projetos depositam suas energias nas boas relagdes com os stakeholders, fazendo com que os resultados do projeto sejam, gradualmente, conseguidos. Na verdade, um gerente de projetos profissional faz uso equilibrado dessas duas abordagens. Para as duas, existem técnicas bastante desenvolvidas para controle de projetos que serao apresentadas nesta parte do livro, abordadas segundo as areas do conhecimento. 4.4 O fim: nao se esquega de formalizar o encerramento do projeto O encerramento de um projeto precisa ser organizado, pois, caso contrario, nao é realizado. Temos visto em trabalhos de consultoria, congressos, palestras, quando solicitamos as pessoas que relatem suas experiéncias sobre encerramento de projetos, as mais variadas manifestacdes humoristicas. Talvez seja a fase de um projeto que menos se leva a sério. No entanto, muitas das empresas que conseguem porsoes significativas de mer¢ado 0 fazem por terem, justamente, 82 Fundamentos em ges do de projetos * Carvalho e Rabechini Jr. realizado de forma adequada.o encerramento de seus projetos. Estas saem na frente, pois tem informacées estratégicas em mos, antes que os concorrentes. O encerramento do projeto deve ser marcado por um evento que formalize 0 fechamento de todas as'sua acdes. Deve ser designado um gerente, no inicio do projeto, para se responsabilizar por essa etapa do projeto. O encerramento, sob essa visdo, tem de ser planejado, sobretudo no que diz respeito As informacées a serem armazenadas. O PMI (PROJECT MANAGEMENT INSTITUTE, 2004) considera que 0 encerramento de projeto deve ser feito sob dois grupos de procedimentos. O primeiro se refere ao fechamento de cada fase do projeto. Cabe aqui armazenar os dados referentes as andlises de sucesso/fracasso de cada fase do projeto, arquivar as informacGes sobre as diversas geréncias do projeto (programacao e realizacao nos prazos previstos, realizados e valor agregado dos diversos momentos do projeto, entre outras), registrar as licGes aprendidas e divulgar os procedimentos para acesso ao banco de dados do projeto. O segundo diz respeito ao fechamento dos contratos realizados durante o desenvolvimento do projeto. Cabe aqui 0 encerramento formal dos contratos, a verificagéo dos itens de notas pendentes e a programacao de pagamentos pos- teriores ao projeto. 7 Um fluxo que descreva o processo de encerramento de projetos (Figura 4.5), mostrando todas as suas a¢ées, poder ser titil ao gerente na hora do fechamento administrativo. . elatérios de controle de onograma é finangs Figura 4.5 Processo.de encerramento de projeto. = z r Gestdo da integrasio do projeto 83 Alguns projetos preveem a distribuicao de lucros entre os integrantes, caso 0 projeto tenha obtido sucesso. O encerramento formal do projeto deverd, assim, deixar claro os valores a serem compartilhados entre os envolvidos. Nesse caso, faz sentido organizar junto equipe de projetos um evento que marque o encer- ramento vitorioso do projeto, Evidentemente, que, nos casos em que 0 projeto deu prejuizo, faz-se necessario organizar uma reuniao para que sejam discutidas as licdes tiradas do desenvolvimento do projeto. Naturalmente, cuidados devem ser tomados no sentido de que os interes- sados nao se sintam desconfortaveis. Para tanto, o gerente de projeto devera conduzir a reuniao dando énfase aos seguintes aspectos: + -Recep¢ao dos convidados: embora alguns membros tenham se desta- cado mais que outros, durante a recep¢4o dos participantes o gerente & de projetos nao deve fazer distinc6es. * Apresentacao da pauta: a pauta, distribufda anteriormente, devera ser anunciada, inicialmente. * Apresentaco dos resultados finais: as informagées relevantes constan- tes na apresentaco final do projeto devem ser discutidas. * Evidenciar as boas contribuicdes: cabe destacar os membros que con- seguiram bom rendimento ao projeto. + Problemas: é com os casos de fracasso que se pode aprender em projetos, portanto, estes tém de ser trabalhados racionalmente durante a reuniao. * Novas propostas: antes de encerrar a reuniao, vale a pena mostrar as possibilidades de trabalhos futuros. * Préximos passos: fechar definitivamente a reunido. Em alguns casos, uma comemoracio discreta faz bem aos participantes. Questées para reflexao e discussio 1. Quais informacées vocé acrescentaria no project charter do projeto da Casa Eduardo & Ménica? 2. Complete um charter que represente as intences de um projeto de construc4o de um novo restaurante na faculdade que vocé estuda. 3. Mostre 0 project charter do tiltimo projeto que participou. Dos elementos de seu plano de projeto, quais as semelhangas € quais as diferencas entre os apresentados neste capitulo? 5. O que se pode aprender com um projeto? Faca uma relacao contendo os Possiveis itens de aprendizagem. i li x! i 84 Fundamentos em gest de proeros * Carvalho. Rabechini J, ————_________ | 6. Identifique um projeto em que.foram feitos os procedimentos de encerra- mento. Liste as ligdes aprendidas. 7 7. Considere um'projeto de instala¢ao de gasodutos e reflita sobre as cinco principais intégragdes'necessarias. i 2 Benth 8. Considere a implementacao de um sistema de ERP (Enterprise Resource Plan ning) e liste os principais problemas de integra¢ao que podem aparecer nesse tipo de projeto. 9. Paulo Mario foi nomeado gerente de projetos de implementacao de um siste- ma de automacio industrial. Imediatamente fez um project charter, convocou uma equipe e se propés a apresentar o projeto para a diretoria da empresa. Antes de terminar sua apresentacdo, foi bombardeado pelo diretor de mar- keting e de finangas. Discuta os possiveis desmembramentos desse fato. Discuta também como fazer uma venda adequada de projetos, os cuidados que devem ser tomados. 10. Sabe-se que as turbinas de energia de um importante projeto de desenvolvi- mento de uma hidrelétrica chegaram com um més de atraso, mas, por outro lado, sua instalacdo sé foi realizada seis meses apés a entrega. Discuta os aspectos ligados a integracdo e os impactos que poderdo ocorrer num projeto desse tipo. vi Mi ae Aquisig6es « Qualidade Aes Neste capitulo, ser4 tratada a questo do gerenciamento do escopo dos projetos. Apés esta unidade, o leitor terd condi¢ées de erene as seguin- tes quéstdes: 2) Quais os processos que suportam o gerenciamento do,escopo do projeto? ‘ b). Como estruturar um projeto — sintese e andlise do trabalho? ©) Quais as técnicas utilizadas para a realizag4o do’ ‘gerenciamento do “~ escopo? d) Como o gerente de projetos pode sé beneficiar do’gerencidménto do si escopo do projeto? 86 Fundamentos em gestio de projetos + Carvalho e Rabechini Jr. A famosa histéria de Lewis Carrol, Alice no pais das maravilhas, revela uma preocupa¢ao bastante ‘singular des um coelho, sempre apressado. Essa preocupa¢ao pode ser resumida num didlogo entre Alice e 0 tal coelho. Alice - Onde fica a safda? Coelho — Mas para onde a senhora quer it? Alice - Para qualquer lugar. Coelho — Para qualquer lugar, qualquer saida serve. As preocupagGes com as intengées e abrangéncia do projeto, com a busca efetiva de seus objetivos, séo empreendidas através da 4rea de conhecimento que considera o gerenciamento de escopo. Elas nao podem ser genéricas, como no didlogo apresentado! gerenciamento do escopo do projeto inclui os processos requeridos para garantir que sejam executadas as atividades necessarias, e apenas as atividades necessarias, para que 0 projeto seja encerrado com sucesso (PROJECT MANA- GEMENT INSTITUTE, 2004). 5.1 Introdugao © conceito de escopo de projetos talvez seja um dos mais variados de todas as dreas de conhecimento do gerenciamento de projetos. Fala-se em alcance, esboso, intencées, objetivos, limites, entre outros. Escopo, na verdade, refere-se ao trabalho a ser realizado no ambito do projeto. Nesse aspecto, o escopo pode estar ligado ao produto ou ao projeto. A disciplina gerenciamento de projetos tem se preocupado com o gerencia- mento do escopo do projeto, uma vez que os processos de gerenciamento de escopo do produto variam conforme as areas de aplicagao. Os processos considerados pelo Project Management Institute - PMBoK® Guide (2004) no gerenciamento do escopo do projeto sao: a) Coletar os requisitos: definicdo e documentacao das necessidades das partes interessadas para alcancar os objetivos do projeto. b) Definir o'escopo: desenvolvimento de uma declaracao detalhada do escopo do projeto, como base para as futuras decisdes do projeto. c) Criar a'Estrutura Analitica do Projeto — EAP (work breakdown structu- re — WBS): subdivisao das maiores entregas e trabalho do projeto em componentes menores, com possibilidades melhor de gerenciamento; d) Verificar 0 escopo: aceitacao formal dos escopos do projeto; e) Controlar o escopo: controle das alteragdes de escopo do projeto. \g Gestdo do escopo do projeto 87 A area de escopo tem forte ligacdo com a atea de integra¢4o, conformie ilustra a Figura 5.1. Além disso, a area de comunicac6es deve identificar e gerenciar os requisitos dos stakeholders, informar através dos seus Relatérios de Desempenho, ou seja, tem insumos importaiites ‘para a gestad do escopo do projeto e de suas mudangas. HE AO) Coletar | ana Requisitos, ees Documentacao de requisitos Plano de gestdo dos requisitos Mari de rastreabiidade dos requisitos Dedlaragéo de Escopo (Greliminer) Requisitos de Mudanga Plano de Projeto \atuaizado) Decaracio de Escopo (atualizado) Fatores Ambientais Plano de Projeto Ativos (atualizado) Organizacionais Plano de Projeto {atualizado) £scopo Verificado wes Informagbes de esempenho Requisitos de Mudangs | Agbes Corretvas 3454) 6 Plano de Projet Contialay | 2S Gusiza Recursos Organizacions (atualizado) +«-——_| Requisitos de nine mudanga (atualzado) _ Fonte: Adaptada de PMI (2008)... « tr Figura 5.1 Flux dos processos de gestdo do estopo. aa Laid 88 Fundamentos em gestio de projetos + Carvalho e Rabechini J. Além disso, nesta 42.édicdo do guia PMBoK foi criado um novo processo, que é coletar os requisitos dos projetos. De fato, esse processo est4 intimamente ligado com a gesto da qualidade que veremos no Capitulo 8, onde faremos sua traducdo em parametros de controle do projeto. Portanto, detalharemos de forma integrada a coleta, o desdobramento e o controle dos requisitos no Capitulo 8, 5.2. Coletar requisitos e definir 0 escopo do projeto Apés a aprovaco do project charter (veja Capitulo 4), faz-se necessério coletar 0s requisitos dos principais stakeholders e estruturar seu escopo para que ele possa ser gerenciado adequadamente. O processo de coletar os requisitos do projeto é altamente dependente de processos das areas de comunicagées e relacionado aos processos da drea de Gestao da Qualidade, assim como para construir a matriz de requisitos é neces- sario identificar os principais stakeholders, etapa da area de comunicagoes (ver Capitulo 10), e desdobr4-las em critérios de aceitacao, etapa desenvolvida na area de qualidade (ver Capitulo 8). Neste capitulo, nos dedicaremos 4s atividades de defini¢aéo do escopo e construcdo da estrutura analitica do projeto. Para isso, devem ser consideradas duas questdes: a declaracdo do escopo e sua defini¢o. Fazendo-se uso de uma linguagem mais corriqueira, pode-se dizer que é agora que o gerente de projetos e sua equipe devem se preocupar em “armar 0 projeto” para seu efetivo gerenciamento. Isso significa gerar uma base de conhecimento, comum, dos resultados e trabalho a ser desenvolvidos no ambito do projeto. Obviamente, esse conhecimento do escopo servird para ser compartilhado com todos os envolvidos. A declaragao de escopo é um processo que visa elaborar e documentar, pro- gressivamente, todo o escopo do projeto para atingir seus objetivos. A declaraco de escopo de um projeto deve incluir, essencialmente, as se- guintes informagées: a) justificativa de sua criacdo: essa informacdo servird para que o gerente de projetos e sua equipe possam apresentar as necessidades de negécio que motivaram a cria¢ao do projeto. No ambito de uma empresa, ajuda o gerente de projetos a negociar recursos para o projeto; ° b) objetivos do projeto: uma vez estabelecidas as justificativas, é preciso deixar claro as intengées do projeto, ou seja, quais suas metas quan- titativas, quais os resultados esperados. Normalmente, projetos com objetivos bem declarados sao aqueles que mostram explicitamente os alvos de prazo, custo e qualidade esperados. Quanto aos objetivos mais qualitativos, estes carregam um grau maior de risco em relacdo ao seu atendimento; & Gestio do escopo do projeto 89 © ©) produto do projeto: aquilo que se espera entregar no final para que o projeto tenha sucesso. Essa informa¢ao deverd conter uma descri¢ao sucinta do produto do projeto. Em muitos projetos, essa informacéo poder envolver desenhos, fluxogramas, esbogos, detalhes de cons- trucdo etc. Ela pode ser complementada com a adicao de uma lista de subprodutos, que, quando integrados, devem compor o produto final do projeto. Devem-se incluir também os critérios de aceitacao do produto. No entanto, é bom que a declaracao também explore adequadamente as fron- teiras'do projeto, o que é escopo e o que nao é escopo do projeto. Além disso, é interessante estabelecer as premissas e restrigdes do projeto conforme jé discu- timos no Capitulo 4, quando da confec¢ao do termo de abertura (project charter). Uma vez registrada a declaragao do escopo, faz-se necessario iniciar 0 pro- cesso de detalhamento do escopo. Esse processo envolve a decomposicao das entregas do projeto de tal forma que os componentes menores gerados possam ser administrados mais facilmente. A decomposicao é um processo que pode ser expresso numa ferramenta conhecida como Estrutura Analitica do Projeto (EAP), que, por sua vez, vem do original Work Breakdown Structure (WBS). A WBS consiste na representa¢4o hierarquica de todo o trabalho do projeto através da decomposicao de seus re- sultados principais. 5.3 Estrutura analitica do projeto ‘A WBS 6 a representacao do processo de desagregacao (para baixo) e inte- gracao (para cima) do trabalho do projeto que vai ajudar o gerente de projetos na execucdo e controle das atividades do projeto. Os élementos finais conseguidos nesse processo sio denominados de pacote de trabalho (mais baixo nivel). Para que os pacotes de trabalho possam ser ge- renciados, associados a eles devem estar os seguintes elementos: a) objetivo: identificacao do que deve ser atingivel com o pacote; b) entregas (deliverables): produto/servi¢o associado ao trabalho; ‘) programasio: atividades associadas com o respectivo planejamento de execucao; d) orcamento: cronograma financeiro de desembolso e valores acumulados; e) responsabilidades: mao de obra (homem/hora) associada, além de responsaveis diretos pelo trabalho. A construgao de uma WBS faz parte de um processo que visa obter a subdi- visio dos resultados parciais que se esperam alcangar com o projeto em compo- nentes menores mais facilmente gerenciados. 90 Fundamentos em gestio de projetos + Carvalho Rabechini J. Para fazer a WBS parte-se de uma estrutura hierarquica top-down (do todo para aparte), decompondo todo o trabalho do projeto até chegar no pacote de trabalho, nivel mais baixo da estrutura analitica do projeto, mas que ainda est associado a uma entrega tangivel, o que o diferencia da atividade, que ¢ a decomposi¢o que fazemos para a elabora¢ao do cronograma, que veremos no Capitulo 6. Nesse processo de decomposico, é importante atentar para algumas regri- nhas. As caixinhas da WBS devem ser mutuamente excludentes, ou seja, um mesmo trabalho nao se encontra em duas caixinhas da WBS. Lembre-se que isso nao quer dizer que as caixinhas nao tenham relacdo entre si, afinal s4o partes de um mesmo projeto e assim tém dependéncia, quer dizer apenas que nao ha redundancia entre elas. Além disso, a soma do trabalho de todas as caixinhas de um determinado nivel deve representar 100% do escopo do nivel superior (ndo pode faltar trabalho); é o que chamamos de integragao (para cima). E recomen- davel também utilizar substantivos para nomear as caixinhas da WBS. ‘Além disso, vocé pode utilizar varios critérios de decomposi¢éo para fazer a WBS, orientada aos subsistemas, a geografia, 4s func6es, as fases do ciclo de vida, As competéncias/aos recursos ou outro critério que pareca pertinente no seu contexto gerencial. A arte de fazer uma boa estrutura analitica é dominar a decomposi¢ao. Enquanto o gerente estiver inseguro quanto as estimativas, é necessario conti- nuar decompondo em niveis menores de trabalho. Também procure manter um mesmo tipo de competéncias em um pacote de trabalho; é mais facil gerenciar, embora nem sempre seja possivel. Finalmente, lembre-se que vocé deve evitar os extremos, pouca decomposicao pode significar que as estimativas dos pacotes de trabalho estao muito grosseiras, enquanto WBSs muito decompostas perdem a finalidade gerencial (aproximam-se do cronograma); nao adianta fazer um mapa do tamanho do mundo! Podemos descrever quatro passos para a decomposi¢o do projeto ao longo da estrutura analitica, conforme segue: (1) Identificar os principais entregas (deliverables) do projeto Projeto Cada caixinha deve ser’ Passo 3 Passo 4 Gestio do escopo do projeto 91 z— (3) Identificar os componentes das entregas de pacotes de trabalho Projeto a a [ Entrega Entrega Entrega, [, Pacote de Pacote di Trabalho Ss kpdhs otratth Trabalho 4 ’ le Pacate de Trabalho Bert PTS Wart Package Level Ew) Pacote dé LJ. Trabalho! APTA) Custo?/Duraga0?/Critério de aceitagao? (4) Verificar se a decomposicao esté correta. Passo seguinte: decompor os pacotes em atividades; isso j4 faz parte da gestao de tempo, para a elaboracao do cronograma Fazer aintegragao da base para o topo. ‘Asoma dos pacotes de trabalho deve ‘conte todo o trabalho dajentrega de nivel imediatamenté Superior.“ * ” Bx Py t Phys = 100% da Frege, Alguns autores consideram a WBS a espinha dorsal do projeto, pois permite a integracdo da triade: escopo, custo e tempo, constituindo um fator critico de ‘sucesso para o projeto (GLOBERSON, 2002, BACHY; HAMERI, 1997; LAMERS, 2002). Utilizando-se da WBS, podem-se estabelecer relagdes mais claras nao sé entre a triade mencionada, mas também com qualidade e riscos, como veremos mais a frente neste livro. Para entender a construcao de uma WBS, vamos ver como foi 0 processo de elaboracado da WBS da casa de Eduardo e M6nica. A construcao da WBS de um projeto se dé no momento em que jé existe um charter aprovado e se faz necessario detalhar todo o trabalho necessario a realizacio de um projeto. Eduardo e Ménica, antes de abrir o computador e desenhar a estrutura analitica, dessa vez resolveram tomar as seguintes decis6es: Y agrupar os servicos preliminares num s6 grupo; Y tratar as documentagées anteriores e posteriores ao projeto num s6 grupo; Y separar a construgao do acabamento; e ¥ ter um grupo que representasse a geréncia do projeto. j Feitas tais considerag6es, a WBS do casal ficou assim: ° | ii Hl 92. Fundamentos em gestdo de projetos + Carvalho e Rabechini J. tty gE . Gestio do escopo do projero 93 q | [ ; =, Muitos gerentes de projetos costumam representar a WBS através de tabelas, Pal i z E ilse uma vez que os programas de planilhas so de facil manuseio. A Figura 5.3 mostra i { el le |e # o mesmo exemplo em forma de tabela. { HAE Wie Ee nt re j | : F Es \ & 01. Servicos Preli--| 01.01 Limpeza i re rt minares (2%) |. 01.02 Agua/tuz } = a 01.03 Canteiro I: ae z 3) 02. Projeto (8%) | 02.01 Planta 02.01.01 Arquitetura Mf |e 4 Be a 02.01.02 Elétrica Ht ns ee te 02.01.03 Hidréulica i | 3) alba 02.01.04 Estrutural i i i ' 02.02 Aprovacées _| 02.02.01 Plantas i i z ¥ 02.02.02 Alvar ! ql a td 2 03. Construgéo —_| 03.01 Fundacao (4%) i [ He (35%) 03.02 Estrutura (16%) : r 4 03.03 Telhado (5%) iy § 5 03.04 Esquadrias (7%) : e 03.05 Alvenaria (3%) Hl | if = i ~ 4| ally 2 i 04, Sistemas 04.01 Hidréulica (8%) Hy! a daile 4 (16%) 04.02 Elétrica (6%) i | 2 SHE . } | 3 i , 05. Acabamento | 05.01 Pintura (5%) | (05.01.01 Interna l } 4 lets (38%) 05.01.02 Externa i 8 05.02 Revestimentos/ | 05.02.01 Banheiros Acabamentos (25%) | 05.02.02 Cozinha i Ht i ¢ ant 05.02.03 Quartos | i a 05.02.04 Outros I I 3 05.03 Vidros (2%) \ ig 05.04 Armérios (5%) ! § 06. Servicos 06.01 Limpeza | ‘Complementa-| 06.02 Jardinagem res (1%) 3 balls 07. Geréncia (0%) | 07.01 Plano i 3 2/2 07.02 Acompanha- Wi 2 “Al ris i, 07.03 Entrega/encer- 1. ramento I. Figura 5.3 WBS Casa, representada por tabela.- fe : b aa A. ine it Vérias questées decorrem do estudo das estruturas analiticas de projetos. Uma delas refere-se ao percentual dedicado ao gerenciamento de projetos. Sabe-se, cada } vez mais, que essa 6 uma atividade relevante e que deve ser executada com primor; ! Figura 5.2. WBS Casa Eduardo & Ménica. ¥ 94 Fundamentos em gestfo de projets + Carvalho e Rabechi visando levar 0 projeto ao sucesso. Portanto, faz-se necessério, quando h4 uma equipe especializada para isto, considerar seus custos e recursos envolvidos. H4 casos em que ndo ha necessidade de se formar uma equipe de gerenciamento, e a dedicagao do gerente acaba sendo direcionada também para outras atividades de sua especialidade no projeto. E 0 que esta ocorrendo no caso de Eduardo & Ménica, por exemplo. Embora o trabalho do casal esteja representado na WBS, seu percentual serd desprezivel, pois nfo serao contabilizadas as horas gastas e seus respectivos valores em gerenciamento. Outra questo que os estudiosos em gerenciamento de projetos tém debatido com relacdo as estruturas do trabalho dos projetos se refere as regras da decom- posicao. Parece que nao h4 um consenso de até que nivel devem-se desagregar os elementos de uma WBS. As atividades esto incluidas ou nao? Essa discussdo foi tratada por Berg e Colenso (2000), que apresentam uma série de pontos favordveis e desfavoraveis da inclusdo (ou nao) de atividades na WBS. Alguns pontos levantados pelos autores mostram os dois lados da questo. As WBSs nfo incluem as atividades. VA WBS em geral é uma ferramenta orientada aos deliverables, que, por sua vez, so expressos através de substantivos, ao passo que as atividades sao expressas em verbos. ¥ A WBS nio chega ao detalhe de alocacao de pessoas e nem de estabeleci- mento de dependéncias. Os membros da equipe devem ter a liberdade de exercitar a criatividade, escolhendo os métodos e sequéncia de atividades adequados para poder produzir os deliverables. Esses métodos e atividades no precisam estar expressos na WBS. ¥ Oprocesso de criagdo da WBS é uma atividade de planejamento separada do proceso de criacio de redes de atividades e suas dependéncias. Portanto, nao ha correlagdo direta entre esses dois processos. As WBSs incluem as atividades. ¥ As relacdes de dependéncia pressupdem que as atividades predecessoras entreguem algo (deliverable) para que se possa iniciar uma sucessora. Por- tanto, atividades criam deliverables. Y Deliverables resultam de atividades e sao gerados de uma estrutura hierér- quica (de deliverables), ou seja, so decompostos de deliverables de mais alto nivel, vindos, em tese, da WBS. Portanto, hé uma correlacao direta entre atividades e WBS. Y Oprocesso de criagado de uma WBS é top-down, que por fim gera uma rede de atividades/eventos. Mesmo sendo processos separados, um recebe influéncia do outro e tém atividades como elemento comum. Alguns aspectos, entretanto, devem ser levados em conta, resultado dessa re- flexdo inicial. Assim: 1» Gestdo do escopo do projeto 95 v ° gerente de projetos deve ter, realmente, o direito de decompor a WBS visando atingir niveis gerenciaveis. Uma WBS é uma ferramenta que pode ser utilizada de diferentes formas, dependendo das necessidades dos ge- rentes de projetos. "| v Conforme definida no Guia de Conhecimentos em Gerenciamento de projetos do PMI - PROJECT MANAGEMENT INSTITUTE (2004) -, WBS 6 uma ferramenta que desmembra 0 trabalho de um projeto de forma hierrquica e orientada a deliverables. ¥ Omais baixo nivel da WBS nao contém rede de atividades e mesmo schedule. Entretanto, o mais baixo nivel pode ser conectado formando ligagdes com os diagramas de rede de atividades. Portanto, o mais baixo nivel pode ser uma atividade. Y Hé um consenso de que as entradas na WBS devem ser formadas por substantivos, especialmente as de mais alto nivel. O gerente de projetos deve ter a liberdade para escolher se usa substantivo ou verbo para dar uma entrada na WBS, principalmente nos itens de mais baixo nivel. v A WBS pode ser elaborada como um deliverable hierarquico e pode ser estruturada obedecendo as fases de ciclo de vida; entretanto, pode ser formada a partir de substantivos que serao detalhados. Discussao a parte, é comum os gerentes de projetos se adaptarem facilmente com o.uso da WBS. No entanto, para se fazer uso adequado da ferramenta, sua constitui- io deve ser elaborada através do uso de pequenos pedacos de papel, autocolantes, em que as decomposicées do trabalho so representadas ¢ explicitas aos envolvidos no planejamento. Percebe-se durante a construgao da WBS a integracao dos membros e 0 infcio do comprometimento com todo o trabalho do projeto. Assim, é possivel pontuar as vantagens do uso da WBS: visdo de todo 0 escopo do projeto e suas entregas programadas; associagao de responsabilidades explicitas; estabelecimento de estimativas de custos bottom-up; facilidade de apresentaco do trabalho do projeto; constituigao das principais fontes de risco e identificago de incertezas; apresentaco das estimativas do total de homens/hora do projeto; identificacao dos envolvidos que necessitam de informagao do projeto. _Um comentario importante a respeito da WBS de um projeto refere-se ao trabalho dedicado ao gerenciamento do projeto propriamente dito. Os gerentes de projetos devem deixar claro que existem trabalhos inerentes ao gerenciamento e, portanto, Tepresentd-los na WBS com os demais. ° RN MERE RE KE 96 Fundamentos em gestio de projetos + Carvalho e Rabechini Jt A Constituic¢go de uma WBS, por fim, deve levar em conta tanto 0 trabalho quanto os recursos das 4reas funcionais da empresa. Nesse sentido, vale a pena relacionar a origem dos recursos com os trabalhos envolvidos em cada entrega planejada na WBS. A Figura 5.4 mostra esta relacao. ESTRUTURA ORGANIZACIONAL j 5 ome] | frtrawor |] econo | |e ame | N° | Programasio: 2 J ing i Eg v9 ramen z Figura 5.4 _Integragiio estrutura organizacional e WBS. 5.4 Acordando 0 escopo do projeto com os stakeholders Uma vez constituida a WBS, ficam explicitas as responsabilidades dos interessados nos resultados do projeto. Esse é um ponto bastante importante do projeto e cabe ao gerente explorar bastante esse momento. Para que a wes possa ser um instrumento bastante eficaz no gerenciamento faz-se necessario garantir que seu contetido seja devidamente aprovado, com comprometimento dos interessados. O PMI (PROJECT MANAGEMENT INSTITUTE, 2004) explora um processo de acordo com 0 escopo do projeto que visa formalizar 0 aceite do projeto pelas partes envolvidas. Uma das praticas mais comuns para efetivar os acordos com os stakeholders &a reuniao de projetds. Nela, o gerente de projetos deverd, para cada pacote de trabalho, garantir a entrega e associd-la a um responsdvel. “| Gestio do escopo do projeto 97 5.5 ,Verificagao e controle das alteragdes do escopo Um dos processos mais importantes do gerenciamento de projetos é, sem duvida, a verificacdo e controle de escopo através de revisdes. As revisGes de projetos devem ser planejadas de acordo com as necessida- des de verificacao de escopo tracadas no planejamento. O Quadro 5.1 mostra os principais tipos de revisdo em projetos. 1 Quadro 5.1 Tipologia de revisao. Reviséo Objetivo Periédica Previstas para serem realizadas em determinados periodos do projeto. Apés cumprir determinadas fases, as revises ocorrem com o objetivo de ase, 4 an Fase, aprovar a fase anterior e, assim, iniciar nova fase. Revises pontuais em que o gerente de projetos e sua equipe apresentam Esporédicas | o- avancos alcancados. t ‘As revis6es de escopo de projetos devem apresentar resultados para que 0 gerente de projetos possa tomar suas decisdes com base nelas. Apés as revisdes os gerentes terao condigées de saber sobre os destinos de projeto. Caso 0 tra- balho esteja atingindo o escopo, segundo o planejamento, a decisao do gerente deve ser manter o desenvolvimento. Caso haja necessidade de aumentar ou diminuir 0 escopo, o gerente deve optar por elaborar um novo planejamento. Nesse caso, a WBS teré de ser revista e a avaliacao das implicagdes em prazos e custo tem de ser refeita. Por fim, caso 0 escopo do projeto tenha sido realizado, cabe ao gerente pro- ceder ao,encerramento do mesmo. Para tal, é necessdria a aceitacdo formal do pacote de trabalho, com base nos critérios estabelecidos. Em geral, a aceitac¢ao formal implica liberagdo de pagamentos, portanto, é necessdrio que de fato tenha havido um controle e verificacao da entrega feita, conforme veremos em maior detalhe nos Capitulo de Gestao de custos (7) e Gestdo de qualidade (8). Durante o desenvolvimento de um projeto, em alguns casos, ocortem altéra- g6es de escopo. Em projetos grandes, em que a incidéncia de mudangas é frequen- te e intensa, cabe ao gerente estabelecer um sistema de controlé de mudangas. A principal entrada para um sistema de controle de mudanga é um documen- to denominado solicitagao de’ mudancas. Seu contetido deve refletir, além dos dados das mudancas em si, os impactos que elas podem causar a0 projeto, em termos'de seus resultados esperados (normalmente, prazo, custo e qualidade):! 98 Fundamentos em gest de projios + Carvalho e Rabechin J: As solicitagdes de mudancas em projetos devem ser sistematicamente ana- lisadas pelo gerente de projetos e sua equipe. Um sistema de controle e acom- panhamento de solicitacdes de mudangas em projetos deveré conter elementos que ajudem na anélise de cada uma delas, possibilitando assim a realizacao de uma espécie de triagem, em que seja possivel selecionar as mudancas mais im- portantes. As mudangas sao mais frequentes nos projetos em que 0 escopo nao foi bem planejado, ou em que a anilise dos interessados nfo foi exaustiva, ou ainda em que a avaliagdo dos riscos inerentes ao projeto nao tenha sido desenhada adequadamente. No entanto, existem outras situacGes em que as mudangas sao inevitaveis: s4o os casos de projetos inerentes a setores turbulentos. Por exem- plo, no Brasil, no final da década de 1990, o setor de telecomunicagées passou por transformacées profundas, fazendo com que os projetos desenvolvidos na €poca fossem muito sensiveis 4s mudangas seja por prazo, custo, especificag6es, tecnologia, fornecedores etc. Na verdade, quanto mais diferente e tinico for um projeto, mais suscetivel A mudanga ele estard. A diversidade e a temporalidade fazem com que seja requeri- do um planejamento forte em diversas 4reas do conhecimento em gerenciamento de projetos. E, quando isso nao ocorre, as mudan¢as aparecem, inevitavelmente. As mudangas ocorridas durante a execu¢4o de um projeto podem e devem ser administradas. Inicialmente, o gerente e sua equipe devem, ao fazer o controle do escopo do projeto, procurar possiveis focos de mudangas. Recomenda-se que a mudanca reconhecida seja traduzida para um documento. Em geral, esse proce dimento vem ao encontro de ser um exercicio para melhor se terem informac6es do futuro enquadramento das mudangas. Gestdo do escopo do projeto “ 99 Eduardo rapidamente acessou um formulario de solicitagéo de mudangas dado em Seu MBA e comecou a preencher. Embora de facil preenchimento, Eduardo teve que pesquisar bastante sobre as informag6es requeridas, bem como fazer uma série de simulages sobre impactos possiveis. O documento final ficou como mostra a Figura 5.5. Solicitagéo de Mudancas Nome Projeto Gerente Patrocinador Casa Eduardo & Ménica__| Eduardo Ménica ed Namero da Mudanga: 01/06 Area: Hidréulica/elétrica _ “ [Solicitante: Eduardo & Ménica Objetivo da Mudanca Instalar um sistema de aquecimento solar contendo 3 placas e boiler de 300 litros. Justificativa e Beneficios da Mudanga Y economia de energia elétrica. ¥_uso “inteligente” de energia. Descricao: ©] ¥" planejamento da Aquisiao do Sistema. ¥ selegio do fornecedor e sistema, ¥- planejamento da instalagso. ¥ instalago (considerar o plano do projeto). Impactos Positivos ¥ Economia a longo prazo. Impactos Negativos ¥_Maior desembolso atual. Um exemplo de preenchimento da solicitacéo de mudanga pode ser visto ane a OP panecalsta Hidrbulca através do caso projeto Casa Eduardo & Ménica. i a wien 2 cv 1 semana ¥_ Equipamento Y Instalaggo Eduardo e Ménica, ao longo do desdobramento dos pacotes pela equipe de Ce vacua engenharia, delegaram algumas questdes técnicas e depois perceberam que o sonho ee ginal da casa sustentavel estava ameacado. Ménica tinha sonhado que sua casa teria energia solar, cisterna para guardar 4gua da chuva, telhado branco, sistemas hidréulicos que priorizassem o consumo eficiente da 4gua, entre outros itens que tinha pesquisado. No entanto, depois da reunido inicial com os projetistas, ndo fez o acompanhamento dos projetos técnicos e descobriu que varios itens nao haviam sido incorporados. Ja durante a construcao da casa, Eduardo e Monica decidiram que fariam as al- teragdes de escopo necessérias para alcancar 0 sonho da casa ecolégica, que havia se perdido na fase de projeto. Eiibora soubessem que por vezes essas alterac6es trariam impactos nos custos no cronograma do projeto, estavam certos dos retornos futuros. ¥ Razoavel Impacto no escopo/objetivos do projeto ¥ Armudanga altera o sistema hidraulico/elétrico ¥- Serdo necessarias adaptagées e portanto planejamento para instalagao Documentacéo de Suporte ie Y_ Muita, dada a etapa da obra “Y_ Manual do equipamento e documentos de garantia do sistema to peo a Aprovacées : Patrocinador Gerente Modelo Engenharia, Arquiteturae | ~ Ménica Eduardo Construsio S/C Lida. = | He Figura 5.5 Solicitagdo de mudanga de escopo. an Hl H 1 rR :08 sstio. je . e Rabechini Jr. | (00 Fundamentos em gestéo de proetos * Carvalho y tay Zz Gestdo do escopo do projeto 101 | He lg Com as solicitacés das mudangas em maos, o gerente de projetos e sua equipe devem fazer uso de um sistema de controle de mudangas, analisando caso proceso, os quais nés podemos geiiericamente nos referir como uma “coisa”, passam acaso no intuito de fazer a triagem das mudancas mais importantes. por um ciclo de vida, do nascimento até a morte. No inicio é somente uma ideia. Entdo é dada alguma definicao sobre como, no final, essa coisa ficaré parecida. Entao f vém os estagios de desenho ou redesenho, em que o produto, servico ou proceso ; é desenhado. Apés completar esse estdgio, o desenho serd construido, testado e instalado. O préximo estagio é a producao. E, quando a coisa nao é mais necessaria, | Um sistema de controle de mudancas deverd ajudar 6 gerente a responder as seguintes questées, entre outras: ' ae e | a) quais as principais mudangas? ela é aposentada, completando 0 ciclo de nascimento e morte. » 3,Um projeto pode abranger todos estes estagios: definir, desenhar, instalar, man- tere entZo aposentar, ou pode abranger somente um ou mais estégios. E importante para o seu time conhecer quais estagios do ciclo de vida de seu produto, servico ou proceso esto inclufdos no seu projeto. Por exemplo, digamos que vocé esteja en- volvido com um projeto para desenhar um novo servico. E esperado que vocé faca uma pesquisa de mercado ou isso jé foi feito anteriormente? E esperado que vocé 1 simplesmente desenhe o servico ou vocé deve treinar os empregados também? Saber i onde comegar e acabar coloca uma cerca em volta do escopo do seu projeto que ajuda voéé'a fazer o que é necessdrio ~ nem mais, nem menos. ‘A préxima cerca que vocé precisa levantar ao redor do seu escopo é a cerca do processo. Quais processos esto inclufdos como parte do seu escopo e quais esto de fora? Os processos incluidos sao aqueles que produzirao os produtos ou servicos a serem entregues pelo projeto. Identifique esses processos. Os representantes desses processos devem ter representantes no time. Existem também processos que impacta- 140 0 projeto, mas que nao esto inclusos no escopo. Sao os processos de suprimentos. h Identifique os processos-chave de suprimentos que afetardo 0 seu projeto. Onde for I necessaria, pega a participagao de um representante no time ou a designagao de um } representante para fazer a coordenaco. Ento, existem os processos que serdo afe- } tados pelo projeto. Sao os processos do cliente. Identifique estes processos também. | Eles nao sao parte do seu projeto, mas impactam a entrega dos produtos/servicos do ! Para contribuir coms 0 entendimento dos conceitos de escopo em projetos | projeto. Eles podem precisar de um representante no time também. Y sera retratado um caso bastante interessante publicado na revista PM Network, Agora vocé tem as cercas ao redor de todo 0 escopo ~ definindo o que est4 dentro fi em abril de 1998, As autoras (PAULA; TATE, 1998) valorizam a 4rea de conheci- eo que est4 fora -, voce precisar4 considerar as superposicées no escopo. A Karen i ih mento de escopo e, através do texto Fencing in project scope, tracam um panorama que ajuda os gerentes de projetos no delineamento das fronteiras dos projetos. b) quais eu posso fazer? ©) quais eu nao posso fazer? d) de quantos recursos eu preciso? e) qual o prazo ideal? Um sistema de controle de mudangas dever4, portanto, ser capaz de avaliar cada solicitacao de mudangas e fornecer informac6es que dar4o suporte aos de- jj cisores quanto 4 aceitagao ou rejeicao da mudanga. | As mudangas aprovadas dever4o passar pelo processo de planejamento do projeto e seus elementos devem ser incorporados ao plano geral de gerencia- | mento de projetos. Nesse ponto, o gerenciamento de mudancas faz uso das praticas de geren- |: ciamento do projeto e “volta” a buscar novos focos de possiveis alteragées em projetos, dando continuidade a todo o processo. 5.6 Caso: cercando o escopo do projeto i importante de um produto, visando reduzir os custos de manufatura. O time traba- thou 18 meses e finalmente atingiu seu objetivo. Era desconhecido do time que um ti outro time de projeto, que estava trabalhando para reduzir o custo total do produto, ih havia decidido eliminar essa parte no desenho do produto! O primeiro time atingiu A seguir, uma tradugio livre do texto de Paula e Tate (1998). Qual é 0 componente mai: importante de um projeto? Voce disse escopo? Acer- tou. O escopo de um projeto o-fine o que ser feito - quais produtos ou servicos sero entregues. Tudo o que ven depois disto - quem participaré do time do projeto, quanto tempo levara, quanto esforco serd necessdrio e quanto custard - depende do escopo do projeto. Entdo, antes que vocé e seu time escrevam uma descri¢ao do escopo, decida sobre as fronteiras desse escopo: o que est dentro e o que est4 fora do projeto. A primeira fronteira ou cerca a ser considerada so as cercas dos est4gios do ciclo de vida. O que é um estdgio do ciclo de vida? Bem, todo produto, servigo ou seu objetivo: reduzir o custo daquela parte do produto, mas aquilo nao interessava mais. Aquela parte do produto virou historia. Nao deixe que isso aconteca a vocé. Descubra como outros projetos, planejados ou em execu¢do, podem impactar o seu Projeto. Designe alguém como representante do seu projeto nesses cues Projetos Para que vocé possa coordenar seus esforcos. / Uma vez que vocé tenha estabelecido toda a sua cerca, vocé estard pronto para escrever a descric4o de seu escopo. Descreva, em detalhes, as caracteristicas e funcdes do produto/servico final a ser entregue. Descreva os critérios de aceitagao por parte do cliente desse produto/servico final. E descreva as fronteiras desse escopo. Consiga t trabalhou num projeto uma vez, que havia sido montado para redesenhar uma parte H i 0 “de acordo” de todos os interessados, em especial do cliente e do patrocinador, ou T a seja, 0 que voc® esta responsdvel para produ. Entao serd a hora de seguir adiante e planejar suas necessidades de'recursos. i | | 102. Fundamentos em gestfo de projetos * Carvalho e Rabechini J ' | Questées para reflex4o e discussao | 1. 2. Vocé concorda que na WBS nao devem estar mencionadas as atividades do projeto? Vocé foi convocado para administrar as proximas olimpiadas da escola. Monte uma WBS que represente todo o trabalho necessirio para realiza-la. Faca uma WBS de uma festa de casamento: até 0 32 nivel. 1 Veja os exemplos de WBS de um restaurante, propostos por Globerson (2002) e classifique o critério de decomposicao como orientado a: subsistemas, geografia, funcdes ou fases do ciclo de vida. a) Projeto do ; Restaurante | | ins — b) Projeto do Restaurante Marketing 10. Gestéo do escopo do projeto 103 Projeto do Restaurante Especificagao das necessidades Design do produto Quais requisitos deve possuir um sistema de controle de mudangas de pro- jetos? Considere projetos suscetiveis a varias mudancas. Para a WBS solicitada no exercicio 2, vocé consegue extrair 0 custo do pro- jeto? Quais informacées so possiveis de extrair de um pacote de trabalho? Faca uma WBS representando os esfor¢os que vocé tera de despender para conseguir mais um titulo (graduacao, pés-graduacao etc.). A declaracao de escopo de um projeto requer o conhecimento da organiza- ¢do em que ele est inserido. Pense na empresa em que vocé trabalha e no projeto atual em que vocé estd envolvido. Como seria uma boa declaracao de escopo? Liste as principais ag6es que vocé tomaria ao saber das mudancas no escopo de seu ultimo projeto que nao foram tomadas. 6 Gestao de tempo do projeto Aquisigoes Qualidade Neste capitulo, sera tratada a questao do gerenciamento do tempo dos projetos. Apés esta unidade, o leitor tera condic6es de responder as seguin- tes questGes: a) Quais os processos que suportam o gerenciamento do tempo do projeto? b) Como elaborar uma lista de atividades e estabelecer sua sequéncia? ©) Como elaborar boas estimativas de prazo e recursos? d) Quais os principais aspectos para definir a duracao do projeto e os marcos temporais associados as entregas (deliverables)? e) Como controlar o cronograma do projeto? Gestfo de tempo do projeto 105 iz Uma das caracteristicas mais énfatizadas quando discutimos o conceito de projetos, no Capitulo 2, foi stra temporalidade. Dessa forma, gerenciar 0 tempo em projetos é crucial. | 4.: + ‘ » Mas vocé leitor também deve’ se ‘perguntar se um projeto é também por caracteristica singular, como prever adequadamente seu prazo, se de alguma forma ele é tinico e demandar4 criatividade para que seja concluido com sucesso. Domenico de Masi, em seu livro O écio criativo, revela uma preocupacao com essa questo, que pode ser resumida no seguinte pardgrafo, que se refere as condigdes étimas para o desenvolvimento do trabalho criativo: “As condigées ideais, na minha opinido, so aquelas descritas por Platao em O Banquete: comodidade, um grupo de amigos criativos, paixao pela beleza e pela verdade, lideranga carismética, tempo e disposigéo, sem a angistia de prazos ou vencimentos improrrogdveis” (DE MASI, 2000, p..220). & claro que no cotidiano dos projetos e contratos as condi¢ées. ideais,ra- ramente estdo presentes. Portanto, resta aos gerentes de projetos jogar com maestria, respeitando os vinculos, sem, contud, fugir dos desafios de buscar 0 melhor resultado possivel. ae ah | 6.1 Introdugao © Project Management Institute (2004) dedica um capitulo para discutir os processos necessdrios para uma boa gestdo do tempo do projeto, visando garantir sua conclusdo no prazo contratado. Contudo, para uma boa gestao do tempo, é necessario que a gest4o do escopo tenha sido bem conduzida, pois todo o gerenciamento de prazos é balizado pelas. decisdes de escopo tomadas. Se retornarmos ao Capitulo 2, o leitor poder re- lembrar do triangulo dos objetivos primarios ~ escopo, prazo e custo - e de como qualquer alteraco em um desses elementos afeta os demais, comprometendo 0s resultados do projeto. : Os processos considerados pelo PMBoK® (PMI, 2008) no gerenciamento do tempo do projeto sao: a) Definir as atividades: identificacdo das atividades especificas que devem ser elaboradas para se produzirem os produtos/servicos do projeto, bem como de suas varias entregas (deliverables) identificadas na WBS. b) Sequenciar as atividades: identifica¢ao e documentacio das relacGes de dependéncia entre as atividades do projeto. 106 Fundamentos em gestdo de projetos + Carvalho e Rabechin J. c) Estimar os recursos das atividades: estimativa dos,recursos necessarios para a elaboracao de cada atividade. : d) Estimar as duragées das atividades: estimativa da quantidade de perio- dos de trabalho que sero necessdrios para a implementacao de cada atividade. 9 e) Desenvolver 0 cronograma: andlise da sequéncia das atividades e res- pectiva duraco, considerando os recursos necessdrios para elaborar 0 cronograma do projeto. f) Controlar o cronograma: controle das mudangas no cronograma do Pprojeto. E sempre bom lembrar que esses processos interagem entre si e com as demais dreas de gerenciamento de projetos, em especial escopo e custo. Desde a 3 versio do PMBoK® (PMI, 2004) ha um processo a mais na ges- to do tempo com relacdo 4 versao de 2000, que é a estimativa dos recursos das atividades. Essa é uma evolucio interessante, pois a determinaco dos tempos esta intimamente ligada aos recursos que serdo utilizados. Por exemplo, se Eduardo e Ménica quiserem estimar o tempo necessario para concretar a laje de sua casa, precisam decidir quais recursos terao disponiveis. Eles utilizardo uma empresa especializada com caminhdo betoneira ou os pedreiros da obra fardo o servico utilizando um carrinho de mao e preparando eles mesmos areceita do concreto? Nada melhor que essas quest6es sejam respondidas antes da determinacao do tempo necessario para desempenhar essa atividade, como propée a nova verso do PMBoK®. 6.2 Desdobrando a WBS em atividades do projeto 2 Vamos buscar nas areas de escopo e de integracao as informacées necessarias para definirmos as atividades do projeto. A Figura 6.1 apresenta o fluxograma das entradas e saidas dos processos das areas de gest4o do tempo ou prazo. Depois da area de integracao, é a area de gestao do tempo ou do prazo que mais interage com os processos de outras areas do PMBoK®, incluindo comunicagées, risco, custo, recursos humanos e a propria integracao. ° Gestio de tempo do projeto 107 a —— = z a Defnigt | runoseroieo| _ Bestéo | 3 s [fase roi | a = Fscopo Atividade de Integracto sta de Atvidades tstade Atibutos| Wes Ustad Marcos (aWalzado) : Plano de Pojto Sequénciar as ‘etulzado) Entradas pei de eee Organizacionais unos | ds plano de Ecop0 (atualizado) Politicase InformacBes Entradas Histrica Rede Onganizacionais ||~cacadario do pwoiwo Dsponiiiade de Recieos Requisitos de Recurso ~atividades |__alendévio _} Usta de atividades Estimativas de custo | : DuroiesEsimads > Usted Athidades otuaza) lita de arto (tulad) + . Plano de Pr Registro de fe Deservowerss] Mala "+ _Cronograma Pelee eee Programagéo de Projeto Requisitos de Recursos, Recursos Organizacionais {atualizado) Controlar eigen nt [Cronbgtama: Requisitos de Mudanca Aprovados Fonte: Adaptada de PMI (2008). Figura 6.1 Proceso de definigdo e sequenciamento das atividades. 108 Fundamentos em gestdo de projetos + Carvalho e Rabechini J. fips Como vimos no Capitulo 5, a WBS é a representac4o do processo de de- sagregacdo e integracdo do trabalho do projeto; nela encontramos as entregas (deliverables) e os pacotes de trabalho, que precisamos agora detalhar até o nivel de atividade. Portanto, o processo de definicao das atividades do projeto é o ultimo nivel do processo de decomposi¢ao do projeto, ou de parti¢o, como preferem alguns autores. Dessa forma, atividade pode ser definida como uma unidade de traba- Iho indivisivel no contexto do projeto, em que recursos, métodos de execugio e controle, bem como tempos, sdo conhecidos. E claro que a palavra indivistvel se refere a um dado Projeto, ou seja, para aquele projeto nao haverd mais particdes. Destaca-se, no entanto, que se dermos a mesma WBS para dois gerentes diferentes, eles chegardo a listas de atividad diferentes. - Verifica-se, na pratica, que gerentes novos tendem a decompor 0 projeto em mais atividades que o gerente sénior. Isto ocorre porque esses gerentes ainda estéo desenvolvendo um repertério de experiéncias, e precisam chegar ao nivel de detalhe de mais facil mensurac4o, para poder estimar recursos e duragdes adequadamente, ou seja, utilizam com maior frequéncia estimativas bottom-up, conforme veremos mais adiante neste capitulo. Por isso, os gerentes de projetos podem utilizar especialistas para auxilid-los na decomposi¢ao do projeto em atividades. Além disso, as informagées hist6ricas, tais como quais atividades foram requeridas em projetos anteriores similares, podem ser de grande valia. Algumas organizaces elaboram modelos (templates), com uma lista de atividades, ou parte dela, baseada em projetos anteriores e/ou recomendagio de especialistas, que podem ainda incluir tipos de recursos, com 0 objetivo de facilitar e de alguma forma padronizar o trabalho dos gerentes de projeto. A Figura 6.2 apresenta um template para definic4o de atividades. Gestdo de tempo do projeto 109 Pacote de Trabalho ~ Nivel Atividade Cliente: sunes PAB Projet Thad Atividade: Responsdvel: Descri¢do: fic Entradas: Recursos: ; y a Figura 6.2 Modelo (template) para definigéo de atividade. Da uot a __ Além'das informacées relativas ao escopo, necessitamos das infotinagbes disponivéis no plano do projeto e no project chart, conforme discutido no ge- Tenciamento da integracao, no Capitulo 4’ Embora neste moméiito estejamos buscand6’o detalhe, no significa que podemos perder de vista os objetivos do Projeto, suas restricées e premissas. °°" me ee Jide anion OM be Meo can 110 Fundamentos em gestio de projetos * Carvalho ¢ Rabechini Jr. Ao final da etapa de defini¢ao das atividades, o gerente de projeto tera de- senvolvido a lista das atividades, de seus atributos e de seus marcos (milestones), Devem constar da lista das atividades todas aquelas necessdrias para a conclu- s&o do projeto, descritas de forma clara para garantir que os membros da equipe entendam como o trabalho deverd ser feito. E importante lembrar que essa lista é uma extensdo da WBS, mantendo a mesma codifica¢ao. “ Complementa essa lista a lista de atributos das atividades, que fornece uma descrigo detalhada de cada atividade. O nivel de detalhe na descri¢ao dos atri- butos varia bastante, dependendo da complexidade do projeto. Geralmente, essas listas incluem os seguintes atributos: premissas; restricdes; pessoal responsdvel; local fisico onde ser desenvolvida a atividade; bem como a respectiva codificagao na WBS (PMI, 2008). . Finalmente, a lista de marcos (milestones) identifica todos os marcos tem- porais associados as atividades do projeto e indica se eles sao demandas contra- tuais mandatérias ou se s4o opcionais. Essas trés listas fazem parte do plano do projeto, discutido no Capitulo 4 (Gest&o da integrac4o do projeto). * * 6.2.1 Sequenciando as atividades O processo de sequenciamento das atividades “permite identificar e docu- mentar as relacdes de dependéncia entre as atividades” (PMI, 2008). i Destaca-se, no entanto, que, assim como no caso da decomposicio, a defini- 40 de relagdes de dependéncia entre as atividades pode gerar bastante discussao entre os membros da equipe. Para ilustrar que tipo de debate pode surgir, pode-se comparar um curriculo de engenharia de uma década atras com os atuais. Nos curriculos antigos era comum que as disciplinas de um semestre fossem con- sideradas pré-requisitos para as dos semestres seguintes. Consequentemente, um aluno que ficasse em recuperacdo em uma disciplina teria muita dificuldade para se formar no perfodo regular. Ao longo das reformas curriculares, varios dos pré-requisitos foram questionados, e depois de exaustivos debates entre os professores, muitos foram retirados. Atualmente, os curriculos apresentam poucas relacdes de dependéncia mandatérias, o que permitiu que varios cursos fossem feitos em paralelo. E importante observar que existem diferentes tipos de dependéncia entre as atividades. O PMBOK® estabelece trés tipos de dependéncia, quais sejam: manda- téria (mandatory), arbitradas (discretionary) e externas (PMI, 2008). As dependéncias mandatérias seguem uma ‘légica rigida, representando limitag6es inerentes a0 trabalho a ser realizado, como no caso de uma construgao, em que é manda- trio que a fundaco seja feita antes de levantar a estrutura. Jé no caso das de- pendéncias arbitradas, segue-se uma légica soft ou preferencial, que é definida - Gestéo de tempo do projeto 111 pela equipe de projeto, com base nas melhores praticas ou na experiéncia de projetos anteriores ou particularidades do projeto. Finalmente, as dependéncias externas envolvem relacionamento entre atividades que fazem parte do escopo do projeto e aquelas atividades que nao fazem parte dele, geralmente envolvendo uma terceira parte, tal como no caso de uma atividade dependendo da entrega de um. material comprado. O fundamental para o gerente é ponderar quanto a real necessidade do esta- pbelecimento de vinculo de dependéncia entre as atividades, pois elas devem ser sequenciadas de modo a elaborar um cronograma realista e vidvel, sem amarragdes desnecessarias, que aumentarao’‘a dura¢ao do projeto como um todo. 6.2.2 Representacdo'do projeto Existem varias formas de representacao do projeto, dentre elas destacam-se: 0 Diagrama de Precedéncia (PDM — Preceding Diagramming Method); o Diagrama de Flecha ou Arcos (ADM - Arrow Diagramming Method) e o Diagrama Condicional (CDM - Conditional Diagramming Method); 0 Diagrama de Gantt; o Diagrama de Marcos (milestones) e o diagrama de barras ou histograma de recursos. a) Método de Diagrama de Precedéncia (PDM) oN O método mais utilizado na maioria dos softwares disponiveis para gesto de projetos € 0 diagrama de precedéncia (PDM — Preceeding Diagramming Method), que representa as atividades nos nés (AON - activity-on-node), por retangulos, e as relacdes de precedéncia sio estabelecidas nas setas. Essa forma de representacao também é'conhecida como método francés. A Figura 6.3 ilustra um Diagrama de Precedéncia, utilizando o software MsProject. “ A > B E+ C Inicio —>| Fim Die > OF Figura 6.3 Exemplo do Diagramas de Precedéncia. “ As precedéncias, que neste modelo s4o representadas nas setas, podem ser de varios tipos: so doom * Término/inicio (finish-to-start): 0 inicio do trabalho ‘da sucessora dep de do término da predecessora. ° Oe wig 112 Fundamentos em gestio de projetos + Carvalho ¢ Rabechini Jr * Término/término (finish-to-finish): 0 término do trabalho da sucessora depende do’ término | da predecessora. * Inicio/inicio | (start-t to: start): 0 inicio do trabalho da sucessora depende do inicio da Bredecé: Sora. : * Inicio/término Gtart-to-fir inish): o término do trabalho da sucessora de- pende do inicio da predecessora. ( b) Método de Diagrama de Flecha/Arco (ADM - Arrow Diagramming Method) Embora a maioria dos softwares no utilize esse tipo de representacio, ela ¢ de grande importancia quando solugées customizadas forem desenvolvidas, pois auxilia na programago, uma vez que utiliza as regras de programacao em grafo. O método do Diagrama de Flecha ou Arco (ADM ~ Arrow Diagramming Method) representa, como o proprio nome sugere, as atividades nas flechas/arcos (AOA ~activity-on-arrow) e as relac6es de precedéncia so definidas nos eventos, sendo apenas do tipo término/inicio. Essa forma de representa¢4o também é conhecida como método americano. A Figura 6.4 ilustra um Diagrama de Flecha/Arco. Figura 6.4 Exemplo de Diagrama de Flecha. Gestio de tempo do projeto 113 Para a elaboracao desse tipo de representacio, algumas regras devem ser seguidas, conforme descrito na Tabela 6.1. qabela 6.1 Regras para elaboragdo do ADM. Regra lustragao Um eventoé considerado atingido quando todas as atividades que convergem para ele A forem conclufdas, do tipo término/inicio. c c) ¥ Evento Atingido Existem sempre um Evento Origem e um Evento Objetivo/Destino. Todas as atividades que nao tém precedéncia partem do Evento + Origem. 5: Lope oe PM Evento Origem Evento Objetivo] Entre 2 eventos sucessivos deve existir somente Uma atividade. Atividades Fantasmas ou Ficticias néo consomem tempo nem recurso e sao utilizadas| quando as relacées ldgicas de dependéncias nao podem ser representadas corretamente com as setas das atividades normais. v Atividade Ficticia Nao devem existir loops, desvios condicionados ou ciclos fechados. c) Método do Diagrama Condicional (CDM - Conditional Diagramming Method). Esse método de representacdo assemelha-se ao Diagrama de Precedéncia (DM), conforme ilustrado na Figura 6.3. No entanto, nessa forma de représen- tacdo sao permitidos loops e desvios condicionados, que tanto no PDM ‘cortio no ADM nio sao permitidos. 1A sage Essa forma de representacao est4 geralmente associada ao ‘uso de modelos de sistemas dinamicos ou do GERT (Graphical Evaluation and Review Technique), que serao discutidos juntos no tépico relativo as técnicas de programacao. 114 Fundamentos em gestdo de projetos * Carvalho e Rabechini J. Reprovado ‘Bvaliacao> Se aprovado, D. Se nao, B. Aprovado Figura 6.5 Exemplo de loop em um Diagrama Condicional. 6.3 Desenvolvimento do cronograma ;, an a Esta é uma das etapas cruciais da gestao do projeto: chegar a um cronogra- ma factivel, respeitando os marcos temporais previstos em contrato e sujeitos ds limitagées de recursos. Para elaborar um bom cronograma é preciso constante intera¢ao com as areas de aquisicées (terceiros), recursos humanos, custos ¢ risco, conforme ilustra a Figura 6.6. ': Gestio Recursos woe de 7 ; Aquisig6es |e Calendario 2 Recursos/atividade, on Lista atualizada Gestdo de e Calendario Gestéo - Estimativas da oe de Cust, Recursos/atividade Integragao a Lista atualizada Custos Gestio de Riscos — Registro de Risco ‘Cronograma atualizado : Fonte: Adaptada de PMI (2008). Figura 6.6 Processo de estimativas e desenvolvimento do cronograma. Gestéo de tempo do projero 115 Aliando boa interac4o com as demais areas e processos do projeto, o gerente deve dominar as ferramentas de programagao e os softwares disponiveis para a elaboracdo de um cronograma exequivel para 0 projeto. Existem varias técnicas que auxiliam a equipe do projeto na elaboracao da sua programaco do projeto e gera¢ao do cronograma, dentre elas as mais di- fundidas sao: * Grafico de Gantt. * Critical Path Method (CPM). + Program Evaluation & Review Technique (PERT). O Grdfico ou Diagrama de Gantt é uma das técnicas mais antigas e mais uti- lizadas para elaboracao de cronogramas de projeto. Em meados de 1917, Henry Gantt desenvolveu um diagrama que mostrava as atividades em uma escala de tempo, marcando a duracdo planejada face ao andamento da atividade, conforme jlustra a Figura 6.7. A principal vantagem dessa técnica é a facilidade de compre- enso; contudo, nao é adequada para projetos muito complexos. rojeto = Construir uma Casa ».[Patividade y= 1-2 Fundacao 1-3 Compra 2-3 Telhado 2-4 Acabamento 3-4 Paisagismo Fonte: Adaptada de Heizer, J. e Render, B. (1999). Figura 6.7. Exemplo de Diagrama de Gantt. Seniélhante ao Diagrama de Gantt, o diagrama de marcos apresenta as ativi- dades em uma escala de tempo, mas a énfase é dada aos marcos (milestones) do Projeto, sendo uma boa ferramenta para relatério gerencial para apresentagao aos stakeholders do projeto, conforme ilustra a Figura 6.8. ern ” | 116 Fundamentos em gestio de projetos * Carvalho e Rabechini Jr 4] Data 1 : atual ne sscnafitividade Jan] Fev] Mary Abe [maid] Jund| sul Subcontratos Assinados av Especificagées Finalizadas a b Projeto Revisto za : Subsistema Testado Pz | Primeira Unidade Entregue a Plano de Producdo Completado’ Sed Existem muitas outras formas de se apresentarem informagées do projeto num Diagrama de Marcos. PlanejadoA Realizadow Fonte: Adaptada de PMI (2008). i Figura 6.8 Exemplo de Diagrama de Marcos. As técnicas de programacdo em rede, PERT e CPM, surgiram de diferentes maneiras no final da década de 1950. O PERT - Program Evaluation & Review Tech- nique - foi desenvolvido por Lockheed Corporation e pela empresa de consultoria Booz, Allen & Hamilton para o escritério de projetos especiais (Special Projects Office) da Marinha americana (US Navy), em meados de 1958. O projeto subma- rino/missil Polaris foi a primeira aplicagao do PERT. Esse método rapidamente se difundiu no ambiente de projetos de P&D. O CPM - Critical Path Method — foi desenvolvido praticamente na mesma época por Morgan Walker e James Kelly para a Du Pont, difundindo-se principalmente nos setores de construcao e de processos industriais (STHUB et al., 1994; MEREDITH; MANTEL JR., 1995; FORSBERG et al., 2000; KERZNER, 2000). Estes dois métodos — PERT e CPM - possuem varias similaridades. Os passos comuns ao PERT e CPM sao: 1. definir todas as atividades significativas ou tarefas; 2. desenvolver os relacionamentos entre as atividades (decidir precedén- cias); ue ai 3. fazer a représenta¢ao em rede conectando todas as atividades, utilizando as técnicas de representacao do projeto discutidas no item 6.2.2; 4. atribuir estimativas de tempos e recursos para cada atividade; 5. calcular o caminho mais longo da rede - caminho critico. A principal diferenca est4 na forma em que as duas técnicas tratam as esti- mativas de tempo. O CPM adota apenas uma estimativa de duraco por atividade para fazer a programagio e o PERT usa um sistema estocdstico mais complexo Gestio de tempo do projeto 117 paseado em trés estimativas, que sero utilizadas para determinar a data mais provavel para o término do projeto. rib SRUMBT 6.0% woetbile’. ent : 6.3.1 -Programagao utilizando o CPM ., ..:-, 7 Conforme comentado, o cPM utiliza uma tnica estimativa de duracao para cada atividade do projeto. Essa estimativa pode ser obtida de varias maneiras pela equipe do projeto. A forma mais utilizada é o julgamento por especialistas, que tém experiéncia no planejamento e estimativa de recursos. Em geral, sao pessoas que ja executaram varios projetos similares e possuem bom dominio técnico do tipo de projeto em questao. Nao obstante, fazer estimativas é uma tarefa 4rdua, com elevado grau de in- certeza, mesmo para os mais experientes especialistas. Existem inimeros fatores que podem influenciar nas estimativas, tais como o nivelamento de recursos, discutido no Capitulo 9. Além disso, em geral existem varios métodos alterna- tivos para realizar uma mesma atividade, que devem ser considerados. Antes de estimar os recursos e as durag6es, é necessario identificar e avaliar as alternativas, disponiveis para a realizacio da atividade. Algumas decisdes frequentes sao'as de fazer'em casa ou terceirizar e utilizar trabalho manual ou automatizar, ambas com impacto nas estimativas. Voltemos ao exemplo dado no inicio deste capitulo para estimativa da ativi- dade de concretar a laje. Eduardo e Ménica teriam de decidir qual das alternativas adotariam para executar essa atividade, quais sejam: +” Alternativa 1: concretagem com uma empresa especializada, que uti- lizaria caminhio-betoneira a um custo de R$ 2.240,00 e duracao de 3 “horas; ou +, Alternativa 2: utilizar a equipe da obra para concretar manualmente a laje, com os quatro pedreiros preparando o concreto e 2 auxiliares “transportando e espalhando a um custo de R$ 1.476,00 e duragao de 8 horas. Para a elaboracdo de estimativas, a equipe pode ainda pesquisar fontes de dados historicos e dados secundarios fornecidos por empresas especializadas. Existem diversas publicagdes que fornecem dados estatisticos periodicamente, contendo informagdes sobre consumo de recursos por unidade produzida ¢ custos unitérios atualizados de diversos recursos, tais: como materiais, équipamento e hora-homem por categoria, estratificados por regido geogrdfica. “No Brasil, por exemplo, podem ser obtidos dados do setor téxtil nos anudrios do IEMI; no setor de construco, existem diversas revistas especializadas que fornecem indicadores, entre outros exemplos. at HY bas G8 118 Fundamentos em gestio de projetos + Carvalho e Rabechin J. O PMBoK® destaca que, para recursos e dura¢Ses, podem-se utilizar estima- tivas bottom-up ou top-down por atividade (PMI, 2008). Quando uma atividade é muito complexa e nao pode ser estimada com grau razoavel de precisdo, pode-se decompor a atividade em um nivel maior de detalhe. Parte-se das estimativas de necessidade de recursos no nivel mais detalhado, e essas estimativas sao agre- gadas entao para cada um dos recursos da atividade. Em geral, essas estimativas so mais trabalhosas, mas também mais precisas. Tabela 6.2 Exemplo de estimativa bottom-up. fl Atividade Unidade | Quantidade Custo Total | Alvenaria de tijolo macigo m? 100 1.417,60 Recursos | Unidade | Producao Total Prego Unit. Custo Total ~ Pedreiro h 2hm?} == 200h 4,00 800,00 Ajudante h Bh/m? 300h 2,00 600,00 Cimento. kg 0,025 kg/m? 2,5 kg 0,40 1,00 Areia mm 0,0083 m’/m?} 0,83 m? 20,00 16,60 As estimativas top-down partem de uma atividade andloga como base para a estimativa da duracao da atividade futura. Esse tipo de estimativa é utilizado quando as informacées sobre 0 projeto sdo limitadas e pouco detalhadas, em geral nas primeiras fases do ciclo de vida do projeto. A saida do processo de estimativas é uma descric4o dos tipos e das quantida- des dos recursos requeridos para cada atividade em um pacote do trabalho, bem como sua dura¢do. Esses recursos requeridos podem entao ser agregados para determinar os recursos e as durag6es estimados para cada pacote do trabalho, bem como para os demais niveis da WBS do projeto. Vencida a etapa de estimativas de recurso e duracées, j4 é possivel fazer a pro- gramac&o da rede do projeto e determinar quando os recursos serao necessirios. O CPM utiliza a légica de programacio para frente e para tras ao longo. da rede do projeto, para a determinacao do caminho critico. Dessa forma, so ob- tidas as datas mais cedo de inicio e as datas mais tarde de término de todas as atividades do projeto. . Na programagaio para frente, que obtém a data mais cedo de inicio de cada ativi- dade, parte-se do evento origem e determina-se a primeira data de inicio de cada evento da rede do projeto. Essa data representa o caminho de maior dura¢o entre Gestio de tempo do projeto 119 aorigem do projeto e um determinado evento da rede. Para obter essas datas do cronograma do projeto, deve-se adotar a seguinte equagao (STHUB et al.; 1994): r Equagao 6.1 5 em qui 1, €a data mais cedo dos eventos i predecessores imediatos; d,é a duracao das atividades (i,j) predecessoras imediatas. max; (t, + d;), para todas as atividades (i,j) definidas E importante ressaltar que todas as atividades que nao tém precedéncias partem da origem, portanto t, = 0, ou seja, a data mais cedo do evento origem, evento'l, é zero e sera utilizada para todas as atividades sem precedéncia. Além disso, para calcular a data mais cedo do evento j (t,), a data mais cedo de todas as atividades que chegam ao evento j devem ser computadas e somadas as suas duracées, assumindo dentre todos os caminhos o de maxima durac¢ao. Lembremos da regra de formacdo do diagrama ADM, que diz que um evento s6 é considerado atingido quando todas as atividades que convergem para ele forem concluidas, portanto, se nao considerarmos o caminho de maior dura¢o, algumas atividades ainda estarao em desenvolvimento. Na programagiio para trds, percorre-se o caminho inverso, que obtém a data mais tarde de término de cada atividade, parte-se do evento término/objetivo do projeto e percorre-se a rede até a origem. O inicio da programago para trés é geralmente feito atribuindo-se, no evento término do projeto (evento n), data mais cedo igual 4 data mais tarde - t, = T,,. Contudo, se a data estipulada em contrato for maior que t,,, pode-se adota-la como T,,,. Ja no caso oposto, nao existe programacio possivel, pois se t, é inferior A data contratual, nao serd possivel completar o projeto a tempo. Para obter essas datas do cronograma do projeto, devem-se adotar as seguintes equac6es: Equagao 6.2 T,= min, (I; + d,), para todas atividades (i}) definidas em qui T, éa data tarde dos eventos i; d; € a duraco das atividades (ij). 120 Fundamentos em gestio de projetos + Carvalho e Rabechini J. Uma vez calculadas as datas cedo e tarde de cada evento, é possivel determi- nar a primeira e a ultima chance de programacao de cada atividade, bem como calcular as suas folgas (slack ou float). Quatro datas so importantes para elaboracao de um bom cronograma'e devem ser calculadas para cada atividade: * PDI, - Primeira Data de Inicio, que representa a primeira data em que a atividade (i,j) pode iniciar sem violar nenhuma relacAo de pre- cedéncia. PDI; = t, ie * PDT, ~ Primeira Data de Término, que representa a primeira data em que a atividade (i,j) pode terminar sem violar nenhuma relagao de precedéncia. PDT, = PDI, + dy = t, + dy Inicio, que representa a ultima data em que a iciar sem atrasar © projeto. UDI, = UDT, - 4, = T, - di * UDT,,- Ultima Data de Término, que representa a tiltima data em que a atividade (i,j) pode acabar sem atrasar 0 projeto. UDT, =7, Com base nessas datas, é possivel calcular as folgas do projeto. A gestao das atividades que possuem folga é de vital importancia para o bom andamento do cronograma do projeto, pois é nessas que podemos mexer sem atrasar 0 término do projeto. Geralmente, calculam-se dois tipos de folga, a folga total e livre de cada atividade do projeto, conforme ilustra a Figura 6.9. Figura 6.9 Célculo das folgas livre e total. Para obter essas datas do cronograma do projeto, deve-se adotar a seguinte equacao: Gestao de tempo do projeto 121 g Equacao 6.3 . FI; = UDI, ~ PDI; = UDT;,- PDT; = em qi ¥ FT, - Folga total da atividade (i,j) Equagao 6.4 FL=t,- (+4) em que: FL - Folga livre da atividade (i,j) FLy = PDI, (PDI; + d;) Equaso 6.5 FT2FL, A folga total equivale 4 quantidade de tempo em que a programacio da ati- vidade pode ser atrasada em relacdo a sua primeira data de inicio sem atrasar 0 término do projeto (PMI, 2008). O conceito de folga total considera todo o tempo disponivel para realizar a atividade (T, - t,) e desconta-se a sua duracio (d,). A folga livre equivale & quantidade de tempo em que a programagio da ativida- de pode ser atrasada sem comprometer o inicio na data mais cedo das atividades sucessoras imediatas (PMI, 2008). Portanto, no clculo da folga livre, assume-se que todas as atividades iniciam-se o mais cedo possivel. A Figura 6.10 apresenta um exemplo de célculo das folgas livre e total de uma atividade. (i> ‘ely UDI=11 PDIy=14 UDT}=19 °°" Cy YP PDT;=9 dis Fl=5, LFT=10} * Figura 6.10. Exemplo de céilculo das folgas livre e total. 122. Fundamentos em gestio de projetos * Carvalho ¢ Rabechini Jr Uma vez calculadas as folgas, é possivel determinar 0 caminho critico do projeto. Pertencem ao caminho critico as atividades que possuem a data cedo igual 4 data tarde (PDI = UDT) e nao possuem folgas. Nessas atividades nao existe nenhuma flexibilidade na programagao e qualquer atraso na realizacio dessas atividades resultara em atraso do projeto como um todo. Caso 6.1: quando a casa ficara pronta Eduardo resolveu utilizar as técnicas de programacao que aprendeu e resolveu’ fazer uma rede simplificada do projeto para testar seus conhecimentos. Para fazer a programacio, ele utilizou estimativas de duracdo fornecidas pelo engenheiro con- tratado para conduzir a obra. Ele sabia que o primeiro passo para construir uma representaco grafica era definir as atividades e estabelecer o tipo de dependéncia entre elas. Como sentiu que ainda nao dominava completamente as técnicas de representacao, resolveu fazer primeiro um exercfcio utilizando o primeiro nivel de sua WBS, pois assim teria uma rede mais simplificada que depois, mais experiente, ele aprimoraria. ~ Eduardo listou todos os elementos do 12 nivel da WBS e listou as precedéncias que julgou mandatérias, conforme ilustra a Tabela 6.3. Tabela 6.3. Precedéncias e duragdes do projeto de Eduardo e Manica. WBS - 12 Nivel Precedéncia Duragao (dias) ‘WBSO1. Servicos preliminares ——. 20 2 ‘WBSO2. Projeto ——— 40 ‘WBSO3. Construcao ‘WBS01;WBSO2 214 ‘WBS04. Sistemas ‘WBSO03 70 WBSO5. Acabamento ‘WBS04 142 WBS06. Servicos complementares ‘wes05 20 Com base nesses dados, a primeira representag4o feita por Eduardo foi um ADM, conforme Figura 6.11. Gestio de tempo do projets 123 486 das 16 mes) x Figura 6.11 ADM do projeto de Eduardo e Ménica. Em seguida, com base nos mesmos dados, Eduardo fez um PDM, con- forme Figura 6.12: Servigos ‘Construgao, ‘Sistemas | Acabamento Servigos complementares| ST grad + ofa | Togo 5 | van} Comlementars T7106 | 1178/06 11/9/06] 5/7/07. 6/7/07 [11/10/07] [12/10/07 28/4/08. 3974/08 [26/5/08 Ta 2 | 403 [17/7/06 8/9/06 Figura 6.12 PDM do projeto de Eduardo e Ménica. Ménica estudou bem as representacées do projeto feitas por Eduardo e, como sempre, identificou os pontos criticos: “— Eduardo, vocé percebeu que praticamente todas as sequéncias sao criticas? — Serd que todas estas precedéncias de fato s4o mandatérias? ~Vocé percebeu que desta forma dificilmente atingiremos nossa meta de 15 meses?” Estas perguntas desestruturaram nosso gerente de projeto! Eduardo e Monica resolveram discutir novamente as precedéncias, chegando @uma nova configuracdo apresentada na Tabela 6.4. : 124 Fundamentos em gestio de projetos + Carvalho ¢ Rabechin J. Tabela 6.4 Precedéncias revisadas. WBS ~ 12 Nivel Precedéncia » , Duragdo (dias) | WBS01. Servicos preliminares ——. 20 WBS02. Projeto ——— 40 WBS03. Construcao WBSO1;WBSO2 214 WBSO4. Sistemas WBSO1;WBSO2 70 [ wes0s. Acabamento WBSO3;WBSO4 142 WBSO6. Servicos complementares wesos 20 Dessa vez, Eduardo fez rapidamente a representagao ADM e percebeu que j&estava mais seguro com a técnica. O resultado esté na Figura 6.13. alae sdzsq) 2 das oda 20 dias saat l 416 dias (~ 14 meses) J Figura 6.13 ADM do projeto de Eduardo e Ménica — versio revisada. Gestio de tempo do projeto 125 4 : ss Servicos —= Servigo st | Preiminares [Jy MLConstuste |} ——rpeabament|—>| omer ertares oe Construcad abaménti ° foe . Figura 6.14 PDM do projeto de Eduardo e Ménica — versao revisada. Como a Eduardo dominava melhor a elabora¢do do Grafico de Gantt, resolveu utiliza-lo para checar o resultado, elaborando um diagrama para a programacao para frente e outro para trés, conforme ilustram as Figuras 6.15 ¢ 6.16. Além disso, julgou que essa representagao facilitaria a compreensao de Ménica, que nao tinha muita familiaridade com as técnicas de Gestao de Projetos, embora ela geralmente no tivesse dificuldade alguma para aprender. Servigos, « Preliminares Projeto Construgao+ Sistemas ‘Acabamento, Servicos Complementares Figura 6.15 Diagrama de Gantt do projeto de Eduardo e Ménica - data cedo. Te Servigos Preliminares Projeto Construéo Sistemas 1 Acabamento Ser rvigos ern Complementares Figura 6.16 Diagrama de Gantt do projeto de Eduardo e Monica ~‘data tarde. | | 126 Fundamentos em gestio de projets + Carvalho e Rabechini J. Eduardo explicou a Ménica que nessa nova representacao duas atividades nao eram criticas — servicds preliminares e sistemas. Nessas atividades, havia folga total de 20 dias para servicos preliminares e de 144 dias para sistemas. Ménica ficou encantada com o resultado; apenas por rever as precedéncias, eles tinham economizado quase dois meses de obra. Contudo, desta vez foi Eduardo que alertou: “— Acho melhor marcarmos uma reunido com o pessoal da Modelo Engenharia, Arquitetura e Construcio S.C. Ltda., pois como sao especia- listas em construcdo civil, podem arbitrar melhor quanto as precedéncias e tempos. ~ Além disto, agora sinto que domino melhor as técnicas de represen- tagdo e que, portanto, podemos utilizar um nivel maior de detalhamento, chegando até atividade.” Ménica concordou e delegou a Eduardo essa tarefa. Antes de terminarem essa discussao sobre o gerenciamento do prazo do pro- jeto, Eduardo lembrou-se de que eles deveriam discutir quais seriam os marcos temporais (milestones) do projeto. * Eles retornaram 4 WBS e pensaram em seus pacotes de trabalho, chegando & conclusdo de que os principais marcos coincidiriam com as seguintes entregas (deliverables): : * Marco 1: entrega das plantas (arquitetura, estrutura e elétrica/hidrau- lica) e do alvard de constru¢ao; a * Marco 2: entrega do canteiro de obras pronto com luz e agua conectadas; * Marco 3: entrega das fundagées da casa; * Marco 4: entrega do 12 pacote associado a construco, que seria a con- cretagem da primeira laje; * Marco 5: entrega do 22 pacote associado a construgao, que seria a con- cretagem da segunda laje; ~ * Marco 6: entrega do 32 pacote associado 4 construgao, que seria a co- bertura (telhado) pronto; Marco 7: entrega do 42 pacote associado a construcdo, que seria a co- locacao de todas as esquadrias; . Marco 8: entrega dos sistemas elétricos; Marco 9: entrega dos sistemas hidrdulicos; . Marco 10: entrega'do 12 pacote associado ao acabamento, que seria a colocagao de todos ds pisos e revestimentos; =) Gestdo de tempo do projeto 127 * Marco 11: entrega do 2° pacote associado ao acabamento, que seria a colocacao dos vidros; ie _ * Marco 12: entrega do 3 pacote’associado ao acabamento, que seria a pintura interna e externa da casa; * Marco 13: entrega da jardinagem da area externa e do jardim de inverno prontos. 6.3.2 Programacao utilizando o PERT Conforme comentado, o PERT utiliza um sistema estocdstico de estimativa de duracdes para cada atividade do projeto. Nesse método, sao feitas trés est mativas de tempo, admitindo-se que a execugao de uma atividade nao interfere no tempo de execucao de outras, ou seja, so independentes. As trés estimativas sao as seguintes: * Mais provvel: duracao baseada no cendrio mais provavel em que os recursos alocados estdo disponiveis e demais premissas do projeto também sio observadas. * Otimista: duragdo baseada no cenério mais positivo. * Pessimista: duracdo baseada no cendrio mais negativo. Com base nessas trés estimativas, é possivel calcular a duraco esperada da atividade, utilizando a distribuigéo Beta de probabilidades, conforme ilustra a Figura 6.17. Mais alta Mais Provavel (usada nos calculos originais do CPM) PERT Média Ponderada = Possibilidade 4— |Otimista + 4 x Mais Provavel + Pessimista Relativa da 6 Ocorréncia 7 a Distribuicdo Beta Mais Re bebe baixa Baer Mais curta Mais longa Possibilidade de Duracao Fonte: Adaptada de PMI (2008). Figura 6.17 Distribuigaio de probabilidade Beta. K a 128 Fundamentos em gestio de projetos + Carvalho e Rabechini J. Para obter a duracdo esperada das atividades do projeto, devem-se adotar as seguintes equagdes: * © - Equacio 6.6 4; = (a+ 4m + b)/6 em que: a éa duracao otimista; b é a duracdo pessimista; m éa duracao mais provavel; d, é a duragio esperada da atividade. Equag4o 6.7 8,2 = [(b-a)/6)? em que: s,? € a variancia da duracao da atividade. Como as datas cedo e tarde resultam da soma de varidveis aleatérias di), admite-se que elas tém distribuicdo normal, pelo Teorema do Limite Central. Dessa forma, a estimativa de duracao do projeto é obtida pela soma das duragées de todas as atividades do caminho critico. A varidncia do projeto é obtida pela soma das variancias das atividades do caminho critico. Gestio de tempo do projet 129 Calculando as probabilidades UX=T -50 Distribuigdo Normal s=5 7 sat Normal Padrao bs T=40 50 x Fonte: Adaptada de Heizer e Render (1999). Figura 6.18 Calculo do valor de z para a durasao do projeto. i‘ Calculando as probabilidades Tabela Normal Padrao 0,97784 | 0,97831 0,98257 | 0,98300 Probabilidades Fonte: Adaptada de Heizer e Render (1999) Figura 6.19 Célculo da probabilidade de conclusdo do projeto. 6.3.3 Outras técnicas de programacao Existem outras formas de programac&o menos difundidas, mas que em casos especificos e em geral mais complexos podem ser de grande utilidade. Entre esses métodos, podemos citar 0 GERT - Graphical Evaluation and Review Technique -, 0 da corrente critica e o método de cendrios what-if. OGERT foi criado para o desenvolvimento de redes mais complexas que nado poderiam ser elaboradas utilizando-se o PERT ou o CPM. Segundo Meredith, Mantel Jr. (1995), esse método combina fluxogramas (ver CDM — Conditional Diagramming Method) e redes probabilisticas, PERT/CPM e arvores de deciséo em um tnico método. Nessa forma de representac4o, s4o permitidos loops e desvios condicionados, que tanto no PDM como no ADM nio sao permitidos. 130 Fundamentos em gestdo de projetos. + Carvalho e Rabechini Jt. ty gE Gestdo de tempo do projeto 131 O método da corrente critica (critical chain) foi criado por Goldratt, o autor da Tabela 6.5 Dados do projeto. teoria das restrig6es e do livro A meta, que estende o conceito de gargalo parao | 7 Atividade Precedénci ambiente de projetos. A corrente critica parte do pressuposto de que os recursos ence oo x P limitados (gargalos) é que devem reger a programaco, mesclando os enfoques A 2 uo 25 7 i deterministico e probabilistico. A rede do projeto é elaborada considerando-se as B —F Fi 1 3 i 4 dependéncias e definindo as restric6es logo no inicio. Calcula-se ent4o o caminho ae critico, alocando-se os recursos disponiveis nas atividades criticas. Essa andlise, 2 2 7 15 4 semelhanca do que ocorre no nivelamento de recursos, geralmente afeta 0 cro- “ob B 2 4 2 nograma inicial programado. Além disso, esse método considera que o caminho Ta a 3 7 | critico é um alvo mével, que deve ser muito bem gerenciado. Como na teoria : : z | das restric6es, o método da corrente critica adota pulmées (buffers), que nao sao : E A 9 14 25 atividades, o que permite manter 0 foco na duracao planejada das atividades. G EF 1 1 1 O autor argumenta que, em geral, as estimativas de duragao apresentam uma H ao margem de seguranga, ou seja, s4o superestimadas e essa folga nao é detectada - zs a ul 12 | na programacio do PERT/CPM. O método enfatiza a gestao dos pulmées (buffer) | 1 B 1 2 9 il | e nao a gestio das folgas, utilizando apenas estimativas otimistas das dura¢des i GH 15 25 12,5 a programagao na data mais tarde (backward). . “ " i 14 * Tempo de duracdo em semanas. ' i A anilise what-if utiliza conceito de cendrios aliado a redes légicas (PMI, . 4 2008). Provoca-se a discussio de questées do tipo “E se a situacao representada it al pelo cenario X ocorrer?”, permitindo que a viabilidade de execucao do crono- Pede-se: Hi Pool grama seja avaliada, bem como planos de contingéncias e de resposta, podendo 7 f fw fazer usos das técnicas de simulagao. Essa técnica é feita em grande integragao * Construir a rede de eventos do projeto; i I com a rea de gesto de risco. : * Calcular as datas mais cedo e tarde dos eventos; | | * Calcular a probabilidade de se executar 0 projeto até trés semanas antes i of 6.4 Exercicios resolvidos da durago esperada. Um projeto é constituido de dez atividades, conforme Tabela 6.5: i Gestdo de tempo do projet 133 | 132 Fundamentos em gestéo de projetos + Carvalho ¢ Rabechin Jt, ——— ty Tabela 6.6 Di je . ‘ | al ados do projeto. 1 | qabela 6.7 Dados do projeto. *"*: : 1 i 5 lade | Precedénci oO: M P qd o fT Fe a fa i Atividade Precedéncia dy FT FL —— 1 25 7 3 1 0 0 i A chef ted 0 0 — 1 3 1" 4 | 28 2 0 | B 4 0 0 A 5 7 15 8 28 0 0 | t c 6 0 0 B 2 4 12 5 28 2 2 i D 5 8 0 cD 3 4s 9 5 1 4 2 | E 4 0 0 A 9 14 | 25 | 15 | 7A 2 ° } F . F 7 8 0 EF 1 1 1 1 0 2 2 G 5 5 5 cD 4 1" 12 | 10 | 18 0 0 5 | 9 H 6 0 0 Hi Ht 1 18 14 14 % Hk ' 8 7 2 2 _ 1 EF 8 8 0 van J GH! 15 | 25 | 12,5 4 3,36 oO 0 ‘ Loy e “ J GH 9 0 0 1 kK J 5 0 0 | L J 4 1 0 M KL Distribuigao Normal Normal Padrao ab & ° e 2 8 ss P= 0,1587, N ! 8 * Tempo de duracao em semanas. 5 22025 x 1,0 0 Zz ; Um projeto é constituido de 14 atividades, conforme Tabela 6.7. Construaa rede de eventos e calcule as folgas total e livre para todas as atividades. | 134 Fundamentos em gestio de projetos * Carvalho e Rabechini Jr. Questées para reflexo e discussao Quais sao os principais métodos de programacio? Quais sao as formas mais utilizadas para representacao dos projetos? Quais sao as vantagens e desvantagens do Diagrama de Gantt? © que difere o diagrama de Gantt do Diagrama de Marcos? Quais sdo as semelhancas e diferencas do PERT e do CPM? Quais cuidados devem ser tomados para gerar boas estimativas? Defina estimativa bottom-up e top-down. Descreva as vantagens e desvantagens de cada método. ee 8. A Loja de departamento decidiu reformar suas instalacdes. No entanto, precisa ficar fechada durante a reforma. O conselho de diretores estima que a empresa nao pode suportar mais de 15 dias fechada. Todas as atividades envolvidas nesse projeto, suas precedéncias, seus tempos estimados e variancias estao descritos na tabela a seguir. Utilizando-se a técnica PERT, pede-se: * Qual éa rede de eventos desse projeto? Quais sdo as datas mais cedo e tarde de cada evento do projeto e o caminho critico? * Qual a probabilidade de o projeto ser entregue no prazo limite de 16 dias, ou antes? * No final do projeto houve um problema no acabamento (atividade F), 0 que levou a um atraso de trés semanas. Qual o impacto desse atraso na duragao do projeto? Duragées (semanas) Atividade | Precedéncia | Otimista Provavel : A : —_— 1 - 2 B — 2 3 c A 1 2 D B 2 4 E c 1 4 F c 1 2 G DE, 3 4 u H FG 1 2 3 9. Uma empresa de software foi contratada para desenvolver um sistema con- tabil para uma clinica médica. Os contratantes estabeleceram uma multa Gestdo de tempo do projeto 135 z— contratual por atraso. O contrato previa a entrega em trés meses. Os dados do projeto estao na tabela a seguir. Serd possivel concluir 0 projeto sem pagar amulta? Atividade | Precedéncia Duragao A — 5s | B — 5 ic — " D c Zz E A 5 F BeD 9 G c 20 10. Digamos que no projeto da questo 9 fosse possivel alterar a precedéncia da atividade F; a equipe julgou que a precedéncia B era muito conservadora e que essas duas atividades poderiam ser feitas em paralelo. O que essa decisao implicaria para 0 projeto como um todo? 7 Qualidade Neste capitulo, sera tratada a questdo do gerenciamento do custo dos projetos. Apés esta unidade, o leitor tera condicdes de responder as seguin- tes questée: a) Quais os processos que suportam o gerenciamento dos custos do projeto? b) Como elaborar um bom or¢amento? ©) Oque éacurva$ do projeto? Como construir a linha base (baseline) de custos do projeto? d) Como fazer a andlise de valor agregado? e) Como gerar indicadores de custo e prazo e monitora-los? Quantas vezes vocé jase surpreendeu gastando bem mais do que havia pre- visto, quer seja numa viagem de turismo, na reforma da casa ou mesmo na festa Gestdo de custos 137 de casamento? Isso sem contat com as manchetes de estouro no or¢amento de obras publicas e nos relatérios de desempenho:dos projetos da empresa em que trabalha. oa H to Por que é to dificil fazer boas estimativas de custo em projetos? O que mais dificulta é 0 fato de os projetos serem tnicos (singulares). Por mais que tenhamos dados histéricos de atividades e de projetos similares, estamos sempre trabalhando com analogias e, portanto, sujeitos a imprecisées. Por isso é tao importante nfo sé ter cuidado nas estimativas, mas também controlar o projeto bem de perto, verificando os desvios de rota, recalculando as estimativas e fazendo as alteracdes necessdrias sempre de forma preventiva. 7.1 -Introdugao O PMBoK® (PMI, 2008) dedica um capitulo para discutir os processos ne- cessdrios para uma boa gestao de custos, visando garantir sua conclusao dentro do custo estimado, permitindo gerar um fluxo de caixa positivo para o projeto € minimizando a utilizagdo das reservas financeiras do projeto. Os processos considerados pelo PMBoK (PMI, 2008) no gerenciamento de custos do projeto sao: © a) Estimar os custos: estimar os custos dos recursos necessarios para completar todas as atividades do projeto. ' b) Determinar o or¢amento: valor agregado de todas as estimativas de cus- tos, somando as estimativas de cada atividade ou pacotes de trabalho, para estabelecer a linha-base (baseline) de custo do projeto para fim de orgamento. ) Controlar os custos: influenciar os fatores geradores de custos adicionais e controlar as mudangas no orcamento ao longo da evolugao do projeto. Conforme mencionamos no Capitulo 6, desde sua 34 edicao, o PMBoK® (PMI, 2004) trouxe um processo a mais na gest4o do tempo com relacdo verso de 2000, que é a estimativa dos recursos das atividades. Esse processo pertencia 4 gestao de custos. Esta mudanga permitiu que as estimativas de recursos e duracdes das atividades fossem feitas de forma mais sinérgica nos processos de gest&o do tempo. Portanto, na gestao de custos do projeto estamos preocupados com a elabora- ¢40 e o controle do orcamento do projeto, de forma agregada e nao atividade por atividade, gerindo os fatores que podem influencié-lo e desvid-lo dos desejados. Contudo, para uma boa gestao de custos, é necessaria boa integracdo com as demais dreas de Gesto do Projeto, em especial com aquelas que fazem parte do triangulo dos objetivos primérios — escopo, prazo e custo (Capitulo,1). Além 138 Fundamentos em gestéo de projets * Carvalho e Rabechin Jr dessas, a 4rea de risco fornece informagées vitais para a boa gestao de custos, bem como a 4rea de integra¢ao,.que deve estar ciente de qualquer alteragao nos planos do projeto. A Figura 7.1 ilustra os principais relacionamentos da gestao dos custos com as demais areas do PMBoK®. A area de custo tem forte integrac¢do com as dreas de integra¢4o, escopo, prazo e risco do projeto. Além disso, a 4rea de comunicagées deve, através dos seus Relatérios de Desempenho, trazer insumos importantes para a analise dos riscos do projeto. A Figura 7.1 ilustra os principais relacionamentos da gestZo de custos com as demais areas. 2 Gestio norman stent cextzo ae de integracio Fano de roto TST PA moctcrmer — [iaseimar al dee Elke al ‘infegragae EL custos cf] TSR Ty iene of Venera anode Gestbo. oH ge Rit yee | |__ Fy Determinar? Fao de Projto toeatiag) . [| Lorearmento Fano de Projet aan) acre ‘eben Cones * organics egies de Mudagss Gestio de Integragso iso) Fonte: Adaptada de PMI (2008). Figura 7.1 Fluxo dos processos de gestdo de custos. ron . Atty g L Gestdo de custos. 139 7.2" Preparando o orcamento do projeto” Para iniciarmos a orcamenta¢ao, precisamos resgatar informagoes de outras 4reas do PMBoK®, que sero necessarias para o desenvolvimento da estrutura de custo do projeto, em especial escopo, prazo é risco. O primeiro passo do gerenciamento de custos é obter boas estimativas. Esse rocesso envolve o levantamento dos recursos necessarios para completar as ati- vidades do projeto, que, agregados, permitirao o desenvolvimento da estimativa dos cisstos do projeto. Essa informacao depende também do plano de contas ou cédigos de contas que foram montados para o projeto em curso. Nesse plano, a estrutura de codifica¢ao utilizada pela organizacao é detalhadamente descrita, permitindo que os gastos e demais informacGes financeiras do projeto sejam adequadamente reportados para seu sistema contabil. Se o gestor do projeto nao tiver esse cuidado na apurago dos custos do projeto, as informagGes financeiras ficardo misturadas com as de outras atividades rotineiras da organizaco, o que prejudicara sobremaneira a estrutura de apuragao dos custos. Em geral, no inicio do ciclo de vida do projeto as estimativas por analogia (top- down) sao mais utilizadas e, com o desenvolvimento do projeto e detalhamento das atividades, as estimativas bottom-up podem substituir com maior precisao as estimativas preliminares realizadas (rever estimativas no Capitulo 6). Concluido o processo de estimativas de custo, pode-se iniciar a orcamentacao do projeto. O objetivo do processo de orcamentacao é gerar a linha base (baseline) de custo do projeto. Caso.7.1: qual ser 0 fluxo de caixa minimo necessdrio para suportar a obra? Eduardo e Ménica estavam adiando a reuniao sobre o planejamento dos custos do projeto, pois sabiam que este seria um momento critico e repleto de discussdes. O primeiro passo foi buscar referencial de custo para a obra. Como ainda nao tinham informagées detalhadas das atividades do projeto, resolveram procurar em revistas especializadas informag6es sobre custos na construcao. Eduardo lembrou-se de que nas aulas de Gestao de Projetos aprendera a utilizar modelagem paramétrica para prospectar 0s custos totais do projeto. O importante para utilizar essa técnica de modelagem matematica era identificar o(s) parametro(s) critico(s) do projeto, que no seu caso era a metragem da casa. Seu professor havia advertido sobre os problemas de preciso das informagées que eram colocadas no modelo. ‘Monica encontrou na Internet o indice A&C, que lhe pareceu bastante interes- sante, pois fornecia dados de custo por metro quadrado (R$/m?), segmentado por regio e por tipo de acabamento, conforme ilustra a Tabela 7.1. 88 SY rr 4